Feature request - overlay for remapping audio to GPIO pins

[stefandz]

Hello - this is a follow-up to me showing my ignorance on the forums (and PhilE - who I imagine is @pelwell here) suggesting that I post a request here.

I am trying to remap the PWM audio from the pins connected to the onboard 3.5mm socket to pins 32 and 33 on the GPIO socket. So far I was achieving this by adding the following to /boot/config.txt

dtoverlay=pwm-2chan,pin=12,pin2=13,func=4,func2=4

However, as Phil points out this loads the driver twice (I think) and certainly also leaves audio coming out of the 3.5mm socket. Would it be possible to ask for someone's help in writing an overlay that actually remaps the audio properly? (and that the user can disable if they would like audio back in the normal place)

All help gratefully received.

[P33M]

The preferred method is to rewrite the relevant section in dt-blob.bin (which is primarily Videocore-based GPIO setup on a per-model basis).

The source DTS is here: https://github.com/raspberrypi/documentation/blob/master/configuration/images/dt-blob.dts and it's simple enough to change pin 40/45 to 12/13.

Docs page here tells you how to insert the modified dt-blob: https://www.raspberrypi.org/documentation/configuration/pin-configuration.md

[pelwell]

I woudn't say it was preferred - the dt-blob is a monolithic monstrosity. Edit once and forever have to keep it up-to-date.

All you have to do is choose a DT node that doesn't have an existing pinctrl section and add one - the "audio" node is the obvious one.

It would look something like this (untested):

/dts-v1/;
/plugin/;

/ {
        compatible = "brcm,bcm2708";

        fragment@0 {
                target = <&gpio>;
                __overlay__ {
                        audio_pins: audio_pins {
                                brcm,pins = <40 45 12 13>;
                                brcm,function = <0 0 4 4>; /* in in alt0 alt0 */
                        };
                };
        };

        fragment@1 {
                target = <&audio>;
                __overlay__ {
                        pinctrl-names = "default";
                        pinctrl-0 = <&audio_pins>;
                };
        };
};

[ EDIT: pinctrl-name corrected to pinctrl-names ]

[stefandz]

Thanks for this @pelwell (sorry for the delay in replying!). Am I correct in thinking that I would use the code snippet as a .dts file, before compiling it to a .dtb (with the -@ argument to allow unresolved references), and then getting it onto the /boot partition, along with adding dtoverlay=name-of-device to /boot/config.txt - is that everything? Once I have this debugged I can obviously submit a PR to have it included in future releases of Raspberry Pi Linux I guess, which should filter down to Raspbian.

If I am getting any of this drastically wrong please let me know!

[pelwell]

@stefandz That looks broadly right, with the proviso that different models use different pins for PWM audio. Having said that, I haven't got it to work yet. For reasons I haven't managed to figure out the pinctrl section is being ignored or at least not taking effect. I'll report back when I make some progress.

[karrika]

I have a tested setup for mapping the audio pins to 12, 13. There is also step by step instructions for creating the dt blob and programming it into an eeprom so it works as soon as the HAT is put on top of the RPi. See at the end of the page in http://discohat.com/miscap/.

[pelwell]

Thanks for the suggestion. By the looks of it I'd say that works almost by accident. What you are doing is enabling the PWM driver, which is not the same as the PWM audio driver - just basic perod+duty cycle stuff. But by getting it to request the PWM function on pins 12 & 13 you are achieving the objective. What I'm trying to do is get the pins assigned to the audio node.

I'm also concerned that your overlay leaves the PWM functions multiply mapped, although it appears to be working for you. Once I've got pins allocated for the audio node I'll get the standard DTBs to request the per-platform standard pins, then all an overlay would have to do is overwrite those pin assignments.

[karrika]

Thank you for the feedback. As a normal user I did not understand the difference between pwm and audio node. I have to change the src to use audio node instead. Perhaps later today when I get home. It would be nice to do things correctly.

[stefandz]

Thank you everyone for your valuable (and generous) time contributions to this. If there's anything I can be doing to help, please let me know! BTW, I really like your HAT, @karrika 👍

[pelwell]

Duh! It really helps if you call the property pinctrl-names (note the plural); with that change, it works as expected. I've edited the post above to correct it.

I'll have a think about the best way to make this work on all platforms. My current proposal is:

1. Add audio_pins to the base DTBs.
2. Add parameters to modify them.
3. Get the firmware to use those parameters to select the pins.
4. Make the firmware use the DT audio_pins values when setting the initial pin functions. The intention is make the system act as if the audio pins were inputs before the kernel starts (i.e. no need to restore the usual pins to inputs), but still set the pin functions in the firmware in case other OSs rely on it.

[pelwell]

The firmware change for this went in at the end of last month. I've now pushed the DTB changes that define the audio_pins node for all the Pi models with audio outputs, to be picked up by the next build.

With these in place, the overlay required to remap the output to 12 & 13 now looks like this:

/dts-v1/;
/plugin/;

/ {
        compatible = "brcm,bcm2708";

        fragment@0 {
                target = <&audio_pins>;
                __overlay__ {
                        brcm,pins = <12 13>;
                        brcm,function = <4>; /* alt0 */
                };
        };
};

Note that you can also disable the PWM output with an empty "brcm.pins" property.

[stefandz]

Thanks very much for this @pelwell (and everyone else involved). I will try testing this out today on as many platforms as I can get my hands on.