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

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

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

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

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