Re: [RFCv1 PATCH 1/7] gspca: allow subdrivers to use the control framework.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 05/05/2012 04:50 PM, Hans Verkuil wrote:
On Sat May 5 2012 16:46:32 Hans de Goede wrote:
Hi,

On 05/05/2012 10:34 AM, Hans Verkuil wrote:
On Sat May 5 2012 09:43:01 Hans de Goede wrote:
Hi,

I'm slowly working my way though this series today (both review, as well
as some tweaks and testing).

Thanks for that!

One note: I initialized the controls in sd_init. That's wrong, it should be
sd_config. sd_init is also called on resume, so that would initialize the
controls twice.

You cannot move the initializing of the controls to sd_config, since in many
cases the sensor probing is done in sd_init, and we need to know the sensor
type to init the controls.

Or you move the sensor probing to sd_config as I did. It makes no sense
anyway to do sensor probing every time you resume.

Unless there is another good reason for doing the probing in sd_init I prefer
to move it to sd_config.

Sensor probing does more then just sensor probing, it also configures
things like the i2c clockrate, and if the bus between bridge and sensor
is spi / i2c or 3-wire, or whatever ...

After a suspend resume all bets are of wrt bridge state, so we prefer to
always do a full re-init as we do on initial probe, so that we (hopefully)
will put the bridge back in a sane state.

I think moving the probing from init to config is a bad idea, the chance
that we will get regressions (after a suspend/resume) from this are too
big IMHO.

Regards,

Hans
--
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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux