Messages in this thread | | | Subject | Re: [PATCH 5/5] ASoC: rsnd: dma: use extended audio dmac registers when available | From | Jiada Wang <> | Date | Wed, 13 Mar 2019 15:34:00 +0900 |
| |
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 >>
| |