- 08 Dec, 2017 2 commits
-
-
Neil Armstrong authored
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. Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Tested-by:
Jerome Brunet <jbrunet@baylibre.com> Reviewed-by:
-
Neil Armstrong authored
The Video Processing Unit power domain was setup by the Vendor U-Boot, add support for an optional Power Domain phandle to setup it from the kernel. Acked-by:
-
- 07 Dec, 2017 2 commits
-
-
Daniel Vetter authored
We're spotting this very rarely in CI, but have no idea. Let's add more debug info about what's going on here. References: https://bugs.freedesktop.org/show_bug.cgi?id=102707Acked-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171207144925.14191-1-daniel.vetter@ffwll.ch
-
Jernej Skrabec authored
min_scale and max_scale in sun8i_vi_layer_atomic_check() can be used without initialization. Fix that. Fixes: b862a648 ("drm/sun4i: Add support for HW scaling to DE2") Signed-off-by:
Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171206152603.25937-1-jernej.skrabec@siol.net
-
- 06 Dec, 2017 3 commits
-
-
Gustavo A. R. Silva authored
fb_helper is being dereferenced before it is null checked, hence there is a potential null pointer dereference. Fix this by moving the pointer dereference after fb_helper has been null checked. This issue was detected with the help of Coccinelle. Fixes: c777990f ("drm/fb-helper: Handle function NULL argument") Signed-off-by:
Gustavo A. R. Silva <garsilva@embeddedor.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20171205174628.GA31189@embeddedor.com
-
Benjamin Gaignard authored
Add SPDX identifiers to files under stm directory Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@st.com> Acked-by:
Vincent Abriou <vincent.abriou@st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171206112947.9569-1-benjamin.gaignard@st.com
-
Benjamin Gaignard authored
Add SPDX identifiers to files under sti directory Signed-off-by:
-
- 05 Dec, 2017 28 commits
-
-
Noralf Trønnes authored
Replace driver's code with the generic helpers that do the same thing. Cc: Stefan Agner <stefan@agner.ch> Cc: Alison Wang <alison.wang@freescale.com> Signed-off-by:
Stefan Agner <stefan@agner.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20171114212517.23536-5-noralf@tronnes.org
-
Jernej Skrabec authored
Now that we have all required bits, add support for YUV formats. DRM subsystem doesn't know YUV411 semi-planar format, so leave that out for now. Signed-off-by:
-
Jernej Skrabec authored
Basic principle of operation when using YUV framebuffer is that chroma planes have to be upscaled to same size as luma. Because of that, expand DE2 scaler library to support that. BSP driver uses another set of FIR filter coefficients for YUV planes. Signed-off-by:
-
Jernej Skrabec authored
This commit expands translation of DRM YUV format to HW specific information. It doesn't do any functional changes. Signed-off-by:
-
Jernej Skrabec authored
DE2 have many CSC units - channel input CSC, channel output CSC and mixer output CSC and maybe more. Fortunately, they have all same register layout, only base offsets differs. Add support only for channel output CSC for now. Signed-off-by:
-
Jernej Skrabec authored
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. Signed-off-by:
-
Jernej Skrabec authored
Scaling is currently supported only for RGB framebuffers Coefficients and algorithm which coefficients to select are taken from BSP driver. Signed-off-by:
-
Jernej Skrabec authored
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. Signed-off-by:
-
Jernej Skrabec authored
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. Signed-off-by:
-
Jernej Skrabec authored
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 No functional change is made. Signed-off-by:
-
Jernej Skrabec authored
Currently only a few RGB formats are supported by the DE2 driver. Add support for all formats supported by the HW. Signed-off-by:
-
Jernej Skrabec authored
Support for multiple UI planes can now be easily enabled just by adding more planes with different index. For now, add immutable zpos property. Signed-off-by:
-
Jernej Skrabec authored
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. Signed-off-by:
-
Jernej Skrabec authored
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. Signed-off-by:
-
Jernej Skrabec authored
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. Signed-off-by:
-
Jernej Skrabec authored
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. Signed-off-by:
-
Jernej Skrabec authored
Since current DE2 driver doesn't know how to scale yet, add atomic check function which checks that. Nice side effect of that function is that populates clipped coordinates and checks visibility of the plane. That data will be used in the future. Signed-off-by:
-
Jernej Skrabec authored
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. Signed-off-by:
-
Jernej Skrabec authored
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. Signed-off-by:
-
Jernej Skrabec authored
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. Signed-off-by:
-
Jernej Skrabec authored
BSP driver always sets blend mode for all channels, no matter if they are really used or not. Do the same here. The exact meaning of the value is not exactly known, but BSP driver mentions "SRC OVER" and by digging through code some more info can be found. Signed-off-by:
-
Jernej Skrabec authored
Color attribute have same format troughout the whole driver. Rename macro, add comment with simple explanation and remove redundant definitions. Signed-off-by:
-
Jernej Skrabec authored
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. Just remove the code. Signed-off-by:
-
Jernej Skrabec authored
Debug message would print "Enabling" even when disabling plane. Fix it. Fixes: 9d75b8c0 (drm/sun4i: add support for Allwinner DE2 mixers) Signed-off-by:
-
Jernej Skrabec authored
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. Because of that, just remove the code. Signed-off-by:
-
Jernej Skrabec authored
Current RGB formats macros are actually not specific to UI planes. Rename it to something more universal and introduce shift macro. Signed-off-by:
-
Jernej Skrabec authored
Format mask is one bit too short. Fix it. Fixes: 9d75b8c0 (drm/sun4i: add support for Allwinner DE2 mixers) Signed-off-by:
-
Hans de Goede authored
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. Suggested-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
-
- 04 Dec, 2017 5 commits
-
-
Hans de Goede authored
This is now all handled in the drivers and communicated through fb_info.fbcon_rotate_hint. Acked-by:
-
Hans de Goede authored
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. Acked-by:
-
Hans de Goede authored
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() Reviewed-by:
-
Hans de Goede authored
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 Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=94894Reviewed-by:
-
Hans de Goede authored
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_* Reviewed-by:
-
