On 02/04/2025 11:58, Boris Brezillon wrote:
> On Wed, 2 Apr 2025 11:20:17 +0100
> Steven Price wrote:
>
>>> static void panthor_mmu_irq_handler(struct panthor_device *ptdev, u32
>>> status)
>>> {
>>> bool has_unhandled_faults = false;
>>>
>>> status = panthor_mmu_fault_mask(ptdev, status
On Wed, 2 Apr 2025 11:20:17 +0100
Steven Price wrote:
> > static void panthor_mmu_irq_handler(struct panthor_device *ptdev, u32
> > status)
> > {
> > bool has_unhandled_faults = false;
> >
> > status = panthor_mmu_fault_mask(ptdev, status);
> > while (status) {
> > u32 a
On Wed, 2 Apr 2025 11:20:17 +0100
Steven Price wrote:
> On 01/04/2025 19:23, Boris Brezillon wrote:
> > MMU handler needs to be in control of the job interrupt clears because
> > clearing the interrupt also unblocks the writer/reader that triggered
> > the fault, and we don't want it to be unbloc
On 01/04/2025 19:23, Boris Brezillon wrote:
> MMU handler needs to be in control of the job interrupt clears because
> clearing the interrupt also unblocks the writer/reader that triggered
> the fault, and we don't want it to be unblocked until we've had a chance
> to process the IRQ.
>
> Since cl
On Tue, Apr 01, 2025 at 08:23:47PM +0200, Boris Brezillon wrote:
> MMU handler needs to be in control of the job interrupt clears because
> clearing the interrupt also unblocks the writer/reader that triggered
> the fault, and we don't want it to be unblocked until we've had a chance
> to process t
MMU handler needs to be in control of the job interrupt clears because
clearing the interrupt also unblocks the writer/reader that triggered
the fault, and we don't want it to be unblocked until we've had a chance
to process the IRQ.
Since clearing the clearing is just one line, let's make it expl
