[PATCH] OMAP: V4L2: Enable V4L2 on ZOOM2/3 & 3630SDP

[PATCH] OMAP: V4L2: Enable V4L2 on ZOOM2/3 & 3630SDP

[Nagarajan, Rajkumar]

Defconfig changes to enable V4L2 on zoom2, zoom3 and 3630sdp boards.

Signed-off-by: Mukund Mittal <mmittal@ti.com>
Signed-off-by: Sudeep Basavaraj <sudeep.basavaraj@ti.com>
Signed-off-by: Kishore Y <kishore.y@ti.com>
Signed-off-by: Rajkumar N <rajkumar.nagarajan@ti.com>
---
 arch/arm/configs/omap_3630sdp_defconfig |  100 ++++++++++++++++++++++++++++++-
 arch/arm/configs/omap_zoom2_defconfig   |   91 +++++++++++++++++++++++++++-
 arch/arm/configs/omap_zoom3_defconfig   |  100 ++++++++++++++++++++++++++++++-
 3 files changed, 284 insertions(+), 7 deletions(-)

diff --git a/arch/arm/configs/omap_3630sdp_defconfig b/arch/arm/configs/omap_3630sdp_defconfig
index 57c1c4f..6b6da13 100644
--- a/arch/arm/configs/omap_3630sdp_defconfig
+++ b/arch/arm/configs/omap_3630sdp_defconfig
@@ -879,7 +879,103 @@ CONFIG_REGULATOR_TWL4030=y
 # CONFIG_REGULATOR_LP3971 is not set
 # CONFIG_REGULATOR_TPS65023 is not set
 # CONFIG_REGULATOR_TPS6507X is not set
-# CONFIG_MEDIA_SUPPORT is not set
+CONFIG_MEDIA_SUPPORT=y
+
+#
+# Multimedia core support
+#
+CONFIG_VIDEO_DEV=y
+CONFIG_VIDEO_V4L2_COMMON=y
+# CONFIG_VIDEO_ALLOW_V4L1 is not set
+CONFIG_VIDEO_V4L1_COMPAT=y
+# CONFIG_DVB_CORE is not set
+CONFIG_VIDEO_MEDIA=y
+
+#
+# Multimedia drivers
+#
+# CONFIG_MEDIA_ATTACH is not set
+CONFIG_MEDIA_TUNER=y
+# CONFIG_MEDIA_TUNER_CUSTOMISE is not set
+CONFIG_MEDIA_TUNER_SIMPLE=y
+CONFIG_MEDIA_TUNER_TDA8290=y
+CONFIG_MEDIA_TUNER_TDA9887=y
+CONFIG_MEDIA_TUNER_TEA5761=y
+CONFIG_MEDIA_TUNER_TEA5767=y
+CONFIG_MEDIA_TUNER_MT20XX=y
+CONFIG_MEDIA_TUNER_XC2028=y
+CONFIG_MEDIA_TUNER_XC5000=y
+CONFIG_MEDIA_TUNER_MC44S803=y
+CONFIG_VIDEO_V4L2=y
+CONFIG_VIDEOBUF_GEN=y
+CONFIG_VIDEOBUF_DMA_SG=y
+CONFIG_VIDEO_CAPTURE_DRIVERS=y
+# CONFIG_VIDEO_ADV_DEBUG is not set
+# CONFIG_VIDEO_FIXED_MINOR_RANGES is not set
+CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
+# CONFIG_VIDEO_VIVI is not set
+# CONFIG_VIDEO_SAA5246A is not set
+# CONFIG_VIDEO_SAA5249 is not set
+CONFIG_VIDEO_OMAP3_OUT=y
+CONFIG_VIDEO_OMAP2_VOUT=y
+# CONFIG_SOC_CAMERA is not set
+CONFIG_V4L_USB_DRIVERS=y
+# CONFIG_USB_VIDEO_CLASS is not set
+CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y
+CONFIG_USB_GSPCA=m
+# CONFIG_USB_M5602 is not set
+# CONFIG_USB_STV06XX is not set
+# CONFIG_USB_GL860 is not set
+# CONFIG_USB_GSPCA_CONEX is not set
+# CONFIG_USB_GSPCA_ETOMS is not set
+# CONFIG_USB_GSPCA_FINEPIX is not set
+# CONFIG_USB_GSPCA_JEILINJ is not set
+# CONFIG_USB_GSPCA_MARS is not set
+# CONFIG_USB_GSPCA_MR97310A is not set
+# CONFIG_USB_GSPCA_OV519 is not set
+# CONFIG_USB_GSPCA_OV534 is not set
+# CONFIG_USB_GSPCA_PAC207 is not set
+# CONFIG_USB_GSPCA_PAC7302 is not set
+# CONFIG_USB_GSPCA_PAC7311 is not set
+# CONFIG_USB_GSPCA_SN9C20X is not set
+# CONFIG_USB_GSPCA_SONIXB is not set
+# CONFIG_USB_GSPCA_SONIXJ is not set
+# CONFIG_USB_GSPCA_SPCA500 is not set
+# CONFIG_USB_GSPCA_SPCA501 is not set
+# CONFIG_USB_GSPCA_SPCA505 is not set
+# CONFIG_USB_GSPCA_SPCA506 is not set
+# CONFIG_USB_GSPCA_SPCA508 is not set
+# CONFIG_USB_GSPCA_SPCA561 is not set
+# CONFIG_USB_GSPCA_SQ905 is not set
+# CONFIG_USB_GSPCA_SQ905C is not set
+# CONFIG_USB_GSPCA_STK014 is not set
+# CONFIG_USB_GSPCA_STV0680 is not set
+# CONFIG_USB_GSPCA_SUNPLUS is not set
+# CONFIG_USB_GSPCA_T613 is not set
+# CONFIG_USB_GSPCA_TV8532 is not set
+# CONFIG_USB_GSPCA_VC032X is not set
+# CONFIG_USB_GSPCA_ZC3XX is not set
+# CONFIG_VIDEO_PVRUSB2 is not set
+# CONFIG_VIDEO_HDPVR is not set
+# CONFIG_VIDEO_EM28XX is not set
+# CONFIG_VIDEO_CX231XX is not set
+# CONFIG_VIDEO_USBVISION is not set
+# CONFIG_USB_ET61X251 is not set
+# CONFIG_USB_SN9C102 is not set
+# CONFIG_USB_ZC0301 is not set
+CONFIG_USB_PWC_INPUT_EVDEV=y
+# CONFIG_USB_ZR364XX is not set
+# CONFIG_USB_STKWEBCAM is not set
+# CONFIG_USB_S2255 is not set
+CONFIG_RADIO_ADAPTERS=y
+# CONFIG_I2C_SI4713 is not set
+# CONFIG_RADIO_SI4713 is not set
+# CONFIG_USB_DSBR is not set
+# CONFIG_RADIO_SI470X is not set
+# CONFIG_USB_MR800 is not set
+# CONFIG_RADIO_TEA5764 is not set
+# CONFIG_RADIO_TEF6862 is not set
+# CONFIG_DAB is not set
 
 #
 # Graphics support
@@ -929,7 +1025,7 @@ CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=4
 CONFIG_FB_OMAP2=y
 # CONFIG_FB_OMAP2_DEBUG_SUPPORT is not set
 # CONFIG_FB_OMAP2_FORCE_AUTO_UPDATE is not set
-CONFIG_FB_OMAP2_NUM_FBS=3
+CONFIG_FB_OMAP2_NUM_FBS=1
 
 #
 # OMAP2/3 Display Device Drivers
diff --git a/arch/arm/configs/omap_zoom2_defconfig b/arch/arm/configs/omap_zoom2_defconfig
index 50b2bb8..a95a550 100644
--- a/arch/arm/configs/omap_zoom2_defconfig
+++ b/arch/arm/configs/omap_zoom2_defconfig
@@ -845,12 +845,96 @@ CONFIG_TWL4030_CORE=y
 #
 # Multimedia core support
 #
-# CONFIG_VIDEO_DEV is not set
+CONFIG_VIDEO_DEV=y
+CONFIG_VIDEO_V4L2_COMMON=y
+# CONFIG_VIDEO_ALLOW_V4L1 is not set
+CONFIG_VIDEO_V4L1_COMPAT=y
 # CONFIG_DVB_CORE is not set
-# CONFIG_VIDEO_MEDIA is not set
+CONFIG_VIDEO_MEDIA=y
 
 #
 # Multimedia drivers
+# CONFIG_MEDIA_ATTACH is not set
+CONFIG_MEDIA_TUNER=y
+# CONFIG_MEDIA_TUNER_CUSTOMISE is not set
+CONFIG_MEDIA_TUNER_SIMPLE=y
+CONFIG_MEDIA_TUNER_TDA8290=y
+CONFIG_MEDIA_TUNER_TDA9887=y
+CONFIG_MEDIA_TUNER_TEA5761=y
+CONFIG_MEDIA_TUNER_TEA5767=y
+CONFIG_MEDIA_TUNER_MT20XX=y
+CONFIG_MEDIA_TUNER_XC2028=y
+CONFIG_MEDIA_TUNER_XC5000=y
+CONFIG_MEDIA_TUNER_MC44S803=y
+CONFIG_VIDEO_V4L2=y
+CONFIG_VIDEOBUF_GEN=y
+CONFIG_VIDEOBUF_DMA_SG=y
+CONFIG_VIDEO_CAPTURE_DRIVERS=y
+# CONFIG_VIDEO_ADV_DEBUG is not set
+# CONFIG_VIDEO_FIXED_MINOR_RANGES is not set
+CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
+# CONFIG_VIDEO_VIVI is not set
+# CONFIG_VIDEO_SAA5246A is not set
+# CONFIG_VIDEO_SAA5249 is not set
+CONFIG_VIDEO_OMAP3_OUT=y
+CONFIG_VIDEO_OMAP2_VOUT=y
+# CONFIG_SOC_CAMERA is not set
+CONFIG_V4L_USB_DRIVERS=y
+# CONFIG_USB_VIDEO_CLASS is not set
+CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y
+CONFIG_USB_GSPCA=m
+# CONFIG_USB_M5602 is not set
+# CONFIG_USB_STV06XX is not set
+# CONFIG_USB_GL860 is not set
+# CONFIG_USB_GSPCA_CONEX is not set
+# CONFIG_USB_GSPCA_ETOMS is not set
+# CONFIG_USB_GSPCA_FINEPIX is not set
+# CONFIG_USB_GSPCA_JEILINJ is not set
+# CONFIG_USB_GSPCA_MARS is not set
+# CONFIG_USB_GSPCA_MR97310A is not set
+# CONFIG_USB_GSPCA_OV519 is not set
+# CONFIG_USB_GSPCA_OV534 is not set
+# CONFIG_USB_GSPCA_PAC207 is not set
+# CONFIG_USB_GSPCA_PAC7302 is not set
+# CONFIG_USB_GSPCA_PAC7311 is not set
+# CONFIG_USB_GSPCA_SN9C20X is not set
+# CONFIG_USB_GSPCA_SONIXB is not set
+# CONFIG_USB_GSPCA_SONIXJ is not set
+# CONFIG_USB_GSPCA_SPCA500 is not set
+# CONFIG_USB_GSPCA_SPCA501 is not set
+# CONFIG_USB_GSPCA_SPCA505 is not set
+# CONFIG_USB_GSPCA_SPCA506 is not set
+# CONFIG_USB_GSPCA_SPCA508 is not set
+# CONFIG_USB_GSPCA_SPCA561 is not set
+# CONFIG_USB_GSPCA_SQ905 is not set
+# CONFIG_USB_GSPCA_SQ905C is not set
+# CONFIG_USB_GSPCA_STK014 is not set
+# CONFIG_USB_GSPCA_STV0680 is not set
+# CONFIG_USB_GSPCA_SUNPLUS is not set
+# CONFIG_USB_GSPCA_T613 is not set
+# CONFIG_USB_GSPCA_TV8532 is not set
+# CONFIG_USB_GSPCA_VC032X is not set
+# CONFIG_USB_GSPCA_ZC3XX is not set
+# CONFIG_VIDEO_PVRUSB2 is not set
+# CONFIG_VIDEO_HDPVR is not set
+# CONFIG_VIDEO_EM28XX is not set
+# CONFIG_VIDEO_CX231XX is not set
+# CONFIG_VIDEO_USBVISION is not set
+# CONFIG_USB_ET61X251 is not set
+# CONFIG_USB_SN9C102 is not set
+# CONFIG_USB_ZC0301 is not set
+CONFIG_USB_PWC_INPUT_EVDEV=y
+# CONFIG_USB_ZR364XX is not set
+# CONFIG_USB_STKWEBCAM is not set
+# CONFIG_USB_S2255 is not set
+CONFIG_RADIO_ADAPTERS=y
+# CONFIG_I2C_SI4713 is not set
+# CONFIG_RADIO_SI4713 is not set
+# CONFIG_USB_DSBR is not set
+# CONFIG_RADIO_SI470X is not set
+# CONFIG_USB_MR800 is not set
+# CONFIG_RADIO_TEA5764 is not set
+# CONFIG_RADIO_TEF6862 is not set
 #
 CONFIG_DAB=y
 # CONFIG_USB_DABUSB is not set
@@ -903,7 +987,7 @@ CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=4
 CONFIG_FB_OMAP2=y
 # CONFIG_FB_OMAP2_DEBUG_SUPPORT is not set
 # CONFIG_FB_OMAP2_FORCE_AUTO_UPDATE is not set
-CONFIG_FB_OMAP2_NUM_FBS=3
+CONFIG_FB_OMAP2_NUM_FBS=1
 
 #
 # OMAP2/3 Display Device Drivers
@@ -1226,6 +1310,7 @@ CONFIG_REGULATOR=y
 # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set
 # CONFIG_REGULATOR_BQ24022 is not set
 CONFIG_REGULATOR_TWL4030=y
+CONFIG_MEDIA_SUPPORT=y
 # CONFIG_UIO is not set
 # CONFIG_STAGING is not set
 
diff --git a/arch/arm/configs/omap_zoom3_defconfig b/arch/arm/configs/omap_zoom3_defconfig
index 1098d71..47e0045 100644
--- a/arch/arm/configs/omap_zoom3_defconfig
+++ b/arch/arm/configs/omap_zoom3_defconfig
@@ -880,7 +880,103 @@ CONFIG_REGULATOR_TWL4030=y
 # CONFIG_REGULATOR_LP3971 is not set
 # CONFIG_REGULATOR_TPS65023 is not set
 # CONFIG_REGULATOR_TPS6507X is not set
-# CONFIG_MEDIA_SUPPORT is not set
+CONFIG_MEDIA_SUPPORT=y
+
+#
+# Multimedia core support
+#
+CONFIG_VIDEO_DEV=y
+CONFIG_VIDEO_V4L2_COMMON=y
+# CONFIG_VIDEO_ALLOW_V4L1 is not set
+CONFIG_VIDEO_V4L1_COMPAT=y
+# CONFIG_DVB_CORE is not set
+CONFIG_VIDEO_MEDIA=y
+
+#
+# Multimedia drivers
+#
+# CONFIG_MEDIA_ATTACH is not set
+CONFIG_MEDIA_TUNER=y
+# CONFIG_MEDIA_TUNER_CUSTOMISE is not set
+CONFIG_MEDIA_TUNER_SIMPLE=y
+CONFIG_MEDIA_TUNER_TDA8290=y
+CONFIG_MEDIA_TUNER_TDA9887=y
+CONFIG_MEDIA_TUNER_TEA5761=y
+CONFIG_MEDIA_TUNER_TEA5767=y
+CONFIG_MEDIA_TUNER_MT20XX=y
+CONFIG_MEDIA_TUNER_XC2028=y
+CONFIG_MEDIA_TUNER_XC5000=y
+CONFIG_MEDIA_TUNER_MC44S803=y
+CONFIG_VIDEO_V4L2=y
+CONFIG_VIDEOBUF_GEN=y
+CONFIG_VIDEOBUF_DMA_SG=y
+CONFIG_VIDEO_CAPTURE_DRIVERS=y
+# CONFIG_VIDEO_ADV_DEBUG is not set
+# CONFIG_VIDEO_FIXED_MINOR_RANGES is not set
+CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
+# CONFIG_VIDEO_VIVI is not set
+# CONFIG_VIDEO_SAA5246A is not set
+# CONFIG_VIDEO_SAA5249 is not set
+CONFIG_VIDEO_OMAP3_OUT=y
+CONFIG_VIDEO_OMAP2_VOUT=y
+# CONFIG_SOC_CAMERA is not set
+CONFIG_V4L_USB_DRIVERS=y
+# CONFIG_USB_VIDEO_CLASS is not set
+CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y
+CONFIG_USB_GSPCA=m
+# CONFIG_USB_M5602 is not set
+# CONFIG_USB_STV06XX is not set
+# CONFIG_USB_GL860 is not set
+# CONFIG_USB_GSPCA_CONEX is not set
+# CONFIG_USB_GSPCA_ETOMS is not set
+# CONFIG_USB_GSPCA_FINEPIX is not set
+# CONFIG_USB_GSPCA_JEILINJ is not set
+# CONFIG_USB_GSPCA_MARS is not set
+# CONFIG_USB_GSPCA_MR97310A is not set
+# CONFIG_USB_GSPCA_OV519 is not set
+# CONFIG_USB_GSPCA_OV534 is not set
+# CONFIG_USB_GSPCA_PAC207 is not set
+# CONFIG_USB_GSPCA_PAC7302 is not set
+# CONFIG_USB_GSPCA_PAC7311 is not set
+# CONFIG_USB_GSPCA_SN9C20X is not set
+# CONFIG_USB_GSPCA_SONIXB is not set
+# CONFIG_USB_GSPCA_SONIXJ is not set
+# CONFIG_USB_GSPCA_SPCA500 is not set
+# CONFIG_USB_GSPCA_SPCA501 is not set
+# CONFIG_USB_GSPCA_SPCA505 is not set
+# CONFIG_USB_GSPCA_SPCA506 is not set
+# CONFIG_USB_GSPCA_SPCA508 is not set
+# CONFIG_USB_GSPCA_SPCA561 is not set
+# CONFIG_USB_GSPCA_SQ905 is not set
+# CONFIG_USB_GSPCA_SQ905C is not set
+# CONFIG_USB_GSPCA_STK014 is not set
+# CONFIG_USB_GSPCA_STV0680 is not set
+# CONFIG_USB_GSPCA_SUNPLUS is not set
+# CONFIG_USB_GSPCA_T613 is not set
+# CONFIG_USB_GSPCA_TV8532 is not set
+# CONFIG_USB_GSPCA_VC032X is not set
+# CONFIG_USB_GSPCA_ZC3XX is not set
+# CONFIG_VIDEO_PVRUSB2 is not set
+# CONFIG_VIDEO_HDPVR is not set
+# CONFIG_VIDEO_EM28XX is not set
+# CONFIG_VIDEO_CX231XX is not set
+# CONFIG_VIDEO_USBVISION is not set
+# CONFIG_USB_ET61X251 is not set
+# CONFIG_USB_SN9C102 is not set
+# CONFIG_USB_ZC0301 is not set
+CONFIG_USB_PWC_INPUT_EVDEV=y
+# CONFIG_USB_ZR364XX is not set
+# CONFIG_USB_STKWEBCAM is not set
+# CONFIG_USB_S2255 is not set
+CONFIG_RADIO_ADAPTERS=y
+# CONFIG_I2C_SI4713 is not set
+# CONFIG_RADIO_SI4713 is not set
+# CONFIG_USB_DSBR is not set
+# CONFIG_RADIO_SI470X is not set
+# CONFIG_USB_MR800 is not set
+# CONFIG_RADIO_TEA5764 is not set
+# CONFIG_RADIO_TEF6862 is not set
+# CONFIG_DAB is not set
 
 #
 # Graphics support
@@ -930,7 +1026,7 @@ CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=4
 CONFIG_FB_OMAP2=y
 # CONFIG_FB_OMAP2_DEBUG_SUPPORT is not set
 # CONFIG_FB_OMAP2_FORCE_AUTO_UPDATE is not set
-CONFIG_FB_OMAP2_NUM_FBS=3
+CONFIG_FB_OMAP2_NUM_FBS=1
 
 #
 # OMAP2/3 Display Device Drivers
-- 
1.5.4.3

Re: [PATCH] OMAP: V4L2: Enable V4L2 on ZOOM2/3 & 3630SDP

[Laurent Pinchart]

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: [PATCH] OMAP: V4L2: Enable V4L2 on ZOOM2/3 & 3630SDP

[Hiremath, Vaibhav]

> -----Original Message-----
> From: linux-media-owner@vger.kernel.org [mailto:linux-media-
> owner@vger.kernel.org] On Behalf Of Laurent Pinchart
> 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.
> 
[Hiremath, Vaibhav] That's correct, and also FYI, you must cc linux-omap mailing list for the patches which touch any files under arch/arm/*

Thanks,
Vaibhav

> --
> Regards,
> 
> Laurent Pinchart
> --
> 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

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

[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