[Letux-kernel] [PATCH RFC] w1: omap: disable iclk autoidle

Andreas Kemnade andreas at kemnade.info
Tue Oct 2 23:37:40 CEST 2018

Hi Tony,

On Mon, 1 Oct 2018 07:47:45 -0700
Tony Lindgren <tony at atomide.com> wrote:

> * Andreas Kemnade <andreas at kemnade.info> [180929 22:39]:
> > +	 * needed to disable autoidle, if system power state is too low
> > +	 * hdq transactions will not work correctly, although registers
> > +	 * are accessible.
> > +	 * According to AM/DM3730 TRM p.2879 the hwmod has to way to
> > +	 * keep iclk running during a transfer if autoidle is enabled  
> 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.
If there is a qos request with latency 10, power consumption
increases even in the case when uarts are active by around 35mA.
I do not see any such increase if I keep that autoidle bit clear and
disable runtime suspend for hdq.
So the qos stuff does keep active more things when needed (of course
such a qos request should be removed if not needed anymore, that was
just for testing). And also the required latency values are quite
We have at least 190µs per bit transferred if I understand things right,
and we are getting an interrupt for every byte we transfer.
To me it feels like doing random things to make things work.
A flag in omap_hwmod_3xxx_data.c to disable iclk autoidle would feel a
lot better.
I will repeat my tests.

BTW: It is enough to idle uart 0 and 1 to have the problem, the others
can be active (well, they belong to other domains).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20181002/8470fd63/attachment.asc>

More information about the Letux-kernel mailing list