All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: Alexander Bigga <ab@mycable.de>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] fixup for pci config_access on alchemy au1x000
Date: Tue, 29 Aug 2006 21:43:25 +0400	[thread overview]
Message-ID: <44F47CBD.8090202@ru.mvista.com> (raw)
In-Reply-To: <200608291648.35250.ab@mycable.de>

Hello.

Alexander Bigga wrote:

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

    You're correct -- this code was only working by some chance. Once you get 
a virtual address not aligned to 8K, it breaks completely since the pages 
can't constitute a valid pair for wired entry anymore.
    Actually, in 2.4 the situation seems to be even worse as get_vm_area() 
there has no provision for the address alignment at all!

> Best regard,

> Alexander

WBR, Sergei

      parent reply	other threads:[~2006-08-29 17:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-29 14:48 [PATCH] fixup for pci config_access on alchemy au1x000 Alexander Bigga
2006-08-29 15:56 ` Ralf Baechle
2006-08-30 10:50   ` Alexander Bigga
2006-08-29 17:43 ` Sergei Shtylyov [this message]

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=44F47CBD.8090202@ru.mvista.com \
    --to=sshtylyov@ru.mvista.com \
    --cc=ab@mycable.de \
    --cc=linux-mips@linux-mips.org \
    /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.