simle-card DT style for DPCM

simle-card DT style for DPCM

[Kuninori Morimoto]

Hi Mark, Lars

I want to add DPCM support on simle-card driver.
1st reason is for "sampling-rate-convert".
And, 2nd reason, our customer want to use 2 cpu 1 codec style.

It works in my local environment.
but, I need to know what is the good style for DT.

I guss Xiubo's clean up patch seems good for me,
so, below approach is based on his style.
What do you think this ?

-- normal style --
sound {
	compatible = "simple-audio-card";
	...

	simple-audio-card,dai-link {
		...
		cpu {
			...
		};
		codec {
			...
		};
	}
}

-- use DPCM for sampling-rate-convert --
sound {
	compatible = "simple-audio-card";
	...

	simple-audio-card,dai-link {
		...
		cpu {
			...
		};
		codec {
			...
			fixed-sampling-rate = <xxx>;
		};
	}
}

	FE-cpu   : cpu
        FE-codec : dummy

        BE-cpu   : dummy
        BE-codec : codec

-- use DPCM for multi DAI --
sound {
	compatible = "simple-audio-card";
	...

	simple-audio-card,dai-link {
		...
		cpu@0 {
			...
		};
		cpu@1 {
			...
		};
		codec@1 {
			...
		};
	}
}

	FE-cpu   : cpu@0
        FE-codec : dummy

        BE-cpu   : cpu@1
        BE-codec : codec@1

Best regards
---
Kuninori Morimoto

Re: simle-card DT style for DPCM

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1005 bytes --]

On Sun, Aug 31, 2014 at 05:35:51PM -0700, Kuninori Morimoto wrote:

> -- use DPCM for sampling-rate-convert --
> sound {
> 	compatible = "simple-audio-card";
> 	...
> 
> 	simple-audio-card,dai-link {
> 		...
> 		cpu {
> 			...
> 		};
> 		codec {
> 			...
> 			fixed-sampling-rate = <xxx>;
> 		};
> 	}
> }

This looks good to me though I think specifying the rate at the link
level might make more sense.

> -- use DPCM for multi DAI --
> sound {
> 	compatible = "simple-audio-card";
> 	...
> 
> 	simple-audio-card,dai-link {
> 		...
> 		cpu@0 {
> 			...
> 		};
> 		cpu@1 {
> 			...
> 		};
> 		codec@1 {
> 			...
> 		};
> 	}
> }

I think here what I'd expect to see is only one CPU DAI specified for
the back end link in the CPU that is actually linked to the CODEC and
the front ends being worked out by the drivers, unless there are systems
where the set of front ends can be configured at system build time (as
opposed to from software at runtime) somehow.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: simle-card DT style for DPCM

[Kuninori Morimoto]

Hi Mark

> I think here what I'd expect to see is only one CPU DAI specified for
> the back end link in the CPU that is actually linked to the CODEC and
> the front ends being worked out by the drivers, unless there are systems
> where the set of front ends can be configured at system build time (as
> opposed to from software at runtime) somehow.

This means BE don't know who is FE.
The implementation can be more easy if it has
connect-to / connect-from property
(I'm not sure this is good naming...)

So, how about this ?
In pattern 3 case, it can be FE/BE if connect-to / connect-from was added,
otherwise, it will be normal DAI link.
connect-to / connect-from can be used if FE/BE were implemented
in different driver (pattern 3 indicates simle-card is BE)
We use pattern2 if FE/BE was not separated.

---------------------------------------
pattern 1: use DPCM in simple-card
---------------------------------------

It is supported, but it should use pattern 2 case.
This is sample of connect-to / connect-from.
see pattern 3

sound {
	compatible = "simple-audio-card";
	...

	/* Front End */
	dai_link0: simple-audio-card,dai-link@0 {
		...
		connect-to = <&dai-link1>;

		cpu { ... };
		codec { ... };
	}

	/* Back End */
	dai_link1: simple-audio-card,dai-link@1 {
		...
		connect-from = <&dai-link0>;

		cpu { ... };
		codec { ... };
	}
}

---------------------------------------
pattern 2: use DPCM in 1 simple-card
---------------------------------------
sound {
	compatible = "simple-audio-card";
	...

	simple-audio-card,dai-link {
		...
		cpu@0 { ... };   /* FE-cpu *//* FE-codec is dummy */
		cpu@1 { ... };   /* BE-cpu */
		codec@1 { ... }; /* BE-codec */
	}
}

---------------------------------------
pattern 3: use DPCM in simple-card and other driver
---------------------------------------
sound {
	compatible = "simple-audio-card";
	...

	dai_link: simple-audio-card,dai-link {
		...
		cpu { ... };
		codec { ... };
	}
}

--
foo-bar-link: foo-bar-sound {
	compatible = "foo-bar-sound";

        ...
	remote = <&dai-link>; /* foo-bar style FE
	                       * same as "connect-to" in simple-card
	                       */
};

&dai_link {
	/* Back End */
	connect-from = <&foo-bar-link>;
};



Best regards
---
Kuninori Morimoto

Re: simle-card DT style for DPCM

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 742 bytes --]

On Mon, Sep 01, 2014 at 06:28:04PM -0700, Kuninori Morimoto wrote:

> > I think here what I'd expect to see is only one CPU DAI specified for
> > the back end link in the CPU that is actually linked to the CODEC and
> > the front ends being worked out by the drivers, unless there are systems
> > where the set of front ends can be configured at system build time (as
> > opposed to from software at runtime) somehow.

> This means BE don't know who is FE.
> The implementation can be more easy if it has
> connect-to / connect-from property
> (I'm not sure this is good naming...)

We don't need to get this from DT if it's fixed in the SoC - the driver
for the SoC can know this.  The whole front end/back end thing is a bit
of a Linuxism.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: simle-card DT style for DPCM

[Kuninori Morimoto]

Hi Mark

> > This means BE don't know who is FE.
> > The implementation can be more easy if it has
> > connect-to / connect-from property
> > (I'm not sure this is good naming...)
> 
> We don't need to get this from DT if it's fixed in the SoC - the driver
> for the SoC can know this.  The whole front end/back end thing is a bit
> of a Linuxism.

Yes, FE/BE is very Linuxism, and I know DT shouldn't have Linuxism property.
But, "connect" or "remote" is normal in DT ?

> the driver for the SoC can know this.

I wonder how to know it in driver ?
(How to switch normal <-> FE/BE ?, and how to know FE or BE ?)
Can you show me objectivization example / idea ?

Best regards
---
Kuninori Morimoto

Re: simle-card DT style for DPCM

[Kuninori Morimoto]

Hi Mark

> > -- use DPCM for multi DAI --
> > sound {
> > 	compatible = "simple-audio-card";
> > 	...
> > 
> > 	simple-audio-card,dai-link {
> > 		...
> > 		cpu@0 {
> > 			...
> > 		};
> > 		cpu@1 {
> > 			...
> > 		};
> > 		codec@1 {
> > 			...
> > 		};
> > 	}
> > }
> 
> I think here what I'd expect to see is only one CPU DAI specified for
> the back end link in the CPU that is actually linked to the CODEC and
> the front ends being worked out by the drivers, unless there are systems
> where the set of front ends can be configured at system build time (as
> opposed to from software at runtime) somehow.

I still confusing about this
Is this mean "simple-card indicates BE side only,
FE should be created by driver somehow/automatically" ?
 -> how to specify/know FE side information ??

I don't think above (2 cpu + 1 codec) is not bad style
from DT point of view.
"configured at system build time" can be below ?

------------------
sound {
	compatible = "simple-audio-card";
	...

	dai_link: simple-audio-card,dai-link {
		...
		cpu@1 {
			...
		};
		codec@1 {
			...
		};
	}
}

----
& dai_link {
	cpu@0 {
		...
	};
};

Re: simle-card DT style for DPCM

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 464 bytes --]

On Tue, Sep 02, 2014 at 05:11:22PM -0700, Kuninori Morimoto wrote:

> > the driver for the SoC can know this.

> I wonder how to know it in driver ?
> (How to switch normal <-> FE/BE ?, and how to know FE or BE ?)
> Can you show me objectivization example / idea ?

Surely we can just put a data table or two in there with all the routing
inside the IP in the same way that we handle routing within CODECs?  It
doesn't seem like a fundamentally different problem.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: simle-card DT style for DPCM

[Kuninori Morimoto]

Hi Mark

> > I wonder how to know it in driver ?
> > (How to switch normal <-> FE/BE ?, and how to know FE or BE ?)
> > Can you show me objectivization example / idea ?
> 
> Surely we can just put a data table or two in there with all the routing
> inside the IP in the same way that we handle routing within CODECs?  It
> doesn't seem like a fundamentally different problem.

We can use this idea inside C code,
then, we need decide to use it or not use it somehow ?
We can do everything in C code, I have no concern about it.
But, my main concern is that how to decide this switching from DT file.
How to decide to use this "data table" ?
Does this mean you can accept new compatible ?

     compatible = "simple-audio-card"; # normal simple-card

     compatible = "soc-audio-card";    # special sound card
                                       # we use DPCM this time

Best regards
---
Kuninori Morimoto

Re: simle-card DT style for DPCM

[Lars-Peter Clausen]

On 09/08/2014 02:20 AM, Kuninori Morimoto wrote:
>
> Hi Mark
>
>>> I wonder how to know it in driver ?
>>> (How to switch normal <-> FE/BE ?, and how to know FE or BE ?)
>>> Can you show me objectivization example / idea ?
>>
>> Surely we can just put a data table or two in there with all the routing
>> inside the IP in the same way that we handle routing within CODECs?  It
>> doesn't seem like a fundamentally different problem.
>
> We can use this idea inside C code,
> then, we need decide to use it or not use it somehow ?
> We can do everything in C code, I have no concern about it.
> But, my main concern is that how to decide this switching from DT file.
> How to decide to use this "data table" ?
> Does this mean you can accept new compatible ?
>
>       compatible = "simple-audio-card"; # normal simple-card
>
>       compatible = "soc-audio-card";    # special sound card
>                                         # we use DPCM this time

If there is no difference in hardware there shouldn't be any difference in 
the hardware description.

Lets try to get to the bottom of the problem. Why do you want to enable DPCM 
on some cards and not enable it on others?

- Lars

Re: simle-card DT style for DPCM

[Kuninori Morimoto]

Hi Lars

Thank you for your feedback

> >       compatible = "simple-audio-card"; # normal simple-card
> >
> >       compatible = "soc-audio-card";    # special sound card
> >                                         # we use DPCM this time
> 
> If there is no difference in hardware there shouldn't be any difference in 
> the hardware description.
> 
> Lets try to get to the bottom of the problem. Why do you want to enable DPCM 
> on some cards and not enable it on others?

2 reasons for enabling DPCM
 1. to use "sampling rate convert"
 2. we need to use multi CPU (2cpu + 1codec)

2nd case is required in our next SoC.

About 1st case, Mark already agreed this style

-- use DPCM for sampling-rate-convert --
sound {
	compatible = "simple-audio-card";
	...

	simple-audio-card,dai-link {
		...
		sampling-rate-convert = <xxx>;
		cpu {
			...
		};
		codec {
			...
		};
	}
}

	FE-cpu   : cpu
        FE-codec : dummy

        BE-cpu   : dummy
        BE-codec : codec

------------------

We can decide "normal style" or "DPCM style" by checking
"sampling-rate-convert" property. This is easy.

2nd case is my confusion. I suggested this

-- use DPCM for multi DAI --
sound {
	compatible = "simple-audio-card";
	...

	simple-audio-card,dai-link {
		...
		cpu@0 {
			...
		};
		cpu@1 {
			...
		};
		codec@1 {
			...
		};
	}
}

	FE-cpu   : cpu@0
        FE-codec : dummy

        BE-cpu   : cpu@1
        BE-codec : codec@1
---------------------

but Mark rejected. His comment is this

    I think here what I'd expect to see is only one CPU DAI specified for
    the back end link in the CPU that is actually linked to the CODEC and
    the front ends being worked out by the drivers, unless there are systems
    where the set of front ends can be configured at system build time (as
    opposed to from software at runtime) somehow.

If my understanding was correct,
I think we can care it if DTS file was...

------------------------
sound {
	compatible = "simple-audio-card";
	...

	dai-link: simple-audio-card,dai-link {
		...
		cpu@1 { ... };
		codec@1 { ... };
	}
}

&dai-link {
	cpu@0 { ... };
};
------------------------

We can create everything/something in C code. I have no concern about it.
I need to know DT style of "multi cpu system on simple-card"
(= we will use DPCM in this case)
It is easy to understand for me if Mark/you can show me your idea of DT style.

best regards
---
Kuninori Morimoto

Re: simle-card DT style for DPCM

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 847 bytes --]

On Mon, Sep 08, 2014 at 01:50:53AM -0700, Kuninori Morimoto wrote:

> 2 reasons for enabling DPCM
>  1. to use "sampling rate convert"
>  2. we need to use multi CPU (2cpu + 1codec)

> 2nd case is required in our next SoC.

...

> We can create everything/something in C code. I have no concern about it.
> I need to know DT style of "multi cpu system on simple-card"
> (= we will use DPCM in this case)
> It is easy to understand for me if Mark/you can show me your idea of DT style.

If these two cases look the same from a hardware point of view (one
external interface connected to the CODEC, one block within the SoC
which happens to be able to deal with multiple streams of audio) then
they should look the same from a DT point of view.  The fact that the
block can handle multiple streams of audio shouldn't be relevant to the
DT bindings.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: simle-card DT style for DPCM

[Kuninori Morimoto]

Hi Mark

> > We can create everything/something in C code. I have no concern about it.
> > I need to know DT style of "multi cpu system on simple-card"
> > (= we will use DPCM in this case)
> > It is easy to understand for me if Mark/you can show me your idea of DT style.
> 
> If these two cases look the same from a hardware point of view (one
> external interface connected to the CODEC, one block within the SoC
> which happens to be able to deal with multiple streams of audio) then
> they should look the same from a DT point of view.  The fact that the
> block can handle multiple streams of audio shouldn't be relevant to the
> DT bindings.

OK. These are different HW/system.

HW images are these

1st one

   [CPU] <--> [CODEC]

CPU can sampling rate convert.
(we need DPCM if system want to use sampling rate convert,
 otherwise, normal simple-card is very OK)

2nd one

   [CPU0] --> [CPU1] <--> [CODEC1]

This is our next SoC style
(DPCM is always needed for this system,
 and these are fixed connection)

So, I need DPCM on DT now,
and I want add it to simple-card driver.

I think we should care both cases
in same time from development point of view.

Then, can you accept my proposal DT style ?

Best regards
---
Kuninori Morimoto