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 Akari, Apollo & Akatsuki DTS-es to better document
the hardware.
pm8005 and pm8998 config is common for all three boards.
Apollo has VIB_LDO_EN (replacing NC) on PMI8998_GPIO_5
Akari and Akatsuki have WLC_EN_N (replacing NC) on PMI8998_GPIO_8
Akari additionally has RSVD(WLC_EN_N) (replacing) on PMI8998_GPIO_11
which sounds a bit like a forgot-to-update-documentation, but maybe
it differs between SKUs.. Time will tell, when we get to enabling the
wireless charger.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230824-topic-tama_gpio-v1-2-014e9d198dce@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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 Akari, Apollo & Akatsuki DTS-es to better document
the hardware.
Apollo can be considered the 'base configuration'. Akari brings
WLC_INT_N on GPIO_31 over that.
Akatsuki & Akari diff:
< "NC",
> "SAMD_RSTEN_N",
< "NC",
> "MASTER_RST_N",
< "NC",
> "DISP_ERR_FG",
< "NC",
> "SAMD_BOOTL_PIN",
< "NC",
< "NC",
< "NC", /* GPIO_60 */
> "SDM_SWD_CLK",
> "SDM_SWD_DAT",
> "SAMD_RST", /* GPIO_60 */
< "NC",
> "MODE_SEL2",
< "NC",
> "NFC_ESE_PWR_REQ",
< "NC",
> "TS_VDDIO_EN",
Which makes sense, as Akari and Akatsuki have a wireless charger and
Akatsuki also additionally has a super-high-end-complex-for-the-time
Samsung OLED display, as opposed to LCDs on the other Tama devices.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230824-topic-tama_gpio-v1-1-014e9d198dce@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add required pins and RMI4 node to the common DT and remove it
from Akatsuki, as it uses a different touch.
Since the panels are super high tech proprietary incell, they
need to be handled with very precise timings. As such the panel
driver sets up the power rails and GPIOs and the touchscreen
driver *has to* probe afterwards.
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/20230313-topic-tama_disp-v3-2-2b1567c039d7@linaro.org
Add required nodes to support display on XZ2/XZ2c. XZ3 has a
different power rail setup and needs to be handled separately.
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/20230313-topic-tama_disp-v3-1-2b1567c039d7@linaro.org
2700000 is not a multiple of pmic4_pldo's step size of 8000 (with base
voltage 1664000), resulting in pm8998-rpmh-regulators not probing. Just
as we did with MSM8998's Sony Yoshino Poplar [1], round the voltages
down to err on the cautious side and leave a comment in place to
document this discrepancy wrt downstream sources.
[1]: https://lore.kernel.org/linux-arm-msm/20220507153627.1478268-1-marijn.suijten@somainline.org/
Fixes: 30a7f99bef ("arm64: dts: qcom: Add support for SONY Xperia XZ2 / XZ2C / XZ3 (Tama platform)")
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220620211212.269956-1-marijn.suijten@somainline.org
Add support for SONY Xperia XZ2, XZ2 Compact and XZ3 smartphones, all based on
the Qualcomm SDM845 chipset. There also exists a fourth Tama device, the XZ2
Premium (Aurora) with a 4K display, but it's relatively rare.
The devices are affected by a scary UFS behaviour where sending a certain UFS
command (which is worked around on downstream) renders the device unbootable,
by effectively erasing the bootloader. Therefore UFS AND UFSPHY are strictly
disabled for now.
Downstream workaround:
2e7a9ee1c9
This platform's bootloader is not very nice either. To boot mainline you need
to flash a bogus DTBO (fastboot erasing may cut it, but it takes an inhumane
amount of time) - one that's just 4 bytes (all zeroes) seems to work just fine.
Of course, one can also provide a "normal" DTBO (device-specific DT overlayed
on top of the SoC DT), but that's not yet supported by the mainline kernel
build system.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Reviewed-by: Martin Botka <martin.botka@somainline.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20211111184630.605035-1-konrad.dybcio@somainline.org
