The current minimum vco frequency leaves us with a gap in our supported
frequencies at 233-243 MHz. Your typical 2560x1440@60 display wants a
pixel clock of 241.5 MHz, which is just withing that gap. Reduce the
allowed vco min frequency to 4.8GHz to reduce the gap to 233-240 MHz,
and thus allow such displays to work.

4.8 GHz is actually the documented (at least in some docs) limit of the
PLL, and we just picked 4.86 GHz originally because that was the lowest
value produced by the PLL spreadsheet, which obviously didn't consider
2560x1440 displays.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVijay Purushothaman <vijay.a.purushothaman@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need this for FBC, and possibly for PSR too.

v2: Don't only flush: invalidate too (Daniel).
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We want to port FBC to the frontbuffer tracking infrastructure, but
for that we need to know what caused the object invalidation so
we can react accordingly: CPU mmaps need manual, GTT mmaps and
flips don't need handling and ring rendering needs nukes.

v2: - s/ORIGIN_RENDER/ORIGIN_CS/ (Daniel, Rodrigo)
    - Fix copy/pasted wrong documentation
    - Rebase
v3: - Rebase
v4: - Don't pass the operation to flushes (Daniel).
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This reverts commit 3f678c96.

We've been a bit too optimistic with this one here :(

The trouble is that internally we're still using these plane
update/disable hooks. Which was totally ok pre-atomic since the drm
core did all the book-keeping updating and these just mostly updated
hw state. But with atomic there's lots more going on, and it causes
heaps of trouble with the load detect code.

This one specifically cause a deadlock since both the load detect code
and the nested plane atomic helper functions tried to grab the same
locks. It only blows up because of the evil tricks though we play with
the implicit ww acquire context.

Applying this revert unearths the NULL deref on already freed
framebuffer objects reported as a regression in 4.0 by various people.

Fixing this will be fairly invasive, hence revert even for the
4.1-next queue.

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Bolle <pebolle@tiscali.nl>
Acked-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

This translation entry was updated after electrical validation by the hw
team. The other entries are removed from existence as they aren't
validated and because the sole use of a certain type of level shifter
for SKL products is anticipated.

v2: Remove all the other entries and force the use of the 800mv+2dB
    config (Sonika)
Suggested-by: NSonika Jindal <sonika.jindal@intel.com>
Cc: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NSonika Jindal <sonika.jindal@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Implicit usage of local variables in macros isn't exactly the greatest
thing in the world, especially when that variable is the drm device and
we want to move towards a broader use of the i915 device structure.

Let's make for_each_sprite() take dev_priv as its first argument then.
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Implicit usage of local variables in macros isn't exactly the greatest
thing in the world, especially when that variable is the drm device and
we want to move towards a broader use of the i915 device structure.

Let's make for_each_plane() take dev_priv as its first argument then.
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the two-step reset counter increments which braket the actual
reset code and the subsequent wake-up we're guaranteeing that all the
lockless waiters _will_ be woken up. And since we unconditionally bail
out of waits with -EAGAIN (or -EIO) in that case there is not risk of
lost interrupt enabling bits when the lockless wait code races against
a gpu reset.

Let's remove this FIXME as resolved then.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Change 'mutliple' to 'multiple'
Change 'mutlipler' to 'multiplier'
Change 'Haswel' to 'Haswell'
Signed-off-by: NYannick Guerrini <yguerrini@tomshardware.fr>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

plane->fb is a legacy pointer that not always be up-to-date (or updated
early enough).  Make sure the watermark code uses plane->state->fb so
that we're always doing our calculations based on the correct
framebuffers.

This patch was generated by Coccinelle with the following semantic
patch:

        @@
        struct drm_plane *P;
        @@
        - P->fb
        + P->state->fb

v2: Rebase
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The cursor size fields in intel_crtc just duplicate the data from
cursor->state.crtc_{w,h} so we don't need them any more.  Worse, their
use in the watermark code actually introduces a subtle bug since they
don't get updated to mirror the state values until the plane commit
stage, which is *after* we've already used them to calculate new
watermark values.  This happens because we had to move watermark updates
slightly earlier (outside vblank evasion) in commit

        commit 32b7eeec
        Author: Matt Roper <matthew.d.roper@intel.com>
        Date:   Wed Dec 24 07:59:06 2014 -0800

            drm/i915: Refactor work that can sleep out of commit (v7)

Dropping the intel_crtc fields and just using the state values (which
are properly updated by the time watermark updates happen) should solve
the problem.

Aside from the actual removal of the struct fields (which are formatted
in a way that I couldn't figure out how to match in Coccinelle), the
rest of this patch was generated via the following semantic patch:

        // Drop assignment
        @@
        struct intel_crtc *C;
        struct drm_plane_state S;
        @@
        (
        - C->cursor_width = S.crtc_w;
        |
        - C->cursor_height = S.crtc_h;
        )

        // Replace usage
        @@
        struct intel_crtc *C;
        expression E;
        @@
        (
        - C->cursor_width
        + C->base.cursor->state->crtc_w
        |
        - C->cursor_height
        + C->base.cursor->state->crtc_h
        |
        - to_intel_crtc(E)->cursor_width
        + E->cursor->state->crtc_w
        |
        - to_intel_crtc(E)->cursor_height
        + E->cursor->state->crtc_h
        )

v2: Rebase

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Joe Konno <joe.konno@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89346Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Drivers implementing the universal planes API report the list of
supported pixel formats for the primary plane. Make sure the fb passed
to the setcrtc ioctl is compatible.

Drivers not implementing the universal planes API will have no format
reported for the primary plane, skip the check in that case.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since the beginning, sysfs/connector/status has done a heavyweight
detection of the current connector status. But no user, such as upowerd
or logind, has ever desired to initiate a probe. Move the probing into a
new attribute so that existing readers get the behaviour they desire.

v2: David Herrmann suggested using "echo detect > /sys/.../status" to
trigger the probing, which is a fine idea. This extends that to also
allow the user to apply the force detection overrides at runtime.

v3: Now with airlied's email address fixed! Requires sysfs_streq()
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We shouldn't tempt driver writers into using this since it uses a
default format list which is likely wrong. And when that's done we can
simplify the code a bit, too.

Noticed while reviewing a patch from Laurent.

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Both the legacy and atomic helpers need to check whether a plane
supports a given pixel format. The code is currently duplicated, share
it.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
[danvet: Slightly extend the docbook.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Change 'pixes' to 'pixels'
Change 'enabel' to 'enable'
Change 'enabeling' to 'enabling'
Signed-off-by: NYannick Guerrini <yguerrini@tomshardware.fr>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Originally it was impossible to be dropping the last refcount in this
function since there was always one around still from the idr. But in

commit 83f45fc3
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Aug 6 09:10:18 2014 +0200

    drm: Don't grab an fb reference for the idr

we've switched to weak references, broke that assumption but forgot to
fix it up.

Since we still force-disable planes it's only possible to hit this
when racing multiple rmfb with fbdev restoring or similar evil things.
As long as userspace is nice it's impossible to hit the BUG_ON.

But the BUG_ON would most likely be hit from fbdev code, which usually
invovles the console_lock besides all modeset locks. So very likely
we'd never get the bug reports if this was hit in the wild, hence
better be safe than sorry and backport.

Spotted by Matt Roper while reviewing other patches.

Cc: stable@vger.kernel.org
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

So no need to have code which never gets called in the driver.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Commit 1da30627 "drm: Add rotation value to
plane state" moved the rotation property to DRM core but only did the set
property part. This does the get property part as well.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Copypaste-fail from cleanup_planes. Reported by Tvrtko.

Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

When enabling atomic state object for this ioctl in

commit abd69c55
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Nov 25 23:50:05 2014 +0100

    drm: Handle atomic state properly in kms getfoo ioctl

I've forgotten to remove this hunk in one of the later revisions.
drm_encoder_get_crtc already does this.

Cc: Rob Clark <robdclark@gmail.com>
Cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

commit a8c6ecb3
Merge: 8dd0eb35 9eccca08
Author: Dave Airlie <airlied@redhat.com>
Date:   Mon Mar 9 19:58:30 2015 +1000

    Merge tag 'v4.0-rc3' into drm-next

managed to pick the wrong code to resolve the conflict and left us with
a mutex_lock(struct_mutex) without the mutex_unlock(struct_mutex) leading
to a deadlock. Fix the problem by recovering the correct code which doesn't
need the lock.

Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Currently tty_wait_until_sent may take up to twice as long as the
requested timeout while waiting for driver and hardware buffers to
drain.

Fix this by taking the remaining number of jiffies after waiting for
driver buffers to drain into account so that the timeout actually
becomes a maximum timeout as it is documented to be.

Note that this specifically implies tighter timings when closing a port
as a consequence of actually honouring the port closing-wait setting
for drivers relying on tty_wait_until_sent_from_close (e.g. via
tty_port_close_start).
Signed-off-by: NJohan Hovold <johan@kernel.org>
Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix overflow bug in tty_wait_until_sent on 64-bit machines, where an
infinite timeout (0) would be passed to the underlying tty-driver's
wait_until_sent-operation as a negative timeout (-1), causing it to
return immediately.

This manifests itself for example as tcdrain() returning immediately,
drivers not honouring the drain flags when setting terminal attributes,
or even dropped data on close as a requested infinite closing-wait
timeout would be ignored.

The first symptom  was reported by Asier LLANO who noted that tcdrain()
returned prematurely when using the ftdi_sio usb-serial driver.

Fix this by passing 0 rather than MAX_SCHEDULE_TIMEOUT (LONG_MAX) to the
underlying tty driver.

Note that the serial-core wait_until_sent-implementation is not affected
by this bug due to a lucky chance (comparison to an unsigned maximum
timeout), and neither is the cyclades one that had an explicit check for
negative timeouts, but all other tty drivers appear to be affected.

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Cc: stable <stable@vger.kernel.org>	# v2.6.12
Reported-by: NZIV-Asier Llano Palacios <asier.llano@cgglobal.com>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Make sure to handle an infinite timeout (0).

Note that wait_until_sent is currently never called with a 0-timeout
argument due to a bug in tty_wait_until_sent.

Fixes: dcf01050 ("USB: serial: add generic wait_until_sent
implementation")
Cc: stable <stable@vger.kernel.org>	# v3.10
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove incorrect and redundant wait_until_sent operation, which waits
for the driver buffer rather than any hardware buffers to drain,
something which is already taken care of by the tty layer (and
chars_in_buffer).
Signed-off-by: NJohan Hovold <johan@kernel.org>
Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix return from sprd_handle_irq() with spin_lock held.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This problem was taken care of three times already in
* b0de59b5 (TTY: do not update
  atime/mtime on read/write),
* 37b7f3c7 (TTY: fix atime/mtime
  regression), and
* b0b88565 (tty: fix up atime/mtime
  mess, take three)

But it still misses one point. As John Paul correctly points out, we
do not care about setting date. If somebody ever changes wall
time backwards (by mistake for example), tty timestamps are never
updated until the original wall time passes.

So check the absolute difference of times and if it large than "8
seconds or so", always update the time. That means we will update
immediatelly when changing time. Ergo, CAP_SYS_TIME can foul the
check, but it was always that way.

Thanks John for serving me this so nicely debugged.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Reported-by: NJohn Paul Perry <john_paul.perry@alcatel-lucent.com>
Cc: <stable@vger.kernel.org> # all, as b0b88565 was backported
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixed behaviour of get_mctrl() serial driver function as documented in:
https://www.kernel.org/doc/Documentation/serial/driver

Added device-tree properties 'dcd-override', 'dsr-override',
'cts-override', and 'ri-override' specific to the Synopsis 8250
DesignWare UART driver. Allows one to force Data Carrier Detect,
Clear To Send, and Data Set Ready signals to permanently be reported as
active. The Ring indicator can be forced to be reported as inactive.

It is possible that if modem control signalling is enabled on a port
that doesn't have these pins (e.g. - a simple two wire Tx/Rx port), the
driver can hang indefinitely waiting for the state to change. The new
DT properties allow the driver to ignore the state of these pins on
serial ports that don't support them, as recommended in the kernel
documentation.
Reviewed-by: NJD (Jiandong) Zheng <jdzheng@broadcom.com>
Signed-off-by: NJonathan Richardson <jonathar@broadcom.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

These quirk entries have the same effect as default
quirk entry, so we can just delete them.
Signed-off-by: NWang YanQing <udknight@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 8b5c913f
("serial: 8250_pci: Add WCH CH352 quirk to avoid Xscale detection")
trigger one redundant entry report message.

This patch fix it.
Reported-by: NRussell King <rmk@arm.linux.org.uk>
Signed-off-by: NWang YanQing <udknight@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

I'm still receiving reports to my email address, so let's point this
at the linux-serial mailing list instead.

Cc: <stable@vger.kernel.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 0aa525d1.

The conditional RX-FIFO read seems to cause spurious interrupts and we
see just:
|serial8250: too much work for irq29

The previous behaviour was "default" for decades and Marvell's 88f6282 SoC
might not be the only that relies on it. Therefore the Omap fix is
reverted for now.

Fixes: 0aa525d1 ("tty: serial: 8250_core: read only RX if there is
something in the FIFO")
Reported-By: NNicolas Schichan <nschichan@freebox.fr>
Debuged-By: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 6d01bb9d.

The exact same code was added in commit 3239fd31 (serial: of-serial: fetch
line number from DT) a few lined above. Doing this once should be enough.

Cc: Rob Herring <robh@kernel.org>
Signed-off-by: NBaruch Siach <baruch@tkos.co.il>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch marks baytrail_i2c_acquire() that it might sleep. Also it chages
while-loop to do-while and, though it is matter of taste, gives a chance to
check one more time before report a timeout.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

It seems the idea behind the cross-check is to prevent acquire semaphore when
there is no release callback and vice versa. Thus, patch fixes a typo.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

There is no need to export functions that are used as the callbacks in the
struct dw_i2c_dev. Otherwise we get the following warnings:

drivers/i2c/busses/i2c-designware-baytrail.c:63:5: warning: symbol 'baytrail_i2c_acquire' was not declared. Should it be static?
drivers/i2c/busses/i2c-designware-baytrail.c:114:6: warning: symbol 'baytrail_i2c_release' was not declared. Should it be static?

While here, do few indentation fixes, remove i2c_dw_eval_lock_support() from
functions exported to the modules and redundant assignment of local sem
variable.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

It seems we have same message for different return values in get_sem() and
baytrail_i2c_acquire(). I suspect this is just a typo, so this patch fixes it.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The patch converts hardcoded numerical constants to a named ones.

While here, align the variable name in get_sem() and reset_semaphore().
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The xhci in Intel Sunrisepoint and Cherryview platforms need a driver
workaround for a Stuck PME that might either block PME events in suspend,
or create spurious PME events preventing runtime suspend.

Workaround is to clear a internal PME flag, BIT(28) in a vendor specific
PMCTRL register at offset 0x80a4, in both suspend resume callbacks

Without this, xhci connected usb devices might never be able to wake up the
system from suspend, or prevent device from going to suspend (xhci d3)

Cc: <stable@vger.kernel.org>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>