Philippe CORNU [Thu, 26 Oct 2017 11:17:46 +0000 (13:17 +0200)]
drm/stm: ltdc: add clut mode support
Add the 8-bit clut mode support at crtc level.
Useful for low memory footprint user interfaces but also for
8-bit old games (including color shifting visual effects).
Tested with fbdev FBIOPUTCMAP & drm DRM_IOCTL_MODE_SETGAMMA
ioctls.
drm/bridge: analogix: Remove unreachable code from analogic_dp_core.c
This patch removes an unreachable code found by the SVACE static
analysis:
UNREACHABLE_CODE: This statement in the source code might be unreachable
during program execution.
[unreachable] unreachable at drivers/gpu/drm/bridge/analogix/analogix_dp_core.c:787
retval != 0 is always false because at this program point the variable retval
is always equal to 0 at drivers/gpu/drm/bridge/analogix/analogix_dp_core.c:786
Maxime Ripard [Thu, 21 Dec 2017 11:02:28 +0000 (12:02 +0100)]
drm/panel: lvds: Add support for the power-supply property
A significant number of panels need to power up a regulator in order to
operate properly. Add support for the power-supply property to enable and
disable such a regulator whenever needed.
Maxime Ripard [Thu, 21 Dec 2017 11:02:32 +0000 (12:02 +0100)]
drm/sun4i: Create minimal multipliers and dividers
The various outputs the TCON can provide have different constraints on the
dotclock divider. Let's make them configurable by the various mode_set
functions.
Maxime Ripard [Thu, 21 Dec 2017 11:02:31 +0000 (12:02 +0100)]
drm/sun4i: Force the mixer rate at 150MHz
It seems like the mixer can only run properly when clocked at 150MHz. In
order to have something more robust than simply a fire-and-forget
assigned-clocks-rate, let's put that in the code.
The A83T has two video pipelines in parallel that looks quite similar to
the other SoCs.
The video planes are handled through a controller called the mixer, and the
video signal is then passed to the timing controller (TCON).
And while there is two instances of the mixers and TCONs, they have a
significant number of differences. The TCONs are quite easy to deal with,
one is supposed to generate TV (in the broader term, so including things
like HDMI) signals, the other one LCD (so RGB, LVDS, DSI) signals. And
while they are called TCON0 and TCON1 in the A83t datasheet, newer SoCs
call them TCON-TV and TCON-LCD, which seems more appropriate.
However, the mixers differ mostly by their capabilities, with some features
being available only in the first one, or the number of planes they expose,
but also through their register layout. And while the capabilities could be
represented as properties, the register layout differences would need to
express all the registers offsets as properties, which is usually quite
bad. Especially since documentation on that hardware block is close to
non-existent and we don't even have the list of all those registers in the
first place.
So let's call them mixer 0 and 1 in our compatibles, even though the name
is pretty bad...
At the moment, we only have tested the code on a board that has a single
display output, so we're leaving the tcon-tv and mixer1 out.
David Lechner [Thu, 21 Dec 2017 18:33:07 +0000 (12:33 -0600)]
drm/tinydrm: Update ILI9225 compatible string
This updates the compatible string for a no-name LCD panel to
"vot,v220hf01a-t", "ilitek,ili9225".
The original bindings were the generic "ilitek,ili9225-2.2in-176x220"
because I could not find a datasheet. However, after some more research,
I finally found one, so the actual vendor and model name are now known.
This previous bindings have not made it to the mainline kernel yet, so
this is not breaking backwards compatibility.
David Lechner [Thu, 21 Dec 2017 18:33:06 +0000 (12:33 -0600)]
dt-bindings: update compatible string for ILI9225
This updates the compatible string for a no-name LCD panel to
"vot,v220hf01a-t", "ilitek,ili9225".
The original bindings [1] were the generic "ilitek,ili9225-2.2in-176x220"
because I could not find a datasheet. However, after some more research,
I finally found one, so the actual vendor and model name are now known.
This previous bindings have not made it to the mainline kernel yet, so
this is not breaking backwards compatibility.
This is also following the precedence of the ILI9322 bindings [2] by using
the pattern "vendor,specific-system-config", "vendor,ip-part";
David Lechner [Thu, 21 Dec 2017 18:46:19 +0000 (12:46 -0600)]
drm: fix tainted kernel caused by drm_panel_orientation_quirks.c
drm_panel_orientation_quirks.c introduced in commit 404d1a3edc38 ("drm:
Add panel orientation quirks, v6.") taints the kernel when compiled as a
module. Fix this by adding MODULE_LICENSE().
Noralf Trønnes [Fri, 15 Dec 2017 17:51:17 +0000 (18:51 +0100)]
drm/fb-helper: Add drm_fb_helper_defio_init()
Add helper for initializing fbdev deferred I/O.
The cleanup could have happened in drm_fb_helper_fini(), but that would
have required me to set fb_info->fbdefio to NULL in a couple of drivers
before they call _fini() to avoid double defio cleanup. The problem is
that one of those is vboxvideo which lives in Greg's staging tree.
So I put the cleanup in drm_fb_helper_fbdev_teardown(), not perfect
but not that bad either.
Daniel Vetter [Thu, 14 Dec 2017 20:30:54 +0000 (21:30 +0100)]
drm/doc: Move legacy kms helpers to the very end
We don't want people to accidentally stumble over there.
Also rename the plane helpers to legacy plane helpers. After Ville's
patch to make the clipping helper atomic and move it to
drm_atomic_helper.c there's nothing left in there that should be
useful for modern drivers.
v2: Laurent had a few questions around how state is added to
drm_atomic_state, tried to clarify that. And spotted another sentence
where the docs suggested subclassing.
Daniel Vetter [Thu, 14 Dec 2017 20:30:53 +0000 (21:30 +0100)]
drm/atomic: document how to handle driver private objects
DK put some nice docs into the commit introducing driver private
state, but in the git history alone it'll be lost.
Also, since Ville remove the void* usage it's a good opportunity to
give the driver private stuff some tlc on the doc front.
Finally try to explain why the "let's just subclass drm_atomic_state"
approach wasn't the greatest, and annotate all those functions as
deprecated in favour of more standardized driver private states. Also
note where we could/should extend driver private states going forward
(atm neither locking nor synchronization is handled in core/helpers,
which isn't really all that great).
v2: Spelling and phrasing improvements (Alex, DK).
Cc: Harry Wentland <harry.wentland@amd.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171214203054.20141-5-daniel.vetter@ffwll.ch
Daniel Vetter [Thu, 14 Dec 2017 20:30:51 +0000 (21:30 +0100)]
drm/print: Unconfuse kerneldoc
It thinks we want to document the __printf(2,0) annotion. Not sure we
want to teach it about all possible gcc-only flags, hence why I opted
for the cheap trick of just moving it ahead of the kerneldoc.
This is only a problem for static inline functions, since for
non-inline function the kerneldoc is in the .c file, but the special
annotations are all in the header.
Daniel Vetter [Thu, 14 Dec 2017 20:30:50 +0000 (21:30 +0100)]
drm/edid: kerneldoc for is_hdmi2_sink
Also some breadcrumbs for how exactly to find this. Probably should
pass drm_connector * or at least drm_display_info * to that function
instead. But drm_hdmi_avi_infoframe_quant_range probably also wants
drm_connector_state (and the hdmi stuff moved into that), so this is a
bit more work.
Thierry Reding [Mon, 20 Nov 2017 15:09:59 +0000 (16:09 +0100)]
drm/atomic-helper: Make zpos property kerneldoc less misleading
kerneldoc for drm_plane_create_zpos_property() says that the DRM core
will automatically calculate the normalized zpos values, but it doesn't
actually do that anymore since commit 38d868e41c4b ("drm: Don't force
all planes to be added to the state due to zpos"). Instead, drivers are
supposed to explicitly call the drm_atomic_normalize_zpos() function.
Change the kerneldoc comment to reflect that.
v2: reference the commit that introduced the kerneldoc unclarity
Keith Packard [Wed, 13 Dec 2017 08:44:26 +0000 (00:44 -0800)]
drm: Update edid-derived drm_display_info fields at edid property set [v2]
There are a set of values in the drm_display_info structure for each
connector which hold information derived from EDID. These are computed
in drm_add_display_info. Before this patch, that was only called in
drm_add_edid_modes. This meant that they were only set when EDID was
present and never reset when EDID was not, as happened when the
display was disconnected.
One of these fields, non_desktop, is used from
drm_mode_connector_update_edid_property, the function responsible for
assigning the new edid value to the application-visible property.
Various drivers call these two functions (drm_add_edid_modes and
drm_mode_connector_update_edid_property) in different orders. This
means that even when EDID is present, the drm_display_info fields may
not have been computed at the time that
drm_mode_connector_update_edid_property used the non_desktop value to
set the non_desktop property.
I've added a public function (drm_reset_display_info) that resets the
drm_display_info field values to default values and then made the
drm_add_display_info function public. These two functions are now
called directly from drm_mode_connector_update_edid_property so that
the drm_display_info fields are always computed from the current EDID
information before being used in that function.
This means that the drm_display_info values are often computed twice,
once when the EDID property it set and a second time when EDID is used
to compute modes for the device. The alternative would be to uniformly
ensure that the values were computed once before being used, which
would require that all drivers reliably invoke the two paths in the
same order. The computation is inexpensive enough that it seems more
maintainable in the long term to simply compute them in both paths.
The API to drm_add_display_info has been changed so that it no longer
takes the set of edid-based quirks as a parameter. Rather, it now
computes those quirks itself and returns them for further use by
drm_add_edid_modes.
This patch also includes a number of 'const' additions caused by
drm_mode_connector_update_edid_property taking a 'const struct edid *'
parameter and wanting to pass that along to drm_add_display_info.
v2: after review by Daniel Vetter <daniel.vetter@ffwll.ch>
Removed EXPORT_SYMBOL_GPL for drm_reset_display_info and
drm_add_display_info.
Added FIXME in drm_mode_connector_update_edid_property about
potentially merging that with drm_add_edid_modes to avoid
the need for two driver calls.
Jani Nikula [Thu, 23 Nov 2017 12:13:08 +0000 (14:13 +0200)]
MAINTAINERS: Remove Jani as drm-misc co-maintainer
I'm juggling too many things, and drm-misc maintenance is one that I
keep dropping on the floor. Admit reality and remove myself as
maintainer. This still leaves us with a nice team of three who are
actually doing the drm-misc work, while I focus on drm-intel.
Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Sean Paul <seanpaul@chromium.org> Cc: Dave Airlie <airlied@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Relunctantly-Acked-By: Sean Paul <seanpaul@chromium.org> Acked-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123121308.12818-1-jani.nikula@intel.com
Noralf Trønnes [Fri, 8 Dec 2017 19:37:42 +0000 (20:37 +0100)]
drm/tinydrm: Use drm_fb_cma_fbdev_init_with_funcs/fini()
Use drm_fb_cma_fbdev_init_with_funcs() and drm_fb_cma_fbdev_fini() which
relies on the fact that drm_device holds a pointer to the drm_fb_helper
structure. This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.
Remove todo entry.
Noralf Trønnes [Wed, 15 Nov 2017 14:19:58 +0000 (15:19 +0100)]
drm/arm/mali: Use drm_fb_cma_fbdev_init/fini()
Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
the fact that drm_device holds a pointer to the drm_fb_helper structure.
This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.
Noralf Trønnes [Wed, 15 Nov 2017 14:19:57 +0000 (15:19 +0100)]
drm/zte: Use drm_fb_cma_fbdev_init/fini()
Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
the fact that drm_device holds a pointer to the drm_fb_helper structure.
This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.
Noralf Trønnes [Wed, 15 Nov 2017 14:19:56 +0000 (15:19 +0100)]
drm/vc4: Use drm_fb_cma_fbdev_init/fini()
Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
the fact that drm_device holds a pointer to the drm_fb_helper structure.
This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.
Noralf Trønnes [Wed, 15 Nov 2017 14:19:55 +0000 (15:19 +0100)]
drm/tve200: Use drm_fb_cma_fbdev_init/fini()
Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
the fact that drm_device holds a pointer to the drm_fb_helper structure.
This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.
Noralf Trønnes [Wed, 15 Nov 2017 14:19:54 +0000 (15:19 +0100)]
drm/tilcdc: Use drm_fb_cma_fbdev_init/fini()
Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
the fact that drm_device holds a pointer to the drm_fb_helper structure.
This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.
Noralf Trønnes [Wed, 15 Nov 2017 14:19:53 +0000 (15:19 +0100)]
drm/sun4i: Use drm_fb_cma_fbdev_init/fini()
Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
the fact that drm_device holds a pointer to the drm_fb_helper structure.
This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.
Noralf Trønnes [Wed, 15 Nov 2017 14:19:52 +0000 (15:19 +0100)]
drm/stm: Use drm_fb_cma_fbdev_init/fini()
Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
the fact that drm_device holds a pointer to the drm_fb_helper structure.
This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.
Remove duplicate ldev assignment.
Cc: Yannick Fertre <yannick.fertre@st.com> Cc: Philippe Cornu <philippe.cornu@st.com> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: Philippe Cornu <philippe.cornu@st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171115142001.45358-14-noralf@tronnes.org
Noralf Trønnes [Wed, 15 Nov 2017 14:19:51 +0000 (15:19 +0100)]
drm/sti: Use drm_fb_cma_fbdev_init/fini()
Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
the fact that drm_device holds a pointer to the drm_fb_helper structure.
This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.
Noralf Trønnes [Wed, 15 Nov 2017 14:19:49 +0000 (15:19 +0100)]
drm/pl111: Use drm_fb_cma_fbdev_init/fini()
Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
the fact that drm_device holds a pointer to the drm_fb_helper structure.
This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.
Noralf Trønnes [Wed, 15 Nov 2017 14:19:46 +0000 (15:19 +0100)]
drm/imx: Use drm_fb_cma_fbdev_init/fini()
Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
the fact that drm_device holds a pointer to the drm_fb_helper structure.
This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.
Noralf Trønnes [Wed, 15 Nov 2017 14:19:44 +0000 (15:19 +0100)]
drm/atmel-hlcdc: Use drm_fb_cma_fbdev_init/fini()
Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
the fact that drm_device holds a pointer to the drm_fb_helper structure.
This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.
Noralf Trønnes [Wed, 15 Nov 2017 14:19:41 +0000 (15:19 +0100)]
drm/cma-helper: Add drm_fb_cma_fbdev_init/fini()
Add functions drm_fb_cma_fbdev_init(), drm_fb_cma_fbdev_fini() and
drm_fb_cma_fbdev_init_with_funcs(). These functions relies on the fact
that the drm_fb_helper struct is stored in dev->drm_fb_helper_private
so drivers don't need to store it.
Noralf Trønnes [Tue, 5 Dec 2017 18:25:04 +0000 (19:25 +0100)]
drm/tegra: Use drm_fb_helper_lastclose() and _poll_changed()
This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.
Noralf Trønnes [Tue, 5 Dec 2017 18:25:03 +0000 (19:25 +0100)]
drm/rockchip: Use drm_fb_helper_lastclose() and _poll_changed()
This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.
Noralf Trønnes [Tue, 5 Dec 2017 18:25:01 +0000 (19:25 +0100)]
drm/omap: Use drm_fb_helper_lastclose() and _poll_changed()
This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.
Noralf Trønnes [Tue, 5 Dec 2017 18:24:59 +0000 (19:24 +0100)]
drm/msm: Use drm_fb_helper_lastclose() and _poll_changed()
This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.
Noralf Trønnes [Tue, 5 Dec 2017 18:24:58 +0000 (19:24 +0100)]
drm/gma500: Use drm_fb_helper_lastclose() and _poll_changed()
This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.
Noralf Trønnes [Tue, 5 Dec 2017 18:24:57 +0000 (19:24 +0100)]
drm/exynos: Use drm_fb_helper_lastclose() and _poll_changed()
This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.
Cc: Inki Dae <inki.dae@samsung.com> Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Inki Dae <inki.dae@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171205182504.41923-5-noralf@tronnes.org
Noralf Trønnes [Tue, 5 Dec 2017 18:24:56 +0000 (19:24 +0100)]
drm/armada: Use drm_fb_helper_lastclose() and _poll_changed()
This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.
Neil Armstrong [Wed, 6 Dec 2017 11:54:27 +0000 (12:54 +0100)]
drm/meson: dw_hdmi: Add support for an optional external 5V regulator
On reference boards and derivatives, the HDMI Logic is powered by an external
5V regulator.
This regulator was set by the Vendor U-Boot, add optional support for it.
On reference boards and derivatives, the HDMI Logic is powered by an external
5V regulator.
This regulator was set by the Vendor U-Boot, add optional support for it.
Jernej Skrabec [Fri, 1 Dec 2017 06:05:45 +0000 (07:05 +0100)]
drm/sun4i: Add CCSC property to DE2 configuration
Base addresses of channel output CSC (CCSC) depends whether mixer in
question is first or second and if it is second, if supports VEP or not.
This new property will tell which set of base addresses to take.
Jernej Skrabec [Fri, 1 Dec 2017 06:05:43 +0000 (07:05 +0100)]
drm/sun4i: Add scaler configuration to DE2 mixers
No all SoCs support scaling on all channels. For example, V3s support
scaling only on VI channels. Because of that, add additional
configuration bitmask which tells which channel support scaler.
Jernej Skrabec [Fri, 1 Dec 2017 06:05:42 +0000 (07:05 +0100)]
drm/sun4i: Add support for DE2 VI planes
This commit adds basic support for VI planes. They are meant for video
overlay and because of that they support YUV formats too. However, using
YUV format is not straightforward, so only RGB formats are supported for
now.
Jernej Skrabec [Fri, 1 Dec 2017 06:05:41 +0000 (07:05 +0100)]
drm/sun4i: Reorganize UI layer code in DE2
Till now, DE2 driver supported only UI planes. Before we add support for
VI planes, lets split out UI layer specific code from common parts. This
commit does the following:
- renames sun8i_layer.c to sun8i_ui_layer.c
- moves UI channel specific code to sun8i_ui_layer.c
- moves common code from sun8i_layer.c to sun8i_mixer.c
- renames function and structure names so it is apparent where they
belong to
Jernej Skrabec [Fri, 1 Dec 2017 06:05:38 +0000 (07:05 +0100)]
drm/sun4i: Move interlace related code in DE2
There is no point having code which sets interlace mode of mixer in
channel related function. Interlace mode will only change when CRTC
state will change, so let's move it to the block which is executed only
when primary plane state is changed.
Jernej Skrabec [Fri, 1 Dec 2017 06:05:37 +0000 (07:05 +0100)]
drm/sun4i: Move channel size related code in DE2
Channel size should be set every time plane is changed, not only when
primary plane changes. Current code works only because only one
(primary) plane is supported at the moment.
Jernej Skrabec [Fri, 1 Dec 2017 06:05:36 +0000 (07:05 +0100)]
drm/sun4i: Move line width setting in DE2
Line width is a property of a framebuffer and it belongs to
sun8i_mixer_update_layer_buffer(). This will became even more obvious
when support for multi-plane formats will be added.
Jernej Skrabec [Fri, 1 Dec 2017 06:05:35 +0000 (07:05 +0100)]
drm/sun4i: Use values calculated by atomic check
Now that we have properly clipped coordinates in plane state structure,
use them.
This also fixes bug where source x and y were adjusted for negative
value, but width and height weren't. It wasn't discovered because
primary plane usually doesn't have negative coordinates.
Jernej Skrabec [Fri, 1 Dec 2017 06:05:33 +0000 (07:05 +0100)]
drm/sun4i: Start using layer id in DE2 driver
Till now, plane selection was hardcoded to first overlay in first UI
channel and layer parameter is unused.
Rename and add parameters to layer functions so they would represent HW
more accurately and start using then.
It turns out that overlays don't fit well in current DRM design, because
they can't be blended together or scaled independetly when they are set
to same channel. Because of that, always use only first overlay in each
channel.
Jernej Skrabec [Fri, 1 Dec 2017 06:05:32 +0000 (07:05 +0100)]
drm/sun4i: Rework enabling plane in DE2 driver
If we want to support multiple planes in the future, code which enables
pipe has to be moved to appropriate place and it must depend on channel
id instead of being hardcoded.
Side effect of that rework is definition of default Z position. For now,
put first channel at the bottom, second above it and so on.
Jernej Skrabec [Fri, 1 Dec 2017 06:05:31 +0000 (07:05 +0100)]
drm/sun4i: Rename some macros in DE2 driver
Now that some knowledge of DE2 is gained, rename or add some macros to
make code more readable.
Max channel macro is removed, since it is not used and it is not clear
if it has right value. Structures in BSP driver shows possibility of 5
channels maximum although there is no SoC with such configuration.
Jernej Skrabec [Fri, 1 Dec 2017 06:05:28 +0000 (07:05 +0100)]
drm/sun4i: Remove setting default values in DE2 driver
Premultiply and color key control registers are already set to zero by
initialization code few lines above. Furthermore, it seems that
colorkeying doesn't really work. It's not used in BSP driver and
experiments with it all failed.
Jernej Skrabec [Fri, 1 Dec 2017 06:05:26 +0000 (07:05 +0100)]
drm/sun4i: Remove setting alpha mode in DE2 driver
Current code sets alpha mode to global alpha mode and global alpha
value to 0xff which is totaly opaque. That is not needed for two
reasons:
- only one plane is active and thus it can be blended only with
background, which is black,
- it will hinder proper blending when more than one plane is supported
Default mode (0) considers pixel alpha value or 0xff if pixel has
no alpha information. Global alpha value is ignored in this case.
Hans de Goede [Mon, 4 Dec 2017 22:33:21 +0000 (23:33 +0100)]
drm: Document that drm_panel_orientation_quirks.c is shared with fbdev
Add a comment to the DRM_PANEL_ORIENTATION_QUIRKS documenting that the
reason for a separate Kconfig for this is because
drm_panel_orientation_quirks.c code is shared with fbdev.
Hans de Goede [Sat, 25 Nov 2017 19:35:52 +0000 (20:35 +0100)]
efifb: Set info->fbcon_rotate_hint based on drm_get_panel_orientation_quirk
On some hardware the LCD panel is not mounted upright in the casing,
but rotated by 90 degrees. In this case we want the console to
automatically be rotated to compensate.
The drm subsys has a quirk table for this, use the
drm_get_panel_orientation_quirk function to get the panel orientation
and set info->fbcon_rotate_hint based on this, so that the fbcon console
on top of efifb gets automatically rotated to compensate for the panel
orientation.
Hans de Goede [Sat, 25 Nov 2017 19:35:51 +0000 (20:35 +0100)]
drm/i915: Add "panel orientation" property to the panel connector, v6.
Ideally we could use the VBT for this, that would be simple, in
intel_dsi_init() check dev_priv->vbt.dsi.config->rotation, set
connector->display_info.panel_orientation accordingly and call
drm_connector_init_panel_orientation_property(), done.
Unfortunately vbt.dsi.config->rotation is always 0 even on tablets
with an upside down LCD and where the GOP is properly rotating the
EFI fb in hardware.
So instead we end up reading the rotation from the primary plane.
This commit only implements the panel orientation property for DSI
panels on BYT / CHT hardware, as all known non normal oriented panels
sofar are only found on this hardware.
Changes in v2:
-Read back the rotation applied by the GOP from the primary plane
instead of relying on dev_priv->vbt.dsi.config->rotation, because it
seems that the VBT rotation filed is always 0 even on devices where the
GOP does apply a rotation
Changes in v3:
-Rewrite the code to read back the orientation from the primary
plane to contain all of this in intel_dsi.c instead of poking a bunch
of holes between all the different layers
Changes in v6:
-Move hardware readout to intel_dsi_init()
Hans de Goede [Sat, 25 Nov 2017 19:35:50 +0000 (20:35 +0100)]
drm/fb-helper: Apply panel orientation connector prop to the primary plane, v6.
Apply the "panel orientation" drm connector prop to the primary plane so
that fbcon and fbdev using userspace programs display the right way up.
Changes in v3:
-Use a rotation member in struct drm_fb_helper_crtc and set that from
drm_setup_crtcs instead of looping over all crtc's to find the right one
later
-Since we now no longer look at rotation quirks directly in the fbcon
code, set fb_info.fbcon_rotate_hint when the panel is not mounted upright
and we cannot use hardware rotation
Changes in v4:
-Make drm_fb_helper_init() init drm_fb_helper_crtc.rotation to
DRM_MODE_ROTATE_0 for all crtcs, so that we do not end up setting the
plane_state's rotation to an invalid value for disabled crtcs
(caught by Fi.CI)
Changes in v5:
-Only use hardware (crtc primary plane) rotation for DRM_ROTATE_180,
90 / 270 degree rotation requires special handling which we lack atm
-Add a TODO comment for 90 / 270 degree hardware rotation
-Add some comments to better document the default case when mapping
sw_rotations to fbcon_rotate_hints
Hans de Goede [Sat, 25 Nov 2017 19:35:49 +0000 (20:35 +0100)]
drm: Add support for a panel-orientation connector property, v6
On some devices the LCD panel is mounted in the casing in such a way that
the up/top side of the panel does not match with the top side of the
device (e.g. it is mounted upside-down).
This commit adds the necessary infra for lcd-panel drm_connector-s to
have a "panel orientation" property to communicate how the panel is
orientated vs the casing.
Userspace can use this property to check for non-normal orientation and
then adjust the displayed image accordingly by rotating it to compensate.
Changes in v2:
-Store panel_orientation in drm_display_info, so that drm_fb_helper.c can
access it easily
-Have a single drm_connector_init_panel_orientation_property rather then
create and attach functions. The caller is expected to set
drm_display_info.panel_orientation before calling this, then this will
check for platform specific quirks overriding the panel_orientation and if
the panel_orientation is set after this then it will attach the property.
Changes in v6:
-Use an enum (with kerneldoc) rather then #defines for
DRM_MODE_PANEL_ORIENTATION_*
Hans de Goede [Sat, 25 Nov 2017 19:35:48 +0000 (20:35 +0100)]
drm: Add panel orientation quirks, v6.
Some x86 clamshell design devices use portrait tablet screens and a display
engine which cannot rotate in hardware, so the firmware just leaves things
as is and we cannot figure out that the display is oriented non upright
from the hardware.
So at least on x86, we need a quirk table for this. This commit adds a DMI
based quirk table which is initially populated with 5 such devices: Asus
T100HA, GPD Pocket, GPD win, I.T.Works TW891 and the VIOS LTH17.
This quirk table will be used by the drm code to let userspace know that
the display is not mounted upright inside the devices case through a new
panel orientation drm-connector property, as well as to tell fbcon to
rotate the console so that it shows the right way up.
Changes in v5:
-Add a kernel-doc comment documenting drm_get_panel_orientation_quirk()
-Remove board_* matches from the dmi-matches for the VIOS LTH17 laptop,
keeping only the (identical) sys_vendor and product_name matches.
This is necessary because an older version of the bios has
board_vendor set to VOIS instead of VIOS
Changes in v6:
-Add reference to added kernel-docs in Documentation/gpu/drm-kms-helpers.rst