For some reason drm_mode_set_crtcinfo() does nothing if the mode has
the DRM_MODE_TYPE_BUILTIN flag set without the other bit from
DRM_MODE_TYPE_CRTC_C also set. I have zero idea what that is supposed
to achieve, but since we have no users for neither flag bit let's kill
this nonsense off.
v2: Fix typo in commit message
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-7-ville.syrjala@linux.intel.com
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reject any mode with DRM_MODE_FLAG_BCAST. We have no code that even
checks for this flag hence it can't possibly do any good.
I think this maybe originated from fbdev where it was supposed to
indicate PAL/NTSC broadcast timings. I have no idea why those would
have to be identified by a flag rather than by just the timings
themselves. And then I assume it got copied into xfree86 for
fbdevhw, and later on it leaked into the randr protocol and kms uapi.
Since kms fbdev emulation never uses the corresponding fbdev flag
there should be no sane way for this to come back into kms via
userspace either.
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Adam Jackson <ajax@redhat.com>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-5-ville.syrjala@linux.intel.com
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jose Abreu <joabreu@synopsys.com>
Reject any mode with DRM_MODE_FLAG_PIXMUX. We have no code that even
checks for this flag hence it can't possibly do any good.
Looks like this flag had something to do the the controller<->ramdac
interface with some ancient S3 graphics adapters. Why someone though
it would be a good idea to expose it directly to users I don't know.
And later on it got copied into the randr protocol and kms uapi.
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Adam Jackson <ajax@redhat.com>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-4-ville.syrjala@linux.intel.com
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jose Abreu <joabreu@synopsys.com>
Currently userspace is allowed to feed in any king of garbage in the
high bits of the mode flags/type, as are drivers when probing modes.
Reject any mode with bogus flags/type.
Hopefully this won't break any current userspace...
v2: Split the type and flags checks to separates ifs (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Adam Jackson <ajax@redhat.com>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171115154913.23827-1-ville.syrjala@linux.intel.com
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Currently we don't sanity check the 3D stereo flags for modes filled out
by the kernel. Move the check from drm_mode_convert_umode() into
drm_mode_validate_basic() so that we get the same check going both ways.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-2-ville.syrjala@linux.intel.com
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
We use 32bit bitmasks to track planes/crtcs/encoders/connectors.
Naturally we can only do that if the index of those objects stays
below 32. Issue a warning whenever we exceed that limit, hopefully
prompting someone to fix the problem.
For connectors the issue is a bit more complicated as they can
be created/destroyed at runtime due to MST. So the problem is no
longer a purely theoretical programmer error. As the connector
indexes are allocated via ida, we can simply limit the maximum
value the ida is allowed to hand out. The error handling is already
in place.
v2: Return an error to the caller (Harry)
v3: Print a debug message so that we know what happened (Maarten)
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180125133020.23845-1-ville.syrjala@linux.intel.com
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
There's a bunch of drivers that duplicate the same function to know if a
particular format embeds an alpha component or not.
Let's create a field in the drm_format_info to avoid duplicating that logic
and looking up formats all the time.
Cc: Eric Anholt <eric@anholt.net>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mark Yao <mark.yao@rock-chips.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9cd9951d147ff810c1f6f68d79e7983361ed6b68.1516617243.git-series.maxime.ripard@free-electrons.com
There is a difference between the panel/bridge requested pixel clock
value and the real one due to the hw platform clock preciseness (pll,
dividers...). This patch updates the adjusted_mode clock value with
the real hw clock value so then attached encoder & connector can use
it for precise timing computations.
Signed-off-by: Philippe Cornu <philippe.cornu@st.com>
Reviewed-by: Yannick Fertré <yannick.fertre@st.com>
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180125160101.9102-1-philippe.cornu@st.com
DP 1.4 spec adds a TPS4 training pattern sequence required for
HBR3. This patch adds the corresponding bit definitions in
MAX_DOWNSPREAD register and TRAINING_PATTERN_SET and
inline functions to check if this bit is set and for selecting
a proper TRAINING_PATTERN_MASK that changed to 0x7 on
DP spec 1.4
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1516660991-20697-2-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: Chunming Zhou <david1.zhou@amd.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex 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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-15-ville.syrjala@linux.intel.com
Acked-by: Shawn Guo <shawnguo@kernel.org>
Reviewed-by: Thierry 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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-14-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Thierry 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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Thierry 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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-12-ville.syrjala@linux.intel.com
Reviewed-by: Thierry 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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-11-ville.syrjala@linux.intel.com
Reviewed-by: Thierry 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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-10-ville.syrjala@linux.intel.com
Reviewed-by: Archit Taneja <architt@codeaurora.org>
Reviewed-by: Thierry 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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-9-ville.syrjala@linux.intel.com
Reviewed-by: Thierry 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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-8-ville.syrjala@linux.intel.com
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Thierry 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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-7-ville.syrjala@linux.intel.com
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Thierry 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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-6-ville.syrjala@linux.intel.com
Reviewed-by: Thierry 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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-5-ville.syrjala@linux.intel.com
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Thierry 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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-4-ville.syrjala@linux.intel.com
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Thierry 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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-3-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Thierry 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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-2-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Thierry 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: 6b8562c86e ("drm/sun4i: engine: Create an atomic_begin
callback")
Fixes: 656e5f6549 ("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: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180122174306.231609-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: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/35604307e5bde2b85c674de79fa7c4d55700f085.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: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Maxime 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: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/cdffc25eab2d817820cc78cbd24f1f4b99902014.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: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e5f5f144e5c20d348cdb29933ae876c105bec017.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: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bfbe4c2e8525a7542526b648d59a8f3546e905f1.1516613040.git-series.maxime.ripard@free-electrons.com
