Re: [PATCH V11 2/2] media: i2c: ov02a10: Add OV02A10 image sensor driver

From: Tomasz Figa <tfiga@chromium.org>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: "Mark Rutland" <mark.rutland@arm.com>,
	linux-devicetree <devicetree@vger.kernel.org>,
	"Nicolas Boichat" <drinkcat@chromium.org>,
	srv_heupstream <srv_heupstream@mediatek.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Shengnan Wang (王圣男)" <shengnan.wang@mediatek.com>,
	"Louis Kuo" <louis.kuo@mediatek.com>,
	"Bartosz Golaszewski" <bgolaszewski@baylibre.com>,
	"Sj Huang" <sj.huang@mediatek.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"moderated list:ARM/Mediatek SoC support"
	<linux-mediatek@lists.infradead.org>,
	"Dongchun Zhu" <dongchun.zhu@mediatek.com>,
	"Sakari Ailus" <sakari.ailus@linux.intel.com>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Cao Bing Bu" <bingbu.cao@intel.com>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>,
	Joerg Roedel <joro@8bytes.org>,
	" <linux-arm-kernel@lists.infradead.org>,
	"Linux Media Mailing List" <linux-media@vger.kernel.org>
Subject: Re: [PATCH V11 2/2] media: i2c: ov02a10: Add OV02A10 image sensor driver
Date: Tue, 30 Jun 2020 16:40:12 +0200	[thread overview]
Message-ID: <CAAFQd5CwwLzGKiCPdd_EzipmXPA2aYBrk0QRPv6Bacy++tXrHA@mail.gmail.com> (raw)
In-Reply-To: <20200630143705.GW3703480@smile.fi.intel.com>

On Tue, Jun 30, 2020 at 4:37 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Tue, Jun 30, 2020 at 04:21:31PM +0200, Tomasz Figa wrote:
> > On Tue, Jun 30, 2020 at 4:19 PM Tomasz Figa <tfiga@chromium.org> wrote:
> > > On Tue, Jun 30, 2020 at 11:54 AM Sakari Ailus
> > > <sakari.ailus@linux.intel.com> wrote:
>
> ...
>
> > > > > +     ov02a10->rst_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> > > >
> > > >
> > > > Shouldn't this be GPIOD_OUT_HIGH? That's the state it'll be after powering
> > > > the sensor off the first time. Alternatively make reset signal high in
> > > > runtime suspend callback.
> > >
> > > We might want to keep the signals low when the regulators are powered
> > > down, to reduce the leakage.
> >
> > Ah, I actually recall that the reset pin was physically active low, so
> > we would indeed better keep it at HIGH. Sorry for the noise.
>
> Here HIGH means "asserted", so in the code above it's LOW, means "deasserted",
> i.o.w. non-reset state. I dunno what is better, it depends to the firmware /
> driver expectations of the device configuration (from the power point of view,
> HIGH makes sense here, and not LOW, i.o.w. asserted reset line).
>
> And nice of the logical state that it doesn't depend to the active low / high
> (the latter just transparent to the user).

Yeah, after reading through the GPIO subsystem documentation and
discussing with a bunch of people on how to interpret it, we concluded
that the driver needs to deal only with the logical state of the
signal.

Actually, I later realized that the problem of leakage should likely
be solved by pinctrl suspend settings, based on given hardware
conditions, rather than the driver explicitly.

Best regards,
Tomasz

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek