Already headed upstream:
https://lore.kernel.org/all/20230220093343.3447381-1-hsinyi@chromium.org/



Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Yunfei Dong authored 6 years ago and Nícolas F. R. A. Prado committed 1 year ago

Add node for the hardware decoder present on the MT8183 SoC.

Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
Signed-off-by: Qianqian Yan <qianqian.yan@mediatek.com>
Signed-off-by: Frederic Chen <frederic.chen@mediatek.com>
Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Remove the VDEC_SYS register space from the decoder, so that the node
address becomes that of VDEC_MISC, solving the conflicting addresses
between this node and the vdecsys clock-controller node.

Also pass a reference to the active clock. Checking the status of this
clock was the only use of the VDEC_SYS space, so the functionality is
maintained.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

On MT8183 it's not necessary to configure the parent for the clocks.
Remove the assigned-clocks assigned-clock-parents from the required
list.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

MT8173 and MT8183 have different clocks, and consequently clock-names.
Set clock-names based on compatible.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Add the CLK_VDEC_ACTIVE and CLK_VDEC_SOC_LAT_ACTIVE clocks to the vdec
clock driver. These clocks indicate that the VDEC and the LAT hardware
are active, respectively.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

The *_ACTIVE clocks are 0 when enabled, and 1 when disabled, but they
were using the mtk_clk_gate_ops_setclr_inv ops, which has the opposite
logic. Use the non-inverted ops for these clocks so the right value is
returned.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Add the CLK_VDEC_ACTIVE clock to the vdec clock driver. This clock is
enabled by the VPU once it starts decoding.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Add the CLK_VDEC_ACTIVE clock to the vdecsys clock driver. This clock is
enabled by the VPU once it starts decoding.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

When the subdev binding is used to describe the codec in the DT, the
second register space is the VDEC_RACING_CTRL. Give it a more
appropriate name in the enum, instead of just reusing the VDEC_MISC name
from the non-subdev binding.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Remove the requirement of a VDEC_SYS reg iospace. To achieve that, rely
on the "active" clock being passed through the DT, and read its status
during IRQ handling to check whether the HW is active.

The old behavior is still present when reg-names aren't supplied, as to
keep backward compatibility.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

The binding expects the first register space to be VDEC_SYS. But this
space is composed of registers to control clocks and resets, which are
better described as separate clock-controller and reset-controller
nodes.

In fact, such nodes have already beed added, which cause conflicting
addresses on mt8173 and would also conflict on mt8183 as its vcodec
node is upstreamed.

The only current use of the VDEC_SYS regiser space in the driver is to
read the status of a clock that indicates the hardware is active. So, to
avoid conflicting addresses and correct the memory description of the
codec, remove the VDEC_SYS register space from the binding and describe
an extra clock that will be used to directly check the hardware status.

Also add a boolean flag to indicate this new register schema is used, so
the driver can keep backward compatibility.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Removing the ranges from the decoder node is done on more recent version
of the series adding it. Adding the dma-ranges in the soc is something
done on 8195 and 8186, and apparently needs to be done on 8192 as well.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

When trying to run ChromeOS tast tests on this branch, the kernel
currently hangs during boot with

<6>[   16.512796] Run /sbin/init as init process
<0>[   16.618777] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100

<4>[   16.662990]  dump_backtrace+0xa4/0x130
<4>[   16.671662]  show_stack+0x20/0x38
<4>[   16.679790]  dump_stack_lvl+0x78/0xc8
<4>[   16.688217]  dump_stack+0x18/0x28
<4>[   16.696158]  panic+0x35c/0x3c8
<4>[   16.703752]  do_exit+0x890/0x9c8
<4>[   16.711480]  do_group_exit+0x3c/0xa0
<4>[   16.719494]  __arm64_sys_exit_group+0x20/0x28
<4>[   16.728269]  invoke_syscall+0x50/0x128
<4>[   16.736330]  el0_svc_common.constprop.0+0x58/0x188
<4>[   16.745388]  do_el0_svc_compat+0x24/0x58
<4>[   16.753527]  el0_svc_compat+0x2c/0xb8
<4>[   16.761281]  el0t_32_sync_handler+0x90/0x140
<4>[   16.769608]  el0t_32_sync+0x1a8/0x1b0

With these configs enabled, when running the cros-tast-kernel test, it
now boots successfully and gives the following results, which are on par
the -fixed test (ie the downstream kernel):

kernel.ConfigVerify.chromeos_kernelci[1;33m [ SKIP ] [0mmissing SoftwareDeps: chromeos_kernelci
kernel.PerfCallgraph                 [1;33m [ SKIP ] [0mmissing SoftwareDeps: amd64
kernel.Bloat                         [1;32m [ PASS ] [0m
kernel.CPUCgroup                     [1;32m [ PASS ] [0m
kernel.Cpuidle                       [1;31m [ FAIL ] [0mExpected cpuidle governor: got "menu", want "teo"
kernel.CryptoAPI                     [1;32m [ PASS ] [0m
kernel.CryptoDigest                  [1;32m [ PASS ] [0m
kernel.ECDeviceNode                  [1;32m [ PASS ] [0m
kernel.HighResTimers                 [1;32m [ PASS ] [0m
kernel.Limits                        [1;31m [ FAIL ] [0m/proc/sys/kernel/sched_rt_runtime_us contains 950000; want 850000

Most of the configs added here are probably unrelated. This is a quick
and dirty solution to get tast working on our integration branch. We
should track down what configs from this list are actually needed.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

This reverts commit b2cbac9b.

It's causing spammy warnings:
sysctl net/netfilter/nf_conntrack_frag6_low_thresh: data points to kernel global data: nf_conntrack_frag6_low_thresh_unused

During probe, the driver registers i2c dummy devices and populates the
aux bus, which registers a device for the panel. After doing that, the
driver can still defer probe if needed. This ordering of operations is
troublesome however, because the deferred probe work will retry probing
all pending devices every time a new device is registered. Therefore, if
modules need to be loaded in order to satisfy the dependencies for this
driver to complete probe, the kernel will stall, since it'll keep trying
to probe the anx7625 driver, but never succeed, given that modules would
only be loaded after the deferred probe work completes.

Two changes are required to avoid this issue:
* Move of_find_mipi_dsi_host_by_node(), which can defer probe, to before
  anx7625_register_i2c_dummy_clients() and
  devm_of_dp_aux_populate_ep_devices(), which register devices.
* Make use of the done_probing callback when populating the aux bus,
  so that the bridge registration is only done after the panel is
  probed. This is required because the panel might need to defer probe,
  but the aux bus population needs the i2c dummy devices working, so
  this call couldn't just be moved to an earlier point in probe.
  One caveat is that if the panel is described outside the aux bus, the
  probe loop issue can still happen, but we don't have a way to avoid
  it in that case since there's no callback available.

With this patch applied, it's possible to boot on
mt8192-asurada-spherion with

CONFIG_DRM_ANALOGIX_ANX7625=y
CONFIG_MTK_MMSYS=m
CONFIG_BACKLIGHT_PWM=y

and also with

CONFIG_DRM_ANALOGIX_ANX7625=y
CONFIG_MTK_MMSYS=y
CONFIG_BACKLIGHT_PWM=m

Fixes: adca62ec ("drm/bridge: anx7625: Support reading edid through aux channel")
Fixes: 26933299 ("drm/bridge: anx7625: Return -EPROBE_DEFER if the dsi host was not found")
Reported-by: "kernelci.org bot" <bot@kernelci.org>
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
[nfraprado: with conflicts fixed to apply on top of type-c series]

Series-to: Robert Foss <rfoss@kernel.org>
Series-cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Series-cc: Pin-yen Lin <treapking@chromium.org>
Series-cc: kernel@collabora.com

The temperature thresholds configured by the driver (hot, hot to
normal), only generate interrupts if the thermal controller is
configured to filtered mode. Mark the controllers present on MT8192 as
filtered so we can make use of those interrupts.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Each LVTS thermal controller can have up to four sensors, each capable
of triggering its own interrupt when its measured temperature crosses
the configured threshold. The threshold for each sensor is handled
separately by the thermal framework, since each one is registered with
its own thermal zone and trips. However, the temperature thresholds are
configured on the controller, and therefore are shared between all
sensors on that controller.

When the temperature measured by the sensors is different enough to
cause the thermal framework to configure different thresholds for each
one, interrupts start triggering on sensors outside the last threshold
configured.

To address the issue, track the thresholds required by each sensor and
only actually set the highest one in the hardware, and disable
interrupts for all sensors outside the current configured range.

Fixes: f5f633b1 ("thermal/drivers/mediatek: Add the Low Voltage Thermal Sensor driver")
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

The thermal framework might leave the low threshold unset if there
aren't any lower trip points. This leaves the register zeroed, which
translates to a very high temperature for the low threshold. The
interrupt for this threshold is then immediately triggered, and the
state machine gets stuck, preventing any other temperature monitoring
interrupts to ever trigger.

(The same happens by not setting the Cold or Hot to Normal thresholds
when using those)

Set the unused threshold to a valid low value. This value was chosen so
that for any valid golden temperature read from the efuse, when the
value is converted to raw and back again to milliCelsius, the result
doesn't underflow.

Fixes: f5f633b1 ("thermal/drivers/mediatek: Add the Low Voltage Thermal Sensor driver")
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Out of the many interrupts supported by the hardware, the only ones of
interest to the driver currently are:
* The temperature went over the high offset threshold, for any of the
  sensors
* The temperature went below the low offset threshold, for any of the
  sensors
* The temperature went over the stage3 threshold

These are the only thresholds configured by the driver through the
OFFSETH, OFFSETL, and PROTTC registers, respectively.

The current interrupt mask in LVTS_MONINT_CONF, enables many more
interrupts, including data ready on sensors for both filtered and
immediate mode. These are not only not handled by the driver, but they
are also triggered too often, causing unneeded overhead. Disable these
unnecessary interrupts.

The meaning of each bit can be seen in the comment describing
LVTS_MONINTST in the IRQ handler.

Fixes: f5f633b1 ("thermal/drivers/mediatek: Add the Low Voltage Thermal Sensor driver")
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

There are two kinds of temperature monitoring interrupts available:
* High Offset, Low Offset
* Hot, Hot to normal, Cold

The code currently uses the hot/h2n/cold interrupts, however in a way
that doesn't work: the cold threshold is left uninitialized, which
prevents the other thresholds from ever triggering, and the h2n
interrupt is used as the lower threshold, which prevents the hot
interrupt from triggering again after the thresholds are updated by the
thermal framework, since a hot interrupt can only trigger again after
the hot to normal interrupt has been triggered.

But better yet than addressing those issues, is to use the high/low
offset interrupts instead. This way only two thresholds need to be
managed, which have a simpler state machine, making them a better match
to the thermal framework's high and low thresholds.

Fixes: f5f633b1 ("thermal/drivers/mediatek: Add the Low Voltage Thermal Sensor driver")
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Each controller can be configured to operate on immediate or filtered
mode. On filtered mode, the sensors are enabled by setting the
corresponding bits in MONCTL0, while on immediate mode, by setting
MSRCTL1.

Previously, the code would set MSRCTL1 for all four sensors when
configured to immediate mode, but given that the controller might not
have all four sensors connected, this would cause interrupts to trigger
for non-existent sensors. Fix this by handling the MSRCTL1 register
analogously to the MONCTL0: only enable the sensors that were declared.

Fixes: f5f633b1 ("thermal/drivers/mediatek: Add the Low Voltage Thermal Sensor driver")
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

There is a single IRQ handler for each LVTS thermal domain, and it is
supposed to check each of its underlying controllers for the origin of
the interrupt and clear its status. However due to a typo, only the
first controller was ever being handled, which resulted in the interrupt
never being cleared when it happened on the other controllers. Add the
missing index so interrupts are handled for all controllers.

Fixes: f5f633b1 ("thermal/drivers/mediatek: Add the Low Voltage Thermal Sensor driver")
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Update LVTS calibration data documentation for mt8192 and mt8195.

Signed-off-by: Balsam CHIHI <bchihi@baylibre.com>
Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Add thermal nodes and thermal zones for the mt8192.
The mt8192 SoC has several hotspots around the CPUs.
Specify the targeted temperature threshold to apply the mitigation
and define the associated cooling devices.

Signed-off-by: Balsam CHIHI <bchihi@baylibre.com>
Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Add LVTS Driver support for MT8192.

Co-developed-by : Nícolas F. R. A. Prado <nfraprado@collabora.com>

Signed-off-by: Balsam CHIHI <bchihi@baylibre.com>
Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Add LVTS thermal controller definition for MT8192.

Signed-off-by: Balsam CHIHI <bchihi@baylibre.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Add suspend and resume support to LVTS driver.

Signed-off-by: Balsam CHIHI <bchihi@baylibre.com>

After 3 retries, ignore sleep ctrl not ready. This allows PM suspend
of the SoC with a power consumption that is possibly slightly higher
than expected.

Still better than no suspend at all.

The proper fix for this is to reset the LARB if SLP_PROT_RDY is never
triggered.

Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

Some bootloaders will set MSDCPLL's rate lower than 400MHz: this
is a performance concern (and possibly a stability one, for very
picky eMMC/SD cards) as the MSDC controller's internal divider
will choose a frequency that is lower than expected, at the end
causing a difference in the expected mmc/sd device timings.

Make sure that the MSDCPLL frequency is always set to 400MHz to
improve performance and possibly reliability in such cases.

Fixes: 37f25828 ("arm64: dts: Add mediatek SoC mt8195 and evaluation board")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

While it is possible to run the standard UHS104/SDR104 at 200MHz, the
correct clock rate for this specification is 208MHz, so, 8MHz more.

This ensures that the maximum possible performance can be achieved, as
theoretically +8MHz means a +4MB/s throughput.

Fixes: 07984e82 ("arm64: dts: mediatek: cherry: Enable secondary SD/MMC controller")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

Various MSDC core clocks, used for multiple MSDC controller instances,
share the same parent(s): in order to add parents selection in the
mtk-sd driver to achieve an accurate clock rate for all modes, remove
the CLK_SET_RATE_PARENT flag from all MSDC clocks for all SoCs: this
will make sure that a clk_set_rate() call performed for a clock on
a secondary controller will not change the rate of a common parent,
which would result in an overclock or underclock of one of the
controllers.

Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: Markus Schneider-Pargmann <msp@baylibre.com>

The clk-mux driver was forcing the CLK_SET_RATE_PARENT flag even for
the GATE_CLK_SET_UPD_FLAGS() macro, as in mtk_clk_register_mux() the
flag was unconditionally added.

In preparation for a change on MSDC clock muxes, stop forcing this
flag and, where necessary, update clock drivers to add it so that
with this commit we introduce no functional changes for the currently
supported SoCs.

Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: Markus Schneider-Pargmann <msp@baylibre.com>

Some SoCs have two PCI-Express controllers: in the case of MT8195,
one of them is using a dedicated PHY, but the other uses a combo PHY
that is shared with USB and in that case the PHY cannot be reset
from the PCIe driver, or USB functionality will be unable to resume.

Resetting the PCIe MAC without also resetting the PHY will result in
a full system lockup at PCIe resume time and the only option to
resume operation is to hard reboot the system (with a PMIC cut-off).

To resolve this issue, check if we've got both a PHY and a MAC reset
and, if not, never assert resets at PM suspend time: in that case,
the link is still getting powered down as both the clocks and the
power domains will go down anyway.

Fixes: d537dc12 ("PCI: mediatek-gen3: Add system PM support")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>