- 27 Jan, 2017 1 commit
-
-
Philipp Zabel authored
Vivante GC hardware uses simple 4x4 tiled and nested 64x64 supertiled formats as well as so-called split-tiled variants for dual-pipe hardware, where even and odd tiles start at different base addresses. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-By: Wladimir J. van der Laan <laanwj@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170126153217.26916-1-p.zabel@pengutronix.de
-
- 26 Jan, 2017 14 commits
-
-
Ville Syrjälä authored
CEA-861-F tells us: "When transmitting any RGB colorimetry, the Source should set the YQ-field to match the RGB Quantization Range being transmitted (e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB, set YQ=1) and the Sink shall ignore the YQ-field." So let's go ahead and do that. Perhaps there are sinks that don't ignore the YQ as they should for RGB? I wasn't able to find similar text in CEA-861-E, so it would seem to be a fairly "recent" addition. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170111125725.8086-6-ville.syrjala@linux.intel.comReviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Eric Anholt <eric@anholt.net>
-
Ville Syrjälä authored
HDMI 2.0 recommends that we set the Q bits in the AVI infoframe even when the sink does not support quantization range selection (QS=0). According to CEA-861 we can do that as long as the Q we send matches the default quantization range for the mode. Previously I think I had misread the spec as saying that you can't send a non-zero Q at all when QS=0. But that's not what the spec actually says. v2: Fix typo in commit message (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170111125725.8086-5-ville.syrjala@linux.intel.comReviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Eric Anholt <eric@anholt.net>
-
Ville Syrjälä authored
Pull the logic to populate the quantization range information in the AVI infoframe into a small helper. We'll be adding a bit more logic to it, and having it in a central place seems like a good idea since it's based on the CEA-861 spec. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170111125725.8086-4-ville.syrjala@linux.intel.comReviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Eric Anholt <eric@anholt.net>
-
Ville Syrjälä authored
Make the code selecting the RGB quantization range a little less magicy by wrapping it up in a small helper. v2: s/adjusted_mode/mode in vc4 to make it actually compile v3: Add a comment proposed by Eric Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170111141835.25369-1-ville.syrjala@linux.intel.comReviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Eric Anholt <eric@anholt.net>
-
Ville Syrjälä authored
drm_edid.h depends on hdmi.h on account of enum hdmi_picture_aspect, so let's just include hdmi.h and drop some useless struct declarations. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170111125725.8086-2-ville.syrjala@linux.intel.comReviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Eric Anholt <eric@anholt.net>
-
Chris Wilson authored
Since moving drm_crtc_get_hv_timings() into drm_modes.c, the compiler has been able to get smarter and spots that drm_mode_copy() is trying to preserve garbage from the stack. Fixes: 196cd5d3 ("drm: s/drm_crtc_get_hv_timings/drm_mode_get_hv_timings/") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170126114409.9115-1-chris@chris-wilson.co.uk
-
Daniel Vetter authored
There's no late_unregister. While at it switch to the new canonical reference style. Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-14-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
The function operates on modes, not CRTCs. Also move it into drm_modes.[hc]. Spotted while reviewing CRTC docs. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-15-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
No point in documenting these, they only confuse. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-13-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
i915, nouveau (ever since merged to upstream) and radeon all lack ums support in upstream. No point keeping the ums vgaarb support around. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-12-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
With that the drm_pci_device_is_agp function becomes trivial, so inline that too. And while at it, move the drm_pci_agp_destroy declaration into drm-internal.h, since it's not used by drivers. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-11-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
It's only for a device quirk, and we might as well do that in the load callback. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-10-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Use the same trick we used for i915 when we still had ums support: Just initialize the agp support unconditionally in the driver load function. Unfortunately that means we need to export drm_agp_init again, but I think that's a lesser evil. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-9-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
There was a bit of mix-up between initialization and registering. v2: Review from Gustavo. Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-7-daniel.vetter@ffwll.ch Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-8-daniel.vetter@ffwll.ch
-
- 25 Jan, 2017 7 commits
-
-
Daniel Vetter authored
After going through all the trouble of splitting out parts from drm_crtc.[hc] and then properly documenting each I've entirely forgotten to show the same TLC for CRTCs themselves! Let's make amends asap. v2: Review from Eric. Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
-
Daniel Vetter authored
Returning 0 for an on-chip gpu doesn't change anything at all. Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-8-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
I just learned that &struct_name.member_name works and looks pretty even. It doesn't (yet) link to the member directly though, which would be really good for big structures or vfunc tables (where the per-member kerneldoc tends to be long). Also some minor drive-by polish where it makes sense, I read a lot of docs ... v2: Review from Eric. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-4-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
I just learned that &struct_name.member_name works and looks pretty even. It doesn't (yet) link to the member directly though, which would be really good for big structures or vfunc tables (where the per-member kerneldoc tends to be long). Also some minor drive-by polish where it makes sense, I read a lot of docs ... v2: Review from Gustavo. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-6-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
I just learned that &struct_name.member_name works and looks pretty even. It doesn't (yet) link to the member directly though, which would be really good for big structures or vfunc tables (where the per-member kerneldoc tends to be long). Also some minor drive-by polish where it makes sense, I read a lot of docs ... Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-5-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
I just learned that &struct_name.member_name works and looks pretty even. It doesn't (yet) link to the member directly though, which would be really good for big structures or vfunc tables (where the per-member kerneldoc tends to be long). Also some minor drive-by polish where it makes sense, I read a lot of docs ... v2: Comments from Gustavo. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Rewiewed-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-2-daniel.vetter@ffwll.ch
-
Dhinakaran Pandiyan authored
struct drm_dp_mst_topology_mgr currently stores a pointer to struct dev. Changing this to instead hold a pointer to drm_device is more useful as it gives access to DRM structures. This also makes it consistent with other DRM structures like drm_crtc, drm_connector etc. Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1485301777-3465-2-git-send-email-dhinakaran.pandiyan@intel.com
-
- 24 Jan, 2017 5 commits
-
-
Chris Wilson authored
For the convenience of encapsulation the reservation object's ww_mutex was wrapped in pair of lock/unlock helpers. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170123095357.29514-1-chris@chris-wilson.co.uk
-
Noralf Trønnes authored
Add missing includes to pull in definitions for drm_crtc, drm_plane and drm_encoder. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170122181117.8210-4-noralf@tronnes.org
-
Noralf Trønnes authored
Add a CMA version of drm_fb_helper_set_suspend_unlocked(). Cc: laurent.pinchart@ideasonboard.com Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170122181117.8210-2-noralf@tronnes.org
-
Chris Wilson authored
The prototypes were moved to a new header, but the function definitions were not updated to pull in the declarations. drivers/gpu/drm/drm_cache.c:79:1: warning: no previous prototype for ‘drm_clflush_pages’ [-Wmissing-prototypes] drivers/gpu/drm/drm_cache.c:120:1: warning: no previous prototype for ‘drm_clflush_sg’ [-Wmissing-prototypes] drivers/gpu/drm/drm_cache.c:152:1: warning: no previous prototype for ‘drm_clflush_virt_range’ [-Wmissing-prototypes] Fixes: f9a87bd7 ("drm: Move drm_clflush prototypes to drm_cache header file") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170121181944.24672-1-chris@chris-wilson.co.uk
-
Arnd Bergmann authored
The of_node member in struct drm_bridge is hidden when CONFIG_OF is disabled, causing a build error: drivers/gpu/drm/bridge/dw-hdmi.c: In function '__dw_hdmi_probe': drivers/gpu/drm/bridge/dw-hdmi.c:2063:14: error: 'struct drm_bridge' has no member named 'of_node' We could fix this either using a Kconfig dependency on CONFIG_OF or making the one line conditional. The latter gives us better compile test coverage, so this is what I'm doing here. Fixes: 69497eb9 ("drm: bridge: dw-hdmi: Implement DRM bridge registration") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170123122312.3290934-1-arnd@arndb.de
-
- 23 Jan, 2017 5 commits
-
-
Tobias Jakobi authored
While the Kconfig entries of FIMD and DECON7 both select FB_MODE_HELPERS, the code doesn't use any of the functionality. Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1484928172-16784-1-git-send-email-tjakobi@math.uni-bielefeld.de
-
Chris Wilson authored
After warning that the connector list is not empty on device unregistration (i.e. module unload) also print out which connectors are still hanging around to aide finding the leak. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170119090513.4154-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
The allocation for the bitmap may become very large, larger than MAX_ORDER, for large requests. We fail gracefully by falling back to trail-division, so disable the warning from kmalloc: 521.961092] WARNING: CPU: 0 PID: 30637 at mm/page_alloc.c:3548 __alloc_pages_slowpath+0x237/0x9a0 [ 521.961105] Modules linked in: i915(+) drm_kms_helper intel_gtt prime_numbers [last unloaded: drm_kms_helper] [ 521.961126] CPU: 0 PID: 30637 Comm: drv_selftest Tainted: G U W 4.10.0-rc3+ #321 [ 521.961137] Hardware name: / , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015 [ 521.961148] Call Trace: [ 521.961161] dump_stack+0x4d/0x6f [ 521.961172] __warn+0xc1/0xe0 [ 521.961181] warn_slowpath_null+0x18/0x20 [ 521.961189] __alloc_pages_slowpath+0x237/0x9a0 [ 521.961200] ? sg_init_table+0x1a/0x40 [ 521.961208] ? get_page_from_freelist+0x3fa/0x910 [ 521.961275] ? i915_gem_object_get_sg+0x272/0x2b0 [i915] [ 521.961285] __alloc_pages_nodemask+0x1ea/0x220 [ 521.961295] kmalloc_order+0x1c/0x50 [ 521.961304] __kmalloc+0x115/0x170 [ 521.961314] expand_to_next_prime+0x43/0x180 [prime_numbers] [ 521.961324] next_prime_number+0x47/0xc0 [prime_numbers] [ 521.961377] igt_vma_rotate+0x386/0x590 [i915] [ 521.961429] i915_subtests+0x37/0xc0 [i915] [ 521.961481] i915_vma_mock_selftests+0x3d/0x70 [i915] [ 521.961532] run_selftests+0x16e/0x1f0 [i915] [ 521.961541] ? 0xffffffffa02a4000 [ 521.961592] i915_mock_selftests+0x29/0x40 [i915] [ 521.961638] i915_init+0xa/0x5e [i915] [ 521.961646] ? 0xffffffffa02a4000 [ 521.961655] do_one_initcall+0x3e/0x160 [ 521.961664] ? __vunmap+0x7c/0xc0 [ 521.961672] ? vfree+0x29/0x70 [ 521.961680] ? kmem_cache_alloc+0xcf/0x120 [ 521.961690] do_init_module+0x55/0x1c4 [ 521.961699] load_module+0x1f3f/0x25b0 [ 521.961707] ? __symbol_put+0x40/0x40 [ 521.961716] ? kernel_read_file+0x100/0x190 [ 521.961725] SYSC_finit_module+0xbc/0xf0 [ 521.961734] SyS_finit_module+0x9/0x10 [ 521.961744] entry_SYSCALL_64_fastpath+0x17/0x98 [ 521.961752] RIP: 0033:0x7f111aca4119 [ 521.961760] RSP: 002b:00007ffd8be6cbe8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 521.961773] RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00007f111aca4119 [ 521.961781] RDX: 0000000000000000 RSI: 000055dfc18bc8e0 RDI: 0000000000000006 [ 521.961789] RBP: 00007ffd8be6bbe0 R08: 0000000000000000 R09: 0000000000000000 [ 521.961796] R10: 0000000000000006 R11: 0000000000000246 R12: 0000000000000005 [ 521.961805] R13: 000055dfc18bd3a0 R14: 00007ffd8be6bbc0 R15: 0000000000000005 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170113235119.22528-1-chris@chris-wilson.co.uk
-
Wei Yongjun authored
PTR_ERR should access the value just tested by IS_ERR, otherwise the wrong error code will be returned. Fixes: d1667b86 ("drm/hisilicon/hibmc: Add support for frame buffer") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170112151921.16538-1-weiyj.lk@gmail.com
-
Wei Yongjun authored
Fixes the following sparse warning: drivers/gpu/drm/drm_atomic_helper.c:1360:6: warning: symbol 'release_crtc_commit' was not declared. Should it be static? Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170112142157.14684-1-weiyj.lk@gmail.com
-
- 19 Jan, 2017 8 commits
-
-
Gabriel Krisman Bertazi authored
This avoids using the deprecated drm_put_dev() and unload() hook interfaces in the qxl driver. Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Cc: Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170119134806.8926-2-krisman@collabora.co.uk
-
Gabriel Krisman Bertazi authored
This avoids using the deprecated drm_get_pci_dev() and load() hook interfaces in the qxl driver. The only tricky part is to ensure TTM debugfs initialization happens after the debugfs root node is created, which is done by moving that code into the debufs_init() hook. Tested on qemu with igt and running a WM on top of X. Changes since v1: - Drop verification for primary minor in qxl_debugsfs_init. Changes since V2: - Put new header together with other debugfs headers. Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Cc: Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170119134806.8926-1-krisman@collabora.co.uk
-
John Stultz authored
I've found that by just turning the chip on and off via the POWER_DOWN register, I end up getting i2c_transfer errors on HiKey. Investigating further, it turns out that some of the register state in hardware is getting lost, as the device registers are reset when the chip is powered down. Thus this patch simply re-writes the i2c address to the ADV7511_REG_EDID_I2C_ADDR register to ensure its properly set before we try to read the EDID data. Cc: David Airlie <airlied@linux.ie> Cc: Archit Taneja <architt@codeaurora.org> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-7-git-send-email-john.stultz@linaro.org
-
John Stultz authored
Thus this patch changes the EDID probing logic so that we re-use the __adv7511_power_on/off() calls instead of duplciating logic. This does change behavior slightly as it adds the HPD signal pulse to the EDID probe path, but Archit has had a patch to add HPD signal pulse to the EDID probe path before, so this should address the cases where that helped. Another difference is that regcache_mark_dirty() is also called in the power off path once EDID is probed. Cc: David Airlie <airlied@linux.ie> Cc: Archit Taneja <architt@codeaurora.org> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-6-git-send-email-john.stultz@linaro.org
-
John Stultz authored
In chasing down issues with EDID probing, I found some duplicated but incomplete logic used to power the chip on and off. This patch refactors the adv7511_power_on/off functions, so they can be used for internal needs. Cc: David Airlie <airlied@linux.ie> Cc: Archit Taneja <architt@codeaurora.org> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-5-git-send-email-john.stultz@linaro.org
-
Archit Taneja authored
On some adv7511 implementations, we can get some spurious disconnect signals which can cause monitor probing to fail. This patch enables HPD (hot plug detect) interrupt support which allows the monitor to be properly re-initialized when the spurious disconnect signal goes away. This also enables proper hotplug support. Cc: David Airlie <airlied@linux.ie> Cc: Archit Taneja <architt@codeaurora.org> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: dri-devel@lists.freedesktop.org Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Originally-by: Archit Taneja <architt@codeaurora.org> [jstultz: Added proper commit message] Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-4-git-send-email-john.stultz@linaro.org
-
John Stultz authored
In chasing down a previous issue with EDID probing from calling drm_helper_hpd_irq_event() from irq context, Laurent noticed that the DRM documentation suggests that drm_kms_helper_hotplug_event() should be used instead. Thus this patch replaces drm_helper_hpd_irq_event() with drm_kms_helper_hotplug_event(), which requires we update the connector.status entry and only call _hotplug_event() when the status changes. Cc: David Airlie <airlied@linux.ie> Cc: Archit Taneja <architt@codeaurora.org> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-3-git-send-email-john.stultz@linaro.org
-
John Stultz authored
I was recently seeing issues with EDID probing, where the logic to wait for the EDID read bit to be set by the IRQ wasn't happening and the code would time out and fail. Digging deeper, I found this was due to the fact that IRQs were disabled as we were running in IRQ context from the HPD signal. Thus this patch changes the logic to handle the HPD signal via a work_struct so we can be out of irq context. With this patch, the EDID probing on hotplug does not time out. Cc: David Airlie <airlied@linux.ie> Cc: Archit Taneja <architt@codeaurora.org> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-2-git-send-email-john.stultz@linaro.org
-