LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH 1/6] IB/ehca: Serialize hypervisor calls in ehca_register_mr()
From: Roland Dreier @ 2007-05-10  3:03 UTC (permalink / raw)
  To: Joachim Fenkes
  Cc: LKML, LinuxPPC-Dev, Christoph Raisch, OF-General, Stefan Roscher
In-Reply-To: <200705091347.57470.fenkes@de.ibm.com>

thanks, it all looks fine... I'll apply when I'm back from my trip on Monday.

^ permalink raw reply

* Re: [PATCH] Move reg_booke.h to include/asm-powerpc
From: Kumar Gala @ 2007-05-10  2:11 UTC (permalink / raw)
  To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070510003452.GA483@localhost.localdomain>


On May 9, 2007, at 7:34 PM, David Gibson wrote:

> On Wed, May 09, 2007 at 02:31:19PM -0500, Becky Bruce wrote:
>> This patch moves reg_booke.h from include/asm-ppc to
>> include/asm-powerpc.  This is just a git-mv of the file; no changes
>> were made.  Tested builds of 8540 ADS and Ebony platforms with
>> ARCH=ppc and ARCH=powerpc.
>
> I'd much prefer if we copied rather than moved it to asm-powerpc.  I'm
> hoping we can get rid of the remaining sharing of include files shared
> between ppc and powerpc.  That way we can do cleanups in powerpc
> without worrying about breaking ppc.  In turn that should expedite
> progress towards ditching arch/ppc entirely.

Is there really a concern about this file only existing in arch/powerpc.

- k

^ permalink raw reply

* Re: [PATCH] Move reg_booke.h to include/asm-powerpc
From: David Gibson @ 2007-05-10  0:34 UTC (permalink / raw)
  To: Becky Bruce; +Cc: linuxppc-dev
In-Reply-To: <11787390792190-git-send-email-becky.bruce@freescale.com>

On Wed, May 09, 2007 at 02:31:19PM -0500, Becky Bruce wrote:
> This patch moves reg_booke.h from include/asm-ppc to
> include/asm-powerpc.  This is just a git-mv of the file; no changes
> were made.  Tested builds of 8540 ADS and Ebony platforms with
> ARCH=ppc and ARCH=powerpc.

I'd much prefer if we copied rather than moved it to asm-powerpc.  I'm
hoping we can get rid of the remaining sharing of include files shared
between ppc and powerpc.  That way we can do cleanups in powerpc
without worrying about breaking ppc.  In turn that should expedite
progress towards ditching arch/ppc entirely.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

^ permalink raw reply

* Re: [PATCH] drivers/ata/pata_scc.c: compile error fix
From: Akira Iguchi @ 2007-05-10  0:33 UTC (permalink / raw)
  To: jeff; +Cc: linux-ide, linuxppc-dev
In-Reply-To: <200705090612.l496CGpU010558@toshiba.co.jp>

I'm sorry I missed Alexey's patch.
Please ignore my patch.

Best regards,
Akira Iguchi

^ permalink raw reply

* PCMCIA on ppc64, and the joys of io port ranges on mmio-only platforms
From: Olof Johansson @ 2007-05-10  0:32 UTC (permalink / raw)
  To: linuxppc-dev, linux-kernel, linux-pcmcia

Hi,

We've got a very simple CF interface on our eval board, sitting on
localbus with a couple of gpios for control. mem and i/o port ranges
are mapped to two mmio ranges, i.e. 0xf0000000 and 0xf1000000 in our case.

I've got a pcmcia driver for the slot to handle all the probing, etc. It ioremaps both
the mem and io ranges, and provides that with the registered device:

        cf->mem_base = ioremap(mem->start, mem->end - mem->start);
        cf->io_base = ioremap(io->start, io->end - io->start);
[...]
        /* pcmcia layer only remaps "real" memory not iospace */
        cf->socket.io_offset = (unsigned long)cf->io_base;

        /* reserve chip-select regions */
        if (!request_mem_region(mem->start, mem->end + 1 - mem->start,
[...]
        if (!request_mem_region(io->start, io->end + 1 - io->start, driver_name))
[...]
        cf->socket.dev.parent = &ofdev->dev;
        cf->socket.ops = &electra_cf_ops;
        cf->socket.resource_ops = &pccard_static_ops;
        cf->socket.features = SS_CAP_PCCARD | SS_CAP_STATIC_MAP | SS_CAP_MEM_ALIGN;
[...]

(I'll post the full driver separately, but wanted to bring this up first).

Bottom line is that io_offset points to the ioremap()ed memory, i.e a
64-bit kernel address.

The problems show up further up the stack, in this case in the
pata_pcmcia driver, where pcmcia_request_io() is used to handle the
address allocation. That in turn calls alloc_io_space(), which takes an
ioaddr_t * as argument and does math on it.

ioaddr_t is 32-bit, causing obvious problems since io_offset is
64-bit. There's a compatible kio_addr_t available, but I'm guessing it's
already not used because of ABI requiremenets given the big warning at
the definition of ioaddr_t.

Since ppc64 never has had pcmcia before (We're the first platform with
it), changing the type under ifdef like mips/arm shouldn't be a problem,
at least it won't lead to regressions -- there's no previous user apps
to regress.


However, that's not enough in this case: Next thing that will fail is
ioport_map() in ppc-specific code, called from devm_ioport_map(). It
currently assumes to be passed the bus-local port number and adding
it to the ioremap base of the (normally only) bus with I/O ports,
i.e. ISA/LPC. Since we already use that for other devices (UARTS, etc),
we now have more than one base register.

I see two ways to solve this:

1. Create infrastructure to track the various io-port ranges, register
them and let the infrastructure take care of the ioremap, pick the right
ioport_map(), etc. I.e. create virtual io port ranges.

2. Make ioport_map() detect already mapped arguments (i.e.:
+       if (port >= IMALLOC_BASE && (port+len) < IMALLOC_END)
+               return (void __iomem *)port;

(1) would be appealing if it was the only change needed, and if that
meant that I didn't have to change ioaddr_t. It doesn't though, since
the pcmcia code still stores the ioport_map():ed value in an ioaddr_t,
so it really just adds complexity without that much benefit.

I'm tempted to go with (2) + type change but if someone has a third
option I'm all ears.


-Olof

^ permalink raw reply

* Re: [PATCH] [POWERPC] 8xx: PQ SoC IRDA support
From: Andrew Morton @ 2007-05-09 23:53 UTC (permalink / raw)
  To: Vitaly Bordug; +Cc: linuxppc-dev, Samuel Ortiz, linux-kernel
In-Reply-To: <20070508224206.4039.87074.stgit@localhost.localdomain>

On Wed, 09 May 2007 02:42:07 +0400
Vitaly Bordug <vitb@kernel.crashing.org> wrote:

> +		model = (char *)get_property(np, "model", NULL);
> +		if (model == NULL)
> +			return -ENODEV;
> +
> +		id = (u32 *) get_property(np, "device-id", NULL);

get_property() got renamed to of_get_property().

You have two coding-styles in the typecasting here.  The former (no space)
is more common and makes more sense, IMO.

However of_get_property() returns const void* so really you shouldn't be
doing any casting at all.  `model' should have type `const char *' and then
you can do

	model = get_property(np, "model", NULL);

which has nice type-safety and const-correctness.

^ permalink raw reply

* Re: [PATCH] Move reg_booke.h to include/asm-powerpc
From: Stephen Rothwell @ 2007-05-09 23:11 UTC (permalink / raw)
  To: Becky Bruce; +Cc: linuxppc-dev
In-Reply-To: <11787390792190-git-send-email-becky.bruce@freescale.com>

[-- Attachment #1: Type: text/plain, Size: 899 bytes --]

On Wed,  9 May 2007 14:31:19 -0500 Becky Bruce <becky.bruce@freescale.com> wrote:
>
> This patch moves reg_booke.h from include/asm-ppc to include/asm-powerpc.  This is
> just a git-mv of the file; no changes were made.  Tested builds of 8540 ADS and
> Ebony platforms with ARCH=ppc and ARCH=powerpc.
>
> Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
> ---
>  include/{asm-ppc => asm-powerpc}/reg_booke.h |    0
>  1 files changed, 0 insertions(+), 0 deletions(-)
>  rename include/{asm-ppc => asm-powerpc}/reg_booke.h (100%)
>
> diff --git a/include/asm-ppc/reg_booke.h b/include/asm-powerpc/reg_booke.h
> similarity index 100%
> rename from include/asm-ppc/reg_booke.h
> rename to include/asm-powerpc/reg_booke.h

Could you please change the self inclusion protection defines?

Thanks.
--
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* Re: vm changes from linux-2.6.14 to linux-2.6.15
From: Benjamin Herrenschmidt @ 2007-05-09 22:48 UTC (permalink / raw)
  To: Mark Fortescue
  Cc: linux-mm, wli, linuxppc-dev, andrea, sparclinux, Andrew Morton,
	David Miller
In-Reply-To: <Pine.LNX.4.61.0705092005060.29444@mtfhpc.demon.co.uk>

On Wed, 2007-05-09 at 20:44 +0100, Mark Fortescue wrote:
> Hi Ben,
> 
> Is it worth formally sending in either of my patches or does more work 
> need to be done first?

Sorry, I've been busy with other things...

What do other thing about it ? Having update_mmu_cache() call buried
inside the ptep_set_access_flags() sounds good ? Somebody has a better
idea ?

One thing I was thinking was that we could replace the whole logic with
having ptep_set_access_flags() compare the new PTE bits with what was
already there and return wether an update_mmu_cache() is required....

Ben.

^ permalink raw reply

* Re: [PATCH] [POWERPC] 8xx: PQ SoC IRDA support
From: Vitaly Bordug @ 2007-05-09 22:36 UTC (permalink / raw)
  To: Samuel Ortiz; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <irUYA8PN.1178718371.1966580.samuel@sortiz.org>

On 9 May 2007 13:46:11 -0000
Samuel Ortiz wrote:

> >So to recap, similar handling path for similar SoC device existing
> >in current kernel for a while now, and working good.  
> 
> I'm sure it works good, but doing the whole RX path from an interrupt
> handler doesn't sound like the best thing to do, at least to me. And
> with a SIR IrDA device, you can afford to offload your interrupt
> processing to a BH, nobody will notice the difference in terms of
> performance.
> I'm not against your proposed implementation, but I just think there's
> a nicer way to achieve the same result.
May I ask to point to the code you're keeping in mind here?

I'm not going to touch this path or else the code will miss this merge window as well, 
but I'm going to keep improving it, and this rework might be useful not only for this particular driver,
but for similar kernel pieces too.


-- 
Sincerely, Vitaly

^ permalink raw reply

* Re: [PATCH] powerpc: export pcibios_remove_pci_devices()
From: Linas Vepstas @ 2007-05-09 21:42 UTC (permalink / raw)
  To: John Rose; +Cc: External List, Paul Mackerras
In-Reply-To: <1178743853.22467.13.camel@sinatra.austin.ibm.com>

On Wed, May 09, 2007 at 03:50:53PM -0500, John Rose wrote:
> The rpadlpar_io module depends on this.

I sent this a few days ago, it should already be in orvlads git tree by
now ... 

^ permalink raw reply

* [PATCH] powerpc: export pcibios_remove_pci_devices()
From: John Rose @ 2007-05-09 20:50 UTC (permalink / raw)
  To: External List, Paul Mackerras, Nathan Fontenot

The rpadlpar_io module depends on this.

Signed-off-by: John Rose <johnrose@austin.ibm.com>

--

Thanks-
John

diff -puN arch/powerpc/platforms/pseries/pci_dlpar.c~export_pci_remove arch/powerpc/platforms/pseries/pci_dlpar.c
--- 2_6_linus/arch/powerpc/platforms/pseries/pci_dlpar.c~export_pci_remove	2007-05-09 15:52:50.000000000 -0500
+++ 2_6_linus-johnrose/arch/powerpc/platforms/pseries/pci_dlpar.c	2007-05-09 15:53:12.000000000 -0500
@@ -79,6 +79,7 @@ pcibios_remove_pci_devices(struct pci_bu
 		pci_remove_bus_device(dev);
 	}
 }
+EXPORT_SYMBOL(pcibios_remove_pci_devices);
 
 /* Must be called before pci_bus_add_devices */
 void

_

^ permalink raw reply

* Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure
From: Linas Vepstas @ 2007-05-09 20:26 UTC (permalink / raw)
  To: matthew; +Cc: linuxppc-dev, linux-pci, linux-kernel, linux-scsi
In-Reply-To: <20070420204720.GM31947@austin.ibm.com>

Hi Matthew,

I had been hoping these patches might make it into 2.6.22,
... this is a nag note; please forward upstream.

--linas

On Fri, Apr 20, 2007 at 03:47:20PM -0500, Linas Vepstas wrote:
> 
> Implement the so-called "first failure data capture" (FFDC) for the
> symbios PCI error recovery.  After a PCI error event is reported,
> the driver requests that MMIO be enabled. Once enabled, it 
> then reads and dumps assorted status registers, and concludes
> by requesting the usual reset sequence.
> 
> (includes a whitespace fix for bad indentation).
> 
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>

^ permalink raw reply

* [patch] PS3: Fix sys manager build error
From: Geoff Levand @ 2007-05-09 20:09 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev

Fix a PS3 build error when CONFIG_PS3_SYS_MANAGER=n.

Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>

---
Paul,

Please apply for 2.6.22.

 include/asm-powerpc/ps3.h |    5 +++++
 1 file changed, 5 insertions(+)

--- ps3-linux-dev.orig/include/asm-powerpc/ps3.h
+++ ps3-linux-dev/include/asm-powerpc/ps3.h
@@ -377,8 +377,13 @@ int ps3_vuart_port_device_register(struc
 
 /* system manager */
 
+#ifdef CONFIG_PS3_SYS_MANAGER
 void ps3_sys_manager_restart(void);
 void ps3_sys_manager_power_off(void);
+#else
+static inline void ps3_sys_manager_restart(void) {}
+static inline void ps3_sys_manager_power_off(void) {}
+#endif
 
 struct ps3_prealloc {
     const char *name;

^ permalink raw reply

* Re: Section mismatch warnings (was Re: [PATCH] early_pfn_to_nid needs to be __meminit)
From: Josh Boyer @ 2007-05-09 19:58 UTC (permalink / raw)
  To: Linas Vepstas; +Cc: Stephen Rothwell, LKML, ppc-dev, paulus, Andrew Morton
In-Reply-To: <20070509194503.GZ4452@austin.ibm.com>

On Wed, 2007-05-09 at 14:45 -0500, Linas Vepstas wrote:
> On Wed, May 09, 2007 at 06:51:15PM +0200, Gabriel Paubert wrote:
> > On Thu, May 10, 2007 at 02:25:52AM +1000, Stephen Rothwell wrote:
> > > This removes a section mismatch warning in those circumstances.
> > 
> > Speaking of this, I just tried to compile an official (Linus' git tree) 
> > kernel for my old PMac G4 and I get a lot of section mismatch warnings at 
> > the end of the compilation:
> > 
> > WARNING: arch/powerpc/mm/built-in.o - Section mismatch: reference to .init.text:early_get_page from .text between 'pte_alloc_one_kernel' (at offset 0xf50) and 'v_mapped_by_bats'
> > 
> > I find these 50 or so warnings so scary that I've not yet tried 
> > to boot the kernel. Note that this is a non-modular kernel.
> 
> I'm getting oodles of these on an older -mm2 tree. The kernels seem to
> work fine. Yes, they should be fixed but I'm up to my proverbial eyballs
> in alligators.

Yeah, I see all kinds of this too.  Does anyone have an idea why they're
being spit out?  Or if it's related to a particular binutils version,
etc?

josh

^ permalink raw reply

* Re: Section mismatch warnings (was Re: [PATCH] early_pfn_to_nid needs to be __meminit)
From: Linas Vepstas @ 2007-05-09 19:45 UTC (permalink / raw)
  To: Gabriel Paubert; +Cc: Stephen Rothwell, Andrew Morton, paulus, LKML, ppc-dev
In-Reply-To: <20070509165115.GA23576@iram.es>

On Wed, May 09, 2007 at 06:51:15PM +0200, Gabriel Paubert wrote:
> On Thu, May 10, 2007 at 02:25:52AM +1000, Stephen Rothwell wrote:
> > This removes a section mismatch warning in those circumstances.
> 
> Speaking of this, I just tried to compile an official (Linus' git tree) 
> kernel for my old PMac G4 and I get a lot of section mismatch warnings at 
> the end of the compilation:
> 
> WARNING: arch/powerpc/mm/built-in.o - Section mismatch: reference to .init.text:early_get_page from .text between 'pte_alloc_one_kernel' (at offset 0xf50) and 'v_mapped_by_bats'
> 
> I find these 50 or so warnings so scary that I've not yet tried 
> to boot the kernel. Note that this is a non-modular kernel.

I'm getting oodles of these on an older -mm2 tree. The kernels seem to
work fine. Yes, they should be fixed but I'm up to my proverbial eyballs
in alligators.

--linas

^ permalink raw reply

* Re: vm changes from linux-2.6.14 to linux-2.6.15
From: Mark Fortescue @ 2007-05-09 19:44 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: linux-mm, wli, linuxppc-dev, andrea, sparclinux, Andrew Morton,
	David Miller
In-Reply-To: <Pine.LNX.4.61.0705012354290.12808@mtfhpc.demon.co.uk>

Hi Ben,

Is it worth formally sending in either of my patches or does more work 
need to be done first?

If you would like me to test any changes, it takes me app. 2 hours to 
cross-compile a sparc kernel for my sun4c. I use my sparc system as a 
diskless client with a very minimal setup to alow me to test cross 
compiled GCC and any small platform independent code I may be working on.

I have not yet tried to get linux-2.6.21 or later working but for the test 
setup I have been using, it should not take too long if that is the kernel 
needed for testing.

I may also be able to do the same testing on an embedded PowerPC (32bit) 
(it will need some work to get my cross compilation system working again 
as some kernel changes in the ppc/powerpc architechture have proven to be 
incompatible with my build scripts) and on x86_64/ix86. Once I have fixed 
the build scripts, it will take app. 4 to 6 hours to get the initial NFS 
root minimal system built for these additional architectures and then app. 
2 hours for each test kernel build.

If a simple ADA build is not considered a suficiently harsh test, then I 
could cross compile a specialist test application, if one is available, or 
compile a more extensive application (maybe gcc) on the test system. The 
problem of compiling a more extensive application on the sparc system is 
that it is a slow system running as a diskless client with its NFS root on 
an aging i486 over a 10MBit Ethernet. The result is it will take days to 
compile somthing like gcc.

Regards
 	Mark Fortescue

On Wed, 2 May 2007, Mark Fortescue wrote:

>
>
> On Wed, 2 May 2007, Benjamin Herrenschmidt wrote:
>
>> 
>>> I have attached a patch (so pine does not mangle it) for linux-2.6.20.9.
>>> Is this what you had in mind?
>>> 
>>> For linux-2.6.21, more work will be needed as it has more code calling
>>> ptep_set_access_flags.
>> 
>> I'm not 100% sure we need the 'update' argument... we can remove the
>> whole old_entry, pte_same, etc... and just have pte_set_access_flags()
>> read the old PTE and decide wether something needs to be changed or not.
>> 
>> Ben.
>> 
>> 
>
> The attached patch works on sun4c (with my simple ADA compile test) but the 
> change in functionality may break things other platforms.
>
> The advantage of the previous patch is that the functionality is only changed 
> for sparc sun4c so less testing would be required.
>
> Regards
> 	Mark Fortescue.

^ permalink raw reply

* [PATCH] Move reg_booke.h to include/asm-powerpc
From: Becky Bruce @ 2007-05-09 19:31 UTC (permalink / raw)
  To: linuxppc-dev

This patch moves reg_booke.h from include/asm-ppc to include/asm-powerpc.  This is
just a git-mv of the file; no changes were made.  Tested builds of 8540 ADS and
Ebony platforms with ARCH=ppc and ARCH=powerpc.

Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
---
 include/{asm-ppc => asm-powerpc}/reg_booke.h |    0 
 1 files changed, 0 insertions(+), 0 deletions(-)
 rename include/{asm-ppc => asm-powerpc}/reg_booke.h (100%)

diff --git a/include/asm-ppc/reg_booke.h b/include/asm-powerpc/reg_booke.h
similarity index 100%
rename from include/asm-ppc/reg_booke.h
rename to include/asm-powerpc/reg_booke.h
-- 
1.5.0.3

^ permalink raw reply

* Re: [PATCH 05/13] Document the fsl, magic-packet property in gianfar nodes.
From: Scott Wood @ 2007-05-09 18:26 UTC (permalink / raw)
  To: Segher Boessenkool; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <baf8c79aa13de543816d62162d4f9928@kernel.crashing.org>

On Wed, May 09, 2007 at 04:33:12PM +0200, Segher Boessenkool wrote:
> >>>> As I previously wrote internally, it's only needed because some
> >>>> versions of the device have it and some don't; what it really means
> >>>> is that certain bits in certain registers are valid.
> 
> So have the driver detect this based on "compatible"
> or "model".

Thus requiring the driver to maintain a list of models/compatibles for
every possible combination of features, rather than letting the device
tree specify them individually.  What would be the advantage in that?

-Scott

^ permalink raw reply

* Section mismatch warnings (was Re: [PATCH] early_pfn_to_nid needs to be __meminit)
From: Gabriel Paubert @ 2007-05-09 16:51 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: ppc-dev, Andrew Morton, paulus, LKML
In-Reply-To: <20070510022552.4bb1a407.sfr@canb.auug.org.au>

On Thu, May 10, 2007 at 02:25:52AM +1000, Stephen Rothwell wrote:
> since it is referenced by memmap_init_zone (which is __meminit) via the
> early_pfn_in_nid macro when CONFIG_NODES_SPAN_OTHER_NODES is set (which
> basically means PowerPC 64).
> 
> This removes a section mismatch warning in those circumstances.

Speaking of this, I just tried to compile an official (Linus' git tree) 
kernel for my old PMac G4 and I get a lot of section mismatch warnings at 
the end of the compilation:

  LD      vmlinux
  SYSMAP  System.map
  SYSMAP  .tmp_System.map
  MODPOST vmlinux
WARNING: "fee_restarts" [arch/powerpc/kernel/built-in] is COMMON symbol
WARNING: "ee_restarts" [arch/powerpc/kernel/built-in] is COMMON symbol
WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from dt_string_start (offset 0x8)
WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from dt_string_end (offset 0xc)
...
WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from dt_struct_end (offset 0x20c)
WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from disp_BAT (offset 0x234)
WARNING: "primary_pteg_full" [arch/powerpc/mm/built-in] is COMMON symbol
WARNING: "next_slot" [arch/powerpc/mm/built-in] is COMMON symbol
WARNING: "htab_hash_searches" [arch/powerpc/mm/built-in] is COMMON symbol
WARNING: arch/powerpc/mm/built-in.o - Section mismatch: reference to .init.text:early_get_page from .text between 'pte_alloc_one_kernel' (at offset 0xf50) and 'v_mapped_by_bats'
WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: reference to .init.data:.got2 from  (offset 0x0)
...
WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: reference to .init.text:pmac_pcibios_after_init from .machine.desc after 'mach_powermac' (at offset 0xc4)
WARNING: mm/built-in.o - Section mismatch: reference to .init.text:set_up_list3s from .text between 'kmem_cache_create' (at
offset 0x1de88) and 'kmem_cache_shrink'
WARNING: mm/built-in.o - Section mismatch: reference to .init.text:set_up_list3s from .text between 'kmem_cache_create' (at
offset 0x1dec0) and 'kmem_cache_shrink'

I find these 50 or so warnings so scary that I've not yet tried 
to boot the kernel. Note that this is a non-modular kernel.

	Gabriel

^ permalink raw reply

* [PATCH] powerpc: add dts entries to 85xx for EDAC
From: Dave Jiang @ 2007-05-09 16:53 UTC (permalink / raw)
  To: galak; +Cc: linuxppc-dev, paulus
In-Reply-To: <6fb05a0954f19c5744369c18670d81ff@kernel.crashing.org>


Adding memory-controller and l2-cache-controller entries to be used by EDAC as
of_devices.

Signed-off-by: Dave Jiang <djiang@mvista.com>

---
 arch/powerpc/boot/dts/mpc8540ads.dts |   16 ++++++++++++++++
 arch/powerpc/boot/dts/mpc8548cds.dts |   16 ++++++++++++++++
 arch/powerpc/boot/dts/mpc8560ads.dts |   18 +++++++++++++++++-
 3 files changed, 49 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc8540ads.dts b/arch/powerpc/boot/dts/mpc8540ads.dts
index f261d64..5471227 100644
--- a/arch/powerpc/boot/dts/mpc8540ads.dts
+++ b/arch/powerpc/boot/dts/mpc8540ads.dts
@@ -48,6 +48,22 @@
 		reg = <e0000000 00100000>;	// CCSRBAR 1M
 		bus-frequency = <0>;
 
+		memory-controller@2000 {
+			compatible = "fsl,8540-memory-controller";
+			reg = <2000 1000>;
+			interrupt-parent = <&mpic>;
+			interrupts = <2 2>;
+		};
+
+		l2-cache-controller@20000 {
+			compatible = "fsl,85xx-l2-cache-controller";
+			reg = <20000 1000>;
+			cache-line-size = <20>;	// 32 bytes
+			cache-size = <40000>;	// L2, 256K
+			interrupt-parent = <&mpic>;
+			interrupts = <0 2>;
+		};
+
 		i2c@3000 {
 			device_type = "i2c";
 			compatible = "fsl-i2c";
diff --git a/arch/powerpc/boot/dts/mpc8548cds.dts b/arch/powerpc/boot/dts/mpc8548cds.dts
index b2b2200..f0c5256 100644
--- a/arch/powerpc/boot/dts/mpc8548cds.dts
+++ b/arch/powerpc/boot/dts/mpc8548cds.dts
@@ -48,6 +48,22 @@
 		reg = <e0000000 00100000>;	// CCSRBAR 1M
 		bus-frequency = <0>;
 
+		memory-controller@2000 {
+			compatible = "fsl,8548-memory-controller";
+			reg = <2000 1000>;
+			interrupt-parent = <&mpic>;
+			interrupts = <2 2>;
+		};
+
+		l2-cache-controller@20000 {
+			compatible = "fsl,85xx-l2-cache-controller";
+			reg = <20000 1000>;
+			cache-line-size = <20>;	// 32 bytes
+			cache-size = <40000>;	// L2, 256K
+			interrupt-parent = <&mpic>;
+			interrupts = <0 2>;
+		};
+
 		i2c@3000 {
 			device_type = "i2c";
 			compatible = "fsl-i2c";
diff --git a/arch/powerpc/boot/dts/mpc8560ads.dts b/arch/powerpc/boot/dts/mpc8560ads.dts
index 1f2afe9..144fc65 100644
--- a/arch/powerpc/boot/dts/mpc8560ads.dts
+++ b/arch/powerpc/boot/dts/mpc8560ads.dts
@@ -48,6 +48,22 @@
 		reg = <e0000000 00000200>;
 		bus-frequency = <13ab6680>;
 
+		memory-controller@2000 {
+			compatible = "fsl,8540-memory-controller";
+			reg = <2000 1000>;
+			interrupt-parent = <&mpic>;
+			interrupts = <2 2>;
+		};
+
+		l2-cache-controller@20000 {
+			compatible = "fsl,85xx-l2-cache-controller";
+			reg = <20000 1000>;
+			cache-line-size = <20>;	// 32 bytes
+			cache-size = <40000>;	// L2, 256K
+			interrupt-parent = <&mpic>;
+			interrupts = <0 2>;
+		};
+
 		mdio@24520 {
 			device_type = "mdio";
 			compatible = "gianfar";
@@ -110,7 +126,7 @@
 			#address-cells = <3>;
 			compatible = "85xx";
 			device_type = "pci";
-			reg = <8000 400>;
+			reg = <8000 1000>;
 			clock-frequency = <3f940aa>;
 			interrupt-map-mask = <f800 0 0 7>;
 			interrupt-map = <

^ permalink raw reply related

* Re: Build failure with Linus' tree
From: Stephen Rothwell @ 2007-05-09 16:39 UTC (permalink / raw)
  To: Ken Moffat; +Cc: linuxppc-dev
In-Reply-To: <20070509161723.GA20759@deepthought>

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

Hi Ken,

On Wed, 9 May 2007 17:17:23 +0100 Ken Moffat <zarniwhoop@ntlworld.com> wrote:
>
>  On my G5 I'm getting this on a copy of Linus' tree I pulled a bit
> over two hours ago:
>
>   LD      .tmp_vmlinux1
> arch/powerpc/sysdev/built-in.o: In function `.iommu_init_late_dart':
> dart_iommu.c:(.init.text+0xf10): undefined reference to
> `.register_nosave_region_late'
> make: *** [.tmp_vmlinux1] Error 1
>
>  I suppose that something is wrong in sysdev/dart_iommu.c, probably
> related to suspend changes - if I need to bisect, it will take some
> time (this is an SMU powermac, dead slow) so I'll mention it here
> now.

Should be already fixed in Paulus' latest tree (and in Linus' tree after
he pulls).

--
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* [PATCH]: PowerPC: Assorted janitorial EEH cleanups.
From: Linas Vepstas @ 2007-05-09 16:38 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: Olof Johansson, linuxppc-dev


Assorted minor cleanups to EEH code; -- use literals, use
kerneldoc format.

Signed-off-by: Linas Vepstas <linas@austin.ibm.com>

----
 arch/powerpc/platforms/pseries/eeh.c        |   13 ++++++++++---
 arch/powerpc/platforms/pseries/eeh_driver.c |    7 ++++---
 include/asm-powerpc/ppc-pci.h               |   18 +++++++++++++++---
 3 files changed, 29 insertions(+), 9 deletions(-)

Index: linux-2.6.21-rc7-mm2/arch/powerpc/platforms/pseries/eeh_driver.c
===================================================================
--- linux-2.6.21-rc7-mm2.orig/arch/powerpc/platforms/pseries/eeh_driver.c	2007-05-08 17:56:55.000000000 -0500
+++ linux-2.6.21-rc7-mm2/arch/powerpc/platforms/pseries/eeh_driver.c	2007-05-09 11:19:11.000000000 -0500
@@ -378,8 +378,9 @@ struct pci_dn * handle_eeh_events (struc
 
 	/* Since rtas may enable MMIO when posting the error log,
 	 * don't post the error log until after all dev drivers
-	 * have been informed. */
-	eeh_slot_error_detail(frozen_pdn, 1 /* Temporary Error */);
+	 * have been informed.
+	 */
+	eeh_slot_error_detail(frozen_pdn, EEH_LOG_TEMP_FAILURE);
 
 	/* If all device drivers were EEH-unaware, then shut
 	 * down all of the device drivers, and hope they
@@ -470,7 +471,7 @@ hard_fail:
 		location, drv_str, pci_str);
 
 perm_error:
-	eeh_slot_error_detail(frozen_pdn, 2 /* Permanent Error */);
+	eeh_slot_error_detail(frozen_pdn, EEH_LOG_PERM_FAILURE);
 
 	/* Notify all devices that they're about to go down. */
 	pci_walk_bus(frozen_bus, eeh_report_failure, NULL);
Index: linux-2.6.21-rc7-mm2/include/asm-powerpc/ppc-pci.h
===================================================================
--- linux-2.6.21-rc7-mm2.orig/include/asm-powerpc/ppc-pci.h	2007-04-26 15:37:56.000000000 -0500
+++ linux-2.6.21-rc7-mm2/include/asm-powerpc/ppc-pci.h	2007-05-09 11:19:30.000000000 -0500
@@ -62,11 +62,14 @@ struct pci_dev *pci_get_device_by_addr(u
 
 /**
  * eeh_slot_error_detail -- record and EEH error condition to the log
- * @severity: 1 if temporary, 2 if permanent failure.
+ * @pdn:      pci device node
+ * @severity: EEH_LOG_TEMP_FAILURE or EEH_LOG_PERM_FAILURE
  *
  * Obtains the the EEH error details from the RTAS subsystem,
  * and then logs these details with the RTAS error log system.
  */
+#define EEH_LOG_TEMP_FAILURE 1
+#define EEH_LOG_PERM_FAILURE 2
 void eeh_slot_error_detail (struct pci_dn *pdn, int severity);
 
 /**
@@ -82,6 +85,7 @@ int rtas_pci_enable(struct pci_dn *pdn, 
 
 /**
  * rtas_set_slot_reset -- unfreeze a frozen slot
+ * @pdn:       pci device node
  *
  * Clear the EEH-frozen condition on a slot.  This routine
  * does this by asserting the PCI #RST line for 1/8th of
@@ -95,6 +99,7 @@ int eeh_wait_for_slot_status(struct pci_
 
 /** 
  * eeh_restore_bars - Restore device configuration info.
+ * @pdn:       pci device node
  *
  * A reset of a PCI device will clear out its config space.
  * This routines will restore the config space for this
@@ -105,6 +110,7 @@ void eeh_restore_bars(struct pci_dn *);
 
 /**
  * rtas_configure_bridge -- firmware initialization of pci bridge
+ * @pdn:       pci device node
  *
  * Ask the firmware to configure all PCI bridges devices
  * located behind the indicated node. Required after a
@@ -118,16 +124,22 @@ int rtas_write_config(struct pci_dn *, i
 int rtas_read_config(struct pci_dn *, int where, int size, u32 *val);
 
 /**
+ * eeh_mark_slot -- set mode flags for pertition endpoint
+ * @pdn:       pci device node
+ *
  * mark and clear slots: find "partition endpoint" PE and set or 
  * clear the flags for each subnode of the PE.
  */
 void eeh_mark_slot (struct device_node *dn, int mode_flag);
 void eeh_clear_slot (struct device_node *dn, int mode_flag);
 
-/* Find the associated "Partiationable Endpoint" PE */
+/**
+ * find_device_pe -- Find the associated "Partiationable Endpoint" PE
+ * @pdn:       pci device node
+ */
 struct device_node * find_device_pe(struct device_node *dn);
 
-#endif
+#endif /* CONFIG_EEH */
 
 #else /* CONFIG_PCI */
 static inline void find_and_init_phbs(void) { }
Index: linux-2.6.21-rc7-mm2/arch/powerpc/platforms/pseries/eeh.c
===================================================================
--- linux-2.6.21-rc7-mm2.orig/arch/powerpc/platforms/pseries/eeh.c	2007-05-08 17:56:55.000000000 -0500
+++ linux-2.6.21-rc7-mm2/arch/powerpc/platforms/pseries/eeh.c	2007-05-09 11:26:01.000000000 -0500
@@ -76,7 +76,7 @@
  */
 #define EEH_MAX_FAILS	2100000
 
-/* Time to wait for a PCI slot to retport status, in milliseconds */
+/* Time to wait for a PCI slot to report status, in milliseconds */
 #define PCI_BUS_RESET_WAIT_MSEC (60*1000)
 
 /* RTAS tokens */
@@ -95,11 +95,18 @@ EXPORT_SYMBOL(eeh_subsystem_enabled);
 /* Lock to avoid races due to multiple reports of an error */
 static DEFINE_SPINLOCK(confirm_error_lock);
 
-/* Buffer for reporting slot-error-detail rtas calls */
+/* Buffer for reporting slot-error-detail rtas calls. Its here
+ * in BSS, and not dynamically alloced, so that it ends up in
+ * RMO where RTAS can access it.
+ */
 static unsigned char slot_errbuf[RTAS_ERROR_LOG_MAX];
 static DEFINE_SPINLOCK(slot_errbuf_lock);
 static int eeh_error_buf_size;
 
+/* Buffer for reporting pci register dumps. Its here in BSS, and
+ * not dynamically alloced, so that it ends up in RMO where RTAS
+ * can access it.
+ */
 #define EEH_PCI_REGS_LOG_LEN 4096
 static unsigned char pci_regs_buf[EEH_PCI_REGS_LOG_LEN];
 
@@ -218,7 +225,7 @@ static size_t gather_pci_data(struct pci
 void eeh_slot_error_detail(struct pci_dn *pdn, int severity)
 {
 	size_t loglen = 0;
-	memset(pci_regs_buf, 0, EEH_PCI_REGS_LOG_LEN);
+	pci_regs_buf[0] = 0;
 
 	rtas_pci_enable(pdn, EEH_THAW_MMIO);
 	loglen = gather_pci_data(pdn, pci_regs_buf, EEH_PCI_REGS_LOG_LEN);

^ permalink raw reply

* Build failure with Linus' tree
From: Ken Moffat @ 2007-05-09 16:17 UTC (permalink / raw)
  To: linuxppc-dev

 On my G5 I'm getting this on a copy of Linus' tree I pulled a bit
over two hours ago:

  LD      .tmp_vmlinux1
arch/powerpc/sysdev/built-in.o: In function `.iommu_init_late_dart':
dart_iommu.c:(.init.text+0xf10): undefined reference to
`.register_nosave_region_late'
make: *** [.tmp_vmlinux1] Error 1

 I suppose that something is wrong in sysdev/dart_iommu.c, probably
related to suspend changes - if I need to bisect, it will take some
time (this is an SMU powermac, dead slow) so I'll mention it here
now.

Ken
--=20
das eine Mal als Trag=F6die, das andere Mal als Farce

^ permalink raw reply

* Re: MPC832xEMDS: ttyS0 output stops mid boot
From: Alex Zeffertt @ 2007-05-09 16:31 UTC (permalink / raw)
  Cc: u-boot-users, linuxppc-embedded
In-Reply-To: <8c4dd9590705030939i5df99f3fw83a59698fe3d30cc@mail.gmail.com>

Hi,

For the record, I've just merged powerpc.git from kernel.org and it has started
working now!  Clearly this means it was a kernel issue rather than a bootloader
issue.

Regards,

Alex

Alex Zeffertt wrote:
> Hi,
> 
> Sorry about the cross posting, but I'm not sure which list I should send 
> to....
> 
> I'm trying to boot an up-to-date kernel on my MPC8323E-MDS-PB board, but 
> I the
> console output stops early on during the kernel boot.
> 
> I'm running the latest u-boot (git://www.denx.de/git/u-boot-mpc83xx.git) 
> with
> its default environment.  The kernel is built from Paulus' powerpc.git, 
> after
> checking out tag 2.6.21-rc5.  The dtb is build from
> arch/powerpc/boot/dts/mpc832x_mds.dts
> with the latest compiler (git://www.jdl.com/software/dtc.git).
> 
> Has anyone else been here before...?  If so I'd appreciate any help you can
> offer.
> 
> TIA,
> 
> Alex
> 
> -------------------my ttyS0 output------------------
> =>
> => printenv
> bootcmd=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath
> ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off
> console=$consoledev,$baudrate $othbootargs;tftp $loadaddr
> $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr - $fdtaddr
> ramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate
> $othbootargs;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr
> $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr
> nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath
> ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off
> console=$consoledev,$baudrate $othbootargs;tftp $loadaddr
> $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr - $fdtaddr
> bootdelay=6
> baudrate=115200
> loads_echo=1
> ethaddr=00:04:9f:ef:03:01
> eth1addr=00:04:9f:ef:03:02
> loadaddr=200000
> netdev=eth0
> consoledev=ttyS0
> ramdiskaddr=1000000
> ramdiskfile=ramfs.83xx
> fdtaddr=400000
> fdtfile=mpc832xemds.dtb
> stdin=serial
> stdout=serial
> stderr=serial
> ethact=FSL UEC0
> 
> Environment size: 979/8188 bytes
> => setenv ramdiskfile uRamdisk
> => setenv fdtfile mpc832x_mds.dtb
> => setenv bootfile uImage
> => setenv serverip 10.0.0.107
> => setenv ipaddr 10.0.6.65
> => run ramboot
> Using FSL UEC0 device
> TFTP from server 10.0.0.107; our IP address is 10.0.6.65
> Filename 'uRamdisk'.
> Load address: 0x1000000
> Loading: #################################################################
>         #################################################################
>         #################################################################
>         #################################################################
>         #################################################################
>         #################################################################
>         #################################################################
>         #################################################################
>         #################################################################
>         ###########################################################
> done
> Bytes transferred = 3296770 (324e02 hex)
> Using FSL UEC0 device
> TFTP from server 10.0.0.107; our IP address is 10.0.6.65
> Filename 'uImage'.
> Load address: 0x200000
> Loading: #################################################################
>         #################################################################
>         #################################################################
>         ##########################################
> done
> Bytes transferred = 1212615 (1280c7 hex)
> Using FSL UEC0 device
> TFTP from server 10.0.0.107; our IP address is 10.0.6.65
> Filename 'mpc832x_mds.dtb'.
> Load address: 0x400000
> Loading: ###
> done
> Bytes transferred = 12288 (3000 hex)
> ## Booting image at 00200000 ...
>   Image Name:   Linux-2.6.21-rc5
>   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>   Data Size:    1212551 Bytes =  1.2 MB
>   Load Address: 00000000
>   Entry Point:  00000000
>   Verifying Checksum ... OK
>   Uncompressing Kernel Image ... OK
> ## Loading RAMDisk Image at 01000000 ...
>   Image Name:   uboot ext2 ramdisk rootfs
>   Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
>   Data Size:    3296706 Bytes =  3.1 MB
>   Load Address: 00000000
>   Entry Point:  00000000
>   Verifying Checksum ... OK
>   Booting using flat device tree at 0x400000
>   Loading Ramdisk to 07c87000, end 07fabdc2 ... OK
> Using MPC832x MDS machine description
> Linux version 2.6.21-rc5 (ajz@zambia) (gcc version 3.4.3) #2 Thu May 3
> 16:42:54 BST 2007
> Found initrd at 0xc7c87000:0xc7fabdc2
> setup_arch: bootmem
> mpc832x_sys_setup_arch()
> Found MPC83xx PCI host bridge at 0x00000000e0008500. Firmware bus 
> number: 0->0
> arch: exit
> Zone PFN ranges:
>  DMA             0 ->    32768
>  Normal      32768 ->    32768
> early_node_map[1] active PFN ranges
>    0:        0 ->    32768
> Built 1 zonelists.  Total pages: 32512
> Kernel command line: root=/dev/ram rw console=ttyS0,115200
> IPIC (128 IRQ sources) at fddf3700
> QEIC (64 IRQ sources) at fddf2080
> PID hash table entries: 512 (order: 9, 2048 bytes)

^ permalink raw reply

* Re: [PATCH 1/2] Declare {compat_}sys_utimensat
From: Stephen Rothwell @ 2007-05-09 16:32 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linuxppc-dev, Andrew Morton, Linus, paulus, LKML
In-Reply-To: <200705091821.59412.arnd@arndb.de>

[-- Attachment #1: Type: text/plain, Size: 656 bytes --]

On Wed, 9 May 2007 18:21:58 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
>
> It seems bogus to declare compat_sys_futimesat in syscalls.h and
> compat_sys_utimensat in compat.h. Your patch is fine, since there
> are precedents for both, but maybe we should agree on one place and
> then move all of the compat_sys_ declarations there.

My preference is to split them like this so that the architectures that
don't need the compat infrastructure are not cluttered with it (if we
declare the compat routines in syscalls.h, then it should include
compat.h).

--
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox