* Re: MODPOST section mismatches
From: Steve Heflin @ 2008-02-22 23:07 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <20080222163625.29433d12@weaponx>
At 05:36 PM 2/22/2008, you wrote:
>On Fri, 22 Feb 2008 17:26:52 -0500
>Steve Heflin <sheflin@newagemicro.com> wrote:
>
> > FLAT_MEM is one of the configuration options:
> > CONFIG_ARCH_FLATMEM_ENABLE=y
>
>That has to do with NUMA stuff. It really doesn't have much bearing on
>the section warnings.
ah, thanks for setting me straight. I thought it meant that
everything existed in a flat address space and existed in memory at
the same time, and therefore the different section warnings might not apply.
^ permalink raw reply
* Re: MODPOST section mismatches
From: Josh Boyer @ 2008-02-22 22:36 UTC (permalink / raw)
To: Steve Heflin; +Cc: linuxppc-embedded
In-Reply-To: <20080222222637.C82EADDF0F@ozlabs.org>
On Fri, 22 Feb 2008 17:26:52 -0500
Steve Heflin <sheflin@newagemicro.com> wrote:
> FLAT_MEM is one of the configuration options:
> CONFIG_ARCH_FLATMEM_ENABLE=y
That has to do with NUMA stuff. It really doesn't have much bearing on
the section warnings.
josh
^ permalink raw reply
* Re: How to dynamically disable/enable CPU features?
From: Benjamin Herrenschmidt @ 2008-02-22 22:32 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, Milton Miller
In-Reply-To: <20080222190531.103050@gmx.net>
> The flag is in POSSIBLE. I now use this code in the platform probe
> function to nop out the code affected by the flag:
>
> cur_cpu_spec->cpu_features &= ~CPU_FTR_NEED_COHERENT;
> /* Patch out unwanted feature. */
> do_feature_fixups(cur_cpu_spec->cpu_features,
> PTRRELOC(&__start___ftr_fixup),
> PTRRELOC(&__stop___ftr_fixup));
>
> It seems to work so far, but I would like to know if this is the right
> way to do it, or if calling do_feature_fixups() more than once can have
> any side effects.
It's a bit hairy... Things -could- have been nop'ed out by the first
call as a result of CPU_FTR_NEED_COHERENT being set and the second
call will not be able to put them back in... now that may not be the
case (depends what kind of patching is done with that flag) and so
'happen' to work for this specific bit but it isn't a nice solution...
A better long term approach is to look at moving the fixup to after
the machine probe() after carefully checking whether that can cause
any problem...
Ben.
^ permalink raw reply
* Re: How to dynamically disable/enable CPU features?
From: Benjamin Herrenschmidt @ 2008-02-22 22:26 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20080221200758.62940@gmx.net>
On Thu, 2008-02-21 at 21:07 +0100, Gerhard Pircher wrote:
> Hi,
>
> I'm wondering how to disable or enable CPU features based on the board the
> kernel is running on. In my case I want to disable the
> CPU_FTR_NEED_COHERENT flag for 74xx CPUs, because it locks up the machine.
> I tried to clear the flag in the platform's *_probe() function with the
> following code:
>
> cur_cpu_spec->cpu_features &= ~CPU_FTR_NEED_COHERENT;
That works on 64 bits but unfortunately not on 32 bits. This is a
longstanding issue that we need to fix. ie. we need to move the
fixups later in the boot process (if possible put them in the
same place for 32 and 64 bits), though that needs to be done very
carefully, making sure nothing that requires those fixups ends up
happening before they happen as a result of the move.
Ben.
^ permalink raw reply
* Re: MODPOST section mismatches
From: Steve Heflin @ 2008-02-22 22:26 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <20080222145224.7349cf36@weaponx>
FLAT_MEM is one of the configuration options:
CONFIG_ARCH_FLATMEM_ENABLE=y
At 03:52 PM 2/22/2008, Josh Boyer wrote:
>On Fri, 22 Feb 2008 11:12:47 -0500
>Steve Heflin <sheflin@newagemicro.com> wrote:
>
> > To reproduce the problem and see the details on section mismatches:
> >
> > make ARCH=powerpc sequoia_defconfig
> >
> > make ARCH=powerpc CONFIG_DEBUG_SECTION_MISMATCH=y
>
>All of those warnings are in drivers or common code. And yes, they
>should eventually all be fixed.
>
> > >After modifying the make launch to include the recommended option
> > >shown above, I see that the section mismatch warning is due to data
> > >structures containing the address of initialization modules which
> > >have the __init attribute. Since the memory model is FLAT, is
> this a problem?
>
>What do you mean by "the memory model is FLAT"?
>
>josh
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] powerpc: Get rid of invalid shifts in math-emu
From: Benjamin Herrenschmidt @ 2008-02-22 22:24 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <410c322e7d7e4b9a420a7209f12dfbd105583f6f.1203708822.git.segher@kernel.crashing.org>
On Fri, 2008-02-22 at 21:01 +0100, Segher Boessenkool wrote:
> Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
> ---
Amen !
_However_ there are significant code changes in there, and I don't
actually understand that code (well, I admit I haven't tried),
so it could definitely use a bit of a commit message explaining
the rationale (you are removing a lot of stuff), and maybe somebody
can run a few tests to make sure things work fine ?
Ben.
> arch/powerpc/math-emu/op-2.h | 75 ++++++++++++++++-------------------------
> 1 files changed, 29 insertions(+), 46 deletions(-)
>
> diff --git a/arch/powerpc/math-emu/op-2.h b/arch/powerpc/math-emu/op-2.h
> index 7d6f17c..16d3e3c 100644
> --- a/arch/powerpc/math-emu/op-2.h
> +++ b/arch/powerpc/math-emu/op-2.h
> @@ -11,58 +11,43 @@
>
> #define _FP_FRAC_SLL_2(X,N) \
> do { \
> - if ((N) < _FP_W_TYPE_SIZE) \
> + int n = (N); \
> + if (n >= _FP_W_TYPE_SIZE) \
> { \
> - if (__builtin_constant_p(N) && (N) == 1) \
> - { \
> - X##_f1 = X##_f1 + X##_f1 + (((_FP_WS_TYPE)(X##_f0)) < 0); \
> - X##_f0 += X##_f0; \
> - } \
> - else \
> - { \
> - X##_f1 = X##_f1 << (N) | X##_f0 >> (_FP_W_TYPE_SIZE - (N)); \
> - X##_f0 <<= (N); \
> - } \
> - } \
> - else \
> - { \
> - X##_f1 = X##_f0 << ((N) - _FP_W_TYPE_SIZE); \
> + X##_f1 = X##_f0; \
> X##_f0 = 0; \
> + n -= _FP_W_TYPE_SIZE; \
> } \
> + X##_f1 = X##_f1 << n | X##_f0 >> (_FP_W_TYPE_SIZE - n - 1) >> 1; \
> + X##_f0 <<= n; \
> } while (0)
>
> #define _FP_FRAC_SRL_2(X,N) \
> do { \
> - if ((N) < _FP_W_TYPE_SIZE) \
> - { \
> - X##_f0 = X##_f0 >> (N) | X##_f1 << (_FP_W_TYPE_SIZE - (N)); \
> - X##_f1 >>= (N); \
> - } \
> - else \
> + int n = (N); \
> + if (n >= _FP_W_TYPE_SIZE) \
> { \
> - X##_f0 = X##_f1 >> ((N) - _FP_W_TYPE_SIZE); \
> + X##_f0 = X##_f1; \
> X##_f1 = 0; \
> + n -= _FP_W_TYPE_SIZE; \
> } \
> + X##_f0 = X##_f0 >> n | X##_f1 << (_FP_W_TYPE_SIZE - n - 1) << 1; \
> + X##_f1 >>= n; \
> } while (0)
>
> /* Right shift with sticky-lsb. */
> #define _FP_FRAC_SRS_2(X,N,sz) \
> do { \
> - if ((N) < _FP_W_TYPE_SIZE) \
> - { \
> - X##_f0 = (X##_f1 << (_FP_W_TYPE_SIZE - (N)) | X##_f0 >> (N) | \
> - (__builtin_constant_p(N) && (N) == 1 \
> - ? X##_f0 & 1 \
> - : (X##_f0 << (_FP_W_TYPE_SIZE - (N))) != 0)); \
> - X##_f1 >>= (N); \
> - } \
> - else \
> + int n = (N); \
> + if (n >= _FP_W_TYPE_SIZE) \
> { \
> - X##_f0 = (X##_f1 >> ((N) - _FP_W_TYPE_SIZE) | \
> - (((X##_f1 << (2 * _FP_W_TYPE_SIZE - (N))) | \
> - X##_f0) != 0)); \
> + X##_f0 = X##_f1; \
> X##_f1 = 0; \
> + n -= _FP_W_TYPE_SIZE; \
> } \
> + X##_f0 = (X##_f1 << (_FP_W_TYPE_SIZE - n - 1) << 1 | X##_f0 >> n | \
> + ((X##_f0 << (_FP_W_TYPE_SIZE - n - 1) << 1) != 0)); \
> + X##_f1 >>= n; \
> } while (0)
>
> #define _FP_FRAC_ADDI_2(X,I) \
> @@ -398,20 +383,18 @@
>
> #define _FP_FRAC_ASSEMBLE_2(r, X, rsize) \
> do { \
> - if (rsize <= _FP_W_TYPE_SIZE) \
> - r = X##_f0; \
> - else \
> - { \
> - r = X##_f1; \
> - r <<= _FP_W_TYPE_SIZE; \
> - r += X##_f0; \
> - } \
> + r = X##_f1; \
> + r <<= _FP_W_TYPE_SIZE - 1; \
> + r <<= 1; \
> + r += X##_f0; \
> } while (0)
>
> -#define _FP_FRAC_DISASSEMBLE_2(X, r, rsize) \
> - do { \
> - X##_f0 = r; \
> - X##_f1 = (rsize <= _FP_W_TYPE_SIZE ? 0 : r >> _FP_W_TYPE_SIZE); \
> +#define _FP_FRAC_DISASSEMBLE_2(X, r, rsize) \
> + do { \
> + X##_f0 = r; \
> + r >>= _FP_W_TYPE_SIZE - 1; \
> + r >>= 1; \
> + X##_f1 = r; \
> } while (0)
>
> /*
^ permalink raw reply
* RE: Xilinx PowerPC
From: Stephen Neuendorffer @ 2008-02-22 22:05 UTC (permalink / raw)
To: dhlii; +Cc: linuxppc-embedded
In-Reply-To: <47BF43CF.5050102@dlasys.lcl>
> -----Original Message-----
> From: David H. Lynch Jr. [mailto:dhlii@dlasys.lcl]
> Sent: Friday, February 22, 2008 1:51 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-embedded
> Subject: Re: Xilinx PowerPC
>=20
> Stephen Neuendorffer wrote:
> >
> >> -----Original Message-----
> >> From:
linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
> >>
> > [mailto:linuxppc-embedded-
> >
> >> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of David =
H.
> >>
> > Lynch Jr.
> >
> >> Sent: Wednesday, February 20, 2008 10:59 PM
> >> To: Grant Likely; linuxppc-embedded
> >> Subject: Xilinx PowerPC
> >>
> >>
> >> So when you have Xilinx under powerpc working, do we pull it
from
> >>
> > your
> >
> >> git tree or the xilinx one ?
> >>
> >> Will there be an announcement ?
> >>
> >> How about a one paragraph getting started guide to moving a
xilinx
> >> ppc bsp to
> >> xilinx powerpc.
> >>
> >> Like ?
> >>
> >> step 1).
> >> Generate a dts - gen-mhs-devicetree ?
> >> And pass it to through your boot loader to Linux ?
> >>
> >
> > http://git.xilinx.com/gen-mhs-devtree.git contains two utilities for
> > generating device trees from EDK projects. The older option is a
python
> > script, originally written by Grant. The newer (and probably more
> > mature at this point) option is an EDK BSP generator for u-boot,
> > originally written by Michal Simek. Preferably this gets passed
from a
> > uboot, although it's also possible to compile it into the kernel.
> > Currently, the uboot option is somewhat annoying because there's not
a
> > good surefire way for getting uboot up and running on an EDK design.
> > (Unfortunately, the EDK BSP generator is incomplete, and the uboot
> > support for virtex needs some work to get it integrated as well).
> >
> Thanks, I found the python script. Please do not fixate on u-boot.
> it is not an option for us. We have our own bootloader.
> it handles .elf files, fits in 16k or BRAM and just starts when
the
> FPGA is loaded. We will have to added device tree support to it.
> I had thought you were talking about appending the device tree to
> the bitfile.
> That sounds like a really good option for us.
>=20
> We also really don't have a great interest in the EDK BSP
generator.
> We have our own BSP's for our cards for both GHS and Linux.
> Except the rare instances - like right now while we are
> transitioning to the
> newer LL_TEMAC, we use normal linux drivers, either from the
> existing kernel
> trees, or written inhouse.
The BSP generator is significantly different from the normal EDK Linux
BSP. The key thing is that the device tree generated by the python
script is necessarily incomplete, since it does not have information
about default parameter values which appear in the core definitions. I
would *highly recommend* using the uboot bsp to get a device tree. You
can always ignore anything else that it does (or hack the code to your
hearts content to do what you want, such as incorporating it into your
own BSP).
> >> Step 2).
> >> the code in arch/powerpc/???? is the devicetree
equvalent
> >>
> > to
> >
> >> arch/ppc/platforms/4xx/xilinx_ml410.c
> >>
> > http://git.xilinx.com/linux-2.6-xlnx.git contains a preliminary stab
at
> > the bootcode for Virtex. I've been using this for a while with
> > ARCH=3Dpowerpc. There isn't really much need for board specific
platform
> > code: This should (I think) be handled by the device tree.
> So I have a device tree for my card somehow. Presumably I need the
> binary form.
> My bootloader needs to pass a pointer to a copy in memory to
Linux.
>=20
> How do I config the linux from your git tree ?
> Do I just config for a generic Xilinx card and the device tree
> handles the rest ?
Essentially. There is a generic virtex configuration option.
> Next we have a hosted pseudo serial port. Devict Trees could cope
> with that.
> But We also have early serial support for both it and Uartlite,
> Also our Linux BSP and UartLite drivers will work without a PIC.
> And would even do ethernet (badly) with the earlier LL_TEMAC
without
> DMA and interrupts.
> So do I modify the device tree to choose a different uartlite
driver ?
> I had to put a fair amount of patches in to support early serial
with
> non-8250 serial ports. Do I have to patch your generic xilinx BSP
to
> deal with that ?
Early serial on uartlite is works fine. You have to add an explicit
reference to the uartlite to get it to work. Early serial on uart16550
doesn't work yet, because the device has an unusual spacing between the
registers.
> Please do not develop a u-boot only solution.
I don't believe Linux will never *require* uboot.
> Just to clarify, am I correct in presuming that say the uartlite
> driver in the
> xilinx git tree will handle either the arch/ppc style platform
> device initialization
> or the arch/powerpc devicetree initialization ?
Yes. drivers are capable of probing both the platform bus and the of
bus. It is expected that each device is advertised on only one. In
general, ppc will advertise platform devices and powerpc will advertise
of devices.
> Is there some means of doing a phased transition ?
> Can I lift the device tree BSP setup code into my own BSP,
> and then remove the platform device code peice by peice as things
work ?
probably, although changing the drivers is not challenging, as long as
all the information you need is in the device tree.
> Is there something magical about being physically located in
> arch/ppc or arch/powerpc ?
Well, ppc doesn't support of/device trees. All of the of bus stuff is
#ifdef'd out of the drivers.
Steve
^ permalink raw reply
* Re: [PATCH] [POWERPC] AMCC Kilauea (405EX): Disable EMAC loopback mode
From: Stefan Roese @ 2008-02-22 21:54 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1203715656.6976.7.camel@pasglop>
On Friday 22 February 2008, 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.
Yes. Valentines patches are a first step to this.
> I need to work on that.
That would be great. Thanks.
BTW: Any news on the generic phy-lib plans for ibm_newemac?
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] [POWERPC] AMCC Kilauea (405EX): Disable EMAC loopback mode
From: Stefan Roese @ 2008-02-22 21:49 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080222143621.0579729b@weaponx>
On Friday 22 February 2008, Josh Boyer wrote:
> On Fri, 22 Feb 2008 09:32:12 +0100
>
> Stefan Roese <sr@denx.de> 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.
>
> Why isn't this done in U-Boot? Or is it done if the network interface
> is used?
Correct. It's only done upon EMAC usage in U-Boot. So when booting completely
from FLASH, EMAC in Linux is not working.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] [POWERPC] AMCC Kilauea (405EX): Disable EMAC loopback mode
From: Benjamin Herrenschmidt @ 2008-02-22 21:27 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1203669132-9385-1-git-send-email-sr@denx.de>
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.
I need to work on that.
Ben.
> Thanks.
>
> arch/powerpc/platforms/40x/kilauea.c | 11 ++++++++++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/40x/kilauea.c b/arch/powerpc/platforms/40x/kilauea.c
> index f9206a7..b5456cc 100644
> --- a/arch/powerpc/platforms/40x/kilauea.c
> +++ b/arch/powerpc/platforms/40x/kilauea.c
> @@ -1,7 +1,7 @@
> /*
> * Kilauea board specific routines
> *
> - * Copyright 2007 DENX Software Engineering, Stefan Roese <sr@denx.de>
> + * Copyright 2007-2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
> *
> * Based on the Walnut code by
> * Josh Boyer <jwboyer@linux.vnet.ibm.com>
> @@ -20,6 +20,8 @@
> #include <asm/time.h>
> #include <asm/uic.h>
> #include <asm/pci-bridge.h>
> +#include <asm/dcr.h>
> +#include <asm/dcr-regs.h>
>
> static __initdata struct of_device_id kilauea_of_bus[] = {
> { .compatible = "ibm,plb4", },
> @@ -45,6 +47,13 @@ static int __init kilauea_probe(void)
>
> ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
>
> + /*
> + * 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 deafult.
> + */
> + mtdcri(SDR0, SDR0_MFR, mfdcri(SDR0, SDR0_MFR) & ~0x0c000000);
> +
> return 1;
> }
>
^ permalink raw reply
* Re: MODPOST section mismatches
From: Josh Boyer @ 2008-02-22 20:52 UTC (permalink / raw)
To: Steve Heflin; +Cc: linuxppc-embedded
In-Reply-To: <20080222164210.48628DE0A9@ozlabs.org>
On Fri, 22 Feb 2008 11:12:47 -0500
Steve Heflin <sheflin@newagemicro.com> wrote:
> To reproduce the problem and see the details on section mismatches:
>
> make ARCH=powerpc sequoia_defconfig
>
> make ARCH=powerpc CONFIG_DEBUG_SECTION_MISMATCH=y
All of those warnings are in drivers or common code. And yes, they
should eventually all be fixed.
> >After modifying the make launch to include the recommended option
> >shown above, I see that the section mismatch warning is due to data
> >structures containing the address of initialization modules which
> >have the __init attribute. Since the memory model is FLAT, is this a problem?
What do you mean by "the memory model is FLAT"?
josh
^ permalink raw reply
* Re: [RFC][PATCH] PowerPC 4xx: ibm_newemac 440GX phy clock workaround.
From: Josh Boyer @ 2008-02-22 20:51 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <47BF1F6E.8050805@ru.mvista.com>
On Fri, 22 Feb 2008 22:15:58 +0300
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> Benjamin Herrenschmidt wrote:
> > On Thu, 2008-02-21 at 17:46 +0300, Valentine Barshak wrote:
> >> The PowerPC 440GX Taishan board fails to reset EMAC3 (reset timeout error)
> >> and because of that it can't 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 main problem is that will force clock on -all- EMACs ... which can
> > be a problem as they can be in probe at the same time. Might be worth
> > also adding a global mutex around that block.
>
> I've tried to move clock selection inside the global emac_phy_map_lock
> block. That works fine for 440GX.
>
> >
> > Also, would you mind having a look at the other workaround for the
> > similar bug?
>
> OK, I'll add 440EP/440GR workaround, but I'm not sure if we need it for
> the currently supported boards. The older ibm_emac driver also has a
> workaround for it on 405ep. This part uses CPC0 dcr registers. So, looks
> like we'll have to search device tree for the CPC0 entry in ibm_newemac
> driver, map dcr registers and select clock with dcr_read/write calls.
> I've omitted the 405ep part, since there's currently no board supported.
I'll be doing a 405EP port for .26.
josh
^ permalink raw reply
* Re: [RFC][PATCH] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaround
From: Josh Boyer @ 2008-02-22 20:49 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20080222192817.GA26211@ru.mvista.com>
On Fri, 22 Feb 2008 22:28:17 +0300
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> This patch adds ibm_newemac phy clock workaround for 440EP/440GR emacs.
> The code is based on the previous ibm_emac driver stuff. The 440EP/440GR
> allows controlling each EMAC clock spearately as opposed to global clock
> selection for 440GX.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> ---
[snip]
> +/* 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)
> +{
> + if (emac_has_feature(dev, EMAC_FTR_440EP_PHY_CLK_FIX)) {
> + unsigned long flags;
> +
> + local_irq_save(flags);
> + mtdcri(SDR0, SDR0_MFR, mfdcri(SDR0, SDR0_MFR) |
> + (SDR0_MFR_ECS >> dev->cell_index));
> + local_irq_restore(flags);
> + }
> +}
> +
> +static inline void emac_rx_clk_default(struct emac_instance *dev)
> +{
> + if (emac_has_feature(dev, EMAC_FTR_440EP_PHY_CLK_FIX)) {
> + unsigned long flags;
> +
> + local_irq_save(flags);
> + mtdcri(SDR0, SDR0_MFR, mfdcri(SDR0, SDR0_MFR) &
> + ~(SDR0_MFR_ECS >> dev->cell_index));
> + local_irq_restore(flags);
> + }
> +}
Why did you do local_irq_save in these two functions? mtdcri already
does spin_lock_irqsave...
josh
^ permalink raw reply
* Re: NETdev driver question xxxx_type_trans()
From: Andy Fleming @ 2008-02-22 20:39 UTC (permalink / raw)
To: rmcguire; +Cc: linuxppc-embedded
In-Reply-To: <000001c87591$2b5a8740$6405a8c0@absolut>
On Feb 22, 2008, at 14:26, Russell McGuire wrote:
> All,
>
> A general and specific question on the behavior of netdev devices =20
> before received sk_buff(s) get passed up to the kernel.
>
> I am almost done creating / testing an HDLC device driver for the =20
> 83xx.
>
>
> I have it working at a low level and was printing out skb_bufs =20
> before and after TX and RX, to ensure data integrity.
>
> Due to me having the print_skbbuf, AFTER the hdlc_type_trans(skb, =20
> ndev).
>
> I thought I was continuously losing 14 bytes of data, after a =20
> little digging I realized that the hdlc_type_trans() call
>
> was shifting the skb->data pointer forward by 14 bytes. ????????
>
> Is this corresponding to a 14 byte pad that the kernel stack adds =20
> before it sends it down?
>
> And why isn=92t the data length being shortened as a result after I =20=
> call hdlc_type_trans?
>
> Anyway=85 I guess I am confused as to what this function was intended =20=
> for, I see there are other calls for eth_type_trans, so I imagine =20
> their usage is similar.
>
> When are they needed?
>
They move the data pointer to point to the start of the L2 header. =20
There's no need for the kernel to see the L1 header, and it doesn't =20
expect it to be there when it looks at the skb.
You shouldn't be using it for TX packets. For TX, I believe the =20
kernel takes care of setting up the L1 header, though I'm not =20
familiar with the kernel's hdlc support.
Andy=
^ permalink raw reply
* [PATCH] powerpc: Get rid of invalid shifts in math-emu
From: Segher Boessenkool @ 2008-02-22 20:01 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
---
arch/powerpc/math-emu/op-2.h | 75 ++++++++++++++++-------------------------
1 files changed, 29 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/math-emu/op-2.h b/arch/powerpc/math-emu/op-2.h
index 7d6f17c..16d3e3c 100644
--- a/arch/powerpc/math-emu/op-2.h
+++ b/arch/powerpc/math-emu/op-2.h
@@ -11,58 +11,43 @@
#define _FP_FRAC_SLL_2(X,N) \
do { \
- if ((N) < _FP_W_TYPE_SIZE) \
+ int n = (N); \
+ if (n >= _FP_W_TYPE_SIZE) \
{ \
- if (__builtin_constant_p(N) && (N) == 1) \
- { \
- X##_f1 = X##_f1 + X##_f1 + (((_FP_WS_TYPE)(X##_f0)) < 0); \
- X##_f0 += X##_f0; \
- } \
- else \
- { \
- X##_f1 = X##_f1 << (N) | X##_f0 >> (_FP_W_TYPE_SIZE - (N)); \
- X##_f0 <<= (N); \
- } \
- } \
- else \
- { \
- X##_f1 = X##_f0 << ((N) - _FP_W_TYPE_SIZE); \
+ X##_f1 = X##_f0; \
X##_f0 = 0; \
+ n -= _FP_W_TYPE_SIZE; \
} \
+ X##_f1 = X##_f1 << n | X##_f0 >> (_FP_W_TYPE_SIZE - n - 1) >> 1; \
+ X##_f0 <<= n; \
} while (0)
#define _FP_FRAC_SRL_2(X,N) \
do { \
- if ((N) < _FP_W_TYPE_SIZE) \
- { \
- X##_f0 = X##_f0 >> (N) | X##_f1 << (_FP_W_TYPE_SIZE - (N)); \
- X##_f1 >>= (N); \
- } \
- else \
+ int n = (N); \
+ if (n >= _FP_W_TYPE_SIZE) \
{ \
- X##_f0 = X##_f1 >> ((N) - _FP_W_TYPE_SIZE); \
+ X##_f0 = X##_f1; \
X##_f1 = 0; \
+ n -= _FP_W_TYPE_SIZE; \
} \
+ X##_f0 = X##_f0 >> n | X##_f1 << (_FP_W_TYPE_SIZE - n - 1) << 1; \
+ X##_f1 >>= n; \
} while (0)
/* Right shift with sticky-lsb. */
#define _FP_FRAC_SRS_2(X,N,sz) \
do { \
- if ((N) < _FP_W_TYPE_SIZE) \
- { \
- X##_f0 = (X##_f1 << (_FP_W_TYPE_SIZE - (N)) | X##_f0 >> (N) | \
- (__builtin_constant_p(N) && (N) == 1 \
- ? X##_f0 & 1 \
- : (X##_f0 << (_FP_W_TYPE_SIZE - (N))) != 0)); \
- X##_f1 >>= (N); \
- } \
- else \
+ int n = (N); \
+ if (n >= _FP_W_TYPE_SIZE) \
{ \
- X##_f0 = (X##_f1 >> ((N) - _FP_W_TYPE_SIZE) | \
- (((X##_f1 << (2 * _FP_W_TYPE_SIZE - (N))) | \
- X##_f0) != 0)); \
+ X##_f0 = X##_f1; \
X##_f1 = 0; \
+ n -= _FP_W_TYPE_SIZE; \
} \
+ X##_f0 = (X##_f1 << (_FP_W_TYPE_SIZE - n - 1) << 1 | X##_f0 >> n | \
+ ((X##_f0 << (_FP_W_TYPE_SIZE - n - 1) << 1) != 0)); \
+ X##_f1 >>= n; \
} while (0)
#define _FP_FRAC_ADDI_2(X,I) \
@@ -398,20 +383,18 @@
#define _FP_FRAC_ASSEMBLE_2(r, X, rsize) \
do { \
- if (rsize <= _FP_W_TYPE_SIZE) \
- r = X##_f0; \
- else \
- { \
- r = X##_f1; \
- r <<= _FP_W_TYPE_SIZE; \
- r += X##_f0; \
- } \
+ r = X##_f1; \
+ r <<= _FP_W_TYPE_SIZE - 1; \
+ r <<= 1; \
+ r += X##_f0; \
} while (0)
-#define _FP_FRAC_DISASSEMBLE_2(X, r, rsize) \
- do { \
- X##_f0 = r; \
- X##_f1 = (rsize <= _FP_W_TYPE_SIZE ? 0 : r >> _FP_W_TYPE_SIZE); \
+#define _FP_FRAC_DISASSEMBLE_2(X, r, rsize) \
+ do { \
+ X##_f0 = r; \
+ r >>= _FP_W_TYPE_SIZE - 1; \
+ r >>= 1; \
+ X##_f1 = r; \
} while (0)
/*
--
1.5.3.4.208.g805a
^ permalink raw reply related
* Re: [PATCH] [POWERPC] AMCC Kilauea (405EX): Disable EMAC loopback mode
From: Josh Boyer @ 2008-02-22 20:36 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1203669132-9385-1-git-send-email-sr@denx.de>
On Fri, 22 Feb 2008 09:32:12 +0100
Stefan Roese <sr@denx.de> 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.
Why isn't this done in U-Boot? Or is it done if the network interface
is used? I know I've tftp'd a kernel onto my 405EXr board, so I'm
slightly confused why this is needed in the kernel.
Aside from that, I'm OK with it living in the platform code for Kilauea
(an Haleakala by inheritance). Particularly given the fact that this
should be fixing in U-Boot for any further boards that use 405EX(r)...
right?
josh
^ permalink raw reply
* NETdev driver question xxxx_type_trans()
From: Russell McGuire @ 2008-02-22 20:26 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 949 bytes --]
All,
A general and specific question on the behavior of netdev devices before
received sk_buff(s) get passed up to the kernel.
I am almost done creating / testing an HDLC device driver for the 83xx.
I have it working at a low level and was printing out skb_bufs before and
after TX and RX, to ensure data integrity.
Due to me having the print_skbbuf, AFTER the hdlc_type_trans(skb, ndev).
I thought I was continuously losing 14 bytes of data, after a little digging
I realized that the hdlc_type_trans() call
was shifting the skb->data pointer forward by 14 bytes. ????????
Is this corresponding to a 14 byte pad that the kernel stack adds before it
sends it down?
And why isn't the data length being shortened as a result after I call
hdlc_type_trans?
Anyway. I guess I am confused as to what this function was intended for, I
see there are other calls for eth_type_trans, so I imagine their usage is
similar.
When are they needed?
-Russ
[-- Attachment #2: Type: text/html, Size: 7130 bytes --]
^ permalink raw reply
* [RFC][PATCH] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaround
From: Valentine Barshak @ 2008-02-22 19:28 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1203634340.10422.203.camel@pasglop>
This patch adds ibm_newemac phy clock workaround for 440EP/440GR emacs.
The code is based on the previous ibm_emac driver stuff. The 440EP/440GR
allows controlling each EMAC clock spearately as opposed to global clock
selection for 440GX.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
drivers/net/ibm_newemac/core.c | 46 +++++++++++++++++++++++++++++++++++++++--
drivers/net/ibm_newemac/core.h | 6 ++++-
2 files changed, 49 insertions(+), 3 deletions(-)
diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/core.c linux-2.6/drivers/net/ibm_newemac/core.c
--- linux-2.6.orig/drivers/net/ibm_newemac/core.c 2008-02-22 20:56:56.000000000 +0300
+++ linux-2.6/drivers/net/ibm_newemac/core.c 2008-02-22 20:55:10.000000000 +0300
@@ -129,10 +129,41 @@ 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)
+{
+ if (emac_has_feature(dev, EMAC_FTR_440EP_PHY_CLK_FIX)) {
+ unsigned long flags;
+
+ local_irq_save(flags);
+ mtdcri(SDR0, SDR0_MFR, mfdcri(SDR0, SDR0_MFR) |
+ (SDR0_MFR_ECS >> dev->cell_index));
+ local_irq_restore(flags);
+ }
+}
+
+static inline void emac_rx_clk_default(struct emac_instance *dev)
+{
+ if (emac_has_feature(dev, EMAC_FTR_440EP_PHY_CLK_FIX)) {
+ unsigned long flags;
+
+ local_irq_save(flags);
+ mtdcri(SDR0, SDR0_MFR, mfdcri(SDR0, SDR0_MFR) &
+ ~(SDR0_MFR_ECS >> dev->cell_index));
+ local_irq_restore(flags);
+ }
+}
+
/* PHY polling intervals */
#define PHY_POLL_LINK_ON HZ
#define PHY_POLL_LINK_OFF (HZ / 5)
@@ -1089,9 +1120,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;
}
@@ -1169,6 +1202,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);
@@ -1181,6 +1215,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);
@@ -2325,9 +2360,12 @@ 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 */
+ /* EMAC PHY clock workaround */
if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX))
+ /* Enable internal clock source */
mtdcri(SDR0, SDR0_MFR, mfdcri(SDR0, SDR0_MFR) | SDR0_MFR_ECS);
+ else
+ emac_rx_clk_tx(dev);
/* Configure EMAC with defaults so we can at least use MDIO
* This is needed mostly for 440GX
@@ -2495,6 +2533,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 */
diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/core.h linux-2.6/drivers/net/ibm_newemac/core.h
--- linux-2.6.orig/drivers/net/ibm_newemac/core.h 2008-02-22 20:56:56.000000000 +0300
+++ linux-2.6/drivers/net/ibm_newemac/core.h 2008-02-22 20:56:38.000000000 +0300
@@ -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
* [RFC][PATCH] ibm_newemac: PowerPC 440GX EMAC PHY clock workaround
From: Valentine Barshak @ 2008-02-22 19:24 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1203634340.10422.203.camel@pasglop>
The PowerPC 440GX Taishan board fails to reset EMAC3 (reset timeout error)
and because of that it can't 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.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
drivers/net/ibm_newemac/core.c | 16 +++++++++++++++-
drivers/net/ibm_newemac/core.h | 8 ++++++--
2 files changed, 21 insertions(+), 3 deletions(-)
diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/core.c linux-2.6/drivers/net/ibm_newemac/core.c
--- linux-2.6.orig/drivers/net/ibm_newemac/core.c 2008-02-22 19:56:26.000000000 +0300
+++ linux-2.6/drivers/net/ibm_newemac/core.c 2008-02-22 20:38:47.000000000 +0300
@@ -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"
@@ -2323,6 +2325,10 @@ 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 */
+ if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX))
+ mtdcri(SDR0, SDR0_MFR, mfdcri(SDR0, SDR0_MFR) | SDR0_MFR_ECS);
+
/* Configure EMAC with defaults so we can at least use MDIO
* This is needed mostly for 440GX
*/
@@ -2355,6 +2361,11 @@ static int __devinit emac_init_phy(struc
if (!emac_mii_phy_probe(&dev->phy, i))
break;
}
+
+ /* Enable external clock source */
+ if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX))
+ mtdcri(SDR0, SDR0_MFR, mfdcri(SDR0, SDR0_MFR) & ~SDR0_MFR_ECS);
+
mutex_unlock(&emac_phy_map_lock);
if (i == 0x20) {
printk(KERN_WARNING "%s: can't find PHY!\n", np->full_name);
@@ -2480,8 +2491,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))
diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/core.h linux-2.6/drivers/net/ibm_newemac/core.h
--- linux-2.6.orig/drivers/net/ibm_newemac/core.h 2008-02-21 16:45:36.000000000 +0300
+++ linux-2.6/drivers/net/ibm_newemac/core.h 2008-02-22 19:57:44.000000000 +0300
@@ -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] ibm_newemac: emac_tx_csum typo fix.patch
From: Valentine Barshak @ 2008-02-22 19:21 UTC (permalink / raw)
To: linuxppc-dev
Move the "&& skb->ip_summed == CHECKSUM_PARTIAL" part out of
emac_has_feature parameters.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
drivers/net/ibm_newemac/core.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/core.c linux-2.6/drivers/net/ibm_newemac/core.c
--- linux-2.6.orig/drivers/net/ibm_newemac/core.c 2008-02-21 16:45:36.000000000 +0300
+++ linux-2.6/drivers/net/ibm_newemac/core.c 2008-02-22 19:55:29.000000000 +0300
@@ -1235,8 +1235,8 @@ static int emac_close(struct net_device
static inline u16 emac_tx_csum(struct emac_instance *dev,
struct sk_buff *skb)
{
- if (emac_has_feature(dev, EMAC_FTR_HAS_TAH &&
- skb->ip_summed == CHECKSUM_PARTIAL)) {
+ if (emac_has_feature(dev, EMAC_FTR_HAS_TAH) &&
+ (skb->ip_summed == CHECKSUM_PARTIAL)) {
++dev->stats.tx_packets_csum;
return EMAC_TX_CTRL_TAH_CSUM;
}
^ permalink raw reply
* Re: [RFC][PATCH] PowerPC 4xx: ibm_newemac 440GX phy clock workaround.
From: Valentine Barshak @ 2008-02-22 19:15 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1203634340.10422.203.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Thu, 2008-02-21 at 17:46 +0300, Valentine Barshak wrote:
>> The PowerPC 440GX Taishan board fails to reset EMAC3 (reset timeout error)
>> and because of that it can't 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 main problem is that will force clock on -all- EMACs ... which can
> be a problem as they can be in probe at the same time. Might be worth
> also adding a global mutex around that block.
I've tried to move clock selection inside the global emac_phy_map_lock
block. That works fine for 440GX.
>
> Also, would you mind having a look at the other workaround for the
> similar bug?
OK, I'll add 440EP/440GR workaround, but I'm not sure if we need it for
the currently supported boards. The older ibm_emac driver also has a
workaround for it on 405ep. This part uses CPC0 dcr registers. So, looks
like we'll have to search device tree for the CPC0 entry in ibm_newemac
driver, map dcr registers and select clock with dcr_read/write calls.
I've omitted the 405ep part, since there's currently no board supported.
Thanks,
Valentine.
>
> Cheers,
> Ben.
>
>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>> ---
>> drivers/net/ibm_newemac/core.c | 16 +++++++++++++++-
>> drivers/net/ibm_newemac/core.h | 8 ++++++--
>> 2 files changed, 21 insertions(+), 3 deletions(-)
>>
>> diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/core.c linux-2.6/drivers/net/ibm_newemac/core.c
>> --- linux-2.6.orig/drivers/net/ibm_newemac/core.c 2008-02-21 16:45:36.000000000 +0300
>> +++ linux-2.6/drivers/net/ibm_newemac/core.c 2008-02-21 17:21:21.000000000 +0300
>> @@ -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"
>>
>> @@ -2480,8 +2482,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))
>> @@ -2673,8 +2678,17 @@ static int __devinit emac_probe(struct o
>> dev->stop_timeout = STOP_TIMEOUT_100;
>> INIT_DELAYED_WORK(&dev->link_work, emac_link_timer);
>>
>> + /* Enable internal phy clock source */
>> + if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX))
>> + mtdcri(SDR0, SDR0_MFR, mfdcri(SDR0, SDR0_MFR) | SDR0_MFR_ECS);
>> +
>> /* Find PHY if any */
>> err = emac_init_phy(dev);
>> +
>> + /* Enable external phy clock source */
>> + if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX))
>> + mtdcri(SDR0, SDR0_MFR, mfdcri(SDR0, SDR0_MFR) & ~SDR0_MFR_ECS);
>> +
>> if (err != 0)
>> goto err_detach_tah;
>>
>> diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/core.h linux-2.6/drivers/net/ibm_newemac/core.h
>> --- linux-2.6.orig/drivers/net/ibm_newemac/core.h 2008-02-21 16:45:36.000000000 +0300
>> +++ linux-2.6/drivers/net/ibm_newemac/core.h 2008-02-21 17:21:47.000000000 +0300
>> @@ -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
* RE: Xilinx PowerPC
From: Stephen Neuendorffer @ 2008-02-22 19:07 UTC (permalink / raw)
To: alan.casey5, Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <4726E9350007F2E5@hawk.dcu.ie>
> -----Original Message-----
> From: Alan Casey [mailto:alan.casey5@mail.dcu.ie]
> Sent: Friday, February 22, 2008 10:58 AM
> To: Stephen Neuendorffer; Grant Likely
> Cc: linuxppc-embedded
> Subject: RE: Xilinx PowerPC
>=20
>=20
> >-- Original Message --
> >Subject: RE: Xilinx PowerPC
> >Date: Fri, 22 Feb 2008 10:11:19 -0800
> >From: "Stephen Neuendorffer" <stephen.neuendorffer@xilinx.com>
> >To: <alan.casey5@mail.dcu.ie>,
> > "Grant Likely" <grant.likely@secretlab.ca>
> >Cc: linuxppc-embedded <linuxppc-embedded@ozlabs.org>
> >
> >
> >>
> >> Hi,
> >>
> >> Just wondering - is it possible to use U-Boot on the Xilinx
XUPV2PRO
> >> board or any similar tools (such as libfdt?) to copy a Linux
kernel
> >and
> >>
> >> ramdisk filesystem from a SystemACE card to memory, uncompress
them
> >and
> >>
> >> boot the Linux kernel etc?? If so is there any notes/docs about
how
> >to
> >> do
> >> this or similar online anywhere?
> >>
> >> Any info. appreciated,
> >> Regards&Thanks,
> >> Alan.
> >
> >In theory, yes... All the infrastructure to do this exists, but I
don't
> >know of anyone who as actually tried it yet with ARCH=3Dpowerpc
kernels.
> >There
> >
> >Steve
>=20
> So i can try the latest official U-Boot releases with the ML300
configuration
> or is there a port or similar of U-Boot for the Xilinx XUPV2PRO
board??
>=20
> Regards&Thanks,
> Alan.
>=20
>=20
That's probably your best starting point.... There is a uboot
application note on the Xilinx website (XAPP 542), but it's a little
thin on porting information.
Steve
^ permalink raw reply
* Re: How to dynamically disable/enable CPU features?
From: Gerhard Pircher @ 2008-02-22 19:05 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev
In-Reply-To: <ebff4ecb45908616728fb5c8ede8b0bf@bga.com>
Hi,
-------- Original-Nachricht --------
> Datum: Fri, 22 Feb 2008 11:24:38 -0600
> Von: Milton Miller <miltonm@bga.com>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: ppcdev <linuxppc-dev@ozlabs.org>
> Betreff: Re: How to dynamically disable/enable CPU features?
> We handle cpu features in a couple of ways:
> (1) we replace assembly instructions with nop early in the kernel boot
I'm pretty sure that is the problem.
> (2) we test the feature flags in c code
>
> In (2), we form two expressions for features that are
> (a) always set
> (b) never set
> so that the compiler can eliminate the test based on the config.
>
> To change a flag, you must make sure its in POSSIBLE but not ALWAYS,
> and also set it before it is used, either to nop out instructions (see
> early_init in setup-32.c for 32 bit), or tested by c code (in this
> case, maybe the initial_mmu setup is testing NEED_COHERENT, which is
> between early_init and probe). The code path is a bit different for 64
> bit.
The flag is in POSSIBLE. I now use this code in the platform probe
function to nop out the code affected by the flag:
cur_cpu_spec->cpu_features &= ~CPU_FTR_NEED_COHERENT;
/* Patch out unwanted feature. */
do_feature_fixups(cur_cpu_spec->cpu_features,
PTRRELOC(&__start___ftr_fixup),
PTRRELOC(&__stop___ftr_fixup));
It seems to work so far, but I would like to know if this is the right
way to do it, or if calling do_feature_fixups() more than once can have
any side effects.
regards,
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
^ permalink raw reply
* RE: Xilinx PowerPC
From: Alan Casey @ 2008-02-22 18:58 UTC (permalink / raw)
To: Stephen Neuendorffer, Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <20080222181124.5F07079007D@mail120-dub.bigfish.com>
>-- Original Message --
>Subject: RE: Xilinx PowerPC
>Date: Fri, 22 Feb 2008 10:11:19 -0800
>From: "Stephen Neuendorffer" <stephen.neuendorffer@xilinx.com>
>To: <alan.casey5@mail.dcu.ie>,
> "Grant Likely" <grant.likely@secretlab.ca>
>Cc: linuxppc-embedded <linuxppc-embedded@ozlabs.org>
>
>
>>
>> Hi,
>>
>> Just wondering - is it possible to use U-Boot on the Xilinx XUPV2PRO=
>> board or any similar tools (such as libfdt?) to copy a Linux kernel
>and
>>
>> ramdisk filesystem from a SystemACE card to memory, uncompress them
>and
>>
>> boot the Linux kernel etc?? If so is there any notes/docs about how
>to
>> do
>> this or similar online anywhere?
>>
>> Any info. appreciated,
>> Regards&Thanks,
>> Alan.
>
>In theory, yes... All the infrastructure to do this exists, but I don't=
>know of anyone who as actually tried it yet with ARCH=3Dpowerpc kernels.=
>There
>
>Steve
So i can try the latest official U-Boot releases with the ML300 configur=
ation
or is there a port or similar of U-Boot for the Xilinx XUPV2PRO board??
Regards&Thanks,
Alan.
^ permalink raw reply
* Re: MPC8540 : What's "SPE used in kernel" ?
From: Andy Fleming @ 2008-02-22 18:33 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linuxppc-dev
In-Reply-To: <20080222095022.GA635@ingate.macqel>
On Feb 22, 2008, at 03:50, Philippe De Muyter wrote:
> Dear list,
>
> I have just compiled linux-2.6.24 for a MPC8540 target using a MPC8540
> specific gcc.
>
> I then got tan infinity of "SPE used in kernel" messages. Looking
> at the
> sources I ifdeffed out the printk call in KernelSPE, and I now have a
> silent kernel, that seems to work fine.
>
> Is there something wrong in my setting and should I look further to
> debug this problem or is this perfectly normal ?
>
> I wonder why a kernel configured for E500 and compiled by a E500-
> specific gcc
> triggers this message. Is it invalid to use SPE instructions in
> the kernel
> or do I misunderstand the message ?
We don't currently support using SPE in the kernel. Are you using
SPE in the kernel for some reason? Do you think that the compiler is
automatically generating SPE code in the kernel? I've never seen
that before.
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