From: Stefan Roese <sr@denx.de>
To: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
linux-spi@vger.kernel.org, Nadav Haklai <nadavh@marvell.com>,
Mark Brown <broonie@kernel.org>,
Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
Gregory CLEMENT <gregory.clement@free-electrons.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] spi: orion.c: Add direct access mode
Date: Tue, 22 Mar 2016 17:44:52 +0100 [thread overview]
Message-ID: <56F17684.2010307@denx.de> (raw)
In-Reply-To: <20160322173546.40d24cc2@free-electrons.com>
Hi Thomas,
On 22.03.2016 17:35, Thomas Petazzoni wrote:
> On Tue, 22 Mar 2016 17:24:53 +0100, Stefan Roese wrote:
>> This patch adds support for the direct access mode to the Orion SPI
>> driver which is used on the Marvell Armada based SoCs. In this direct
>> mode, all data written to (or read from) a specifically mapped MBus
>> window (linked to one SPI chip-select on one of the SPI controllers)
>> will be transferred directly to the SPI bus. Without the need to control
>> the SPI registers in between. This can improve the SPI transfer rate in
>> such cases.
>>
>> Both, direct-read and -write mode are supported. But only the write
>> mode has been tested. This mode especially benefits from the SPI direct
>> mode, as the data bytes are written head-to-head to the SPI bus,
>> without any additional addresses.
>>
>> One use-case for this direct write mode is, programming a FPGA bitstream
>> image into the FPGA connected to the SPI bus at maximum speed.
>>
>> This mode is described in chapter "22.5.2 Direct Write to SPI" in the
>> Marvell Armada XP Functional Spec Datasheet.
>>
>> Signed-off-by: Stefan Roese <sr@denx.de>
>> Cc: Nadav Haklai <nadavh@marvell.com>
>> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
>> Cc: Mark Brown <broonie@kernel.org>
>> ---
>> Mark, sorry for the huge delay for v2 of this direct-access patch.
>> I was busy with other tasks in the meantime. And only found now
>> the time to address (hopefully all) of your comments.
>
> Thanks for this new version! To be honest, I don't remember all the
> discussions that took place on the v1, so maybe I'll just be re-asking
> the same question.
No problem. Thanks for looking into this.
> Has there been any discussion on whether dynamically adding the MBus
> window is a good idea, as opposed to statically defining it in the
> board .dts ?
Yes. My 1st patch version (still RFC) used fixed MBus windows instead:
http://www.spinics.net/lists/linux-spi/msg06536.html
Mark suggested to use dynamic windows, so that one area could be
used for all SPI devices by switching (re-configuring) the MBus
window:
http://www.spinics.net/lists/linux-spi/msg06537.html
> So far, the only driver that was using dynamically allocated MBus is
> the PCIe controller driver, because there is no way in advanced to know
> the number and memory window requirements of the PCIe devices that will
> be connected to the system.
>
> For all other windows (BootROM, crypto SRAM and more recently network
> related SRAM), we are using statically allocated windows.
>
> So I'm wondering if we should add this additional DT binding that
> describes the necessary information to allow the driver to dynamically
> allocate a window, or if we shouldn't rely on a statically allocated
> window.
>
> This is really an open discussion, I don't have a very well-defined
> opinion on the matter.
I also have no real preference here.
> Let's Cc: Arnd Bergmann on this question, he has followed the whole
> MBus story and might have some interesting insights.
Good idea.
Thanks,
Stefan
next prev parent reply other threads:[~2016-03-22 16:44 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-22 16:24 [PATCH v2] spi: orion.c: Add direct access mode Stefan Roese
[not found] ` <1458663893-13766-1-git-send-email-sr-ynQEQJNshbs@public.gmane.org>
2016-03-22 16:35 ` Thomas Petazzoni
2016-03-22 16:44 ` Stefan Roese [this message]
[not found] ` <56F17684.2010307-ynQEQJNshbs@public.gmane.org>
2016-03-23 11:33 ` Mark Brown
[not found] ` <20160323113316.GH2566-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-03-23 11:59 ` Stefan Roese
[not found] ` <56F2852C.5010006-ynQEQJNshbs@public.gmane.org>
2016-03-23 12:54 ` Mark Brown
[not found] ` <20160323125448.GM2566-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-03-23 13:10 ` Stefan Roese
[not found] ` <56F295E1.4030505-ynQEQJNshbs@public.gmane.org>
2016-03-23 13:26 ` Andrew Lunn
[not found] ` <20160323132637.GC19953-g2DYL2Zd6BY@public.gmane.org>
2016-03-23 13:36 ` Mark Brown
[not found] ` <20160323133612.GO2566-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-03-23 13:56 ` Andrew Lunn
[not found] ` <20160323135606.GE19953-g2DYL2Zd6BY@public.gmane.org>
2016-03-23 19:51 ` Arnd Bergmann
2016-03-24 7:22 ` Stefan Roese
[not found] ` <56F395BC.6070108-ynQEQJNshbs@public.gmane.org>
2016-03-24 12:42 ` Arnd Bergmann
2016-03-24 16:15 ` Stefan Roese
[not found] ` <56F412B5.2080200-ynQEQJNshbs@public.gmane.org>
2016-03-24 16:42 ` Arnd Bergmann
2016-03-24 17:30 ` Stefan Roese
2016-03-24 16:48 ` Arnd Bergmann
2016-03-24 17:51 ` Stefan Roese
[not found] ` <56F42939.4020803-ynQEQJNshbs@public.gmane.org>
2016-03-24 20:07 ` Arnd Bergmann
2016-03-25 10:32 ` Mark Brown
[not found] ` <20160325103253.GA2566-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-03-25 15:11 ` Arnd Bergmann
2016-03-25 15:50 ` Mark Brown
[not found] ` <20160325155032.GH2566-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-03-25 20:58 ` Arnd Bergmann
2016-03-25 22:39 ` Mark Brown
[not found] ` <20160325223922.GG5028-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-03-29 12:39 ` Arnd Bergmann
2016-03-29 16:47 ` Mark Brown
[not found] ` <20160329164758.GQ2350-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-03-29 19:49 ` Arnd Bergmann
2016-03-29 19:52 ` Mark Brown
2016-03-29 20:04 ` Arnd Bergmann
2016-03-29 21:00 ` Mark Brown
[not found] ` <20160329210018.GL2350-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-03-29 21:08 ` Arnd Bergmann
2016-03-29 21:28 ` Mark Brown
[not found] ` <20160329212842.GN2350-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-03-29 22:04 ` Arnd Bergmann
2016-04-05 7:11 ` Stefan Roese
[not found] ` <5703651F.4040901-ynQEQJNshbs@public.gmane.org>
2016-04-05 13:15 ` Andrew Lunn
[not found] ` <20160405131529.GA30881-g2DYL2Zd6BY@public.gmane.org>
2016-04-05 13:20 ` Stefan Roese
[not found] ` <5703BB82.4090204-ynQEQJNshbs@public.gmane.org>
2016-04-05 13:31 ` Andrew Lunn
2016-03-23 13:27 ` Mark Brown
[not found] ` <20160323132732.GN2566-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-03-23 17:25 ` Stefan Roese
[not found] ` <56F2D19A.7020604-ynQEQJNshbs@public.gmane.org>
2016-03-23 18:29 ` Mark Brown
2016-03-23 18:39 ` Andrew Lunn
[not found] ` <20160323183952.GK5250-g2DYL2Zd6BY@public.gmane.org>
2016-03-24 5:45 ` Stefan Roese
2016-03-24 11:23 ` Mark Brown
[not found] ` <20160324112308.GY2566-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-03-24 12:05 ` Stefan Roese
[not found] ` <20160322173546.40d24cc2-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2016-03-22 17:39 ` Mark Brown
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=56F17684.2010307@denx.de \
--to=sr@denx.de \
--cc=arnd@arndb.de \
--cc=broonie@kernel.org \
--cc=ezequiel.garcia@free-electrons.com \
--cc=gregory.clement@free-electrons.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=nadavh@marvell.com \
--cc=thomas.petazzoni@free-electrons.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).