The usage of MUTEX_MOD1 and MUTEX_MOD2 for calculating mod settings
over 32 has been confusing. To improve consistency and clarity, these
defines need to fit into the same MUTEX_MOD define as possible.
However, MUTEX_MOD1 cannot be directly used for all SoCs because,
for example, the mod1 register (0x34) of MT2712 is not adjacent to
its mod0 register (0x2c). To address this, a `mutex_mod1_reg` field
is introduced in the mutex driver data structure. This allows all
SoCs to use a unified MUTEX_MOD to determine their register offsets.
With this change, the separate usage of MUTEX_MOD1 and MUTEX_MOD2 is
eliminated, simplifying the logic for obtaining offsets and mod IDs.
Signed-off-by: Jason-JH Lin <jason-jh.lin@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20250624103928.408194-1-jason-jh.lin@mediatek.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
This structure was left unused by a previous patch:
drivers/soc/mediatek/mtk-dvfsrc.c:542:43: error: unused variable 'dvfsrc_bw_constr_mt8195' [-Werror,-Wunused-const-variable]
Fixes: b06785283e ("soc: mediatek: mtk-dvfsrc: Rename and move bw constraints data")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20250423162958.2223689-1-arnd@kernel.org
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Add support for the MediaTek Dimensity 1200 (MT6893) SoC's DVFSRC
v2 hardware: the only difference between this and the only other
supported DVFSRCv2 SoC (MT8195) is the VCore-DRAM OPP array.
Link: https://lore.kernel.org/r/20250410144019.475930-6-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Rename the MT8183 and MT8195 bandwidth constraints data structure
to, respectively, dvfsrc_bw_constr_v1 and dvfsrc_bw_constr_v2, as
the actual constraints are depending on the DVFSRC version rather
than on the SoC.
While at it, to prepare for adding a new SoC, also move the two
structures at the start of the platform data code section.
Link: https://lore.kernel.org/r/20250410144019.475930-5-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
The Mediatek Genio 1200 EVK P1V2 board has a different socinfo match
for MT8395 SoC (commercial name Genio 1200), so add it the driver.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20250220-mtk-socinfo-genio-1200-evk-v1-1-a683ad028bc5@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Now that all of the mmsys routing tables have been fixed,
migrate all of them to use the MMSYS_ROUTE() macro: this
will make sure that future additions to any of the tables
for the currently supported SoCs are compile-time sanity
checked, greatly reducing room for (way too common) mistakes.
Link: https://lore.kernel.org/r/20250212100012.33001-8-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
The mmsys driver reads the routing table and writes to the
hardware `val & mask`, but multiple entries in the mmsys
routing table for the MT8365 SoC are setting a 0x0 mask:
this effectively writes .. nothing .. to the hardware.
That would never work, and if the display controller was
actually working with the mmsys doing no routing at all,
that was only because the bootloader was correctly setting
the display controller routing registers before booting the
kernel, and the mmsys was never reset.
Make this table to actually set the routing by adding the
correct register masks to it.
While at it, also change MOUT val definitions to BIT(x), as
the MOUT registers are effectively checking for each bit to
enable output to the corresponding HW.
Please note that, for this SoC, only the MOUT registers are
checking bits (as those can enable multiple outputs), while
the others are purely reading a number to select an input.
Fixes: bc3fc5c051 ("soc: mediatek: mmsys: add MT8365 support")
Link: https://lore.kernel.org/r/20250212100012.33001-7-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
The mmsys routing table for this SoC was effectively missing
initialization of the val variable of struct mtk_mmsys_routes:
this means that `val` was incorrectly initialized to zero,
hence the registers were wrongly initialized.
Add the required regval to all of the entries of the routing
table for this SoC to fix display controller functionality.
Fixes: 060f7875bd ("soc: mediatek: mmsys: Add support for MT8167 SoC")
Link: https://lore.kernel.org/r/20250212100012.33001-6-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Change the initialization data in the arrays of structure
mtk_mmsys_routes to make use of the MMSYS_ROUTE() macro:
this will make sure that each array entry's SEL value fits
in its corresponding register mask with a compile time check.
Link: https://lore.kernel.org/r/20250212100012.33001-5-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Every MediaTek SoC with multimedia capabilities has an array of
structure mtk_mmsys_routes that defines a multimedia connection
between hardware components.
This connection is activated by writing a (masked) value in each
specific register, and the association between from->to path and
value to write is expressed as an entry in that array.
Failing to set the right path does not give any meaningful error
and makes things to simply not work as the data will either not
be retrieved from the right input port, or will be written to
the wrong output port (or both): since a misconfiguration may
effectively still be a possibly correct configuration at the HW
level, this may be only giving side effects in terms of simply
getting no functionality but, again, no errors.
In order to reduce room for mistakes in declarations of the
mmsys routes, add a macro that compile-time checks that the
provided value does at least fit in the register mask.
Link: https://lore.kernel.org/r/20250212100012.33001-4-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
The VDO1_MERGE4 hardware (merge5 software component) should be
set to enable output to DPI1_SEL by setting BIT(2) but, despite
the intention being exactly that, this won't work because the
declared register mask is wrong as it is set as GENMASK(1, 0).
Register MERGE4_MOUT_EN in VDO1 has four used bits [3, 0] so
fix the mask to reflect that.
That, in turn, allows the mmsys driver to actually set BIT(2)
in this register, fixing the MERGE4 output to DPI1 selection.
Fixes: c0349314d5 ("soc: mediatek: Support MT8188 VDOSYS1 in mtk-mmsys")
Link: https://lore.kernel.org/r/20250212100012.33001-3-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
MT8188 uses DPI1 to output to the HDMI controller: add the
Start of Frame and End of Frame configuration for the DPI1
IP to the tables to unblock generation and sending of these
signals to the GCE.
Link: https://lore.kernel.org/r/20250212100012.33001-2-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
The recently introduced SoC attribute info rework avoided modifying the
machine attribut but still used it in the log message on successful SoC
matching. It leads to print a confusing log about a board-related info
(read from devicetree) and not about the matched SoC:
```
mtk-socinfo mtk-socinfo.0.auto: MediaTek MediaTek Genio-510 EVK SoC
detected
```
So, fix the dev_info format to display SoC family and name attribute
instead.
```
mtk-socinfo mtk-socinfo.0.auto: MediaTek Genio 510 (MT8370) SoC detected.
```
Fixes: da77c2d3d0 ("soc: mediatek: mtk-socinfo: Restructure SoC attribute information")
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: Fei Shao <fshao@chromium.org>
Tested-by: Fei Shao <fshao@chromium.org>
Link: https://lore.kernel.org/r/20250221-mtk-socinfo-fix-print-v1-1-20500f30ef66@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Add an entry for the MT8390 SoC with commercial name Genio 700.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20250113-mtk-socinfo_genio-510-700-v1-2-cf5112b325b7@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Add an entry for the MT8370 SoC with commercial name Genio 510.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20250113-mtk-socinfo_genio-510-700-v1-1-cf5112b325b7@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
So far, the MediaTek socinfo driver populates the SoC information as
follows:
- family: "MediaTek"
- machine: "<marketing_name> (<soc_name>)"
e.g., "Kompanio 1380 (MT8195)"
- soc_id: <null>
This approach has some drawbacks:
1. "soc_id" can be used for showing the SoC name (e.g. "MT8195"), while
it's currently unused.
2. The newer socinfo API automatically populates the "machine"
attribute with the model name from board DTS if unspecified, which
we may want to preserve if possible.
3. "machine" combines the marketing name and SoC name, making it
trickier to parse. Ideally, the marketing name and SoC name should
be in separate attributes so userspace to utilize them as needed.
4. There's no guarantee that the marketing name will be announced along
with the SoC name. If either is undetermined, the current design
will result in a malformed "machine" output. This is observed on
some newer MediaTek platforms, where the marketing name is still
undetermined but the SoC information needs to be settled for device
registration and validation before launch.
To address these points, this commit proposes a new theme to display the
SoC information:
- family: "MediaTek <marketing_name>"
e.g., "MediaTek Kompanio 1380"
- machine: "<dt_model_name>" (auto-populated)
e.g., "Acer Tomato (rev1) board"
- soc_id: "<soc_name>"
e.g., "MT8195"
Moreover, if the marketing name is not provided, the driver displays
"MediaTek" in the "family" attribute instead, consistent with the
previous behavior.
Restructure the way driver populates the SoC information as described
above.
Note that Mediatek-based Chromebooks are the primary consumers of this
socinfo driver, and Google has prepared corresponding userspace changes
to comply with this update, so the impact to userspace is controlled.
Signed-off-by: Fei Shao <fshao@chromium.org>
Link: https://lore.kernel.org/r/20241219113411.3999355-1-fshao@chromium.org
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE+QmuaPwR3wnBdVwACF8+vY7k4RUFAmeTNHEACgkQCF8+vY7k
4RWHRA//UI8B/q+/WHzqC5CCtySIvrabFvhQOFPR1GBwPBoASS0JwGuVFZcsJbjV
m6krBshs2OTwafVH8Sbxw6tlShG5hs7fe6hwhtokEnrL5uzfgYMxf7MpM0F2g8CR
1zTow17A7TDeUhdYDTmVbdcOb9rj5oFJCEOVsQXNaAu2jsDBGVZ1P7iUZTwIeyT+
r0uUzrlLylH4neIyXu6yBWXYCmXbQXtGHxkwe5GGxKMfqKwD83KK5gd4uUpiAyJe
tKW+gzZa/ngJaCQ+cr+8/z270h2vXeNohhC3c6Kq+/6pZgyEwUgyDTXT4nYVsUdd
1DeYiQekMUE3MwsKXPtFCyH3VGMvgMQK9fc+N10KC8wj+uCaqi59une8Yz3Ck89m
tIE9R9EwBWiyAmSKEBVZAJJjOKi5TBC1lOw+RUUjnjwVG34gZhe/ML8IyWI8OcAH
nEHb8BGwWHpoO7M5bmtzSbjAhgxzizzCclp1aEIzTlAbtC+1YXd96qJxzG5qjUrA
uO0PvwghFjjiZKDU9Iwsk9q83VMCva3IX9pondmefC5OZvgR5xG/L6H5JfwRotOa
XlRLj80/Pmn+PqvHxHJYqHkp9ujqiGbq6b0PJYU7FjiyghDGV7+urHuvmT+sdLo8
+nzch/NbZDf2WFxENZOzAOSYKYbahcp3dqkiOwTU1Iu23ERkSws=
=ktuX
-----END PGP SIGNATURE-----
Merge tag 'media/v6.14-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media updates from Mauro Carvalho Chehab:
- Sensor driver fixes
- remove dead TI wl128x FM radio driver
- Add support for the imx462 sensor at the IMX290 binding
- V4L2 pixel data transmitter and receiver documentation improvements
- Add support for MIPI Discovery and Configuration for C-PHY line
orders
- imx8-isi fixes and improvements
- stm32: dcmipp: add core support for the stm32mp25
- qcom: camss: Add sc7280 support
- Various fixes and enhancements
* tag 'media/v6.14-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (152 commits)
media: nuvoton: Fix an error check in npcm_video_ece_init()
media: dvb-usb-v2: af9035: fix ISO C90 compilation error on af9035_i2c_master_xfer
media: platform: rzg2l-cru: rzg2l-video: Fix the comment in rzg2l_cru_start_streaming_vq()
media: fix secfeed undefined when filter alloc fail
media: dt-bindings: trivial white-space and example cleanup
MAINTAINERS: repair file entry in MEDIA DRIVERS FOR STM32 - CSI
media: solo6x10: Use const 'struct bin_attribute' callback
media: saa7164: Remove unused values
staging: media: imx: fix OF node leak in imx_media_add_of_subdevs()
media: platform: exynos4-is: Remove unused __is_get_frame_size
media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread
media: mmp: Bring back registration of the device
media: cec: include linux/debugfs.h and linux/seq_file.h where needed
Revert "media: qcom: camss: Restructure camss_link_entities"
media: venus: Remove unused hfi_core_ping()
media: dt-bindings: qcom-venus: Deprecate video-decoder and video-encoder where applicable
media: venus: Populate video encoder/decoder nodename entries
media: venus: Add support for static video encoder/decoder declarations
media: venus: match instance creation and destruction order
media: venus: destroy hfi session after m2m_ctx release
...
These are changes to SoC specific drivers and DT bindings that don't have
a separate subsystem tree, or that get grouped here for simplicity.
Nothing out of the ordinary for the 6.14 release here:
- Most of the updates are for Qualcomm specific drivers, adding support
for additional SoCs in the exssting drivers, and support for wrapped
encryption key access in the SCM firmware.
- The Arm SCMI firmware code gains support for having multiple
instances of firmware running, and better module auto loading.
- A few minor updates for litex, samsung, ti, tegra, mediatek, imx and
renesas platforms.
- Reset controller updates for amlogic, to add support for the A1 soc
and clean up the existing code.
- Memory controller updates for ti davinci aemif, refactoring the code
and adding a few interfaces to other drivers.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmeTgqUACgkQYKtH/8kJ
Uif73w/6A005eeovEmXLEUBMThlMpOLGeE5YL6arspQ2jvF93uh4vbJXn70xWn76
pV/1yzeu87E078mHBxcoQX0tb2Lt0xoueDBQ+jODxCcrr+6+0gPEPOq/VK7SBFH8
h1WrCeFjxmks3kyh0/8rQ4FebPClhkNT32RbQpbu+oP6n3uoKOvFgh5WxG29+hV/
6+lmzuMr7vWMnQ8KqPCX4tKPERkGE/68Gtq08SCH79K35dTVpMu6HadzURDssKdj
/SJW9rJhSZGOoYFHdOU5f2n1jRt2/Vg7snzujGFCY0pV7BW9tU/XzPV8YKU4wVx3
m0dlLCGDAN4I23TfhDJTDoEQXGU1dd4ISLf5LrbksQX9mfyZJB0hl0c9rCESuZkG
1Rt6CCgMNjSNDrqnoM2KDSwSF9mcczea6R/NDvYcU1jbX4gHZK91OuzD6AjI8OLm
1GcT8tmGPsUQElQYiSC+4rtsXBDg433p9WAnKLVH7xQ62mYzA2LQ6tvl2Cjua09z
LFNv5YD2oHNo3nI3zHFu+h/TKFJ+Tnq958mH575K54HgFfsGIv/eVvm3rXY3Tb8a
i+I41wHkGc5xuvTGgu3ZlwqC/a9cXo8jUoHPlp+c27U4VDUEkrlzRkIUaPgDZzBe
4DUCk8LTC+l0PKcOcdr5wwBArn0c4DDC+8rPnb27ZQoW0kC0GI8=
=oeUS
-----END PGP SIGNATURE-----
Merge tag 'soc-drivers-6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull SoC driver updates from Arnd Bergmann:
"These are changes to SoC specific drivers and DT bindings that don't
have a separate subsystem tree, or that get grouped here for
simplicity.
Nothing out of the ordinary for the 6.14 release here:
- Most of the updates are for Qualcomm specific drivers, adding
support for additional SoCs in the exssting drivers, and support
for wrapped encryption key access in the SCM firmware.
- The Arm SCMI firmware code gains support for having multiple
instances of firmware running, and better module auto loading.
- A few minor updates for litex, samsung, ti, tegra, mediatek, imx
and renesas platforms.
- Reset controller updates for amlogic, to add support for the A1 soc
and clean up the existing code.
- Memory controller updates for ti davinci aemif, refactoring the
code and adding a few interfaces to other drivers"
* tag 'soc-drivers-6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (58 commits)
drivers/soc/litex: Use devm_register_restart_handler()
reset: amlogic: aux: drop aux registration helper
reset: amlogic: aux: get regmap through parent device
reset: amlogic: add support for A1 SoC in auxiliary reset driver
dt-bindings: reset: add bindings for A1 SoC audio reset controller
soc/tegra: fuse: Update Tegra234 nvmem keepout list
soc/tegra: Fix spelling error in tegra234_lookup_slave_timeout()
soc/tegra: cbb: Drop unnecessary debugfs error handling
firmware: qcom: scm: add calls for wrapped key support
soc: qcom: pd_mapper: Add SM7225 compatible
dt-bindings: firmware: qcom,scm: Document ipq5424 SCM
soc: qcom: llcc: Update configuration data for IPQ5424
dt-bindings: cache: qcom,llcc: Add IPQ5424 compatible
soc: mediatek: mtk-devapc: Fix leaking IO map on driver remove
soc: mediatek: mtk-devapc: Fix leaking IO map on error paths
firmware: qcom: scm: smc: Narrow 'mempool' variable scope
firmware: qcom: scm: smc: Handle missing SCM device
firmware: qcom: scm: Cleanup global '__scm' on probe failures
firmware: qcom: scm: Fix missing read barrier in qcom_scm_get_tzmem_pool()
firmware: qcom: scm: Fix missing read barrier in qcom_scm_is_available()
...
Error paths of mtk_devapc_probe() should unmap the memory. Reported by
Smatch:
drivers/soc/mediatek/mtk-devapc.c:292 mtk_devapc_probe() warn: 'ctx->infra_base' from of_iomap() not released on lines: 277,281,286.
Fixes: 0890beb226 ("soc: mediatek: add mt6779 devapc driver")
Cc: stable@vger.kernel.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250104142012.115974-1-krzysztof.kozlowski@linaro.org
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
The helper devm_clk_bulk_get_all_enable() missed to return the number of
clocks stored in the clk_bulk_data table referenced by the clks
argument and, therefore, will be dropped.
Use the newly introduced devm_clk_bulk_get_all_enabled() variant
instead, which is consistent with devm_clk_bulk_get_all() in terms of
the returned value:
> 0 if one or more clocks have been stored
= 0 if there are no clocks
< 0 if an error occurred
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20241217-clk_bulk_ena_fix-v5-1-aafbbb245155@collabora.com
Acked-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
In order to have fine-grained control, use cmdq_pkt_eoc() and
cmdq_pkt_jump_rel() to replace cmdq_pkt_finalize().
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Acked-by: Matthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This adds support for the MT8188 SoC in the MediaTek Regulator
Coupler driver, allowing stable GPU DVFS on this chip;
Moreover, this adds a new MediaTek DVFS Resource Collector (DVFSRC)
driver, allowing to enable other drivers (interconnect, regulator)
which can now communicate with the DVFSRC hardware.
Last but not least, this includes some cleanups for the CMDQ Helper
and MediaTek SVS drivers.
-----BEGIN PGP SIGNATURE-----
iJ4EABYKAEYWIQQn3Xxr56ypAcSHzXSaNgTPrZeEeAUCZyitDigcYW5nZWxvZ2lv
YWNjaGluby5kZWxyZWdub0Bjb2xsYWJvcmEuY29tAAoJEJo2BM+tl4R4h1wA/1xT
8kHN16gVzZ6JvjvzOeipCi2YPJ0LCPv4jpvEx4abAP9tFsyVYsQGAE0XS74p3GRT
r9NhhlV7dnpQmVO/SPClDQ==
=cgv/
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmcpQSMACgkQYKtH/8kJ
UieT8A/+LmbcqykZ8LJEvKwIE7zsXEX+Jru2Ani7XMr8hbRTTHS5YsQNaRG1EdqL
9rDtwhI5L+IK6hn9JDu2RoUF2avECirX2gf+OUiMXy7Cn4BN+lpoir1sImtgSBOz
zwNq2zLzEU2im/fCaL1uN8gzi8+dR0drX9LYyaghoBlv5RlNu+NE+lx3dIezaEaU
Plx9dhH2GpbvOp6zVD01Q+6uD3bR8ybvoCPpewWv8Jn3u3+M9qf1krXOHKRqT9Vp
ErFTF3aC2KBsAPVBHBXgx/uKx918KJIvLRHYh+a5KtstRBjGwpn0SKumNyogNF2I
czULW9UX7kwqrOR1pVnu+4C28vTj38syV3VWEZ/fYUxe283TPcr86YLcZhb3u6m8
I0JpN+DqTf+f6r6tY4PWm19aKBFmDNEerIz8f2ajQoZdT6yunV+LwBMfhGYZnESC
o96lZai4U+gd9XmEHxJlGQU5prfLob/hZ/NrYScCrOrQ7lX86+30M6jtEr5GwLNS
113IWzwSwSm6yqDmDiylm4Vmk6zCmjQuaZ2YMNpk7yfWX9Mw+rNWPawf3s5k4KVe
XP+Y0UOW3SzU8OXns0XCwNVTtJL0rPsh0zKwzLcqowrLuc3P+jJyYq58VgI3g58V
1nLpRBGhM5VD83c27/borOQYjk5IsTxHx2jttrdgO6qsQN5C1JM=
=GKpu
-----END PGP SIGNATURE-----
Merge tag 'mtk-soc-for-v6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux into arm/drivers
MediaTek soc driver updates for v6.13
This adds support for the MT8188 SoC in the MediaTek Regulator
Coupler driver, allowing stable GPU DVFS on this chip;
Moreover, this adds a new MediaTek DVFS Resource Collector (DVFSRC)
driver, allowing to enable other drivers (interconnect, regulator)
which can now communicate with the DVFSRC hardware.
Last but not least, this includes some cleanups for the CMDQ Helper
and MediaTek SVS drivers.
* tag 'mtk-soc-for-v6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux:
soc: mediatek: mtk-svs: Call of_node_put(np) only once in svs_get_subsys_device()
soc: mediatek: mediatek-regulator-coupler: Support mt8188
soc: mediatek: mtk-cmdq: Move cmdq_instruction init to declaration
soc: mediatek: mtk-cmdq: Move mask build and append to function
soc: mediatek: Add MediaTek DVFS Resource Collector (DVFSRC) driver
dt-bindings: soc: mediatek: Add DVFSRC bindings for MT8183 and MT8195
Link: https://lore.kernel.org/r/20241104112625.161365-2-angelogioacchino.delregno@collabora.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
After commit 0edb555a65 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.
Convert all platform drivers below drivers/soc to use .remove(), with
the eventual goal to drop struct platform_driver::remove_new(). As
.remove() and .remove_new() have the same prototypes, conversion is done
by just changing the structure member name in the driver initializer.
On the way do a few whitespace changes to make indention consistent.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Herve Codina <herve.codina@bootlin.com> # for fsl/qe/{qmc,tsa}.c
Acked-by: Bjorn Andersson <andersson@kernel.org> # qcom parts
Acked-by: Gabriel Somlo <gsomlo@gmail.com>
Acked-by: Andrew Jeffery <andrew@codeconstruct.com.au> # aspeed
Link: https://lore.kernel.org/r/20241029074859.509587-2-u.kleine-koenig@baylibre.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
An of_node_put(np) call was immediately used after a pointer check
for a of_find_device_by_node() call in this function implementation.
Thus call such a function only once instead directly before the check.
This issue was transformed by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/884f0a5d-e6d3-47dc-8a9e-201bb86b271f@web.de
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
The Mali GPU in mt8188 also requires coupled power supplies,
that is, the "vsram" voltage should follow the "vgpu" voltage.
Therefore add the compatible to enable this coupling behavior.
Signed-off-by: Pablo Sun <pablo.sun@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20241002022138.29241-6-pablo.sun@mediatek.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Move, where possible, the initialization of struct cmdq_instruction
variables to their declaration to compress the code.
While at it, also change an instance of open-coded mask to use the
GENMASK() macro instead, and instances of `ret = func(); return ret;`
to the equivalent (but shorter) `return func()`.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Move the CMDQ_CODE_MASK packet build and append logic to a new
cmdq_pkt_mask() function; this reduces code duplication by 4x.
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
The Dynamic Voltage and Frequency Scaling Resource Collector (DVFSRC) is a
Hardware module used to collect all the requests from both software and the
various remote processors embedded into the SoC and decide about a minimum
operating voltage and a minimum DRAM frequency to fulfill those requests in
an effort to provide the best achievable performance per watt.
This hardware IP is capable of transparently performing direct register R/W
on all of the DVFSRC-controlled regulators and SoC bandwidth knobs.
This driver includes support for MT8183, MT8192 and MT8195.
Co-Developed-by: Dawei Chien <dawei.chien@mediatek.com>
[Angelo: Partial refactoring and cleanups]
Reviewed-by: Georgi Djakov <djakov@kerenl.org>
Link: https://lore.kernel.org/r/20240610085735.147134-5-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
All of mutex_mod and mutex_table_mod contain an array of bit
numbers, which can go from 0 to 63, it is hence not needed to
use an unsigned 32-bits integer to store that: change them to
unsigned 8-bits instead.
As for the mutex_sof table since this directly contains the values
to write to the DISP_MUTEXn_CTL register, which has only bits [13:0]
(so this register is effectively 14 bits long), change that to use
unsigned 16-bits.
The type of mutex_{mod,sof}_reg was also changed to 16 bits, as
the maximum value that those will ever have is 0x800, because it
calculates as 0x30 + (0x20 * n) where n's maximum value is 63.
This reduces module size and brings no functional changes.
Before:
text data bss dec hex filename
9929 512 0 10441 28c9 mtk-mutex.o
After:
text data bss dec hex filename
7425 512 0 7937 1f01 mtk-mutex.o
Link: https://lore.kernel.org/r/20240729122538.989855-1-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Use devm_clk_bulk_get_all_enable() to simplify the code and to make sure
that clk_disable_unprepare() is called if the driver is unloaded.
Fixes: 55924157da ("soc: mediatek: pwrap: add support for sys & tmr clocks")
Fixes: 1f022d84bd ("soc: mediatek: Add PMIC wrapper for MT8135 and MT8173 SoCs")
Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/5b1114c538dd5230728592855f89942aec8ef83b.1720331018.git.christophe.jaillet@wanadoo.fr
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
These arrays are not modified in this driver.
Constifying this structure moves some data to a read-only section, so
increase overall security.
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
45528 8532 16 54076 d33c drivers/soc/mediatek/mtk-pmic-wrap.o
After:
=====
text data bss dec hex filename
52664 1384 16 54064 d330 drivers/soc/mediatek/mtk-pmic-wrap.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/f1fea00fbaa0fea298bf67732e019f9cc5c407ab.1720331018.git.christophe.jaillet@wanadoo.fr
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
'struct pmic_wrapper_type' is not modified in this driver.
Constifying this structure moves some data to a read-only section, so
increase overall security.
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
45336 8724 16 54076 d33c drivers/soc/mediatek/mtk-pmic-wrap.o
After:
=====
text data bss dec hex filename
45528 8532 16 54076 d33c drivers/soc/mediatek/mtk-pmic-wrap.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/5b4b60c5dfd6d8fe893b05cfc96c0e2d67705463.1720331018.git.christophe.jaillet@wanadoo.fr
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
This adds the previously missed Tone Curve Conversion (TCC)
MuteX bit to enable the same in MDP3 on the the MT8188 SoC,
disables 9-bit Alpha for display HDR support in MT8195 and
adds math operation support in the Global Command Engine for
all MediaTek SoCs, which will be used in the near future in
the ISP driver.
-----BEGIN PGP SIGNATURE-----
iJ4EABYKAEYWIQQn3Xxr56ypAcSHzXSaNgTPrZeEeAUCZn5/kygcYW5nZWxvZ2lv
YWNjaGluby5kZWxyZWdub0Bjb2xsYWJvcmEuY29tAAoJEJo2BM+tl4R4ct0BAN+y
Bf99G+Dz2bDJOZWV5waVqatekpHhsFO0+2xgzIjRAP9Ljhbp2OjiosfYHkJWMS54
2IKKuUz/IKqxJFWydLzsCw==
=2Ckw
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmZ+55wACgkQYKtH/8kJ
UifVvQ/9H0330C3V51NDSzU+HzxOGC8xaCI9CFhOcg1N46dTYId8UvPDb4VjHBc4
PL4uAQLAHSlrjNi0+KjMYVf00G+c7cTf8px2hvkAstiGc6tiACC/dHVHOeqBIeDb
5nMtEKEMWdDzmXVf4LAl0K+/jtjLWVsKHJ6vRnD0Zd8l8Y3pZYVPS6BJmQz0qrOG
irb1pQ8lA2OL55StvvKr4z3H/vMonwFoxZZATR4FupK5wNthYQiaEJz1ZOwKuH3c
W/XanCOgc15RnueXwCXriM2PN4ELUFH7LPBfCk5WVEsWdZ3IdUYOqZaDlimPqzJF
KkynqNnwZkuB7x/3l33Y0i5crIJQVjXzs1ToJFc0CGzOJZE9D+6IbmTrD8F0VpVR
ObXb2xalfgSv7gGwv4uIKB39t7alKSjhI3E4jFgSVohDmvpLGfNFyezXmsTc/faa
7wR+hMczhAP6g0UjbxMHMRy10AsChxIYwEuZf4Ysu205zPEjf3TLTBvJralgvtTB
wlMNezrJqaBn+L5TKhlAiyZt0CC4wZMyLC724OALVJqVxX8m6+M01dPxMwPo8HmO
naDbPArN3Rw9YpP2SUeN2748hA2b9s9okL/babRDE+chb3VeFEPyFUnuC4OUTSGo
Bzrn1tJjeNXhqNJi6WiPzQ2Oc438zLPRt/IdbcXZ5RwO0wSE6Es=
=Fo/W
-----END PGP SIGNATURE-----
Merge tag 'mtk-soc-for-v6.11' of https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux into soc/drivers
MediaTek driver updates for v6.11
This adds the previously missed Tone Curve Conversion (TCC)
MuteX bit to enable the same in MDP3 on the the MT8188 SoC,
disables 9-bit Alpha for display HDR support in MT8195 and
adds math operation support in the Global Command Engine for
all MediaTek SoCs, which will be used in the near future in
the ISP driver.
* tag 'mtk-soc-for-v6.11' of https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux:
soc: mtk-cmdq: Add cmdq_pkt_logic_command to support math operation
soc: mediatek: Disable 9-bit alpha in ETHDR
soc: mediatek: mtk-mutex: Add MDP_TCC0 mod to MT8188 mutex table
Link: https://lore.kernel.org/r/20240628093801.126013-3-angelogioacchino.delregno@collabora.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
With ARCH=x86, make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/soc/imx/soc-imx8m.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/soc/ixp4xx/ixp4xx-qmgr.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/soc/ixp4xx/ixp4xx-npe.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/soc/mediatek/mtk-cmdq-helper.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/soc/amlogic/meson-clk-measure.o
Add the missing invocations of the MODULE_DESCRIPTION() macro.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Shawn Guo <shawnguo@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> # for amlogic/meson-clk-measure.c
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Link: https://lore.kernel.org/r/20240625-md-drivers-soc-v2-1-8bc7c03e3e69@quicinc.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Add cmdq_pkt_logic_command to support math operation.
cmdq_pkt_logic_command can append logic command to the CMDQ packet,
ask GCE to execute a arithmetic calculate instruction,
such as add, subtract, multiply, AND, OR and NOT, etc.
Note that all arithmetic instructions are unsigned calculations.
If there are any overflows, GCE will sent the invalid IRQ to notify
CMDQ driver.
Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com>
Link: https://lore.kernel.org/r/20240625083957.3540-1-jason-jh.lin@mediatek.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
When 9-bit alpha is enabled, its value will be converted from 0-255 to
0-256 (255 = not defined). This is designed for special HDR related
calculation, which should be disabled by default, otherwise, alpha
blending will not work correctly.
Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20240620-9bit_alpha-v1-1-13c69daaf29f@mediatek.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
MT8188's MDP3 is able to use MDP_TCC0, this mutex_mod bit does
actually exist and it's the same as MT8195: add it to the table.
Fixes: 26bb17dae6 ("soc: mediatek: mtk-mutex: Add support for MT8188 VPPSYS")
Reviewed-by: Fei Shao <fshao@chromium.org>
Link: https://lore.kernel.org/r/20240619103034.110377-1-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
As usual, these are updates for drivers that are specific to certain
SoCs or firmware running on them. Notable updates include
- The new STMicroelectronics STM32 "firewall" bus driver that is
used to provide a barrier between different parts of an SoC
- Lots of updates for the Qualcomm platform drivers, in particular
SCM, which gets a rewrite of its initialization code
- Firmware driver updates for Arm FF-A notification interrupts
and indirect messaging, SCMI firmware support for pin control
and vendor specific interfaces, and TEE firmware interface
changes across multiple TEE drivers
- A larger cleanup of the Mediatek CMDQ driver and some related bits
- Kconfig changes for riscv drivers to prepare for adding Kanaan
k230 support
- Multiple minor updates for the TI sysc bus driver, memory controllers,
hisilicon hccs and more
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmY+dbEACgkQYKtH/8kJ
UifGTBAA3lh2qw++S5i6nk71388/nswb5fZKwqPKl1m+44SndE7r0/nauGm7IZhd
oM5xiBZzsoYCKuesSuejkBNgPmUPtUhyHBJKSKjwrcak4k1mrjDgXxfSxCqGptVZ
Ps683koJ/Ic7O/LQNxlVzUlssG/3gmhJELfpaVIB7rG8pmdgF9ocM73+iJrRwW1Q
fTFXUXeCcXJ2N5Yki7z2+4oB3RebPzTBz4NeIYNdGQj5/u61oG0KzXwvk8eqWhNb
0KJYsfAQZGzdyAys6XU1MHv4T4L2a3DQL6NMgLnovVEMhP2Hk0XlBmI7X+uAXYiM
2z289d9Wx3HMoiekulDJ+rpDUPxPXrEqaRkfWZ8G+HSY4KcIeSP7YGmhylr0kdvw
+Qo6orxZ9lkSPaT1aUkNIIywDzet/E2hY8zV1EcLBu9GWjkybAvT/Uy2lSSN+LLH
yEQyDf+s90N6QuZwdXN8a3QliP39tHqlye8wou6UQG8aZ7z870fKAKlvA6DjTfPM
JyhY1rXYH/bvC87sVTi5Qb09+2R6ftvk5xijiMOyXugPpO/6PQKULVataeUnzwgs
YTgOPhaqXVadDR/nkrG3FzEtvpYeTspwGpDiEpDrNHf5H1tFg6VfPNS8y0QOlSPY
JcmylQNCtwxCRLTw2NHOb3tLcY4ruDHNmrWf5INTzf6cJe49jaU=
=4rf0
-----END PGP SIGNATURE-----
Merge tag 'soc-drivers-6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull SoC driver updates from Arnd Bergmann:
"As usual, these are updates for drivers that are specific to certain
SoCs or firmware running on them.
Notable updates include
- The new STMicroelectronics STM32 "firewall" bus driver that is used
to provide a barrier between different parts of an SoC
- Lots of updates for the Qualcomm platform drivers, in particular
SCM, which gets a rewrite of its initialization code
- Firmware driver updates for Arm FF-A notification interrupts and
indirect messaging, SCMI firmware support for pin control and
vendor specific interfaces, and TEE firmware interface changes
across multiple TEE drivers
- A larger cleanup of the Mediatek CMDQ driver and some related bits
- Kconfig changes for riscv drivers to prepare for adding Kanaan k230
support
- Multiple minor updates for the TI sysc bus driver, memory
controllers, hisilicon hccs and more"
* tag 'soc-drivers-6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (103 commits)
firmware: qcom: uefisecapp: Allow on sc8180x Primus and Flex 5G
soc: qcom: pmic_glink: Make client-lock non-sleeping
dt-bindings: soc: qcom,wcnss: fix bluetooth address example
soc/tegra: pmc: Add EQOS wake event for Tegra194 and Tegra234
bus: stm32_firewall: fix off by one in stm32_firewall_get_firewall()
bus: etzpc: introduce ETZPC firewall controller driver
firmware: arm_ffa: Avoid queuing work when running on the worker queue
bus: ti-sysc: Drop legacy idle quirk handling
bus: ti-sysc: Drop legacy quirk handling for smartreflex
bus: ti-sysc: Drop legacy quirk handling for uarts
bus: ti-sysc: Add a description and copyrights
bus: ti-sysc: Move check for no-reset-on-init
soc: hisilicon: kunpeng_hccs: replace MAILBOX dependency with PCC
soc: hisilicon: kunpeng_hccs: Add the check for obtaining complete port attribute
firmware: arm_ffa: Fix memory corruption in ffa_msg_send2()
bus: rifsc: introduce RIFSC firewall controller driver
of: property: fw_devlink: Add support for "access-controller"
soc: mediatek: mtk-socinfo: Correct the marketing name for MT8188GV
soc: mediatek: mtk-socinfo: Add entry for MT8395AV/ZA Genio 1200
soc: mediatek: mtk-mutex: Add support for MT8188 VPPSYS
...
Add an entry for the MT8395 SoC with commercial name Genio 1200.
Reviewed-by: Christopher Obbard <chris.obbard@collabora.com>
Tested-by: Christopher Obbard <chris.obbard@collabora.com>
Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
Link: https://lore.kernel.org/r/20240404082056.93454-1-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
In case we're running on a MediaTek SoC that is not declared in the
socinfo_data_table, print a message stating that and, with it, also
print out the read eFuse data: this allows to easily add a new SoC
in the table, granted that its actual soc/segment/marketing names
are already previously known.
This is especially useful when booting an already known SoC that
already has socinfo support, but has a different silicon version
and/or revision, hence different model information in the eFuses.
Link: https://lore.kernel.org/r/20240314113015.121940-1-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Most of the callers to this function do not require CMDQ support, it is
optional, so the missing property shouldn't cause an error message.
However, it could result on degraded performance, so the fact that it's
missing should still be alerted. Furthermore, the callers that do
require CMDQ support already log at the error level when an error is
returned.
Change the log message in this helper to be printed at the warning level
instead.
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20240229-gce-client-reg-log-dbg-v2-1-4975077173d0@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Add cmdq_pkt_acquire_event() function to support CMDQ user making
an instruction for acquiring event.
CMDQ users can use cmdq_pkt_acquire_event() as `mutex_lock`
and cmdq_pkt_clear_event() as `mutex_unlock` to protect the global
resource modified instructions between them.
cmdq_pkt_acquire_event() would wait for event to be cleared.
After event is cleared by cmdq_pkt_clear_event() in other GCE threads,
cmdq_pkt_acquire_event() would set event and keep executing next
instruction. So the mutex would work like this:
cmdq_pkt_acquire_event() /* mutex lock */
/* critical secton instructions that modified global resource */
cmdq_pkt_clear_event() /* mutex unlock */
Prevent the critical section instructions from being affected by other
GCE threads.
Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20240307013458.23550-5-jason-jh.lin@mediatek.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Add cmdq_pkt_poll_addr function to support CMDQ user making
an instruction for polling a specific address of hardware rigster
to check the value with or without mask.
POLL is a legacy operation in GCE, so it does not support SPR and
CMDQ_CODE_LOGIC. To support polling the register address which doesn't
have the subsys id, CMDQ users need to make an instruction with GPR and
CMDQ_CODE_MASK operation to move the register address to be poll into GPR.
Then users can make an POLL instruction with GPR to poll the register
address assigned in previous instruction.
Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20240307013458.23550-4-jason-jh.lin@mediatek.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Add cmdq_pkt_mem_move() function to support CMDQ user making
an instruction for moving a value from a source address to a
destination address.
Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20240307013458.23550-3-jason-jh.lin@mediatek.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
cmdq_pkt_create() and cmdq_pkt_destroy() is not suitable for
client drivers so each client driver has implement its own
function. This refinement would pass struct cmdq_pkt pointer into
cmdq_pkt_create(). In addition, client driver has the struct
cmdq_client information, so it's not necessary to store this
information in struct cmdq_pkt. After this refinement, client
drivers could use these helper funciton instead of implementing
its own version.
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Link: https://lore.kernel.org/r/20240222154120.16959-8-chunkuang.hu@kernel.org
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
cmdq_pkt_flush_async() is not used by all client drivers (MediaTek
drm driver and MediaTek mdp3 driver), so remove it.
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Link: https://lore.kernel.org/r/20240222154120.16959-7-chunkuang.hu@kernel.org
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
