Card Memory windows in client driver - how to access ?
I have a 16 bit PCMCIA card driver I am working on which requires memory
windows to read and write both attribute and common memory. Card needs only
memory windows to work (no IO or irq).
I use the foll. method to get access to the card memory windows after
setting up the window attributes appropriately
link->conf.ConfigBase = parse.config.base;
link->conf.Present = parse.config.rmask[0];
link->conf.IntType = INT_MEMORY;
dev->request_attr_memory.Attributes = ( WIN_DATA_WIDTH_8 |
WIN_MEMORY_TYPE_AM | WIN_ENABLE );
dev->request_attr_memory.Base = 0;
dev->request_attr_memory.Size = 0x1000;
dev->request_attr_memory.AccessSpeed = 200;
ret = pcmcia_request_window(&link, &dev->request_attr_memory,
&dev->handle_attr_memory);
if (ret != 0) {
cs_error(link, RequestWindow, ret);
}
memreq_attr_memory.CardOffset = 0;
memreq_attr_memory.Page = 0;
ret = pcmcia_map_mem_page(dev->handle_attr_memory, &memreq_attr_memory);
if (ret != 0) {
cs_error(link, MapMemPage, ret);}
dev->attr_memory = ioremap( dev->request_attr_memory.Base,
dev->request_attr_memory.Size);
All the above succeed and then I call pcmcia_request_configuration
Now if I try to dump say the first 512 bytes of memory at the address
returned by ioremap - the bytes there dont look anything like what I am
supposed to see in the CIS. In fact they are all 0's. Same with common
memory window that I request and create like the above except for the size
and attribute being differnet
So I am obviously not doing something right here
Any pointers on what I am/could be doing wrong will be much appreciated.
Thanks
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: pci_bus_for_each_resource, transparent bridges and rsrc_nonstatic.c
On Mon, Mar 22, 2010 at 04:11:33PM -0700, Bjorn Helgaas wrote: > > (1) The root PCI bus has _CRS I/O -0cf7; 0d00- "produced"; > > > > the (transparent) PCI-PCI bridge offers, as bus resources, to > > downstream users 0x4000-0x4fff plus everything else because of > > subtractive decoding; > > > > there is a yenta-style PCI-CardBus/PCMCIA bridge below this > > PCI-PCI bridge. > > > > (2) There are some I/O ports which react rather unfriendly to being read or > > written. Let's assume they're at 0x100-0x10f; and let's also assume that > > the BIOS writers forgot to mention them at all in the ACPI _CRS > > settings; no other part of the kernel knows about it. > > > > -0cf7 : PCI Bus :00 > > ... > > 00f0-00ff : fpu > > 0170-0177 : :00:1f.2 > > > > > > (3) A PCMCIA card is inserted. It needs an I/O port resource of size 8. The > > PCMCIA subsystem looks in its own resource database which I/O ports it > > may use; there, it finds not only 0x4000-0x4fff but (with a small > > exception) 0x-0x; as 0x-0x00ff are already assigned, it > > happily assigns the first free area -- 0x100-0x108 -- to the PCMCIA > > card. > > > > -0cf7 : PCI Bus :00 > > ... > > 00f0-00ff : fpu > > 0100-0108 : pcmcia0.0 > > 0170-0177 : :00:1f.2 > > > > (4) The PCMCIA card and the PCMCIA driver are set up to work with an IO > > resource at 0x100-0x108. As soon as they attempt to use this resource, > > bad things happen (lockups, etc.) because of the reasons spelled out at > > (2). > > We'd have exactly the same situation if we assigned I/O port 0x100 > to a PCI device. Why can't we use the same strategy PCI uses to > avoid it? Well, PCI devices have three advantages: - they can more easily be "enumerated" (and their resource needs reflected) by ACPI or the BIOS. - they usually don't conflict with ISA-style hardware(?) - they usually work happily with any (even high) I/O ports. > > => It is only an issue if the ACPI resource descriptions are incomplete. It > > is worse for PCMCIA because it happily assigns resources below 0x1000, where > > such system/platform devices usually listen to. And usecrs worsens the > > situation also in another regard: on my own laptop (a pre-2008 model), > > pci=use_crs makes the PCI-PCI bridge to be marked as "transparent", while > > pci=nocrs means the PCI-PCI bridge is assumed to be "non-transparent". > > Sorry to be slow again... The pci=use_crs and pci=nocrs options only > affect the PCI host bridge; they don't affect PCI-PCI bridges at all, > except that they change the set of resources available for subtractive- > decode PCI-PCI bridges to forward. (Strictly speaking, they don't > affect the *behavior* of the PCI-PCI bridges, they only affect our > *idea* of what they're doing.) > > I'm thinking of the code in pci_setup_device() where we set dev->transparent > based on the bridge's class code. Obviously, you must be thinking > of something else. > > My intention was that on pre-2008 systems like your laptop, my patches > would not change any behavior at all, unless you boot with "pci=use_crs". > Are you seeing an unexpected change on your system? No, that's excactly what I'm seeing here. On pre-2008 system, the behavior is still the same; no unexpected change; all fine unless I boot with "pci=use_crs". In contrast, on post-2008 systems like Komuros system, we now trust to ACPI report _all_ resource users. If ACPI gets this right, I don't see a real problem (but I might add a safety check to avoid any I/O ports < 0x0100 anyway). The remaining question: can we safely trust BIOS authors to get it right? Dominik ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: pci_bus_for_each_resource, transparent bridges and rsrc_nonstatic.c
On Monday 22 March 2010 04:52:35 pm Dominik Brodowski wrote: > Hey, > > On Mon, Mar 22, 2010 at 03:28:55PM -0700, Bjorn Helgaas wrote: > > On Monday 22 March 2010 02:51:21 pm Dominik Brodowski wrote: > > > On Mon, Mar 22, 2010 at 01:36:03PM -0700, Bjorn Helgaas wrote: > > > > > You can still use subtractive-decoded resources, but then you have to > > > > > add > > > > > them to /etc/pcmcia/config.opts and run pcmcia-startup-bridges (or > > > > > echo the > > > > > resource to a sysfs file). > > > > > > > > It's too bad we still have such manual configuration. > > > > > > Agreed. > > > > > > > Is there still > > > > information there that we can't figure out automatically? > > > > > > That's unknown to me -- are there any ISA-capable systems being sold? If > > > so, > > > then I suspect the answer may be "yes". > > > > > > > > Now, "usecrs" is only used on 2008-or-newer systems where we _hope_ > > > > > that all > > > > > resource "consumers" are accounted for. So the problem might be > > > > > mitigated. > > > > > However, I wouldn't dare to use ioports 0x0-0xff anyways for they > > > > > usually > > > > > are used for onboard legacy devices... > > > > > > > > Right. But PCMCIA is at no greater risk than regular PCI, right? > > > > It looks like both will allocate only above PCIBIOS_MIN_IO (0x1000). > > > > > > No, PCMCIA will happily allocate below this limit. > > > > I saw "#define PCIBIOS_MIN_CARDBUS_IO PCIBIOS_MIN_IO" in yenta_socket.c > > and assumed it would take care of this, but I didn't look any deeper. > > > > I'm still confused about why PCMCIA is "special" in this regard and > > why pci=use_crs breaks it. Can you make up an example that illustrates > > the problem? > > Consider the following case: Thanks! Sorry to be so dense here ... > (1) The root PCI bus has _CRS I/O -0cf7; 0d00- "produced"; > > the (transparent) PCI-PCI bridge offers, as bus resources, to > downstream users 0x4000-0x4fff plus everything else because of > subtractive decoding; > > there is a yenta-style PCI-CardBus/PCMCIA bridge below this > PCI-PCI bridge. > > (2) There are some I/O ports which react rather unfriendly to being read or > written. Let's assume they're at 0x100-0x10f; and let's also assume that > the BIOS writers forgot to mention them at all in the ACPI _CRS > settings; no other part of the kernel knows about it. > > -0cf7 : PCI Bus :00 > ... > 00f0-00ff : fpu > 0170-0177 : :00:1f.2 > > > (3) A PCMCIA card is inserted. It needs an I/O port resource of size 8. The > PCMCIA subsystem looks in its own resource database which I/O ports it > may use; there, it finds not only 0x4000-0x4fff but (with a small > exception) 0x-0x; as 0x-0x00ff are already assigned, it > happily assigns the first free area -- 0x100-0x108 -- to the PCMCIA > card. > > -0cf7 : PCI Bus :00 > ... > 00f0-00ff : fpu > 0100-0108 : pcmcia0.0 > 0170-0177 : :00:1f.2 > > (4) The PCMCIA card and the PCMCIA driver are set up to work with an IO > resource at 0x100-0x108. As soon as they attempt to use this resource, > bad things happen (lockups, etc.) because of the reasons spelled out at > (2). We'd have exactly the same situation if we assigned I/O port 0x100 to a PCI device. Why can't we use the same strategy PCI uses to avoid it? > => It is only an issue if the ACPI resource descriptions are incomplete. It > is worse for PCMCIA because it happily assigns resources below 0x1000, where > such system/platform devices usually listen to. And usecrs worsens the > situation also in another regard: on my own laptop (a pre-2008 model), > pci=use_crs makes the PCI-PCI bridge to be marked as "transparent", while > pci=nocrs means the PCI-PCI bridge is assumed to be "non-transparent". Sorry to be slow again... The pci=use_crs and pci=nocrs options only affect the PCI host bridge; they don't affect PCI-PCI bridges at all, except that they change the set of resources available for subtractive- decode PCI-PCI bridges to forward. (Strictly speaking, they don't affect the *behavior* of the PCI-PCI bridges, they only affect our *idea* of what they're doing.) I'm thinking of the code in pci_setup_device() where we set dev->transparent based on the bridge's class code. Obviously, you must be thinking of something else. My intention was that on pre-2008 systems like your laptop, my patches would not change any behavior at all, unless you boot with "pci=use_crs". Are you seeing an unexpected change on your system? Bjorn ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Boot options acpi=off pci=biosirq dmesg
Ah, we're getting closer! The CardBus bridge should be using IRQ 10, but the BIOS does not report this. What happens if you use acpi=off pci=biosirq irqfixup or even acpi=off pci=biosirq irqpoll as kernel options? Please try out inserting the USB card into _both_ sockets (if there are two), and send the resulting "dmesg" if it fails. Thanks and best, Dominik ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: pci_bus_for_each_resource, transparent bridges and rsrc_nonstatic.c
Hey, On Mon, Mar 22, 2010 at 03:28:55PM -0700, Bjorn Helgaas wrote: > On Monday 22 March 2010 02:51:21 pm Dominik Brodowski wrote: > > On Mon, Mar 22, 2010 at 01:36:03PM -0700, Bjorn Helgaas wrote: > > > > You can still use subtractive-decoded resources, but then you have to > > > > add > > > > them to /etc/pcmcia/config.opts and run pcmcia-startup-bridges (or echo > > > > the > > > > resource to a sysfs file). > > > > > > It's too bad we still have such manual configuration. > > > > Agreed. > > > > > Is there still > > > information there that we can't figure out automatically? > > > > That's unknown to me -- are there any ISA-capable systems being sold? If so, > > then I suspect the answer may be "yes". > > > > > > Now, "usecrs" is only used on 2008-or-newer systems where we _hope_ > > > > that all > > > > resource "consumers" are accounted for. So the problem might be > > > > mitigated. > > > > However, I wouldn't dare to use ioports 0x0-0xff anyways for they > > > > usually > > > > are used for onboard legacy devices... > > > > > > Right. But PCMCIA is at no greater risk than regular PCI, right? > > > It looks like both will allocate only above PCIBIOS_MIN_IO (0x1000). > > > > No, PCMCIA will happily allocate below this limit. > > I saw "#define PCIBIOS_MIN_CARDBUS_IO PCIBIOS_MIN_IO" in yenta_socket.c > and assumed it would take care of this, but I didn't look any deeper. > > I'm still confused about why PCMCIA is "special" in this regard and > why pci=use_crs breaks it. Can you make up an example that illustrates > the problem? Consider the following case: (1) The root PCI bus has _CRS I/O -0cf7; 0d00- "produced"; the (transparent) PCI-PCI bridge offers, as bus resources, to downstream users 0x4000-0x4fff plus everything else because of subtractive decoding; there is a yenta-style PCI-CardBus/PCMCIA bridge below this PCI-PCI bridge. (2) There are some I/O ports which react rather unfriendly to being read or written. Let's assume they're at 0x100-0x10f; and let's also assume that the BIOS writers forgot to mention them at all in the ACPI _CRS settings; no other part of the kernel knows about it. -0cf7 : PCI Bus :00 ... 00f0-00ff : fpu 0170-0177 : :00:1f.2 (3) A PCMCIA card is inserted. It needs an I/O port resource of size 8. The PCMCIA subsystem looks in its own resource database which I/O ports it may use; there, it finds not only 0x4000-0x4fff but (with a small exception) 0x-0x; as 0x-0x00ff are already assigned, it happily assigns the first free area -- 0x100-0x108 -- to the PCMCIA card. -0cf7 : PCI Bus :00 ... 00f0-00ff : fpu 0100-0108 : pcmcia0.0 0170-0177 : :00:1f.2 (4) The PCMCIA card and the PCMCIA driver are set up to work with an IO resource at 0x100-0x108. As soon as they attempt to use this resource, bad things happen (lockups, etc.) because of the reasons spelled out at (2). => It is only an issue if the ACPI resource descriptions are incomplete. It is worse for PCMCIA because it happily assigns resources below 0x1000, where such system/platform devices usually listen to. And usecrs worsens the situation also in another regard: on my own laptop (a pre-2008 model), pci=use_crs makes the PCI-PCI bridge to be marked as "transparent", while pci=nocrs means the PCI-PCI bridge is assumed to be "non-transparent". Best, Dominik ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Boot options acpi=off pci=biosirq dmesg
rved, 2142k data, 540k init, 0k highmem) [0.00] virtual kernel memory layout: [0.00] fixmap : 0xfff1d000 - 0xf000 ( 904 kB) [0.00] pkmap : 0xff80 - 0xffc0 (4096 kB) [0.00] vmalloc : 0xe067 - 0xff7fe000 ( 497 MB) [0.00] lowmem : 0xc000 - 0xdfe7 ( 510 MB) [0.00] .init : 0xc078e000 - 0xc0815000 ( 540 kB) [0.00] .data : 0xc0575b94 - 0xc078d3c8 (2142 kB) [0.00] .text : 0xc010 - 0xc0575b94 (4566 kB) [0.00] Checking if this processor honours the WP bit even in supervisor mode...Ok. [0.00] SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] NR_IRQS:2304 nr_irqs:256 [0.00] Fast TSC calibration using PIT [0.00] Detected 596.238 MHz processor. [0.001968] Console: colour VGA+ 80x25 [0.001985] console [tty0] enabled [0.004000] Calibrating delay loop (skipped), value calculated using timer frequency.. 1192.47 BogoMIPS (lpj=2384952) [0.004000] Security Framework initialized [0.004000] AppArmor: AppArmor initialized [0.004000] Mount-cache hash table entries: 512 [0.004000] Initializing cgroup subsys ns [0.004000] Initializing cgroup subsys cpuacct [0.004000] Initializing cgroup subsys memory [0.004000] Initializing cgroup subsys freezer [0.004000] Initializing cgroup subsys net_cls [0.004000] CPU: L1 I cache: 16K, L1 D cache: 16K [0.004000] CPU: L2 cache: 128K [0.004000] mce: CPU supports 5 MCE banks [0.004000] Performance Counters: [0.004000] no APIC, boot with the "lapic" boot parameter to force-enable it. [0.004000] no hardware sampling interrupt available. [0.004000] p6 PMU driver. [0.004000] ... version: 0 [0.004000] ... bit width: 32 [0.004000] ... generic counters:2 [0.004000] ... value mask: [0.004000] ... max period: 7fff [0.004000] ... fixed-purpose counters: 0 [0.004000] ... counter mask:0003 [0.004000] Checking 'hlt' instruction... OK. [0.017908] SMP alternatives: switching to UP code [0.032069] Freeing SMP alternatives: 19k freed [0.032493] weird, boot CPU (#0) not listed by the BIOS. [0.032577] SMP motherboard not detected. [0.032645] Local APIC not detected. Using dummy APIC emulation. [0.032716] SMP disabled [0.033547] Brought up 1 CPUs [0.033641] Total of 1 processors activated (1192.47 BogoMIPS). [0.033768] CPU0 attaching NULL sched-domain. [0.034941] Booting paravirtualized kernel on bare hardware [0.036529] regulator: core version 0.5 [0.036656] Time: 23:28:02 Date: 03/22/10 [0.036951] NET: Registered protocol family 16 [0.037533] EISA bus registered [0.045810] PCI: PCI BIOS revision 2.10 entry at 0xfd9b0, last bus=1 [0.045903] PCI: Using configuration type 1 for base access [0.050376] bio: create slab at 0 [0.050816] ACPI: Interpreter disabled. [0.051459] SCSI subsystem initialized [0.051811] libata version 3.00 loaded. [0.052285] usbcore: registered new interface driver usbfs [0.052433] usbcore: registered new interface driver hub [0.052665] usbcore: registered new device driver usb [0.053308] PCI: Probing PCI hardware [0.053387] PCI: Probing PCI hardware (bus 00) [0.053628] pci :00:02.0: reg 10 32bit mmio: [0xf800-0xfbff] [0.053648] pci :00:02.0: reg 14 32bit mmio: [0xf400-0xf407] [0.053894] pci :00:1f.0: quirk: region 1000-107f claimed by ICH4 ACPI/GPIO/TCO [0.053995] pci :00:1f.0: quirk: region 1180-11bf claimed by ICH4 GPIO [0.054139] pci :00:1f.1: reg 20 io port: [0x1800-0x180f] [0.054239] pci :00:1f.2: reg 20 io port: [0x1820-0x183f] [0.054344] pci :00:1f.3: reg 20 io port: [0x1810-0x181f] [0.054442] pci :00:1f.4: reg 20 io port: [0x1840-0x185f] [0.054513] pci :00:1f.5: reg 10 io port: [0x1c00-0x1cff] [0.054531] pci :00:1f.5: reg 14 io port: [0x1880-0x18bf] [0.054623] pci :00:1f.6: reg 10 io port: [0x2400-0x24ff] [0.054642] pci :00:1f.6: reg 14 io port: [0x2000-0x207f] [0.054764] pci :01:00.0: reg 10 32bit mmio: [0xf4104000-0xf41047ff] [0.054785] pci :01:00.0: reg 14 32bit mmio: [0xf410-0xf4103fff] [0.054855] pci :01:00.0: supports D2 [0.054866] pci :01:00.0: PME# supported from D2 D3hot [0.054943] pci :01:00.0: PME# disabled [0.055067] pci :01:02.0: reg 10 32bit mmio: [0x00-0x000fff] [0.055103] pci :01:02.0: supports D1 D2 [0.055113] pci :01:02.0: PME# supported from D0 D1 D2 D3hot D3cold [0.055192] pci :01:02.0: PME# disabled [0.055313] pci :01:02.1: reg 10 32bit mmio: [0x00-0x000fff] [0.055349] pci :01:02.1: supports D1 D2 [0.055359] pci :01:02.1: P
Re: pci_bus_for_each_resource, transparent bridges and rsrc_nonstatic.c
On Monday 22 March 2010 02:51:21 pm Dominik Brodowski wrote: > On Mon, Mar 22, 2010 at 01:36:03PM -0700, Bjorn Helgaas wrote: > > > You can still use subtractive-decoded resources, but then you have to add > > > them to /etc/pcmcia/config.opts and run pcmcia-startup-bridges (or echo > > > the > > > resource to a sysfs file). > > > > It's too bad we still have such manual configuration. > > Agreed. > > > Is there still > > information there that we can't figure out automatically? > > That's unknown to me -- are there any ISA-capable systems being sold? If so, > then I suspect the answer may be "yes". > > > > Now, "usecrs" is only used on 2008-or-newer systems where we _hope_ that > > > all > > > resource "consumers" are accounted for. So the problem might be mitigated. > > > However, I wouldn't dare to use ioports 0x0-0xff anyways for they usually > > > are used for onboard legacy devices... > > > > Right. But PCMCIA is at no greater risk than regular PCI, right? > > It looks like both will allocate only above PCIBIOS_MIN_IO (0x1000). > > No, PCMCIA will happily allocate below this limit. I saw "#define PCIBIOS_MIN_CARDBUS_IO PCIBIOS_MIN_IO" in yenta_socket.c and assumed it would take care of this, but I didn't look any deeper. I'm still confused about why PCMCIA is "special" in this regard and why pci=use_crs breaks it. Can you make up an example that illustrates the problem? Bjorn ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Boot options
Hi, On Mon, Mar 22, 2010 at 08:01:17PM +0100, Cyrille GRINNER wrote: > Here is the dmesg after a boot test with acpi=off pci=usepirqmask: last message for today -- what's the "dmesg" ater a boot test with "acpi=off pci=biosirq"? Best, Dominik ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [PATCH v2] pcmcia: db1xxx-ss: suspend/resume fix
Hm, what about using two commits currently in my tree for 2.6.36 instead,
which should fix all socket drivers?
power: support _noirq actions on device types and classes
pcmcia: use dev_pm_ops for class pcmcia_socket_class
Manuel: Could you try whether they also solve these issues? If so, I'd
propose pushing both patches already for 2.6.36. Rafael: do you concur?
Best,
Dominik
On Mon, Mar 22, 2010 at 08:43:23PM +0100, Manuel Lauss wrote:
> This patch adds more pm method callbacks to the db1xxx-ss socket
> driver, which fixes spurious interrupts and dead cards upon resume
> from STR.
>
> Tested on DB1200 with CF card (tons of spurious interrupts resulting
> in card interrupt being disabled) and a 3c509 card (this one was
> just dead after resume).
>
> Signed-off-by: Manuel Lauss
> ---
> v2: remove uneeded .suspend callback (which was identical to
> suspend_noirq).
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index d477f4d..941fcb8 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -439,8 +439,23 @@ static int device_resume_noirq(struct device *dev,
pm_message_t state)
if (dev->bus && dev->bus->pm) {
pm_dev_dbg(dev, state, "EARLY ");
error = pm_noirq_op(dev, dev->bus->pm, state);
+ if (error)
+ goto End;
}
+ if (dev->type && dev->type->pm) {
+ pm_dev_dbg(dev, state, "EARLY type ");
+ error = pm_noirq_op(dev, dev->type->pm, state);
+ if (error)
+ goto End;
+ }
+
+ if (dev->class && dev->class->pm) {
+ pm_dev_dbg(dev, state, "EARLY class ");
+ error = pm_noirq_op(dev, dev->class->pm, state);
+ }
+
+End:
TRACE_RESUME(error);
return error;
}
@@ -735,10 +750,26 @@ static int device_suspend_noirq(struct device *dev,
pm_message_t state)
{
int error = 0;
+ if (dev->class && dev->class->pm) {
+ pm_dev_dbg(dev, state, "LATE class ");
+ error = pm_noirq_op(dev, dev->class->pm, state);
+ if (error)
+ goto End;
+ }
+
+ if (dev->type && dev->type->pm) {
+ pm_dev_dbg(dev, state, "LATE type ");
+ error = pm_noirq_op(dev, dev->type->pm, state);
+ if (error)
+ goto End;
+ }
+
if (dev->bus && dev->bus->pm) {
pm_dev_dbg(dev, state, "LATE ");
error = pm_noirq_op(dev, dev->bus->pm, state);
}
+
+End:
return error;
}
diff --git a/drivers/pcmcia/at91_cf.c b/drivers/pcmcia/at91_cf.c
index 5d22807..fb904f4 100644
--- a/drivers/pcmcia/at91_cf.c
+++ b/drivers/pcmcia/at91_cf.c
@@ -361,7 +361,6 @@ static int at91_cf_suspend(struct platform_device *pdev,
pm_message_t mesg)
struct at91_cf_socket *cf = platform_get_drvdata(pdev);
struct at91_cf_data *board = cf->board;
- pcmcia_socket_dev_suspend(&pdev->dev);
if (device_may_wakeup(&pdev->dev)) {
enable_irq_wake(board->det_pin);
if (board->irq_pin)
@@ -381,7 +380,6 @@ static int at91_cf_resume(struct platform_device *pdev)
disable_irq_wake(board->irq_pin);
}
- pcmcia_socket_dev_resume(&pdev->dev);
return 0;
}
diff --git a/drivers/pcmcia/au1000_generic.c b/drivers/pcmcia/au1000_generic.c
index 171c8a6..ac4d089 100644
--- a/drivers/pcmcia/au1000_generic.c
+++ b/drivers/pcmcia/au1000_generic.c
@@ -510,17 +510,6 @@ static int au1x00_drv_pcmcia_probe(struct platform_device
*dev)
return ret;
}
-static int au1x00_drv_pcmcia_suspend(struct platform_device *dev,
-pm_message_t state)
-{
- return pcmcia_socket_dev_suspend(&dev->dev);
-}
-
-static int au1x00_drv_pcmcia_resume(struct platform_device *dev)
-{
- return pcmcia_socket_dev_resume(&dev->dev);
-}
-
static struct platform_driver au1x00_pcmcia_driver = {
.driver = {
.name = "au1x00-pcmcia",
@@ -528,8 +517,6 @@ static struct platform_driver au1x00_pcmcia_driver = {
},
.probe = au1x00_drv_pcmcia_probe,
.remove = au1x00_drv_pcmcia_remove,
- .suspend= au1x00_drv_pcmcia_suspend,
- .resume = au1x00_drv_pcmcia_resume,
};
diff --git a/drivers/pcmcia/bfin_cf_pcmcia.c b/drivers/pcmcia/bfin_cf_pcmcia.c
index 1744f38..b16f209 100644
--- a/drivers/pcmcia/bfin_cf_pcmcia.c
+++ b/drivers/pcmcia/bfin_cf_pcmcia.c
@@ -300,16 +300,6 @@ static int __devexit bfin_cf_remove(struct platform_device
*pdev)
return 0;
}
-static int bfin_cf_suspend(struct platform_device *pdev, pm_message_t mesg)
-{
- return pcmcia_socket_dev_suspend(&pdev->dev);
-}
-
-static int bfin_cf_resume(struct platform_device *pdev)
-{
- return pcmcia_socket_dev_resume(&pdev->dev);
-}
-
Re: pci_bus_for_each_resource, transparent bridges and rsrc_nonstatic.c
On Mon, Mar 22, 2010 at 01:36:03PM -0700, Bjorn Helgaas wrote: > > You can still use subtractive-decoded resources, but then you have to add > > them to /etc/pcmcia/config.opts and run pcmcia-startup-bridges (or echo the > > resource to a sysfs file). > > It's too bad we still have such manual configuration. Agreed. > Is there still > information there that we can't figure out automatically? That's unknown to me -- are there any ISA-capable systems being sold? If so, then I suspect the answer may be "yes". > > Now, "usecrs" is only used on 2008-or-newer systems where we _hope_ that all > > resource "consumers" are accounted for. So the problem might be mitigated. > > However, I wouldn't dare to use ioports 0x0-0xff anyways for they usually > > are used for onboard legacy devices... > > Right. But PCMCIA is at no greater risk than regular PCI, right? > It looks like both will allocate only above PCIBIOS_MIN_IO (0x1000). No, PCMCIA will happily allocate below this limit. Best, Dominik ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: runtime PM ops and PCMCIA bus
On Mon, 22 Mar 2010, Dominik Brodowski wrote: > Alan, > > many thanks for your extensive feedback! My pleasure. > On Mon, Mar 22, 2010 at 11:38:44AM -0400, Alan Stern wrote: > > On Sun, 21 Mar 2010, Dominik Brodowski wrote: > > > (2) Whenever two functions local to drivers/pcmcia/ds.c -- > > > runtime_suspend() or runtime_resume() -- are called, > > > we need to force a synchronous call to pcmcia_dev_suspend(), > > > or to pcmcia_dev_resume(). Currently, we do this by taking > > > device_lock() and calling the function manually. > > > > That seems like the right thing to do. (Except that I don't know what > > your device_lock() routine is for.) > > Actually, that's the generic device_lock(), which replaced down(&dev->sem) Heh. Guess I'm not used to seeing it yet... > ... which is used here to not let a reset or a runtime suspend/resume race > with a system sleep event. The PM core is supposed to prevent races between runtime suspend/resume and system sleep, so you don't need to worry about that. But you do need to worry about races with reset (this may or may not be the best way to handle them). > > I don't understand. Aren't runtime_suspend() and runtime_resume(), as > > mentioned above, already part of your runtime PM interface? Or at > > least, intended to be part of your runtime PM interface? > > Well, they are part of the PCMCIA-local runtime PM interface -- it is based > around the concept that an user may, whenever she wants, can set a PCMCIA > device (or the whole card) to the "suspend" state. > Well, that's not what this "runtime_suspend()" does -- it is the wrapper for > userspace-issued suspend commands. > > One of the background assumptions behind the runtime PM > > framework is that users don't tell the system when to suspend devices. > > Ah, that's the fundamental issue. I agree that the PCMCIA subsystem does > something unusual here (relating to PCMCIA cards or PCMCIA devices) -- > but I would prefer not to break how the system currently works. All right. It appears that what you have implemented is really a "power-down" or "on/off" type of interface rather than a "runtime-suspend" interface. You can of course have both types of interfaces at the same time, but keep in mind that they don't work the same way. > > > (5) Another problem I'm seeing with the put/get approach: there are three > > > different callpaths where runtime_suspend() / runtime_resume() might > > > be called.[*] However, each one decreases the counter, which might > > > get < 0. > > > > The counter should never become negative; if it does, there's a bug in > > your driver. Every decrement should match a corresponding increment, > > just like with refcounts. And the device should never be > > runtime-suspended unless the counter is 0. > > what's the initial value, actually? Is it 0 or 1? It is 0. > > Instead, the system automatically suspends devices when it realizes > > they aren't being used. > > That's what we could use for PCMCIA sockets. Yes, that sounds like an easy application. If the socket contains no card, or if all devices on the card are powered-down, then the socket can be runtime-suspended. > > > --- a/drivers/pcmcia/Kconfig > > > +++ b/drivers/pcmcia/Kconfig > > > @@ -20,6 +20,7 @@ if PCCARD > > > config PCMCIA > > > tristate "16-bit PCMCIA support" > > > select CRC32 > > > + select PM_RUNTIME > > > > This seems very wrong. Why do you need it? Can't the pcmcia subsystem > > work correctly without runtime PM support? Hasn't it been working > > correctly that way all along? > > Oh yes, it did. However, continuing support for the PCMCIA-style "runtime > PM" might need to depend on PM_RUNTIME. It shouldn't be that way. Keep the existing PCMCIA-style interface if you want, but realize that it is separate and independent from the runtime PM framework and therefore it shouldn't select PM_RUNTIME. The alternative is to remove the user's ability to power-down PCMCIA devices, and rely on the operating system to suspend them at the right times. Alan Stern ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: pci_bus_for_each_resource, transparent bridges and rsrc_nonstatic.c
On Monday 22 March 2010 02:21:35 pm Dominik Brodowski wrote: > Hey, > > On Mon, Mar 22, 2010 at 01:08:35PM -0700, Bjorn Helgaas wrote: > > > So, what should we do? > > > > Let's back up a bit. I don't know enough about PCMCIA, and I don't > > see the problem yet. We have the 00:1e.0 bridge leading to bus 04, > > and 04:06.0 is a CardBus bridge. These three windows are the ranges > > positively decoded and forwarded by the 00:1e.0 bridge: > > > > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge I/O window: 0x1000 > > - 0x1fff > > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge Memory window: > > 0xd200 - 0xd40f > > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge Memory window: > > 0xd000 - 0xd1ff > > > > But the bridge is in subtractive-decode mode, so it *also* forwards > > anything it sees that is unclaimed by other devices on bus 00, which > > means the 04:06.0 CardBus bridge will also see these ranges: > > > > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge I/O window: 0x0 - > > 0xcf7 > > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge I/O window: 0xd00 - > > 0x > > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge Memory window: > > 0xa - 0xb > > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge Memory window: > > 0xc000 - 0xfebf > > > > Why do you care whether these additional ranges are excluded? They > > should be just as usable as the first three. > > Quoting rsrc_nonstatic.c: > > /* If this is the root bus, the risk of hitting > * some strange system devices which aren't protected > * by either ACPI resource tables or properly requested > * resources is too big. [...] > */ > > Or, as Alan put it -- when it came to I/O resources in the 0x100-0x3ff area: > > "Which crashes older thinkpads, some ATI chipset systems and >usually anything containing an NE2000 clone in ISA space." > > You can still use subtractive-decoded resources, but then you have to add > them to /etc/pcmcia/config.opts and run pcmcia-startup-bridges (or echo the > resource to a sysfs file). It's too bad we still have such manual configuration. Is there still information there that we can't figure out automatically? > Now, "usecrs" is only used on 2008-or-newer systems where we _hope_ that all > resource "consumers" are accounted for. So the problem might be mitigated. > However, I wouldn't dare to use ioports 0x0-0xff anyways for they usually > are used for onboard legacy devices... Right. But PCMCIA is at no greater risk than regular PCI, right? It looks like both will allocate only above PCIBIOS_MIN_IO (0x1000). Bjorn ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: pci_bus_for_each_resource, transparent bridges and rsrc_nonstatic.c
Hey, On Mon, Mar 22, 2010 at 01:08:35PM -0700, Bjorn Helgaas wrote: > > So, what should we do? > > Let's back up a bit. I don't know enough about PCMCIA, and I don't > see the problem yet. We have the 00:1e.0 bridge leading to bus 04, > and 04:06.0 is a CardBus bridge. These three windows are the ranges > positively decoded and forwarded by the 00:1e.0 bridge: > > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge I/O window: 0x1000 - > 0x1fff > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge Memory window: > 0xd200 - 0xd40f > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge Memory window: > 0xd000 - 0xd1ff > > But the bridge is in subtractive-decode mode, so it *also* forwards > anything it sees that is unclaimed by other devices on bus 00, which > means the 04:06.0 CardBus bridge will also see these ranges: > > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge I/O window: 0x0 - > 0xcf7 > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge I/O window: 0xd00 - > 0x > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge Memory window: > 0xa - 0xb > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge Memory window: > 0xc000 - 0xfebf > > Why do you care whether these additional ranges are excluded? They > should be just as usable as the first three. Quoting rsrc_nonstatic.c: /* If this is the root bus, the risk of hitting * some strange system devices which aren't protected * by either ACPI resource tables or properly requested * resources is too big. [...] */ Or, as Alan put it -- when it came to I/O resources in the 0x100-0x3ff area: "Which crashes older thinkpads, some ATI chipset systems and usually anything containing an NE2000 clone in ISA space." You can still use subtractive-decoded resources, but then you have to add them to /etc/pcmcia/config.opts and run pcmcia-startup-bridges (or echo the resource to a sysfs file). Now, "usecrs" is only used on 2008-or-newer systems where we _hope_ that all resource "consumers" are accounted for. So the problem might be mitigated. However, I wouldn't dare to use ioports 0x0-0xff anyways for they usually are used for onboard legacy devices... Best, Dominik ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: pci_bus_for_each_resource, transparent bridges and rsrc_nonstatic.c
On Monday 22 March 2010 11:27:10 am Dominik Brodowski wrote: > Bjorn, > > On Mon, Mar 22, 2010 at 09:34:28AM -0700, Bjorn Helgaas wrote: > > On Monday 22 March 2010 06:00:41 am Dominik Brodowski wrote: > > > Komuro reports the following issue: > > > > > > 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93) > > > (prog-if 01 [Subtractive decode]) > > > ... > > > Bus: primary=00, secondary=04, subordinate=05, sec-latency=32 > > > I/O behind bridge: 1000-1fff > > > Memory behind bridge: d200-d40f > > > Prefetchable memory behind bridge: d000-d1ff > > > > > > 04:06.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6) > > > > > > Iterating over the bus (4) resources used to report just IO > > > 0x1000-0x1, > > > MEM d2...-d4..., prefetch d0...-d1..., and that's exactly what we need in > > > drivers/pcmcia/rsrc_nonstatic.c . However, the newly added > > > pci_bus_for_each_resource() seems to return _also_ additional resources, > > > which we need to exclude in drivers/pcmcia/rssrc_nonstatic.c . Any ideas > > > on > > > how to fix this issue? > > ... > We did indeed iterate over all 16 bus resources, so also for the root PCI > bridge resources. However, this used to just skip in the next check: > > if (res == &ioport_resource) > continue; > > (or &iomem_resource) as there used to be no specific root I/O / Memory > window resource set. But now, all of the I/O address space is split up into > two, and a (previously non-existing) "PCI Bus :00" appears in > /proc/iomem . Do you know, by chance, which change or patchset specifically > introduced this? Yep, I think this is 7bc5e3f2be32a, which makes us pay attention to the PCI host bridge windows reported by the BIOS instead of assuming that "all of ioport_resource and iomem_resource are routed to the single PCI root bus." You should see the same behavior even before 7bc5e3f2be32a if you boot with "pci=use_crs". > > > > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge I/O window: 0x0 - > > > > 0xcf7 > > > > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge I/O window: 0xd00 > > > > - 0x > > with just a very small hole in between... This is pretty typical. The BIOS is telling us that 0xcf8-0xcff is consumed directly by the host bridge (it uses that for doing config space accesses on the PCI bus), and the rest of the area if forwarded to the downstream PCI bus and is available for PCI devices to use. > So, what should we do? Let's back up a bit. I don't know enough about PCMCIA, and I don't see the problem yet. We have the 00:1e.0 bridge leading to bus 04, and 04:06.0 is a CardBus bridge. These three windows are the ranges positively decoded and forwarded by the 00:1e.0 bridge: yenta_cardbus :04:06.0: pcmcia: parent PCI bridge I/O window: 0x1000 - 0x1fff yenta_cardbus :04:06.0: pcmcia: parent PCI bridge Memory window: 0xd200 - 0xd40f yenta_cardbus :04:06.0: pcmcia: parent PCI bridge Memory window: 0xd000 - 0xd1ff But the bridge is in subtractive-decode mode, so it *also* forwards anything it sees that is unclaimed by other devices on bus 00, which means the 04:06.0 CardBus bridge will also see these ranges: yenta_cardbus :04:06.0: pcmcia: parent PCI bridge I/O window: 0x0 - 0xcf7 yenta_cardbus :04:06.0: pcmcia: parent PCI bridge I/O window: 0xd00 - 0x yenta_cardbus :04:06.0: pcmcia: parent PCI bridge Memory window: 0xa - 0xb yenta_cardbus :04:06.0: pcmcia: parent PCI bridge Memory window: 0xc000 - 0xfebf Why do you care whether these additional ranges are excluded? They should be just as usable as the first three. Of course, the first three ranges (the ones positively decoded by 00:1e.0) can only be used by devices on bus 04, while the last four (subtractively decoded by 00:1e.0) can be used by devices on bus 00 or bus 04, so there's more competition for the last four. But I don't understand why we care whether the upstream bridge decoded a region positively or subtractively when deciding whether to add it to the PCMCIA resource map. Bjorn ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: runtime PM ops and PCMCIA bus
Alan,
many thanks for your extensive feedback!
On Mon, Mar 22, 2010 at 11:38:44AM -0400, Alan Stern wrote:
> On Sun, 21 Mar 2010, Dominik Brodowski wrote:
> > (2) Whenever two functions local to drivers/pcmcia/ds.c --
> > runtime_suspend() or runtime_resume() -- are called,
> > we need to force a synchronous call to pcmcia_dev_suspend(),
> > or to pcmcia_dev_resume(). Currently, we do this by taking
> > device_lock() and calling the function manually.
>
> That seems like the right thing to do. (Except that I don't know what
> your device_lock() routine is for.)
Actually, that's the generic device_lock(), which replaced down(&dev->sem)
... which is used here to not let a reset or a runtime suspend/resume race
with a system sleep event.
> > (3) However, it'd be much nicer to be able to use the new runtime
> > PM interface.
>
> I don't understand. Aren't runtime_suspend() and runtime_resume(), as
> mentioned above, already part of your runtime PM interface? Or at
> least, intended to be part of your runtime PM interface?
Well, they are part of the PCMCIA-local runtime PM interface -- it is based
around the concept that an user may, whenever she wants, can set a PCMCIA
device (or the whole card) to the "suspend" state.
> > As the PCMCIA bus can always suspend,
>
> Is that really literally true? Don't you run into trouble if you try
> to suspend while a data transfer is taking place? And if you've got a
> whole series of transfers going on, does it really make sense to
> suspend after each individual transfer, only to resume immediately when
> the next transfer comes along?
>
> How long should a pcmcia device have to remain idle before suspending
> it will actually end up saving energy?
>
> How does your driver determine when the device becomes idle (and just
> as important, stops being idle)?
Well, all of this is done by the user. I agree that it might make sense to
take all these issues into consideration -- e.g. by get/put commands used by
the ATA layer etc.
> > To enable it, we should add
> >
> >pm_runtime_set_active(&p_dev->dev);
> >pm_runtime_enable(&p_dev->dev);
> >
> > in pcmcia_device_add().
>
> Yes.
>
> > (4) What is then to be done to modify runtime_suspend() / runtime_resume() ?
> > Is it:
> >
> > + static int runtime_suspend(struct device *dev)
> > + {
> > + pm_runtime_put_noidle(dev);
> > + return pm_runtime_suspend(dev);
> > + }
>
> This makes no sense at all. pm_runtime_suspend() calls your
> runtime_suspend() function, not the other way around.
Well, that's not what this "runtime_suspend()" does -- it is the wrapper for
userspace-issued suspend commands.
> > (5) Another problem I'm seeing with the put/get approach: there are three
> > different callpaths where runtime_suspend() / runtime_resume() might
> > be called.[*] However, each one decreases the counter, which might get
> > < 0.
>
> The counter should never become negative; if it does, there's a bug in
> your driver. Every decrement should match a corresponding increment,
> just like with refcounts. And the device should never be
> runtime-suspended unless the counter is 0.
what's the initial value, actually? Is it 0 or 1?
> One of the background assumptions behind the runtime PM
> framework is that users don't tell the system when to suspend devices.
Ah, that's the fundamental issue. I agree that the PCMCIA subsystem does
something unusual here (relating to PCMCIA cards or PCMCIA devices) --
but I would prefer not to break how the system currently works.
> Instead, the system automatically suspends devices when it realizes
> they aren't being used.
That's what we could use for PCMCIA sockets.
> > --- a/drivers/pcmcia/Kconfig
> > +++ b/drivers/pcmcia/Kconfig
> > @@ -20,6 +20,7 @@ if PCCARD
> > config PCMCIA
> > tristate "16-bit PCMCIA support"
> > select CRC32
> > + select PM_RUNTIME
>
> This seems very wrong. Why do you need it? Can't the pcmcia subsystem
> work correctly without runtime PM support? Hasn't it been working
> correctly that way all along?
Oh yes, it did. However, continuing support for the PCMCIA-style "runtime
PM" might need to depend on PM_RUNTIME.
Will do write (and possibly test) some patches first, then get back to you
-- many thanks for your feedback. Really appreciate it!
Best,
Dominik
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
[PATCH v2] pcmcia: db1xxx-ss: suspend/resume fix
This patch adds more pm method callbacks to the db1xxx-ss socket
driver, which fixes spurious interrupts and dead cards upon resume
from STR.
Tested on DB1200 with CF card (tons of spurious interrupts resulting
in card interrupt being disabled) and a 3c509 card (this one was
just dead after resume).
Signed-off-by: Manuel Lauss
---
v2: remove uneeded .suspend callback (which was identical to
suspend_noirq).
drivers/pcmcia/db1xxx_ss.c | 17 +
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/pcmcia/db1xxx_ss.c b/drivers/pcmcia/db1xxx_ss.c
index 9254ab0..2191654 100644
--- a/drivers/pcmcia/db1xxx_ss.c
+++ b/drivers/pcmcia/db1xxx_ss.c
@@ -559,21 +559,30 @@ static int __devexit db1x_pcmcia_socket_remove(struct
platform_device *pdev)
}
#ifdef CONFIG_PM
-static int db1x_pcmcia_suspend(struct device *dev)
+static int db1x_pcmcia_suspend_noirq(struct device *dev)
{
return pcmcia_socket_dev_suspend(dev);
}
+static int db1x_pcmcia_resume_noirq(struct device *dev)
+{
+ pcmcia_socket_dev_early_resume(dev);
+ return 0;
+}
+
static int db1x_pcmcia_resume(struct device *dev)
{
- return pcmcia_socket_dev_resume(dev);
+ pcmcia_socket_dev_late_resume(dev);
+ return 0;
}
static struct dev_pm_ops db1x_pcmcia_pmops = {
.resume = db1x_pcmcia_resume,
- .suspend= db1x_pcmcia_suspend,
+ .resume_noirq = db1x_pcmcia_resume_noirq,
+ .suspend_noirq = db1x_pcmcia_suspend_noirq,
.thaw = db1x_pcmcia_resume,
- .freeze = db1x_pcmcia_suspend,
+ .thaw_noirq = db1x_pcmcia_resume_noirq,
+ .freeze = db1x_pcmcia_suspend_noirq,
};
#define DB1XXX_SS_PMOPS &db1x_pcmcia_pmops
--
1.7.0.2
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
[Bug 7304] no PCI irq, Cardbus support disabled
https://bugzilla.kernel.org/show_bug.cgi?id=7304 --- Comment #79 from Dominik Brodowski 2010-03-22 19:15:49 --- Regarding the dmidecode output: do you have CONFIG_DMI and CONFIG_DMIID enabled in the kernel? Using a dmi-code is the preferred way to specify an override. Also, could you re-run cbdump, please, with kernel 2.6.34-rc2 and the following fix-up: socket->cb_irq = 11; dev->irq = 11; first inserted into the working socket #1, then into the non-working socket #0? Thanks! -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Boot options
Hi! Here is the dmesg after a boot test with acpi=off pci=usepirqmask: [0.00] 00 - 40 page 4k [0.00] 40 - 001fc0 page 2M [0.00] 001fc0 - 001fe7 page 4k [0.00] kernel direct mapping tables up to 1fe7 @ 1-15000 [0.00] RAMDISK: 1f715000 - 1fe5fd78 [0.00] 0MB HIGHMEM available. [0.00] 510MB LOWMEM available. [0.00] mapped low ram: 0 - 1fe7 [0.00] low ram: 0 - 1fe7 [0.00] node 0 low ram: - 1fe7 [0.00] node 0 bootmap 00011000 - 00014fd0 [0.00] (9 early reservations) ==> bootmem [00 - 001fe7] [0.00] #0 [00 - 001000] BIOS data page ==> [00 - 001000] [0.00] #1 [001000 - 002000]EX TRAMPOLINE ==> [001000 - 002000] [0.00] #2 [006000 - 007000] TRAMPOLINE ==> [006000 - 007000] [0.00] #3 [10 - 8a80a0]TEXT DATA BSS ==> [10 - 8a80a0] [0.00] #4 [001f715000 - 001fe5fd78] RAMDISK ==> [001f715000 - 001fe5fd78] [0.00] #5 [09f800 - 10]BIOS reserved ==> [09f800 - 10] [0.00] #6 [8a9000 - 8ac121] BRK ==> [8a9000 - 8ac121] [0.00] #7 [01 - 011000] PGTABLE ==> [01 - 011000] [0.00] #8 [011000 - 015000] BOOTMAP ==> [011000 - 015000] [0.00] Zone PFN ranges: [0.00] DMA 0x0010 -> 0x1000 [0.00] Normal 0x1000 -> 0x0001fe70 [0.00] HighMem 0x0001fe70 -> 0x0001fe70 [0.00] Movable zone start PFN for each node [0.00] early_node_map[2] active PFN ranges [0.00] 0: 0x0010 -> 0x009f [0.00] 0: 0x0100 -> 0x0001fe70 [0.00] On node 0 totalpages: 130559 [0.00] free_area_init_node: node 0, pgdat c0784940, node_mem_map c1000200 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 3951 pages, LIFO batch:0 [0.00] Normal zone: 989 pages used for memmap [0.00] Normal zone: 125587 pages, LIFO batch:31 [0.00] Using APIC driver default [0.00] SMP: Allowing 1 CPUs, 0 hotplug CPUs [0.00] Local APIC disabled by BIOS -- you can enable it with "lapic" [0.00] APIC: disable apic facility [0.00] nr_irqs_gsi: 16 [0.00] PM: Registered nosave memory: 0009f000 - 000a [0.00] PM: Registered nosave memory: 000a - 000e6000 [0.00] PM: Registered nosave memory: 000e6000 - 0010 [0.00] Allocating PCI resources starting at 2000 (gap: 2000:dff0) [0.00] NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:1 nr_node_ids:1 [0.00] PERCPU: Embedded 14 pages at c1402000, static data 35612 bytes [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129538 [0.00] Kernel command line: root=UUID=549a6bf0-214f-4e92-80c5-22181afee69a acpi=off pci=usepirqmask [0.00] PID hash table entries: 2048 (order: 11, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Enabling fast FPU save and restore... done. [0.00] Enabling unmasked SIMD FPU exception support... done. [0.00] Initializing CPU#0 [0.00] allocated 2613120 bytes of page_cgroup [0.00] please try 'cgroup_disable=memory' option if you don't want memory cgroups [0.00] Initializing HighMem for node 0 (:) [0.00] Memory: 499568k/522688k available (4566k kernel code, 22460k reserved, 2142k data, 540k init, 0k highmem) [0.00] virtual kernel memory layout: [0.00] fixmap : 0xfff1d000 - 0xf000 ( 904 kB) [0.00] pkmap : 0xff80 - 0xffc0 (4096 kB) [0.00] vmalloc : 0xe067 - 0xff7fe000 ( 497 MB) [0.00] lowmem : 0xc000 - 0xdfe7 ( 510 MB) [0.00] .init : 0xc078e000 - 0xc0815000 ( 540 kB) [0.00] .data : 0xc0575b94 - 0xc078d3c8 (2142 kB) [0.00] .text : 0xc010 - 0xc0575b94 (4566 kB) [0.00] Checking if this processor honours the WP bit even in supervisor mode...Ok. [0.00] SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] NR_IRQS:2304 nr_irqs:256 [0.00] Fast TSC calibration using PIT [0.00] Detected 596.207 MHz processor. [0.001970] Console: colour VGA+ 80x25 [0.001987] console [tty0] enabled [0.004026] Calibrating delay loop (skipped), value calculated using timer frequency.. 1192.41 BogoMIPS (lpj=2384828) [0.004247] Security Framework initialized [0.004410] Ap
Re: pci_bus_for_each_resource, transparent bridges and rsrc_nonstatic.c
Bjorn,
On Mon, Mar 22, 2010 at 09:34:28AM -0700, Bjorn Helgaas wrote:
> On Monday 22 March 2010 06:00:41 am Dominik Brodowski wrote:
> > Komuro reports the following issue:
> >
> > 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
> > (prog-if 01 [Subtractive decode])
> > ...
> > Bus: primary=00, secondary=04, subordinate=05, sec-latency=32
> > I/O behind bridge: 1000-1fff
> > Memory behind bridge: d200-d40f
> > Prefetchable memory behind bridge: d000-d1ff
> >
> > 04:06.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)
> >
> > Iterating over the bus (4) resources used to report just IO 0x1000-0x1,
> > MEM d2...-d4..., prefetch d0...-d1..., and that's exactly what we need in
> > drivers/pcmcia/rsrc_nonstatic.c . However, the newly added
> > pci_bus_for_each_resource() seems to return _also_ additional resources,
> > which we need to exclude in drivers/pcmcia/rssrc_nonstatic.c . Any ideas on
> > how to fix this issue?
>
> This was probably broken by 2fe2abf896c1 or maybe 89a74ecccd1f7, but
> I don't see how yet.
>
> Before those changes, we had this:
>
> #define PCI_BUS_NUM_RESOURCES 16
> static int nonstatic_autoadd_resources(struct pcmcia_socket *s)
> ...
> for (i = 0; i < PCI_BUS_NUM_RESOURCES; i++) {
> struct resource *root = socket->dev->bus->resource[i];
>
> so we used to iterate over all 16 possible bus resources, not just four.
>
> Can you please collect a dmesg log from b16694f70c (just before my
> changes) and another from 7bc5e3f2be32 (just after) so we can compare
> them?
>
> You can open a kernel bugzilla, assign it to me, and attach the logs
> there, if you want.
Actually, I now think the bug was introduced somewhere else.
We did indeed iterate over all 16 bus resources, so also for the root PCI
bridge resources. However, this used to just skip in the next check:
if (res == &ioport_resource)
continue;
(or &iomem_resource) as there used to be no specific root I/O / Memory
window resource set. But now, all of the I/O address space is split up into
two, and a (previously non-existing) "PCI Bus :00" appears in
/proc/iomem . Do you know, by chance, which change or patchset specifically
introduced this?
> > > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge I/O window: 0x0 -
> > > 0xcf7
> > > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge I/O window: 0xd00 -
> > > 0x
with just a very small hole in between...
So, what should we do?
(1) The best way seems to be to skip all resources of type
PCI_SUBTRACTIVE_DECODE, but this flag is only stored in
struct pci_bus_resource, which is hard to access, and nonexistent for the
first four resources. Actually, the "flag" field is unused otherwise. Could
we set res->flags |= PCI_SUBTRACTIVE_DECODE instead? (it probably needs to
be != 0x1 then, but anyways). Then it's trivial in rsrc_nonstatic.c
(2) An alternative would be to
diff --git a/drivers/pcmcia/rsrc_nonstatic.c b/drivers/pcmcia/rsrc_nonstatic.c
index ba3a53e..b0e60a1 100644
--- a/drivers/pcmcia/rsrc_nonstatic.c
+++ b/drivers/pcmcia/rsrc_nonstatic.c
@@ -933,7 +933,8 @@ static int nonstatic_autoadd_resources(struct pcmcia_socket
*s)
return -EINVAL;
#endif
- pci_bus_for_each_resource(s->cb_dev->bus, res, i) {
+ for (i = 0; i < PCI_BRIDGE_RESOURCE_NUM; i++) {
+ res = s->cb_dev->bus->resource[i];
if (!res)
continue;
What do you think?
Best,
Dominik
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: pci_bus_for_each_resource, transparent bridges and rsrc_nonstatic.c
On Monday 22 March 2010 06:00:41 am Dominik Brodowski wrote:
> Komuro reports the following issue:
>
> 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
> (prog-if 01 [Subtractive decode])
> ...
> Bus: primary=00, secondary=04, subordinate=05, sec-latency=32
> I/O behind bridge: 1000-1fff
> Memory behind bridge: d200-d40f
> Prefetchable memory behind bridge: d000-d1ff
>
> 04:06.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)
>
> Iterating over the bus (4) resources used to report just IO 0x1000-0x1,
> MEM d2...-d4..., prefetch d0...-d1..., and that's exactly what we need in
> drivers/pcmcia/rsrc_nonstatic.c . However, the newly added
> pci_bus_for_each_resource() seems to return _also_ additional resources,
> which we need to exclude in drivers/pcmcia/rssrc_nonstatic.c . Any ideas on
> how to fix this issue?
This was probably broken by 2fe2abf896c1 or maybe 89a74ecccd1f7, but
I don't see how yet.
Before those changes, we had this:
#define PCI_BUS_NUM_RESOURCES 16
static int nonstatic_autoadd_resources(struct pcmcia_socket *s)
...
for (i = 0; i < PCI_BUS_NUM_RESOURCES; i++) {
struct resource *root = socket->dev->bus->resource[i];
so we used to iterate over all 16 possible bus resources, not just four.
Can you please collect a dmesg log from b16694f70c (just before my
changes) and another from 7bc5e3f2be32 (just after) so we can compare
them?
You can open a kernel bugzilla, assign it to me, and attach the logs
there, if you want.
Bjorn
> > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge I/O window: 0x1000 -
> > 0x1fff
> > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge Memory window:
> > 0xd200 - 0xd40f
> > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge Memory window:
> > 0xd000 - 0xd1ff
> > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge I/O window: 0x0 -
> > 0xcf7
> > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge I/O window: 0xd00 -
> > 0x
> > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge Memory window:
> > 0xa - 0xb
> > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge Memory window:
> > 0xc000 - 0xfebf
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: runtime PM ops and PCMCIA bus
On Sun, 21 Mar 2010, Dominik Brodowski wrote:
> Hey!
>
> On the PCMCIA bus, implementing runtime PM "should" be simple.
Ha! There always are lots of little issues that make it more
complicated than it seems...
> However, there's a major caveat: the bus must be able to
> force devices to suspend, or force them to resume during
> runtime. Let's discuss this in detail:
>
> (1) Converting the PCMCIA bus to dev_pm_ops seems easy:
>
> pcmcia_dev_suspend() needs to get rid of its second argument,
> then it's just a
>
> SET_SYSTEM_SLEEP_PM_OPS(pcmcia_dev_suspend, pcmcia_dev_resume)
Yes.
> (2) Whenever two functions local to drivers/pcmcia/ds.c --
> runtime_suspend() or runtime_resume() -- are called,
> we need to force a synchronous call to pcmcia_dev_suspend(),
> or to pcmcia_dev_resume(). Currently, we do this by taking
> device_lock() and calling the function manually.
That seems like the right thing to do. (Except that I don't know what
your device_lock() routine is for.)
> (3) However, it'd be much nicer to be able to use the new runtime
> PM interface.
I don't understand. Aren't runtime_suspend() and runtime_resume(), as
mentioned above, already part of your runtime PM interface? Or at
least, intended to be part of your runtime PM interface?
> As the PCMCIA bus can always suspend,
Is that really literally true? Don't you run into trouble if you try
to suspend while a data transfer is taking place? And if you've got a
whole series of transfers going on, does it really make sense to
suspend after each individual transfer, only to resume immediately when
the next transfer comes along?
How long should a pcmcia device have to remain idle before suspending
it will actually end up saving energy?
How does your driver determine when the device becomes idle (and just
as important, stops being idle)?
> pcmcia_dev_idle() might only contain a call to
>
> pm_schedule_suspend(dev, 0) - or pm_runtime_suspend() ?
pm_schedule_suspend(dev, 0) is exactly the same as
pm_request_suspend(dev). Either way involves going through a
workqueue, whereas pm_runtime_suspend() invokes the runtime_suspend
method directly. So there's no reason not to call
pm_runtime_suspend().
> To enable it, we should add
>
>pm_runtime_set_active(&p_dev->dev);
>pm_runtime_enable(&p_dev->dev);
>
> in pcmcia_device_add().
Yes.
> (4) What is then to be done to modify runtime_suspend() / runtime_resume() ?
> Is it:
>
> + static int runtime_suspend(struct device *dev)
> + {
> + pm_runtime_put_noidle(dev);
> + return pm_runtime_suspend(dev);
> + }
This makes no sense at all. pm_runtime_suspend() calls your
runtime_suspend() function, not the other way around.
> + static int runtime_resume(struct device *dev)
> + {
> + return pm_runtime_get_sync(dev);
> + }
Likewise.
> or more something like
>
>
> + static int runtime_suspend(struct device *dev)
> + {
> + return pm_runtime_put_sync(dev);
> + }
> +
> + static int runtime_resume(struct device *dev)
> + {
> + return pm_runtime_get_sync(dev);
> + }
Ditto. As far as I can see, those routines don't need to be changed at
all -- except perhaps to avoid suspending the device while it is being
used. Maybe your device_lock() handles that.
> and modifying pcmcia_dev_idle() to call pm_runtime_suspend() instead of
> pm_schedule_suspend()?
That's correct assuming you want to suspend right away when
pcmcia_dev_idle() runs.
> (5) Another problem I'm seeing with the put/get approach: there are three
> different callpaths where runtime_suspend() / runtime_resume() might
> be called.[*] However, each one decreases the counter, which might get <
> 0.
The counter should never become negative; if it does, there's a bug in
your driver. Every decrement should match a corresponding increment,
just like with refcounts. And the device should never be
runtime-suspended unless the counter is 0.
> What to do? Using pm_runtime_suspended seems racy...
What exactly is the problem? Are you worried about the
pcmcia_store_pm_state() routine? It's not clear to me that the routine
is needed. One of the background assumptions behind the runtime PM
framework is that users don't tell the system when to suspend devices.
Instead, the system automatically suspends devices when it realizes
they aren't being used.
Note that suspending a device is different from turning it off. When a
device is off, it stays off -- it doesn't get turned on automatically
when a process tries to use it. But a runtime-suspended device _does_
get resumed automatically as needed.
So if pcmcia_store_pm_state() is meant to turn the device off, then it
shouldn't use the runtime PM framework. If it is meant only to suspend
the device then it shouldn't exist.
> (6) As pcmcia_dev_resume() is used -- as per UNIVERSAL_DEV_PM_OPS -- what is
> needed there to set the runtime PM state correctly if we
pci_bus_for_each_resource, transparent bridges and rsrc_nonstatic.c
Bjorn, Jesse, Komuro reports the following issue: lspci -vvv [snippets]: 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93) (prog-if 01 [Subtractive decode]) ... Bus: primary=00, secondary=04, subordinate=05, sec-latency=32 I/O behind bridge: 1000-1fff Memory behind bridge: d200-d40f Prefetchable memory behind bridge: d000-d1ff 04:06.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6) Iterating over the bus (4) resources used to report just IO 0x1000-0x1, MEM d2...-d4..., prefetch d0...-d1..., and that's exactly what we need in drivers/pcmcia/rsrc_nonstatic.c . However, the newly added pci_bus_for_each_resource() seems to return _also_ additional resources, which we need to exclude in drivers/pcmcia/rssrc_nonstatic.c . Any ideas on how to fix this issue? > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge I/O window: 0x1000 - > 0x1fff > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge Memory window: > 0xd200 - 0xd40f > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge Memory window: > 0xd000 - 0xd1ff > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge I/O window: 0x0 - 0xcf7 > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge I/O window: 0xd00 - > 0x > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge Memory window: 0xa > - 0xb > yenta_cardbus :04:06.0: pcmcia: parent PCI bridge Memory window: > 0xc000 - 0xfebf Best, Dominik ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [BUG? kernel 2.6.34-rc1-git8] cs: IO port probe 0x0-0xcf7: clean.
Hi, >> Actually, ioport 0x0-0xff is used for onboard legacy devices. >> So it should be excluded? > >Probably -- and none of the devices listed below seem to actually be PCI >devcices... However, I have no idea why there is a "PCI Bus :00" here. >Oh wait. Is this the PC in which both pd6729 and yenta_socket are installed? sorry, This PC is different with the PC with pd6729 and yenta_socket are installed. Here is the dmesg and lspci -vvv [dmesg] Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 2.6.34-rc2 (r...@localhost.localdomain) (gcc version 4.4.0 20090506 (Red Hat 4.4.0-4) (GCC) ) #1 SMP Sun Mar 21 20:58:10 JST 2010 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - b7b6c000 (usable) BIOS-e820: b7b6c000 - b7bbf000 (reserved) BIOS-e820: b7bbf000 - b7c86000 (usable) BIOS-e820: b7c86000 - b7cbf000 (ACPI NVS) BIOS-e820: b7cbf000 - b7ced000 (usable) BIOS-e820: b7ced000 - b7cff000 (ACPI data) BIOS-e820: b7cff000 - b7d0 (usable) BIOS-e820: b7d0 - c000 (reserved) BIOS-e820: f800 - fc00 (reserved) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fed1 - fed14000 (reserved) BIOS-e820: fed18000 - fed1a000 (reserved) BIOS-e820: fed1c000 - fed2 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: fff0 - 0001 (reserved) BIOS-e820: 0001 - 00014000 (usable) NX (Execute Disable) protection: active DMI 2.4 present. e820 update range: - 1000 (usable) ==> (reserved) e820 remove range: 000a - 0010 (usable) last_pfn = 0x14 max_arch_pfn = 0x100 MTRR default type: uncachable MTRR fixed ranges enabled: 0-9 write-back A-C uncachable D-D write-protect E-F uncachable MTRR variable ranges enabled: 0 base 0FFFE mask E write-protect 1 base 0 mask F8000 write-back 2 base 08000 mask FC000 write-back 3 base 0B800 mask FF800 uncachable 4 base 0B7E0 mask FFFE0 uncachable 5 base 0B7D0 mask 0 uncachable 6 base 1 mask FC000 write-back 7 disabled x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 initial memory mapped : 0 - 00e0 init_memory_mapping: -375fe000 00 - 20 page 4k 20 - 003740 page 2M 003740 - 00375fe000 page 4k kernel direct mapping tables up to 375fe000 @ 7000-f000 RAMDISK: 37ce2000 - 37fef817 Allocated new RAMDISK: 009f5000 - 00d02817 Move RAMDISK from 37ce2000 - 37fef816 to 009f5000 - 00d02816 ACPI: RSDP 000fe020 00024 (v02 TOSINV) ACPI: XSDT b7cfe120 00064 (v01 TOSINV TOSINV00 0001 0113) ACPI: FACP b7cfd000 000F4 (v04 TOSINV TOSINV00 0001 MSFT 0113) ACPI: DSDT b7cf 08FA8 (v01 TOSINV TOSINV00 0001 MSFT 0113) ACPI: FACS b7c93000 00040 ACPI: HPET b7cfc000 00038 (v01 TOSINV TOSINV00 0001 MSFT 0113) ACPI: APIC b7cfb000 0006C (v02 TOSINV TOSINV00 0001 MSFT 0113) ACPI: MCFG b7cfa000 0003C (v01 TOSINV TOSINV00 0001 MSFT 0113) ACPI: ASF! b7cf9000 000A5 (v32 TOSINV TOSINV00 0001 MSFT 0113) ACPI: SLIC b7cef000 00176 (v01 TOSINV TOSINV00 0001 MSFT 0113) ACPI: BOOT b7cee000 00028 (v01 TOSINV TOSINV00 0001 MSFT 0113) ACPI: SSDT b7ced000 00655 (v01 PmRefCpuPm 3000 INTL 20051117) ACPI: Local APIC address 0xfee0 4234MB HIGHMEM available. 885MB LOWMEM available. mapped low ram: 0 - 375fe000 low ram: 0 - 375fe000 Zone PFN ranges: DMA 0x0001 -> 0x1000 Normal 0x1000 -> 0x000375fe HighMem 0x000375fe -> 0x0014 Movable zone start PFN for each node early_node_map[6] active PFN ranges 0: 0x0001 -> 0x009f 0: 0x0100 -> 0x000b7b6c 0: 0x000b7bbf -> 0x000b7c86 0: 0x000b7cbf -> 0x000b7ced 0: 0x000b7cff -> 0x000b7d00 0: 0x0010 -> 0x0014 On node 0 totalpages: 1014784 free_area_init_node: node 0, pgdat c089d580, node_mem_map c1001020 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 3966 pages, LIFO batch:0 Normal zone: 1740 pages used for memmap Normal zone: 220978 pages, LIFO batch:31 HighMem zone: 8469 pages used for memmap HighMem zone: 779599 pages, LIFO batch:31 Using APIC driver default ACPI: PM-Timer IO Port: 0x408 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x00] disabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x
Re: [BUG? kernel 2.6.34-rc1-git8] cs: IO port probe 0x0-0xcf7: clean.
Addendum: Could you send a "lspci -vvv" (again), please? Also, what's s->cb_dev->bus->number ? Best, Dominik ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [BUG? kernel 2.6.34-rc1-git8] cs: IO port probe 0x0-0xcf7: clean.
Hey,
On Mon, Mar 22, 2010 at 09:40:22AM +0900, Komuro wrote:
> >> I don't add "include port 0x0-0xcf7" in /etc/pcmcia/config.opts.
> >> but recent kernel probes this ioport range ...
> >
> >That's because the parent PCI bridge offers these resources for downstream
> >users, such as yenta_cardbus. So that's not a bug.
>
>
> Actually, ioport 0x0-0xff is used for onboard legacy devices.
> So it should be excluded?
Probably -- and none of the devices listed below seem to actually be PCI
devcices... However, I have no idea why there is a "PCI Bus :00" here.
Oh wait. Is this the PC in which both pd6729 and yenta_socket are installed?
Its dmesg contained:
pci_root PNP0A03:00: host bridge window [io 0x-0x0cf7] (ignored)
[because of pci=use_crs being disabled on this system)
but later on
pci :00:11.6: reg 10: [io 0x-0x00ff]
this PCI device actually requests io from 0x00 to 0xff! Which PCI device is
it? Later on:
pnp 00:0a: disabling [io 0x0010-0x001f] because it overlaps :00:11.6 BAR 0
[io 0x-0x00ff]
pnp 00:0a: disabling [io 0x0022-0x003f] because it overlaps :00:11.6 BAR 0
[io 0x-0x00ff]
pnp 00:0a: disabling [io 0x0044-0x005f] because it overlaps :00:11.6 BAR 0
[io 0x-0x00ff]
pnp 00:0a: disabling [io 0x0062-0x0063] because it overlaps :00:11.6 BAR 0
[io 0x-0x00ff]
pnp 00:0a: disabling [io 0x0065-0x006f] because it overlaps :00:11.6 BAR 0
[io 0x-0x00ff]
pnp 00:0a: disabling [io 0x0072-0x007f] because it overlaps :00:11.6 BAR 0
[io 0x-0x00ff]
pnp 00:0a: disabling [io 0x0080] because it overlaps :00:11.6 BAR 0 [io
0x-0x00ff]
pnp 00:0a: disabling [io 0x0084-0x0086] because it overlaps :00:11.6 BAR 0
[io 0x-0x00ff]
pnp 00:0a: disabling [io 0x0088] because it overlaps :00:11.6 BAR 0 [io
0x-0x00ff]
pnp 00:0a: disabling [io 0x008c-0x008e] because it overlaps :00:11.6 BAR 0
[io 0x-0x00ff]
pnp 00:0a: disabling [io 0x0090-0x009f] because it overlaps :00:11.6 BAR 0
[io 0x-0x00ff]
pnp 00:0a: disabling [io 0x00a2-0x00bf] because it overlaps :00:11.6 BAR 0
[io 0x-0x00ff]
pnp 00:0a: disabling [io 0x00e0-0x00ef] because it overlaps :00:11.6 BAR 0
[io 0x-0x00ff]
So -- we could either manually exclude <0xff on x86{_64}, we could ask the
PCI people to fix this (or why they consider 0x00-0xff to be valid here)...
What do you think?
Best,
Dominik
> -0cf7 : PCI Bus :00
> -001f : dma1
> 0020-0021 : pic1
> 0040-0043 : timer0
> 0050-0053 : timer1
> 0060-0060 : keyboard
> 0064-0064 : keyboard
> 0070-0077 : rtc0
> 0080-008f : dma page reg
> 00a0-00a1 : pic2
> 00c0-00df : dma2
> 00f0-00ff : fpu
>
> ___
> Linux PCMCIA reimplementation list
> http://lists.infradead.org/mailman/listinfo/linux-pcmcia
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
