From jbj1 at ultraemail.net  Mon Jun  7 18:45:58 2004
From: jbj1 at ultraemail.net (Jens B. Jorgensen)
Date: Mon Jun  7 18:46:11 2004
Subject: orinoco_cs.c cannot get io ports (cs.c 1.271), can anyone help me
 understand why?
Message-ID: <40C4F026.9070302@ultraemail.net>

Hello,

I'm trying to get a wireless card working under a new Fedora 
installation. I worked find under a previous install and I'm stymied as 
to why it won't work in this system. The card lives in an isa-to-pcmcia 
adapter. The Fedora install uses kernel 2.6.5-1.358. A working example 
system is a recent Knoppix using 2.4.20-xfs. In Knoppix I see:

Linux Kernel Card Services 3.1.22
  options:  [pci] [cardbus] [pm]
Intel PCIC probe:
  Vadem VG-469 ISA-to-PCMCIA at port 0x3e0 ofs 0x00, 2 sockets
    host opts [0]: [ext mode] [isa buf]
    host opts [1]: [ext mode] [isa buf]
    ISA irqs (scanned) = 3,4,7 polling interval = 1000 ms
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0820-0x08ff: clean.
cs: IO port probe 0x0800-0x080f: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x100-0x107 0x2f8-0x2ff 
0x378-0x37f 0
x3f8-0x3ff 0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
cs: memory probe 0x0d0000-0x0dffff: excluding 0xdc000-0xdffff
cs: memory probe 0x0c0000-0x0cffff: excluding 0xc0000-0xcffff
hermes.c: 4 Dec 2002 David Gibson <hermes@gibson.dropbear.id.au>
orinoco.c 0.13b (David Gibson <hermes@gibson.dropbear.id.au> and others)
orinoco_cs.c 0.13b (David Gibson <hermes@gibson.dropbear.id.au> and others)
eth0: Station identity 001f:0002:0001:0004
eth0: Looks like an Intersil firmware version 1.4.2
eth0: Ad-hoc demo mode supported
eth0: IEEE standard IBSS ad-hoc mode supported
eth0: WEP supported, 104-bit key
eth0: MAC address 00:03:9D:40:1F:74
eth0: Station name "Prism  I"
eth0: ready
eth0: index 0x01: Vcc 3.3, irq 3, io 0x0180-0x01bf
eth0: New link status: Connected (0001)

while under the fedora system I get:

Linux Kernel Card Services
  options:  [pci] [cardbus] [pm]
Intel ISA PCIC probe:
  Vadem VG-469 ISA-to-PCMCIA at port 0x3e0 ofs 0x00, 2 sockets
    host opts [0]: [ext mode]
    host opts [1]: [ext mode]
    ISA irqs (scanned) = 3,4,7 polling interval = 1000 ms
eth0: no IPv6 routers present
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x100-0x107 0x378-0x37f 
0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
cs: memory probe 0x0d0000-0x0dffff: clean.
orinoco.c 0.13e (David Gibson <hermes@gibson.dropbear.id.au> and others)
orinoco_cs.c 0.13e (David Gibson <hermes@gibson.dropbear.id.au> and others)
GetNextTuple().  No matching CIS configuration, maybe you need the 
ignore_cis_vcc=1 parameter.
orinoco_cs: GetFirstTuple: No more items

I thought it curious that I don't see [isa buf] after host opts under 
2.6.5 but I'm not even sure what that does so I've not pursued that. The 
obvious check was to try the ignore_cis_vcc. I added that and still the 
same error. So, I hacked some extra debugging info into orinoco_cs.c to 
see where things were *actually* failing. The above is from the first 
run. After having added my own debugging printks I see:

orinoco_cs: skipping because pcmcia_request_io(link->handle, &link->io) 
failed: 30
orinoco_cs: req->Attributes1 = 8, req->BasePort1 = 0, req->NumPorts1 = 
64, req->IOAddrLines = 6

so pcmcia_request_io is failing with CS_IN_USE with the above params. 
However, I cannot for the life of me figure why it was unable to find an 
ioport region. It seems to be instructed to consider the ioport region 
0x180 - 0x1bf and in fact with this installation it is not in use: 
(excerpt from /proc/ioports)

00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0213-0213 : ISAPnP

So why would it not choose to use 0x180 - 0x1bf?! What am I missing?

Thanks for any help,

-- 
Jens B. Jorgensen
jbj1@ultraemail.net


From proski at gnu.org  Mon Jun  7 22:18:17 2004
From: proski at gnu.org (Pavel Roskin)
Date: Mon Jun  7 22:18:32 2004
Subject: orinoco_cs.c cannot get io ports (cs.c 1.271), can anyone help
	me understand why?
In-Reply-To: <40C4F026.9070302@ultraemail.net>
References: <40C4F026.9070302@ultraemail.net>
Message-ID: <20040607221817.azo44gwo88gs0k8s@webmail.spamcop.net>

Quoting "Jens B. Jorgensen" <jbj1@ultraemail.net>:

> Hello,
>
> I'm trying to get a wireless card working under a new Fedora
> installation. I worked find under a previous install and I'm stymied as
> to why it won't work in this system. The card lives in an isa-to-pcmcia
> adapter. The Fedora install uses kernel 2.6.5-1.358. A working example
> system is a recent Knoppix using 2.4.20-xfs. In Knoppix I see:

Compare /etc/pcmcia/config.opts on both systems.

--
Regards,
Pavel Roskin

From okurth at gmx.net  Tue Jun  8 12:43:53 2004
From: okurth at gmx.net (Oliver Kurth)
Date: Tue Jun  8 12:48:53 2004
Subject: ooops with USB 2.0 Cardbus card, keventd dies
Message-ID: <1086713033.1277.41.camel@localhost>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.infradead.org/pipermail/linux-pcmcia/attachments/20040608/af8f19b3/attachment.bin
From jbj1 at ultraemail.net  Tue Jun  8 18:47:07 2004
From: jbj1 at ultraemail.net (Jens B. Jorgensen)
Date: Tue Jun  8 18:47:18 2004
Subject: [fixed] orinoco_cs.c cannot get io ports (cs.c 1.271), can anyone
 help me understand why?
In-Reply-To: <40C4F026.9070302@ultraemail.net>
References: <40C4F026.9070302@ultraemail.net>
Message-ID: <40C641EB.1060206@ultraemail.net>

So after putting in all manner of printk() statements deeper and deeper 
I discovered something interesting. I was using lxr to trace through the 
source on the web and noticed that my fedora core 2 source for 
rsrc_mgr.c didn't match that of the "stock" 2.6.5 code. In particular, I 
noticed that the fedora core 2 code has

int find_io_region(ioaddr_t *base, ioaddr_t num, unsigned long align,
                   char *name, struct pcmcia_socket *s)
{
        struct resource *res = make_resource(0, num, IORESOURCE_IO, name);
        struct pcmcia_align_data data;
        unsigned long min = *base;
        int ret;

        if (align == 0)
                align = 0x10000;

        data.mask = align - 1;
        data.offset = *base & data.mask;
        data.map = &io_db;

#ifdef CONFIG_PCI
        if (s->cb_dev) {
                ret = pci_bus_alloc_resource(s->cb_dev->bus, res, num, 1,
                                             min, 0, pcmcia_align, &data);
                printk(KERN_ERR "rsrc_mgr.c: pci_bus_alloc_resource(...) 
returne
d %d\n", ret);
        } else
#endif
        {
                down(&rsrc_sem);
                ret = allocate_resource(&ioport_resource, res, num, min, 
~0UL, 0
,
                                        pcmcia_align, &data);
                printk(KERN_ERR "rsrc_mgr.c: allocate_resource(...) 
returned %d\n", ret);
                up(&rsrc_sem);
        }

        if (ret != 0) {
                kfree(res);
        } else {
                *base = res->start;
        }
        return ret;
}


while the 2.6.5 code I was looking at on lxr was:

569 int find_io_region(ioaddr_t *base, ioaddr_t num, ioaddr_t align,
570                    char *name, struct pcmcia_socket *s)
571 {
572     ioaddr_t try;
573     resource_map_t *m;
574     int ret = -1;
575
576     down(&rsrc_sem);
577     for (m = io_db.next; m != &io_db; m = m->next) {
578         try = (m->base & ~(align-1)) + *base;
579         for (try = (try >= m->base) ? try : try+align;
580              (try >= m->base) && (try+num <= m->base+m->num);
581              try += align) {
582             if (request_io_resource(try, num, name, s->cb_dev) == 0) {
583                 *base = try;
584                 ret = 0;
585                 goto out;
586             }
587             if (!align)
588                 break;
589         }
590     }
591  out:
592     up(&rsrc_sem);
593     return ret;
594 }

So I thought to myself: hey, it looks like those Fedora guys decided to 
make their pcmcia code use this new-fangled allocate_resource function 
but perhaps the "include ..." lines in /etc/pcmcia/config.opts are 
causing it to /reserve/ those ioports in such a way that they are not 
available to allocate_resource? While I am not dedicated enough to 
digging that far into it I saw I could easily test my theory. I 
commented out the line:

include port 0x100-0x4ff, port 0xc00-0xcff

Since I new the region it was after was in that range. I did that, 
restarted cardmgr and sure enough now the device came up! I'm going to 
guess that /all/ off the resource lines in /etc/pcmcia/config.opts 
should be commented out under fedora core 2. It looks like this would 
only affect ISA bus people which are probably in the minority amongst 
pcmcia users so perhaps that is why this went unnoticed.

Jens B. Jorgensen wrote:

> Hello,
>
> I'm trying to get a wireless card working under a new Fedora 
> installation. I worked find under a previous install and I'm stymied 
> as to why it won't work in this system. The card lives in an 
> isa-to-pcmcia adapter. The Fedora install uses kernel 2.6.5-1.358. A 
> working example system is a recent Knoppix using 2.4.20-xfs. In 
> Knoppix I see:
>
> Linux Kernel Card Services 3.1.22
>  options:  [pci] [cardbus] [pm]
> Intel PCIC probe:
>  Vadem VG-469 ISA-to-PCMCIA at port 0x3e0 ofs 0x00, 2 sockets
>    host opts [0]: [ext mode] [isa buf]
>    host opts [1]: [ext mode] [isa buf]
>    ISA irqs (scanned) = 3,4,7 polling interval = 1000 ms
> cs: IO port probe 0x0c00-0x0cff: clean.
> cs: IO port probe 0x0820-0x08ff: clean.
> cs: IO port probe 0x0800-0x080f: clean.
> cs: IO port probe 0x0100-0x04ff: excluding 0x100-0x107 0x2f8-0x2ff 
> 0x378-0x37f 0
> x3f8-0x3ff 0x4d0-0x4d7
> cs: IO port probe 0x0a00-0x0aff: clean.
> cs: memory probe 0x0d0000-0x0dffff: excluding 0xdc000-0xdffff
> cs: memory probe 0x0c0000-0x0cffff: excluding 0xc0000-0xcffff
> hermes.c: 4 Dec 2002 David Gibson <hermes@gibson.dropbear.id.au>
> orinoco.c 0.13b (David Gibson <hermes@gibson.dropbear.id.au> and others)
> orinoco_cs.c 0.13b (David Gibson <hermes@gibson.dropbear.id.au> and 
> others)
> eth0: Station identity 001f:0002:0001:0004
> eth0: Looks like an Intersil firmware version 1.4.2
> eth0: Ad-hoc demo mode supported
> eth0: IEEE standard IBSS ad-hoc mode supported
> eth0: WEP supported, 104-bit key
> eth0: MAC address 00:03:9D:40:1F:74
> eth0: Station name "Prism  I"
> eth0: ready
> eth0: index 0x01: Vcc 3.3, irq 3, io 0x0180-0x01bf
> eth0: New link status: Connected (0001)
>
> while under the fedora system I get:
>
> Linux Kernel Card Services
>  options:  [pci] [cardbus] [pm]
> Intel ISA PCIC probe:
>  Vadem VG-469 ISA-to-PCMCIA at port 0x3e0 ofs 0x00, 2 sockets
>    host opts [0]: [ext mode]
>    host opts [1]: [ext mode]
>    ISA irqs (scanned) = 3,4,7 polling interval = 1000 ms
> eth0: no IPv6 routers present
> cs: IO port probe 0x0c00-0x0cff: clean.
> cs: IO port probe 0x0100-0x04ff: excluding 0x100-0x107 0x378-0x37f 
> 0x4d0-0x4d7
> cs: IO port probe 0x0a00-0x0aff: clean.
> cs: memory probe 0x0d0000-0x0dffff: clean.
> orinoco.c 0.13e (David Gibson <hermes@gibson.dropbear.id.au> and others)
> orinoco_cs.c 0.13e (David Gibson <hermes@gibson.dropbear.id.au> and 
> others)
> GetNextTuple().  No matching CIS configuration, maybe you need the 
> ignore_cis_vcc=1 parameter.
> orinoco_cs: GetFirstTuple: No more items
>
> I thought it curious that I don't see [isa buf] after host opts under 
> 2.6.5 but I'm not even sure what that does so I've not pursued that. 
> The obvious check was to try the ignore_cis_vcc. I added that and 
> still the same error. So, I hacked some extra debugging info into 
> orinoco_cs.c to see where things were *actually* failing. The above is 
> from the first run. After having added my own debugging printks I see:
>
> orinoco_cs: skipping because pcmcia_request_io(link->handle, 
> &link->io) failed: 30
> orinoco_cs: req->Attributes1 = 8, req->BasePort1 = 0, req->NumPorts1 = 
> 64, req->IOAddrLines = 6
>
> so pcmcia_request_io is failing with CS_IN_USE with the above params. 
> However, I cannot for the life of me figure why it was unable to find 
> an ioport region. It seems to be instructed to consider the ioport 
> region 0x180 - 0x1bf and in fact with this installation it is not in 
> use: (excerpt from /proc/ioports)
>
> 00c0-00df : dma2
> 00f0-00ff : fpu
> 0170-0177 : ide1
> 01f0-01f7 : ide0
> 0213-0213 : ISAPnP
>
> So why would it not choose to use 0x180 - 0x1bf?! What am I missing?
>
> Thanks for any help,
>


-- 
Jens B. Jorgensen
jbj1@ultraemail.net


From rmk+pcmcia at arm.linux.org.uk  Tue Jun  8 19:23:18 2004
From: rmk+pcmcia at arm.linux.org.uk (Russell King)
Date: Tue Jun  8 19:23:30 2004
Subject: [fixed] orinoco_cs.c cannot get io ports (cs.c 1.271),
	can anyone help me understand why?
In-Reply-To: <40C641EB.1060206@ultraemail.net>;
	from jbj1@ultraemail.net on Tue, Jun 08, 2004 at 05:47:07PM -0500
References: <40C4F026.9070302@ultraemail.net> <40C641EB.1060206@ultraemail.net>
Message-ID: <20040609002318.J24431@flint.arm.linux.org.uk>

On Tue, Jun 08, 2004 at 05:47:07PM -0500, Jens B. Jorgensen wrote:
> So after putting in all manner of printk() statements deeper and deeper 
> I discovered something interesting. I was using lxr to trace through the 
> source on the web and noticed that my fedora core 2 source for 
> rsrc_mgr.c didn't match that of the "stock" 2.6.5 code. In particular, I 
> noticed that the fedora core 2 code has

Keep on investigating please - the code should work as before - there
should be no functional change.  You're the first one to report a
change in behaviour, and this needs to be tracked down and resolved.

Could you prod about in pcmcia_align and pcmcia_common_align please?

Also, might be worth dumping out data.mask, data.offset, num and min
in find_io_region.

Thanks.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

From jbj1 at ultraemail.net  Wed Jun  9 14:09:56 2004
From: jbj1 at ultraemail.net (Jens B. Jorgensen)
Date: Wed Jun  9 14:10:09 2004
Subject: [fixed] orinoco_cs.c cannot get io ports (cs.c 1.271),
 can anyone help me understand why?
In-Reply-To: <20040609002318.J24431@flint.arm.linux.org.uk>
References: <40C4F026.9070302@ultraemail.net> <40C641EB.1060206@ultraemail.net>
	<20040609002318.J24431@flint.arm.linux.org.uk>
Message-ID: <40C75274.1030509@ultraemail.net>

Russell King wrote:

>On Tue, Jun 08, 2004 at 05:47:07PM -0500, Jens B. Jorgensen wrote:
>  
>
>>So after putting in all manner of printk() statements deeper and deeper 
>>I discovered something interesting. I was using lxr to trace through the 
>>source on the web and noticed that my fedora core 2 source for 
>>rsrc_mgr.c didn't match that of the "stock" 2.6.5 code. In particular, I 
>>noticed that the fedora core 2 code has
>>    
>>
>
>Keep on investigating please - the code should work as before - there
>should be no functional change.  You're the first one to report a
>change in behaviour, and this needs to be tracked down and resolved.
>
>Could you prod about in pcmcia_align and pcmcia_common_align please?
>
>Also, might be worth dumping out data.mask, data.offset, num and min
>in find_io_region.
>  
>
Ok, I will go back in and dig further. I did notice after I sent the 
last email that the card services code does actually go back and call 
some *_resource functions--seems it calls some lower-level ones than 
allocate_resource so I guess this /is/ something more subtle. I can't 
get to this today but I'll try to do it soon.

-- 
Jens B. Jorgensen
jbj1@ultraemail.net


From jar at pcuf.fi  Wed Jun  9 14:50:03 2004
From: jar at pcuf.fi (jar)
Date: Wed Jun  9 14:50:17 2004
Subject: 2.6.x kernels & PCI-to-PCMCIA bridges [again]
Message-ID: <40C75BDB.9000409@pcuf.fi>

Hello again

31.5.2004 Komuro did some changes according to Russell's suggestions and 
sent the driver source code again to the list.

Russell, how is the driver code looks like now? Do you will accept it?

What will be the fate of the driver, do we get the PD6729 based wlan 
cards and pc-card readers supported by the main kernel-2.6.x some d?y?

BR, Jar




From adamk at voicenet.com  Thu Jun 10 20:54:31 2004
From: adamk at voicenet.com (Adam K Kirchhoff)
Date: Thu Jun 10 20:54:40 2004
Subject: Unable to apply power.
Message-ID: <Pine.LNX.4.33L2.0406101449480.19824-100000@memory.visualtech.com>


	I've recently purchased an 802.11g card from NetGear which
theoretically works with the prism54 drivers.  However, I have been unable
to test this since I am consistently getting "PCMCIA: socket cee6282c:
unable to apply power."  errors when inserting the card.  Previously I
would get the error sporadically with various 802.11b cards, but *all* I
get with the "g" card is this error.  I've tried this with 2.4.3 and 2.4.6
(with 2.4.3, I get the error above, with 2.4.6, it complains about socket0
or socket1 instead of cee6282c).

	I actually found this mailing list after googling for this error
message and coming up with one or two posts to his list about the message.
In particular:

http://lists.infradead.org/pipermail/linux-pcmcia/2004-February/000514.html

	 Russel King asked the initial bug reporter if the error was
reproducable for him.  It was not, unfortunately.  I wanted to let you
know that, for me, it is 100% reproducable.  This is on a Sony VAIO
PCG-871L.  Please let me know if there's any other information you need
and if there's anything that can be done to fix this.

Adam Kirchhoff



From adamk at voicenet.com  Sun Jun 13 13:38:50 2004
From: adamk at voicenet.com (Adam K Kirchhoff)
Date: Sun Jun 13 13:39:10 2004
Subject: Unable to apply power.
In-Reply-To: <Pine.LNX.4.33L2.0406101449480.19824-100000@memory.visualtech.com>
References: <Pine.LNX.4.33L2.0406101449480.19824-100000@memory.visualtech.com>
Message-ID: <Pine.LNX.4.58.0406131338340.15860@thorn.ashke.com>


Anyone?  Am I better off asking on the linux-kernel mailing list?

On Thu, 10 Jun 2004, Adam K Kirchhoff wrote:

>
> 	I've recently purchased an 802.11g card from NetGear which
> theoretically works with the prism54 drivers.  However, I have been unable
> to test this since I am consistently getting "PCMCIA: socket cee6282c:
> unable to apply power."  errors when inserting the card.  Previously I
> would get the error sporadically with various 802.11b cards, but *all* I
> get with the "g" card is this error.  I've tried this with 2.4.3 and 2.4.6
> (with 2.4.3, I get the error above, with 2.4.6, it complains about socket0
> or socket1 instead of cee6282c).
>
> 	I actually found this mailing list after googling for this error
> message and coming up with one or two posts to his list about the message.
> In particular:
>
> http://lists.infradead.org/pipermail/linux-pcmcia/2004-February/000514.html
>
> 	 Russel King asked the initial bug reporter if the error was
> reproducable for him.  It was not, unfortunately.  I wanted to let you
> know that, for me, it is 100% reproducable.  This is on a Sony VAIO
> PCG-871L.  Please let me know if there's any other information you need
> and if there's anything that can be done to fix this.
>
> Adam Kirchhoff
>
>
>

From rmk+pcmcia at arm.linux.org.uk  Sun Jun 13 13:58:30 2004
From: rmk+pcmcia at arm.linux.org.uk (Russell King)
Date: Sun Jun 13 13:58:41 2004
Subject: Unable to apply power.
In-Reply-To: <Pine.LNX.4.33L2.0406101449480.19824-100000@memory.visualtech.com>;
	from adamk@voicenet.com on Thu, Jun 10, 2004 at 08:54:31PM -0400
References: <Pine.LNX.4.33L2.0406101449480.19824-100000@memory.visualtech.com>
Message-ID: <20040613185830.A29897@flint.arm.linux.org.uk>

On Thu, Jun 10, 2004 at 08:54:31PM -0400, Adam K Kirchhoff wrote:
> 	I've recently purchased an 802.11g card from NetGear which
> theoretically works with the prism54 drivers.  However, I have been unable
> to test this since I am consistently getting "PCMCIA: socket cee6282c:
> unable to apply power."  errors when inserting the card.  Previously I
> would get the error sporadically with various 802.11b cards, but *all* I
> get with the "g" card is this error.  I've tried this with 2.4.3 and 2.4.6
> (with 2.4.3, I get the error above, with 2.4.6, it complains about socket0
> or socket1 instead of cee6282c).

I assume that you mean 2.6 not 2.4 in each of these?

Could you grab the cbdump program from the PCMCIA site in my sig and
send its output both before and after you've inserted the card.  I
can't guarantee it'll give us something to go on, but it'll be start.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

From jar at pcuf.fi  Sun Jun 13 14:42:22 2004
From: jar at pcuf.fi (jar)
Date: Sun Jun 13 14:42:38 2004
Subject: 2.6.x kernels & PCI-to-PCMCIA bridges [again]
Message-ID: <40CCA00E.7070006@pcuf.fi>

Hello again

I'am sorry to disturbing you all, but I send this same question to the 
list couple of days ago but didn't get any answer.

31.5.2004 Komuro did some changes/fixes according to Russell's 
suggestions and sent the driver source code again to the list.

Russell, how is the driver code looks now? Do you will accept it?

What will be the fate of the driver, do we finally get the PD6729 based 
wlan cards and pc-card readers supported by the main kernel-2.6.x some day?

Best Regards, Jar

From adamk at voicenet.com  Sun Jun 13 15:06:38 2004
From: adamk at voicenet.com (Adam K Kirchhoff)
Date: Sun Jun 13 15:06:49 2004
Subject: Unable to apply power.
In-Reply-To: <20040613185830.A29897@flint.arm.linux.org.uk>
References: <Pine.LNX.4.33L2.0406101449480.19824-100000@memory.visualtech.com>
	<20040613185830.A29897@flint.arm.linux.org.uk>
Message-ID: <Pine.LNX.4.58.0406131506230.16356@thorn.ashke.com>




On Sun, 13 Jun 2004, Russell King wrote:

> On Thu, Jun 10, 2004 at 08:54:31PM -0400, Adam K Kirchhoff wrote:
> > 	I've recently purchased an 802.11g card from NetGear which
> > theoretically works with the prism54 drivers.  However, I have been unable
> > to test this since I am consistently getting "PCMCIA: socket cee6282c:
> > unable to apply power."  errors when inserting the card.  Previously I
> > would get the error sporadically with various 802.11b cards, but *all* I
> > get with the "g" card is this error.  I've tried this with 2.4.3 and 2.4.6
> > (with 2.4.3, I get the error above, with 2.4.6, it complains about socket0
> > or socket1 instead of cee6282c).
>
> I assume that you mean 2.6 not 2.4 in each of these?
>
> Could you grab the cbdump program from the PCMCIA site in my sig and
> send its output both before and after you've inserted the card.  I
> can't guarantee it'll give us something to go on, but it'll be start.

Attached :-)

Adam
-------------- next part --------------
02:05.0 CardBus bridge: Ricoh Co Ltd RL5c476 II
  -- generic cardbus config registers
  Vendor ID                      [00] : 0x1180
  Device ID                      [02] : 0x0476
  PCI command                    [04] : 0x0007
  Base address                   [10] : 0x10000000
  Memory Base 0                  [1c] : 0x10400000
  Memory Limit 0                 [20] : 0x107ff000
  Memory Base 1                  [24] : 0x10800000
  Memory Limit 1                 [28] : 0x10bff000
  IO Base 0                      [2c] : 0x00004000
  IO Limit 0                     [30] : 0x000040fc
  IO Base 1                      [34] : 0x00004400
  IO Limit 1                     [38] : 0x000044fc
  Bridge control                 [3e] : 0x0500
  Subsystem vendor ID            [40] : 0x104d
  Subsystem device ID            [42] : 0x80e7
  Legacy mode base               [44] : 0x0001
  -- cardbus registers
  CB_SOCKET_EVENT                [00] : 0x00000000
  CB_SOCKET_MASK                 [04] : 0x00000006
  CB_SOCKET_STATE                [08] : 0x30000826
  CB_SOCKET_FORCE                [0c] : 0x00000000
  CB_SOCKET_CONTROL              [10] : 0x00000400
  CB_SOCKET_POWER                [20] : 0x00000000
  -- exca registers
  I365_IDENT                     [00] : 0x83
  I365_STATUS                    [01] : 0x33
  I365_POWER                     [02] : 0x00
  I365_INTCTL                    [03] : 0x00
  I365_CSC                       [04] : 0x00
  I365_CSCINT                    [05] : 0x00
  I365_ADDRWIN                   [06] : 0x00
  I365_IOCTL                     [07] : 0x00
  I365_GENCTL                    [16] : 0x0000
  I365_GBLCTL                    [1e] : 0x0000
  I365_IO0_START                 [08] : 0x0000
  I365_IO0_STOP                  [0a] : 0x0001
  I365_IO1_START                 [0c] : 0x0000
  I365_IO1_STOP                  [0e] : 0x0001
  I365_MEM0_START                [10] : 0x0000
  I365_MEM0_STOP                 [12] : 0x0000
  I365_MEM0_OFF                  [14] : 0x0000
  I365_MEM0_PAGE                 [40] : 0x00
  I365_MEM1_START                [18] : 0x0000
  I365_MEM1_STOP                 [1a] : 0x0000
  I365_MEM1_OFF                  [1c] : 0x0000
  I365_MEM1_PAGE                 [41] : 0x00
  I365_MEM2_START                [20] : 0x0000
  I365_MEM2_STOP                 [22] : 0x0000
  I365_MEM2_OFF                  [24] : 0x0000
  I365_MEM2_PAGE                 [42] : 0x00
  I365_MEM3_START                [28] : 0x0000
  I365_MEM3_STOP                 [2a] : 0x0000
  I365_MEM3_OFF                  [2c] : 0x0000
  I365_MEM3_PAGE                 [43] : 0x00
  I365_MEM4_START                [30] : 0x0000
  I365_MEM4_STOP                 [32] : 0x0000
  I365_MEM4_OFF                  [34] : 0x0000
  I365_MEM4_PAGE                 [44] : 0x00

02:05.1 CardBus bridge: Ricoh Co Ltd RL5c476 II
  -- generic cardbus config registers
  Vendor ID                      [00] : 0x1180
  Device ID                      [02] : 0x0476
  PCI command                    [04] : 0x0007
  Base address                   [10] : 0x10001000
  Memory Base 0                  [1c] : 0x10c00000
  Memory Limit 0                 [20] : 0x10fff000
  Memory Base 1                  [24] : 0x11000000
  Memory Limit 1                 [28] : 0x113ff000
  IO Base 0                      [2c] : 0x00004800
  IO Limit 0                     [30] : 0x000048fc
  IO Base 1                      [34] : 0x00004c00
  IO Limit 1                     [38] : 0x00004cfc
  Bridge control                 [3e] : 0x0580
  Subsystem vendor ID            [40] : 0x104d
  Subsystem device ID            [42] : 0x80e7
  Legacy mode base               [44] : 0x0001
  -- cardbus registers
  CB_SOCKET_EVENT                [00] : 0x00000000
  CB_SOCKET_MASK                 [04] : 0x00000006
  CB_SOCKET_STATE                [08] : 0x30000006
  CB_SOCKET_FORCE                [0c] : 0x00000000
  CB_SOCKET_CONTROL              [10] : 0x00000400
  CB_SOCKET_POWER                [20] : 0x00000000
  -- exca registers
  I365_IDENT                     [00] : 0x83
  I365_STATUS                    [01] : 0x33
  I365_POWER                     [02] : 0x40
  I365_INTCTL                    [03] : 0x40
  I365_CSC                       [04] : 0x00
  I365_CSCINT                    [05] : 0x08
  I365_ADDRWIN                   [06] : 0x00
  I365_IOCTL                     [07] : 0x00
  I365_GENCTL                    [16] : 0x0000
  I365_GBLCTL                    [1e] : 0x0000
  I365_IO0_START                 [08] : 0x0000
  I365_IO0_STOP                  [0a] : 0x0001
  I365_IO1_START                 [0c] : 0x0000
  I365_IO1_STOP                  [0e] : 0x0001
  I365_MEM0_START                [10] : 0x0000
  I365_MEM0_STOP                 [12] : 0x0000
  I365_MEM0_OFF                  [14] : 0x0000
  I365_MEM0_PAGE                 [40] : 0x00
  I365_MEM1_START                [18] : 0x0000
  I365_MEM1_STOP                 [1a] : 0x0000
  I365_MEM1_OFF                  [1c] : 0x0000
  I365_MEM1_PAGE                 [41] : 0x00
  I365_MEM2_START                [20] : 0x0000
  I365_MEM2_STOP                 [22] : 0x0000
  I365_MEM2_OFF                  [24] : 0x0000
  I365_MEM2_PAGE                 [42] : 0x00
  I365_MEM3_START                [28] : 0x0000
  I365_MEM3_STOP                 [2a] : 0x0000
  I365_MEM3_OFF                  [2c] : 0x0000
  I365_MEM3_PAGE                 [43] : 0x00
  I365_MEM4_START                [30] : 0x0000
  I365_MEM4_STOP                 [32] : 0x0000
  I365_MEM4_OFF                  [34] : 0x0000
  I365_MEM4_PAGE                 [44] : 0x00

-------------- next part --------------
02:05.0 CardBus bridge: Ricoh Co Ltd RL5c476 II
  -- generic cardbus config registers
  Vendor ID                      [00] : 0x1180
  Device ID                      [02] : 0x0476
  PCI command                    [04] : 0x0007
  Base address                   [10] : 0x10000000
  Memory Base 0                  [1c] : 0x10400000
  Memory Limit 0                 [20] : 0x107ff000
  Memory Base 1                  [24] : 0x10800000
  Memory Limit 1                 [28] : 0x10bff000
  IO Base 0                      [2c] : 0x00004000
  IO Limit 0                     [30] : 0x000040fc
  IO Base 1                      [34] : 0x00004400
  IO Limit 1                     [38] : 0x000044fc
  Bridge control                 [3e] : 0x0500
  Subsystem vendor ID            [40] : 0x104d
  Subsystem device ID            [42] : 0x80e7
  Legacy mode base               [44] : 0x0001
  -- cardbus registers
  CB_SOCKET_EVENT                [00] : 0x00000000
  CB_SOCKET_MASK                 [04] : 0x00000006
  CB_SOCKET_STATE                [08] : 0x30000820
  CB_SOCKET_FORCE                [0c] : 0x00000000
  CB_SOCKET_CONTROL              [10] : 0x00000400
  CB_SOCKET_POWER                [20] : 0x00000000
  -- exca registers
  I365_IDENT                     [00] : 0x83
  I365_STATUS                    [01] : 0x3f
  I365_POWER                     [02] : 0x00
  I365_INTCTL                    [03] : 0x00
  I365_CSC                       [04] : 0x00
  I365_CSCINT                    [05] : 0x00
  I365_ADDRWIN                   [06] : 0x00
  I365_IOCTL                     [07] : 0x00
  I365_GENCTL                    [16] : 0x0000
  I365_GBLCTL                    [1e] : 0x0000
  I365_IO0_START                 [08] : 0x0000
  I365_IO0_STOP                  [0a] : 0x0001
  I365_IO1_START                 [0c] : 0x0000
  I365_IO1_STOP                  [0e] : 0x0001
  I365_MEM0_START                [10] : 0x0000
  I365_MEM0_STOP                 [12] : 0x0000
  I365_MEM0_OFF                  [14] : 0x0000
  I365_MEM0_PAGE                 [40] : 0x00
  I365_MEM1_START                [18] : 0x0000
  I365_MEM1_STOP                 [1a] : 0x0000
  I365_MEM1_OFF                  [1c] : 0x0000
  I365_MEM1_PAGE                 [41] : 0x00
  I365_MEM2_START                [20] : 0x0000
  I365_MEM2_STOP                 [22] : 0x0000
  I365_MEM2_OFF                  [24] : 0x0000
  I365_MEM2_PAGE                 [42] : 0x00
  I365_MEM3_START                [28] : 0x0000
  I365_MEM3_STOP                 [2a] : 0x0000
  I365_MEM3_OFF                  [2c] : 0x0000
  I365_MEM3_PAGE                 [43] : 0x00
  I365_MEM4_START                [30] : 0x0000
  I365_MEM4_STOP                 [32] : 0x0000
  I365_MEM4_OFF                  [34] : 0x0000
  I365_MEM4_PAGE                 [44] : 0x00

02:05.1 CardBus bridge: Ricoh Co Ltd RL5c476 II
  -- generic cardbus config registers
  Vendor ID                      [00] : 0x1180
  Device ID                      [02] : 0x0476
  PCI command                    [04] : 0x0007
  Base address                   [10] : 0x10001000
  Memory Base 0                  [1c] : 0x10c00000
  Memory Limit 0                 [20] : 0x10fff000
  Memory Base 1                  [24] : 0x11000000
  Memory Limit 1                 [28] : 0x113ff000
  IO Base 0                      [2c] : 0x00004800
  IO Limit 0                     [30] : 0x000048fc
  IO Base 1                      [34] : 0x00004c00
  IO Limit 1                     [38] : 0x00004cfc
  Bridge control                 [3e] : 0x0580
  Subsystem vendor ID            [40] : 0x104d
  Subsystem device ID            [42] : 0x80e7
  Legacy mode base               [44] : 0x0001
  -- cardbus registers
  CB_SOCKET_EVENT                [00] : 0x00000000
  CB_SOCKET_MASK                 [04] : 0x00000006
  CB_SOCKET_STATE                [08] : 0x30000006
  CB_SOCKET_FORCE                [0c] : 0x00000000
  CB_SOCKET_CONTROL              [10] : 0x00000400
  CB_SOCKET_POWER                [20] : 0x00000000
  -- exca registers
  I365_IDENT                     [00] : 0x83
  I365_STATUS                    [01] : 0x33
  I365_POWER                     [02] : 0x40
  I365_INTCTL                    [03] : 0x40
  I365_CSC                       [04] : 0x00
  I365_CSCINT                    [05] : 0x08
  I365_ADDRWIN                   [06] : 0x00
  I365_IOCTL                     [07] : 0x00
  I365_GENCTL                    [16] : 0x0000
  I365_GBLCTL                    [1e] : 0x0000
  I365_IO0_START                 [08] : 0x0000
  I365_IO0_STOP                  [0a] : 0x0001
  I365_IO1_START                 [0c] : 0x0000
  I365_IO1_STOP                  [0e] : 0x0001
  I365_MEM0_START                [10] : 0x0000
  I365_MEM0_STOP                 [12] : 0x0000
  I365_MEM0_OFF                  [14] : 0x0000
  I365_MEM0_PAGE                 [40] : 0x00
  I365_MEM1_START                [18] : 0x0000
  I365_MEM1_STOP                 [1a] : 0x0000
  I365_MEM1_OFF                  [1c] : 0x0000
  I365_MEM1_PAGE                 [41] : 0x00
  I365_MEM2_START                [20] : 0x0000
  I365_MEM2_STOP                 [22] : 0x0000
  I365_MEM2_OFF                  [24] : 0x0000
  I365_MEM2_PAGE                 [42] : 0x00
  I365_MEM3_START                [28] : 0x0000
  I365_MEM3_STOP                 [2a] : 0x0000
  I365_MEM3_OFF                  [2c] : 0x0000
  I365_MEM3_PAGE                 [43] : 0x00
  I365_MEM4_START                [30] : 0x0000
  I365_MEM4_STOP                 [32] : 0x0000
  I365_MEM4_OFF                  [34] : 0x0000
  I365_MEM4_PAGE                 [44] : 0x00

From lloyd at passcal.nmt.edu  Tue Jun 15 14:15:16 2004
From: lloyd at passcal.nmt.edu (Lloyd Carothers)
Date: Tue Jun 15 14:15:27 2004
Subject: (no subject)
Message-ID: <1087323316.1396.29.camel@firestorm.passcal.nmt.edu>

Hello all;
  I would like to know what the status is for pcmcia compact flash ide
memory drives with the 2.6 kernel. Here's a brief overview of my
experiences:

Most drives (Scandisk, Hitachi & IBM microdrives) seem to work fine with
the kernel provided drivers with 2.4.20 and on, However the SimpleTech
1GB drives (the only drives I need to support) can be seen by these
drivers but on access (fdisk, mount hdparm) I get repeated Drive Seek
errors ( more info on this can be provided but my main concern is for
2.6 use)... The only way I can access this SimpleTech Drives is using a
2.4.20 (22, 24 don't work) with the pcmcia-cs package (note: when I
install this package it says due to kernel configuration that only
util's not drivers will be installed)

now for 2.6
On a compaq armada M700 with 2.6.? I have yenta drivers built in and
when I put a card (microdrive or simpletech) cardctl status says it's
in, but I can't find the drive file to access. any suggestions I know my
info is sparse I can provide more if specifics are asked
thanks in advance
--LLoyd C.


From tam at diotec.com  Thu Jun 17 06:17:04 2004
From: tam at diotec.com (Timo Maier)
Date: Thu Jun 17 06:17:15 2004
Subject: DANGER unable to remove socket power
Message-ID: <40D16FA0.2040401@diotec.com>

Hi!

When I insert and remove mit Netgear WG511 WLAN card I get
PCMCIA: socket df65a02c: *** DANGER *** unable to remove socket power

Below is my dmesg output. Machine is a IBM ThinkPad T23.


Linux version 2.6.7 (root@tp) (gcc version 3.3.3 20040412 (Gentoo Linux 
3.3.3-r6, ssp-3.3.2-2, pie-8.7.6)) #1 Thu Jun 17 11:11:59 CEST 2004
BIOS-provided physical RAM map:
  BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
  BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
  BIOS-e820: 0000000000100000 - 000000001ff70000 (usable)
  BIOS-e820: 000000001ff70000 - 000000001ff7e000 (ACPI data)
  BIOS-e820: 000000001ff7e000 - 000000001ff80000 (ACPI NVS)
  BIOS-e820: 000000001ff80000 - 0000000020000000 (reserved)
  BIOS-e820: 00000000ff800000 - 0000000100000000 (reserved)
511MB LOWMEM available.
On node 0 totalpages: 130928
   DMA zone: 4096 pages, LIFO batch:1
   Normal zone: 126832 pages, LIFO batch:16
   HighMem zone: 0 pages, LIFO batch:1
DMI present.
IBM machine detected. Enabling interrupts during APM calls.
IBM machine detected. Disabling SMBus accesses.
ACPI: RSDP (v002 IBM                                       ) @ 0x000f7450
ACPI: XSDT (v001 IBM    TP-1A    0x00001170  LTP 0x00000000) @ 0x1ff73af9
ACPI: FADT (v001 IBM    TP-1A    0x00001170 IBM  0x00000001) @ 0x1ff73c00
ACPI: SSDT (v001 IBM    TP-1A    0x00001170 MSFT 0x0100000d) @ 0x1ff73cb4
ACPI: ECDT (v001 IBM    TP-1A    0x00001170 IBM  0x00000001) @ 0x1ff7deca
ACPI: BOOT (v001 IBM    TP-1A    0x00001170  LTP 0x00000001) @ 0x1ff7dfd8
ACPI: DSDT (v001 IBM    TP-1A    0x00001170 MSFT 0x0100000d) @ 0x00000000
Built 1 zonelists
Kernel command line: root=/dev/hda2 vga=0x33c video=vesafb:mtrr,ywrap
Initializing CPU#0
PID hash table entries: 2048 (order 11: 16384 bytes)
Detected 1199.115 MHz processor.
Using tsc for high-res timesource
Console: colour dummy device 80x25
Memory: 514904k/523712k available (2599k kernel code, 8040k reserved, 
932k data, 148k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 2375.68 BogoMIPS
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU:     After generic identify, caps: 0383f9ff 00000000 00000000 00000000
CPU:     After vendor identify, caps: 0383f9ff 00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
CPU:     After all inits, caps: 0383f9ff 00000000 00000000 00000040
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel(R) Pentium(R) III Mobile CPU      1200MHz stepping 01
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfd8fe, last bus=8
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
Linux Plug and Play Support v0.97 (c) Adam Belay
SCSI subsystem initialized
Linux Kernel Card Services
   options:  [pci] [cardbus] [pm]
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Transparent bridge - 0000:00:1e.0
PCI: Discovered primary peer bus 09 [IRQ]
PCI: Using IRQ router PIIX/ICH [8086/248c] at 0000:00:1f.0
PCI: IRQ 0 for device 0000:00:1f.1 doesn't match PIRQ mask - try 
pci=usepirqmask
PCI: Found IRQ 11 for device 0000:00:1f.1
PCI: Sharing IRQ 11 with 0000:00:1d.2
PCI: Sharing IRQ 11 with 0000:02:02.0
NET: Registered protocol family 23
vesafb: framebuffer at 0xe8000000, mapped to 0xe0800000, size 5742k
vesafb: mode is 1400x1050x16, linelength=2800, pages=4
vesafb: protected mode interface info at c000:9868
vesafb: pmi: set display start = c00c98ca, set palette = c00c9913
vesafb: scrolling: ywrap using protected mode interface, yres_virtual=2100
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
fb0: VESA VGA frame buffer device
Simple Boot Flag at 0x35 set to 0x1
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
devfs: 2004-01-31 Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
NTFS driver 2.1.14 [Flags: R/O].
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Console: switching to colour frame buffer device 175x65
lp: driver loaded but no devices found
Real Time Clock Driver v1.12
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected an Intel 830M Chipset.
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: AGP aperture is 256M @ 0xd0000000
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A
parport0: PC-style at 0x3bc (0x7bc) [PCSPP,TRISTATE]
parport0: irq 7 detected
lp0: using parport0 (polling).
eepro100.c:v1.09j-t 9/29/99 Donald Becker 
http://www.scyld.com/network/eepro100.html
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin 
<saw@saw.sw.com.sg> and others
PCI: Found IRQ 11 for device 0000:02:08.0
eth0: 0000:02:08.0, 00:D0:59:B5:3D:CB, IRQ 11.
   Board assembly 000000-000, Physical connectors present: RJ45
   Primary interface chip i82555 PHY #1.
   General self-test: passed.
   Serial sub-system self-test: passed.
   Internal registers self-test: passed.
   ROM checksum self-test: passed (0x04f4518b).
Loaded prism54 driver, version 1.1
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH3M: IDE controller at PCI slot 0000:00:1f.1
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
PCI: Found IRQ 11 for device 0000:00:1f.1
PCI: Sharing IRQ 11 with 0000:00:1d.2
PCI: Sharing IRQ 11 with 0000:02:02.0
ICH3M: chipset revision 2
ICH3M: not 100% native mode: will probe irqs later
     ide0: BM-DMA at 0x1860-0x1867, BIOS settings: hda:DMA, hdb:pio
     ide1: BM-DMA at 0x1868-0x186f, BIOS settings: hdc:DMA, hdd:pio
hda: IC25T060ATCS05-0, ATA DISK drive
Using anticipatory io scheduler
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: UJDA720 DVD/CDRW, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 117210240 sectors (60011 MB) w/1768KiB Cache, CHS=65535/16/63, 
UDMA(100)
  /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 p4
hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
USB Universal Host Controller Interface driver v2.2
PCI: Found IRQ 11 for device 0000:00:1d.0
PCI: Sharing IRQ 11 with 0000:01:00.0
PCI: Sharing IRQ 11 with 0000:02:00.0
uhci_hcd 0000:00:1d.0: Intel Corp. 82801CA/CAM USB (Hub #1)
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: irq 11, io base 00001800
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
PCI: Found IRQ 11 for device 0000:00:1d.1
uhci_hcd 0000:00:1d.1: Intel Corp. 82801CA/CAM USB (Hub #2)
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: irq 11, io base 00001820
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
PCI: Found IRQ 11 for device 0000:00:1d.2
PCI: Sharing IRQ 11 with 0000:00:1f.1
PCI: Sharing IRQ 11 with 0000:02:02.0
uhci_hcd 0000:00:1d.2: Intel Corp. 82801CA/CAM USB (Hub #3)
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: irq 11, io base 00001840
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
usbcore: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
mice: PS/2 mouse device common for all mice
serio: i8042 AUX port at 0x60,0x64 irq 12
input: PS/2 Generic Mouse on isa0060/serio1
serio: i8042 KBD port at 0x60,0x64 irq 1
input: AT Translated Set 2 keyboard on isa0060/serio0
Advanced Linux Sound Architecture Driver Version 1.0.4 (Mon May 17 
14:31:44 2004 UTC).
PCI: Enabling device 0000:00:1f.5 (0000 -> 0001)
PCI: Found IRQ 5 for device 0000:00:1f.5
PCI: Sharing IRQ 5 with 0000:00:1f.3
PCI: Sharing IRQ 5 with 0000:02:00.1
PCI: Setting latency timer of device 0000:00:1f.5 to 64
intel8x0_measure_ac97_clock: measured 49505 usecs
intel8x0: clocking to 48000
ALSA device list:
   #0: Intel 82801CA-ICH3 at 0x1c00, irq 5
NET: Registered protocol family 2
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 65536)
NET: Registered protocol family 1
NET: Registered protocol family 17
IrCOMM protocol (Dag Brattli)
ReiserFS: hda2: found reiserfs format "3.6" with standard journal
ReiserFS: hda2: using ordered data mode
ReiserFS: hda2: journal params: device hda2, size 8192, journal first 
block 18, max trans len 1024, max batch 900, max commit age 30, max 
trans age 30
ReiserFS: hda2: checking transaction log (hda2)
ReiserFS: hda2: Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 148k freed
Adding 551872k swap on /dev/hda4.  Priority:-1 extents:1
PCI: Found IRQ 11 for device 0000:02:00.0
PCI: Sharing IRQ 11 with 0000:00:1d.0
PCI: Sharing IRQ 11 with 0000:01:00.0
Yenta: CardBus bridge found at 0000:02:00.0 [1014:023b]
Yenta: Using INTVAL to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:02:00.0, mfunc 0x01d21022, devctl 0x64
Yenta: ISA IRQ mask 0x06d8, PCI irq 11
Socket status: 30000006
PCI: Found IRQ 5 for device 0000:02:00.1
PCI: Sharing IRQ 5 with 0000:00:1f.3
PCI: Sharing IRQ 5 with 0000:00:1f.5
Yenta: CardBus bridge found at 0000:02:00.1 [1014:023b]
Yenta: Using INTVAL to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:02:00.1, mfunc 0x01d21022, devctl 0x64
Yenta: ISA IRQ mask 0x06d8, PCI irq 5
Socket status: 30000006
NTFS volume version 3.1.
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0800-0x08ff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
hda: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }

hda: set_drive_speed_status: status=0x58 { DriveReady SeekComplete 
DataRequest }
hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
hda: task_no_data_intr: error=0x04 { DriveStatusError }
PCI: Enabling device 0000:03:00.0 (0000 -> 0002)
eth1: prism54 driver detected card model: Netgear WG511
Assuming someone else called the IRQ
Assuming someone else called the IRQ
eth1: hot unplug detected
eth1: removing device
PCMCIA: socket df65a02c: *** DANGER *** unable to remove socket power


From adamk at voicenet.com  Fri Jun 18 11:59:04 2004
From: adamk at voicenet.com (Adam K Kirchhoff)
Date: Fri Jun 18 11:58:30 2004
Subject: Unable to apply power.
In-Reply-To: <Pine.LNX.4.58.0406131506230.16356@thorn.ashke.com>
References: <Pine.LNX.4.33L2.0406101449480.19824-100000@memory.visualtech.com>
	<20040613185830.A29897@flint.arm.linux.org.uk>
	<Pine.LNX.4.58.0406131506230.16356@thorn.ashke.com>
Message-ID: <40D31148.1020909@voicenet.com>

Adam K Kirchhoff wrote:

>
>On Sun, 13 Jun 2004, Russell King wrote:
>
>  
>
>>On Thu, Jun 10, 2004 at 08:54:31PM -0400, Adam K Kirchhoff wrote:
>>    
>>
>>>	I've recently purchased an 802.11g card from NetGear which
>>>theoretically works with the prism54 drivers.  However, I have been unable
>>>to test this since I am consistently getting "PCMCIA: socket cee6282c:
>>>unable to apply power."  errors when inserting the card.  Previously I
>>>would get the error sporadically with various 802.11b cards, but *all* I
>>>get with the "g" card is this error.  I've tried this with 2.4.3 and 2.4.6
>>>(with 2.4.3, I get the error above, with 2.4.6, it complains about socket0
>>>or socket1 instead of cee6282c).
>>>      
>>>
>>I assume that you mean 2.6 not 2.4 in each of these?
>>
>>Could you grab the cbdump program from the PCMCIA site in my sig and
>>send its output both before and after you've inserted the card.  I
>>can't guarantee it'll give us something to go on, but it'll be start.
>>    
>>
>
>Attached :-)
>
>Adam
>  
>

Russel,

    Were you able to use this to identify the problem?

    As a test, I tried the card in an old Toshiba Libretto 100CT running 
2.4.26...  The pcmcia package definitely sees the card... "cardctl 
ident" identifies it as an Intersil ISL3890.  But even that machine 
compains a little:

PCI: Enabling device 15:00.0 (0000 -> 0002)
PCI: No IRQ known for interrupt pin A of device 15:00.0.  Please try 
using pci=biosirq.

    So I guess I'm not gonna try pci=bioirq.  Please let me know if 
you've been able to identify the problem with the 2.6.* kernels (I don't 
care if I get it working on the Libretto) or if there's anything else I 
can do to help.

Adam


From rmk+pcmcia at arm.linux.org.uk  Fri Jun 18 12:17:28 2004
From: rmk+pcmcia at arm.linux.org.uk (Russell King)
Date: Fri Jun 18 12:17:39 2004
Subject: Unable to apply power.
In-Reply-To: <40D31148.1020909@voicenet.com>;
	from adamk@voicenet.com on Fri, Jun 18, 2004 at 11:59:04AM -0400
References: <Pine.LNX.4.33L2.0406101449480.19824-100000@memory.visualtech.com>
	<20040613185830.A29897@flint.arm.linux.org.uk>
	<Pine.LNX.4.58.0406131506230.16356@thorn.ashke.com>
	<40D31148.1020909@voicenet.com>
Message-ID: <20040618171728.D7138@flint.arm.linux.org.uk>

On Fri, Jun 18, 2004 at 11:59:04AM -0400, Adam K Kirchhoff wrote:
>     Were you able to use this to identify the problem?

Not really - the only difference between the two shows that a card was
inserted.  No sign of any other changes.

Could you try applying this patch and reporting the extra kernel messages
please?  It may also be a good idea to add:

EXTRA_CFLAGS := -DDEBUG

into drivers/pcmcia/Makefile and pass "pcmcia_core.pc_debug=5" to the
kernel at boot (if you've built pcmcia into the kernel) or pc_debug=5
when pcmcia_core is inserted (if as a module.)

Thanks.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

From jar at pcuf.fi  Fri Jun 18 16:42:03 2004
From: jar at pcuf.fi (jar)
Date: Fri Jun 18 16:42:14 2004
Subject: 2.6.x kernels & PCI-to-PCMCIA bridges [again]
Message-ID: <40D3539B.6040900@pcuf.fi>


Hello

I don't want to spam, but I am tried several times to get
information about the status of the PD6729 driver?

Russell, do you had to have time to check the corrected
source code yet?

Regards, Jar

From rmk+pcmcia at arm.linux.org.uk  Fri Jun 18 18:04:56 2004
From: rmk+pcmcia at arm.linux.org.uk (Russell King)
Date: Fri Jun 18 18:05:11 2004
Subject: compaq r3000z notebook pcmcia
In-Reply-To: <20040531061824.GA26934@section-1.net>;
	from linux-pcmcia@section-1.net on Mon, May 31, 2004 at
	12:18:24AM -0600
References: <mailman.8.1085480033.5287.linux-pcmcia@lists.infradead.org>
	<Pine.LNX.4.53.0405252025230.14428@garu.i2pi.com>
	<Pine.LNX.4.60.0405251157330.2635@marabou.research.att.com>
	<20040526043931.GA14450@section-1.net>
	<20040526060530.GA11428@sonic.net>
	<20040531061824.GA26934@section-1.net>
Message-ID: <20040618230456.F17516@flint.arm.linux.org.uk>

On Mon, May 31, 2004 at 12:18:24AM -0600, Max wrote:
> On Tue, May 25, 2004 at 11:05:30PM -0700, David Hinds wrote:
> > > 
> > > cs: memory probe 0xe1000000-0xe13ff000: excluding 0xe1000000-0xe141dfff
> > 
> > The memory ranges listed for the CardBus bridge in 'lspci -v' are
> > *unavailable* for use by 16-bit cards with the 2.6 drivers.  The
> > pcmcia-cs drivers behave differently here: they free the CardBus
> > bridge windows at startup time.
> > 
> > With 2.6 I would try similar windows like 0xe0000000-0xe0ffffff,
> > 0xe2000000-0xe2ffffff, etc.  The ranges need to fit within the memory
> > windows of the PCI-to-PCI bridge with secondary bus = 2 on your
> > system.  You may also need to replace the IO port windows with
> > something like 0x4000-0x4fff.
> > 
> > -- Dave
> 
> Thanks Dave, this certainly pointed me in the right direction and my
> 16bit card now works, however my Cardbus cards still are not working.
> When I insert a card absolutely nothing happens. When I remove the card
> it get the message:
> 
> PCMCIA: socket ccabb82c: *** DANGER *** unable to remove socket power

When people get this, can they please grab a copy of 'cbdump.c' build
it and provide the output in addition to the above message.  It'll let
us see what state the cardbus bridge is in after you've removed the
card.

Where you getting this before you changed the memory/io windows?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

From rmk+pcmcia at arm.linux.org.uk  Fri Jun 18 18:11:47 2004
From: rmk+pcmcia at arm.linux.org.uk (Russell King)
Date: Fri Jun 18 18:12:07 2004
Subject: 2.6.x kernels & PCI-to-PCMCIA bridges [again]
In-Reply-To: <40D3539B.6040900@pcuf.fi>;
	from jar@pcuf.fi on Fri, Jun 18, 2004 at 11:42:03PM +0300
References: <40D3539B.6040900@pcuf.fi>
Message-ID: <20040618231147.G17516@flint.arm.linux.org.uk>

On Fri, Jun 18, 2004 at 11:42:03PM +0300, jar wrote:
> 
> Hello
> 
> I don't want to spam, but I am tried several times to get
> information about the status of the PD6729 driver?
> 
> Russell, do you had to have time to check the corrected
> source code yet?

I did, and I've been over it a few times last week end, but then got
distracted, sorry.

Essentially, I've:
- corrected the formatting
- removed extraneous white space
- removed useless "card_state" variable (it was only ever set to 1 and
  3, and only ever tested to be 0. IOW, the test could never be true.)

It would probably be a good idea if someone could confirm that it
hasn't broken as a result of this before I finally through it to
Linus.

diff -ruN linux/drivers/pcmcia.orig/Kconfig linux/drivers/pcmcia/Kconfig
--- linux/drivers/pcmcia.orig/Kconfig	2004-05-10 11:33:05.000000000 +0900
+++ linux/drivers/pcmcia/Kconfig	2004-05-31 21:07:06.000000000 +0900
@@ -69,6 +69,13 @@
 	depends on YENTA
 	default y if YENTA
 
+config PD6729
+	tristate "Cirrus PD6729 compatible bridge support"
+	depends on PCMCIA && PCI
+	help
+	  This provides support for the Cirrus PD6729 PCI-to-PCMCIA bridge
+	  device, found in some older laptops and PCMCIA card readers.
+
 config I82092
 	tristate "i82092 compatible bridge support"
 	depends on PCMCIA && PCI
diff -ruN linux/drivers/pcmcia.orig/Makefile linux/drivers/pcmcia/Makefile
--- linux/drivers/pcmcia.orig/Makefile	2004-05-10 11:33:12.000000000 +0900
+++ linux/drivers/pcmcia/Makefile	2004-05-31 21:07:06.000000000 +0900
@@ -9,6 +9,7 @@
 obj-$(CONFIG_PCMCIA)				+= pcmcia_core.o ds.o
 obj-$(CONFIG_YENTA) 				+= yenta_socket.o
 
+obj-$(CONFIG_PD6729)				+= pd6729.o
 obj-$(CONFIG_I82365)				+= i82365.o
 obj-$(CONFIG_I82092)				+= i82092.o
 obj-$(CONFIG_TCIC)				+= tcic.o
diff -ruN linux/drivers/pcmcia.orig/pd6729.c linux/drivers/pcmcia/pd6729.c
--- linux/drivers/pcmcia.orig/pd6729.c	1970-01-01 09:00:00.000000000 +0900
+++ linux/drivers/pcmcia/pd6729.c	2004-05-31 21:28:59.000000000 +0900
@@ -0,0 +1,765 @@
+/*
+ * Driver for the Cirrus PD6729 PCI-PCMCIA bridge.
+ *
+ * Based on the i82092.c driver.
+ *
+ * This software may be used and distributed according to the terms of
+ * the GNU General Public License, incorporated herein by reference.
+ */
+
+#include <linux/kernel.h>
+#include <linux/config.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/init.h>
+#include <linux/workqueue.h>
+#include <linux/interrupt.h>
+#include <linux/device.h>
+
+#include <pcmcia/cs_types.h>
+#include <pcmcia/ss.h>
+#include <pcmcia/cs.h>
+
+#include <asm/system.h>
+#include <asm/io.h>
+
+#include "pd6729.h"
+#include "i82365.h"
+#include "cirrus.h"
+
+MODULE_LICENSE("GPL");
+
+#define MAX_SOCKETS 2
+
+/* simple helper functions */
+/* External clock time, in nanoseconds.  120 ns = 8.33 MHz */
+#define to_cycles(ns)	((ns)/120)
+
+static spinlock_t port_lock = SPIN_LOCK_UNLOCKED;
+
+/* basic value read/write functions */
+
+static unsigned char indirect_read(struct pd6729_socket *socket, unsigned short reg)
+{
+	unsigned long port;
+	unsigned char val;
+	unsigned long flags;
+
+	spin_lock_irqsave(&port_lock, flags);
+	reg += socket->number * 0x40;
+	port = socket->io_base;
+	outb(reg, port);
+	val = inb(port + 1);
+	spin_unlock_irqrestore(&port_lock, flags);
+
+	return val;
+}
+
+static unsigned short indirect_read16(struct pd6729_socket *socket, unsigned short reg)
+{
+	unsigned long port;
+	unsigned short tmp;
+	unsigned long flags;
+
+	spin_lock_irqsave(&port_lock, flags);
+	reg  = reg + socket->number * 0x40;
+	port = socket->io_base;
+	outb(reg, port);
+	tmp = inb(port + 1);
+	reg++;
+	outb(reg, port);
+	tmp = tmp | (inb(port + 1) << 8);
+	spin_unlock_irqrestore(&port_lock, flags);
+
+	return tmp;
+}
+
+static void indirect_write(struct pd6729_socket *socket, unsigned short reg, unsigned char value)
+{
+	unsigned long port;
+	unsigned long flags;
+
+	spin_lock_irqsave(&port_lock, flags);
+	reg = reg + socket->number * 0x40;
+	port = socket->io_base;
+	outb(reg, port);
+	outb(value, port + 1);
+	spin_unlock_irqrestore(&port_lock, flags);
+}
+
+static void indirect_setbit(struct pd6729_socket *socket, unsigned short reg, unsigned char mask)
+{
+	unsigned long port;
+	unsigned char val;
+	unsigned long flags;
+
+	spin_lock_irqsave(&port_lock, flags);
+	reg = reg + socket->number * 0x40;
+	port = socket->io_base;
+	outb(reg, port);
+	val = inb(port + 1);
+	val |= mask;
+	outb(reg, port);
+	outb(val, port + 1);
+	spin_unlock_irqrestore(&port_lock, flags);
+}
+
+static void indirect_resetbit(struct pd6729_socket *socket, unsigned short reg, unsigned char mask)
+{
+	unsigned long port;
+	unsigned char val;
+	unsigned long flags;
+
+	spin_lock_irqsave(&port_lock, flags);
+	reg = reg + socket->number * 0x40;
+	port = socket->io_base;
+	outb(reg, port);
+	val = inb(port + 1);
+	val &= ~mask;
+	outb(reg, port);
+	outb(val, port + 1);
+	spin_unlock_irqrestore(&port_lock, flags);
+}
+
+static void indirect_write16(struct pd6729_socket *socket, unsigned short reg, unsigned short value)
+{
+	unsigned long port;
+	unsigned char val;
+	unsigned long flags;
+
+	spin_lock_irqsave(&port_lock, flags);
+	reg = reg + socket->number * 0x40;
+	port = socket->io_base;
+
+	outb(reg, port);
+	val = value & 255;
+	outb(val, port + 1);
+
+	reg++;
+
+	outb(reg, port);
+	val = value >> 8;
+	outb(val, port + 1);
+	spin_unlock_irqrestore(&port_lock, flags);
+}
+
+/* Interrupt handler functionality */
+
+static irqreturn_t pd6729_interrupt(int irq, void *dev, struct pt_regs *regs)
+{
+	struct pd6729_socket **socket = (struct pd6729_socket **) dev;
+	int i;
+	int loopcount = 0;
+	int handled = 0;
+	unsigned int events, active = 0;
+
+	while (1) {
+		loopcount++;
+		if (loopcount > 20) {
+			printk(KERN_ERR "pd6729: infinite eventloop in interrupt\n");
+			break;
+		}
+
+		active = 0;
+
+		for (i = 0; i < MAX_SOCKETS; i++) {
+			unsigned int csc;
+
+			/* card status change register */
+			csc = indirect_read(socket[i], I365_CSC);
+			if (csc == 0)  /* no events on this socket */
+				continue;
+
+			handled = 1;
+			events = 0;
+
+			if (csc & I365_CSC_DETECT) {
+				events |= SS_DETECT;
+				dprintk("Card detected in socket %i!\n", i);
+			}
+
+			if (indirect_read(socket[i], I365_INTCTL) & I365_PC_IOCARD) {
+				/* For IO/CARDS, bit 0 means "read the card" */
+				events |= (csc & I365_CSC_STSCHG) ? SS_STSCHG : 0;
+			} else {
+				/* Check for battery/ready events */
+				events |= (csc & I365_CSC_BVD1) ? SS_BATDEAD : 0;
+				events |= (csc & I365_CSC_BVD2) ? SS_BATWARN : 0;
+				events |= (csc & I365_CSC_READY) ? SS_READY : 0;
+			}
+
+			if (events) {
+				pcmcia_parse_events(&socket[i]->socket, events);
+			}
+			active |= events;
+		}
+
+		if (active == 0) /* no more events to handle */
+			break;
+	}
+	return IRQ_RETVAL(handled);
+}
+
+/* socket functions */
+
+static int card_present(struct pd6729_socket *socket)
+{
+	unsigned int val;
+
+	val = indirect_read(socket, 1); /* Interface status register */
+	if ((val&12) == 12) {
+		dprintk("card_present 1");
+		return 1;
+	}
+
+	dprintk("card_present 0");
+	return 0;
+}
+
+static void set_bridge_state(struct pd6729_socket *socket)
+{
+	indirect_write(socket, I365_GBLCTL, 0x00);
+	indirect_write(socket, I365_GENCTL, 0x00);
+
+	indirect_setbit(socket, I365_INTCTL, 0x08);
+}
+
+static int pd6729_get_status(struct pcmcia_socket *sock, u_int *value)
+{
+	struct pd6729_socket *socket = container_of(sock, struct pd6729_socket, socket);
+	unsigned int status;
+	unsigned int data;
+	struct pd6729_socket *t;
+
+	/* Interface Status Register */
+	status = indirect_read(socket, I365_STATUS);
+	*value = 0;
+
+	if ((status & I365_CS_DETECT) == I365_CS_DETECT) {
+		*value |= SS_DETECT;
+	}
+
+	/* IO cards have a different meaning of bits 0,1 */
+	/* Also notice the inverse-logic on the bits */
+	if (indirect_read(socket, I365_INTCTL) & I365_PC_IOCARD) {
+		/* IO card */
+		if (!(status & I365_CS_STSCHG))
+			*value |= SS_STSCHG;
+	} else {
+		/* non I/O card */
+		if (!(status & I365_CS_BVD1))
+			*value |= SS_BATDEAD;
+		if (!(status & I365_CS_BVD2))
+			*value |= SS_BATWARN;
+	}
+
+	if (status & I365_CS_WRPROT)
+		*value |= SS_WRPROT;	/* card is write protected */
+
+	if (status & I365_CS_READY)
+		*value |= SS_READY;	/* card is not busy */
+
+	if (status & I365_CS_POWERON)
+		*value |= SS_POWERON;	/* power is applied to the card */
+
+	t = (socket->number) ? socket : socket + 1;
+	indirect_write(t, PD67_EXT_INDEX, PD67_EXTERN_DATA);
+	data = indirect_read16(t, PD67_EXT_DATA);
+	*value |= (data & PD67_EXD_VS1(socket->number)) ? 0 : SS_3VCARD;
+
+	return 0;
+}
+
+
+static int pd6729_get_socket(struct pcmcia_socket *sock, socket_state_t *state)
+{
+	struct pd6729_socket *socket = container_of(sock, struct pd6729_socket, socket);
+	unsigned char reg, vcc, vpp;
+
+	state->flags    = 0;
+	state->Vcc      = 0;
+	state->Vpp      = 0;
+	state->io_irq   = 0;
+	state->csc_mask = 0;
+
+	/* First the power status of the socket */
+	/* PCTRL - Power Control Register */
+	reg = indirect_read(socket, I365_POWER);
+
+	if (reg & I365_PWR_AUTO)
+		state->flags |= SS_PWR_AUTO;  /* Automatic Power Switch */
+
+	if (reg & I365_PWR_OUT)
+		state->flags |= SS_OUTPUT_ENA; /* Output signals are enabled */
+
+	vcc = reg & I365_VCC_MASK;    vpp = reg & I365_VPP1_MASK;
+
+	if (reg & I365_VCC_5V) {
+		state->Vcc = (indirect_read(socket, PD67_MISC_CTL_1) &
+			PD67_MC1_VCC_3V) ? 33 : 50;
+
+		if (vpp == I365_VPP1_5V) {
+			if (state->Vcc == 50)
+				state->Vpp = 50;
+			else
+				state->Vpp = 33;
+		}
+		if (vpp == I365_VPP1_12V)
+			state->Vpp = 120;
+	}
+
+	/* Now the IO card, RESET flags and IO interrupt */
+	/* IGENC, Interrupt and General Control */
+	reg = indirect_read(socket, I365_INTCTL);
+
+	if ((reg & I365_PC_RESET) == 0)
+		state->flags |= SS_RESET;
+	if (reg & I365_PC_IOCARD)
+		state->flags |= SS_IOCARD; /* This is an IO card */
+
+	/* Set the IRQ number */
+	if (socket->dev != NULL)
+		state->io_irq = socket->socket.pci_irq;
+
+	/* Card status change */
+	/* CSCICR, Card Status Change Interrupt Configuration */
+	reg = indirect_read(socket, I365_CSCINT);
+
+	if (reg & I365_CSC_DETECT)
+		state->csc_mask |= SS_DETECT; /* Card detect is enabled */
+
+	if (state->flags & SS_IOCARD) {/* IO Cards behave different */
+		if (reg & I365_CSC_STSCHG)
+			state->csc_mask |= SS_STSCHG;
+	} else {
+		if (reg & I365_CSC_BVD1)
+			state->csc_mask |= SS_BATDEAD;
+		if (reg & I365_CSC_BVD2)
+			state->csc_mask |= SS_BATWARN;
+		if (reg & I365_CSC_READY)
+			state->csc_mask |= SS_READY;
+	}
+
+	return 0;
+}
+
+static int pd6729_set_socket(struct pcmcia_socket *sock, socket_state_t *state)
+{
+	struct pd6729_socket *socket = container_of(sock, struct pd6729_socket, socket);
+	unsigned char reg;
+
+	/* First, set the global controller options */
+
+	set_bridge_state(socket);
+
+	/* Values for the IGENC register */
+
+	reg = 0;
+ 	/* The reset bit has "inverse" logic */
+	if (!(state->flags & SS_RESET))
+		reg = reg | I365_PC_RESET;
+	if (state->flags & SS_IOCARD)
+		reg = reg | I365_PC_IOCARD;
+
+	/* IGENC, Interrupt and General Control Register */
+	indirect_write(socket, I365_INTCTL, reg);
+
+	/* Power registers */
+
+	reg = I365_PWR_NORESET; /* default: disable resetdrv on resume */
+
+	if (state->flags & SS_PWR_AUTO) {
+		dprintk("Auto power\n");
+		reg |= I365_PWR_AUTO;	/* automatic power mngmnt */
+	}
+	if (state->flags & SS_OUTPUT_ENA) {
+		dprintk("Power Enabled\n");
+		reg |= I365_PWR_OUT;	/* enable power */
+	}
+
+	switch (state->Vcc) {
+	case 0:
+		break;
+	case 33:
+		dprintk("setting voltage to Vcc to 3.3V on socket %i\n",
+			socket->number);
+		reg |= I365_VCC_5V;
+		indirect_setbit(socket, PD67_MISC_CTL_1, PD67_MC1_VCC_3V);
+		break;
+	case 50:
+		dprintk("setting voltage to Vcc to 5V on socket %i\n",
+			socket->number);
+		reg |= I365_VCC_5V;
+		indirect_resetbit(socket, PD67_MISC_CTL_1, PD67_MC1_VCC_3V);
+		break;
+	default:
+		dprintk("pd6729: pd6729_set_socket called with invalid VCC power value: %i\n",
+			state->Vcc);
+		return -EINVAL;
+	}
+
+	switch (state->Vpp) {
+	case 0:
+		dprintk("not setting Vpp on socket %i\n", socket->number);
+		break;
+	case 33:
+	case 50:
+		dprintk("setting Vpp to Vcc for socket %i\n", socket->number);
+		reg |= I365_VPP1_5V;
+		break;
+	case 120:
+		dprintk("setting Vpp to 12.0\n");
+		reg |= I365_VPP1_12V;
+		break;
+	default:
+		dprintk("pd6729: pd6729_set_socket called with invalid VPP power value: %i\n",
+			state->Vpp);
+		return -EINVAL;
+	}
+
+	/* only write if changed */
+	if (reg != indirect_read(socket, I365_POWER))
+		indirect_write(socket, I365_POWER, reg);
+
+	/* Now, specifiy that all interrupts are to be done as PCI interrupts */
+	indirect_write(socket, PD67_EXT_INDEX, PD67_EXT_CTL_1);
+	indirect_write(socket, PD67_EXT_DATA, PD67_EC1_INV_MGMT_IRQ | PD67_EC1_INV_CARD_IRQ);
+
+	/* Enable specific interrupt events */
+
+	reg = 0x00;
+	if (state->csc_mask & SS_DETECT) {
+		reg |= I365_CSC_DETECT;
+	}
+	if (state->flags & SS_IOCARD) {
+		if (state->csc_mask & SS_STSCHG)
+			reg |= I365_CSC_STSCHG;
+	} else {
+		if (state->csc_mask & SS_BATDEAD)
+			reg |= I365_CSC_BVD1;
+		if (state->csc_mask & SS_BATWARN)
+			reg |= I365_CSC_BVD2;
+		if (state->csc_mask & SS_READY)
+			reg |= I365_CSC_READY;
+	}
+	reg |= 0x30;	/* management IRQ: PCI INTA# = "irq 3" */
+	indirect_write(socket, I365_CSCINT, reg);
+
+	reg = indirect_read(socket, I365_INTCTL);
+	reg |= 0x03;	/* card IRQ: PCI INTA# = "irq 3" */
+	indirect_write(socket, I365_INTCTL, reg);
+
+	/* now clear the (probably bogus) pending stuff by doing a dummy read */
+	(void)indirect_read(socket, I365_CSC);
+
+	return 0;
+}
+
+static int pd6729_set_io_map(struct pcmcia_socket *sock, struct pccard_io_map *io)
+{
+	struct pd6729_socket *socket = container_of(sock, struct pd6729_socket, socket);
+	unsigned char map, ioctl;
+
+	map = io->map;
+
+	/* Check error conditions */
+	if (map > 1) {
+		dprintk("pd6729_set_io_map with invalid map");
+		return -EINVAL;
+	}
+
+	/* Turn off the window before changing anything */
+	if (indirect_read(socket, I365_ADDRWIN) & I365_ENA_IO(map))
+		indirect_resetbit(socket, I365_ADDRWIN, I365_ENA_IO(map));
+
+/*	dprintk("set_io_map: Setting range to %x - %x\n", io->start, io->stop);*/
+
+	/* write the new values */
+	indirect_write16(socket, I365_IO(map)+I365_W_START, io->start);
+	indirect_write16(socket, I365_IO(map)+I365_W_STOP, io->stop);
+
+	ioctl = indirect_read(socket, I365_IOCTL) & ~I365_IOCTL_MASK(map);
+
+	if (io->flags & MAP_0WS) ioctl |= I365_IOCTL_0WS(map);
+	if (io->flags & MAP_16BIT) ioctl |= I365_IOCTL_16BIT(map);
+	if (io->flags & MAP_AUTOSZ) ioctl |= I365_IOCTL_IOCS16(map);
+
+	indirect_write(socket, I365_IOCTL, ioctl);
+
+	/* Turn the window back on if needed */
+	if (io->flags & MAP_ACTIVE)
+		indirect_setbit(socket, I365_ADDRWIN, I365_ENA_IO(map));
+
+	return 0;
+}
+
+static int pd6729_set_mem_map(struct pcmcia_socket *sock, struct pccard_mem_map *mem)
+{
+	struct pd6729_socket *socket = container_of(sock, struct pd6729_socket, socket);
+	unsigned short base, i;
+	unsigned char map;
+
+	map = mem->map;
+	if (map > 4) {
+		printk("pd6729_set_mem_map: invalid map");
+		return -EINVAL;
+	}
+
+	if ((mem->sys_start > mem->sys_stop) || (mem->speed > 1000)) {
+		printk("pd6729_set_mem_map: invalid address / speed");
+		/* printk("invalid mem map for socket %i : %lx to %lx with a start of %x\n",
+			 sock, mem->sys_start, mem->sys_stop, mem->card_start); */
+		return -EINVAL;
+	}
+
+	/* Turn off the window before changing anything */
+	if (indirect_read(socket, I365_ADDRWIN) & I365_ENA_MEM(map))
+		indirect_resetbit(socket, I365_ADDRWIN, I365_ENA_MEM(map));
+
+	/* write the start address */
+	base = I365_MEM(map);
+	i = (mem->sys_start >> 12) & 0x0fff;
+	if (mem->flags & MAP_16BIT)
+		i |= I365_MEM_16BIT;
+	if (mem->flags & MAP_0WS)
+		i |= I365_MEM_0WS;
+	indirect_write16(socket, base + I365_W_START, i);
+
+	/* write the stop address */
+
+	i= (mem->sys_stop >> 12) & 0x0fff;
+	switch (to_cycles(mem->speed)) {
+	case 0:
+		break;
+	case 1:
+		i |= I365_MEM_WS0;
+		break;
+	case 2:
+		i |= I365_MEM_WS1;
+		break;
+	default:
+		i |= I365_MEM_WS1 | I365_MEM_WS0;
+		break;
+	}
+
+	indirect_write16(socket, base + I365_W_STOP, i);
+
+	/* Take care of high byte */
+	indirect_write(socket, PD67_EXT_INDEX, PD67_MEM_PAGE(map));
+	indirect_write(socket, PD67_EXT_DATA, mem->sys_start >> 24);
+
+	/* card start */
+
+	i = ((mem->card_start - mem->sys_start) >> 12) & 0x3fff;
+	if (mem->flags & MAP_WRPROT)
+		i |= I365_MEM_WRPROT;
+	if (mem->flags & MAP_ATTRIB) {
+/*		dprintk("requesting attribute memory for socket %i\n",
+			socket->number);*/
+		i |= I365_MEM_REG;
+	} else {
+/*		dprintk("requesting normal memory for socket %i\n",
+			socket->number);*/
+	}
+	indirect_write16(socket, base + I365_W_OFF, i);
+
+	/* Enable the window if necessary */
+	if (mem->flags & MAP_ACTIVE)
+		indirect_setbit(socket, I365_ADDRWIN, I365_ENA_MEM(map));
+
+	return 0;
+}
+
+static int pd6729_suspend(struct pcmcia_socket *sock)
+{
+	return pd6729_set_socket(sock, &dead_socket);
+}
+
+static int pd6729_init(struct pcmcia_socket *sock)
+{
+	int i;
+	pccard_io_map io = { 0, 0, 0, 0, 1 };
+	pccard_mem_map mem = { 0, 0, 0, 0, 0, 0 };
+
+	mem.sys_stop = 0x0fff;
+	pd6729_set_socket(sock, &dead_socket);
+	for (i = 0; i < 2; i++) {
+		io.map = i;
+		pd6729_set_io_map(sock, &io);
+	}
+	for (i = 0; i < 5; i++) {
+		mem.map = i;
+		pd6729_set_mem_map(sock, &mem);
+	}
+
+	return 0;
+}
+
+
+/* the pccard structure and its functions */
+static struct pccard_operations pd6729_operations = {
+	.init 			= pd6729_init,
+	.suspend		= pd6729_suspend,
+	.get_status		= pd6729_get_status,
+	.get_socket		= pd6729_get_socket,
+	.set_socket		= pd6729_set_socket,
+	.set_io_map		= pd6729_set_io_map,
+	.set_mem_map		= pd6729_set_mem_map,
+};
+
+static int __devinit pd6729_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
+{
+	int i, j, ret;
+	char configbyte;
+	struct pd6729_socket **socket;
+
+	socket = kmalloc(sizeof(socket)*MAX_SOCKETS, GFP_KERNEL);
+	if (!socket)
+		return -ENOMEM;
+
+	socket[0] = kmalloc(sizeof(struct pd6729_socket)*MAX_SOCKETS, GFP_KERNEL);
+	if (!socket[0]) {
+		ret = -ENOMEM;
+		goto err_out_free_mem;
+	}
+
+	memset(socket[0], 0, sizeof(struct pd6729_socket)*MAX_SOCKETS);
+
+	for (i = 1; i < MAX_SOCKETS; i++) {
+		socket[i] = socket[0] + i;
+	}
+
+	if ((ret = pci_enable_device(dev)))
+		goto err_out_free_mem2;
+
+	printk(KERN_INFO "pd6729: Cirrus PD6729 PCI to PCMCIA Bridge at 0x%lx on irq %d\n",
+		pci_resource_start(dev, 0), dev->irq);
+	printk(KERN_INFO "pd6729: configured as a %d socket device.\n", MAX_SOCKETS);
+ 	/* Since we have no memory BARs some firmware we may not
+ 	   have had PCI_COMMAND_MEM enabled, yet the device needs
+ 	   it. */
+	pci_read_config_byte(dev, PCI_COMMAND, &configbyte);
+	if (!(configbyte & PCI_COMMAND_MEMORY)) {
+		printk(KERN_DEBUG "pd6729: Enabling PCI_COMMAND_MEMORY.\n");
+		configbyte |= PCI_COMMAND_MEMORY;
+		pci_write_config_byte(dev, PCI_COMMAND, configbyte);
+	}
+
+	ret = pci_request_regions(dev, "pd6729");
+	if (ret) {
+		printk(KERN_INFO "pd6729: pci request region failed.\n");
+		goto err_out_disable;
+	}
+
+	for (i = 0; i < MAX_SOCKETS; i++) {
+		socket[i]->io_base = pci_resource_start(dev, 0);
+		socket[i]->socket.features |= SS_CAP_PCCARD;
+		socket[i]->socket.map_size = 0x1000;
+		socket[i]->socket.irq_mask = 0;
+		socket[i]->socket.pci_irq  = dev->irq;
+		socket[i]->socket.owner = THIS_MODULE;
+
+		socket[i]->number = i;
+
+		socket[i]->socket.ops = &pd6729_operations;
+		socket[i]->socket.dev.dev = &dev->dev;
+		socket[i]->socket.driver_data = socket[i];
+
+		pci_set_drvdata(dev, socket);
+
+		if (card_present(socket[i])) {
+			dprintk(KERN_DEBUG "pd6729: slot %i is occupied\n", i);
+		} else {
+			dprintk(KERN_DEBUG "pd6729: slot %i is vacant\n", i);
+		}
+	}
+
+	/* Register the interrupt handler */
+	if ((ret = request_irq(dev->irq, pd6729_interrupt, SA_SHIRQ, "pd6729", socket))) {
+		printk(KERN_ERR "pd6729: Failed to register irq %d, aborting\n", dev->irq);
+		goto err_out_free_res;
+	}
+
+	for (i = 0; i<MAX_SOCKETS; i++) {
+		ret = pcmcia_register_socket(&socket[i]->socket);
+		if (ret) {
+			printk(KERN_INFO "pd6729: pcmcia_register_socket failed.\n");
+			for (j = 0; j < i ; j++)
+				pcmcia_unregister_socket(&socket[j]->socket);
+			goto err_out_free_res2;
+		}
+	}
+
+	return 0;
+
+ err_out_free_res2:
+	free_irq(dev->irq, socket);
+ err_out_free_res:
+	pci_release_regions(dev);
+ err_out_disable:
+	pci_disable_device(dev);
+
+ err_out_free_mem2:
+	kfree(socket[0]);
+ err_out_free_mem:
+	kfree(socket);
+	return ret;
+}
+
+static void __devexit pd6729_pci_remove(struct pci_dev *dev)
+{
+	int i;
+	struct pd6729_socket **socket = pci_get_drvdata(dev);
+
+	for (i = 0; i < MAX_SOCKETS; i++)
+		pcmcia_unregister_socket(&socket[i]->socket);
+
+	free_irq(dev->irq, socket);
+	pci_release_regions(dev);
+
+	kfree(socket[0]);
+	kfree(socket);
+}
+
+static int pd6729_socket_suspend(struct pci_dev *dev, u32 state)
+{
+	return pcmcia_socket_dev_suspend(&dev->dev, state);
+}
+
+static int pd6729_socket_resume(struct pci_dev *dev)
+{
+	return pcmcia_socket_dev_resume(&dev->dev);
+}
+
+static struct pci_device_id pd6729_pci_ids[] = {
+	{
+		.vendor		= PCI_VENDOR_ID_CIRRUS,
+		.device		= PCI_DEVICE_ID_CIRRUS_6729,
+		.subvendor	= PCI_ANY_ID,
+		.subdevice	= PCI_ANY_ID,
+	},
+	{ }
+};
+MODULE_DEVICE_TABLE(pci, pd6729_pci_ids);
+
+static struct pci_driver pd6729_pci_drv = {
+	.name		= "pd6729",
+	.id_table	= pd6729_pci_ids,
+	.probe		= pd6729_pci_probe,
+	.remove		= __devexit_p(pd6729_pci_remove),
+	.suspend	= pd6729_socket_suspend,
+	.resume		= pd6729_socket_resume,
+};
+
+static int pd6729_module_init(void)
+{
+	return pci_module_init(&pd6729_pci_drv);
+}
+
+static void pd6729_module_exit(void)
+{
+	pci_unregister_driver(&pd6729_pci_drv);
+}
+
+module_init(pd6729_module_init);
+module_exit(pd6729_module_exit);
diff -ruN linux/drivers/pcmcia.orig/pd6729.h linux/drivers/pcmcia/pd6729.h
--- linux/drivers/pcmcia.orig/pd6729.h	1970-01-01 09:00:00.000000000 +0900
+++ linux/drivers/pcmcia/pd6729.h	2004-05-31 21:07:06.000000000 +0900
@@ -0,0 +1,26 @@
+#ifndef _INCLUDE_GUARD_PD6729_H_
+#define _INCLUDE_GUARD_PD6729_H_
+
+/* Debuging defines */
+#ifdef NOTRACE
+#define dprintk(fmt, args...) printk(fmt , ## args)
+#else
+#define dprintk(fmt, args...) do {} while (0)
+#endif
+
+/* Flags for I365_GENCTL */
+#define I365_DF_VS1		0x40	/* DF-step Voltage Sense */
+#define I365_DF_VS2		0x80
+
+/* Fields in PD67_EXTERN_DATA */
+#define PD67_EXD_VS1(s)		(0x01 << ((s) << 1))
+#define PD67_EXD_VS2(s)		(0x02 << ((s) << 1))
+
+
+struct pd6729_socket {
+	int	number;
+	unsigned long io_base; 	/* base io address of the socket */
+	struct pcmcia_socket socket;
+};
+
+#endif


-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

From jar at pcuf.fi  Sat Jun 19 06:14:07 2004
From: jar at pcuf.fi (Jar)
Date: Sat Jun 19 06:14:14 2004
Subject: 2.6.x kernels & PCI-to-PCMCIA bridges [again]
In-Reply-To: <20040618231147.G17516@flint.arm.linux.org.uk>
References: <40D3539B.6040900@pcuf.fi>
	<20040618231147.G17516@flint.arm.linux.org.uk>
Message-ID: <3095.192.168.0.150.1087640047.squirrel@192.168.0.150>


> I did, and I've been over it a few times last week end, but then got
> distracted, sorry.
>
> Essentially, I've:
> - corrected the formatting
> - removed extraneous white space
> - removed useless "card_state" variable (it was only ever set to 1 and
>   3, and only ever tested to be 0. IOW, the test could never be true.)

Excellent !

But this code doesn't compile well. The Komuro's 31.5.2004 version
compiles without errors/warnings.

[root@gw1 pd6729.final]# make
Copying files: cirrus.h,i82365.h from /usr/src/linux/drivers/pcmcia/
make -C /usr/src/linux SUBDIRS=/u1/src/pd6729.final/module modules \
MODVERDIR=/u1/src/pd6729.final/module modules
make[1]: Entering directory `/usr/src/linux-2.6.6-1.435'
  LD      /u1/src/pd6729.final/module/built-in.o
  CC [M]  /u1/src/pd6729.final/module/pd6729.o
/u1/src/pd6729.final/module/pd6729.c: In function `indirect_read16':
/u1/src/pd6729.final/module/pd6729.c:66: error: `reg' undeclared (first
use in this function)
/u1/src/pd6729.final/module/pd6729.c:66: error: (Each undeclared
identifier is reported only once
/u1/src/pd6729.final/module/pd6729.c:66: error: for each function it
appears in.)
/u1/src/pd6729.final/module/pd6729.c: In function `pd6729_get_socket':
/u1/src/pd6729.final/module/pd6729.c:322: error: structure has no member
named `dev'
/u1/src/pd6729.final/module/pd6729.c: At top level:
/u1/src/pd6729.final/module/pd6729.c:611: warning: type defaults to `int'
in declaration of `structpci_device_id'
/u1/src/pd6729.final/module/pd6729.c:611: error: syntax error before '*'
token
/u1/src/pd6729.final/module/pd6729.c:612: warning: function declaration
isn't a prototype
/u1/src/pd6729.final/module/pd6729.c: In function `pd6729_pci_probe':
/u1/src/pd6729.final/module/pd6729.c:633: error: `dev' undeclared (first
use in this function)
make[2]: *** [/u1/src/pd6729.final/module/pd6729.o] Error 1
make[1]: *** [_module_/u1/src/pd6729.final/module] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.6-1.435'
make: *** [pd6729.o] Error 2

-- 
Best Regards, Jar

From komujun at nifty.com  Sat Jun 19 06:17:13 2004
From: komujun at nifty.com (komujun@nifty.com)
Date: Sat Jun 19 06:17:29 2004
Subject: 2.6.x kernels & PCI-to-PCMCIA bridges [again]  
Message-ID: <493051.1087640233594.komujun@nifty.com>

>Essentially, I've:
>- corrected the formatting
>- removed extraneous white space
>- removed useless "card_state" variable (it was only ever set to 1 and
>  3, and only ever tested to be 0. IOW, the test could never be true.)

I've made some changes.

(1)fix compile error
>drivers/pcmcia/pd6729.c:321: error: structure has no member named `dev'

-	if (socket->dev != NULL)
-		state->io_irq = socket->socket.pci_irq;
+	state->io_irq = socket->socket.pci_irq;

(2)card_present is unnecessary.

(3)kmalloc size is sizeof(*socket)*MAX_SOCKETS.

(4)pci_disable_device when unloading.

Please see the followng patch.
Best Regards
Komuro


--- pd6729.c.orig	2004-06-19 11:46:48.000000000 +0900
+++ pd6729.c	2004-06-19 12:22:38.292064992 +0900
@@ -200,22 +200,6 @@
 	return IRQ_RETVAL(handled);
 }
 
-/* socket functions */
-
-static int card_present(struct pd6729_socket *socket)
-{
-	unsigned int val;
-
-	val = indirect_read(socket, 1); /* Interface status register */
-	if ((val&12) == 12) {
-		dprintk("card_present 1");
-		return 1;
-	}
-
-	dprintk("card_present 0");
-	return 0;
-}
-
 static void set_bridge_state(struct pd6729_socket *socket)
 {
 	indirect_write(socket, I365_GBLCTL, 0x00);
@@ -318,8 +302,7 @@
 		state->flags |= SS_IOCARD; /* This is an IO card */
 
 	/* Set the IRQ number */
-	if (socket->dev != NULL)
-		state->io_irq = socket->socket.pci_irq;
+	state->io_irq = socket->socket.pci_irq;
 
 	/* Card status change */
 	/* CSCICR, Card Status Change Interrupt Configuration */
@@ -613,7 +596,7 @@
 	char configbyte;
 	struct pd6729_socket **socket;
 
-	socket = kmalloc(sizeof(socket)*MAX_SOCKETS, GFP_KERNEL);
+	socket = kmalloc(sizeof(*socket)*MAX_SOCKETS, GFP_KERNEL);
 	if (!socket)
 		return -ENOMEM;
 
@@ -666,12 +649,6 @@
 		socket[i]->socket.driver_data = socket[i];
 
 		pci_set_drvdata(dev, socket);
-
-		if (card_present(socket[i])) {
-			dprintk(KERN_DEBUG "pd6729: slot %i is occupied\n", i);
-		} else {
-			dprintk(KERN_DEBUG "pd6729: slot %i is vacant\n", i);
-		}
 	}
 
 	/* Register the interrupt handler */
@@ -716,6 +693,7 @@
 
 	free_irq(dev->irq, socket);
 	pci_release_regions(dev);
+	pci_disable_device(dev);
 
 	kfree(socket[0]);
 	kfree(socket);



From rmk+pcmcia at arm.linux.org.uk  Sat Jun 19 06:40:46 2004
From: rmk+pcmcia at arm.linux.org.uk (Russell King)
Date: Sat Jun 19 06:40:55 2004
Subject: 2.6.x kernels & PCI-to-PCMCIA bridges [again]
In-Reply-To: <3095.192.168.0.150.1087640047.squirrel@192.168.0.150>;
	from jar@pcuf.fi on Sat, Jun 19, 2004 at 01:14:07PM +0300
References: <40D3539B.6040900@pcuf.fi>
	<20040618231147.G17516@flint.arm.linux.org.uk>
	<3095.192.168.0.150.1087640047.squirrel@192.168.0.150>
Message-ID: <20040619114046.A26611@flint.arm.linux.org.uk>

On Sat, Jun 19, 2004 at 01:14:07PM +0300, Jar wrote:
> But this code doesn't compile well. The Komuro's 31.5.2004 version
> compiles without errors/warnings.

No idea why you're getting these errors:

> [root@gw1 pd6729.final]# make
> Copying files: cirrus.h,i82365.h from /usr/src/linux/drivers/pcmcia/
> make -C /usr/src/linux SUBDIRS=/u1/src/pd6729.final/module modules \
> MODVERDIR=/u1/src/pd6729.final/module modules
> make[1]: Entering directory `/usr/src/linux-2.6.6-1.435'
>   LD      /u1/src/pd6729.final/module/built-in.o
>   CC [M]  /u1/src/pd6729.final/module/pd6729.o
> /u1/src/pd6729.final/module/pd6729.c: In function `indirect_read16':
> /u1/src/pd6729.final/module/pd6729.c:66: error: `reg' undeclared (first
> use in this function)

57:+static unsigned short indirect_read16(struct pd6729_socket *socket, unsigned short reg)
66:+       outb(reg, port);

'reg' is a function parameter, therefore it _is_ declared.  I suggest
that your mail client knows far more about white spacing rules than
the mail sender.

> /u1/src/pd6729.final/module/pd6729.c: In function `pd6729_get_socket':
> /u1/src/pd6729.final/module/pd6729.c:322: error: structure has no member
> named `dev'

This one is valid.

> /u1/src/pd6729.final/module/pd6729.c: At top level:
> /u1/src/pd6729.final/module/pd6729.c:611: warning: type defaults to `int'
> in declaration of `structpci_device_id'

In my patch, this reads:

+static int __devinit pd6729_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)

again, it's another effect if your mail client knowing too much about
white spacing (or rather, your mail client authors thinking that they
have the right to dictate how plain text should be formatted.)

> /u1/src/pd6729.final/module/pd6729.c:611: error: syntax error before '*'
> token
> /u1/src/pd6729.final/module/pd6729.c:612: warning: function declaration
> isn't a prototype
> /u1/src/pd6729.final/module/pd6729.c: In function `pd6729_pci_probe':
> /u1/src/pd6729.final/module/pd6729.c:633: error: `dev' undeclared (first
> use in this function)

and this is a side effect of the above error.

So, we've found one real problem and discovered that the mail client
you're using does stupid things with white spacing / long lines.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

From rmk+pcmcia at arm.linux.org.uk  Sat Jun 19 07:07:13 2004
From: rmk+pcmcia at arm.linux.org.uk (Russell King)
Date: Sat Jun 19 07:07:27 2004
Subject: 2.6.x kernels & PCI-to-PCMCIA bridges [again]
In-Reply-To: <493051.1087640233594.komujun@nifty.com>;
	from komujun@nifty.com on Sat, Jun 19, 2004 at 07:17:13PM +0900
References: <493051.1087640233594.komujun@nifty.com>
Message-ID: <20040619120713.B26611@flint.arm.linux.org.uk>

On Sat, Jun 19, 2004 at 07:17:13PM +0900, komujun@nifty.com wrote:
> (3)kmalloc size is sizeof(*socket)*MAX_SOCKETS.

Ok, the one thing I'm left wondering about is why we kmalloc an array
of pointers and an array of struct pd6729_socket.

IOW, how about the attached patch (and lets hope everyone can get it
without their mail client crapping on it...)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core
-------------- next part --------------
diff -ruN linux/drivers/pcmcia.orig/Kconfig linux/drivers/pcmcia/Kconfig
--- linux/drivers/pcmcia.orig/Kconfig	2004-05-10 11:33:05.000000000 +0900
+++ linux/drivers/pcmcia/Kconfig	2004-05-31 21:07:06.000000000 +0900
@@ -69,6 +69,13 @@
 	depends on YENTA
 	default y if YENTA
 
+config PD6729
+	tristate "Cirrus PD6729 compatible bridge support"
+	depends on PCMCIA && PCI
+	help
+	  This provides support for the Cirrus PD6729 PCI-to-PCMCIA bridge
+	  device, found in some older laptops and PCMCIA card readers.
+
 config I82092
 	tristate "i82092 compatible bridge support"
 	depends on PCMCIA && PCI
diff -ruN linux/drivers/pcmcia.orig/Makefile linux/drivers/pcmcia/Makefile
--- linux/drivers/pcmcia.orig/Makefile	2004-05-10 11:33:12.000000000 +0900
+++ linux/drivers/pcmcia/Makefile	2004-05-31 21:07:06.000000000 +0900
@@ -9,6 +9,7 @@
 obj-$(CONFIG_PCMCIA)				+= pcmcia_core.o ds.o
 obj-$(CONFIG_YENTA) 				+= yenta_socket.o
 
+obj-$(CONFIG_PD6729)				+= pd6729.o
 obj-$(CONFIG_I82365)				+= i82365.o
 obj-$(CONFIG_I82092)				+= i82092.o
 obj-$(CONFIG_TCIC)				+= tcic.o
diff -ruN linux/drivers/pcmcia.orig/pd6729.c linux/drivers/pcmcia/pd6729.c
--- linux/drivers/pcmcia.orig/pd6729.c	1970-01-01 09:00:00.000000000 +0900
+++ linux/drivers/pcmcia/pd6729.c	2004-05-31 21:28:59.000000000 +0900
@@ -0,0 +1,732 @@
+/*
+ * Driver for the Cirrus PD6729 PCI-PCMCIA bridge.
+ *
+ * Based on the i82092.c driver.
+ *
+ * This software may be used and distributed according to the terms of
+ * the GNU General Public License, incorporated herein by reference.
+ */
+
+#include <linux/kernel.h>
+#include <linux/config.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/init.h>
+#include <linux/workqueue.h>
+#include <linux/interrupt.h>
+#include <linux/device.h>
+
+#include <pcmcia/cs_types.h>
+#include <pcmcia/ss.h>
+#include <pcmcia/cs.h>
+
+#include <asm/system.h>
+#include <asm/io.h>
+
+#include "pd6729.h"
+#include "i82365.h"
+#include "cirrus.h"
+
+MODULE_LICENSE("GPL");
+
+#define MAX_SOCKETS 2
+
+/* simple helper functions */
+/* External clock time, in nanoseconds.  120 ns = 8.33 MHz */
+#define to_cycles(ns)	((ns)/120)
+
+static spinlock_t port_lock = SPIN_LOCK_UNLOCKED;
+
+/* basic value read/write functions */
+
+static unsigned char indirect_read(struct pd6729_socket *socket, unsigned short reg)
+{
+	unsigned long port;
+	unsigned char val;
+	unsigned long flags;
+
+	spin_lock_irqsave(&port_lock, flags);
+	reg += socket->number * 0x40;
+	port = socket->io_base;
+	outb(reg, port);
+	val = inb(port + 1);
+	spin_unlock_irqrestore(&port_lock, flags);
+
+	return val;
+}
+
+static unsigned short indirect_read16(struct pd6729_socket *socket, unsigned short reg)
+{
+	unsigned long port;
+	unsigned short tmp;
+	unsigned long flags;
+
+	spin_lock_irqsave(&port_lock, flags);
+	reg  = reg + socket->number * 0x40;
+	port = socket->io_base;
+	outb(reg, port);
+	tmp = inb(port + 1);
+	reg++;
+	outb(reg, port);
+	tmp = tmp | (inb(port + 1) << 8);
+	spin_unlock_irqrestore(&port_lock, flags);
+
+	return tmp;
+}
+
+static void indirect_write(struct pd6729_socket *socket, unsigned short reg, unsigned char value)
+{
+	unsigned long port;
+	unsigned long flags;
+
+	spin_lock_irqsave(&port_lock, flags);
+	reg = reg + socket->number * 0x40;
+	port = socket->io_base;
+	outb(reg, port);
+	outb(value, port + 1);
+	spin_unlock_irqrestore(&port_lock, flags);
+}
+
+static void indirect_setbit(struct pd6729_socket *socket, unsigned short reg, unsigned char mask)
+{
+	unsigned long port;
+	unsigned char val;
+	unsigned long flags;
+
+	spin_lock_irqsave(&port_lock, flags);
+	reg = reg + socket->number * 0x40;
+	port = socket->io_base;
+	outb(reg, port);
+	val = inb(port + 1);
+	val |= mask;
+	outb(reg, port);
+	outb(val, port + 1);
+	spin_unlock_irqrestore(&port_lock, flags);
+}
+
+static void indirect_resetbit(struct pd6729_socket *socket, unsigned short reg, unsigned char mask)
+{
+	unsigned long port;
+	unsigned char val;
+	unsigned long flags;
+
+	spin_lock_irqsave(&port_lock, flags);
+	reg = reg + socket->number * 0x40;
+	port = socket->io_base;
+	outb(reg, port);
+	val = inb(port + 1);
+	val &= ~mask;
+	outb(reg, port);
+	outb(val, port + 1);
+	spin_unlock_irqrestore(&port_lock, flags);
+}
+
+static void indirect_write16(struct pd6729_socket *socket, unsigned short reg, unsigned short value)
+{
+	unsigned long port;
+	unsigned char val;
+	unsigned long flags;
+
+	spin_lock_irqsave(&port_lock, flags);
+	reg = reg + socket->number * 0x40;
+	port = socket->io_base;
+
+	outb(reg, port);
+	val = value & 255;
+	outb(val, port + 1);
+
+	reg++;
+
+	outb(reg, port);
+	val = value >> 8;
+	outb(val, port + 1);
+	spin_unlock_irqrestore(&port_lock, flags);
+}
+
+/* Interrupt handler functionality */
+
+static irqreturn_t pd6729_interrupt(int irq, void *dev, struct pt_regs *regs)
+{
+	struct pd6729_socket *socket = (struct pd6729_socket *)dev;
+	int i;
+	int loopcount = 0;
+	int handled = 0;
+	unsigned int events, active = 0;
+
+	while (1) {
+		loopcount++;
+		if (loopcount > 20) {
+			printk(KERN_ERR "pd6729: infinite eventloop in interrupt\n");
+			break;
+		}
+
+		active = 0;
+
+		for (i = 0; i < MAX_SOCKETS; i++) {
+			unsigned int csc;
+
+			/* card status change register */
+			csc = indirect_read(&socket[i], I365_CSC);
+			if (csc == 0)  /* no events on this socket */
+				continue;
+
+			handled = 1;
+			events = 0;
+
+			if (csc & I365_CSC_DETECT) {
+				events |= SS_DETECT;
+				dprintk("Card detected in socket %i!\n", i);
+			}
+
+			if (indirect_read(&socket[i], I365_INTCTL) & I365_PC_IOCARD) {
+				/* For IO/CARDS, bit 0 means "read the card" */
+				events |= (csc & I365_CSC_STSCHG) ? SS_STSCHG : 0;
+			} else {
+				/* Check for battery/ready events */
+				events |= (csc & I365_CSC_BVD1) ? SS_BATDEAD : 0;
+				events |= (csc & I365_CSC_BVD2) ? SS_BATWARN : 0;
+				events |= (csc & I365_CSC_READY) ? SS_READY : 0;
+			}
+
+			if (events) {
+				pcmcia_parse_events(&socket[i].socket, events);
+			}
+			active |= events;
+		}
+
+		if (active == 0) /* no more events to handle */
+			break;
+	}
+	return IRQ_RETVAL(handled);
+}
+
+/* socket functions */
+
+static void set_bridge_state(struct pd6729_socket *socket)
+{
+	indirect_write(socket, I365_GBLCTL, 0x00);
+	indirect_write(socket, I365_GENCTL, 0x00);
+
+	indirect_setbit(socket, I365_INTCTL, 0x08);
+}
+
+static int pd6729_get_status(struct pcmcia_socket *sock, u_int *value)
+{
+	struct pd6729_socket *socket = container_of(sock, struct pd6729_socket, socket);
+	unsigned int status;
+	unsigned int data;
+	struct pd6729_socket *t;
+
+	/* Interface Status Register */
+	status = indirect_read(socket, I365_STATUS);
+	*value = 0;
+
+	if ((status & I365_CS_DETECT) == I365_CS_DETECT) {
+		*value |= SS_DETECT;
+	}
+
+	/* IO cards have a different meaning of bits 0,1 */
+	/* Also notice the inverse-logic on the bits */
+	if (indirect_read(socket, I365_INTCTL) & I365_PC_IOCARD) {
+		/* IO card */
+		if (!(status & I365_CS_STSCHG))
+			*value |= SS_STSCHG;
+	} else {
+		/* non I/O card */
+		if (!(status & I365_CS_BVD1))
+			*value |= SS_BATDEAD;
+		if (!(status & I365_CS_BVD2))
+			*value |= SS_BATWARN;
+	}
+
+	if (status & I365_CS_WRPROT)
+		*value |= SS_WRPROT;	/* card is write protected */
+
+	if (status & I365_CS_READY)
+		*value |= SS_READY;	/* card is not busy */
+
+	if (status & I365_CS_POWERON)
+		*value |= SS_POWERON;	/* power is applied to the card */
+
+	t = (socket->number) ? socket : socket + 1;
+	indirect_write(t, PD67_EXT_INDEX, PD67_EXTERN_DATA);
+	data = indirect_read16(t, PD67_EXT_DATA);
+	*value |= (data & PD67_EXD_VS1(socket->number)) ? 0 : SS_3VCARD;
+
+	return 0;
+}
+
+
+static int pd6729_get_socket(struct pcmcia_socket *sock, socket_state_t *state)
+{
+	struct pd6729_socket *socket = container_of(sock, struct pd6729_socket, socket);
+	unsigned char reg, vcc, vpp;
+
+	state->flags    = 0;
+	state->Vcc      = 0;
+	state->Vpp      = 0;
+	state->io_irq   = 0;
+	state->csc_mask = 0;
+
+	/* First the power status of the socket */
+	/* PCTRL - Power Control Register */
+	reg = indirect_read(socket, I365_POWER);
+
+	if (reg & I365_PWR_AUTO)
+		state->flags |= SS_PWR_AUTO;  /* Automatic Power Switch */
+
+	if (reg & I365_PWR_OUT)
+		state->flags |= SS_OUTPUT_ENA; /* Output signals are enabled */
+
+	vcc = reg & I365_VCC_MASK;    vpp = reg & I365_VPP1_MASK;
+
+	if (reg & I365_VCC_5V) {
+		state->Vcc = (indirect_read(socket, PD67_MISC_CTL_1) &
+			PD67_MC1_VCC_3V) ? 33 : 50;
+
+		if (vpp == I365_VPP1_5V) {
+			if (state->Vcc == 50)
+				state->Vpp = 50;
+			else
+				state->Vpp = 33;
+		}
+		if (vpp == I365_VPP1_12V)
+			state->Vpp = 120;
+	}
+
+	/* Now the IO card, RESET flags and IO interrupt */
+	/* IGENC, Interrupt and General Control */
+	reg = indirect_read(socket, I365_INTCTL);
+
+	if ((reg & I365_PC_RESET) == 0)
+		state->flags |= SS_RESET;
+	if (reg & I365_PC_IOCARD)
+		state->flags |= SS_IOCARD; /* This is an IO card */
+
+	/* Set the IRQ number */
+	state->io_irq = socket->socket.pci_irq;
+
+	/* Card status change */
+	/* CSCICR, Card Status Change Interrupt Configuration */
+	reg = indirect_read(socket, I365_CSCINT);
+
+	if (reg & I365_CSC_DETECT)
+		state->csc_mask |= SS_DETECT; /* Card detect is enabled */
+
+	if (state->flags & SS_IOCARD) {/* IO Cards behave different */
+		if (reg & I365_CSC_STSCHG)
+			state->csc_mask |= SS_STSCHG;
+	} else {
+		if (reg & I365_CSC_BVD1)
+			state->csc_mask |= SS_BATDEAD;
+		if (reg & I365_CSC_BVD2)
+			state->csc_mask |= SS_BATWARN;
+		if (reg & I365_CSC_READY)
+			state->csc_mask |= SS_READY;
+	}
+
+	return 0;
+}
+
+static int pd6729_set_socket(struct pcmcia_socket *sock, socket_state_t *state)
+{
+	struct pd6729_socket *socket = container_of(sock, struct pd6729_socket, socket);
+	unsigned char reg;
+
+	/* First, set the global controller options */
+
+	set_bridge_state(socket);
+
+	/* Values for the IGENC register */
+
+	reg = 0;
+ 	/* The reset bit has "inverse" logic */
+	if (!(state->flags & SS_RESET))
+		reg = reg | I365_PC_RESET;
+	if (state->flags & SS_IOCARD)
+		reg = reg | I365_PC_IOCARD;
+
+	/* IGENC, Interrupt and General Control Register */
+	indirect_write(socket, I365_INTCTL, reg);
+
+	/* Power registers */
+
+	reg = I365_PWR_NORESET; /* default: disable resetdrv on resume */
+
+	if (state->flags & SS_PWR_AUTO) {
+		dprintk("Auto power\n");
+		reg |= I365_PWR_AUTO;	/* automatic power mngmnt */
+	}
+	if (state->flags & SS_OUTPUT_ENA) {
+		dprintk("Power Enabled\n");
+		reg |= I365_PWR_OUT;	/* enable power */
+	}
+
+	switch (state->Vcc) {
+	case 0:
+		break;
+	case 33:
+		dprintk("setting voltage to Vcc to 3.3V on socket %i\n",
+			socket->number);
+		reg |= I365_VCC_5V;
+		indirect_setbit(socket, PD67_MISC_CTL_1, PD67_MC1_VCC_3V);
+		break;
+	case 50:
+		dprintk("setting voltage to Vcc to 5V on socket %i\n",
+			socket->number);
+		reg |= I365_VCC_5V;
+		indirect_resetbit(socket, PD67_MISC_CTL_1, PD67_MC1_VCC_3V);
+		break;
+	default:
+		dprintk("pd6729: pd6729_set_socket called with invalid VCC power value: %i\n",
+			state->Vcc);
+		return -EINVAL;
+	}
+
+	switch (state->Vpp) {
+	case 0:
+		dprintk("not setting Vpp on socket %i\n", socket->number);
+		break;
+	case 33:
+	case 50:
+		dprintk("setting Vpp to Vcc for socket %i\n", socket->number);
+		reg |= I365_VPP1_5V;
+		break;
+	case 120:
+		dprintk("setting Vpp to 12.0\n");
+		reg |= I365_VPP1_12V;
+		break;
+	default:
+		dprintk("pd6729: pd6729_set_socket called with invalid VPP power value: %i\n",
+			state->Vpp);
+		return -EINVAL;
+	}
+
+	/* only write if changed */
+	if (reg != indirect_read(socket, I365_POWER))
+		indirect_write(socket, I365_POWER, reg);
+
+	/* Now, specifiy that all interrupts are to be done as PCI interrupts */
+	indirect_write(socket, PD67_EXT_INDEX, PD67_EXT_CTL_1);
+	indirect_write(socket, PD67_EXT_DATA, PD67_EC1_INV_MGMT_IRQ | PD67_EC1_INV_CARD_IRQ);
+
+	/* Enable specific interrupt events */
+
+	reg = 0x00;
+	if (state->csc_mask & SS_DETECT) {
+		reg |= I365_CSC_DETECT;
+	}
+	if (state->flags & SS_IOCARD) {
+		if (state->csc_mask & SS_STSCHG)
+			reg |= I365_CSC_STSCHG;
+	} else {
+		if (state->csc_mask & SS_BATDEAD)
+			reg |= I365_CSC_BVD1;
+		if (state->csc_mask & SS_BATWARN)
+			reg |= I365_CSC_BVD2;
+		if (state->csc_mask & SS_READY)
+			reg |= I365_CSC_READY;
+	}
+	reg |= 0x30;	/* management IRQ: PCI INTA# = "irq 3" */
+	indirect_write(socket, I365_CSCINT, reg);
+
+	reg = indirect_read(socket, I365_INTCTL);
+	reg |= 0x03;	/* card IRQ: PCI INTA# = "irq 3" */
+	indirect_write(socket, I365_INTCTL, reg);
+
+	/* now clear the (probably bogus) pending stuff by doing a dummy read */
+	(void)indirect_read(socket, I365_CSC);
+
+	return 0;
+}
+
+static int pd6729_set_io_map(struct pcmcia_socket *sock, struct pccard_io_map *io)
+{
+	struct pd6729_socket *socket = container_of(sock, struct pd6729_socket, socket);
+	unsigned char map, ioctl;
+
+	map = io->map;
+
+	/* Check error conditions */
+	if (map > 1) {
+		dprintk("pd6729_set_io_map with invalid map");
+		return -EINVAL;
+	}
+
+	/* Turn off the window before changing anything */
+	if (indirect_read(socket, I365_ADDRWIN) & I365_ENA_IO(map))
+		indirect_resetbit(socket, I365_ADDRWIN, I365_ENA_IO(map));
+
+/*	dprintk("set_io_map: Setting range to %x - %x\n", io->start, io->stop);*/
+
+	/* write the new values */
+	indirect_write16(socket, I365_IO(map)+I365_W_START, io->start);
+	indirect_write16(socket, I365_IO(map)+I365_W_STOP, io->stop);
+
+	ioctl = indirect_read(socket, I365_IOCTL) & ~I365_IOCTL_MASK(map);
+
+	if (io->flags & MAP_0WS) ioctl |= I365_IOCTL_0WS(map);
+	if (io->flags & MAP_16BIT) ioctl |= I365_IOCTL_16BIT(map);
+	if (io->flags & MAP_AUTOSZ) ioctl |= I365_IOCTL_IOCS16(map);
+
+	indirect_write(socket, I365_IOCTL, ioctl);
+
+	/* Turn the window back on if needed */
+	if (io->flags & MAP_ACTIVE)
+		indirect_setbit(socket, I365_ADDRWIN, I365_ENA_IO(map));
+
+	return 0;
+}
+
+static int pd6729_set_mem_map(struct pcmcia_socket *sock, struct pccard_mem_map *mem)
+{
+	struct pd6729_socket *socket = container_of(sock, struct pd6729_socket, socket);
+	unsigned short base, i;
+	unsigned char map;
+
+	map = mem->map;
+	if (map > 4) {
+		printk("pd6729_set_mem_map: invalid map");
+		return -EINVAL;
+	}
+
+	if ((mem->sys_start > mem->sys_stop) || (mem->speed > 1000)) {
+		printk("pd6729_set_mem_map: invalid address / speed");
+		/* printk("invalid mem map for socket %i : %lx to %lx with a start of %x\n",
+			 sock, mem->sys_start, mem->sys_stop, mem->card_start); */
+		return -EINVAL;
+	}
+
+	/* Turn off the window before changing anything */
+	if (indirect_read(socket, I365_ADDRWIN) & I365_ENA_MEM(map))
+		indirect_resetbit(socket, I365_ADDRWIN, I365_ENA_MEM(map));
+
+	/* write the start address */
+	base = I365_MEM(map);
+	i = (mem->sys_start >> 12) & 0x0fff;
+	if (mem->flags & MAP_16BIT)
+		i |= I365_MEM_16BIT;
+	if (mem->flags & MAP_0WS)
+		i |= I365_MEM_0WS;
+	indirect_write16(socket, base + I365_W_START, i);
+
+	/* write the stop address */
+
+	i= (mem->sys_stop >> 12) & 0x0fff;
+	switch (to_cycles(mem->speed)) {
+	case 0:
+		break;
+	case 1:
+		i |= I365_MEM_WS0;
+		break;
+	case 2:
+		i |= I365_MEM_WS1;
+		break;
+	default:
+		i |= I365_MEM_WS1 | I365_MEM_WS0;
+		break;
+	}
+
+	indirect_write16(socket, base + I365_W_STOP, i);
+
+	/* Take care of high byte */
+	indirect_write(socket, PD67_EXT_INDEX, PD67_MEM_PAGE(map));
+	indirect_write(socket, PD67_EXT_DATA, mem->sys_start >> 24);
+
+	/* card start */
+
+	i = ((mem->card_start - mem->sys_start) >> 12) & 0x3fff;
+	if (mem->flags & MAP_WRPROT)
+		i |= I365_MEM_WRPROT;
+	if (mem->flags & MAP_ATTRIB) {
+/*		dprintk("requesting attribute memory for socket %i\n",
+			socket->number);*/
+		i |= I365_MEM_REG;
+	} else {
+/*		dprintk("requesting normal memory for socket %i\n",
+			socket->number);*/
+	}
+	indirect_write16(socket, base + I365_W_OFF, i);
+
+	/* Enable the window if necessary */
+	if (mem->flags & MAP_ACTIVE)
+		indirect_setbit(socket, I365_ADDRWIN, I365_ENA_MEM(map));
+
+	return 0;
+}
+
+static int pd6729_suspend(struct pcmcia_socket *sock)
+{
+	return pd6729_set_socket(sock, &dead_socket);
+}
+
+static int pd6729_init(struct pcmcia_socket *sock)
+{
+	int i;
+	pccard_io_map io = { 0, 0, 0, 0, 1 };
+	pccard_mem_map mem = { 0, 0, 0, 0, 0, 0 };
+
+	mem.sys_stop = 0x0fff;
+	pd6729_set_socket(sock, &dead_socket);
+	for (i = 0; i < 2; i++) {
+		io.map = i;
+		pd6729_set_io_map(sock, &io);
+	}
+	for (i = 0; i < 5; i++) {
+		mem.map = i;
+		pd6729_set_mem_map(sock, &mem);
+	}
+
+	return 0;
+}
+
+
+/* the pccard structure and its functions */
+static struct pccard_operations pd6729_operations = {
+	.init 			= pd6729_init,
+	.suspend		= pd6729_suspend,
+	.get_status		= pd6729_get_status,
+	.get_socket		= pd6729_get_socket,
+	.set_socket		= pd6729_set_socket,
+	.set_io_map		= pd6729_set_io_map,
+	.set_mem_map		= pd6729_set_mem_map,
+};
+
+static int __devinit pd6729_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
+{
+	int i, j, ret;
+	char configbyte;
+	struct pd6729_socket *socket;
+
+	socket = kmalloc(sizeof(struct pd6729_socket) * MAX_SOCKETS, GFP_KERNEL);
+	if (!socket)
+		return -ENOMEM;
+
+	memset(socket, 0, sizeof(struct pd6729_socket) * MAX_SOCKETS);
+
+	if ((ret = pci_enable_device(dev)))
+		goto err_out_free_mem;
+
+	printk(KERN_INFO "pd6729: Cirrus PD6729 PCI to PCMCIA Bridge at 0x%lx on irq %d\n",
+		pci_resource_start(dev, 0), dev->irq);
+	printk(KERN_INFO "pd6729: configured as a %d socket device.\n", MAX_SOCKETS);
+ 	/* Since we have no memory BARs some firmware we may not
+ 	   have had PCI_COMMAND_MEM enabled, yet the device needs
+ 	   it. */
+	pci_read_config_byte(dev, PCI_COMMAND, &configbyte);
+	if (!(configbyte & PCI_COMMAND_MEMORY)) {
+		printk(KERN_DEBUG "pd6729: Enabling PCI_COMMAND_MEMORY.\n");
+		configbyte |= PCI_COMMAND_MEMORY;
+		pci_write_config_byte(dev, PCI_COMMAND, configbyte);
+	}
+
+	ret = pci_request_regions(dev, "pd6729");
+	if (ret) {
+		printk(KERN_INFO "pd6729: pci request region failed.\n");
+		goto err_out_disable;
+	}
+
+	for (i = 0; i < MAX_SOCKETS; i++) {
+		socket[i].io_base = pci_resource_start(dev, 0);
+		socket[i].socket.features |= SS_CAP_PCCARD;
+		socket[i].socket.map_size = 0x1000;
+		socket[i].socket.irq_mask = 0;
+		socket[i].socket.pci_irq  = dev->irq;
+		socket[i].socket.owner = THIS_MODULE;
+
+		socket[i].number = i;
+
+		socket[i].socket.ops = &pd6729_operations;
+		socket[i].socket.dev.dev = &dev->dev;
+		socket[i].socket.driver_data = &socket[i];
+	}
+
+	pci_set_drvdata(dev, socket);
+
+	/* Register the interrupt handler */
+	if ((ret = request_irq(dev->irq, pd6729_interrupt, SA_SHIRQ, "pd6729", socket))) {
+		printk(KERN_ERR "pd6729: Failed to register irq %d, aborting\n", dev->irq);
+		goto err_out_free_res;
+	}
+
+	for (i = 0; i < MAX_SOCKETS; i++) {
+		ret = pcmcia_register_socket(&socket[i].socket);
+		if (ret) {
+			printk(KERN_INFO "pd6729: pcmcia_register_socket failed.\n");
+			for (j = 0; j < i ; j++)
+				pcmcia_unregister_socket(&socket[j].socket);
+			goto err_out_free_res2;
+		}
+	}
+
+	return 0;
+
+ err_out_free_res2:
+	free_irq(dev->irq, socket);
+ err_out_free_res:
+	pci_release_regions(dev);
+ err_out_disable:
+	pci_disable_device(dev);
+
+ err_out_free_mem:
+	kfree(socket);
+	return ret;
+}
+
+static void __devexit pd6729_pci_remove(struct pci_dev *dev)
+{
+	int i;
+	struct pd6729_socket *socket = pci_get_drvdata(dev);
+
+	for (i = 0; i < MAX_SOCKETS; i++)
+		pcmcia_unregister_socket(&socket[i].socket);
+
+	free_irq(dev->irq, socket);
+	pci_release_regions(dev);
+	pci_disable_device(dev);
+
+	kfree(socket);
+}
+
+static int pd6729_socket_suspend(struct pci_dev *dev, u32 state)
+{
+	return pcmcia_socket_dev_suspend(&dev->dev, state);
+}
+
+static int pd6729_socket_resume(struct pci_dev *dev)
+{
+	return pcmcia_socket_dev_resume(&dev->dev);
+}
+
+static struct pci_device_id pd6729_pci_ids[] = {
+	{
+		.vendor		= PCI_VENDOR_ID_CIRRUS,
+		.device		= PCI_DEVICE_ID_CIRRUS_6729,
+		.subvendor	= PCI_ANY_ID,
+		.subdevice	= PCI_ANY_ID,
+	},
+	{ }
+};
+MODULE_DEVICE_TABLE(pci, pd6729_pci_ids);
+
+static struct pci_driver pd6729_pci_drv = {
+	.name		= "pd6729",
+	.id_table	= pd6729_pci_ids,
+	.probe		= pd6729_pci_probe,
+	.remove		= __devexit_p(pd6729_pci_remove),
+	.suspend	= pd6729_socket_suspend,
+	.resume		= pd6729_socket_resume,
+};
+
+static int pd6729_module_init(void)
+{
+	return pci_module_init(&pd6729_pci_drv);
+}
+
+static void pd6729_module_exit(void)
+{
+	pci_unregister_driver(&pd6729_pci_drv);
+}
+
+module_init(pd6729_module_init);
+module_exit(pd6729_module_exit);
diff -ruN linux/drivers/pcmcia.orig/pd6729.h linux/drivers/pcmcia/pd6729.h
--- linux/drivers/pcmcia.orig/pd6729.h	1970-01-01 09:00:00.000000000 +0900
+++ linux/drivers/pcmcia/pd6729.h	2004-05-31 21:07:06.000000000 +0900
@@ -0,0 +1,28 @@
+#ifndef _INCLUDE_GUARD_PD6729_H_
+#define _INCLUDE_GUARD_PD6729_H_
+
+/* Debuging defines */
+#ifdef NOTRACE
+#define dprintk(fmt, args...) printk(fmt , ## args)
+#else
+#define dprintk(fmt, args...) do {} while (0)
+#endif
+
+/* Flags for I365_GENCTL */
+#define I365_DF_VS1		0x40	/* DF-step Voltage Sense */
+#define I365_DF_VS2		0x80
+
+/* Fields in PD67_EXTERN_DATA */
+#define PD67_EXD_VS1(s)		(0x01 << ((s) << 1))
+#define PD67_EXD_VS2(s)		(0x02 << ((s) << 1))
+
+
+
+
+struct pd6729_socket {
+	int	number;
+	unsigned long io_base; 	/* base io address of the socket */
+	struct pcmcia_socket socket;
+};
+
+#endif


_______________________________________________
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
From jar at pcuf.fi  Sat Jun 19 07:20:48 2004
From: jar at pcuf.fi (Jar)
Date: Sat Jun 19 07:20:58 2004
Subject: 2.6.x kernels & PCI-to-PCMCIA bridges [again]
In-Reply-To: <20040619114046.A26611@flint.arm.linux.org.uk>
References: <40D3539B.6040900@pcuf.fi>
	<20040618231147.G17516@flint.arm.linux.org.uk>
	<3095.192.168.0.150.1087640047.squirrel@192.168.0.150>
	<20040619114046.A26611@flint.arm.linux.org.uk>
Message-ID: <3313.192.168.0.150.1087644048.squirrel@192.168.0.150>

> So, we've found one real problem and discovered that the mail client
> you're using does stupid things with white spacing / long lines.

Yes, you are absolutely right, 100% my fault, sorry for that
useless email I send. I use SquirrelMail right now and all long lines
doesn?t fit to one line. It cut the line and throw the rest words to the
second line and evidently removes the cpace. And when I throw back the
word there are no space anymore. But I should have had to notice that,
sorry.

Anyway, I corrected the long lines and also added the Komuros's todays
fixes. Driver seems to work OK for me.

-- 
Best Regards, Jar

From jar at pcuf.fi  Sat Jun 19 07:57:04 2004
From: jar at pcuf.fi (Jar)
Date: Sat Jun 19 07:57:09 2004
Subject: 2.6.x kernels & PCI-to-PCMCIA bridges [again]
In-Reply-To: <20040619120713.B26611@flint.arm.linux.org.uk>
References: <493051.1087640233594.komujun@nifty.com>
	<20040619120713.B26611@flint.arm.linux.org.uk>
Message-ID: <3377.192.168.0.150.1087646224.squirrel@192.168.0.150>


> On Sat, Jun 19, 2004 at 07:17:13PM +0900, komujun@nifty.com wrote:
>> (3)kmalloc size is sizeof(*socket)*MAX_SOCKETS.
>
> Ok, the one thing I'm left wondering about is why we kmalloc an array
> of pointers and an array of struct pd6729_socket.
>
> IOW, how about the attached patch (and lets hope everyone can get it
> without their mail client crapping on it...)

This patch seems also working for me:

- hardware is working
- all cardctl commands working
- pcmcia restart is working

-- 
Best Regards, Jar

From komujun at nifty.com  Sat Jun 19 11:20:07 2004
From: komujun at nifty.com (komujun@nifty.com)
Date: Sat Jun 19 11:20:17 2004
Subject: 2.6.x kernels & PCI-to-PCMCIA bridges [again]
In-Reply-To: <20040619120713.B26611@flint.arm.linux.org.uk>
References: <20040619120713.B26611@flint.arm.linux.org.uk>
	<493051.1087640233594.komujun@nifty.com>
Message-ID: <4850364.1087658407607.komujun@nifty.com>


>> (3)kmalloc size is sizeof(*socket)*MAX_SOCKETS.
>
>Ok, the one thing I'm left wondering about is why we kmalloc an array
>of pointers and an array of struct pd6729_socket.
>
>IOW, how about the attached patch (and lets hope everyone can get it
>without their mail client crapping on it...)
>

It works properly.

Thank you.
Komuro


From rmk+pcmcia at arm.linux.org.uk  Sat Jun 19 13:06:31 2004
From: rmk+pcmcia at arm.linux.org.uk (Russell King)
Date: Sat Jun 19 13:06:43 2004
Subject: 2.6.x kernels & PCI-to-PCMCIA bridges [again]
In-Reply-To: <4850364.1087658407607.komujun@nifty.com>;
	from komujun@nifty.com on Sun, Jun 20, 2004 at 12:20:07AM +0900
References: <20040619120713.B26611@flint.arm.linux.org.uk>
	<493051.1087640233594.komujun@nifty.com>
	<20040619120713.B26611@flint.arm.linux.org.uk>
	<4850364.1087658407607.komujun@nifty.com>
Message-ID: <20040619180630.A8063@flint.arm.linux.org.uk>

On Sun, Jun 20, 2004 at 12:20:07AM +0900, komujun@nifty.com wrote:
> >> (3)kmalloc size is sizeof(*socket)*MAX_SOCKETS.
> >
> >Ok, the one thing I'm left wondering about is why we kmalloc an array
> >of pointers and an array of struct pd6729_socket.
> >
> >IOW, how about the attached patch (and lets hope everyone can get it
> >without their mail client crapping on it...)
> >
> 
> It works properly.

Thanks.  I shall be submitting this to Linus tonight.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

From xfesty at computeraddictions.com.au  Sat Jun 19 14:41:45 2004
From: xfesty at computeraddictions.com.au (Ryan Verner)
Date: Sat Jun 19 14:41:50 2004
Subject: "unable to apply power" problem in 2.6.6
Message-ID: <40D488E9.20903@computeraddictions.com.au>

Howdy,

Found the very recent threads here on the "unable to apply power" 
problem under 2.6; need to say "me, too".

I'm trying to configure two Senao 200mW wireless cards, under two Ricoh 
PCMCIA->PCI bridges, on Debian Stable.  I can't get anything to work, 
even under 2.4.

Right now, I'm down to just the one cradle, and I've swapped the 
wireless card with a Orinoco that I know works.  I'm getting various 
errors, though:

 From the dmesg:

Linux Kernel Card Services
   options:  [pci] [cardbus]
PCI: Enabling device 0000:01:04.0 (0000 -> 0002)
PCI: Found IRQ 10 for device 0000:01:04.0
PCI: Sharing IRQ 10 with 0000:00:1d.2
PCI: Sharing IRQ 10 with 0000:00:1f.1
PCI: Sharing IRQ 10 with 0000:00:1f.2
Yenta: CardBus bridge found at 0000:01:04.0 [14ef:0101]
Yenta: ISA IRQ mask 0x0000, PCI irq 10
Socket status: 30000410
cs: pcmcia_socket0: unable to apply power.

In my syslog, I get other errors following this, such as: "cardmgr[433]: 
could not adjust resource: IO ports 0xc00-0xcff: Input/Output error".

And cardctl commands fail:

root@kid[~]# cardctl status
Socket 0:
ioctl(): Input/output error

I've upgraded the pcmcia-cs utilities to the latest, and I'm still 
having the same problems.

My lspci:

00:00.0 Host bridge: Intel Corp.: Unknown device 2570 (rev 02)
00:02.0 VGA compatible controller: Intel Corp.: Unknown device 2572 (rev 02)
00:1d.0 USB Controller: Intel Corp.: Unknown device 24d2 (rev 02)
00:1d.1 USB Controller: Intel Corp.: Unknown device 24d4 (rev 02)
00:1d.2 USB Controller: Intel Corp.: Unknown device 24d7 (rev 02)
00:1d.3 USB Controller: Intel Corp.: Unknown device 24de (rev 02)
00:1d.7 USB Controller: Intel Corp.: Unknown device 24dd (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82820 820 (Camino 2) Chipset PCI (rev c2)
00:1f.0 ISA bridge: Intel Corp.: Unknown device 24d0 (rev 02)
00:1f.1 IDE interface: Intel Corp.: Unknown device 24db (rev 02)
00:1f.2 IDE interface: Intel Corp.: Unknown device 24d1 (rev 02)
00:1f.3 SMBus: Intel Corp.: Unknown device 24d3 (rev 02)
00:1f.5 Multimedia audio controller: Intel Corp.: Unknown device 24d5 
(rev 02)
01:04.0 CardBus bridge: Ricoh Co Ltd RL5c475 (rev 80)
01:08.0 Ethernet controller: Intel Corp.: Unknown device 1050 (rev 01)

Is this a known problem?  Am I just blundering something stupidly?

More importantly, is there a fix available, even as a patch?

Thanks,

R


From xfesty at computeraddictions.com.au  Sat Jun 19 14:53:11 2004
From: xfesty at computeraddictions.com.au (Ryan Verner)
Date: Sat Jun 19 14:53:06 2004
Subject: "unable to apply power" problem in 2.6.6
In-Reply-To: <40D488E9.20903@computeraddictions.com.au>
References: <40D488E9.20903@computeraddictions.com.au>
Message-ID: <40D48B97.9000201@computeraddictions.com.au>

Ryan Verner wrote:

> Howdy,
> 
> Found the very recent threads here on the "unable to apply power" 
> problem under 2.6; need to say "me, too".
> 
> I'm trying to configure two Senao 200mW wireless cards, under two Ricoh 
> PCMCIA->PCI bridges, on Debian Stable.  I can't get anything to work, 
> even under 2.4.

I probably should have posted this with the original email, but under 
2.4, the error is "cs: unable to map card memory!".  I've tried all the 
usual changes to /etc/pcmcia/config.opts but to no avail.

All of the above occurs with both 3.3V/5V PCMCIA/Cardbus cards.

I'm stumped as I'm sure I've used these cradles before in different 
systems; perhaps they are slightly different, I don't know.  The system 
they're in is a recent P4 in an Intel board, FYI; and I've booted 
Knoppix suspecting perhaps a configuration blunder on my part but the 
same issues occur.

More detailed lspci of the cradle:

01:04.0 CardBus bridge: Ricoh Co Ltd RL5c475 (rev 80)
         Subsystem: CARRY Computer ENG. CO Ltd: Unknown device 0101
         Flags: bus master, medium devsel, latency 168, IRQ 18
         Memory at 3f001000 (32-bit, non-prefetchable) [size=4K]
         Bus: primary=01, secondary=02, subordinate=05, sec-latency=176
         Memory window 0: 3f400000-3f7ff000 (prefetchable)
         Memory window 1: 3f800000-3fbff000
         I/O window 0: 00004000-000040ff
         I/O window 1: 00004400-000044ff
         16-bit legacy interface ports at 0001

Any suggestions are *very* appreciated.

R


From xfesty at computeraddictions.com.au  Sat Jun 19 15:14:16 2004
From: xfesty at computeraddictions.com.au (Ryan Verner)
Date: Sat Jun 19 15:14:12 2004
Subject: "unable to apply power" problem in 2.6.6
In-Reply-To: <40D48B97.9000201@computeraddictions.com.au>
References: <40D488E9.20903@computeraddictions.com.au>
	<40D48B97.9000201@computeraddictions.com.au>
Message-ID: <40D49088.8010501@computeraddictions.com.au>

Ryan Verner wrote:

> I probably should have posted this with the original email, but under 
> 2.4, the error is "cs: unable to map card memory!".  I've tried all the 
> usual changes to /etc/pcmcia/config.opts but to no avail.

Last time I reply to myself, promise :-)

Just tried the patch Russell posted against 2.6.6, and compiled a new 
kernel; no difference, same problems. :-(

R



From rmk+pcmcia at arm.linux.org.uk  Sat Jun 19 17:14:10 2004
From: rmk+pcmcia at arm.linux.org.uk (Russell King)
Date: Sat Jun 19 17:14:28 2004
Subject: "unable to apply power" problem in 2.6.6
In-Reply-To: <40D49088.8010501@computeraddictions.com.au>;
	from xfesty@computeraddictions.com.au on Sun, Jun 20, 2004 at
	04:44:16AM +0930
References: <40D488E9.20903@computeraddictions.com.au>
	<40D48B97.9000201@computeraddictions.com.au>
	<40D49088.8010501@computeraddictions.com.au>
Message-ID: <20040619221410.E8063@flint.arm.linux.org.uk>

On Sun, Jun 20, 2004 at 04:44:16AM +0930, Ryan Verner wrote:
> Ryan Verner wrote:
> 
> > I probably should have posted this with the original email, but under 
> > 2.4, the error is "cs: unable to map card memory!".  I've tried all the 
> > usual changes to /etc/pcmcia/config.opts but to no avail.
> 
> Last time I reply to myself, promise :-)
> 
> Just tried the patch Russell posted against 2.6.6, and compiled a new 
> kernel; no difference, same problems. :-(

The patch wasn't designed to specifically fix the problem, but to try
harder to turn the power on and report what was going on.  The kernel
messages from it may provide a hint, but I somehow doubt it from what
you're saying.

It seems that some cardbus controllers just get stuck and refuse point
blankly to enable power to the socket without reporting why they're
refusing to.  At present, I've no idea why they're behaving in that
way.  So far, everything suggests that the CPU side looks fine
_except_ they just won't turn the power on.

(and then there's the converse problem where some controllers decide
they're not going to turn the power off when we ask...)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

From xfesty at computeraddictions.com.au  Sun Jun 20 02:19:53 2004
From: xfesty at computeraddictions.com.au (Ryan Verner)
Date: Sun Jun 20 02:20:22 2004
Subject: "unable to apply power" problem in 2.6.6
In-Reply-To: <20040619221410.E8063@flint.arm.linux.org.uk>
References: <40D488E9.20903@computeraddictions.com.au>
	<40D48B97.9000201@computeraddictions.com.au>
	<40D49088.8010501@computeraddictions.com.au>
	<20040619221410.E8063@flint.arm.linux.org.uk>
Message-ID: <1087712393.5824.2.camel@fluffy>

On Sun, 2004-06-20 at 06:44, Russell King wrote:
> It seems that some cardbus controllers just get stuck and refuse point
> blankly to enable power to the socket without reporting why they're

Ok. maybe I can help here.  I don't think it's the cardbus controller.

I've just taken the cardbus controller and hard drive off the
motherboard it's on (recent Pentium 4 Intel thing), stuck it onto an
older Pentium 3 Intel board, and everything works perfectly in both 2.4
and 2.6.

I've also tried several other Ricoh cardbus controllers (older
revisions) and exactly the same behavour occurs.

I've got things like ACPI disabled in my kernels.

Please tell me what I can do to provide you with more information.  I'd
love to get this bug squashed; I've already ordered a whole heap of
these Intel motherboards for use with these cradles :-(

Thanks,

R



From xfesty at computeraddictions.com.au  Mon Jun 21 08:12:24 2004
From: xfesty at computeraddictions.com.au (Ryan Verner)
Date: Mon Jun 21 08:12:57 2004
Subject: "unable to apply power" problem in 2.6.6
In-Reply-To: <1087712393.5824.2.camel@fluffy>
References: <40D488E9.20903@computeraddictions.com.au>
	<40D48B97.9000201@computeraddictions.com.au>
	<40D49088.8010501@computeraddictions.com.au>
	<20040619221410.E8063@flint.arm.linux.org.uk>
	<1087712393.5824.2.camel@fluffy>
Message-ID: <1087819944.16470.40.camel@fluffy>

On Sun, 2004-06-20 at 15:49, Ryan Verner wrote:
> On Sun, 2004-06-20 at 06:44, Russell King wrote:
> > It seems that some cardbus controllers just get stuck and refuse point
> > blankly to enable power to the socket without reporting why they're
> 
> Ok. maybe I can help here.  I don't think it's the cardbus controller.

Is this list the best place to ask?  I'd really like to help to get this
problem solved; it's certainly causing me problems at the moment (I need
Cardbus working on high powered systems); not being a kernel hacker
myself though, the best I can do is provide information.  At the least,
I'd like to identify what exactly is in the system that's causing the
problem so I can replace whatever the issue is; I'm suspecting the
chipset used in the board, perhaps?

Can you please let me know what I can provide, how I could track down
this issue, or point me in another direction?

Thanks,

R



From rmk+pcmcia at arm.linux.org.uk  Mon Jun 21 08:47:45 2004
From: rmk+pcmcia at arm.linux.org.uk (Russell King)
Date: Mon Jun 21 08:49:16 2004
Subject: "unable to apply power" problem in 2.6.6
In-Reply-To: <1087819944.16470.40.camel@fluffy>;
	from xfesty@computeraddictions.com.au on Mon, Jun 21, 2004 at
	09:42:24PM +0930
References: <40D488E9.20903@computeraddictions.com.au>
	<40D48B97.9000201@computeraddictions.com.au>
	<40D49088.8010501@computeraddictions.com.au>
	<20040619221410.E8063@flint.arm.linux.org.uk>
	<1087712393.5824.2.camel@fluffy> <1087819944.16470.40.camel@fluffy>
Message-ID: <20040621134745.A7802@flint.arm.linux.org.uk>

On Mon, Jun 21, 2004 at 09:42:24PM +0930, Ryan Verner wrote:
> On Sun, 2004-06-20 at 15:49, Ryan Verner wrote:
> > On Sun, 2004-06-20 at 06:44, Russell King wrote:
> > > It seems that some cardbus controllers just get stuck and refuse point
> > > blankly to enable power to the socket without reporting why they're
> > 
> > Ok. maybe I can help here.  I don't think it's the cardbus controller.
> 
> Is this list the best place to ask?  I'd really like to help to get this
> problem solved; it's certainly causing me problems at the moment (I need
> Cardbus working on high powered systems); not being a kernel hacker
> myself though, the best I can do is provide information.  At the least,
> I'd like to identify what exactly is in the system that's causing the
> problem so I can replace whatever the issue is; I'm suspecting the
> chipset used in the board, perhaps?
> 
> Can you please let me know what I can provide, how I could track down
> this issue, or point me in another direction?

Well, this list has David Hinds, myself, Dominik Brodowski and a few
other developers on, which are what you could call "the most active
Linux kernel PCMCIA people" so by that it is the most appropriate
place to ask.

That said, I have other commitments which don't allow me to work full
time on PCMCIA, and Dominik does other stuff as well, so there's little
chance for us to do a deep investigation.

What we really need are more good kernel developers in PCMCIA land who
are willing to look into issues like this - I do suspect that, where
they occur on the x86 architecture, they may be related to other areas
which I certainly have a lack of knowledge (eg, ACPI or BIOS quirks)
since I'm not an x86 guy.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

From xfesty at computeraddictions.com.au  Mon Jun 21 11:42:03 2004
From: xfesty at computeraddictions.com.au (Ryan Verner)
Date: Mon Jun 21 11:42:24 2004
Subject: "unable to apply power" problem in 2.6.6
In-Reply-To: <20040621134745.A7802@flint.arm.linux.org.uk>
References: <40D488E9.20903@computeraddictions.com.au>
	<40D48B97.9000201@computeraddictions.com.au>
	<40D49088.8010501@computeraddictions.com.au>
	<20040619221410.E8063@flint.arm.linux.org.uk>
	<1087712393.5824.2.camel@fluffy> <1087819944.16470.40.camel@fluffy>
	<20040621134745.A7802@flint.arm.linux.org.uk>
Message-ID: <1087832522.19102.9.camel@fluffy>

On Mon, 2004-06-21 at 22:17, Russell King wrote:
> Well, this list has David Hinds, myself, Dominik Brodowski and a few
> other developers on, which are what you could call "the most active
> Linux kernel PCMCIA people" so by that it is the most appropriate
> place to ask.

Ok, excellent.

> That said, I have other commitments which don't allow me to work full
> time on PCMCIA, and Dominik does other stuff as well, so there's little
> chance for us to do a deep investigation.

Understand.  I know exactly what it's like to be busy, believe me - and
this is after all completely voluntary work on your part.  Thanks for
all the work you've done so far to get us to where we are, btw :-)

> What we really need are more good kernel developers in PCMCIA land who
> are willing to look into issues like this - I do suspect that, where
> they occur on the x86 architecture, they may be related to other areas
> which I certainly have a lack of knowledge (eg, ACPI or BIOS quirks)
> since I'm not an x86 guy.

I'n not ordinarily an x86 guy, either; and again, certainly not a kernel
hacker.

I'd really appreciate some kind of pointer, though; in short, I'm in
deep mud right now as I blindly thought that the cardbus controller
would work fine with the Intel board, and I have a whole heap of them at
the moment for a rather large project I'm undertaking (the software is
80% developed but now we've run into hardware problems).  D'oh.

A resort, is, of course, to order different hardware, but I'm at a loss
as to identify what exactly is causing the cardbus controller to have
such problems (if it's the motherboard, I'm not sure what we order
*differently*).  I believe these motherboards are the latest high end
Intel desktop motherboards, currently, so I'd imagine this problem is
probably going to increase.

Appreciate your time in this; I'm wanting to do whatever I can within my
power/ability to at least get a feel for what the problem is.  If you've
got time to help and need root ssh access to the machine in question, I
can organise that in a flash.

R



From lloyd at passcal.nmt.edu  Mon Jun 21 17:38:38 2004
From: lloyd at passcal.nmt.edu (Lloyd Carothers)
Date: Mon Jun 21 17:38:59 2004
Subject: buffer I/O error, trying to use SimpleTech compact flash via pcmcia
Message-ID: <1087853918.1258.16.camel@firestorm.passcal.nmt.edu>

hi,

The following info was generated on an IBM A31 laptop with kernel
2.6.5-1.358 trying to use a SimpleTech 1GB Compact Flash ATA card with a
pcmcia adapter

I get very similar results with 2.4 kernels and the 2.6.7 kernels and on
other laptops including IBM T41.

The only time I have be able to use this card is with the 2.4.20 kernel
and the pcmcia-cs package utilities, not drivers installed.

Also, I am able to use similar cards with out problems including IBM's
microdrives, SanDisks compact flash 1 and 1GB cards, and Kingston
technology 32MB cards.

I would be willing to ship off a couple of these cards to the
maintainers if 
they request so.

Below are label outputs from dmesg ,cardctl , lspci -v and  what
/var/log/messages gets on insert and ejection of the card.

thanks
--Lloyd

cardctl status:
===========================================
Socket 0:
  3.3V 16-bit PC Card
  function 0: [ready], [bat dead], [bat low]
Socket 1:
  no card

dmesg:
=============================================
hdc: packet command error: status=0x51 { DriveReady SeekComplete Error }
hdc: packet command error: error=0x54
cdrom: open failed.
Adding 2519488k swap on /dev/hda2.  Priority:-1 extents:1
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
parport0: PC-style at 0x3bc [PCSPP,TRISTATE]
SCSI subsystem initialized
inserting floppy driver for 2.6.5-1.358
Floppy drive(s): fd0 is 1.44M
FDC 0 is a National Semiconductor PC87306
e100: Intel(R) PRO/100 Network Driver, 3.0.17
e100: Copyright(c) 1999-2004 Intel Corporation
divert: allocating divert_blk for eth0
e100: eth0: e100_probe: addr 0xd0200000, irq 11, MAC addr
00:02:8A:35:85:5B
divert: freeing divert_blk for eth0
ip_tables: (C) 2000-2002 Netfilter core team
e100: Intel(R) PRO/100 Network Driver, 3.0.17
e100: Copyright(c) 1999-2004 Intel Corporation
divert: allocating divert_blk for eth0
e100: eth0: e100_probe: addr 0xd0200000, irq 11, MAC addr
00:02:8A:35:85:5B
ip_tables: (C) 2000-2002 Netfilter core team
Linux Kernel Card Services
  options:  [pci] [cardbus] [pm]
Yenta: CardBus bridge found at 0000:02:00.0 [1014:0185]
Yenta: ISA IRQ mask 0x04b8, PCI irq 11
Socket status: 30000006
Yenta: CardBus bridge found at 0000:02:00.1 [1014:0185]
Yenta: ISA IRQ mask 0x04b8, PCI irq 11
Socket status: 30000006
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x3b8-0x3df 0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 1x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 1x mode
PCI: Setting latency timer of device 0000:00:1f.5 to 64
intel8x0_measure_ac97_clock: measured 78379 usecs
intel8x0: clocking to 48000
cs: memory probe 0xa0000000-0xa0ffffff: clean.
hde: STI Flash S.1.0, CFA DISK drive
ide2 at 0x100-0x107,0x10e on irq 3
hde: max request size: 128KiB
hde: 2002896 sectors (1025 MB) w/1KiB Cache, CHS=1987/16/63
 hde:hde: status error: status=0x20 { DeviceFault }

On insert:
==============================================
Jun 21 13:08:35 localhost cardmgr[1948]: socket 0: ATA/IDE Fixed Disk
Jun 21 13:08:36 localhost kernel: hde: STI Flash S.1.0, CFA DISK drive
Jun 21 13:08:36 localhost kernel: ide2 at 0x100-0x107,0x10e on irq 3
Jun 21 13:08:36 localhost kernel: hde: max request size: 128KiB
Jun 21 13:08:36 localhost kernel: hde: 2002896 sectors (1025 MB) w/1KiB
Cache, CHS=1987/16/63
Jun 21 13:08:36 localhost kernel:  hde:hde: status error: status=0x20 {
DeviceFault }
Jun 21 13:08:36 localhost kernel: 
Jun 21 13:08:36 localhost kernel: hde: drive not ready for command
Jun 21 13:08:36 localhost udev[3304]: creating device node '/udev/hde'
Jun 21 13:08:36 localhost kernel: ide2: reset: success
Jun 21 13:08:36 localhost kernel: hde: status error: status=0x20 {
DeviceFault }
Jun 21 13:08:36 localhost kernel: 
Jun 21 13:08:36 localhost kernel: hde: drive not ready for command
Jun 21 13:08:36 localhost kernel: ide2: reset: success
Jun 21 13:08:36 localhost kernel: hde: status error: status=0x20 {
DeviceFault }
Jun 21 13:08:37 localhost kernel: 
Jun 21 13:08:37 localhost kernel: end_request: I/O error, dev hde,
sector 0
Jun 21 13:08:37 localhost kernel: Buffer I/O error on device hde,
logical block 0
Jun 21 13:08:37 localhost kernel: hde: drive not ready for command
Jun 21 13:08:37 localhost kernel: hde: status error: status=0x20 {
DeviceFault }
Jun 21 13:08:37 localhost kernel: 
Jun 21 13:08:37 localhost kernel: hde: drive not ready for command
Jun 21 13:08:37 localhost kernel: ide2: reset: success
Jun 21 13:08:37 localhost kernel: hde: status error: status=0x20 {
DeviceFault }
Jun 21 13:08:37 localhost kernel: 
Jun 21 13:08:37 localhost kernel: hde: drive not ready for command
Jun 21 13:08:37 localhost kernel: ide2: reset: success
Jun 21 13:08:37 localhost kernel: hde: status error: status=0x20 {
DeviceFault }
Jun 21 13:08:37 localhost kernel: 
Jun 21 13:08:37 localhost kernel: end_request: I/O error, dev hde,
sector 0
Jun 21 13:08:37 localhost kernel: Buffer I/O error on device hde,
logical block 0
Jun 21 13:08:37 localhost kernel: hde: drive not ready for command
Jun 21 13:08:37 localhost kernel: hde: status error: status=0x20 {
DeviceFault }
Jun 21 13:08:37 localhost kernel: 
Jun 21 13:08:37 localhost kernel: hde: drive not ready for command
Jun 21 13:08:37 localhost kernel: ide2: reset: success
Jun 21 13:08:37 localhost kernel: hde: status error: status=0x20 {
DeviceFault }
Jun 21 13:08:37 localhost kernel: 
Jun 21 13:08:37 localhost kernel: hde: drive not ready for command
Jun 21 13:08:37 localhost kernel: ide2: reset: success
Jun 21 13:08:37 localhost kernel: hde: status error: status=0x20 {
DeviceFault }
Jun 21 13:08:37 localhost kernel: 
Jun 21 13:08:37 localhost kernel: end_request: I/O error, dev hde,
sector 2002888
Jun 21 13:08:37 localhost kernel: Buffer I/O error on device hde,
logical block 250361
Jun 21 13:08:37 localhost kernel: hde: drive not ready for command
Jun 21 13:08:37 localhost kernel: hde: status error: status=0x20 {
DeviceFault }
Jun 21 13:08:37 localhost kernel: 
Jun 21 13:08:37 localhost kernel: hde: drive not ready for command
Jun 21 13:08:37 localhost kernel: ide2: reset: success
Jun 21 13:08:37 localhost kernel: hde: status error: status=0x20 {
DeviceFault }
Jun 21 13:08:37 localhost kernel: 
Jun 21 13:08:37 localhost kernel: hde: drive not ready for command
Jun 21 13:08:37 localhost kernel: ide2: reset: success
Jun 21 13:08:37 localhost kernel: hde: status error: status=0x20 {
DeviceFault }
Jun 21 13:08:37 localhost kernel: 
Jun 21 13:08:37 localhost kernel: end_request: I/O error, dev hde,
sector 2002888
Jun 21 13:08:37 localhost kernel: Buffer I/O error on device hde,
logical block 250361
Jun 21 13:08:37 localhost kernel: hde: drive not ready for command
Jun 21 13:08:37 localhost kernel: hde: status error: status=0x20 {
DeviceFault }
Jun 21 13:08:37 localhost kernel: 
Jun 21 13:08:37 localhost kernel: hde: drive not ready for command
Jun 21 13:08:37 localhost kernel: ide2: reset: success
Jun 21 13:08:37 localhost kernel: hde: status error: status=0x20 {
DeviceFault }
Jun 21 13:08:37 localhost kernel: 
Jun 21 13:08:37 localhost kernel: hde: drive not ready for command
Jun 21 13:08:37 localhost kernel: ide2: reset: success
Jun 21 13:08:37 localhost kernel: hde: status error: status=0x20 {
DeviceFault }
Jun 21 13:08:37 localhost kernel: 
Jun 21 13:08:37 localhost kernel: end_request: I/O error, dev hde,
sector 0
Jun 21 13:08:37 localhost kernel: Buffer I/O error on device hde,
logical block 0
Jun 21 13:08:37 localhost kernel: hde: drive not ready for command
Jun 21 13:08:37 localhost kernel:  unable to read partition table
Jun 21 13:08:37 localhost kernel: ide-cs: hde: Vcc = 3.3, Vpp = 0.0
Jun 21 13:08:37 localhost kernel: hde: status error: status=0x20 {
DeviceFault }
Jun 21 13:08:37 localhost kernel: 
Jun 21 13:08:37 localhost kernel: hde: drive not ready for command
Jun 21 13:08:37 localhost kernel: hde: status error: status=0x20 {
DeviceFault }
Jun 21 13:08:37 localhost kernel: 
Jun 21 13:08:38 localhost kernel: hde: drive not ready for command

On eject
=================================================
Jun 21 14:00:19 localhost kernel: hde: status error: status=0x20 {
DeviceFault }
Jun 21 14:00:19 localhost kernel: 
Jun 21 14:00:19 localhost kernel: hde: drive not ready for command
Jun 21 14:00:19 localhost kernel: hde: status error: status=0x20 {
DeviceFault }
Jun 21 14:00:19 localhost kernel: 
Jun 21 14:00:19 localhost kernel: hde: drive not ready for command
Jun 21 14:00:19 localhost kernel: hde: status error: status=0x20 {
DeviceFault }
Jun 21 14:00:19 localhost kernel: 
Jun 21 14:00:19 localhost kernel: hde: drive not ready for command
Jun 21 14:00:19 localhost kernel: hde: status error: status=0x20 {
DeviceFault }
Jun 21 14:00:19 localhost kernel: 
Jun 21 14:00:19 localhost kernel: hde: drive not ready for command
Jun 21 14:00:22 localhost udev[4445]: removing device node '/udev/hde'



lspci -v output
================================================

00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host
Bridge (rev 04)
	Flags: bus master, fast devsel, latency 0
	Memory at e0000000 (32-bit, prefetchable)
	Capabilities: [e4] #09 [d104]
	Capabilities: [a0] AGP version 2.0

00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge
(rev 04) (prog-if 00 [Normal decode])
	Flags: bus master, 66Mhz, fast devsel, latency 96
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
	I/O behind bridge: 00003000-00003fff
	Memory behind bridge: d0100000-d01fffff
	Prefetchable memory behind bridge: e8000000-efffffff
	Expansion ROM at 00003000 [disabled] [size=4K]

00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 02)
(prog-if 00 [UHCI])
	Subsystem: IBM ThinkPad A/T/X Series
	Flags: bus master, medium devsel, latency 0, IRQ 11
	I/O ports at 1800 [size=32]

00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #2) (rev 02)
(prog-if 00 [UHCI])
	Subsystem: IBM ThinkPad A/T/X Series
	Flags: bus master, medium devsel, latency 0, IRQ 11
	I/O ports at 1820 [size=32]

00:1d.2 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #3) (rev 02)
(prog-if 00 [UHCI])
	Subsystem: IBM ThinkPad A/T/X Series
	Flags: bus master, medium devsel, latency 0, IRQ 11
	I/O ports at 1840 [size=32]

00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 42)
(prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=02, subordinate=08, sec-latency=64
	I/O behind bridge: 00004000-00008fff
	Memory behind bridge: d0200000-dfffffff
	Prefetchable memory behind bridge: f0000000-f7ffffff

00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 02)
	Flags: bus master, medium devsel, latency 0

00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02) (prog-if
8a [Master SecP PriP])
	Subsystem: IBM ThinkPad A/T/X Series
	Flags: bus master, medium devsel, latency 0, IRQ 11
	I/O ports at <ignored>
	I/O ports at <ignored>
	I/O ports at <ignored>
	I/O ports at <ignored>
	I/O ports at 1860 [size=16]
	Memory at 10000000 (32-bit, non-prefetchable) [size=1K]

00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus Controller (rev 02)
	Subsystem: IBM ThinkPad A/T/X Series
	Flags: medium devsel, IRQ 11
	I/O ports at 1880 [size=32]

00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 Audio
Controller (rev 02)
	Subsystem: IBM ThinkPad T30
	Flags: bus master, medium devsel, latency 0, IRQ 11
	I/O ports at 1c00
	I/O ports at 18c0 [size=64]

00:1f.6 Modem: Intel Corp. 82801CA/CAM AC'97 Modem Controller (rev 02)
(prog-if 00 [Generic])
	Subsystem: IBM ThinkPad A/T/X Series
	Flags: medium devsel, IRQ 11
	I/O ports at 2400
	I/O ports at 2000 [size=128]

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility
M7 LW [Radeon Mobility 7500] (prog-if 00 [VGA])
	Subsystem: IBM: Unknown device 0509
	Flags: bus master, stepping, fast Back2Back, 66Mhz, medium devsel,
latency 66, IRQ 11
	Memory at e8000000 (32-bit, prefetchable)
	I/O ports at 3000 [size=256]
	Memory at d0100000 (32-bit, non-prefetchable) [size=64K]
	Capabilities: [58] AGP version 2.0
	Capabilities: [50] Power Management version 2

02:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80)
	Subsystem: IBM ThinkPad A/T/X Series
	Flags: bus master, medium devsel, latency 168, IRQ 11
	Memory at 50000000 (32-bit, non-prefetchable)
	Bus: primary=02, secondary=03, subordinate=06, sec-latency=176
	Memory window 0: 10400000-107ff000 (prefetchable)
	Memory window 1: 10800000-10bff000
	I/O window 0: 00004000-000040ff
	I/O window 1: 00004400-000044ff
	16-bit legacy interface ports at 0001

02:00.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80)
	Subsystem: IBM ThinkPad A/T/X Series
	Flags: bus master, medium devsel, latency 168, IRQ 11
	Memory at 50100000 (32-bit, non-prefetchable)
	Bus: primary=02, secondary=07, subordinate=0a, sec-latency=176
	Memory window 0: 10c00000-10fff000 (prefetchable)
	Memory window 1: 11000000-113ff000
	I/O window 0: 00004800-000048ff
	I/O window 1: 00004c00-00004cff
	16-bit legacy interface ports at 0001

02:08.0 Ethernet controller: Intel Corp. 82801CAM (ICH3) PRO/100 VE
(LOM) Ethernet Controller (rev 42)
	Subsystem: IBM ThinkPad A/T/X Series
	Flags: bus master, medium devsel, latency 66, IRQ 11
	Memory at d0200000 (32-bit, non-prefetchable)
	I/O ports at 8000 [size=64]
	Capabilities: [dc] Power Management version 2




From lloyd at passcal.nmt.edu  Mon Jun 21 18:19:02 2004
From: lloyd at passcal.nmt.edu (Lloyd Carothers)
Date: Mon Jun 21 18:19:07 2004
Subject: buffer I/O error, trying to use SimpleTech compact flash via
	pcmcia
In-Reply-To: <1087853918.1258.16.camel@firestorm.passcal.nmt.edu>
References: <1087853918.1258.16.camel@firestorm.passcal.nmt.edu>
Message-ID: <1087856342.1258.20.camel@firestorm.passcal.nmt.edu>

Also,
	This card worked fine using a firewire card reader
--Lloyd


From rmk+pcmcia at arm.linux.org.uk  Mon Jun 21 19:36:39 2004
From: rmk+pcmcia at arm.linux.org.uk (Russell King)
Date: Mon Jun 21 19:36:47 2004
Subject: buffer I/O error,
	trying to use SimpleTech compact flash via pcmcia
In-Reply-To: <1087853918.1258.16.camel@firestorm.passcal.nmt.edu>;
	from lloyd@passcal.nmt.edu on Mon, Jun 21, 2004 at 03:38:38PM
	-0600
References: <1087853918.1258.16.camel@firestorm.passcal.nmt.edu>
Message-ID: <20040622003639.C7802@flint.arm.linux.org.uk>

On Mon, Jun 21, 2004 at 03:38:38PM -0600, Lloyd Carothers wrote:
> The following info was generated on an IBM A31 laptop with kernel
> 2.6.5-1.358 trying to use a SimpleTech 1GB Compact Flash ATA card with a
> pcmcia adapter

I'd suggest posting this to the linux-ide mailing list rather than the
PCMCIA list - I don't think this is specific to PCMCIA itself.

(All PCMCIA does in this is tell the IDE layer where the CF ATA
interface is in the system, and lets the IDE layer get on with the
business of actually talking to it.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

From lloyd at passcal.nmt.edu  Mon Jun 21 19:53:57 2004
From: lloyd at passcal.nmt.edu (Lloyd Carothers)
Date: Mon Jun 21 19:54:17 2004
Subject: buffer I/O error, trying to use SimpleTech compact flash via
	pcmcia
In-Reply-To: <20040622003639.C7802@flint.arm.linux.org.uk>
References: <1087853918.1258.16.camel@firestorm.passcal.nmt.edu>
	<20040622003639.C7802@flint.arm.linux.org.uk>
Message-ID: <1087862037.2920.0.camel@firestorm.passcal.nmt.edu>

> I'd suggest posting this to the linux-ide mailing list rather than the
> PCMCIA list - I don't think this is specific to PCMCIA itself.

thanks I'll try them
--Lloyd


From edwardh312 at yahoo.com.tw  Tue Jun 22 21:45:55 2004
From: edwardh312 at yahoo.com.tw (=?big5?q?=20=20=20?=)
Date: Tue Jun 22 21:46:03 2004
Subject: R5C485 (PCI bus) driver for linux kernel 2.6.7
Message-ID: <20040623014555.24042.qmail@web16608.mail.tpe.yahoo.com>

Dear All,

    Where could I get the PCMCIA device driver for
Ricoh R5C485 PCMCIA controller (PCI bus) for linux
kernel 2.6.7? My linux kernel version is 2.6.7. I
cannot use pcmcia-cs 3.2.7 anymore. It seems only for
linux kernel 2.4. I also tried to find out R5C485
driver from linux-2.6.7/drivers/pcmcia but I failed
unfortunately. It only included i82365 device driver
for ISA bus. Do I still need cardmgr program in
pcmcia-cs package? Any comments are very appreciated.

Thanks,
Edward

-----------------------------------------------------------------
Yahoo!©_¼¯Messenger6.0
«H½c·f°t§Y®É³q, ·¾³q¼Ö½ìµL½a! 
http://tw.messenger.yahoo.com/

From linux at dominikbrodowski.de  Wed Jun 23 02:49:10 2004
From: linux at dominikbrodowski.de (Dominik Brodowski)
Date: Wed Jun 23 03:04:19 2004
Subject: R5C485 (PCI bus) driver for linux kernel 2.6.7
In-Reply-To: <20040623014555.24042.qmail@web16608.mail.tpe.yahoo.com>
References: <20040623014555.24042.qmail@web16608.mail.tpe.yahoo.com>
Message-ID: <20040623064910.GA8171@dominikbrodowski.de>

On Wed, Jun 23, 2004 at 09:45:55AM +0800,     wrote:
> Dear All,
> 
>     Where could I get the PCMCIA device driver for
> Ricoh R5C485 PCMCIA controller (PCI bus) for linux
> kernel 2.6.7? My linux kernel version is 2.6.7. I
> cannot use pcmcia-cs 3.2.7 anymore. It seems only for
> linux kernel 2.4.

What driver do you use in pcmcia-cs 3.2.7 / 2.4.kernel for that PCMCIA
controller you specified?

	Dominik

From rmk+pcmcia at arm.linux.org.uk  Wed Jun 23 04:51:11 2004
From: rmk+pcmcia at arm.linux.org.uk (Russell King)
Date: Wed Jun 23 04:51:28 2004
Subject: PCMCIA in 2.6.7-mm1
Message-ID: <20040623095111.A21444@flint.arm.linux.org.uk>

Hi,

I'd just like to check whether anyone has tested PCMCIA in 2.6.7-mm1 yet?
It has PD6729 merged, and a few other bits from my 12-pcmcia-resource-2
patch series.

Thanks.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

From rmk+pcmcia at arm.linux.org.uk  Wed Jun 23 07:20:36 2004
From: rmk+pcmcia at arm.linux.org.uk (Russell King)
Date: Wed Jun 23 07:20:45 2004
Subject: 2.6.x kernels & PCI-to-PCMCIA bridges [again]
In-Reply-To: <20040619180630.A8063@flint.arm.linux.org.uk>;
	from rmk+pcmcia@arm.linux.org.uk on Sat, Jun 19, 2004 at
	06:06:31PM +0100
References: <20040619120713.B26611@flint.arm.linux.org.uk>
	<493051.1087640233594.komujun@nifty.com>
	<20040619120713.B26611@flint.arm.linux.org.uk>
	<4850364.1087658407607.komujun@nifty.com>
	<20040619180630.A8063@flint.arm.linux.org.uk>
Message-ID: <20040623122036.A26805@flint.arm.linux.org.uk>

On Sat, Jun 19, 2004 at 06:06:31PM +0100, Russell King wrote:
> On Sun, Jun 20, 2004 at 12:20:07AM +0900, komujun@nifty.com wrote:
> > >> (3)kmalloc size is sizeof(*socket)*MAX_SOCKETS.
> > >
> > >Ok, the one thing I'm left wondering about is why we kmalloc an array
> > >of pointers and an array of struct pd6729_socket.
> > >
> > >IOW, how about the attached patch (and lets hope everyone can get it
> > >without their mail client crapping on it...)
> > >
> > 
> > It works properly.
> 
> Thanks.  I shall be submitting this to Linus tonight.

PS, could I have a patch to add a MODULE_AUTHOR line to the version in
2.6.7-mm1 please?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

From komujun at nifty.com  Wed Jun 23 11:12:47 2004
From: komujun at nifty.com (komujun@nifty.com)
Date: Wed Jun 23 11:19:42 2004
Subject: [KERNEL 2.6.7]  fix "cs: unable to map card memory!" problem
Message-ID: <4298296.1088003567189.komujun@nifty.com>

Dear all

find_mem_region in rsrc_mgr.c calls allocate_resource with align=0.
bogus value is loaded, then causes "cs: unable to map card memory" problem.

>        ret = allocate_resource(&iomem_resource, res, num, min,
			max, 0, pcmcia_align, &data);

Following patch fixes this problem.

Best Regards
Komuro

--- linux/kernel/resource.c.orig	2004-06-23 23:09:58.000000000 +0900
+++ linux/kernel/resource.c	2004-06-23 23:10:38.000000000 +0900
@@ -261,7 +261,8 @@
 			new->start = min;
 		if (new->end > max)
 			new->end = max;
-		new->start = (new->start + align - 1) & ~(align - 1);
+		if (align != 0)
+			new->start = (new->start + align - 1) & ~(align - 1);
 		if (alignf)
 			alignf(alignf_data, new, size, align);
 		if (new->start < new->end && new->end - new->start + 1 >= size) {


From xfesty at computeraddictions.com.au  Wed Jun 23 11:20:38 2004
From: xfesty at computeraddictions.com.au (Ryan Verner)
Date: Wed Jun 23 11:20:33 2004
Subject: "unable to apply power" problem in 2.6.6
In-Reply-To: <20040621203849.GA8212@dominikbrodowski.de>
References: <1087819944.16470.40.camel@fluffy>
	<20040621134745.A7802@flint.arm.linux.org.uk>
	<40D488E9.20903@computeraddictions.com.au>
	<40D48B97.9000201@computeraddictions.com.au>
	<40D49088.8010501@computeraddictions.com.au>
	<20040619221410.E8063@flint.arm.linux.org.uk>
	<1087712393.5824.2.camel@fluffy> <1087819944.16470.40.camel@fluffy>
	<20040621134745.A7802@flint.arm.linux.org.uk>
	<1087832522.19102.9.camel@fluffy>
	<20040621203849.GA8212@dominikbrodowski.de>
Message-ID: <40D99FC6.40200@computeraddictions.com.au>

Dominik Brodowski wrote:
> On Tue, Jun 22, 2004 at 01:12:03AM +0930, Ryan Verner wrote:
> 
>>>since I'm not an x86 guy.
>>
>>I'n not ordinarily an x86 guy
> 
> 
> Well, I _am_ an x86 guy in the form of only having x86 hardware available...
> and maybe I can spare a few minutes in the next days, but possibly only next
> week... A few things you could provide to me:

Hi,

Thanks for your reply - keen as ever to get this sorted out.  Apologies 
I didn't get back to you yesterday - insane day :-(

> 
> a) cbdump output [Russell's program at http://pcmcia.arm.linux.org.uk ]
> _before_ yenta_socket is loaded

http://mail.catstick.com/pcmcia/before.txt

> b) _after_ yenta_socket is loaded with _no_ card inserted

http://mail.catstick.com/pcmcia/after.txt

> c) _after_ yenta_socket is loaded with a card inserted

http://mail.catstick.com/pcmcia/after-withcard.txt

> d) complete dmesg, possibly with DEBUG enabled in drivers/pcmcia/cs.c and
>    drivers/pcmcia/yenta_socket.c

http://mail.catstick.com/pcmcia/dmesg.txt

Note, this is without DEBUG enabled; I'll recompile my kernel in a 
minute and post results with it enabled.

More detailed error at:

http://mail.catstick.com/pcmcia/syslog-withcard.txt

> e) information on the card concerned: is it a PCMCIA card, or a Cardbus
>    card?

The particular card I am trying is a Senao 200mW 16-bit PCMCIA card, 
more information at:

http://www.seattlewireless.net/index.cgi/SenaoCard

It's not just this card, though; it happens with other cards I have, too 
(i.e. 16-bit Orinoco card).  I believe one card is 3.3V, and the other 
is 5V, but I can't recall which is which.

Also note that the same cards, with the same cardbus controller, with 
the same hard drive (i.e. userland/configuration/tools) work flawlessly 
on a different motherboard.

> And a few things you could try:
> 
> 1) Does it work on a different board, e.g. when booting Knoppix on it?

Yes, it works on another board.  No, it does not work on the same board 
with Knoppix.

> 2) increase the delays in pcmcia_core by passing module parameters to this
>    module: most importantly, setup_delay and vcc_settle.

Ok, I'll toy with this; not sure exactly what I should set them to, though.

> 
> I hope we'll be able to solve this issue,

Me too, thanks for your help :-)

R

> 	Dominik
> 


From rmk+pcmcia at arm.linux.org.uk  Wed Jun 23 11:41:04 2004
From: rmk+pcmcia at arm.linux.org.uk (Russell King)
Date: Wed Jun 23 11:41:14 2004
Subject: [KERNEL 2.6.7]  fix "cs: unable to map card memory!" problem
In-Reply-To: <4298296.1088003567189.komujun@nifty.com>;
	from komujun@nifty.com on Thu, Jun 24, 2004 at 12:12:47AM +0900
References: <4298296.1088003567189.komujun@nifty.com>
Message-ID: <20040623164104.D27549@flint.arm.linux.org.uk>

On Thu, Jun 24, 2004 at 12:12:47AM +0900, komujun@nifty.com wrote:
> find_mem_region in rsrc_mgr.c calls allocate_resource with align=0.
> bogus value is loaded, then causes "cs: unable to map card memory" problem.

Hmm, I'm wondering how we ended up with stuff working with align = 0.
It should actually be '1'.

Something else to be merged _post_ 12-pcmcia-resource-2 (can't be
merged beforehand because this series is already half-merged and
I'm not going to strip my tree down, _especially_ as various people
have already pulled csets from it.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

From xfesty at computeraddictions.com.au  Wed Jun 23 11:42:54 2004
From: xfesty at computeraddictions.com.au (Ryan Verner)
Date: Wed Jun 23 11:42:43 2004
Subject: "unable to apply power" problem in 2.6.6
In-Reply-To: <40D99FC6.40200@computeraddictions.com.au>
References: <1087819944.16470.40.camel@fluffy>	<20040621134745.A7802@flint.arm.linux.org.uk>	<40D488E9.20903@computeraddictions.com.au>	<40D48B97.9000201@computeraddictions.com.au>	<40D49088.8010501@computeraddictions.com.au>	<20040619221410.E8063@flint.arm.linux.org.uk>	<1087712393.5824.2.camel@fluffy>
	<1087819944.16470.40.camel@fluffy>	<20040621134745.A7802@flint.arm.linux.org.uk>	<1087832522.19102.9.camel@fluffy>	<20040621203849.GA8212@dominikbrodowski.de>
	<40D99FC6.40200@computeraddictions.com.au>
Message-ID: <40D9A4FE.9090403@computeraddictions.com.au>

Just to follow myself up, recompiled with debug, and syslog now states:

Jun 23 23:42:51 ap kernel: Linux Kernel Card Services
Jun 23 23:42:51 ap kernel:   options:  [pci] [cardbus]
Jun 23 23:42:55 ap kernel: Yenta: CardBus bridge found at 0000:01:01.0 
[14ef:0101]
Jun 23 23:42:55 ap kernel: Yenta: ISA IRQ mask 0x0000, PCI irq 22
Jun 23 23:42:55 ap kernel: Socket status: 30000810
Jun 23 23:42:55 ap kernel: cs: : pcmcia_register_socket(0xf88df780)
Jun 23 23:42:55 ap kernel: cs: pcmcia_socket0: parse_events: events 00000080
Jun 23 23:42:55 ap kernel: cs: pcmcia_socket0: insert
Jun 23 23:42:55 ap kernel: cs: pcmcia_socket0: setup
Jun 23 23:42:55 ap kernel: cs: pcmcia_socket0: unable to apply power.
Jun 23 23:42:56 ap last message repeated 2 times
Jun 23 23:42:56 ap kernel: cs: pcmcia_socket0: shutdown
Jun 23 23:42:56 ap kernel: cs: pcmcia_socket0: remove_drivers
Jun 23 23:42:56 ap kernel: cs: pcmcia_socket0: send_event(event 8, pri 1)
Jun 23 23:42:57 ap kernel: cs: pcmcia_socket0: shutdown_socket

Note, this is also with your patch applied that attempts to set power 
three times.  As you can see, it's not working.

All I know now is that I'm even more confused :-)

Appreciate your help,

R

From proski at gnu.org  Wed Jun 23 11:15:53 2004
From: proski at gnu.org (Pavel Roskin)
Date: Wed Jun 23 11:52:32 2004
Subject: R5C485 (PCI bus) driver for linux kernel 2.6.7
In-Reply-To: <20040623014555.24042.qmail@web16608.mail.tpe.yahoo.com>
References: <20040623014555.24042.qmail@web16608.mail.tpe.yahoo.com>
Message-ID: <Pine.LNX.4.60.0406231107080.3515@marabou.research.att.com>

On Wed, 23 Jun 2004, [big5]     wrote:

>    Where could I get the PCMCIA device driver for Ricoh R5C485 PCMCIA 
> controller (PCI bus) for linux kernel 2.6.7? My linux kernel version is 
> 2.6.7. I cannot use pcmcia-cs 3.2.7 anymore. It seems only for linux 
> kernel 2.4. I also tried to find out R5C485 driver from 
> linux-2.6.7/drivers/pcmcia but I failed unfortunately. It only included 
> i82365 device driver for ISA bus. Do I still need cardmgr program in 
> pcmcia-cs package? Any comments are very appreciated.

You still need cardmgr from pcmcia-cs.  When compiling pcmcia-cs, only the 
utilities will be compiled, but not the drivers.  That's OK.

The driver is in the Linux kernel.  You need to enable CardBus support in 
the kernel configuration to enable compiling the driver.  If you compile 
PCMCIA support as a module, the module will be called yenta_socket. 
You'll also need the "ds" module loaded before you run cardmgr.

If you have any problems with compiling user-space utilities in pcmcia-cs 
try the latest beta version from http://pcmcia-cs.sourceforge.net/ftp/NEW/ 
If the problem persist please describe it in details.  Error messages from 
Configure (or "make config") can be ignored if the script finishes 
successfully.

-- 
Regards,
Pavel Roskin

From proski at gnu.org  Wed Jun 23 12:11:41 2004
From: proski at gnu.org (Pavel Roskin)
Date: Wed Jun 23 12:10:21 2004
Subject: [KERNEL 2.6.7]  fix "cs: unable to map card memory!" problem
In-Reply-To: <20040623164104.D27549@flint.arm.linux.org.uk>
References: <4298296.1088003567189.komujun@nifty.com>
	<20040623164104.D27549@flint.arm.linux.org.uk>
Message-ID: <Pine.LNX.4.60.0406231206180.1676@marabou.research.att.com>

Hi, Russell!

On Wed, 23 Jun 2004, Russell King wrote:

> On Thu, Jun 24, 2004 at 12:12:47AM +0900, komujun@nifty.com wrote:
>> find_mem_region in rsrc_mgr.c calls allocate_resource with align=0.
>> bogus value is loaded, then causes "cs: unable to map card memory" problem.
>
> Hmm, I'm wondering how we ended up with stuff working with align = 0.
> It should actually be '1'.
>
> Something else to be merged _post_ 12-pcmcia-resource-2 (can't be
> merged beforehand because this series is already half-merged and
> I'm not going to strip my tree down, _especially_ as various people
> have already pulled csets from it.)

I'll appreciate if you also reconsider using static variables in both 
variants of validate_mem() in drivers/pcmcia/rsrc_mgr.c.  The can cause 
the same error message when cardmgr is restarted.

The original message didn't describe the problem in details.  It's 
possible that the actual problem was in validate_mem().  For that to be 
the case, the problem would not appear initially after reboot or after 
pcmcia_core is reloaded.

-- 
Regards,
Pavel Roskin

From rmk+pcmcia at arm.linux.org.uk  Wed Jun 23 12:13:37 2004
From: rmk+pcmcia at arm.linux.org.uk (Russell King)
Date: Wed Jun 23 12:13:46 2004
Subject: [KERNEL 2.6.7]  fix "cs: unable to map card memory!" problem
In-Reply-To: <Pine.LNX.4.60.0406231206180.1676@marabou.research.att.com>;
	from proski@gnu.org on Wed, Jun 23, 2004 at 12:11:41PM -0400
References: <4298296.1088003567189.komujun@nifty.com>
	<20040623164104.D27549@flint.arm.linux.org.uk>
	<Pine.LNX.4.60.0406231206180.1676@marabou.research.att.com>
Message-ID: <20040623171337.G27549@flint.arm.linux.org.uk>

On Wed, Jun 23, 2004 at 12:11:41PM -0400, Pavel Roskin wrote:
> Hi, Russell!
> 
> On Wed, 23 Jun 2004, Russell King wrote:
> 
> > On Thu, Jun 24, 2004 at 12:12:47AM +0900, komujun@nifty.com wrote:
> >> find_mem_region in rsrc_mgr.c calls allocate_resource with align=0.
> >> bogus value is loaded, then causes "cs: unable to map card memory" problem.
> >
> > Hmm, I'm wondering how we ended up with stuff working with align = 0.
> > It should actually be '1'.
> >
> > Something else to be merged _post_ 12-pcmcia-resource-2 (can't be
> > merged beforehand because this series is already half-merged and
> > I'm not going to strip my tree down, _especially_ as various people
> > have already pulled csets from it.)
> 
> I'll appreciate if you also reconsider using static variables in both 
> variants of validate_mem() in drivers/pcmcia/rsrc_mgr.c.  The can cause 
> the same error message when cardmgr is restarted.

That's a bug which needs fixing, and likewise I'm not planning any bug
fixing until after this series has been merged (iow, during the -rc
kernel series.)

> The original message didn't describe the problem in details.  It's 
> possible that the actual problem was in validate_mem().  For that to be 
> the case, the problem would not appear initially after reboot or after 
> pcmcia_core is reloaded.

Nevertheless, if you look at allocate_resource(), you'll notice
passing a value of '0' for align is bogus and _wrong_.  It should've
been '1'.  I suspect that the only reason it worked was because of
the extra alignment which pcmcia_common_align does.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

From xfesty at computeraddictions.com.au  Wed Jun 23 12:17:33 2004
From: xfesty at computeraddictions.com.au (Ryan Verner)
Date: Wed Jun 23 12:17:22 2004
Subject: PCMCIA in 2.6.7-mm1
In-Reply-To: <20040623095111.A21444@flint.arm.linux.org.uk>
References: <20040623095111.A21444@flint.arm.linux.org.uk>
Message-ID: <40D9AD1D.9030804@computeraddictions.com.au>

Russell King wrote:

> Hi,
> 
> I'd just like to check whether anyone has tested PCMCIA in 2.6.7-mm1 yet?
> It has PD6729 merged, and a few other bits from my 12-pcmcia-resource-2
> patch series.

Well, if it means anything, just tried it here; I can't tell you much 
though as I'm getting the exact same problems as detailed in my previous 
thread.

R


From proski at gnu.org  Wed Jun 23 15:05:28 2004
From: proski at gnu.org (Pavel Roskin)
Date: Wed Jun 23 15:04:12 2004
Subject: [KERNEL 2.6.7]  fix "cs: unable to map card memory!" problem
In-Reply-To: <20040623171337.G27549@flint.arm.linux.org.uk>
References: <4298296.1088003567189.komujun@nifty.com>
	<20040623164104.D27549@flint.arm.linux.org.uk>
	<Pine.LNX.4.60.0406231206180.1676@marabou.research.att.com>
	<20040623171337.G27549@flint.arm.linux.org.uk>
Message-ID: <Pine.LNX.4.60.0406231502460.2740@marabou.research.att.com>

On Wed, 23 Jun 2004, Russell King wrote:

>> I'll appreciate if you also reconsider using static variables in both
>> variants of validate_mem() in drivers/pcmcia/rsrc_mgr.c.  The can cause
>> the same error message when cardmgr is restarted.
>
> That's a bug which needs fixing, and likewise I'm not planning any bug
> fixing until after this series has been merged (iow, during the -rc
> kernel series.)

OK, OK, I just wanted to say that I debugged a similar issue a while ago, 
and in my case (Vadem-469, i82365) the fix was in validate_mem(), although 
I also suspected align issues first.

-- 
Regards,
Pavel Roskin

From proski at gnu.org  Wed Jun 23 19:19:26 2004
From: proski at gnu.org (Pavel Roskin)
Date: Wed Jun 23 19:18:05 2004
Subject: [PATCH] Overflow protection in do_io_probe()
Message-ID: <Pine.LNX.4.60.0406231912260.6266@marabou.research.att.com>

Hello!

If I use something like "include port 0xf000-0xffff" in 
/etc/pcmcia/config.opts, the kernel hangs while printing the excluded 
ports on the console.  It happens because "i" has type ioaddr_t and 
overflows to 0 after it reaches 0xfff8.

The patch looks pretty ugly for my taste, but I cannot think of anything 
else that would be as simple and reliable.

Note that "include port 0x0000-0xffff" still fails (but not hangs) for a 
different reason.  Maybe I'll debug it later.

-- 
Regards,
Pavel Roskin
-------------- next part --------------
--- linux.orig/drivers/pcmcia/rsrc_mgr.c
+++ linux/drivers/pcmcia/rsrc_mgr.c
@@ -251,6 +251,7 @@ static void do_io_probe(ioaddr_t base, i
 	if ((j == 8) && (++b[hole] > b[most]))
 	    most = hole;
 	if (b[most] == 127) break;
+	if ((ioaddr_t)(i + 8) < i) break;	/* overflow protection */
     }
     kfree(b);
 
@@ -274,6 +275,7 @@ static void do_io_probe(ioaddr_t base, i
 		bad = 0;
 	    }
 	}
+	if ((ioaddr_t)(i + 8) < i) break;	/* overflow protection */
     }
     if (bad) {
 	if ((num > 16) && (bad == base) && (i == base+num)) {
From lloyd at passcal.nmt.edu  Thu Jun 24 14:09:32 2004
From: lloyd at passcal.nmt.edu (Lloyd Carothers)
Date: Thu Jun 24 14:10:03 2004
Subject: buffer I/O error, trying to use SimpleTech compact flash via
	pcmcia
In-Reply-To: <20040622003639.C7802@flint.arm.linux.org.uk>
References: <1087853918.1258.16.camel@firestorm.passcal.nmt.edu>
	<20040622003639.C7802@flint.arm.linux.org.uk>
Message-ID: <1088100572.2920.53.camel@firestorm.passcal.nmt.edu>

On Mon, 2004-06-21 at 17:36, Russell King wrote:

> I'd suggest posting this to the linux-ide mailing list rather than the
> PCMCIA list - I don't think this is specific to PCMCIA itself.

Russel,

I posted to linux-ide with no response. I'd like to point out that
cardctl status shows:
[bat dead], [bat low]
which doesn't make since since there is no battery in these things

	I don't know whether this changes things from you perspective but I've
hit a dead end. If you know of any other routes to take, or more
debugging or research  I can do please let me know( e.g. kernel
internals documentation) 
Many thanks,
--Lloyd


From rmk+pcmcia at arm.linux.org.uk  Thu Jun 24 14:28:06 2004
From: rmk+pcmcia at arm.linux.org.uk (Russell King)
Date: Thu Jun 24 14:28:18 2004
Subject: buffer I/O error,
	trying to use SimpleTech compact flash via pcmcia
In-Reply-To: <1088100572.2920.53.camel@firestorm.passcal.nmt.edu>;
	from lloyd@passcal.nmt.edu on Thu, Jun 24, 2004 at 12:09:32PM
	-0600
References: <1087853918.1258.16.camel@firestorm.passcal.nmt.edu>
	<20040622003639.C7802@flint.arm.linux.org.uk>
	<1088100572.2920.53.camel@firestorm.passcal.nmt.edu>
Message-ID: <20040624192806.A32002@flint.arm.linux.org.uk>

On Thu, Jun 24, 2004 at 12:09:32PM -0600, Lloyd Carothers wrote:
> On Mon, 2004-06-21 at 17:36, Russell King wrote:
> > I'd suggest posting this to the linux-ide mailing list rather than the
> > PCMCIA list - I don't think this is specific to PCMCIA itself.
> 
> Russel,
> 
> I posted to linux-ide with no response. I'd like to point out that
> cardctl status shows:
> [bat dead], [bat low]
> which doesn't make since since there is no battery in these things

That's a little weird, because IO cards just don't report those things.

Could you grab the cbdump.c program from pcmcia.arm.linux.org.uk, and
dump out:

- cardctl status
- cardctl config
- cbdump

with the card inserted please?  We can then see exactly what state
the kernel thinks stuff should be in vs the state of the actual socket
itself.

Thanks.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

From jar at pcuf.fi  Thu Jun 24 14:58:29 2004
From: jar at pcuf.fi (jar)
Date: Thu Jun 24 14:58:45 2004
Subject: PCMCIA in 2.6.7-mm1
In-Reply-To: <20040623095111.A21444@flint.arm.linux.org.uk>
References: <20040623095111.A21444@flint.arm.linux.org.uk>
Message-ID: <40DB2455.40200@pcuf.fi>

Russell King wrote:
> Hi,
> 
> I'd just like to check whether anyone has tested PCMCIA in 2.6.7-mm1 yet?
> It has PD6729 merged, and a few other bits from my 12-pcmcia-resource-2
> patch series.

I tested the 2.6.7-mm1. The PD6729 part is working just fine. I would 
like to thank Komuro and Russell for this excellent driver.

Kernel still panics when I remove the 1 sleep between cardctl eject
and rmmod ds and do pcmcia restart. Without "cardctl eject & 1 sleep"
the modules are in use and can't be unloaded and the message
"cs: unable to map card memory!" appears. Apparently these aren't yet 
corrected in the 2.6.7-mm1 kernel.

Additionally I get feature more, the dmesg now says: set_rtc_mmss: can't 
update from 59 to 4..5 etc. But that's not pcmcia issue I belive.

Best Regads, Jar

From lloyd at passcal.nmt.edu  Thu Jun 24 16:24:53 2004
From: lloyd at passcal.nmt.edu (Lloyd Carothers)
Date: Thu Jun 24 16:25:15 2004
Subject: buffer I/O error, trying to use SimpleTech compact flash via
	pcmcia
In-Reply-To: <20040624192806.A32002@flint.arm.linux.org.uk>
References: <1087853918.1258.16.camel@firestorm.passcal.nmt.edu>
	<20040622003639.C7802@flint.arm.linux.org.uk>
	<1088100572.2920.53.camel@firestorm.passcal.nmt.edu>
	<20040624192806.A32002@flint.arm.linux.org.uk>
Message-ID: <1088108693.2920.60.camel@firestorm.passcal.nmt.edu>

On Thu, 2004-06-24 at 12:28, Russell King wrote:

> Could you grab the cbdump.c program from pcmcia.arm.linux.org.uk, and
> dump out:
> 
> - cardctl status

Socket 0:
  3.3V 16-bit PC Card
  function 0: [ready], [bat dead], [bat low]

> - cardctl config

Socket 0:
  Vcc 3.3V  Vpp1 0.0V  Vpp2 0.0V
  interface type is "memory and I/O"
  irq 3 [exclusive] [level]
  function 0:
    config base 0x0200
      option 0x41 status 0x00 pin 0x00 copy 0x00
    io 0x0100-0x010f [auto]

> - cbdump

02:00.0 CardBus bridge: Gammagraphx, Inc.: Unknown device 0000
  -- generic cardbus config registers
  Vendor ID                      [00] : 0x1180
  Device ID                      [02] : 0x0476
  PCI command                    [04] : 0x0007
  Base address                   [10] : 0x50000000
  Memory Base 0                  [1c] : 0x10400000
  Memory Limit 0                 [20] : 0x107ff000
  Memory Base 1                  [24] : 0x10800000
  Memory Limit 1                 [28] : 0x10bff000
  IO Base 0                      [2c] : 0x00004000
  IO Limit 0                     [30] : 0x000040fc
  IO Base 1                      [34] : 0x00004400
  IO Limit 1                     [38] : 0x000044fc
  Bridge control                 [3e] : 0x0580
  Subsystem vendor ID            [40] : 0x1014
  Subsystem device ID            [42] : 0x0185
  Legacy mode base               [44] : 0x0001
  -- cardbus registers
  CB_SOCKET_EVENT                [00] : 0x00000000
  CB_SOCKET_MASK                 [04] : 0x00000006
  CB_SOCKET_STATE                [08] : 0x30000819
  CB_SOCKET_FORCE                [0c] : 0x00000000
  CB_SOCKET_CONTROL              [10] : 0x00000430
  CB_SOCKET_POWER                [20] : 0x00000000
  -- exca registers
  I365_IDENT                     [00] : 0x83
  I365_STATUS                    [01] : 0x6f
  I365_POWER                     [02] : 0xd0
  I365_INTCTL                    [03] : 0x63
  I365_CSC                       [04] : 0x00
  I365_CSCINT                    [05] : 0x08
  I365_ADDRWIN                   [06] : 0x41
  I365_IOCTL                     [07] : 0x02
  I365_GENCTL                    [16] : 0x0000
  I365_GBLCTL                    [1e] : 0x0000
  I365_IO0_START                 [08] : 0x0100
  I365_IO0_STOP                  [0a] : 0x010f
  I365_IO1_START                 [0c] : 0x0000
  I365_IO1_STOP                  [0e] : 0x0001
  I365_MEM0_START                [10] : 0x0000
  I365_MEM0_STOP                 [12] : 0x8000
  I365_MEM0_OFF                  [14] : 0x4000
  I365_MEM0_PAGE                 [40] : 0xa0
  I365_MEM1_START                [18] : 0x0000
  I365_MEM1_STOP                 [1a] : 0x0000
  I365_MEM1_OFF                  [1c] : 0x0000
  I365_MEM1_PAGE                 [41] : 0x00
  I365_MEM2_START                [20] : 0x0000
  I365_MEM2_STOP                 [22] : 0x0000
  I365_MEM2_OFF                  [24] : 0x0000
  I365_MEM2_PAGE                 [42] : 0x00
  I365_MEM3_START                [28] : 0x0000
  I365_MEM3_STOP                 [2a] : 0x0000
  I365_MEM3_OFF                  [2c] : 0x0000
  I365_MEM3_PAGE                 [43] : 0x00
  I365_MEM4_START                [30] : 0x0000
  I365_MEM4_STOP                 [32] : 0x0000
  I365_MEM4_OFF                  [34] : 0x0000
  I365_MEM4_PAGE                 [44] : 0x00

02:00.1 CardBus bridge: Gammagraphx, Inc.: Unknown device 0000
  -- generic cardbus config registers
  Vendor ID                      [00] : 0x1180
  Device ID                      [02] : 0x0476
  PCI command                    [04] : 0x0007
  Base address                   [10] : 0x50100000
  Memory Base 0                  [1c] : 0x10c00000
  Memory Limit 0                 [20] : 0x10fff000
  Memory Base 1                  [24] : 0x11000000
  Memory Limit 1                 [28] : 0x113ff000
  IO Base 0                      [2c] : 0x00004800
  IO Limit 0                     [30] : 0x000048fc
  IO Base 1                      [34] : 0x00004c00
  IO Limit 1                     [38] : 0x00004cfc
  Bridge control                 [3e] : 0x0580
  Subsystem vendor ID            [40] : 0x1014
  Subsystem device ID            [42] : 0x0185
  Legacy mode base               [44] : 0x0001
  -- cardbus registers
  CB_SOCKET_EVENT                [00] : 0x00000000
  CB_SOCKET_MASK                 [04] : 0x00000006
  CB_SOCKET_STATE                [08] : 0x30000006
  CB_SOCKET_FORCE                [0c] : 0x00000000
  CB_SOCKET_CONTROL              [10] : 0x00000400
  CB_SOCKET_POWER                [20] : 0x00000000
  -- exca registers
  I365_IDENT                     [00] : 0x83
  I365_STATUS                    [01] : 0x33
  I365_POWER                     [02] : 0x40
  I365_INTCTL                    [03] : 0x40
  I365_CSC                       [04] : 0x00
  I365_CSCINT                    [05] : 0x08
  I365_ADDRWIN                   [06] : 0x00
  I365_IOCTL                     [07] : 0x00
  I365_GENCTL                    [16] : 0x0000
  I365_GBLCTL                    [1e] : 0x0000
  I365_IO0_START                 [08] : 0x0000
  I365_IO0_STOP                  [0a] : 0x0001
  I365_IO1_START                 [0c] : 0x0000
  I365_IO1_STOP                  [0e] : 0x0001
  I365_MEM0_START                [10] : 0x0000
  I365_MEM0_STOP                 [12] : 0x0000
  I365_MEM0_OFF                  [14] : 0x0000
  I365_MEM0_PAGE                 [40] : 0x00
  I365_MEM1_START                [18] : 0x0000
  I365_MEM1_STOP                 [1a] : 0x0000
  I365_MEM1_OFF                  [1c] : 0x0000
  I365_MEM1_PAGE                 [41] : 0x00
  I365_MEM2_START                [20] : 0x0000
  I365_MEM2_STOP                 [22] : 0x0000
  I365_MEM2_OFF                  [24] : 0x0000
  I365_MEM2_PAGE                 [42] : 0x00
  I365_MEM3_START                [28] : 0x0000
  I365_MEM3_STOP                 [2a] : 0x0000
  I365_MEM3_OFF                  [2c] : 0x0000
  I365_MEM3_PAGE                 [43] : 0x00
  I365_MEM4_START                [30] : 0x0000
  I365_MEM4_STOP                 [32] : 0x0000
  I365_MEM4_OFF                  [34] : 0x0000
  I365_MEM4_PAGE                 [44] : 0x00



> Thanks.
thank you


From dhinds at sonic.net  Thu Jun 24 17:17:25 2004
From: dhinds at sonic.net (David Hinds)
Date: Thu Jun 24 17:17:51 2004
Subject: buffer I/O error,
	trying to use SimpleTech compact flash via pcmcia
In-Reply-To: <20040624192806.A32002@flint.arm.linux.org.uk>
References: <1087853918.1258.16.camel@firestorm.passcal.nmt.edu>
	<20040622003639.C7802@flint.arm.linux.org.uk>
	<1088100572.2920.53.camel@firestorm.passcal.nmt.edu>
	<20040624192806.A32002@flint.arm.linux.org.uk>
Message-ID: <20040624211725.GA13235@sonic.net>

On Thu, Jun 24, 2004 at 07:28:06PM +0100, Russell King wrote:
> On Thu, Jun 24, 2004 at 12:09:32PM -0600, Lloyd Carothers wrote:
> > On Mon, 2004-06-21 at 17:36, Russell King wrote:
> >
> > cardctl status shows:
> > [bat dead], [bat low]
> > which doesn't make since since there is no battery in these things
> 
> That's a little weird, because IO cards just don't report those things.

IO cards report these things via the "Pin Replacement Register", if
implemented.  And that is what the "get status" function uses.

I don't think this has anything whatsoever to do with the problem.
The card presumably has implemented the PRR but these bits are just
returning nonsense because the card has no battery.

-- Dave

From lloyd at passcal.nmt.edu  Thu Jun 24 18:03:49 2004
From: lloyd at passcal.nmt.edu (Lloyd Carothers)
Date: Fri Jun 25 07:34:26 2004
Subject: buffer I/O error, trying to use SimpleTech compact flash via
	pcmcia
In-Reply-To: <20040624224950.B2851@flint.arm.linux.org.uk>
References: <1087853918.1258.16.camel@firestorm.passcal.nmt.edu>
	<20040622003639.C7802@flint.arm.linux.org.uk>
	<1088100572.2920.53.camel@firestorm.passcal.nmt.edu>
	<20040624192806.A32002@flint.arm.linux.org.uk>
	<1088108693.2920.60.camel@firestorm.passcal.nmt.edu>
	<20040624224950.B2851@flint.arm.linux.org.uk>
Message-ID: <1088114629.2920.67.camel@firestorm.passcal.nmt.edu>

On Thu, 2004-06-24 at 15:49, Russell King wrote:

> Well, it all looks fine.  I still suggest talking to the Linux-ide
> people since, as I say, PCMCIA merely only sets up the bridge and
> tells the IDE layer where the interface is.  The actual accesses
> to the card are managed and performed by IDE, so you really need
> an IDE person to take this forward.

I'll try them again... Unfortunately they aren't as responsive as this
mailing list
thanks again
--Lloyd


From rmk+pcmcia at arm.linux.org.uk  Thu Jun 24 17:49:51 2004
From: rmk+pcmcia at arm.linux.org.uk (Russell King)
Date: Fri Jun 25 07:34:29 2004
Subject: buffer I/O error,
	trying to use SimpleTech compact flash via pcmcia
In-Reply-To: <1088108693.2920.60.camel@firestorm.passcal.nmt.edu>;
	from lloyd@passcal.nmt.edu on Thu, Jun 24, 2004 at 02:24:53PM
	-0600
References: <1087853918.1258.16.camel@firestorm.passcal.nmt.edu>
	<20040622003639.C7802@flint.arm.linux.org.uk>
	<1088100572.2920.53.camel@firestorm.passcal.nmt.edu>
	<20040624192806.A32002@flint.arm.linux.org.uk>
	<1088108693.2920.60.camel@firestorm.passcal.nmt.edu>
Message-ID: <20040624224950.B2851@flint.arm.linux.org.uk>

On Thu, Jun 24, 2004 at 02:24:53PM -0600, Lloyd Carothers wrote:
> On Thu, 2004-06-24 at 12:28, Russell King wrote:
> > Could you grab the cbdump.c program from pcmcia.arm.linux.org.uk, and
> > dump out:

Well, it all looks fine.  I still suggest talking to the linux-ide
people since, as I say, PCMCIA merely only sets up the bridge and
tells the IDE layer where the interface is.  The actual accesses
to the card are managed and performed by IDE, so you really need
an IDE person to take this forward.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

From komuro4649 at nifty.com  Fri Jun 25 20:04:05 2004
From: komuro4649 at nifty.com (Komuro)
Date: Fri Jun 25 20:04:16 2004
Subject: PCMCIA in 2.6.7-mm1 
Message-ID: <6445066.1088208245209.komuro4649@nifty.com>

> I'd just like to check whether anyone has tested PCMCIA in 2.6.7-mm1 yet?
> It has PD6729 merged, and a few other bits from my 12-pcmcia-resource-2
> patch series.

It works properly.
( ,need following patch in my configuration)

Best Regards
Komuro


--- linux/kernel/resource.c.orig	2004-06-24 21:02:38.000000000 +0900
+++ linux/kernel/resource.c	2004-06-24 21:03:59.000000000 +0900
@@ -261,7 +261,8 @@
 			new->start = min;
 		if (new->end > max)
 			new->end = max;
-		new->start = (new->start + align - 1) & ~(align - 1);
+		if (align)
+			new->start = (new->start + align - 1) & ~(align - 1);
 		if (alignf)
 			alignf(alignf_data, new, size, align);
 		if (new->start < new->end && new->end - new->start + 1 >= size) {


From jar at pcuf.fi  Mon Jun 28 02:48:43 2004
From: jar at pcuf.fi (Jar)
Date: Mon Jun 28 02:49:07 2004
Subject: (no subject)
Message-ID: <60921.194.157.0.2.1088405323.squirrel@194.157.0.2>


Now the PD6729 driver is on the way to the offical kernel. To be
exact, should there be MODULE_AUTHOR(""); and MODULE_DESCRIPTION("");
statements in the driver code? So that people can easily see with
lsmod what is this driver and who is the author.

Could you provide that information?


-- 
Best Regards, Jar

From rmk+pcmcia at arm.linux.org.uk  Mon Jun 28 04:31:09 2004
From: rmk+pcmcia at arm.linux.org.uk (Russell King)
Date: Mon Jun 28 04:31:28 2004
Subject: (no subject)
In-Reply-To: <60921.194.157.0.2.1088405323.squirrel@194.157.0.2>;
	from jar@pcuf.fi on Mon, Jun 28, 2004 at 09:48:43AM +0300
References: <60921.194.157.0.2.1088405323.squirrel@194.157.0.2>
Message-ID: <20040628093109.D32206@flint.arm.linux.org.uk>

On Mon, Jun 28, 2004 at 09:48:43AM +0300, Jar wrote:
> Now the PD6729 driver is on the way to the offical kernel. To be
> exact, should there be MODULE_AUTHOR(""); and MODULE_DESCRIPTION("");
> statements in the driver code? So that people can easily see with
> lsmod what is this driver and who is the author.
> 
> Could you provide that information?

I've already asked Komuro for that, but I've not had a response as yet.
I hope Komuro can provide the information ASAP...

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

From komurojun at mbn.nifty.com  Mon Jun 28 09:20:41 2004
From: komurojun at mbn.nifty.com (Komuro)
Date: Mon Jun 28 09:27:30 2004
Subject: 2.6.x kernels & PCI-to-PCMCIA bridges [again] 
Message-ID: <7343708.1088428841823.komurojun@mbn.nifty.com>

>PS, could I have a patch to add a MODULE_AUTHOR line to the version in
>2.6.7-mm1 please?

Please see the following patch for 2.6.7-mm3

I've fixed card_start problem.
Most client driver set card_start=0,
So
mem->card_start - mem->sys_start equals -mem->sys_start.  wrong!    

Please see the following patch for 2.6.7-mm3
This fix is needed for yenta_socket, i82092 and i82365 driver too.

Best Regards
Komuro


--- linux/drivers/pcmcia/pd6729.c.orig	2004-06-28 09:38:21.960143712 +0900
+++ linux/drivers/pcmcia/pd6729.c	2004-06-28 09:59:10.721303160 +0900
@@ -28,11 +28,13 @@
 #include "cirrus.h"
 
 MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Driver for the Cirrus PD6729 PCI-PCMCIA bridge");
+MODULE_AUTHOR("Jun Komuro <komurojun@mbn.nifty.com>");
 
 #define MAX_SOCKETS 2
 
-/* simple helper functions */
-/* External clock time, in nanoseconds.  120 ns = 8.33 MHz */
+/* Simple helper function 
+   External clock time, in nanoseconds.  120 ns = 8.33 MHz */
 #define to_cycles(ns)	((ns)/120)
 
 static spinlock_t port_lock = SPIN_LOCK_UNLOCKED;
@@ -535,7 +537,7 @@
 
 	/* card start */
 
-	i = ((mem->card_start - mem->sys_start) >> 12) & 0x3fff;
+	i = (mem->card_start >> 12) & 0x3fff;
 	if (mem->flags & MAP_WRPROT)
 		i |= I365_MEM_WRPROT;
 	if (mem->flags & MAP_ATTRIB) {


From rmk+pcmcia at arm.linux.org.uk  Mon Jun 28 10:43:27 2004
From: rmk+pcmcia at arm.linux.org.uk (Russell King)
Date: Mon Jun 28 10:43:35 2004
Subject: 2.6.x kernels & PCI-to-PCMCIA bridges [again]
In-Reply-To: <7343708.1088428841823.komurojun@mbn.nifty.com>;
	from komurojun@mbn.nifty.com on Mon, Jun 28, 2004 at 10:20:41PM
	+0900
References: <7343708.1088428841823.komurojun@mbn.nifty.com>
Message-ID: <20040628154327.A9214@flint.arm.linux.org.uk>

On Mon, Jun 28, 2004 at 10:20:41PM +0900, Komuro wrote:
> >PS, could I have a patch to add a MODULE_AUTHOR line to the version in
> >2.6.7-mm1 please?
> 
> Please see the following patch for 2.6.7-mm3
> 
> I've fixed card_start problem.
> Most client driver set card_start=0,
> So
> mem->card_start - mem->sys_start equals -mem->sys_start.  wrong!    

Actually, its right.  You've programmed the memory start/stop registers
with sys_start and sys_stop.  Since card_start = 0, you want accesses
to physical address "sys_start" to correspond with card address
"card_start".  So, if card_start = 0, you need to program the offset
register (I365_W_OFF) with -sys_start to achieve the required address
on the PCMCIA bus.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

From dhinds at sonic.net  Mon Jun 28 12:57:26 2004
From: dhinds at sonic.net (David Hinds)
Date: Mon Jun 28 12:57:35 2004
Subject: 2.6.x kernels & PCI-to-PCMCIA bridges [again]
In-Reply-To: <20040628154327.A9214@flint.arm.linux.org.uk>
References: <7343708.1088428841823.komurojun@mbn.nifty.com>
	<20040628154327.A9214@flint.arm.linux.org.uk>
Message-ID: <20040628165726.GC27809@sonic.net>

On Mon, Jun 28, 2004 at 03:43:27PM +0100, Russell King wrote:
> 
> Actually, its right.  You've programmed the memory start/stop registers
> with sys_start and sys_stop.  Since card_start = 0, you want accesses
> to physical address "sys_start" to correspond with card address
> "card_start".  So, if card_start = 0, you need to program the offset
> register (I365_W_OFF) with -sys_start to achieve the required address
> on the PCMCIA bus.

Agreed; the original code was correct.

-- Dave

From rohan208 at gmail.com  Mon Jun 28 15:01:53 2004
From: rohan208 at gmail.com (rohan mutagi)
Date: Mon Jun 28 15:02:24 2004
Subject: pci-to-pcmcia connection with "AirPrime 5220 EVDO"
Message-ID: <91740af304062812016a668a91@mail.gmail.com>

Hello,
 I have attached a EVDO card to my Desktop PC via a PCI-to-PCMCIA
bridge by ElanDigital. When I do a lspci with my EV-Do card inserted i
get:
pcilib: Cannot open /proc/bus/pci/02/00.0
lspci: Unable to read 64 bytes of configuration space.
But when i do lspci -H1 i get:
00:00.0 Host bridge: Silicon Integrated Systems [SiS]: Unknown device
0651 (rev 02)
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] 5591/5592 AGP
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 (rev 25)
00:03.0 USB Controller: Silicon Integrated Systems [SiS] 7001 (rev 0f)
00:03.1 USB Controller: Silicon Integrated Systems [SiS] 7001 (rev 0f)
00:03.2 USB Controller: Silicon Integrated Systems [SiS]: Unknown device 7002
00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900
10/100 Ethernet (rev 91)
00:09.0 CardBus bridge: ENE Technology Inc: Unknown device 1410
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS]:
Unknown device 6325
02:00.0 USB Controller: Lucent Microelectronics: Unknown device 5802 (rev 10)

So i thought the problem was with my PC and so i inserted the EV-Do
caed in the PCI slot of my laptop. When i did a lspci:
I get the results fine and dont see the "cannot open" error. Why is
there this difference?

IAm not able to connect the AirPrime Evdo card
"http://www.ka9q.net/5220.html" to Desktop via the Adaptor. While i
can connect the EVDO card to my laptop under linux and i can use my
ETHERNET PCI card from the adaptor.

rohan

From dhinds at sonic.net  Mon Jun 28 16:22:26 2004
From: dhinds at sonic.net (David Hinds)
Date: Mon Jun 28 16:22:49 2004
Subject: pci-to-pcmcia connection with "AirPrime 5220 EVDO"
In-Reply-To: <91740af304062812016a668a91@mail.gmail.com>
References: <91740af304062812016a668a91@mail.gmail.com>
Message-ID: <20040628202226.GA27080@sonic.net>

On Mon, Jun 28, 2004 at 03:01:53PM -0400, rohan mutagi wrote:
> Hello,
>  I have attached a EVDO card to my Desktop PC via a PCI-to-PCMCIA
> bridge by ElanDigital. When I do a lspci with my EV-Do card inserted i
> get:
> pcilib: Cannot open /proc/bus/pci/02/00.0
> lspci: Unable to read 64 bytes of configuration space.

...

> So i thought the problem was with my PC and so i inserted the EV-Do
> caed in the PCI slot of my laptop. When i did a lspci:
> I get the results fine and dont see the "cannot open" error. Why is
> there this difference?

The difference is that your desktop is running a 2.4 kernel with the
external pcmcia-cs driver modules, while your laptop is running some
other combination, probably a 2.4 or 2.6 kernel with the kernel PCMCIA
subsystem.

-- Dave

From rohan208 at gmail.com  Mon Jun 28 16:36:09 2004
From: rohan208 at gmail.com (rohan mutagi)
Date: Mon Jun 28 16:36:15 2004
Subject: pci-to-pcmcia connection with "AirPrime 5220 EVDO"
In-Reply-To: <20040628202226.GA27080@sonic.net>
References: <91740af304062812016a668a91@mail.gmail.com>
	<20040628202226.GA27080@sonic.net>
Message-ID: <91740af304062813366dd4a27b@mail.gmail.com>

Hello Dave,
You are right. Both, my laptop and PC are running same version of
linux. (i did the installation from the same CDs). How ever, on the PC
i have Disabled "yenta_socket" from the kernel and recompiled the
kernel to support pcmcia_cs.
How ever my concern is that why isnt the EVDO card working on my PC. I
have been tring for 8 days now to get it to work. The evdo card has an
usb controler insde and its simulated to be two Usb's (one for data
and one for commands). Is there any place where i can look for help
regarding this?
Thanks for ur time,
Rohan

On Mon, 28 Jun 2004 13:22:26 -0700, David Hinds <dhinds@sonic.net> wrote:
> 
> On Mon, Jun 28, 2004 at 03:01:53PM -0400, rohan mutagi wrote:
> > Hello,
> >  I have attached a EVDO card to my Desktop PC via a PCI-to-PCMCIA
> > bridge by ElanDigital. When I do a lspci with my EV-Do card inserted i
> > get:
> > pcilib: Cannot open /proc/bus/pci/02/00.0
> > lspci: Unable to read 64 bytes of configuration space.
> 
> ...
> 
> > So i thought the problem was with my PC and so i inserted the EV-Do
> > caed in the PCI slot of my laptop. When i did a lspci:
> > I get the results fine and dont see the "cannot open" error. Why is
> > there this difference?
> 
> The difference is that your desktop is running a 2.4 kernel with the
> external pcmcia-cs driver modules, while your laptop is running some
> other combination, probably a 2.4 or 2.6 kernel with the kernel PCMCIA
> subsystem.
> 
> -- Dave
>

From komurojun at mbn.nifty.com  Tue Jun 29 08:53:14 2004
From: komurojun at mbn.nifty.com (Komuro)
Date: Tue Jun 29 08:53:23 2004
Subject: 2.6.x kernels & PCI-to-PCMCIA bridges [again]
In-Reply-To: <20040628154327.A9214@flint.arm.linux.org.uk>
References: <20040628154327.A9214@flint.arm.linux.org.uk>
	<7343708.1088428841823.komurojun@mbn.nifty.com>
Message-ID: <6508031.1088513594611.komurojun@mbn.nifty.com>


>> I've fixed card_start problem.
>> Most client driver set card_start=0,
>> So
>> mem->card_start - mem->sys_start equals -mem->sys_start.  wrong!    
>
>Actually, its right.  You've programmed the memory start/stop registers
>with sys_start and sys_stop.  Since card_start = 0, you want accesses
>to physical address "sys_start" to correspond with card address
>"card_start".  So, if card_start = 0, you need to program the offset
>register (I365_W_OFF) with -sys_start to achieve the required address
>on the PCMCIA bus.

I think I365_W_OFF value is greater than or equal to 0.

I365_W_OFF specifies the offset in PCMCIA Memory Address Space(MAX 64Mbytes).
I365_W_START specifies the address in PCI Memory Address Space(MAX 4Gbytes)

Please see "Figure 3-1 Memory Window Organization" in the PD6729 datasheet
(page 18).
You can dowonload the PD6729 datasheet from the pcmcia-cs site.
http://pcmcia-cs.sourceforge.net/specs/index.html

Best Regards
Komuro


From rmk+pcmcia at arm.linux.org.uk  Tue Jun 29 09:14:42 2004
From: rmk+pcmcia at arm.linux.org.uk (Russell King)
Date: Tue Jun 29 09:14:54 2004
Subject: 2.6.x kernels & PCI-to-PCMCIA bridges [again]
In-Reply-To: <6508031.1088513594611.komurojun@mbn.nifty.com>;
	from komurojun@mbn.nifty.com on Tue, Jun 29, 2004 at 09:53:14PM
	+0900
References: <20040628154327.A9214@flint.arm.linux.org.uk>
	<7343708.1088428841823.komurojun@mbn.nifty.com>
	<20040628154327.A9214@flint.arm.linux.org.uk>
	<6508031.1088513594611.komurojun@mbn.nifty.com>
Message-ID: <20040629141442.B24951@flint.arm.linux.org.uk>

On Tue, Jun 29, 2004 at 09:53:14PM +0900, Komuro wrote:
> 
> >> I've fixed card_start problem.
> >> Most client driver set card_start=0,
> >> So
> >> mem->card_start - mem->sys_start equals -mem->sys_start.  wrong!    
> >
> >Actually, its right.  You've programmed the memory start/stop registers
> >with sys_start and sys_stop.  Since card_start = 0, you want accesses
> >to physical address "sys_start" to correspond with card address
> >"card_start".  So, if card_start = 0, you need to program the offset
> >register (I365_W_OFF) with -sys_start to achieve the required address
> >on the PCMCIA bus.
> 
> I think I365_W_OFF value is greater than or equal to 0.
> 
> I365_W_OFF specifies the offset in PCMCIA Memory Address Space(MAX 64Mbytes).
> I365_W_START specifies the address in PCI Memory Address Space(MAX 4Gbytes)
> 
> Please see "Figure 3-1 Memory Window Organization" in the PD6729 datasheet
> (page 18).
> You can dowonload the PD6729 datasheet from the pcmcia-cs site.
> http://pcmcia-cs.sourceforge.net/specs/index.html

Take a look at page 57 and 58 of that same data sheet.

"Bits 7-0: Offset address 19-12
"This register contains the least-significant byte of the quantity that
will be added to the system memory address that determines where in the
PCMCIA card's memory map the memory access will occur."

"Bits 5-0: Offset address 25-20
"This field contains the most-significant six bits of the Offset Address.
See the description of the Offset Address field associated with bits 7-0
of the Card Memory Map 0-4 Offset Address Low Register."

What this is saying is that:

	Card Address = System Address + Offset Address

System Address is mem->sys_start
Card Address is mem->card_start

Also note that the card address is only 26 bits in size, and therefore
the above equation only has 26 bits of precision.

So, we have:

	mem->card_start = mem->sys_start + Offset Address

Rearranging this equation gives:

	Offset Address = mem->card_start - mem->sys_start

Therefore, the code as it currently stands in even your pd6729 driver
is correct.

Now, as noted above, we only have 26 bits of precision for the card
address, and also note that the offset address is also 26 bits.
Remember your 2's complement arithmetic and you'll realise that
having a large 26-bit number (eg, 0x3ffffff) is the same as a
negative number (-1).

To give an example, lets assume that mem->sys_start is 0xe00000
and we want mem->card_start = 0.  Let's work it out:

	Offset Address = 0 - 0xe0000

This obviously gives Offset Address = -0xe0000, or 0xfff20000
(assuming 32-bit arithmetic).  Limiting this to the 26-bit number
gives 0x3f20000.  Now, lets plug this back in to the original
equation and work out what the actual card address is:

	Card Address = 0xe0000 + 0x3f20000

which gives 0x4000000.  Remember that card addresses are cropped
to 26 bits, and this gives a card address of 0 - which is what
we wanted all along.

Repeat this for another card address and you'll see that it all
works out correctly, and hopefully you'll prove to yourself that
the code as it stands is actually 100% correct.

You may also like to try plugging your proposed "fix" into the
equation and see what happens.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

From stefan.eletzhofer at eletztrick.de  Tue Jun 29 09:31:00 2004
From: stefan.eletzhofer at eletztrick.de (stefan.eletzhofer@eletztrick.de)
Date: Tue Jun 29 09:32:02 2004
Subject: [PATCH] PXA PCMCIA timing
Message-ID: <20040629133100.GF19605@gonzo.local>

Hi,
here's a patch which allows boards to override the
timing calculations done in pxa2xx_core.c.

The patch is against 2.6.6-bkpxa, If the patch is OK
I'll update it to the latest 2.6 bk tree. AFAIK the timing
calculation stuff did not change in 2.6.7.

Please comment.

Thanks,
	Stefan E.
-- 
Eletztrick Computing - Customized Linux Development
Stefan Eletzhofer, Marktstrasse 43, DE-88214 Ravensburg
http://www.eletztrick.de
-------------- next part --------------
Allow boards to override MCMEM/IO/ATTR timing calculations

#
# Patch managed by http://www.mn-logistik.de/unsupported/pxa250/patcher
#

--- linux-ra_alpha/include/asm-arm/arch-pxa/pcmcia.h~pxa-pcmcia-board-timing
+++ linux-ra_alpha/include/asm-arm/arch-pxa/pcmcia.h
@@ -96,13 +96,12 @@
 	 */
 	void (*socket_suspend)(struct pxa2xx_pcmcia_socket *);
 
-	/*
-	 * Calculate MECR timing clock wait states
-	 *
-	 * FIXME: fixt this to match PXA registers
+	/* Override timing calculations for this platform.
+	 * If not set, use default timing calc from pxa2xx_core.c
 	 */
-	unsigned int (*socket_get_timing)(struct pxa2xx_pcmcia_socket *,
-			unsigned int cpu_speed, unsigned int cmd_time);
+	int (*socket_set_mcmem)(struct pxa2xx_pcmcia_socket *skt, int speed, int clock );
+	int (*socket_set_mcio)(struct pxa2xx_pcmcia_socket *skt, int speed, int clock );
+	int (*socket_set_mcatt)(struct pxa2xx_pcmcia_socket *skt, int speed, int clock );
 };
 
 #endif
--- linux-ra_alpha/drivers/pcmcia/pxa2xx_core.c~pxa-pcmcia-board-timing
+++ linux-ra_alpha/drivers/pcmcia/pxa2xx_core.c
@@ -65,33 +65,6 @@
 
 #define to_pxa2xx_socket(x)	container_of(x, struct pxa2xx_pcmcia_socket, socket)
 
-/* FIXME */
-#define cpufreq_get(dummy) (get_clk_frequency_khz())
-
-#if 0
-/*
- * pxa2xx_core_pcmcia_default_mecr_timing
- * ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- *
- * Calculate MECR clock wait states for given CPU clock
- * speed and command wait state. This function can be over-
- * written by a board specific version.
- *
- * The default is to simply calculate the BS values as specified in
- * the INTEL SA1100 development manual
- * "Expansion Memory (PCMCIA) Configuration Register (MECR)"
- * that's section 10.2.5 in _my_ version of the manual ;)
- */
-static unsigned int
-pxa2xx_core_pcmcia_default_mecr_timing(struct pxa2xx_pcmcia_socket *skt,
-		unsigned int cpu_speed,
-		unsigned int cmd_time)
-{
-	debugs( skt, 1, "speed=%d, time=%d", cpu_speed, cmd_time );
-	return pxa2xx_core_pcmcia_mecr_bs(cmd_time, cpu_speed);
-}
-#endif
-
 static unsigned short calc_speed(unsigned short *spds, int num, unsigned short dflt)
 {
 	unsigned short speed = 0;
@@ -106,49 +79,71 @@
 	return speed;
 }
 
-static int pxa2xx_core_pcmcia_set_mcmem( int sock, int speed, int clock )
+static int pxa2xx_core_pcmcia_set_mcmem( struct pxa2xx_pcmcia_socket *skt,
+		int speed, int clock )
 {
-	MCMEM(sock) = ((pxa2xx_mcxx_setup(speed, clock)
-		& MCXX_SETUP_MASK) << MCXX_SETUP_SHIFT)
-		| ((pxa2xx_mcxx_asst(speed, clock)
-		& MCXX_ASST_MASK) << MCXX_ASST_SHIFT)
-		| ((pxa2xx_mcxx_hold(speed, clock)
-		& MCXX_HOLD_MASK) << MCXX_HOLD_SHIFT);
+	int ret = 0;
+	int sock = skt->nr;
 
-	return 0;
+	if (skt->ops->socket_set_mcmem) {
+		ret = skt->ops->socket_set_mcmem(skt, speed, clock);
+	} else  {
+		MCMEM(sock) = ((pxa2xx_mcxx_setup(speed, clock)
+			& MCXX_SETUP_MASK) << MCXX_SETUP_SHIFT)
+			| ((pxa2xx_mcxx_asst(speed, clock)
+			& MCXX_ASST_MASK) << MCXX_ASST_SHIFT)
+			| ((pxa2xx_mcxx_hold(speed, clock)
+			& MCXX_HOLD_MASK) << MCXX_HOLD_SHIFT);
+	}
+
+	return ret;
 }
 
-static int pxa2xx_core_pcmcia_set_mcio( int sock, int speed, int clock )
+static int pxa2xx_core_pcmcia_set_mcio( struct pxa2xx_pcmcia_socket *skt,
+		int speed, int clock )
 {
-	MCIO(sock) = ((pxa2xx_mcxx_setup(speed, clock)
-		& MCXX_SETUP_MASK) << MCXX_SETUP_SHIFT)
-		| ((pxa2xx_mcxx_asst(speed, clock)
-		& MCXX_ASST_MASK) << MCXX_ASST_SHIFT)
-		| ((pxa2xx_mcxx_hold(speed, clock)
-		& MCXX_HOLD_MASK) << MCXX_HOLD_SHIFT);
+	int ret = 0;
+	int sock = skt->nr;
 
-	return 0;
+	if (skt->ops->socket_set_mcio) {
+		ret = skt->ops->socket_set_mcio(skt, speed, clock);
+	} else  {
+		MCIO(sock) = ((pxa2xx_mcxx_setup(speed, clock)
+			& MCXX_SETUP_MASK) << MCXX_SETUP_SHIFT)
+			| ((pxa2xx_mcxx_asst(speed, clock)
+			& MCXX_ASST_MASK) << MCXX_ASST_SHIFT)
+			| ((pxa2xx_mcxx_hold(speed, clock)
+			& MCXX_HOLD_MASK) << MCXX_HOLD_SHIFT);
+	}
+
+	return ret;
 }
 
-static int pxa2xx_core_pcmcia_set_mcatt( int sock, int speed, int clock )
+static int pxa2xx_core_pcmcia_set_mcatt( struct pxa2xx_pcmcia_socket *skt,
+		int speed, int clock )
 {
-	MCATT(sock) = ((pxa2xx_mcxx_setup(speed, clock)
-		& MCXX_SETUP_MASK) << MCXX_SETUP_SHIFT)
-		| ((pxa2xx_mcxx_asst(speed, clock)
-		& MCXX_ASST_MASK) << MCXX_ASST_SHIFT)
-		| ((pxa2xx_mcxx_hold(speed, clock)
-		& MCXX_HOLD_MASK) << MCXX_HOLD_SHIFT);
+	int ret = 0;
+	int sock = skt->nr;
 
-	return 0;
+	if (skt->ops->socket_set_mcatt) {
+		ret = skt->ops->socket_set_mcatt(skt, speed, clock);
+	} else  {
+		MCATT(sock) = ((pxa2xx_mcxx_setup(speed, clock)
+			& MCXX_SETUP_MASK) << MCXX_SETUP_SHIFT)
+			| ((pxa2xx_mcxx_asst(speed, clock)
+			& MCXX_ASST_MASK) << MCXX_ASST_SHIFT)
+			| ((pxa2xx_mcxx_hold(speed, clock)
+			& MCXX_HOLD_MASK) << MCXX_HOLD_SHIFT);
+	}
+
+	return ret;
 }
 
 static int pxa2xx_core_pcmcia_set_mcxx(struct pxa2xx_pcmcia_socket *skt, unsigned int cpu_clock)
 {
-	int sock = skt->nr;
-
-	pxa2xx_core_pcmcia_set_mcmem( sock, PXA_PCMCIA_5V_MEM_ACCESS, cpu_clock );
-	pxa2xx_core_pcmcia_set_mcatt( sock, PXA_PCMCIA_ATTR_MEM_ACCESS, cpu_clock );
-	pxa2xx_core_pcmcia_set_mcio( sock, PXA_PCMCIA_IO_ACCESS, cpu_clock );
+	pxa2xx_core_pcmcia_set_mcmem( skt, PXA_PCMCIA_5V_MEM_ACCESS, cpu_clock );
+	pxa2xx_core_pcmcia_set_mcatt( skt, PXA_PCMCIA_ATTR_MEM_ACCESS, cpu_clock );
+	pxa2xx_core_pcmcia_set_mcio( skt, PXA_PCMCIA_IO_ACCESS, cpu_clock );
 
 	return 0;
 }
@@ -466,7 +461,7 @@
 	}
 
 	skt->spd_io[map->map] = speed;
-	pxa2xx_core_pcmcia_set_mcio( skt->nr, speed, get_lclk_frequency_10khz() );
+	pxa2xx_core_pcmcia_set_mcio( skt, speed, get_lclk_frequency_10khz() );
 
 	if (map->stop == 1)
 		map->stop = PAGE_SIZE-1;
@@ -521,12 +516,12 @@
 		res = &skt->res_attr;
 		skt->spd_attr[map->map] = speed;
 		skt->spd_mem[map->map] = 0;
-		pxa2xx_core_pcmcia_set_mcatt( skt->nr, speed, get_lclk_frequency_10khz() );
+		pxa2xx_core_pcmcia_set_mcatt( skt, speed, get_lclk_frequency_10khz() );
 	} else {
 		res = &skt->res_mem;
 		skt->spd_attr[map->map] = 0;
 		skt->spd_mem[map->map] = speed;
-		pxa2xx_core_pcmcia_set_mcmem( skt->nr, speed , get_lclk_frequency_10khz());
+		pxa2xx_core_pcmcia_set_mcmem( skt, speed , get_lclk_frequency_10khz());
 	}
 
 	map->sys_stop -= map->sys_start;
@@ -711,15 +706,6 @@
 	struct pcmcia_low_level *ops;
 	int first, nr;
 
-#if 0
-	/* FIXME: fix this for pxa or kill it
-	 * set default MECR calculation if the board specific
-	 * code did not specify one...
-	 */
-	if (!ops->socket_get_timing)
-		ops->socket_get_timing = pxa2xx_pcmcia_default_mecr_timing;
-#endif
-	
 	if (!dev || !dev->platform_data)
 		goto out;
 
@@ -977,11 +963,11 @@
 
 	down(&pxa2xx_sockets_lock);
 	list_for_each_entry(skt, &pxa2xx_sockets, node) {
-		pxa2xx_core_pcmcia_set_mcio(skt->nr, calc_speed(skt->spd_io,
+		pxa2xx_core_pcmcia_set_mcio(skt, calc_speed(skt->spd_io,
 					MAX_IO_WIN, PXA_PCMCIA_IO_ACCESS), clock);
-		pxa2xx_core_pcmcia_set_mcmem(skt->nr, calc_speed(skt->spd_io,
+		pxa2xx_core_pcmcia_set_mcmem(skt, calc_speed(skt->spd_io,
 					MAX_IO_WIN, PXA_PCMCIA_3V_MEM_ACCESS), clock );
-		pxa2xx_core_pcmcia_set_mcatt(skt->nr, calc_speed(skt->spd_io,
+		pxa2xx_core_pcmcia_set_mcatt(skt, calc_speed(skt->spd_io,
 					MAX_IO_WIN, PXA_PCMCIA_3V_MEM_ACCESS), clock );
 	}
 	up(&pxa2xx_sockets_lock);
From komurojun at mbn.nifty.com  Wed Jun 30 08:31:56 2004
From: komurojun at mbn.nifty.com (Komuro)
Date: Wed Jun 30 08:32:06 2004
Subject: 2.6.x kernels & PCI-to-PCMCIA bridges [again]
In-Reply-To: <20040629141442.B24951@flint.arm.linux.org.uk>
References: <20040629141442.B24951@flint.arm.linux.org.uk>
	<20040628154327.A9214@flint.arm.linux.org.uk>
	<7343708.1088428841823.komurojun@mbn.nifty.com>
	<20040628154327.A9214@flint.arm.linux.org.uk>
	<6508031.1088513594611.komurojun@mbn.nifty.com>
Message-ID: <1257111.1088598716778.komurojun@mbn.nifty.com>

>> >Actually, its right.  You've programmed the memory start/stop registers
>> >with sys_start and sys_stop.  Since card_start = 0, you want accesses
>> >to physical address "sys_start" to correspond with card address
>> >"card_start".  So, if card_start = 0, you need to program the offset
>> >register (I365_W_OFF) with -sys_start to achieve the required address
>> >on the PCMCIA bus.
>> 


See the following example, please.

We assume that mem->sys_start is 0x0a0000000
and we want mem->card_start = 0. 
Note that 0x0a0000000 is 32bit number.

((mem->card_start - mem->sys_start) >> 12) & 0x3fff
= ((0 - 0x0a0000000) >> 12 ) & 0x3fff
= (0x60000000 >> 12) & 0x3fff
= 0x60000 & 0x3fff
= 0  
strange and wrong!

Best Regards
Komuro



From rmk+pcmcia at arm.linux.org.uk  Wed Jun 30 08:45:27 2004
From: rmk+pcmcia at arm.linux.org.uk (Russell King)
Date: Wed Jun 30 08:45:37 2004
Subject: 2.6.x kernels & PCI-to-PCMCIA bridges [again]
In-Reply-To: <1257111.1088598716778.komurojun@mbn.nifty.com>;
	from komurojun@mbn.nifty.com on Wed, Jun 30, 2004 at 09:31:56PM
	+0900
References: <20040629141442.B24951@flint.arm.linux.org.uk>
	<20040628154327.A9214@flint.arm.linux.org.uk>
	<7343708.1088428841823.komurojun@mbn.nifty.com>
	<20040628154327.A9214@flint.arm.linux.org.uk>
	<6508031.1088513594611.komurojun@mbn.nifty.com>
	<20040629141442.B24951@flint.arm.linux.org.uk>
	<1257111.1088598716778.komurojun@mbn.nifty.com>
Message-ID: <20040630134527.A19234@flint.arm.linux.org.uk>

On Wed, Jun 30, 2004 at 09:31:56PM +0900, Komuro wrote:
> We assume that mem->sys_start is 0x0a0000000
> and we want mem->card_start = 0. 
> Note that 0x0a0000000 is 32bit number.
> 
> ((mem->card_start - mem->sys_start) >> 12) & 0x3fff
> = ((0 - 0x0a0000000) >> 12 ) & 0x3fff
> = (0x60000000 >> 12) & 0x3fff
> = 0x60000 & 0x3fff
> = 0  
> strange and wrong!

strange and correct.  Work it back to the original relationship given
in the data sheet.

	26-bit card address = memory address + 26-bit offset address

which is:

	                    = 0xa0000000 + 0x00000000

And 0xa0000000 as a 26-bit address is 0x00000000.  This happens to
be your card_start.

Therefore, your example _is_ correct.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

From smarkou at patras.atmel.com  Wed Jun 30 07:09:41 2004
From: smarkou at patras.atmel.com (Stavros Markou)
Date: Wed Jun 30 09:32:44 2004
Subject: cardctl eject problem
Message-ID: <40E29F75.4090607@patras.atmel.com>

Hi,

I am developing a wireless network driver and I am having problems to 
eject the pcmcia card. Even though I am sending a cardctl eject command,
nothing happens. Module's usage count is 1 and neither detach, nor 
release function is called at all.
Can you give me a hint ?

Tanks In Advance,

Stavros Markou.

