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. Cheers! -- 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
