Re: Questions about ioport-assignments
Thanks for your assistance, guys! Very much appreciated. I will be busy until Sunday, so I can't do much testing and debugging until then. > It seems the card tries to request the ioport 0x300, > but alloc_io_space (in pcmcia_resource.c) added 0xc000 accidentally . > then ioport becomes 0xc300. That's strange. I attach the output of dump_cis: Socket 0 offset 0x02, tuple 0x01, link 0x02 00 ff dev_info no_info offset 0x06, tuple 0x15, link 0x13 04 01 44 2d 4c 69 6e 6b 00 44 4d 46 35 36 30 54 58 00 ff vers_1 4.1, "D-Link", "DMF560TX" offset 0x1b, tuple 0x20, link 0x04 43 01 ab c0 manfid 0x0143, 0xc0ab offset 0x21, tuple 0x21, link 0x02 00 00 funcid multi_function offset 0x25, tuple 0x1a, link 0x05 01 1b e0 ff 67 config base 0xffe0 mask 0x0067 last_index 0x1b offset 0x2c, tuple 0x1b, link 0x16 c3 41 99 79 55 3d 86 46 26 4c ea 61 f8 02 07 00 03 1f f0 38 9e 28 cftable_entry 0x03 [default] [rdybsy] [audio] [pwrdown] Vcc Vnom 5V Istatic 35mA Iavg 170mA Ipeak 200mA Idown 4500uA io 0x02f8-0x02ff, 0x0300-0x031f [lines=10] [8bit] [16bit] [range] irq mask 0x9e38 [level] [pulse] [shared] offset 0x44, tuple 0x1b, link 0x0a 05 08 ea 61 e8 03 07 00 03 1f cftable_entry 0x05 io 0x03e8-0x03ef, 0x0300-0x031f [lines=10] [8bit] [16bit] [range] offset 0x50, tuple 0x1b, link 0x0a 07 08 ea 61 e8 02 07 00 03 1f cftable_entry 0x07 io 0x02e8-0x02ef, 0x0300-0x031f [lines=10] [8bit] [16bit] [range] offset 0x5c, tuple 0x1b, link 0x0a 09 08 ea 61 f8 02 07 20 03 1f cftable_entry 0x09 io 0x02f8-0x02ff, 0x0320-0x033f [lines=10] [8bit] [16bit] [range] offset 0x68, tuple 0x1b, link 0x0a 0b 08 ea 61 e8 03 07 20 03 1f cftable_entry 0x0b io 0x03e8-0x03ef, 0x0320-0x033f [lines=10] [8bit] [16bit] [range] offset 0x74, tuple 0x1b, link 0x0a 0d 08 ea 61 e8 02 07 20 03 1f cftable_entry 0x0d io 0x02e8-0x02ef, 0x0320-0x033f [lines=10] [8bit] [16bit] [range] offset 0x80, tuple 0x1b, link 0x0a 0f 08 ea 61 f8 02 07 40 03 1f cftable_entry 0x0f io 0x02f8-0x02ff, 0x0340-0x035f [lines=10] [8bit] [16bit] [range] offset 0x8c, tuple 0x1b, link 0x0a 11 08 ea 61 e8 03 07 40 03 1f cftable_entry 0x11 io 0x03e8-0x03ef, 0x0340-0x035f [lines=10] [8bit] [16bit] [range] offset 0x98, tuple 0x1b, link 0x0a 13 08 ea 61 e8 02 07 40 03 1f cftable_entry 0x13 io 0x02e8-0x02ef, 0x0340-0x035f [lines=10] [8bit] [16bit] [range] offset 0xa4, tuple 0x1b, link 0x0a 15 08 ea 61 f8 02 07 20 02 1f cftable_entry 0x15 io 0x02f8-0x02ff, 0x0220-0x023f [lines=10] [8bit] [16bit] [range] offset 0xb0, tuple 0x1b, link 0x0a 17 08 ea 61 e8 03 07 20 02 1f cftable_entry 0x17 io 0x03e8-0x03ef, 0x0220-0x023f [lines=10] [8bit] [16bit] [range] offset 0xbc, tuple 0x1b, link 0x0a 19 08 ea 61 e8 02 07 20 02 1f cftable_entry 0x19 io 0x02e8-0x02ef, 0x0220-0x023f [lines=10] [8bit] [16bit] [range] offset 0xc8, tuple 0x1b, link 0x0a 1b 08 ea 61 f8 02 07 40 02 0f cftable_entry 0x1b io 0x02f8-0x02ff, 0x0240-0x024f [lines=10] [8bit] [16bit] [range] As you see, there is no entry with io=0x. But lines is always 10, so the alignment is always 1 << 10 = 0x400. As I understood, 0xc000 matches this alignment requirement and the 0x300 from the first entry gets added to this. I thought this is all valid and the card should find its registers, but it doesn't :( But I may be really missing a point here... > so I think alloc_io_space should be fixed. I was wondering that, too... Thanks again, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Questions about ioport-assignments
Hi, >> >- Is it just a buggy card if it works at 0x300 but not 0xc300 >> > (or is it maybe a problem with Linux assigning the io area)? >> >- Why is IOAddrLines forced to 16 (and thus alignment to 0x1), but only >> > if BasePort1 is 0? >> >> Some pcmcia-card decodes only lower 10bits (0x-0x03FF). >> Such card does not work on higher ports (0x0400-0x) >> > >Quick'n'Dirty patch -- or should we handle this generically, Komuro? Any way >to reliably detect these cards? I think your patch is not correct. >> >- Is it just a buggy card if it works at 0x300 but not 0xc300 It seems the card tries to request the ioport 0x300, but alloc_io_space (in pcmcia_resource.c) added 0xc000 accidentally . then ioport becomes 0xc300. That's strange. so I think alloc_io_space should be fixed. Best Regards Komuro ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Questions about ioport-assignments
Hey,
On Thu, Jan 14, 2010 at 08:39:17PM +0900, Komuro wrote:
> Hi,
>
> >- Is it just a buggy card if it works at 0x300 but not 0xc300
> > (or is it maybe a problem with Linux assigning the io area)?
> >- Why is IOAddrLines forced to 16 (and thus alignment to 0x1), but only
> > if BasePort1 is 0?
>
> Some pcmcia-card decodes only lower 10bits (0x-0x03FF).
> Such card does not work on higher ports (0x0400-0x)
>
> So your card is not a buggy card.
Quick'n'Dirty patch -- or should we handle this generically, Komuro? Any way
to reliably detect these cards?
Best,
Dominik
diff --git a/drivers/net/pcmcia/pcnet_cs.c b/drivers/net/pcmcia/pcnet_cs.c
index 776cad2..8f03bd0 100644
--- a/drivers/net/pcmcia/pcnet_cs.c
+++ b/drivers/net/pcmcia/pcnet_cs.c
@@ -89,6 +89,7 @@ INT_MODULE_PARM(delay_output, 0); /* pause after xmit? */
INT_MODULE_PARM(delay_time,4); /* in usec */
INT_MODULE_PARM(use_shmem, -1);/* use shared memory? */
INT_MODULE_PARM(full_duplex, 0); /* full duplex? */
+INT_MODULE_PARM(lowport, 0); /* full duplex? */
/* Ugh! Let the user hardwire the hardware address for queer cards */
static int hw_addr[6] = { 0, /* ... */ };
@@ -497,11 +498,15 @@ static int try_io_port(struct pcmcia_device *link)
link->io.Attributes1 = IO_DATA_PATH_WIDTH_8;
link->io.Attributes2 = IO_DATA_PATH_WIDTH_16;
}
+if (lowport && link->io.BasePort1 >= 0x0400)
+ return -EINVAL;
if (link->io.BasePort1 == 0) {
link->io.IOAddrLines = 16;
for (j = 0; j < 0x400; j += 0x20) {
link->io.BasePort1 = j ^ 0x300;
link->io.BasePort2 = (j ^ 0x300) + 0x10;
+ if (lowport && link->io.BasePort1 >= 0x0400)
+ continue;
ret = pcmcia_request_io(link, &link->io);
if (ret == 0)
return ret;
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [PATCH] ide/ide-cs: fix order of releasing resources
> > bzolnier: > > - release resources in ide_release() to fix ordering of events > > - remove stale FIXME note while at it > > Ok this does look better, Wolfram can you test this? ACK, looks better. I will test it, might not happen before Sunday, though. -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [PATCH] ide/ide-cs: fix order of releasing resources
From: Bartlomiej Zolnierkiewicz Date: Thu, 14 Jan 2010 16:50:17 +0100 > bzolnier: > - release resources in ide_release() to fix ordering of events > - remove stale FIXME note while at it Ok this does look better, Wolfram can you test this? ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
