| Message ID | 87tuitusy4.wl-kuninori.morimoto.gx@renesas.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ASoC: Add Rich Graph Card support | expand |
Hi Mark 2 weeks have passed, and nothing happened. Do I need to repost this patch-set ? > Hi Mark > > We already have Audio-Graph-Card which is Of-Graph base general sound > card driver. Basically it supports basic CPU-Codec connection, and is > also supporting DPCM connection. Because it was forcibly expanded to > DPCM, DT parsing is very limited and very difficult to add new features > on it, for example Multi-CPU/Codec support, Codec2Codec support, etc. > > This patch adds more flexible new Rich-Graph-Card driver for it. > Audio-Graph-Card and Rich-Graph-Card are similar, but don't have > full compatibility. > The reason why I need Rich-Graph-Card instead of updating Audio-Graph-Card > is that it is very difficult to keep compatibility. > > Rich-Graph-Card supports Normal/DPCM/Codec2Codec Connection wich > Single/Multi DAIs. And it is possible to Customizing. > > This patch-set adds Rich-Graph-Card driver and customized driver > sample, and DT settings sample which can be used for testing. > > To enable testing/debuging, this patch-set also adds Test-Component > driver. We already have Dummy Component and/or Dummy DAI on soc-utils, > but 1) we can't use it from DT, 2) it do nothing. > Added new Test-Component can be used from DT, and it can indicate called > function name. We can use it to trace callback order, understanding > ALSA SoC behavior, etc, etc... > Sample DT settings of Rich Graph Card is using Test-Component as CPU/Codec DAI. > > You can easily try to use/test it if you added below line to your DT file. > Your .config needs to have below CONFIGs to use/test it. > It will probe sample Sound Card which has Normal/DPCM/Multi/Codec2Codec > connections. > > #include "../../../../../sound/soc/generic/rich-graph-card-sample.dtsi" > > CONFIG_SND_RICH_GRAPH_CARD > CONFIG_SND_RICH_CUSTOM_CARD_SAMPLE > CONFIG_SND_TEST_COMPONENT > > Because Audio Graph Card2 is still under experimental stage, it will > indicate such warning when probing, and the DT might be updated/exchanged. > > It can use Codec2Codec, but it will start automatically when probed, > and can't stop it so far. It should be updated. > > Link: https://lore.kernel.org/r/87k0xszlep.wl-kuninori.morimoto.gx@renesas.com > Link: https://lore.kernel.org/r/871r8u4s6q.wl-kuninori.morimoto.gx@renesas.com > Link: https://lore.kernel.org/r/87a6mhwyqn.wl-kuninori.morimoto.gx@renesas.com > > v1 -> v2 > - don't use "port" base for_each loop > > v2 -> v3 > - Rename audio-graph-card2 to rich-graph-card > - Rename DSP to DPCM not to confuse > - Normal/DPCM/Codec2Codec can use Single/Multi DAIs. > - use dpcm/multi/codec2codec node instead of using extra compatible > - Sample DTSI patch is separated to Single/Multi. > > Kuninori Morimoto (16): > ASoC: test-component: add Test Component YAML bindings > ASoC: test-component: add Test Component for Sound debug/test > ASoC: simple-card-utils: add asoc_graph_is_ports0() > ASoC: simple-card-utils: add codec2codec support > ASoC: add Rich Graph Card driver > ASoC: rich-graph-card: add Multi CPU/Codec support > ASoC: rich-graph-card: add DPCM support > ASoC: rich-graph-card: add Codec2Codec support > ASoC: add Rich Graph Card Yaml Document > ASoC: add Rich Graph Card Custom Sample > ASoC: rich-graph-card-sample.dtsi: add Sample DT for Normal (Single) > ASoC: rich-graph-card-sample.dtsi: add Sample DT for Normal (Nulti) > ASoC: rich-graph-card-sample.dtsi: add DPCM sample (Single) > ASoC: rich-graph-card-sample.dtsi: add DPCM sample (Multi) > ASoC: rich-graph-card-sample.dtsi: add Codec2Codec sample (Single) > ASoC: rich-graph-card-sample.dtsi: add Codec2Codec sample (Multi) > > .../bindings/sound/rich-graph-card.yaml | 57 + > .../bindings/sound/test-component.yaml | 33 + > include/sound/graph_card.h | 21 + > include/sound/simple_card_utils.h | 4 + > sound/soc/generic/Kconfig | 20 + > sound/soc/generic/Makefile | 6 + > sound/soc/generic/rich-custom-card-sample.c | 174 +++ > sound/soc/generic/rich-graph-card-sample.dtsi | 225 +++ > sound/soc/generic/rich-graph-card.c | 1277 +++++++++++++++++ > sound/soc/generic/simple-card-utils.c | 46 +- > sound/soc/generic/test-component.c | 659 +++++++++ > 11 files changed, 2521 insertions(+), 1 deletion(-) > create mode 100644 Documentation/devicetree/bindings/sound/rich-graph-card.yaml > create mode 100644 Documentation/devicetree/bindings/sound/test-component.yaml > create mode 100644 sound/soc/generic/rich-custom-card-sample.c > create mode 100644 sound/soc/generic/rich-graph-card-sample.dtsi > create mode 100644 sound/soc/generic/rich-graph-card.c > create mode 100644 sound/soc/generic/test-component.c > > -- > 2.25.1 >
On Thu, Sep 30, 2021 at 07:23:06AM +0900, Kuninori Morimoto wrote: > 2 weeks have passed, and nothing happened. > Do I need to repost this patch-set ? No, it's still in my queue - I'm hoping to get to it this week, between Plumbers last week and a big internal conference the week before I've not had much bandwidth for complicated stuff like this.
Hi Mark Thank you for your reply > > 2 weeks have passed, and nothing happened. > > Do I need to repost this patch-set ? > > No, it's still in my queue - I'm hoping to get to it this week, between > Plumbers last week and a big internal conference the week before I've > not had much bandwidth for complicated stuff like this. Oh, I see. Thank you for your help !! Best regards --- Kuninori Morimoto
Hi Morimoto-san, Mark, On 10/09/2021 04:20, Kuninori Morimoto wrote: > > Hi Mark > > We already have Audio-Graph-Card which is Of-Graph base general sound > card driver. Basically it supports basic CPU-Codec connection, and is > also supporting DPCM connection. Because it was forcibly expanded to > DPCM, DT parsing is very limited and very difficult to add new features > on it, for example Multi-CPU/Codec support, Codec2Codec support, etc. > > This patch adds more flexible new Rich-Graph-Card driver for it. > Audio-Graph-Card and Rich-Graph-Card are similar, but don't have > full compatibility. > The reason why I need Rich-Graph-Card instead of updating Audio-Graph-Card > is that it is very difficult to keep compatibility. > > Rich-Graph-Card supports Normal/DPCM/Codec2Codec Connection wich > Single/Multi DAIs. And it is possible to Customizing. > > This patch-set adds Rich-Graph-Card driver and customized driver > sample, and DT settings sample which can be used for testing. I understand is that naming is difficult, but a rich-graph-card sounds a bit awkward? Will we see a wealthy-graph-card if the rich is not resourceful enough? ;) The current generation of graph based generic audio card is audio-graph-card This is going to be an (incompatible) evolution, the Next/New Generation. Would it sound better if it is named audio-graph-card-ng / ng-audio-graph-card The 'rich' sound really out of place (if not rich then poor?). Next Generation, New Generation, Extended, etc or just drop the graph and generic-audio-card > To enable testing/debuging, this patch-set also adds Test-Component > driver. We already have Dummy Component and/or Dummy DAI on soc-utils, > but 1) we can't use it from DT, 2) it do nothing. > Added new Test-Component can be used from DT, and it can indicate called > function name. We can use it to trace callback order, understanding > ALSA SoC behavior, etc, etc... > Sample DT settings of Rich Graph Card is using Test-Component as CPU/Codec DAI. > > You can easily try to use/test it if you added below line to your DT file. > Your .config needs to have below CONFIGs to use/test it. > It will probe sample Sound Card which has Normal/DPCM/Multi/Codec2Codec > connections. > > #include "../../../../../sound/soc/generic/rich-graph-card-sample.dtsi" > > CONFIG_SND_RICH_GRAPH_CARD > CONFIG_SND_RICH_CUSTOM_CARD_SAMPLE > CONFIG_SND_TEST_COMPONENT > > Because Audio Graph Card2 is still under experimental stage, it will > indicate such warning when probing, and the DT might be updated/exchanged. > > It can use Codec2Codec, but it will start automatically when probed, > and can't stop it so far. It should be updated. > > Link: https://lore.kernel.org/r/87k0xszlep.wl-kuninori.morimoto.gx@renesas.com > Link: https://lore.kernel.org/r/871r8u4s6q.wl-kuninori.morimoto.gx@renesas.com > Link: https://lore.kernel.org/r/87a6mhwyqn.wl-kuninori.morimoto.gx@renesas.com > > v1 -> v2 > - don't use "port" base for_each loop > > v2 -> v3 > - Rename audio-graph-card2 to rich-graph-card > - Rename DSP to DPCM not to confuse > - Normal/DPCM/Codec2Codec can use Single/Multi DAIs. > - use dpcm/multi/codec2codec node instead of using extra compatible > - Sample DTSI patch is separated to Single/Multi. > > Kuninori Morimoto (16): > ASoC: test-component: add Test Component YAML bindings > ASoC: test-component: add Test Component for Sound debug/test > ASoC: simple-card-utils: add asoc_graph_is_ports0() > ASoC: simple-card-utils: add codec2codec support > ASoC: add Rich Graph Card driver > ASoC: rich-graph-card: add Multi CPU/Codec support > ASoC: rich-graph-card: add DPCM support > ASoC: rich-graph-card: add Codec2Codec support > ASoC: add Rich Graph Card Yaml Document > ASoC: add Rich Graph Card Custom Sample > ASoC: rich-graph-card-sample.dtsi: add Sample DT for Normal (Single) > ASoC: rich-graph-card-sample.dtsi: add Sample DT for Normal (Nulti) > ASoC: rich-graph-card-sample.dtsi: add DPCM sample (Single) > ASoC: rich-graph-card-sample.dtsi: add DPCM sample (Multi) > ASoC: rich-graph-card-sample.dtsi: add Codec2Codec sample (Single) > ASoC: rich-graph-card-sample.dtsi: add Codec2Codec sample (Multi) > > .../bindings/sound/rich-graph-card.yaml | 57 + > .../bindings/sound/test-component.yaml | 33 + > include/sound/graph_card.h | 21 + > include/sound/simple_card_utils.h | 4 + > sound/soc/generic/Kconfig | 20 + > sound/soc/generic/Makefile | 6 + > sound/soc/generic/rich-custom-card-sample.c | 174 +++ > sound/soc/generic/rich-graph-card-sample.dtsi | 225 +++ > sound/soc/generic/rich-graph-card.c | 1277 +++++++++++++++++ > sound/soc/generic/simple-card-utils.c | 46 +- > sound/soc/generic/test-component.c | 659 +++++++++ > 11 files changed, 2521 insertions(+), 1 deletion(-) > create mode 100644 Documentation/devicetree/bindings/sound/rich-graph-card.yaml > create mode 100644 Documentation/devicetree/bindings/sound/test-component.yaml > create mode 100644 sound/soc/generic/rich-custom-card-sample.c > create mode 100644 sound/soc/generic/rich-graph-card-sample.dtsi > create mode 100644 sound/soc/generic/rich-graph-card.c > create mode 100644 sound/soc/generic/test-component.c >
Hi Peter, Mark Thank you for your feedback > I understand is that naming is difficult, but a rich-graph-card sounds a > bit awkward? > Will we see a wealthy-graph-card if the rich is not resourceful enough? ;) > > The current generation of graph based generic audio card is > audio-graph-card > > This is going to be an (incompatible) evolution, the Next/New > Generation. Would it sound better if it is named > audio-graph-card-ng / ng-audio-graph-card > > The 'rich' sound really out of place (if not rich then poor?). > > Next Generation, New Generation, Extended, etc > or just drop the graph and > generic-audio-card To be honest, I don't think this version will be final version of Generic audio card driver. We will want to have more advanced generic audio card if framework was updated, and/or new feature was added, and/or want to use more complex connection, etc, etc, etc... In such case, because of Device-Tree, it is very difficult to update driver with keeping compatibility. This means, we need to keep old version generic audio card as-is, and add new generic audio card, like this version. New / Next / Extended / Rich are not best naming IMO. For example, we will confuse if we add new generic audio card at 10 years later (It should be more new/next/extended/rich than this version). And yes, people should not feel bad from driver naming. Thus, my honest opinion is that using v2, v3, ... is easy to understand, especially for audio-graph-card. (audio-graph-card2, audio-graph-card3, ...) But, any naming is very welcome for me if Mark and/or all people are accepted. Thank you for your help !! Best regards --- Kuninori Morimoto
On Fri, Oct 01, 2021 at 03:48:26PM +0900, Kuninori Morimoto wrote: > > The current generation of graph based generic audio card is > > audio-graph-card > > This is going to be an (incompatible) evolution, the Next/New > > Generation. Would it sound better if it is named > > audio-graph-card-ng / ng-audio-graph-card > > The 'rich' sound really out of place (if not rich then poor?). Wealthy, billionaire, oligarch... :P > > Next Generation, New Generation, Extended, etc > > or just drop the graph and > > generic-audio-card > To be honest, I don't think this version will be final version of > Generic audio card driver. > We will want to have more advanced generic audio card if framework was updated, > and/or new feature was added, and/or want to use more complex connection, > etc, etc, etc... > Thus, my honest opinion is that using v2, v3, ... is easy to understand, > especially for audio-graph-card. (audio-graph-card2, audio-graph-card3, ...) I think part of the thing that pushed me towards suggesting a more descriptive name was that your original posting made it sound like this wasn't going to replace the existing card for all applications which looking again isn't really the case and just numbering might be better. Sorry about the hassle there :/
Hi Mark Thank you for your feedback > Wealthy, billionaire, oligarch... :P audio-graph-billionaire-card... sound good :) > > To be honest, I don't think this version will be final version of > > Generic audio card driver. > > We will want to have more advanced generic audio card if framework was updated, > > and/or new feature was added, and/or want to use more complex connection, > > etc, etc, etc... > > > Thus, my honest opinion is that using v2, v3, ... is easy to understand, > > especially for audio-graph-card. (audio-graph-card2, audio-graph-card3, ...) > > I think part of the thing that pushed me towards suggesting a more > descriptive name was that your original posting made it sound like this > wasn't going to replace the existing card for all applications which > looking again isn't really the case and just numbering might be better. > Sorry about the hassle there :/ Sorry for the confusion. If you are OK, I want to use audio-graph-card2 at v4 patch. Thank you for your help !! Best regards --- Kuninori Morimoto
On Mon, Oct 04, 2021 at 08:52:44AM +0900, Kuninori Morimoto wrote:
> If you are OK, I want to use audio-graph-card2 at v4 patch.
Yes, that sounds the best option we've come up with.