From: "Richard Röjfors" <richard.rojfors@pelagicore.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>,
Mauro Carvalho Chehab <mchehab@infradead.org>,
Douglas Schilling Landgraf <dougsland@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 1/2] radio: Add radio-timb
Date: Wed, 27 Jan 2010 17:04:49 +0100 [thread overview]
Message-ID: <4B606421.1060905@pelagicore.com> (raw)
In-Reply-To: <201001271241.46912.hverkuil@xs4all.nl>
Hans Verkuil wrote:
>> The first time we run we could definitely do a 4l2_i2c_new_subdev*, but what if I rmmod the driver
>> and insmod it again? When we do the do an open, then v4l2_i2c_new_subdev* would fail because the
>> device is only on the bus and probed. So I would have to look for it anyway. Or am I wrong? I found
>> this like the only generic way(?)
>
> Not sure I understand you. When you call v4l2_device_unregister any registered
> i2c devices will be automatically unloaded from the i2c bus. So when you do a
> new modprobe, then it is as if you did it for the first time.
>
> This should work. If not, then let me know and we can look at it.
Thanks for the explanation! It should work, I will update accordingly.
>
>>> Is there a reason why you want to load them only on first use? It is customary
>>> to load them when this driver is loaded. Exceptions to that may be if the i2c
>>> device needs to load a firmware: this can be slow over i2c and so should be
>>> postponed until the i2c driver is needed for the first time.
>> The main reason is actually that this is a platform device which might come available before the I2C
>> bus in the system. So we postpone the use of the bus until needed, because we know for sure it's
>> available at that point.
>
> The i2c busses are always initialized first. That's a change that went in a few
> kernel releases ago.
Ok, in this case the I2C bus sits on top of a MFD device which might be installed late to reduce
bootup time.
Bootup time is actually also a reason to keep this code in open rather than in probe.
--Richard
prev parent reply other threads:[~2010-01-27 16:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-22 12:38 [PATCH 1/2] radio: Add radio-timb Richard Röjfors
2010-01-22 16:26 ` Hans Verkuil
2010-01-22 19:36 ` Richard Röjfors
2010-01-27 11:41 ` Hans Verkuil
2010-01-27 16:04 ` Richard Röjfors [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=4B606421.1060905@pelagicore.com \
--to=richard.rojfors@pelagicore.com \
--cc=akpm@linux-foundation.org \
--cc=dougsland@gmail.com \
--cc=hverkuil@xs4all.nl \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@infradead.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.