drm/i915 Update Gen8 golden context batch buffer

The file drivers/gpu/drm/i915/intel_renderstate_gen8.c is
updated to the version created by IGT null_state_gen

Signed-off-by: Armin Reese <armin.c.reese@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915 Add golden context support for Gen9

This patch includes the Gen9 batch buffer to generate
a 'golden context' for that product family.

Signed-off-by: Armin Reese <armin.c.reese@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: only flip frontbuffer if crtc is active

There is no point in flipping a buffer for a disabled crtc.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Remove unnecessary test on the gen in intel_do_mmio_flip()

use_mmio_flip() makes sure we only enable MMIO flips on gen5+. So we
don't need to take into account older devices.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ALSA: pcm: Correct PCM BUG error message

While converting to dev_*(), the message showing the invalid PCM
position was wrongly tagged as if an XRUN although it's actually a
BUG.  This patch corrects the message again.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: pcm: Replace PCM hwptr tracking with tracepoints

ALSA PCM core has a mechanism tracking the PCM hwptr updates for
analyzing XRUNs.  But its log is limited (up to 10) and its log output
is a kernel message, which is hard to handle.

In this patch, the hwptr logging is moved to the tracing
infrastructure instead of its own.  Not only the hwptr updates but
also XRUN and hwptr errors are recorded on the trace log, so that user
can see such events at the exact timing.

The new "snd_pcm" entry will appear in the tracing events:
  # ls -F /sys/kernel/debug/tracing/events/snd_pcm
  enable  filter  hw_ptr_error/  hwptr/  xrun/

The hwptr is for the regular hwptr update events.  An event trace
looks like:

  aplay-26187 [004] d..3  4012.834761: hwptr: pcmC0D0p/sub0: POS: pos=488, old=0, base=0, period=1024, buf=16384

"POS" shows the hwptr update by the explicit position update call and
"IRQ" means the hwptr update by the interrupt,
i.e. snd_pcm_period_elapsed() call.  The "pos" is the passed
ring-buffer offset by the caller, "old" is the previous hwptr, "base"
is the hwptr base position, "period" and "buf" are period- and
buffer-size of the target PCM substream.
(Note that the hwptr position displayed here isn't the ring-buffer
 offset.  It increments up to the PCM position boundary.)

The XRUN event appears similarly, but without "pos" field.
The hwptr error events appear with the PCM identifier and its reason
string, such as "Lost interrupt?".

The XRUN and hwptr error reports on kernel message are still left, can
be turned on/off via xrun_debug proc like before.  But the bit 3, 4, 5
and 6 bits of xrun_debug proc are dropped by this patch.  Also, along
with the change, the message strings have been reformatted to be a bit
more consistent.

Last but not least, the hwptr reporting is enabled only when
CONFIG_SND_PCM_XRUN_DEBUG is set.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: pcm: Add xrun_injection proc entry

This patch adds a new proc entry for PCM substreams to inject an
XRUN.  When a PCM substream is running and any value is written to its
xrun_injection proc file, the driver triggers XRUN.  This is a useful
feature for debugging XRUN and error handling code paths.

Note that this entry is enabled only when CONFIG_SND_PCM_XRUN_DEBUG is
set.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
of: introduce of_property_read_s32

Introduce signed 32bit integer of_property_read method.

Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
of: Eliminate of_allnodes list

The device tree structure is composed of two lists; the 'allnodes' list
which is a singly linked list containing every node in the tree, and the
child->parent structure where each parent node has a singly linked list
of children. All of the data in the allnodes list can be easily
reproduced with the parent-child lists, so of_allnodes is actually
unnecessary. Remove it entirely which saves a bit of memory and
simplifies the data structure quite a lot.

Signed-off-by: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Gaurav Minocha <gaurav.minocha.os@gmail.com>
Cc: Pantelis Antoniou <pantelis@pantelis.antoniou@konsulko.com>
scsi: consolidate opcode lookup in scsi_opcode_sa_name()

Consolidate the CDB opcode lookup in scsi_opcode_sa_name(),
so that we don't have to call several functions to figure
out the CDB opcode string.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Robert Elliott <elliott@hp.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
scsi: repurpose the last argument from print_opcode_name()

print_opcode_name() was only ever called with a '0' argument
from LLDDs and ULDs which were _not_ supporting variable length
CDBs, so the 'if' clause was never triggered.
Instead we should be using the last argument to specify
the cdb length to avoid accidental overflow when reading
the cdb buffer.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Robert Elliott <elliott@hp.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
scsi: Remove scsi_print_command when calling abort

Calling scsi_print_command should not be necessary during abort;
if the information is required one should enable scsi logging.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Robert Elliott <elliott@hp.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
scsi: separate out scsi_(host|driver)byte_string()

Export functions for later use.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Robert Elliott <elliott@hp.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
scsi: remove scsi_show_result()

Open-code scsi_print_result in sd.c, and cleanup logging to
not print duplicate informations.
Also remove the call to scsi_show_result() in ufshcd.c
to be consistent with other callers of scsi_execute().

With that we can remove scsi_show_result in constants.c

Signed-off-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Robert Elliott <elliott@hp.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
scsi: simplify scsi_log_(send|completion)

Simplify scsi_log_(send|completion) by externalizing
scsi_mlreturn_string() and always print the command address.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Robert Elliott <elliott@hp.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
scsi: fixup logging messages in scsi_error.c

Use the matching scope for logging messages to allow for
better command tracing.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Suggested-by: Robert Elliott <elliott@hp.com>
Reviewed-by: Robert Elliott <elliott@hp.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
scsi: use shost argument in scsi_eh_prt_fail_stats

The EH statistics are per host, so we should be using
shost_printk() here.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Suggested-by: Robert Elliott <elliott@hp.com>
Reviewed-by: Robert Elliott <elliott@hp.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
scsi: document scsi_try_to_abort_cmd

scsi_try_to_abort_cmd() should only return SUCCESS, FAILED, or
FAST_IO_FAIL. So document that in the function description and simplify
the logging message.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Suggested-by: Christoph Hellwig <hch@infradead.org>
Reviewed-by: Robert Elliott <elliott@hp.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
scsi: correct return values for .eh_abort_handler implementations

The .eh_abort_handler needs to return SUCCESS, FAILED, or
FAST_IO_FAIL. So fixup all callers to adhere to this requirement.

Reviewed-by: Robert Elliott <elliott@hp.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
scsi: ratelimit I/O error messages

There can be quite a lot of I/O error messages, even on smaller
machines. So we need to ratelimit them to not overwhelm logging.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Tested-by: Robert Elliott <elliott@hp.com>
Reviewed-by: Robert Elliott <elliott@hp.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>