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
