On Wed, 2018-02-28 at 23:59 +0530, Jassi Brar 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:
> > >
> > > +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.
It helps when choosing hardware, designing products, and also with
software design. Example:
I really need another GPIO pin on this SoC. Here's this interrupt line
from a spi slave. I don't need that and can take the pin. I can poll
the slave at a low rate and it'll be ok as there is no tight latency
requirement.
That might use a lot more CPU that one would think.
> 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.
Here's another example, someone has a "direct" flash on their hardware,
probably just copied from the reference design. In doing cost
engineering for the next rev, they determine that they don't need much
performance from this flash and should be able to use a cheaper non-vol
storage part (eeprom..). The new part has a Linux driver. No one
realizes the significance of switching from "direct" to "spi" mode.
��.n��������+%������w��{.n����z�{��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
