[meta-freescale] mxc_v4l2_capture sometimes not being modprobed

[Otavio Salvador]

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