On Thu, Feb 06, 2020 at 01:45:14PM -0700, Lina Iyer wrote:

On Thu, Feb 06 2020 at 01:46 -0700, Ulf Hansson wrote:

quoted

On Wed, 5 Feb 2020 at 17:18, Sudeep Holla [off-list ref] wrote:

quoted

On Wed, Feb 05, 2020 at 04:55:17PM +0100, Ulf Hansson wrote:

quoted

On Wed, 5 Feb 2020 at 15:06, Sudeep Holla [off-list ref] wrote:

quoted

On Wed, Feb 05, 2020 at 05:53:00PM +0530, Maulik Shah wrote:

quoted

On 2/4/2020 8:51 PM, Sudeep Holla wrote:

quoted

On Tue, Feb 04, 2020 at 10:22:42AM +0530, Maulik Shah wrote:

quoted

On 2/3/2020 10:38 PM, Sudeep Holla wrote:

quoted

On Mon, Feb 03, 2020 at 07:05:38PM +0530, Maulik Shah wrote:

quoted

From: Ulf Hansson <redacted>

I was, but not anymore, especially if we want such changes in the kernel
to do so.

Just use OSI as that was the point of adding all these after years of
discussion claiming it's more optimal compared to PC. Now telling that
you need more changes to compare it with PC just doesn't make any sense
at all to me.

Fair enough.

I was just pondering over if there are other reasons to why we may want this.

One other thing that could be problematic to support, is when are
other resources, I/O controllers for example, sharing the same power
rail as a cluster. When such controller is in use, idle states of the
cluster must be prevented. Without using genpd to model the CPU
topology, it may be difficult to deal with this.

Of course, using PC mode when trying to deal with this
platform/board-requirement would also be suboptimal. In other words,
your argument about when using OSI vs PC mode, still stands.

I understand the arguments for using PC vs OSI and agree with it. But
what in PSCI is against Linux knowing when the last core is powering
down when the PSCI is configured to do only Platform Cordinated.

Nothing :D. But knowing the evolution and reasons for adding OSI in the
PSCI specification and having argued about benefits of OSI over PC for
years and finally when we have it in mainline, this argument of using
PC for exact reasons why OSI evolved is something I can't understand
and I am confused.

There should not be any objection to drivers knowing when all the cores
are powered down, be it reference counting CPU PM notifications or using
a cleaner approach like this where GendPD framwork does everything
cleanly and gives a nice callback. ARM architecture allows for different
aspects of CPU access be handled at different levels. I see this as an
extension of that approach.

One thing that was repeatedly pointed out during OSI patch review was no
extra overhead for PC mode where firmware can make decisions. So, just
use OSI now and let us be done with this discussion of OSI vs PC. If PC
is what you think you need for future, we can revert all OSI changes and
start discussing again :-)

--
Regards,
Sudeep

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