Re: [PATCH 0/5] extra module resets to ensure full-chip idle

[Kevin Hilman <khilman@deeprootsystems.com>]

Dirk Behme <dirk.behme@googlemail.com> writes:

> Kevin Hilman wrote:
>> Various bootloaders have been known to leave modules in a state
>> which prevents full-chip retention.  
>
> Does it make sense to check if
>
> [PATCH 1/5] OMAP3: PM: HSMMC: force MMC module reset on boot
> [PATCH 2/5] OMAP3: PM: Force IVA2 into idle during bootup
>
> can be done in U-Boot, too? If yes, I would have a look to it.

Yes, ideally u-boot or whatever bootloader isused should 
be leaving these modules in a known reset/idle state.

However, there are many bootloaders for many platforms out there so
until there is some sort of standard on bootloaders, I think the
kernel will have to ensure this is done.

Kevin

>
>> This series forces
>> MMC, IVA2 and D2D/modem into known reset/idle states so that
>> the OMAP3 can hit full-chip idle.
>>
>> Tested on OMAP3 Beagle, and custom OMAP3 hardware.
>>
>> NOTE: this is similar to the set I posted for the PM branch
>>       but this series is rebased onto linux-omap and includes
>>       the MMC reset.
>>
>> Kevin Hilman (5):
>>   OMAP3: PM: HSMMC: force MMC module reset on boot
>>   OMAP3: PM: Force IVA2 into idle during bootup
>>   OMAP3: PM: Add D2D clocks and auto-idle setup to PRCM init
>>   OMAP3: PM: D2D clockdomain supports SW supervised transitions
>>   OMAP3: PM: Ensure modem is reset during PRCM init
>>
>>  arch/arm/mach-omap2/clock34xx.h           |   37 +++++++++++++-
>>  arch/arm/mach-omap2/clockdomains.h        |    2 +-
>>  arch/arm/mach-omap2/cm-regbits-34xx.h     |   14 +++++
>>  arch/arm/mach-omap2/devices.c             |   76 +++++++++++++++++++++++++++++
>>  arch/arm/mach-omap2/pm34xx.c              |   65 ++++++++++++++++++++++++-
>>  arch/arm/plat-omap/include/mach/control.h |    5 ++
>>  6 files changed, 195 insertions(+), 4 deletions(-)
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>