All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH] V4L: introduce a Kconfig variable to disable helper-chip autoselection
Date: Wed, 17 Mar 2010 18:09:07 -0300	[thread overview]
Message-ID: <4BA144F3.7000706@redhat.com> (raw)
In-Reply-To: <201003172054.53553.hverkuil@xs4all.nl>

Hans,

Hans Verkuil wrote:
> On Wednesday 17 March 2010 20:28:07 Mauro Carvalho Chehab wrote:
>> Guennadi Liakhovetski wrote:
>>
>>> Hi Mauro
>>>
>>> we just discussed this with Hans on IRC, and if I understood him 
>>> correctly, he was of the same opinion, that adding such a variable could 
>>> help.
>>>
>>> The problem is the following: this automatic selection works in a way, 
>>> that various bridge drivers select "helper" chip drivers (i2c subdevice 
>>> drivers" if this autoselection is enabled, e.g.
>>>
>>> config VIDEO_MXB
>>> 	tristate "Siemens-Nixdorf 'Multimedia eXtension Board'"
>>> 	depends on PCI && VIDEO_V4L1 && I2C
>>> 	select VIDEO_SAA7146_VV
>>> 	select VIDEO_TUNER
>>> 	select VIDEO_SAA711X if VIDEO_HELPER_CHIPS_AUTO
>>> 	select VIDEO_TDA9840 if VIDEO_HELPER_CHIPS_AUTO
>>> 	select VIDEO_TEA6415C if VIDEO_HELPER_CHIPS_AUTO
>>> 	select VIDEO_TEA6420 if VIDEO_HELPER_CHIPS_AUTO
>>>
>>> With SoC-based set ups this cannot work. The only location where this 
>>> information is available is platform code under arch/... and selecting 
>>> these drivers from there would be awkward imho.
>> Kconfig works fine if the var is on another place. So, you could do things
>> like:
>>
>> config VIDEO_xxx
>> 	select VIDEO_foo if VIDEO_HELPER_CHIPS_AUTO && ARCH_bar
>>
>> You may even convert it into dependencies like:
>>
>> config VIDEO_I2C_foo
>> 	depends on ARCH_bar && config VIDEO_xxx
>> 	default y if VIDEO_HELPER_CHIPS_AUTO
> 
> I2C drivers are NOT dependent on architectures. They can be used anywhere.
> 
>> The depends on syntax generally works better than using select. We've converted
>> some select into depends on a few places like tuner, like, for example:
>>
>> config MEDIA_TUNER_TDA827X
>>         tristate "Philips TDA827X silicon tuner"
>>         depends on VIDEO_MEDIA && I2C
>>         default m if MEDIA_TUNER_CUSTOMISE
>>
>>> So, for example, we want 
>>> to put the ak881x video encoder driver under
>>>
>>> comment "Video encoders"
>>>
>>> and those drivers are only visible if VIDEO_HELPER_CHIPS_AUTO is 
>>> unselected, and if it is selected, which it is by default, there is noone 
>>> to automatically select ak881x. So, I think, the proposed patch is not a 
>>> work-around, but a reasonable solution for this issue.
>> Even the menu being invisible, any of the above logic would work, if you do
>> something like:
>>
>> config VIDEO_AK881X
>> 	depends on ARCH_MX1 && I2C
>> 	default y if VIDEO_HELPER_CHIPS_AUTO && SOC_CAMERA
>>
>> or:
>>
>> config SOC_CAMERA
>> 	select VIDEO_AK881X if VIDEO_HELPER_CHIPS_AUTO && ARCH_MX1
> 
> Same problem here: the architecture does not determine whether this i2c driver
> is needed. That is determined by the board definition. I guess the right place
> to do this is probably in a 'mach' specific Kconfig like for example
> arch/arm/mach-davinci/Kconfig.
> 
> But to be honest, I think that the SoC + VIDEO_HELPER_CHIPS_AUTO combination
> is pretty pointless.
> 
> Regards,
> 
> 	Hans
> 

I've discussed this issue with Guennadi on IRC today. The better seems to just
disable or change the default to 'n' for the AUTO/CUSTOMISE options, when 
CONFIG_EMBEDDED. He's working on a new patch.

-- 

Cheers,
Mauro

      reply	other threads:[~2010-03-17 21:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-17 12:38 [PATCH] V4L: introduce a Kconfig variable to disable helper-chip autoselection Guennadi Liakhovetski
2010-03-17 12:59 ` Mauro Carvalho Chehab
2010-03-17 13:56   ` Guennadi Liakhovetski
2010-03-17 19:28     ` Mauro Carvalho Chehab
2010-03-17 19:54       ` Hans Verkuil
2010-03-17 21:09         ` Mauro Carvalho Chehab [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BA144F3.7000706@redhat.com \
    --to=mchehab@redhat.com \
    --cc=g.liakhovetski@gmx.de \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-media@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.