[meta-freescale] mxc_v4l2_capture sometimes not being modprobed

[John Weber]

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.

I'd be interested to know if anyone else sees the same problem on other machines?

John