2010/2/8 Erik Andrén <erik.andren@xxxxxxxxx>: > 2010/2/6 Lukáš Karas <lukas.karas@xxxxxxxxxx>: >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
