| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Now that we no longer have fixed addresses for the firmware memory
regions, disable them by default and only enable them together with
the actual user in the board DT.
This frees up unnecessary reserved memory for boards that do not use
some of the remoteprocs and allows moving selected device-specific
properties (such as firmware size) to the board-specific DT part in
the next step.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20230911-msm8916-rmem-v1-7-b7089ec3e3a1@gerhold.net
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Venus needs firmware that is usually signed with a device-specific key.
There are also devices that might not need it (especially during
bring-up), so let's follow more recent SoCs and disable it by default.
Enable it explicitly for all current devices except msm8916-mtp. That
one has just UART enabled currently so it cannot really benefit from
Venus.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Link: https://lore.kernel.org/r/20230911-msm8916-rmem-v1-1-b7089ec3e3a1@gerhold.net
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
properties
Use id-gpios and vbus-gpios instead.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Shawn Guo <shawnguo@kernel.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Heiko Stuebner <heiko@sntech.de> #rockchip
Link: https://lore.kernel.org/r/20230724103914.1779027-7-alexander.stein@ew.tq-group.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
The audio pinctrl in MSM8916/MSM8939 is very similar but still has
subtle differences, e.g. &cdc_pdm_lines_act on MSM8916 vs
&cdc_pdm_lines_default on MSM8939.
Make this consistent and use the chance to cleanup all of the audio
pinctrl: Drop unneeded outer nodes and replace the names taken over
from the vendor kernel with more clear ones that are similar to the
actual pinctrl function.
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
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-4-11f540b51c93@gerhold.net
|
|
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
|
|
The current SD card detect pinctrl setup configures bias-pull-up for
the "default" (active) case and bias-disable for the "sleep" case.
Before commit b5c833b703cc ("mmc: sdhci-msm: Set IO pins in low power
state during suspend") the pull up was permanently active. Since then
it is only active when a valid SD card is inserted.
This does not really make sense: For an active-low CD, the pull up is
needed to pull the GPIO high when the card is not inserted. When the
card gets inserted CD is shorted to ground (low). This means right now
the pull-up is removed exactly when it is needed to detect the next
card insertion. Generally, applying different bias for CD does not
really make sense. It should always stay the same so card removals and
insertions can be detected properly.
The reason why card detection still works fine in practice is that most
boards seem to have external pull up on the CD pin. However, this means
that there is no need to configure an internal pull-up at all and we
can keep bias-disable permanently.
There are also some boards with different CD polarity (acer-a1-724) and
with different GPIO number (huawei-g7). All in all this makes it
obvious that the CD pin is board-specific and the pinctrl for it should
be defined in the board DT.
Move it to the boards that need it and use bias-disable permanently for
the boards that seem to have external pull-up. The vendor device tree
for msm8939-sony-xperia-kanuti-tulip suggests that it needs the
internal pull-up permanently [1] so it gets bias-pull-up to be sure.
[1]: https://github.com/sonyxperiadev/kernel/blob/57b5050e340f40a88e1ddb8d16fd9adb44418923/arch/arm/boot/dts/qcom/msm8939-kanuti_tulip.dtsi#L634-L636
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-1-11f540b51c93@gerhold.net
|
|
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
|
|
All definitions in pm8916.dtsi use the &pm8916_ label prefix, only the
codec uses the &wcd_codec label. &wcd_codec is confusing because the
codec on MSM8916 is split into a "wcd-digital" and "wcd-analog" part
and both could be described with &wcd_codec.
Let's just name it &pm8916_codec so it's consistent with all other PMIC
device nodes.
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-5-bec0f5fb46fb@gerhold.net
|
|
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
|
|
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
|
|
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
|
|
Not every device has something connected to the digital audio codec
in MSM8916 and/or the analog audio codec in PM8916. Disable those by
default so the hardware is only powered up when necessary.
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-4-54d4960a05fc@gerhold.net
|
|
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
|
|
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
|
|
Switch '//' comments to C-style /* */ and fix up the contents of some.
Make sure all multiline C-style commends begin with just '/*' with
the comment text starting on a new line.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221107145522.6706-2-konrad.dybcio@linaro.org
|
|
DT schema expects TLMM pin configuration nodes to be named with
'-state' suffix and their optional children with '-pins' suffix.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221024002356.28261-2-krzysztof.kozlowski@linaro.org
|
|
The node names should be generic and DT schema expects certain pattern
(e.g. with key/button/switch).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220616005333.18491-21-krzysztof.kozlowski@linaro.org
|
|
The huawei-g7 uses the msm8916-wcd-digital/analog audio codecs similar
to apq8016-sbc, so we can mostly copy paste it from there to make audio
work correctly. The main difference is the hphl-jack-type-normally-open
property, which is needed to avoid inverted audio jack detection.
Note that at least on my device the jack detection is not fully
reliable: sometimes headphones are detected as headsets (with
microphone). However, this is not a big problem for typical usage.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220410195113.13646-3-stephan@gerhold.net
|
|
The comment with installation instructions in the huawei-g7 device tree
is a bit misleading and does not describe the recommended installation
steps very well. The bootloader is actually not patched; to avoid all
trouble with the vendor bootloader it is easier to bypass it completely
by jumping to a custom bootloader (e.g. based on the open-source LK
released by Qualcomm).
To avoid confusion, simplify the comment to state only the problem
and then refer to the wiki article which contains detailed suggested
installation instructions. This will also make it easier to keep it
up to date with new developments in the future.
Fixes: 55056b229189 ("arm64: dts: qcom: msm8916: Add device tree for Huawei Ascend G7")
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220410195113.13646-2-stephan@gerhold.net
|
|
A new 'chassis-type' root node property has recently been approved for
the device-tree specification, in order to provide a simple way for
userspace to detect the device form factor and adjust their behavior
accordingly.
This patch fills in this property for end-user devices (such as laptops,
smartphones and tablets) based on Qualcomm ARM64 processors.
Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>
Reviewed-by: Stephan Gerhold <stephan@gerhold.net> # msm8916
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20211016102025.23346-4-arnaud.ferraris@collabora.com
|
|
The Huawei Ascend G7 supports NFC using the NXP PN547, which is
supported by the nxp-nci-i2c driver in mainline. It seems to detect
NFC tags using "nfctool" just fine, although it seems like there
are not really any useful applications making use of the Linux NFC
subsystem. :(
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210514104328.18756-5-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
|
|
The display on the Huawei Ascend G7 is supplied by a TI TPS65132
regulator. The panel needs a driver in mainline first, but the
TPS65132 is already supported in mainline by the tps65132 driver.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210514104328.18756-4-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
|
|
The Huawei Ascend G7 has 3 sensors, all supported by existing kernel drivers:
1. Kionix KX023-1025 accelerometer (kxcjk-1023)
2. Asahi Kasei AK09911 magnetometer (ak8975)
3. Avago APDS9930 proximity/light sensor (tsl2772)
Add them to the huawei-g7 device tree.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210514104328.18756-3-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
|
|
The Huawei Ascend G7 has a Synaptics "C199HW-006" touchscreen,
supplied by pm8916_l17 and pm8916_l16. Add it to the device tree
and reduce the maximum allowed voltage for pm8916_l16 to 1.8V since
we really should not use more for an I/O supply.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210514104328.18756-2-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
|
|
The Huawei Ascend G7 is a smartphone from Huawei based on MSM8916.
It's fairly similar to the other MSM8916 devices, the only notable
exception are the "cd-gpios" for detecting if a SD card was inserted:
It looks like Huawei forgot to re-route this to gpio38, so the correct
GPIO seems to be gpio56 on this device.
Note: The original firmware from Huawei can only boot 32-bit kernels.
To boot arm64 kernels it is necessary to flash 64-bit TZ/HYP firmware
with EDL, e.g. taken from the DragonBoard 410c. This works because Huawei
forgot to set up (firmware) secure boot for some reason.
Also note that Huawei no longer provides bootloader unlock codes.
This can be bypassed by patching the bootloader from a custom HYP firmware,
making it think the bootloader is unlocked. I use a modified version of
qhypstub [1], that patches a single instruction in the Huawei bootloader.
The device tree contains initial support for the Huawei Ascend G7 with:
- UART (untested, probably available via some test points)
- eMMC/SD card
- Buttons
- Notification LED (combination of 3 GPIO LEDs)
- Vibrator
- WiFi/Bluetooth (WCNSS)
- USB
[1]: https://github.com/msm8916-mainline/qhypstub
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210514104328.18756-1-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
|
