mbox series

[0/4] Enable DisplayPort over USB-C on SONY Sagami

Message ID 20230321-topic-sagami_dp-v1-0-340c8bce4276@linaro.org
Headers show
Series Enable DisplayPort over USB-C on SONY Sagami | expand

Message

Konrad Dybcio March 21, 2023, 10:12 p.m. UTC
DisplayPort is there before DSI panel, kinda funny!

Depends on:

https://lore.kernel.org/linux-arm-msm/20230130-topic-sm8450-upstream-pmic-glink-v5-0-552f3b721f9e@linaro.org
https://lore.kernel.org/linux-arm-msm/20230206-topic-sm8450-upstream-dp-controller-v6-3-d78313cbc41d@linaro.org

Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
Konrad Dybcio (4):
      dt-bindings: usb: gpio-sbu-mux: Add OnSemi NB7VPQ904M mux
      arm64: dts: qcom: sm8350-sagami: Add PMIC GLINK
      arm64: dts: qcom: sm8350-sagami: Hook up USB-C Display Port
      arm64: dts: qcom: sm8350-nagara: Unify status property placement

 .../devicetree/bindings/usb/gpio-sbu-mux.yaml      |   1 +
 .../boot/dts/qcom/sm8350-sony-xperia-sagami.dtsi   | 162 ++++++++++++++++++---
 2 files changed, 146 insertions(+), 17 deletions(-)
---
base-commit: 52581937d6423c3bd15eb3894580ab87fe7308a1
change-id: 20230321-topic-sagami_dp-11f90e38d43c

Best regards,

Comments

Rob Herring March 30, 2023, 3:31 p.m. UTC | #1
On Tue, Mar 21, 2023 at 11:12:28PM +0100, Konrad Dybcio wrote:
> The OnSemi NB7VPQ904M Type-C DP altmode redriver provides SBU signals
> that can be used in with the gpio-sbu-mux driver. Document it.
> 
> Note that the -mux suffix is there to indicate that the gpio-sbu-mux
> driver interacts with the mux part of this otherwise quite sophisticated
> chip, leaving the "onnn,nb7vpq904m" compatible free for when a proper
> driver taking care of all of the chip's capabilities is introduced.

You should define a proper and complete binding. If you want to bind the 
gpio-sbu-mux driver to it now until you have a proper driver then that's 
fine. When you have such a driver, then you drop the compatible from the 
gpio-sbu-mux driver.

Note that having the fallback "gpio-sbu-mux" is somewhat problematic 
because the kernel has no mechanism to ensure you bind the most specific 
driver. For that to happen, it would have to support (automatically) 
unbinding one driver and binding to the more specific driver since one 
driver could be built-in and the other a module.

Rob
Konrad Dybcio March 30, 2023, 11 p.m. UTC | #2
On 30.03.2023 17:31, Rob Herring wrote:
> On Tue, Mar 21, 2023 at 11:12:28PM +0100, Konrad Dybcio wrote:
>> The OnSemi NB7VPQ904M Type-C DP altmode redriver provides SBU signals
>> that can be used in with the gpio-sbu-mux driver. Document it.
>>
>> Note that the -mux suffix is there to indicate that the gpio-sbu-mux
>> driver interacts with the mux part of this otherwise quite sophisticated
>> chip, leaving the "onnn,nb7vpq904m" compatible free for when a proper
>> driver taking care of all of the chip's capabilities is introduced.
> 
> You should define a proper and complete binding. If you want to bind the 
> gpio-sbu-mux driver to it now until you have a proper driver then that's 
> fine. When you have such a driver, then you drop the compatible from the 
> gpio-sbu-mux driver.
Okay, that makes perfect sense and is good to know. Perhaps even worth
documenting somewhere.

I think I'll delay resending this and get an "actual" driver going.

Konrad
> 
> Note that having the fallback "gpio-sbu-mux" is somewhat problematic 
> because the kernel has no mechanism to ensure you bind the most specific 
> driver. For that to happen, it would have to support (automatically) 
> unbinding one driver and binding to the more specific driver since one 
> driver could be built-in and the other a module.
> 
> Rob