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

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

On Tue, 2020-06-30 at 16:40 +0200, Tomasz Figa wrote:
> 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.
> 

Thank you for all your explanation.
Fixed in next release.

> Best regards,
> Tomasz