From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id C7AC4E00B85; Thu, 5 Jun 2014 13:30:35 -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.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 * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.216.50 listed in list.dnswl.org] Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id C0752E00A44 for ; Thu, 5 Jun 2014 13:30:34 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id j15so2176370qaq.37 for ; Thu, 05 Jun 2014 13:30:33 -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=DUShfSFXFD7tEqD+2gBe0achQgUjXEV7nh74FZBC+Q0=; b=p/SCFXWBf5y7iTE5o+x8uXIjCwsfy+DnfVowMsc9kNqjCPX68iCFuNkCem0qVVj0Qm aMmS3G0rRTOv9uIzVtdyycRAwN9pF7Ohf9h8W0g9zdRVlm3yrroJKCfyjoYfvBKRbNhK Kqu/k0Ep6elCLABRLitwhJMTxHem2mA086+BqRdECTploTlZT8u8/1xqoiu1awVDP25/ YtTV96u4wTKo2EGhBWG/yvrKEr+Ve5au5Pz1tL4UUAXhkW+2wrLQjbPr8Jy4PgtSgTLN nvC2HNx0nkC2hgTXwC6uEoVEV6oP8U2xrgYCozl9aN+H+JrX1lT2vYqtJyPUVEoNq1ov CuCg== X-Received: by 10.140.39.164 with SMTP id v33mr81654973qgv.99.1402000233568; Thu, 05 Jun 2014 13:30:33 -0700 (PDT) Received: from goober-2.local ([75.76.197.2]) by mx.google.com with ESMTPSA id t32sm10412558yhp.48.2014.06.05.13.30.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 13:30:32 -0700 (PDT) Message-ID: <5390D368.9000309@gmail.com> Date: Thu, 05 Jun 2014 15:30:32 -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> <5390C097.6050908@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 20:30:35 -0000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 6/5/14, 2:34 PM, Otavio Salvador wrote: > On Thu, Jun 5, 2014 at 4:10 PM, John Weber wrote: >> 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. > 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