Re: [PATCH 01/15] i2c/powermac: Register i2c devices from device-tree
Benjamin Herrenschmidt b...@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,f200/pci@1/mac-io@7/i2c@18000/deq@6a i2c i2c-5: i2c-powermac: invalid reg on /ht@0,f200/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,f800/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,f200/pci@1/mac-io@7/i2c@18000/deq@6a is under i2c. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/15] i2c/powermac: Register i2c devices from device-tree
On Sun, 2012-06-10 at 09:13 +0200, Andreas Schwab wrote: Benjamin Herrenschmidt b...@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,f200/pci@1/mac-io@7/i2c@18000/deq@6a i2c i2c-5: i2c-powermac: invalid reg on /ht@0,f200/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,f800/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,f200/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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Kill flatdevtree_env.h too
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 pebo...@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..000 --- 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 mgr...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/15] i2c/powermac: Register i2c devices from device-tree
Benjamin Herrenschmidt b...@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,f800/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,f200/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,f200/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, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
PowerMac PMU programming
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerMac PMU programming
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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] usb: fsl_udc: errata - postpone freeing current dTD
Hi Christoph,
On Mon, Jun 4, 2012 at 8:37 AM, Christoph Fritz
chf.fr...@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);
}
}
--
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Question about MPIC_SINGLE_DEST_CPU on P1020 (e500 core) SMP
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[no subject]
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 0/6] Description for PCI patches using platform driver
-Original Message- From: Bhushan Bharat-R65777 Sent: Friday, June 08, 2012 6:47 PM To: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org Cc: Li Yang-R58472; b...@kernel.crashing.org; Wood Scott-B07421 Subject: RE: [PATCH 0/6] Description for PCI patches using platform driver -Original Message- From: Jia Hongtao-B38951 Sent: Friday, June 08, 2012 3:12 PM To: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org Cc: Li Yang-R58472; b...@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]. With these patches will not the SWIOTLB will not be initialized even if PCI/PCIe demanded? Thanks -Bharat These patches still have the swiotlb init problem if ppc_swiotlb_enable is 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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerMac PMU programming
On Mon, 11 Jun 2012 09:03:13 +1000 Benjamin Herrenschmidt b...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
