Re: [PATCH v2 05/11] ASoC: SDCA: add populate_function hw_op for DT function data

[Charles Keepax <ckeepax@opensource.cirrus.com>]

On Mon, Sep 07, 2026 at 01:28:42PM +0200, Pierre-Louis Bossart wrote:
> On 9/7/26 10:37, Srinivas Kandagatla wrote:
> > 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.

> > 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