- Jan 26, 2023
-
-
Nícolas F. R. A. Prado authored
TODO: maybe add the others as well
-
Nícolas F. R. A. Prado authored
Add a devicetree for rev4 of Spherion. It uses the rt5682s audio codec instead of the rt5682 used in the previous revision. Signed-off-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com>
-
Nícolas F. R. A. Prado authored
Add a devicetree for rev5-sku2 of Hayato. It uses the rt5682s audio codec instead of the rt5682 used in the previous revision. Signed-off-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com>
-
Nícolas F. R. A. Prado authored
Add a dtsi file for the rt5682s audio codec and another, mt8192-asurada-audio-rt1015p-rt5682s, which wires it to be used by mt8192's sound card. These includes will be used by Spherion rev4 and Hayato rev5-sku2, which make use of the rt5682s codec, instead of the rt5682 used in previous revisions. Signed-off-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com>
-
Nícolas F. R. A. Prado authored
Add binding for newer version of Google Spherion (Acer Chromebook 514): rev4. Signed-off-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com>
-
Nícolas F. R. A. Prado authored
Add binding for newer version of Google Hayato board: rev5-sku2. Signed-off-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com> Cover-letter: arm64: dts: mediatek: Add newer revisions of Google Spherion and Hayato boards Add devicetrees for the newer revisions of two boards: Google Spherion rev4 and Google Hayato rev5-sku2. For both, the difference from the previous revision is that they now use the rt5682s audio codec instead of rt5682. END Series-to: Matthias Brugger <matthias.bgg@gmail.com> Series-cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Series-cc: kernel@collabora.com
-
Nícolas F. R. A. Prado authored
Register the compatibles for this module on the module device table so it can be automatically loaded when a matching device is found on the system. Signed-off-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com> Series-to: Viresh Kumar <viresh.kumar@linaro.org> Series-cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Series-cc: kernel@collabora.com
-
- Jan 25, 2023
-
-
The DISP_PWM controller's default behavior is to always use register double buffering: all reads/writes are then performed on shadow registers instead of working registers and this becomes an issue in case our chosen configuration in Linux is different from the default (or from the one that was pre-applied by the bootloader). An example of broken behavior is when the controller is configured to use shadow registers, but this driver wants to configure it otherwise: what happens is that the .get_state() callback is called right after registering the pwmchip and checks whether the PWM is enabled by reading the DISP_PWM_EN register; At this point, if shadow registers are enabled but their content was not committed before booting Linux, we are *not* reading the current PWM enablement status, leading to the kernel knowing that the hardware is actually enabled when, in reality, it's not. The aforementioned issue emerged since this driver was fixed with commit 0b5ef342 ("pwm: mtk-disp: Fix the parameters calculated by the enabled flag of disp_pwm") making it to read the enablement status from the right register. Configure the controller in the .get_state() callback to avoid this desync issue and get the backlight properly working again. Fixes: 3f2b1673 ("pwm: mtk-disp: Implement atomic API .get_state()") Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
-
If shadow registers usage is not desired, disable that before performing any write to CON0/1 registers in the .apply() callback, otherwise we may lose clkdiv or period/width updates. Fixes: cd4b45ac ("pwm: Add MediaTek MT2701 display PWM driver support") Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
-
- Jan 20, 2023
-
-
The scp_adsp clock controller is under the SCP_ADSP power domain. This power domain is currently not supported nor defined. Mark the clock controller as broken for now, to avoid the system from trying to access it, and causing the CPU or bus to stall. Fixes: 5d2b897b ("arm64: dts: mediatek: Add mt8192 clock controllers") Signed-off-by:
Chen-Yu Tsai <wenst@chromium.org>
-
Nícolas F. R. A. Prado authored
We already have anx7625_audio_update_connector_status() to notify the audio framework when HDMI is (dis)connected, but up until now this function was only called during the callback setup. Add a call for it to the HPD change handling logic. A couple functions needed to be hoisted as part of this. Signed-off-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com> Series-to: Robert Foss <robert.foss@linaro.org> Series-cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Series-cc: kernel@collabora.com
-
Nícolas F. R. A. Prado authored
Add 'if' blocks to prevent bias-disable, bias-pull-up and bias-pull-down to be used together, since they're mutually exclusive. Signed-off-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com>
-
Nícolas F. R. A. Prado authored
Add a new 'if' block to validate that drive-strength and drive-strength-microamp aren't used together, since they're mutually exclusive. Signed-off-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com>
-
Nícolas F. R. A. Prado authored
-
Nícolas F. R. A. Prado authored
-
Register USB Type-C mode switches when the "mode-switch" property and relevant port are available in Device Tree. Configure the "lane_swap" state based on the entered alternate mode for a specific Type-C connector, which ends up updating the lane swap registers of the it6505 chip. Signed-off-by:
Pin-yen Lin <treapking@chromium.org> Tested-by:
Chen-Yu Tsai <wenst@chromium.org>
-
Replace the spaces with tab characters in the Kconfig file. Signed-off-by:
Pin-yen Lin <treapking@chromium.org> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
-
ITE IT6505 can be used in systems to switch the DP traffic between two downstreams, which can be USB Type-C DisplayPort alternate mode lane or regular DisplayPort output ports. Update the binding to accommodate this usage by introducing a data-lanes and a mode-switch property on endpoints. Signed-off-by:
Pin-yen Lin <treapking@chromium.org>
-
Register USB Type-C mode switches when the "mode-switch" property and relevant ports are available in Device Tree. Configure the crosspoint switch based on the entered alternate mode for a specific Type-C connector. Crosspoint switch can also be used for switching the output signal for different orientations of a single USB Type-C connector, but the orientation switch is not implemented yet. A TODO is added for this. Signed-off-by:
Pin-yen Lin <treapking@chromium.org> Tested-by:
Chen-Yu Tsai <wenst@chromium.org>
-
The output port endpoints can be connected to USB-C connectors. Running drm_of_find_panel_or_bridge() with such endpoints leads to a continuous return value of -EPROBE_DEFER, even though there is no panel present. To avoid this, check for the existence of a "mode-switch" property in the port endpoint, and skip panel registration completely if so. Signed-off-by:
Pin-yen Lin <treapking@chromium.org> Reviewed-by:
Chen-Yu Tsai <wenst@chromium.org> Tested-by:
Chen-Yu Tsai <wenst@chromium.org>
-
Analogix 7625 can be used in systems to switch the DP traffic between two downstreams, which can be USB Type-C DisplayPort alternate mode lane or regular DisplayPort output ports. Update the binding to accommodate this usage by introducing a data-lanes and a mode-switch property on endpoints. Also include the link to the product brief in the bindings. Signed-off-by:
Pin-yen Lin <treapking@chromium.org> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Chen-Yu Tsai <wenst@chromium.org> Tested-by:
Chen-Yu Tsai <wenst@chromium.org> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
-
Add helpers to register and unregister Type-C "switches" for bridges capable of switching their output between two downstream devices. The helper registers USB Type-C mode switches when the "mode-switch" and the "data-lanes" properties are available in Device Tree. Signed-off-by:
Pin-yen Lin <treapking@chromium.org> Tested-by:
Chen-Yu Tsai <wenst@chromium.org> Reviewed-by:
Chen-Yu Tsai <wenst@chromium.org> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
-
When using OF graph, the fw_devlink code will create links between the individual port driver (cros-ec-typec here) and the parent device for a Type-C switch (like mode-switch). Since the mode-switch will in turn have the usb-c-connector (i.e the child of the port driver) as a supplier, fw_devlink will not be able to resolve the cyclic dependency correctly. As a result, the mode-switch driver probe() never runs, so mode-switches are never registered. Because of that, the port driver probe constantly fails with -EPROBE_DEFER, because the Type-C connector class requires all switch devices to be registered prior to port registration. To break this deadlock and allow the mode-switch registration to occur, purge all the usb-c-connector nodes' absent suppliers. This eliminates the connector as a supplier for a switch and allows it to be probed. Signed-off-by:
Prashant Malani <pmalani@chromium.org> Signed-off-by:
Pin-yen Lin <treapking@chromium.org> Reviewed-by:
Chen-Yu Tsai <wenst@chromium.org> Tested-by:
Chen-Yu Tsai <wenst@chromium.org> Acked-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com>
-
When searching the device graph for device matches, check the remote-endpoint itself for a match. Some drivers register devices for individual endpoints. This allows the matcher code to evaluate those for a match too, instead of only looking at the remote parent devices. This is required when a device supports two mode switches in its endpoints, so we can't simply register the mode switch with the parent node. Signed-off-by:
Prashant Malani <pmalani@chromium.org> Signed-off-by:
Pin-yen Lin <treapking@chromium.org> Reviewed-by:
Chen-Yu Tsai <wenst@chromium.org> Tested-by:
Chen-Yu Tsai <wenst@chromium.org> Acked-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com>
-
Nícolas F. R. A. Prado authored
Signed-off-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com>
-
Nícolas F. R. A. Prado authored
The dt-binding for Mediatek's SPI NOR flash controller expects a mt8173 fallback compatible for mt8192, so add it in mt8192.dtsi. The driver already sets custom data based on the mt8192 compatible, so this fallback compatible won't be used and is added purely to suppress the dt-binding warning. Signed-off-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com> Series-to: Matthias Brugger <matthias.bgg@gmail.com> Series-cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Series-cc: kernel@collabora.com
-
In the previous commits that added CLK_OPS_PARENT_ENABLE, support for this flag was only added to rate change operations (rate setting and reparent) and disabling unused subtree. It was not added to the clock gate related operations. Any hardware driver that needs it for these operations will either see bogus results, or worse, hang. This has been seen on MT8192 and MT8195, where the imp_ii2_* clk drivers set this, but dumping debugfs clk_summary would cause it to hang. Prepare parent on prepare and enable parent on enable dependencies are already handled automatically by the core as part of its sequencing. Whether the case for "enable parent on prepare" should be supported by this flag or not is not clear, and thus ignored for now. This change solely fixes the handling of clk_core_is_enabled, i.e. enabling the parent clock when reading the hardware state. Unfortunately clk_core_is_enabled is called in a variety of places, sometimes with the enable clock already held. To avoid deadlocking, the core will ignore readouts and just return false if CLK_OPS_PARENT_ENABLE is set but the parent isn't currently enabled. Fixes: fc8726a2 ("clk: core: support clocks which requires parents enable (part 2)") Fixes: a4b3518d ("clk: core: support clocks which requires parents enable (part 1)") Signed-off-by:
Chen-Yu Tsai <wenst@chromium.org> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
-
Complete all clocks and clock-names be used for mt8192 SoC into dt-bindings. Signed-off-by:
Jiaxin Yu <jiaxin.yu@mediatek.com> Signed-off-by:
Allen-KH Cheng <allen-kh.cheng@mediatek.com> Reviewed-by:
Matthias Brugger <matthias.bgg@gmail.com>
-
This driver currently deals with GPU-SRAM regulator coupling, ensuring that the SRAM voltage is always between a specific range of distance to the GPU voltage, depending on the SoC, necessary in order to achieve system stability across the full range of supported GPU frequencies. Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
-
- Jan 17, 2023
-
-
Nícolas F. R. A. Prado authored
MT8192 uses 5 power domains, so the maximum generic value needs to be increased. Each SoC can further limit its own range in the if/else blocks. While at it, also add a generic limit for the power domain names. Signed-off-by:
Nícolas F. R. A. Prado <nfraprado@collabora.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>
-
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. Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
-
The MediaTek MT8192 includes a Mali-G57 GPU supported in Panfrost. Add the GPU node to the device tree to enable 3D acceleration. 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>
-
Nícolas F. R. A. Prado authored
-
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>
-
Required for Mali-G57 on the Mediatek MT8192 and MT8195, which uses even more power domains than the MT8183 before it. Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> [Angelo: Removed unneeded "sram" supply, added mt8195 to commit description] Signed-off-by:
AngeloGioachino Del Regno <angelogioacchino.delregno@collabora.com>
-
MediaTek MT8192 has a Mali-G57 with a special GPU ID. Add its GPU ID, but treat it as otherwise identical to a standard Mali-G57. We do _not_ fix up the GPU ID here -- userspace needs to be aware of the special GPU ID, in case we find functional differences between MediaTek's implementation and the standard Mali-G57 down the line. Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
-
Increase the MAX_PM_DOMAINS constant from 3 to 5, to support the extra power domains required by the Mali-G57 on the MT8192. Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
-
Correct dts node name in patch v1: performance-domain This patch depends on [1] and [2]. [1]http://lists.infradead.org/pipermail/linux-mediatek/2020-November/019378.html [2]https://patchwork.kernel.org/project/linux-mediatek/patch/1607586516-6547-3-git-send-email-hector.yuan@mediatek.com/ Signed-off-by:
Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com> [Nicolas: rebased & fixed node name. Note: this commit is required for suspend/resume to work]
-
Add video-codec lat and core nodes for mt8192 SoC. Signed-off-by:
Allen-KH Cheng <allen-kh.cheng@mediatek.com> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com> Tested-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com>
-