Re: [PATCH v2] edac: mpc85xx: Add support for MPC8572
On Oct 7, 2008, at 6:10 PM, Doug Thompson wrote: the SVN repos is svn checkout https://bluesmoke.svn.sourceforge.net/svnroot/bluesmoke/trunk the info page is http://bluesmoke.sourceforge.net/ doug t SVN, ick.. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Relocatable kdump kernel support in kexec-tools
On Tue, Sep 30, 2008 at 06:26:21PM +0530, Mohan Kumar M wrote: Relocatable kdump kernel support in kexec-tools This patch adds relocatable kernel support for kdump in the kexec-tools code. A signature (0xfeed1234) is passed in r6 from panic code to the purgatory code through kexec_sequence function. The signature is used to differentiate between relocatable kdump kernel and non-kdump kernels. The purgatory code compares the signature and sets the __kdump_flag in head_64.S by using the offset with respect to next kernel load address. During the boot up, kernel code checks __kdump_flag and if it is set, the kernel will behave as relocatable kdump kernel. Thanks Mohan, applied. -- Simon Horman VA Linux Systems Japan K.K., Sydney, Australia Satellite Office H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3] MPC5121 add pci support
On Oct 7, 2008, at 2:00 PM, John Rigby wrote: The following three patches add pci support for MPC5121 These got no NACKs back in August but they were not picked up by anyone either. I'll look at picking up patches 1/3 and 3/3. I'll leave 2/3 to Grant. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3] powerpc: dma code cleanup
On Oct 7, 2008, at 4:03 PM, Remi Machet wrote: Hi, Following is the whole DMA code cleanup on top of the work already done by Becky Bruce. It includes removing __dma_sync and __dma_sync_page that got replaced by dma_mapping_ops-sync, getting rid of the old dma-noncoherent code which is now another type of dma_mapping_ops and cleaning up the dma non-coherent code by removing the virtual address pool it was using. This code was tested on a 32bits PowerPC C2K board (noncoherent cache) and I verified it builds on pmac32 (coherent cache, 32bits) and pseries (64bits). If anyone would be willing to test this code on other platforms (mainly ones with non-coherent DMA architectures), I would greatly appreciate! Your patch commit subject should be more descriptive for each patch. Have the same subject is not acceptable. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Could XUP be uesd as a SMP platform
Hi all, I am working with a Xilinx Virtex II Pro evaluation board, which has two PowerPC 405 and I have ported linux 2.6.24 onto that board when there is one PPC405 configured. I'd like to use this board as a SMP platform. Is it feasible? If it works, what steps should i follow? Could you give me some recommendations or any literatures I could refer to? Thanks a lot! ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
patches for 2.6.28
Ben, Paul Please merge or comment on the following patches for 2.6.28. They were originally posted for 2.6.27 as the merge window was opening and got lost in the shuffles. I verified they still applied to Ben's next tree on 10/5, with minor offsets. powerpc: numa.c: always trim to lmb_end_of_DRAM http://oldpatchwork.ozlabs.org/linuxppc/patch?person=79id=19577 powerpc: pseries, cell: use cpu_thread_in_core in smp_init for of_spin_map http://oldpatchwork.ozlabs.org/linuxppc/patch?person=79id=19578 powerpc: find and destroy possible stale kernel added properties http://oldpatchwork.ozlabs.org/linuxppc/patch?person=79id=19579 powerpc: add static and ifdef prom_strtoul and prom_memparse http://oldpatchwork.ozlabs.org/linuxppc/patch?person=79id=19580 thanks, milton ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ehea: Error in ehea_treat_poll_error: CQE Error for QP 16
Michael Neuling [EMAIL PROTECTED] wrote on 08.10.2008 08:24:13: Elbert, Just CCing in the ehea maintainers... Jan-Bernd, Thomas, Christoph: can you help with this query? Mikey System log shows a lot of ehea: Error, see below, during system start up. Not sure what it is. I'd like to understand this, could someone points me the direction? My Machine Type and Model ... ST9146802SS reported fromlscfg (p6 blade). OS is RHEL 5.2. Kernel level is 2.6.18-92.1.10.el5. Thanks. E. Hu Elbert, The ehea driver in RHEL 5.2 logs packets with a bad TCP checksum in the way you see in your logs. As this is obviously too noisy, the driver has meanwhile been modified not to log TCP checksum errors but just incremented the respective statistics counters. RHEL 5.3 will contain this patch. Mainline kernel contains the patch since 2.6.24. Regards Thomas ehea.modinfo filename: /lib/modules/2.6.18-92.1.10.el5/kernel/drivers/net/ehea/ehea.ko version: EHEA_0076-05 description: IBM eServer HEA Driver author: Christoph Raisch [EMAIL PROTECTED] license: GPL srcversion: C481DB79B4694F406CF4AA7 depends: vermagic: 2.6.18-92.1.10.el5 SMP mod_unload gcc-4.1 parm: num_tx_qps:Number of TX-QPS (int) parm: msg_level:msg_level (int) parm: prop_carrier_state:Propagate carrier state of physical port to stack. 1:yes, 0:no. Default = 0 (int) parm: rq3_entries:Number of entries for Receive Queue 3 [2^x - 1], x = [6..14]. Default = 1023) (int) parm: rq2_entries:Number of entries for Receive Queue 2 [2^x - 1], x = [6..14]. Default = 1023) (int) parm: rq1_entries:Number of entries for Receive Queue 1 [2^x - 1], x = [6..14]. Default = 4095) (int) parm: sq_entries: Number of entries for the Send Queue [2^x - 1], x = [6..14]. Default = 1023) (int) parm: use_mcs: 0:NAPI, 1:Multiple receive queues, Default = 0 (int) parm: lro_max_aggr: LRO: Max packets to be aggregated. Default = 64 (int) parm: use_lro: Large Receive Offload, 1: enable, 0: disable, Default= 0 (int) module_sig: 883f3504886ebc8736cb7d2578e3b1112b7ab09e3b2c69b141d16d1bbbd51ab063f7955335a49e80a0ba218c849673e067f7c0ccc9d7353cc1ce05997 system log Sep 29 09:35:35 newhamburg kernel: ehea: Error in ehea_treat_poll_error: CQE Error for QP 16 Sep 29 09:35:35 newhamburg kernel: ehea CQE adr=c001ddbc1400 ofs= 2000408e Sep 29 09:35:35 newhamburg kernel: ehea CQE adr=c001ddbc1410 ofs=0010 d6ec002a 0400 Sep 29 09:35:35 newhamburg kernel: ehea CQE adr=c001ddbc1420 ofs=0020 Sep 29 09:35:35 newhamburg kernel: ehea CQE adr=c001ddbc1430 ofs=0030 Sep 29 09:40:10 newhamburg kernel: ehea: Error in ehea_treat_poll_error: CQE Error for QP 16 Sep 29 09:40:10 newhamburg kernel: ehea CQE adr=c001dd9d2800 ofs= 2000408e Sep 29 09:40:10 newhamburg kernel: ehea CQE adr=c001dd9d2810 ofs=0010 d6ec002a 0800 Sep 29 09:40:10 newhamburg kernel: ehea CQE adr=c001dd9d2820 ofs=0020 Sep 29 09:40:10 newhamburg kernel: ehea CQE adr=c001dd9d2830 ofs=0030 Sep 29 10:08:17 newhamburg kernel: ehea: Error in ehea_treat_poll_error: CQE Error for QP 16 Sep 29 10:08:17 newhamburg kernel: ehea CQE adr=c001dd9eb600 ofs= 2000408e Sep 29 10:08:17 newhamburg kernel: ehea CQE adr=c001dd9eb610 ofs=0010 d6ec002a 0600 Sep 29 10:08:17 newhamburg kernel: ehea CQE adr=c001dd9eb620 ofs=0020 Sep 29 10:08:17 newhamburg kernel: ehea CQE adr=c001dd9eb630 ofs=0030 Sep 29 10:21:51 newhamburg kernel: ehea: Error in ehea_treat_poll_error: CQE Error for QP 16 Sep 29 10:21:51 newhamburg kernel: ehea CQE adr=c001dd9e2300 ofs= 2000408e Sep 29 10:21:51 newhamburg kernel: ehea CQE adr=c001dd9e2310 ofs=0010 d6ec002a 0300 Sep 29 10:21:51 newhamburg kernel: ehea CQE adr=c001dd9e2320 ofs=0020 Sep 29 10:21:51 newhamburg kernel: ehea CQE adr=c001dd9e2330 ofs=0030 Sep 29 16:16:23 newhamburg kernel: ehea: Error in ehea_treat_poll_error: CQE Error for QP 16 Sep 29 16:16:23 newhamburg kernel: ehea CQE adr=c001ddb9a800 ofs= 03000263 408040e0 Sep 29 16:16:23 newhamburg kernel: ehea CQE adr=c001ddb9a810 ofs=0010 e10f002a 0800 Sep 29 16:16:23 newhamburg kernel: ehea CQE adr=c001ddb9a820 ofs=0020 Sep 29 16:16:23 newhamburg kernel: ehea CQE adr=c001ddb9a830 ofs=0030 Sep 29 21:50:04 newhamburg kernel: ehea: Error in ehea_treat_poll_error: CQE Error for QP 16 Sep 29 21:50:04
Re: [PATCH] pata_of_platform: fix no irq handling
On Tue, 2008-10-07 at 10:37 +0100, Alan Cox wrote: Zero means no IRQ. Any platform with bits of code left over exposing IRQ 0 is already not supported by lots of driver code including libata. ...and must implement some kind of interrupt remapping crap just to work around this bogus design decision. -- David WoodhouseOpen Source Technology Centre [EMAIL PROTECTED] Intel Corporation ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pata_of_platform: fix no irq handling
On Wed, 8 Oct 2008, Alan Cox wrote: On Wed, 08 Oct 2008 09:40:54 +0100 David Woodhouse [EMAIL PROTECTED] wrote: On Tue, 2008-10-07 at 10:37 +0100, Alan Cox wrote: Zero means no IRQ. Any platform with bits of code left over exposing IRQ 0 is already not supported by lots of driver code including libata. ...and must implement some kind of interrupt remapping crap just to work around this bogus design decision. I'll leave you to argue with Linus about that, but since that was the decision back in 2005 (for good C reasons) we can safely rely on it. `git grep NO_IRQ include arch/*/include' is still quite enlightening... With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pata_of_platform: fix no irq handling
I'll leave you to argue with Linus about that, but since that was the decision back in 2005 (for good C reasons) we can safely rely on it. `git grep NO_IRQ include arch/*/include' is still quite enlightening... Good guide to platform code we should delete really ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc.git status
On Oct 8, 2008, at 4:29 AM, Benjamin Herrenschmidt wrote: Its useful to not rebase a branch you expect people to send you patches against and sub-maintainers are using to build tree's against. It sounds like 'next' is that branch. Indeed. Though so far I've managed to avoid rebasing anything :-) So what's the status of the patches moving from master into next? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc: pci: 5121: Hide pci bridge.
On Oct 7, 2008, at 2:00 PM, John Rigby wrote: The class of the MPC5121 pci host bridge is PCI_CLASS_BRIDGE_OTHER while other freescale host bridges have class set to PCI_CLASS_PROCESSOR_POWERPC. This patch makes fixup_hide_host_resource_fsl match PCI_CLASS_BRIDGE_OTHER in addition to PCI_CLASS_PROCESSOR_POWERPC. Signed-off-by: John Rigby [EMAIL PROTECTED] --- arch/powerpc/kernel/pci_32.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) applied - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc: 83xx: pci: Remove need for get_immrbase from mpc83xx_add_bridge.
On Oct 7, 2008, at 2:00 PM, John Rigby wrote: Modify mpc83xx_add_bridge to get config space register base address from the device tree instead of immr + hardcoded offset. 83xx pci nodes have this change: register properties now contain two address length tuples: First is the pci bridge register base, this has always been there. Second is the config base, this is new. This is documented in Documentation/powerpc/dts-bindings/fsl/ 83xx-512x-pci.txt The changes accomplish these things: mpc83xx_add_bridge no longer needs to call get_immrbase it uses hard coded addresses if the second register value is missing Signed-off-by: John Rigby [EMAIL PROTECTED] --- .../powerpc/dts-bindings/fsl/83xx-512x-pci.txt | 40 +++ +++ arch/powerpc/boot/dts/mpc8313erdb.dts |3 +- arch/powerpc/boot/dts/mpc8315erdb.dts |3 +- arch/powerpc/boot/dts/mpc832x_mds.dts |3 +- arch/powerpc/boot/dts/mpc832x_rdb.dts |3 +- arch/powerpc/boot/dts/mpc8349emitx.dts |6 ++- arch/powerpc/boot/dts/mpc8349emitxgp.dts |3 +- arch/powerpc/boot/dts/mpc834x_mds.dts |6 ++- arch/powerpc/boot/dts/mpc836x_mds.dts |3 +- arch/powerpc/boot/dts/mpc836x_rdk.dts |3 +- arch/powerpc/boot/dts/mpc8377_mds.dts |3 +- arch/powerpc/boot/dts/mpc8377_rdb.dts |3 +- arch/powerpc/boot/dts/mpc8378_mds.dts |3 +- arch/powerpc/boot/dts/mpc8378_rdb.dts |3 +- arch/powerpc/boot/dts/mpc8379_mds.dts |3 +- arch/powerpc/boot/dts/mpc8379_rdb.dts |3 +- arch/powerpc/boot/dts/sbc8349.dts |3 +- arch/powerpc/sysdev/fsl_pci.c | 54 +++ ++--- 18 files changed, 111 insertions(+), 37 deletions(-) create mode 100644 Documentation/powerpc/dts-bindings/fsl/83xx-512x- pci.txt applied - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] edac: mpc85xx: Add support for new compatible types, mpc8536 and mpc8560
All other compatibles that are uniquely identifying the processor use
a prefix of the form fsl,mpc85...'. We add support for it so we
can deprecate the older 'fsl,85...' that was inproperly used here.
Additionally added mpc8536 mpc8560 to the compatible lists.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
This patch is based on Nate's 8572 patch.
drivers/edac/mpc85xx_edac.c | 74 ++
1 files changed, 32 insertions(+), 42 deletions(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index 63bdc47..184799a 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -630,27 +630,22 @@ static int mpc85xx_l2_err_remove(struct of_device *op)
}
static struct of_device_id mpc85xx_l2_err_of_match[] = {
- {
-.compatible = fsl,8540-l2-cache-controller,
-},
- {
-.compatible = fsl,8541-l2-cache-controller,
-},
- {
-.compatible = fsl,8544-l2-cache-controller,
-},
- {
-.compatible = fsl,8548-l2-cache-controller,
-},
- {
-.compatible = fsl,8555-l2-cache-controller,
-},
- {
-.compatible = fsl,8568-l2-cache-controller,
-},
- {
-.compatible = fsl,mpc8572-l2-cache-controller,
-},
+/* deprecate the fsl,85.. forms in the future, 2.6.30? */
+ { .compatible = fsl,8540-l2-cache-controller, },
+ { .compatible = fsl,8541-l2-cache-controller, },
+ { .compatible = fsl,8544-l2-cache-controller, },
+ { .compatible = fsl,8548-l2-cache-controller, },
+ { .compatible = fsl,8555-l2-cache-controller, },
+ { .compatible = fsl,8568-l2-cache-controller, },
+ { .compatible = fsl,mpc8536-l2-cache-controller, },
+ { .compatible = fsl,mpc8540-l2-cache-controller, },
+ { .compatible = fsl,mpc8541-l2-cache-controller, },
+ { .compatible = fsl,mpc8544-l2-cache-controller, },
+ { .compatible = fsl,mpc8548-l2-cache-controller, },
+ { .compatible = fsl,mpc8555-l2-cache-controller, },
+ { .compatible = fsl,mpc8560-l2-cache-controller, },
+ { .compatible = fsl,mpc8568-l2-cache-controller, },
+ { .compatible = fsl,mpc8572-l2-cache-controller, },
{},
};
@@ -967,27 +962,22 @@ static int mpc85xx_mc_err_remove(struct of_device *op)
}
static struct of_device_id mpc85xx_mc_err_of_match[] = {
- {
-.compatible = fsl,8540-memory-controller,
-},
- {
-.compatible = fsl,8541-memory-controller,
-},
- {
-.compatible = fsl,8544-memory-controller,
-},
- {
-.compatible = fsl,8548-memory-controller,
-},
- {
-.compatible = fsl,8555-memory-controller,
-},
- {
-.compatible = fsl,8568-memory-controller,
-},
- {
-.compatible = fsl,mpc8572-memory-controller,
-},
+/* deprecate the fsl,85.. forms in the future, 2.6.30? */
+ { .compatible = fsl,8540-memory-controller, },
+ { .compatible = fsl,8541-memory-controller, },
+ { .compatible = fsl,8544-memory-controller, },
+ { .compatible = fsl,8548-memory-controller, },
+ { .compatible = fsl,8555-memory-controller, },
+ { .compatible = fsl,8568-memory-controller, },
+ { .compatible = fsl,mpc8536-memory-controller, },
+ { .compatible = fsl,mpc8540-memory-controller, },
+ { .compatible = fsl,mpc8541-memory-controller, },
+ { .compatible = fsl,mpc8544-memory-controller, },
+ { .compatible = fsl,mpc8548-memory-controller, },
+ { .compatible = fsl,mpc8555-memory-controller, },
+ { .compatible = fsl,mpc8560-memory-controller, },
+ { .compatible = fsl,mpc8568-memory-controller, },
+ { .compatible = fsl,mpc8572-memory-controller, },
{},
};
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Could XUP be uesd as a SMP platform
On Wed, Oct 08, 2008 at 02:49:14PM +0800, =?GB2312?B?ItXF6fMiIDx6aGFuZ3lpaGVyZUBnbWFpbC5jb20+?= wrote: Hi all, I am working with a Xilinx Virtex II Pro evaluation board, which has two PowerPC 405 and I have ported linux 2.6.24 onto that board when there is one PPC405 configured. I'd like to use this board as a SMP platform. Is it feasible? No. The 405 cores are not designed with SMP in mind and it will not work. If the board has discrete memory for each CPU, you might be able to run it in an AMP fashion. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] powerpc: 5121: Add PCI support.
On Oct 7, 2008, at 4:13 PM, John Rigby wrote: Uses mpc83xx_add_bridge in fsl_pci.c Adds second register tuple to pci node register property as done for 83xx device trees in a previous patch. Signed-off-by: John Rigby [EMAIL PROTECTED] --- arch/powerpc/boot/dts/mpc5121ads.dts |3 ++- arch/powerpc/platforms/512x/Kconfig |2 ++ arch/powerpc/platforms/512x/mpc5121_ads.c | 10 ++ arch/powerpc/sysdev/fsl_pci.c |4 ++-- 4 files changed, 16 insertions(+), 3 deletions(-) Acked-by: Kumar Gala [EMAIL PROTECTED] - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc.git status
Its useful to not rebase a branch you expect people to send you patches against and sub-maintainers are using to build tree's against. It sounds like 'next' is that branch. Indeed. Though so far I've managed to avoid rebasing anything :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8315ERDB PCI Express support status?
Kumar, John, On Mon, Oct 6, 2008 at 5:09 PM, Kumar Gala [EMAIL PROTECTED] wrote: On Oct 6, 2008, at 8:42 AM, Leon Woestenberg wrote: can Freescale or any of the powerpc maintainers indicate to what extend PCI Express support for the MPC8315E processor has been merged to Linux mainline, or what is still needs review or attention? I could find u-boot and Linux patches provided by Freescale in their [...] but I could not easily identify what has been merged upstream. My first goal (and hardware on my desk) would be to test an Intel PCIe PRO/1000 Ethernet adapter, as a start to add a custom PCIe FPGA device. No PCI-e support for 83xx has been merged in any mainline kernel. I got MPC8315E working with PCI Express, using an Intel PRO/1000 GbE PCIe x1 card, using 2.6.24.3-rt3 with a lot of Freescale patches, as well as u-boot 1.2.0 forward patched to 1.3.0 by Freescale with some PCIe initialization work. So, basically the BSP 20080627. I would like these patches to be ported forward to mainline, and I can put some time in this, but I'ld rather first know what the Freescale status on the patches is? John, Stuart, could you please check if there is ongoing work in Freescale? I hate double efforts when I'm short on time :-) Thanks. Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Could XUP be uesd as a SMP platform
No, the PowerPC 405s can’t be used as a SMP platform. The 405 caches are not designed with cache coherency for SMP. Thanks, John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ?? Sent: Wednesday, October 08, 2008 12:49 AM To: linuxppc-dev@ozlabs.org Subject: Could XUP be uesd as a SMP platform Hi all, I am working with a Xilinx Virtex II Pro evaluation board, which has two PowerPC 405 and I have ported linux 2.6.24 onto that board when there is one PPC405 configured. I'd like to use this board as a SMP platform. Is it feasible? If it works, what steps should i follow? Could you give me some recommendations or any literatures I could refer to? Thanks a lot! This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8315ERDB PCI Express support status?
On Oct 8, 2008, at 8:53 AM, Leon Woestenberg wrote: I would like these patches to be ported forward to mainline, and I can put some time in this, but I'ld rather first know what the Freescale status on the patches is? John, Stuart, could you please check if there is ongoing work in Freescale? I hate double efforts when I'm short on time :-) Thanks. Leon (I also work @ FSL) and we don't have any work going on right now to cleanup the PCIe patches. The reason they aren't in the kernel is the mechanism used to do PCIe config cycles is not acceptable for kernel.org. The issue is that the code ioremaps a huge address space (128M if I remember). The code should look at doing a sliding window and only use 4k of address space. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] of-bindings: Don't support linux, modalias compatible values
From: Grant Likely [EMAIL PROTECTED]
Compatible property values in the form linux,modalias is not documented
anywhere and using it leaks Linux implementation details into the device
tree data (which is bad). Remove support for compatible values of this
form.
If any platforms exist which depended on this code (and I don't know of
any), then they can be fixed up by adding legacy translations to the
lookup table in this file.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
drivers/of/base.c | 25 +
1 files changed, 5 insertions(+), 20 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index ad8ac1a..cd1ce7a 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -420,13 +420,12 @@ static struct of_modalias_table of_modalias_table[] = {
* @len: Length of modalias value
*
* Based on the value of the compatible property, this routine will determine
- * an appropriate modalias value for a particular device tree node. Three
- * separate methods are used to derive a modalias value.
+ * an appropriate modalias value for a particular device tree node. Two
+ * separate methods are attempted to derive a modalias value.
*
* First method is to lookup the compatible value in of_modalias_table.
- * Second is to look for a linux,modalias entry in the compatible list
- * and used that for modalias. Third is to strip off the manufacturer
- * prefix from the first compatible entry and use the remainder as modalias
+ * Second is to strip off the manufacturer prefix from the first
+ * compatible entry and use the remainder as modalias
*
* This routine returns 0 on success
*/
@@ -449,21 +448,7 @@ int of_modalias_node(struct device_node *node, char
*modalias, int len)
if (!compatible)
return -ENODEV;
- /* 2. search for linux,modalias entry */
- p = compatible;
- while (cplen 0) {
- if (!strncmp(p, linux,, 6)) {
- p += 6;
- strlcpy(modalias, p, len);
- return 0;
- }
-
- i = strlen(p) + 1;
- p += i;
- cplen -= i;
- }
-
- /* 3. take first compatible entry and strip manufacturer */
+ /* 2. take first compatible entry and strip manufacturer */
p = strchr(compatible, ',');
if (!p)
return -ENODEV;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3] MPC5121 add pci support
If this patchset is okay with everyone, is it possible that it could be rushed into 2.6.27 before it hits rc10 or release? :/ -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations John Rigby wrote: The following three patches add pci support for MPC5121 These got no NACKs back in August but they were not picked up by anyone either. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3] MPC5121 add pci support
On Wed, Oct 8, 2008 at 9:29 AM, Matt Sealey [EMAIL PROTECTED] wrote: If this patchset is okay with everyone, is it possible that it could be rushed into 2.6.27 before it hits rc10 or release? :/ no -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: performance: memcpy vs. __copy_tofrom_user
Forwarding message to [EMAIL PROTECTED] This is an interesting
question for the wider powerpc community, but not many people read
linuxppc-embedded.
On Wed, Oct 08, 2008 at 04:39:13PM +0200, Dominik Bozek wrote:
Hi all,
I have done a test of memcpy() and __copy_tofrom_user() on the mpc8313.
And the major conclusion is that __copy_tofrom_user is more efficient
than memcpy. Sometimes about 40%.
If I good understand, the memcpy() just copy the data, while
__copy_tofrom_user() take care if the memory wasn't swapped out. So then
memcpy() shall be faster than __copy_tofrom_user(). Am I right?
Is here anybody, who can confirm such results and maybe is able to
improve the memcpy()?
Let talk about the test.
I have prepared two pieces of memory of size 64KB and I make sure that
this memory is not swapped out (necessary for memcpy() later). Then I
run one of the memory copy function to transfer 32MB and I measure the
time. The memory is copied in chunks from 64KB to 8B. I take care about
the cache calling flush_dcache_range() whenever whole 64KB was used.
I know, that memcpy on the kernel level is not intended to copy memory
blocks in userspace and __copy_tofrom_user is not intended to copy data
only between two user blocks, but for the performance test it doesn't
matter.
Bellow you may see the short piece of code in the kernel module.
#define TEST_BUF_SIZE (64*1024)
int function;
char *buf1, *buf2, *buf1_bis, *buf2_bis;
unsigned int size, cnt;
get_user(function, ((TEST_ARG*)(arg))-function);
get_user(buf1, ((TEST_ARG*)(arg))-buf1);
get_user(buf2, ((TEST_ARG*)(arg))-buf2);
get_user(size, ((TEST_ARG*)(arg))-size);
cnt = (32*1024*1024)/size; /* how many repeats of memory copy is needed
to transfer 32MB ? */
buf1_bis = buf1;
buf2_bis = buf2;
switch (function)
{
case MEMCPY_TEST:
while (cnt--0)
{
if (buf1_bis = buf1+TEST_BUF_SIZE)
{
/* need for flusch data cache as seldom as possible */
buf1_bis = buf1;
buf2_bis = buf2;
flush_dcache_range((int)buf1, (int)(buf2+TEST_BUF_SIZE));
}
if (buf1_bis != memcpy(buf1_bis, buf2_bis, size))
break;
buf1_bis += size;
buf2_bis += size;
}
break;
case COPY_TOFROM_USER_TEST:
while (cnt--0)
{
if (buf1_bis = buf1+TEST_BUF_SIZE)
{
/* need for flusch data cache as seldom as possible */
buf1_bis = buf1;
buf2_bis = buf2;
flush_dcache_range((int)buf1, (int)(buf2+TEST_BUF_SIZE));
}
ret = __copy_tofrom_user(buf1_bis, buf2_bis, size);
if (ret != 0)
break;
buf1_bis += size;
buf2_bis += size;
}
break;
}
Bellow are the results:
memcpy()
chunk: 65536 [B] | transfer: 69.2 [MB/s] | time: 1.849727 [s] |
size: 128.000 [MB]
chunk: 32768 [B] | transfer: 69.2 [MB/s] | time: 1.849700 [s] |
size: 128.000 [MB]
chunk: 16384 [B] | transfer: 69.2 [MB/s] | time: 1.849845 [s] |
size: 128.000 [MB]
chunk: 8192 [B] | transfer: 69.2 [MB/s] | time: 1.850535 [s] |
size: 128.000 [MB]
chunk: 4096 [B] | transfer: 69.1 [MB/s] | time: 1.853405 [s] |
size: 128.000 [MB]
chunk: 2048 [B] | transfer: 69.1 [MB/s] | time: 1.852877 [s] |
size: 128.000 [MB]
chunk: 1024 [B] | transfer: 69.2 [MB/s] | time: 1.849963 [s] |
size: 128.000 [MB]
chunk:512 [B] | transfer: 69.0 [MB/s] | time: 1.853793 [s] |
size: 128.000 [MB]
chunk:256 [B] | transfer: 68.6 [MB/s] | time: 1.866222 [s] |
size: 128.000 [MB]
chunk:128 [B] | transfer: 68.0 [MB/s] | time: 1.883002 [s] |
size: 128.000 [MB]
chunk: 64 [B] | transfer: 67.2 [MB/s] | time: 1.904073 [s] |
size: 128.000 [MB]
chunk: 32 [B] | transfer: 64.7 [MB/s] | time: 1.978109 [s] |
size: 128.000 [MB]
chunk: 16 [B] | transfer: 54.5 [MB/s] | time: 2.348682 [s] |
size: 128.000 [MB]
chunk: 8 [B] | transfer: 47.4 [MB/s] | time: 2.698635 [s] |
size: 128.000 [MB]
__copy_tofrom_user()
chunk: 65536 [B] | transfer: 97.3 [MB/s] | time: 1.315155 [s] |
size: 128.000 [MB]
chunk: 32768 [B] | transfer: 97.3 [MB/s] | time: 1.315762 [s] |
size: 128.000 [MB]
chunk: 16384 [B] | transfer: 97.2 [MB/s] | time: 1.316946 [s] |
size: 128.000 [MB]
chunk: 8192 [B] | transfer: 96.8 [MB/s] | time: 1.321705 [s] |
size: 128.000 [MB]
chunk: 4096 [B] | transfer: 96.6 [MB/s] | time: 1.325516 [s] |
size: 128.000 [MB]
chunk: 2048 [B] | transfer: 96.6 [MB/s] | time: 1.325570 [s] |
size: 128.000 [MB]
chunk: 1024 [B] | transfer: 96.8 [MB/s] | time: 1.322599 [s] |
size: 128.000 [MB]
chunk:512 [B] | transfer: 97.8 [MB/s] | time: 1.308186 [s] |
size: 128.000 [MB]
Re: [PATCH 0/3] MPC5121 add pci support
On Wed, Oct 8, 2008 at 12:20 AM, Kumar Gala [EMAIL PROTECTED] wrote: On Oct 7, 2008, at 2:00 PM, John Rigby wrote: The following three patches add pci support for MPC5121 These got no NACKs back in August but they were not picked up by anyone either. I'll look at picking up patches 1/3 and 3/3. I'll leave 2/3 to Grant. Kumar, since both 1/3 and 2/3 touch fsl_pci.c, can you please pick up 2/3? It won't conflict with anything that I'm pushing. I'll post my ack-by line. g. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] powerpc: 5121: Add PCI support.
On Wed, Oct 8, 2008 at 6:38 AM, Kumar Gala [EMAIL PROTECTED] wrote: On Oct 7, 2008, at 4:13 PM, John Rigby wrote: Uses mpc83xx_add_bridge in fsl_pci.c Adds second register tuple to pci node register property as done for 83xx device trees in a previous patch. Signed-off-by: John Rigby [EMAIL PROTECTED] --- arch/powerpc/boot/dts/mpc5121ads.dts |3 ++- arch/powerpc/platforms/512x/Kconfig |2 ++ arch/powerpc/platforms/512x/mpc5121_ads.c | 10 ++ arch/powerpc/sysdev/fsl_pci.c |4 ++-- 4 files changed, 16 insertions(+), 3 deletions(-) Acked-by: Kumar Gala [EMAIL PROTECTED] Acked-by: Grant Likely [EMAIL PROTECTED] -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] edac: mpc85xx: Add support for new compatible types, mpc8536 and mpc8560
Acked-by: Dave Jiang [EMAIL PROTECTED]
Kumar Gala wrote:
All other compatibles that are uniquely identifying the processor use
a prefix of the form fsl,mpc85...'. We add support for it so we
can deprecate the older 'fsl,85...' that was inproperly used here.
Additionally added mpc8536 mpc8560 to the compatible lists.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
This patch is based on Nate's 8572 patch.
drivers/edac/mpc85xx_edac.c | 74 ++
1 files changed, 32 insertions(+), 42 deletions(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index 63bdc47..184799a 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -630,27 +630,22 @@ static int mpc85xx_l2_err_remove(struct of_device *op)
}
static struct of_device_id mpc85xx_l2_err_of_match[] = {
- {
-.compatible = fsl,8540-l2-cache-controller,
-},
- {
-.compatible = fsl,8541-l2-cache-controller,
-},
- {
-.compatible = fsl,8544-l2-cache-controller,
-},
- {
-.compatible = fsl,8548-l2-cache-controller,
-},
- {
-.compatible = fsl,8555-l2-cache-controller,
-},
- {
-.compatible = fsl,8568-l2-cache-controller,
-},
- {
-.compatible = fsl,mpc8572-l2-cache-controller,
-},
+/* deprecate the fsl,85.. forms in the future, 2.6.30? */
+ { .compatible = fsl,8540-l2-cache-controller, },
+ { .compatible = fsl,8541-l2-cache-controller, },
+ { .compatible = fsl,8544-l2-cache-controller, },
+ { .compatible = fsl,8548-l2-cache-controller, },
+ { .compatible = fsl,8555-l2-cache-controller, },
+ { .compatible = fsl,8568-l2-cache-controller, },
+ { .compatible = fsl,mpc8536-l2-cache-controller, },
+ { .compatible = fsl,mpc8540-l2-cache-controller, },
+ { .compatible = fsl,mpc8541-l2-cache-controller, },
+ { .compatible = fsl,mpc8544-l2-cache-controller, },
+ { .compatible = fsl,mpc8548-l2-cache-controller, },
+ { .compatible = fsl,mpc8555-l2-cache-controller, },
+ { .compatible = fsl,mpc8560-l2-cache-controller, },
+ { .compatible = fsl,mpc8568-l2-cache-controller, },
+ { .compatible = fsl,mpc8572-l2-cache-controller, },
{},
};
@@ -967,27 +962,22 @@ static int mpc85xx_mc_err_remove(struct of_device *op)
}
static struct of_device_id mpc85xx_mc_err_of_match[] = {
- {
-.compatible = fsl,8540-memory-controller,
-},
- {
-.compatible = fsl,8541-memory-controller,
-},
- {
-.compatible = fsl,8544-memory-controller,
-},
- {
-.compatible = fsl,8548-memory-controller,
-},
- {
-.compatible = fsl,8555-memory-controller,
-},
- {
-.compatible = fsl,8568-memory-controller,
-},
- {
-.compatible = fsl,mpc8572-memory-controller,
-},
+/* deprecate the fsl,85.. forms in the future, 2.6.30? */
+ { .compatible = fsl,8540-memory-controller, },
+ { .compatible = fsl,8541-memory-controller, },
+ { .compatible = fsl,8544-memory-controller, },
+ { .compatible = fsl,8548-memory-controller, },
+ { .compatible = fsl,8555-memory-controller, },
+ { .compatible = fsl,8568-memory-controller, },
+ { .compatible = fsl,mpc8536-memory-controller, },
+ { .compatible = fsl,mpc8540-memory-controller, },
+ { .compatible = fsl,mpc8541-memory-controller, },
+ { .compatible = fsl,mpc8544-memory-controller, },
+ { .compatible = fsl,mpc8548-memory-controller, },
+ { .compatible = fsl,mpc8555-memory-controller, },
+ { .compatible = fsl,mpc8560-memory-controller, },
+ { .compatible = fsl,mpc8568-memory-controller, },
+ { .compatible = fsl,mpc8572-memory-controller, },
{},
};
--
--
Dave Jiang
Software Engineer
MontaVista Software, Inc.
http://www.mvista.com
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC 0/6] Proposal for a Generic PWM Device API
This series proposes a generic PWM driver API. This proposed API is motivated by the author's need to support pluggable devices; a secondary objective is to consolidate the existing PWM implementations behind an agreeable, consistent, redundancy-reducing interface. The code included in this patch draws heavily from the existing PWM infrastructure and driver for the AT91SAM9263 PWMC. The author is grateful to Russell King, Eric Miao, David Brownell and others for providing such tall shoulders to stand upon. The proposed updates to that code should not be interpreted as attempts to address shortcomings, but rather to extend functionality in ways that were not originally required. The implementation of the proposed API is structurally similar to the generic GPIO API, except that the PWM code uses platform bus_id strings instead of integers to identify devices. A configuration structure is also provided, so that the API can be extended in a source-code-compatible way to accomodate devices with features not anticipated by the current code. Pulse width modulated signals are used in an astounding number and range of applications, and there is no one true way of either realizing them or employing them to accomplish real work. The current proposal attempts to provide a useful feature set for the most basic users, packaged in such a way as to allow the API to be extended in a backwards-compatible way as new needs are identified. Some of these needs have already been identified. The proposed code has been run-tested on a Cogent CSB737 (AT91SAM9263), mated to a custom circuit that drives multiple DC motors and sensors. Feedback is welcome! b.g. -- Bill Gatliff [EMAIL PROTECTED] == Bill Gatliff (6): [PWM] Generic PWM API implementation [PWM] Changes to existing pwm.h to adapt to generic PWM API [PWM] Documentation [PWM] Driver for Atmel PWMC peripheral [PWM] Install new Atmel PWMC driver in Kconfig, expunge old one [PWM] New LED driver and trigger that use PWM API Documentation/pwm.txt | 258 + arch/arm/Kconfig |2 + drivers/Makefile |2 + drivers/leds/Kconfig | 21 +- drivers/leds/Makefile |2 + drivers/leds/leds-pwm.c| 141 ++ drivers/leds/ledtrig-dim.c | 95 +++ drivers/misc/Kconfig |9 - drivers/misc/Makefile |1 - drivers/misc/atmel_pwm.c | 409 --- drivers/pwm/Kconfig| 24 ++ drivers/pwm/Makefile |6 + drivers/pwm/atmel-pwm.c| 631 + drivers/pwm/pwm.c | 667 include/linux/pwm-led.h| 34 +++ include/linux/pwm.h| 168 ++-- 16 files changed, 2023 insertions(+), 447 deletions(-) create mode 100644 Documentation/pwm.txt create mode 100644 drivers/leds/leds-pwm.c create mode 100644 drivers/leds/ledtrig-dim.c delete mode 100644 drivers/misc/atmel_pwm.c create mode 100644 drivers/pwm/Kconfig create mode 100644 drivers/pwm/Makefile create mode 100644 drivers/pwm/atmel-pwm.c create mode 100644 drivers/pwm/pwm.c create mode 100644 include/linux/pwm-led.h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC 6/6] [PWM] New LED driver and trigger that use PWM API
Signed-off-by: Bill Gatliff [EMAIL PROTECTED]
---
drivers/leds/Kconfig | 21 --
drivers/leds/Makefile |2 +
drivers/leds/leds-pwm.c| 141
drivers/leds/ledtrig-dim.c | 95 +
include/linux/pwm-led.h| 34 +++
5 files changed, 286 insertions(+), 7 deletions(-)
create mode 100644 drivers/leds/leds-pwm.c
create mode 100644 drivers/leds/ledtrig-dim.c
create mode 100644 include/linux/pwm-led.h
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 9556262..019c2e8 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -17,13 +17,6 @@ config LEDS_CLASS
comment LED drivers
-config LEDS_ATMEL_PWM
- tristate LED Support using Atmel PWM outputs
- depends on LEDS_CLASS ATMEL_PWM
- help
- This option enables support for LEDs driven using outputs
- of the dedicated PWM controller found on newer Atmel SOCs.
-
config LEDS_CORGI
tristate LED Support for the Sharp SL-C7x0 series
depends on LEDS_CLASS PXA_SHARP_C7xx
@@ -119,6 +112,12 @@ config LEDS_GPIO
outputs. To be useful the particular board must have LEDs
and they must be connected to the GPIO lines.
+config LEDS_PWM
+ tristate LED Support for PWM connected LEDs
+ depends on LEDS_CLASS GENERIC_PWM
+ help
+ Enables support for LEDs connected to PWM outputs.
+
config LEDS_CM_X270
tristate LED Support for the CM-X270 LEDs
depends on LEDS_CLASS MACH_ARMCORE
@@ -190,6 +189,14 @@ config LEDS_TRIGGER_IDE_DISK
This allows LEDs to be controlled by IDE disk activity.
If unsure, say Y.
+config LEDS_TRIGGER_DIM
+ tristate LED Dimmer Trigger
+ depends on LEDS_TRIGGERS
+ help
+ Regulates the brightness of an LED based on the 1-minute CPU
+ load average. Ideal for PWM-driven LEDs.
+ If unsure, say Y.
+
config LEDS_TRIGGER_HEARTBEAT
tristate LED Heartbeat Trigger
depends on LEDS_TRIGGERS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index ff7982b..1031086 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_LEDS_COBALT_QUBE)+=
leds-cobalt-qube.o
obj-$(CONFIG_LEDS_COBALT_RAQ) += leds-cobalt-raq.o
obj-$(CONFIG_LEDS_PCA9532) += leds-pca9532.o
obj-$(CONFIG_LEDS_GPIO)+= leds-gpio.o
+obj-$(CONFIG_LEDS_PWM) += leds-pwm.o
obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
obj-$(CONFIG_LEDS_CLEVO_MAIL) += leds-clevo-mail.o
obj-$(CONFIG_LEDS_HP6XX) += leds-hp6xx.o
@@ -27,5 +28,6 @@ obj-$(CONFIG_LEDS_PCA955X)+= leds-pca955x.o
# LED Triggers
obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o
obj-$(CONFIG_LEDS_TRIGGER_IDE_DISK)+= ledtrig-ide-disk.o
+obj-$(CONFIG_LEDS_TRIGGER_DIM) += ledtrig-dim.o
obj-$(CONFIG_LEDS_TRIGGER_HEARTBEAT) += ledtrig-heartbeat.o
obj-$(CONFIG_LEDS_TRIGGER_DEFAULT_ON) += ledtrig-default-on.o
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
new file mode 100644
index 000..3bd9afb
--- /dev/null
+++ b/drivers/leds/leds-pwm.c
@@ -0,0 +1,141 @@
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/leds.h
+#include linux/io.h
+#include linux/pwm.h
+#include linux/pwm-led.h
+
+
+struct led_pwm {
+ struct led_classdev led;
+ struct pwm_channel *pwm;
+ int percent;
+};
+
+
+static void
+led_pwm_brightness_set(struct led_classdev *c,
+ enum led_brightness b)
+{
+ struct led_pwm *led;
+ int percent;
+
+ percent = (b * 100) / (LED_FULL - LED_OFF);
+ led = container_of(c, struct led_pwm, led);
+ led-percent = percent;
+ pwm_duty_percent(led-pwm, percent);
+}
+
+
+static enum led_brightness
+led_pwm_brightness_get(struct led_classdev *c)
+{
+ struct led_pwm *led;
+ led = container_of(c, struct led_pwm, led);
+ return led-percent;
+}
+
+
+static int __init
+led_pwm_probe(struct platform_device *pdev)
+{
+ struct pwm_led_platform_data *pdata = pdev-dev.platform_data;
+ struct led_pwm *led;
+ struct device *d = pdev-dev;
+ int ret;
+
+ if (!pdata || !pdata-led_info)
+ return -EINVAL;
+
+ if (!try_module_get(d-driver-owner))
+ return -ENODEV;
+
+ led = kzalloc(sizeof(*led), GFP_KERNEL);
+ if (!led)
+ return -ENOMEM;
+
+ led-pwm = pwm_request(pdata-bus_id, pdata-chan,
+ pdata-led_info-name);
+ if (!led-pwm) {
+ ret = -EINVAL;
+ goto err_pwm_request;
+ }
+
+ platform_set_drvdata(pdev, led);
+
+ led-led.name = pdata-led_info-name;
+ led-led.default_trigger = pdata-led_info-default_trigger;
+ led-led.brightness_set
[RFC 3/6] [PWM] Documentation
Signed-off-by: Bill Gatliff [EMAIL PROTECTED] --- Documentation/pwm.txt | 258 + 1 files changed, 258 insertions(+), 0 deletions(-) create mode 100644 Documentation/pwm.txt diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt new file mode 100644 index 000..b8932dd --- /dev/null +++ b/Documentation/pwm.txt @@ -0,0 +1,258 @@ + Generic PWM Device API + + October 8, 2008 + Bill Gatliff + [EMAIL PROTECTED] + + + +The code in drivers/pwm and include/linux/pwm.h implements an API for +applications involving pulse-width-modulation signals. This document +describes how the API implementation facilitates both PWM-generating +devices, and users of those devices. + + + +Motivation + +The primary goals for implementing the generic PWM API are to +consolidate the various PWM implementations within a consistent and +redundancy-reducing framework, and to facilitate the use of +hotpluggable PWM devices. + +Previous PWM-related implementations within the Linux kernel achieved +their consistency via cut-and-paste, but did not need to (and didn't) +facilitate more than one PWM-generating device within the system--- +hotplug or otherwise. The Generic PWM Device API might be most +appropriately viewed as an update to those implementations, rather +than a complete rewrite. + + + +Challenges + +One of the difficulties in implementing a generic PWM framework is the +fact that pulse-width-modulation applications involve real-world +signals, which often must be carefully managed to prevent destruction +of hardware that is linked to those signals. A DC motor that +experiences a brief interruption in the PWM signal controlling it +might destructively overheat; it could change speed, losing +synchronization with a sensor; it could even suddenly change direction +or torque, breaking the mechanical device connected to it. + +(A generic PWM device framework is not directly responsible for +preventing the above scenarios: that responsibility lies with the +hardware designer and the application and driver authors. But it must +to the greatest extent possible make it easy to avoid such problems). + +A generic PWM device framework must accomodate the substantial +differences between available PWM-generating hardware devices, without +becoming sub-optimal for any of them. + +Finally, a generic PWM device framework must be relatively +lightweight, computationally speaking. Some PWM users demand +high-speed outputs, plus the ability to regulate those outputs +quickly. A device framework must be able to keep up with such +hardware, while still leaving time to do real work. + +The Generic PWM Device API is an attempt to meet all of the above +requirements. At its initial publication, the API was already in use +managing small DC motors through a custom-designed, optically-isolated +H-bridge driver. + + + +Functional Overview + +The Generic PWM Device API framework is implemented in +include/linux/pwm.h and drivers/pwm/pwm.c. The functions therein use +information from pwm_device, pwm_channel and pwm_channel_config +structures to invoke services in PWM peripheral device drivers. +Consult drivers/pwm/atmel-pwm.c for an example driver. + +There are two classes of adopters of the PWM framework: + + Users -- those wishing to employ the API merely to produce PWM + signals; once they have identified the appropriate physical output + on the platform in question, they don't care about the details of + the underlying hardware + + Driver authors -- those wishing to bind devices that can generate + PWM signals to the Generic PWM Device API, so that the services of + those devices become available to users; assuming the hardware can + support the needs of a user, driver authors don't care about the + details of the user's application + +Generally speaking, users will first invoke pwm_request() to obtain a +handle to a PWM device. They will then pass that handle to functions +like pwm_duty_ns() and pwm_period_ns() to set the duty cycle and +period of the PWM signal, respectively. They will also invoke +pwm_start() and pwm_stop() to turn the signal on and off. + +The framework also provides a sysfs interface to PWM devices, which is +adequate for basic needs and testing. + +Driver authors fill out a pwm_device structure, which describes the +capabilities of the PWM hardware being driven--- including the number +of distinct output channels the peripheral offers. They then invoke +pwm_register() (usually from within their device's probe() handler) to +make the PWM API aware of their device. The framework will call back +to the methods described in the pwm_device structure to configure and +use the hardware. + +Note that PWM signals can be produced by a variety of peripherals, +beyond the true PWM hardware offered by many system-on-chip devices. +Other possibilities include
[RFC 2/6] [PWM] Changes to existing include/linux/pwm.h to adapt to generic PWM API
Signed-off-by: Bill Gatliff [EMAIL PROTECTED]
---
include/linux/pwm.h | 168 --
1 files changed, 147 insertions(+), 21 deletions(-)
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 3945f80..d3d18f7 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -1,31 +1,157 @@
#ifndef __LINUX_PWM_H
#define __LINUX_PWM_H
-struct pwm_device;
-
/*
- * pwm_request - request a PWM device
+ * include/linux/pwm.h
+ *
+ * Copyright (C) 2008 Bill Gatliff
+ *
+ * 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
*/
-struct pwm_device *pwm_request(int pwm_id, const char *label);
-/*
- * pwm_free - free a PWM device
- */
-void pwm_free(struct pwm_device *pwm);
+enum {
+ PWM_CONFIG_DUTY_TICKS = BIT(0),
+ PWM_CONFIG_PERIOD_TICKS = BIT(1),
+ PWM_CONFIG_POLARITY = BIT(2),
+ PWM_CONFIG_START = BIT(3),
+ PWM_CONFIG_STOP = BIT(4),
-/*
- * pwm_config - change a PWM device configuration
- */
-int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns);
+ PWM_CONFIG_HANDLER = BIT(5),
-/*
- * pwm_enable - start a PWM output toggling
- */
-int pwm_enable(struct pwm_device *pwm);
+ PWM_CONFIG_DUTY_NS = BIT(6),
+ PWM_CONFIG_DUTY_PERCENT = BIT(7),
+ PWM_CONFIG_PERIOD_NS = BIT(8),
+};
+
+struct pwm_channel;
+struct work_struct;
+
+typedef int (*pwm_handler_t)(struct pwm_channel *p, void *data);
+typedef void (*pwm_callback_t)(struct pwm_channel *p);
+
+struct pwm_channel_config {
+ int config_mask;
+ unsigned long duty_ticks;
+ unsigned long period_ticks;
+ int polarity;
+
+ pwm_handler_t handler;
+
+ unsigned long duty_ns;
+ unsigned long period_ns;
+ int duty_percent;
+};
+
+struct pwm_device {
+ struct list_head list;
+ spinlock_t list_lock;
+ struct device *dev;
+ struct module *owner;
+ struct pwm_channel *channels;
+
+ const char *bus_id;
+ int nchan;
+
+ int (*request) (struct pwm_channel *p);
+ void(*free) (struct pwm_channel *p);
+ int (*config) (struct pwm_channel *p,
+struct pwm_channel_config *c);
+ int (*config_nosleep)(struct pwm_channel *p,
+ struct pwm_channel_config *c);
+ int (*synchronize) (struct pwm_channel *p,
+struct pwm_channel *to_p);
+ int (*unsynchronize)(struct pwm_channel *p,
+struct pwm_channel *from_p);
+ int (*set_callback) (struct pwm_channel *p,
+pwm_callback_t callback);
+};
+
+int pwm_register(struct pwm_device *pwm);
+int pwm_unregister(struct pwm_device *pwm);
+
+enum {
+ FLAG_REQUESTED = 0,
+ FLAG_STOP = 1,
+};
+
+struct pwm_channel {
+ struct list_head list;
+ struct pwm_device *pwm;
+ const char *requester;
+ int chan;
+ unsigned long flags;
+ unsigned long tick_hz;
+
+ spinlock_t lock;
+ struct completion complete;
+
+ pwm_callback_t callback;
+
+ struct work_struct handler_work;
+ pwm_handler_t handler;
+ void *handler_data;
+
+ int active_low;
+ unsigned long period_ticks;
+ unsigned long duty_ticks;
+};
+
+struct pwm_channel *
+pwm_request(const char *bus_id, int chan,
+ const char *requester);
+
+void pwm_free(struct pwm_channel *pwm);
+
+int pwm_config_nosleep(struct pwm_channel *pwm,
+ struct pwm_channel_config *c);
+
+int pwm_config(struct pwm_channel *pwm,
+ struct pwm_channel_config *c);
+
+unsigned long pwm_ns_to_ticks(struct pwm_channel *pwm,
+ unsigned long nsecs);
+
+unsigned long pwm_ticks_to_ns(struct pwm_channel *pwm,
+ unsigned long ticks);
+
+int pwm_period_ns(struct pwm_channel *pwm,
+ unsigned long period_ns);
+
+int pwm_duty_ns(struct pwm_channel *pwm,
+ unsigned long duty_ns);
+
+int pwm_duty_percent(struct pwm_channel *pwm,
+int percent);
+
+int pwm_polarity(struct pwm_channel *pwm,
+int active_high);
+
+int pwm_start(struct pwm_channel *pwm);
+
+int pwm_stop(struct pwm_channel
[RFC 5/6] [PWM] Install new Atmel PWMC driver in Kconfig, expunge old one
Signed-off-by: Bill Gatliff [EMAIL PROTECTED]
---
arch/arm/Kconfig |2 +
drivers/Makefile |2 +
drivers/misc/Kconfig |9 -
drivers/misc/Makefile|1 -
drivers/misc/atmel_pwm.c | 409 --
drivers/pwm/Kconfig | 24 +++
drivers/pwm/Makefile |6 +
7 files changed, 34 insertions(+), 419 deletions(-)
delete mode 100644 drivers/misc/atmel_pwm.c
create mode 100644 drivers/pwm/Kconfig
create mode 100644 drivers/pwm/Makefile
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 70dba16..fed3eef 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1196,6 +1196,8 @@ source drivers/spi/Kconfig
source drivers/gpio/Kconfig
+source drivers/pwm/Kconfig
+
source drivers/w1/Kconfig
source drivers/power/Kconfig
diff --git a/drivers/Makefile b/drivers/Makefile
index 2735bde..f242fc6 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -6,6 +6,8 @@
#
obj-y += gpio/
+obj-$(CONFIG_GENERIC_PWM) += pwm/
+
obj-$(CONFIG_PCI) += pci/
obj-$(CONFIG_PARISC) += parisc/
obj-$(CONFIG_RAPIDIO) += rapidio/
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index a726f3b..cdea0bb 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -13,15 +13,6 @@ menuconfig MISC_DEVICES
if MISC_DEVICES
-config ATMEL_PWM
- tristate Atmel AT32/AT91 PWM support
- depends on AVR32 || ARCH_AT91
- help
- This option enables device driver support for the PWM channels
- on certain Atmel prcoessors. Pulse Width Modulation is used for
- purposes including software controlled power-efficent backlights
- on LCD displays, motor control, and waveform generation.
-
config ATMEL_TCLIB
bool Atmel AT32/AT91 Timer/Counter Library
depends on (AVR32 || ARCH_AT91)
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index c6c13f6..9e67012 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -10,7 +10,6 @@ obj-$(CONFIG_EEEPC_LAPTOP)+= eeepc-laptop.o
obj-$(CONFIG_MSI_LAPTOP) += msi-laptop.o
obj-$(CONFIG_COMPAL_LAPTOP)+= compal-laptop.o
obj-$(CONFIG_ACER_WMI) += acer-wmi.o
-obj-$(CONFIG_ATMEL_PWM)+= atmel_pwm.o
obj-$(CONFIG_ATMEL_SSC)+= atmel-ssc.o
obj-$(CONFIG_ATMEL_TCLIB) += atmel_tclib.o
obj-$(CONFIG_HP_WMI) += hp-wmi.o
diff --git a/drivers/misc/atmel_pwm.c b/drivers/misc/atmel_pwm.c
deleted file mode 100644
index 6aa5294..000
--- a/drivers/misc/atmel_pwm.c
+++ /dev/null
@@ -1,409 +0,0 @@
-#include linux/module.h
-#include linux/clk.h
-#include linux/err.h
-#include linux/io.h
-#include linux/interrupt.h
-#include linux/platform_device.h
-#include linux/atmel_pwm.h
-
-
-/*
- * This is a simple driver for the PWM controller found in various newer
- * Atmel SOCs, including the AVR32 series and the AT91sam9263.
- *
- * Chips with current Linux ports have only 4 PWM channels, out of max 32.
- * AT32UC3A and AT32UC3B chips have 7 channels (but currently no Linux).
- * Docs are inconsistent about the width of the channel counter registers;
- * it's at least 16 bits, but several places say 20 bits.
- */
-#definePWM_NCHAN 4 /* max 32 */
-
-struct pwm {
- spinlock_t lock;
- struct platform_device *pdev;
- u32 mask;
- int irq;
- void __iomem*base;
- struct clk *clk;
- struct pwm_channel *channel[PWM_NCHAN];
- void(*handler[PWM_NCHAN])(struct pwm_channel *);
-};
-
-
-/* global PWM controller registers */
-#define PWM_MR 0x00
-#define PWM_ENA0x04
-#define PWM_DIS0x08
-#define PWM_SR 0x0c
-#define PWM_IER0x10
-#define PWM_IDR0x14
-#define PWM_IMR0x18
-#define PWM_ISR0x1c
-
-static inline void pwm_writel(const struct pwm *p, unsigned offset, u32 val)
-{
- __raw_writel(val, p-base + offset);
-}
-
-static inline u32 pwm_readl(const struct pwm *p, unsigned offset)
-{
- return __raw_readl(p-base + offset);
-}
-
-static inline void __iomem *pwmc_regs(const struct pwm *p, int index)
-{
- return p-base + 0x200 + index * 0x20;
-}
-
-static struct pwm *pwm;
-
-static void pwm_dumpregs(struct pwm_channel *ch, char *tag)
-{
- struct device *dev = pwm-pdev-dev;
-
- dev_dbg(dev, %s: mr %08x, sr %08x, imr %08x\n,
- tag,
- pwm_readl(pwm, PWM_MR),
- pwm_readl(pwm, PWM_SR),
- pwm_readl(pwm, PWM_IMR));
- dev_dbg(dev,
- pwm ch%d - mr %08x, dty %u, prd %u, cnt %u\n,
- ch-index,
- pwm_channel_readl(ch, PWM_CMR),
- pwm_channel_readl(ch, PWM_CDTY),
- pwm_channel_readl(ch, PWM_CPRD),
-
[RFC 1/6] [PWM] Generic PWM API implementation
Signed-off-by: Bill Gatliff [EMAIL PROTECTED]
---
drivers/pwm/pwm.c | 667 +
1 files changed, 667 insertions(+), 0 deletions(-)
create mode 100644 drivers/pwm/pwm.c
diff --git a/drivers/pwm/pwm.c b/drivers/pwm/pwm.c
new file mode 100644
index 000..2f28c20
--- /dev/null
+++ b/drivers/pwm/pwm.c
@@ -0,0 +1,667 @@
+/*
+ * drivers/pwm/pwm.c
+ *
+ * Copyright (C) 2008 Bill Gatliff
+ *
+ * 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
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/device.h
+#include linux/spinlock.h
+#include linux/fs.h
+#include linux/completion.h
+#include linux/workqueue.h
+#include linux/pwm.h
+
+
+static int __pwm_create_sysfs(struct pwm_device *pwm);
+
+static LIST_HEAD(pwm_device_list);
+static DEFINE_MUTEX(device_list_mutex);
+static struct class pwm_class;
+static struct workqueue_struct *pwm_handler_workqueue;
+
+
+int pwm_register(struct pwm_device *pwm)
+{
+ struct pwm_channel *p;
+ int wchan;
+ int ret = 0;
+
+ spin_lock_init(pwm-list_lock);
+
+ p = kcalloc(pwm-nchan, sizeof(struct pwm_channel), GFP_KERNEL);
+ if (!p)
+ return -ENOMEM;
+
+ for (wchan = 0; wchan pwm-nchan; wchan++) {
+ spin_lock_init(p[wchan].lock);
+ init_completion(p[wchan].complete);
+ p[wchan].chan = wchan;
+ p[wchan].pwm = pwm;
+ }
+
+ pwm-channels = p;
+
+ mutex_lock(device_list_mutex);
+
+ list_add_tail(pwm-list, pwm_device_list);
+ ret = __pwm_create_sysfs(pwm);
+ if (ret) {
+ mutex_unlock(device_list_mutex);
+ goto err_create_sysfs;
+ }
+
+ mutex_unlock(device_list_mutex);
+
+ pr_info(%s: %d channels\n, pwm-bus_id, pwm-nchan);
+ return 0;
+
+err_create_sysfs:
+ kfree(p);
+
+ return ret;
+}
+EXPORT_SYMBOL(pwm_register);
+
+
+static int __match_device(struct device *dev, void *data)
+{
+ return dev_get_drvdata(dev) == data;
+}
+
+
+int pwm_unregister(struct pwm_device *pwm)
+{
+ int wchan;
+ struct device *dev;
+
+ mutex_lock(device_list_mutex);
+
+ for (wchan = 0; wchan pwm-nchan; wchan++) {
+ if (pwm-channels[wchan].flags FLAG_REQUESTED) {
+ mutex_unlock(device_list_mutex);
+ return -EBUSY;
+ }
+ }
+
+ for (wchan = 0; wchan pwm-nchan; wchan++) {
+ dev = class_find_device(pwm_class, NULL,
+ pwm-channels[wchan],
+ __match_device);
+ if (dev) {
+ put_device(dev);
+ device_unregister(dev);
+ }
+ }
+
+ kfree(pwm-channels);
+ list_del(pwm-list);
+ mutex_unlock(device_list_mutex);
+
+ return 0;
+}
+EXPORT_SYMBOL(pwm_unregister);
+
+
+static struct pwm_device *
+__pwm_find_device(const char *bus_id)
+{
+ struct pwm_device *p;
+
+ list_for_each_entry(p, pwm_device_list, list)
+ {
+ if (!strcmp(bus_id, p-bus_id))
+ return p;
+ }
+ return NULL;
+}
+
+
+static int
+__pwm_request_channel(struct pwm_channel *p,
+ const char *requester)
+{
+ int ret;
+
+ if (test_and_set_bit(FLAG_REQUESTED, p-flags))
+ return -EBUSY;
+
+ if (p-pwm-request) {
+ ret = p-pwm-request(p);
+ if (ret) {
+ clear_bit(FLAG_REQUESTED, p-flags);
+ return ret;
+ }
+ }
+
+ p-requester = requester;
+ return 0;
+}
+
+
+struct pwm_channel *
+pwm_request(const char *bus_id,
+ int chan,
+ const char *requester)
+{
+ struct pwm_device *p;
+ int ret;
+
+ mutex_lock(device_list_mutex);
+
+ p = __pwm_find_device(bus_id);
+ if (!p || chan = p-nchan)
+ goto err_no_device;
+
+ if (!try_module_get(p-owner))
+ goto err_module_get_failed;
+
+ ret = __pwm_request_channel(p-channels[chan], requester);
+ if (ret)
+ goto err_request_failed;
+
+
[RFC 4/6] [PWM] Driver for Atmel PWMC peripheral
Signed-off-by: Bill Gatliff [EMAIL PROTECTED]
---
drivers/pwm/atmel-pwm.c | 631 +++
1 files changed, 631 insertions(+), 0 deletions(-)
create mode 100644 drivers/pwm/atmel-pwm.c
diff --git a/drivers/pwm/atmel-pwm.c b/drivers/pwm/atmel-pwm.c
new file mode 100644
index 000..b65e84f
--- /dev/null
+++ b/drivers/pwm/atmel-pwm.c
@@ -0,0 +1,631 @@
+/*
+ * drivers/pwm/atmel-pwm.c
+ *
+ * Copyright (C) 2008 Bill Gatliff
+ * Copyright (C) 2007 David Brownell
+ *
+ * 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
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/io.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/pwm.h
+
+
+enum {
+ /* registers common to the PWMC peripheral */
+ PWMC_MR = 0,
+ PWMC_ENA = 4,
+ PWMC_DIS = 8,
+ PWMC_SR = 0xc,
+ PWMC_IER = 0x10,
+ PWMC_IDR = 0x14,
+ PWMC_IMR = 0x18,
+ PWMC_ISR = 0x1c,
+
+ /* registers per each PWMC channel */
+ PWMC_CMR = 0,
+ PWMC_CDTY = 4,
+ PWMC_CPRD = 8,
+ PWMC_CCNT = 0xc,
+ PWMC_CUPD = 0x10,
+
+ /* how to find each channel */
+ PWMC_CHAN_BASE = 0x200,
+ PWMC_CHAN_STRIDE = 0x20,
+
+ /* CMR bits of interest */
+ PWMC_CMR_CPD = 10,
+ PWMC_CMR_CPOL = 9,
+ PWMC_CMR_CALG = 8,
+ PWMC_CMR_CPRE_MASK = 0xf,
+};
+
+struct atmel_pwm {
+ struct pwm_device pwm;
+ spinlock_t lock;
+ void __iomem *iobase;
+ struct clk *clk;
+ u32 *sync_mask;
+ int irq;
+ u32 ccnt_mask;
+};
+
+
+static inline void
+pwmc_writel(const struct atmel_pwm *p,
+ unsigned offset, u32 val)
+{
+ __raw_writel(val, p-iobase + offset);
+}
+
+
+static inline u32
+pwmc_readl(const struct atmel_pwm *p,
+ unsigned offset)
+{
+ return __raw_readl(p-iobase + offset);
+}
+
+
+static inline void
+pwmc_chan_writel(const struct pwm_channel *p,
+u32 offset, u32 val)
+{
+ const struct atmel_pwm *ap
+ = container_of(p-pwm, struct atmel_pwm, pwm);
+
+ if (PWMC_CMR == offset)
+ val = ((1 PWMC_CMR_CPD)
+ | (1 PWMC_CMR_CPOL)
+ | (1 PWMC_CMR_CALG)
+ | (PWMC_CMR_CPRE_MASK));
+ else
+ val = ap-ccnt_mask;
+
+ pwmc_writel(ap, offset + PWMC_CHAN_BASE
+ + (p-chan * PWMC_CHAN_STRIDE), val);
+}
+
+
+static inline u32
+pwmc_chan_readl(const struct pwm_channel *p,
+ u32 offset)
+{
+ const struct atmel_pwm *ap
+ = container_of(p-pwm, struct atmel_pwm, pwm);
+
+ return pwmc_readl(ap, offset + PWMC_CHAN_BASE
+ + (p-chan * PWMC_CHAN_STRIDE));
+}
+
+
+static inline int
+__atmel_pwm_is_on(struct pwm_channel *p)
+{
+ struct atmel_pwm *ap = container_of(p-pwm, struct atmel_pwm, pwm);
+ return (pwmc_readl(ap, PWMC_SR) (1 p-chan)) ? 1 : 0;
+}
+
+
+static inline void
+__atmel_pwm_unsynchronize(struct pwm_channel *p,
+ struct pwm_channel *to_p)
+{
+ const struct atmel_pwm *ap
+ = container_of(p-pwm, struct atmel_pwm, pwm);
+ int wchan;
+
+ if (to_p) {
+ ap-sync_mask[p-chan] = ~(1 to_p-chan);
+ ap-sync_mask[to_p-chan] = ~(1 p-chan);
+ goto done;
+ }
+
+ ap-sync_mask[p-chan] = 0;
+ for (wchan = 0; wchan ap-pwm.nchan; wchan++)
+ ap-sync_mask[wchan] = ~(1 p-chan);
+done:
+ pr_debug(%s:%d sync_mask %x\n,
+p-pwm-bus_id, p-chan, ap-sync_mask[p-chan]);
+}
+
+
+static inline void
+__atmel_pwm_synchronize(struct pwm_channel *p,
+ struct pwm_channel *to_p)
+{
+ const struct atmel_pwm *ap
+ = container_of(p-pwm, struct atmel_pwm, pwm);
+
+ if (!to_p)
+ return;
+
+ ap-sync_mask[p-chan] |= (1 to_p-chan);
+ ap-sync_mask[to_p-chan] |= (1 p-chan);
+
+ pr_debug(%s:%d sync_mask %x\n,
+p-pwm-bus_id, p-chan, ap-sync_mask[p-chan]);
+}
+
+
+static inline void
+__atmel_pwm_stop(struct pwm_channel *p)
+{
+ struct atmel_pwm *ap = container_of(p-pwm, struct
Re: performance: memcpy vs. __copy_tofrom_user
Dominik Bozek wrote: I have done a test of memcpy() and __copy_tofrom_user() on the mpc8313. And the major conclusion is that __copy_tofrom_user is more efficient than memcpy. Sometimes about 40%. If I good understand, the memcpy() just copy the data, while __copy_tofrom_user() take care if the memory wasn't swapped out. There's not much overhead in dealing with bad pointers; it's mostly fixup after the fault. The performance difference most likely comes from the fact that copy to/from user can assume that the memory is cacheable, while memcpy is occasionally used on cache-inhibited memory -- so dcbz isn't used. We may be better off handling the alignment fault on those occasions, and we should use dcba on chips that support it. I'm not sure why we don't use dcbt in memcpy(), as it's just ignored if the memory is cache-inhibited. BTW. The memcpy() maybe optimized as it is on i32 when the size of block is known at compile time. Yes, that would be nice. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3] MPC5121 add pci support
On Oct 8, 2008, at 11:14 AM, Grant Likely wrote: On Wed, Oct 8, 2008 at 12:20 AM, Kumar Gala [EMAIL PROTECTED] wrote: On Oct 7, 2008, at 2:00 PM, John Rigby wrote: The following three patches add pci support for MPC5121 These got no NACKs back in August but they were not picked up by anyone either. I'll look at picking up patches 1/3 and 3/3. I'll leave 2/3 to Grant. Kumar, since both 1/3 and 2/3 touch fsl_pci.c, can you please pick up 2/3? It won't conflict with anything that I'm pushing. I'll post my ack-by line. will do. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/83xx: add DS1374 RTC support for the MPC837xE-MDS boards
The RTC is sitting on the I2C1 bus at address 0x68. RTC interrupt signal
is connected to the IPIC's EXT3 interrupt line.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8377_mds.dts |7 +++
arch/powerpc/boot/dts/mpc8378_mds.dts |7 +++
arch/powerpc/boot/dts/mpc8379_mds.dts |7 +++
3 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts
b/arch/powerpc/boot/dts/mpc8377_mds.dts
index 432782b..6ec8b86 100644
--- a/arch/powerpc/boot/dts/mpc8377_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8377_mds.dts
@@ -136,6 +136,13 @@
interrupts = 14 0x8;
interrupt-parent = ipic;
dfsrr;
+
+ [EMAIL PROTECTED] {
+ compatible = dallas,ds1374;
+ reg = 0x68;
+ interrupts = 19 0x8;
+ interrupt-parent = ipic;
+ };
};
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/mpc8378_mds.dts
b/arch/powerpc/boot/dts/mpc8378_mds.dts
index ed32c8d..c87340d 100644
--- a/arch/powerpc/boot/dts/mpc8378_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8378_mds.dts
@@ -136,6 +136,13 @@
interrupts = 14 0x8;
interrupt-parent = ipic;
dfsrr;
+
+ [EMAIL PROTECTED] {
+ compatible = dallas,ds1374;
+ reg = 0x68;
+ interrupts = 19 0x8;
+ interrupt-parent = ipic;
+ };
};
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/mpc8379_mds.dts
b/arch/powerpc/boot/dts/mpc8379_mds.dts
index f4db9ed..22cd183 100644
--- a/arch/powerpc/boot/dts/mpc8379_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8379_mds.dts
@@ -136,6 +136,13 @@
interrupts = 14 0x8;
interrupt-parent = ipic;
dfsrr;
+
+ [EMAIL PROTECTED] {
+ compatible = dallas,ds1374;
+ reg = 0x68;
+ interrupts = 19 0x8;
+ interrupt-parent = ipic;
+ };
};
[EMAIL PROTECTED] {
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3] MPC5121 add pci support
Grant Likely wrote: On Wed, Oct 8, 2008 at 9:29 AM, Matt Sealey [EMAIL PROTECTED] wrote: If this patchset is okay with everyone, is it possible that it could be rushed into 2.6.27 before it hits rc10 or release? :/ no Shucks :( At least it'll patch cleanly against 2.6.27 though right? It doesn't look very intrusive.. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3] MPC5121 add pci support
On Oct 8, 2008, at 1:51 PM, Matt Sealey wrote: Grant Likely wrote: On Wed, Oct 8, 2008 at 9:29 AM, Matt Sealey [EMAIL PROTECTED] wrote: If this patchset is okay with everyone, is it possible that it could be rushed into 2.6.27 before it hits rc10 or release? :/ no Shucks :( At least it'll patch cleanly against 2.6.27 though right? It doesn't look very intrusive.. It should patch cleanly against 2.6.27.. A few simple git cherry-picks will get you what you want. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc.git status
On Wed, 2008-10-08 at 07:10 -0500, Kumar Gala wrote: On Oct 8, 2008, at 4:29 AM, Benjamin Herrenschmidt wrote: Its useful to not rebase a branch you expect people to send you patches against and sub-maintainers are using to build tree's against. It sounds like 'next' is that branch. Indeed. Though so far I've managed to avoid rebasing anything :-) So what's the status of the patches moving from master into next? Mostly just in case. No big deal. I'll move them over today hopefully. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove CHRP and PMAC support from defconfigs, fix Kconfigs
On Wed, 2008-10-08 at 10:28 -0500, Timur Tabi wrote: On Fri, Sep 26, 2008 at 12:19 PM, Timur Tabi [EMAIL PROTECTED] wrote: The Kconfig files for PowerPC CHRP and PMAC support had default=y for some Kconfig options, and this caused support for CHRP and PMAC platforms to be enabled incorrectly for several platforms. Fix the Kconfigs and the affected defconfigs. Ben, When you applied this patch, you removed the Kconfig changes. Without those, doing a make xxx_defconfig will just add CONFIG_PPC_PMAC=y and CONFIG_PPC_CHRP=y to the .config! Hrm. Yes, I removed those changes because I want to think more about that aspect of things. $ make 83xx/mpc834x_itxgp_defconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/docproc HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/kxgettext.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/lex.zconf.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf # # configuration written to .config # $ grep CHRP .config CONFIG_PPC_CHRP=y So please apply my *original* patch. yeah well, there's a consistency problem. If we remove default for these we should remove default for all. The bug I think is in your original patch in fact to just remove those from .config rather than explicitely set them to not set. I'm not going to remove the applied patch to avoid rebasing, it's harmless to keep it in, please send another one that does the above. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove CHRP and PMAC support from defconfigs, fix Kconfigs
Benjamin Herrenschmidt wrote: yeah well, there's a consistency problem. If we remove default for these we should remove default for all. I only removed the default from the ones I knew were wrong. The bug I think is in your original patch in fact to just remove those from .config rather than explicitely set them to not set. I did that because with the Kconfig changes, it's not necessary to set them to not set, so it kept the patch smaller. I'm not going to remove the applied patch to avoid rebasing, it's harmless to keep it in, please send another one that does the above. Ok. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: remove default=y from PMAC and CHRP Kconfigs
Remove the default y from the Kconfig options for CHRP, PMAC, and PMAC64 platforms. This patch is a follow-up to remove CHRP and PMAC support from defconfigs, fix Kconfigs, which was applied incompletely. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- Ben, in the future, please apply either all of my patch or none of it. Applying half of my patch and thinking about the other half doesn't do me any good. arch/powerpc/platforms/chrp/Kconfig |1 - arch/powerpc/platforms/powermac/Kconfig |4 2 files changed, 0 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/platforms/chrp/Kconfig b/arch/powerpc/platforms/chrp/Kconfig index 22b4b4e..682afbc 100644 --- a/arch/powerpc/platforms/chrp/Kconfig +++ b/arch/powerpc/platforms/chrp/Kconfig @@ -9,4 +9,3 @@ config PPC_CHRP select PPC_UDBG_16550 select PPC_NATIVE select PCI - default y diff --git a/arch/powerpc/platforms/powermac/Kconfig b/arch/powerpc/platforms/powermac/Kconfig index 055990c..85619d3 100644 --- a/arch/powerpc/platforms/powermac/Kconfig +++ b/arch/powerpc/platforms/powermac/Kconfig @@ -6,7 +6,6 @@ config PPC_PMAC select PPC_INDIRECT_PCI if PPC32 select PPC_MPC106 if PPC32 select PPC_NATIVE - default y config PPC_PMAC64 bool @@ -16,6 +15,3 @@ config PPC_PMAC64 select MPIC_U3_HT_IRQS select GENERIC_TBSYNC select PPC_970_NAP - default y - - -- 1.5.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
8600 serial support
Hi, I thought I might take a whack at fixing the 2.6 serial driver for my 8600. At the top of pmac_zilog.c (2.6.26) there is a todo for DMA. A quick glance at macserial.c (2.4.31) suggests it has dbdma support for receive. Anyone know of any pitfalls for adding dbdma support for pmac_zilog.c? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove default=y from PMAC and CHRP Kconfigs
On Wed, 2008-10-08 at 14:57 -0500, Timur Tabi wrote: Remove the default y from the Kconfig options for CHRP, PMAC, and PMAC64 platforms. This patch is a follow-up to remove CHRP and PMAC support from defconfigs, fix Kconfigs, which was applied incompletely. No. Instead, send a patch that fixes the defconfig's to explicitely set those to n. As to whether those should be defaults or not, this is a different discussion (I'm almost tempted to have everything default to y). Ben. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- Ben, in the future, please apply either all of my patch or none of it. Applying half of my patch and thinking about the other half doesn't do me any good. arch/powerpc/platforms/chrp/Kconfig |1 - arch/powerpc/platforms/powermac/Kconfig |4 2 files changed, 0 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/platforms/chrp/Kconfig b/arch/powerpc/platforms/chrp/Kconfig index 22b4b4e..682afbc 100644 --- a/arch/powerpc/platforms/chrp/Kconfig +++ b/arch/powerpc/platforms/chrp/Kconfig @@ -9,4 +9,3 @@ config PPC_CHRP select PPC_UDBG_16550 select PPC_NATIVE select PCI - default y diff --git a/arch/powerpc/platforms/powermac/Kconfig b/arch/powerpc/platforms/powermac/Kconfig index 055990c..85619d3 100644 --- a/arch/powerpc/platforms/powermac/Kconfig +++ b/arch/powerpc/platforms/powermac/Kconfig @@ -6,7 +6,6 @@ config PPC_PMAC select PPC_INDIRECT_PCI if PPC32 select PPC_MPC106 if PPC32 select PPC_NATIVE - default y config PPC_PMAC64 bool @@ -16,6 +15,3 @@ config PPC_PMAC64 select MPIC_U3_HT_IRQS select GENERIC_TBSYNC select PPC_970_NAP - default y - - ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove default=y from PMAC and CHRP Kconfigs
On Wed, Oct 8, 2008 at 3:03 PM, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: No. Instead, send a patch that fixes the defconfig's to explicitely set those to n. As to whether those should be defaults or not, this is a different discussion (I'm almost tempted to have everything default to y). But this is the reason I sent you the patch in the first place. I think default y is wrong and doesn't make any sense, so I'm asking you for a technical reason why PMAC and CHRP should default to yes. That is the focus of my patch. The defconfig changes are just to clean up the mess that default y left behind. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove default=y from PMAC and CHRP Kconfigs
On Wed, 2008-10-08 at 15:14 -0500, Timur Tabi wrote: But this is the reason I sent you the patch in the first place. I think default y is wrong and doesn't make any sense, so I'm asking you for a technical reason why PMAC and CHRP should default to yes. That is the focus of my patch. The defconfig changes are just to clean up the mess that default y left behind. I'm happy with -all- platforms for a given CPU type defaulting to y. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 8600 serial support
On Wed, 2008-10-08 at 12:51 -0700, Kevin Diggs wrote: Hi, I thought I might take a whack at fixing the 2.6 serial driver for my 8600. At the top of pmac_zilog.c (2.6.26) there is a todo for DMA. A quick glance at macserial.c (2.4.31) suggests it has dbdma support for receive. Anyone know of any pitfalls for adding dbdma support for pmac_zilog.c? Yes, it's not totally trivial and I wouldn't recommend using the weirdo code in macserial (it does things that I don't understand how they work with the dbdma engine). The best way I see is to start from scratch with two different mechanisms: - For Tx, that's the easiest, the fire off DMA's for outgoing chars, maybe queue up a few descriptors to let data accumulate. - For Rx, one descriptor per byte. That sucks but I think that's also what Apple does. No need to have a huge Rx buffer anyway. That gives you precise Rx status to the byte. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
PPC440EPx gpio driver
I have begun writing a driver for the GPIOs of the PPC440EPx. I just
noticed that the PIKA Warp .dts references a device ibm,gpio-440ep,
but so far I have not been able to find a driver for that device.
So, here is what I have so far (patch is off 2.6.27-rc9). It is not
sufficiently general to be merged at this point, but it does appear
to function with my Sequoia board (only tested gpio input, so far).
Signed-off-by: Steve Falco sfalco at harris.com
diff --git a/arch/powerpc/platforms/44x/ppc4xx-gpio.c
b/arch/powerpc/platforms/44x/ppc4xx-gpio.c
new file mode 100644
index 000..ce552b4
--- /dev/null
+++ b/arch/powerpc/platforms/44x/ppc4xx-gpio.c
@@ -0,0 +1,246 @@
+/*
+ * PPC4xx gpio driver
+ *
+ * Copyright (c) 2008 Harris Corporation
+ * Copyright (c) 2008 Sascha Hauer [EMAIL PROTECTED], Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * 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
+ */
+
+#include linux/of.h
+#include linux/kernel.h
+#include linux/of_gpio.h
+#include linux/io.h
+#include linux/of_platform.h
+
+#include asm/gpio.h
+#include asm/ppc4xx.h
+
+static DEFINE_SPINLOCK(gpio_lock);
+
+struct ppc4xx_gpiochip {
+ struct of_mm_gpio_chip mmchip;
+ unsigned int shadow_or;
+ unsigned int shadow_tcr;
+ unsigned int shadow_osrl;
+ unsigned int shadow_osrh;
+ unsigned int shadow_tsrl;
+ unsigned int shadow_tsrh;
+ unsigned int shadow_odr;
+};
+
+/*
+ * GPIO LIB API implementation for GPIOs
+ *
+ * There are a maximum of 64 gpios, spread over two sets of control registers.
+ * The sets are called GPIO0 and GPIO1. Each set is managed separately, so
+ * there will be two entried in the .dts file.
+ */
+
+static int ppc4xx_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct ppc4xx_gpio __iomem *regs = mm_gc-regs;
+ unsigned int ret;
+
+ ret = (in_be32(regs-gpio_ir) (31 - gpio)) 1;
+
+ return ret;
+}
+
+static inline void
+__ppc4xx_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct ppc4xx_gpiochip *chip = container_of(mm_gc,
+ struct ppc4xx_gpiochip, mmchip);
+ struct ppc4xx_gpio __iomem *regs = mm_gc-regs;
+
+ if (val)
+ chip-shadow_or |= 1 (31 - gpio);
+ else
+ chip-shadow_or = ~(1 (31 - gpio));
+ out_be32(regs-gpio_or, chip-shadow_or);
+}
+
+static void
+ppc4xx_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(gpio_lock, flags);
+
+ __ppc4xx_gpio_set(gc, gpio, val);
+
+ spin_unlock_irqrestore(gpio_lock, flags);
+
+ pr_debug(%s: gpio: %d val: %d\n, __func__, gpio, val);
+}
+
+static int ppc4xx_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct ppc4xx_gpiochip *chip = container_of(mm_gc,
+ struct ppc4xx_gpiochip, mmchip);
+ struct ppc4xx_gpio __iomem *regs = mm_gc-regs;
+ unsigned long flags;
+
+ spin_lock_irqsave(gpio_lock, flags);
+
+ /* Disable open-drain function */
+ chip-shadow_odr = ~(1 (31 - gpio));
+ out_be32(regs-gpio_odr, chip-shadow_odr);
+
+ /* Float the pin */
+ chip-shadow_tcr = ~(1 (31 - gpio));
+ out_be32(regs-gpio_tcr, chip-shadow_tcr);
+
+ /* Bits 0-15 use TSRL/OSRL, bits 16-31 use TSRH/OSRH */
+ if(gpio 16) {
+ chip-shadow_osrl = ~(3 ((15 - gpio) * 2));
+ out_be32(regs-gpio_osrl, chip-shadow_osrl);
+
+ chip-shadow_tsrl = ~(3 ((15 - gpio) * 2));
+ out_be32(regs-gpio_tsrl, chip-shadow_tsrl);
+ } else {
+ chip-shadow_osrh = ~(3 ((31 - gpio) * 2));
+ out_be32(regs-gpio_osrh, chip-shadow_osrh);
+
+ chip-shadow_tsrh = ~(3 ((31 - gpio) * 2));
+ out_be32(regs-gpio_tsrh, chip-shadow_tsrh);
+ }
+
+ spin_unlock_irqrestore(gpio_lock, flags);
+
+ return 0;
+}
+
+static int
+ppc4xx_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct ppc4xx_gpiochip *chip = container_of(mm_gc,
+ struct ppc4xx_gpiochip,
Re: powerpc.git status
On Oct 8, 2008, at 2:16 PM, Benjamin Herrenschmidt wrote: On Wed, 2008-10-08 at 07:10 -0500, Kumar Gala wrote: On Oct 8, 2008, at 4:29 AM, Benjamin Herrenschmidt wrote: Its useful to not rebase a branch you expect people to send you patches against and sub-maintainers are using to build tree's against. It sounds like 'next' is that branch. Indeed. Though so far I've managed to avoid rebasing anything :-) So what's the status of the patches moving from master into next? Mostly just in case. No big deal. I'll move them over today hopefully. Thanks. I need a stable basis to send a new pull request. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove default=y from PMAC and CHRP Kconfigs
On Thu, Oct 09, 2008 at 07:03:06AM +1100, Benjamin Herrenschmidt wrote: No. Instead, send a patch that fixes the defconfig's to explicitely set those to n. What's the difference, other than wasting some bytes in the Kconfig file? As to whether those should be defaults or not, this is a different discussion (I'm almost tempted to have everything default to y). Please, no. It's much easier to turn on what you want, than to go through menuconfig turning a million things off. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC440EPx gpio driver
Here is the remainder of the driver - just the structure of the
registers for the 440EPx. I put the struct in this file because that
is similar to what was done for the mpc52xx, but the struct could go
elsewhere if more appropriate.
Anyway, I'd like some feedback on this driver, because I imagine other
folks would like to have a gpio driver for the 440 family.
Signed-off-by: Steve Falco sfalco at harris.com
diff --git a/arch/powerpc/include/asm/ppc4xx.h
b/arch/powerpc/include/asm/ppc4xx.h
index 033039a..acbccb7 100644
--- a/arch/powerpc/include/asm/ppc4xx.h
+++ b/arch/powerpc/include/asm/ppc4xx.h
@@ -13,6 +13,28 @@
#ifndef __ASM_POWERPC_PPC4xx_H__
#define __ASM_POWERPC_PPC4xx_H__
+/* GPIO */
+struct ppc4xx_gpio {
+ unsigned int gpio_or;
+ unsigned int gpio_tcr;
+ unsigned int gpio_osrl;
+ unsigned int gpio_osrh;
+ unsigned int gpio_tsrl;
+ unsigned int gpio_tsrh;
+ unsigned int gpio_odr;
+ unsigned int gpio_ir;
+ unsigned int gpio_rr1;
+ unsigned int gpio_rr2;
+ unsigned int gpio_rr3;
+ unsigned int reserved1;
+ unsigned int gpio_isr1l;
+ unsigned int gpio_isr1h;
+ unsigned int gpio_isr2l;
+ unsigned int gpio_isr2h;
+ unsigned int gpio_isr3l;
+ unsigned int gpio_isr3h;
+};
+
extern void ppc4xx_reset_system(char *cmd);
#endif /* __ASM_POWERPC_PPC4xx_H__ */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: fsl_upm compile failure.
Hi,
On Wed, Oct 08, 2008 at 06:28:15PM -0400, Dave Jones wrote:
Hi Anton,
I tried reenabling CONFIG_MTD_NAND_FSL_UPM in the Fedora kernel
today (currently on 2.6.27-rc9-git1), and got the error below.
ERROR: fsl_lbc_lock [drivers/mtd/nand/fsl_upm.ko] undefined!
Weird. It works for me with mpc836x_rdk_defconfig and
MTD_NAND_FSL_UPM=m...
Hm..
CC drivers/mtd/nand/fsl_upm.mod.o
LD [M] drivers/mtd/nand/fsl_upm.ko
Can you send me the .config file you use?
It seems that this isn't exported to modules.
diff below fixes this. (Not tested yet, the Fedora ppc
builders are a little slow).
Dave
---
CONFIG_MTD_NAND_FSL_UPM can be built modular, but needs to
use fsl_lbc_lock, which isn't currently exported.
Signed-off-by: Dave Jones [EMAIL PROTECTED]
diff --git a/arch/powerpc/sysdev/fsl_lbc.c b/arch/powerpc/sysdev/fsl_lbc.c
index 422c8fa..1c6c522 100644
--- a/arch/powerpc/sysdev/fsl_lbc.c
+++ b/arch/powerpc/sysdev/fsl_lbc.c
@@ -16,6 +16,7 @@
#include asm/fsl_lbc.h
spinlock_t fsl_lbc_lock = __SPIN_LOCK_UNLOCKED(fsl_lbc_lock);
+EXPORT_SYMBOL(fsl_lbc_lock);
struct fsl_lbc_regs __iomem *fsl_lbc_regs;
EXPORT_SYMBOL(fsl_lbc_regs);
But the patch looks obviously correct. Much thanks for catching this.
Though better option would be to uninline the fsl_upm_run_pattern()..
it is quite big anyway... Something like this:
diff --git a/arch/powerpc/include/asm/fsl_lbc.h
b/arch/powerpc/include/asm/fsl_lbc.h
index 303f548..af2b535 100644
--- a/arch/powerpc/include/asm/fsl_lbc.h
+++ b/arch/powerpc/include/asm/fsl_lbc.h
@@ -24,7 +24,6 @@
#define __ASM_FSL_LBC_H
#include linux/types.h
-#include linux/spinlock.h
#include asm/io.h
struct fsl_lbc_bank {
@@ -228,7 +227,6 @@ struct fsl_lbc_regs {
};
extern struct fsl_lbc_regs __iomem *fsl_lbc_regs;
-extern spinlock_t fsl_lbc_lock;
/*
* FSL UPM routines
@@ -268,44 +266,7 @@ static inline void fsl_upm_end_pattern(struct fsl_upm *upm)
cpu_relax();
}
-/**
- * fsl_upm_run_pattern - actually run an UPM pattern
- * @upm: pointer to the fsl_upm structure obtained via fsl_upm_find
- * @io_base: remapped pointer to where memory access should happen
- * @mar: MAR register content during pattern execution
- *
- * This function triggers dummy write to the memory specified by the io_base,
- * thus UPM pattern actually executed. Note that mar usage depends on the
- * pre-programmed AMX bits in the UPM RAM.
- */
-static inline int fsl_upm_run_pattern(struct fsl_upm *upm,
- void __iomem *io_base, u32 mar)
-{
- int ret = 0;
- unsigned long flags;
-
- spin_lock_irqsave(fsl_lbc_lock, flags);
-
- out_be32(fsl_lbc_regs-mar, mar (32 - upm-width));
-
- switch (upm-width) {
- case 8:
- out_8(io_base, 0x0);
- break;
- case 16:
- out_be16(io_base, 0x0);
- break;
- case 32:
- out_be32(io_base, 0x0);
- break;
- default:
- ret = -EINVAL;
- break;
- }
-
- spin_unlock_irqrestore(fsl_lbc_lock, flags);
-
- return ret;
-}
+extern int fsl_upm_run_pattern(struct fsl_upm *upm, void __iomem *io_base,
+ u32 mar);
#endif /* __ASM_FSL_LBC_H */
diff --git a/arch/powerpc/sysdev/fsl_lbc.c b/arch/powerpc/sysdev/fsl_lbc.c
index 422c8fa..d81297c 100644
--- a/arch/powerpc/sysdev/fsl_lbc.c
+++ b/arch/powerpc/sysdev/fsl_lbc.c
@@ -13,6 +13,7 @@
#include linux/kernel.h
#include linux/of.h
+#include linux/spinlock.h
#include asm/fsl_lbc.h
spinlock_t fsl_lbc_lock = __SPIN_LOCK_UNLOCKED(fsl_lbc_lock);
@@ -127,3 +128,43 @@ int fsl_upm_find(phys_addr_t addr_base, struct fsl_upm
*upm)
return 0;
}
EXPORT_SYMBOL(fsl_upm_find);
+
+/**
+ * fsl_upm_run_pattern - actually run an UPM pattern
+ * @upm: pointer to the fsl_upm structure obtained via fsl_upm_find
+ * @io_base: remapped pointer to where memory access should happen
+ * @mar: MAR register content during pattern execution
+ *
+ * This function triggers dummy write to the memory specified by the io_base,
+ * thus UPM pattern actually executed. Note that mar usage depends on the
+ * pre-programmed AMX bits in the UPM RAM.
+ */
+int fsl_upm_run_pattern(struct fsl_upm *upm, void __iomem *io_base, u32 mar)
+{
+ int ret = 0;
+ unsigned long flags;
+
+ spin_lock_irqsave(fsl_lbc_lock, flags);
+
+ out_be32(fsl_lbc_regs-mar, mar (32 - upm-width));
+
+ switch (upm-width) {
+ case 8:
+ out_8(io_base, 0x0);
+ break;
+ case 16:
+ out_be16(io_base, 0x0);
+ break;
+ case 32:
+ out_be32(io_base, 0x0);
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+
+ spin_unlock_irqrestore(fsl_lbc_lock, flags);
+
+ return ret;
+}
Re: fsl_upm compile failure.
On Thu, Oct 09, 2008 at 03:02:19AM +0400, Anton Vorontsov wrote:
Though better option would be to uninline the fsl_upm_run_pattern()..
it is quite big anyway... Something like this:
Even better. We don't need exported fsl_lbc_regs too. And also we can
mark the lock and regs as static. Yeah, w/o inline things look much
better.
diff --git a/arch/powerpc/include/asm/fsl_lbc.h
b/arch/powerpc/include/asm/fsl_lbc.h
index 303f548..375f46c 100644
--- a/arch/powerpc/include/asm/fsl_lbc.h
+++ b/arch/powerpc/include/asm/fsl_lbc.h
@@ -24,7 +24,6 @@
#define __ASM_FSL_LBC_H
#include linux/types.h
-#include linux/spinlock.h
#include asm/io.h
struct fsl_lbc_bank {
@@ -227,9 +226,6 @@ struct fsl_lbc_regs {
u8 res8[0xF00];
};
-extern struct fsl_lbc_regs __iomem *fsl_lbc_regs;
-extern spinlock_t fsl_lbc_lock;
-
/*
* FSL UPM routines
*/
@@ -268,44 +264,7 @@ static inline void fsl_upm_end_pattern(struct fsl_upm *upm)
cpu_relax();
}
-/**
- * fsl_upm_run_pattern - actually run an UPM pattern
- * @upm: pointer to the fsl_upm structure obtained via fsl_upm_find
- * @io_base: remapped pointer to where memory access should happen
- * @mar: MAR register content during pattern execution
- *
- * This function triggers dummy write to the memory specified by the io_base,
- * thus UPM pattern actually executed. Note that mar usage depends on the
- * pre-programmed AMX bits in the UPM RAM.
- */
-static inline int fsl_upm_run_pattern(struct fsl_upm *upm,
- void __iomem *io_base, u32 mar)
-{
- int ret = 0;
- unsigned long flags;
-
- spin_lock_irqsave(fsl_lbc_lock, flags);
-
- out_be32(fsl_lbc_regs-mar, mar (32 - upm-width));
-
- switch (upm-width) {
- case 8:
- out_8(io_base, 0x0);
- break;
- case 16:
- out_be16(io_base, 0x0);
- break;
- case 32:
- out_be32(io_base, 0x0);
- break;
- default:
- ret = -EINVAL;
- break;
- }
-
- spin_unlock_irqrestore(fsl_lbc_lock, flags);
-
- return ret;
-}
+extern int fsl_upm_run_pattern(struct fsl_upm *upm, void __iomem *io_base,
+ u32 mar);
#endif /* __ASM_FSL_LBC_H */
diff --git a/arch/powerpc/sysdev/fsl_lbc.c b/arch/powerpc/sysdev/fsl_lbc.c
index 422c8fa..cb4f570 100644
--- a/arch/powerpc/sysdev/fsl_lbc.c
+++ b/arch/powerpc/sysdev/fsl_lbc.c
@@ -13,12 +13,12 @@
#include linux/kernel.h
#include linux/of.h
+#include linux/spinlock.h
#include asm/fsl_lbc.h
-spinlock_t fsl_lbc_lock = __SPIN_LOCK_UNLOCKED(fsl_lbc_lock);
+static spinlock_t fsl_lbc_lock = __SPIN_LOCK_UNLOCKED(fsl_lbc_lock);
-struct fsl_lbc_regs __iomem *fsl_lbc_regs;
-EXPORT_SYMBOL(fsl_lbc_regs);
+static struct fsl_lbc_regs __iomem *fsl_lbc_regs;
static char __initdata *compat_lbc[] = {
fsl,pq2-localbus,
@@ -127,3 +127,43 @@ int fsl_upm_find(phys_addr_t addr_base, struct fsl_upm
*upm)
return 0;
}
EXPORT_SYMBOL(fsl_upm_find);
+
+/**
+ * fsl_upm_run_pattern - actually run an UPM pattern
+ * @upm: pointer to the fsl_upm structure obtained via fsl_upm_find
+ * @io_base: remapped pointer to where memory access should happen
+ * @mar: MAR register content during pattern execution
+ *
+ * This function triggers dummy write to the memory specified by the io_base,
+ * thus UPM pattern actually executed. Note that mar usage depends on the
+ * pre-programmed AMX bits in the UPM RAM.
+ */
+int fsl_upm_run_pattern(struct fsl_upm *upm, void __iomem *io_base, u32 mar)
+{
+ int ret = 0;
+ unsigned long flags;
+
+ spin_lock_irqsave(fsl_lbc_lock, flags);
+
+ out_be32(fsl_lbc_regs-mar, mar (32 - upm-width));
+
+ switch (upm-width) {
+ case 8:
+ out_8(io_base, 0x0);
+ break;
+ case 16:
+ out_be16(io_base, 0x0);
+ break;
+ case 32:
+ out_be32(io_base, 0x0);
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+
+ spin_unlock_irqrestore(fsl_lbc_lock, flags);
+
+ return ret;
+}
+EXPORT_SYMBOL(fsl_upm_run_pattern);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: fsl_upm compile failure.
On Thu, Oct 09, 2008 at 03:02:19AM +0400, Anton Vorontsov wrote: Hi, On Wed, Oct 08, 2008 at 06:28:15PM -0400, Dave Jones wrote: Hi Anton, I tried reenabling CONFIG_MTD_NAND_FSL_UPM in the Fedora kernel today (currently on 2.6.27-rc9-git1), and got the error below. ERROR: fsl_lbc_lock [drivers/mtd/nand/fsl_upm.ko] undefined! Weird. It works for me with mpc836x_rdk_defconfig and MTD_NAND_FSL_UPM=m... Hm.. CC drivers/mtd/nand/fsl_upm.mod.o LD [M] drivers/mtd/nand/fsl_upm.ko Can you send me the .config file you use? http://davej.fedorapeople.org/ppc.config But the patch looks obviously correct. Much thanks for catching this. Though better option would be to uninline the fsl_upm_run_pattern().. it is quite big anyway... Something like this: I'll leave it to you to decide what to push to Linus Dave -- http://www.codemonkey.org.uk ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Sync RPA note in zImage with kernel's RPA note
Commit 9b09c6d909dfd8de96b99b9b9c808b94b0a71614 (powerpc: Change the
default link address for pSeries zImage kernels) changed the
real-base value in the CHRP note added by the addnote program from
12MB to 32MB to give more space for Open Firmware to load the zImage.
(The real-base value says where we want OF to position itself in
memory.) However, this change was ineffective on most pSeries
machines, because the RPA note added by addnote has the ignore me
flag set to 1. This was intended to tell OF to ignore just the RPA
note, but has the side effect of also making OF ignore the CHRP note
(at least on most pSeries machines).
To solve this we have to set the ignore me flag to 0 in the RPA
note. (We can't just omit the RPA note because that is equivalent to
having an RPA note with default values, and the default values are not
what we want.) However, then we have to make sure the values in the
zImage's RPA note match up with the values that the kernel supplies
later in prom_init.c with either the ibm,client-architecture-support
call or the process-elf-header call in prom_send_capabilities().
So this sets the ignore me flag in the RPA note in addnote to 0, and
adjusts the RPA note values in addnote.c and in prom_init.c to be
consistent with each other and with the values in ibm_architecture_vec.
However, since the wrapper is independent of the kernel, this doesn't
ensure that the notes will stay consistent. To ensure that, this adds
code to addnote.c so that it can extract the kernel's RPA note from
the kernel binary and put that in the zImage. To that end, we put the
kernel's fake ELF header (which contains the kernel's RPA note) into
its own section, and arrange for wrapper to pull out that section with
objcopy and pass it to addnote, which then extracts the RPA note from
it and transfers it to the zImage.
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
---
diff --git a/arch/powerpc/boot/addnote.c b/arch/powerpc/boot/addnote.c
index b1e5611..dcc9ab2 100644
--- a/arch/powerpc/boot/addnote.c
+++ b/arch/powerpc/boot/addnote.c
@@ -11,7 +11,12 @@
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*
- * Usage: addnote zImage
+ * Usage: addnote zImage [note.elf]
+ *
+ * If note.elf is supplied, it is the name of an ELF file that contains
+ * an RPA note to use instead of the built-in one. Alternatively, the
+ * note.elf file may be empty, in which case the built-in RPA note is
+ * used (this is to simplify how this is invoked from the wrapper script).
*/
#include stdio.h
#include stdlib.h
@@ -43,27 +48,29 @@ char rpaname[] = IBM,RPA-Client-Config;
*/
#define N_RPA_DESCR8
unsigned int rpanote[N_RPA_DESCR] = {
- 0, /* lparaffinity */
- 64, /* min_rmo_size */
+ 1, /* lparaffinity */
+ 128,/* min_rmo_size */
0, /* min_rmo_percent */
- 40, /* max_pft_size */
+ 46, /* max_pft_size */
1, /* splpar */
-1, /* min_load */
- 0, /* new_mem_def */
- 1, /* ignore_my_client_config */
+ 1, /* new_mem_def */
+ 0, /* ignore_my_client_config */
};
#define ROUNDUP(len) (((len) + 3) ~3)
unsigned char buf[512];
+unsigned char notebuf[512];
-#define GET_16BE(off) ((buf[off] 8) + (buf[(off)+1]))
-#define GET_32BE(off) ((GET_16BE(off) 16) + GET_16BE((off)+2))
+#define GET_16BE(b, off) (((b)[off] 8) + ((b)[(off)+1]))
+#define GET_32BE(b, off) ((GET_16BE((b), (off)) 16) + \
+GET_16BE((b), (off)+2))
-#define PUT_16BE(off, v) (buf[off] = ((v) 8) 0xff, \
-buf[(off) + 1] = (v) 0xff)
-#define PUT_32BE(off, v) (PUT_16BE((off), (v) 16), \
-PUT_16BE((off) + 2, (v)))
+#define PUT_16BE(b, off, v)((b)[off] = ((v) 8) 0xff, \
+(b)[(off) + 1] = (v) 0xff)
+#define PUT_32BE(b, off, v)(PUT_16BE((b), (off), (v) 16), \
+PUT_16BE((b), (off) + 2, (v)))
/* Structure of an ELF file */
#define E_IDENT0 /* ELF header */
@@ -88,15 +95,71 @@ unsigned char buf[512];
unsigned char elf_magic[4] = { 0x7f, 'E', 'L', 'F' };
+unsigned char *read_rpanote(const char *fname, int *nnp)
+{
+ int notefd, nr, i;
+ int ph, ps, np;
+ int note, notesize;
+
+ notefd = open(fname, O_RDONLY);
+ if (notefd 0) {
+ perror(fname);
+ exit(1);
+ }
+ nr = read(notefd, notebuf, sizeof(notebuf));
+ if (nr 0) {
+ perror(read note);
+ exit(1);
+ }
+ if (nr == 0)/* empty file */
+
Re: 8600 serial support
On Thu, Oct 09, 2008 at 07:45:11AM +1100, Benjamin Herrenschmidt wrote: Yes, it's not totally trivial and I wouldn't recommend using the weirdo code in macserial (it does things that I don't understand how they work with the dbdma engine). The best way I see is to start from scratch with two different mechanisms: - For Tx, that's the easiest, the fire off DMA's for outgoing chars, maybe queue up a few descriptors to let data accumulate. - For Rx, one descriptor per byte. That sucks but I think that's also what Apple does. No need to have a huge Rx buffer anyway. That gives you precise Rx status to the byte. I know it's not really in the scope of the discussion, but do you have any suggestions for how we might support this with AMIC or PSC DMA where we can't have an arbitrary number of in-flight commands? There hasn't been a lot of traction on getting the non-PCI macs working again, but that is something that may happen eventually. It would be nice to have similar designs for both the descriptor based and register driven DMA engines, but I definitely understand if you think that's not realistic. It seems to me that an interrupt per-byte (which this design would imply on the older DMA engines) would make the DMA less useful. Brad Boyer [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: fix fsl_upm nand driver modular build
The fsl_upm nand driver fails to build because fsl_lbc_lock isn't
exported, the lock is needed by the inlined fsl_upm_run_pattern()
function:
ERROR: fsl_lbc_lock [drivers/mtd/nand/fsl_upm.ko] undefined!
Dave Jones purposed to export the lock, but it is better to just uninline
the fsl_upm_run_pattern().
When uninlined we also no longer need the exported fsl_lbc_regs, and
both fsl_lbc_lock and fsl_lbc_regs could be marked static.
While at it, also add some missing includes that we should have included
explicitly.
Reported-by: Dave Jones [EMAIL PROTECTED]
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
On Wed, Oct 08, 2008 at 07:33:06PM -0400, Dave Jones wrote:
[...]
ERROR: fsl_lbc_lock [drivers/mtd/nand/fsl_upm.ko] undefined!
Weird. It works for me with mpc836x_rdk_defconfig and
MTD_NAND_FSL_UPM=m...
Hm..
CC drivers/mtd/nand/fsl_upm.mod.o
LD [M] drivers/mtd/nand/fsl_upm.ko
Can you send me the .config file you use?
http://davej.fedorapeople.org/ppc.config
Still works here. :-/ I'm using latest Linus' git tree, pulled few
minutes ago just in case.
gcc version 4.2.0 (MontaVista 4.2.0-16.0.20.0800760 2008-04-05)
GNU ld (GNU Binutils) 2.17.50.20070611
Most probably something on my side, maybe need to update the toolchain.
But the patch looks obviously correct. Much thanks for catching this.
Though better option would be to uninline the fsl_upm_run_pattern()..
it is quite big anyway... Something like this:
I'll leave it to you to decide what to push to Linus
Ok, here it is. Since I'm unable to reproduce the error, I'd
appreciate Tested-by: tag if you could find time to build-test
the patch. It works for me though...
Thanks again,
arch/powerpc/include/asm/fsl_lbc.h | 48 +++-
arch/powerpc/sysdev/fsl_lbc.c | 53 +---
2 files changed, 53 insertions(+), 48 deletions(-)
diff --git a/arch/powerpc/include/asm/fsl_lbc.h
b/arch/powerpc/include/asm/fsl_lbc.h
index 303f548..63a4f77 100644
--- a/arch/powerpc/include/asm/fsl_lbc.h
+++ b/arch/powerpc/include/asm/fsl_lbc.h
@@ -23,9 +23,9 @@
#ifndef __ASM_FSL_LBC_H
#define __ASM_FSL_LBC_H
+#include linux/compiler.h
#include linux/types.h
-#include linux/spinlock.h
-#include asm/io.h
+#include linux/io.h
struct fsl_lbc_bank {
__be32 br; /** Base Register */
@@ -227,9 +227,6 @@ struct fsl_lbc_regs {
u8 res8[0xF00];
};
-extern struct fsl_lbc_regs __iomem *fsl_lbc_regs;
-extern spinlock_t fsl_lbc_lock;
-
/*
* FSL UPM routines
*/
@@ -268,44 +265,7 @@ static inline void fsl_upm_end_pattern(struct fsl_upm *upm)
cpu_relax();
}
-/**
- * fsl_upm_run_pattern - actually run an UPM pattern
- * @upm: pointer to the fsl_upm structure obtained via fsl_upm_find
- * @io_base: remapped pointer to where memory access should happen
- * @mar: MAR register content during pattern execution
- *
- * This function triggers dummy write to the memory specified by the io_base,
- * thus UPM pattern actually executed. Note that mar usage depends on the
- * pre-programmed AMX bits in the UPM RAM.
- */
-static inline int fsl_upm_run_pattern(struct fsl_upm *upm,
- void __iomem *io_base, u32 mar)
-{
- int ret = 0;
- unsigned long flags;
-
- spin_lock_irqsave(fsl_lbc_lock, flags);
-
- out_be32(fsl_lbc_regs-mar, mar (32 - upm-width));
-
- switch (upm-width) {
- case 8:
- out_8(io_base, 0x0);
- break;
- case 16:
- out_be16(io_base, 0x0);
- break;
- case 32:
- out_be32(io_base, 0x0);
- break;
- default:
- ret = -EINVAL;
- break;
- }
-
- spin_unlock_irqrestore(fsl_lbc_lock, flags);
-
- return ret;
-}
+extern int fsl_upm_run_pattern(struct fsl_upm *upm, void __iomem *io_base,
+ u32 mar);
#endif /* __ASM_FSL_LBC_H */
diff --git a/arch/powerpc/sysdev/fsl_lbc.c b/arch/powerpc/sysdev/fsl_lbc.c
index 422c8fa..0494ee5 100644
--- a/arch/powerpc/sysdev/fsl_lbc.c
+++ b/arch/powerpc/sysdev/fsl_lbc.c
@@ -11,14 +11,19 @@
* (at your option) any later version.
*/
+#include linux/init.h
+#include linux/module.h
#include linux/kernel.h
+#include linux/compiler.h
+#include linux/spinlock.h
+#include linux/types.h
+#include linux/io.h
#include linux/of.h
+#include asm/prom.h
#include asm/fsl_lbc.h
-spinlock_t fsl_lbc_lock = __SPIN_LOCK_UNLOCKED(fsl_lbc_lock);
-
-struct fsl_lbc_regs __iomem *fsl_lbc_regs;
-EXPORT_SYMBOL(fsl_lbc_regs);
+static spinlock_t fsl_lbc_lock = __SPIN_LOCK_UNLOCKED(fsl_lbc_lock);
+static struct fsl_lbc_regs __iomem *fsl_lbc_regs;
static char __initdata *compat_lbc[] = {
fsl,pq2-localbus,
@@ -127,3 +132,43 @@ int fsl_upm_find(phys_addr_t addr_base, struct fsl_upm
*upm)
return 0;
}
Re: 8600 serial support
Benjamin Herrenschmidt wrote: On Wed, 2008-10-08 at 12:51 -0700, Kevin Diggs wrote: Hi, I thought I might take a whack at fixing the 2.6 serial driver for my 8600. At the top of pmac_zilog.c (2.6.26) there is a todo for DMA. A quick glance at macserial.c (2.4.31) suggests it has dbdma support for receive. Anyone know of any pitfalls for adding dbdma support for pmac_zilog.c? Yes, it's not totally trivial and I wouldn't recommend using the weirdo code in macserial (it does things that I don't understand how they work with the dbdma engine). The best way I see is to start from scratch with two different mechanisms: - For Tx, that's the easiest, the fire off DMA's for outgoing chars, maybe queue up a few descriptors to let data accumulate. - For Rx, one descriptor per byte. That sucks but I think that's also what Apple does. No need to have a huge Rx buffer anyway. That gives you precise Rx status to the byte. Ben. Does the 8530 (as implemented in the PowerMac ASICs) have a receive buffer like the 16550? Any pointers to some good dbdma example code? Anyone know where one might find some 8530 docs? This driver should work for ppp without receive dma, right? One descriptor per byte??? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: performance: memcpy vs. __copy_tofrom_user
Scott Wood writes: I'm not sure why we don't use dcbt in memcpy(), as it's just ignored if the memory is cache-inhibited. Both dcbt and dcbz tend to slow things down if the relevant block is already in the cache. Since the kernel memcpy is mostly used for copies that are only 1 or a small number of cache lines long, it's not clear that the benefit of dcbt and/or dcbz would outweigh the cost. And anyway, I have yet to be convinced that optimizing memcpy would provide a measureable benefit. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix error path in kernel_thread function
Josh Boyer writes: From: Josh Poimboeuf [EMAIL PROTECTED] The powerpc 32-bit and 64-bit kernel_thread functions don't properly propagate errors being returned by the clone syscall. (In the case of error, the syscall exit code returns a positive errno in r3 and sets the CR0[SO] bit.) This patch fixes that by negating r3 if CR0[SO] is set after the syscall. Signed-off-by: Josh Poimboeuf [EMAIL PROTECTED] Signed-off-by: Josh Boyer [EMAIL PROTECTED] Acked-by: Paul Mackerras [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Support for relocatable kdump kernel
Mohan Kumar M writes: Support for relocatable kdump kernel [snip] @@ -1384,7 +1392,15 @@ _STATIC(__after_prom_start) /* process relocations for the final address of the kernel */ lis r25,[EMAIL PROTECTED] /* compute virtual base of kernel */ sldir25,r25,32 - mr r3,r25 +#ifdef CONFIG_CRASH_DUMP + ld r7,[EMAIL PROTECTED](r2) + add r7,r7,r26 + ld r7,0(r7) I think it is dangerous to use an address from the GOT at this point when we haven't called relocate() yet. In fact those 3 instructions can be replaced by one: ld r7,__kdump_flag-_stext(r26) since we have our base address (i.e. the address of _stext) in r26 at this point. +#ifdef CONFIG_RELOCATABLE +#ifdef CONFIG_CRASH_DUMP +/* + * Check if the kernel has to be running as relocatable kernel based on the + * variable __kdump_flag, if it is set the kernel is treated as relocatble + * kernel, otherwise it will be moved to PHYSICAL_START + */ + ld r7,[EMAIL PROTECTED](r2) + ld r7,0(r7) Here again I would rather you did ld r7,__kdump_flag-_stext(r26) since the kernel is relocated for its final location by this point, but it is not running at the final location yet. + cmpldi cr0,r7,1 + bne regular + + li r5,__end_interrupts - _stext/* just copy interrupts */ + b 5f +regular: +#endif + lis r5,(copy_to_here - _stext)@ha + addir5,r5,(copy_to_here - _stext)@l /* # bytes of memory to copy */ bl .copy_and_flush /* copy the first n bytes*/ /* this includes the code being */ @@ -1411,15 +1443,33 @@ _STATIC(__after_prom_start) mtctr r8 bctr +p_end: .llong _end - _stext + 4: /* Now copy the rest of the kernel up to _end */ addis r5,r26,(p_end - _stext)@ha ld r5,(p_end - _stext)@l(r5) /* get _end */ - bl .copy_and_flush /* copy the rest */ +#else + lis r5,(copy_to_here - _stext)@ha + addir5,r5,(copy_to_here - _stext)@l /* # bytes of memory to copy */ -9: b .start_here_multiplatform + bl .copy_and_flush /* copy the first n bytes*/ + /* this includes the code being */ + /* executed here.*/ + addis r8,r3,(4f - _stext)@ha /* Jump to the copy of this code */ + addir8,r8,(4f - _stext)@l /* that we just made */ + mtctr r8 + bctr p_end: .llong _end - _stext +4: /* Now copy the rest of the kernel up to _end */ + addis r5,r26,(p_end - _stext)@ha + ld r5,(p_end - _stext)@l(r5) /* get _end */ +#endif +5: bl .copy_and_flush /* copy the rest */ + +9: b .start_here_multiplatform You have ended up with two separate copies of the code here depending on whether or not we have CONFIG_RELOCATABLE set. I don't think the code paths should be different to such an extent. Please try to make the ifdef as small as possible (ideally, nonexistent). Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix kdump kernel hang issue with relocatable kernel patches
Mohan Kumar M writes: One of the relocatable kernel support patches assumes that the target address will be 0. But for kdump kernels (without relocation support) it will be 32MB. The following patch fixes this issue. Fix kdump kernel issue Kdump kernel without relocation support needs to be moved to PHYSICAL_START (ie 32MB) instead of 0. This patch fixes this issue. Hmmm. Is there any reason to continue to support non-relocatable 64-bit kernels being kdump kernels? In other words, for 64-bit, couldn't we make CONFIG_CRASH_DUMP depend on CONFIG_RELOCATABLE? I don't think we want to try to support two different modes of operation for a kdump kernel, and I don't see any value in continuing to support PHYSICAL_START 0 for 64-bit non-relocatable kernels. (And when we can make 32-bit PIE kernels, I'll be making the same statement about 32-bit. :) Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
