Re: OMAP baseline test results for v3.9-rc3

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

 



On Tue, 2013-03-26 at 18:43 +0000, Paul Walmsley wrote:
> Hi.
> 
> On Tue, 19 Mar 2013, Tero Kristo wrote:
> 
> > I think you should definitely upgrade your bootloader, the old one you
> > are using is prone to cause trouble due to bugs it has, and we have no
> > simple way to workaround the issues it causes on kernel side.
> 
> So, the kernel should be independent of the bootloader that's used.  Many 
> of the rest of us have taken great care to ensure that devices get reset 
> to do this.  We've got pretty good coverage on OMAP3 and most of the other 
> OMAP4 IP blocks.
> 
> You mention that there's no simple way to do it, but as far as I know, no 
> one has assessed what's needed to reset the remaining devices.  Or if 
> someone has this information, it hasn't been shared here - please do so.
> 
> So what I'd like you to do is:
> 
> 1. Determine what devices are remaining to be reset and idled on OMAP4 
>    with the bootloader that I use.  As far as I know, there are only four 
>    that block full-chip idle: M3, DSP, SL2IF, FSUSB
> 
> 2. Determine what's needed to reset and idle them.  For the M3 and DSP, 
>    I'd assume this involves pointing the reset vector for those 
>    processors at a few lines of code that basically enter WFI or the C64x 
>    equivalent.

This is the nasty part. We need firmware support for the blocks to do
this, and this is imo a complete overkill for the task at hand, as it
will duplicate the DSP + M3 firmware and drivers at least partially. On
OMAP3, it was easy as you could just setup the boot mode for IVA and get
over with it. We don't have similar luxury on OMAP4.

If there was a simple way to do this, don't you think this would have
been done already a year back when we started to discuss this first
time? And, a year old bootloader is ancient seeing we didn't have any
kind of support for OMAP4 core idle in mainline back then and this
feature was essentially completely untested.... nobody cared about the
upstream u-boot PM compatibility before that.

-Tero

> 
> 3. At this point, we can determine the difficulty level of the task.
> 
> 4. Then, assuming it's of the level described in step 2, that reset/idle 
>    code should be implemented.
> 
> This process will ensure both that users with "old" OMAP4 bootloaders -- 
> really, u-boot versions distributed less than a year ago, so not very old 
> at all -- will be able to successfully enter chip low power states.  It 
> will also ensure that users who boot to new kernels with kexec will be 
> able to do so successfully, with a minimum of interference from other 
> devices.
> 
> 
> - Paul
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[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