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

[Jassi Brar]

On Mon, Jul 15, 2024 at 4:45 AM Jason-JH Lin (林睿祥)
<Jason-JH.Lin at mediatek.com> wrote:
>
> Hi Jassi,
>
> > > You mean _with_ the api patches. right? Because I had suggested
> > > "Over
> > > your patchset, apply the following diff ..."
> >
> > No matter __with__ or __without__ the api patches, autosuspend didn't
> > work...
> >
> > We have to find out the reason __without__ the api patches, then see
> > if
> > we still need the api patches to fix "calling sleep in atomic
> > context"
> > problem.
> >
>
> I found that the reason autosuspend didn't work was that I added the
> devece_add_link() locally between the drm device and the mbox device.
>
> After removing that change, the mailbox device of display can
> autosuspend as expected. So the current autosuspend function is fine.
>
> And the mailbox device of display has the same BUG report like imgsys.
>
>
> Here is the log after removing the local change of device link and
> without the PM api patches:
>
....
That is the log of your some w.i.p code... it does not trace
mbox_send_message() which is where users call the api.  You trace
cmdq_mbox_send_data() , i.e, the api calls the driver.

Even here, the minimum send_diff (time between two cmdq_mbox_send_data
calls) is 32ms. The minimum resume_diff is 540ms, which means you
suspend for at least 540ms.  Also you don't expect these times to
change even with the changed api, do you?

At these timescales, you could very well release-acquire the channel
resource because that cost is ~0ms for your driver. That will not only
be the right thing to do but also avoid opening another can of worms
by adding some ad-hoc api that works only on your platform.

Thanks
Jassi