[meta-freescale] mxc_v4l2_capture sometimes not being modprobed
Otavio Salvador
otavio at ossystems.com.br
Thu Jun 5 12:34:24 PDT 2014
On Thu, Jun 5, 2014 at 4:10 PM, John Weber <rjohnweber at gmail.com> wrote:
>
> On 6/5/14, 1:38 PM, Otavio Salvador wrote:
>>
>> On Thu, Jun 5, 2014 at 3:23 PM, John Weber <rjohnweber at gmail.com> wrote:
>>>
>>> On 6/5/14, 1:17 PM, Otavio Salvador wrote:
>>>>
>>>> On Thu, Jun 5, 2014 at 3:14 PM, John Weber <rjohnweber at gmail.com> wrote:
>>>>>
>>>>> On 6/5/14, 1:08 PM, Otavio Salvador wrote:
>>>>>>
>>>>>> On Thu, Jun 5, 2014 at 3:05 PM, John Weber <rjohnweber at gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> On 6/5/14, 12:34 PM, Otavio Salvador wrote:
>>>>>>>>
>>>>>>>> On Mon, May 26, 2014 at 12:42 AM, John Weber <rjohnweber at gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> meta-freescalers:
>>>>>>>>>
>>>>>>>>> I'm seeing a behavior that I can't easily explain. I'm not seeing
>>>>>>>>> the
>>>>>>>>> mxc_v4l2_capture drivers and dependent ipu drivers being
>>>>>>>>> automatically
>>>>>>>>> modprobed on Wandboard during a majority of system startups (but
>>>>>>>>> not
>>>>>>>>> all).
>>>>>>>>> I was under the impression that this should be done by udev, but
>>>>>>>>> for
>>>>>>>>> some
>>>>>>>>> reason it seems to either fail or is skipped.
>>>>>>>>>
>>>>>>>>> I can force the driver to be loaded at startup by adding the name
>>>>>>>>> of
>>>>>>>>> the
>>>>>>>>> driver in a line in /etc/modules. This works to load the driver
>>>>>>>>> every
>>>>>>>>> time
>>>>>>>>> at startup, but I'm fairly certain that this is not the most ideal
>>>>>>>>> approach
>>>>>>>>> because (A) I have to write a recipe to make the change to
>>>>>>>>> /etc/modules
>>>>>>>>> and
>>>>>>>>> (B) it does not explain why the driver load works sometimes, but
>>>>>>>>> not
>>>>>>>>> all
>>>>>>>>> of
>>>>>>>>> the time.
>>>>>>>>>
>>>>>>>>> Any ideas?
>>>>>>>>
>>>>>>>> Does this happens with 3.0.35 and 3.10.17?
>>>>>>>>
>>>>>>> I did notice it on both kernels. From what I've been able to gather
>>>>>>> after
>>>>>>> sending this email, the modules load at first boot on a freshly
>>>>>>> burned
>>>>>>> rootfs (that hasn't been postinst'd). After that, SW and HW resets
>>>>>>> and
>>>>>>> POR
>>>>>>> to not result in loaded mxc_v4l2_capture module or its dependencies.
>>>>>>> I
>>>>>>> do
>>>>>>> have other modules loaded, however, all the time - the ov5640_mipi
>>>>>>> driver
>>>>>>> and the Broadcom WLAN drivers load without fail.
>>>>>>>
>>>>>>> I suspect it could be a sequencing problem, but adding the line to
>>>>>>> /etc/modules fixes it.
>>>>>>
>>>>>> Are you using udev-cache?
>>>>>>
>>>>> I believe so:
>>>>> root at wandboard-dual:/etc# find . -name *udev-cache*
>>>>> ./rcS.d/S36udev-cache
>>>>> ./default/udev-cache
>>>>> ./init.d/udev-cache
>>>>
>>>> Disable it in default, please, and check if it helps.
>>>>
>>> That did it. Thanks! Not sure how to fix the problem though.
>>
>> Well ... I need a coffee ...
>>
>> Ok ... it seems we have a timing issue but it is related to the device
>> settling.
>>
>> Please apply following change in the udev init script:
>>
>> --- a/meta/recipes-core/udev/udev/init
>> +++ b/meta/recipes-core/udev/udev/init
>> @@ -103,7 +103,7 @@ case "$1" in
>> udevadm control --env=STARTUP=1
>> if [ "$not_first_boot" != "" ];then
>> udevadm trigger --action=add --subsystem-nomatch=tty
>> --subsystem-nomatch=mem --subsystem-nomatch=vc
>> --subsystem-nomatch=vtconsole --subsystem-nomatch=misc
>> --subsystem-nomatch=dcon -
>> - (udevadm settle --timeout=3; udevadm control --env=STARTUP=)&
>> + (udevadm settle; udevadm control --env=STARTUP=)&
>> else
>> udevadm trigger --action=add
>> udevadm settle
>>
>>
> Nope - that doesn't help the problem. The udevadm trigger line above
> includes "--subsystem-nomatch=platform" and if I remove that while keeping
> everything else the same, it works fine.
It kind of makes sense to me; if you keep the platform skip and remove
the background & job, does it work?
> I'd be interested to know if anyone else sees the same problem on other
> machines?
I bet it is not machine dependent.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
More information about the meta-freescale
mailing list