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(-)
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,
--
Abel Vesa <abel.vesa@linaro.org>
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 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 Wed, Apr 30, 2025 at 12:39:13PM +0300, 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? Yes, this sounds logical. DP3 is repurposed for eDP on a board level, so the SoC configuration should not contain any specific config for that port. > > > > > Greetings, > > > > -- Sebastian > > -- With best wishes Dmitry
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
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 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 For the series: Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> > > 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, > -- > Abel Vesa <abel.vesa@linaro.org> > -- With best wishes Dmitry
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. Either way: Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
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. I can squash them if the consensus is that it's not backporting. > > Either way: > > Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Thanks! Abel
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
On 25-04-29 11:13:04, Johan Hovold wrote: > 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. Sure. Will drop Fixes tags and squash in the next version. > > Johan Abel
© 2016 - 2026 Red Hat, Inc.