[PATCH 03/12] PCI/ACPI: Add aux power grant notifier

[Gupta, Anshuman]

/snip
> > >
> > > Exactly like I said: If you only allow one driver to use the _DSM to
> > > request the Aux power from a given Root Port, it will have all of
> > > the information and does not need to be notified about any changes.
> > > Since no one else is allowed to use this interface for that Root
> > > Port, no one else will need a notifier either.  For this to work,
> > > you need some mechanism allowing drivers to claim the interface so
> > > no one else can use it (on a per Root Port basis) which is currently missing
> AFAICS.
> >
> > IMHO such kind of mechanism will require to add Root Port specific
> > data structure to claim the interface. But real problem is the criteria  to claim
> the interface.
> > Is first PCIe Non-Bridge Endpoint Function 0 driver can be criteria
> > to claim the Interface. Or first come and first serve approach ?
> 
> IMV, the first PCIe Non-Bridge Endpoint Function 0 driver approach would be
> sort of fragile and cumbersome to enforce.
> 
> First come, first serve is much simpler and should be sufficient for now AFAICS.
We are enabling VRSR only for default vga boot device.
As it needed only GPU driving the display for better user experience.
Can we use same logic vga_default_device() to claim the interface under root port.
That will simplify the criteria to claim the interface.
> 
> > > I think that this is the option you want to pursue.
> > >
> > We will prefer to stick with this option, if it can guaranty that
> > XeKMD will the only driver allowed to request Aux power to enable VRSR.
> >
> > > OTOH, if you want to allow multiple drivers to use this interface
> > > for the same Root Port, you need to aggregate the requests (as
> > > required by the spec IIUC) in the first place, or else the users can
> > > override each other's request.  In that case
> >
> > INHO how Linux Kernel will aggregate the Aux Power request, without
> > knowing the total Aux power budget. AFAIU aggregated Aux power request
> > without knowledge of total power budget can also be denied by BIOS[1].
> > Therefore how aggregation can be useful ?
> 
> Say two drivers request the Aux power from the same Root Port and each of
> them passes a limit sufficient for its device.  Without aggregation, what
> guarantees that the last limit passed will be sufficient for both devices?
Thanks for explaining this.
> 
> Also see the spec provision regarding retries below.
> 
> > [1]As per r3.3 Section 4.6.10
> > Platform Firmware Budgeting of Aux Power Availability:
> > Platform firmware must not grant more power than what is available
> > within the system. For example, a board may be designed with four CEM
> > slots (one x16 slot, one x4 slot, and two x1 slots). The board may
> > implement a power delivery circuit capable of supplying 2 W of power for the
> 3.3 Vaux rail supplying all 4 slots. The 3.3 Vaux pins on each CEM slot can
> supply 1 W each.
> > Platform firmware may use the retry mechanism to prioritize requests
> > from devices in preferred slots in the following manner:
> >
> > -> Requests from a device in the highest priority slot (e.g., x16) are
> > -> granted immediately, if
> > available.
> >
> > -> Requests from devices in lower priority slots (e.g., x2, x1) are
> > -> initially rejected, with a retry
> > interval inversely proportional to the slot priority. For instance, if
> > the x2 slot is higher priority than the x1 slots, so the retry
> > interval for the x2 slot may be 4 seconds, and the x1 slots may be
> > 8 and 10 seconds.
> >
> > ->As requests are granted, the granted values are subtracted from the
> available budget.
> >  Retried requests are granted based on the remaining power budget or
> > denied if insufficient power budget is available. Another retry is not
> permitted.
> >
> > -> When there is insufficient power budget for a request, firmware may
> > -> choose to keep main
> > power on and return no power removal (2h).
> 
> This means that the platform firmware is supposed to do its own aggregation,
> but at the system (board) level, not at the Root Port level.
> 
> The algorithm is described above and my understanding of it is that once a
> request has been granted, it cannot be retracted later.  Also it appears to
> assume a 1:1 correspondence between PCIe slots and Root Ports.
> 
> The guys who haven't been granted their requests at once may be asked to try
> again later and there may not be enough Aux power for the last guys at all, so
> they will not get it and they will stay on the main power.  And again, this
> appears to be at the Root Port granularity.
Thanks for explanation.
Thanks,
Anshuman