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