[PATCH 2/2] mailbox: mtk-cmdq: Move pm_runimte_get and put to mbox_chan_ops API

[Jassi Brar]

On Wed, Jun 19, 2024 at 3:18 AM AngeloGioacchino Del Regno
<angelogioacchino.delregno at collabora.com> wrote:
> Il 18/06/24 17:59, Jassi Brar ha scritto:
.....

> For example, when static content is displayed on screen, the CMDQ mailbox never
> gets shut down, but no communication happens for a relatively long time; the
> overhead of actually shutting down the mailbox and setting it back up would be
> increasing latency in an unacceptable manner.
>
Hmm...  in your driver,  startup() is _empty_   and  shutdown() is all
under a spin-lock with irqs disabled, so that too shouldn't be
expensive. Right?
Then what causes unacceptable latencies?

> This is why I opted for autosuspend - it's only bringing down certain clocks for
> the CMDQ HW, adding up a bit of power saving to the mix which, for some use cases
> such as mobile devices with relatively small batteries, is definitely important.
>
> I'll also briefly (and only briefly) mention that 120Hz displays are already a
> common thing and in this case the gap between TX and ACK is ~8.33ms instead, let
> alone that displays with a framerate of more than 120Hz also do exist even though
> they're less common.
>
I don't know how even busier channels help your point.

> All of the above describes a few of the reasons why autosuspend is a good choice
> here, instead of a shutdown->startup flow.
> And again - I can place some bets that PM would also be applicable to SoCs from
> other vendors as well, with most probably different benefits (but still with some
> power related benefits!) compared to MediaTek.
>
Sure, if some platform _actually_ has a high channel
startup()/shutdown() cost, it may need finer PM control. And I have a
way for that, but even with that I am sure someone from MTK will
realize they didn't need that.

Thanks.