From: Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>
To: Sam Ravnborg <sam-uyr5N9Q2VtJg9hUCZPvPmw@public.gmane.org>
Cc: Neil Armstrong
<narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>,
Nouveau Dev
<nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
Liviu Dudau <liviu.dudau-5wv7dgnIgG8@public.gmane.org>,
DRI Development
<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
"open list:VIRTIO CORE,
NET..."
<virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>,
Daniel Vetter
<daniel.vetter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
linux-stm32-XDFAJ8BFU24N7RejjzZ/Li2xQDfSxrLKVpNB7YpNyf8@public.gmane.org,
linux-samsung-soc
<linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Oleksandr Andrushchenko
<oleksandr_andrushchenko-uRwfk40T5oI@public.gmane.org>,
amd-gfx list
<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"open list:DRM DRIVER FOR QXL VIRTUAL GPU"
<spice-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
Jani Nikula <jani.nikula-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
linux-arm-msm
<linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
intel-gfx
<intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
The etnaviv authors
<etnaviv-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: [PATCH] drm: Split out drm_probe_helper.h
Date: Tue, 22 Jan 2019 09:03:36 +0100 [thread overview]
Message-ID: <CAKMK7uF_8yRycA4ZUyudH7dM23DOiFEkKStAbbAvD=79y_UE_Q@mail.gmail.com> (raw)
In-Reply-To: <20190121221329.GA6512-uyr5N9Q2VtJg9hUCZPvPmw@public.gmane.org>
On Mon, Jan 21, 2019 at 11:13 PM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> 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.
Yeah in the process of splitting up drmP.h we've created a few smaller
such piles of headers. I think in some cases it's just not going to be
worth it to fully split them up, e.g. drm_crtc_helper.h is going to be
a pure legacy helper, only needed by pre-atomic drivers. Splitting
that up doesn't seem to useful to me. Similarly we might want
drm_atomic_helper.h to keep pulling in the other helper headers. So
probably going to be a judgement call on a case-by-case basis.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2019-01-22 8:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-16 16:34 [PATCH] drm: Split out drm_probe_helper.h Daniel Vetter
2019-01-16 18:10 ` Sam Ravnborg
[not found] ` <20190116181018.GA27364-uyr5N9Q2VtJg9hUCZPvPmw@public.gmane.org>
2019-01-17 16:45 ` Daniel Vetter
2019-01-17 17:45 ` Sam Ravnborg
2019-01-21 22:13 ` Sam Ravnborg
[not found] ` <20190121221329.GA6512-uyr5N9Q2VtJg9hUCZPvPmw@public.gmane.org>
2019-01-22 8:03 ` Daniel Vetter [this message]
2019-01-17 21:03 ` Daniel Vetter
2019-01-22 21:16 ` Wentland, Harry
[not found] ` <20190117210334.13234-1-daniel.vetter-/w4YWyX8dFk@public.gmane.org>
2019-01-23 17:00 ` Sam Ravnborg
2019-01-24 9:46 ` Daniel Vetter
[not found] ` <20190124094646.GR3271-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2019-01-24 12:39 ` Daniel Vetter
-- strict thread matches above, loose matches on Subject: below --
2019-01-16 13:51 Daniel Vetter
2019-01-15 10:41 Daniel Vetter
[not found] ` <20190115104137.25695-1-daniel.vetter-/w4YWyX8dFk@public.gmane.org>
2019-01-15 10:57 ` Jani Nikula
2019-01-15 12:26 ` Neil Armstrong
2019-01-15 14:58 ` Oleksandr Andrushchenko
2019-01-16 3:30 ` Alex Deucher
2019-01-15 14:30 ` Laurent Pinchart
2019-01-16 2:11 ` CK Hu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAKMK7uF_8yRycA4ZUyudH7dM23DOiFEkKStAbbAvD=79y_UE_Q@mail.gmail.com' \
--to=daniel-/w4ywyx8dfk@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=daniel.vetter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=etnaviv-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=jani.nikula-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org \
--cc=linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-stm32-XDFAJ8BFU24N7RejjzZ/Li2xQDfSxrLKVpNB7YpNyf8@public.gmane.org \
--cc=liviu.dudau-5wv7dgnIgG8@public.gmane.org \
--cc=narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org \
--cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=oleksandr_andrushchenko-uRwfk40T5oI@public.gmane.org \
--cc=sam-uyr5N9Q2VtJg9hUCZPvPmw@public.gmane.org \
--cc=spice-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).