| Message ID | 20220716181750.3874838-1-sam@ravnborg.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm: move dri1 drivers to drm/dri1/ | expand |
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. 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. Best regards Thomsa > > Sam > > Sam Ravnborg (11): > drm: rename DRIVER_LEGACY to DRIVER_DRI1 > drm: Rename CONFIG_DRM_LEGACY to CONFIG_DRM_DRI1 > drm/tdfx: Move the tdfx driver to drm/dri1/ > drm/r128: Move the r128 driver to drm/dri1/ > drm/i810: Move the i810 driver to drm/dri1/ > drm/mga: Move the mga driver to drm/dri1/ > drm/sis: Move the sis driver to drm/dri1/ > drm/via: Move the via driver to drm/dri1/ > drm/savage: Move the savage driver to drm/dri1/ > drm/dri1: Move Kconfig logic to drm/dri1 > drm: Move dri1 core files to drm/dri1 > > arch/powerpc/configs/pmac32_defconfig | 2 +- > arch/powerpc/configs/ppc6xx_defconfig | 2 +- > drivers/char/agp/Makefile | 2 +- > drivers/char/agp/agp.h | 2 +- > drivers/gpu/drm/Kconfig | 79 +--------------------- > drivers/gpu/drm/Makefile | 18 +++-- > drivers/gpu/drm/dri1/Kconfig | 79 ++++++++++++++++++++++ > drivers/gpu/drm/dri1/Makefile | 11 +++ > drivers/gpu/drm/{ => dri1}/drm_agpsupport.c | 4 +- > drivers/gpu/drm/{ => dri1}/drm_bufs.c | 22 +++--- > drivers/gpu/drm/{ => dri1}/drm_context.c | 24 +++---- > drivers/gpu/drm/{ => dri1}/drm_dma.c | 4 +- > drivers/gpu/drm/{ => dri1}/drm_hashtab.c | 0 > drivers/gpu/drm/{ => dri1}/drm_irq.c | 6 +- > drivers/gpu/drm/{ => dri1}/drm_legacy_misc.c | 2 +- > drivers/gpu/drm/{ => dri1}/drm_lock.c | 6 +- > drivers/gpu/drm/{ => dri1}/drm_memory.c | 0 > drivers/gpu/drm/{ => dri1}/drm_scatter.c | 6 +- > drivers/gpu/drm/{ => dri1}/drm_vm.c | 2 +- > drivers/gpu/drm/{ => dri1}/i810/Makefile | 0 > drivers/gpu/drm/{ => dri1}/i810/i810_dma.c | 0 > drivers/gpu/drm/{ => dri1}/i810/i810_drv.c | 2 +- > drivers/gpu/drm/{ => dri1}/i810/i810_drv.h | 0 > drivers/gpu/drm/{ => dri1}/mga/Makefile | 0 > drivers/gpu/drm/{ => dri1}/mga/mga_dma.c | 0 > drivers/gpu/drm/{ => dri1}/mga/mga_drv.c | 2 +- > drivers/gpu/drm/{ => dri1}/mga/mga_drv.h | 0 > drivers/gpu/drm/{ => dri1}/mga/mga_ioc32.c | 0 > drivers/gpu/drm/{ => dri1}/mga/mga_irq.c | 0 > drivers/gpu/drm/{ => dri1}/mga/mga_state.c | 0 > drivers/gpu/drm/{ => dri1}/mga/mga_warp.c | 0 > drivers/gpu/drm/{ => dri1}/r128/Makefile | 0 > drivers/gpu/drm/{ => dri1}/r128/ati_pcigart.c | 0 > drivers/gpu/drm/{ => dri1}/r128/ati_pcigart.h | 0 > drivers/gpu/drm/{ => dri1}/r128/r128_cce.c | 0 > drivers/gpu/drm/{ => dri1}/r128/r128_drv.c | 2 +- > drivers/gpu/drm/{ => dri1}/r128/r128_drv.h | 0 > drivers/gpu/drm/{ => dri1}/r128/r128_ioc32.c | 0 > drivers/gpu/drm/{ => dri1}/r128/r128_irq.c | 0 > drivers/gpu/drm/{ => dri1}/r128/r128_state.c | 0 > drivers/gpu/drm/{ => dri1}/savage/Makefile | 0 > drivers/gpu/drm/{ => dri1}/savage/savage_bci.c | 0 > drivers/gpu/drm/{ => dri1}/savage/savage_drv.c | 2 +- > drivers/gpu/drm/{ => dri1}/savage/savage_drv.h | 0 > drivers/gpu/drm/{ => dri1}/savage/savage_state.c | 0 > drivers/gpu/drm/{ => dri1}/sis/Makefile | 0 > drivers/gpu/drm/{ => dri1}/sis/sis_drv.c | 2 +- > drivers/gpu/drm/{ => dri1}/sis/sis_drv.h | 0 > drivers/gpu/drm/{ => dri1}/sis/sis_mm.c | 0 > drivers/gpu/drm/{ => dri1}/tdfx/Makefile | 0 > drivers/gpu/drm/{ => dri1}/tdfx/tdfx_drv.c | 2 +- > drivers/gpu/drm/{ => dri1}/tdfx/tdfx_drv.h | 0 > drivers/gpu/drm/{ => dri1}/via/Makefile | 4 +- > drivers/gpu/drm/{via/via_dri1.c => dri1/via/via.c} | 4 +- > drivers/gpu/drm/drm_drv.c | 2 +- > drivers/gpu/drm/drm_file.c | 12 ++-- > drivers/gpu/drm/drm_internal.h | 2 +- > drivers/gpu/drm/drm_ioc32.c | 12 ++-- > drivers/gpu/drm/drm_ioctl.c | 4 +- > drivers/gpu/drm/drm_legacy.h | 32 ++++----- > drivers/gpu/drm/drm_pci.c | 12 ++-- > drivers/gpu/drm/drm_vblank.c | 12 ++-- > include/drm/drm_auth.h | 2 +- > include/drm/drm_device.h | 4 +- > include/drm/drm_drv.h | 10 +-- > include/drm/drm_file.h | 2 +- > include/drm/drm_legacy.h | 2 +- > 67 files changed, 205 insertions(+), 194 deletions(-) > >
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
Hi Sam Am 18.07.22 um 09:56 schrieb Sam Ravnborg: > 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. Thanks a lot. Best regards Thomas > > Sam
Hello Thomas, On 7/18/22 08:56, 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 That could be avoided by moving drivers/gpu/drm/via/via_3d_reg.h and other header files to include/drm/via_3d_reg.h for example. Other drivers (i.e: i915) do the same for headers that are shared across different subsystems. > 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? I believe for these we could also move them to include/drm/ if needed. > Patches 1 and 2 look reasonable to me. The other driver patches have > basically zero upside IMHO. > I disagree with the zero upside. It may be that the trade offs are not worth it but there are upsides of having all DRI1 drivers and core DRI1 bits in the same place. It makes grep-ing and reading files easier if one doesn't care about legacy DRI1 drivers. Also, it would ease the removal of this if we ever get rid of them. > 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 Maybe this could be sorted by splitting the DRI1 core bits in a separate drm_dri1.ko module? > 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. > That would be an improvement but IMO moving them into a different dir as Sam did would be preferable. What would be the upside of having it in drivers/gpu/drm instead? Just to avoid the Makefile rule to have a dri1/ prefix in the included object files ? Regardless of this discussion, I think that at the very least we should rename the Kconfig symbols to CONFIG_DRM_DRI1_* even if DRI1 drivers are kept in drivers/gpu/drm/ instead of moved to a drivers/gpu/drm/dri1/ dir.
Hi Javier Am 18.07.22 um 11:46 schrieb Javier Martinez Canillas: > Hello Thomas, > > On 7/18/22 08:56, 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 > > That could be avoided by moving drivers/gpu/drm/via/via_3d_reg.h and other > header files to include/drm/via_3d_reg.h for example. Other drivers (i.e: > i915) do the same for headers that are shared across different subsystems. > >> 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? > > I believe for these we could also move them to include/drm/ if needed. That pollutes these shared directories at the expense of everyone else. If anything, we want to move files out of the shared include paths. It would make sense to me if we'd have two distinct drivers. But here, the new and the old driver is really just one DRM driver with badly organized source code. > >> Patches 1 and 2 look reasonable to me. The other driver patches have >> basically zero upside IMHO. >> > > I disagree with the zero upside. It may be that the trade offs are not > worth it but there are upsides of having all DRI1 drivers and core DRI1 > bits in the same place. It makes grep-ing and reading files easier if > one doesn't care about legacy DRI1 drivers. The grep-ability is a minor point. It does come up, but is usually sorted out easily. If we want to improve grep output, we should consider applying Sam's via_dri1 changes to all DRI1 drivers. So we'd end up with a single mga_dri1.c, tdfx_dri1.c, savage_dri1.c and so on. If the core/helper code is also in a _dri1-named source file, grep runs can filter out those filenames. > > Also, it would ease the removal of this if we ever get rid of them. We're not going to remove them all at once. And if we'd do, the actual work would be in removing the DRI1 code from the DRM core. There's code in the core that does runtime tests for DRIVER_LEGACY and is partially shared with KMS drivers (mostly in VBLANK handling IIRC). Removing the driver directories is trivial. > >> 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 > > Maybe this could be sorted by splitting the DRI1 core bits in a separate > drm_dri1.ko module? The dri1 core files cannot be in a separate module as they are linked with other core stuff. It would result in dependency cycles IIRC. > >> 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. >> > > That would be an improvement but IMO moving them into a different dir > as Sam did would be preferable. What would be the upside of having it > in drivers/gpu/drm instead? Just to avoid the Makefile rule to have a > dri1/ prefix in the included object files ? Makefile readability is important and our existing ones could be better, but that's a minor point. Putting everything into a single file gets the legacy code out of the way, benefits grepping and is faster to build. In the case of a core/helper split, it would further align with the overall design of the DRM sub-system. > > Regardless of this discussion, I think that at the very least we should > rename the Kconfig symbols to CONFIG_DRM_DRI1_* even if DRI1 drivers are > kept in drivers/gpu/drm/ instead of moved to a drivers/gpu/drm/dri1/ dir. > Agreed. Best regards Thomas
On 7/18/22 12:50, Thomas Zimmermann wrote: [...] >>> 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 >> >> That could be avoided by moving drivers/gpu/drm/via/via_3d_reg.h and other >> header files to include/drm/via_3d_reg.h for example. Other drivers (i.e: >> i915) do the same for headers that are shared across different subsystems. >> >>> 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? >> >> I believe for these we could also move them to include/drm/ if needed. > > That pollutes these shared directories at the expense of everyone else. > If anything, we want to move files out of the shared include paths. > Yes, every option has a different set of trade offs. > It would make sense to me if we'd have two distinct drivers. But here, > the new and the old driver is really just one DRM driver with badly > organized source code. > I see. I haven't looked at the via drivers in detail. >> >>> Patches 1 and 2 look reasonable to me. The other driver patches have >>> basically zero upside IMHO. >>> >> >> I disagree with the zero upside. It may be that the trade offs are not >> worth it but there are upsides of having all DRI1 drivers and core DRI1 >> bits in the same place. It makes grep-ing and reading files easier if >> one doesn't care about legacy DRI1 drivers. > > The grep-ability is a minor point. It does come up, but is usually > sorted out easily. > > If we want to improve grep output, we should consider applying Sam's > via_dri1 changes to all DRI1 drivers. So we'd end up with a single > mga_dri1.c, tdfx_dri1.c, savage_dri1.c and so on. If the core/helper > code is also in a _dri1-named source file, grep runs can filter out > those filenames. > Having everything with a _dri1 suffix would be an improvement I agree and if that's the consensus then I'm OK with that approach as well. [...] >> >>> 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 >> >> Maybe this could be sorted by splitting the DRI1 core bits in a separate >> drm_dri1.ko module? > > The dri1 core files cannot be in a separate module as they are linked > with other core stuff. It would result in dependency cycles IIRC. > Got it.
Hi Javier, Thomas, On Mon, Jul 18, 2022 at 02:18:13PM +0200, Javier Martinez Canillas wrote: > On 7/18/22 12:50, Thomas Zimmermann wrote: > > [...] > > >>> 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 > >> > >> That could be avoided by moving drivers/gpu/drm/via/via_3d_reg.h and other > >> header files to include/drm/via_3d_reg.h for example. Other drivers (i.e: > >> i915) do the same for headers that are shared across different subsystems. > >> > >>> 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? > >> > >> I believe for these we could also move them to include/drm/ if needed. > > > > That pollutes these shared directories at the expense of everyone else. > > If anything, we want to move files out of the shared include paths. > > > > Yes, every option has a different set of trade offs. > > > It would make sense to me if we'd have two distinct drivers. But here, > > the new and the old driver is really just one DRM driver with badly > > organized source code. > > > > I see. I haven't looked at the via drivers in detail. > > >> > >>> Patches 1 and 2 look reasonable to me. The other driver patches have > >>> basically zero upside IMHO. > >>> > >> > >> I disagree with the zero upside. It may be that the trade offs are not > >> worth it but there are upsides of having all DRI1 drivers and core DRI1 > >> bits in the same place. It makes grep-ing and reading files easier if > >> one doesn't care about legacy DRI1 drivers. > > > > The grep-ability is a minor point. It does come up, but is usually > > sorted out easily. > > > > If we want to improve grep output, we should consider applying Sam's > > via_dri1 changes to all DRI1 drivers. So we'd end up with a single > > mga_dri1.c, tdfx_dri1.c, savage_dri1.c and so on. If the core/helper > > code is also in a _dri1-named source file, grep runs can filter out > > those filenames. > > > > Having everything with a _dri1 suffix would be an improvement I agree > and if that's the consensus then I'm OK with that approach as well. > > [...] I will update the series with the following: - Drop drm/dri1/ - Keep the CONFIG_DRM_* change and keep the DRIVER_DRI1 change - All config options for DRI1 drivers will get a CONFIG_DRM_DRI1_* prefix - Convert at least some of the drivers to single file drivers named foo_dri1. - I may add SPDX for licenses when I am touching the files - I may try to concatenate all dri1 specific drm core files to drm_dri1. It is easy to do but I will take a look at the result before posting anything. When I have posted the above let's see what we all agree on. May take a couple of days before I get back to it. Sam
Hi Sam Am 19.07.22 um 09:55 schrieb Sam Ravnborg: > Hi Javier, Thomas, > > On Mon, Jul 18, 2022 at 02:18:13PM +0200, Javier Martinez Canillas wrote: >> On 7/18/22 12:50, Thomas Zimmermann wrote: >> >> [...] >> >>>>> 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 >>>> >>>> That could be avoided by moving drivers/gpu/drm/via/via_3d_reg.h and other >>>> header files to include/drm/via_3d_reg.h for example. Other drivers (i.e: >>>> i915) do the same for headers that are shared across different subsystems. >>>> >>>>> 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? >>>> >>>> I believe for these we could also move them to include/drm/ if needed. >>> >>> That pollutes these shared directories at the expense of everyone else. >>> If anything, we want to move files out of the shared include paths. >>> >> >> Yes, every option has a different set of trade offs. >> >>> It would make sense to me if we'd have two distinct drivers. But here, >>> the new and the old driver is really just one DRM driver with badly >>> organized source code. >>> >> >> I see. I haven't looked at the via drivers in detail. >> >>>> >>>>> Patches 1 and 2 look reasonable to me. The other driver patches have >>>>> basically zero upside IMHO. >>>>> >>>> >>>> I disagree with the zero upside. It may be that the trade offs are not >>>> worth it but there are upsides of having all DRI1 drivers and core DRI1 >>>> bits in the same place. It makes grep-ing and reading files easier if >>>> one doesn't care about legacy DRI1 drivers. >>> >>> The grep-ability is a minor point. It does come up, but is usually >>> sorted out easily. >>> >>> If we want to improve grep output, we should consider applying Sam's >>> via_dri1 changes to all DRI1 drivers. So we'd end up with a single >>> mga_dri1.c, tdfx_dri1.c, savage_dri1.c and so on. If the core/helper >>> code is also in a _dri1-named source file, grep runs can filter out >>> those filenames. >>> >> >> Having everything with a _dri1 suffix would be an improvement I agree >> and if that's the consensus then I'm OK with that approach as well. >> >> [...] > > I will update the series with the following: > - Drop drm/dri1/ > - Keep the CONFIG_DRM_* change and keep the DRIVER_DRI1 change > - All config options for DRI1 drivers will get a CONFIG_DRM_DRI1_* > prefix > - Convert at least some of the drivers to single file drivers named > foo_dri1. > - I may add SPDX for licenses when I am touching the files > - I may try to concatenate all dri1 specific drm core files to drm_dri1. > It is easy to do but I will take a look at the result before posting > anything. > > When I have posted the above let's see what we all agree on. > May take a couple of days before I get back to it. Sounds like a plan to me. Best regards Thomas > > Sam
On 7/19/22 10:05, Thomas Zimmermann wrote: >>> [...] >> >> I will update the series with the following: >> - Drop drm/dri1/ >> - Keep the CONFIG_DRM_* change and keep the DRIVER_DRI1 change >> - All config options for DRI1 drivers will get a CONFIG_DRM_DRI1_* >> prefix >> - Convert at least some of the drivers to single file drivers named >> foo_dri1. >> - I may add SPDX for licenses when I am touching the files >> - I may try to concatenate all dri1 specific drm core files to drm_dri1. >> It is easy to do but I will take a look at the result before posting >> anything. >> >> When I have posted the above let's see what we all agree on. >> May take a couple of days before I get back to it. > > Sounds like a plan to me. > Sounds good to me as well.
On Mon, 18 Jul 2022 at 08:56, Thomas Zimmermann <tzimmermann@suse.de> 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. Imo transitional drivers with both legacy dri1 and kms+gem support made some sense 10+ years ago when all this infrastructure was still being built. Now I really don't see much point. For via imo make it a clean new driver, and copypaste anything from the old one (like register headers) it needs. That will also make review a ton easier I think. There has not been any actual via work, just general refactoring, in that driver for 10+ years, so "bugfix sharing" is really not an argument. > 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. Ugly Makefile for dri1 might be a feature :-) But personally no stake on this bikeshed. -Daniel > > Best regards > Thomsa > > > > > Sam > > > > Sam Ravnborg (11): > > drm: rename DRIVER_LEGACY to DRIVER_DRI1 > > drm: Rename CONFIG_DRM_LEGACY to CONFIG_DRM_DRI1 > > drm/tdfx: Move the tdfx driver to drm/dri1/ > > drm/r128: Move the r128 driver to drm/dri1/ > > drm/i810: Move the i810 driver to drm/dri1/ > > drm/mga: Move the mga driver to drm/dri1/ > > drm/sis: Move the sis driver to drm/dri1/ > > drm/via: Move the via driver to drm/dri1/ > > drm/savage: Move the savage driver to drm/dri1/ > > drm/dri1: Move Kconfig logic to drm/dri1 > > drm: Move dri1 core files to drm/dri1 > > > > arch/powerpc/configs/pmac32_defconfig | 2 +- > > arch/powerpc/configs/ppc6xx_defconfig | 2 +- > > drivers/char/agp/Makefile | 2 +- > > drivers/char/agp/agp.h | 2 +- > > drivers/gpu/drm/Kconfig | 79 +--------------------- > > drivers/gpu/drm/Makefile | 18 +++-- > > drivers/gpu/drm/dri1/Kconfig | 79 ++++++++++++++++++++++ > > drivers/gpu/drm/dri1/Makefile | 11 +++ > > drivers/gpu/drm/{ => dri1}/drm_agpsupport.c | 4 +- > > drivers/gpu/drm/{ => dri1}/drm_bufs.c | 22 +++--- > > drivers/gpu/drm/{ => dri1}/drm_context.c | 24 +++---- > > drivers/gpu/drm/{ => dri1}/drm_dma.c | 4 +- > > drivers/gpu/drm/{ => dri1}/drm_hashtab.c | 0 > > drivers/gpu/drm/{ => dri1}/drm_irq.c | 6 +- > > drivers/gpu/drm/{ => dri1}/drm_legacy_misc.c | 2 +- > > drivers/gpu/drm/{ => dri1}/drm_lock.c | 6 +- > > drivers/gpu/drm/{ => dri1}/drm_memory.c | 0 > > drivers/gpu/drm/{ => dri1}/drm_scatter.c | 6 +- > > drivers/gpu/drm/{ => dri1}/drm_vm.c | 2 +- > > drivers/gpu/drm/{ => dri1}/i810/Makefile | 0 > > drivers/gpu/drm/{ => dri1}/i810/i810_dma.c | 0 > > drivers/gpu/drm/{ => dri1}/i810/i810_drv.c | 2 +- > > drivers/gpu/drm/{ => dri1}/i810/i810_drv.h | 0 > > drivers/gpu/drm/{ => dri1}/mga/Makefile | 0 > > drivers/gpu/drm/{ => dri1}/mga/mga_dma.c | 0 > > drivers/gpu/drm/{ => dri1}/mga/mga_drv.c | 2 +- > > drivers/gpu/drm/{ => dri1}/mga/mga_drv.h | 0 > > drivers/gpu/drm/{ => dri1}/mga/mga_ioc32.c | 0 > > drivers/gpu/drm/{ => dri1}/mga/mga_irq.c | 0 > > drivers/gpu/drm/{ => dri1}/mga/mga_state.c | 0 > > drivers/gpu/drm/{ => dri1}/mga/mga_warp.c | 0 > > drivers/gpu/drm/{ => dri1}/r128/Makefile | 0 > > drivers/gpu/drm/{ => dri1}/r128/ati_pcigart.c | 0 > > drivers/gpu/drm/{ => dri1}/r128/ati_pcigart.h | 0 > > drivers/gpu/drm/{ => dri1}/r128/r128_cce.c | 0 > > drivers/gpu/drm/{ => dri1}/r128/r128_drv.c | 2 +- > > drivers/gpu/drm/{ => dri1}/r128/r128_drv.h | 0 > > drivers/gpu/drm/{ => dri1}/r128/r128_ioc32.c | 0 > > drivers/gpu/drm/{ => dri1}/r128/r128_irq.c | 0 > > drivers/gpu/drm/{ => dri1}/r128/r128_state.c | 0 > > drivers/gpu/drm/{ => dri1}/savage/Makefile | 0 > > drivers/gpu/drm/{ => dri1}/savage/savage_bci.c | 0 > > drivers/gpu/drm/{ => dri1}/savage/savage_drv.c | 2 +- > > drivers/gpu/drm/{ => dri1}/savage/savage_drv.h | 0 > > drivers/gpu/drm/{ => dri1}/savage/savage_state.c | 0 > > drivers/gpu/drm/{ => dri1}/sis/Makefile | 0 > > drivers/gpu/drm/{ => dri1}/sis/sis_drv.c | 2 +- > > drivers/gpu/drm/{ => dri1}/sis/sis_drv.h | 0 > > drivers/gpu/drm/{ => dri1}/sis/sis_mm.c | 0 > > drivers/gpu/drm/{ => dri1}/tdfx/Makefile | 0 > > drivers/gpu/drm/{ => dri1}/tdfx/tdfx_drv.c | 2 +- > > drivers/gpu/drm/{ => dri1}/tdfx/tdfx_drv.h | 0 > > drivers/gpu/drm/{ => dri1}/via/Makefile | 4 +- > > drivers/gpu/drm/{via/via_dri1.c => dri1/via/via.c} | 4 +- > > drivers/gpu/drm/drm_drv.c | 2 +- > > drivers/gpu/drm/drm_file.c | 12 ++-- > > drivers/gpu/drm/drm_internal.h | 2 +- > > drivers/gpu/drm/drm_ioc32.c | 12 ++-- > > drivers/gpu/drm/drm_ioctl.c | 4 +- > > drivers/gpu/drm/drm_legacy.h | 32 ++++----- > > drivers/gpu/drm/drm_pci.c | 12 ++-- > > drivers/gpu/drm/drm_vblank.c | 12 ++-- > > include/drm/drm_auth.h | 2 +- > > include/drm/drm_device.h | 4 +- > > include/drm/drm_drv.h | 10 +-- > > include/drm/drm_file.h | 2 +- > > include/drm/drm_legacy.h | 2 +- > > 67 files changed, 205 insertions(+), 194 deletions(-) > > > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Ivo Totev
Hi Am 19.07.22 um 11:52 schrieb Daniel Vetter: > On Mon, 18 Jul 2022 at 08:56, Thomas Zimmermann <tzimmermann@suse.de> 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. > > Imo transitional drivers with both legacy dri1 and kms+gem support > made some sense 10+ years ago when all this infrastructure was still > being built. Now I really don't see much point. > > For via imo make it a clean new driver, and copypaste anything from > the old one (like register headers) it needs. That will also make > review a ton easier I think. There has not been any actual via work, > just general refactoring, in that driver for 10+ years, so "bugfix > sharing" is really not an argument. At some point, I suggested to turn the VIA KMS driver into a new 'unichrome' driver, but everyone wants to keep 'via' instead. > >> 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. > > Ugly Makefile for dri1 might be a feature :-) But personally no stake > on this bikeshed. It's the core DRM makefile that would look ugly. :/ Best regards Thomas > -Daniel > >> >> Best regards >> Thomsa >> >>> >>> Sam >>> >>> Sam Ravnborg (11): >>> drm: rename DRIVER_LEGACY to DRIVER_DRI1 >>> drm: Rename CONFIG_DRM_LEGACY to CONFIG_DRM_DRI1 >>> drm/tdfx: Move the tdfx driver to drm/dri1/ >>> drm/r128: Move the r128 driver to drm/dri1/ >>> drm/i810: Move the i810 driver to drm/dri1/ >>> drm/mga: Move the mga driver to drm/dri1/ >>> drm/sis: Move the sis driver to drm/dri1/ >>> drm/via: Move the via driver to drm/dri1/ >>> drm/savage: Move the savage driver to drm/dri1/ >>> drm/dri1: Move Kconfig logic to drm/dri1 >>> drm: Move dri1 core files to drm/dri1 >>> >>> arch/powerpc/configs/pmac32_defconfig | 2 +- >>> arch/powerpc/configs/ppc6xx_defconfig | 2 +- >>> drivers/char/agp/Makefile | 2 +- >>> drivers/char/agp/agp.h | 2 +- >>> drivers/gpu/drm/Kconfig | 79 +--------------------- >>> drivers/gpu/drm/Makefile | 18 +++-- >>> drivers/gpu/drm/dri1/Kconfig | 79 ++++++++++++++++++++++ >>> drivers/gpu/drm/dri1/Makefile | 11 +++ >>> drivers/gpu/drm/{ => dri1}/drm_agpsupport.c | 4 +- >>> drivers/gpu/drm/{ => dri1}/drm_bufs.c | 22 +++--- >>> drivers/gpu/drm/{ => dri1}/drm_context.c | 24 +++---- >>> drivers/gpu/drm/{ => dri1}/drm_dma.c | 4 +- >>> drivers/gpu/drm/{ => dri1}/drm_hashtab.c | 0 >>> drivers/gpu/drm/{ => dri1}/drm_irq.c | 6 +- >>> drivers/gpu/drm/{ => dri1}/drm_legacy_misc.c | 2 +- >>> drivers/gpu/drm/{ => dri1}/drm_lock.c | 6 +- >>> drivers/gpu/drm/{ => dri1}/drm_memory.c | 0 >>> drivers/gpu/drm/{ => dri1}/drm_scatter.c | 6 +- >>> drivers/gpu/drm/{ => dri1}/drm_vm.c | 2 +- >>> drivers/gpu/drm/{ => dri1}/i810/Makefile | 0 >>> drivers/gpu/drm/{ => dri1}/i810/i810_dma.c | 0 >>> drivers/gpu/drm/{ => dri1}/i810/i810_drv.c | 2 +- >>> drivers/gpu/drm/{ => dri1}/i810/i810_drv.h | 0 >>> drivers/gpu/drm/{ => dri1}/mga/Makefile | 0 >>> drivers/gpu/drm/{ => dri1}/mga/mga_dma.c | 0 >>> drivers/gpu/drm/{ => dri1}/mga/mga_drv.c | 2 +- >>> drivers/gpu/drm/{ => dri1}/mga/mga_drv.h | 0 >>> drivers/gpu/drm/{ => dri1}/mga/mga_ioc32.c | 0 >>> drivers/gpu/drm/{ => dri1}/mga/mga_irq.c | 0 >>> drivers/gpu/drm/{ => dri1}/mga/mga_state.c | 0 >>> drivers/gpu/drm/{ => dri1}/mga/mga_warp.c | 0 >>> drivers/gpu/drm/{ => dri1}/r128/Makefile | 0 >>> drivers/gpu/drm/{ => dri1}/r128/ati_pcigart.c | 0 >>> drivers/gpu/drm/{ => dri1}/r128/ati_pcigart.h | 0 >>> drivers/gpu/drm/{ => dri1}/r128/r128_cce.c | 0 >>> drivers/gpu/drm/{ => dri1}/r128/r128_drv.c | 2 +- >>> drivers/gpu/drm/{ => dri1}/r128/r128_drv.h | 0 >>> drivers/gpu/drm/{ => dri1}/r128/r128_ioc32.c | 0 >>> drivers/gpu/drm/{ => dri1}/r128/r128_irq.c | 0 >>> drivers/gpu/drm/{ => dri1}/r128/r128_state.c | 0 >>> drivers/gpu/drm/{ => dri1}/savage/Makefile | 0 >>> drivers/gpu/drm/{ => dri1}/savage/savage_bci.c | 0 >>> drivers/gpu/drm/{ => dri1}/savage/savage_drv.c | 2 +- >>> drivers/gpu/drm/{ => dri1}/savage/savage_drv.h | 0 >>> drivers/gpu/drm/{ => dri1}/savage/savage_state.c | 0 >>> drivers/gpu/drm/{ => dri1}/sis/Makefile | 0 >>> drivers/gpu/drm/{ => dri1}/sis/sis_drv.c | 2 +- >>> drivers/gpu/drm/{ => dri1}/sis/sis_drv.h | 0 >>> drivers/gpu/drm/{ => dri1}/sis/sis_mm.c | 0 >>> drivers/gpu/drm/{ => dri1}/tdfx/Makefile | 0 >>> drivers/gpu/drm/{ => dri1}/tdfx/tdfx_drv.c | 2 +- >>> drivers/gpu/drm/{ => dri1}/tdfx/tdfx_drv.h | 0 >>> drivers/gpu/drm/{ => dri1}/via/Makefile | 4 +- >>> drivers/gpu/drm/{via/via_dri1.c => dri1/via/via.c} | 4 +- >>> drivers/gpu/drm/drm_drv.c | 2 +- >>> drivers/gpu/drm/drm_file.c | 12 ++-- >>> drivers/gpu/drm/drm_internal.h | 2 +- >>> drivers/gpu/drm/drm_ioc32.c | 12 ++-- >>> drivers/gpu/drm/drm_ioctl.c | 4 +- >>> drivers/gpu/drm/drm_legacy.h | 32 ++++----- >>> drivers/gpu/drm/drm_pci.c | 12 ++-- >>> drivers/gpu/drm/drm_vblank.c | 12 ++-- >>> include/drm/drm_auth.h | 2 +- >>> include/drm/drm_device.h | 4 +- >>> include/drm/drm_drv.h | 10 +-- >>> include/drm/drm_file.h | 2 +- >>> include/drm/drm_legacy.h | 2 +- >>> 67 files changed, 205 insertions(+), 194 deletions(-) >>> >>> >> >> -- >> Thomas Zimmermann >> Graphics Driver Developer >> SUSE Software Solutions Germany GmbH >> Maxfeldstr. 5, 90409 Nürnberg, Germany >> (HRB 36809, AG Nürnberg) >> Geschäftsführer: Ivo Totev > > >
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! Sam Sam Ravnborg (11): drm: rename DRIVER_LEGACY to DRIVER_DRI1 drm: Rename CONFIG_DRM_LEGACY to CONFIG_DRM_DRI1 drm/tdfx: Move the tdfx driver to drm/dri1/ drm/r128: Move the r128 driver to drm/dri1/ drm/i810: Move the i810 driver to drm/dri1/ drm/mga: Move the mga driver to drm/dri1/ drm/sis: Move the sis driver to drm/dri1/ drm/via: Move the via driver to drm/dri1/ drm/savage: Move the savage driver to drm/dri1/ drm/dri1: Move Kconfig logic to drm/dri1 drm: Move dri1 core files to drm/dri1 arch/powerpc/configs/pmac32_defconfig | 2 +- arch/powerpc/configs/ppc6xx_defconfig | 2 +- drivers/char/agp/Makefile | 2 +- drivers/char/agp/agp.h | 2 +- drivers/gpu/drm/Kconfig | 79 +--------------------- drivers/gpu/drm/Makefile | 18 +++-- drivers/gpu/drm/dri1/Kconfig | 79 ++++++++++++++++++++++ drivers/gpu/drm/dri1/Makefile | 11 +++ drivers/gpu/drm/{ => dri1}/drm_agpsupport.c | 4 +- drivers/gpu/drm/{ => dri1}/drm_bufs.c | 22 +++--- drivers/gpu/drm/{ => dri1}/drm_context.c | 24 +++---- drivers/gpu/drm/{ => dri1}/drm_dma.c | 4 +- drivers/gpu/drm/{ => dri1}/drm_hashtab.c | 0 drivers/gpu/drm/{ => dri1}/drm_irq.c | 6 +- drivers/gpu/drm/{ => dri1}/drm_legacy_misc.c | 2 +- drivers/gpu/drm/{ => dri1}/drm_lock.c | 6 +- drivers/gpu/drm/{ => dri1}/drm_memory.c | 0 drivers/gpu/drm/{ => dri1}/drm_scatter.c | 6 +- drivers/gpu/drm/{ => dri1}/drm_vm.c | 2 +- drivers/gpu/drm/{ => dri1}/i810/Makefile | 0 drivers/gpu/drm/{ => dri1}/i810/i810_dma.c | 0 drivers/gpu/drm/{ => dri1}/i810/i810_drv.c | 2 +- drivers/gpu/drm/{ => dri1}/i810/i810_drv.h | 0 drivers/gpu/drm/{ => dri1}/mga/Makefile | 0 drivers/gpu/drm/{ => dri1}/mga/mga_dma.c | 0 drivers/gpu/drm/{ => dri1}/mga/mga_drv.c | 2 +- drivers/gpu/drm/{ => dri1}/mga/mga_drv.h | 0 drivers/gpu/drm/{ => dri1}/mga/mga_ioc32.c | 0 drivers/gpu/drm/{ => dri1}/mga/mga_irq.c | 0 drivers/gpu/drm/{ => dri1}/mga/mga_state.c | 0 drivers/gpu/drm/{ => dri1}/mga/mga_warp.c | 0 drivers/gpu/drm/{ => dri1}/r128/Makefile | 0 drivers/gpu/drm/{ => dri1}/r128/ati_pcigart.c | 0 drivers/gpu/drm/{ => dri1}/r128/ati_pcigart.h | 0 drivers/gpu/drm/{ => dri1}/r128/r128_cce.c | 0 drivers/gpu/drm/{ => dri1}/r128/r128_drv.c | 2 +- drivers/gpu/drm/{ => dri1}/r128/r128_drv.h | 0 drivers/gpu/drm/{ => dri1}/r128/r128_ioc32.c | 0 drivers/gpu/drm/{ => dri1}/r128/r128_irq.c | 0 drivers/gpu/drm/{ => dri1}/r128/r128_state.c | 0 drivers/gpu/drm/{ => dri1}/savage/Makefile | 0 drivers/gpu/drm/{ => dri1}/savage/savage_bci.c | 0 drivers/gpu/drm/{ => dri1}/savage/savage_drv.c | 2 +- drivers/gpu/drm/{ => dri1}/savage/savage_drv.h | 0 drivers/gpu/drm/{ => dri1}/savage/savage_state.c | 0 drivers/gpu/drm/{ => dri1}/sis/Makefile | 0 drivers/gpu/drm/{ => dri1}/sis/sis_drv.c | 2 +- drivers/gpu/drm/{ => dri1}/sis/sis_drv.h | 0 drivers/gpu/drm/{ => dri1}/sis/sis_mm.c | 0 drivers/gpu/drm/{ => dri1}/tdfx/Makefile | 0 drivers/gpu/drm/{ => dri1}/tdfx/tdfx_drv.c | 2 +- drivers/gpu/drm/{ => dri1}/tdfx/tdfx_drv.h | 0 drivers/gpu/drm/{ => dri1}/via/Makefile | 4 +- drivers/gpu/drm/{via/via_dri1.c => dri1/via/via.c} | 4 +- drivers/gpu/drm/drm_drv.c | 2 +- drivers/gpu/drm/drm_file.c | 12 ++-- drivers/gpu/drm/drm_internal.h | 2 +- drivers/gpu/drm/drm_ioc32.c | 12 ++-- drivers/gpu/drm/drm_ioctl.c | 4 +- drivers/gpu/drm/drm_legacy.h | 32 ++++----- drivers/gpu/drm/drm_pci.c | 12 ++-- drivers/gpu/drm/drm_vblank.c | 12 ++-- include/drm/drm_auth.h | 2 +- include/drm/drm_device.h | 4 +- include/drm/drm_drv.h | 10 +-- include/drm/drm_file.h | 2 +- include/drm/drm_legacy.h | 2 +- 67 files changed, 205 insertions(+), 194 deletions(-)