[PATCH v1 0/11] drm: move dri1 drivers to drm/dri1/
Sam Ravnborg
sam at ravnborg.org
Mon Jul 18 07:56:39 UTC 2022
Hi Thomas,
On Mon, Jul 18, 2022 at 08:56:16AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 16.07.22 um 20:17 schrieb Sam Ravnborg:
> > While discussing the way forward for the via driver
> > Javier came up with the proposal to move all DRI1 drivers
> > to their own folder.
> >
> > The idea is to move the old DRI1 drivers so one do not
> > accidentally consider them modern drivers.
> >
> > This set of patches implements this idea.
> >
> > To prepare the move, DRIVER_LEGACY and CONFIG_DRM_LEGACY
> > are both renamed to *_DRI1. This makes it more obvious
> > that we are dealing with DRI1 drivers, as we have
> > a lot of other legacy support.
> >
> > The drivers continue to have their own sub-directory
> > so the driver files are not mixed with the core files
> > which are copied in the last commit.
> >
> > The DRI1 specific part of drm/Kconfig is likewise pulled
> > out and located in the dri1/ folder.
> >
> > Feedback welcome!
>
> To be honest, I still don't like this rename. Especially in the case of via,
> which has a KMS driver coming up. It will now have an include statement that
> crosses several levels in the directory hierarchy. And what about the other
> DRI1 drivers? If we ever get KMS drivers for those, do we want to move some
> header files back into their original locations? Patches 1 and 2 look
> reasonable to me. The other driver patches have basically zero upside IMHO.
Until there are consensus, if ever, I will drop the patches moving the drivers.
There is a few DRIVER_LEGACY in Documentation/ that I missed, so will
send a v2 with these.
> In the case of moving the core files into dri1/, the resulting Makefile rule
> looks really ugly. I'd suggest to move all code into a separate file
> drm_dri1.c and be done with it. For something more elaborate, there could
> by drm_dri1.c and drm_dri1_helper.c, where the latter contains all DRI1 code
> that is only used by the drivers.
If we do not move the core code, then this is a good way to tell this is dri1
specific. I may try to give it a spin - but just as a single file I think.
Sam
More information about the dri-devel
mailing list