2009/7/12 Hans Verkuil <hverkuil@xxxxxxxxx>:
> On Saturday 11 July 2009 13:02:33 Dongsoo, Nathaniel Kim wrote:
>> Hi,
>>
>> The thing is - Is it possible to make the subdev device not to be
>> turned on in registering process using any of v4l2_i2c_new_subdev*** ?
>> You can say that I can ignore the i2c errors in booting process, but I
>> think it is not a pretty way.
>>
>> And for the reason I'm asking you about this, I need you to consider
>> following conditions I carry.
>>
>> 1. ARM embedded platform especially mobile handset.
>> 2. Mass production which is very concerned about power consumption.
>> 3. Strict and automated test process in product line.
>>
>> So, what I want to ask you is about s_config subdev call which is
>> called from every single I2C subdev load in some kind of probe
>> procedure. As s_config is supposed to do, it tries to initialize
>> subdev device. which means it needs to turn on the subdev to make that
>> initialized.
>
> Actually, all s_config does is to pass the irq and platform_data arguments
> to the subdev driver. The subdev driver can just store that information
> somewhere and only use it when needed. It does not necessarily have to turn
> on the sub-device.
>
> Whether to just store this info or turn on the sub-device is something that
> each subdev driver writer has to decide.
>
> Note that this really has nothing to do with the existance of s_config:
> s_config was only introduced in order to support legacy v4l2 drivers and
> subdev drivers. In the (far?) future this will probably disappear and this
> information will always be passed via struct i2c_board_info.
>
>> But as I mentioned above if we make the product go through the product
>> line, it turns on the subdev device even though nobody intended to
>> turn the subdev on. It might be an issue in product vendor's point of
>> view, because there should be a crystal clear reason for the
>> consumption of power the subdev made. I'm working on camera device and
>> speaking of which, camera devices are really power consuming device
>> and some camera devices even take ages to be initialized as well.
>>
>> So far I hope I made a good explanation about why I'm asking you about
>> following question.
>> By the way, it seems to be similar to the issue I've faced whe using
>> old i2c driver model..I mean probing i2c devices on boot up sequence.
>
> That at least should no longer be a problem anymore (as long as you don't
> use the address-probing variants).
>
> Regards,
>
> Hans
>
> --
> Hans Verkuil - video4linux developer - sponsored by TANDBERG
>
Hello Hans,
Actually I picked up s_config to make external camera module (subdev)
do initialization when we open camera device, but s_config seems to be
made for other purpose.
As you noted in comment for the "init" API, you recommended not to use
"init" subdev API and neither do I want to use any API to be removed.
So, I'm figuring out how to make camera device to be initialized under
subdev framework.
So, I re-checked the whole subdev API list we have in v4l2-subdev and
found s_crystal_freq.
Here is a question:
Is s_crystal_freq for let the subdev know about the given clock like
MCLK(master clock) for external camera device?
The thing is, if you are intending to get rid of the "init" subdev API
in the future and on the other hand some device like camera still
needs a direct way to be initialized, I think we can use one of API
which can be used during initializing process. I figured out that if
s_crystal_freq is for subdev to be noticed about the given clock
frequency to itself, it might be used for initialization programming
also.
Let's assume that I'm turning on the camera which is working with 24MHz MCLK.
1. power on
2. give 24MHz MCLK from host to camera and let camera know about the
frequency given through s_crystal_freq (even though the camera device
supports for only one frequency value)
3. reset device
4. preview on
If I'm getting wrong about s_crystal_freq, I think we need to keep
"init" for camera devices.
Cheers,
Nate
--
=
DongSoo, Nathaniel Kim
Engineer
Mobile S/W Platform Lab.
Digital Media & Communications R&D Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo.kim@xxxxxxxxx
dongsoo45.kim@xxxxxxxxxxx
--
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
