Arnaud Ferraris [Sat, 16 Oct 2021 10:20:24 +0000 (12:20 +0200)]
arm64: dts: qcom: add 'chassis-type' property
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.
arm64: dts: qcom: sdm845: Drop standalone smem node
Now that the SMEM binding and driver allows the SMEM node to be
described in the reserved-memory region directly, move the compatible
and hwlock properties to the reserved-memory node and drop the
standadlone node.
Stephan Gerhold [Tue, 21 Sep 2021 15:21:19 +0000 (17:21 +0200)]
arm64: dts: qcom: msm8916: Drop underscore in node name
Using underscores in device tree nodes is not very common.
Additionally, the _region suffix in "smem_region@..." is not really
useful since it's obvious that it describes a reserved memory region.
Commit 0f6b380d580c ("arm64: dts: qcom: apq8016-sbc: Update modem and WiFi
firmware path") added "firmware-name"s to the APQ8016 SBC (DB410c) device
tree to separate the (test key)-signed firmware from other devices.
However, the added names are a bit confusing. The "modem" firmware used by
DB410c is actually a simplified version for APQ8016 that lacks most of the
modem functionality (phone calls, SMS etc) that is available on MSM8916.
Placing it in "qcom/msm8916/modem.mbn" suggests that it supports all
functionality for MSM and not just the reduced functionality for APQ.
Request the firmware from "qcom/apq8016/modem.mbn" instead to clarify this.
Do the same for "wcnss.mbn" for consistency (although the WCNSS firmware
works just fine on MSM8916).
Finally, add a "_sbc" suffix to the WCNSS_qcom_wlan_nv.bin firmware file.
It seems like the nv.bin firmware is somewhat board specific and can
therefore vary a bit from device to device. This makes it more clear
which board it is intended to be used for.
arm64: dts: qcom: sm6125: Improve indentation of multiline properties
Some multiline properties (spread out over multiple lines to keep length
in check) were not indented properly, leading to misalignment with the
items above. The DT file is still small enough to address this early in
the process.
Stephan Gerhold [Tue, 28 Sep 2021 11:29:45 +0000 (13:29 +0200)]
arm64: dts: qcom: msm8916-longcheer-l8150: Use &pm8916_usbin extcon
At the moment, longcheer-l8150 is using a dummy extcon-usb-gpio device
that permanently enables USB gadget mode. This workaround allows USB
to work but is actually wrong and confusing. The "vbus-gpio" used there
refers to an unused (floating) GPIO that is pulled up to make
extcon-usb-gpio report USB gadget mode permanently.
Replace this with the new &pm8916_usbin extcon device that actually
reports if an USB cable is attached or not. This allows the USB PHY
to be turned off when there is no USB cable attached and is much
cleaner overall.
Stephan Gerhold [Tue, 28 Sep 2021 11:29:44 +0000 (13:29 +0200)]
arm64: dts: qcom: pm8916: Add pm8941-misc extcon for USB detection
At the moment, USB gadget mode on MSM8916 works only with an extcon
device that reports the correct USB mode. This might be because the
USB PHY needs to be configured appropriately.
Unfortunately there is currently no simple approach to get such an
extcon device during early bring-up. The extcon device for USB VBUS
(i.e. gadget/peripheral mode) is typically provided by the charging
driver which is almost always very complex to port.
On pretty much all devices with PM8916, the USB VBUS is also connected
to the PM8916 "USB_IN" pad, no matter if they use the linear charger
integrated into PM8916 or not. The state of this pad can be checked
with the "USBIN_VALID" interrupt of PM8916.
The "qcom,pm8941-misc" binding exists to expose an "usb_vbus" and/or
"usb_id" interrupt from the PMIC as an extcon device.
Add a &pm8916_usbin node to pm8916.dtsi which can be used as simple
extcon device for devices that are currently lacking a proper charger
driver.
Stephan Gerhold [Tue, 28 Sep 2021 11:29:43 +0000 (13:29 +0200)]
arm64: dts: qcom: pm8916: Remove wrong reg-names for rtc@6000
While removing the size from the "reg" properties in pm8916.dtsi,
commit bd6429e81010 ("ARM64: dts: qcom: Remove size elements from
pmic reg properties") mistakenly also removed the second register
address for the rtc@6000 device. That one did not represent the size
of the register region but actually the address of the second "alarm"
register region of the rtc@6000 device.
Now there are "reg-names" for two "reg" elements, but there is actually
only one "reg" listed.
Since the DT schema for "qcom,pm8941-rtc" only expects one "reg"
element anyway, just drop the "reg-names" entirely to fix this.
Fixes: bd6429e81010 ("ARM64: dts: qcom: Remove size elements from pmic reg properties") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210928112945.25310-1-stephan@gerhold.net
This device has a physical matrix keyboard, connected to a GPIO
expander, for which there's still no support yet.
Though, some of the keys are connected to the MSM8998 GPIOs and not
as a matrix, so these can be added.
Stephan Gerhold [Mon, 16 Aug 2021 18:18:10 +0000 (20:18 +0200)]
arm64: dts: qcom: msm8916: Fix Secondary MI2S bit clock
At the moment, playing audio on Secondary MI2S will just end up getting
stuck, without actually playing any audio. This happens because the wrong
bit clock is configured when playing audio on Secondary MI2S.
The PRI_I2S_CLK (better name: SPKR_I2S_CLK) is used by the SPKR audio mux
block that provides both Primary and Secondary MI2S.
The SEC_I2S_CLK (better name: MIC_I2S_CLK) is used by the MIC audio mux
block that provides Tertiary MI2S. Quaternary MI2S is also part of the
MIC audio mux but has its own clock (AUX_I2S_CLK).
This means that (quite confusingly) the SEC_I2S_CLK is not actually
used for Secondary MI2S as the name would suggest. Secondary MI2S
needs to have the same clock as Primary MI2S configured.
Fix the clock list for the lpass node in the device tree and add
a comment to clarify this confusing naming. With these changes,
audio can be played correctly on Secondary MI2S.
So far there were no interrupts set up for the BMC150 accelerometer
+ magnetometer combo because they were broken for some reason.
It turns out Longcheer L8150 actually has a BMC156 which is very similar
to BMC150, but only has an INT2 pin for the accelerometer part.
This requires some minor changes in the bmc150-accel driver which is now
supported by using the more correct bosch,bmc156_accel compatible.
Unfortunately it looks like even INT2 is not functional on most boards
because the interrupt line is not actually connected to the BMC156.
However, there are two pads next to the chip that can be shorted
to make it work if needed.
While at it, add the missing interrupts for the magnetometer part
and extra BMG160 gyroscope, those seem to work without any problems.
Also correct the magnetometer compatible to bosch,bmc156_magn for clarity
(no functional difference for the magnetometer part).
Konrad Dybcio [Thu, 23 Sep 2021 16:22:02 +0000 (18:22 +0200)]
arm64: dts: qcom: sm6350: Add device tree for Sony Xperia 10 III
Add initial SM6350 SoC and Sony Xperia 10 III (PDX213, Lena platform) device
trees. There is no sign of another Lena devices on the horizon, so a common
DTSI is not created for now. 10 III features a Full HD OLED display and 5G
support, among other nice things like USB3.
The bootloader is VERY unpleasant, to get a bootable setup you have to run:
// You have to either pull vbmeta{"","_system"} from
// /dev/block/bootdevice/by-name/ or build one as a part of AOSP build process
fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img
fastboot --disable-verity --disable-verification flash vbmeta_system \
vbmeta_system.img
fastboot flash boot mainline.img
fastboot erase dtbo // This will take approx 70s...
fastboot reboot
Sibi Sankar [Thu, 16 Sep 2021 13:59:27 +0000 (19:29 +0530)]
arm64: dts: qcom: sm8350: Use QMP property to control load state
Use the Qualcomm Mailbox Protocol (QMP) property to control the load
state resources on SM8350 SoCs and drop deprecated power-domains exposed
by AOSS QMP node.
Sibi Sankar [Thu, 16 Sep 2021 13:59:26 +0000 (19:29 +0530)]
arm64: dts: qcom: sm8250: Use QMP property to control load state
Use the Qualcomm Mailbox Protocol (QMP) property to control the load
state resources on SM8250 SoCs and drop deprecated power-domains exposed
by AOSS QMP node.
Sibi Sankar [Thu, 16 Sep 2021 13:59:25 +0000 (19:29 +0530)]
arm64: dts: qcom: sm8150: Use QMP property to control load state
Use the Qualcomm Mailbox Protocol (QMP) property to control the load
state resources on SM8150 SoCs and drop deprecated power-domains exposed
by AOSS QMP node.
Sibi Sankar [Thu, 16 Sep 2021 13:59:24 +0000 (19:29 +0530)]
arm64: dts: qcom: sdm845: Use QMP property to control load state
Use the Qualcomm Mailbox Protocol (QMP) property to control the load
state resources on SDM845 SoCs and drop deprecated power-domains exposed
by AOSS QMP node.
Sibi Sankar [Thu, 16 Sep 2021 13:59:23 +0000 (19:29 +0530)]
arm64: dts: qcom: sc7280: Use QMP property to control load state
Use the Qualcomm Mailbox Protocol (QMP) property to control the load
state resources on SC7280 SoCs and drop deprecated power-domains exposed
by AOSS QMP node.
Sibi Sankar [Thu, 16 Sep 2021 13:59:22 +0000 (19:29 +0530)]
arm64: dts: qcom: sc7180: Use QMP property to control load state
Use the Qualcomm Mailbox Protocol (QMP) property to control the load
state resources on SC7180 SoCs and drop deprecated power-domains exposed
by AOSS QMP node.
Douglas Anderson [Thu, 23 Sep 2021 15:14:04 +0000 (08:14 -0700)]
arm64: dts: qcom: sc7180: Base homestar's power coefficients in reality
The commit 82ea7d411d43 ("arm64: dts: qcom: sc7180: Base dynamic CPU
power coefficients in reality") and the commit be0416a3f917 ("arm64:
dts: qcom: Add sc7180-trogdor-homestar") passed each other in the
tubes that make up the Internet. Despite the fact the patches didn't
cause a merge conflict, they need to account for each other. Do that.
Fixes: 82ea7d411d43 ("arm64: dts: qcom: sc7180: Base dynamic CPU power coefficients in reality") Fixes: be0416a3f917 ("arm64: dts: qcom: Add sc7180-trogdor-homestar") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210923081352.1.I2a2ee0ac428a63927324d65022929565aa7d8361@changeid
Add configuration for the LAB and IBB regulators (in boost mode):
this platform has smartphones with three different display sizes,
hence different displays requiring different voltage.
The common configuration parameters have been put in the common
device-tree, while specific voltage specs and soft-start-us are
variant specific, so they have been put into the machine specific
dts file.
arm64: dts: qcom: msm8998-xperia: Add RMI4 touchscreen support
All of the devices in the Sony Yoshino platform are using a Synaptics
RMI4-compatible touch IC with identical pins and supplies: enable the
I2C-5 bus and add the rmi4-i2c node along with the required pin
configurations.
arm64: dts: qcom: msm8998: Introduce support for Sony Yoshino platform
This commit introduces support for the Sony Yoshino platform, using
the MSM8998 SoC, including:
- Sony Xperia XZ1 (codename Poplar),
- Sony Xperia XZ1 Compact (codename Lilac),
- Sony Xperia XZ Premium (codename Maple).
All of the three aforementioned smartphones are sharing a 99%
equal board configuration, with very small differences between
each other, which is the reason for the introduction of a common
msm8998-sony-xperia-yoshino DT.
This base configuration includes regulators and project-wide pin
configurations and it's made to boot to a serial console.
Shawn Guo [Tue, 24 Aug 2021 02:19:18 +0000 (10:19 +0800)]
arm64: dts: qcom: pm660: Add reboot mode support
It turns out that the pm660 PON is a GEN2 device. Update the compatible
to "qcom,pm8998-pon" and add reboot mode support, so that devices can be
rebooted into bootloader and recovery mode. Tested on Xiaomi Redmi Note
7 phone.
While at it, drop the unnecessary newline between 'compatible' and 'reg'
property.
Uart5 is treated as dedicated debug uart.Change the
compatible as "qcom,geni-uart" in SoC DT to make it generic
and later update it as "qcom,geni-debug-uart" in sc7280-idp
Add interconnects and power-domains. Split the pinctrl
functions and correct the gpio pins.
arch/arm64/boot/dts/qcom/sm6125.dtsi:497.19-503.6: Warning (unit_address_format): /soc/timer@f120000/frame@0f121000: unit name should not have leading 0s
arch/arm64/boot/dts/qcom/sm6125.dtsi:505.19-510.6: Warning (unit_address_format): /soc/timer@f120000/frame@0f123000: unit name should not have leading 0s
arch/arm64/boot/dts/qcom/sm6125.dtsi:512.19-517.6: Warning (unit_address_format): /soc/timer@f120000/frame@0f124000: unit name should not have leading 0
arm64: dts: qcom: sc7180: Use maximum drive strength values for eMMC
The current drive strength values are not sufficient on non discrete
boards and this leads to CRC errors during switching to HS400 enhanced
strobe mode.
Hardware simulation results on non discrete boards shows up that use the
maximum drive strength values for data and command lines could helps
in avoiding these CRC errors.
So, update data and command line drive strength values to maximum.
According to Documentation/devicetree/bindings/mmc/sdhci-msm.txt
a SoC specific compatible should be used in addition to the IP version
compatible, but for some reason it was never added for MSM8916.
Add the "qcom,msm8916-sdhci" compatible additionally to make the
device tree match the documented bindings.
Specify recovery and bootloader magic values to be programmed by the
qcom-pon driver. This allows the bootloader to handle
reboot-to-bootloader functionality.
Douglas Anderson [Mon, 30 Aug 2021 15:06:37 +0000 (08:06 -0700)]
arm64: dts: qcom: sc7280: Move the SD CD GPIO pin out of the dtsi file
There's nothing magical about GPIO91 and boards could use different
GPIOs for card detect. Move the pin out of the dtsi file and to the
only existing board file.
Bjorn Andersson [Mon, 31 May 2021 22:44:53 +0000 (15:44 -0700)]
arm64: dts: qcom: apq8016-sbc: Update modem and WiFi firmware path
The firmware for the modem and WiFi subsystems platform specific and is
signed with a OEM specific key (or a test key). In order to support more
than a single device it is therefor not possible to rely on the default
path and stash these files directly in the firmware directory.
This has already been addressed for other platforms, but the APQ8016 SBC
(aka db410c) was never finished upstream.
arm64: dts: qcom: sc7280: fix display port phy reg property
Existing display port phy reg property is derived from usb phy which
map display port phy pcs to wrong address which cause aux init
with wrong address and prevent both dpcd read and write from working.
Fix this problem by assigning correct pcs address to display port
phy reg property.
Homestar is a trogdor variant. The DT bits are essentially the same as
in the downstream tree, except for:
- skip -rev0 and rev1 which were early builds and have their issues,
it's not very useful to support them upstream
- don't include the .dtsi for the MIPI cameras, which doesn't exist
upstream
The PMI8998 PMIC has a WLED backlight controller, which is used on
most MSM8998 and SDM845 based devices: add a base configuration for
it and keep it disabled.
This contains only the PMIC specific configuration that does not
change across boards; parameters like number of strings, OVP and
current limits are product specific and shall be specified in the
product DT in order to achieve functionality.
arm64: dts: qcom: sc7180-trogdor: Delete ADC config for unused thermistors
The charger thermistor on Lazor, CoachZ rev1 and Pompom rev1+2 is
either the wrong part or not stuffed at all, the same is true for
the skin temperature thermistor on CoachZ rev1. The corresponding
thermal zones are already disabled for these devices, in addition
delete the ADC nodes of the thermistors.
For Lazor and CoachZ rev1 also disable the PM6150 ADC and thermal
monitor since none of the ADC channels is used.
Robert Marko [Thu, 2 Sep 2021 22:03:25 +0000 (00:03 +0200)]
arm64: dts: qcom: ipq8074: remove USB tx-fifo-resize property
tx-fifo-resize is now added by default by the dwc3-qcom driver
to the SNPS DWC3 child node.
So, lets drop the tx-fifo-resize property from dwc3-qcom nodes
as having it there will cause the dwc3-qcom driver to error and
abort probe with:
[ 1.362938] dwc3-qcom 8af8800.usb: unable to add property
[ 1.368405] dwc3-qcom 8af8800.usb: failed to register DWC3 Core, err=-17
arm64: dts: qcom: sc7180: Base dynamic CPU power coefficients in reality
The sc7180's dynamic-power-coefficient violates the device tree bindings.
The bindings (arm/cpus.yaml) say that the units for the
dynamic-power-coefficient are supposed to be "uW/MHz/V^2". The ones for
sc7180 aren't this. Qualcomm arbitrarily picked 100 for the "little" CPUs
and then picked a number for the big CPU based on this.
At the time, there was a giant dicussion about this. Apparently Qualcomm
Engineers were instructed not to share the actual numbers here. As part
of the discussion, I pointed out [1] that these numbers shouldn't really
be secret since once a device is shipping anyone can just run a script
and produce them. This patch is the result of running the script I posted
in that discussion on sc7180-trogdor-coachz, which is currently available
for purchase by consumers.
As you can see, the calculations aren't perfectly consistent but
roughly you could say about 480 for big and 137 for little.
The ratio between these numbers isn't quite the same as the ratio
between the two numbers that Qualcomm used. Perhaps this is because
Qualcomm measured something slightly different than the 64-bit version
of dhrystone 2.2 or perhaps it's because they fudged these numbers a
bit (and fudged the capacity-dmips-mhz). As per discussion [2], let's
use the numbers I came up with and also un-fudge
capacity-dmips-mhz. While unfudging capacity-dmips-mhz, let's scale it
so that bigs are 1024 which seems to be the common practice.
In general these numbers don't need to be perfectly exact. In fact,
they can't be since the CPU power depends a lot on what's being run on
the CPU and the big/little CPUs are each more or less efficient in
different operations. Historically running the 32-bit vs. 64-bit
versions of dhrystone produced notably different numbers, though I
didn't test this time.
We also need to scale all of the sustainable-power numbers by the same
amount. I scale ones related to the big CPUs by the adjustment I made
to the big dynamic-power-coefficient and the ones related to the
little CPUs by the adjustment I made to the little
dynamic-power-coefficient.
arm64: dts: qcom: msm8996: Add support for the Xiaomi MSM8996 platform
There are 5 Xiaomi devices with the MSM8996 SoC:
- Mi 5 (gemini): MSM8996 + PMI8994
- Mi Note 2 (scorpio): MSM8996 Pro + PMI8996
- Mi 5s (capricorn): MSM8996 Pro + PMI8996
- Mi Mix (lithium): MSM8996 Pro + PMI8996
- Mi 5s Plus (natrium): MSM8996 Pro + PMI8996
These devices share a common board design with only a few differences.
Add support for the common board, as well as support for the Mi Note 2.
arm64: dts: qcom: msm8998: Configure Adreno GPU and related IOMMU
The MSM8998 SoC includes an Adreno 540.1 GPU, with a maximum frequency
of 710MHz. This GPU may or may not accept a ZAP shader, depending on
platform configuration, so adding a zap-shader node is left to the
board DT.
arm64: dts: qcom: msm8998: Move qfprom iospace to calibrated values
The QFPROM iospace was (erroneously, I believe) set to the uncalibrated
fuse start address, but every driver only needs - and will always only
need - only calibrated values.
Move the iospace forward to the calibrated values start to avoid
offsetting every fuse definition.
Obviously, the only defined fuse (qusb2_hstx_trim) was also fixed to
remove the offset, in order to comply with this change.
arm64: dts: qcom: msm8998: Fix CPU/L2 idle state latency and residency
The entry/exit latency and minimum residency in state for the idle
states of MSM8998 were ..bad: first of all, for all of them the
timings were written for CPU sleep but the min-residency-us param
was miscalculated (supposedly, while porting this from downstream);
Then, the power collapse states are setting PC on both the CPU
cluster *and* the L2 cache, which have different timings: in the
specific case of L2 the times are higher so these ones should be
taken into account instead of the CPU ones.
This parameter misconfiguration was not giving particular issues
because on MSM8998 there was no CPU scaling at all, so cluster/L2
power collapse was rarely (if ever) hit.
When CPU scaling is enabled, though, the wrong timings will produce
SoC unstability shown to the user as random, apparently error-less,
sudden reboots and/or lockups.
This set of parameters are stabilizing the SoC when CPU scaling is
ON and when power collapse is frequently hit.
projects / thirdparty / kernel / linux.git / log
