| Age | Commit message (Collapse) | Author |
|---|
|
J721S2 has 8 MCSPI instances in the main domain and 3 instances
in the MCU domain. Add the DT nodes for all the 11 instances and
keep them disabled. MAIN_MCSPI4 is connected as a slave to MCU_MCSPI2
by default at power-up, MAIN_MCSPI4 and MCU_MCSPI2 are not pinned out
externally.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Reviewed-by: Keerthy <j-keerthy@ti.com>
Link: https://lore.kernel.org/r/20230321082827.14274-4-vaishnav.a@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
J7200 has 8 MCSPI instances in the main domain and 3 instances
in the MCU domain. Add the DT nodes for all the 11 instances and
keep them disabled. MAIN_MCSPI4 is connected as a slave to MCU_MCSPI2
by default at power-up, MAIN_MCSPI4 and MCU_MCSPI2 are not pinned out
externally.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Reviewed-by: Keerthy <j-keerthy@ti.com>
Link: https://lore.kernel.org/r/20230321082827.14274-3-vaishnav.a@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
J721E has 8 MCSPI instances in the main domain and 3 instances
in the MCU domain. Add the DT nodes for all the 11 instances and
keep them disabled. MAIN_MCSPI4 is connected as a slave to MCU_MCSPI2
by default at power-up, MAIN_MCSPI4 and MCU_MCSPI2 are not pinned out
externally.
Co-developed-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Reviewed-by: Jai Luthra <j-luthra@ti.com>
Link: https://lore.kernel.org/r/20230321082827.14274-2-vaishnav.a@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
The AM62x LP SK board is similar to the AM62x SK board, but has some
not-so-minor changes that requires different device tree.
The differences are mainly:
- AM62x SoC in the AMC package that meets AECQ100 automotive standard.
- LPDDR4 versus DDR4 on the AM62x SK.
- TPS65219 PMIC instead of discrete regulators.
- IO expander pin names are wired differently.
- Second ethernet port is currently disabled as the boards do not have
the part physically installed.
- OSPI NAND vs OSPI NOR.
- No WLAN chip instead a SDIO M.2 connector.
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
[vigneshr@ti.com: Add PMIC node]
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20230321-am62-lp-sk-v2-3-0a56e1694804@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
To prepare for upcoming derivative boards based on the AM625 SK,
refactor the dts file for this board into a common dtsi file that the
derivative boards will inherit and retain only those parts that are
different in the current dts file.
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20230321-am62-lp-sk-v2-2-0a56e1694804@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Add compatible for AM62x SoC based Low Power Starter Kit board[1]
[1] https://www.ti.com/tool/SK-AM62-LP
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230321-am62-lp-sk-v2-1-0a56e1694804@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
The property "ti,vbus-divider" is needed for both usbss0 and usbss1 as
both USB0 and USB1 have the same external voltage divider circuit.
Fixes: 2d94dfc43885 ("arm64: dts: ti: k3-am625-sk: Add support for USB")
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20230328124315.123778-2-rogerq@kernel.org
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Rev E2 of the AM68 SK baseboard has updated the GPIO IO expander pins
functionality. To match the Rev E2 schematics, update existing IO expander
GPIO line names and the corresponding node which uses the expansion(exp1)
node.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
Link: https://lore.kernel.org/r/20230315120934.16954-1-sinthu.raja@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
BeagleBoard.org BeaglePlay is an easy to use, affordable open source
hardware single board computer based on the Texas Instruments AM625
SoC that allows you to create connected devices that work even at long
distances using IEEE 802.15.4g LR-WPAN and IEEE 802.3cg 10Base-T1L.
Expansion is provided over open standards based mikroBUS, Grove and
QWIIC headers among other interfaces.
This board family can be identified by the 24c32 eeprom:
[aa 55 33 ee 01 37 00 10 2e 00 42 45 41 47 4c 45 |.U3..7....BEAGLE|]
[50 4c 41 59 2d 41 30 2d 00 00 30 32 30 30 37 38 |PLAY-A0-..020078|]
https://beagleplay.org/
https://git.beagleboard.org/beagleplay/beagleplay
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Link: https://lore.kernel.org/r/20230316152143.2438928-3-nm@ti.com
Co-developed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Enable CRU, CSI on RZ/G2L SMARC EVK and tie the CSI to OV5645 sensor
using Device Tree overlay. rz-smarc-cru-csi-ov5645.dtsi is created so
that RZ/G2L alike EVKs can make use of it.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20230322125648.24948-3-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Add CSI and CRU nodes r9a07g044 (RZ/G2L) SoC DTSI.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20230322125648.24948-2-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Enable sci0 node using dt overlay and disable can{0,1}-stb-hog
nodes in DT overlay as its pins are shared with sci0 pins.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20230321114753.75038-6-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Add support for the 7 PWM channels provided by PWM Timers on R-Car H2,
by adding device nodes describing the PWM Timers.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/9755b3af4296060ee31c4652def639574cbbd2fb.1679330878.git.geert+renesas@glider.be
|
|
Add support for the 4 PWM channels provided by the 16-bit Timer Pulse
Unit on R-Car H2, by adding a device node describing the TPU.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/75da1e63135a3fc8a3aaafbff7139bd5d7509be3.1679330727.git.geert+renesas@glider.be
|
|
Enable the single I2C bus available on the Marzen development board.
As this bus contains an AK4643 codec, it must be limited to 100 kHz.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/77b87378397fd26f39c73f68e3ea465db6d38fb1.1679330016.git.geert+renesas@glider.be
|
|
Describe the four General Purpose Switches on the Marzen development
board, so they can be used for user input and/or for wake-up from s2ram.
The GPIO block on R-Car H1 does not support triggering interrupts on
both edges of a changing input signal, hence one cannot use gpio-keys
with gpios properties. Instead, one of two alternatives needs to be
used:
1. Use gpio-keys with interrupts instead of gpios properties, at the
expense of receiving only key presses (release events will be
auto-generated),
2. Use gpio-keys-polled with gpios properties, at the expense of
making these keys unusable as wake-up sources.
As the DTS for the Marzen development board serves mainly as an example,
the approach taken is to use the first alternative for the first two
switches, and the second alternative for the last two switches.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/f834a3c397362f2424fcae6a0c0440356208b182.1679329829.git.geert+renesas@glider.be
|
|
Add support for the 7 PWM channels provided by PWM Timers on R-Car
H1, by describing the PWM Timers and their module clock.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/71622584db692f571d542ef2dcf088ce549aed3f.1679329211.git.geert+renesas@glider.be
|
|
Add the module clock used by the PWM Timers on the Renesas R-Car H1
(R8A7779) SoC.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/1397b517fccbe716a71cfae770512ed577730a25.1679329211.git.geert+renesas@glider.be
|
|
Add clock-names and reset-names to RZ/G2{L,LC,UL}, RZ/V2L and
RZ/Five DMAC nodes.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20230315064726.22739-2-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
The OrangePi R1 Plus LTS is a minor variant of OrangePi R1 Plus with
the on-board NIC chip changed from rtl8211e to yt8531c, and otherwise
identical to OrangePi R1 Plus.
Signed-off-by: Tianling Shen <cnsztl@gmail.com>
Link: https://lore.kernel.org/r/20230325074022.9818-5-cnsztl@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Add devicetree binding documentation for the
Xunlong OrangePi R1 Plus LTS.
Signed-off-by: Tianling Shen <cnsztl@gmail.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20230325074022.9818-4-cnsztl@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The NanoPi R2C is a minor variant of NanoPi R2S with the on-board NIC
chip changed from rtl8211e to yt8521s, and otherwise identical to R2S.
Signed-off-by: Tianling Shen <cnsztl@gmail.com>
Link: https://lore.kernel.org/r/20230325074022.9818-3-cnsztl@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Add devicetree binding documentation for the FriendlyARM NanoPi R2C.
Signed-off-by: Tianling Shen <cnsztl@gmail.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20230325074022.9818-2-cnsztl@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The phone has a Goodix GT1158 touchscreen, add a DT node for it.
Signed-off-by: Martijn Braam <martijn@brixit.nl>
Co-developed-by: Kamil Trzciński <ayufan@ayufan.eu>
Signed-off-by: Kamil Trzciński <ayufan@ayufan.eu>
Co-developed-by: Ondrej Jirman <megi@xff.cz>
Signed-off-by: Ondrej Jirman <megi@xff.cz>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20230328073309.1743112-3-javierm@redhat.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The phone's display is using a Hannstar LCD panel. Support it by adding a
panel DT node and all needed nodes (backlight, MIPI DSI, regulators, etc).
Signed-off-by: Martijn Braam <martijn@brixit.nl>
Co-developed-by: Kamil Trzciński <ayufan@ayufan.eu>
Signed-off-by: Kamil Trzciński <ayufan@ayufan.eu>
Co-developed-by: Ondrej Jirman <megi@xff.cz>
Signed-off-by: Ondrej Jirman <megi@xff.cz>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Tested-by: Ondrej Jirman <megi@xff.cz>
Link: https://lore.kernel.org/r/20230328073309.1743112-2-javierm@redhat.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Add rockchip,rk3588-wdt compatible string.
Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230328210048.195124-3-shreeya.patel@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Add DT node for watchdog support in RK3588.
Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
Link: https://lore.kernel.org/r/20230328210048.195124-2-shreeya.patel@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Add display node for vdosys1.
Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230323013730.1378-1-nancy.lin@mediatek.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Override the PMIC-default voltage constraints for VGPU and VSRAM_GPU
with the platform specific vmin/vmax for the highest possible SoC
binning.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Suggested-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230301095523.428461-20-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Override the PMIC-default voltage constraints for VGPU and VSRAM_GPU
with the platform specific vmin/vmax for the highest possible SoC
binning.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Suggested-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230301095523.428461-19-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Add a GPU node for MT8186 SoC but keep it disabled.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230301095523.428461-18-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Enable the Mali-G57 found on this platform with the open-source
Panfrost driver.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230301095523.428461-17-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Add GPU support through panfrost for the Mali-G57 GPU on MT8195
with its OPP table but keep it in disabled state.
This is expected to be enabled only on boards which make use of
the GPU.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230301095523.428461-16-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Similarly to what can be seen in MT8192, on MT8195 the mfg_core_tmp
clock is a mux used to switch between different "safe" (and slower)
clock sources for the GPU: this is used during MFGPLL reconfiguration
and eventually during idling at very low frequencies.
This clock getting turned off means that the GPU will occasionally be
unclocked, producing obvious consequences such as system crash or
unpredictable behavior: assigning it to the top level MFG power domain
will make sure that this stays on at all times during any operation on
the MFG domain (only GPU-related transactions).
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230301095523.428461-15-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Enable the GPU with its power supplies described.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
[wenst@: patch split out from MT8192 GPU node patch]
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
[Angelo: Minor commit title fix]
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230301095523.428461-14-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Add coupling for these regulators, as VSRAM_OTHER is used to power the
GPU SRAM, and they have a strict voltage output relation to satisfy in
order to ensure GPU stable operation.
While at it, also add voltage constraint overrides for the GPU SRAM
regulator "mt6359_vsram_others" so that we stay in a safe range of
0.75-0.80V.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230301095523.428461-13-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
The MT8192 SoC specifies a maximum voltage for the GPU's digital supply
of 0.88V and the GPU OPPs are declaring a maximum voltage of 0.80V.
In order to keep the GPU voltage in the safe range, change the maximum
voltage for mt6315@7's vbuck1 to 0.80V as sending, for any mistake,
1.193V would be catastrophic.
Fixes: 3183cb62b033 ("arm64: dts: mediatek: asurada: Add SPMI regulators")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-yu Tsai <wenst@chromium.org>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230301095523.428461-12-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Add a phandle to the MT8192_POWER_DOMAIN_MFG1 power domain and
assign the GPU VSRAM supply to this in mt8192-asurada: this allows to
keep the sram powered up while the GPU is used.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230301095523.428461-11-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
The mfg0 power domain encompasses the whole GPU and its surrounding
glue logic. This power domain has a separate power rail.
Add its power supply for Asurada.
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
[wenst@chromium.org: fix subject prefix and add commit message]
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
[Angelo: Reordered commits to address DVFS stability issues]
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230301095523.428461-10-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
The mfg_ref_sel clock is a mux used to switch between different "safe"
(and slower) clock sources for the GPU: this is used during MFGPLL
reconfiguration and eventually during idling at very low frequencies.
This clock getting turned off means that the GPU will occasionally be
unclocked, producing obvious consequences such as system crash or
unpredictable behavior: assigning it to the top level MFG power domain
will make sure that this stays on at all times during any operation on
the MFG domain (only GPU-related transactions).
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230301095523.428461-9-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
The MediaTek MT8192 includes a Mali-G57 GPU supported in Panfrost. Add
the GPU node to the device tree to enable 3D acceleration.
The GPU node is disabled by default. It should be enabled by board with
its power supplies correctly assigned.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
[nfraprado: removed sram supply, tweaked opp node name, adjusted commit message]
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
[wenst@: disable GPU by default; adjusted prefix; split out board change]
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
[Angelo: cosmetic fixes]
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230301095523.428461-8-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Use the new GPU related compatible to finally enable GPU DVFS on
the MT8183 SoC.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230301095523.428461-7-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Add coupling for these regulators, as they have a strict voltage output
relation to satisfy in order to ensure GPU stable operation.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230301095523.428461-6-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Add coupling for these regulators, as they have a strict voltage output
relation to satisfy in order to ensure GPU stable operation.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230301095523.428461-5-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
This was done to keep a strict relation between VSRAM and VGPU, but
it never worked: now we're doing it transparently with the new
mediatek-regulator-coupler driver.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230301095523.428461-4-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Override the PMIC-default voltage constraints for VGPU and VSRAM_GPU
with the platform specific vmin/vmax for the highest possible SoC
binning.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230301095523.428461-3-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Add coupling for these regulators, as they have a strict voltage output
relation to satisfy in order to ensure GPU stable operation.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230301095523.428461-2-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
The Qualcomm pinctrl driver has been violating the documented meaning
of PIN_CONFIG_INPUT_ENABLE. That documentation says:
Note that this does not affect the pin's ability to drive output.
...yet the Qualcomm driver's sole action when asked to "enable input"
on a pin is to disable its output.
The Qualcomm driver's implementation stems from the fact that
"output-disable" is a "new" property from 2017. It was introduced in
commit 425562429d4f ("pinctrl: generic: Add output-enable
property"). The "input-enable" handling in Qualcomm drivers is from
2015 introduced in commit 407f5e392f9c ("pinctrl: qcom: handle
input-enable pinconf property").
Let's change the Qualcomm driver to move us in the right direction. As
part of this:
1. We'll now support PIN_CONFIG_OUTPUT_ENABLE
2. We'll still support using PIN_CONFIG_INPUT_ENABLE to disable a
pin's output (in violation of the docs) with a big comment in the
code. This is needed because old device trees have "input-enable"
in them and, in some cases, people might need the old
behavior. While we could programmatically change all old device
trees, it doesn't really hurt to keep supporting the old behavior
and we're _supposed_ to try to be compatible with old device trees
anyway.
It can also be noted that the PIN_CONFIG_INPUT_ENABLE handling code
seems to have purposefully ignored its argument. That means that old
boards that had _either_ "input-disable" or "input-enable" in them
would have had the effect of disabling a pin's output. While we could
change this behavior, since we're only leaving the
PIN_CONFIG_INPUT_ENABLE there for backward compatibility we might as
well be fully backward compatible.
NOTE: despite the fact that we'll still support
PIN_CONFIG_INPUT_ENABLE for _setting_ config, we take it away from
msm_config_group_get(). This appears to be only used for populating
debugfs and fixing debugfs to "output enabled" where relevant instead
of "input enabled" makes more sense and has more truthiness.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230323102605.8.Id740ae6a993f9313b58add6b10f6a92795d510d4@changeid
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
In the patch ("dt-bindings: pinctrl: qcom: tlmm should use
output-disable, not input-enable") we allowed setting "output-disable"
for TLMM pinctrl states. Let's also add "output-enable".
At first blush this seems a needless thing to do. Specifically:
- In Linux (and presumably any other OSes using the same device trees)
the GPIO/pinctrl driver knows to automatically enable the output
when a GPIO is changed to an output. Thus in most cases specifying
"output-enable" is superfluous and should be avoided.
- If we need to set a pin's default state we already have
"output-high" and "output-low" and these properties already imply
"output-enabled" (at least on the Linux Qualcomm TLMM driver).
However, there is one instance where "output-enable" seems like it
could be useful: sleep states. It's not uncommon to want to configure
pins as inputs (with appropriate pulls) when the driver controlling
them is in a low power state. Then we want the pins back to outputs
when the driver wants things running normally. To accomplish this we'd
want to be able to use "output-enable". Then the "default" state could
have "output-enable" and the "sleep" state could have
"output-disable".
NOTE: in all instances I'm aware of, we'd only want to use
"output-enable" on pins that are configured as "gpio". The Qualcomm
documentation that I have access to says that "output-enable" only
does something useful when in GPIO mode.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230323102605.7.I7874c00092115c45377c2a06f7f133356956686e@changeid
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
As evidenced by the Qualcomm TLMM Linux driver, the TLMM IP block in
Qualcomm SoCs has a bit to enable/disable the output for a pin that's
configured as a GPIO but _not_ a bit to enable/disable an input
buffer. Current device trees that are specifying "input-enable" for
pins managed by TLMM are either doing so needlessly or are using it to
mean "output-disable".
Presumably the current convention of using "input-enable" to mean
"output-disable" stems from the fact that "output-disable" is a "new"
property from 2017. It was introduced in commit 425562429d4f
("pinctrl: generic: Add output-enable property"). The "input-enable"
handling in Qualcomm drivers is from 2015 introduced in commit
407f5e392f9c ("pinctrl: qcom: handle input-enable pinconf property").
Given that there's no other use for "input-enable" for TLMM, we can
still handle old device trees in code, but let's encourage people to
move to the proper / documented property by updating the bindings.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230323102605.6.I291ce0ba2c6ea80b341659c4f75a567a76dd7ca6@changeid
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
