mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
To: Abhishek Goel <huntbag@linux.vnet.ibm.com>,
	linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org
Cc: ego@linux.vnet.ibm.com, mikey@neuling.org, mpe@ellerman.id.au,
	oohall@gmail.com, psampat@linux.ibm.com, svaidy@linux.ibm.com,
	skiboot@lists.ozlabs.org
Subject: Re: [RFC 1/3] powernv/cpuidle : Support for pre-entry and post exit of stop state in firmware
Date: Tue, 28 Apr 2020 11:08:54 +1000	[thread overview]
Message-ID: <1588035100.usm3gb816q.astroid@bobo.none> (raw)
In-Reply-To: <20200427021027.114582-1-huntbag@linux.vnet.ibm.com>

Thanks for picking this up and pushing it along. I do plan to come back 
and take another look at it all, but what we do need to do first is get 
a coherent approach to this proposed new calling convention and OS ops.

It's fine to work on this in the meantime, but to start merging things
my idea is:

- OPAL must leave r13-r15 untouched for the OS.
- OS ops are made available only for a "v4" OS that uses the new
  calling convention, including kernel stack.
- OS ops baseline (all OSes must provide) will be console / printk 
  facility, trap handling and crash/symbol decoding on behalf of OPAL,
  and runtime virtual memory.

Other OS ops features can be added in the versioned structure, including 
this.

I'm trying to get back to cleaning these things up and start getting 
them merged now. Any comments or review on those would be helpful.

Thanks,
Nick


  parent reply	other threads:[~2020-04-28  1:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-27  2:10 Abhishek Goel
2020-04-27  2:10 ` [RFC 2/3] powernv/cpuidle : Interface for an idle-stop dependency structure Abhishek Goel
2020-04-27 13:47   ` Gautham R Shenoy
2020-04-27  2:10 ` [RFC 3/3] powernv/cpuidle : Introduce capability for firmware-enabled-stop Abhishek Goel
2020-04-27 13:48   ` Gautham R Shenoy
2020-04-27 10:26 ` [RFC 1/3] powernv/cpuidle : Support for pre-entry and post exit of stop state in firmware Gautham R Shenoy
2020-04-28  1:08 ` Nicholas Piggin [this message]
2020-04-30  5:52   ` Abhishek
2020-05-02 11:40     ` Nicholas Piggin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1588035100.usm3gb816q.astroid@bobo.none \
    --to=npiggin@gmail.com \
    --cc=ego@linux.vnet.ibm.com \
    --cc=huntbag@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mikey@neuling.org \
    --cc=mpe@ellerman.id.au \
    --cc=oohall@gmail.com \
    --cc=psampat@linux.ibm.com \
    --cc=skiboot@lists.ozlabs.org \
    --cc=svaidy@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®