From: Alexander Bigga <ab@mycable.de>
To: linux-mips@linux-mips.org
Cc: ppopov@embeddedalley.com
Subject: [PATCH] fixup for pci config_access on alchemy au1x000
Date: Tue, 29 Aug 2006 16:48:34 +0200 [thread overview]
Message-ID: <200608291648.35250.ab@mycable.de> (raw)
Hi all,
I've encountered a serious problem with PCI config space access on Au1x000
platforms with recent 2.6.x-kernel. With 2.4.31 the same hardware works fine.
So I was looking for the differences:
Symptoms:
- no PCI-device is seen on bootup though two or three cards are present
- lspci output is empty
- OR: lspci shows 20 times the same device
(- OR: in some slot-configurations it worked anyhow)
System(s):
1. platform with Au1500 and three PCI-devices (actually a mycable XXS1500
with backplane for three PCI-devices)
2. platform with Au1550 and two PCI-devices (custom board)
Debugging:
I digged down to the config_access() of the au1xxx-processors in
arch/mips/pci/ops-au1000.c and switched on DEBUG.
The code of config_access() seems to be almost the same as of the
2.4.x-kernel. But the "pci_cfg_vm->addr" returned by get_vm_area(0x2000, 0)
once on booting is different. That's of course not forbidden. But the
alignment seems to be wrong. In my case, I received:
2.4.31: pci_cfg_vm->addr = c0000000
2.6.18-rc5: pci_cfg_vm->addr = c0101000
To make it short: With 2.6.x it fails on the first config-access with:
"PCI ERR detected: status 83a00356".
Fixup:
My fix is now, to use the VM_IOREMAP-flag in the get_vm_area call. This flag
seems to be introduced in mm/vmalloc.c a long time ago (in 2.6.7-bk13, I
found in gitweb).
Now, the returned address is pci_cfg_vm->addr = c0104000 and everything works
fine.
What do you think about my fixup-patch?
Nobody's using the get_vm_area()-call without any flag ("0"). Was it only
forgotten in the arch/mips/pci/ops-au1000.c?
Or am I completely wrong?
Thanks a lot for your comments!
Best regard,
Alexander
--- linux-2.6.18-rc5/arch/mips/pci/ops-au1000.c 2006-08-28 12:09:15.000000000
+0200
+++ linux-2.6.18-rc5-dev/arch/mips/pci/ops-au1000.c 2006-08-29
13:08:59.000000000 +0200
@@ -110,7 +110,7 @@
if (first_cfg) {
/* reserve a wired entry for pci config accesses */
first_cfg = 0;
- pci_cfg_vm = get_vm_area(0x2000, 0);
+ pci_cfg_vm = get_vm_area(0x2000, VM_IOREMAP);
if (!pci_cfg_vm)
panic (KERN_ERR "PCI unable to get vm area\n");
pci_cfg_wired_entry = read_c0_wired();
--
Alexander Bigga Tel: +49 4873 90 10 866
mycable GmbH Fax: +49 4873 901 976
Boeker Stieg 43
D-24613 Aukrug eMail: ab@mycable.de
next reply other threads:[~2006-08-29 14:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-29 14:48 Alexander Bigga [this message]
2006-08-29 15:56 ` [PATCH] fixup for pci config_access on alchemy au1x000 Ralf Baechle
2006-08-30 10:50 ` Alexander Bigga
2006-08-29 17:43 ` Sergei Shtylyov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200608291648.35250.ab@mycable.de \
--to=ab@mycable.de \
--cc=linux-mips@linux-mips.org \
--cc=ppopov@embeddedalley.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.