[PATCH] AT91RM9200 Compact Flash driver
David Brownell
david-b at pacbell.net
Wed Mar 1 11:12:31 EST 2006
On Wednesday 01 March 2006 1:36 am, you wrote:
> > + (void) at91_set_A_periph(AT91_PIN_PC9, 0); /* A25/CFRNW */
> > + (void) at91_set_A_periph(AT91_PIN_PC10, 0); /* NCS4/CFCS */
> > + (void) at91_set_A_periph(AT91_PIN_PC11, 0); /* NCS5/CFCE1 */
> > + (void) at91_set_A_periph(AT91_PIN_PC12, 0); /* NCS6/CFCE2 */
>
> Why do you add "(void)" here before the function call?
To make it explicit that potential fault codes are being ignored;
casting into a void is about the simplest convention for that.
A different question is why the pin muxing is done in that driver
rather than as part of platform setup, which is where it's done for
all (!) the other AT91 platform drivers. And at this point I forget
the issues there, except consistency with:
> > + /* nWAIT is _not_ a default setting */
> > + (void) at91_set_A_periph(AT91_PIN_PC6, 1); /* nWAIT */
When nWAIT is changed, it's possible that PC6 can cause trouble...
ISTR either an erratum or an appnote mention of this (or maybe it
was just an emailed problem report); basically, if that pin just
happens to be inappropriately grounded then the SOC may then decide
to wait at that point, and the weak pullup ("1") won't help. Whole
system locks up; unfriendly, but if it came from "modpdrobe at91_cf"
then it's a bit easier to work around and solve than if it's done
as part of platform setup in (very) early boot.
- Dave
More information about the linux-pcmcia
mailing list