linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: sr@denx.de (Stefan Roese)
To: linux-arm-kernel@lists.infradead.org
Subject: [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

  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
2016-03-22 16:35 ` Thomas Petazzoni
2016-03-22 16:44   ` Stefan Roese [this message]
2016-03-23 11:33     ` Mark Brown
2016-03-23 11:59       ` Stefan Roese
2016-03-23 12:54         ` Mark Brown
2016-03-23 13:10           ` Stefan Roese
2016-03-23 13:26             ` Andrew Lunn
2016-03-23 13:36               ` Mark Brown
2016-03-23 13:56                 ` Andrew Lunn
2016-03-23 19:51                   ` Arnd Bergmann
2016-03-24  7:22                     ` Stefan Roese
2016-03-24 12:42                       ` Arnd Bergmann
2016-03-24 16:15                         ` Stefan Roese
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
2016-03-24 20:07                               ` Arnd Bergmann
2016-03-25 10:32                                 ` Mark Brown
2016-03-25 15:11                                   ` Arnd Bergmann
2016-03-25 15:50                                     ` Mark Brown
2016-03-25 20:58                                       ` Arnd Bergmann
2016-03-25 22:39                                         ` Mark Brown
2016-03-29 12:39                                           ` Arnd Bergmann
2016-03-29 16:47                                             ` Mark Brown
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
2016-03-29 21:08                                                       ` Arnd Bergmann
2016-03-29 21:28                                                         ` Mark Brown
2016-03-29 22:04                                                           ` Arnd Bergmann
2016-04-05  7:11                                                             ` Stefan Roese
2016-04-05 13:15                                                               ` Andrew Lunn
2016-04-05 13:20                                                                 ` Stefan Roese
2016-04-05 13:31                                                                   ` Andrew Lunn
2016-03-23 13:27             ` Mark Brown
2016-03-23 17:25               ` Stefan Roese
2016-03-23 18:29                 ` Mark Brown
2016-03-23 18:39                 ` Andrew Lunn
2016-03-24  5:45                   ` Stefan Roese
2016-03-24 11:23                     ` Mark Brown
2016-03-24 12:05                       ` Stefan Roese
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=linux-arm-kernel@lists.infradead.org \
    /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).