ar71xx_gpio.c touches SPI_CS1 and 2?

[Stefan Bethke]

Am 04.12.2011 um 14:01 schrieb Adrian Chadd:

> Well, the real question is whether the SPI CS pins are actually the
> ones being used or not.

I'll try and break CS1 and see what happens…

> I'm pretty sure the SPI flash is actually being talked to via
> bitbanged GPIO, rather than the actual ar71xx/ar91xx SPI interface.
> So those chip selects aren't strictly needed.

I couldn't tell.  The register definitions in ar71xxreg.h seem to indicate that there is hardware support for SPI, and that CS1 and CS2 (but not CS0) share the pins with GPIO, but looking at the code in ar71xx_spi.c seems to do bit banging for transmit and register read for reception.  Does the SPI support only have a shift register for reception?

> They may be needed for the mikrotik routerboard's though, I recall
> gonzo@ talking about something like that.
> 
> I think we can just work around this by having a boot-time machine
> dependent "function mask" hint which we set to define which on-board
> peripherals are enabled.
> It can be machdep rather than generic, as we'd likely set it up early
> - eg, ar71xx_machdep.c::platform_start().
> 
> The only downside which i haven't yet thought through is whether to:
> 
> * just write a raw value to the function register, which means we
> would override whatever the bootloader revision says; or
> * have two hints - one "clear these bits" and one "set these bits" in
> the GPIO function register, so we can override what the bootloader
> code does at startup. That way if it, for example, initialises the
> sound pins, we don't have to know that unless we want to use the GPIO
> pins shared by the sound interface.
> 
> How's that sound? Too dirty? :)

Hhm.

How about the ar71xx_spi.c driver claiming CS0 and optionally CS1 and CS2 (again via hint?), and setting the GPIO function bits accordingly?  Or only activate CS1 and CS2 if we have SPI bus children that claim them?


Stefan

-- 
Stefan Bethke <stb at lassitu.de>   Fon +49 151 14070811