Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31 |
|
#
c943e4c5 |
| 30-May-2023 |
Stephan Gerhold <stephan@gerhold.net> |
arm64: dts: qcom: msm8916/39: Consolidate SDC pinctrl
MSM8939 has the SDC pinctrl consolidated in two &sdcN_default and &sdcN_sleep states, while MSM8916 has all pins separated. Make this consistent
arm64: dts: qcom: msm8916/39: Consolidate SDC pinctrl
MSM8939 has the SDC pinctrl consolidated in two &sdcN_default and &sdcN_sleep states, while MSM8916 has all pins separated. Make this consistent by consolidating them for MSM8916 well.
Use this as a chance to define default pinctrl in the SoC.dtsi and only let boards that add additional definitions (such as cd-gpios) override it.
For MSM8939 just make the label consistent with the other pinctrl definitions (they do not have a _state suffix).
Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230529-msm8916-pinctrl-v1-2-11f540b51c93@gerhold.net
show more ...
|
#
154f23a8 |
| 29-May-2023 |
Stephan Gerhold <stephan@gerhold.net> |
arm64: dts: qcom: msm8916: Move aliases to boards
MSM8939 has the aliases defined separately for each board (because there could be (theoretically) a board where the slots are numbered differently.
arm64: dts: qcom: msm8916: Move aliases to boards
MSM8939 has the aliases defined separately for each board (because there could be (theoretically) a board where the slots are numbered differently. To make MSM8916 and MSM8939 more consistent do the same for all MSM8916 boards and move aliases there.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230525-msm8916-labels-v1-6-bec0f5fb46fb@gerhold.net
show more ...
|
#
835f9395 |
| 29-May-2023 |
Stephan Gerhold <stephan@gerhold.net> |
arm64: dts: qcom: msm8916/39: Clean up MDSS labels
Right now MDSS related definitions cannot be properly grouped together in board DTs because the labels do not use consistent prefixes. The DSI PHY
arm64: dts: qcom: msm8916/39: Clean up MDSS labels
Right now MDSS related definitions cannot be properly grouped together in board DTs because the labels do not use consistent prefixes. The DSI PHY label is particularly weird because the DSI number is at the end (&dsi_phy0) while DSI itself is called &dsi0.
Follow the example of more recent SoCs and give all the MDSS related nodes a consistent label that allows proper grouping.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230525-msm8916-labels-v1-4-bec0f5fb46fb@gerhold.net
show more ...
|
#
c310ca82 |
| 29-May-2023 |
Stephan Gerhold <stephan@gerhold.net> |
arm64: dts: qcom: msm8916/39: Rename &blsp1_uartN -> &blsp_uartN
For some reason the BLSP UART controllers have a label with a number behind blsp (&blsp1_uartN) while I2C/SPI are named without (&bls
arm64: dts: qcom: msm8916/39: Rename &blsp1_uartN -> &blsp_uartN
For some reason the BLSP UART controllers have a label with a number behind blsp (&blsp1_uartN) while I2C/SPI are named without (&blsp_i2cN). This is confusing, especially for proper node ordering in board DTs.
Right now all board DTs are ordered as if the number behind blsp does not exist (&blsp_i2cN comes before &blsp1_uartN). Strictly speaking correct ordering would be the other way around ('1' comes before '_').
End this confusion by giving the UART controllers consistent labels. There is just one BLSP on MSM8916/39 so the number is redundant.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230525-msm8916-labels-v1-2-bec0f5fb46fb@gerhold.net
show more ...
|
#
41e22c2f |
| 29-May-2023 |
Stephan Gerhold <stephan@gerhold.net> |
arm64: dts: qcom: msm8916: Rename &msmgpio -> &tlmm
MSM8916 is the only ARM64 Qualcomm SoC that is still using the old &msmgpio name. Change this to &tlmm to avoid confusion.
Note that the node ord
arm64: dts: qcom: msm8916: Rename &msmgpio -> &tlmm
MSM8916 is the only ARM64 Qualcomm SoC that is still using the old &msmgpio name. Change this to &tlmm to avoid confusion.
Note that the node ordering does not change because the MSM8916 device trees have pinctrl separated at the bottom (similar to sc7180).
Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230525-msm8916-labels-v1-1-bec0f5fb46fb@gerhold.net
show more ...
|
Revision tags: v6.1.30 |
|
#
b0a8f16a |
| 17-May-2023 |
Stephan Gerhold <stephan@gerhold.net> |
arm64: dts: qcom: msm8916: Define regulator constraints next to usage
Right now each MSM8916 device has a huge block of regulator constraints with allowed voltages for each regulator. For lack of be
arm64: dts: qcom: msm8916: Define regulator constraints next to usage
Right now each MSM8916 device has a huge block of regulator constraints with allowed voltages for each regulator. For lack of better documentation these voltages are often copied as-is from the vendor device tree, without much extra thought.
Unfortunately, the voltages in the vendor device trees are often misleading or even wrong, e.g. because:
- There is a large voltage range allowed and the actual voltage is only set somewhere hidden in some messy vendor driver. This is often the case for pm8916_{l14,l15,l16} because they have a broad range of 1.8-3.3V by default.
- The voltage is actually wrong but thanks to the voltage constraints in the RPM firmware it still ends up applying the correct voltage.
To have proper regulator constraints it is important to review them in context of the usage. The current setup in the MSM8916 device trees makes this quite hard because each device duplicates the standard voltages for components of the SoC and mixes those with minor device-specific additions and dummy voltages for completely unused regulators.
The actual usage of the regulators for the SoC components is in msm8916-pm8916.dtsi, so it can and should also define the related voltage constraints. These are not board-specific but defined in the APQ8016E/PM8916 Device Specification. The board DT can then focus on describing the actual board-specific regulators, which makes it much easier to review and spot potential mistakes there.
Note that this commit does not make any functional change. All used regulators still have the same regulator constraints as before. Unused regulators do not have regulator constraints anymore because most of these were too broad or even entirely wrong. They should be added back with proper voltage constraints when there is an actual usage.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230510-msm8916-regulators-v1-7-54d4960a05fc@gerhold.net
show more ...
|
#
35575082 |
| 17-May-2023 |
Stephan Gerhold <stephan@gerhold.net> |
arm64: dts: qcom: msm8916: Fix regulator constraints
The regulator constraints for most MSM8916 devices (except DB410c) were originally taken from Qualcomm's msm-3.10 vendor device tree (for lack of
arm64: dts: qcom: msm8916: Fix regulator constraints
The regulator constraints for most MSM8916 devices (except DB410c) were originally taken from Qualcomm's msm-3.10 vendor device tree (for lack of better documentation). Unfortunately it turns out that Qualcomm's voltages are slightly off as well and do not match the voltage constraints applied by the RPM firmware.
This means that we sometimes request a specific voltage but the RPM firmware actually applies a much lower or higher voltage. This is particularly critical for pm8916_l11 which is used as SD card VMMC regulator: The SD card can choose a voltage from the current range of 1.8 - 2.95V. If it chooses to run at 1.8V we pretend that this is fine but the RPM firmware will still silently end up configuring 2.95V. This can be easily reproduced with a multimeter or by checking the SPMI hardware registers of the regulator.
Fix this by making the voltages match the actual "specified range" in the PM8916 Device Specification which is enforced by the RPM firmware.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230510-msm8916-regulators-v1-3-54d4960a05fc@gerhold.net
show more ...
|
Revision tags: v6.1.29, v6.1.28 |
|
#
06a9f50c |
| 05-May-2023 |
Yang Xiwen <forbidden405@outlook.com> |
arm64: dts: qcom: msm8916-ufi: make UDC dual mode
It's possible to use this device with a (non-standard) hub to get USB working in host mode, but dr_mode="peripheral" prevents the UDC to do so. Remo
arm64: dts: qcom: msm8916-ufi: make UDC dual mode
It's possible to use this device with a (non-standard) hub to get USB working in host mode, but dr_mode="peripheral" prevents the UDC to do so. Remove dr_mode="peripheral" and add usb-role-switch so that it defaults to otg mode and can be switched to host mode in userspace.
Signed-off-by: Yang Xiwen <forbidden405@outlook.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/TYZPR04MB632102315884225B7343533B96729@TYZPR04MB6321.apcprd04.prod.outlook.com
show more ...
|
Revision tags: v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16 |
|
#
32444424 |
| 09-Mar-2023 |
Stephan Gerhold <stephan.gerhold@kernkonzept.com> |
arm64: dts: qcom: msm8916: Move WCN compatible to boards
On MSM8916 the wireless connectivity functionality (WiFi/Bluetooth) is split into the digital part inside the SoC and the analog RF part insi
arm64: dts: qcom: msm8916: Move WCN compatible to boards
On MSM8916 the wireless connectivity functionality (WiFi/Bluetooth) is split into the digital part inside the SoC and the analog RF part inside a supplementary WCN36xx chip. For MSM8916, three different options exist:
- WCN3620 (WLAN 802.11 b/g/n 2.4 GHz + Bluetooth) - WCN3660B (WLAN 802.11 a/b/g/n 2.4/5 GHz + Bluetooth) - WCN3680B (WLAN 802.11ac 2.4/5 GHz + Bluetooth)
Choosing one of these is up to the board vendor. This means that the compatible belongs into the board-specific DT part so people porting new boards pay attention to set the correct compatible.
Right now msm8916.dtsi sets "qcom,wcn3620" as default compatible, which does not work at all for boards that have WCN3660B or WCN3680B.
Remove the default compatible from msm8196.dtsi and move it to the board DT as follows:
- Boards with only &pronto { status = "okay"; } used the default "qcom,wcn3620" so far. They now set this explicitly for &wcnss_iris. - Boards with &pronto { ... iris { compatible = "qcom,wcn3660b"; }}; already had an override that just moves to &wcnss_iris now. - For msm8916-samsung-a2015-common.dtsi the WCN compatible differs for boards making use of it (a3u: wcn3620, a5u: wcn3660b, e2015: wcn3620) so the definitions move to the board-specific DT part.
Since this requires touching all the board DTs, use this as a chance to name the WCNSS-related labels consistently, so everything is grouped properly when sorted alphabetically.
No functional change, just clean-up for more clarity & easier porting. Aside from ordering the generated DTBs are identical.
Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230309091452.1011776-1-stephan.gerhold@kernkonzept.com
show more ...
|
Revision tags: v6.1.15 |
|
#
eaba4166 |
| 01-Mar-2023 |
Yang Xiwen <forbidden405@foxmail.com> |
arm64: dts: qcom: msm8916-ufi: Fix sim card selection pinctrl
The previous commit mistakenly introduced sim_ctrl_default as pinctrl, this is incorrect, the interface for sim card selection varies be
arm64: dts: qcom: msm8916-ufi: Fix sim card selection pinctrl
The previous commit mistakenly introduced sim_ctrl_default as pinctrl, this is incorrect, the interface for sim card selection varies between different devices and should not be placed in the dtsi.
This commit selects external SIM card slot for ufi001c as default. uf896 selects the correct SIM card slot automatically, thus does not need this pinctrl node.
Fixes: faf69431464b ("arm64: dts: qcom: msm8916-thwc: Add initial device trees") Signed-off-by: Yang Xiwen <forbidden405@foxmail.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/tencent_7036BCA256055D05F8C49D86DF7F0E2D1A05@qq.com
show more ...
|
Revision tags: v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6 |
|
#
faf69431 |
| 14-Jan-2023 |
Yang Xiwen <forbidden405@foxmail.com> |
arm64: dts: qcom: msm8916-thwc: Add initial device trees
This commit adds support for the ufi-001C and uf896 WiFi/LTE dongle made by Tong Heng Wei Chuang based on MSM8916. uf896 is another variant f
arm64: dts: qcom: msm8916-thwc: Add initial device trees
This commit adds support for the ufi-001C and uf896 WiFi/LTE dongle made by Tong Heng Wei Chuang based on MSM8916. uf896 is another variant for the usb stick. The board design differs by using different gpios for the keys and leds.
Note: The original firmware does not support 64-bit OS. It is necessary to flash 64-bit TZ firmware to boot arm64.
Currently supported: - All CPU cores - Buttons - LEDs - Modem - SDHC - USB Device Mode - UART
Co-developed-by: Jaime Breva <jbreva@nayarsystems.com> Signed-off-by: Jaime Breva <jbreva@nayarsystems.com> Co-developed-by: Nikita Travkin <nikita@trvn.ru> Signed-off-by: Nikita Travkin <nikita@trvn.ru> Signed-off-by: Yang Xiwen <forbidden405@foxmail.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org>
show more ...
|