Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1525667 > unrolled thread

[PATCH v3 0/2] DW DMAC: update device tree

Back to article view | Back to linux.kernel

Contents

  [PATCH v3 0/2] DW DMAC: update device tree Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> - 2016-11-18 20:20 +0100
    [PATCH v3 1/2] DW DMAC: enable memory-to-memory transfers support Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> - 2016-11-18 20:20 +0100
      Re: [PATCH v3 1/2] DW DMAC: enable memory-to-memory transfers  support Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-11-18 20:30 +0100
    Re: [PATCH v3 0/2] DW DMAC: update device tree Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-11-18 20:30 +0100
      Re: [PATCH v3 0/2] DW DMAC: update device tree Alexey Brodkin <Alexey.Brodkin@synopsys.com> - 2016-11-21 11:10 +0100
        Re: [PATCH v3 0/2] DW DMAC: update device tree Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-11-21 11:40 +0100
          Re: [PATCH v3 0/2] DW DMAC: update device tree Vinod Koul <vinod.koul@intel.com> - 2016-11-23 05:00 +0100

#1525667 — [PATCH v3 0/2] DW DMAC: update device tree

It wasn't possible to enable some features like
memory-to-memory transfers or multi block transfers via DT.
It is fixed by these patches.

Changes for v3:
 * Update existing platform data.
   We don't need to update existing DTS because default logic 
   wasn't change: we don't set "is_nollp" if we read 
   configuration from DT before. And we don't set it now if
   "multi-block" property doesn't exist in DTS.

Changes for v2:
 * I thought about is_memcpy DT property: all known devices, which 
   use DT for configuration, support memory-to-memory transfers. 
   So we don't need to read it from DT. So enable it by default, 
   if we read configuration from DT.

 * Use "multi-block" instead of "hw-llp" name to be more clear.

 * Move adding DT property and adding documentation for this
   property to one patch.

Eugeniy Paltsev (2):
  DW DMAC: enable memory-to-memory transfers support
  DW DMAC: add multi-block property to device tree

 Documentation/devicetree/bindings/dma/snps-dma.txt |  2 ++
 drivers/dma/dw/core.c                              |  2 +-
 drivers/dma/dw/platform.c                          | 11 +++++++++++
 drivers/tty/serial/8250/8250_lpss.c                |  2 +-
 include/linux/platform_data/dma-dw.h               |  4 ++--
 5 files changed, 17 insertions(+), 4 deletions(-)

-- 
2.5.5

[toc] | [next] | [standalone]

#1525668 — [PATCH v3 1/2] DW DMAC: enable memory-to-memory transfers support

All known devices, which use DT for configuration, support
memory-to-memory transfers. So enable it by default, if we read
configuration from DT.

Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
---
 drivers/dma/dw/platform.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index 5bda0eb..aa7a5c1 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -129,6 +129,12 @@ dw_dma_parse_dt(struct platform_device *pdev)
 	if (of_property_read_bool(np, "is_private"))
 		pdata->is_private = true;
 
+	/*
+	 * All known devices, which use DT for configuration, support
+	 * memory-to-memory transfers. So enable it by default.
+	 */
+	pdata->is_memcpy = true;
+
 	if (!of_property_read_u32(np, "chan_allocation_order", &tmp))
 		pdata->chan_allocation_order = (unsigned char)tmp;
 
-- 
2.5.5

[toc] | [prev] | [next] | [standalone]

#1525669 — Re: [PATCH v3 1/2] DW DMAC: enable memory-to-memory transfers support

On Fri, 2016-11-18 at 22:12 +0300, Eugeniy Paltsev wrote:
> All known devices, which use DT for configuration, support
> memory-to-memory transfers. So enable it by default, if we read
> configuration from DT.
> 
> Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>

You missed the given tag(s).

> ---
>  drivers/dma/dw/platform.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
> index 5bda0eb..aa7a5c1 100644
> --- a/drivers/dma/dw/platform.c
> +++ b/drivers/dma/dw/platform.c
> @@ -129,6 +129,12 @@ dw_dma_parse_dt(struct platform_device *pdev)
>  	if (of_property_read_bool(np, "is_private"))
>  		pdata->is_private = true;
>  
> +	/*
> +	 * All known devices, which use DT for configuration, support
> +	 * memory-to-memory transfers. So enable it by default.
> +	 */
> +	pdata->is_memcpy = true;
> +
>  	if (!of_property_read_u32(np, "chan_allocation_order", &tmp))
>  		pdata->chan_allocation_order = (unsigned char)tmp;
>  

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

[toc] | [prev] | [next] | [standalone]

#1525672

On Fri, 2016-11-18 at 22:12 +0300, Eugeniy Paltsev wrote:
> It wasn't possible to enable some features like
> memory-to-memory transfers or multi block transfers via DT.
> It is fixed by these patches.

First of all, please, give time to reviewers to comment the patches.
Usually it should be at least 24h (for the series that has been sent
first time 1 week approximately).

> 
> Changes for v3:
>  * Update existing platform data.
>    We don't need to update existing DTS because default logic 
>    wasn't change: we don't set "is_nollp" if we read 
>    configuration from DT before. And we don't set it now if
>    "multi-block" property doesn't exist in DTS.

See my comments in the patches.
And do not send the updated version earlier than Monday, please.

> 
> Changes for v2:
>  * I thought about is_memcpy DT property: all known devices, which 
>    use DT for configuration, support memory-to-memory transfers. 
>    So we don't need to read it from DT. So enable it by default, 
>    if we read configuration from DT.
> 
>  * Use "multi-block" instead of "hw-llp" name to be more clear.
> 
>  * Move adding DT property and adding documentation for this
>    property to one patch.
> 
> Eugeniy Paltsev (2):
>   DW DMAC: enable memory-to-memory transfers support
>   DW DMAC: add multi-block property to device tree
> 
>  Documentation/devicetree/bindings/dma/snps-dma.txt |  2 ++
>  drivers/dma/dw/core.c                              |  2 +-
>  drivers/dma/dw/platform.c                          | 11 +++++++++++
>  drivers/tty/serial/8250/8250_lpss.c                |  2 +-
>  include/linux/platform_data/dma-dw.h               |  4 ++--
>  5 files changed, 17 insertions(+), 4 deletions(-)
> 

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

[toc] | [prev] | [next] | [standalone]

#1526513

Hi Andy,

On Fri, 2016-11-18 at 21:26 +0200, Andy Shevchenko wrote:
> On Fri, 2016-11-18 at 22:12 +0300, Eugeniy Paltsev wrote:
> > 
> > It wasn't possible to enable some features like
> > memory-to-memory transfers or multi block transfers via DT.
> > It is fixed by these patches.
> 
> First of all, please, give time to reviewers to comment the patches.
> Usually it should be at least 24h (for the series that has been sent
> first time 1 week approximately).

I'm not really sure a lot of people get disturbed by this series
and given this all has been discussed for months now I'd really like
to see changes required for our HW to work to land in upstream ASAP.

Too bad we're late for 4.9 (which is supposed to be the next LTS) but
we need to make sure this series hits 4.10 for sure.

Hope this race doesn't affect you that much.

-Alexey

[toc] | [prev] | [next] | [standalone]

#1526542

On Mon, 2016-11-21 at 10:02 +0000, Alexey Brodkin wrote:
> Hi Andy,
> 
> On Fri, 2016-11-18 at 21:26 +0200, Andy Shevchenko wrote:
> > On Fri, 2016-11-18 at 22:12 +0300, Eugeniy Paltsev wrote:
> > > 
> > > It wasn't possible to enable some features like
> > > memory-to-memory transfers or multi block transfers via DT.
> > > It is fixed by these patches.
> > 
> > First of all, please, give time to reviewers to comment the patches.
> > Usually it should be at least 24h (for the series that has been sent
> > first time 1 week approximately).
> 
> I'm not really sure a lot of people get disturbed by this series
> and given this all has been discussed for months now I'd really like
> to see changes required for our HW to work to land in upstream ASAP.

I understand your concern, I'm often in the same position in many areas,
including this driver (I'm not a maintainer of slave DMA subsystem).

Though let's face the issues we have with the series:
- stuff regarding to style and alike (would be fixed in a day)
- DTS naming and conventions, this is apparently a big area, where I
might share opinion, but can't decide for
- last word by the subsystem maintainer

> Too bad we're late for 4.9 (which is supposed to be the next LTS) but
> > we need to make sure this series hits 4.10 for sure.

Vinod, is it possible to get in for this series (if we get Ack from DT
people)?

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

[toc] | [prev] | [next] | [standalone]

#1528111

On Mon, Nov 21, 2016 at 12:37:06PM +0200, Andy Shevchenko wrote:
> On Mon, 2016-11-21 at 10:02 +0000, Alexey Brodkin wrote:
> > Hi Andy,
> > 
> > On Fri, 2016-11-18 at 21:26 +0200, Andy Shevchenko wrote:
> > > On Fri, 2016-11-18 at 22:12 +0300, Eugeniy Paltsev wrote:
> > > > 
> > > > It wasn't possible to enable some features like
> > > > memory-to-memory transfers or multi block transfers via DT.
> > > > It is fixed by these patches.
> > > 
> > > First of all, please, give time to reviewers to comment the patches.
> > > Usually it should be at least 24h (for the series that has been sent
> > > first time 1 week approximately).
> > 
> > I'm not really sure a lot of people get disturbed by this series
> > and given this all has been discussed for months now I'd really like
> > to see changes required for our HW to work to land in upstream ASAP.
> 
> I understand your concern, I'm often in the same position in many areas,
> including this driver (I'm not a maintainer of slave DMA subsystem).
> 
> Though let's face the issues we have with the series:
> - stuff regarding to style and alike (would be fixed in a day)
> - DTS naming and conventions, this is apparently a big area, where I
> might share opinion, but can't decide for
> - last word by the subsystem maintainer
> 
> > Too bad we're late for 4.9 (which is supposed to be the next LTS) but
> > > we need to make sure this series hits 4.10 for sure.
> 
> Vinod, is it possible to get in for this series (if we get Ack from DT
> people)?

We still have a week or so... But holding race agaisnt upstream is a bad
idea... Doesnt work that way.

-- 
~Vinod

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web