[GIT PULL 4/7] firmware/tegra: Changes for v7.4-rc1

[Sudeep Holla]

On Thu, Nov 05, 2026 at 02:31:31PM +0100, Thierry Reding wrote:
> On Thu, Nov 05, 2026 at 10:23:24AM +0000, Sudeep Holla wrote:
> > On Thu, Nov 05, 2026 at 10:54:42AM +0100, Arnd Bergmann wrote:
> > > On Thu, Nov 5, 2026, at 10:30, Sudeep Holla wrote:

[...]

> > 
> > I’ve quickly reviewed the patch; it does implements a custom method BMRQ
> > rather than a standard or out-of-the-box solution. More details on this is
> > used based on my understanding below.
> 
> To get everyone on the same page: in a nutshell, BPMP is a separate
> processor that handles various aspects of power management (Boot and
> Power Management Processor). The CPU communicates with it over a shared
> memory region and a mailbox/doorbell for signalling.
> 

I interpret this as PCC is used where needed and that aligns well with
my understanding.

> > > How does this relate to the EC and PCC interfaces in ACPI systems?
> > > 
> > 
> > I am still evaluating how the BPMP driver is intended to operate on ACPI
> > systems. In the meantime, I share the same questions noted above. The current
> > commit message lists several driver features that may not be required for
> > ACPI, which has introduced some clarity issues regarding the intended design.
> 
> My understanding is that an ACPI systems, as opposed to DT where we do
> this all through kernel drivers, the inter-processor communication is
> done via AML. This is because standard power management operations use
> this same mechanism to enable clocks, deassert resets, etc.
> 

Thanks for confirming this. I think we are almost aligned with respect to
the expectations from any ACPI system firmware.

> > > In current mainline, I see that the bpmp driver is used on DT systems
> > > by the tegra specific cpufreq, memory and pci drivers, but I would
> > > expect that on ACPI those all use shared drivers. Are there any other
> > > users that are not already covered on ACPI?
> > > 
> > 
> > For ACPI systems, CPUFreq operates through CPPC via PCC, MEMIO, or
> > supported backends.
> > 
> > My understanding is that the BMRQ method is called by tegra_bpmp_transfer(),
> > which supports Tegra-specific drivers for power domains, clocks, resets,
> > I2C, PCIe, and memory. On ACPI, these can be abstracted through PCC
> > OpRegions as part of standard methods like _ON/_OFF or other device state
> > methods. Although device/memory DVFS is trickier since the ACPI
> > specification lacks standard methods for it today, the commit message
> > implies these components are largely unused on ACPI systems.
> 
> I think this goes back to the disconnect from the patch thread and
> earlier in this discussion: the intent was very much to encapsulate all
> the power management within standard ACPI methods, and that's working
> fine, hence why clocks, resets and power domains are not getting exposed
> on ACPI systems.
> 

Agreed and I think we are aligned.

> However, there's no equivalent in ACPI to expose these MBWT knobs, hence
> the need to expose this through BPMP directly.
> 

IIUC this is Memory Bandwidth Throttling and shouldn't that align with
Arm MPAM and resctrl framework in the kernel ? We now have MPAM via PCC,
so if the firmware exposes the right interface, you must be able to reuse
that. Even otherwise, shouldn't to make this fit with resctrl ? What am I
missing ?

-- 
Regards,
Sudeep