[alsa-devel] [PATCH v2] ASoC: rsnd: enable SRC setting via DT
From: Kuninori Morimoto kuninori.morimoto.gx@renesas.com
Some special board wants to exchange sampling rate for special codec (or for very simple DA/AD converter) which can accept only 1 sampling rate. This patch enables its settings.
48kHz ---> 48kHz 44.1kHz ---> [SRC] ---> [codec] 96kHz --->
Signed-off-by: Kuninori Morimoto kuninori.morimoto.gx@renesas.com --- v1 -> v2
- add detail git log
.../devicetree/bindings/sound/renesas,rsnd.txt | 2 +- sound/soc/sh/rcar/src.c | 14 ++++++++++++-- 2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt index aa697ab..652573e 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt @@ -27,7 +27,7 @@ SSI subnode properties: - no-busif : BUSIF is not ussed when [mem -> SSI] via DMA case
SRC subnode properties: -no properties at this point +- convert-rate : SRC convert rate if needed
DAI subnode properties: - playback : list of playback modules diff --git a/sound/soc/sh/rcar/src.c b/sound/soc/sh/rcar/src.c index 4d39505..7f3c7d7 100644 --- a/sound/soc/sh/rcar/src.c +++ b/sound/soc/sh/rcar/src.c @@ -612,11 +612,11 @@ static void rsnd_of_parse_src(struct platform_device *pdev, const struct rsnd_of_data *of_data, struct rsnd_priv *priv) { - struct device_node *src_node; + struct device_node *src_node, *np; struct rcar_snd_info *info = rsnd_priv_to_info(priv); struct rsnd_src_platform_info *src_info; struct device *dev = &pdev->dev; - int nr; + int nr, i;
if (!of_data) return; @@ -640,6 +640,16 @@ static void rsnd_of_parse_src(struct platform_device *pdev, info->src_info = src_info; info->src_info_nr = nr;
+ i = 0; + for_each_child_of_node(src_node, np) { + src_info = info->src_info + i; + + of_property_read_u32(np, "convert-rate", + &src_info->convert_rate); + + i++; + } + rsnd_of_parse_src_end: of_node_put(src_node); }
On Tue, Jul 08, 2014 at 10:36:30PM -0700, Kuninori Morimoto wrote:
From: Kuninori Morimoto kuninori.morimoto.gx@renesas.com
Some special board wants to exchange sampling rate for special codec (or for very simple DA/AD converter) which can accept only 1 sampling rate. This patch enables its settings.
48kHz ---> 48kHz 44.1kHz ---> [SRC] ---> [codec] 96kHz --->
This is something which really should be implemented using the frameworks (DPCM mainly in this case as previously discussed for this and other bits of the hardware) rather than with something custom to the driver - we already have a way of forcing a DAI link into a single configuration, we should be using it.
Hi Mark
Some special board wants to exchange sampling rate for special codec (or for very simple DA/AD converter) which can accept only 1 sampling rate. This patch enables its settings.
48kHz ---> 48kHz 44.1kHz ---> [SRC] ---> [codec] 96kHz --->
This is something which really should be implemented using the frameworks (DPCM mainly in this case as previously discussed for this and other bits of the hardware) rather than with something custom to the driver - we already have a way of forcing a DAI link into a single configuration, we should be using it.
Ahh... yes indeed. I will re-consider about this. Thank you
Hi Mark
Can I confirm about this ?
48kHz ---> 48kHz 44.1kHz ---> [SRC] ---> [codec] 96kHz --->
This is something which really should be implemented using the frameworks (DPCM mainly in this case as previously discussed for this and other bits of the hardware) rather than with something custom to the driver - we already have a way of forcing a DAI link into a single configuration, we should be using it.
If my understand is correct, current upstream code doesn't have above feature at this point, and, I can update DPCM feature for it ?
If yes, and if I want to exchange rate from 96kHz -> 48kHz, I can use be->dai_link->be_hw_params_fixup() for 48kHz settings ?
Then, FE side want to know this result (= BE want to use 48kHz). I can add something new method for it ?
Or does current upstream code already have something this feature ?
Best regards --- Kuninori Morimoto
On Thu, Jul 24, 2014 at 07:08:19PM -0700, Kuninori Morimoto wrote:
48kHz ---> 48kHz 44.1kHz ---> [SRC] ---> [codec] 96kHz --->
This is something which really should be implemented using the frameworks (DPCM mainly in this case as previously discussed for this and other bits of the hardware) rather than with something custom to the driver - we already have a way of forcing a DAI link into a single configuration, we should be using it.
If my understand is correct, current upstream code doesn't have above feature at this point, and, I can update DPCM feature for it ?
If yes, and if I want to exchange rate from 96kHz -> 48kHz, I can use be->dai_link->be_hw_params_fixup() for 48kHz settings ?
That's the idea, yes.
Then, FE side want to know this result (= BE want to use 48kHz). I can add something new method for it ?
Let's have a look at the code - it might be easier to do it within the driver but a framework feature is also OK.
Or does current upstream code already have something this feature ?
No, just the fixup functions.
Hi Mark
48kHz ---> 48kHz 44.1kHz ---> [SRC] ---> [codec] 96kHz --->
I would like to confirm about this again.
If yes, and if I want to exchange rate from 96kHz -> 48kHz, I can use be->dai_link->be_hw_params_fixup() for 48kHz settings ?
That's the idea, yes.
I need to add DPCM support for above sample rate convert feature, and, I need it under DT. So, I need to add DPCM DT support as 1st step. Of course I want to add it on simple-card driver.
Q1 About DPCM, if my understanding was correct, the FE/BE for above feature will be like below. Here, CPU (= FE) can covert rate for codec (= BE). But, is it correct ? if not, what is the correct connection ?
FE: CPU <-> dummy BE: dummy <-> codec
Q2 This is extra question, but, if my understanding was correct, DPCM can use "single source (= CPU), multi sink (= codec)" playback ?
Q3. I know Lars-Peter pointed DT idea for DPCM via http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/media...
and, you and Jean-Francois discussed about it in Subject: Re: [alsa-devel] [PATCH] ASoC: generic: add generic compound card with DT support Date: Thu, 2 Jan 2014 13:44:37 +0100
But, it seems that there is no final agreement in ML ?
In my understanding, FE/BE connection is controlled by amixer, this means connection is not statically, but dynamically selected. (Or can we use statically linked FE/BE ?) I think, we can use above video-interfaces.txt idea for DT, but, not 100% good match for us ? Can you show me your DT binding idea for DPCM ? I can study it, and try to implement it.
Best regards --- Kuninori Morimoto
On Tue, Aug 05, 2014 at 01:39:13AM -0700, Kuninori Morimoto wrote:
Q1 About DPCM, if my understanding was correct, the FE/BE for above feature will be like below. Here, CPU (= FE) can covert rate for codec (= BE). But, is it correct ? if not, what is the correct connection ?
FE: CPU <-> dummy BE: dummy <-> codec
That's right.
Q2 This is extra question, but, if my understanding was correct, DPCM can use "single source (= CPU), multi sink (= codec)" playback ?
It should be able to do any combination of sources and sinks.
Q3. I know Lars-Peter pointed DT idea for DPCM via http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/media...
and, you and Jean-Francois discussed about it in Subject: Re: [alsa-devel] [PATCH] ASoC: generic: add generic compound card with DT support Date: Thu, 2 Jan 2014 13:44:37 +0100
But, it seems that there is no final agreement in ML ?
Right.
In my understanding, FE/BE connection is controlled by amixer, this means connection is not statically, but dynamically selected. (Or can we use statically linked FE/BE ?) I think, we can use above video-interfaces.txt idea for DT, but, not 100% good match for us ? Can you show me your DT binding idea for DPCM ? I can study it, and try to implement it.
This depends a bit on the hardware. If the audio block is one single IP to the rest of the system then DPCM probably ought to be totally transparent to DT and just look like a couple of DAIs attached to the IP or something. If the blocks are separate blocks that can be connected up any old way then it gets a lot more complicated. How does your system look?
Hi Mark
Thank you for your feedback
In my understanding, FE/BE connection is controlled by amixer, this means connection is not statically, but dynamically selected. (Or can we use statically linked FE/BE ?) I think, we can use above video-interfaces.txt idea for DT, but, not 100% good match for us ? Can you show me your DT binding idea for DPCM ? I can study it, and try to implement it.
This depends a bit on the hardware. If the audio block is one single IP to the rest of the system then DPCM probably ought to be totally transparent to DT and just look like a couple of DAIs attached to the IP or something. If the blocks are separate blocks that can be connected up any old way then it gets a lot more complicated. How does your system look?
I guess our IP is one of complicated system. Our system have many IP blocks which are called as SSI/SRC/CMD/DVC. So, in perfect world, I guess it will be
FE : SSI <-> dummy BE : SRC <-> CMD BE : DVC <-> codec
Or something like that, but, it is very complicate system at this point. I think we need 3 or 4 step for it.
Fortunately (?) these blocks are controlled in rsnd driver as 1 CPU today. So, I can say we can use it as
FE : CPU(*) <-> dummy BE : dummy <-> codec
(*) CPU includes SSI/SRC/CMD/DVC in rsnd driver
This is simple enough and good 1st step for DPCM support. I think our IP block needed these step
1. simple DPCM support on DT 2. sampling rate convert support on DPCM 3. multi FE/BE support on DT 4. rsnd multi block IP use multi DPCM
or (1 + 3) -> 2 -> 4 order How about this plan ?
On Wed, Aug 06, 2014 at 07:10:00PM -0700, Kuninori Morimoto wrote:
Fortunately (?) these blocks are controlled in rsnd driver as 1 CPU today. So, I can say we can use it as
FE : CPU(*) <-> dummy BE : dummy <-> codec
(*) CPU includes SSI/SRC/CMD/DVC in rsnd driver
This is simple enough and good 1st step for DPCM support. I think our IP block needed these step
- simple DPCM support on DT
- sampling rate convert support on DPCM
- multi FE/BE support on DT
- rsnd multi block IP use multi DPCM
or (1 + 3) -> 2 -> 4 order How about this plan ?
That sounds like it's moving in the right direction - it's always going to be possible to go round again and expand the code in the future if it turns out that more is needed.
participants (3)
-
Kuninori Morimoto -
Kuninori Morimoto -
Mark Brown