On Mon, Oct 04, 2021 at 09:55:32AM -0700, Florian Fainelli wrote:

On 10/4/21 9:51 AM, Jason Gunthorpe wrote:

quoted

On Mon, Oct 04, 2021 at 09:36:37AM -0700, Florian Fainelli wrote:

quoted

No please don't, I should have arguably justified the reasons why
better, but the main reason is that one of the platforms on which this
driver is used has received extensive power management analysis and
changes, and shutting down every bit of hardware, including something as
small as a SPI controller, and its clock (and its PLL) helped meet
stringent power targets.

Huh? for device shutdown? What would this matter if the next step is
reboot or power off?

Power off, the device is put into a low power state (equivalent to ACPI
S5) and then a remote control key press, or a GPIO could wake-up the
device again. While it is in that mode, it consumes less than 0.5W(AC).
Imagine your stick/cast/broom behind your TV falling in that category.

So really this is more of a very deep sleep that cannot be recovered
from than what other platforms would call a shutdown - eg the
powerdomain of the device under driver control will not loose
power.

I'm kind of surprised a scheme like this didn't involve a FW call
after Linux is done with the CPUs to quiet all the HW and let it
sleep, I've built things that way before at least.

I am fairly sure that no driver write knows about the being bound in
time aspect.

Well, it is a logical consequence. The system is shutting down, no
driver should be designed to deadlock the shutdown forever.

I suppose this is why I've occasionally seen Linux just hang at a
black screen and no power off when told to shutdown :)

Jason

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel