On Thu, 12 Jan 2012, NeilBrown wrote:
> On Wed, 11 Jan 2012 06:43:04 -0700 (MST) Paul Walmsley <[email protected]> wrote:
>
> Not off-mode - just retention.
Okay. It's expected that the UART will drop the first byte also when CORE
is in retention, due to the delay involved in waking up the chip. But
that shouldn't prevent the MPU from going into a low-power state. I've
sent a patch under separate cover that should fix this.
> > If the former, this is hardly surprising as the HDQ driver
> > (drivers/w1/masters/omap_hdq.c) doesn't contain any context save/restore
> > code. In fact the HDQ driver doesn't even use PM runtime, so quite a bit
> > of work is needed there.
>
> The HDQ driver does enable/disable the iclk and fclk. I thought I read that
> having the clocks enabled would prevent the powerdomain from dropping to a
> lower-power state ??
Several years ago, we started handling all of the operations needed to
quiesce and wake an IP block in a common integration layer called 'hwmod',
which is currently called through the PM runtime functions. This includes
clk_{enable,disable}(). Unfortunately, due to some internal political
reasons, not all of our drivers are converted to use PM runtime functions
yet. You just happened to hit one that isn't -- apparently very few
people care very much about this driver...
> Could you suggest some other driver which does do the right sort of runtime
> PM that I could try copying?
I did a quick conversion for you. The series is at
git://git.pwsan.com/linux-2.6 in the branch named 'hdq_hwmod_runtime_pm'.
Please let me know if it works.
I did boot-test it, and noticed that the hwmod subsystem was unable to
softreset the device:
[ 0.182769] omap_hwmod: hdq: softreset failed (waited 10000 usec)
This could be because I screwed up something in the hwmod data, or it
could be that the HDQ reset hardware doesn't work correctly, similar to
I2C. If that presents a problem, you might add the HWMOD_INIT_NO_RESET
flag to the struct omap_hwmod.flags field for the HDQ.
It also spit out these messages later, but I have no idea what they mean.
At least the kernel seems to be able to access the HDQ registers:
[ 1.685272] omap_hdq omap_hdq: OMAP HDQ Hardware Rev 0.5. Driver in
Interrupt mode
[ 1.888153] w1_master_driver w1_bus_master1: Family 1 for
01.000000000000.3d is not registered.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
