Re: [PATCH v11 2/3] ASoC: qcom: dt-bindings: Add sc7180 machine bindings

On Tue, Oct 20, 2020 at 10:55 PM Srinivas Kandagatla
[off-list ref] wrote:

On 20/10/2020 15:37, Mark Brown wrote:

quoted

I don't understand what "logic scattered in various dtsi files" means,
sorry.

quoted

Yes, that should work to describe the dailink we are using.
But a more tricky issue is how to do calls like setting PLL in dai startup ops.

...

quoted

I think that asking a generic machine driver to do configuration like
this with only a limited interface of device property
might be too much of an ask for the machine driver.

Richard was looking at some basic configuration for PLLs.

quoted

Would you mind if I simplify the compatible string like Srinivas
suggested, and send a v12?
As for other two kinds of variations that I am aware of:
1. front mic / rear mic
2. replace alc5682 with adau7002

The CODEC change is going to be described in the DT no matter what -
you'll have a reference to the CODEC node but it may make sense if
there's enough custom code around it.  For front vs rear mic the
simplest thing would just be to not mention which if this is a hardware
fixed thing, otherwise a control.

quoted

We can set different board names and different compatible strings to
achieve such variation.
So that it would make sense to describe configuration in compatible
strings like you suggested, and also provides UCM a way to distinguish
different boards.

I don't recall having suggested distinguishing these things with a
compatible string, especially not the microphones.  UCM can already use
the display names for the boards to distinguish things.

Not with the compatible string!

Currently card name, and long name are exactly same in all Qualcomm
soundcards, which makes it very difficult to identify how those boards
re wired up at UCM2 level. So the plan is to properly populate card long
name with "model" property which can include details on how things are
wiredup on that board.

--srini

Hi Srini,
Thanks for taking a look.
Let me try to clarify your comments in case there is any misunderstanding.

I understand your request on having different board variations using
different sound card names through model property, and I totally agree
with that.
As for compatible strings, do you insist on having all the board
variations using exactly the same compatible string ?

Thanks!