Existing helpers add support upto HBR2. This patch
adds support for HBR3 rate (8.1 Gbps) introduced as
part of DP 1.4 specification.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1516660991-20697-1-git-send-email-manasi.d.navare@intel.com

Change reservation_object_get_fences_rcu to make the exclusive fence
pointer optional.

If not specified the exclusive fence is put into the fence array as
well.

This is helpful for a couple of cases where we need all fences in a
single array.
Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180110125341.3618-1-christian.koenig@amd.com

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-15-ville.syrjala@linux.intel.comAcked-by: NShawn Guo <shawnguo@kernel.org>
Reviewed-by: NThierry Reding <treding@nvidia.com>

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-14-ville.syrjala@linux.intel.comReviewed-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

No functional changes as the code already uses crtc_state->mode
to populate the clip, which is also what drm_mode_get_hv_timing()
uses.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

v2: Rebase due to tegra_plane_state_add() relocating to plane.c

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-tegra@vger.kernel.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-13-ville.syrjala@linux.intel.com

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-12-ville.syrjala@linux.intel.comReviewed-by: NThierry Reding <treding@nvidia.com>

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

No functional changes as the code already uses crtc_state->mode
to populate the clip, which is also what drm_mode_get_hv_timing()
uses.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: nouveau@lists.freedesktop.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-11-ville.syrjala@linux.intel.comReviewed-by: NThierry Reding <treding@nvidia.com>

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Archit Taneja <architt@codeaurora.org>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-10-ville.syrjala@linux.intel.comReviewed-by: NArchit Taneja <architt@codeaurora.org>
Reviewed-by: NThierry Reding <treding@nvidia.com>

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

No functional changes as the code already uses crtc_state->mode
to populate the clip, which is also what drm_mode_get_hv_timing()
uses.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: linux-amlogic@lists.infradead.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-9-ville.syrjala@linux.intel.comReviewed-by: NThierry Reding <treding@nvidia.com>

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

No functional changes as the code already uses crtc_state->mode
to populate the clip, which is also what drm_mode_get_hv_timing()
uses.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: CK Hu <ck.hu@mediatek.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-8-ville.syrjala@linux.intel.comAcked-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: NThierry Reding <treding@nvidia.com>

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-7-ville.syrjala@linux.intel.comAcked-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: NThierry Reding <treding@nvidia.com>

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-6-ville.syrjala@linux.intel.comReviewed-by: NThierry Reding <treding@nvidia.com>

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Brian Starkey <brian.starkey@arm.com>
Cc: Mali DP Maintainers <malidp@foss.arm.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-5-ville.syrjala@linux.intel.comAcked-by: NLiviu Dudau <liviu.dudau@arm.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Brian Starkey <brian.starkey@arm.com>
Cc: Mali DP Maintainers <malidp@foss.arm.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-4-ville.syrjala@linux.intel.comAcked-by: NLiviu Dudau <liviu.dudau@arm.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
No functional changes since pipe_src_w/h are already filled via
drm_mode_get_hv_timing().

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-3-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NThierry Reding <treding@nvidia.com>

In order to guarantee that pipe_src_w/h matches the user mode h/vdisplay
we must not adjust pipe_src_w to accommodate double wide/dual link.
Instead just reject the mode outright.

This will allows us to rely on crtc_state->mode for plane clipping.

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-2-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NThierry Reding <treding@nvidia.com>

Fixes the following build warnings:
In file included from ../drivers/gpu/drm/sun4i/sun8i_mixer.h:18:0,
                 from ../drivers/gpu/drm/sun4i/sun8i_vi_scaler.h:13,
                 from ../drivers/gpu/drm/sun4i/sun8i_vi_scaler.c:12:
../drivers/gpu/drm/sun4i/sunxi_engine.h:36:16: warning: ‘struct drm_crtc_state’ declared inside parameter list will not be visible outside of this definition or declaration
         struct drm_crtc_state *old_state);
                ^~~~~~~~~~~~~~
../drivers/gpu/drm/sun4i/sunxi_engine.h:53:15: warning: ‘struct drm_crtc_state’ declared inside parameter list will not be visible outside of this definition or declaration
        struct drm_crtc_state *state);
               ^~~~~~~~~~~~~~
In file included from ../drivers/gpu/drm/sun4i/sun8i_mixer.h:18:0,
                 from ../drivers/gpu/drm/sun4i/sun8i_ui_scaler.h:12,
                 from ../drivers/gpu/drm/sun4i/sun8i_ui_scaler.c:12:
../drivers/gpu/drm/sun4i/sunxi_engine.h:36:16: warning: ‘struct drm_crtc_state’ declared inside parameter list will not be visible outside of this definition or declaration
         struct drm_crtc_state *old_state);
                ^~~~~~~~~~~~~~
../drivers/gpu/drm/sun4i/sunxi_engine.h:53:15: warning: ‘struct drm_crtc_state’ declared inside parameter list will not be visible outside of this definition or declaration
        struct drm_crtc_state *state);
               ^~~~~~~~~~~~~~

Fixes: 6b8562c8 ("drm/sun4i: engine: Create an atomic_begin
callback")
Fixes: 656e5f65 ("drm/sun4i: engine: Add a custom crtc
atomic_check")
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180122174306.231609-1-seanpaul@chromium.org

A couple more return value fixes which Philippe brought up during our
previous review.
Suggested-by: NPhilippe CORNU <philippe.cornu@st.com>
Reviewed-by: NPhilippe Cornu <philippe.cornu@st.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180117213751.54668-1-seanpaul@chromium.org

If we try to read the backend registers while it fetches the new values, we
end up with the value of some random register instead of the one we asked
for.

In order to prevent that, let's make sure that the very first thing we do
during our atomic modesetting is to let the commit bit come to a rest.

We don't have to worry about anything else since the only time we will
trigger a new transaction is during the atomic_commit which comes much
later.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/35604307e5bde2b85c674de79fa7c4d55700f085.1516613040.git-series.maxime.ripard@free-electrons.com

During a hardware commit, the commit bit in the backend will only be
cleared if the TCON is enabled. Use the runtime_pm variant of the
atomic_commit_tail hook that makes sure that the CRTC, our TCON, is enabled
when we perform an atomic_commit.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bde95faff2078f63e9af99c3abee5360b9050fd1.1516613040.git-series.maxime.ripard@free-electrons.com

Now that we have everything in place, we can start enabling the frontend.
This is more difficult than one would assume since there can only be one
plane using the frontend per-backend.

We therefore need to make sure that the userspace will not try to setup
multiple planes using it, since that would be impossible. In order to
prevent that, we can create an atomic_check callback that will check that
only one plane will effectively make use of the frontend in a given
configuration, and will toggle the switch in that plane state so that the
proper setup function can do their role.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/278e6c514a8311750fe627c7f28d58b3e2cbd825.1516613040.git-series.maxime.ripard@free-electrons.com

Now that we have a driver, we can make use of it. This is done by
adding a flag to our custom plane state that will trigger whether we should
use the frontend on that particular plane or not.

The rest is just plumbing to set up the backend to not perform the DMA but
receive its data from the frontend.

Note that we're still not making any use of the frontend itself, as no one
is setting the flag yet.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/cdffc25eab2d817820cc78cbd24f1f4b99902014.1516613040.git-series.maxime.ripard@free-electrons.com

The display frontend is an hardware block that can be used to implement
some more advanced features like hardware scaling or colorspace
conversions. It can also be used to implement the output format of the VPU.

Let's create a minimal driver for it that will only enable the hardware
scaling features.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/029cdc3478bf89d422f5e8d9e600baf5e48ce4db.1516613040.git-series.maxime.ripard@free-electrons.com

We have to implement some display engine specific behaviours in
atomic_begin. Let's add a function for that.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/44110951ae0cc13767fefc7fc1d9e2ec782d0a40.1516613040.git-series.maxime.ripard@free-electrons.com

In some cases, the display engine needs to apply some quirks during the
VBLANK event. In the Display Engine 1.0 case for example, we can only
disable the frontend once the backend has been, which is at VBLANK.

Let's introduce a callback that can be implemented by the various engines.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7c298d43aa1500196aa5d15d7a7c0f228c7a6f3c.1516613040.git-series.maxime.ripard@free-electrons.com

We have some restrictions on what the planes and CRTC can provide that are
tied to only one generation of display engines.

For example, on the first generation, we can only have one YUV plane or one
plane that uses the frontend output.

Let's allow our engines to provide an atomic_check callback to validate the
current configuration.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e5f5f144e5c20d348cdb29933ae876c105bec017.1516613040.git-series.maxime.ripard@free-electrons.com

We will need to store some additional data in the future to the state.
Create a custom plane state that will embed those data, in order to store
the pipe or whether or not that plane should use the frontend.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/88dd9c2b0caa550595e7b2ff37dc9d0af2c78609.1516613040.git-series.maxime.ripard@free-electrons.com

The function converting the DRM format to its equivalent in the backend
registers was assuming that we were having a plane.

However, we might want to use that function when setting up a plane using
the frontend, in which case we will not have a plane associated to the
backend's layer. Yet, we still need to setup the format to the one output
by the frontend.

Test for NULL plane pointers before referencing them, so that we can work
around it.
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bfbe4c2e8525a7542526b648d59a8f3546e905f1.1516613040.git-series.maxime.ripard@free-electrons.com

Our operations were missing some documentation to explain what was expected
from them.

Let's make that clearer.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/fdcd8ec3ae9ecd73ef089ede5218d3a41b49be05.1516613040.git-series.maxime.ripard@free-electrons.com

Setup the line stride in the buffer setup function, since it's tied to the
buffer itself, and is not needed when we do not set the buffer in the
backend.

This is for example the case when using the frontend and then routing its
output to the backend.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/cbec84125bc0d5a6cf1d856b8291fbf77b138881.1516613040.git-series.maxime.ripard@free-electrons.com

It's been a while since we've backmerged drm-next. Dave just brought
back 4.15-rc8, so now's a good time to freshen things up around here.
Signed-off-by: NSean Paul <seanpaul@chromium.org>

Signed-off-by: NSamuel Li <Samuel.Li@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1516311860-24949-1-git-send-email-Samuel.Li@amd.com

Since i2c_unregister_device() became NULL-aware we may remove duplicate
NULL check.

Cc: Russell King <linux@armlinux.org.uk>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031142149.32512-8-andriy.shevchenko@linux.intel.comAcked-by: NRussell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Since i2c_unregister_device() became NULL-aware we may remove duplicate
NULL check.

Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031142149.32512-7-andriy.shevchenko@linux.intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Since i2c_unregister_device() became NULL-aware we may remove duplicate
NULL check.

Cc: Archit Taneja <architt@codeaurora.org>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031142149.32512-6-andriy.shevchenko@linux.intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Linux 4.15-rc8

Daniel requested this for so the intel CI won't fall over on drm-next
so often.

Return value for mipi_dsi_shutdown_peripheral() is unchecked.
Check it and return any errors if they come up. Even if
mipi_dsi_shutdown_peripheral() fails, continue attempting to
disable.

Cc: Philippe Cornu <philippe.cornu@st.com>
Reviewed-by: NPhilippe Cornu <philippe.cornu@st.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180116222217.240939-1-seanpaul@chromium.org

The function mipi_dsi_device_transfer() returns the number of transmitted
or received bytes on success or a negative error code on failure.

The functions mipi_dsi_shutdown_peripheral(), mipi_dsi_turn_on_peripheral() &
mipi_dsi_set_maximum_return_packet_size() use improperly this returned
value in case of success: 0 should be returned instead of the number of
transmitted bytes.
Signed-off-by: NPhilippe Cornu <philippe.cornu@st.com>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180112144847.18810-1-philippe.cornu@st.com

We're filling the "remainder" word with little-endian data, then writing
it out to IO registers with endian-correcting writel(). That probably
won't work on big-endian systems.

Let's mark the "remainder" variable as LE32 (since we fill it with
memcpy()) and do the swapping explicitly.

Some of this function could be done more easily without memcpy(), but
the unaligned "remainder" case is a little hard to do without
potentially overrunning 'tx_buf', so I just applied the same solution in
all cases (memcpy() + le32_to_cpu()).

Tested only on a little-endian system.
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180109203248.139249-2-briannorris@chromium.org

This takes care of 2 TODOs in this driver, by using the common DSI
packet-marshalling code instead of our custom short/long write code.
This both saves us some duplicated code and gets us free support for
command types that weren't already part of our switch block (e.g.,
MIPI_DSI_GENERIC_LONG_WRITE).

The code logic stays mostly intact, except that it becomes unnecessary
to split the short/long write functions, and we have to copy data a bit
more.

Along the way, I noticed that loop bounds were a little odd:

	while (DIV_ROUND_UP(len, pld_data_bytes))

This really was just supposed to be 'len != 0', so I made that more
clear.

Tested on RK3399 with some pending refactoring patches by Nickey Yang,
to make the Rockchip DSI driver wrap this common driver.
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Reviewed-by: NPhilippe Cornu <philippe.cornu@st.com>
Tested-by: NPhilippe Cornu <philippe.cornu@st.com>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180109203248.139249-1-briannorris@chromium.org