On Fri, Jun 19, 2009 at 01:45:46PM +0200, Leon Woestenberg wrote:
> Hello,
>
> On Thu, Jun 18, 2009 at 4:04 PM, Kumar Gala<ga...@kernel.crashing.org> wrote:
> > On Jun 18, 2009, at 8:09 AM, Anton Vorontsov wrote:
> >> On Thu, Jun 18, 2009 at 08:19:44AM +0200, Rini van Zetten wrote:
> >>>
> >>> This patch adds the possibility to have a spi device without a cs.
> >>>
> > That is a good question. What HW is this for (I don't think its for eSPI
> > but I could be wrong).
> >
> We need SPI without CS too on our MPC8313E design.
We do support SPI without CS, but only for one slave device. If
there is no CS, technically you can address only one device on a
SPI bus.
And apparently Rini's case is not for addressing multiple chips
w/o CS lines, it's just some chip-selects need quirks.
> In our case having a CS line to each slave (18 of them) is too
> expensive and we use a chip select which piggy backs on another
> signal.
> Once the slave is selected, SPI is used to send large amounts of data.
Can you describe it a little bit more? Have you patched the SPI
driver to work with your setup?
If you can address 18 slaves w/o chip-select line, I quess
you have a CS demuxing bridge somewhere, i.e.
spi-controller {
/*
* no chip-selects from the controller, it can only talk to
* one device: the cs demuxing bridge, it is always selected.
*/
spi-cs-demuxing-bridge {
/*
* knows how to manage chip-selects (or demux
* one chip select line for several slaves)
*/
spi-slave {
reg = <0>;
};
...
spi-slave {
reg = <17>;
};
};
};
Surely we can hide the bridge into the SPI controller driver,
but I think it would be beneficial to "factor-out" it to a
stand-alone entity, so that other SPI controllers could work
with this setup without any modifications (oh and btw, we could
also create a bridge called "gpio-chipselects-bridge", and
factor out all GPIO stuff from the drivers).
There are two options of how we can factor out chip-select
machines... the bad and the ugly. :-) No, the first one is bad,
but the second should be OK.
1. We can create full-fledged SPI master bridge drivers, the
drivers will just pass-through all SPI IO, but will manage
chip-selects. The bad part is that these drivers could degrade
performance since they'll have to manage SPI IO, which is
unneeded for the pure CS machines.
2. Another option (which I like more), is to create "SPI chip-
select machine driver framework", so we could (finally)
separate two SPI entities: SPI IO and SPI chip-select machine.
CS machines of different flavours: GPIO, built-in, and
board-specific (!) with a lot of demuxing magic.
(1) can be implemented trivially, while (2) is a lot of work.
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
