Re: [RFC PATCH 1/2] soundwire: add support for static port mapping

[Srinivas Kandagatla]

On 19/02/2021 19:52, Pierre-Louis Bossart wrote:
> > > > > It seems you are in a different solution-space, where the codec driver
> > > > > needs to notify the master of which ports it needs to use?
> > > > Correct! As Codec is the place where we have mixer controls ant it can
> > > > clearly tell which master ports should be used for that particular
> > > > configuration.
> > > And that should come from firmware (DT etc) and driver should pass on
> > > this info
> >
> > Are you okay with the patch as it is, provided this information is 
> > populated from DT?
>
> I am fine with the direction at a high-level. The premise for SoundWire 
> is that the bus is simple enough that it can be used in different 
> contexts and architectures, so if Qualcomm need something that differs 
> from what is needed for Intel we are really not in a position to object.
>
> That said, I could use more explanations on how the mapping is defined: 
> I don't think we have the same definition of 'static port mapping'. For 
> SDCA integration, we plan to have a static mapping in some sort of ACPI 
> table that will describe which port on the Manager side is connected to 
> which ports on Peripheral XYZ. That's static as in set in stone in 
> platform firmware. I understand the reference to DT settings as the same 
> idea.

Yes, we are talking about the same static mapping here!

> But if the mapping depends on the value of mixer controls as you 
> describe it, then it's not static and defined by DT settings, but 
> run-time defined.
I think there is some miss understanding here, the mapping is static but 
the port selection is based on the mixer controls!

> Also maybe we'd want to have a more opaque way of passing the 
> information, maybe with a stream private data or a callback, instead of 
> hard-coding fields that are only used by Qualcomm.

Let me try the callback way and see how it will endup!

thanks,
srini

>