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