Re: [PATCHv4 2/3] spi: Add spi driver for Socionext Synquacer platform

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux