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

[Thierry Reding <thierry.reding@kernel.org>]

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

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

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.

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

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

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

Thierry

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