* Re: [PATCH] dmaengine: xgene-dma: fix spelling mistake "descripto" -> "descriptor"
From: Vinod Koul @ 2019-04-26 11:27 UTC (permalink / raw)
To: Colin King; +Cc: Dan Williams, dmaengine, kernel-janitors, linux-kernel
In-Reply-To: <20190415153028.24849-1-colin.king@canonical.com>
On 15-04-19, 16:30, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> There is a spelling mistake in a chan_dbg message, fix it.
Applied, thanks
--
~Vinod
^ permalink raw reply
* [2/2] dmaengine: milbeaut: Add Milbeaut AXI DMA controller
From: Vinod Koul @ 2019-04-26 11:46 UTC (permalink / raw)
To: Kazuhiro Kasai
Cc: robh+dt, mark.rutland, dmaengine, devicetree, orito.takao,
sugaya.taichi, kanematsu.shinji, jaswinder.singh,
masami.hiramatsu, linux-kernel
On 25-03-19, 13:15, Kazuhiro Kasai wrote:
> Add Milbeaut AXI DMA controller. This DMA controller has
> only capable of memory to memory transfer.
Have you tested this with dmatest?
> +struct m10v_dma_chan {
> + struct dma_chan chan;
> + struct m10v_dma_device *mdmac;
> + void __iomem *regs;
> + int irq;
> + struct m10v_dma_desc mdesc;
So there is a *single* descriptor? Not a list??
> +static void m10v_xdmac_disable_dma(struct m10v_dma_device *mdmac)
> +{
> + unsigned int val;
> +
> + val = readl(mdmac->regs + M10V_XDACS);
> + val &= ~M10V_XDACS_XE;
> + val |= FIELD_PREP(M10V_XDACS_XE, 0);
> + writel(val, mdmac->regs + M10V_XDACS);
Why not create a modifyl() macro and use it here
> +static void m10v_xdmac_issue_pending(struct dma_chan *chan)
> +{
> + struct m10v_dma_chan *mchan = to_m10v_dma_chan(chan);
> +
> + m10v_xdmac_config_chan(mchan);
> +
> + m10v_xdmac_enable_chan(mchan);
You dont check if anything is already running or not?
> +static dma_cookie_t m10v_xdmac_tx_submit(struct dma_async_tx_descriptor *txd)
> +{
> + struct m10v_dma_chan *mchan = to_m10v_dma_chan(txd->chan);
> + dma_cookie_t cookie;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&mchan->lock, flags);
> + cookie = dma_cookie_assign(txd);
> + spin_unlock_irqrestore(&mchan->lock, flags);
> +
> + return cookie;
sounds like vchan_tx_submit() i think you can use virt-dma layer and then
get rid of artificial limit in driver and be able to queue up the txn on
dmaengine.
> +static struct dma_async_tx_descriptor *
> +m10v_xdmac_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dst,
> + dma_addr_t src, size_t len, unsigned long flags)
> +{
> + struct m10v_dma_chan *mchan = to_m10v_dma_chan(chan);
> +
> + dma_async_tx_descriptor_init(&mchan->mdesc.txd, chan);
> + mchan->mdesc.txd.tx_submit = m10v_xdmac_tx_submit;
> + mchan->mdesc.txd.callback = NULL;
> + mchan->mdesc.txd.flags = flags;
> + mchan->mdesc.txd.cookie = -EBUSY;
> +
> + mchan->mdesc.len = len;
> + mchan->mdesc.src = src;
> + mchan->mdesc.dst = dst;
> +
> + return &mchan->mdesc.txd;
So you support single descriptor and dont check if this has been already
configured. So I guess this has been tested by doing txn one at a time
and not submitted bunch of txn and wait for them to complete. Please fix
that to really enable dmaengine capabilities.
> +static int m10v_xdmac_remove(struct platform_device *pdev)
> +{
> + struct m10v_dma_chan *mchan;
> + struct m10v_dma_device *mdmac = platform_get_drvdata(pdev);
> + int i;
> +
> + m10v_xdmac_disable_dma(mdmac);
> +
> + for (i = 0; i < mdmac->channels; i++) {
> + mchan = &mdmac->mchan[i];
> + devm_free_irq(&pdev->dev, mchan->irq, mchan);
> + }
No call to dma_async_device_unregister()?
^ permalink raw reply
* Re: [PATCH 2/2] dmaengine: milbeaut: Add Milbeaut AXI DMA controller
From: Vinod Koul @ 2019-04-26 11:46 UTC (permalink / raw)
To: Kazuhiro Kasai
Cc: robh+dt, mark.rutland, dmaengine, devicetree, orito.takao,
sugaya.taichi, kanematsu.shinji, jaswinder.singh,
masami.hiramatsu, linux-kernel
In-Reply-To: <1553487314-9185-3-git-send-email-kasai.kazuhiro@socionext.com>
On 25-03-19, 13:15, Kazuhiro Kasai wrote:
> Add Milbeaut AXI DMA controller. This DMA controller has
> only capable of memory to memory transfer.
Have you tested this with dmatest?
> +struct m10v_dma_chan {
> + struct dma_chan chan;
> + struct m10v_dma_device *mdmac;
> + void __iomem *regs;
> + int irq;
> + struct m10v_dma_desc mdesc;
So there is a *single* descriptor? Not a list??
> +static void m10v_xdmac_disable_dma(struct m10v_dma_device *mdmac)
> +{
> + unsigned int val;
> +
> + val = readl(mdmac->regs + M10V_XDACS);
> + val &= ~M10V_XDACS_XE;
> + val |= FIELD_PREP(M10V_XDACS_XE, 0);
> + writel(val, mdmac->regs + M10V_XDACS);
Why not create a modifyl() macro and use it here
> +static void m10v_xdmac_issue_pending(struct dma_chan *chan)
> +{
> + struct m10v_dma_chan *mchan = to_m10v_dma_chan(chan);
> +
> + m10v_xdmac_config_chan(mchan);
> +
> + m10v_xdmac_enable_chan(mchan);
You dont check if anything is already running or not?
> +static dma_cookie_t m10v_xdmac_tx_submit(struct dma_async_tx_descriptor *txd)
> +{
> + struct m10v_dma_chan *mchan = to_m10v_dma_chan(txd->chan);
> + dma_cookie_t cookie;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&mchan->lock, flags);
> + cookie = dma_cookie_assign(txd);
> + spin_unlock_irqrestore(&mchan->lock, flags);
> +
> + return cookie;
sounds like vchan_tx_submit() i think you can use virt-dma layer and then
get rid of artificial limit in driver and be able to queue up the txn on
dmaengine.
> +static struct dma_async_tx_descriptor *
> +m10v_xdmac_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dst,
> + dma_addr_t src, size_t len, unsigned long flags)
> +{
> + struct m10v_dma_chan *mchan = to_m10v_dma_chan(chan);
> +
> + dma_async_tx_descriptor_init(&mchan->mdesc.txd, chan);
> + mchan->mdesc.txd.tx_submit = m10v_xdmac_tx_submit;
> + mchan->mdesc.txd.callback = NULL;
> + mchan->mdesc.txd.flags = flags;
> + mchan->mdesc.txd.cookie = -EBUSY;
> +
> + mchan->mdesc.len = len;
> + mchan->mdesc.src = src;
> + mchan->mdesc.dst = dst;
> +
> + return &mchan->mdesc.txd;
So you support single descriptor and dont check if this has been already
configured. So I guess this has been tested by doing txn one at a time
and not submitted bunch of txn and wait for them to complete. Please fix
that to really enable dmaengine capabilities.
> +static int m10v_xdmac_remove(struct platform_device *pdev)
> +{
> + struct m10v_dma_chan *mchan;
> + struct m10v_dma_device *mdmac = platform_get_drvdata(pdev);
> + int i;
> +
> + m10v_xdmac_disable_dma(mdmac);
> +
> + for (i = 0; i < mdmac->channels; i++) {
> + mchan = &mdmac->mchan[i];
> + devm_free_irq(&pdev->dev, mchan->irq, mchan);
> + }
No call to dma_async_device_unregister()?
--
~Vinod
^ permalink raw reply
* [v2,2/3] dmaengine: imx-sdma: Only check ratio on parts that support 1:1
From: Vinod Koul @ 2019-04-26 11:48 UTC (permalink / raw)
To: Angus Ainslie (Purism)
Cc: angus.ainslie, Rob Herring, Mark Rutland, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Dan Williams, Lucas Stach, Carlo Caione, Daniel Baluta,
Guido Günther, devicetree, linux-arm-kernel, linux-kernel,
dmaengine
On 29-03-19, 08:21, Angus Ainslie (Purism) wrote:
> On imx8mq B0 chip, AHB/SDMA clock ratio 2:1 can't be supported,
> since SDMA clock ratio has to be increased to 250Mhz, AHB can't reach
> to 500Mhz, so use 1:1 instead.
>
> To limit this change to the imx8mq for now this patch also adds an
> im8mq-sdma compatible string.
Applied, thanks
^ permalink raw reply
* Re: [PATCH v2 2/3] dmaengine: imx-sdma: Only check ratio on parts that support 1:1
From: Vinod Koul @ 2019-04-26 11:48 UTC (permalink / raw)
To: Angus Ainslie (Purism)
Cc: angus.ainslie, Rob Herring, Mark Rutland, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Dan Williams, Lucas Stach, Carlo Caione, Daniel Baluta,
Guido Günther, devicetree, linux-arm-kernel, linux-kernel,
dmaengine
In-Reply-To: <20190329152130.18411-3-angus@akkea.ca>
On 29-03-19, 08:21, Angus Ainslie (Purism) wrote:
> On imx8mq B0 chip, AHB/SDMA clock ratio 2:1 can't be supported,
> since SDMA clock ratio has to be increased to 250Mhz, AHB can't reach
> to 500Mhz, so use 1:1 instead.
>
> To limit this change to the imx8mq for now this patch also adds an
> im8mq-sdma compatible string.
Applied, thanks
--
~Vinod
^ permalink raw reply
* dmaengine: fsl-qdma: fixed the source/destination descriptior format
From: Vinod Koul @ 2019-04-26 11:50 UTC (permalink / raw)
To: Peng Ma; +Cc: dan.j.williams, leoyang.li, dmaengine, linux-kernel
On 19-04-19, 08:46, Peng Ma wrote:
> CMD of Source/Destination descriptior format should be lower of
s/descriptior/descriptor
> struct fsl_qdma_engine number data address.
>
> Signed-off-by: Peng Ma <peng.ma@nxp.com>
> ---
> drivers/dma/fsl-qdma.c | 29 ++++++++++++++++++-----------
> 1 files changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/dma/fsl-qdma.c b/drivers/dma/fsl-qdma.c
> index aa1d0ae..542765a 100644
> --- a/drivers/dma/fsl-qdma.c
> +++ b/drivers/dma/fsl-qdma.c
> @@ -113,6 +113,7 @@
> /* Field definition for Descriptor offset */
> #define QDMA_CCDF_STATUS 20
> #define QDMA_CCDF_OFFSET 20
> +#define QDMA_SDDF_CMD(x) (((u64)(x)) << 32)
>
> /* Field definition for safe loop count*/
> #define FSL_QDMA_HALT_COUNT 1500
> @@ -214,6 +215,12 @@ struct fsl_qdma_engine {
>
> };
>
> +static inline void
> +qdma_sddf_set_cmd(struct fsl_qdma_format *sddf, u32 val)
> +{
> + sddf->data = QDMA_SDDF_CMD(val);
> +}
> +
> static inline u64
> qdma_ccdf_addr_get64(const struct fsl_qdma_format *ccdf)
> {
> @@ -341,6 +348,7 @@ static void fsl_qdma_free_chan_resources(struct dma_chan *chan)
> static void fsl_qdma_comp_fill_memcpy(struct fsl_qdma_comp *fsl_comp,
> dma_addr_t dst, dma_addr_t src, u32 len)
> {
> + u32 cmd;
> struct fsl_qdma_format *sdf, *ddf;
> struct fsl_qdma_format *ccdf, *csgf_desc, *csgf_src, *csgf_dest;
>
> @@ -353,6 +361,7 @@ static void fsl_qdma_comp_fill_memcpy(struct fsl_qdma_comp *fsl_comp,
>
> memset(fsl_comp->virt_addr, 0, FSL_QDMA_COMMAND_BUFFER_SIZE);
> memset(fsl_comp->desc_virt_addr, 0, FSL_QDMA_DESCRIPTOR_BUFFER_SIZE);
> +
> /* Head Command Descriptor(Frame Descriptor) */
> qdma_desc_addr_set64(ccdf, fsl_comp->bus_addr + 16);
> qdma_ccdf_set_format(ccdf, qdma_ccdf_get_offset(ccdf));
> @@ -369,14 +378,14 @@ static void fsl_qdma_comp_fill_memcpy(struct fsl_qdma_comp *fsl_comp,
> /* This entry is the last entry. */
> qdma_csgf_set_f(csgf_dest, len);
> /* Descriptor Buffer */
> - sdf->data =
> - cpu_to_le64(FSL_QDMA_CMD_RWTTYPE <<
> - FSL_QDMA_CMD_RWTTYPE_OFFSET);
> - ddf->data =
> - cpu_to_le64(FSL_QDMA_CMD_RWTTYPE <<
> - FSL_QDMA_CMD_RWTTYPE_OFFSET);
> - ddf->data |=
> - cpu_to_le64(FSL_QDMA_CMD_LWC << FSL_QDMA_CMD_LWC_OFFSET);
> + cmd = cpu_to_le32(FSL_QDMA_CMD_RWTTYPE <<
> + FSL_QDMA_CMD_RWTTYPE_OFFSET);
> + qdma_sddf_set_cmd(sdf, cmd);
> +
> + cmd = cpu_to_le32(FSL_QDMA_CMD_RWTTYPE <<
> + FSL_QDMA_CMD_RWTTYPE_OFFSET);
> + cmd |= cpu_to_le32(FSL_QDMA_CMD_LWC << FSL_QDMA_CMD_LWC_OFFSET);
> + qdma_sddf_set_cmd(ddf, cmd);
> }
>
> /*
> @@ -701,10 +710,8 @@ static irqreturn_t fsl_qdma_error_handler(int irq, void *dev_id)
>
> intr = qdma_readl(fsl_qdma, status + FSL_QDMA_DEDR);
>
> - if (intr) {
> + if (intr)
> dev_err(fsl_qdma->dma_dev.dev, "DMA transaction error!\n");
> - return IRQ_NONE;
> - }
this seems unrelated can you explain?
>
> qdma_writel(fsl_qdma, FSL_QDMA_DEDR_CLEAR, status + FSL_QDMA_DEDR);
> return IRQ_HANDLED;
> --
> 1.7.1
^ permalink raw reply
* Re: [PATCH] dmaengine: fsl-qdma: fixed the source/destination descriptior format
From: Vinod Koul @ 2019-04-26 11:50 UTC (permalink / raw)
To: Peng Ma; +Cc: dan.j.williams, leoyang.li, dmaengine, linux-kernel
In-Reply-To: <20190419084629.41742-1-peng.ma@nxp.com>
On 19-04-19, 08:46, Peng Ma wrote:
> CMD of Source/Destination descriptior format should be lower of
s/descriptior/descriptor
> struct fsl_qdma_engine number data address.
>
> Signed-off-by: Peng Ma <peng.ma@nxp.com>
> ---
> drivers/dma/fsl-qdma.c | 29 ++++++++++++++++++-----------
> 1 files changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/dma/fsl-qdma.c b/drivers/dma/fsl-qdma.c
> index aa1d0ae..542765a 100644
> --- a/drivers/dma/fsl-qdma.c
> +++ b/drivers/dma/fsl-qdma.c
> @@ -113,6 +113,7 @@
> /* Field definition for Descriptor offset */
> #define QDMA_CCDF_STATUS 20
> #define QDMA_CCDF_OFFSET 20
> +#define QDMA_SDDF_CMD(x) (((u64)(x)) << 32)
>
> /* Field definition for safe loop count*/
> #define FSL_QDMA_HALT_COUNT 1500
> @@ -214,6 +215,12 @@ struct fsl_qdma_engine {
>
> };
>
> +static inline void
> +qdma_sddf_set_cmd(struct fsl_qdma_format *sddf, u32 val)
> +{
> + sddf->data = QDMA_SDDF_CMD(val);
> +}
> +
> static inline u64
> qdma_ccdf_addr_get64(const struct fsl_qdma_format *ccdf)
> {
> @@ -341,6 +348,7 @@ static void fsl_qdma_free_chan_resources(struct dma_chan *chan)
> static void fsl_qdma_comp_fill_memcpy(struct fsl_qdma_comp *fsl_comp,
> dma_addr_t dst, dma_addr_t src, u32 len)
> {
> + u32 cmd;
> struct fsl_qdma_format *sdf, *ddf;
> struct fsl_qdma_format *ccdf, *csgf_desc, *csgf_src, *csgf_dest;
>
> @@ -353,6 +361,7 @@ static void fsl_qdma_comp_fill_memcpy(struct fsl_qdma_comp *fsl_comp,
>
> memset(fsl_comp->virt_addr, 0, FSL_QDMA_COMMAND_BUFFER_SIZE);
> memset(fsl_comp->desc_virt_addr, 0, FSL_QDMA_DESCRIPTOR_BUFFER_SIZE);
> +
> /* Head Command Descriptor(Frame Descriptor) */
> qdma_desc_addr_set64(ccdf, fsl_comp->bus_addr + 16);
> qdma_ccdf_set_format(ccdf, qdma_ccdf_get_offset(ccdf));
> @@ -369,14 +378,14 @@ static void fsl_qdma_comp_fill_memcpy(struct fsl_qdma_comp *fsl_comp,
> /* This entry is the last entry. */
> qdma_csgf_set_f(csgf_dest, len);
> /* Descriptor Buffer */
> - sdf->data =
> - cpu_to_le64(FSL_QDMA_CMD_RWTTYPE <<
> - FSL_QDMA_CMD_RWTTYPE_OFFSET);
> - ddf->data =
> - cpu_to_le64(FSL_QDMA_CMD_RWTTYPE <<
> - FSL_QDMA_CMD_RWTTYPE_OFFSET);
> - ddf->data |=
> - cpu_to_le64(FSL_QDMA_CMD_LWC << FSL_QDMA_CMD_LWC_OFFSET);
> + cmd = cpu_to_le32(FSL_QDMA_CMD_RWTTYPE <<
> + FSL_QDMA_CMD_RWTTYPE_OFFSET);
> + qdma_sddf_set_cmd(sdf, cmd);
> +
> + cmd = cpu_to_le32(FSL_QDMA_CMD_RWTTYPE <<
> + FSL_QDMA_CMD_RWTTYPE_OFFSET);
> + cmd |= cpu_to_le32(FSL_QDMA_CMD_LWC << FSL_QDMA_CMD_LWC_OFFSET);
> + qdma_sddf_set_cmd(ddf, cmd);
> }
>
> /*
> @@ -701,10 +710,8 @@ static irqreturn_t fsl_qdma_error_handler(int irq, void *dev_id)
>
> intr = qdma_readl(fsl_qdma, status + FSL_QDMA_DEDR);
>
> - if (intr) {
> + if (intr)
> dev_err(fsl_qdma->dma_dev.dev, "DMA transaction error!\n");
> - return IRQ_NONE;
> - }
this seems unrelated can you explain?
>
> qdma_writel(fsl_qdma, FSL_QDMA_DEDR_CLEAR, status + FSL_QDMA_DEDR);
> return IRQ_HANDLED;
> --
> 1.7.1
--
~Vinod
^ permalink raw reply
* [next,03/25] dmaengine: Use dev_get_drvdata()
From: Vinod Koul @ 2019-04-26 11:52 UTC (permalink / raw)
To: Kefeng Wang; +Cc: linux-kernel, Masahiro Yamada, Vinod Koul, dmaengine
On 23-04-19, 15:49, Kefeng Wang wrote:
> Using dev_get_drvdata directly.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: dmaengine@vger.kernel.org
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> ---
> drivers/dma/bcm-sba-raid.c | 3 +--
> drivers/dma/nbpfaxi.c | 4 ++--
I would prefer these to be two patches, one for each driver
^ permalink raw reply
* Re: [PATCH next 03/25] dmaengine: Use dev_get_drvdata()
From: Vinod Koul @ 2019-04-26 11:52 UTC (permalink / raw)
To: Kefeng Wang; +Cc: linux-kernel, Masahiro Yamada, Vinod Koul, dmaengine
In-Reply-To: <20190423075020.173734-4-wangkefeng.wang@huawei.com>
On 23-04-19, 15:49, Kefeng Wang wrote:
> Using dev_get_drvdata directly.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: dmaengine@vger.kernel.org
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> ---
> drivers/dma/bcm-sba-raid.c | 3 +--
> drivers/dma/nbpfaxi.c | 4 ++--
I would prefer these to be two patches, one for each driver
--
~Vinod
^ permalink raw reply
* dmaengine: rcar-dmac: Update copyright information
From: Vinod Koul @ 2019-04-26 11:53 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: Geert Uytterhoeven, Niklas Söderlund, Simon Horman,
dmaengine@vger.kernel.org, Linux-Renesas, HIROYUKI YOKOYAMA
On 25-04-19, 03:52, Yoshihiro Shimoda wrote:
> Hi Geert-san,
>
> > From: Geert Uytterhoeven, Sent: Wednesday, April 24, 2019 9:22 PM
> >
> > Hi Niklas, Shimoda-san,
> >
> > On Thu, Apr 11, 2019 at 5:18 PM Niklas Söderlund
> > <niklas.soderlund@ragnatech.se> wrote:
> > > On 2019-04-11 10:49:37 +0200, Simon Horman wrote:
> > > > On Wed, Apr 10, 2019 at 08:26:57PM +0200, Niklas Söderlund wrote:
> > > > Not strictly related, but is it appropriate to:
> > > >
> > > > 1. Move this driver and drivers/dma/sh/usb-dmac.c to drivers/dma/renesas/
> >
> > That may make sense...
> >
> > > > 2. Remove drivers/dma/sh/sudmac.c which appears unused
> > >
> > > I let someone with a better grasp of history answer this one. From my
> > > side removing drivers which are unused seems like a good idea :-)
> >
> > There seem to be some (half-baked?) interaction between sudmac.c and
> > drivers/usb/gadget/udc/r8a66597-udc.c and drivers/usb/renesas_usbhs/fifo.c.
> > These don't seem to be used at all on Renesas ARM platforms, but
> > CONFIG_USB_R8A66597_HCD is enabled in shmobile_defconfig and
> > multi_v7_defconfig?
> >
> > Shimoda-san: can you please enlighten us?
> > Thanks!
>
> Sure.
>
> - SH4A / sh7757 has SUDMAC. (any other Renesas ARM platforms don't have it).
> # sh7757 is not public product though...
> - At first, I added this SUDMAC support into r8a66597-udc.
> - But, our direction is changed by some reason. So, we use renesas_usbhs driver anyway.
> - The renesas_usbhs supports dmaengine, so I added dma/sh/sudmac driver.
> - However, for some reasons (maybe I'm busy for other projects?),
> I didn't add using the sudmac support into arch/sh/kernel/cpu/sh4a/setup-sh7757.c.
> - So, no one uses both r8a66597-udc and sudmac now.
>
> From 2013 (added the sudmac driver) to now, since no one integrated the sudmac for sh7757,
> I think we can remove the driver.
And where is the removal patch :)
^ permalink raw reply
* Re: [PATCH] dmaengine: rcar-dmac: Update copyright information
From: Vinod Koul @ 2019-04-26 11:53 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: Geert Uytterhoeven, Niklas Söderlund, Simon Horman,
dmaengine@vger.kernel.org, Linux-Renesas, HIROYUKI YOKOYAMA
In-Reply-To: <OSBPR01MB1733615712FC0F8271580D8BD83D0@OSBPR01MB1733.jpnprd01.prod.outlook.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 1928 bytes --]
On 25-04-19, 03:52, Yoshihiro Shimoda wrote:
> Hi Geert-san,
>
> > From: Geert Uytterhoeven, Sent: Wednesday, April 24, 2019 9:22 PM
> >
> > Hi Niklas, Shimoda-san,
> >
> > On Thu, Apr 11, 2019 at 5:18 PM Niklas Söderlund
> > <niklas.soderlund@ragnatech.se> wrote:
> > > On 2019-04-11 10:49:37 +0200, Simon Horman wrote:
> > > > On Wed, Apr 10, 2019 at 08:26:57PM +0200, Niklas Söderlund wrote:
> > > > Not strictly related, but is it appropriate to:
> > > >
> > > > 1. Move this driver and drivers/dma/sh/usb-dmac.c to drivers/dma/renesas/
> >
> > That may make sense...
> >
> > > > 2. Remove drivers/dma/sh/sudmac.c which appears unused
> > >
> > > I let someone with a better grasp of history answer this one. From my
> > > side removing drivers which are unused seems like a good idea :-)
> >
> > There seem to be some (half-baked?) interaction between sudmac.c and
> > drivers/usb/gadget/udc/r8a66597-udc.c and drivers/usb/renesas_usbhs/fifo.c.
> > These don't seem to be used at all on Renesas ARM platforms, but
> > CONFIG_USB_R8A66597_HCD is enabled in shmobile_defconfig and
> > multi_v7_defconfig?
> >
> > Shimoda-san: can you please enlighten us?
> > Thanks!
>
> Sure.
>
> - SH4A / sh7757 has SUDMAC. (any other Renesas ARM platforms don't have it).
> # sh7757 is not public product though...
> - At first, I added this SUDMAC support into r8a66597-udc.
> - But, our direction is changed by some reason. So, we use renesas_usbhs driver anyway.
> - The renesas_usbhs supports dmaengine, so I added dma/sh/sudmac driver.
> - However, for some reasons (maybe I'm busy for other projects?),
> I didn't add using the sudmac support into arch/sh/kernel/cpu/sh4a/setup-sh7757.c.
> - So, no one uses both r8a66597-udc and sudmac now.
>
> From 2013 (added the sudmac driver) to now, since no one integrated the sudmac for sh7757,
> I think we can remove the driver.
And where is the removal patch :)
--
~Vinod
^ permalink raw reply
* dmaengine: rcar-dmac: Update copyright information
From: Vinod Koul @ 2019-04-26 11:54 UTC (permalink / raw)
To: Niklas Söderlund; +Cc: dmaengine, linux-renesas-soc, Hiroyuki Yokoyama
On 10-04-19, 20:26, Niklas Söderlund wrote:
> From: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
>
> Update copyright and string for Gen3.
Applied, thanks
^ permalink raw reply
* Re: [PATCH] dmaengine: rcar-dmac: Update copyright information
From: Vinod Koul @ 2019-04-26 11:54 UTC (permalink / raw)
To: Niklas Söderlund; +Cc: dmaengine, linux-renesas-soc, Hiroyuki Yokoyama
In-Reply-To: <20190410182657.23034-1-niklas.soderlund+renesas@ragnatech.se>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 177 bytes --]
On 10-04-19, 20:26, Niklas Söderlund wrote:
> From: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
>
> Update copyright and string for Gen3.
Applied, thanks
--
~Vinod
^ permalink raw reply
* [1/1] dmaengine: mediatek-cqdma: fix wrong register usage in mtk_cqdma_start
From: Vinod Koul @ 2019-04-26 11:58 UTC (permalink / raw)
To: shun-chih.yu
Cc: Sean Wang, Matthias Brugger, Dan Williams, dmaengine,
linux-arm-kernel, linux-mediatek, devicetree, linux-kernel,
srv_wsdupstream
On 25-04-19, 11:53, shun-chih.yu@mediatek.com wrote:
> From: Shun-Chih Yu <shun-chih.yu@mediatek.com>
>
> This patch fixes wrong register usage in the mtk_cqdma_start. The
> destination register should be MTK_CQDMA_DST2 instead.
Applied and cced stable, thanks
^ permalink raw reply
* Re: [PATCH 1/1] dmaengine: mediatek-cqdma: fix wrong register usage in mtk_cqdma_start
From: Vinod Koul @ 2019-04-26 11:58 UTC (permalink / raw)
To: shun-chih.yu
Cc: Sean Wang, Matthias Brugger, Dan Williams, dmaengine,
linux-arm-kernel, linux-mediatek, devicetree, linux-kernel,
srv_wsdupstream
In-Reply-To: <1556164430-30724-1-git-send-email-shun-chih.yu@mediatek.com>
On 25-04-19, 11:53, shun-chih.yu@mediatek.com wrote:
> From: Shun-Chih Yu <shun-chih.yu@mediatek.com>
>
> This patch fixes wrong register usage in the mtk_cqdma_start. The
> destination register should be MTK_CQDMA_DST2 instead.
Applied and cced stable, thanks
--
~Vinod
^ permalink raw reply
* [v1] dmaengine: tegra: Use relaxed versions of readl/writel
From: Vinod Koul @ 2019-04-26 12:01 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Laxman Dewangan, Thierry Reding, Jonathan Hunter, dmaengine,
linux-tegra, linux-kernel
On 25-04-19, 02:17, Dmitry Osipenko wrote:
> The readl/writel functions are inserting memory barrier in order to
> ensure that memory stores are completed. On Tegra20 and Tegra30 this
> results in L2 cache syncing which isn't a cheapest operation. The
> tegra20-apb-dma driver doesn't need to synchronize generic memory
> accesses, hence use the relaxed versions of the functions.
Subsystem name is **dmaengine** not dma! Please fix that
^ permalink raw reply
* Re: [PATCH v1] dmaengine: tegra: Use relaxed versions of readl/writel
From: Vinod Koul @ 2019-04-26 12:01 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Laxman Dewangan, Thierry Reding, Jonathan Hunter, dmaengine,
linux-tegra, linux-kernel
In-Reply-To: <20190424231708.21219-1-digetx@gmail.com>
On 25-04-19, 02:17, Dmitry Osipenko wrote:
> The readl/writel functions are inserting memory barrier in order to
> ensure that memory stores are completed. On Tegra20 and Tegra30 this
> results in L2 cache syncing which isn't a cheapest operation. The
> tegra20-apb-dma driver doesn't need to synchronize generic memory
> accesses, hence use the relaxed versions of the functions.
Subsystem name is **dmaengine** not dma! Please fix that
--
~Vinod
^ permalink raw reply
* dmaengine: stm32-dma: fix residue calculation in stm32-dma
From: Vinod Koul @ 2019-04-26 12:17 UTC (permalink / raw)
To: Arnaud Pouliquen
Cc: Dan Williams, Pierre-Yves MORDRET, linux-stm32, linux-kernel,
dmaengine
Hi Arnaud,
Sorry for delay in review, the conference travel/vacation plan delayed
this.
On 27-03-19, 13:21, Arnaud Pouliquen wrote:
> During residue calculation. the DMA can switch to the next sg. When
> this race condition occurs, the residue returned value is not valid.
> Indeed the position in the sg returned by the hardware is the position
> of the next sg, not the current sg.
> Solution is to check the sg after the calculation to verify it.
> If a transition is detected we consider that the DMA has switched to
> the beginning of next sg.
Now, that sounds like duct tape. Why should we bother doing that.
Also looking back at the stm32_dma_desc_residue() and calls to it from
stm32_dma_tx_status() am not sure we are doing the right thing
why are we looking at next_sg here, can you explain me that please
>
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Pierre-Yves MORDRET <pierre-yves.mordret@st.com>
> ---
> drivers/dma/stm32-dma.c | 70 ++++++++++++++++++++++++++++++++++++++++---------
> 1 file changed, 57 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
> index 4903a40..30309d2 100644
> --- a/drivers/dma/stm32-dma.c
> +++ b/drivers/dma/stm32-dma.c
> @@ -1038,33 +1038,77 @@ static u32 stm32_dma_get_remaining_bytes(struct stm32_dma_chan *chan)
> return ndtr << width;
> }
>
> +static bool stm32_dma_is_current_sg(struct stm32_dma_chan *chan)
> +{
> + struct stm32_dma_device *dmadev = stm32_dma_get_dev(chan);
> + struct stm32_dma_sg_req *sg_req;
> + u32 dma_scr, dma_smar, id;
> +
> + id = chan->id;
> + dma_scr = stm32_dma_read(dmadev, STM32_DMA_SCR(id));
> +
> + if (!(dma_scr & STM32_DMA_SCR_DBM))
> + return true;
> +
> + sg_req = &chan->desc->sg_req[chan->next_sg];
> +
> + if (dma_scr & STM32_DMA_SCR_CT) {
> + dma_smar = stm32_dma_read(dmadev, STM32_DMA_SM0AR(id));
> + return (dma_smar == sg_req->chan_reg.dma_sm0ar);
> + }
> +
> + dma_smar = stm32_dma_read(dmadev, STM32_DMA_SM1AR(id));
> +
> + return (dma_smar == sg_req->chan_reg.dma_sm1ar);
> +}
> +
> static size_t stm32_dma_desc_residue(struct stm32_dma_chan *chan,
> struct stm32_dma_desc *desc,
> u32 next_sg)
> {
> u32 modulo, burst_size;
> - u32 residue = 0;
> + u32 residue;
> + u32 n_sg = next_sg;
> + struct stm32_dma_sg_req *sg_req = &chan->desc->sg_req[chan->next_sg];
> int i;
>
> + residue = stm32_dma_get_remaining_bytes(chan);
> +
> /*
> - * In cyclic mode, for the last period, residue = remaining bytes from
> - * NDTR
> + * Calculate the residue means compute the descriptors
> + * information:
> + * - the sg currently transferred
> + * - the remaining position in this sg (NDTR).
> + *
> + * The issue is that a race condition can occur if DMA is
> + * running. DMA can have started to transfer the next sg before
> + * the position in sg is read. In this case the remaing position
> + * can correspond to the new sg position.
> + * The strategy implemented in the stm32 driver is to check the
> + * sg transition. If detected we can not trust the SxNDTR register
> + * value, this register can not be up to date during the transition.
> + * In this case we can assume that the dma is at the beginning of next
> + * sg so we calculate the residue in consequence.
> */
> - if (chan->desc->cyclic && next_sg == 0) {
> - residue = stm32_dma_get_remaining_bytes(chan);
> - goto end;
> +
> + if (!stm32_dma_is_current_sg(chan)) {
> + n_sg++;
> + if (n_sg == chan->desc->num_sgs)
> + n_sg = 0;
> + residue = sg_req->len;
> }
>
> /*
> - * For all other periods in cyclic mode, and in sg mode,
> - * residue = remaining bytes from NDTR + remaining periods/sg to be
> - * transferred
> + * In cyclic mode, for the last period, residue = remaining bytes
> + * from NDTR,
> + * else for all other periods in cyclic mode, and in sg mode,
> + * residue = remaining bytes from NDTR + remaining
> + * periods/sg to be transferred
> */
> - for (i = next_sg; i < desc->num_sgs; i++)
> - residue += desc->sg_req[i].len;
> - residue += stm32_dma_get_remaining_bytes(chan);
> + if (!chan->desc->cyclic || n_sg != 0)
> + for (i = n_sg; i < desc->num_sgs; i++)
> + residue += desc->sg_req[i].len;
>
> -end:
> if (!chan->mem_burst)
> return residue;
>
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH] dmaengine: stm32-dma: fix residue calculation in stm32-dma
From: Vinod Koul @ 2019-04-26 12:17 UTC (permalink / raw)
To: Arnaud Pouliquen
Cc: Dan Williams, Pierre-Yves MORDRET, linux-stm32, linux-kernel,
dmaengine
In-Reply-To: <1553689316-6231-1-git-send-email-arnaud.pouliquen@st.com>
Hi Arnaud,
Sorry for delay in review, the conference travel/vacation plan delayed
this.
On 27-03-19, 13:21, Arnaud Pouliquen wrote:
> During residue calculation. the DMA can switch to the next sg. When
> this race condition occurs, the residue returned value is not valid.
> Indeed the position in the sg returned by the hardware is the position
> of the next sg, not the current sg.
> Solution is to check the sg after the calculation to verify it.
> If a transition is detected we consider that the DMA has switched to
> the beginning of next sg.
Now, that sounds like duct tape. Why should we bother doing that.
Also looking back at the stm32_dma_desc_residue() and calls to it from
stm32_dma_tx_status() am not sure we are doing the right thing
why are we looking at next_sg here, can you explain me that please
>
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Pierre-Yves MORDRET <pierre-yves.mordret@st.com>
> ---
> drivers/dma/stm32-dma.c | 70 ++++++++++++++++++++++++++++++++++++++++---------
> 1 file changed, 57 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
> index 4903a40..30309d2 100644
> --- a/drivers/dma/stm32-dma.c
> +++ b/drivers/dma/stm32-dma.c
> @@ -1038,33 +1038,77 @@ static u32 stm32_dma_get_remaining_bytes(struct stm32_dma_chan *chan)
> return ndtr << width;
> }
>
> +static bool stm32_dma_is_current_sg(struct stm32_dma_chan *chan)
> +{
> + struct stm32_dma_device *dmadev = stm32_dma_get_dev(chan);
> + struct stm32_dma_sg_req *sg_req;
> + u32 dma_scr, dma_smar, id;
> +
> + id = chan->id;
> + dma_scr = stm32_dma_read(dmadev, STM32_DMA_SCR(id));
> +
> + if (!(dma_scr & STM32_DMA_SCR_DBM))
> + return true;
> +
> + sg_req = &chan->desc->sg_req[chan->next_sg];
> +
> + if (dma_scr & STM32_DMA_SCR_CT) {
> + dma_smar = stm32_dma_read(dmadev, STM32_DMA_SM0AR(id));
> + return (dma_smar == sg_req->chan_reg.dma_sm0ar);
> + }
> +
> + dma_smar = stm32_dma_read(dmadev, STM32_DMA_SM1AR(id));
> +
> + return (dma_smar == sg_req->chan_reg.dma_sm1ar);
> +}
> +
> static size_t stm32_dma_desc_residue(struct stm32_dma_chan *chan,
> struct stm32_dma_desc *desc,
> u32 next_sg)
> {
> u32 modulo, burst_size;
> - u32 residue = 0;
> + u32 residue;
> + u32 n_sg = next_sg;
> + struct stm32_dma_sg_req *sg_req = &chan->desc->sg_req[chan->next_sg];
> int i;
>
> + residue = stm32_dma_get_remaining_bytes(chan);
> +
> /*
> - * In cyclic mode, for the last period, residue = remaining bytes from
> - * NDTR
> + * Calculate the residue means compute the descriptors
> + * information:
> + * - the sg currently transferred
> + * - the remaining position in this sg (NDTR).
> + *
> + * The issue is that a race condition can occur if DMA is
> + * running. DMA can have started to transfer the next sg before
> + * the position in sg is read. In this case the remaing position
> + * can correspond to the new sg position.
> + * The strategy implemented in the stm32 driver is to check the
> + * sg transition. If detected we can not trust the SxNDTR register
> + * value, this register can not be up to date during the transition.
> + * In this case we can assume that the dma is at the beginning of next
> + * sg so we calculate the residue in consequence.
> */
> - if (chan->desc->cyclic && next_sg == 0) {
> - residue = stm32_dma_get_remaining_bytes(chan);
> - goto end;
> +
> + if (!stm32_dma_is_current_sg(chan)) {
> + n_sg++;
> + if (n_sg == chan->desc->num_sgs)
> + n_sg = 0;
> + residue = sg_req->len;
> }
>
> /*
> - * For all other periods in cyclic mode, and in sg mode,
> - * residue = remaining bytes from NDTR + remaining periods/sg to be
> - * transferred
> + * In cyclic mode, for the last period, residue = remaining bytes
> + * from NDTR,
> + * else for all other periods in cyclic mode, and in sg mode,
> + * residue = remaining bytes from NDTR + remaining
> + * periods/sg to be transferred
> */
> - for (i = next_sg; i < desc->num_sgs; i++)
> - residue += desc->sg_req[i].len;
> - residue += stm32_dma_get_remaining_bytes(chan);
> + if (!chan->desc->cyclic || n_sg != 0)
> + for (i = n_sg; i < desc->num_sgs; i++)
> + residue += desc->sg_req[i].len;
>
> -end:
> if (!chan->mem_burst)
> return residue;
>
> --
> 2.7.4
--
~Vinod
^ permalink raw reply
* [v1] dmaengine: tegra: Use relaxed versions of readl/writel
From: Dmitry Osipenko @ 2019-04-26 12:18 UTC (permalink / raw)
To: Jon Hunter, Laxman Dewangan, Vinod Koul, Thierry Reding
Cc: dmaengine, linux-tegra, linux-kernel
26.04.2019 14:13, Jon Hunter пишет:
>
> On 26/04/2019 11:45, Dmitry Osipenko wrote:
>> 26.04.2019 12:52, Jon Hunter пишет:
>>>
>>> On 25/04/2019 00:17, Dmitry Osipenko wrote:
>>>> The readl/writel functions are inserting memory barrier in order to
>>>> ensure that memory stores are completed. On Tegra20 and Tegra30 this
>>>> results in L2 cache syncing which isn't a cheapest operation. The
>>>> tegra20-apb-dma driver doesn't need to synchronize generic memory
>>>> accesses, hence use the relaxed versions of the functions.
>>>
>>> Do you mean device-io accesses here as this is not generic memory?
>>
>> Yes. The IOMEM accesses within are always ordered and uncached, while
>> generic memory accesses are out-of-order and cached.
>>
>>> Although there may not be any issues with this change, I think I need a
>>> bit more convincing that we should do this given that we have had it
>>> this way for sometime and I would not like to see us introduce any
>>> regressions as this point without being 100% certain we would not.
>>> Ideally, if I had some good extensive tests I could run to hammer the
>>> DMA for all configurations with different combinations of channels
>>> running simultaneously then we could test this, but right now I don't :-(
>>>
>>> Have you ...
>>> 1. Tested both cyclic and scatter-gather transfers?
>>> 2. Stress tested simultaneous transfers with various different
>>> configurations?
>>> 3. Quantified the actual performance benefit of this change so we can
>>> understand how much of a performance boost this offers?
>>
>> Actually I found a case where this change causes a problem, I'm seeing
>> I2C transfer timeout for touchscreen and it breaks the touch input.
>> Indeed, I haven't tested this patch very well.
>>
>> And the fix is this:
>>
>> @@ -1592,6 +1592,8 @@ static int tegra_dma_runtime_suspend(struct device
>> *dev)
>> TEGRA_APBDMA_CHAN_WCOUNT);
>> }
>>
>> + dsb();
>> +
>> clk_disable_unprepare(tdma->dma_clk);
>>
>> return 0;
>>
>>
>> Apparently the problem is that CLK/DMA (PPSB/APB) accesses are
>> incoherent and CPU disables clock before writes are reaching DMA controller.
>>
>> I'd say that cyclic and scatter-gather transfers are now tested. I also
>> made some more testing of simultaneous transfers.
>>
>> Quantifying performance probably won't be easy to make as the DMA
>> read/writes are not on any kind of code's hot-path.
>
> So why make the change?
For consistency.
>> Jon, are you still insisting about to drop this patch or you will be
>> fine with the v2 that will have the dsb() in place?
>
> If we can't quantify the performance gain, then it is difficult to
> justify the change. I would also be concerned if that is the only place
> we need an explicit dsb.
Maybe it won't hurt to add dsb to the ISR as well. But okay, let's drop
this patch for now.
^ permalink raw reply
* Re: [PATCH v1] dmaengine: tegra: Use relaxed versions of readl/writel
From: Dmitry Osipenko @ 2019-04-26 12:18 UTC (permalink / raw)
To: Jon Hunter, Laxman Dewangan, Vinod Koul, Thierry Reding
Cc: dmaengine, linux-tegra, linux-kernel
In-Reply-To: <bff59709-426b-32d2-08eb-d8f51cd7d5c1@nvidia.com>
26.04.2019 14:13, Jon Hunter пишет:
>
> On 26/04/2019 11:45, Dmitry Osipenko wrote:
>> 26.04.2019 12:52, Jon Hunter пишет:
>>>
>>> On 25/04/2019 00:17, Dmitry Osipenko wrote:
>>>> The readl/writel functions are inserting memory barrier in order to
>>>> ensure that memory stores are completed. On Tegra20 and Tegra30 this
>>>> results in L2 cache syncing which isn't a cheapest operation. The
>>>> tegra20-apb-dma driver doesn't need to synchronize generic memory
>>>> accesses, hence use the relaxed versions of the functions.
>>>
>>> Do you mean device-io accesses here as this is not generic memory?
>>
>> Yes. The IOMEM accesses within are always ordered and uncached, while
>> generic memory accesses are out-of-order and cached.
>>
>>> Although there may not be any issues with this change, I think I need a
>>> bit more convincing that we should do this given that we have had it
>>> this way for sometime and I would not like to see us introduce any
>>> regressions as this point without being 100% certain we would not.
>>> Ideally, if I had some good extensive tests I could run to hammer the
>>> DMA for all configurations with different combinations of channels
>>> running simultaneously then we could test this, but right now I don't :-(
>>>
>>> Have you ...
>>> 1. Tested both cyclic and scatter-gather transfers?
>>> 2. Stress tested simultaneous transfers with various different
>>> configurations?
>>> 3. Quantified the actual performance benefit of this change so we can
>>> understand how much of a performance boost this offers?
>>
>> Actually I found a case where this change causes a problem, I'm seeing
>> I2C transfer timeout for touchscreen and it breaks the touch input.
>> Indeed, I haven't tested this patch very well.
>>
>> And the fix is this:
>>
>> @@ -1592,6 +1592,8 @@ static int tegra_dma_runtime_suspend(struct device
>> *dev)
>> TEGRA_APBDMA_CHAN_WCOUNT);
>> }
>>
>> + dsb();
>> +
>> clk_disable_unprepare(tdma->dma_clk);
>>
>> return 0;
>>
>>
>> Apparently the problem is that CLK/DMA (PPSB/APB) accesses are
>> incoherent and CPU disables clock before writes are reaching DMA controller.
>>
>> I'd say that cyclic and scatter-gather transfers are now tested. I also
>> made some more testing of simultaneous transfers.
>>
>> Quantifying performance probably won't be easy to make as the DMA
>> read/writes are not on any kind of code's hot-path.
>
> So why make the change?
For consistency.
>> Jon, are you still insisting about to drop this patch or you will be
>> fine with the v2 that will have the dsb() in place?
>
> If we can't quantify the performance gain, then it is difficult to
> justify the change. I would also be concerned if that is the only place
> we need an explicit dsb.
Maybe it won't hurt to add dsb to the ISR as well. But okay, let's drop
this patch for now.
^ permalink raw reply
* [v1] dmaengine: tegra: Use relaxed versions of readl/writel
From: Dmitry Osipenko @ 2019-04-26 12:19 UTC (permalink / raw)
To: Vinod Koul
Cc: Laxman Dewangan, Thierry Reding, Jonathan Hunter, dmaengine,
linux-tegra, linux-kernel
26.04.2019 15:01, Vinod Koul пишет:
> On 25-04-19, 02:17, Dmitry Osipenko wrote:
>> The readl/writel functions are inserting memory barrier in order to
>> ensure that memory stores are completed. On Tegra20 and Tegra30 this
>> results in L2 cache syncing which isn't a cheapest operation. The
>> tegra20-apb-dma driver doesn't need to synchronize generic memory
>> accesses, hence use the relaxed versions of the functions.
>
> Subsystem name is **dmaengine** not dma! Please fix that
>
Looks like you answered to a wrong email.
^ permalink raw reply
* Re: [PATCH v1] dmaengine: tegra: Use relaxed versions of readl/writel
From: Dmitry Osipenko @ 2019-04-26 12:19 UTC (permalink / raw)
To: Vinod Koul
Cc: Laxman Dewangan, Thierry Reding, Jonathan Hunter, dmaengine,
linux-tegra, linux-kernel
In-Reply-To: <20190426120148.GB28103@vkoul-mobl>
26.04.2019 15:01, Vinod Koul пишет:
> On 25-04-19, 02:17, Dmitry Osipenko wrote:
>> The readl/writel functions are inserting memory barrier in order to
>> ensure that memory stores are completed. On Tegra20 and Tegra30 this
>> results in L2 cache syncing which isn't a cheapest operation. The
>> tegra20-apb-dma driver doesn't need to synchronize generic memory
>> accesses, hence use the relaxed versions of the functions.
>
> Subsystem name is **dmaengine** not dma! Please fix that
>
Looks like you answered to a wrong email.
^ permalink raw reply
* dmaengine: stm32-dma: dmaengine: stm32-dma: use platform_get_irq()
From: Vinod Koul @ 2019-04-26 12:20 UTC (permalink / raw)
To: Fabien Dessenne
Cc: Dan Williams, Maxime Coquelin, Alexandre Torgue,
Pierre-Yves MORDRET, dmaengine, linux-stm32, linux-arm-kernel,
linux-kernel
On 24-04-19, 11:21, Fabien Dessenne wrote:
> platform_get_resource(pdev, IORESOURCE_IRQ) is not recommended for
> requesting IRQ's resources, as they can be not ready yet. Using
> platform_get_irq() instead is preferred for getting IRQ even if it was
> not retrieved earlier.
Applied, thanks
^ permalink raw reply
* Re: [PATCH] dmaengine: stm32-dma: dmaengine: stm32-dma: use platform_get_irq()
From: Vinod Koul @ 2019-04-26 12:20 UTC (permalink / raw)
To: Fabien Dessenne
Cc: Dan Williams, Maxime Coquelin, Alexandre Torgue,
Pierre-Yves MORDRET, dmaengine, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <1556097685-7236-1-git-send-email-fabien.dessenne@st.com>
On 24-04-19, 11:21, Fabien Dessenne wrote:
> platform_get_resource(pdev, IORESOURCE_IRQ) is not recommended for
> requesting IRQ's resources, as they can be not ready yet. Using
> platform_get_irq() instead is preferred for getting IRQ even if it was
> not retrieved earlier.
Applied, thanks
--
~Vinod
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox