Sony ever so graciously provides GPIO line names in their downstream
kernel (though sometimes they are not 100% accurate and you can judge
that by simply looking at them and with what drivers they are used).
Add these to the Sagami-common / PDX215 DTSIs to better document the
hardware.
Diff between 215 and common:
< "NC",
< "NC",
> "WLC_I2C_SDA",
> "WLC_I2C_SCL",
< "NC",
> "WLC_INT_N",
> "CAM_MCLK4",
< "NC",
< "NC",
> "TOF_RST_N",
< "NC",
< "NC",
< "NC",
> "QLINK1_REQ",
> "QLINK1_EN",
> "QLINK1_WMSS_RESET_N",
It's pretty logical as 1 III has WLC (WireLess Charging), and an
additional 3D iToF sensor. As for QLINK, no idea.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221116123612.34302-3-konrad.dybcio@linaro.org
When recently adding the missing 'regulator-allowed-modes' properties it
appears that the binding example with its four-spaces indentation
(corresponding to a single tab, which is still to little) was copied
verbatim.
Drop the unnecessary first line break after 'regulator-allowed-modes'
properties and indent the single remaining continuation line properly.
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221116102054.4673-3-johan+linaro@kernel.org
Add necessary nodes to support various QUP configurations. Note that:
- QUP3/4/5 and 11 are straight up missing
- There may be more QUPs physically on the SoC that work perfectly
fine, but Qualcomm decided not to expose them on the downstream kernel
- Many are missing pinctrls, as there are both missing pin funcs in
the TLMM driver and missing configuration settings (though they are
possible to guesstimate quite easily)
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221115152727.9736-6-konrad.dybcio@linaro.org
Add the pin setup for SPI/I2C configurations that are supported
downstream. I can guesstimate the correct settings for other buses,
but:
- I have no hardware to test it on
- Some QUPs are straight up missing pin funcs in TLMM
- Vendors probably didn't really care and used whatever was there in
the reference design and BSP - should any other be used, they can be
configured at a later time
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221115152727.9736-5-konrad.dybcio@linaro.org
PMK8350 is shipped on SID6 with some SoCs, for example with SM6375.
Add some preprocessor logic to allow changing the SID in cases like
this.
While I am not in favour of adding #if's into the device tree, this
is the least messy way to handle this. If one isn't specified, it
will default to 0 (as it has been previously).
Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221115152727.9736-3-konrad.dybcio@linaro.org
Add a device tree for the Xperia 5 IV (pdx224). It's literally the 1 IV
with a smaller body, different panel, one camera lens (not sensor afaict)
swapped out and no 3D iToF sensor, hence the device-specific DT is tiny.
Be sure to follow the vbmeta disablement steps (detailed in pdx223
introduction commit message), otherwise your phone will not boot and
will reject anything and everything with just a non-descriptive
"Your device is corrupted" followed by a sad reboot. This should not
be the case, as vbmeta should be plainly ignored in unlocked state,
but what can we do..
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221114095654.34561-3-konrad.dybcio@linaro.org
When adding support for the DisplayPort part of the QMP PHY the binding
(and devicetree parser) for the (USB) child node was simply reused and
this has lead to some confusion.
The third DP register region is really the DP_PHY region, not "PCS" as
the binding claims, and lie at offset 0x2a00 (not 0x2c00).
Similarly, there likely are no "RX", "RX2" or "PCS_MISC" regions as
there are for the USB part of the PHY (and in any case the Linux driver
does not use them).
Note that the sixth "PCS_MISC" region is not even in the binding.
Fixes: 5aa0d1becd ("arm64: dts: qcom: sm8250: switch usb1 qmp phy to USB3+DP mode")
Cc: stable@vger.kernel.org # 5.13
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221111094729.11842-3-johan+linaro@kernel.org
When adding support for the DisplayPort part of the QMP PHY the binding
(and devicetree parser) for the (USB) child node was simply reused and
this has lead to some confusion.
The third DP register region is really the DP_PHY region, not "PCS" as
the binding claims, and lie at offset 0x2a00 (not 0x2c00).
Similarly, there likely are no "RX", "RX2" or "PCS_MISC" regions as
there are for the USB part of the PHY (and in any case the Linux driver
does not use them).
Note that the sixth "PCS_MISC" region is not even in the binding.
Fixes: 23737b9557 ("arm64: dts: qcom: sm6350: Add USB1 nodes")
Cc: stable@vger.kernel.org # 5.16
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221111094729.11842-2-johan+linaro@kernel.org
This is not a fix on its own but more a cleanup. Phy qmp pcie driver
currently have a workaround to handle pcs_misc not declared and add
0x400 offset to the pcs reg if pcs_misc is not declared.
Correctly declare pcs_misc reg and reduce PCS size to the common value
of 0x1f0 as done for every other qmp based pcie phy device.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221103212125.17156-2-ansuelsmth@gmail.com
There are three UFS reference clocks on SC8280XP which are used as
follows:
- The GCC_UFS_REF_CLKREF_CLK clock is fed to any UFS device connected
to either controller.
- The GCC_UFS_1_CARD_CLKREF_CLK and GCC_UFS_CARD_CLKREF_CLK clocks
provide reference clocks to the two PHYs.
Note that this depends on first updating the clock driver to reflect
that all three clocks are sourced from CXO. Specifically, the UFS
controller driver expects the device reference clock to have a valid
frequency:
ufshcd-qcom 1d84000.ufs: invalid ref_clk setting = 0
Fixes: 152d1faf1e ("arm64: dts: qcom: add SC8280XP platform")
Fixes: 8d6b458ce6 ("arm64: dts: qcom: sc8280xp: fix ufs_card_phy ref clock")
Fixes: f3aa975e23 ("arm64: dts: qcom: sc8280xp: correct ref clock for ufs_mem_phy")
Link: https://lore.kernel.org/lkml/Y2OEjNAPXg5BfOxH@hovoldconsulting.com/
Cc: stable@vger.kernel.org # 5.20
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221104092045.17410-2-johan+linaro@kernel.org
The devices on the SC8280XP PCIe buses are cache coherent and must be
marked as such to avoid data corruption.
A coherent device can, for example, end up snooping stale data from the
caches instead of using data written by the CPU through the
non-cacheable mapping which is used for consistent DMA buffers for
non-coherent devices.
Note that this is much more likely to happen since commit c44094eee3
("arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()")
that was added in 6.1 and which removed the cache invalidation when
setting up the non-cacheable mapping.
Marking the PCIe devices as coherent specifically fixes the intermittent
NVMe probe failures observed on the Thinkpad X13s, which was due to
corruption of the submission and completion queues. This was typically
observed as corruption of the admin submission queue (with well-formed
completion):
could not locate request for tag 0x0
nvme nvme0: invalid id 0 completed on queue 0
or corruption of the admin or I/O completion queues (malformed
completion):
could not locate request for tag 0x45f
nvme nvme0: invalid id 25695 completed on queue 25965
presumably as these queues are small enough to not be allocated using
CMA which in turn make them more likely to be cached (e.g. due to
accesses to nearby pages through the cacheable linear map). Increasing
the buffer sizes to two pages to force CMA allocation also appears to
make the problem go away.
Fixes: 813e831570 ("arm64: dts: qcom: sc8280xp/sa8540p: add PCIe2-4 nodes")
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221124142501.29314-1-johan+linaro@kernel.org
The 1-mic and 3-mic dtsi still had two minor cosmetic differences
after commit '3d11e7e120ee ("arm64: dts: qcom: sc7280: sort out the
"Status" to last property with
sc7280-herobrine-audio-rt5682.dtsi")'. Let's fix them so the two files
diff better. This is expected to have no effect though it will
slightly change the generated dtb by removing an unnecessary 'status =
"okay"' from the sound node.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221114162807.1.I0900b97128f9bb03e5f96fcb3068c227a33f143a@changeid
