simle-card DT style for DPCM

Discussion:

Kuninori Morimoto

2014-09-01 00:35:51 UTC

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 {
...
***@0 {
...
};
***@1 {
...
};
***@1 {
...
};
}
}

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

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

Best regards
---
Kuninori Morimoto

Mark Brown

2014-09-01 14:30:47 UTC

Permalink

Post by Kuninori Morimoto
-- 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.

Post by Kuninori Morimoto
-- use DPCM for multi DAI --
sound {
compatible = "simple-audio-card";
...
simple-audio-card,dai-link {
...
...
};
...
};
...
};
}
}

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.

Kuninori Morimoto

2014-09-02 01:28:04 UTC

Permalink

Hi Mark

Post by Mark Brown
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-***@0 {
...
connect-to = <&dai-link1>;

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

/* Back End */
dai_link1: simple-audio-card,dai-***@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 {
...
***@0 { ... }; /* FE-cpu *//* FE-codec is dummy */
***@1 { ... }; /* BE-cpu */
***@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

Mark Brown

2014-09-02 11:34:07 UTC

Permalink

Post by Kuninori Morimoto

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.

Kuninori Morimoto

2014-09-03 00:11:22 UTC

Permalink

Hi Mark

Post by Mark Brown

Post by Kuninori Morimoto
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 ?

Post by Mark Brown
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

Mark Brown

2014-09-05 15:55:13 UTC

Permalink

Post by Kuninori Morimoto

Post by Mark Brown
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.

Kuninori Morimoto

2014-09-08 00:20:36 UTC

Permalink

Hi Mark

Post by Mark Brown

Post by Kuninori Morimoto
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

Lars-Peter Clausen

2014-09-08 07:39:23 UTC

Permalink

Post by Kuninori Morimoto
Hi Mark

Post by Mark Brown

Post by Kuninori Morimoto
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

Kuninori Morimoto

2014-09-08 08:50:53 UTC

Permalink

Hi Lars

Thank you for your feedback

Post by Lars-Peter Clausen

Post by Kuninori Morimoto
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 {
...
***@0 {
...
};
***@1 {
...
};
***@1 {
...
};
}
}

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

BE-cpu : ***@1
BE-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 {
...
***@1 { ... };
***@1 { ... };
}
}

&dai-link {
***@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

Mark Brown

2014-09-09 11:51:30 UTC

Permalink

Post by Kuninori Morimoto
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.

...

Post by Kuninori Morimoto
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.

Kuninori Morimoto

2014-09-10 00:18:52 UTC

Permalink

Hi Mark

Post by Mark Brown

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

Kuninori Morimoto

2014-09-03 05:17:52 UTC

Permalink

Hi Mark

Post by Mark Brown

Post by Kuninori Morimoto
-- use DPCM for multi DAI --
sound {
compatible = "simple-audio-card";
...
simple-audio-card,dai-link {
...
...
};
...
};
...
};
}
}

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 {
...
***@1 {
...
};
***@1 {
...
};
}
}

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