From: Scott Wood <scottwood@freescale.com>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: linuxppc <linuxppc-dev@lists.ozlabs.org>, Kevin Hao <haokexin@gmail.com>
Subject: Re: [PATCH] powerpc/mpc85xx: match with the pci bus address used by u-boot for all p1_p2_rdb_pc boards
Date: Thu, 30 May 2013 09:43:28 -0500 [thread overview]
Message-ID: <1369925008.14679.1@snotra> (raw)
In-Reply-To: <9845CB5F-0E99-49A5-A10B-CD2E2379E903@kernel.crashing.org> (from galak@kernel.crashing.org on Thu May 30 09:21:19 2013)
On 05/30/2013 09:21:19 AM, Kumar Gala wrote:
>=20
> On May 28, 2013, at 5:45 PM, Scott Wood wrote:
>=20
> > On 05/16/2013 01:29:45 AM, Kevin Hao wrote:
> >> All these boards use the same configuration file p1_p2_rdb_pc.h in
> >> u-boot. So they have the same pci bus address set by the u-boot.
> >> But in some of these boards the bus address set in dtb don't match
> >> the one used by u-boot. And this will trigger a kernel bug in 32bit
> >> kernel and cause the pci device malfunction. For example, on a
> >> p2020rdb-pc board the u-boot use the 0xa0000000 as both bus address
> >> and cpu address for one pci controller and then assign bus address
> >> such as 0xa00004000 to some pci device. But in the kernel, the dtb
> >> set the bus address to 0xe0000000 and the cpu address to =20
> 0xa0000000.
> >> The kernel assumes mistakenly the assigned bus address 0xa0004000
> >> in pci device is correct and keep it unchanged. This will =20
> definitely
> >> cause the pci device malfunction. I have made two patches to fix
> >> this in the pci subsystem.
> >> http://patchwork.ozlabs.org/patch/243702/
> >> http://patchwork.ozlabs.org/patch/243703/
> >> But I still think it makes sense to set these bus address to match
> >> with the u-boot. This issue can't be reproduced on 36bit kernel.
> >> But I also tweak the 36bit dtb for the above reason.
> >
> > IIRC the reason for using 0xe0000000 on all PCIe roots is to =20
> maximize the memory that is DMA-addressable without involving swiotlb.
> >
> > Maybe U-Boot should be fixed?
> >
> > -Scott
>=20
> I feel that u-boot was the way it is to allow accessing each bus from =20
> the command line in u-boot w/o big changes for >32-bit addressing.
>=20
> Linux was able to handle the PCI bus addresses all being the same.
It's a bit of a hack though, in that you're using the device tree to =20
indicate how you want the hardware programmed rather than to describe =20
the hardware or even what U-Boot's done to it, and in that you can't =20
arbitrarily change what U-Boot chose -- it only works because you're =20
picking an address that U-Boot used for one of the PCIe controllers and =20
thus U-Boot covered it with a LAW.
-Scott=
prev parent reply other threads:[~2013-05-30 14:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-16 6:29 [PATCH] powerpc/mpc85xx: match with the pci bus address used by u-boot for all p1_p2_rdb_pc boards Kevin Hao
2013-05-28 22:45 ` Scott Wood
2013-05-30 3:25 ` Kevin Hao
2013-05-30 18:57 ` Scott Wood
2013-05-31 7:53 ` Kevin Hao
2013-06-01 12:12 ` [PATCH v2] " Kevin Hao
2013-05-30 14:21 ` [PATCH] " Kumar Gala
2013-05-30 14:43 ` Scott Wood [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=1369925008.14679.1@snotra \
--to=scottwood@freescale.com \
--cc=galak@kernel.crashing.org \
--cc=haokexin@gmail.com \
--cc=linuxppc-dev@lists.ozlabs.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.