Add fixed voltage regulators to audio overlays using pcm512x, wm8804 and adau1977 codecs

[clivem]

Phil/Dom, feel free to close straight away if you want without pulling. But if you ever do enable REGULATOR, you might want to have these reg defs already in the overlays affected.

CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=m

This stops the codecs using regs, (specifically pcm512x and wm8804), from refusing to load because they cant find the necessary regs.

[kukabu]

I think better way writes two overlay pcm512x-regulator-overlay, wm8804-regulator-overlay and them included in codec overlays.

[HiassofT]

@clivem you also need to reference the regulators in the codec DT nodes.

Note that the supply prroperties are required, not optional, as per the devicetree binding documentation. See for example
https://github.com/raspberrypi/linux/blob/rpi-4.4.y/Documentation/devicetree/bindings/sound/pcm512x.txt

So it can be argued that the current overlays are broken and need fixing anyways.

BTW: you don't need to define multiple regulators, one per voltage is enough (even a single one for all voltages would do to make DT and the regulator core happy). eg something like this:

...
reg_3v3: fixedreg@0 {
    compatible = "regulator-fixed";
    regulator-name = "DC_3V3";
    regulator-min-microvolt = <3300000>;
    regulator-max-microvolt = <3300000>;
    regulator-always-on;
};
...
pcm5122@4c {
...
    AVDD-supply = <&reg_3v3>;
    DVDD-supply = <&reg_3v3>;
    CPVDD-supply = <&reg_3v3>;
};

[pelwell]

@clivem Thanks - this could be a useful resource.

@HiassofT Thanks also for your input.

Both - it's a tremendous help having guidance from specialists in the field.

@kukabu No, I think this is the correct approach, because we don't want all users to have to change the name of the overlay they use in order to continue using their soundcard just because we've enabled regulators. However, this PR is something we will keep around until the day that regulators are enabled, at which point we'll merge it.

[clivem]

@HiassofT Matthias, is that OK?

EDIT: By which I mean, is it done in an upstream compatible way? (I know it works. Tested on HB digi and IQ pcm512x. "fixed" regulator module auto-loaded, no complaints from drivers, and music playing. ;))

[HiassofT]

I think it'd be best to move the 3.3v regulator definition to bcm2708_common.dtsi - or some common file that's included by all RPi boards. The RPis have a fixed 3.3V regulator on board and most of the system and addon cards are running off that, so the regulator should be part of the board definition.

Not sure under which root node it should be anchored ("/regulators", "/motherboard" maybe?) but I'm pretty sure there's some convention for that.

Ping @pelwell I think you are more familiar with the conventions used in the (RPi) devicetree structure than I am

[pelwell]

Under /regulators seems to be the convention, but I haven't found the edict that says so.

[clivem]

@HiassofT @pelwell This is where I think we have gotten to, if we were going to use and enable the regulator framework for these audio boards..... Comments?????

[pelwell]

I like it. It's as neat as it's going to get, and without checking each of the codecs and their regulator requirements I don't see anything wrong with it.

[HiassofT]

Thanks, looks fine to me, too!

While we're at it I think it might make sense to register a 5V fixed regulator as well - just to be prepared if some HAT or onboard component is going to require this.

[clivem]

Do we want to add a def for 1V8 as well while we are at it? ISTR, the chap trying to merge that Fe-Pi, had a 1V8 def for his LDO reg. On second thoughts, might be better for everything other than the 3.3V and 5V, to be kept in the overlays. ;)

[HiassofT]

The 1V8 reg in that codes seems to be a "real" regulator that'll be switched on/off as needed - that needs to be properly setup in the specific DT overlay/driver.

Only 5V and 3V3 fixed rails are available on the RPi board, so it's sufficient to add these to the DT.

[clivem]

The 1V8 reg in that codes seems to be a "real" regulator that'll be switched on/off as needed

I didn't actually look at it again, just had it in the back of my mind from way back when, (sgtl5000 on Wandboard), regulator was 1V8. Also had it in mind that DVDD can be either 1V8 or 3V3 for PCM512x.
Anyway, all moot. As you say, only 3V3 and 5V0 supplies should be in the core board def.

[clivem]

I've just done a quick test with the patch applied and ...

CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=m

.... on B, B+, Zero, 2B, 3B and various HB and IQ boards attached, that use the regs. All looks good.
Later, I'll leave the patch applied but disable the CONFIG_REGULATOR options on a new build. If it doesn't cause anything to break, the patch could be applied now to rpi-4.4.y, without enabling regulator framework, but it would mean at the point regulator options are enabled in the future, (and I suspect they will be), everything wont "go to hell in a hand cart". And as @HiassofT already pointed out, the supplies aren't supposed to be optional properties, they should be in the dt config, even if so far we have got away with not having them there, because regulator framework hasn't been enabled.

[clivem]

@pelwell Of course, up to you, but having tested this patch with and without enabling regulator framework, I cannot find a reason for not wanting to apply it now, even if you don't intend to enable regulator framework now.
@HiassofT Can you think of any reason why applying this now, without enabling CONFIG_REGULATOR, will come back and bite us on the bum?

[HiassofT]

I think it would make more sense to apply with the regulator framework enabled so if something breaks we notice that immediately, not a few months later when we may have forgotten about this.

@pelwell @popcornmix are there plans to revive firmware-next to test new features? This PR would be a good candidate IMHO.

@clivem Otherwise a PR on the 4.6 tree might make sense, that one is used by Milhouse for his LibreELEC builds so it'll get some test coverage.

[pelwell]

Re: BRANCH=next

I've created a "next" branch in the kernel tree so that it can be an alternative branch using the same kernel version, rather than having to be the next version, but we were waiting for a candidate implementation of the ARM-side clock manager that works with I2S audio before making the first release. However, I've got no problem cleaning the pipes with this small patch.