public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Liviu.Dudau@arm.com (Liviu Dudau)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 2/4] drm: Add support for ARM's HDLCD controller.
Date: Thu, 3 Dec 2015 10:00:21 +0000	[thread overview]
Message-ID: <20151203100021.GD972@e106497-lin.cambridge.arm.com> (raw)
In-Reply-To: <CAPj87rNFFGeL8z9GBXxyVri1RyhVpMGS0yz7opgCYamHYV1Yow@mail.gmail.com>

On Wed, Dec 02, 2015 at 05:21:44PM +0000, Daniel Stone wrote:
> Hi Liviu,

Hi Daniel,

> 
> On 2 December 2015 at 12:23, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> > +       if (irq_status & HDLCD_INTERRUPT_VSYNC) {
> > +               unsigned long flags;
> > +
> > +               drm_handle_vblank(drm, 0);
> > +
> > +               spin_lock_irqsave(&drm->event_lock, flags);
> > +               if (hdlcd->event) {
> > +                       drm_send_vblank_event(drm, hdlcd->event->pipe, hdlcd->event);
> > +                       drm_crtc_vblank_put(&hdlcd->crtc);
> > +                       hdlcd->event = NULL;
> > +               }
> > +               spin_unlock_irqrestore(&drm->event_lock, flags);
> > +       }
> 
> As with VC4 and Rockchip, you're missing a ->preclose handler in your
> drm_drv, to make sure that you don't try to send events to a dead
> client (which causes an OOPS):
> https://git.collabora.com/cgit/user/daniels/linux.git/commit/?h=wip/4.4.x/rockchip-drm-fixes&id=d14f21bcd7
> (and its parent)
 
Thanks for reviewing this!

I do acknowledge your concerns and you might correct my understanding on
how atomic DRM works, but I believe in this case we should be safe. The
event stored in hdlcd->event is taken out of the crtc->state->event during
the crtc->atomic_begin() callback. If the client is dead the callback should
not be called, so that's how we avoid the OOPS.

> Also, is there anything preventing clients from submitting multiple
> pageflips before the event is sent? I couldn't see anything from a
> quick look, so you could have the situation of:
>   - client submits pageflip, event 1 stored to hdlcd->event
>   - client submits pageflip, event 2 stored to hdlcd->event
>   - vblank arrives, event 2 is sent
>   - event 1 has disappeared and been leaked

As for multiple events being submitted before vsync interrupt happening: given
that the event is plucked out of the crtc->state, is that possible? And if so,
is there a case where having the later event overwrite the earlier one a desired
outcome?

> 
> Cheers,
> Daniel
> 

Best regards,
Liviu

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

  reply	other threads:[~2015-12-03 10:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-02 12:22 [PATCH v3 0/4] drm: Add support for the ARM HDLCD display controller Liviu Dudau
2015-12-02 12:22 ` [PATCH v3 1/4] drm: arm: Add DT bindings documentation for HDLCD driver Liviu Dudau
2015-12-02 14:25   ` Rob Herring
2015-12-02 14:51     ` Liviu Dudau
2015-12-02 12:23 ` [PATCH v3 2/4] drm: Add support for ARM's HDLCD controller Liviu Dudau
2015-12-02 15:24   ` Daniel Vetter
2015-12-02 15:33     ` Daniel Vetter
2015-12-02 15:57       ` Liviu Dudau
2015-12-02 17:13     ` Liviu Dudau
2015-12-02 17:21   ` Daniel Stone
2015-12-03 10:00     ` Liviu Dudau [this message]
2015-12-03 14:20       ` Daniel Stone
2015-12-03 14:48         ` Liviu Dudau
2015-12-02 12:23 ` [PATCH v3 3/4] arm64: Juno: Add HDLCD support to the Juno boards Liviu Dudau
2015-12-02 12:23 ` [PATCH v3 4/4] MAINTAINERS: Add Liviu Dudau as maintainer for ARM HDLCD driver Liviu Dudau

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=20151203100021.GD972@e106497-lin.cambridge.arm.com \
    --to=liviu.dudau@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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