* Re: virtex_devices.c
From: Grant Likely @ 2007-05-07 0:46 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <463E4B13.2030600@dlasys.net>
On 5/6/07, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> >> At some point if I get inspired I may take a wack at crafting
> >> generic approach using an early serial mini driver.
> >>
> >> But for the moment my choices are:
> >> add a few more 8250 specific #ifdefs to kill off most of
> >> the
> >> conflicting code in virtex_devices.c
> >> and adapt my own code that is already in my BSP. This is the
> >> simplest and does the least damage to your code.
>
> > Considering the fact that the whole purpose of virtex_devices.c is to
> > massage the mess of #defines that is xparameters.h in to something
> > more parsable, then extra #if defined() test may not be a big deal.
> This is not just about virtex_devices. Supporting early Output on
> something other than an 8250
> requires #ifdef's all over creation.
> This is just screaming for a more generic solution. But that needs
> to happen without
> much increase in complexity
Okay if I understand you correctly, you're talking about two areas:
1. setting up output in the zImage wrapper (which is easy), and
2. Stuff turned on by CONFIG_SERIAL_TEXT_DEBUG which does seem to be a
mess of #ifdefs.
Uartlite s already supported in the zImage wrapper, and keyhole
support should be easy to add. As far as CONFIG_SERIAL_TEXT_DEBUG
support; it's probably a case of do whatever you need to make it work;
but don't get too worked up about getting it into mainline. It's all
pretty arch/ppc specific at the moment, and if you want to work on a
generic solution then you should probably wait until arch/powerpc is
working.
> > However, I need clarification. Are you talking about early serial
> > port support, console support or regular serial devices?
> While I am specifically dealing with one area. More broadly I am
> talking about
> all Output prior to the real serial driver coming up.
> This seems to be the pre-linux stuff in
> arch/ppc/boot/simple. You just added a uartlite_tty.c there. I have
> had one for a long time.
> but that is pretty trivial.
> and the slightly more complex
> arch/ppc/syslib/uartlite_dbg that is used by the progress stuff and
> for a bit prior to the early serial
> driver code.
> I do not think you have code for this - but I do.
No, I've not tackled this, and I haven't looked at your code.
> These bits are only critical when something early goes completely to
> crap.
> But then they are important.
>
> > For example;
> > on one of my boards here I've got both 16550 and uartlite devices on
> > the same board and it works fine for serial port access. I've also
> > got another design with only uartlite and another with only 16550.
> > Each of these scenarios should work with the code that is now in
> > mainline (but there are some issues still).
> This is also relevant to me because I have another pseudo serial
> device that I support in exactly the same way as UartLite. It is unique
> enough to our hardware that it is likely of little interest to anyone else.
> But it means everytime I look at a UartLite
Bullshit. :-) The pico is a commercially available board; support
for it should be in mainline. Besides, support in mainline should
make it easier for Pico to sell boards. :-)
> issue, I am looking at a "keyhole" issue too. It means that everywhere
> there is an 8250 specific solution to a problem, I end up with a 3 way fork.
> While support for early non-8250's is lite - there are others besides the
> uartlite and my keyhole.
Right; I agree this should be fixed. However keep in mind that if you
work on it in arch/ppc; you'll probably just end up redoing all your
work again in arch/powerpc.
> > plat_serial8250_port is used because it is the structure used by the
> > platform bus to connect the 8250 driver to 8250 devices. This is of
> > course specific to the 8250 driver. The Uartlite ports are simple
> > enough that they don't need a *_platform_data structure; instead the
> > resources table in a virtex_platform_devices[] entry is sufficient to
> > describe the device to the platform bus. You should be able to do the
> > same thing with your keyhole device registration.
> By substituting uart_port for plat_serial8250 I end up with something generic.
> I do not understand the rational behind the plat_serialxxxx structs.
> It is not like u-boot or something else passes them, they seem to be
> entirely a kernel
> creation, they contain no information that is not in uart_port which
> is generic for
> anything that pretends to be a serial device, and using the
> plat_serial8250 means
> individually copying values from that struct to a uart_port.
> By just substitution uart_port for plat_serial8250 I end up with
> code that is
> exactly the same for anything that looks like a serial device.
plat_serial8250 isn't supposed to be generic. You shouldn't use it as
such. It is supposed to be the driver specific data for the driver's
platform device binding. I may not like the approach of
plat_serial8250, but it at the correct level, and therefore isolated.
The 8250 platform bus binding is the only user of that data.
The generic bit is the platform_device structure. the
virtex_platform_devices[] table is supposed to contain one entry per
device. (8250 is an abomination in this regard; it uses 1
platform_device entry to represent all 8250 serial ports). The
generic early serial code should *not* be looking to the
virtex_serial_platform_data[] table to find ports. It should be
parsing the virtex_platform_devices[] table.
It is done this way because the platform bus infrastructure takes care
of binding platform_device records to platform bus device drivers. No
extra code required.
> > Now, early serial is still a problem. When using zImages, you must
> > To add early serial support, I think virtex_early_serial_map() should
> > be reworked to scan the whole virtex_platform_devices table looking
> > for either "uartlite", "serial8250" or "keyhole" devices.
>
> That is basically what I am doing.
> The UART macro(s) in xparameters, are changed to use uart_port
> element names.
> All serial/pseudo serial devices are setup uniformly the same.
> Serial devices are distinguishable in the uart_port struct by
> their .type field,
> In the rare instances I need to distinguish there are if's or
> switches on the .type field.
Yes, but then you need to write new code to pass each port off to the
correct driver; completely ignoring the platform bus code which *does
the exact same thing*.
> > It doesn't smell right; but I'm not sure I fully understand what
> > you're suggesting. Show me patches.
>
> The basic fundimental question is why is there an 8250 specific
> structure,
> when there is a perfectly good generic structure that already exists ?
> Actually it seems to be even more complex than that because I think
> there is actually an
> old_serial structure that is also used in places.
I ask the opposite question; why try to make the 8250 structure
generic when there is already a generic structure that does exactly
what you want one level up?
I *do* think that 8250 should be changed; but not in the way you're describing.
>
> This is not really a virtex or ppc question and probably belongs on
> linux-serial,
> but the gist is uart_port is what the majority if not all serial
> devices end up using.
Right; but we're not talking about the internal use of uart_port by
the drivers. We're talking about the
> instead of starting with something else and then having incongruent
> field names
> lots fo device specific code and/or #ifdef's,
> if we just use uart_port instead of plat_serialxxx's for every device,
> then all code gets simpler as does adding additional devices.
> Shortly I hope. I have code, it is just not working at this minute.
> Actually I suspect it is working, but my overall migration from my
> implimentation of your earlier code to my implimentation of your newer
> code is not yet working.
I look forward to seeing it.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 4/6] Device tree aware EMAC driver
From: Olof Johansson @ 2007-05-07 0:57 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070507003019.GB16165@localhost.localdomain>
On Mon, May 07, 2007 at 10:30:19AM +1000, David Gibson wrote:
> This is BenH's rewritten, device tree aware driver for the IBM/AMCC
> EMAC, ethernet MAC controller ASIC found on various 4xx CPUs and also
> the Axon bridge. Tweaked to build on current kernels.
Shouldn't benh have a signoff line on it as well in that case?
Is it ibm_emac or ibm_newemac? All file headers say ibm_emac, and there's
still Kconfig references to ibm_emac.
(Is this just posted FYI? If not, it should really go to netdev/jgarzik
instead, right?)
-Olof
^ permalink raw reply
* Re: virtex_devices.c
From: Grant Likely @ 2007-05-07 1:17 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0705061746s28ebb15et428c7afda2f477ba@mail.gmail.com>
On 5/6/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 5/6/07, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> > The basic fundimental question is why is there an 8250 specific
> > structure,
> > when there is a perfectly good generic structure that already exists ?
> > Actually it seems to be even more complex than that because I think
> > there is actually an
> > old_serial structure that is also used in places.
>
> I ask the opposite question; why try to make the 8250 structure
> generic when there is already a generic structure that does exactly
> what you want one level up?
>
> I *do* think that 8250 should be changed; but not in the way you're describing.
Although this point is actually moot because platform_bus pretty much
goes away when we move to arch/powerpc. We'll be using
of_platform_devices instead (which map onto nodes in the device tree).
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 4/6] Device tree aware EMAC driver
From: David Gibson @ 2007-05-07 1:40 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070507005723.GA4453@lixom.net>
On Sun, May 06, 2007 at 07:57:23PM -0500, Olof Johansson wrote:
> On Mon, May 07, 2007 at 10:30:19AM +1000, David Gibson wrote:
> > This is BenH's rewritten, device tree aware driver for the IBM/AMCC
> > EMAC, ethernet MAC controller ASIC found on various 4xx CPUs and also
> > the Axon bridge. Tweaked to build on current kernels.
>
> Shouldn't benh have a signoff line on it as well in that case?
Well, his patch which I tweaked didn't have his signoff, so I didn't
think I ought to add it.
> Is it ibm_emac or ibm_newemac? All file headers say ibm_emac, and there's
> still Kconfig references to ibm_emac.
It's ibm_newemac, the file headers just haven't been updated. The
Kconfig changes referring to ibm_emac are just because the patch moves
the suboptions for the old emac driver into their own subdirectory,
and it inhibits selecting the old emac driver in arch/powerpc.
> (Is this just posted FYI? If not, it should really go to netdev/jgarzik
> instead, right?)
This is just FYI at the moment, or rather, it's not really an Ebony
related patch but it's in this series because the Ebony support is
much more interesting if the ethernet works.
--
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
* ppc: Fix build problem in ppc4xx_sgdma.c
From: David Gibson @ 2007-05-07 2:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
ppc4xx_sgdma.c is #including asm/dma-mapping.h directly, which should
only ever be included via linux/dma-mapping.h. asm/dma-mapping.h
relies on an enum defined in linux/dma-mapping.h before its own
include. This fixes the problem.
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Index: working-2.6/arch/ppc/syslib/ppc4xx_sgdma.c
===================================================================
--- working-2.6.orig/arch/ppc/syslib/ppc4xx_sgdma.c 2007-05-07 12:04:40.000000000 +1000
+++ working-2.6/arch/ppc/syslib/ppc4xx_sgdma.c 2007-05-07 12:04:47.000000000 +1000
@@ -23,10 +23,10 @@
#include <linux/mm.h>
#include <linux/init.h>
#include <linux/module.h>
+#include <linux/dma-mapping.h>
#include <asm/system.h>
#include <asm/io.h>
-#include <asm/dma-mapping.h>
#include <asm/ppc4xx_dma.h>
void
--
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 5/6] Support for the Ebony 440GP reference board in arch/powerpc
From: David Gibson @ 2007-05-07 3:22 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070504143645.GA10645@lixom.net>
On Fri, May 04, 2007 at 09:36:45AM -0500, Olof Johansson wrote:
> Hi,
>
> Not much actual board support code in here, nice and clean. :-) Seems
> like most of this was boot wrapper enhancements.
Mostly, yes. There will be more in-kernel support code coming
eventually, when we get PCI, the RTC and various other peripherals
going.
> Some comments below.
>
>
> -Olof
>
> On Fri, May 04, 2007 at 03:57:33PM +1000, David Gibson wrote:
>
> > Index: working-2.6/arch/powerpc/kernel/head_44x.S
> > ===================================================================
> > --- working-2.6.orig/arch/powerpc/kernel/head_44x.S 2007-05-03 10:19:32.000000000 +1000
> > +++ working-2.6/arch/powerpc/kernel/head_44x.S 2007-05-04 13:46:51.000000000 +1000
> > @@ -709,16 +709,6 @@ _GLOBAL(giveup_fpu)
> > blr
> > #endif
> >
> > -/*
> > - * extern void abort(void)
> > - *
> > - * At present, this routine just applies a system reset.
> > - */
> > -_GLOBAL(abort)
> > - mfspr r13,SPRN_DBCR0
> > - oris r13,r13,DBCR0_RST_SYSTEM@h
> > - mtspr SPRN_DBCR0,r13
> > -
>
> Looks like this rename is really separate from the platform support. Maybe
> post it as such in a patch before this one?
Hrm, I suppose I could. Is it really worth it?
> Also, I know it was just a rename but you might want to add a "b ."
> after it, if for some reason the reset doesn't happen instantly to avoid
> executing random code afterwards.
Added.
[snip]
> > +static struct of_device_id ebony_of_bus[] = {
> > + { .type = "ibm,plb", },
> > + { .type = "ibm,opb", },
> > + { .type = "ibm,ebc", },
> > + {},
> > +};
> > +
> > +static int __init ebony_device_probe(void)
> > +{
> > + if (! machine_is(ebony))
>
> Extra space after !
Fixed.
[snip]
> > Index: working-2.6/arch/powerpc/platforms/Makefile
> > ===================================================================
> > --- working-2.6.orig/arch/powerpc/platforms/Makefile 2007-02-14 10:58:22.000000000 +1100
> > +++ working-2.6/arch/powerpc/platforms/Makefile 2007-05-04 13:46:51.000000000 +1000
> > @@ -6,7 +6,8 @@ obj-$(CONFIG_PPC_PMAC) += powermac/
> > endif
> > endif
> > obj-$(CONFIG_PPC_CHRP) += chrp/
> > -obj-$(CONFIG_4xx) += 4xx/
> > +#obj-$(CONFIG_4xx) += 4xx/
>
> Hmm?
Contrary to the comment in arch/powerpc/platforms/4xx/Makefile, an
empty Makefile does *not* compile correctly within Kbuild. It's
commented out so we build again, obviously it will need to go back in
once there's any code that actually works in
arch/powerpc/platforms/4xx.
[snip]
> > Index: working-2.6/arch/powerpc/boot/dcr.h
> > ===================================================================
> > --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> > +++ working-2.6/arch/powerpc/boot/dcr.h 2007-05-04 13:46:51.000000000 +1000
> > @@ -0,0 +1,85 @@
> > +#ifndef _PPC_BOOT_DCR_H_
> > +#define _PPC_BOOT_DCR_H_
> > +
> > +#define mfdcr(rn) \
> > + ({ \
> > + unsigned long rval; \
> > + asm volatile("mfdcr %0,%1" : "=r"(rval) : "i"(rn)); \
> > + rval; \
> > + })
> > +#define mtdcr(rn, val) \
> > + asm volatile("mtdcr %0,%1" : : "i"(rn), "r"(val))
> > +
> > +/* 440GP/440GX SDRAM controller DCRs */
> > +#define DCRN_SDRAM0_CFGADDR 0x010
> > +#define DCRN_SDRAM0_CFGDATA 0x011
> > +
> > +#define SDRAM0_B0CR 0x40
> > +#define SDRAM0_B1CR 0x44
> > +#define SDRAM0_B2CR 0x48
> > +#define SDRAM0_B3CR 0x4c
> > +
> > +static const unsigned long sdram_bxcr[] = { SDRAM0_B0CR, SDRAM0_B1CR, SDRAM0_B2CR, SDRAM0_B3CR };
> > +
> > +#define SDRAM_CONFIG_BANK_ENABLE 0x00000001
> > +#define SDRAM_CONFIG_SIZE_MASK 0x000e0000
> > +#define SDRAM_CONFIG_BANK_SIZE(reg) \
> > + (0x00400000 << ((reg & SDRAM_CONFIG_SIZE_MASK) >> 17))
>
> Lots of tabs here? Other powerpc code tends to use
> <tab><space><space><space> for the register field defines indentation.
>
> Same for below.
Yeah, I suppose they do. Spacing revised through this file.
> > +
> > +/* 440GP Clock, PM, chip control */
> > +#define DCRN_CPC0_SR 0x0b0
> > +#define DCRN_CPC0_ER 0x0b1
> > +#define DCRN_CPC0_FR 0x0b2
> > +#define DCRN_CPC0_SYS0 0x0e0
> > +#define CPC0_SYS0_TUNE 0xffc00000
> > +#define CPC0_SYS0_FBDV_MASK 0x003c0000
> > +#define CPC0_SYS0_FBDV(reg) \
> > + ((((((reg) & CPC0_SYS0_FBDV_MASK) >> 18) - 1) & 0xf) + 1)
>
> Would you mind a short comment about why the above math is needed?
Ok, I've regrouped all those macros together, and added:
/* Helper macros to compute the actual clock divider values from the
* encodings in the CPC0 register */
[snip]
> > +#define SPRN_DBCR0 0x134
> > +#define DBCR0_RST_SYSTEM 0x30000000
> > +
> > +static void ebony_exit(void)
> > +{
> > + unsigned long tmp;
> > +
> > + asm volatile (
> > + "mfspr %0,%1\n"
> > + "oris %0,%0,%2@h\n"
> > + "mtspr %1,%0"
> > + : "=&r"(tmp) : "i"(SPRN_DBCR0), "i"(DBCR0_RST_SYSTEM)
>
> You don't have to pass in the constants here, you can specify them in
> the asm. Makes it a little more readable.
As discussed in that other thread, not quite as easy as it sounds.
Unless, possibly, you use some abomination like asm volatile("#include
...")
[snip]
--
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 5/6] Support for the Ebony 440GP reference board in arch/powerpc
From: Olof Johansson @ 2007-05-07 3:45 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070507032206.GB21287@localhost.localdomain>
Hi,
On Mon, May 07, 2007 at 01:22:06PM +1000, David Gibson wrote:
> On Fri, May 04, 2007 at 09:36:45AM -0500, Olof Johansson wrote:
> > Hi,
> >
> > Not much actual board support code in here, nice and clean. :-) Seems
> > like most of this was boot wrapper enhancements.
>
> Mostly, yes. There will be more in-kernel support code coming
> eventually, when we get PCI, the RTC and various other peripherals
> going.
Makes sense.
> > > Index: working-2.6/arch/powerpc/kernel/head_44x.S
> > > ===================================================================
> > > --- working-2.6.orig/arch/powerpc/kernel/head_44x.S 2007-05-03 10:19:32.000000000 +1000
> > > +++ working-2.6/arch/powerpc/kernel/head_44x.S 2007-05-04 13:46:51.000000000 +1000
> > > @@ -709,16 +709,6 @@ _GLOBAL(giveup_fpu)
> > > blr
> > > #endif
> > >
> > > -/*
> > > - * extern void abort(void)
> > > - *
> > > - * At present, this routine just applies a system reset.
> > > - */
> > > -_GLOBAL(abort)
> > > - mfspr r13,SPRN_DBCR0
> > > - oris r13,r13,DBCR0_RST_SYSTEM@h
> > > - mtspr SPRN_DBCR0,r13
> > > -
> >
> > Looks like this rename is really separate from the platform support. Maybe
> > post it as such in a patch before this one?
>
> Hrm, I suppose I could. Is it really worth it?
Personally I prefer to see new code separate from just
renames/moves/cleanups, it makes the new code easier to spot during
review. My first reaction when reading this patch was "why does he remove
this?" since it wasn't added until X chunks later down in the file.
> > > Index: working-2.6/arch/powerpc/platforms/Makefile
> > > ===================================================================
> > > --- working-2.6.orig/arch/powerpc/platforms/Makefile 2007-02-14 10:58:22.000000000 +1100
> > > +++ working-2.6/arch/powerpc/platforms/Makefile 2007-05-04 13:46:51.000000000 +1000
> > > @@ -6,7 +6,8 @@ obj-$(CONFIG_PPC_PMAC) += powermac/
> > > endif
> > > endif
> > > obj-$(CONFIG_PPC_CHRP) += chrp/
> > > -obj-$(CONFIG_4xx) += 4xx/
> > > +#obj-$(CONFIG_4xx) += 4xx/
> >
> > Hmm?
>
> Contrary to the comment in arch/powerpc/platforms/4xx/Makefile, an
> empty Makefile does *not* compile correctly within Kbuild. It's
> commented out so we build again, obviously it will need to go back in
> once there's any code that actually works in
> arch/powerpc/platforms/4xx.
I'm not sure I follow you here. This patch also adds the makefile, and
it's not empty (if you-ve got CONFIG_4xx enabled, it will build at least
one file in there)?
> > > +#define SPRN_DBCR0 0x134
> > > +#define DBCR0_RST_SYSTEM 0x30000000
> > > +
> > > +static void ebony_exit(void)
> > > +{
> > > + unsigned long tmp;
> > > +
> > > + asm volatile (
> > > + "mfspr %0,%1\n"
> > > + "oris %0,%0,%2@h\n"
> > > + "mtspr %1,%0"
> > > + : "=&r"(tmp) : "i"(SPRN_DBCR0), "i"(DBCR0_RST_SYSTEM)
> >
> > You don't have to pass in the constants here, you can specify them in
> > the asm. Makes it a little more readable.
>
> As discussed in that other thread, not quite as easy as it sounds.
> Unless, possibly, you use some abomination like asm volatile("#include
> ...")
Yea, that just makes it worse. It was a bad suggestion, nevermind.
-Olof
^ permalink raw reply
* Re: [PATCH 4/6] Device tree aware EMAC driver
From: Olof Johansson @ 2007-05-07 3:56 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070507014051.GF16165@localhost.localdomain>
Hi,
On Mon, May 07, 2007 at 11:40:51AM +1000, David Gibson wrote:
> On Sun, May 06, 2007 at 07:57:23PM -0500, Olof Johansson wrote:
> > On Mon, May 07, 2007 at 10:30:19AM +1000, David Gibson wrote:
> > > This is BenH's rewritten, device tree aware driver for the IBM/AMCC
> > > EMAC, ethernet MAC controller ASIC found on various 4xx CPUs and also
> > > the Axon bridge. Tweaked to build on current kernels.
> >
> > Shouldn't benh have a signoff line on it as well in that case?
>
> Well, his patch which I tweaked didn't have his signoff, so I didn't
> think I ought to add it.
Heh, ok.
> > Is it ibm_emac or ibm_newemac? All file headers say ibm_emac, and there's
> > still Kconfig references to ibm_emac.
>
> It's ibm_newemac, the file headers just haven't been updated. The
> Kconfig changes referring to ibm_emac are just because the patch moves
> the suboptions for the old emac driver into their own subdirectory,
> and it inhibits selecting the old emac driver in arch/powerpc.
Hm, so it both modifies the old driver and adds the new one? Is the plan
to have both of them in parallel? Sounds wasteful, but I guess it'll be
hard to avoid until 4xx is dead in arch/ppc.
> > (Is this just posted FYI? If not, it should really go to netdev/jgarzik
> > instead, right?)
>
> This is just FYI at the moment, or rather, it's not really an Ebony
> related patch but it's in this series because the Ebony support is
> much more interesting if the ethernet works.
Ok. It really sucks trying to review patches of this size, but I'll try
to make a few passes over it.
It'd be useful to just see the incremental steps of how it was morphed
from the current driver, but that's a pain to recreate once you have
this kind of blob. Especially if you inherited the bulk of it. :-)
-Olof
^ permalink raw reply
* Re: [PATCH] powerpc: Support new property called interrupt-parents
From: Paul Mackerras @ 2007-05-07 3:57 UTC (permalink / raw)
To: Stuart Yoder; +Cc: linuxppc-dev
In-Reply-To: <200703201917.l2KJHO51015104@ld0164-tx32.am.freescale.net>
Stuart Yoder writes:
> Support new property called interrupt-parents. This enables the
> description of devices that have multiple interrupts that are routed to
> different interrupt controllers.
I think we can get the same effect by using an interrupt-map property
in the node, with the node's interrupt-parent pointing to itself.
That way we can just use the existing interrupt-map parsing code.
Paul.
^ permalink raw reply
* Re: [PATCH 5/6] Support for the Ebony 440GP reference board in arch/powerpc
From: David Gibson @ 2007-05-07 4:02 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070507034526.GA5352@lixom.net>
On Sun, May 06, 2007 at 10:45:26PM -0500, Olof Johansson wrote:
> Hi,
>
> On Mon, May 07, 2007 at 01:22:06PM +1000, David Gibson wrote:
> > On Fri, May 04, 2007 at 09:36:45AM -0500, Olof Johansson wrote:
> > > Hi,
> > >
> > > Not much actual board support code in here, nice and clean. :-) Seems
> > > like most of this was boot wrapper enhancements.
> >
> > Mostly, yes. There will be more in-kernel support code coming
> > eventually, when we get PCI, the RTC and various other peripherals
> > going.
>
> Makes sense.
>
> > > > Index: working-2.6/arch/powerpc/kernel/head_44x.S
> > > > ===================================================================
> > > > --- working-2.6.orig/arch/powerpc/kernel/head_44x.S 2007-05-03 10:19:32.000000000 +1000
> > > > +++ working-2.6/arch/powerpc/kernel/head_44x.S 2007-05-04 13:46:51.000000000 +1000
> > > > @@ -709,16 +709,6 @@ _GLOBAL(giveup_fpu)
> > > > blr
> > > > #endif
> > > >
> > > > -/*
> > > > - * extern void abort(void)
> > > > - *
> > > > - * At present, this routine just applies a system reset.
> > > > - */
> > > > -_GLOBAL(abort)
> > > > - mfspr r13,SPRN_DBCR0
> > > > - oris r13,r13,DBCR0_RST_SYSTEM@h
> > > > - mtspr SPRN_DBCR0,r13
> > > > -
> > >
> > > Looks like this rename is really separate from the platform support. Maybe
> > > post it as such in a patch before this one?
> >
> > Hrm, I suppose I could. Is it really worth it?
>
> Personally I prefer to see new code separate from just
> renames/moves/cleanups, it makes the new code easier to spot during
> review. My first reaction when reading this patch was "why does he remove
> this?" since it wasn't added until X chunks later down in the file.
Oh, ok, I'll split it out again.
> > > > Index: working-2.6/arch/powerpc/platforms/Makefile
> > > > ===================================================================
> > > > --- working-2.6.orig/arch/powerpc/platforms/Makefile 2007-02-14 10:58:22.000000000 +1100
> > > > +++ working-2.6/arch/powerpc/platforms/Makefile 2007-05-04 13:46:51.000000000 +1000
> > > > @@ -6,7 +6,8 @@ obj-$(CONFIG_PPC_PMAC) += powermac/
> > > > endif
> > > > endif
> > > > obj-$(CONFIG_PPC_CHRP) += chrp/
> > > > -obj-$(CONFIG_4xx) += 4xx/
> > > > +#obj-$(CONFIG_4xx) += 4xx/
> > >
> > > Hmm?
> >
> > Contrary to the comment in arch/powerpc/platforms/4xx/Makefile, an
> > empty Makefile does *not* compile correctly within Kbuild. It's
> > commented out so we build again, obviously it will need to go back in
> > once there's any code that actually works in
> > arch/powerpc/platforms/4xx.
>
> I'm not sure I follow you here. This patch also adds the makefile, and
> it's not empty (if you-ve got CONFIG_4xx enabled, it will build at least
> one file in there)?
Not quite. The patch adds the platforms/44x/Makefile, it comments out
4xx so that the (empty) platforms/4xx/Makefile is not invoked.
Possibly we should rename 44x to ibm_booke everywhere to avoid this
kind of confusion.
--
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 4/6] Device tree aware EMAC driver
From: David Gibson @ 2007-05-07 4:10 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070507035639.GA5567@lixom.net>
On Sun, May 06, 2007 at 10:56:39PM -0500, Olof Johansson wrote:
> Hi,
>
> On Mon, May 07, 2007 at 11:40:51AM +1000, David Gibson wrote:
> > On Sun, May 06, 2007 at 07:57:23PM -0500, Olof Johansson wrote:
> > > On Mon, May 07, 2007 at 10:30:19AM +1000, David Gibson wrote:
> > > > This is BenH's rewritten, device tree aware driver for the IBM/AMCC
> > > > EMAC, ethernet MAC controller ASIC found on various 4xx CPUs and also
> > > > the Axon bridge. Tweaked to build on current kernels.
> > >
> > > Shouldn't benh have a signoff line on it as well in that case?
> >
> > Well, his patch which I tweaked didn't have his signoff, so I didn't
> > think I ought to add it.
>
> Heh, ok.
>
> > > Is it ibm_emac or ibm_newemac? All file headers say ibm_emac, and there's
> > > still Kconfig references to ibm_emac.
> >
> > It's ibm_newemac, the file headers just haven't been updated. The
> > Kconfig changes referring to ibm_emac are just because the patch moves
> > the suboptions for the old emac driver into their own subdirectory,
> > and it inhibits selecting the old emac driver in arch/powerpc.
>
> Hm, so it both modifies the old driver and adds the new one?
Well, barely. It moves the Kconfig around a little for the old
driver, but doesn't change the actual code at all.
> Is the plan
> to have both of them in parallel? Sounds wasteful, but I guess it'll be
> hard to avoid until 4xx is dead in arch/ppc.
Exactly.
> > > (Is this just posted FYI? If not, it should really go to netdev/jgarzik
> > > instead, right?)
> >
> > This is just FYI at the moment, or rather, it's not really an Ebony
> > related patch but it's in this series because the Ebony support is
> > much more interesting if the ethernet works.
>
> Ok. It really sucks trying to review patches of this size, but I'll try
> to make a few passes over it.
>
> It'd be useful to just see the incremental steps of how it was morphed
> from the current driver, but that's a pain to recreate once you have
> this kind of blob. Especially if you inherited the bulk of it. :-)
Heh. Talk to Ben, but I think he'll be too busy to reply, let alone
reconstruct the patch sequence. My contribution is a one-liner to fix
a recent build failure.
--
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 v2 4/7] Add support for 750CL Holly board
From: Paul Mackerras @ 2007-05-07 4:22 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1178381871.3393.32.camel@zod.rchland.ibm.com>
Josh Boyer writes:
> +config HOLLY
That's a bit too non-specific, I think; please make it PPC_HOLLY.
Paul.
^ permalink raw reply
* Re: [PATCH 17/19] PCI: rpaphp: Use pcibios_remove_pci_devices() symmetrically
From: Michael Ellerman @ 2007-05-07 5:09 UTC (permalink / raw)
To: Linas Vepstas
Cc: Andrew Morton, linuxppc-dev, Kristen Carlson Accardi,
pcihpd-discuss
In-Reply-To: <20070403173154.77B623A65C@topology.austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]
On Tue, 2007-04-03 at 12:31 -0500, Linas Vepstas wrote:
> At first blush, the disable_slot() routine does not look
> at all like its symmetric with the enable_slot() routine;
> as it seems to call a very different set of routines.
> However, this is easily fixed: pcibios_remove_pci_devices()
> does the right thing.
>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
> Cc: John Rose <johnrose@austin.ibm.com>
>
> ----
>
> drivers/pci/hotplug/rpaphp_core.c | 10 ++--------
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> Index: linux-2.6.21-rc4-git4/drivers/pci/hotplug/rpaphp_core.c
> ===================================================================
> --- linux-2.6.21-rc4-git4.orig/drivers/pci/hotplug/rpaphp_core.c 2007-04-03 11:04:41.000000000 -0500
> +++ linux-2.6.21-rc4-git4/drivers/pci/hotplug/rpaphp_core.c 2007-04-03 11:04:47.000000000 -0500
> @@ -424,18 +424,12 @@ static int enable_slot(struct hotplug_sl
> return retval;
> }
>
> -static int __disable_slot(struct slot *slot)
> +static inline int __disable_slot(struct slot *slot)
> {
> - struct pci_dev *dev, *tmp;
> -
> if (slot->state == NOT_CONFIGURED)
> return -EINVAL;
>
> - list_for_each_entry_safe(dev, tmp, &slot->bus->devices, bus_list) {
> - eeh_remove_bus_device(dev);
> - pci_remove_bus_device(dev);
> - }
> -
> + pcibios_remove_pci_devices(slot->bus);
You need to add an EXPORT_SYMBOL() for this.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Cope with PCI host bridge I/O window not starting at 0
From: Paul Mackerras @ 2007-05-07 5:16 UTC (permalink / raw)
To: linuxppc-dev
Currently our code to set up the data structures for a PCI host bridge
and create the mapping for its I/O window assumes that the window
starts at I/O port 0 on the PCI side. If this is not true, we can end
up with I/O port numbers in the resources for PCI devices which will
cause an oops if a driver tries to access them via inb/outb etc.,
because there is no mapping for the corresponding addresses.
Normally the I/O window starts at 0, but there are some situations on
partitioned machines with a hypervisor where the window may not start
at 0.
This fixes the problem by allocating space for the range from 0 to the
end of the I/O window. That is, hose->io_base_virt contains the
virtual address for I/O port 0 on the PCI bus, and thus the assumption
that hose->io_base_virt - pci_io_base is the offset between the
"global" I/O port numbers (those in the PCI device resources) and the
I/O port numbers on the PCI bus is maintained.
For PCI host bridges that are present at boot, we only map the portion
of that range that correspond to the bridge's I/O window. For bridges
added after boot we ioremap the range from 0 to the end of the I/O
window, for now; in fact hot-added bridges should be using
reserve_phb_iospace() and __ioremap_explicit (so they get sensible
global port numbers), but we don't have the infrastructure yet to do
that (basically a free_phb_iospace() routine plus appropriate
locking).
Interestingly, this makes the two arms of the if statement in
get_bus_io_range do almost exactly the same thing; that function could
now be simplified in a further patch.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index 60d7d4b..706b7f3 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -1006,8 +1006,9 @@ void __devinit pci_process_bridge_OF_ranges(struct pci_controller *hose,
switch ((pci_space >> 24) & 0x3) {
case 1: /* I/O space */
- hose->io_base_phys = cpu_phys_addr;
- hose->pci_io_size = size;
+ hose->io_base_phys = cpu_phys_addr - pci_addr;
+ /* handle from 0 to top of I/O window */
+ hose->pci_io_size = pci_addr + size;
res = &hose->io_resource;
res->flags = IORESOURCE_IO;
@@ -1117,8 +1118,8 @@ static int get_bus_io_range(struct pci_bus *bus, unsigned long *start_phys,
} else {
/* Root Bus */
res = &hose->io_resource;
- *start_phys = hose->io_base_phys;
- *start_virt = (unsigned long) hose->io_base_virt;
+ *start_phys = hose->io_base_phys + res->start;
+ *start_virt = (unsigned long) hose->io_base_virt + res->start;
if (res->end > res->start)
*size = res->end - res->start + 1;
else {
^ permalink raw reply related
* powerpc: Remove use of 4level-fixup.h for ppc32
From: David Gibson @ 2007-05-07 5:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
For 32-bit systems, powerpc still relies on the 4level-fixup.h hack,
to pretend that the generic pagetable handling stuff is 3-levels
rather than 4. This patch removes this, instead using the newer
pgtable-nopmd.h to handle the elision of both the pud and pmd
pagetable levels (ppc32 pagetables are actually 2 levels).
This removes a little extraneous code, and makes it more easily
compared to the 64-bit pagetable code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
arch/powerpc/lib/dma-noncoherent.c | 4 +++-
arch/powerpc/mm/pgtable_32.c | 28 ++++++++++++++++------------
include/asm-powerpc/page.h | 4 ++++
include/asm-powerpc/pgalloc-32.h | 4 ++--
include/asm-powerpc/pgtable-ppc32.h | 30 ++----------------------------
5 files changed, 27 insertions(+), 43 deletions(-)
Index: working-2.6/include/asm-powerpc/pgtable-ppc32.h
===================================================================
--- working-2.6.orig/include/asm-powerpc/pgtable-ppc32.h 2007-05-07 15:30:04.000000000 +1000
+++ working-2.6/include/asm-powerpc/pgtable-ppc32.h 2007-05-07 15:30:04.000000000 +1000
@@ -1,7 +1,7 @@
#ifndef _ASM_POWERPC_PGTABLE_PPC32_H
#define _ASM_POWERPC_PGTABLE_PPC32_H
-#include <asm-generic/4level-fixup.h>
+#include <asm-generic/pgtable-nopmd.h>
#ifndef __ASSEMBLY__
#include <linux/sched.h>
@@ -76,13 +76,8 @@ extern unsigned long ioremap_bot, iorema
* level has 2048 entries and the second level has 512 64-bit PTE entries.
* -Matt
*/
-/* PMD_SHIFT determines the size of the area mapped by the PTE pages */
-#define PMD_SHIFT (PAGE_SHIFT + PTE_SHIFT)
-#define PMD_SIZE (1UL << PMD_SHIFT)
-#define PMD_MASK (~(PMD_SIZE-1))
-
/* PGDIR_SHIFT determines what a top-level page table entry can map */
-#define PGDIR_SHIFT PMD_SHIFT
+#define PGDIR_SHIFT (PAGE_SHIFT + PTE_SHIFT)
#define PGDIR_SIZE (1UL << PGDIR_SHIFT)
#define PGDIR_MASK (~(PGDIR_SIZE-1))
@@ -103,8 +98,6 @@ extern unsigned long ioremap_bot, iorema
#define pte_ERROR(e) \
printk("%s:%d: bad pte %llx.\n", __FILE__, __LINE__, \
(unsigned long long)pte_val(e))
-#define pmd_ERROR(e) \
- printk("%s:%d: bad pmd %08lx.\n", __FILE__, __LINE__, pmd_val(e))
#define pgd_ERROR(e) \
printk("%s:%d: bad pgd %08lx.\n", __FILE__, __LINE__, pgd_val(e))
@@ -516,19 +509,6 @@ extern unsigned long empty_zero_page[102
#ifndef __ASSEMBLY__
/*
- * The "pgd_xxx()" functions here are trivial for a folded two-level
- * setup: the pgd is never bad, and a pmd always exists (as it's folded
- * into the pgd entry)
- */
-static inline int pgd_none(pgd_t pgd) { return 0; }
-static inline int pgd_bad(pgd_t pgd) { return 0; }
-static inline int pgd_present(pgd_t pgd) { return 1; }
-#define pgd_clear(xp) do { } while (0)
-
-#define pgd_page_vaddr(pgd) \
- ((unsigned long) __va(pgd_val(pgd) & PAGE_MASK))
-
-/*
* The following only work if pte_present() is true.
* Undefined behaviour if not..
*/
@@ -737,12 +717,6 @@ extern pgprot_t phys_mem_access_prot(str
#define pgd_index(address) ((address) >> PGDIR_SHIFT)
#define pgd_offset(mm, address) ((mm)->pgd + pgd_index(address))
-/* Find an entry in the second-level page table.. */
-static inline pmd_t * pmd_offset(pgd_t * dir, unsigned long address)
-{
- return (pmd_t *) dir;
-}
-
/* Find an entry in the third-level page table.. */
#define pte_index(address) \
(((address) >> PAGE_SHIFT) & (PTRS_PER_PTE - 1))
Index: working-2.6/include/asm-powerpc/page.h
===================================================================
--- working-2.6.orig/include/asm-powerpc/page.h 2007-05-07 14:24:21.000000000 +1000
+++ working-2.6/include/asm-powerpc/page.h 2007-05-07 15:30:04.000000000 +1000
@@ -121,9 +121,11 @@ typedef struct { pte_t pte; } real_pte_t
#endif
/* PMD level */
+#ifdef CONFIG_PPC64
typedef struct { unsigned long pmd; } pmd_t;
#define pmd_val(x) ((x).pmd)
#define __pmd(x) ((pmd_t) { (x) })
+#endif
/* PUD level exusts only on 4k pages */
#if defined(CONFIG_PPC64) && !defined(CONFIG_PPC_64K_PAGES)
@@ -159,9 +161,11 @@ typedef unsigned long real_pte_t;
#endif
+#if defined (CONFIG_PPC64)
typedef unsigned long pmd_t;
#define pmd_val(x) (x)
#define __pmd(x) (x)
+#endif
#if defined(CONFIG_PPC64) && !defined(CONFIG_PPC_64K_PAGES)
typedef unsigned long pud_t;
Index: working-2.6/arch/powerpc/mm/pgtable_32.c
===================================================================
--- working-2.6.orig/arch/powerpc/mm/pgtable_32.c 2007-04-26 13:57:24.000000000 +1000
+++ working-2.6/arch/powerpc/mm/pgtable_32.c 2007-05-07 15:30:04.000000000 +1000
@@ -261,7 +261,7 @@ int map_page(unsigned long va, phys_addr
int err = -ENOMEM;
/* Use upper 10 bits of VA to index the first level map */
- pd = pmd_offset(pgd_offset_k(va), va);
+ pd = pmd_offset(pud_offset(pgd_offset_k(va), va), va);
/* Use middle 10 bits of VA to index the second-level map */
pg = pte_alloc_kernel(pd, va);
if (pg != 0) {
@@ -354,23 +354,27 @@ int
get_pteptr(struct mm_struct *mm, unsigned long addr, pte_t **ptep, pmd_t **pmdp)
{
pgd_t *pgd;
+ pud_t *pud;
pmd_t *pmd;
pte_t *pte;
int retval = 0;
pgd = pgd_offset(mm, addr & PAGE_MASK);
if (pgd) {
- pmd = pmd_offset(pgd, addr & PAGE_MASK);
- if (pmd_present(*pmd)) {
- pte = pte_offset_map(pmd, addr & PAGE_MASK);
- if (pte) {
- retval = 1;
- *ptep = pte;
- if (pmdp)
- *pmdp = pmd;
- /* XXX caller needs to do pte_unmap, yuck */
- }
- }
+ pud = pud_offset(pgd, addr & PAGE_MASK);
+ if (pud && pud_present(*pud)) {
+ pmd = pmd_offset(pud, addr & PAGE_MASK);
+ if (pmd_present(*pmd)) {
+ pte = pte_offset_map(pmd, addr & PAGE_MASK);
+ if (pte) {
+ retval = 1;
+ *ptep = pte;
+ if (pmdp)
+ *pmdp = pmd;
+ /* XXX caller needs to do pte_unmap, yuck */
+ }
+ }
+ }
}
return(retval);
}
Index: working-2.6/include/asm-powerpc/pgalloc-32.h
===================================================================
--- working-2.6.orig/include/asm-powerpc/pgalloc-32.h 2007-05-07 12:57:07.000000000 +1000
+++ working-2.6/include/asm-powerpc/pgalloc-32.h 2007-05-07 15:30:04.000000000 +1000
@@ -12,10 +12,10 @@ extern void pgd_free(pgd_t *pgd);
* We don't have any real pmd's, and this code never triggers because
* the pgd will always be present..
*/
-#define pmd_alloc_one(mm,address) ({ BUG(); ((pmd_t *)2); })
+/* #define pmd_alloc_one(mm,address) ({ BUG(); ((pmd_t *)2); }) */
#define pmd_free(x) do { } while (0)
#define __pmd_free_tlb(tlb,x) do { } while (0)
-#define pgd_populate(mm, pmd, pte) BUG()
+/* #define pgd_populate(mm, pmd, pte) BUG() */
#ifndef CONFIG_BOOKE
#define pmd_populate_kernel(mm, pmd, pte) \
Index: working-2.6/arch/powerpc/lib/dma-noncoherent.c
===================================================================
--- working-2.6.orig/arch/powerpc/lib/dma-noncoherent.c 2007-02-09 09:57:55.000000000 +1100
+++ working-2.6/arch/powerpc/lib/dma-noncoherent.c 2007-05-07 15:30:04.000000000 +1000
@@ -306,13 +306,15 @@ EXPORT_SYMBOL(__dma_free_coherent);
static int __init dma_alloc_init(void)
{
pgd_t *pgd;
+ pud_t *pud;
pmd_t *pmd;
pte_t *pte;
int ret = 0;
do {
pgd = pgd_offset(&init_mm, CONSISTENT_BASE);
- pmd = pmd_alloc(&init_mm, pgd, CONSISTENT_BASE);
+ pud = pud_alloc(&init_mm, pgd, CONSISTENT_BASE);
+ pmd = pmd_alloc(&init_mm, pud, CONSISTENT_BASE);
if (!pmd) {
printk(KERN_ERR "%s: no pmd tables\n", __func__);
ret = -ENOMEM;
--
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: powerpc: Remove use of 4level-fixup.h for ppc32
From: David Gibson @ 2007-05-07 5:47 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev
In-Reply-To: <20070507053527.GB24464@localhost.localdomain>
On Mon, May 07, 2007 at 03:35:27PM +1000, David Gibson wrote:
> For 32-bit systems, powerpc still relies on the 4level-fixup.h hack,
> to pretend that the generic pagetable handling stuff is 3-levels
> rather than 4. This patch removes this, instead using the newer
> pgtable-nopmd.h to handle the elision of both the pud and pmd
> pagetable levels (ppc32 pagetables are actually 2 levels).
>
> This removes a little extraneous code, and makes it more easily
> compared to the 64-bit pagetable code.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Urg.. forgot to mention. This patch is dependent (textually, not
conceptually) on my earlier patch abolishing PTE_FMT.
--
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
* [PATCH] Add __init annotations to reserve_mem() and stabs_alloc()
From: Michael Ellerman @ 2007-05-07 5:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
reserve_mem() and stabs_alloc() are both called only from other __init
routines, so can be marked __init.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/prom_init.c | 2 +-
arch/powerpc/mm/stab.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Index: msi-new/arch/powerpc/kernel/prom_init.c
===================================================================
--- msi-new.orig/arch/powerpc/kernel/prom_init.c
+++ msi-new/arch/powerpc/kernel/prom_init.c
@@ -967,7 +967,7 @@ static unsigned long __init prom_next_ce
* If problems seem to show up, it would be a good start to track
* them down.
*/
-static void reserve_mem(u64 base, u64 size)
+static void __init reserve_mem(u64 base, u64 size)
{
u64 top = base + size;
unsigned long cnt = RELOC(mem_reserve_cnt);
Index: msi-new/arch/powerpc/mm/stab.c
===================================================================
--- msi-new.orig/arch/powerpc/mm/stab.c
+++ msi-new/arch/powerpc/mm/stab.c
@@ -227,7 +227,7 @@ void switch_stab(struct task_struct *tsk
* the first (bolted) segment, so that do_stab_bolted won't get a
* recursive segment miss on the segment table itself.
*/
-void stabs_alloc(void)
+void __init stabs_alloc(void)
{
int cpu;
^ permalink raw reply
* Re: virtex_devices.c
From: David H. Lynch Jr. @ 2007-05-07 6:38 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <528646bc0705061817h7a8fd767v73195e9d4572b8e1@mail.gmail.com>
Grant Likely wrote:
>
> Although this point is actually moot because platform_bus pretty much
> goes away when we move to arch/powerpc. We'll be using
> of_platform_devices instead (which map onto nodes in the device tree).
That I got and as I pound away at all of this I keep thinking my
time would be better spent figuring out device trees.
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: powerpc: Remove use of 4level-fixup.h for ppc32
From: Christoph Hellwig @ 2007-05-07 8:24 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev
In-Reply-To: <20070507053527.GB24464@localhost.localdomain>
On Mon, May 07, 2007 at 03:35:27PM +1000, David Gibson wrote:
> ===================================================================
> --- working-2.6.orig/include/asm-powerpc/page.h 2007-05-07 14:24:21.000000000 +1000
> +++ working-2.6/include/asm-powerpc/page.h 2007-05-07 15:30:04.000000000 +1000
> @@ -121,9 +121,11 @@ typedef struct { pte_t pte; } real_pte_t
> #endif
>
> /* PMD level */
> +#ifdef CONFIG_PPC64
> typedef struct { unsigned long pmd; } pmd_t;
> #define pmd_val(x) ((x).pmd)
> #define __pmd(x) ((pmd_t) { (x) })
> +#endif
>
> /* PUD level exusts only on 4k pages */
> #if defined(CONFIG_PPC64) && !defined(CONFIG_PPC_64K_PAGES)
> @@ -159,9 +161,11 @@ typedef unsigned long real_pte_t;
> #endif
>
>
> +#if defined (CONFIG_PPC64)
> typedef unsigned long pmd_t;
> #define pmd_val(x) (x)
> #define __pmd(x) (x)
> +#endif
This should be one bit CONFIG_PPC64 block with a nested !CONFIG_PPC_64K_PAGES
block inbetween.
>
> #if defined(CONFIG_PPC64) && !defined(CONFIG_PPC_64K_PAGES)
> typedef unsigned long pud_t;
also extending down here. Unfortunately the page.h you patch seems
to be different already from the one in current mainline so I don't
have the full picture at hand, but it would be nice to only have
a few ifdef blocks in the header.
Except for that little nitpick the patch looks good.
^ permalink raw reply
* Re: [PATCH v2] via-pmu: remove LED sleep notifier
From: Paul Mackerras @ 2007-05-07 8:47 UTC (permalink / raw)
To: Johannes Berg; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <1178116377.13233.63.camel@johannes.berg>
Johannes Berg writes:
> The generic LED code now makes sure that suspended devices don't blink,
> so we no longer need to do it ourselves. For the suspend to disk case,
> however, we need to make sure that we don't blink if the PMU sysdev
> was suspended before the LED device.
With this patch I get:
LD .tmp_vmlinux1
drivers/built-in.o:(.toc1+0x71d8): undefined reference to `pmu_sys_suspended'
with a 64-bit config that has CONFIG_PPC_PMAC=y and CONFIG_PM=n.
Paul.
^ permalink raw reply
* Re: [PATCH v2] via-pmu: remove LED sleep notifier
From: Johannes Berg @ 2007-05-07 8:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <17982.59298.848311.626151@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 510 bytes --]
On Mon, 2007-05-07 at 18:47 +1000, Paul Mackerras wrote:
> With this patch I get:
>
> LD .tmp_vmlinux1
> drivers/built-in.o:(.toc1+0x71d8): undefined reference to `pmu_sys_suspended'
>
> with a 64-bit config that has CONFIG_PPC_PMAC=y and CONFIG_PM=n.
Ouch, sorry about that. I suppose I should make it
#ifdef CONFIG_PM
extern int pmu_sys_suspended;
#else
#define pmu_sys_suspended 0
#endif
in the header file. Will look at it again and send an updated patch
later.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH 1/8] powerpc: Fix the MODALIAS generation in modpost for of devices
From: Johannes Berg @ 2007-05-07 9:09 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: PPC dev ML, Paul Mackerras
In-Reply-To: <11784659351487-git-send-email-tnt@246tNt.com>
[-- Attachment #1: Type: text/plain, Size: 487 bytes --]
On Sun, 2007-05-06 at 17:38 +0200, Sylvain Munaut wrote:
> Since the devices may have multiple (or none) compatible properties,
> the uevent generated internally by the kernel may have multiple
> "C..." entries. So the MODALIAS stored in the module must have
> wilcard before and after the compatible entry.
> Also, if the 'compatible' field is not used for matching, there
> will be no 'C' and that must handled as well.
Ack, I really need this patch for aoa now.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH v2 4/7] Add support for 750CL Holly board
From: Josh Boyer @ 2007-05-07 10:32 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17982.43385.49199.628627@cargo.ozlabs.ibm.com>
On Mon, 2007-05-07 at 14:22 +1000, Paul Mackerras wrote:
> Josh Boyer writes:
>
> > +config HOLLY
>
> That's a bit too non-specific, I think; please make it PPC_HOLLY.
Ok.
josh
^ permalink raw reply
* Re: [PATCH 5/6] Support for the Ebony 440GP reference board in arch/powerpc
From: Josh Boyer @ 2007-05-07 10:41 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070504055733.8FB7EDDFFD@ozlabs.org>
On Fri, 2007-05-04 at 15:57 +1000, David Gibson wrote:
> +
> +config EBONY
> + bool "Ebony"
> + depends on 44x
> + default y
> + select 440GP
> + help
> + This option enables support for the IBM PPC440GP evaluation
> board.
Given Paul's comment about config HOLLY being too generic, should this
be PPC_EBONY?
josh
^ permalink raw reply
* kernel expection generated with 2.6.21-mm1 kernel boot up
From: Kamalesh Babulal @ 2007-05-07 11:00 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1857 bytes --]
Hi,
I tried compiling and booting up with 2.6.21-mm1 kernel
on the following machine
Architecture : PPC64
CPU Type : POWER5 (gr)
Machine Type : CHRP IBM,9117-570
Base OS : Fedora Core 5
the kernel enters the xmon state after an exception as following
Red Hat nash version 5.0.32 starting
Mounting proc filesystem
Mounting sysfs filesystem
Creating /dev
Creating initial device nodes
Setting up hotplug.
Creating block device nodes.
Loading jbd.ko module
Unable to handle kernel paging request for data at address 0x0083a680
Faulting instruction address: 0xc0000000000cc5e4
cpu 0x1: Vector: 300 (Data Access) at [c000000005373320]
pc: c0000000000cc5e4: .slab_free+0x6c/0x424
lr: c00000000002fa70: .pgtable_free_tlb+0xd0/0x140
sp: c0000000053735a0
msr: 8000000000009032
dar: 83a680
dsisr: 40000000
current = 0xc000000009408790
paca = 0xc0000000004b2700
pid = 295, comm = init
enter ? for help
[c000000005373650] c00000000002fa70 .pgtable_free_tlb+0xd0/0x140
[c0000000053736f0] c0000000000b0f40 .free_pgd_range+0x23c/0x3c4
[c0000000053737f0] c0000000000b13cc .free_pgtables+0x100/0x134
[c0000000053738a0] c0000000000b29f0 .exit_mmap+0xcc/0x15c
[c000000005373950] c000000000057808 .mmput+0x78/0x170
[c0000000053739f0] c0000000000d9c38 .flush_old_exec+0x750/0xa74
[c000000005373ad0] c000000000012ef0 .load_elf_binary+0x5f8/0x1a18
[c000000005373c30] c0000000000d8a2c .search_binary_handler+0x124/0x304
[c000000005373ce0] c00000000011728c .compat_do_execve+0x1d0/0x328
[c000000005373d90] c000000000016428 .compat_sys_execve+0x74/0xf8
[c000000005373e30] c00000000000872c syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 00000000100d9358
SP (ff8b79e0) is in userspace
1:mon>
Attached and console log and config file.
Thanks,
Kamalesh Babulal.
[-- Attachment #2: boot_message --]
[-- Type: text/plain, Size: 5661 bytes --]
Linux version 2.6.21-mm1-autokern1 (root@gekko-lp2.ltc.austin.ibm.com) (gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)) #1 SMP Mon May 7 00:13:58 CDT 2007
[boot]0012 Setup Arch
Node 0 active with no memory
EEH: PCI Enhanced I/O Error Handling Enabled
PPC64 nvram contains 7168 bytes
Zone PFN ranges:
DMA 0 -> 1048576
Normal 1048576 -> 1048576
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
1: 0 -> 1048576
Could not find start_pfn for node 0
Node 0 active with no memory
Node 0 active with no memory
Node 0 active with no memory
Node 0 active with no memory
Node 0 active with no memory
Node 0 active with no memory
Node 0 active with no memory
Node 0 active with no memory
Node 0 active with no memory
Node 0 active with no memory
Node 0 active with no memory
Node 0 active with no memory
[boot]0015 Setup Done
Built 2 zonelists, mobility grouping on. Total pages: 1034240
Kernel command line: ro console=hvc0 autobench_args: root=/dev/sda7 ABAT:1178515939
[boot]0020 XICS Init
[boot]0021 XICS Done
PID hash table entries: 4096 (order: 12, 32768 bytes)
Console: colour dummy device 80x25
console handover: boot [udbg0] -> real [hvc0]
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
freeing bootmem node 1
Memory: 4114076k/4194304k available (4728k kernel code, 80228k reserved, 892k data, 577k bss, 260k init)
SLUB: Genslabs=18, HWalign=128, Order=0-4, MinObjects=16, Processors=4, Nodes=16
Security Framework v1.0.0 initialized
SELinux: Initializing.
selinux_register_security: Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 256
Processor 1 found.
Processor 2 found.
Processor 3 found.
Brought up 4 CPUs
migration_cost=4,3
NET: Registered protocol family 16
IOMMU table initialized, virtual merging enabled
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
TCP established hash table entries: 524288 (order: 11, 12582912 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 524288 bind 65536)
TCP reno registered
checking if image is initramfs... it is
Freeing initrd memory: 1300k freed
scan-log-dump not implemented on this system
audit: initializing netlink socket (disabled)
audit(1178516185.644:1): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
JFS: nTxBlock = 8192, nTxLock = 65536
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
rpaphp: Slot [0000:00:02.4](PCI location=U7879.001.DQD0T7T-P1-C5) registered
Generic RTC Driver v1.07
[drm] Initialized drm 1.1.0 20060810
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ide-floppy driver 0.99.newide
usbmon: debugfs is not available
mice: PS/2 mouse device common for all mice
async_tx: api initialized (sync-only)
xor: measuring software checksumming speed
8regs : 6091.000 MB/sec
8regs_prefetch: 5169.000 MB/sec
32regs : 6744.000 MB/sec
32regs_prefetch: 4828.000 MB/sec
xor: using function: 32regs (6744.000 MB/sec)
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
Freeing unused kernel memory: 260k freed
Red Hat nash version 5.0.32 starting
Mounting proc filesystem
Mounting sysfs filesystem
Creating /dev
Creating initial device nodes
Setting up hotplug.
Creating block device nodes.
Loading jbd.ko module
Unable to handle kernel paging request for data at address 0x0083a680
Faulting instruction address: 0xc0000000000cc5e4
cpu 0x1: Vector: 300 (Data Access) at [c000000005373320]
pc: c0000000000cc5e4: .slab_free+0x6c/0x424
lr: c00000000002fa70: .pgtable_free_tlb+0xd0/0x140
sp: c0000000053735a0
msr: 8000000000009032
dar: 83a680
dsisr: 40000000
current = 0xc000000009408790
paca = 0xc0000000004b2700
pid = 295, comm = init
enter ? for help
[c000000005373650] c00000000002fa70 .pgtable_free_tlb+0xd0/0x140
[c0000000053736f0] c0000000000b0f40 .free_pgd_range+0x23c/0x3c4
[c0000000053737f0] c0000000000b13cc .free_pgtables+0x100/0x134
[c0000000053738a0] c0000000000b29f0 .exit_mmap+0xcc/0x15c
[c000000005373950] c000000000057808 .mmput+0x78/0x170
[c0000000053739f0] c0000000000d9c38 .flush_old_exec+0x750/0xa74
[c000000005373ad0] c000000000012ef0 .load_elf_binary+0x5f8/0x1a18
[c000000005373c30] c0000000000d8a2c .search_binary_handler+0x124/0x304
[c000000005373ce0] c00000000011728c .compat_do_execve+0x1d0/0x328
[c000000005373d90] c000000000016428 .compat_sys_execve+0x74/0xf8
[c000000005373e30] c00000000000872c syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 00000000100d9358
SP (ff8b79e0) is in userspace
1:mon>
[-- Attachment #3: dotconfig.bz2 --]
[-- Type: application/x-bzip, Size: 12371 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox