[PATCH 6/6] [WIP] libertas: add support for 8385 CompactFlash cards
Dan Williams
dcbw at redhat.com
Tue Jun 19 12:28:42 EDT 2007
On Tue, 2007-06-19 at 17:47 +0200, Holger Schurig wrote:
> > > +static int if_cs_poll_reg(struct if_cs_card *card, uint
> addr, u8 reg)
> > > +{
> > > + int i;
> > > +
> > > + for (i = 0; i < 500; i++) {
> > > + u8 val = if_cs_read8(card, addr);
> > > + if (val == reg)
> > > + return i;
> > > + udelay(100);
> > > + }
> > > + return -ETIME;
> >
> > Hmm; is it normal in CF drivers to poll the card a lot, or is
> > this just
> > for test/debug for the time being?
>
> Until I find a better programming idiom. Look in the firmware
> v5.1 manual, page 18, 3. e) and page 19, at the very top, point
> 9. I didn't follow their timing exactly.
>
> The polling actually only happens while programming the firmware,
> so for me getting it working was more important than
> over-optimizing.
>
> Do you have suggestions for me? This doesn't happen in interrupt
> context, so I guess I can sleep. Or I could transform this into
> a statemachine and let call back from the kernel, but this seems
> a bit complicated. Any ideas?
Hmm, not really, I think we pretty much just do a lot of mdelay(x) on
USB too when programming firmware. So nevermind.
> > > +#define IF_CS_H_STATUS 0x00000000
> > > +#define IF_CS_H_STATUS_TX_OVER 0x01
> > > +#define IF_CS_H_STATUS_RX_OVER 0x02
> > > +#define IF_CS_H_STATUS_DNLD_OVER 0x04
> > > +
> > > +#define IF_CS_H_INT_CAUSE 0x00000002
> > > +#define IF_CS_H_IC_TX_OVER 0x0001
> > > +#define IF_CS_H_IC_RX_OVER 0x0002
> > > +#define IF_CS_H_IC_DNLD_OVER 0x0004
> > > +#define IF_CS_H_IC_HOST_EVENT 0x0008
> > > +#define IF_CS_H_IC_MASK 0x001f
> >
> > These look a lot like the HIS_* defines above, are they the
> > same?
>
> Yes, you're right. I added them before I found the HIS_xxx
> defines in defs.h. At that time, my constants where hardware
> related, the other ones logical bits.
>
> > Yeah, there seem to be a lot of these same constants floating
> > around, it would be good to consolidate them all and just have
> > two, I assume one for host bits and one for card bits, right?
>
> Or even just one, if they are the same anyway.
>
>
> > > + /* "If the value is 0x5a, the firmware is already
> > > + * downloaded successfully"
> > > + */
> > > + if (scratch == 0x5a)
> > > + goto done;
> > > +
> > > + /* "If the value is != 00, it is invalid value of register
> > > */ + if (scratch != 0x00) {
> > > + ret = -ENODEV;
> > > + goto done;
> > > + }
> >
> > Are the 0x5a and 0x00 values determined empirically?
>
> No, see Firmware Specification v5.1, page 18.
Ah, sorry. Forgot. We should probably get nice names for these.
> > Also,
> > are the scratch registers part and interface dependent at all?
> > The SDIO driver uses different values for "firmware ready"; I
> > wouldn't expect them to be the same, but how similar are SDIO
> > and CF? They appear to use a lot of the same constructs and
> > even constants.
>
> For now, I don't care. I don't see that if_cs.c also contains
> code for SDIO, I much more see that a different if_sdio.c file
> get's written. Once that is done, we can look at what is equal
> and put that into a header file.
Yeah, I'm just trying to make sure that CF-specific constants are kept
in CF-only files.
> > One more quick question; does the device show up correctly in
> > HAL as a child of the socket? It should be Socket > Card >
> > network interface I think.
>
> What is HAL? I don't know this software. However, in my /sys
> tree, I see some directories like this, so I guess it's properly
> put there:
HAL is used on many non-embedded systems (and also on more embedded ones
like Nokia internet tablets) to provide a consistent view of hardware,
including the relationships between devices. We need to make sure that
the right symlinks are made by the driver in sysfs (like SET_NETDEV_DEV)
so that things come out right in HAL too.
> ./pci0000:00/0000:00:1e.0/0000:02:0b.0
> ./pci0000:00/0000:00:1e.0/0000:02:0b.0/0.0
> ./pci0000:00/0000:00:1e.0/0000:02:0b.0/0.0/net
> ./pci0000:00/0000:00:1e.0/0000:02:0b.0/0.0/net/eth1
> ./pci0000:00/0000:00:1e.0/0000:02:0b.0/0.0/net/eth1/power
> ./pci0000:00/0000:00:1e.0/0000:02:0b.0/0.0/net/eth1/wireless
> ./pci0000:00/0000:00:1e.0/0000:02:0b.0/0.0/net/eth1/statistics
> ./pci0000:00/0000:00:1e.0/0000:02:0b.0/0.0/power
> ./pci0000:00/0000:00:1e.0/0000:02:0b.0/pcmcia_socket
> ./pci0000:00/0000:00:1e.0/0000:02:0b.0/pcmcia_socket/pcmcia_socket0
> ./pci0000:00/0000:00:1e.0/0000:02:0b.0/pcmcia_socket/pcmcia_socket0/power
> ./pci0000:00/0000:00:1e.0/0000:02:0b.0/power
For a true PCMCIA card (Cisco Aironet 350), I get this
from /sys/class/net/eth2:
-r--r--r-- 1 root root 4096 Jun 19 12:25 address
-r--r--r-- 1 root root 4096 Jun 19 12:25 addr_len
-r--r--r-- 1 root root 4096 Jun 19 12:25 broadcast
-r--r--r-- 1 root root 4096 Jun 19 12:25 carrier
lrwxrwxrwx 1 root root 0 Jun 19 12:25 device -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:00.0/0.0
-r--r--r-- 1 root root 4096 Jun 19 12:25 dormant
-r--r--r-- 1 root root 4096 Jun 19 12:25 features
-rw-r--r-- 1 root root 4096 Jun 19 12:25 flags
-r--r--r-- 1 root root 4096 Jun 19 12:25 ifindex
-r--r--r-- 1 root root 4096 Jun 19 12:25 iflink
-r--r--r-- 1 root root 4096 Jun 19 12:25 link_mode
-rw-r--r-- 1 root root 4096 Jun 19 12:25 mtu
-r--r--r-- 1 root root 4096 Jun 19 12:25 operstate
drwxr-xr-x 2 root root 0 Jun 19 12:25 statistics
lrwxrwxrwx 1 root root 0 Jun 19 12:25 subsystem -> ../../../class/net
-rw-r--r-- 1 root root 4096 Jun 19 12:25 tx_queue_len
-r--r--r-- 1 root root 4096 Jun 19 12:25 type
--w------- 1 root root 4096 Jun 19 12:25 uevent
-rw-r--r-- 1 root root 4096 Jun 19 12:25 weight
drwxr-xr-x 2 root root 0 Jun 19 12:25 wireless
The required thing there is the 'device' link. That points HAL to the
right parent device, which looks like:
--w------- 1 root root 0 Jun 19 12:25 allow_func_id_match
lrwxrwxrwx 1 root root 0 Jun 19 12:25 bus -> ../../../../../bus/pcmcia
-r--r--r-- 1 root root 4096 Jun 19 12:25 card_id
lrwxrwxrwx 1 root root 0 Jun 19 12:25 driver -> ../../../../../bus/pcmcia/drivers/airo_cs
-r--r--r-- 1 root root 4096 Jun 19 12:25 func_id
-r--r--r-- 1 root root 4096 Jun 19 12:27 function
-r--r--r-- 1 root root 4096 Jun 19 12:25 manf_id
-r--r--r-- 1 root root 4096 Jun 19 12:27 modalias
lrwxrwxrwx 1 root root 0 Jun 19 12:27 net:eth2 -> ../../../../../class/net/eth2
-rw-r--r-- 1 root root 4096 Jun 19 12:27 pm_state
drwxr-xr-x 2 root root 0 Jun 19 12:25 power
-r--r--r-- 1 root root 4096 Jun 19 12:25 prod_id1
-r--r--r-- 1 root root 4096 Jun 19 12:25 prod_id2
-r--r--r-- 1 root root 4096 Jun 19 12:25 prod_id3
-r--r--r-- 1 root root 4096 Jun 19 12:25 prod_id4
lrwxrwxrwx 1 root root 0 Jun 19 12:25 subsystem -> ../../../../../bus/pcmcia
--w------- 1 root root 4096 Jun 19 12:27 uevent
and that allows HAL to construct it's device tree. What do you have
in /sys/class/net/eth1, and when you follow the 'device' link in that
directory (if you don't have it you need to get it) what's in the device
directory?
Dan
More information about the libertas-dev
mailing list