* Re: [PATCH 1/3] i2c: move of_i2c_register_devices call into core
From: Rob Herring @ 2011-08-05 23:22 UTC (permalink / raw)
To: Grant Likely
Cc: Stephen Warren, Sebastian Andrzej Siewior, linux-kernel,
Dirk Brandewie, linux-i2c, Ben Dooks, Jean Delvare, linuxppc-dev
In-Reply-To: <20110805225435.GA6404@ponder.secretlab.ca>
Grant,
On 08/05/2011 05:54 PM, Grant Likely wrote:
> On Fri, Aug 05, 2011 at 04:24:26PM -0500, Rob Herring wrote:
>> From: Rob Herring <rob.herring@calxeda.com>
>>
>> All callers of of_i2c_register_devices are immediately preceded by a call
>> to i2c_add_adapter or i2c_add_numbered_adapter. Add call to
>> of_i2c_register_devices and remove all other callers.
>>
>> This causes a module dependency loop that is resolved by the next commit.
>
> Wrong way around. Don't break bisectability. I'll leave it up to Ben
> and Jean on weather or not they want to move this code. I intend to
> do the same thing for spi/gpio, but I maintain those subsystems so I
> get to choose. i2c is not up to me.
>
Well, I know, but it's only broken for bisect in the case of both being
modules. So it's only run-time brokenness. That's better than the 3
months it was broken before. I couldn't come up with a better way. The
choices I thought of were:
-temporarily exporting and adding of_i2c_register_devices to i2c.h and
then removing it. I'm not a fan of adding that churn.
-just combining it all into 1 patch.
-reverse the order and leave i2c device registration broken for 1
commit. Thinking some more about it, perhaps that is a bit better than
broken module loading. Guess it depends if you are doing modules or
built-in.
Rob
> g.
>
>>
>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>> Cc: Grant Likely <grant.likely@secretlab.ca>
>> Cc: Jochen Friedrich <jochen@scram.de>
>> Cc: Jean Delvare <khali@linux-fr.org>
>> Cc: Ben Dooks <ben-linux@fluff.org>
>> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>> Cc: Dirk Brandewie <dirk.brandewie@gmail.com>
>> Cc: Stephen Warren <swarren@nvidia.com>
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Cc: linux-i2c@vger.kernel.org
>> ---
>> drivers/i2c/busses/i2c-cpm.c | 6 ------
>> drivers/i2c/busses/i2c-ibm_iic.c | 4 ----
>> drivers/i2c/busses/i2c-mpc.c | 2 --
>> drivers/i2c/busses/i2c-pxa.c | 2 --
>> drivers/i2c/busses/i2c-tegra.c | 3 ---
>> drivers/i2c/i2c-core.c | 4 ++++
>> 6 files changed, 4 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
>> index b1d9cd2..7cbc82a 100644
>> --- a/drivers/i2c/busses/i2c-cpm.c
>> +++ b/drivers/i2c/busses/i2c-cpm.c
>> @@ -42,7 +42,6 @@
>> #include <linux/dma-mapping.h>
>> #include <linux/of_device.h>
>> #include <linux/of_platform.h>
>> -#include <linux/of_i2c.h>
>> #include <sysdev/fsl_soc.h>
>> #include <asm/cpm.h>
>>
>> @@ -673,11 +672,6 @@ static int __devinit cpm_i2c_probe(struct platform_device *ofdev)
>> dev_dbg(&ofdev->dev, "hw routines for %s registered.\n",
>> cpm->adap.name);
>>
>> - /*
>> - * register OF I2C devices
>> - */
>> - of_i2c_register_devices(&cpm->adap);
>> -
>> return 0;
>> out_shut:
>> cpm_i2c_shutdown(cpm);
>> diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c
>> index 3c110fb..5ba15ba 100644
>> --- a/drivers/i2c/busses/i2c-ibm_iic.c
>> +++ b/drivers/i2c/busses/i2c-ibm_iic.c
>> @@ -42,7 +42,6 @@
>> #include <linux/io.h>
>> #include <linux/i2c.h>
>> #include <linux/of_platform.h>
>> -#include <linux/of_i2c.h>
>>
>> #include "i2c-ibm_iic.h"
>>
>> @@ -759,9 +758,6 @@ static int __devinit iic_probe(struct platform_device *ofdev)
>> dev_info(&ofdev->dev, "using %s mode\n",
>> dev->fast_mode ? "fast (400 kHz)" : "standard (100 kHz)");
>>
>> - /* Now register all the child nodes */
>> - of_i2c_register_devices(adap);
>> -
>> return 0;
>>
>> error_cleanup:
>> diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
>> index 107397a..a433f59 100644
>> --- a/drivers/i2c/busses/i2c-mpc.c
>> +++ b/drivers/i2c/busses/i2c-mpc.c
>> @@ -18,7 +18,6 @@
>> #include <linux/sched.h>
>> #include <linux/init.h>
>> #include <linux/of_platform.h>
>> -#include <linux/of_i2c.h>
>> #include <linux/slab.h>
>>
>> #include <linux/io.h>
>> @@ -637,7 +636,6 @@ static int __devinit fsl_i2c_probe(struct platform_device *op)
>> dev_err(i2c->dev, "failed to add adapter\n");
>> goto fail_add;
>> }
>> - of_i2c_register_devices(&i2c->adap);
>>
>> return result;
>>
>> diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
>> index d603646..c1c2885 100644
>> --- a/drivers/i2c/busses/i2c-pxa.c
>> +++ b/drivers/i2c/busses/i2c-pxa.c
>> @@ -29,7 +29,6 @@
>> #include <linux/errno.h>
>> #include <linux/interrupt.h>
>> #include <linux/i2c-pxa.h>
>> -#include <linux/of_i2c.h>
>> #include <linux/platform_device.h>
>> #include <linux/err.h>
>> #include <linux/clk.h>
>> @@ -1147,7 +1146,6 @@ static int i2c_pxa_probe(struct platform_device *dev)
>> printk(KERN_INFO "I2C: Failed to add bus\n");
>> goto eadapt;
>> }
>> - of_i2c_register_devices(&i2c->adap);
>>
>> platform_set_drvdata(dev, i2c);
>>
>> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
>> index 2440b74..9ec0a58 100644
>> --- a/drivers/i2c/busses/i2c-tegra.c
>> +++ b/drivers/i2c/busses/i2c-tegra.c
>> @@ -26,7 +26,6 @@
>> #include <linux/delay.h>
>> #include <linux/slab.h>
>> #include <linux/i2c-tegra.h>
>> -#include <linux/of_i2c.h>
>>
>> #include <asm/unaligned.h>
>>
>> @@ -653,8 +652,6 @@ static int tegra_i2c_probe(struct platform_device *pdev)
>> goto err_free_irq;
>> }
>>
>> - of_i2c_register_devices(&i2c_dev->adapter);
>> -
>> return 0;
>> err_free_irq:
>> free_irq(i2c_dev->irq, i2c_dev);
>> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
>> index 131079a..011e195 100644
>> --- a/drivers/i2c/i2c-core.c
>> +++ b/drivers/i2c/i2c-core.c
>> @@ -32,6 +32,7 @@
>> #include <linux/init.h>
>> #include <linux/idr.h>
>> #include <linux/mutex.h>
>> +#include <linux/of_i2c.h>
>> #include <linux/of_device.h>
>> #include <linux/completion.h>
>> #include <linux/hardirq.h>
>> @@ -863,6 +864,9 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
>> if (adap->nr < __i2c_first_dynamic_bus_num)
>> i2c_scan_static_board_info(adap);
>>
>> + /* Register devices from the device tree */
>> + of_i2c_register_devices(adap);
>> +
>> /* Notify drivers */
>> mutex_lock(&core_lock);
>> bus_for_each_drv(&i2c_bus_type, NULL, adap, __process_new_adapter);
>> --
>> 1.7.4.1
>>
^ permalink raw reply
* Re: [PATCH 02/15] [PS3] Get lv1 high memory region from devtree
From: Andre Heider @ 2011-08-06 11:50 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <4E3AF1E4.90407@infradead.org>
On Thu, Aug 4, 2011 at 9:24 PM, Geoff Levand <geoff@infradead.org> wrote:
> Also, it needs to be considered that a lot of kernels are out
> there will be confused if started with high mem already allocated.
True, but is there anything we can do about that?
Isn't is okay to tell users of first stage boot loaders utilizing this
mechanism that whatever steps their boot chain contains has to support
this highmem pass over? As far as I can tell all current loaders won't
be affected by this patch.
When a user wants to chain a loader with this mechanism with
petitboot, he needs a petitboot coming with a kernel containing this
feature, and can then kexec whatever contains it too.
>> Using the lv1 repo is an option, but does it make sense? It's even less
>> standard than a FDT and we'd have to put both the region1 location and
>> the initrd location in there (there's no point to maintaining highmem if
>> you aren't going to use it).
>>
>> FWIW, the lv1 repo writing hypercalls are unused and undocumented.
>
> The hcalls to create, write, and delete nodes are known, but I don't
> recall if I verified they work:
>
> =A0http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;a=
=3Dblob;f=3Darch/powerpc/include/asm/lv1call.h;hb=3DHEAD#l265
>
> #92 should be named lv1_write_repository_node.
>
> You can only modify the repo for your lpar, so:
>
> =A0lv1_{create,write}_repository_node(n1, n2, n3, n4, v1, v2);
> =A0lv1_delete_repository_node(n1, n2, n3, n4);
I tried this and it indeed works - I can pass over the highmem info
just fine using repository nodes.
If there is a chance that another OS might require this highmem pass
over then I agree that using the repository makes more sense.
I can prepare a patch for that, replacing this one. Any suggestions on
which nodes to use?
For a test run I used:
FIELD_FIRST("bi", 0),
FIELD("highmem", 0),
FIELD("address", 0),
0
and
FIELD_FIRST("bi", 0),
FIELD("highmem", 0),
FIELD("size", 0),
0
Regards,
Andre
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 09/15] ps3: Limit the number of regions per storage device
From: Andre Heider @ 2011-08-06 12:28 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Geoff Levand, cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <CAHsu+b_zsBeK1JcNA2XsB+Hh9+eYxAkuMU_4hWZ-Q5zEs_Vcug@mail.gmail.com>
On Mon, Aug 1, 2011 at 10:58 PM, Andre Heider <a.heider@gmail.com> wrote:
> On Mon, Aug 1, 2011 at 10:30 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Mon, Aug 1, 2011 at 22:03, Andre Heider <a.heider@gmail.com> wrote:
>>> There can be only 8 regions, add a sanity check
>>
>> Why can there be only 8 regions?
>
> I believe lv1 limits it to 8? I might be mistaken here, it mostly is a
> check for the patches after this one
Small follow-up:
While the repository contains ("bus", "dev", "n_regs") to describe the
actual number of regions, it also contains ("bus", "dev", "region", [
"id" | "start" | "size" ]) for always exactly 8 regions (with a value
of 0xdeadbeef for invalid regions).
I added this check for the storage drivers, which contain:
for (region_idx = 0; region_idx < dev->num_regions; region_idx++) {
...
gendisk->first_minor = devidx * PS3DISK_MINORS + region_idx;
But that limit might be raised in future hypervisor versions.
Maybe a
BUG_ON(dev->num_regions <= PS3DISK_MINORS);
is more appropriate?
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 07/15] ps3flash: Refuse to work in lpars other than OtherOS
From: Andre Heider @ 2011-08-06 12:40 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Geoff Levand, cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <CAMuHMdVe9+Y4Xn24BpR+1zFF3Wes6uvwx-EA3A2jASyoA66Vjg@mail.gmail.com>
On Thu, Aug 4, 2011 at 9:27 PM, Geert Uytterhoeven <geert@linux-m68k.org> w=
rote:
> On Thu, Aug 4, 2011 at 18:40, Andre Heider <a.heider@gmail.com> wrote:
>> On Thu, Aug 4, 2011 at 12:34 AM, Geoff Levand <geoff@infradead.org> wrot=
e:
>>> On 08/01/2011 01:02 PM, Andre Heider wrote:
>>>> --- a/drivers/char/ps3flash.c
>>>> +++ b/drivers/char/ps3flash.c
>>>> @@ -25,6 +25,7 @@
>>>>
>>>> =A0#include <asm/lv1call.h>
>>>> =A0#include <asm/ps3stor.h>
>>>> +#include <asm/firmware.h>
>>>>
>>>>
>>>> =A0#define DEVICE_NAME =A0 =A0 =A0 =A0 =A0"ps3flash"
>>>> @@ -455,6 +456,12 @@ static struct ps3_system_bus_driver ps3flash =3D =
{
>>>>
>>>> =A0static int __init ps3flash_init(void)
>>>> =A0{
>>>> + =A0 =A0 if (!firmware_has_feature(FW_FEATURE_PS3_LV1))
>>>> + =A0 =A0 =A0 =A0 =A0 =A0 return -ENODEV;
>>>
>>> Is this needed? =A0Won't this driver only be loaded on PS3 hardware?
>>>
>>
>> The same code is in drivers/block/ps3disk.c, I wasn't sure if it is
>> missing here or redundant there.
>> Should I remove it here?
>>
>>>> +
>>>> + =A0 =A0 if (ps3_get_ss_laid() !=3D PS3_SS_LAID_OTHEROS)
>>>> + =A0 =A0 =A0 =A0 =A0 =A0 return -ENODEV;
>>>> +
>>>> =A0 =A0 =A0 return ps3_system_bus_driver_register(&ps3flash);
>>>> =A0}
>
> ps3flash_init() is called straight from module_init(), so it could be
> called on non-PS3.
> ps3_system_bus_driver_register() has the firmware_has_feature_check(),
> so it will
> reject non-PS3.
>
> But if your *_init() does any processing before calling
> ps3_system_bus_driver_register()
> (like ps3disk_init() does, and ps3flash_init() now does due to your
> patch), you have to
> do the check yourself, to make sure it returns early on non-PS3.
Aha, makes perfect sense.
Thanks Geert
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 09/15] ps3: Limit the number of regions per storage device
From: Andre Heider @ 2011-08-06 12:47 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Geoff Levand, cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <CAHsu+b9hLnhoCOH5jj3SmZWp+jZdCWTN74nbMkyqDNKkDpdnMA@mail.gmail.com>
On Sat, Aug 6, 2011 at 2:28 PM, Andre Heider <a.heider@gmail.com> wrote:
> On Mon, Aug 1, 2011 at 10:58 PM, Andre Heider <a.heider@gmail.com> wrote:
>> On Mon, Aug 1, 2011 at 10:30 PM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> On Mon, Aug 1, 2011 at 22:03, Andre Heider <a.heider@gmail.com> wrote:
>>>> There can be only 8 regions, add a sanity check
>>>
>>> Why can there be only 8 regions?
>>
>> I believe lv1 limits it to 8? I might be mistaken here, it mostly is a
>> check for the patches after this one
>
> Small follow-up:
> While the repository contains ("bus", "dev", "n_regs") to describe the
> actual number of regions, it also contains ("bus", "dev", "region", [
> "id" | "start" | "size" ]) for always exactly 8 regions (with a value
> of 0xdeadbeef for invalid regions).
>
> I added this check for the storage drivers, which contain:
> =A0for (region_idx =3D 0; region_idx < dev->num_regions; region_idx++) {
> =A0 =A0...
> =A0 =A0gendisk->first_minor =3D devidx * PS3DISK_MINORS + region_idx;
>
> But that limit might be raised in future hypervisor versions.
> Maybe a
> =A0BUG_ON(dev->num_regions <=3D PS3DISK_MINORS);
> is more appropriate?
Of course I meant the exact opposite, heh:
=A0BUG_ON(dev->num_regions > PS3DISK_MINORS);
^ permalink raw reply
* Re: [RFC 4/4] [powerpc] Implement a p1010rdb clock source.
From: Marc Kleine-Budde @ 2011-08-06 13:58 UTC (permalink / raw)
To: Robin Holt; +Cc: socketcan-core, netdev, U Bhaskar-B22300, linuxppc-dev
In-Reply-To: <1312603504-30282-5-git-send-email-holt@sgi.com>
[-- Attachment #1: Type: text/plain, Size: 3946 bytes --]
On 08/06/2011 06:05 AM, Robin Holt wrote:
> flexcan driver needs the clk_get, clk_get_rate, etc functions
> to work. This patch provides the minimum functionality.
This patch has to go via the powerpc git tree. Added
linuxppc-dev@lists.ozlabs.org on CC.
> Signed-off-by: Robin Holt <holt@sgi.com>
> To: Marc Kleine-Budde <mkl@pengutronix.de>
> To: Wolfgang Grandegger <wg@grandegger.com>
> To: U Bhaskar-B22300 <B22300@freescale.com>
> Cc: socketcan-core@lists.berlios.de
> Cc: netdev@vger.kernel.org
> ---
> arch/powerpc/platforms/85xx/p1010rdb.c | 78 ++++++++++++++++++++++++++++++++
> 1 files changed, 78 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/85xx/p1010rdb.c b/arch/powerpc/platforms/85xx/p1010rdb.c
> index 3540a88..8f78ddd 100644
> --- a/arch/powerpc/platforms/85xx/p1010rdb.c
> +++ b/arch/powerpc/platforms/85xx/p1010rdb.c
> @@ -28,6 +28,7 @@
> #include <asm/udbg.h>
> #include <asm/mpic.h>
> #include <asm/swiotlb.h>
> +#include <asm/clk_interface.h>
>
> #include <sysdev/fsl_soc.h>
> #include <sysdev/fsl_pci.h>
> @@ -164,6 +165,82 @@ static void __init p1010_rdb_setup_arch(void)
> printk(KERN_INFO "P1010 RDB board from Freescale Semiconductor\n");
> }
>
> +/*
> + * p1010rdb needs to provide a clock source for the flexcan driver.
> + */
> +struct clk {
> + unsigned long rate;
> +} p1010rdb_system_clk;
> +
> +static struct clk *p1010_rdb_clk_get(struct device *dev, const char *id)
> +{
> + struct clk *clk;
> + u32 *of_property;
> + unsigned long clock_freq, clock_divider;
> + const char *dev_init_name;
> +
> + if (!dev)
> + return ERR_PTR(-ENOENT);
> +
> + /*
> + * The can devices are named ffe1c000.can0 and ffe1d000.can1 on
> + * the p1010rdb. Check for the "can" portion of that name before
> + * returning a clock source.
> + */
> + dev_init_name = dev_name(dev);
> + if (strlen(dev_init_name) != 13)
> + return ERR_PTR(-ENOENT);
> + dev_init_name += 9;
> + if (strncmp(dev_init_name, "can", 3))
> + return ERR_PTR(-ENOENT);
> +
> + of_property = (u32 *)of_get_property(dev->of_node, "clock_freq", NULL);
> + if (!of_property)
> + return ERR_PTR(-ENOENT);
> + clock_freq = *of_property;
> +
> + of_property = (u32 *)of_get_property(dev->of_node,
> + "fsl,flexcan-clock-divider", NULL);
> + if (!of_property)
> + return ERR_PTR(-ENOENT);
> + clock_divider = *of_property;
> +
> + clk = kmalloc(sizeof(struct clk), GFP_KERNEL);
> + if (!clk)
> + return ERR_PTR(-ENOMEM);
> +
> + clk->rate = DIV_ROUND_CLOSEST(clock_freq / clock_divider, 1000);
> + clk->rate *= 1000;
> +
> + return clk;
> +}
> +
> +static void p1010_rdb_clk_put(struct clk *clk)
> +{
> + kfree(clk);
> +}
> +
> +static unsigned long p1010_rdb_clk_get_rate(struct clk *clk)
> +{
> + return clk->rate;
> +}
> +
> +static struct clk_interface p1010_rdb_clk_functions = {
> + .clk_get = p1010_rdb_clk_get,
> + .clk_get_rate = p1010_rdb_clk_get_rate,
> + .clk_put = p1010_rdb_clk_put,
> +};
> +
> +static void __init p1010_rdb_clk_init(void)
> +{
> + clk_functions = p1010_rdb_clk_functions;
> +}
> +
> +static void __init p1010_rdb_init(void)
> +{
> + p1010_rdb_clk_init();
> +}
> +
> static struct of_device_id __initdata p1010rdb_ids[] = {
> { .type = "soc", },
> { .compatible = "soc", },
> @@ -195,6 +272,7 @@ define_machine(p1010_rdb) {
> .name = "P1010 RDB",
> .probe = p1010_rdb_probe,
> .setup_arch = p1010_rdb_setup_arch,
> + .init = p1010_rdb_init,
> .init_IRQ = p1010_rdb_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: [RFC 4/4] [powerpc] Implement a p1010rdb clock source.
From: Kumar Gala @ 2011-08-06 16:52 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Netdev, U Bhaskar-B22300, socketcan-core, Robin Holt,
linuxppc-dev@lists.ozlabs.org Development
In-Reply-To: <4E3D4875.30707@pengutronix.de>
On Aug 6, 2011, at 8:58 AM, Marc Kleine-Budde wrote:
> On 08/06/2011 06:05 AM, Robin Holt wrote:
>> flexcan driver needs the clk_get, clk_get_rate, etc functions
>> to work. This patch provides the minimum functionality.
>=20
> This patch has to go via the powerpc git tree. Added
> linuxppc-dev@lists.ozlabs.org on CC.
>=20
>> Signed-off-by: Robin Holt <holt@sgi.com>
>> To: Marc Kleine-Budde <mkl@pengutronix.de>
>> To: Wolfgang Grandegger <wg@grandegger.com>
>> To: U Bhaskar-B22300 <B22300@freescale.com>
>> Cc: socketcan-core@lists.berlios.de
>> Cc: netdev@vger.kernel.org
>> ---
>> arch/powerpc/platforms/85xx/p1010rdb.c | 78 =
++++++++++++++++++++++++++++++++
>> 1 files changed, 78 insertions(+), 0 deletions(-)
NAK.
This doesn't look right at all. We should be doing something based on =
the device tree node that isn't board specific.
I believe Bhaskar has a version of flexcan support that he's been =
working on cleanup up for upstream.
- k=
^ permalink raw reply
* Re: [RFC 4/4] [powerpc] Implement a p1010rdb clock source.
From: Robin Holt @ 2011-08-06 20:50 UTC (permalink / raw)
To: Kumar Gala
Cc: Netdev, U Bhaskar-B22300, socketcan-core, Robin Holt,
linuxppc-dev@lists.ozlabs.org Development
In-Reply-To: <39414D86-7822-4B92-B005-351890A2A167@kernel.crashing.org>
On Sat, Aug 06, 2011 at 11:52:45AM -0500, Kumar Gala wrote:
>
> On Aug 6, 2011, at 8:58 AM, Marc Kleine-Budde wrote:
>
> > On 08/06/2011 06:05 AM, Robin Holt wrote:
> >> flexcan driver needs the clk_get, clk_get_rate, etc functions
> >> to work. This patch provides the minimum functionality.
> >
> > This patch has to go via the powerpc git tree. Added
> > linuxppc-dev@lists.ozlabs.org on CC.
> >
> >> Signed-off-by: Robin Holt <holt@sgi.com>
> >> To: Marc Kleine-Budde <mkl@pengutronix.de>
> >> To: Wolfgang Grandegger <wg@grandegger.com>
> >> To: U Bhaskar-B22300 <B22300@freescale.com>
> >> Cc: socketcan-core@lists.berlios.de
> >> Cc: netdev@vger.kernel.org
> >> ---
> >> arch/powerpc/platforms/85xx/p1010rdb.c | 78 ++++++++++++++++++++++++++++++++
> >> 1 files changed, 78 insertions(+), 0 deletions(-)
>
> NAK.
>
> This doesn't look right at all. We should be doing something based on the device tree node that isn't board specific.
>
> I believe Bhaskar has a version of flexcan support that he's been working on cleanup up for upstream.
That version may be similar to what is in the freescale BSP which puts
the clock functions inside flexcan.c
The powerpc arch already provides a means for individual boards to provide
the clock functions. I am not posting this patch here for acceptance
for powerpc and I am sure I will get feedback there when I post to
their mailing list. I am posting it here only to show that the flexcan
developers earlier assertion that this can and should be done in the arch
tree is correct and will work for the p1010 assuming we can get changes
into the arch/powerpc directory to implement these clk_* functions.
Thanks,
Robin
^ permalink raw reply
* Re: [RFC 4/4] [powerpc] Implement a p1010rdb clock source.
From: Kumar Gala @ 2011-08-06 20:59 UTC (permalink / raw)
To: Robin Holt
Cc: Netdev, U Bhaskar-B22300, socketcan-core,
linuxppc-dev@lists.ozlabs.org Development
In-Reply-To: <20110806205010.GQ4926@sgi.com>
On Aug 6, 2011, at 3:50 PM, Robin Holt wrote:
> On Sat, Aug 06, 2011 at 11:52:45AM -0500, Kumar Gala wrote:
>>=20
>> On Aug 6, 2011, at 8:58 AM, Marc Kleine-Budde wrote:
>>=20
>>> On 08/06/2011 06:05 AM, Robin Holt wrote:
>>>> flexcan driver needs the clk_get, clk_get_rate, etc functions
>>>> to work. This patch provides the minimum functionality.
>>>=20
>>> This patch has to go via the powerpc git tree. Added
>>> linuxppc-dev@lists.ozlabs.org on CC.
>>>=20
>>>> Signed-off-by: Robin Holt <holt@sgi.com>
>>>> To: Marc Kleine-Budde <mkl@pengutronix.de>
>>>> To: Wolfgang Grandegger <wg@grandegger.com>
>>>> To: U Bhaskar-B22300 <B22300@freescale.com>
>>>> Cc: socketcan-core@lists.berlios.de
>>>> Cc: netdev@vger.kernel.org
>>>> ---
>>>> arch/powerpc/platforms/85xx/p1010rdb.c | 78 =
++++++++++++++++++++++++++++++++
>>>> 1 files changed, 78 insertions(+), 0 deletions(-)
>>=20
>> NAK.
>>=20
>> This doesn't look right at all. We should be doing something based =
on the device tree node that isn't board specific.
>>=20
>> I believe Bhaskar has a version of flexcan support that he's been =
working on cleanup up for upstream.
>=20
> That version may be similar to what is in the freescale BSP which puts
> the clock functions inside flexcan.c
>=20
> The powerpc arch already provides a means for individual boards to =
provide
> the clock functions. I am not posting this patch here for acceptance
> for powerpc and I am sure I will get feedback there when I post to
> their mailing list. I am posting it here only to show that the =
flexcan
> developers earlier assertion that this can and should be done in the =
arch
> tree is correct and will work for the p1010 assuming we can get =
changes
> into the arch/powerpc directory to implement these clk_* functions.
My point is that I don't think they should live in the arch code. The =
clk_* functions you want to implement are tied more the FlexCAN IP than =
anything arch specific. As such I believe they should be in the driver.
For example when FSL has a P9999 with FlexCAN on it, we should NOT have =
to add any arch code to support it.
- k=
^ permalink raw reply
* Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty & young
From: Mike Frysinger @ 2011-08-08 2:31 UTC (permalink / raw)
To: Peter Zijlstra
Cc: tony.luck, Shan Hai, linux-kernel, cmetcalf, stable,
David Howells, paulus, uclinux-dist-devel, tglx, walken,
linuxppc-dev, akpm
In-Reply-To: <1311761831.24752.413.camel@twins>
On Wed, Jul 27, 2011 at 06:17, Peter Zijlstra wrote:
> On Wed, 2011-07-27 at 11:09 +0100, David Howells wrote:
>> Can you inline this for the NOMMU case please?
>
> ---
> Subject: mm: Fix fixup_user_fault() for MMU=n
>
> In commit 2efaca927 ("mm/futex: fix futex writes on archs with SW
> tracking of dirty & young") we forgot about MMU=n. This patch fixes
> that.
can we get this merged ? mainline is now broken, linux-next is still
broken, and it seems gregkh is pulling this into the stable 3.0.1
which means that's going to be broken too.
-mike
^ permalink raw reply
* RE: FW: Ethernet driver WR linux
From: smitha.vanga @ 2011-08-08 5:53 UTC (permalink / raw)
To: scottwood; +Cc: linuxppc-dev
In-Reply-To: <4E3C3270.2010705@freescale.com>
Hi Scott,
Below is the .dts file. My board is based on mpc8247. Currently using
FCC1.
/*
* MPC8272 EPN412 Device Tree Source
*
* Copyright 2005 Freescale Semiconductor Inc.
*
* 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.
*/
/ {
model =3D "MPC8247 EPN412";
compatible =3D "MPC82XX";
#address-cells =3D <1>;
#size-cells =3D <1>;
linux,phandle =3D <100>;
cpus {
#cpus =3D <1>;
#address-cells =3D <1>;
#size-cells =3D <0>;
linux,phandle =3D <200>;
PowerPC,8247@0 {
device_type =3D "cpu";
reg =3D <0>;
d-cache-line-size =3D <20>; // 32 bytes
i-cache-line-size =3D <20>; // 32 bytes
d-cache-size =3D <4000>; // L1, 16K
i-cache-size =3D <4000>; // L1, 16K
timebase-frequency =3D <0>;
bus-frequency =3D <0>;
clock-frequency =3D <0>;
32-bit;
linux,phandle =3D <201>;
};
};
interrupt-controller@f8200000 {
linux,phandle =3D <f8200000>;
#address-cells =3D <0>;
#interrupt-cells =3D <2>;
interrupt-controller;
reg =3D <f8200000 f8200004>;
built-in;
device_type =3D "pci-pic";
};
memory {
device_type =3D "memory";
linux,phandle =3D <300>;
reg =3D <00000000 4000000>;
};
soc8272@f0000000 {
#address-cells =3D <1>;
#size-cells =3D <1>;
#interrupt-cells =3D <2>;
device_type =3D "soc";
ranges =3D <00000000 f0000000 00053000>;
reg =3D <f0000000 10000>;
cpm@119c0{
linux,phandle =3D <f0000000>;
#address-cells =3D <1>;
#size-cells =3D <1>;
#interrupt-cells =3D <2>;
device_type =3D "cpm";
model =3D "CPM2";
ranges =3D <00000000 00000000 20000>;
reg =3D <0 20000>;
command-proc =3D <119c0>;
brg-frequency =3D <FE70B8>;
cpm_clk =3D <7F385C0>;
scc@11a00 {
device_type =3D "serial";
compatible =3D "cpm_uart";
model =3D "SCC";
device-id =3D <1>;
reg =3D <11a00 20 8000 100>;
current-speed =3D <2580>;
interrupts =3D <28 2>;
interrupt-parent =3D <10c00>;
clock-setup =3D <0 00ffffff>;
rx-clock =3D <1>;
tx-clock =3D <1>;
};
mdio@10d40 {
device_type =3D "mdio";
compatible =3D "fs_enet";
reg =3D <0 0>;
linux,phandle =3D <24520>;
#address-cells =3D <1>;
#size-cells =3D <0>;
ethernet-phy@0 {
linux,phandle =3D <2452000>;
interrupt-parent =3D <10c00>;
interrupts =3D <17 4>;
reg =3D <0>;
bitbang =3D [ 12 12 13 02 02 01 ];
device_type =3D "ethernet-phy";
};
};
ethernet@11300 {
#address-cells =3D <1>;
#size-cells =3D <0>;
device_type =3D "network";
device-id =3D <1>;
compatible =3D "fs_enet";
model =3D "FCC";
reg =3D <11300 20 8400 100 11380 30>;
mac-address =3D [ 00 e0 ee 00 05 2e ];
interrupts =3D <20 2>;
interrupt-parent =3D <10c00>;
phy-handle =3D <2452000>;
rx-clock =3D <13>;
tx-clock =3D <12>;
};
};
interrupt-controller@10c00 {
linux,phandle =3D <10c00>;
#address-cells =3D <0>;
#interrupt-cells =3D <2>;
interrupt-controller;
reg =3D <10c00 80>;
built-in;
device_type =3D "cpm-pic";
compatible =3D "CPM2";
};
flash@fe000000 {
device_type =3D "rom";
compatible =3D "direct-mapped";
probe-type =3D "CFI";
reg =3D <fe000000 00800000>;
bank-width =3D <1>;
partitions =3D <00780000 00080000
00770000 00010000
00760000 00010000
00750000
00010000>;
partition-names =3D
"u-boot\0u-boot env1\0u-boot env2\0id data";
};
};
};
Regards,
Smitha
Please do not print this email unless it is absolutely necessary. =0A=
=0A=
The information contained in this electronic message and any attachments to=
this message are intended for the exclusive use of the addressee(s) and may=
contain proprietary, confidential or privileged information. If you are not=
the intended recipient, you should not disseminate, distribute or copy this=
e-mail. Please notify the sender immediately and destroy all copies of this=
message and any attachments. =0A=
=0A=
WARNING: Computer viruses can be transmitted via email. The recipient should=
check this email and any attachments for the presence of viruses. The compa=
ny accepts no liability for any damage caused by any virus transmitted by th=
is email. =0A=
=0A=
www.wipro.com
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: David Gibson @ 2011-08-08 6:07 UTC (permalink / raw)
To: Alex Williamson
Cc: Alexey Kardashevskiy, kvm, Paul Mackerras, Joerg Roedel,
Anthony Liguori, linux-pci@vger.kernel.org, linuxppc-dev
In-Reply-To: <1312557012.2559.34.camel@x201.home>
On Fri, Aug 05, 2011 at 09:10:09AM -0600, Alex Williamson wrote:
> On Fri, 2011-08-05 at 20:42 +1000, Benjamin Herrenschmidt wrote:
> > Right. In fact to try to clarify the problem for everybody, I think we
> > can distinguish two different classes of "constraints" that can
> > influence the grouping of devices:
> >
> > 1- Hard constraints. These are typically devices using the same RID or
> > where the RID cannot be reliably guaranteed (the later is the case with
> > some PCIe-PCIX bridges which will take ownership of "some" transactions
> > such as split but not all). Devices like that must be in the same
> > domain. This is where PowerPC adds to what x86 does today the concept
> > that the domains are pre-existing, since we use the RID for error
> > isolation & MMIO segmenting as well. so we need to create those domains
> > at boot time.
> >
> > 2- Softer constraints. Those constraints derive from the fact that not
> > applying them risks enabling the guest to create side effects outside of
> > its "sandbox". To some extent, there can be "degrees" of badness between
> > the various things that can cause such constraints. Examples are shared
> > LSIs (since trusting DisINTx can be chancy, see earlier discussions),
> > potentially any set of functions in the same device can be problematic
> > due to the possibility to get backdoor access to the BARs etc...
>
> This is what I've been trying to get to, hardware constraints vs system
> policy constraints.
>
> > Now, what I derive from the discussion we've had so far, is that we need
> > to find a proper fix for #1, but Alex and Avi seem to prefer that #2
> > remains a matter of libvirt/user doing the right thing (basically
> > keeping a loaded gun aimed at the user's foot with a very very very
> > sweet trigger but heh, let's not start a flamewar here :-)
>
> Doesn't your own uncertainty of whether or not to allow this lead to the
> same conclusion, that it belongs in userspace policy? I don't think we
> want to make white lists of which devices we trust to do DisINTx
> correctly part of the kernel interface, do we? Thanks,
Yes, but the overall point is that both the hard and soft constraints
are much easier to handle if a group or iommu domain or whatever is a
persistent entity that can be set up once-per-boot by the admin with
whatever degree of safety they want, rather than a transient entity
tied to an fd's lifetime, which must be set up correctly, every time,
by the thing establishing it.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] PSeries: Cancel RTAS event scan before firmware flash
From: Suzuki Poulose @ 2011-08-08 6:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: mikey, sbest, Ravi K. Nittala, antonb, subrata.modak, ranittal,
linuxppc-dev, divya.vikas
In-Reply-To: <20110727120801.10429.7276.stgit@localhost6.localdomain6>
On 07/27/11 17:39, Ravi K. Nittala wrote:
> The firmware flash update is conducted using an RTAS call, that is serialized
> by lock_rtas() which uses spin_lock. rtasd keeps scanning for the RTAS events
> generated on the machine. This is performed via a delayed workqueue, invoking
> an RTAS call to scan the events.
>
> The flash update takes a while to complete and during this time, any other
> RTAS call has to wait. In this case, rtas_event_scan() waits for a long time
> on the spin_lock resulting in a soft lockup.
>
> Approaches to fix the issue :
>
> Approach 1: Stop all the other CPUs before we start flashing the firmware.
>
> Before the rtas firmware update starts, all other CPUs should be stopped.
> Which means no other CPU should be in lock_rtas(). We do not want other CPUs
> execute while FW update is in progress and the system will be rebooted anyway
> after the update.
>
> --- arch/powerpc/kernel/setup-common.c.orig 2011-07-01 22:41:12.952507971 -0400
> +++ arch/powerpc/kernel/setup-common.c 2011-07-01 22:48:31.182507915 -0400
> @@ -109,11 +109,12 @@ void machine_shutdown(void)
> void machine_restart(char *cmd)
> {
> machine_shutdown();
> - if (ppc_md.restart)
> - ppc_md.restart(cmd);
> #ifdef CONFIG_SMP
> - smp_send_stop();
> + smp_send_stop();
> #endif
> + if (ppc_md.restart)
> + ppc_md.restart(cmd);
> +
> printk(KERN_EMERG "System Halted, OK to turn off power\n");
> local_irq_disable();
> while (1) ;
>
> Problems with this approach:
> Stopping the CPUs suddenly may cause other serious problems depending on what
> was running on them. Hence, this approach cannot be considered.
>
>
> Approach 2: Cancel the rtas_scan_event work before starting the firmware flash.
>
> Just before the flash update is performed, the queued rtas_event_scan() work
> item is cancelled from the work queue so that there is no other RTAS call
> issued while the flash is in progress. After the flash completes, the system
> reboots and the rtas_event_scan() is rescheduled.
>
> Approach 2 looks to be a better solution than Approach 1. Kindly let us know
> your thoughts. Patch attached.
>
Ben,
Could you please let us know your thoughts about the following patch ?
Thanks
Suzuki
>
> Signed-off-by: Suzuki Poulose<suzuki@in.ibm.com>
> Signed-off-by: Ravi Nittala<ravi.nittala@in.ibm.com>
>
>
> ---
> arch/powerpc/include/asm/rtas.h | 2 ++
> arch/powerpc/kernel/rtas_flash.c | 6 ++++++
> arch/powerpc/kernel/rtasd.c | 6 ++++++
> 3 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
> index 58625d1..3f26f87 100644
> --- a/arch/powerpc/include/asm/rtas.h
> +++ b/arch/powerpc/include/asm/rtas.h
> @@ -245,6 +245,8 @@ extern int early_init_dt_scan_rtas(unsigned long node,
>
> extern void pSeries_log_error(char *buf, unsigned int err_type, int fatal);
>
> +extern bool rtas_cancel_event_scan(void);
> +
> /* Error types logged. */
> #define ERR_FLAG_ALREADY_LOGGED 0x0
> #define ERR_FLAG_BOOT 0x1 /* log was pulled from NVRAM on boot */
> diff --git a/arch/powerpc/kernel/rtas_flash.c b/arch/powerpc/kernel/rtas_flash.c
> index e037c74..4174b4b 100644
> --- a/arch/powerpc/kernel/rtas_flash.c
> +++ b/arch/powerpc/kernel/rtas_flash.c
> @@ -568,6 +568,12 @@ static void rtas_flash_firmware(int reboot_type)
> }
>
> /*
> + * Just before starting the firmware flash, cancel the event scan work
> + * to avoid any soft lockup issues.
> + */
> + rtas_cancel_event_scan();
> +
> + /*
> * NOTE: the "first" block must be under 4GB, so we create
> * an entry with no data blocks in the reserved buffer in
> * the kernel data segment.
> diff --git a/arch/powerpc/kernel/rtasd.c b/arch/powerpc/kernel/rtasd.c
> index 481ef06..e8f03fa 100644
> --- a/arch/powerpc/kernel/rtasd.c
> +++ b/arch/powerpc/kernel/rtasd.c
> @@ -472,6 +472,12 @@ static void start_event_scan(void)
> &event_scan_work, event_scan_delay);
> }
>
> +/* Cancel the rtas event scan work */
> +bool rtas_cancel_event_scan(void)
> +{
> + return cancel_delayed_work_sync(&event_scan_work);
> +}
> +
> static int __init rtas_init(void)
> {
> struct proc_dir_entry *entry;
>
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Avi Kivity @ 2011-08-08 8:28 UTC (permalink / raw)
To: Alex Williamson, aafabbri, Alexey Kardashevskiy, kvm,
Paul Mackerras, qemu-devel, chrisw, iommu, Anthony Liguori,
linux-pci@vger.kernel.org, linuxppc-dev, benve
In-Reply-To: <20110803020422.GF29719@yookeroo.fritz.box>
On 08/03/2011 05:04 AM, David Gibson wrote:
> I still don't understand the distinction you're making. We're saying
> the group is "owned" by a given user or guest in the sense that no-one
> else may use anything in the group (including host drivers). At that
> point none, some or all of the devices in the group may actually be
> used by the guest.
>
> You seem to be making a distinction between "owned by" and "assigned
> to" and "used by" and I really don't see what it is.
>
Alex (and I) think that we should work with device/function granularity,
as is common with other archs, and that the group thing is just a
constraint on which functions may be assigned where, while you think
that we should work at group granularity, with 1-function groups for
archs which don't have constraints.
Is this an accurate way of putting it?
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [RFC 4/4] [powerpc] Implement a p1010rdb clock source.
From: Wolfgang Grandegger @ 2011-08-08 8:49 UTC (permalink / raw)
To: Kumar Gala
Cc: Netdev, U Bhaskar-B22300, socketcan-core, Robin Holt,
linuxppc-dev@lists.ozlabs.org Development
In-Reply-To: <3C4B6145-5C75-4A3C-B504-DA32E0D2EC8A@kernel.crashing.org>
On 08/06/2011 10:59 PM, Kumar Gala wrote:
>
> On Aug 6, 2011, at 3:50 PM, Robin Holt wrote:
>
>> On Sat, Aug 06, 2011 at 11:52:45AM -0500, Kumar Gala wrote:
>>>
>>> On Aug 6, 2011, at 8:58 AM, Marc Kleine-Budde wrote:
>>>
>>>> On 08/06/2011 06:05 AM, Robin Holt wrote:
>>>>> flexcan driver needs the clk_get, clk_get_rate, etc functions
>>>>> to work. This patch provides the minimum functionality.
>>>>
>>>> This patch has to go via the powerpc git tree. Added
>>>> linuxppc-dev@lists.ozlabs.org on CC.
>>>>
>>>>> Signed-off-by: Robin Holt <holt@sgi.com>
>>>>> To: Marc Kleine-Budde <mkl@pengutronix.de>
>>>>> To: Wolfgang Grandegger <wg@grandegger.com>
>>>>> To: U Bhaskar-B22300 <B22300@freescale.com>
>>>>> Cc: socketcan-core@lists.berlios.de
>>>>> Cc: netdev@vger.kernel.org
>>>>> ---
>>>>> arch/powerpc/platforms/85xx/p1010rdb.c | 78 ++++++++++++++++++++++++++++++++
>>>>> 1 files changed, 78 insertions(+), 0 deletions(-)
>>>
>>> NAK.
>>>
>>> This doesn't look right at all. We should be doing something based on the device tree node that isn't board specific.
>>>
>>> I believe Bhaskar has a version of flexcan support that he's been working on cleanup up for upstream.
>>
>> That version may be similar to what is in the freescale BSP which puts
>> the clock functions inside flexcan.c
>>
>> The powerpc arch already provides a means for individual boards to provide
>> the clock functions. I am not posting this patch here for acceptance
>> for powerpc and I am sure I will get feedback there when I post to
>> their mailing list. I am posting it here only to show that the flexcan
>> developers earlier assertion that this can and should be done in the arch
>> tree is correct and will work for the p1010 assuming we can get changes
>> into the arch/powerpc directory to implement these clk_* functions.
>
> My point is that I don't think they should live in the arch code. The clk_* functions you want to implement are tied more the FlexCAN IP than anything arch specific. As such I believe they should be in the driver.
>
> For example when FSL has a P9999 with FlexCAN on it, we should NOT have to add any arch code to support it.
The Flexcan is found on ARM and now also on PowerPC SOCs. My current
understanding is that the ability to set the clock source and divider is
only available on PowerPC SOCs and therefore it's clearly arch specific
and should go to arch/powerpc/sysdev/fsl_soc.c if it's common for all
PowerPC platforms. What do you think?
Wolfgang.
^ permalink raw reply
* [PATCH v2] powerpc: 85xx: separate e500 from e500mc
From: Baruch Siach @ 2011-08-08 9:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood, Baruch Siach, Timur Tabi
In-Reply-To: <1fb57aeaeefcc40f6646d026caba8d40371d18fb.1312175199.git.baruch@tkos.co.il>
CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6, thus
breaking clear_pages(), probably others too.
This patch adds a new "Processor Type" entry for e500mc, and makes e500 systems
depend on PPC_E500.
Cc: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
Changes from v1:
* Rebase on 3.1-rc1
* Remove the list of processor families from the PPC_E500 and
PPC_E500MC options description. The P20xx can be either e500v2 or
e500mc.
arch/powerpc/platforms/85xx/Kconfig | 13 +++++++++----
arch/powerpc/platforms/Kconfig.cputype | 27 +++++++++++++++------------
2 files changed, 24 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 498534c..0132b21 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -13,6 +13,8 @@ if FSL_SOC_BOOKE
if PPC32
+if PPC_E500
+
config MPC8540_ADS
bool "Freescale MPC8540 ADS"
select DEFAULT_UIMAGE
@@ -171,10 +173,13 @@ config SBC8560
help
This option enables support for the Wind River SBC8560 board
+endif # PPC_E500
+
+if PPC_E500MC
+
config P2040_RDB
bool "Freescale P2040 RDB"
select DEFAULT_UIMAGE
- select PPC_E500MC
select PHYS_64BIT
select SWIOTLB
select MPC8xxx_GPIO
@@ -186,7 +191,6 @@ config P2040_RDB
config P3041_DS
bool "Freescale P3041 DS"
select DEFAULT_UIMAGE
- select PPC_E500MC
select PHYS_64BIT
select SWIOTLB
select MPC8xxx_GPIO
@@ -198,7 +202,6 @@ config P3041_DS
config P4080_DS
bool "Freescale P4080 DS"
select DEFAULT_UIMAGE
- select PPC_E500MC
select PHYS_64BIT
select SWIOTLB
select MPC8xxx_GPIO
@@ -207,13 +210,15 @@ config P4080_DS
help
This option enables support for the P4080 DS board
+endif # PPC_E500MC
+
endif # PPC32
config P5020_DS
bool "Freescale P5020 DS"
+ depends on PPC_E500MC
select DEFAULT_UIMAGE
select E500
- select PPC_E500MC
select PHYS_64BIT
select SWIOTLB
select MPC8xxx_GPIO
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index e06e395..8f9bd9f 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -10,13 +10,13 @@ choice
prompt "Processor Type"
depends on PPC32
help
- There are five families of 32 bit PowerPC chips supported.
+ There are six families of 32 bit PowerPC chips supported.
The most common ones are the desktop and server CPUs (601, 603,
604, 740, 750, 74xx) CPUs from Freescale and IBM, with their
embedded 512x/52xx/82xx/83xx/86xx counterparts.
- The other embeeded parts, namely 4xx, 8xx, e200 (55xx) and e500
- (85xx) each form a family of their own that is not compatible
- with the others.
+ The other embeeded parts, namely 4xx, 8xx, e200 (55xx), e500
+ (85xx), and e500mc each form a family of their own that is not
+ compatible with the others.
If unsure, select 52xx/6xx/7xx/74xx/82xx/83xx/86xx.
@@ -24,10 +24,15 @@ config PPC_BOOK3S_32
bool "512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx"
select PPC_FPU
-config PPC_85xx
- bool "Freescale 85xx"
+config PPC_E500
+ bool "Freescale e500v1/e500v2"
+ select PPC_85xx
select E500
+config PPC_E500MC
+ bool "Freescale e500mc/e5500"
+ select PPC_85xx
+
config PPC_8xx
bool "Freescale 8xx"
select FSL_SOC
@@ -128,15 +133,13 @@ config TUNE_CELL
config 8xx
bool
-config E500
+config PPC_85xx
+ bool
select FSL_EMB_PERFMON
select PPC_FSL_BOOK3E
- bool
-config PPC_E500MC
- bool "e500mc Support"
- select PPC_FPU
- depends on E500
+config E500
+ bool
config PPC_FPU
bool
--
1.7.5.4
^ permalink raw reply related
* Re: [RFC 4/4] [powerpc] Implement a p1010rdb clock source.
From: Marc Kleine-Budde @ 2011-08-08 9:32 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Netdev, U Bhaskar-B22300, socketcan-core, Robin Holt,
linuxppc-dev@lists.ozlabs.org Development
In-Reply-To: <4E3FA301.4050005@grandegger.com>
[-- Attachment #1: Type: text/plain, Size: 3244 bytes --]
On 08/08/2011 10:49 AM, Wolfgang Grandegger wrote:
> On 08/06/2011 10:59 PM, Kumar Gala wrote:
>>
>> On Aug 6, 2011, at 3:50 PM, Robin Holt wrote:
>>
>>> On Sat, Aug 06, 2011 at 11:52:45AM -0500, Kumar Gala wrote:
>>>>
>>>> On Aug 6, 2011, at 8:58 AM, Marc Kleine-Budde wrote:
>>>>
>>>>> On 08/06/2011 06:05 AM, Robin Holt wrote:
>>>>>> flexcan driver needs the clk_get, clk_get_rate, etc functions
>>>>>> to work. This patch provides the minimum functionality.
>>>>>
>>>>> This patch has to go via the powerpc git tree. Added
>>>>> linuxppc-dev@lists.ozlabs.org on CC.
>>>>>
>>>>>> Signed-off-by: Robin Holt <holt@sgi.com>
>>>>>> To: Marc Kleine-Budde <mkl@pengutronix.de>
>>>>>> To: Wolfgang Grandegger <wg@grandegger.com>
>>>>>> To: U Bhaskar-B22300 <B22300@freescale.com>
>>>>>> Cc: socketcan-core@lists.berlios.de
>>>>>> Cc: netdev@vger.kernel.org
>>>>>> ---
>>>>>> arch/powerpc/platforms/85xx/p1010rdb.c | 78 ++++++++++++++++++++++++++++++++
>>>>>> 1 files changed, 78 insertions(+), 0 deletions(-)
>>>>
>>>> NAK.
>>>>
>>>> This doesn't look right at all. We should be doing something based on the device tree node that isn't board specific.
>>>>
>>>> I believe Bhaskar has a version of flexcan support that he's been working on cleanup up for upstream.
>>>
>>> That version may be similar to what is in the freescale BSP which puts
>>> the clock functions inside flexcan.c
>>>
>>> The powerpc arch already provides a means for individual boards to provide
>>> the clock functions. I am not posting this patch here for acceptance
>>> for powerpc and I am sure I will get feedback there when I post to
>>> their mailing list. I am posting it here only to show that the flexcan
>>> developers earlier assertion that this can and should be done in the arch
>>> tree is correct and will work for the p1010 assuming we can get changes
>>> into the arch/powerpc directory to implement these clk_* functions.
>>
>> My point is that I don't think they should live in the arch code. The clk_* functions you want to implement are tied more the FlexCAN IP than anything arch specific. As such I believe they should be in the driver.
>>
>> For example when FSL has a P9999 with FlexCAN on it, we should NOT have to add any arch code to support it.
>
> The Flexcan is found on ARM and now also on PowerPC SOCs. My current
> understanding is that the ability to set the clock source and divider is
> only available on PowerPC SOCs and therefore it's clearly arch specific
> and should go to arch/powerpc/sysdev/fsl_soc.c if it's common for all
> PowerPC platforms. What do you think?
There is a bit in the CAN-Controller that selects the clock (at least on
arm). The current driver just supports the bus clock. Support for the
other, the oscillator clock, has not been implemented so far.
IIRC the oscillator clock has a frequency that results in worse standard
timing than the bus clock.
cheers, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* [PATCH] fsl-rio: Correct IECSR register clear value
From: Liu Gang @ 2011-08-08 10:13 UTC (permalink / raw)
To: linuxppc-dev; +Cc: r58472, Liu Gang, r61911, Liu Gang, akpm, B11780
The RETE bit in IECSR is cleared by writing a 1 to it.
Signed-off-by: Liu Gang <Gang.Liu@freescale.com>
---
arch/powerpc/sysdev/fsl_rio.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index b3fd081..cdd765b 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -54,6 +54,7 @@
#define ODSR_CLEAR 0x1c00
#define LTLEECSR_ENABLE_ALL 0xFFC000FC
#define ESCSR_CLEAR 0x07120204
+#define IECSR_CLEAR 0x80000000
#define RIO_PORT1_EDCSR 0x0640
#define RIO_PORT2_EDCSR 0x0680
@@ -1089,11 +1090,11 @@ static void port_error_handler(struct rio_mport *port, int offset)
if (offset == 0) {
out_be32((u32 *)(rio_regs_win + RIO_PORT1_EDCSR), 0);
- out_be32((u32 *)(rio_regs_win + RIO_PORT1_IECSR), 0);
+ out_be32((u32 *)(rio_regs_win + RIO_PORT1_IECSR), IECSR_CLEAR);
out_be32((u32 *)(rio_regs_win + RIO_ESCSR), ESCSR_CLEAR);
} else {
out_be32((u32 *)(rio_regs_win + RIO_PORT2_EDCSR), 0);
- out_be32((u32 *)(rio_regs_win + RIO_PORT2_IECSR), 0);
+ out_be32((u32 *)(rio_regs_win + RIO_PORT2_IECSR), IECSR_CLEAR);
out_be32((u32 *)(rio_regs_win + RIO_PORT2_ESCSR), ESCSR_CLEAR);
}
}
--
1.7.3.1
^ permalink raw reply related
* [PATCH 6/9] arch/powerpc/platforms/pseries/iommu.c: add missing kfree
From: Julia Lawall @ 2011-08-08 11:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: devicetree-discuss, kernel-janitors, linux-kernel, Milton Miller,
Paul Gortmaker, Paul Mackerras, Will Schmidt, Nishanth Aravamudan,
linuxppc-dev
From: Julia Lawall <julia@diku.dk>
At this point, window has not been stored anywhere, so it has to be freed
before leaving the function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@exists@
local idexpression x;
statement S,S1;
expression E;
identifier fl;
expression *ptr != NULL;
@@
x = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
when != if (...) { <+...kfree(x)...+> }
when any
when != true x == NULL
x->fl
...>
(
if (x == NULL) S1
|
if (...) { ... when != x
when forall
(
return \(0\|<+...x...+>\|ptr\);
|
* return ...;
)
}
)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
arch/powerpc/platforms/pseries/iommu.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index 2b20b05..6351af8 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -940,14 +940,14 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
if (ret) {
dev_info(&dev->dev, "failed to map direct window for %s: %d\n",
dn->full_name, ret);
- goto out_clear_window;
+ goto out_free_window;
}
ret = prom_add_property(pdn, win64);
if (ret) {
dev_err(&dev->dev, "unable to add dma window property for %s: %d",
pdn->full_name, ret);
- goto out_clear_window;
+ goto out_free_window;
}
window->device = pdn;
@@ -959,6 +959,9 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
dma_addr = of_read_number(&create.addr_hi, 2);
goto out_unlock;
+out_free_window:
+ kfree(window);
+
out_clear_window:
remove_ddw(pdn);
^ permalink raw reply related
* [PATCH 8/9] arch/powerpc/sysdev/ehv_pic.c: add missing kfree
From: Julia Lawall @ 2011-08-08 11:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: kernel-janitors, Ashish Kalra, linux-kernel, Paul Mackerras,
linuxppc-dev, Timur Tabi
From: Julia Lawall <julia@diku.dk>
At this point, ehv_pic has been allocated but not stored anywhere, so it
should be freed before leaving the function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@exists@
local idexpression x;
statement S,S1;
expression E;
identifier fl;
expression *ptr != NULL;
@@
x = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
when != if (...) { <+...kfree(x)...+> }
when any
when != true x == NULL
x->fl
...>
(
if (x == NULL) S1
|
if (...) { ... when != x
when forall
(
return \(0\|<+...x...+>\|ptr\);
|
* return ...;
)
}
)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
arch/powerpc/sysdev/ehv_pic.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/sysdev/ehv_pic.c b/arch/powerpc/sysdev/ehv_pic.c
index af1a5df..b6731e4 100644
--- a/arch/powerpc/sysdev/ehv_pic.c
+++ b/arch/powerpc/sysdev/ehv_pic.c
@@ -280,6 +280,7 @@ void __init ehv_pic_init(void)
if (!ehv_pic->irqhost) {
of_node_put(np);
+ kfree(ehv_pic);
return;
}
^ permalink raw reply related
* Re: [PATCH 6/9] arch/powerpc/platforms/pseries/iommu.c: add missing kfree
From: Nishanth Aravamudan @ 2011-08-08 17:47 UTC (permalink / raw)
To: Julia Lawall
Cc: devicetree-discuss, kernel-janitors, linux-kernel, Milton Miller,
Paul Gortmaker, Paul Mackerras, Will Schmidt, linuxppc-dev
In-Reply-To: <1312802283-9107-6-git-send-email-julia@diku.dk>
On 08.08.2011 [13:18:00 +0200], Julia Lawall wrote:
> From: Julia Lawall <julia@diku.dk>
>
> At this point, window has not been stored anywhere, so it has to be freed
> before leaving the function.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @exists@
> local idexpression x;
> statement S,S1;
> expression E;
> identifier fl;
> expression *ptr != NULL;
> @@
>
> x = \(kmalloc\|kzalloc\|kcalloc\)(...);
> ...
> if (x == NULL) S
> <... when != x
> when != if (...) { <+...kfree(x)...+> }
> when any
> when != true x == NULL
> x->fl
> ...>
> (
> if (x == NULL) S1
> |
> if (...) { ... when != x
> when forall
> (
> return \(0\|<+...x...+>\|ptr\);
> |
> * return ...;
> )
> }
> )
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
Acked-by: Nishanth Aravamudan <nacc@us.ibm.com>
Thanks,
Nish
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH v2] powerpc: 85xx: separate e500 from e500mc
From: Scott Wood @ 2011-08-08 19:42 UTC (permalink / raw)
To: Baruch Siach; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <029dda0b5fef124811bd4c577bdade25d7f93fba.1312794031.git.baruch@tkos.co.il>
On 08/08/2011 04:07 AM, Baruch Siach wrote:
> CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6, thus
> breaking clear_pages(), probably others too.
>
> This patch adds a new "Processor Type" entry for e500mc, and makes e500 systems
> depend on PPC_E500.
I can see confusion coming from having CONFIG_E500 and CONFIG_PPC_E500...
Maybe CONFIG_PPC_E500V1_2? Or CONFIG_PPC_E500V2, with a note in the
kconfig help that it supports e500v1 as well.
-Scott
^ permalink raw reply
* Re: FW: Ethernet driver WR linux
From: Scott Wood @ 2011-08-08 20:54 UTC (permalink / raw)
To: smitha.vanga; +Cc: linuxppc-dev
In-Reply-To: <07ACDFB8ECA8EF47863A613BC01BBB220344E6CD@HYD-MKD-MBX02.wipro.com>
On 08/08/2011 12:53 AM, smitha.vanga@wipro.com wrote:
>
> Hi Scott,
>
> Below is the .dts file. My board is based on mpc8247. Currently using
> FCC1.
This device tree is based on something very short-lived when 82xx
support was first being worked on for 82xx, around 2.6.24 or so. Please
redo it from scratch based on what is in the current kernel.
-Scott
^ permalink raw reply
* [PATCH] powerpc: Fix xmon for systems without MSR[RI]
From: Jimi Xenidis @ 2011-08-08 21:25 UTC (permalink / raw)
To: linuxppc-dev
From: David Gibson <dwg@au1.ibm.com>
Based on patch by David Gibson <dwg@au1.ibm.com>
xmon has a longstanding bug on systems which are SMP-capable but lack
the MSR[RI] bit. In these cases, xmon invoked by IPI on secondary
CPUs will not properly keep quiet, but will print stuff, thereby
garbling the primary xmon's output. This patch fixes it, by ignoring
the RI bit if the processor does not support it.
There's already a version of this for 4xx upstream, which we'll need
to extend to other RI-lacking CPUs at some point. For now this adds
BookE processors to the mix.
Signed-off-by: Jimi Xenidis <jimix@pobox.com>
---
arch/powerpc/xmon/xmon.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 42541bb..fdb2f7e 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -340,8 +340,8 @@ int cpus_are_in_xmon(void)
static inline int unrecoverable_excp(struct pt_regs *regs)
{
-#ifdef CONFIG_4xx
- /* We have no MSR_RI bit on 4xx, so we simply return false */
+#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
+ /* We have no MSR_RI bit on 4xx or Book3e, so we simply return false */
return 0;
#else
return ((regs->msr & MSR_RI) == 0);
--
1.7.0.4
^ permalink raw reply related
* [PATCH] powerpc: wsp: Fix Wire Speed Processor platform configs
From: Jimi Xenidis @ 2011-08-08 21:33 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Ian Munsie
Some config selections were applied to the platform (reference board)
when they actuall apply to the chip.
Signed-off-by: Jimi Xenidis <jimix@pobox.com>
---
arch/powerpc/platforms/wsp/Kconfig | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/wsp/Kconfig b/arch/powerpc/platforms/wsp/Kconfig
index c3c48eb..d051581 100644
--- a/arch/powerpc/platforms/wsp/Kconfig
+++ b/arch/powerpc/platforms/wsp/Kconfig
@@ -1,5 +1,9 @@
config PPC_WSP
bool
+ select PPC_A2
+ select PPC_SCOM
+ select PPC_XICS
+ select PPC_ICP_NATIVE
default n
menu "WSP platform selection"
@@ -7,13 +11,9 @@ menu "WSP platform selection"
config PPC_PSR2
bool "PSR-2 platform"
- select PPC_A2
select GENERIC_TBSYNC
- select PPC_SCOM
select EPAPR_BOOT
select PPC_WSP
- select PPC_XICS
- select PPC_ICP_NATIVE
default y
endmenu
--
1.7.0.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox