On Wed, Jan 16, 2019 at 07:10:18PM +0100, Sam Ravnborg wrote:> Hi Daniel. > > > v5: Actually try to sort them, and while at it, sort all the ones I > > touch. > > Applied this variant on top of drm-misc and did a build test. > Looked good for ia64, x86 and alpha. > > Took a closer look at the changes to atmel_hlcd - and they looked OK. > > But I noticed that atmel_hlcdc uses only drm_kms_helper_poll_init() and > drm_kms_helper_poll_fini(). > But there are no hits on DRM_CONNECTOR_POLL - so I think we maybe > have a driver here where we have plugged the drm_poll infrastructure, > but it is not in use. > > > include/drm/drm_crtc_helper.h | 16 ----------- > > The list of include files in this file could be dropped and replaced by: > struct drm_connector; > struct drm_device; > struct drm_display_mode; > struct drm_encoder; > struct drm_framebuffer; > struct drm_mode_set; > struct drm_modeset_acquire_ctx; > > I tried to do so on top of your patch. > But there were too many build errros and I somehow lost the motivation.Yeah the drm_crtc_helper.h header is a bit the miniature drmP.h for legacy kms drivers. Just removing it from all the atomic drivers caused lots of fallout, I expect even more if you entirely remove the includes it has. Maybe a todo, care to pls create that patch since it's your idea? -Daniel> > > > include/drm/drm_probe_helper.h | 27 +++++++++++++++++++ > This on the other hand is fine - as expected as this is a new file. > > But the above is just some random comments so: > > Acked-by: Sam Ravnborg <sam at ravnborg.org>-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
On Thu, Jan 17, 2019 at 05:45:41PM +0100, Daniel Vetter wrote:> On Wed, Jan 16, 2019 at 07:10:18PM +0100, Sam Ravnborg wrote: > > Hi Daniel. > > > > > v5: Actually try to sort them, and while at it, sort all the ones I > > > touch. > > > > Applied this variant on top of drm-misc and did a build test. > > Looked good for ia64, x86 and alpha. > > > > Took a closer look at the changes to atmel_hlcd - and they looked OK. > > > > But I noticed that atmel_hlcdc uses only drm_kms_helper_poll_init() and > > drm_kms_helper_poll_fini(). > > But there are no hits on DRM_CONNECTOR_POLL - so I think we maybe > > have a driver here where we have plugged the drm_poll infrastructure, > > but it is not in use. > > > > > include/drm/drm_crtc_helper.h | 16 ----------- > > > > The list of include files in this file could be dropped and replaced by: > > struct drm_connector; > > struct drm_device; > > struct drm_display_mode; > > struct drm_encoder; > > struct drm_framebuffer; > > struct drm_mode_set; > > struct drm_modeset_acquire_ctx; > > > > I tried to do so on top of your patch. > > But there were too many build errros and I somehow lost the motivation. > > Yeah the drm_crtc_helper.h header is a bit the miniature drmP.h for legacy > kms drivers. Just removing it from all the atomic drivers caused lots of > fallout, I expect even more if you entirely remove the includes it has. > Maybe a todo, care to pls create that patch since it's your idea?The main reason I bailed out initially was that this would create small changes to several otherwise seldomly touched files. And then we would later come and remove drmP.h - so lots of small but incremental changes to the same otherwise seldomly edited files. And the job was only partially done. I will try to experiment with an approach where I clean up the include/drm/*.h files a little (like suggested above, +delete drmP.h and maybe a bit more). Then to try on a driver by driver basis to make it build with a cleaned set of include files. I hope that the cleaned up driver can still build without the cleaned header files so the changes can be submitted piecemal. Will do so with an eye on the lesser maintained drivers to try it out to avoid creating too much chrunch for others. And if it works out I expect the active drivers to follow the example. todo.rst item will wait until I run out of energy. Sam
Hi Daniel et al.> > > > Yeah the drm_crtc_helper.h header is a bit the miniature drmP.h for legacy > > kms drivers. Just removing it from all the atomic drivers caused lots of > > fallout, I expect even more if you entirely remove the includes it has. > > Maybe a todo, care to pls create that patch since it's your idea? > > The main reason I bailed out initially was that this would create > small changes to several otherwise seldomly touched files. > And then we would later come and remove drmP.h - so lots of > small but incremental changes to the same otherwise seldomly > edited files. > And the job was only partially done. > > I will try to experiment with an approach where I clean up the > include/drm/*.h files a little (like suggested above, +delete drmP.h > and maybe a bit more). > > Then to try on a driver by driver basis to make it build with a > cleaned set of include files. > I hope that the cleaned up driver can still build without the > cleaned header files so the changes can be submitted piecemal. > > Will do so with an eye on the lesser maintained drivers to try it > out to avoid creating too much chrunch for others.I have now a few patches queued, but the result is not too pretty. I did the following: - For all files in include/drm/*.h the set of include files were adjusted to the minimum number of files required to make them build without any other files included first. Created one .c file for each .h file. Then included the .h file and adjusted to the minimal set of include files. In the process a lot of forwards were added. - Deleted drmP.h - Fixed build of a few drivers: sti, tilcdc, gma500, tve200, via Some observations: - Killing all the includes not needed in the headers files results in a a lot of extra changes. Examples: drm_modseset_helper_vtables.h is no longer included by anyone, so needs to be added in many files drm_atomic_state_helper.h is no longer included by anyone so likewise needs to be added in many files - It is very tedious to do this properly. The process I followed was: - delete / comment out all include files - add back the obvious from a quick scan of the code - build - fix - build - fix - build - fix ... - next file... - The result is errorprone as only the allyesconfig + allmodconfig variants are tested. But reallife configurations are more diverse. Current diffstat: 111 files changed, 771 insertions(+), 401 deletions(-) This is for the 5 drivers alone and not the header cleanup. So long story short - this is not good and not the way forward. I will try to come up with a few improvements to make the headers files selfcontained, but restricted to the changes that add forwards/include to avoid the chrunch in all the drivers. And then post for review a few patches to clean up some headers. If the cleanup gets a go I will try to persuade the introduction of these. This will include, but will not be limited to, the above mentioned drm_crtc_helper.h header file. For now too much time was already spent on this, so it is at the moment pushed back on my TODO list. This mail serve also as a kind of "where had I left", when/if I pick this up again. If there are anyone that knows some tooling that can help in the process of adjusting the header files I am all ears. Sam