Re: PPC4xx maintainer?
Stefan Roese writes: > I really think that now, as the PPC4xx Linux development is picking up in > speed in the ongoing move to arch/powerpc, we need an "active" maintainer for > the 4xx Linux kernel platform. Since I haven't heard anything from Matt in a > long time, perhaps it would be better if somebody else takes care of this > matter. I propose that Josh Boyer takes over this maintainership, and I know > that he is competent enough and willing to dedicate the needed time for this > task. Glad you think so. :) I asked Josh to be the 4xx maintainer a couple of weeks ago but didn't make an announcement about it, which I should have done - sorry about that. Josh, please send me a patch for MAINTAINERS. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 4/4] 4xx: Convert Seqouia flash mappings to new binding
On Saturday 15 September 2007, David Gibson wrote: > On Fri, Sep 14, 2007 at 01:54:14PM -0500, Josh Boyer wrote: > > A new binding for flash devices was recently introduced. This updates > > the Sequoia DTS to use the new binding and enabled MTD in the defconfig. > > > > Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> > > Acked-by: David Gibson <[EMAIL PROTECTED]> Acked-by: Stefan Roese <[EMAIL PROTECTED]> Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 3/4] 4xx: Convert Walnut flash mappings to new binding
On Friday 14 September 2007, Josh Boyer wrote:
> A new binding for flash devices was recently introduced. This updates the
> Walnut DTS to use the new binding.
>
> Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/dts/walnut.dts | 17 -
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> --- linux-2.6.orig/arch/powerpc/boot/dts/walnut.dts
> +++ linux-2.6/arch/powerpc/boot/dts/walnut.dts
> @@ -137,6 +137,10 @@
> dcr-reg = <012 2>;
> #address-cells = <2>;
> #size-cells = <1>;
> + /* The ranges property is supplied by the bootwrapper
> + * and is based on the firmware's configuration of the
> + * EBC bridge
> + */
> clock-frequency = <0>; /* Filled in by zImage */
>
> [EMAIL PROTECTED],0 {
> @@ -144,13 +148,16 @@
> };
>
> [EMAIL PROTECTED],8 {
> - device_type = "rom";
> - compatible = "direct-mapped";
> - probe-type = "JEDEC";
> + compatible = "jedec-flash";
> bank-width = <1>;
> - partitions = <0 8>;
> - partition-names = "OpenBIOS";
> reg = <0 8 8>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + [EMAIL PROTECTED] {
> + label = "OpenBIOS";
> + reg = <0 8>;
> + read-only;
> + };
There are not only Bamboo board running PIBS, but running U-Boot too. How
should we handle this different FLASH partitioning? Same goes for Ebony too
btw.
Best regards,
Stefan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC4xx maintainer?
On Saturday 15 September 2007, David Gibson wrote: > > I second that nomination... Go JOSH! > > You're behind the times. Paulus has already annointed Josh as 4xx > maintainer. Excellent. That's good news. Good luck Josh. :) Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 2/4] Make partitions optional in physmap_of
On Fri, Sep 14, 2007 at 01:54:12PM -0500, Josh Boyer wrote: > The latest physmap_of driver has a small error where it will fail the probe > with: > > physmap-flash: probe of fff0.small-flas failed with error -2 > > if there are no partition subnodes in the device tree and the old style > binding > is not used. Since partition definitions are optional, the probe should still > succeed. > > Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> Acked-by: David Gibson <[EMAIL PROTECTED]> -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: rtc-ds1742.c should use resource_size_t for base address
On Fri, Sep 14, 2007 at 12:20:37PM -0500, Josh Boyer wrote: > On Fri, 14 Sep 2007 15:54:27 +1000 > David Gibson <[EMAIL PROTECTED]> wrote: > > > Currently the rtc driver, rtc-ds1742.c uses an unsigned long to store > > the base mmio address of the NVRAM/RTC. This breaks on systems like > > PowerPC 440, which is a 32-bit core with 36-bit physical addresses: IO > > on the system, including the RTC, is typically above the 4GB point, > > and cannot fit into an unsigned long. > > > > This patch fixes the problem by replacing the unsigned long with a > > resource_size_t. Tested on Ebony (PPC440) (with additional patches to > > instantiate the ds1742 platform device appropriately). > > Where would those additional patches be? :) Coming, they still need polish... -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/4] cuimage for Bamboo board
On Fri, Sep 14, 2007 at 01:54:11PM -0500, Josh Boyer wrote:
> Add a cuboot wrapper for the Bamboo board. This also removes some obsoleted
> linker declarations that have been moved into ops.h
>
> Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
> Acked-by: David Gibson <[EMAIL PROTECTED]>
Heh, well, I know I acked this already, but...
[snip]
> --- /dev/null
> +++ linux-2.6/arch/powerpc/boot/cuboot-bamboo.c
> @@ -0,0 +1,30 @@
> +/*
> + * Old U-boot compatibility for Ebony
Error in the comment here.
[snip]
> --- linux-2.6.orig/arch/powerpc/boot/bamboo.c
> +++ linux-2.6/arch/powerpc/boot/bamboo.c
> @@ -24,8 +24,7 @@
> #include "4xx.h"
> #include "44x.h"
>
> -extern char _dtb_start[];
> -extern char _dtb_end[];
> +static u8 *bamboo_mac0, *bamboo_mac1;
This additional handling of the MAC addresses should really also be
mentioned in the commit comment.
>
> static void bamboo_fixups(void)
> {
> @@ -34,12 +33,15 @@ static void bamboo_fixups(void)
> ibm440ep_fixup_clocks(sysclk, 11059200);
> ibm4xx_fixup_memsize();
> ibm4xx_quiesce_eth((u32 *)0xef600e00, (u32 *)0xef600f00);
> + dt_fixup_mac_addresses(bamboo_mac0, bamboo_mac1);
> }
>
> -void bamboo_init(void)
> +void bamboo_init(void *mac0, void *mac1)
> {
> platform_ops.fixups = bamboo_fixups;
> platform_ops.exit = ibm44x_dbcr_reset;
> + bamboo_mac0 = mac0;
> + bamboo_mac1 = mac1;
> ft_init(_dtb_start, 0, 32);
> serial_console_init();
> }
> --- linux-2.6.orig/arch/powerpc/boot/treeboot-bamboo.c
> +++ linux-2.6/arch/powerpc/boot/treeboot-bamboo.c
> @@ -12,16 +12,32 @@
> #include "ops.h"
> #include "stdio.h"
> #include "44x.h"
> -
> -extern char _end[];
> +#include "stdlib.h"
>
> BSS_STACK(4096);
>
> +#define PIBS_MAC0 0xfffc0400
> +#define PIBS_MAC1 0xfffc0500
> +char pibs_mac0[6];
> +char pibs_mac1[6];
> +
> +static void read_pibs_mac(void)
> +{
> + unsigned long long mac64;
> +
> + mac64 = strtoull((char *)PIBS_MAC0, 0, 16);
> + memcpy(&pibs_mac0, (char *)&mac64+2, 6);
> +
> + mac64 = strtoull((char *)PIBS_MAC1, 0, 16);
> + memcpy(&pibs_mac1, (char *)&mac64+2, 6);
> +}
> +
> void platform_init(void)
> {
> unsigned long end_of_ram = 0x800;
> unsigned long avail_ram = end_of_ram - (unsigned long)_end;
>
> simple_alloc_init(_end, avail_ram, 32, 64);
> - bamboo_init();
> + read_pibs_mac();
> + bamboo_init((u8 *)&pibs_mac0, (u8 *)&pibs_mac1);
> }
>
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 3/4] 4xx: Convert Walnut flash mappings to new binding
On Fri, Sep 14, 2007 at 01:54:13PM -0500, Josh Boyer wrote: > A new binding for flash devices was recently introduced. This updates the > Walnut DTS to use the new binding. > > Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> Acked-by: David Gibson <[EMAIL PROTECTED]> We should both really figure out the vendor/device ids of the JEDEC flash chips in use here and on Ebony, and add the appropriate properties as per the binding. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 4/4] 4xx: Convert Seqouia flash mappings to new binding
On Fri, Sep 14, 2007 at 01:54:14PM -0500, Josh Boyer wrote: > A new binding for flash devices was recently introduced. This updates the > Sequoia DTS to use the new binding and enabled MTD in the defconfig. > > Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> Acked-by: David Gibson <[EMAIL PROTECTED]> -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/9] 8xx: Infrastructure code cleanup.
On Fri, Sep 14, 2007 at 12:21:14PM +0400, Vitaly Bordug wrote: > Hello David, > > On Fri, 14 Sep 2007 14:09:34 +1000 > David Gibson wrote: > > > On Thu, Sep 13, 2007 at 12:16:40PM +0400, Vitaly Bordug wrote: > > [snip] > > > > This looks bogus. You're replacing the old crap immr_map() functions, > > > > which ioremap()ed the registers every time, with a much simpler > > > > version which uses an established-once mapping of the register > > > > region. AFAICT, anywah. > > > > > > > > So far, so good - but your immr_unmap() still does an iounmap() which > > > > is surely wrong - it should now be a no-op, leaving the mpc8xx_immr > > > > mapping intact. You probably get away with it by accident, because I > > > > imagine attempting to unmap an unaligned chunk of the region will just > > > > fail. > > > > > > > > > > yes, it should do nop instead of iounmap. > > > > In fact, with this patch in place, I'd like to see another patch which > > > > removes all calls to immr_map() and immr_unmap(), simply accessing the > > > > common mapping directly. > > > > > > > Sorry, but originally, that stuff was created to get rid of BSP > > > ifdefs in drivers. For PQ family, it is a common practice to have > > > single driver handling all 3 CPU families, which use the same logic, > > > but immr structure differs a little bit. > > > > > > At this point it's clear case-by-case ioremapping does not have firm > > > benefit, but getting back to the way it was is useless either. In > > > ideal world, we'd have all those stuff put into dts and have > > > specific drivers be a shim layer between core hw and IO drivers. > > > > Err.. I don't understand what you're getting at. As the code stands > > after Scott's cleanup, the map() and unmap() calls can certainly be > > trivially removed, regardless of the history for them. > > > I don't argue if they can be removed, but if we aught to do > that. Direct immr dereference adds plenty of mess into driver Um... better one line of mess than the 3 lines it is now (map/access/unmap). > code. I would like to keep the situation when immr accesses factored > out as a starting point, rather then turn them back to &immap-> or > cpm2_immr-> refs. I can see no advantage to the current "factoring". > > And, yes, the drivers should certainly uses addresses from the device > > tree, rather than that revolting structure covering all the inbuilt > > device retgisters. > hehe, then you prolly know, that this structure does not fin well > into device/driver model, either platform_ or of_device. And I am > going to sort it out at some point... Well, that's good to know. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC4xx maintainer?
On Fri, Sep 14, 2007 at 02:11:55PM -0600, Grant Likely wrote: > On 9/14/07, Stefan Roese <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I really think that now, as the PPC4xx Linux development is picking up in > > speed in the ongoing move to arch/powerpc, we need an "active" maintainer > > for > > the 4xx Linux kernel platform. Since I haven't heard anything from Matt in a > > long time, perhaps it would be better if somebody else takes care of this > > matter. I propose that Josh Boyer takes over this maintainership, and I know > > that he is competent enough and willing to dedicate the needed time for this > > task. > > > > What do you think? Any other ideas on this? > > I second that nomination... Go JOSH! You're behind the times. Paulus has already annointed Josh as 4xx maintainer. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add Kconfig option for optimizing for cell
On Sat, 2007-09-15 at 03:02 +0200, Arnd Bergmann wrote: > On Saturday 15 September 2007, Josh Boyer wrote: > > On Sat, 2007-09-15 at 02:21 +0200, Arnd Bergmann wrote: > > > Since the PPE on cell is an in-order core, it suffers significantly > > > from wrong instruction scheduling. This adds an Kconfig option that > > > enables passing -mtune=cell to gcc in order to generate object > > > code that runs well on cell. > > > > Which version of gcc supports that? > > > > gcc-4.3 will be the first official release that has everything in it, > and I think 4.1 has some parts. However, there are many patched gcc > versions in various distributions, so I tried to avoid being too > specific about the version here. > > Of course, on gcc versions that don't support -mtune=cell, the > Kconfig option does not make a difference. Sure. I was just wondering if mentioning the first official GCC version in the Kconfig description would help prevent users from selecting the option for GCCs that don't support it and then being confused later when nothing happens. Your call though. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add Kconfig option for optimizing for cell
On Saturday 15 September 2007, Segher Boessenkool wrote: > > > +config TUNE_CELL > > + bool "Optimize for Cell Broadband Engine" > > + depends on PPC64 > > + help > > + Cause the compiler to optimize for the PPE of the Cell Broadband > > + Engine. This will make the code run considerably faster on Cell > > + but somewhat slower on other machines. This option only changes > > + the scheduling of instructions, not the selection of instructions > > + itself, > > It _does_ change instruction selection, which is the main factor > in the slowdown on other machines (and a big part of the speedup > on Cell, too). It doesn't change which insns the compiler is > allowed to use though, which is probably what you wanted to say? Right, thanks for the correction. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add Kconfig option for optimizing for cell
On Saturday 15 September 2007, Josh Boyer wrote: > On Sat, 2007-09-15 at 02:21 +0200, Arnd Bergmann wrote: > > Since the PPE on cell is an in-order core, it suffers significantly > > from wrong instruction scheduling. This adds an Kconfig option that > > enables passing -mtune=cell to gcc in order to generate object > > code that runs well on cell. > > Which version of gcc supports that? > gcc-4.3 will be the first official release that has everything in it, and I think 4.1 has some parts. However, there are many patched gcc versions in various distributions, so I tried to avoid being too specific about the version here. Of course, on gcc versions that don't support -mtune=cell, the Kconfig option does not make a difference. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add Kconfig option for optimizing for cell
> +config TUNE_CELL > + bool "Optimize for Cell Broadband Engine" > + depends on PPC64 > + help > + Cause the compiler to optimize for the PPE of the Cell Broadband > + Engine. This will make the code run considerably faster on Cell > + but somewhat slower on other machines. This option only changes > + the scheduling of instructions, not the selection of instructions > + itself, It _does_ change instruction selection, which is the main factor in the slowdown on other machines (and a big part of the speedup on Cell, too). It doesn't change which insns the compiler is allowed to use though, which is probably what you wanted to say? Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add Kconfig option for optimizing for cell
On Sat, 2007-09-15 at 02:21 +0200, Arnd Bergmann wrote: > Since the PPE on cell is an in-order core, it suffers significantly > from wrong instruction scheduling. This adds an Kconfig option that > enables passing -mtune=cell to gcc in order to generate object > code that runs well on cell. Which version of gcc supports that? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] add Kconfig option for optimizing for cell
Since the PPE on cell is an in-order core, it suffers significantly from wrong instruction scheduling. This adds an Kconfig option that enables passing -mtune=cell to gcc in order to generate object code that runs well on cell. Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> --- diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 6015a92..87aff53 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -92,6 +92,10 @@ else endif endif +ifeq ($(CONFIG_TUNE_CELL),y) + CFLAGS += $(call cc-option,-mtune=cell) +endif + # No AltiVec instruction when building kernel CFLAGS += $(call cc-option,-mno-altivec) diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype index 86eb4cf..4c315be 100644 --- a/arch/powerpc/platforms/Kconfig.cputype +++ b/arch/powerpc/platforms/Kconfig.cputype @@ -71,6 +71,18 @@ config POWER4 depends on PPC64 def_bool y +config TUNE_CELL + bool "Optimize for Cell Broadband Engine" + depends on PPC64 + help + Cause the compiler to optimize for the PPE of the Cell Broadband + Engine. This will make the code run considerably faster on Cell + but somewhat slower on other machines. This option only changes + the scheduling of instructions, not the selection of instructions + itself, so the resulting kernel will keep running on all other + machines. When building a kernel that is supposed to run only + on Cell, you should also select the POWER4_ONLY option. + config 6xx bool ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device tree aware EMAC driver
On Thu, 2007-08-23 at 09:30 +0200, Benjamin Herrenschmidt wrote: > On Thu, 2007-08-23 at 13:56 +1000, David Gibson wrote: > > > > > > Jeff, I've discussed this with BenH, and although there are some > > problems with the driver still, we think it's good enough to merge in > > 2.6.24, the warts can be fixed up later. Please apply... > > Or to be more precise: > > This driver will work well for 4xx platforms and will allow us to move a > big step toward getting rid of arch/ppc. The issues with DMA mapping > really only concern the case where this is used within the cell "Axon" > southbridge, which doesn't happen on any released product at this stage. Since we have 4 boards that could use this now, and at least one more on the way, I've put this in the 'emac' branch of my git tree. That branch is based off of the current 'upstream' branch of the netdev-2.6 tree. This is just intended to make it easier for those that want to use ibm_newemac on their boards while we work the driver into the netdev tree. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 00/10] x86: Reduce Memory Usage and Inter-Node message traffic (v3)
On Tue, 11 Sep 2007 18:56:44 -0700 [EMAIL PROTECTED] wrote: > Changes for version v3: > > cpu_sibling_map has been converted to a per_cpu data array to fix > build errors on ia64, ppc64 and sparc64 to accomodate references in > block/blktrace.c and kernel/sched.c when CONFIG_SCHED_SMT is defined. > > Warning: ppc64 and sparc64 have not yet been built nor tested. These patches all seem to be unaltered from what I had. The first patch (x86: remove x86_cpu_to_log_apicid array) is in Andi's tree as x86_64-mm-remove-x86_cpu_to_log_apicid.patch so I don't apply that. The sparc64/ppc64/ia64 convert-cpu_sibling_map-to-a-per_cpu-data-array patches need to be folded into the base patch so that we don't break the build at any stage. So what I ended up with was x86-fix-cpu_to_node-references.patch x86-convert-cpu_core_map-to-be-a-per-cpu-variable.patch convert-cpu_sibling_map-to-be-a-per-cpu-variable.patch convert-cpu_sibling_map-to-a-per_cpu-data-array-ia64.patch convert-cpu_sibling_map-to-a-per_cpu-data-array-ppc64.patch convert-cpu_sibling_map-to-a-per_cpu-data-array-sparc64.patch x86-convert-x86_cpu_to_apicid-to-be-a-per-cpu-variable.patch x86-convert-cpu_llc_id-to-be-a-per-cpu-variable.patch where the four convert-cpu_sibling_map-to-* will be clumped into a single diff. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Define termios_1 functions for powerpc, s390, avr32 and frv
From: Andrew Morton <[EMAIL PROTECTED]> Date: Fri, 14 Sep 2007 15:12:53 -0700 > That fixes sparc, but I think other architectures are still broken. And if > we use Tony's ifdef patch to fix the other architectures, that makes the > above sparc-fix patch unneeded. > > argh. I don't care if we use Tony's fix or mine, both are fine. What I do care about is that I spent 24 hours on trains and planes, only to find more than a day later that Sparc still didn't build. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Define termios_1 functions for powerpc, s390, avr32 and frv
On Fri, 14 Sep 2007 11:33:24 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Thu, 13 Sep 2007 03:55:06 -0700
>
> > I think we need to go with Tony's patch. sparc32 and sparc64 are
> > presently broken too, and the patch which converts sparc to use the
> > new interfaces introduces a few build errors.
>
> The problem with the asm-generic/termios.h thing is it only works
> if your copying functions are just a copy_{to,from}_user() and you
> can define that __ARCH_* macro.
>
> In retrospect what that header should do is, outside of the
> ARCH_* block, define the foo_1 interfaces plainly to foo.
>
> Alternatively, here is a patch that gets sparc compiling and
> working again in the current tree.
>
> This whole termios thing hasn't been handled very well, and it's maybe
> not what we should be doing so late in the -rc cycle. And yes,
> this is coming from the guy who added the TCP oops'er two weeks ago
> :-P
tell me about it.
> [SPARC]: Fix build due to termios changes.
>
> Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
>
> diff --git a/include/asm-sparc/termios.h b/include/asm-sparc/termios.h
> index d767f20..25e9cbb 100644
> --- a/include/asm-sparc/termios.h
> +++ b/include/asm-sparc/termios.h
> @@ -142,6 +142,11 @@ struct winsize {
> 0; \
> })
>
> +#define user_termios_to_kernel_termios_1(k, u) \
> + user_termios_to_kernel_termios(k, u)
> +#define kernel_termios_to_user_termios_1(u, k) \
> + kernel_termios_to_user_termios(u, k)
> +
> #endif /* __KERNEL__ */
>
> #endif /* _SPARC_TERMIOS_H */
> diff --git a/include/asm-sparc64/termios.h b/include/asm-sparc64/termios.h
> index f05d390..6fc71e6 100644
> --- a/include/asm-sparc64/termios.h
> +++ b/include/asm-sparc64/termios.h
> @@ -145,6 +145,11 @@ struct winsize {
> err; \
> })
>
> +#define user_termios_to_kernel_termios_1(k, u) \
> + user_termios_to_kernel_termios(k, u)
> +#define kernel_termios_to_user_termios_1(u, k) \
> + kernel_termios_to_user_termios(u, k)
> +
> #endif /* __KERNEL__ */
>
> #endif /* _SPARC64_TERMIOS_H */
That fixes sparc, but I think other architectures are still broken. And if
we use Tony's ifdef patch to fix the other architectures, that makes the
above sparc-fix patch unneeded.
argh.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] fix xmon input on 440
Implement udbg_getc() for 440, which fixes xmon input.
Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/kernel/udbg_16550.c b/arch/powerpc/kernel/udbg_16550.c
--- a/arch/powerpc/kernel/udbg_16550.c
+++ b/arch/powerpc/kernel/udbg_16550.c
@@ -206,11 +206,22 @@ static void udbg_44x_as1_putc(char c)
}
}
+static int udbg_44x_as1_getc(void)
+{
+ if (udbg_comport) {
+ while ((as1_readb(&udbg_comport->lsr) & LSR_DR) == 0)
+ /* wait for char */;
+ return as1_readb(&udbg_comport->rbr);
+ }
+ return -1;
+}
+
void __init udbg_init_44x_as1(void)
{
udbg_comport =
(volatile struct NS16550 __iomem *)PPC44x_EARLY_DEBUG_VIRTADDR;
udbg_putc = udbg_44x_as1_putc;
+ udbg_getc = udbg_44x_as1_getc;
}
#endif /* CONFIG_PPC_EARLY_DEBUG_44x */
--
Hollis Blanchard
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: CONFIG_BLK_DEV_BSG=n
On Fri, 2007-09-14 at 12:50 -0700, Medve Emilian-EMMEDVE1 wrote: > Which solution would you be more comfortable with? The one which is currently in -mm is this one: http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commit;h=49892223f7d3a2333ef9e6cbdd526676e1fc517a James ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC4xx maintainer?
On 9/14/07, Stefan Roese <[EMAIL PROTECTED]> wrote: > Hi, > > I really think that now, as the PPC4xx Linux development is picking up in > speed in the ongoing move to arch/powerpc, we need an "active" maintainer for > the 4xx Linux kernel platform. Since I haven't heard anything from Matt in a > long time, perhaps it would be better if somebody else takes care of this > matter. I propose that Josh Boyer takes over this maintainership, and I know > that he is competent enough and willing to dedicate the needed time for this > task. > > What do you think? Any other ideas on this? I second that nomination... Go JOSH! :-) -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
PPC4xx maintainer?
Hi, I really think that now, as the PPC4xx Linux development is picking up in speed in the ongoing move to arch/powerpc, we need an "active" maintainer for the 4xx Linux kernel platform. Since I haven't heard anything from Matt in a long time, perhaps it would be better if somebody else takes care of this matter. I propose that Josh Boyer takes over this maintainership, and I know that he is competent enough and willing to dedicate the needed time for this task. What do you think? Any other ideas on this? Thanks. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
CONFIG_BLK_DEV_BSG=n
Hello,
I'm trying to get powerpc to build without block device support
(CONFIG_BLOCK=n). I'm getting the following errors:
CC arch/powerpc/kernel/setup_32.o
In file included from include/linux/blkdev.h:17,
from include/linux/ide.h:13,
from arch/powerpc/kernel/setup_32.c:13:
include/linux/bsg.h:67: warning: 'struct request_queue' declared inside
parameter list
include/linux/bsg.h:67: warning: its scope is only this definition or
declaration, which is probably not what you want
include/linux/bsg.h:71: warning: 'struct request_queue' declared inside
parameter list
In file included from arch/powerpc/kernel/setup_32.c:13:
include/linux/ide.h:857: error: field 'wrq' has incomplete type
CC arch/powerpc/kernel/ppc_ksyms.o
In file included from include/linux/blkdev.h:17,
from include/linux/ide.h:13,
from arch/powerpc/kernel/ppc_ksyms.c:15:
include/linux/bsg.h:67: warning: 'struct request_queue' declared inside
parameter list
include/linux/bsg.h:67: warning: its scope is only this definition or
declaration, which is probably not what you want
include/linux/bsg.h:71: warning: 'struct request_queue' declared inside
parameter list
In file included from arch/powerpc/kernel/ppc_ksyms.c:15:
include/linux/ide.h:857: error: field 'wrq' has incomplete type
I fixed the errors with a small patch in the powerpc code only and I'm
comfortable with that. The matter I wanted your input on is the warnings
from bsg.h coming from this are of the file:
...
#ifdef __KERNEL__
#if defined(CONFIG_BLK_DEV_BSG)
struct bsg_class_device {
struct class_device *class_dev;
struct device *dev;
int minor;
struct request_queue *queue;
};
extern int bsg_register_queue(struct request_queue *, struct device *,
const char *);
extern void bsg_unregister_queue(struct request_queue *);
#else
static inline int bsg_register_queue(struct request_queue * rq, struct
device *dev, const char *name
)
{
return 0;
}
static inline void bsg_unregister_queue(struct request_queue *rq)
{
}
#endif
#endif /* __KERNEL__ */
...
I noticed that the '#else' branch was last updated by James (a4ee0df8)
in order to address some other warnings in scsi_sysfs.c, for example, in
the next piece of code:
...
error = bsg_register_queue(rq, &sdev->sdev_gendev, NULL);
if (error)
sdev_printk(KERN_INFO, sdev,
"Failed to register bsg queue, errno=%d\n",
error);
/* we're treating error on bsg register as non-fatal, so pretend
* nothing went wrong */
error = 0;
...
The quick fix to those warnings is to add a declaration of struct
request_queue in bsg.h something looking like this:
...
#ifdef __KERNEL__
struct request_queue; <- This is the addition
#if defined(CONFIG_BLK_DEV_BSG)
struct bsg_class_device {
struct class_device *class_dev;
...
However, I was wondering if there isn't a cleaner way of doing it. For
example, from the comments in scsi_sysfs.c it looks like it would be
possible not to call bsg_register_queue() at all when
CONFIG_BLK_DEV_BSG=n and get rid of the '#else' branch in bsg.h as I
don't think bsg_register_queue() and bsg_unregister_queue() should be
called when CONFIG_BLK_DEV_BSG=n.
Which solution would you be more comfortable with?
Thanks,
Emil.
This e-mail, and any associated attachments have been classified as:
[ ] Public
[x] Freescale Semiconductor Internal Use Only
[ ] Freescale Semiconductor Confidential Proprietary
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 0/4] Small 4xx updates for 2.6.24
On Fri, 14 Sep 2007 13:59:14 -0500 Josh Boyer <[EMAIL PROTECTED]> wrote: > Below is a small update series for 4xx that I intend to put in my > 2.6.24 branch soon and send to Paul. It contains an already acked > cuboot wrapper for Bamboo, a fix for the newly updated physmap_of > driver, and updates to the walnut and sequoia flash nodes in the DTS > files. Ignore this particular email. I had two mailers competing to send out patches and couldn't kill one of them before this got out. The other one with the patches actually following it is the right one :) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 0/4] Small 4xx updates for 2.6.24
Below is a small update series for 4xx that I intend to put in my 2.6.24 branch soon and send to Paul. It contains an already acked cuboot wrapper for Bamboo, a fix for the newly updated physmap_of driver, and updates to the walnut and sequoia flash nodes in the DTS files. josh -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 3/4] 4xx: Convert Walnut flash mappings to new binding
A new binding for flash devices was recently introduced. This updates the
Walnut DTS to use the new binding.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/walnut.dts | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
--- linux-2.6.orig/arch/powerpc/boot/dts/walnut.dts
+++ linux-2.6/arch/powerpc/boot/dts/walnut.dts
@@ -137,6 +137,10 @@
dcr-reg = <012 2>;
#address-cells = <2>;
#size-cells = <1>;
+ /* The ranges property is supplied by the bootwrapper
+* and is based on the firmware's configuration of the
+* EBC bridge
+*/
clock-frequency = <0>; /* Filled in by zImage */
[EMAIL PROTECTED],0 {
@@ -144,13 +148,16 @@
};
[EMAIL PROTECTED],8 {
- device_type = "rom";
- compatible = "direct-mapped";
- probe-type = "JEDEC";
+ compatible = "jedec-flash";
bank-width = <1>;
- partitions = <0 8>;
- partition-names = "OpenBIOS";
reg = <0 8 8>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ [EMAIL PROTECTED] {
+ label = "OpenBIOS";
+ reg = <0 8>;
+ read-only;
+ };
};
[EMAIL PROTECTED],0 {
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 1/4] cuimage for Bamboo board
Add a cuboot wrapper for the Bamboo board. This also removes some obsoleted
linker declarations that have been moved into ops.h
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
Acked-by: David Gibson <[EMAIL PROTECTED]>
---
arch/powerpc/boot/44x.h |2 +-
arch/powerpc/boot/Makefile |4 ++--
arch/powerpc/boot/bamboo.c |8 +---
arch/powerpc/boot/cuboot-bamboo.c | 30 ++
arch/powerpc/boot/treeboot-bamboo.c | 22 +++---
5 files changed, 57 insertions(+), 9 deletions(-)
--- linux-2.6.orig/arch/powerpc/boot/Makefile
+++ linux-2.6/arch/powerpc/boot/Makefile
@@ -49,7 +49,7 @@ src-wlib := string.S crt0.S stdio.c main
src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
- cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c
+ cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c cuboot-bamboo.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -146,7 +146,7 @@ image-$(CONFIG_8260)+= cuImage.pq2
image-$(CONFIG_PPC_83xx) += cuImage.83xx
image-$(CONFIG_PPC_85xx) += cuImage.85xx
image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
-image-$(CONFIG_BAMBOO) += treeImage.bamboo
+image-$(CONFIG_BAMBOO) += treeImage.bamboo cuImage.bamboo
image-$(CONFIG_SEQUOIA)+= cuImage.sequoia
image-$(CONFIG_WALNUT) += treeImage.walnut
endif
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/cuboot-bamboo.c
@@ -0,0 +1,30 @@
+/*
+ * Old U-boot compatibility for Ebony
+ *
+ * Author: Josh Boyer <[EMAIL PROTECTED]>
+ *
+ * Copyright 2007 IBM Corporation
+ *
+ * Based on cuboot-ebony.c
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "ops.h"
+#include "stdio.h"
+#include "44x.h"
+#include "cuboot.h"
+
+#define TARGET_44x
+#include "ppcboot.h"
+
+static bd_t bd;
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ CUBOOT_INIT();
+ bamboo_init(&bd.bi_enetaddr, &bd.bi_enet1addr);
+}
--- linux-2.6.orig/arch/powerpc/boot/44x.h
+++ linux-2.6/arch/powerpc/boot/44x.h
@@ -11,6 +11,6 @@
#define _PPC_BOOT_44X_H_
void ebony_init(void *mac0, void *mac1);
-void bamboo_init(void);
+void bamboo_init(void *mac0, void *mac1);
#endif /* _PPC_BOOT_44X_H_ */
--- linux-2.6.orig/arch/powerpc/boot/bamboo.c
+++ linux-2.6/arch/powerpc/boot/bamboo.c
@@ -24,8 +24,7 @@
#include "4xx.h"
#include "44x.h"
-extern char _dtb_start[];
-extern char _dtb_end[];
+static u8 *bamboo_mac0, *bamboo_mac1;
static void bamboo_fixups(void)
{
@@ -34,12 +33,15 @@ static void bamboo_fixups(void)
ibm440ep_fixup_clocks(sysclk, 11059200);
ibm4xx_fixup_memsize();
ibm4xx_quiesce_eth((u32 *)0xef600e00, (u32 *)0xef600f00);
+ dt_fixup_mac_addresses(bamboo_mac0, bamboo_mac1);
}
-void bamboo_init(void)
+void bamboo_init(void *mac0, void *mac1)
{
platform_ops.fixups = bamboo_fixups;
platform_ops.exit = ibm44x_dbcr_reset;
+ bamboo_mac0 = mac0;
+ bamboo_mac1 = mac1;
ft_init(_dtb_start, 0, 32);
serial_console_init();
}
--- linux-2.6.orig/arch/powerpc/boot/treeboot-bamboo.c
+++ linux-2.6/arch/powerpc/boot/treeboot-bamboo.c
@@ -12,16 +12,32 @@
#include "ops.h"
#include "stdio.h"
#include "44x.h"
-
-extern char _end[];
+#include "stdlib.h"
BSS_STACK(4096);
+#define PIBS_MAC0 0xfffc0400
+#define PIBS_MAC1 0xfffc0500
+char pibs_mac0[6];
+char pibs_mac1[6];
+
+static void read_pibs_mac(void)
+{
+ unsigned long long mac64;
+
+ mac64 = strtoull((char *)PIBS_MAC0, 0, 16);
+ memcpy(&pibs_mac0, (char *)&mac64+2, 6);
+
+ mac64 = strtoull((char *)PIBS_MAC1, 0, 16);
+ memcpy(&pibs_mac1, (char *)&mac64+2, 6);
+}
+
void platform_init(void)
{
unsigned long end_of_ram = 0x800;
unsigned long avail_ram = end_of_ram - (unsigned long)_end;
simple_alloc_init(_end, avail_ram, 32, 64);
- bamboo_init();
+ read_pibs_mac();
+ bamboo_init((u8 *)&pibs_mac0, (u8 *)&pibs_mac1);
}
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 2/4] Make partitions optional in physmap_of
The latest physmap_of driver has a small error where it will fail the probe
with:
physmap-flash: probe of fff0.small-flas failed with error -2
if there are no partition subnodes in the device tree and the old style binding
is not used. Since partition definitions are optional, the probe should still
succeed.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
drivers/mtd/maps/physmap_of.c |2 ++
1 file changed, 2 insertions(+)
--- linux-2.6.orig/drivers/mtd/maps/physmap_of.c
+++ linux-2.6/drivers/mtd/maps/physmap_of.c
@@ -142,6 +142,8 @@ static int __devinit process_partitions(
}
} else {
nr_parts = parse_obsolete_partitions(dev, info, dp);
+ if (nr_parts == -ENOENT)
+ nr_parts = 0;
}
if (nr_parts < 0)
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 4/4] 4xx: Convert Seqouia flash mappings to new binding
A new binding for flash devices was recently introduced. This updates the
Sequoia DTS to use the new binding and enabled MTD in the defconfig.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/sequoia.dts | 38 +
arch/powerpc/configs/sequoia_defconfig | 91 +++--
2 files changed, 115 insertions(+), 14 deletions(-)
--- linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts
+++ linux-2.6/arch/powerpc/boot/dts/sequoia.dts
@@ -142,19 +142,35 @@
interrupt-parent = <&UIC1>;
[EMAIL PROTECTED],0 {
- device_type = "rom";
- compatible = "direct-mapped";
- probe-type = "CFI";
+ compatible = "amd,s29gl256n",
"cfi-flash";
bank-width = <2>;
- partitions = < 0 18
- 18 20
- 38 3aa
- 3e2 14
- 3f6 4
- 3fa 6>;
- partition-names = "Kernel", "ramdisk",
"file system",
- "kozio", "env",
"u-boot";
reg = <0 00 400>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ [EMAIL PROTECTED] {
+ label = "Kernel";
+ reg = <0 18>;
+ };
+ [EMAIL PROTECTED] {
+ label = "ramdisk";
+ reg = <18 20>;
+ };
+ [EMAIL PROTECTED] {
+ label = "file system";
+ reg = <38 3aa>;
+ };
+ [EMAIL PROTECTED] {
+ label = "kozio";
+ reg = <3e2 14>;
+ };
+ [EMAIL PROTECTED] {
+ label = "env";
+ reg = <3f6 4>;
+ };
+ [EMAIL PROTECTED] {
+ label = "u-boot";
+ reg = <3fa 6>;
+ };
};
};
--- linux-2.6.orig/arch/powerpc/configs/sequoia_defconfig
+++ linux-2.6/arch/powerpc/configs/sequoia_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.23-rc3
-# Mon Aug 27 20:19:13 2007
+# Linux kernel version: 2.6.23-rc6
+# Fri Sep 14 13:20:06 2007
#
# CONFIG_PPC64 is not set
@@ -146,6 +146,7 @@ CONFIG_440A=y
# CONFIG_GENERIC_IOMAP is not set
# CONFIG_CPU_FREQ is not set
# CONFIG_CPM2 is not set
+# CONFIG_FSL_ULI1575 is not set
#
# Kernel options
@@ -317,7 +318,81 @@ CONFIG_FW_LOADER=y
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
-# CONFIG_MTD is not set
+CONFIG_MTD=y
+# CONFIG_MTD_DEBUG is not set
+# CONFIG_MTD_CONCAT is not set
+CONFIG_MTD_PARTITIONS=y
+# CONFIG_MTD_REDBOOT_PARTS is not set
+CONFIG_MTD_CMDLINE_PARTS=y
+
+#
+# User Modules And Translation Layers
+#
+CONFIG_MTD_CHAR=y
+# CONFIG_MTD_BLKDEVS is not set
+# CONFIG_MTD_BLOCK is not set
+# CONFIG_MTD_BLOCK_RO is not set
+# CONFIG_FTL is not set
+# CONFIG_NFTL is not set
+# CONFIG_INFTL is not set
+# CONFIG_RFD_FTL is not set
+# CONFIG_SSFDC is not set
+
+#
+# RAM/ROM/Flash chip drivers
+#
+CONFIG_MTD_CFI=y
+CONFIG_MTD_JEDECPROBE=y
+CONFIG_MTD_GEN_PROBE=y
+# CONFIG_MTD_CFI_ADV_OPTIONS is not set
+CONFIG_MTD_MAP_BANK_WIDTH_1=y
+CONFIG_MTD_MAP_BANK_WIDTH_2=y
+CONFIG_MTD_MAP_BANK_WIDTH_4=y
+# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
+CONFIG_MTD_CFI_I1=y
+CONFIG_MTD_CFI_I2=y
+# CONFIG_MTD_CFI_I4 is not set
+# CONFIG_MTD_CFI_I8 is not set
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_CFI_AMDSTD=y
+# CONFIG_MTD_CFI_STAA is not set
+CONFIG_MTD_CFI_UTIL=y
+# CONFIG_MTD_RAM i
[patch 0/4] Small 4xx updates for 2.6.24
Below is a small update series for 4xx that I intend to put in my 2.6.24 branch soon and send to Paul. It contains an already acked cuboot wrapper for Bamboo, a fix for the newly updated physmap_of driver, and updates to the walnut and sequoia flash nodes in the DTS files. josh -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from for-2.6.24
Dropped for now. I doubt we want this based on Segher's comments. (pretty sure its a ts108 on the hpc2 board). >>> >>> It is a tsi108 on hpc2. Holly has tsi109. From a Linux perspective, >>> there is no difference. And the comment Segher made on the list was >>> "Looks good, thanks!" So what other comment are you talking about? >> >> I think that was to the .dts clean ups. The patch from Roy wasn't >> part of that. >> >> http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042499.html > > Nope, on the original patch: > > http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039289.html > > Guess Segher changed his mind :) I didn't notice this issue before, that's all :-) >> But, I think segher is right in saying we should have tsi109 props if >> the HW is actually tsi108. > > Yeah, that's probably true. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from for-2.6.24
On Fri, 14 Sep 2007 13:24:17 -0500 Kumar Gala <[EMAIL PROTECTED]> wrote: > >>> Roy Zang (1): > >>> [POWERPC] Update mpc7448hpc2 device tree to be compatible for > >>> tsi109 chip > >> > >> Dropped for now. I doubt we want this based on Segher's comments. > >> (pretty sure its a ts108 on the hpc2 board). > > > > It is a tsi108 on hpc2. Holly has tsi109. From a Linux perspective, > > there is no difference. And the comment Segher made on the list was > > "Looks good, thanks!" So what other comment are you talking about? > > I think that was to the .dts clean ups. The patch from Roy wasn't > part of that. > > http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042499.html Nope, on the original patch: http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039289.html Guess Segher changed his mind :) > But, I think segher is right in saying we should have tsi109 props if > the HW is actually tsi108. Yeah, that's probably true. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Define termios_1 functions for powerpc, s390, avr32 and frv
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Thu, 13 Sep 2007 03:55:06 -0700
> I think we need to go with Tony's patch. sparc32 and sparc64 are
> presently broken too, and the patch which converts sparc to use the
> new interfaces introduces a few build errors.
The problem with the asm-generic/termios.h thing is it only works
if your copying functions are just a copy_{to,from}_user() and you
can define that __ARCH_* macro.
In retrospect what that header should do is, outside of the
ARCH_* block, define the foo_1 interfaces plainly to foo.
Alternatively, here is a patch that gets sparc compiling and
working again in the current tree.
This whole termios thing hasn't been handled very well, and it's maybe
not what we should be doing so late in the -rc cycle. And yes,
this is coming from the guy who added the TCP oops'er two weeks ago
:-P
[SPARC]: Fix build due to termios changes.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
diff --git a/include/asm-sparc/termios.h b/include/asm-sparc/termios.h
index d767f20..25e9cbb 100644
--- a/include/asm-sparc/termios.h
+++ b/include/asm-sparc/termios.h
@@ -142,6 +142,11 @@ struct winsize {
0; \
})
+#define user_termios_to_kernel_termios_1(k, u) \
+ user_termios_to_kernel_termios(k, u)
+#define kernel_termios_to_user_termios_1(u, k) \
+ kernel_termios_to_user_termios(u, k)
+
#endif /* __KERNEL__ */
#endif /* _SPARC_TERMIOS_H */
diff --git a/include/asm-sparc64/termios.h b/include/asm-sparc64/termios.h
index f05d390..6fc71e6 100644
--- a/include/asm-sparc64/termios.h
+++ b/include/asm-sparc64/termios.h
@@ -145,6 +145,11 @@ struct winsize {
err; \
})
+#define user_termios_to_kernel_termios_1(k, u) \
+ user_termios_to_kernel_termios(k, u)
+#define kernel_termios_to_user_termios_1(u, k) \
+ kernel_termios_to_user_termios(u, k)
+
#endif /* __KERNEL__ */
#endif /* _SPARC64_TERMIOS_H */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from for-2.6.24
>>> Roy Zang (1): >>> [POWERPC] Update mpc7448hpc2 device tree to be compatible for >>> tsi109 chip >> >> Dropped for now. I doubt we want this based on Segher's comments. >> (pretty sure its a ts108 on the hpc2 board). > > It is a tsi108 on hpc2. Holly has tsi109. From a Linux perspective, > there is no difference. And the comment Segher made on the list was > "Looks good, thanks!" So what other comment are you talking about? I think that was to the .dts clean ups. The patch from Roy wasn't part of that. http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042499.html But, I think segher is right in saying we should have tsi109 props if the HW is actually tsi108. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] DTS cleanup
On Sep 14, 2007, at 11:28 AM, Jon Loeliger wrote: > Kumar Gala wrote: > >> Someone really needs to add some macro/preprocessor magic into DTC >> so this is made a lot simpler. >> - k > > Kumar, > > I am seriously contemplating this problem. > The trick is, I need to quit with the whole > Power Point Programmer job title for a bit... I'm all for both of these things. You working on getting DTC to have some macro/include ability and you not being a powerpoint programmer. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from for-2.6.24
On Fri, 14 Sep 2007 09:02:04 -0500 Kumar Gala <[EMAIL PROTECTED]> wrote: > > On Sep 13, 2007, at 3:55 PM, Kumar Gala wrote: > > > Please pull from 'for-2.6.24' branch of > > > > master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git > > for-2.6.24 > > > > to receive the following updates: > > I've updated the branch with the following changes: > > > Anton Vorontsov (3): > > [POWERPC] MPC832x_RDB: Update dts to use SPI1 in QE, register > > mmc_spi stub > > Updated commit message. (let me know if you want me to drop this for > now and wait til mmc_spi gets merged) > > > Roy Zang (1): > > [POWERPC] Update mpc7448hpc2 device tree to be compatible for > > tsi109 chip > > Dropped for now. I doubt we want this based on Segher's comments. > (pretty sure its a ts108 on the hpc2 board). It is a tsi108 on hpc2. Holly has tsi109. From a Linux perspective, there is no difference. And the comment Segher made on the list was "Looks good, thanks!" So what other comment are you talking about? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: rtc-ds1742.c should use resource_size_t for base address
On Fri, 14 Sep 2007 15:54:27 +1000 David Gibson <[EMAIL PROTECTED]> wrote: > Currently the rtc driver, rtc-ds1742.c uses an unsigned long to store > the base mmio address of the NVRAM/RTC. This breaks on systems like > PowerPC 440, which is a 32-bit core with 36-bit physical addresses: IO > on the system, including the RTC, is typically above the 4GB point, > and cannot fit into an unsigned long. > > This patch fixes the problem by replacing the unsigned long with a > resource_size_t. Tested on Ebony (PPC440) (with additional patches to > instantiate the ds1742 platform device appropriately). Where would those additional patches be? :) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pcmcia: Convert io_req_t to use kio_addr_t
On Fri, Sep 14, 2007 at 03:48:54AM -0700, Andrew Morton wrote: > On Wed, 5 Sep 2007 09:27:43 -0500 Olof Johansson <[EMAIL PROTECTED]> wrote: > > > Convert the io_req_t members to kio_addr_t, to allow use on machines with > > more than 16 bits worth of IO port address space (ppc64 in this case, > > but it applies to others as well). > > drivers/usb/host/sl811_cs.c: In function 'sl811_cs_config': > drivers/usb/host/sl811_cs.c:263: warning: format '%04x' expects type > 'unsigned int', but argument 2 has type 'kio_addr_t' > drivers/usb/host/sl811_cs.c:263: warning: format '%04x' expects type > 'unsigned int', but argument 3 has type 'long unsigned int' > > That's not just a cosmetic thing - the printk can print junk and if there's > a %s in the control string after the %x's, printk() will crash. > > I don't know how many instances of this are in the tree, but they'll all > need to be found and fixed. A crap, I completely forgot to check drivers/, and my default builds don't contain many of them. My bad. I'll do a full pass and review all references to the changed variables. So far I've only noticed printk stuff, but I'm not done. There's a fair amount lot of places where they're cast into ints instead of longs, but that's a whole other ball of wax (and shouldn't cause regressions like the printk ones could). -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: rtc-ds1742.c should use resource_size_t for base address
On Fri, 14 Sep 2007 15:54:27 +1000, David Gibson <[EMAIL PROTECTED]> wrote: > Currently the rtc driver, rtc-ds1742.c uses an unsigned long to store > the base mmio address of the NVRAM/RTC. This breaks on systems like > PowerPC 440, which is a 32-bit core with 36-bit physical addresses: IO > on the system, including the RTC, is typically above the 4GB point, > and cannot fit into an unsigned long. > > This patch fixes the problem by replacing the unsigned long with a > resource_size_t. Tested on Ebony (PPC440) (with additional patches to > instantiate the ds1742 platform device appropriately). > > Signed-off-by: David Gibson <[EMAIL PROTECTED]> Thanks! Acked-by: Atsushi Nemoto <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] DTS cleanup
Kumar Gala wrote: > Someone really needs to add some macro/preprocessor magic into DTC so > this is made a lot simpler. > > - k Kumar, I am seriously contemplating this problem. The trick is, I need to quit with the whole Power Point Programmer job title for a bit... jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 02/12] IB/ehca: Add 1 is not longer needed because of firmware interface change
> If the rest of this patchset is okay with you, could you apply it and > leave out this one patch? The patchset will apply cleanly without it. Yes, no problem, I'll drop this patch for now. - R. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [NEWBIE] Interrupt-problem mpc5200
Grant Likely wrote: > > No, they are explicitly numbered. Are you looking at the 5200 or the > 5200B user manual? MPC5200B User's Manual, Rev. 1.3 (MPC5200BUM.pdf) > In my copy, on page 7-17, I see this: Ah! 7-20 here. Do we have different revisions of the manual, perhaps? :) PSa0 in > peripheral interrupt 0 (l2=0), PSa23 is peripheral interrupt #23 > (l2=23) > >BitsName > 8 PSa23 BestCom So, the numbering of the interrupts is not derived from anything but the "Name" field in those tables? 0 1 3 would be Slice Timer 0, 1 0 3 would be Slice Timer 1 (main, interrupt 0, we always use 3 on Efika for some reason) and 1 9 3 would be TMR0? PCI control and initiator interrupts would be 2 (8,9,10) 3? Well, this certainly makes a lot more sense, at least in terms of deriving the numbers, however it looks like it's a fairly nonsensical numbering system to be fair. -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [NEWBIE] Interrupt-problem mpc5200
On 9/14/07, Matt Sealey <[EMAIL PROTECTED]> wrote: > Grant Likely wrote: > > On 9/14/07, Matt Sealey <[EMAIL PROTECTED]> wrote: > >> sparse, irq_of_find_and_map isn't much help). Maybe I am just not > >> looking in the right place but not being an MPC52xx PIC Expert I > >> wouldn't even know where to start... > > > > The l2 irq numbers map directly to the interrupt numbers listed in the > > 5200b user guide. For example, on p7-11, the masks are listed for > > main interrupts 0 through 16. and on p7-17,18, the peripherial > > interrupts are listed as numbered from 0 to 23 (but notice that it > > does *not* line up with bit positions). > > Wow I even had to search.. it's on p7-13 here.. > > Right but it does start from a certain bit and progress linearly > across the rest of the register. > > However, what is interrupt 0 and what is interrupt 16? Do you start > from the left or the right (i.e. Motorola big endian or Rest Of > World big endian)?? > > > However, it is interesting to note that other than in the register > > definitions, I don't think there is anywhere in the 5200b user manual > > that simple lists the interrupt numbers for each interrupt type. > > I think the interesting note is that picking out "what does IRQ 4 > in the main interrupt group handle" or picking out a device and > saying "this is IRQ 10" is still, even with your explanation, a > matter of luck and handedness. > > Personally I would count from the right (Motorola bit 31) and > work my way from LSB to MSB, but Motorola likes it's backwards > representation and so do some other people. So, does bit 31 > equal interrupt 0 or interrupt 16? :) No, they are explicitly numbered. Are you looking at the 5200 or the 5200B user manual? In my copy, on page 7-17, I see this: PSa0 in peripheral interrupt 0 (l2=0), PSa23 is peripheral interrupt #23 (l2=23) BitsName 8 PSa23 BestCom 9 PSa22 BDLC 10PSa0 BestCom 11PSa1 PSC1 12 PSa2PSC2 13 PSa3PSC3 14 PSa4PSC6 15 PSa5Ethernet 16 PSa6USB 17 PSa7ATA 18 PSa8PCI Contr 19 PSa9PCI SC In 20 PSa10 PCI SC In 21 PSa11 PSC4 22 PSa12 PSC5 23 PSa13 SPI modf 24 PSa14 SPI spif 25 PSa15 I2C1 26 PSa16 I2C2 27 PSa17 CAN1 28 PSa18 CAN2 29:30 — Reserved 31 PSa21 XLB Arbit > > Then there are the status encoded registers, which report which > IRQ is firing. They are just values. But which value corresponds > to which interrupt (left or right reading) here or do they even > have completely different ones? > > -- > Matt Sealey <[EMAIL PROTECTED]> > Genesi, Manager, Developer Relations > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PowerPC: usb ehci of_platform bindings for Sequoia 440EPx
On Sep 14, 2007, at 9:31 AM, Valentine Barshak wrote: > Segher Boessenkool wrote: >>> EHCI OF bindings for PowerPC 440EPx Sequoia. >> >> Those aren't bindings, they are examples. Bindings are pieces >> of documentation that describe what device-specific properties >> mean what, what standard properties are required with what >> values, etc. >> >> Examples are good to have, of course. >> >> One thing you really need to document is what "ehci-be-desc" >> and friends mean. I can give you one comment already: for >> devices that are usually little-endian, but an implementation >> implements registers as big-endian, precedent is to show that >> in the device tree by including an (empty) "big-endian" property, >> rather than inventing new "compatible" values. > > I was looking at the ohci-ppc-of driver that has "ohci-bigendian" > compatible string and enables both be-mmio and be-desc for the > device in > this case. I just wanted to separate mmio and desc stuff for ehci, > since > some devices need be-mmio only. > I'll use "big-endian" property instead of "ehci-be-mmio" compatible > value. That's a good point, thanks. > Do I have to add "sequoia usb ehci" description to > Documentation/powerpc/booting-without-of.txt? > Do I also have to describe ehci-ppc-of stuff in general? > BTW, I see nothing about ohci-ppc-of there. We may need to comprehend the Freescale USB controller since its technically an EHCI controller. There should be some stuff in booting-without-of.txt related to it. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [NEWBIE] Interrupt-problem mpc5200
Grant Likely wrote: > On 9/14/07, Matt Sealey <[EMAIL PROTECTED]> wrote: >> sparse, irq_of_find_and_map isn't much help). Maybe I am just not >> looking in the right place but not being an MPC52xx PIC Expert I >> wouldn't even know where to start... > > The l2 irq numbers map directly to the interrupt numbers listed in the > 5200b user guide. For example, on p7-11, the masks are listed for > main interrupts 0 through 16. and on p7-17,18, the peripherial > interrupts are listed as numbered from 0 to 23 (but notice that it > does *not* line up with bit positions). Wow I even had to search.. it's on p7-13 here.. Right but it does start from a certain bit and progress linearly across the rest of the register. However, what is interrupt 0 and what is interrupt 16? Do you start from the left or the right (i.e. Motorola big endian or Rest Of World big endian)?? > However, it is interesting to note that other than in the register > definitions, I don't think there is anywhere in the 5200b user manual > that simple lists the interrupt numbers for each interrupt type. I think the interesting note is that picking out "what does IRQ 4 in the main interrupt group handle" or picking out a device and saying "this is IRQ 10" is still, even with your explanation, a matter of luck and handedness. Personally I would count from the right (Motorola bit 31) and work my way from LSB to MSB, but Motorola likes it's backwards representation and so do some other people. So, does bit 31 equal interrupt 0 or interrupt 16? :) Then there are the status encoded registers, which report which IRQ is firing. They are just values. But which value corresponds to which interrupt (left or right reading) here or do they even have completely different ones? -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [NEWBIE] Interrupt-problem mpc5200
On 9/14/07, Matt Sealey <[EMAIL PROTECTED]> wrote:
> Grant!
>
> I have a newbie question which I never had properly answered. On the
> MPC52xx and specifically regarding the device tree, how are interrupt
> numbers assigned?
>
> On Efika (and in the DT docs) it's basically the X Y Z where X is the
> type (critical, main, peripheral, sdma), Y is the number of the
> interrupt, and Z is it's sense level.
>
> However while X and Z are easy to derive, how do you work out what Y
> is meant to be given a device? Is it a bit number in the interrupt
> register, or the value of the encoded interrupt register or something
> else algorithmically determined?
>
> I am just finding the code in Linux that derives this number fairly
> elusive (the irq setup function for the mpc52xx platform is truly
> sparse, irq_of_find_and_map isn't much help). Maybe I am just not
> looking in the right place but not being an MPC52xx PIC Expert I
> wouldn't even know where to start...
The l2 irq numbers map directly to the interrupt numbers listed in the
5200b user guide. For example, on p7-11, the masks are listed for
main interrupts 0 through 16. and on p7-17,18, the peripherial
interrupts are listed as numbered from 0 to 23 (but notice that it
does *not* line up with bit positions).
However, it is interesting to note that other than in the register
definitions, I don't think there is anywhere in the 5200b user manual
that simple lists the interrupt numbers for each interrupt type.
Cheers,
g.
>
> --
> Matt Sealey <[EMAIL PROTECTED]>
> Genesi, Manager, Developer Relations
>
> Grant Likely wrote:
> > On 9/11/07, S. Fricke <[EMAIL PROTECTED]> wrote:
> >> Hello,
> >>
> [...]
> intr = mpc52xx_find_and_map("mpc52xx-pic");
> if(!intr) {
> panic(__FILE__ ": mpc52xx-pic - MAP failed");
> }
>
> set_irq_chip(MPC52xx_IRQ2, &my_irq_chip);
> >>> You probably don't want to do this (unless you are cascading IRQs to
> >>> custom external hardware). All you should need is the call to
> >>> request_irq() to register your irq handler, and code in your ISR
> >>> handler to clear the interrupt condition.
> >>>
> >>> You do *NOT* want to program the interrupt controller directly. The
> >>> mpc5200 interrupt controller already has a driver. Don't go twiddling
> >>> the registers manually.
> >> OK!
> >>
> >> I have tried it before and i get a "-ENOSYS" returned.
> >>
> >> My code was/is now:
> >> --==>
> >> request_irq(MPC52xx_IRQ2, intmod_isr, IRQF_DISABLED , "intmod",
> >> INTMOD_IRQ_BOARD);
> >> <==--
> >>
> >> I have looked up "kernel/irq/manage.c". "-ENOSYS" is returned on function
> >> "setup_irq" because the used irq(MPC52xx_IRQ2) is the same as no_irq_chip.
> >>
> >> THE MPC52xx_IRQ2 is a excerpt from "include/ppc/mpc52xx.h" (per copy
> >> paste), but mpc52xx is (now) a powerpc-arch. What is the desired value for
> >> IRQ-2 on a mpc5200b?
> >
> > The irq number you pass into request_irq is a system-wide irq number;
> > it doesn't necessarily map directly onto the MPC52xx irq number.
> > Typically, you'd have a node for your device in the device tree which
> > has a phandle back to the interrupt node and you would use
> > irq_of_parse_and_map() to map it back to a system-wide irq number.
> >
> > Otherwise, you need to call of_irq_map_raw with the pointer to the
> > 52xx interrupt controller node and the interrupt number in the form
> > expected by the device tree. (But adding a device tree node for your
> > device is far easier).
> >
> > Cheers,
> > g.
> >
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PowerPC: usb ehci of_platform bindings for Sequoia 440EPx
Segher Boessenkool wrote: >> EHCI OF bindings for PowerPC 440EPx Sequoia. > > Those aren't bindings, they are examples. Bindings are pieces > of documentation that describe what device-specific properties > mean what, what standard properties are required with what > values, etc. > > Examples are good to have, of course. > > One thing you really need to document is what "ehci-be-desc" > and friends mean. I can give you one comment already: for > devices that are usually little-endian, but an implementation > implements registers as big-endian, precedent is to show that > in the device tree by including an (empty) "big-endian" property, > rather than inventing new "compatible" values. I was looking at the ohci-ppc-of driver that has "ohci-bigendian" compatible string and enables both be-mmio and be-desc for the device in this case. I just wanted to separate mmio and desc stuff for ehci, since some devices need be-mmio only. I'll use "big-endian" property instead of "ehci-be-mmio" compatible value. That's a good point, thanks. Do I have to add "sequoia usb ehci" description to Documentation/powerpc/booting-without-of.txt? Do I also have to describe ehci-ppc-of stuff in general? BTW, I see nothing about ohci-ppc-of there. Thanks, Valentine. > > > Segher > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: 2.6.23-rc3 boot hang on MPC8641D
Hi Zhang, Asper ur idea, i downloaded latest BSP(Jun,2007) and the kernel (2.6.23-rc4) from the Paul's Git tree. Uboot(1.2.0) was taken from the latest BSP. I portted the new uboot to my custom board, i got uboot prompt. When i compiling the kernel i got following warning messages WARNING: vmlinux.o(.text+0x169f6): Section mismatch: reference to .init.data:boot_command_line (between 'note_bootable_part' and 'pmac_restart') WARNING: vmlinux.o(.text+0x16a02): Section mismatch: reference to .init.data:boot_command_line (between 'note_bootable_part' and 'pmac_restart') WARNING: vmlinux.o(.text+0x16a12): Section mismatch: reference to .init.data:boot_command_line (between 'note_bootable_part' and 'pmac_restart') When i try to boot the kernel, I got following messages Booting image at 0020 ... Image Name: Linux-2.6.23-rc4-g5326152f-dirty Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1842307 Bytes = 1.8 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK Booting using flat device tree at 0x60 I can't know whether the problem is related to uboot or kernel. But i tested the board with the 2.6.21 kernel, it was up.In that kernel we face some issues on PCI Express so we plan to upgrade the kernel. But the latest kernel was not up. Please advice me. By Sivaji Zhang Wei-r63237 wrote: > > Hi, Sivaji, > > I've tested the newest git tree of Paul's, which is aleady updated to > 2.6.23-rc4. The kernel is no problem with the u-boot of our released BSP > (Jun, 2007) on MPC8641HPCN board. > > Maybe you could update to the newest kernel git tree and try again. > > Cheers! > -zw > >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] >> g] On Behalf Of sivaji >> Sent: Thursday, September 13, 2007 1:32 PM >> To: linuxppc-dev@ozlabs.org >> Subject: RE: 2.6.23-rc3 boot hang on MPC8641D >> >> >> Hi, >> Sorry i specify the wrong version, we r using >> 1.2.0. This uboot >> was taken from the BSP which was released by Freescale. >> Previously we tested >> linux 2.6.21 kernel, we got linux prompt. For this we are >> using the same >> uboot(1.2.0). >> In that version we face some issues in the pci express, at >> that time kumar >> suggest to upgrade the kernel verison 2.6.23-rc3. >> Zhang did u suspect the problem is related to uboot?. >> by >> sivaji >> >> >> Zhang Wei-r63237 wrote: >> > >> > Yes, It's too old. Maybe not fully supports FDT. You can >> try the version >> > of Kumar said or in the BSP of Freescale released. >> > >> > - zw >> > >> >> -Original Message- >> >> From: [EMAIL PROTECTED] >> >> [mailto:[EMAIL PROTECTED] >> >> g] On Behalf Of Kumar Gala >> >> Sent: Thursday, September 13, 2007 1:11 PM >> >> To: sivaji >> >> Cc: linuxppc-dev@ozlabs.org >> >> Subject: Re: 2.6.23-rc3 boot hang on MPC8641D >> >> >> >> >> >> On Sep 12, 2007, at 11:52 PM, sivaji wrote: >> >> >> >> > >> >> > >> >> > Hi, >> >> > I tired to move the dtb to 0x200, but the >> result was >> >> > same. >> >> > uboot version is 1.1.6 >> >> >> >> seems like a pretty old u-boot. Willing to try a 1.3.0-rc1? >> >> >> >> - k >> >> ___ >> >> Linuxppc-dev mailing list >> >> Linuxppc-dev@ozlabs.org >> >> https://ozlabs.org/mailman/listinfo/linuxppc-dev >> >> >> > ___ >> > Linuxppc-dev mailing list >> > Linuxppc-dev@ozlabs.org >> > https://ozlabs.org/mailman/listinfo/linuxppc-dev >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/2.6.23-rc3-boot-hang-on-MPC8641D-tf44335 >> 08.html#a12648963 >> Sent from the linuxppc-dev mailing list archive at Nabble.com. >> >> ___ >> Linuxppc-dev mailing list >> Linuxppc-dev@ozlabs.org >> https://ozlabs.org/mailman/listinfo/linuxppc-dev >> > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > > -- View this message in context: http://www.nabble.com/2.6.23-rc3-boot-hang-on-MPC8641D-tf4433508.html#a12676464 Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: add new required termio functions
On Wed, Sep 12, 2007 at 02:49:10PM +0100, Christoph Hellwig wrote: > On Wed, Sep 12, 2007 at 01:52:57PM +0200, Heiko Carstens wrote: > > > I might be missing something, but the the right fix is probably to > > > apply the arch patches from Alan to powerpc and s390. We don't want to > > > be left over without all the nice termios features on these platforms, > > > do we? > > > > But not in rc6 timeframe, I would guess? > > Ask Alan.. Well i've been chasing people for many months on the 390 side so if they missed a release tough ... Alan -- -- "A wiki is where ideas go to die" -- Becky Hogge ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ucc_geth: fix compilation
On Sep 13, 2007, at 10:23 AM, Anton Vorontsov wrote:
> Currently qe_bd_t is used in the macro call -- dma_unmap_single,
> which is a no-op on PPC32, thus error is hidden today. Starting
> with 2.6.24, macro will be replaced by the empty static function,
> and erroneous use of qe_bd_t will trigger compilation error.
>
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> ---
Jeff, I'm going to pick this up via the powerpc.git tree since its
currently only broken in our for-2.6.24 branch (because of other
changes in there). Any issues?
- k
>
> Reposting this to include netdev in Cc.
>
> drivers/net/ucc_geth.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
> index 12e01b2..9a38dfe 100644
> --- a/drivers/net/ucc_geth.c
> +++ b/drivers/net/ucc_geth.c
> @@ -2148,7 +2148,7 @@ static void ucc_geth_memclean(struct
> ucc_geth_private *ugeth)
> for (j = 0; j < ugeth->ug_info->bdRingLenTx[i]; j++) {
> if (ugeth->tx_skbuff[i][j]) {
> dma_unmap_single(NULL,
> - ((qe_bd_t *)bd)->buf,
> + ((struct qe_bd *)bd)->buf,
>(in_be32((u32 *)bd) &
> BD_LENGTH_MASK),
>DMA_TO_DEVICE);
> --
> 1.5.0.6
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from for-2.6.24
On Sep 13, 2007, at 3:55 PM, Kumar Gala wrote: > Please pull from 'for-2.6.24' branch of > > master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git > for-2.6.24 > > to receive the following updates: I've updated the branch with the following changes: > Anton Vorontsov (3): > [POWERPC] MPC832x_RDB: Update dts to use SPI1 in QE, register > mmc_spi stub Updated commit message. (let me know if you want me to drop this for now and wait til mmc_spi gets merged) > Roy Zang (1): > [POWERPC] Update mpc7448hpc2 device tree to be compatible for > tsi109 chip Dropped for now. I doubt we want this based on Segher's comments. (pretty sure its a ts108 on the hpc2 board). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RTC class drivers and powerpc arch
On Sep 14, 2007, at 3:39 AM, Gerhard Pircher wrote: > Hi, > > Since todc was removed from arch/powerpc I wonder how to use the > rtc-cmos > RTC class driver for my AmigaOne with its VIA southbridge. Do I > have to > define a platform device and the get/set_rtc_time hook functions or > can > the driver probe for and access the hardware automatically, if > there's a > device node for the RTC in the device tree? Take a look at the RTC nodes that exist in arch/powerpc/boot/dts/ mpc8544ds.dts for an example related to rtc-cmos. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 02/12] IB/ehca: Add 1 is not longer needed because of firmware interface change
Roland Dreier <[EMAIL PROTECTED]> wrote on 12.09.2007 22:21:54: > What happens if someone runs the new driver with older firmware? Or > what if someone upgrades the firmware without updating the driver? Thanks for pointing our noses to this. Your comment triggered some further internal discussions about the meaning of the values for the current system implementation. We'll think this one over again and repost the final solution in time for 2.6.24-rc1. If the rest of this patchset is okay with you, could you apply it and leave out this one patch? The patchset will apply cleanly without it. Thanks, Joachim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 22/22] [POWERPC] MPC832x_RDB: Update dts to use SPI1 in QE, register mmc_spi stub
On Sep 14, 2007, at 8:21 AM, Kumar Gala wrote: > > On Sep 14, 2007, at 7:32 AM, Paul Mackerras wrote: > >> Kumar Gala writes: >> >>> From: Anton Vorontsov <[EMAIL PROTECTED]> >>> >>> mmc_spi already tested to work. When it will hit mainline >>> the only change that will be needed is replacing "spidev" >>> with "mmc_spi". >> >> That's a *remarkably* uninformative commit message. And what's the >> use of putting in something about "when it will hit mainline" when >> this is the point where it hits mainline? > > Yeah, I was afraid of that when I glanced at Anton's patches. > > I think the comment is in reference to a mainline SPI subsystem > change intended for 2.6.24. Let me know how you want to handle this. I see two options. 1. merge patch as is (with new commit message, see below) 2. drop patch for now and wait for mmc_spi to be merged. Take a look at the following for Anton's comments on the situation: http://ozlabs.org/pipermail/linuxppc-dev/2007-August/041370.html How about a commit message like the following: [POWERPC] MPC832x_RDB: Update dts to use SPI1 in QE, register mmc_spi stub Enabled using SPI controller on the MPC832x RDB board. We currently use a modalias of "spidev" as a place holder (replace with "mmc_spie") until the mmc_spi driver support is merged in. This gets us the ability to test SPI until then. Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [NEWBIE] Interrupt-problem mpc5200
Grant!
I have a newbie question which I never had properly answered. On the
MPC52xx and specifically regarding the device tree, how are interrupt
numbers assigned?
On Efika (and in the DT docs) it's basically the X Y Z where X is the
type (critical, main, peripheral, sdma), Y is the number of the
interrupt, and Z is it's sense level.
However while X and Z are easy to derive, how do you work out what Y
is meant to be given a device? Is it a bit number in the interrupt
register, or the value of the encoded interrupt register or something
else algorithmically determined?
I am just finding the code in Linux that derives this number fairly
elusive (the irq setup function for the mpc52xx platform is truly
sparse, irq_of_find_and_map isn't much help). Maybe I am just not
looking in the right place but not being an MPC52xx PIC Expert I
wouldn't even know where to start...
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
Grant Likely wrote:
> On 9/11/07, S. Fricke <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
[...]
intr = mpc52xx_find_and_map("mpc52xx-pic");
if(!intr) {
panic(__FILE__ ": mpc52xx-pic - MAP failed");
}
set_irq_chip(MPC52xx_IRQ2, &my_irq_chip);
>>> You probably don't want to do this (unless you are cascading IRQs to
>>> custom external hardware). All you should need is the call to
>>> request_irq() to register your irq handler, and code in your ISR
>>> handler to clear the interrupt condition.
>>>
>>> You do *NOT* want to program the interrupt controller directly. The
>>> mpc5200 interrupt controller already has a driver. Don't go twiddling
>>> the registers manually.
>> OK!
>>
>> I have tried it before and i get a "-ENOSYS" returned.
>>
>> My code was/is now:
>> --==>
>> request_irq(MPC52xx_IRQ2, intmod_isr, IRQF_DISABLED , "intmod",
>> INTMOD_IRQ_BOARD);
>> <==--
>>
>> I have looked up "kernel/irq/manage.c". "-ENOSYS" is returned on function
>> "setup_irq" because the used irq(MPC52xx_IRQ2) is the same as no_irq_chip.
>>
>> THE MPC52xx_IRQ2 is a excerpt from "include/ppc/mpc52xx.h" (per copy
>> paste), but mpc52xx is (now) a powerpc-arch. What is the desired value for
>> IRQ-2 on a mpc5200b?
>
> The irq number you pass into request_irq is a system-wide irq number;
> it doesn't necessarily map directly onto the MPC52xx irq number.
> Typically, you'd have a node for your device in the device tree which
> has a phandle back to the interrupt node and you would use
> irq_of_parse_and_map() to map it back to a system-wide irq number.
>
> Otherwise, you need to call of_irq_map_raw with the pointer to the
> 52xx interrupt controller node and the interrupt number in the form
> expected by the device tree. (But adding a device tree node for your
> device is far easier).
>
> Cheers,
> g.
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 04/22] [POWERPC] Update mpc7448hpc2 device tree to be compatible for tsi109 chip
On Sep 13, 2007, at 5:54 PM, Segher Boessenkool wrote:
>> Update mpc7448hpc2 device tree to be compatible for tsi109 chip.
>
> Do all those boards have a tsi109? If not, this patch is
> incorrect. If they do, is tsi109 actually backward-compatible
> to tsi108? That is, will a driver that knows about tsi108
> only work correctly on a tsi109?
I believe its a tsi108 and thus am going to drop this patch since I
agree with you. Unless Roy tells me otherwise.
> Also, all those names really should have a manufacturer
> prefix ("XXX,...").
More cleanup for someone :)
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 22/22] [POWERPC] MPC832x_RDB: Update dts to use SPI1 in QE, register mmc_spi stub
On Sep 14, 2007, at 7:32 AM, Paul Mackerras wrote: > Kumar Gala writes: > >> From: Anton Vorontsov <[EMAIL PROTECTED]> >> >> mmc_spi already tested to work. When it will hit mainline >> the only change that will be needed is replacing "spidev" >> with "mmc_spi". > > That's a *remarkably* uninformative commit message. And what's the > use of putting in something about "when it will hit mainline" when > this is the point where it hits mainline? Yeah, I was afraid of that when I glanced at Anton's patches. I think the comment is in reference to a mainline SPI subsystem change intended for 2.6.24. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 22/22] [POWERPC] MPC832x_RDB: Update dts to use SPI1 in QE, register mmc_spi stub
Kumar Gala writes: > From: Anton Vorontsov <[EMAIL PROTECTED]> > > mmc_spi already tested to work. When it will hit mainline > the only change that will be needed is replacing "spidev" > with "mmc_spi". That's a *remarkably* uninformative commit message. And what's the use of putting in something about "when it will hit mainline" when this is the point where it hits mainline? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Section mismatch warning
On Fri, 14 Sep 2007 05:01:14 -0700 (PDT) sivaji <[EMAIL PROTECTED]> wrote: > > Hi, > When compiling the kernel 2.6.23-rc4 for our custom board based on > MPC8641, I got following warning messages > > WARNING: vmlinux.o(.text+0x169f6): Section mismatch: reference to > .init.data:boot_command_line (between 'note_bootable_part' and > 'pmac_restart') > WARNING: vmlinux.o(.text+0x16a02): Section mismatch: reference to > .init.data:boot_command_line (between 'note_bootable_part' and > 'pmac_restart') > WARNING: vmlinux.o(.text+0x16a12): Section mismatch: reference to > .init.data:boot_command_line (between 'note_bootable_part' and > 'pmac_restart') > > Give some idea to fix these warnings. These should be fixed for 2.6.24 josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Section mismatch warning
Hi, When compiling the kernel 2.6.23-rc4 for our custom board based on MPC8641, I got following warning messages WARNING: vmlinux.o(.text+0x169f6): Section mismatch: reference to .init.data:boot_command_line (between 'note_bootable_part' and 'pmac_restart') WARNING: vmlinux.o(.text+0x16a02): Section mismatch: reference to .init.data:boot_command_line (between 'note_bootable_part' and 'pmac_restart') WARNING: vmlinux.o(.text+0x16a12): Section mismatch: reference to .init.data:boot_command_line (between 'note_bootable_part' and 'pmac_restart') Give some idea to fix these warnings. by Sivaji -- View this message in context: http://www.nabble.com/Section-mismatch-warning-tf4442060.html#a12673863 Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG][2.6.23-rc6] Badness at arch/powerpc/kernel/smp.c:202
Anton, this seems a little reminicient of that bug which popped up in 2.6.23-rc3 so do with SLB loading (if memory serves), with machine checks and signal 7's. Of course that is _supposed_ to be fixed by this time ... I believe it was Paul who fixed up that one, and he is already copied. -apw On Fri, Sep 14, 2007 at 04:07:37PM +0530, Satyam Sharma wrote: > > With 2.6.23-rc6 running on the ppc64 box, following oops is hit > > > > Oops: Machine check, sig: 7 [#1] > > > > SMP NR_CPUS=128 pSeries > > > > Modules linked in: binfmt_misc ipv6 dm_mod ehci_hcd ohci_hcd usbcore > > > > NIP: c00ed560 LR: c00efc7c CTR: c00ed504 > > > > REGS: cffef680 TRAP: 0200 Not tainted (2.6.23-rc6-autokern1) > > > > MSR: 80109032 CR: 28002042 XER: 0010 > > > > TASK = c000ecf9f000[0] 'swapper' THREAD: cff8c000 CPU: 2 > > > > GPR00: cffef900 c06fe598 c000d7a8f200 > > > > GPR04: 1000 1000 80c26393 > > > > GPR08: c06b43d0 0001 1000 > > > > GPR12: 4848 c05f1700 07a8dcd0 > > > > GPR16: 0002 > > > > GPR20: 1000 1000 > > > > GPR24: 1000 c63234e8 > > > > GPR28: 1000 c0689c08 cff3a480 > > > > NIP [c00ed560] .end_bio_bh_io_sync+0x5c/0xac > > > > LR [c00efc7c] .bio_endio+0xb4/0xd4 > > > > Call Trace: > > > > [cffef900] [cffef990] 0xcffef990 (unreliable) > > > > [cffef980] [c00efc7c] .bio_endio+0xb4/0xd4 > > > > [cffefa10] [c0290060] .__end_that_request_first+0x154/0x548 > > > > [cffefae0] [c035af10] .scsi_end_request+0x40/0x138 > > > > [cffefb80] [c035b234] .scsi_io_completion+0x188/0x454 > > > > [cffefc60] [c0372a24] .sd_rw_intr+0x2e4/0x338 > > > > [cffefd30] [c0354548] .scsi_finish_command+0xbc/0xe0 > > > > [cffefdc0] [c035bdf0] .scsi_softirq_done+0x140/0x188 > > > > [cffefe60] [c0293184] .blk_done_softirq+0xa0/0xd0 > > > > [cffefef0] [c0055e1c] .__do_softirq+0xa8/0x164 > > > > [cffeff90] [c0023f14] .call_do_softirq+0x14/0x24 > > > > [cff8f960] [c000bd30] .do_softirq+0x68/0xac > > > > [cff8f9f0] [c0055f70] .irq_exit+0x54/0x6c > > > > [cff8fa70] [c000c358] .do_IRQ+0x170/0x1ac > > > > [cff8fb00] [c0004780] hardware_interrupt_entry+0x18/0x98 > > > > --- Exception: 501 at .pseries_dedicated_idle_sleep+0xe0/0x194 > > > > LR = .pseries_dedicated_idle_sleep+0xd0/0x194 > > > > [cff8fdf0] [] .__start+0x4000/0x8 > > (unreliable) > > > > [cff8fe80] [c0010bd4] .cpu_idle+0x104/0x1d8 > > > > [cff8ff00] [c002672c] .start_secondary+0x160/0x184 > > > > [cff8ff90] [c0008364] .start_secondary_prolog+0xc/0x10 > > > > Instruction dump: > > > > 409a0030 393f0018 3880 7d6048a8 7d6b0378 7d6049ad 40a2fff4 38002000 > > > > 7d2018a8 7d290378 7d2019ad 40a2fff4 e89f0018 e969 f8410028 > > > > Kernel panic - not syncing: Fatal exception in interrupt > > This oops is the real bug here, but is that a machine check exception? > If so, it could be a hardware failure what you saw there instead, and not > really a kernel bug ... ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pcmcia: Convert io_req_t to use kio_addr_t
On Wed, 5 Sep 2007 09:27:43 -0500 Olof Johansson <[EMAIL PROTECTED]> wrote: > Convert the io_req_t members to kio_addr_t, to allow use on machines with > more than 16 bits worth of IO port address space (ppc64 in this case, > but it applies to others as well). drivers/usb/host/sl811_cs.c: In function 'sl811_cs_config': drivers/usb/host/sl811_cs.c:263: warning: format '%04x' expects type 'unsigned int', but argument 2 has type 'kio_addr_t' drivers/usb/host/sl811_cs.c:263: warning: format '%04x' expects type 'unsigned int', but argument 3 has type 'long unsigned int' That's not just a cosmetic thing - the printk can print junk and if there's a %s in the control string after the %x's, printk() will crash. I don't know how many instances of this are in the tree, but they'll all need to be found and fixed. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG][2.6.23-rc6] Badness at arch/powerpc/kernel/smp.c:202
Hi Kamalesh, There's two things at work here ... On 9/14/07, Kamalesh Babulal <[EMAIL PROTECTED]> wrote: > Hi, > > With 2.6.23-rc6 running on the ppc64 box, following oops is hit > > Oops: Machine check, sig: 7 [#1] > > SMP NR_CPUS=128 pSeries > > Modules linked in: binfmt_misc ipv6 dm_mod ehci_hcd ohci_hcd usbcore > > NIP: c00ed560 LR: c00efc7c CTR: c00ed504 > > REGS: cffef680 TRAP: 0200 Not tainted (2.6.23-rc6-autokern1) > > MSR: 80109032 CR: 28002042 XER: 0010 > > TASK = c000ecf9f000[0] 'swapper' THREAD: cff8c000 CPU: 2 > > GPR00: cffef900 c06fe598 c000d7a8f200 > > GPR04: 1000 1000 80c26393 > > GPR08: c06b43d0 0001 1000 > > GPR12: 4848 c05f1700 07a8dcd0 > > GPR16: 0002 > > GPR20: 1000 1000 > > GPR24: 1000 c63234e8 > > GPR28: 1000 c0689c08 cff3a480 > > NIP [c00ed560] .end_bio_bh_io_sync+0x5c/0xac > > LR [c00efc7c] .bio_endio+0xb4/0xd4 > > Call Trace: > > [cffef900] [cffef990] 0xcffef990 (unreliable) > > [cffef980] [c00efc7c] .bio_endio+0xb4/0xd4 > > [cffefa10] [c0290060] .__end_that_request_first+0x154/0x548 > > [cffefae0] [c035af10] .scsi_end_request+0x40/0x138 > > [cffefb80] [c035b234] .scsi_io_completion+0x188/0x454 > > [cffefc60] [c0372a24] .sd_rw_intr+0x2e4/0x338 > > [cffefd30] [c0354548] .scsi_finish_command+0xbc/0xe0 > > [cffefdc0] [c035bdf0] .scsi_softirq_done+0x140/0x188 > > [cffefe60] [c0293184] .blk_done_softirq+0xa0/0xd0 > > [cffefef0] [c0055e1c] .__do_softirq+0xa8/0x164 > > [cffeff90] [c0023f14] .call_do_softirq+0x14/0x24 > > [cff8f960] [c000bd30] .do_softirq+0x68/0xac > > [cff8f9f0] [c0055f70] .irq_exit+0x54/0x6c > > [cff8fa70] [c000c358] .do_IRQ+0x170/0x1ac > > [cff8fb00] [c0004780] hardware_interrupt_entry+0x18/0x98 > > --- Exception: 501 at .pseries_dedicated_idle_sleep+0xe0/0x194 > > LR = .pseries_dedicated_idle_sleep+0xd0/0x194 > > [cff8fdf0] [] .__start+0x4000/0x8 > (unreliable) > > [cff8fe80] [c0010bd4] .cpu_idle+0x104/0x1d8 > > [cff8ff00] [c002672c] .start_secondary+0x160/0x184 > > [cff8ff90] [c0008364] .start_secondary_prolog+0xc/0x10 > > Instruction dump: > > 409a0030 393f0018 3880 7d6048a8 7d6b0378 7d6049ad 40a2fff4 38002000 > > 7d2018a8 7d290378 7d2019ad 40a2fff4 e89f0018 e969 f8410028 > > Kernel panic - not syncing: Fatal exception in interrupt This oops is the real bug here, but is that a machine check exception? If so, it could be a hardware failure what you saw there instead, and not really a kernel bug ... > [ cut here ] > > Badness at arch/powerpc/kernel/smp.c:202 This one is not the real issue at all -- it's just a sad problem in the powerpc panic() -> smp_send_stop() -> smp_call_function() -> smp_call_function_map() call chain. The thing is, smp_call_function() cannot be allowed from interrupt disabled contexts, hence the WARN_ON() there. But panic() is a special case, and so we must *not* complain when called from panic -- doing so will only scroll away the real call trace / oops log from the screen (thankfully you had a serial cable there?) and distract from the real bug, like what happened here ... The fix is to define an alternative __smp_call_function(), that calls into smp_call_function_map(), and is itself called from smp_call_function(), and then: 1. Use the inner __smp_call_function() in smp_send_stop(), and, 2. Move the WARN_ON() to the smp_call_function() wrapper instead. I'd be back at my desk only by Tuesday, so don't expect a patch before then, unless Paul fixes this up by himself before that. Cheers, Satyam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[BUG][2.6.23-rc6] Badness at arch/powerpc/kernel/smp.c:202
Hi, With 2.6.23-rc6 running on the ppc64 box, following oops is hit Oops: Machine check, sig: 7 [#1] SMP NR_CPUS=128 pSeries Modules linked in: binfmt_misc ipv6 dm_mod ehci_hcd ohci_hcd usbcore NIP: c00ed560 LR: c00efc7c CTR: c00ed504 REGS: cffef680 TRAP: 0200 Not tainted (2.6.23-rc6-autokern1) MSR: 80109032 CR: 28002042 XER: 0010 TASK = c000ecf9f000[0] 'swapper' THREAD: cff8c000 CPU: 2 GPR00: cffef900 c06fe598 c000d7a8f200 GPR04: 1000 1000 80c26393 GPR08: c06b43d0 0001 1000 GPR12: 4848 c05f1700 07a8dcd0 GPR16: 0002 GPR20: 1000 1000 GPR24: 1000 c63234e8 GPR28: 1000 c0689c08 cff3a480 NIP [c00ed560] .end_bio_bh_io_sync+0x5c/0xac LR [c00efc7c] .bio_endio+0xb4/0xd4 Call Trace: [cffef900] [cffef990] 0xcffef990 (unreliable) [cffef980] [c00efc7c] .bio_endio+0xb4/0xd4 [cffefa10] [c0290060] .__end_that_request_first+0x154/0x548 [cffefae0] [c035af10] .scsi_end_request+0x40/0x138 [cffefb80] [c035b234] .scsi_io_completion+0x188/0x454 [cffefc60] [c0372a24] .sd_rw_intr+0x2e4/0x338 [cffefd30] [c0354548] .scsi_finish_command+0xbc/0xe0 [cffefdc0] [c035bdf0] .scsi_softirq_done+0x140/0x188 [cffefe60] [c0293184] .blk_done_softirq+0xa0/0xd0 [cffefef0] [c0055e1c] .__do_softirq+0xa8/0x164 [cffeff90] [c0023f14] .call_do_softirq+0x14/0x24 [cff8f960] [c000bd30] .do_softirq+0x68/0xac [cff8f9f0] [c0055f70] .irq_exit+0x54/0x6c [cff8fa70] [c000c358] .do_IRQ+0x170/0x1ac [cff8fb00] [c0004780] hardware_interrupt_entry+0x18/0x98 --- Exception: 501 at .pseries_dedicated_idle_sleep+0xe0/0x194 LR = .pseries_dedicated_idle_sleep+0xd0/0x194 [cff8fdf0] [] .__start+0x4000/0x8 (unreliable) [cff8fe80] [c0010bd4] .cpu_idle+0x104/0x1d8 [cff8ff00] [c002672c] .start_secondary+0x160/0x184 [cff8ff90] [c0008364] .start_secondary_prolog+0xc/0x10 Instruction dump: 409a0030 393f0018 3880 7d6048a8 7d6b0378 7d6049ad 40a2fff4 38002000 7d2018a8 7d290378 7d2019ad 40a2fff4 e89f0018 e969 f8410028 Kernel panic - not syncing: Fatal exception in interrupt [ cut here ] Badness at arch/powerpc/kernel/smp.c:202 NIP: c0026024 LR: c004e378 CTR: 8013f270 REGS: cffef120 TRAP: 0700 Tainted: G D (2.6.23-rc6-autokern1) MSR: 80021032 CR: 22002022 XER: 000a TASK = c000ecf9f000[0] 'swapper' THREAD: cff8c000 CPU: 2 GPR00: 0001 cffef3a0 c06fe598 c069ffb8 GPR04: 0001 0007 GPR08: c0739818 c0742998 c069ffb8 GPR12: 4000 c05f1700 07a8dcd0 GPR16: 0002 GPR20: 1000 1000 GPR24: 1000 0007 GPR28: c04e3190 c0685b80 NIP [c0026024] .smp_call_function_map+0x34/0x28c LR [c004e378] .panic+0x98/0x1b0 Call Trace: [cffef3a0] [c06943e8] 0xc06943e8 (unreliable) [cffef450] [c004e378] .panic+0x98/0x1b0 [cffef4f0] [c002213c] .die+0x224/0x264 [cffef590] [c00231f0] .machine_check_exception+0x210/0x240 [cffef610] [c0003480] machine_check_common+0x100/0x180 --- Exception: 200 at .end_bio_bh_io_sync+0x5c/0xac LR = .bio_endio+0xb4/0xd4 [cffef900] [cffef990] 0xcffef990 (unreliable) [cffef980] [c00efc7c] .bio_endio+0xb4/0xd4 [cffefa10] [c0290060] .__end_that_request_first+0x154/0x548 [cffefae0] [c035af10] .scsi_end_request+0x40/0x138 [cffefb80] [c035b234] .scsi_io_completion+0x188/0x454 [cffefc60] [c0372a24] .sd_rw_intr+0x2e4/0x338 [cffefd30] [c0354548] .scsi_finish_command+0xbc/0xe0 [cffefdc0] [c035bdf0] .scsi_softirq_done+0x140/0x188 [cffefe60] [c0293184] .blk_done_softirq+0xa0/0xd0 [cffefef0] [c0055e1c] .__do_softirq+0xa8/0x164 [cffeff90] [
RTC class drivers and powerpc arch
Hi, Since todc was removed from arch/powerpc I wonder how to use the rtc-cmos RTC class driver for my AmigaOne with its VIA southbridge. Do I have to define a platform device and the get/set_rtc_time hook functions or can the driver probe for and access the hardware automatically, if there's a device node for the RTC in the device tree? Thanks! regards, Gerhard -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/9] 8xx: Infrastructure code cleanup.
Hello David, On Fri, 14 Sep 2007 14:09:34 +1000 David Gibson wrote: > On Thu, Sep 13, 2007 at 12:16:40PM +0400, Vitaly Bordug wrote: > [snip] > > > This looks bogus. You're replacing the old crap immr_map() functions, > > > which ioremap()ed the registers every time, with a much simpler > > > version which uses an established-once mapping of the register > > > region. AFAICT, anywah. > > > > > > So far, so good - but your immr_unmap() still does an iounmap() which > > > is surely wrong - it should now be a no-op, leaving the mpc8xx_immr > > > mapping intact. You probably get away with it by accident, because I > > > imagine attempting to unmap an unaligned chunk of the region will just > > > fail. > > > > > > > yes, it should do nop instead of iounmap. > > > In fact, with this patch in place, I'd like to see another patch which > > > removes all calls to immr_map() and immr_unmap(), simply accessing the > > > common mapping directly. > > > > > Sorry, but originally, that stuff was created to get rid of BSP > > ifdefs in drivers. For PQ family, it is a common practice to have > > single driver handling all 3 CPU families, which use the same logic, > > but immr structure differs a little bit. > > > > At this point it's clear case-by-case ioremapping does not have firm > > benefit, but getting back to the way it was is useless either. In > > ideal world, we'd have all those stuff put into dts and have > > specific drivers be a shim layer between core hw and IO drivers. > > Err.. I don't understand what you're getting at. As the code stands > after Scott's cleanup, the map() and unmap() calls can certainly be > trivially removed, regardless of the history for them. > I don't argue if they can be removed, but if we aught to do that. Direct immr dereference adds plenty of mess into driver code. I would like to keep the situation when immr accesses factored out as a starting point, rather then turn them back to &immap-> or cpm2_immr-> refs. > And, yes, the drivers should certainly uses addresses from the device > tree, rather than that revolting structure covering all the inbuilt > device retgisters. hehe, then you prolly know, that this structure does not fin well into device/driver model, either platform_ or of_device. And I am going to sort it out at some point... -- Sincerely, Vitaly ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 19/25] spufs: Internal __spufs_get_foo() routines should take a spu_context *
On Fri, Sep 14, 2007 at 04:32:54PM +1000, Jeremy Kerr wrote: > From: Michael Ellerman <[EMAIL PROTECTED]> > > The SPUFS attribute get routines take a void * because the generic attribute > code doesn't know what sort of data it's passing around. > > However our internal __spufs_get_foo() routines can take a spu_context * > directly, which saves plonking it in and out of a void * again. Looks good. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 10/25] spusched: fix null pointer dereference in find_victim
On Fri, Sep 14, 2007 at 04:32:54PM +1000, Jeremy Kerr wrote: > From: Christoph Hellwig <[EMAIL PROTECTED]> > > find_victim can dereference a NULL pointer when iterating over the list > of victim spus because list_mutex only guarantees spu->ct to be stable, > but of course not to be non-NULL. > > Also fix find_victim to not call spu_unbind_context without list_mutex > because that violates the above guarantee. Didn't we want to try to get this into 2.6.23? It's a quite emberassing bug with a trivial fix. And a regression vs 2.6.22. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 02/25] spufs: remove asmlinkage from do_spu_create
On Fri, Sep 14, 2007 at 04:32:54PM +1000, Jeremy Kerr wrote: > do_spu_create doesn't need the asmlinkage qualifier; remove it. Ah, okay it's solved here. Drop my earlier comment then. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 09/25] cell: remove DEBUG for spu callbacks
On Fri, Sep 14, 2007 at 04:32:54PM +1000, Jeremy Kerr wrote: > We don't want SPE programs to be able to flood the kernel log by > invoking the SPE callback handler, so don't enable DEBUG for > spu_callbacks.c by default. Yeah, sounds sane. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 01/25] spufs: staticify file-internal functions & variables
On Fri, Sep 14, 2007 at 04:32:54PM +1000, Jeremy Kerr wrote: > From: Sebastian Siewior <[EMAIL PROTECTED]> > > There are a few symbols used only in one file within spufs; this change > makes them static where suitable. > > Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]> > Signed-off-by: Jeremy Kerr <[EMAIL PROTECTED]> Looks good. > +static asmlinkage long do_spu_create(const char __user *pathname, > + unsigned int flags, mode_t mode, struct file *neighbor) please drop the unessecary asmlinkage here, though. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
