Kay Sievers wrote:
On Thu, Jan 28, 2010 at 00:25, Valentin Longchamp
<valentin.longchamp@xxxxxxx> 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@xxxxxxx, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEB3494, Station 9, CH-1015 Lausanne
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
