RE: [PATCH] powerpc/44x: Support OCM(On Chip Memory) for APM821xx SoC and Bluestone board
-Original Message-
From: Vinh Nguyen Huu Tuong [mailto:vhtngu...@apm.com]
Sent: Monday, May 07, 2012 10:53 AM
To: Benjamin Herrenschmidt; Paul Mackerras; Josh Boyer; Matt Porter;
Grant Likely; Rob Herring; Duc Dang; David S. Miller; Kumar Gala; Li
Yang; Ashish Kalra; Anatolij Gustschin; Liu Gang; linuxppc-
d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; devicetree-
disc...@lists.ozlabs.org
Cc: Vinh Nguyen Huu Tuong
Subject: [PATCH] powerpc/44x: Support OCM(On Chip Memory) for APM821xx
SoC and Bluestone board
This patch consists of:
- Add driver for OCM component
- Export OCM Information at /sys/class/ocm/ocminfo
Signed-off-by: Vinh Nguyen Huu Tuong vhtngu...@apm.com
---
arch/powerpc/boot/dts/bluestone.dts |8 +
arch/powerpc/include/asm/ppc4xx_ocm.h | 47
arch/powerpc/platforms/44x/Kconfig|8 +
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/ppc4xx_ocm.c | 420
+
5 files changed, 484 insertions(+), 0 deletions(-) create mode 100644
arch/powerpc/include/asm/ppc4xx_ocm.h
create mode 100644 arch/powerpc/sysdev/ppc4xx_ocm.c
diff --git a/arch/powerpc/boot/dts/bluestone.dts
b/arch/powerpc/boot/dts/bluestone.dts
index 7bda373..2687c11 100644
--- a/arch/powerpc/boot/dts/bluestone.dts
+++ b/arch/powerpc/boot/dts/bluestone.dts
@@ -107,6 +107,14 @@
interrupt-parent = UIC0;
};
+ OCM1: ocm@40004 {
+ compatible = ibm,ocm;
+ status = ok;
+ cell-index = 1;
+ /* configured in U-Boot */
+ reg = 4 0x0004 0x8000; /* 32K */
+ };
+
SDR0: sdr {
compatible = ibm,sdr-apm821xx;
dcr-reg = 0x00e 0x002;
diff --git a/arch/powerpc/include/asm/ppc4xx_ocm.h
b/arch/powerpc/include/asm/ppc4xx_ocm.h
new file mode 100644
index 000..ff7f386
--- /dev/null
+++ b/arch/powerpc/include/asm/ppc4xx_ocm.h
@@ -0,0 +1,47 @@
+/*
+ * PowerPC 4xx OCM memory allocation support
+ *
+ * (C) Copyright 2009, Applied Micro Circuits Corporation
+ * Victor Gallardo (vgalla...@amcc.com)
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __ASM_POWERPC_PPC4xx_OCM_H__
+#define __ASM_POWERPC_PPC4xx_OCM_H__
+
+#include linux/types.h
+
+#define OCM_NON_CACHED 0
+#define OCM_CACHED 1
+
+#if defined(CONFIG_PPC4xx_OCM)
+
+void *ocm_alloc(phys_addr_t *phys, int size, int align,
+ int flags, const char *owner);
+void ocm_free(const void *virt);
+
+#else
+
+#define ocm_alloc(phys, size, align, flags, owner) NULL
+#define ocm_free(addr) ((void)0)
+
+#endif /* CONFIG_PPC4xx_OCM */
+
+#endif /* __ASM_POWERPC_PPC4xx_OCM_H__ */
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
index 2e4e64a..6b1a64e 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -250,6 +250,14 @@ config PPC4xx_GPIO
help
Enable gpiolib support for ppc440 based boards
+config PPC4xx_OCM
+ bool PPC4xx On Chip Memory (OCM) support
+ depends on 4xx
+ select PPC_LIB_RHEAP
+ help
+ Enable OCM support for PowerPC 4xx platforms with on chip
memory,
+ OCM provides the fast place for memory access to improve
performance.
+
# 44x specific CPU modules, selected based on the board above.
config 440EP
bool
diff --git a/arch/powerpc/sysdev/Makefile
b/arch/powerpc/sysdev/Makefile index 1bd7ecb..6f768e2 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_PPC_INDIRECT_PCI) += indirect_pci.o
obj-$(CONFIG_PPC_I8259) += i8259.o
obj-$(CONFIG_IPIC) += ipic.o
obj-$(CONFIG_4xx)+= uic.o
+obj-$(CONFIG_PPC4xx_OCM) += ppc4xx_ocm.o
obj-$(CONFIG_4xx_SOC)+= ppc4xx_soc.o
obj-$(CONFIG_XILINX_VIRTEX) += xilinx_intc.o
obj-$(CONFIG_XILINX_PCI) += xilinx_pci.o
diff --git a/arch/powerpc/sysdev/ppc4xx_ocm.c
b/arch/powerpc/sysdev/ppc4xx_ocm.c
new file mode 100644
index 000..ba3e450
--- /dev/null
+++ b/arch/powerpc/sysdev/ppc4xx_ocm.c
@@ -0,0
RE: reserving memory using OF rsvmap feature?
Is it possible to reserve some memory using OF rsvmap such that Linux will not touch this area at all? Think of is as warm start stash area were one could store data which should survive a reboot. Yes, I guess it should be possible, but you need to take care where you place this block so it does not get overwritten during the boot process. This depends on how your bootloader is set up to place images in memory, decompress them etc. I don't know about OF, but in U-Boot use the function fdt_add_mem_rsv() in file http://git.denx.de/?p=u-boot.git;a=blob;f=lib/libfdt/fdt_rw.c // Reserve the memory location of the framebuffer + descriptor page. if (fdt_add_mem_rsv(working_fdt, fbinfo-smem_start, (fbinfo-smem_len + 0x1FFF) 0xF000)) printf(ERROR: could not reserve FB memory in device tree\n); In my powerpc_e500v2 systems this block is located at 64MiB (0x0400). Clive ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/2] uprobes: Pass probed vaddr to arch_uprobe_analyze_insn()
Well, IMHO, this is confusing. First of all, why do we have this addr or even vaddr? It should not exists. We pass it to copy_insn(), but for what?? copy_insn() should simply use uprobe-offset, the virtual address for this particular mapping does not matter at all. I am going to send the cleanup. Yes, we can use uprobe-offset instead of vaddr/addr. Note also that we should move this !UPROBE_COPY_INSN from install_breakpoint() to somewhere near alloc_uprobe(). This code is called only once, it looks a bit strange to use the random mm (the first mm vma_prio_tree_foreach() finds) and its mapping to verify the insn. In fact this is simply not correct and should be fixed, note that on x86 arch_uprobe_analyze_insn() checks The reason we delay the copy_insn to the first insert is because we have to get access to mm. For archs like x86, we want to know if the executable is 32 bit or not (since we have a different valid set of instructions for 32 bit and 64 bit). So in effect, if we get access to struct file corresponding to the inode and if the inode corresponds to 32 bit executable file or 64 bit executable file during register, then we can move it around alloc_uprobe(). ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: reserving memory using OF rsvmap feature?
Jenkins, Clive clive.jenk...@xerox.com wrote on 2012/06/12 17:48:15: Is it possible to reserve some memory using OF rsvmap such that Linux will not touch this area at all? Think of is as warm start stash area were one could store data which should survive a reboot. Yes, I guess it should be possible, but you need to take care where you place this block so it does not get overwritten during the boot process. This depends on how your bootloader is set up to place images in memory, decompress them etc. I don't know about OF, but in U-Boot use the function fdt_add_mem_rsv() in file http://git.denx.de/?p=u-boot.git;a=blob;f=lib/libfdt/fdt_rw.c // Reserve the memory location of the framebuffer + descriptor page. if (fdt_add_mem_rsv(working_fdt, fbinfo-smem_start, (fbinfo-smem_len + 0x1FFF) 0xF000)) printf(ERROR: could not reserve FB memory in device tree\n); In my powerpc_e500v2 systems this block is located at 64MiB (0x0400). Thanks, this was what I was looking at too. I plan to use u-boots PRAM feature and reserve memory at the end of RAM. Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/2] uprobes: Pass probed vaddr to arch_uprobe_analyze_insn()
On 06/12, Srikar Dronamraju wrote: Note also that we should move this !UPROBE_COPY_INSN from install_breakpoint() to somewhere near alloc_uprobe(). This code is called only once, it looks a bit strange to use the random mm (the first mm vma_prio_tree_foreach() finds) and its mapping to verify the insn. In fact this is simply not correct and should be fixed, note that on x86 arch_uprobe_analyze_insn() checks The reason we delay the copy_insn to the first insert is because we have to get access to mm. For archs like x86, we want to know if the executable is 32 bit or not Yes. And this is wrong afaics. Once again. This !UPROBE_COPY_INSN code is called only once, and it uses the random mm. After that install_breakpoint() just calls set_swbp(another_mm) while the insn can be invalid because another_mm-ia32_compat != mm-ia32_compat. So in effect, if we get access to struct file corresponding to the inode and if the inode corresponds to 32 bit executable file or 64 bit executable file during register, then we can move it around alloc_uprobe(). I don't think this can work. I have another simple fix in mind, I'll write another email later. Oleg. ___ 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 Fabio On Sun, 2012-06-10 at 15:41 -0300, Fabio Estevam wrote: 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? Thanks for your patch. It does indeed load Freescale High-Speed USB SOC Device Controller driver (Apr 20, 2007) fine - but now when I want to use it: modprobe g_ether [ 17.099363] g_ether gadget: using random self ethernet address [ 17.105316] g_ether gadget: using random host ethernet address [ 17.111974] usb0: MAC 1a:c7:9e:76:cc:45 [ 17.115866] usb0: HOST MAC 66:a2:4a:0a:46:17 [ 17.120199] g_ether gadget: Ethernet Gadget, version: Memorial Day 2008 [ 17.126861] g_ether gadget: g_ether ready these are the last words: System hangs completely. Same behavior with g_serial (these two I've tested). Currently I can't investigate this further, not because of a bug - but a flu. Thanks, -- Christoph ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
QUICC Engine USB Host controller
Hi guys,
I'm struggling to make the QUICC engine USB host controller to work.
Thus, I came here in the hope to get some light =)
I am working on MPC8321 processor and kernel 2.6.32. Comparing against
the mainstream version, I applied some patches to fix some pŕoblems in
the FHCI driver, then it got running.
Now, it seems that the driver detects a new device, but is not able to
get its description. I'm aware that the driver uses the timer to
synchronize its packets exchange, but I couldn't find the proper timer
clock frequency. I've already tried every value I could derive from
the documentation, once as long as I am concerned there is no way to
measure it.
Here follows a relevant dmesg USB driver output, where there is a timeout error:
[ 24.396373] usbcore: registered new interface driver usbfs
[ 24.405860] usbcore: registered new interface driver hub
[ 24.414642] usbcore: registered new device driver usb
[ 24.706132] fsl,usb-fhci e01006c0.usb: at 0xcbaf66c0, irq 23
[ 24.721953] fsl,usb-fhci e01006c0.usb: FHCI HOST Controller
[ 24.734528] fsl,usb-fhci e01006c0.usb: new USB bus registered,
assigned bus number 1
[ 24.745942] fsl,usb-fhci e01006c0.usb: irq 23, io mem 0x
[ 24.853738] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
[ 24.860623] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[ 24.867902] usb usb1: Product: FHCI HOST Controller
[ 24.872836] usb usb1: Manufacturer: Linux 2.6.32 fsl,usb-fhci
[ 24.878633] usb usb1: SerialNumber: e01006c0.usb
[ 24.937686] usb usb1: configuration #1 chosen from 1 choice
[ 24.957830] hub 1-0:1.0: USB hub found
[ 24.968867] hub 1-0:1.0: 1 port detected
[ 25.367766] usb 1-1: new full speed USB device using fsl,usb-fhci
and address 2
[ 25.531795] usb 1-1: device descriptor read/64, error -110
[ 25.787864] usb 1-1: device descriptor read/64, error -110
[ 26.024464] usb 1-1: new full speed USB device using fsl,usb-fhci
and address 3
[ 26.199736] usb 1-1: device descriptor read/64, error -110
[ 26.455838] usb 1-1: device descriptor read/64, error -110
[ 26.688100] usb 1-1: new full speed USB device using fsl,usb-fhci
and address 4
[ 27.123765] usb 1-1: device not accepting address 4, error -110
[ 27.271797] usb 1-1: new full speed USB device using fsl,usb-fhci
and address 5
[ 27.712333] usb 1-1: device not accepting address 5, error -110
[ 27.735892] hub 1-0:1.0: unable to enumerate USB device on port 1
And here follows a snippet from my device tree:
qe@e010 {
#address-cells = 1;
#size-cells= 1;
device_type = qe;
compatible = fsl,qe;
reg = 0xe010 0x480;
ranges = 0x0 0xe010 0x10;
brg-frequency = 0;
bus-frequency = 0;
timer@440 {
compatible = fsl,mpc8321-qe-gtm,
fsl,mpc8360-qe-gtm,
fsl,qe-gtm, fsl,gtm;
reg = 0x440 0x40; // 64 bytes @ offset 0x000440
interrupts = 12 13 14 15;
interrupt-parent = qeic;
clock-frequency = 1; // 100 MHz???
};
usb@6C0 {
#address-cells = 1;
#size-cells= 0;
compatible = fsl,mpc8321-qe-usb,
fsl,mpc8323-qe-usb,
fsl,mpc8360-qe-usb;
reg = 0x6c0 0x40 0x700 0x100;
interrupts = 11;
interrupt-parent = qeic;
mode = host;
fsl,fullspeed-clock = clk3;
hub-power-budget = 100;
gpios =
qe_pio_a 8 0 // USBOE
qe_pio_a 1 0 // USBTXP
qe_pio_a 0 0 // USBTXN
qe_pio_a 4 0 // USBRXP
qe_pio_a 5 0 // USBRXN
qe_pio_d 21 1 // SPEED
qe_pio_d 25 0 // POWER/SUSPEND
;
};
};
Thanks in advance for anyone willing to help me.
Best regards,
--
Guilherme Maciel Ferreira
Site: http://guilhermemacielferreira.com/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/booke-64: fix tlbsrx. path in bolted tlb handler
It was branching to the cleanup part of the non-bolted handler, which would have been bad if there were any chips with tlbsrx. that use the bolted handler. Signed-off-by: Scott Wood sc...@tyr.buserror.net --- arch/powerpc/mm/tlb_low_64e.S |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/mm/tlb_low_64e.S b/arch/powerpc/mm/tlb_low_64e.S index ff672bd..efe0f33 100644 --- a/arch/powerpc/mm/tlb_low_64e.S +++ b/arch/powerpc/mm/tlb_low_64e.S @@ -128,7 +128,7 @@ BEGIN_MMU_FTR_SECTION */ PPC_TLBSRX_DOT(0,r16) ldx r14,r14,r15 /* grab pgd entry */ - beq normal_tlb_miss_done/* tlb exists already, bail */ + beq tlb_miss_done_bolted/* tlb exists already, bail */ MMU_FTR_SECTION_ELSE ldx r14,r14,r15 /* grab pgd entry */ ALT_MMU_FTR_SECTION_END_IFSET(MMU_FTR_USE_TLBRSRV) @@ -184,6 +184,7 @@ ALT_MMU_FTR_SECTION_END_IFSET(MMU_FTR_USE_TLBRSRV) mtspr SPRN_MAS7_MAS3,r15 tlbwe +tlb_miss_done_bolted: TLB_MISS_STATS_X(MMSTAT_TLB_MISS_NORM_OK) tlb_epilog_bolted rfi -- 1.7.5.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/44x: Support OCM(On Chip Memory) for APM821xx SoC and Bluestone board
On Tue, 2012-06-12 at 17:26 +0700, Vinh Huu Tuong Nguyen wrote: -Original Message- From: Vinh Nguyen Huu Tuong [mailto:vhtngu...@apm.com] Sent: Monday, May 07, 2012 10:53 AM To: Benjamin Herrenschmidt; Paul Mackerras; Josh Boyer; Matt Porter; Grant Likely; Rob Herring; Duc Dang; David S. Miller; Kumar Gala; Li Yang; Ashish Kalra; Anatolij Gustschin; Liu Gang; linuxppc- d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; devicetree- disc...@lists.ozlabs.org Cc: Vinh Nguyen Huu Tuong Subject: [PATCH] powerpc/44x: Support OCM(On Chip Memory) for APM821xx SoC and Bluestone board Such a CC list won't get you any good will. Send it only to the relevant mailing lists with possibly the -one- concerned maintainer on CC. I doubt Dave Miller or Matt Porter give any damn about those patches. As for why it wasn't reviewed yet, well, reviewers are a finite resource with limited time dedicated to it. If the patch is properly formed and was posted to the linuxppc-...@ozlabs.org, it should be tracked on patchwork.ozlabs.org and won't be lost. Double check it's there (if it's not, then the patch was probably corrupt). 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
On Tue, Jun 12, 2012 at 4:40 PM, Christoph Fritz chf.fr...@googlemail.com wrote: Thanks for your patch. It does indeed load Freescale High-Speed USB SOC Device Controller driver (Apr 20, 2007) fine - but now when I want to use it: modprobe g_ether [ 17.099363] g_ether gadget: using random self ethernet address [ 17.105316] g_ether gadget: using random host ethernet address [ 17.111974] usb0: MAC 1a:c7:9e:76:cc:45 [ 17.115866] usb0: HOST MAC 66:a2:4a:0a:46:17 [ 17.120199] g_ether gadget: Ethernet Gadget, version: Memorial Day 2008 [ 17.126861] g_ether gadget: g_ether ready these are the last words: System hangs completely. Same behavior with g_serial (these two I've tested). Ok, I just sent a new patch to the linux-usb mailing list. Tested it on a mx31 and mx51 and it probed g_ether fine. I don't have a mx35 handy. Currently I can't investigate this further, not because of a bug - but a flu. Hope you get better soon. Regards, Fabio Estevam ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/44x: Support OCM(On Chip Memory) for APM821xx SoC and Bluestone board
On Tue, Jun 12, 2012 at 8:40 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Tue, 2012-06-12 at 17:26 +0700, Vinh Huu Tuong Nguyen wrote: -Original Message- From: Vinh Nguyen Huu Tuong [mailto:vhtngu...@apm.com] Sent: Monday, May 07, 2012 10:53 AM To: Benjamin Herrenschmidt; Paul Mackerras; Josh Boyer; Matt Porter; Grant Likely; Rob Herring; Duc Dang; David S. Miller; Kumar Gala; Li Yang; Ashish Kalra; Anatolij Gustschin; Liu Gang; linuxppc- d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; devicetree- disc...@lists.ozlabs.org Cc: Vinh Nguyen Huu Tuong Subject: [PATCH] powerpc/44x: Support OCM(On Chip Memory) for APM821xx SoC and Bluestone board Such a CC list won't get you any good will. Send it only to the relevant mailing lists with possibly the -one- concerned maintainer on CC. I doubt Dave Miller or Matt Porter give any damn about those patches. As for why it wasn't reviewed yet, well, reviewers are a finite resource with limited time dedicated to it. If the patch is properly formed and was posted to the linuxppc-...@ozlabs.org, it should be tracked on patchwork.ozlabs.org and won't be lost. Double check it's there (if it's not, then the patch was probably corrupt). It's there. I just missed it until today. My apologies Vinh. I'll do a more formal review tomorrow, but at first glance I'm concerned with the sysfs usage. The files in sysfs are supposed to be one file per value, and you see to have something akin to /proc/meminfo in the sysfs file being created. Perhaps that would be better either split into unique file names per field in sysfs, or in a debugfs file instead? Again, I'll review more closely tomrorow. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] [PATCH 05/10] powerpc/ps3: Use highmem region from repository
On Wed, 2012-04-25 at 19:19 +, Andre Heider wrote: Use any preallocated highmem region setup by the bootloader. This implementation only checks for the existance of a single region at region_index=0. This feature allows the bootloader to preallocate highmem regions and pass the region locations to the kernel through the repository. Preallocated regions can be used to hold the initrd or other large data. If no region info exists, the kernel retains the old behavior and attempts to allocate the highmem region itself. Based on Hector Martin's patch Get lv1 high memory region from devtree. Apologies if this has been covered before, but why not use the device tree? cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerMac PMU programming
On Tue, 12 Jun 2012 07:24:22 +1000 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Sun, 2012-06-10 at 23:31 -0400, Justin Hibbits wrote: 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? No doco no, Darwin and Linux source code are your best bet. It works like sleep as in: you send the switch command and the PMU will reboot the processor with the new frequency whenever the processor enters NAP mode. This is tricky because there's a loss of cache coherency vs. ongoing DMAs, hence tricky bits of code in there to deal with the various caches. 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. Well that will not disable CB1 (or the external GPIO one). You need to make sure no other communication with the PMU takes place once you've sent the sleep command and until you're back. I disable interrupts on the CPU first thing right now with a kernel spin lock, and don't restore them until I'm ready to return from the speed switch, so the only communication that should be taking place is what happens in my thread -- I may be missing something here during the reset, so I'll have to go over it with a fine-toothed comb, this may be the wrong thing for me to do. 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. I don't remember what openpic does in Darwin, I think interrupts are all masked there as a side effect of the code in KeyLargo.cpp but I'm not sure that applies to frequency changes. Cheers, Ben. Thanks for all this, it's really helping me understand what needs to happen. When I get some free time I'll take a closer look at what I'm doing and try to fix it with your comments. Thanks - Justin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: pseries: Round up MSI-X requests
On Tue, 2012-06-05 at 12:47 +1000, Anton Blanchard wrote: Hi, On Mon, 2012-06-04 at 16:43 +1000, Michael Ellerman wrote: There is some chance this will result in breakage because the driver asks for N - and assumes that is what was allocated - and the device is configured for N. We can fix that. We can whack the configuration back with N, just know that we have allocated N. I think whacking config space is more likely to break something than just configuring more than the driver asked for. I agree we don't want to be giving back a larger value than requested. There's only one place that can happen in theory and since firmware only returns power of two values I dont think it will happen in practise. Don't follow you here. Even so do we want to do something like this (as yet untested)? If the rounded up request fails we retry with the original request. Yes we do. Had a chance to test it? The pseries msi free code just sets our vectors to 0 so it doesn't need to know how many were originally allocated. Yep, looks like it will cope. We only create virqs for what's in pdev-msi_list, which will be what the driver originally asked for, and we free all those by walking the list again. So the fact that firmware allocated a few extra for us is OK, we have nothing extra to cleanup. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: pseries: Round up MSI-X requests
On Wed, 2012-06-13 at 15:18 +1000, Michael Ellerman wrote: On Tue, 2012-06-05 at 12:47 +1000, Anton Blanchard wrote: Hi, On Mon, 2012-06-04 at 16:43 +1000, Michael Ellerman wrote: There is some chance this will result in breakage because the driver asks for N - and assumes that is what was allocated - and the device is configured for N. We can fix that. We can whack the configuration back with N, just know that we have allocated N. I think whacking config space is more likely to break something than just configuring more than the driver asked for. How so ? I tend to disagree here.. . I agree we don't want to be giving back a larger value than requested. There's only one place that can happen in theory and since firmware only returns power of two values I dont think it will happen in practise. Don't follow you here. Even so do we want to do something like this (as yet untested)? If the rounded up request fails we retry with the original request. Yes we do. Had a chance to test it? The pseries msi free code just sets our vectors to 0 so it doesn't need to know how many were originally allocated. Yep, looks like it will cope. We only create virqs for what's in pdev-msi_list, which will be what the driver originally asked for, and we free all those by walking the list again. So the fact that firmware allocated a few extra for us is OK, we have nothing extra to cleanup. The firmware interface is busted anyway. We want to be able to enable/allocate individual MSI-X at runtime, we need to get a new interface sorted. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
