From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 0C8ADE00B85; Thu, 5 Jun 2014 12:10:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-HAM-Report: * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (rjohnweber[at]gmail.com) * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.213.41 listed in list.dnswl.org] * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Received: from mail-yh0-f41.google.com (mail-yh0-f41.google.com [209.85.213.41]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 2308CE00BB1 for ; Thu, 5 Jun 2014 12:10:16 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id f73so1252506yha.0 for ; Thu, 05 Jun 2014 12:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=v0OZ/JeAvA9adU48ZvzOaJ8llErBL6eoe5S4rDvcc7U=; b=Lx4ZyhF7eXH/IF20wKHzAEAszt6U8A3/lou5VGI/vnClpQZil4bVzwYxJHfDEWgQbU R2TNlK0+YIgxLBGWxUi7DT+hM4alQd2nZXHkmcdOPupEymL97H2sVnxxNB9odxc2p+1X sG+tXw4aTOhzpRHdJGCa0YVvXWT9A6njtFm8KPTBQEkHyx+nODmMwGn3HSd1mft+hKcM mZhXAogB8H4HiHjJ1RGsJskkl9MpyZxuH3oHpuIhxE6HUlpvwxh/rt1+n2zfg5zALALd VeABhXo3Z9y+c7nH56uSHsyD1w0wATjNDIyK1LLO+Z0VfO5CTiWVbmeCrbv2EXUkwro1 39SQ== X-Received: by 10.236.39.103 with SMTP id c67mr38328628yhb.139.1401995416285; Thu, 05 Jun 2014 12:10:16 -0700 (PDT) Received: from goober-2.local ([75.76.197.2]) by mx.google.com with ESMTPSA id l12sm10111920yhj.1.2014.06.05.12.10.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 12:10:15 -0700 (PDT) Message-ID: <5390C097.6050908@gmail.com> Date: Thu, 05 Jun 2014 14:10:15 -0500 From: John Weber User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Otavio Salvador References: <5382B827.2030302@gmail.com> <5390B171.8080600@gmail.com> <5390B373.7040805@gmail.com> <5390B585.8090104@gmail.com> In-Reply-To: Cc: "meta-freescale@yoctoproject.org" Subject: Re: mxc_v4l2_capture sometimes not being modprobed X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 19:10:29 -0000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 6/5/14, 1:38 PM, Otavio Salvador wrote: > On Thu, Jun 5, 2014 at 3:23 PM, John Weber wrote: >> On 6/5/14, 1:17 PM, Otavio Salvador wrote: >>> On Thu, Jun 5, 2014 at 3:14 PM, John Weber wrote: >>>> On 6/5/14, 1:08 PM, Otavio Salvador wrote: >>>>> On Thu, Jun 5, 2014 at 3:05 PM, John Weber wrote: >>>>>> On 6/5/14, 12:34 PM, Otavio Salvador wrote: >>>>>>> On Mon, May 26, 2014 at 12:42 AM, John Weber >>>>>>> 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. I'd be interested to know if anyone else sees the same problem on other machines? John