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

[Sudeep Holla]

On Thu, Nov 05, 2026 at 10:54:42AM +0100, Arnd Bergmann wrote:
> On Thu, Nov 5, 2026, at 10:30, Sudeep Holla wrote:
> > On Wed, Nov 04, 2026 at 04:11:25PM -0800, Jonathan Cameron wrote:
> 
> >> 1) Basic stand alone driver stuff.  Mostly that's all pretty standard
> >>    and follow the specs where possible.  If there are gaps start asking
> >>    questions. Linux definitely  doesn't support all the stuff that has been
> >>    added to the spec in recent years.  So this covers things like register
> >>    addresses, interrupts etc.  All fine, hopefully a subsystem maintainer
> >>    can take a look and will have enough of any idea.  If not ping the folk
> >>    on this thread for help.  Things are a bit flexible for consumer type
> >>    devices where fixed and bodges are common, generally less so if it is
> >>    server grade hardware.
> >> 
> >> 2) Stuff that is an ACPI spec gap or place where we'd expect generalization.
> >>    There are several examples of this on list this week and a few more in
> >>    my inbox.  The particular series here might fall into this category.
> >>    I've not figured out enough of the details yet to say definitively.
> >> 
> >
> > Nicely summarised or categorised Jonathan. Nothing much to add.
> 
> +1
> 
> >> I'd also expect a driver using AML as the target interface to either
> >> point at a published spec doc, or to include some snippets
> >> of the AML - that can be a lot easier to read than the driver code
> >> (imagine reading DT by only looking at how drivers parse it).
> >> 
> >
> > Ideally, it should be just HID that any vendor needs to publish unless
> > they make use of any custom methods or something device specific like
> > DSD/DSM. I would expect most of the devices to use standard methods and
> > properties that are already well defined in the ACPI spec.
> 
> >> Given that has new ABI etc, I'd expect that to have gotten broader review
> >> as well.  Probably keeping it to linux-tegra and lkml alone wasn't
> >> going to result in anyone noticing!
> >> 
> >> https://lore.kernel.org/all/?q=20260929095915.2215685-1-anrao@nvidia.com
> >> 
> >
> > Agreed, it shouldn't hurt to cc linux-acpi for such driver ACPI enablement
> > patches.
> 
> Is the "BMRQ" in
> https://lore.kernel.org/all/20260929095915.2215685-3-anrao@nvidia.com/
> a custom method then? 
> 

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.

> 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.

> 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 have raised a query on the thread to clarify this.

-- 
Regards,
Sudeep