* [PATCH 5/5] ASoC: rsnd: dma: use extended audio dmac registers when available @ 2019-03-13 5:58 Jiada Wang 2019-03-13 6:23 ` Kuninori Morimoto 0 siblings, 1 reply; 7+ messages in thread From: Jiada Wang @ 2019-03-13 5:58 UTC (permalink / raw) To: horms, magnus.damm, robh+dt, mark.rutland, lgirdwood, broonie, perex, tiwai, kuninori.morimoto.gx, geert Cc: linux-renesas-soc, devicetree, linux-kernel, alsa-devel, jiada_wang Some of SoCs have both basic and extended dmac registers set basic set only supports busif0 ~ busif3, in order to use busif4 ~ busif7, extended audio dmac registers need to be used. This patch changes to use extended dmac registers set when it is available in device-tree. Signed-off-by: Jiada Wang <jiada_wang@mentor.com> --- sound/soc/sh/rcar/dma.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/sound/soc/sh/rcar/dma.c b/sound/soc/sh/rcar/dma.c index 0324a5c39619..905502ccedba 100644 --- a/sound/soc/sh/rcar/dma.c +++ b/sound/soc/sh/rcar/dma.c @@ -830,7 +830,10 @@ int rsnd_dma_probe(struct rsnd_priv *priv) /* * for Gen2 or later */ - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "audmapp"); + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "extaudmapp"); + if (!res) + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, + "audmapp"); dmac = devm_kzalloc(dev, sizeof(*dmac), GFP_KERNEL); if (!dmac || !res) { dev_err(dev, "dma allocate failed\n"); -- 2.19.2 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH 5/5] ASoC: rsnd: dma: use extended audio dmac registers when available 2019-03-13 5:58 [PATCH 5/5] ASoC: rsnd: dma: use extended audio dmac registers when available Jiada Wang @ 2019-03-13 6:23 ` Kuninori Morimoto 2019-03-13 6:33 ` Kuninori Morimoto 2019-03-13 6:34 ` Jiada Wang 0 siblings, 2 replies; 7+ messages in thread From: Kuninori Morimoto @ 2019-03-13 6:23 UTC (permalink / raw) To: Jiada Wang Cc: horms, magnus.damm, robh+dt, mark.rutland, lgirdwood, broonie, perex, tiwai, geert, linux-renesas-soc, devicetree, linux-kernel, alsa-devel Hi Jiada > Some of SoCs have both basic and extended dmac registers set > basic set only supports busif0 ~ busif3, in order to use > busif4 ~ busif7, extended audio dmac registers need to be used. > > This patch changes to use extended dmac registers set when it is > available in device-tree. > > Signed-off-by: Jiada Wang <jiada_wang@mentor.com> > --- 1st of all, if you want to post this kind of patch-set, you *should* post driver side patch 1st, and if it was accepted, you need to post SoC side patch. Then, you need to indicate to SoC maintainer which branch/commit should be based. Otherwise, it will 100% breaks git-bisect. 2nd, in my understanding, our conclusion at Renesas-ML is that we don't need to think about basic/extend DMAC register. Because extend area is 100% covering basic area. In other words, it is compatible. Driver side don't need to think about it. > --- a/sound/soc/sh/rcar/dma.c > +++ b/sound/soc/sh/rcar/dma.c > @@ -830,7 +830,10 @@ int rsnd_dma_probe(struct rsnd_priv *priv) > /* > * for Gen2 or later > */ > - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "audmapp"); > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "extaudmapp"); > + if (!res) > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, > + "audmapp"); > dmac = devm_kzalloc(dev, sizeof(*dmac), GFP_KERNEL); > if (!dmac || !res) { > dev_err(dev, "dma allocate failed\n"); > -- > 2.19.2 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 5/5] ASoC: rsnd: dma: use extended audio dmac registers when available 2019-03-13 6:23 ` Kuninori Morimoto @ 2019-03-13 6:33 ` Kuninori Morimoto 2019-03-13 6:36 ` Jiada Wang 2019-03-13 6:34 ` Jiada Wang 1 sibling, 1 reply; 7+ messages in thread From: Kuninori Morimoto @ 2019-03-13 6:33 UTC (permalink / raw) To: Jiada Wang Cc: horms, magnus.damm, robh+dt, mark.rutland, lgirdwood, broonie, perex, tiwai, geert, linux-renesas-soc, devicetree, linux-kernel, alsa-devel Hi Jiada > > Some of SoCs have both basic and extended dmac registers set > > basic set only supports busif0 ~ busif3, in order to use > > busif4 ~ busif7, extended audio dmac registers need to be used. > > > > This patch changes to use extended dmac registers set when it is > > available in device-tree. > > > > Signed-off-by: Jiada Wang <jiada_wang@mentor.com> > > --- > > 1st of all, if you want to post this kind of patch-set, > you *should* post driver side patch 1st, and if it was accepted, > you need to post SoC side patch. Then, you need to indicate > to SoC maintainer which branch/commit should be based. > Otherwise, it will 100% breaks git-bisect. Grr, orz my head was 100% broken. This time, your patch doesn't breaks git-bisect. I'm so sorry. Best regards --- Kuninori Morimoto ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 5/5] ASoC: rsnd: dma: use extended audio dmac registers when available 2019-03-13 6:33 ` Kuninori Morimoto @ 2019-03-13 6:36 ` Jiada Wang 0 siblings, 0 replies; 7+ messages in thread From: Jiada Wang @ 2019-03-13 6:36 UTC (permalink / raw) To: Kuninori Morimoto Cc: horms, magnus.damm, robh+dt, mark.rutland, lgirdwood, broonie, perex, tiwai, geert, linux-renesas-soc, devicetree, linux-kernel, alsa-devel Hi Morimoto-san On 2019/03/13 15:33, Kuninori Morimoto wrote: > > Hi Jiada > >>> Some of SoCs have both basic and extended dmac registers set >>> basic set only supports busif0 ~ busif3, in order to use >>> busif4 ~ busif7, extended audio dmac registers need to be used. >>> >>> This patch changes to use extended dmac registers set when it is >>> available in device-tree. >>> >>> Signed-off-by: Jiada Wang <jiada_wang@mentor.com> >>> --- >> >> 1st of all, if you want to post this kind of patch-set, >> you *should* post driver side patch 1st, and if it was accepted, >> you need to post SoC side patch. Then, you need to indicate >> to SoC maintainer which branch/commit should be based. >> Otherwise, it will 100% breaks git-bisect. > > Grr, orz > my head was 100% broken. > This time, your patch doesn't breaks git-bisect. > I'm so sorry. > right, no problem. anyway, keep driver change before dts change, is always a good practice Thanks, Jiada > Best regards > --- > Kuninori Morimoto > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 5/5] ASoC: rsnd: dma: use extended audio dmac registers when available 2019-03-13 6:23 ` Kuninori Morimoto 2019-03-13 6:33 ` Kuninori Morimoto @ 2019-03-13 6:34 ` Jiada Wang 2019-03-13 6:57 ` Kuninori Morimoto 1 sibling, 1 reply; 7+ messages in thread From: Jiada Wang @ 2019-03-13 6:34 UTC (permalink / raw) To: Kuninori Morimoto Cc: horms, magnus.damm, robh+dt, mark.rutland, lgirdwood, broonie, perex, tiwai, geert, linux-renesas-soc, devicetree, linux-kernel, alsa-devel Hi Morimoto-san thanks for your comments On 2019/03/13 15:23, Kuninori Morimoto wrote: > > Hi Jiada > >> Some of SoCs have both basic and extended dmac registers set >> basic set only supports busif0 ~ busif3, in order to use >> busif4 ~ busif7, extended audio dmac registers need to be used. >> >> This patch changes to use extended dmac registers set when it is >> available in device-tree. >> >> Signed-off-by: Jiada Wang <jiada_wang@mentor.com> >> --- > > 1st of all, if you want to post this kind of patch-set, > you *should* post driver side patch 1st, and if it was accepted, > you need to post SoC side patch. Then, you need to indicate > to SoC maintainer which branch/commit should be based. > Otherwise, it will 100% breaks git-bisect. > yes, you're right, sorry about this > 2nd, in my understanding, our conclusion at Renesas-ML > is that we don't need to think about basic/extend DMAC register. > Because extend area is 100% covering basic area. > In other words, it is compatible. > Driver side don't need to think about it. > I am a little confused, because latest comment received from simon, suggests to let driver to decide which register set to use. for me, I think it's not necessary, if extended register set is available, driver shall always use it. Thanks, Jiada >> --- a/sound/soc/sh/rcar/dma.c >> +++ b/sound/soc/sh/rcar/dma.c >> @@ -830,7 +830,10 @@ int rsnd_dma_probe(struct rsnd_priv *priv) >> /* >> * for Gen2 or later >> */ >> - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "audmapp"); >> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "extaudmapp"); >> + if (!res) >> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, >> + "audmapp"); >> dmac = devm_kzalloc(dev, sizeof(*dmac), GFP_KERNEL); >> if (!dmac || !res) { >> dev_err(dev, "dma allocate failed\n"); >> -- >> 2.19.2 >> ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 5/5] ASoC: rsnd: dma: use extended audio dmac registers when available 2019-03-13 6:34 ` Jiada Wang @ 2019-03-13 6:57 ` Kuninori Morimoto 2019-03-13 8:52 ` Geert Uytterhoeven 0 siblings, 1 reply; 7+ messages in thread From: Kuninori Morimoto @ 2019-03-13 6:57 UTC (permalink / raw) To: horms Cc: Jiada Wang, magnus.damm, robh+dt, mark.rutland, lgirdwood, broonie, perex, tiwai, geert, linux-renesas-soc, devicetree, linux-kernel, alsa-devel Hi Simon > > 2nd, in my understanding, our conclusion at Renesas-ML > > is that we don't need to think about basic/extend DMAC register. > > Because extend area is 100% covering basic area. > > In other words, it is compatible. > > Driver side don't need to think about it. > > > I am a little confused, > because latest comment received from simon, suggests to let driver to > decide which register set to use. > > for me, I think it's not necessary, if extended register set is available, > driver shall always use it. I can agree to have both basic/extend register if driver need to switch its behavior. But this case, there is nothing to do on driver side. In other words, SoC always need to use extend register if it has. I don't know why datasheet is indicating both area. Maybe it is because for Gen3 all-in ? I'm not sure. Anyway, Simon, can you agree about it ? Having both basic/extend register is just noise for driver. Best regards --- Kuninori Morimoto ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 5/5] ASoC: rsnd: dma: use extended audio dmac registers when available 2019-03-13 6:57 ` Kuninori Morimoto @ 2019-03-13 8:52 ` Geert Uytterhoeven 0 siblings, 0 replies; 7+ messages in thread From: Geert Uytterhoeven @ 2019-03-13 8:52 UTC (permalink / raw) To: Kuninori Morimoto Cc: Simon Horman, Jiada Wang, Magnus Damm, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai, Linux-Renesas, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, Linux Kernel Mailing List, ALSA Development Mailing List Hi Morimoto-san, On Wed, Mar 13, 2019 at 7:57 AM Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> wrote: > > > 2nd, in my understanding, our conclusion at Renesas-ML > > > is that we don't need to think about basic/extend DMAC register. > > > Because extend area is 100% covering basic area. > > > In other words, it is compatible. > > > Driver side don't need to think about it. > > > > > I am a little confused, > > because latest comment received from simon, suggests to let driver to > > decide which register set to use. > > > > for me, I think it's not necessary, if extended register set is available, > > driver shall always use it. > > I can agree to have both basic/extend register > if driver need to switch its behavior. > But this case, there is nothing to do on driver side. > In other words, SoC always need to use extend > register if it has. > I don't know why datasheet is indicating both area. > Maybe it is because for Gen3 all-in ? I'm not sure. > > Anyway, Simon, can you agree about it ? > Having both basic/extend register is just noise for driver. I can follow your rationale of only describing the extended register set, if available. However: 1) The DT bindings should state clearly that the AUDMAPP register block should point to the extended register set, if available, 2) Can the driver distinguish between an old DTB describing the basic register set, and a new DTB describing the extended register set? I.e. will the driver avoid using busif4-7 when using an old DTB describing the basic register set, to maintain backwards compatibility? Thanks! P.S. The binding doc seems to need some love. I came up with the following a while ago, but got interrupted. Feel free to steal ;-) --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt @@ -338,9 +338,9 @@ Required properties: ============================================= - compatible : "renesas,rcar_sound-<soctype>", fallbacks - "renesas,rcar_sound-gen1" if generation1, and - "renesas,rcar_sound-gen2" if generation2 (or RZ/G1) - "renesas,rcar_sound-gen3" if generation3 (or RZ/G2) + "renesas,rcar_sound-gen1" if R-Car Gen1, and + "renesas,rcar_sound-gen2" if R-Car Gen2 or RZ/G1 + "renesas,rcar_sound-gen3" if R-Car Gen3 or RZ/G2 Examples with soctypes are: - "renesas,rcar_sound-r8a7743" (RZ/G1M) - "renesas,rcar_sound-r8a7745" (RZ/G1E) @@ -357,8 +357,10 @@ Required properties: - "renesas,rcar_sound-r8a77990" (R-Car E3) - reg : Should contain the register physical address. required register is - SRU/ADG/SSI if generation1 - SRU/ADG/SSIU/SSI if generation2 + SRU/ADG/SSI if R-Car Gen1 + SCU/ADG/SSIU/SSI/AUDMAPP if R-Car Gen2, + R-Car Gen3, RZ/G1, or RZ/G2. +- reg-names = "scu", "adg", "ssiu", "ssi", "audmapp"; - rcar_sound,ssi : Should contain SSI feature. The number of SSI subnode should be same as HW. see below for detail. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-03-13 8:52 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-03-13 5:58 [PATCH 5/5] ASoC: rsnd: dma: use extended audio dmac registers when available Jiada Wang 2019-03-13 6:23 ` Kuninori Morimoto 2019-03-13 6:33 ` Kuninori Morimoto 2019-03-13 6:36 ` Jiada Wang 2019-03-13 6:34 ` Jiada Wang 2019-03-13 6:57 ` Kuninori Morimoto 2019-03-13 8:52 ` Geert Uytterhoeven
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).