On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote: > Current version of DC: > > * https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7 > > Once Alex pulls in the latest patches: > > * https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7 One more: That 4.7 here is going to be unbelievable amounts of pain for you. Yes it's a totally sensible idea to just freeze your baseline kernel because then linux looks a lot more like Windows where the driver abi is frozen. But it makes following upstream entirely impossible, because rebasing is always a pain and hence postponed. Which means you can't just use the latest stuff in upstream drm, which means collaboration with others and sharing bugfixes in core is a lot more pain, which then means you do more than necessary in your own code and results in HALs like DAL, perpetuating the entire mess. So I think you don't just need to demidlayer DAL/DC, you also need to demidlayer your development process. In our experience here at Intel that needs continuous integration testing (in drm-tip), because even 1 month of not resyncing with drm-next is sometimes way too long. See e.g. the controlD regression we just had. And DAL is stuck on a 1 year old kernel, so pretty much only of historical significance and otherwise dead code. And then for any stuff which isn't upstream yet (like your internal enabling, or DAL here, or our own internal enabling) you need continuous rebasing&re-validation. When we started doing this years ago it was still manually, but we still rebased like every few days to keep the pain down and adjust continuously to upstream evolution. But then going to a continous rebase bot that sends you mail when something goes wrong was again a massive improvement. I guess in the end Conway's law that your software architecture necessarily reflects how you organize your teams applies again. Fix your process and it'll become glaringly obvious to everyone involved that DC-the-design as-is is entirely unworkeable and how it needs to be fixed. >From my own experience over the past few years: Doing that is a fun journey ;-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
