Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver

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

 



Hello.

+static int omap34xxcam_open(struct inode *inode, struct file *file)
+{

<snip>

+       if (atomic_inc_return(&vdev->users) == 1) {
+               isp_get();
+               if (omap34xxcam_slave_power_set(vdev, V4L2_POWER_ON,
+                                               OMAP34XXCAM_SLAVE_POWER_ALL))
+                       goto out_slave_power_set_standby;
+               omap34xxcam_slave_power_set(
+                       vdev, V4L2_POWER_STANDBY,
+                       OMAP34XXCAM_SLAVE_POWER_SENSOR);
+               omap34xxcam_slave_power_suggest(
+                       vdev, V4L2_POWER_STANDBY,
+                       OMAP34XXCAM_SLAVE_POWER_LENS);
+       }


I'm wondering whether this V4L2_POWER_STANDBY operation for sensor
device is really necessary.

Because if that makes sensor device in standby mode, we do S_FMT and
bunch of V4L2 APIs while the camera module is in standby mode.

In most cases of "sensor + ISP" SOC camera modules, I2C command is not
working while the camera module is in standby mode.

Following the camera interface source code, sensor goes down to
standby mode until VIDIOC_STREAMON is called.

If this power up timing depends on sensor device, then I think we need
a conditional power on sequence.

As you defined slave devices as SENSOR, LENS, FLASH, then how about
making a new slave category like "ISP" for "sensor+ISP" SOC modules?

Then we could make slave devices with conditional cases.
Cheers.


Regards,
Nate
--
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