* Re: [PATCH] PPC: PCI: Fix pcibios_io_space_offset() so it works for 32-bit ptr/64-bit rsrcs
From: Ben Collins @ 2012-06-08 18:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <1339104753.24838.30.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]
On Jun 7, 2012, at 5:32 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2012-06-07 at 11:38 -0400, Ben Collins wrote:
>>> Note that oddly, the second range of bus addresses looks -more-
>> correct
>>> than the first one...
>>
>> Except that the first one is exactly the same bus address as my bare
>> metal system:
>>
>> 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.
--
Bluecherry: http://www.bluecherrydvr.com/
SwissDisk : http://www.swissdisk.com/
Ubuntu : http://www.ubuntu.com/
My Blog : http://ben-collins.blogspot.com/
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 203 bytes --]
^ permalink raw reply
* Re: P2010 External HW IRQ number?
From: Scott Wood @ 2012-06-08 19:23 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev
In-Reply-To: <OF71CEA252.1CE143D5-ONC1257A17.00329573-C1257A17.003D00D0@transmode.se>
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
For external interrupts, the first cell is equal to the IRQ number.
For an example of specifying an external IRQ, see the RTC and PHY nodes
in various mpc85xx device trees (e.g. mpc8536ds.dtsi).
> What do I use with request_irq(?,....)?
You need a virtual IRQ number. Typically this comes from
irq_of_parse_and_map().
-Scott
^ permalink raw reply
* Re: [PATCH 5/15] powerpc: convert to %r for all GPR usage
From: Jesse Larrew @ 2012-06-08 21:54 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20120608113605.75BD5D43B26@localhost.localdomain>
On 06/08/2012 06:36 AM, Michael Neuling wrote:
> -/* General Purpose Registers (GPRs) */
> +/*
> + * General Purpose Registers (GPRs)
> + *
> + * The lower case r0-r31 should be used in preference to the upper
> + * case R0-R31 as they provide more error checking in the assembler.
> + * Use R0-31 only when really nessesary.
> + */
>
> -#define r0 0
> -#define r1 1
> -#define r2 2
> -#define r3 3
> -#define r4 4
> -#define r5 5
> -#define r6 6
> -#define r7 7
> -#define r8 8
> -#define r9 9
> -#define r10 10
> -#define r11 11
> -#define r12 12
> -#define r13 13
> -#define r14 14
> -#define r15 15
> -#define r16 16
> -#define r17 17
> -#define r18 18
> -#define r19 19
> -#define r20 20
> -#define r21 21
> -#define r22 22
> -#define r23 23
> -#define r24 24
> -#define r25 25
> -#define r26 26
> -#define r27 27
> -#define r28 28
> -#define r29 29
> -#define r30 30
> -#define r31 31
> +#define r0 %r0
> +#define r1 %r1
> +#define r2 %r2
> +#define r3 %r3
> +#define r4 %r4
> +#define r5 %r5
> +#define r6 %r6
> +#define r7 %r7
> +#define r8 %r8
> +#define r9 %r9
> +#define r10 %r10
> +#define r11 %r11
> +#define r12 %r12
> +#define r13 %r13
> +#define r14 %r14
> +#define r15 %r15
> +#define r16 %r16
> +#define r17 %r17
> +#define r18 %r18
> +#define r19 %r19
> +#define r20 %r20
> +#define r21 %r21
> +#define r22 %r22
> +#define r23 %r23
> +#define r24 %r24
> +#define r25 %r25
> +#define r26 %r26
> +#define r27 %r27
> +#define r28 %r28
> +#define r29 %r29
> +#define r30 %r30
> +#define r31 %r31
>
> #define R0 0
> #define R1 1
I think your patch was truncated somehow.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
Jesse Larrew
Software Engineer, Linux on Power Kernel Team
IBM Linux Technology Center
Phone: (512) 973-2052 (T/L: 363-2052)
jlarrew@linux.vnet.ibm.com
^ permalink raw reply
* 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
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