Hi Lokesh, On 06/06/13 14:26, Lokesh Vutla wrote: > Hi Lubomir, > On Thursday 06 June 2013 12:55 PM, Lubomir Popov wrote: >> Hi Tom, >> >> On 05/06/13 16:45, Tom Rini wrote: >>> On Wed, Jun 05, 2013 at 11:03:26AM +0300, Lubomir Popov wrote: >>> [snip] >>> >>> OK, lets see. That so lets keep your patch as-is, since we've now got >>> -ffunction-sections/-fdata-sections/--gc-sections on ARM for main >>> U-Boot, these small things won't hurt like they used to. >>> >> OK, but then I would like to do some cleanup first - remove the audio >> power stuff (shall have it in my board file), as well as either sort out >> the function naming: >> >> - Those functions that are specific to a SoC+PMIC combination are >> named e.g. twl603x_... or tps659038_... so that they explicitly >> indicate the hardware that they are working with (actually almost all >> functions are such). This is however sort of regression, and requires >> fixes in the files calling these functions; >> >> or, alternatively: >> >> - Introduce generic functions with fixed names, palmas_bla_bla(), >> sort of wrappers, which in their bodies perform the appropriate action >> based on the #ifdefs defining the platform hardware (where we could also >> define the particular LDO which for example a palmas_mmc1_poweron_ldo() >> generic function would manipulate). Drawback: again #ifdefs. >> Advantage: single place where this stuff is located, and where other >> PMIC/LDO combinations can be added without affecting other code. > I think, we can have function pointers for and can populate data in the > beginning or from board file based on Soc, similarly what we did for > prcm structure. > Regards, > Lokesh OK, sounds reasonable. I think this should be done in a future release however, after careful investigation and planning. At present, I guess, we are staying with the current situation.
Today I shall submit an updated version of my patch to the palmas driver - sort of compromise between clean code and ease of use. I have included your stuff there, so should work out of the box on the dra7xx_evm. Please note that now we have a semi-generic function to power on the appropriate SDMMC LDO: the old palmas_mmc1_poweron_ldo(), which you shall have to call in omap_hsmmc. Differentiation of which particular LDO to control within which PMIC is done in driver, based on the board #ifdefs. If Tom approves this patch and applies it, we shall all be happy with working boards, although the code may not be perfect. I would also like to ask you to send me a Register Manual of the TPS659038/9, if possible. If you have any NDA concerns, then just check if the LDO1 control register has a BYPASS option and tell me. Thanks. Best regards, Lubo _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
