Re: [PATCH RFC v5 7/7] media: mali-c55: Sequence resets explicitly

[Jacopo Mondi <jacopo.mondi@ideasonboard.com>]

Hi Linus

On Thu, Nov 05, 2026 at 09:58:09AM +0100, Linus Walleij wrote:
> Hi Prabhakar,
>
> thanks a lot for your help!
>
> On Tue, Nov 3, 2026 at 2:47 PM Lad, Prabhakar
> <prabhakar.csengg@gmail.com> wrote:
>
> > I tested on the RZ/V2H EVK with the clocks and DT left untouched,
> > changing only the reset order.
> >
> > The hang comes from the reset assert order in __mali_c55_power_off().
> > Asserting vresetn (the ISP core reset per the RZ/V2H manual) before
> > hresetn/aresetn wedges the ISP. The next power-on then stalls on its
> > first register access. The deassert order doesn't matter.
>
> OK I will drop the clock patch and keep this one.
>
> > Asserting h->a->v (deasserting v->a->h) passes repeated runtime-PM
> > cycles and also works with the IVC enabled. So 7/7 gives the right
> > reset sequence, 6/7 isn't needed for this, and the existing DT mapping
> > (0xd3 = vresetn = ISP core reset) is correct.
>
> So this is a Tested-by for this patch?
>
> > A smaller alternative keeps the bulk API and only reorders the names:
>
> I guess that works, but I'm not sure the reset bulk API in the
> kernel guarantees any order, so we better keep this patch as-is if

I was under the same impression as I have memories of quite some
conversations around this and I recall a workqueue was used to
schedule bulk reset operations.

Now that I re-looked at the implementation of
reset_control_bulk_deassert() and its history I don't see any trace of
it and the documentation says

 * Deassert the reset lines for all provided reset controls, in reverse order.

Was I hallucinating when I first suggested no ordering was guaranteed ?


> it works so we explicitly show users that this is critical.
>
> Yours,
> Linus Walleij