The DP MST encoder config function never sets ddi_pll_sel, even though
its value is programmed in its ->pre_enable() hook. That used to work
because a new pipe_config was kzalloc'ed at every modeset, and the value
of zero selects the highest clock for the PLL. Starting with the commit
below, the value of ddi_pll_sel is preserved through modesets, and since
the correct value wasn't properly setup by the MST code, it could lead
to warnings and blank screens.

commit 8504c74c
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date:   Fri May 15 11:51:50 2015 +0300

    drm/i915: Preserve ddi_pll_sel when allocating new pipe_config

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91628
Cc: stable@vger.kernel.org # 7e6313a2 drm/i915: Don't use link_bw for PLL setup
Cc: stable@vger.kernel.org
Cc: Timo Aaltonen <tjaalton@ubuntu.com>
Cc: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Use port_clock instead of link_bw when picking the PLL parameters for
DP. link_bw may be zero with an eDP 1.4 sink that supports
DP_LINK_RATE_SET so we shouldn't use it for anything other than feed it
to the sink appropriately.

v2: Fix typo in commit message (Sivakumar)
Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
[Jani: cherry-picked from future.]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Commit 92122789 ("drm/i915: preserve SSC if previously set v3")
added code to intel_modeset_gem_init to override the SSC status read
from VBT with the SSC status set by BIOS.

However, intel_modeset_gem_init is invoked *after* intel_modeset_init,
which calls intel_setup_outputs, which *modifies* SSC status by way of
intel_init_pch_refclk. So unlike advertised, intel_modeset_gem_init
doesn't preserve the SSC status set by BIOS but whatever
intel_init_pch_refclk decided on.

This is a problem on dual gpu laptops such as the MacBook Pro which
require either a handler to switch DDC lines, or the discrete gpu
to proxy DDC/AUX communication: Both the handler and the discrete
gpu may initialize after the i915 driver, and consequently, an LVDS
connector may initially seem disconnected and the SSC therefore
is disabled by intel_init_pch_refclk, but on reprobe the connector
may turn out to be connected and the SSC must then be enabled.

Due to 92122789 however, the SSC is not enabled on reprobe since
it is assumed BIOS disabled it while in fact it was disabled by
intel_init_pch_refclk.

Also, because the SSC status is preserved so late, the preserved value
only ever gets used on resume but not on panel initialization:
intel_modeset_init calls intel_init_display which indirectly calls
intel_panel_use_ssc via multiple subroutines, *before* the BIOS value
overrides the VBT value in intel_modeset_gem_init (intel_panel_use_ssc
is the sole user of dev_priv->vbt.lvds_use_ssc).

Fix this by moving the code introduced by 92122789 from
intel_modeset_gem_init to intel_modeset_init before the invocation
of intel_setup_outputs and intel_init_display.

Add a DRM_DEBUG_KMS as suggested way back by Jani:
http://lists.freedesktop.org/archives/intel-gfx/2014-June/046666.html

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115Tested-by: NPaul Hordiienko <pvt.gord@gmail.com>
    [MBP  6,2 2010  intel ILK + nvidia GT216  pre-retina]
Tested-by: NWilliam Brown <william@blackhats.net.au>
    [MBP  8,2 2011  intel SNB + amd turks     pre-retina]
Tested-by: NLukas Wunner <lukas@wunner.de>
    [MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina]
Tested-by: NBruno Bierbaumer <bruno@bierbaumer.net>
    [MBP 11,3 2013  intel HSW + nvidia GK107  retina -- work in progress]
Fixes: 92122789 ("drm/i915: preserve SSC if previously set v3")
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

From B spec, DDI_E port belong to PowerWell 2, but
DDI_E share the powerwell_req/staus register bit with
DDI_A which belong to DDI_A_E_POWER_WELL.

In order to communicate with the connector on DDI-E, both
DDI_A_E_POWER_WELL and POWER_WELL_2 must be enabled.

Currently intel_dp_power_get(DDI_E) only enable
DDI_A_E_POWER_WELL, this patch will not only enable
DDI_a_E_POWER_WELL but also enable POWER_WELL_2.

This patch also fix the DDI-E hotplug function.
Signed-off-by: NXiong Zhang <xiong.y.zhang@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Enable eDP on DDI-E.

Also let's remove duplicated definitions to avoid later confusion.
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NXiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

There are OEMs using DDI-E out there,
so let's enable it.

Unfortunately there is no detection bit for DDI-E
So we need to rely on VBT for that.

I also need to give credits to Xiong since before seing
his approach to check info->support_* I was creating an ugly
vbt->ddie_sfuse_strap in order to propagate the ddi presence info

v2: Rebased as last patch in the series. since all other patches
in this series are needed for anything working propperly on DDI-E.

Credits-to: "Zhang, Xiong Y" <xiong.y.zhang@intel.com>
Cc: "Zhang, Xiong Y" <xiong.y.zhang@intel.com>
Reviewed-by: NXiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

DDI-E doesn't have the correspondent GMBUS pin.

We rely on VBT to tell us which one it being used instead.

The DVI/HDMI on shared port couldn't exist.

This patch isn't tested without hardware wchich has HDMI
on DDI-E.

v2: fix trailing whitespace
v3: MISSING_CASE take place of BUG()
Signed-off-by: NXiong Zhang <xiong.y.zhang@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

commit da2bc1b9
Author: Imre Deak <imre.deak@intel.com>
Date:   Thu Oct 23 19:23:26 2014 +0300

    drm/i915: add poweroff_late handler

introduced a regression on old platforms during hibernation. A workaround was
added in

commit ab3be73f
Author: Imre Deak <imre.deak@intel.com>
Date:   Mon Mar 2 13:04:41 2015 +0200

    drm/i915: gen4: work around hang during hibernation

using an explicit blacklist for the GENs/BIOS vendors where the issue was
reported. Later there we had reports of the same failure on platforms not on
this list.

To my best knowledge the correct thing to do is still to put the device to PCI
D3 state during hibernation, see [1] and [2] for the reasons. This also aligns
with our future plans to unify more the runtime and system suspend/resume
paths. Since an exact blacklist seems to be impractical (multiple GENs and
BIOS vendors are affected) apply the workaround on everything pre GEN6.

[1] http://lists.freedesktop.org/archives/intel-gfx/2015-February/060710.html
[2] https://lkml.org/lkml/2015/6/22/274

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=95061Reported-by: NIlya Tumaykin <itumaykin@gmail.com>
Reported-by: NDirk Griesbach <spamthis@freenet.de>
Reported-by: NPavel Machek <pavel@ucw.cz>
Reported-by: NMikko Rapeli <mikko.rapeli@iki.fi>
Tested-by: NMikko Rapeli <mikko.rapeli@iki.fi>
Reported-by: NPaul Bolle <pebolle@tiscali.nl>
CC: stable@vger.kernel.org
Signed-off-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

We are no longer checkling the DP link status on long hpd. We used to do
that from the .hot_plug() handler, but it was removed when MST got
introduced.

If there's no userspace we now fail to retrain the link if the sink
power is toggled (or cable yanked and replugged), meaning the user is
left staring at a blank screen. With the retraining put back that should
be fixed.

Also remove the leftover comment that referred to the old retraining
from .hot_plug().

Fixes a regression introduced in:
commit 0e32b39c
Author: Dave Airlie <airlied@redhat.com>
Date:   Fri May 2 14:02:48 2014 +1000

    drm/i915: add DP 1.2 MST support (v0.7)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89453Tested-by: NPalmer Dabbelt <palmer@dabbelt.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91407
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89461
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89594
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85641
Cc: Dave Airlie <airlied@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Since BIOS RC 1.4 it would enable CDCLK PLL during BIOS S3 resume, then
driver needs to set CDCLK to avoid display corruption if DPLL0 enabled.

References: https://bugs.freedesktop.org/show_bug.cgi?id=91697Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NCooper Chiou <cooper.chiou@intel.com>
Reviewed-by: NWei Shun Chang <wei.shun.chang@intel.com>
Tested-by: NGary Wang <gary.c.wang@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Gavin Hindman <gavin.hindman@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Xiong Y Zhang <xiong.y.zhang@intel.com>
Signed-off-by: NGary Wang <gary.c.wang@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

v2: fix one error found by checkpath.pl
v3: Add one ignored break for switch-case. DDI-E hotplug
    function doesn't work after updating drm-intel tree,
    I checked the code and found this missing which isn't
    the root cause for broke DDI-E hp.  The broken
    DDI-E hp function is fixed by "Adding DDI_E power
    well domain".
Signed-off-by: NXiong Zhang <xiong.y.zhang@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Tested-by: NTimo Aaltonen <timo.aaltonen@canonical.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The gtt.stolen_size field is of type size_t, and so should be printed
using %zu to avoid build warnings on either 32-bit and 64-bit builds.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

SKL-Y can now use the same programming for all VccIO values after an
adjustment to I_boost.  SKL-U DP table adjustments.

1. Remove SKL Y 0.95V from "SKL H and S" columns in all tables. The
   other SKL Y column removes the "0.85V VccIO" so it now applies to all
   voltages.

2. DP table changes SKL U 400mV+0db dword 0 value from 2016h to 201Bh.

3. DP table changes SKL U 600mv+0db dword 0 value from 2016h to 201Bh.

4. DP table increases I_boost to level 3 for SKL Y 400mv+9.5db.

v2: Fix compilation warnings as pointed by Paulo.

Reference: Graphics Spec Change r97962
Cc: Arthur Runyan <arthur.j.runyan@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
[Jani: reformatted commit message for shorter lines.]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

VBT version 196 increased the size of common_child_dev_config. The
parser code assumed that the size of this structure would not change.

The modified code now copies the amount needed based on the VBT version,
and emits a debug message if the VBT version is unknown (too new); since
the struct config block won't shrink in newer versions it should be
harmless to copy the maximum known size in such cases, so that's what we
do, but emitting the warning is probably sensible anyway.

In the longer run it might make sense to modify the parser code to use a
version/feature mapping, rather than hardcoding things like this, but
for now the variants are fairly manageable.

This fixes a regression introduced in

commit 75067dde
Author: Antti Koskipaa <antti.koskipaa@linux.intel.com>
Date:   Fri Jul 10 14:10:55 2015 +0300

    drm/i915: Per-DDI I_boost override

since that commit changed the child device config size without updating
the checks and memcpy.

v2: Stricter size checks

v3 by Jani:
- Keep the checks strict, and warnigns verbose, but keep going anyway.
- Take care to copy the max amount of child device config we can.
- Fix the messages.
Signed-off-by: NDavid Weinehall <david.weinehall@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This patch fixes the bug that SKL SKUs before B0 might return
HBR2 as supported even though it is not supposed to be enabled
on such platforms.

v2: optimize if else condition (Jani)
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
[Jani: minor whitespace fix.]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

commit 75067dde
Author: Antti Koskipaa <antti.koskipaa@linux.intel.com>
Date:   Fri Jul 10 14:10:55 2015 +0300

    drm/i915: Per-DDI I_boost override

increased size of union child_device_config without taking into account
the size check in parse_sdvo_device_mapping(). Switch the function over
to using the legacy struct only.

Fixes: 75067dde ("drm/i915: Per-DDI I_boost override")
Cc: Antti Koskipaa <antti.koskipaa@linux.intel.com>
Cc: David Weinehall <david.weinehall@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

- Added PLL algorithm for a new rev of G200e
- Removed the bandwidth limitation for the new G200e
Signed-off-by: NMathieu Larouche <mathieu.larouche@matrox.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

- Added support for the new deviceID for G200eW3
- Added PLL algorithm for the G200eW3
- Added some initialization code for G200eW3
Signed-off-by: NMathieu Larouche <mathieu.larouche@matrox.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Commit c48a11c7 ("netvm: propagate page->pfmemalloc to skb") added
checks for page->pfmemalloc to __skb_fill_page_desc():

        if (page->pfmemalloc && !page->mapping)
                skb->pfmemalloc = true;

It assumes page->mapping == NULL implies that page->pfmemalloc can be
trusted.  However, __delete_from_page_cache() can set set page->mapping
to NULL and leave page->index value alone.  Due to being in union, a
non-zero page->index will be interpreted as true page->pfmemalloc.

So the assumption is invalid if the networking code can see such a page.
And it seems it can.  We have encountered this with a NFS over loopback
setup when such a page is attached to a new skbuf.  There is no copying
going on in this case so the page confuses __skb_fill_page_desc which
interprets the index as pfmemalloc flag and the network stack drops
packets that have been allocated using the reserves unless they are to
be queued on sockets handling the swapping which is the case here and
that leads to hangs when the nfs client waits for a response from the
server which has been dropped and thus never arrive.

The struct page is already heavily packed so rather than finding another
hole to put it in, let's do a trick instead.  We can reuse the index
again but define it to an impossible value (-1UL).  This is the page
index so it should never see the value that large.  Replace all direct
users of page->pfmemalloc by page_is_pfmemalloc which will hide this
nastiness from unspoiled eyes.

The information will get lost if somebody wants to use page->index
obviously but that was the case before and the original code expected
that the information should be persisted somewhere else if that is
really needed (e.g.  what SLAB and SLUB do).

[akpm@linux-foundation.org: fix blooper in slub]
Fixes: c48a11c7 ("netvm: propagate page->pfmemalloc to skb")
Signed-off-by: NMichal Hocko <mhocko@suse.com>
Debugged-by: NVlastimil Babka <vbabka@suse.com>
Debugged-by: NJiri Bohac <jbohac@suse.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Miller <davem@davemloft.net>
Acked-by: NMel Gorman <mgorman@suse.de>
Cc: <stable@vger.kernel.org>	[3.6+]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

We apparantly get a hotplug irq before we've initialised
modesetting,

[drm] Loading R100 Microcode
BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [<c125f56f>] __mutex_lock_slowpath+0x23/0x91
*pde = 00000000
Oops: 0002 [#1]
Modules linked in: radeon(+) drm_kms_helper ttm drm i2c_algo_bit backlight pcspkr psmouse evdev sr_mod input_leds led_class cdrom sg parport_pc parport floppy intel_agp intel_gtt lpc_ich acpi_cpufreq processor button mfd_core agpgart uhci_hcd ehci_hcd rng_core snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm usbcore usb_common i2c_i801 i2c_core snd_timer snd soundcore thermal_sys
CPU: 0 PID: 15 Comm: kworker/0:1 Not tainted 4.2.0-rc7-00015-gbf674028 #111
Hardware name: MicroLink                               /D850MV                         , BIOS MV85010A.86A.0067.P24.0304081124 04/08/2003
Workqueue: events radeon_hotplug_work_func [radeon]
task: f6ca5900 ti: f6d3e000 task.ti: f6d3e000
EIP: 0060:[<c125f56f>] EFLAGS: 00010282 CPU: 0
EIP is at __mutex_lock_slowpath+0x23/0x91
EAX: 00000000 EBX: f5e900fc ECX: 00000000 EDX: fffffffe
ESI: f6ca5900 EDI: f5e90100 EBP: f5e90000 ESP: f6d3ff0c
 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
CR0: 8005003b CR2: 00000000 CR3: 36f61000 CR4: 000006d0
Stack:
 f5e90100 00000000 c103c4c1 f6d2a5a0 f5e900fc f6df394c c125f162 f8b0faca
 f6d2a5a0 c138ca00 f6df394c f7395600 c1034741 00d40000 00000000 f6d2a5a0
 c138ca00 f6d2a5b8 c138ca10 c1034b58 00000001 f6d40000 f6ca5900 f6d0c940
Call Trace:
 [<c103c4c1>] ? dequeue_task_fair+0xa4/0xb7
 [<c125f162>] ? mutex_lock+0x9/0xa
 [<f8b0faca>] ? radeon_hotplug_work_func+0x17/0x57 [radeon]
 [<c1034741>] ? process_one_work+0xfc/0x194
 [<c1034b58>] ? worker_thread+0x18d/0x218
 [<c10349cb>] ? rescuer_thread+0x1d5/0x1d5
 [<c103742a>] ? kthread+0x7b/0x80
 [<c12601c0>] ? ret_from_kernel_thread+0x20/0x30
 [<c10373af>] ? init_completion+0x18/0x18
Code: 42 08 e8 8e a6 dd ff c3 57 56 53 83 ec 0c 8b 35 48 f7 37 c1 8b 10 4a 74 1a 89 c3 8d 78 04 8b 40 08 89 63
Reported-and-Tested-by: NMeelis Roos <mroos@linux.ee>
Signed-off-by: NDave Airlie <airlied@redhat.com>

It appears some MST docks are worse than other, but the only
way to know is to see the sw revisions in here, so dump
the branch OUI so we can look at the sw revision.

v2: Thierry made me feel guilty, so I parsed the branch
OUI.
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Meelis and Helge reported that 3a9ad0b4 ("PCI: Add pci_bus_addr_t")
caused HPMCs on A500 and hangs on rp5470.

PA-RISC does not set ARCH_DMA_ADDR_T_64BIT, even for 64-bit kernels, so
prior to 3a9ad0b4, we always used 32-bit PCI addresses.  After
3a9ad0b4, we do use 64-bit PCI addresses in 64-bit kernels, and
apparently there's some PA-RISC problem related to them.

Fixes: 3a9ad0b4 ("PCI: Add pci_bus_addr_t")
Link: http://lkml.kernel.org/r/alpine.LRH.2.11.1507260929000.30065@math.ut.eeReported-by: NMeelis Roos <mroos@linux.ee>
Reported-by: NHelge Deller <deller@gmx.de>
Tested-by: NHelge Deller <deller@gmx.de>
Based-on-idea-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>
CC: stable@vger.kernel.org	# v3.19+

GPIOF_IN flag was lost in:
Commit 633a21d8("input: gpio_keys_polled: Add support for GPIO
descriptors").

Without this flag, legacy code path (for non-descriptor GPIO declarations)
would configure GPIO as output (0 meaning GPIOF_DIR_OUT | GPIOF_INIT_LOW).

Cc: stable@vger.kernel.org
Signed-off-by: NVincent Pelletier <plr.vincent@gmail.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Commit 6dd74782 ("ARM: imx: move timer resources into a structure")
moved initialization parameters into a data structure, but neglected to set
the irq field in that data structure for non-DT boots. This causes the system
to hang if a non-DT boot is attempted.

Fixes: 6dd74782 ("ARM: imx: move timer resources into a structure")
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: http://lkml.kernel.org/r/1440066441-13930-1-git-send-email-linux@roeck-us.netSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

This patch add support for Two Dimensional Animation and Compositing
Engine (2D-ACE) on the Freescale SoCs.

2D-ACE is a Freescale display controller. 2D-ACE describes
the functionality of the module extremely well its name is a value
that cannot be used as a token in programming languages.
Instead the valid token "DCU" is used to tag the register names and
function names.

The Display Controller Unit (DCU) module is a system master that
fetches graphics stored in internal or external memory and displays
them on a TFT LCD panel. A wide range of panel sizes is supported
and the timing of the interface signals is highly configurable.
Graphics are read directly from memory and then blended in real-time,
which allows for dynamic content creation with minimal CPU
intervention.

The features:
(1) Full RGB888 output to TFT LCD panel.
(2) Blending of each pixel using up to 4 source layers
dependent
on size of panel.
(3) Each graphic layer can be placed with one pixel resolution
in either axis.
(4) Each graphic layer support RGB565 and RGB888 direct colors
without alpha channel and BGRA8888 BGRA4444 ARGB1555 direct
colors
with an alpha channel and YUV422 format.
(5) Each graphic layer support alpha blending with 8-bit
resolution.
This is a simplified version, only one primary plane, one
framebuffer, one crtc, one connector and one encoder for TFT
LCD panel.
Signed-off-by: NAlison Wang <b18965@freescale.com>
Signed-off-by: NXiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: NJianwei Wang <jianwei.wang.chn@gmail.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The TI crossbar irqchip doesn't provides any facility to configure the
wakeup sources, but the conversion to hierarchical irqdomains set the
irq_set_wake callback to irq_chip_set_wake_parent. The parent chip
(OMAP wakeupgen) has no irq_set_wake function either so the call will
fail with -ENOSYS. As a result the irq_set_wake() call in the resume
path will trigger an 'Unbalanced wake disable' warning.

Before the conversion the GIC irqchip was the top level irqchip and
correctly flagged with IRQCHIP_SKIP_SET_WAKE.

Restore the correct behaviour by removing the irq_set_type callback
from the crossbar irqchip and set the IRQCHIP_SKIP_SET_WAKE flag which
lets the irq_set_irq_wake() call from the driver succeed.

[ tglx: Massaged changelog ]

Fixes: 783d3186 ('irqchip: crossbar: Convert dra7 crossbar...')
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: <linux@arm.linux.org.uk>
Cc: <nsekhar@ti.com>
Cc: <jason@lakedaemon.net>
Cc: <balbi@ti.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: <tony@atomide.com>
Cc: <marc.zyngier@arm.com>
Cc: stable@vger.kernel.org # 4.1
Link: http://lkml.kernel.org/r/1439554830-19502-7-git-send-email-grygorii.strashko@ti.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

The ARM GIC requires that all interrupts which are not used as a
wakeup source have to be masked during suspend.

The conversion of the crossbar irqchip to hierarchical irq domains
failed to mark the crossbar irqchip with the IRQCHIP_MASK_ON_SUSPEND
flag and therefor broke the suspend requirement of the GIC.

Before the conversion the flags were visible because the GIC was the
top level irqchip. After the conversion the crossbar irqchip is the
top level irq chip whose flags are evaluated in suspend_device_irq().
As the flag is not set the masking of the non-wakeup irqs is not
invoked which breaks suspend.

Add the IRQCHIP_MASK_ON_SUSPEND flag to the crossbar irqchip, so the
GIC interrupts get masked properly.

[ tglx: Massaged changelog ]

Fixes: 783d3186 ('irqchip: crossbar: Convert dra7 crossbar...')
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: <linux@arm.linux.org.uk>
Cc: <nsekhar@ti.com>
Cc: <jason@lakedaemon.net>
Cc: <balbi@ti.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: <tony@atomide.com>
Cc: <marc.zyngier@arm.com>
Cc: stable@vger.kernel.org # 4.1
Link: http://lkml.kernel.org/r/1439554830-19502-6-git-send-email-grygorii.strashko@ti.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

The conversion of the crossbar irqchip to hierarchical irq domains
failed to provide a mechanism to properly set the trigger type of an
interrupt.

The crossbar irq chip itself has no mechanism and therefor no
irq_set_type() callback. The code before the conversion relayed the
trigger configuration directly to the underlying GIC.

Restore the correct behaviour by setting the crossbar irq_set_type
callback to irq_chip_set_type_parent(). This propagates the
set_trigger() call to the underlying GIC irqchip.

[ tglx: Massaged changelog ]

Fixes: 783d3186 ('irqchip: crossbar: Convert dra7 crossbar...')
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: <linux@arm.linux.org.uk>
Cc: <nsekhar@ti.com>
Cc: <jason@lakedaemon.net>
Cc: <balbi@ti.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: <tony@atomide.com>
Cc: <marc.zyngier@arm.com>
Cc: stable@vger.kernel.org # 4.1
Link: http://lkml.kernel.org/r/1439554830-19502-4-git-send-email-grygorii.strashko@ti.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

We should not assume any particular hardware topology.  Commit d0751b98
("PCI: Add dev->has_secondary_link to track downstream PCIe links") relied
on the assumption that every PCIe hierarchy is rooted at a Root Port.  But
we can't rely on any assumption about what hardware we will find; we just
have to deal with the world as it is.

On some platforms, PCIe devices (endpoints, switch upstream ports, etc.)
appear directly on the root bus, and there is no Root Port in the PCI bus
hierarchy.  For example, Meelis observed these top-level devices on a
Sparc V245:

  0000:02:00.0 PCI bridge to [bus 03-0d]    Switch Upstream Port
  0001:02:00.0 PCI bridge to [bus 03]       PCIe to PCI/PCI-X Bridge

These devices *look* like they have links going upstream, but there really
are no upstream devices.

In set_pcie_port_type(), we used the parent device to figure out which side
of a switch port has a link, so if the parent device did not exist, we
dereferenced a NULL parent pointer.

Check whether the parent device exists before dereferencing it.

Meelis observed this oops on Sparc V245 and T2000.  Ben Herrenschmidt says
this is also possible on IBM PowerVM guests on PowerPC.

[bhelgaas: changelog, comment]
Link: http://lkml.kernel.org/r/alpine.LRH.2.20.1508122118210.18637@math.ut.eeReported-by: NMeelis Roos <mroos@linux.ee>
Tested-by: NMeelis Roos <mroos@linux.ee>
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: Rafał Miłecki <zajec5@gmail.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/11020/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Current code assigns 0 to variable 'err', which makes mantis_dma_init()
to return success even if mantis_alloc_buffers() fails.

Fix it by checking the return value from mantis_alloc_buffers() and
propagating it in the case of error.
Reported-by: NRUC_Soft_Sec <zy900702@163.com>
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This reverts commit 9869da5b.

The current code is not mature enough, the API should allow a single
protocol to be specified. Also, the current code contains heuristics
that will depend on module load order.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Acked-by: NAntti Seppälä <a.seppala@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This reverts commit 1d971d92.

The current code is not mature enough, the API should allow a single
protocol to be specified. Also, the current code contains heuristics
that will depend on module load order.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Acked-by: NAntti Seppälä <a.seppala@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This reverts commit a0466f15.

The current code is not mature enough, the API should allow a single
protocol to be specified. Also, the current code contains heuristics
that will depend on module load order.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Acked-by: NAntti Seppälä <a.seppala@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This reverts commit cf257e28.

The current code is not mature enough, the API should allow a single
protocol to be specified. Also, the current code contains heuristics
that will depend on module load order.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Acked-by: NAntti Seppälä <a.seppala@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This reverts commit 0d830b2d.

The current code is not mature enough, the API should allow a single
protocol to be specified. Also, the current code contains heuristics
that will depend on module load order.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Acked-by: NAntti Seppälä <a.seppala@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This reverts commit 2e4ebde2.

The current code is not mature enough, the API should allow a single
protocol to be specified. Also, the current code contains heuristics
that will depend on module load order.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Acked-by: NAntti Seppälä <a.seppala@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This reverts commit da7ee60b.

The current code is not mature enough, the API should allow a single
protocol to be specified. Also, the current code contains heuristics
that will depend on module load order.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Acked-by: NAntti Seppälä <a.seppala@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This patch removes TP3 support on CHV since there is no support
for HBR2 on this platform.

v2: rename the function to indicate it checks source rates (Jani)
v3: update comment to indicate TP3 dependency on HBR2 supported
    hardware (Jani)

Cc: stable@vger.kernel.org # v4.1+
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
[Jani: fixed a couple of checkpatch warnings.]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This patch removes 5.4Gbps from supported link rate for CHV since
it is not supported in it.

v2: change the ordering for better readability (Ville)

Cc: stable@vger.kernel.org # v4.1+
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>