Hi,
sorry for late reply.
I copied this approach from looking at other camera sensor drivers,
and it seemed less "ugly" to me than using assigned-rates (I will be
upstreaming required dts changes for Samsung Galaxy A3 (2015), so the
dts feeling "proper" is important to me).
I however am not qualified to make that decision, so if you believe
that the assigned-rates approach is cleaner and more suitable for mainline,
I will try to adjust my internal filter for what is "more proper" :)
As for rounding, the issue is that it seems to like to round up, instead
of trying to find the closest possible value. I *guess* trying to set
the lower barrier might work out in practice, but it seems kind of ugly.
All in all, what I did seemed like the cleanest option to me, and it was
an approach that other drivers also use. But if you believe there is
a cleaner approach, I will be more than happy to do something else,
though I would appreciate an explanation of why it is cleaner so that
I can make better decisions in the future.
Best regards,
Michael
On 07. 12. 20 6:59, Sascha Hauer wrote:
> Hi Michael,
>
> On Sun, Dec 06, 2020 at 06:27:18PM +0100, michael.srba@xxxxxxxxx wrote:
>> From: Michael Srba <Michael.Srba@xxxxxxxxx>
>>
>> This patch adds 1% tolerance on input clock, similar to other camera sensor
>> drivers. It also allows for specifying the actual clock in the device tree,
>> instead of relying on it being already set to the right frequency (which is
>> often not the case).
>>
>> Signed-off-by: Michael Srba <Michael.Srba@xxxxxxxxx>
>>
>> ---
>>
>> changes since v1: default to exactly 24MHz when `clock-frequency` is not present
>>
>> ---
>> drivers/media/i2c/imx219.c | 19 +++++++++++++++++--
>> 1 file changed, 17 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/i2c/imx219.c b/drivers/media/i2c/imx219.c
>> index f64c0ef7a897..b6500e2ab19e 100644
>> --- a/drivers/media/i2c/imx219.c
>> +++ b/drivers/media/i2c/imx219.c
>> @@ -1443,13 +1443,28 @@ static int imx219_probe(struct i2c_client *client)
>> return PTR_ERR(imx219->xclk);
>> }
>>
>> - imx219->xclk_freq = clk_get_rate(imx219->xclk);
>> - if (imx219->xclk_freq != IMX219_XCLK_FREQ) {
>> + ret = fwnode_property_read_u32(dev_fwnode(dev), "clock-frequency", &imx219->xclk_freq);
>> + if (ret) {
>> + dev_warn(dev, "could not get xclk frequency\n");
>> +
>> + /* default to 24MHz */
>> + imx219->xclk_freq = 24000000;
>> + }
>> +
>> + /* this driver currently expects 24MHz; allow 1% tolerance */
>> + if (imx219->xclk_freq < 23760000 || imx219->xclk_freq > 24240000) {
>> dev_err(dev, "xclk frequency not supported: %d Hz\n",
>> imx219->xclk_freq);
>> return -EINVAL;
>> }
>>
>> + ret = clk_set_rate(imx219->xclk, imx219->xclk_freq);
>> + if (ret) {
>> + dev_err(dev, "could not set xclk frequency\n");
>> + return ret;
>> + }
> clk_set_rate() returns successfully when the rate change has succeeded.
> It tells you nothing about the actual rate that has been set. The rate
> could be very different from what you want to get, depending on what the
> hardware is able to archieve. There's clk_round_rate() that tells you
> which rate you'll get when you call clk_set_rate() with that value.
> You would have to call clk_round_rate() first and see if you are happy
> with the result, afterwards set the rate. From that view it doesn't make
> much sense to check the device tree if a number between 23760000 and
> 24240000 is specified there, the clk api will do rounding anyway.
>
> Also there's the assigned-clocks device tree binding, see
> Documentation/devicetree/bindings/clock/clock-bindings.txt. This allows
> you to set the desired clock rate directly in the device tree. All
> that's left to do in the driver is to replace the check for the exact
> rate with a check which allows a certain tolerance.
>
> Sascha
>
