* Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
From: Kumar Gala @ 2008-05-02 21:31 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <1f2a22ddd60d37e6e7dc1048feb6d0a4@kernel.crashing.org>
On May 2, 2008, at 12:33 PM, Segher Boessenkool wrote:
>> If someone using cutting edge toolchains for ppc64 could test and
>> make
>> sure if we enable CONFIG_CC_OPTIMIZE_FOR_SIZE things work that
>> would be
>> nice.
>
> Current linus tree + some more stuff + this patch, ppc64_defconfig,
> powerpc64-linux-gcc (GCC) 4.4.0 20080429 (experimental), builds just
> fine. CONFIG_CC_OPTIMIZE_FOR_SIZE=y. Need any more test / more info?
I don't think the gcc guys have accepted (or committed) the patch I
was referencing. Once it has been we should retest and see what
happens.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
From: Kumar Gala @ 2008-05-02 21:34 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <03e9cbca081bff8f6db9862bf3d8d028@kernel.crashing.org>
On May 2, 2008, at 12:34 PM, Segher Boessenkool wrote:
>>> <brokenrecord>
>>> Why don't we just link with libgcc?
>>> </brokenrecord>
>>
>> Its something of a PITA to do that in the kernel at this point
>> since we've duplicated libgcc functionality in it. I'm sure there
>> are some historical reasons this wasn't done to start with.
>
> That's the same as saying that it would be a nice cleanup to remove
> all
> that duplicated code now...
We'll hopefully this thread might spark either an explanation for why
we aren't just linking libgcc in a statement that says we should and
we can remove the code that implements libgcc functionality.
How would libgcc linking intermix with modules? Would we have to
EXPORT_SYMBOL() all functions that libgcc implements? I'm guessing
that's varies w/different gcc versions.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
From: Scott Wood @ 2008-05-02 21:40 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <BFB7B7A0-6EA9-467D-B23E-B0D46EF6BA54@kernel.crashing.org>
Kumar Gala wrote:
>
> On May 2, 2008, at 12:34 PM, Segher Boessenkool wrote:
>
>>>> <brokenrecord>
>>>> Why don't we just link with libgcc?
>>>> </brokenrecord>
>>>
>>> Its something of a PITA to do that in the kernel at this point since
>>> we've duplicated libgcc functionality in it. I'm sure there are some
>>> historical reasons this wasn't done to start with.
>>
>> That's the same as saying that it would be a nice cleanup to remove all
>> that duplicated code now...
>
> We'll hopefully this thread might spark either an explanation for why we
> aren't just linking libgcc in a statement that says we should and we can
> remove the code that implements libgcc functionality.
>
> How would libgcc linking intermix with modules? Would we have to
> EXPORT_SYMBOL() all functions that libgcc implements?
Yes, unfortunately.
A quick way to generate such a list would be to build a non-modular
kernel and leave out the libgcc link (after removing the reimplemented
functions), and see what linker errors you get.
> I'm guessing that's varies w/different gcc versions.
Yeah, but so does the set of functions that Linux needs to reimplement.
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
From: David Miller @ 2008-05-02 21:40 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
In-Reply-To: <3B083683-CB6E-4F1D-87EF-BBFA7D491271@kernel.crashing.org>
From: Kumar Gala <galak@kernel.crashing.org>
Date: Fri, 2 May 2008 16:28:36 -0500
> Sorry, I meant the gcc patch. I'm not sure if this has been committed
> to FSF head or not.
If that's the case it would be a good idea to suggest a command line
option to disable the new out-of-line code generation feature of that
patch.
But if the stubs it calls are really simple, you can just add
implementations under arch/powerpc/lib/, and therefore it's
not such a big deal. This is what we've traditionally done
with libcalls generated by gcc for runtime support.
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
From: David Miller @ 2008-05-02 21:42 UTC (permalink / raw)
To: galak; +Cc: scottwood, linuxppc-dev
In-Reply-To: <BFB7B7A0-6EA9-467D-B23E-B0D46EF6BA54@kernel.crashing.org>
From: Kumar Gala <galak@kernel.crashing.org>
Date: Fri, 2 May 2008 16:34:13 -0500
> We'll hopefully this thread might spark either an explanation for why
> we aren't just linking libgcc in a statement that says we should and
> we can remove the code that implements libgcc functionality.
>
> How would libgcc linking intermix with modules? Would we have to
> EXPORT_SYMBOL() all functions that libgcc implements? I'm guessing
> that's varies w/different gcc versions.
If you link in libgcc, all of a sudden you have a whole new class of
potential problems, don't do it.
All it takes is one of these libgcc libcalls the kernel actually
references, needing something else in libc, to make this exercise
futile.
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
From: Scott Wood @ 2008-05-02 21:45 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev
In-Reply-To: <20080502.144220.53637856.davem@davemloft.net>
David Miller wrote:
> If you link in libgcc, all of a sudden you have a whole new class of
> potential problems, don't do it.
>
> All it takes is one of these libgcc libcalls the kernel actually
> references, needing something else in libc, to make this exercise
> futile.
What in libgcc references libc, and why isn't this a problem for
Linux/ARM, Linux/SH, U-boot, and the many other libc-less programs that
use libgcc?
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
From: Kumar Gala @ 2008-05-02 21:58 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev
In-Reply-To: <20080502.144009.147804001.davem@davemloft.net>
On May 2, 2008, at 4:40 PM, David Miller wrote:
> From: Kumar Gala <galak@kernel.crashing.org>
> Date: Fri, 2 May 2008 16:28:36 -0500
>
>> Sorry, I meant the gcc patch. I'm not sure if this has been
>> committed
>> to FSF head or not.
>
> If that's the case it would be a good idea to suggest a command line
> option to disable the new out-of-line code generation feature of that
> patch.
>
> But if the stubs it calls are really simple, you can just add
> implementations under arch/powerpc/lib/, and therefore it's
> not such a big deal. This is what we've traditionally done
> with libcalls generated by gcc for runtime support.
They are pretty simple.
http://patchwork.ozlabs.org/linuxppc/patch?id=18292
http://patchwork.ozlabs.org/linuxppc/patch?id=18290
I've got a toolchain from CodeSourcery that has the GCC change in it
and was posting this as preemptive for the point in time when FSF GCC
has it. At which point the whole discussion about why don't we just
link libgcc started up :)
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
From: David Miller @ 2008-05-02 22:04 UTC (permalink / raw)
To: scottwood; +Cc: linuxppc-dev
In-Reply-To: <481B8B89.2030703@freescale.com>
From: Scott Wood <scottwood@freescale.com>
Date: Fri, 02 May 2008 16:45:45 -0500
> David Miller wrote:
> > If you link in libgcc, all of a sudden you have a whole new class of
> > potential problems, don't do it.
> >
> > All it takes is one of these libgcc libcalls the kernel actually
> > references, needing something else in libc, to make this exercise
> > futile.
>
> What in libgcc references libc, and why isn't this a problem for
> Linux/ARM, Linux/SH, U-boot, and the many other libc-less programs that
> use libgcc?
The problem only occurs once you reference a function that references
libc stuff, and those guys are just lucky so far.
It's also one less variable to debug if you put the implementation
in the kernel, or do you like debugging compiler induced problems?
I don't :-)
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
From: Scott Wood @ 2008-05-02 22:16 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev
In-Reply-To: <20080502.150448.32652665.davem@davemloft.net>
David Miller wrote:
> The problem only occurs once you reference a function that references
> libc stuff, and those guys are just lucky so far.
Yeah, lucky they don't need to reinvent the wheel every time the
GCC/libgcc interface changes. :-)
If GCC generates a call to a libgcc function that calls a libc function,
I'd consider that a pretty serious bug, given that said libc function is
likely to consist of GCC-generated code, which could call the same
libgcc function, which calls the libc function, etc.
> It's also one less variable to debug if you put the implementation
> in the kernel, or do you like debugging compiler induced problems?
> I don't :-)
I'd say problems are more likely if you use nonstandard implementations
of GCC internals...
-Scott
^ permalink raw reply
* Re: [RFC] [PATCH] vmemmap fixes to use smaller pages
From: Geoff Levand @ 2008-05-02 22:21 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev list
In-Reply-To: <1209681590.18023.295.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Thu, 2008-05-01 at 14:46 -0700, Geoff Levand wrote:
>>
>> It doesn't seem to cause problems on PS3, and I added it into
>> ps3-linux.git
>> as other/powerpc-vmemmap-variable-page-size.diff, but I couldn't get
>> it to
>> fail without the patch...
>>
>> Could you send me your kernel .config?
>
> ps3_defconfig with added vmmemap (which is disabled by default).
Well, it seems that it wasn't that I couldn't get it to fail, but
that it always fails. add_memory() doesn't work anymore, with or
without vmmemap.
I'll look at it more next week.
-Geoff
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
From: David Miller @ 2008-05-02 22:30 UTC (permalink / raw)
To: scottwood; +Cc: linuxppc-dev
In-Reply-To: <481B92A7.3070302@freescale.com>
From: Scott Wood <scottwood@freescale.com>
Date: Fri, 02 May 2008 17:16:07 -0500
> If GCC generates a call to a libgcc function that calls a libc function,
> I'd consider that a pretty serious bug, given that said libc function is
> likely to consist of GCC-generated code, which could call the same
> libgcc function, which calls the libc function, etc.
Not really, there are several interfaces in libgcc that need some
runtime help from the C library or the dynamic linker.
For example, EH frame support.
You really don't know what you're talking about.
> I'd say problems are more likely if you use nonstandard implementations
> of GCC internals...
The kernel is a special environment. Therefore even if you start
linking with libgcc, it is inevitable that you will need some
changed local version for some of those routines in the kernel.
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
From: Scott Wood @ 2008-05-02 22:38 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev
In-Reply-To: <20080502.153059.91956773.davem@davemloft.net>
David Miller wrote:
> From: Scott Wood <scottwood@freescale.com>
> Date: Fri, 02 May 2008 17:16:07 -0500
>
>> If GCC generates a call to a libgcc function that calls a libc function,
>> I'd consider that a pretty serious bug, given that said libc function is
>> likely to consist of GCC-generated code, which could call the same
>> libgcc function, which calls the libc function, etc.
>
> Not really, there are several interfaces in libgcc that need some
> runtime help from the C library or the dynamic linker.
>
> For example, EH frame support.
...which is in libgcc_eh, not libgcc, and is in support of features not
found in the language that libc is implemented in, avoiding any
possibility of a cyclic dependency. And the sort of libc functions it
uses are basic, standard things like memcpy and malloc. Much easier and
more stable to implement than the internal libgcc interface.
> You really don't know what you're talking about.
Yawn.
>> I'd say problems are more likely if you use nonstandard implementations
>> of GCC internals...
>
> The kernel is a special environment. Therefore even if you start
> linking with libgcc, it is inevitable that you will need some
> changed local version for some of those routines in the kernel.
Such as?
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
From: David Miller @ 2008-05-02 22:39 UTC (permalink / raw)
To: scottwood; +Cc: linuxppc-dev
In-Reply-To: <481B97DD.5070103@freescale.com>
From: Scott Wood <scottwood@freescale.com>
Date: Fri, 02 May 2008 17:38:21 -0500
> David Miller wrote:
> > The kernel is a special environment. Therefore even if you start
> > linking with libgcc, it is inevitable that you will need some
> > changed local version for some of those routines in the kernel.
>
> Such as?
When I added the software multiply and divide implemenations
to the 32-bit sparc port, I ended up using a different software
trap for signalling divide by zero in the handler so that it
was easier to detect the "from kernel" kernel case.
We're not talking about big complicated routines, we're talking about
quite simple stubs whose interfaces really are not going to change.
^ permalink raw reply
* Re: [POWERPC][v2] Bolt in SLB entry for kernel stack on secondary cpus
From: Benjamin Herrenschmidt @ 2008-05-02 23:19 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel, David Gibson
In-Reply-To: <18458.55542.977597.204532@cargo.ozlabs.ibm.com>
On Fri, 2008-05-02 at 19:03 +1000, Paul Mackerras wrote:
> David Gibson writes:
>
> > Do you even need the processor ID test at all? The boot processor
> > should always have its stack covered by SLB entry 0 when we come
> > through here, shouldn't it?
>
> I was concerned that get_paca()->kstack wouldn't have been initialized
> by the time the boot cpu calls slb_initialize(). If that fear is
> unfounded then the check could go.
No, you are correct, it's not initialized. However, I find that a bit
weird, as we shouldn't have a problem initializing it in
start_here_multiplatform rather than start_here_common.
The whole stack setup part of these here seems like a dup to me.
Ben.
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
From: Benjamin Herrenschmidt @ 2008-05-02 23:23 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <BFB7B7A0-6EA9-467D-B23E-B0D46EF6BA54@kernel.crashing.org>
On Fri, 2008-05-02 at 16:34 -0500, Kumar Gala wrote:
> On May 2, 2008, at 12:34 PM, Segher Boessenkool wrote:
>
> >>> <brokenrecord>
> >>> Why don't we just link with libgcc?
> >>> </brokenrecord>
> >>
> >> Its something of a PITA to do that in the kernel at this point
> >> since we've duplicated libgcc functionality in it. I'm sure there
> >> are some historical reasons this wasn't done to start with.
> >
> > That's the same as saying that it would be a nice cleanup to remove
> > all
> > that duplicated code now...
>
> We'll hopefully this thread might spark either an explanation for why
> we aren't just linking libgcc in a statement that says we should and
> we can remove the code that implements libgcc functionality.
>
> How would libgcc linking intermix with modules? Would we have to
> EXPORT_SYMBOL() all functions that libgcc implements? I'm guessing
> that's varies w/different gcc versions.
The historical reason for not linking with libgcc was around the lines
of "we want to catch when people do stupid things like 64 bits divides
in the kernel".
Nowadays, this is mostly moot and it's accepted that things might want
to do such operations here or there.
I personally don't see any problem with a patch that would make us link
with libgcc and get rid of the hacks.
Ben.
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
From: Benjamin Herrenschmidt @ 2008-05-02 23:24 UTC (permalink / raw)
To: David Miller; +Cc: scottwood, linuxppc-dev
In-Reply-To: <20080502.144220.53637856.davem@davemloft.net>
On Fri, 2008-05-02 at 14:42 -0700, David Miller wrote:
> From: Kumar Gala <galak@kernel.crashing.org>
> Date: Fri, 2 May 2008 16:34:13 -0500
>
> > We'll hopefully this thread might spark either an explanation for why
> > we aren't just linking libgcc in a statement that says we should and
> > we can remove the code that implements libgcc functionality.
> >
> > How would libgcc linking intermix with modules? Would we have to
> > EXPORT_SYMBOL() all functions that libgcc implements? I'm guessing
> > that's varies w/different gcc versions.
>
> If you link in libgcc, all of a sudden you have a whole new class of
> potential problems, don't do it.
>
> All it takes is one of these libgcc libcalls the kernel actually
> references, needing something else in libc, to make this exercise
> futile.
Hrm... I though you linked it in, I must be confusing with another
arch :-) Oh well, if we fail with something pulling bits off libc etc...
we'll see quickly who is the culprit no ?
Ben.
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
From: Benjamin Herrenschmidt @ 2008-05-02 23:27 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev
In-Reply-To: <20080502.144009.147804001.davem@davemloft.net>
On Fri, 2008-05-02 at 14:40 -0700, David Miller wrote:
> From: Kumar Gala <galak@kernel.crashing.org>
> Date: Fri, 2 May 2008 16:28:36 -0500
>
> > Sorry, I meant the gcc patch. I'm not sure if this has been committed
> > to FSF head or not.
>
> If that's the case it would be a good idea to suggest a command line
> option to disable the new out-of-line code generation feature of that
> patch.
>
> But if the stubs it calls are really simple, you can just add
> implementations under arch/powerpc/lib/, and therefore it's
> not such a big deal. This is what we've traditionally done
> with libcalls generated by gcc for runtime support.
My only worry with this is modules.
That is, it would be fairly non-sensical for module code to go through
the trampoline to call those stubs in the kernel (and having to
EXPORT_SYMBOL them).
In the case of those register save stubs, I believe they should really
be linked with the modules.
Ben.
^ permalink raw reply
* Re: function calls from identify_cpu()
From: Benjamin Herrenschmidt @ 2008-05-02 23:29 UTC (permalink / raw)
To: Kevin Diggs; +Cc: linuxppc-dev
In-Reply-To: <481B7CB4.90103@hypersurf.com>
On Fri, 2008-05-02 at 13:42 -0700, Kevin Diggs wrote:
> I added:
>
> int __init iDoNothingUseful(struct cpu_spec *s,struct cpu_spec *t)
> {
> return s-t;
> }
>
> right before the definition of identify_cpu() in cputable.c and:
>
> // (void) (*PTRRELOC(&iDoNothingUseful))(s,t);
> (void) iDoNothingUseful(s,t);
>
> right before the return s; in the match block and it will not boot? Can
> someone please explain what might be going on?
Why are you trying to muck around with that code in the first
place ? :-)
What are you trying to achieve ?
Cheers,
Ben.
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git master branch
From: Paul Mackerras @ 2008-05-02 23:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, akpm, linux-kernel
In-Reply-To: <alpine.LFD.1.10.0805020818440.5994@woody.linux-foundation.org>
Linus Torvalds writes:
> On Fri, 2 May 2008, Paul Mackerras wrote:
> >
> > git pull \
> > git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git master
>
> "Already up-to-date."
>
> Forgot to push?
Yep. :(
Try again now.
Thanks,
Paul.
^ permalink raw reply
* Re: [PATCH v2.6.26] powerpc: Add 8568 PHY workarounds to board code
From: Olof Johansson @ 2008-05-02 23:49 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev
In-Reply-To: <1209751422-25634-1-git-send-email-afleming@freescale.com>
Hi,
On Fri, May 02, 2008 at 01:03:42PM -0500, Andy Fleming wrote:
> +static int __init board_fixups(void)
> +{
> + char phy_id[BUS_ID_SIZE];
> + char *compstrs[2] = {"fsl,gianfar-mdio", "fsl,ucc-mdio"};
> + struct device_node *mdio;
> + struct resource res;
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(compstrs); i++) {
> + mdio = of_find_compatible_node(NULL, NULL, compstrs[i]);
> +
> + of_address_to_resource(mdio, 0, &res);
> + snprintf(phy_id, BUS_ID_SIZE, "%x:%02x", res.start, 1);
> +
> + phy_register_fixup_for_id(phy_id, mpc8568_fixup_125_clock);
> + phy_register_fixup_for_id(phy_id, mpc8568_mds_phy_fixups);
> +
> + /* Register a workaround for errata */
> + snprintf(phy_id, BUS_ID_SIZE, "%x:%02x", res.start, 7);
> + phy_register_fixup_for_id(phy_id, mpc8568_mds_phy_fixups);
> +
> + of_node_put(mdio);
> + }
> +
> + return 0;
> +}
> +arch_initcall(board_fixups);
Are you sure you want to run this workaround on all boards that happen
to be built-in? I.e. shouldn't you be checked for what board you are
running on, since the compatible strings you match on seem generic?
-Olof
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
From: David Miller @ 2008-05-02 23:38 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1209770875.26383.14.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Sat, 03 May 2008 09:27:55 +1000
> That is, it would be fairly non-sensical for module code to go through
> the trampoline to call those stubs in the kernel (and having to
> EXPORT_SYMBOL them).
Oh, I forgot about how far function calls are done on powerpc.
Yes, that will suck.
Is there some way to map all of the modules in the low 32-bits and
thus aovid the trampolines? The powerpc call instruction can cover
4GB like on sparc right?
Actually, I remember there is some linkage register that has
to be setup on powerpc with the code model you guys use, is
that the problem?
^ permalink raw reply
* Re: [PATCH v2.6.26] powerpc: Add 8568 PHY workarounds to board code
From: Andy Fleming @ 2008-05-02 23:43 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20080502234927.GC28587@lixom.net>
On May 2, 2008, at 18:49, Olof Johansson wrote:
> Hi,
>
> On Fri, May 02, 2008 at 01:03:42PM -0500, Andy Fleming wrote:
>> +static int __init board_fixups(void)
>> +{
>> + char phy_id[BUS_ID_SIZE];
>> + char *compstrs[2] = {"fsl,gianfar-mdio", "fsl,ucc-mdio"};
>> + struct device_node *mdio;
>> + struct resource res;
>> + int i;
>> +
>> + for (i = 0; i < ARRAY_SIZE(compstrs); i++) {
>> + mdio = of_find_compatible_node(NULL, NULL, compstrs[i]);
>> +
>> + of_address_to_resource(mdio, 0, &res);
>> + snprintf(phy_id, BUS_ID_SIZE, "%x:%02x", res.start, 1);
>> +
>> + phy_register_fixup_for_id(phy_id, mpc8568_fixup_125_clock);
>> + phy_register_fixup_for_id(phy_id, mpc8568_mds_phy_fixups);
>> +
>> + /* Register a workaround for errata */
>> + snprintf(phy_id, BUS_ID_SIZE, "%x:%02x", res.start, 7);
>> + phy_register_fixup_for_id(phy_id, mpc8568_mds_phy_fixups);
>> +
>> + of_node_put(mdio);
>> + }
>> +
>> + return 0;
>> +}
>> +arch_initcall(board_fixups);
>
> Are you sure you want to run this workaround on all boards that happen
> to be built-in? I.e. shouldn't you be checked for what board you are
> running on, since the compatible strings you match on seem generic?
Shoot. That's a good point. I keep forgetting that just because it's
in mpc85xx_mds.c, doesn't mean it's only being run on that platform.
Alright, I'll resubmit.
>
>
>
> -Olof
^ permalink raw reply
* [PATCH v2] powerpc: Add 8568 PHY workarounds to board code
From: Andy Fleming @ 2008-05-02 23:56 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
The 8568 MDS needs some configuration changes to the PHY in order to
work properly. These are done in the firmware, normally, but Linux
shouldn't need to rely on the firmware running such things (someone
could disable the PHY support in the firmware to save space, for instance).
Signed-off-by: Andy Fleming <afleming@freescale.com>
---
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 119 +++++++++++++++++++++++++++++
1 files changed, 119 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 12f68ab..43a459f 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -32,6 +32,7 @@
#include <linux/fsl_devices.h>
#include <linux/of_platform.h>
#include <linux/of_device.h>
+#include <linux/phy.h>
#include <asm/system.h>
#include <asm/atomic.h>
@@ -56,6 +57,95 @@
#define DBG(fmt...)
#endif
+#define MV88E1111_SCR 0x10
+#define MV88E1111_SCR_125CLK 0x0010
+static int mpc8568_fixup_125_clock(struct phy_device *phydev)
+{
+ int scr;
+ int err;
+
+ /* Workaround for the 125 CLK Toggle */
+ scr = phy_read(phydev, MV88E1111_SCR);
+
+ if (scr < 0)
+ return scr;
+
+ err = phy_write(phydev, MV88E1111_SCR, scr & ~(MV88E1111_SCR_125CLK));
+
+ if (err)
+ return err;
+
+ err = phy_write(phydev, MII_BMCR, BMCR_RESET);
+
+ if (err)
+ return err;
+
+ scr = phy_read(phydev, MV88E1111_SCR);
+
+ if (scr < 0)
+ return err;
+
+ err = phy_write(phydev, MV88E1111_SCR, scr | 0x0008);
+
+ return err;
+}
+
+static int mpc8568_mds_phy_fixups(struct phy_device *phydev)
+{
+ int temp;
+ int err;
+
+ /* Errata */
+ err = phy_write(phydev,29, 0x0006);
+
+ if (err)
+ return err;
+
+ temp = phy_read(phydev, 30);
+
+ if (temp < 0)
+ return temp;
+
+ temp = (temp & (~0x8000)) | 0x4000;
+ err = phy_write(phydev,30, temp);
+
+ if (err)
+ return err;
+
+ err = phy_write(phydev,29, 0x000a);
+
+ if (err)
+ return err;
+
+ temp = phy_read(phydev, 30);
+
+ if (temp < 0)
+ return temp;
+
+ temp = phy_read(phydev, 30);
+
+ if (temp < 0)
+ return temp;
+
+ temp &= ~0x0020;
+
+ err = phy_write(phydev,30,temp);
+
+ if (err)
+ return err;
+
+ /* Disable automatic MDI/MDIX selection */
+ temp = phy_read(phydev, 16);
+
+ if (temp < 0)
+ return temp;
+
+ temp &= ~0x0060;
+ err = phy_write(phydev,16,temp);
+
+ return err;
+}
+
/* ************************************************************************
*
* Setup the architecture
@@ -138,6 +228,35 @@ static void __init mpc85xx_mds_setup_arch(void)
#endif /* CONFIG_QUICC_ENGINE */
}
+
+static int __init board_fixups(void)
+{
+ char phy_id[BUS_ID_SIZE];
+ char *compstrs[2] = {"fsl,gianfar-mdio", "fsl,ucc-mdio"};
+ struct device_node *mdio;
+ struct resource res;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(compstrs); i++) {
+ mdio = of_find_compatible_node(NULL, NULL, compstrs[i]);
+
+ of_address_to_resource(mdio, 0, &res);
+ snprintf(phy_id, BUS_ID_SIZE, "%x:%02x", res.start, 1);
+
+ phy_register_fixup_for_id(phy_id, mpc8568_fixup_125_clock);
+ phy_register_fixup_for_id(phy_id, mpc8568_mds_phy_fixups);
+
+ /* Register a workaround for errata */
+ snprintf(phy_id, BUS_ID_SIZE, "%x:%02x", res.start, 7);
+ phy_register_fixup_for_id(phy_id, mpc8568_mds_phy_fixups);
+
+ of_node_put(mdio);
+ }
+
+ return 0;
+}
+machine_arch_initcall(mpc85xx_mds, board_fixups);
+
static struct of_device_id mpc85xx_ids[] = {
{ .type = "soc", },
{ .compatible = "soc", },
--
1.5.4.GIT
^ permalink raw reply related
* Re: [PATCH v2.6.26] powerpc: Fix a bunch of sparse warnings in the qe_lib
From: Andy Fleming @ 2008-05-02 23:59 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev list, Tabi Timur
In-Reply-To: <481B5870.2010000@freescale.com>
On May 2, 2008, at 13:07, Scott Wood wrote:
> Andy Fleming wrote:
>> + struct qe_iram __iomem iram; /* I-RAM */
>> + struct qe_ic_regs __iomem ic; /* Interrupt Controller */
>> + struct cp_qe __iomem cp; /* Communications Processor */
>> + struct qe_mux __iomem qmx; /* QE Multiplexer */
>> + struct qe_timers __iomem qet; /* QE Timers */
>> + struct spi __iomem spi[0x2]; /* spi */
>> + struct mcc __iomem mcc; /* mcc */
>> + struct qe_brg __iomem brg; /* brg */
>> + struct usb_ctlr __iomem usb; /* USB */
>> + struct si1 __iomem si1; /* SI */
>
> Why not just set __iomem on qe_immap references?
Does that work? I'm not quite clear on how the scope for __iomem works.
I can definitely do that, though.
^ permalink raw reply
* Re: [PATCH v2.6.26] powerpc: Fix a bunch of sparse warnings in the qe_lib
From: Andy Fleming @ 2008-05-03 0:00 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <481B5F59.8020201@freescale.com>
On May 2, 2008, at 13:37, Timur Tabi wrote:
> Andy Fleming wrote:
>
>> int ucc_fast_init(struct ucc_fast_info * uf_info, struct
>> ucc_fast_private ** uccf_ret)
>> {
>> struct ucc_fast_private *uccf;
>> - struct ucc_fast *uf_regs;
>> + struct ucc_fast __iomem *uf_regs;
>> u32 gumr;
>> int ret;
>>
>> @@ -216,10 +216,10 @@ int ucc_fast_init(struct ucc_fast_info *
>> uf_info, struct ucc_fast_private ** ucc
>> uccf->stopped_tx = 0;
>> uccf->stopped_rx = 0;
>> uf_regs = uccf->uf_regs;
>> - uccf->p_ucce = (u32 *) & (uf_regs->ucce);
>> - uccf->p_uccm = (u32 *) & (uf_regs->uccm);
>> + uccf->p_ucce = (u32 __iomem *) & (uf_regs->ucce);
>> + uccf->p_uccm = (u32 __iomem *) & (uf_regs->uccm);
>
> Since you've already made uf_regs into an __iomem pointer, do you
> really need to
> cast it?
Ah, yes. That's probably leftover from when uf_regs wasn't __iomem.
>
> And please remember to CC: me on any QE library patches.
Can do.
Andy
^ 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