- 14 Mar, 2017 8 commits
-
-
Daniel Vetter authored
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:
Sean Paul <seanpaul@chromium.org> Reviewed-by:
Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-25-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-11-daniel.vetter@ffwll.ch
-
Dan Carpenter authored
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:
Dan Carpenter <dan.carpenter@oracle.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170314075410.GB5984@mwandaSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Gerd Hoffmann authored
kmem_cache_alloc returns NULL on error, not ERR_PTR. Fixes: f5985bf9Reported-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
-
kbuild test robot authored
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:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
- 13 Mar, 2017 3 commits
-
-
Chris Zhong authored
In order to analyze some video config failed, add some useful printouts. Signed-off-by:
Chris Zhong <zyw@rock-chips.com> Signed-off-by:
-
Chris Zhong authored
Correct some DP register address for PHY Configuration according to latest datasheet. Signed-off-by:
-
Chris Zhong authored
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:
-
- 11 Mar, 2017 1 commit
-
-
git://linuxtv.org/pinchartl/mediaDaniel Vetter authored
Merge Laurent's drm_platform removal code. Only conflict is with the drm_pci.h extraction, which allows me to fix up the misplayed drm_platform_init fumble that 0day and Stephen Rothwell reported. Signed-off-by:
-
- 10 Mar, 2017 10 commits
-
-
Laurent Pinchart authored
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:
Jose Abreu <Jose.Abreu@synopsys.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Jose Abreu <joabreu@synopsys.com> Signed-off-by:
Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-10-laurent.pinchart+renesas@ideasonboard.com
-
Neil Armstrong authored
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:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
-
Kieran Bingham authored
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:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
-
Kieran Bingham authored
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:
-
Laurent Pinchart authored
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:
-
Laurent Pinchart authored
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:
-
Laurent Pinchart authored
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:
-
Neil Armstrong authored
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:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Laurent Pinchart authored
The color space converter isn't part of the PHY, move its configuration out of PHY code. Signed-off-by:
-
Laurent Pinchart authored
Most of the hdmi_phy_test_*() functions are unused. Remove them. Signed-off-by:
Nickey Yang <nickey.yang@rock-chips.com> Signed-off-by:
-
- 09 Mar, 2017 10 commits
-
-
Daniel Vetter authored
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:
Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by:
-
Daniel Vetter authored
This was originally added by David Herrmann for range checks, but entirely unused. It confused me, so let's remove it. Cc: David Herrmann <dh.herrmann@gmail.com> Reviewed-by:
David Herrmann <dh.herrmann@gmail.com> Signed-off-by:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
Worst case if the hw can't support completion signalling in a race-free way we want the event to be too late, not too early. Text adapted from a proposal from Laurent - the other side of how to make hw work correctly where it's possible is imo already sufficiently documented. v2: Review from Laurent. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Daniel Vetter authored
An easy one as a drive-by. Reviewed-by:
-
Daniel Vetter authored
Just another step in finally making drmP.h obsolete. Reviewed-by:
-
Daniel Vetter authored
And remove the semi-kernel-doc stuff, to make sure no one uses this. Reviewed-by:
-
Daniel Vetter authored
Plus a little bit more documentation. v2: Untangle the missing forward decls to make drm_prime|gem.h free-standing. Reviewed-by:
-
Daniel Vetter authored
At least radeon, amdgpu and nouveau should be converted. We have patches for i915 already. v2: Spelling (Sean). Reviewed-by:
-
Noralf Trønnes authored
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:
Noralf Trønnes <noralf@tronnes.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170307204924.1002-4-noralf@tronnes.org [ kraxel: solved conflict ] Signed-off-by:
-
- 08 Mar, 2017 2 commits
-
-
Noralf Trønnes authored
Remove the .debugfs_cleanup() callback now that all the users are gone. Signed-off-by:
-
Noralf Trønnes authored
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:
Rob Clark <robdclark@gmail.com> Signed-off-by:
-
- 07 Mar, 2017 6 commits
-
-
Tomeu Vizoso authored
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:
Gabriel Krisman Bertazi <krisman@collabora.co.uk> Signed-off-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by:
-
Gerd Hoffmann authored
Just use kmem_cache instead of rolling our own, limited implementation. Signed-off-by:
-
Gerd Hoffmann authored
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:
-
Gerd Hoffmann authored
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:
-
Gerd Hoffmann authored
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:
-
Gerd Hoffmann authored
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:
-
