[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG3jFyu5S1H=r6pV92tc_a2LoCUnhb0mDbOegP2BCO8a5C1nVg@mail.gmail.com>
Date: Tue, 10 Mar 2020 16:55:20 +0100
From: Robert Foss <robert.foss@...aro.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: ben.kao@...el.com, mchehab@...nel.org, robh+dt@...nel.org,
mark.rutland@....com, matthias.bgg@...il.com, davem@...emloft.net,
gregkh@...uxfoundation.org, Jonathan.Cameron@...wei.com,
linux-media@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org,
Dongchun Zhu <dongchun.zhu@...iatek.com>,
Tomasz Figa <tfiga@...omium.org>
Subject: Re: [v1 2/3] media: ov8856: Add devicetree support
Hi Andy,
On Tue, 10 Mar 2020 at 15:26, Andy Shevchenko
<andriy.shevchenko@...ux.intel.com> wrote:
>
> On Tue, Mar 10, 2020 at 02:46:02PM +0100, Robert Foss wrote:
> > Add devicetree match table, and enable ov8856_probe()
> > to initialize power, clocks and reset pins.
>
> ...
>
> > +#define OV8856_NUM_SUPPLIES ARRAY_SIZE(ov8856_supply_names)
>
> Use ARRAY_SIZE() directly.
Ack.
>
> Have you seen Sakari's comments?
> Sakari, do I have déją vu or you indeed commented this driver?
Yes, I may have missed some part of it, so please tell me if I have.
There is a patchset floating around that implements a larger chunk of
functionality,
including a couple of new modes. This is based on that series.
>
> ...
>
> > + gpiod_set_value_cansleep(ov8856->n_shutdn_gpio, GPIOD_OUT_LOW);
>
> > + gpiod_set_value_cansleep(ov8856->n_shutdn_gpio, GPIOD_OUT_HIGH);
>
> Yes, seems this one is inverted.
>
> ...
>
> > +{
> > + gpiod_set_value_cansleep(ov8856->n_shutdn_gpio, GPIOD_OUT_LOW);
> > + regulator_bulk_disable(OV8856_NUM_SUPPLIES, ov8856->supplies);
> > + clk_disable_unprepare(ov8856->xvclk);
> > +}
> > +
> > +
>
> One blank line is enough.
>
> ...
>
> > + ov8856->xvclk = devm_clk_get(&client->dev, "xvclk");
> > + if (IS_ERR(ov8856->xvclk)) {
> > + dev_err(&client->dev, "failed to get xvclk\n");
> > + return -EINVAL;
> > + }
>
> Previously it worked without clock provider, now you make a dependency.
>
> This won't work.
So the ideal behavior would be to only use the xclk if it is provided?
Powered by blists - more mailing lists