Message ID | 20241022-x1e80100-qcp-sdhc-v3-2-46c401e32cbf@linaro.org |
---|---|
State | New |
Headers | show |
Series | arm64: dts: qcom: x1e80100: Describe SDCs and enable support on QCP | expand |
On 22.10.2024 12:46 PM, Abel Vesa wrote: > Describe the SDC2 default and sleep state pins configuration > in TLMM. Do this in SoC dtsi file since they will be shared > across multiple boards. > > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > --- Not very useful on its own but okay.. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Konrad
On 24-10-25 20:34:19, Konrad Dybcio wrote: > On 22.10.2024 12:46 PM, Abel Vesa wrote: > > Describe the SDC2 default and sleep state pins configuration > > in TLMM. Do this in SoC dtsi file since they will be shared > > across multiple boards. > > > > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > > --- > > Not very useful on its own but okay.. Fair enough. For some reason, I'm not able to get sdc4 pinconf to work. And there is no board that has a slot populated for it. So I split the pinconf for sdc2 into a separate patch to make it more obvious that sdc4 one is missing. Let me know if you still want to me to squash this into the patch that adds the controller nodes. > > Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > > Konrad Thanks for reviewing. Abel
On 24-10-28 14:10:54, Konrad Dybcio wrote: > On 28.10.2024 9:48 AM, Abel Vesa wrote: > > On 24-10-25 20:34:19, Konrad Dybcio wrote: > >> On 22.10.2024 12:46 PM, Abel Vesa wrote: > >>> Describe the SDC2 default and sleep state pins configuration > >>> in TLMM. Do this in SoC dtsi file since they will be shared > >>> across multiple boards. > >>> > >>> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > >>> --- > >> > >> Not very useful on its own but okay.. > > > > Fair enough. For some reason, I'm not able to get sdc4 pinconf > > to work. > > Any chance you tried to define 'sdc4_cmd' etc.? This one seems to have > sdc4 pins on gpio127..=132 Yes. But since the sdc4 pins can have other functions and since there is no device that uses them (yet). Shouldn't we just skip describing the sdc4 pinconf entirely as that should be done on a per-board basis? > > Konrad
On 1.11.2024 12:21 PM, Abel Vesa wrote: > On 24-10-28 14:10:54, Konrad Dybcio wrote: >> On 28.10.2024 9:48 AM, Abel Vesa wrote: >>> On 24-10-25 20:34:19, Konrad Dybcio wrote: >>>> On 22.10.2024 12:46 PM, Abel Vesa wrote: >>>>> Describe the SDC2 default and sleep state pins configuration >>>>> in TLMM. Do this in SoC dtsi file since they will be shared >>>>> across multiple boards. >>>>> >>>>> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> >>>>> --- >>>> >>>> Not very useful on its own but okay.. >>> >>> Fair enough. For some reason, I'm not able to get sdc4 pinconf >>> to work. >> >> Any chance you tried to define 'sdc4_cmd' etc.? This one seems to have >> sdc4 pins on gpio127..=132 > > Yes. > > But since the sdc4 pins can have other functions and since there is no > device that uses them (yet). Shouldn't we just skip describing the sdc4 > pinconf entirely as that should be done on a per-board basis? By that argument, why describe the controller in the first place :| The possible pins are predefined and physically wired up inside the soc Konrad
On 24-11-04 15:06:29, Konrad Dybcio wrote: > On 1.11.2024 12:21 PM, Abel Vesa wrote: > > On 24-10-28 14:10:54, Konrad Dybcio wrote: > >> On 28.10.2024 9:48 AM, Abel Vesa wrote: > >>> On 24-10-25 20:34:19, Konrad Dybcio wrote: > >>>> On 22.10.2024 12:46 PM, Abel Vesa wrote: > >>>>> Describe the SDC2 default and sleep state pins configuration > >>>>> in TLMM. Do this in SoC dtsi file since they will be shared > >>>>> across multiple boards. > >>>>> > >>>>> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > >>>>> --- > >>>> > >>>> Not very useful on its own but okay.. > >>> > >>> Fair enough. For some reason, I'm not able to get sdc4 pinconf > >>> to work. > >> > >> Any chance you tried to define 'sdc4_cmd' etc.? This one seems to have > >> sdc4 pins on gpio127..=132 > > > > Yes. > > > > But since the sdc4 pins can have other functions and since there is no > > device that uses them (yet). Shouldn't we just skip describing the sdc4 > > pinconf entirely as that should be done on a per-board basis? > > By that argument, why describe the controller in the first place :| > > The possible pins are predefined and physically wired up inside the soc Right, unlike the sdc2 ones, these can be muxed to a different function. This is why I their pinconf need to be described in the board dts rather than SoC dtsi. Since there is no board that supports it, we don't describe them at all. As for the controller, we should still describe it even if we don't have ways to test it yet. > > Konrad
diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi index 2d0befd6ba0ea11fdf2305d23c0cd8743de303dc..59cedd16b174f01d0db90caefd2555f5516c5f7a 100644 --- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi +++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi @@ -5741,6 +5741,46 @@ rx-pins { bias-disable; }; }; + + sdc2_default: sdc2-default-state { + clk-pins { + pins = "sdc2_clk"; + drive-strength = <16>; + bias-disable; + }; + + cmd-pins { + pins = "sdc2_cmd"; + drive-strength = <10>; + bias-pull-up; + }; + + data-pins { + pins = "sdc2_data"; + drive-strength = <10>; + bias-pull-up; + }; + }; + + sdc2_sleep: sdc2-sleep-state { + clk-pins { + pins = "sdc2_clk"; + drive-strength = <2>; + bias-disable; + }; + + cmd-pins { + pins = "sdc2_cmd"; + drive-strength = <2>; + bias-pull-up; + }; + + data-pins { + pins = "sdc2_data"; + drive-strength = <2>; + bias-pull-up; + }; + }; }; apps_smmu: iommu@15000000 {
Describe the SDC2 default and sleep state pins configuration in TLMM. Do this in SoC dtsi file since they will be shared across multiple boards. Signed-off-by: Abel Vesa <abel.vesa@linaro.org> --- arch/arm64/boot/dts/qcom/x1e80100.dtsi | 40 ++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+)