* Re: [PATCH] sysdev,mv64x60: early console fix
From: Dale Farnsworth @ 2008-04-21 21:32 UTC (permalink / raw)
To: Remi Machet; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1208811777.5789.86.camel@pcds-ts102.slac.stanford.edu>
On Mon, Apr 21, 2008 at 02:02:56PM -0700, Remi Machet wrote:
> The MPSC driver and prpmc2800.dts have been modified to
> use property 'cell-index' as the serial port number but
> the early serial console driver for the mv64x60 has not
> been modified to use this new property.
>
> Signed-off-by: Remi Machet (rmachet@slac.stanford.edu)
Acked-by: Dale Farnsworth <dale@farnsworth.org>
^ permalink raw reply
* Re: [PATCH 4/5] [POWERPC] QE: implement support for the GPIO LIB API
From: Anton Vorontsov @ 2008-04-21 21:33 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev
In-Reply-To: <200804211301.13026.david-b@pacbell.net>
On Mon, Apr 21, 2008 at 01:01:12PM -0700, David Brownell wrote:
> On Monday 21 April 2008, Anton Vorontsov wrote:
> > From: J. Random Hacker
> > Subject: [POWERPC] cleanup board initialization code
> >
> > This patch removes vast amount of machine_arch_initcall()s that were
> > used to solely initialize some hardware, like this:
> >
> > qe_add_gpio_chips();
> > fsl_gtm_init();
> > fsl_spi_init();
> > ...
> >
> > So, instead of calling this stuff from the board files, we implement
> > own arch_initcalls for these functions.
>
> The way other platforms do this is to hav SOC-specific
> init code, and have board-specific initcalls call the
> relevant SOC-specific setup.
I don't know about other platforms other than PowerPC and some ARM,
of course. For example, PXA boards don't call any SOC specific code.
Instead, looking into reworked PXA code, I can see that there are
separate arch_initcalls() for the pxa25x, pxa27x, and pxa3xx SOCs.
The same for s3cxxxx. So, at least not every platform out there doing
this.
Yes, I can see AVR32. But there are only two boards, and when you'll
have more, probably later you'd want to eliminate some repetitive
code, if possible.
Here, with OF, it's quite simple because we have methods of "probing" SOC
devices instead of placing init code into board files (think arch/ppc/).
> Among other things that facilitates kernels that handle
> multiple SOCs (if they're closely-enough related). That
> may not be used by many distros (handhelds.org being at
> least a partial exception), but it certainly helps cut
> the number of configurations that need build-testing.
Is this about QE_GPIO being user-selectable? Yes, verbose Konfig option
have its own drawbacks. Though, I don't actually have any objections
for making it silent.
And well, I'm not objecting for placing qe gpio code under arch/, too.
I'll resend this patch once again reverting its placement to arch/.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] [POWERPC] ppc32: Fix errata for 603 CPUs
From: Kumar Gala @ 2008-04-21 22:04 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1208812957.9640.47.camel@pasglop>
On Apr 21, 2008, at 4:22 PM, Benjamin Herrenschmidt wrote:
>
>>
>> _GLOBAL(__setup_cpu_603)
>> - b setup_common_caches
>> + mflr r4
>> +BEGIN_FTR_SECTION
>> + bl __init_fpu_registers
>> +END_FTR_SECTION_IFCLR(CPU_FTR_FPU_UNAVAILABLE)
>> + bl __init_fpu_registers
>> + bl setup_common_caches
>> + mtlr r4
>> + blr
>> _GLOBAL(__setup_cpu_604)
>> mflr r4
>> bl setup_common_cache
>
> Has the feature fixup been perform yet when __setup_* is called ?
Yes. We call do_feature_fixups() in early_init and call
call_setup_cpu() after than on 6xx (in head_32.S).
- k
^ permalink raw reply
* Re: [PATCH 5/5] [POWERPC] 83xx: new board support: MPC8360E-RDK
From: Anton Vorontsov @ 2008-04-21 22:04 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40804211405mbe3f6beof07a3287d7157fbe@mail.gmail.com>
On Mon, Apr 21, 2008 at 03:05:25PM -0600, Grant Likely wrote:
> On Fri, Apr 18, 2008 at 1:10 PM, Anton Vorontsov
> <avorontsov@ru.mvista.com> wrote:
> > This is patch adds board file, device tree, and defconfig for the new
> > board, made by Freescale Semiconductor Inc. and Logic Product Development.
>
> > arch/powerpc/platforms/83xx/mpc836x_rdk.c | 106 +++
>
> I don't see anything exotic in here. This can be merged with one of
> the other non-exotic mpc83xx board files. The dts parsing takes care
> of the differences.
Please name the board file in which you think I'll easily merge this
indeed non-exotic board.
The only QE boards there are: mpc832x_{rdb,mds} and mpc836x_mds. All of
them have board-specific fixups either in the machine_device_initcall()s
or setup_arch()s.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] [POWERPC] ppc32: Fix errata for 603 CPUs
From: Benjamin Herrenschmidt @ 2008-04-21 22:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <059AA568-4729-4060-A876-C8460E0A7794@kernel.crashing.org>
On Mon, 2008-04-21 at 17:04 -0500, Kumar Gala wrote:
> On Apr 21, 2008, at 4:22 PM, Benjamin Herrenschmidt wrote:
> >
> >>
> >> _GLOBAL(__setup_cpu_603)
> >> - b setup_common_caches
> >> + mflr r4
> >> +BEGIN_FTR_SECTION
> >> + bl __init_fpu_registers
> >> +END_FTR_SECTION_IFCLR(CPU_FTR_FPU_UNAVAILABLE)
> >> + bl __init_fpu_registers
> >> + bl setup_common_caches
> >> + mtlr r4
> >> + blr
> >> _GLOBAL(__setup_cpu_604)
> >> mflr r4
> >> bl setup_common_cache
> >
> > Has the feature fixup been perform yet when __setup_* is called ?
>
> Yes. We call do_feature_fixups() in early_init and call
> call_setup_cpu() after than on 6xx (in head_32.S).
Hrm. I think that may be the other way around on 64 bits... damn, I need
to consolidate these.
I'd rather have the init code explicitely test for the features.
Ben.
^ permalink raw reply
* Re: [PATCH 4/5] [POWERPC] QE: implement support for the GPIO LIB API
From: David Brownell @ 2008-04-21 22:19 UTC (permalink / raw)
To: cbouatmailru; +Cc: linuxppc-dev
In-Reply-To: <20080421213349.GA3833@zarina>
On Monday 21 April 2008, Anton Vorontsov wrote:
> On Mon, Apr 21, 2008 at 01:01:12PM -0700, David Brownell wrote:
> > The way other platforms do this is to hav SOC-specific
> > init code, and have board-specific initcalls call the
> > relevant SOC-specific setup.
>
> I don't know about other platforms other than PowerPC and some ARM,
> of course. For example, PXA boards don't call any SOC specific code.
> Instead, looking into reworked PXA code, I can see that there are
> separate arch_initcalls() for the pxa25x, pxa27x, and pxa3xx SOCs.
Exactly: SOC-specific initcalls.
> > Among other things that facilitates kernels that handle
> > multiple SOCs (if they're closely-enough related). That
> > may not be used by many distros (handhelds.org being at
> > least a partial exception), but it certainly helps cut
> > the number of configurations that need build-testing.
>
> Is this about QE_GPIO being user-selectable?
No. It's about "kernels that handle multiple SOCs". Like
for example pxa{25,27,3x}x ... or omap{16xx,17xx,5912}.
Consider several ways to support a family of SOCs.
- One way supports only one board at a time. Testing
builds after arch level changes means rebuilding kernels
for each board ... quite possibly several dozen.
- Another supports several boards, but only if they use
the same SOC. Testing builds here takes fewer kernels;
one per SOC; better, but still routinely shortchanged.
- Yet another way supports any number of boards, using
a variety of mostly-compatible SOCs. This allows test
builds that support entire SOC families (e.g. OMAP1,
or OMAP2/OMAP3, or PXA XScale, etc).
Test builds are a quality control thing. If they're done
regularly, it's less likely you'll push code upstream
that can't build in some configuration.
> And well, I'm not objecting for placing qe gpio code under arch/, too.
> I'll resend this patch once again reverting its placement to arch/.
OK, good. Then I don't really have to be involved with that.
- Dave
^ permalink raw reply
* Re: [PATCH] [POWERPC] ppc32: Fix errata for 603 CPUs
From: Kumar Gala @ 2008-04-21 22:31 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1208815944.9640.49.camel@pasglop>
On Apr 21, 2008, at 5:12 PM, Benjamin Herrenschmidt wrote:
>
> On Mon, 2008-04-21 at 17:04 -0500, Kumar Gala wrote:
>> On Apr 21, 2008, at 4:22 PM, Benjamin Herrenschmidt wrote:
>>>
>>>>
>>>> _GLOBAL(__setup_cpu_603)
>>>> - b setup_common_caches
>>>> + mflr r4
>>>> +BEGIN_FTR_SECTION
>>>> + bl __init_fpu_registers
>>>> +END_FTR_SECTION_IFCLR(CPU_FTR_FPU_UNAVAILABLE)
>>>> + bl __init_fpu_registers
>>>> + bl setup_common_caches
>>>> + mtlr r4
>>>> + blr
>>>> _GLOBAL(__setup_cpu_604)
>>>> mflr r4
>>>> bl setup_common_cache
>>>
>>> Has the feature fixup been perform yet when __setup_* is called ?
>>
>> Yes. We call do_feature_fixups() in early_init and call
>> call_setup_cpu() after than on 6xx (in head_32.S).
>
> Hrm. I think that may be the other way around on 64 bits... damn, I
> need
> to consolidate these.
>
> I'd rather have the init code explicitely test for the features.
Ok, but we'd also need to fix setup_750_7400_hid0 and
setup_745x_specifics to test.
There's a bit more cleanup that needs to be done here. I'm not going
to worry about it for this patch since it covers handling a chip
errata and isn't any more "broken" than other bits of code in this file.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] ppc32: Fix errata for 603 CPUs
From: Benjamin Herrenschmidt @ 2008-04-21 22:39 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <B9800143-8E81-44D2-A922-28E992203717@kernel.crashing.org>
On Mon, 2008-04-21 at 17:31 -0500, Kumar Gala wrote:
> Ok, but we'd also need to fix setup_750_7400_hid0 and
> setup_745x_specifics to test.
>
> There's a bit more cleanup that needs to be done here. I'm not
> going
> to worry about it for this patch since it covers handling a chip
> errata and isn't any more "broken" than other bits of code in this fi
True.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/5] [POWERPC] sysdev: implement FSL GTM support
From: Grant Likely @ 2008-04-21 23:27 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080421183914.GA6213@ld0162-tx32.am.freescale.net>
On Mon, Apr 21, 2008 at 12:39 PM, Scott Wood <scottwood@freescale.com> wrote:
> On Mon, Apr 21, 2008 at 08:03:31AM -0600, Grant Likely wrote:
>
> > > + r) Freescale General-purpose Timers Module
> > > +
> > > + Required properties:
> > > + - compatible : should be "fsl,gtm" ("fsl,qe-gtm" in addition for QE
> > > + GTMs or "fsl,cpm2-gtm" for CPM2 GTMs).
> >
> > I don't think this is specific enough. It is a very real possibility
> > for Freescale to produce another part with a "general purpose timers
> > module" that isn't register level compatible (and fsl,i2c is an
> > example of what not to do).
>
> If that happens, we'll make up "fsl,gtm2". :-)
:-P
> > The compatible string should include the
> > exact chip version. Newer parts can also claim compatibility with
> > older ones.
> >
> > Defining a 'generic' compatible value is also known as "making stuff up". :-)
>
> Nothing wrong with making stuff up as long as we do it sanely.
>
> How about something like fsl,gtm-1.0?
The problem I have with that is that there is always the potential
that some rogue hardware will appear that messes up your sane scheme.
Plus there is pretty much no downside to just choosing a device that
the more recent parts reference.
Example: consider 3 chips using the same i2c core; say MPC8313,
MPC5200 & MPC8548. compatible lines could look like this:
compatible = "fsl,mpc8313-i2c","fsl-i2c";
compatible = "fsl,mpc5200-i2c","fsl-i2c";
compatible = "fsl,mpc8548-i2c","fsl-i2c";
Or; (assuming 8313 is where it first appeared) it could look like this:
compatible = "fsl,mpc8313-i2c";
compatible = "fsl,mpc5200-i2c","fsl,mpc8313-i2c";
compatible = "fsl,mpc8548-i2c","fsl,mpc8313-i2c";
To the driver it's just a different string ("fsl,mpc8313-i2c" instead
of "fsl-i2c"), but with the second you *always* know what an
mpc8131-i2c core is; the mpc8131 user guide tells you. Even if you
are strict about your sane naming scheme, you cannot look into the
future and someone will do something wonky on you.
The other benefit is it avoids the temptation to define generic
compatible values for things which will *never* be generic parts.
Case in point; when I did the original mpc5200 bindings I did things
like "mpc52xx-<blah>". However, there probably never will be another
mpc52xx part; and if there is it will look vastly different from the
current 5200. So I wasted all kinds of effort trying to be generic
about stuff when it is almost certainly wasted effort and additional
complexity to the naming conventions.
> > > +static inline void gtm_ack_timer16(struct gtm_timer *tmr, u16 events)
> > > +{
> > > + out_be16(tmr->gtevr, events);
> > > +}
> >
> > Drop 'inline' and expect gcc to do the right thing.
>
> Not in a header...
Oops, yeah; not sure what I was smoking.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] [POWERPC] AMCC Kilauea (405EX): Disable EMAC loopback mode
From: Benjamin Herrenschmidt @ 2008-04-21 23:46 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1203715656.6976.7.camel@pasglop>
On Sat, 2008-02-23 at 08:27 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2008-02-22 at 09:32 +0100, Stefan Roese wrote:
> > 405EX(r) has SDR0_MFR[E0CS/E1CS] set after reset. This selects
> > the internal loopback mode. Clear these bits so that both EMACs
> > don't use loopback mode as default.
> >
> > Signed-off-by: Stefan Roese <sr@denx.de>
> > ---
> > I'm not sure if this should be done here in the board platform code,
> > or in the newemac driver or perhaps in some code common for 405EX.
> >
> > Any thoughts on this welcome.
>
> This should be done in EMAC since we also need to force internal
> loopback & clocking when probing the PHY or we might not probe
> it properly (and fail reset) if there is no link.
Is that patch still needed if I apply Valentine patches ? I'm fixing
them up so they don't break DCR MMIO anymore.
Cheers,
Ben.
^ permalink raw reply
* Re: Patches added to powerpc.git master and powerpc-next branches
From: Paul Mackerras @ 2008-04-22 0:15 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <C69E510D-5838-4BE6-AB57-56FCB0592414@kernel.crashing.org>
Kumar Gala writes:
> > Once again I want to go through it carefully and understand how it all
> > works, and in particular understand things like the way it ensures
> > that the base address for the kmap region is aligned to a 4M boundary
> > so all the kmap ptes are in a single page (assuming it does :).
>
> I'm not clear on why this is needed. I can see value in having the
> PGD entry in place but the pte PAs would be changing all the time so I
> don't see what benefit there is in keeping them in one page.
Have a look at map_new_virtual in mm/highmem.c. In particular:
set_pte_at(&init_mm, vaddr,
&(pkmap_page_table[last_pkmap_nr]), mk_pte(page, kmap_prot));
assumes that the ptes that kmap uses are in a contiguous array whose
base is pkmap_page_table.
> For normal kmap ptes we cover things in one PGD via:
>
> #define PKMAP_BASE ((FIXADDR_BOOT_START - PAGE_SIZE*(LAST_PKMAP +
> 1)) & PMD_MASK)
OK, that probably does the trick ... <checks> ... yes it does.
We seem to have a distinction without a difference between
FIXADDR_START and FIXADDR_BOOT_START, and similarly between
__FIXADDR_SIZE and __FIXADDR_BOOT_SIZE. Is there any actual
difference and if not why do we have two names for the same thing?
Also, we seem to have an unnecessary distinction (and unnecessary
casting) between __FIXADDR_TOP and FIXADDR_TOP.
Regards,
Paul.
^ permalink raw reply
* [PATCH 1/6] ibm_newemac: Fix problem with jumbo frame support and EMAC V4.patch
From: Benjamin Herrenschmidt @ 2008-04-22 0:46 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-dev
From: Stefan Roese <sr@denx.de>
This fixes the jumbo frame support on EMAC V4 systems. Now the correct
bit is set depending on the EMAC version configured.
Tested on Kilauea (405EX) and Canyonlands (460EX).
Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/net/ibm_newemac/core.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 0789802..486901f 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -524,7 +524,10 @@ static int emac_configure(struct emac_instance *dev)
rx_size = dev->rx_fifo_size_gige;
if (dev->ndev->mtu > ETH_DATA_LEN) {
- mr1 |= EMAC_MR1_JPSM;
+ if (emac_has_feature(dev, EMAC_FTR_EMAC4))
+ mr1 |= EMAC4_MR1_JPSM;
+ else
+ mr1 |= EMAC_MR1_JPSM;
dev->stop_timeout = STOP_TIMEOUT_1000_JUMBO;
} else
dev->stop_timeout = STOP_TIMEOUT_1000;
^ permalink raw reply related
* [PATCH 2/6] ibm_newemac: Add support for 460EX/GT-type MAL rx-channel handling
From: Benjamin Herrenschmidt @ 2008-04-22 0:46 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-dev
From: Stefan Roese <sr@denx.de>
On some 4xx PPC's (e.g. 460EX/GT), the rx channel number is a multiple
of 8 (e.g. 8 for EMAC1, 16 for EMAC2), but enabling in MAL_RXCASR needs
the divided by 8 value for the bitmask.
Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/net/ibm_newemac/mal.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/net/ibm_newemac/mal.c b/drivers/net/ibm_newemac/mal.c
index 6869f08..fb9c9eb 100644
--- a/drivers/net/ibm_newemac/mal.c
+++ b/drivers/net/ibm_newemac/mal.c
@@ -136,6 +136,14 @@ void mal_enable_rx_channel(struct mal_instance *mal, int channel)
{
unsigned long flags;
+ /*
+ * On some 4xx PPC's (e.g. 460EX/GT), the rx channel is a multiple
+ * of 8, but enabling in MAL_RXCASR needs the divided by 8 value
+ * for the bitmask
+ */
+ if (!(channel % 8))
+ channel >>= 3;
+
spin_lock_irqsave(&mal->lock, flags);
MAL_DBG(mal, "enable_rx(%d)" NL, channel);
@@ -148,6 +156,14 @@ void mal_enable_rx_channel(struct mal_instance *mal, int channel)
void mal_disable_rx_channel(struct mal_instance *mal, int channel)
{
+ /*
+ * On some 4xx PPC's (e.g. 460EX/GT), the rx channel is a multiple
+ * of 8, but enabling in MAL_RXCASR needs the divided by 8 value
+ * for the bitmask
+ */
+ if (!(channel % 8))
+ channel >>= 3;
+
set_mal_dcrn(mal, MAL_RXCARR, MAL_CHAN_MASK(channel));
MAL_DBG(mal, "disable_rx(%d)" NL, channel);
^ permalink raw reply related
* [PATCH 3/6] ibm_newemac: Fix section mismatch warnings
From: Benjamin Herrenschmidt @ 2008-04-22 0:46 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-dev
From: Josh Boyer <jwboyer@gmail.com>
This patch fixes several section mismatch warnings in the
ibm_newemac driver similar to:
WARNING: vmlinux.o(.devinit.text+0x3a04): Section mismatch in reference from the function emac_probe() to the function .devexit.text:tah_detach()
The function __devinit emac_probe() references
a function __devexit tah_detach().
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/net/ibm_newemac/core.c | 2 +-
drivers/net/ibm_newemac/mal.c | 4 ++--
drivers/net/ibm_newemac/rgmii.c | 2 +-
drivers/net/ibm_newemac/tah.c | 2 +-
drivers/net/ibm_newemac/zmii.c | 2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
--- linux-work.orig/drivers/net/ibm_newemac/core.c 2008-04-22 10:02:32.000000000 +1000
+++ linux-work/drivers/net/ibm_newemac/core.c 2008-04-22 10:02:53.000000000 +1000
@@ -2240,7 +2240,7 @@ static int __devinit emac_of_bus_notify(
return 0;
}
-static struct notifier_block emac_of_bus_notifier = {
+static struct notifier_block emac_of_bus_notifier __devinitdata = {
.notifier_call = emac_of_bus_notify
};
Index: linux-work/drivers/net/ibm_newemac/mal.c
===================================================================
--- linux-work.orig/drivers/net/ibm_newemac/mal.c 2008-04-22 10:02:42.000000000 +1000
+++ linux-work/drivers/net/ibm_newemac/mal.c 2008-04-22 10:02:53.000000000 +1000
@@ -61,8 +61,8 @@ int __devinit mal_register_commac(struct
return 0;
}
-void __devexit mal_unregister_commac(struct mal_instance *mal,
- struct mal_commac *commac)
+void mal_unregister_commac(struct mal_instance *mal,
+ struct mal_commac *commac)
{
unsigned long flags;
Index: linux-work/drivers/net/ibm_newemac/rgmii.c
===================================================================
--- linux-work.orig/drivers/net/ibm_newemac/rgmii.c 2008-03-19 13:52:35.000000000 +1100
+++ linux-work/drivers/net/ibm_newemac/rgmii.c 2008-04-22 10:02:53.000000000 +1000
@@ -179,7 +179,7 @@ void rgmii_put_mdio(struct of_device *of
mutex_unlock(&dev->lock);
}
-void __devexit rgmii_detach(struct of_device *ofdev, int input)
+void rgmii_detach(struct of_device *ofdev, int input)
{
struct rgmii_instance *dev = dev_get_drvdata(&ofdev->dev);
struct rgmii_regs __iomem *p = dev->base;
Index: linux-work/drivers/net/ibm_newemac/tah.c
===================================================================
--- linux-work.orig/drivers/net/ibm_newemac/tah.c 2008-03-26 10:39:25.000000000 +1100
+++ linux-work/drivers/net/ibm_newemac/tah.c 2008-04-22 10:02:53.000000000 +1000
@@ -35,7 +35,7 @@ int __devinit tah_attach(struct of_devic
return 0;
}
-void __devexit tah_detach(struct of_device *ofdev, int channel)
+void tah_detach(struct of_device *ofdev, int channel)
{
struct tah_instance *dev = dev_get_drvdata(&ofdev->dev);
Index: linux-work/drivers/net/ibm_newemac/zmii.c
===================================================================
--- linux-work.orig/drivers/net/ibm_newemac/zmii.c 2008-03-03 11:58:49.000000000 +1100
+++ linux-work/drivers/net/ibm_newemac/zmii.c 2008-04-22 10:02:53.000000000 +1000
@@ -189,7 +189,7 @@ void zmii_set_speed(struct of_device *of
mutex_unlock(&dev->lock);
}
-void __devexit zmii_detach(struct of_device *ofdev, int input)
+void zmii_detach(struct of_device *ofdev, int input)
{
struct zmii_instance *dev = dev_get_drvdata(&ofdev->dev);
^ permalink raw reply
* [PATCH 4/6] ibm_newemac Use status property for unused/unwired EMACs
From: Benjamin Herrenschmidt @ 2008-04-22 0:46 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-dev
From: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Convert ibm_newemac to use the of_device_is_available function when checking
for unused/unwired EMACs. We leave the current check for an "unused" property
to maintain backwards compatibility for older device trees. Newer device
trees should simply use the standard "status" property in the EMAC node.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/net/ibm_newemac/core.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- linux-work.orig/drivers/net/ibm_newemac/core.c 2008-04-22 10:42:42.000000000 +1000
+++ linux-work/drivers/net/ibm_newemac/core.c 2008-04-22 10:43:01.000000000 +1000
@@ -2562,8 +2562,11 @@ static int __devinit emac_probe(struct o
struct device_node **blist = NULL;
int err, i;
- /* Skip unused/unwired EMACS */
- if (of_get_property(np, "unused", NULL))
+ /* Skip unused/unwired EMACS. We leave the check for an unused
+ * property here for now, but new flat device trees should set a
+ * status property to "disabled" instead.
+ */
+ if (of_get_property(np, "unused", NULL) || !of_device_is_available(np))
return -ENODEV;
/* Find ourselves in the bootlist if we are there */
^ permalink raw reply
* [PATCH 5/6] ibm_newemac: PowerPC 440GX EMAC PHY clock workaround
From: Benjamin Herrenschmidt @ 2008-04-22 0:46 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-dev
From: Valentine Barshak <vbarshak@ru.mvista.com>
The PowerPC 440GX Taishan board fails to reset EMAC3 (reset timeout error)
if there's no link. Because of that it fails to find PHY chip. The older ibm_emac
driver had a workaround for that: the EMAC_CLK_INTERNAL/EMAC_CLK_EXTERNAL macros,
which toggle the Ethernet Clock Select bit in the SDR0_MFR register. This patch
does the same for "ibm,emac-440gx" compatible chips. The workaround forces
clock on -all- EMACs, so we select clock under global emac_phy_map_lock.
BenH: Made that #ifdef CONFIG_PPC_DCR_NATIVE for now as dcri_* stuff doesn't
exist for MMIO type DCRs like Cell. Some future rework & improvements of the
DCR infrastructure will make that cleaner but for now, this makes it work.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/net/ibm_newemac/core.c | 18 +++++++++++++++++-
drivers/net/ibm_newemac/core.h | 8 ++++++--
2 files changed, 23 insertions(+), 3 deletions(-)
--- linux-work.orig/drivers/net/ibm_newemac/core.c 2008-04-22 10:11:59.000000000 +1000
+++ linux-work/drivers/net/ibm_newemac/core.c 2008-04-22 10:31:18.000000000 +1000
@@ -43,6 +43,8 @@
#include <asm/io.h>
#include <asm/dma.h>
#include <asm/uaccess.h>
+#include <asm/dcr.h>
+#include <asm/dcr-regs.h>
#include "core.h"
@@ -2333,6 +2335,11 @@ static int __devinit emac_init_phy(struc
dev->phy.mdio_read = emac_mdio_read;
dev->phy.mdio_write = emac_mdio_write;
+ /* Enable internal clock source */
+#ifdef CONFIG_PPC_DCR_NATIVE
+ if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX))
+ dcri_clrset(SDR0, SDR0_MFR, 0, SDR0_MFR_ECS);
+#endif
/* Configure EMAC with defaults so we can at least use MDIO
* This is needed mostly for 440GX
*/
@@ -2365,6 +2372,12 @@ static int __devinit emac_init_phy(struc
if (!emac_mii_phy_probe(&dev->phy, i))
break;
}
+
+ /* Enable external clock source */
+#ifdef CONFIG_PPC_DCR_NATIVE
+ if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX))
+ dcri_clrset(SDR0, SDR0_MFR, SDR0_MFR_ECS, 0);
+#endif
mutex_unlock(&emac_phy_map_lock);
if (i == 0x20) {
printk(KERN_WARNING "%s: can't find PHY!\n", np->full_name);
@@ -2490,8 +2503,11 @@ static int __devinit emac_init_config(st
}
/* Check EMAC version */
- if (of_device_is_compatible(np, "ibm,emac4"))
+ if (of_device_is_compatible(np, "ibm,emac4")) {
dev->features |= EMAC_FTR_EMAC4;
+ if (of_device_is_compatible(np, "ibm,emac-440gx"))
+ dev->features |= EMAC_FTR_440GX_PHY_CLK_FIX;
+ }
/* Fixup some feature bits based on the device tree */
if (of_get_property(np, "has-inverted-stacr-oc", NULL))
Index: linux-work/drivers/net/ibm_newemac/core.h
===================================================================
--- linux-work.orig/drivers/net/ibm_newemac/core.h 2008-04-22 10:06:31.000000000 +1000
+++ linux-work/drivers/net/ibm_newemac/core.h 2008-04-22 10:30:03.000000000 +1000
@@ -301,6 +301,10 @@ struct emac_instance {
* Set if we have new type STACR with STAOPC
*/
#define EMAC_FTR_HAS_NEW_STACR 0x00000040
+/*
+ * Set if we need phy clock workaround for 440gx
+ */
+#define EMAC_FTR_440GX_PHY_CLK_FIX 0x00000080
/* Right now, we don't quite handle the always/possible masks on the
@@ -312,8 +316,8 @@ enum {
EMAC_FTRS_POSSIBLE =
#ifdef CONFIG_IBM_NEW_EMAC_EMAC4
- EMAC_FTR_EMAC4 | EMAC_FTR_HAS_NEW_STACR |
- EMAC_FTR_STACR_OC_INVERT |
+ EMAC_FTR_EMAC4 | EMAC_FTR_HAS_NEW_STACR |
+ EMAC_FTR_STACR_OC_INVERT | EMAC_FTR_440GX_PHY_CLK_FIX |
#endif
#ifdef CONFIG_IBM_NEW_EMAC_TAH
EMAC_FTR_HAS_TAH |
^ permalink raw reply
* [PATCH 6/6] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaround
From: Benjamin Herrenschmidt @ 2008-04-22 0:46 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-dev
From: Valentine Barshak <vbarshak@ru.mvista.com>
This patch adds ibm_newemac PHY clock workaround for 440EP/440GR EMAC
attached to a PHY which doesn't generate RX clock if there is no link.
The code is based on the previous ibm_emac driver stuff. The 440EP/440GR
allows controlling each EMAC clock separately as opposed to global clock
selection for 440GX.
BenH: Made that #ifdef CONFIG_PPC_DCR_NATIVE for now as dcri_* stuff doesn't
exist for MMIO type DCRs like Cell. Some future rework & improvements of the
DCR infrastructure will make that cleaner but for now, this makes it work.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/net/ibm_newemac/core.c | 43 ++++++++++++++++++++++++++++++++++++++++-
drivers/net/ibm_newemac/core.h | 6 ++++-
2 files changed, 47 insertions(+), 2 deletions(-)
--- linux-work.orig/drivers/net/ibm_newemac/core.c 2008-04-22 10:31:18.000000000 +1000
+++ linux-work/drivers/net/ibm_newemac/core.c 2008-04-22 10:38:49.000000000 +1000
@@ -129,10 +129,35 @@ static struct device_node *emac_boot_lis
static inline void emac_report_timeout_error(struct emac_instance *dev,
const char *error)
{
- if (net_ratelimit())
+ if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX |
+ EMAC_FTR_440EP_PHY_CLK_FIX))
+ DBG(dev, "%s" NL, error);
+ else if (net_ratelimit())
printk(KERN_ERR "%s: %s\n", dev->ndev->name, error);
}
+/* EMAC PHY clock workaround:
+ * 440EP/440GR has more sane SDR0_MFR register implementation than 440GX,
+ * which allows controlling each EMAC clock
+ */
+static inline void emac_rx_clk_tx(struct emac_instance *dev)
+{
+#ifdef CONFIG_PPC_DCR_NATIVE
+ if (emac_has_feature(dev, EMAC_FTR_440EP_PHY_CLK_FIX))
+ dcri_clrset(SDR0, SDR0_MFR,
+ 0, SDR0_MFR_ECS >> dev->cell_index);
+#endif
+}
+
+static inline void emac_rx_clk_default(struct emac_instance *dev)
+{
+#ifdef CONFIG_PPC_DCR_NATIVE
+ if (emac_has_feature(dev, EMAC_FTR_440EP_PHY_CLK_FIX))
+ dcri_clrset(SDR0, SDR0_MFR,
+ SDR0_MFR_ECS >> dev->cell_index, 0);
+#endif
+}
+
/* PHY polling intervals */
#define PHY_POLL_LINK_ON HZ
#define PHY_POLL_LINK_OFF (HZ / 5)
@@ -1099,9 +1124,11 @@ static int emac_open(struct net_device *
int link_poll_interval;
if (dev->phy.def->ops->poll_link(&dev->phy)) {
dev->phy.def->ops->read_link(&dev->phy);
+ emac_rx_clk_default(dev);
netif_carrier_on(dev->ndev);
link_poll_interval = PHY_POLL_LINK_ON;
} else {
+ emac_rx_clk_tx(dev);
netif_carrier_off(dev->ndev);
link_poll_interval = PHY_POLL_LINK_OFF;
}
@@ -1179,6 +1206,7 @@ static void emac_link_timer(struct work_
if (dev->phy.def->ops->poll_link(&dev->phy)) {
if (!netif_carrier_ok(dev->ndev)) {
+ emac_rx_clk_default(dev);
/* Get new link parameters */
dev->phy.def->ops->read_link(&dev->phy);
@@ -1191,6 +1219,7 @@ static void emac_link_timer(struct work_
link_poll_interval = PHY_POLL_LINK_ON;
} else {
if (netif_carrier_ok(dev->ndev)) {
+ emac_rx_clk_tx(dev);
netif_carrier_off(dev->ndev);
netif_tx_disable(dev->ndev);
emac_reinitialize(dev);
@@ -2340,6 +2369,14 @@ static int __devinit emac_init_phy(struc
if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX))
dcri_clrset(SDR0, SDR0_MFR, 0, SDR0_MFR_ECS);
#endif
+ /* PHY clock workaround */
+ emac_rx_clk_tx(dev);
+
+ /* Enable internal clock source on 440GX*/
+#ifdef CONFIG_PPC_DCR_NATIVE
+ if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX))
+ dcri_clrset(SDR0, SDR0_MFR, 0, SDR0_MFR_ECS);
+#endif
/* Configure EMAC with defaults so we can at least use MDIO
* This is needed mostly for 440GX
*/
@@ -2507,6 +2544,10 @@ static int __devinit emac_init_config(st
dev->features |= EMAC_FTR_EMAC4;
if (of_device_is_compatible(np, "ibm,emac-440gx"))
dev->features |= EMAC_FTR_440GX_PHY_CLK_FIX;
+ } else {
+ if (of_device_is_compatible(np, "ibm,emac-440ep") ||
+ of_device_is_compatible(np, "ibm,emac-440gr"))
+ dev->features |= EMAC_FTR_440EP_PHY_CLK_FIX;
}
/* Fixup some feature bits based on the device tree */
Index: linux-work/drivers/net/ibm_newemac/core.h
===================================================================
--- linux-work.orig/drivers/net/ibm_newemac/core.h 2008-04-22 10:30:03.000000000 +1000
+++ linux-work/drivers/net/ibm_newemac/core.h 2008-04-22 10:33:12.000000000 +1000
@@ -305,6 +305,10 @@ struct emac_instance {
* Set if we need phy clock workaround for 440gx
*/
#define EMAC_FTR_440GX_PHY_CLK_FIX 0x00000080
+/*
+ * Set if we need phy clock workaround for 440ep or 440gr
+ */
+#define EMAC_FTR_440EP_PHY_CLK_FIX 0x00000100
/* Right now, we don't quite handle the always/possible masks on the
@@ -328,7 +332,7 @@ enum {
#ifdef CONFIG_IBM_NEW_EMAC_RGMII
EMAC_FTR_HAS_RGMII |
#endif
- 0,
+ EMAC_FTR_440EP_PHY_CLK_FIX,
};
static inline int emac_has_feature(struct emac_instance *dev,
^ permalink raw reply
* [PATCH 0/2] Fix 440 arch/ppc builds
From: Josh Boyer @ 2008-04-22 0:47 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
The following two patches fix arch/ppc 440 builds. Unless some miracle
occurs and people stop breaking arch/ppc with commits, this will likely
be the last kernel where it builds.
josh
^ permalink raw reply
* [PATCH 1/2] [PPC] 4xx: Fix duplicate phys_addr_t definition
From: Josh Boyer @ 2008-04-22 0:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <1208825276.6654.41.camel@vader.jdub.homelinux.org>
Commit d04ceb3fc294ea2c4f538a04343f3a473953a3b0 moved phys_addr_t definitions
to include/asm-powerpc/types.h. However, arch/ppc 440 builds had a duplicate
definition in include/asm-ppc/mmu.h that caused the build to fail.
This removes the duplicate definition in arch/ppc.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
include/asm-ppc/mmu.h | 2 --
1 file changed, 2 deletions(-)
--- linux-2.6.orig/include/asm-ppc/mmu.h
+++ linux-2.6/include/asm-ppc/mmu.h
@@ -15,10 +15,8 @@
* physical need a larger than native word size type. -Matt
*/
#ifndef CONFIG_PHYS_64BIT
-typedef unsigned long phys_addr_t;
#define PHYS_FMT "%.8lx"
#else
-typedef unsigned long long phys_addr_t;
extern phys_addr_t fixup_bigphys_addr(phys_addr_t, phys_addr_t);
#define PHYS_FMT "%16Lx"
#endif
^ permalink raw reply
* [PATCH 2/2] [PPC] Add strncmp to arch/ppc
From: Josh Boyer @ 2008-04-22 0:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <1208825276.6654.41.camel@vader.jdub.homelinux.org>
Commit 0119536cd314ef95553604208c25bc35581f7f0a added an assembly version
of strncmp to PowerPC. However, it changed a common header file between
arch/ppc and arch/powerpc without adding strncmp to arch/ppc. This fixes
that omission so that arch/ppc links again.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/ppc/kernel/ppc_ksyms.c | 1 +
arch/ppc/lib/string.S | 14 ++++++++++++++
2 files changed, 15 insertions(+)
--- linux-2.6.orig/arch/ppc/kernel/ppc_ksyms.c
+++ linux-2.6/arch/ppc/kernel/ppc_ksyms.c
@@ -89,6 +89,7 @@ EXPORT_SYMBOL(strncpy);
EXPORT_SYMBOL(strcat);
EXPORT_SYMBOL(strlen);
EXPORT_SYMBOL(strcmp);
+EXPORT_SYMBOL(strncmp);
EXPORT_SYMBOL(csum_partial);
EXPORT_SYMBOL(csum_partial_copy_generic);
--- linux-2.6.orig/arch/ppc/lib/string.S
+++ linux-2.6/arch/ppc/lib/string.S
@@ -121,6 +121,20 @@ _GLOBAL(strcmp)
beq 1b
blr
+_GLOBAL(strncmp)
+ PPC_LCMPI r5,0
+ beqlr
+ mtctr r5
+ addi r5,r3,-1
+ addi r4,r4,-1
+1: lbzu r3,1(r5)
+ cmpwi 1,r3,0
+ lbzu r0,1(r4)
+ subf. r3,r0,r3
+ beqlr 1
+ bdnzt eq,1b
+ blr
+
_GLOBAL(strlen)
addi r4,r3,-1
1: lbzu r0,1(r4)
^ permalink raw reply
* Re: [PATCH] [PPC] Remove mpc8272 ads board from arch/ppc
From: Scott Wood @ 2008-04-22 1:06 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <d6a1e8455b5c2c2a23d3713ee7c16805@kernel.crashing.org>
On Mon, Apr 21, 2008 at 11:25:29PM +0200, Segher Boessenkool wrote:
> >> The last time arch/ppc built for me (a few days ago), it got
> >> 535 warnings.
Heh.
> >> I don't think anyone would notice one more.
Well, it wouldn't be one more, it'd be one per file that includes the
header. If we choose something like asm/system.h, and scream in
*** ALL CAPS!!one!11! ***, it should get through the noise.
> >> Also, whoever doesn't yet know arch/ppc will be going away has been
> >> living under a rock for the last two years.
> >
> >You say that as if it is an uncommon living condition.
>
> Oh sorry. "Under a rock without any connection to the intertubes".
I guess you missed the recent patch someone posted with style cleanup in
arch/ppc/8xx_io? :-P
-Scott
^ permalink raw reply
* [PATCH 1/3] radeonfb: Fix 64 bits resources on 32 bits archs
From: Benjamin Herrenschmidt @ 2008-04-22 1:26 UTC (permalink / raw)
To: linux-fbdev-devel; +Cc: linuxppc-dev, Andrew Morton, linux-kernel, adaplas
This fixes radeonfb to not truncate 64 bits resources on 32 bits
platforms. Unfortunately, there are still issues with addresses
returned to userspace via struct fb_fix_screeninfo. This will
have to be dealt with separately.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/video/aty/radeon_base.c | 4 ++--
drivers/video/aty/radeonfb.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
--- linux-work.orig/drivers/video/aty/radeon_base.c 2008-04-22 11:04:19.000000000 +1000
+++ linux-work/drivers/video/aty/radeon_base.c 2008-04-22 11:05:00.000000000 +1000
@@ -1886,7 +1886,7 @@ static int __devinit radeon_set_fbinfo (
info->screen_size = rinfo->mapped_vram;
/* Fill fix common fields */
strlcpy(info->fix.id, rinfo->name, sizeof(info->fix.id));
- info->fix.smem_start = rinfo->fb_base_phys;
+ info->fix.smem_start = (unsigned long)rinfo->fb_base_phys;
info->fix.smem_len = rinfo->video_ram;
info->fix.type = FB_TYPE_PACKED_PIXELS;
info->fix.visual = FB_VISUAL_PSEUDOCOLOR;
@@ -1894,7 +1894,7 @@ static int __devinit radeon_set_fbinfo (
info->fix.ypanstep = 1;
info->fix.ywrapstep = 0;
info->fix.type_aux = 0;
- info->fix.mmio_start = rinfo->mmio_base_phys;
+ info->fix.mmio_start = (unsigned long)rinfo->mmio_base_phys;
info->fix.mmio_len = RADEON_REGSIZE;
info->fix.accel = FB_ACCEL_ATI_RADEON;
Index: linux-work/drivers/video/aty/radeonfb.h
===================================================================
--- linux-work.orig/drivers/video/aty/radeonfb.h 2008-04-22 11:03:17.000000000 +1000
+++ linux-work/drivers/video/aty/radeonfb.h 2008-04-22 11:03:27.000000000 +1000
@@ -287,8 +287,8 @@ struct radeonfb_info {
char name[DEVICE_NAME_SIZE];
- unsigned long mmio_base_phys;
- unsigned long fb_base_phys;
+ resource_size_t mmio_base_phys;
+ resource_size_t fb_base_phys;
void __iomem *mmio_base;
void __iomem *fb_base;
^ permalink raw reply
* [PATCH 2/3] aty128fb: Fix 64 bits resources on 32 bits archs
From: Benjamin Herrenschmidt @ 2008-04-22 1:26 UTC (permalink / raw)
To: linux-fbdev-devel; +Cc: linuxppc-dev, Andrew Morton, linux-kernel, adaplas
This fixes aty128fb to not truncate 64 bits resources on 32 bits
platforms. Unfortunately, there are still issues with addresses
returned to userspace via struct fb_fix_screeninfo. This will
have to be dealt with separately.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/video/aty/aty128fb.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
--- linux-work.orig/drivers/video/aty/aty128fb.c 2008-04-22 11:18:41.000000000 +1000
+++ linux-work/drivers/video/aty/aty128fb.c 2008-04-22 11:19:31.000000000 +1000
@@ -2011,7 +2011,7 @@ static int __devinit aty128_init(struct
/* register a card ++ajoshi */
static int __devinit aty128_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
{
- unsigned long fb_addr, reg_addr;
+ resource_size_t fb_addr, reg_addr;
struct aty128fb_par *par;
struct fb_info *info;
int err;
@@ -2052,7 +2052,6 @@ static int __devinit aty128_probe(struct
info->pseudo_palette = par->pseudo_palette;
/* Virtualize mmio region */
- info->fix.mmio_start = reg_addr;
par->regbase = ioremap(reg_addr, pci_resource_len(pdev, 2));
if (!par->regbase)
goto err_free_info;
@@ -2068,9 +2067,9 @@ static int __devinit aty128_probe(struct
/* Set up info->fix */
info->fix = aty128fb_fix;
- info->fix.smem_start = fb_addr;
+ info->fix.smem_start = (unsigned long)fb_addr;
info->fix.smem_len = par->vram_size;
- info->fix.mmio_start = reg_addr;
+ info->fix.mmio_start = (unsigned long)reg_addr;
/* If we can't test scratch registers, something is seriously wrong */
if (!register_test(par)) {
^ permalink raw reply
* [PATCH 3/3] atyfb: Fix 64 bits resources on 32 bits archs
From: Benjamin Herrenschmidt @ 2008-04-22 1:26 UTC (permalink / raw)
To: linux-fbdev-devel; +Cc: linuxppc-dev, Andrew Morton, linux-kernel, adaplas
This fixes atyfb to not truncate 64 bits resources on 32 bits
platforms. Unfortunately, there are still issues with addresses
returned to userspace via struct fb_fix_screeninfo. This will
have to be dealt with separately.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/video/aty/atyfb_base.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
--- linux-work.orig/drivers/video/aty/atyfb_base.c 2008-04-22 11:21:46.000000000 +1000
+++ linux-work/drivers/video/aty/atyfb_base.c 2008-04-22 11:23:58.000000000 +1000
@@ -2842,7 +2842,7 @@ static int atyfb_setcolreg(u_int regno,
#ifdef __sparc__
static int __devinit atyfb_setup_sparc(struct pci_dev *pdev,
- struct fb_info *info, unsigned long addr)
+ struct fb_info *info, resource_size_t addr)
{
struct atyfb_par *par = info->par;
struct device_node *dp;
@@ -3334,11 +3334,11 @@ static int __devinit init_from_bios(stru
}
#endif /* __i386__ */
-static int __devinit atyfb_setup_generic(struct pci_dev *pdev, struct fb_info *info, unsigned long addr)
+static int __devinit atyfb_setup_generic(struct pci_dev *pdev, struct fb_info *info, resource_size_t addr)
{
struct atyfb_par *par = info->par;
u16 tmp;
- unsigned long raddr;
+ resource_size_t raddr;
struct resource *rrp;
int ret = 0;
@@ -3351,8 +3351,8 @@ static int __devinit atyfb_setup_generic
PRINTKI("using auxiliary register aperture\n");
}
- info->fix.mmio_start = raddr;
- par->ati_regbase = ioremap(info->fix.mmio_start, 0x1000);
+ info->fix.mmio_start = (unsigned long)raddr;
+ par->ati_regbase = ioremap(raddr, 0x1000);
if (par->ati_regbase == 0)
return -ENOMEM;
@@ -3374,7 +3374,7 @@ static int __devinit atyfb_setup_generic
#endif
/* Map in frame buffer */
- info->fix.smem_start = addr;
+ info->fix.smem_start = (unsigned long)addr;
info->screen_base = ioremap(addr, 0x800000);
if (info->screen_base == NULL) {
ret = -ENOMEM;
@@ -3411,7 +3411,7 @@ atyfb_setup_generic_fail:
static int __devinit atyfb_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
{
- unsigned long addr, res_start, res_size;
+ resource_size_t addr, res_start, res_size;
struct fb_info *info;
struct resource *rp;
struct atyfb_par *par;
^ permalink raw reply
* [PATCH 1/3] Raise the upper limit of NR_CPUS.
From: Tony Breeds @ 2008-04-22 3:30 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev
As the pacas are statically initialised increasing NR_CPUS beyond 128,
means that any additional pacas will be empty ... which is bad.
This patch adds the required functionality to fill in any excess pacas
at runtime.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/kernel/paca.c | 57 ++++++++++++++++++++------------
arch/powerpc/kernel/setup_64.c | 3 ++
arch/powerpc/platforms/Kconfig.cputype | 4 +-
include/asm-powerpc/paca.h | 20 +++++++++++
4 files changed, 61 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index ac163bd..7cd55f2 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -18,6 +18,15 @@
#include <asm/paca.h>
#include <asm/mmu.h>
+/*
+ * In order to handle "strange" values of NR_CPUS, Make sure we use
+ * max(NR_CPUS, NR_STATIC_PACAS) for array sizes below
+ */
+#if NR_CPUS > NR_STATIC_PACAS
+#define MAX_CPUS NR_CPUS
+#else
+#define MAX_CPUS NR_STATIC_PACAS
+#endif
/* This symbol is provided by the linker - let it fill in the paca
* field correctly */
@@ -33,7 +42,7 @@ extern unsigned long __toc_start;
* will suffice to ensure that it doesn't cross a page boundary.
*/
struct lppaca lppaca[] = {
- [0 ... (NR_CPUS-1)] = {
+ [0 ... (MAX_CPUS-1)] = {
.desc = 0xd397d781, /* "LpPa" */
.size = sizeof(struct lppaca),
.dyn_proc_status = 2,
@@ -50,7 +59,7 @@ struct lppaca lppaca[] = {
* initially, hence will all be invaild until we actually write them.
*/
struct slb_shadow slb_shadow[] __cacheline_aligned = {
- [0 ... (NR_CPUS-1)] = {
+ [0 ... (MAX_CPUS-1)] = {
.persistent = SLB_NUM_BOLTED,
.buffer_length = sizeof(struct slb_shadow),
},
@@ -76,7 +85,7 @@ struct slb_shadow slb_shadow[] __cacheline_aligned = {
.__current = &init_task, \
}
-struct paca_struct paca[] = {
+struct paca_struct paca[MAX_CPUS] = {
PACA_INIT(0),
#if NR_CPUS > 1
PACA_INIT( 1), PACA_INIT( 2), PACA_INIT( 3),
@@ -98,27 +107,33 @@ struct paca_struct paca[] = {
PACA_INIT( 52), PACA_INIT( 53), PACA_INIT( 54), PACA_INIT( 55),
PACA_INIT( 56), PACA_INIT( 57), PACA_INIT( 58), PACA_INIT( 59),
PACA_INIT( 60), PACA_INIT( 61), PACA_INIT( 62), PACA_INIT( 63),
-#if NR_CPUS > 64
- PACA_INIT( 64), PACA_INIT( 65), PACA_INIT( 66), PACA_INIT( 67),
- PACA_INIT( 68), PACA_INIT( 69), PACA_INIT( 70), PACA_INIT( 71),
- PACA_INIT( 72), PACA_INIT( 73), PACA_INIT( 74), PACA_INIT( 75),
- PACA_INIT( 76), PACA_INIT( 77), PACA_INIT( 78), PACA_INIT( 79),
- PACA_INIT( 80), PACA_INIT( 81), PACA_INIT( 82), PACA_INIT( 83),
- PACA_INIT( 84), PACA_INIT( 85), PACA_INIT( 86), PACA_INIT( 87),
- PACA_INIT( 88), PACA_INIT( 89), PACA_INIT( 90), PACA_INIT( 91),
- PACA_INIT( 92), PACA_INIT( 93), PACA_INIT( 94), PACA_INIT( 95),
- PACA_INIT( 96), PACA_INIT( 97), PACA_INIT( 98), PACA_INIT( 99),
- PACA_INIT(100), PACA_INIT(101), PACA_INIT(102), PACA_INIT(103),
- PACA_INIT(104), PACA_INIT(105), PACA_INIT(106), PACA_INIT(107),
- PACA_INIT(108), PACA_INIT(109), PACA_INIT(110), PACA_INIT(111),
- PACA_INIT(112), PACA_INIT(113), PACA_INIT(114), PACA_INIT(115),
- PACA_INIT(116), PACA_INIT(117), PACA_INIT(118), PACA_INIT(119),
- PACA_INIT(120), PACA_INIT(121), PACA_INIT(122), PACA_INIT(123),
- PACA_INIT(124), PACA_INIT(125), PACA_INIT(126), PACA_INIT(127),
-#endif
#endif
#endif
#endif
#endif
};
EXPORT_SYMBOL(paca);
+
+/*
+ * The first few (NR_STATIC_PACAS) paca entires are initiialised
+ * statically. populate the rest.
+ */
+void __init initialise_pacas(void)
+{
+ int cpu;
+ unsigned long kernel_toc = (unsigned long)(&__toc_start) + 0x8000UL;
+
+ /* Can't use for_each_*_cpu, as they aren't functional yet */
+ for (cpu = NR_STATIC_PACAS; cpu < NR_CPUS; cpu++) {
+ struct paca_struct *new_paca = &paca[cpu];
+
+ new_paca->lppaca_ptr = &lppaca[cpu];
+ new_paca->lock_token = 0x8000;
+ new_paca->paca_index = cpu;
+ new_paca->kernel_toc = kernel_toc;
+ new_paca->hw_cpu_id = 0xffff;
+ new_paca->slb_shadow_ptr = &slb_shadow[cpu];
+ new_paca->__current = &init_task;
+
+ }
+}
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 31ada9f..5e382ac 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -170,6 +170,9 @@ void __init setup_paca(int cpu)
void __init early_setup(unsigned long dt_ptr)
{
+ /* Fill in any unititialised pacas */
+ initialise_pacas();
+
/* Identify CPU type */
identify_cpu(0, mfspr(SPRN_PVR));
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 5fc7fac..f7efaa9 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -220,8 +220,8 @@ config SMP
If you don't know what to do here, say N.
config NR_CPUS
- int "Maximum number of CPUs (2-128)"
- range 2 128
+ int "Maximum number of CPUs (2-1024)"
+ range 2 1024
depends on SMP
default "32" if PPC64
default "4"
diff --git a/include/asm-powerpc/paca.h b/include/asm-powerpc/paca.h
index eb61b9c..871f693 100644
--- a/include/asm-powerpc/paca.h
+++ b/include/asm-powerpc/paca.h
@@ -16,10 +16,29 @@
#define _ASM_POWERPC_PACA_H
#ifdef __KERNEL__
+#include <linux/threads.h>
+
#include <asm/types.h>
#include <asm/lppaca.h>
#include <asm/mmu.h>
+/*
+ * iSeries needs the paca to be statically allocated and initialised.
+ * We will allocated this many, based on NR_CPUS.
+ */
+#if NR_CPUS >= 32
+#define NR_STATIC_PACAS 64
+#elif NR_CPUS > 8
+#define NR_STATIC_PACAS 32
+#elif NR_CPUS > 4
+#define NR_STATIC_PACAS 8
+#elif NR_CPUS > 1
+#define NR_STATIC_PACAS 4
+#else
+#define NR_STATIC_PACAS 1
+#endif
+
+
register struct paca_struct *local_paca asm("r13");
#if defined(CONFIG_DEBUG_PREEMPT) && defined(CONFIG_SMP)
@@ -108,6 +127,7 @@ struct paca_struct {
};
extern struct paca_struct paca[];
+extern void initialise_pacas(void);
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_PACA_H */
--
1.5.5
^ permalink raw reply related
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