All of lore.kernel.org
 help / color / mirror / Atom feed
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

WARNING: multiple messages have this Message-ID (diff)
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 15:02:54 +0100	[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

  reply	other threads:[~2010-01-28 14:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-27 23:25 [Q] udev and soc-camera Valentin Longchamp
2010-01-27 23:25 ` Valentin Longchamp
2010-01-28  9:18 ` Kay Sievers
2010-01-28  9:18   ` Kay Sievers
2010-01-28 14:02   ` Valentin Longchamp [this message]
2010-01-28 14:02     ` Valentin Longchamp
2010-01-28 14:13     ` Kay Sievers
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 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.