From: Andy Shevchenko <firstname.lastname@example.org> To: Hein Tibosch <email@example.com> Cc: Viresh Kumar <firstname.lastname@example.org>, Andrew Morton <email@example.com>, Hans-Christian Egtvedt <firstname.lastname@example.org>, Arnd Bergmann <email@example.com>, spear-devel <firstname.lastname@example.org>, Linux Kernel Mailing List <email@example.com>, "ludovic.desroches" <firstname.lastname@example.org>, Havard Skinnemoen <email@example.com>, Nicolas Ferre <firstname.lastname@example.org> 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: <CAHp75VdQV+nZzvp8OK+vZtqnC34nj_PwVK0EdGS1_AYhDDfvemail@example.com> (raw) In-Reply-To: <5044AB51.firstname.lastname@example.org> On Mon, Sep 3, 2012 at 4:06 PM, Hein Tibosch <email@example.com> 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
prev parent 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: 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='CAHp75VdQV+nZzvp8OK+vZtqnC34nj_PwVK0EdGS1_AYhDDfvfirstname.lastname@example.org' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH v4 2/3] dw_dmac: max_mem_width limits value for SRC/DST_TR_WID register' \ /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
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).