[PATCH 00/28] OpenChrome DRM for Linux 5.20

Thomas Zimmermann tzimmermann at suse.de
Thu Jun 30 08:19:13 UTC 2022


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

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20220630/a645d1f2/attachment-0001.sig>


More information about the dri-devel mailing list