[Skiboot] [PATCH] Add OPAL_CONSOLE_FLUSH to the OPAL API
stewart at linux.vnet.ibm.com
Fri Nov 27 18:16:53 AEDT 2015
Russell Currey <ruscur at russell.cc> writes:
> uart consoles only flush output when polled. The Linux kernel calls these
> pollers frequently, except when in a panic state. As such, panic messages
> are not fully printed unless the system is configured to reboot after panic.
> This patch adds a new call to the OPAL API to completely flush the buffer.
> If the system has a uart console (i.e. BMC machines), it will fully flush
> the buffer. If not, this function will have no effect. This will allow
> the Linux kernel to ensure the panic message has been fully printed out.
> Signed-off-by: Russell Currey <ruscur at russell.cc>
> A patch to the Linux kernel to call this function while panicking will be
> sent upstream shortly. If this function is not defined (i.e. an older
> Skiboot version), it will just call opal_poll_events a bunch of times.
> core/console.c | 1 +
> doc/opal-api/opal-console-read-write-1-2.txt | 16 +++++++++++++++-
> include/opal-api.h | 3 ++-
> 3 files changed, 18 insertions(+), 2 deletions(-)
> diff --git a/core/console.c b/core/console.c
> index 1cee5da..9295d6c 100644
> --- a/core/console.c
> +++ b/core/console.c
> @@ -295,6 +295,7 @@ void flush_console_driver(void)
> if (con_driver && con_driver->flush != NULL)
> +opal_call(OPAL_CONSOLE_FLUSH, flush_console_driver, 0);
Current semantics of flush_console_driver are to block if needed while
things are flushed out. This is why we have async console flushing, so
that boot with a billion printfs going on doesn't take a huge amount of
time, and instead we only flush when we're about to shutdown or reboot.
Except that OPAL_CONSOLE_WRITE *does* flush the uart out.. so I think
this patch is okay....
Although I think we want to commit to the API being "if OPAL_BUSY is
returned, call again as the whole buffer is *not* yet flushed". As I
think that would leave us open to be being able to hook into the kernel
tty layer flush()ing mechanism in the future?
> void set_console(struct con_ops *driver)
> diff --git a/doc/opal-api/opal-console-read-write-1-2.txt b/doc/opal-api/opal-console-read-write-1-2.txt
> index b8fbc12..97d0632 100644
> --- a/doc/opal-api/opal-console-read-write-1-2.txt
> +++ b/doc/opal-api/opal-console-read-write-1-2.txt
> @@ -1,11 +1,12 @@
> OPAL Console calls
> -There are three OPAL calls relating to the OPAL console:
> +There are four OPAL calls relating to the OPAL console:
> #define OPAL_CONSOLE_WRITE 1
> #define OPAL_CONSOLE_READ 2
> #define OPAL_CONSOLE_WRITE_BUFFER_SPACE 25
> +#define OPAL_CONSOLE_FLUSH 117
> The OPAL console calls can support multiple consoles. Each console MUST
> be represented in the device tree.
> @@ -64,3 +65,16 @@ Returns:
> Use OPAL_POLL_EVENTS for how to determine
> + none
Should same paramter as OPAL_CONSOLE_READ/WRITE, which accepts a
term_number parameter. We may want a simple way to say "just the one
that's actually the OPAL console dammit" - maybe ~0 as term_number?
> + none
Should return OPAL_SUCCESS and as mentioned above OPAL_BUSY if buffer
not completely flushed (actually... come to think of it, maybe
OPAL_PARTIAL is what we want there).
Even though OPAL_CONSOLE_WRITE is currently synchronous and all that,
let's not limit what we specify the API to be.
More information about the Skiboot