Re: mxc_v4l2_capture sometimes not being modprobed

[John Weber <rjohnweber@gmail.com>]

On 6/5/14, 2:34 PM, Otavio Salvador wrote:
> On Thu, Jun 5, 2014 at 4:10 PM, John Weber <rjohnweber@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@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@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@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@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@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?
If you mean, remove the timeout=3 on the udevadm settle, no.  If I keep the 
platform skip, it does not work at all.

>> I'd be interested to know if anyone else sees the same problem on other
>> machines?
> I bet it is not machine dependent.
>
I think you're right, but as far as I know the only other entity that could 
confirm this would be Boundary Devices.  Eric - do you see this same issue when 
connecting your camera to Nitrogen6x?

John