[PATCH] [media] dvb-usb: remove another redundant #include
Kernel source files need not include explicitly
because the top Makefile forces to include it with:
-include $(srctree)/include/linux/kconfig.h
Remove another reduntdant include, that managed to sneak by commit
97139d4a6f26 ("treewide: remove redundant #include ").
Signed-off-by: Paul Bolle <pebo...@tiscali.nl>
---
drivers/media/usb/dvb-usb/dibusb-mc-common.c | 1 -
1 file changed, 1 deletion(-)
Masahiro: another #include was added to include/asm-generic/export.h. I
think it's bogus too, but testing it required setting
CONFIG_TRIM_UNUSED_KSYMS. And doing that triggered over 100K (!) undefined
symbol errors in my test build.
So naturally I decided to behave as if I never saw that #include enter
export.h. Perhaps you are braver than I am.
diff --git a/drivers/media/usb/dvb-usb/dibusb-mc-common.c
b/drivers/media/usb/dvb-usb/dibusb-mc-common.c
index d66f56cc46a5..c989cac9343d 100644
--- a/drivers/media/usb/dvb-usb/dibusb-mc-common.c
+++ b/drivers/media/usb/dvb-usb/dibusb-mc-common.c
@@ -9,7 +9,6 @@
* see Documentation/dvb/README.dvb-usb for more information
*/
-#include
#include "dibusb.h"
/* 3000MC/P stuff */
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] create SMAF module
A nit only, I'm afraid: a license mismatch. On ma, 2015-07-06 at 13:40 +0200, Benjamin Gaignard wrote: --- /dev/null +++ b/drivers/smaf/smaf-core.c + * License terms: GNU General Public License (GPL), version 2 +MODULE_LICENSE(GPL); The comment at the top of this file states, succinctly, that the license is GPL v2. And, according to include/linux/module.h, the MODULE_LICENSE() macro here states that the license is GPL v2 or later. So I think that either that comment or the ident used in that macro needs to change. Ditto for 2/2. Thanks, Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/12] [media] tsin: c8sectpfe: Add Kconfig and Makefile for the driver.
On Wed, 2015-06-24 at 16:11 +0100, Peter Griffin wrote: --- /dev/null +++ b/drivers/media/tsin/c8sectpfe/Makefile +c8sectpfe-y += c8sectpfe-core.o c8sectpfe-common.o c8sectpfe-dvb.o + +obj-$(CONFIG_DVB_C8SECTPFE) += c8sectpfe.o + +ifneq ($(CONFIG_DVB_C8SECTPFE),) + c8sectpfe-y += c8sectpfe-debugfs.o +endif Isn't the above equivalent to c8sectpfe-y += c8sectpfe-core.o c8sectpfe-common.o c8sectpfe-dvb.o c8sectpfe-debugfs.o obj-$(CONFIG_DVB_C8SECTPFE) += c8sectpfe.o Or am I missing something subtle here? Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] dvb-usb/dvb-usb-v2: use IS_REACHABLE
-descriptor.idProduct) ==
+ USB_PID_LITEON_DVB_T_WARM) {
+ msleep(1000);
+ }
+
+ adap-fe_adap[0].fe = dvb_attach(dib3000mc_attach,
+ adap-dev-i2c_adap,
+ DEFAULT_DIB3000P_I2C_ADDRESS,
+ mod3000p_dib3000p_config);
+ if ((adap-fe_adap[0].fe) == NULL)
+ adap-fe_adap[0].fe = dvb_attach(dib3000mc_attach,
+ adap-dev-i2c_adap,
+ DEFAULT_DIB3000MC_I2C_ADDRESS,
+ mod3000p_dib3000p_config);
+ if ((adap-fe_adap[0].fe) != NULL) {
+ if (adap-priv != NULL) {
+ struct dibusb_state *st = adap-priv;
+ st-ops.pid_parse = dib3000mc_pid_parse;
+ st-ops.pid_ctrl = dib3000mc_pid_control;
+ }
+ return 0;
+ }
+ return -ENODEV;
+}
+EXPORT_SYMBOL(dibusb_dib3000mc_frontend_attach);
+
+static struct mt2060_config stk3000p_mt2060_config = {
+ 0x60
+};
+
+int dibusb_dib3000mc_tuner_attach(struct dvb_usb_adapter *adap)
+{
+ struct dibusb_state *st = adap-priv;
+ u8 a,b;
+ u16 if1 = 1220;
+ struct i2c_adapter *tun_i2c;
+
+ // First IF calibration for Liteon Sticks
+ if (le16_to_cpu(adap-dev-udev-descriptor.idVendor) == USB_VID_LITEON
+ le16_to_cpu(adap-dev-udev-descriptor.idProduct) ==
USB_PID_LITEON_DVB_T_WARM) {
+
+ dibusb_read_eeprom_byte(adap-dev,0x7E,a);
+ dibusb_read_eeprom_byte(adap-dev,0x7F,b);
+
+ if (a == 0x00)
+ if1 += b;
+ else if (a == 0x80)
+ if1 -= b;
+ else
+ warn(LITE-ON DVB-T: Strange IF1 calibration :%2X
%2X\n, a, b);
+
+ } else if (le16_to_cpu(adap-dev-udev-descriptor.idVendor) ==
USB_VID_DIBCOM
+le16_to_cpu(adap-dev-udev-descriptor.idProduct) ==
USB_PID_DIBCOM_MOD3001_WARM) {
+ u8 desc;
+ dibusb_read_eeprom_byte(adap-dev, 7, desc);
+ if (desc == 2) {
+ a = 127;
+ do {
+ dibusb_read_eeprom_byte(adap-dev, a, desc);
+ a--;
+ } while (a 7 (desc == 0xff || desc == 0x00));
+ if (desc 0x80)
+ if1 -= (0xff - desc);
+ else
+ if1 += desc;
+ }
+ }
+
+ tun_i2c = dib3000mc_get_tuner_i2c_master(adap-fe_adap[0].fe, 1);
+ if (dvb_attach(mt2060_attach, adap-fe_adap[0].fe, tun_i2c,
stk3000p_mt2060_config, if1) == NULL) {
+ /* not found - use panasonic pll parameters */
+ if (dvb_attach(dvb_pll_attach, adap-fe_adap[0].fe, 0x60,
tun_i2c, DVB_PLL_ENV57H1XD5) == NULL)
+ return -ENOMEM;
+ } else {
+ st-mt2060_present = 1;
+ /* set the correct parameters for the dib3000p */
+ dib3000mc_set_config(adap-fe_adap[0].fe,
stk3000p_dib3000p_config);
+ }
+ return 0;
+}
+EXPORT_SYMBOL(dibusb_dib3000mc_tuner_attach);
But without a MODULE_LICENSE() macro loading that module will taint the
kernel (see set_license() in kernel/module.c). So, although it seems
this driver can do without most of the usual module boilerplate, a
MODULE_LICENSE() macro would still be needed.
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] break kconfig dependency loop
On Wed, 2015-04-01 at 16:47 +0300, Jani Nikula wrote: I think part of the problem is that select is often used not as documented [1] but rather as show my config in menuconfig for convenience even if my dependency is not met, and select the dependency even though I know it can screw up the dependency chain. Perhaps people use select because it offers, given the problem they face, a reasonable way to make the kconfig tools generate a sensible .config. It helps them to spend less time fiddling with Kconfig files. And they expect that it helps others to configure their build more easily, as it might save those others some work. In the big picture, it feels like menuconfig needs a way to display items whose dependencies are not met, and a way to recursively enable said items and all their dependencies when told. How could that work its way through (multiple levels of) things like: depends on FOO || (BAZ BAR) This would reduce the resistance to sticking with select when clearly depends is what's meant. I had drafted a rather verbose response to this. But I think I'm not really sure what you're saying here, probably because select and depends on are rather different. How would you know that the actual intention was to use depends on? Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] media: i2c: add support for omnivision's ov2659 sensor
On Sat, 2015-03-07 at 15:21 +, Lad Prabhakar wrote: --- /dev/null +++ b/drivers/media/i2c/ov2659.c @@ -0,0 +1,1495 @@ +/* + * Omnivision OV2659 CMOS Image Sensor driver + * + * Copyright (C) 2015 Texas Instruments, Inc. + * + * Benoit Parrot bpar...@ti.com + * Lad, Prabhakar prabhakar.cse...@gmail.com + * + * This program is free software; you may redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE + * SOFTWARE. + */ This states the license of this modules is GPL v2. +MODULE_LICENSE(GPL); So you probably want MODULE_LICENSE(GPL v2); here. (If you think this is a bit silly, and somewhere I think so too, you're invited to jump into the discussion starting at https://lkml.org/lkml/2015/3/7/119 .) Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linuxtv-media:master 7661/7664] ERROR: omapdss_compat_init [drivers/media/platform/omap/omap-vout.ko] undefined!
Hi Fengguang On Wed, 2014-11-26 at 11:30 -0800, Fengguang Wu wrote: On Wed, Nov 26, 2014 at 08:50:41AM +0100, Paul Bolle wrote: Hi Fengguang, On Wed, 2014-11-26 at 09:34 +0800, kbuild test robot wrote: tree: git://linuxtv.org/media_tree.git master head: 504febc3f98c87a8bebd8f2f274f32c0724131e4 commit: 6b213e81ddf8b265383c9a1a1884432df88f701e [7661/7664] [media] omap: Fix typo HAS_MMU config: m68k-allmodconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 6b213e81ddf8b265383c9a1a1884432df88f701e # save the attached .config to linux build tree make.cross ARCH=m68k This is the first time I've made the kbuild test robot trip. So I'm not sure how to interpret this. Is ARCH=m68k the only build that failed through this commit? Or is it the first build that failed? If so, how can I determine which arches build correctly? It's the first build that failed. I checked log and find these failures, which covers m68k, mips and i386. By now your bot sent its fanmail for those other two architectures too. So the lesson here is, apparently, to wait a few hours. By then the bots should have done their thing and I can do damage control. Luckily, for me, Mauro already has done damage control (see http://git.linuxtv.org/cgit.cgi/mchehab/media-next.git/commit/?id=7996d58f03c14c0caf9935e64bb32ed04dbe79c5 ). So all I'll have to do now is ponder how to make sure your bot leaves me alone in the future. Thanks, both of you! Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linuxtv-media:master 7661/7664] ERROR: omapdss_compat_init [drivers/media/platform/omap/omap-vout.ko] undefined!
Hi Fengguang, On Wed, 2014-11-26 at 09:34 +0800, kbuild test robot wrote: tree: git://linuxtv.org/media_tree.git master head: 504febc3f98c87a8bebd8f2f274f32c0724131e4 commit: 6b213e81ddf8b265383c9a1a1884432df88f701e [7661/7664] [media] omap: Fix typo HAS_MMU config: m68k-allmodconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 6b213e81ddf8b265383c9a1a1884432df88f701e # save the attached .config to linux build tree make.cross ARCH=m68k This is the first time I've made the kbuild test robot trip. So I'm not sure how to interpret this. Is ARCH=m68k the only build that failed through this commit? Or is it the first build that failed? If so, how can I determine which arches build correctly? All error/warnings: ERROR: omapdss_compat_init [drivers/media/platform/omap/omap-vout.ko] undefined! ERROR: omap_dss_get_overlay_manager [drivers/media/platform/omap/omap-vout.ko] undefined! ERROR: omap_dss_get_num_overlay_managers [drivers/media/platform/omap/omap-vout.ko] undefined! ERROR: omap_dss_get_overlay [drivers/media/platform/omap/omap-vout.ko] undefined! ERROR: omapdss_is_initialized [drivers/media/platform/omap/omap-vout.ko] undefined! ERROR: omap_dispc_register_isr [drivers/media/platform/omap/omap-vout.ko] undefined! ERROR: omapdss_get_version [drivers/media/platform/omap/omap-vout.ko] undefined! ERROR: omap_dss_put_device [drivers/media/platform/omap/omap-vout.ko] undefined! ERROR: omap_dss_get_next_device [drivers/media/platform/omap/omap-vout.ko] undefined! ERROR: omap_dispc_unregister_isr [drivers/media/platform/omap/omap-vout.ko] undefined! ERROR: omapdss_compat_uninit [drivers/media/platform/omap/omap-vout.ko] undefined! ERROR: omap_dss_get_device [drivers/media/platform/omap/omap-vout.ko] undefined! ERROR: omap_dss_get_num_overlays [drivers/media/platform/omap/omap-vout.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation Thanks, Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] omap24xx/tcm825x: remove pointless Makefile entry
The deprecated omap2 camera drivers were recently removed. Both the Kconfig symbol VIDEO_TCM825X and the drivers/staging/media/omap24xx directory are gone. So the Makefile entry that references both is now pointless. Remove it too. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Tested by grepping the tree. Triggered by commit db85a0403be4 ([media] omap24xx/tcm825x: remove deprecated omap2 camera drivers.), which is included in next-20141124. What happened is that it removed only one of the two Makefile entries for omap24xx. drivers/staging/media/Makefile | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile index 97bfef97f838..30fb352fc4a9 100644 --- a/drivers/staging/media/Makefile +++ b/drivers/staging/media/Makefile @@ -4,7 +4,6 @@ obj-$(CONFIG_LIRC_STAGING) += lirc/ obj-$(CONFIG_VIDEO_DT3155) += dt3155v4l/ obj-$(CONFIG_VIDEO_DM365_VPFE) += davinci_vpfe/ obj-$(CONFIG_VIDEO_OMAP4) += omap4iss/ -obj-$(CONFIG_VIDEO_TCM825X) += omap24xx/ obj-$(CONFIG_DVB_MN88472) += mn88472/ obj-$(CONFIG_DVB_MN88473) += mn88473/ -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] omap24xx/tcm825x: remove pointless Makefile entry
On Mon, 2014-11-24 at 12:08 +0100, Hans Verkuil wrote: I found the same thing and it is already part of my pull request to Mauro. Either way, this trivial issue will be solved. Thanks, Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] omap: Fix typo HAS_MMU
Commit 38a073116525 ([media] omap: be sure that MMU is there for COMPILE_TEST) added a dependency on HAS_MMU. There's no Kconfig symbol HAS_MMU. Use MMU instead. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- 0) Perhaps it would have been better to add a line or two explaining why MMU is now a separate dependency, as Mauro suggested. Commit 38a073116525 tells us that COMPILE_TEST fail[s] on (some) archs without MMU. It doesn't tell on which architectures nor how it fails. And I was unable to figure that out myself so I decided to stay silent on that aspect of this patch. 1) A Fixes: line seems not worth the trouble here. 2) Tested on top of next-20141124 by doing, in short: cp arch/x86/configs/x86_64_defconfig .config echo CONFIG_COMPILE_TEST=y .config echo CONFIG_MEDIA_SUPPORT=y .config echo CONFIG_MEDIA_CAMERA_SUPPORT=y .config echo CONFIG_V4L_PLATFORM_DRIVERS=y .config echo CONFIG_VIDEO_OMAP2_VOUT=[ym] .config yes | make oldconfig both before and after applying this patch and diffing the before and after .config. Only with this patch I see CONFIG_VIDEO_OMAP2_VOUT=[ym] appear in the .config. 3) Actually, I've wasted quite a bit of time cobbling together a script to test commits locally. The test(s) I want to run is (are) saved in a git note for that commit. The script parses this note and runs the test(s). Have I been reinventing the wheel? drivers/media/platform/omap/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/omap/Kconfig b/drivers/media/platform/omap/Kconfig index 05de442d24e4..8f27cdadf8b8 100644 --- a/drivers/media/platform/omap/Kconfig +++ b/drivers/media/platform/omap/Kconfig @@ -3,7 +3,8 @@ config VIDEO_OMAP2_VOUT_VRFB config VIDEO_OMAP2_VOUT tristate OMAP2/OMAP3 V4L2-Display driver - depends on ARCH_OMAP2 || ARCH_OMAP3 || (COMPILE_TEST HAS_MMU) + depends on MMU + depends on ARCH_OMAP2 || ARCH_OMAP3 || COMPILE_TEST select VIDEOBUF_GEN select VIDEOBUF_DMA_CONTIG select OMAP2_DSS if HAS_IOMEM ARCH_OMAP2PLUS -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL for v3.18-rc1] media updates
Hi Mauro, On Mon, 2014-10-20 at 10:31 +0200, Paul Bolle wrote: This became commit 38a073116525 ([media] omap: be sure that MMU is there for COMPILE_TEST). As I reported in http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/82299 it adds an (optional) test for a Kconfig symbol HAS_MMU. There's no such symbol. So that test will always fail. Did you perhaps mean simply MMU? This typo is still present in both next-20141110 and v3.18-rc4. And I've first reported it nearly two months ago. I see two fixes: 1) s/HAS_MMU/MMU/ 2) s/ || (COMPILE_TEST HAS_MMU)// Which would you prefer? Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL for v3.18-rc1] media updates
On Mon, 2014-11-10 at 18:54 -0200, Mauro Carvalho Chehab wrote: Em Mon, 10 Nov 2014 21:45:56 +0100 Paul Bolle pebo...@tiscali.nl escreveu: This typo is still present in both next-20141110 and v3.18-rc4. And I've first reported it nearly two months ago. I see two fixes: 1) s/HAS_MMU/MMU/ 2) s/ || (COMPILE_TEST HAS_MMU)// Which would you prefer? Hmm... Probably patchwork didn't get your patch. There's no patch, not yet. I try to report stuff like this before sending patches. The idea here being that the people familiar with the code tend to fix things better and quicker. IMHO, the best would be: depends on HAS_MMU You really like the HAS_MMU symbol, don't you? depends on ARCH_OMAP2 || ARCH_OMAP3 || COMPILE_TEST But I understand what you're suggesting here. Should I draft a, probably untested, patch? Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL for v3.18-rc1] media updates
Mauro, On Thu, 2014-10-09 at 14:18 -0300, Mauro Carvalho Chehab wrote: Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v3.18-rc1 [...] Mauro Carvalho Chehab (180): [...] [media] omap: be sure that MMU is there for COMPILE_TEST This became commit 38a073116525 ([media] omap: be sure that MMU is there for COMPILE_TEST). As I reported in http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/82299 it adds an (optional) test for a Kconfig symbol HAS_MMU. There's no such symbol. So that test will always fail. Did you perhaps mean simply MMU? Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for Oct 8 (media/usb/gspca)
On Wed, 2014-10-08 at 22:50 -0300, Mauro Carvalho Chehab wrote: Em Wed, 08 Oct 2014 13:53:33 -0700 Randy Dunlap rdun...@infradead.org escreveu: On 10/08/14 11:31, Mauro Carvalho Chehab wrote: From gpsca's PoV, IMHO, it should be fine to disable the webcam buttons if the webcam was compiled as builtin and the input subsystem is compiled as module. The core feature expected on a camera is to capture streams. Buttons are just a plus. Also, most cams don't even have buttons. The gspca subdriver has support for buttons for the few models that have it. So, IMHO, it should be ok to have GSPCA=y and INPUT=m, provided that the buttons will be disabled. Then all of the sub-drivers that use IS_ENABLED(CONFIG_INPUT) should be changed to use IS_BUILTIN(CONFIG_INPUT). But that is too restrictive IMO. The input subsystem will work fine when CONFIG_INPUT=m and the GSPCA drivers are also loadable modules. Agreed. Maybe the solution would be something more complex like (for drivers/media/usb/gspca/zc3xx.c): #if (IS_BUILTIN(CONFIG_INPUT)) || (IS_ENABLED(CONFIG_INPUT) !IS_BUILTIN(CONFIG_USB_GSPCA_ZC3XX)) The above discussion meanders a bit, and I just stumbled onto it, but would #if IS_BUILTIN(CONFIG_INPUT) || (IS_MODULE(CONFIG_INPUT) defined(MODULE)) cover your requirements when using macros? Probably the best would be to write another macro that would evaluate like the above. Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for Oct 8 (media/usb/gspca)
On Thu, 2014-10-09 at 07:30 -0300, Mauro Carvalho Chehab wrote: Em Thu, 09 Oct 2014 08:45:28 +0200 Paul Bolle pebo...@tiscali.nl escreveu: The above discussion meanders a bit, and I just stumbled onto it, but would #if IS_BUILTIN(CONFIG_INPUT) || (IS_MODULE(CONFIG_INPUT) defined(MODULE)) cover your requirements when using macros? No. What we need to do, for all gspca sub-drivers that have optional support for buttons is to only enable the buttons support if: CONFIG_INPUT=y or CONFIG_INPUT=m and CONFIG_USB_GSPCA_submodule=m If we use a reverse logic, we need to disable the code if: # CONFIG_INPUT is not set or CONFIG_INPUT=m and CONFIG_USB_GSPCA_submodule=y The rationale for disabling the code on the last expression is that a builtin code cannot call a function inside a module. Also, as the submodule is already being compiled, we know that CONFIG_USB_GSPCA_submodule is either module or builtin. So, either one of those expressions should work: #if (IS_BUILTIN(CONFIG_INPUT)) || (IS_ENABLED(CONFIG_INPUT) !IS_BUILTIN(CONFIG_USB_GSPCA_submodule)) or #if (IS_BUILTIN(CONFIG_INPUT)) || (IS_MODULE(CONFIG_INPUT) IS_MODULE(CONFIG_USB_GSPCA_submodule) defined(MODULE)) I thought MODULE was only defined for code that will be part of a module. So IS_MODULE(CONFIG_USB_GSPCA_submodule) and defined(MODULE) should be equal when used _inside_ [...]/usb/gspca/that_submodule.c, shouldn't they? That would make this option basically identical to my suggestion. Or are you thinking about using these tests outside of these submodules themselves? or #if (IS_BUILTIN(CONFIG_INPUT)) || (IS_ENABLED(CONFIG_INPUT) IS_MODULE(CONFIG_USB_GSPCA_submodule)) I think it's clearer to use IS_BUILTIN(CONFIG_FOO) || (IS_MODULE(CONFIG_FOO) [...]) Ditto above. Perhaps just a matter of taste. (Depending on INPUT is apparently not possible for these submodules. So obviously any solution needs to check whether input is available, say like if (IS_MODULE(CONFIG_INPUT)) if (!is_input_loaded()) goto no_input; Doesn't it?) Thanks, Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Remove optional dependencies on PLAT_S5P
Commit d78c16ccde96 (ARM: SAMSUNG: Remove remaining legacy code) removed the Kconfig symbol PLAT_S5P. The seven dependencies on that symbol have evaluated to false since next-20140716 (for linux-next) and v3.17-rc1 (for mainline). Probably no one noticed because these are all optional dependencies. I've mentioned this a few times: - http://lkml.kernel.org/r/1405505756.4408.24.camel@x220 - http://lkml.kernel.org/r/1409825817.5546.99.camel@x220 - http://lkml.kernel.org/r/1411068565.2017.83.camel@x220 As far as I know no fix for this is pending. So let's remove these optional dependencies. If it turns out that they should actually be replaced by another symbol, as was said in a reply to my first message but never done, this series can be used as a reference for the places that need fixing. This series is done on top of next-20141003. It is tested by grepping the tree only. Paul Bolle (4): [media] Remove optional dependencies on PLAT_S5P [media] exynos4-is: Remove optional dependency on PLAT_S5P [media] Remove optional dependency on PLAT_S5P usb: host: Remove optional dependencies on PLAT_S5P drivers/media/platform/Kconfig| 6 +++--- drivers/media/platform/exynos4-is/Kconfig | 2 +- drivers/media/platform/s5p-tv/Kconfig | 2 +- drivers/usb/host/Kconfig | 4 ++-- 4 files changed, 7 insertions(+), 7 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] [media] Remove optional dependencies on PLAT_S5P
Commit d78c16ccde96 (ARM: SAMSUNG: Remove remaining legacy code) removed the Kconfig symbol PLAT_S5P. Remove three optional dependencies on that symbol from this Kconfig file too. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- drivers/media/platform/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index bee9074ebc13..19774b60ba38 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -166,7 +166,7 @@ config VIDEO_MEM2MEM_DEINTERLACE config VIDEO_SAMSUNG_S5P_G2D tristate Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver depends on VIDEO_DEV VIDEO_V4L2 - depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST + depends on ARCH_EXYNOS || COMPILE_TEST depends on HAS_DMA select VIDEOBUF2_DMA_CONTIG select V4L2_MEM2MEM_DEV @@ -178,7 +178,7 @@ config VIDEO_SAMSUNG_S5P_G2D config VIDEO_SAMSUNG_S5P_JPEG tristate Samsung S5P/Exynos3250/Exynos4 JPEG codec driver depends on VIDEO_DEV VIDEO_V4L2 - depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST + depends on ARCH_EXYNOS || COMPILE_TEST depends on HAS_DMA select VIDEOBUF2_DMA_CONTIG select V4L2_MEM2MEM_DEV @@ -189,7 +189,7 @@ config VIDEO_SAMSUNG_S5P_JPEG config VIDEO_SAMSUNG_S5P_MFC tristate Samsung S5P MFC Video Codec depends on VIDEO_DEV VIDEO_V4L2 - depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST + depends on ARCH_EXYNOS || COMPILE_TEST depends on HAS_DMA select VIDEOBUF2_DMA_CONTIG default n -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] [media] exynos4-is: Remove optional dependency on PLAT_S5P
Commit d78c16ccde96 (ARM: SAMSUNG: Remove remaining legacy code) removed the Kconfig symbol PLAT_S5P. Remove an optional dependency on that symbol from this Kconfig file too. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- drivers/media/platform/exynos4-is/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/exynos4-is/Kconfig b/drivers/media/platform/exynos4-is/Kconfig index 77c951237744..775c3278d0eb 100644 --- a/drivers/media/platform/exynos4-is/Kconfig +++ b/drivers/media/platform/exynos4-is/Kconfig @@ -2,7 +2,7 @@ config VIDEO_SAMSUNG_EXYNOS4_IS bool Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver depends on VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API - depends on (PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST) + depends on (ARCH_EXYNOS || COMPILE_TEST) depends on OF COMMON_CLK help Say Y here to enable camera host interface devices for -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] [media] Remove optional dependency on PLAT_S5P
On Mon, 2014-10-06 at 11:26 +0200, Arnd Bergmann wrote: On Monday 06 October 2014 11:10:26 Paul Bolle wrote: config VIDEO_SAMSUNG_S5P_TV bool Samsung TV driver for S5P platform depends on PM_RUNTIME - depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST + depends on ARCH_EXYNOS || COMPILE_TEST default n ---help--- Say Y here to enable selecting the TV output devices for I wonder if it should now allow being built for ARCH_S5PV210. That was what Tomasz Figa claimed in http://lkml.kernel.org/r/53c676db.6070...@samsung.com Maybe it was a mistake to remove the PLAT_S5P symbol without changing the use here? At least it was a bit sloppy to remove the symbol without touching this (and six other) dependencies. But after nearly three months I lost patience waiting for a fix to be submitted. My cleanup doesn't really change a thing. And a proper fix, if needed, is still possible after this has landed. Does S5PV210 have this device? Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] [media] Remove optional dependency on PLAT_S5P
On Mon, 2014-10-06 at 11:34 +0200, Sylwester Nawrocki wrote: On 06/10/14 11:26, Arnd Bergmann wrote: Does S5PV210 have this device? Yes, it does. Indeed, in all patches in this series we should have replaced PLAT_S5P with ARCH_S5PV210. If somebody would actually do that, that would be great. I lost patience waiting for a patch that did that. So I submitted these cleanup patches that basically change nothing. Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] [media] Remove references to non-existent PLAT_S5P symbol
On Mon, 2014-10-06 at 18:10 +0200, Sylwester Nawrocki wrote: The PLAT_S5P Kconfig symbol was removed in commit d78c16ccde96 (ARM: SAMSUNG: Remove remaining legacy code). However, there are still some references to that symbol left, fix that by substituting them with ARCH_S5PV210. Reported-by: Paul Bolle pebo...@tiscali.nl Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Thanks for picking this up! Should Fixes: d78c16ccde96 (ARM: SAMSUNG: Remove remaining legacy code) be added so this will end up in stable for v3.17? drivers/media/platform/Kconfig|6 +++--- drivers/media/platform/exynos4-is/Kconfig |2 +- drivers/media/platform/s5p-tv/Kconfig |2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index bee9074..3aac88f 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -166,7 +166,7 @@ config VIDEO_MEM2MEM_DEINTERLACE config VIDEO_SAMSUNG_S5P_G2D tristate Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver depends on VIDEO_DEV VIDEO_V4L2 - depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST + depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST depends on HAS_DMA select VIDEOBUF2_DMA_CONTIG select V4L2_MEM2MEM_DEV @@ -178,7 +178,7 @@ config VIDEO_SAMSUNG_S5P_G2D config VIDEO_SAMSUNG_S5P_JPEG tristate Samsung S5P/Exynos3250/Exynos4 JPEG codec driver depends on VIDEO_DEV VIDEO_V4L2 - depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST + depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST depends on HAS_DMA select VIDEOBUF2_DMA_CONTIG select V4L2_MEM2MEM_DEV @@ -189,7 +189,7 @@ config VIDEO_SAMSUNG_S5P_JPEG config VIDEO_SAMSUNG_S5P_MFC tristate Samsung S5P MFC Video Codec depends on VIDEO_DEV VIDEO_V4L2 - depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST + depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST depends on HAS_DMA select VIDEOBUF2_DMA_CONTIG default n diff --git a/drivers/media/platform/exynos4-is/Kconfig b/drivers/media/platform/exynos4-is/Kconfig index 77c9512..b7b2e47 100644 --- a/drivers/media/platform/exynos4-is/Kconfig +++ b/drivers/media/platform/exynos4-is/Kconfig @@ -2,7 +2,7 @@ config VIDEO_SAMSUNG_EXYNOS4_IS bool Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver depends on VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API - depends on (PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST) + depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST depends on OF COMMON_CLK help Say Y here to enable camera host interface devices for diff --git a/drivers/media/platform/s5p-tv/Kconfig b/drivers/media/platform/s5p-tv/Kconfig index a9d56f8..beb180e 100644 --- a/drivers/media/platform/s5p-tv/Kconfig +++ b/drivers/media/platform/s5p-tv/Kconfig @@ -9,7 +9,7 @@ config VIDEO_SAMSUNG_S5P_TV bool Samsung TV driver for S5P platform depends on PM_RUNTIME - depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST + depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST default n ---help--- Say Y here to enable selecting the TV output devices for Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: randconfig build error with next-20140923, in drivers/media/mmc/siano/smssdio.c
On Tue, 2014-09-23 at 09:38 -0700, Jim Davis wrote: Building with the attached random configuration file, drivers/built-in.o: In function `smssdio_remove': smssdio.c:(.text+0x14751c): undefined reference to `smscore_putbuffer' smssdio.c:(.text+0x147526): undefined reference to `smscore_unregister_device' drivers/built-in.o: In function `smssdio_interrupt': smssdio.c:(.text+0x1475aa): undefined reference to `smscore_getbuffer' smssdio.c:(.text+0x147695): undefined reference to `smscore_putbuffer' smssdio.c:(.text+0x1476f3): undefined reference to `smscore_putbuffer' smssdio.c:(.text+0x14772a): undefined reference to `smsendian_handle_rx_message' smssdio.c:(.text+0x147737): undefined reference to `smscore_onresponse' drivers/built-in.o: In function `smssdio_sendrequest': smssdio.c:(.text+0x14776c): undefined reference to `smsendian_handle_tx_message' drivers/built-in.o: In function `smssdio_probe': smssdio.c:(.text+0x14786c): undefined reference to `sms_get_board' smssdio.c:(.text+0x14788a): undefined reference to `smscore_register_device' smssdio.c:(.text+0x1478a1): undefined reference to `smscore_set_board_id' smssdio.c:(.text+0x1478fa): undefined reference to `smscore_start_device' smssdio.c:(.text+0x14792d): undefined reference to `smscore_unregister_device' make: *** [vmlinux] Error 1 # # Automatically generated file; DO NOT EDIT. # Linux/x86 3.17.0-rc6 Kernel Configuration # [...] CONFIG_SMS_SDIO_DRV=y [...] CONFIG_SMS_SIANO_MDTV=m [...] Should SMS_SDIO_DRV depend on SMS_SIANO_MDTV? Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2,35/35,media] omap: be sure that MMU is there for COMPILE_TEST
Hi Mauro, On Tue, 2014-08-26 at 18:55 -0300, Mauro Carvalho Chehab wrote: COMPILE_TEST fail on (some) archs without MMU. Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com This patch just landed in next-20140919 as commit 38a073116525 ([media] omap: be sure that MMU is there for COMPILE_TEST). --- drivers/media/platform/omap/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/omap/Kconfig b/drivers/media/platform/omap/Kconfig index 2253bf102ed9..05de442d24e4 100644 --- a/drivers/media/platform/omap/Kconfig +++ b/drivers/media/platform/omap/Kconfig @@ -3,7 +3,7 @@ config VIDEO_OMAP2_VOUT_VRFB config VIDEO_OMAP2_VOUT tristate OMAP2/OMAP3 V4L2-Display driver - depends on ARCH_OMAP2 || ARCH_OMAP3 || COMPILE_TEST + depends on ARCH_OMAP2 || ARCH_OMAP3 || (COMPILE_TEST HAS_MMU) There's no Kconfig symbol HAS_MMU. So this last test will always fail. Did you perhaps mean simply MMU? select VIDEOBUF_GEN select VIDEOBUF_DMA_CONTIG Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] dib0090: remove manual configuration system
Hi Mauro, On Thu, 2014-09-04 at 12:36 -0300, Mauro Carvalho Chehab wrote: Em Thu, 22 May 2014 14:48:07 +0200 Paul Bolle pebo...@tiscali.nl escreveu: dib0900.c has always shipped with its own, manual, configuration system. There a three problems with it. 1) macros that are defined, but not used: CONFIG_SYS_DVBT CONFIG_DIB0090_USE_PWM_AGC 2) checks for macros that are always true: CONFIG_SYS_ISDBT CONFIG_BAND_CBAND CONFIG_BAND_VHF CONFIG_BAND_UHF 3) checks for macros that are never defined and are always false: CONFIG_BAND_SBAND CONFIG_STANDARD_DAB CONFIG_STANDARD_DVBT CONFIG_TUNER_DIB0090_P1B_SUPPORT CONFIG_BAND_LBAND Remove all references to these macros, and, of course, remove the code hidden behind the macros that are never defined too. IMHO, it is OK to remove the macros that are always true and the ones that aren't used. I see. I hope to send a v2 that does that one of these days. However, I don't like the idea of removing the other macros. This is a tuner driver that can be used on other bands, and some day we might end implementing analog support for the Dibcom driver or to add something that will require the code there. So, IMHO, better to keep the code there. But would you consider a patch that at least moves those macros out of the CONFIG_* namespace (ie, a patch that prefixes those macros with, say, DIB0090_)? Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Kconfig symbol MX1_VIDEO
Alexander, Your patch [media] media: mx1_camera: Remove driver landed in today's linux-next (ie, next-20140627), as commit 90b055898e9d. It is archived at http://www.spinics.net/lists/linux-media/msg76764.html . It removes the Kconfig symbols MX1_VIDEO en VIDEO_MX1. It only removes the code depending on VIDEO_MX1 (ie, in drivers/media/platform/soc_camera). A previous version of that patch is archived at http://www.spinics.net/lists/linux-media/msg76432.html . (Please, next time you submit a second version of a patch mark it as a v2 and add some info below the --- marker about the differences to the first version.) That previous version removed the code depending on both symbols. But a quick glance at the discussion about that patch shows that you were asked to not remove the code depending on MX1_VIDEO (ie, in arch/arm/mach-imx/). Would you perhaps know whether a patch to remove the arch/arm/mach-imx/ code is pending somewhere? Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] sms: Remove CONFIG_ prefix from Kconfig symbols
On Wed, 2014-04-16 at 17:47 +0200, Paul Bolle wrote: Remove the CONFIG_ prefix from two Kconfig symbols in a dependency for SMS_SIANO_DEBUGFS. This prefix is invalid inside Kconfig files. Note that the current (common sense) dependency on SMS_USB_DRV and SMS_SDIO_DRV being equal ensures that SMS_SIANO_DEBUGFS will not violate its constraints. These constraint are that: - it should only be built if SMS_USB_DRV is set; - it can't be builtin if USB support is modular. So drop the dependency on SMS_USB_DRV, as it is unneeded. Fixes: 6c84b214284e ([media] sms: fix randconfig building error) Reported-by: Martin Walch walch.mar...@web.de Signed-off-by: Paul Bolle pebo...@tiscali.nl --- This is not runtime tested, as I don't have the hardware. A matrix of the three cases in which this symbol can be set, to aid review and to see whether I actually understood the constraints: USB SMS_USB_DRV SMS_SDIO_DRV SMS_SIANO_MDTV SMS_SIANO_DEBUGFS mmm m y ymm m y yyy y y By the way, I found myself staring at the entries in this file for quite some time. Perhaps things would have been easier to understand if SMS_USB_DRV and SMS_SDIO_DRV both selected SMS_SIANO_MDTV. But I didn't dare to test that idea. This can still be seen in v3.16-rc1 and in next-20140616. Debugfs for smsdvb has been unbuildable since v3.12. That problem has been reported even before v3.12 was released. Does no one care and can it be removed? drivers/media/common/siano/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/media/common/siano/Kconfig b/drivers/media/common/siano/Kconfig index f953d33ee151..4bfbd5f463d1 100644 --- a/drivers/media/common/siano/Kconfig +++ b/drivers/media/common/siano/Kconfig @@ -22,8 +22,7 @@ config SMS_SIANO_DEBUGFS bool Enable debugfs for smsdvb depends on SMS_SIANO_MDTV depends on DEBUG_FS - depends on SMS_USB_DRV - depends on CONFIG_SMS_USB_DRV = CONFIG_SMS_SDIO_DRV + depends on SMS_USB_DRV = SMS_SDIO_DRV ---help--- Choose Y to enable visualizing a dump of the frontend Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] staging: lirc: remove checks for CONFIG_LIRC_SERIAL_NSLU2
When support for homebrew serial port receivers was added in v2.6.36 its
code contained checks for CONFIG_LIRC_SERIAL_NSLU2. The related Kconfig
symbol didn't exist then. It still doesn't exist now. Remove these checks.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Untested. Done on top of next-20140526.
I left the #define LIRC_NSLU2 line alone.
drivers/staging/media/lirc/lirc_serial.c | 81
1 file changed, 81 deletions(-)
diff --git a/drivers/staging/media/lirc/lirc_serial.c
b/drivers/staging/media/lirc/lirc_serial.c
index dc5ba43116c7..efe561cd0935 100644
--- a/drivers/staging/media/lirc/lirc_serial.c
+++ b/drivers/staging/media/lirc/lirc_serial.c
@@ -73,9 +73,6 @@
#include linux/fcntl.h
#include linux/spinlock.h
-#ifdef CONFIG_LIRC_SERIAL_NSLU2
-#include asm/hardware.h
-#endif
/* From Intel IXP42X Developer's Manual (#252480-005): */
/* ftp://download.intel.com/design/network/manuals/25248005.pdf */
#define UART_IE_IXP42X_UUE 0x40 /* IXP42X UART Unit enable */
@@ -198,33 +195,6 @@ static struct lirc_serial hardware[] = {
.features= LIRC_CAN_REC_MODE2
#endif
},
-
-#ifdef CONFIG_LIRC_SERIAL_NSLU2
- /*
-* Modified Linksys Network Storage Link USB 2.0 (NSLU2):
-* We receive on CTS of the 2nd serial port (R142,LHS), we
-* transmit with a IR diode between GPIO[1] (green status LED),
-* and ground (Matthias Goebl matthias.go...@goebl.net).
-* See also http://www.nslu2-linux.org for this device
-*/
- [LIRC_NSLU2] = {
- .lock = __SPIN_LOCK_UNLOCKED(hardware[LIRC_NSLU2].lock),
- .signal_pin= UART_MSR_CTS,
- .signal_pin_change = UART_MSR_DCTS,
- .on = (UART_MCR_RTS | UART_MCR_OUT2 | UART_MCR_DTR),
- .off = (UART_MCR_RTS | UART_MCR_OUT2),
- .send_pulse = send_pulse_homebrew,
- .send_space = send_space_homebrew,
-#ifdef CONFIG_LIRC_SERIAL_TRANSMITTER
- .features= (LIRC_CAN_SET_SEND_DUTY_CYCLE |
- LIRC_CAN_SET_SEND_CARRIER |
- LIRC_CAN_SEND_PULSE | LIRC_CAN_REC_MODE2)
-#else
- .features= LIRC_CAN_REC_MODE2
-#endif
- },
-#endif
-
};
#define RS_ISR_PASS_LIMIT 256
@@ -315,16 +285,6 @@ static void soutp(int offset, u8 value)
static void on(void)
{
-#ifdef CONFIG_LIRC_SERIAL_NSLU2
- /*
-* On NSLU2, we put the transmit diode between the output of the green
-* status LED and ground
-*/
- if (type == LIRC_NSLU2) {
- gpio_set_value(NSLU2_LED_GRN, 0);
- return;
- }
-#endif
if (txsense)
soutp(UART_MCR, hardware[type].off);
else
@@ -333,12 +293,6 @@ static void on(void)
static void off(void)
{
-#ifdef CONFIG_LIRC_SERIAL_NSLU2
- if (type == LIRC_NSLU2) {
- gpio_set_value(NSLU2_LED_GRN, 1);
- return;
- }
-#endif
if (txsense)
soutp(UART_MCR, hardware[type].on);
else
@@ -793,20 +747,6 @@ static int hardware_init_port(void)
sinp(UART_IIR);
sinp(UART_MSR);
-#ifdef CONFIG_LIRC_SERIAL_NSLU2
- if (type == LIRC_NSLU2) {
- /* Setup NSLU2 UART */
-
- /* Enable UART */
- soutp(UART_IER, sinp(UART_IER) | UART_IE_IXP42X_UUE);
- /* Disable Receiver data Time out interrupt */
- soutp(UART_IER, sinp(UART_IER) ~UART_IE_IXP42X_RTOIE);
- /* set out2 = interrupt unmask; off() doesn't set MCR
- on NSLU2 */
- soutp(UART_MCR, UART_MCR_RTS|UART_MCR_OUT2);
- }
-#endif
-
/* Set line for power source */
off();
@@ -842,16 +782,6 @@ static int lirc_serial_probe(struct platform_device *dev)
{
int i, nlow, nhigh, result;
-#ifdef CONFIG_LIRC_SERIAL_NSLU2
- /* This GPIO is used for a LED on the NSLU2 */
- result = devm_gpio_request(dev, NSLU2_LED_GRN, lirc-serial);
- if (result)
- return result;
- result = gpio_direction_output(NSLU2_LED_GRN, 0);
- if (result)
- return result;
-#endif
-
result = request_irq(irq, lirc_irq_handler,
(share_irq ? IRQF_SHARED : 0),
LIRC_DRIVER_NAME, (void *)hardware);
@@ -1217,14 +1147,6 @@ static int __init lirc_serial_init_module(void)
io = io ? io : 0x3f8;
irq = irq ? irq : 4;
break;
-#ifdef CONFIG_LIRC_SERIAL_NSLU2
- case LIRC_NSLU2:
- io = io ? io : IRQ_IXP4XX_UART2;
- irq = irq ? irq : (IXP4XX_UART2_BASE_VIRT + REG_OFFSET);
- iommap = iommap ? iommap : IXP4XX_UART2_BASE_PHYS;
- ioshift = ioshift ? ioshift : 2;
- break;
-#endif
default:
return -EINVAL
[PATCH] [media] dib0090: remove manual configuration system
dib0900.c has always shipped with its own, manual, configuration
system. There a three problems with it.
1) macros that are defined, but not used:
CONFIG_SYS_DVBT
CONFIG_DIB0090_USE_PWM_AGC
2) checks for macros that are always true:
CONFIG_SYS_ISDBT
CONFIG_BAND_CBAND
CONFIG_BAND_VHF
CONFIG_BAND_UHF
3) checks for macros that are never defined and are always false:
CONFIG_BAND_SBAND
CONFIG_STANDARD_DAB
CONFIG_STANDARD_DVBT
CONFIG_TUNER_DIB0090_P1B_SUPPORT
CONFIG_BAND_LBAND
Remove all references to these macros, and, of course, remove the code
hidden behind the macros that are never defined too.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
0) Compile tested. I don't have the hardware.
1) This might be a bit hard to review. Should I split it in two or three
patches?
2) dib0070.c has a reference to CONFIG_SYS_ISDBT. I'll remove it in a
future patch.
3) If this gets accepted I might be inclined to clean up the coding
style in a future patch. It needs cleaning up quite a bit.
drivers/media/dvb-frontends/dib0090.c | 130 --
1 file changed, 130 deletions(-)
diff --git a/drivers/media/dvb-frontends/dib0090.c
b/drivers/media/dvb-frontends/dib0090.c
index 3ee22ff76315..bb50fec4f475 100644
--- a/drivers/media/dvb-frontends/dib0090.c
+++ b/drivers/media/dvb-frontends/dib0090.c
@@ -46,13 +46,6 @@ MODULE_PARM_DESC(debug, turn on debugging (default: 0));
} \
} while (0)
-#define CONFIG_SYS_DVBT
-#define CONFIG_SYS_ISDBT
-#define CONFIG_BAND_CBAND
-#define CONFIG_BAND_VHF
-#define CONFIG_BAND_UHF
-#define CONFIG_DIB0090_USE_PWM_AGC
-
#define EN_LNA0 0x8000
#define EN_LNA1 0x4000
#define EN_LNA2 0x2000
@@ -1165,24 +1158,14 @@ int dib0090_gain_control(struct dvb_frontend *fe)
state-agc_freeze = 0;
dib0090_write_reg(state, 0x04, 0x0);
-#ifdef CONFIG_BAND_SBAND
- if (state-current_band == BAND_SBAND) {
- dib0090_set_rframp(state, rf_ramp_sband);
- dib0090_set_bbramp(state, bb_ramp_boost);
- } else
-#endif
-#ifdef CONFIG_BAND_VHF
if (state-current_band == BAND_VHF !state-identity.p1g) {
dib0090_set_rframp(state, rf_ramp_pwm_vhf);
dib0090_set_bbramp(state, bb_ramp_pwm_normal);
} else
-#endif
-#ifdef CONFIG_BAND_CBAND
if (state-current_band == BAND_CBAND !state-identity.p1g) {
dib0090_set_rframp(state, rf_ramp_pwm_cband);
dib0090_set_bbramp(state, bb_ramp_pwm_normal);
} else
-#endif
if ((state-current_band == BAND_CBAND || state-current_band
== BAND_VHF) state-identity.p1g) {
dib0090_set_rframp(state, rf_ramp_pwm_cband_7090p);
dib0090_set_bbramp(state, bb_ramp_pwm_normal_socs);
@@ -1220,14 +1203,12 @@ int dib0090_gain_control(struct dvb_frontend *fe)
if (*tune_state == CT_AGC_STEP_0) {
if (wbd_error 0 state-rf_gain_limit 0
!state-identity.p1g) {
-#ifdef CONFIG_BAND_CBAND
/* in case of CBAND tune reduce first the
lt_gain2 before adjusting the RF gain */
u8 ltg2 = (state-rf_lt_def 10) 0x7;
if (state-current_band == BAND_CBAND ltg2) {
ltg2 = 1;
state-rf_lt_def = ltg2 10; /*
reduce in 3 steps from 7 to 0 */
}
-#endif
} else {
state-agc_step = 0;
*tune_state = CT_AGC_STEP_1;
@@ -1238,16 +1219,6 @@ int dib0090_gain_control(struct dvb_frontend *fe)
adc = (adc * ((s32) 355774) + (((s32) 1) 20)) 21;
/* included in [0:-700] */
adc_error = (s16) (((s32) ADC_TARGET) - adc);
-#ifdef CONFIG_STANDARD_DAB
- if (state-fe-dtv_property_cache.delivery_system ==
STANDARD_DAB)
- adc_error -= 10;
-#endif
-#ifdef CONFIG_STANDARD_DVBT
- if (state-fe-dtv_property_cache.delivery_system ==
STANDARD_DVBT
-
(state-fe-dtv_property_cache.modulation == QAM_64 ||
state-fe-dtv_property_cache.modulation == QAM_16))
- adc_error += 60;
-#endif
-#ifdef CONFIG_SYS_ISDBT
if ((state-fe-dtv_property_cache.delivery_system ==
SYS_ISDBT) (((state-fe-dtv_property_cache.layer[0].segment_count
0)
@@ -1274,17 +1245,9 @@ int dib0090_gain_control(struct dvb_frontend *fe
[PATCH] [media] sms: Remove CONFIG_ prefix from Kconfig symbols
Remove the CONFIG_ prefix from two Kconfig symbols in a dependency for SMS_SIANO_DEBUGFS. This prefix is invalid inside Kconfig files. Note that the current (common sense) dependency on SMS_USB_DRV and SMS_SDIO_DRV being equal ensures that SMS_SIANO_DEBUGFS will not violate its constraints. These constraint are that: - it should only be built if SMS_USB_DRV is set; - it can't be builtin if USB support is modular. So drop the dependency on SMS_USB_DRV, as it is unneeded. Fixes: 6c84b214284e ([media] sms: fix randconfig building error) Reported-by: Martin Walch walch.mar...@web.de Signed-off-by: Paul Bolle pebo...@tiscali.nl --- This is not runtime tested, as I don't have the hardware. A matrix of the three cases in which this symbol can be set, to aid review and to see whether I actually understood the constraints: USB SMS_USB_DRV SMS_SDIO_DRV SMS_SIANO_MDTV SMS_SIANO_DEBUGFS mmm m y ymm m y yyy y y By the way, I found myself staring at the entries in this file for quite some time. Perhaps things would have been easier to understand if SMS_USB_DRV and SMS_SDIO_DRV both selected SMS_SIANO_MDTV. But I didn't dare to test that idea. drivers/media/common/siano/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/media/common/siano/Kconfig b/drivers/media/common/siano/Kconfig index f953d33ee151..4bfbd5f463d1 100644 --- a/drivers/media/common/siano/Kconfig +++ b/drivers/media/common/siano/Kconfig @@ -22,8 +22,7 @@ config SMS_SIANO_DEBUGFS bool Enable debugfs for smsdvb depends on SMS_SIANO_MDTV depends on DEBUG_FS - depends on SMS_USB_DRV - depends on CONFIG_SMS_USB_DRV = CONFIG_SMS_SDIO_DRV + depends on SMS_USB_DRV = SMS_SDIO_DRV ---help--- Choose Y to enable visualizing a dump of the frontend -- 1.9.0 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] drx-j: use customise option correctly
On Thu, 2014-04-03 at 13:11 -0300, Mauro Carvalho Chehab wrote: Devin Heitmueller (3): [...] [media] drx-j: add a driver for Trident drx-j frontend This commit introduced a reference to DVB_FE_CUSTOMISE. But that Kconfig symbol was removed in v3.7. It seems that the intent was to use MEDIA_SUBDRV_AUTOSELECT here. So the following (untested!) patch makes the Kconfig entry for Micronas DRX-J demodulator use the current symbol. It is basically a copy of d65fcbb0007b ([media] ts2020: use customise option correctly). - 8 - From: Paul Bolle pebo...@tiscali.nl The Kconfig entry for Micronas DRX-J demodulator defaults to modular if DVB_FE_CUSTOMISE is set. But that Kconfig symbol was replaced with MEDIA_SUBDRV_AUTOSELECT as of v3.7. So use the new symbol. And negate the logic, because MEDIA_SUBDRV_AUTOSELECT's logic is the opposite of the former logic. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- drivers/media/dvb-frontends/drx39xyj/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/dvb-frontends/drx39xyj/Kconfig b/drivers/media/dvb-frontends/drx39xyj/Kconfig index 15628eb5cf0c..6c2ccb6a506b 100644 --- a/drivers/media/dvb-frontends/drx39xyj/Kconfig +++ b/drivers/media/dvb-frontends/drx39xyj/Kconfig @@ -1,7 +1,7 @@ config DVB_DRX39XYJ tristate Micronas DRX-J demodulator depends on DVB_CORE I2C - default m if DVB_FE_CUSTOMISE + default m if !MEDIA_SUBDRV_AUTOSELECT help An ATSC 8VSB and QAM64/256 tuner module. Say Y when you want to support this frontend. -- 1.9.0 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] [media] v4l: omap4iss: Add DEBUG compiler flag
On Wed, 2014-03-05 at 20:45 -0800, Greg Kroah-Hartman wrote: On Thu, Mar 06, 2014 at 01:48:29AM +0100, Laurent Pinchart wrote: Would you recommend to drop driver-specific Kconfig options related to debugging and use CONFIG_DYNAMIC_DEBUG instead ? Yes, please do that, no one wants to rebuild drivers and subsystems with different options just for debugging. There are 50+ cases of Kconfig options setting the DEBUG flag, so there might be room for a series to remove some of those. (Note that Joe says there are valid reasons to use a Kconfig option to set this flag, if I'm not misunderstanding Joe.) For what it's worth, I've added the list of these (for v3.14-rc5) below. Paul Bolle v3.14-rc5:arch/powerpc/platforms/pseries/Makefile:ccflags-$(CONFIG_PPC_PSERIES_DEBUG) += -DDEBUG v3.14-rc5:drivers/base/Makefile:ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG v3.14-rc5:drivers/base/power/Makefile:ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG v3.14-rc5:drivers/bcma/Makefile:ccflags-$(CONFIG_BCMA_DEBUG):= -DDEBUG v3.14-rc5:drivers/dma/Makefile:ccflags-$(CONFIG_DMADEVICES_DEBUG) := -DDEBUG v3.14-rc5:drivers/gpio/Makefile:ccflags-$(CONFIG_DEBUG_GPIO)+= -DDEBUG v3.14-rc5:drivers/gpu/drm/tegra/Makefile:ccflags-$(CONFIG_DRM_TEGRA_DEBUG) += -DDEBUG v3.14-rc5:drivers/hwmon/Makefile:ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG v3.14-rc5:drivers/i2c/Makefile:ccflags-$(CONFIG_I2C_DEBUG_CORE) := -DDEBUG v3.14-rc5:drivers/i2c/algos/Makefile:ccflags-$(CONFIG_I2C_DEBUG_ALGO) := -DDEBUG v3.14-rc5:drivers/i2c/busses/Makefile:ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG v3.14-rc5:drivers/i2c/muxes/Makefile:ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG v3.14-rc5:drivers/infiniband/hw/amso1100/Kbuild:ccflags-$(CONFIG_INFINIBAND_AMSO1100_DEBUG) := -DDEBUG v3.14-rc5:drivers/infiniband/hw/cxgb3/Makefile:ccflags-$(CONFIG_INFINIBAND_CXGB3_DEBUG) += -DDEBUG v3.14-rc5:drivers/media/platform/omap3isp/Makefile:ccflags-$(CONFIG_VIDEO_OMAP3_DEBUG) += -DDEBUG v3.14-rc5:drivers/media/platform/ti-vpe/Makefile:ccflags-$(CONFIG_VIDEO_TI_VPE_DEBUG) += -DDEBUG v3.14-rc5:drivers/memstick/Makefile:subdir-ccflags-$(CONFIG_MEMSTICK_DEBUG) := -DDEBUG v3.14-rc5:drivers/misc/cb710/Makefile:ccflags-$(CONFIG_CB710_DEBUG) := -DDEBUG v3.14-rc5:drivers/misc/sgi-gru/Makefile:ccflags-$(CONFIG_SGI_GRU_DEBUG) := -DDEBUG v3.14-rc5:drivers/mmc/Makefile:subdir-ccflags-$(CONFIG_MMC_DEBUG) := -DDEBUG v3.14-rc5:drivers/net/caif/Makefile:ccflags-$(CONFIG_CAIF_DEBUG) := -DDEBUG v3.14-rc5:drivers/net/can/Makefile:ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG v3.14-rc5:drivers/net/can/c_can/Makefile:ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG v3.14-rc5:drivers/net/can/cc770/Makefile:ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG v3.14-rc5:drivers/net/can/mscan/Makefile:ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG v3.14-rc5:drivers/net/can/sja1000/Makefile:ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG v3.14-rc5:drivers/net/can/softing/Makefile:ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG v3.14-rc5:drivers/net/can/usb/Makefile:ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG v3.14-rc5:drivers/net/ethernet/dec/tulip/Makefile:ccflags-$(CONFIG_NET_TULIP) := -DDEBUG v3.14-rc5:drivers/net/wireless/brcm80211/Makefile:subdir-ccflags-$(CONFIG_BRCMDBG) += -DDEBUG v3.14-rc5:drivers/net/wireless/zd1211rw/Makefile:ccflags-$(CONFIG_ZD1211RW_DEBUG) := -DDEBUG v3.14-rc5:drivers/nfc/Makefile:ccflags-$(CONFIG_NFC_DEBUG) := -DDEBUG v3.14-rc5:drivers/pci/Makefile:ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG v3.14-rc5:drivers/pinctrl/Makefile:ccflags-$(CONFIG_DEBUG_PINCTRL) += -DDEBUG v3.14-rc5:drivers/power/Makefile:ccflags-$(CONFIG_POWER_SUPPLY_DEBUG) := -DDEBUG v3.14-rc5:drivers/pps/Makefile:ccflags-$(CONFIG_PPS_DEBUG) := -DDEBUG v3.14-rc5:drivers/pps/clients/Makefile:ccflags-$(CONFIG_PPS_DEBUG) := -DDEBUG v3.14-rc5:drivers/rapidio/Makefile:subdir-ccflags-$(CONFIG_RAPIDIO_DEBUG) := -DDEBUG v3.14-rc5:drivers/regulator/Makefile:ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG v3.14-rc5:drivers/rtc/Makefile:ccflags-$(CONFIG_RTC_DEBUG) := -DDEBUG v3.14-rc5:drivers/spi/Makefile:ccflags-$(CONFIG_SPI_DEBUG) := -DDEBUG v3.14-rc5:drivers/staging/comedi/Makefile:ccflags-$(CONFIG_COMEDI_DEBUG) := -DDEBUG v3.14-rc5:drivers/staging/comedi/drivers/Makefile:ccflags-$(CONFIG_COMEDI_DEBUG) := -DDEBUG v3.14-rc5:drivers/staging/comedi/kcomedilib/Makefile:ccflags-$(CONFIG_COMEDI_DEBUG) := -DDEBUG v3.14-rc5:drivers/staging/usbip/Makefile:ccflags-$(CONFIG_USBIP_DEBUG) := -DDEBUG v3.14-rc5:drivers/usb/chipidea/Makefile:ccflags-$(CONFIG_USB_CHIPIDEA_DEBUG) := -DDEBUG v3.14-rc5:drivers/usb/dwc2/Makefile:ccflags-$(CONFIG_USB_DWC2_DEBUG)+= -DDEBUG v3.14-rc5:drivers/usb/dwc3/Makefile:ccflags-$(CONFIG_USB_DWC3_DEBUG):= -DDEBUG v3.14-rc5:drivers/usb/gadget/Makefile:ccflags-$(CONFIG_USB_GADGET_DEBUG) := -DDEBUG v3.14-rc5:drivers/usb/wusbcore/Makefile:ccflags-$(CONFIG_USB_WUSB_CBAF_DEBUG) := -DDEBUG
[PATCH] [media] s5p-fimc: Remove reference to outdated macro
The Kconfig symbol S5P_SETUP_MIPIPHY was removed in v3.13. Remove a reference to its macro from a list of Kconfig options. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- See commit e66f233dc7f7 (ARM: Samsung: Remove the MIPI PHY setup code). Should one or more options be added to replace S5P_SETUP_MIPIPHY? I couldn't say. It's safe to remove this one anyway. Documentation/video4linux/fimc.txt | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/Documentation/video4linux/fimc.txt b/Documentation/video4linux/fimc.txt index e51f1b5..7d6e160 100644 --- a/Documentation/video4linux/fimc.txt +++ b/Documentation/video4linux/fimc.txt @@ -151,9 +151,8 @@ CONFIG_S5P_DEV_FIMC1 \ CONFIG_S5P_DEV_FIMC2 |optional CONFIG_S5P_DEV_FIMC3 | CONFIG_S5P_SETUP_FIMC / -CONFIG_S5P_SETUP_MIPIPHY \ -CONFIG_S5P_DEV_CSIS0 | optional for MIPI-CSI interface -CONFIG_S5P_DEV_CSIS1 / +CONFIG_S5P_DEV_CSIS0 \optional for MIPI-CSI interface +CONFIG_S5P_DEV_CSIS1 / Except that, relevant s5p_device_fimc? should be registered in the machine code in addition to a s5p-fimc-md platform device to which the media device driver -- 1.8.5.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] [media] v4l: omap4iss: Add DEBUG compiler flag
Commit d632dfefd36f ([media] v4l: omap4iss: Add support for OMAP4 camera interface - Build system) added a Kconfig entry for VIDEO_OMAP4_DEBUG. But nothing uses that symbol. This entry was apparently copied from a similar entry for OMAP 3 Camera debug messages. The OMAP 3 entry is used to set the DEBUG compiler flag, which enables calls of dev_dbg(). So add a Makefile line to do that for omap4iss too. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- 0) v1 was called [media] v4l: omap4iss: Remove VIDEO_OMAP4_DEBUG. This versions implements Laurent's alternative (which is much better). 1) Still untested. drivers/staging/media/omap4iss/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/staging/media/omap4iss/Makefile b/drivers/staging/media/omap4iss/Makefile index a716ce9..f46c6bd 100644 --- a/drivers/staging/media/omap4iss/Makefile +++ b/drivers/staging/media/omap4iss/Makefile @@ -1,5 +1,7 @@ # Makefile for OMAP4 ISS driver +ccflags-$(CONFIG_VIDEO_OMAP4_DEBUG) += -DDEBUG + omap4-iss-objs += \ iss.o iss_csi2.o iss_csiphy.o iss_ipipeif.o iss_ipipe.o iss_resizer.o iss_video.o -- 1.8.5.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kconfig] update: results of some syntactical checks
Mauro, On Sat, 2013-11-02 at 17:40 -0200, Mauro Carvalho Chehab wrote: Em Sat, 02 Nov 2013 20:20:54 +0100 Paul Bolle pebo...@tiscali.nl escreveu: On Sun, 2013-10-20 at 00:03 +0200, Martin Walch wrote: drivers/media/common/siano/Kconfig:21-26 config SMS_SIANO_DEBUGFS bool Enable debugfs for smsdvb depends on SMS_SIANO_MDTV depends on DEBUG_FS depends on SMS_USB_DRV depends on CONFIG_SMS_USB_DRV = CONFIG_SMS_SDIO_DRV The last line adds the dependency CONFIG_SMS_USB_DRV = CONFIG_SMS_SDIO_DRV. This expression does not look sound as those two symbols are not declared anywhere. So, the two strings CONFIG_SMS_USB_DRV and CONFIG_SMS_SDIO_DRV are compared, yielding always 'n'. As a result, SMS_SIANO_DEBUGFS will never be enabled. [...] The Kconfig logic here is that it should depends on !SMS_SDIO_DRV or SMS_USB_DRV = SMS_SDIO_DRV. I remember I made a patch like that while testing some things with this driver, but it seems that I forgot to push. I might have it somewhere on my test machine. This line is still present in v3.14-rc2. Did you ever find that patch on your test machine? Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] v4l: omap4iss: Remove VIDEO_OMAP4_DEBUG
Laurent, On Mon, 2014-02-10 at 15:13 +0100, Laurent Pinchart wrote: On Sunday 09 February 2014 16:09:37 Paul Bolle wrote: Commit d632dfefd36f ([media] v4l: omap4iss: Add support for OMAP4 camera interface - Build system) added a Kconfig entry for VIDEO_OMAP4_DEBUG. But nothing uses that symbol. This entry was apparently copied from a similar entry for OMAP 3 Camera debug messages. But a corresponding Makefile line is missing. Besides, the debug code also depends on a mysterious ISS_ISR_DEBUG macro. This Kconfig entry can be removed. What about adding the associated Makefile line instead to #define DEBUG when VIDEO_OMAP4_DEBUG is selected, as with the OMAP3 ISP driver ? Someone familiar with the code might be able to say what to do with the code depending on the DEBUG and ISS_ISR_DEBUG macros. ISS_ISR_DEBUG is expected to be set by manually modifying the source code, as it prints lots of messages in interrupt context. Which renders the DEBUG macro pointless. Or does the code use some dev_dbg()-like magic, which is only triggered if the DEBUG macro is set? Thanks, Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] v4l: omap4iss: Remove VIDEO_OMAP4_DEBUG
Commit d632dfefd36f ([media] v4l: omap4iss: Add support for OMAP4 camera interface - Build system) added a Kconfig entry for VIDEO_OMAP4_DEBUG. But nothing uses that symbol. This entry was apparently copied from a similar entry for OMAP 3 Camera debug messages. But a corresponding Makefile line is missing. Besides, the debug code also depends on a mysterious ISS_ISR_DEBUG macro. This Kconfig entry can be removed. Someone familiar with the code might be able to say what to do with the code depending on the DEBUG and ISS_ISR_DEBUG macros. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Untested. drivers/staging/media/omap4iss/Kconfig | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/staging/media/omap4iss/Kconfig b/drivers/staging/media/omap4iss/Kconfig index b9fe753..78b0fba 100644 --- a/drivers/staging/media/omap4iss/Kconfig +++ b/drivers/staging/media/omap4iss/Kconfig @@ -4,9 +4,3 @@ config VIDEO_OMAP4 select VIDEOBUF2_DMA_CONTIG ---help--- Driver for an OMAP 4 ISS controller. - -config VIDEO_OMAP4_DEBUG - bool OMAP 4 Camera debug messages - depends on VIDEO_OMAP4 - ---help--- - Enable debug messages on OMAP 4 ISS controller driver. -- 1.8.5.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] si4713: Remove select SI4713
Commits 7391232e1215 ([media] si4713: Reorganized drivers/media/radio directory) and b874b39fcd2f ([media] si4713: Added the USB driver for Si4713) both added a select SI4713. But there's no Kconfig symbol SI4713, so these selects are nops. It's not clear why they were added but it's safe to remove them anyway. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Untested! drivers/media/radio/si4713/Kconfig | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/media/radio/si4713/Kconfig b/drivers/media/radio/si4713/Kconfig index a7c3ba8..ed51ed0 100644 --- a/drivers/media/radio/si4713/Kconfig +++ b/drivers/media/radio/si4713/Kconfig @@ -1,7 +1,6 @@ config USB_SI4713 tristate Silicon Labs Si4713 FM Radio Transmitter support with USB depends on USB RADIO_SI4713 - select SI4713 ---help--- This is a driver for USB devices with the Silicon Labs SI4713 chip. Currently these devices are known to work. @@ -16,7 +15,6 @@ config USB_SI4713 config PLATFORM_SI4713 tristate Silicon Labs Si4713 FM Radio Transmitter support with I2C depends on I2C RADIO_SI4713 - select SI4713 ---help--- This is a driver for I2C devices with the Silicon Labs SI4713 chip. -- 1.8.5.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] si4713: Remove select SI4713
Hans, On Sun, 2014-02-09 at 16:18 +0100, Hans Verkuil wrote: USB_SI4713 and PLATFORM_SI4713 both depend on I2C_SI4713. So the select should be I2C_SI4713. Are you sure? I've actually scanned si4713.c before submitting this patch and I couldn't find anything in it that these other two modules require. Have I overlooked anything? If you can post a patch fixing that, then I'll pick it up for 3.14. With the addition of the USB si4713 driver things moved around and were renamed, and these selects were missed. Thanks, Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] si4713: Remove select SI4713
On Sun, 2014-02-09 at 18:04 +0100, Hans Verkuil wrote: The i2c module is loaded by v4l2_i2c_new_subdev_board(). I see. Thanks. But now I wonder: is I2C_SI4713 useful on itself? Would anyone use si4713.ko without using either radio-usb-si4713.ko or radio-platform-si4713.ko? Because it seems that if what people actually use is radio-usb-si4713.ko or radio-platform-si4713.ko than I2C_SI4713 could be made a 'select only' Kconfig symbol (that won't show up in menuconfig), couldn't it? Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kconfig] update: results of some syntactical checks
On Sun, 2013-10-20 at 00:03 +0200, Martin Walch wrote: drivers/media/common/siano/Kconfig:21-26 config SMS_SIANO_DEBUGFS bool Enable debugfs for smsdvb depends on SMS_SIANO_MDTV depends on DEBUG_FS depends on SMS_USB_DRV depends on CONFIG_SMS_USB_DRV = CONFIG_SMS_SDIO_DRV The last line adds the dependency CONFIG_SMS_USB_DRV = CONFIG_SMS_SDIO_DRV. This expression does not look sound as those two symbols are not declared anywhere. So, the two strings CONFIG_SMS_USB_DRV and CONFIG_SMS_SDIO_DRV are compared, yielding always 'n'. As a result, SMS_SIANO_DEBUGFS will never be enabled. Those are obvious typos. Still present in v3.12-rc7. Perhaps you'd like to send the trivial patch to fix this? Probably, it was meant to say something like depends on SMS_USB_DRV = SMS_SDIO_DRV Two other config sections that probably behave differently than expected: drivers/staging/rtl8188eu/Kconfig: 13-15 config 88EU_AP_MODE bool Realtek RTL8188EU AP mode default Y drivers/staging/rtl8188eu/Kconfig: 21-23 config 88EU_P2P bool Realtek RTL8188EU Peer-to-peer mode default Y The capital Y is different from the lowercase y. While y is an actually hard coded constant symbol, Y is undeclared and evaluates to n. The default values are probably only for convenience, so 88EU_AP_MODE and 88EU_P2P are activated together with 8188EU. They still can be turned off. Anyway, it should probably say default y in both cases. Ditto. Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kconfig] update: results of some syntactical checks
On Sat, 2013-11-02 at 17:40 -0200, Mauro Carvalho Chehab wrote: Em Sat, 02 Nov 2013 20:20:54 +0100 Paul Bolle pebo...@tiscali.nl escreveu: Those are obvious typos. Still present in v3.12-rc7. Perhaps you'd like to send the trivial patch to fix this? Yes, it is a typo... Probably, it was meant to say something like depends on SMS_USB_DRV = SMS_SDIO_DRV But this is not the right thing to do. The Kconfig logic here is that it should depends on !SMS_SDIO_DRV or SMS_USB_DRV = SMS_SDIO_DRV. For the record: my reason for suggesting to Martin to send patches is that sending a (trivial) patch often turns out to be a quick way to get issues like that resolved. Maintainers seem to react quite quickly on patches. Perhaps even faster if a patch is not solving the issue at hand entirely correct! Messages like Martin's, that basically state that there are one or more tree-wide problems, seem to be overlooked easily. I remember I made a patch like that while testing some things with this driver, but it seems that I forgot to push. I might have it somewhere on my test machine. Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v3] media: davinci: kconfig: fix incorrect selects
On Tue, 2013-03-12 at 09:14 +, Sekhar Nori wrote: drivers/media/platform/davinci/Kconfig uses selects where it should be using 'depends on'. This results in warnings of the following sort when doing randconfig builds. warning: (VIDEO_DM6446_CCDC VIDEO_DM355_CCDC VIDEO_ISIF VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT V4L_PLATFORM_DRIVERS ARCH_DAVINCI) The VPIF kconfigs had a strange 'select' and 'depends on' cross linkage which have been fixed as well by removing unneeded VIDEO_DAVINCI_VPIF config symbol. Similarly, remove the unnecessary VIDEO_VPSS_SYSTEM and VIDEO_VPFE_CAPTURE. They don't select any independent functionality and were being used to manage code dependencies which can be handled using makefile. Selecting video modules is now dependent on all ARCH_DAVINCI instead of specific EVMs and SoCs earlier. This should help build coverage. Remove unnecessary 'default y' for some config symbols. While at it, fix the Kconfig help text to make it more readable and fix names of modules created during module build. Rename VIDEO_ISIF to VIDEO_DM365_ISIF as per suggestion from Prabhakar. This patch has only been build tested; I have tried to not break any existing assumptions. I do not have the setup to test video, so any test reports welcome. Reported-by: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Sekhar Nori nsek...@ti.com Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com This seems to be the patch that ended up as mainline commit 3778d05036cc7ddd983ae2451da579af00acdac2 (which was included in v3.10-rc1). After that commit there's still one reference to VIDEO_VPFE_CAPTURE in the tree: as a (negative) dependency in drivers/staging/media/davinci_vpfe/Kconfig. Can that (negative) dependency now be dropped (as it's currently useless) or should it be replaced with a (negative) dependency on a related symbol? Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v3] media: davinci: kconfig: fix incorrect selects
Prabhakar, On Mon, 2013-05-13 at 15:27 +0530, Prabhakar Lad wrote: Good catch! the dependency can be dropped now. Great. Are you planning to post a patch for it or shall I do it ? I don't mind submitting that trivial patch. However, it's probably better if you do that. I can only state that this dependency is now useless, because that is simply how the kconfig system works. But you can probably elaborate why it's OK to not replace it with another (negative) dependency. That would make a more informative commit explanation. Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] [media] soc-camera: remove two unused configs
The last users of Kconfig symbols MX3_VIDEO and VIDEO_MX2_HOSTSUPPORT were removed in v3.2. Their Kconfig entries can be removed now. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- v1 was called [...] remove config MX3_VIDEO. But it turned out that v3.2, through commit 389d12cc7f (ARM: mxc: Remove setting of consistent dma size), also removed the last user of VIDEO_MX2_HOSTSUPPORT. Still tested with git grep only. drivers/media/platform/soc_camera/Kconfig | 8 1 file changed, 8 deletions(-) diff --git a/drivers/media/platform/soc_camera/Kconfig b/drivers/media/platform/soc_camera/Kconfig index b139b52..ffd0010 100644 --- a/drivers/media/platform/soc_camera/Kconfig +++ b/drivers/media/platform/soc_camera/Kconfig @@ -27,14 +27,10 @@ config VIDEO_MX1 ---help--- This is a v4l2 driver for the i.MX1/i.MXL CMOS Sensor Interface -config MX3_VIDEO - bool - config VIDEO_MX3 tristate i.MX3x Camera Sensor Interface driver depends on VIDEO_DEV MX3_IPU SOC_CAMERA select VIDEOBUF2_DMA_CONTIG - select MX3_VIDEO ---help--- This is a v4l2 driver for the i.MX3x Camera Sensor Interface @@ -66,14 +62,10 @@ config VIDEO_OMAP1 ---help--- This is a v4l2 driver for the TI OMAP1 camera interface -config VIDEO_MX2_HOSTSUPPORT - bool - config VIDEO_MX2 tristate i.MX27 Camera Sensor Interface driver depends on VIDEO_DEV SOC_CAMERA MACH_MX27 select VIDEOBUF2_DMA_CONTIG - select VIDEO_MX2_HOSTSUPPORT ---help--- This is a v4l2 driver for the i.MX27 Camera Sensor Interface -- 1.7.11.7 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] soc-camera: remove config MX3_VIDEO
The last user of Kconfig symbol MX3_VIDEO was removed in v3.2. Its Kconfig entry can be removed now. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Tested with git grep. drivers/media/platform/soc_camera/Kconfig | 4 1 file changed, 4 deletions(-) diff --git a/drivers/media/platform/soc_camera/Kconfig b/drivers/media/platform/soc_camera/Kconfig index b139b52..f73057a 100644 --- a/drivers/media/platform/soc_camera/Kconfig +++ b/drivers/media/platform/soc_camera/Kconfig @@ -27,14 +27,10 @@ config VIDEO_MX1 ---help--- This is a v4l2 driver for the i.MX1/i.MXL CMOS Sensor Interface -config MX3_VIDEO - bool - config VIDEO_MX3 tristate i.MX3x Camera Sensor Interface driver depends on VIDEO_DEV MX3_IPU SOC_CAMERA select VIDEOBUF2_DMA_CONTIG - select MX3_VIDEO ---help--- This is a v4l2 driver for the i.MX3x Camera Sensor Interface -- 1.7.11.7 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] gspca: remove obsolete Kconfig macros
The et61x251 driver was removed in v3.5. Remove the last references to
its Kconfig macro now.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Untested, as usual.
drivers/media/usb/gspca/etoms.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/media/usb/gspca/etoms.c b/drivers/media/usb/gspca/etoms.c
index 38f68e1..f165581 100644
--- a/drivers/media/usb/gspca/etoms.c
+++ b/drivers/media/usb/gspca/etoms.c
@@ -768,9 +768,7 @@ static const struct sd_desc sd_desc = {
/* -- module initialisation -- */
static const struct usb_device_id device_table[] = {
{USB_DEVICE(0x102c, 0x6151), .driver_info = SENSOR_PAS106},
-#if !defined CONFIG_USB_ET61X251 !defined CONFIG_USB_ET61X251_MODULE
{USB_DEVICE(0x102c, 0x6251), .driver_info = SENSOR_TAS5130CXX},
-#endif
{}
};
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] staging: lirc: remove dead code
lirc uses the CONFIG_SA1100_BITSY Kconfig macro. But its Kconfig symbol
was removed in v2.4.13. So we can remove a few lines of dead code.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Untested, but of rather low risk. Note that support for the
machine_is_bitsy() macro was already removed in v2.4.10.
drivers/staging/media/lirc/lirc_sir.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/staging/media/lirc/lirc_sir.c
b/drivers/staging/media/lirc/lirc_sir.c
index 63a554c..f781c53 100644
--- a/drivers/staging/media/lirc/lirc_sir.c
+++ b/drivers/staging/media/lirc/lirc_sir.c
@@ -787,12 +787,6 @@ static int init_hardware(void)
spin_lock_irqsave(hardware_lock, flags);
/* reset UART */
#ifdef LIRC_ON_SA1100
-#ifdef CONFIG_SA1100_BITSY
- if (machine_is_bitsy()) {
- pr_info(Power on IR module\n);
- set_bitsy_egpio(EGPIO_BITSY_IR_ON);
- }
-#endif
#ifdef CONFIG_SA1100_COLLIE
sa1100_irda_set_power_collie(3);/* power on */
#endif
@@ -942,10 +936,6 @@ static void drop_hardware(void)
Ser2UTCR3 = sr.utcr3;
Ser2HSCR0 = sr.hscr0;
-#ifdef CONFIG_SA1100_BITSY
- if (machine_is_bitsy())
- clr_bitsy_egpio(EGPIO_BITSY_IR_ON);
-#endif
#ifdef CONFIG_SA1100_COLLIE
sa1100_irda_set_power_collie(0);/* power off */
#endif
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: lirc: remove dead code
On Mon, 2013-03-25 at 13:40 +0400, Denis Kirjanov wrote: Just found that the exactly the same patch has been posted a while ago: http://driverdev.linuxdriverproject.org/pipermail/devel/2012-November/033623.html Thanks for that. Is that previous patch queued somewhere? Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] ts2020: use customise option correctly
The Kconfig entry for TS2020 based tuners defaults to modular if DVB_FE_CUSTOMISE is set. But that Kconfig symbol was replaced with MEDIA_SUBDRV_AUTOSELECT as of v3.7. So use the new symbol. And negate the logic, so we are in line with all the similar entries in this file. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Entirely untested. drivers/media/dvb-frontends/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/dvb-frontends/Kconfig b/drivers/media/dvb-frontends/Kconfig index 6f809a7..0e2ec6f 100644 --- a/drivers/media/dvb-frontends/Kconfig +++ b/drivers/media/dvb-frontends/Kconfig @@ -210,7 +210,7 @@ config DVB_SI21XX config DVB_TS2020 tristate Montage Tehnology TS2020 based tuners depends on DVB_CORE I2C - default m if DVB_FE_CUSTOMISE + default m if !MEDIA_SUBDRV_AUTOSELECT help A DVB-S/S2 silicon tuner. Say Y when you want to support this tuner. -- 1.7.11.7 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] soc_camera: remove two outdated selects
Release v2.6.30 removed the MT9M001_PCA9536_SWITCH and MT9V022_PCA9536_SWITCH Kconfig symbols, in commits 36034dc325ecab63c8cfb992fbf9a1a8e94738a2 (V4L/DVB (11032): mt9m001: allow setting of bus width from board code) and e958e27adeade7fa085dd396a8a0dfaef7e338c1 (V4L/DVB (11033): mt9v022: allow setting of bus width from board code). These two commits removed all gpio related code from these two drivers. But they skipped removing their two selects of GPIO_PCA953X. Remove these now as they are outdated. Their dependencies can never evaluate to true anyhow. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Tested by grepping the tree. drivers/media/i2c/soc_camera/Kconfig | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/media/i2c/soc_camera/Kconfig b/drivers/media/i2c/soc_camera/Kconfig index 6dff2b7..23d352f 100644 --- a/drivers/media/i2c/soc_camera/Kconfig +++ b/drivers/media/i2c/soc_camera/Kconfig @@ -9,7 +9,6 @@ config SOC_CAMERA_IMX074 config SOC_CAMERA_MT9M001 tristate mt9m001 support depends on SOC_CAMERA I2C - select GPIO_PCA953X if MT9M001_PCA9536_SWITCH help This driver supports MT9M001 cameras from Micron, monochrome and colour models. @@ -36,7 +35,6 @@ config SOC_CAMERA_MT9T112 config SOC_CAMERA_MT9V022 tristate mt9v022 and mt9v024 support depends on SOC_CAMERA I2C - select GPIO_PCA953X if MT9V022_PCA9536_SWITCH help This driver supports MT9V022 cameras from Micron -- 1.7.11.7 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] m920x: let GCC see 'ret' is used initialized
Since commit 7543f344e9b06afe86b55a2620f5c11b38bd5642 ([media] m920x:
factor out a m920x_write_seq() function) building m920x.o triggers this
GCC warning:
drivers/media/usb/dvb-usb/m920x.c: In function ‘m920x_probe’:
drivers/media/usb/dvb-usb/m920x.c:91:6: warning: ‘ret’ may be used
uninitialized in this function [-Wuninitialized]
This warning is caused by m920x_write_seq(), which is apparently inlined
into m920x_probe(). It is clear why GCC thinks 'ret' may be used
uninitialized. But in practice the first seq-address will always be
non-zero when this function is called. That means we can change the
while()-do{} loop into a do{}-while() loop. And that suffices to make
GCC see that 'ret' will not be used uninitialized.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Compile tested only!
drivers/media/usb/dvb-usb/m920x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/m920x.c
b/drivers/media/usb/dvb-usb/m920x.c
index 92afeb2..79b31ae 100644
--- a/drivers/media/usb/dvb-usb/m920x.c
+++ b/drivers/media/usb/dvb-usb/m920x.c
@@ -68,13 +68,13 @@ static inline int m920x_write_seq(struct usb_device *udev,
u8 request,
struct m920x_inits *seq)
{
int ret;
- while (seq-address) {
+ do {
ret = m920x_write(udev, request, seq-data, seq-address);
if (ret != 0)
return ret;
seq++;
- }
+ } while (seq-address);
return ret;
}
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] saa7164: silence GCC warnings
Compiling the saa7164 driver without CONFIG_VIDEO_ADV_DEBUG set triggers
these GCC warnings:
drivers/media/pci/saa7164/saa7164-encoder.c:1301:12: warning:
‘saa7164_g_register’ defined but not used [-Wunused-function]
drivers/media/pci/saa7164/saa7164-encoder.c:1314:12: warning:
‘saa7164_s_register’ defined but not used [-Wunused-function]
Silence these warnings by wrapping these two functions in an #ifdef
CONFIG_VIDEO_ADV_DEBUG and #endif pair.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
0) Compile tested only.
1) These warnings are apparently a side effect of commit
5faf7db804e1e67ab8f78edb305d1858779a6279 ([media] saa7164: get rid of
warning: no previous prototype): now that these two functions are
static GCC can determine that they are unused in this case.
drivers/media/pci/saa7164/saa7164-encoder.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/pci/saa7164/saa7164-encoder.c
b/drivers/media/pci/saa7164/saa7164-encoder.c
index 994018e..9bb0903 100644
--- a/drivers/media/pci/saa7164/saa7164-encoder.c
+++ b/drivers/media/pci/saa7164/saa7164-encoder.c
@@ -1298,6 +1298,7 @@ static int saa7164_g_chip_ident(struct file *file, void
*fh,
return 0;
}
+#ifdef CONFIG_VIDEO_ADV_DEBUG
static int saa7164_g_register(struct file *file, void *fh,
struct v4l2_dbg_register *reg)
{
@@ -1323,6 +1324,7 @@ static int saa7164_s_register(struct file *file, void *fh,
return 0;
}
+#endif
static const struct v4l2_ioctl_ops mpeg_ioctl_ops = {
.vidioc_s_std= vidioc_s_std,
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] budget-av: only use t_state if initialized
Building budget-av.o triggers this GCC warning: In file included from drivers/media/pci/ttpci/budget-av.c:44:0: drivers/media/dvb-frontends/tda8261_cfg.h: In function ‘tda8261_get_bandwidth’: drivers/media/dvb-frontends/tda8261_cfg.h:68:21: warning: ‘t_state.bandwidth’ may be used uninitialized in this function [-Wuninitialized] Move the printk() that uses t_state.bandwith to the location where it should be initialized to fix this. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- 0) Compile tested only. 1) By the way, the first two if()-tests in tda8261_get_bandwidth() should be superfluous. And the first two if()-tests in both tda8261_get_frequency() and tda8261_set_frequency() look bogus to me, as they should always succeed. If that's correct, there are some cleanups possible in this header. drivers/media/dvb-frontends/tda8261_cfg.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/dvb-frontends/tda8261_cfg.h b/drivers/media/dvb-frontends/tda8261_cfg.h index 1af1ee4..4671074 100644 --- a/drivers/media/dvb-frontends/tda8261_cfg.h +++ b/drivers/media/dvb-frontends/tda8261_cfg.h @@ -78,7 +78,7 @@ static int tda8261_get_bandwidth(struct dvb_frontend *fe, u32 *bandwidth) return err; } *bandwidth = t_state.bandwidth; + printk(%s: Bandwidth=%d\n, __func__, t_state.bandwidth); } - printk(%s: Bandwidth=%d\n, __func__, t_state.bandwidth); return 0; } -- 1.7.11.7 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] tda18212: tda18218: use 'val' if initialized
Commits e666a44fa313cb9329c0381ad02fc6ee1e21cb31 ([media] tda18212:
silence compiler warning) and e0e52d4e9f5bce7ea887027c127473eb654a5a04
([media] tda18218: silence compiler warning) silenced warnings
equivalent to these:
drivers/media/tuners/tda18212.c: In function ‘tda18212_attach’:
drivers/media/tuners/tda18212.c:299:2: warning: ‘val’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
drivers/media/tuners/tda18218.c: In function ‘tda18218_attach’:
drivers/media/tuners/tda18218.c:305:2: warning: ‘val’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
But in both cases 'val' will still be used uninitialized if the calls
of tda18212_rd_reg() or tda18218_rd_reg() fail. Fix this by only
printing the chip id if the calls of those functions were successful.
This allows to drop the uninitialized_var() stopgap measure.
Also stop printing the return values of tda18212_rd_reg() or
tda18218_rd_reg(), as these are not interesting.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
0) Compile tested only.
drivers/media/tuners/tda18212.c | 6 +++---
drivers/media/tuners/tda18218.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/media/tuners/tda18212.c b/drivers/media/tuners/tda18212.c
index 5d9f028..e4a84ee 100644
--- a/drivers/media/tuners/tda18212.c
+++ b/drivers/media/tuners/tda18212.c
@@ -277,7 +277,7 @@ struct dvb_frontend *tda18212_attach(struct dvb_frontend
*fe,
{
struct tda18212_priv *priv = NULL;
int ret;
- u8 uninitialized_var(val);
+ u8 val;
priv = kzalloc(sizeof(struct tda18212_priv), GFP_KERNEL);
if (priv == NULL)
@@ -296,8 +296,8 @@ struct dvb_frontend *tda18212_attach(struct dvb_frontend
*fe,
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 0); /* close I2C-gate */
- dev_dbg(priv-i2c-dev, %s: ret=%d chip id=%02x\n, __func__, ret,
- val);
+ if (!ret)
+ dev_dbg(priv-i2c-dev, %s: chip id=%02x\n, __func__, val);
if (ret || val != 0xc7) {
kfree(priv);
return NULL;
diff --git a/drivers/media/tuners/tda18218.c b/drivers/media/tuners/tda18218.c
index 1819853..2d31aeb 100644
--- a/drivers/media/tuners/tda18218.c
+++ b/drivers/media/tuners/tda18218.c
@@ -277,7 +277,7 @@ struct dvb_frontend *tda18218_attach(struct dvb_frontend
*fe,
struct i2c_adapter *i2c, struct tda18218_config *cfg)
{
struct tda18218_priv *priv = NULL;
- u8 uninitialized_var(val);
+ u8 val;
int ret;
/* chip default registers values */
static u8 def_regs[] = {
@@ -302,8 +302,8 @@ struct dvb_frontend *tda18218_attach(struct dvb_frontend
*fe,
/* check if the tuner is there */
ret = tda18218_rd_reg(priv, R00_ID, val);
- dev_dbg(priv-i2c-dev, %s: ret=%d chip id=%02x\n, __func__, ret,
- val);
+ if (!ret)
+ dev_dbg(priv-i2c-dev, %s: chip id=%02x\n, __func__, val);
if (ret || val != def_regs[R00_ID]) {
kfree(priv);
return NULL;
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] staging: lirc_serial: silence GCC warning
Building lirc_serial.o triggers this GCC warning: drivers/staging/media/lirc/lirc_serial.c: In function '__check_sense': drivers/staging/media/lirc/lirc_serial.c:1301:1: warning: return from incompatible pointer type [enabled by default] This can be trivially fixed by changing the 'sense' parameter from bool to int. But, to be safe, we also need to make sure 'sense' will only be -1, 0, or 1. There's no need to document the new values that are now allowed for the 'sense' parameter, since they're basically useless. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- 0) This warning popped up when building v3.6.2 using Fedora 17's default config (in which, for some reason, the LIRC drivers were enabled going from v3.5.y to v3.6.y). 1) Compile tested only. drivers/staging/media/lirc/lirc_serial.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/staging/media/lirc/lirc_serial.c b/drivers/staging/media/lirc/lirc_serial.c index 97ef670..08cfaf6 100644 --- a/drivers/staging/media/lirc/lirc_serial.c +++ b/drivers/staging/media/lirc/lirc_serial.c @@ -1239,6 +1239,10 @@ static int __init lirc_serial_init_module(void) } } + /* make sure sense is either -1, 0, or 1 */ + if (sense != -1) + sense = !!sense; + result = lirc_serial_init(); if (result) return result; @@ -1298,7 +1302,7 @@ MODULE_PARM_DESC(irq, Interrupt (4 or 3)); module_param(share_irq, bool, S_IRUGO); MODULE_PARM_DESC(share_irq, Share interrupts (0 = off, 1 = on)); -module_param(sense, bool, S_IRUGO); +module_param(sense, int, S_IRUGO); MODULE_PARM_DESC(sense, Override autodetection of IR receiver circuit (0 = active high, 1 = active low )); -- 1.7.11.7 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] stradis: remove unused V4L1 headers
Commit 39c3d488452ae206cfc8afda0db041ee55d01c3c ([media] cpia, stradis:
remove deprecated V4L1 drivers) removed the last file including these
five headers. Apparently it was just an oversight to keep them in the
tree. They can safely be removed now.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
0) Tested only by using various git commands on the (history of the)
tree.
1) Note that I haven't checked whether the things these headers provide
might still be used in the tree. Since no file includes these files
anymore, that should have caused compilation errors by now, so checking
for that seems rather pointless.
2) Also note that there are two other headers called saa7146.h:
- include/media/saa7146.h; and
- sound/pci/aw2/saa7146.h.
Those should be the headers that are included by:
- drivers/media/common/saa7146_core.c,
drivers/media/dvb/ttpci/budget.h,
include/media/saa7146_vv.h; and
- sound/pci/aw2/aw2-alsa.c,
sound/pci/aw2/aw2-saa7146.c.
So the saa7146.h header that this patch removes shouldn't break
compilation of those files. Perhaps the maintains would like that to be
actually tested. Can the drivers that use those files be compiled for
x86?
drivers/media/video/cs8420.h | 50 ---
drivers/media/video/ibmmpeg2.h | 94 -
drivers/media/video/saa7121.h| 132 --
drivers/media/video/saa7146.h| 112 ---
drivers/media/video/saa7146reg.h | 283 --
5 files changed, 0 insertions(+), 671 deletions(-)
delete mode 100644 drivers/media/video/cs8420.h
delete mode 100644 drivers/media/video/ibmmpeg2.h
delete mode 100644 drivers/media/video/saa7121.h
delete mode 100644 drivers/media/video/saa7146.h
delete mode 100644 drivers/media/video/saa7146reg.h
diff --git a/drivers/media/video/cs8420.h b/drivers/media/video/cs8420.h
deleted file mode 100644
index 621c0c6..000
--- a/drivers/media/video/cs8420.h
+++ /dev/null
@@ -1,50 +0,0 @@
-/* cs8420.h - cs8420 initializations
- Copyright (C) 1999 Nathan Laredo (lar...@gnu.org)
-
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or
- (at your option) any later version.
-
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
-
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the Free Software
- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-
- */
-#ifndef __CS8420_H__
-#define __CS8420_H__
-
-/* Initialization Sequence */
-
-static __u8 init8420[] = {
- 1, 0x01,2, 0x02,3, 0x00,4, 0x46,
- 5, 0x24,6, 0x84,18, 0x18, 19, 0x13,
-};
-
-#define INIT8420LEN(sizeof(init8420)/2)
-
-static __u8 mode8420pro[] = { /* professional output mode */
- 32, 0xa1, 33, 0x00, 34, 0x00, 35, 0x00,
- 36, 0x00, 37, 0x00, 38, 0x00, 39, 0x00,
- 40, 0x00, 41, 0x00, 42, 0x00, 43, 0x00,
- 44, 0x00, 45, 0x00, 46, 0x00, 47, 0x00,
- 48, 0x00, 49, 0x00, 50, 0x00, 51, 0x00,
- 52, 0x00, 53, 0x00, 54, 0x00, 55, 0x00,
-};
-#define MODE8420LEN(sizeof(mode8420pro)/2)
-
-static __u8 mode8420con[] = { /* consumer output mode */
- 32, 0x20, 33, 0x00, 34, 0x00, 35, 0x48,
- 36, 0x00, 37, 0x00, 38, 0x00, 39, 0x00,
- 40, 0x00, 41, 0x00, 42, 0x00, 43, 0x00,
- 44, 0x00, 45, 0x00, 46, 0x00, 47, 0x00,
- 48, 0x00, 49, 0x00, 50, 0x00, 51, 0x00,
- 52, 0x00, 53, 0x00, 54, 0x00, 55, 0x00,
-};
-
-#endif
diff --git a/drivers/media/video/ibmmpeg2.h b/drivers/media/video/ibmmpeg2.h
deleted file mode 100644
index 68e1038..000
--- a/drivers/media/video/ibmmpeg2.h
+++ /dev/null
@@ -1,94 +0,0 @@
-/* ibmmpeg2.h - IBM MPEGCD21 definitions */
-
-#ifndef __IBM_MPEG2__
-#define __IBM_MPEG2__
-
-/* Define all MPEG Decoder registers */
-/* Chip Control and Status */
-#define IBM_MP2_CHIP_CONTROL 0x200*2
-#define IBM_MP2_CHIP_MODE 0x201*2
-/* Timer Control and Status */
-#define IBM_MP2_SYNC_STC2 0x202*2
-#define IBM_MP2_SYNC_STC1 0x203*2
-#define IBM_MP2_SYNC_STC0 0x204*2
-#define IBM_MP2_SYNC_PTS2 0x205*2
-#define IBM_MP2_SYNC_PTS1 0x206*2
-#define IBM_MP2_SYNC_PTS0 0x207*2
-/* Video FIFO Control */
-#define IBM_MP2_FIFO 0x208*2
-#define IBM_MP2_FIFOW 0x100*2
-#define IBM_MP2_FIFO_STAT 0x209*2
-#define IBM_MP2_RB_THRESHOLD 0x22b*2
-/* Command buffer */
-#define
[PATCH] [media] Fix typos in VIDEO_CX231XX_DVB Kconfig entry
Commit ede676c72d ([...] add digital support for PV SBTVD hybrid) added select MEDIA_TUNER_NXP18271 to the VIDEO_CX231XX_DVB Kconfig entry. But there's no Kconfig symbol MEDIA_TUNER_NXP18271. That should have been MEDIA_TUNER_TDA18271. (The code added in that commit uses tda18271_attach, which is only available if MEDIA_TUNER_TDA18271 is set.) The selects of MEDIA_TUNER_XC5000 and MEDIA_TUNER_TDA18271 should only be done if MEDIA_TUNER_CUSTOMISE isn't set. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- 0) git grep tested only. The second statement is pure bluff: I'm not familiar with the usage of DVB_FE_CUSTOMISE and MEDIA_TUNER_CUSTOMISE. I only noticed that these two lines looked odd when compared to all similar lines in drivers/media. 1) Apparently no one noticed because no one build with settings that could trigger a problem (ie, both MEDIA_TUNER_TDA18271 and MEDIA_TUNER_CUSTOMISE not set). drivers/media/video/cx231xx/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/cx231xx/Kconfig b/drivers/media/video/cx231xx/Kconfig index ae85a7a..c74ce9e 100644 --- a/drivers/media/video/cx231xx/Kconfig +++ b/drivers/media/video/cx231xx/Kconfig @@ -42,8 +42,8 @@ config VIDEO_CX231XX_DVB tristate DVB/ATSC Support for Cx231xx based TV cards depends on VIDEO_CX231XX DVB_CORE select VIDEOBUF_DVB - select MEDIA_TUNER_XC5000 if !DVB_FE_CUSTOMISE - select MEDIA_TUNER_NXP18271 if !DVB_FE_CUSTOMISE + select MEDIA_TUNER_XC5000 if !MEDIA_TUNER_CUSTOMISE + select MEDIA_TUNER_TDA18271 if !MEDIA_TUNER_CUSTOMISE select DVB_MB86A20S if !DVB_FE_CUSTOMISE ---help--- -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [RESEND] media: tea5764: reconcile Kconfig symbol and macro
The Kconfig symbol RADIO_TEA5764_XTAL is unused. The code does use a
RADIO_TEA5764_XTAL macro, but does that rather peculiar. But there seems
to be a way to keep both. (The easiest way out would be to rip out both
the Kconfig symbol and the macro.)
Note there's also a module parameter 'use_xtal' to influence all this.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
I didn't dare to submit this a trivial patch. This is still untested. By
the way, is xtal a common abbreviation of crystal?
drivers/media/radio/radio-tea5764.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/media/radio/radio-tea5764.c
b/drivers/media/radio/radio-tea5764.c
index 95ddcc4..db20904 100644
--- a/drivers/media/radio/radio-tea5764.c
+++ b/drivers/media/radio/radio-tea5764.c
@@ -128,8 +128,10 @@ struct tea5764_write_regs {
u16 rdsbbl; /* PAUSEDET RDSBBL */
} __attribute__ ((packed));
-#ifndef RADIO_TEA5764_XTAL
+#ifdef CONFIG_RADIO_TEA5764_XTAL
#define RADIO_TEA5764_XTAL 1
+#else
+#define RADIO_TEA5764_XTAL 0
#endif
static int radio_nr = -1;
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RESEND] media: tea5764: reconcile Kconfig symbol and macro
On Sun, 2011-10-30 at 09:43 -0700, Randy Dunlap wrote: On 10/30/11 05:08, Paul Bolle wrote: The Kconfig symbol RADIO_TEA5764_XTAL is unused. The code does use a RADIO_TEA5764_XTAL macro, but does that rather peculiar. But there seems to be a way to keep both. (The easiest way out would be to rip out both the Kconfig symbol and the macro.) Note there's also a module parameter 'use_xtal' to influence all this. It's curious that the module parameter is only available when the driver is builtin (=y) but not built as a loadable module (=m): As far as I can see the module parameter is available in both cases but defaults to different values when builtin and when loadable. config RADIO_TEA5764_XTAL bool TEA5764 crystal reference depends on RADIO_TEA5764=y default y 0) I've noticed similar dependencies (while doing some other Kconfig related clean up) with a number of other config entries in that same Kconfig file: $ git grep -n depends on.*=y drivers/media/radio/ drivers/media/radio/Kconfig:60: depends on RADIO_RTRACK=y drivers/media/radio/Kconfig:83: depends on RADIO_RTRACK2=y drivers/media/radio/Kconfig:106:depends on RADIO_AZTECH=y drivers/media/radio/Kconfig:135:depends on RADIO_GEMTEK=y drivers/media/radio/Kconfig:147:depends on RADIO_GEMTEK=y drivers/media/radio/Kconfig:239:depends on RADIO_TERRATEC=y drivers/media/radio/Kconfig:257:depends on RADIO_TRUST=y drivers/media/radio/Kconfig:280:depends on RADIO_TYPHOON=y drivers/media/radio/Kconfig:287:depends on RADIO_TYPHOON=y drivers/media/radio/Kconfig:314:depends on RADIO_ZOLTRIX=y drivers/media/radio/Kconfig:385:depends on RADIO_TEA5764=y 1) It seems the logic behind those config symbols is mostly like this: - if the driver for a radio is builtin: default some setting for that radio to a sane value, but allow overriding of that setting on the kernel commandline (through a module parameter) - if the driver for a radio is a module: default that same setting to something invalid and _force_ the use of module parameters to get a sane value This logic isn't implemented flawless but it does look to me that this is intentional. 2) I'm not sure why things are done that way. Why can't builtin drivers and loadable drivers default to identical values? But perhaps I'm just misunderstanding the code. Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RESEND] media: tea5764: reconcile Kconfig symbol and macro
On Sun, 2011-10-30 at 10:24 -0700, Randy Dunlap wrote: On 10/30/11 10:12, Paul Bolle wrote: 2) I'm not sure why things are done that way. Why can't builtin drivers and loadable drivers default to identical values? But perhaps I'm just misunderstanding the code. They could default to identical values. That would make the cleaning up I'm trying to do now somewhat easier. It would allow to simplify the drivers a bit too. Maybe someone thinks that it's more difficult to pass parameters to builtin drivers so they just try to use some sane defaults for them instead, whereas it's easy (easier) to pass parameters to loadable modules. ?? Perhaps Mauro or the people at linux-media know the reasoning here. Or they can show us that I didn't parse the code correctly, of course. Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: tea5764: reconcile Kconfig symbol and macro
The Kconfig symbol RADIO_TEA5764_XTAL is unused. The code does use a
RADIO_TEA5764_XTAL macro, but does that rather peculiar. But there seems
to be a way to keep both. (The easiest way out would be to rip out both
the Kconfig symbol and the macro.)
Note there's also a module parameter 'use_xtal' to influence all this.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
I didn't dare to submit this a trivial patch. This is still untested. By
the way, is xtal a common abbreviation of crystal?
drivers/media/radio/radio-tea5764.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/media/radio/radio-tea5764.c
b/drivers/media/radio/radio-tea5764.c
index 95ddcc4..db20904 100644
--- a/drivers/media/radio/radio-tea5764.c
+++ b/drivers/media/radio/radio-tea5764.c
@@ -128,8 +128,10 @@ struct tea5764_write_regs {
u16 rdsbbl; /* PAUSEDET RDSBBL */
} __attribute__ ((packed));
-#ifndef RADIO_TEA5764_XTAL
+#ifdef CONFIG_RADIO_TEA5764_XTAL
#define RADIO_TEA5764_XTAL 1
+#else
+#define RADIO_TEA5764_XTAL 0
#endif
static int radio_nr = -1;
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] usbmon capture and parser script
On Thu, 2011-03-17 at 08:46 -0300, Mauro Carvalho Chehab wrote: On a quick test, it seems that it doesn't recognize the tcpdump file format (at least, it was not able to capture the dump files I got with the beagleboard). Adding support for it could be an interesting addition to your code. Please note that Micah Dowty is the maintainer of vusb-analyzer. I mostly cleaned, etc. its usbmon support (which was originally added by Christoph Zimmermann). Anyway, you're always free to try to add support for another file format. I must say that Micah was rather easy to work with. Btw, it seems that most of your work is focused on getting VMware logs. Micah had a vmware.com address last time I contacted him. That should explain that focus. Do you know if any of them are now capable of properly emulate USB 2.0 isoc transfers and give enough performance for the devices to actually work with such high-bandwidth requirements? This is not something I know much about. I tried to use some digital camera over USB with qemu without much success. Apparently qemu's USB pass through has little chance of supporting high bandwidth USB devices. See http://lists.nongnu.org/archive/html/qemu-devel/2010-09/msg00017.html for the - not very interesting - answer I got when I wanted to know more about the problems of USB pass through in qemu. Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] usbmon capture and parser script
On Wed, 2011-03-16 at 12:47 -0700, Greg KH wrote: Very cool stuff. You are away of: http://vusb-analyzer.sourceforge.net/ right? I know you are doing this in console mode, but it looks close to the same idea. Perhaps there should be some references to vusb-analyzer and similar tools in Documentation/usb/usbmon.txt (it now only mentions usbdump and USBMon). I remember looking for a tool like that (ie, a parser) for quite some time before stumbling onto vusb-analyzer. Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
