Not clearing this flag causes spurious interrupts at least in D3 state,
so before enabling RPM we need to fix this. We were already setting this
flag when enabling interrupts, only clearing it was missing.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

These will be needed by the upcoming VLV RPM helpers.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The BDW GT3 has two independent BSD rings, which can be used to process the
video commands. To be simpler, it is transparent to user-space driver/middle.
Instead the kernel driver will decide which ring is to dispatch the BSD video
command.

As every BSD ring is powerful, it is enough to dispatch the BSD video command
based on the drm fd. In such case it can play back video stream while encoding
another video stream. The coarse ping-pong mechanism is used to determine
which BSD ring is used to dispatch the BSD video command.

V1->V2: Follow Daniel's comment and use the simple ping-pong mechanism.
This is only to add the support of dual BSD rings on BDW GT3 machine.
The further optimization will be considered in another patch set.

V2->V3: Follow Daniel's comment to use the struct_mutext instead of
atomic_t during determining which ring can be used to dispatch Video command.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The Gen7 doesn't have the second BSD ring. But it will complain the switch check
warning message during compilation. So just add it to remove the
switch check warning.

V1->V2: Follow Daniel's comment to update the comment
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Based on the hardware spec, the BDW GT3 machine has two independent
BSD ring that can be used to dispatch the video commands.
So just initialize it.

V3->V4: Follow Imre's comment to do some minor updates. For example:
more comments are added to describe the semaphore between ring.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
[danvet: Fix up checkpatch error.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Based on the hardware spec, the BDW GT3 has the different configuration
with the BDW GT1/GT2. So split the BDW device info definition.
This is to do the preparation for adding the Dual BSD rings on BDW GT3 machine.

V1->V2: Follow Daniel's comment to pay attention to the stolen check for BDW
in kernel/early-quirks.c
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need to make sure that userspace keeps on following the contract,
otherwise we won't be able to use the reserved fields at all.

v2: Add DRM_DEBUG (Chris)

Testcase: igt/gem_exec_params/*-dirt
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

A bit tricky since 0 is also a valid constant ...

v2: Add DRM_DEBUG (Chris)

Testcase: igt/gem_exec_params/rel-constants-*
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently we catch it, but silently succeed. Our userspace is
better than this.

v2: Add DRM_DEBUG (Chris)

Testcase: igt/gem_exec_params/sol-reset-*
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If we include the expected values for the failing ring register checks,
it makes it marginally easier to see which is the culprit.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NOscar Mateo <oscar.mateo@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

During module load, if we fail to initialise the rings, we abort the
load reporting EIO. However during resume, even though we report EIO as
we fail to reinitialize the ringbuffers, the resume continues and the
device is restored - albeit in a non-functional state. As we cannot
execute any commands on the GPU, it is effectively wedged, mark it so.

As we now preserve the ringbuffers across resume, this should prevent
UXA from falling into the trap of repeatedly sending invalid
batchbuffers and dropping all further rendering into /dev/null.
Reported-and-tested-by: NJiri Kosina <jkosina@suse.cz>
References: https://bugs.freedesktop.org/show_bug.cgi?id=76554Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NOscar Mateo <oscar.mateo@intel.com>
[danvet: Drop unused error, spotted by Oscar.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Even without enabling the ringbuffers to allow command execution, we can
still control the display engines to enable modesetting. So make the
ringbuffer initialization failure soft, and mark the GPU as wedged
instead.

v2: Only treat an EIO from ring initialisation as a soft failure, and
abort module load for any other failure, such as allocation failures.

v3: Add an *ERROR* prior to declaring the GPU wedged so that it stands
out like a sore thumb in the logs
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NOscar Mateo <oscar.mateo@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Tearing down the ring buffers across resume is overkill, risks
unnecessary failure and increases fragmentation.

After failure, since the device is still active we may end up trying to
write into the dangling iomapping and trigger an oops.

v2: stop_ringbuffers() was meant to call stop(ring) not
cleanup(ring) during resume!
Reported-by: NJae-hyeon Park <jhyeon@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=72351
References: https://bugs.freedesktop.org/show_bug.cgi?id=76554Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NOscar Mateo <oscar.mateo@intel.com>
[danvet: s/ring->obj == NULL/!intel_ring_initialized(ring)/ as
suggested by Oscar.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For readibility and guess at the meaning behind the constants.

v2: Claim only the meagerest connections with reality.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NOscar Mateo <oscar.mateo@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I don't think this is necessary; at least it doesn't appear to be on my
BYT.  Dropping it speeds up our shutdown code a little, in some cases
resulting in faster init times.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Remove occurrences of unused struct qxl_device pointer in functions
qxl_ttm_fault() and qxl_init_mem_type().

Detected by Coverity: CID 1019128, CID 1019129.
Signed-off-by: NChristian Engelmayer <cengelma@gmx.at>
Signed-off-by: NDave Airlie <airlied@redhat.com>

For QXL hw we really want the bits to be replaced as we change
the preferred mode on the fly, and the same goes for virgl when
I get to it, however the original fix for this seems to have caused
a wierd regression on Intel G33 that in a stunning display of failure
at opposition to his normal self, Daniel failed to diagnose.

So we are left doing this, ugly ugly ugly ugly, Daniel you fixed
that G33 yet?, ugly, ugly.
Tested-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Use %pad for dma_addr_t, because a dma_addr_t type can vary
based on build options. So, it prevents possible build warnings
in printks.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Reviewed-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

devm_ioremap_resource() returns an error pointer, not NULL. Thus,
the result should be checked with IS_ERR().
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

exynos_drm_crtc_mode_set assigns primary framebuffer to plane without
taking reference. Then during framebuffer removal it is dereferenced twice,
causing oops. The patch fixes it.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

A number of older CMOTech modems are based on Qualcomm
chips.  The blacklisted interfaces are QMI/wwan.
Reported-by: NLars Melin <larsm17@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Device interface layout:
0: ff/ff/ff - serial
1: ff/00/00 - serial AT+PPP
2: ff/ff/ff - QMI/wwan
3: 08/06/50 - storage

Cc: <stable@vger.kernel.org>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Device interface layout:
0: ff/ff/ff - serial
1: ff/ff/ff - serial AT+PPP
2: 08/06/50 - storage
3: ff/ff/ff - serial
4: ff/ff/ff - QMI/wwan

Cc: <stable@vger.kernel.org>
Reported-by: NJulio Araujo <julio.araujo@wllctel.com.br>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Cc: <stable@vger.kernel.org>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Cc: <stable@vger.kernel.org>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Cc: <stable@vger.kernel.org>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

During firmware download the device expects memory addresses in
big-endian byte order. As the wIndex parameter which hold the address is
sent in little-endian byte order regardless of host byte order, we need
to use swab16 rather than cpu_to_be16.

Also make sure to handle the struct ti_i2c_desc size parameter which is
returned in little-endian byte order.
Reported-by: NLudovic Drolez <ldrolez@debian.org>
Tested-by: NLudovic Drolez <ldrolez@debian.org>
Cc: stable@vger.kernel.org
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this
warning:
drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined
but not used [-Wunused-function]

Instead of creating nested #ifdefs, this patch fixes it by defining the
xHCI PCI stubs as inline.

This warning has been in since 3.2 kernel and was
caused by commit 421aa841
"usb/xhci: hide MSI code behind PCI bars", but wasn't noticed
until 3.13 when a configuration with these options was tried
Signed-off-by: NDavid Cohen <david.a.cohen@linux.intel.com>
Cc: stable@vger.kernel.org # 3.2
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

After suspend another Renesas PCI-X USB 3.0 card doesn't work.
[root@fedora-20 ~]# lspci -vmnnd 1912:
Device:	03:00.0
Class:	USB controller [0c03]
Vendor:	Renesas Technology Corp. [1912]
Device:	uPD720202 USB 3.0 Host Controller [0015]
SVendor:	Renesas Technology Corp. [1912]
SDevice:	uPD720202 USB 3.0 Host Controller [0015]
Rev:	02
ProgIf:	30

This patch should be applied to stable kernel 3.14 that contain
the commit 1aa9578c
"xhci: Fix resume issues on Renesas chips in Samsung laptops"
Reported-and-tested-by: NAnatoly Kharchenko <rfr-bugs@yandex.ru>
Reference: http://redmine.russianfedora.pro/issues/1315Signed-off-by: NIgor Gnatenko <i.gnatenko.brain@gmail.com>
Cc: stable@vger.kernel.org # 3.14
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The same issue like with Panther Point chipsets. If the USB ports are
switched to xHCI on shutdown, the xHCI host will send a spurious interrupt,
which will wake the system. Some BIOS have work around for this, but not all.
One example is Compulab's mini-desktop, the Intense-PC2.

The bug can be avoided if the USB ports are switched back to EHCI on
shutdown.

This patch should be backported to stable kernels as old as 3.12,
that contain the commit 638298dc
"xhci: Fix spurious wakeups after S5 on Haswell"
Signed-off-by: NDenis Turischev <denis@compulab.co.il>
Cc: stable@vger.kernel.org
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We have observed a rare cycle state desync bug after Set TR Dequeue
Pointer commands on Intel LynxPoint xHCs (resulting in an endpoint that
doesn't fetch new TRBs and thus an unresponsive USB device). It always
triggers when a previous Set TR Dequeue Pointer command has set the
pointer to the final Link TRB of a segment, and then another URB gets
enqueued and cancelled again before it can be completed. Further
investigation showed that the xHC had returned the Link TRB in the TRB
Pointer field of the Transfer Event (CC == Stopped -- Length Invalid),
but when xhci_find_new_dequeue_state() later accesses the Endpoint
Context's TR Dequeue Pointer field it is set to the first TRB of the
next segment.

The driver expects those two values to be the same in this situation,
and uses the cycle state of the latter together with the address of the
former. This should be fine according to the XHCI specification, since
the endpoint ring should be stopped when returning the Transfer Event
and thus should not advance over the Link TRB before it gets restarted.
However, real-world XHCI implementations apparently don't really care
that much about these details, so the driver should follow a more
defensive approach to try to work around HC spec violations.

This patch removes the stopped_trb variable that had been used to store
the TRB Pointer from the last Transfer Event of a stopped TRB. Instead,
xhci_find_new_dequeue_state() now relies only on the Endpoint Context,
requiring a small amount of additional processing to find the virtual
address corresponding to the TR Dequeue Pointer. Some other parts of the
function were slightly rearranged to better fit into this model.

This patch should be backported to kernels as old as 2.6.31 that contain
the commit ae636747 "USB: xhci: URB
cancellation support."
Signed-off-by: NJulius Werner <jwerner@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In commit a51435a3
Author: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Date:   Wed Mar 12 16:39:40 2014 +0530

    drm/i915: disable rings before HW status page setup

we reordered stopping the rings to do so before we set the HWS register.
However, there is an extra workaround for g45 to reset the rings twice,
and for consistency we should apply that workaround before setting the
HWS to be sure that the rings are truly stopped.

Reference: http://lkml.kernel.org/r/20140423202248.GA3621@amd.pavel.ucw.czTested-by: NPavel Machek <pavel@ucw.cz>
Cc: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The status bits are unconditionally set, the control bits only enable
the actual interrupt generation. Which means if we get some random
other interrupts we'll bogusly complain about them.

So restrict the WARN to platforms with a sane hotplug interrupt
handling scheme. And even more important also don't attempt to process
the hpd bit since we've detected a storm already. Instead just clear
the bit silently.

This WARN has been introduced in

commit b8f102e8
Author: Egbert Eich <eich@suse.de>
Date:   Fri Jul 26 14:14:24 2013 +0200

    drm/i915: Add messages useful for HPD storm detection debugging (v2)

before that we silently handled the hpd event and so partially
defeated the storm detection.

v2: Pimp commit message (Jani)

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Egbert Eich <eich@suse.de>
Cc: bitlord <bitlord0xff@gmail.com>
Reported-by: Nbitlord <bitlord0xff@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The hw cursor is relatively adept at triggering underflows, which
manifest as a "blue flash" (since blue is configured as the underflow
color).  Juggle a few things around to tighten up the timing for setting
cursor registers in DONE irq.

And most importantly, don't ever disable the hw cursor.  Instead flip it
to a blank/empty cursor.  This seems far more reliable, as even simply
clearing the cursor-enable bit (with no other updates in previous/
following frames) can in some cases cause underflow.

v1: original
v2: add missing locking spotted by Micah

Cc: Micah Richert <richert@braincorporation.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Since X11 is going to create an XR24 fb, if the pixel formats do not
match then crtc helpers will think it is a full modeset even if mode is
the same, which prevents smooth/flickerless handover from fbcon/plymouth
to X11.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Signed-off-by: NMicah Richert <richert@braincorporation.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

While porting a RS485 driver from 2.6.29 to 3.14, i noticed that the serial tty
driver could break it by using uart ports that it does not own :

1. uart_change_pm ist called during uart_open and calls the uart pm function
   without checking for PORT_UNKNOWN.
   The fix is to move uart_change_pm from uart_open to uart_port_startup.
2. The return code from the uart request_port call in uart_set_info is not
   handled properly, leading to the situation that the serial driver also
   thinks it owns the uart ports.
   This can triggered by doing following actions :

   setserial /dev/ttyS0 uart none    # release the uart ports
   modprobe lirc-serial              # or any other device that uses the uart
   setserial /dev/ttyS0 uart 16550   # gives no error and the uart tty driver
                                     # can use the ports as well
Signed-off-by: NThomas Pfaff <tpfaff@pcs.com>
Reviewed-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The two functions to write out to the console (one used in normal
console mode and one in polling console mode) were slightly different.
One used a barrier() in its loop and the other a cpu_relax().  The
barrier() really doesn't do anything since we're using rd_regl() to
read the port anyway.  Switch it to cpu_relax() to make things
consistent.

No known bugs / issues are fixed by this change--it just makes things
more consistent.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>