Harsha Sanjeewa wrote:
> int init_module(void) {
>
> printk("<1> MECR: %x \n", MECR);
> MECR = (MECR & (0x00000)) |0x7fe47fff;
>
> for (driver_i; driver_i < driver_count; driver_i += 1 ) {
> printk("<1> %x : ",PCIO_BASE + driver_start + driver_i);
> printk("%x \n", inb( driver_start + driver_i));
> }
> return 0;
> }
Unless you have some code which deals with this elsewhere, you appear
not to be performing the power-on/reset sequence, so essentially it
doesn't matter whether you have the card physically in the socket or
not. =)
Look in the documentation for your board to see how power control works.
Essentially, you'll want to apply power, wait a little while, apply
power+reset, wait, then apply power only, and wait (at least 20ms, but
in the absence of actually checking the card ready line, just wait a
long time). Now you should be able to read attribute memory.
Some additional notes:
1. You're setting specific MECR fields for slot 1, but leaving slot 0 at
the slowest possible speed. Take a look at Card Services
(http://www.cs.cmu.edu/~wearable/software/pcmcia-arm.html) for a method
to compute the correct values.
2. To permit client driver portability for Card Services, the ISA I/O
macros in the SA-1100 kernel patches no longer apply the PCIO_BASE
offset (2.3.99-pre6-rmk1-np1 and higher, I believe). Be warned.
3. Even after you get this part to work, why rewrite all of the code
that deals with parsing CIS tuples, handling inserts/ejects, &c.?
Consider helping out with Card Services, rather than building a
hardwired driver.
-jd
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
++ Please use [EMAIL PROTECTED] for ++
++ kernel-related discussions. ++
