Re: [PATCH v4 2/3] dw_dmac: max_mem_width limits value forSRC/DST_TR_WID register

[Andy Shevchenko]

On Mon, Sep 3, 2012 at 4:06 PM, Hein Tibosch <hein_tibosch@xxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/