Alternative for defconfig

Alternative for defconfig

[Nagarajan, Rajkumar]

Hi,

1. What is the alternative way of submitting defconfig changes/files to LO? 

2. Can any of you give me examples? 

Regards,
Rajkumar N.

> -----Original Message-----
> From: Laurent Pinchart [mailto:laurent.pinchart@ideasonboard.com] 
> Sent: Wednesday, June 09, 2010 3:57 PM
> To: Nagarajan, Rajkumar
> Cc: linux-media@vger.kernel.org
> Subject: Re: [PATCH] OMAP: V4L2: Enable V4L2 on ZOOM2/3 & 3630SDP
> 
> Hi Rajkumar,
> 
> On Wednesday 09 June 2010 11:51:45 Nagarajan, Rajkumar wrote:
> > Defconfig changes to enable V4L2 on zoom2, zoom3 and 3630sdp boards.
> 
> Defconfigs on ARM are going away. See the 
> http://lkml.org/lkml/2010/6/2/472 
> thread on LKML. There's also a lengthy discussion about that 
> on LAKML. Linus 
> will not accept any change to the defconfig files anymore and 
> currently plans 
> to remove them completely for 2.6.36.
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 

Re: Alternative for defconfig

[Felipe Contreras]

On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar <x0133774@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

RE: Alternative for defconfig

[Aguirre, Sergio]

> -----Original Message-----
> From: linux-media-owner@vger.kernel.org [mailto:linux-media-
> owner@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-omap@vger.kernel.org
> Subject: Re: Alternative for defconfig
> 
> On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar <x0133774@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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Alternative for defconfig

[Laurent Pinchart]

Hi Sergio,

On Friday 11 June 2010 16:55:07 Aguirre, Sergio wrote:
> > -----Original Message-----
> > From: linux-media-owner@vger.kernel.org [mailto:linux-media-
> > owner@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-omap@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

RE: Alternative for defconfig

[Aguirre, Sergio]

Hi Laurent,

> -----Original Message-----
> From: Laurent Pinchart [mailto:laurent.pinchart@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-omap@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-owner@vger.kernel.org [mailto:linux-media-
> > > owner@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-omap@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

RE: Alternative for defconfig

[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

Re: Alternative for defconfig

[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

RE: Alternative for defconfig

[Aguirre, Sergio]

> -----Original Message-----
> From: Laurent Pinchart [mailto:laurent.pinchart@ideasonboard.com]
> Sent: Friday, June 11, 2010 10:26 AM
> To: Gadiyar, Anand
> Cc: Aguirre, Sergio; Felipe Contreras; Nagarajan, Rajkumar; linux-
> media@vger.kernel.org; Hiremath, Vaibhav; linux-omap@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

Re: Alternative for defconfig

[Sid Boyce]

On 11/06/10 16:14, 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?
> 
> - Anand

If I use omap3_beagle_defconfig instead of omap3_defconfig HID is
missing from the .config and doesn't show up for selection in "make
config".
Is this an oversight or is omap3_defconfig the proper one to use.
Regards
Sid.
-- 
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

Re: Alternative for defconfig

[Felipe Contreras]

On Fri, Jun 11, 2010 at 6:07 PM, Laurent Pinchart
<laurent.pinchart@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

Re: Alternative for defconfig

[Tony Lindgren]

* Felipe Contreras <felipe.contreras@gmail.com> [100611 19:03]:
> On Fri, Jun 11, 2010 at 6:07 PM, Laurent Pinchart
> <laurent.pinchart@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

Re: Alternative for defconfig

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [100616 10:50]:
> * Felipe Contreras <felipe.contreras@gmail.com> [100611 19:03]:
> > On Fri, Jun 11, 2010 at 6:07 PM, Laurent Pinchart
> > <laurent.pinchart@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

Re: Alternative for defconfig

[Felipe Contreras]

On Wed, Jun 16, 2010 at 10:56 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Felipe Contreras <felipe.contreras@gmail.com> [100611 19:03]:
>> On Fri, Jun 11, 2010 at 6:07 PM, Laurent Pinchart
>> <laurent.pinchart@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