| Message ID | 20220524134840.1.I80072b8815ac08c12af8f379a33cc2d83693dc51@changeid (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
| Series | arm64: dts: qcom: sc7280: Add touchscreen to villager | expand |
On 24/05/2022 22:48, Douglas Anderson wrote: > This adds the touchscreen to the sc7280-herobrine-villager device > tree. Note that the touchscreen on villager actually uses the reset > line and thus we use the more specific "elan,ekth6915" compatible > which allows us to specify the reset. > > The fact that villager's touchscreen uses the reset line can be > contrasted against the touchscreen for CRD/herobrine-r1. On those > boards, even though the touchscreen goes to the display, it's not > hooked up to anything there. > > In order to keep the line parked on herobrine/CRD, we'll move the > pullup from the qcard.dtsi file to the specific boards. This allows us > to disable the pullup in the villager device tree since the pin is an > output. > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > --- > This uses bindings introduced in the patch ("dt-bindings: HID: > i2c-hid: elan: Introduce bindings for Elan eKTH6915") [1]. > > [1] https://lore.kernel.org/r/20220523142257.v2.1.Iedc61f9ef220a89af6a031200a7850a27a440134@changeid > > .../boot/dts/qcom/sc7280-herobrine-crd.dts | 11 ++++++++ > .../qcom/sc7280-herobrine-herobrine-r1.dts | 11 ++++++++ > .../dts/qcom/sc7280-herobrine-villager-r0.dts | 25 +++++++++++++++++++ > arch/arm64/boot/dts/qcom/sc7280-qcard.dtsi | 1 - > 4 files changed, 47 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts b/arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts > index a4ac33c4fd59..b79d84d7870a 100644 > --- a/arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts > +++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts > @@ -134,6 +134,17 @@ &sdhc_2 { > status = "okay"; > }; > > +/* PINCTRL - ADDITIONS TO NODES IN PARENT DEVICE TREE FILES */ Please drop this line, this isn't msm-3.4. It's immediately obvious that if a pin is referenced by a label and it is not defined in this file (because otherwise it wouldn't be both defined and referenced here..), it comes from a previously included device tree. > + > +/* > + * This pin goes to the display panel but then doesn't actually do anything > + * on the panel itself (it doesn't connect to the touchscreen controller). > + * We'll set a pullup here just to park the line. > + */ > +&ts_rst_conn { > + bias-pull-up; > +}; > + > /* PINCTRL - BOARD-SPECIFIC */ > > /* > diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts b/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts > index b69ca09d9bfb..c1647a85a371 100644 > --- a/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts > +++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts > @@ -128,6 +128,17 @@ &sdhc_2 { > status = "okay"; > }; > > +/* PINCTRL - ADDITIONS TO NODES IN PARENT DEVICE TREE FILES */ Ditto > + > +/* > + * This pin goes to the display panel but then doesn't actually do anything > + * on the panel itself (it doesn't connect to the touchscreen controller). > + * We'll set a pullup here just to park the line. > + */ > +&ts_rst_conn { > + bias-pull-up; > +}; > + > /* PINCTRL - BOARD-SPECIFIC */ > > /* > diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine-villager-r0.dts b/arch/arm64/boot/dts/qcom/sc7280-herobrine-villager-r0.dts > index d3d6ffad4eff..950b69448109 100644 > --- a/arch/arm64/boot/dts/qcom/sc7280-herobrine-villager-r0.dts > +++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine-villager-r0.dts > @@ -46,6 +46,25 @@ trackpad: trackpad@2c { > }; > }; > > +ts_i2c: &i2c13 { > + status = "okay"; > + clock-frequency = <400000>; > + > + ap_ts: touchscreen@10 { > + compatible = "elan,ekth6915"; > + reg = <0x10>; > + pinctrl-names = "default"; > + pinctrl-0 = <&ts_int_conn>, <&ts_rst_conn>; > + > + interrupt-parent = <&tlmm>; > + interrupts = <55 IRQ_TYPE_LEVEL_LOW>; > + > + reset-gpios = <&tlmm 54 GPIO_ACTIVE_LOW>; > + > + vcc33-supply = <&ts_avdd>; > + }; > +}; > + > &ap_sar_sensor_i2c { > status = "okay"; > }; > @@ -81,6 +100,12 @@ &sdhc_1 { > status = "okay"; > }; > > +/* PINCTRL - ADDITIONS TO NODES IN PARENT DEVICE TREE FILES */ Ditto > + > +&ts_rst_conn { > + bias-disable; > +}; > + > /* PINCTRL - BOARD-SPECIFIC */ > > /* > diff --git a/arch/arm64/boot/dts/qcom/sc7280-qcard.dtsi b/arch/arm64/boot/dts/qcom/sc7280-qcard.dtsi > index d59002d4492e..404936c6bf20 100644 > --- a/arch/arm64/boot/dts/qcom/sc7280-qcard.dtsi > +++ b/arch/arm64/boot/dts/qcom/sc7280-qcard.dtsi > @@ -604,7 +604,6 @@ ts_int_conn: ts-int-conn { > ts_rst_conn: ts-rst-conn { > pins = "gpio54"; > function = "gpio"; > - bias-pull-up; If you overwrite it where it should be overwritten, wouldn't it make more sense to leave bias-pull-up here as a default configuration for boards that don't have a peculiar routed-but-NC line? Konrad > drive-strength = <2>; > }; > }; >
Hi, On Tue, May 24, 2022 at 2:13 PM Konrad Dybcio <konrad.dybcio@somainline.org> wrote: > > > On 24/05/2022 22:48, Douglas Anderson wrote: > > This adds the touchscreen to the sc7280-herobrine-villager device > > tree. Note that the touchscreen on villager actually uses the reset > > line and thus we use the more specific "elan,ekth6915" compatible > > which allows us to specify the reset. > > > > The fact that villager's touchscreen uses the reset line can be > > contrasted against the touchscreen for CRD/herobrine-r1. On those > > boards, even though the touchscreen goes to the display, it's not > > hooked up to anything there. > > > > In order to keep the line parked on herobrine/CRD, we'll move the > > pullup from the qcard.dtsi file to the specific boards. This allows us > > to disable the pullup in the villager device tree since the pin is an > > output. > > > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > > --- > > This uses bindings introduced in the patch ("dt-bindings: HID: > > i2c-hid: elan: Introduce bindings for Elan eKTH6915") [1]. > > > > [1] https://lore.kernel.org/r/20220523142257.v2.1.Iedc61f9ef220a89af6a031200a7850a27a440134@changeid > > > > .../boot/dts/qcom/sc7280-herobrine-crd.dts | 11 ++++++++ > > .../qcom/sc7280-herobrine-herobrine-r1.dts | 11 ++++++++ > > .../dts/qcom/sc7280-herobrine-villager-r0.dts | 25 +++++++++++++++++++ > > arch/arm64/boot/dts/qcom/sc7280-qcard.dtsi | 1 - > > 4 files changed, 47 insertions(+), 1 deletion(-) > > > > diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts b/arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts > > index a4ac33c4fd59..b79d84d7870a 100644 > > --- a/arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts > > +++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts > > @@ -134,6 +134,17 @@ &sdhc_2 { > > status = "okay"; > > }; > > > > +/* PINCTRL - ADDITIONS TO NODES IN PARENT DEVICE TREE FILES */ > > Please drop this line, this isn't msm-3.4. It's immediately obvious that > if a pin is referenced by a label and it is not defined in this file > (because otherwise it wouldn't be both defined and referenced here..), > it comes from a previously included device tree. In general these headings specify a change in sort ordering. Without them then either we intersperse pinctrl overrides with other stuff, which IMO is overall worse or people have no idea why the sort ordering changes. > > @@ -604,7 +604,6 @@ ts_int_conn: ts-int-conn { > > ts_rst_conn: ts-rst-conn { > > pins = "gpio54"; > > function = "gpio"; > > - bias-pull-up; > > If you overwrite it where it should be overwritten, wouldn't it make > more sense to leave bias-pull-up here as a default configuration for > boards that don't have a peculiar routed-but-NC line? Yeah, it'd be nice. ...but because of the way "bias" is specified in the device tree it means an ugly "/delete-property" in places that actually route the line. I believe that, style wise, the preference is to avoid delete-property and move the bias toward board files in cases like this. Bjorn can feel free to override me if he disagrees. -Doug
On Tue, May 24, 2022 at 01:48:49PM -0700, Douglas Anderson wrote: > This adds the touchscreen to the sc7280-herobrine-villager device > tree. Note that the touchscreen on villager actually uses the reset > line and thus we use the more specific "elan,ekth6915" compatible > which allows us to specify the reset. > > The fact that villager's touchscreen uses the reset line can be > contrasted against the touchscreen for CRD/herobrine-r1. On those > boards, even though the touchscreen goes to the display, it's not > hooked up to anything there. > > In order to keep the line parked on herobrine/CRD, we'll move the > pullup from the qcard.dtsi file to the specific boards. This allows us > to disable the pullup in the villager device tree since the pin is an > output. > > Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
On 25/05/2022 00:14, Doug Anderson wrote: > Hi, > > On Tue, May 24, 2022 at 2:13 PM Konrad Dybcio > <konrad.dybcio@somainline.org> wrote: >> >> On 24/05/2022 22:48, Douglas Anderson wrote: >>> This adds the touchscreen to the sc7280-herobrine-villager device >>> tree. Note that the touchscreen on villager actually uses the reset >>> line and thus we use the more specific "elan,ekth6915" compatible >>> which allows us to specify the reset. >>> >>> The fact that villager's touchscreen uses the reset line can be >>> contrasted against the touchscreen for CRD/herobrine-r1. On those >>> boards, even though the touchscreen goes to the display, it's not >>> hooked up to anything there. >>> >>> In order to keep the line parked on herobrine/CRD, we'll move the >>> pullup from the qcard.dtsi file to the specific boards. This allows us >>> to disable the pullup in the villager device tree since the pin is an >>> output. >>> >>> Signed-off-by: Douglas Anderson <dianders@chromium.org> >>> --- >>> This uses bindings introduced in the patch ("dt-bindings: HID: >>> i2c-hid: elan: Introduce bindings for Elan eKTH6915") [1]. >>> >>> [1] https://lore.kernel.org/r/20220523142257.v2.1.Iedc61f9ef220a89af6a031200a7850a27a440134@changeid >>> >>> .../boot/dts/qcom/sc7280-herobrine-crd.dts | 11 ++++++++ >>> .../qcom/sc7280-herobrine-herobrine-r1.dts | 11 ++++++++ >>> .../dts/qcom/sc7280-herobrine-villager-r0.dts | 25 +++++++++++++++++++ >>> arch/arm64/boot/dts/qcom/sc7280-qcard.dtsi | 1 - >>> 4 files changed, 47 insertions(+), 1 deletion(-) >>> >>> diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts b/arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts >>> index a4ac33c4fd59..b79d84d7870a 100644 >>> --- a/arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts >>> +++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts >>> @@ -134,6 +134,17 @@ &sdhc_2 { >>> status = "okay"; >>> }; >>> >>> +/* PINCTRL - ADDITIONS TO NODES IN PARENT DEVICE TREE FILES */ >> Please drop this line, this isn't msm-3.4. It's immediately obvious that >> if a pin is referenced by a label and it is not defined in this file >> (because otherwise it wouldn't be both defined and referenced here..), >> it comes from a previously included device tree. > In general these headings specify a change in sort ordering. Without > them then either we intersperse pinctrl overrides with other stuff, > which IMO is overall worse or people have no idea why the sort > ordering changes. I get what you mean, but at the end of the day, the entire machine DT specifies all machine-specific changes and only machine-specific changes. They all are a part of a bigger picture, sometimes being downstream from the SoC, sometimes downstream from a common board. I don't think it brings much benefit if at all to separate them into sections like these, if in the end they all correspond to modifications present in the hardware. In its current form, the sorting is all over the place, and ideally we could have labels sorted alphabetically. The present solution, in my opinion, causes more disarray as you first have to think about what is the change against and then find it in the corresponding subsection instead of thinking of it as a complete quote-on-quote diff against the parent DTSIs. Plus, most DTs don't split it like that. > >>> @@ -604,7 +604,6 @@ ts_int_conn: ts-int-conn { >>> ts_rst_conn: ts-rst-conn { >>> pins = "gpio54"; >>> function = "gpio"; >>> - bias-pull-up; >> If you overwrite it where it should be overwritten, wouldn't it make >> more sense to leave bias-pull-up here as a default configuration for >> boards that don't have a peculiar routed-but-NC line? > Yeah, it'd be nice. ...but because of the way "bias" is specified in > the device tree it means an ugly "/delete-property" in places that > actually route the line. I believe that, style wise, the preference is > to avoid delete-property and move the bias toward board files in cases > like this. Bjorn can feel free to override me if he disagrees. Ok, totally fair, it somehow slipped my mind that you have to delete one property to replace it with the other, I retract that comment then. Konrad > > -Doug
Hi, On Tue, May 24, 2022 at 3:41 PM Konrad Dybcio <konrad.dybcio@somainline.org> wrote: > > > On 25/05/2022 00:14, Doug Anderson wrote: > > Hi, > > > > On Tue, May 24, 2022 at 2:13 PM Konrad Dybcio > > <konrad.dybcio@somainline.org> wrote: > >> > >> On 24/05/2022 22:48, Douglas Anderson wrote: > >>> This adds the touchscreen to the sc7280-herobrine-villager device > >>> tree. Note that the touchscreen on villager actually uses the reset > >>> line and thus we use the more specific "elan,ekth6915" compatible > >>> which allows us to specify the reset. > >>> > >>> The fact that villager's touchscreen uses the reset line can be > >>> contrasted against the touchscreen for CRD/herobrine-r1. On those > >>> boards, even though the touchscreen goes to the display, it's not > >>> hooked up to anything there. > >>> > >>> In order to keep the line parked on herobrine/CRD, we'll move the > >>> pullup from the qcard.dtsi file to the specific boards. This allows us > >>> to disable the pullup in the villager device tree since the pin is an > >>> output. > >>> > >>> Signed-off-by: Douglas Anderson <dianders@chromium.org> > >>> --- > >>> This uses bindings introduced in the patch ("dt-bindings: HID: > >>> i2c-hid: elan: Introduce bindings for Elan eKTH6915") [1]. > >>> > >>> [1] https://lore.kernel.org/r/20220523142257.v2.1.Iedc61f9ef220a89af6a031200a7850a27a440134@changeid > >>> > >>> .../boot/dts/qcom/sc7280-herobrine-crd.dts | 11 ++++++++ > >>> .../qcom/sc7280-herobrine-herobrine-r1.dts | 11 ++++++++ > >>> .../dts/qcom/sc7280-herobrine-villager-r0.dts | 25 +++++++++++++++++++ > >>> arch/arm64/boot/dts/qcom/sc7280-qcard.dtsi | 1 - > >>> 4 files changed, 47 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts b/arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts > >>> index a4ac33c4fd59..b79d84d7870a 100644 > >>> --- a/arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts > >>> +++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts > >>> @@ -134,6 +134,17 @@ &sdhc_2 { > >>> status = "okay"; > >>> }; > >>> > >>> +/* PINCTRL - ADDITIONS TO NODES IN PARENT DEVICE TREE FILES */ > >> Please drop this line, this isn't msm-3.4. It's immediately obvious that > >> if a pin is referenced by a label and it is not defined in this file > >> (because otherwise it wouldn't be both defined and referenced here..), > >> it comes from a previously included device tree. > > In general these headings specify a change in sort ordering. Without > > them then either we intersperse pinctrl overrides with other stuff, > > which IMO is overall worse or people have no idea why the sort > > ordering changes. > > I get what you mean, but at the end of the day, the entire machine DT > specifies all machine-specific changes and only machine-specific > changes. They all are a part of a bigger picture, sometimes being > downstream from the SoC, sometimes downstream from a common board. I > don't think it brings much benefit if at all to separate them into > sections like these, if in the end they all correspond to modifications > present in the hardware. In its current form, the sorting is all over > the place, and ideally we could have labels sorted alphabetically. I think overall DT just made it hard. In my mind the root of the problem is actually that we're trying to avoid replicating hierarchy from the dtsi files that we include. In other words, we try very hard to do: &qup_i2c2_data_clk { bias-disable; }; Instead of replicating the hierarchy in the board dts files, like this: / { soc@0 { pinctrl@f100000 { qup-i2c2-data-clk { bias-disable;; }; }; }; }; (and, of course, you could replicate parts of the hierarchy too). When you avoid replicating things then it really causes everything to become scattered / disorganized and I think there's a benefit to trying to enforce some type of ordering. > The present solution, in my opinion, causes more disarray as you first > have to think about what is the change against and then find it in the > corresponding subsection instead of thinking of it as a complete > quote-on-quote diff against the parent DTSIs. It's a fair opinion. I'd be interested to know if others feel the same way. In general it feels like a style decision for the people working on these boards, subject to the approval of the Qualcomm tree maintainer(s). > Plus, most DTs don't split > it like that. I will say that it's hard to compare the trogdor (and now herobrine) situation with most other ARM boards out there. There are _a lot_ of different variants and revisions and it's, IMO, more art than science in trying to balance all of the tradeoffs between duplicating code and ending up with unreadable spaghetti. I won't claim that we made the right tradeoff in every case, but so far experience on trogdor has been that things ended up being fairly understandable I think? -Doug
On 25/05/2022 00:55, Doug Anderson wrote: > Hi, > > On Tue, May 24, 2022 at 3:41 PM Konrad Dybcio > <konrad.dybcio@somainline.org> wrote: >> >> On 25/05/2022 00:14, Doug Anderson wrote: >>> Hi, >>> >>> On Tue, May 24, 2022 at 2:13 PM Konrad Dybcio >>> <konrad.dybcio@somainline.org> wrote: >>>> On 24/05/2022 22:48, Douglas Anderson wrote: >>>>> This adds the touchscreen to the sc7280-herobrine-villager device >>>>> tree. Note that the touchscreen on villager actually uses the reset >>>>> line and thus we use the more specific "elan,ekth6915" compatible >>>>> which allows us to specify the reset. >>>>> >>>>> The fact that villager's touchscreen uses the reset line can be >>>>> contrasted against the touchscreen for CRD/herobrine-r1. On those >>>>> boards, even though the touchscreen goes to the display, it's not >>>>> hooked up to anything there. >>>>> >>>>> In order to keep the line parked on herobrine/CRD, we'll move the >>>>> pullup from the qcard.dtsi file to the specific boards. This allows us >>>>> to disable the pullup in the villager device tree since the pin is an >>>>> output. >>>>> >>>>> Signed-off-by: Douglas Anderson <dianders@chromium.org> >>>>> --- >>>>> This uses bindings introduced in the patch ("dt-bindings: HID: >>>>> i2c-hid: elan: Introduce bindings for Elan eKTH6915") [1]. >>>>> >>>>> [1] https://lore.kernel.org/r/20220523142257.v2.1.Iedc61f9ef220a89af6a031200a7850a27a440134@changeid >>>>> >>>>> .../boot/dts/qcom/sc7280-herobrine-crd.dts | 11 ++++++++ >>>>> .../qcom/sc7280-herobrine-herobrine-r1.dts | 11 ++++++++ >>>>> .../dts/qcom/sc7280-herobrine-villager-r0.dts | 25 +++++++++++++++++++ >>>>> arch/arm64/boot/dts/qcom/sc7280-qcard.dtsi | 1 - >>>>> 4 files changed, 47 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts b/arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts >>>>> index a4ac33c4fd59..b79d84d7870a 100644 >>>>> --- a/arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts >>>>> +++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts >>>>> @@ -134,6 +134,17 @@ &sdhc_2 { >>>>> status = "okay"; >>>>> }; >>>>> >>>>> +/* PINCTRL - ADDITIONS TO NODES IN PARENT DEVICE TREE FILES */ >>>> Please drop this line, this isn't msm-3.4. It's immediately obvious that >>>> if a pin is referenced by a label and it is not defined in this file >>>> (because otherwise it wouldn't be both defined and referenced here..), >>>> it comes from a previously included device tree. >>> In general these headings specify a change in sort ordering. Without >>> them then either we intersperse pinctrl overrides with other stuff, >>> which IMO is overall worse or people have no idea why the sort >>> ordering changes. >> I get what you mean, but at the end of the day, the entire machine DT >> specifies all machine-specific changes and only machine-specific >> changes. They all are a part of a bigger picture, sometimes being >> downstream from the SoC, sometimes downstream from a common board. I >> don't think it brings much benefit if at all to separate them into >> sections like these, if in the end they all correspond to modifications >> present in the hardware. In its current form, the sorting is all over >> the place, and ideally we could have labels sorted alphabetically. > I think overall DT just made it hard. In my mind the root of the > problem is actually that we're trying to avoid replicating hierarchy > from the dtsi files that we include. In other words, we try very hard > to do: > > &qup_i2c2_data_clk { > bias-disable; > }; > > Instead of replicating the hierarchy in the board dts files, like this: > > / { > soc@0 { > pinctrl@f100000 { > qup-i2c2-data-clk { > bias-disable;; > }; > }; > }; > }; > > (and, of course, you could replicate parts of the hierarchy too). It was attempted back in 8974 times, but things fell apart pretty quickly, as typos went unnoticed en masse and it resulted in various regressions from creating dead, useless code to things not working for supposedly no reason. Labels make it harder to mess things up like this, as referencing a non-existent one will simply break compilation. Sadly, they still don't fix typos in properties/compatibles, but we have dt-schema for that. > > When you avoid replicating things then it really causes everything to > become scattered / disorganized and I think there's a benefit to > trying to enforce some type of ordering. Going back to the 8974 example, we've come a really really really long way (you can compare with [1] for example), but yes, we can probably still do a bit better. > >> The present solution, in my opinion, causes more disarray as you first >> have to think about what is the change against and then find it in the >> corresponding subsection instead of thinking of it as a complete >> quote-on-quote diff against the parent DTSIs. > It's a fair opinion. I'd be interested to know if others feel the same > way. In general it feels like a style decision for the people working > on these boards, subject to the approval of the Qualcomm tree > maintainer(s). Sure, my opinion is not end-all-be-all. > > >> Plus, most DTs don't split >> it like that. > I will say that it's hard to compare the trogdor (and now herobrine) > situation with most other ARM boards out there. There are _a lot_ of > different variants and revisions and it's, IMO, more art than science > in trying to balance all of the tradeoffs between duplicating code and > ending up with unreadable spaghetti. I won't claim that we made the > right tradeoff in every case, but so far experience on trogdor has > been that things ended up being fairly understandable I think? I think the biggest problem for these devices is that often a single revision/model has something very different to others, which makes supporting it require more mess on both sides.. I think it is managed quite sanely, but I also think that /delete-node/ could be used more often instead of copying the same code in n places. While not at the same scale, we have to deal with this mess on Xperias where they are all based on per-SoC common boards and it makes little sense to keep them separate, but unifying them requires some clever positioning to commonize as much as possible. Konrad [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/boot/dts/qcom-msm8974.dtsi?h=v5.10.117 > > -Doug
On Tue, 24 May 2022 13:48:49 -0700, Douglas Anderson wrote: > This adds the touchscreen to the sc7280-herobrine-villager device > tree. Note that the touchscreen on villager actually uses the reset > line and thus we use the more specific "elan,ekth6915" compatible > which allows us to specify the reset. > > The fact that villager's touchscreen uses the reset line can be > contrasted against the touchscreen for CRD/herobrine-r1. On those > boards, even though the touchscreen goes to the display, it's not > hooked up to anything there. > > [...] Applied, thanks! [1/1] arm64: dts: qcom: sc7280: Add touchscreen to villager commit: e58539532bab3cbe5b1ba71d54db6d6b7d4eeced Best regards,
diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts b/arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts index a4ac33c4fd59..b79d84d7870a 100644 --- a/arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts +++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts @@ -134,6 +134,17 @@ &sdhc_2 { status = "okay"; }; +/* PINCTRL - ADDITIONS TO NODES IN PARENT DEVICE TREE FILES */ + +/* + * This pin goes to the display panel but then doesn't actually do anything + * on the panel itself (it doesn't connect to the touchscreen controller). + * We'll set a pullup here just to park the line. + */ +&ts_rst_conn { + bias-pull-up; +}; + /* PINCTRL - BOARD-SPECIFIC */ /* diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts b/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts index b69ca09d9bfb..c1647a85a371 100644 --- a/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts +++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts @@ -128,6 +128,17 @@ &sdhc_2 { status = "okay"; }; +/* PINCTRL - ADDITIONS TO NODES IN PARENT DEVICE TREE FILES */ + +/* + * This pin goes to the display panel but then doesn't actually do anything + * on the panel itself (it doesn't connect to the touchscreen controller). + * We'll set a pullup here just to park the line. + */ +&ts_rst_conn { + bias-pull-up; +}; + /* PINCTRL - BOARD-SPECIFIC */ /* diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine-villager-r0.dts b/arch/arm64/boot/dts/qcom/sc7280-herobrine-villager-r0.dts index d3d6ffad4eff..950b69448109 100644 --- a/arch/arm64/boot/dts/qcom/sc7280-herobrine-villager-r0.dts +++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine-villager-r0.dts @@ -46,6 +46,25 @@ trackpad: trackpad@2c { }; }; +ts_i2c: &i2c13 { + status = "okay"; + clock-frequency = <400000>; + + ap_ts: touchscreen@10 { + compatible = "elan,ekth6915"; + reg = <0x10>; + pinctrl-names = "default"; + pinctrl-0 = <&ts_int_conn>, <&ts_rst_conn>; + + interrupt-parent = <&tlmm>; + interrupts = <55 IRQ_TYPE_LEVEL_LOW>; + + reset-gpios = <&tlmm 54 GPIO_ACTIVE_LOW>; + + vcc33-supply = <&ts_avdd>; + }; +}; + &ap_sar_sensor_i2c { status = "okay"; }; @@ -81,6 +100,12 @@ &sdhc_1 { status = "okay"; }; +/* PINCTRL - ADDITIONS TO NODES IN PARENT DEVICE TREE FILES */ + +&ts_rst_conn { + bias-disable; +}; + /* PINCTRL - BOARD-SPECIFIC */ /* diff --git a/arch/arm64/boot/dts/qcom/sc7280-qcard.dtsi b/arch/arm64/boot/dts/qcom/sc7280-qcard.dtsi index d59002d4492e..404936c6bf20 100644 --- a/arch/arm64/boot/dts/qcom/sc7280-qcard.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7280-qcard.dtsi @@ -604,7 +604,6 @@ ts_int_conn: ts-int-conn { ts_rst_conn: ts-rst-conn { pins = "gpio54"; function = "gpio"; - bias-pull-up; drive-strength = <2>; }; };
This adds the touchscreen to the sc7280-herobrine-villager device tree. Note that the touchscreen on villager actually uses the reset line and thus we use the more specific "elan,ekth6915" compatible which allows us to specify the reset. The fact that villager's touchscreen uses the reset line can be contrasted against the touchscreen for CRD/herobrine-r1. On those boards, even though the touchscreen goes to the display, it's not hooked up to anything there. In order to keep the line parked on herobrine/CRD, we'll move the pullup from the qcard.dtsi file to the specific boards. This allows us to disable the pullup in the villager device tree since the pin is an output. Signed-off-by: Douglas Anderson <dianders@chromium.org> --- This uses bindings introduced in the patch ("dt-bindings: HID: i2c-hid: elan: Introduce bindings for Elan eKTH6915") [1]. [1] https://lore.kernel.org/r/20220523142257.v2.1.Iedc61f9ef220a89af6a031200a7850a27a440134@changeid .../boot/dts/qcom/sc7280-herobrine-crd.dts | 11 ++++++++ .../qcom/sc7280-herobrine-herobrine-r1.dts | 11 ++++++++ .../dts/qcom/sc7280-herobrine-villager-r0.dts | 25 +++++++++++++++++++ arch/arm64/boot/dts/qcom/sc7280-qcard.dtsi | 1 - 4 files changed, 47 insertions(+), 1 deletion(-)