linux-mips
[Top] [All Lists]

Problems with PCMCIA on AMD dbau1100

To: linux-mips@linux-mips.org
Subject: Problems with PCMCIA on AMD dbau1100
From: Josh Green <jgreen@users.sourceforge.net>
Date: Tue, 21 Dec 2004 03:31:05 -0800
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
I'm having trouble getting PCMCIA to work properly on my dbau1100 MIPS
board with latest CVS (2.6.10rc3).  Any help would be very appreciated.
Here is lsmod output:

# lsmod
Module                  Size  Used by    Not tainted
au1x00_ss 12160 0 - Live 0xc0005000
pcmcia_core 60848 1 au1x00_ss, Live 0xc0015000


I get this output when modprobing au1x00_ss:

Linux Kernel Card Services
  options:  none


At this point 'pcmcia' is not listed in /proc/devices though, so I'm
assuming another module needs to be inserted?  On my x86 laptop I see
there is a ds module.  This appears to have been compiled into an object
for my MIPS build, but there is no stand alone ds module.  If I insert
the 'pcmcia' module I get pcmcia support (I'm assuming this is the 16
bit PCMCIA module, it doesn't appear dependent on au1x00_ss), but no
cards are detected:

# cardctl ident
Socket 0:
  no product info available
Socket 1:
  no product info available

# cardctl status
Socket 0:
  no card
Socket 1:
  no card


One thing to note is that I get a few warnings during the PCMCIA build:

  CC [M]  drivers/pcmcia/au1000_generic.o
drivers/pcmcia/au1000_generic.c: In function
`au1x00_pcmcia_socket_probe':
drivers/pcmcia/au1000_generic.c:425: warning: integer constant is too
large for "long" type
drivers/pcmcia/au1000_generic.c:433: warning: integer constant is too
large for "long" type

The first warning is related to the following code (second is similar
but for socket 1):

        skt->virt_io = (void *)
                ((u32)ioremap((ioaddr_t)AU1X_SOCK0_IO, 0x1000) -
                (u32)mips_io_port_base);


AU1X_SOCK0_IO is defined as 0xF00000000 which is a 36 bit number, not
sure if that will cause a problem or not (since ioremap is using phys_t
which is 32 bit).  Perhaps this truncation is intentional though.

Thanks in advance for any helpful pointers. Best regards,
        Josh Green

Attachment: signature.asc
Description: This is a digitally signed message part

<Prev in Thread] Current Thread [Next in Thread>