dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Zimmermann <tzimmermann@suse.de>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>,
	"Christian König" <christian.koenig@amd.com>,
	alexander.deucher@amd.com, Xinhui.Pan@amd.com, airlied@gmail.com,
	daniel@ffwll.ch, javierm@redhat.com
Cc: dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 00/10] drm/radeon: Convert fbdev to DRM client
Date: Mon, 20 Mar 2023 16:19:23 +0100	[thread overview]
Message-ID: <1b85517d-1847-a779-2a13-b7cb5c7a592b@suse.de> (raw)
In-Reply-To: <8cc926f5-ccee-b5ea-b217-297829051a7f@gmail.com>


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

Hi

Am 20.03.23 um 16:11 schrieb Christian König:
> Am 17.03.23 um 10:20 schrieb Thomas Zimmermann:
>> Hi Christian
>>
>> Am 17.03.23 um 09:53 schrieb Christian König:
>>> Am 16.03.23 um 10:37 schrieb Thomas Zimmermann:
>>>> Convert radeon's fbdev code to drm_client. Replaces the current
>>>> ad-hoc integration. The conversion includes a number of cleanups.
>>>> Only build fbdev support if the config option has been set.
>>>
>>> I'm torn apart on that. On the one hand it looks like a really nice 
>>> cleanup on the other hand we don't really want to touch radeon any more.
>>
>> It's a driver in the upstream kernel. You have to expect at least some 
>> changes.
> 
> Some changes is not the problem, but we need a justification to change 
> something. Just that it's nice to have won't do it without extensive 
> testing.
> 
>>
>>>
>>> Alex what do you think? Is that worth the risk of breaking stuff?
>>
>> Moving all fbdev emulation to struct drm_client is required for new 
>> in-kernel DRM clients, such as a DRM kernel logger or a boot splash.
> 
> Well that's a rather good justification. I suggest to add that to the 
> cover-letter.

Ok, will go into a possible v2. The mid-term plan is to convert the 
fbdev code in all remaining drivers to struct drm_client and remove the 
old ad-hoc callbacks.

With struct drm_client, we can select in-kernel clients at compile time 
or runtime just like userspace clients. I guess, we can have a bootup 
screen and then switch to the console or the DRM logger. Or go from any 
client to the logger on kernel panics (or something like that). There's 
been occasional talk about userspace consoles, which would use such 
functionality.

Best regards
Thomas

> 
> Regards,
> Christian.
> 
>>
>> Best regards
>> Thomas
>>
>>>
>>> Christian.
>>>
>>>>
>>>> Thomas Zimmermann (10):
>>>>    drm/radeon: Move radeon_align_pitch() next to dumb-buffer helpers
>>>>    drm/radeon: Improve fbdev object-test helper
>>>>    drm/radeon: Remove struct radeon_fbdev
>>>>    drm/radeon: Remove test for !screen_base in fbdev probing
>>>>    drm/radeon: Move fbdev object helpers before struct fb_ops et al
>>>>    drm/radeon: Fix coding style in fbdev emulation
>>>>    drm/radeon: Move fbdev cleanup code into fb_destroy callback
>>>>    drm/radeon: Correctly clean up failed display probing
>>>>    drm/radeon: Implement client-based fbdev emulation
>>>>    drm/radeon: Only build fbdev if DRM_FBDEV_EMULATION is set
>>>>
>>>>   drivers/gpu/drm/radeon/Makefile         |   3 +-
>>>>   drivers/gpu/drm/radeon/radeon.h         |   2 +
>>>>   drivers/gpu/drm/radeon/radeon_display.c |   4 -
>>>>   drivers/gpu/drm/radeon/radeon_drv.c     |   3 +-
>>>>   drivers/gpu/drm/radeon/radeon_drv.h     |   1 -
>>>>   drivers/gpu/drm/radeon/radeon_fb.c      | 400 ----------------------
>>>>   drivers/gpu/drm/radeon/radeon_fbdev.c   | 422 
>>>> ++++++++++++++++++++++++
>>>>   drivers/gpu/drm/radeon/radeon_gem.c     |  24 ++
>>>>   drivers/gpu/drm/radeon/radeon_kms.c     |  18 -
>>>>   drivers/gpu/drm/radeon/radeon_mode.h    |  20 +-
>>>>   10 files changed, 464 insertions(+), 433 deletions(-)
>>>>   delete mode 100644 drivers/gpu/drm/radeon/radeon_fb.c
>>>>   create mode 100644 drivers/gpu/drm/radeon/radeon_fbdev.c
>>>>
>>>>
>>>> base-commit: ec0708e846b819c8d5b642de42448a87d7526564
>>>
>>
> 

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

  reply	other threads:[~2023-03-20 15:19 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-16  9:37 [PATCH 00/10] drm/radeon: Convert fbdev to DRM client Thomas Zimmermann
2023-03-16  9:37 ` [PATCH 01/10] drm/radeon: Move radeon_align_pitch() next to dumb-buffer helpers Thomas Zimmermann
2023-03-16  9:37 ` [PATCH 02/10] drm/radeon: Improve fbdev object-test helper Thomas Zimmermann
2023-03-16  9:37 ` [PATCH 03/10] drm/radeon: Remove struct radeon_fbdev Thomas Zimmermann
2023-03-16  9:37 ` [PATCH 04/10] drm/radeon: Remove test for !screen_base in fbdev probing Thomas Zimmermann
2023-03-16  9:37 ` [PATCH 05/10] drm/radeon: Move fbdev object helpers before struct fb_ops et al Thomas Zimmermann
2023-03-16  9:37 ` [PATCH 06/10] drm/radeon: Fix coding style in fbdev emulation Thomas Zimmermann
2023-03-16  9:37 ` [PATCH 07/10] drm/radeon: Move fbdev cleanup code into fb_destroy callback Thomas Zimmermann
2023-03-16  9:37 ` [PATCH 08/10] drm/radeon: Correctly clean up failed display probing Thomas Zimmermann
2023-03-16  9:37 ` [PATCH 09/10] drm/radeon: Implement client-based fbdev emulation Thomas Zimmermann
2023-03-16  9:37 ` [PATCH 10/10] drm/radeon: Only build fbdev if DRM_FBDEV_EMULATION is set Thomas Zimmermann
2023-03-17  8:53 ` [PATCH 00/10] drm/radeon: Convert fbdev to DRM client Christian König
2023-03-17  9:20   ` Thomas Zimmermann
2023-03-20 15:11     ` Christian König
2023-03-20 15:19       ` Thomas Zimmermann [this message]
2023-03-20 15:23         ` Alex Deucher
2023-03-21  9:33           ` Thomas Zimmermann
2023-03-24 21:44             ` Alex Deucher
2023-03-27 22:39               ` Alex Deucher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1b85517d-1847-a779-2a13-b7cb5c7a592b@suse.de \
    --to=tzimmermann@suse.de \
    --cc=Xinhui.Pan@amd.com \
    --cc=airlied@gmail.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=ckoenig.leichtzumerken@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=javierm@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).