On Thu, Mar 1, 2018 at 12:06 AM, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > On 28 February 2018 at 18:29, Jassi Brar <jassisinghbrar@xxxxxxxxx> wrote: >> On Wed, Feb 28, 2018 at 11:25 PM, Trent Piepho <tpiepho@xxxxxxxxxx> wrote: >>> On Tue, 2018-02-27 at 18:28 +0530, jassisinghbrar@xxxxxxxxx wrote: >>>> From: Jassi Brar <jaswinder.singh@xxxxxxxxxx> >>>> >>>> This patch adds support for controller found on synquacer platforms. >>>> >>>> Signed-off-by: Jassi Brar <jaswinder.singh@xxxxxxxxxx> >>>> --- >>>> drivers/spi/Kconfig | 11 + >>>> drivers/spi/Makefile | 1 + >>>> drivers/spi/spi-synquacer.c | 663 ++++++++++++++++++++++++++++++++++++++++++++ >>>> 3 files changed, 675 insertions(+) >>>> create mode 100644 drivers/spi/spi-synquacer.c >>>> >>>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig >>>> index 6037839..9e04bbe 100644 >>>> --- a/drivers/spi/Kconfig >>>> +++ b/drivers/spi/Kconfig >>>> @@ -659,6 +659,17 @@ config SPI_SUN6I >>>> help >>>> This enables using the SPI controller on the Allwinner A31 SoCs. >>>> >>>> +config SPI_SYNQUACER >>>> + tristate "Socionext's Synquacer HighSpeed SPI controller" >>>> + depends on ARCH_SYNQUACER || COMPILE_TEST >>>> + select SPI_BITBANG >>>> + help >>>> + SPI driver for Socionext's High speed SPI controller which provides >>>> + various operating modes for interfacing to serial peripheral devices >>>> + that use the de-facto standard SPI protocol. >>>> + >>>> + It also supports the new dual-bit and quad-bit SPI protocol. >>>> + >>> >>> As someone who designs and develops embedded Linux devices, it would be >>> really useful if there was a bit more documentation about the driver. >>> >>> The hardware doesn't support DMA or even interrupts, and must busy wait >>> for the duration of the entire SPI transfers. That's kind of a Big >>> Deal. A design that involves lots of SPI transfers on a slow clock >>> will work fine on most SPI hardware, but will be utterly unfeasible >>> here. It would be nice to say something about that. I'd probably put >>> it in driver code. >>> >> From marketing point of view, why would I want to advertise my limitations? :) >> >> Its not like any random platform might want to use this driver, nor >> the enduser could do anything about it (its not a s/w issue). The >> decision to integrate the ip in a SoC is already taken before the >> driver is written. Obviously the users that need high spi performance >> are not its intended target. >> >> BTW, the IP is actually not that bad. It is meant for interfacing >> flash devices and can operate in two modes - "direct" mode where it >> maps flash memory as i/o region and the other last resort "spi" mode >> where we could manually drive the flash. This driver implements that >> limited "spi" mode. >> > > My SoC manual does list interrupts for this IP block. Are you sure > SynQuacer uses the same version of the IP as before? > Having got hold of english specs, the newer version does seem to support IRQ despite being named same "FIP006" as before. Let me investigate deeper. Thanks. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
