[meta-freescale] mxc_v4l2_capture sometimes not being modprobed

[Otavio Salvador]

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


-- 
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