[PATCH v2 0/1] drm/tyr: make SRAM supply optional like panthor

[PATCH v2 0/1] drm/tyr: make SRAM supply optional like panthor

[Onur Özkan]

Changes in v2:
- Add rust_helper_regulator_get_optional() to fix CONFIG_REGULATOR=n
  builds where `regulator_get_optional()` may be only a static inline.
- Update Regulator invariants documentation to mention both regulator_get()
  and regulator_get_optional().

Onur Özkan (1):
  drm/tyr: make SRAM supply optional like panthor

 drivers/gpu/drm/tyr/driver.rs |  5 ++--
 rust/helpers/regulator.c      |  5 ++++
 rust/kernel/regulator.rs      | 45 +++++++++++++++++++++++++++++++++--
 3 files changed, 51 insertions(+), 4 deletions(-)

-- 
2.51.2

[PATCH v2 1/1] drm/tyr: make SRAM supply optional like panthor

[Onur Özkan]

On rk3588s, `dmesg | grep 'tyr'` logs:

  tyr fb000000.gpu: supply SRAM not found, using dummy regulator

This happens because Tyr calls Regulator<Enabled>::get() for SRAM,
which goes through the non-optional regulator_get() path. If the
device tree doesn't provide sram-supply, regulator core falls back
to a dummy regulator and writes that log.

Panthor handles SRAM as optional and tolerates missing sram-supply.
This patch matches that behavior in Tyr by using optional regulator
lookup and storing SRAM as Option<Regulator<Enabled>> which avoids
dummy-regulator fallback/noise when SRAM is not described inside
the device tree.

Link: https://rust-for-linux.zulipchat.com/#narrow/stream/x/topic/x/near/573210018
Signed-off-by: Onur Özkan <work@onurozkan.dev>
---
 drivers/gpu/drm/tyr/driver.rs |  5 ++--
 rust/helpers/regulator.c      |  5 ++++
 rust/kernel/regulator.rs      | 45 +++++++++++++++++++++++++++++++++--
 3 files changed, 51 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tyr/driver.rs b/drivers/gpu/drm/tyr/driver.rs
index 0389c558c036..e0856deb83ec 100644
--- a/drivers/gpu/drm/tyr/driver.rs
+++ b/drivers/gpu/drm/tyr/driver.rs
@@ -113,7 +113,8 @@ fn probe(
         coregroup_clk.prepare_enable()?;
 
         let mali_regulator = Regulator::<regulator::Enabled>::get(pdev.as_ref(), c_str!("mali"))?;
-        let sram_regulator = Regulator::<regulator::Enabled>::get(pdev.as_ref(), c_str!("sram"))?;
+        let sram_regulator =
+            Regulator::<regulator::Enabled>::get_optional(pdev.as_ref(), c_str!("sram"))?;
 
         let request = pdev.io_request_by_index(0).ok_or(ENODEV)?;
         let iomem = Arc::pin_init(request.iomap_sized::<SZ_2M>(), GFP_KERNEL)?;
@@ -201,5 +202,5 @@ struct Clocks {
 #[pin_data]
 struct Regulators {
     mali: Regulator<regulator::Enabled>,
-    sram: Regulator<regulator::Enabled>,
+    sram: Option<Regulator<regulator::Enabled>>,
 }
diff --git a/rust/helpers/regulator.c b/rust/helpers/regulator.c
index 11bc332443bd..5ef45a8adf12 100644
--- a/rust/helpers/regulator.c
+++ b/rust/helpers/regulator.c
@@ -25,6 +25,11 @@ struct regulator *rust_helper_regulator_get(struct device *dev, const char *id)
 	return regulator_get(dev, id);
 }
 
+struct regulator *rust_helper_regulator_get_optional(struct device *dev, const char *id)
+{
+	return regulator_get_optional(dev, id);
+}
+
 int rust_helper_regulator_enable(struct regulator *regulator)
 {
 	return regulator_enable(regulator);
diff --git a/rust/kernel/regulator.rs b/rust/kernel/regulator.rs
index 2c44827ad0b7..d27ce3f6ef26 100644
--- a/rust/kernel/regulator.rs
+++ b/rust/kernel/regulator.rs
@@ -232,10 +232,11 @@ pub fn devm_enable_optional(dev: &Device<Bound>, name: &CStr) -> Result {
 ///
 /// # Invariants
 ///
-/// - `inner` is a non-null wrapper over a pointer to a `struct
-///   regulator` obtained from [`regulator_get()`].
+/// - `inner` is a non-null wrapper over a pointer to a `struct regulator`
+///   obtained from [`regulator_get()`] or [`regulator_get_optional()`].
 ///
 /// [`regulator_get()`]: https://docs.kernel.org/driver-api/regulator.html#c.regulator_get
+/// [`regulator_get_optional()`]: https://docs.kernel.org/driver-api/regulator.html#c.regulator_get_optional
 pub struct Regulator<State>
 where
     State: RegulatorState,
@@ -283,6 +284,29 @@ fn get_internal(dev: &Device, name: &CStr) -> Result<Regulator<T>> {
         })
     }
 
+    fn get_optional_internal(dev: &Device, name: &CStr) -> Result<Option<Regulator<T>>> {
+        // SAFETY: It is safe to call `regulator_get_optional()`, on a
+        // device pointer received from the C code.
+        let inner = from_err_ptr(unsafe {
+            bindings::regulator_get_optional(dev.as_raw(), name.as_char_ptr())
+        });
+
+        let inner = match inner {
+            Ok(inner) => inner,
+            Err(ENODEV) => return Ok(None),
+            Err(err) => return Err(err),
+        };
+
+        // SAFETY: We can safely trust `inner` to be a pointer to a valid
+        // regulator if `ERR_PTR` was not returned.
+        let inner = unsafe { NonNull::new_unchecked(inner) };
+
+        Ok(Some(Self {
+            inner,
+            _phantom: PhantomData,
+        }))
+    }
+
     fn enable_internal(&self) -> Result {
         // SAFETY: Safe as per the type invariants of `Regulator`.
         to_result(unsafe { bindings::regulator_enable(self.inner.as_ptr()) })
@@ -300,6 +324,11 @@ pub fn get(dev: &Device, name: &CStr) -> Result<Self> {
         Regulator::get_internal(dev, name)
     }
 
+    /// Obtains an optional [`Regulator`] instance from the system.
+    pub fn get_optional(dev: &Device, name: &CStr) -> Result<Option<Self>> {
+        Regulator::get_optional_internal(dev, name)
+    }
+
     /// Attempts to convert the regulator to an enabled state.
     pub fn try_into_enabled(self) -> Result<Regulator<Enabled>, Error<Disabled>> {
         // We will be transferring the ownership of our `regulator_get()` count to
@@ -329,6 +358,18 @@ pub fn get(dev: &Device, name: &CStr) -> Result<Self> {
             .map_err(|error| error.error)
     }
 
+    /// Obtains an optional [`Regulator`] instance from the system and enables it.
+    pub fn get_optional(dev: &Device, name: &CStr) -> Result<Option<Self>> {
+        match Regulator::<Disabled>::get_optional_internal(dev, name)? {
+            Some(regulator) => {
+                let enabled_regulator =
+                    regulator.try_into_enabled().map_err(|error| error.error)?;
+                Ok(Some(enabled_regulator))
+            }
+            None => Ok(None),
+        }
+    }
+
     /// Attempts to convert the regulator to a disabled state.
     pub fn try_into_disabled(self) -> Result<Regulator<Disabled>, Error<Enabled>> {
         // We will be transferring the ownership of our `regulator_get()` count
-- 
2.51.2

Re: [PATCH v2 1/1] drm/tyr: make SRAM supply optional like panthor

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 548 bytes --]

On Thu, Feb 12, 2026 at 01:05:38PM +0300, Onur Özkan wrote:
> On rk3588s, `dmesg | grep 'tyr'` logs:
> 
>   tyr fb000000.gpu: supply SRAM not found, using dummy regulator
> 
> This happens because Tyr calls Regulator<Enabled>::get() for SRAM,
> which goes through the non-optional regulator_get() path. If the
> device tree doesn't provide sram-supply, regulator core falls back
> to a dummy regulator and writes that log.

> Panthor handles SRAM as optional and tolerates missing sram-supply.

Does the RAM really work without power?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2 1/1] drm/tyr: make SRAM supply optional like panthor

[Onur Özkan]

On Thu, 12 Feb 2026 11:34:41 +0000
Mark Brown <broonie@kernel.org> wrote:

> On Thu, Feb 12, 2026 at 01:05:38PM +0300, Onur Özkan wrote:
> > On rk3588s, `dmesg | grep 'tyr'` logs:
> > 
> >   tyr fb000000.gpu: supply SRAM not found, using dummy regulator
> > 
> > This happens because Tyr calls Regulator<Enabled>::get() for SRAM,
> > which goes through the non-optional regulator_get() path. If the
> > device tree doesn't provide sram-supply, regulator core falls back
> > to a dummy regulator and writes that log.
> 
> > Panthor handles SRAM as optional and tolerates missing sram-supply.
> 
> Does the RAM really work without power?

If the platform has no separate sram-supply (meaning that rail is
coupled to mali), RAM should still be powered and work fine. Panthor
already relies on this model by treating sram-supply as optional and
as far as I can see there are no RAM issues on Panthor.

- Onur

Re: [PATCH v2 1/1] drm/tyr: make SRAM supply optional like panthor

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

On Thu, Feb 12, 2026 at 03:16:44PM +0300, Onur Özkan wrote:
> Mark Brown <broonie@kernel.org> wrote:
> > On Thu, Feb 12, 2026 at 01:05:38PM +0300, Onur Özkan wrote:

> > > Panthor handles SRAM as optional and tolerates missing sram-supply.

> > Does the RAM really work without power?

> If the platform has no separate sram-supply (meaning that rail is
> coupled to mali), RAM should still be powered and work fine. Panthor
> already relies on this model by treating sram-supply as optional and
> as far as I can see there are no RAM issues on Panthor.

The panthor driver is buggy here and should be fixed, the driver should
treat the supply as mandatory and let the system integration work out
how it's actually made available.

Trying to open code this just breaks the error handling.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2 1/1] drm/tyr: make SRAM supply optional like panthor

[Boris Brezillon]

On Thu, 12 Feb 2026 12:21:07 +0000
Mark Brown <broonie@kernel.org> wrote:

> On Thu, Feb 12, 2026 at 03:16:44PM +0300, Onur Özkan wrote:
> > Mark Brown <broonie@kernel.org> wrote:  
> > > On Thu, Feb 12, 2026 at 01:05:38PM +0300, Onur Özkan wrote:  
> 
> > > > Panthor handles SRAM as optional and tolerates missing sram-supply.  
> 
> > > Does the RAM really work without power?  
> 
> > If the platform has no separate sram-supply (meaning that rail is
> > coupled to mali), RAM should still be powered and work fine. Panthor
> > already relies on this model by treating sram-supply as optional and
> > as far as I can see there are no RAM issues on Panthor.  
> 
> The panthor driver is buggy here and should be fixed, the driver should
> treat the supply as mandatory and let the system integration work out
> how it's actually made available.
> 
> Trying to open code this just breaks the error handling.

Maybe, but the thing is, the DT bindings have been accepted already,
and it's not something we can easily change. What we can do is make this
sram-supply mandatory for new compatibles, but we can't force it on
older/existing SoCs without breaking backward-DT compat.

Re: [PATCH v2 1/1] drm/tyr: make SRAM supply optional like panthor

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

On Thu, Feb 12, 2026 at 01:46:01PM +0100, Boris Brezillon wrote:
> Mark Brown <broonie@kernel.org> wrote:

> > The panthor driver is buggy here and should be fixed, the driver should
> > treat the supply as mandatory and let the system integration work out
> > how it's actually made available.

> > Trying to open code this just breaks the error handling.

> Maybe, but the thing is, the DT bindings have been accepted already,
> and it's not something we can easily change. What we can do is make this
> sram-supply mandatory for new compatibles, but we can't force it on
> older/existing SoCs without breaking backward-DT compat.

In practice you can because we do sub in a dummy regulator for missing
supplies, it produces a warning but works fine.  If we didn't do this
it'd be basically impossible to add regulator support to anything at any
point after the original merge which is clearly not reasonable.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2 1/1] drm/tyr: make SRAM supply optional like panthor

[Boris Brezillon]

On Thu, 12 Feb 2026 13:13:31 +0000
Mark Brown <broonie@kernel.org> wrote:

> On Thu, Feb 12, 2026 at 01:46:01PM +0100, Boris Brezillon wrote:
> > Mark Brown <broonie@kernel.org> wrote:  
> 
> > > The panthor driver is buggy here and should be fixed, the driver should
> > > treat the supply as mandatory and let the system integration work out
> > > how it's actually made available.  
> 
> > > Trying to open code this just breaks the error handling.  
> 
> > Maybe, but the thing is, the DT bindings have been accepted already,
> > and it's not something we can easily change. What we can do is make this
> > sram-supply mandatory for new compatibles, but we can't force it on
> > older/existing SoCs without breaking backward-DT compat.  
> 
> In practice you can because we do sub in a dummy regulator for missing
> supplies, it produces a warning but works fine.  If we didn't do this
> it'd be basically impossible to add regulator support to anything at any
> point after the original merge which is clearly not reasonable.

Okay, I guess we need to fix panthor then...

Re: [PATCH v2 1/1] drm/tyr: make SRAM supply optional like panthor

[Onur Özkan]

On Thu, 12 Feb 2026 14:51:34 +0100
Boris Brezillon <boris.brezillon@collabora.com> wrote:

> On Thu, 12 Feb 2026 13:13:31 +0000
> Mark Brown <broonie@kernel.org> wrote:
> 
> > On Thu, Feb 12, 2026 at 01:46:01PM +0100, Boris Brezillon wrote:
> > > Mark Brown <broonie@kernel.org> wrote:  
> > 
> > > > The panthor driver is buggy here and should be fixed, the
> > > > driver should treat the supply as mandatory and let the system
> > > > integration work out how it's actually made available.  
> > 
> > > > Trying to open code this just breaks the error handling.  
> > 
> > > Maybe, but the thing is, the DT bindings have been accepted
> > > already, and it's not something we can easily change. What we can
> > > do is make this sram-supply mandatory for new compatibles, but we
> > > can't force it on older/existing SoCs without breaking
> > > backward-DT compat.  
> > 
> > In practice you can because we do sub in a dummy regulator for
> > missing supplies, it produces a warning but works fine.  If we
> > didn't do this it'd be basically impossible to add regulator
> > support to anything at any point after the original merge which is
> > clearly not reasonable.
> 
> Okay, I guess we need to fix panthor then...
> 

That + updating the log to something like "sram-supply is missing in
the DT" would be quite better I think. It would make the issue more
obvious and convey that the DT file is expected to configure that field
explicitly. With the current log message, not many people will
understand the problem at a glance.

As for the bug I described in this patch, we can proceed with the
alternative solution (updating the DT file) that I mentioned in the
Zulip thread (the link is included in the patch). Which is this simple
diff:

diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
index dafad29f9854..a30339fd2c10 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
@@ -177,6 +177,7 @@ &gmac1_rgmii_clk

 &gpu {
        mali-supply = <&vdd_gpu_s0>;
+       sram-supply = <&vdd_gpu_mem_s0>;
        status = "okay";
 };

@@ -537,7 +538,7 @@ rk806_dvs3_null: dvs3-null-pins {
                };

                regulators {
-                       vdd_gpu_s0: dcdc-reg1 {
+                       vdd_gpu_s0: vdd_gpu_mem_s0: dcdc-reg1 {
                                regulator-name = "vdd_gpu_s0";
                                regulator-boot-on;
                                regulator-min-microvolt = <550000>;

Note that this only fixes the issue for the Orange Pi 5. If we want
to go further, the same approach should be applied to many other boards
as well. I can generate a list of the DT files (using a simple Python
script) that need this update over the weekend.

If we want to go even further and fix all DT files to properly include
sram-supply we could also enforce that DT files do not omit sram-supply
in the future. I am not sure this is strictly necessary but it also
doesn't seem consistent to leave things as they are. Right now, some DT
files include sram-supply even when there is no separate SRAM rail,
while others do not. As a result, some boards will continue to print
that annoying log message.

It's not very clear which approach is best.

Re: [PATCH v2 1/1] drm/tyr: make SRAM supply optional like panthor

[Liviu Dudau]

On Thu, Feb 12, 2026 at 09:30:10PM +0300, Onur Özkan wrote:
> On Thu, 12 Feb 2026 14:51:34 +0100
> Boris Brezillon <boris.brezillon@collabora.com> wrote:
> 
> > On Thu, 12 Feb 2026 13:13:31 +0000
> > Mark Brown <broonie@kernel.org> wrote:
> > 
> > > On Thu, Feb 12, 2026 at 01:46:01PM +0100, Boris Brezillon wrote:
> > > > Mark Brown <broonie@kernel.org> wrote:  
> > > 
> > > > > The panthor driver is buggy here and should be fixed, the
> > > > > driver should treat the supply as mandatory and let the system
> > > > > integration work out how it's actually made available.  
> > > 
> > > > > Trying to open code this just breaks the error handling.  
> > > 
> > > > Maybe, but the thing is, the DT bindings have been accepted
> > > > already, and it's not something we can easily change. What we can
> > > > do is make this sram-supply mandatory for new compatibles, but we
> > > > can't force it on older/existing SoCs without breaking
> > > > backward-DT compat.  
> > > 
> > > In practice you can because we do sub in a dummy regulator for
> > > missing supplies, it produces a warning but works fine.  If we
> > > didn't do this it'd be basically impossible to add regulator
> > > support to anything at any point after the original merge which is
> > > clearly not reasonable.
> > 
> > Okay, I guess we need to fix panthor then...
> > 
> 
> That + updating the log to something like "sram-supply is missing in
> the DT" would be quite better I think. It would make the issue more
> obvious and convey that the DT file is expected to configure that field
> explicitly. With the current log message, not many people will
> understand the problem at a glance.
> 
> As for the bug I described in this patch, we can proceed with the
> alternative solution (updating the DT file) that I mentioned in the
> Zulip thread (the link is included in the patch). Which is this simple
> diff:
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
> index dafad29f9854..a30339fd2c10 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
> @@ -177,6 +177,7 @@ &gmac1_rgmii_clk
> 
>  &gpu {
>         mali-supply = <&vdd_gpu_s0>;
> +       sram-supply = <&vdd_gpu_mem_s0>;
>         status = "okay";
>  };
> 
> @@ -537,7 +538,7 @@ rk806_dvs3_null: dvs3-null-pins {
>                 };
> 
>                 regulators {
> -                       vdd_gpu_s0: dcdc-reg1 {
> +                       vdd_gpu_s0: vdd_gpu_mem_s0: dcdc-reg1 {

You don't need to define a new label, using the same supply for mali-supply and
sram-supply should be fine.

>                                 regulator-name = "vdd_gpu_s0";
>                                 regulator-boot-on;
>                                 regulator-min-microvolt = <550000>;
> 
> Note that this only fixes the issue for the Orange Pi 5. If we want
> to go further, the same approach should be applied to many other boards
> as well. I can generate a list of the DT files (using a simple Python
> script) that need this update over the weekend.

Yes, please, but bias the script towards using the same regulator as mali-supply.

> 
> If we want to go even further and fix all DT files to properly include
> sram-supply we could also enforce that DT files do not omit sram-supply
> in the future. I am not sure this is strictly necessary but it also
> doesn't seem consistent to leave things as they are. Right now, some DT
> files include sram-supply even when there is no separate SRAM rail,
> while others do not. As a result, some boards will continue to print
> that annoying log message.
> 
> It's not very clear which approach is best.

I'm in favor of the proposal here, where we make sram-supply mandatory for non-"mt8196-mali"
SoCs and we patch the DTs to add the sram-supply for those.

Best regards,
Liviu


-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

Re: [PATCH v2 1/1] drm/tyr: make SRAM supply optional like panthor

[Boris Brezillon]

Hi,

On Fri, 13 Feb 2026 12:15:47 +0000
Liviu Dudau <Liviu.Dudau@arm.com> wrote:

> On Thu, Feb 12, 2026 at 09:30:10PM +0300, Onur Özkan wrote:
> > On Thu, 12 Feb 2026 14:51:34 +0100
> > Boris Brezillon <boris.brezillon@collabora.com> wrote:
> >   
> > > On Thu, 12 Feb 2026 13:13:31 +0000
> > > Mark Brown <broonie@kernel.org> wrote:
> > >   
> > > > On Thu, Feb 12, 2026 at 01:46:01PM +0100, Boris Brezillon wrote:  
> > > > > Mark Brown <broonie@kernel.org> wrote:    
> > > >   
> > > > > > The panthor driver is buggy here and should be fixed, the
> > > > > > driver should treat the supply as mandatory and let the system
> > > > > > integration work out how it's actually made available.    
> > > >   
> > > > > > Trying to open code this just breaks the error handling.    
> > > >   
> > > > > Maybe, but the thing is, the DT bindings have been accepted
> > > > > already, and it's not something we can easily change. What we can
> > > > > do is make this sram-supply mandatory for new compatibles, but we
> > > > > can't force it on older/existing SoCs without breaking
> > > > > backward-DT compat.    
> > > > 
> > > > In practice you can because we do sub in a dummy regulator for
> > > > missing supplies, it produces a warning but works fine.  If we
> > > > didn't do this it'd be basically impossible to add regulator
> > > > support to anything at any point after the original merge which is
> > > > clearly not reasonable.  
> > > 
> > > Okay, I guess we need to fix panthor then...
> > >   
> > 
> > That + updating the log to something like "sram-supply is missing in
> > the DT" would be quite better I think. It would make the issue more
> > obvious and convey that the DT file is expected to configure that field
> > explicitly. With the current log message, not many people will
> > understand the problem at a glance.
> > 
> > As for the bug I described in this patch, we can proceed with the
> > alternative solution (updating the DT file) that I mentioned in the
> > Zulip thread (the link is included in the patch). Which is this simple
> > diff:
> > 
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
> > b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
> > index dafad29f9854..a30339fd2c10 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
> > @@ -177,6 +177,7 @@ &gmac1_rgmii_clk
> > 
> >  &gpu {
> >         mali-supply = <&vdd_gpu_s0>;
> > +       sram-supply = <&vdd_gpu_mem_s0>;
> >         status = "okay";
> >  };
> > 
> > @@ -537,7 +538,7 @@ rk806_dvs3_null: dvs3-null-pins {
> >                 };
> > 
> >                 regulators {
> > -                       vdd_gpu_s0: dcdc-reg1 {
> > +                       vdd_gpu_s0: vdd_gpu_mem_s0: dcdc-reg1 {  
> 
> You don't need to define a new label, using the same supply for mali-supply and
> sram-supply should be fine.
> 
> >                                 regulator-name = "vdd_gpu_s0";
> >                                 regulator-boot-on;
> >                                 regulator-min-microvolt = <550000>;
> > 
> > Note that this only fixes the issue for the Orange Pi 5. If we want
> > to go further, the same approach should be applied to many other boards
> > as well. I can generate a list of the DT files (using a simple Python
> > script) that need this update over the weekend.  
> 
> Yes, please, but bias the script towards using the same regulator as mali-supply.
> 
> > 
> > If we want to go even further and fix all DT files to properly include
> > sram-supply we could also enforce that DT files do not omit sram-supply
> > in the future. I am not sure this is strictly necessary but it also
> > doesn't seem consistent to leave things as they are. Right now, some DT
> > files include sram-supply even when there is no separate SRAM rail,
> > while others do not. As a result, some boards will continue to print
> > that annoying log message.
> > 
> > It's not very clear which approach is best.  
> 
> I'm in favor of the proposal here, where we make sram-supply mandatory for non-"mt8196-mali"
> SoCs and we patch the DTs to add the sram-supply for those.

Works for me. Thanks for chiming in Liviu.

Regards,

Boris

Re: [PATCH v2 1/1] drm/tyr: make SRAM supply optional like panthor

[Onur Özkan]

Hi Liviu,

Thank you for reviewing this.

On Fri, 13 Feb 2026 12:15:47 +0000
Liviu Dudau <Liviu.Dudau@arm.com> wrote:

> On Thu, Feb 12, 2026 at 09:30:10PM +0300, Onur Özkan wrote:
> > On Thu, 12 Feb 2026 14:51:34 +0100
> > Boris Brezillon <boris.brezillon@collabora.com> wrote:
> > 
> > > On Thu, 12 Feb 2026 13:13:31 +0000
> > > Mark Brown <broonie@kernel.org> wrote:
> > > 
> > > > On Thu, Feb 12, 2026 at 01:46:01PM +0100, Boris Brezillon wrote:
> > > > > Mark Brown <broonie@kernel.org> wrote:  
> > > > 
> > > > > > The panthor driver is buggy here and should be fixed, the
> > > > > > driver should treat the supply as mandatory and let the
> > > > > > system integration work out how it's actually made
> > > > > > available.  
> > > > 
> > > > > > Trying to open code this just breaks the error handling.  
> > > > 
> > > > > Maybe, but the thing is, the DT bindings have been accepted
> > > > > already, and it's not something we can easily change. What we
> > > > > can do is make this sram-supply mandatory for new
> > > > > compatibles, but we can't force it on older/existing SoCs
> > > > > without breaking backward-DT compat.  
> > > > 
> > > > In practice you can because we do sub in a dummy regulator for
> > > > missing supplies, it produces a warning but works fine.  If we
> > > > didn't do this it'd be basically impossible to add regulator
> > > > support to anything at any point after the original merge which
> > > > is clearly not reasonable.
> > > 
> > > Okay, I guess we need to fix panthor then...
> > > 
> > 
> > That + updating the log to something like "sram-supply is missing in
> > the DT" would be quite better I think. It would make the issue more
> > obvious and convey that the DT file is expected to configure that
> > field explicitly. With the current log message, not many people will
> > understand the problem at a glance.
> > 
> > As for the bug I described in this patch, we can proceed with the
> > alternative solution (updating the DT file) that I mentioned in the
> > Zulip thread (the link is included in the patch). Which is this
> > simple diff:
> > 
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
> > b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
> > index dafad29f9854..a30339fd2c10 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
> > @@ -177,6 +177,7 @@ &gmac1_rgmii_clk
> > 
> >  &gpu {
> >         mali-supply = <&vdd_gpu_s0>;
> > +       sram-supply = <&vdd_gpu_mem_s0>;
> >         status = "okay";
> >  };
> > 
> > @@ -537,7 +538,7 @@ rk806_dvs3_null: dvs3-null-pins {
> >                 };
> > 
> >                 regulators {
> > -                       vdd_gpu_s0: dcdc-reg1 {
> > +                       vdd_gpu_s0: vdd_gpu_mem_s0: dcdc-reg1 {
> 
> You don't need to define a new label, using the same supply for
> mali-supply and sram-supply should be fine.
>

That also works but I never seen that usage (sram-supply =
<&vdd_gpu_s0>) anywhere in the tree and I wanted to follow the
current standard.
 
> >                                 regulator-name = "vdd_gpu_s0";
> >                                 regulator-boot-on;
> >                                 regulator-min-microvolt = <550000>;
> > 
> > Note that this only fixes the issue for the Orange Pi 5. If we want
> > to go further, the same approach should be applied to many other
> > boards as well. I can generate a list of the DT files (using a
> > simple Python script) that need this update over the weekend.
> 
> Yes, please, but bias the script towards using the same regulator as
> mali-supply.
> 
> > 
> > If we want to go even further and fix all DT files to properly
> > include sram-supply we could also enforce that DT files do not omit
> > sram-supply in the future. I am not sure this is strictly necessary
> > but it also doesn't seem consistent to leave things as they are.
> > Right now, some DT files include sram-supply even when there is no
> > separate SRAM rail, while others do not. As a result, some boards
> > will continue to print that annoying log message.
> > 
> > It's not very clear which approach is best.
> 
> I'm in favor of the proposal here, where we make sram-supply
> mandatory for non-"mt8196-mali" SoCs and we patch the DTs to add the
> sram-supply for those.
> 

Cool! 

Regards,
Onur

> Best regards,
> Liviu
> 
> 

Re: [PATCH v2 1/1] drm/tyr: make SRAM supply optional like panthor

[Liviu Dudau]

On Thu, Feb 12, 2026 at 12:21:07PM +0000, Mark Brown wrote:
> On Thu, Feb 12, 2026 at 03:16:44PM +0300, Onur Özkan wrote:
> > Mark Brown <broonie@kernel.org> wrote:
> > > On Thu, Feb 12, 2026 at 01:05:38PM +0300, Onur Özkan wrote:
> 
> > > > Panthor handles SRAM as optional and tolerates missing sram-supply.
> 
> > > Does the RAM really work without power?
> 
> > If the platform has no separate sram-supply (meaning that rail is
> > coupled to mali), RAM should still be powered and work fine. Panthor
> > already relies on this model by treating sram-supply as optional and
> > as far as I can see there are no RAM issues on Panthor.
> 
> The panthor driver is buggy here and should be fixed, the driver should
> treat the supply as mandatory and let the system integration work out
> how it's actually made available.

Please note that the sram supply is mandatory in all compatibles except
for the "mt8196-mali". This was to work around the fact that MTK has decided
to control some supplies via another method and not give Panthor control over
those.

We should fix Panthor to check that we only treat the sram supply as
optional for "mt8196-mali", but that doesn't alleviate Tyr's need to support
optional regulators.

Best regards,
Liviu

> 
> Trying to open code this just breaks the error handling.



-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

Re: [PATCH v2 1/1] drm/tyr: make SRAM supply optional like panthor

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 619 bytes --]

On Fri, Feb 13, 2026 at 10:57:49AM +0000, Liviu Dudau wrote:

> Please note that the sram supply is mandatory in all compatibles except
> for the "mt8196-mali". This was to work around the fact that MTK has decided
> to control some supplies via another method and not give Panthor control over
> those.

> We should fix Panthor to check that we only treat the sram supply as
> optional for "mt8196-mali", but that doesn't alleviate Tyr's need to support
> optional regulators.

If you know that the supply will never be present for that compatible
then the driver shouldn't really be requesting it in the first place.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2 1/1] drm/tyr: make SRAM supply optional like panthor

[Boris Brezillon]

On Thu, 12 Feb 2026 15:16:44 +0300
Onur Özkan <work@onurozkan.dev> wrote:

> On Thu, 12 Feb 2026 11:34:41 +0000
> Mark Brown <broonie@kernel.org> wrote:
> 
> > On Thu, Feb 12, 2026 at 01:05:38PM +0300, Onur Özkan wrote:  
> > > On rk3588s, `dmesg | grep 'tyr'` logs:
> > > 
> > >   tyr fb000000.gpu: supply SRAM not found, using dummy regulator
> > > 
> > > This happens because Tyr calls Regulator<Enabled>::get() for SRAM,
> > > which goes through the non-optional regulator_get() path. If the
> > > device tree doesn't provide sram-supply, regulator core falls back
> > > to a dummy regulator and writes that log.  
> >   
> > > Panthor handles SRAM as optional and tolerates missing sram-supply.  
> > 
> > Does the RAM really work without power?  
> 
> If the platform has no separate sram-supply (meaning that rail is
> coupled to mali), RAM should still be powered and work fine. Panthor
> already relies on this model by treating sram-supply as optional and
> as far as I can see there are no RAM issues on Panthor.

Yep, some SoC integration have just one power-rail for everything in
the GPU, others have two. The sram-supply is documented as optional in
the DT bindings, so I think that's the right thing to do.

Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>

> 
> - Onur

Re: [PATCH v2 1/1] drm/tyr: make SRAM supply optional like panthor

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

On Thu, Feb 12, 2026 at 01:22:22PM +0100, Boris Brezillon wrote:
> Onur Özkan <work@onurozkan.dev> wrote:

> > If the platform has no separate sram-supply (meaning that rail is
> > coupled to mali), RAM should still be powered and work fine. Panthor
> > already relies on this model by treating sram-supply as optional and
> > as far as I can see there are no RAM issues on Panthor.

> Yep, some SoC integration have just one power-rail for everything in
> the GPU, others have two. The sram-supply is documented as optional in
> the DT bindings, so I think that's the right thing to do.

This is expected to be handled through platform integration of the
device, not through bodges like this.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]