| Message ID | 20221103-upstream-goodix-reset-v3-0-0975809eb183@theobroma-systems.com |
|---|---|
| Headers | show |
| Series | fix reset line polarity for Goodix touchscreen controllers | expand |
On Mon, 5 Dec 2022 14:40:29 +0100, Quentin Schulz wrote: > From: Quentin Schulz <quentin.schulz@theobroma-systems.com> > > The Goodix touchscreen controller has a reset line active low. It happens to > also be used to configure its i2c address at runtime. If the reset line is > incorrectly asserted, the address will be wrongly configured. This cost me a few > hours, trying to figure out why the touchscreen wouldn't work. > > [...] Applied, thanks! [8/9] arm64: dts: qcom: msm8998-fxtec: fix touchscreen reset GPIO polarity commit: 8a0721dae68fdb4534e220fc9faae7a0ef2f3785 Best regards,
Hi Bjorn, all, On 1/10/23 17:17, Bjorn Andersson wrote: > On Mon, 5 Dec 2022 14:40:29 +0100, Quentin Schulz wrote: >> From: Quentin Schulz <quentin.schulz@theobroma-systems.com> >> >> The Goodix touchscreen controller has a reset line active low. It happens to >> also be used to configure its i2c address at runtime. If the reset line is >> incorrectly asserted, the address will be wrongly configured. This cost me a few >> hours, trying to figure out why the touchscreen wouldn't work. >> >> [...] > > Applied, thanks! > > [8/9] arm64: dts: qcom: msm8998-fxtec: fix touchscreen reset GPIO polarity > commit: 8a0721dae68fdb4534e220fc9faae7a0ef2f3785 > Thank you for the merge, however I think there could be some issue here. This requires the patches 1, 2 and 3 all modifying the input driver in order to not introduce a regression. I mistakenly removed the RFC tag and seemingly didn't make it clear enough that I had some question on how to properly merge this patch series, c.f. "Do we also make this patch series only one patchset since the DT patches depend on the driver patch and vice-versa? In which tree would this go?" in the cover letter. So please, how do we go on with the rest of the patch series? Should I submit a v4 which would be only one patch with DT and input changes all at once and Bjorn reverts the patch they had just merged? @Dmitry, since you would have to merge at least patches 1 to 3 in your tree (I assume), would you be willing to take the DT patches at the same time through your tree too? Are the appropriate device DT maintainers OK with this? Cheers, Quentin
Hi all, On 1/16/23 13:37, Quentin Schulz wrote: > Hi Bjorn, all, > > On 1/10/23 17:17, Bjorn Andersson wrote: >> On Mon, 5 Dec 2022 14:40:29 +0100, Quentin Schulz wrote: >>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com> >>> >>> The Goodix touchscreen controller has a reset line active low. It >>> happens to >>> also be used to configure its i2c address at runtime. If the reset >>> line is >>> incorrectly asserted, the address will be wrongly configured. This >>> cost me a few >>> hours, trying to figure out why the touchscreen wouldn't work. >>> >>> [...] >> >> Applied, thanks! >> >> [8/9] arm64: dts: qcom: msm8998-fxtec: fix touchscreen reset GPIO >> polarity >> commit: 8a0721dae68fdb4534e220fc9faae7a0ef2f3785 >> > > Thank you for the merge, however I think there could be some issue here. > > This requires the patches 1, 2 and 3 all modifying the input driver in > order to not introduce a regression. > > I mistakenly removed the RFC tag and seemingly didn't make it clear > enough that I had some question on how to properly merge this patch > series, c.f. "Do we also make this patch series only one patchset since > the DT patches depend > on the driver patch and vice-versa? In which tree would this go?" in the > cover letter. > > So please, how do we go on with the rest of the patch series? Should I > submit a v4 which would be only one patch with DT and input changes all > at once and Bjorn reverts the patch they had just merged? > > @Dmitry, since you would have to merge at least patches 1 to 3 in your > tree (I assume), would you be willing to take the DT patches at the same > time through your tree too? Are the appropriate device DT maintainers OK > with this? > Ping. Cheers, Quentin