On Tue, 10 Mar 2020 at 16:51, Robert Foss <robert.foss@xxxxxxxxxx> wrote:
>
> Hey Fabio,
>
> Thanks for having a look at this series so quickly.
>
> On Tue, 10 Mar 2020 at 14:57, Fabio Estevam <festevam@xxxxxxxxx> wrote:
> >
> > Hi Robert,
> >
> > On Tue, Mar 10, 2020 at 10:46 AM Robert Foss <robert.foss@xxxxxxxxxx> wrote:
> >
> > > + ov8856: camera-sensor@10 {
> > > + compatible = "ovti,ov8856";
> > > + reg = <0x10>;
> > > + reset-gpios = <&pio 111 GPIO_ACTIVE_HIGH>;
> >
> > Could you double check this is correct? Other OmniVision sensors have
> > reset-gpios as active low.
>
> I have tested this, unfortunately I don't have access to a ov8856
> datasheet that includes
> this level of detail. But I have tested this.
>
> >
> > I suspect that the driver has also an inverted logic, so that's why it works.
>
> That could explain it still working. Let me have a look into the
> driver and see what it does.
>
I had a look at some of OmniVision drivers, and there does seem to be
a logical inversion in some of them,
but not all of them.
ov7251:
- enable-gpios: Chip enable GPIO. Polarity is GPIO_ACTIVE_HIGH. This corresponds
to the hardware pin XSHUTDOWN which is physically active low.
ov5640:
- reset-gpios: reference to the GPIO connected to the reset pin, if any.
This is an active low signal to the OV5640.
I think the confusion stems from the XSHUTDOWN pin being mapped to a
GPIO called reset, and the two being logically inverted. Currently
this series does several mappings.
XSHUTDOWN -> reset-gpio -> n_shutdn_gpio
^ ^ ^
Physical Pin DT Driver
I think changing to what ov5640 does makes the most sense.
XSHUTDOWN -> reset-gpio -> reset_gpio
> >
> > I don't have access to the datasheet though, so I am just guessing.
>
> Me neither unfortunately, if anyone does have a link for it, I would
> very much appreciate it.
