Re: Alternative for defconfig

2010-06-18 Thread Felipe Contreras
On Wed, Jun 16, 2010 at 10:56 AM, Tony Lindgren t...@atomide.com wrote:
 * Felipe Contreras felipe.contre...@gmail.com [100611 19:03]:
 On Fri, Jun 11, 2010 at 6:07 PM, Laurent Pinchart
 laurent.pinch...@ideasonboard.com wrote:
  My understanding is that Linus will remove all ARM defconfigs in 2.6.36,
  unless someone can convince him not to.

 Huh? I thought he was only threatening to remove them[1]. I don't
 think he said he was going to do that without any alternative in
 place.

 My suggestion[2] was to have minimal defconfigs so that we could do
 $ cp arch/arm/configs/omap3_beagle_baseconfig .config
 $ echo  | make ARCH=arm oldconfig

 [1] http://article.gmane.org/gmane.linux.kernel/994194
 [2] http://article.gmane.org/gmane.linux.kernel/995412

 Sounds like the defconfigs will be going though and we'll use
 some Kconfig based system that's still open. I believe Russell
 said he is not taking any more defconfig patches, so we should
 not merge them either.

 Anyways, we already have multi-omap mostly working for both
 mach-omap1 and mach-omap2.

Cool, that's a much better approach :)

Although it still doesn't solve the problem of default configuration
for certain boards... I doubt many people know how to enable USB,
audio, and so on. We would probably need some place to share
configuration samples and documentation.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Alternative for defconfig

2010-06-17 Thread Tony Lindgren
* Tony Lindgren t...@atomide.com [100616 10:50]:
 * Felipe Contreras felipe.contre...@gmail.com [100611 19:03]:
  On Fri, Jun 11, 2010 at 6:07 PM, Laurent Pinchart
  laurent.pinch...@ideasonboard.com wrote:
   My understanding is that Linus will remove all ARM defconfigs in 2.6.36,
   unless someone can convince him not to.
  
  Huh? I thought he was only threatening to remove them[1]. I don't
  think he said he was going to do that without any alternative in
  place.
  
  My suggestion[2] was to have minimal defconfigs so that we could do
  $ cp arch/arm/configs/omap3_beagle_baseconfig .config
  $ echo  | make ARCH=arm oldconfig
  
  [1] http://article.gmane.org/gmane.linux.kernel/994194
  [2] http://article.gmane.org/gmane.linux.kernel/995412
 
 Sounds like the defconfigs will be going though and we'll use
 some Kconfig based system that's still open. I believe Russell
 said he is not taking any more defconfig patches, so we should
 not merge them either.
 
 Anyways, we already have multi-omap mostly working for both
 mach-omap1 and mach-omap2.
 
 So the remaining things to do are:
 
 1. For mach-omap1, patch entry-macro.S to allow compiling in
7xx, 15xx and 16xx. This can be done in a similar way as
for mach-omap2. The only issue is how to detect 7xx from
other mach-omap1 omaps. If anybody has a chance to work
on this, please go for it!

Have not done anything about this.
 
 2. The old omap_cfg_reg mux function needs to disappear
for mach-omap2 and use the new mux code instead. I'm
currently working on this and should have it ready
for testing this week.

Got finally rid of these. These are in devel-mux branch
on top of the devel-tls branch.
 
 3. To boot both ARMv6 and 7, we need to get rid of
CONFIG_HAS_TLS_REG. I already have a patch for that,
I'll try to update that during this week.

Need to still look at this, but a working version is in
devel-tls branch.
 
 4. To make CONFIG_VFP work for both ARMv6 and 7, we need
to fix CONFIG_VFPv3 so it boots on ARMv6 too. It currently
oopses. Will take a look at this after I'm done with the
CONFIG_HAS_TLS_REG. This is another one where some help
would be nice. To reproduce, boot Linux on ARMv6 with
CONFIG_VFPv3 set.

Got this fixed, but need to still test. Also in devel-tls
branch.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Alternative for defconfig

2010-06-16 Thread Tony Lindgren
* Felipe Contreras felipe.contre...@gmail.com [100611 19:03]:
 On Fri, Jun 11, 2010 at 6:07 PM, Laurent Pinchart
 laurent.pinch...@ideasonboard.com wrote:
  My understanding is that Linus will remove all ARM defconfigs in 2.6.36,
  unless someone can convince him not to.
 
 Huh? I thought he was only threatening to remove them[1]. I don't
 think he said he was going to do that without any alternative in
 place.
 
 My suggestion[2] was to have minimal defconfigs so that we could do
 $ cp arch/arm/configs/omap3_beagle_baseconfig .config
 $ echo  | make ARCH=arm oldconfig
 
 [1] http://article.gmane.org/gmane.linux.kernel/994194
 [2] http://article.gmane.org/gmane.linux.kernel/995412

Sounds like the defconfigs will be going though and we'll use
some Kconfig based system that's still open. I believe Russell
said he is not taking any more defconfig patches, so we should
not merge them either.

Anyways, we already have multi-omap mostly working for both
mach-omap1 and mach-omap2.

So the remaining things to do are:

1. For mach-omap1, patch entry-macro.S to allow compiling in
   7xx, 15xx and 16xx. This can be done in a similar way as
   for mach-omap2. The only issue is how to detect 7xx from
   other mach-omap1 omaps. If anybody has a chance to work
   on this, please go for it!

2. The old omap_cfg_reg mux function needs to disappear
   for mach-omap2 and use the new mux code instead. I'm
   currently working on this and should have it ready
   for testing this week.

3. To boot both ARMv6 and 7, we need to get rid of
   CONFIG_HAS_TLS_REG. I already have a patch for that,
   I'll try to update that during this week.

4. To make CONFIG_VFP work for both ARMv6 and 7, we need
   to fix CONFIG_VFPv3 so it boots on ARMv6 too. It currently
   oopses. Will take a look at this after I'm done with the
   CONFIG_HAS_TLS_REG. This is another one where some help
   would be nice. To reproduce, boot Linux on ARMv6 with
   CONFIG_VFPv3 set.

5. After all this works, we can participate on building
   in multiple ARM platforms :)

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Alternative for defconfig

2010-06-11 Thread Felipe Contreras
On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar x0133...@ti.com wrote:
 1. What is the alternative way of submitting defconfig changes/files to LO?

I don't think we have any alternative yet.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: Alternative for defconfig

2010-06-11 Thread Aguirre, Sergio


 -Original Message-
 From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] On Behalf Of Felipe Contreras
 Sent: Friday, June 11, 2010 8:43 AM
 To: Nagarajan, Rajkumar
 Cc: Laurent Pinchart; linux-media@vger.kernel.org; Hiremath, Vaibhav;
 linux-o...@vger.kernel.org
 Subject: Re: Alternative for defconfig
 
 On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar x0133...@ti.com
 wrote:
  1. What is the alternative way of submitting defconfig changes/files to
 LO?

I don't think defconfig changes are prohibited now. If I understand
correctly, Linus just hates the fact that there is a big percentage of
patches for defconfigs. Maybe he wants us to hold these, and better
provide higher percentage of actual code changes.

What about holding defconfig changes in a separate branch, and just send
them for upstream once in a while, specially if there's a big quantity of
them in the queue?

IMHO, defconfigs are just meant to make us life easier, but changes to them
should _never_ be a fix/solution to any problem, and therefore I understand
that those aren't a priority over regressions.

Regards,
Sergio

 
 I don't think we have any alternative yet.
 
 --
 Felipe Contreras
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Alternative for defconfig

2010-06-11 Thread Laurent Pinchart
Hi Sergio,

On Friday 11 June 2010 16:55:07 Aguirre, Sergio wrote:
  -Original Message-
  From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
  ow...@vger.kernel.org] On Behalf Of Felipe Contreras
  Sent: Friday, June 11, 2010 8:43 AM
  To: Nagarajan, Rajkumar
  Cc: Laurent Pinchart; linux-media@vger.kernel.org; Hiremath, Vaibhav;
  linux-o...@vger.kernel.org
  Subject: Re: Alternative for defconfig
  
  On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar wrote:
   1. What is the alternative way of submitting defconfig changes/files to
  
  LO?
 
 I don't think defconfig changes are prohibited now. If I understand
 correctly, Linus just hates the fact that there is a big percentage of
 patches for defconfigs. Maybe he wants us to hold these, and better
 provide higher percentage of actual code changes.
 
 What about holding defconfig changes in a separate branch, and just send
 them for upstream once in a while, specially if there's a big quantity of
 them in the queue?
 
 IMHO, defconfigs are just meant to make us life easier, but changes to them
 should _never_ be a fix/solution to any problem, and therefore I understand
 that those aren't a priority over regressions.

My understanding is that Linus will remove all ARM defconfigs in 2.6.36, 
unless someone can convince him not to. Board-specific defconfigs won't be 
allowed anymore, the number of defconfigs needs to be reduced drastically 
(ideally to one or two only).

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: Alternative for defconfig

2010-06-11 Thread Aguirre, Sergio
Hi Laurent,

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Friday, June 11, 2010 10:08 AM
 To: Aguirre, Sergio
 Cc: Felipe Contreras; Nagarajan, Rajkumar; linux-media@vger.kernel.org;
 Hiremath, Vaibhav; linux-o...@vger.kernel.org
 Subject: Re: Alternative for defconfig
 
 Hi Sergio,
 
 On Friday 11 June 2010 16:55:07 Aguirre, Sergio wrote:
   -Original Message-
   From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
   ow...@vger.kernel.org] On Behalf Of Felipe Contreras
   Sent: Friday, June 11, 2010 8:43 AM
   To: Nagarajan, Rajkumar
   Cc: Laurent Pinchart; linux-media@vger.kernel.org; Hiremath, Vaibhav;
   linux-o...@vger.kernel.org
   Subject: Re: Alternative for defconfig
  
   On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar wrote:
1. What is the alternative way of submitting defconfig changes/files
 to
  
   LO?
 
  I don't think defconfig changes are prohibited now. If I understand
  correctly, Linus just hates the fact that there is a big percentage of
  patches for defconfigs. Maybe he wants us to hold these, and better
  provide higher percentage of actual code changes.
 
  What about holding defconfig changes in a separate branch, and just send
  them for upstream once in a while, specially if there's a big quantity
 of
  them in the queue?
 
  IMHO, defconfigs are just meant to make us life easier, but changes to
 them
  should _never_ be a fix/solution to any problem, and therefore I
 understand
  that those aren't a priority over regressions.
 
 My understanding is that Linus will remove all ARM defconfigs in 2.6.36,
 unless someone can convince him not to. Board-specific defconfigs won't be
 allowed anymore, the number of defconfigs needs to be reduced drastically
 (ideally to one or two only).

Hmm, Interesting...

We will be now forced to resolve some potential hidden issues with
ARM multibuilds (like the ones showing up when creating the
omap3_defconfig), and that's a great motivation to nail down all possible
portability problems.

/me likes that :)

Regards,
Sergio

 
 --
 Regards,
 
 Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: Alternative for defconfig

2010-06-11 Thread Gadiyar, Anand
Laurent Pinchart wrote:
 On Friday 11 June 2010 16:55:07 Aguirre, Sergio wrote:
   On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar wrote:
1. What is the alternative way of submitting defconfig changes/files to
   
   LO?
  
  I don't think defconfig changes are prohibited now. If I understand
  correctly, Linus just hates the fact that there is a big percentage of
  patches for defconfigs. Maybe he wants us to hold these, and better
  provide higher percentage of actual code changes.
  
  What about holding defconfig changes in a separate branch, and just send
  them for upstream once in a while, specially if there's a big quantity of
  them in the queue?
  
  IMHO, defconfigs are just meant to make us life easier, but changes to them
  should _never_ be a fix/solution to any problem, and therefore I understand
  that those aren't a priority over regressions.
 
 My understanding is that Linus will remove all ARM defconfigs in 2.6.36, 
 unless someone can convince him not to. Board-specific defconfigs won't be 
 allowed anymore, the number of defconfigs needs to be reduced drastically 
 (ideally to one or two only).
 

There is some good work going on on the linux-arm-kernel mailing list to
cut down heavily the ARM defconfigs. Would be good to join that discussion.

For OMAP, I suppose maintaining omap1_defconfig and omap3_defconfig would
suffice to cover all OMAPs?

- Anand
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Alternative for defconfig

2010-06-11 Thread Laurent Pinchart
Hi Anand,

On Friday 11 June 2010 17:14:19 Gadiyar, Anand wrote:
 Laurent Pinchart wrote:
  On Friday 11 June 2010 16:55:07 Aguirre, Sergio wrote:
On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar wrote:
 1. What is the alternative way of submitting defconfig
 changes/files to

LO?
   
   I don't think defconfig changes are prohibited now. If I understand
   correctly, Linus just hates the fact that there is a big percentage of
   patches for defconfigs. Maybe he wants us to hold these, and better
   provide higher percentage of actual code changes.
   
   What about holding defconfig changes in a separate branch, and just
   send them for upstream once in a while, specially if there's a big
   quantity of them in the queue?
   
   IMHO, defconfigs are just meant to make us life easier, but changes to
   them should _never_ be a fix/solution to any problem, and therefore I
   understand that those aren't a priority over regressions.
  
  My understanding is that Linus will remove all ARM defconfigs in 2.6.36,
  unless someone can convince him not to. Board-specific defconfigs won't
  be allowed anymore, the number of defconfigs needs to be reduced
  drastically (ideally to one or two only).
 
 There is some good work going on on the linux-arm-kernel mailing list to
 cut down heavily the ARM defconfigs. Would be good to join that discussion.
 
 For OMAP, I suppose maintaining omap1_defconfig and omap3_defconfig would
 suffice to cover all OMAPs?

I'm not sure what the exact roadmap will be. Linus is complaining about the 
defconfig changes taking up too much of the diffstat. I don't know if he will 
accept patches to solve the problem gradually, or if he will just remove all 
defconfig files in 2.6.36.

In any case, all changes that make it possible to built more machine types and 
platform types in the same kernel are a step in the right direction.

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: Alternative for defconfig

2010-06-11 Thread Aguirre, Sergio


 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Friday, June 11, 2010 10:26 AM
 To: Gadiyar, Anand
 Cc: Aguirre, Sergio; Felipe Contreras; Nagarajan, Rajkumar; linux-
 me...@vger.kernel.org; Hiremath, Vaibhav; linux-o...@vger.kernel.org
 Subject: Re: Alternative for defconfig
 
 Hi Anand,
 
 On Friday 11 June 2010 17:14:19 Gadiyar, Anand wrote:
  Laurent Pinchart wrote:
   On Friday 11 June 2010 16:55:07 Aguirre, Sergio wrote:
 On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar wrote:
  1. What is the alternative way of submitting defconfig
  changes/files to

 LO?
   
I don't think defconfig changes are prohibited now. If I understand
correctly, Linus just hates the fact that there is a big percentage
 of
patches for defconfigs. Maybe he wants us to hold these, and better
provide higher percentage of actual code changes.
   
What about holding defconfig changes in a separate branch, and just
send them for upstream once in a while, specially if there's a big
quantity of them in the queue?
   
IMHO, defconfigs are just meant to make us life easier, but changes
 to
them should _never_ be a fix/solution to any problem, and therefore
 I
understand that those aren't a priority over regressions.
  
   My understanding is that Linus will remove all ARM defconfigs in
 2.6.36,
   unless someone can convince him not to. Board-specific defconfigs
 won't
   be allowed anymore, the number of defconfigs needs to be reduced
   drastically (ideally to one or two only).
 
  There is some good work going on on the linux-arm-kernel mailing list to
  cut down heavily the ARM defconfigs. Would be good to join that
 discussion.
 
  For OMAP, I suppose maintaining omap1_defconfig and omap3_defconfig
 would
  suffice to cover all OMAPs?
 
 I'm not sure what the exact roadmap will be. Linus is complaining about
 the
 defconfig changes taking up too much of the diffstat. I don't know if he
 will
 accept patches to solve the problem gradually, or if he will just remove
 all
 defconfig files in 2.6.36.
 
 In any case, all changes that make it possible to built more machine types
 and
 platform types in the same kernel are a step in the right direction.

I definitely think that one important step to achieve a multi platform build
is to detect the minimal arm_defconfig first, and then (most importantly
IMHO) proceed with trying to generate kernel modules of almost all
peripherals.

Many boards tend to be tested with just monolithic single-platform kernels,
and making things modular hasn't been addressed at all in some drivers (old
OMAP DSS code, for example).

Regards,
Sergio

 
 --
 Regards,
 
 Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Alternative for defconfig

2010-06-11 Thread Felipe Contreras
On Fri, Jun 11, 2010 at 6:07 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 My understanding is that Linus will remove all ARM defconfigs in 2.6.36,
 unless someone can convince him not to.

Huh? I thought he was only threatening to remove them[1]. I don't
think he said he was going to do that without any alternative in
place.

My suggestion[2] was to have minimal defconfigs so that we could do
$ cp arch/arm/configs/omap3_beagle_baseconfig .config
$ echo  | make ARCH=arm oldconfig

[1] http://article.gmane.org/gmane.linux.kernel/994194
[2] http://article.gmane.org/gmane.linux.kernel/995412

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html