Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 22 7月, 2014 1 次提交
  3. 21 12月, 2013 1 次提交
    • M
      [media] subdev autoselect only works if I2C and I2C_MUX is selected · 347f7a37
      由 Mauro Carvalho Chehab 提交于 
      As reported by the kbuild test robot <fengguang.wu@intel.com>:

> warning: (VIDEO_EM28XX_DVB) selects DVB_M88DS3103 which has unmet direct dependencies (MEDIA_SUPPORT && DVB_CORE && I2C && I2C_MUX)
>    drivers/built-in.o: In function `m88ds3103_release':
> >> m88ds3103.c:(.text+0x1ab1af): undefined reference to `i2c_del_mux_adapter'
>    drivers/built-in.o: In function `m88ds3103_attach':
> >> (.text+0x1ab342): undefined reference to `i2c_add_mux_adapter'

There are 3 possible ways to fix it:

1) make em28xx dependent on I2C_MUX.

That sounds wrong, as the em28xx bridge doesn't have i2c muxes on it,
and just one frontend has.

Well, subdevs could eventually be converted to, instead of using dvb
i2c gate control, to use i2c mux support.

That makes sense, but it takes time and lots of effort. Not sure if
this will happen anytime soon.

2) MEDIA_SUBDRV_AUTOSELECT can be dependent of I2C and I2C_MUX.

That means that users will need to manually enable I2C_MUX on some
distributions. Not sure about others, but, on Fedora, this option is
disabled.

So, it can end by generating a number of complains from users
that their devices suddenly stopped working after a Kernel upgrade,
at least until all distros that ship Kernels with I2C_MUX enabled.

3) if MEDIA_SUBDRV_AUTOSELECT is selected, it will select I2C and I2C_MUX.

Of course, MEDIA_SUBDRV_AUTOSELECT will need to inherit all dependencies
that I2C and I2C_MUX have (only HAS_IOMEM).

The disadvantage is that, if new dependencies are added on I2C, they'll
also need to be added here.

As the hole idea of autoselect is to let the user not bother about whatever
frontend/tuner is used by a driver, IMHO, (3) is the better solution.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      347f7a37
  5. 20 6月, 2013 1 次提交
    • M
      [media] Fix build when drivers are builtin and frontend modules · bb69ee27
      由 Mauro Carvalho Chehab 提交于 
      There are a large number of reports that the media build is
not compiling when some drivers are compiled as builtin, while
the needed frontends are compiled as module.

On the last one of such reports:
	From: kbuild test robot <fengguang.wu@intel.com>
	Subject: saa7134-dvb.c:undefined reference to `zl10039_attach'

The .config file has:

	CONFIG_VIDEO_SAA7134=y
	CONFIG_VIDEO_SAA7134_DVB=y
	# CONFIG_MEDIA_ATTACH is not set
	CONFIG_DVB_ZL10039=m

And it produces all those errors:

   drivers/built-in.o: In function `set_type':
   tuner-core.c:(.text+0x2f263e): undefined reference to `tea5767_attach'
   tuner-core.c:(.text+0x2f273e): undefined reference to `tda9887_attach'
   drivers/built-in.o: In function `tuner_probe':
   tuner-core.c:(.text+0x2f2d20): undefined reference to `tea5767_autodetection'
   drivers/built-in.o: In function `av7110_attach':
   av7110.c:(.text+0x330bda): undefined reference to `ves1x93_attach'
   av7110.c:(.text+0x330bf7): undefined reference to `stv0299_attach'
   av7110.c:(.text+0x330c63): undefined reference to `tda8083_attach'
   av7110.c:(.text+0x330d09): undefined reference to `ves1x93_attach'
   av7110.c:(.text+0x330d33): undefined reference to `tda8083_attach'
   av7110.c:(.text+0x330d5d): undefined reference to `stv0297_attach'
   av7110.c:(.text+0x330dbe): undefined reference to `stv0299_attach'
   drivers/built-in.o: In function `tuner_attach_dtt7520x':
   ngene-cards.c:(.text+0x3381cb): undefined reference to `dvb_pll_attach'
   drivers/built-in.o: In function `demod_attach_lg330x':
   ngene-cards.c:(.text+0x33828a): undefined reference to `lgdt330x_attach'
   drivers/built-in.o: In function `demod_attach_stv0900':
   ngene-cards.c:(.text+0x3383d5): undefined reference to `stv090x_attach'
   drivers/built-in.o: In function `cineS2_probe':
   ngene-cards.c:(.text+0x338b7f): undefined reference to `drxk_attach'
   drivers/built-in.o: In function `configure_tda827x_fe':
   saa7134-dvb.c:(.text+0x346ae7): undefined reference to `tda10046_attach'
   drivers/built-in.o: In function `dvb_init':
   saa7134-dvb.c:(.text+0x347283): undefined reference to `mt352_attach'
   saa7134-dvb.c:(.text+0x3472cd): undefined reference to `mt352_attach'
   saa7134-dvb.c:(.text+0x34731c): undefined reference to `tda10046_attach'
   saa7134-dvb.c:(.text+0x34733c): undefined reference to `tda10046_attach'
   saa7134-dvb.c:(.text+0x34735c): undefined reference to `tda10046_attach'
   saa7134-dvb.c:(.text+0x347378): undefined reference to `tda10046_attach'
   saa7134-dvb.c:(.text+0x3473db): undefined reference to `tda10046_attach'
   drivers/built-in.o:saa7134-dvb.c:(.text+0x347502): more undefined references to `tda10046_attach' follow
   drivers/built-in.o: In function `dvb_init':
   saa7134-dvb.c:(.text+0x347812): undefined reference to `mt352_attach'
   saa7134-dvb.c:(.text+0x347951): undefined reference to `mt312_attach'
   saa7134-dvb.c:(.text+0x3479a9): undefined reference to `mt312_attach'
>> saa7134-dvb.c:(.text+0x3479c1): undefined reference to `zl10039_attach'

This is happening because a builtin module can't use directly a symbol
found on a module. By enabling CONFIG_MEDIA_ATTACH, the configuration
becomes valid, as dvb_attach() macro loads the module if needed, making
the symbol available to the builtin module.

While this bug started to appear after the patches that use IS_DEFINED
macro (like changeset 7b34be71), this
bug is a way ancient than that.

The thing is that, before the IS_DEFINED() patches, the logic used to be:

       && defined(MODULE))
struct dvb_frontend *zl10039_attach(struct dvb_frontend *fe,
					u8 i2c_addr,
					struct i2c_adapter *i2c);
static inline struct dvb_frontend *zl10039_attach(struct dvb_frontend *fe,
					u8 i2c_addr,
					struct i2c_adapter *i2c)
{
	printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
	return NULL;
}

The above code, with the .config file used, was evoluting to FALSE
(instead of TRUE as it should be, as CONFIG_DVB_ZL10039 is 'm'),
and were adding the static inline code at saa7134-dvb, instead
of the external call. So, while it weren't producing any compilation
error, the code weren't working either.

So, as the overhead for using CONFIG_MEDIA_ATTACH is minimal, just
enable it, if MODULES is defined.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      bb69ee27
  7. 12 1月, 2013 1 次提交
  9. 28 12月, 2012 2 次提交
  11. 18 10月, 2012 1 次提交
  13. 21 8月, 2012 3 次提交
  15. 16 8月, 2012 4 次提交
  17. 14 8月, 2012 9 次提交
  19. 06 7月, 2012 3 次提交
    • M
      [media] Kconfig: Split the core support options from the driver ones · c455f5c8
      由 Mauro Carvalho Chehab 提交于 
      Better arrange the remote controller driver items to happen after the
core support, on their proper menus, and making clerarer what is media
core options and what is media driver options.
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      c455f5c8
    • M
      [media] media: Remove VIDEO_MEDIA Kconfig option · 8cfd9dcc
      由 Mauro Carvalho Chehab 提交于 
      In the past, it was possible to have either DVB or V4L2 core
as module and the other as builtin. Such config never make much
sense, and created several issues in order to make the Kconfig
dependency to work, as all drivers that depend on both (most
TV drivers) would need to be compiled as 'm'. Due to that,
the VIDEO_MEDIA config option were added.

Instead of such weird approach, let's just use the MEDIA_SUPPORT
=y or =m to select if the media subsystem core will be either
builtin or module, simplifying the building system logic.

Also, fix the tuners configuration, by enabling them only if
a tuner is required. So, if just webcam/grabbers support is
selected, no tuner option will be selected. Also, if only digital
TV is selected, no analog tuner support is selected.

That removes the need of using EXPERT customise options, when
analog TV is not selected.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      8cfd9dcc
    • M
      [media] media: reorganize the main Kconfig items · b4c184e5
      由 Mauro Carvalho Chehab 提交于 
      Change the main items to:

<m> Multimedia support  --->
   [ ]   Cameras/video grabbers support
   [ ]   Analog TV support
   [ ]   Digital TV support
   [ ]   AM/FM radio receivers/transmitters support
   [ ]   Remote Controller support

This provides an interface that is clearer to end users that
are compiling the Kernel, and will allow the building system
to automatically unselect drivers for unused functions.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      b4c184e5
  21. 28 7月, 2011 3 次提交
  23. 22 3月, 2011 2 次提交
  25. 29 12月, 2010 4 次提交
  27. 09 11月, 2010 1 次提交
    • A
      [media] v4l: kill the BKL · 0edf2e5e
      由 Arnd Bergmann 提交于 
      All of the hard problems for BKL removal appear to be solved in the
v4l-dvb/master tree. This removes the BKL from the various open
functions that do not need it, or only use it to protect an
open count.

The zoran driver is nontrivial in this regard, so I introduce
a new mutex that locks both the open/release and the ioctl
functions. Someone with access to the hardware can probably
improve that by using the existing lock in all cases.

Finally, all drivers that still use the locked version of the
ioctl function now get called under a new mutex instead of
the BKL.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      0edf2e5e
  29. 21 10月, 2010 1 次提交
    • A
      BKL: introduce CONFIG_BKL. · 6de5bd12
      由 Arnd Bergmann 提交于 
      With all the patches we have queued in the BKL removal tree, only a
few dozen modules are left that actually rely on the BKL, and even
there are lots of low-hanging fruit. We need to decide what to do
about them, this patch illustrates one of the options:

Every user of the BKL is marked as 'depends on BKL' in Kconfig,
and the CONFIG_BKL becomes a user-visible option. If it gets
disabled, no BKL using module can be built any more and the BKL
code itself is compiled out.

The one exception is file locking, which is practically always
enabled and does a 'select BKL' instead. This effectively forces
CONFIG_BKL to be enabled until we have solved the fs/lockd
mess and can apply the patch that removes the BKL from fs/locks.c.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      6de5bd12
  31. 16 12月, 2009 1 次提交
  33. 17 6月, 2009 1 次提交
  35. 30 3月, 2009 1 次提交