* Re: [PATCH] [PowerPC] MPC8272ADS: fix device tree for 8 MB flash size
From: Scott Wood @ 2009-05-20 14:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Li Yang, Wolfgang Denk, LKML List
In-Reply-To: <156C2E1E-8E67-4358-B72E-4BB67D79C2AF@kernel.crashing.org>
Kumar Gala wrote:
> Scott, any feedback if our boards have 8M or 32M flash modules?
According to the manual, it comes with 8 but can be expanded to 32. I
don't think we swapped out the flash SIMM that came with the board.
As I wrote earlier in the thread, I don't see any way a current u-boot
would enable more than 8MiB of flash on this board anyway. I'd go ahead
and apply the patch.
-Scott
^ permalink raw reply
* Re: Weird 5200/mtd-ram problem
From: Gary Thomas @ 2009-05-20 14:23 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: linuxppc-dev
In-Reply-To: <14558983.1242828785546.JavaMail.ngmail@webmail10.arcor-online.net>
Albrecht Dreß wrote:
> Hi all,
>
> I ran into a weird problem when I tried to access a static (NV) ram attached to the localbus of a '5200 using Wolfram's mtd-ram OF driver (on a stock 2.6.29.1 kernel). The 512k ram chip is connected in 16-bit mode to cs1. the of entry reads
>
> nvram@1,0 {
> compatible = "mtd-ram";
> reg = <1 0x0 0x00080000>; // 512 kB
> bank-width = <2>;
> device-width = <2>;
> #size-cells = <1>;
> #address-cells = <1>;
> };
>
> For the test I created a "pattern file" which is filled with the unsigned long 0x0055aaff. Using the Abatron BDI3000, I can write the pattern file to the ram and re-read it without problems. The same applies to u-boot (write ram via tftp, dump contents).
>
> In Linux, when I write the file to /dev/mtdx, the last dword of each block is broken, e.g. when running "dd if=pattern of=/dev/mtd5 bs=512" the dword's at offset 0x1fc, 0x3fc, ... are 0x0000aaaa (instead of 0x0055aaff), if I use bs=1024 the dwords at 0x3fc, 0x7fc, ... show this value, if I use bs=4096 the dword at 0xffc shows this value, etc. I looked at the CS/WR lines with a scope, and I couldn't see anything special. The timing should be fine, as u-boot uses the same as Linux.
>
> Any idea what goes wrong here? I guessed I missed something in the LPB setup...
Check your cache setup - the BDI is most certainly not accessing
this via the Data cache whereas Linux probably will be.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Weird 5200/mtd-ram problem
From: Albrecht Dreß @ 2009-05-20 14:13 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I ran into a weird problem when I tried to access a static (NV) ram attache=
d to the localbus of a '5200 using Wolfram's mtd-ram OF driver (on a stock =
2.6.29.1 kernel). The 512k ram chip is connected in 16-bit mode to cs1. t=
he of entry reads
nvram@1,0 {
=09compatible =3D "mtd-ram";
=09reg =3D <1 0x0 0x00080000>; // 512 kB
=09bank-width =3D <2>;
=09device-width =3D <2>;
=09#size-cells =3D <1>;
=09#address-cells =3D <1>;
=09};
For the test I created a "pattern file" which is filled with the unsigned l=
ong 0x0055aaff. Using the Abatron BDI3000, I can write the pattern file to=
the ram and re-read it without problems. The same applies to u-boot (writ=
e ram via tftp, dump contents).
In Linux, when I write the file to /dev/mtdx, the last dword of each block =
is broken, e.g. when running "dd if=3Dpattern of=3D/dev/mtd5 bs=3D512" the =
dword's at offset 0x1fc, 0x3fc, ... are 0x0000aaaa (instead of 0x0055aaff),=
if I use bs=3D1024 the dwords at 0x3fc, 0x7fc, ... show this value, if I u=
se bs=3D4096 the dword at 0xffc shows this value, etc. I looked at the CS/=
WR lines with a scope, and I couldn't see anything special. The timing sho=
uld be fine, as u-boot uses the same as Linux.
Any idea what goes wrong here? I guessed I missed something in the LPB set=
up...
Thanks in advance,
Albrecht.
Arcor.de Gaming Area - kostenfrei daddeln bis der Arzt kommt!
Jetzt checken und aus =FCber 80 Spielen w=E4hlen!
http://www.arcor.de/footer-gaming/
^ permalink raw reply
* RE: mpc5200 fec error
From: Eric Millbrandt @ 2009-05-20 13:42 UTC (permalink / raw)
To: Wolfram Sang, Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20090520064218.GA29102@pengutronix.de>
> > I am able to reproduce the error using 2.6.29.2-rt11. I was able to
> > mitigate the problem by raising the priority of the transmit irq.
> > However when running an NFS server on the pcm030 under high cpu load =
I
> > now get
> >
> > [ 132.477503] net eth0: FEC_IEVENT_RFIFO_ERROR
> > [ 132.892329] net eth0: FEC_IEVENT_RFIFO_ERROR
> > [ 133.884109] net eth0: FEC_IEVENT_RFIFO_ERROR
> > [ 134.876059] net eth0: FEC_IEVENT_RFIFO_ERROR
> >
> > Raising the priority of the rx irq does not seem to fix this problem
> > though.
>=20
> Hi Eric,
>=20
> This error has been seen before in non-rt kernels. I haven't had the
> chance to track it down and kill it yet. I believe there are locking
> issues associated with it.
Uuuh, I recall this message. Kept me busy for some time :(
You might try this patch which helped in our situation.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Subject: Enable XLB pipelining for MPC5200B
From: Wolfram Sang <w.sang@pengutronix.de>
Enable pipelining as it helps getting rid of FEC problems.
Not intended for upstream, this must be dealt differently there.
This patch is disabled by default. The bootloader should enable this =
feature.
So, this patch is only intended to be used where the bootloader does it =
in a
wrong manner and can't be replaced.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: Juergen Beisert <j.beisert@pengutronix.de>
---
arch/powerpc/platforms/52xx/mpc52xx_common.c | 7 +++++++
1 file changed, 7 insertions(+)
Index: arch/powerpc/platforms/52xx/mpc52xx_common.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- arch/powerpc/platforms/52xx/mpc52xx_common.c.orig
+++ arch/powerpc/platforms/52xx/mpc52xx_common.c
@@ -107,6 +107,13 @@ mpc5200_setup_xlb_arbiter(void)
*/
if ((mfspr(SPRN_SVR) & MPC5200_SVR_MASK) =3D=3D MPC5200_SVR)
out_be32(&xlb->config, in_be32(&xlb->config) | =
MPC52xx_XLB_CFG_PLDIS);
+#if 0
+ /*
+ * Enable pipelining, fixes FEC problems. The previous workaround is =
not
+ * needed, as we have an MPC5200B (not A).
+ */
+ out_be32(&xlb->config, in_be32(&xlb->config) & =
~MPC52xx_XLB_CFG_PLDIS);
+#endif
=20
iounmap(xlb);
}
--=20
Pengutronix e.K. | Wolfram Sang =
|
Industrial Linux Solutions | http://www.pengutronix.de/ =
|
Wolfram,
Thanks, but no luck with this patch. It was already setup correctly by =
U-Boot.
Eric
_________________________________________________________________________=
________________
This e-mail and the information, including any attachments, it contains =
are intended to be a confidential communication only to the person or =
entity to whom it is addressed and may contain information that is =
privileged. If the reader of this message is not the intended recipient, =
you are hereby notified that any dissemination, distribution or copying =
of this communication is strictly prohibited. If you have received this =
communication in error, please immediately notify the sender and destroy =
the original message.
Thank you.
Please consider the environment before printing this email.
^ permalink raw reply
* Re: [PATCH] [PowerPC] MPC8272ADS: fix device tree for 8 MB flash size
From: Kumar Gala @ 2009-05-20 13:29 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev list, Li Yang, Wolfgang Denk, LKML List
In-Reply-To: <20090513194249.BA7D9832E416@gemini.denx.de>
On May 13, 2009, at 2:42 PM, Wolfgang Denk wrote:
> Dear Li Yang,
>
> In message <2a27d3730905130328m27743852w2d68a62ebc32ce31@mail.gmail.com
> > you wrote:
>>
>> Although 8MB seems to be the common size used. It can be very easy
>> changed as a pluggable module. It might be better to make the code
>> working for any reasonable flash sizes.
>
> You either have to provide a correct device tree for your board, or
> use a boot loader / boot wrapper that fixes the flash base address and
> size.
>
> At the moment, U-Boot does not contain any code yet to do that
> (patches welcome :-), and as far as I understand the cuImage wrapper
> works just the other way round: it adjusts the mappings to the
> settings in the device tree, which may or may not match the actual
> hardware. This may work, but at least gives you a different flash
> memory map in Linux than what you had before in U-Boot, so it's not
> really nice either.
>
>
> Hm... it seems the majority of MPC8272ADS boards seems to come indeed
> with 8 MB NOR flash, so I wonder if the patch should actually go in?
>
> Best regards,
>
> Wolfgang Denk
Scott, any feedback if our boards have 8M or 32M flash modules?
- k
^ permalink raw reply
* Re: [PATCH] powerpc/ep8248e: phylib needs NET_SCHED to build
From: Kumar Gala @ 2009-05-20 13:27 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev list, Alexander Beregalov, Netdev
In-Reply-To: <alpine.LRH.2.00.0905201425540.5871@vixen.sonytel.be>
On May 20, 2009, at 7:27 AM, Geert Uytterhoeven wrote:
> On Wed, 20 May 2009, Alexander Beregalov wrote:
>> Fix this build error:
>> drivers/built-in.o: In function `phy_state_machine':
>> drivers/net/phy/phy.c:893: undefined reference to 'netif_carrier_off'
>> drivers/net/phy/phy.c:854: undefined reference to 'netif_carrier_on'
>>
>> Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
>> ---
>> arch/powerpc/platforms/82xx/Kconfig | 3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/82xx/Kconfig b/arch/powerpc/
>> platforms/82xx/Kconfig
>> index 7c7df40..36a3e58 100644
>> --- a/arch/powerpc/platforms/82xx/Kconfig
>> +++ b/arch/powerpc/platforms/82xx/Kconfig
>> @@ -31,6 +31,9 @@ config EP8248E
>> select 8260
>> select FSL_SOC
>> select PHYLIB
>> + select NET
>> + select NETDEVICE
>> + select NET_SCHED
>> select MDIO_BITBANG
>> help
>> This enables support for the Embedded Planet EP8248E board.
>
> Why is there a `select PHYLIB' at the platform level? Shouldn't it
> be in
> drivers/net/Kconfig, near the appropriate network driver? That way
> people can
> build kernels without networking support, if they want.
I agree w/you however the initial reason it was:
commit ff21f23648d33649fcf3e1e99d03e245f0e1acf8
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Wed Jul 16 17:47:54 2008 -0500
powerpc/ep8248e: Unconditionally select PHYLIB for mdio_bitbang
Its possible to build the phylib as a module, however this breaks
the
board code because alloc_mdio_bitbang and mdiobus_register are not
available if we build as a module. These are needed by the board
code
since it implements the low level mdio bitbang ops.
So we unconditionally select PHYLIB to ensure its built into the
kernel
if we are building in EP8248E support.
Long term we should look at moving the mdio_ops into its own file
so it
can be built as a module.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
so maybe it should:
select PHYLIB if NET
- k
^ permalink raw reply
* Re: [PATCH] powerpc/ep8248e: phylib needs NET_SCHED to build
From: Geert Uytterhoeven @ 2009-05-20 12:27 UTC (permalink / raw)
To: Alexander Beregalov; +Cc: linuxppc-dev, netdev
In-Reply-To: <1242821902-16836-1-git-send-email-a.beregalov@gmail.com>
On Wed, 20 May 2009, Alexander Beregalov wrote:
> Fix this build error:
> drivers/built-in.o: In function `phy_state_machine':
> drivers/net/phy/phy.c:893: undefined reference to 'netif_carrier_off'
> drivers/net/phy/phy.c:854: undefined reference to 'netif_carrier_on'
>
> Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
> ---
> arch/powerpc/platforms/82xx/Kconfig | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/82xx/Kconfig b/arch/powerpc/platforms/82xx/Kconfig
> index 7c7df40..36a3e58 100644
> --- a/arch/powerpc/platforms/82xx/Kconfig
> +++ b/arch/powerpc/platforms/82xx/Kconfig
> @@ -31,6 +31,9 @@ config EP8248E
> select 8260
> select FSL_SOC
> select PHYLIB
> + select NET
> + select NETDEVICE
> + select NET_SCHED
> select MDIO_BITBANG
> help
> This enables support for the Embedded Planet EP8248E board.
Why is there a `select PHYLIB' at the platform level? Shouldn't it be in
drivers/net/Kconfig, near the appropriate network driver? That way people can
build kernels without networking support, if they want.
With kind regards,
Geert Uytterhoeven
Software Architect
Techsoft Centre
Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* [PATCH] powerpc/ep8248e: phylib needs NET_SCHED to build
From: Alexander Beregalov @ 2009-05-20 12:18 UTC (permalink / raw)
To: galak, linuxppc-dev; +Cc: netdev, Alexander Beregalov
Fix this build error:
drivers/built-in.o: In function `phy_state_machine':
drivers/net/phy/phy.c:893: undefined reference to 'netif_carrier_off'
drivers/net/phy/phy.c:854: undefined reference to 'netif_carrier_on'
Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
---
arch/powerpc/platforms/82xx/Kconfig | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/82xx/Kconfig b/arch/powerpc/platforms/82xx/Kconfig
index 7c7df40..36a3e58 100644
--- a/arch/powerpc/platforms/82xx/Kconfig
+++ b/arch/powerpc/platforms/82xx/Kconfig
@@ -31,6 +31,9 @@ config EP8248E
select 8260
select FSL_SOC
select PHYLIB
+ select NET
+ select NETDEVICE
+ select NET_SCHED
select MDIO_BITBANG
help
This enables support for the Embedded Planet EP8248E board.
--
1.6.2.4
^ permalink raw reply related
* [FTRACE] 2.6.30-rc6-git5 : Badness at kernel/trace/ftrace.c:444
From: Sachin Sant @ 2009-05-20 9:08 UTC (permalink / raw)
To: linuxppc-dev; +Cc: rostedt
[-- Attachment #1: Type: text/plain, Size: 2205 bytes --]
While booting 2.6.30-rc6-git5 kernel came across this badness message.
ftrace: allocating 18134 entries in 107 pages
------------[ cut here ]------------
Badness at kernel/trace/ftrace.c:444
NIP: c00000000011e754 LR: c0000000001210fc CTR: 0000000000000000
REGS: c000000000edba40 TRAP: 0700 Not tainted (2.6.30-rc6-git5)
MSR: 8000000000021032 <ME,CE,IR,DR> CR: 28000082 XER: 00000000
TASK = c000000000e2d650[0] 'swapper' THREAD: c000000000ed8000 CPU: 0
GPR00: 0000000000000001 c000000000edbcc0 c000000000ed8830 ffffffffffffffea
GPR04: c000000000500000 0000000000000004 0000000000000000 0000000000000080
GPR08: 0000000000000000 c000000000fe6c80 f0000000013bc5c0 001bd7a20f0eb79e
GPR12: 0000000048000088 c000000000f1f380 0000000000382400 0000000000000000
GPR16: 0000000001100000 0000000001550a00 0000000001550898 0000000008000000
GPR20: 00000000031cae90 c0000000008f3d88 0000000000000000 c000000000500000
GPR24: 0000000000000000 0000000000000000 0000000004a47270 0000000000000001
GPR28: c000000000fe6c80 c000000000500000 c000000000e670f0 c000000000edbcc0
NIP [c00000000011e754] .ftrace_bug+0x98/0x218
LR [c0000000001210fc] .ftrace_convert_nops+0x20c/0x308
Call Trace:
[c000000000edbcc0] [600000000012bf5c] 0x600000000012bf5c (unreliable)
[c000000000edbd60] [c0000000001210fc] .ftrace_convert_nops+0x20c/0x308
[c000000000edbe30] [c000000000929b8c] .ftrace_init+0x158/0x17c
[c000000000edbee0] [c0000000008fdca4] .start_kernel+0x47c/0x4a8
[c000000000edbf90] [c000000000008408] .start_here_common+0x2c/0xa4
Instruction dump:
41be0010 e93e8010 38000001 90090018 e93e8000 e81e8008 e87e80b0 48000138
8009001c 7c000034 5400d97e 78000020 <0b000000> 2fa00000 41be0010 e93e8010
ftrace failed to modify [<c000000000500000>] .uhci_activate_qh+0x34/0x220
actual: 00:00:10:10
irq: irq 2 on host null mapped to virtual irq 16
Observed similar problem with git4 as well. This doesn't seem to be a
widespread problem
and currently observing this on one out of 3 power6 machines.
Complete dmesg and .config(gzipped) attached.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
[-- Attachment #2: ftrace_dmesg_log --]
[-- Type: text/plain, Size: 16532 bytes --]
Phyp-dump disabled at boot time
Using pSeries machine description
Page orders: linear mapping = 24, virtual = 12, io = 12, vmemmap = 24
Using 1TB segments
Found initrd at 0xc000000001e00000:0xc000000002182400
console [udbg0] enabled
Partition configured for 8 cpus.
CPU maps initialized for 2 threads per core
(thread shift is 1)
Starting Linux PPC64 #1 SMP Wed May 20 11:51:20 IST 2009
-----------------------------------------------------
ppc64_pft_size = 0x1a
physicalMemorySize = 0xa0000000
htab_hash_mask = 0x7ffff
-----------------------------------------------------
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.30-rc6-git5 (root@mjs22lp1) (gcc version 4.4.0 20090307 (Red Hat 4.4.0-0.23) (GCC) ) #1 SMP Wed May 20 11:51:20 IST 2009
[boot]0012 Setup Arch
Node 0 Memory: 0x8000000-0x5c000000
Node 1 Memory: 0x0-0x8000000 0x5c000000-0xa0000000
EEH: No capable adapters found
PPC64 nvram contains 15360 bytes
Using shared processor idle loop
Zone PFN ranges:
DMA 0x00000000 -> 0x000a0000
Normal 0x000a0000 -> 0x000a0000
Movable zone start PFN for each node
early_node_map[3] active PFN ranges
1: 0x00000000 -> 0x00008000
0: 0x00008000 -> 0x0005c000
1: 0x0005c000 -> 0x000a0000
On node 0 totalpages: 344064
DMA zone: 4704 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 339360 pages, LIFO batch:31
On node 1 totalpages: 311296
DMA zone: 8960 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 302336 pages, LIFO batch:31
[boot]0015 Setup Done
Built 2 zonelists in Node order, mobility grouping on. Total pages: 641696
Policy zone: DMA
Kernel command line: ro console=hvc0 rhgb quiet root=UUID=9448b379-7842-486c-8bc8-22a1427c4462
NR_IRQS:512
[boot]0020 XICS Init
[boot]0021 XICS Done
pic: no ISA interrupt controller
PID hash table entries: 4096 (order: 12, 32768 bytes)
time_init: decrementer frequency = 512.000000 MHz
time_init: processor frequency = 4005.000000 MHz
clocksource: timebase mult[7d0000] shift[22] registered
clockevent: decrementer mult[8312] shift[16] cpu[0]
Console: colour dummy device 80x25
console handover: boot [udbg0] -> real [hvc0]
allocated 26214400 bytes of page_cgroup
please try cgroup_disable=memory option if you don't want
freeing bootmem node 0
freeing bootmem node 1
Memory: 2514952k/2621440k available (14120k kernel code, 137064k reserved, 1076k data, 1310k bss, 4916k init)
SLUB: Genslabs=14, HWalign=128, Order=0-3, MinObjects=0, CPUs=8, Nodes=16
Calibrating delay loop... 1021.95 BogoMIPS (lpj=510976)
Security Framework initialized
SELinux: Initializing.
SELinux: Starting in permissive mode
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Mount-cache hash table entries: 256
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
Initializing cgroup subsys net_cls
ftrace: allocating 18134 entries in 107 pages
------------[ cut here ]------------
Badness at kernel/trace/ftrace.c:444
NIP: c00000000011e754 LR: c0000000001210fc CTR: 0000000000000000
REGS: c000000000edba40 TRAP: 0700 Not tainted (2.6.30-rc6-git5)
MSR: 8000000000021032 <ME,CE,IR,DR> CR: 28000082 XER: 00000000
TASK = c000000000e2d650[0] 'swapper' THREAD: c000000000ed8000 CPU: 0
GPR00: 0000000000000001 c000000000edbcc0 c000000000ed8830 ffffffffffffffea
GPR04: c000000000500000 0000000000000004 0000000000000000 0000000000000080
GPR08: 0000000000000000 c000000000fe6c80 f0000000013bc5c0 001bd7a20f0eb79e
GPR12: 0000000048000088 c000000000f1f380 0000000000382400 0000000000000000
GPR16: 0000000001100000 0000000001550a00 0000000001550898 0000000008000000
GPR20: 00000000031cae90 c0000000008f3d88 0000000000000000 c000000000500000
GPR24: 0000000000000000 0000000000000000 0000000004a47270 0000000000000001
GPR28: c000000000fe6c80 c000000000500000 c000000000e670f0 c000000000edbcc0
NIP [c00000000011e754] .ftrace_bug+0x98/0x218
LR [c0000000001210fc] .ftrace_convert_nops+0x20c/0x308
Call Trace:
[c000000000edbcc0] [600000000012bf5c] 0x600000000012bf5c (unreliable)
[c000000000edbd60] [c0000000001210fc] .ftrace_convert_nops+0x20c/0x308
[c000000000edbe30] [c000000000929b8c] .ftrace_init+0x158/0x17c
[c000000000edbee0] [c0000000008fdca4] .start_kernel+0x47c/0x4a8
[c000000000edbf90] [c000000000008408] .start_here_common+0x2c/0xa4
Instruction dump:
41be0010 e93e8010 38000001 90090018 e93e8000 e81e8008 e87e80b0 48000138
8009001c 7c000034 5400d97e 78000020 <0b000000> 2fa00000 41be0010 e93e8010
ftrace failed to modify [<c000000000500000>] .uhci_activate_qh+0x34/0x220
actual: 00:00:10:10
irq: irq 2 on host null mapped to virtual irq 16
clockevent: decrementer mult[8312] shift[16] cpu[1]
Processor 1 found.
clockevent: decrementer mult[8312] shift[16] cpu[2]
Processor 2 found.
clockevent: decrementer mult[8312] shift[16] cpu[3]
Processor 3 found.
clockevent: decrementer mult[8312] shift[16] cpu[4]
Processor 4 found.
clockevent: decrementer mult[8312] shift[16] cpu[5]
Processor 5 found.
clockevent: decrementer mult[8312] shift[16] cpu[6]
Processor 6 found.
clockevent: decrementer mult[8312] shift[16] cpu[7]
Processor 7 found.
Brought up 8 CPUs
Node 0 CPUs: 0-7
Node 1 CPUs:
CPU0 attaching sched-domain:
domain 0: span 0-1 level SIBLING
groups: 0 1
domain 1: span 0-7 level CPU
groups: 0-1 2-3 4-5 6-7
domain 2: span 0-7 level NODE
groups: 0-7 (__cpu_power = 4096)
CPU1 attaching sched-domain:
domain 0: span 0-1 level SIBLING
groups: 1 0
domain 1: span 0-7 level CPU
groups: 0-1 2-3 4-5 6-7
domain 2: span 0-7 level NODE
groups: 0-7 (__cpu_power = 4096)
CPU2 attaching sched-domain:
domain 0: span 2-3 level SIBLING
groups: 2 3
domain 1: span 0-7 level CPU
groups: 2-3 4-5 6-7 0-1
domain 2: span 0-7 level NODE
groups: 0-7 (__cpu_power = 4096)
CPU3 attaching sched-domain:
domain 0: span 2-3 level SIBLING
groups: 3 2
domain 1: span 0-7 level CPU
groups: 2-3 4-5 6-7 0-1
domain 2: span 0-7 level NODE
groups: 0-7 (__cpu_power = 4096)
CPU4 attaching sched-domain:
domain 0: span 4-5 level SIBLING
groups: 4 5
domain 1: span 0-7 level CPU
groups: 4-5 6-7 0-1 2-3
domain 2: span 0-7 level NODE
groups: 0-7 (__cpu_power = 4096)
CPU5 attaching sched-domain:
domain 0: span 4-5 level SIBLING
groups: 5 4
domain 1: span 0-7 level CPU
groups: 4-5 6-7 0-1 2-3
domain 2: span 0-7 level NODE
groups: 0-7 (__cpu_power = 4096)
CPU6 attaching sched-domain:
domain 0: span 6-7 level SIBLING
groups: 6 7
domain 1: span 0-7 level CPU
groups: 6-7 0-1 2-3 4-5
domain 2: span 0-7 level NODE
groups: 0-7 (__cpu_power = 4096)
CPU7 attaching sched-domain:
domain 0: span 6-7 level SIBLING
groups: 7 6
domain 1: span 0-7 level CPU
groups: 6-7 0-1 2-3 4-5
domain 2: span 0-7 level NODE
groups: 0-7 (__cpu_power = 4096)
net_namespace: 1952 bytes
regulator: core version 0.5
NET: Registered protocol family 16
IBM eBus Device Driver
PCI: Probing PCI hardware
PCI: Probing PCI hardware done
bio: create slab <bio-0> at 0
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NetLabel: Initializing
NetLabel: domain hash size = 128
NetLabel: protocols = UNLABELED CIPSOv4
NetLabel: unlabeled traffic allowed by default
NET: Registered protocol family 2
Switched to high resolution mode on CPU 0
Switched to high resolution mode on CPU 3
Switched to high resolution mode on CPU 4
Switched to high resolution mode on CPU 5
Switched to high resolution mode on CPU 1
Switched to high resolution mode on CPU 6
Switched to high resolution mode on CPU 2
Switched to high resolution mode on CPU 7
IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 524288 bind 65536)
TCP reno registered
NET: Registered protocol family 1
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 3593k freed
irq: irq 655360 on host null mapped to virtual irq 17
irq: irq 655362 on host null mapped to virtual irq 18
IOMMU table initialized, virtual merging enabled
irq: irq 655364 on host null mapped to virtual irq 19
irq: irq 655365 on host null mapped to virtual irq 20
irq: irq 589825 on host null mapped to virtual irq 21
RTAS daemon started
audit: initializing netlink socket (disabled)
type=2000 audit(1242803832.218:1): initialized
RTAS: event: 20, Type: Platform Error, Severity: 2
HugeTLB registered 16 MB page size, pre-allocated 0 pages
HugeTLB registered 16 GB page size, pre-allocated 0 pages
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
msgmni has been set to 4919
SELinux: Registering netfilter hooks
alg: No test for stdrng (krng)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: PCI Express Hot Plug Controller Driver version: 0.4
vio_register_driver: driver hvc_console registering
HVSI: registered 0 devices
Linux agpgart interface v0.103
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
TX39/49 Serial driver version 1.11
brd: module loaded
loop: module loaded
input: Macintosh mouse button emulation as /devices/virtual/input/input0
Uniform Multi-Platform E-IDE driver
ide-gd driver 1.18
Driver 'sd' needs updating - please use bus_type methods
Driver 'sr' needs updating - please use bus_type methods
Fixed MDIO Bus: probed
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
uhci_hcd: USB Universal Host Controller Interface driver
mice: PS/2 mouse device common for all mice
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
nf_conntrack.acct=1 kernel paramater, acct=1 nf_conntrack module option or
sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 17
Running MSI bitmap self-tests ...
PM: Resume from disk failed.
registered taskstats version 1
Initalizing network drop monitor service
Freeing unused kernel memory: 4916k freed
vio_register_driver: driver ibmvscsi registering
ibmvscsi 30000002: SRP_VERSION: 16.a
scsi0 : IBM POWER Virtual SCSI Adapter 1.5.8
ibmvscsi 30000002: partner initialization complete
ibmvscsi 30000002: sent SRP login
ibmvscsi 30000002: SRP_LOGIN succeeded
ibmvscsi 30000002: host srp version: 16.a, host partition 06-1C12A (1), OS 3, max io 1048576
scsi 0:0:1:0: Direct-Access AIX VDASD 0001 PQ: 0 ANSI: 3
scsi 0:0:2:0: CD-ROM AIX VOPTA PQ: 0 ANSI: 4
scsi: waiting for bus probes to complete ...
sd 0:0:1:0: Attached scsi generic sg0 type 0
sd 0:0:1:0: [sda] 147324928 512-byte hardware sectors: (75.4 GB/70.2 GiB)
sd 0:0:1:0: [sda] Write Protect is off
sd 0:0:1:0: [sda] Mode Sense: 17 00 00 08
sd 0:0:1:0: [sda] Cache data unavailable
sd 0:0:1:0: [sda] Assuming drive cache: write through
sr0: scsi-1 drive
Uniform CD-ROM driver Revision: 3.20
sd 0:0:1:0: [sda] Cache data unavailable
sd 0:0:1:0: [sda] Assuming drive cache: write through
sda:<7>sr 0:0:2:0: Attached scsi CD-ROM sr0
sr 0:0:2:0: Attached scsi generic sg1 type 5
sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 >
sd 0:0:1:0: [sda] Attached SCSI disk
EXT4-fs: barriers enabled
kjournald2 starting: pid 129, dev sda3:8, commit interval 5 seconds
EXT4-fs: delayed allocation enabled
EXT4-fs: file extents enabled
EXT4-fs: mballoc enabled
EXT4-fs: mounted filesystem sda3 with ordered data mode
type=1404 audit(1242803833.068:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
SELinux: 8192 avtab hash slots, 117789 rules.
SELinux: 8192 avtab hash slots, 117789 rules.
SELinux: 8 users, 13 roles, 2653 types, 121 bools, 1 sens, 1024 cats
SELinux: 74 classes, 117789 rules
SELinux: Completing initialization.
SELinux: Setting up existing superblocks.
SELinux: initialized (dev sda3, type ext4), uses xattr
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts
SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs
SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses genfs_contexts
SELinux: initialized (dev devpts, type devpts), uses transition SIDs
SELinux: initialized (dev inotifyfs, type inotifyfs), uses genfs_contexts
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
SELinux: initialized (dev anon_inodefs, type anon_inodefs), uses genfs_contexts
SELinux: initialized (dev pipefs, type pipefs), uses task SIDs
SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts
SELinux: initialized (dev sockfs, type sockfs), uses task SIDs
SELinux: initialized (dev proc, type proc), uses genfs_contexts
SELinux: initialized (dev bdev, type bdev), uses genfs_contexts
SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts
SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
type=1403 audit(1242803833.425:3): policy loaded auid=4294967295 ses=4294967295
SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts
udev: starting version 139
drivers/net/ibmveth.c: ibmveth: IBM i/pSeries Virtual Ethernet Driver 1.03
vio_register_driver: driver ibmveth registering
eth0 (ibmveth): not using net_device_ops yet
eth1 (ibmveth): not using net_device_ops yet
IBM eHEA ethernet device driver (Release EHEA_0101)
irq: irq 590080 on host null mapped to virtual irq 256
ehea: eth0: Jumbo frames are enabled
ehea: eth0 -> logical port id #3
ehea: eth2: Jumbo frames are enabled
ehea: eth2 -> logical port id #4
udev: renamed network interface eth1 to eth3
udev: renamed network interface eth0_rename to eth1
device-mapper: multipath: version 1.0.5 loaded
EXT4 FS on sda3, internal journal on sda3:8
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda2, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
SELinux: initialized (dev sda2, type ext3), uses xattr
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
Adding 3068372k swap on /dev/sda8. Priority:-1 extents:1 across:3068372k
SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses genfs_contexts
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts
Bluetooth: Core ver 2.15
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.13
Bluetooth: L2CAP socket layer initialized
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Bridge firewalling registered
Bluetooth: SCO (Voice Link) ver 0.6
Bluetooth: SCO socket layer initialized
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
SELinux: initialized (dev nfsd, type nfsd), uses genfs_contexts
NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
NFSD: starting 90-second grace period
virbr0: starting userspace STP failed, starting kernel STP
SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs
SELinux: initialized (dev proc, type proc), uses genfs_contexts
SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs
lo: Disabled Privacy Extensions
SELinux: initialized (dev proc, type proc), uses genfs_contexts
eth3: no IPv6 routers present
eth1: no IPv6 routers present
virbr0: no IPv6 routers present
ehea: eth0: Physical port up
ehea: External switch port is backup port
irq: irq 777 on host null mapped to virtual irq 265
irq: irq 778 on host null mapped to virtual irq 266
eth0: no IPv6 routers present
[-- Attachment #3: config_ftrace.gz --]
[-- Type: application/x-gzip, Size: 23592 bytes --]
^ permalink raw reply
* AMCC 405ex memory size issue
From: konamo @ 2009-05-20 8:55 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
we are using u-boot 2009.01, linux-2.6.25-rc2, 1GB DDR2 memory(2Gbit * 4,
1 rank), AMCC powerpc 405ex, both 1G and 512MB memory works fine under
u-boot, but linux boot fails in 1G memory, if we limit mem=512M, linux could
boot. Could anyone pls help us how to find the root cause? thanks
--
View this message in context: http://www.nabble.com/AMCC-405ex-memory-size-issue-tp23631525p23631525.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] powerpc/pcm030.dts: add i2c eeprom and delete cruft
From: Wolfram Sang @ 2009-05-20 8:07 UTC (permalink / raw)
To: w.sang; +Cc: linuxppc-dev
Add a node for the i2c eeprom and delete the superflous gpio-example.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: linuxppc-dev@ozlabs.org
---
arch/powerpc/boot/dts/pcm030.dts | 26 ++++----------------------
1 files changed, 4 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/boot/dts/pcm030.dts b/arch/powerpc/boot/dts/pcm030.dts
index 8958347..33ce488 100644
--- a/arch/powerpc/boot/dts/pcm030.dts
+++ b/arch/powerpc/boot/dts/pcm030.dts
@@ -258,34 +258,16 @@
compatible = "nxp,pcf8563";
reg = <0x51>;
};
- /* FIXME: EEPROM */
+ eeprom@52 {
+ compatible = "at24,24c32";
+ reg = <0x52>;
+ };
};
sram@8000 {
compatible = "fsl,mpc5200b-sram","fsl,mpc5200-sram";
reg = <0x8000 0x4000>;
};
-
- /* This is only an example device to show the usage of gpios. It maps all available
- * gpios to the "gpio-provider" device.
- */
- gpio {
- compatible = "gpio-provider";
-
- /* mpc52xx exp.con patchfield */
- gpios = <&gpio_wkup 0 0 /* GPIO_WKUP_7 11d jp13-3 */
- &gpio_wkup 1 0 /* GPIO_WKUP_6 14c */
- &gpio_wkup 6 0 /* PSC2_4 43c x5-11 */
- &gpio_simple 2 0 /* IRDA_1 24c x7-6 set GPS_PORT_CONFIG[IRDA] = 0 */
- &gpio_simple 3 0 /* IRDA_0 x8-5 set GPS_PORT_CONFIG[IRDA] = 0 */
- &gpt2 0 0 /* timer2 12d x4-4 */
- &gpt3 0 0 /* timer3 13d x6-4 */
- &gpt4 0 0 /* timer4 61c x2-16 */
- &gpt5 0 0 /* timer5 44c x7-11 */
- &gpt6 0 0 /* timer6 60c x8-15 */
- &gpt7 0 0 /* timer7 36a x17-9 */
- >;
- };
};
pci@f0000d00 {
--
1.6.2
^ permalink raw reply related
* Re: [PATCH] powerpc/5200: beyond ARRAY_SIZE of mpc52xx_uart_{ports, nodes}
From: Wolfram Sang @ 2009-05-20 7:11 UTC (permalink / raw)
To: Roel Kluin; +Cc: linuxppc-dev, Andrew Morton
In-Reply-To: <4A134EC4.3000805@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]
On Wed, May 20, 2009 at 02:28:52AM +0200, Roel Kluin wrote:
> Do not go beyond ARRAY_SIZE of mpc52xx_uart_{ports,nodes}
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
> ---
> diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
> index 7f72f8c..b3feb61 100644
> --- a/drivers/serial/mpc52xx_uart.c
> +++ b/drivers/serial/mpc52xx_uart.c
> @@ -988,7 +988,7 @@ mpc52xx_console_setup(struct console *co, char *options)
> pr_debug("mpc52xx_console_setup co=%p, co->index=%i, options=%s\n",
> co, co->index, options);
>
> - if ((co->index < 0) || (co->index > MPC52xx_PSC_MAXNUM)) {
> + if ((co->index < 0) || (co->index >= MPC52xx_PSC_MAXNUM)) {
> pr_debug("PSC%x out of range\n", co->index);
> return -EINVAL;
> }
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH] powerpc/pci: Pull ppc32 code we need in ppc64
From: Benjamin Herrenschmidt @ 2009-05-20 7:08 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <A254D12F-2709-48BB-8E7B-2F82D45D1372@kernel.crashing.org>
On Wed, 2009-05-20 at 00:57 -0500, Kumar Gala wrote:
> Ben,
>
> Comments on the pmac case?
Not yet :-) Give me a day. Was tracking a bug today.
Cheers,
Ben.
> - k
>
> On Apr 29, 2009, at 3:49 PM, Kumar Gala wrote:
>
> > Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> > ---
> >
> > Ben,
> >
> > My question is if we think fake_pci_bus will always get a valid
> > hose().
> > The users of EARLY_PCI_OP are fsl/8xxx, 4xx, and pmac. I verified
> > that
> > fsl/8xxx & 4xx pass a valid hose. Do we think pmac does?
> >
> > - k
> >
> > arch/powerpc/include/asm/machdep.h | 6 +-
> > arch/powerpc/include/asm/pci-bridge.h | 35 +++++++---------
> > arch/powerpc/kernel/pci-common.c | 70 ++++++++++++++++++++++++
> > ++++++++
> > arch/powerpc/kernel/pci_32.c | 71
> > ---------------------------------
> > 4 files changed, 89 insertions(+), 93 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/
> > include/asm/machdep.h
> > index 0efdb1d..1b389ff 100644
> > --- a/arch/powerpc/include/asm/machdep.h
> > +++ b/arch/powerpc/include/asm/machdep.h
> > @@ -205,14 +205,14 @@ struct machdep_calls {
> > /*
> > * optional PCI "hooks"
> > */
> > - /* Called in indirect_* to avoid touching devices */
> > - int (*pci_exclude_device)(struct pci_controller *, unsigned char,
> > unsigned char);
> > -
> > /* Called at then very end of pcibios_init() */
> > void (*pcibios_after_init)(void);
> >
> > #endif /* CONFIG_PPC32 */
> >
> > + /* Called in indirect_* to avoid touching devices */
> > + int (*pci_exclude_device)(struct pci_controller *, unsigned char,
> > unsigned char);
> > +
> > /* Called after PPC generic resource fixup to perform
> > machine specific fixups */
> > void (*pcibios_fixup_resources)(struct pci_dev *);
> > diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/
> > include/asm/pci-bridge.h
> > index 48f58aa..8b371df 100644
> > --- a/arch/powerpc/include/asm/pci-bridge.h
> > +++ b/arch/powerpc/include/asm/pci-bridge.h
> > @@ -77,9 +77,7 @@ struct pci_controller {
> >
> > int first_busno;
> > int last_busno;
> > -#ifndef CONFIG_PPC64
> > int self_busno;
> > -#endif
> >
> > void __iomem *io_base_virt;
> > #ifdef CONFIG_PPC64
> > @@ -104,7 +102,6 @@ struct pci_controller {
> > unsigned int __iomem *cfg_addr;
> > void __iomem *cfg_data;
> >
> > -#ifndef CONFIG_PPC64
> > /*
> > * Used for variants of PCI indirect handling and possible quirks:
> > * SET_CFG_TYPE - used on 4xx or any PHB that does explicit type0/1
> > @@ -128,7 +125,6 @@ struct pci_controller {
> > #define PPC_INDIRECT_TYPE_BIG_ENDIAN 0x00000010
> > #define PPC_INDIRECT_TYPE_BROKEN_MRM 0x00000020
> > u32 indirect_type;
> > -#endif /* !CONFIG_PPC64 */
> > /* Currently, we limit ourselves to 1 IO range and 3 mem
> > * ranges since the common pci_bus structure can't handle more
> > */
> > @@ -146,21 +142,6 @@ struct pci_controller {
> > #endif /* CONFIG_PPC64 */
> > };
> >
> > -#ifndef CONFIG_PPC64
> > -
> > -static inline struct pci_controller *pci_bus_to_host(const struct
> > pci_bus *bus)
> > -{
> > - return bus->sysdata;
> > -}
> > -
> > -static inline int isa_vaddr_is_ioport(void __iomem *address)
> > -{
> > - /* No specific ISA handling on ppc32 at this stage, it
> > - * all goes through PCI
> > - */
> > - return 0;
> > -}
> > -
> > /* These are used for config access before all the PCI probing
> > has been done. */
> > extern int early_read_config_byte(struct pci_controller *hose, int
> > bus,
> > @@ -182,6 +163,22 @@ extern int early_find_capability(struct
> > pci_controller *hose, int bus,
> > extern void setup_indirect_pci(struct pci_controller* hose,
> > resource_size_t cfg_addr,
> > resource_size_t cfg_data, u32 flags);
> > +
> > +#ifndef CONFIG_PPC64
> > +
> > +static inline struct pci_controller *pci_bus_to_host(const struct
> > pci_bus *bus)
> > +{
> > + return bus->sysdata;
> > +}
> > +
> > +static inline int isa_vaddr_is_ioport(void __iomem *address)
> > +{
> > + /* No specific ISA handling on ppc32 at this stage, it
> > + * all goes through PCI
> > + */
> > + return 0;
> > +}
> > +
> > #else /* CONFIG_PPC64 */
> >
> > /*
> > diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/
> > pci-common.c
> > index 9c69e7e..cae4ee1 100644
> > --- a/arch/powerpc/kernel/pci-common.c
> > +++ b/arch/powerpc/kernel/pci-common.c
> > @@ -1620,3 +1620,73 @@ void __devinit
> > pcibios_setup_phb_resources(struct pci_controller *hose)
> >
> > }
> >
> > +/*
> > + * Null PCI config access functions, for the case when we can't
> > + * find a hose.
> > + */
> > +#define NULL_PCI_OP(rw, size, type) \
> > +static int \
> > +null_##rw##_config_##size(struct pci_dev *dev, int offset, type
> > val) \
> > +{ \
> > + return PCIBIOS_DEVICE_NOT_FOUND; \
> > +}
> > +
> > +static int
> > +null_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
> > + int len, u32 *val)
> > +{
> > + return PCIBIOS_DEVICE_NOT_FOUND;
> > +}
> > +
> > +static int
> > +null_write_config(struct pci_bus *bus, unsigned int devfn, int
> > offset,
> > + int len, u32 val)
> > +{
> > + return PCIBIOS_DEVICE_NOT_FOUND;
> > +}
> > +
> > +static struct pci_ops null_pci_ops =
> > +{
> > + .read = null_read_config,
> > + .write = null_write_config,
> > +};
> > +
> > +/*
> > + * These functions are used early on before PCI scanning is done
> > + * and all of the pci_dev and pci_bus structures have been created.
> > + */
> > +static struct pci_bus *
> > +fake_pci_bus(struct pci_controller *hose, int busnr)
> > +{
> > + static struct pci_bus bus;
> > +
> > + if (hose == 0) {
> > + printk(KERN_ERR "Can't find hose for PCI bus %d!\n", busnr);
> > + }
> > + bus.number = busnr;
> > + bus.sysdata = hose;
> > + bus.ops = hose? hose->ops: &null_pci_ops;
> > + return &bus;
> > +}
> > +
> > +#define EARLY_PCI_OP(rw, size, type) \
> > +int early_##rw##_config_##size(struct pci_controller *hose, int
> > bus, \
> > + int devfn, int offset, type value) \
> > +{ \
> > + return pci_bus_##rw##_config_##size(fake_pci_bus(hose, bus), \
> > + devfn, offset, value); \
> > +}
> > +
> > +EARLY_PCI_OP(read, byte, u8 *)
> > +EARLY_PCI_OP(read, word, u16 *)
> > +EARLY_PCI_OP(read, dword, u32 *)
> > +EARLY_PCI_OP(write, byte, u8)
> > +EARLY_PCI_OP(write, word, u16)
> > +EARLY_PCI_OP(write, dword, u32)
> > +
> > +extern int pci_bus_find_capability (struct pci_bus *bus, unsigned
> > int devfn, int cap);
> > +int early_find_capability(struct pci_controller *hose, int bus, int
> > devfn,
> > + int cap)
> > +{
> > + return pci_bus_find_capability(fake_pci_bus(hose, bus), devfn, cap);
> > +}
> > diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/
> > pci_32.c
> > index d473634..32fbadb 100644
> > --- a/arch/powerpc/kernel/pci_32.c
> > +++ b/arch/powerpc/kernel/pci_32.c
> > @@ -497,75 +497,4 @@ long sys_pciconfig_iobase(long which, unsigned
> > long bus, unsigned long devfn)
> > return result;
> > }
> >
> > -/*
> > - * Null PCI config access functions, for the case when we can't
> > - * find a hose.
> > - */
> > -#define NULL_PCI_OP(rw, size, type) \
> > -static int \
> > -null_##rw##_config_##size(struct pci_dev *dev, int offset, type
> > val) \
> > -{ \
> > - return PCIBIOS_DEVICE_NOT_FOUND; \
> > -}
> > -
> > -static int
> > -null_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
> > - int len, u32 *val)
> > -{
> > - return PCIBIOS_DEVICE_NOT_FOUND;
> > -}
> > -
> > -static int
> > -null_write_config(struct pci_bus *bus, unsigned int devfn, int
> > offset,
> > - int len, u32 val)
> > -{
> > - return PCIBIOS_DEVICE_NOT_FOUND;
> > -}
> > -
> > -static struct pci_ops null_pci_ops =
> > -{
> > - .read = null_read_config,
> > - .write = null_write_config,
> > -};
> >
> > -/*
> > - * These functions are used early on before PCI scanning is done
> > - * and all of the pci_dev and pci_bus structures have been created.
> > - */
> > -static struct pci_bus *
> > -fake_pci_bus(struct pci_controller *hose, int busnr)
> > -{
> > - static struct pci_bus bus;
> > -
> > - if (hose == 0) {
> > - hose = pci_bus_to_hose(busnr);
> > - if (hose == 0)
> > - printk(KERN_ERR "Can't find hose for PCI bus %d!\n", busnr);
> > - }
> > - bus.number = busnr;
> > - bus.sysdata = hose;
> > - bus.ops = hose? hose->ops: &null_pci_ops;
> > - return &bus;
> > -}
> > -
> > -#define EARLY_PCI_OP(rw, size, type) \
> > -int early_##rw##_config_##size(struct pci_controller *hose, int
> > bus, \
> > - int devfn, int offset, type value) \
> > -{ \
> > - return pci_bus_##rw##_config_##size(fake_pci_bus(hose, bus), \
> > - devfn, offset, value); \
> > -}
> > -
> > -EARLY_PCI_OP(read, byte, u8 *)
> > -EARLY_PCI_OP(read, word, u16 *)
> > -EARLY_PCI_OP(read, dword, u32 *)
> > -EARLY_PCI_OP(write, byte, u8)
> > -EARLY_PCI_OP(write, word, u16)
> > -EARLY_PCI_OP(write, dword, u32)
> > -
> > -extern int pci_bus_find_capability (struct pci_bus *bus, unsigned
> > int devfn, int cap);
> > -int early_find_capability(struct pci_controller *hose, int bus, int
> > devfn,
> > - int cap)
> > -{
> > - return pci_bus_find_capability(fake_pci_bus(hose, bus), devfn, cap);
> > -}
> > --
> > 1.6.0.6
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Musings on PCI busses
From: Benjamin Herrenschmidt @ 2009-05-20 6:51 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, thunderbird2k, John.Linn
In-Reply-To: <20090519.225118.58497608.davem@davemloft.net>
On Tue, 2009-05-19 at 22:51 -0700, David Miller wrote:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Wed, 20 May 2009 13:01:30 +1000
>
> > For example, some of the OF parsing bits may fail to convert memory
> > addresses to IO addresses if the PCI host bridges have not been
> > discovered yet, potentially causing issues with matching of resources
> > between the early serial stuff and the generic serial driver (if you
> > use an IO driven UART, the PCI 8250 driver may not properly figure out
> > that what it's finding in its IO BARs is actually the same port as
> > what it gets from the platform code as the later will end up with
> > memory addresses rather than IO ones). That's one example.
>
> FWIW, I never run into this issue on sparc64 exactly because I
> fully resolve all resources when I populate the OF device tree
> in the kernel.
What do you mean by fully resolve ? IE. The issue above is specific to
IO space, which you can resolve both as MMIO, or as "IO" which in linux
means going through the special mapping for IO which allows the use of
the inX/outX instructions...
The later can only be done after we have established the special mapping
in question for a given PCI bus IO space, at which point, we know what
IO "base" corresponds to the IO space of that bridge. So in the
meantime, all we have is an MMIO resource, which is "resolved" in the
sense that it does contain all the right bits to get the serial ports
(address translation etc...) but isn't an IORESOURCE_IO type resource
and thus doesn't contain a magic token we can pass to inX/outX.
One of the issues we may have here on powerpc is that our very early
probe of serial ports (so we get some debug output early) may get to
those resources while the serial driver later sees the actual
IORESOURCE_IO resources coming from the PCI probe, and is unable to
figure that they are the same things.
Currently, we do a pass of "conversion" over those early resolved
resources just after the PCI bridges have been discovered to check if
they happen to land into the IO space of a bridge and then turn them
into IORESOURCE_IO tokens.
If we delay the probing of PCI bridges, things can get fishy there.
Cheers,
Ben.
^ permalink raw reply
* Re: RapidIO - general questions
From: Jan Neskudla @ 2009-05-20 7:00 UTC (permalink / raw)
To: ext Li Yang; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <2a27d3730905150056m7298b66ckb9db92f9432953d6@mail.gmail.com>
n Fri, 2009-05-15 at 15:56 +0800, ext Li Yang wrote:
> On Fri, May 15, 2009 at 3:33 PM, Jan Neskudla <jan.neskudla.ext@nsn.com> wrote:
> > On Wed, 2009-05-13 at 18:57 +0800, ext Li Yang wrote:
> >> cc'ed LKML
> >>
> >> On Tue, May 12, 2009 at 5:17 PM, Jan Neskudla <jan.neskudla.ext@nsn.com> wrote:
> >> > Hallo
> >> >
> >> > we'd likes to use a RapidIO as a general communication bus on our new
> >> > product, and so I have some questions about general design of Linux RIO
> >> > subsystem. I did not find any better mailing list for RapidIO
> >> > discussion.
> >> >
> >> > [1] - we'd like to implement following features
> >> > * Hot-plug (hot-insert/hot-remove) of devices
> >> > * Error handling (port-write packets - configuration, handling of
> >> > them)
> >> > * Static ID configuration based on port numbers
> >> > * Aux driver - basic driver, for sending messages over different
> >> > mboxes, handling ranges of doorbells
> >> >
> >> > Is it here anyone who is working on any improvement, or anyone who
> >> > knows the development plans for RapidIO subsystem?
> >> >
> >>
> >> AFAIK, there is no one currently working on these features for Linux.
> >> It will be good if you can add these useful features.
> > Yes it looks like that, currently we are analyzing current rapidIO
> > system, and how we can add these features.
> >
> >>
> >> > [2] - I have a following problem with a current implementation of
> >> > loading drivers. The driver probe-function call is based on comparison
> >> > of VendorID (VID) and DeviceID (DID) only. Thus if I have 3 devices with
> >> > same DID and VID connected to the same network (bus), the driver is
> >> > loaded 3times, instead only once for the actual device Master port.
> >>
> >> This should be the correct way as you actually have 3 instances of the device.
> >>
> >> >
> >> > Rionet driver solved this by enabling to call initialization function
> >> > just once, and it expect that this is the Master port.
> >>
> >> Rionet is kind of special. It's not working like a simple device
> >> driver, but more like a customized protocol stack to support multiple
> >> ethernet over rio links.
> >>
> >> >
> >> > Is it this correct behavior ? It looks to me that RapidIO is handled
> >> > like a local bus (like PCI)
> >>
> >> This is correct behavior. All of them are using Linux device/driver
> >> infrastructure, but rionet is a special device.
> >
> > But I do not have a 3 devices on one silicon. I am talking about 3
> > devices (3 x EP8548 boards + IDT switch) connected over rapidIO through
> > the switch. And in this case I'd like to have only one driver siting on
> > the top of Linux RapidIO subsystem. I don't see the advantage of loading
>
> You are having one driver, but it probes 3 times for each device using
> the driver.
>
> > a driver locally for remote device. Am I missing something ?
>
> If you want to interact with the remote device, you need the driver to
> do the work locally.
We are going to use a RapidIO as a bigger network of active devices, and
each will have each own driver (sitting on its own), and all the
settings will be done over maintenance packets.
May be it will be solved by the fact, that we are going to use a
staticIDs, so there will be no discovery as it is now. And thus there
will be only one device visible in the internal structures of the
subsystem, and thus only one drive will be loaded.
>
> >
> > And one more think, I am getting so much Bus errors OOPSes. Whenever
> > there is a problem with a comunication over Rio I get such a kernel OPS.
> > I had to add some delays into some function to be able to finish the
> > enum+discovery process. Did you have some experience with some bigger
> > rio network running under linux ?
>
> It looks like an known issue for switched rio network, but I don't
> have the correct equipment to reproduce the problem here. Could you
> do some basic debugging and share your findings? Thanks.
I tried to acquired some info about the problem, I found that the OOPS
always occur when there is no respond from the device or the respond is
too slow. I always got that error during function call
rio_get_host_deviceid_lock when it tries to access a remote device or
switch. This function is the first call of the rio_mport_read_config_32
so is also first try of remote access to any device.
It is a timing issue, and after placing a printk into the
rio_get_host_deviceid_lock the OOPSing almost disappeared.
Jan
>
> - Leo
^ permalink raw reply
* Re: mpc5200 fec error
From: Wolfram Sang @ 2009-05-20 6:42 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Eric Millbrandt
In-Reply-To: <fa686aa40905191636u6f4a23d0xc8c6c13904a65b8e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2339 bytes --]
> > I am able to reproduce the error using 2.6.29.2-rt11. I was able to
> > mitigate the problem by raising the priority of the transmit irq.
> > However when running an NFS server on the pcm030 under high cpu load I
> > now get
> >
> > [ 132.477503] net eth0: FEC_IEVENT_RFIFO_ERROR
> > [ 132.892329] net eth0: FEC_IEVENT_RFIFO_ERROR
> > [ 133.884109] net eth0: FEC_IEVENT_RFIFO_ERROR
> > [ 134.876059] net eth0: FEC_IEVENT_RFIFO_ERROR
> >
> > Raising the priority of the rx irq does not seem to fix this problem
> > though.
>
> Hi Eric,
>
> This error has been seen before in non-rt kernels. I haven't had the
> chance to track it down and kill it yet. I believe there are locking
> issues associated with it.
Uuuh, I recall this message. Kept me busy for some time :(
You might try this patch which helped in our situation.
===========
Subject: Enable XLB pipelining for MPC5200B
From: Wolfram Sang <w.sang@pengutronix.de>
Enable pipelining as it helps getting rid of FEC problems.
Not intended for upstream, this must be dealt differently there.
This patch is disabled by default. The bootloader should enable this feature.
So, this patch is only intended to be used where the bootloader does it in a
wrong manner and can't be replaced.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: Juergen Beisert <j.beisert@pengutronix.de>
---
arch/powerpc/platforms/52xx/mpc52xx_common.c | 7 +++++++
1 file changed, 7 insertions(+)
Index: arch/powerpc/platforms/52xx/mpc52xx_common.c
===================================================================
--- arch/powerpc/platforms/52xx/mpc52xx_common.c.orig
+++ arch/powerpc/platforms/52xx/mpc52xx_common.c
@@ -107,6 +107,13 @@ mpc5200_setup_xlb_arbiter(void)
*/
if ((mfspr(SPRN_SVR) & MPC5200_SVR_MASK) == MPC5200_SVR)
out_be32(&xlb->config, in_be32(&xlb->config) | MPC52xx_XLB_CFG_PLDIS);
+#if 0
+ /*
+ * Enable pipelining, fixes FEC problems. The previous workaround is not
+ * needed, as we have an MPC5200B (not A).
+ */
+ out_be32(&xlb->config, in_be32(&xlb->config) & ~MPC52xx_XLB_CFG_PLDIS);
+#endif
iounmap(xlb);
}
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Initialize DBCR0 for PPC440 targets
From: srikanth krishnakar @ 2009-05-20 6:14 UTC (permalink / raw)
To: srikanth krishnakar, Linuxppc-dev
In-Reply-To: <20090520060014.GL6333@yookeroo.seuss>
Hi David,
Just to correct the statements : How the DBCR0 is initialized on
targets that don't use boot loaders ?
-Srikant
On Wed, May 20, 2009 at 11:30 AM, David Gibson
<david@gibson.dropbear.id.au> wrote:
> On Wed, May 20, 2009 at 11:20:46AM +0530, srikanth krishnakar wrote:
>> Hi David,
>>
>> I am not sure how the IDM behaves on few of PPC440 targets which don't
>> have boot loaders. I have a reference for your question:
>>
>> http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td2304=
9044.html
>>
>> Without this fix (given patch) I am facing problems with GDB, and
>> further target hangs while running gdbserver !
>
> That doesn't answer my question. =A0It's not enough to say "this fixes a
> problem" you need to explain *how* it fixes the problem.
>
> And I don't see why IDM would have any effect on *software*
> breakpoints.
>
>> On Wed, May 20, 2009 at 5:23 AM, David Gibson
>> <david@gibson.dropbear.id.au> wrote:
>> > On Tue, May 19, 2009 at 06:38:53PM +0530, srikanth krishnakar wrote:
>> >> Hi,
>> >>
>> >> kernel- 2.6.29
>> >> Debug technique: KGDB
>> >>
>> >> The PowerPC kernel does not initialize the PPC440 DBCR0 register. Thi=
s
>> >> prevents the use of software breakpoints in case of internal debug
>> >> mode. Looking into head_fsl_booke.S for initialization of DBCR0 is
>> >> used by boot-loaders.
>> >> It seems head_44x.S lacks this step of DBCR0 register initialization.
>> >> So fixing this with initializing the DBCR0 register as shown below :
>> >>
>> >> Subject: [PATCH] powerpc: 44x: Initialize DBCR0 for targets not havin=
g
>> >> bootloader
>> >>
>> >> The kernel does not initialize the PPC440 DBCR0 register.
>> >> This prevents (among other things) the use of software
>> >> breakpoints with GDB. The boot loaders probably do initialize
>> >> this but few targets run without a boot loader
>> >
>> > Um.. how does this prevent the use of software breakpoints with gdb?
>> > The trap instructions still work with IDM=3D=3D0.
>
> --
> David Gibson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| I'll have my music =
baroque, and my code
> david AT gibson.dropbear.id.au =A0| minimalist, thank you. =A0NOT _the_ _=
other_
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| _way_ _a=
round_!
> http://www.ozlabs.org/~dgibson
>
--=20
"The Good You Do, The Best You GET"
Regards
Srikanth Krishnakar
**********************
^ permalink raw reply
* Re: Initialize DBCR0 for PPC440 targets
From: David Gibson @ 2009-05-20 6:00 UTC (permalink / raw)
To: srikanth krishnakar; +Cc: Linuxppc-dev
In-Reply-To: <6213bc560905192250w4caa84aem9c0dedb2eed72fea@mail.gmail.com>
On Wed, May 20, 2009 at 11:20:46AM +0530, srikanth krishnakar wrote:
> Hi David,
>
> I am not sure how the IDM behaves on few of PPC440 targets which don't
> have boot loaders. I have a reference for your question:
>
> http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html
>
> Without this fix (given patch) I am facing problems with GDB, and
> further target hangs while running gdbserver !
That doesn't answer my question. It's not enough to say "this fixes a
problem" you need to explain *how* it fixes the problem.
And I don't see why IDM would have any effect on *software*
breakpoints.
> On Wed, May 20, 2009 at 5:23 AM, David Gibson
> <david@gibson.dropbear.id.au> wrote:
> > On Tue, May 19, 2009 at 06:38:53PM +0530, srikanth krishnakar wrote:
> >> Hi,
> >>
> >> kernel- 2.6.29
> >> Debug technique: KGDB
> >>
> >> The PowerPC kernel does not initialize the PPC440 DBCR0 register. This
> >> prevents the use of software breakpoints in case of internal debug
> >> mode. Looking into head_fsl_booke.S for initialization of DBCR0 is
> >> used by boot-loaders.
> >> It seems head_44x.S lacks this step of DBCR0 register initialization.
> >> So fixing this with initializing the DBCR0 register as shown below :
> >>
> >> Subject: [PATCH] powerpc: 44x: Initialize DBCR0 for targets not having
> >> bootloader
> >>
> >> The kernel does not initialize the PPC440 DBCR0 register.
> >> This prevents (among other things) the use of software
> >> breakpoints with GDB. The boot loaders probably do initialize
> >> this but few targets run without a boot loader
> >
> > Um.. how does this prevent the use of software breakpoints with gdb?
> > The trap instructions still work with IDM==0.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [RFC][PATCH] powerpc/pci: Pull ppc32 code we need in ppc64
From: Kumar Gala @ 2009-05-20 5:57 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <Pine.LNX.4.64.0904291546130.19681@localhost.localdomain>
Ben,
Comments on the pmac case?
- k
On Apr 29, 2009, at 3:49 PM, Kumar Gala wrote:
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
>
> Ben,
>
> My question is if we think fake_pci_bus will always get a valid
> hose().
> The users of EARLY_PCI_OP are fsl/8xxx, 4xx, and pmac. I verified
> that
> fsl/8xxx & 4xx pass a valid hose. Do we think pmac does?
>
> - k
>
> arch/powerpc/include/asm/machdep.h | 6 +-
> arch/powerpc/include/asm/pci-bridge.h | 35 +++++++---------
> arch/powerpc/kernel/pci-common.c | 70 ++++++++++++++++++++++++
> ++++++++
> arch/powerpc/kernel/pci_32.c | 71
> ---------------------------------
> 4 files changed, 89 insertions(+), 93 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/
> include/asm/machdep.h
> index 0efdb1d..1b389ff 100644
> --- a/arch/powerpc/include/asm/machdep.h
> +++ b/arch/powerpc/include/asm/machdep.h
> @@ -205,14 +205,14 @@ struct machdep_calls {
> /*
> * optional PCI "hooks"
> */
> - /* Called in indirect_* to avoid touching devices */
> - int (*pci_exclude_device)(struct pci_controller *, unsigned char,
> unsigned char);
> -
> /* Called at then very end of pcibios_init() */
> void (*pcibios_after_init)(void);
>
> #endif /* CONFIG_PPC32 */
>
> + /* Called in indirect_* to avoid touching devices */
> + int (*pci_exclude_device)(struct pci_controller *, unsigned char,
> unsigned char);
> +
> /* Called after PPC generic resource fixup to perform
> machine specific fixups */
> void (*pcibios_fixup_resources)(struct pci_dev *);
> diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/
> include/asm/pci-bridge.h
> index 48f58aa..8b371df 100644
> --- a/arch/powerpc/include/asm/pci-bridge.h
> +++ b/arch/powerpc/include/asm/pci-bridge.h
> @@ -77,9 +77,7 @@ struct pci_controller {
>
> int first_busno;
> int last_busno;
> -#ifndef CONFIG_PPC64
> int self_busno;
> -#endif
>
> void __iomem *io_base_virt;
> #ifdef CONFIG_PPC64
> @@ -104,7 +102,6 @@ struct pci_controller {
> unsigned int __iomem *cfg_addr;
> void __iomem *cfg_data;
>
> -#ifndef CONFIG_PPC64
> /*
> * Used for variants of PCI indirect handling and possible quirks:
> * SET_CFG_TYPE - used on 4xx or any PHB that does explicit type0/1
> @@ -128,7 +125,6 @@ struct pci_controller {
> #define PPC_INDIRECT_TYPE_BIG_ENDIAN 0x00000010
> #define PPC_INDIRECT_TYPE_BROKEN_MRM 0x00000020
> u32 indirect_type;
> -#endif /* !CONFIG_PPC64 */
> /* Currently, we limit ourselves to 1 IO range and 3 mem
> * ranges since the common pci_bus structure can't handle more
> */
> @@ -146,21 +142,6 @@ struct pci_controller {
> #endif /* CONFIG_PPC64 */
> };
>
> -#ifndef CONFIG_PPC64
> -
> -static inline struct pci_controller *pci_bus_to_host(const struct
> pci_bus *bus)
> -{
> - return bus->sysdata;
> -}
> -
> -static inline int isa_vaddr_is_ioport(void __iomem *address)
> -{
> - /* No specific ISA handling on ppc32 at this stage, it
> - * all goes through PCI
> - */
> - return 0;
> -}
> -
> /* These are used for config access before all the PCI probing
> has been done. */
> extern int early_read_config_byte(struct pci_controller *hose, int
> bus,
> @@ -182,6 +163,22 @@ extern int early_find_capability(struct
> pci_controller *hose, int bus,
> extern void setup_indirect_pci(struct pci_controller* hose,
> resource_size_t cfg_addr,
> resource_size_t cfg_data, u32 flags);
> +
> +#ifndef CONFIG_PPC64
> +
> +static inline struct pci_controller *pci_bus_to_host(const struct
> pci_bus *bus)
> +{
> + return bus->sysdata;
> +}
> +
> +static inline int isa_vaddr_is_ioport(void __iomem *address)
> +{
> + /* No specific ISA handling on ppc32 at this stage, it
> + * all goes through PCI
> + */
> + return 0;
> +}
> +
> #else /* CONFIG_PPC64 */
>
> /*
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/
> pci-common.c
> index 9c69e7e..cae4ee1 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -1620,3 +1620,73 @@ void __devinit
> pcibios_setup_phb_resources(struct pci_controller *hose)
>
> }
>
> +/*
> + * Null PCI config access functions, for the case when we can't
> + * find a hose.
> + */
> +#define NULL_PCI_OP(rw, size, type) \
> +static int \
> +null_##rw##_config_##size(struct pci_dev *dev, int offset, type
> val) \
> +{ \
> + return PCIBIOS_DEVICE_NOT_FOUND; \
> +}
> +
> +static int
> +null_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
> + int len, u32 *val)
> +{
> + return PCIBIOS_DEVICE_NOT_FOUND;
> +}
> +
> +static int
> +null_write_config(struct pci_bus *bus, unsigned int devfn, int
> offset,
> + int len, u32 val)
> +{
> + return PCIBIOS_DEVICE_NOT_FOUND;
> +}
> +
> +static struct pci_ops null_pci_ops =
> +{
> + .read = null_read_config,
> + .write = null_write_config,
> +};
> +
> +/*
> + * These functions are used early on before PCI scanning is done
> + * and all of the pci_dev and pci_bus structures have been created.
> + */
> +static struct pci_bus *
> +fake_pci_bus(struct pci_controller *hose, int busnr)
> +{
> + static struct pci_bus bus;
> +
> + if (hose == 0) {
> + printk(KERN_ERR "Can't find hose for PCI bus %d!\n", busnr);
> + }
> + bus.number = busnr;
> + bus.sysdata = hose;
> + bus.ops = hose? hose->ops: &null_pci_ops;
> + return &bus;
> +}
> +
> +#define EARLY_PCI_OP(rw, size, type) \
> +int early_##rw##_config_##size(struct pci_controller *hose, int
> bus, \
> + int devfn, int offset, type value) \
> +{ \
> + return pci_bus_##rw##_config_##size(fake_pci_bus(hose, bus), \
> + devfn, offset, value); \
> +}
> +
> +EARLY_PCI_OP(read, byte, u8 *)
> +EARLY_PCI_OP(read, word, u16 *)
> +EARLY_PCI_OP(read, dword, u32 *)
> +EARLY_PCI_OP(write, byte, u8)
> +EARLY_PCI_OP(write, word, u16)
> +EARLY_PCI_OP(write, dword, u32)
> +
> +extern int pci_bus_find_capability (struct pci_bus *bus, unsigned
> int devfn, int cap);
> +int early_find_capability(struct pci_controller *hose, int bus, int
> devfn,
> + int cap)
> +{
> + return pci_bus_find_capability(fake_pci_bus(hose, bus), devfn, cap);
> +}
> diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/
> pci_32.c
> index d473634..32fbadb 100644
> --- a/arch/powerpc/kernel/pci_32.c
> +++ b/arch/powerpc/kernel/pci_32.c
> @@ -497,75 +497,4 @@ long sys_pciconfig_iobase(long which, unsigned
> long bus, unsigned long devfn)
> return result;
> }
>
> -/*
> - * Null PCI config access functions, for the case when we can't
> - * find a hose.
> - */
> -#define NULL_PCI_OP(rw, size, type) \
> -static int \
> -null_##rw##_config_##size(struct pci_dev *dev, int offset, type
> val) \
> -{ \
> - return PCIBIOS_DEVICE_NOT_FOUND; \
> -}
> -
> -static int
> -null_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
> - int len, u32 *val)
> -{
> - return PCIBIOS_DEVICE_NOT_FOUND;
> -}
> -
> -static int
> -null_write_config(struct pci_bus *bus, unsigned int devfn, int
> offset,
> - int len, u32 val)
> -{
> - return PCIBIOS_DEVICE_NOT_FOUND;
> -}
> -
> -static struct pci_ops null_pci_ops =
> -{
> - .read = null_read_config,
> - .write = null_write_config,
> -};
>
> -/*
> - * These functions are used early on before PCI scanning is done
> - * and all of the pci_dev and pci_bus structures have been created.
> - */
> -static struct pci_bus *
> -fake_pci_bus(struct pci_controller *hose, int busnr)
> -{
> - static struct pci_bus bus;
> -
> - if (hose == 0) {
> - hose = pci_bus_to_hose(busnr);
> - if (hose == 0)
> - printk(KERN_ERR "Can't find hose for PCI bus %d!\n", busnr);
> - }
> - bus.number = busnr;
> - bus.sysdata = hose;
> - bus.ops = hose? hose->ops: &null_pci_ops;
> - return &bus;
> -}
> -
> -#define EARLY_PCI_OP(rw, size, type) \
> -int early_##rw##_config_##size(struct pci_controller *hose, int
> bus, \
> - int devfn, int offset, type value) \
> -{ \
> - return pci_bus_##rw##_config_##size(fake_pci_bus(hose, bus), \
> - devfn, offset, value); \
> -}
> -
> -EARLY_PCI_OP(read, byte, u8 *)
> -EARLY_PCI_OP(read, word, u16 *)
> -EARLY_PCI_OP(read, dword, u32 *)
> -EARLY_PCI_OP(write, byte, u8)
> -EARLY_PCI_OP(write, word, u16)
> -EARLY_PCI_OP(write, dword, u32)
> -
> -extern int pci_bus_find_capability (struct pci_bus *bus, unsigned
> int devfn, int cap);
> -int early_find_capability(struct pci_controller *hose, int bus, int
> devfn,
> - int cap)
> -{
> - return pci_bus_find_capability(fake_pci_bus(hose, bus), devfn, cap);
> -}
> --
> 1.6.0.6
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Musings on PCI busses
From: David Miller @ 2009-05-20 5:51 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, thunderbird2k, John.Linn
In-Reply-To: <1242788490.16901.133.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Wed, 20 May 2009 13:01:30 +1000
> For example, some of the OF parsing bits may fail to convert memory
> addresses to IO addresses if the PCI host bridges have not been
> discovered yet, potentially causing issues with matching of resources
> between the early serial stuff and the generic serial driver (if you
> use an IO driven UART, the PCI 8250 driver may not properly figure out
> that what it's finding in its IO BARs is actually the same port as
> what it gets from the platform code as the later will end up with
> memory addresses rather than IO ones). That's one example.
FWIW, I never run into this issue on sparc64 exactly because I
fully resolve all resources when I populate the OF device tree
in the kernel.
^ permalink raw reply
* Re: Initialize DBCR0 for PPC440 targets
From: srikanth krishnakar @ 2009-05-20 5:50 UTC (permalink / raw)
To: srikanth krishnakar, Linuxppc-dev, Linuxppc-embedded
In-Reply-To: <20090519235302.GA6333@yookeroo.seuss>
Hi David,
I am not sure how the IDM behaves on few of PPC440 targets which don't
have boot loaders. I have a reference for your question:
http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td2304904=
4.html
Without this fix (given patch) I am facing problems with GDB, and
further target hangs while running gdbserver !
Thanks,
Srikanth
On Wed, May 20, 2009 at 5:23 AM, David Gibson
<david@gibson.dropbear.id.au> wrote:
> On Tue, May 19, 2009 at 06:38:53PM +0530, srikanth krishnakar wrote:
>> Hi,
>>
>> kernel- 2.6.29
>> Debug technique: KGDB
>>
>> The PowerPC kernel does not initialize the PPC440 DBCR0 register. This
>> prevents the use of software breakpoints in case of internal debug
>> mode. Looking into head_fsl_booke.S for initialization of DBCR0 is
>> used by boot-loaders.
>> It seems head_44x.S lacks this step of DBCR0 register initialization.
>> So fixing this with initializing the DBCR0 register as shown below :
>>
>> Subject: [PATCH] powerpc: 44x: Initialize DBCR0 for targets not having
>> bootloader
>>
>> The kernel does not initialize the PPC440 DBCR0 register.
>> This prevents (among other things) the use of software
>> breakpoints with GDB. The boot loaders probably do initialize
>> this but few targets run without a boot loader
>
> Um.. how does this prevent the use of software breakpoints with gdb?
> The trap instructions still work with IDM=3D=3D0.
>
> --
> David Gibson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| I'll have my music =
baroque, and my code
> david AT gibson.dropbear.id.au =A0| minimalist, thank you. =A0NOT _the_ _=
other_
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| _way_ _a=
round_!
> http://www.ozlabs.org/~dgibson
>
--=20
"The Good You Do, The Best You GET"
Regards
Srikanth Krishnakar
**********************
^ permalink raw reply
* Re: Musings on PCI busses
From: Benjamin Herrenschmidt @ 2009-05-20 5:33 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, thunderbird2k, John.Linn, arnd
In-Reply-To: <20090519.120514.26253637.davem@davemloft.net>
On Tue, 2009-05-19 at 12:05 -0700, David Miller wrote:
>
> This is also what sparc64 does :-)
>
> All of the individual sparc64 PCI controller types have a OF driver
> and then there is a common layer of OF PCI helper code to do most
> of the work.
I agree it's a good idea in the long run, but on ppc32, I would be a bit
careful due to the amount of historical crap & early board fixup we have
that may need working PCI config space accesses and make assumption
about when PCI is probed.
We could add the necessary bits for ppc32 to be able to "opt-in" the new
scheme on a per board basis I suppose.
Cheers,
Ben.
^ permalink raw reply
* Re: Musings on PCI busses
From: Benjamin Herrenschmidt @ 2009-05-20 5:31 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Roderick Colenbrander, John Linn
In-Reply-To: <fa686aa40905192017r7978fdddq70872dcf86127008@mail.gmail.com>
On Tue, 2009-05-19 at 21:17 -0600, Grant Likely wrote:
> On Tue, May 19, 2009 at 9:02 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Tue, 2009-05-19 at 09:25 -0700, Stephen Neuendorffer wrote:
> >
> >> I agree that something is called for... The first might be slightly
> >> simpler, since it would probably transparently deal with the presence
> >> of more than one PLB->PCI bridge?
> >
> > The current code doesn't already ?
>
> Current code doesn't exist in mainline. :-)
Well, I was thinking about ppc4xx_pci :-)
> And, no, the patch Roderick wrote doesn't handle more than one PHB.
> No reason it couldn't though.
Right, it shouldn't be hard.
Cheers,
Ben.
^ permalink raw reply
* Re: question : DMA of PCI bridge
From: David Hawkins @ 2009-05-20 3:51 UTC (permalink / raw)
To: Sauce.Cheng; +Cc: linuxppc-dev
In-Reply-To: <23628338.post@talk.nabble.com>
Hi,
> Now I attempt to fetch data from peripheral device to SDRAM, and it has been
> successed
>
> but how the DMA controller know the data bandwidth of src and dest.
>
> for example, if i get a 16bits data with a 32bits bus, and other 16bits will
> be set high
> and data will fetched into cache line of dma, then it will be wrote to
> 32bits SDRAM.
You'll need to give us a little more detail. For example,
what processor are you using to perform the transaction?
Your email title says DMA of PCI bridge, however, you
mention peripheral to SDRAM. Are you using a DMA controller
on the peripheral, eg. a PCI bus master, to DMA into the
host SDRAM, or are you using a host DMA controller to
DMA over PCI into memory on the host?
Whether or not you get packing bytes when you access a
16-bit device and transfer the data to a 32-bit destination
depends on how the device is mapped. For example, a 16-bit
device can be implemented such that it responds to 8-bit,
16-bit, and 32-bit requests, but the 32-bit requests will
require more wait-states, since the device has to be
read from twice before constructing a 32-bit word to
place on the PCI bus.
Its also possible that the DMA controller can be configured
to deal with different source and destination widths. However
without knowing what processor or DMA controller you are
asking about, theres not much to say.
Cheers,
Dave
^ permalink raw reply
* question : DMA of PCI bridge
From: Sauce.Cheng @ 2009-05-20 3:19 UTC (permalink / raw)
To: linuxppc-dev
excuse me
I hate to bother everyone but I have a question about DMA of PCI bridge
Now I attempt to fetch data from peripheral device to SDRAM, and it has been
successed
but how the DMA controller know the data bandwidth of src and dest.
for example, if i get a 16bits data with a 32bits bus, and other 16bits will
be set high
and data will fetched into cache line of dma, then it will be wrote to
32bits SDRAM.
i guess the data will be wrong, isn't ?
please give me some advices. thank you
--
View this message in context: http://www.nabble.com/question-%3A-DMA-of-PCI-bridge-tp23628338p23628338.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox