Make assert(false) for calling attn be a PR_EMERG level error

When we do something so severe we're asserting... we want that to
be in the log!

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
opal_del_caller shouldn't be called: up severity level, change message.

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Reduce the amount of text 'parsing hdat' uses.

We can, by default, deal with just two lines rather than 5 of
ASCII art

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Modify the (many) printouts in core/cpu.c to have appropriate PR levels

We don't need too much detail coming out the serial port, some more
detail in memory is good, but for the most part, summarize.

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Modify HOMER printouts in hw/homer.c to be (mostly) PR_DEBUG prlog calls

Having these in memory may be of benefit, but we don't need them
out the serial console unless something fooey is going on.

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Returning CPU message just needs to be PR_DEBUG at most

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
convert printf in core/cpu.c to prlog with PR_INFO or PR_DEBUG

Most of these things are only needed during some interesting
debugging sessions, not for normal startup. Let's keep them
in memory buffer, not on serial console (unless user specifies)

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
decrease verbosity of logging CPU information.

If we have an UNAVAILABLE core (e.g. garded by FSP), we *WILL*
print that out with PR_WARNING, as that's probably something
that people want to pay attention to. Otherwise we stick with
PR_INFO, which should be enough for these kind of log messages.

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Only print SPIRA discovered serial port info at PR_INFO priority

It's certainly not an error that we have a serial port, and not
essential to display during boot. Odds are, you already know
about the serial port.

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
hdata/memory.c: only prlog with PR_DEBUG most things

We will PR_INFO the total amount of memory, as this is just
informative.

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
bump last two hdata/memory.c MS VPD printouts to PR_DEBUG

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Reduce severity of XSCOM detection log message to PR_INFO

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Secondary CPUs calling in should be PR_DEBUG

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Increase verbosity of CHIPTOD to PR_DEBUG

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Rework hdata/iohub.c CEC log messages to appropriate log levels

We're mostly PR_DEBUG here, except for the basics, which are PR_INFO.

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Get assert and PEL log messages from HBRT to the correct priority

(PR_CRIT and PR_ERR respectively)

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Reduce severity of hdata/fsp.c log messages (mostly to PR_DEBUG)

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Some CHIPTOD log messages should be prerror in event of error.

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
FSP buffer allocation messages can be PR_DEBUG.

Very unlikely to ever actually fail.

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Adjust log message priority in fsp-leds.c

Mostly PR_DEBUG or PR_TRACE, but a few error conditions should
be PR_ERR.

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>