From: Ben Dooks <ben.dooks@codethink.co.uk>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
linux-kernel@lists.codethink.co.uk, dmaengine@vger.kernel.org,
Vinod Koul <vinod.koul@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
Linux-sh list <linux-sh@vger.kernel.org>,
magnus.damm@opensource.se, Simon Horman <horms@verge.net.au>,
Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v2 8/9] DMA: shdma: initial of common code
Date: Wed, 04 Jun 2014 15:54:26 +0000 [thread overview]
Message-ID: <538F4132.4030204@codethink.co.uk> (raw)
In-Reply-To: <CAMuHMdU-FEnAjjcACaFt_-5i4EFDnj=uqrM_ew+nz7n9+ndbSQ@mail.gmail.com>
On 21/05/14 21:14, Geert Uytterhoeven wrote:
> Hi Ben,
>
> On Tue, Apr 15, 2014 at 11:54 AM, Ben Dooks <ben.dooks@codethink.co.uk> wrote:
>>>> static struct dma_chan *shdma_of_xlate(struct of_phandle_args
>>>> *dma_spec,
>>>> struct of_dma *ofdma)
>>>> {
>>>> + struct platform_device *pdev = ofdma->of_dma_data;
>>>> u32 id = dma_spec->args[0];
>>>> dma_cap_mask_t mask;
>>>> struct dma_chan *chan;
>>>>
>>>> - if (dma_spec->args_count != 1)
>>>> + if (dma_spec->args_count = 2) {
>>>> + struct shdma_of_state *state >>>> platform_get_drvdata(pdev);
>>>> + struct shdma_of_client *client;
>>>> +
>>>> + client = shdma_of_find_client(state, id);
>>>> + if (!client) {
>>>> + client = devm_kzalloc(&pdev->dev,
>>>> sizeof(*client),
>>>> + GFP_KERNEL);
>>>> + if (!client)
>>>> + return NULL;
>>>> +
>>>> + client->index >>>> atomic_inc_return(&of_slave_index);
>>>> + client->cfg.slave_id = id;
>>>> + client->cfg.mid_rid = id;
>>>> + client->cfg.chcr = dma_spec->args[1];
>>>
>>>
>>> Can you explain the purpose of setting the chcr in DT? For all I can
>>> tell, this should come from the device driver when that calls the
>>> dma_slave_config function, unlike the mid_rid value.
>>
>>
>> See previous note about transfer-widths and register-sizes not always
>> matching. I also do not have any idea about other SoCs in the series
>> if there are any differences between channel settings.
>
> If you look for sh_dmae_slave_config in arch/arm arch/sh, you find the values
> for the existing board support.
>
> The same device always seem to use the same value, i.e. MMC always uses
> 32-bit, SCIF uses 8-bit, SDHI uses 16-bit. So I think it could be hardcoded
> in the device driver (passed via enum dma_slave_buswidth {src,dst}_addr_width
> in dma_slave_config?), and you can drop the field in the bindings.
>
> Notes:
> - RSPI is special: on SH, it's 16-bit, while QSPI on R-Car uses 8-bit.
> - SDHI uses 32-bit according to the R-Car docs, but the (working) code
> uses 16-bit?
I will move to using the configuration passed when the slave is used
instead of the one in the slave table.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
WARNING: multiple messages have this Message-ID (diff)
From: Ben Dooks <ben.dooks@codethink.co.uk>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
linux-kernel@lists.codethink.co.uk, dmaengine@vger.kernel.org,
Vinod Koul <vinod.koul@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
Linux-sh list <linux-sh@vger.kernel.org>,
magnus.damm@opensource.se, Simon Horman <horms@verge.net.au>,
Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v2 8/9] DMA: shdma: initial of common code
Date: Wed, 04 Jun 2014 16:54:26 +0100 [thread overview]
Message-ID: <538F4132.4030204@codethink.co.uk> (raw)
In-Reply-To: <CAMuHMdU-FEnAjjcACaFt_-5i4EFDnj=uqrM_ew+nz7n9+ndbSQ@mail.gmail.com>
On 21/05/14 21:14, Geert Uytterhoeven wrote:
> Hi Ben,
>
> On Tue, Apr 15, 2014 at 11:54 AM, Ben Dooks <ben.dooks@codethink.co.uk> wrote:
>>>> static struct dma_chan *shdma_of_xlate(struct of_phandle_args
>>>> *dma_spec,
>>>> struct of_dma *ofdma)
>>>> {
>>>> + struct platform_device *pdev = ofdma->of_dma_data;
>>>> u32 id = dma_spec->args[0];
>>>> dma_cap_mask_t mask;
>>>> struct dma_chan *chan;
>>>>
>>>> - if (dma_spec->args_count != 1)
>>>> + if (dma_spec->args_count == 2) {
>>>> + struct shdma_of_state *state =
>>>> platform_get_drvdata(pdev);
>>>> + struct shdma_of_client *client;
>>>> +
>>>> + client = shdma_of_find_client(state, id);
>>>> + if (!client) {
>>>> + client = devm_kzalloc(&pdev->dev,
>>>> sizeof(*client),
>>>> + GFP_KERNEL);
>>>> + if (!client)
>>>> + return NULL;
>>>> +
>>>> + client->index =
>>>> atomic_inc_return(&of_slave_index);
>>>> + client->cfg.slave_id = id;
>>>> + client->cfg.mid_rid = id;
>>>> + client->cfg.chcr = dma_spec->args[1];
>>>
>>>
>>> Can you explain the purpose of setting the chcr in DT? For all I can
>>> tell, this should come from the device driver when that calls the
>>> dma_slave_config function, unlike the mid_rid value.
>>
>>
>> See previous note about transfer-widths and register-sizes not always
>> matching. I also do not have any idea about other SoCs in the series
>> if there are any differences between channel settings.
>
> If you look for sh_dmae_slave_config in arch/arm arch/sh, you find the values
> for the existing board support.
>
> The same device always seem to use the same value, i.e. MMC always uses
> 32-bit, SCIF uses 8-bit, SDHI uses 16-bit. So I think it could be hardcoded
> in the device driver (passed via enum dma_slave_buswidth {src,dst}_addr_width
> in dma_slave_config?), and you can drop the field in the bindings.
>
> Notes:
> - RSPI is special: on SH, it's 16-bit, while QSPI on R-Car uses 8-bit.
> - SDHI uses 32-bit according to the R-Car docs, but the (working) code
> uses 16-bit?
I will move to using the configuration passed when the slave is used
instead of the one in the slave table.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
next prev parent reply other threads:[~2014-06-04 15:54 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-14 21:35 Updates Renesas OF-DMA code Ben Dooks
2014-04-14 21:35 ` Ben Dooks
2014-04-14 21:35 ` [PATCH v2 1/9] ARM: shmobile: r8a7790: add dmac0,dmac1 clocks Ben Dooks
2014-04-14 21:35 ` Ben Dooks
2014-05-13 9:23 ` Geert Uytterhoeven
2014-05-13 9:23 ` Geert Uytterhoeven
2014-06-04 15:54 ` Ben Dooks
2014-06-04 15:54 ` Ben Dooks
2014-04-14 21:35 ` [PATCH v2 2/9] ARM: shmobile: r8a7790: add dma defines for sys and audio dmacs Ben Dooks
2014-04-14 21:35 ` Ben Dooks
2014-04-14 22:10 ` Arnd Bergmann
2014-04-14 22:10 ` Arnd Bergmann
2014-04-14 22:51 ` Simon Horman
2014-04-14 22:51 ` Simon Horman
2014-04-15 9:46 ` Ben Dooks
2014-04-15 9:46 ` Ben Dooks
2014-05-13 8:51 ` Geert Uytterhoeven
2014-05-13 8:51 ` Geert Uytterhoeven
2014-05-13 10:46 ` Geert Uytterhoeven
2014-05-13 10:46 ` Geert Uytterhoeven
[not found] ` <CAMuHMdUsRSGuGgnAgjKtOWmx3C_PWUxAU=2XTvPE1M9o13S1uA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-27 8:08 ` Geert Uytterhoeven
2014-05-27 8:08 ` Geert Uytterhoeven
2014-09-24 12:27 ` [PATCH v2 2/9] ARM: shmobile: r8a7790: Add DU node to device tree Laurent Pinchart
2014-04-14 21:35 ` [PATCH v2 3/9] ARM: shmobile: r8a7790: add dmac0 dmac1 nodes Ben Dooks
2014-04-14 21:35 ` Ben Dooks
[not found] ` <1397511312-4845-4-git-send-email-ben.dooks-4yDnlxn2s6sWdaTGBSpHTA@public.gmane.org>
2014-05-13 12:00 ` Geert Uytterhoeven
2014-05-13 12:00 ` Geert Uytterhoeven
[not found] ` <CAMuHMdUNAFJEFWYe5cpKaZqoZFhRA1s0YBntT5ZVJaieSj8ovQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-06-04 16:04 ` Ben Dooks
2014-06-04 16:04 ` Ben Dooks
2014-05-15 13:11 ` Geert Uytterhoeven
2014-05-15 13:11 ` Geert Uytterhoeven
2014-04-14 21:35 ` [PATCH v2 4/9] ARM: shmobile: r8a7790: Add DMA for MMCIF1 Ben Dooks
2014-04-14 21:35 ` Ben Dooks
2014-04-14 21:35 ` [PATCH v2 5/9] ARM: shmobile: add Audio DMAC clocks Ben Dooks
2014-04-14 21:35 ` Ben Dooks
2014-04-14 21:35 ` [PATCH v2 6/9] ARM: shmobile: r8a7790: add audio dmac node Ben Dooks
2014-04-14 21:35 ` Ben Dooks
2014-05-13 8:53 ` Geert Uytterhoeven
2014-05-13 8:53 ` Geert Uytterhoeven
2014-05-13 12:10 ` Geert Uytterhoeven
2014-05-13 12:10 ` Geert Uytterhoeven
2014-05-15 13:12 ` Geert Uytterhoeven
2014-05-15 13:12 ` Geert Uytterhoeven
[not found] ` <1397511312-4845-1-git-send-email-ben.dooks-4yDnlxn2s6sWdaTGBSpHTA@public.gmane.org>
2014-04-14 21:35 ` [PATCH v2 7/9] ARM: shmobile: lager: enable sysdma units 0 and 1 Ben Dooks
2014-04-14 21:35 ` Ben Dooks
2014-09-24 12:27 ` [PATCH v2 7/9] ARM: shmobile: lager: Enable DU device in DT Laurent Pinchart
2014-09-24 13:01 ` Sergei Shtylyov
2014-09-24 13:09 ` Laurent Pinchart
2014-04-14 21:35 ` [PATCH v2 8/9] DMA: shdma: initial of common code Ben Dooks
2014-04-14 21:35 ` Ben Dooks
2014-04-14 22:06 ` Arnd Bergmann
2014-04-14 22:06 ` Arnd Bergmann
2014-04-15 9:54 ` Ben Dooks
2014-04-15 9:54 ` Ben Dooks
2014-05-21 20:14 ` Geert Uytterhoeven
2014-05-21 20:14 ` Geert Uytterhoeven
2014-06-04 15:54 ` Ben Dooks [this message]
2014-06-04 15:54 ` Ben Dooks
2014-04-14 21:35 ` [PATCH v2 9/9] DMA: shdma: wire r8a7790 Ben Dooks
2014-04-14 21:35 ` Ben Dooks
2014-04-15 12:20 ` Sergei Shtylyov
2014-04-15 12:20 ` Sergei Shtylyov
2014-04-18 1:32 ` Kuninori Morimoto
2014-04-18 1:32 ` Kuninori Morimoto
2014-04-23 13:08 ` Ben Dooks
2014-04-23 13:08 ` Ben Dooks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=538F4132.4030204@codethink.co.uk \
--to=ben.dooks@codethink.co.uk \
--cc=arnd@arndb.de \
--cc=dan.j.williams@intel.com \
--cc=devicetree@vger.kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=g.liakhovetski@gmx.de \
--cc=geert@linux-m68k.org \
--cc=horms@verge.net.au \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=linux-kernel@lists.codethink.co.uk \
--cc=linux-sh@vger.kernel.org \
--cc=magnus.damm@opensource.se \
--cc=vinod.koul@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.