[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87zi7o8x1y.fsf@anholt.net>
Date: Tue, 14 Nov 2017 11:44:41 -0800
From: Eric Anholt <eric@...olt.net>
To: Stefan Schake <stschake@...il.com>
Cc: dri-devel@...ts.freedesktop.org,
linux-rpi-kernel@...ts.infradead.org,
David Airlie <airlied@...ux.ie>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] drm/vc4: Ensure interrupts are disabled
Stefan Schake <stschake@...il.com> writes:
> On Tue, Nov 14, 2017 at 1:18 AM, Eric Anholt <eric@...olt.net> wrote:
>> Stefan Schake <stschake@...il.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.
Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)
Powered by blists - more mailing lists