summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-03-21drm/edid: detect SCDC support in HF-VSDBShashank Sharma
This patch does following: - Adds a new structure (drm_hdmi_info) in drm_display_info. This structure will be used to save and indicate if sink supports advanced HDMI 2.0 features - Adds another structure drm_scdc within drm_hdmi_info, to reflect scdc support and capabilities in connected HDMI 2.0 sink. - Checks the HF-VSDB block for presence of SCDC, and marks it in scdc structure - If SCDC is present, checks if sink is capable of generating SCDC read request, and marks it in scdc structure. V2: Addressed review comments Thierry: - Fix typos in commit message and make abbreviation consistent across the commit message. - Change structure object name from hdmi_info -> hdmi - Fix typos and abbreviations in description of structure drm_hdmi_info end the description with a full stop. - Create a structure drm_scdc, and keep all information related to SCDC register set (supported, read request supported) etc in it. Ville: - Change rr -> read_request - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all of HF-VSDB parsing can be kept in same function, in incremental patches. V3: Rebase. V4: Rebase. V5: Rebase. V6: Addressed review comments from Ville - Add clock rate calculations for 1/10 and 1/40 ratios - Remove leftovers from old patchset V7: Added R-B from Jose. V8: Rebase. V9: Rebase. V10: Rebase. Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-5-git-send-email-shashank.sharma@intel.com
2017-03-21drm/edid: detect SCDC support in HF-VSDBShashank Sharma
This patch does following: - Adds a new structure (drm_hdmi_info) in drm_display_info. This structure will be used to save and indicate if sink supports advanced HDMI 2.0 features - Adds another structure drm_scdc within drm_hdmi_info, to reflect scdc support and capabilities in connected HDMI 2.0 sink. - Checks the HF-VSDB block for presence of SCDC, and marks it in scdc structure - If SCDC is present, checks if sink is capable of generating SCDC read request, and marks it in scdc structure. V2: Addressed review comments Thierry: - Fix typos in commit message and make abbreviation consistent across the commit message. - Change structure object name from hdmi_info -> hdmi - Fix typos and abbreviations in description of structure drm_hdmi_info end the description with a full stop. - Create a structure drm_scdc, and keep all information related to SCDC register set (supported, read request supported) etc in it. Ville: - Change rr -> read_request - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all of HF-VSDB parsing can be kept in same function, in incremental patches. V3: Rebase. V4: Rebase. V5: Rebase. V6: Rebase. V7: Added R-B from Jose. V8: Rebase. V9: Rebase. V10: Rebase. Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-4-git-send-email-shashank.sharma@intel.com
2017-03-21drm/edid: check for HF-VSDB blockThierry Reding
This patch implements a small function that finds if a given CEA db is hdmi-forum vendor specific data block or not. V2: Rebase. V3: Added R-B from Jose. V4: Rebase V5: Rebase V6: Rebase V7: Rebase V8: Rebase V9: Rebase V10: Rebase Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-3-git-send-email-shashank.sharma@intel.com
2017-03-21drm: Add SCDC helpersThierry Reding
SCDC is a mechanism defined in the HDMI 2.0 specification that allows the source and sink devices to communicate. This commit introduces helpers to access the SCDC and provides the symbolic names for the various registers defined in the specification. V2: Rebase. V3: Added R-B from Jose. V4: Rebase V5: Addressed review comments from Ville - Handle the I2c return values in a better way (dp_dual_mode) - Make the macros for SCDC Major/Minor more readable, by adding a 'GET' in the macro names V6: Rebase V7: Rebase V8: Rebase V9: Rebase V10: Rebase Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-2-git-send-email-shashank.sharma@intel.com
2017-03-21drm: bridge: dw-hdmi: add HDMI vendor specific infoframe configNickey Yang
Vendor specific infoframe is mandatory for 4K2K resolution. Without this, the HDMI protocol compliance fails. Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1490081777-2232-1-git-send-email-nickey.yang@rock-chips.com
2017-03-21drm/bridge: dw_hdmi: support i2c extended read modeNickey Yang
"I2C Master Interface Extended Read Mode" implements a segment pointer-based read operation using the Special Register configuration. This patch fix https://patchwork.kernel.org/patch/7098101/ mentioned "The current implementation does not support "I2C Master Interface Extended Read Mode" to read data addressed by non-zero segment pointer, this means that if EDID has more than 1 extension blocks, EDID reading operation won't succeed" With this patch, dw-hdmi can read EDID data with 1/2/4 blocks. Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Acked-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1489978651-16647-1-git-send-email-nickey.yang@rock-chips.com
2017-03-20drm/msm: add stubs for msm_{perf,rd}_debugfs_cleanupArnd Bergmann
We now call those two functions even when they are not defined or declared anywhere because DEBUG_FS is disabled: drivers/gpu/drm/msm/msm_drv.c: In function 'msm_drm_uninit': drivers/gpu/drm/msm/msm_drv.c:244:2: error: implicit declaration of function 'msm_perf_debugfs_cleanup';did you mean 'msm_framebuffer_cleanup'? [-Werror=implicit-function-declaration] drivers/gpu/drm/msm/msm_drv.c:245:2: error: implicit declaration of function 'msm_rd_debugfs_cleanup';did you mean 'msm_framebuffer_cleanup'? [-Werror=implicit-function-declaration] This adds empty stub implementations for that case. Fixes: 85eac4700ede ("drm/msm: Remove msm_debugfs_cleanup()") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170320093936.1255573-1-arnd@arndb.de
2017-03-20drm: bochs: Don't remove uninitialized fbdev framebufferGabriel Krisman Bertazi
In the same spirit of the fix for QXL in commit 861078381ba5 ("drm: qxl: Don't alloc fbdev if emulation is not supported"), prevent the Oops in the unbind path of Bochs if fbdev emulation is disabled. [ 112.176009] Oops: 0002 [#1] SMP [ 112.176009] Modules linked in: bochs_drm [ 112.176009] CPU: 0 PID: 3002 Comm: bash Not tainted 4.11.0-rc1+ #111 [ 112.176009] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014 [ 112.176009] task: ffff8800743bbac0 task.stack: ffffc90000b5c000 [ 112.176009] RIP: 0010:mutex_lock+0x18/0x30 [ 112.176009] RSP: 0018:ffffc90000b5fc78 EFLAGS: 00010246 [ 112.176009] RAX: 0000000000000000 RBX: 0000000000000260 RCX: 0000000000000000 [ 112.176009] RDX: ffff8800743bbac0 RSI: ffff8800787176e0 RDI: 0000000000000260 [ 112.176009] RBP: ffffc90000b5fc80 R08: ffffffff00000000 R09: 00000000ffffffff [ 112.176009] R10: ffff88007b463650 R11: 0000000000000000 R12: 0000000000000260 [ 112.176009] R13: ffff8800787176e0 R14: ffffffffa0003068 R15: 0000000000000060 [ 112.176009] FS: 00007f20564c7b40(0000) GS:ffff88007ce00000(0000) knlGS:0000000000000000 [ 112.176009] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 112.176009] CR2: 0000000000000260 CR3: 000000006b89c000 CR4: 00000000000006f0 [ 112.176009] Call Trace: [ 112.176009] drm_mode_object_unregister+0x1e/0x50 [ 112.176009] drm_framebuffer_unregister_private+0x15/0x20 [ 112.176009] bochs_fbdev_fini+0x57/0x70 [bochs_drm] [ 112.176009] bochs_unload+0x16/0x50 [bochs_drm] [ 112.176009] drm_dev_unregister+0x37/0xd0 [ 112.176009] drm_put_dev+0x31/0x60 [ 112.176009] bochs_pci_remove+0x10/0x20 [bochs_drm] [ 112.176009] pci_device_remove+0x34/0xb0 [ 112.176009] device_release_driver_internal+0x150/0x200 [ 112.176009] device_release_driver+0xd/0x10 [ 112.176009] unbind_store+0x108/0x150 [ 112.176009] drv_attr_store+0x20/0x30 [ 112.176009] sysfs_kf_write+0x32/0x40 [ 112.176009] kernfs_fop_write+0x10b/0x190 [ 112.176009] __vfs_write+0x23/0x120 [ 112.176009] ? security_file_permission+0x36/0xb0 [ 112.176009] ? rw_verify_area+0x49/0xb0 [ 112.176009] vfs_write+0xb0/0x190 [ 112.176009] SyS_write+0x41/0xa0 [ 112.176009] entry_SYSCALL_64_fastpath+0x1a/0xa9 [ 112.176009] RIP: 0033:0x7f2055bd5620 [ 112.176009] RSP: 002b:00007ffed2f487d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 112.176009] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f2055bd5620 [ 112.176009] RDX: 000000000000000d RSI: 0000000000ee0008 RDI: 0000000000000001 [ 112.176009] RBP: 0000000000000001 R08: 00007f2055e94760 R09: 00007f20564c7b40 [ 112.176009] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000000 [ 112.176009] R13: 00007ffed2f48d70 R14: 0000000000000000 R15: 0000000000000000 [ 112.176009] Code: 00 00 00 55 be 02 00 00 00 48 89 e5 e8 62 fb ff ff 5d c3 55 48 89 e5 53 48 89 fb e8 53 e9 ff ff 65 48 8b 14 25 40 c4 00 00 31 c0 <f0> 48 0f b1 13 48 85 c0 74 08 48 89 df e8c6 ff ff ff 5b 5d c3 [ 112.176009] RIP: mutex_lock+0x18/0x30 RSP: ffffc90000b5fc78 [ 112.176009] CR2: 0000000000000260 [ 112.205622] ---[ end trace 76189cd7a9bdd155 ]--- Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170317181409.4183-1-krisman@collabora.co.uk Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-03-17drm: vc4: remove redundant check of plane being non-nullColin Ian King
The pointer plane is always null on the error path at label 'fail' hence the check if it is non-null is redundant. We can therefore remove the check and the destruction of plane as well as the fail error path and instead just return an -ENOMEM ERR_PTR. Detected by CoverityScan, CID#1339532 ("Logically Dead Code") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Eric Anholt <eric@anholt.net> Link: http://patchwork.freedesktop.org/patch/msgid/20170316185418.32765-1-colin.king@canonical.com
2017-03-17drm/vc4: use platform_register_driversPhilipp Zabel
Use platform_register_drivers instead of open coding the iteration over component platform drivers in the vc4_drv module. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Eric Anholt <eric@anholt.net> Link: http://patchwork.freedesktop.org/patch/msgid/20170317170059.17821-1-p.zabel@pengutronix.de
2017-03-17dma-fence: add dma_fence_match_context helperPhilipp Zabel
Add a helper to check if all fences in a fence array are from a given context. For convenience, the function can also handle being given a non-array fence. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: http://patchwork.freedesktop.org/patch/msgid/1489768492-25190-1-git-send-email-p.zabel@pengutronix.de
2017-03-16drm/vc4: Add HDMI audio supportEric Anholt
The HDMI encoder IP embeds all needed blocks to output audio, with a custom DAI called MAI moving audio between the two parts of the HDMI core. This driver now exposes a sound card to let users stream audio to their display. Using the hdmi-codec driver has been considered here, but MAI meant having to significantly rework hdmi-codec, and it would have left little shared code with the I2S mode anyway. The encoder requires that the audio be SPDIF-formatted frames only, which alsalib will format-convert for us. This patch is the combined work of Eric Anholt (initial register setup with a separate dmaengine driver and using simple-audio-card) and Boris Brezillon (moving it all into HDMI, massive debug to get it actually working), and which Eric has the permission to release. v2: Drop "-audio" from sound card name, since that's already implied (suggestion by Boris) Signed-off-by: Eric Anholt <eric@anholt.net> Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170227202803.12855-2-eric@anholt.net
2017-03-16dt-bindings: Document the dmas and dma-names properties for VC4 HDMIBoris Brezillon
These are optional, but necessary for HDMI audio support. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Eric Anholt <eric@anholt.net> Acked-by: Rob Herring <robh@kernel.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170227202803.12855-1-eric@anholt.net
2017-03-16drm/atmel-hlcdc: Fix suspend/resume implementationBoris Brezillon
The current suspend resume implementation is assuming register values are kept when entering suspend, which is no longer the case with the suspend-to-RAM on the sama5d2. While at it, switch to the generic infrastructure to enter suspend mode (drm_atomic_helper_suspend/resume()). Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: Sylvain Rochet <sylvain.rochet@finsecur.com> Link: http://patchwork.freedesktop.org/patch/msgid/1488371461-22243-1-git-send-email-boris.brezillon@free-electrons.com
2017-03-16drm: Skip the waitqueue setup for vblank queriesChris 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: Chris 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: Michel Dänzer <michel@daenzer.net> Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170315204027.20160-2-chris@chris-wilson.co.uk
2017-03-16drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off)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: Chris 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: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170315204027.20160-1-chris@chris-wilson.co.uk
2017-03-14drm/doc: atomic overview, with graphDaniel Vetter
I want to split up a few more things and document some details better (like how exactly to subclass drm_atomic_state). And maybe also split up the helpers a bit per-topic, but this should be a ok-ish start for better atomic overview. v2: Spelling and clarifications (Eric). v3: Implement suggestion from Gabriel to fix the graph. v4: Review from Laurent. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Acked-by: Eric Anholt <eric@anholt.net> Cc: Eric Anholt <eric@anholt.net> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170302151638.1882-6-daniel.vetter@ffwll.ch
2017-03-14drm/doc: diagram for mode objects and propertiesDaniel Vetter
Resulted in confusion a few times in the past. v2: Spelling fix (Eric). Cc: Eric Anholt <eric@anholt.net> Acked-by: Eric Anholt <eric@anholt.net> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170302151638.1882-5-daniel.vetter@ffwll.ch
2017-03-14drm/doc: Consistent kerneldoc include orderDaniel Vetter
First overview text (if there is any), then headers (since generally you want to start out with the data structures), then all the other stuff with functions. Most of this is pre-shpinx, since with the old docbook only the overview stuff was pulled in directly. Everything else was put in a per-section index, so include order didn't really matter. Acked-by: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170302151638.1882-4-daniel.vetter@ffwll.ch
2017-03-14drm/doc: Add KMS overview graphsDaniel Vetter
Oh, the shiny and pretties! v2: Review from Laurent. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Eric Anholt <eric@anholt.net> Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170302151638.1882-3-daniel.vetter@ffwll.ch
2017-03-14Merge tag 'doc-4.11-images' of git://git.lwn.net/linux into drm-misc-nextDaniel Vetter
Pointer for Markus's image conversion work. We need this so we can merge all the pretty drm graphs for 4.12. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2017-03-14drm/gem: Add DEFINE_DRM_GEM_FOPSDaniel 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: 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
2017-03-14drm: Create DEFINE_DRM_GEM_CMA_FOPS and roll it out to driversDaniel 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: 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-24-daniel.vetter@ffwll.ch
2017-03-14drm/vgem: switch to postcloseDaniel 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: 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-18-daniel.vetter@ffwll.ch
2017-03-14drm/doc: Document drm_file.[hc]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: 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-12-daniel.vetter@ffwll.ch
2017-03-14drm: Remove drm_pending_event->pidDaniel 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 b9c2c9ae882f058084e13e339925dbf8d2d20271 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: Sean Paul <seanpaul@chromium.org> Reviewed-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-11-daniel.vetter@ffwll.ch
2017-03-14drm: qxl: add missing return checkDan 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: Dan Carpenter <dan.carpenter@oracle.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170314075410.GB5984@mwanda Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-03-14drm: virtio: fix kmem_cache_alloc error checkGerd Hoffmann
kmem_cache_alloc returns NULL on error, not ERR_PTR. Fixes: f5985bf9cadd4e3ed8d5d9a9cbbb2e39cdb81cd9 Reported-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1489393346-13874-1-git-send-email-kraxel@redhat.com
2017-03-14drm/tinydrm: fix semicolon.cocci warningskbuild 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: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170312144636.GA91808@lkp-g5.lkp.intel.com
2017-03-13drm/rockchip: cdn-dp: add more log for video configChris Zhong
In order to analyze some video config failed, add some useful printouts. Signed-off-by: Chris Zhong <zyw@rock-chips.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1488940077-22297-4-git-send-email-zyw@rock-chips.com
2017-03-13drm/rockchip: cdn-dp: Correct PHY register addressChris Zhong
Correct some DP register address for PHY Configuration according to latest datasheet. Signed-off-by: Chris Zhong <zyw@rock-chips.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1488940077-22297-3-git-send-email-zyw@rock-chips.com
2017-03-13drm/rockchip: cdn-dp: return error code when clk_get_rate failedChris 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: Chris Zhong <zyw@rock-chips.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1488940077-22297-2-git-send-email-zyw@rock-chips.com
2017-03-11Merge branch 'drm/next/platform' of git://linuxtv.org/pinchartl/media into ↵Daniel Vetter
drm-misc-next 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: Daniel Vetter <daniel.vetter@intel.com>
2017-03-10drm: bridge: dw-hdmi: Move the driver to a separate directory.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: 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
2017-03-10drm: bridge: dw-hdmi: Switch to regmap for register accessNeil 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: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jose Abreu <Jose.Abreu@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
2017-03-10drm: bridge: dw-hdmi: Remove device type from platform dataKieran 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: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Neil Armstrong <narmstrong@baylibre.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-9-laurent.pinchart+renesas@ideasonboard.com
2017-03-10drm: bridge: dw-hdmi: Add support for custom PHY configurationKieran 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: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-8-laurent.pinchart+renesas@ideasonboard.com
2017-03-10drm: bridge: dw-hdmi: Create PHY operationsLaurent 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: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170305233615.11993-1-laurent.pinchart+renesas@ideasonboard.com
2017-03-10drm: bridge: dw-hdmi: Fix the PHY power up sequenceLaurent 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: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170305233557.11945-1-laurent.pinchart+renesas@ideasonboard.com
2017-03-10drm: bridge: dw-hdmi: Fix the PHY power down sequenceLaurent 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: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170305233539.11898-1-laurent.pinchart+renesas@ideasonboard.com
2017-03-10drm: bridge: dw-hdmi: Enable CSC even for DVINeil 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: Jose Abreu <joabreu@synopsys.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-4-laurent.pinchart+renesas@ideasonboard.com
2017-03-10drm: bridge: dw-hdmi: Move CSC configuration out of PHY codeLaurent Pinchart
The color space converter isn't part of the PHY, move its configuration out of PHY code. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Neil Armstrong <narmstrong@baylibre.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-3-laurent.pinchart+renesas@ideasonboard.com
2017-03-10drm: bridge: dw-hdmi: Remove unused functionsLaurent Pinchart
Most of the hdmi_phy_test_*() functions are unused. Remove them. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Tested-by: Nickey Yang <nickey.yang@rock-chips.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-2-laurent.pinchart+renesas@ideasonboard.com
2017-03-09drm: Extract drm_file.hDaniel 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: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-10-daniel.vetter@ffwll.ch
2017-03-09drm: Remove DRM_MINOR_CNTDaniel Vetter
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 <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-9-daniel.vetter@ffwll.ch
2017-03-09drm: rename drm_fops.c to drm_file.cDaniel 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: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-8-daniel.vetter@ffwll.ch
2017-03-09drm/doc: document fallback behaviour for atomic eventsDaniel Vetter
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: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-7-daniel.vetter@ffwll.ch
2017-03-09drm: Remove drmP.h include from drm_kms_helper_common.cDaniel Vetter
An easy one as a drive-by. Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-6-daniel.vetter@ffwll.ch
2017-03-09drm: Extract drm_pci.hDaniel Vetter
Just another step in finally making drmP.h obsolete. Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-5-daniel.vetter@ffwll.ch
2017-03-09drm: Move drm_lock_data out of drmP.hDaniel Vetter
And remove the semi-kernel-doc stuff, to make sure no one uses this. Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-4-daniel.vetter@ffwll.ch
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-18 12:09:25 +0000