lkml.org 
[lkml]   [2015]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: multi-codec support for arizona-ldo1 was Re: System with multiple arizona (wm5102) codecs
    On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote:

    > Well, mfd_core.c seems to call regulator_bulk_register_supply_alias()
    > with device that does not have dev_name initialized.

    OK, that'll be the problem then - we're not mapping the supply into the
    individual child device but rather system wide, probably because that
    mapping is being done too early, before we've actually created the
    device.

    > regulator_bulk_register_supply_alias() results in "Adding alias"
    > stuff, and then drivers/regulator/arizona-micsupp.c tries to register
    > another "MICVDD".

    That's fine because all supplies should be namespaced with a device.
    The goal is to say "Supply X on device Y" (we do support exceptions for
    the few cases where there are not yet any devices involved but this
    clearly isn't one of them).

    > And now we have

    > sound/soc/codecs/wm5102.c, around line 1093:

    > @@ -1092,7 +1094,6 @@ SND_SOC_DAPM_SUPPLY("ASYNCOPCLK",
    > ARIZONA_OUTPUT_ASYNC_CLOCK,
    > SND_SOC_DAPM_REGULATOR_SUPPLY("DBVDD2", 0, 0),
    > SND_SOC_DAPM_REGULATOR_SUPPLY("DBVDD3", 0, 0),
    > SND_SOC_DAPM_REGULATOR_SUPPLY("CPVDD", 20, 0),
    > -SND_SOC_DAPM_REGULATOR_SUPPLY("MICVDD", 0, SND_SOC_DAPM_REGULATOR_BYPASS),
    > SND_SOC_DAPM_REGULATOR_SUPPLY("SPKVDDL", 0, 0),
    > SND_SOC_DAPM_REGULATOR_SUPPLY("SPKVDDR", 0, 0),

    > That is the regulator<->alsa interface I'm talking about. But as you

    So if you look at this just templates out some boilerplate regulator API
    client code which calls regulator_get() like any other client and then
    hooks that regulator into the audio power management.

    > may recall, I have 2 arizona chips here, so two wm5102.c instances,
    > and I believe this means that "MICVDD" is not suitable here, and we
    > want something like "MICVDD,spi32766.2" here.

    > But a) code does not seem to be quite ready for that, and b) you said
    > you disliked that approach.

    Please go and look at how regulator clients request their supplies and
    how those get resolved into actual supplies - it's exactly the same
    struct device based namespacing that we use for clocks, PWMs and other
    resources. It's not that I dislike this approach, it's that this
    approach does not make sense in the model we use for requesting supplies
    and is not supported in any way by the code.

    I'm not sure how I can be any clearer that supply names are namespaced
    by client device and that as a result fiddling around with the supply
    name is not going to help anything.

    > > to be on something like the same page here, at the very least I need you
    > > to talk about what code you're looking at and what you don't understand
    > > so I can try to help you follow it but right now I'm just not sure where
    > > to start, it feels like you're trying to treat a lot of the code as a
    > > black box without following the abstractions it provides which makes
    > > things very hard.

    > Well, the code is pretty close to the black box for me :-(.

    How far have you got in trying to follow the code, what specific areas
    are confusing you?

    > Ok, good. I don't understand how the things are expected to fit
    > together. See above. I believe SND_SOC_ macros should have another
    > argument "device", or maybe regulator names should have "device" name
    > embedded in them.

    Regulator names *do* have a device. This is the whole point with
    namespacing by client device.
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2015-11-14 20:01    [W:4.208 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site