| Message ID | 20201014145418.31838-1-rf@opensource.cirrus.com |
|---|---|
| Headers | show |
| Series | Add dts for Rpi4 + Cirrus Lochnagar and codecs | expand |
On Wed, Oct 14, 2020 at 03:54:11PM +0100, Richard Fitzgerald wrote: > This set of patches provides support for using the Cirrus Logic > Lochnagar audio development platform plus Cirrus Logic Madera/Arizona > codecs with the simple-card machine driver and a Raspberry Pi4. The > ultimate aim is to provide the dts file but some updates are needed to > the simple-card machine driver. Why extend simple-card and not the more modern and flexible audio-graph-card?
Hi Richard, your series is very welcome, upstream support for audio codecs on the RPi4 has always been lackluster. Could you provide more information on the actual products? Are there custom made hats for the RPi4 or this wired into a generic development board. On Wed, 2020-10-14 at 15:54 +0100, Richard Fitzgerald wrote: > This is based on the default bcm2711-rpi-4-b.dts. Note that you could've included bcm2711-rpi-4.dts (as if it was a .dtsi). > Configurations are provided for Cirrus Logic codecs CS42L92, CS47L15, > CS47L24, CS47L35, CS47L90 and WM8998. > > For each codec there is a sound node and a codec device node and both > default to disabled. Enable the pair for the codec in use. > > Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> > --- Sadly I don't think creating a new device tree is a good solution here. If we were to do so for every RPi hat/usage it'd become unmanageable very fast. There is a way to maintain this in the open nonetheless. I suggest you build a DT overlay and submit it to https://github.com/raspberrypi/linux, see 'arch/arm/boot/dts/overlays.' The Raspberry Pi engineers have a kernel branch that tracks of the latest kernel release, so once you get the rest of patches sorted out and they are included in a release it'll make sense to do so. I can't tell for other distros, but opensuse packages overlays, so the effort will ultimately be useful to users. Regards, Nicolas
On 15/10/2020 11:25, Nicolas Saenz Julienne wrote: > Hi Richard, > your series is very welcome, upstream support for audio codecs on the RPi4 has > always been lackluster. > > Could you provide more information on the actual products? Are there custom > made hats for the RPi4 or this wired into a generic development board. > Info on the codecs is available from www.cirrus.com. The Lochnagar audio development board is not a hat, but it can be wired over to the RPi GPIO header. It is not specific to the RPi. > On Wed, 2020-10-14 at 15:54 +0100, Richard Fitzgerald wrote: >> This is based on the default bcm2711-rpi-4-b.dts. > > Note that you could've included bcm2711-rpi-4.dts (as if it was a .dtsi). > Ok, will change. >> Configurations are provided for Cirrus Logic codecs CS42L92, CS47L15, >> CS47L24, CS47L35, CS47L90 and WM8998. >> >> For each codec there is a sound node and a codec device node and both >> default to disabled. Enable the pair for the codec in use. >> >> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> >> --- > > Sadly I don't think creating a new device tree is a good solution here. If we > were to do so for every RPi hat/usage it'd become unmanageable very fast. There > is a way to maintain this in the open nonetheless. I suggest you build a DT > overlay and submit it to https://github.com/raspberrypi/linux, see > 'arch/arm/boot/dts/overlays.' The Raspberry Pi engineers have a kernel branch We want something in mainline so that it can be used by people developing on mainline and taken as a starting point for configuring the codecs for other host platforms. The RPi is a convenient platform to use as the base because it is widely available and low-cost. > that tracks of the latest kernel release, so once you get the rest of patches > sorted out and they are included in a release it'll make sense to do so. > > I can't tell for other distros, but opensuse packages overlays, so the effort > will ultimately be useful to users. > > Regards, > Nicolas > >
On Thu, 2020-10-15 at 12:14 +0100, Richard Fitzgerald wrote: > > Sadly I don't think creating a new device tree is a good solution here. If we > > were to do so for every RPi hat/usage it'd become unmanageable very fast. There > > is a way to maintain this in the open nonetheless. I suggest you build a DT > > overlay and submit it to https://github.com/raspberrypi/linux, see > > 'arch/arm/boot/dts/overlays.' The Raspberry Pi engineers have a kernel branch > > We want something in mainline so that it can be used by people > developing on mainline and taken as a starting point for configuring > the codecs for other host platforms. The RPi is a convenient platform to > use as the base because it is widely available and low-cost. If what you want to convey is the proper way of configuring your specific device the way to go is writing a devicetree binding. See Documentation/devicetree. It's even possible to validate a given devicetree against the bindings (given they are written in yaml format). Regards, Nicolas
On Thu, Oct 15, 2020 at 05:12:42PM +0200, Nicolas Saenz Julienne wrote: > On Thu, 2020-10-15 at 12:14 +0100, Richard Fitzgerald wrote: > > We want something in mainline so that it can be used by people > > developing on mainline and taken as a starting point for configuring > > the codecs for other host platforms. The RPi is a convenient platform to > > use as the base because it is widely available and low-cost. > If what you want to convey is the proper way of configuring your specific > device the way to go is writing a devicetree binding. See > Documentation/devicetree. It's even possible to validate a given devicetree > against the bindings (given they are written in yaml format). These devices already have bindings, that doesn't really help with describing how a specific board is wired up.
On 15/10/2020 16:12, Nicolas Saenz Julienne wrote: > On Thu, 2020-10-15 at 12:14 +0100, Richard Fitzgerald wrote: >>> Sadly I don't think creating a new device tree is a good solution here. If we >>> were to do so for every RPi hat/usage it'd become unmanageable very fast. There >>> is a way to maintain this in the open nonetheless. I suggest you build a DT >>> overlay and submit it to https://github.com/raspberrypi/linux, see >>> 'arch/arm/boot/dts/overlays.' The Raspberry Pi engineers have a kernel branch >> >> We want something in mainline so that it can be used by people >> developing on mainline and taken as a starting point for configuring >> the codecs for other host platforms. The RPi is a convenient platform to >> use as the base because it is widely available and low-cost. > > If what you want to convey is the proper way of configuring your specific > device the way to go is writing a devicetree binding. See If we have a working configuration it is unreasonable not to make this available for people who want to use it or examine it. A working example can be more helpful than a ton of documentation. It's also worth noting that setting up a working sound system involves configuring multiple drivers (for example you also need a properly configured ASoC machine driver at least) crossing multiple driver bindings. So a complete working example is valuable to see how it fits together. > Documentation/devicetree. It's even possible to validate a given devicetree > against the bindings (given they are written in yaml format). > Validating only checks syntax and bounds. It doesn't prove that it will work. > Regards, > Nicolas >
On 14/10/2020 19:56, Mark Brown wrote: > On Wed, Oct 14, 2020 at 03:54:11PM +0100, Richard Fitzgerald wrote: >> This set of patches provides support for using the Cirrus Logic >> Lochnagar audio development platform plus Cirrus Logic Madera/Arizona >> codecs with the simple-card machine driver and a Raspberry Pi4. The >> ultimate aim is to provide the dts file but some updates are needed to >> the simple-card machine driver. > > Why extend simple-card and not the more modern and flexible > audio-graph-card? > I'm struggling to understand how to use audio-graph-card where there are multiple alternative codecs. The host I2S endpoint has to point back to the codec endpoint, like this: cpu_i2s_ep_cs47l15: endpoint { remote-endpoint = <&cs47l15_aif1>; }; But obviously that depends on which codec node was enabled. Listing multiple endpoints makes the whole port node disabled if any remote endpoint is in a disabled node. I've tried adding status="disabled" to endpoints or multiple port definitions with status="disabled" but I haven't figured out a solution.
On Fri, Oct 16, 2020 at 02:30:08PM +0100, Richard Fitzgerald wrote: > On 14/10/2020 19:56, Mark Brown wrote: > > Why extend simple-card and not the more modern and flexible > > audio-graph-card? > I'm struggling to understand how to use audio-graph-card where there are > multiple alternative codecs. The host I2S endpoint has to point back to > the codec endpoint, like this: OK, this seems like a more urgent problem to address given that the graph card is supposed to be able to support things like TDM. However... > cpu_i2s_ep_cs47l15: endpoint { > remote-endpoint = <&cs47l15_aif1>; > }; > But obviously that depends on which codec node was enabled. Listing > multiple endpoints makes the whole port node disabled if any remote > endpoint is in a disabled node. I've tried adding status="disabled" > to endpoints or multiple port definitions with status="disabled" but > I haven't figured out a solution. ...it seems like the issue here is that you're essentially trying to define multiple cards at once in the same overlay. TBH this feels like you want two nested levels of overlay, with the extra layer patching the CODEC compatible. Or if this is mainly as an example for people you could just pick one and use that?
On Fri, Oct 16, 2020 at 02:30:08PM +0100, Richard Fitzgerald wrote: > On 14/10/2020 19:56, Mark Brown wrote: > > On Wed, Oct 14, 2020 at 03:54:11PM +0100, Richard Fitzgerald wrote: > > > This set of patches provides support for using the Cirrus Logic > > > Lochnagar audio development platform plus Cirrus Logic Madera/Arizona > > > codecs with the simple-card machine driver and a Raspberry Pi4. The > > > ultimate aim is to provide the dts file but some updates are needed to > > > the simple-card machine driver. > > > > Why extend simple-card and not the more modern and flexible > > audio-graph-card? > > > > I'm struggling to understand how to use audio-graph-card where there are > multiple alternative codecs. The host I2S endpoint has to point back to > the codec endpoint, like this: > > cpu_i2s_ep_cs47l15: endpoint { > remote-endpoint = <&cs47l15_aif1>; > }; > > But obviously that depends on which codec node was enabled. Listing > multiple endpoints makes the whole port node disabled if any remote > endpoint is in a disabled node. I've tried adding status="disabled" > to endpoints or multiple port definitions with status="disabled" but > I haven't figured out a solution. Multiple endpoints is what you should do. And 'status' goes in the device nodes (not the graph nodes). Rob