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
hw
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
to
expose anything about it
in the public API. Hack should stay hidden, deep, in driver's specific
code.
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

Tomasz

Join devel@lists.zephyrproject.org to automatically receive all group messages.