Boris Brezillon [Fri, 12 Jan 2018 09:09:26 +0000 (10:09 +0100)]
drm/vc4: Expose performance counters to userspace
The V3D engine has various hardware counters which might be interesting
to userspace performance analysis tools.
Expose new ioctls to create/destroy a performance monitor object and
query the counter values of this perfmance monitor.
Note that a perfomance monitor is given an ID that is only valid on the
file descriptor it has been allocated from. A performance monitor can be
attached to a CL submission and the driver will enable HW counters for
this request and update the performance monitor values at the end of the
job.
Eric Anholt [Tue, 30 Jan 2018 21:56:43 +0000 (13:56 -0800)]
drm: Print the pid when debug logging an ioctl error.
When we debug print what ioctl we're calling into, we include the pid.
If you have multiple processes rendering simulataneously, the error
return also needs the pid so you can see which of the ioctl calls was
the one to fail.
Philippe CORNU [Thu, 1 Feb 2018 10:42:43 +0000 (11:42 +0100)]
drm/stm: ltdc: remove non-alpha color formats on layer 2 for older hw
Hw older versions support non-alpha color formats derived
from native alpha color formats only on the primary layer.
For instance, RG16 native format without alpha works fine
on 2nd layer but XR24 (derived color format from AR24)
does not work on 2nd layer.
Philippe CORNU [Thu, 1 Feb 2018 10:42:42 +0000 (11:42 +0100)]
drm/stm: ltdc: add non-alpha color formats
ltdc supports natively some color formats with alpha (like
ARGB8888, ARGB1555, ARGB4444...). Related non-alpha formats are
supported too (ARGB8888->XRGB8888, ARGB4444->XRGB4444...) by
adjusting ltdc blending factors.
Note: Wayland/Weston requests by default the non-alpha XRGB8888
color format.
Philippe Cornu [Tue, 6 Feb 2018 08:42:51 +0000 (09:42 +0100)]
drm/bridge/synopsys: dsi: Add 1.31 version support
Add support for the Synopsys DesignWare MIPI DSI version 1.31
Two registers need to be updated/added for supporting 1.31:
* PHY_TMR_CFG 0x9c (updated)
1.30 [31:24] phy_hs2lp_time
[23:16] phy_lp2hs_time
[14: 0] max_rd_time
Linus Walleij [Tue, 6 Feb 2018 09:35:40 +0000 (10:35 +0100)]
drm/pl111: Support multiple endpoints on the CLCD
The Versatile PL110 implementations use multiple endpoints:
from the PL111 port, the lines are routed through a PLD,
and from there forked so the same lines go to a VGA DAC and
an external TFT panel connector. This is discrete wireing
so there is no way to turn of one output, i.e. this is
really two endpoints, not two ports.
We model this with multiple endpoints, so we need to loop
over the available endpoints, check for panel or bridge on
each and accumulate the result before continuing.
The code already will give the panel preference over the
bridge, if present, so the output will be sent to the panel
if both a panel and a bridge is present on two endpoints
of the same port.
If they all return -EPROBE_DEFER we return -EPROBE_DEFER
as well.
If just one endpoint is present on the port, the behaviour
is the same as before.
Linus Walleij [Tue, 6 Feb 2018 09:35:39 +0000 (10:35 +0100)]
drm/pl111: Support variants with broken VBLANK
The early Integrator CLCD synthesized in the Integrator CP and
IM-PD1 FPGAs are broken: their vertical and next base interrupts
are not functional. Support these variants by simply disabling
the use of the vblank interrupt on these variants.
Linus Walleij [Tue, 6 Feb 2018 09:35:38 +0000 (10:35 +0100)]
drm/pl111: Support variants with broken clock divider
The early Integrator CLCD synthesized in the Integrator CP and
IM-PD1 FPGAs are broken: their clock dividers do not work
properly. Support disabling the clock divider and drive the
clock directly from the parent under these circumstances.
Linus Walleij [Tue, 6 Feb 2018 09:35:37 +0000 (10:35 +0100)]
drm/pl111: Handle the Versatile RGB/BGR565 mode
The ARM Versatile series can do RGB/BGR565 with an external
"PLD" (Programmable Logical Device). However the CLCD does not
have control bits for this, so it needs to be set into the
ordinary 16BPP mode, then the RGB/BGR565 handling of the pixel
data is handled by configuring the PLD through the external
register.
Linus Walleij [Tue, 6 Feb 2018 09:35:36 +0000 (10:35 +0100)]
drm/pl111: Properly detect the ARM PL110 variants
With a bit of refactoring we can contain the variant data for
the strange PL110 versions that is feature-incomplete PL110 for
the ARM Integrator/CP and somewhere inbetween PL110 and PL111
for the ARM Versatile AB and Versatile PB.
We also accomodate for the custom duct-taped RGB565/BGR565 support
in the Versatile variant.
Linus Walleij [Mon, 5 Feb 2018 19:20:13 +0000 (20:20 +0100)]
drm/panel: Add support for ARM Versatile panels
The ARM reference designs "Versatile AB" and "Versatile PB"
contain panel connectors with autodetection of the connected
panel type. This adds a small driver utilizing the MFD syscon
look-up to read the autodetection register and set up the
corresponding panel appropriately.
In the source file there is a bit of elaboration of the
panel types and interfaces on these boards.
This was tested with the PL111 DRM driver on the ARM Versatile
AB with the IB2 daughterboard.
This will make it possible for userspace to know whether reading
will block, without blocking on the fd. This makes it possible to
drain all queued CRC's in blocking mode, without having to reopen
the fd.
Ville Syrjälä [Tue, 23 Jan 2018 17:08:54 +0000 (19:08 +0200)]
drm/sun4i: Use drm_mode_get_hv_timing() to populate plane clip rectangle
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().
Daniel Vetter [Wed, 31 Jan 2018 10:21:56 +0000 (11:21 +0100)]
MAINTAINERS: Maarten for drm-misc co-maintainer
I'm stepping down, also handing all the drm-misc stuff to the new
team. Plan is that Sean handles 4.17, and Maarten then has fun with
4.18 as his first release.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Sean Paul <seanpaul@chromium.org> Acked-by: Sean Paul <seanpaul@chromium.org> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Gustavo Padovan <gustavo.padovan@collabora.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180131102156.25634-1-daniel.vetter@ffwll.ch
Daniel Vetter [Wed, 17 Jan 2018 14:17:55 +0000 (15:17 +0100)]
drm/arcpgu: remove drm_encoder_slave
drm_encoder_slave is the old way to write bridge drivers, for i2c
bridges only. It's deprecated, and definitely should not be used in
new drivers. This has absolutely nothing to do with the new bridge
driver infrastructure implemented by drm_bridge.
What's even strange is that arcpgu doesn't even use any of this, it
really only wants a plain normal drm_encoder. Nuke all the surplus
real estate.
v2: Actually git add after compile testing ...
v3: Clarify commit message and stop including drm_encoder_slave.h.
Philippe Cornu [Thu, 25 Jan 2018 10:38:00 +0000 (11:38 +0100)]
drm/bridge/synopsys: dsi: Fix dsi_host_transfer() return value
The dw_mipi_dsi_host_transfer() must return the number of
bytes transmitted/received on success instead of 0.
Note: As the read feature is not implemented, only the
transmitted number of bytes is returned for the moment.
Philippe CORNU [Mon, 22 Jan 2018 15:35:47 +0000 (16:35 +0100)]
dt-bindings: display: stm32: correct clock-names in dsi panel example
In the dsi panel example, clock names in the "clock-names"
field have been swapped:
* "pclk" (peripheral clock) is <&rcc 1 CLK_F469_DSI> on stm32f4
* "ref" (dsi phy pll ref clock) is <&clk_hse> on stm32f4
Leo (Sunpeng) Li [Wed, 17 Jan 2018 11:51:08 +0000 (12:51 +0100)]
drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits
During a non-blocking commit, it is possible to return before the
commit_tail work is queued (-ERESTARTSYS, for example).
Since a reference on the crtc commit object is obtained for the pending
vblank event when preparing the commit, the above situation will leave
us with an extra reference.
Therefore, if the commit_tail worker has not consumed the event at the
end of a commit, release it's reference.
Changes since v1:
- Also check for state->event->base.completion being set, to
handle the case where stall_checks() fails in setup_crtc_commit().
Changes since v2:
- Add a flag to drm_crtc_commit, to prevent dereferencing a freed event.
i915 may unreference the state in a worker.
Fixes: 24835e442f28 ("drm: reference count event->completion") Cc: <stable@vger.kernel.org> # v4.11+ Signed-off-by: Leo (Sunpeng) Li <sunpeng.li@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> #v1 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180117115108.29608-1-maarten.lankhorst@linux.intel.com Reviewed-by: Sean Paul <seanpaul@chromium.org>
Ville Syrjälä [Tue, 14 Nov 2017 18:32:58 +0000 (20:32 +0200)]
drm/i915: Provide a device level .mode_valid() hook
We never support certain mode flags etc. Reject those early on in the
mode_config.mode_valid() hook. That allows us to remove some duplicated
checks from the connector .mode_valid() hooks, and it guarantees that
we never see those flags even from user mode as the
mode_config.mode_valid() hooks gets executed for those as well.
Ville Syrjälä [Tue, 14 Nov 2017 18:32:57 +0000 (20:32 +0200)]
drm/modes: Provide global mode_valid hook
Allow drivers to provide a device wide .mode_valid() hook in addition to
the already existing crtc/encoder/bridge/connector hooks. This can be
used to validate device/driver wide constraings without having to add
those to the other hooks. And since we call this hook also for user
modes later on in the modeset we don't have to worry about anything the
hook has already rejected.
I also have some further ideas for this hook. Eg. we could replace the
drm_mode_set_crtcinfo(HALVE_V) call in drm_mode_convert_umode()/etc.
with a driver specific variant via this hook. At least on i915 we would
like to pass CRTC_STEREO_DOUBLE to that function instead, and then
we could safely use the crtc_ timings in all our .mode_valid() hooks,
which would allow us to reuse those hooks for validating the
adjusted_mode during a modeset.
v2: Fix the language fails in the kernel docs (Daniel)
Ville Syrjälä [Wed, 15 Nov 2017 15:45:04 +0000 (17:45 +0200)]
drm/uapi: Deprecate nonsense kms mode types
BUILTIN, CRTC_C, CLOCK_C, and DEFULT mode types are unused. Let's
refuse to generate them or accept them from userspace either. A
cursory check didn't reveal any userspace code that would depend
on these.
v2: Recommend DRIVER instead of BUILTIN (ajax)
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> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171115154504.14338-1-ville.syrjala@linux.intel.com Reviewed-by: Jose Abreu <joabreu@synopsys.com>
Ville Syrjälä [Tue, 14 Nov 2017 18:32:54 +0000 (20:32 +0200)]
drm/modes: Kill off the oddball DRM_MODE_TYPE_CRTC_C vs. DRM_MODE_TYPE_BUILTIN handling
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.
Ville Syrjälä [Tue, 14 Nov 2017 18:32:52 +0000 (20:32 +0200)]
drm/uapi: Deprecate DRM_MODE_FLAG_BCAST
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.
Ville Syrjälä [Tue, 14 Nov 2017 18:32:51 +0000 (20:32 +0200)]
drm/uapi: Deprecate DRM_MODE_FLAG_PIXMUX
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.
Ville Syrjälä [Wed, 15 Nov 2017 15:49:13 +0000 (17:49 +0200)]
drm/uapi: Validate the mode flags/type
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>
Ville Syrjälä [Tue, 14 Nov 2017 18:32:49 +0000 (20:32 +0200)]
drm/modes: Move 3D stereo flag check into drm_mode_validate_basic()
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.
Ville Syrjälä [Thu, 25 Jan 2018 13:30:20 +0000 (15:30 +0200)]
drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit bitmasks
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>
Maxime Ripard [Mon, 26 Jun 2017 20:51:15 +0000 (22:51 +0200)]
drm/sun4i: backend: Check for the number of alpha planes
Due to the way the composition is done in hardware, we can only have a
single alpha-enabled plane active at a time, placed in the second (highest
priority) pipe.
Make sure of that in our atomic_check to not end up in an impossible
scenario.
Maxime Ripard [Mon, 1 May 2017 08:52:32 +0000 (10:52 +0200)]
drm/sun4i: backend: Add support for zpos
Our various planes have a configurable zpos, that combined with the pipes
allow to configure the composition.
Since the interaction between the pipes, zpos and alphas framebuffers is
not trivial, let's just enable the zpos as an immutable property for now,
and use that zpos in our atomic_update part.
Philippe CORNU [Thu, 25 Jan 2018 16:01:01 +0000 (17:01 +0100)]
drm/stm: ltdc: use crtc_mode_fixup to update adjusted_mode clock
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.
Manasi Navare [Mon, 22 Jan 2018 22:43:11 +0000 (14:43 -0800)]
drm/dp: Add definitions for TPS4 bits and macros to check the support
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
Ville Syrjälä [Thu, 23 Nov 2017 19:05:01 +0000 (21:05 +0200)]
drm/zte: Use drm_mode_get_hv_timing() to populate plane clip rectangle
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().
Ville Syrjälä [Thu, 23 Nov 2017 19:05:00 +0000 (21:05 +0200)]
drm/vmwgfx: Use drm_mode_get_hv_timing() to populate plane clip rectangle
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().
Ville Syrjälä [Thu, 23 Nov 2017 19:04:58 +0000 (21:04 +0200)]
drm/rockchip: Use drm_mode_get_hv_timing() to populate plane clip rectangle
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().
Ville Syrjälä [Thu, 23 Nov 2017 19:04:56 +0000 (21:04 +0200)]
drm/msm/mdp5: Use drm_mode_get_hv_timing() to populate plane clip rectangle
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>
Ville Syrjälä [Thu, 23 Nov 2017 19:04:53 +0000 (21:04 +0200)]
drm/imx: Use drm_mode_get_hv_timing() to populate plane clip rectangle
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().
Ville Syrjälä [Thu, 23 Nov 2017 19:04:52 +0000 (21:04 +0200)]
drm/simple_kms_helper: Use drm_mode_get_hv_timing() to populate plane clip rectangle
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().
Ville Syrjälä [Thu, 23 Nov 2017 19:04:51 +0000 (21:04 +0200)]
drm/arm/mali-dp: Use drm_mode_get_hv_timing() to populate plane clip rectangle
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().
Ville Syrjälä [Thu, 23 Nov 2017 19:04:50 +0000 (21:04 +0200)]
drm/arm/hdlcd: Use drm_mode_get_hv_timing() to populate plane clip rectangle
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().
Ville Syrjälä [Thu, 23 Nov 2017 19:04:49 +0000 (21:04 +0200)]
drm/i915: Use drm_mode_get_hv_timing() to populate plane clip rectangle
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().
Ville Syrjälä [Thu, 23 Nov 2017 19:04:48 +0000 (21:04 +0200)]
drm/i915: Reject odd pipe source width with double wide/dual link
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.
Sean Paul [Mon, 22 Jan 2018 17:42:59 +0000 (12:42 -0500)]
drm/sun4i: Fix build warnings in sunxi_engine.h
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: 6b8562c86e24 ("drm/sun4i: engine: Create an atomic_begin
callback") Fixes: 656e5f654903 ("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
Maxime Ripard [Mon, 22 Jan 2018 09:25:26 +0000 (10:25 +0100)]
drm/sun4i: backend: Make sure we don't have a commit pending
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.
Maxime Ripard [Mon, 22 Jan 2018 09:25:25 +0000 (10:25 +0100)]
drm/sun4i: backend: Use runtime_pm variant of atomic_commit_tail
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.
Maxime Ripard [Mon, 22 Jan 2018 09:25:24 +0000 (10:25 +0100)]
drm/sun4i: backend: Add a custom atomic_check for the frontend
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.
Maxime Ripard [Mon, 22 Jan 2018 09:25:23 +0000 (10:25 +0100)]
drm/sun4i: backend: Wire in the frontend
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.
Maxime Ripard [Mon, 22 Jan 2018 09:25:22 +0000 (10:25 +0100)]
drm/sun4i: Add a driver for the display frontend
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.
Maxime Ripard [Mon, 22 Jan 2018 09:25:20 +0000 (10:25 +0100)]
drm/sun4i: engine: Add a VBLANK quirk callback
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.
Maxime Ripard [Mon, 22 Jan 2018 09:25:18 +0000 (10:25 +0100)]
drm/sun4i: backend: Add a custom plane state
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.
Maxime Ripard [Mon, 22 Jan 2018 09:25:17 +0000 (10:25 +0100)]
drm/sun4i: backend: Allow a NULL plane pointer to retrieve the format
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.
Maxime Ripard [Mon, 22 Jan 2018 09:25:15 +0000 (10:25 +0100)]
drm/sun4i: backend: Move line stride setup to buffer setup function
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.
Sean Paul [Tue, 16 Jan 2018 22:22:10 +0000 (17:22 -0500)]
drm/panel: panasonic-vvx10f034n00: Fix wuxga_nt_panel_disable() return value
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.
Philippe Cornu [Fri, 12 Jan 2018 14:48:47 +0000 (15:48 +0100)]
drm/dsi: Fix improper use of mipi_dsi_device_transfer() return value
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.
Brian Norris [Tue, 9 Jan 2018 20:32:48 +0000 (12:32 -0800)]
drm/bridge/synopsys: dsi: handle endianness correctly in dw_mipi_dsi_write()
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()).
Brian Norris [Tue, 9 Jan 2018 20:32:47 +0000 (12:32 -0800)]
drm/bridge/synopsys: dsi: use common mipi_dsi_create_packet()
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.
Noralf Trønnes [Wed, 10 Jan 2018 18:59:39 +0000 (19:59 +0100)]
drm/tinydrm: Embed the mode in tinydrm_connector
Embed the mode in tinydrm_connector instead of doing an devm_ allocation.
Remove unnecessary use of ret variable at the end of
tinydrm_display_pipe_init().
Noralf Trønnes [Wed, 10 Jan 2018 18:59:38 +0000 (19:59 +0100)]
drm/tinydrm/mi0283qt: Let the display pipe handle power
It's better to leave power handling and controller init to the
modesetting machinery using the simple pipe .enable and .disable
callbacks. Remove unused mipi_dbi_pipe_enable().
projects / mirror_ubuntu-eoan-kernel.git / log