* Andreas Kemnade <andreas@xxxxxxxxxxxx> [181002 21:42]:
> On Mon, 1 Oct 2018 07:47:45 -0700
> Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> > Sounds like hdq1w is not wake-up capable and the uart is blocking
> > deeper SoC idle states. To me it seems that you should rather just
> > use pm_qos in the hdq1w driver to block SoC idle for the duration
> > of transfers.
> >
> > We had a similar problem with audio playback glitches a while
> > back, see commit 9834ffd1ecc3 ("ASoC: omap-mcbsp: Add PM QoS
> > support for McBSP to prevent glitches"). See how it does
> > pm_qos_add_request(), pm_qos_update_request() and
> > pm_qos_remove_request().
> >
> Hmm, that formula for the latency should really be commented.
>
> I experimented with that and the results were strange.
> latency = 100 seems not to be safe.
> latency = 10 seems to be safe.
FYI, the value to pick should in theory be something out of the
latencies in omap3_idle_driver. But that data is for omap34xx,
and 36xx is faster so we really should have separate data for
36xx. Basically you'd want to block anything that cuts off the
clocks, so probably anything retention related.
> If there is a qos request with latency 10, power consumption
> increases even in the case when uarts are active by around 35mA.
OK yeah this will block deeper idle states.
> I do not see any such increase if I keep that autoidle bit clear and
> disable runtime suspend for hdq.
OK
Regards,
Tony
