FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 01-20-2010, 02:42 AM
Steve Conklin
 
Default drm-i915-remove-loop-in-Ironlake-interrupt-handler

This is a multi-part message in MIME format.The attached patch is derived from c7c85101afd0cb8ce497456d12ee1cad4aad152f in
Linus's tree. There has been an urgent request made by intel to apply this to
the stable tree, and it should be in Karmic as well.

I welcome additional reviews of this patch, as it required some tweaking to
apply and it's ISR code.

As far as I know, this is the last remaining patch for the moment that is
required in Karmic for Ironlake.

Steve
 
Old 01-20-2010, 12:45 PM
Tim Gardner
 
Default drm-i915-remove-loop-in-Ironlake-interrupt-handler

Steve Conklin wrote:
> The attached patch is derived from c7c85101afd0cb8ce497456d12ee1cad4aad152f in
> Linus's tree. There has been an urgent request made by intel to apply this to
> the stable tree, and it should be in Karmic as well.
>
> I welcome additional reviews of this patch, as it required some tweaking to
> apply and it's ISR code.
>
> As far as I know, this is the last remaining patch for the moment that is
> required in Karmic for Ironlake.
>
> Steve
>

I noticed 3 things about the resulting patch.

1) This handler is not very efficient. There is typically one or more
bits in a single register that indicates if this instance of the card
actually generated the interrupt. In this case it looks like DEIER has
that information. Does the handler really need to do 6 register reads
and 2 register writes simply to determine it has nothing to do.

2) Depending on the HW design, there may be a race between when the IIR
registers are read, and when their conditions are cleared. For example,
DEIIR could go active after having been read, but before its cleared at
the end of the handler.

3) Why is there an additional variable introduced 'u32 segno' ?

rtg
--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 01-20-2010, 04:45 PM
Steve Conklin
 
Default drm-i915-remove-loop-in-Ironlake-interrupt-handler

On 01/20/2010 07:45 AM, Tim Gardner wrote:
> Steve Conklin wrote:
>> The attached patch is derived from c7c85101afd0cb8ce497456d12ee1cad4aad152f in
>> Linus's tree. There has been an urgent request made by intel to apply this to
>> the stable tree, and it should be in Karmic as well.
>>
>> I welcome additional reviews of this patch, as it required some tweaking to
>> apply and it's ISR code.
>>
>> As far as I know, this is the last remaining patch for the moment that is
>> required in Karmic for Ironlake.
>>
>> Steve
>>
>
> I noticed 3 things about the resulting patch.
>
> 1) This handler is not very efficient. There is typically one or more
> bits in a single register that indicates if this instance of the card
> actually generated the interrupt. In this case it looks like DEIER has
> that information. Does the handler really need to do 6 register reads
> and 2 register writes simply to determine it has nothing to do.
>
> 2) Depending on the HW design, there may be a race between when the IIR
> registers are read, and when their conditions are cleared. For example,
> DEIIR could go active after having been read, but before its cleared at
> the end of the handler.
>
> 3) Why is there an additional variable introduced 'u32 segno' ?
>
> rtg

Upon further review, I see some divergence from both upstream and what's in
Linus's tree that worry me. I'm going to investigate but in the meantime, this
patch should be withdrawn from consideration for Karmic.

Steve

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 01-20-2010, 08:49 PM
Steve Conklin
 
Default drm-i915-remove-loop-in-Ironlake-interrupt-handler

On 01/20/2010 07:45 AM, Tim Gardner wrote:
> Steve Conklin wrote:
>> The attached patch is derived from c7c85101afd0cb8ce497456d12ee1cad4aad152f in
>> Linus's tree. There has been an urgent request made by intel to apply this to
>> the stable tree, and it should be in Karmic as well.
>>
>> I welcome additional reviews of this patch, as it required some tweaking to
>> apply and it's ISR code.
>>
>> As far as I know, this is the last remaining patch for the moment that is
>> required in Karmic for Ironlake.
>>
>> Steve
>>
>
> I noticed 3 things about the resulting patch.
>
> 1) This handler is not very efficient. There is typically one or more
> bits in a single register that indicates if this instance of the card
> actually generated the interrupt. In this case it looks like DEIER has
> that information. Does the handler really need to do 6 register reads
> and 2 register writes simply to determine it has nothing to do.
>
> 2) Depending on the HW design, there may be a race between when the IIR
> registers are read, and when their conditions are cleared. For example,
> DEIIR could go active after having been read, but before its cleared at
> the end of the handler.
>
> 3) Why is there an additional variable introduced 'u32 segno' ?
>
> rtg

I'm convinced that the patch is good. It leaves this function identical to
what's now in Linus's upstream tree. As for the questions above, I've pasted the
complete patched function below, and my answers are:

1) There aren't really any extra reads. The "disable master interrupt" bit
accesses the DEIER register correctly, and looks pretty standard. The throwaway
read isn't documented as far as I can find in the hardware documentation but
it's been in the driver for a very long time.

To determine whether there is an interrupt pending that we care about, and to
determine the source, requires reading three registers - DEIIR, GTIIR, and
SDEIIR. If these three are zero, then we finish out and are done. The registers
are only read once.

2) Also, the only bits which cleared are the ones which were set when we got
interrupted, which should all have been handled. Without the documentation about
the specifics of this I think we have to assume it's correct. It may be in the
manuals, I haven't found it.

3) That variable was added by an earlier patch which makes tracing the driver
easier - the description frmo the commit to Linus's tree is:

commit 1c5d22f76dc721f3acb7a3dadc657a221e487fb7
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Aug 25 11:15:50 2009 +0100

drm/i915: Add tracepoints

By adding tracepoint equivalents for WATCH_BUF/EXEC we are able to monitor
the lifetimes of objects, requests and significant events. These events can
then be probed using the tracing frameworks, such as systemtap and, in
particular, perf.

I hereby renew my request to have this pulled in to SRU proposed for Karmic.

Steve

-----------------------------

irqreturn_t igdng_irq_handler(struct drm_device *dev)
{
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev->dev_private;
int ret = IRQ_NONE;
u32 de_iir, gt_iir, de_ier, pch_iir;
struct drm_i915_master_private *master_priv;

/* disable master interrupt before clearing iir */
de_ier = I915_READ(DEIER);
I915_WRITE(DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
(void)I915_READ(DEIER);

de_iir = I915_READ(DEIIR);
gt_iir = I915_READ(GTIIR);
pch_iir = I915_READ(SDEIIR);

if (de_iir == 0 && gt_iir == 0 && pch_iir == 0)
goto done;

ret = IRQ_HANDLED;

if (dev->primary->master) {
master_priv = dev->primary->master->driver_priv;
if (master_priv->sarea_priv)
master_priv->sarea_priv->last_dispatch =
READ_BREADCRUMB(dev_priv);
}

if (gt_iir & GT_USER_INTERRUPT) {
u32 seqno = i915_get_gem_seqno(dev);
dev_priv->mm.irq_gem_seqno = seqno;
trace_i915_gem_request_complete(dev, seqno);
DRM_WAKEUP(&dev_priv->irq_queue);
dev_priv->hangcheck_count = 0;
mod_timer(&dev_priv->hangcheck_timer, jiffies +
DRM_I915_HANGCHECK_PERIOD);
}

if (de_iir & DE_GSE)
ironlake_opregion_gse_intr(dev);

/* check event from PCH */
if ((de_iir & DE_PCH_EVENT) &&
(pch_iir & SDE_HOTPLUG_MASK)) {
queue_work(dev_priv->wq, &dev_priv->hotplug_work);
}

/* should clear PCH hotplug event before clear CPU irq */
I915_WRITE(SDEIIR, pch_iir);
I915_WRITE(GTIIR, gt_iir);
I915_WRITE(DEIIR, de_iir);

done:
I915_WRITE(DEIER, de_ier);
(void)I915_READ(DEIER);

return ret;
}


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 01-21-2010, 09:13 AM
Stefan Bader
 
Default drm-i915-remove-loop-in-Ironlake-interrupt-handler

Steve Conklin wrote:
> The attached patch is derived from c7c85101afd0cb8ce497456d12ee1cad4aad152f in
> Linus's tree. There has been an urgent request made by intel to apply this to
> the stable tree, and it should be in Karmic as well.
>
> I welcome additional reviews of this patch, as it required some tweaking to
> apply and it's ISR code.
>
> As far as I know, this is the last remaining patch for the moment that is
> required in Karmic for Ironlake.
>
> Steve
>

This one is queued for upstream stable 2.6.32.5. It looks ok to me. The only
slight difference seems to be that it moves writing into the IIRs after the
other actions, but this might have no impact at all.

Steve, I need a (public) bug number for this request. I did not see any. For the
patch part:

Acked-by: Stefan Bader <stefan.bader@canonical.com>

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 01-21-2010, 11:59 AM
Tim Gardner
 
Default drm-i915-remove-loop-in-Ironlake-interrupt-handler

Steve Conklin wrote:
> On 01/20/2010 07:45 AM, Tim Gardner wrote:
>> Steve Conklin wrote:
>>> The attached patch is derived from c7c85101afd0cb8ce497456d12ee1cad4aad152f in
>>> Linus's tree. There has been an urgent request made by intel to apply this to
>>> the stable tree, and it should be in Karmic as well.
>>>
>>> I welcome additional reviews of this patch, as it required some tweaking to
>>> apply and it's ISR code.
>>>
>>> As far as I know, this is the last remaining patch for the moment that is
>>> required in Karmic for Ironlake.
>>>
>>> Steve
>>>
>> I noticed 3 things about the resulting patch.
>>
>> 1) This handler is not very efficient. There is typically one or more
>> bits in a single register that indicates if this instance of the card
>> actually generated the interrupt. In this case it looks like DEIER has
>> that information. Does the handler really need to do 6 register reads
>> and 2 register writes simply to determine it has nothing to do.
>>
>> 2) Depending on the HW design, there may be a race between when the IIR
>> registers are read, and when their conditions are cleared. For example,
>> DEIIR could go active after having been read, but before its cleared at
>> the end of the handler.
>>
>> 3) Why is there an additional variable introduced 'u32 segno' ?
>>
>> rtg
>
> I'm convinced that the patch is good. It leaves this function identical to
> what's now in Linus's upstream tree. As for the questions above, I've pasted the
> complete patched function below, and my answers are:
>
> 1) There aren't really any extra reads. The "disable master interrupt" bit
> accesses the DEIER register correctly, and looks pretty standard. The throwaway
> read isn't documented as far as I can find in the hardware documentation but
> it's been in the driver for a very long time.
>
> To determine whether there is an interrupt pending that we care about, and to
> determine the source, requires reading three registers - DEIIR, GTIIR, and
> SDEIIR. If these three are zero, then we finish out and are done. The registers
> are only read once.
>
> 2) Also, the only bits which cleared are the ones which were set when we got
> interrupted, which should all have been handled. Without the documentation about
> the specifics of this I think we have to assume it's correct. It may be in the
> manuals, I haven't found it.
>
> 3) That variable was added by an earlier patch which makes tracing the driver
> easier - the description frmo the commit to Linus's tree is:
>
> commit 1c5d22f76dc721f3acb7a3dadc657a221e487fb7
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date: Tue Aug 25 11:15:50 2009 +0100
>
> drm/i915: Add tracepoints
>
> By adding tracepoint equivalents for WATCH_BUF/EXEC we are able to monitor
> the lifetimes of objects, requests and significant events. These events can
> then be probed using the tracing frameworks, such as systemtap and, in
> particular, perf.
>
> I hereby renew my request to have this pulled in to SRU proposed for Karmic.
>
> Steve
>
> -----------------------------
>
> irqreturn_t igdng_irq_handler(struct drm_device *dev)
> {
> drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev->dev_private;
> int ret = IRQ_NONE;
> u32 de_iir, gt_iir, de_ier, pch_iir;
> struct drm_i915_master_private *master_priv;
>
> /* disable master interrupt before clearing iir */
> de_ier = I915_READ(DEIER);
> I915_WRITE(DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
> (void)I915_READ(DEIER);
>
> de_iir = I915_READ(DEIIR);
> gt_iir = I915_READ(GTIIR);
> pch_iir = I915_READ(SDEIIR);
>
> if (de_iir == 0 && gt_iir == 0 && pch_iir == 0)
> goto done;
>
> ret = IRQ_HANDLED;
>
> if (dev->primary->master) {
> master_priv = dev->primary->master->driver_priv;
> if (master_priv->sarea_priv)
> master_priv->sarea_priv->last_dispatch =
> READ_BREADCRUMB(dev_priv);
> }
>
> if (gt_iir & GT_USER_INTERRUPT) {
> u32 seqno = i915_get_gem_seqno(dev);
> dev_priv->mm.irq_gem_seqno = seqno;
> trace_i915_gem_request_complete(dev, seqno);
> DRM_WAKEUP(&dev_priv->irq_queue);
> dev_priv->hangcheck_count = 0;
> mod_timer(&dev_priv->hangcheck_timer, jiffies +
> DRM_I915_HANGCHECK_PERIOD);
> }
>
> if (de_iir & DE_GSE)
> ironlake_opregion_gse_intr(dev);
>
> /* check event from PCH */
> if ((de_iir & DE_PCH_EVENT) &&
> (pch_iir & SDE_HOTPLUG_MASK)) {
> queue_work(dev_priv->wq, &dev_priv->hotplug_work);
> }
>
> /* should clear PCH hotplug event before clear CPU irq */
> I915_WRITE(SDEIIR, pch_iir);
> I915_WRITE(GTIIR, gt_iir);
> I915_WRITE(DEIIR, de_iir);
>
> done:
> I915_WRITE(DEIER, de_ier);
> (void)I915_READ(DEIER);
>
> return ret;
> }
>

Acked-by: Tim Gardner <tim.gardner@canonical.com>

--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 01-21-2010, 03:09 PM
Steve Conklin
 
Default drm-i915-remove-loop-in-Ironlake-interrupt-handler

On 01/21/2010 04:13 AM, Stefan Bader wrote:
> Steve Conklin wrote:
>> The attached patch is derived from c7c85101afd0cb8ce497456d12ee1cad4aad152f in
>> Linus's tree. There has been an urgent request made by intel to apply this to
>> the stable tree, and it should be in Karmic as well.
>>
>> I welcome additional reviews of this patch, as it required some tweaking to
>> apply and it's ISR code.
>>
>> As far as I know, this is the last remaining patch for the moment that is
>> required in Karmic for Ironlake.
>>
>> Steve
>>
>
> This one is queued for upstream stable 2.6.32.5. It looks ok to me. The only
> slight difference seems to be that it moves writing into the IIRs after the
> other actions, but this might have no impact at all.
>
> Steve, I need a (public) bug number for this request. I did not see any. For the
> patch part:
>
> Acked-by: Stefan Bader <stefan.bader@canonical.com>

Bug number 510722

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 01-22-2010, 02:48 PM
Stefan Bader
 
Default drm-i915-remove-loop-in-Ironlake-interrupt-handler

Steve Conklin wrote:
> The attached patch is derived from c7c85101afd0cb8ce497456d12ee1cad4aad152f in
> Linus's tree. There has been an urgent request made by intel to apply this to
> the stable tree, and it should be in Karmic as well.
>
> I welcome additional reviews of this patch, as it required some tweaking to
> apply and it's ISR code.
>
> As far as I know, this is the last remaining patch for the moment that is
> required in Karmic for Ironlake.
>
> Steve
>
Applied to Karmic. Seen this included in 2.6.32.5, so next Lucid pull of stable
should close it there.

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

Thread Tools




All times are GMT. The time now is 12:24 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org