All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Anholt <eric@anholt.net>
To: Stefan Schake <stschake@gmail.com>
Cc: David Airlie <airlied@linux.ie>,
	linux-rpi-kernel@lists.infradead.org,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] drm/vc4: Ensure interrupts are disabled
Date: Tue, 14 Nov 2017 11:44:41 -0800	[thread overview]
Message-ID: <87zi7o8x1y.fsf@anholt.net> (raw)
In-Reply-To: <CAOZHkRxf_puuVOoUUnbQ_mM92=pA5Mzoi4_LtJ8BKRnmau-HYg@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1135 bytes --]

Stefan Schake <stschake@gmail.com> writes:

> On Tue, Nov 14, 2017 at 1:18 AM, Eric Anholt <eric@anholt.net> wrote:
>> Stefan Schake <stschake@gmail.com> writes:
>>
>>> The overflow mem work callback vc4_overflow_mem_work reenables its
>>> associated interrupt upon completion. To ensure all interrupts are disabled
>>> when we return from vc4_irq_uninstall, we need to disable it again if
>>> cancel_work_sync indicated pending work.
>>
>> Is there a reason we need the interrupts disabled at the V3D level while
>> we have the IRQ disabled at the irqchip level?  Once we re-enable at the
>> irqchip, we immediately V3D_WRITE(V3D_INTENA, V3D_DRIVER_IRQS) anyway.
>
> irqchip will mask it in the ARM interrupt controller, so we will certainly never
> see an interrupt. I'm not sure on the exact guarantees V3D_INTENA and
> V3D_INTCTL make - does the state in INTENA affect if V3D will signal an
> interrupt in INTCTL? We're not currently clearing the latter in postinstall.

INTENA/INTDIS writes update the state of the single register that
controls which bits of INTCTL get ORed together to raise the interrupt
outside the V3D block.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Eric Anholt <eric@anholt.net>
To: Stefan Schake <stschake@gmail.com>
Cc: dri-devel@lists.freedesktop.org,
	linux-rpi-kernel@lists.infradead.org,
	David Airlie <airlied@linux.ie>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] drm/vc4: Ensure interrupts are disabled
Date: Tue, 14 Nov 2017 11:44:41 -0800	[thread overview]
Message-ID: <87zi7o8x1y.fsf@anholt.net> (raw)
In-Reply-To: <CAOZHkRxf_puuVOoUUnbQ_mM92=pA5Mzoi4_LtJ8BKRnmau-HYg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]

Stefan Schake <stschake@gmail.com> writes:

> On Tue, Nov 14, 2017 at 1:18 AM, Eric Anholt <eric@anholt.net> wrote:
>> Stefan Schake <stschake@gmail.com> writes:
>>
>>> The overflow mem work callback vc4_overflow_mem_work reenables its
>>> associated interrupt upon completion. To ensure all interrupts are disabled
>>> when we return from vc4_irq_uninstall, we need to disable it again if
>>> cancel_work_sync indicated pending work.
>>
>> Is there a reason we need the interrupts disabled at the V3D level while
>> we have the IRQ disabled at the irqchip level?  Once we re-enable at the
>> irqchip, we immediately V3D_WRITE(V3D_INTENA, V3D_DRIVER_IRQS) anyway.
>
> irqchip will mask it in the ARM interrupt controller, so we will certainly never
> see an interrupt. I'm not sure on the exact guarantees V3D_INTENA and
> V3D_INTCTL make - does the state in INTENA affect if V3D will signal an
> interrupt in INTCTL? We're not currently clearing the latter in postinstall.

INTENA/INTDIS writes update the state of the single register that
controls which bits of INTCTL get ORed together to raise the interrupt
outside the V3D block.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2017-11-14 19:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-10  1:05 [PATCH 0/2] drm/vc4: Correctly uninstall interrupts Stefan Schake
2017-11-10  1:05 ` Stefan Schake
2017-11-10  1:05 ` [PATCH 1/2] drm/vc4: Account for interrupts in flight Stefan Schake
2017-11-10  1:05   ` Stefan Schake
2017-11-14  0:59   ` Eric Anholt
2017-11-14  0:59     ` Eric Anholt
2017-11-10  1:05 ` [PATCH 2/2] drm/vc4: Ensure interrupts are disabled Stefan Schake
2017-11-10  1:05   ` Stefan Schake
2017-11-14  0:18   ` Eric Anholt
2017-11-14  0:18     ` Eric Anholt
2017-11-14 11:43     ` Stefan Schake
2017-11-14 19:44       ` Eric Anholt [this message]
2017-11-14 19:44         ` Eric Anholt
2017-11-14 23:18         ` Stefan Schake
2017-11-14 23:18           ` Stefan Schake

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=87zi7o8x1y.fsf@anholt.net \
    --to=eric@anholt.net \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=stschake@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.