linux-mips.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Zimmermann <tzimmermann@suse.de>
To: Javier Martinez Canillas <javierm@redhat.com>,
	daniel@ffwll.ch, airlied@gmail.com, sam@ravnborg.org,
	mripard@kernel.org, maarten.lankhorst@linux.intel.com
Cc: dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
	linux-aspeed@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org,
	etnaviv@lists.freedesktop.org, linux-samsung-soc@vger.kernel.org,
	linux-hyperv@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	linux-mips@vger.kernel.org, linux-mediatek@lists.infradead.org,
	linux-amlogic@lists.infradead.org, linux-arm-msm@vger.kernel.org,
	freedreno@lists.freedesktop.org, nouveau@lists.freedesktop.org,
	virtualization@lists.linux-foundation.org,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-sunxi@lists.linux.dev, linux-tegra@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 17/21] drm/fb-helper: Perform all fbdev I/O with the same implementation
Date: Wed, 2 Nov 2022 11:33:12 +0100	[thread overview]
Message-ID: <0ca70b76-c24a-4fdb-cf0d-2647d37379df@suse.de> (raw)
In-Reply-To: <3ab32fc3-f2aa-1b42-fd87-557482ab56d5@redhat.com>


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

Hi

Am 02.11.22 um 10:32 schrieb Javier Martinez Canillas:
> On 10/24/22 13:19, Thomas Zimmermann wrote:
>> Implement the fbdev's read/write helpers with the same functions. Use
>> the generic fbdev's code as template. Convert all drivers.
>>
>> DRM's fb helpers must implement regular I/O functionality in struct
>> fb_ops and possibly perform a damage update. Handle all this in the
>> same functions and convert drivers. The functionality has been used
>> as part of the generic fbdev code for some time. The drivers don't
>> set struct drm_fb_helper.fb_dirty, so they will not be affected by
>> damage handling.
>>
>> For I/O memory, fb helpers now provide drm_fb_helper_cfb_read() and
>> drm_fb_helper_cfb_write(). Several drivers require these. Until now
>> tegra used I/O read and write, although the memory buffer appears to
>> be in system memory. So use _sys_ helpers now.
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> ---
> 
> [...]
> 
>> +static ssize_t __drm_fb_helper_write(struct fb_info *info, const char __user *buf, size_t count,
>> +				     loff_t *ppos, drm_fb_helper_write_screen write_screen)
>> +{
> 
> [...]
> 
>> +	/*
>> +	 * Copy to framebuffer even if we already logged an error. Emulates
>> +	 * the behavior of the original fbdev implementation.
>> +	 */
>> +	ret = write_screen(info, buf, count, pos);
>> +	if (ret < 0)
>> +		return ret; /* return last error, if any */
>> +	else if (!ret)
>> +		return err; /* return previous error, if any */
>> +
>> +	*ppos += ret;
>> +
> 
> Should *ppos be incremented even if the previous error is returned?

Yes. It emulates the original fbdev code at [1]. Further down in that 
function, the position is being updated even if an error occured. We 
only return the initial error if no bytes got written.

It could happen that some userspace program hits to error, but still 
relies on the output and position being updated. IIRC I even added 
validation of this behavior to the IGT fbdev tests.  I agree that this 
is somewhat bogus behavior, but changing it would change long-standing 
userspace semantics.

[1] 
https://elixir.bootlin.com/linux/v6.0.6/source/drivers/video/fbdev/core/fbmem.c#L825

> 
> The write_screen() succeeded anyways, even when the count written was
> smaller than what the caller asked for.
> 
>>   /**
>> - * drm_fb_helper_sys_read - wrapper around fb_sys_read
>> + * drm_fb_helper_sys_read - Implements struct &fb_ops.fb_read for system memory
>>    * @info: fb_info struct pointer
>>    * @buf: userspace buffer to read from framebuffer memory
>>    * @count: number of bytes to read from framebuffer memory
>>    * @ppos: read offset within framebuffer memory
>>    *
>> - * A wrapper around fb_sys_read implemented by fbdev core
>> + * Returns:
>> + * The number of read bytes on success, or an error code otherwise.
>>    */
> 
> This sentence sounds a little bit off to me. Shouldn't be "number of bytes read"
> instead? I'm not a native English speaker though, so feel free to just ignore me.

You're right.

> 
> [...]
> 
>>   
>> +static ssize_t fb_read_screen_base(struct fb_info *info, char __user *buf, size_t count,
>> +				   loff_t pos)
>> +{
>> +	const char __iomem *src = info->screen_base + pos;
>> +	size_t alloc_size = min_t(size_t, count, PAGE_SIZE);
>> +	ssize_t ret = 0;
>> +	int err = 0;
> 
> Do you really need these two? AFAIK ssize_t is a signed type

I think so. We'll go through the while loop multiple times. If we fail 
on the initial iteration, we return the error in err. If we fail on any 
later iteration, we return the number of processed bytes.  Having this 
in two variables simplifies the logic AFAICT.

Best regards
Thomas

> so you can just use the ret variable to store and return the
> errno value.
> 
> [...]
> 
>> +static ssize_t fb_write_screen_base(struct fb_info *info, const char __user *buf, size_t count,
>> +				    loff_t pos)
>> +{
>> +	char __iomem *dst = info->screen_base + pos;
>> +	size_t alloc_size = min_t(size_t, count, PAGE_SIZE);
>> +	ssize_t ret = 0;
>> +	int err = 0;
> 
> Same here.
> 

-- 
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:[~2022-11-02 10:33 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-24 11:19 [PATCH v2 00/21] drm/fb-helper: Untangle fbdev emulation and helpers Thomas Zimmermann
2022-10-24 11:19 ` [PATCH v2 01/21] drm/komeda: Don't set struct drm_driver.lastclose Thomas Zimmermann
2022-10-31 11:58   ` Javier Martinez Canillas
2022-10-24 11:19 ` [PATCH v2 02/21] drm/mcde: " Thomas Zimmermann
2022-10-31 11:59   ` Javier Martinez Canillas
2022-10-24 11:19 ` [PATCH v2 03/21] drm/vboxvideo: " Thomas Zimmermann
2022-10-31 12:00   ` Javier Martinez Canillas
2022-10-24 11:19 ` [PATCH v2 04/21] drm/amdgpu: Don't set struct drm_driver.output_poll_changed Thomas Zimmermann
2022-10-31 12:08   ` Javier Martinez Canillas
2022-10-31 12:13   ` Javier Martinez Canillas
2022-10-24 11:19 ` [PATCH v2 05/21] drm/imx/dcss: " Thomas Zimmermann
2022-10-31 12:16   ` Javier Martinez Canillas
2022-10-24 11:19 ` [PATCH v2 06/21] drm/ingenic: " Thomas Zimmermann
2022-10-31 12:17   ` Javier Martinez Canillas
2022-10-24 11:19 ` [PATCH v2 07/21] drm/logicvc: " Thomas Zimmermann
2022-10-31 12:18   ` Javier Martinez Canillas
2022-10-24 11:19 ` [PATCH v2 08/21] drm/rockchip: " Thomas Zimmermann
2022-10-31 12:19   ` Javier Martinez Canillas
2022-10-24 11:19 ` [PATCH v2 09/21] drm/panel-ili9341: Include <linux/backlight.h> Thomas Zimmermann
2022-10-31 12:21   ` Javier Martinez Canillas
2022-10-24 11:19 ` [PATCH v2 10/21] drm/tve200: Include <linux/of.h> Thomas Zimmermann
2022-10-31 12:22   ` Javier Martinez Canillas
2022-10-24 11:19 ` [PATCH v2 11/21] drm/fb-helper: Cleanup include statements in header file Thomas Zimmermann
2022-10-31 12:23   ` Javier Martinez Canillas
2022-10-24 11:19 ` [PATCH v2 12/21] drm/fb_helper: Rename field fbdev to info in struct drm_fb_helper Thomas Zimmermann
2022-10-31 12:25   ` Javier Martinez Canillas
2022-10-24 11:19 ` [PATCH v2 13/21] drm/fb-helper: Rename drm_fb_helper_alloc_fbi() to use _info postfix Thomas Zimmermann
2022-10-31 12:26   ` Javier Martinez Canillas
2022-10-24 11:19 ` [PATCH v2 14/21] drm/fb-helper: Rename drm_fb_helper_unregister_fbi() " Thomas Zimmermann
2022-10-31 13:27   ` Javier Martinez Canillas
2022-10-24 11:19 ` [PATCH v2 15/21] drm/fb-helper: Disconnect damage worker from update logic Thomas Zimmermann
2022-11-02  9:03   ` Javier Martinez Canillas
2022-10-24 11:19 ` [PATCH v2 16/21] drm/fb-helper: Call fb_sync in I/O functions Thomas Zimmermann
2022-11-02  9:05   ` Javier Martinez Canillas
2022-10-24 11:19 ` [PATCH v2 17/21] drm/fb-helper: Perform all fbdev I/O with the same implementation Thomas Zimmermann
2022-11-02  9:32   ` Javier Martinez Canillas
2022-11-02 10:33     ` Thomas Zimmermann [this message]
2022-11-02 10:46       ` Javier Martinez Canillas
2022-10-24 11:19 ` [PATCH v2 18/21] drm/fb_helper: Minimize damage-helper overhead Thomas Zimmermann
2022-11-02  9:39   ` Javier Martinez Canillas
2022-10-24 11:19 ` [PATCH v2 19/21] drm/fb-helper: Always initialize generic fbdev emulation Thomas Zimmermann
2022-11-02  9:40   ` Javier Martinez Canillas
2022-10-24 11:19 ` [PATCH v2 20/21] drm/fb-helper: Move generic fbdev emulation into separate source file Thomas Zimmermann
2022-11-02 10:01   ` Javier Martinez Canillas
2022-10-24 11:19 ` [PATCH v2 21/21] drm/fb-helper: Remove unnecessary include statements Thomas Zimmermann
2022-11-02 10:02   ` Javier Martinez Canillas

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=0ca70b76-c24a-4fdb-cf0d-2647d37379df@suse.de \
    --to=tzimmermann@suse.de \
    --cc=airlied@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=etnaviv@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=javierm@redhat.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-aspeed@lists.ozlabs.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=linux-tegra@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=sam@ravnborg.org \
    --cc=spice-devel@lists.freedesktop.org \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=xen-devel@lists.xenproject.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).