[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOMqctQH4MnKMthOnuPgB-A5k6PCOAmhwHzJfn7gE3R4w8bufg@mail.gmail.com>
Date: Wed, 22 Jul 2015 09:30:54 +0200
From: Michal Suchanek <hramrach@...il.com>
To: Vinod Koul <vinod.koul@...el.com>
Cc: Brian Norris <computersforpeace@...il.com>,
Marek Vasut <marex@...x.de>,
Richard Cochran <richardcochran@...il.com>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Mark Rutland <mark.rutland@....com>,
Krzysztof Kozlowski <k.kozlowski@...sung.com>,
Geert Uytterhoeven <geert+renesas@...der.be>,
MTD Maling List <linux-mtd@...ts.infradead.org>,
Alison Chaiken <alison_chaiken@...tor.com>,
Bean Huo 霍斌斌 (beanhuo)
<beanhuo@...ron.com>,
"linux-samsung-soc@...r.kernel.org"
<linux-samsung-soc@...r.kernel.org>,
Russell King <linux@....linux.org.uk>,
Rafał Miłecki <zajec5@...il.com>,
Kukjin Kim <kgene@...nel.org>,
Ben Hutchings <ben@...adent.org.uk>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
Pawel Moll <pawel.moll@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Kumar Gala <galak@...eaurora.org>,
Mark Brown <broonie@...nel.org>,
Dan Williams <dan.j.williams@...el.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"grmoore@...era.com" <grmoore@...era.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-spi <linux-spi@...r.kernel.org>,
Huang Shijie <b32955@...escale.com>,
Rob Herring <robh+dt@...nel.org>,
Han Xu <han.xu@...escale.com>,
Knut Wohlrab <knut.wohlrab@...bosch.com>,
dmaengine <dmaengine@...r.kernel.org>,
David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH 08/11] MTD: m25p80: Add option to limit SPI transfer size.
On 22 July 2015 at 06:49, Vinod Koul <vinod.koul@...el.com> wrote:
> On Tue, Jul 21, 2015 at 10:14:11AM +0200, Michal Suchanek wrote:
>> > Or alternatively we could publish the limitations of the channel using
>> > capabilities so SPI knows I have a dmaengine channel and it can transfer max N
>> > length transfers so would be able to break rather than guessing it or coding
>> > in DT. Yes it may come from DT but that should be dmaengine driver rather
>> > than client driver :)
>> >
>> > This can be done by dma_get_slave_caps(chan, &caps)
>> >
>> > And we add max_length as one more parameter to existing set
>> >
>> > Also all this could be handled in generic SPI-dmaengine layer so that
>> > individual drivers don't have to code it in
>> >
>> > Let me know if this idea is okay, I can push the dmaengine bits...
>>
>> It would be ok if there was a fixed limit. However, the limit depends
>> on SPI slave settings. Presumably for other buses using the dmaengine
>> the limit would depend on the bus or slave settings as well. I do not
>> see a sane way of passing this all the way to the dmaengine driver.
> I don't see why this should be client (SPI) dependent. The max length
> supported is a dmaengine constraint, typically flowing from max
> blocks/length it can transfer. Know this limit can allow clients to split
> transfers.
In practice on the board I have the maximum transfer length before it
fails depends on SPI bus speed which is set up per slave. I did not
try searching the space of possible settings thorougly and settled for
a setting that gives reasonable speed and transfer length.
However, if this was not tied to the particular slave setting picked
in the current DT a formula would be needed that translates arbitrary
client settings to transfer size limit and there would be need to
somehow get the client settings to the formula in the dmaengine
driver.
Thanks
Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists