> Hi, > > [now with Saravana's correct mail, sorry for the noise] [+ Saravana] > > On Wed Mar 11, 2026 at 4:54 PM CET, Bartholomäus Steinmayr wrote: >> this patch series adds support for the Densitron DMT050WVNMCMI-1A >> panel to the ILI9806E DSI driver. The patch mainly contains >> initialization code for the panel. >> >> However, the display also has a peculiarity which required some more >> changes to the driver. The display contains a Goodix GT911 touchpanel >> controller. The GT911 and ILI9806E share a single reset line. The i2c >> address of the GT911 chip is set by manipulating an IO line during >> reset. This is already handled by the existing GT911 driver, but it >> means that the reset line MUST be controlled by the Goodix driver >> (drivers/input/touchscreen/goodix.c). The ILI9806E should defer its >> probing until the Goodix driver has completed its reset. The ILI9806E >> should then probe with asserting the reset line. > > I see. This explanation should definitely go into the commit message of the > second patch. > > So basically, you 'just' need to have the driver for the touch panel probed > first. I'm not really sure you can just move the reset line to the touch > controller or if it has to be shared between both. > Also, what happens if the dsi panel is turned off, which right now, would > assert the reset line. > > I think device-links is what you need ([1], maybe > Documentation/driver-api/device_link.rst). IIRC they get added automatically > by parsing the device tree. So you might just need a phandle pointint to the > goodix touchscreen driver, to have it probed first. But there is probably > more you'd need to handle the "turn the DSI display off and on again" case. > I'd start by adding a phandle called "touch-controller" to the panel node > (similar to your i2c-frag I think).
Thank you for the review and suggestions! I will try to find a better solution and amend this thread. This might take a while, we currently have a rather tight product development schedule and the current, hacky solution works. >> To achieve this, this patch adds an optional dt node "i2c-frag" to the >> ILI9806E driver. If this node exists, the Ilitek driver defers its >> probing until the i2c node has been initialized. Furthermore, the >> reset-gpios property has been made optional. To keep the Ilitek driver >> from asserting the reset line, the reset-gpios property should be left >> out for the DMT050 display. > > Any devicetree bindings (i2c-frag, optional reset) have to be documented in > the corresponding binding, i.e. see your first patch. > >> This solution does not seem particularly elegant, but I could not find >> a more straight-forward one. This is also my first kernel patch, so I >> appreciate your patience. > > Thanks for joining the linux kernel community and don't worry. > > -michael > > [1] https://lore.kernel.org/all/[email protected]/
