[ Upstream commit e526cb03e2 ]
The last cell of 'gpio-ranges' should be number of GPIO pins, and in
case of qcom platform it should match msm_pinctrl_soc_data.ngpio rather
than msm_pinctrl_soc_data.ngpio - 1.
This fixes the problem that when the last GPIO pin in the range is
configured with the following call sequence, it always fails with
-EPROBE_DEFER.
pinctrl_gpio_set_config()
pinctrl_get_device_gpio_range()
pinctrl_match_gpio_range()
Fixes: 16951b490b ("arm64: dts: qcom: sm8250: Add TLMM pinctrl node")
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Link: https://lore.kernel.org/r/20210303033106.549-4-shawn.guo@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit de3abdf3d1 ]
The last cell of 'gpio-ranges' should be number of GPIO pins, and in
case of qcom platform it should match msm_pinctrl_soc_data.ngpio rather
than msm_pinctrl_soc_data.ngpio - 1.
This fixes the problem that when the last GPIO pin in the range is
configured with the following call sequence, it always fails with
-EPROBE_DEFER.
pinctrl_gpio_set_config()
pinctrl_get_device_gpio_range()
pinctrl_match_gpio_range()
Fixes: e13c6d144f ("arm64: dts: qcom: sm8150: Add base dts file")
Cc: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Link: https://lore.kernel.org/r/20210303033106.549-3-shawn.guo@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 02058fc383 ]
The last cell of 'gpio-ranges' should be number of GPIO pins, and in
case of qcom platform it should match msm_pinctrl_soc_data.ngpio rather
than msm_pinctrl_soc_data.ngpio - 1.
This fixes the problem that when the last GPIO pin in the range is
configured with the following call sequence, it always fails with
-EPROBE_DEFER.
pinctrl_gpio_set_config()
pinctrl_get_device_gpio_range()
pinctrl_match_gpio_range()
Fixes: bc2c806293 ("arm64: dts: qcom: sdm845: Add gpio-ranges to TLMM node")
Cc: Evan Green <evgreen@chromium.org>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Link: https://lore.kernel.org/r/20210303033106.549-2-shawn.guo@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 3716a583fe ]
When the BMC150 accelerometer/magnetometer was added to the device tree,
the sensors were working without specifying any regulator supplies,
likely because the regulators were on by default and then never turned off.
For some reason, this is no longer the case for pm8916_l17, which prevents
the sensors from working in some cases.
Now that the bmc150_accel/bmc150_magn drivers can enable necessary
regulators, declare the necessary regulator supplies to make the sensors
work again.
Fixes: 079f81acf1 ("arm64: dts: qcom: msm8916-samsung-a2015: Add accelerometer/magnetometer")
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210111175358.97171-1-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 826e6faf49 ]
Unlike most MSM8916 boards, samsung-a5u uses WCN3660B instead of
WCN3620 to support the 5 GHz band additionally.
WCN3660B has similar requirements as WCN3620, but it needs the XO
clock to run at 48 MHz instead of 19.2 MHz. So far it was possible
to describe that configuration using the qcom,wcn3680 compatible.
However, as of commit 8490987bdb ("wcn36xx: Hook and identify RF_IRIS_WCN3680"),
the wcn36xx driver will now use the qcom,wcn3680 compatible
to enable functionality specific to WCN3680. In particular,
WCN3680 supports 802.11ac, which is not available in WCN3660B.
Use the new qcom,wcn3660b compatible to describe the chip properly.
Fixes: 0d70519991 ("arm64: dts: msm8916-samsung-a5u: Override iris compatible")
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210106102134.59801-4-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 93f2a11580 ]
The GCC_LPASS_Q6_AXI_CLK and GCC_LPASS_SWAY_CLK clocks may not be
touched on a typical UEFI based SDM845 device, but when the kernel is
built with CONFIG_SDM_LPASSCC_845 this happens, unless they are marked
as protected-clocks in the DT.
This was done for the MTP and the Pocophone, but not for DB845c and the
Lenovo Yoga C630 - causing these to fail to boot if the LPASS clock
controller is enabled (which it typically isn't).
Tested-by: Vinod Koul <vkoul@kernel.org> #on db845c
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20201222001103.3112306-1-bjorn.andersson@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit a9164910c5 ]
Indicated by AML code in ACPI table, the touchpad in-use could be found
on two possible slave addresses on &i2c3, i.e. hid@15 and hid@2c. And
which one is in-use can be determined by reading another address on the
I2C bus. Unfortunately, for DT boot, there is currently no support in
firmware to make this check and patch DT accordingly. This results in
a non-functional touchpad on those C630 devices with hid@2c.
As i2c-hid driver will stop probing the device if there is nothing on
the slave address, we can actually keep both devices enabled in DT, and
i2c-hid driver will only probe the existing one. The only problem is
that we cannot set up pinctrl in both device nodes, as two devices with
the same pinctrl will cause pin conflict that makes the second device
fail to probe. Let's move the pinctrl state up to parent node to solve
this problem. As the pinctrl state of parent node is already defined in
sdm845.dtsi, it ends up with overwriting pinctrl-0 with i2c3_hid_active
state added in there.
Fixes: 11d0e4f281 ("arm64: dts: qcom: c630: Polish i2c-hid devices")
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Link: https://lore.kernel.org/r/20210102045940.26874-1-shawn.guo@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 11d0e4f281 ]
The numbering of the i2c busses differs from ACPI and a number of typos
was made in the original patch. Further more the irq flags for the
various resources was not correct and i2c3 only has one of the two
client devices active in any one device.
Also label the various devices, for easier comparison with the ACPI
tables.
Tested-by: Steev Klimaszewski <steev@kali.org>
Fixes: 44acee2078 ("arm64: dts: qcom: Add Lenovo Yoga C630")
Link: https://lore.kernel.org/r/20201130165924.319708-1-bjorn.andersson@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 228813aaa7 ]
In commit e23b1220a2 ("arm64: dts: qcom: sc7180: Increase the number
of interconnect cells") we missed increasing the cells on one
interconnect. That's no bueno. Fix it.
NOTE: it appears that things aren't totally broken without this fix,
but clearly something isn't going to be working right. If nothing
else, without this fix I see this in the logs:
OF: /soc@0/mdss@ae00000: could not get #interconnect-cells for /soc@0/interrupt-controller@17a00000
Fixes: e23b1220a2 ("arm64: dts: qcom: sc7180: Increase the number of interconnect cells")
Reviewed-by: Georgi Djakov <georgi.djakov@linaro.org>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20201001141838.1.I08054d1d976eed64ffa1b0e21d568e0dc6040b54@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
The scripts/dtc/checks.c requires that the node have empty "dma-ranges"
property must have the same "#address-cells" and "#size-cells" values as
the parent node. Otherwise, the following warnings is reported:
arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning \
(dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but \
its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning \
(dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but \
its #size-cells (1) differs from / (2)
Arnd Bergmann figured out why it's necessary:
Also note that the #address-cells=<1> means that any device under
this bus is assumed to only support 32-bit addressing, and DMA will
have to go through a slow swiotlb in the absence of an IOMMU.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20201016090833.1892-3-thunder.leizhen@huawei.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Over the time, the SCM and MSS driver were refactored to use
SoC-specific compatibles. While the generic compatibles still work
correctly, add the MSM8916-specific compatibles so they are actually
used somewhere.
For SCM this will ensure that we actually manage to obtain all
three of the specified clocks, since those are required on MSM8916.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200915071221.72895-9-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The hwlock device node does not (directly) use memory resources
of the SoC, so we should move it outside the "soc" node.
However, as of commit 7a1e6fb1c6 ("hwspinlock: qcom: Allow mmio usage
in addition to syscon") we can now assign the memory region directly
to the hwlock device node. This works because the register space
used by it is actually separate and not used by any other components.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200915071221.72895-7-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
dt-bindings/interrupt-controller/arm-gic.h has a GIC_SPI define
that allows specifying interrupts more clearly, but right now only
some device nodes in msm8916.dtsi make use of it.
Convert all others to use it.
The same applies to the IRQ_TYPE_* defines in
dt-bindings/interrupt-controller/irq.h. Some interrupts were defined
with raw numbers, or even with IRQ_TYPE_NONE (0).
Convert all these to use appropriate IRQ types.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200915071221.72895-6-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The mdss node sets #interrupt-cells = <1>, so its interrupts
should be referenced using a single cell (in this case: only the
interrupt number).
However, right now the mdp/dsi node both have two interrupt cells
set, e.g. interrupts = <4 0>. The 0 is probably meant to say
IRQ_TYPE_NONE (= 0), but with #interrupt-cells = <1> this is
actually interpreted as a second interrupt line.
Remove the IRQ flags from both interrupts to fix this.
Fixes: 305410ffd1 ("arm64: dts: msm8916: Add display support")
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200915071221.72895-5-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Tha parent node of "wcd_codec" specifies #address-cells = <1>
and #size-cells = <0>, which means that each resource should be
described by one cell for the address and size omitted.
However, wcd_codec currently lists 0x200 as second cell (probably
the size of the resource). When parsing this would be treated like
another memory resource - which is entirely wrong.
To quote the device tree specification [1]:
"If the parent node specifies a value of 0 for #size-cells,
the length field in the value of reg shall be omitted."
[1]: https://www.devicetree.org/specifications/
Fixes: 5582fcb382 ("arm64: dts: apq8016-sbc: add analog audio support with multicodec")
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200915071221.72895-4-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Commit fe2aff0c57 ("arm64: dts: qcom: msm8916: remove unit name for thermal trip points")
removed the unit names for most of the thermal trip points defined
in msm8916.dtsi, but missed to update the one for cpu0_1-thermal.
So why wasn't this spotted by "make dtbs_check"? Apparently, the name
of the thermal zone is already invalid: thermal-zones.yaml specifies
a regex of ^[a-zA-Z][a-zA-Z0-9\\-]{1,12}-thermal$, so it is not allowed
to contain underscores. Therefore the thermal zone was never verified
using the DTB schema.
After replacing the underscore in the thermal zone name, the warning
shows up:
apq8016-sbc.dt.yaml: thermal-zones: cpu0-1-thermal:trips: 'trip-point@0'
does not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-_]{0,63}$', 'pinctrl-[0-9]+'
Fix up the thermal zone names and remove the unit name for the trip point.
Cc: Amit Kucheria <amit.kucheria@linaro.org>
Fixes: fe2aff0c57 ("arm64: dts: qcom: msm8916: remove unit name for thermal trip points")
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200915071221.72895-3-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Right now we define "hnp-disable", "srp-disable", "adp-disable"
separately for every MSM8916 board that has USB working.
They are needed for USB to work properly if CONFIG_USB_OTG_FSM
is enabled. This is because the chipidea OTG FSM code waits for
interrupts regarding the VBUS state (AVVIS). Those never happen
on MSM8916 because VBUS is always connected to the PMIC instead
of the USB controller.
There was a patch [1] to work around this but ultimately it was
decided that it's easier to disable the OTG FSM altogether using
these properties. This works fine for most use cases, because the
OTG FSM isn't needed for simple dual role host/gadget operation.
Given that these properties are needed for every MSM8916 device,
move them to msm8916.dtsi so we can avoid some more duplication.
[1]: https://lore.kernel.org/lkml/20160707222114.1673-10-stephen.boyd@linaro.org/
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200720085406.6716-11-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Right now some device nodes set default pinctrl within msm8916.dtsi
(e.g. I2C, SPI), but for others it needs to be explicitly set in the
board-specific device tree (e.g. UART).
While it is theoretically possible that some super special board
needs different pinctrl for these, in practice pretty much every
board ends up using the common pinctrl definitions.
Make this consistent by also defining the common pinctrl properties
for blsp1_uart1 and blsp1_uart2 so we don't need to copy this for every
board. If there is really such a super special board it could just
override these properties with custom pinctrl or make minor modifications
to the common pinctrl configurations provided by msm8916-pins.dtsi.
Also move #address-cells/#size-cells for &dsi0 to msm8916.dtsi
since this is specific to the DSI node, not the board.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200720085406.6716-10-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
