[U-Boot] [PATCH V2] OMAP5: Power: Add more functionality to Palmas driver

menon.nishanth at gmail.com menon.nishanth at gmail.com
Thu May 16 22:45:38 CEST 2013


On Thu, May 16, 2013 at 3:14 PM, Lubomir Popov <lpopov at mm-sol.com> wrote:
>> On Thu, May 16, 2013 at 2:03 PM, Lubomir Popov <lpopov at mm-sol.com> wrote:
>>> Well, I needed it when bringing up the board ;) - to validate the
>>> supplies, clocks, etc. Right, this function should be embraced within a
>>> #ifdef CONFIG_PALSMAS_AUDPWR and not compile in the general case (my
>>> code
>>> calling it is #ifdef-ed anyway).
>> Right, and you need u-boot modified to do validation? I think either
>> such code should stay out of tree, or be validated by expicit i2c
>> commands (which already is supported) OR tested by virtual regulator
>> consumer in linux ;)
>>
>> I dont think we should make u-boot an OS. just my 2 cents. my rule of
>> thumb is: if it is not needed for boot, do it elsewhere other than
>> bootloader.
> Yes, TI has omapboot, just a bootloader. I think that U-Boot, on the other
> hand,
> has become a quite powerfull tool, with a lot of useful functionality, at
> least for
> me as a hardware guy. But of course, if the community thinks of it as of a
> bootloader only, I give up. ;)
Lets not forget it is a bootloader. there are gazillion options -
barebox, uboot, vendor specific ones like omapboot etc.
U-boot is primarily a bootloader. It provides excellent testing
interfaces which are useful for preliminary testing. However stuff
like Audio power chip LDO supply enable when not really used, makes no
real sense in my opinion.

Sure you can use u-boot to validate with the i2c commands available -
hell, you can even write your own uEnv.txt or bootcmd which will do a
bunch of validation at boot.. but why have it in mainline u-boot is
beyond me.

Regards,
Nishanth Menon


More information about the U-Boot mailing list