Re: [PATCH v2] pcmcia: db1xxx-ss: suspend/resume fix
On Tuesday 23 March 2010, Manuel Lauss wrote: > Howdy, > > On Mon, Mar 22, 2010 at 9:58 PM, Dominik Brodowski > wrote: > > 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 > > Yes it does, works on my MIPS test systems. I don't seem to have received the original message, so sorry for the lack of response. > > propose pushing both patches already for 2.6.36. Rafael: do you concur? I do. The patches look good and if they fix things for people right now, that's a good reason to push them for .34. > I hope you meant 2.6.34 I think Dominik meant .35 actually. Rafael ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
acpi=off pci=biosirq irqfixup SLOT2
[1.478062] device-mapper: uevent: version 1.0.3 [1.478808] device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-de...@redhat.com [1.479474] device-mapper: multipath: version 1.1.0 loaded [1.479570] device-mapper: multipath round-robin: version 1.0.0 loaded [1.480568] EISA: Probing bus 0 at eisa.0 [1.480665] Cannot allocate resource for EISA slot 1 [1.480738] Cannot allocate resource for EISA slot 2 [1.480809] Cannot allocate resource for EISA slot 3 [1.480908] EISA: Detected 0 cards. [1.481311] cpuidle: using governor ladder [1.481391] cpuidle: using governor menu [1.484101] TCP cubic registered [1.484967] NET: Registered protocol family 10 [1.487047] lo: Disabled Privacy Extensions [1.488655] NET: Registered protocol family 17 [1.488841] Bluetooth: L2CAP ver 2.13 [1.488909] Bluetooth: L2CAP socket layer initialized [1.488983] Bluetooth: SCO (Voice Link) ver 0.6 [1.489051] Bluetooth: SCO socket layer initialized [1.489313] Bluetooth: RFCOMM TTY layer initialized [1.489394] Bluetooth: RFCOMM socket layer initialized [1.489465] Bluetooth: RFCOMM ver 1.11 [1.489573] Using IPI No-Shortcut mode [1.489995] PM: Resume from disk failed. [1.490049] registered taskstats version 1 [1.490475] Magic number: 2:413:650 [1.490689] rtc_cmos 00:05: setting system clock to 2010-03-23 20:37:46 UTC (126937) [1.490788] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [1.490859] EDD information not available. [1.507744] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input1 [1.632575] ata2.00: ATAPI: HL-DT-ST DVDRAM GMA-4082N, HJ02, max UDMA/33 [1.633437] ata1.00: ATA-5: FUJITSU MHM2100AT, 5823, max UDMA/66 [1.633521] ata1.00: 19640880 sectors, multi 16: LBA [1.648396] ata2.00: configured for UDMA/33 [1.649098] ata1.00: configured for UDMA/66 [1.649787] scsi 0:0:0:0: Direct-Access ATA FUJITSU MHM2100A 5823 PQ: 0 ANSI: 5 [1.650593] sd 0:0:0:0: Attached scsi generic sg0 type 0 [1.650909] sd 0:0:0:0: [sda] 19640880 512-byte logical blocks: (10.0 GB/9.36 GiB) [1.651261] sd 0:0:0:0: [sda] Write Protect is off [1.651340] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [1.651481] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [1.652307] sda: [1.656515] scsi 1:0:0:0: CD-ROMHL-DT-ST DVDRAM GMA-4082N HJ02 PQ: 0 ANSI: 5 [1.668523] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray [1.668633] Uniform CD-ROM driver Revision: 3.20 [1.669110] sr 1:0:0:0: Attached scsi CD-ROM sr0 [1.669358] sr 1:0:0:0: Attached scsi generic sg1 type 5 [1.670834] sda1 < sda5 sda6 > sda3 [1.693480] sd 0:0:0:0: [sda] Attached SCSI disk [1.693644] Freeing unused kernel memory: 540k freed [1.697428] Write protecting the kernel text: 4568k [1.697676] Write protecting the kernel read-only data: 1836k [1.784051] usb 1-2: new full speed USB device using uhci_hcd and address 2 [2.110574] usb 1-2: configuration #1 chosen from 1 choice [2.572160] Linux agpgart interface v0.103 [2.905010] agpgart-intel :00:00.0: Intel i815 Chipset [3.070808] agpgart-intel :00:00.0: AGP aperture is 64M @ 0xf800 [3.176764] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[10] MMIO=[f4104000-f41047ff] Max Packet=[2048] IR/IT contexts=[4/8] [4.270299] PM: Starting manual resume from disk [4.270397] PM: Resume from partition 8:6 [4.270405] PM: Checking hibernation image. [4.270934] PM: Resume from disk failed. [4.346555] kjournald starting. Commit interval 5 seconds [4.346700] EXT3-fs: mounted filesystem with writeback data mode. [4.452392] ieee1394: Host added: ID:BUS[0-00:1023] GUID[0800460300a53ece] [5.955923] type=1505 audit(1269376670.965:2): operation="profile_load" pid=298 name=/usr/share/gdm/guest-session/Xsession [6.031994] type=1505 audit(1269376671.041:3): operation="profile_load" pid=299 name=/sbin/dhclient3 [6.034135] type=1505 audit(1269376671.041:4): operation="profile_load" pid=299 name=/usr/lib/NetworkManager/nm-dhcp-client.action [6.035318] type=1505 audit(1269376671.041:5): operation="profile_load" pid=299 name=/usr/lib/connman/scripts/dhclient-script [6.143674] type=1505 audit(1269376671.149:6): operation="profile_load" pid=300 name=/usr/bin/evince [6.178958] type=1505 audit(1269376671.185:7): operation="profile_load" pid=300 name=/usr/bin/evince-previewer [6.202090] type=1505 audit(1269376671.209:8): operation="profile_load" pid=300 name=/usr/bin/evince-thumbnailer [6.285969] type=1505 audit(1269376671.293:9): operation="profile_load" pid=302 name=/usr/lib/cups/backend/cups-pdf [6.288713] type=1505 audit(1269376671.297:10): operation="profile_load" pid=302 name=/usr/sbin/cupsd [6.311426] type=1505 audit(1269376671
dmesg acpi=off pci=biosirq irqfixup SLOT 1
/form2 cdda tray [1.674584] Uniform CD-ROM driver Revision: 3.20 [1.675073] sr 1:0:0:0: Attached scsi CD-ROM sr0 [1.675324] sr 1:0:0:0: Attached scsi generic sg1 type 5 [1.691147] sda6 > sda3 [1.692880] sd 0:0:0:0: [sda] Attached SCSI disk [1.693045] Freeing unused kernel memory: 540k freed [1.696836] Write protecting the kernel text: 4568k [1.697085] Write protecting the kernel read-only data: 1836k [1.788070] usb 1-2: new full speed USB device using uhci_hcd and address 2 [2.116950] usb 1-2: configuration #1 chosen from 1 choice [2.685078] Linux agpgart interface v0.103 [2.954305] agpgart-intel :00:00.0: Intel i815 Chipset [3.053012] agpgart-intel :00:00.0: AGP aperture is 64M @ 0xf800 [3.176085] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[10] MMIO=[f4104000-f41047ff] Max Packet=[2048] IR/IT contexts=[4/8] [4.326137] PM: Starting manual resume from disk [4.326240] PM: Resume from partition 8:6 [4.326248] PM: Checking hibernation image. [4.326871] PM: Resume from disk failed. [4.402938] kjournald starting. Commit interval 5 seconds [4.403067] EXT3-fs: mounted filesystem with writeback data mode. [4.456652] ieee1394: Host added: ID:BUS[0-00:1023] GUID[0800460300a53ece] [6.040851] type=1505 audit(1269375678.048:2): operation="profile_load" pid=300 name=/usr/share/gdm/guest-session/Xsession [6.116705] type=1505 audit(1269375678.124:3): operation="profile_load" pid=301 name=/sbin/dhclient3 [6.118825] type=1505 audit(1269375678.124:4): operation="profile_load" pid=301 name=/usr/lib/NetworkManager/nm-dhcp-client.action [6.120077] type=1505 audit(1269375678.128:5): operation="profile_load" pid=301 name=/usr/lib/connman/scripts/dhclient-script [6.228355] type=1505 audit(1269375678.236:6): operation="profile_load" pid=302 name=/usr/bin/evince [6.264150] type=1505 audit(1269375678.272:7): operation="profile_load" pid=302 name=/usr/bin/evince-previewer [6.286745] type=1505 audit(1269375678.292:8): operation="profile_load" pid=302 name=/usr/bin/evince-thumbnailer [6.370902] type=1505 audit(1269375678.376:9): operation="profile_load" pid=304 name=/usr/lib/cups/backend/cups-pdf [6.373676] type=1505 audit(1269375678.380:10): operation="profile_load" pid=304 name=/usr/sbin/cupsd [6.396483] type=1505 audit(1269375678.404:11): operation="profile_load" pid=305 name=/usr/sbin/tcpdump [ 28.697992] Adding 546168k swap on /dev/sda6. Priority:-1 extents:1 across:546168k [ 28.780353] udev: starting version 147 [ 29.178320] EXT3 FS on sda5, internal journal [ 29.968308] lp: driver loaded but no devices found [ 29.976693] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [ 30.055212] Intel 82802 RNG detected [ 30.429891] cfg80211: Calling CRDA to update world regulatory domain [ 30.620322] cfg80211: World regulatory domain updated: [ 30.620343] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 30.620357] (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [ 30.620370] (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [ 30.620383] (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [ 30.620395] (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 2000 mBm) [ 30.620407] (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [ 31.214992] yenta_cardbus :01:02.0: CardBus bridge found [104d:80df] [ 31.215035] yenta_cardbus :01:02.0: no PCI IRQ, CardBus support disabled for this socket. [ 31.215048] yenta_cardbus :01:02.0: check your BIOS CardBus, BIOS IRQ or ACPI settings. [ 33.517548] irq 10: nobody cared (try booting with the "irqpoll" option) [ 33.517652] Pid: 475, comm: modprobe Not tainted 2.6.31-16-generic #52-Ubuntu [ 33.517664] Call Trace: [ 33.517698] [] ? printk+0x18/0x1c [ 33.517740] [] __report_bad_irq+0x27/0x90 [ 33.517756] [] note_interrupt+0x150/0x190 [ 33.517786] [] ? mask_and_ack_8259A+0x52/0xf0 [ 33.517801] [] handle_level_irq+0xbc/0xe0 [ 33.517816] [] handle_irq+0x18/0x30 [ 33.517829] [] do_IRQ+0x47/0xc0 [ 33.517855] [] ? ata_sff_host_intr+0xa2/0x160 [ 33.517870] [] common_interrupt+0x30/0x40 [ 33.517887] [] ? schedule_hrtimeout_range+0xbb/0x150 [ 33.517903] [] ? can_request_irq+0x10/0x40 [ 33.517930] [] ? __do_softirq+0x45/0x1a0 [ 33.517957] [] ? default_spin_lock_flags+0x8/0x10 [ 33.517976] [] ? _spin_lock_irqsave+0x2a/0x40 [ 33.517991] [] ? enable_8259A_irq+0x42/0x60 [ 33.518005] [] ? handle_level_irq+0xa6/0xe0 [ 33.518020] [] do_softirq+0x3d/0x40 [ 33.518035] [] irq_exit+0x5d/0x70 [ 33.518048] [] do_IRQ+0x50/0xc0 [ 33.518061] [] ? schedule_timeout+0x131/0x200 [ 33.518076] [] common_interrupt+0x30/0x40 [ 33.518092] [] ? delay_tsc+0x28/0x70 [ 33.518105] [] __delay+0x9/0x10 [ 33.518118] [] __const_udelay+0x2b/0x30 [ 33.518157] [] yenta_get_socket_capabilities+0xf2/0x15
Re: Boot options acpi=off pci=biosirq dmesg
Hi Dominik! I checked under Windows! IRQ9 is being used for the pcmcia card! I'm going to try right now the acpi=off pci=biosirq irqfixup acpi=off pci=biosirq irqpoll I'll let you know in a few minutes ;-) Cyrille ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: pci_bus_for_each_resource, transparent bridges and rsrc_nonstatic.c
> I'm concerned that this changes a resource that PCMCIA doesn't own, > i.e., this struct resource actually lives in the pci_dev of an upstream > bridge or in the host bridge data. Oh yes, you're right -- my patch was badly broken. Brown paper-bag style. > > + > > if (res == &ioport_resource) > > continue; > > If you make PCMCIA smart enough to avoid these low ports, do we still > need these &ioport_resource and &iomem_resource checks? Having two > mechanisms will lead to more complicated behavior and more special > cases. Well, it aren't only the low ports (<0x100) I'm concerned about, it's also (and especially on pre-2008 systems) ports in higher areas (0x100 < x < 0x). If we don't use _CRS, we need to be more careful to avoid accidentally hitting wrong I/O-ports. > > - dev_printk(KERN_INFO, &s->cb_dev->dev, > > - "pcmcia: parent PCI bridge I/O " > > - "window: 0x%llx - 0x%llx\n", > > - (unsigned long long)res->start, > > - (unsigned long long)res->end); > > + dev_info(&s->cb_dev->dev, "pcmcia: parent PCI bridge " > > + "window: %pR\n", res); > > Jesse applied a patch from me to make this %pR change just a few days ago. Okay, I'll leave that alone then. Thanks, Dominik From: Dominik Brodowski Date: Tue, 23 Mar 2010 16:05:00 +0100 Subject: [PATCH] pcmcia: do not use ioports < 0x100 on x86 On x86 systems using ACPI _CRS information -- now the default for post-2008 systems -- the PCI root bus no longer pretends to be offering the root ioport_resource. To avoid accidentally hitting some platform / system device, use only I/O ports >= 0x100 for PCMCIA devices on x86. Reported-by: Komuro CC: Bjorn Helgaas Signed-off-by: Dominik Brodowski diff --git a/drivers/pcmcia/rsrc_nonstatic.c b/drivers/pcmcia/rsrc_nonstatic.c index 4663b3f..dcc6021 100644 --- a/drivers/pcmcia/rsrc_nonstatic.c +++ b/drivers/pcmcia/rsrc_nonstatic.c @@ -810,6 +810,13 @@ static int adjust_io(struct pcmcia_socket *s, unsigned int action, unsigned long unsigned long size = end - start + 1; int ret = 0; +#if defined(CONFIG_X86) + /* on x86, avoid anything < 0x100 for it is often used for +* legacy platform devices */ + if (start < 0x100) + start = 0x100; +#endif + if (end < start) return -EINVAL; ___ 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 Tuesday 23 March 2010 09:13:01 am Dominik Brodowski wrote:
> From: Dominik Brodowski
> Date: Tue, 23 Mar 2010 16:05:00 +0100
> Subject: [PATCH] pcmcia: do not use ioports < 0x100 on x86
>
> On x86 systems using ACPI _CRS information -- now the default for
> post-2008 systems -- the PCI root bus no longer pretends to be
> offering the root ioport_resource. To avoid accidentally hitting
> some platform / system device, use only I/O ports >= 0x100 for
> PCMCIA devices on x86.
>
> Also, use %pR, while we're there.
>
> Reported-by: Komuro
> CC: Bjorn Helgaas
> Signed-off-by: Dominik Brodowski
>
> diff --git a/drivers/pcmcia/rsrc_nonstatic.c b/drivers/pcmcia/rsrc_nonstatic.c
> index 4663b3f..7ae5b0f 100644
> --- a/drivers/pcmcia/rsrc_nonstatic.c
> +++ b/drivers/pcmcia/rsrc_nonstatic.c
> @@ -864,13 +864,21 @@ static int nonstatic_autoadd_resources(struct
> pcmcia_socket *s)
> continue;
>
> if (res->flags & IORESOURCE_IO) {
> +
> +#if defined(CONFIG_X86)
> + /* on x86, avoid anything < 0x100 for it is often
> + * used for legacy platform devices
> + */
> + if (res->start < 0x100)
> + res->start = 0x100;
> + if (res->start >= res->end)
> + continue;
> +#endif
I'm concerned that this changes a resource that PCMCIA doesn't own,
i.e., this struct resource actually lives in the pci_dev of an upstream
bridge or in the host bridge data.
Doesn't PCMCIA maintain its own resource_map structures, and if so,
wouldn't it be cleaner to modify *those* instead, or change the
allocator to avoid these low ports?
> +
> if (res == &ioport_resource)
> continue;
If you make PCMCIA smart enough to avoid these low ports, do we still
need these &ioport_resource and &iomem_resource checks? Having two
mechanisms will lead to more complicated behavior and more special
cases.
> - dev_printk(KERN_INFO, &s->cb_dev->dev,
> -"pcmcia: parent PCI bridge I/O "
> -"window: 0x%llx - 0x%llx\n",
> -(unsigned long long)res->start,
> -(unsigned long long)res->end);
> + dev_info(&s->cb_dev->dev, "pcmcia: parent PCI bridge "
> + "window: %pR\n", res);
Jesse applied a patch from me to make this %pR change just a few days ago.
Bjorn
> if (!adjust_io(s, ADD_MANAGED_RESOURCE, res->start,
> res->end))
> done |= IORESOURCE_IO;
>
> @@ -879,11 +887,8 @@ static int nonstatic_autoadd_resources(struct
> pcmcia_socket *s)
> if (res->flags & IORESOURCE_MEM) {
> if (res == &iomem_resource)
> continue;
> - dev_printk(KERN_INFO, &s->cb_dev->dev,
> -"pcmcia: parent PCI bridge Memory "
> -"window: 0x%llx - 0x%llx\n",
> -(unsigned long long)res->start,
> -(unsigned long long)res->end);
> + dev_info(&s->cb_dev->dev, "pcmcia: parent PCI bridge "
> + "window: %pR\n", res);
> if (!adjust_memory(s, ADD_MANAGED_RESOURCE, res->start,
> res->end))
> done |= IORESOURCE_MEM;
> }
>
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [PATCH v2] pcmcia: db1xxx-ss: suspend/resume fix
Howdy, On Mon, Mar 22, 2010 at 9:58 PM, Dominik Brodowski wrote: > 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 Yes it does, works on my MIPS test systems. > propose pushing both patches already for 2.6.36. Rafael: do you concur? I hope you meant 2.6.34 Thanks! Manuel Lauss ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Card Memory windows in client driver - how to access ?
Using INT_MEMORY_AND_IO didnt help either
This is what I got when I dumped the contents of pDev->conf in my config
routine
conf.Attributes = 0
conf.ConfigBase = 1024
conf.Vpp = 0
conf.IntType = 0
conf.Status = 0
conf.Pin = 0
conf.Copy = 0
conf.ExStatus = 0
conf.ConfigIndex = 0
conf.Present = 37
Is conf.Vpp = 0 the problem here ?
-R-
- Original Message -
From: "Dominik Brodowski"
To: "raraks"
Cc:
Sent: Tuesday, March 23, 2010 9:14 AM
Subject: Re: Card Memory windows in client driver - how to access ?
On Tue, Mar 23, 2010 at 09:13:27AM -0700, raraks wrote:
- I would think that pDev->conf.ConfigBase and pDev->conf.Present will
only be valid after a pcmcia_request_configuration. Is it valid in the
probe routine ?
It's set up before ->probe() is being called:
ret = pccard_read_tuple(p_dev->socket, p_dev->func, CISTPL_CONFIG,
&cis_config);
if (!ret) {
p_dev->conf.ConfigBase = cis_config.base;
p_dev->conf.Present = cis_config.rmask[0];
} ...
ret = p_drv->probe(p_dev);
- I havent tried using INT_MEMORY_AND_IO but have tried using access
speed
0. I know the card normally works at 200ns
Could you try it out (_AND_IO)?
Best,
Dominik
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Card Memory windows in client driver - how to access ?
On Tue, Mar 23, 2010 at 09:13:27AM -0700, raraks wrote:
> - I would think that pDev->conf.ConfigBase and pDev->conf.Present will
> only be valid after a pcmcia_request_configuration. Is it valid in the
> probe routine ?
It's set up before ->probe() is being called:
ret = pccard_read_tuple(p_dev->socket, p_dev->func, CISTPL_CONFIG,
&cis_config);
if (!ret) {
p_dev->conf.ConfigBase = cis_config.base;
p_dev->conf.Present = cis_config.rmask[0];
} ...
ret = p_drv->probe(p_dev);
> - I havent tried using INT_MEMORY_AND_IO but have tried using access speed
> 0. I know the card normally works at 200ns
Could you try it out (_AND_IO)?
Best,
Dominik
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Card Memory windows in client driver - how to access ?
- I am using 2.6.31-17
- I would think that pDev->conf.ConfigBase and pDev->conf.Present will only
be valid after a pcmcia_request_configuration. Is it valid in the probe
routine ?
- pDev->conf.ConfigBase is a pointer to attribute memory or common memory
window ? ...and how do I get the other window mapped for access ? (cistpl
config has default flag set and uses device size as common memory size.
Based on our last interchange I assume all attrib memory is sized 4K).
- I havent tried using INT_MEMORY_AND_IO but have tried using access speed
0. I know the card normally works at 200ns
- I believe CardOffset = 0 ... if not I dont know what value to set here ..
where do I get this info ? ( I have an older 2.4 card services version
driver that does the same thing when requesting mappings for both memory
windows ).
Thanks
-R-
- Original Message -
From: "Dominik Brodowski"
To: "raraks"
Cc:
Sent: Tuesday, March 23, 2010 8:30 AM
Subject: Re: Card Memory windows in client driver - how to access ?
Hey,
On Mon, Mar 22, 2010 at 04:40:33PM -0700, raraks wrote:
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];
That's already available in
p_dev->conf.ConfigBase
p_dev->conf.Present
no need to overwrite it here. Unless, of course, you're using an ld
kernel.
link->conf.IntType = INT_MEMORY;
What happens if you set this to INT_MEMORY_AND_IO ?
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;
Have you tried different accessspeed settings, or keeping it at 0?
ret = pcmcia_request_window(&link, &dev->request_attr_memory,
&dev->handle_attr_memory);
if (ret != 0) {
cs_error(link, RequestWindow, ret);
}
Using cs_error is deprecated.
memreq_attr_memory.CardOffset = 0;
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
Is this ordering correct? IIRC you shouldn't even have to call
pcmcia_request_configuration...
Best,
Dominik
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Card Memory windows in client driver - how to access ?
Hey,
On Mon, Mar 22, 2010 at 04:40:33PM -0700, raraks wrote:
> 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];
That's already available in
p_dev->conf.ConfigBase
p_dev->conf.Present
no need to overwrite it here. Unless, of course, you're using an ld
kernel.
> link->conf.IntType = INT_MEMORY;
What happens if you set this to INT_MEMORY_AND_IO ?
> 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;
Have you tried different accessspeed settings, or keeping it at 0?
>
> ret = pcmcia_request_window(&link, &dev->request_attr_memory,
> &dev->handle_attr_memory);
>
> if (ret != 0) {
> cs_error(link, RequestWindow, ret);
> }
Using cs_error is deprecated.
> memreq_attr_memory.CardOffset = 0;
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
Is this ordering correct? IIRC you shouldn't even have to call
pcmcia_request_configuration...
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 Tue, Mar 23, 2010 at 12:28:00AM +0100, Dominik Brodowski wrote:
> 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?
From: Dominik Brodowski
Date: Tue, 23 Mar 2010 16:05:00 +0100
Subject: [PATCH] pcmcia: do not use ioports < 0x100 on x86
On x86 systems using ACPI _CRS information -- now the default for
post-2008 systems -- the PCI root bus no longer pretends to be
offering the root ioport_resource. To avoid accidentally hitting
some platform / system device, use only I/O ports >= 0x100 for
PCMCIA devices on x86.
Also, use %pR, while we're there.
Reported-by: Komuro
CC: Bjorn Helgaas
Signed-off-by: Dominik Brodowski
diff --git a/drivers/pcmcia/rsrc_nonstatic.c b/drivers/pcmcia/rsrc_nonstatic.c
index 4663b3f..7ae5b0f 100644
--- a/drivers/pcmcia/rsrc_nonstatic.c
+++ b/drivers/pcmcia/rsrc_nonstatic.c
@@ -864,13 +864,21 @@ static int nonstatic_autoadd_resources(struct
pcmcia_socket *s)
continue;
if (res->flags & IORESOURCE_IO) {
+
+#if defined(CONFIG_X86)
+ /* on x86, avoid anything < 0x100 for it is often
+* used for legacy pl
Re: [BUG? kernel 2.6.34-rc1-git8] cs: IO port probe 0x0-0xcf7: clean.
Hi, Some pcmcia device works only with lower ioport ( ioport < 0x300 ) and does not work with higher ioport ( ioport > 0x400 ). Actually, it is difficult to find unused ioport in this lower area. One solution is to use PNP BIOS to get used ioport. but pre-1995 system does not have PNP BIOS. I'm not sure the recent system have PNP BIOS. Another solution is to use ACPI BIOS. but pre-1998 system does not have ACPI BIOS. ISA slot card is no longer sold in the PC store, but on-board legacy devices still use this lower ioport. Best Regards Komuro ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
