Re: Questions about ioport-assignments

2010-05-10 Thread Dominik Brodowski
Hey,

On Sun, May 09, 2010 at 09:11:15PM +0900, Komuro wrote:
> > >>- 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 onl
> y
> > >>  if BasePort1 is 0?
> > 
> >
> >In this case, 
> >start = 0xc000, 
> >align_data->mask = 0x3ff, 
> >align_data->offset = 0x300
> >then ret becomes 0xc300;
> >
> >but ret should be 0x300.
> 
> 
> "pci_find_parent_resource" only finds the io-window of cardbus bridge.

It only finds IO windows which also the parent Cardbus bridge can see.
However, other IO areas (even if they are added by pmcia-socket-startup) may
not be "seen" by the parent Cardbus bridge. Thus they may not be available
for use, even for PCMCIA. THerefore, the current behaviour seems proper.

Best,
Dominik

___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia


Re: Questions about ioport-assignments

2010-05-09 Thread Komuro
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 onl
y
> >>  if BasePort1 is 0?
> 
>
>In this case, 
>start = 0xc000, 
>align_data->mask = 0x3ff, 
>align_data->offset = 0x300
>then ret becomes 0xc300;
>
>but ret should be 0x300.


"pci_find_parent_resource" only finds the io-window of cardbus bridge.

I think the claim_region should find the io-area added by pcmcia-socket-startu
p.


claim_region(struct pcmcia_socket *s, resource_size_t base,
resource_size_t size, int type, char *name)
{
struct resource *res, *parent;

parent = type & IORESOURCE_MEM ? &iomem_resource : &ioport_resource;
res = make_resource(base, size, type | IORESOURCE_BUSY, name);

if (res) {
#ifdef CONFIG_PCI
if (s && s->cb_dev)
parent = pci_find_parent_resource(s->cb_dev, res);
#endif


Komuro


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia


Re: Questions about ioport-assignments

2010-04-18 Thread Dominik Brodowski
Hey,

On Sun, Apr 18, 2010 at 10:11:41AM +0900, Komuro wrote:
> 
> Hi,
> 
> >Hm, I don't get (yet) where you're heading to -- could you provide me with a
> >patch and/or more extensive explanation?
> 
> OK. Here is the patch.
> 
> pci_bus_alloc_resource calls pcmcia_align with res->start=0xc000.
> To avoid this , we need to call pcmcia_align manually.
> 
> 
> 
> --- linux-2.6.34-rc4-git4/drivers/pcmcia/rsrc_nonstatic.c.orig
> 2010-04-18 09:52:12.0 +0900
> +++ linux-2.6.34-rc4-git4/drivers/pcmcia/rsrc_nonstatic.c 2010-04-18 
> 09:56:09.0 +0900
> @@ -697,6 +697,9 @@ static struct resource *nonstatic_find_i
>   struct pcmcia_align_data data;
>   unsigned long min = base;
>   int ret;
> +#if defined(CONFIG_X86)
> + resource_size_t start;
> +#endif
>  
>   if (align == 0)
>   align = 0x1;
> @@ -705,6 +708,16 @@ static struct resource *nonstatic_find_i
>   data.offset = base & data.mask;
>   data.map = &s_data->io_db;
>  
> +#if defined(CONFIG_X86)
> + start = pcmcia_align(&data, res, num, align);
> +
> + if (start) {
> + res->start = start;
> + res->end = start+num-1;
> + return res;
> + }
> +#endif
> +
>  #ifdef CONFIG_PCI
>   if (s->cb_dev) {
>   ret = pci_bus_alloc_resource(s->cb_dev->bus, res, num, 1,

No, that can't be right -- see commits 509b0865 and 7a96e87d , both based on
reports from you, on why we need to call pci_bus_alloc_resource...

Best,
Dominik


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia


Re: Questions about ioport-assignments

2010-04-17 Thread Komuro

Hi,

>Hm, I don't get (yet) where you're heading to -- could you provide me with a
>patch and/or more extensive explanation?

OK. Here is the patch.

pci_bus_alloc_resource calls pcmcia_align with res->start=0xc000.
To avoid this , we need to call pcmcia_align manually.



--- linux-2.6.34-rc4-git4/drivers/pcmcia/rsrc_nonstatic.c.orig  2010-04-18 
09:52:12.0 +0900
+++ linux-2.6.34-rc4-git4/drivers/pcmcia/rsrc_nonstatic.c   2010-04-18 
09:56:09.0 +0900
@@ -697,6 +697,9 @@ static struct resource *nonstatic_find_i
struct pcmcia_align_data data;
unsigned long min = base;
int ret;
+#if defined(CONFIG_X86)
+   resource_size_t start;
+#endif
 
if (align == 0)
align = 0x1;
@@ -705,6 +708,16 @@ static struct resource *nonstatic_find_i
data.offset = base & data.mask;
data.map = &s_data->io_db;
 
+#if defined(CONFIG_X86)
+   start = pcmcia_align(&data, res, num, align);
+
+   if (start) {
+   res->start = start;
+   res->end = start+num-1;
+   return res;
+   }
+#endif
+
 #ifdef CONFIG_PCI
if (s->cb_dev) {
ret = pci_bus_alloc_resource(s->cb_dev->bus, res, num, 1,

___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia


Re: Questions about ioport-assignments

2010-04-17 Thread Wolfram Sang
> > io-res1  0xc000-0xcfff
> > io-res2  0x0100-0x03ff
> > 
> 
> Hm, I don't get (yet) where you're heading to -- could you provide me with a
> patch and/or more extensive explanation?

Do you have the complete thread?

http://thread.gmane.org/gmane.linux.kernel.pcmcia.devel/2884

-- 
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

2010-04-17 Thread Dominik Brodowski
On Sat, Apr 17, 2010 at 07:47:48PM +0900, Komuro wrote:
> 
> Hi,
> 
> [solution]
> 
> If we have two io-resource io-res1, io-res2 (for example)
> we try to allocate io-resource from io-res2(lower ioport).
> 
> if it fails , try to allocate io-resource from io-res1.
> 
> 
> io-res1  0xc000-0xcfff
> io-res2  0x0100-0x03ff
> 

Hm, I don't get (yet) where you're heading to -- could you provide me with a
patch and/or more extensive explanation?

Best,
Dominik

___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia


Re: Questions about ioport-assignments

2010-04-17 Thread Komuro

Hi,

[solution]

If we have two io-resource io-res1, io-res2 (for example)
we try to allocate io-resource from io-res2(lower ioport).

if it fails , try to allocate io-resource from io-res1.


io-res1  0xc000-0xcfff
io-res2  0x0100-0x03ff


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia


Re: Questions about ioport-assignments

2010-04-16 Thread Wolfram Sang
> sorry, "lines" seems to be align.
> 
> but some devices with lines=10,
> it means max io-port = 0x3ff.

This would lead to consider the CIS of the card broken and override it? (And
the fact that it used to work was just Linux doing the assignment "wrong" back
then?)

Regards,

   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

2010-04-16 Thread Komuro
Hi,

sorry, "lines" seems to be align.

but some devices with lines=10,
it means max io-port = 0x3ff.

___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia


Re: Questions about ioport-assignments

2010-04-16 Thread Komuro
Hi,

>That's not pcmcia_common_align()s fault -- but this line in alloc_io_space:
>
>   align = (*base) ? (lines ? 1<
>Should we try replacing it with
>
>   align = lines ? 1 << lines : 0;
>
>unconditionally?


In this case, *base = 0x300
So 
align = (*base) ? (lines ? 1

Re: Questions about ioport-assignments

2010-04-16 Thread Dominik Brodowski
On Fri, Apr 16, 2010 at 10:21:35PM +0900, Komuro wrote:
> Hi,
> 
> > Wolfram wrote:
> > 
> > >>- 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?
> > 
> 
> In this case, 
> start = 0xc000, 
> align_data->mask = 0x3ff, 
> align_data->offset = 0x300
> then ret becomes 0xc300;
> 
> but ret should be 0x300.

That's not pcmcia_common_align()s fault -- but this line in alloc_io_space:

align = (*base) ? (lines ? 1

Re: Questions about ioport-assignments

2010-04-16 Thread Komuro
Hi,

> Wolfram wrote:
> 
> >>- 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?
> 

In this case, 
start = 0xc000, 
align_data->mask = 0x3ff, 
align_data->offset = 0x300
then ret becomes 0xc300;

but ret should be 0x300.

static resource_size_t pcmcia_common_align(struct pcmcia_align_data *align_data,
resource_size_t start)
{
resource_size_t ret;
/*
 * Ensure that we have the correct start address
 */
ret = (start & ~align_data->mask) + align_data->offset;
if (ret < start)
ret += align_data->mask + 1;

return ret;
}

Best Regards
Komuro

___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia


Re: Questions about ioport-assignments

2010-02-21 Thread Wolfram Sang
Hello Komuro,

On Sun, Feb 21, 2010 at 08:09:51PM +0900, Komuro wrote:

> Could you post the patch you made for D-Link DMF560TX?
> 
> This problem is not fixed yet.

The patch I used is here:

http://article.gmane.org/gmane.linux.kernel.pcmcia.devel/2884

Sadly, I cannot do any tests for a few months as I am in Japan for that time
and the card belongs to a friend of mine (who still is in Germany). Interesting
enough, shortly before I left we accidently found out that the card works with
a standard Debian kernel (2.6.30 IIRC) and a TI-controller. My laptops all had
O2-controllers. Sadly again, there was no time left to debug further in that
direction.

Kind regards,

  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

2010-02-21 Thread Komuro
Wolfram wrote:

>>- 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?

>Sorry, today I got this (after applying the patch to make my D-Link DMF560TX
>work):

Could you post the patch you made for D-Link DMF560TX?

This problem is not fixed yet.



Best Regards
Komuro


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia


Re: Questions about ioport-assignments

2010-01-15 Thread Wolfram Sang
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

2010-01-15 Thread Komuro
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

2010-01-15 Thread Dominik Brodowski
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: Questions about ioport-assignments

2010-01-14 Thread Komuro
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.


Best Regards
Komuro

___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia