[linux-yocto] RFC 500 line media config fragment
Bruce, I've been carrying around a 500 line config fragment from Koen for the MinnowBoard that I would like to eliminate from the BSP. The time to validate these options will be significant, so before I dig in, I'm wondering what we think the best way to deal with these internally to linux-yocto. This fragment enables media APIs, subsystems, webcams, analog and digital TV tuners, etc. I imagine there is sum commonality here that could go in a media-common fragment, like VIDEO_V4L2, etc. A webcam fragment would be logical (do we break that out into USB, PCI, SoC?), what about tuners? digital, analog, satellite, terrestrial, USB, PCI... lots of ways to split it. We didn't split by bus on the wifi features, so the logical split to me would be: media-common.cfg webcam.cfg tuner.cfg Possibly with something like: media-soc.cfg for some of the more specific stuff - or perhaps just eliminate those and rely on the BSP for that SoC to pull those in? Yeah... that I think. media.cfg attached. Any other suggestions? -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ++ .config 2013-04-19 11:55:51.013419546 +0200 CONFIG_FW_LOADER=m CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE="" CONFIG_ALTERA_STAPL=m CONFIG_MFD_WL1273_CORE=m CONFIG_MEDIA_CAMERA_SUPPORT=y CONFIG_MEDIA_ANALOG_TV_SUPPORT=y CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y CONFIG_MEDIA_RADIO_SUPPORT=y CONFIG_MEDIA_RC_SUPPORT=y CONFIG_MEDIA_CONTROLLER=y CONFIG_VIDEO_DEV=y CONFIG_VIDEO_V4L2_SUBDEV_API=y CONFIG_VIDEO_V4L2=y CONFIG_VIDEO_TUNER=m CONFIG_V4L2_MEM2MEM_DEV=m CONFIG_VIDEOBUF_GEN=m CONFIG_VIDEOBUF_DMA_SG=m CONFIG_VIDEOBUF_VMALLOC=m CONFIG_VIDEOBUF_DVB=m CONFIG_VIDEOBUF2_CORE=m CONFIG_VIDEOBUF2_MEMOPS=m CONFIG_VIDEOBUF2_DMA_CONTIG=m CONFIG_VIDEOBUF2_VMALLOC=m CONFIG_DVB_CORE=y CONFIG_DVB_NET=y CONFIG_DVB_MAX_ADAPTERS=8 CONFIG_DVB_DYNAMIC_MINORS=y CONFIG_RC_CORE=y CONFIG_RC_MAP=y CONFIG_RC_DECODERS=y CONFIG_LIRC=m CONFIG_IR_LIRC_CODEC=m CONFIG_IR_NEC_DECODER=y CONFIG_IR_RC5_DECODER=y CONFIG_IR_RC6_DECODER=y CONFIG_IR_JVC_DECODER=y CONFIG_IR_SONY_DECODER=y CONFIG_IR_RC5_SZ_DECODER=y CONFIG_IR_SANYO_DECODER=y CONFIG_IR_MCE_KBD_DECODER=y # CONFIG_RC_DEVICES is not set CONFIG_MEDIA_USB_SUPPORT=y # # Webcam devices # CONFIG_USB_VIDEO_CLASS=m CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y CONFIG_USB_GSPCA=m CONFIG_USB_M5602=m CONFIG_USB_STV06XX=m CONFIG_USB_GL860=m CONFIG_USB_GSPCA_BENQ=m CONFIG_USB_GSPCA_CONEX=m CONFIG_USB_GSPCA_CPIA1=m CONFIG_USB_GSPCA_ETOMS=m CONFIG_USB_GSPCA_FINEPIX=m CONFIG_USB_GSPCA_JEILINJ=m CONFIG_USB_GSPCA_JL2005BCD=m CONFIG_USB_GSPCA_KINECT=m CONFIG_USB_GSPCA_KONICA=m CONFIG_USB_GSPCA_MARS=m CONFIG_USB_GSPCA_MR97310A=m CONFIG_USB_GSPCA_NW80X=m CONFIG_USB_GSPCA_OV519=m CONFIG_USB_GSPCA_OV534=m CONFIG_USB_GSPCA_OV534_9=m CONFIG_USB_GSPCA_PAC207=m CONFIG_USB_GSPCA_PAC7302=m CONFIG_USB_GSPCA_PAC7311=m CONFIG_USB_GSPCA_SE401=m CONFIG_USB_GSPCA_SN9C2028=m CONFIG_USB_GSPCA_SN9C20X=m CONFIG_USB_GSPCA_SONIXB=m CONFIG_USB_GSPCA_SONIXJ=m CONFIG_USB_GSPCA_SPCA500=m CONFIG_USB_GSPCA_SPCA501=m CONFIG_USB_GSPCA_SPCA505=m CONFIG_USB_GSPCA_SPCA506=m CONFIG_USB_GSPCA_SPCA508=m CONFIG_USB_GSPCA_SPCA561=m CONFIG_USB_GSPCA_SPCA1528=m CONFIG_USB_GSPCA_SQ905=m CONFIG_USB_GSPCA_SQ905C=m CONFIG_USB_GSPCA_SQ930X=m CONFIG_USB_GSPCA_STK014=m CONFIG_USB_GSPCA_STV0680=m CONFIG_USB_GSPCA_SUNPLUS=m CONFIG_USB_GSPCA_T613=m CONFIG_USB_GSPCA_TOPRO=m CONFIG_USB_GSPCA_TV8532=m CONFIG_USB_GSPCA_VC032X=m CONFIG_USB_GSPCA_VICAM=m CONFIG_USB_GSPCA_XIRLINK_CIT=m CONFIG_USB_GSPCA_ZC3XX=m CONFIG_USB_PWC=m # CONFIG_USB_PWC_DEBUG is not set CONFIG_USB_PWC_INPUT_EVDEV=y CONFIG_VIDEO_CPIA2=m # CONFIG_USB_ZR364XX is not set CONFIG_USB_STKWEBCAM=m CONFIG_USB_S2255=m CONFIG_USB_SN9C102=m # # Analog TV USB devices # CONFIG_VIDEO_AU0828=m CONFIG_VIDEO_PVRUSB2=m CONFIG_VIDEO_PVRUSB2_SYSFS=y CONFIG_VIDEO_PVRUSB2_DVB=y # CONFIG_VIDEO_PVRUSB2_DEBUGIFC is not set CONFIG_VIDEO_HDPVR=m CONFIG_VIDEO_TLG2300=m CONFIG_VIDEO_USBVISION=m CONFIG_VIDEO_STK1160=m # CONFIG_VIDEO_STK1160_AC97 is not set # # Analog/digital TV USB devices # CONFIG_VIDEO_CX231XX=m CONFIG_VIDEO_CX231XX_RC=y CONFIG_VIDEO_CX231XX_ALSA=m CONFIG_VIDEO_CX231XX_DVB=m CONFIG_VIDEO_TM6000=m CONFIG_VIDEO_TM6000_ALSA=m CONFIG_VIDEO_TM6000_DVB=m # # Digital TV USB devices # CONFIG_DVB_USB=m # CONFIG_DVB_USB_DEBUG is not set CONFIG_DVB_USB_A800=m CONFIG_DVB_USB_DIBUSB_MB=m # CONFIG_DVB_USB_DIBUSB_MB_FAULTY is not set CONFIG_DVB_USB_DIBUSB_MC=m CONFIG_DVB_USB_DIB0700=m CONFIG_DVB_USB_UMT_010=m CONFIG_DVB_USB_CXUSB=m CONFIG_DVB_USB_M920X=m CONFIG_DVB_USB_DIGITV=m CONFIG_DVB_USB_VP7045=m CONFIG_DVB_USB_VP702X=m CONFIG_DVB_USB_GP8PSK=m CONFIG_DVB_USB_NOVA_T_USB2=m CONFIG_DVB_USB_TTUSB2=m CONFIG_DVB_USB_DTT200U=m CONFIG_DVB_USB_OPERA1=m CONFIG_DVB_USB_AF9005=m CONFIG_DVB_USB_AF9005_REMOTE=m CONFIG_DVB_USB_PCTV452E=m CONFIG_DVB_USB_DW2102=m CONFIG_DVB_USB_CINERGY_T2=m CONFIG_DVB_USB_DTV5100=m CONFIG_DVB_USB_FRIIO=m CONFIG_DVB_USB_AZ6027=m CONFIG_DVB_USB_TECHNISAT_USB2=m CONFIG_DVB_USB_V2=m CONFIG_DVB_USB_CYPRESS
Re: [linux-yocto] [PATCH 00/16] linux-yocto-3.10: config fragments for minnow BSP
On Fri, 2013-11-22 at 11:36 -0800, nitin.a.kam...@intel.com wrote: > From: Nitin A Kamble > > > This patch series imports the 500 line media.cfg from the kernel recipe > in to the linux-yocto-3.10 meta branch, by splitting it into many > fragments. > > It replaces some of the existing webcam media fragments, and hence BSPs > configs using the old media fragments is changed accordingly. > > > This has been tested the following way. > * It gives the same minnow kernel config as with the big media.cfg on SRC_URI > * This changes the kernel config for sugarbay and genericx86-64 BSPs, and > the sugarbay BSP is validated to work as expected with this change. Fantastic, thank you Nitin. Did you also verify that no new issues are reported by the config validation task and logged in the .meta/standard/$KMACHINE/* log files? missing, etc? -- Darren > > Thanks, > Nitin > > The following changes since commit 4a04774a6562ab37a769404920e070b70acf3c4c: > > minnow: Remove branch statements from minnow scc files (2013-11-14 22:56:03 > -0500) > > are available in the git repository at: > > git://git.yoctoproject.org/linux-yocto-contrib nitin/meta > http://git.yoctoproject.org/cgit.cgi/linux-yocto-contrib/log/?h=nitin/meta > > Nitin A Kamble (16): > minnow.cfg: Enable TEA575X sound driver > firmware.scc/cfg : Feature for firmware loading > remove old MEDIA config fragments > media.scc : A feature for Media infrastructure > media/common : A feature for common media support > media/usb: A feature for USB media devices. > media/i2c: A feature for i2c media devices > media/pci-capture : A feature for PCI media capture devices > media/platform : A feature for platform media devices > media/radio : A feature for AM/FM radio devices > media/rc : A feature for remote control media devices > media/tuners: A feature for tuner media devices > media/usb_tv: A feature for usb tv media adapters > media/dvb-frontends : A feature for Digital Video Broadcast Devices > minnow.scc: enable media & firmware features > common-pc-64.scc: update as per changes in the media config fragments > > .../kernel-cache/bsp/common-pc-64/common-pc-64.scc | 3 +- > meta/cfg/kernel-cache/bsp/minnow/minnow.cfg| 1 + > meta/cfg/kernel-cache/bsp/minnow/minnow.scc| 9 ++ > .../kernel-cache/features/firmware/firmware.cfg| 8 ++ > .../kernel-cache/features/firmware/firmware.scc| 4 + > meta/cfg/kernel-cache/features/media/common.cfg| 15 +++ > meta/cfg/kernel-cache/features/media/common.scc| 6 ++ > .../kernel-cache/features/media/dvb_frontends.cfg | 116 > + > .../kernel-cache/features/media/dvb_frontends.scc | 6 ++ > meta/cfg/kernel-cache/features/media/i2c.cfg | 74 + > meta/cfg/kernel-cache/features/media/i2c.scc | 7 ++ > .../kernel-cache/features/media/media-camera.cfg | 4 - > .../kernel-cache/features/media/media-camera.scc | 4 - > meta/cfg/kernel-cache/features/media/media.cfg | 54 ++ > meta/cfg/kernel-cache/features/media/media.scc | 4 + > .../kernel-cache/features/media/pci-capture.cfg| 80 ++ > .../kernel-cache/features/media/pci-capture.scc| 8 ++ > meta/cfg/kernel-cache/features/media/platform.cfg | 15 +++ > meta/cfg/kernel-cache/features/media/platform.scc | 6 ++ > meta/cfg/kernel-cache/features/media/radio.cfg | 24 + > meta/cfg/kernel-cache/features/media/radio.scc | 6 ++ > meta/cfg/kernel-cache/features/media/rc.cfg| 18 > meta/cfg/kernel-cache/features/media/rc.scc| 6 ++ > meta/cfg/kernel-cache/features/media/tuners.cfg| 30 ++ > meta/cfg/kernel-cache/features/media/tuners.scc| 7 ++ > meta/cfg/kernel-cache/features/media/usb.cfg | 76 ++ > meta/cfg/kernel-cache/features/media/usb.scc | 7 ++ > meta/cfg/kernel-cache/features/media/usb_tv.cfg| 82 +++ > meta/cfg/kernel-cache/features/media/usb_tv.scc| 8 ++ > meta/cfg/kernel-cache/features/media/v4l2.cfg | 21 > meta/cfg/kernel-cache/features/media/v4l2.scc | 6 -- > .../cfg/kernel-cache/features/usb/usb-uvcvideo.cfg | 3 - > .../cfg/kernel-cache/features/usb/usb-uvcvideo.scc | 7 -- > 33 files changed, 678 insertions(+), 47 deletions(-) > create mode 100644 meta/cfg/kernel-cache/features/firmware/firmware.cfg > create mode 100644 meta/cfg/kernel-cache/features/firmware/firmware.scc > create mode 100644 meta/cfg/kernel-cache/features/media/common.cfg > create mode 100644 meta/cfg/kernel-cache/features/media/common.scc > create mode 100644 meta/cfg/kernel-cache/features/media/dvb_frontends.cfg > create mode 100644 meta/cfg/kernel-cache/features/media/dvb_frontends.scc > create mode 100644 meta/cfg/kernel-cache/features/media/i2c.cfg > create mode 100644 meta/cfg/kernel-cache/features/media/i2c.scc > delete mode 100644 meta/cfg/kernel-cache/features/medi
Re: [linux-yocto] [PATCH 02/16] firmware.scc/cfg : Feature for firmware loading
On Fri, 2013-11-22 at 11:35 -0800, nitin.a.kam...@intel.com wrote: > From: Nitin A Kamble > > This enables the kernel configuration for firmware loading. This is bare-minimum in size (3 CONFIGs) in my opinion to be considered for it's own fragment. I'm OK with it - but I wonder, Bruce, would this be better off just included in the base.cfg? It seems a reasonable thing to just include by default on all linux-yocto kernels. -- Darren > > Signed-off-by: Nitin A Kamble > --- > meta/cfg/kernel-cache/features/firmware/firmware.cfg | 8 > meta/cfg/kernel-cache/features/firmware/firmware.scc | 4 > 2 files changed, 12 insertions(+) > create mode 100644 meta/cfg/kernel-cache/features/firmware/firmware.cfg > create mode 100644 meta/cfg/kernel-cache/features/firmware/firmware.scc > > diff --git a/meta/cfg/kernel-cache/features/firmware/firmware.cfg > b/meta/cfg/kernel-cache/features/firmware/firmware.cfg > new file mode 100644 > index 000..7331ab3 > --- /dev/null > +++ b/meta/cfg/kernel-cache/features/firmware/firmware.cfg > @@ -0,0 +1,8 @@ > +CONFIG_FW_LOADER=m > +CONFIG_FIRMWARE_IN_KERNEL=y > +CONFIG_EXTRA_FIRMWARE="" > + > +# > +# Altera FPGA firmware download module > +# > +CONFIG_ALTERA_STAPL=m > diff --git a/meta/cfg/kernel-cache/features/firmware/firmware.scc > b/meta/cfg/kernel-cache/features/firmware/firmware.scc > new file mode 100644 > index 000..09432a8 > --- /dev/null > +++ b/meta/cfg/kernel-cache/features/firmware/firmware.scc > @@ -0,0 +1,4 @@ > +define KFEATURE_DESCRIPTION "Firmware loading support" > +define KFEATURE_COMPATIBILITY all > + > +kconf non-hardware firmware.cfg -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 04/16] media.scc : A feature for Media infrastructure
On Fri, 2013-11-22 at 11:35 -0800, nitin.a.kam...@intel.com wrote: > From: Nitin A Kamble > > This replaces the previous limited media config fragments. > Other hardware media features depends on this feature. Please include the intent of this particular feature here. This adds the infrastructure V4L2, tuner, camera, and radio, to be included by driver-specific features. But, yes, good abstraction. -- Darren > > Signed-off-by: Nitin A Kamble > --- > meta/cfg/kernel-cache/features/media/media.cfg | 54 > ++ > meta/cfg/kernel-cache/features/media/media.scc | 4 ++ > 2 files changed, 58 insertions(+) > create mode 100644 meta/cfg/kernel-cache/features/media/media.cfg > create mode 100644 meta/cfg/kernel-cache/features/media/media.scc > > diff --git a/meta/cfg/kernel-cache/features/media/media.cfg > b/meta/cfg/kernel-cache/features/media/media.cfg > new file mode 100644 > index 000..b7b5f5e > --- /dev/null > +++ b/meta/cfg/kernel-cache/features/media/media.cfg > @@ -0,0 +1,54 @@ > +# > +# Enable support for multimedia devices such as webcams and Video grabber > devices > +# > +CONFIG_MEDIA_SUPPORT=m > +CONFIG_MEDIA_CAMERA_SUPPORT=y > +CONFIG_MEDIA_ANALOG_TV_SUPPORT=y > +CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y > +CONFIG_MEDIA_RADIO_SUPPORT=y > +CONFIG_MEDIA_CONTROLLER=y > + > +# > +# Enable the V4L2 core and API > +# > +CONFIG_VIDEO_DEV=m > +CONFIG_VIDEO_V4L2=m > +CONFIG_VIDEO_V4L2_SUBDEV_API=y > + > +# > +# Used by drivers that need v4l2-mem2mem.ko > +# > +CONFIG_V4L2_MEM2MEM_DEV=m > + > +# > +# Used by drivers that need Videobuf modules > +# > +CONFIG_VIDEOBUF_GEN=m > +CONFIG_VIDEOBUF_DMA_SG=m > +CONFIG_VIDEOBUF_DMA_CONTIG=m > +CONFIG_VIDEOBUF_VMALLOC=m > +CONFIG_VIDEOBUF_DVB=m > + > +# > +# Used by drivers that need Videobuf2 modules > +# > +CONFIG_VIDEOBUF2_CORE=m > +CONFIG_VIDEOBUF2_MEMOPS=m > +CONFIG_VIDEOBUF2_DMA_SG=m > +CONFIG_VIDEOBUF2_DMA_CONTIG=m > +CONFIG_VIDEOBUF2_VMALLOC=m > + > +# > +# Digital Video Broadcast support > +# > +CONFIG_DVB_CORE=y > +CONFIG_DVB_NET=y > +CONFIG_DVB_MAX_ADAPTERS=8 > +CONFIG_DVB_DYNAMIC_MINORS=y > + > +# > +# Autoselect ancillary drivers (tuners, sensors, i2c, frontends) > +# > +CONFIG_MEDIA_SUBDRV_AUTOSELECT=y > + > +CONFIG_MEDIA_ATTACH=y > diff --git a/meta/cfg/kernel-cache/features/media/media.scc > b/meta/cfg/kernel-cache/features/media/media.scc > new file mode 100644 > index 000..838782d > --- /dev/null > +++ b/meta/cfg/kernel-cache/features/media/media.scc > @@ -0,0 +1,4 @@ > +define KFEATURE_DESCRIPTION "Enable support for multimedia devices such as > webcams and Video grabber devices" > +define KFEATURE_COMPATIBILITY all > + > +kconf non-hardware media.cfg -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 07/16] media/i2c: A feature for i2c media devices
On Fri, 2013-11-22 at 11:35 -0800, nitin.a.kam...@intel.com wrote: > From: Nitin A Kamble > > This enables kernel configuration for bunch of i2c media devices. > > Signed-off-by: Nitin A Kamble > --- > meta/cfg/kernel-cache/features/media/i2c.cfg | 74 > > meta/cfg/kernel-cache/features/media/i2c.scc | 7 +++ At the very least, lets use media-i2c, media-usb, etc. naming to avoid confusion. > 2 files changed, 81 insertions(+) > create mode 100644 meta/cfg/kernel-cache/features/media/i2c.cfg > create mode 100644 meta/cfg/kernel-cache/features/media/i2c.scc > > diff --git a/meta/cfg/kernel-cache/features/media/i2c.cfg > b/meta/cfg/kernel-cache/features/media/i2c.cfg > new file mode 100644 > index 000..a59631f > --- /dev/null > +++ b/meta/cfg/kernel-cache/features/media/i2c.cfg > @@ -0,0 +1,74 @@ > +# > +# Media I2C Support > +# > + > +# > +# Encoders, Decoders, Sensors And Other Helper Chips > +# > +CONFIG_VIDEO_IR_I2C=y > +CONFIG_VIDEO_TVAUDIO=m > +CONFIG_VIDEO_TDA7432=m > +CONFIG_VIDEO_TDA9840=m > +CONFIG_VIDEO_TEA6415C=m > +CONFIG_VIDEO_TEA6420=m > +CONFIG_VIDEO_MSP3400=m > +CONFIG_VIDEO_CS5345=m > +CONFIG_VIDEO_CS53L32A=m > +CONFIG_VIDEO_WM8775=m > +CONFIG_VIDEO_WM8739=m > +CONFIG_VIDEO_VP27SMPX=m > + > +# > +# RDS decoders > +# > +CONFIG_VIDEO_SAA6588=m > + > +# > +# Video decoders > +# > +CONFIG_VIDEO_BT819=m > +CONFIG_VIDEO_BT856=m > +CONFIG_VIDEO_BT866=m > +CONFIG_VIDEO_KS0127=m > +CONFIG_VIDEO_SAA7110=m > +CONFIG_VIDEO_SAA711X=m > +CONFIG_VIDEO_TVP5150=m > +CONFIG_VIDEO_VPX3220=m > + > +# > +# Video and audio decoders > +# > +CONFIG_VIDEO_SAA717X=m > +CONFIG_VIDEO_CX25840=m > + > +# > +# MPEG video encoders > +# > +CONFIG_VIDEO_CX2341X=m > + > +# > +# Video encoders > +# > +CONFIG_VIDEO_SAA7127=m > +CONFIG_VIDEO_ADV7170=m > +CONFIG_VIDEO_ADV7175=m > + > +# > +# Camera sensor devices > +# > +CONFIG_VIDEO_MT9V011=m > + > +# > +# Flash devices > +# Nothing here? Can drop the heading then. > +# > +# Video improvement chips > +# > +CONFIG_VIDEO_UPD64031A=m > +CONFIG_VIDEO_UPD64083=m > + > +# > +# Miscelaneous helper chips > +# > +CONFIG_VIDEO_M52790=m Looks good in general, I didn't check this one for options without prompts that are auto-selected, that audit should always be done when creating fragments. > diff --git a/meta/cfg/kernel-cache/features/media/i2c.scc > b/meta/cfg/kernel-cache/features/media/i2c.scc > new file mode 100644 > index 000..195266b > --- /dev/null > +++ b/meta/cfg/kernel-cache/features/media/i2c.scc > @@ -0,0 +1,7 @@ > +define KFEATURE_DESCRIPTION "Enable Configuration For I2C Media devices" > +define KFEATURE_COMPATIBILITY all > + > +include media.scc > +include ../i2c/i2c.scc > + > +kconf hardware i2c.cfg -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 08/16] media/pci-capture : A feature for PCI media capture devices
On Fri, 2013-11-22 at 11:35 -0800, nitin.a.kam...@intel.com wrote: > From: Nitin A Kamble I've avoided too much feedback on the commit message, but these are nearly as important as the content itself. So I'll spend some time on just this one and leave it to you to extend to the others. > This enables kernel configuration for bunch of PCI media capture ^ a :-) and elsewhere > devices. Convention would be to speak in the imperative, so drop the "This" and replace "enables" with "Enable". "Enable kernel configuration for PCI media capture devices." Or perhaps more appropriately: "Create a feature fragment for PCI media capture devices." If you made any non-obvious decisions in preparing this fragment, please note them here as well. Did you drop any specific options? Did you included something that appears out of place to avoid extra complexity elsewhere, etc. > Signed-off-by: Nitin A Kamble > --- > .../kernel-cache/features/media/pci-capture.cfg| 80 > ++ > .../kernel-cache/features/media/pci-capture.scc| 8 +++ > 2 files changed, 88 insertions(+) > create mode 100644 meta/cfg/kernel-cache/features/media/pci-capture.cfg > create mode 100644 meta/cfg/kernel-cache/features/media/pci-capture.scc > > diff --git a/meta/cfg/kernel-cache/features/media/pci-capture.cfg > b/meta/cfg/kernel-cache/features/media/pci-capture.cfg > new file mode 100644 > index 000..232de32 > --- /dev/null > +++ b/meta/cfg/kernel-cache/features/media/pci-capture.cfg > @@ -0,0 +1,80 @@ > +# > +# Media capture support for PCI devices > +# > +CONFIG_MEDIA_PCI_SUPPORT=y > + > +# > +# Media capture/analog TV support > +# > +CONFIG_VIDEO_IVTV=m > +CONFIG_VIDEO_IVTV_ALSA=m > +CONFIG_VIDEO_FB_IVTV=m > + > +CONFIG_VIDEO_ZORAN=m > +CONFIG_VIDEO_ZORAN_DC30=m > +CONFIG_VIDEO_ZORAN_ZR36060=m > +# CONFIG_VIDEO_ZORAN_BUZ is not set Why? > +CONFIG_VIDEO_ZORAN_DC10=m > +CONFIG_VIDEO_ZORAN_LML33=m > +CONFIG_VIDEO_ZORAN_LML33R10=m > +CONFIG_VIDEO_ZORAN_AVS6EYES=m > + > +CONFIG_VIDEO_HEXIUM_GEMINI=m > +CONFIG_VIDEO_HEXIUM_ORION=m > +CONFIG_VIDEO_MXB=m > + > +# > +# Media capture/analog/hybrid TV support > +# > +CONFIG_VIDEO_CX18=m > +CONFIG_VIDEO_CX18_ALSA=m > + > +CONFIG_VIDEO_CX23885=m > +CONFIG_MEDIA_ALTERA_CI=m > + > +CONFIG_VIDEO_CX25821=m > +CONFIG_VIDEO_CX25821_ALSA=m > + > +CONFIG_VIDEO_CX88=m > +CONFIG_VIDEO_CX88_ALSA=m > +CONFIG_VIDEO_CX88_BLACKBIRD=m > +CONFIG_VIDEO_CX88_DVB=m > +CONFIG_VIDEO_CX88_VP3054=m > +CONFIG_VIDEO_CX88_MPEG=m > + > +CONFIG_VIDEO_BT848=m > +CONFIG_DVB_BT8XX=m > + > +CONFIG_VIDEO_SAA7134=m > +CONFIG_VIDEO_SAA7134_ALSA=m > +CONFIG_VIDEO_SAA7134_RC=y > +CONFIG_VIDEO_SAA7134_DVB=m > +CONFIG_VIDEO_SAA7164=m > + > +# > +# Media digital TV PCI Adapters > +# > +CONFIG_DVB_AV7110=m > +CONFIG_DVB_AV7110_OSD=y > +CONFIG_DVB_BUDGET_CORE=m > +CONFIG_DVB_BUDGET=m > +CONFIG_DVB_BUDGET_CI=m > +CONFIG_DVB_BUDGET_AV=m > +CONFIG_DVB_BUDGET_PATCH=m > + > +CONFIG_DVB_B2C2_FLEXCOP_PCI=m > +# CONFIG_DVB_B2C2_FLEXCOP_PCI_DEBUG is not set Defaults to off I presume? > + > +CONFIG_DVB_PLUTO2=m > + > +CONFIG_DVB_DM1105=m > + > +CONFIG_DVB_PT1=m > + > +CONFIG_MANTIS_CORE=m > +CONFIG_DVB_MANTIS=m > +CONFIG_DVB_HOPPER=m > + > +CONFIG_DVB_NGENE=m > + > +CONFIG_DVB_DDBRIDGE=m > diff --git a/meta/cfg/kernel-cache/features/media/pci-capture.scc > b/meta/cfg/kernel-cache/features/media/pci-capture.scc > new file mode 100644 > index 000..e24e6c8 > --- /dev/null > +++ b/meta/cfg/kernel-cache/features/media/pci-capture.scc > @@ -0,0 +1,8 @@ > +define KFEATURE_DESCRIPTION "Enable Configuration For Media PCI Capture > Devices" > +define KFEATURE_COMPATIBILITY all > + > +include media.scc > +include ../pci/pci.scc > +include common.scc order again, pci first. > + > +kconf hardware pci-capture.cfg -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 00/16] linux-yocto-3.10: config fragments for minnow BSP
On Fri, 2013-11-22 at 21:23 +, Kamble, Nitin A wrote: > > > -Original Message- > > From: Hart, Darren > > Sent: Friday, November 22, 2013 12:48 PM > > To: Kamble, Nitin A > > Cc: linux-yo...@yoctoproject.org; bruce.ashfi...@windriver.com > > Subject: Re: [PATCH 00/16] linux-yocto-3.10: config fragments for minnow > > BSP > > > > On Fri, 2013-11-22 at 11:36 -0800, nitin.a.kam...@intel.com wrote: > > > From: Nitin A Kamble > > > > > > > > > This patch series imports the 500 line media.cfg from the kernel > > > recipe in to the linux-yocto-3.10 meta branch, by splitting it into > > > many fragments. > > > > > > It replaces some of the existing webcam media fragments, and hence > > > BSPs configs using the old media fragments is changed accordingly. > > > > > > > > > This has been tested the following way. > > > * It gives the same minnow kernel config as with the big media.cfg on > > > SRC_URI > > > * This changes the kernel config for sugarbay and genericx86-64 BSPs, and > > > the sugarbay BSP is validated to work as expected with this change. > > > > Fantastic, thank you Nitin. > > > > Did you also verify that no new issues are reported by the config validation > > task and logged in the .meta/standard/$KMACHINE/* log files? > > missing, etc? > > > I did verify that there are no errors in those log file. Hrm, I'm surprised, I would have expected many of those tuner "y" to have been changed to "m" which would show up in those logs. But, that's good. -- Darren > Nitin > > > > > -- > > Darren > > > > > > > > Thanks, > > > Nitin > > > > > > The following changes since commit > > 4a04774a6562ab37a769404920e070b70acf3c4c: > > > > > > minnow: Remove branch statements from minnow scc files (2013-11-14 > > > 22:56:03 -0500) > > > > > > are available in the git repository at: > > > > > > git://git.yoctoproject.org/linux-yocto-contrib nitin/meta > > > > > > http://git.yoctoproject.org/cgit.cgi/linux-yocto-contrib/log/?h=nitin/ > > > meta > > > > > > Nitin A Kamble (16): > > > minnow.cfg: Enable TEA575X sound driver > > > firmware.scc/cfg : Feature for firmware loading > > > remove old MEDIA config fragments > > > media.scc : A feature for Media infrastructure > > > media/common : A feature for common media support > > > media/usb: A feature for USB media devices. > > > media/i2c: A feature for i2c media devices > > > media/pci-capture : A feature for PCI media capture devices > > > media/platform : A feature for platform media devices > > > media/radio : A feature for AM/FM radio devices > > > media/rc : A feature for remote control media devices > > > media/tuners: A feature for tuner media devices > > > media/usb_tv: A feature for usb tv media adapters > > > media/dvb-frontends : A feature for Digital Video Broadcast Devices > > > minnow.scc: enable media & firmware features > > > common-pc-64.scc: update as per changes in the media config > > > fragments > > > > > > .../kernel-cache/bsp/common-pc-64/common-pc-64.scc | 3 +- > > > meta/cfg/kernel-cache/bsp/minnow/minnow.cfg| 1 + > > > meta/cfg/kernel-cache/bsp/minnow/minnow.scc| 9 ++ > > > .../kernel-cache/features/firmware/firmware.cfg| 8 ++ > > > .../kernel-cache/features/firmware/firmware.scc| 4 + > > > meta/cfg/kernel-cache/features/media/common.cfg| 15 +++ > > > meta/cfg/kernel-cache/features/media/common.scc| 6 ++ > > > .../kernel-cache/features/media/dvb_frontends.cfg | 116 > > + > > > .../kernel-cache/features/media/dvb_frontends.scc | 6 ++ > > > meta/cfg/kernel-cache/features/media/i2c.cfg | 74 + > > > meta/cfg/kernel-cache/features/media/i2c.scc | 7 ++ > > > .../kernel-cache/features/media/media-camera.cfg | 4 - > > > .../kernel-cache/features/media/media-camera.scc | 4 - > > > meta/cfg/kernel-cache/features/media/media.cfg | 54 ++ > > > meta/cfg/kernel-cache/features/media/media.scc | 4 + > > > .../kernel-cache/features/media/pci-capture.cfg| 80 ++ > > > .../kernel-cache/features/media/pci-capture.scc| 8 ++ > > > meta/cfg/kernel-cache/features/me
Re: [yocto] Question on building out-of-tree modules on the target
On 5/29/15, 12:21 PM, "Trevor Woerner" wrote: >Hi Scott, > >On 05/18/15 10:42, Rifenbark, Scott M wrote: >> I have a section in the YP Linux Kernel Development Manual that talks >>about building out-of-tree-modules on the target - > >Interestingly enough, I was just reading through that document the other >day. As soon as I saw a section titled "Building Out-Of-Tree Modules _On >The Target_" I thought to myself "why would anyone be doing development >on the target and not the host?" and skipped to the next section. > >If it were me, I'd just remove that section altogether. I'm of the >opinion that doing development work on the target is wrong (if for no >other reason than to prove your cross-development setup is working >correctly), but that's just me. > >;-) > I personally agree, but having it documented means I get to answer a lot few emails about people insisting on doing this. The section stays. -- Darren Hart Intel Open Source Technology Center -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Question on building out-of-tree modules on the target
On 5/29/15, 12:46 PM, "Rifenbark, Scott M" wrote: >Ok - so we established that we want it... If I get some clarifications in >there about the "rarity" of the situation that would allow someone to >develop on the target and also the benefits of having a verified >cross-development system if they were to develop on the host, does the >rest of the section stand as is? Are there any issues with it? Adding something like: "While the traditional Yocto Project development model would be to include kernel modules as part of the normal build process, some developers find it useful to build modules on the target." This section is lagging the 1.8 addition of kernel-devsrc, which was not applied uniformly across all included SDK images. There is probably a patch necessary to do that for a 1.8 point release, and then this document could be made to reflect that. -- Darren > >Thanks, >Scott > >>-Original Message- >>From: Hart, Darren >>Sent: Friday, May 29, 2015 12:40 PM >>To: Trevor Woerner; Rifenbark, Scott M; yocto@yoctoproject.org >>Cc: Wold, Saul >>Subject: Re: [yocto] Question on building out-of-tree modules on the >>target >> >>On 5/29/15, 12:21 PM, "Trevor Woerner" wrote: >> >>>Hi Scott, >>> >>>On 05/18/15 10:42, Rifenbark, Scott M wrote: >>>> I have a section in the YP Linux Kernel Development Manual that talks >>>>about building out-of-tree-modules on the target - >>> >>>Interestingly enough, I was just reading through that document the >>>other day. As soon as I saw a section titled "Building Out-Of-Tree >>>Modules _On The Target_" I thought to myself "why would anyone be doing >>>development on the target and not the host?" and skipped to the next >>section. >>> >>>If it were me, I'd just remove that section altogether. I'm of the >>>opinion that doing development work on the target is wrong (if for no >>>other reason than to prove your cross-development setup is working >>>correctly), but that's just me. >>> >>>;-) >>> >> >>I personally agree, but having it documented means I get to answer a lot >>few >>emails about people insisting on doing this. The section stays. >> >>-- >>Darren Hart >>Intel Open Source Technology Center >> > > -- Darren Hart Intel Open Source Technology Center -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] yocto-docs: Some aesthetic changes to kernel-dev-common.xml
> -Original Message- > From: Robert P. J. Day [mailto:rpj...@crashcourse.ca] > Sent: Thursday, February 23, 2017 3:08 AM > To: Yocto discussion list > Cc: Hart, Darren > Subject: [PATCH] yocto-docs: Some aesthetic changes to kernel-dev- > common.xml > > > Small number of aesthetic/visual changes to kernel-dev-common.xml. > Erm... that's not really what these are :-) These are a mix of grammatical fixes, format preferences, and clarifying commentary, which do amount to some functional changes in terms of what a reader may do or not do as a result of reading them. Please be explicit in your commit log. That said, I have no objections to these changes, the majority of which I consider to be good improvements. Thanks for taking the time to improve the documentation. > Signed-off-by: Robert P. J. Day Reviewed-by: Darren Hart > > --- > > as darren is the author, i'll leave it in his hands to > accept/reject any of this. a lot of this is just subtle rewording > whenever i think there might be the slightest ambiguity, and some > aesthetic prettification. nothing significant. > > diff --git a/documentation/kernel-dev/kernel-dev-common.xml > b/documentation/kernel-dev/kernel-dev-common.xml > index a9aafd3..cb186c9 100644 > --- a/documentation/kernel-dev/kernel-dev-common.xml > +++ b/documentation/kernel-dev/kernel-dev-common.xml > @@ -25,10 +25,10 @@ > If you are going to be modifying kernel recipes, it is > recommended > that you create and prepare your own layer in which to do your > work. > -Your layer contains its own > +Your layer would typically contain its own > BitBake > append files > -(.bbappend) and provides a convenient > +(.bbappend) and would provide a > convenient > mechanism to create your own recipe files > (.bb). > For details on how to create and work with layers, see the > following > @@ -59,9 +59,9 @@ > > Modifying an existing recipe can consist of the following: > > -Creating the append file > -Applying patches > -Changing the configuration > +Creating an append file > +Applying some local > patches > +Changing the kernel > configuration > > > > @@ -81,14 +81,14 @@ > > > You create this file in your custom layer. > -You also name it accordingly based on the linux-yocto recipe > -you are using. > +You also name it accordingly based on the version of the > +linux-yocto recipe you are modifying. > For example, if you are modifying the > -meta/recipes-kernel/linux/linux- > yocto_3.19.bb > -recipe, the append file will typically be located as follows > -within your custom layer: > +meta/recipes-kernel/linux/linux- > yocto_4.4.bb > +recipe, the corresponding append file will typically be > located > +as follows within your custom layer: > > - your-layer/recipes-kernel/linux/linux- > yocto_3.19.bbappend > + your-layer/recipes-kernel/linux/linux- > yocto_4.4.bbappend > > The append file should initially extend the > FILESPATH > @@ -133,12 +133,14 @@ > > > For example, you can apply a three-patch series by adding the > -following lines to your linux-yocto > -.bbappend file in your layer: > +following lines to the linux-yocto > +.bbappend file in your custom layer: > > - SRC_URI += "file://0001-first-change.patch" > - SRC_URI += "file://0002-second-change.patch" > - SRC_URI += "file://0003-third-change.patch" > + SRC_URI += " \ > +file://0001-first-change.patch \ > +file://0002-second-change.patch \ > +file://0003-third-change.patch \ > +" > > The next time you run BitBake to build the Linux kernel, > BitBake detects the change in the recipe and fetches and > @@ -158,11 +160,12 @@ > > You can make wholesale or incremental changes to the final > .config file used for the eventual > -Linux kernel configuration by inclu
Re: [yocto] [PATCH] yocto-docs: Aesthetic changes to kernel-dev-intro.xml
> -Original Message- > From: Robert P. J. Day [mailto:rpj...@crashcourse.ca] > Sent: Thursday, February 23, 2017 2:33 AM > To: Yocto discussion list > Cc: Hart, Darren > Subject: [PATCH] yocto-docs: Aesthetic changes to kernel-dev-intro.xml > > > * "sys" filesystem is technically "sysfs" filesystem > * "aggregate" already implies together :-) > > Signed-off-by: Robert P. J. Day > Thanks for taking the time to correct the docs. Reviewed-by: Darren Hart -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] yocto-docs: Some aesthetic changes to kernel-dev-common.xml
> -Original Message- > From: Robert P. J. Day [mailto:rpj...@crashcourse.ca] > Sent: Thursday, February 23, 2017 9:40 AM > To: Hart, Darren > Cc: Yocto discussion list > Subject: RE: [PATCH] yocto-docs: Some aesthetic changes to kernel-dev- > common.xml > > On Thu, 23 Feb 2017, Hart, Darren wrote: > > > > -Original Message- > > > From: Robert P. J. Day [mailto:rpj...@crashcourse.ca] > > > Sent: Thursday, February 23, 2017 3:08 AM > > > To: Yocto discussion list > > > Cc: Hart, Darren > > > Subject: [PATCH] yocto-docs: Some aesthetic changes to kernel-dev- > > > common.xml > > > > > > > > > Small number of aesthetic/visual changes to kernel-dev- > common.xml. > > > > > > > Erm... that's not really what these are :-) These are a mix of > > grammatical fixes, format preferences, and clarifying commentary, > > which do amount to some functional changes in terms of what a reader > > may do or not do as a result of reading them. Please be explicit in > > your commit log. > > > > That said, I have no objections to these changes, the majority of > > which I consider to be good improvements. Thanks for taking the time > > to improve the documentation. > > so i should resubmit PATCH v2 with a more detailed commit msg? ok, i > can do that. stay tuned ... That is ultimately up to the maintainer who could decide to update the message themselves, or require a v2 from you. If it were me, I would just submit a v2 with an updated commit message as that is likely the fastest path to merging, and you are sure to get your intent captured. Thanks! -- Darren Hart Intel Open Source Technology Center -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH v2] yocto-docs: kernel-dev, Aesthetic/formatting/clarification fixes
> -Original Message- > From: Robert P. J. Day [mailto:rpj...@crashcourse.ca] > Sent: Thursday, February 23, 2017 9:45 AM > To: Yocto discussion list > Cc: Hart, Darren > Subject: [PATCH v2] yocto-docs: kernel-dev, > Aesthetic/formatting/clarification fixes > > > A variety of tweaks to kernel-dev manual, section > kernel-dev-common.xml, which include: > > * adding extra text in places to clarify possibly ambiguous content > * some formatting changes related to font and overly long lines > * update some old version numbers that don't even exist anymore > > Signed-off-by: Robert P. J. Day Thanks Robert! Reviewed-by: Darren Hart -- Darren Hart Intel Open Source Technology Center > > --- > > diff --git a/documentation/kernel-dev/kernel-dev-common.xml > b/documentation/kernel-dev/kernel-dev-common.xml > index a9aafd3..cb186c9 100644 > --- a/documentation/kernel-dev/kernel-dev-common.xml > +++ b/documentation/kernel-dev/kernel-dev-common.xml > @@ -25,10 +25,10 @@ > If you are going to be modifying kernel recipes, it is > recommended > that you create and prepare your own layer in which to do your > work. > -Your layer contains its own > +Your layer would typically contain its own > BitBake > append files > -(.bbappend) and provides a convenient > +(.bbappend) and would provide a > convenient > mechanism to create your own recipe files > (.bb). > For details on how to create and work with layers, see the > following > @@ -59,9 +59,9 @@ > > Modifying an existing recipe can consist of the following: > > -Creating the append file > -Applying patches > -Changing the configuration > +Creating an append file > +Applying some local > patches > +Changing the kernel > configuration > > > > @@ -81,14 +81,14 @@ > > > You create this file in your custom layer. > -You also name it accordingly based on the linux-yocto recipe > -you are using. > +You also name it accordingly based on the version of the > +linux-yocto recipe you are modifying. > For example, if you are modifying the > -meta/recipes-kernel/linux/linux- > yocto_3.19.bb > -recipe, the append file will typically be located as follows > -within your custom layer: > +meta/recipes-kernel/linux/linux- > yocto_4.4.bb > +recipe, the corresponding append file will typically be > located > +as follows within your custom layer: > > - your-layer/recipes-kernel/linux/linux- > yocto_3.19.bbappend > + your-layer/recipes-kernel/linux/linux- > yocto_4.4.bbappend > > The append file should initially extend the > FILESPATH > @@ -133,12 +133,14 @@ > > > For example, you can apply a three-patch series by adding the > -following lines to your linux-yocto > -.bbappend file in your layer: > +following lines to the linux-yocto > +.bbappend file in your custom layer: > > - SRC_URI += "file://0001-first-change.patch" > - SRC_URI += "file://0002-second-change.patch" > - SRC_URI += "file://0003-third-change.patch" > + SRC_URI += " \ > +file://0001-first-change.patch \ > +file://0002-second-change.patch \ > +file://0003-third-change.patch \ > +" > > The next time you run BitBake to build the Linux kernel, > BitBake detects the change in the recipe and fetches and > @@ -158,11 +160,12 @@ > > You can make wholesale or incremental changes to the final > .config file used for the eventual > -Linux kernel configuration by including a > -defconfig file and by specifying > +Linux kernel configuration by including a local > +defconfig file, as well as by specifying > configuration fragments in the > SRC_URI > -to be applied to that file. > +to be applied to the configuration defined by that >
