From: Valentin Longchamp <valentin.longchamp@epfl.ch>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
"linux-hotplug@vger.kernel.org" <linux-hotplug@vger.kernel.org>
Subject: Re: [Q] udev and soc-camera
Date: Thu, 28 Jan 2010 14:02:54 +0000 [thread overview]
Message-ID: <4B61990E.5010604@epfl.ch> (raw)
In-Reply-To: <ac3eb2511001280118s4e00dca3l905a8ed7d532bde2@mail.gmail.com>
Kay Sievers wrote:
> On Thu, Jan 28, 2010 at 00:25, Valentin Longchamp
> <valentin.longchamp@epfl.ch> wrote:
>> I have a system that is built with OpenEmbedded where I use a mt9t031 camera
>> with the soc-camera framework. The mt9t031 works ok with the current kernel
>> and system.
>>
>> However, udev does not create the /dev/video0 device node. I have to create
>> it manually with mknod and then it works well. If I unbind the device on the
>> soc-camera bus (and then eventually rebind it), udev then creates the node
>> correctly. This looks like a "timing" issue at "coldstart".
>>
>> OpenEmbedded currently builds udev 141 and I am using kernel 2.6.33-rc5 (but
>> this was already like that with earlier kernels).
>>
>> Is this problem something known or has at least someone already experienced
>> that problem ?
>
> You need to run "udevadm trigger" as the bootstrap/coldplug step,
> after you stared udev. All the devices which are already there at that
> time, will not get created by udev, only new ones which udev will see
> events for. The trigger will tell the kernel to send all events again.
>
> Or just use the kernel's devtmpfs, and all this should work, even
> without udev, if you do not have any other needs than plain device
> nodes.
>
Thanks a lot Kay, you pointed me exactly where I needed to watch.
OpenEmbedded adds udevadm trigger a big list of --susbsystem-nomatch
options as soon as you are not doing your first boot anymore and
video4linux is among them.
I either have to remove this option in the script or understand why my
other /dev nodes are kept (ttys are doing fine with the same treatment
for instance) and not video4linux ones (it looks like they are using
DEVCACHE or something like this). But I would prefer the first
alternative since cameras may be unplugged on some robots.
Val
--
Valentin Longchamp, PhD Student, EPFL-STI-LSRO1
valentin.longchamp@epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEB3494, Station 9, CH-1015 Lausanne
next prev parent reply other threads:[~2010-01-28 14:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-27 23:25 [Q] udev and soc-camera Valentin Longchamp
2010-01-28 9:18 ` Kay Sievers
2010-01-28 14:02 ` Valentin Longchamp [this message]
2010-01-28 14:13 ` Kay Sievers
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=4B61990E.5010604@epfl.ch \
--to=valentin.longchamp@epfl.ch \
--cc=kay.sievers@vrfy.org \
--cc=linux-hotplug@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).