Re: [PATCH v6 2/2] drm/bridge: Add Lontium LT9611C(EX/UXD) MIPI DSI to HDMI driver

[Sunyun Yang]

Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxxxxxxxx> 于2026年6月25日周四 22:57写道：
>
> On Thu, Jun 25, 2026 at 09:26:47PM +0800, Sunyun Yang wrote:
> > Krzysztof Kozlowski <krzk@xxxxxxxxxx> 于2026年6月25日周四 21:17写道：
> > >
> > > On 25/06/2026 15:14, Sunyun Yang wrote:
> > > > Krzysztof Kozlowski <krzk@xxxxxxxxxx> 于2026年6月25日周四 20:54写道：
> > > >>
> > > >> On 08/05/2026 15:40, syyang@xxxxxxxxxxx wrote:
> > > >>> +
> > > >>> +static void lt9611c_reset(struct lt9611c *lt9611c)
> > > >>> +{
> > > >>> +     gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
> > > >>> +     msleep(20);
> > > >>> +
> > > >>> +     gpiod_set_value_cansleep(lt9611c->reset_gpio, 0);
> > > >>> +     msleep(20);
> > > >>> +
> > > >>> +     gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
> > > >>
> > > >> This is just plain wrong. Why do you assert, then de-assert and then
> > > >> finally assert AGAIN the reset leaving the device in powerdown stage?
> > > >>
> > > > I am using software to emulate the hardware RESET button on our EVB.
> > > > When the hardware RESET button is pressed while our chip is running,
> > > > the signal level changes from HIGH to LOW and then back to HIGH.
> > > >
> > > > Of course, we can also use the following:
> > > > static void lt9611c_reset(struct lt9611c *lt9611c)
> > > > {
> > > >     gpiod_set_value_cansleep(lt9611c->reset_gpio, 0);
> > > >     msleep(50);
> > > >     gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
> > > >     msleep(20);
> > > > }
> > >
> > > Makes no sense either and you just did not get the point and did not
> > > answer my question. I asked WHY you leave asserted. Answer "we emulate"
> > > is just plain wrong.
> > >
> > > So again please answer:
> > >
> > > Why do you leave device with reset asserted?
> > >
> >
> >  devicetree:   reset-gpios = <&tlmm 128 GPIO_ACTIVE_HIGH>;
>
> It should be GPIO_ACTIVE_LOW, if the pin as active-low.
>

Yes, I understand that.

I used GPIO_ACTIVE_HIGH intentionally, because I did not want to
modify the existing reset-gpios = <&tlmm 128 GPIO_ACTIVE_HIGH>
property in the lontium-lt9611.yaml device tree file that was
submitted by others. If I used GPIO_ACTIVE_LOW, I would have to change
that line in the device tree binding, and also update the driver files
lontium-lt9611.c and lontium-lt9611uxc.c accordingly. That would add a
significant amount of extra work for me.


Moreover, in much earlier versions, I had added a separate
lontium-lt9611c.yaml file to decouple this new chip from the existing
lontium-lt9611 / lontium-lt9611uxc support. However, Dmitry Baryshkov
considered that unnecessary and asked me to merge lontium-lt9611c
together with the existing drivers. He also told me that the
differences in reset‑pin and VDD/VCC supply did not matter.


The existing device tree and driver code already had issues, and I had
raised them with you before. At that time, you did not seem to care,
and the community reviewers insisted that I must follow your
directions. So I did exactly what you told me to do.

> >
> > GPIO_ACTIVE_HIGH:
> >
> > gpiod_set_value_cansleep(lt9611c->reset_gpio, 0);   ------   reset pin
> > is Low level : Clear the register configuration in the chip to stop
> > the chip from working.
> >
> > gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);   ------  reset pin
> > is high level:  The chip resumes operation.
> >
> >
> >
> > > Best regards,
> > > Krzysztof
>
> --
> With best wishes
> Dmitry