[alsa-devel] [PATCH v3 09/11] ASoC: fsl: remove the fatal error checking on codec-handle

[Shawn Guo]

On Wed, Mar 14, 2012 at 06:00:41PM -0500, Timur Tabi wrote:
> Mark Brown wrote:
> 
> > All of which is exactly the same as for any other device and essentially
> > irrelevant to how we define the bindings for the cards.
> 
> So using imx-audio-sgtl5000.txt as an example, you're saying that if I
> have two SSIs, I should do this in my device tree:
> 
> sound1 {
> 	compatible = "fsl,imx51-babbage-sgtl5000",
> 		     "fsl,imx-audio-sgtl5000";
> 	model = "imx51-babbage-sgtl5000";
> 	ssi-controller = <&ssi1>;
> 	audio-codec = <&sgtl5000_1>;
> 	mux-int-port = <1>;
> 	mux-ext-port = <3>;
> };
> 
> sound2 {
> 	compatible = "fsl,imx51-babbage-sgtl5000",
> 		     "fsl,imx-audio-sgtl5000";
> 	model = "imx51-babbage-sgtl5000";
> 	ssi-controller = <&ssi2>;
> 	audio-codec = <&sgtl5000_2>;
> 	mux-int-port = <1>;
> 	mux-ext-port = <3>;
> };
> 
Are you putting an example that has two sgtl5000 codecs connected to
SSI1 and SSI2 on a particular board?

I have never seen a real case for such setup.  Have you actually seen?
I do not even see the need to use two SSI controllers for all imx
platforms I have seen.

The real case I have seen is imx28 saif driver, which has to use two
saif controllers connected to one sgtl5000 to support full-duplex.
I would expect something like below for that machine driver.

sound2 {
	compatible = "fsl,imx28-evk-sgtl5000",
		     "fsl,mxs-audio-sgtl5000";
	model = "imx28-evk-sgtl5000";
	saif-controller = <&saif1, &saif2>;
};

We can have that controller property be a phandle array in the binding.

> >>> The biggest improvement is that the SoC binding knows nothing about the
> >>> card binding at all, cards are completely separate and are free to
> >>> define any binding they choose using any number of on-SoC and off-SoC
> >>> devices.
> > 
> >> Ok, I don't understand that at all.
> > 
> > Do you have some questions about the above?  What is it that you find
> > unclear?   
> 
> What's the difference between an "SoC binding" and a "card binding"?
> 
I guess "SoC binding" means the binding for fsl_ssi while "card
binding" means the binding for imx-sgtl5000 in this particular case.

> > We've been through this *repeatedly*, including in the message you're
> > replying to, and we're still going back to square one every time you
> > decide to start talking about device tree again.  This is frustrating
> > in the extreme.
> 
> I'm sorry you're frustrated, but so am I.

And, so am I :(

I thought you have agreed that we can go for new binding for imx
machine drivers per the discussion you and Mark had on the first
version of the series.  That's why I changed to use the new binding
in v2, and you even had given your ack tag on v2.  Now you are
suddenly against that so strongly.  I really do not understand why.
Can you share your concern regarding to that?  What's the problem
with imx using new binding exactly?

> I still don't understand why
> the binding that I invented for the SSI driver isn't good enough for i.MX.

I guess Mark had made it clear that having "codec-handle" encoded in
ssi node is not as good as what new binding does, having it encoded
in "audio complex" node.

>  The binding and the code was documented and approved a long time ago.
> Why can't we keep the same binding on i.MX,
> to keep the code simpler?

I hardly agree with that.  The PowerPC binding will require:

1. fsl_ssi's probe function needs to trigger machine driver's probe
2. machine driver needs to find ssi's node to access codec-handle

which actually makes it complexer than the new binding.

Anyway, either way works, and I have tried both.  But unfortunately
I still have not made everyone happy.  Are we going to make the series
miss the v3.4 merge window just because of this argument, which does
not make much point to me at all.

-- 
Regards,
Shawn