On Tue, Sep 08, 2026 at 04:22:53PM +0200, Pierre-Louis Bossart wrote:
quoted
quoted
quoted
That's why the current series takes the lower-overhead path
(mechanical transcription in C) rather than proposing an intermediate
DT format as part of this submission. If the concept-DT direction
gets traction at LPC 2026 DT MC, we can revisit.
This part I follow slightly better, I would be happy to proceed,
pending reviews with the current approach, although if Pierre
is or not probably remains to be seen.
@Pierre
Please let us know if you are okay with this approach of C structures.
Now that I have more context, I don't have any objections with Srini's
proposal. It'd a good step forward to use common class drivers across
multiple vendors, we'll probably find a couple of bugs or harden the
SDCA core and that'd be good progress for everyone developing or
depending on the ASoC/SoundWire/SDCA frameworks.
If this means that in an intermediate step C tables are used, that's
fine with me. In the long run, things might change with additional
options such as:
a) ACPI support on all platforms
b) DT hybrid mode to reuse ACPI/DSDT tables
c) DT native representation of properties.
We can review the preferred direction when the platform firmware
plumbing improves.
I believe the point about binary/opaque data was noted by Srini, it can
be handled in multiple ways and there's no reason to block.
Best to start small at the SDCA level with incremental changes later on
how to fetch DisCo information from platform firmware - that wouldn't
change the system behavior, only optimize by making the translation from
DSDT to C tables un-necessary.
Super, thanks Pierre. I will start working through a more
detailed review of the series.
Thanks,
Charles