From: Thomas Zimmermann <tzimmermann@suse.de>
To: Javier Martinez Canillas <javierm@redhat.com>,
daniel@ffwll.ch, airlied@linux.ie, mripard@kernel.org,
maarten.lankhorst@linux.intel.com, deller@gmx.de
Cc: dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org
Subject: Re: [PATCH 6/9] drm/fb-helper: Provide callback to create fbdev dumb buffers
Date: Wed, 9 Mar 2022 09:42:42 +0100 [thread overview]
Message-ID: <1ec9bf07-798a-2bfa-a61b-b98fe9066df1@suse.de> (raw)
In-Reply-To: <4d489fba-917f-4212-0528-0295e86c4c4a@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 4100 bytes --]
Hi
Am 08.03.22 um 18:51 schrieb Javier Martinez Canillas:
> On 3/3/22 21:58, Thomas Zimmermann wrote:
>> Provide struct drm_driver.dumb_create_fbdev, a callback hook for
>> fbdev dumb buffers. Wire up fbdev and client helpers to use the new
>> interface, if present.
>>
>> This acknowledges the fact that fbdev buffers are different. The most
>> significant difference to regular GEM BOs is in mmap semantics. Fbdev
>> userspace treats the pages as video memory, which makes it impossible
>> to ever move the mmap'ed buffer. Hence, drivers ussually have to pin
>> the BO permanently or install an intermediate shadow buffer for mmap.
>>
>> So far, fbdev memory came from dumb buffers and DRM drivers had no
>> means of detecting this without reimplementing a good part of the fbdev
>> code. With the new callback, drivers can perma-pin fbdev buffer objects
>> if needed.
>>
>> Several drivers also require damage handling, which fbdev implements
>> with its deferred I/O helpers. The new callback allows a driver's memory
>> manager to set up a suitable mmap.
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> ---
>> drivers/gpu/drm/drm_client.c | 14 +++++++----
>> drivers/gpu/drm/drm_crtc_internal.h | 3 +++
>> drivers/gpu/drm/drm_dumb_buffers.c | 36 +++++++++++++++++++++++++----
>> drivers/gpu/drm/drm_fb_helper.c | 26 +++++++++++++++++----
>> include/drm/drm_client.h | 3 ++-
>> include/drm/drm_drv.h | 17 ++++++++++++++
>> 6 files changed, 84 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
>> index af3b7395bf69..c964064651d5 100644
>> --- a/drivers/gpu/drm/drm_client.c
>> +++ b/drivers/gpu/drm/drm_client.c
>> @@ -247,7 +247,8 @@ static void drm_client_buffer_delete(struct drm_client_buffer *buffer)
>> }
>>
>> static struct drm_client_buffer *
>> -drm_client_buffer_create(struct drm_client_dev *client, u32 width, u32 height, u32 format)
>> +drm_client_buffer_create(struct drm_client_dev *client, u32 width, u32 height, u32 format,
>> + bool fbdev)
>> {
>> const struct drm_format_info *info = drm_format_info(format);
>> struct drm_mode_create_dumb dumb_args = { };
>> @@ -265,7 +266,10 @@ drm_client_buffer_create(struct drm_client_dev *client, u32 width, u32 height, u
>> dumb_args.width = width;
>> dumb_args.height = height;
>> dumb_args.bpp = info->cpp[0] * 8;
>> - ret = drm_mode_create_dumb(dev, &dumb_args, client->file);
>> + if (fbdev)
>
> Maybe if (defined(CONFIG_DRM_FBDEV_EMULATION) && fbdev) ?
>
>> + ret = drm_mode_create_dumb_fbdev(dev, &dumb_args, client->file);
>
> And drm_mode_create_dumb_fbdev() could just be made a stub if
> CONFIG_DRM_FBDEV_EMULATION isn't enabled.
Makes sense.
>
> I believe the only usage of the DRM client API currently is the fbdev
> emulation layer anyways? But still makes sense I think to condtionally
> compile that since drm_client.o is built in the drm.ko module and the
> drm_fb_helper.o only included if fbdev emulation has been enabled.
Makes sense, I think.
Fbdev emulation is the only user of this code. And there won't be other
helpers like that. Any other client would use the regular dumb-buffer
functions.
>
>> + else
>> + ret = drm_mode_create_dumb(dev, &dumb_args, client->file);
>> if (ret)
>> goto err_delete;
>>
>> @@ -402,6 +406,7 @@ static int drm_client_buffer_addfb(struct drm_client_buffer *buffer,
>> * @width: Framebuffer width
>> * @height: Framebuffer height
>> * @format: Buffer format
>> + * @fbdev: True if the client provides an fbdev device, or false otherwise
>> *
>
> An emulated fbdev device ?
Ok.
Best regards
Thomas
>
> Other than those small nit,
>
> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
>
--
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 --]
next prev parent reply other threads:[~2022-03-09 8:42 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-03 20:58 [PATCH 0/9] drm: Support GEM SHMEM fbdev without shadow FB Thomas Zimmermann
2022-03-03 20:58 ` [PATCH 1/9] drm/simpledrm: Use fbdev defaults for shadow buffering Thomas Zimmermann
2022-03-08 9:31 ` Javier Martinez Canillas
2022-03-08 9:56 ` Thomas Zimmermann
2022-03-08 9:58 ` Javier Martinez Canillas
2022-03-03 20:58 ` [PATCH 2/9] fbdev: Put mmap for deferred I/O into drivers Thomas Zimmermann
2022-03-08 14:03 ` Javier Martinez Canillas
2022-03-03 20:58 ` [PATCH 3/9] fbdev: Track deferred-I/O pages in pageref struct Thomas Zimmermann
2022-03-08 14:42 ` Javier Martinez Canillas
2022-03-09 8:36 ` Thomas Zimmermann
2022-03-09 11:21 ` Javier Martinez Canillas
2022-03-03 20:58 ` [PATCH 4/9] fbdev: Export helper for implementing page_mkwrite Thomas Zimmermann
2022-03-08 17:21 ` Javier Martinez Canillas
2022-03-03 20:58 ` [PATCH 5/9] drm/fb-helper: Separate deferred I/O from shadow buffers Thomas Zimmermann
2022-03-08 17:24 ` Javier Martinez Canillas
2022-03-03 20:58 ` [PATCH 6/9] drm/fb-helper: Provide callback to create fbdev dumb buffers Thomas Zimmermann
2022-03-08 17:51 ` Javier Martinez Canillas
2022-03-09 8:42 ` Thomas Zimmermann [this message]
2022-03-15 19:11 ` Thomas Zimmermann
2022-03-03 20:58 ` [PATCH 7/9] drm/fb-helper: Provide fbdev deferred-I/O helpers Thomas Zimmermann
2022-03-08 18:56 ` Javier Martinez Canillas
2022-03-03 20:58 ` [PATCH 8/9] drm/gem-shmem: Implement fbdev dumb buffer and mmap helpers Thomas Zimmermann
2022-03-08 19:29 ` Javier Martinez Canillas
2022-03-09 8:47 ` Thomas Zimmermann
2022-03-09 11:25 ` Javier Martinez Canillas
2022-03-03 20:58 ` [PATCH 9/9] drm/virtio: Implement dumb_create_fbdev with GEM SHMEM helpers Thomas Zimmermann
2022-03-08 19:37 ` Javier Martinez Canillas
2022-03-09 8:52 ` Thomas Zimmermann
2022-03-09 11:29 ` Javier Martinez Canillas
2022-03-08 9:13 ` [PATCH 0/9] drm: Support GEM SHMEM fbdev without shadow FB Javier Martinez Canillas
2022-03-08 9:44 ` Thomas Zimmermann
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=1ec9bf07-798a-2bfa-a61b-b98fe9066df1@suse.de \
--to=tzimmermann@suse.de \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=deller@gmx.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=javierm@redhat.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
/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).