Commit adacb228 ("drm: Exynos: Respect framebuffer pitch for
FIMD/Mixer") fixed the buffer size calculation by using the FB
pitch value but later commit 26b9c2813ede1 ("drm/exynos: remove
struct *_win_data abstraction on planes") added a regression so
fix the buffer size calculation again.

Tested on Chromebook Snow / Peach Pit.

Fixes: 26b9c2813ede1 ("drm/exynos: remove struct *_win_data abstraction on planes")
Signed-off-by: NDaniel Stone <daniels@collabora.com>
Tested-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

After adding display power domain for Exynos5250 in commit
2d2c9a8d ("ARM: dts: add display power domain for exynos5250") the
display on Chromebook Snow and others stopped working after boot.

The reason for this suggested Andrzej Hajda: the DP clock was disabled.
This clock is required by Display Port and is enabled by bootloader.
However when FIMD driver probing was deferred, the display power domain
was turned off. This effectively reset the value of DP clock enable
register.

When exynos-dp is later probed, the clock is not enabled and display is
not properly configured:

exynos-dp 145b0000.dp-controller: Timeout of video streamclk ok
exynos-dp 145b0000.dp-controller: unable to config video

Fixes: 2d2c9a8d ("ARM: dts: add display power domain for exynos5250")
Cc: <stable@vger.kernel.org>
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Reported-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

>From the commit "drm/exynos: fix the execution order in FIMD
initialization" (598285bfdce46d7c47632a2ba4b980f60be4a677), the error
checking code is removed improperly. This patch fix the regression.
Signed-off-by: NHyungwon Hwang <human.hwang@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Because the helper function which calls this callback checks whether
it is registered or not. It is not necessary if it does nothing.
So it would be better to remove the function for clarity.
Signed-off-by: NHyungwon Hwang <human.hwang@samsung.com>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Calculation ratio from exynos_drm plane codes, then each hw drivers can
use it without extra operation. Also this fixes width and height of
source used for actual crtc shown via screen.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

It's more reasonable to use src_x and src_y to represent source as
counterpart of destination(crtc). Already we are using src_width and
src_height for width and height of source.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

While the VP (video processor) supports arbitrary scaling
of its input, the mixer just supports a simple 2x (line
doubling) scaling. Expose this functionality and exit
early when an unsupported scaling configuration is
encountered.

This was tested with modetest's DRM plane test (from
the libdrm test suite) on an Odroid-X2 (Exynos4412).

v2: Put if- and return-statement on different lines.
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de>
Acked-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The messages are redundant since 'check_fb_gem_memory_type'
already prints out exactly the same string when it fails.
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de>
Acked-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Use the correct spelling for 'progressive'.
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de>
Acked-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

As for now there is no validation of incoming buffer
enqueue request as far as the gem buffers are being
concerned. This might lead to some undesired cases
when the driver tries to operate on invalid buffers
(wiht no valid gem object handle i.e.).
Add some basic checks to rule out those potential issues.
Signed-off-by: NBeata Michalska <b.michalska@samsung.com>
[mszyprow: rebased onto v4.0-rc1 and adapted to recent ipp changes]
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The goal of the change is to make sure we send the vblank event on the
current vblank. My hope is to fix any races that might be causing flicker.
After this change I only see a flicker in the transition plymouth and
X11.

Simplified the code by tracking vblank events on a per-crtc basis. This
allowed me to remove all error paths from the callback. It also allowed
me to remove the vblank wait from the callback.
Signed-off-by: NMandeep Singh Baines <msb@chromium.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

These functions were already removed by previous cleanup work, but these
ones were left behind.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Acked-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The .destroy() callback for exynos can be replaced by drm_plane_cleanup().
The only extra operation on exynos_plane_destroy() was a call to
exynos_plane_disable() but the plane is already disabled by a earlier call
to drm_framebuffer_remove().
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

We already set each plane zpos at init, after that changes to zpos are
not expected. This patch turns zpos into a read-only property so now it is
impossible to set zpos.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Usually userspace don't want to have two overlay planes on the same zpos
so this change assign a different zpos for each plane. Before this change
a zpos of value zero was created for all planes so the userspace had to
set up the zpos of every plane it wanted to use.

Also all places that were storing zpos positions are now unsigned int.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

struct {fimd,mixer,vidi}_win_data was just keeping the same data
as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
directly.

It changes how planes are created and remove .win_mode_set() callback
that was only filling all *_win_data structs.

v2: check for return of exynos_plane_init()
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

None of the exynos crtc drivers implements win_enable() so remove it for
better clarity of the code.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

XR24 planes were not shown properly, so now set the right registers
to correctly enable displaying these planes.

It also moves the alpha register settings to fimd_win_set_pixfmt()
to keep all pixel format stuff together.

v2: remove leftover var alpha
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Commit 1daa4303 ("net/mlx4_core: Deprecate error message at
ConnectX-2 cards startup to debug") did the deprecation only for port 1
of the card. Need to deprecate for port 2 as well.

Fixes: 1daa4303 ("net/mlx4_core: Deprecate error message at ConnectX-2 cards startup to debug")
Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: NAmir Vadai <amirv@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

mvneta_adjust_link() is a callback for of_phy_connect() and should
not be called directly. The result of calling it directly is as below:
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

On V2 devices the DualPoint Stick reports bare packets, these should be
reported via the "AlpsPS/2 ALPS DualPoint Stick" dev2 evdev node, which also
has the INPUT_PROP_POINTING_STICK propbit set.

Note that since there is no way to distinguish these packets from an external
PS/2 mouse (insofar as these laptops have an external PS/2 port) this means
that we will be reporting PS/2 mouse events via this evdev node too, as we've
been doing in kernel 3.19 and older.

This has been tested on a Dell Latitude D620 and a Dell Latitude E6400,
which both have a V2 touchpad + a DualPoint Stick which reports bare packets.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Bare packets should be reported via the same evdev device independent on
whether they are detected on the beginning of a packet or in the middle
of a packet.

This has been tested on a Dell Latitude E6400, where the DualPoint Stick
reports bare packets, which get reported via dev3 when the touchpad is
idle, and via dev2 when the touchpad and stick are used simultaneously.

This commit fixes this inconsistency by always reporting bare packets via
dev3. Note that since the come from a DualPoint Stick they really should be
reported via dev2, this gets fixed in a later commit.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Reference the power domain incase vop power down when
in use.
Signed-off-by: NMark Yao <yzq@rock-chips.com>

drm/rockchip already has support for disabling all displays on suspend
and enabling them on resume.

Disable automatic VT switching on suspend by the pm console tracking
layer.

Tested on veyron, used `echo mem > sys/power/state`
  => verified no VT switch
Reviewed-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NCaesar Wang <wxt@rock-chips.com>

Register connectors with userspace after all components are bound.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Reviewed-by: NDominik Behr <dbehr@chromium.org>

drm_connector_get_name -> connector->name
This patch is necessary to make X11 see screens it seems.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

The function disables the dclk at the beginning, so don't simply return
when an error happens, but instead enable the clock again, so that
enable and disable calls are balanced.

ret_clk is introduced to hold the clk_enable result and not mangle the
original error code.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NDaniel Kurtz <djkurtz@chromium.org>

xen-netfront limits transmitted skbs to be at most 44 segments in size. However,
GSO permits up to 65536 bytes, which means a maximum of 45 segments of 1448
bytes each. This slight reduction in the size of packets means a slight loss in
efficiency.

Since c/s 9ecd1a75, xen-netfront sets gso_max_size to
    XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER,
where XEN_NETIF_MAX_TX_SIZE is 65535 bytes.

The calculation used by tcp_tso_autosize (and also tcp_xmit_size_goal since c/s
6c09fa09) in determining when to split an skb into two is
    sk->sk_gso_max_size - 1 - MAX_TCP_HEADER.

So the maximum permitted size of an skb is calculated to be
    (XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER) - 1 - MAX_TCP_HEADER.

Intuitively, this looks like the wrong formula -- we don't need two TCP headers.
Instead, there is no need to deviate from the default gso_max_size of 65536 as
this already accommodates the size of the header.

Currently, the largest skb transmitted by netfront is 63712 bytes (44 segments
of 1448 bytes each), as observed via tcpdump. This patch makes netfront send
skbs of up to 65160 bytes (45 segments of 1448 bytes each).

Similarly, the maximum allowable mtu does not need to subtract MAX_TCP_HEADER as
it relates to the size of the whole packet, including the header.

Fixes: 9ecd1a75 ("xen-netfront: reduce gso_max_size to account for max TCP header")
Signed-off-by: NJonathan Davies <jonathan.davies@citrix.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This adds support for the AM-800480R3TMQW-A1H 7" 800x480 panel to the
DRM simple panel driver.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NThierry Reding <treding@nvidia.com>

The HannStar HSD070PWW1 LVDS panel data sheet lists allowed ranges
additionally to the typical values for pixel clock rate (64.3-82 MHz)
and blanking intervals (54-681 clock cycles horizontally, 3-23 lines
vertically).

This patch replaces this panel's display mode with the display timing
information to describe acceptable timings. Since the HSYNC and VSYNC
are unused, the distribution between front porches, back porches, and
sync pulse lengths was chosen at will.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NThierry Reding <treding@nvidia.com>

The simple panel driver's ->get_modes() implementation calculates the
display mode list from the typical timings and the ->get_timings()
implementation returns the timings to the connected encoder for mode
validation and fixup.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
[treding@nvidia.com: select VIDEOMODE_HELPERS]
Signed-off-by: NThierry Reding <treding@nvidia.com>

This adds support for the COM43H4M85ULC 3.7" 800x480 panel to the
DRM simple panel driver.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This patch adds the bus_format field to the GPG482739QS5 panel structure.
Signed-off-by: NPhilipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

The AUO b101ean01 panel is a 10.1" 1280x800 panel which can be supported
by the simple panel driver.
Signed-off-by: NHuang Lin <hl@rock-chips.com>
Reviewed-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>

The Innolux ZJ070NA-01P is a 7.0" TFT LCD panel with an integrated LED
backlight unit.

This panel is used on the Technexion Toucan.
Signed-off-by: NMichael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: NThierry Reding <treding@nvidia.com>

The Innolux AT043TN24 4.3" WQVGA TFT LCD panel.
This panel with backlight is found in PDA 4.3" LCD screen (TM43xx series for
instance).
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

The Shelly SCA07010-BFN-LNN is a 7.0" WVGA TFT LCD panel.
This panel with backlight is found in PDA 7" LCD screen (TM70xx series for
instance).
Signed-off-by: NBoris BREZILLON <boris.brezillon@free-electrons.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This panel is used by the Nyan Blaze board and can be supported by the
simple-panel driver.
Signed-off-by: NStéphane Marchesin <marcheu@chromium.org>
[tomeu.vizoso@collabora.com: add device tree binding document]
Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Acked-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Properly verify that the resulting page aligned end address is larger
than both the start address and the length of the memory area requested.

Both the start and length arguments for ib_umem_get are controlled by
the user. A misbehaving user can provide values which will cause an
integer overflow when calculating the page aligned end address.

This overflow can cause also miscalculation of the number of pages
mapped, and additional logic issues.

Addresses: CVE-2014-8159
Cc: <stable@vger.kernel.org>
Signed-off-by: NShachar Raindel <raindel@mellanox.com>
Signed-off-by: NJack Morgenstein <jackm@mellanox.com>
Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NRoland Dreier <roland@purestorage.com>

As there isn't a way for the firmware on the Nyan Chromebooks to hand
over the display to the kernel, and the kernel isn't redoing the whole
configuration at present.

With this patch, the SOR is brought to a known state and we get correct
display on every boot.
Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Name the fields of the SOR_SEQ_CTL register consistently.
Signed-off-by: NThierry Reding <treding@nvidia.com>