Bug in mipi_dbi_hw_reset() causes incorrect DT entries

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

There is a bug in the mipi_dbi_hw_reset() function that handles the
reset logic of the controller. Currently, it will set the reset gpio
value to 0, wait a specified time, then set the reset gpio value to 1.

The issue with this implementation is that the MIPI DBI spec states that
the reset signal is active low. So, in order to correct for this logic,
the developer needs to incorrectly define the reset gpio as active high
in the DT.

Fixing the logic in the driver would cause all the displays using this
driver downstream to stop working. To mitigate this, Josef and I were
thinking about adding an additional boolean property to the DT that when
present would use the correct reset logic in the driver. And if it's not
present use the current reset logic and print out a warning that this
reset logic is deprecated.

The overall plan would be to have this temporary fix for a few release
cycles so downstream has time to be aware of the issue and update their
DT. Eventually, we would remove the incorrect reset logic in the driver
and this addtional boolean property.

Let me know what you think of this approach and if there might be
something better we can do here.

Best regards,
Alex




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux