devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jon Medhurst (Tixy)" <tixy@linaro.org>
To: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: David Airlie <airlied@linux.ie>,
	dri-devel@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	Mark Rutland <mark.rutland@arm.com>,
	Arnd Bergmann <arnd@arndb.de>, Pawel Moll <pawel.moll@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	Rob Herring <robh+dt@kernel.org>,
	Kumar Gala <galak@codeaurora.org>,
	Olof Johansson <olof@lixom.net>,
	Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH 2/4] drm: Add support for ARM's HDLCD controller.
Date: Mon, 17 Aug 2015 19:17:53 +0100	[thread overview]
Message-ID: <1439835473.3341.88.camel@linaro.org> (raw)
In-Reply-To: <1438784892-27888-3-git-send-email-Liviu.Dudau@arm.com>

I haven't reviewed the code in detail, just had one comment I alluded to
in a private email the other day...

On Wed, 2015-08-05 at 15:28 +0100, Liviu Dudau wrote:

> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
[...]
> +void hdlcd_set_scanout(struct hdlcd_drm_private *hdlcd)
> +{
> +	struct drm_framebuffer *fb = hdlcd->crtc.primary->fb;
> +	struct drm_gem_cma_object *gem;
> +	unsigned int depth, bpp;
> +	dma_addr_t scanout_start;
> +
> +	drm_fb_get_bpp_depth(fb->pixel_format, &depth, &bpp);
> +	gem = drm_fb_cma_get_gem_obj(fb, 0);
> +
> +	scanout_start = gem->paddr + fb->offsets[0] +
> +		(hdlcd->crtc.y * fb->pitches[0]) + (hdlcd->crtc.x * bpp/8);
> +
> +	hdlcd_write(hdlcd, HDLCD_REG_FB_BASE, scanout_start);
> +}
> +

The above function accesses various pointers and values, which
presumably all need to be valid and consistent. However...

[...]
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
[...]
> +static irqreturn_t hdlcd_irq(int irq, void *arg)
> +{
> +	struct drm_device *dev = arg;
> +	struct hdlcd_drm_private *hdlcd = dev->dev_private;
> +	unsigned long irq_status;
> +
> +	irq_status = hdlcd_read(hdlcd, HDLCD_REG_INT_STATUS);
> +
> +#ifdef CONFIG_DEBUG_FS
> +	if (irq_status & HDLCD_INTERRUPT_UNDERRUN) {
> +		atomic_inc(&hdlcd->buffer_underrun_count);
> +	}
> +	if (irq_status & HDLCD_INTERRUPT_DMA_END) {
> +		atomic_inc(&hdlcd->dma_end_count);
> +	}
> +	if (irq_status & HDLCD_INTERRUPT_BUS_ERROR) {
> +		atomic_inc(&hdlcd->bus_error_count);
> +	}
> +	if (irq_status & HDLCD_INTERRUPT_VSYNC) {
> +		atomic_inc(&hdlcd->vsync_count);
> +	}
> +#endif
> +	if (irq_status & HDLCD_INTERRUPT_VSYNC) {
> +		struct drm_pending_vblank_event *event;
> +		unsigned long flags;
> +
> +		hdlcd_set_scanout(hdlcd);

hdlcd_set_scanout is being called on every vsync interrupt, can we
guarantee that is safe? What if we're in the middle of a page flip or
panning operation? Seems to me that there is at least scope for
incorrect addresses being calculated leading to a nasty glitch on the
screen for one frame. And in the worst case, possibly invalid pointer
being dereferenced.

So, if scanout needs to be set on every vsync, would it not be safer
(and more efficient) to have a single variable storing the value to use
during interrupts, and recalculate that value outside of interrupts
whenever things are changed?

-- 
Tixy

  parent reply	other threads:[~2015-08-17 18:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-05 14:28 [PATCH 0/4] drm: Add support for the ARM HDLCD display controller Liviu Dudau
2015-08-05 14:28 ` [PATCH 1/4] drm: arm: Add DT bindings documentation for HDLCD driver Liviu Dudau
2015-08-05 14:28 ` [PATCH 2/4] drm: Add support for ARM's HDLCD controller Liviu Dudau
2015-08-16  8:56   ` Emil Velikov
     [not found]     ` <CACvgo537C6SRfhMTNoE4cSLJukcXuKLvt1TRykynX--ybEhmaQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-17 15:15       ` Liviu Dudau
2015-08-18 16:41         ` Emil Velikov
2015-08-19  9:28           ` Liviu Dudau
2015-08-17 18:17   ` Jon Medhurst (Tixy) [this message]
2015-08-19  9:46     ` Liviu Dudau
2015-08-05 14:28 ` [PATCH 3/4] arm64: Juno: Add HDLCD support to the Juno boards Liviu Dudau
     [not found]   ` <1438784892-27888-4-git-send-email-Liviu.Dudau-5wv7dgnIgG8@public.gmane.org>
2015-08-05 17:53     ` Russell King - ARM Linux
     [not found]       ` <20150805175303.GB7557-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2015-08-05 19:03         ` Liviu Dudau
2015-08-05 21:48           ` Russell King - ARM Linux
2015-08-06 10:16             ` Liviu Dudau
2015-08-05 14:28 ` [PATCH 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=1439835473.3341.88.camel@linaro.org \
    --to=tixy@linaro.org \
    --cc=Liviu.Dudau@arm.com \
    --cc=airlied@linux.ie \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=olof@lixom.net \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=will.deacon@arm.com \
    /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).