Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760269AbbLCOUa (ORCPT ); Thu, 3 Dec 2015 09:20:30 -0500 Received: from mail-wm0-f42.google.com ([74.125.82.42]:38450 "EHLO mail-wm0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752053AbbLCOU1 (ORCPT ); Thu, 3 Dec 2015 09:20:27 -0500 MIME-Version: 1.0 In-Reply-To: <20151203100021.GD972@e106497-lin.cambridge.arm.com> References: <1449058982-18595-1-git-send-email-Liviu.Dudau@arm.com> <1449058982-18595-3-git-send-email-Liviu.Dudau@arm.com> <20151203100021.GD972@e106497-lin.cambridge.arm.com> Date: Thu, 3 Dec 2015 14:20:26 +0000 Message-ID: Subject: Re: [PATCH v3 2/4] drm: Add support for ARM's HDLCD controller. From: Daniel Stone To: Liviu Dudau Cc: David Airlie , Catalin Marinas , Will Deacon , Rob Herring , Sudeep Holla , Jon Medhurst , Mark Rutland , Ian Campbell , Kumar Gala , Rob Herring , Russell King , devicetree , Pawel Moll , Arnd Bergmann , Greg Kroah-Hartman , Punit Agrawal , LKML , DRI devel , Andrew Morton , Robin Murphy , LAKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3223 Lines: 70 Hi Liviu, On 3 December 2015 at 10:00, Liviu Dudau wrote: > On Wed, Dec 02, 2015 at 05:21:44PM +0000, Daniel Stone wrote: >> On 2 December 2015 at 12:23, Liviu Dudau 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. Right, it's taken out of the CRTC state and put into the overall HDLCD structure. So the OOPS happens when: - client submits state with event requested, async flag set - atomic_begin moves crtc->state->event into hdlcd->event - control returns to client, who exits immediately - vblank happens - hdlcd->event->base.file_priv now points to a dead client - 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? Having events being overwritten is extremely undesirable; it could cause a client to stall in the right scenarios (e.g. requests submitted separately for different planes). It would be far better to turn hdlcd->event into a list of events which are sent per-vblank, probably just by retaining a list of pending states to apply; this also makes it easier to handle async commits in the future (which Weston in particular relies on). Cheers, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/