[meta-freescale] mxc_v4l2_capture sometimes not being modprobed

John Weber rjohnweber at gmail.com
Thu Jun 5 11:14:11 PDT 2014

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*

More information about the meta-freescale mailing list