* mxc_v4l2_capture sometimes not being modprobed
@ 2014-05-26 3:42 John Weber
2014-06-05 17:34 ` Otavio Salvador
0 siblings, 1 reply; 23+ messages in thread
From: John Weber @ 2014-05-26 3:42 UTC (permalink / raw)
To: meta-freescale
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?
John
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mxc_v4l2_capture sometimes not being modprobed
2014-05-26 3:42 mxc_v4l2_capture sometimes not being modprobed John Weber
@ 2014-06-05 17:34 ` Otavio Salvador
2014-06-05 18:05 ` John Weber
0 siblings, 1 reply; 23+ messages in thread
From: Otavio Salvador @ 2014-06-05 17:34 UTC (permalink / raw)
To: John Weber; +Cc: meta-freescale
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?
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mxc_v4l2_capture sometimes not being modprobed
2014-06-05 17:34 ` Otavio Salvador
@ 2014-06-05 18:05 ` John Weber
2014-06-05 18:08 ` Otavio Salvador
0 siblings, 1 reply; 23+ messages in thread
From: John Weber @ 2014-06-05 18:05 UTC (permalink / raw)
To: Otavio Salvador; +Cc: meta-freescale
Hey Otavio,
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.
John
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mxc_v4l2_capture sometimes not being modprobed
2014-06-05 18:05 ` John Weber
@ 2014-06-05 18:08 ` Otavio Salvador
2014-06-05 18:14 ` John Weber
0 siblings, 1 reply; 23+ messages in thread
From: Otavio Salvador @ 2014-06-05 18:08 UTC (permalink / raw)
To: John Weber; +Cc: meta-freescale
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?
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mxc_v4l2_capture sometimes not being modprobed
2014-06-05 18:08 ` Otavio Salvador
@ 2014-06-05 18:14 ` John Weber
2014-06-05 18:17 ` Otavio Salvador
0 siblings, 1 reply; 23+ messages in thread
From: John Weber @ 2014-06-05 18:14 UTC (permalink / raw)
To: Otavio Salvador; +Cc: meta-freescale
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mxc_v4l2_capture sometimes not being modprobed
2014-06-05 18:14 ` John Weber
@ 2014-06-05 18:17 ` Otavio Salvador
2014-06-05 18:23 ` John Weber
0 siblings, 1 reply; 23+ messages in thread
From: Otavio Salvador @ 2014-06-05 18:17 UTC (permalink / raw)
To: John Weber; +Cc: meta-freescale
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.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mxc_v4l2_capture sometimes not being modprobed
2014-06-05 18:17 ` Otavio Salvador
@ 2014-06-05 18:23 ` John Weber
2014-06-05 18:38 ` Otavio Salvador
0 siblings, 1 reply; 23+ messages in thread
From: John Weber @ 2014-06-05 18:23 UTC (permalink / raw)
To: Otavio Salvador; +Cc: meta-freescale
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mxc_v4l2_capture sometimes not being modprobed
2014-06-05 18:23 ` John Weber
@ 2014-06-05 18:38 ` Otavio Salvador
2014-06-05 19:10 ` John Weber
0 siblings, 1 reply; 23+ messages in thread
From: Otavio Salvador @ 2014-06-05 18:38 UTC (permalink / raw)
To: John Weber; +Cc: meta-freescale
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
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mxc_v4l2_capture sometimes not being modprobed
2014-06-05 18:38 ` Otavio Salvador
@ 2014-06-05 19:10 ` John Weber
2014-06-05 19:34 ` Otavio Salvador
0 siblings, 1 reply; 23+ messages in thread
From: John Weber @ 2014-06-05 19:10 UTC (permalink / raw)
To: Otavio Salvador; +Cc: meta-freescale
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.
I'd be interested to know if anyone else sees the same problem on other machines?
John
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mxc_v4l2_capture sometimes not being modprobed
2014-06-05 19:10 ` John Weber
@ 2014-06-05 19:34 ` Otavio Salvador
2014-06-05 20:30 ` John Weber
0 siblings, 1 reply; 23+ messages in thread
From: Otavio Salvador @ 2014-06-05 19:34 UTC (permalink / raw)
To: John Weber; +Cc: meta-freescale
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?
> I'd be interested to know if anyone else sees the same problem on other
> machines?
I bet it is not machine dependent.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mxc_v4l2_capture sometimes not being modprobed
2014-06-05 19:34 ` Otavio Salvador
@ 2014-06-05 20:30 ` John Weber
2014-06-05 20:33 ` Eric Nelson
0 siblings, 1 reply; 23+ messages in thread
From: John Weber @ 2014-06-05 20:30 UTC (permalink / raw)
To: Otavio Salvador; +Cc: meta-freescale
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mxc_v4l2_capture sometimes not being modprobed
2014-06-05 20:30 ` John Weber
@ 2014-06-05 20:33 ` Eric Nelson
2014-06-05 20:40 ` John Weber
2014-06-06 23:10 ` Eric Nelson
0 siblings, 2 replies; 23+ messages in thread
From: Eric Nelson @ 2014-06-05 20:33 UTC (permalink / raw)
To: John Weber, Otavio Salvador; +Cc: meta-freescale
Hi all,
On 06/05/2014 01:30 PM, John Weber wrote:
>
> 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:
>>>>>>>>>>>
>>>>
>>>> <snip>
>>>>
>>>> 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?
>
I've kinda followed this thread, but I'm kinda buried and it will take
a day or two for me to confirm or deny this.
Regards,
Eric
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mxc_v4l2_capture sometimes not being modprobed
2014-06-05 20:33 ` Eric Nelson
@ 2014-06-05 20:40 ` John Weber
2014-06-06 23:10 ` Eric Nelson
1 sibling, 0 replies; 23+ messages in thread
From: John Weber @ 2014-06-05 20:40 UTC (permalink / raw)
To: Eric Nelson, Otavio Salvador; +Cc: meta-freescale
On 6/5/14, 3:33 PM, Eric Nelson wrote:
> Hi all,
>
> On 06/05/2014 01:30 PM, John Weber wrote:
>> 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:
>>>>>>>>>>>>
>>>>> <snip>
>>>>>
>>>>> 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?
>>
> I've kinda followed this thread, but I'm kinda buried and it will take
> a day or two for me to confirm or deny this.
>
> Regards,
>
>
> Eric
>
Thanks Eric. It just occurred to me that it could be confirmed on the SDB or
SDP as well.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mxc_v4l2_capture sometimes not being modprobed
2014-06-05 20:33 ` Eric Nelson
2014-06-05 20:40 ` John Weber
@ 2014-06-06 23:10 ` Eric Nelson
2014-06-08 15:51 ` John Weber
1 sibling, 1 reply; 23+ messages in thread
From: Eric Nelson @ 2014-06-06 23:10 UTC (permalink / raw)
To: John Weber, Otavio Salvador; +Cc: meta-freescale
Hi John,
On 06/05/2014 01:33 PM, Eric Nelson wrote:
> On 06/05/2014 01:30 PM, John Weber wrote:
>>
>> <snip>
>>
>> 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?
>>
>
> I've kinda followed this thread, but I'm kinda buried and it will take
> a day or two for me to confirm or deny this.
>
I just tested across a dozen assorted reboots/resets/power-cycles
and didn't see the issue with an OV5642 parallel camera and 3.10.17.
I **don't** have udev-cache configured.
Regards,
Eric
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mxc_v4l2_capture sometimes not being modprobed
2014-06-06 23:10 ` Eric Nelson
@ 2014-06-08 15:51 ` John Weber
2014-06-09 13:51 ` Otavio Salvador
0 siblings, 1 reply; 23+ messages in thread
From: John Weber @ 2014-06-08 15:51 UTC (permalink / raw)
To: Eric Nelson, Otavio Salvador; +Cc: meta-freescale
Thanks Eric,
On 6/6/14, 6:10 PM, Eric Nelson wrote:
> Hi John,
>
> On 06/05/2014 01:33 PM, Eric Nelson wrote:
>> On 06/05/2014 01:30 PM, John Weber wrote:
>>> <snip>
>>>
>>> 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?
>>>
>> I've kinda followed this thread, but I'm kinda buried and it will take
>> a day or two for me to confirm or deny this.
>>
> I just tested across a dozen assorted reboots/resets/power-cycles
> and didn't see the issue with an OV5642 parallel camera and 3.10.17.
>
> I **don't** have udev-cache configured.
I suspect that we will need to disable it on Wandboard as well.
>
> Regards,
>
>
> Eric
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mxc_v4l2_capture sometimes not being modprobed
2014-06-08 15:51 ` John Weber
@ 2014-06-09 13:51 ` Otavio Salvador
2014-06-09 13:52 ` Otavio Salvador
0 siblings, 1 reply; 23+ messages in thread
From: Otavio Salvador @ 2014-06-09 13:51 UTC (permalink / raw)
To: John Weber; +Cc: meta-freescale
On Sun, Jun 8, 2014 at 12:51 PM, John Weber <rjohnweber@gmail.com> wrote:
> On 6/6/14, 6:10 PM, Eric Nelson wrote:
>> On 06/05/2014 01:33 PM, Eric Nelson wrote:
>>> On 06/05/2014 01:30 PM, John Weber wrote:
>>>>
>>>> <snip>
>>>>
>>>> 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?
>>>>
>>> I've kinda followed this thread, but I'm kinda buried and it will take
>>> a day or two for me to confirm or deny this.
>>>
>> I just tested across a dozen assorted reboots/resets/power-cycles
>> and didn't see the issue with an OV5642 parallel camera and 3.10.17.
>>
>> I **don't** have udev-cache configured.
>
> I suspect that we will need to disable it on Wandboard as well.
This is not a good fix.
I added a patch, for OE-Core/Poky, attached; please confirm it fixes it.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mxc_v4l2_capture sometimes not being modprobed
2014-06-09 13:51 ` Otavio Salvador
@ 2014-06-09 13:52 ` Otavio Salvador
2014-06-09 16:00 ` John Weber
2014-06-09 17:16 ` Eric Nelson
0 siblings, 2 replies; 23+ messages in thread
From: Otavio Salvador @ 2014-06-09 13:52 UTC (permalink / raw)
To: John Weber; +Cc: meta-freescale
[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]
On Mon, Jun 9, 2014 at 10:51 AM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Sun, Jun 8, 2014 at 12:51 PM, John Weber <rjohnweber@gmail.com> wrote:
>> On 6/6/14, 6:10 PM, Eric Nelson wrote:
>>> On 06/05/2014 01:33 PM, Eric Nelson wrote:
>>>> On 06/05/2014 01:30 PM, John Weber wrote:
>>>>>
>>>>> <snip>
>>>>>
>>>>> 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?
>>>>>
>>>> I've kinda followed this thread, but I'm kinda buried and it will take
>>>> a day or two for me to confirm or deny this.
>>>>
>>> I just tested across a dozen assorted reboots/resets/power-cycles
>>> and didn't see the issue with an OV5642 parallel camera and 3.10.17.
>>>
>>> I **don't** have udev-cache configured.
>>
>> I suspect that we will need to disable it on Wandboard as well.
>
> This is not a good fix.
>
> I added a patch, for OE-Core/Poky, attached; please confirm it fixes it.
Oops!
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
[-- Attachment #2: 0001-udev-Trigger-platform-events-for-udev-cache.patch --]
[-- Type: text/x-patch, Size: 1738 bytes --]
From 0d1eaebf86a79089c71eb59711e83e0ca23d8b84 Mon Sep 17 00:00:00 2001
From: Otavio Salvador <otavio@ossystems.com.br>
Date: Mon, 9 Jun 2014 10:48:59 -0300
Subject: [PATCH] udev: Trigger platform events for udev-cache
Organization: O.S. Systems Software LTDA.
Some embedded boards need to have the platform events triggered so the
platform specific drivers are loaded.
This has been found when testing a camera module in Wandboard Quad.
Reported-by: John Weber <rjohnweber@gmail.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
meta/recipes-core/udev/udev/init | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/udev/udev/init b/meta/recipes-core/udev/udev/init
index 410a650..649109c 100644
--- a/meta/recipes-core/udev/udev/init
+++ b/meta/recipes-core/udev/udev/init
@@ -102,7 +102,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 --subsystem-nomatch=pci_bus --subsystem-nomatch=graphics --subsystem-nomatch=backlight --subsystem-nomatch=video4linux --subsystem-nomatch=platform
+ udevadm trigger --action=add --subsystem-nomatch=tty --subsystem-nomatch=mem --subsystem-nomatch=vc --subsystem-nomatch=vtconsole --subsystem-nomatch=misc --subsystem-nomatch=dcon --subsystem-nomatch=pci_bus --subsystem-nomatch=graphics --subsystem-nomatch=backlight --subsystem-nomatch=video4linux
(udevadm settle --timeout=3; udevadm control --env=STARTUP=)&
else
udevadm trigger --action=add
--
2.0.0.rc4
^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: mxc_v4l2_capture sometimes not being modprobed
2014-06-09 13:52 ` Otavio Salvador
@ 2014-06-09 16:00 ` John Weber
2014-06-09 17:16 ` Eric Nelson
1 sibling, 0 replies; 23+ messages in thread
From: John Weber @ 2014-06-09 16:00 UTC (permalink / raw)
To: Otavio Salvador; +Cc: meta-freescale
Hi Otavio,
On 6/9/14, 8:52 AM, Otavio Salvador wrote:
> On Mon, Jun 9, 2014 at 10:51 AM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> On Sun, Jun 8, 2014 at 12:51 PM, John Weber <rjohnweber@gmail.com> wrote:
>>> On 6/6/14, 6:10 PM, Eric Nelson wrote:
>>>> On 06/05/2014 01:33 PM, Eric Nelson wrote:
>>>>> On 06/05/2014 01:30 PM, John Weber wrote:
>>>>>> <snip>
>>>>>>
>>>>>> 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?
>>>>>>
>>>>> I've kinda followed this thread, but I'm kinda buried and it will take
>>>>> a day or two for me to confirm or deny this.
>>>>>
>>>> I just tested across a dozen assorted reboots/resets/power-cycles
>>>> and didn't see the issue with an OV5642 parallel camera and 3.10.17.
>>>>
>>>> I **don't** have udev-cache configured.
>>> I suspect that we will need to disable it on Wandboard as well.
>> This is not a good fix.
>>
>> I added a patch, for OE-Core/Poky, attached; please confirm it fixes it.
> Oops!
>
Thanks! From my testing this will work.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mxc_v4l2_capture sometimes not being modprobed
2014-06-09 13:52 ` Otavio Salvador
2014-06-09 16:00 ` John Weber
@ 2014-06-09 17:16 ` Eric Nelson
2014-06-09 17:35 ` John Weber
1 sibling, 1 reply; 23+ messages in thread
From: Eric Nelson @ 2014-06-09 17:16 UTC (permalink / raw)
To: Otavio Salvador, John Weber; +Cc: meta-freescale
Hi all,
On 06/09/2014 06:52 AM, Otavio Salvador wrote:
> On Mon, Jun 9, 2014 at 10:51 AM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> On Sun, Jun 8, 2014 at 12:51 PM, John Weber <rjohnweber@gmail.com> wrote:
>>> On 6/6/14, 6:10 PM, Eric Nelson wrote:
>>>> On 06/05/2014 01:33 PM, Eric Nelson wrote:
>>>>> On 06/05/2014 01:30 PM, John Weber wrote:
>>>>>>
>>>>>> <snip>
>>>>>>
>>>>>> 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?
>>>>>>
>>>>> I've kinda followed this thread, but I'm kinda buried and it will take
>>>>> a day or two for me to confirm or deny this.
>>>>>
>>>> I just tested across a dozen assorted reboots/resets/power-cycles
>>>> and didn't see the issue with an OV5642 parallel camera and 3.10.17.
>>>>
>>>> I **don't** have udev-cache configured.
>>>
>>> I suspect that we will need to disable it on Wandboard as well.
>>
>> This is not a good fix.
>>
>> I added a patch, for OE-Core/Poky, attached; please confirm it fixes it.
>
I just tested again on an image with udev-cache, and don't see any
issues on a Nitrogen6x board (CSI camera).
I'm not sure what's different about my environment.
Regards,
Eric
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mxc_v4l2_capture sometimes not being modprobed
2014-06-09 17:16 ` Eric Nelson
@ 2014-06-09 17:35 ` John Weber
2014-06-09 17:49 ` Eric Nelson
0 siblings, 1 reply; 23+ messages in thread
From: John Weber @ 2014-06-09 17:35 UTC (permalink / raw)
To: Eric Nelson, Otavio Salvador; +Cc: meta-freescale
Hi Eric,
On 6/9/14, 12:16 PM, Eric Nelson wrote:
> Hi all,
>
> On 06/09/2014 06:52 AM, Otavio Salvador wrote:
>> On Mon, Jun 9, 2014 at 10:51 AM, Otavio Salvador
>> <otavio@ossystems.com.br> wrote:
>>> On Sun, Jun 8, 2014 at 12:51 PM, John Weber <rjohnweber@gmail.com> wrote:
>>>> On 6/6/14, 6:10 PM, Eric Nelson wrote:
>>>>> On 06/05/2014 01:33 PM, Eric Nelson wrote:
>>>>>> On 06/05/2014 01:30 PM, John Weber wrote:
>>>>>>> <snip>
>>>>>>>
>>>>>>> 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?
>>>>>>>
>>>>>> I've kinda followed this thread, but I'm kinda buried and it will take
>>>>>> a day or two for me to confirm or deny this.
>>>>>>
>>>>> I just tested across a dozen assorted reboots/resets/power-cycles
>>>>> and didn't see the issue with an OV5642 parallel camera and 3.10.17.
>>>>>
>>>>> I **don't** have udev-cache configured.
>>>> I suspect that we will need to disable it on Wandboard as well.
>>> This is not a good fix.
>>>
>>> I added a patch, for OE-Core/Poky, attached; please confirm it fixes it.
> I just tested again on an image with udev-cache, and don't see any
> issues on a Nitrogen6x board (CSI camera).
>
> I'm not sure what's different about my environment.
>
> Regards,
>
>
> Eric
>
Not sure either, but are you testing with the parallel CSI or MIPI CSI camera?
Could there be a difference in the how the drivers are loaded?
John
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mxc_v4l2_capture sometimes not being modprobed
2014-06-09 17:35 ` John Weber
@ 2014-06-09 17:49 ` Eric Nelson
2014-06-09 17:59 ` John Weber
0 siblings, 1 reply; 23+ messages in thread
From: Eric Nelson @ 2014-06-09 17:49 UTC (permalink / raw)
To: John Weber, Otavio Salvador; +Cc: meta-freescale
Hi John,
On 06/09/2014 10:35 AM, John Weber wrote:
> Hi Eric,
>
> On 6/9/14, 12:16 PM, Eric Nelson wrote:
>> Hi all,
>>
>> On 06/09/2014 06:52 AM, Otavio Salvador wrote:
>>> On Mon, Jun 9, 2014 at 10:51 AM, Otavio Salvador
>>> <otavio@ossystems.com.br> wrote:
>>>> On Sun, Jun 8, 2014 at 12:51 PM, John Weber <rjohnweber@gmail.com>
>>>> wrote:
>>>>> On 6/6/14, 6:10 PM, Eric Nelson wrote:
>>>>>> On 06/05/2014 01:33 PM, Eric Nelson wrote:
>>>>>>> On 06/05/2014 01:30 PM, John Weber wrote:
>>>>>>>> <snip>
>>>>>>>>
>>>>>>>> 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?
>>>>>>>>
>>>>>>> I've kinda followed this thread, but I'm kinda buried and it will
>>>>>>> take
>>>>>>> a day or two for me to confirm or deny this.
>>>>>>>
>>>>>> I just tested across a dozen assorted reboots/resets/power-cycles
>>>>>> and didn't see the issue with an OV5642 parallel camera and 3.10.17.
>>>>>>
>>>>>> I **don't** have udev-cache configured.
>>>>> I suspect that we will need to disable it on Wandboard as well.
>>>> This is not a good fix.
>>>>
>>>> I added a patch, for OE-Core/Poky, attached; please confirm it fixes
>>>> it.
>> I just tested again on an image with udev-cache, and don't see any
>> issues on a Nitrogen6x board (CSI camera).
>>
>> I'm not sure what's different about my environment.
>>
>> Regards,
>>
>>
>> Eric
>>
> Not sure either, but are you testing with the parallel CSI or MIPI CSI
> camera? Could there be a difference in the how the drivers are loaded?
>
I tested using parallel CSI.
AFAIK, the driver load process is the same for both.
Regards,
Eric
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mxc_v4l2_capture sometimes not being modprobed
2014-06-09 17:49 ` Eric Nelson
@ 2014-06-09 17:59 ` John Weber
2014-06-09 18:09 ` Eric Nelson
0 siblings, 1 reply; 23+ messages in thread
From: John Weber @ 2014-06-09 17:59 UTC (permalink / raw)
To: Eric Nelson, Otavio Salvador; +Cc: meta-freescale
Hi Eric,
On 6/9/14, 12:49 PM, Eric Nelson wrote:
> Hi John,
>
> On 06/09/2014 10:35 AM, John Weber wrote:
>> Hi Eric,
>>
>> On 6/9/14, 12:16 PM, Eric Nelson wrote:
>>> Hi all,
>>>
>>> On 06/09/2014 06:52 AM, Otavio Salvador wrote:
>>>> On Mon, Jun 9, 2014 at 10:51 AM, Otavio Salvador
>>>> <otavio@ossystems.com.br> wrote:
>>>>> On Sun, Jun 8, 2014 at 12:51 PM, John Weber <rjohnweber@gmail.com>
>>>>> wrote:
>>>>>> On 6/6/14, 6:10 PM, Eric Nelson wrote:
>>>>>>> On 06/05/2014 01:33 PM, Eric Nelson wrote:
>>>>>>>> On 06/05/2014 01:30 PM, John Weber wrote:
>>>>>>>>> <snip>
>>>>>>>>>
>>>>>>>>> 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?
>>>>>>>>>
>>>>>>>> I've kinda followed this thread, but I'm kinda buried and it will
>>>>>>>> take
>>>>>>>> a day or two for me to confirm or deny this.
>>>>>>>>
>>>>>>> I just tested across a dozen assorted reboots/resets/power-cycles
>>>>>>> and didn't see the issue with an OV5642 parallel camera and 3.10.17.
>>>>>>>
>>>>>>> I **don't** have udev-cache configured.
>>>>>> I suspect that we will need to disable it on Wandboard as well.
>>>>> This is not a good fix.
>>>>>
>>>>> I added a patch, for OE-Core/Poky, attached; please confirm it fixes
>>>>> it.
>>> I just tested again on an image with udev-cache, and don't see any
>>> issues on a Nitrogen6x board (CSI camera).
>>>
>>> I'm not sure what's different about my environment.
>>>
>>> Regards,
>>>
>>>
>>> Eric
>>>
>> Not sure either, but are you testing with the parallel CSI or MIPI CSI
>> camera? Could there be a difference in the how the drivers are loaded?
>>
> I tested using parallel CSI.
>
> AFAIK, the driver load process is the same for both.
>
> Regards,
>
>
> Eric
OK. I don't think our environments are very different, so I suspect that it
might be one of the few kernel enhancements that you've made.
BTW - did you disable udev-cache by default? If so where did you do this in Yocto?
John
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: mxc_v4l2_capture sometimes not being modprobed
2014-06-09 17:59 ` John Weber
@ 2014-06-09 18:09 ` Eric Nelson
0 siblings, 0 replies; 23+ messages in thread
From: Eric Nelson @ 2014-06-09 18:09 UTC (permalink / raw)
To: John Weber, Otavio Salvador; +Cc: meta-freescale
Hi John,
On 06/09/2014 10:59 AM, John Weber wrote:
> Hi Eric,
>
> On 6/9/14, 12:49 PM, Eric Nelson wrote:
>> Hi John,
>>
>> On 06/09/2014 10:35 AM, John Weber wrote:
>>> Hi Eric,
>>>
>>> On 6/9/14, 12:16 PM, Eric Nelson wrote:
>>>> Hi all,
>>>>
>>>> On 06/09/2014 06:52 AM, Otavio Salvador wrote:
>>>>> On Mon, Jun 9, 2014 at 10:51 AM, Otavio Salvador
>>>>> <otavio@ossystems.com.br> wrote:
>>>>>> On Sun, Jun 8, 2014 at 12:51 PM, John Weber <rjohnweber@gmail.com>
>>>>>> wrote:
>>>>>>> On 6/6/14, 6:10 PM, Eric Nelson wrote:
>>>>>>>> On 06/05/2014 01:33 PM, Eric Nelson wrote:
>>>>>>>>> On 06/05/2014 01:30 PM, John Weber wrote:
>>>>>>>>>> <snip>
>>>>>>>>>>
>>>>>>>>>> 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?
>>>>>>>>>>
>>>>>>>>> I've kinda followed this thread, but I'm kinda buried and it will
>>>>>>>>> take
>>>>>>>>> a day or two for me to confirm or deny this.
>>>>>>>>>
>>>>>>>> I just tested across a dozen assorted reboots/resets/power-cycles
>>>>>>>> and didn't see the issue with an OV5642 parallel camera and
>>>>>>>> 3.10.17.
>>>>>>>>
>>>>>>>> I **don't** have udev-cache configured.
>>>>>>> I suspect that we will need to disable it on Wandboard as well.
>>>>>> This is not a good fix.
>>>>>>
>>>>>> I added a patch, for OE-Core/Poky, attached; please confirm it fixes
>>>>>> it.
>>>> I just tested again on an image with udev-cache, and don't see any
>>>> issues on a Nitrogen6x board (CSI camera).
>>>>
>>>> I'm not sure what's different about my environment.
>>>>
>>>> Regards,
>>>>
>>>>
>>>> Eric
>>>>
>>> Not sure either, but are you testing with the parallel CSI or MIPI CSI
>>> camera? Could there be a difference in the how the drivers are loaded?
>>>
>> I tested using parallel CSI.
>>
>> AFAIK, the driver load process is the same for both.
>>
>> Regards,
>>
>>
>> Eric
> OK. I don't think our environments are very different, so I suspect
> that it might be one of the few kernel enhancements that you've made.
>
> BTW - did you disable udev-cache by default? If so where did you do
> this in Yocto?
>
This was purely un-intentional. I think I was working with a build that
started with core-image-minimal.
Regards,
Eric
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2014-06-09 18:09 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-26 3:42 mxc_v4l2_capture sometimes not being modprobed John Weber
2014-06-05 17:34 ` Otavio Salvador
2014-06-05 18:05 ` John Weber
2014-06-05 18:08 ` Otavio Salvador
2014-06-05 18:14 ` John Weber
2014-06-05 18:17 ` Otavio Salvador
2014-06-05 18:23 ` John Weber
2014-06-05 18:38 ` Otavio Salvador
2014-06-05 19:10 ` John Weber
2014-06-05 19:34 ` Otavio Salvador
2014-06-05 20:30 ` John Weber
2014-06-05 20:33 ` Eric Nelson
2014-06-05 20:40 ` John Weber
2014-06-06 23:10 ` Eric Nelson
2014-06-08 15:51 ` John Weber
2014-06-09 13:51 ` Otavio Salvador
2014-06-09 13:52 ` Otavio Salvador
2014-06-09 16:00 ` John Weber
2014-06-09 17:16 ` Eric Nelson
2014-06-09 17:35 ` John Weber
2014-06-09 17:49 ` Eric Nelson
2014-06-09 17:59 ` John Weber
2014-06-09 18:09 ` Eric Nelson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.