[gta02-core] ECN0001 comments+patch on SPI

[Rask Ingemann Lambertsen]

On Sun, Aug 30, 2009 at 03:59:52AM +0100, Dave Ball wrote:
> Hi Rask,
>
> Did you see the ecn I posted yesterday?  Might have crossed paths in the  
> mail.

   Yes, the usual stuff: I spotted the new ecn0034 in docs/ecn/STATUS
_after_ sending my message.

> Does that proposed ecn  
> (http://docs.openmoko.org/trac/browser/trunk/gta02-core/docs/ecn/ecn0034.txt) 
> achieve what you were wanting?  If so, I'm in favour of not swapping  
> between GPG6 & GPD9 etc.  The less changes we make to the existing  
> design, the less chance we've got of screwing something subtle up.

   Oh, I see, we already had the accelerometers on SPI1/GPG in GTA02, we
just didn't use the hardware SPI support when talking to the accelerometers.
We've always just bitbanged them, so we can't fully screw it up. Of course
we should try to get the hardware SPI going for efficiency reasons. There is
(was?) actually some confusion as to what some of these SPI pins really are:

https://lists.openmoko.org/pipermail/gta03/2009-May/000210.html

   I'd be fine with me to stay with the accelerometer on GPG and have 0Rs in
the SPI1 traces to be able to swap them with a soldering iron. My worry is
ending up with another GTA02 where things are set in stone and in a useless
state on top of it. Having 0Rs to swap the SPI assignment also means we can
verify the suspicion that VD9/SPICLK1/GPD1 is really VD9/nSPICS1/GPD1.

   As a general observation, in no way specific to SPI, I find it desirable
to allocate the pins such that a device has all its pins in the same GPIO
bank, so if you bitbang the device, you can set several pins with one
instruction.

   As a specific observation in this case, when looking for a new home for
WLAN_INT, I noticed that with DEBUG_SPI using the pins on GPG we'd have:

GPG0/EINT8	 Unused.
GPG1/EINT9	 PWR_IRQ, could swap with e.g. EINT3 on EINT3/GPF3.
GPG2/nSS0/EINT10 WLAN_SS, could use another GPIO (CPU is master).
GPG3/nSS1/EINT11 DEBUG_nSS.
GPG4/.../EINT12	 Unused.
GPG5/.../EINT13	 DEBUG_SPIMISO.
GPG6/.../EINT14	 DEBUG_SPIMOSI.
GPG7/.../EINT15	 DEBUG_SPICLK.

   That's could be the byte aligned, 8-bit parallel port that I'm looking
for to interface devices which move a lot of data. EINT3 is already on the
debug connector and DEBUG_* would go there as well, that leaves just three
more signals to route there. I'd like an EINT pin on top of that, but would
just grab one of the nicely NC-R'd board revision ones if they stay there.
:-)

   I realise this means half the wake-up capable EINTs going to the debug
connector, but the previous assignment wasn't any better in terms of using
them for wake-up purposes. At least you will now be able to easily access
them should the need arise.

> I've also proposed routing VD8/nSPICS1/GPD0 to the debug connector,  
> which should allow for 2 spi-slave devices through the debug connector.

   I have no idea what nSPICS is for that won't work just as well from any
random GPIO. If I'm reading the sc32442 manual right, the hardware nSPICS
support is just the 'n' in nSPICS.

> As far as i can see, SS (input) is only used in multi-master or  
> cpu-as-slave mode - so shouldn't be needed for single or multiple slaves  
> (where cpu is master). However as you mentioned it would be fairly easy  
> to move the WLAN interrupt (this is a new signal in gta02-core) to  
> another free EINT.

   Yes, it is slave mode SPI that I had in mind with the nSS input. Slave
mode SPI needs hardware support and the sc32442 manual gives no indication
that it will work without the nSS input, so I'm assuming the worst.

> Out of interest, is there a specific project you're hoping to use this  
> extra spi connection for?

   Actually, I'm hoping _not_ to use the SPI interface for a camera, like
I'm trying to on the GTA02. It's just a backup plan. A parallel interface is
much preferred as it's faster, easier and cheaper to work with.

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year