Lines Matching +full:power +full:- +full:sensor

1 .. SPDX-License-Identifier: GPL-2.0
3 Writing camera sensor drivers
6 CSI-2
7 -----
12 ---------------
23 elsewhere. Therefore only the pre-determined frequencies are configurable by the
27 ----------
32 Freely configurable camera sensor drivers
35 Freely configurable camera sensor drivers expose the device's internal
36 processing pipeline as one or more sub-devices with different cropping and
51 Most sensor drivers are implemented this way, see e.g.
55 ----------------------------
65 a result of the configuration of a number of camera sensor implementation
80 pixel rate is specified by ``V4L2_CID_PIXEL_RATE`` in the same sub-device. The
83 Register list based drivers need to implement read-only sub-device nodes for the
89 skipping, scaling or digital crop :ref:`v4l2-subdev-selections`.
100 Power management
101 ----------------
103 Always use runtime PM to manage the power states of your device. Camera sensor
105 controlling the power state of the device they otherwise control as well. In
109 Existing camera sensor drivers may rely on the old
110 :c:type:`v4l2_subdev_core_ops`->s_power() callback for bridge or ISP drivers to
111 manage their power state. This is however **deprecated**. If you feel you need
113 runtime PM support to the sensor driver you are using. Likewise, new drivers
117 ``drivers/media/i2c/smiapp/smiapp-core.c``. The two drivers work in both ACPI
124 PM ``runtime_resume`` callback, as it has no way to figure out the power state
125 of the device. This is because the power state of the device is only changed
126 after the power state transition has taken place. The ``s_ctrl`` callback can be
127 used to obtain device's power state after the power state transition:
132 The function returns a non-zero value if it succeeded getting the power count or