- 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:
Daniel Vetter <daniel.vetter@ffwll.ch> 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:
Eric Anholt <eric@anholt.net> Signed-off-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 15 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
-
Daniel Vetter authored
There's nothing tinydrm specific to this, and there's a few more copies of the same in various other drivers. Signed-off-by:
David Lechner <david@lechnology.com> Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180405154449.23038-3-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Less hits to go through when I git grep over all drivers. These callbacks are optional. Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405154449.23038-2-daniel.vetter@ffwll.ch
-
Hans de Goede authored
The Lenovo Ideapad Mixx 320 laptop uses a portrait LCD panel, add a quirk for this. While at it instead of duplicating the same drm_dmi_panel_orientation_data for 3 laptops add a generic lcd800x1280_rightside_up orientation_data and use that for all 3 (including the new Mixx 320 entry). Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180418123642.11088-2-hdegoede@redhat.com
-
Hans de Goede authored
Some production batches of the Lenovo Ideapad Mixx 310 laptop use a portrait LCD panel, add a quirk for this. Reviewed-by:
-
Tomasz Figa authored
It is not used anymore after last changes and it was not even correct to begin with as it assumed a 1:1 relation between a CRTC and encoder, while in fact a CRTC can be attached to multiple encoders. Signed-off-by:
Tomasz Figa <tfiga@chromium.org> Signed-off-by:
Thierry Escande <thierry.escande@collabora.com> Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by:
Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by:
-
Tomasz Figa authored
Currently PSR flush is triggered from CRTC's .atomic_begin() callback, which is executed after modeset disables and enables and before plane updates are committed. Since PSR flush and re-enable can be triggered asynchronously by external sources (input event, delayed work), it can race with hardware programming done in the aforementioned stages. This patch blocks the PSR completely before hardware programming part begins and unblock after it ends. This relies on reference counted PSR disable introduced with previous patch. Cc: Kristian H. Kristensen <hoegsberg@chromium.org> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
-
Tomasz Figa authored
Currently both rockchip_drm_psr_activate() and _deactivate() only set the boolean "active" flag without actually making sure that hardware state complies with it. Since we are going to extend the usage of this API to properly lock PSR for the duration of atomic commits, we change the semantics in following way: - a counter is used to track the number of inhibit requests, - PSR is actually disabled in hardware on first inhibit request, - PSR enable work is scheduled on last allow request. The above allows using the API as a way to deterministically synchronize PSR state changes with other DRM events, i.e. atomic commits and cursor updates. As a nice side effect, the naming is sorted out and we have "inhibit" for stopping the software logic and "enable" for hardware state. Signed-off-by:
-
Tomasz Figa authored
The first time after we call rockchip_drm_do_flush() after rockchip_drm_psr_register(), we go from PSR_DISABLE to PSR_FLUSH. The difference between PSR_DISABLE and PSR_FLUSH is whether or not we have a delayed work pending - PSR is off in either state. However psr_set_state() only catches the transition from PSR_FLUSH to PSR_DISABLE (which never happens), while going from PSR_DISABLE to PSR_FLUSH triggers a call to psr->set() to disable PSR while it's already disabled. This triggers the eDP PHY power-on sequence without being shut down first and this seems to occasionally leave the encoder unable to later enable PSR. Let's just simplify the state machine and simply consider PSR_DISABLE and PSR_FLUSH the same state. Signed-off-by:
Kristian H. Kristensen <hoegsberg@chromium.org> Signed-off-by:
-
Tomasz Figa authored
Driver callbacks, such as system suspend or resume can be called any time, specifically they can be called before the component bind callback. Let's use dp->adp pointer as a safeguard and skip calling Analogix entry points if it is an ERR_PTR(). Signed-off-by:
-
