- 01 May, 2018 1 commit
-
-
Kristian H. Kristensen authored
Blending win0 with the background color doesn't seem to work correctly. We only get the background color, no matter the contents of the win0 framebuffer. However, blending pre-multiplied color with the default opaque black default background color is a no-op, so we can just disable blending to get the correct result. Signed-off-by:
Kristian H. Kristensen <hoegsberg@chromium.org> Cc: Sandy Huang <hjc@rock-chips.com> Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180418173152.93246-1-hoegsberg@chromium.org
-
- 30 Apr, 2018 8 commits
-
-
Stefan Schake authored
This doesn't require any additional functionality from the driver but is a prerequisite to userland calling the syncobj ioctls. Signed-off-by:
Stefan Schake <stschake@gmail.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
-
Stefan Schake authored
Allow specifying a syncobj on render job submission where we store the fence for the job. This gives userland flexible access to the fence. v2: Use 0 as invalid syncobj to drop flag (Eric) Don't reintroduce the padding (Eric) Signed-off-by: -
Stefan Schake authored
Allow userland to specify a syncobj that is waited on before a render job starts processing. v2: Use 0 as invalid syncobj to drop flag (Eric) Drop extra newline (Eric) Signed-off-by: -
Eric Anholt authored
It turns out that I had just mistaken what type of write the register writes were supposed to be, using DCS instead of generic long writes. Switching to transactions instead of using the atmel as a bridge also seems to resolve the sparkling pixels problem I've had. Signed-off-by:
Boris Brezillon <boris.brezillon@bootlin.com> Acked-by:
Thierry Reding <treding@nvidia.com>
-
Eric Anholt authored
It seems that trying to go from unlatched to unlatched will time out waiting for STOP, and we can just skip that. Signed-off-by:
-
Vaishali Thakkar authored
Sparse complains with following warning: drivers/gpu/drm/vc4/vc4_v3d.c:222:1: warning: symbol 'vc4_allocate_bin_bo' was not declared. Should it be static? Make vc4_allocate_bin static as it is not used outside of vc4_v3d.c. Signed-off-by:
Vaishali Thakkar <vthakkar1994@gmail.com> Signed-off-by:
-
Eric Anholt authored
Some drivers leave these unimplemented, so don't make them have unimplemented stubs. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Tom Callaway authored
The PiTFT (ili9340) has a hardware reset circuit that resets only on power-on and not on each reboot through a gpio like the rpi-display does. As a result, we need to always apply the rotation value regardless of the display "on/off" state. Moved the rotation setting code below out_enable:. Signed-off-by:
Tom Callaway <tcallawa@redhat.com> Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
-
- 27 Apr, 2018 9 commits
-
-
Ville Syrjälä authored
drm_property_add_enum() can calculate the index itself just fine, so no point in having the caller pass it in. Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.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/20180316190420.26734-1-ville.syrjala@linux.intel.comReviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Manasi Navare authored
No functional changes in this patch. The SDP Header is a generic header for secondary data packets for both eDP and DP so call it dp_sdp_header. This header gets used for different SDP types already defined. Also header bytes 2 and 3 are secondary data packet specific header bytes. So change the comment to indicate the same. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Philippe CORNU authored
"make C=1" returns 2 warnings in ltdc_plane_create() ("Using plain integer as NULL pointer"). This patch fixes them. Signed-off-by:Philippe Cornu <philippe.cornu@st.com> Reviewed-by:
Yannick Fertré <yannick.fertre@st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180419132804.8317-1-philippe.cornu@st.com
-
Philippe CORNU authored
Add mode_valid() function to filter modes according to available pll clock values and "preferred" modes. It is particularly useful for hdmi modes that require precise pixel clocks. Note that "preferred" modes are always accepted: - this is important for panels because panel clock tolerances are bigger than hdmi ones and there is no reason to not accept them (the fps may vary a little but it is not a problem). - the hdmi preferred mode will be accepted too, but userland will be able to use others hdmi "valid" modes if necessary. Signed-off-by:
-
Philippe CORNU authored
When a driver related to one of the endpoints is deferred due to probe dependencies (i2c, spi...) but the other one is ready, ltdc probe continues and the deferred driver will never be probed again. The fix consists in waiting for all deferred endpoints before continuing the ltdc probe. Signed-off-by:
-
Gerd Hoffmann authored
These days drm core checks function pointers everywhere before calling them. So we can drop a bunch of dummy functions now. Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/20180420071904.24276-5-kraxel@redhat.com
-
Gerd Hoffmann authored
The encoder callbacks are only called in case the video mode changes. So any layout changes without mode changes will go unnoticed. Add qxl_crtc_update_monitors_config(), based on the old qxl_write_monitors_config_for_encoder() function. Hook it into the enable, disable and flush atomic crtc callbacks. Remove monitors_config updates from all other places. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1544322Signed-off-by:
-
Gerd Hoffmann authored
Needed to avoid a forward declaration in a followup patch. Pure code move, no functional change. Signed-off-by:
-
Gerd Hoffmann authored
qxl_io_log() sends messages over to the host (qemu) for logging. Remove the function and all callers, we can just use standard DRM_DEBUG calls (and if needed a serial console). Signed-off-by:
-
- 26 Apr, 2018 1 commit
-
-
Philippe CORNU authored
The "adjusted_mode" clock value (ie the real pixel clock) is more accurate than "mode" clock value (ie the panel/bridge requested clock value). It offers a better preciseness for timing computations and allows to reduce the extra dsi bandwidth in burst mode (from ~20% to ~10-12%, hw platform dependent). Signed-off-by:
Brian Norris <briannorris@chromium.org> Reviewed-by:
Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180125155504.8611-1-philippe.cornu@st.com
-
- 25 Apr, 2018 15 commits
-
-
Daniel Vetter authored
Bunch of ideas from Eric and me on what we could do to make gem gpu rendering drivers a notch simpler to type. v2: Fix typo (Eric). Cc: Eric Anholt <eric@anholt.net> Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180425111742.5872-1-daniel.vetter@ffwll.ch
-
Luc Van Oostenryck authored
The method struct drm_connector_helper_funcs::mode_valid is defined as returning an 'enum drm_mode_status' but the driver implementation for this method uses an 'int' for it. Fix this by using 'enum drm_mode_status' in the driver too. Signed-off-by:
Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by:
-
Luc Van Oostenryck authored
The method struct drm_connector_helper_funcs::mode_valid is defined as returning an 'enum drm_mode_status' but the driver implementation for this method uses an 'int' for it. Fix this by using 'enum drm_mode_status' in the driver too. Signed-off-by:
-
Luc Van Oostenryck authored
The method struct drm_connector_helper_funcs::mode_valid is defined as returning an 'enum drm_mode_status' but the driver implementation for this method uses an 'int' for it. Fix this by using 'enum drm_mode_status' in the driver too. Signed-off-by:
-
Luc Van Oostenryck authored
The method struct drm_connector_helper_funcs::mode_valid is defined as returning an 'enum drm_mode_status' but the driver implementation for this method, psb_intel_lvds_mode_valid(), uses an 'int' for it. Fix this by using 'enum drm_mode_status' for psb_intel_lvds_mode_valid(). Signed-off-by:
-
Luc Van Oostenryck authored
The method struct drm_connector_helper_funcs::mode_valid is defined as returning an 'enum drm_mode_status' but the driver implementation for this method uses an 'int' for it. Fix this by using 'enum drm_mode_status' in the driver too. Signed-off-by:
-
Luc Van Oostenryck authored
The method struct drm_connector_helper_funcs::mode_valid is defined as returning an 'enum drm_mode_status' but the driver implementation for this method uses an 'int' for it. Fix this by using 'enum drm_mode_status' in the driver too. Signed-off-by:
-
Luc Van Oostenryck authored
The method struct drm_connector_helper_funcs::mode_valid is defined as returning an 'enum drm_mode_status' but the driver implementation for this method uses an 'int' for it. Fix this by using 'enum drm_mode_status' in the driver too. Signed-off-by:
-
Luc Van Oostenryck authored
The method struct drm_connector_helper_funcs::mode_valid is defined as returning an 'enum drm_mode_status' but the driver implementation for this method uses an 'int' for it. Fix this by using 'enum drm_mode_status' in the driver too. Signed-off-by:
-
Luc Van Oostenryck authored
The method struct drm_connector_helper_funcs::mode_valid is defined as returning an 'enum drm_mode_status' but the driver implementation for this method uses an 'int' for it. Fix this by using 'enum drm_mode_status' in the driver too. Signed-off-by:
-
Luc Van Oostenryck authored
The method struct drm_connector_helper_funcs::mode_valid is defined as returning an 'enum drm_mode_status' but the driver implementation for this method uses an 'int' for it. Fix this by using 'enum drm_mode_status' in the driver too. Signed-off-by:
-
Luc Van Oostenryck authored
The method struct drm_connector_helper_funcs::mode_valid is defined as returning an 'enum drm_mode_status' but the driver implementation for this method uses an 'int' for it. Fix this by using 'enum drm_mode_status' in the driver too. Signed-off-by:
-
Luc Van Oostenryck authored
The method struct drm_connector_helper_funcs::mode_valid is defined as returning an 'enum drm_mode_status' but the driver implementation for this method uses an 'int' for it. Fix this by using 'enum drm_mode_status' in the driver too. Signed-off-by:
-
Kieran Bingham authored
The ADV7511 has four 256-byte maps that can be accessed via the main I2C ports. Each map has it own I2C address and acts as a standard slave device on the I2C bus. Allow a device tree node to override the default addresses so that address conflicts with other devices on the same bus may be resolved at the board description level. Signed-off-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Archit Taneja <architt@codeaurora.org> Link: https://patchwork.freedesktop.org/patch/msgid/1518544137-2742-6-git-send-email-kbingham@kernel.org
-
Kieran Bingham authored
The ADV7511 has four 256-byte maps that can be accessed via the main I2C ports. Each map has it own I2C address and acts as a standard slave device on the I2C bus. Extend the device tree node bindings to be able to override the default addresses so that address conflicts with other devices on the same bus may be resolved at the board description level. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
- 24 Apr, 2018 6 commits
-
-
Daniel Vetter authored
Only used within drm.ko, no need to tempt drivers. Cc: Keith Packard <keithp@keithp.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
I missed this one because on an older tree. Signed-off-by:
Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180409085134.27321-1-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Note that a pile of drivers don't seem to take implicit fencing into account, or at least don't call drm_atoimc_set_fence_for_plane(). Cc'ing relevant people, or at least some. Some drivers also look like they don't disable implicit fencing (e.g. amdgpu) because the explicit fences and implicit fences are handled by entirely independent code paths. I also wonder whether we shouldn't just make the recommended helpers the default ones, since a lot of drivers don't bother to handle the implicit fences at all it seems. The helpers won't blow up even for non-GEM drivers or GEM drivers which don't fill out the gem bo pointers in struct drm_framebuffer. v2: Comments from Eric. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Reviewed-by:
-
Daniel Vetter authored
Signed-off-by:
-
Daniel Vetter authored
Signed-off-by:
-
Daniel Vetter authored
Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180405154449.23038-4-daniel.vetter@ffwll.ch
-
