On Wed, Oct 10, 2007 at 08:32:12AM +0200, Stefan Roese wrote:
> This patch makes the PPC4xx NAND flash controller (NDFC) device-tree
> friendly using OF glue code to create and insert necessary platform
> devices. Such "constructor" approach makes NAND usable under
> arch/powerpc yet keeping full c
On Monday 24 September 2007, Valentine Barshak wrote:
> Some PowerPC systems have a built-in EHCI controller.
> This is a device tree aware version of the EHCI controller driver.
> Currently it's been tested on the PowerPC 440EPx Sequoia board.
> Other platforms can be added later.
> The code is ba
This patch makes the PPC4xx NAND flash controller (NDFC) device-tree
friendly using OF glue code to create and insert necessary platform
devices. Such "constructor" approach makes NAND usable under
arch/powerpc yet keeping full compatibility with arch/ppc.
This patch also introduces a "common" (no
On Mon, Oct 08, 2007 at 04:24:34PM -0500, Scott Wood wrote:
> I'd like to expose flatdevtree's ability to do relative path lookups in
> ops, and I'd prefer to extend the existing finddevice method rather than
> add a new finddevice_rel. However, I'm not very familiar with real OF
> -- how would
Please Let me know the Status
Misbah
Misbah khan wrote:
>
>
>
>
> Timur Tabi-3 wrote:
>>
>> Kumar, this is what I get when I compile your 2.6.24 branch for the 8610:
>>
>>CC arch/powerpc/sysdev/fsl_soc.o
>> In file included from arch/powerpc/sysdev/fsl_soc.c:40:
>> include/asm/c
On Tue, Oct 09, 2007 at 11:06:05AM -0500, Timur Tabi wrote:
> David Gibson wrote:
>
> > Policy. Compiling everything means build bugs - like this one - can
> > be found by everybody, not just those building for the specific
> > obscure platform.
>
> Is this a new policy? Modules in the kernel a
On Tue, Oct 09, 2007 at 11:06:45AM -0500, Scott Wood wrote:
> On Tue, Oct 09, 2007 at 01:07:29PM +1000, David Gibson wrote:
> > On Mon, Oct 08, 2007 at 04:33:24PM -0500, Timur Tabi wrote:
> > > Question: I'm building a kernel for the 8610. Why is treeboot-walnut.c
> > > being compiled at all?
> >
Jan-Bernd Themann wrote:
> eHEA recovery and DLPAR functions are called seldomly. The eHEA workqueues
> are replaced by the kernel event queue.
>
> Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
>
> ---
> The patch has been built against upstream git
>
> drivers/net/ehea/ehea.h |
Don't allow cpu hotplug on systems lacking XICS interrupt controller,
since current code is hardcoded for it.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
---
On Wed, Oct 10, 2007 at 10:18:26AM +1000, Stephen Rothwell wrote:
> > + struct device_node *np;
> > + const char *typep;
> > +
Hi Olof,
On Tue, 9 Oct 2007 19:08:15 -0500 Olof Johansson <[EMAIL PROTECTED]> wrote:
>
> Don't allow cpu hotplug on systems lacking XICS interrupt controller,
> since current platform code is hardcoded for it.
>
>
> Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
>
>
> diff --git a/arch/powe
Don't allow cpu hotplug on systems lacking XICS interrupt controller,
since current platform code is hardcoded for it.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c
b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index 9711eb0..e29b8
On Tue, Oct 09, 2007 at 04:27:06PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 10 Oct 2007, Thomas Gleixner wrote:
> >
> > Wrapping it into a #ifdef CONFIG_X86 would be sufficient.
>
> Well, the ppc oops seems to be a ppc bug regardless.
>
> If CPU_HOTPLUG isn't defined, the thing does nothing.
On Tue, Oct 09, 2007 at 04:28:10PM -0500, Linas Vepstas wrote:
>
> Perhaps I should IRC this ...
yeah. I guess I'd forgotten how funky things can get. So never mind ...
--linas
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org
Signed-off-by: Wolfgang Denk <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/vdso.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 213fa31..2322ba5 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel
On Tue, Oct 09, 2007 at 04:18:19PM -0500, Nathan Lynch wrote:
> Linas Vepstas wrote:
> >
> > I was futzing with linux-2.6.23-rc8-mm1 in a power6 lpar when,
> > for whatever reason, a spinlock locked up. The bizarre thing
> > was that the rest of system locked up as well: an ssh terminal,
> > and
Linas Vepstas wrote:
>
> I was futzing with linux-2.6.23-rc8-mm1 in a power6 lpar when,
> for whatever reason, a spinlock locked up. The bizarre thing
> was that the rest of system locked up as well: an ssh terminal,
> and also an hvc console.
>
> Breaking into the debugger showed 4 cpus, 1 of w
On Tue, 2007-10-09 at 11:39 -0600, Grant Likely wrote:
> On 10/8/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> > On Mon, 2007-10-08 at 22:43 -0600, Grant Likely wrote:
> > > BTW, what path do framebuffer patches take to get into Linus' tree?
> > > Does he pull your tree directly, or do they g
I was futzing with linux-2.6.23-rc8-mm1 in a power6 lpar when,
for whatever reason, a spinlock locked up. The bizarre thing
was that the rest of system locked up as well: an ssh terminal,
and also an hvc console.
Breaking into the debugger showed 4 cpus, 1 of which was
deadlocked in the spinloc
On Oct 9, 2007, at 2:18 PM, Timur Tabi wrote:
> Kumar Gala wrote:
>
>> Ok. I guess I'm not in favor of changing the device tree to
>> address this issue. I think it would be solved if "dtc" had
>> #define support.
>
> Not really. The #defines would then need to match the enum, and
> that
Kumar Gala wrote:
> Ok. I guess I'm not in favor of changing the device tree to address
> this issue. I think it would be solved if "dtc" had #define support.
Not really. The #defines would then need to match the enum, and that's dual
maintenance. This method is better because you can use t
On Oct 9, 2007, at 1:17 PM, Timur Tabi wrote:
> Kumar Gala wrote:
>
>> But that's a function of linux' use. Remember decouple the device
>> tree from how linux does things.
>
> Ok, I just understand what your point is. I'm proposing that we
> just put the name of the clock source in the dev
On Oct 9, 2007, at 1:52 PM, Josh Boyer wrote:
> On Tue, 09 Oct 2007 11:06:05 -0500
> Timur Tabi <[EMAIL PROTECTED]> wrote:
>
>> David Gibson wrote:
>>
>>> Policy. Compiling everything means build bugs - like this one - can
>>> be found by everybody, not just those building for the specific
>>> o
On Tue, 09 Oct 2007 11:06:05 -0500
Timur Tabi <[EMAIL PROTECTED]> wrote:
> David Gibson wrote:
>
> > Policy. Compiling everything means build bugs - like this one - can
> > be found by everybody, not just those building for the specific
> > obscure platform.
>
> Is this a new policy? Modules i
Kumar Gala wrote:
> But that's a function of linux' use. Remember decouple the device tree
> from how linux does things.
Ok, I just understand what your point is. I'm proposing that we just put the
name of the clock source in the device tree, and have a function which
converts that into an i
On Oct 9, 2007, at 1:12 PM, Timur Tabi wrote:
> Kumar Gala wrote:
>
>> rx-clock-type = "brg" or "clk"
>> rx-clock-id = 3
>> I don't see how this doesn't cover what you need in the device tree.
>
> That just looks more complicated than what my patch proposes. Why
> have two properties when one
Kumar Gala wrote:
> rx-clock-type = "brg" or "clk"
> rx-clock-id = 3
>
> I don't see how this doesn't cover what you need in the device tree.
That just looks more complicated than what my patch proposes. Why have two
properties when one will suffice? I still need to have a look-up table that
On Oct 9, 2007, at 11:48 AM, Timur Tabi wrote:
> Scott Wood wrote:
>
>> In the absence of a BRG, the driver should just not support
>> changing the baud rate -- it shouldn't fail to function.
>
> Since I don't have hardware that can test external clocks, I can't
> guarantee that any such code
On 10/8/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-10-08 at 22:43 -0600, Grant Likely wrote:
> > BTW, what path do framebuffer patches take to get into Linus' tree?
> > Does he pull your tree directly, or do they go through someone else's
> > tree?
>
> They all go to -mm tree,
On Mon, Oct 08, 2007 at 06:07:24PM -0700, Geoff Levand wrote:
> Subject: PS3: Add os-area database routines
>
> Add support for a simple tagged database in the PS3 flash rom
> os-area. The database allows the flash rom os-area to be shared
> between a bootloader and installed operating systems.
Scott Wood wrote:
> In the absence of a BRG, the driver should just not support changing the
> baud rate -- it shouldn't fail to function.
Since I don't have hardware that can test external clocks, I can't guarantee
that any such code will work.
I'm sure there are a dozen things I could do to
Timur Tabi wrote:
> Scott Wood wrote:
>
>> Or we could just stop putting CLK information in the device tree. :-)
>
> If we had a BRG/CLK manager, we probably could do that. But we don't
> have something like that now.
I didn't say stop putting BRG information in there -- just CLKs, which
are
Timur Tabi wrote:
> UART, for instance, can use a CLK signal, but I wrote the driver to only
> support BRGs because there are plenty of them and it's a lot simpler. But
> someone, for instance, could wire up his board to want to use external clocks
> for some UARTs, and so he'd need to modify t
Scott Wood wrote:
> Or we could just stop putting CLK information in the device tree. :-)
If we had a BRG/CLK manager, we probably could do that. But we don't have
something like that now.
--
Timur Tabi
Linux Kernel Developer @ Freescale
___
Linuxpp
Kumar Gala wrote:
> Ok, I went and looked at how rx-clock & tx-clock are spec'd in
> booting-without-of.txt
>
> Why dont we fix this so we have a property that says "BRG" or "CLK"
> and another that has ID = [1.16] for BRG and [1..24] for CLK.
Or we could keep it as it is, check the beginning
Kumar Gala wrote:
> Ok, I went and looked at how rx-clock & tx-clock are spec'd in
> booting-without-of.txt
>
> Why dont we fix this so we have a property that says "BRG" or "CLK" and
> another that has ID = [1.16] for BRG and [1..24] for CLK.
Because sometimes you can use both BRGs and CLKs.
Ok, I went and looked at how rx-clock & tx-clock are spec'd in
booting-without-of.txt
Why dont we fix this so we have a property that says "BRG" or "CLK"
and another that has ID = [1.16] for BRG and [1..24] for CLK.
- k
___
Linuxppc-dev mailing list
Kumar Gala wrote:
> is 19 the actual value you'd end up using from the HW? or is it related
> to some random enum value?
Random enum value. Here's the code in ucc_geth:
prop = of_get_property(np, "rx-clock", NULL);
ug_info->uf_info.rx_clock = *prop;
Here's the data type:
str
On Oct 9, 2007, at 11:01 AM, Timur Tabi wrote:
> Kumar Gala wrote:
>> On Oct 9, 2007, at 10:53 AM, Timur Tabi wrote:
>>> Add function qe_clock_source() which takes a string containing
>>> the name of a
>>> QE clock source (as is typically found in device trees) and
>>> returns the
>>> matchin
On Tue, Oct 09, 2007 at 01:07:29PM +1000, David Gibson wrote:
> On Mon, Oct 08, 2007 at 04:33:24PM -0500, Timur Tabi wrote:
> > Question: I'm building a kernel for the 8610. Why is treeboot-walnut.c
> > being compiled at all?
>
> Policy. Compiling everything means build bugs - like this one - ca
David Gibson wrote:
> Policy. Compiling everything means build bugs - like this one - can
> be found by everybody, not just those building for the specific
> obscure platform.
Is this a new policy? Modules in the kernel are not built unless you want
them. Even in arch/powerpc/platforms, only
Kumar Gala wrote:
>
> On Oct 9, 2007, at 10:53 AM, Timur Tabi wrote:
>
>> Add function qe_clock_source() which takes a string containing the
>> name of a
>> QE clock source (as is typically found in device trees) and returns the
>> matching enum qe_clock value.
>>
>> Signed-off-by: Timur Tabi <[
On Oct 9, 2007, at 9:38 AM, Grant Likely wrote:
> On 10/9/07, Marian Balakowicz <[EMAIL PROTECTED]> wrote:
>>
>> All,
>>
>> Thanks for the review, will process all the comments and resend
>> updated patches soon.
>
> Make sure you take a look at the 6 patches I posted yesterday. They
> will prob
On Oct 9, 2007, at 10:53 AM, Timur Tabi wrote:
> Add function qe_clock_source() which takes a string containing the
> name of a
> QE clock source (as is typically found in device trees) and returns
> the
> matching enum qe_clock value.
>
> Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
> ---
>
Add function qe_clock_source() which takes a string containing the name of a
QE clock source (as is typically found in device trees) and returns the
matching enum qe_clock value.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
This patch applies to Kumar's for-2.6.24 branch.
arch/powerpc/sysd
Kumar Gala wrote:
> $ make V=1
make ARCH=ppc64 -f scripts/Makefile.build obj=arch/powerpc/boot
arch/powerpc/boot/uImage powerpc-unknown-linux-gnu-gcc -m32
-Wp,-MD,arch/powerpc/boot/.treeboot-walnut.o.d -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -Os -msoft-float -pipe
On Oct 9, 2007, at 9:44 AM, Timur Tabi wrote:
> Kumar Gala wrote:
>
>> What's the actual compile line? Want to see the flags to
>> assembler of -Wa to the compiler.
>
> How do I modify the makefiles to spit out that command line?
try
$ make V=1
- k
__
On Tue, 9 Oct 2007, Timur Tabi wrote:
> Kumar Gala wrote:
>
> > What's the actual compile line? Want to see the flags to assembler of
> > -Wa to the compiler.
>
> How do I modify the makefiles to spit out that command line?
make V=1
With kind regards,
Geert Uytterhoeven
Software Architect
Kumar Gala wrote:
> What's the actual compile line? Want to see the flags to assembler of
> -Wa to the compiler.
How do I modify the makefiles to spit out that command line?
--
Timur Tabi
Linux Kernel Developer @ Freescale
___
Linuxppc-dev mailing l
On 10/9/07, Marian Balakowicz <[EMAIL PROTECTED]> wrote:
>
> All,
>
> Thanks for the review, will process all the comments and resend
> updated patches soon.
Make sure you take a look at the 6 patches I posted yesterday. They
will probably go in before your changes and will cause conflicts.
Kuma
On 10/9/07, Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> On Oct 8, 2007, at 5:25 PM, Grant Likely wrote:
>
> > From: Grant Likely <[EMAIL PROTECTED]>
> >
> > There is no good reason for board platform code to mess with the
> > ROOT_DEV.
> > Remove it from all in-tree platforms except powermac
> >
> >
On Oct 8, 2007, at 5:25 PM, Grant Likely wrote:
> From: Grant Likely <[EMAIL PROTECTED]>
>
> There is no good reason for board platform code to mess with the
> ROOT_DEV.
> Remove it from all in-tree platforms except powermac
>
> Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
> ---
>
> arch/po
On Oct 8, 2007, at 11:00 PM, Grant Likely wrote:
> On 10/8/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
>> Looks like the problem is back:
>>
>>BOOTCC arch/powerpc/boot/treeboot-walnut.o
>> Assembler messages:
>> Error: Internal assembler error for instruction icbt
>> Internal error, aborting a
I have just seen a crash at shutdown with 2.6.23-rc9 on an RS/6000
powerpc box (POWER3, 64-bit). It crashed immediately after printing
"Disabling non-boot CPUs", so I tried reverting 4047727e and that
fixed it. It's unfortunate that that commit added the
disable_nonboot_cpus for all architectures
On 09/10/2007, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
>
> On Mon, 8 Oct 2007, Ranulf Doswell wrote:
> > However, in this case the only data required is a single identifier used
> to
> > identify one PS3 from another, and in fact this single 64-bit token can
> be
> > shared amongst many other
On Mon, 8 Oct 2007, Geoff Levand wrote:
> o Add a KERN_WARNING message when flash driver is not available.
> --- a/arch/powerpc/platforms/ps3/os-area.c
> +++ b/arch/powerpc/platforms/ps3/os-area.c
> +static void update_flash_db(void)
> +{
> + int result;
> + int file;
> + off_t offs
Hi Olof,
On Monday 08 October 2007, Olof Johansson wrote:
> > +config KILAUEA
> > + bool "Kilauea"
> > + depends on 40x
> > + default y
> > + select 405EX
> > + help
> > + This option enables support for the AMCC PPC405EX evaluation board.
> > +
> > #config REDWOOD_5
> > # bool "R
Roland Dreier <[EMAIL PROTECTED]> wrote on 03.10.2007 20:05:44:
> > > Replace struct ibmebus_dev and struct ibmebus_driver with
> struct of_device
> > > and struct of_platform_driver, respectively. Match the external
ibmebus
> > > interface and drivers using it.
> > >
> > > Signed-off-by:
On Mon, 8 Oct 2007, Ranulf Doswell wrote:
> On 08/10/2007, Geoff Levand <[EMAIL PROTECTED]> wrote:
> > > How do we go about claiming one of these OS_AREA_DB_OWNER_ keys? I'd
> > > very much like to use this functionality in my python-ps3 games library.
> >
> > It sounds like you should be storing y
All,
Thanks for the review, will process all the comments and resend
updated patches soon.
Marian
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Hello Scott,
On Mon, 8 Oct 2007 17:48:47 -0500
Scott Wood wrote:
> Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
ok, will give it a try shortly.
patch looks good after a quick glance.
--
Sincerely, Vitaly
___
Linuxppc-dev mailing list
Linuxppc-dev@o
Our _GLOBAL macro does a ".align 2" so the alignment is fine for 32
bit, but on 64 bit it is possible for it to end up only 4 byte aligned.
I don't know if it matters, but it can't hurt to 8 byte align it.
It also means that when we build with --emit_relocs, none of our 64 bit
relocations are to m
61 matches
Mail list logo
