Re: [RFC] SPI API update

Tomasz Bursztyka

Hi Jon,

On Wed, 2016-09-14 at 09:31 +0200, Tomasz Bursztyka wrote:
This GPIO used as CS is a hack for - currently - DW controllers. When
integration makes it
available (it's possible on QuarkSE X86 core, not on QuarkSE ARC core
for instance).

So indeed, it's very much limited for now, but I don't see any reason
expose anything about it
in the public API. Hack should stay hidden, deep, in driver's specific
Not sure why you call this a 'hack'. Anyway, the serial device IP I'm
writing an SPI driver for (ARM's PL022) doesn't have a concept of a chip
select, so I'm going to have to implement this same 'hack'. Except I
won't, because making the current SPI APIs gate CS on every call to
tranceive makes them silly to use (the zero copy problem as mentioned in
the RFC).
I call it a hack in DW driver, because this controller has a CS... which
is broken.

So, rather than upstreaming this driver along with other board
support, which is what my brief is, I'll just park this work in a fork
somewhere until Zephyr's APIs settle down to something more usable. :-(
Legacy or new API: your driver will have to deal with CS internally,
either controlling the controller's capability or
a GPIO line. That has nothing to do with zero-copy btw.

As I proposed, we could make such "GPIO as CS" generic into an
spi_utils.h into drivers/spi/
It's really a driver centric piece, nothing that needs to be public. Up
to the boards.h file to provide the proper mapping.

We will have to sort this out anyway


Join to automatically receive all group messages.