New kernel failed suspend ro ram with m5602 camera

New kernel failed suspend ro ram with m5602 camera

[Lukáš Karas]

Hi Erik and others. 

New kernel (2.6.33-rc*) failed suspend to ram with camera m5602 on my machine. 
At first, I thought that it's a kernel bug (see 
http://bugzilla.kernel.org/show_bug.cgi?id=15189) - suspend failed after 
unload gspca_m5602 module too. But it is more probably a hardware bug, that we 
can evade with simple udev rule

ATTR{idVendor}=="0402", ATTR{idProduct}=="5602", ATTR{power/wakeup}="disabled"

I sent this rule to linux-hotplug (udev) mailing list, but answer is 
(http://www.spinics.net/lists/hotplug/msg03353.html) that this quirk should be 
in camera driver or should be send to udev from v4l developers...

What do you thing about it? It is a general m5602 chip problem or only my 
hardware combination problem? How we can put rule into udev userspace library? 
What I know, in v4l repository isn't directory with general v4l rules. This 
problem can affect many users with this hardware...

Best regards, 
Lukas

Re: New kernel failed suspend ro ram with m5602 camera

[Erik Andrén]

2010/2/6 Lukáš Karas <lukas.karas@centrum.cz>:
> Hi Erik and others.
>
> New kernel (2.6.33-rc*) failed suspend to ram with camera m5602 on my machine.
> At first, I thought that it's a kernel bug (see
> http://bugzilla.kernel.org/show_bug.cgi?id=15189) - suspend failed after
> unload gspca_m5602 module too. But it is more probably a hardware bug, that we
> can evade with simple udev rule
>
> ATTR{idVendor}=="0402", ATTR{idProduct}=="5602", ATTR{power/wakeup}="disabled"
>
> I sent this rule to linux-hotplug (udev) mailing list, but answer is
> (http://www.spinics.net/lists/hotplug/msg03353.html) that this quirk should be
> in camera driver or should be send to udev from v4l developers...
>
> What do you thing about it? It is a general m5602 chip problem or only my
> hardware combination problem?
Hi Lukas,

I haven't experienced it so far, but I haven't tried the latest kernel.
I'll see if I can manage to reproduce the problem later this week.

> How we can put rule into udev userspace library?
> What I know, in v4l repository isn't directory with general v4l rules. This
> problem can affect many users with this hardware...

We should definitely try to solve this in the camera driver if possible.
Would it be possible for you to bisect the kernel tree to see what
commit that caused this regression?

Best regards,
Erik

>
> Best regards,
> Lukas
>

Re: New kernel failed suspend ro ram with m5602 camera

[Erik Andrén]

2010/2/8 Erik Andrén <erik.andren@gmail.com>:
> 2010/2/6 Lukáš Karas <lukas.karas@centrum.cz>:
>> Hi Erik and others.
>>
>> New kernel (2.6.33-rc*) failed suspend to ram with camera m5602 on my machine.
>> At first, I thought that it's a kernel bug (see
>> http://bugzilla.kernel.org/show_bug.cgi?id=15189) - suspend failed after
>> unload gspca_m5602 module too. But it is more probably a hardware bug, that we
>> can evade with simple udev rule
>>
>> ATTR{idVendor}=="0402", ATTR{idProduct}=="5602", ATTR{power/wakeup}="disabled"
>>
>> I sent this rule to linux-hotplug (udev) mailing list, but answer is
>> (http://www.spinics.net/lists/hotplug/msg03353.html) that this quirk should be
>> in camera driver or should be send to udev from v4l developers...
>>
>> What do you thing about it? It is a general m5602 chip problem or only my
>> hardware combination problem?
> Hi Lukas,
>
> I haven't experienced it so far, but I haven't tried the latest kernel.
> I'll see if I can manage to reproduce the problem later this week.
>
>> How we can put rule into udev userspace library?
>> What I know, in v4l repository isn't directory with general v4l rules. This
>> problem can affect many users with this hardware...
>
> We should definitely try to solve this in the camera driver if possible.
> Would it be possible for you to bisect the kernel tree to see what
> commit that caused this regression?
>
> Best regards,
> Erik
>
>>
>> Best regards,
>> Lukas
>>
>

Hi Lukas,
I cannot reproduce this issue with the linux tip kernel. AFAICT, this
issue only exists with the m5602 connected to a s5k83a sensor. I'm not
sure what the correct solution to this problem is but it would greatly
help if you could perform a git bisect and try to identify what commit
caused this issue.

Best regards,
Erik