From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lubomir Popov Date: Thu, 06 Jun 2013 15:17:09 +0300 Subject: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1 In-Reply-To: <51B071FB.5060601@ti.com> References: <1369919979-26497-1-git-send-email-lokeshvutla@ti.com> <1369919979-26497-10-git-send-email-lokeshvutla@ti.com> <51A7617B.8040503@mm-sol.com> <51AC7790.8010600@ti.com> <5573fc255a96bc1866e356d767a2b44b.squirrel@www.mm-sol.com> <20130604210631.GA10720@bill-the-cat> <51AEF0CE.1000500@mm-sol.com> <20130605134555.GU10720@bill-the-cat> <51B0395F.7050401@mm-sol.com> <51B071FB.5060601@ti.com> Message-ID: <51B07DC5.7010505@mm-sol.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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