On Thursday 02 August 2007, Josh Boyer wrote:
> On Mon, 30 Jul 2007 19:16:28 +0400
> > +0400 +++ linux/arch/powerpc/kernel/cputable.c 2007-07-27
> > 20:44:26.0 +0400 @@ -1132,6 +1132,42 @@
> > .dcache_bsize = 32,
> > .platform = "ppc440",
On Wed, Jul 18, 2007 at 05:55:16PM +0200, Segher Boessenkool wrote:
> >>> Too big for the list, the patch is at:
> >>> http://ozlabs.org/~dgibson/home/prep-support
> >>
> >> Too lazy to split the patch into bite-size chunks, you mean ;-)
> >
> > Well... much as I like small patches, I don't reall
On Thu, Jun 28, 2007 at 12:00:20PM +0200, Gabriel Paubert wrote:
> On Thu, Jun 28, 2007 at 10:59:35AM +0200, Segher Boessenkool wrote:
> > > Here is an implementation to allow PReP systems to boot under the
> > > arch/powerpc codebase, one of the few remaining platforms supported in
> > > arch/ppc
On Thursday 02 August 2007, Josh Boyer wrote:
> On Mon, 30 Jul 2007 19:14:45 +0400
> > +#define SPRN_CCR1 0x378
> > +void ibm440ep_fixup_clocks(unsigned int sysclk, unsigned int ser_clk)
> > +{
> > + u32 cpu, plb, opb, ebc, tb, uart0, m, vco;
> > + u32 reg;
> > + u32 fwdva, fwdvb, fbdv, lfbdv
On Thu, 2007-08-02 at 12:29, Kumar Gala wrote:
> On Aug 1, 2007, at 8:23 PM, Benjamin Herrenschmidt wrote:
>
> > On Thu, 2007-08-02 at 09:17 +0800, Zhang Wei-r63237 wrote:
> >> Hi, Ben,
> >>
> >>>
> >>> Are we sure that any powerpc machine that uses that ULI chip will
> >>> need
> >>> the same qu
On Fri, Aug 03, 2007 at 02:57:05PM +1000, David Gibson wrote:
> On Fri, Aug 03, 2007 at 11:18:09AM +1000, Benjamin Herrenschmidt wrote:
> > On Thu, 2007-08-02 at 13:48 +1000, David Gibson wrote:
> > > On Mon, Jul 30, 2007 at 08:35:17PM +0400, Valentine Barshak wrote:
> > > > PPC44x cascade UIC irq
On Thu, Aug 02, 2007 at 12:21:21PM -0700, Siva Prasad wrote:
> Hi,
>
> I am trying to understand ..
>
> 1) How a given dts file is embedded into the zImage (how about vmlinux?)
The arch/powerpc/boot/wrapper script builds the dts into a device tree
blob using dtc (the Device Tree Compiler), it th
On Fri, Aug 03, 2007 at 11:18:09AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2007-08-02 at 13:48 +1000, David Gibson wrote:
> > On Mon, Jul 30, 2007 at 08:35:17PM +0400, Valentine Barshak wrote:
> > > PPC44x cascade UIC irq handler fix.
> > >
> > > According to PPC44x UM, if an interrupt is c
On Thu, Aug 02, 2007 at 07:23:00PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> David Gibson wrote:
>
> >>Also mine. I've been home sick the last couple of days, but by way of
> >>a sharper prod, see my draft work below. It patches both
> >>booting-without-of.txt with a revised binding, and imple
On Thu, Aug 02, 2007 at 03:41:23PM -0500, Will Schmidt wrote:
> Hi Paul,
>just a few questions.
[snip]
> > +#define VSID_MULTIPLIER_256M ASM_CONST(200730139)/* 28-bit prime
> > */
>
> > +#define VSID_MULTIPLIER_1T ASM_CONST(12538073) /* 24-bit prime */
>
> Anything special i
On Fri, 2007-08-03 at 11:55 +1000, Michael Neuling wrote:
> We sometimes change the vmalloc segment in slb_flush_and_rebolt but we
> never updated with slb shadow buffer. This fixes it. Thanks to paulus
> for finding this.
>
> Also added some write barriers to ensure the shadow buffer is always
We sometimes change the vmalloc segment in slb_flush_and_rebolt but we
never updated with slb shadow buffer. This fixes it. Thanks to paulus
for finding this.
Also added some write barriers to ensure the shadow buffer is always
valid.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
Integ
On Thu, Aug 02, 2007 at 03:18:33PM -0500, Josh Boyer wrote:
> On Wed, 1 Aug 2007 15:47:51 +1000
> David Gibson <[EMAIL PROTECTED]> wrote:
> >
> > Duh, forgot to attach the actual patch. Here it is:
>
> So, no signed-off-by. Intentional, as it's for comments only?
Pretty much.
> Also, could yo
On Thu, 2007-08-02 at 13:48 +1000, David Gibson wrote:
> On Mon, Jul 30, 2007 at 08:35:17PM +0400, Valentine Barshak wrote:
> > PPC44x cascade UIC irq handler fix.
> >
> > According to PPC44x UM, if an interrupt is configured as level-sensitive,
> > and a clear is attempted on the UIC_SR, the UIC_
On Thu, 2007-08-02 at 19:26 -0500, Josh Boyer wrote:
> On Fri, Aug 03, 2007 at 08:38:16AM +1000, Benjamin Herrenschmidt wrote:
> > On Thu, 2007-08-02 at 16:39 -0500, Josh Boyer wrote:
> > >
> > > Someone brought up the fact that the EMAC rewrite is mostly just
> > > changing probing code and the g
On Fri, Aug 03, 2007 at 08:38:16AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2007-08-02 at 16:39 -0500, Josh Boyer wrote:
> >
> > Someone brought up the fact that the EMAC rewrite is mostly just
> > changing probing code and the guts are still similar to the current
> > EMAC driver. I haven'
On Fri, 2007-08-03 at 08:37 +1000, Benjamin Herrenschmidt wrote:
> > Is there technical reason why the 'local' variable remains at the end of
> > the parm list for these? In other cases 'ssize' simply gets added to
> > the end of the parm list.
>
> Looks nicer to have psize and ssize together :
wd wrote:
>
> In message <[EMAIL PROTECTED]> you wrote:
>>
>> I upgraded from an old 2.4.25 kernel to the latest Denx snapshot and
>> cannot
> ...
>> I am running a 5200B. Thanks for any help.
>
> Do you really have the latest snapshot, i. e. top of tree from the git
> repository?
>
Yes sir
On Wednesday 01 August 2007, Christoph Hellwig wrote:
> On Wed, Aug 01, 2007 at 09:28:07AM +0200, Domen Puncer wrote:
> > > It doesn't make any assumption on struct clk, it's just a
> > > wrapper around functions from clk.h.
> > > Point of this patch was to abstract exported functions, since
> > >
On Thu, Jul 05, 2007 at 12:54:06PM -0600, Matthew Wilcox wrote:
> On Thu, Jul 05, 2007 at 11:28:38AM -0700, Andrew Morton wrote:
> > Well you've sent it a couple of times, and I've sent it in five more times
> > over the past year. Once we were told "awaiting maintainer ack".
> >
> > This situati
On Thu, 2007-08-02 at 16:39 -0500, Josh Boyer wrote:
>
> Someone brought up the fact that the EMAC rewrite is mostly just
> changing probing code and the guts are still similar to the current
> EMAC driver. I haven't really looked into it yet, but if that's true,
> I'd be curious as to why it was
> Is there technical reason why the 'local' variable remains at the end of
> the parm list for these? In other cases 'ssize' simply gets added to
> the end of the parm list.
Looks nicer to have psize and ssize together :-)
Ben.
___
Linuxppc-dev ma
On Thursday 02 August 2007, Anton Vorontsov wrote:
> Probably someday mpc83xx_spi->sysclk should be renamed to
> mpc83xx_spi->spiclk to be less confusing.
Why not "today", with this patch? That would fix some of
the root cause of this bug...
___
Linu
On Thu, 2 Aug 2007 20:57:26 + (UTC)
Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> On Tue, 17 Jul 2007 13:15:47 -0500, Josh Boyer wrote:
>
> > For those interested, here's my current 4xx patch series. There are a few
> > cleanups as a pre-requisite for 40x support, some minimal Walnut support
> remap_4k_pfn is defined in terms of remap_pfn_range if the base page
> size if 4k, so you don't need this #ifdef afaics.
Good point. I'll wait for an updated patch.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/lis
On Tue, 17 Jul 2007 13:15:47 -0500, Josh Boyer wrote:
> For those interested, here's my current 4xx patch series. There are a few
> cleanups as a pre-requisite for 40x support, some minimal Walnut support, and
> another round of Bamboo patches. These are all based off of Paul's current
> tree.
In message <[EMAIL PROTECTED]> you wrote:
>
> I upgraded from an old 2.4.25 kernel to the latest Denx snapshot and cannot
...
> I am running a 5200B. Thanks for any help.
Do you really have the latest snapshot, i. e. top of tree from the git
repository?
Best regards,
Wolfgang Denk
--
DENX So
Hi Paul,
just a few questions.
On Wed, 2007-08-01 at 12:04 +1000, Paul Mackerras wrote:
> This makes the kernel use 1TB segments for all kernel mappings and for
> user addresses of 1TB and above, on machines which support them
> (currently POWER5+ and POWER6). We don't currently use 1TB seg
Reserved MCSR bits on FSL BookE parts may have spurious values
when mcheck occurs. Mask these off when printing the MCSR to
avoid confusion. Also, get rid of the MCSR_GL_CI bit defined
for e500 - this bit doesn't actually have any meaning.
Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
---
arch
On Mon, 30 Jul 2007 19:23:39 +0400
Valentine Barshak <[EMAIL PROTECTED]> wrote:
> The patch adds PHY support for the Sequoia board to the new EMAC driver and
> enables NEW_EMAC for 440EPx Kconfig.
> The phy code has been written by Stefan Roese.
> This has been tested with the following version of
On Mon, 30 Jul 2007 19:16:28 +0400
Valentine Barshak <[EMAIL PROTECTED]> wrote:
> diff -ruN linux.orig/arch/powerpc/kernel/cputable.c
> linux/arch/powerpc/kernel/cputable.c
> --- linux.orig/arch/powerpc/kernel/cputable.c 2007-07-27 20:37:10.0
> +0400
> +++ linux/arch/powerpc/kernel/cputa
On Wed, 1 Aug 2007 15:05:42 +1000
David Gibson <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 01, 2007 at 07:01:17AM +0200, Segher Boessenkool wrote:
> > >> +{ /* 440EPX - without Security/Kasumi */
> > >> +.pvr_mask = 0xffff,
> > >> +.pvr_valu
On Mon, 30 Jul 2007 19:14:45 +0400
> +#define SPRN_CCR1 0x378
> +void ibm440ep_fixup_clocks(unsigned int sysclk, unsigned int ser_clk)
> +{
> + u32 cpu, plb, opb, ebc, tb, uart0, m, vco;
> + u32 reg;
> + u32 fwdva, fwdvb, fbdv, lfbdv, opbdv0, perdv0, spcid0, prbdv0, tmp;
> +
> + mtd
On Wed, 1 Aug 2007 12:09:36 +1000
David Gibson <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 30, 2007 at 07:12:45PM +0400, Valentine Barshak wrote:
> > This patch adds DCR defines needed for 440EP/440EPx clock
> > initialization. These defines have been introduced in the Bamboo
> > support by Josh Boye
On Wed, 1 Aug 2007 15:47:51 +1000
David Gibson <[EMAIL PROTECTED]> wrote:
>
> Duh, forgot to attach the actual patch. Here it is:
So, no signed-off-by. Intentional, as it's for comments only?
Also, could you break this out into a separate thread when you do
submit it please? Will make a few p
On Wed, 1 Aug 2007 15:04:22 +1000
David Gibson <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 01, 2007 at 06:57:33AM +0200, Segher Boessenkool wrote:
> > >> +UIC0: interrupt-controller0 {
> > >> +compatible = "ibm,uic-440gp","ibm,uic";
> > >
> > > The first compatible entry shoul
On Wed, 1 Aug 2007 12:08:36 +1000
David Gibson <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 30, 2007 at 07:06:48PM +0400, Valentine Barshak wrote:
> > AMCC Sequoia board DTS
> >
> > Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
> > ---
> > arch/powerpc/boot/dts/sequoia.dts | 292
> >
On Thu, 2 Aug 2007 13:48:48 +1000
David Gibson <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 30, 2007 at 08:35:17PM +0400, Valentine Barshak wrote:
> > PPC44x cascade UIC irq handler fix.
> >
> > According to PPC44x UM, if an interrupt is configured as
> > level-sensitive, and a clear is attempted on
Hi,
I am trying to understand ..
1) How a given dts file is embedded into the zImage (how about vmlinux?)
2) Where does it get stored for later access during booting?
3) How a specific dts file out of the available in /boot/dts directory
is chosen?
I am a newbie to this open firmware thing and l
On Aug 2, 2007, at 12:35 PM, Anton Vorontsov wrote:
> mmc_spi already tested to work. When it will hit mainline
> the only change that will be needed is replacing "spidev"
> by "mmc_spi".
>
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/dts/mpc832x_rdb.dts |
Creating a platform device for the PCI error registers in order for the
mpc85xx EDAC driver to pick up proper resources. This is to prevent the EDAC
driver from monopolizing the of_device and thus preventing future PCI code from
using the PCI of_device(s).
Signed-off-by: Dave Jiang <[EMAIL PROTECT
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/fsl_soc.c | 109 +
arch/powerpc/sysdev/fsl_soc.h | 12 +
2 files changed, 121 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fs
mmc_spi already tested to work. When it will hit mainline
the only change that will be needed is replacing "spidev"
by "mmc_spi".
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc832x_rdb.dts | 27 +-
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 5
Hi all,
Thanks for the previous review! Here is updated version, also needs
your comments.
Changelog:
o Device tree:
- cosmetic cleanups (@01 -> @1);
- device-id renamed to fsl,device-id;
- removed max-chipselect and sysclk properties from spi node;
- removed chipselect property from mmc
On Aug 2, 2007, at 10:28 AM, Scott Wood wrote:
> On Thu, Aug 02, 2007 at 10:14:31AM +0800, Liu Dave-r63238 wrote:
>>> MBAR doesn't live up to its name. It's a general-purpose scratch
>>> register - the hardware doesn't do anything with it. So, wrt
>
> That doesn't mean there isn't value in sett
On Thu, Aug 02, 2007 at 10:14:31AM +0800, Liu Dave-r63238 wrote:
> > MBAR doesn't live up to its name. It's a general-purpose scratch
> > register - the hardware doesn't do anything with it. So, wrt
That doesn't mean there isn't value in setting it, so code can easily
find the IMMR without havi
On Thu, Aug 02, 2007 at 10:19:17AM -0500, Kumar Gala wrote:
>
> On Aug 2, 2007, at 9:26 AM, Anton Vorontsov wrote:
>
>> For MPC8349E input to SPIBRG is SYSCLK, but it's SYSCLK/2 for
>> MPC8323E (running in so-called "QE mode").
>
> QE mode or the SPI in QE running in CPU mode?
Yeah, "qe_mode" vari
Hello.
David Gibson wrote:
>>Also mine. I've been home sick the last couple of days, but by way of
>>a sharper prod, see my draft work below. It patches both
>>booting-without-of.txt with a revised binding, and implements it in
>>the physmap_of driver (which needs renaming, but that's another
>
On Aug 2, 2007, at 9:26 AM, Anton Vorontsov wrote:
> For MPC8349E input to SPIBRG is SYSCLK, but it's SYSCLK/2 for
> MPC8323E (running in so-called "QE mode").
QE mode or the SPI in QE running in CPU mode?
- k
>
> This fixes clocking issues I've noticed recently.
>
> Probably someday mpc83xx_s
For MPC8349E input to SPIBRG is SYSCLK, but it's SYSCLK/2 for
MPC8323E (running in so-called "QE mode").
This fixes clocking issues I've noticed recently.
Probably someday mpc83xx_spi->sysclk should be renamed to
mpc83xx_spi->spiclk to be less confusing.
Signed-off-by: Anton Vorontsov <[EMAIL PR
On Thursday 02 August 2007, Hoang-Nam Nguyen wrote:
> +#ifdef CONFIG_PPC_64K_PAGES
> + /* make sure we map only 4k for fw context */
> + ret = remap_4k_pfn(vma, vma->vm_start, physical >> EHCA_PAGESHIFT,
> + vma->vm_page_prot);
> +#else
> ret = remap_pfn
From: Hoang-Nam Nguyen
Date: Thu, 2 Aug 2007 10:08:30 +0200
Subject: [PATCH] ehca: map 4k firmware context of cq, qp to user space
This patch utilizes remap_4k_pfn() as introduced by Paul M.,
for details see http://patchwork.ozlabs.org/linuxppc/patch?id=10281,
to map ehca cq, qp firmware context (
> On Thu, 2007-08-02 at 19:03 +1000, Michael Neuling wrote:
> > >
> > > Ok, that was missing from your description :-)
> >
> > Sorry... so ditch the barriers?
>
> As you like. The reason why you can ditch them is purely because you
> know for sure that the only case the firmware will access tho
On Thu, 2007-08-02 at 19:03 +1000, Michael Neuling wrote:
> >
> > Ok, that was missing from your description :-)
>
> Sorry... so ditch the barriers?
As you like. The reason why you can ditch them is purely because you
know for sure that the only case the firmware will access those shadows
from
> On Thu, 2007-08-02 at 18:56 +1000, Michael Neuling wrote:
> > > > But even in the case of a checkpoint restart, the ordering will be
> > > > preserved as the NIA we get as part of the checkpoint will have
> > all
> > > > previous instructions complete and none of the following
> > instructions
>
On Thu, 2007-08-02 at 18:56 +1000, Michael Neuling wrote:
> > > But even in the case of a checkpoint restart, the ordering will be
> > > preserved as the NIA we get as part of the checkpoint will have
> all
> > > previous instructions complete and none of the following
> instructions
> > > started.
> >
> > But even in the case of a checkpoint restart, the ordering will be
> > preserved as the NIA we get as part of the checkpoint will have all
> > previous instructions complete and none of the following instructions
> > started.
>
> Instruction completion isn't enough to ensure storage order
On Thu, 2007-08-02 at 15:56 +1000, Michael Neuling wrote:
>
> But even in the case of a checkpoint restart, the ordering will be
> preserved as the NIA we get as part of the checkpoint will have all
> previous instructions complete and none of the following instructions
> started.
Instruction com
58 matches
Mail list logo
