Please pull linux-2.6-mpc52xx.git
Paul, here is a bug fix that needs to go in for 2.6.25. Thanks, g. The following changes since commit 42e6de0e6079f4a7ce6bd62340b1b14a1af314dc: Oliver Pinter (1): fix vmsas.c file permissions are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-mpc52xx.git for-2.6.25 Eric Dujardin (1): [POWERPC] Add export for mpc52xx_set_psc_clkdiv arch/powerpc/platforms/52xx/mpc52xx_common.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) -- 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
Please pull linux-2.6-mpc52xx.git
The following changes since commit 6c39103ce5192bdb2195f3daab7323dfa44fb52e: Zhang Wei (1): [RAPIDIO] Change RapidIO doorbell source and target ID field to 16-bit are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-mpc52xx.git for-2.6.26 Bartlomiej Sieka (1): [POWERPC] mpc5200: defconfigs for CM5200, Lite5200B, Motion-PRO and TQM5200 Grant Likely (2): [POWERPC] mpc5200: Fix unterminated of_device_id table [POWERPC] mpc5200: Switch mpc5200 dts files to dts-v1 format Sascha Hauer (2): [POWERPC] mpc5200: add interrupt type function [POWERPC] mpc5200: Fix FEC error handling on FIFO errors [EMAIL PROTECTED] (2): [POWERPC] mpc5200: add gpiolib support for mpc5200 [POWERPC] mpc5200: add Phytec pcm030 board support .../powerpc/mpc52xx-device-tree-bindings.txt | 12 + arch/powerpc/boot/dts/cm5200.dts | 98 +- arch/powerpc/boot/dts/lite5200.dts | 132 ++-- arch/powerpc/boot/dts/lite5200b.dts| 146 ++-- arch/powerpc/boot/dts/motionpro.dts| 118 +- arch/powerpc/boot/dts/pcm030.dts | 363 ++ arch/powerpc/boot/dts/tqm5200.dts | 80 +- arch/powerpc/configs/52xx/cm5200_defconfig | 1099 ++ arch/powerpc/configs/52xx/lite5200b_defconfig | 1049 + arch/powerpc/configs/52xx/motionpro_defconfig | 1107 ++ arch/powerpc/configs/52xx/pcm030_defconfig | 1115 ++ arch/powerpc/configs/52xx/tqm5200_defconfig| 1214 arch/powerpc/platforms/52xx/Kconfig|6 + arch/powerpc/platforms/52xx/Makefile |2 + arch/powerpc/platforms/52xx/mpc5200_simple.c |1 + arch/powerpc/platforms/52xx/mpc52xx_gpio.c | 465 arch/powerpc/platforms/52xx/mpc52xx_pic.c | 38 + drivers/net/fec_mpc52xx.c | 23 +- drivers/serial/mpc52xx_uart.c |2 +- 19 files changed, 6771 insertions(+), 299 deletions(-) create mode 100644 arch/powerpc/boot/dts/pcm030.dts create mode 100644 arch/powerpc/configs/52xx/cm5200_defconfig create mode 100644 arch/powerpc/configs/52xx/lite5200b_defconfig create mode 100644 arch/powerpc/configs/52xx/motionpro_defconfig create mode 100644 arch/powerpc/configs/52xx/pcm030_defconfig create mode 100644 arch/powerpc/configs/52xx/tqm5200_defconfig create mode 100644 arch/powerpc/platforms/52xx/mpc52xx_gpio.c -- 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
Please pull linux-2.6-mpc52xx.git
Paul, here's a couple more for 2.6.26. One bug fix and one minor change that I've had on the back burner for a month or so. This should be the last of any non-bugfix changes through my tree. Cheers, g. git-request-pull powerpc git://git.secretlab.ca/git/linux-2.6-mpc52xx.git The following changes since commit eabd90944b3a00766e84da3d117ea0f3e0a3b1a3: Michael Ellerman (1): [POWERPC] Fix crashkernel= handling when no crashkernel= specified are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-mpc52xx.git for-2.6.26 Andrew Liu (1): Fix a potential issue in mpc52xx uart driver Grant Likely (1): [POWERPC] mpc5200: Allow for fixed speed MII configurations .../powerpc/mpc52xx-device-tree-bindings.txt | 11 ++ drivers/net/fec_mpc52xx.c | 97 +++- drivers/net/fec_mpc52xx.h | 19 drivers/serial/mpc52xx_uart.c |2 + 4 files changed, 87 insertions(+), 42 deletions(-) -- 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
Please pull linux-2.6-mpc52xx.git
Paulus, Sylvain has asked if I would like to help with the mpc52xx maintainership. If it's okay by you, here is a patch that adds me as co-maintainer for the mpc52xx platform along with 3 other mpc52xx related fixes. Sylvain, can you please reply to this message confirming that this is what we talked about? Thanks, g. The following changes since commit dcccb37e98e0444b0c6a03b303855771aa463c96: Grant Likely (1): [POWERPC] Lite5200: Use comma delimiter format for lists in device tree are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-mpc52xx.git for-2.6.24 Grant Likely (4): [POWERPC] MPC52xx: Drop show_cpuinfo platform hooks from Lite5200 [POWERPC] MPC52xx: Trim includes on mpc5200 platform support code [POWERPC] MPC5200: Don't make firmware fixups into common code [POWERPC] Add co-maintainer for PowerPC MPC52xx platform MAINTAINERS |2 + arch/powerpc/platforms/52xx/efika.c | 19 +- arch/powerpc/platforms/52xx/lite5200.c | 95 ++ arch/powerpc/platforms/52xx/mpc52xx_common.c | 38 --- arch/powerpc/platforms/52xx/mpc52xx_pic.c| 11 +--- include/asm-powerpc/mpc52xx.h|2 +- 6 files changed, 68 insertions(+), 99 deletions(-) -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull linux-2.6-mpc52xx.git
Paul, Here is the addition of the bestcomm driver. I think this is ready to go in. There are remaining outstanding comments; but my opinion is that they should be addressed in subsequent patches (performance optimization for mp5200b boards and making the sram management code a generic interface usable by other SoC support code). If you agree; please pull into your tree. The following changes since commit 65a6ec0d72a07f16719e9b7a96e1c4bae044b591: Linus Torvalds (1): Merge branch 'devel' of master.kernel.org:/home/rmk/linux-2.6-arm are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-mpc52xx.git for-2.6.24 Domen Puncer (1): [POWERPC] mpc52xx: device tree changes for FEC and MDIO Sylvain Munaut (7): [POWERPC] exports rheap symbol to modules [POWERPC] rheap: Changes config mechanism [POWERPC] mpc52xx: Update mpc52xx_psc structure with B revision changes [POWERPC] bestcomm: core bestcomm support for Freescale MPC5200 [POWERPC] bestcomm: ATA task support [POWERPC] bestcomm: FEC task support [POWERPC] bestcomm: GenBD task support arch/powerpc/Kconfig |4 + arch/powerpc/boot/dts/lite5200b.dts| 18 +- arch/powerpc/lib/Makefile |5 +- arch/powerpc/lib/rheap.c | 15 + arch/powerpc/platforms/Kconfig |4 + arch/powerpc/platforms/Kconfig.cputype |1 + arch/powerpc/sysdev/Makefile |1 + arch/powerpc/sysdev/bestcomm/Kconfig | 39 ++ arch/powerpc/sysdev/bestcomm/Makefile | 14 + arch/powerpc/sysdev/bestcomm/ata.c | 154 ++ arch/powerpc/sysdev/bestcomm/ata.h | 37 ++ arch/powerpc/sysdev/bestcomm/bcom_ata_task.c | 67 +++ arch/powerpc/sysdev/bestcomm/bcom_fec_rx_task.c| 78 +++ arch/powerpc/sysdev/bestcomm/bcom_fec_tx_task.c| 91 arch/powerpc/sysdev/bestcomm/bcom_gen_bd_rx_task.c | 63 +++ arch/powerpc/sysdev/bestcomm/bcom_gen_bd_tx_task.c | 69 +++ arch/powerpc/sysdev/bestcomm/bestcomm.c| 528 arch/powerpc/sysdev/bestcomm/bestcomm.h| 190 +++ arch/powerpc/sysdev/bestcomm/bestcomm_priv.h | 334 + arch/powerpc/sysdev/bestcomm/fec.c | 270 ++ arch/powerpc/sysdev/bestcomm/fec.h | 61 +++ arch/powerpc/sysdev/bestcomm/gen_bd.c | 260 ++ arch/powerpc/sysdev/bestcomm/gen_bd.h | 48 ++ arch/powerpc/sysdev/bestcomm/sram.c| 177 +++ arch/powerpc/sysdev/bestcomm/sram.h| 54 ++ arch/ppc/Kconfig |6 + include/asm-ppc/mpc52xx_psc.h | 10 +- 27 files changed, 2591 insertions(+), 7 deletions(-) create mode 100644 arch/powerpc/sysdev/bestcomm/Kconfig create mode 100644 arch/powerpc/sysdev/bestcomm/Makefile create mode 100644 arch/powerpc/sysdev/bestcomm/ata.c create mode 100644 arch/powerpc/sysdev/bestcomm/ata.h create mode 100644 arch/powerpc/sysdev/bestcomm/bcom_ata_task.c create mode 100644 arch/powerpc/sysdev/bestcomm/bcom_fec_rx_task.c create mode 100644 arch/powerpc/sysdev/bestcomm/bcom_fec_tx_task.c create mode 100644 arch/powerpc/sysdev/bestcomm/bcom_gen_bd_rx_task.c create mode 100644 arch/powerpc/sysdev/bestcomm/bcom_gen_bd_tx_task.c create mode 100644 arch/powerpc/sysdev/bestcomm/bestcomm.c create mode 100644 arch/powerpc/sysdev/bestcomm/bestcomm.h create mode 100644 arch/powerpc/sysdev/bestcomm/bestcomm_priv.h create mode 100644 arch/powerpc/sysdev/bestcomm/fec.c create mode 100644 arch/powerpc/sysdev/bestcomm/fec.h create mode 100644 arch/powerpc/sysdev/bestcomm/gen_bd.c create mode 100644 arch/powerpc/sysdev/bestcomm/gen_bd.h create mode 100644 arch/powerpc/sysdev/bestcomm/sram.c create mode 100644 arch/powerpc/sysdev/bestcomm/sram.h -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull linux-2.6-mpc52xx.git
Hi Ben and Paulus. Please pull the 'merge' branch of my MPC5200 tree (url below). I've got mpc5200 bug fixes, virtex bug fixes and defconfig updates in it. This all needs to go into 2.6.28. This branch does have both mpc5200 and Xilinx Virtex 4xx changes. I've cleared it with Josh that it is okay to push the 4xx changes out to my tree rather than having him pull it first. The following changes since commit 58e20d8d344b0ee083febb18c2b021d2427e56ca: Linus Torvalds (1): Merge branch 'for-linus' of git://git.kernel.org/.../jbarnes/pci-2.6 are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-mpc52xx merge Grant Likely (4): powerpc/mpc5200: fix bestcomm Kconfig dependencies powerpc/virtex: fix various format/casting printk mismatches powerpc/52xx: update defconfigs powerpc/virtex: Update defconfigs Yuri Tikhonov (1): xsysace: Fix driver to use resource_size_t instead of unsigned long arch/powerpc/configs/40x/virtex_defconfig | 1176 + arch/powerpc/configs/44x/virtex5_defconfig| 234 +++--- arch/powerpc/configs/52xx/cm5200_defconfig| 169 +++- arch/powerpc/configs/52xx/lite5200b_defconfig | 206 -- arch/powerpc/configs/52xx/motionpro_defconfig | 168 +++- arch/powerpc/configs/52xx/pcm030_defconfig| 182 +++-- arch/powerpc/configs/52xx/tqm5200_defconfig | 180 +++- arch/powerpc/configs/mpc5200_defconfig| 573 +--- arch/powerpc/configs/ppc40x_defconfig | 92 ++- arch/powerpc/configs/ppc44x_defconfig | 92 ++- arch/powerpc/sysdev/bestcomm/Kconfig |9 +- arch/powerpc/sysdev/xilinx_intc.c |4 +- drivers/block/xsysace.c | 23 +- drivers/char/xilinx_hwicap/xilinx_hwicap.c|9 +- drivers/net/Kconfig |3 +- drivers/serial/uartlite.c |4 +- drivers/video/xilinxfb.c |5 +- sound/soc/fsl/Kconfig |3 +- 18 files changed, 2617 insertions(+), 515 deletions(-) create mode 100644 arch/powerpc/configs/40x/virtex_defconfig -- 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
Please pull linux-2.6-mpc52xx.git
Hey Ben, Here is my last minute pull request. It's pretty simple stuff all around, mostly in the bug-fix category. One new of_i2c() helper function. Biggest change is the xilinx spi driver; but it doesn't even compile without this. I have not included the media5200 platform support patch because it is a little borderline for so late in the window. Technically the xilinx changes are 4xx patches and would normally go through Josh, but since they only touch Xilinx drivers, and don't affect any other 4xx platforms I'm sending them to you directly. Sorry for the lateness of this pull request, I got mired in board breakage over the last week. Yeah, it's a lame excuse, but it's the one I'm using. The following changes since commit 5886188dc7ba9a76babcd37452f44079a9a77f71: Benjamin Krill (1): serial: Add driver for the Cell Network Processor serial port NWP device are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-mpc52xx next Grant Likely (1): powerpc/mpc52xx: Properly update irq_desc when set_type() is called. John Linn (1): Xilinx: SPI: updated driver for device tree Jon Smirl (1): drivers/of: Add the of_find_i2c_device_by_node function. Wolfram Sang (1): powerpc/mpc52xx: remove dead code from GPIO driver Yuri Tikhonov (1): powerpc/xsysace: add compatible string for non-ipcore instance roel kluin (1): powerpc/mpc5121: fix NULL test in mpc5121_clk_get utility function. arch/powerpc/platforms/512x/clock.c|4 +- arch/powerpc/platforms/52xx/mpc52xx_gpio.c |3 - arch/powerpc/platforms/52xx/mpc52xx_pic.c |8 ++- drivers/block/xsysace.c|1 + drivers/of/of_i2c.c| 19 drivers/spi/xilinx_spi.c | 137 --- include/linux/of_i2c.h |3 + 7 files changed, 113 insertions(+), 62 deletions(-) Thanks, g. -- 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
Fwd: Please pull linux-2.6-mpc52xx.git
(resend; including the mailing list this time) Paul, Please pull my mpc52xx tree. It contains the MPC512x work which John Rigby has been doing. I should have got these out to you sooner, but I forgot about them. :-( Cheers, g. The following changes since commit 99e139126ab2e84be67969650f92eb37c12ab5cd: Michael Ellerman (1): [POWERPC] Cell IOMMU fixed mapping support are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-mpc52xx.git for-2.6.25 John Rigby (4): [POWERPC] mpc512x: Basic platform support [POWERPC] mpc512x: Device tree for MPC5121 ADS [POWERPC] mpc512x: Factor out 5200 dependencies from 52xx psc driver [POWERPC] mpc512x: Add MPC512x PSC support to MPC52xx psc driver arch/powerpc/Kconfig |2 +- arch/powerpc/boot/dts/mpc5121ads.dts | 122 arch/powerpc/platforms/512x/Kconfig | 20 ++ arch/powerpc/platforms/512x/Makefile |4 + arch/powerpc/platforms/512x/mpc5121_ads.c | 104 +++ arch/powerpc/platforms/Kconfig|1 + arch/powerpc/platforms/Kconfig.cputype|6 +- arch/powerpc/platforms/Makefile |1 + drivers/serial/Kconfig| 12 +- drivers/serial/mpc52xx_uart.c | 431 - include/asm-powerpc/mpc512x.h | 22 ++ include/asm-powerpc/mpc52xx_psc.h | 48 12 files changed, 694 insertions(+), 79 deletions(-) create mode 100644 arch/powerpc/boot/dts/mpc5121ads.dts create mode 100644 arch/powerpc/platforms/512x/Kconfig create mode 100644 arch/powerpc/platforms/512x/Makefile create mode 100644 arch/powerpc/platforms/512x/mpc5121_ads.c create mode 100644 include/asm-powerpc/mpc512x.h -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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
Please pull linux-2.6-mpc52xx.git (again!)
On 2/6/08, Grant Likely <[EMAIL PROTECTED]> wrote: > On 2/6/08, Olof Johansson <[EMAIL PROTECTED]> wrote: > > mpc52xx_defconfig no longer builds for me, and the two latter of the > > above patches are the ones that touch that file: > > Gah! I caused some patch damage when I rebased the patches. I'll > send a fixup patch ASAP. Paul, here's the fixup patch for my rebase screwup. This solves the mpc52xx compile failure. The following changes since commit de0723dcca6e593a12a259798a54eb0e82628fb8: Nathan Fontenot (1): [POWERPC] Update default irq servers when boot cpu is removed are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-mpc52xx.git for-2.6.25 Grant Likely (1): [POWERPC] mpc52xx: fix compile error introduce when rebasing patch drivers/serial/mpc52xx_uart.c | 39 ++- 1 files changed, 14 insertions(+), 25 deletions(-) -- 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: Please pull linux-2.6-mpc52xx.git
On Mon, Mar 17, 2008 at 9:57 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote: > Grant Likely wrote: > > Paul, here is a bug fix that needs to go in for 2.6.25. > > Hi Grant, > > What is the status of the various MPC5200-related patches (support for > TQM5200, CM5200 and Motion-PRO boards, few drivers, etc) posted some > time ago by Marian Balakowicz? There's been some comments to the patches > on the list, which were addressed and no further discussion occurred, so > we were hoping that the changes would go upstream (in 2.6.25). I can see > that the .dts files for those boards are in the mainline already, but I > see no trace of for example _defconfig files -- could you shed some > light on this? Yes, the separate dts files have been dropped in preference for a single mpc5200_defconfig for all 5200 boards. Cheers, g. -- 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: Please pull linux-2.6-mpc52xx.git
In message <[EMAIL PROTECTED]> you wrote: > > > What is the status of the various MPC5200-related patches (support for > > TQM5200, CM5200 and Motion-PRO boards, few drivers, etc) posted some > > time ago by Marian Balakowicz? There's been some comments to the patches > > on the list, which were addressed and no further discussion occurred, so > > we were hoping that the changes would go upstream (in 2.6.25). I can see > > that the .dts files for those boards are in the mainline already, but I > > see no trace of for example _defconfig files -- could you shed some > > light on this? > > Yes, the separate dts files have been dropped in preference for a > single mpc5200_defconfig for all 5200 boards. I know that my opinion doesn't matter but that's a stupid thing to do. Do you think that this single mpc5200_defconfig will (a) work and (b) be useful on all 5200 boards? Who hast tested it, and on which platforms? And what about the other patches? I see no code for these boards in arch/powerpc/platforms/52xx/ ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] Minds are like parachutes - they only function when open. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
On Mon, Mar 17, 2008 at 2:59 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote: > In message <[EMAIL PROTECTED]> you wrote: > > > > > What is the status of the various MPC5200-related patches (support for > > > TQM5200, CM5200 and Motion-PRO boards, few drivers, etc) posted some > > > time ago by Marian Balakowicz? There's been some comments to the patches > > > on the list, which were addressed and no further discussion occurred, so > > > we were hoping that the changes would go upstream (in 2.6.25). I can see > > > that the .dts files for those boards are in the mainline already, but I > > > see no trace of for example _defconfig files -- could you shed some > > > light on this? > > > > Yes, the separate dts files have been dropped in preference for a > > single mpc5200_defconfig for all 5200 boards. > > I know that my opinion doesn't matter but that's a stupid thing to ^ Bull. You know better than that. > do. Do you think that this single mpc5200_defconfig will (a) work and > (b) be useful on all 5200 boards? Who hast tested it, and on which > platforms? a) the same way we know that 5200 ethernet driver (for example) works on all 5200 boards. If it breaks for one board then we fix it. b) defconfigs is more about testing and a known working configuration than it is about a distribution configuration. It's not intended to be the deployed config. For a distribution/deployable image it is expected that the engineer responsible will tailor the config. > And what about the other patches? I see no code for these boards in > arch/powerpc/platforms/52xx/ ? All these boards are supported with arch/powerpc/platforms/mpc5200_simple.c. A kernel built for that platform will boot on any of those boards as long as it is passed the correct device tree. Cheers, g. -- 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: Please pull linux-2.6-mpc52xx.git
In message <[EMAIL PROTECTED]> you wrote: > > b) defconfigs is more about testing and a known working configuration > than it is about a distribution configuration. It's not intended to > be the deployed config. For a distribution/deployable image it is > expected that the engineer responsible will tailor the config. This may be true in general, but for the boards in question it is definitely incorrect: * The TQM5200 configuration as provided is intended for shipping as default configuration for this board. The "engineer responsible" already *did* the tailoring and put that state in the defconfig file. * The CM5200 and Motion-Pro boards are custom designs, where the defconfig file matches exactly the requirements of the respective customers. I feel it is very important to be able to include this configuration information somewhere with the kernel source tree - and to me the defconfig file for a board is the most natural place to put such information. Please understand that we do NOT expect the end user having to "tailor the config" - instead, we want to provide a default configuration that can be used as is, at least for default usage cases. If you don't want to use a board specific default configuration, then please tell me what the recommended way is to provide a knwon to be working, tested *and* *useful* default configuration for custom boards in the Linux kernel tree? > All these boards are supported with > arch/powerpc/platforms/mpc5200_simple.c. A kernel built for that > platform will boot on any of those boards as long as it is passed the > correct device tree. I don't doubt that the kernel will boot. But that does not mean that it is ready for use for the intended purpose. For example, arch/powerpc/platforms/52xx/motionpro.c contains code to setup some custom LEDs on this board. I can't find that code in arch/powerpc/platforms/mpc5200_simple.c. It may be argued that this code should be moved somewhere else, but I don't remeber to have seen any such review comments. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] You don't have to stay up nights to succeed; you have to stay awake days. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
On Mon, Mar 17, 2008 at 4:28 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote: > In message <[EMAIL PROTECTED]> you wrote: > > * The TQM5200 configuration as provided is intended for shipping as > default configuration for this board. The "engineer responsible" > already *did* the tailoring and put that state in the defconfig > file. > > * The CM5200 and Motion-Pro boards are custom designs, where the > defconfig file matches exactly the requirements of the respective > customers. > > I feel it is very important to be able to include this configuration > information somewhere with the kernel source tree - and to me the > defconfig file for a board is the most natural place to put such > information. (copied from my comments in an off-list conversation) However, I have declined (for now) to pick up the defconfigs for those boards and instead merged in the config features they require into the mpc5200 defconfig. My primary reason for doing so is to increase the likelyhood that full featured kernels are built and tested so that situations where board ports conflict with each other are caught and fixed. ojn has also been complaining about the number of defconfigs he needs to build to test all the powerpc configurations without any indications about which ones are important and which ones are not. There has been some discussion about having a subdirectory for optimized board configs, but nobody has done anything about it yet. The one part that I have a really strong opinion on is that there should be a full featured mpc5200 defconfig for build testing. Beyond that (and if ojn can also be appeased) I can probably be convinced. :-) > > All these boards are supported with > > arch/powerpc/platforms/mpc5200_simple.c. A kernel built for that > > platform will boot on any of those boards as long as it is passed the > > correct device tree. > > I don't doubt that the kernel will boot. But that does not mean that > it is ready for use for the intended purpose. For example, > arch/powerpc/platforms/52xx/motionpro.c contains code to setup some > custom LEDs on this board. I can't find that code in > > arch/powerpc/platforms/mpc5200_simple.c. > > It may be argued that this code should be moved somewhere else, but I > don't remeber to have seen any such review comments. The LED code just hasn't been picked up. IIRC, it was reworked to make it a proper driver in drivers/leds. I need to look at it again, but it is a lot of code for a very simple thing and I wasn't sure if I should be the one to pick it up because it is in drivers/leds which has a different maintainer. Cheers, g. -- 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: Please pull linux-2.6-mpc52xx.git
Dear Grant, in message <[EMAIL PROTECTED]> you wrote: > > However, I have declined (for now) to pick up the defconfigs for those > boards and instead merged in the config features they require into the > mpc5200 defconfig. My primary reason for doing so is to increase the > likelyhood that full featured kernels are built and tested so that > situations where board ports conflict with each other are caught and > fixed. I know what you mean, and I agree with the idea. Unfortunately I think it's impossible to implement, especially on such embedded processors with their high level of pin multiplexing. For example, if you want to include testing of the FEC ethernet driver, you will probably fail to test the second USB port. I think it's simply not possible to test all possible options in a single kernel configuration - first it doesn't work (for example because of pin multiplexing issues), second you will likely not be able to find hardware that implements all features at once. My dream is to have a distributed test environment - a framework which can be used for automatic testing which includes building and running the code on a set of systems, and which will then report the test results to a central location. We have the same problem (probably to a much higher degree) in U-Boot; nobody can test all board configurations because nobody has all the cross-tools installed nor the 500+ boards available. > ojn has also been complaining about the number of defconfigs he needs > to build to test all the powerpc configurations without any > indications about which ones are important and which ones are not. again, some distributed test tool might help - we would get not only information abouyt test results, but also which configurations have been tested how frequently. > There has been some discussion about having a subdirectory for > optimized board configs, but nobody has done anything about it yet. Is this a hint? > The one part that I have a really strong opinion on is that there > should be a full featured mpc5200 defconfig for build testing. Beyond > that (and if ojn can also be appeased) I can probably be convinced. :-) Maybe my expectations for "full featured' are just too high.. > The LED code just hasn't been picked up. IIRC, it was reworked to > make it a proper driver in drivers/leds. I need to look at it again, > but it is a lot of code for a very simple thing and I wasn't sure if I > should be the one to pick it up because it is in drivers/leds which > has a different maintainer. I see. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] If some day we are defeated, well, war has its fortunes, good and bad. -- Commander Kor, "Errand of Mercy", stardate 3201.7 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
On Mon, Mar 17, 2008 at 6:26 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote: > Dear Grant, > > > in message <[EMAIL PROTECTED]> you wrote: > > > > However, I have declined (for now) to pick up the defconfigs for those > > boards and instead merged in the config features they require into the > > mpc5200 defconfig. My primary reason for doing so is to increase the > > likelyhood that full featured kernels are built and tested so that > > situations where board ports conflict with each other are caught and > > fixed. > > I know what you mean, and I agree with the idea. > > Unfortunately I think it's impossible to implement, especially on such > embedded processors with their high level of pin multiplexing. > > For example, if you want to include testing of the FEC ethernet > driver, you will probably fail to test the second USB port. I think > it's simply not possible to test all possible options in a single > kernel configuration - first it doesn't work (for example because of > pin multiplexing issues), second you will likely not be able to find > hardware that implements all features at once. I don't think this example really applies. Yes, I agree that I cannot test all the functions, but that does not preclude building in all the drivers and making sure that they don't cause a conflict by just being present. For instance, I can build a single kernel image right now that should boot and fully run on the Efika, lite5200, tqm and motion pro boards (although the Efika has a different wrapper). I can only test it on the Efika and lite5200 boards and I have to rely on other people for the boards I don't have. If it breaks; I expect to receive an irate email in my Inbox telling me to fix it! pin multiplexing shouldn't be an issue at all. Only the devices which are instantiated in the device tree will actually get initialized so if the pins aren't hooked up then it shouldn't be in the tree. Ideally, the bootloader should take care of the pin multiplexing setup, but even if it doesn't it can be setup by platform code and CONFIG_MULTIPLATFORM supports building multiple platforms into a single image (within a processor family of course; you can't build a 405+6xx multiplatform kernel.) tqm, motionpro and cm boards can all use simple platform because they all have good firmware ports that setup the hardware correctly in the first place. lite5200(b) does not because there are quite a few lite5200 boards 'in the wild' with firmware that doesn't setup the board the way it should be (or at least the way Linux likes it). > > There has been some discussion about having a subdirectory for > > optimized board configs, but nobody has done anything about it yet. > > Is this a hint? Oh, probably. :-) Cheers, g. -- 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: Please pull linux-2.6-mpc52xx.git
Grant Likely wrote: On Mon, Mar 17, 2008 at 9:57 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote: [...] we were hoping that the changes would go upstream (in 2.6.25). I can see that the .dts files for those boards are in the mainline already, but I see no trace of for example _defconfig files -- could you shed some light on this? Yes, the separate dts files have been dropped in preference for a single mpc5200_defconfig for all 5200 boards. Ah, yes. I was searching for patches by Marian, and missed the defconfig unification patch by you. BTW: I can't find it using its description from the commit log (i.e., "[POWERPC] mpc5200: merge defconfigs for all mpc5200 boards") in Nabble's archive of linuxppc ML; searching patchwork.ozlabs.org/linuxppc fails as well. Should I search using some other description? Regards, Bartlomiej ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
Grant Likely wrote: On Mon, Mar 17, 2008 at 4:28 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote: [...] It may be argued that this code should be moved somewhere else, but I don't remeber to have seen any such review comments. The LED code just hasn't been picked up. IIRC, it was reworked to make it a proper driver in drivers/leds. Grant, Yes, the Motion-PRO LED driver has been reworked and posted: http://patchwork.ozlabs.org/linuxppc/patch?q=Motion-pro&id=16617 > I need to look at it again, but it is a lot of code for a very simple thing and I wasn't sure if I should be the one to pick it up because it is in drivers/leds which has a different maintainer. I'm copying Richard Purdie who's listed as LED SUBSYSTEM maintainer. Richard -- could pick up the above mentioned Motion-PRO LED driver for upstream inclusion? It started as a MPC5200-specific thing posted to linuxppc-dev and got reviewed there, with the intent to go upstream via Grant (MPC52XX maintainer). However, it seems that it should be merged through your subsystem. Thanks, Bartlomiej ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
On Tue, 2008-03-18 at 09:29 +0100, Bartlomiej Sieka wrote: > Grant Likely wrote: > > The LED code just hasn't been picked up. IIRC, it was reworked to > > make it a proper driver in drivers/leds. > > Yes, the Motion-PRO LED driver has been reworked and posted: > http://patchwork.ozlabs.org/linuxppc/patch?q=Motion-pro&id=16617 > > > I need to look at it again, > > but it is a lot of code for a very simple thing and I wasn't sure if I > > should be the one to pick it up because it is in drivers/leds which > > has a different maintainer. > > I'm copying Richard Purdie who's listed as LED SUBSYSTEM maintainer. > > Richard -- could pick up the above mentioned Motion-PRO LED driver for > upstream inclusion? It started as a MPC5200-specific thing posted to > linuxppc-dev and got reviewed there, with the intent to go upstream via > Grant (MPC52XX maintainer). However, it seems that it should be merged > through your subsystem. There are some tweaks this driver needs before it can be merged. Firstly, it seems to re implement a timer to make the LED blink and I'm not keen on doing that. I notice that you have default_trigger = "timer" but that won't make it activate at boot which is probably why the other code exists? I will accept a patch which allows the default timer state to be configurable (either from the defconfig or from the commandline) which should solve your problem? Secondly, can you confirm what of_get_property(op->node, "label", NULL); returns and whether this conforms to the LED naming guidelines? Cheers, Richard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
On Mon, 17 Mar 2008 20:42:14 -0600 "Grant Likely" <[EMAIL PROTECTED]> wrote: > On Mon, Mar 17, 2008 at 6:26 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote: > > Dear Grant, > > > > > > in message <[EMAIL PROTECTED]> you wrote: > > > > > > However, I have declined (for now) to pick up the defconfigs for those > > > boards and instead merged in the config features they require into the > > > mpc5200 defconfig. My primary reason for doing so is to increase the > > > likelyhood that full featured kernels are built and tested so that > > > situations where board ports conflict with each other are caught and > > > fixed. > > > > I know what you mean, and I agree with the idea. > > > > Unfortunately I think it's impossible to implement, especially on such > > embedded processors with their high level of pin multiplexing. > > > > For example, if you want to include testing of the FEC ethernet > > driver, you will probably fail to test the second USB port. I think > > it's simply not possible to test all possible options in a single > > kernel configuration - first it doesn't work (for example because of > > pin multiplexing issues), second you will likely not be able to find > > hardware that implements all features at once. > > I don't think this example really applies. Yes, I agree that I cannot > test all the functions, but that does not preclude building in all the > drivers and making sure that they don't cause a conflict by just being > present. For instance, I can build a single kernel image right now > that should boot and fully run on the Efika, lite5200, tqm and motion > pro boards (although the Efika has a different wrapper). I can only > test it on the Efika and lite5200 boards and I have to rely on other > people for the boards I don't have. If it breaks; I expect to receive > an irate email in my Inbox telling me to fix it! > > pin multiplexing shouldn't be an issue at all. Only the devices which > are instantiated in the device tree will actually get initialized so > if the pins aren't hooked up then it shouldn't be in the tree. That's not entirely true. Devices that are muxed can be added to the tree just fine. What I've done on 440 boards that have devices that share pins is to add a status = "disabled"; property to the device that doesn't have pins at the moment. See my patch for of_device_is_available for how to query that. I'll be throwing that in my tree soon if Paul doesn't pick it up. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
On Tue, Mar 18, 2008 at 2:29 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote: > Grant, > > Yes, the Motion-PRO LED driver has been reworked and posted: > http://patchwork.ozlabs.org/linuxppc/patch?q=Motion-pro&id=16617 > > > > > I need to look at it again, > > but it is a lot of code for a very simple thing and I wasn't sure if I > > should be the one to pick it up because it is in drivers/leds which > > has a different maintainer. > > I'm copying Richard Purdie who's listed as LED SUBSYSTEM maintainer. > > Richard -- could pick up the above mentioned Motion-PRO LED driver for > upstream inclusion? It started as a MPC5200-specific thing posted to > linuxppc-dev and got reviewed there, with the intent to go upstream via > Grant (MPC52XX maintainer). However, it seems that it should be merged > through your subsystem. Okay, I've taken another look at the driver and I've figured out what has been bothering me about it. It seems to me that the motion pro led driver is just the first of many that we will see (seeing as some many people find the blinking lights rather soothing) and it's a non trivial amount of code. (Note: I'm not actually opposed to this driver if Richard is okay with it; but I do think that in the long term we should move towards a more generic approach) In essence, this driver sets up two GPIO pins to drive LEDs. A pretty common approach for putting LEDs on a board. In this case each GPIO bank only contains 1 pin; but I imagine that on other boards there will be multiple pins in a GPIO bank, only some of which actually used for blinking LEDs. I've started thinking that it would be better to split things up in the device tree to have one node for each GPIO block and a single LED node that maps LEDs to gpio pins. That would allow a common driver to be written for all GPIO driven LEDs with a single block of device tree parsing code. Plus, it allows other devices to use GPIO pins within the same block (not an issue for the motion pro board; but when other boards start coming on-line it would allow us to reduce the amount of board specific code). Finally, it means that the timer pin GPIO driver can be used for more than just flashing an attached LED. Cheers, g. -- 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: Please pull linux-2.6-mpc52xx.git
On Tue, 2008-03-18 at 08:47 -0600, Grant Likely wrote: > On Tue, Mar 18, 2008 at 2:29 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote: > > Grant, > > > > Yes, the Motion-PRO LED driver has been reworked and posted: > > http://patchwork.ozlabs.org/linuxppc/patch?q=Motion-pro&id=16617 > > Okay, I've taken another look at the driver and I've figured out what > has been bothering me about it. It seems to me that the motion pro > led driver is just the first of many that we will see (seeing as some > many people find the blinking lights rather soothing) and it's a non > trivial amount of code. > > (Note: I'm not actually opposed to this driver if Richard is okay with > it; but I do think that in the long term we should move towards a more > generic approach) > > In essence, this driver sets up two GPIO pins to drive LEDs. A pretty > common approach for putting LEDs on a board. In this case each GPIO > bank only contains 1 pin; but I imagine that on other boards there > will be multiple pins in a GPIO bank, only some of which actually used > for blinking LEDs. > > I've started thinking that it would be better to split things up in > the device tree to have one node for each GPIO block and a single LED > node that maps LEDs to gpio pins. That would allow a common driver to > be written for all GPIO driven LEDs with a single block of device tree > parsing code. Plus, it allows other devices to use GPIO pins within > the same block (not an issue for the motion pro board; but when other > boards start coming on-line it would allow us to reduce the amount of > board specific code). Finally, it means that the timer pin GPIO > driver can be used for more than just flashing an attached LED. I don't mind having a specific driver but I don't know anything about the hardware its creating the interface for so I need the community's help with that part. There is drivers/leds/leds-gpio.c if that would work better. Regards, Richard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
On Tue, Mar 18, 2008 at 10:41 AM, Richard Purdie <[EMAIL PROTECTED]> wrote: > > On Tue, 2008-03-18 at 08:47 -0600, Grant Likely wrote: > I don't mind having a specific driver but I don't know anything about > the hardware its creating the interface for so I need the community's > help with that part. There is drivers/leds/leds-gpio.c if that would > work better. Yes, I think that would be the right approach. We would need to add the binding code to translate from the OF device tree to the leds-gpio driver. Cheers, g. -- 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: Please pull linux-2.6-mpc52xx.git
Richard Purdie wrote: On Tue, 2008-03-18 at 09:29 +0100, Bartlomiej Sieka wrote: Grant Likely wrote: The LED code just hasn't been picked up. IIRC, it was reworked to make it a proper driver in drivers/leds. Yes, the Motion-PRO LED driver has been reworked and posted: http://patchwork.ozlabs.org/linuxppc/patch?q=Motion-pro&id=16617 > I need to look at it again, but it is a lot of code for a very simple thing and I wasn't sure if I should be the one to pick it up because it is in drivers/leds which has a different maintainer. I'm copying Richard Purdie who's listed as LED SUBSYSTEM maintainer. Richard -- could pick up the above mentioned Motion-PRO LED driver for upstream inclusion? It started as a MPC5200-specific thing posted to linuxppc-dev and got reviewed there, with the intent to go upstream via Grant (MPC52XX maintainer). However, it seems that it should be merged through your subsystem. There are some tweaks this driver needs before it can be merged. Firstly, it seems to re implement a timer to make the LED blink and I'm not keen on doing that. I notice that you have default_trigger = "timer" but that won't make it activate at boot which is probably why the other code exists? That's right. The requirement is to have the LED blink while the system is booting up, until a custom application takes control over. I will accept a patch which allows the default timer state to be configurable (either from the defconfig or from the commandline) which should solve your problem? Yes, this should work. Will you accept a patch that allows default timer configuration based on the information from the device tree blob (the board in question is under arch/powerpc)? Secondly, can you confirm what of_get_property(op->node, "label", NULL); returns and whether this conforms to the LED naming guidelines? No it does not -- thanks for bringing this point up. Will post code that fixes this. Thanks for your comments. Regards, Bartlomiej ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
Grant Likely wrote: On Tue, Mar 18, 2008 at 10:41 AM, Richard Purdie <[EMAIL PROTECTED]> wrote: On Tue, 2008-03-18 at 08:47 -0600, Grant Likely wrote: I don't mind having a specific driver but I don't know anything about the hardware its creating the interface for so I need the community's help with that part. There is drivers/leds/leds-gpio.c if that would work better. Yes, I think that would be the right approach. We would need to add the binding code to translate from the OF device tree to the leds-gpio driver. I think that leds-gpio.c is a good solution for long-term. Note however, that having the LED-to-GPIO pin mapping defined in the OF device tree is problematic for targets that don't use a device tree, and for a generic driver like leds-gpio.c some other mechanisms should probably be used. Going back to LEDs on Motion-PRO, using leds-gpio.c for this target won't be achieved quickly. leds-gpio.c uses generic GPIO access routines, which are not implemented for powerpc in general, and MPC5200 in particular. One would have to add support for MPC5200 to GPIO LIB API, and implement the above mentioned LED-to-GPIO pin mapping in leds-gpio.c, and then convert Motion-PRO. Since both you and Richard don't have objections against a specific driver, and switching Motion-PRO to a generic approach requires quite a bit of work -- then how about we provide a patch that addresses Richard's comments, and have the Motion-PRO LED support merged upstream as a specific driver? Regards, Bartlomiej ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
Grant Likely wrote: [...] (copied from my comments in an off-list conversation) However, I have declined (for now) to pick up the defconfigs for those boards and instead merged in the config features they require into the mpc5200 defconfig. My primary reason for doing so is to increase the likelyhood that full featured kernels are built and tested so that situations where board ports conflict with each other are caught and fixed. ojn has also been complaining about the number of defconfigs he needs to build to test all the powerpc configurations without any indications about which ones are important and which ones are not. There has been some discussion about having a subdirectory for optimized board configs, but nobody has done anything about it yet. The one part that I have a really strong opinion on is that there should be a full featured mpc5200 defconfig for build testing. Beyond that (and if ojn can also be appeased) I can probably be convinced. :-) Hi Grant, How to deal with a situation where I need a particular PHY driver from libphy compiled in the kernel for one of the MPC5200 boards? Adding it to mpc5200_defconfig doesn't seem like a right thing to do. How to convince you (and appease ojn) to accept a patch that adds a board-specific defconfig that only slightly differs from mpc5200_defconfig? :) Regards, Bartlomiej ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
On Tue, Mar 25, 2008 at 10:50 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote: > Grant Likely wrote: > > On Tue, Mar 18, 2008 at 10:41 AM, Richard Purdie <[EMAIL PROTECTED]> wrote: > >> On Tue, 2008-03-18 at 08:47 -0600, Grant Likely wrote: > >> I don't mind having a specific driver but I don't know anything about > >> the hardware its creating the interface for so I need the community's > >> help with that part. There is drivers/leds/leds-gpio.c if that would > >> work better. > > > > Yes, I think that would be the right approach. We would need to add > > the binding code to translate from the OF device tree to the leds-gpio > > driver. > > I think that leds-gpio.c is a good solution for long-term. Note however, > that having the LED-to-GPIO pin mapping defined in the OF device > tree is problematic for targets that don't use a device tree, and for a > generic driver like leds-gpio.c some other mechanisms should probably be > used. Something to consider: The device tree is all about describing hardware and binding it to the driver. Nothing more. So; there will always be glue code to extract the config from the tree and tell the leds-gpio driver about it (the binding); but once that is done the driver isn't any different. I've got several drivers with both platform bus and of_platform bus bindings where most of the driver is shared. Only the bit of code that extracts the configuration from either pdata or the device tree is bus specific. > > Going back to LEDs on Motion-PRO, using leds-gpio.c for this target > won't be achieved quickly. leds-gpio.c uses generic GPIO access > routines, which are not implemented for powerpc in general, and MPC5200 > in particular. One would have to add support for MPC5200 to GPIO LIB > API, and implement the above mentioned LED-to-GPIO pin mapping in > leds-gpio.c, and then convert Motion-PRO. > > Since both you and Richard don't have objections against a specific > driver, and switching Motion-PRO to a generic approach requires quite a > bit of work -- then how about we provide a patch that addresses > Richard's comments, and have the Motion-PRO LED support merged upstream > as a specific driver? Yes, I'm totally cool with that. Cheers, g. -- 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: Please pull linux-2.6-mpc52xx.git
On Tue, Mar 25, 2008 at 11:38 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote: > Grant Likely wrote: > > The one part that I have a really strong opinion on is that there > > should be a full featured mpc5200 defconfig for build testing. Beyond > > that (and if ojn can also be appeased) I can probably be convinced. :-) > > Hi Grant, > > How to deal with a situation where I need a particular PHY driver from > libphy compiled in the kernel for one of the MPC5200 boards? Adding it > to mpc5200_defconfig doesn't seem like a right thing to do. Why not? mpc5200_defconfig is all about compile and runtime testing on many platforms to make sure drivers play well together. I have no problem adding more drivers to the mpc5200 defconfig. (In fact, I encourage it). > How to > convince you (and appease ojn) to accept a patch that adds a > board-specific defconfig that only slightly differs from > mpc5200_defconfig? :) I'm thinking 'optimized' defconfigs should go into a subdirectory. Cheers, g. -- 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: Please pull linux-2.6-mpc52xx.git
Hi Grant, Grant Likely wrote: On Tue, Mar 25, 2008 at 11:38 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote: Grant Likely wrote: > The one part that I have a really strong opinion on is that there > should be a full featured mpc5200 defconfig for build testing. Beyond > that (and if ojn can also be appeased) I can probably be convinced. :-) Hi Grant, How to deal with a situation where I need a particular PHY driver from libphy compiled in the kernel for one of the MPC5200 boards? Adding it to mpc5200_defconfig doesn't seem like a right thing to do. Why not? mpc5200_defconfig is all about compile and runtime testing on many platforms to make sure drivers play well together. I have no problem adding more drivers to the mpc5200 defconfig. (In fact, I encourage it). How to convince you (and appease ojn) to accept a patch that adds a board-specific defconfig that only slightly differs from mpc5200_defconfig? :) I'm thinking 'optimized' defconfigs should go into a subdirectory. This requires a change to the top-level Makefile and shepherding this change upstream. Could we perhaps try to avoid this by having optimized defconfigs in the form of, for example: arch/powerpc/configs/tqm5200_opt_defconfig arch/powerpc/configs/motionpro_opt_defconfig Or, to signify what is the base defconfig: arch/powerpc/configs/mpc5200_tqm5200_defconfig arch/powerpc/configs/mpc5200_motionpro_defconfig or even: arch/powerpc/configs/mpc5200_opt_tqm5200_defconfig arch/powerpc/configs/mpc5200_opt_motionpro_defconfig Would patch adding an optimized _defconfig along these lines be accepted? Regards, Bartlomiej ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
Bartlomiej Sieka wrote: Hi Grant, Grant Likely wrote: On Tue, Mar 25, 2008 at 11:38 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote: Grant Likely wrote: > The one part that I have a really strong opinion on is that there > should be a full featured mpc5200 defconfig for build testing. Beyond > that (and if ojn can also be appeased) I can probably be convinced. :-) Hi Grant, How to deal with a situation where I need a particular PHY driver from libphy compiled in the kernel for one of the MPC5200 boards? Adding it to mpc5200_defconfig doesn't seem like a right thing to do. Why not? mpc5200_defconfig is all about compile and runtime testing on many platforms to make sure drivers play well together. I have no problem adding more drivers to the mpc5200 defconfig. (In fact, I encourage it). How to convince you (and appease ojn) to accept a patch that adds a board-specific defconfig that only slightly differs from mpc5200_defconfig? :) I'm thinking 'optimized' defconfigs should go into a subdirectory. This requires a change to the top-level Makefile and shepherding this change upstream. Could we perhaps try to avoid this by having optimized defconfigs in the form of, for example: arch/powerpc/configs/tqm5200_opt_defconfig arch/powerpc/configs/motionpro_opt_defconfig Or, to signify what is the base defconfig: arch/powerpc/configs/mpc5200_tqm5200_defconfig arch/powerpc/configs/mpc5200_motionpro_defconfig or even: arch/powerpc/configs/mpc5200_opt_tqm5200_defconfig arch/powerpc/configs/mpc5200_opt_motionpro_defconfig Would patch adding an optimized _defconfig along these lines be accepted? Grant, Any thoughts on the above? Regards, Bartlomiej ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
On Fri, Apr 4, 2008 at 5:13 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote: > > Bartlomiej Sieka wrote: > > > Hi Grant, > > > > Grant Likely wrote: > > > I'm thinking 'optimized' defconfigs should go into a subdirectory. > > > > This requires a change to the top-level Makefile and shepherding this > > change upstream. Could we perhaps try to avoid this by having optimized > > defconfigs in the form of, for example: I don't think changes are required to put them in a subdir: $ mkdir arch/powerpc/configs/optimized $ cp arch/powerpc/configs/mpc5200_defconfig arch/powerpc/configs/optimized/lite5200_defconfig $ make optimized/lite5200_defconfig This works for me. > > Grant, > > Any thoughts on the above? Sorry I didn't reply earlier Cheers, g. -- 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: Please pull linux-2.6-mpc52xx.git
On Fri, Apr 4, 2008 at 10:11 AM, Grant Likely <[EMAIL PROTECTED]> wrote: > > > > I'm thinking 'optimized' defconfigs should go into a subdirectory. > > > > > > This requires a change to the top-level Makefile and shepherding this > > > change upstream. Could we perhaps try to avoid this by having optimized > > > defconfigs in the form of, for example: > > I don't think changes are required to put them in a subdir: > > $ mkdir arch/powerpc/configs/optimized > $ cp arch/powerpc/configs/mpc5200_defconfig > arch/powerpc/configs/optimized/lite5200_defconfig > $ make optimized/lite5200_defconfig > > This works for me. However, I'm not sure what the naming scheme should be for subdirectories. board vendor? host processor? just one big directory for board specific defconfigs? Olof, Kumar, Josh; any thoughts? Not that it matters much; files are easy to move around later. Cheers, g. -- 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: Please pull linux-2.6-mpc52xx.git
On Fri, Apr 04, 2008 at 10:14:34AM -0600, Grant Likely wrote: > On Fri, Apr 4, 2008 at 10:11 AM, Grant Likely <[EMAIL PROTECTED]> wrote: > > > > > I'm thinking 'optimized' defconfigs should go into a subdirectory. > > > > > > > > This requires a change to the top-level Makefile and shepherding this > > > > change upstream. Could we perhaps try to avoid this by having optimized > > > > defconfigs in the form of, for example: > > > > I don't think changes are required to put them in a subdir: > > > > $ mkdir arch/powerpc/configs/optimized > > $ cp arch/powerpc/configs/mpc5200_defconfig > > arch/powerpc/configs/optimized/lite5200_defconfig > > $ make optimized/lite5200_defconfig > > > > This works for me. > > However, I'm not sure what the naming scheme should be for subdirectories. > > board vendor? > host processor? > just one big directory for board specific defconfigs? > > Olof, Kumar, Josh; any thoughts? > > Not that it matters much; files are easy to move around later. I really like the idea. It would probably make sense to organize it in the same way as the platforms are done today, i.e. per processor/platform family. And then have shared/merged configs in the main config directory. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
On Fri, 2008-04-04 at 11:38 -0500, Olof Johansson wrote: > On Fri, Apr 04, 2008 at 10:14:34AM -0600, Grant Likely wrote: > > On Fri, Apr 4, 2008 at 10:11 AM, Grant Likely <[EMAIL PROTECTED]> wrote: > > > > > > I'm thinking 'optimized' defconfigs should go into a subdirectory. > > > > > > > > > > This requires a change to the top-level Makefile and shepherding this > > > > > change upstream. Could we perhaps try to avoid this by having > > > optimized > > > > > defconfigs in the form of, for example: > > > > > > I don't think changes are required to put them in a subdir: > > > > > > $ mkdir arch/powerpc/configs/optimized > > > $ cp arch/powerpc/configs/mpc5200_defconfig > > > arch/powerpc/configs/optimized/lite5200_defconfig > > > $ make optimized/lite5200_defconfig > > > > > > This works for me. > > > > However, I'm not sure what the naming scheme should be for subdirectories. > > > > board vendor? > > host processor? > > just one big directory for board specific defconfigs? > > > > Olof, Kumar, Josh; any thoughts? > > > > Not that it matters much; files are easy to move around later. > > I really like the idea. It would probably make sense to organize it in > the same way as the platforms are done today, i.e. per processor/platform > family. And then have shared/merged configs in the main config directory. Yes. I was thinking the same already for 4xx. Essentially: configs/ppc44x_defconfig configs/ppc40x_defconfig configs/44x/_defconfig configs/40x/_defconfig josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
On Fri, Apr 4, 2008 at 11:15 AM, Josh Boyer > > I really like the idea. It would probably make sense to organize it in > > the same way as the platforms are done today, i.e. per processor/platform > > family. And then have shared/merged configs in the main config directory. > > Yes. I was thinking the same already for 4xx. Essentially: > > configs/ppc44x_defconfig > configs/ppc40x_defconfig > configs/44x/_defconfig > configs/40x/_defconfig Sounds logical. I'm cool with this. g. -- 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: Please pull linux-2.6-mpc52xx.git
Hi Grant, Grant Likely wrote: On Fri, Apr 4, 2008 at 5:13 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote: Bartlomiej Sieka wrote: Hi Grant, Grant Likely wrote: I'm thinking 'optimized' defconfigs should go into a subdirectory. This requires a change to the top-level Makefile and shepherding this change upstream. Could we perhaps try to avoid this by having optimized defconfigs in the form of, for example: I don't think changes are required to put them in a subdir: $ mkdir arch/powerpc/configs/optimized $ cp arch/powerpc/configs/mpc5200_defconfig arch/powerpc/configs/optimized/lite5200_defconfig $ make optimized/lite5200_defconfig This works for me. Yes, this indeed works. I'm about to post a patch that adds board-specific defconfigs for 52xx boards -- could you review it and push the changes upstream via your tree? Thanks in advance. Regards, Bartlomiej ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
> Paulus, > > Sylvain has asked if I would like to help with the mpc52xx > maintainership. If it's okay by you, here is a patch that adds me as > co-maintainer for the mpc52xx platform along with 3 other mpc52xx > related fixes. > > Sylvain, can you please reply to this message confirming that this is > what we talked about? Paulus, Yes, I confirm. Sylvain ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
Grant Likely writes: > There are remaining outstanding comments; but my opinion is that they > should be addressed in subsequent patches (performance optimization > for mp5200b boards and making the sram management code a generic > interface usable by other SoC support code). > > If you agree; please pull into your tree. I'll pull it on the understanding that the remaining issues will in fact be addressed in the near term. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
On 10/17/07, Paul Mackerras <[EMAIL PROTECTED]> wrote: > Grant Likely writes: > > > There are remaining outstanding comments; but my opinion is that they > > should be addressed in subsequent patches (performance optimization > > for mp5200b boards and making the sram management code a generic > > interface usable by other SoC support code). > > > > If you agree; please pull into your tree. > > I'll pull it on the understanding that the remaining issues will in > fact be addressed in the near term. agreed Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Fwd: Please pull linux-2.6-mpc52xx.git
Paulus, please pull the following mpc52xx related changes. The following changes since commit 2fb59d623ad85dfdb8ce03a660051743f7361896: Linus Torvalds (1): Merge branch 'audit.b43' of git://git.kernel.org/.../viro/audit-current are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-mpc52xx.git for-2.6.24 Grant Likely (1): [POWERPC] bestcomm: Restrict bus prefetch bugfix to original mpc5200 silicon. Marian Balakowicz (4): [POWERPC] Add mpc52xx_find_and_map_path(), refactor utility functions [POWERPC] Update device tree binding for mpc5200 gpt [POWERPC] Add restart support for mpc52xx based platforms [POWERPC] Enable restart support for lite5200 board .../powerpc/mpc52xx-device-tree-bindings.txt |4 +- arch/powerpc/boot/dts/lite5200.dts | 26 +++- arch/powerpc/boot/dts/lite5200b.dts| 26 +++- arch/powerpc/platforms/52xx/lite5200.c |4 + arch/powerpc/platforms/52xx/mpc52xx_common.c | 71 ++- arch/powerpc/sysdev/bestcomm/bestcomm.c|9 ++- drivers/watchdog/mpc5200_wdt.c |3 + include/asm-powerpc/mpc52xx.h |9 +++ 8 files changed, 109 insertions(+), 43 deletions(-) -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
Grant Likely writes: > Please pull the 'merge' branch of my MPC5200 tree (url below). I've Pulled and pushed out, but I will wait until Linus is back from vacation before asking him to pull. Some of the commits in there are very close to being unsuitable to go in at this stage - in particular the ones that just fix up printks don't seem to me to be fixing a serious bug, build failure or regression. However, we'll see what Linus says. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
On Sun, Nov 23, 2008 at 8:38 PM, Paul Mackerras <[EMAIL PROTECTED]> wrote: > Grant Likely writes: > >> Please pull the 'merge' branch of my MPC5200 tree (url below). I've > > Pulled and pushed out, but I will wait until Linus is back from > vacation before asking him to pull. Thanks Paul. > Some of the commits in there are very close to being unsuitable to go > in at this stage - in particular the ones that just fix up printks > don't seem to me to be fixing a serious bug, build failure or > regression. Well, they do fixup compiler warnings which I would categorize under build failure, otherwise I wouldn't have pushed them out. I won't do it again if that isn't sufficient. > However, we'll see what Linus says. :-) -- 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: Fwd: Please pull linux-2.6-mpc52xx.git
Hi, On Wed, Feb 06, 2008 at 02:34:24PM -0700, Grant Likely wrote: > John Rigby (4): > [POWERPC] mpc512x: Basic platform support > [POWERPC] mpc512x: Device tree for MPC5121 ADS > [POWERPC] mpc512x: Factor out 5200 dependencies from 52xx psc driver > [POWERPC] mpc512x: Add MPC512x PSC support to MPC52xx psc driver mpc52xx_defconfig no longer builds for me, and the two latter of the above patches are the ones that touch that file: (from powerpc.git HEAD=de0723dcca6e593a12a259798a54eb0e82628fb8, seems to include this pull): drivers/serial/mpc52xx_uart.c:137: error: 'mpc52xx_psc_ops' undeclared here (not in a function) drivers/serial/mpc52xx_uart.c:149: error: conflicting types for 'mpc52xx_uart_of _match' drivers/serial/mpc52xx_uart.c:135: error: previous definition of 'mpc52xx_uart_of_match' was here drivers/serial/mpc52xx_uart.c:153: warning: braces around scalar initializer drivers/serial/mpc52xx_uart.c:153: warning: (near initialization for 'mpc52xx_uart_of_match[0].data') drivers/serial/mpc52xx_uart.c:153: error: empty scalar initializer drivers/serial/mpc52xx_uart.c:153: error: (near initialization for 'mpc52xx_uart_of_match[0].data') drivers/serial/mpc52xx_uart.c:154: error: expected '}' before ';' token drivers/serial/mpc52xx_uart.c:157:2: error: #endif without #if -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Fwd: Please pull linux-2.6-mpc52xx.git
On 2/6/08, Olof Johansson <[EMAIL PROTECTED]> wrote: > Hi, > > On Wed, Feb 06, 2008 at 02:34:24PM -0700, Grant Likely wrote: > > > John Rigby (4): > > [POWERPC] mpc512x: Basic platform support > > [POWERPC] mpc512x: Device tree for MPC5121 ADS > > [POWERPC] mpc512x: Factor out 5200 dependencies from 52xx psc driver > > [POWERPC] mpc512x: Add MPC512x PSC support to MPC52xx psc driver > > mpc52xx_defconfig no longer builds for me, and the two latter of the > above patches are the ones that touch that file: Gah! I caused some patch damage when I rebased the patches. I'll send a fixup patch ASAP. Cheers, g. -- 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
Please pull linux-2.6-mpc52xx.git for 2.6.26
Hi Paul, Here is one more last minute 2.6.26 bug fix. The following changes since commit 1702b52092e9a6d05398d3f9581ddc050ef00d06: Linus Torvalds (1): Merge git://git.kernel.org/.../mchehab/v4l-dvb are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-mpc52xx.git for-2.6.26 Tim Yamin (1): powerpc/mpc5200: Fix lite5200b suspend/resume arch/powerpc/platforms/52xx/lite5200_pm.c | 14 +- 1 files changed, 13 insertions(+), 1 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
