Speaker
Description
MiPi Specifications defines standard device properties that endup into ACPI tables. Whoever Device tree bindings evolve in a very different way.
Even-though all the three are defining hardware, there is no consideration of MiPi or ACPI while defining the bindings.
where do we draw a line?
Is there some consolidation that needs to happen?
How can drivers written for ACPI be re-useable for Device tree based platforms.
The MIPI SoundWire® Device Class for Audio (SDCA) specifications are built around ACPI, and the software support reflects that. At the same time, the kernel’s fwnode_* API's provides a degree of unification between ACPI and Device Tree. Does this imply that Device Tree bindings should mirror ACPI descriptions to some extent?
This becomes more interesting as new MIPI SoundWire® Device Class for Audio (SDCA) specification is designed to offer “out-of-box audio enablement” without relying on SoC- or device-specific drivers. The goal is to support audio codecs through a generic driver rather than writing one for each device.
Fantastic!!, Hold on.. What about ARM64 platforms and Device Tree Bindings?
Now the Question is :
- what extent should device tree bindings reflect the ACPI bindings from this Specifications?
- Should it make it fully compatible?
- Should we just ignore this and do THE device-tree way and invent a parallel bindings?
- Should we have an intermediate representation of this?
- Should Device Tree bindings comply to MIPI Standard Specifications?
