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

From: Thomas Zimmermann <tzimmermann@suse.de>
To: Javier Martinez Canillas <javierm@redhat.com>,
	Sam Ravnborg <sam@ravnborg.org>
Cc: Kevin Brace <kevinbrace@bracecomputerlab.com>,
	dri-devel@lists.freedesktop.org, Kevin Brace <kevinbrace@gmx.com>
Subject: Re: [PATCH 00/28] OpenChrome DRM for Linux 5.20
Date: Thu, 30 Jun 2022 10:33:52 +0200	[thread overview]
Message-ID: <f64fc02f-f82f-17f8-a669-61c9d9b4e869@suse.de> (raw)
In-Reply-To: <dae59187-a055-2699-bee1-c066b69627b0@suse.de>

[-- Attachment #1.1: Type: text/plain, Size: 3542 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]