* Re: [PATCH 01/10] Add support for GCC-4.5's __builtin_unreachable() to compiler.h
From: David Daney @ 2009-09-11 15:58 UTC (permalink / raw)
To: Michael Buesch
Cc: linux-mips, Heiko Carstens, linuxppc-dev, Paul Mackerras,
H. Peter Anvin, linux-s390, linux-am33-list, Helge Deller, x86,
Ingo Molnar, Mike Frysinger, Ivan Kokshaysky, linux390,
Thomas Gleixner, Richard Henderson, Haavard Skinnemoen,
linux-parisc, torvalds, linux-kernel, ralf, Kyle McMartin,
linux-alpha, Martin Schwidefsky, uclinux-dist-devel, akpm,
Koichi Yasutake, linuxppc-dev
In-Reply-To: <200909111633.00665.mb@bu3sch.de>
Michael Buesch wrote:
> On Friday 11 September 2009 01:56:42 David Daney wrote:
>> +/* Unreachable code */
>> +#ifndef unreachable
>> +# define unreachable() do { for (;;) ; } while (0)
>> +#endif
>
> # define unreachable() do { } while (1)
>
> ? :)
Clearly I was not thinking clearly when I wrote that part. RTH noted
the same thing. I will fix it.
Thanks,
David Daney
^ permalink raw reply
* Re: [PATCH 01/10] Add support for GCC-4.5's __builtin_unreachable() to compiler.h
From: Michael Buesch @ 2009-09-11 14:32 UTC (permalink / raw)
To: linuxppc-dev
Cc: linux-mips, Heiko Carstens, linuxppc-dev, Paul Mackerras,
H. Peter Anvin, linux-s390, linux-am33-list, Helge Deller, x86,
David Daney, Ingo Molnar, Mike Frysinger, Ivan Kokshaysky,
linux390, Thomas Gleixner, Richard Henderson, Haavard Skinnemoen,
linux-parisc, linux-kernel, ralf, Kyle McMartin, linux-alpha,
Martin Schwidefsky, uclinux-dist-devel, akpm, Koichi Yasutake,
torvalds
In-Reply-To: <1252627011-2933-1-git-send-email-ddaney@caviumnetworks.com>
On Friday 11 September 2009 01:56:42 David Daney wrote:
> +/* Unreachable code */
> +#ifndef unreachable
> +# define unreachable() do { for (;;) ; } while (0)
> +#endif
# define unreachable() do { } while (1)
? :)
--
Greetings, Michael.
^ permalink raw reply
* Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Tom Burns @ 2009-09-11 13:51 UTC (permalink / raw)
To: benh; +Cc: Prodyut Hazarika, Andrea Zypchen, linuxppc-dev, azilkie, lebon
In-Reply-To: <1252634148.8566.11.camel@pasglop>
Hi Ben,
Benjamin Herrenschmidt wrote:
> On Wed, 2009-09-09 at 09:43 -0400, Tom Burns wrote:
>
>> Hi,
>>
>> With the default config for the Sequoia board on 2.6.24, calling
>> pci_dma_sync_sg_for_cpu() results in executing
>> invalidate_dcache_range() in arch/ppc/kernel/misc.S from __dma_sync().
>> This OOPses on PPC440 since it tries to call directly the assembly
>> instruction dcbi, which can only be executed in supervisor mode. We
>> tried that before resorting to manual cache line management with
>> usermode-safe assembly calls.
>>
>
> Wait a minute.... usermode ? You are doing all of that from userspace ?
> I don't understand the story here. You can't call all those kernel APIs
> form userspace in the first place, indeed... But then an IDE driver has
> nothing to do in userspace neither.
>
Sorry, I was referring to whether or not the CPU is in supervisor mode.
Our code is all in the kernel, not userspace :). I can see now from the
value of MSR at the time of the OOPS that the processor was in
supervisor mode, I missed that earlier. Looks like you're right about
the bad address, I will investigate.
Thanks,
Tom
> Cheers,
> Ben.
>
>
>> Regards,
>> Tom Burns
>> International Datacasting Corporation
>>
>> Mikhail Zolotaryov wrote:
>>
>>> Hi,
>>>
>>> Why manage cache lines manually, if appropriate code is a part of
>>> __dma_sync / dma_sync_single_for_device of DMA API ? (implies
>>> CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
>>>
>>> Prodyut Hazarika wrote:
>>>
>>>> Hi Adam,
>>>>
>>>>
>>>>
>>>>> Yes, I am using the 440EPx (same as the sequoia board). Our
>>>>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
>>>>>
>>>>>
>>>> (using
>>>>
>>>>
>>>>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on timing)
>>>>> end up being partially corrupted when we try to parse the data in the
>>>>> virtual page. We have confirmed the data is good before the PCI-IDE
>>>>> bridge. We are creating two 8K pages and map them to physical DMA
>>>>>
>>>>>
>>>> memory
>>>>
>>>>
>>>>> using single-entry scatter/gather structs. When a DMA block is
>>>>> corrupted, we see a random portion of it (always a multiple of 16byte
>>>>> cache lines) is overwritten with old data from the last time the
>>>>>
>>>>>
>>>> buffer
>>>>
>>>>
>>>>> was used.
>>>>>
>>>> This looks like a cache coherency problem.
>>>> Can you ensure that the TLB entries corresponding to the DMA region has
>>>> the CacheInhibit bit set.
>>>> You will need a BDI connected to your system.
>>>>
>>>> Also, you will need to invalidate and flush the lines appropriately,
>>>> since in 440 cores,
>>>> L1Cache coherency is managed entirely by software.
>>>> Please look at drivers/net/ibm_newemac/mal.c and core.c for example on
>>>> how to do it.
>>>>
>>>> Thanks
>>>> Prodyut
>>>>
>>>> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
>>>>
>>>>
>>>>> Hi Adam,
>>>>>
>>>>>
>>>>>
>>>>>> Are you sure there is L2 cache on the 440?
>>>>>>
>>>>>>
>>>>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
>>>>>
>>>>>
>>>> board)
>>>>
>>>>
>>>>> have L2Cache.
>>>>> It seems you are using a Sequoia board, which has a 440EPx SoC. 440EPx
>>>>> has a 440 cpu core, but no L2Cache.
>>>>> Could you please tell me which SoC you are using?
>>>>> You can also refer to the appropriate dts file to see if there is L2C.
>>>>> For example, in canyonlands.dts (460EX based board), we have the L2C
>>>>> entry.
>>>>> L2C0: l2c {
>>>>> ...
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>>> I am seeing this problem with our custom IDE driver which is based on
>>>>>>
>>>>>>
>>>>
>>>>
>>>>>> pretty old code. Our driver uses pci_alloc_consistent() to allocate
>>>>>>
>>>>>>
>>>> the
>>>>
>>>>
>>>>>> physical DMA memory and alloc_pages() to allocate a virtual page.
>>>>>> It then uses pci_map_sg() to map to a scatter/gather buffer.
>>>>>> Perhaps I should convert these to the DMA API calls as you suggest.
>>>>>>
>>>>>>
>>>>> Could you give more details on the consistency problem? It is a good
>>>>> idea to change to the new DMA APIs, but pci_alloc_consistent() should
>>>>> work too
>>>>>
>>>>> Thanks
>>>>> Prodyut
>>>>>
>>>>> On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt wrote:
>>>>>
>>>>>
>>>>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
>>>>>>
>>>>>>
>>>>>>> Hi Adam,
>>>>>>>
>>>>>>> If you have a look in include/asm-ppc/pgtable.h for the following
>>>>>>>
>>>>>>>
>>>>> section:
>>>>>
>>>>>
>>>>>>> #ifdef CONFIG_44x
>>>>>>> #define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED |
>>>>>>>
>>>>>>>
>>>>> _PAGE_GUARDED)
>>>>>
>>>>>
>>>>>>> #else
>>>>>>> #define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED)
>>>>>>> #endif
>>>>>>>
>>>>>>> Try adding _PAGE_COHERENT to the appropriate line above and see if
>>>>>>>
>>>>>>>
>>>>> that
>>>>>
>>>>>>> fixes your issue - this causes the 'M' bit to be set on the page
>>>>>>>
>>>>>>>
>>>>> which
>>>>>
>>>>>>> sure enforce cache coherency. If it doesn't, you'll need to check
>>>>>>>
>>>>>>>
>>>>> the
>>>>>
>>>>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
>>>>>>>
>>>>>>>
>>>>> masked
>>>>>
>>>>>>> out on arch/powerpc, but was fixed in later kernels when the cache
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>>>>> coherency issues with non-SMP systems were resolved).
>>>>>>>
>>>>>>>
>>>>>> I have some doubts about the usefulness of doing that for 4xx.
>>>>>>
>>>>>>
>>>> AFAIK,
>>>>
>>>>
>>>>>> the 440 core just ignores M.
>>>>>>
>>>>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
>>>>>>
>>>>>>
>>>>> isn't
>>>>>
>>>>>
>>>>>> enabled or not working ?
>>>>>>
>>>>>> The L1 cache on 440 is simply not coherent, so drivers have to make
>>>>>>
>>>>>>
>>>>> sure
>>>>>
>>>>>
>>>>>> they use the appropriate DMA APIs which will do cache flushing when
>>>>>> needed.
>>>>>>
>>>>>> Adam, what driver is causing you that sort of problems ?
>>>>>>
>>>>>> Cheers,
>>>>>> Ben.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>
>
>
>
^ permalink raw reply
* RE: [RESEND][PATCH] sata_fsl: hard and soft reset split
From: Kalra Ashish-B00888 @ 2009-09-11 13:21 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide, linuxppc-dev
In-Reply-To: <4AA9F038.6030207@garzik.org>
Hello Jeff,
I will do the rediff and resubmit the patch.
Thanks,
Ashish=20
-----Original Message-----
From: Jeff Garzik [mailto:jeff@garzik.org]=20
Sent: Friday, September 11, 2009 12:08 PM
To: Kalra Ashish-B00888
Cc: linux-ide@vger.kernel.org; linuxppc-dev@ozlabs.org
Subject: Re: [RESEND][PATCH] sata_fsl: hard and soft reset split
On 06/29/2009 09:26 AM, ashish kalra wrote:
> Split sata_fsl_softreset() into hard and soft resets to make=20
> error-handling more efficient & device and PMP detection more
reliable.
>
> Also includes fix for PMP support, driver tested with Sil3726, Sil4726
> & Exar PMP controllers.
>
> Signed-off-by: Ashish Kalra <Ashish.Kalra@freescale.com>
can you rediff this and 'AN' support against latest upstream?
^ permalink raw reply
* Re: linux booting fine but running slow
From: Frank Svendsbøe @ 2009-09-11 13:06 UTC (permalink / raw)
To: Gao Ya'nan; +Cc: linuxppc-dev, stevan
In-Reply-To: <d15e5cf90909110459p221d4bc3nc9e1d45b95bce6bd@mail.gmail.com>
Hi Gao and Stevan
I've observed the same slow-down issue on an MPC875 a while now, but
haven't had the time to do a git-bisect
and find the patch that causes the problem. So far, I'm running
torvalds 2.6.29-rc6, and the slow-down problem
was introduced somewhere between 2.6.26-rc6 and 2.6.30-rc2.
What options did you specify to improve the performance?
Regards,
Frank
On Fri, Sep 11, 2009 at 1:59 PM, Gao Ya'nan <abutter.gao@gmail.com> wrote:
> Hi, stevan, I had met a similarly problem with U-Boot-v2009.08 and
> DENX-v2.6.30.3 Linux.
>
> Today, I add some options to Linux, everythings worked well, but I got
> a fat kernel. Do you solve it now ?
>
> Gao Ya'nan
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re:linux booting fine but running slow
From: Gao Ya'nan @ 2009-09-11 11:59 UTC (permalink / raw)
To: linuxppc-dev; +Cc: stevan
Hi, stevan, I had met a similarly problem with U-Boot-v2009.08 and
DENX-v2.6.30.3 Linux.
Today, I add some options to Linux, everythings worked well, but I got
a fat kernel. Do you solve it now ?
Gao Ya'nan
^ permalink raw reply
* Re: [PATCH][v1] powerpc/85xx: Create dts for each core in CAMPmodefor P2020RDB
From: Gabriel Paubert @ 2009-09-11 11:52 UTC (permalink / raw)
To: Aggrwal Poonam-B10812; +Cc: linuxppc-dev
In-Reply-To: <1BD5CFC378ED0946B688E0C9BA2EF0951FD33A@zin33exm24.fsl.freescale.net>
On Fri, Sep 11, 2009 at 05:17:50PM +0530, Aggrwal Poonam-B10812 wrote:
>
>
> > -----Original Message-----
> > From: Gabriel Paubert [mailto:paubert@iram.es]
> > Sent: Thursday, September 10, 2009 9:33 PM
> > To: Aggrwal Poonam-B10812
> > Cc: linuxppc-dev@ozlabs.org
> > Subject: Re: [PATCH][v1] powerpc/85xx: Create dts for each
> > core in CAMPmodefor P2020RDB
> >
> > Ok, I wrongly understood protected interrupts as reserved for
> > one core. However, I still dislike two devices having the same name.
> >
> > Otherwise it may work if every interrupt is delivered to both
> > cores although statistically only one core will actually have
> > some work to do. Doesn't the kernel complain about unhandled
> > irqs however?
> >
> We don't see any such messages of unhandled interrupts, although I
> checked the corresponding files for mpc8572ds, they do not have the
> interrupts property for the serial ports at all, in both the core0 and
> core1 dts.
> Don't know the reason.
Well it may depend on the irqdebug (or actually it seems to
be noirqdebug) kernel parameter.
But if serial is used for console, the message rate could
go ballistic.
Gabriel
^ permalink raw reply
* RE: [PATCH][v1] powerpc/85xx: Create dts for each core in CAMPmodefor P2020RDB
From: Aggrwal Poonam-B10812 @ 2009-09-11 11:47 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev
In-Reply-To: <20090910160233.GA24085@iram.es>
=20
> -----Original Message-----
> From: Gabriel Paubert [mailto:paubert@iram.es]=20
> Sent: Thursday, September 10, 2009 9:33 PM
> To: Aggrwal Poonam-B10812
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH][v1] powerpc/85xx: Create dts for each=20
> core in CAMPmodefor P2020RDB
>=20
> On Thu, Sep 10, 2009 at 08:48:38PM +0530, Aggrwal Poonam-B10812 wrote:
> > =20
> >=20
> > > -----Original Message-----
> > > From: Gabriel Paubert [mailto:paubert@iram.es]
> > > Sent: Thursday, September 10, 2009 3:03 PM
> > > To: Aggrwal Poonam-B10812
> > > Cc: linuxppc-dev@ozlabs.org
> > > Subject: Re: [PATCH][v1] powerpc/85xx: Create dts for=20
> each core in=20
> > > CAMPmode for P2020RDB
> > >=20
> > > On Thu, Sep 10, 2009 at 02:27:11PM +0530, Poonam Aggrwal wrote:
> > > > This patch creates the dts files for each core and splits
> > > the devices
> > > > between the two cores for P2020RDB.
> > > >=20
> > > > core0 has memory, L2, i2c, spi, dma1, usb, eth0, eth1, crypto,=20
> > > > global-util, pci0
> > > > core1 has L2, dma2, eth0, pci1, msi.
> > >=20
> > > Surely you mean eth1 and eth2 for core0, no?
> > Yes you are right , I'll fix this.
> > >=20
> > > At least it's what I gather from the code.
> > >=20
> > > Also both cores have a node called serial0, at different=20
> addresses=20
> > > but with the same interrupt!
> > Yes both the UARTS use the same int line in shared mode.=20
> > >=20
> > > But in the mpic comment line there is "serial1", and=20
> interrupt 42 is=20
> > > the only number which appears in both lists of mpic protected=20
> > > interrupts.
> > I am not sure how to handle the shared interrupts in AMP scenario,=20
> > although this has been tested and both serials are working=20
> one on each=20
> > core.
>=20
> Ok, I wrongly understood protected interrupts as reserved for=20
> one core. However, I still dislike two devices having the same name.
>=20
> Otherwise it may work if every interrupt is delivered to both=20
> cores although statistically only one core will actually have=20
> some work to do. Doesn't the kernel complain about unhandled=20
> irqs however?=20
>=20
We don't see any such messages of unhandled interrupts, although I
checked the corresponding files for mpc8572ds, they do not have the
interrupts property for the serial ports at all, in both the core0 and
core1 dts.
Don't know the reason.
> Regards,
> Gabriel
>=20
> > > > +
> > > > + serial0: serial@4500 {
> > > > + cell-index =3D <0>;
> > > > + device_type =3D "serial";
> > > > + compatible =3D "ns16550";
> > > > + reg =3D <0x4500 0x100>;
> > > > + clock-frequency =3D <0>;
> > > > + interrupts =3D <42 2>;
> > > > + interrupt-parent =3D <&mpic>;
> > > > + };
>=20
> > > > +
> > > > + mpic: pic@40000 {
> > > > + interrupt-controller;
> > > > + #address-cells =3D <0>;
> > > > + #interrupt-cells =3D <2>;
> > > > + reg =3D <0x40000 0x40000>;
> > > > + compatible =3D "chrp,open-pic";
> > > > + device_type =3D "open-pic";
> > > > + protected-sources =3D <
> > > > + 42 76 77 78 79 /* serial1 , dma2 */
> > > > + 29 30 34 26 /* enet0, pci1 */
> > > > + 0xe0 0xe1 0xe2 0xe3 /* msi */
> > > > + 0xe4 0xe5 0xe6 0xe7
> > > > + >;
> > > > + };
> > > > +
> > > > +
>=20
> > > > + serial0: serial@4600 {
> > > > + cell-index =3D <1>;
> > > > + device_type =3D "serial";
> > > > + compatible =3D "ns16550";
> > > > + reg =3D <0x4600 0x100>;
> > > > + clock-frequency =3D <0>;
> > > > + interrupts =3D <42 2>;
> > > > + interrupt-parent =3D <&mpic>;
> > > > + };
> > > > +
> > > > +
>=20
> > > > + mpic: pic@40000 {
> > > > + interrupt-controller;
> > > > + #address-cells =3D <0>;
> > > > + #interrupt-cells =3D <2>;
> > > > + reg =3D <0x40000 0x40000>;
> > > > + compatible =3D "chrp,open-pic";
> > > > + device_type =3D "open-pic";
> > > > + protected-sources =3D <
> > > > + 17 18 43 42 59 47 /*ecm, mem,=20
> i2c, serial0, spi,gpio */
> > > > + 16 20 21 22 23 28 /* L2,=20
> dma1, USB */
> > > > + 03 35 36 40 31 32 33 /*=20
> mdio, enet1, enet2 */
> > > > + 72 45 58 25 /*=20
> sdhci, crypto , pci */
> > > > + >;
> > > > + };
> > > > +
>=20
>=20
^ permalink raw reply
* PCI: ioread8 on MPC8323E-RDB cause kernel oops message
From: Grzegorz Jakubowski @ 2009-09-11 11:06 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I try to install NIC VIA-Rhine III on PCI in MPC8323E-RDB.
I have used BSP in ver. 1.0-rt (MPC8323E-RDB-20070507),
after that LTIB was build, I have marked in kernel configuration menu to
build driver for NIC as module in PIO mode (via-rhine.ko).
lspci return:
~ # lspci -vv
00:10.0 USB Controller: NEC Corporation USB (rev 44) (prog-if 10 [OHCI])
Subsystem: NEC Corporation Hama USB 2.0 CardBus
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128 (250ns min, 10500ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at 90000000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:10.1 USB Controller: NEC Corporation USB 2.0 (rev 05) (prog-if 20 [EHCI])
Subsystem: NEC Corporation USB 2.0
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128 (4000ns min, 8500ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at 90001000 (32-bit, non-prefetchable) [size=256]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6105 [Rhine-III]
(rev 86)
Subsystem: VIA Technologies, Inc. Unknown device 0105
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128 (750ns min, 2000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 20
Region 0: I/O ports at d0000000 [size=256]
Region 1: Memory at 90001100 (32-bit, non-prefetchable) [size=256]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
after modprobe via-rhine I'got kernel oops message:
~ # modprobe via-rhine
via-rhine.c:v1.10-LK1.4.2 Sept-11-2006 Written by Donald Becker
drivers/net/via-rhine.c <453>: ioread8(3489660928 + 131)
Unable to handle kernel paging request for data at address 0xd00
00083
Faulting instruction address: 0xc0011b58
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT
Modules linked in: via_rhine
NIP: C0011B58 LR: C501FEAC CTR: C0011B54
REGS: c307fc80 TRAP: 0300 Not tainted (2.6.20.6-rt8)
MSR: 00009032 <EE,ME,IR,DR> CR: 44004422 XER: 00000000
DAR: D0000083, DSISR: 20000000
TASK = c042f030[798] 'modprobe' THREAD: c307e000
GPR00: C501FEA4 C307FD30 C042F030 D0000083 00001485 FFFFFFFF C01
6136C 00000033
GPR08: C042F030 C02E0000 00009032 C0011B54 24004422 1001C7AC 000
00000 00000000
GPR16: 00000000 00000000 000000A5 00000124 C03DBC48 00000001 C50
20000 C5022BF4
GPR24: C04E62C0 C04E6000 D0000000 00000100 D0000000 D0000083 C04
E62C0 D0000000
NIP [C0011B58] ioread8+0x4/0x18
LR [C501FEAC] rhine_power_init+0x64/0x19c [via_rhine]
Call Trace:
[C307FD30] [C501FEA4] rhine_power_init+0x5c/0x19c [via_rhine] (u
nreliable)
[C307FD50] [C50203A4] rhine_init_one+0x220/0x650 [via_rhine]
[C307FDA0] [C014A434] pci_device_probe+0x80/0xa0
[C307FDC0] [C0165794] really_probe+0x64/0x134
[C307FDE0] [C0165BB4] __driver_attach+0x84/0x88
[C307FE00] [C01647F8] bus_for_each_dev+0x54/0x90
[C307FE30] [C0165518] driver_attach+0x24/0x34
[C307FE40] [C0164E68] bus_add_driver+0x88/0x1b4
[C307FE60] [C0165E8C] driver_register+0x68/0xb0
[C307FE70] [C0149E6C] __pci_register_driver+0x84/0xe4
[C307FE90] [C502602C] rhine_init+0x2c/0x90 [via_rhine]
[C307FEA0] [C004B670] sys_init_module+0xf4/0x1624
[C307FF40] [C000F4A4] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff70fe8
LR = 0x10002ac4
Instruction dump:
83e1001c 38210020 7c0803a6 4e800020 38800000 7c0803a6 4e800021 2
f830000
3860ffea 419eff04 4bffffac 7c0004ac <88630000> 0c030000 4c00012c
5463063e
Segmentation fault
~ #
failed funcftion was ioread8 called from rhine_power_init in via-rhine.c
drivers/net/via-rhine.c <453>: ioread8(d0000000 + 83)
I have no idea why this call was failed, thanks for any help.
Thanks in advance.
Best Regards, Gregory Jakubowski
ps. U-Boot and kernel boot messages:
U-Boot 1.1.6 (May 7 2007 - 14:10:46) MPC83XX
Clock configuration:
Coherent System Bus: 133 MHz
Core: 333 MHz
QE: 99 MHz
BRG: 49 MHz
Local Bus Controller: 133 MHz
Local Bus: 66 MHz
DDR: 266 MHz
SEC: 133 MHz
I2C1: 133 MHz
CPU: MPC8323E, Rev: 11 at 333.333 MHz
Board: Freescale MPC8323ERDB
I2C: ready
DRAM:
DDR RAM: 64 MB
FLASH: 16 MB
PCI clock is 33MHz
In: serial
Out: serial
Err: serial
Net: UEC: PHY is Generic MII (2430d80)
FSL UEC0: Full Duplex
FSL UEC0: Speed 100BT
FSL UEC0: Link is up
UEC: PHY is Generic MII (2430d80)
FSL UEC1: Full Duplex
FSL UEC1: Speed 100BT
FSL UEC1: Link is up
FSL UEC0, FSL UEC1
Hit any key to stop autoboot: 6 ... 0
=> run tfpramboot
## Error: "tfpramboot" not defined
=> run tftpramboot
Using FSL UEC0 device
TFTP from server 192.168.0.119; our IP address is 192.168.0.121
Filename '832xerdb/rootfs.ext2.gz.uboot'.
Load address: 0x1000000
Loading: *.#####################################################
...
. #############
done
Bytes transferred = 9050488 (8a1978 hex)
Using FSL UEC0 device
TFTP from server 192.168.0.119; our IP address is 192.168.0.121
Filename '832xerdb/uImage'.
Load address: 0x200000
Loading: *.#####################################################
############
...
. ##########################################
done
Bytes transferred = 1545367 (179497 hex)
Using FSL UEC0 device
TFTP from server 192.168.0.119; our IP address is 192.168.0.121
Filename '832xerdb/mpc832x_rdb.dtb'.
Load address: 0x400000
Loading: *.#
done
Bytes transferred = 5070 (13ce hex)
## Booting image at 00200000 ...
Image Name: Linux-2.6.20.6-rt8
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1545303 Bytes = 1.5 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 01000000 ...
Image Name: uboot ext2 ramdisk rootfs
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 9050424 Bytes = 8.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Booting using flat device tree at 0x400000
Loading Ramdisk to 0370a000, end 03fab938 ... OK
Using MPC832x RDB machine description
Linux version 2.6.20.6-rt8 (grzegorz@matrix) (gcc version 4.0.2
20060628 (Wasabi)) #2 PREEMPT Tue Sep 8 14:41:52 CEST 2009
Found initrd at 0xc370a000:0xc3fab938
setup_arch: bootmem
mpc832x_rdb_setup_arch()
Found MPC83xx PCI host bridge at 0x00000000e0008500. Firmware bu
s number: 0->0
arch: exit
Zone PFN ranges:
DMA 0 -> 16384
Normal 16384 -> 16384
early_node_map[1] active PFN ranges
0: 0 -> 16384
Real-Time Preemption Support (C) 2004-2007 Ingo Molnar
Built 1 zonelists. Total pages: 16256
Kernel command line: root=/dev/ram ramdisk_size=25000 rw console
=ttyS0,115200
WARNING: experimental RCU implementation.
IPIC (128 IRQ sources) at fdefb700
QEIC (64 IRQ sources) at fdefa080
PID hash table entries: 256 (order: 8, 1024 bytes)
Using MPC832x RDB machine description
Linux version 2.6.20.6-rt8 (grzegorz@matrix) (gcc version 4.0.2
20060628 (Wasabi)) #2 PREEMPT Tue Sep 8 14:41:52 CEST 2009
Found initrd at 0xc370a000:0xc3fab938
Found MPC83xx PCI host bridge at 0x00000000e0008500. Firmware bu
s number: 0->0
Zone PFN ranges:
DMA 0 -> 16384
Normal 16384 -> 16384
early_node_map[1] active PFN ranges
0: 0 -> 16384
Real-Time Preemption Support (C) 2004-2007 Ingo Molnar
Built 1 zonelists. Total pages: 16256
Kernel command line: root=/dev/ram ramdisk_size=25000 rw console
=ttyS0,115200
WARNING: experimental RCU implementation.
IPIC (128 IRQ sources) at fdefb700
QEIC (64 IRQ sources) at fdefa080
PID hash table entries: 256 (order: 8, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 52736k/65536k available (2912k kernel code, 12740k reser
ved, 204k data, 120k bss, 136k init)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
Generic PHY: Registered new driver
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 4, 65536 bytes)
TCP bind hash table entries: 1024 (order: 2, 28672 bytes)
TCP: Hash tables configured (established 2048 bind 1024)
TCP reno registered
checking if image is initramfs...it isn't (no cpio magic); looks
like an initrd
Freeing initrd memory: 8838k freed
prom_parse: Bad cell count for /qe@e0100000/mdio@3120/ethernet-p
hy@00
prom_parse: Bad cell count for /qe@e0100000/mdio@3120/ethernet-p
hy@04
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Generic RTC Driver v1.07
WDT driver for MPC83xx initialized. mode:reset timeout=65535 (32
seconds)
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing
disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 25000K size 1024 blo
cksize
loop: loaded (max 8 devices)
Intel(R) PRO/1000 Network Driver - version 7.3.15-k2
Copyright (c) 1999-2006 Intel Corporation.
UCC Ethernet Controller MII Bus: probed
ucc_geth: QE UCC Gigabit Ethernet Controller
ucc_geth: UCC2 at 0xe0103000 (irq = 21)
eth0: MTU=1500 (frame size=1518,rx_buffer_size=1536,truesize=178
4,sk_buff=152)
ucc_geth: UCC3 at 0xe0102200 (irq = 34)
eth1: MTU=1500 (frame size=1518,rx_buffer_size=1536,truesize=178
4,sk_buff=152)
SKB Handler initialized(max=64)
ICPlus IP175C: Registered new driver
usbmon: debugfs is not available
ehci_hcd 0000:00:10.1: EHCI Host Controller
ehci_hcd 0000:00:10.1: new USB bus registered, assigned bus numb
er 1
ehci_hcd 0000:00:10.1: irq 19, io mem 0x90001000
ehci_hcd 0000:00:10.1: USB 2.0 started, EHCI 1.00, driver 10 Dec
2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
ohci_hcd 0000:00:10.0: OHCI Host Controller
ohci_hcd 0000:00:10.0: new USB bus registered, assigned bus numb
er 2
ohci_hcd 0000:00:10.0: irq 19, io mem 0x90000000
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
i2c /dev entries driver
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
RAMDISK: Compressed image found at block 0
Time: timebase clocksource has been installed.
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 136k init
Setting the hostname to freescale
Mounting filesystems
Setting up networking on loopback device:
Setting up networking on eth1:
udhcpc (v0.9.9-pre) started
udhcpc[725]: udhcpc (v0.9.9-pre) started
Sending discover...
udhcpc[725]: Sending discover...
PHY: e0103120:04 - Link is Up - 100/Full
Sending discover...
udhcpc[725]: Sending discover...
Sending select for 192.168.0.206...
udhcpc[725]: Sending select for 192.168.0.206...
Lease of 192.168.0.206 obtained, lease time 3600
udhcpc[725]: Lease of 192.168.0.206 obtained, lease time 3600
deleting routers
SIOCDELRT: No such process
adding dns 192.168.1.10
adding dns 192.168.1.9
adding dns 194.204.159.1
Setting up networking on eth0:
Adding static route for default gateway to 192.168.2.1:
Setting nameserver to 192.168.2.1 in /etc/resolv.conf:
Starting the boa webserver:
/sbin/ip
Starting dhcpd
Internet Systems Consortium DHCP Server V3.0.3b1
Copyright 2004-2005 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
Wrote 0 deleted host decls to leases file.
Wrote 0 new dynamic host decls to leases file.
Wrote 0 leases to leases file.
Listening on LPF/eth0/00:04:9f:ef:03:02/192.168.2/24
Sending on LPF/eth0/00:04:9f:ef:03:02/192.168.2/24
Sending on Socket/fallback/fallback-net
Done
PHY: e0103120:00 - Link is Up - 100/Full
Welcome to Freescale Semiconductor Embedded Linux Environment
^ permalink raw reply
* RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Pravin Bathija @ 2009-09-11 9:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Andrea Zypchen, lebon, Prodyut Hazarika, tburns, Stefan Roese,
linuxppc-dev, azilkie
In-Reply-To: <1252647621.8566.67.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 737 bytes --]
Benjamin Herrenschmidt wrote:
> Do you know many drivers that do config space accesses without using
> the config space accessors ?
> Such drivers should be banned to oblivion.
> Cheers,
> Ben.
I'm not aware of such drivers in the 2.6.30+ kernel.
Thanks,
Pravin
On Thu, 2009-09-10 at 22:35 -0700, Pravin Bathija wrote:
> Thanks Stefan. The whole intention of the patch/hack (or whatever one
> might call it :) ) was to avoid rogue drivers from setting
> pci_cache_line_size to non-zero value even though the underlying
> hardware doesn't support MRM calls. Nonetheless this approach works
> only if the drivers use the kernel API for PCI config space access
> provided by the powerpc platform driver.
>
[-- Attachment #2: Type: text/html, Size: 1544 bytes --]
^ permalink raw reply
* Re: RMO ? (in the prom_init.c)
From: Benjamin Herrenschmidt @ 2009-09-11 7:39 UTC (permalink / raw)
To: HongWoo Lee; +Cc: linuxppc-dev list
In-Reply-To: <4AA9EF51.1050506@gmail.com>
On Fri, 2009-09-11 at 15:33 +0900, HongWoo Lee wrote:
> Hi ~
>
> Can anybody tell me what the RMO is ?? in the linux kernel.
> (arch/powerpc/kernel/prom_init.c)
> Through googling and guessing, I found "Read Memory Only" and "Relaxed
> Memory Order".
> But none of these are not properly understood in the context.
It's actually a bad name and should probably be "RMA" , aka Real Mode
Area.
This is a "feature" of the POWER architecture for servers, when running
under a hypervisor. Not all of memory can be accessed when the processor
is in "real mode" (MSR:IR and/or DR off).
The reason is obvious, since the OS doesn't have access to real memory
but virtualized logical addresses. And since all of the virtualization
normally goes through the MMU hash table, "real mode" accesses that
bypass the hash table are problematic to allow in an OS.
The "solution" used by those processors is to have a HW feature that
allows a chunk of physical memory to be made accessible to the partition
in "real" mode, which is called the RMA.
That means in practice that the kernel can only access that portion of
it's logical address space while in real mode, it needs to use
translations in the hash table to access the whole of it.
The value in prom_init.c is used to constrain some allocations to that
range for things that will be accessed while running in real mode (such
as RTAS), though it's also abused to constrain those allocations to a
subset of memory even without hypervisors to work around things like
firmware bugs etc...
Cheers,
Ben.
^ permalink raw reply
* Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Benjamin Herrenschmidt @ 2009-09-11 7:31 UTC (permalink / raw)
To: Mikhail Zolotaryov
Cc: Prodyut Hazarika, tburns, Andrea Zypchen, linuxppc-dev, azilkie
In-Reply-To: <4AA9F98E.2010800@lebon.org.ua>
On Fri, 2009-09-11 at 10:17 +0300, Mikhail Zolotaryov wrote:
> Benjamin Herrenschmidt wrote:
> > On Wed, 2009-09-09 at 17:40 +0300, Mikhail Zolotaryov wrote:
> >
> >> Hi Tom,
> >>
> >> In my case __dma_sync() calls flush_dcache_range() (it's due to
> >> alignment) from a tasklet - no OOPS. It uses dcbf instruction instead of
> >> dcbi - that's the difference as dcbf is not privileged.
> >>
> >
> > What it calls depends on the direction of the transfer.
> Would not agree with you in this point as __dma_sync() code is:
Well, it -does- depend on the direction of the transfer... and -also- on
the size & alignement :-)
Anyway, that is probably not the problem. From the log I've seen, it
just looks like a page fault due to a bad virtual address passed there.
Cheers,
Ben.
> case DMA_FROM_DEVICE:
> /*
> * invalidate only when cache-line aligned otherwise
> there is
> * the potential for discarding uncommitted data from
> the cache
> */
> if ((start & (L1_CACHE_BYTES - 1)) || (size &
> (L1_CACHE_BYTES - 1)))
> flush_dcache_range(start, end);
> else
> invalidate_dcache_range(start, end);
> break;
>
> So, actual instruction used depends on address/size alignment.
>
> > The tasklet runs
> > in priviledged mode, dcbi should work just fine... if passed a correct
> > address :-)
> >
> > Cheers,
> > Ben.
> >
> >
> >> Tom Burns wrote:
> >>
> >>> Hi Mikhail,
> >>>
> >>> Sorry, this DMA code is in a tasklet. Are you suggesting the
> >>> processor is in supervisor mode at that time? Calling
> >>> pci_dma_sync_sg_for_cpu() from the tasklet context is what generates
> >>> the OOPS. The entire oops is as follows, if it's relevant:
> >>>
> >>> Oops: kernel access of bad area, sig: 11 [#1]
> >>> NIP: c0003ab0 LR: c0010c30 CTR: 02400001
> >>> REGS: df117bd0 TRAP: 0300 Tainted: P (2.6.24.2)
> >>> MSR: 00029000 <EE,ME> CR: 44224042 XER: 20000000
> >>> DEAR: 3fd39000, ESR: 00800000
> >>> TASK = de5db7d0[157] 'cat' THREAD: df116000
> >>> GPR00: e11e5854 df117c80 de5db7d0 3fd39000 02400001 0000001f 00000002
> >>> 0079a169
> >>> GPR08: 00000001 c0310000 00000000 c0010c84 24224042 101c0dac c0310000
> >>> 10177000
> >>> GPR16: deb14200 df116000 e12062d0 e11f6104 de0f16c0 e11f0000 c0310000
> >>> e11f59cc
> >>> GPR24: e11f62d0 e11f0000 e11f0000 00000000 00000002 defee014 3fd39008
> >>> 87d39009
> >>> NIP [c0003ab0] invalidate_dcache_range+0x1c/0x30
> >>> LR [c0010c30] __dma_sync+0x58/0xac
> >>> Call Trace:
> >>> [df117c80] [0000000a] 0xa (unreliable)
> >>> [df117c90] [e11e5854] DoTasklet+0x67c/0xc90 [ideDriverDuo_cyph]
> >>> [df117ce0] [c001ee24] tasklet_action+0x60/0xcc
> >>> [df117cf0] [c001ef04] __do_softirq+0x74/0xe0
> >>> [df117d10] [c00067a8] do_softirq+0x54/0x58
> >>> [df117d20] [c001edb4] irq_exit+0x48/0x58
> >>> [df117d30] [c00069d0] do_IRQ+0x6c/0xc0
> >>> [df117d40] [c00020e0] ret_from_except+0x0/0x18
> >>> [df117e00] [c00501e0] unmap_vmas+0x2c4/0x560
> >>> [df117e90] [c0053ebc] exit_mmap+0x64/0xec
> >>> [df117ec0] [c00171ac] mmput+0x50/0xd4
> >>> [df117ed0] [c001aef8] exit_mm+0x80/0xe0
> >>> [df117ef0] [c001c818] do_exit+0x134/0x6f8
> >>> [df117f30] [c001ce14] do_group_exit+0x38/0x74
> >>> [df117f40] [c0001a80] ret_from_syscall+0x0/0x3c
> >>> Instruction dump:
> >>> 7c0018ac 38630020 4200fff8 7c0004ac 4e800020 38a0001f 7c632878 7c832050
> >>> 7c842a14 5484d97f 4d820020 7c8903a6 <7c001bac> 38630020 4200fff8
> >>> 7c0004ac
> >>> Kernel panic - not syncing: Aiee, killing interrupt handler!
> >>> Rebooting in 180 seconds..
> >>>
> >>>
> >>> Cheers,
> >>> Tom
> >>>
> >>> Mikhail Zolotaryov wrote:
> >>>
> >>>> Hi Tom,
> >>>>
> >>>> possible solution could be to use tasklet to perform DMA-related job
> >>>> (as in most cases DMA transfer is interrupt driven - makes sense).
> >>>>
> >>>>
> >>>> Tom Burns wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> With the default config for the Sequoia board on 2.6.24, calling
> >>>>> pci_dma_sync_sg_for_cpu() results in executing
> >>>>> invalidate_dcache_range() in arch/ppc/kernel/misc.S from
> >>>>> __dma_sync(). This OOPses on PPC440 since it tries to call directly
> >>>>> the assembly instruction dcbi, which can only be executed in
> >>>>> supervisor mode. We tried that before resorting to manual cache
> >>>>> line management with usermode-safe assembly calls.
> >>>>>
> >>>>> Regards,
> >>>>> Tom Burns
> >>>>> International Datacasting Corporation
> >>>>>
> >>>>> Mikhail Zolotaryov wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> Why manage cache lines manually, if appropriate code is a part of
> >>>>>> __dma_sync / dma_sync_single_for_device of DMA API ? (implies
> >>>>>> CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
> >>>>>>
> >>>>>> Prodyut Hazarika wrote:
> >>>>>>
> >>>>>>> Hi Adam,
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Yes, I am using the 440EPx (same as the sequoia board). Our
> >>>>>>>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
> >>>>>>>>
> >>>>>>>>
> >>>>>>> (using
> >>>>>>>
> >>>>>>>
> >>>>>>>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on
> >>>>>>>> timing)
> >>>>>>>> end up being partially corrupted when we try to parse the data in
> >>>>>>>> the
> >>>>>>>> virtual page. We have confirmed the data is good before the PCI-IDE
> >>>>>>>> bridge. We are creating two 8K pages and map them to physical DMA
> >>>>>>>>
> >>>>>>>>
> >>>>>>> memory
> >>>>>>>
> >>>>>>>
> >>>>>>>> using single-entry scatter/gather structs. When a DMA block is
> >>>>>>>> corrupted, we see a random portion of it (always a multiple of
> >>>>>>>> 16byte
> >>>>>>>> cache lines) is overwritten with old data from the last time the
> >>>>>>>>
> >>>>>>>>
> >>>>>>> buffer
> >>>>>>>
> >>>>>>>
> >>>>>>>> was used.
> >>>>>>>>
> >>>>>>> This looks like a cache coherency problem.
> >>>>>>> Can you ensure that the TLB entries corresponding to the DMA
> >>>>>>> region has
> >>>>>>> the CacheInhibit bit set.
> >>>>>>> You will need a BDI connected to your system.
> >>>>>>>
> >>>>>>> Also, you will need to invalidate and flush the lines appropriately,
> >>>>>>> since in 440 cores,
> >>>>>>> L1Cache coherency is managed entirely by software.
> >>>>>>> Please look at drivers/net/ibm_newemac/mal.c and core.c for
> >>>>>>> example on
> >>>>>>> how to do it.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>> Prodyut
> >>>>>>>
> >>>>>>> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>> Hi Adam,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Are you sure there is L2 cache on the 440?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
> >>>>>>>>
> >>>>>>>>
> >>>>>>> board)
> >>>>>>>
> >>>>>>>
> >>>>>>>> have L2Cache.
> >>>>>>>> It seems you are using a Sequoia board, which has a 440EPx SoC.
> >>>>>>>> 440EPx
> >>>>>>>> has a 440 cpu core, but no L2Cache.
> >>>>>>>> Could you please tell me which SoC you are using?
> >>>>>>>> You can also refer to the appropriate dts file to see if there is
> >>>>>>>> L2C.
> >>>>>>>> For example, in canyonlands.dts (460EX based board), we have the L2C
> >>>>>>>> entry.
> >>>>>>>> L2C0: l2c {
> >>>>>>>> ...
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> I am seeing this problem with our custom IDE driver which is
> >>>>>>>>> based on
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>> pretty old code. Our driver uses pci_alloc_consistent() to allocate
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>> the
> >>>>>>>
> >>>>>>>
> >>>>>>>>> physical DMA memory and alloc_pages() to allocate a virtual
> >>>>>>>>> page. It then uses pci_map_sg() to map to a scatter/gather
> >>>>>>>>> buffer. Perhaps I should convert these to the DMA API calls as
> >>>>>>>>> you suggest.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> Could you give more details on the consistency problem? It is a good
> >>>>>>>> idea to change to the new DMA APIs, but pci_alloc_consistent()
> >>>>>>>> should
> >>>>>>>> work too
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>> Prodyut On Thu, 2009-09-03 at 19:57 +1000, Benjamin
> >>>>>>>> Herrenschmidt wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Hi Adam,
> >>>>>>>>>>
> >>>>>>>>>> If you have a look in include/asm-ppc/pgtable.h for the following
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> section:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> #ifdef CONFIG_44x
> >>>>>>>>>> #define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED |
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> _PAGE_GUARDED)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> #else
> >>>>>>>>>> #define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED)
> >>>>>>>>>> #endif
> >>>>>>>>>>
> >>>>>>>>>> Try adding _PAGE_COHERENT to the appropriate line above and see if
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> that
> >>>>>>>>
> >>>>>>>>>> fixes your issue - this causes the 'M' bit to be set on the page
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> which
> >>>>>>>>
> >>>>>>>>>> sure enforce cache coherency. If it doesn't, you'll need to check
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> the
> >>>>>>>>
> >>>>>>>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> masked
> >>>>>>>>
> >>>>>>>>>> out on arch/powerpc, but was fixed in later kernels when the cache
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> coherency issues with non-SMP systems were resolved).
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> I have some doubts about the usefulness of doing that for 4xx.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>> AFAIK,
> >>>>>>>
> >>>>>>>
> >>>>>>>>> the 440 core just ignores M.
> >>>>>>>>>
> >>>>>>>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> isn't
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> enabled or not working ?
> >>>>>>>>>
> >>>>>>>>> The L1 cache on 440 is simply not coherent, so drivers have to make
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> sure
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> they use the appropriate DMA APIs which will do cache flushing when
> >>>>>>>>> needed.
> >>>>>>>>>
> >>>>>>>>> Adam, what driver is causing you that sort of problems ?
> >>>>>>>>>
> >>>>>>>>> Cheers,
> >>>>>>>>> Ben.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >> _______________________________________________
> >> Linuxppc-dev mailing list
> >> Linuxppc-dev@lists.ozlabs.org
> >> https://lists.ozlabs.org/listinfo/linuxppc-dev
> >>
> >
> >
^ permalink raw reply
* Re: Debian on MPC8572DS
From: Isaac Gomez Morales @ 2009-09-11 7:30 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20090910163244.GA24878@b07421-ec1.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 780 bytes --]
Hello,
I'll try the "linutronix-lenny-gnuspe/" distro option, because i prefer a
option without a fp emulation.
Thanks u all.
2009/9/10 Scott Wood <scottwood@freescale.com>
> On Thu, Sep 10, 2009 at 05:01:53PM +0200, Isaac Gomez Morales wrote:
> > Hello,
> >
> > I'm trying to get a Linux distro such as Debian in the following system
> >
> > System:
> > mpc8572ds HW
>
> The 8572 does not have classic PowerPC floating point. The Debian
> binaries use this, so they cannot run without emulation.
>
> Emulation is slow, so you probably want something like this instead:
>
> http://groups.google.com/group/linux.debian.ports.powerpc/browse_thread/thread/235607517fd7ae1e/f4638a2cdef09bf7?lnk=raot
> http://download.breakpoint.cc/debian/linutronix-lenny-gnuspe/
>
> -Scott
>
[-- Attachment #2: Type: text/html, Size: 1443 bytes --]
^ permalink raw reply
* Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Mikhail Zolotaryov @ 2009-09-11 7:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Prodyut Hazarika, tburns, Andrea Zypchen, linuxppc-dev, azilkie
In-Reply-To: <1252634270.8566.14.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Wed, 2009-09-09 at 17:40 +0300, Mikhail Zolotaryov wrote:
>
>> Hi Tom,
>>
>> In my case __dma_sync() calls flush_dcache_range() (it's due to
>> alignment) from a tasklet - no OOPS. It uses dcbf instruction instead of
>> dcbi - that's the difference as dcbf is not privileged.
>>
>
> What it calls depends on the direction of the transfer.
Would not agree with you in this point as __dma_sync() code is:
case DMA_FROM_DEVICE:
/*
* invalidate only when cache-line aligned otherwise
there is
* the potential for discarding uncommitted data from
the cache
*/
if ((start & (L1_CACHE_BYTES - 1)) || (size &
(L1_CACHE_BYTES - 1)))
flush_dcache_range(start, end);
else
invalidate_dcache_range(start, end);
break;
So, actual instruction used depends on address/size alignment.
> The tasklet runs
> in priviledged mode, dcbi should work just fine... if passed a correct
> address :-)
>
> Cheers,
> Ben.
>
>
>> Tom Burns wrote:
>>
>>> Hi Mikhail,
>>>
>>> Sorry, this DMA code is in a tasklet. Are you suggesting the
>>> processor is in supervisor mode at that time? Calling
>>> pci_dma_sync_sg_for_cpu() from the tasklet context is what generates
>>> the OOPS. The entire oops is as follows, if it's relevant:
>>>
>>> Oops: kernel access of bad area, sig: 11 [#1]
>>> NIP: c0003ab0 LR: c0010c30 CTR: 02400001
>>> REGS: df117bd0 TRAP: 0300 Tainted: P (2.6.24.2)
>>> MSR: 00029000 <EE,ME> CR: 44224042 XER: 20000000
>>> DEAR: 3fd39000, ESR: 00800000
>>> TASK = de5db7d0[157] 'cat' THREAD: df116000
>>> GPR00: e11e5854 df117c80 de5db7d0 3fd39000 02400001 0000001f 00000002
>>> 0079a169
>>> GPR08: 00000001 c0310000 00000000 c0010c84 24224042 101c0dac c0310000
>>> 10177000
>>> GPR16: deb14200 df116000 e12062d0 e11f6104 de0f16c0 e11f0000 c0310000
>>> e11f59cc
>>> GPR24: e11f62d0 e11f0000 e11f0000 00000000 00000002 defee014 3fd39008
>>> 87d39009
>>> NIP [c0003ab0] invalidate_dcache_range+0x1c/0x30
>>> LR [c0010c30] __dma_sync+0x58/0xac
>>> Call Trace:
>>> [df117c80] [0000000a] 0xa (unreliable)
>>> [df117c90] [e11e5854] DoTasklet+0x67c/0xc90 [ideDriverDuo_cyph]
>>> [df117ce0] [c001ee24] tasklet_action+0x60/0xcc
>>> [df117cf0] [c001ef04] __do_softirq+0x74/0xe0
>>> [df117d10] [c00067a8] do_softirq+0x54/0x58
>>> [df117d20] [c001edb4] irq_exit+0x48/0x58
>>> [df117d30] [c00069d0] do_IRQ+0x6c/0xc0
>>> [df117d40] [c00020e0] ret_from_except+0x0/0x18
>>> [df117e00] [c00501e0] unmap_vmas+0x2c4/0x560
>>> [df117e90] [c0053ebc] exit_mmap+0x64/0xec
>>> [df117ec0] [c00171ac] mmput+0x50/0xd4
>>> [df117ed0] [c001aef8] exit_mm+0x80/0xe0
>>> [df117ef0] [c001c818] do_exit+0x134/0x6f8
>>> [df117f30] [c001ce14] do_group_exit+0x38/0x74
>>> [df117f40] [c0001a80] ret_from_syscall+0x0/0x3c
>>> Instruction dump:
>>> 7c0018ac 38630020 4200fff8 7c0004ac 4e800020 38a0001f 7c632878 7c832050
>>> 7c842a14 5484d97f 4d820020 7c8903a6 <7c001bac> 38630020 4200fff8
>>> 7c0004ac
>>> Kernel panic - not syncing: Aiee, killing interrupt handler!
>>> Rebooting in 180 seconds..
>>>
>>>
>>> Cheers,
>>> Tom
>>>
>>> Mikhail Zolotaryov wrote:
>>>
>>>> Hi Tom,
>>>>
>>>> possible solution could be to use tasklet to perform DMA-related job
>>>> (as in most cases DMA transfer is interrupt driven - makes sense).
>>>>
>>>>
>>>> Tom Burns wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> With the default config for the Sequoia board on 2.6.24, calling
>>>>> pci_dma_sync_sg_for_cpu() results in executing
>>>>> invalidate_dcache_range() in arch/ppc/kernel/misc.S from
>>>>> __dma_sync(). This OOPses on PPC440 since it tries to call directly
>>>>> the assembly instruction dcbi, which can only be executed in
>>>>> supervisor mode. We tried that before resorting to manual cache
>>>>> line management with usermode-safe assembly calls.
>>>>>
>>>>> Regards,
>>>>> Tom Burns
>>>>> International Datacasting Corporation
>>>>>
>>>>> Mikhail Zolotaryov wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Why manage cache lines manually, if appropriate code is a part of
>>>>>> __dma_sync / dma_sync_single_for_device of DMA API ? (implies
>>>>>> CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
>>>>>>
>>>>>> Prodyut Hazarika wrote:
>>>>>>
>>>>>>> Hi Adam,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Yes, I am using the 440EPx (same as the sequoia board). Our
>>>>>>>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
>>>>>>>>
>>>>>>>>
>>>>>>> (using
>>>>>>>
>>>>>>>
>>>>>>>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on
>>>>>>>> timing)
>>>>>>>> end up being partially corrupted when we try to parse the data in
>>>>>>>> the
>>>>>>>> virtual page. We have confirmed the data is good before the PCI-IDE
>>>>>>>> bridge. We are creating two 8K pages and map them to physical DMA
>>>>>>>>
>>>>>>>>
>>>>>>> memory
>>>>>>>
>>>>>>>
>>>>>>>> using single-entry scatter/gather structs. When a DMA block is
>>>>>>>> corrupted, we see a random portion of it (always a multiple of
>>>>>>>> 16byte
>>>>>>>> cache lines) is overwritten with old data from the last time the
>>>>>>>>
>>>>>>>>
>>>>>>> buffer
>>>>>>>
>>>>>>>
>>>>>>>> was used.
>>>>>>>>
>>>>>>> This looks like a cache coherency problem.
>>>>>>> Can you ensure that the TLB entries corresponding to the DMA
>>>>>>> region has
>>>>>>> the CacheInhibit bit set.
>>>>>>> You will need a BDI connected to your system.
>>>>>>>
>>>>>>> Also, you will need to invalidate and flush the lines appropriately,
>>>>>>> since in 440 cores,
>>>>>>> L1Cache coherency is managed entirely by software.
>>>>>>> Please look at drivers/net/ibm_newemac/mal.c and core.c for
>>>>>>> example on
>>>>>>> how to do it.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Prodyut
>>>>>>>
>>>>>>> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Hi Adam,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Are you sure there is L2 cache on the 440?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
>>>>>>>>
>>>>>>>>
>>>>>>> board)
>>>>>>>
>>>>>>>
>>>>>>>> have L2Cache.
>>>>>>>> It seems you are using a Sequoia board, which has a 440EPx SoC.
>>>>>>>> 440EPx
>>>>>>>> has a 440 cpu core, but no L2Cache.
>>>>>>>> Could you please tell me which SoC you are using?
>>>>>>>> You can also refer to the appropriate dts file to see if there is
>>>>>>>> L2C.
>>>>>>>> For example, in canyonlands.dts (460EX based board), we have the L2C
>>>>>>>> entry.
>>>>>>>> L2C0: l2c {
>>>>>>>> ...
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> I am seeing this problem with our custom IDE driver which is
>>>>>>>>> based on
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> pretty old code. Our driver uses pci_alloc_consistent() to allocate
>>>>>>>>>
>>>>>>>>>
>>>>>>> the
>>>>>>>
>>>>>>>
>>>>>>>>> physical DMA memory and alloc_pages() to allocate a virtual
>>>>>>>>> page. It then uses pci_map_sg() to map to a scatter/gather
>>>>>>>>> buffer. Perhaps I should convert these to the DMA API calls as
>>>>>>>>> you suggest.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Could you give more details on the consistency problem? It is a good
>>>>>>>> idea to change to the new DMA APIs, but pci_alloc_consistent()
>>>>>>>> should
>>>>>>>> work too
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Prodyut On Thu, 2009-09-03 at 19:57 +1000, Benjamin
>>>>>>>> Herrenschmidt wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi Adam,
>>>>>>>>>>
>>>>>>>>>> If you have a look in include/asm-ppc/pgtable.h for the following
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> section:
>>>>>>>>
>>>>>>>>
>>>>>>>>>> #ifdef CONFIG_44x
>>>>>>>>>> #define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED |
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> _PAGE_GUARDED)
>>>>>>>>
>>>>>>>>
>>>>>>>>>> #else
>>>>>>>>>> #define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED)
>>>>>>>>>> #endif
>>>>>>>>>>
>>>>>>>>>> Try adding _PAGE_COHERENT to the appropriate line above and see if
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> that
>>>>>>>>
>>>>>>>>>> fixes your issue - this causes the 'M' bit to be set on the page
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> which
>>>>>>>>
>>>>>>>>>> sure enforce cache coherency. If it doesn't, you'll need to check
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> the
>>>>>>>>
>>>>>>>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> masked
>>>>>>>>
>>>>>>>>>> out on arch/powerpc, but was fixed in later kernels when the cache
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>> coherency issues with non-SMP systems were resolved).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> I have some doubts about the usefulness of doing that for 4xx.
>>>>>>>>>
>>>>>>>>>
>>>>>>> AFAIK,
>>>>>>>
>>>>>>>
>>>>>>>>> the 440 core just ignores M.
>>>>>>>>>
>>>>>>>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
>>>>>>>>>
>>>>>>>>>
>>>>>>>> isn't
>>>>>>>>
>>>>>>>>
>>>>>>>>> enabled or not working ?
>>>>>>>>>
>>>>>>>>> The L1 cache on 440 is simply not coherent, so drivers have to make
>>>>>>>>>
>>>>>>>>>
>>>>>>>> sure
>>>>>>>>
>>>>>>>>
>>>>>>>>> they use the appropriate DMA APIs which will do cache flushing when
>>>>>>>>> needed.
>>>>>>>>>
>>>>>>>>> Adam, what driver is causing you that sort of problems ?
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Ben.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>
>
^ permalink raw reply
* [git pull] Please pull powerpc.git next branch
From: Benjamin Herrenschmidt @ 2009-09-11 7:17 UTC (permalink / raw)
To: Linus Torvalds
Cc: linuxppc-dev list, Andrew Morton, Ingo Molnar, Linux Kernel list,
FUJITA Tomonori
Hi Linus !
This is the powerpc batch for 2.6.32.
You will notice a bunch of generic swiotlb changes along with
corresponding changes to arch/sparc and arch/x86 from Fujita Tomonori.
There are due to my tree having pulled Ingo's iommu tree do sort out
various dependencies. If you pull Ingo's first, you'll already have
all these.
I'm happy for you to defer the pulling of my tree until you have those
bits via Ingo if you prefer, and I'll then send a pull request cleared
of that noise.
Among other non-arch/powerpc patches: Some PS3 and PowerMac specific
driver changes (yes, I think we are still the only users of
generic_nvram), some changes to HVC console and that should be it.
Cheers,
Ben.
The following changes since commit e07cccf4046978df10f2e13fe2b99b2f9b3a65db:
Linus Torvalds (1):
Linux 2.6.31-rc9
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next
Anton Blanchard (3):
powerpc: Move 64bit VDSO to improve context switch performance
powerpc: Rearrange SLB preload code
powerpc: Preload application text segment instead of TASK_UNMAPPED_BASE
Anton Vorontsov (7):
powerpc/83xx: Add support for MPC8377E-WLAN boards
powerpc/85xx: Add support for I2C EEPROMs on MPC8548CDS boards
powerpc/83xx: Add eSDHC support for MPC837xE-RDB/WLAN boards
powerpc/85xx: Add eSDHC support for MPC8536DS boards
powerpc/82xx: Fix BCSR bits for MPC8272ADS boards
powerpc/82xx: Add CPM USB Gadget support for MPC8272ADS boards
powerpc/85xx: Add QE USB support for MPC8569E-MDS boards
Arnd Bergmann (1):
dma-ops: Remove flush_write_buffers() in dma-mapping-common.h
Bastian Blank (1):
powerpc: Remove SMP warning from PowerMac cpufreq
Becky Bruce (1):
powerpc: Name xpn & x fields in HW Hash PTE format
Benjamin Herrenschmidt (37):
powerpc: Rename exception.h to exception-64s.h
powerpc: Use names rather than numbers for SPRGs (v2)
powerpc: Remove use of a second scratch SPRG in STAB code
powerpc/mm: Fix definitions of FORCE_MAX_ZONEORDER in Kconfig
powerpc/pmac: Fix PowerSurge SMP IPI allocation
powerpc: Change PACA from SPRG3 to SPRG1
powerpc: Add compat_sys_truncate
powerpc/mm: Fix misplaced #endif in pgtable-ppc64-64k.h
powerpc/of: Remove useless register save/restore when calling OF back
powerpc/mm: Add HW threads support to no_hash TLB management
powerpc/mm: Add opcode definitions for tlbivax and tlbsrx.
powerpc/mm: Add more bit definitions for Book3E MMU registers
powerpc/mm: Add support for early ioremap on non-hash 64-bit processors
powerpc: Modify some ppc_asm.h macros to accomodate 64-bits Book3E
powerpc/mm: Make low level TLB flush ops on BookE take additional args
powerpc/mm: Call mmu_context_init() from ppc64
powerpc: Clean ifdef usage in copy_thread()
powerpc: Move definitions of secondary CPU spinloop to header file
powerpc/mm: Rework & cleanup page table freeing code path
powerpc: Add SPR definitions for new 64-bit BookE
powerpc: Add memory management headers for new 64-bit BookE
powerpc: Add definitions used by exception handling on 64-bit Book3E
powerpc: Add PACA fields specific to 64-bit Book3E processors
powerpc/mm: Move around mmu_gathers definition on 64-bit
powerpc: Add TLB management code for 64-bit Book3E
powerpc/mm: Add support for SPARSEMEM_VMEMMAP on 64-bit Book3E
powerpc: Remaining 64-bit Book3E support
powerpc/mm: Fix encoding of page table cache numbers
Merge commit 'paulus-perf/master' into next
Merge commit 'origin/master' into next
powerpc/mm: Cleanup handling of execute permission
Merge commit 'kumar/next' into next
Merge commit 'tip/iommu-for-powerpc' into next
powerpc: Properly start decrementer on BookE secondary CPUs
powerpc: Fix some late PowerMac G5 with PCIe ATI graphics
powerpc/booke: Don't set DABR on 64-bit BookE, use DAC1 instead
powerpc/iseries: Fix oops reading from /proc/iSeries/mf/*/cmdline
Benjamin Krill (1):
powerpc/prom_init: Evaluate mem kernel parameter for early allocation
Brian King (1):
powerpc/pseries: Fix to handle slb resize across migration
Casey Dahlin (1):
lib/swiotlb.c: Fix strange panic message selection logic when swiotlb fills up
Christoph Hellwig (2):
powerpc/sputrace: Use the generic event tracer
powerpc: Switch to asm-generic/hardirq.h
FUJITA Tomonori (29):
swiotlb: remove unused swiotlb_alloc_boot()
swiotlb: remove unused swiotlb_alloc()
swiotlb: remove swiotlb_arch_range_needs_mapping
swiotlb: remove unnecessary swiotlb_bus_to_virt
x86: add dma_capable() to replace is_buffer_dma_capable()
x86: replace is_buffer_dma_capable() with dma_capable
ia64: add dma_capable() to replace is_buffer_dma_capable()
powerpc: add dma_capable() to replace is_buffer_dma_capable()
swiotlb: use dma_capable()
powerpc: remove unncesary swiotlb_arch_address_needs_mapping
remove is_buffer_dma_capable()
x86, IA64, powerpc: add phys_to_dma() and dma_to_phys()
swiotlb: use phys_to_dma and dma_to_phys
powerpc: remove unused swiotlb_phys_to_bus() and swiotlb_bus_to_phys()
x86: remove unused swiotlb_phys_to_bus() and swiotlb_bus_to_phys()
IA64: Remove NULL flush_write_buffers
sparc: Use dma_map_ops struct
sparc: Use asm-generic/dma-mapping-common.h
sparc: Remove no-op dma_4v_sync_single_for_cpu and dma_4v_sync_sg_for_cpu
sparc: Replace sbus_map_single and sbus_unmap_single with sbus_map_page and sbus_unmap_page
sparc: Use asm-generic/pci-dma-compat
sparc: Add CONFIG_DMA_API_DEBUG support
powerpc: Remove addr_needs_map in struct dma_mapping_ops
powerpc: Remove swiotlb_pci_dma_ops
dma: Add set_dma_mask hook to struct dma_map_ops
powerpc: use dma_map_ops struct
powerpc: Use asm-generic/dma-mapping-common.h
powerpc: Handle SWIOTLB mapping error properly
powerpc: Add CONFIG_DMA_API_DEBUG support
Frans Pop (1):
powerpc: Makefile simplification through use of cc-ifversion
Gautham R Shenoy (1):
powerpc/pseries: Reduce the polling interval in __cpu_up()
Geert Uytterhoeven (1):
powerpc/cell: Move CBE_IOPTE_* to <asm/cell-regs.h>
Geoff Levand (1):
powerpc/ps3: Workaround for flash memory I/O error
Geoff Thorpe (1):
powerpc: expose the multi-bit ops that underlie single-bit ops.
Gerhard Pircher (1):
powerpc/amigaone: Convert amigaone_init() to a machine_device_initcall()
Grant Likely (3):
powerpc/pci: Remove dead checks for CONFIG_PPC_OF
powerpc/pci: move pci_64.c device tree scanning code into pci-common.c
powerpc/pci: Merge ppc32 and ppc64 versions of phb_scan()
Heiko Schocher (2):
powerpc/82xx: mgcoge - updates for 2.6.32
powerpc/82xx: mgcoge - updated defconfig
Josh Boyer (1):
powerpc: Fix __flush_icache_range on 44x
Julia Lawall (5):
powerpc/fsl_rio: Add kmalloc NULL tests
powerpc/ipic: introduce missing kfree
powerpc/qe: introduce missing kfree
hvc_console: Drop unnecessary NULL test
powerpc: Use DIV_ROUND_CLOSEST in time init code
Kumar Gala (14):
powerpc/mm: Fix switch_mmu_context to iterate of the proper list of cpus
powerpc/85xx: Move mpc8536ds.dts to address-cells/size-cells = <2>
powerpc/85xx: Added 36-bit physical device tree for mpc8536ds board
powerpc/mm: Fix assert_pte_locked to work properly on uniprocessor
powerpc/booke: Move MMUCSR definition into mmu-book3e.h
powerpc/mm: Add MMU features for TLB reservation & Paired MAS registers
powerpc/book3e-64: Move the default cpu table entry
powerpc/book3e-64: Wait til generic_calibrate_decr to enable decrementer
powerpc/book3e-64: Add helper function to setup IVORs
powerpc/book3e-64: Add support to initial_tlb_book3e for non-HES TLB
powerpc/pci: Pull ppc32 PCI features into common
powerpc/book3e: Add missing page sizes
powerpc/fsl-booke: Use HW PTE format if CONFIG_PTE_64BIT
powerpc/85xx: Fix SMP compile error and allow NULL for smp_ops
Liang Li (4):
powerpc/83xx: Remove second USB node from SBC834x DTS
powerpc/83xx: Add localbus node and MTD partitions for SBC834x
powerpc/83xx: Fix incorrect PCI interrupt map in SBC834x DTS
powerpc/85xx: sbc8560 - Fix warm reboot with board specific reset function
Lucian Adrian Grijincu (1):
powerpc: Update boot wrapper script with the new location of dtc
Lyonel Vincent (1):
powerpc/powermac: Thermal control turns system off too eagerly
Martyn Welch (5):
powerpc/86xx: Correct reading of information presented in cpuinfo
powerpc/86xx: Enable XMC site on GE Fanuc SBC310
powerpc/86xx: Update GE Fanuc sbc310 DTS
powerpc/nvram: Allow byte length reads from mmio NVRAM driver
powerpc/nvram: Enable use Generic NVRAM driver for different size chips
Michael Barkowski (1):
powerpc/qe_lib: Set gpio data before changing the direction to output
Michael Ellerman (4):
powerpc/mpic: Fix MPIC_BROKEN_REGREAD on non broken MPICs
kmemleak: Allow kmemleak to be built on powerpc
powerpc: Enable GCOV
powerpc/vmlinux.lds: Move _edata down
Michael Wolf (1):
powerpc: Adjust base and index registers in Altivec macros
Michel Dänzer (2):
agp/uninorth: Allow larger aperture sizes on pre-U3 bridges.
agp/uninorth: Simplify cache flushing.
Paul Gortmaker (4):
powerpc/83xx: sbc8349 - update defconfig, enable MTD, USB storage
powerpc/85xx: issue fsl_soc reboot warning only when applicable
powerpc/85xx: sbc8560 - remove "has-rstcr" from global utilities block
powerpc: derive COMMAND_LINE_SIZE from asm-generic
Paul Mackerras (5):
powerpc/32: Always order writes to halves of 64-bit PTEs
powerpc: Allow perf_counters to access user memory at interrupt time
perf_counter: powerpc: Add callchain support
powerpc: Fix bug where perf_counters breaks oprofile
powerpc/perf_counters: Reduce stack usage of power_check_constraints
Peter Huewe (1):
hvc_console: Add __init and __exit to hvc_vio
Poonam Aggrwal (1):
powerpc/85xx: Add support for P2020RDB board
Roel Kluin (2):
powerpc/fsl-booke: read buffer overflow
powerpc/hvsi: Avoid calculating possibly-invalid address
Sebastian Andrzej Siewior (1):
powerpc/ipic: unmask all interrupt sources
Solomon Peachy (1):
powerpc/40x: Add support for the ESTeem 195E (PPC405EP) SBC
Stefan Roese (7):
powerpc: Add AMCC 460EX/460GT Rev. B support to cputable.c
powerpc/44x: Add NAND support to Canyonlands dts
powerpc/40x: Update Kilauea dts to support NAND, RTC and HWMON
powerpc/44x: Update Canyonlands defconfig to support NOR, NAND and RTC
powerpc/40x: Update kilauea defconfig to support NAND, RTC and HWMON
powerpc/44x: Update Arches dts
powerpc/44x: Update Arches defconfig
Stephen Rothwell (1):
powerpc: use consistent types in mktree
Stoyan Gaydarov (1):
powerpc: ARRAY_SIZE changes in pasemi and powermac code
Tiejun Chen (2):
powerpc/405ex: provide necessary fixup function to support cuImage
powerpc/405ex: support cuImage via included dtb
Wolfram Sang (1):
powerpc/irq: Improve nanodoc
fkan@amcc.com (1):
powerpc/44x: Add Eiger AMCC (AppliedMicro) PPC460SX evaluation board support.
roel kluin (3):
powerpc/cell: Replace strncpy by strlcpy
powerpc: Missing tests for NULL after ioremap()
powerpc/macio: Don't the address of an array element before boundchecking
arch/ia64/include/asm/dma-mapping.h | 19 +-
arch/powerpc/Kconfig | 29 +-
arch/powerpc/Makefile | 2 +-
arch/powerpc/boot/4xx.c | 142 +++
arch/powerpc/boot/4xx.h | 1 +
arch/powerpc/boot/Makefile | 6 +-
arch/powerpc/boot/cuboot-hotfoot.c | 142 +++
arch/powerpc/boot/cuboot-kilauea.c | 49 +
arch/powerpc/boot/dcr.h | 4 +-
arch/powerpc/boot/dts/arches.dts | 50 +
arch/powerpc/boot/dts/canyonlands.dts | 49 +-
arch/powerpc/boot/dts/eiger.dts | 421 +++++++
arch/powerpc/boot/dts/gef_sbc310.dts | 64 +-
arch/powerpc/boot/dts/hotfoot.dts | 294 +++++
arch/powerpc/boot/dts/kilauea.dts | 44 +-
arch/powerpc/boot/dts/mgcoge.dts | 53 +
arch/powerpc/boot/dts/mpc8272ads.dts | 8 +
arch/powerpc/boot/dts/mpc8377_rdb.dts | 2 +-
arch/powerpc/boot/dts/mpc8377_wlan.dts | 464 ++++++++
arch/powerpc/boot/dts/mpc8378_rdb.dts | 2 +-
arch/powerpc/boot/dts/mpc8379_rdb.dts | 2 +-
arch/powerpc/boot/dts/mpc8536ds.dts | 40 +-
arch/powerpc/boot/dts/mpc8536ds_36b.dts | 475 ++++++++
arch/powerpc/boot/dts/mpc8548cds.dts | 20 +
arch/powerpc/boot/dts/mpc8569mds.dts | 45 +
arch/powerpc/boot/dts/p2020rdb.dts | 586 +++++++++
arch/powerpc/boot/dts/sbc8349.dts | 60 +-
arch/powerpc/boot/dts/sbc8560.dts | 1 -
arch/powerpc/boot/mktree.c | 10 +-
arch/powerpc/boot/ppcboot-hotfoot.h | 133 +++
arch/powerpc/boot/wrapper | 3 +-
arch/powerpc/configs/40x/kilauea_defconfig | 298 ++++-
arch/powerpc/configs/44x/arches_defconfig | 382 ++++++-
arch/powerpc/configs/44x/canyonlands_defconfig | 350 +++++-
arch/powerpc/configs/44x/eiger_defconfig | 1252 ++++++++++++++++++++
arch/powerpc/configs/83xx/sbc834x_defconfig | 320 +++++-
arch/powerpc/configs/mgcoge_defconfig | 86 ++-
arch/powerpc/configs/mpc85xx_defconfig | 1 +
arch/powerpc/include/asm/bitops.h | 194 +---
arch/powerpc/include/asm/cell-regs.h | 11 +
arch/powerpc/include/asm/cputhreads.h | 16 +
arch/powerpc/include/asm/device.h | 7 +-
arch/powerpc/include/asm/dma-mapping.h | 323 +-----
arch/powerpc/include/asm/exception-64e.h | 205 ++++
.../include/asm/{exception.h => exception-64s.h} | 25 +-
arch/powerpc/include/asm/hardirq.h | 30 +-
arch/powerpc/include/asm/hw_irq.h | 5 +
arch/powerpc/include/asm/iommu.h | 10 -
arch/powerpc/include/asm/irq.h | 7 +-
arch/powerpc/include/asm/machdep.h | 6 +-
arch/powerpc/include/asm/mmu-40x.h | 3 +
arch/powerpc/include/asm/mmu-44x.h | 6 +
arch/powerpc/include/asm/mmu-8xx.h | 3 +
arch/powerpc/include/asm/mmu-book3e.h | 208 +++-
arch/powerpc/include/asm/mmu-hash32.h | 16 +-
arch/powerpc/include/asm/mmu-hash64.h | 22 +-
arch/powerpc/include/asm/mmu.h | 46 +
arch/powerpc/include/asm/mmu_context.h | 15 +-
arch/powerpc/include/asm/nvram.h | 3 +
arch/powerpc/include/asm/paca.h | 23 +-
arch/powerpc/include/asm/page.h | 4 +
arch/powerpc/include/asm/page_64.h | 10 +
arch/powerpc/include/asm/pci-bridge.h | 40 +-
arch/powerpc/include/asm/pci.h | 11 +-
arch/powerpc/include/asm/pgalloc.h | 46 +-
arch/powerpc/include/asm/pgtable-ppc32.h | 9 +-
arch/powerpc/include/asm/pgtable-ppc64-64k.h | 4 +-
arch/powerpc/include/asm/pgtable-ppc64.h | 67 +-
arch/powerpc/include/asm/pgtable.h | 6 +-
arch/powerpc/include/asm/pmc.h | 16 +-
arch/powerpc/include/asm/ppc-opcode.h | 6 +
arch/powerpc/include/asm/ppc-pci.h | 1 -
arch/powerpc/include/asm/ppc_asm.h | 26 +-
arch/powerpc/include/asm/pte-40x.h | 2 +-
arch/powerpc/include/asm/pte-44x.h | 2 +-
arch/powerpc/include/asm/pte-8xx.h | 1 -
arch/powerpc/include/asm/pte-book3e.h | 84 ++
arch/powerpc/include/asm/pte-common.h | 25 +-
arch/powerpc/include/asm/pte-fsl-booke.h | 9 +-
arch/powerpc/include/asm/pte-hash32.h | 1 -
arch/powerpc/include/asm/reg.h | 141 +++-
arch/powerpc/include/asm/reg_booke.h | 50 +-
arch/powerpc/include/asm/setup.h | 2 +-
arch/powerpc/include/asm/smp.h | 10 +
arch/powerpc/include/asm/swiotlb.h | 8 +-
arch/powerpc/include/asm/systbl.h | 4 +-
arch/powerpc/include/asm/tlb.h | 38 +-
arch/powerpc/include/asm/tlbflush.h | 11 +-
arch/powerpc/include/asm/vdso.h | 3 +-
arch/powerpc/kernel/Makefile | 21 +-
arch/powerpc/kernel/asm-offsets.c | 21 +-
arch/powerpc/kernel/cpu_setup_6xx.S | 2 +-
arch/powerpc/kernel/cputable.c | 62 +-
arch/powerpc/kernel/dma-iommu.c | 2 +-
arch/powerpc/kernel/dma-swiotlb.c | 99 +--
arch/powerpc/kernel/dma.c | 13 +-
arch/powerpc/kernel/entry_32.S | 20 +-
arch/powerpc/kernel/entry_64.S | 102 +-
arch/powerpc/kernel/exceptions-64e.S | 1001 ++++++++++++++++
arch/powerpc/kernel/exceptions-64s.S | 97 +-
arch/powerpc/kernel/fpu.S | 2 +-
arch/powerpc/kernel/head_32.S | 40 +-
arch/powerpc/kernel/head_40x.S | 124 +-
arch/powerpc/kernel/head_44x.S | 58 +-
arch/powerpc/kernel/head_64.S | 83 ++-
arch/powerpc/kernel/head_8xx.S | 13 +-
arch/powerpc/kernel/head_booke.h | 50 +-
arch/powerpc/kernel/head_fsl_booke.S | 100 +-
arch/powerpc/kernel/ibmebus.c | 2 +-
arch/powerpc/kernel/lparcfg.c | 3 +
arch/powerpc/kernel/misc_32.S | 7 +
arch/powerpc/kernel/of_platform.c | 2 +-
arch/powerpc/kernel/paca.c | 3 +
arch/powerpc/kernel/pci-common.c | 133 ++-
arch/powerpc/kernel/pci_32.c | 105 +--
arch/powerpc/kernel/pci_64.c | 335 +-----
arch/powerpc/kernel/pci_of_scan.c | 358 ++++++
arch/powerpc/kernel/perf_callchain.c | 527 ++++++++
arch/powerpc/kernel/perf_counter.c | 68 +-
arch/powerpc/kernel/process.c | 16 +-
arch/powerpc/kernel/prom_init.c | 107 ++-
arch/powerpc/kernel/rtas.c | 7 +-
arch/powerpc/kernel/setup_32.c | 8 +
arch/powerpc/kernel/setup_64.c | 34 +-
arch/powerpc/kernel/smp.c | 15 +-
arch/powerpc/kernel/sys_ppc32.c | 12 +
arch/powerpc/kernel/sysfs.c | 3 +
arch/powerpc/kernel/time.c | 33 +-
arch/powerpc/kernel/vdso.c | 7 +-
arch/powerpc/kernel/vdso32/Makefile | 1 +
arch/powerpc/kernel/vdso64/Makefile | 2 +
arch/powerpc/kernel/vector.S | 2 +-
arch/powerpc/kernel/vio.c | 2 +-
arch/powerpc/kernel/vmlinux.lds.S | 8 +-
arch/powerpc/kvm/booke_interrupts.S | 18 +-
arch/powerpc/mm/40x_mmu.c | 4 +-
arch/powerpc/mm/Makefile | 1 +
arch/powerpc/mm/fsl_booke_mmu.c | 2 +-
arch/powerpc/mm/hash_low_32.S | 4 +-
arch/powerpc/mm/hugetlbpage.c | 8 +-
arch/powerpc/mm/init_32.c | 2 -
arch/powerpc/mm/init_64.c | 55 +-
arch/powerpc/mm/mmu_context_nohash.c | 96 +-
arch/powerpc/mm/mmu_decl.h | 37 +-
arch/powerpc/mm/pgtable.c | 179 ++-
arch/powerpc/mm/pgtable_32.c | 2 +-
arch/powerpc/mm/pgtable_64.c | 59 +-
arch/powerpc/mm/slb.c | 83 +-
arch/powerpc/mm/stab.c | 11 +-
arch/powerpc/mm/tlb_hash32.c | 3 +
arch/powerpc/mm/tlb_hash64.c | 20 +-
arch/powerpc/mm/tlb_low_64e.S | 770 ++++++++++++
arch/powerpc/mm/tlb_nohash.c | 268 ++++-
arch/powerpc/mm/tlb_nohash_low.S | 87 ++-
arch/powerpc/platforms/40x/Kconfig | 10 +
arch/powerpc/platforms/40x/ppc40x_simple.c | 3 +-
arch/powerpc/platforms/44x/Kconfig | 12 +
arch/powerpc/platforms/44x/ppc44x_simple.c | 1 +
arch/powerpc/platforms/82xx/mgcoge.c | 69 +-
arch/powerpc/platforms/82xx/mpc8272_ads.c | 22 +-
arch/powerpc/platforms/83xx/Kconfig | 4 +-
arch/powerpc/platforms/83xx/mpc837x_rdb.c | 28 +-
arch/powerpc/platforms/83xx/mpc83xx.h | 4 +
arch/powerpc/platforms/85xx/Kconfig | 9 +
arch/powerpc/platforms/85xx/Makefile | 3 +-
arch/powerpc/platforms/85xx/mpc8536_ds.c | 3 +-
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 3 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 7 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 141 +++
arch/powerpc/platforms/85xx/sbc8560.c | 39 +-
arch/powerpc/platforms/85xx/smp.c | 23 -
arch/powerpc/platforms/86xx/gef_ppc9a.c | 37 +-
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 3 +-
arch/powerpc/platforms/86xx/mpc86xx_smp.c | 1 -
arch/powerpc/platforms/Kconfig.cputype | 38 +-
arch/powerpc/platforms/amigaone/setup.c | 6 +-
arch/powerpc/platforms/cell/Kconfig | 7 -
arch/powerpc/platforms/cell/celleb_setup.c | 3 +-
arch/powerpc/platforms/cell/iommu.c | 2 +-
arch/powerpc/platforms/cell/smp.c | 2 -
arch/powerpc/platforms/cell/spufs/Makefile | 3 +-
arch/powerpc/platforms/cell/spufs/context.c | 1 +
arch/powerpc/platforms/cell/spufs/file.c | 1 +
arch/powerpc/platforms/cell/spufs/sched.c | 2 +
arch/powerpc/platforms/cell/spufs/spufs.h | 5 -
arch/powerpc/platforms/cell/spufs/sputrace.c | 272 -----
arch/powerpc/platforms/cell/spufs/sputrace.h | 39 +
arch/powerpc/platforms/iseries/exception.S | 59 +-
arch/powerpc/platforms/iseries/exception.h | 6 +-
arch/powerpc/platforms/iseries/mf.c | 2 +-
arch/powerpc/platforms/pasemi/idle.c | 2 +-
arch/powerpc/platforms/powermac/cpufreq_32.c | 8 -
arch/powerpc/platforms/powermac/feature.c | 13 +-
arch/powerpc/platforms/powermac/pci.c | 61 +
arch/powerpc/platforms/powermac/smp.c | 2 +-
arch/powerpc/platforms/ps3/mm.c | 2 +-
arch/powerpc/platforms/ps3/system-bus.c | 6 +-
arch/powerpc/platforms/pseries/pci_dlpar.c | 2 +-
arch/powerpc/platforms/pseries/reconfig.c | 9 +-
arch/powerpc/platforms/pseries/setup.c | 4 -
arch/powerpc/platforms/pseries/smp.c | 2 -
arch/powerpc/sysdev/fsl_rio.c | 18 +-
arch/powerpc/sysdev/fsl_soc.c | 6 +-
arch/powerpc/sysdev/ipic.c | 7 +-
arch/powerpc/sysdev/mmio_nvram.c | 32 +
arch/powerpc/sysdev/mpic.c | 13 +-
arch/powerpc/sysdev/qe_lib/gpio.c | 4 +-
arch/powerpc/sysdev/qe_lib/qe_ic.c | 5 +-
arch/powerpc/xmon/Makefile | 2 +
arch/powerpc/xmon/xmon.c | 2 +-
arch/sparc/Kconfig | 2 +
arch/sparc/include/asm/dma-mapping.h | 145 +--
arch/sparc/include/asm/pci.h | 3 +
arch/sparc/include/asm/pci_32.h | 105 --
arch/sparc/include/asm/pci_64.h | 88 --
arch/sparc/kernel/Makefile | 2 +-
arch/sparc/kernel/dma.c | 175 +---
arch/sparc/kernel/dma.h | 14 -
arch/sparc/kernel/iommu.c | 20 +-
arch/sparc/kernel/ioport.c | 190 ++--
arch/sparc/kernel/pci.c | 2 +-
arch/sparc/kernel/pci_sun4v.c | 30 +-
arch/x86/include/asm/dma-mapping.h | 18 +
arch/x86/kernel/pci-dma.c | 2 +-
arch/x86/kernel/pci-gart_64.c | 5 +-
arch/x86/kernel/pci-nommu.c | 29 +-
arch/x86/kernel/pci-swiotlb.c | 25 -
drivers/block/ps3vram.c | 2 +-
drivers/char/agp/uninorth-agp.c | 49 +-
drivers/char/generic_nvram.c | 27 +-
drivers/char/hvc_console.c | 2 -
drivers/char/hvc_vio.c | 4 +-
drivers/char/hvsi.c | 3 +-
drivers/macintosh/macio_asic.c | 6 +-
drivers/macintosh/therm_windtunnel.c | 4 +-
drivers/ps3/ps3stor_lib.c | 65 +-
drivers/video/ps3fb.c | 2 +-
include/asm-generic/dma-mapping-common.h | 6 -
include/linux/dma-mapping.h | 6 +-
include/linux/pci_ids.h | 1 +
include/linux/swiotlb.h | 11 -
kernel/gcov/Kconfig | 2 +-
lib/Kconfig.debug | 2 +-
lib/swiotlb.c | 124 +--
244 files changed, 12124 insertions(+), 3266 deletions(-)
create mode 100644 arch/powerpc/boot/cuboot-hotfoot.c
create mode 100644 arch/powerpc/boot/cuboot-kilauea.c
create mode 100644 arch/powerpc/boot/dts/eiger.dts
create mode 100644 arch/powerpc/boot/dts/hotfoot.dts
create mode 100644 arch/powerpc/boot/dts/mpc8377_wlan.dts
create mode 100644 arch/powerpc/boot/dts/mpc8536ds_36b.dts
create mode 100644 arch/powerpc/boot/dts/p2020rdb.dts
create mode 100644 arch/powerpc/boot/ppcboot-hotfoot.h
create mode 100644 arch/powerpc/configs/44x/eiger_defconfig
create mode 100644 arch/powerpc/include/asm/exception-64e.h
rename arch/powerpc/include/asm/{exception.h => exception-64s.h} (94%)
create mode 100644 arch/powerpc/include/asm/pte-book3e.h
create mode 100644 arch/powerpc/kernel/exceptions-64e.S
create mode 100644 arch/powerpc/kernel/pci_of_scan.c
create mode 100644 arch/powerpc/kernel/perf_callchain.c
create mode 100644 arch/powerpc/mm/tlb_low_64e.S
create mode 100644 arch/powerpc/platforms/85xx/mpc85xx_rdb.c
delete mode 100644 arch/powerpc/platforms/cell/spufs/sputrace.c
create mode 100644 arch/powerpc/platforms/cell/spufs/sputrace.h
delete mode 100644 arch/sparc/kernel/dma.h
^ permalink raw reply
* Re: [RESEND][PATCH] sata_fsl: hard and soft reset split
From: Jeff Garzik @ 2009-09-11 6:37 UTC (permalink / raw)
To: ashish kalra; +Cc: linux-ide, linuxppc-dev
In-Reply-To: <Pine.WNT.4.64.0906291854180.2640@B00888-02.fsl.freescale.net>
On 06/29/2009 09:26 AM, ashish kalra wrote:
> Split sata_fsl_softreset() into hard and soft resets to make
> error-handling more efficient & device and PMP detection more reliable.
>
> Also includes fix for PMP support, driver tested with Sil3726, Sil4726 &
> Exar PMP controllers.
>
> Signed-off-by: Ashish Kalra <Ashish.Kalra@freescale.com>
can you rediff this and 'AN' support against latest upstream?
^ permalink raw reply
* RMO ? (in the prom_init.c)
From: HongWoo Lee @ 2009-09-11 6:33 UTC (permalink / raw)
To: linuxppc-dev list
Hi ~
Can anybody tell me what the RMO is ?? in the linux kernel.
(arch/powerpc/kernel/prom_init.c)
Through googling and guessing, I found "Read Memory Only" and "Relaxed
Memory Order".
But none of these are not properly understood in the context.
Thanks in advance.
HongWoo.
^ permalink raw reply
* RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Benjamin Herrenschmidt @ 2009-09-11 5:40 UTC (permalink / raw)
To: Pravin Bathija
Cc: Andrea Zypchen, lebon, Prodyut Hazarika, tburns, Stefan Roese,
linuxppc-dev, azilkie
In-Reply-To: <9D1E2BDCB5C57B46B56E6D80843439EB0580C926@SDCEXCHANGE01.ad.amcc.com>
On Thu, 2009-09-10 at 22:35 -0700, Pravin Bathija wrote:
> Thanks Stefan. The whole intention of the patch/hack (or whatever one
> might call it :) ) was to avoid rogue drivers from setting
> pci_cache_line_size to non-zero value even though the underlying
> hardware doesn't support MRM calls. Nonetheless this approach works
> only if the drivers use the kernel API for PCI config space access
> provided by the powerpc platform driver.
>
Do you know many drivers that do config space accesses without using
the config space accessors ?
Such drivers should be banned to oblivion.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc/iseries: Fix oops reading from /proc/iSeries/mf/*/cmdline
From: Benjamin Herrenschmidt @ 2009-09-11 5:37 UTC (permalink / raw)
To: linuxppc-dev list
That code uses dma_mapping_error() with a NULL device, which is
a bad idea :-) The proper fix might be to start using some kind
of pseudo device for all these low level mappings with the
hypervisor but that will be for another day. Since it directly
calls into the low level iommu code, I see no problem in having
it directly test against DMA_ERROR_CODE instead of using the
accessors with a NULL argument for now.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/platforms/iseries/mf.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/iseries/mf.c b/arch/powerpc/platforms/iseries/mf.c
index fef4d51..0d9343d 100644
--- a/arch/powerpc/platforms/iseries/mf.c
+++ b/arch/powerpc/platforms/iseries/mf.c
@@ -872,7 +872,7 @@ static int proc_mf_dump_cmdline(char *page, char **start, off_t off,
count = 256 - off;
dma_addr = iseries_hv_map(page, off + count, DMA_FROM_DEVICE);
- if (dma_mapping_error(NULL, dma_addr))
+ if (dma_addr == DMA_ERROR_CODE)
return -ENOMEM;
memset(page, 0, off + count);
memset(&vsp_cmd, 0, sizeof(vsp_cmd));
--
1.6.1.2.14.gf26b5
^ permalink raw reply related
* RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Pravin Bathija @ 2009-09-11 5:35 UTC (permalink / raw)
To: Stefan Roese, linuxppc-dev
Cc: Andrea Zypchen, lebon, Prodyut Hazarika, tburns, azilkie
In-Reply-To: <200909110725.36208.sr@denx.de>
[-- Attachment #1: Type: text/plain, Size: 939 bytes --]
> Stefan Roese wrote:
> Correct. IIRC, some PATA driver as Pravin already mentioned.
> Cheers,
> Stefan
Thanks Stefan. The whole intention of the patch/hack (or whatever one might call it :) ) was to avoid rogue drivers from setting pci_cache_line_size to non-zero value even though the underlying hardware doesn't support MRM calls. Nonetheless this approach works only if the drivers use the kernel API for PCI config space access provided by the powerpc platform driver.
Regards,
Pravin
On Friday 11 September 2009 07:17:50 Benjamin Herrenschmidt wrote:
> On Fri, 2009-09-11 at 07:12 +0200, Stefan Roese wrote:
> > It's already there. See commit:
> >
> > 5ce4b59653b2c2053cd9a011918ac1e4747f24cc
> >
> > powerpc/4xx: Workaround for PPC440EPx/GRx PCI_28 Errata
>
> Ok, that's another way to do it. Will catch nasty drivers who
> try to write directly rather than clear pci_cache_line_size I suppose...
[-- Attachment #2: Type: text/html, Size: 1486 bytes --]
^ permalink raw reply
* Re: How to access DCR registers in powerpc440gx? Got err when use macro def in Linux kernel
From: David Gibson @ 2009-09-11 5:31 UTC (permalink / raw)
To: g r1x; +Cc: linuxppc-dev
In-Reply-To: <8abf57fa0909102114hf935c21h5dd727ba2a9a4825@mail.gmail.com>
On Fri, Sep 11, 2009 at 12:14:55PM +0800, g r1x wrote:
> Now, I'm writing a DMA driver on powerpc
> 440gx platform(2.6.26.5), as the only way to set up DMA Controller is
> to access it's dcr registers with 'mfdcr' and 'mtdcr'.
>
> I've found some dma code in Linux kernel 2.6.26.5, so I copy the code
> u wrote to my driver module directory, and include them, but when I
> compile my driver, gcc complains following err messages:
[snip]
> #define mfdcr(rn) \
> ({ \
> unsigned long rval; \
> asm volatile("mfdcr %0,%1" : "=r"(rval) : "i"(rn)); \
> rval; \
> })
This form of mfdcr macro will only work when passed a constant DCR
number. That's a limitation in the actual CPU implementation of the
mfdcr instruction (the DCR number is part of the instruction opcode).
Some newer cores have an indirect for of mfdcr which allows the DCR
number to be specified in a register, but I don't know if 440gx is one
of them.
In current kernels we have some DCR macros that use a big table of
pre-generated instructions in order to allow accesses to runtime
computed DCR numbers. But either they didn't exist in 2.6.26, or they
have a different name, I don't remember.
--
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: AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Stefan Roese @ 2009-09-11 5:25 UTC (permalink / raw)
To: linuxppc-dev
Cc: Andrea Zypchen, Pravin Bathija, lebon, Prodyut Hazarika, tburns,
azilkie
In-Reply-To: <1252646270.8566.64.camel@pasglop>
On Friday 11 September 2009 07:17:50 Benjamin Herrenschmidt wrote:
> On Fri, 2009-09-11 at 07:12 +0200, Stefan Roese wrote:
> > It's already there. See commit:
> >
> > 5ce4b59653b2c2053cd9a011918ac1e4747f24cc
> >
> > powerpc/4xx: Workaround for PPC440EPx/GRx PCI_28 Errata
>
> Ok, that's another way to do it. Will catch nasty drivers who
> try to write directly rather than clear pci_cache_line_size I suppose...
Correct. IIRC, some PATA driver as Pravin already mentioned.
Cheers,
Stefan
^ permalink raw reply
* Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Benjamin Herrenschmidt @ 2009-09-11 5:17 UTC (permalink / raw)
To: Stefan Roese
Cc: Andrea Zypchen, Pravin Bathija, lebon, Prodyut Hazarika, tburns,
linuxppc-dev, azilkie
In-Reply-To: <200909110712.11858.sr@denx.de>
On Fri, 2009-09-11 at 07:12 +0200, Stefan Roese wrote:
>
> It's already there. See commit:
>
> 5ce4b59653b2c2053cd9a011918ac1e4747f24cc
>
> powerpc/4xx: Workaround for PPC440EPx/GRx PCI_28 Errata
>
Ok, that's another way to do it. Will catch nasty drivers who
try to write directly rather than clear pci_cache_line_size I suppose...
Cheers,
Ben.
^ permalink raw reply
* Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Stefan Roese @ 2009-09-11 5:12 UTC (permalink / raw)
To: linuxppc-dev
Cc: Andrea Zypchen, Pravin Bathija, lebon, Prodyut Hazarika, tburns,
azilkie
In-Reply-To: <1252637074.8566.56.camel@pasglop>
On Friday 11 September 2009 04:44:34 Benjamin Herrenschmidt wrote:
> On Thu, 2009-09-10 at 13:30 -0700, Pravin Bathija wrote:
> > There is also a patch that was submitted for 440EPX a couple of years
> > back. The 440EPX SOC causes hangs with Memory Read Multiple (MRM)
> > commands. Whether MRM is used or not depends on the value of
> > PCI_CACHE_LINE_SIZE register. I see that the changes are no longer
> > present in linux 2.6.30+ kernels. Although the patch certainly resolved
> > the hang issue with Silicon Image 680 PATA card as the 680 driver
> > attempts to use MRM commands - I don't know if it would resolve the data
> > corruption issue. It is certainly worth trying in my opinion. Below is a
> > link to the patch submission:
> >
> > http://git.denx.de/?p=linux-2.6-denx.git;a=commit;h=cffefde924123e685327
> > 48dd58fcb780eab5e219
>
> The changes in the above repository is a quick hack that can't be merged
> as-is (and afaik hasn't been submitted).
>
> If indeed we need to clamp the PCI cache line size on those critters,
> then we need something in ppc4xx_pci.c to detect the need, set
> pci_cache_line_size to 0 and eventually fixup the existing values in
> devices in case u-boot don't have them right.
>
> Care to send a patch ? :-)
It's already there. See commit:
5ce4b59653b2c2053cd9a011918ac1e4747f24cc
powerpc/4xx: Workaround for PPC440EPx/GRx PCI_28 Errata
Cheers,
Stefan
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Cleanup handling of execute permission v2
From: David Gibson @ 2009-09-11 4:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1250658034.4810.9.camel@pasglop>
On Wed, Aug 19, 2009 at 03:00:34PM +1000, Benjamin Herrenschmidt wrote:
> This is an attempt at cleaning up a bit the way we handle execute
> permission on powerpc. _PAGE_HWEXEC is gone, _PAGE_EXEC is now only
> defined by CPUs that can do something with it, and the myriad of
> #ifdef's in the I$/D$ coherency code is reduced to 2 cases that
> hopefully should cover everything.
>
> The logic on BookE is a little bit different than what it was though
> not by much. Since now, _PAGE_EXEC will be set by the generic code
> for executable pages, we need to filter out if they are unclean and
> recover it. However, I don't expect the code to be more bloated than
> it already was in that area due to that change.
>
> I could boast that this brings proper enforcing of per-page execute
> permissions to all BookE and 40x but in fact, we've had that now for
> some time as a side effect of my previous rework in that area (and
> I didn't even know it :-) We would only enable execute permission if
> the page was cache clean and we would only cache clean it if we took
> and exec fault. Since we now enforce that the later only work if
> VM_EXEC is part of the VMA flags, we de-fact already enforce per-page
> execute permissions... Unless I missed something
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
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
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