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? -- 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
