Re: [PATCH RFC] w1: omap: disable iclk autoidle

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Tony,


On Mon, 1 Oct 2018 07:47:45 -0700
Tony Lindgren <tony@xxxxxxxxxxx> wrote:

> * Andreas Kemnade <andreas@xxxxxxxxxxxx> [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
strange.
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).

Regards,
Andreas

Attachment: pgpTL8d7WuZ3x.pgp
Description: OpenPGP digital signature


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux