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

[Jassi Brar]

On Wed, Jun 26, 2024 at 4:32 AM Jason-JH Lin (林睿祥)
<Jason-JH.Lin at mediatek.com> wrote:
> >
> > The idea is that
> > 1) If the gap between transfers on a busy channel is ~10ms or
> > more.  And ..
> > 2) The silence on the mailbox channel is multiple of 100ms. And ...
>
> The mailbox channel would not be always busy and the gap is not
> consistent as well.
> For example, display driver calls mbox_send_message() every ~16ms while
> UI is updating in 60fps.
> If UI dose not update, display driver won't call mbox_send_message(),
> so user may not has the gap and the silence like this.
>
>From your logs, send_diff only increases from 16ms if the UI is not
updating. Which makes it more prudent to release the channel.

The user needs the channel for mbox_send_message, while actual power
saving comes from cmdq_runtime_suspend/resume.
So for your target usage pattern, trace mbox_send_message() ,
cmdq_runtime_resume() and cmdq_runtime_suspend() and compare the
timestamped logs with and without this patchset.

> > 3) startup() and shutdown() are empty (as in your driver)
> >   ... then you could afford to release/suspend and resume/request
> > during the silence period because the _api_ cost of request/release
> > should not even be 1ms. Your stack may be designed to make doing that
> > difficult but numbers wise it should work.
>
> Yes, that's true, but I think we can not achieve the goal during the
> suspend/resume stage.
>
> Currently, we use the pm_runtime_get_sync() and
> pm_runtime_auto_suspend() to achieve this.
> So I think adding the PM function hook in mailbox driver is much better
> for users driver and also more flexible for the controller driver.
>
> Please correct me if there is something I misunderstood :)
>
I have a gut feeling the logs above will make it clear :)

Cheers!