We can use queue_ring_free_flushed() instead, so remove this
redundancy.
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

Add a timer to each dma_ops domain so that we flush unused
IOTLB entries regularily, even if the queues don't get full
all the time.
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

The counters are increased every time the TLB for a given
domain is flushed. We also store the current value of that
counter into newly added entries of the flush-queue, so that
we can tell whether this entry is already flushed.
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

With locking we can safely access the flush-queues of other
cpus.
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

Fill the flush-queue on unmap and only flush the IOMMU and
device TLBs when a per-cpu queue gets full.
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

Make the flush-queue per dma-ops domain and add code
allocate and free the flush-queues;
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

The queue flushing is pretty inefficient when it flushes the
queues for all cpus at once. Further it flushes all domains
from all IOMMUs for all CPUs, which is overkill as well.

Rip it out to make room for something more efficient.
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

Currently if there is no room to add a command to the command buffer, the
driver performs a "completion wait" which only returns when all commands
on the queue have been processed. There is no need to wait for the entire
command queue to be executed before adding the next command.

Update the driver to perform the same udelay() loop that the "completion
wait" performs, but instead re-read the head pointer to determine if
sufficient space is available.  The very first time it is found that there
is no space available, the udelay() will be skipped to immediately perform
the opportunistic read of the head pointer. If it is still found that
there is not sufficient space, then the udelay() will be performed.
Signed-off-by: NLeo Duran <leo.duran@amd.com>
Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

As newer, higher speed devices are developed, perf data shows that the
amount of MMIO that is performed when submitting commands to the IOMMU
causes performance issues. Currently, the command submission path reads
the command buffer head and tail pointers and then writes the tail
pointer once the command is ready.

The tail pointer is only ever updated by the driver so it can be tracked
by the driver without having to read it from the hardware.

The head pointer is updated by the hardware, but can be read
opportunistically. Reading the head pointer only when it appears that
there might not be room in the command buffer and then re-checking the
available space reduces the number of times the head pointer has to be
read.
Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

struct irq_domain_ops is not modified, so it can be made const.
Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

Misbehaving devices can cause an endless chain of
io-page-faults, flooding dmesg and making the system-log
unusable or even prevent the system from booting.

So ratelimit the error messages about io-page-faults on a
per-device basis.
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

Add a new Kconfig option to enable/disable the extra warnings
from the vblank evade code. For now we'll keep the warning
about an actually missed vblank always enabled as that can have
an actual user visible impact. But if we miss the deadline
othrwise there's no real need to bother the user with that.
We'll want these warnings enabled during development however
so that we can catch regressions.

Based on the reports it looks like this is still very easy
to hit on SKL, so we have more work ahead of us to optimize
the crtiical section further.

Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reported-by: NJens Axboe <axboe@kernel.dk>
Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Fixes: e1edbd44 ("drm/i915: Complain if we take too long under vblank evasion.")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

gcc-7 warns about 'const SIMPLE_DEV_PM_OPS', as that macro already contains
a 'const' keyword:

drivers/input/keyboard/cros_ec_keyb.c:663:14: error: duplicate 'const' declaration specifier [-Werror=duplicate-decl-specifier]
 static const SIMPLE_DEV_PM_OPS(cros_ec_keyb_pm_ops, NULL, cros_ec_keyb_resume);

This removes the extra one.

Fixes: 6af6dc2d ("input: Add ChromeOS EC keyboard driver")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

These were ineffective due to touching the list without the alarm lock,
but should no longer be required.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

The idea here was to avoid having to "manually" program the HW if there's
a new earliest alarm.  This was lazy and bad, as it leads to loads of fun
races between inter-related callers (ie. therm).

Turns out, it's not so difficult after all.  Go figure ;)
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

At least therm/fantog "attempts" to work around this issue, which could
lead to corruption of the pending alarm list.

Fix it properly by not updating the timestamp without the lock held, or
trying to add an already pending alarm to the pending alarm list....
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

If the time to the next alarm is short enough, we could race with HW and
end up with an ~4 second delay until it triggers.

Fix this by checking again after we update HW.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

Fixes a race where we can miss an alarm that triggers while we're already
processing previous alarms.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

object->engine cannot be NULL, it's either valid, or an error pointer.

This particular condition shouldn't actually be possible, but just in
case, we'll keep it.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This reg has moved on Pascal, and causes a bus fault.

We never use the value anyway, so just remove the read.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The DRM core used to only call prepare_fb/cleanup_fb() when a plane's
framebuffer changed, which achieved the desired effect.

It's apparently now up to the driver to decide on its own.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org [4.11+]

This "optimisation" (which was originally meant to skip updating cursor
settings in the core channel on position-only updates) turned out to be
pointless in the final design of the code before it was merged.

Remove it completely, as it breaks other cases.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org [4.10+]

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This reverts commit 0e2eb7d1

  Author: Bart Van Assche <bart.vanassche@sandisk.com>
  Date:   Thu Mar 30 10:12:39 2017 -0700

      target: Fix VERIFY and WRITE VERIFY command parsing

This patch broke existing behaviour for WRITE_VERIFY because
it dropped the original SCF_SCSI_DATA_CDB assignment for
bytchk = 0 so target_cmd_size_check() no longer rejected
this case, allowing an overflow case to trigger an OOPs
in iscsi-target.

Since the short term and long term fixes are still being
discussed, revert it for now since it's late in the merge
window and try again in v4.13-rc1.

Conflicts:
	drivers/target/target_core_sbc.c
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

If we had badblocks/poison in the metadata area of a BTT, recreating the
BTT would not clear the poison in all cases, notably the flog area. This
is because rw_bytes will only clear errors if the request being sent
down is 512B aligned and sized.

Make sure that when writing the map and info blocks, the rw_bytes being
sent are of the correct size/alignment. For the flog, instead of doing
the smaller log_entry writes only, first do a 'wipe' of the entire area
by writing zeroes in large enough chunks so that errors get cleared.

Cc: Andy Rudoff <andy.rudoff@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NVishal Verma <vishal.l.verma@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

nsio_rw_bytes can clear media errors, but this cannot be done while we
are in an atomic context due to locking within ACPI. From the BTT,
->rw_bytes may be called either from atomic or process context depending
on whether the calls happen during initialization or during IO.

During init, we want to ensure error clearing happens, and the flag
marking process context allows nsio_rw_bytes to do that. When called
during IO, we're in atomic context, and error clearing can be skipped.

Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NVishal Verma <vishal.l.verma@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

PlayStation 1/2 joypads can be connected directly to the SPI interface.
Signed-off-by: NTomohiro Yoshidomi <sylph23k@gmail.com>
Acked-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Use the new enums for setting and getting the fan control mode.
Fixes problems due to previous inconsistencies between enums.
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Use the new enums for setting and getting the fan control mode.
Fixes problems due to previous inconsistencies between enums.
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Use the new enums for setting and getting the fan control mode.
Fixes problems due to previous inconsistencies between enums.
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Make the interface consistent.
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Add common fan enums that can be used for both
powerplay and dpm.
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Add some new SMU messages.
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The problem is that executing the jobs in the right order doesn't give you the right result
because consecutive jobs executed on the same engine are pipelined.
In other words job B does it buffer read before job A has written it's result.
Signed-off-by: NChunming Zhou <David1.Zhou@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Need to increment after the fence check.
Signed-off-by: NChunming Zhou <David1.Zhou@amd.com>
Reviewed-by: NJunwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Reviewed-by: NFelix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Need to use the atomfirmware interface rather than atombios since
soc15 is atomfirmware based.
Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Update the scratch reg for when the engine is hung.
Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Encountered a dozen of exact same backtraces when mesa's
pb_cache_release_all_buffers is called after that a gpu reset failed.

v2: Remove superfluous error message added in v1.

bug: https://bugs.freedesktop.org/show_bug.cgi?id=96271Signed-off-by: NJulien Isorce <jisorce@oblong.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Free up kmalloc allocated memory if failure happens while handling L2P
table transfer in nvme_nvm_get_l2p_tbl.

Fixes: 8e79b5cb ("lightnvm: move block provisioning to targets")
Signed-off-by: NRakesh Pandit <rakesh@tuxera.com>
Reviewed-by: NJavier González <javier@cnexlabs.com>
Signed-off-by: NJens Axboe <axboe@fb.com>