aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2018-04-25drm/virtio: fix mode_valid's return typeLuc Van Oostenryck1-1/+1
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: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180424131524.2510-1-luc.vanoostenryck@gmail.com Link: https://patchwork.freedesktop.org/patch/msgid/20180424131515.2360-1-luc.vanoostenryck@gmail.com Cc: David Airlie <airlied@linux.ie> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: virtualization@lists.linux-foundation.org
2018-04-25drm/i2c: tda998x: fix mode_valid's return typeLuc Van Oostenryck1-1/+1
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: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180424131522.2460-1-luc.vanoostenryck@gmail.com
2018-04-25drm/qxl: fix mode_valid's return typeLuc Van Oostenryck1-1/+1
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: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180424131515.2360-1-luc.vanoostenryck@gmail.com
2018-04-25drm/gma500: fix psb_intel_lvds_mode_valid()'s return typeLuc Van Oostenryck2-2/+2
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 <luc.vanoostenryck@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180424131458.2060-1-luc.vanoostenryck@gmail.com
2018-04-25drm/gma500: fix mode_valid's return typeLuc Van Oostenryck7-7/+7
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: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180424131455.2011-1-luc.vanoostenryck@gmail.com
2018-04-25drm/bridge: tc358767: fix mode_valid's return typeLuc Van Oostenryck1-1/+1
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: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180424131453.1961-1-luc.vanoostenryck@gmail.com
2018-04-25drm/bochs: fix mode_valid's return typeLuc Van Oostenryck1-1/+1
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: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180424131445.1861-1-luc.vanoostenryck@gmail.com
2018-04-25drm/udl: fix mode_valid's return typeLuc Van Oostenryck1-1/+1
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: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180424131520.2409-1-luc.vanoostenryck@gmail.com
2018-04-25drm/mgag200: fix mode_valid's return typeLuc Van Oostenryck1-1/+1
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: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180424131508.2210-1-luc.vanoostenryck@gmail.com
2018-04-25drm/hisilicon: fix mode_valid's return typeLuc Van Oostenryck1-1/+1
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: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180424131504.2159-1-luc.vanoostenryck@gmail.com
2018-04-25drm/bridge: adv7511: fix mode_valid's return typeLuc Van Oostenryck1-1/+1
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: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180424131450.1910-1-luc.vanoostenryck@gmail.com
2018-04-25drm/ast: fix mode_valid's return typeLuc Van Oostenryck1-1/+1
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: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180424131443.1810-1-luc.vanoostenryck@gmail.com
2018-04-25drm/i915/fbdev: Enable late fbdev initial configurationJosé Roberto de Souza1-1/+1
If the initial fbdev configuration (intel_fbdev_initial_config()) runs and there still no sink connected it will cause drm_fb_helper_initial_config() to return 0 as no error happened (but internally the return is -EAGAIN). Because no framebuffer was allocated, when a sink is connected intel_fbdev_output_poll_changed() will not execute drm_fb_helper_hotplug_event() that would trigger another try to do the initial fbdev configuration. So here allowing drm_fb_helper_hotplug_event() to be executed when there is no framebuffer allocated and fbdev was not set up yet. This issue also happens when a MST DP sink is connected since boot, as the MST topology is discovered in parallel if intel_fbdev_initial_config() is executed before the first sink MST is discovered it will cause this same issue. This is a follow-up patch of https://patchwork.freedesktop.org/patch/196089/ Changes from v1: - not creating a dump framebuffer anymore, instead just allowing drm_fb_helper_hotplug_event() to execute when fbdev is not setup yet. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104158 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104425 Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: stable@vger.kernel.org # v4.15+ Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> Tested-by: frederik <frederik.schwan@linux.com> # 4.15.17 Tested-by: Ian Pilcher <arequipeno@gmail.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180418234158.9388-1-jose.souza@intel.com (cherry picked from commit df9e6521749ab33cde306e8a4350b0ac7889220a) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2018-04-25drm/i915: Use ktime on wait_forMika Kuoppala1-2/+2
We use jiffies to determine when wait expires. However Imre did find out that jiffies can and will do a >1 increments on certain situations [1]. When this happens in a wait_for loop, we return timeout errorneously much earlier than what the real wallclock would say. We can't afford our waits to timeout prematurely. Discard jiffies and change to ktime to detect timeouts. v2: added bugzilla entry (Imre), added stable (Chris) Reported-by: Imre Deak <imre.deak@intel.com> References: https://lkml.org/lkml/2018/4/18/798 [1] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105771 Cc: Imre Deak <imre.deak@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180423113754.28424-1-mika.kuoppala@linux.intel.com (cherry picked from commit 3085982c6b45d7d22f76e3aa018affbc143a7370) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2018-04-25drm/mediatek: Use ERR_CAST instead of ERR_PTR(PTR_ERR())Gomonovych, Vasyl1-1/+1
Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...)). drivers/gpu/drm/mediatek/mtk_drm_gem.c:223:9-16: WARNING: ERR_CAST can be used with mtk_gem Generated by: scripts/coccinelle/api/err_cast.cocci Signed-off-by: Vasyl Gomonovych <gomonovych@gmail.com> Acked-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2018-04-25drm: adv7511: Add support for i2c_new_secondary_deviceKieran Bingham2-15/+33
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
2018-04-24drm/amdgpu: set COMPUTE_PGM_RSRC1 for SGPR/VGPR clearing shadersNicolai Hähnle1-2/+5
Otherwise, the SQ may skip some of the register writes, or shader waves may be allocated where we don't expect them, so that as a result we don't actually reset all of the register SRAMs. This can lead to spurious ECC errors later on if a shader uses an uninitialized register. Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2018-04-24drm/atomic: Print debug message on atomic check failureLyude Paul1-3/+7
Does what it says on the label, it's a little confusing debugging atomic check failures otherwise. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180411234302.2896-2-lyude@redhat.com
2018-04-24drm: Don't EXPORT drm_add/reset_display_infoDaniel Vetter2-2/+2
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180424142242.12093-1-daniel.vetter@ffwll.ch
2018-04-24drm/i915/breadcrumbs: Keep the fake irq armed across resetChris Wilson1-9/+20
Instead of synchronously cancelling the timer and re-enabling it inside the reset callbacks, keep the timer enabled and let it die on its next wakeup if no longer required. This allows intel_engine_reset_breadcrumbs() to be used from an atomic (timer/softirq) context such as required for resetting an engine. It also allows us to react better to the user poking around debugfs for testing missed irqs. v2: Tighten the order of del_timer_sync as the fake_irq timer may trigger the hangcheck timer, and so we should cancel it first and then cancel the hangcheck (Mika) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180424142945.6787-1-chris@chris-wilson.co.uk
2018-04-24drm/i915/selftests: Fix uninitialized variableGustavo A. R. Silva1-1/+1
There is a potential execution path in which variable err is returned without being properly initialized previously. Fix this by initializing variable err to 0. Addresses-Coverity-ID: 1468362 ("Uninitialized scalar variable") Fixes: f4ecfbfc32ed ("drm/i915: Check whitelist registers across resets") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180424131545.GA4053@embeddedor.com
2018-04-24drm/i915/fbdev: Enable late fbdev initial configurationJosé Roberto de Souza1-1/+1
If the initial fbdev configuration (intel_fbdev_initial_config()) runs and there still no sink connected it will cause drm_fb_helper_initial_config() to return 0 as no error happened (but internally the return is -EAGAIN). Because no framebuffer was allocated, when a sink is connected intel_fbdev_output_poll_changed() will not execute drm_fb_helper_hotplug_event() that would trigger another try to do the initial fbdev configuration. So here allowing drm_fb_helper_hotplug_event() to be executed when there is no framebuffer allocated and fbdev was not set up yet. This issue also happens when a MST DP sink is connected since boot, as the MST topology is discovered in parallel if intel_fbdev_initial_config() is executed before the first sink MST is discovered it will cause this same issue. This is a follow-up patch of https://patchwork.freedesktop.org/patch/196089/ Changes from v1: - not creating a dump framebuffer anymore, instead just allowing drm_fb_helper_hotplug_event() to execute when fbdev is not setup yet. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104158 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104425 Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: stable@vger.kernel.org # v4.15+ Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> Tested-by: frederik <frederik.schwan@linux.com> # 4.15.17 Tested-by: Ian Pilcher <arequipeno@gmail.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180418234158.9388-1-jose.souza@intel.com
2018-04-24drm/i915: Skip printing global offsets for per-engine scratch pagesChris Wilson1-5/+0
Knowing the offset of the per-engine scratch/HWS page during boot is not very informative, so remove the DRM_DEBUG. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180424115236.2022-1-chris@chris-wilson.co.uk
2018-04-24drm/i915: Don't dump umpteen thousand requestsChris Wilson1-5/+38
If we have more than a few, possibly several thousand request in the queue, don't show the central portion, just the first few and the last being executed and/or queued. The first few should be enough to help identify a problem in execution, and most often comparing the first/last in the queue is enough to identify problems in the scheduling. We may need some fine tuning to set MAX_REQUESTS_TO_SHOW for common debug scenarios, but for the moment if we can avoiding spending more than a few seconds dumping the GPU state that will avoid a nasty livelock (where hangcheck spends so long dumping the state, it fires again and starts to dump the state again in parallel, ad infinitum). v2: Remember to print last not the stale rq iter after the loop. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180424081600.27544-1-chris@chris-wilson.co.uk
2018-04-24drm/i915: Build request info on stack before printkChris Wilson1-9/+15
printk unhelpfully inserts a '\n' between consecutive calls, and since our drm_printf wrapper may be emitting info a seq_file instead, KERN_CONT is not an option. To work with any drm_printf destination, we need to build up the output into a temporary buf on the stack and then feed the complete line in a single call to printk. Fixes: b7268c5eed0a ("drm/i915: Pack params to engine->schedule() into a struct") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180424010839.22860-1-chris@chris-wilson.co.uk
2018-04-24drm/i915: Add compiler barrier to wait_forMika Kuoppala1-0/+4
We need to be careful to not let compiler evaluate the expiration and the operation on it's terms. Document and enforce that COND will be evaluated before checking timeout expiration. Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180423113754.28424-2-mika.kuoppala@linux.intel.com
2018-04-24drm/i915: Use ktime on wait_forMika Kuoppala1-2/+2
We use jiffies to determine when wait expires. However Imre did find out that jiffies can and will do a >1 increments on certain situations [1]. When this happens in a wait_for loop, we return timeout errorneously much earlier than what the real wallclock would say. We can't afford our waits to timeout prematurely. Discard jiffies and change to ktime to detect timeouts. v2: added bugzilla entry (Imre), added stable (Chris) Reported-by: Imre Deak <imre.deak@intel.com> References: https://lkml.org/lkml/2018/4/18/798 [1] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105771 Cc: Imre Deak <imre.deak@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180423113754.28424-1-mika.kuoppala@linux.intel.com
2018-04-24drm/xen-front: use simple display pipe prepare_fb helperDaniel Vetter1-7/+1
I missed this one because on an older tree. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Cc: xen-devel@lists.xen.org Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180409085134.27321-1-daniel.vetter@ffwll.ch
2018-04-24drm/atomic: better doc for implicit vs explicit fencingDaniel Vetter1-0/+8
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: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405154449.23038-7-daniel.vetter@ffwll.ch
2018-04-24drm/mxsfb: Use simple_display_pipe prepare_fb helperDaniel Vetter1-7/+1
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Marek Vasut <marex@denx.de> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20180405154449.23038-6-daniel.vetter@ffwll.ch
2018-04-24drm/pl111: Use simple_display_pipe prepare_fb helperDaniel Vetter1-7/+1
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20180405154449.23038-5-daniel.vetter@ffwll.ch
2018-04-24drm/tve200: Use simple_display_pipe prepare_fb helperDaniel Vetter1-7/+1
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180405154449.23038-4-daniel.vetter@ffwll.ch
2018-04-24drm: Move simple_display_pipe prepare_fb helper into gem fb helpersDaniel Vetter7-22/+25
There's nothing tinydrm specific to this, and there's a few more copies of the same in various other drivers. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Airlie <airlied@linux.ie> Cc: David Lechner <david@lechnology.com> Cc: "Noralf Trønnes" <noralf@tronnes.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Daniel Stone <daniels@collabora.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Acked-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
2018-04-24drm/vmwgfx: Remove no-op prepare/cleanup_fb callbacksDaniel Vetter1-35/+0
Less hits to go through when I git grep over all drivers. These callbacks are optional. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Sinclair Yeh <syeh@vmware.com> Reviewed-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
2018-04-24drm: panel-orientation-quirks: Add quirk for Lenovo Ideapad Mixx 320Hans de Goede1-9/+10
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
2018-04-24drm: panel-orientation-quirks: Add quirk for Lenovo Ideapad Mixx 310Hans de Goede1-0/+17
Some production batches of the Lenovo Ideapad Mixx 310 laptop use a portrait LCD panel, add a quirk for this. 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-1-hdegoede@redhat.com
2018-04-24drm/amdkfd: fix build, select MMU_NOTIFIERRandy Dunlap1-0/+1
When CONFIG_MMU_NOTIFIER is not enabled, struct mmu_notifier has an incomplete type definition, which causes build errors. ../drivers/gpu/drm/amd/amdkfd/kfd_priv.h:607:22: error: field 'mmu_notifier' has incomplete type ../include/linux/kernel.h:979:32: error: dereferencing pointer to incomplete type ../include/linux/kernel.h:980:18: error: dereferencing pointer to incomplete type ../drivers/gpu/drm/amd/amdkfd/kfd_process.c:434:2: error: implicit declaration of function 'mmu_notifier_unregister_no_release' [-Werror=implicit-function-declaration] ../drivers/gpu/drm/amd/amdkfd/kfd_process.c:435:2: error: implicit declaration of function 'mmu_notifier_call_srcu' [-Werror=implicit-function-declaration] ../drivers/gpu/drm/amd/amdkfd/kfd_process.c:438:21: error: variable 'kfd_process_mmu_notifier_ops' has initializer but incomplete type ../drivers/gpu/drm/amd/amdkfd/kfd_process.c:439:2: error: unknown field 'release' specified in initializer ../drivers/gpu/drm/amd/amdkfd/kfd_process.c:439:2: warning: excess elements in struct initializer [enabled by default] ../drivers/gpu/drm/amd/amdkfd/kfd_process.c:439:2: warning: (near initialization for 'kfd_process_mmu_notifier_ops') [enabled by default] ../drivers/gpu/drm/amd/amdkfd/kfd_process.c:534:2: error: implicit declaration of function 'mmu_notifier_register' [-Werror=implicit-function-declaration] Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Anders Roxell <anders.roxell@linaro.org> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2018-04-24drm/i2c: tda998x: add CEC supportRussell King2-9/+187
The TDA998x is a HDMI transmitter with a TDA9950 CEC engine integrated onto the same die. Add support for the TDA9950 CEC engine to the TDA998x driver. Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2018-04-24drm/i2c: tda9950: add CEC driverRussell King3-0/+515
Add a CEC driver for the TDA9950, which is a stand-alone I2C CEC device, but is also integrated into HDMI transceivers such as the TDA9989 and TDA19989. The TDA9950 contains a command processor which handles retransmissions and the low level bus protocol. The driver just has to read and write the messages, and handle error conditions. Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2018-04-24drm/amdkfd: fix clock counter retrieval for node without GPUAndres Rodriguez1-6/+7
Currently if a user requests clock counters for a node without a GPU resource we will always return EINVAL. Instead if no GPU resource is attached, fill the gpu_clock_counter argument with zeroes so that we may proceed and return valid CPU counters. Signed-off-by: Andres Rodriguez <andres.rodriguez@amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2018-04-24drm/amdkfd: Fix the error return code in kfd_ioctl_unmap_memory_from_gpu()Wei Yongjun1-1/+1
Passing NULL pointer to PTR_ERR will result in return value of 0 indicating success which is clearly not what it is intended here. This patch returns -EINVAL instead. v2: change ret code to -ENODEV Fixes: 5ec7e02854b3 ("drm/amdkfd: Add ioctls for GPUVM memory management") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2018-04-24drm/amdkfd: kfd_dev_is_large_bar() can be statickbuild test robot1-1/+1
Fixes: 5ec7e02854b3 ("drm/amdkfd: Add ioctls for GPUVM memory management") Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2018-04-24drm/rockchip: psr: Remove flush by CRTCTomasz Figa2-36/+0
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: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-28-enric.balletbo@collabora.com
2018-04-24drm/rockchip: Disallow PSR for the whole atomic commitTomasz Figa2-8/+60
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: Tomasz Figa <tfiga@chromium.org> Signed-off-by: Sean Paul <seanpaul@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: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-27-enric.balletbo@collabora.com
2018-04-24drm/rockchip: psr: Sanitize semantics of allow/inhibit APITomasz Figa3-17/+46
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 <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: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-26-enric.balletbo@collabora.com
2018-04-24drm/rockchip: psr: Avoid redundant calls to .set() callbackTomasz Figa1-55/+23
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: Tomasz Figa <tfiga@chromium.org> Signed-off-by: Kristian H. Kristensen <hoegsberg@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> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-25-enric.balletbo@collabora.com
2018-04-24drm/rockchip: analogix_dp: Do not call Analogix code before bindTomasz Figa1-0/+9
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: 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: Archit Taneja <architt@codeaurora.org> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-24-enric.balletbo@collabora.com
2018-04-24drm/bridge: analogix_dp: Split the platform-specific poweron in two partsDouglas Anderson3-5/+16
Some of the platform-specific stuff in rockchip_dp_poweron() needs to happen before the generic code. Some needs to happen after. Let's split the callback in two. Specifically we can't start doing PSR work until _after_ the whole controller is up, so don't set the enable until the end. Cc: Kristian H. Kristensen <hoegsberg@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> [seanpaul added exynos change] Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-23-enric.balletbo@collabora.com
2018-04-24drm/rockchip: pre dither down when output bpc is 8bitMark Yao5-0/+11
Some encoder have a crc verification check, crc check fail if input and output data is not equal. That means encoder input and output need use same color depth, vop can output 10bit data to encoder, but some panel only support 8bit depth, that would make crc check die. So pre dither down vop data to 8bit if panel's bpc is 8. Signed-off-by: Mark Yao <mark.yao@rock-chips.com> [seanpaul resolved conflict in rockchip_drm_vop.c] Signed-off-by: Sean Paul <seanpaul@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: Archit Taneja <architt@codeaurora.org> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-22-enric.balletbo@collabora.com
2018-04-24drm/bridge: analogix_dp: Properly disable aux chan retries on rockchipDouglas Anderson1-7/+8
The comments in analogix_dp_init_aux() claim that we're disabling aux channel retries, but then right below it for Rockchip it sets them to 3. If we actually need 3 retries for Rockchip then we could adjust the comment, but it seems more likely that we want the same retry behavior across all platforms. Cc: Stéphane Marchesin <marcheu@chromium.org> Cc: 征增 王 <wzz@rock-chips.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Sean Paul <seanpaul@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: Archit Taneja <architt@codeaurora.org> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-21-enric.balletbo@collabora.com
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.