| Message ID | 20230607164712.63579-15-hdegoede@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | media: ov2680: Bugfixes + ACPI + selection(crop-tgt) API support | expand |
On Wed, Jun 07, 2023 at 06:46:58PM +0200, Hans de Goede wrote: > On ACPI systems the following 2 scenarios are possible: > > 1. The xvclk is fully controlled by ACPI powermanagement, so there > is no "xvclk" for the driver to get (since it is abstracted away). > In this case there will be a "clock-frequency" device property > to tell the driver the xvclk rate. > > 2. There is a xvclk modelled in the clk framework for the driver, > but the clk-generator may not be set to the right frequency > yet. In this case there will also be a "clock-frequency" device > property and the driver is expected to set the rate of the xvclk > through this frequency through the clk framework. > > Handle both these scenarios by switching to devm_clk_get_optional() > and checking for a "clock-frequency" device property. > > This is modelled after how this same issues was fixed for the ov8865 in this --> the > commit 73dcffeb2ff9 ("media: i2c: Support 19.2MHz input clock in ov8865"). ... > + /* > + * We could have either a 24MHz or 19.2MHz clock rate from either dt or DT > + * ACPI...but we also need to support the weird IPU3 case which will ACPI... but > + * have an external clock AND a clock-frequency property. Check for the > + * clock-frequency property and if found, set that rate if we managed > + * to acquire a clock. This should cover the ACPI case. If the system > + * uses devicetree then the configured rate should already be set, so > + * we can just read it. > + */ > + ret = fwnode_property_read_u32(dev_fwnode(dev), "clock-frequency", &rate); if (ret && !sensor->xvclk) return dev_err_probe(dev, ret, "invalid clock config\n"); ('else' is redundant) > + if (!ret && sensor->xvclk) { > + ret = clk_set_rate(sensor->xvclk, rate); > + if (ret) > + return dev_err_probe(dev, ret, "failed to set clock rate\n"); > + } else if (ret && !sensor->xvclk) { > + return dev_err_probe(dev, ret, "invalid clock config\n"); > + } ... > + sensor->xvclk_freq = rate ? rate : clk_get_rate(sensor->xvclk); Elvis can be used: sensor->xvclk_freq = rate ?: clk_get_rate(sensor->xvclk);
diff --git a/drivers/media/i2c/ov2680.c b/drivers/media/i2c/ov2680.c index d04336d9c3ce..81d59206f901 100644 --- a/drivers/media/i2c/ov2680.c +++ b/drivers/media/i2c/ov2680.c @@ -676,6 +676,7 @@ static int ov2680_check_id(struct ov2680_dev *sensor) static int ov2680_parse_dt(struct ov2680_dev *sensor) { struct device *dev = sensor->dev; + unsigned int rate = 0; int ret; /* @@ -694,13 +695,31 @@ static int ov2680_parse_dt(struct ov2680_dev *sensor) return ret; } - sensor->xvclk = devm_clk_get(dev, "xvclk"); + sensor->xvclk = devm_clk_get_optional(dev, "xvclk"); if (IS_ERR(sensor->xvclk)) { dev_err(dev, "xvclk clock missing or invalid\n"); return PTR_ERR(sensor->xvclk); } - sensor->xvclk_freq = clk_get_rate(sensor->xvclk); + /* + * We could have either a 24MHz or 19.2MHz clock rate from either dt or + * ACPI...but we also need to support the weird IPU3 case which will + * have an external clock AND a clock-frequency property. Check for the + * clock-frequency property and if found, set that rate if we managed + * to acquire a clock. This should cover the ACPI case. If the system + * uses devicetree then the configured rate should already be set, so + * we can just read it. + */ + ret = fwnode_property_read_u32(dev_fwnode(dev), "clock-frequency", &rate); + if (!ret && sensor->xvclk) { + ret = clk_set_rate(sensor->xvclk, rate); + if (ret) + return dev_err_probe(dev, ret, "failed to set clock rate\n"); + } else if (ret && !sensor->xvclk) { + return dev_err_probe(dev, ret, "invalid clock config\n"); + } + + sensor->xvclk_freq = rate ? rate : clk_get_rate(sensor->xvclk); if (sensor->xvclk_freq != OV2680_XVCLK_VALUE) { dev_err(dev, "wrong xvclk frequency %d HZ, expected: %d Hz\n", sensor->xvclk_freq, OV2680_XVCLK_VALUE);
On ACPI systems the following 2 scenarios are possible: 1. The xvclk is fully controlled by ACPI powermanagement, so there is no "xvclk" for the driver to get (since it is abstracted away). In this case there will be a "clock-frequency" device property to tell the driver the xvclk rate. 2. There is a xvclk modelled in the clk framework for the driver, but the clk-generator may not be set to the right frequency yet. In this case there will also be a "clock-frequency" device property and the driver is expected to set the rate of the xvclk through this frequency through the clk framework. Handle both these scenarios by switching to devm_clk_get_optional() and checking for a "clock-frequency" device property. This is modelled after how this same issues was fixed for the ov8865 in commit 73dcffeb2ff9 ("media: i2c: Support 19.2MHz input clock in ov8865"). Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- drivers/media/i2c/ov2680.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-)