[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200921120234.GB1233@kozik-lap>
Date: Mon, 21 Sep 2020 14:02:34 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc: Mauro Carvalho Chehab <mchehab@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>,
NXP Linux Team <linux-imx@....com>,
linux-media@...r.kernel.org, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 3/3] media: imx258: Get clock from device properties
and enable it via runtime PM
On Wed, Sep 02, 2020 at 10:39:35AM +0300, Sakari Ailus wrote:
> Hi Krzysztof,
>
> Thanks for the update.
>
> On Wed, Sep 02, 2020 at 09:18:10AM +0200, Krzysztof Kozlowski wrote:
> > The IMX258 sensor driver checked in device properties for a
> > clock-frequency property which actually does not mean that the clock is
> > really running such frequency or is it even enabled.
> >
> > Get the provided clock and check it frequency. If none is provided,
> > fall back to old property.
> >
> > Enable the clock when accessing the IMX258 registers and when streaming
> > starts with runtime PM.
> >
> > Signed-off-by: Krzysztof Kozlowski <krzk@...nel.org>
> >
> > ---
> >
> > Changes since v1:
> > 1. Use runtime PM for clock toggling
> > ---
> > drivers/media/i2c/imx258.c | 68 ++++++++++++++++++++++++++++++++++++++++------
> > 1 file changed, 59 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> > index c20bac9b00ec..ee38dafb8450 100644
> > --- a/drivers/media/i2c/imx258.c
> > +++ b/drivers/media/i2c/imx258.c
> > @@ -2,6 +2,7 @@
> > // Copyright (C) 2018 Intel Corporation
> >
> > #include <linux/acpi.h>
> > +#include <linux/clk.h>
> > #include <linux/delay.h>
> > #include <linux/i2c.h>
> > #include <linux/module.h>
> > @@ -68,6 +69,9 @@
> > #define REG_CONFIG_MIRROR_FLIP 0x03
> > #define REG_CONFIG_FLIP_TEST_PATTERN 0x02
> >
> > +/* Input clock frequency in Hz */
> > +#define IMX258_INPUT_CLOCK_FREQ 19200000
> > +
> > struct imx258_reg {
> > u16 address;
> > u8 val;
> > @@ -610,6 +614,8 @@ struct imx258 {
> >
> > /* Streaming on/off */
> > bool streaming;
> > +
> > + struct clk *clk;
> > };
> >
> > static inline struct imx258 *to_imx258(struct v4l2_subdev *_sd)
> > @@ -972,6 +978,27 @@ static int imx258_stop_streaming(struct imx258 *imx258)
> > return 0;
> > }
> >
> > +static int imx258_power_on(struct device *dev)
> > +{
> > + struct imx258 *imx258 = dev_get_drvdata(dev);
> > + int ret;
> > +
> > + ret = clk_prepare_enable(imx258->clk);
> > + if (ret)
> > + dev_err(dev, "failed to enable clock\n");
> > +
> > + return ret;
> > +}
> > +
> > +static int imx258_power_off(struct device *dev)
> > +{
> > + struct imx258 *imx258 = dev_get_drvdata(dev);
> > +
> > + clk_disable_unprepare(imx258->clk);
> > +
> > + return 0;
> > +}
> > +
> > static int imx258_set_stream(struct v4l2_subdev *sd, int enable)
> > {
> > struct imx258 *imx258 = to_imx258(sd);
> > @@ -1201,9 +1228,27 @@ static int imx258_probe(struct i2c_client *client)
> > int ret;
> > u32 val = 0;
> >
> > - device_property_read_u32(&client->dev, "clock-frequency", &val);
> > - if (val != 19200000)
> > - return -EINVAL;
> > + imx258 = devm_kzalloc(&client->dev, sizeof(*imx258), GFP_KERNEL);
> > + if (!imx258)
> > + return -ENOMEM;
> > +
> > + dev_set_drvdata(&client->dev, imx258);
>
> This you cannot do --- it'll be overwritten by v4l2_i2c_subdev_init().
Right, thanks.
>
> > +
> > + imx258->clk = devm_clk_get_optional(&client->dev, NULL);
> > + if (!imx258->clk) {
>
> You can move declaration of val here (I think).
No, the val is used later in further device_property_read* calls.
>
> > + dev_info(&client->dev, "no clock provided, using clock-frequency property\n");
>
> As this is showing up on all ACPI based systems, I guess dev_dbg() would be
> more appropriate.
Sure, I'll make it debug.
>
> Please also wrap lines over 80 if they reasonably can be.
OK
Thanks for the review.
Best regards,
Krzysztof
Powered by blists - more mailing lists