* [PATCH v3 0/2] iio: adc: Add Axiado SARADC driver
From: Petar Stepanovic @ 2026-06-22 7:47 UTC (permalink / raw)
To: Akhila Kavi, Prasad Bolisetty, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah
Cc: linux-iio, devicetree, linux-arm-kernel, linux-kernel,
Petar Stepanovic, Conor Dooley
This series adds support for the SAR ADC controller found on Axiado
AX3000 and AX3005 SoCs.
A new driver is needed because this SAR ADC controller is a SoC-specific
hardware block used on Axiado SoCs. It has its own register layout,
channel enable handling, conversion control, and data readout sequence,
and it does not match any existing upstream IIO ADC driver.
AX3000 provides sixteen input channels, while AX3005 provides eight
input channels. The driver uses SoC match data to select the number of
available channels for each compatible.
The driver supports single-shot voltage reads through the IIO subsystem
and uses the reference voltage regulator for scale calculation.
The datasheet is not publicly available. Public high-level product
information is available at:
https://axiado.com/products/#AX3080
The register definitions and programming sequence used by this driver
are based on Axiado internal SoC documentation.
Signed-off-by: Petar Stepanovic <pstepanovic@axiado.com>
---
Changes in v3:
- Fixed vref regulator error handling.
- Added linux/units.h and used MICRO / MILLI in scale calculation.
- Reordered struct axiado_saradc members to improve the structure
layout.
- Fixed indentation/alignment of multi-line FIELD_PREP(), GENMASK(), and
writel() expressions.
- Removed the blank line before module_platform_driver().
- Link to v2: https://lore.kernel.org/r/20260611-axiado-ax3000-ax3005-saradc-v2-0-913c9de7c64c@axiado.com
Changes in v2:
- Fixed the devicetree example node name to use the generic ADC node name.
- Removed the explicit `depends on OF` from Kconfig.
- Cleaned up and reordered header includes.
- Added missing includes for `bits.h`, `clk.h`, `cleanup.h`, and `err.h`.
- Removed unused `linux/kernel.h` include.
- Renamed register offset macros to use the `_REG` suffix.
- Renamed register bitfield macros to include the register name prefix.
- Added separate macros for `GLOBAL_CTRL` and `MANUAL_CTRL` register
fields and values.
- Replaced `iowrite32()` / `ioread32()` with `writel()` / `readl()`.
- Moved ADC conversion locking into `axiado_saradc_conversion()` using
`guard(mutex)`.
- Replaced `usleep_range()` with `fsleep()`.
- Renamed `vref_uv` to `vref_uV`.
- Added SoC-specific device names in `axiado_saradc_soc_data`.
- Used the fixed SoC-specific name for `indio_dev->name`.
- Removed unused buffered scan configuration from IIO channels.
- Added a managed cleanup action to disable the SARADC hardware on driver
unbind or probe failure.
- Switched to a local `struct device *dev` helper in probe.
- Used `devm_mutex_init()` for mutex initialization.
- Simplified error handling by using `dev_err_probe()`.
- Updated probe variable declarations to follow reverse Christmas tree
order.
- Fixed the `of_device_id` terminator style.
- Replaced `KBUILD_MODNAME` with a fixed driver name string.
- Link to v1: https://lore.kernel.org/r/20260528-axiado-ax3000-ax3005-saradc-v1-0-345dd5f6608a@axiado.com
---
Petar Stepanovic (2):
dt-bindings: iio: adc: add Axiado AX3000/AX3005 SARADC
iio: adc: add Axiado SARADC driver
.../bindings/iio/adc/axiado,ax3000-saradc.yaml | 63 ++++++
MAINTAINERS | 8 +
drivers/iio/adc/Kconfig | 10 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/axiado_saradc.c | 245 +++++++++++++++++++++
5 files changed, 327 insertions(+)
---
base-commit: 51f0c0b8545b23963afd5d43a8f56ee05bfa54da
change-id: 20260508-axiado-ax3000-ax3005-saradc-151aed5d25da
Best regards,
--
Petar Stepanovic <pstepanovic@axiado.com>
^ permalink raw reply
* Re: [PATCH v11 5/6] arm64: dts: qcom: monaco: Add OPP-table for ICE UFS and ICE eMMC nodes
From: Abhinaba Rakshit @ 2026-06-22 7:38 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Konrad Dybcio, Manivannan Sadhasivam,
James E.J. Bottomley, Martin K. Petersen, Adrian Hunter,
Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neeraj Soni, Harshal Dev, Kuldeep Singh, linux-arm-msm,
linux-kernel, linux-scsi, linux-mmc, devicetree
In-Reply-To: <d8fd7888-cf7d-47e2-8e77-3ba705c88502@oss.qualcomm.com>
On Thu, Jun 18, 2026 at 03:04:57PM +0200, Konrad Dybcio wrote:
> On 6/8/26 11:47 PM, Abhinaba Rakshit wrote:
> > Qualcomm Inline Crypto Engine (ICE) platform driver now, supports
> > an optional OPP-table.
> >
> > Add OPP-table for ICE UFS and ICE eMMC device nodes for Monaco
> > platform.
> >
> > Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> > ---
> > arch/arm64/boot/dts/qcom/monaco.dtsi | 37 ++++++++++++++++++++++++++++++++++++
> > 1 file changed, 37 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
> > index a1b6e6211b84d0d5008231c55613a0ccd61b9450..d9298d8b7874b8669b2cded2a28a99dce6eadbda 100644
> > --- a/arch/arm64/boot/dts/qcom/monaco.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
> > @@ -2742,6 +2742,27 @@ ice: crypto@1d88000 {
> > clock-names = "core",
> > "iface";
> > power-domains = <&gcc GCC_UFS_PHY_GDSC>;
> > +
> > + operating-points-v2 = <&ice_opp_table>;
> > +
> > + ice_opp_table: opp-table {
> > + compatible = "operating-points-v2";
> > +
> > + opp-75000000 {
> > + opp-hz = /bits/ 64 <75000000>;
> > + required-opps = <&rpmhpd_opp_svs_l1>;
> > + };
> > +
> > + opp-201600000 {
> > + opp-hz = /bits/ 64 <201600000>;
> > + required-opps = <&rpmhpd_opp_svs_l1>;
> > + };
>
> Since 75 MHz and 201.6 Mhz require the same power level, is the former
> OPP any useful?
Yes, both use the same power requirements. However recommended by the ICE team,
the DT should include all opp/freq supported by the hardware.
Abhinaba Rakshit
^ permalink raw reply
* Re: [PATCH v5 2/2] hw_random: timeriomem-rng: add configurable read width and data mask
From: Krzysztof Kozlowski @ 2026-06-22 7:37 UTC (permalink / raw)
To: Jad Keskes
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Olivia Mackall,
Herbert Xu, Alexander Clouter, devicetree, linux-crypto,
linux-kernel
In-Reply-To: <20260618120110.36439-2-inasj268@gmail.com>
On Thu, Jun 18, 2026 at 01:01:10PM +0100, Jad Keskes wrote:
> The TODO for supporting read sizes other than 32 bits and masking has
> been sitting in this driver since 2009. Implement it.
And who - which driver/platform - uses or needs that? We are not really
doing things because someone wrote TODO in 2009. Quite likely notes
from 2009 are way outdated...
>
> Add reg-io-width (1, 2, or 4 bytes) and mask support. The read loop
> dispatches on width using readb/readw/readl so a configured 1-byte
> access does not trigger a bus error on hardware that rejects 32-bit
> reads to that address. The mask is ANDed with the value before storing.
>
> These are platform properties, not runtime policy -- width depends on
> SoC integration, mask reflects which output bits carry entropy.
>
> The alignment check in probe is updated to verify the resource is
> aligned to the configured width instead of hardcoding 4-byte alignment.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: rng: timeriomem_rng: add reg-io-width and mask properties
From: Krzysztof Kozlowski @ 2026-06-22 7:36 UTC (permalink / raw)
To: Jad Keskes
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Olivia Mackall,
Herbert Xu, Alexander Clouter, devicetree, linux-crypto,
linux-kernel
In-Reply-To: <20260618120110.36439-1-inasj268@gmail.com>
On Thu, Jun 18, 2026 at 01:01:09PM +0100, Jad Keskes wrote:
> Add optional reg-io-width (1, 2, or 4 bytes) and mask properties.
> reg-io-width selects the bus access size. mask is ANDed with the raw
> register value to allow only the entropy-bearing bits through.
You should explain here why. Why are you doing this? Why do we want
this?
>
> Update the example to show a 1-byte configuration.
>
> Signed-off-by: Jad Keskes <inasj268@gmail.com>
> ---
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v11 1/6] soc: qcom: ice: Add OPP-based clock scaling support for ICE
From: Abhinaba Rakshit @ 2026-06-22 7:34 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Konrad Dybcio, Manivannan Sadhasivam,
James E.J. Bottomley, Martin K. Petersen, Adrian Hunter,
Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neeraj Soni, Harshal Dev, Kuldeep Singh, linux-arm-msm,
linux-kernel, linux-scsi, linux-mmc, devicetree
In-Reply-To: <d1232243-2f23-423b-84ac-4463eac79f9a@oss.qualcomm.com>
On Thu, Jun 18, 2026 at 03:01:54PM +0200, Konrad Dybcio wrote:
> On 6/8/26 11:47 PM, Abhinaba Rakshit wrote:
> > Register optional operation-points-v2 table for ICE device
> > during device probe. Attach the OPP-table with only the ICE
> > core clock. Since, dtbinding is on a transition phase to include
> > iface clock and clock-names, attaching the opp-table to core clock
> > remains optional such that it does not cause probe failures.
> >
> > Introduce clock scaling API qcom_ice_scale_clk which scale ICE
> > core clock based on the target frequency provided and if a valid
> > OPP-table is registered. Use round_ceil passed to decide on the
> > rounding of the clock freq against OPP-table. Clock scaling is
> > disabled when a valid OPP-table is not registered.
> >
> > This ensures when an ICE-device specific OPP table is available,
> > use the PM OPP framework to manage frequency scaling and maintain
> > proper power-domain constraints.
> >
> > Also, ensure to drop the votes in suspend to prevent power/thermal
> > retention. Subsequently restore the frequency in resume from
> > core_clk_freq which stores the last ICE core clock operating frequency.
> >
> > Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
> > Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> > ---
>
> [...]
>
> > @@ -335,6 +342,11 @@ int qcom_ice_suspend(struct qcom_ice *ice)
> > {
> > clk_disable_unprepare(ice->iface_clk);
> > clk_disable_unprepare(ice->core_clk);
> > +
> > + /* Drop the clock votes while suspend */
> > + if (ice->has_opp)
> > + dev_pm_opp_set_rate(ice->dev, 0);
>
> The PM core will quiesce the vote as the device suspends, this is
> unnecessary. Similarly, the rate restore logic will become unnecessary.
> Especially since dev_pm_opp_set_rate(0) does not actually do any rate
> setting.
This section was earlier discussed in the patchset v4:
https://lore.kernel.org/all/7b219a50-6971-4a0c-a465-418f8abd5556@oss.qualcomm.com/
The intention here was to drop the RPMh votes once the device goes to suspend same
as the storage drivers such as mmc drivers does:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/mmc/host/sdhci-msm.c#n2946
This was done to leave the hanging votes *on* for unused clocks.
However, I get your point, due to mean to say that once device goes to suspend
and GDSC power-domain will be turned OFF, it will automatically quiesce the
performance votes?
Abhinaba Rakshit
^ permalink raw reply
* Re: [PATCH v6 2/8] dt-bindings: clock: qcom,glymur-tcsr: Add mahua support
From: Krzysztof Kozlowski @ 2026-06-22 7:32 UTC (permalink / raw)
To: Qiang Yu
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Konrad Dybcio, linux-arm-msm, linux-clk, devicetree, linux-kernel,
krishna.chundru
In-Reply-To: <20260621-tcsr_qref_0622-v6-2-c939c22ded0c@oss.qualcomm.com>
On Sun, Jun 21, 2026 at 10:11:25PM -0700, Qiang Yu wrote:
> Mahua shares the same QREF TX/RPT/RX component naming as Glymur, but
> has a different topology: a single QREF block fed by REFGEN3 only,
> rather than the two independent blocks fed by REFGEN3 and REFGEN4 on
> Glymur.
>
> Add qcom,mahua-tcsr compatible and document its required supply
> properties.
>
> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> ---
> .../bindings/clock/qcom,glymur-tcsr.yaml | 68 ++++++++++++++++------
> 1 file changed, 50 insertions(+), 18 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml
> index 16fc6ab87f9b..2b6422627165 100644
> --- a/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml
> +++ b/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml
> @@ -20,7 +20,9 @@ description: |
> properties:
> compatible:
> items:
> - - const: qcom,glymur-tcsr
> + - enum:
> + - qcom,glymur-tcsr
You could have made this enum in the first patch, so you would avoid
changing the same line twice. Usually adding line in patch #1 and then
removing it in patch #2 is indication of something to improve.
> + - qcom,mahua-tcsr
> - const: syscon
>
> clocks:
> @@ -41,9 +43,11 @@ properties:
> vdda-qrefrpt2-0p9-supply: true
> vdda-qrefrpt3-0p9-supply: true
> vdda-qrefrpt4-0p9-supply: true
> + vdda-qrefrpt5-0p9-supply: true
> vdda-qrefrx0-0p9-supply: true
> vdda-qrefrx1-0p9-supply: true
> vdda-qrefrx2-0p9-supply: true
> + vdda-qrefrx3-0p9-supply: true
> vdda-qrefrx4-0p9-supply: true
> vdda-qrefrx5-0p9-supply: true
> vdda-qreftx0-0p9-supply: true
> @@ -54,26 +58,54 @@ properties:
> vdda-refgen4-0p9-supply: true
> vdda-refgen4-1p2-supply: true
>
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: qcom,glymur-tcsr
> + then:
> + required:
> + - vdda-qrefrpt0-0p9-supply
> + - vdda-qrefrpt1-0p9-supply
> + - vdda-qrefrpt2-0p9-supply
> + - vdda-qrefrpt3-0p9-supply
> + - vdda-qrefrpt4-0p9-supply
> + - vdda-qrefrx0-0p9-supply
> + - vdda-qrefrx1-0p9-supply
> + - vdda-qrefrx2-0p9-supply
> + - vdda-qrefrx4-0p9-supply
> + - vdda-qrefrx5-0p9-supply
> + - vdda-qreftx0-0p9-supply
> + - vdda-qreftx0-1p2-supply
> + - vdda-qreftx1-0p9-supply
> + - vdda-refgen3-0p9-supply
> + - vdda-refgen3-1p2-supply
> + - vdda-refgen4-0p9-supply
> + - vdda-refgen4-1p2-supply
It is fine, although this you could as well keep like that in first
patch and mention in commit msg, that binding will grow, thus you
already define if:then: block to accommodate future changes.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH 0/7] soc: aspeed: Add AST2600 eSPI controller support
From: YH Chung @ 2026-06-22 7:31 UTC (permalink / raw)
To: YH Chung, Shulzhenko, Oleksandr, Arnd Bergmann, Andrew Jeffery,
Conor Dooley
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Ryan Chen, Philipp Zabel, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, maciej.lawniczak@intel.com, Mark Brown
In-Reply-To: <KL1PR0601MB427604A7136947D020CF272D90002@KL1PR0601MB4276.apcprd06.prod.outlook.com>
Hi Shulzhenko, Arnd, Andrew
Please allow me to summarize the potential approaches we have discussed so
far for upstreaming the eSPI driver:
(1) Reuse the existing SPI subsystem and treat eSPI packets as pure signals.
(2) Maintain the driver under the SoC subsystem, since there is currently no
eSPI subsystem.
(3) Create a new eSPI subsystem and rewrite the eSPI driver accordingly.
For option 1, we do not think this would be a good fit, because eSPI has
clearly defined semantics for each channel, and our hardware exposes
different sets of registers for each of them.
For option 2, we think this would be a practical short-term solution, and we
can expose the per-channel functionality through the existing GPIO, MCTP, and
MTD subsystems for the VW, OOB, and flash channels, respectively.
However, this may need to be revisited once an eSPI subsystem becomes
available in-tree.
For option 3, our concern is that there is currently no other eSPI hardware
or driver in-tree that could serve as a reference for defining a more generic
interface. Creating a new subsystem at this stage may therefore be somewhat
over-engineered, since it would only have one user.
We understand that Nuvoton may be the next likely vendor to support eSPI in
their BMC SoCs. Since drivers/soc patches for Nuvoton BMCs also go through
the BMC tree, we expect there would be an opportunity to reconsider whether
an independent eSPI subsystem is needed once another user appears.
Based on the above, we would like to prepare and submit the next revision
with the driver located under drivers/soc.
Could you please let us know if there are any concerns or suggestions that we
have not covered, or whether we could send the next revision for review?
^ permalink raw reply
* Re: [PATCH v6 1/8] dt-bindings: clock: qcom: Move glymur TCSR to own binding
From: Krzysztof Kozlowski @ 2026-06-22 7:30 UTC (permalink / raw)
To: sashiko-reviews; +Cc: Qiang Yu, robh, conor+dt, devicetree
In-Reply-To: <20260622051811.D8B041F000E9@smtp.kernel.org>
On Mon, Jun 22, 2026 at 05:18:11AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The commit message claims to 'Mark the relevant supplies as required per compatible using allOf/if/then conditionals', but the implementation uses an unconditional global `required` list. The conditionals are actually introduced in the subsequent patch 'dt-bindings: clock: qcom,glymur-tcsr: Add mahua support', making the commit message for this patch inaccurate.
This is a valid comment.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 1/8] dt-bindings: clock: qcom: Move glymur TCSR to own binding
From: Krzysztof Kozlowski @ 2026-06-22 7:29 UTC (permalink / raw)
To: Qiang Yu
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Konrad Dybcio, linux-arm-msm, linux-clk, devicetree, linux-kernel,
krishna.chundru
In-Reply-To: <20260621-tcsr_qref_0622-v6-1-c939c22ded0c@oss.qualcomm.com>
On Sun, Jun 21, 2026 at 10:11:24PM -0700, Qiang Yu wrote:
> The QREF block supplies reference clocks to PCIe PHYs and requires
> dedicated LDO supplies to operate. The digital control interface for QREF
> (clkref_en registers) resides in TCSR on glymur. Since QREF has no
> dedicated DT node of its own, these supply properties are placed in the
> TCSR node which acts as the control interface for QREF.
>
> Add a dedicated binding file for qcom,glymur-tcsr and document the supply
> properties.
>
> Mark the relevant supplies as required per compatible using allOf/if/then
> conditionals.
>
> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> ---
> .../bindings/clock/qcom,glymur-tcsr.yaml | 114 +++++++++++++++++++++
> .../bindings/clock/qcom,sm8550-tcsr.yaml | 2 -
> 2 files changed, 114 insertions(+), 2 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 1/3] regulator: dt-bindings: Add Unisoc SC2730 PMIC
From: Krzysztof Kozlowski @ 2026-06-22 7:29 UTC (permalink / raw)
To: Otto Pflüger
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Orson Zhai, Baolin Wang, Chunyan Zhang, Lee Jones,
linux-kernel, devicetree, Krzysztof Kozlowski
In-Reply-To: <20260620-sc2730-regulators-v6-1-bbd2db395231@abscue.de>
On Sat, Jun 20, 2026 at 10:54:00AM +0200, Otto Pflüger wrote:
> Add bindings for the regulators found in the Spreadtrum/Unisoc SC2730
> PMIC, used e.g. with the UMS512 and UMS9230 SoCs.
>
> Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> .../bindings/regulator/sprd,sc2730-regulator.yaml | 44 ++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
>
Sashiko has good point - where is any user of this binding (through
reference)? Without $ref, this won't match thus is a noop for validation.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v9 3/9] regulator: dt-bindings: Add MediaTek MT6392 PMIC
From: Krzysztof Kozlowski @ 2026-06-22 7:23 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Liam Girdwood,
Mark Brown, Linus Walleij, Julien Massot, Louis-Alexis Eyraud,
Val Packett, Fabien Parent, Akari Tsuyukusa, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <20260621081634.467858-4-l.scorcia@gmail.com>
On Sun, Jun 21, 2026 at 10:13:28AM +0200, Luca Leonardo Scorcia wrote:
> Add bindings for the regulators found in the MediaTek MT6392 PMIC,
> usually found in board designs using the MediaTek MT8516/MT8167 SoCs.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../regulator/mediatek,mt6392-regulator.yaml | 112 ++++++++++++++++++
> .../regulator/mediatek,mt6392-regulator.h | 23 ++++
> 2 files changed, 135 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> create mode 100644 include/dt-bindings/regulator/mediatek,mt6392-regulator.h
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 6/7] drm/tegra: vic: Add Tegra264 support
From: sashiko-bot @ 2026-06-22 7:11 UTC (permalink / raw)
To: Mikko Perttunen; +Cc: robh, dri-devel, conor+dt, devicetree
In-Reply-To: <20260622-t264-host1x-v2-6-ff7364d9ff7b@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Error paths in vic_load_firmware leave a dangling pointer in vic->falcon.firmware.virt, causing Use-After-Free and Double Free.
--
commit c58aa87e57c2ab3ec5383df99d29ec8f6a79e162
Author: Mikko Perttunen <mperttunen@nvidia.com>
Subject: drm/tegra: vic: Add Tegra264 support
Add support for VIC on Tegra264. The Tegra264 VIC uses a RISC-V based
Falcon microcontroller instead of the traditional Falcon previously,
and has the TRANSCFG register in a different place.
> diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
> index 332c9b563d3f4..46c7e00de3473 100644
> --- a/drivers/gpu/drm/tegra/vic.c
> +++ b/drivers/gpu/drm/tegra/vic.c
[ ... ]
> @@ -302,7 +330,6 @@ static int vic_load_firmware(struct vic *vic)
> return err;
> }
>
[Severity: Critical]
This is a pre-existing issue, but I noticed a potential use-after-free and
double-free in the error handling of vic_load_firmware().
When memory allocation succeeds, the pointers are assigned:
vic->falcon.firmware.virt = virt;
vic->falcon.firmware.iova = iova;
If a subsequent step fails (such as falcon_load_firmware() or
dma_map_single()), the code jumps to the cleanup label, frees the memory,
but does not clear the pointer:
cleanup:
if (!client->group)
dma_free_coherent(vic->dev, size, virt, iova);
else
tegra_drm_free(tegra, size, virt, iova);
mutex_unlock(&lock);
return err;
If vic_load_firmware() is called again (for example, during the next PM runtime
resume), it sees the non-NULL pointer, assumes the firmware is loaded, and
returns 0.
Will this cause the driver to program the hardware to DMA from the freed memory?
Furthermore, when the device is unbound, will the teardown path unconditionally
free vic->falcon.firmware.virt again causing a double-free?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260622-t264-host1x-v2-0-ff7364d9ff7b@nvidia.com?part=6
^ permalink raw reply
* Re: [PATCH v2 3/7] gpu: host1x: Correctly parse linear ranges of context devices
From: sashiko-bot @ 2026-06-22 7:09 UTC (permalink / raw)
To: Mikko Perttunen; +Cc: conor+dt, dri-devel, devicetree, robh
In-Reply-To: <20260622-t264-host1x-v2-3-ff7364d9ff7b@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The `struct device` objects embedded in `host1x_memory_context` are allocated as a contiguous array and freed synchronously via `kfree(cdl->devs)` on error paths and teardown, violating device lifecycle rules.
--
commit a5e361c6f75f05af608f6d934522d035e2ecb31b
Author: Mikko Perttunen <mperttunen@nvidia.com>
gpu: host1x: Correctly parse linear ranges of context devices
The previous parsing of the iommu-map property assumed each context
device has its own one-length entry in the device tree. This patch updates
the logic to support linear ranges by properly summing the lengths.
> diff --git a/drivers/gpu/host1x/context.c b/drivers/gpu/host1x/context.c
> index d50d41c205617..52ca663902ad1 100644
> --- a/drivers/gpu/host1x/context.c
> +++ b/drivers/gpu/host1x/context.c
[ ... ]
> @@ -34,7 +34,16 @@ int host1x_memory_context_list_init(struct host1x *host1x)
> if (err < 0)
> return 0;
>
> - cdl->len = err / 4;
> + devs = 0;
> +
> + for (i = 0; i < err / 4; i++) {
> + u32 length;
> +
> + of_property_read_u32_index(node, "iommu-map", i * 4 + 3, &length);
> + devs += length;
> + }
> +
> + cdl->len = devs;
> cdl->devs = kzalloc_objs(*cdl->devs, cdl->len);
[Severity: High]
This is a pre-existing issue, but allocating struct device objects as a
contiguous array and synchronously freeing them can lead to a use-after-free.
When host1x_memory_context_list_init() fails later on, it jumps to the
unreg_devices label:
unreg_devices:
while (i--)
device_unregister(&cdl->devs[i].dev);
kfree(cdl->devs);
Calling device_unregister() drops a reference, but does not guarantee the
reference count drops to zero immediately. If another subsystem or userspace
holds an asynchronous reference, kfree() will prematurely free the entire
array while those references are still active.
Later, when the final reference is dropped, the kernel will attempt to invoke
the host1x_memory_context_release() callback on the already freed memory.
Can the individual context devices be allocated separately to allow them to
have independent lifecycles managed by their respective release callbacks?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260622-t264-host1x-v2-0-ff7364d9ff7b@nvidia.com?part=3
^ permalink raw reply
* Re: [PATCH v2 5/7] drm/tegra: falcon: Add support for RISC-V external boot
From: sashiko-bot @ 2026-06-22 7:08 UTC (permalink / raw)
To: Mikko Perttunen; +Cc: devicetree, robh, dri-devel, conor+dt
In-Reply-To: <20260622-t264-host1x-v2-5-ff7364d9ff7b@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing bounds check, endianness conversion, and size validation of the RISC-V firmware descriptor leads to out-of-bounds memory accesses and unbounded DMA.
--
commit ce83e1285215f11b260dbf628363fe352ce09b78
Author: Mikko Perttunen <mperttunen@nvidia.com>
drm/tegra: falcon: Add support for RISC-V external boot
Add support for loading and booting RISC-V firmwares on Falcons with
RISC-V hardware.
> diff --git a/drivers/gpu/drm/tegra/falcon.c b/drivers/gpu/drm/tegra/falcon.c
> index 17f616bbcb45b..1172356b6af3b 100644
> --- a/drivers/gpu/drm/tegra/falcon.c
> +++ b/drivers/gpu/drm/tegra/falcon.c
[ ... ]
> @@ -122,6 +126,17 @@ static int falcon_parse_firmware_image(struct falcon *falcon)
> return 0;
> }
>
> +static void falcon_parse_firmware_desc(struct falcon *falcon)
> +{
> + struct falcon_fw_riscv_desc *desc =
> + (struct falcon_fw_riscv_desc *)falcon->firmware.desc_firmware->data;
> +
> + falcon->firmware.code.offset = desc->code_offset;
> + falcon->firmware.code.size = desc->code_size;
> + falcon->firmware.data.offset = desc->data_offset;
> + falcon->firmware.data.size = desc->data_size;
[Severity: High]
Does this code need to validate the size of desc_firmware before casting its
data to struct falcon_fw_riscv_desc? If the firmware file is smaller than the
struct size, this could lead to an out-of-bounds read.
Also, do these fields need le32_to_cpu() conversion for big-endian systems,
similar to how the main firmware is handled in falcon_copy_firmware_image()?
Finally, are the parsed sizes and offsets validated against the main firmware's
size? If not, these unchecked values could cause out-of-bounds host memory
accesses later in falcon_boot() when they are used in the falcon_copy_chunk()
DMA loops:
for (offset = 0; offset < falcon->firmware.data.size; offset += 256)
falcon_copy_chunk(falcon,
falcon->firmware.data.offset + offset,
offset, FALCON_MEMORY_DATA);
> +}
> +
> int falcon_read_firmware(struct falcon *falcon, const char *name)
> {
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260622-t264-host1x-v2-0-ff7364d9ff7b@nvidia.com?part=5
^ permalink raw reply
* Re: [PATCH v2 0/7] Host1x/VIC support on Tegra264
From: Mikko Perttunen @ 2026-06-22 7:06 UTC (permalink / raw)
To: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-tegra, dri-devel, devicetree, linux-kernel, Santosh BS
In-Reply-To: <20260622-t264-host1x-v2-0-cdbb730165c4@nvidia.com>
On Monday, June 22, 2026 3:52 PM Mikko Perttunen wrote:
> Hello everyone,
> ...
Please disregard this one, email is hard. v2 submitted as another
thread.
Thanks
Mikko
^ permalink raw reply
* Re: [PATCH v2 4/7] gpu: host1x: Add Tegra264 support
From: sashiko-bot @ 2026-06-22 7:05 UTC (permalink / raw)
To: Mikko Perttunen; +Cc: conor+dt, dri-devel, robh, devicetree
In-Reply-To: <20260622-t264-host1x-v2-4-ff7364d9ff7b@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] In `hw_host1x10_uclass.h`, the macro definition following `host1x_uclass_indoff_rwn_read_v` incorrectly redefines `HOST1X_UCLASS_INDOFF_INDROFFSET_F` instead of defining `HOST1X_UCLASS_INDOFF_RWN_READ_V`.
--
commit 6528bd5a94c6539553c675b4b4c0ced0e30024a6
Author: Santosh BS <santoshb@nvidia.com>
gpu: host1x: Add Tegra264 support
This commit adds device data and chip headers for Tegra264.
> diff --git a/drivers/gpu/host1x/hw/hw_host1x10_uclass.h b/drivers/gpu/host1x/hw/hw_host1x10_uclass.h
> new file mode 100644
> index 0000000000000..abe83e67fa837
> --- /dev/null
> +++ b/drivers/gpu/host1x/hw/hw_host1x10_uclass.h
[ ... ]
> +static inline u32 host1x_uclass_indoff_indroffset_f(u32 v)
> +{
> + return (v & 0xffff) << 2;
> +}
> +#define HOST1X_UCLASS_INDOFF_INDROFFSET_F(v) \
> + host1x_uclass_indoff_indroffset_f(v)
> +static inline u32 host1x_uclass_indoff_rwn_read_v(void)
> +{
> + return 1;
> +}
> +#define HOST1X_UCLASS_INDOFF_INDROFFSET_F(v) \
> + host1x_uclass_indoff_indroffset_f(v)
[Severity: Low]
Does this code accidentally redefine HOST1X_UCLASS_INDOFF_INDROFFSET_F?
It looks like this might be a copy-paste error where
HOST1X_UCLASS_INDOFF_RWN_READ_V should have been defined instead, calling
host1x_uclass_indoff_rwn_read_v().
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260622-t264-host1x-v2-0-ff7364d9ff7b@nvidia.com?part=4
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: qcom: kodiak: Sort pinctrl subnodes by pins
From: Luca Weiss @ 2026-06-22 7:05 UTC (permalink / raw)
To: Konrad Dybcio, Luca Weiss, Vladimir Zapolskiy, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <ba0e9f93-fd2b-4895-b8a7-8e38eeff9bcb@oss.qualcomm.com>
On Mon Jun 15, 2026 at 2:09 PM CEST, Konrad Dybcio wrote:
> On 6/12/26 3:46 PM, Luca Weiss wrote:
>> On Fri Jun 12, 2026 at 2:59 PM CEST, Vladimir Zapolskiy wrote:
>>> As documented in the "Devicetree Sources (DTS) Coding Style" document,
>>> pinctrl subnodes should be sorted by the pins property. Do this once for
>>> kodiak.dtsi so that future additions can be added at the right places.
>>>
>>> No functional change intended, verified with dtx_diff.
>>>
>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>>> ---
>>> arch/arm64/boot/dts/qcom/kodiak.dtsi | 1382 +++++++++++++++++-----------------
>>> 1 file changed, 691 insertions(+), 691 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>> index fa540d8c2615..62daef726d32 100644
>>> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>
>> <snip>
>>
>>> + qup_uart12_cts: qup-uart12-cts-state {
>>> + pins = "gpio48";
>>> + function = "qup14";
>>> + };
>>> +
>>> + qup_uart12_rts: qup-uart12-rts-state {
>>> + pins = "gpio49";
>>> + function = "qup14";
>>> + };
>>> +
>>> + qup_uart12_tx: qup-uart12-tx-state {
>>> + pins = "gpio50";
>>> + function = "qup14";
>>> + };
>>>
>>> I understand and support the intention to keep this change non-functional,
>>> but this pad "gpio50" is for qup16 also, right?
>>
>> According to my QCM6490 data sheet, GPIO_50 has these functions:
>> * UART for qup14 (OK)
>> * SPI for qup14 (OK)
>> * SPI for qup16 (no pinctrl)
>
> "no pinctrl" meaning "not defined in the upstream dt as of today"?
Correct.
>>> Similarly pads "gpio54"/"gpio55" for qup14 function, "gpio62"/"gpio63"
>>> for qup16 function, I find all of these are missing on the original list.
>>
>> GPIO_54:
>> * UART qup15 (OK)
>> * SPI qup15 (OK)
>> * SPI qup14 (no pinctrl)
>>
>> GPIO_55:
>> * UART qup15 (OK)
>> * SPI qup15 (OK)
>> * SPI qup14 (no pinctrl)
>>
>> GPIO_62:
>> * UART qup17 (OK)
>> * SPI qup17 (OK)
>> * SPI qup16 (no pinctrl)
>>
>> GPIO_63:
>> * UART qup16 (?)
>> * SPI qup16 (lane 3) (?)
>> * SPI qup16 (lane 5) (?)
>>
>> But the GPIO_63 looks weird, is the data sheet wrong?! Where would
>> UART_RX of QUP1 SE7 go? Maybe it should be UART qup17 and SPI qup17 and
>> then SPI qup16 ??
>
> GPIO63:
>
> QUP1_SE6 SPI_CS2
> QUP1_SE7 UART_RX/SPI_CS0
That matches pinctrl driver and kodiak.dtsi at least. Still, the data
sheet is just wrong there. If you have any contact to relevant people
there, please let them know!
Regards
Luca
^ permalink raw reply
* [PATCH v2 7/7] arm64: tegra: Add Host1x and VIC on Tegra264
From: Mikko Perttunen @ 2026-06-22 6:57 UTC (permalink / raw)
To: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-tegra, dri-devel, devicetree, linux-kernel, Mikko Perttunen
In-Reply-To: <20260622-t264-host1x-v2-0-ff7364d9ff7b@nvidia.com>
Tegra264 has a host1x instance with a VIC (video image compositor).
Other multimedia engines have moved outside host1x. Stream IDs are
now namespaced by device rather than being defined globally --
however, the only engine we have using context isolation is VIC so
we only define VIC's range of context devices.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra264.dtsi | 63 ++++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra264.dtsi b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
index 06d8357bdf52..fc398975a830 100644
--- a/arch/arm64/boot/dts/nvidia/tegra264.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
@@ -3807,6 +3807,69 @@ its: msi-controller@40000 {
};
};
+ /* VISION MMIO */
+ bus@8180000000 {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ranges = <0x000 0x00000000 0x81 0x80000000 0x00 0x10000000>, /* MMIO (256 MiB) */
+ <0x100 0x00000000 0x00 0x20000000 0x00 0x40000000>, /* non-prefetchable memory (32-bit) */
+ <0x200 0x00000000 0xa8 0x80000000 0x57 0x80000000>; /* I/O, ECAM, prefetchable memory (64-bit) */
+
+ host1x@1200000 {
+ compatible = "nvidia,tegra264-host1x";
+ reg = <0x0 0x1200000 0x0 0x10000>,
+ <0x0 0x1210000 0x0 0x10000>,
+ <0x0 0x1240000 0x0 0x10000>;
+ reg-names = "common", "hypervisor", "vm";
+ interrupts = <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "syncpt0", "syncpt1", "syncpt2", "syncpt3", "syncpt4",
+ "syncpt5", "syncpt6", "syncpt7", "host1x";
+ clocks = <&bpmp TEGRA264_CLK_HOST1X>;
+ clock-names = "host1x";
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ranges = <0x000 0x00000000 0x00 0x08000000 0x00 0x01000000>,
+ <0x000 0x02800000 0x00 0x0a800000 0x00 0x00800000>;
+
+ interconnects = <&mc TEGRA264_MEMORY_CLIENT_HOST1XR &emc>;
+ interconnect-names = "dma-mem";
+ iommus = <&smmu1 TEGRA264_SID_HOST1X>;
+ dma-coherent;
+
+ /* Context isolation domains */
+ iommu-map = <0 &smmu1 (TEGRA264_SID_VIC + 1) 16>;
+
+ vic@50000 {
+ compatible = "nvidia,tegra264-vic";
+ reg = <0x0 0x50000 0x0 0x40000>;
+ interrupts = <GIC_SPI 468 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&bpmp TEGRA264_CLK_VIC>;
+ clock-names = "vic";
+ resets = <&bpmp TEGRA264_RESET_VIC>;
+ reset-names = "vic";
+ power-domains = <&bpmp TEGRA264_POWER_DOMAIN_VIC>;
+ interconnects = <&mc TEGRA264_MEMORY_CLIENT_VICR &emc>,
+ <&mc TEGRA264_MEMORY_CLIENT_VICW &emc>;
+ interconnect-names = "dma-mem", "write";
+
+ iommus = <&smmu1 TEGRA264_SID_VIC>;
+ dma-coherent;
+ };
+ };
+ };
+
/* DISP_USB MMIO */
bus@8800000000 {
compatible = "simple-bus";
--
2.53.0
^ permalink raw reply related
* [PATCH v2 6/7] drm/tegra: vic: Add Tegra264 support
From: Mikko Perttunen @ 2026-06-22 6:57 UTC (permalink / raw)
To: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-tegra, dri-devel, devicetree, linux-kernel, Mikko Perttunen
In-Reply-To: <20260622-t264-host1x-v2-0-ff7364d9ff7b@nvidia.com>
Add support for VIC on Tegra264. The Tegra264 VIC uses a RISC-V based
Falcon microcontroller instead of the traditional Falcon previously,
and has the TRANSCFG register in a different place.
The .version field is set to 0x264 rather than 0x26 to allow
distinguishing between different VIC capabilities between minor version
variations of some chips.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
drivers/gpu/drm/tegra/drm.c | 1 +
drivers/gpu/drm/tegra/vic.c | 95 +++++++++++++++++++++++++++++++++------------
drivers/gpu/drm/tegra/vic.h | 9 ++---
3 files changed, 76 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 1dcef4e7d104..28245bf5ba5f 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1396,6 +1396,7 @@ static const struct of_device_id host1x_drm_subdevs[] = {
{ .compatible = "nvidia,tegra194-nvdec", },
{ .compatible = "nvidia,tegra234-vic", },
{ .compatible = "nvidia,tegra234-nvdec", },
+ { .compatible = "nvidia,tegra264-vic", },
{ /* sentinel */ }
};
diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
index 332c9b563d3f..46c7e00de347 100644
--- a/drivers/gpu/drm/tegra/vic.c
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -8,6 +8,7 @@
#include <linux/dma-mapping.h>
#include <linux/host1x.h>
#include <linux/iommu.h>
+#include <linux/iopoll.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/platform_device.h>
@@ -20,10 +21,16 @@
#include "falcon.h"
#include "vic.h"
+#define VIC_FALCON_DEBUGINFO 0x1094
+#define VIC_DEBUGINFO_DUMMY 0xabcd1234
+#define VIC_DEBUGINFO_CLEAR 0x0
+
struct vic_config {
const char *firmware;
unsigned int version;
bool supports_sid;
+ bool has_riscv;
+ unsigned int transcfg_offset;
};
struct vic {
@@ -54,8 +61,8 @@ static void vic_writel(struct vic *vic, u32 value, unsigned int offset)
static int vic_boot(struct vic *vic)
{
- u32 fce_ucode_size, fce_bin_data_offset, stream_id;
- void *hdr;
+ u32 stream_id;
+ u32 val;
int err = 0;
if (vic->config->supports_sid && tegra_dev_iommu_get_stream_id(vic->dev, &stream_id)) {
@@ -63,7 +70,7 @@ static int vic_boot(struct vic *vic)
value = TRANSCFG_ATT(1, TRANSCFG_SID_FALCON) |
TRANSCFG_ATT(0, TRANSCFG_SID_HW);
- vic_writel(vic, value, VIC_TFBIF_TRANSCFG);
+ vic_writel(vic, value, vic->config->transcfg_offset);
/*
* STREAMID0 is used for input/output buffers. Initialize it to SID_VIC in case
@@ -85,31 +92,50 @@ static int vic_boot(struct vic *vic)
CG_WAKEUP_DLY_CNT(4),
NV_PVIC_MISC_PRI_VIC_CG);
+ if (vic->config->has_riscv) {
+ /* Write a known pattern into DEBUGINFO register */
+ vic_writel(vic, VIC_DEBUGINFO_DUMMY, VIC_FALCON_DEBUGINFO);
+ }
+
err = falcon_boot(&vic->falcon);
if (err < 0)
return err;
- hdr = vic->falcon.firmware.virt;
- fce_bin_data_offset = *(u32 *)(hdr + VIC_UCODE_FCE_DATA_OFFSET);
-
- /* Old VIC firmware needs kernel help with setting up FCE microcode. */
- if (fce_bin_data_offset != 0x0 && fce_bin_data_offset != 0xa5a5a5a5) {
- hdr = vic->falcon.firmware.virt +
- *(u32 *)(hdr + VIC_UCODE_FCE_HEADER_OFFSET);
- fce_ucode_size = *(u32 *)(hdr + FCE_UCODE_SIZE_OFFSET);
-
- falcon_execute_method(&vic->falcon, VIC_SET_FCE_UCODE_SIZE,
- fce_ucode_size);
- falcon_execute_method(
- &vic->falcon, VIC_SET_FCE_UCODE_OFFSET,
- (vic->falcon.firmware.iova + fce_bin_data_offset) >> 8);
- }
+ if (vic->config->has_riscv) {
+ /* Check VIC has reached a proper initialized state */
+ err = readl_poll_timeout(vic->regs + VIC_FALCON_DEBUGINFO, val,
+ val == VIC_DEBUGINFO_CLEAR,
+ 1000, 2000000);
+ if (err) {
+ dev_err(vic->dev, "VIC not initialized, timeout, val=0x%x\n", val);
+ return err;
+ }
+ } else {
+ u32 fce_ucode_size, fce_bin_data_offset;
+ void *hdr;
+
+ hdr = vic->falcon.firmware.virt;
+ fce_bin_data_offset = *(u32 *)(hdr + VIC_UCODE_FCE_DATA_OFFSET);
+
+ /* Old VIC firmware needs kernel help with setting up FCE microcode. */
+ if (fce_bin_data_offset != 0x0 && fce_bin_data_offset != 0xa5a5a5a5) {
+ hdr = vic->falcon.firmware.virt +
+ *(u32 *)(hdr + VIC_UCODE_FCE_HEADER_OFFSET);
+ fce_ucode_size = *(u32 *)(hdr + FCE_UCODE_SIZE_OFFSET);
+
+ falcon_execute_method(&vic->falcon, VIC_SET_FCE_UCODE_SIZE,
+ fce_ucode_size);
+ falcon_execute_method(
+ &vic->falcon, VIC_SET_FCE_UCODE_OFFSET,
+ (vic->falcon.firmware.iova + fce_bin_data_offset) >> 8);
+ }
- err = falcon_wait_idle(&vic->falcon);
- if (err < 0) {
- dev_err(vic->dev,
- "failed to set application ID and FCE base\n");
- return err;
+ err = falcon_wait_idle(&vic->falcon);
+ if (err < 0) {
+ dev_err(vic->dev,
+ "failed to set application ID and FCE base\n");
+ return err;
+ }
}
return 0;
@@ -277,6 +303,8 @@ static int vic_load_firmware(struct vic *vic)
if (!vic->config->supports_sid) {
vic->can_use_context = false;
+ } else if (vic->config->has_riscv) {
+ vic->can_use_context = true;
} else if (fce_bin_data_offset != 0x0 && fce_bin_data_offset != 0xa5a5a5a5) {
/*
* Firmware will access FCE through STREAMID0, so context
@@ -302,7 +330,6 @@ static int vic_load_firmware(struct vic *vic)
return err;
}
-
static int __maybe_unused vic_runtime_resume(struct device *dev)
{
struct vic *vic = dev_get_drvdata(dev);
@@ -417,6 +444,7 @@ static const struct vic_config vic_t186_config = {
.firmware = NVIDIA_TEGRA_186_VIC_FIRMWARE,
.version = 0x18,
.supports_sid = true,
+ .transcfg_offset = 0x2044,
};
#define NVIDIA_TEGRA_194_VIC_FIRMWARE "nvidia/tegra194/vic.bin"
@@ -425,6 +453,7 @@ static const struct vic_config vic_t194_config = {
.firmware = NVIDIA_TEGRA_194_VIC_FIRMWARE,
.version = 0x19,
.supports_sid = true,
+ .transcfg_offset = 0x2044,
};
#define NVIDIA_TEGRA_234_VIC_FIRMWARE "nvidia/tegra234/vic.bin"
@@ -433,6 +462,18 @@ static const struct vic_config vic_t234_config = {
.firmware = NVIDIA_TEGRA_234_VIC_FIRMWARE,
.version = 0x23,
.supports_sid = true,
+ .transcfg_offset = 0x2044,
+};
+
+#define NVIDIA_TEGRA_264_VIC_FIRMWARE "nvidia/tegra264/vic.bin"
+#define NVIDIA_TEGRA_264_VIC_DESC "nvidia/tegra264/vic.bin.desc"
+
+static const struct vic_config vic_t264_config = {
+ .firmware = NVIDIA_TEGRA_264_VIC_FIRMWARE,
+ .version = 0x264,
+ .supports_sid = true,
+ .has_riscv = true,
+ .transcfg_offset = 0x2244,
};
static const struct of_device_id tegra_vic_of_match[] = {
@@ -441,6 +482,7 @@ static const struct of_device_id tegra_vic_of_match[] = {
{ .compatible = "nvidia,tegra186-vic", .data = &vic_t186_config },
{ .compatible = "nvidia,tegra194-vic", .data = &vic_t194_config },
{ .compatible = "nvidia,tegra234-vic", .data = &vic_t234_config },
+ { .compatible = "nvidia,tegra264-vic", .data = &vic_t264_config },
{ },
};
MODULE_DEVICE_TABLE(of, tegra_vic_of_match);
@@ -495,6 +537,7 @@ static int vic_probe(struct platform_device *pdev)
vic->falcon.dev = dev;
vic->falcon.regs = vic->regs;
+ vic->falcon.riscv = vic->config->has_riscv;
err = falcon_init(&vic->falcon);
if (err < 0)
@@ -571,3 +614,7 @@ MODULE_FIRMWARE(NVIDIA_TEGRA_194_VIC_FIRMWARE);
#if IS_ENABLED(CONFIG_ARCH_TEGRA_234_SOC)
MODULE_FIRMWARE(NVIDIA_TEGRA_234_VIC_FIRMWARE);
#endif
+#if IS_ENABLED(CONFIG_ARCH_TEGRA_264_SOC)
+MODULE_FIRMWARE(NVIDIA_TEGRA_264_VIC_FIRMWARE);
+MODULE_FIRMWARE(NVIDIA_TEGRA_264_VIC_DESC);
+#endif
diff --git a/drivers/gpu/drm/tegra/vic.h b/drivers/gpu/drm/tegra/vic.h
index acf35aac948b..e525a06daaba 100644
--- a/drivers/gpu/drm/tegra/vic.h
+++ b/drivers/gpu/drm/tegra/vic.h
@@ -21,11 +21,10 @@
#define CG_IDLE_CG_EN (1 << 6)
#define CG_WAKEUP_DLY_CNT(val) ((val & 0xf) << 16)
-#define VIC_TFBIF_TRANSCFG 0x00002044
-#define TRANSCFG_ATT(i, v) (((v) & 0x3) << (i * 4))
-#define TRANSCFG_SID_HW 0
-#define TRANSCFG_SID_PHY 1
-#define TRANSCFG_SID_FALCON 2
+#define TRANSCFG_ATT(i, v) (((v) & 0x3) << (i * 4))
+#define TRANSCFG_SID_HW 0
+#define TRANSCFG_SID_PHY 1
+#define TRANSCFG_SID_FALCON 2
/* Firmware offsets */
--
2.53.0
^ permalink raw reply related
* [PATCH v2 5/7] drm/tegra: falcon: Add support for RISC-V external boot
From: Mikko Perttunen @ 2026-06-22 6:57 UTC (permalink / raw)
To: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-tegra, dri-devel, devicetree, linux-kernel, Mikko Perttunen
In-Reply-To: <20260622-t264-host1x-v2-0-ff7364d9ff7b@nvidia.com>
Add support for loading and booting RISC-V firmwares on Falcons with
RISC-V hardware. The flow is mostly the same as for traditional
Falcons, with a few different registers and different firmware layout.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
drivers/gpu/drm/tegra/falcon.c | 66 +++++++++++++++++++++++++++++++++++-------
drivers/gpu/drm/tegra/falcon.h | 23 +++++++++++++++
2 files changed, 79 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/tegra/falcon.c b/drivers/gpu/drm/tegra/falcon.c
index 17f616bbcb45..1172356b6af3 100644
--- a/drivers/gpu/drm/tegra/falcon.c
+++ b/drivers/gpu/drm/tegra/falcon.c
@@ -26,8 +26,12 @@ int falcon_wait_idle(struct falcon *falcon)
{
u32 value;
- return readl_poll_timeout(falcon->regs + FALCON_IDLESTATE, value,
- (value == 0), 10, 100000);
+ if (falcon->riscv)
+ return readl_poll_timeout(falcon->regs + RISCV_CPUCTL, value,
+ (value & RISCV_CPUCTL_ACTIVE_STAT_ACTIVE), 10, 100000);
+ else
+ return readl_poll_timeout(falcon->regs + FALCON_IDLESTATE, value,
+ (value == 0), 10, 100000);
}
static int falcon_dma_wait_not_full(struct falcon *falcon)
@@ -122,6 +126,17 @@ static int falcon_parse_firmware_image(struct falcon *falcon)
return 0;
}
+static void falcon_parse_firmware_desc(struct falcon *falcon)
+{
+ struct falcon_fw_riscv_desc *desc =
+ (struct falcon_fw_riscv_desc *)falcon->firmware.desc_firmware->data;
+
+ falcon->firmware.code.offset = desc->code_offset;
+ falcon->firmware.code.size = desc->code_size;
+ falcon->firmware.data.offset = desc->data_offset;
+ falcon->firmware.data.size = desc->data_size;
+}
+
int falcon_read_firmware(struct falcon *falcon, const char *name)
{
int err;
@@ -133,7 +148,23 @@ int falcon_read_firmware(struct falcon *falcon, const char *name)
falcon->firmware.size = falcon->firmware.firmware->size;
+ if (falcon->riscv) {
+ /* Load separate descriptor */
+ char desc_name[128];
+
+ scnprintf(desc_name, sizeof(desc_name), "%s.desc", name);
+ err = request_firmware(&falcon->firmware.desc_firmware, desc_name, falcon->dev);
+ if (err < 0)
+ goto release_firmware;
+ }
+
return 0;
+
+release_firmware:
+ release_firmware(falcon->firmware.firmware);
+ falcon->firmware.firmware = NULL;
+
+ return err;
}
int falcon_load_firmware(struct falcon *falcon)
@@ -144,16 +175,22 @@ int falcon_load_firmware(struct falcon *falcon)
/* copy firmware image into local area. this also ensures endianness */
falcon_copy_firmware_image(falcon, firmware);
- /* parse the image data */
- err = falcon_parse_firmware_image(falcon);
- if (err < 0) {
- dev_err(falcon->dev, "failed to parse firmware image\n");
- return err;
+ if (falcon->riscv) {
+ falcon_parse_firmware_desc(falcon);
+ } else {
+ err = falcon_parse_firmware_image(falcon);
+ if (err < 0) {
+ dev_err(falcon->dev, "failed to parse firmware image\n");
+ return err;
+ }
}
release_firmware(firmware);
falcon->firmware.firmware = NULL;
+ release_firmware(falcon->firmware.desc_firmware);
+ falcon->firmware.desc_firmware = NULL;
+
return 0;
}
@@ -168,6 +205,9 @@ void falcon_exit(struct falcon *falcon)
{
if (falcon->firmware.firmware)
release_firmware(falcon->firmware.firmware);
+
+ if (falcon->firmware.desc_firmware)
+ release_firmware(falcon->firmware.desc_firmware);
}
int falcon_boot(struct falcon *falcon)
@@ -229,9 +269,15 @@ int falcon_boot(struct falcon *falcon)
FALCON_ITFEN_CTXEN,
FALCON_ITFEN);
- /* boot falcon */
- falcon_writel(falcon, 0x00000000, FALCON_BOOTVEC);
- falcon_writel(falcon, FALCON_CPUCTL_STARTCPU, FALCON_CPUCTL);
+ if (falcon->riscv) {
+ falcon_writel(falcon, RISCV_BCR_CTRL_CORE_SELECT_RISCV, RISCV_BCR_CTRL);
+ falcon_writel(falcon, 0x0, RISCV_BOOT_VECTOR_HI);
+ falcon_writel(falcon, 0x100000, RISCV_BOOT_VECTOR_LO);
+ falcon_writel(falcon, RISCV_CPUCTL_STARTCPU, RISCV_CPUCTL);
+ } else {
+ falcon_writel(falcon, 0x00000000, FALCON_BOOTVEC);
+ falcon_writel(falcon, FALCON_CPUCTL_STARTCPU, FALCON_CPUCTL);
+ }
err = falcon_wait_idle(falcon);
if (err < 0) {
diff --git a/drivers/gpu/drm/tegra/falcon.h b/drivers/gpu/drm/tegra/falcon.h
index 902bb7e4fd0f..37a17c6136b3 100644
--- a/drivers/gpu/drm/tegra/falcon.h
+++ b/drivers/gpu/drm/tegra/falcon.h
@@ -55,6 +55,16 @@
#define FALCON_DMATRFFBOFFS 0x0000111c
+#define RISCV_BOOT_VECTOR_LO 0x00001780
+#define RISCV_BOOT_VECTOR_HI 0x00001784
+
+#define RISCV_CPUCTL 0x00001788
+#define RISCV_CPUCTL_STARTCPU (1 << 0)
+#define RISCV_CPUCTL_ACTIVE_STAT_ACTIVE (1 << 7)
+
+#define RISCV_BCR_CTRL 0x00001a68
+#define RISCV_BCR_CTRL_CORE_SELECT_RISCV (1 << 4)
+
struct falcon_fw_bin_header_v1 {
u32 magic; /* 0x10de */
u32 version; /* version of bin format (1) */
@@ -76,6 +86,14 @@ struct falcon_fw_os_header_v1 {
u32 data_size;
};
+struct falcon_fw_riscv_desc {
+ u32 reserved[74];
+ u32 data_offset;
+ u32 data_size;
+ u32 code_offset;
+ u32 code_size;
+};
+
struct falcon_firmware_section {
unsigned long offset;
size_t size;
@@ -84,6 +102,8 @@ struct falcon_firmware_section {
struct falcon_firmware {
/* Firmware after it is read but not loaded */
const struct firmware *firmware;
+ /* RISC-V firmware descriptor */
+ const struct firmware *desc_firmware;
/* Raw firmware data */
dma_addr_t iova;
@@ -102,6 +122,9 @@ struct falcon {
struct device *dev;
void __iomem *regs;
+ /* Peregrine falcon, external boot */
+ bool riscv;
+
struct falcon_firmware firmware;
};
--
2.53.0
^ permalink raw reply related
* [PATCH v2 4/7] gpu: host1x: Add Tegra264 support
From: Mikko Perttunen @ 2026-06-22 6:57 UTC (permalink / raw)
To: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-tegra, dri-devel, devicetree, linux-kernel, Santosh BS,
Mikko Perttunen
In-Reply-To: <20260622-t264-host1x-v2-0-ff7364d9ff7b@nvidia.com>
From: Santosh BS <santoshb@nvidia.com>
Add device data and chip headers for Tegra264.
Signed-off-by: Santosh BS <santoshb@nvidia.com>
Co-developed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
drivers/gpu/host1x/Makefile | 3 +-
drivers/gpu/host1x/dev.c | 41 ++++++
drivers/gpu/host1x/hw/cdma_hw.c | 12 +-
drivers/gpu/host1x/hw/host1x10.c | 33 +++++
drivers/gpu/host1x/hw/host1x10.h | 15 ++
drivers/gpu/host1x/hw/host1x10_hardware.h | 21 +++
drivers/gpu/host1x/hw/hw_host1x10_common.h | 6 +
drivers/gpu/host1x/hw/hw_host1x10_hypervisor.h | 10 ++
drivers/gpu/host1x/hw/hw_host1x10_uclass.h | 181 +++++++++++++++++++++++++
drivers/gpu/host1x/hw/hw_host1x10_vm.h | 36 +++++
10 files changed, 352 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index fead483af0b4..b684fbf73841 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -17,7 +17,8 @@ host1x-y = \
hw/host1x05.o \
hw/host1x06.o \
hw/host1x07.o \
- hw/host1x08.o
+ hw/host1x08.o \
+ hw/host1x10.o
host1x-$(CONFIG_IOMMU_API) += \
context.o
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 3f475f0e6545..d2c64728f804 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -41,6 +41,7 @@
#include "hw/host1x06.h"
#include "hw/host1x07.h"
#include "hw/host1x08.h"
+#include "hw/host1x10.h"
void host1x_common_writel(struct host1x *host1x, u32 v, u32 r)
{
@@ -287,7 +288,47 @@ static const struct host1x_info host1x08_info = {
.reserve_vblank_syncpts = false,
};
+static const struct host1x_sid_entry tegra264_sid_table[] = {
+ { /* SE1 MMIO */ .base = 0x1650, .offset = 0x90, .limit = 0x90 },
+ { /* SE2 MMIO */ .base = 0x1658, .offset = 0x90, .limit = 0x90 },
+ { /* SE4 MMIO */ .base = 0x1660, .offset = 0x90, .limit = 0x90 },
+ { /* SE1 ch */ .base = 0x1738, .offset = 0x90, .limit = 0x90 },
+ { /* SE2 ch */ .base = 0x1740, .offset = 0x90, .limit = 0x90 },
+ { /* SE4 ch */ .base = 0x1748, .offset = 0x90, .limit = 0x90 },
+ { /* VIC ch */ .base = 0x1790, .offset = 0x30, .limit = 0x30 },
+ { /* VIC MMIO */ .base = 0x1688, .offset = 0x34, .limit = 0x34 },
+ { /* TSEC MMIO */ .base = 0x1690, .offset = 0x30, .limit = 0x34 },
+ { /* VI MMIO */ .base = 0x1698, .offset = 0x800, .limit = 0x800 },
+ { /* VI_THI MMIO */ .base = 0x16a0, .offset = 0x30, .limit = 0x34 },
+ { /* ISP MMIO */ .base = 0x1680, .offset = 0x800, .limit = 0x800 },
+ { /* ISP_THI MMIO */ .base = 0x16a8, .offset = 0x30, .limit = 0x34 },
+ { /* VI2 MMIO */ .base = 0x16b8, .offset = 0x800, .limit = 0x800 },
+ { /* VI2_THI MMIO */ .base = 0x16c0, .offset = 0x30, .limit = 0x34 },
+ { /* ISP1 MMIO */ .base = 0x16c8, .offset = 0x800, .limit = 0x800 },
+ { /* ISP1_THI MMIO */ .base = 0x16d0, .offset = 0x30, .limit = 0x34 },
+};
+
+static const struct host1x_info host1x10_info = {
+ .nb_channels = 63,
+ .nb_pts = 1024,
+ .nb_mlocks = 24,
+ .nb_bases = 0,
+ .init = host1x10_init,
+ .sync_offset = 0x0,
+ .dma_mask = DMA_BIT_MASK(40),
+ .has_wide_gather = true,
+ .has_hypervisor = true,
+ .has_common = true,
+ .num_sid_entries = ARRAY_SIZE(tegra264_sid_table),
+ .sid_table = tegra264_sid_table,
+ .streamid_vm_table = { 0x1004, 128 },
+ .classid_vm_table = { 0x1404, 25 },
+ .mmio_vm_table = { 0x1504, 25 },
+ .reserve_vblank_syncpts = false,
+};
+
static const struct of_device_id host1x_of_match[] = {
+ { .compatible = "nvidia,tegra264-host1x", .data = &host1x10_info, },
{ .compatible = "nvidia,tegra234-host1x", .data = &host1x08_info, },
{ .compatible = "nvidia,tegra194-host1x", .data = &host1x07_info, },
{ .compatible = "nvidia,tegra186-host1x", .data = &host1x06_info, },
diff --git a/drivers/gpu/host1x/hw/cdma_hw.c b/drivers/gpu/host1x/hw/cdma_hw.c
index 3f3f0018eee0..e43a9cf20c27 100644
--- a/drivers/gpu/host1x/hw/cdma_hw.c
+++ b/drivers/gpu/host1x/hw/cdma_hw.c
@@ -246,23 +246,24 @@ static void timeout_release_mlock(struct host1x_cdma *cdma)
* so it turns out that if we don't /actually/ need MLOCKs, we can just
* ignore them.
*
- * As such, for now just implement this on Tegra234 where things are
- * stricter but also easy to implement.
+ * As such, for now just implement this on Tegra234 and above where things
+ * are stricter but also easy to implement.
*/
struct host1x_channel *ch = cdma_to_channel(cdma);
struct host1x *host1x = cdma_to_host1x(cdma);
u32 offset;
switch (ch->client->class) {
+ case HOST1X_CLASS_VIC:
+ offset = HOST1X_COMMON_VIC_MLOCK;
+ break;
+#if HOST1X_HW == 8
case HOST1X_CLASS_NVJPG1:
offset = HOST1X_COMMON_NVJPG1_MLOCK;
break;
case HOST1X_CLASS_NVENC:
offset = HOST1X_COMMON_NVENC_MLOCK;
break;
- case HOST1X_CLASS_VIC:
- offset = HOST1X_COMMON_VIC_MLOCK;
- break;
case HOST1X_CLASS_NVJPG:
offset = HOST1X_COMMON_NVJPG_MLOCK;
break;
@@ -272,6 +273,7 @@ static void timeout_release_mlock(struct host1x_cdma *cdma)
case HOST1X_CLASS_OFA:
offset = HOST1X_COMMON_OFA_MLOCK;
break;
+#endif
default:
WARN(1, "%s was not updated for class %u", __func__, ch->client->class);
return;
diff --git a/drivers/gpu/host1x/hw/host1x10.c b/drivers/gpu/host1x/hw/host1x10.c
new file mode 100644
index 000000000000..2800f309bf6f
--- /dev/null
+++ b/drivers/gpu/host1x/hw/host1x10.c
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Host1x init for Tegra264 SoCs
+ *
+ * Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+ */
+
+/* include hw specification */
+#include "host1x10.h"
+#include "host1x10_hardware.h"
+
+/* include code */
+#define HOST1X_HW 10
+
+#include "cdma_hw.c"
+#include "channel_hw.c"
+#include "debug_hw.c"
+#include "intr_hw.c"
+#include "syncpt_hw.c"
+
+#include "../dev.h"
+
+int host1x10_init(struct host1x *host)
+{
+ host->channel_op = &host1x_channel_ops;
+ host->cdma_op = &host1x_cdma_ops;
+ host->cdma_pb_op = &host1x_pushbuffer_ops;
+ host->syncpt_op = &host1x_syncpt_ops;
+ host->intr_op = &host1x_intr_ops;
+ host->debug_op = &host1x_debug_ops;
+
+ return 0;
+}
diff --git a/drivers/gpu/host1x/hw/host1x10.h b/drivers/gpu/host1x/hw/host1x10.h
new file mode 100644
index 000000000000..577f6ff3dff5
--- /dev/null
+++ b/drivers/gpu/host1x/hw/host1x10.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Host1x init for Tegra264 SoCs
+ *
+ * Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+ */
+
+#ifndef HOST1X_HOST1X10_H
+#define HOST1X_HOST1X10_H
+
+struct host1x;
+
+int host1x10_init(struct host1x *host);
+
+#endif
diff --git a/drivers/gpu/host1x/hw/host1x10_hardware.h b/drivers/gpu/host1x/hw/host1x10_hardware.h
new file mode 100644
index 000000000000..abbead8190b1
--- /dev/null
+++ b/drivers/gpu/host1x/hw/host1x10_hardware.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Tegra host1x Register Offsets for Tegra264
+ *
+ * Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+ */
+
+#ifndef __HOST1X_HOST1X10_HARDWARE_H
+#define __HOST1X_HOST1X10_HARDWARE_H
+
+#include <linux/types.h>
+#include <linux/bitops.h>
+
+#include "hw_host1x10_uclass.h"
+#include "hw_host1x10_vm.h"
+#include "hw_host1x10_hypervisor.h"
+#include "hw_host1x10_common.h"
+
+#include "opcodes.h"
+
+#endif
diff --git a/drivers/gpu/host1x/hw/hw_host1x10_common.h b/drivers/gpu/host1x/hw/hw_host1x10_common.h
new file mode 100644
index 000000000000..48a632672a47
--- /dev/null
+++ b/drivers/gpu/host1x/hw/hw_host1x10_common.h
@@ -0,0 +1,6 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+ */
+
+#define HOST1X_COMMON_VIC_MLOCK 0x4060
diff --git a/drivers/gpu/host1x/hw/hw_host1x10_hypervisor.h b/drivers/gpu/host1x/hw/hw_host1x10_hypervisor.h
new file mode 100644
index 000000000000..8c9069caffa8
--- /dev/null
+++ b/drivers/gpu/host1x/hw/hw_host1x10_hypervisor.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+ */
+
+#define HOST1X_HV_SYNCPT_PROT_EN 0x172c
+#define HOST1X_HV_SYNCPT_PROT_EN_CH_EN BIT(1)
+#define HOST1X_HV_CH_MLOCK_EN(x) (0x1708 + (x * 4))
+#define HOST1X_HV_CH_KERNEL_FILTER_GBUFFER(x) (0x1718 + (x * 4))
+#define HOST1X_HV_SYNCPT_VM(x) (0x0 + 4 * (x))
diff --git a/drivers/gpu/host1x/hw/hw_host1x10_uclass.h b/drivers/gpu/host1x/hw/hw_host1x10_uclass.h
new file mode 100644
index 000000000000..abe83e67fa83
--- /dev/null
+++ b/drivers/gpu/host1x/hw/hw_host1x10_uclass.h
@@ -0,0 +1,181 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+ */
+
+ /*
+ * Function naming determines intended use:
+ *
+ * <x>_r(void) : Returns the offset for register <x>.
+ *
+ * <x>_w(void) : Returns the word offset for word (4 byte) element <x>.
+ *
+ * <x>_<y>_s(void) : Returns size of field <y> of register <x> in bits.
+ *
+ * <x>_<y>_f(u32 v) : Returns a value based on 'v' which has been shifted
+ * and masked to place it at field <y> of register <x>. This value
+ * can be |'d with others to produce a full register value for
+ * register <x>.
+ *
+ * <x>_<y>_m(void) : Returns a mask for field <y> of register <x>. This
+ * value can be ~'d and then &'d to clear the value of field <y> for
+ * register <x>.
+ *
+ * <x>_<y>_<z>_f(void) : Returns the constant value <z> after being shifted
+ * to place it at field <y> of register <x>. This value can be |'d
+ * with others to produce a full register value for <x>.
+ *
+ * <x>_<y>_v(u32 r) : Returns the value of field <y> from a full register
+ * <x> value 'r' after being shifted to place its LSB at bit 0.
+ * This value is suitable for direct comparison with other unshifted
+ * values appropriate for use in field <y> of register <x>.
+ *
+ * <x>_<y>_<z>_v(void) : Returns the constant value for <z> defined for
+ * field <y> of register <x>. This value is suitable for direct
+ * comparison with unshifted values appropriate for use in field <y>
+ * of register <x>.
+ */
+
+#ifndef HOST1X_HW_HOST1X10_UCLASS_H
+#define HOST1X_HW_HOST1X10_UCLASS_H
+
+static inline u32 host1x_uclass_incr_syncpt_r(void)
+{
+ return 0x0;
+}
+#define HOST1X_UCLASS_INCR_SYNCPT \
+ host1x_uclass_incr_syncpt_r()
+static inline u32 host1x_uclass_incr_syncpt_cond_f(u32 v)
+{
+ return (v & 0xff) << 10;
+}
+#define HOST1X_UCLASS_INCR_SYNCPT_COND_F(v) \
+ host1x_uclass_incr_syncpt_cond_f(v)
+static inline u32 host1x_uclass_incr_syncpt_indx_f(u32 v)
+{
+ return (v & 0x3ff) << 0;
+}
+#define HOST1X_UCLASS_INCR_SYNCPT_INDX_F(v) \
+ host1x_uclass_incr_syncpt_indx_f(v)
+static inline u32 host1x_uclass_wait_syncpt_r(void)
+{
+ return 0x8;
+}
+#define HOST1X_UCLASS_WAIT_SYNCPT \
+ host1x_uclass_wait_syncpt_r()
+static inline u32 host1x_uclass_wait_syncpt_indx_f(u32 v)
+{
+ return (v & 0xff) << 24;
+}
+#define HOST1X_UCLASS_WAIT_SYNCPT_INDX_F(v) \
+ host1x_uclass_wait_syncpt_indx_f(v)
+static inline u32 host1x_uclass_wait_syncpt_thresh_f(u32 v)
+{
+ return (v & 0xffffff) << 0;
+}
+#define HOST1X_UCLASS_WAIT_SYNCPT_THRESH_F(v) \
+ host1x_uclass_wait_syncpt_thresh_f(v)
+static inline u32 host1x_uclass_wait_syncpt_base_r(void)
+{
+ return 0x9;
+}
+#define HOST1X_UCLASS_WAIT_SYNCPT_BASE \
+ host1x_uclass_wait_syncpt_base_r()
+static inline u32 host1x_uclass_wait_syncpt_base_indx_f(u32 v)
+{
+ return (v & 0xff) << 24;
+}
+#define HOST1X_UCLASS_WAIT_SYNCPT_BASE_INDX_F(v) \
+ host1x_uclass_wait_syncpt_base_indx_f(v)
+static inline u32 host1x_uclass_wait_syncpt_base_base_indx_f(u32 v)
+{
+ return (v & 0xff) << 16;
+}
+#define HOST1X_UCLASS_WAIT_SYNCPT_BASE_BASE_INDX_F(v) \
+ host1x_uclass_wait_syncpt_base_base_indx_f(v)
+static inline u32 host1x_uclass_wait_syncpt_base_offset_f(u32 v)
+{
+ return (v & 0xffff) << 0;
+}
+#define HOST1X_UCLASS_WAIT_SYNCPT_BASE_OFFSET_F(v) \
+ host1x_uclass_wait_syncpt_base_offset_f(v)
+static inline u32 host1x_uclass_load_syncpt_base_r(void)
+{
+ return 0xb;
+}
+#define HOST1X_UCLASS_LOAD_SYNCPT_BASE \
+ host1x_uclass_load_syncpt_base_r()
+static inline u32 host1x_uclass_load_syncpt_base_base_indx_f(u32 v)
+{
+ return (v & 0xff) << 24;
+}
+#define HOST1X_UCLASS_LOAD_SYNCPT_BASE_BASE_INDX_F(v) \
+ host1x_uclass_load_syncpt_base_base_indx_f(v)
+static inline u32 host1x_uclass_load_syncpt_base_value_f(u32 v)
+{
+ return (v & 0xffffff) << 0;
+}
+#define HOST1X_UCLASS_LOAD_SYNCPT_BASE_VALUE_F(v) \
+ host1x_uclass_load_syncpt_base_value_f(v)
+static inline u32 host1x_uclass_incr_syncpt_base_base_indx_f(u32 v)
+{
+ return (v & 0xff) << 24;
+}
+#define HOST1X_UCLASS_INCR_SYNCPT_BASE_BASE_INDX_F(v) \
+ host1x_uclass_incr_syncpt_base_base_indx_f(v)
+static inline u32 host1x_uclass_incr_syncpt_base_offset_f(u32 v)
+{
+ return (v & 0xffffff) << 0;
+}
+#define HOST1X_UCLASS_INCR_SYNCPT_BASE_OFFSET_F(v) \
+ host1x_uclass_incr_syncpt_base_offset_f(v)
+static inline u32 host1x_uclass_indoff_r(void)
+{
+ return 0x2d;
+}
+#define HOST1X_UCLASS_INDOFF \
+ host1x_uclass_indoff_r()
+static inline u32 host1x_uclass_indoff_indbe_f(u32 v)
+{
+ return (v & 0xf) << 28;
+}
+#define HOST1X_UCLASS_INDOFF_INDBE_F(v) \
+ host1x_uclass_indoff_indbe_f(v)
+static inline u32 host1x_uclass_indoff_autoinc_f(u32 v)
+{
+ return (v & 0x1) << 27;
+}
+#define HOST1X_UCLASS_INDOFF_AUTOINC_F(v) \
+ host1x_uclass_indoff_autoinc_f(v)
+static inline u32 host1x_uclass_indoff_indmodid_f(u32 v)
+{
+ return (v & 0xff) << 18;
+}
+#define HOST1X_UCLASS_INDOFF_INDMODID_F(v) \
+ host1x_uclass_indoff_indmodid_f(v)
+static inline u32 host1x_uclass_indoff_indroffset_f(u32 v)
+{
+ return (v & 0xffff) << 2;
+}
+#define HOST1X_UCLASS_INDOFF_INDROFFSET_F(v) \
+ host1x_uclass_indoff_indroffset_f(v)
+static inline u32 host1x_uclass_indoff_rwn_read_v(void)
+{
+ return 1;
+}
+#define HOST1X_UCLASS_INDOFF_INDROFFSET_F(v) \
+ host1x_uclass_indoff_indroffset_f(v)
+static inline u32 host1x_uclass_load_syncpt_payload_32_r(void)
+{
+ return 0x4e;
+}
+#define HOST1X_UCLASS_LOAD_SYNCPT_PAYLOAD_32 \
+ host1x_uclass_load_syncpt_payload_32_r()
+static inline u32 host1x_uclass_wait_syncpt_32_r(void)
+{
+ return 0x50;
+}
+#define HOST1X_UCLASS_WAIT_SYNCPT_32 \
+ host1x_uclass_wait_syncpt_32_r()
+
+#endif
diff --git a/drivers/gpu/host1x/hw/hw_host1x10_vm.h b/drivers/gpu/host1x/hw/hw_host1x10_vm.h
new file mode 100644
index 000000000000..75f5b881c561
--- /dev/null
+++ b/drivers/gpu/host1x/hw/hw_host1x10_vm.h
@@ -0,0 +1,36 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+ */
+
+#define HOST1X_CHANNEL_DMASTART 0x0000
+#define HOST1X_CHANNEL_DMASTART_HI 0x0004
+#define HOST1X_CHANNEL_DMAPUT 0x0008
+#define HOST1X_CHANNEL_DMAPUT_HI 0x000c
+#define HOST1X_CHANNEL_DMAGET 0x0010
+#define HOST1X_CHANNEL_DMAGET_HI 0x0014
+#define HOST1X_CHANNEL_DMAEND 0x0018
+#define HOST1X_CHANNEL_DMAEND_HI 0x001c
+#define HOST1X_CHANNEL_DMACTRL 0x0020
+#define HOST1X_CHANNEL_DMACTRL_DMASTOP BIT(0)
+#define HOST1X_CHANNEL_DMACTRL_DMAGETRST BIT(1)
+#define HOST1X_CHANNEL_DMACTRL_DMAINITGET BIT(2)
+#define HOST1X_CHANNEL_CMDFIFO_STAT 0x0024
+#define HOST1X_CHANNEL_CMDFIFO_STAT_EMPTY BIT(13)
+#define HOST1X_CHANNEL_CMDFIFO_RDATA 0x0028
+#define HOST1X_CHANNEL_CMDP_OFFSET 0x0030
+#define HOST1X_CHANNEL_CMDP_CLASS 0x0034
+#define HOST1X_CHANNEL_CHANNELSTAT 0x0038
+#define HOST1X_CHANNEL_CMDPROC_STOP 0x0048
+#define HOST1X_CHANNEL_TEARDOWN 0x004c
+#define HOST1X_CHANNEL_SMMU_STREAMID 0x0084
+
+#define HOST1X_SYNC_SYNCPT_CPU_INCR(x) (0x6400 + 4 * (x))
+#define HOST1X_SYNC_SYNCPT_THRESH_CPU0_INT_STATUS(x) (0x6600 + 4 * (x))
+#define HOST1X_SYNC_SYNCPT_INTR_DEST(x) (0x6684 + 4 * (x))
+#define HOST1X_SYNC_SYNCPT_THRESH_INT_ENABLE_CPU0(x) (0x770c + 4 * (x))
+#define HOST1X_SYNC_SYNCPT_THRESH_INT_DISABLE(x) (0x7790 + 4 * (x))
+#define HOST1X_SYNC_SYNCPT(x) (0x8080 + 4 * (x))
+#define HOST1X_SYNC_SYNCPT_INT_THRESH(x) (0xa088 + 4 * (x))
+#define HOST1X_SYNC_SYNCPT_CH_APP(x) (0xb090 + 4 * (x))
+#define HOST1X_SYNC_SYNCPT_CH_APP_CH(v) (((v) & 0x3f) << 8)
--
2.53.0
^ permalink raw reply related
* [PATCH v2 3/7] gpu: host1x: Correctly parse linear ranges of context devices
From: Mikko Perttunen @ 2026-06-22 6:57 UTC (permalink / raw)
To: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-tegra, dri-devel, devicetree, linux-kernel, Mikko Perttunen
In-Reply-To: <20260622-t264-host1x-v2-0-ff7364d9ff7b@nvidia.com>
The previous parsing of the iommu-map property assumed each context
device has its own one-length entry in the device tree. This has worked
fine so far, but on Tegra264 larger numbers of context devices are
usable, so it's better to support linear ranges as well.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
drivers/gpu/host1x/context.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/host1x/context.c b/drivers/gpu/host1x/context.c
index d50d41c20561..52ca663902ad 100644
--- a/drivers/gpu/host1x/context.c
+++ b/drivers/gpu/host1x/context.c
@@ -23,7 +23,7 @@ int host1x_memory_context_list_init(struct host1x *host1x)
struct host1x_memory_context_list *cdl = &host1x->context_list;
struct device_node *node = host1x->dev->of_node;
struct host1x_memory_context *ctx;
- unsigned int i;
+ unsigned int devs, i;
int err;
cdl->devs = NULL;
@@ -34,7 +34,16 @@ int host1x_memory_context_list_init(struct host1x *host1x)
if (err < 0)
return 0;
- cdl->len = err / 4;
+ devs = 0;
+
+ for (i = 0; i < err / 4; i++) {
+ u32 length;
+
+ of_property_read_u32_index(node, "iommu-map", i * 4 + 3, &length);
+ devs += length;
+ }
+
+ cdl->len = devs;
cdl->devs = kzalloc_objs(*cdl->devs, cdl->len);
if (!cdl->devs)
return -ENOMEM;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 2/7] dt-bindings: display: tegra: Add Tegra264 compatible for VIC
From: Mikko Perttunen @ 2026-06-22 6:57 UTC (permalink / raw)
To: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-tegra, dri-devel, devicetree, linux-kernel, Conor Dooley,
Mikko Perttunen
In-Reply-To: <20260622-t264-host1x-v2-0-ff7364d9ff7b@nvidia.com>
Add nvidia,tegra264-vic compatible string for the VIC on Tegra264. VIC
on Tegra264 has a new RISC-V based microcontroller and improved image
processing capabilities.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-vic.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-vic.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-vic.yaml
index 7200095ef19e..bdf981781bd5 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-vic.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-vic.yaml
@@ -22,6 +22,7 @@ properties:
- nvidia,tegra186-vic
- nvidia,tegra194-vic
- nvidia,tegra234-vic
+ - nvidia,tegra264-vic
- items:
- const: nvidia,tegra132-vic
--
2.53.0
^ permalink raw reply related
* [PATCH v2 1/7] dt-bindings: display: tegra: Changes to support Tegra264
From: Mikko Perttunen @ 2026-06-22 6:57 UTC (permalink / raw)
To: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-tegra, dri-devel, devicetree, linux-kernel, Mikko Perttunen
In-Reply-To: <20260622-t264-host1x-v2-0-ff7364d9ff7b@nvidia.com>
Add nvidia,tegra264-host1x compatible string. The Tegra264 host1x is
similar to Tegra234, but with a different set of engines and layout.
The engine register range is no longer continuous, so two range entries
are also needed.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
.../display/tegra/nvidia,tegra20-host1x.yaml | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
index 3563378a01af..8312b7699cbe 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
@@ -25,6 +25,7 @@ properties:
- nvidia,tegra186-host1x
- nvidia,tegra194-host1x
- nvidia,tegra234-host1x
+ - nvidia,tegra264-host1x
- items:
- const: nvidia,tegra132-host1x
@@ -57,7 +58,8 @@ properties:
enum: [1, 2]
ranges:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
clocks:
description: Must contain one entry, for the module clock. See
@@ -192,6 +194,7 @@ allOf:
contains:
enum:
- nvidia,tegra234-host1x
+ - nvidia,tegra264-host1x
then:
properties:
reg-names:
@@ -239,6 +242,21 @@ allOf:
required:
- reg-names
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra264-host1x
+ then:
+ properties:
+ ranges:
+ minItems: 2
+ maxItems: 2
+ else:
+ properties:
+ ranges:
+ maxItems: 1
examples:
- |
--
2.53.0
^ permalink raw reply related
* [PATCH v2 0/7] Host1x/VIC support on Tegra264
From: Mikko Perttunen @ 2026-06-22 6:57 UTC (permalink / raw)
To: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-tegra, dri-devel, devicetree, linux-kernel, Mikko Perttunen,
Conor Dooley, Santosh BS
Hello everyone,
this series adds support for Host1x and VIC on Tegra264 SoCs.
The Host1x side is not very interesting, just adding the usual register
definitions and other information. One thing of note is that multimedia
engines apart from VIC have moved away from Host1x on this generation.
On the VIC side, there is a bit more of a change, as the VIC Falcon is
now RISC-V based. Unlike NVDEC, VIC is still "externally booted", so
the boot sequence is very similar to before.
host1x uapi-test[1] has been updated for Tegra264. Necessary headers for
constructing VIC jobs have been added to open-gpu-doc[2].
Patches 1 and 2 add new compatible strings to Host1x and VIC device tree
bindings.
Patch 3 fixes the context device device tree parsing code to handle
iommu-map entries with length more than 1.
Patch 4 adds Tegra264 support to the Host1x driver.
Patches 5 and 6 add Tegra264 support to the VIC driver.
Patch 7 adds Host1x and VIC nodes to the Tegra264 device tree.
Thank you,
Mikko
[1] https://github.com/cyndis/uapi-test
[2] https://github.com/NVIDIA/open-gpu-doc/blob/master/classes/video/clceb6.h
https://github.com/NVIDIA/open-gpu-doc/blob/master/classes/video/vic_ceb6_types.h
---
Changes in v2:
- Updated dt-bindings changes to be chip-specific
- Link to v1: https://patch.msgid.link/20260612-t264-host1x-v1-0-8d934987de67@nvidia.com
---
Mikko Perttunen (6):
dt-bindings: display: tegra: Changes to support Tegra264
dt-bindings: display: tegra: Add Tegra264 compatible for VIC
gpu: host1x: Correctly parse linear ranges of context devices
drm/tegra: falcon: Add support for RISC-V external boot
drm/tegra: vic: Add Tegra264 support
arm64: tegra: Add Host1x and VIC on Tegra264
Santosh BS (1):
gpu: host1x: Add Tegra264 support
.../display/tegra/nvidia,tegra124-vic.yaml | 1 +
.../display/tegra/nvidia,tegra20-host1x.yaml | 20 ++-
arch/arm64/boot/dts/nvidia/tegra264.dtsi | 63 +++++++
drivers/gpu/drm/tegra/drm.c | 1 +
drivers/gpu/drm/tegra/falcon.c | 66 ++++++--
drivers/gpu/drm/tegra/falcon.h | 23 +++
drivers/gpu/drm/tegra/vic.c | 95 ++++++++---
drivers/gpu/drm/tegra/vic.h | 9 +-
drivers/gpu/host1x/Makefile | 3 +-
drivers/gpu/host1x/context.c | 13 +-
drivers/gpu/host1x/dev.c | 41 +++++
drivers/gpu/host1x/hw/cdma_hw.c | 12 +-
drivers/gpu/host1x/hw/host1x10.c | 33 ++++
drivers/gpu/host1x/hw/host1x10.h | 15 ++
drivers/gpu/host1x/hw/host1x10_hardware.h | 21 +++
drivers/gpu/host1x/hw/hw_host1x10_common.h | 6 +
drivers/gpu/host1x/hw/hw_host1x10_hypervisor.h | 10 ++
drivers/gpu/host1x/hw/hw_host1x10_uclass.h | 181 +++++++++++++++++++++
drivers/gpu/host1x/hw/hw_host1x10_vm.h | 36 ++++
19 files changed, 601 insertions(+), 48 deletions(-)
---
base-commit: 4549871118cf616eecdd2d939f78e3b9e1dddc48
change-id: 20260313-t264-host1x-c97171fdde77
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox