All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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.