Re: Please pull linux-2.6-mpc52xx.git

In message [off-list ref] 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.

On Mon, Mar 17, 2008 at 4:28 PM, Wolfgang Denk [off-list ref] wrote:

In message [off-list ref] 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.

Grant Likely wrote:

On Mon, Mar 17, 2008 at 4:28 PM, Wolfgang Denk [off-list ref] wrote:

[...]

quoted

 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

On Tue, 2008-03-18 at 09:29 +0100, Bartlomiej Sieka wrote:

Grant Likely wrote:

quoted

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,

quoted

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

On Tue, Mar 18, 2008 at 2:29 AM, Bartlomiej Sieka [off-list ref] 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.

On Tue, 2008-03-18 at 08:47 -0600, Grant Likely wrote:

On Tue, Mar 18, 2008 at 2:29 AM, Bartlomiej Sieka [off-list ref] wrote:

quoted

 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

On Tue, Mar 18, 2008 at 10:41 AM, Richard Purdie [off-list ref] 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.

Richard Purdie wrote:

On Tue, 2008-03-18 at 09:29 +0100, Bartlomiej Sieka wrote:

quoted

Grant Likely wrote:

quoted

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,

quoted

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

Grant Likely wrote:

On Tue, Mar 18, 2008 at 10:41 AM, Richard Purdie [off-list ref] wrote:

quoted

 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

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

On Tue, Mar 25, 2008 at 10:50 AM, Bartlomiej Sieka [off-list ref] wrote:

Grant Likely wrote:
 > On Tue, Mar 18, 2008 at 10:41 AM, Richard Purdie [off-list ref] 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.

On Tue, Mar 25, 2008 at 11:38 AM, Bartlomiej Sieka [off-list ref] 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.

Hi Grant,

Grant Likely wrote:

On Tue, Mar 25, 2008 at 11:38 AM, Bartlomiej Sieka [off-list ref] wrote:

quoted

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).

quoted

 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

Bartlomiej Sieka wrote:

Hi Grant,

Grant Likely wrote:

quoted

On Tue, Mar 25, 2008 at 11:38 AM, Bartlomiej Sieka [off-list ref] wrote:

quoted

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).

quoted

 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:

5 more quoted lines

Grant,

Any thoughts on the above?

Regards,
Bartlomiej

On Fri, Apr 4, 2008 at 5:13 AM, Bartlomiej Sieka [off-list ref] wrote:

Bartlomiej Sieka wrote:

quoted

Hi Grant,

Grant Likely wrote:

quoted

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.

On Fri, Apr 4, 2008 at 10:11 AM, Grant Likely [off-list ref] wrote:

quoted

quoted

quoted

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.

On Fri, Apr 04, 2008 at 10:14:34AM -0600, Grant Likely wrote:

On Fri, Apr 4, 2008 at 10:11 AM, Grant Likely [off-list ref] wrote:

quoted

quoted

quoted

quoted

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

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:

quoted

On Fri, Apr 4, 2008 at 10:11 AM, Grant Likely [off-list ref] wrote:

quoted

quoted

quoted

quoted

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

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.

Hi Grant,

Grant Likely wrote:

On Fri, Apr 4, 2008 at 5:13 AM, Bartlomiej Sieka [off-list ref] wrote:

quoted

Bartlomiej Sieka wrote:

quoted

Hi Grant,

Grant Likely wrote:

quoted

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