On Mon, Sep 07, 2026 at 01:28:42PM +0200, Pierre-Louis Bossart wrote:
On 9/7/26 10:37, Srinivas Kandagatla wrote:
quoted
sdca_parse_function() walks a firmware node, but on DT there is no
DisCo node -- sdca_lookup_functions() is a no-op and the SDCA
function descriptors come with a NULL fwnode.
It'd be good to have a link to an example set of DT properties for SDCA.
The way the functions were organized in ACPI is based on a DT-inspired
_DSD mechanism to have nested blocks.
There was one in the last chain discussing this, let me know if
you can't find it and I will try to dig it out my inbox.
edit: After reaching the last patch I realized there are no such
properties. The main problem is how to deal with board-specific
initialization data, the suggestion to encode all the tables in C seems
limited to me.
Yeah unfortunately the DT maintainers seem to have put a hard
NAK on putting SDCA properties in DT (again see previous chain
for the discussion), so we are basically left with the choices
of C tables as in the patch chain or using software nodes. Both
will end up with the same issue of drivers eventually being
fully of little quirks to tweak the tables to match the current
hardware.
Using software nodes is possibly more "correct" and would
let us re-use the parsing, but will end up significantly more
verbose. I am not sure I have a strong opinion one way or the
other, apart from putting things actually in the DT would be
the clearly best option.
quoted
Add a populate_function hw_op that the class function driver falls
back to when @function->desc->node is NULL: it fills the caller-owned
sdca_function_data (entities, clusters, init_table, delays) from the
codec's static tables, matching by function type. Leave
@function->desc alone -- the framework owns the per-instance
descriptor, so devices with more than one function of the same type
keep their per-instance SoundWire address.
I wasn't able to understand that last sentence - and I don't remember
seeing a case with different functions of the same type. It's permitted
by the spec but it'd be fun to manage...
We have some systems that are starting to do that :-)
Thanks,
Charles