| Message ID | 20250429-x1e80100-dts-drop-useless-dp-compatible-override-v1-0-058847814d70@linaro.org |
|---|---|
| Headers | show |
| Series | arm64: dts: qcom: x1e80100-*: Drop useless DP3 compatible override | expand |
On Tue, Apr 29, 2025 at 12:05:58PM +0300, Abel Vesa wrote: > On 25-04-29 10:57:44, Johan Hovold wrote: > > On Tue, Apr 29, 2025 at 10:42:28AM +0300, Abel Vesa wrote: > > > It all started with the support for CRD back when we had different > > > compatibles for eDP and DP. Meanwhile, that has been sorted out and it > > > is now figured out at runtime while using only the DP compatible. > > > > > > It's almost funny how this got copied over from CRD and spread to all > > > X Elite platforms. > > > > > > TBH, the best reason to drop it ASAP is to make sure this doesn't spread > > > beyond X Elite to newer platforms. > > > > > > Functionally nothing changes. > > > > > > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > > > --- > > > Abel Vesa (7): > > > arm64: dts: qcom: x1e-crd: Drop useless DP3 compatible override > > > arm64: dts: acom: x1e80100-qcp: Drop useless DP3 compatible override > > > arm64: dts: qcom: x1e80100-t14s: Drop useless DP3 compatible override > > > arm64: dts: qcom: x1e80100-s15: Drop useless DP3 compatible override > > > arm64: dts: qcom: x1e80100-hp-x14: Drop useless DP3 compatible override > > > arm64: dts: qcom: x1e80100: Drop useless DP3 compatible override > > > arm64: dts: qcom: x1e80100-romulus: Drop useless DP3 compatible override > > > > Since this is essentially a clean up perhaps you should have squashed > > these into one patch. > > I was actually thinking that before sending, but then I decided to add > the Fixes tag to each one. Since it's such a trivial worthless cleanup, > I wasn't sure if the Fixes tags were worth it either. Right, since it's not a bug you should probably have skipped the Fixes tags too. > I can squash them if the consensus is that it's not backporting. We should definitely not backport these as they are not fixing any bugs. Johan
Hi, On Tue, Apr 29, 2025 at 10:42:28AM +0300, Abel Vesa wrote: > It all started with the support for CRD back when we had different > compatibles for eDP and DP. Meanwhile, that has been sorted out and it > is now figured out at runtime while using only the DP compatible. > > It's almost funny how this got copied over from CRD and spread to all > X Elite platforms. > > TBH, the best reason to drop it ASAP is to make sure this doesn't spread > beyond X Elite to newer platforms. > > Functionally nothing changes. Looking at the diff I wonder if this part should also be simplified: /delete-property/ #sound-dai-cells; This is done by all upstream X1E boards, so maybe just drop the #sound-dai-cells directly in x1e80100.dtsi? Greetings, -- Sebastian
On 4/30/25 01:26, Sebastian Reichel wrote: > Hi, > > On Tue, Apr 29, 2025 at 10:42:28AM +0300, Abel Vesa wrote: >> ... > Looking at the diff I wonder if this part should also be simplified: > > /delete-property/ #sound-dai-cells; > > This is done by all upstream X1E boards, so maybe just drop the > #sound-dai-cells directly in x1e80100.dtsi? > This is for phy configurations where a display panel is connected that has no sound channels. Not guaranteed that it's always on mdss_dp3. with best regards Jens Gathe
On 25-04-30 01:26:13, Sebastian Reichel wrote: > Hi, > > On Tue, Apr 29, 2025 at 10:42:28AM +0300, Abel Vesa wrote: > > It all started with the support for CRD back when we had different > > compatibles for eDP and DP. Meanwhile, that has been sorted out and it > > is now figured out at runtime while using only the DP compatible. > > > > It's almost funny how this got copied over from CRD and spread to all > > X Elite platforms. > > > > TBH, the best reason to drop it ASAP is to make sure this doesn't spread > > beyond X Elite to newer platforms. > > > > Functionally nothing changes. > > Looking at the diff I wonder if this part should also be simplified: > > /delete-property/ #sound-dai-cells; > > This is done by all upstream X1E boards, so maybe just drop the > #sound-dai-cells directly in x1e80100.dtsi? Yeah, I'm not sure about that. Though the DP3 PHY is currently used as eDP, I think it could be used as DP. So I think it makes more sense to keep the DP3 controller as is in the SoC dtsi and delete the #sound-dai-cells property in each board specific dts. Don't know if it will ever be the case with this SoC, but maybe someone will use DP3 with the PHY configured as DP rather than eDP. Not sure if I'm 100% right about this though. Dmitry, Bjorn, do you think that is accurate enough? > > Greetings, > > -- Sebastian
On 4/30/25 11:39 AM, Abel Vesa wrote: > On 25-04-30 01:26:13, Sebastian Reichel wrote: >> Hi, >> >> On Tue, Apr 29, 2025 at 10:42:28AM +0300, Abel Vesa wrote: >>> It all started with the support for CRD back when we had different >>> compatibles for eDP and DP. Meanwhile, that has been sorted out and it >>> is now figured out at runtime while using only the DP compatible. >>> >>> It's almost funny how this got copied over from CRD and spread to all >>> X Elite platforms. >>> >>> TBH, the best reason to drop it ASAP is to make sure this doesn't spread >>> beyond X Elite to newer platforms. >>> >>> Functionally nothing changes. >> >> Looking at the diff I wonder if this part should also be simplified: >> >> /delete-property/ #sound-dai-cells; >> >> This is done by all upstream X1E boards, so maybe just drop the >> #sound-dai-cells directly in x1e80100.dtsi? > > Yeah, I'm not sure about that. > > Though the DP3 PHY is currently used as eDP, I think it could be used > as DP. So I think it makes more sense to keep the DP3 controller as is > in the SoC dtsi and delete the #sound-dai-cells property in each board > specific dts. Don't know if it will ever be the case with this SoC, but > maybe someone will use DP3 with the PHY configured as DP rather than > eDP. > > Not sure if I'm 100% right about this though. > > Dmitry, Bjorn, do you think that is accurate enough? I'd say just keep it everywhere, the physical capability of the controller to send audio streams is there, but is left unused by the specific eDP usecase (which is determined dynamically) Konrad
It all started with the support for CRD back when we had different compatibles for eDP and DP. Meanwhile, that has been sorted out and it is now figured out at runtime while using only the DP compatible. It's almost funny how this got copied over from CRD and spread to all X Elite platforms. TBH, the best reason to drop it ASAP is to make sure this doesn't spread beyond X Elite to newer platforms. Functionally nothing changes. Signed-off-by: Abel Vesa <abel.vesa@linaro.org> --- Abel Vesa (7): arm64: dts: qcom: x1e-crd: Drop useless DP3 compatible override arm64: dts: acom: x1e80100-qcp: Drop useless DP3 compatible override arm64: dts: qcom: x1e80100-t14s: Drop useless DP3 compatible override arm64: dts: qcom: x1e80100-s15: Drop useless DP3 compatible override arm64: dts: qcom: x1e80100-hp-x14: Drop useless DP3 compatible override arm64: dts: qcom: x1e80100: Drop useless DP3 compatible override arm64: dts: qcom: x1e80100-romulus: Drop useless DP3 compatible override arch/arm64/boot/dts/qcom/x1-crd.dtsi | 1 - arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi | 1 - arch/arm64/boot/dts/qcom/x1e80100-asus-vivobook-s15.dts | 1 - arch/arm64/boot/dts/qcom/x1e80100-hp-omnibook-x14.dts | 1 - arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts | 1 - arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi | 1 - arch/arm64/boot/dts/qcom/x1e80100-qcp.dts | 1 - 7 files changed, 7 deletions(-) --- base-commit: 7e69ad9a1f7ba8554c4d3d1ccbffcccafcd45c2e change-id: 20250429-x1e80100-dts-drop-useless-dp-compatible-override-db8562c6b7cd Best regards,