- 16 3月, 2017 2 次提交
-
-
由 Chris Wilson 提交于
Avoid adding to the waitqueue and reprobing the current vblank if the caller is only querying the current vblank sequence and timestamp, where we know that the wait would return immediately. v2: Add CRTC identifier to debug messages Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Michel Dänzer <michel@daenzer.net> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Dave Airlie <airlied@redhat.com>, Cc: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: NMichel Dänzer <michel@daenzer.net> Reviewed-and-tested-by: NMario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170315204027.20160-2-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
On vblank instant-off systems, we can get into a situation where the cost of enabling and disabling the vblank IRQ around a drmWaitVblank query dominates. And with the advent of even deeper hardware sleep state, touching registers becomes ever more expensive. However, we know that if the user wants the current vblank counter, they are also very likely to immediately queue a vblank wait and so we can keep the interrupt around and only turn it off if we have no further vblank requests queued within the interrupt interval. After vblank event delivery, this patch adds a shadow of one vblank where the interrupt is kept alive for the user to query and queue another vblank event. Similarly, if the user is using blocking drmWaitVblanks, the interrupt will be disabled on the IRQ following the wait completion. However, if the user is simply querying the current vblank counter and timestamp, the interrupt will be disabled after every IRQ and the user will enabled it again on the first query following the IRQ. v2: Mario Kleiner - After testing this, one more thing that would make sense is to move the disable block at the end of drm_handle_vblank() instead of at the top. Turns out that if high precision timestaming is disabled or doesn't work for some reason (as can be simulated by echo 0 > /sys/module/drm/parameters/timestamp_precision_usec), then with your delayed disable code at its current place, the vblank counter won't increment anymore at all for instant queries, ie. with your other "instant query" patches. Clients which repeatedly query the counter and wait for it to progress will simply hang, spinning in an endless query loop. There's that comment in vblank_disable_and_save: "* Skip this step if there isn't any high precision timestamp * available. In that case we can't account for this and just * hope for the best. */ With the disable happening after leading edge of vblank (== hw counter increment already happened) but before the vblank counter/timestamp handling in drm_handle_vblank, that step is needed to keep the counter progressing, so skipping it is bad. Now without high precision timestamping support, a kms driver must not set dev->vblank_disable_immediate = true, as this would cause problems for clients, so this shouldn't matter, but it would be good to still make this robust against a future kms driver which might have unreliable high precision timestamping, e.g., high precision timestamping that intermittently doesn't work. v3: Patch before coffee needs extra coffee. Testcase: igt/kms_vblank Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Michel Dänzer <michel@daenzer.net> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Dave Airlie <airlied@redhat.com>, Cc: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170315204027.20160-1-chris@chris-wilson.co.uk
-
- 14 3月, 2017 11 次提交
-
-
由 Daniel Vetter 提交于
Sadly there's only 1 driver which can use it, everyone else is special for some reason: - gma500 has a horrible runtime PM ioctl wrapper that probably doesn't really work but meh. - i915 needs special compat_ioctl handler because regrets. - arcgpu needs to fixup the pgprot because (no idea why it can't do that in the fault handler like everyone else). - tegra does even worse stuff with pgprot - udl does something with vm_flags too ... - cma helpers, etnaviv, mtk, msm, rockchip, omap all implement some variation on prefaulting. - exynos is exynos, I got lost in the midlayers. - vc4 has to reinvent half of cma helpers because those are too much midlayer, plus vm_flags dances. - vgem also seems unhappy with the default vm_flags. So pretty sad divergence and I'm sure we could do better, but not really an idea. Oh well, maybe this macro here helps to encourage more consistency at least going forward. Reviewed-by: NSean Paul <seanpaul@chromium.org> Reviewed-by: NLiviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-25-daniel.vetter@ffwll.ch
-
由 Daniel Vetter 提交于
Less code ftw. This converts all drivers except the tinydrm helper module. That one needs more work, since it gets the THIS_MODULE reference from tinydrm.ko instead of the actual driver module like it should. Probably needs a similar trick like I used here with generating the entire struct with a macro. Cc: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: NSean Paul <seanpaul@chromium.org> Reviewed-by: NLiviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-24-daniel.vetter@ffwll.ch
-
由 Daniel Vetter 提交于
I didn't spot anything that would require ordering here (well not anywhere else either), and I'm trying to unify at least modern drivers on one close hook. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NSean Paul <seanpaul@chromium.org> Reviewed-by: NLiviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-18-daniel.vetter@ffwll.ch
-
由 Daniel Vetter 提交于
Well, mostly drm_file.h, and clean up all related things: - I didnt' figure out the difference between preclose and postclose. The existing explanation in drm-internals.rst didn't convince me, since it's also really outdated - we clean up pending DRM events in the core nowadays. I put a FIXME in for the future. - Another FIXME is to have a macro for default fops. - Lots of links all around, main areas are to tie the overview in drm_file.c more into the callbacks in struct drm_device, and the other is to link render/primary node code to the right sections in drm-uapi.rst. - Also moved the open/close stuff to drm_drv.h from drm-internals.rst, seems like the better place for that information. Since that section was rather outdated this amounted to full-on rewrite. A big missing piece here is some overview graph, but I think better to wait with that one until drm_device and drm_driver are also fully documented. v2: Nits from Sean. Reviewed-by: NSean Paul <seanpaul@chromium.org> Reviewed-by: NLiviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-12-daniel.vetter@ffwll.ch
-
由 Daniel Vetter 提交于
We might as well dump the drm_file pointer, that's about as useful a cookie as the pid. Noticed while typing docs for drm_file and friends. Since the only consumer of this is the tracepoints I think we can safely change this - those tracepoints should not be uapi relevant at all. It all goes back to commit b9c2c9ae Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Jul 1 16:48:09 2010 -0700 drm: add per-event vblank event trace points which doesn't give a special justification for using pid over a pointer. Also note that the nouveau code setting it is entirely pointless: Since this isn't a vblank event, it will never hit the vblank tracepoints. Cc: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Reviewed-by: NLiviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-11-daniel.vetter@ffwll.ch
-
由 Dan Carpenter 提交于
My static checker complains that "release" is uninitialized if qxl_alloc_release_reserved() fails, so let's add a check for that. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170314075410.GB5984@mwandaSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
kmem_cache_alloc returns NULL on error, not ERR_PTR. Fixes: f5985bf9Reported-by: NJiri Slaby <jslaby@suse.cz> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1489393346-13874-1-git-send-email-kraxel@redhat.com
-
由 kbuild test robot 提交于
drivers/gpu/drm/tinydrm/mipi-dbi.c:657:2-3: Unneeded semicolon drivers/gpu/drm/tinydrm/mipi-dbi.c:593:2-3: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci Signed-off-by: NFengguang Wu <fengguang.wu@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170312144636.GA91808@lkp-g5.lkp.intel.com
-
由 Chris Zhong 提交于
In order to analyze some video config failed, add some useful printouts. Signed-off-by: NChris Zhong <zyw@rock-chips.com> Signed-off-by: NSean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1488940077-22297-4-git-send-email-zyw@rock-chips.com
-
由 Chris Zhong 提交于
Correct some DP register address for PHY Configuration according to latest datasheet. Signed-off-by: NChris Zhong <zyw@rock-chips.com> Signed-off-by: NSean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1488940077-22297-3-git-send-email-zyw@rock-chips.com
-
由 Chris Zhong 提交于
The clk_get_rate return 0 if something goes wrong, so it can never be less then zero, the ret should be set a error code, otherwise the cdn_dp_clk_enable will return 0 when it failed at clk_get_rate. In addition, clk_get_rate() returns an "unsigned long", so use "unsigned long" instead of "u32" is better. Signed-off-by: NChris Zhong <zyw@rock-chips.com> Signed-off-by: NSean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1488940077-22297-2-git-send-email-zyw@rock-chips.com
-
- 10 3月, 2017 10 次提交
-
-
由 Laurent Pinchart 提交于
The driver is already made of 5 separate source files. Move it to a newly created directory named synopsys where more Synopsys bridge drivers can be added later (for the DisplayPort controller for instance). Suggested-by: NJose Abreu <Jose.Abreu@synopsys.com> Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: NJose Abreu <joabreu@synopsys.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-10-laurent.pinchart+renesas@ideasonboard.com
-
由 Neil Armstrong 提交于
The Synopsys Designware HDMI TX Controller does not enforce register access on platforms instanciating it. The current driver supports two different types of memory-mapped flat register access, but in order to support the Amlogic Meson SoCs integration, and provide a more generic way to handle all sorts of register mapping, switch the register access to use the regmap infrastructure. In the case of registers that are not flat memory-mapped or do not conform to the current driver implementation, a regmap struct can be given in the plat_data and be used at probe or bind. Since the AHB audio driver is only available with direct memory access, only allow the I2S audio driver to be registered is directly memory-mapped. Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NJose Abreu <Jose.Abreu@synopsys.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-10-laurent.pinchart+renesas@ideasonboard.com
-
由 Kieran Bingham 提交于
The device type isn't used anymore now that workarounds and PHY-specific operations are performed based on version information read at runtime. Remove it. Signed-off-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NJose Abreu <joabreu@synopsys.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-9-laurent.pinchart+renesas@ideasonboard.com
-
由 Kieran Bingham 提交于
The DWC HDMI TX controller interfaces with a companion PHY. While Synopsys provides multiple standard PHYs, SoC vendors can also integrate a custom PHY. Modularize PHY configuration to support vendor PHYs through platform data. The existing PHY configuration code was originally written to support the DWC HDMI 3D TX PHY, and seems to be compatible with the DWC MLP PHY. The HDMI 2.0 PHY will require a separate configuration function. Signed-off-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NJose Abreu <Jose.Abreu@synopsys.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-8-laurent.pinchart+renesas@ideasonboard.com
-
由 Laurent Pinchart 提交于
The HDMI TX controller support different PHYs whose programming interface can vary significantly, especially with vendor PHYs that are not provided by Synopsys. To support them, create a PHY operation structure that can be provided by the platform glue layer. The existing PHY handling code (limited to Synopsys PHY support) is refactored into a set of default PHY operations that are used automatically when the platform glue doesn't provide its own operations. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NJose Abreu <joabreu@synopsys.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170305233615.11993-1-laurent.pinchart+renesas@ideasonboard.com
-
由 Laurent Pinchart 提交于
When powering the PHY up we need to wait for the PLL to lock. This is done by polling the TX_PHY_LOCK bit in the HDMI_PHY_STAT0 register (interrupt-based wait could be implemented as well but is likely overkill). The bit is asserted when the PLL locks, but the current code incorrectly waits for the bit to be deasserted. Fix it, and while at it, replace the udelay() with a sleep as the code never runs in non-sleepable context. To be consistent with the power down implementation move the poll loop to the power off function. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NJose Abreu <joabreu@synopsys.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170305233557.11945-1-laurent.pinchart+renesas@ideasonboard.com
-
由 Laurent Pinchart 提交于
The PHY requires us to wait for the PHY to switch to low power mode after deasserting TXPWRON and before asserting PDDQ in the power down sequence, otherwise power down will fail. The PHY power down can be monitored though the TX_READY bit, available through I2C in the PHY registers, or the TX_PHY_LOCK bit, available through the HDMI TX registers. As the two are equivalent, let's pick the easier solution of polling the TX_PHY_LOCK bit. The power down code is currently duplicated in multiple places. To avoid spreading multiple calls to a TX_PHY_LOCK poll function, we have to refactor the power down code and group it all in a single function. Tests showed that one poll iteration was enough for TX_PHY_LOCK to become low, without requiring any additional delay. Retrying the read five times with a 1ms to 2ms delay between each attempt should thus be more than enough. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NJose Abreu <joabreu@synopsys.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170305233539.11898-1-laurent.pinchart+renesas@ideasonboard.com
-
由 Neil Armstrong 提交于
If the input pixel format is not RGB, the CSC must be enabled in order to provide valid pixel to DVI sinks. This patch removes the hdmi only dependency on the CSC enabling. Reviewed-by: NJose Abreu <joabreu@synopsys.com> Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Tested-by: NNeil Armstrong <narmstrong@baylibre.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-4-laurent.pinchart+renesas@ideasonboard.com
-
由 Laurent Pinchart 提交于
The color space converter isn't part of the PHY, move its configuration out of PHY code. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NJose Abreu <joabreu@synopsys.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-3-laurent.pinchart+renesas@ideasonboard.com
-
由 Laurent Pinchart 提交于
Most of the hdmi_phy_test_*() functions are unused. Remove them. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NJose Abreu <joabreu@synopsys.com> Tested-by: NNickey Yang <nickey.yang@rock-chips.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-2-laurent.pinchart+renesas@ideasonboard.com
-
- 09 3月, 2017 6 次提交
-
-
由 Daniel Vetter 提交于
I'm torn on whether drm_minor really should be here or somewhere else. Maybe with more clarity after untangling drmP.h more this is easier to decide, for now I've put a FIXME comment right next to it. Right now we need struct drm_minor for the inline drm_file type helpers, and so it does kinda make sense to have them here. Next patch will kerneldoc-ify the entire pile. Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-10-daniel.vetter@ffwll.ch
-
由 Daniel Vetter 提交于
It's not just file ops, but drm_file stuff in general. This is prep work to extracting a drm_file.h header in the next patch. Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-8-daniel.vetter@ffwll.ch
-
由 Daniel Vetter 提交于
An easy one as a drive-by. Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-6-daniel.vetter@ffwll.ch
-
由 Daniel Vetter 提交于
Just another step in finally making drmP.h obsolete. Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-5-daniel.vetter@ffwll.ch
-
由 Daniel Vetter 提交于
Plus a little bit more documentation. v2: Untangle the missing forward decls to make drm_prime|gem.h free-standing. Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-3-daniel.vetter@ffwll.ch
-
由 Noralf Trønnes 提交于
drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so it's not necessary to call drm_debugfs_remove_files(). Cc: airlied@linux.ie Cc: kraxel@redhat.com Signed-off-by: NNoralf Trønnes <noralf@tronnes.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170307204924.1002-4-noralf@tronnes.org [ kraxel: solved conflict ] Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
- 08 3月, 2017 3 次提交
-
-
由 Noralf Trønnes 提交于
Remove the .debugfs_cleanup() callback now that all the users are gone. Signed-off-by: NNoralf Trønnes <noralf@tronnes.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170307204924.1002-3-noralf@tronnes.org
-
由 Noralf Trønnes 提交于
Move the contents of msm_debugfs_cleanup() to msm_drm_uninit() to free up the drm_driver->debugfs_cleanup callback. Also remove the mdp_kms_funcs->debugfs_cleanup callback which has no users. Cc: robdclark@gmail.com Signed-off-by: NNoralf Trønnes <noralf@tronnes.org> Acked-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170307204924.1002-2-noralf@tronnes.org
-
由 Tomeu Vizoso 提交于
Gabriel Krisman reported these warnings when building the documentation: ./drivers/gpu/drm/drm_dp_helper.c:1165: warning: No description found for parameter 'crtc' ./drivers/gpu/drm/drm_dp_helper.c:1166: warning: No description found for parameter 'crtc' Reported-by: NGabriel Krisman Bertazi <krisman@collabora.co.uk> Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by: NSean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170307203511.14258-1-tomeu.vizoso@collabora.com
-
- 07 3月, 2017 8 次提交
-
-
由 Gerd Hoffmann 提交于
Just use kmem_cache instead of rolling our own, limited implementation. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1488377348-5006-1-git-send-email-kraxel@redhat.com
-
由 Gerd Hoffmann 提交于
Call qxl_add_monitors_config_modes() unconditionally. Do all sanity checks in that function. Fix sanity checks. monitors_config is the current monitor configuration, whereas client_monitors_config is the configuration requested by the spice client. So when filling the mode list, based on the spice client request, we need to look at client_monitors_config->count not monitors_config->count. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Reviewed-by: NGabriel Krisman Bertazi <krisman@collabora.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1488363154-6889-5-git-send-email-kraxel@redhat.com
-
由 Gerd Hoffmann 提交于
Try to read the client monitors config at driver load time, even without explicit notification. So in case that info was filled before the driver loaded and we've missed the notifications because of that the settings will still be used. With that place we now have to take care to properly handle a empty client monitors config, so we don't trip over an uninitialized client monitors config. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Reviewed-by: NGabriel Krisman Bertazi <krisman@collabora.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1488363154-6889-4-git-send-email-kraxel@redhat.com
-
由 Gerd Hoffmann 提交于
When reading the monitor config fails, don't retry forever. If it fails ten times in a row just give up to avoid the driver hangs. Also add a small delay after each attempt, so the host has a chance to complete a partial update. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Reviewed-by: NGabriel Krisman Bertazi <krisman@collabora.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1488363154-6889-3-git-send-email-kraxel@redhat.com
-
由 Gerd Hoffmann 提交于
very old qxl hardware revisions (predating qxl ksm support by a few years) supported a fixed list of video modes only. The list is still provided by the virtual hardware, for backward compatibility reasons. The qxl kms driver never ever looks at it, except for dumping it to the kernel log at load time in case debug logging is enabled. Drop that pointless code. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Reviewed-by: NGabriel Krisman Bertazi <krisman@collabora.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1488363154-6889-2-git-send-email-kraxel@redhat.com
-
由 Gabriel Krisman Bertazi 提交于
If fbdev emulation is disabled, the QXL shutdown path will try to clean a framebuffer that wasn't initialized, hitting the Oops below. The problem is that even when FBDEV_EMULATION is disabled we allocate the qfbdev strutucture, but we don't initialize it. The fix is to stop allocating the memory, since it won't be used. This allows the existing verification in the cleanup hook to do it's job preventing the oops. Now that we don't allocate the unused fbdev structure, we need to be careful when dereferencing it in the PM suspend hook. [ 24.284684] BUG: unable to handle kernel NULL pointer dereference at 00000000000002e0 [ 24.285627] IP: mutex_lock+0x18/0x30 [ 24.286049] PGD 78cdf067 [ 24.286050] PUD 7940f067 [ 24.286344] PMD 0 [ 24.286649] [ 24.287072] Oops: 0002 [#1] SMP [ 24.287422] Modules linked in: qxl [ 24.287806] CPU: 0 PID: 2328 Comm: bash Not tainted 4.10.0-rc5+ #97 [ 24.288515] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014 [ 24.289681] task: ffff88007c4c0000 task.stack: ffffc90001b58000 [ 24.290354] RIP: 0010:mutex_lock+0x18/0x30 [ 24.290812] RSP: 0018:ffffc90001b5bcb0 EFLAGS: 00010246 [ 24.291401] RAX: 0000000000000000 RBX: 00000000000002e0 RCX: 0000000000000000 [ 24.292209] RDX: ffff88007c4c0000 RSI: 0000000000000001 RDI: 00000000000002e0 [ 24.292987] RBP: ffffc90001b5bcb8 R08: fffffffffffffffe R09: 0000000000000001 [ 24.293797] R10: ffff880078d80b80 R11: 0000000000011400 R12: 0000000000000000 [ 24.294601] R13: 00000000000002e0 R14: ffffffffa0009c28 R15: 0000000000000060 [ 24.295439] FS: 00007f30e3acbb40(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000 [ 24.296364] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 24.296997] CR2: 00000000000002e0 CR3: 0000000078c7b000 CR4: 00000000000006f0 [ 24.297813] Call Trace: [ 24.298097] drm_framebuffer_cleanup+0x1f/0x70 [ 24.298612] qxl_fbdev_fini+0x68/0x90 [qxl] [ 24.299074] qxl_modeset_fini+0xd/0x30 [qxl] [ 24.299562] qxl_pci_remove+0x22/0x50 [qxl] [ 24.300025] pci_device_remove+0x34/0xb0 [ 24.300507] device_release_driver_internal+0x150/0x200 [ 24.301082] device_release_driver+0xd/0x10 [ 24.301587] unbind_store+0x108/0x150 [ 24.301993] drv_attr_store+0x20/0x30 [ 24.302402] sysfs_kf_write+0x32/0x40 [ 24.302827] kernfs_fop_write+0x108/0x190 [ 24.303269] __vfs_write+0x23/0x120 [ 24.303678] ? security_file_permission+0x36/0xb0 [ 24.304193] ? rw_verify_area+0x49/0xb0 [ 24.304636] vfs_write+0xb0/0x190 [ 24.305004] SyS_write+0x41/0xa0 [ 24.305362] entry_SYSCALL_64_fastpath+0x1a/0xa9 [ 24.305887] RIP: 0033:0x7f30e31d9620 [ 24.306285] RSP: 002b:00007ffc54b47e68 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 24.307128] RAX: ffffffffffffffda RBX: 00007f30e3497600 RCX: 00007f30e31d9620 [ 24.307928] RDX: 000000000000000d RSI: 0000000000da2008 RDI: 0000000000000001 [ 24.308727] RBP: 000000000070bc60 R08: 00007f30e3498760 R09: 00007f30e3acbb40 [ 24.309504] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000001 [ 24.310295] R13: 0000000000000000 R14: 0000000000000000 R15: 00007ffc54b47f34 [ 24.311095] Code: 0e 01 e9 7b fe ff ff 66 90 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 53 48 89 fb e8 83 e8 ff ff 65 48 8b 14 25 40 c4 00 00 31 c0 <3e> 48 0f b1 13 48 85 c0 74 08 48 89 df e8 66 fd ff ff 5b 5d c3 [ 24.313182] RIP: mutex_lock+0x18/0x30 RSP: ffffc90001b5bcb0 [ 24.313811] CR2: 00000000000002e0 [ 24.314208] ---[ end trace 29669c1593cae14b ]--- Signed-off-by: NGabriel Krisman Bertazi <krisman@collabora.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170227203330.18542-1-krisman@collabora.co.ukSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Sean Paul 提交于
Fixes the following link error when CONFIG_DRM_ANALOGIX_DP is not defined: ERROR: "analogix_dp_start_crc" [drivers/gpu/drm/rockchip/rockchipdrm.ko] undefined! ERROR: "analogix_dp_stop_crc" [drivers/gpu/drm/rockchip/rockchipdrm.ko] undefined! Fixes: 3190e58d ("drm/rockchip: Implement CRC debugfs API") Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Mark Yao <mark.yao@rock-chips.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Heiko Stuebner <heiko@sntech.de> Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-rockchip@lists.infradead.org Cc: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: NEmil Velikov <emil.l.velikov@gmail.com> Signed-off-by: NSean Paul <seanpaul@chromium.org>
-
由 Tomeu Vizoso 提交于
Implement the .set_crc_source() callback and call the DP helpers accordingly to start and stop CRC capture. This is only done if this CRTC is currently using the eDP connector. v3: Remove superfluous check on rockchip_crtc_state->output_type v6: Remove superfluous variable Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: NMark Yao <mark.yao@rock-chips.com> Signed-off-by: NSean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303133936.14964-5-tomeu.vizoso@collabora.com
-