lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 24 Jun 2023 17:33:35 +0800
From:   Sui Jingfeng <suijingfeng@...ngson.cn>
To:     Geert Uytterhoeven <geert+renesas@...der.be>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Kieran Bingham <kieran.bingham+renesas@...asonboard.com>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Magnus Damm <magnus.damm@...il.com>
Cc:     linux-renesas-soc@...r.kernel.org, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org
Subject: Re: [28/39] drm: renesas: shmobile: Use drm_crtc_handle_vblank()

Hi,


I'm fine with this patch but I I don't see the benefit.

This reply is more about my personal question.


On 2023/6/22 17:21, Geert Uytterhoeven wrote:
> Replace the call to the legacy drm_handle_vblank() function with a call
> to the new drm_crtc_handle_vblank() helper.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@...der.be>
> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>
Reviewed-by: Sui Jingfeng <suijingfeng@...ngson.cn>
> ---
>   drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c b/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c
> index c98e2bdd888c3274..6eaf2c5a104f451a 100644
> --- a/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c
> +++ b/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c
> @@ -86,7 +86,7 @@ static irqreturn_t shmob_drm_irq(int irq, void *arg)
>   	spin_unlock_irqrestore(&sdev->irq_lock, flags);
>   
>   	if (status & LDINTR_VES) {
> -		drm_handle_vblank(dev, 0);
> +		drm_crtc_handle_vblank(&sdev->crtc.base);


After switching to drm_crtc_handle_vblank(),

your driver need another deference to the pointer of 'struct drm_crtc' 
to get the pointer of 'struct drm_device';

Plus another call to get the index(display pipe) of the CRTC by calling 
drm_crtc_index(crtc).


Consider that shmob-drm support only one display pipe,

is it that the switching is less straight forward than the original 
implement ?


```

/**
  * drm_crtc_handle_vblank - handle a vblank event
  * @crtc: where this event occurred
  *
  * Drivers should call this routine in their vblank interrupt handlers to
  * update the vblank counter and send any signals that may be pending.
  *
  * This is the native KMS version of drm_handle_vblank().
  *
  * Note that for a given vblank counter value drm_crtc_handle_vblank()
  * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
  * provide a barrier: Any writes done before calling
  * drm_crtc_handle_vblank() will be visible to callers of the later
  * functions, if the vblank count is the same or a later one.
  *
  * See also &drm_vblank_crtc.count.
  *
  * Returns:
  * True if the event was successfully handled, false on failure.
  */
bool drm_crtc_handle_vblank(struct drm_crtc *crtc)
{
     return drm_handle_vblank(crtc->dev, drm_crtc_index(crtc));
}

```

Is it that drm_crtc_handle_vblank() function is preferred over 
drm_handle_vblank() in the future?

I'm fine with this question answered.


>   		shmob_drm_crtc_finish_page_flip(&sdev->crtc);
>   	}
>   

-- 
Jingfeng

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ