Hi,
On Fri, Apr 20, 2018 at 11:44:19AM +0200, Daniel Mack wrote:
> Allow setting the xclk rate via an optional 'clock-frequency' property in
> the device tree node.
>
> Signed-off-by: Daniel Mack <daniel@xxxxxxxxxx>
> ---
> Documentation/devicetree/bindings/media/i2c/ov5640.txt | 2 ++
> drivers/media/i2c/ov5640.c | 10 ++++++++++
> 2 files changed, 12 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5640.txt b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
> index 8e36da0d8406..584bbc944978 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ov5640.txt
> +++ b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
> @@ -13,6 +13,8 @@ Optional Properties:
> This is an active low signal to the OV5640.
> - powerdown-gpios: reference to the GPIO connected to the powerdown pin,
> if any. This is an active high signal to the OV5640.
> +- clock-frequency: frequency to set on the xclk input clock. The clock
> + is left untouched if this property is missing.
This can be done through assigned-clocks, right?
> The device node must contain one 'port' child node for its digital output
> video port, in accordance with the video interface bindings defined in
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index 78669ed386cd..2d94d6dbda5d 100644
> --- a/drivers/media/i2c/ov5640.c
> +++ b/drivers/media/i2c/ov5640.c
> @@ -2685,6 +2685,7 @@ static int ov5640_probe(struct i2c_client *client,
> struct fwnode_handle *endpoint;
> struct ov5640_dev *sensor;
> struct v4l2_mbus_framefmt *fmt;
> + u32 freq;
> int ret;
>
> sensor = devm_kzalloc(dev, sizeof(*sensor), GFP_KERNEL);
> @@ -2731,6 +2732,15 @@ static int ov5640_probe(struct i2c_client *client,
> return PTR_ERR(sensor->xclk);
> }
>
> + ret = of_property_read_u32(dev->of_node, "clock-frequency", &freq);
> + if (ret == 0) {
> + ret = clk_set_rate(sensor->xclk, freq);
> + if (ret) {
> + dev_err(dev, "could not set xclk frequency\n");
> + return ret;
> + }
> + }
> +
I'm wondering what the use case for that would be. The clock rate is
subject to various changes depending on the resolution and framerate
used, so that's very likely to change. Wouldn't we be better off to
simply try to change the rate at runtime, depending on those factors?
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
Attachment:
signature.asc
Description: PGP signature
