archive mirror
 help / color / mirror / Atom feed
From: Andy Shevchenko <>
To: Hein Tibosch <>
Cc: Viresh Kumar <>,
	Andrew Morton <>,
	Hans-Christian Egtvedt <>,
	Arnd Bergmann <>,
	spear-devel <>,
	Linux Kernel Mailing List <>,
	"ludovic.desroches" <>,
	Havard Skinnemoen <>,
	Nicolas Ferre <>
Subject: Re: [PATCH v4 2/3] dw_dmac: max_mem_width limits value for SRC/DST_TR_WID register
Date: Tue, 4 Sep 2012 09:38:47 +0300	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Sep 3, 2012 at 4:06 PM, Hein Tibosch <> wrote:
> 1. The first draft of the patches worked with the max allowable value for
> the SRC_WIDTH & DST_WIDTH fields: 0,1,2,3... Viresh thought it was not
> transparent enough, he suggested to make it simpler with a binary choice of
> 32- or 64-bits, defaulting to 64-bits.
> But Andy is right: there are versions supporting 256-bit wide memory transfers.
> I'd also go for this previous solution and use: "min(max_mem_width, width)"
> The only problem is that one doesn't want to change arch code for other
> platforms (ARM) so I proposed: let "max_mem_width=0" mean: leave it up to
> the driver, for now 3 : 64-bits.
Sounds better to support all possible options without any additional
layer of conversion, isn't it?

> 2. In another version I made 'max_mem_width' a member of 'dw_dma_platform_data'
> because I also see it as 'constant' for all dma slaves.
> But the dw_dmac controller can be used for multiple (types of) memories
> and in that case, maybe a limit per slave might be desirable? My knowledge
> of DMA-hardware doesn't reach far enough to judge that.
As Viresh told early that will not cover memory-to-memory transfers.

> I'd say: for now let it become a member of 'dw_dma_platform_data' because
> it's the max value of a register field.
I support such choice.

> 3. Felipe Balbi: why don't we ask the DW IP for its maximum allowed value of
> SRC_WIDTH & DST_WIDTH (on the memory side)? Sure, would be elegant!
It's not so simple, unfortunately.

> Alternatively, we could do a small dma-memcpy-test at start-up and try all
> values from 5 (or 7) down to 2. The first value that works correctly will be
> used as the maximum.
Oh, it might be good idea to get this value in case neither IP nor
platform data provides it.
I'm pretty sure the platform device driver has to know this beforehand.

With Best Regards,
Andy Shevchenko

      reply	other threads:[~2012-09-04  6:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-02 17:54 Hein Tibosch
2012-09-03  8:25 ` Andy Shevchenko
2012-09-03  8:30   ` Viresh Kumar
2012-09-03  8:49     ` Andy Shevchenko
2012-09-03  8:59       ` Viresh Kumar
2012-09-03 13:06         ` Hein Tibosch
2012-09-04  6:38           ` Andy Shevchenko [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v4 2/3] dw_dmac: max_mem_width limits value for SRC/DST_TR_WID register' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).