From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Date: Fri, 9 Oct 2015 15:44:08 +0200 Subject: [U-Boot] [PATCH 3/7] sunxi: power: Unify axp pmic function names In-Reply-To: <1444394488.1410.371.camel@hellion.org.uk> References: <1443882383-21181-1-git-send-email-hdegoede@redhat.com> <1443882383-21181-3-git-send-email-hdegoede@redhat.com> <56103783.2090105@redhat.com> <1444379501.1410.280.camel@hellion.org.uk> <5617A3EB.5070001@redhat.com> <1444394488.1410.371.camel@hellion.org.uk> Message-ID: <5617C4A8.8060800@redhat.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, On 09-10-15 14:41, Ian Campbell wrote: > On Fri, 2015-10-09 at 13:24 +0200, Hans de Goede wrote: >> Hi, >> >> On 09-10-15 10:31, Ian Campbell wrote: >>> On Sat, 2015-10-03 at 22:16 +0200, Hans de Goede wrote: >>>> Hi, >>>> >>>> On 03-10-15 16:32, Chen-Yu Tsai wrote: >>>>> On Sat, Oct 3, 2015 at 10:26 PM, Hans de Goede >>>>> >>>>> wrote: >>>>>> Stop prefixing the axp functions for setting voltages, etc. with >>>>>> the >>>>>> model number, there ever is only one pmic driver built into u >>>>>> -boot, >>>>>> this allows simplifying the callers. >>>>> >>>>> Hmm... What's going to happen with the A80, which has 2 PMICs? IIRC >>>>> a subset of their LDOs share the same name, which would be a >>>>> problem. >>>> >>>> My plan for that is to use a different function name for the ldo-s >>>> on the secondary pmic, e.g. something like axp2_set_xldo1(...), or >>>> somesuch. Actually this patch should help adding support for the >>>> other pmics since it will make it less of an #ifdef fest. >>> >>> Is it going to be (or very likely to be) the case that a given AXPxxx >>> device will only ever be a primary or a secondary, but never used as >>> both >>> (perhaps on different boards)? >> >> AFAIK that is correct, there are different axp models for primary / secondary >> pmics. > > OK, that makes sense, but then this: > >> Some a80 / a83 boards may only use the primary pmic, but using only >> the secondary is not really expected. > > ... makes me want to clarify, since I understand that having a secondary > but not a primary would be rather strange and wasn't what I was getting at. > > What I meant was for a given AXPxxx is that model only ever either used as > a primary _or_ used as a secondary (with some other AXPabc as the primary). > I think your answer further above is telling me that yes, a given AXPxxx is > either designed (and used) as a primary or a secondary. > > From the patch #1 discussion (since it is predicated on the above and > splitting the conversation in two will probably just get confusing): > >>> ... these three ought to be inside a choice? >> >> I was thinking the same, but on A80 boards there are 2 >> different axp chips, so if we make this a choice now we >> just end up needing to revert this when we get full A80 support. > > But one of those would be a primary and the other a secondary, and as > discussed above (as I currently understand it at least) each > CONFIG_AXPxxx_POWER can be a primary XOR a secondary. > > In which case what we would want is a set of choice options for primary and > a separate set choice options for secondary (with a none option too in this > case) and there would be no duplication of any specific AXPxxx option > between both the primary and secondary sets. Ah Yes, from what we now know / expect about how things will work on boards with 2 pmics that is correct. I'll respin the first patch to change things into a choice including a none option. Regards, Hans