Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init

["Cousson, Benoit" <b-cousson@ti.com>]

On 5/29/2011 11:04 PM, Steve Calfee wrote:
> On Fri, May 27, 2011 at 12:38 PM, Kevin Hilman<khilman@ti.com>  wrote:
>> "Cousson, Benoit"<b-cousson@ti.com>  writes:
>>
>> [...]
>>
>>> In general we do not want to reset nor idle an IP that was potentially
>>> already properly configured by bootloader or early Linux boot code.
>>
>> Actually, the opposite is true.
>>
>> The kernel should not make any assumptions about what the bootloader has
>> or has not done.  We need to have a kernel that can boot from any
>> bootloader (or none, like using kexec) and be able to start from a known
>> hardware state.
>>
> YES. Bootloaders should only do what is necessary (set clocks, enable
> memories etc) to load the next stage. Pushing stuff that should be in
> the kernel into the bootloader (like iniiting gpios and other things)
> bloats it and makes a developer deal with two entirely different
> source trees (kernel and booterx) to enable a new feature or to fix
> bugs.
>
> Uboot tends to lag the kernel in capabilities too, probably because
> fewer developers or something. For instance Beagleboard xm uboot
> cannot access the ethernet because it is usb based, and uboot cannot
> access its own environment in flash - because it is running from a new
> microsd based flash system. U-boot will eventually catch up with
> these, but by then other new hardware will be available.
>
> Does anyone know if 2.6.39 has kexec working again for the kernel? NFS
> boot is a dream development environment but with both u-boot and kexec
> not working with nfs, it is slightly more work and less automated.

I apologize for the confusing message in my answer.

The default behavior of the hwmod fmwk is to reset every IPs in order to 
ensure a stable and known state. The HWMOD flags should only be used in 
case of broken reset in an IP. That's why hacking the GPIO flag in that 
case is wrong.

That being said, you cannot prevent a board manufacturer to do some 
hacks in its bootloader, because it is require for proper voltage like 
here or because he wants to enable a splash screen and do not want to 
have ugly artifact on the screen due to asynchronous reset of the DSS.

In that case, it might be desirable to allow the board file to prevent 
such blind reset at boot time. Hence the need for a board level 
mechanism to change that default behavior.

Bootloader sucks, but you cannot prevent people to use them:-(

In an ideal world, the bootloader will not do anything, and everything 
will be perfectly handled by the kernel...

Benoit