Revisiting "problem with converting from at91_spi to atmel_spi (AT91RM9200)"

Revisiting "problem with converting from at91_spi to atmel_spi (AT91RM9200)"

[LTI. - Ticmanis, Linards]

Hello to all,

I was wondering if the problem described in the thread "problem with converting from at91_spi to atmel_spi (AT91RM9200)" from last May was ever solved, as I'm currently running into the same trouble. at91_spi works nicely with an at25-driven EEPROM on CS0, but atmel_spi doesn't - it just blocks whatever thread is using it.

While that's no problem in the EEPROM case, a customer wants to use SPI basically as a very fast UART between two AT91RM9200 based boards now, on which only CS0 is available. Is there no other chance than converting the layout to use another CS instead?

Thanks for any hints offered to this kernel newbie,
-- 
Linards Ticmanis
Team Systemsoftware
Skeye Germany
Höft & Wessel AG

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Revisiting "problem with converting from at91_spi to atmel_spi (AT91RM9200)"

[David Brownell]

> I was wondering if the problem described in the thread "problem with
> converting from at91_spi to atmel_spi (AT91RM9200)" from last May
> was ever solved, as I'm currently running into the same trouble.
> at91_spi works nicely with an at25-driven EEPROM on CS0, but atmel_spi
> doesn't - it just blocks whatever thread is using it.

Andrew Victor had partial success after updating the platform setup
code appropriately.  I don't know what the status of that patch is.


> While that's no problem in the EEPROM case, a customer wants to use
> SPI basically as a very fast UART between two AT91RM9200 based boards
> now, on which only CS0 is available. Is there no other chance than
> converting the layout to use another CS instead?

Unfortunately CS0 on rm9200 seems especially full of trouble; from
what I've seen and heard, using another chipselect would be good
just on the basis of the number of CS0-specific errata.

Of course, if you just want UART-ish behavior, you might also be
able to use one of the SSC channels.  The SPI stack aims to handle
master/slave style communication, not peer-to-peer.  When you're
modeling a bidirectional byte stream, that's the wrong model. 
Plus, you'd have fewer chip errata to cope with.

- Dave


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: Revisiting "problem with converting from at91_spi to atmel_spi (AT91RM9200)"

[Andrew Victor]

hi David,

> Andrew Victor had partial success after updating the platform setup
> code appropriately.  I don't know what the status of that patch is.

I never seemed to get it working consistently with DataFlash.
Changing dataflash_status() to only perform a single transfer made CS0
work.  But no luck with the DataFlash card on CS3 (tried both GPIO and
Periphereral mode).

No problems using the old at91_spi and at91_dataflash though.


Regards,
  Andrew Victor



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/