Re: [PATCH RFC] ppc: fix default_machine_crash_shutdown #ifdef botch

[Paul E. McKenney]

On Thu, Jun 17, 2010 at 11:56:53AM +1000, Michael Neuling wrote:
> 
> 
> In message <20100616004839.ga18...@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 
> 
> 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 
> 
> > ---
> > 
> > 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
> > 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Porting a driver to powerpc using FDT

[Chris Alfred]

> 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


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Porting a driver to powerpc using FDT

[Chris Alfred]

 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 = ",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

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH RFC] ppc: fix default_machine_crash_shutdown #ifdef botch

[Michael Neuling]

In message <20100616004839.ga18...@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 

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 

> ---
> 
> 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
> 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] gianfar: Fix oversized packets handling

[David Miller]

From: Anton Vorontsov 
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 

Applied, thanks Anton.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/2] ehea: Fix kernel deadlock in DLPAR-mem processing

[David Miller]

From: "Jan-Bernd Themann" 
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 

Applied.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/2] ehea: fix delayed packet processing

[David Miller]

From: Jay Vosburgh 
Date: Tue, 15 Jun 2010 09:45:47 -0700

> Jan-Bernd Themann  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 
> 
>   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 

Applied.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 04/12] phylib: add a way to make PHY time stamps possible.

[David Miller]

From: Richard Cochran 
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.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Porting a driver to powerpc using FDT

[Grant Likely]

On Wed, Jun 16, 2010 at 4:48 PM, Chris Alfred  wrote:
>>> 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?

>
>> 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 
>  *
>  * 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";

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.

>  #address-cells = <1>;
>  #size-cells = <1>;
>  interrupt-parent = <&mpc5200_pic>;
>
>  cpus {
>  #address-cells = <1>;
>  #size-cells = <0>;
>
>  PowerPC,5...@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 = <0x 0x1000>; // 256MB
>  };
>
>  dsa {
>  compatible = "dsa-of";
>  reg = <0 0>;   // 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 = "simple-bus";
dsa {
  compatible = ",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.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Porting a driver to powerpc using FDT

[Chris Alfred]

>> 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 
 *
 * 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,5...@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 = <0x 0x1000>; // 256MB
 };

 dsa {
  compatible = "dsa-of";
  reg = <0 0>;   // unused
 };

 soc5...@f000 {
  #address-cells = <1>;
  #size-cells = <1>;
  compatible = "fsl,mpc5200b-immr";
  ranges = <0 0xf000 0xc000>;
  reg = <0xf000 0x0100>;
  bus-frequency = <0>;  // from bootloader
  system-frequency = <0>;  // from bootloader

  c...@200 {
   compatible = "fsl,mpc5200b-cdm","fsl,mpc5200-cdm";
   reg = <0x200 0x38>;
  };

  mpc5200_pic: interrupt-control...@500 {
   // 5200 interrupts are encoded into two levels;
   interrupt-controller;
   #interrupt-cells = <3>;
   compatible = "fsl,mpc5200b-pic","fsl,mpc5200-pic";
   reg = <0x500 0x80>;
  };

  ti...@600 { // General Purpose Timer
   compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
   reg = <0x600 0x10>;
   interrupts = <1 9 0>;
   fsl,has-wdt;
  };

  ti...@610 { // General Purpose Timer
   compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
   reg = <0x610 0x10>;
   interrupts = <1 10 0>;
  };

  ti...@620 { // General Purpose Timer
   compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
   reg = <0x620 0x10>;
   interrupts = <1 11 0>;
  };

  ti...@630 { // General Purpose Timer
   compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
   reg = <0x630 0x10>;
   interrupts = <1 12 0>;
  };

  ti...@640 { // General Purpose Timer
   compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
   reg = <0x640 0x10>;
   interrupts = <1 13 0>;
  };

  ti...@650 { // General Purpose Timer
   compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
   reg = <0x650 0x10>;
   interrupts = <1 14 0>;
  };

  ti...@660 { // General Purpose Timer
   compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
   reg = <0x660 0x10>;
   interrupts = <1 15 0>;
  };

  ti...@670 { // General Purpose Timer
   compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
   reg = <0x670 0x10>;
   interrupts = <1 16 0>;
  };

  r...@800 { // Real time clock
   compatible = "fsl,mpc5200b-rtc","fsl,mpc5200-rtc";
   reg = <0x800 0x100>;
   interrupts = <1 5 0 1 6 0>;
  };

  c...@900 {
   compatible = "fsl,mpc5200b-mscan","fsl,mpc5200-mscan";
   interrupts = <2 17 0>;
   reg = <0x900 0x80>;
  };

  c...@980 {
   compatible = "fsl,mpc5200b-mscan","fsl,mpc5200-mscan";
   interrupts = <2 18 0>;
   reg = <0x980 0x80>;
  };

  gpio_simple: g...@b00 {
   compatible = "fsl,mpc5200b-gpio","fsl,mpc5200-gpio";
   reg = <0xb00 0x40>;
   interrupts = <1 7 0>;
   gpio-controller;
   #gpio-cells = <2>;
  };

  gpio_wkup: g...@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>;
  };

  s...@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-swi...@0 {
//compatible = "spidev";
//compatible = "micrel,spi-ks8995";
compatible = "micrel,spi-ks8995-dsa";
spi-max-frequency = <100>;
reg = <0>;
   };
  };

  u...@1000 {
   compatible = "fsl,mpc5200b-ohci","fsl,mpc5200-ohci","ohci-be";
   reg = <0x1000 0xff>;
   interrupts = <2 6 0>;
  };

  dma-control...@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>;
  };

  x...@1f00 {
   compatible = "fsl,mpc5200b-xlb","fsl,mpc5200-xlb";
   reg = <0x1f00 0x100>;
  };

  s

Re: Porting a driver to powerpc using FDT

[Grant Likely]

On Wed, Jun 16, 2010 at 4:06 PM, Chris Alfred  wrote:
> Grant Likely wrote:
>> On Tue, Jun 15, 2010 at 4:19 PM, Chris Alfred
>>  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";

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.

>          reg = <0 0>;   // 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.

>         };
>        ...
>    };
>
> 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 
>    #include 
>    #include 
>
>    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     MODULE_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.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Porting a driver to powerpc using FDT

[Chris Alfred]

Grant Likely wrote:
> On Tue, Jun 15, 2010 at 4:19 PM, Chris Alfred
>  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 
#include 
#include 

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 https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] gianfar: Fix setup of RX time stamping

[David Miller]

From: Anton Vorontsov 
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 
>> ---
> 
> Looks OK. I tested that it doesn't break anything, but I didn't
> test the timestamping functionality. So
> 
> Reviewed-by: Anton Vorontsov 

Applied, thanks guys.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Request review of device tree documentation

[Tim Bird]

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
=

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/2] of: kill struct of_device

[David Miller]

From: Grant Likely 
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 

Acked-by: David S. Miller 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCHv3] [RFC] Xilinx Virtex 4 FX Soft FPU support

[Stephen Neuendorffer]

> -Original Message-
> From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org 
> [mailto:linuxppc-dev-
> bounces+stephen=neuendorffer.n...@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
>  wrote:
> > This patch enables support for Xilinx Virtex 4 FX singe-float FPU.
> >
> > Changelog v2-v3:
> >        -Fixed whitespaces for SAVE_FPR/REST_FPR.
> >        -Changed description of MSR_AP bit.
> >        -Removed the stub for APU unavailable exception.
> >
> > Changelog v1->v2:
> >        -Added MSR_AP bit definition
> >        -Renamed CONFIG_XILINX_FPU to CONFIG_XILINX_SOFTFPU, moved it to
> >         'Platform support' and made it Virtex4-FX-only.
> >        -Changed SAVE_FPR/REST_FPR definition style.
> >
> > Caveats:
> >        - Hard-float binaries which rely on in-kernel math emulation will
> >        give wrong results since they expect 64-bit double-precision instead 
> > of
> >        32-bit single-precision numbers which Xilinx V4-FX Soft FPU produces.

Perhaps this caveat should go in the description of the configuration option?

Steve


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCHv3] [RFC] Xilinx Virtex 4 FX Soft FPU support

[Grant Likely]

On Wed, May 26, 2010 at 11:04 AM, Sergey Temerkhanov
 wrote:
> This patch enables support for Xilinx Virtex 4 FX singe-float FPU.
>
> Changelog v2-v3:
>        -Fixed whitespaces for SAVE_FPR/REST_FPR.
>        -Changed description of MSR_AP bit.
>        -Removed the stub for APU unavailable exception.
>
> Changelog v1->v2:
>        -Added MSR_AP bit definition
>        -Renamed CONFIG_XILINX_FPU to CONFIG_XILINX_SOFTFPU, moved it to
>         'Platform support' and made it Virtex4-FX-only.
>        -Changed SAVE_FPR/REST_FPR definition style.
>
> Caveats:
>        - Hard-float binaries which rely on in-kernel math emulation will
>        give wrong results since they expect 64-bit double-precision instead of
>        32-bit single-precision numbers which Xilinx V4-FX Soft FPU produces.
>
>
> Signed-off-by: Sergey Temerkhanov

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        Wed May 26 15:33:32 2010 +0400
> +++ b/arch/powerpc/include/asm/ppc_asm.h        Wed May 26 20:30:43 2010 +0400
> @@ -85,13 +85,21 @@
>  #define REST_8GPRS(n, base)    REST_4GPRS(n, base); REST_4GPRS(n+4, base)
>  #define REST_10GPRS(n, base)   REST_8GPRS(n, base); REST_2GPRS(n+8, base)
>
> +
> +#ifdef CONFIG_XILINX_SOFTFPU
> +#define SAVE_FPR(n, base)      stfs    n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
> +#define REST_FPR(n, base)      lfs     n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
> +#else
>  #define SAVE_FPR(n, base)      stfd    n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
> +#define REST_FPR(n, base)      lfd     n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
> +#endif
> +
>  #define SAVE_2FPRS(n, base)    SAVE_FPR(n, base); SAVE_FPR(n+1, base)
>  #define SAVE_4FPRS(n, base)    SAVE_2FPRS(n, base); SAVE_2FPRS(n+2, base)
>  #define SAVE_8FPRS(n, base)    SAVE_4FPRS(n, base); SAVE_4FPRS(n+4, base)
>  #define SAVE_16FPRS(n, base)   SAVE_8FPRS(n, base); SAVE_8FPRS(n+8, base)
>  #define SAVE_32FPRS(n, base)   SAVE_16FPRS(n, base); SAVE_16FPRS(n+16, base)
> -#define REST_FPR(n, base)      lfd     n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
> +
>  #define REST_2FPRS(n, base)    REST_FPR(n, base); REST_FPR(n+1, base)
>  #define REST_4FPRS(n, base)    REST_2FPRS(n, base); REST_2FPRS(n+2, base)
>  #define REST_8FPRS(n, base)    REST_4FPRS(n, base); REST_4FPRS(n+4, base)
> diff -r 626de0d94469 arch/powerpc/include/asm/reg.h
> --- a/arch/powerpc/include/asm/reg.h    Wed May 26 15:33:32 2010 +0400
> +++ b/arch/powerpc/include/asm/reg.h    Wed May 26 20:30:43 2010 +0400
> @@ -30,6 +30,7 @@
>  #define MSR_ISF_LG     61              /* Interrupt 64b mode valid on 630 */
>  #define MSR_HV_LG      60              /* Hypervisor state */
>  #define MSR_VEC_LG     25              /* Enable AltiVec */
> +#define MSR_AP_LG      25              /* Enable PPC405 APU */
>  #define MSR_VSX_LG     23              /* Enable VSX */
>  #define MSR_POW_LG     18              /* Enable Power Management */
>  #define MSR_WE_LG      18              /* Wait State Enable */
> @@ -71,6 +72,7 @@
>  #define MSR_HV         0
>  #endif
>
> +#define MSR_AP         __MASK(MSR_AP_LG)       /* Enable PPC405 APU */
>  #define MSR_VEC                __MASK(MSR_VEC_LG)      /* Enable AltiVec */
>  #define MSR_VSX                __MASK(MSR_VSX_LG)      /* Enable VSX */
>  #define MSR_POW                __MASK(MSR_POW_LG)      /* 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 @@
>  _GLOBAL(load_up_fpu)
>        mfmsr   r5
>        ori     r5,r5,MSR_FP
> +#ifdef CONFIG_XILINX_SOFTFPU
> +       oris    r5,r5,msr...@h
> +#endif
>  #ifdef CONFIG_VSX
>  BEGIN_FTR_SECTION
>        oris    r5,r5,msr_...@h
> @@ -85,6 +88,9 @@
>        toreal(r5)
>        PPC_LL  r4,_MSR-STACK_FRAME_OVERHEAD(r5)
>        li      r10,MSR_FP|MSR_FE0|MSR_FE1
> +#ifdef CONFIG_XILINX_SOFTFPU
> +       oris    r10,r10,msr...@h
> +#endif
>        andc    r4,r4,r10               /* disable FP for previous task */
>        PPC_STL r4,_MSR-STACK_FRAME_OVERHEAD(r5)
>  1:
> @@ -94,6 +100,9 @@
>        mfspr   r5,SPRN_SPRG3           /* current task's THREAD (phys) */
>        lwz     r4,THREAD_FPEXC_MODE(r5)
>        ori     r9,r9,MSR_FP            /* enable FP for current */
> +#ifdef CONFIG_XILINX_SOFTFPU
> +       oris    r9,r9,msr...@h
> +#endif
>        or      r9,r9,r4
>  #else
>        ld      r4,PACACURRENT(r13)
> @@ -124,6 +133,9 @@
>  _GLOBAL(giveup_fpu)
>        mfmsr   r5
>        ori     r5,r5,MSR_FP
> +#ifdef CONFIG_XILINX_SOFTFPU
> +       oris    r5,r5,msr...@h
> +#endif
>  #ifdef CONFIG_VSX
>  BEGIN_FTR_SECTION
>        oris    r5,r5,msr_...@h
> @@ -145,6 +157,9 @@
>        beq     1f
>        PPC_LL  r4,_MSR-STACK_FRAME_OVERHEAD(r5)
>        li      r3,MSR_FP|MSR_FE0|MSR_FE1
> +#ifdef CONFIG_XILINX_SOFTFPU
> +       oris    r3,r3,msr...@

Re: [PATCH 0/5] Rework MPC5121 DIU support (for 2.6.35)

[Anatolij Gustschin]

On Wed, 16 Jun 2010 11:26:39 -0500
Timur Tabi  wrote:

> Anatolij Gustschin wrote:
> > On Wed, 16 Jun 2010 10:42:28 -0500
> > Timur Tabi  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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [Patch v2 1/2] 5200/mpc: improve i2c bus error recovery

[Albrecht Dreß]

Am 19.05.10 18:02 schrieb(en) Grant Likely:

> That's , 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.


pgpzHfLOVT5IJ.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2] lite5200: fix ethernet phy address

[Grant Likely]

On Tue, Jun 15, 2010 at 4:19 PM, Dmitry Eremin-Solenikov
 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.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Porting a driver to powerpc using FDT

[Grant Likely]

On Tue, Jun 15, 2010 at 4:19 PM, Chris Alfred  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?

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.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/5] Rework MPC5121 DIU support (for 2.6.35)

[Wolfram Sang]

> 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/  |


signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/5] Rework MPC5121 DIU support (for 2.6.35)

[Timur Tabi]

Anatolij Gustschin wrote:
> On Wed, 16 Jun 2010 10:42:28 -0500
> Timur Tabi  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?

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/5] Rework MPC5121 DIU support (for 2.6.35)

[Anatolij Gustschin]

On Wed, 16 Jun 2010 10:42:28 -0500
Timur Tabi  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!
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/5] Rework MPC5121 DIU support (for 2.6.35)

[Timur Tabi]

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.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]

[Micha Nelissen]

Micha Nelissen wrote:
Do you mean like attached? I had to change the order of the '_GLOBAL' 
definitions __setup_cpu_e500v1/__setup_cpu_e500v2 since this bit is 
e500v2 only.


Hmm, maybe need to use r0 or r3 instead of r2?

Micha
Index: linux/arch/powerpc/kernel/cpu_setup_fsl_booke.S
===
--- linux/arch/powerpc/kernel/cpu_setup_fsl_booke.S (revision 2871)
+++ linux/arch/powerpc/kernel/cpu_setup_fsl_booke.S (working copy)
@@ -57,8 +57,14 @@
ori r3,r3,hid0_dap...@l
mtspr   SPRN_HID0,r3
b   __setup_e200_ivors
+_GLOBAL(__setup_cpu_e500v2)
+#ifdef CONFIG_PTE_64BIT
+   /* enable mas7 register for tlbre/tlbsx */
+   mfspr   r0,SPRN_HID0
+   ori r0,r0,hid0_en_mas7_upd...@l
+   mtspr   SPRN_HID0,r0
+#endif
 _GLOBAL(__setup_cpu_e500v1)
-_GLOBAL(__setup_cpu_e500v2)
mflrr4
bl  __e500_icache_setup
bl  __e500_dcache_setup
Index: linux/arch/powerpc/include/asm/reg.h
===
--- linux/arch/powerpc/include/asm/reg.h(revision 2871)
+++ linux/arch/powerpc/include/asm/reg.h(working copy)
@@ -276,6 +276,7 @@
 #define HID0_DAPUEN(1<<8)  /* Debug APU enable */
 #define HID0_SGE   (1<<7)  /* Store Gathering Enable */
 #define HID0_SIED  (1<<7)  /* Serial Instr. Execution [Disable] */
+#define HID0_EN_MAS7_UPDATE (1<<7) /* Enable MAS7 reg for tlbre/tlbsx */
 #define HID0_DCFA  (1<<6)  /* Data Cache Flush Assist */
 #define HID0_LRSTK (1<<4)  /* Link register stack - 745x */
 #define HID0_BTIC  (1<<5)  /* Branch Target Instr Cache Enable */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/iseries: fix possible null pointer dereference in iSeries_pcibios_fixup_resources

[Denis Kirjanov]

I don't know if this is a right fix for the problem
since of_get_property can return NULL.
Since iseries_device_information is used only for informational purpose,
we can skip this function without valid HvSubBusNumber number.

Signed-off-by: Denis Kirjanov 
---
arch/powerpc/platforms/iseries/pci.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/platforms/iseries/pci.c 
b/arch/powerpc/platforms/iseries/pci.c
index 3fc2e64..ab3962b 100644
--- a/arch/powerpc/platforms/iseries/pci.c
+++ b/arch/powerpc/platforms/iseries/pci.c
@@ -445,7 +445,11 @@ void __init iSeries_pcibios_fixup_resources(struct pci_dev 
*pdev)
}
 
allocate_device_bars(pdev);
-   iseries_device_information(pdev, bus, *sub_bus);
+   if (likely(sub_bus))
+   iseries_device_information(pdev, bus, *sub_bus);
+   else
+   printk(KERN_ERR "PCI: Device node %s has missing or invalid "
+   "linux,subbus property\n", node->full_name);
 }
 
 /*
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]

[Micha Nelissen]

Kumar Gala wrote:

+BEGIN_MMU_FTR_SECTION
+   mfspr   r2,SPRN_HID0
+   ori r2,r2,hid0_en_mas7_upd...@l
+   mtspr   SPRN_HID0, r2
+END_MMU_FTR_SECTION_IFSET(MMU_FTR_BIG_PHYS)
+#endif


If you want to do this, do it in:

arch/powerpc/kernel/cpu_setup_fsl_booke.S


Do you mean like attached? I had to change the order of the '_GLOBAL' 
definitions __setup_cpu_e500v1/__setup_cpu_e500v2 since this bit is 
e500v2 only.


Thanks,

Micha
Index: linux/arch/powerpc/kernel/cpu_setup_fsl_booke.S
===
--- linux/arch/powerpc/kernel/cpu_setup_fsl_booke.S (revision 2871)
+++ linux/arch/powerpc/kernel/cpu_setup_fsl_booke.S (working copy)
@@ -57,8 +57,14 @@
ori r3,r3,hid0_dap...@l
mtspr   SPRN_HID0,r3
b   __setup_e200_ivors
+_GLOBAL(__setup_cpu_e500v2)
+#ifdef CONFIG_PTE_64BIT
+   /* enable mas7 register for tlbre/tlbsx */
+   mfspr   r2,SPRN_HID0
+   ori r2,r2,hid0_en_mas7_upd...@l
+   mtspr   SPRN_HID0,r2
+#endif
 _GLOBAL(__setup_cpu_e500v1)
-_GLOBAL(__setup_cpu_e500v2)
mflrr4
bl  __e500_icache_setup
bl  __e500_dcache_setup
Index: linux/arch/powerpc/include/asm/reg.h
===
--- linux/arch/powerpc/include/asm/reg.h(revision 2871)
+++ linux/arch/powerpc/include/asm/reg.h(working copy)
@@ -276,6 +276,7 @@
 #define HID0_DAPUEN(1<<8)  /* Debug APU enable */
 #define HID0_SGE   (1<<7)  /* Store Gathering Enable */
 #define HID0_SIED  (1<<7)  /* Serial Instr. Execution [Disable] */
+#define HID0_EN_MAS7_UPDATE (1<<7) /* Enable MAS7 reg for tlbre/tlbsx */
 #define HID0_DCFA  (1<<6)  /* Data Cache Flush Assist */
 #define HID0_LRSTK (1<<4)  /* Link register stack - 745x */
 #define HID0_BTIC  (1<<5)  /* Branch Target Instr Cache Enable */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 12/12] ptp: Added a clock driver for the National Semiconductor PHYTER.

[Grant Likely]

On Wed, Jun 16, 2010 at 4:05 AM, Richard Cochran
 wrote:
> On Tue, Jun 15, 2010 at 12:49:13PM -0600, Grant Likely wrote:
>> Won't this break things for existing DP83640 users?
>
> Nope, the driver was only added five patches ago, and it only offers
> the timestamping stuff. The standard PHY functions just call the
> generic functions, so the PHY works fine even without this driver.
>
>> > +static struct ptp_clock *dp83640_clock;
>> > +DEFINE_SPINLOCK(clock_lock); /* protects the one and only dp83640_clock */
>>
>> Why only one?  Is it not possible to have 2 of these PHYs in a system?
>
> Yes, you can have multiple PHYs, but only one PTP clock.
>
> If you do use multiple PHYs, then you must wire their clocks together
> and adjust the PTP clock on only one of the PHYs.
>
>
> Thanks for your other comments,

You're welcome.  Make sure to cc: linux-kernel on your next posting.
I commented on what I could, but there is a lot of code outside my
areas of expertise.  In particular the time keeping code needs to be
looked at by the maintainers in that area.

Cheers,
g.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]

[Kumar Gala]

On Jun 16, 2010, at 1:58 AM, Micha Nelissen wrote:

> Hi,
> 
> Attached is a patch to fix large physical address support for the e500v2 
> core. When >4GB addresses are used, the MAS7 register needs to be valid for 
> tlbsx instruction usage.
> 
> Please review and apply.
> 
> Micha
> diff -u -ru linux-2.6.34/arch/powerpc/include/asm/reg.h 
> linux-2.6.34-fix/arch/powerpc/include/asm/reg.h
> --- linux-2.6.34/arch/powerpc/include/asm/reg.h   2010-05-16 
> 23:17:36.0 +0200
> +++ linux-2.6.34-fix/arch/powerpc/include/asm/reg.h   2010-06-16 
> 08:43:28.0 +0200
> @@ -272,6 +272,7 @@
> #define HID0_DAPUEN   (1<<8)  /* Debug APU enable */
> #define HID0_SGE  (1<<7)  /* Store Gathering Enable */
> #define HID0_SIED (1<<7)  /* Serial Instr. Execution [Disable] */
> +#define HID0_EN_MAS7_UPDATE (1<<7)  /* tlbre/tlbsx update MAS7 - e500v2 
> */
> #define HID0_DCFA (1<<6)  /* Data Cache Flush Assist */
> #define HID0_LRSTK(1<<4)  /* Link register stack - 745x */
> #define HID0_BTIC (1<<5)  /* Branch Target Instr Cache Enable */
> diff -u -ru linux-2.6.34/arch/powerpc/kernel/head_fsl_booke.S 
> linux-2.6.34-fix/arch/powerpc/kernel/head_fsl_booke.S
> --- linux-2.6.34/arch/powerpc/kernel/head_fsl_booke.S 2010-05-16 
> 23:17:36.0 +0200
> +++ linux-2.6.34-fix/arch/powerpc/kernel/head_fsl_booke.S 2010-06-16 
> 08:45:10.0 +0200
> @@ -328,6 +328,13 @@
>   orisr2,r2,hid0_d...@h
>   mtspr   SPRN_HID0, r2
> #endif
> +#ifdef CONFIG_PTE_64BIT
> +BEGIN_MMU_FTR_SECTION
> + mfspr   r2,SPRN_HID0
> + ori r2,r2,hid0_en_mas7_upd...@l
> + mtspr   SPRN_HID0, r2
> +END_MMU_FTR_SECTION_IFSET(MMU_FTR_BIG_PHYS)
> +#endif

If you want to do this, do it in:

arch/powerpc/kernel/cpu_setup_fsl_booke.S

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]

[Micha Nelissen]

Timur Tabi wrote:

I'm sorry, but Linux does depend on the boot loader, and U-Boot does
need to know whether Linux is going to use 36-bit addressing.  


Why?


That's
just the way it works. 


What a great design philosophy!


Linux patches that repeat what U-Boot already
does just so that you don't need to update your U-boot are going to be
rejected.


Who said anything about not wanting/needing to upgrade U-boot?

Micha

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Request review of device tree documentation

[Nicolas Pitre]

On Wed, 16 Jun 2010, Mike Rapoport wrote:
> Mitch Bradley wrote:
> > One counterargument, of course, is that "there is a better way".  But it is
> > only "better" under a cost function that values things differently than the
> > vendors value them.  Were that not so, the vendors would gladly use the
> > "better" way and not be tempted to use the objectionable feature. (Unless,
> > of course, the vendors are just ignorant or unskilled - but I generally find
> > that different cost functions cause more disconnects than lack of ability.)
> 
> It's hardly arguable that Linux community and decision makers at chip vendor
> companies use different cost functions. But it's not that obvious that vendors
> cost functions based on well established _technical_ analysis.
> Many vendors try to use the same code base for several operating systems. From
> the high level perspective it sounds logical: use the same core functionality
> and thin adaptation layers to fit the core functionality into several OSes.
> But in reality, developing the OS abstraction layer and "thin" adaptation
> layers may become more expensive than developing each OS support from scratch.
> Besides, such code becomes a real mess after a while, and it's maintainability
> is very questionable.

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.

> > Which of course raises the question:  How does the Linux community view such
> > SoC vendors?  Are they embraced and eagerly supported, 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.


Nicolas
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/iseries: fix constant warning

[Denis Kirjanov]

Fix smatch warning: constant 0x8000 is so big it is unsigned long

Signed-off-by: Denis Kirjanov 
---
arch/powerpc/include/asm/abs_addr.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/include/asm/abs_addr.h 
b/arch/powerpc/include/asm/abs_addr.h
index 98324c5..c3bffc3 100644
--- a/arch/powerpc/include/asm/abs_addr.h
+++ b/arch/powerpc/include/asm/abs_addr.h
@@ -69,7 +69,7 @@ static inline unsigned long phys_to_abs(unsigned long pa)
  * Legacy iSeries Hypervisor calls
  */
 #define iseries_hv_addr(virtaddr)  \
-   (0x8000 | virt_to_abs(virtaddr))
+   (0x8000UL | virt_to_abs(virtaddr))
 
 #endif /* __KERNEL__ */
 #endif /* _ASM_POWERPC_ABS_ADDR_H */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]

[Timur Tabi]

On Wed, Jun 16, 2010 at 4:24 AM, Micha Nelissen  wrote:

> IMHO:
> 1) Linux should not be dependent on U-boot or any other bootloader, or at
> least as possible
> 2) U-boot cannot (and does not want to) know whether Linux is going to use
> large physical addresses.

To quote The Dude: "Yeah, well, you know, that's just, like, your opinion, man."

I'm sorry, but Linux does depend on the boot loader, and U-Boot does
need to know whether Linux is going to use 36-bit addressing.  That's
just the way it works.  Linux patches that repeat what U-Boot already
does just so that you don't need to update your U-boot are going to be
rejected.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 08/12] ptp: Added a brand new class driver for ptp clocks.

[Richard Cochran]

On Tue, Jun 15, 2010 at 11:00:10AM -0600, Grant Likely wrote:
> 
> Question from an ignorant reviewer:  Why a new interface instead of
> working with the existing high resolution timers infrastructure?

Short answer: Timers are only one part of the PTP API. If you offer
the PTP clock as a Linux clock source, then you could just use the
existing POSIX timers. However, we decided not to offer the PTP clock
in that way. The following excerpts from an upcoming paper explain
why:

\subsection{Basic Clock Operations}

   Based on our experience with a number of commercially available
   hardware clocks, we identified a set of four basic clock
   operations. Besides simply setting or getting the clock's time
   value, two additional operations are needed for clock control.
   Once a PTP slave has an initial estimate of the offset to its
   master, it typically would need to shift the clock by the offset
   atomically.  Also, the servo loop of a slave periodically needs to
   adjust the clock frequency.

\subsection{Ancillary Clock Features}

   Perhaps the most challenging design issue was deciding how to offer
   a PTP clock's capabilities to the GNU/Linux operating system.  As
   John Eidson pointed out~\cite{eidson2006measurement}, modern
   operating systems provide surprisingly little support for
   programming based on absolute time.  As the IEEE 1588 standard is
   being applied to a wide variety of test, measurement, and control
   applications, we can imagine many possible ways to use an embedded
   computer equipped with a PTP hardware clock.  We do not expect that
   any API will be able to cover every conceivable application of this
   technology.  However, the design presented here does cover common
   use cases based on the capabilities of currently available hardware
   clocks.

   The design allows user space programs to control all of a clock's
   ancillary features.  Programs may create one-shot or periodic
   alarms, with signal delivery on expiration.  \Timestamps on
   external events are provided via a First In, First Out (FIFO)
   interface.  If the clock has output signals, then their periods are
   configurable from user space.  Synchronization of the Linux system
   time via the PPS subsystem may be enabled or disabled as desired.

\subsection{Synchronizing the Linux System Clock}

   One important question that needed to be addressed was, now that we
   have a precise time source, how do we synchronize the Linux kernel
   to it?  The Linux kernel offers a modular clock infrastructure
   comprising ``clock sources'' and ``clock event devices.'' Clock
   sources provide a monotonically increasing time base, and clock
   event devices are used to schedule the next interrupt for various
   timer events.

   We considered but ultimately rejected the idea of offering the PTP
   clock to the Linux kernel as a combined clock source and clock
   event device.  The one great advantage of this approach would have
   been that it obviates the need for synchronization when the PTP
   clock is selected as the system timer.

   However, this approach is problematic when using certain kinds of
   clock hardware. For example, physical layer (PHY) chip based clocks
   can only be accessed by the relatively slow 16 bit wide MDIO
   bus. Such a clock would not be suitable for providing high
   resolution timers, which are now a standard Linux kernel feature.
   Furthermore, we cannot even be sure that a given hardware clock
   will offer any interrupt to the system at all.

   Instead, we elected to use the Pulse Per Second (PPS) subsystem as
   a method to optionally synchronize the Linux system time to the PTP
   clock.  This method is feasible even for clocks that do not offer
   fast register access, such as the PHY clocks.  Of course, the main
   disadvantage of this approach is that the Linux system time will
   not be exactly synchronized to the PTP clock time.  Since PTP
   clocks can be synchronized an order of magnitude better than the
   typical operating system scheduling latency, we expect that this
   method will still yield acceptable results for many applications.
   Applications with more demanding time requirements may use the new
   PTP interfaces directly when needed.

\subsection{System Calls or Character Device}

   When adding new functionality to an operating system, a basic design
   decision is how user space programs will call into the kernel.  For
   the Linux kernel, two different ways come into question, namely
   system calls or as a ``character device.''  In an attempt to make
   the PTP clock API easy to understand, we patterned it after the
   existing Network Time Protocol (NTP) and the POSIX timer APIs, as
   described in Section~\ref{UserAPI}.  Both of these services are
   exported to the user space as system calls.  However, we decided to
   offer the PTP clock as a character device because extending the NTP
   and POSIX interfaces seemed impractical.  In addition, th

Re: Request review of device tree documentation

[Jamie Bennett]

On 16 Jun 2010, at 12:41, Jamie Lokier wrote:
> Mike Rapoport wrote:
>>> Which of course raises the question:  How does the Linux community view 
>>> such SoC vendors?  Are they embraced and eagerly supported, 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.
> 
> As far as I can tell, many such vendors don't have much interest in
> contributing to the Linux community either.  They use Linux code, glue
> in their black-box binary modules and/or HALs, and engage poorly with
> the community.  It is not just end-product makers, but upstream
> component, board and SDK manufacturers too.

That is what we are trying to change [1].

> -- Jamie

Regards,
Jamie.

[1] http://www.linaro.org

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]

[Aggrwal Poonam-B10812]

> -Original Message-
> From: Micha Nelissen [mailto:mi...@neli.hopto.org]
> Sent: Wednesday, June 16, 2010 5:04 PM
> To: Aggrwal Poonam-B10812
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
> 
> Aggrwal Poonam-B10812 wrote:
> > Not sure of other platforms but on 85xx platforms on which I am
> > currently working u-boot does LAW and eLBC programming for 36bit
> > physical address. Hence possibly u-boot has to made aware of large
> > physical address space.
> > Please correct me if I am wrong.
> 
> Yes, I can understand this for SDRAM and local flash interface. For
> RapidIO we have (local) patches to pass the law address range in the
dtb.
> Perhaps also for PCI-express this might be done; U-boot has nothing to
> with these high speed interfaces (in our case at least).
You are correct , for PCIe and SRIO kinds of interfaces Linux reprograms
the address windows.
Thanks
Poonam
> 
> Micha

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Request review of device tree documentation

[Jamie Lokier]

Mike Rapoport wrote:
> >Which of course raises the question:  How does the Linux community view 
> >such SoC vendors?  Are they embraced and eagerly supported, 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.

As far as I can tell, many such vendors don't have much interest in
contributing to the Linux community either.  They use Linux code, glue
in their black-box binary modules and/or HALs, and engage poorly with
the community.  It is not just end-product makers, but upstream
component, board and SDK manufacturers too.

-- Jamie
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]

[Micha Nelissen]

Aggrwal Poonam-B10812 wrote:

Not sure of other platforms but on 85xx platforms on which I am
currently working u-boot does LAW and eLBC programming for 36bit
physical address. Hence 
possibly u-boot has to made aware of large physical address space.

Please correct me if I am wrong.


Yes, I can understand this for SDRAM and local flash interface. For 
RapidIO we have (local) patches to pass the law address range in the 
dtb. Perhaps also for PCI-express this might be done; U-boot has nothing 
to with these high speed interfaces (in our case at least).


Micha
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]

[Aggrwal Poonam-B10812]

> -Original Message-
> From: Micha Nelissen [mailto:mi...@neli.hopto.org]
> Sent: Wednesday, June 16, 2010 2:55 PM
> To: Aggrwal Poonam-B10812; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
> 
> Aggrwal Poonam-B10812 wrote:
> >> Attached is a patch to fix large physical address support for the
> >
> > This is already being done by u-boot, should linux set it again?
> 
> Yikes! Took me 5 min to reformat your email.
> 
> Our version of U-boot does not but it's not latest greatest.
> 
> IMHO:
> 1) Linux should not be dependent on U-boot or any other bootloader, or
at
> least as possible
> 2) U-boot cannot (and does not want to) know whether Linux is going to
> use large physical addresses.
> 
Not sure of other platforms but on 85xx platforms on which I am
currently working u-boot does LAW and eLBC programming for 36bit
physical address. Hence 
possibly u-boot has to made aware of large physical address space.
Please correct me if I am wrong.
> Regards,
> 
> Micha

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Request review of device tree documentation

[Mike Rapoport]

Mitch Bradley wrote:

Mike Rapoport wrote:

Mitch Bradley wrote:

Mike Rapoport wrote:

Mitch Bradley wrote:

Mike Rapoport wrote:

Mitch Bradley wrote:

The second topic is the hypothetical use of OFW as a HAL. That 
will not happen for several reasons.  The opposition to the idea 
is widespread and deeply held, and there are good arguments to 
support that opposition.   Furthermore, the economic conditions 
necessary for the creation of such a HAL do not exist in the ARM 
world, nor indeed in the Linux world in general.  (The necessary 
condition is the ability for one company to impose a substantial 
change by fiat - essentially a monopoly position.)


Shall we agree, then, that any further discussion of the HAL 
issue is "just for fun", and that nobody needs to feel threatened 
that it would actually happen?


I've recently worked with vendor versions of U-Boot for advanced 
ARM SoCs. There is already *huge* chunk of HAL code in those 
versions. And if there would be possibility to have callbacks into 
the firmware these chunks would only grow, IMHO.


How can there be HAL code in U-Boot unless there is already the 
possibility to have callbacks into the firmware?


Currently it aims to abstract hardware from U-Boot and reuse the 
same HW access code across operating systems and bootloaders. If 
this code would have callbacks I afraid the things would became worse.


The only way I can understand what you said is if I assume that by 
"callback", you mean the following sequence:


a) U-boot loads and executes the OS, providing to the OS the address 
of some HW access routines that it can use

b) The OS calls one of those HW access routines
c) During the execution of that HW access routine, that routine calls 
"back" into the OS, before returning.  So a call into the OS is 
nested inside a call into U-boot resident code.


If that is what you are worried about, it is not what we were 
discussing.  We were discussing - and many people were against - step 
(b).


Are you saying that step (b) - the OS calling into routines provided 
by U-Boot - is already the status quo?


I'm also objecting the step (b) and, fortunately, it's not yet the 
status quo.
Current U-Boot/kernel implementations I've encountered still do not 
have OS calls to resident HW access routines. But if such calls would 
be allowed, my impression is that SoC vendors would make extensive use 
of them.


One could argue that a feature that vendors would use extensively is one 
that is sorely needed from their point of view.


One counterargument, of course, is that "there is a better way".  But it 
is only "better" under a cost function that values things differently 
than the vendors value them.  Were that not so, the vendors would gladly 
use the "better" way and not be tempted to use the objectionable 
feature. (Unless, of course, the vendors are just ignorant or unskilled 
- but I generally find that different cost functions cause more 
disconnects than lack of ability.)


It's hardly arguable that Linux community and decision makers at chip 
vendor companies use different cost functions. But it's not that obvious 
that vendors cost functions based on well established _technical_ analysis.
Many vendors try to use the same code base for several operating 
systems. From the high level perspective it sounds logical: use the same 
core functionality and thin adaptation layers to fit the core 
functionality into several OSes. But in reality, developing the OS 
abstraction layer and "thin" adaptation layers may become more expensive 
than developing each OS support from scratch. Besides, such code becomes 
a real mess after a while, and it's maintainability is very questionable.


Which of course raises the question:  How does the Linux community view 
such SoC vendors?  Are they embraced and eagerly supported, 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.







It is not HAL if it can't be called.




The potential for "vendors breaking out of the debugging use case 
and turning it into a HAL" is miniscule, because


a) The callback is disabled by default
b) The technical challenges of the callback interface limit its 
applicability to specific "wizard user" scenarios
c) OFW is unlikely to achieve sufficient market penetration for 
the HAL thing to be worth doing



___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel












--
Sincerely yours,
Mike.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Request review of device tree documentation

[Vladimir Pantelic]

Mitch Bradley wrote:


 I'm also objecting the step (b) and, fortunately, it's not yet the
 status quo.
 Current U-Boot/kernel implementations I've encountered still do not
 have OS calls to resident HW access routines. But if such calls would
 be allowed, my impression is that SoC vendors would make extensive use
 of them.


One could argue that a feature that vendors would use extensively is one
that is sorely needed from their point of view.


yes, it would free them from writing these pesky linux drivers and getting
them into mainline :)

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 2.6.35 v3] powerpc: fix logic error in fixup_irqs

[Johannes Berg]

When SPARSE_IRQ is set, irq_to_desc() can
return NULL. While the code here has a
check for NULL, it's not really correct.
Fix it by separating the check for it.

This fixes CPU hot unplug for me.

Reported-by: Alastair Bridgewater 
Cc: sta...@kernel.org [2.6.32+]
Signed-off-by: Johannes Berg 
---
v2: cc Alastair, sorry
v3: indicate stable versions

 arch/powerpc/kernel/irq.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--- wireless-testing.orig/arch/powerpc/kernel/irq.c 2010-06-11 
22:51:08.0 +0200
+++ wireless-testing/arch/powerpc/kernel/irq.c  2010-06-11 22:54:11.0 
+0200
@@ -295,7 +295,10 @@ void fixup_irqs(const struct cpumask *ma
 
for_each_irq(irq) {
desc = irq_to_desc(irq);
-   if (desc && desc->status & IRQ_PER_CPU)
+   if (!desc)
+   continue;
+
+   if (desc->status & IRQ_PER_CPU)
continue;
 
cpumask_and(mask, desc->affinity, map);



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 12/12] ptp: Added a clock driver for the National Semiconductor PHYTER.

[Richard Cochran]

On Tue, Jun 15, 2010 at 12:49:13PM -0600, Grant Likely wrote:
> Won't this break things for existing DP83640 users?

Nope, the driver was only added five patches ago, and it only offers
the timestamping stuff. The standard PHY functions just call the
generic functions, so the PHY works fine even without this driver.

> > +static struct ptp_clock *dp83640_clock;
> > +DEFINE_SPINLOCK(clock_lock); /* protects the one and only dp83640_clock */
> 
> Why only one?  Is it not possible to have 2 of these PHYs in a system?

Yes, you can have multiple PHYs, but only one PTP clock.

If you do use multiple PHYs, then you must wire their clocks together
and adjust the PTP clock on only one of the PHYs.


Thanks for your other comments,

Richard
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]

[Micha Nelissen]

Aggrwal Poonam-B10812 wrote:

Attached is a patch to fix large physical address support for the


This is already being done by u-boot, should linux set it again?


Yikes! Took me 5 min to reformat your email.

Our version of U-boot does not but it's not latest greatest.

IMHO:
1) Linux should not be dependent on U-boot or any other bootloader, or 
at least as possible
2) U-boot cannot (and does not want to) know whether Linux is going to 
use large physical addresses.


Regards,

Micha
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]

[Aggrwal Poonam-B10812]

> -Original Message-
> From:
linuxppc-dev-bounces+poonam.aggrwal=freescale@lists.ozlabs.org
> [mailto:linuxppc-dev-
> bounces+poonam.aggrwal=freescale@lists.ozlabs.org] On Behalf Of
Micha
> Nelissen
> Sent: Wednesday, June 16, 2010 12:29 PM
> To: linuxppc-dev@lists.ozlabs.org
> Subject: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
> 
> Hi,
> 
> Attached is a patch to fix large physical address support for the
e500v2
> core. When >4GB addresses are used, the MAS7 register needs to be
valid
> for tlbsx instruction usage.
> 
> Please review and apply.
[Aggrwal Poonam] This is already being done by u-boot, should linux set
it again?
> 
> Micha
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Request review of device tree documentation

[Mitch Bradley]

Mike Rapoport wrote:

Mitch Bradley wrote:

Mike Rapoport wrote:

Mitch Bradley wrote:

Mike Rapoport wrote:

Mitch Bradley wrote:

The second topic is the hypothetical use of OFW as a HAL. That 
will not happen for several reasons.  The opposition to the idea 
is widespread and deeply held, and there are good arguments to 
support that opposition.   Furthermore, the economic conditions 
necessary for the creation of such a HAL do not exist in the ARM 
world, nor indeed in the Linux world in general.  (The necessary 
condition is the ability for one company to impose a substantial 
change by fiat - essentially a monopoly position.)


Shall we agree, then, that any further discussion of the HAL 
issue is "just for fun", and that nobody needs to feel threatened 
that it would actually happen?


I've recently worked with vendor versions of U-Boot for advanced 
ARM SoCs. There is already *huge* chunk of HAL code in those 
versions. And if there would be possibility to have callbacks into 
the firmware these chunks would only grow, IMHO.


How can there be HAL code in U-Boot unless there is already the 
possibility to have callbacks into the firmware?


Currently it aims to abstract hardware from U-Boot and reuse the 
same HW access code across operating systems and bootloaders. If 
this code would have callbacks I afraid the things would became worse.


The only way I can understand what you said is if I assume that by 
"callback", you mean the following sequence:


a) U-boot loads and executes the OS, providing to the OS the address 
of some HW access routines that it can use

b) The OS calls one of those HW access routines
c) During the execution of that HW access routine, that routine calls 
"back" into the OS, before returning.  So a call into the OS is 
nested inside a call into U-boot resident code.


If that is what you are worried about, it is not what we were 
discussing.  We were discussing - and many people were against - step 
(b).


Are you saying that step (b) - the OS calling into routines provided 
by U-Boot - is already the status quo?


I'm also objecting the step (b) and, fortunately, it's not yet the 
status quo.
Current U-Boot/kernel implementations I've encountered still do not 
have OS calls to resident HW access routines. But if such calls would 
be allowed, my impression is that SoC vendors would make extensive use 
of them.


One could argue that a feature that vendors would use extensively is one 
that is sorely needed from their point of view.


One counterargument, of course, is that "there is a better way".  But it 
is only "better" under a cost function that values things differently 
than the vendors value them.  Were that not so, the vendors would gladly 
use the "better" way and not be tempted to use the objectionable 
feature. (Unless, of course, the vendors are just ignorant or unskilled 
- but I generally find that different cost functions cause more 
disconnects than lack of ability.)


Which of course raises the question:  How does the Linux community view 
such SoC vendors?  Are they embraced and eagerly supported, 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?







It is not HAL if it can't be called.




The potential for "vendors breaking out of the debugging use case 
and turning it into a HAL" is miniscule, because


a) The callback is disabled by default
b) The technical challenges of the callback interface limit its 
applicability to specific "wizard user" scenarios
c) OFW is unlikely to achieve sufficient market penetration for 
the HAL thing to be worth doing



___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel










___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/5] Rework MPC5121 DIU support (for 2.6.35)

[Anatolij Gustschin]

Hi Timur,

On Fri, 4 Jun 2010 10:46:28 -0500
Timur Tabi  wrote:

> On Tue, Jun 1, 2010 at 4:38 AM, Anatolij Gustschin  wrote:
> 
> > Could you please test these patches on MPC8610 HPCD? I think these
> > changes won't break that platform. The patches apply cleanly on
> > 2.6.35-rc1.
> 
> I'll try to get to them as soon as I can.

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.

Thanks,
Anatolij
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]

[Micha Nelissen]

Hi,

Attached is a patch to fix large physical address support for the e500v2 
core. When >4GB addresses are used, the MAS7 register needs to be valid 
for tlbsx instruction usage.


Please review and apply.

Micha
diff -u -ru linux-2.6.34/arch/powerpc/include/asm/reg.h 
linux-2.6.34-fix/arch/powerpc/include/asm/reg.h
--- linux-2.6.34/arch/powerpc/include/asm/reg.h 2010-05-16 23:17:36.0 
+0200
+++ linux-2.6.34-fix/arch/powerpc/include/asm/reg.h 2010-06-16 
08:43:28.0 +0200
@@ -272,6 +272,7 @@
 #define HID0_DAPUEN(1<<8)  /* Debug APU enable */
 #define HID0_SGE   (1<<7)  /* Store Gathering Enable */
 #define HID0_SIED  (1<<7)  /* Serial Instr. Execution [Disable] */
+#define HID0_EN_MAS7_UPDATE (1<<7)  /* tlbre/tlbsx update MAS7 - e500v2 */
 #define HID0_DCFA  (1<<6)  /* Data Cache Flush Assist */
 #define HID0_LRSTK (1<<4)  /* Link register stack - 745x */
 #define HID0_BTIC  (1<<5)  /* Branch Target Instr Cache Enable */
diff -u -ru linux-2.6.34/arch/powerpc/kernel/head_fsl_booke.S 
linux-2.6.34-fix/arch/powerpc/kernel/head_fsl_booke.S
--- linux-2.6.34/arch/powerpc/kernel/head_fsl_booke.S   2010-05-16 
23:17:36.0 +0200
+++ linux-2.6.34-fix/arch/powerpc/kernel/head_fsl_booke.S   2010-06-16 
08:45:10.0 +0200
@@ -328,6 +328,13 @@
orisr2,r2,hid0_d...@h
mtspr   SPRN_HID0, r2
 #endif
+#ifdef CONFIG_PTE_64BIT
+BEGIN_MMU_FTR_SECTION
+   mfspr   r2,SPRN_HID0
+   ori r2,r2,hid0_en_mas7_upd...@l
+   mtspr   SPRN_HID0, r2
+END_MMU_FTR_SECTION_IFSET(MMU_FTR_BIG_PHYS)
+#endif
 
 #if !defined(CONFIG_BDI_SWITCH)
/*
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Request review of device tree documentation

[M. Warner Losh]

In message: <4c187013.5000...@firmworks.com>
Mitch Bradley  writes:
: Mike Rapoport wrote:
: > Mitch Bradley wrote:
: >> Mike Rapoport wrote:
: >>> Mitch Bradley wrote:
: >>>
:  The second topic is the hypothetical use of OFW as a HAL. That will
:  not happen for several reasons.  The opposition to the idea is
:  widespread and deeply held, and there are good arguments to support
:  that opposition.  Furthermore, the economic conditions necessary for
:  the creation of such a HAL do not exist in the ARM world, nor indeed
:  in the Linux world in general.  (The necessary condition is the
:  ability for one company to impose a substantial change by fiat -
:  essentially a monopoly position.)
: 
:  Shall we agree, then, that any further discussion of the HAL issue is
:  "just for fun", and that nobody needs to feel threatened that it would
:  actually happen?
: >>>
: >>> I've recently worked with vendor versions of U-Boot for advanced ARM
: >>> SoCs. There is already *huge* chunk of HAL code in those versions. And
: >>> if there would be possibility to have callbacks into the firmware
: >>> these chunks would only grow, IMHO.
: >>
: >> How can there be HAL code in U-Boot unless there is already the
: >> possibility to have callbacks into the firmware?
: >
: > Currently it aims to abstract hardware from U-Boot and reuse the same
: > HW access code across operating systems and bootloaders. If this code
: > would have callbacks I afraid the things would became worse.
: 
: The only way I can understand what you said is if I assume that by
: "callback", you mean the following sequence:
: 
: a) U-boot loads and executes the OS, providing to the OS the address
: of some HW access routines that it can use
: b) The OS calls one of those HW access routines
: c) During the execution of that HW access routine, that routine calls
: "back" into the OS, before returning.  So a call into the OS is nested
: inside a call into U-boot resident code.
: 
: If that is what you are worried about, it is not what we were
: discussing.  We were discussing - and many people were against - step
: (b).
: 
: Are you saying that step (b) - the OS calling into routines provided
: by U-Boot - is already the status quo?

I don't know about status quo, but it certainly is supported.  There's
an option to allow for a secondary boot loader, such as FreeBSD's
/boot/loader, to call back into uboot to read things from
flash/disk/whatever, do network access, etc.  Not so much a HAL, but
more of an echo of the functionality provided by PC BIOS functions.
/boot/loader can be viewed as a mini OS that calls back into uboot to
have it do things.  Once /boot/loader loads FreeBSD, btw, it and uboot
disappear from the scene, so this isn't exactly a HAL situation...

Warner


: >
: >> It is not HAL if it can't be called.
: >>
: >>>
: >>>
:  The potential for "vendors breaking out of the debugging use case and
:  turning it into a HAL" is miniscule, because
: 
:  a) The callback is disabled by default
:  b) The technical challenges of the callback interface limit its
:  applicability to specific "wizard user" scenarios
:  c) OFW is unlikely to achieve sufficient market penetration for the
:  HAL thing to be worth doing
: 
: 
:  ___
:  linux-arm-kernel mailing list
:  linux-arm-ker...@lists.infradead.org
:  http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
: >>>
: >>>
: >
: >
: ___
: devicetree-discuss mailing list
: devicetree-disc...@lists.ozlabs.org
: https://lists.ozlabs.org/listinfo/devicetree-discuss
: 
: 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Request review of device tree documentation

[Mike Rapoport]

Mitch Bradley wrote:

The second topic is the hypothetical use of OFW as a HAL. That will not 
happen for several reasons.  The opposition to the idea is widespread 
and deeply held, and there are good arguments to support that 
opposition.   Furthermore, the economic conditions necessary for the 
creation of such a HAL do not exist in the ARM world, nor indeed in the 
Linux world in general.  (The necessary condition is the ability for one 
company to impose a substantial change by fiat - essentially a monopoly 
position.)


Shall we agree, then, that any further discussion of the HAL issue is 
"just for fun", and that nobody needs to feel threatened that it would 
actually happen?


I've recently worked with vendor versions of U-Boot for advanced ARM 
SoCs. There is already *huge* chunk of HAL code in those versions. And 
if there would be possibility to have callbacks into the firmware these 
chunks would only grow, IMHO.



The potential for "vendors breaking out of the debugging use case and 
turning it into a HAL" is miniscule, because


a) The callback is disabled by default
b) The technical challenges of the callback interface limit its 
applicability to specific "wizard user" scenarios
c) OFW is unlikely to achieve sufficient market penetration for the HAL 
thing to be worth doing



___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



--
Sincerely yours,
Mike.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev