On Fri, 2009-04-03 at 14:10 +0800, Harry Ciao wrote:
> Setup a platform device for the CPC925 Memory Controller during system
> booting up, against which CPC925 MC EDAC driver would be matched.
>
> Signed-off-by: Harry Ciao
> ---
> arch/powerpc/platforms/maple/setup.c | 47
> +
Setup a platform device for the CPC925 Memory Controller during system
booting up, against which CPC925 MC EDAC driver would be matched.
Signed-off-by: Harry Ciao
---
arch/powerpc/platforms/maple/setup.c | 47 ++
1 files changed, 47 insertions(+), 0 deletions(-)
Hi,
Sorry, my git-send-mail died and failed to send out 3/3 patch.
Harry
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Add edac_device_alloc_index(), because for MAPLE platform there may
exist several EDAC driver modules that could make use of
edac_device_ctl_info structure at the same time. The index allocation
for these structures should be taken care of by EDAC core.
Signed-off-by: Harry Ciao
---
drivers/edac
Hi,
Sorry, my git-send-mail died and failed to send out the 2/3 patch.
Harry
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Introduce IBM CPC925 EDAC driver, which makes use of ECC, CPU and
HyperTransport Link error detections and corrections on the IBM
CPC925 Bridge and Memory Controller.
Signed-off-by: Harry Ciao
---
drivers/edac/Kconfig |9 +
drivers/edac/Makefile |1 +
drivers/edac/cpc925_edac.
Hi Doug and PPC developers,
This is v1 series of patches for CPC925 Memory Controller EDAC driver that
works on PPC970FX. I have taken Arnd's suggestion to fold header/source/etc
into one file and makes CONFIG_EDAC_CPC925 depend on CONFIG_PPC64.
Please take a look and give your comments, many
Harry Ciao 写道:
Arnd Bergmann 写道:
On Thursday 02 April 2009, Harry Ciao wrote:
+#ifdef CONFIG_EDAC
+#define CPC925_MC_START0xf800
+#define CPC925_MC_END 0xf8ff /* sizeof 16MB */
+/* Register a platform device for CPC925 memory controller */
+static int __init m
> I don't think having it working for BookE is really a requirement before this
> gets in though. If we can get it working with minimal effort for ppc64, that
> would help get systemtap and related things functioning correctly there.
Sure, just conditionalize arch_has_block_step() however is corr
On Thu, 2009-04-02 at 17:44 -0700, Roland McGrath wrote:
> > The patch only implements it for "server/classic" processors, not BookE,
> > thus it should probably only advertise it for these :-)
> >
> > Though it wouldn't be too hard to implement it for BookE using DBCR0:BRT
> > (Branch Taken debug
On Thu, Apr 02, 2009 at 05:44:50PM -0700, Roland McGrath wrote:
>> The patch only implements it for "server/classic" processors, not BookE,
>> thus it should probably only advertise it for these :-)
>>
>> Though it wouldn't be too hard to implement it for BookE using DBCR0:BRT
>> (Branch Taken debu
> The patch only implements it for "server/classic" processors, not BookE,
> thus it should probably only advertise it for these :-)
>
> Though it wouldn't be too hard to implement it for BookE using DBCR0:BRT
> (Branch Taken debug event) though it might need some careful fixups such
> as the one w
Hi All,
I'm using u-boot to boot kernel 2.6.24.2 on a powerpc based board .
I see that after uncompressing the kernel it hangs.
I found a location (System.map) I think corresponds to the __log_buf (my SDRAM
starts at physical address 0 (and u-boot performs -> Load Address:
Entry Point:
Added a few minor commits..
Please pull from 'next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git next
to receive the following updates:
arch/powerpc/Kconfig |1 +
arch/powerpc/boot/dts/ksi8560.dts |4 ++--
arch/powerpc/boot/dts/
On Apr 2, 2009, at 5:09 PM, Kyle McMartin wrote:
On Thu, Apr 02, 2009 at 05:04:47PM -0500, Kumar Gala wrote:
+config SPE_EMULATION
+ bool "SPE Emulation Support"
+ depends on (CLASSIC32 || POWER4) && !ALTIVEC && !SPE
+ ---help---
+ This option enables kernel support for the
On Thu, Apr 02, 2009 at 05:04:47PM -0500, Kumar Gala wrote:
> +config SPE_EMULATION
> + bool "SPE Emulation Support"
> + depends on (CLASSIC32 || POWER4) && !ALTIVEC && !SPE
> + ---help---
> + This option enables kernel support for the Altivec extensions to the
> +
Looks like you
Based on patch from Edmar Wienskoski
---
I posting this to see if anyone would possibly use this support if it was in
the stock kernel. It allows us to build and use e500/SPE toolchains on G5 HW.
- k
arch/powerpc/include/asm/processor.h |6 +-
arch/powerpc/kernel/traps.c| 6
On Thu, 2009-04-02 at 11:12 -0500, Scott Wood wrote:
> On Wed, Apr 01, 2009 at 08:23:42PM -0700, Sauce.Cheng wrote:
> > > I don't see where you set up a BAT that covers 0xf000.
> >
> > if i have to set up a BAT that cover 0xF000. i had a debug with LEDs
> > like that in u-boot code. everyt
While normally we don't use the math emulation code on ppc64 it can be
useful for doing things like emulating the embedded FP instructions.
Since performance isn't critical in this scenario its easier to keep
the sizes of the various math-emu the same as on ppc32.
Signed-off-by: Kumar Gala
---
From: Kumar Gala
Date: Thu, 2 Apr 2009 08:45:23 -0500
> From: Segher Boessenkool
>
> Add EXPORT_SYMBOL_GPL(fsl_pq_mdio_bus_name) for module builds
>
> Signed-off-by: Segher Boessenkool
> Signed-off-by: Kumar Gala
Applied, thanks.
___
Linuxppc-dev
Hugh Dickins wrote:
This is a cosmetic matter, not worth more than a couple of lines of
code: I suggested masking off the high bits in the display, but when
KAMEZAWA-san suggested just showing 0, it was hard to argue against
his brutal simplicity.
Consider this change a fix: it used to show
On MPC8313, the TSEC flags ECNTRL_REDUCED_MODE (for RGMII) and
ECNTRL_REDUCED_MII_MODE (for RMII) are mutually exclusive (15-32 of
the 8313 reference manual). The current gianfar driver only checks
for RMII when RGMII is enabled, so plain RMII is never detected. This
patch makes the flags indepen
On Apr 2, 2009, at 1:50 PM, Wolfgang Grandegger wrote:
[PATCH] powerpc/85xx: Re-add the device_type soc to socrates.dts
The device_type "soc" is still required for MPC85xx boards.
Signed-off-by: Wolfgang Grandegger
---
arch/powerpc/boot/dts/socrates.dts |1 +
1 file changed, 1 insertion(+
SPEFSCR is a user space register and doesn't conflict with anything.
Moving the defines of the various bit fields makes some emulation
code have fewer ifdefs
Signed-off-by: Kumar Gala
---
arch/powerpc/include/asm/reg.h | 30 ++
arch/powerpc/include/asm/reg_boo
On Tuesday 31 March 2009, KOBAYASHI Yoshitake wrote:
> 2009/03/31 16:51, Geert Uytterhoeven wrote:
> > On Mon, 30 Mar 2009, Grant Grundler wrote:
> >> Followup to "[PATCH 03/10] ide: destroy DMA mappings after ending DMA"
> >> email on March 14th:
> >> http://lkml.org/lkml/2009/3/14/17
> >>
> >
Anton Vorontsov wrote:
On Thu, Apr 02, 2009 at 01:42:37PM -0500, Timur Tabi wrote:
Anton Vorontsov wrote:
Oh, I was wrong. fsl_qe_udc driver uses mpc8360 compatible for
matching, so you can't remove it. :-/
Ugh, that's a bug in the driver then.
Yes, but that depends on what chip was the fir
On Thu, Apr 02, 2009 at 01:42:37PM -0500, Timur Tabi wrote:
> Anton Vorontsov wrote:
>
> > Oh, I was wrong. fsl_qe_udc driver uses mpc8360 compatible for
> > matching, so you can't remove it. :-/
>
> Ugh, that's a bug in the driver then.
Yes, but that depends on what chip was the first one? MPC8
On Thu, 2 Apr 2009, Chris Friesen wrote:
> Hugh Dickins wrote:
> > > > f7feb000-f7fec000 rw-p f7feb000 00:00 0
> > > > ffe6d000-ffe82000 rw-p ffeb000 00:00 0 [stack]
>
> > Chris isn't the first to be concerned by that: there's a patch in
> > -mm which just shows 0 instead of anon vm_pgoff
Anton Vorontsov wrote:
> Oh, I was wrong. fsl_qe_udc driver uses mpc8360 compatible for
> matching, so you can't remove it. :-/
Ugh, that's a bug in the driver then.
My understanding is that the only MPC8323 QE microcode update is the one
for UART. If there are any updates to any other QE devic
Kumar Gala wrote:
>
> On Apr 2, 2009, at 1:38 AM, Wolfgang Grandegger wrote:
>
>>
>> Socrates is a new board and it has no problem using an up-to-date
>> version of U-Boot. The socrates.dts file in your "next" tree already has
>> the "device_type = "soc" removed. We need to add "fsl,soc" to the
>
On Thu, Apr 02, 2009 at 10:33:57PM +0400, Anton Vorontsov wrote:
[...]
> > + compatible = "fsl,mpc8360-qe-usb",
>
> Ditto. No need for mpc8360 compatible.
Oh, I was wrong. fsl_qe_udc driver uses mpc8360 compatible for
matching, so you can't remove it. :-/
--
Anton Vorontsov
em
[ Cc'ing linuxppc-dev and Timur Tabi ]
On Wed, Apr 01, 2009 at 11:46:36PM +0200, Marcel Ziswiler wrote:
> Open issues:
> - MPC832x_MDS seems to lie about BCSR12_USMODE bit.
> - How to use qe_setbrg() with an external clock pin? Hard-coded for now.
> - How to properly allocate USB pram on MPC832x a
Hugh Dickins wrote:
On Thu, 2 Apr 2009, Michael Ellerman wrote:
On Wed, 2009-04-01 at 17:18 -0600, Chris Friesen wrote:
Resending due to lack of response to original post.
Hi Chris,
You'll probably get a more useful response on lkml. You CC'ed
linux-kernel-owner originally :)
Thanks.
Than
On Tue, 31 Mar 2009, Geert Uytterhoeven wrote:
> With today's kernel, I can no longer kexec any kernel on PS3:
>
> | /proc/device-tree/chosen/linux,kernel-end: No such file or directory
> | Could not get memory layout
>
> Today's bad version: 15f7176eb1cccec0a332541285ee752b935c1c85
> Yesterday's
On Wed, Apr 01, 2009 at 08:23:42PM -0700, Sauce.Cheng wrote:
> > I don't see where you set up a BAT that covers 0xf000.
>
> if i have to set up a BAT that cover 0xF000. i had a debug with LEDs
> like that in u-boot code. everything is //normal. 0xF is the value
> of CFG_IMMR(CONFIG
On Thu, Apr 2, 2009 at 6:52 AM, Gary Thomas wrote:
>
> Can you share what you had and what you changed it to? I'm
> running on very similar systems and may face this exact problem
> soon.
>
> Thanks
>
I don't actually have a platform-specific bus, but I misread the help
text for CONFIG_SERIAL_OF
On Thu, 2 Apr 2009, Michael Ellerman wrote:
> On Wed, 2009-04-01 at 17:18 -0600, Chris Friesen wrote:
> > Resending due to lack of response to original post.
>
> Hi Chris,
>
> You'll probably get a more useful response on lkml. You CC'ed
> linux-kernel-owner originally :)
Thanks.
>
> > I was v
* Arnd Bergmann | 2009-04-02 15:15:11 [+0200]:
>BenK, can you try Geert's patch on QPACE?
Successfully tested on QPACE.
Acked-by: Benjamin Krill
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Thu, Apr 02, 2009 at 11:42:02AM +0200, Geert Uytterhoeven wrote:
> On Fri, 13 Mar 2009, Kyle McMartin wrote:
> > On Wed, Mar 11, 2009 at 06:26:12PM +0100, Geert Uytterhoeven wrote:
> > > On Wed, 11 Mar 2009, Kyle McMartin wrote:
> > > > On Wed, Mar 11, 2009 at 11:36:02AM +0100, Geert Uytterhoeve
On Apr 2, 2009, at 1:38 AM, Wolfgang Grandegger wrote:
Socrates is a new board and it has no problem using an up-to-date
version of U-Boot. The socrates.dts file in your "next" tree already
has
the "device_type = "soc" removed. We need to add "fsl,soc" to the
"compatible" property and updat
From: Segher Boessenkool
Add EXPORT_SYMBOL_GPL(fsl_pq_mdio_bus_name) for module builds
Signed-off-by: Segher Boessenkool
Signed-off-by: Kumar Gala
---
Dave,
I think this got lost in a thread on the ppc list.
- k
drivers/net/fsl_pq_mdio.c |1 +
1 files changed, 1 insertions(+), 0 dele
On Thu, Apr 2, 2009 at 1:57 AM, David Miller wrote:
> From: Grant Likely
> Date: Wed, 01 Apr 2009 00:16:46 -0600
>
>> Here are the fec_mpc52xx patches which should be picked up for 2.6.29.
>> Patch #1 fixes a dma related BUG_ON() discovered after the merge window
>> opened. #2 & #3 were original
> On Wed, Apr 01, 2009 at 01:20:49PM -0400, Herrera-Bendezu, Luis wrote:
> >> I am working on a PPC440EPx board with some FPGAs located at
> >> addresses above 4 GB
Cc'ing the PPC list, since they have the most experience with this
CPU, and may have some useful insights. The topic is "UIO on the
On Thursday 02 April 2009, Geert Uytterhoeven wrote:
> | arch/powerpc/platforms/built-in.o:(.toc1+0x4e8): undefined reference to
> `pci_io_base'
>
> due to arch/powerpc/platforms/cell/io-workarounds.c. I guess this file
> shouldn't be built when CONFIG_PCI=n?
Right, the I/O workarounds are speci
On Thursday 02 April 2009, Harry Ciao wrote:
> Introduce IBM CPC925 EDAC driver source file, which makes use of error
> detections on the IBM CPC925 Bridge and Memory Controller.
>
> Signed-off-by: Harry Ciao
On a very brief review, the driver looks good to me, but please
post the full series to
On Thursday 02 April 2009, Harry Ciao wrote:
> +#ifdef CONFIG_EDAC
> +#define CPC925_MC_START0xf800
> +#define CPC925_MC_END 0xf8ff /* sizeof 16MB */
> +/* Register a platform device for CPC925 memory controller */
> +static int __init maple_cpc925_edac_setup(void)
Hi,
my mpc8349 based board is known to have some problems with one ethernet phy
and is producing more (< 0.001%) frame errors than it should. This is enough
for the gianfar driver (of 2.6.27.20) to oops when I create lot's of packets
with a ping flood.
The oops occurs after "NETDEV WATCHDOG" r
Matthew L. Creech wrote:
> It turned out that the normally-initialized 8250 driver was getting
> stomped on by my device tree's serial driver (which is also an 8250) -
> apparently CONFIG_SERIAL_8250[_CONSOLE] and CONFIG_SERIAL_OF_PLATFORM
> don't play well together. Disabling the latter fixed my
On Fri, 13 Mar 2009, Kyle McMartin wrote:
> On Wed, Mar 11, 2009 at 06:26:12PM +0100, Geert Uytterhoeven wrote:
> > On Wed, 11 Mar 2009, Kyle McMartin wrote:
> > > On Wed, Mar 11, 2009 at 11:36:02AM +0100, Geert Uytterhoeven wrote:
> > > > Is it OK for you to take it through your PA-RISC tree?
> >
Hi !
I've posted for those interested at:
http://gate.crashing.org/~benh/patches-preliminary-book3e.tar.gz
A work-in-progress set of patches for adding support for a new processor
type, which ultimately will be common to 32 and 64-bit, and will
represent processors compliant with the architectur
From: Anton Vorontsov
Date: Tue, 31 Mar 2009 22:33:52 +0400
> commit 1577ecef766650a57fceb171acee2b13cbfaf1d3 ("netdev: Merge UCC
> and gianfar MDIO bus drivers") introduced a regression so that UCC
> MDIO buses no longer work.
>
> This is because fsl_pq_mdio driver wrongly masks all non-TBI PHY
From: Anton Vorontsov
Date: Tue, 31 Mar 2009 22:58:37 +0400
> The driver should pass a device that actually specifies internal DMA
> ops, but currently it passes netdev's device, which is wrong and that
> causes following oops:
...
> Fix this by passing of_device's device that specifies DMA ops
From: Kumar Gala
Date: Tue, 31 Mar 2009 08:42:59 -0500
> Now that the driver is exclusively an of_platform driver we no longer
> use the structs and #defines in fsl_devices.h
>
> Signed-off-by: Kumar Gala
Applied.
___
Linuxppc-dev mailing list
Linuxp
From: Kumar Gala
Date: Tue, 31 Mar 2009 08:42:58 -0500
> Now that the driver is exclusively an of_platform driver we no longer
> use the structs and #defines in fsl_devices.h
>
> Signed-off-by: Kumar Gala
Applied.
___
Linuxppc-dev mailing list
Linuxp
On Wed, 2009-04-01 at 17:18 -0600, Chris Friesen wrote:
> Resending due to lack of response to original post.
Hi Chris,
You'll probably get a more useful response on lkml. You CC'ed
linux-kernel-owner originally :)
> I was validating some code dealing with /proc//maps on 2.6.29 and
> was surpri
From: Grant Likely
Date: Wed, 01 Apr 2009 00:16:46 -0600
> Here are the fec_mpc52xx patches which should be picked up for 2.6.29.
> Patch #1 fixes a dma related BUG_ON() discovered after the merge window
> opened. #2 & #3 were original a single patch posted prior to the merge
> window, but not h
On Wed, 1 Apr 2009, Benjamin Herrenschmidt wrote:
> On Wed, 2009-04-01 at 12:45 +0200, Arnd Bergmann wrote:
> > On Wednesday 01 April 2009, Benjamin Herrenschmidt wrote:
> > > On Wed, 2009-04-01 at 11:42 +0200, Geert Uytterhoeven wrote:
> > > > PPC_CELL_NATIVE selects PPC_OF_PLATFORM_PCI, but not t
On Wed, Apr 1, 2009 at 11:31 PM, Subodh Nijsure
wrote:
> Hello,
>
> I need some help in understanding the interrupts = <...> section of DTB file.
>
> I have read the Documentation/booting-without-of.txt and I understand
> that interrupts = means interrupt A and B is "enum" that
> indicates if it
> I have a custom board based on the MPC8313ERDB and have
> communications capabilities over Ethernet using internet
> sockets. Basically, just data transfer from the host (my
> board) to a client (a PC). I want to be able to perform
> similar transactions across USB.
>
> I have done some cu
Looks good. I tested it on x86_32.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
60 matches
Mail list logo
