* Re: [PATCH v2] lite5200: fix ethernet phy address
From: Dmitry Eremin-Solenikov @ 2010-06-17 8:41 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <AANLkTilDO4Q_pXHux71Cr34EQsso-8kAd1ce7q2ATrCd@mail.gmail.com>
On 16.06.2010 22:25, Grant Likely wrote:
> On Tue, Jun 15, 2010 at 4:19 PM, Dmitry Eremin-Solenikov
> <dbaryshkov@gmail.com> wrote:
>> Dmitry Eremin-Solenikov wrote:
>>
>>> According to my schematics, on Lite5200 board ethernet phy uses address
>>> 0 (all ADDR lines are pulled down). With this change I can talk to
>>> onboard phy (LXT971) and correctly use autonegotiation.
>>
>> What about this patch?
>
> It was included in my merge req to Linus yesterday.
Yes. This mail was sent a minute before you've sent poll request to Linus :)
Sorry for the noise.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH RFC] ppc: fix default_machine_crash_shutdown #ifdef botch
From: Paul E. McKenney @ 2010-06-17 4:30 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev
In-Reply-To: <6286.1276739813@neuling.org>
On Thu, Jun 17, 2010 at 11:56:53AM +1000, Michael Neuling wrote:
>
>
> In message <20100616004839.GA18110@linux.vnet.ibm.com> you wrote:
> > crash_kexec_wait_realmode() is defined only if CONFIG_PPC_STD_MMU_64
> > and CONFIG_SMP, but is called if CONFIG_PPC_STD_MMU_64 even if !CONFIG_SMP.
> > Fix the conditional compilation around the invocation.
> >
> > Untested, probably does not compile.
> >
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>
> This should be right since we don't need to wait for the other CPUs if
> there are no others...
>
> Compiles for me and even fixes the SMP=N case. Thanks!
Glad it worked! ;-)
Thanx, Paul
> Acked-by: Michael Neuling <mikey@neuling.org>
>
> > ---
> >
> > diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
> > index b46f2e0..29df48f 100644
> > --- a/arch/powerpc/kernel/crash.c
> > +++ b/arch/powerpc/kernel/crash.c
> > @@ -447,7 +447,7 @@ void default_machine_crash_shutdown(struct pt_regs *regs)
> > crash_kexec_prepare_cpus(crashing_cpu);
> > cpu_set(crashing_cpu, cpus_in_crash);
> > crash_kexec_stop_spus();
> > -#ifdef CONFIG_PPC_STD_MMU_64
> > +#if defined(CONFIG_PPC_STD_MMU_64) && defined(CONFIG_SMP)
> > crash_kexec_wait_realmode(crashing_cpu);
> > #endif
> > if (ppc_md.kexec_cpu_down)
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
> >
^ permalink raw reply
* Re: Porting a driver to powerpc using FDT
From: Chris Alfred @ 2010-06-17 4:29 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <DC0A9AAD98D847FC97F74D4B04C4E898@kos>
> We have only done a text search/replace lite5200 to jkc5200.
I meant to write:
We copied lite5200.c to jkc5200n8.c, and have only done a text
search/replace lite5200 to jkc5200n8
Chris
^ permalink raw reply
* Re: Porting a driver to powerpc using FDT
From: Chris Alfred @ 2010-06-17 4:25 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <AANLkTim8kD9PH7BqOIV0GvElIfOgUDMw1VfWcOJhj-8r@mail.gmail.com>
>>>> dsa_of_init is successfully called; but dsa_of_probe is not
>>>> called.
>>>
>>> That means the node is not being used to register an of_device. I
>>> need some more information to suggest how best to fix this.
>>
>>> What SoC are you using?
>>> What file in arch/powerpc/platforms/* is used to setup your
>>> machine?
>>
>> We are using the MPC5200. Very similar to the Lite5200.
>
> So you're board is driver by
> arch/powerpc/platforms/52xx/mpc5200_simple.c then?
The Lite5200 is based on arch/powerpc/platforms/52xx/lite5200.c
We have only done a text search/replace lite5200 to jkc5200.
Based on your email, we have now also changed fsl,jkc5200n8 to
jkc,jkc5200n8
> As mentioned, drop the reg property and be more specific in the
> compatible value.
Done, changed fsl,jkc5200n8 to jkc,jkc5200n8
> If you do the
> following, then it should start working:
>
> virtual-devices {
> compatible = "simple-bus";
> dsa {
> compatible = "<vendor>,jkc5200n8-dsa";
> };
> };
Where did "simple-bus" come from?
Did you mean "mpc5200-simple-platform" from:
define_machine(mpc5200_simple_platform) {
.name = "mpc5200-simple-platform",
...
};
> You can look under /sys/devices to see if your device actually gets
> registered or not.
Not there unfortunately, and probe is still not called.
Regards,
Chris
^ permalink raw reply
* Re: [PATCH RFC] ppc: fix default_machine_crash_shutdown #ifdef botch
From: Michael Neuling @ 2010-06-17 1:56 UTC (permalink / raw)
To: paulmck; +Cc: linuxppc-dev
In-Reply-To: <20100616004839.GA18110@linux.vnet.ibm.com>
In message <20100616004839.GA18110@linux.vnet.ibm.com> you wrote:
> crash_kexec_wait_realmode() is defined only if CONFIG_PPC_STD_MMU_64
> and CONFIG_SMP, but is called if CONFIG_PPC_STD_MMU_64 even if !CONFIG_SMP.
> Fix the conditional compilation around the invocation.
>
> Untested, probably does not compile.
>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
This should be right since we don't need to wait for the other CPUs if
there are no others...
Compiles for me and even fixes the SMP=N case. Thanks!
Acked-by: Michael Neuling <mikey@neuling.org>
> ---
>
> diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
> index b46f2e0..29df48f 100644
> --- a/arch/powerpc/kernel/crash.c
> +++ b/arch/powerpc/kernel/crash.c
> @@ -447,7 +447,7 @@ void default_machine_crash_shutdown(struct pt_regs *regs)
> crash_kexec_prepare_cpus(crashing_cpu);
> cpu_set(crashing_cpu, cpus_in_crash);
> crash_kexec_stop_spus();
> -#ifdef CONFIG_PPC_STD_MMU_64
> +#if defined(CONFIG_PPC_STD_MMU_64) && defined(CONFIG_SMP)
> crash_kexec_wait_realmode(crashing_cpu);
> #endif
> if (ppc_md.kexec_cpu_down)
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH] gianfar: Fix oversized packets handling
From: David Miller @ 2010-06-17 1:09 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, afleming, Sandeep.Kumar, netdev
In-Reply-To: <20100611205103.GA4255@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@mvista.com>
Date: Sat, 12 Jun 2010 00:51:03 +0400
> Issuing the following command on host:
>
> $ ifconfig eth2 mtu 1600 ; ping 10.0.0.27 -s 1485 -c 1
>
> Makes some boards (tested with MPC8315 rev 1.1 and MPC8313 rev 1.0)
> oops like this:
...
> Dumped buffer descriptors showed that eTSEC's length/truncation
> logic sometimes passes oversized packets, i.e. for the above ICMP
> packet the following two buffer descriptors may become ready:
>
> status=1400 length=1536
> status=1800 length=1541
>
> So, it seems that gianfar actually receives the whole big frame,
> and it tries to place the packet into two BDs. This situation
> confuses the driver, and so the skb_put() sanity check fails.
>
> This patch fixes the issue by adding an appropriate check, i.e.
> the driver should not try to process frames with buffer
> descriptor's length over rx_buffer_size (i.e. maxfrm and mrblr).
>
> Note that sometimes eTSEC works correctly, i.e. in the second
> (last) buffer descriptor bits 'truncated' and 'crcerr' are set,
> and so there's no oops. Though I couldn't find any logic when
> it works correctly and when not.
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Applied, thanks Anton.
^ permalink raw reply
* Re: [PATCH 2/2] ehea: Fix kernel deadlock in DLPAR-mem processing
From: David Miller @ 2010-06-17 1:05 UTC (permalink / raw)
To: ossthema; +Cc: themann, netdev, linux-kernel, linuxppc-dev, tklein, adetsch
In-Reply-To: <201006151735.43144.ossthema@de.ibm.com>
From: "Jan-Bernd Themann" <ossthema@de.ibm.com>
Date: Tue, 15 Jun 2010 17:35:42 +0200
> Port reset operations and memory add/remove operations need to
> be serialized to avoid a kernel deadlock. The deadlock is caused
> by calling the napi_disable() function twice.
> Therefore we have to employ the dlpar_mem_lock in the ehea_reset_port
> function as well
>
>
> Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] ehea: fix delayed packet processing
From: David Miller @ 2010-06-17 1:05 UTC (permalink / raw)
To: fubar
Cc: themann, netdev, linux-kernel, linuxppc-dev, ossthema, tklein,
adetsch
In-Reply-To: <6663.1276620347@death.nxdomain.ibm.com>
From: Jay Vosburgh <fubar@us.ibm.com>
Date: Tue, 15 Jun 2010 09:45:47 -0700
> Jan-Bernd Themann <ossthema@de.ibm.com> wrote:
>
>>In the eHEA poll function an rmb() is required. Without that some packets
>>on the receive queue are not seen and thus delayed until the next interrupt
>>is handled for the same receive queue.
>>
>>Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
>
> To add a bit of background, this could manifest during a netperf
> TCP_RR or UDP_RR on an otherwise idle network. TCP would occasionally
> retransmit, but then both the original segment and the retransmission
> would simultaneously appear at the receiver. For UDP_RR, message sizes
> in excess of the mtu would occasionally "lose" an IP fragment, and
> eventually IP reassembly would time out.
>
> -J
>
> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH 04/12] phylib: add a way to make PHY time stamps possible.
From: David Miller @ 2010-06-17 1:03 UTC (permalink / raw)
To: richardcochran
Cc: netdev, devicetree-discuss, linuxppc-dev, linux-arm-kernel, khc
In-Reply-To: <27c0ad283f025c2bb71e7ceb71be07f969939429.1276615626.git.richard.cochran@omicron.at>
From: Richard Cochran <richardcochran@gmail.com>
Date: Tue, 15 Jun 2010 18:08:20 +0200
> +static inline void skb_tx_timetamp(struct phy_device *phy, struct sk_buff *skb)
> +{
> + union skb_shared_tx *shtx = skb_tx(skb);
> +
> + if (shtx->hardware && phy && phy->drv->txtstamp)
> + phy->drv->txtstamp(phy, skb);
> +
> + if (shtx->software && !shtx->in_progress)
> + skb_tstamp_tx(skb, NULL);
> +}
> +
> +static inline void skb_rx_timetamp(struct phy_device *phy, struct sk_buff *skb)
> +{
> + if (phy && phy->drv->rxtstamp)
> + phy->drv->rxtstamp(phy, skb);
> +}
Since, as you say, this can provide a way to deal with the sw TX
timestamping sequencing problem we have right now, I'd rather
you implement this from the inside out instead of from the
outside in.
By this I mean you should provide these inline helpers by default
then we can begin to put them into the drivers.
You could also split the SW tstamp handling into a seperate inline
function, which drivers call immediately once they know they will
actually give the packet to the hardware for sending.
^ permalink raw reply
* Re: Porting a driver to powerpc using FDT
From: Grant Likely @ 2010-06-16 23:14 UTC (permalink / raw)
To: Chris Alfred; +Cc: linuxppc-dev
In-Reply-To: <162C87D14617439384076F797228B1EF@kos>
On Wed, Jun 16, 2010 at 4:48 PM, Chris Alfred <c.alfred@internode.on.net> w=
rote:
>>> dsa_of_init is successfully called; but dsa_of_probe is not called.
>>
>> That means the node is not being used to register an of_device. =A0I
>> need some more information to suggest how best to fix this.
>
>> What SoC are you using?
>> What file in arch/powerpc/platforms/* is used to setup your machine?
>
> We are using the MPC5200. Very similar to the Lite5200.
So you're board is driver by arch/powerpc/platforms/52xx/mpc5200_simple.c t=
hen?
>
>> It would help to have a copy of your full .dts file.
>
> /*
> =A0* jkc5200n8 board Device Tree Source
> =A0*
> =A0* Copyright 2006-2007 Secret Lab Technologies Ltd.
> =A0* Grant Likely <grant.likely@secretlab.ca>
> =A0*
> =A0* This program is free software; you can redistribute =A0it and/or
> modify it
> =A0* under =A0the terms of =A0the GNU General =A0Public License as publis=
hed
> by the
> =A0* Free Software Foundation; =A0either version 2 of the =A0License, or =
(at
> your
> =A0* option) any later version.
> =A0*/
>
> /dts-v1/;
>
> / {
> =A0model =3D "fsl,jkc5200n8";
> =A0compatible =3D "fsl,jkc5200n8";
Replace these two instances of 'fsl,' with this vendor name of this
board. fsl means freescale, and I'm guessing freescale didn't design
this board.
> =A0#address-cells =3D <1>;
> =A0#size-cells =3D <1>;
> =A0interrupt-parent =3D <&mpc5200_pic>;
>
> =A0cpus {
> =A0#address-cells =3D <1>;
> =A0#size-cells =3D <0>;
>
> =A0PowerPC,5200@0 {
> =A0 device_type =3D "cpu";
> =A0 reg =3D <0>;
> =A0 d-cache-line-size =3D <32>;
> =A0 i-cache-line-size =3D <32>;
> =A0 d-cache-size =3D <0x4000>; // L1, 16K
> =A0 i-cache-size =3D <0x4000>; // L1, 16K
> =A0 timebase-frequency =3D <0>; // from bootloader
> =A0 bus-frequency =3D <0>; =A0// from bootloader
> =A0 clock-frequency =3D <0>; =A0// from bootloader
> =A0};
> =A0};
>
> =A0memory {
> =A0device_type =3D "memory";
> =A0reg =3D <0x00000000 0x10000000>; // 256MB
> =A0};
>
> =A0dsa {
> =A0compatible =3D "dsa-of";
> =A0reg =3D <0 0>; =A0 // unused
As mentioned, drop the reg property and be more specific in the
compatible value.
Okay, so the problem is that the 5200 board support doesn't understand
that this device is a real device. The solution (and this isn't
perfect, but I'm working to make this better) is to put the node in a
place where the platform code actually processes it. If you do the
following, then it should start working:
virtual-devices {
compatible =3D "simple-bus";
dsa {
compatible =3D "<vendor>,jkc5200n8-dsa";
};
};
Note that I've encoded the board name in the compatible value. Until
(when/if) there is a 'generic' binding for DSA devices, you should
just use a string that is board specific.
You can look under /sys/devices to see if your device actually gets
registered or not.
This is *not* ideal. The support code should pick up the device even
as a child of the root node, but I've got to make some changes to the
registration code to make it work correctly.
Cheers,
g.
^ permalink raw reply
* Re: Porting a driver to powerpc using FDT
From: Chris Alfred @ 2010-06-16 22:48 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <AANLkTinBJgwL9qcw0Ouzuvc55C1Gs2KtIoY2NbBy34V2@mail.gmail.com>
>> dsa_of_init is successfully called; but dsa_of_probe is not called.
>
> That means the node is not being used to register an of_device. I
> need some more information to suggest how best to fix this.
> What SoC are you using?
> What file in arch/powerpc/platforms/* is used to setup your machine?
We are using the MPC5200. Very similar to the Lite5200.
> It would help to have a copy of your full .dts file.
/*
* jkc5200n8 board Device Tree Source
*
* Copyright 2006-2007 Secret Lab Technologies Ltd.
* Grant Likely <grant.likely@secretlab.ca>
*
* This program is free software; you can redistribute it and/or
modify it
* under the terms of the GNU General Public License as published
by the
* Free Software Foundation; either version 2 of the License, or (at
your
* option) any later version.
*/
/dts-v1/;
/ {
model = "fsl,jkc5200n8";
compatible = "fsl,jkc5200n8";
#address-cells = <1>;
#size-cells = <1>;
interrupt-parent = <&mpc5200_pic>;
cpus {
#address-cells = <1>;
#size-cells = <0>;
PowerPC,5200@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <32>;
i-cache-line-size = <32>;
d-cache-size = <0x4000>; // L1, 16K
i-cache-size = <0x4000>; // L1, 16K
timebase-frequency = <0>; // from bootloader
bus-frequency = <0>; // from bootloader
clock-frequency = <0>; // from bootloader
};
};
memory {
device_type = "memory";
reg = <0x00000000 0x10000000>; // 256MB
};
dsa {
compatible = "dsa-of";
reg = <0 0>; // unused
};
soc5200@f0000000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc5200b-immr";
ranges = <0 0xf0000000 0x0000c000>;
reg = <0xf0000000 0x00000100>;
bus-frequency = <0>; // from bootloader
system-frequency = <0>; // from bootloader
cdm@200 {
compatible = "fsl,mpc5200b-cdm","fsl,mpc5200-cdm";
reg = <0x200 0x38>;
};
mpc5200_pic: interrupt-controller@500 {
// 5200 interrupts are encoded into two levels;
interrupt-controller;
#interrupt-cells = <3>;
compatible = "fsl,mpc5200b-pic","fsl,mpc5200-pic";
reg = <0x500 0x80>;
};
timer@600 { // General Purpose Timer
compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
reg = <0x600 0x10>;
interrupts = <1 9 0>;
fsl,has-wdt;
};
timer@610 { // General Purpose Timer
compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
reg = <0x610 0x10>;
interrupts = <1 10 0>;
};
timer@620 { // General Purpose Timer
compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
reg = <0x620 0x10>;
interrupts = <1 11 0>;
};
timer@630 { // General Purpose Timer
compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
reg = <0x630 0x10>;
interrupts = <1 12 0>;
};
timer@640 { // General Purpose Timer
compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
reg = <0x640 0x10>;
interrupts = <1 13 0>;
};
timer@650 { // General Purpose Timer
compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
reg = <0x650 0x10>;
interrupts = <1 14 0>;
};
timer@660 { // General Purpose Timer
compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
reg = <0x660 0x10>;
interrupts = <1 15 0>;
};
timer@670 { // General Purpose Timer
compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
reg = <0x670 0x10>;
interrupts = <1 16 0>;
};
rtc@800 { // Real time clock
compatible = "fsl,mpc5200b-rtc","fsl,mpc5200-rtc";
reg = <0x800 0x100>;
interrupts = <1 5 0 1 6 0>;
};
can@900 {
compatible = "fsl,mpc5200b-mscan","fsl,mpc5200-mscan";
interrupts = <2 17 0>;
reg = <0x900 0x80>;
};
can@980 {
compatible = "fsl,mpc5200b-mscan","fsl,mpc5200-mscan";
interrupts = <2 18 0>;
reg = <0x980 0x80>;
};
gpio_simple: gpio@b00 {
compatible = "fsl,mpc5200b-gpio","fsl,mpc5200-gpio";
reg = <0xb00 0x40>;
interrupts = <1 7 0>;
gpio-controller;
#gpio-cells = <2>;
};
gpio_wkup: gpio@c00 {
compatible = "fsl,mpc5200b-gpio-wkup","fsl,mpc5200-gpio-wkup";
reg = <0xc00 0x40>;
interrupts = <1 8 0 0 3 0>;
gpio-controller;
#gpio-cells = <2>;
};
spi@f00 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
reg = <0xf00 0x20>;
interrupts = <2 13 0 2 14 0>;
interrupt-parent = <&mpc5200_pic>;
switch0: ethernet-switch@0 {
//compatible = "spidev";
//compatible = "micrel,spi-ks8995";
compatible = "micrel,spi-ks8995-dsa";
spi-max-frequency = <1000000>;
reg = <0>;
};
};
usb@1000 {
compatible = "fsl,mpc5200b-ohci","fsl,mpc5200-ohci","ohci-be";
reg = <0x1000 0xff>;
interrupts = <2 6 0>;
};
dma-controller@1200 {
compatible = "fsl,mpc5200b-bestcomm","fsl,mpc5200-bestcomm";
reg = <0x1200 0x80>;
interrupts = <3 0 0 3 1 0 3 2 0 3 3 0
3 4 0 3 5 0 3 6 0 3 7 0
3 8 0 3 9 0 3 10 0 3 11 0
3 12 0 3 13 0 3 14 0 3 15 0>;
};
xlb@1f00 {
compatible = "fsl,mpc5200b-xlb","fsl,mpc5200-xlb";
reg = <0x1f00 0x100>;
};
serial@2000 { // PSC1
compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
cell-index = <0>;
reg = <0x2000 0x100>;
interrupts = <2 1 0>;
};
// PSC2 in ac97 mode example
ac97@2200 { // PSC2
compatible = "fsl,mpc5200b-psc-ac97","fsl,mpc5200-psc-ac97";
cell-index = <1>;
reg = <0x2200 0x100>;
interrupts = <2 2 0>;
};
// PSC3 in CODEC mode example
i2s@2400 { // PSC3
compatible = "fsl,mpc5200b-psc-i2s"; //not 5200 compatible
cell-index = <2>;
reg = <0x2400 0x100>;
interrupts = <2 3 0>;
//codec-handle = <&dummycodec>;
};
// PSC4 in uart mode example
//serial@2600 { // PSC4
// compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
// cell-index = <3>;
// reg = <0x2600 0x100>;
// interrupts = <2 11 0>;
//};
// PSC5 in uart mode example
//serial@2800 { // PSC5
// compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
// cell-index = <4>;
// reg = <0x2800 0x100>;
// interrupts = <2 12 0>;
//};
// PSC6 in spi mode example
//spi@2c00 { // PSC6
// compatible = "fsl,mpc5200b-psc-spi","fsl,mpc5200-psc-spi";
// cell-index = <5>;
// reg = <0x2c00 0x100>;
// interrupts = <2 4 0>;
//};
ethernet@3000 {
compatible = "fsl,mpc5200b-fec","fsl,mpc5200-fec";
reg = <0x3000 0x400>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <2 5 0>;
phy-handle = <&phy0>;
};
mdio@3000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5200b-mdio","fsl,mpc5200-mdio";
reg = <0x3000 0x400>; // fec range, since we need to setup fec
interrupts
interrupts = <2 5 0>; // these are for "mii command finished", not
link changes & co.
phy0: ethernet-phy@1 {
reg = <1>;
};
phy1: ethernet-phy@2 {
reg = <1>;
};
phy2: ethernet-phy@3 {
reg = <1>;
};
phy3: ethernet-phy@4 {
reg = <1>;
};
};
ata@3a00 {
compatible = "fsl,mpc5200b-ata","fsl,mpc5200-ata";
reg = <0x3a00 0x100>;
interrupts = <2 7 0>;
};
i2c@3d00 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
reg = <0x3d00 0x40>;
interrupts = <2 15 0>;
};
i2c@3d40 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
reg = <0x3d40 0x40>;
interrupts = <2 16 0>;
};
sram@8000 {
compatible = "fsl,mpc5200b-sram","fsl,mpc5200-sram";
reg = <0x8000 0x4000>;
};
};
pci@f0000d00 {
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
compatible = "fsl,mpc5200b-pci","fsl,mpc5200-pci";
reg = <0xf0000d00 0x100>;
interrupt-map-mask = <0xf800 0 0 7>;
interrupt-map = <0xc000 0 0 1 &mpc5200_pic 0 0 3 // 1st slot
0xc000 0 0 2 &mpc5200_pic 1 1 3
0xc000 0 0 3 &mpc5200_pic 1 2 3
0xc000 0 0 4 &mpc5200_pic 1 3 3
0xc800 0 0 1 &mpc5200_pic 1 1 3 // 2nd slot
0xc800 0 0 2 &mpc5200_pic 1 2 3
0xc800 0 0 3 &mpc5200_pic 1 3 3
0xc800 0 0 4 &mpc5200_pic 0 0 3>;
clock-frequency = <0>; // From boot loader
interrupts = <2 8 0 2 9 0 2 10 0>;
bus-range = <0 0>;
ranges = <0x42000000 0 0x80000000 0x80000000 0 0x20000000
0x02000000 0 0xa0000000 0xa0000000 0 0x10000000
0x01000000 0 0x00000000 0xb0000000 0 0x01000000>;
};
localbus {
compatible = "fsl,mpc5200b-lpb","fsl,mpc5200-lpb","simple-bus";
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0xff000000 0x01000000 /* CS0: Flash */
1 0 0x10000000 0x10000000>; /* CS1: USB ISP1761 */
flash@0,0 {
compatible = "cfi-flash";
reg = <0 0 0x01000000>;
bank-width = <2>;
#size-cells = <1>;
#address-cells = <1>;
// fe000000 aliased at ff000000
partition@0 {
label = "spare";
reg = <0x00000000 0x00f00000>;
};
partition@f00000 {
label = "u-boot";
reg = <0x00f00000 0x00040000>;
};
partition@f40000 {
label = "u-boot-env";
reg = <0x00f40000 0x00020000>;
};
partition@f60000 {
label = "spare2";
reg = <0x00f60000 0x000a0000>;
};
};
isp1761@1,0 {
compatible = "nxp,usb-isp1761";
reg = <1 0 0x10000000>;
bus-width = <16>;
big-endian;
interrupts = <1 1 3>; /* HC INT */
//interrupts = <0 0 0>;
};
};
};
^ permalink raw reply
* Re: Porting a driver to powerpc using FDT
From: Grant Likely @ 2010-06-16 22:43 UTC (permalink / raw)
To: Chris Alfred; +Cc: linuxppc-dev
In-Reply-To: <EBEDB9C789D344D9A8D459B6FCB1A0AD@kos>
On Wed, Jun 16, 2010 at 4:06 PM, Chris Alfred <c.alfred@internode.on.net> w=
rote:
> Grant Likely wrote:
>> On Tue, Jun 15, 2010 at 4:19 PM, Chris Alfred
>> <c.alfred@internode.on.net> wrote:
>>> I am trying to port a DSA (Distributed Switch Architecture) driver
>>> for the Micrel KS8995M managed switch connected to a MPC5200. There
>>> is an SPI interface and MII interface managed by the DSA driver.
>>>
>>> I can't understand how probe gets called when the flatted device
>>> tree
>>> (FDT) system is used, and how to bind such a driver using the FDT
>>> (if
>>> you have to at all).
>>>
>>> The DSA driver is initialised via:
>>>
>>> // net/dsa/dsa.c
>>>
>>> static struct platform_driver dsa_driver =3D {
>>> .probe =3D dsa_probe,
>>> .remove =3D dsa_remove,
>>> .shutdown =3D dsa_shutdown,
>>> .driver =3D {
>>> .name =3D "dsa",
>>> .owner =3D THIS_MODULE,
>>> },
>>> };
>>>
>>> static int __init dsa_init_module(void)
>>> {
>>> return platform_driver_register(&dsa_driver);
>>> }
>>>
>>> dsa_init_module is being called; but how do I get the system to
>>> call
>>> .probe?
>>
>> To avoid writing new machine-specific code in
>> arch/powerpc/platforms,
>> then I recommend that you add a node to your .dts file to describe
>> the
>> DSA complex and write a very simple of_platform_driver that binds
>> against it. =A0Then use the probe hook to extract data out of the
>> device
>> tree node (if needed) and register the appropriate platform_device
>> (don't forget to make the of_device the parent of the
>> platform_device). =A0This can be considered a temporary solution, but
>> it
>> will not break when I make the infrastructure changes, and then you
>> can migrate over to the new method at your leisure.
>
>
> Thanks for the great response.
>
> I still have some learning to do. To start, I tried to get a simple
> of_platform_driver going.
> In my .dts I added:
>
> =A0 =A0/ {
> =A0 =A0 =A0 =A0...
> =A0 =A0 =A0 =A0 dsa {
> =A0 =A0 =A0 =A0 =A0compatible =3D "dsa-of";
This is too generic. Until there is a real generic binding for DSA
devices, use a name specific to your board. An of driver can bind to
more than one compatible value. Don't forget to include the vendor
prefix in your compatible value.
> =A0 =A0 =A0 =A0 =A0reg =3D <0 0>; =A0 // TODO: might need config values e=
.g. number
> of phys, cpu port
Just drop this property until you have real data to populate it with.
For a virtual device like this you probably don't need a reg property.
What you probably do need in this node is references (phandles) to
the node for the marvel switch which I imagine hangs off of an MDIO or
SPI bus.
> =A0 =A0 =A0 =A0 };
> =A0 =A0 =A0 =A0...
> =A0 =A0};
>
> I created net/dsa/dsa_of.c - the simple of_platform_driver that will
> bind to the DSA platform driver (in net/dsa/dsa.c):
>
> =A0 =A0#include <linux/of.h>
> =A0 =A0#include <linux/kernel.h>
> =A0 =A0#include <linux/of_platform.h>
>
> =A0 =A0static int __devinit dsa_of_probe(struct of_device *ofdev, const
> struct of_device_id *match)
> =A0 =A0{
> =A0 =A0 printk("dsa_of_probe\n");
> =A0 =A0 return 0;
> =A0 =A0}
>
> =A0 =A0static int dsa_of_remove(struct of_device *ofdev)
> =A0 =A0{
> =A0 =A0 printk("dsa_of_remove\n");
> =A0 =A0 return 0;
> =A0 =A0}
>
>
> =A0 =A0static const struct of_device_id dsa_of_match[] =3D {
> =A0 =A0 {
> =A0 =A0 =A0.compatible =3D "dsa-of",
> =A0 =A0 },
> =A0 =A0 {}
> =A0 =A0};
>
> =A0 =A0static struct of_platform_driver dsa_of_driver =3D {
> =A0 =A0 .name =3D "dsa-of",
> =A0 =A0 .match_table =3D dsa_of_match,
> =A0 =A0 .probe =3D dsa_of_probe,
> =A0 =A0 .remove =3D dsa_of_remove,
> =A0 =A0};
>
> =A0 =A0static int __init dsa_of_init(void)
> =A0 =A0{
> =A0 =A0 printk("dsa_of_init\n");
>
> =A0 =A0 if (of_register_platform_driver(&dsa_of_driver))
> =A0 =A0 =A0printk(KERN_ERR "Unable to register DSA OF platform driver\n")=
;
>
> =A0 =A0 return 0;
> =A0 =A0}
> =A0 =A0module_init(dsa_of_init);
>
> =A0 =A0static void __exit dsa_of_cleanup(void)
> =A0 =A0{
> =A0 =A0 printk("dsa_of_cleanup\n");
>
> =A0 =A0 of_unregister_platform_driver(&dsa_of_driver);
> =A0 =A0}
> =A0 =A0module_exit(dsa_of_cleanup);
>
> =A0 =A0MODULE_DESCRIPTION("DSA OF platform driver");
> =A0 =A0MODULE_AUTHOR("Chris Alfred <chris@greyfog.com.au");
> =A0 =A0MODULE_LICENSE("GPL v2");
>
> dsa_of_init is successfully called; but dsa_of_probe is not called.
That means the node is not being used to register an of_device. I
need some more information to suggest how best to fix this. What SoC
are you using? What file in arch/powerpc/platforms/* is used to setup
your machine? It would help to have a copy of your full .dts file.
Cheers,
g.
^ permalink raw reply
* Re: Porting a driver to powerpc using FDT
From: Chris Alfred @ 2010-06-16 22:06 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <AANLkTimArb-UjJMe84Qrd4iNquGHEehbGW1Uciq_zGYm@mail.gmail.com>
Grant Likely wrote:
> On Tue, Jun 15, 2010 at 4:19 PM, Chris Alfred
> <c.alfred@internode.on.net> wrote:
>> I am trying to port a DSA (Distributed Switch Architecture) driver
>> for the Micrel KS8995M managed switch connected to a MPC5200. There
>> is an SPI interface and MII interface managed by the DSA driver.
>>
>> I can't understand how probe gets called when the flatted device
>> tree
>> (FDT) system is used, and how to bind such a driver using the FDT
>> (if
>> you have to at all).
>>
>> The DSA driver is initialised via:
>>
>> // net/dsa/dsa.c
>>
>> static struct platform_driver dsa_driver = {
>> .probe = dsa_probe,
>> .remove = dsa_remove,
>> .shutdown = dsa_shutdown,
>> .driver = {
>> .name = "dsa",
>> .owner = THIS_MODULE,
>> },
>> };
>>
>> static int __init dsa_init_module(void)
>> {
>> return platform_driver_register(&dsa_driver);
>> }
>>
>> dsa_init_module is being called; but how do I get the system to
>> call
>> .probe?
>
> To avoid writing new machine-specific code in
> arch/powerpc/platforms,
> then I recommend that you add a node to your .dts file to describe
> the
> DSA complex and write a very simple of_platform_driver that binds
> against it. Then use the probe hook to extract data out of the
> device
> tree node (if needed) and register the appropriate platform_device
> (don't forget to make the of_device the parent of the
> platform_device). This can be considered a temporary solution, but
> it
> will not break when I make the infrastructure changes, and then you
> can migrate over to the new method at your leisure.
Thanks for the great response.
I still have some learning to do. To start, I tried to get a simple
of_platform_driver going.
In my .dts I added:
/ {
...
dsa {
compatible = "dsa-of";
reg = <0 0>; // TODO: might need config values e.g. number
of phys, cpu port
};
...
};
I created net/dsa/dsa_of.c - the simple of_platform_driver that will
bind to the DSA platform driver (in net/dsa/dsa.c):
#include <linux/of.h>
#include <linux/kernel.h>
#include <linux/of_platform.h>
static int __devinit dsa_of_probe(struct of_device *ofdev, const
struct of_device_id *match)
{
printk("dsa_of_probe\n");
return 0;
}
static int dsa_of_remove(struct of_device *ofdev)
{
printk("dsa_of_remove\n");
return 0;
}
static const struct of_device_id dsa_of_match[] = {
{
.compatible = "dsa-of",
},
{}
};
static struct of_platform_driver dsa_of_driver = {
.name = "dsa-of",
.match_table = dsa_of_match,
.probe = dsa_of_probe,
.remove = dsa_of_remove,
};
static int __init dsa_of_init(void)
{
printk("dsa_of_init\n");
if (of_register_platform_driver(&dsa_of_driver))
printk(KERN_ERR "Unable to register DSA OF platform driver\n");
return 0;
}
module_init(dsa_of_init);
static void __exit dsa_of_cleanup(void)
{
printk("dsa_of_cleanup\n");
of_unregister_platform_driver(&dsa_of_driver);
}
module_exit(dsa_of_cleanup);
MODULE_DESCRIPTION("DSA OF platform driver");
MODULE_AUTHOR("Chris Alfred <chris@greyfog.com.au");
MODULE_LICENSE("GPL v2");
dsa_of_init is successfully called; but dsa_of_probe is not called.
Regards,
Chris
^ permalink raw reply
* Re: [PATCH] gianfar: Fix setup of RX time stamping
From: David Miller @ 2010-06-16 21:40 UTC (permalink / raw)
To: cbouatmailru; +Cc: netdev, richard.cochran, Manfred.Rudigier, linuxppc-dev
In-Reply-To: <20100611122023.GA1598@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <cbouatmailru@gmail.com>
Date: Fri, 11 Jun 2010 16:20:23 +0400
> On Fri, Jun 11, 2010 at 01:49:05PM +0200, Manfred Rudigier wrote:
>> Previously the RCTRL_TS_ENABLE bit was set unconditionally. However, if
>> the RCTRL_TS_ENABLE is set without TMR_CTRL[TE], the driver does not work
>> properly on some boards (Anton had problems with the MPC8313ERDB and
>> MPC8568EMDS).
>>
>> With this patch the bit will only be set if requested from user space
>> with the SIOCSHWTSTAMP ioctl command, meaning that time stamping is
>> disabled during normal operation. Users who are not interested in time
>> stamps will not experience problems with buggy CPU revisions or
>> performance drops any more.
>>
>> The setting of TMR_CTRL[TE] is still up to the user. This is considered
>> safe because users wanting HW timestamps must initialize the eTSEC clock
>> first anyway, e.g. with the recently submitted PTP clock driver.
>>
>> Signed-off-by: Manfred Rudigier <manfred.rudigier@omicron.at>
>> ---
>
> Looks OK. I tested that it doesn't break anything, but I didn't
> test the timestamping functionality. So
>
> Reviewed-by: Anton Vorontsov <cbouatmailru@gmail.com>
Applied, thanks guys.
^ permalink raw reply
* Re: [PATCH 2/2] of: kill struct of_device
From: David Miller @ 2010-06-16 21:07 UTC (permalink / raw)
To: grant.likely
Cc: sfr, monstr, microblaze-uclinux, devicetree-discuss, linuxppc-dev,
sparclinux
In-Reply-To: <20100604211138.2762.35074.stgit@angua>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Fri, 04 Jun 2010 15:11:38 -0600
> Now that the device tree node pointer has been moved out of struct
> of_device and into the common struct device, there isn't anything
> unique about of_device anymore. In fact, there isn't much need
> for a separate of_bus when all busses have access to OF style
> probing.
>
> arch/powerpc and arch/microblaze are moving away from using the of_bus
> and using the regular platform bus instead for mmio devices. This
> patch makes of_device the same as platform_device as a stepping stone
> in migrating of_platform_drivers over to the platform bus.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* RE: [PATCHv3] [RFC] Xilinx Virtex 4 FX Soft FPU support
From: Stephen Neuendorffer @ 2010-06-16 20:19 UTC (permalink / raw)
To: Grant Likely, Sergey Temerkhanov; +Cc: John Linn, linuxppc-dev
In-Reply-To: <AANLkTinx5nCwng6tFz8h1VC_2qZ69xMF1SCCGD9iv3MM@mail.gmail.com>
> -----Original Message-----
> From: linuxppc-dev-bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org [=
mailto:linuxppc-dev-
> bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org] On Behalf Of Grant =
Likely
> Sent: Wednesday, June 16, 2010 1:02 PM
> To: Sergey Temerkhanov
> Cc: linuxppc-dev@lists.ozlabs.org; John Linn
> Subject: Re: [PATCHv3] [RFC] Xilinx Virtex 4 FX Soft FPU support
> =
> On Wed, May 26, 2010 at 11:04 AM, Sergey Temerkhanov
> <temerkhanov@cifronik.ru> wrote:
> > This patch enables support for Xilinx Virtex 4 FX singe-float FPU.
> >
> > Changelog v2-v3:
> > =A0 =A0 =A0 =A0-Fixed whitespaces for SAVE_FPR/REST_FPR.
> > =A0 =A0 =A0 =A0-Changed description of MSR_AP bit.
> > =A0 =A0 =A0 =A0-Removed the stub for APU unavailable exception.
> >
> > Changelog v1->v2:
> > =A0 =A0 =A0 =A0-Added MSR_AP bit definition
> > =A0 =A0 =A0 =A0-Renamed CONFIG_XILINX_FPU to CONFIG_XILINX_SOFTFPU, mov=
ed it to
> > =A0 =A0 =A0 =A0 'Platform support' and made it Virtex4-FX-only.
> > =A0 =A0 =A0 =A0-Changed SAVE_FPR/REST_FPR definition style.
> >
> > Caveats:
> > =A0 =A0 =A0 =A0- Hard-float binaries which rely on in-kernel math emula=
tion will
> > =A0 =A0 =A0 =A0give wrong results since they expect 64-bit double-preci=
sion instead of
> > =A0 =A0 =A0 =A032-bit single-precision numbers which Xilinx V4-FX Soft =
FPU produces.
Perhaps this caveat should go in the description of the configuration optio=
n?
Steve
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [PATCHv3] [RFC] Xilinx Virtex 4 FX Soft FPU support
From: Grant Likely @ 2010-06-16 20:01 UTC (permalink / raw)
To: Sergey Temerkhanov; +Cc: linuxppc-dev, John Linn
In-Reply-To: <201005262104.48938.temerkhanov@cifronik.ru>
On Wed, May 26, 2010 at 11:04 AM, Sergey Temerkhanov
<temerkhanov@cifronik.ru> wrote:
> This patch enables support for Xilinx Virtex 4 FX singe-float FPU.
>
> Changelog v2-v3:
> =9A =9A =9A =9A-Fixed whitespaces for SAVE_FPR/REST_FPR.
> =9A =9A =9A =9A-Changed description of MSR_AP bit.
> =9A =9A =9A =9A-Removed the stub for APU unavailable exception.
>
> Changelog v1->v2:
> =9A =9A =9A =9A-Added MSR_AP bit definition
> =9A =9A =9A =9A-Renamed CONFIG_XILINX_FPU to CONFIG_XILINX_SOFTFPU, moved=
it to
> =9A =9A =9A =9A 'Platform support' and made it Virtex4-FX-only.
> =9A =9A =9A =9A-Changed SAVE_FPR/REST_FPR definition style.
>
> Caveats:
> =9A =9A =9A =9A- Hard-float binaries which rely on in-kernel math emulati=
on will
> =9A =9A =9A =9Agive wrong results since they expect 64-bit double-precisi=
on instead of
> =9A =9A =9A =9A32-bit single-precision numbers which Xilinx V4-FX Soft FP=
U produces.
>
>
> Signed-off-by: Sergey Temerkhanov<temerkhanov@cifronik.ru>
Seems okay to me. Josh & Ben, what do you think?
>
> diff -r 626de0d94469 arch/powerpc/include/asm/ppc_asm.h
> --- a/arch/powerpc/include/asm/ppc_asm.h =9A =9A =9A =9AWed May 26 15:33:=
32 2010 +0400
> +++ b/arch/powerpc/include/asm/ppc_asm.h =9A =9A =9A =9AWed May 26 20:30:=
43 2010 +0400
> @@ -85,13 +85,21 @@
> =9A#define REST_8GPRS(n, base) =9A =9AREST_4GPRS(n, base); REST_4GPRS(n+4=
, base)
> =9A#define REST_10GPRS(n, base) =9A REST_8GPRS(n, base); REST_2GPRS(n+8, =
base)
>
> +
> +#ifdef CONFIG_XILINX_SOFTFPU
> +#define SAVE_FPR(n, base) =9A =9A =9Astfs =9A =9An,THREAD_FPR0+8*TS_FPRW=
IDTH*(n)(base)
> +#define REST_FPR(n, base) =9A =9A =9Alfs =9A =9A n,THREAD_FPR0+8*TS_FPRW=
IDTH*(n)(base)
> +#else
> =9A#define SAVE_FPR(n, base) =9A =9A =9Astfd =9A =9An,THREAD_FPR0+8*TS_FP=
RWIDTH*(n)(base)
> +#define REST_FPR(n, base) =9A =9A =9Alfd =9A =9A n,THREAD_FPR0+8*TS_FPRW=
IDTH*(n)(base)
> +#endif
> +
> =9A#define SAVE_2FPRS(n, base) =9A =9ASAVE_FPR(n, base); SAVE_FPR(n+1, ba=
se)
> =9A#define SAVE_4FPRS(n, base) =9A =9ASAVE_2FPRS(n, base); SAVE_2FPRS(n+2=
, base)
> =9A#define SAVE_8FPRS(n, base) =9A =9ASAVE_4FPRS(n, base); SAVE_4FPRS(n+4=
, base)
> =9A#define SAVE_16FPRS(n, base) =9A SAVE_8FPRS(n, base); SAVE_8FPRS(n+8, =
base)
> =9A#define SAVE_32FPRS(n, base) =9A SAVE_16FPRS(n, base); SAVE_16FPRS(n+1=
6, base)
> -#define REST_FPR(n, base) =9A =9A =9Alfd =9A =9A n,THREAD_FPR0+8*TS_FPRW=
IDTH*(n)(base)
> +
> =9A#define REST_2FPRS(n, base) =9A =9AREST_FPR(n, base); REST_FPR(n+1, ba=
se)
> =9A#define REST_4FPRS(n, base) =9A =9AREST_2FPRS(n, base); REST_2FPRS(n+2=
, base)
> =9A#define REST_8FPRS(n, base) =9A =9AREST_4FPRS(n, base); REST_4FPRS(n+4=
, base)
> diff -r 626de0d94469 arch/powerpc/include/asm/reg.h
> --- a/arch/powerpc/include/asm/reg.h =9A =9AWed May 26 15:33:32 2010 +040=
0
> +++ b/arch/powerpc/include/asm/reg.h =9A =9AWed May 26 20:30:43 2010 +040=
0
> @@ -30,6 +30,7 @@
> =9A#define MSR_ISF_LG =9A =9A 61 =9A =9A =9A =9A =9A =9A =9A/* Interrupt =
64b mode valid on 630 */
> =9A#define MSR_HV_LG =9A =9A =9A60 =9A =9A =9A =9A =9A =9A =9A/* Hypervis=
or state */
> =9A#define MSR_VEC_LG =9A =9A 25 =9A =9A =9A =9A =9A =9A =9A/* Enable Alt=
iVec */
> +#define MSR_AP_LG =9A =9A =9A25 =9A =9A =9A =9A =9A =9A =9A/* Enable PPC=
405 APU */
> =9A#define MSR_VSX_LG =9A =9A 23 =9A =9A =9A =9A =9A =9A =9A/* Enable VSX=
*/
> =9A#define MSR_POW_LG =9A =9A 18 =9A =9A =9A =9A =9A =9A =9A/* Enable Pow=
er Management */
> =9A#define MSR_WE_LG =9A =9A =9A18 =9A =9A =9A =9A =9A =9A =9A/* Wait Sta=
te Enable */
> @@ -71,6 +72,7 @@
> =9A#define MSR_HV =9A =9A =9A =9A 0
> =9A#endif
>
> +#define MSR_AP =9A =9A =9A =9A __MASK(MSR_AP_LG) =9A =9A =9A /* Enable P=
PC405 APU */
> =9A#define MSR_VEC =9A =9A =9A =9A =9A =9A =9A =9A__MASK(MSR_VEC_LG) =9A =
=9A =9A/* Enable AltiVec */
> =9A#define MSR_VSX =9A =9A =9A =9A =9A =9A =9A =9A__MASK(MSR_VSX_LG) =9A =
=9A =9A/* Enable VSX */
> =9A#define MSR_POW =9A =9A =9A =9A =9A =9A =9A =9A__MASK(MSR_POW_LG) =9A =
=9A =9A/* Enable Power Management */
> diff -r 626de0d94469 arch/powerpc/kernel/fpu.S
> --- a/arch/powerpc/kernel/fpu.S Wed May 26 15:33:32 2010 +0400
> +++ b/arch/powerpc/kernel/fpu.S Wed May 26 20:30:43 2010 +0400
> @@ -57,6 +57,9 @@
> =9A_GLOBAL(load_up_fpu)
> =9A =9A =9A =9Amfmsr =9A r5
> =9A =9A =9A =9Aori =9A =9A r5,r5,MSR_FP
> +#ifdef CONFIG_XILINX_SOFTFPU
> + =9A =9A =9A oris =9A =9Ar5,r5,MSR_AP@h
> +#endif
> =9A#ifdef CONFIG_VSX
> =9ABEGIN_FTR_SECTION
> =9A =9A =9A =9Aoris =9A =9Ar5,r5,MSR_VSX@h
> @@ -85,6 +88,9 @@
> =9A =9A =9A =9Atoreal(r5)
> =9A =9A =9A =9APPC_LL =9Ar4,_MSR-STACK_FRAME_OVERHEAD(r5)
> =9A =9A =9A =9Ali =9A =9A =9Ar10,MSR_FP|MSR_FE0|MSR_FE1
> +#ifdef CONFIG_XILINX_SOFTFPU
> + =9A =9A =9A oris =9A =9Ar10,r10,MSR_AP@h
> +#endif
> =9A =9A =9A =9Aandc =9A =9Ar4,r4,r10 =9A =9A =9A =9A =9A =9A =9A /* disab=
le FP for previous task */
> =9A =9A =9A =9APPC_STL r4,_MSR-STACK_FRAME_OVERHEAD(r5)
> =9A1:
> @@ -94,6 +100,9 @@
> =9A =9A =9A =9Amfspr =9A r5,SPRN_SPRG3 =9A =9A =9A =9A =9A /* current tas=
k's THREAD (phys) */
> =9A =9A =9A =9Alwz =9A =9A r4,THREAD_FPEXC_MODE(r5)
> =9A =9A =9A =9Aori =9A =9A r9,r9,MSR_FP =9A =9A =9A =9A =9A =9A/* enable =
FP for current */
> +#ifdef CONFIG_XILINX_SOFTFPU
> + =9A =9A =9A oris =9A =9Ar9,r9,MSR_AP@h
> +#endif
> =9A =9A =9A =9Aor =9A =9A =9Ar9,r9,r4
> =9A#else
> =9A =9A =9A =9Ald =9A =9A =9Ar4,PACACURRENT(r13)
> @@ -124,6 +133,9 @@
> =9A_GLOBAL(giveup_fpu)
> =9A =9A =9A =9Amfmsr =9A r5
> =9A =9A =9A =9Aori =9A =9A r5,r5,MSR_FP
> +#ifdef CONFIG_XILINX_SOFTFPU
> + =9A =9A =9A oris =9A =9Ar5,r5,MSR_AP@h
> +#endif
> =9A#ifdef CONFIG_VSX
> =9ABEGIN_FTR_SECTION
> =9A =9A =9A =9Aoris =9A =9Ar5,r5,MSR_VSX@h
> @@ -145,6 +157,9 @@
> =9A =9A =9A =9Abeq =9A =9A 1f
> =9A =9A =9A =9APPC_LL =9Ar4,_MSR-STACK_FRAME_OVERHEAD(r5)
> =9A =9A =9A =9Ali =9A =9A =9Ar3,MSR_FP|MSR_FE0|MSR_FE1
> +#ifdef CONFIG_XILINX_SOFTFPU
> + =9A =9A =9A oris =9A =9Ar3,r3,MSR_AP@h
> +#endif
> =9A#ifdef CONFIG_VSX
> =9ABEGIN_FTR_SECTION
> =9A =9A =9A =9Aoris =9A =9Ar3,r3,MSR_VSX@h
> diff -r 626de0d94469 arch/powerpc/kernel/head_40x.S
> --- a/arch/powerpc/kernel/head_40x.S =9A =9AWed May 26 15:33:32 2010 +040=
0
> +++ b/arch/powerpc/kernel/head_40x.S =9A =9AWed May 26 20:30:43 2010 +040=
0
> @@ -420,7 +420,19 @@
> =9A =9A =9A =9Aaddi =9A =9Ar3,r1,STACK_FRAME_OVERHEAD
> =9A =9A =9A =9AEXC_XFER_STD(0x700, program_check_exception)
>
> +/* 0x0800 - FPU unavailable Exception */
> +#ifdef CONFIG_PPC_FPU
> + =9A =9A =9A START_EXCEPTION(0x0800, FloatingPointUnavailable)
> + =9A =9A =9A NORMAL_EXCEPTION_PROLOG
> + =9A =9A =9A beq =9A =9A 1f; =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A=
=9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A \
> + =9A =9A =9A bl =9A =9A =9Aload_up_fpu; =9A =9A =9A =9A =9A =9A/* if fro=
m user, just load it up */ =9A \
> + =9A =9A =9A b =9A =9A =9A fast_exception_return; =9A =9A =9A =9A =9A =
=9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A\
> +1: =9A =9A addi =9A =9Ar3,r1,STACK_FRAME_OVERHEAD; =9A =9A =9A =9A =9A =
=9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A \
> + =9A =9A =9A EXC_XFER_EE_LITE(0x800, kernel_fp_unavailable_exception)
> +#else
> =9A =9A =9A =9AEXCEPTION(0x0800, Trap_08, unknown_exception, EXC_XFER_EE)
> +#endif
> +
> =9A =9A =9A =9AEXCEPTION(0x0900, Trap_09, unknown_exception, EXC_XFER_EE)
> =9A =9A =9A =9AEXCEPTION(0x0A00, Trap_0A, unknown_exception, EXC_XFER_EE)
> =9A =9A =9A =9AEXCEPTION(0x0B00, Trap_0B, unknown_exception, EXC_XFER_EE)
> @@ -821,8 +833,10 @@
> =9A* The PowerPC 4xx family of processors do not have an FPU, so this jus=
t
> =9A* returns.
> =9A*/
> +#ifndef CONFIG_PPC_FPU
> =9A_ENTRY(giveup_fpu)
> =9A =9A =9A =9Ablr
> +#endif
>
> =9A/* This is where the main kernel code starts.
> =9A*/
> diff -r 626de0d94469 arch/powerpc/platforms/Kconfig
> --- a/arch/powerpc/platforms/Kconfig =9A =9AWed May 26 15:33:32 2010 +040=
0
> +++ b/arch/powerpc/platforms/Kconfig =9A =9AWed May 26 20:30:43 2010 +040=
0
> @@ -333,4 +333,9 @@
> =9A =9A =9A =9Abool "Xilinx PCI host bridge support"
> =9A =9A =9A =9Adepends on PCI && XILINX_VIRTEX
>
> +config XILINX_SOFTFPU
> + =9A =9A =9A bool "Xilinx Soft FPU"
> + =9A =9A =9A select PPC_FPU
> + =9A =9A =9A depends on XILINX_VIRTEX_4_FX && !PPC40x_SIMPLE && !405GP &=
& !405GPR
> +
> =9Aendmenu
>
> --
> Regards, Sergey Temerkhanov,
> Cifronic ZAO
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 0/5] Rework MPC5121 DIU support (for 2.6.35)
From: Anatolij Gustschin @ 2010-06-16 20:00 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, linux-fbdev, devicetree-discuss, yorksun
In-Reply-To: <4C18FB3F.4020705@freescale.com>
On Wed, 16 Jun 2010 11:26:39 -0500
Timur Tabi <timur@freescale.com> wrote:
> Anatolij Gustschin wrote:
> > On Wed, 16 Jun 2010 10:42:28 -0500
> > Timur Tabi <timur@freescale.com> wrote:
> >
> >> Anatolij Gustschin wrote:
> >>
> >>> Any chance this could be done soon? I'd like to include the
> >>> MPC5121e DIU support in 2.6.36 since it is currently broken in
> >>> mainline and the patches provide the fix.
> >>
> >> Ok, I'll try it today.
> >
> > Thanks!
>
> I tried to build this, but it wouldn't compile, and then I realized I also
> need the 11 patches of the set "Update support for MPC512x". Unfortunately,
> I don't have this set in my inbox.
Please use Linus' tree, v2.6.35-rc3. The 5 patches from this series
apply cleanly on top of it and 86xx/mpc8610_hpcd_defconfig builds
here. I've tested them on mpc5121e based board but I don't have
MPC8610 HPCD and can't test on it.
> Can you email me, perhaps in one tarball, all of the patches I need?
I've send you these 5 patches, same patches have been posted to the list.
Thanks four your help,
Anatolij
^ permalink raw reply
* Re: [Patch v2 1/2] 5200/mpc: improve i2c bus error recovery
From: Albrecht Dreß @ 2010-06-16 19:30 UTC (permalink / raw)
To: Grant Likely
Cc: Linux PPC Development, Devicetree Discussions,
Ben Dooks (embedded platforms), Ira W. Snyder
In-Reply-To: <AANLkTikrF7-oxN5BzdiJga0XbMbQPKKj-SqwLp46_GQb@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 413 bytes --]
Am 19.05.10 18:02 schrieb(en) Grant Likely:
> > That's <http://git.secretlab.ca/?p=linux-2.6.git;a=shortlog>, isn't it?
> > Hmmm, didn't find it there... :-/
>
> Ugh... Stupid typing too fast. I meant to say, "I *don't* think ben
> has asked me to take..."
>
> Well this leaves a bit of a mess. I'll make sure it gets in one way or another.
*ping* Any news about this issue?
Cheers, Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH v2] lite5200: fix ethernet phy address
From: Grant Likely @ 2010-06-16 18:25 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: linuxppc-dev
In-Reply-To: <hv8ua6$uq0$1@dough.gmane.org>
On Tue, Jun 15, 2010 at 4:19 PM, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> wrote:
> Dmitry Eremin-Solenikov wrote:
>
>> According to my schematics, on Lite5200 board ethernet phy uses address
>> 0 (all ADDR lines are pulled down). With this change I can talk to
>> onboard phy (LXT971) and correctly use autonegotiation.
>
> What about this patch?
It was included in my merge req to Linus yesterday.
g.
^ permalink raw reply
* Re: Porting a driver to powerpc using FDT
From: Grant Likely @ 2010-06-16 18:22 UTC (permalink / raw)
To: Chris Alfred; +Cc: linuxppc-dev
In-Reply-To: <57F24E98919C4D22A784127E6CF1C9DA@kos>
On Tue, Jun 15, 2010 at 4:19 PM, Chris Alfred <c.alfred@internode.on.net> w=
rote:
> I am trying to port a DSA (Distributed Switch Architecture) driver for
> the Micrel KS8995M managed switch connected to a MPC5200. There is an
> SPI interface and MII interface managed by the DSA driver.
>
> I can't understand how probe gets called when the flatted device tree
> (FDT) system is used, and how to bind such a driver using the FDT (if
> you have to at all).
>
> The DSA driver is initialised via:
>
> =A0 =A0// net/dsa/dsa.c
>
> =A0 =A0static struct platform_driver dsa_driver =3D {
> =A0 =A0 .probe =A0=3D dsa_probe,
> =A0 =A0 .remove =A0=3D dsa_remove,
> =A0 =A0 .shutdown =3D dsa_shutdown,
> =A0 =A0 .driver =3D {
> =A0 =A0 =A0.name =3D "dsa",
> =A0 =A0 =A0.owner =3D THIS_MODULE,
> =A0 =A0 },
> =A0 =A0};
>
> =A0 =A0static int __init dsa_init_module(void)
> =A0 =A0{
> =A0 =A0 return platform_driver_register(&dsa_driver);
> =A0 =A0}
>
> dsa_init_module is being called; but how do I get the system to call
> .probe?
You need a platform device registered for the driver to bind against.
On a lot of systems, the machine setup code just registers a
statically allocated platform_device. You can still do this on
powerpc if you create a new machine specific board file in
arch/powerpc/platforms/ (discouraged, but only mildly so for things
that are very board specific).
The "preferred" approach on device tree systems is to add device tree
hooks to the driver you want to use. However, I'm not going to ask
you to do that since the current approach for doing so is in the
process of being removed (The current approach is to add a new
of_platform_driver registration for the device driver; but I've got
changes in my tree that will make regular old platform_drivers able to
bind against devices described in the device tree).
To avoid writing new machine-specific code in arch/powerpc/platforms,
then I recommend that you add a node to your .dts file to describe the
DSA complex and write a very simple of_platform_driver that binds
against it. Then use the probe hook to extract data out of the device
tree node (if needed) and register the appropriate platform_device
(don't forget to make the of_device the parent of the
platform_device). This can be considered a temporary solution, but it
will not break when I make the infrastructure changes, and then you
can migrate over to the new method at your leisure.
Cheers,
g.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Tim Bird @ 2010-06-16 17:43 UTC (permalink / raw)
To: Nicolas Pitre
Cc: microblaze-uclinux@itee.uq.edu.au, devicetree-discuss,
Jamie Lokier, linuxppc-dev, Mike Rapoport, Mitch Bradley,
Dan Malek, Jeremy Kerr, linux-arm-kernel@lists.infradead.org,
David Gibson
In-Reply-To: <alpine.LFD.2.00.1006160917390.13427@xanadu.home>
On 06/16/2010 07:39 AM, Nicolas Pitre wrote:
> The cost function _is_ different for the Linux community and decision
> makers at chip vendor companies. I know that for having worked long
> enough at a prominent chip vendor already.
>
> Those vendors want to ship a product and be first on the market before
> the competitors do. They grab a kernel tree, fit in their existing HAL
> as quickly as they can, so that they are able to demo the new chip to
> potential customers even before moving to full production. And if the
> HAL fitting work has been done into last year's kernel already, then
> they will simply reuse that kernel to minimize the effort further as in
> theory only the HAL part needs to be swapped with the new one (doesn't
> matter if last year's kernel was itself already based on a kernel from
> the year before). Once the software appears to work, they send it to
> customers and forget about it as they move to the next chip design. So
> here, the cost is directly related to bring-up time, and quick (or big)
> ugly software hacks are more than a convenience but rather a necessity
> if you want to win the race.
>
> People from the Linux community care about totally different things. The
> most important factor here is _long term_ maintainability. It is
> important that the code be clean, use a uniform coding style, and follow
> common interfaces. This is so because the cost function here is
> directly related to the difficulty for the Linux community to evolve the
> kernel with generic improvements and new features. If each driver has a
> different style, or rely on a different HAL, then it quickly becomes
> extremely expensive to update those drivers along with the generic
> improvements. And if the HAL is in binary form only, or stuck behind
> some unalterable BIOS-like calls or firmware API, then it may even be
> impossible to update those drivers as the execution context assumed by
> the HAL firmware may not be guaranteed anymore (think about UP vs SMP,
> different preemption modes, different realtime kernel modes, etc.) And
> of course it is impossible to anticipate what execution context and
> requirements the kernel might need in the future, hence this can't be
> provisioned for (and much less validated) into the HAL design in advance
> (and see above why it is next to hopeless to expect vendors to update
> their HAL for old products in a timely fashion).
>
> So there *is* indeed a big difference between both points of view. And
> sometimes the imperatives from each group are in total conflict.
This is absolutely correct. At the CE Linux Forum, we've been working
for years to try to get vendors more involved in the community, with
a variety of techniques, including white papers for management,
magazine articles, outreach at industry events, and hosting our
own events to introduce "industry" and "community" developers.
It is not uncommon for vendors to throw the software away (or big
chunks of it) for each release, which is completely contrary
to the goals of mainline developers. I once had a product line
where each year for 3 years, the product team used a different
processor ARCHITECTURE. Stuff like that significantly impairs
the argument that they'll see big wins from mainlining things.
>>> Which of course raises the question: How does the Linux community view such
>>> SoC vendors? Are they embraced and eagerly supported,
No. Mostly, they get chastised and told how wrong they are,
so they just stay away. Any work they have done is often thrown
under the bus by people who refuse to acknowledge their requirements.
(Witness the suspend blockers thread on linux-pm).
>>> or (either openly or
>>> secretly) viewed as a nuisance? How does the widespread objection to
>>> something that such vendors "would make extensive use of" mesh with that
>>> view?
>>
>> I cannot tell for the entire Linux community, but from what I know, such
>> vendors are not much welcomed in the community.
>
> And the reverse is also true: those vendors are not amenable to more
> openness and early community involvement which could help them get to
> market with "community acceptable" support for their products due to
> NDAs and such, or simply because of the perception that the Linux
> community is putting too much value on "expendable software". It is way
> too common to hear from hardware designers that "software is cheap"...
> which is not quite the case in the end. That's a real pity.
Also true. Nicolas - you're on a roll today. :-)
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Network Entertainment
=============================
^ permalink raw reply
* Re: [PATCH 0/5] Rework MPC5121 DIU support (for 2.6.35)
From: Wolfram Sang @ 2010-06-16 17:34 UTC (permalink / raw)
To: Timur Tabi
Cc: linuxppc-dev, linux-fbdev, Anatolij Gustschin, devicetree-discuss,
yorksun
In-Reply-To: <4C18FB3F.4020705@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 256 bytes --]
> Can you email me, perhaps in one tarball, all of the patches I need?
Or push a git tree :)
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 0/5] Rework MPC5121 DIU support (for 2.6.35)
From: Timur Tabi @ 2010-06-16 16:26 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev, linux-fbdev, devicetree-discuss, yorksun
In-Reply-To: <20100616174714.74a2e110@mw.dip.t-dialin.net>
Anatolij Gustschin wrote:
> On Wed, 16 Jun 2010 10:42:28 -0500
> Timur Tabi <timur@freescale.com> wrote:
>
>> Anatolij Gustschin wrote:
>>
>>> Any chance this could be done soon? I'd like to include the
>>> MPC5121e DIU support in 2.6.36 since it is currently broken in
>>> mainline and the patches provide the fix.
>>
>> Ok, I'll try it today.
>
> Thanks!
I tried to build this, but it wouldn't compile, and then I realized I also
need the 11 patches of the set "Update support for MPC512x". Unfortunately,
I don't have this set in my inbox.
Can you email me, perhaps in one tarball, all of the patches I need?
^ permalink raw reply
* Re: [PATCH 0/5] Rework MPC5121 DIU support (for 2.6.35)
From: Anatolij Gustschin @ 2010-06-16 15:47 UTC (permalink / raw)
To: Timur Tabi
Cc: linux-fbdev, wd, dzu, devicetree-discuss, linuxppc-dev, yorksun
In-Reply-To: <4C18F0E4.90309@freescale.com>
On Wed, 16 Jun 2010 10:42:28 -0500
Timur Tabi <timur@freescale.com> wrote:
> Anatolij Gustschin wrote:
>
> > Any chance this could be done soon? I'd like to include the
> > MPC5121e DIU support in 2.6.36 since it is currently broken in
> > mainline and the patches provide the fix.
>
> Ok, I'll try it today.
Thanks!
^ 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