public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 3/7] sunxi: power: Unify axp pmic function names
Date: Fri, 9 Oct 2015 15:44:08 +0200	[thread overview]
Message-ID: <5617C4A8.8060800@redhat.com> (raw)
In-Reply-To: <1444394488.1410.371.camel@hellion.org.uk>

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 <hdegoede@redhat.com
>>>>>>
>>>>> 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

  reply	other threads:[~2015-10-09 13:44 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-03 14:26 [U-Boot] [PATCH 1/7] sunxi: Kconfig-ify CONFIG_AXP152_POWER and _AXP209_POWER Hans de Goede
2015-10-03 14:26 ` [U-Boot] [PATCH 2/7] sunxi: power: Make all voltages configurable through Kconfig Hans de Goede
2015-10-09  6:56   ` Ian Campbell
2015-10-03 14:26 ` [U-Boot] [PATCH 3/7] sunxi: power: Unify axp pmic function names Hans de Goede
2015-10-03 14:32   ` Chen-Yu Tsai
2015-10-03 20:16     ` Hans de Goede
2015-10-09  8:31       ` Ian Campbell
2015-10-09 11:24         ` Hans de Goede
2015-10-09 12:41           ` Ian Campbell
2015-10-09 13:44             ` Hans de Goede [this message]
2015-10-09 14:24               ` Ian Campbell
2015-10-09 14:49             ` Chen-Yu Tsai
2015-10-11 11:14   ` Ian Campbell
2015-10-03 14:26 ` [U-Boot] [PATCH 4/7] sunxi: power: Change A23/A33 VDD-SYS default from 1.2V to 1.1V Hans de Goede
2015-10-09  8:33   ` Ian Campbell
2015-10-10 14:13   ` Chen-Yu Tsai
2015-10-11 11:17     ` Hans de Goede
2015-10-03 14:26 ` [U-Boot] [PATCH 5/7] sunxi: power: Change A23/A33 aldo1 default voltage to 3.0V Hans de Goede
2015-10-09  8:34   ` Ian Campbell
2015-10-03 14:26 ` [U-Boot] [PATCH 6/7] sunxi: power: Use pmic_bus functions for axp152 / axp209 driver Hans de Goede
2015-10-09  8:36   ` Ian Campbell
2015-10-03 14:26 ` [U-Boot] [PATCH 7/7] sunxi: power: Drop protection against multiple calls from axp221 axp_init() Hans de Goede
2015-10-09  8:36   ` Ian Campbell
2015-10-09  6:49 ` [U-Boot] [PATCH 1/7] sunxi: Kconfig-ify CONFIG_AXP152_POWER and _AXP209_POWER Ian Campbell
2015-10-09 11:20   ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5617C4A8.8060800@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox