* Re: [PATCH 10/15] powerpc: fixes for instructions not using correct register naming
From: Benjamin Herrenschmidt @ 2012-06-08 22:42 UTC (permalink / raw)
To: Andreas Schwab
Cc: Michael Neuling, Michael Ellerman, linuxppc-dev, Paul Mackerras,
Anton Blanchard, Olof Johannsson
In-Reply-To: <m2sje6t2y5.fsf@igel.home>
On Fri, 2012-06-08 at 14:15 +0200, Andreas Schwab wrote:
> Michael Neuling <mikey@neuling.org> writes:
>
> > /* Invalidate all TLBs */
> > - PPC_TLBILX_ALL(0,0)
> > + PPC_TLBILX_ALL(R0,R0)
>
> The first argument is (RA|0), so 0 is zero, not r0.
The macro system we use cannot do that (it will prefix with REG_), since
both arguments are registers we must use R0 in this case.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] PPC: PCI: Fix pcibios_io_space_offset() so it works for 32-bit ptr/64-bit rsrcs
From: Benjamin Herrenschmidt @ 2012-06-08 22:48 UTC (permalink / raw)
To: Ben Collins; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <BA42176E-B45B-4628-A143-EA7465233651@ubuntu.com>
On Fri, 2012-06-08 at 14:38 -0400, Ben Collins wrote:
> >> pci_bus 0000:00: root bus resource [io 0xffbeb000-0xffbfafff] (bus
> >> address [0x100000000-0x10000ffff])
> >>
> >> I only have one PCIe RAID card on the bare metal system. Not
> >> surprising I never noticed the problem on it directly.
> >
> > Can you show me the device-tree node for that PCI host bridge ?
>
>
> It's a p4080ds, so it's in arch/powerpc/boot/
>
> And that means that this bug affects a real hardware platform, so I
> think it makes it more valid to include it. The only reason it didn't
> affect me directly is because my only PCIe card doesn't have io, just
> mem BARs.
Something doesn't make sense. The bus address printed above are clearly
not right, the .dts contains for the "ranges" entries for IO space of
all 3 bridges:
0x01000000 0 0x00000000 0xf 0xf8000000 0x0 0x00010000
0x01000000 0 0x00000000 0xf 0xf8010000 0x0 0x00010000
0x01000000 0 0x00000000 0xf 0xf8020000 0x0 0x00010000
So something is wrong with the printing of the bus address, there's a
stale top bit (overflow from the 64-bit substraction somewhere ?)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 10/15] powerpc: fixes for instructions not using correct register naming
From: Andreas Schwab @ 2012-06-09 6:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Michael Neuling, Michael Ellerman, linuxppc-dev, Paul Mackerras,
Anton Blanchard, Olof Johannsson
In-Reply-To: <1339195362.24838.50.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> The macro system we use cannot do that (it will prefix with REG_), since
> both arguments are registers we must use R0 in this case.
So define a ___PPC_RA0 macro that doesn't do that.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 10/15] powerpc: fixes for instructions not using correct register naming
From: Benjamin Herrenschmidt @ 2012-06-09 7:17 UTC (permalink / raw)
To: Andreas Schwab
Cc: Michael Neuling, Michael Ellerman, linuxppc-dev, Paul Mackerras,
Anton Blanchard, Olof Johannsson
In-Reply-To: <m2boktnfh9.fsf@linux-m68k.org>
On Sat, 2012-06-09 at 08:53 +0200, Andreas Schwab wrote:
>
> > The macro system we use cannot do that (it will prefix with REG_),
> since
> > both arguments are registers we must use R0 in this case.
>
> So define a ___PPC_RA0 macro that doesn't do that.
But then we lose the checking for other instructions :-) Unless we start
being nasty and defining a different macro form for RA which can be 0...
I'd rather not go there unless we absolutely have to...
What would be nice also would be if we had a gas option to enforce the
use of % for register names. We'd probably have to struggle a little bit
with gcc inline asm in a case or two though.
Cheers,
Ben.
^ permalink raw reply
* Re: P2010 External HW IRQ number?
From: Joakim Tjernlund @ 2012-06-09 9:00 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <4FD25146.5090108@freescale.com>
Scott Wood <scottwood@freescale.com> wrote on 2012/06/08 21:23:50:
> From: Scott Wood <scottwood@freescale.com>
> To: Joakim Tjernlund <joakim.tjernlund@transmode.se>,
> Cc: <linuxppc-dev@ozlabs.org>
> Date: 2012/06/08 21:25
> Subject: Re: P2010 External HW IRQ number?
>
> On 06/08/2012 06:06 AM, Joakim Tjernlund wrote:
> >
> > I have been trying to figure out what irq number to use for external IRQs for
> > the P2010. There are no HW IRQ numbers in the ref manual and I cannot find
> > any examples in the kernel either.
> > How do specify irq numbers in my dts for external IRQs?
>
> See Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
Ahh, now I see. however I must say that I didn't until I read this older version first:
http://os1a.cs.columbia.edu/lxr/source/Documentation/powerpc/dts-bindings/fsl/mpic.txt?a=x86;v=2.6.34
Jocke
^ permalink raw reply
* Re: [PATCH 10/15] powerpc: fixes for instructions not using correct register naming
From: Andreas Schwab @ 2012-06-09 9:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Michael Neuling, Michael Ellerman, linuxppc-dev, Paul Mackerras,
Anton Blanchard, Olof Johannsson
In-Reply-To: <1339226228.24838.74.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Sat, 2012-06-09 at 08:53 +0200, Andreas Schwab wrote:
>>
>> > The macro system we use cannot do that (it will prefix with REG_),
>> since
>> > both arguments are registers we must use R0 in this case.
>>
>> So define a ___PPC_RA0 macro that doesn't do that.
>
> But then we lose the checking for other instructions :-)
??? There is no loss of checking for instructions that do not use
___PPC_RA0.
> Unless we start being nasty and defining a different macro form for RA
> which can be 0...
That's what ___PPC_RA0 is all about.
> I'd rather not go there unless we absolutely have to...
Having to use R0 for an insn that does *not* use r0 is clearly a step
backwards.
> What would be nice also would be if we had a gas option to enforce the
> use of % for register names.
If gas is ever changed that way you have to be explict about 0 vs. %r0
anyway.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 01/15] i2c/powermac: Register i2c devices from device-tree
From: Andreas Schwab @ 2012-06-09 13:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1334823416-9138-2-git-send-email-benh__33169.052625499$1334826821$gmane$org@kernel.crashing.org>
That breaks the tas3004 driver (and most likely the pcm3052 driver as
well), since it wants to create its own i2c device. I'm using the
attached patch as a workaround (only tas3004 driver tested on iBook G4),
but that needs to move the workarounds for the older systems that don't
have proper compatible properties somewhere else, which I don't know
where.
Andreas.
---
sound/aoa/codecs/onyx.c | 75 ++------------------------------------------
sound/aoa/codecs/tas.c | 80 ++---------------------------------------------
2 files changed, 6 insertions(+), 149 deletions(-)
diff --git a/sound/aoa/codecs/onyx.c b/sound/aoa/codecs/onyx.c
index 270790d..4cedc69 100644
--- a/sound/aoa/codecs/onyx.c
+++ b/sound/aoa/codecs/onyx.c
@@ -997,45 +997,10 @@ static void onyx_exit_codec(struct aoa_codec *codec)
onyx->codec.soundbus_dev->detach_codec(onyx->codec.soundbus_dev, onyx);
}
-static int onyx_create(struct i2c_adapter *adapter,
- struct device_node *node,
- int addr)
-{
- struct i2c_board_info info;
- struct i2c_client *client;
-
- memset(&info, 0, sizeof(struct i2c_board_info));
- strlcpy(info.type, "aoa_codec_onyx", I2C_NAME_SIZE);
- info.addr = addr;
- info.platform_data = node;
- client = i2c_new_device(adapter, &info);
- if (!client)
- return -ENODEV;
-
- /*
- * We know the driver is already loaded, so the device should be
- * already bound. If not it means binding failed, which suggests
- * the device doesn't really exist and should be deleted.
- * Ideally this would be replaced by better checks _before_
- * instantiating the device.
- */
- if (!client->driver) {
- i2c_unregister_device(client);
- return -ENODEV;
- }
-
- /*
- * Let i2c-core delete that device on driver removal.
- * This is safe because i2c-core holds the core_lock mutex for us.
- */
- list_add_tail(&client->detected, &client->driver->clients);
- return 0;
-}
-
static int onyx_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- struct device_node *node = client->dev.platform_data;
+ struct device_node *node = client->dev.of_node;
struct onyx *onyx;
u8 dummy;
@@ -1071,40 +1036,6 @@ static int onyx_i2c_probe(struct i2c_client *client,
return -ENODEV;
}
-static int onyx_i2c_attach(struct i2c_adapter *adapter)
-{
- struct device_node *busnode, *dev = NULL;
- struct pmac_i2c_bus *bus;
-
- bus = pmac_i2c_adapter_to_bus(adapter);
- if (bus == NULL)
- return -ENODEV;
- busnode = pmac_i2c_get_bus_node(bus);
-
- while ((dev = of_get_next_child(busnode, dev)) != NULL) {
- if (of_device_is_compatible(dev, "pcm3052")) {
- const u32 *addr;
- printk(KERN_DEBUG PFX "found pcm3052\n");
- addr = of_get_property(dev, "reg", NULL);
- if (!addr)
- return -ENODEV;
- return onyx_create(adapter, dev, (*addr)>>1);
- }
- }
-
- /* if that didn't work, try desperate mode for older
- * machines that have stuff missing from the device tree */
-
- if (!of_device_is_compatible(busnode, "k2-i2c"))
- return -ENODEV;
-
- printk(KERN_DEBUG PFX "found k2-i2c, checking if onyx chip is on it\n");
- /* probe both possible addresses for the onyx chip */
- if (onyx_create(adapter, NULL, 0x46) == 0)
- return 0;
- return onyx_create(adapter, NULL, 0x47);
-}
-
static int onyx_i2c_remove(struct i2c_client *client)
{
struct onyx *onyx = i2c_get_clientdata(client);
@@ -1117,16 +1048,16 @@ static int onyx_i2c_remove(struct i2c_client *client)
}
static const struct i2c_device_id onyx_i2c_id[] = {
- { "aoa_codec_onyx", 0 },
+ { "MAC,pcm3052", 0 },
{ }
};
+MODULE_DEVICE_TABLE(i2c,onyx_i2c_id);
static struct i2c_driver onyx_driver = {
.driver = {
.name = "aoa_codec_onyx",
.owner = THIS_MODULE,
},
- .attach_adapter = onyx_i2c_attach,
.probe = onyx_i2c_probe,
.remove = onyx_i2c_remove,
.id_table = onyx_i2c_id,
diff --git a/sound/aoa/codecs/tas.c b/sound/aoa/codecs/tas.c
index 8e63d1f..c491ae0 100644
--- a/sound/aoa/codecs/tas.c
+++ b/sound/aoa/codecs/tas.c
@@ -883,43 +883,10 @@ static void tas_exit_codec(struct aoa_codec *codec)
}
-static int tas_create(struct i2c_adapter *adapter,
- struct device_node *node,
- int addr)
-{
- struct i2c_board_info info;
- struct i2c_client *client;
-
- memset(&info, 0, sizeof(struct i2c_board_info));
- strlcpy(info.type, "aoa_codec_tas", I2C_NAME_SIZE);
- info.addr = addr;
- info.platform_data = node;
-
- client = i2c_new_device(adapter, &info);
- if (!client)
- return -ENODEV;
- /*
- * We know the driver is already loaded, so the device should be
- * already bound. If not it means binding failed, and then there
- * is no point in keeping the device instantiated.
- */
- if (!client->driver) {
- i2c_unregister_device(client);
- return -ENODEV;
- }
-
- /*
- * Let i2c-core delete that device on driver removal.
- * This is safe because i2c-core holds the core_lock mutex for us.
- */
- list_add_tail(&client->detected, &client->driver->clients);
- return 0;
-}
-
static int tas_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- struct device_node *node = client->dev.platform_data;
+ struct device_node *node = client->dev.of_node;
struct tas *tas;
tas = kzalloc(sizeof(struct tas), GFP_KERNEL);
@@ -953,47 +920,6 @@ static int tas_i2c_probe(struct i2c_client *client,
return -EINVAL;
}
-static int tas_i2c_attach(struct i2c_adapter *adapter)
-{
- struct device_node *busnode, *dev = NULL;
- struct pmac_i2c_bus *bus;
-
- bus = pmac_i2c_adapter_to_bus(adapter);
- if (bus == NULL)
- return -ENODEV;
- busnode = pmac_i2c_get_bus_node(bus);
-
- while ((dev = of_get_next_child(busnode, dev)) != NULL) {
- if (of_device_is_compatible(dev, "tas3004")) {
- const u32 *addr;
- printk(KERN_DEBUG PFX "found tas3004\n");
- addr = of_get_property(dev, "reg", NULL);
- if (!addr)
- continue;
- return tas_create(adapter, dev, ((*addr) >> 1) & 0x7f);
- }
- /* older machines have no 'codec' node with a 'compatible'
- * property that says 'tas3004', they just have a 'deq'
- * node without any such property... */
- if (strcmp(dev->name, "deq") == 0) {
- const u32 *_addr;
- u32 addr;
- printk(KERN_DEBUG PFX "found 'deq' node\n");
- _addr = of_get_property(dev, "i2c-address", NULL);
- if (!_addr)
- continue;
- addr = ((*_addr) >> 1) & 0x7f;
- /* now, if the address doesn't match any of the two
- * that a tas3004 can have, we cannot handle this.
- * I doubt it ever happens but hey. */
- if (addr != 0x34 && addr != 0x35)
- continue;
- return tas_create(adapter, dev, addr);
- }
- }
- return -ENODEV;
-}
-
static int tas_i2c_remove(struct i2c_client *client)
{
struct tas *tas = i2c_get_clientdata(client);
@@ -1011,16 +937,16 @@ static int tas_i2c_remove(struct i2c_client *client)
}
static const struct i2c_device_id tas_i2c_id[] = {
- { "aoa_codec_tas", 0 },
+ { "MAC,tas3004", 0 },
{ }
};
+MODULE_DEVICE_TABLE(i2c,tas_i2c_id);
static struct i2c_driver tas_driver = {
.driver = {
.name = "aoa_codec_tas",
.owner = THIS_MODULE,
},
- .attach_adapter = tas_i2c_attach,
.probe = tas_i2c_probe,
.remove = tas_i2c_remove,
.id_table = tas_i2c_id,
--
1.7.10.4
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
* Re: [PATCH 01/15] i2c/powermac: Register i2c devices from device-tree
From: Benjamin Herrenschmidt @ 2012-06-09 22:11 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <m2r4tofuxr.fsf@igel.home>
On Sat, 2012-06-09 at 15:58 +0200, Andreas Schwab wrote:
> That breaks the tas3004 driver (and most likely the pcm3052 driver as
> well), since it wants to create its own i2c device. I'm using the
> attached patch as a workaround (only tas3004 driver tested on iBook G4),
> but that needs to move the workarounds for the older systems that don't
> have proper compatible properties somewhere else, which I don't know
> where.
Should we keep the tas_create method for those ? We could have some code
in the aoa core file that calls those "fixups" to create missing
devices...
Cheers,
Ben.
> Andreas.
>
> ---
> sound/aoa/codecs/onyx.c | 75 ++------------------------------------------
> sound/aoa/codecs/tas.c | 80 ++---------------------------------------------
> 2 files changed, 6 insertions(+), 149 deletions(-)
>
> diff --git a/sound/aoa/codecs/onyx.c b/sound/aoa/codecs/onyx.c
> index 270790d..4cedc69 100644
> --- a/sound/aoa/codecs/onyx.c
> +++ b/sound/aoa/codecs/onyx.c
> @@ -997,45 +997,10 @@ static void onyx_exit_codec(struct aoa_codec *codec)
> onyx->codec.soundbus_dev->detach_codec(onyx->codec.soundbus_dev, onyx);
> }
>
> -static int onyx_create(struct i2c_adapter *adapter,
> - struct device_node *node,
> - int addr)
> -{
> - struct i2c_board_info info;
> - struct i2c_client *client;
> -
> - memset(&info, 0, sizeof(struct i2c_board_info));
> - strlcpy(info.type, "aoa_codec_onyx", I2C_NAME_SIZE);
> - info.addr = addr;
> - info.platform_data = node;
> - client = i2c_new_device(adapter, &info);
> - if (!client)
> - return -ENODEV;
> -
> - /*
> - * We know the driver is already loaded, so the device should be
> - * already bound. If not it means binding failed, which suggests
> - * the device doesn't really exist and should be deleted.
> - * Ideally this would be replaced by better checks _before_
> - * instantiating the device.
> - */
> - if (!client->driver) {
> - i2c_unregister_device(client);
> - return -ENODEV;
> - }
> -
> - /*
> - * Let i2c-core delete that device on driver removal.
> - * This is safe because i2c-core holds the core_lock mutex for us.
> - */
> - list_add_tail(&client->detected, &client->driver->clients);
> - return 0;
> -}
> -
> static int onyx_i2c_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> - struct device_node *node = client->dev.platform_data;
> + struct device_node *node = client->dev.of_node;
> struct onyx *onyx;
> u8 dummy;
>
> @@ -1071,40 +1036,6 @@ static int onyx_i2c_probe(struct i2c_client *client,
> return -ENODEV;
> }
>
> -static int onyx_i2c_attach(struct i2c_adapter *adapter)
> -{
> - struct device_node *busnode, *dev = NULL;
> - struct pmac_i2c_bus *bus;
> -
> - bus = pmac_i2c_adapter_to_bus(adapter);
> - if (bus == NULL)
> - return -ENODEV;
> - busnode = pmac_i2c_get_bus_node(bus);
> -
> - while ((dev = of_get_next_child(busnode, dev)) != NULL) {
> - if (of_device_is_compatible(dev, "pcm3052")) {
> - const u32 *addr;
> - printk(KERN_DEBUG PFX "found pcm3052\n");
> - addr = of_get_property(dev, "reg", NULL);
> - if (!addr)
> - return -ENODEV;
> - return onyx_create(adapter, dev, (*addr)>>1);
> - }
> - }
> -
> - /* if that didn't work, try desperate mode for older
> - * machines that have stuff missing from the device tree */
> -
> - if (!of_device_is_compatible(busnode, "k2-i2c"))
> - return -ENODEV;
> -
> - printk(KERN_DEBUG PFX "found k2-i2c, checking if onyx chip is on it\n");
> - /* probe both possible addresses for the onyx chip */
> - if (onyx_create(adapter, NULL, 0x46) == 0)
> - return 0;
> - return onyx_create(adapter, NULL, 0x47);
> -}
> -
> static int onyx_i2c_remove(struct i2c_client *client)
> {
> struct onyx *onyx = i2c_get_clientdata(client);
> @@ -1117,16 +1048,16 @@ static int onyx_i2c_remove(struct i2c_client *client)
> }
>
> static const struct i2c_device_id onyx_i2c_id[] = {
> - { "aoa_codec_onyx", 0 },
> + { "MAC,pcm3052", 0 },
> { }
> };
> +MODULE_DEVICE_TABLE(i2c,onyx_i2c_id);
>
> static struct i2c_driver onyx_driver = {
> .driver = {
> .name = "aoa_codec_onyx",
> .owner = THIS_MODULE,
> },
> - .attach_adapter = onyx_i2c_attach,
> .probe = onyx_i2c_probe,
> .remove = onyx_i2c_remove,
> .id_table = onyx_i2c_id,
> diff --git a/sound/aoa/codecs/tas.c b/sound/aoa/codecs/tas.c
> index 8e63d1f..c491ae0 100644
> --- a/sound/aoa/codecs/tas.c
> +++ b/sound/aoa/codecs/tas.c
> @@ -883,43 +883,10 @@ static void tas_exit_codec(struct aoa_codec *codec)
> }
>
>
> -static int tas_create(struct i2c_adapter *adapter,
> - struct device_node *node,
> - int addr)
> -{
> - struct i2c_board_info info;
> - struct i2c_client *client;
> -
> - memset(&info, 0, sizeof(struct i2c_board_info));
> - strlcpy(info.type, "aoa_codec_tas", I2C_NAME_SIZE);
> - info.addr = addr;
> - info.platform_data = node;
> -
> - client = i2c_new_device(adapter, &info);
> - if (!client)
> - return -ENODEV;
> - /*
> - * We know the driver is already loaded, so the device should be
> - * already bound. If not it means binding failed, and then there
> - * is no point in keeping the device instantiated.
> - */
> - if (!client->driver) {
> - i2c_unregister_device(client);
> - return -ENODEV;
> - }
> -
> - /*
> - * Let i2c-core delete that device on driver removal.
> - * This is safe because i2c-core holds the core_lock mutex for us.
> - */
> - list_add_tail(&client->detected, &client->driver->clients);
> - return 0;
> -}
> -
> static int tas_i2c_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> - struct device_node *node = client->dev.platform_data;
> + struct device_node *node = client->dev.of_node;
> struct tas *tas;
>
> tas = kzalloc(sizeof(struct tas), GFP_KERNEL);
> @@ -953,47 +920,6 @@ static int tas_i2c_probe(struct i2c_client *client,
> return -EINVAL;
> }
>
> -static int tas_i2c_attach(struct i2c_adapter *adapter)
> -{
> - struct device_node *busnode, *dev = NULL;
> - struct pmac_i2c_bus *bus;
> -
> - bus = pmac_i2c_adapter_to_bus(adapter);
> - if (bus == NULL)
> - return -ENODEV;
> - busnode = pmac_i2c_get_bus_node(bus);
> -
> - while ((dev = of_get_next_child(busnode, dev)) != NULL) {
> - if (of_device_is_compatible(dev, "tas3004")) {
> - const u32 *addr;
> - printk(KERN_DEBUG PFX "found tas3004\n");
> - addr = of_get_property(dev, "reg", NULL);
> - if (!addr)
> - continue;
> - return tas_create(adapter, dev, ((*addr) >> 1) & 0x7f);
> - }
> - /* older machines have no 'codec' node with a 'compatible'
> - * property that says 'tas3004', they just have a 'deq'
> - * node without any such property... */
> - if (strcmp(dev->name, "deq") == 0) {
> - const u32 *_addr;
> - u32 addr;
> - printk(KERN_DEBUG PFX "found 'deq' node\n");
> - _addr = of_get_property(dev, "i2c-address", NULL);
> - if (!_addr)
> - continue;
> - addr = ((*_addr) >> 1) & 0x7f;
> - /* now, if the address doesn't match any of the two
> - * that a tas3004 can have, we cannot handle this.
> - * I doubt it ever happens but hey. */
> - if (addr != 0x34 && addr != 0x35)
> - continue;
> - return tas_create(adapter, dev, addr);
> - }
> - }
> - return -ENODEV;
> -}
> -
> static int tas_i2c_remove(struct i2c_client *client)
> {
> struct tas *tas = i2c_get_clientdata(client);
> @@ -1011,16 +937,16 @@ static int tas_i2c_remove(struct i2c_client *client)
> }
>
> static const struct i2c_device_id tas_i2c_id[] = {
> - { "aoa_codec_tas", 0 },
> + { "MAC,tas3004", 0 },
> { }
> };
> +MODULE_DEVICE_TABLE(i2c,tas_i2c_id);
>
> static struct i2c_driver tas_driver = {
> .driver = {
> .name = "aoa_codec_tas",
> .owner = THIS_MODULE,
> },
> - .attach_adapter = tas_i2c_attach,
> .probe = tas_i2c_probe,
> .remove = tas_i2c_remove,
> .id_table = tas_i2c_id,
> --
> 1.7.10.4
>
>
^ permalink raw reply
* Re: [PATCH 01/15] i2c/powermac: Register i2c devices from device-tree
From: Andreas Schwab @ 2012-06-09 22:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1339279889.24838.93.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> Should we keep the tas_create method for those ? We could have some code
> in the aoa core file that calls those "fixups" to create missing
> devices...
I'm not sure if the function is needed, if the device can be created in
i2c_powermac_register_devices.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 01/15] i2c/powermac: Register i2c devices from device-tree
From: Benjamin Herrenschmidt @ 2012-06-09 22:36 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <m2k3zgf79j.fsf@igel.home>
On Sun, 2012-06-10 at 00:30 +0200, Andreas Schwab wrote:
> > Should we keep the tas_create method for those ? We could have some code
> > in the aoa core file that calls those "fixups" to create missing
> > devices...
>
> I'm not sure if the function is needed, if the device can be created in
> i2c_powermac_register_devices.
But it doesn't have a device-node ... does it ? Which machine is this
btw ? Can you shoot me privately the device-tree ? That will help me
figure out what exactly needs to be done.
Thanks !
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 01/15] i2c/powermac: Register i2c devices from device-tree
From: Andreas Schwab @ 2012-06-09 22:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1339281364.24838.94.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Sun, 2012-06-10 at 00:30 +0200, Andreas Schwab wrote:
>> > Should we keep the tas_create method for those ? We could have some code
>> > in the aoa core file that calls those "fixups" to create missing
>> > devices...
>>
>> I'm not sure if the function is needed, if the device can be created in
>> i2c_powermac_register_devices.
>
> But it doesn't have a device-node ... does it ? Which machine is this
> btw ?
It's a PowerMac G5. During booting I see this:
PowerMac i2c bus pmu 2 registered
PowerMac i2c bus pmu 1 registered
PowerMac i2c bus mac-io 0 registered
i2c i2c-5: i2c-powermac: modalias failure on /ht@0,f2000000/pci@1/mac-io@7/i2c@18000/deq@6a
i2c i2c-5: i2c-powermac: invalid reg on /ht@0,f2000000/pci@1/mac-io@7/i2c@18000/i2c-modem
PowerMac i2c bus u3 1 registered
i2c i2c-6: i2c-powermac: modalias failure on /u3@0,f8000000/i2c@f8001000/cereal@1c0
PowerMac i2c bus u3 0 registered
The deq node has no compatible, perhaps the modalias can be constructed
out of the name instead?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 01/15] i2c/powermac: Register i2c devices from device-tree
From: Benjamin Herrenschmidt @ 2012-06-09 23:10 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <m2fwa4f5x5.fsf@igel.home>
On Sun, 2012-06-10 at 00:59 +0200, Andreas Schwab wrote:
> It's a PowerMac G5. During booting I see this:
There's about half a dozen versions of those :-) I assume the older
PowerMac7,2 ? It's the one that tends to have missing bits in the
device-tree. In that case, I think we still have one of these working at
work, I can have a look when I'm back.
> PowerMac i2c bus pmu 2 registered
> PowerMac i2c bus pmu 1 registered
> PowerMac i2c bus mac-io 0 registered
> i2c i2c-5: i2c-powermac: modalias failure
> on /ht@0,f2000000/pci@1/mac-io@7/i2c@18000/deq@6a
> i2c i2c-5: i2c-powermac: invalid reg
> on /ht@0,f2000000/pci@1/mac-io@7/i2c@18000/i2c-modem
> PowerMac i2c bus u3 1 registered
> i2c i2c-6: i2c-powermac: modalias failure
> on /u3@0,f8000000/i2c@f8001000/cereal@1c0
> PowerMac i2c bus u3 0 registered
>
> The deq node has no compatible, perhaps the modalias can be
> constructed out of the name instead?
But where is the deq node ? Under i2c or under sound ? If not under i2c
then we need to do something else entirely.
For modalias I'm thinking best might be to have the platform code create
a platform device for sound and have aoa core match on that ;-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 01/15] i2c/powermac: Register i2c devices from device-tree
From: Andreas Schwab @ 2012-06-10 7:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1339283422.24838.96.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Sun, 2012-06-10 at 00:59 +0200, Andreas Schwab wrote:
>> It's a PowerMac G5. During booting I see this:
>
> There's about half a dozen versions of those :-) I assume the older
> PowerMac7,2 ?
Yes, that's right. Sorry for being imprecise.
>> PowerMac i2c bus pmu 2 registered
>> PowerMac i2c bus pmu 1 registered
>> PowerMac i2c bus mac-io 0 registered
>> i2c i2c-5: i2c-powermac: modalias failure
>> on /ht@0,f2000000/pci@1/mac-io@7/i2c@18000/deq@6a
>> i2c i2c-5: i2c-powermac: invalid reg
>> on /ht@0,f2000000/pci@1/mac-io@7/i2c@18000/i2c-modem
>> PowerMac i2c bus u3 1 registered
>> i2c i2c-6: i2c-powermac: modalias failure
>> on /u3@0,f8000000/i2c@f8001000/cereal@1c0
>> PowerMac i2c bus u3 0 registered
>>
>> The deq node has no compatible, perhaps the modalias can be
>> constructed out of the name instead?
>
> But where is the deq node ? Under i2c or under sound ?
It looks like /ht@0,f2000000/pci@1/mac-io@7/i2c@18000/deq@6a is under
i2c.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 01/15] i2c/powermac: Register i2c devices from device-tree
From: Benjamin Herrenschmidt @ 2012-06-10 7:23 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <m2zk8br65n.fsf@linux-m68k.org>
On Sun, 2012-06-10 at 09:13 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
> > On Sun, 2012-06-10 at 00:59 +0200, Andreas Schwab wrote:
> >> It's a PowerMac G5. During booting I see this:
> >
> > There's about half a dozen versions of those :-) I assume the older
> > PowerMac7,2 ?
>
> Yes, that's right. Sorry for being imprecise.
>
> >> PowerMac i2c bus pmu 2 registered
> >> PowerMac i2c bus pmu 1 registered
> >> PowerMac i2c bus mac-io 0 registered
> >> i2c i2c-5: i2c-powermac: modalias failure
> >> on /ht@0,f2000000/pci@1/mac-io@7/i2c@18000/deq@6a
> >> i2c i2c-5: i2c-powermac: invalid reg
> >> on /ht@0,f2000000/pci@1/mac-io@7/i2c@18000/i2c-modem
> >> PowerMac i2c bus u3 1 registered
> >> i2c i2c-6: i2c-powermac: modalias failure
> >> on /u3@0,f8000000/i2c@f8001000/cereal@1c0
> >> PowerMac i2c bus u3 0 registered
> >>
> >> The deq node has no compatible, perhaps the modalias can be
> >> constructed out of the name instead?
> >
> > But where is the deq node ? Under i2c or under sound ?
>
> It looks like /ht@0,f2000000/pci@1/mac-io@7/i2c@18000/deq@6a is under
> i2c.
Ah, excellent, so a small quirk in i2c_powermac is the way to go then,
we can detect it by name and hack up something. Either that or even
better, in prom_init, we could add the missing property to the
device-tree.
Any chance you can try that ? (Look at other examples of DT fixups in
prom_init.c and don't forget the RELOC() around strings :-)
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc: Kill flatdevtree_env.h too
From: Paul Bolle @ 2012-06-10 9:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
Commit 430b01e8f5e524a2bfa50074d97d0bdc2505807b ("[POWERPC] Kill
flatdevtree.c") killed the two files including flatdevtree_env.h. It was
apparently just an oversight to not kill that header too. Kill it now.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
Tested with "git grep" only.
arch/powerpc/boot/flatdevtree_env.h | 27 ---------------------------
1 files changed, 0 insertions(+), 27 deletions(-)
delete mode 100644 arch/powerpc/boot/flatdevtree_env.h
diff --git a/arch/powerpc/boot/flatdevtree_env.h b/arch/powerpc/boot/flatdevtree_env.h
deleted file mode 100644
index 66e0ebb..0000000
--- a/arch/powerpc/boot/flatdevtree_env.h
+++ /dev/null
@@ -1,27 +0,0 @@
-/*
- * This file adds the header file glue so that the shared files
- * flatdevicetree.[ch] can compile and work in the powerpc bootwrapper.
- *
- * strncmp & strchr copied from <file:lib/string.c>
- * Copyright (C) 1991, 1992 Linus Torvalds
- *
- * Maintained by: Mark A. Greer <mgreer@mvista.com>
- */
-#ifndef _PPC_BOOT_FLATDEVTREE_ENV_H_
-#define _PPC_BOOT_FLATDEVTREE_ENV_H_
-
-#include <stdarg.h>
-#include <stddef.h>
-#include "types.h"
-#include "string.h"
-#include "stdio.h"
-#include "ops.h"
-
-#define be16_to_cpu(x) (x)
-#define cpu_to_be16(x) (x)
-#define be32_to_cpu(x) (x)
-#define cpu_to_be32(x) (x)
-#define be64_to_cpu(x) (x)
-#define cpu_to_be64(x) (x)
-
-#endif /* _PPC_BOOT_FLATDEVTREE_ENV_H_ */
--
1.7.7.6
^ permalink raw reply related
* Re: [PATCH 01/15] i2c/powermac: Register i2c devices from device-tree
From: Andreas Schwab @ 2012-06-10 11:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1339312981.24838.98.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> Ah, excellent, so a small quirk in i2c_powermac is the way to go then,
> we can detect it by name and hack up something. Either that or even
> better, in prom_init, we could add the missing property to the
> device-tree.
How does that look like? Though I'm not sure this is the right
approach. Those models with the onyx chip that lack the pcm3052
compatible property apparently have no OF node at all to key off the
workaround.
Andreas.
diff --git i/arch/powerpc/kernel/prom_init.c w/arch/powerpc/kernel/prom_init.c
index 1b488e5..1b04159 100644
--- i/arch/powerpc/kernel/prom_init.c
+++ w/arch/powerpc/kernel/prom_init.c
@@ -2554,7 +2554,7 @@ static void __init fixup_device_tree_chrp(void)
#endif
#if defined(CONFIG_PPC64) && defined(CONFIG_PPC_PMAC)
-static void __init fixup_device_tree_pmac(void)
+static void __init fixup_device_tree_pmac_u3_i2c(void)
{
phandle u3, i2c, mpic;
u32 u3_rev;
@@ -2593,6 +2593,39 @@ static void __init fixup_device_tree_pmac(void)
prom_setprop(i2c, "/u3@0,f8000000/i2c@f8001000", "interrupt-parent",
&parent, sizeof(parent));
}
+
+static void __init fixup_device_tree_pmac_deq(void)
+{
+ phandle deq;
+ u32 i2c_address;
+
+ /*
+ * On older G5s the tas3004 is described by a deq node missing a
+ * compatible definition, instead of a codec node with a
+ * tas3004,code compatible property. Fix that up here.
+ */
+ deq = call_prom("finddevice", 1, 1, ADDR("/ht@0,f2000000/pci@1/mac-io@7/i2c@18000/deq@6a"));
+ if (!PHANDLE_VALID(deq))
+ return;
+ /* Check for proper i2c-address. */
+ if (prom_getprop(deq, "i2c-address", &i2c_address, sizeof(i2c_address)) == PROM_ERROR)
+ return;
+ i2c_address = (i2c_address >> 1) & 0x7f;
+ if (i2c_address != 0x34 && i2c_address != 0x35)
+ return;
+
+ prom_printf("fixing up missing compatible for deq node...\n");
+
+ prom_setprop (deq, "/ht@0,f2000000/pci@1/mac-io@7/i2c@18000/deq@6a",
+ "compatible", &RELOC("tas3004\0codec\0"),
+ sizeof("tas3004\0codec\0"));
+}
+
+static void __init fixup_device_tree_pmac(void)
+{
+ fixup_device_tree_pmac_u3_i2c();
+ fixup_device_tree_pmac_deq();
+}
#else
#define fixup_device_tree_pmac()
#endif
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
* PowerMac PMU programming
From: Justin Hibbits @ 2012-06-10 13:29 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I'm working on various PMU bits for FreeBSD (I know, not related to
Linux), but running into some problems, which the Linux crowd may be
able to help with, as it's already solved for Linux. I've managed to
get it to sleep for performing the sleep operation and for the CPU speed
switch on MPC7455-based machines, but it goes catatonic, not waking
up. I've installed the reset vector pointer at 0x0080, which both OS X
and Linux do, and flush the caches, but no luck. During development of
the Linux driver was this ever encountered? Any assistance would be
greatly appreciated, I've been banging my head against this off and on
for about 8 months now.
Thanks for any assistance. I'm not subscribed to the list, so please
keep my address in replies.
Justin Hibbits
^ permalink raw reply
* Re: [PATCH v2] usb: fsl_udc: errata - postpone freeing current dTD
From: Fabio Estevam @ 2012-06-10 18:41 UTC (permalink / raw)
To: Christoph Fritz
Cc: Ben Dooks, Chen Peter-B29397, Nicolas Ferre, Hans J. Koch,
Kukjin Kim, Russell King, Thomas Dahlmann, Sascha Hauer,
Christian Hemp, Haojian Zhuang, Daniel Mack, Neil Zhang,
linux-arm-kernel, Oliver Neukum, Eric Miao, Li Yang-R58472,
Greg Kroah-Hartman, linux-usb@vger.kernel.org, Felipe Balbi,
Ido Shayevitz, Estevam Fabio-R49496,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1338809853.3371.31.camel@mars>
Hi Christoph,
On Mon, Jun 4, 2012 at 8:37 AM, Christoph Fritz
<chf.fritz@googlemail.com> wrote:
> After that, I stumbled upon this dmesg:
>
> Freescale High-Speed USB SOC Device Controller driver (Apr 20, 2007)
> fsl-usb2-udc fsl-usb2-udc: clk_get("usb") failed
> fsl-usb2-udc: probe of fsl-usb2-udc failed with error -2
>
> Sascha, could you give me a hint?
Does the patch below fix your problem?
drivers/usb/gadget/fsl_mxc_udc.c | 20 ++++++++++----------
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/gadget/fsl_mxc_udc.c b/drivers/usb/gadget/fsl_mxc_udc.c
index dcbc0a2..c3ade6b 100644
--- a/drivers/usb/gadget/fsl_mxc_udc.c
+++ b/drivers/usb/gadget/fsl_mxc_udc.c
@@ -36,21 +36,21 @@ int fsl_udc_clk_init(struct platform_device *pdev)
pdata = pdev->dev.platform_data;
if (!cpu_is_mx35() && !cpu_is_mx25()) {
- mxc_ahb_clk = clk_get(&pdev->dev, "usb_ahb");
+ mxc_ahb_clk = clk_get(&pdev->dev, "ipg");
if (IS_ERR(mxc_ahb_clk))
return PTR_ERR(mxc_ahb_clk);
- ret = clk_enable(mxc_ahb_clk);
+ ret = clk_prepare_enable(mxc_ahb_clk);
if (ret < 0) {
- dev_err(&pdev->dev, "clk_enable(\"usb_ahb\") failed\n");
+ dev_err(&pdev->dev, "clk_enable(\"ipg\") failed\n");
goto eenahb;
}
}
/* make sure USB_CLK is running at 60 MHz +/- 1000 Hz */
- mxc_usb_clk = clk_get(&pdev->dev, "usb");
+ mxc_usb_clk = clk_get(&pdev->dev, "per");
if (IS_ERR(mxc_usb_clk)) {
- dev_err(&pdev->dev, "clk_get(\"usb\") failed\n");
+ dev_err(&pdev->dev, "clk_get(\"per\") failed\n");
ret = PTR_ERR(mxc_usb_clk);
goto egusb;
}
@@ -65,7 +65,7 @@ int fsl_udc_clk_init(struct platform_device *pdev)
}
}
- ret = clk_enable(mxc_usb_clk);
+ ret = clk_prepare_enable(mxc_usb_clk);
if (ret < 0) {
dev_err(&pdev->dev, "clk_enable(\"usb_clk\") failed\n");
goto eenusb;
@@ -79,7 +79,7 @@ eclkrate:
mxc_usb_clk = NULL;
egusb:
if (!cpu_is_mx35())
- clk_disable(mxc_ahb_clk);
+ clk_disable_unprepare(mxc_ahb_clk);
eenahb:
if (!cpu_is_mx35())
clk_put(mxc_ahb_clk);
@@ -104,7 +104,7 @@ void fsl_udc_clk_finalize(struct platform_device *pdev)
/* ULPI transceivers don't need usbpll */
if (pdata->phy_mode == FSL_USB2_PHY_ULPI) {
- clk_disable(mxc_usb_clk);
+ clk_disable_unprepare(mxc_usb_clk);
clk_put(mxc_usb_clk);
mxc_usb_clk = NULL;
}
@@ -113,11 +113,11 @@ void fsl_udc_clk_finalize(struct platform_device *pdev)
void fsl_udc_clk_release(void)
{
if (mxc_usb_clk) {
- clk_disable(mxc_usb_clk);
+ clk_disable_unprepare(mxc_usb_clk);
clk_put(mxc_usb_clk);
}
if (!cpu_is_mx35()) {
- clk_disable(mxc_ahb_clk);
+ clk_disable_unprepare(mxc_ahb_clk);
clk_put(mxc_ahb_clk);
}
}
--
^ permalink raw reply related
* Question about MPIC_SINGLE_DEST_CPU on P1020 (e500 core) SMP
From: Gopalakrishnan Raman @ 2012-06-10 20:37 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org; +Cc: rgkwstl@gmail.com
[-- Attachment #1: Type: text/plain, Size: 588 bytes --]
Hi
The P1020 manual states (in the PIC chapter) that in the "Internal Interrupt Destination" register, only 1 CPU (and not both) can be selected as the IRQ destination. How then can we achieve "interrupt spraying" for the PCI interrupt (we want interrupts to be sent alternately to CPU0 and CPU1). Also, we changed the code to ignore the MPIC_SINGLE_DEST_CPU flag and set both CPUs in the destination of the PIC_IIDRn register. This does seem to work. But we're not sure if we can rely on this behavior and whether it will cause other problems.
Any advice appreciated
Thanks
-gopal
[-- Attachment #2: Type: text/html, Size: 2381 bytes --]
^ permalink raw reply
* (no subject)
From: Gopalakrishnan Raman @ 2012-06-10 20:52 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 590 bytes --]
Hi
The P1020 manual states (in the PIC chapter) that in the "Internal Interrupt Destination" register, only 1 CPU (and not both) can be selected as the IRQ destination. How then can we achieve "interrupt spraying" for the PCI interrupt (we want interrupts to be sent alternately to CPU0 and CPU1). Also, we changed the code to ignore the MPIC_SINGLE_DEST_CPU flag and set both CPUs in the destination of the PIC_IIDRn register. This does seem to work. But we're not sure if we can rely on this behavior and whether it will cause other problems.
Any advice appreciated
Thanks
-gopal
[-- Attachment #2: Type: text/html, Size: 2425 bytes --]
^ permalink raw reply
* Re: PowerMac PMU programming
From: Benjamin Herrenschmidt @ 2012-06-10 23:03 UTC (permalink / raw)
To: Justin Hibbits; +Cc: linuxppc-dev
In-Reply-To: <20120610092932.38857c77@narn.knownspace>
On Sun, 2012-06-10 at 09:29 -0400, Justin Hibbits wrote:
> Hello,
>
> I'm working on various PMU bits for FreeBSD (I know, not related to
> Linux), but running into some problems, which the Linux crowd may be
> able to help with, as it's already solved for Linux. I've managed to
> get it to sleep for performing the sleep operation and for the CPU speed
> switch on MPC7455-based machines, but it goes catatonic, not waking
> up. I've installed the reset vector pointer at 0x0080, which both OS X
> and Linux do, and flush the caches, but no luck. During development of
> the Linux driver was this ever encountered? Any assistance would be
> greatly appreciated, I've been banging my head against this off and on
> for about 8 months now.
>
> Thanks for any assistance. I'm not subscribed to the list, so please
> keep my address in replies.
Yes it was :-) pretty much any bug even minor during that process will
cause just that :-)
One thing paulus did that helped us a lot initially was write a little
synchronous version of the PMU send command and use it to blink the PMU
LED very early on when resuming from sleep, which allows us to debug a
bit.
It takes quite a bit of work (see the code in radeonfb) to get the
graphics back, so most of the time you come back with nothing on screen.
If your machine is not a laptop, there are other possible
considerations, such as the need to restore the PCI-PCI bridge that
might be above the macio chip very early on, before you try to restore
macio itself (we don't do that in Linux at this stage).
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH 0/6] Description for PCI patches using platform driver
From: Jia Hongtao-B38951 @ 2012-06-11 2:33 UTC (permalink / raw)
To: Bhushan Bharat-R65777, linuxppc-dev@lists.ozlabs.org,
galak@kernel.crashing.org
Cc: Li Yang-R58472, Wood Scott-B07421
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D03D71F38@039-SN2MPN1-022.039d.mgd.msft.net>
> -----Original Message-----
> From: Bhushan Bharat-R65777
> Sent: Friday, June 08, 2012 6:47 PM
> To: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org;
> galak@kernel.crashing.org
> Cc: Li Yang-R58472; benh@kernel.crashing.org; Wood Scott-B07421
> Subject: RE: [PATCH 0/6] Description for PCI patches using platform
> driver
>=20
>=20
> > -----Original Message-----
> > From: Jia Hongtao-B38951
> > Sent: Friday, June 08, 2012 3:12 PM
> > To: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org
> > Cc: Li Yang-R58472; benh@kernel.crashing.org; Wood Scott-B07421;
> Bhushan Bharat-
> > R65777; Jia Hongtao-B38951
> > Subject: [PATCH 0/6] Description for PCI patches using platform driver
> >
> > This series of patches are to unify pci initialization code and add PM
> support
> > for all 85xx/86xx powerpc boards. But two side effects are introduced
> by this
> > mechanism which listed below:
> >
> > 1. of_platform_bus_probe() will be called twice but in some cases
> duplication
> > warning occured. We fix this in [PATCH 5/6].
> >
> > 2. Edac driver failed to register pci nodes as platform devices. We fix
> this
> > in [PATCH 6/6].
>=20
> With these patches will not the SWIOTLB will not be initialized even if
> PCI/PCIe demanded?
>=20
> Thanks
> -Bharat
>=20
These patches still have the swiotlb init problem if "ppc_swiotlb_enable" i=
s
only demanded by PCI/PCIe. One of the purposes of sending out these patches
is to let us start a discussion for this problem in upstream.
-Jia Hongtao.
^ permalink raw reply
* Re: PowerMac PMU programming
From: Justin Hibbits @ 2012-06-11 3:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1339369393.24838.101.camel@pasglop>
On Mon, 11 Jun 2012 09:03:13 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Sun, 2012-06-10 at 09:29 -0400, Justin Hibbits wrote:
> > Hello,
> >
> > I'm working on various PMU bits for FreeBSD (I know, not related to
> > Linux), but running into some problems, which the Linux crowd may be
> > able to help with, as it's already solved for Linux. I've managed
> > to get it to sleep for performing the sleep operation and for the
> > CPU speed switch on MPC7455-based machines, but it goes catatonic,
> > not waking up. I've installed the reset vector pointer at 0x0080,
> > which both OS X and Linux do, and flush the caches, but no luck.
> > During development of the Linux driver was this ever encountered?
> > Any assistance would be greatly appreciated, I've been banging my
> > head against this off and on for about 8 months now.
> >
> > Thanks for any assistance. I'm not subscribed to the list, so
> > please keep my address in replies.
>
> Yes it was :-) pretty much any bug even minor during that process will
> cause just that :-)
>
> One thing paulus did that helped us a lot initially was write a little
> synchronous version of the PMU send command and use it to blink the
> PMU LED very early on when resuming from sleep, which allows us to
> debug a bit.
>
> It takes quite a bit of work (see the code in radeonfb) to get the
> graphics back, so most of the time you come back with nothing on
> screen.
>
> If your machine is not a laptop, there are other possible
> considerations, such as the need to restore the PCI-PCI bridge that
> might be above the macio chip very early on, before you try to restore
> macio itself (we don't do that in Linux at this stage).
>
> Cheers,
> Ben.
>
>
Thanks Ben,
I'll settle on just getting the CPU speed change working, losing 333MHz
on my TiBook is a few too many MHz for the poor thing to lose :) I do
have a desktop, but that's my development platform, so needs to be
at least somewhat stable, so my TiBook is my guinea pig.
I've googled everything I can think of, but do you know of any
definitive PMU documentation? Or can you give me any hints on what's
needed just for that simple operation?
I noticed that you wind down the ADB queue before killing the PMU. Is
this necessary? I only disable the interrupt by writing 0x10 to the
IER, but our interrupt model for the PMU is different from the Linux
one. Is it also necessary to disable the interrupt input, even though
the register write should be disabling the PMU's asserting of the
line? There doesn't seem to be much more different than that, and
setting the openpic priority, Linux sets it to 0x0f but I didn't see
anything in OS X doing that (might that be a problem, too?)
I would love to get my TiBook using the full 1GHz.
Thanks,
Justin
^ permalink raw reply
* [Doubt] PPC Linux Device Tree Update
From: Kay One @ 2012-06-11 7:52 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1.1: Type: text/plain, Size: 1098 bytes --]
Hi All,
Currently I am working on p1020rdb soc for some kernel bringing up activity.
I have come across one requirement to update the memory map (MMAP) of
kernel from evaluation board to
some other board who is having the same soc.
for my eval board I have used the p1020rdb.dts file from 2.6.38 standard
kernel source. (PFA) which is working almost fine.
But, I am really not able to find the following mapping as a part of the
attached dts file what I am using.
Can anyone please point me out that dts file is the only one to search out
following base addresses selected in memory map or is there
some specific file of kernel inside which I will be able to search through
to find the following base addresses?
FFFF_F000 4 KB .bootpg FFE0_0000 1 MB CCSR EC00_0000 64 MB Flash + alias
8000_0000 1 GB PCI[1:2] mem FFC0_0000 256 KB PCI[1:2] I/O FFB0_0000 1 MB
VTSS FFA0_0000 1 MB CPLD FF80_0000 1 MB NAND 0000_0000 1 GB DDR
So that I can update that address with the newly address given by the
vendor of new board on which I am
porting the ppc kernel.
Any help appreciated,
Karnik jain
[-- Attachment #1.2: Type: text/html, Size: 3050 bytes --]
[-- Attachment #2: p1020rdb.dts.dts --]
[-- Type: application/octet-stream, Size: 24712 bytes --]
/*
* P1020 RDB Device Tree Source
*
* Copyright 2009 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.
*/
/dts-v1/;
/ {
model = "fsl,P1020";
compatible = "fsl,P1020RDB";
#address-cells = <2>;
#size-cells = <2>;
aliases {
serial0 = &serial0;
serial1 = &serial1;
ethernet0 = &enet0;
ethernet1 = &enet1;
ethernet2 = &enet2;
pci0 = &pci0;
pci1 = &pci1;
};
cpus {
#address-cells = <1>;
#size-cells = <0>;
PowerPC,P1020@0 {
device_type = "cpu";
reg = <0x0>;
next-level-cache = <&L2>;
};
PowerPC,P1020@1 {
device_type = "cpu";
reg = <0x1>;
next-level-cache = <&L2>;
};
};
memory {
device_type = "memory";
};
localbus@ffe05000 {
#address-cells = <2>;
#size-cells = <1>;
compatible = "fsl,p1020-elbc", "fsl,elbc", "simple-bus";
reg = <0 0xffe05000 0 0x1000>;
interrupts = <19 2>;
interrupt-parent = <&mpic>;
/* NOR, NAND Flashes and Vitesse 5 port L2 switch */
ranges = <0x0 0x0 0x0 0xef000000 0x01000000
0x1 0x0 0x0 0xffa00000 0x00040000
0x2 0x0 0x0 0xffb00000 0x00020000>;
nor@0,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "cfi-flash";
reg = <0x0 0x0 0x1000000>;
bank-width = <2>;
device-width = <1>;
partition@0 {
/* This location must not be altered */
/* 256KB for Vitesse 7385 Switch firmware */
reg = <0x0 0x00040000>;
label = "NOR (RO) Vitesse-7385 Firmware";
read-only;
};
partition@40000 {
/* 256KB for DTB Image */
reg = <0x00040000 0x00040000>;
label = "NOR (RO) DTB Image";
read-only;
};
partition@80000 {
/* 3.5 MB for Linux Kernel Image */
reg = <0x00080000 0x00380000>;
label = "NOR (RO) Linux Kernel Image";
read-only;
};
partition@400000 {
/* 11MB for JFFS2 based Root file System */
reg = <0x00400000 0x00b00000>;
label = "NOR (RW) JFFS2 Root File System";
};
partition@f00000 {
/* This location must not be altered */
/* 512KB for u-boot Bootloader Image */
/* 512KB for u-boot Environment Variables */
reg = <0x00f00000 0x00100000>;
label = "NOR (RO) U-Boot Image";
read-only;
};
};
nand@1,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,p1020-fcm-nand",
"fsl,elbc-fcm-nand";
reg = <0x1 0x0 0x40000>;
partition@0 {
/* This location must not be altered */
/* 1MB for u-boot Bootloader Image */
reg = <0x0 0x00100000>;
label = "NAND (RO) U-Boot Image";
read-only;
};
partition@100000 {
/* 1MB for DTB Image */
reg = <0x00100000 0x00100000>;
label = "NAND (RO) DTB Image";
read-only;
};
partition@200000 {
/* 4MB for Linux Kernel Image */
reg = <0x00200000 0x00400000>;
label = "NAND (RO) Linux Kernel Image";
read-only;
};
partition@600000 {
/* 4MB for Compressed Root file System Image */
reg = <0x00600000 0x00400000>;
label = "NAND (RO) Compressed RFS Image";
read-only;
};
partition@a00000 {
/* 7MB for JFFS2 based Root file System */
reg = <0x00a00000 0x00700000>;
label = "NAND (RW) JFFS2 Root File System";
};
partition@1100000 {
/* 15MB for JFFS2 based Root file System */
reg = <0x01100000 0x00f00000>;
label = "NAND (RW) Writable User area";
};
};
L2switch@2,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "vitesse-7385";
reg = <0x2 0x0 0x20000>;
};
};
soc@ffe00000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
compatible = "fsl,p1020-immr", "simple-bus";
ranges = <0x0 0x0 0xffe00000 0x100000>;
bus-frequency = <0>; // Filled out by uboot.
ecm-law@0 {
compatible = "fsl,ecm-law";
reg = <0x0 0x1000>;
fsl,num-laws = <12>;
};
ecm@1000 {
compatible = "fsl,p1020-ecm", "fsl,ecm";
reg = <0x1000 0x1000>;
interrupts = <16 2>;
interrupt-parent = <&mpic>;
};
memory-controller@2000 {
compatible = "fsl,p1020-memory-controller";
reg = <0x2000 0x1000>;
interrupt-parent = <&mpic>;
interrupts = <16 2>;
};
i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <0>;
compatible = "fsl-i2c";
reg = <0x3000 0x100>;
interrupts = <43 2>;
interrupt-parent = <&mpic>;
dfsrr;
rtc@68 {
compatible = "dallas,ds1339";
reg = <0x68>;
};
};
i2c@3100 {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <1>;
compatible = "fsl-i2c";
reg = <0x3100 0x100>;
interrupts = <43 2>;
interrupt-parent = <&mpic>;
dfsrr;
};
serial0: serial@4500 {
cell-index = <0>;
device_type = "serial";
compatible = "ns16550";
reg = <0x4500 0x100>;
clock-frequency = <0>;
interrupts = <42 2>;
interrupt-parent = <&mpic>;
};
serial1: serial@4600 {
cell-index = <1>;
device_type = "serial";
compatible = "ns16550";
reg = <0x4600 0x100>;
clock-frequency = <0>;
interrupts = <42 2>;
interrupt-parent = <&mpic>;
};
spi@7000 {
cell-index = <0>;
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,espi";
reg = <0x7000 0x1000>;
interrupts = <59 0x2>;
interrupt-parent = <&mpic>;
mode = "cpu";
fsl_m25p80@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,espi-flash";
reg = <0>;
linux,modalias = "fsl_m25p80";
modal = "s25sl128b";
spi-max-frequency = <50000000>;
mode = <0>;
partition@0 {
/* 512KB for u-boot Bootloader Image */
reg = <0x0 0x00080000>;
label = "SPI (RO) U-Boot Image";
read-only;
};
partition@80000 {
/* 512KB for DTB Image */
reg = <0x00080000 0x00080000>;
label = "SPI (RO) DTB Image";
read-only;
};
partition@100000 {
/* 4MB for Linux Kernel Image */
reg = <0x00100000 0x00400000>;
label = "SPI (RO) Linux Kernel Image";
read-only;
};
partition@500000 {
/* 4MB for Compressed RFS Image */
reg = <0x00500000 0x00400000>;
label = "SPI (RO) Compressed RFS Image";
read-only;
};
partition@900000 {
/* 7MB for JFFS2 based RFS */
reg = <0x00900000 0x00700000>;
label = "SPI (RW) JFFS2 RFS";
};
};
};
gpio: gpio-controller@f000 {
#gpio-cells = <2>;
compatible = "fsl,mpc8572-gpio";
reg = <0xf000 0x100>;
interrupts = <47 0x2>;
interrupt-parent = <&mpic>;
gpio-controller;
};
L2: l2-cache-controller@20000 {
compatible = "fsl,p1020-l2-cache-controller";
reg = <0x20000 0x1000>;
cache-line-size = <32>; // 32 bytes
cache-size = <0x40000>; // L2,256K
interrupt-parent = <&mpic>;
interrupts = <16 2>;
};
dma@21300 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,eloplus-dma";
reg = <0x21300 0x4>;
ranges = <0x0 0x21100 0x200>;
cell-index = <0>;
dma-channel@0 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x0 0x80>;
cell-index = <0>;
interrupt-parent = <&mpic>;
interrupts = <20 2>;
};
dma-channel@80 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x80 0x80>;
cell-index = <1>;
interrupt-parent = <&mpic>;
interrupts = <21 2>;
};
dma-channel@100 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x100 0x80>;
cell-index = <2>;
interrupt-parent = <&mpic>;
interrupts = <22 2>;
};
dma-channel@180 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x180 0x80>;
cell-index = <3>;
interrupt-parent = <&mpic>;
interrupts = <23 2>;
};
};
mdio@24000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,etsec2-mdio";
reg = <0x24000 0x1000 0xb0030 0x4>;
phy0: ethernet-phy@0 {
interrupt-parent = <&mpic>;
interrupts = <3 1>;
reg = <0x0>;
};
phy1: ethernet-phy@1 {
interrupt-parent = <&mpic>;
interrupts = <2 1>;
reg = <0x1>;
};
};
mdio@25000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,etsec2-tbi";
reg = <0x25000 0x1000 0xb1030 0x4>;
tbi0: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
};
};
enet0: ethernet@b0000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "network";
model = "eTSEC";
compatible = "fsl,etsec2";
fsl,num_rx_queues = <0x8>;
fsl,num_tx_queues = <0x8>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupt-parent = <&mpic>;
fixed-link = <1 1 1000 0 0>;
phy-connection-type = "rgmii-id";
queue-group@0 {
#address-cells = <1>;
#size-cells = <1>;
reg = <0xb0000 0x1000>;
interrupts = <29 2 30 2 34 2>;
};
queue-group@1 {
#address-cells = <1>;
#size-cells = <1>;
reg = <0xb4000 0x1000>;
interrupts = <17 2 18 2 24 2>;
};
};
enet1: ethernet@b1000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "network";
model = "eTSEC";
compatible = "fsl,etsec2";
fsl,num_rx_queues = <0x8>;
fsl,num_tx_queues = <0x8>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupt-parent = <&mpic>;
phy-handle = <&phy0>;
tbi-handle = <&tbi0>;
phy-connection-type = "sgmii";
queue-group@0 {
#address-cells = <1>;
#size-cells = <1>;
reg = <0xb1000 0x1000>;
interrupts = <35 2 36 2 40 2>;
};
queue-group@1 {
#address-cells = <1>;
#size-cells = <1>;
reg = <0xb5000 0x1000>;
interrupts = <51 2 52 2 67 2>;
};
};
enet2: ethernet@b2000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "network";
model = "eTSEC";
compatible = "fsl,etsec2";
fsl,num_rx_queues = <0x8>;
fsl,num_tx_queues = <0x8>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupt-parent = <&mpic>;
phy-handle = <&phy1>;
phy-connection-type = "rgmii-id";
queue-group@0 {
#address-cells = <1>;
#size-cells = <1>;
reg = <0xb2000 0x1000>;
interrupts = <31 2 32 2 33 2>;
};
queue-group@1 {
#address-cells = <1>;
#size-cells = <1>;
reg = <0xb6000 0x1000>;
interrupts = <25 2 26 2 27 2>;
};
};
usb@22000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl-usb2-dr";
reg = <0x22000 0x1000>;
interrupt-parent = <&mpic>;
interrupts = <28 0x2>;
phy_type = "ulpi";
};
/* USB2 is shared with localbus, so it must be disabled
by default. We can't put 'status = "disabled";' here
since U-Boot doesn't clear the status property when
it enables USB2. OTOH, U-Boot does create a new node
when there isn't any. So, just comment it out.
usb@23000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl-usb2-dr";
reg = <0x23000 0x1000>;
interrupt-parent = <&mpic>;
interrupts = <46 0x2>;
phy_type = "ulpi";
};
*/
sdhci@2e000 {
compatible = "fsl,p1020-esdhc", "fsl,esdhc";
reg = <0x2e000 0x1000>;
interrupts = <72 0x2>;
interrupt-parent = <&mpic>;
/* Filled in by U-Boot */
clock-frequency = <0>;
};
crypto@30000 {
compatible = "fsl,sec3.1", "fsl,sec3.0", "fsl,sec2.4",
"fsl,sec2.2", "fsl,sec2.1", "fsl,sec2.0";
reg = <0x30000 0x10000>;
interrupts = <45 2 58 2>;
interrupt-parent = <&mpic>;
fsl,num-channels = <4>;
fsl,channel-fifo-len = <24>;
fsl,exec-units-mask = <0xbfe>;
fsl,descriptor-types-mask = <0x3ab0ebf>;
};
mpic: pic@40000 {
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <0x40000 0x40000>;
compatible = "chrp,open-pic";
device_type = "open-pic";
};
msi@41600 {
compatible = "fsl,p1020-msi", "fsl,mpic-msi";
reg = <0x41600 0x80>;
msi-available-ranges = <0 0x100>;
interrupts = <
0xe0 0
0xe1 0
0xe2 0
0xe3 0
0xe4 0
0xe5 0
0xe6 0
0xe7 0>;
interrupt-parent = <&mpic>;
};
global-utilities@e0000 { //global utilities block
compatible = "fsl,p1020-guts";
reg = <0xe0000 0x1000>;
fsl,has-rstcr;
};
};
pci0: pcie@ffe09000 {
compatible = "fsl,mpc8548-pcie";
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <0 0xffe09000 0 0x1000>;
bus-range = <0 255>;
ranges = <0x2000000 0x0 0xa0000000 0 0xa0000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0 0xffc30000 0x0 0x10000>;
clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
interrupts = <16 2>;
pcie@0 {
reg = <0x0 0x0 0x0 0x0 0x0>;
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
ranges = <0x2000000 0x0 0xa0000000
0x2000000 0x0 0xa0000000
0x0 0x20000000
0x1000000 0x0 0x0
0x1000000 0x0 0x0
0x0 0x100000>;
};
};
pci1: pcie@ffe0a000 {
compatible = "fsl,mpc8548-pcie";
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <0 0xffe0a000 0 0x1000>;
bus-range = <0 255>;
ranges = <0x2000000 0x0 0xc0000000 0 0xc0000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0 0xffc20000 0x0 0x10000>;
clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
interrupts = <16 2>;
pcie@0 {
reg = <0x0 0x0 0x0 0x0 0x0>;
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
ranges = <0x2000000 0x0 0xc0000000
0x2000000 0x0 0xc0000000
0x0 0x20000000
0x1000000 0x0 0x0
0x1000000 0x0 0x0
0x0 0x100000>;
};
};
};
^ permalink raw reply
* RE: Question about MPIC_SINGLE_DEST_CPU on P1020 (e500 core) SMP
From: Li Yang-R58472 @ 2012-06-11 9:36 UTC (permalink / raw)
To: Gopalakrishnan Raman, linuxppc-dev@lists.ozlabs.org; +Cc: rgkwstl@gmail.com
In-Reply-To: <802E1C77E421D345A43385A6BFAC7AC4BE502C@ROYALGORGE.arubanetworks.com>
> Subject: Question about MPIC_SINGLE_DEST_CPU on P1020 (e500 core) SMP
>=20
> Hi
> The P1020 manual states (in the PIC chapter) that in the "Internal
> Interrupt Destination" register, only 1 CPU (and not both) can be
> selected as the IRQ destination. How then can we achieve "interrupt
> spraying" for the PCI interrupt (we want interrupts to be sent
> alternately to CPU0 and CPU1). Also, =A0we changed the code to ignore the
> MPIC_SINGLE_DEST_CPU flag and set both CPUs in the destination of the
> PIC_IIDRn register. This does seem to work. But we're not sure if we can
> rely on this behavior and whether it will cause other problems.
I suggest you to follow the UM. The note should be there for a reason alth=
ough personally I don't know what the specific problem will be.
Leo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox