- 10 Jun, 2021 8 commits
-
-
Stephan Gerhold authored
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.netSigned-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org>
-
Stephan Gerhold authored
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/qhypstubSigned-off-by:
-
Stephen Boyd authored
This spi flash part is actually being clocked at 37.5MHz, not 25MHz, because of the way the clk driver is rounding up the rate that is requested to the nearest supported frequency. Let's update the frequency here, and remove the TODO because this is the fastest frequency we're going to be able to use here. Reviewed-by:
Douglas Anderson <dianders@chromium.org> Cc: Douglas Anderson <dianders@chromium.org> Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210519054030.3217704-1-swboyd@chromium.orgSigned-off-by:
-
Srinivasa Rao Mandadapu authored
Add wakeup delay for fixing PoP noise during capture begin. Reviewed-by:
Judy Hsiao <judyhsiao@chromium.org> Signed-off-by:
Srinivasa Rao Mandadapu <srivasam@codeaurora.org> Link: https://lore.kernel.org/r/20210513122429.25295-1-srivasam@codeaurora.orgSigned-off-by:
-
Stephen Boyd authored
This compatible string isn't present upstream. Let's drop the node as it isn't used. Reviewed-by:
-
Stephen Boyd authored
This compatible string isn't present upstream. Let's drop the node as it isn't used. Reviewed-by:
-
Stephen Boyd authored
We don't use the PON module on Trogdor devices. Instead the reboot reason is sort of stored in the 'eventlog' and the bootloader figures out if the boot is abnormal and records that there. Disable the PON node and then drop the power key disabling because that's a child node that will no longer be enabled if the PON node is disabled. Reviewed-by:
-
Wenchao Han authored
On coachz it could be observed that SPI_CLK voltage level was only 1.4V during active transfers because the drive strength was too weak. The line hadn't finished slewing up by the time we started driving it down again. Using a drive strength of 8 lets us achieve the correct voltage level of 1.8V. Though the worst problems were observed on coachz hardware, let's do this across the board for trogdor devices. Scoping other boards shows that this makes the clk line look nicer on them too and doesn't introduce any problems. Only the clk line is adjusted, not any data lines. Because SPI isn't a DDR protocol we only sample the data lines on either rising or falling edges, not both. That means the clk line needs to toggle twice as fast as data lines so having the higher drive strength is more important there. Signed-off-by:
Wenchao Han <hanwenchao@huaqin.corp-partner.google.com> [dianders: Adjust author real name; adjust commit message] Signed-off-by:
-
- 06 Jun, 2021 10 commits
-
-
Felipe Balbi authored
Microsoft Surface Duo is based on SM8150 chipset. This new Device Tree is a copy of sm8150-mtp with a the addition of the volume up key and relevant i2c nodes. Signed-off-by:
Felipe Balbi <felipe.balbi@microsoft.com> Link: https://lore.kernel.org/r/20210603122923.1919624-1-balbi@kernel.orgSigned-off-by:
-
Alex Elder authored
Enable IPA on the SDM845 MTP. Signed-off-by:
Alex Elder <elder@linaro.org> Link: https://lore.kernel.org/r/20200519123258.29228-1-elder@linaro.orgSigned-off-by:
-
Sujit Kautkar authored
Some SC7180 based boards do not have external pull-up for cd-gpio. Set this pin to internal pull-up for sleep config to avoid frequent regulator toggle events. Reviewed-by:
Sujit Kautkar <sujitka@chromium.org> Link: https://lore.kernel.org/r/20210602121313.v3.2.I52f30ddfe62041b7e6c3c362f0ad8f695ac28224@changeidSigned-off-by:
-
Sujit Kautkar authored
Move sdc1/sdc2 pinconf from SoC specific DT file to board specific DT files Reviewed-by:
-
Stephan Gerhold authored
The Samsung Galaxy A3/A5 both have a Samsung S3FWRN5 NFC chip that works quite well with the s3fwrn5 driver in the Linux NFC subsystem. The clock setup for the NFC chip is a bit special (although this seems to be a common approach used for Qualcomm devices with NFC): The NFC chip has an output GPIO that is asserted whenever the clock is needed to function properly. On the A3/A5 this is wired up to PM8916 GPIO2, which is then configured with a special function (NFC_CLK_REQ or BB_CLK2_REQ). Enabling the rpmcc RPM_SMD_BB_CLK2_PIN clock will then instruct PM8916 to automatically enable the clock whenever the NFC chip requests it. The advantage is that the clock is only enabled when needed and we don't need to manage it ourselves from the NFC driver. Note that for some reason Samsung decided to connect the I2C pins to GPIOs where no hardware I2C bus is available, so we need to fall back to software bit-banging with i2c-gpio. Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by:
-
Stephan Gerhold authored
The Samsung Galaxy A3/A5 use a Richtek RT5033 PMIC as battery fuel gauge, charger, flash LED and for some regulators. For now, only add the fuel gauge/battery device to the device tree, so we can check the remaining battery percentage. The other RT5033 drivers need some more work first before they can be used properly. Signed-off-by:
-
Stephan Gerhold authored
On the Samsung Galaxy A5 the touch key is supplied by a single fixed regulator (enabled via GPIO 97) that supplies both MCU and LED. Add it to the device tree. Signed-off-by:
-
Michael Srba authored
The touch key MCU and LED is supplied by two separate fixed regulators that can be enabled through GPIO 86 and 60. Add them to the device tree. Signed-off-by:
Michael Srba <Michael.Srba@seznam.cz> [stephan: extend commit message] Signed-off-by:
-
Stephan Gerhold authored
The Samsung Galaxy A3/A5 both have two capacitive touch keys, connected to an ABOV MCU. It implements the same interface as implemented by the tm2-touchkey driver and works just fine with the coreriver,tc360-touchkey compatible. It's probably actually some Samsung-specific interface that they implement with different MCUs. Note that for some reason Samsung decided to connect this to GPIOs where no hardware I2C bus is available, so we need to fall back to software bit-banging using i2c-gpio. The vdd/vcc-supply is board-specific and will be added separately for a3u/a5u. Co-developed-by:
-
Matthias Kaehlcke authored
Add a thermal zone for the pm6150 on-die temperature. The system should try to shut down orderly when the temperature reaches the critical trip point at 115°C, otherwise the PMIC will perform a HW power off at 145°C. Reviewed-by:
Matthias Kaehlcke <mka@chromium.org> Link: https://lore.kernel.org/r/20210603081215.v2.1.Id4510e9e4baaa3f6c9fdd5cdf4d8606e63c262e3@changeidSigned-off-by:
-
- 01 Jun, 2021 1 commit
-
-
Judy Hsiao authored
Adds label for MI2S secondary block to allow follower projects to override for the four speaker support which uses I2S SD1 line on gpio52 pin. Reviewed-by:
-
- 31 May, 2021 21 commits
-
-
Rajendra Nayak authored
The sc7280 IDP board is also called senor in the Chrome OS builds. Add the "google,senor" compatible so coreboot/depthcharge knows what device tree blob to pick Reviewed-by:
Rajendra Nayak <rnayak@codeaurora.org> Link: https://lore.kernel.org/r/1619674827-26650-2-git-send-email-rnayak@codeaurora.orgSigned-off-by:
-
Rajendra Nayak authored
Document the google,senor board based on sc7280 SoC Acked-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Sibi Sankar authored
Add miscellaneous nodes to boot the Wireless Processor Subsystem (WPSS) on SC7280 SoCs. Signed-off-by:
Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/1619508824-14413-6-git-send-email-sibis@codeaurora.orgSigned-off-by:
-
Sibi Sankar authored
Add WPSS remote processor client index to Inter-Processor Communication Controller (IPCC) block. Acked-by:
-
Sujit Kautkar authored
Move rmtfs memory region so that it does not overlap with system RAM (kernel data) when KAsan is enabled. This puts rmtfs right after mba_mem which is not supposed to increase beyond 0x94600000 Reviewed-by:
-
Taniya Das authored
Add support for the video, gpu, display, lpass clock controller device nodes for SC7280 SoC. Signed-off-by:
Taniya Das <tdas@codeaurora.org> Link: https://lore.kernel.org/r/1618020280-5470-3-git-send-email-tdas@codeaurora.org [bjorn: Dropped includes, as they are not present in v5.13-rc1] Signed-off-by:
-
Taniya Das authored
Add cpufreq HW device node to scale 4-Silver/3-Gold/1-Gold+ cores on SC7280 SoCs. Reviewed-by:
-
Matthias Kaehlcke authored
Add ADC and thermal monitor configuration for skin temperature, plus a thermal zone that monitors the skin temperature and uses the big cores as cooling devices. CoachZ rev1 is stuffed with an incompatible thermistor for the skin temperature, disable the thermal zone for rev1 to avoid the use of bogus temperature values. Reviewed-by:
-
Douglas Anderson authored
As per Dmitry Baryshkov [1]: a) The 2nd "reg" should be 0x3c because "Offset 0x38 is USB3_DP_COM_REVISION_ID3 (not used by the current driver though)." b) The 3rd "reg" "is a serdes region and qmp_v3_dp_serdes_tbl contains registers 0x148 and 0x154." I think because the 3rd "reg" is a serdes region we should just use the same size as the 1st "reg"? [1] https://lore.kernel.org/r/ee5695bb-a603-0dd5-7a7f-695e919b1af1@linaro.orgReviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
-
Jonathan Marek authored
Use sm8250 compatibles instead of sdm845 compatibles Reviewed-by:
Jonathan Marek <jonathan@marek.ca> Signed-off-by:
-
Stephen Boyd authored
We should indicate that we're not using the HPD pin on this device, per the binding document. Otherwise if code in the future wants to enable HPD in the bridge when this property is absent we'll be enabling HPD when it isn't supposed to be used. Presumably this board isn't using hpd on the bridge. Reviewed-by:
-
Serge Semin authored
In accordance with the DWC USB3 bindings the corresponding node name is suppose to comply with the Generic USB HCD DT schema, which requires the USB nodes to have the name acceptable by the regexp: "^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly named. Signed-off-by:
Serge Semin <Sergey.Semin@baikalelectronics.ru> Acked-by:
Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by:
-
Stephen Boyd authored
We should indicate that we're not using the HPD pin on this device, per the binding document. Otherwise if code in the future wants to enable HPD in the bridge when this property is absent we'll be wasting power powering hpd when we don't use it on trogdor boards. We didn't notice this before because the kernel driver blindly disables hpd, but that won't be true for much longer. Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Petr Vorel authored
Reserve GPIO pins 85-88 as these aren't meant to be accessible from the application CPUs (causes reboot). Yet another fix similar to 91345867, 5f8d3ab1, which is needed to allow angler to boot after 3edfb7bd ("gpiolib: Show correct direction from the beginning"). Fixes: feeaf56a ("arm64: dts: msm8994 SoC and Huawei Angler (Nexus 6P) support") Signed-off-by:
Petr Vorel <petr.vorel@gmail.com> Reviewed-by:
Konrad Dybcio <konrad.dybcio@somainline.org> Link: https://lore.kernel.org/r/20210415193913.1836153-1-petr.vorel@gmail.comSigned-off-by:
-
Konrad Dybcio authored
Fix the compatible to make the driver probe and tell the driver where to look for the "xo" clock to make sure everything works. Then we get a happy (eh, happier) 8996: somainline-sdcard:/home/konrad# cat /sys/kernel/debug/clk/pwrcl_pll/clk_rate 1152000000 Don't backport without "arm64: dts: qcom: msm8996: Add CPU opps", as the system fails to boot without consumers for these clocks. Signed-off-by:
-
Loic Poulain authored
Add the operating points capabilities of the kryo CPUs, that can be used for frequency scaling. There are two differents operating point tables, one for the big cluster and one for the LITTLE cluster. This frequency scaling support can then be used as a passive cooling device (cpufreq cooling device). Only add nominal fmax for now, since there is no dynamic control of VDD APC (s11..) which is statically set at its nominal value. Original patch link: https://patchwork.kernel.org/project/linux-arm-msm/patch/1595253740-29466-6-git-send-email-loic.poulain@linaro.org/Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> [konrad: drop the thermals part, rebase and remove spaces within <>] Signed-off-by:
-
Matthias Kaehlcke authored
CoachZ rev3 uses a 100k NTC thermistor for the charger temperatures, instead of the 47k NTC that is stuffed in earlier revisions. Add .dts files for rev3. The 47k NTC currently isn't supported by the PM6150 ADC driver. Disable the charger thermal zone for rev1 and rev2 to avoid the use of bogus temperature values. This also gets rid of the explicit DT files for rev2 and handles rev2 in the rev1 .dts instead. There was some back and forth downstream involving the 'dmic_clk_en' pin, after that was sorted out the DT for rev1 and rev2 is the same. Signed-off-by:
-
Matthias Kaehlcke authored
The only kernel visible change with respect to rev2 is that pompom rev3 changed the charger thermistor from a 47k to a 100k NTC to use a thermistor which is supported by the PM6150 ADC driver. Disable the charger thermal zone for pompom rev1 and rev2 to avoid the use of bogus temperature values from the unsupported thermistor. Signed-off-by:
-
Matthias Kaehlcke authored
Commit f73558cc83d1 ("arm64: dts: qcom: sc7180: Disable charger thermal zone for lazor") disables the charger thermal zone for specific lazor revisions due to an unsupported thermistor type. The initial idea was to disable the thermal zone for older revisions and leave it enabled for newer ones that use a supported thermistor. Finally the thermistor won't be changed on newer revisions, hence the thermal zone should be disabled for all lazor (and limozeen) revisions. Instead of disabling it per revision do it once in the shared .dtsi for lazor. Signed-off-by: -
Roja Rani Yarubandi authored
We had introduced the QUP-CORE ICC path to put proxy votes from QUP wrapper on behalf of earlycon, if other users of QUP-CORE turn off this clock before the real console is probed, unclocked access to HW was seen from earlycon. With ICC sync state support proxy votes are no longer need as ICC will ensure that the default bootloader votes are not removed until all it's consumer are probed. We can safely remove ICC path for QUP-CORE clock from QUP wrapper device. Signed-off-by:
Roja Rani Yarubandi <rojay@codeaurora.org> Signed-off-by:
Akash Asthana <akashast@codeaurora.org> Reviewed-by:
-
Vinod Koul authored
Some node unit addresses were put wrongly in the dts, resulting in below warning when run with W=1 arch/arm64/boot/dts/qcom/sm8350.dtsi:693.34-702.5: Warning (simple_bus_reg): /soc@0/thermal-sensor@c222000: simple-bus unit address format error, expected "c263000" arch/arm64/boot/dts/qcom/sm8350.dtsi:704.34-713.5: Warning (simple_bus_reg): /soc@0/thermal-sensor@c223000: simple-bus unit address format error, expected "c265000" arch/arm64/boot/dts/qcom/sm8350.dtsi:1180.32-1185.5: Warning (simple_bus_reg): /soc@0/interconnect@90e0000: simple-bus unit address format error, expected "90c0000" Fix by correcting to the correct address as given in reg node Reviewed-by:
Robert Foss <robert.foss@linaro.org> Signed-off-by:
Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20210513060733.382420-1-vkoul@kernel.orgSigned-off-by:
-
