Re: [PATCH 00/28] OpenChrome DRM for Linux 5.20

[Thomas Zimmermann <tzimmermann@xxxxxxx>]

Hi

Am 30.06.22 um 10:19 schrieb Thomas Zimmermann:
> Hi
>
> Am 30.06.22 um 10:07 schrieb Javier Martinez Canillas:
> > Hello,
> >
> > On 6/28/22 14:21, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 27.06.22 um 23:32 schrieb Sam Ravnborg:
> > > > Hi Kevin/Thomas,
> > > >
> > > > > I had a brief look over the patches. Even though the code looks 
> > > > > fairly rough
> > > > > in places, I think we should get this driver merged ASAP.
> > > >
> > > > Agreed, we have a had a few cases where we dragged out committing much
> > > > too long time.
> > > >
> > > > Timing wise, it would be good if we can already hit drm-misc-next right
> > > > _after_ the pull -so we have a full cycle to fix anything before it 
> > > > hits
> > > > mainline.
> > > >
> > > > > For the old via driver, I think we need a better apprach. IMHO it 
> > > > > would be
> > > > > preferable to put the new driver into via/ but keep the old driver 
> > > > > there as
> > > > > well.  A build option would control which is being used.
> > > >
> > > > I assume the user base for via drivers are very small and they have the
> > > > fbdev driver already.
> > > > So I support replacing the current via drm driver as Kevin tries to do.
> > >
> > > I don't know if there are still users of the old userspace, but if so I
> > > would consider this removal a regression. I think the old code supports
> > > 3d and video decoding. Depending on the feature set, 3d support might
> > > not be useful any longer, but video decoding probably is.  (I might be
> > > wrong about all this.) IMHO we should not simply remove this at least
> > > until we can verify that it's no longer useful to anyone.
> >
> > I strongly agree with Thomas on this.
> > > However, legacy support is trivial. Kevin, please see the attached files
> > > for two cleanup patches. You're welcome to add them to the start of your
> > > patchset to get the legacy code out of the way.
> >
> > I'm not sure about this approach, I think that having completely 
> > separated
> > drivers would be better to maintain in the long run since it's likely 
> > that
> > the legacy VIA driver will only get bug fixes (if any) and could be 
> > removed
> > once the new modsetting driver has feature parity, the legacy can be 
> > dropped.
> > Maybe an alternative could be to add a drivers/gpu/drm/legacy 
> > directory and
> > move all the legacy DRM drivers there ? And the Kconfig symbol could 
> > be i.e:
> > CONFIG_DRM_LEGACY_VIA and same for the others legacy DRM drivers.
> >
> > And the directory could only be sourced from Kconfig when 
> > CONFIG_DRM_LEGACY
> > is enabled and make it default to n. If in a few of releases nobody 
> > complains
> > then the whole directory could be removed.

To add another comment here, if we do this then let's please not call it 
legacy.  We also have non-atomic modesetting, non-atomic color mgmt, 
non-universal planes, etc. All that is also legacy in some way.

If we're going to rename and move the old drivers, let's call it 
consistently CONFIG_DRI1 and dri1/.

Best regard
Thomas

> >
>
> That seems a lot of work for simply removing something. And I'm sure 
> that people will only complain after legacy/via got removed.
>
> If we want to separate code for the old and new VIA driver, let's put 
> the new code into  unichrome/ and be done with it.
>
> Best regards
> Thomas

--
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

Attachment: OpenPGP_signature
Description: OpenPGP digital signature