Please pull linux-2.6-mpc52xx.git

Please pull linux-2.6-mpc52xx.git

[Grant Likely]

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.
grant.likely@secretlab.ca
(403) 399-0195

Re: Please pull linux-2.6-mpc52xx.git

[Paul Mackerras]

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.

Re: Please pull linux-2.6-mpc52xx.git

[Grant Likely]

On 10/17/07, Paul Mackerras <paulus@samba.org> 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.
grant.likely@secretlab.ca
(403) 399-0195

Please pull linux-2.6-mpc52xx.git

[Grant Likely]

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.

Please pull linux-2.6-mpc52xx.git

[Grant Likely]

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.

Re: Please pull linux-2.6-mpc52xx.git

[Paul Mackerras]

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.

Re: Please pull linux-2.6-mpc52xx.git

[Grant Likely]

On Sun, Nov 23, 2008 at 8:38 PM, Paul Mackerras <paulus@samba.org> 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.

Please pull linux-2.6-mpc52xx.git

[Grant Likely]

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.

Please pull linux-2.6-mpc52xx.git

[Grant Likely]

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

s.hauer@pengutronix.de (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.

Please pull linux-2.6-mpc52xx.git

[Grant Likely]

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.

Re: Please pull linux-2.6-mpc52xx.git

[Grant Likely]

On Mon, Mar 17, 2008 at 9:57 AM, Bartlomiej Sieka <tur@semihalf.com> 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.

Re: Please pull linux-2.6-mpc52xx.git

[Wolfgang Denk]

In message <fa686aa40803171219s7135a0f8n91bcd20329a94637@mail.gmail.com> 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: wd@denx.de
Minds are like parachutes - they only function when open.

Re: Please pull linux-2.6-mpc52xx.git

[Grant Likely]

On Mon, Mar 17, 2008 at 2:59 PM, Wolfgang Denk <wd@denx.de> wrote:
> In message <fa686aa40803171219s7135a0f8n91bcd20329a94637@mail.gmail.com> 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.

Re: Please pull linux-2.6-mpc52xx.git

[Wolfgang Denk]

In message <fa686aa40803171443q7a53f0balbb49740116c6552@mail.gmail.com> 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: wd@denx.de
You don't have to stay up nights to succeed; you have to  stay  awake
days.

Re: Please pull linux-2.6-mpc52xx.git

[Grant Likely]

On Mon, Mar 17, 2008 at 4:28 PM, Wolfgang Denk <wd@denx.de> wrote:
> In message <fa686aa40803171443q7a53f0balbb49740116c6552@mail.gmail.com> 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.

Re: Please pull linux-2.6-mpc52xx.git

[Wolfgang Denk]

Dear Grant,

in message <fa686aa40803171643y7db21cadsc454a713ba6c4342@mail.gmail.com> 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: wd@denx.de
If some day we are defeated, well, war has  its  fortunes,  good  and
bad.
	-- Commander Kor, "Errand of Mercy", stardate 3201.7

Re: Please pull linux-2.6-mpc52xx.git

[Grant Likely]

On Mon, Mar 17, 2008 at 6:26 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Grant,
>
>
>  in message <fa686aa40803171643y7db21cadsc454a713ba6c4342@mail.gmail.com> 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.

Re: Please pull linux-2.6-mpc52xx.git

[Josh Boyer]

On Mon, 17 Mar 2008 20:42:14 -0600
"Grant Likely" <grant.likely@secretlab.ca> wrote:

> On Mon, Mar 17, 2008 at 6:26 PM, Wolfgang Denk <wd@denx.de> wrote:
> > Dear Grant,
> >
> >
> >  in message <fa686aa40803171643y7db21cadsc454a713ba6c4342@mail.gmail.com> 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

Re: Please pull linux-2.6-mpc52xx.git

[Bartlomiej Sieka]

Grant Likely wrote:
> On Mon, Mar 17, 2008 at 4:28 PM, Wolfgang Denk <wd@denx.de> 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

Re: Please pull linux-2.6-mpc52xx.git

[Richard Purdie]

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

Re: Please pull linux-2.6-mpc52xx.git

[Bartlomiej Sieka]

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

Re: Please pull linux-2.6-mpc52xx.git

[Grant Likely]

On Tue, Mar 18, 2008 at 2:29 AM, Bartlomiej Sieka <tur@semihalf.com> 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.

Re: Please pull linux-2.6-mpc52xx.git

[Richard Purdie]

On Tue, 2008-03-18 at 08:47 -0600, Grant Likely wrote:
> On Tue, Mar 18, 2008 at 2:29 AM, Bartlomiej Sieka <tur@semihalf.com> 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

Re: Please pull linux-2.6-mpc52xx.git

[Grant Likely]

On Tue, Mar 18, 2008 at 10:41 AM, Richard Purdie <rpurdie@rpsys.net> 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.

Re: Please pull linux-2.6-mpc52xx.git

[Bartlomiej Sieka]

Grant Likely wrote:
> On Tue, Mar 18, 2008 at 10:41 AM, Richard Purdie <rpurdie@rpsys.net> 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

Re: Please pull linux-2.6-mpc52xx.git

[Grant Likely]

On Tue, Mar 25, 2008 at 10:50 AM, Bartlomiej Sieka <tur@semihalf.com> wrote:
> Grant Likely wrote:
>  > On Tue, Mar 18, 2008 at 10:41 AM, Richard Purdie <rpurdie@rpsys.net> 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.

Re: Please pull linux-2.6-mpc52xx.git

[Bartlomiej Sieka]

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

Re: Please pull linux-2.6-mpc52xx.git

[Grant Likely]

On Tue, Mar 25, 2008 at 11:38 AM, Bartlomiej Sieka <tur@semihalf.com> 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.

Re: Please pull linux-2.6-mpc52xx.git

[Bartlomiej Sieka]

Hi Grant,

Grant Likely wrote:
> On Tue, Mar 25, 2008 at 11:38 AM, Bartlomiej Sieka <tur@semihalf.com> 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

Re: Please pull linux-2.6-mpc52xx.git

[Bartlomiej Sieka]

Bartlomiej Sieka wrote:
> Hi Grant,
> 
> Grant Likely wrote:
>> On Tue, Mar 25, 2008 at 11:38 AM, Bartlomiej Sieka <tur@semihalf.com> 
>> 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

Re: Please pull linux-2.6-mpc52xx.git

[Grant Likely]

On Fri, Apr 4, 2008 at 5:13 AM, Bartlomiej Sieka <tur@semihalf.com> 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.

Re: Please pull linux-2.6-mpc52xx.git

[Grant Likely]

On Fri, Apr 4, 2008 at 10:11 AM, Grant Likely <grant.likely@secretlab.ca> 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.

Re: Please pull linux-2.6-mpc52xx.git

[Olof Johansson]

On Fri, Apr 04, 2008 at 10:14:34AM -0600, Grant Likely wrote:
> On Fri, Apr 4, 2008 at 10:11 AM, Grant Likely <grant.likely@secretlab.ca> 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

Re: Please pull linux-2.6-mpc52xx.git

[Josh Boyer]

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 <grant.likely@secretlab.ca> 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/<board>_defconfig
configs/40x/<board>_defconfig

josh

Re: Please pull linux-2.6-mpc52xx.git

[Grant Likely]

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/<board>_defconfig
>  configs/40x/<board>_defconfig

Sounds logical.  I'm cool with this.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: Please pull linux-2.6-mpc52xx.git

[Bartlomiej Sieka]

Hi Grant,

Grant Likely wrote:
> On Fri, Apr 4, 2008 at 5:13 AM, Bartlomiej Sieka <tur@semihalf.com> 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

Re: Please pull linux-2.6-mpc52xx.git

[Bartlomiej Sieka]

Grant Likely wrote:
> On Mon, Mar 17, 2008 at 9:57 AM, Bartlomiej Sieka <tur@semihalf.com> 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

Please pull linux-2.6-mpc52xx.git

[Grant Likely]

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.
grant.likely@secretlab.ca
(403) 399-0195

Re: Please pull linux-2.6-mpc52xx.git

[tnt]

> 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