It took me about 5 to 6 days to figure out what was wrong with the code, but I am happy to report that the initial implementation of TTM memory allocator for OpenChrome DRM appears to be working okay.  I have not gone through all the tests I should be doing at this point, but at least it is working on my HP 2133 mini-note.  I booted my usual Xubuntu 16.04.5 LTS 32-bit and now the code can start up the X Server properly.  Of course, standby resume is also working fine (A small unrelated bug with FP detection right after standby resume still exists in the code, but I have not encountered this yet).  I expect it will take another week or two to properly clean up the code for the commit push into the upstream repository.

Finally, I got the new TTM memory allocator code merged with OpenChrome DRM.  The code now compiles without syntax errors.  As expected, it could not boot the X Server the first time or the second time I tried it.  I am still working on getting it to work properly, and I expect this to take a week or two.  Code commit will probably not happen for 2 to 3 weeks.  Anyway, this is a huge step forward for OpenChrome Project, and my other future underserved graphics device revival projects.

I am now in the process of compiling the new TTM memory allocator code for OpenChrome DRM.  I hope to test the code for the first time by tomorrow.  Again, I plan to reuse the code with the future DRM modernization project (i.e., adding Kernel Mode Setting or KMS support) for underserved PCI / AGP graphics devices.  That project has stalled for now pending the validation of TTM memory allocator code.  It will resume once the code is proven.  Things are pretty much going along the lines described in my XDC 2017 OpenChrome Project presentation, except the schedule.

OpenChrome DRM drm-next-4.21 branch is now EOL.  The bleeding edge development has now transitioned to drm-next-5.1 branch.  Currently, working on integrating the new TTM memory allocator and I hope to compile the code in the next few days.

It is 3 months late, but . . ., OpenChrome DRM drm-next-4.20 branch is now EOL.  The bleeding edge development has now transitioned to drm-next-4.21 branch.

I finished removing the unfinished acceleration code.  It was a little harder than I expected it and took a few days, but the code is back to working fine.  Now that there is an ABI break, the version of OpenChrome DRM is now Version 3.1.x rather than 3.0.x.

When the code is finally in the Linux kernel mainline tree, I expect the version to be incremented to Version 4.0.x.  There will be no acceleration support initially.  Version 4.1.x and later should support acceleration.

I am now in the process of integrating my own TTM memory allocator into OpenChrome DRM.  I expect this to take a few weeks.  I hope to reuse this code with other DRM implementations down the road.

Although it appears from the outside that the development pace of OpenChrome DRM has slowed down considerably over the past few months (i.e., frequency of the code commit into the OpenChrome DRM upstream repository), I have been working on implementing my own implementation of TTM memory allocator since July 2018.  After trying out several implementation ideas, I am hoping the current implementation will work out.  The code has not even been through compilation yet, and even after this, it may not work right away.  I hope to get the TTM memory allocator committed in the next few weeks.

That being said, I was told by the DRM maintainer back in June 2018 that I will need to remove the previous developer, James Simmons, developed unfinished acceleration related code before Linux kernel tree mainlining.  The thing is, I do not really like the code quality of the acceleration related code along with the fact that I want more control of the design of the acceleration related code.  I now plan to throw out all the unfinished acceleration related code.  I am in the process of doing this for the past few days, but due to various interlocking modules of the code present in the OpenChrome DRM, it is taking longer than I hoped.

My plan is to remove all of the unfinished acceleration related code, compile OpenChrome DRM to see if the code is still working fine.  After that, I plan to substitute in my own initialization code and header file.  Then, I plan to integrate my own TTM memory allocator code with OpenChrome DRM.

I will write more when I have something new to report.