2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-27 06:34:11 +08:00

media: Documentation: media: Document clock handling in camera sensor drivers

Document pratices of handling clocks in camera sensor drivers on both DT
and ACPI.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This commit is contained in:
Sakari Ailus 2020-12-11 18:56:04 +01:00 committed by Mauro Carvalho Chehab
parent 3ef5e42d28
commit 2225cf4492

View File

@ -15,7 +15,7 @@ Camera sensors have an internal clock tree including a PLL and a number of
divisors. The clock tree is generally configured by the driver based on a few
input parameters that are specific to the hardware:: the external clock frequency
and the link frequency. The two parameters generally are obtained from system
firmware. No other frequencies should be used in any circumstances.
firmware. **No other frequencies should be used in any circumstances.**
The reason why the clock frequencies are so important is that the clock signals
come out of the SoC, and in many cases a specific frequency is designed to be
@ -23,6 +23,24 @@ used in the system. Using another frequency may cause harmful effects
elsewhere. Therefore only the pre-determined frequencies are configurable by the
user.
ACPI
~~~~
Read the "clock-frequency" _DSD property to denote the frequency. The driver can
rely on this frequency being used.
Devicetree
~~~~~~~~~~
The currently preferred way to achieve this is using "assigned-clock-rates"
property. See Documentation/devicetree/bindings/clock/clock-bindings.txt for
more information. The driver then gets the frequency using clk_get_rate().
This approach has the drawback that there's no guarantee that the frequency
hasn't been modified directly or indirectly by another driver, or supported by
the board's clock tree to begin with. Changes to the Common Clock Framework API
are required to ensure reliability.
Frame size
----------