- 22 Oct, 2016 1 commit
-
-
Ville Syrjälä authored
The global mode_config.rotation_property is going away, switch over to per-plane rotation_property. v2: Drop the BIT() Cc: Rob Clark <robdclark@gmail.com> Cc: Jilai Wang <jilaiw@codeaurora.org> Cc: Archit Taneja <architt@codeaurora.org> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1477077768-4274-2-git-send-email-ville.syrjala@linux.intel.com
-
- 21 Oct, 2016 12 commits
-
-
Chris Wilson authored
We have reached the era where monitor bandwidths now exceed 31bits in frequency calculations, though as we stored them in kHz units we are safe from overflow in the modelines for some time. [ 48.723720] UBSAN: Undefined behaviour in ../drivers/gpu/drm/drm_modes.c:325:49 [ 48.726943] signed integer overflow: [ 48.728503] 2240 * 1000000 cannot be represented in type 'int' Reported-by:
Martin Liška <marxin.liska@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98372Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Ville Syrjälä authored
On certain platforms not all planes support the same set of rotations/reflections, so let's use the per-plane property for this. This is already a problem on SKL when we use the legay cursor plane as it only supports 0|180 whereas the universal planes support 0|90|180|270, and it will be a problem on CHV soon. v2: Use drm_plane_create_rotation_property() helper v3: Drop the BIT(), use INTEL_GEN() Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
The global mode_config.rotation_property is going away, switch over to per-plane rotation_property. Not sure I got the annoying crtc rotation_property handling right. Might work, or migth not. v2: Drop the BIT() Don't create rotation property twice for each primary plane Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Rob Clark <robdclark@gmail.com> Signed-off-by:Tomi Valkeinen <tomi.valkeinen@ti.com> [danvet: Add comment per discussion between Tomi&Ville.] Signed-off-by:
-
Ville Syrjälä authored
0 isn't a valid rotation property value, so let's set the initial value of the property to BIT(DRM_ROTATE_0) instead. v2: Drop the BIT() Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Rob Clark <robdclark@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
The global mode_config.rotation_property is going away, switch over to per-plane rotation_property. v2: Propagate error upwards (Boris) v3: Drop the BIT() Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
-
Ville Syrjälä authored
The global mode_config.rotation_property is going away, switch over to per-plane rotation_property. v2: Drop the BIT() Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Brian Starkey <brian.starkey@arm.com> Cc: Mali DP Maintainers <malidp@foss.arm.com> Signed-off-by:
Brian Starkey <brian.starkey@arm.com> Signed-off-by:
-
Ville Syrjälä authored
Not all planes on the system may support the same rotations/reflections, so make it possible to create a separate property for each plane. This way userspace gets told exactly which rotations/reflections are possible for each plane. v2: Add drm_plane_create_rotation_property() helper v3: Drop the BIT(), __builtin_ffs(x) - 1, Moar WARNs for bad parameters Deal with superfluous code shuffling Signed-off-by: -
Ville Syrjälä authored
The rotation property should only accept exactly one rotation angle at once. Let's reject attempts to set none or multiple angles. Testcase: igt/kms_rotation_crc/bad-rotation Signed-off-by:
-
Ville Syrjälä authored
We have intel_rotation_90_or_270() in i915 to check if the rotation is 90 or 270 degrees. Similar checks are elsewhere in drm, so let's move the helper into a central place and use it everwhere. v2: Drop the BIT() Convert all new intel_rotation_90_or_270() calls Deal with superfluous code shuffling Signed-off-by: -
Gustavo Padovan authored
fence referencing was out of balance. It was not taking any ref to the fence at creating time, but it was putting a reference when freeing the sync file. This patch fixes the balancing issue by getting a reference for the fence when creating the sync_file. Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1476899313-22241-1-git-send-email-gustavo@padovan.org
-
Peter Griffin authored
Use tabs instead of spaces. Signed-off-by:
Peter Griffin <peter.griffin@linaro.org> Acked-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Gustavo Padovan authored
If the event gets canceled we also need to put away the fence reference it holds. Signed-off-by:
-
- 20 Oct, 2016 2 commits
-
-
Chris Wilson authored
In the error path, we have to be ready to handle an error before either the state or restore_state have been allocated. [ 397.001342] BUG: unable to handle kernel NULL pointer dereference at (null) [ 397.001419] IP: [<ffffffffa04347b4>] intel_get_load_detect_pipe+0xe4/0x610 [i915] [ 397.001502] PGD 136a2a067 [ 397.001523] PUD 134b5f067 [ 397.001546] PMD 0 [ 397.001569] Oops: 0002 [#1] PREEMPT SMP [ 397.001599] Modules linked in: snd_hda_intel i915 cdc_ncm usbnet mii x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm lpc_ich mei_me mei sdhci_pci sdhci mmc_core e1000e ptp pps_core [last unloaded: i915] [ 397.001902] CPU: 1 PID: 9287 Comm: kms_force_conne Tainted: G U 4.9.0-rc1-CI-CI_DRM_1730+ #1 [ 397.001965] Hardware name: LENOVO 2356GCG/2356GCG, BIOS G7ET31WW (1.13 ) 07/02/2012 [ 397.002017] task: ffff880138c38040 task.stack: ffffc900083e4000 [ 397.002057] RIP: 0010:[<ffffffffa04347b4>] [<ffffffffa04347b4>] intel_get_load_detect_pipe+0xe4/0x610 [i915] [ 397.002153] RSP: 0018:ffffc900083e7ae8 EFLAGS: 00010286 [ 397.002191] RAX: 00000000ffffffdd RBX: ffffc900083e7bc8 RCX: 0000000000000006 [ 397.002239] RDX: 0000000000000006 RSI: ffff880138c388b8 RDI: ffffc900083e79e0 [ 397.002287] RBP: ffffc900083e7b78 R08: 0000000000000000 R09: 0000000000000000 [ 397.002335] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 397.002386] R13: ffff8801305e1158 R14: 00000000ffffffdd R15: 0000000000000000 [ 397.002434] FS: 00007fea1b03c740(0000) GS:ffff88013e240000(0000) knlGS:0000000000000000 [ 397.002488] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 397.002528] CR2: 0000000000000000 CR3: 00000001361da000 CR4: 00000000001406e0 [ 397.002576] Stack: [ 397.002592] ffff88013046f180 0000000000000000 ffffc900083e7bc0 0000000000000000 [ 397.002655] 0000000000000000 ffff8801306bd038 ffff88012e980000 ffffc90000000001 [ 397.002718] ffffc90000000000 ffff880136b8ca88 ffff88012e980890 ffff88012e980540 [ 397.002780] Call Trace: [ 397.002828] [<ffffffffa044e8c4>] intel_crt_detect+0x3c4/0x8f0 [i915] [ 397.002876] [<ffffffff810e37fa>] ? vprintk_default+0x1a/0x20 [ 397.002918] [<ffffffff8116eb68>] ? printk+0x43/0x4b [ 397.002956] [<ffffffff81546b06>] drm_helper_probe_single_connector_modes+0x406/0x4f0 [ 397.003014] [<ffffffff81819c09>] ? mutex_unlock+0x9/0x10 [ 397.003054] [<ffffffff815723dc>] drm_mode_getconnector+0x33c/0x3c0 [ 397.003099] [<ffffffff810ed59d>] ? debug_lockdep_rcu_enabled+0x1d/0x20 [ 397.003147] [<ffffffff811a6bae>] ? __might_fault+0x3e/0x90 [ 397.003191] [<ffffffff8155aaf6>] drm_ioctl+0x1f6/0x480 [ 397.003231] [<ffffffff815720a0>] ? drm_mode_connector_property_set_ioctl+0x30/0x30 [ 397.003285] [<ffffffff8120308e>] do_vfs_ioctl+0x8e/0x690 [ 397.003324] [<ffffffff810a102c>] ? task_work_run+0x8c/0xb0 [ 397.003366] [<ffffffff810d6d92>] ? trace_hardirqs_on_caller+0x122/0x1b0 [ 397.003412] [<ffffffff812036cc>] SyS_ioctl+0x3c/0x70 [ 397.003451] [<ffffffff8181df2e>] entry_SYSCALL_64_fastpath+0x1c/0xb1 [ 397.003496] Code: 85 c0 41 89 c6 75 57 49 8b 85 f0 00 00 00 48 89 de 45 31 ff 48 8d 78 20 e8 1a 89 13 e1 45 31 c9 85 c0 41 89 c6 0f 84 2f 01 00 00 <f0> 41 83 29 01 74 53 f0 41 83 2f 01 74 2d 41 83 fe dd 75 35 48 [ 397.003837] RIP [<ffffffffa04347b4>] intel_get_load_detect_pipe+0xe4/0x610 [i915] [ 397.003921] RSP <ffffc900083e7ae8> [ 397.003947] CR2: 0000000000000000 Testcase: igt/kms_force_connector_basic/force-load-detect # ivb-3720m Fixes: 0853695c ("drm: Add reference counting to drm_atomic_state" Signed-off-by:
-
Stefan Agner authored
If fbdev emulation is not in use (or not built-in), fb_helper.fbdev is NULL. Don't call calling drm_fbdev_cma_defio_fini in this case. Signed-off-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
-
- 19 Oct, 2016 3 commits
-
-
Jani Nikula authored
Fixes sparse warnings: drivers/gpu/drm/drm_debugfs_crc.c:118:30: warning: symbol 'drm_crtc_crc_control_fops' was not declared. Should it be static? drivers/gpu/drm/drm_debugfs_crc.c:264:30: warning: symbol 'drm_crtc_crc_data_fops' was not declared. Should it be static? drivers/gpu/drm/drm_debugfs_crc.c:281:5: warning: symbol 'drm_debugfs_crtc_crc_add' was not declared. Should it be static? Fixes: 9edbf1fa ("drm: Add API for capturing frame CRCs") Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.velikov@collabora.com> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1476790115-28665-1-git-send-email-jani.nikula@intel.com
-
Stephen Boyd authored
These GPU drivers only depend on the RESET_CONTROLLER config option to fix build issues that existed when there weren't stub reset APIs for reset controller consumers. Given that these drivers aren't providing any reset controllers themselves, they don't actually depend on the API to build (just to function) so they don't need to depend on it. Remove the dependency to fix recursive build errors like the following: drivers/usb/Kconfig:39:error: recursive dependency detected! drivers/usb/Kconfig:39: symbol USB is selected by MOUSE_APPLETOUCH drivers/input/mouse/Kconfig:187: symbol MOUSE_APPLETOUCH depends on INPUT drivers/input/Kconfig:8: symbol INPUT is selected by VT drivers/tty/Kconfig:12: symbol VT is selected by FB_STI drivers/video/fbdev/Kconfig:674: symbol FB_STI depends on FB drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:42: symbol DRM_KMS_FB_HELPER is selected by DRM_KMS_CMA_HELPER drivers/gpu/drm/Kconfig:98: symbol DRM_KMS_CMA_HELPER is selected by DRM_IMX drivers/gpu/drm/imx/Kconfig:1: symbol DRM_IMX depends on IMX_IPUV3_CORE drivers/gpu/ipu-v3/Kconfig:1: symbol IMX_IPUV3_CORE depends on RESET_CONTROLLER drivers/reset/Kconfig:4: symbol RESET_CONTROLLER is selected by USB_CHIPIDEA drivers/usb/chipidea/Kconfig:1: symbol USB_CHIPIDEA depends on USB_EHCI_HCD drivers/usb/host/Kconfig:84: symbol USB_EHCI_HCD depends on USB Cc: Arnd Bergmann <arnd@arndb.de> Cc: <dri-devel@lists.freedesktop.org> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Mark Yao <mark.yao@rock-chips.com> Acked-by:
Philipp Zabel <p.zabel@pengutronix.de> Acked-by: robdclark@gmail.com Signed-off-by:
Stephen Boyd <stephen.boyd@linaro.org> Signed-off-by:
-
Arnd Bergmann authored
The introduction of reference counting on the state structures caused sanitize_watermarks() in i915 to break in the error handling case, as pointed out by gcc -Wmaybe-uninitialized drivers/gpu/drm/i915/intel_display.c: In function ‘intel_modeset_init’: include/drm/drm_atomic.h:224:2: error: ‘state’ may be used uninitialized in this function [-Werror=maybe-uninitialized] This changes the function back to only drop the reference count when it was successfully allocated first. Fixes: 0853695c ("drm: Add reference counting to drm_atomic_state") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Eric Engestrom <eric.engestrom@imgtec.com> Reviewed-by:
-
- 18 Oct, 2016 14 commits
-
-
Laurent Pinchart authored
The function is only used by the drm_helper_mode_fill_fb_struct() core function to fill the drm_framebuffer bpp and depth fields, used by drivers that haven't been converted to use pixel formats directly yet. It should not be used by new drivers, so inline it in its only caller. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-14-git-send-email-laurent.pinchart@ideasonboard.com
-
Laurent Pinchart authored
The driver doesn't need the color depth, only the number of bits per pixel. Use the right API. Signed-off-by:
-
Laurent Pinchart authored
The driver is the last users of the drm_fb_get_bpp_depth() function. It should ideally be converted to use struct drm_mode_fb_cmd2 instead of the legacy struct drm_mode_fb_cmd internally, but that will require broad changes across the code base. As a first step, replace drm_fb_get_bpp_depth() with drm_format_info() in order to stop exporting the function to drivers. The new DRM_ERROR() message comes from the vmw_create_dmabuf_proxy(), vmw_kms_new_framebuffer_surface() and vmw_kms_new_framebuffer_dmabuf() functions that currently print an error if the pixel format is unsupported. Signed-off-by:
Sinclair Yeh <syeh@vmware.com> Reviewed-by:
-
Laurent Pinchart authored
The driver needs the number of bytes per pixel, not the bpp and depth info meant for fbdev compatibility. Use the right API. Signed-off-by:
-
Laurent Pinchart authored
The driver needs the number of bytes per pixel, not the bpp and depth info meant for fbdev compatibility. Use the right API. Signed-off-by:
-
Laurent Pinchart authored
The driver uses drm_fb_get_bpp_depth() to check whether it can support the format requested by userspace when creating a framebuffer. This isn't the right API, as it doesn't differentiate between RGB formats other than on a depth and bpp basis. Fixing this requires non trivial changes to the drivers internals. As a first step, replace usage of the drm_fb_get_bpp_depth() function with an equivalent check based on drm_format_info(). This is part of a wider effort to remove usage of the drm_fb_get_bpp_depth() function in drivers. Signed-off-by:
-
Laurent Pinchart authored
The driver doesn't need the color depth, only the number of bits per pixel. Use the right API. Signed-off-by:
-
Laurent Pinchart authored
The driver needs the number of bytes per pixel, not the bpp and depth info meant for fbdev compatibility. Use the right API. In the tilcdc_crtc_mode_set() function compute the hardware register value directly from the pixel format instead of computing the number of bits per pixels first. Signed-off-by:
-
Laurent Pinchart authored
The driver needs the number of bytes per pixel, not the bpp and depth info meant for fbdev compatibility. Use the right API. Signed-off-by:
Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by:
-
Laurent Pinchart authored
The format helpers have historically treated unsupported formats as part of the default case, returning values that are likely wrong. We can't change this behaviour now without risking breaking drivers in difficult to detect ways, but we can WARN on unsupported formats to catch faulty callers. The only exception is the framebuffer_check() function that calls drm_format_info() to validate the format passed from userspace. This is a valid use case that shouldn't generate a warning. Signed-off-by:
-
Laurent Pinchart authored
Replace calls to the drm_format_*() helper functions with direct use of the drm_format_info structure. This improves efficiency by removing duplicate lookups. Signed-off-by:
-
Laurent Pinchart authored
Turn the drm_format_*() helpers into wrappers around the drm_format_info lookup function to centralize all format information in a single place. Signed-off-by:
-
Laurent Pinchart authored
Various pieces of information about DRM formats (number of planes, color depth, chroma subsampling, ...) are scattered across different helper functions in the DRM core. Callers of those functions often need to access more than a single parameter of the format, leading to inefficiencies due to multiple lookups. Centralize all format information in a data structure and create a function to look up information based on the format 4CC. Signed-off-by:
-
Arnd Bergmann authored
gcc warns about the timestamp in drm_wait_vblank being possibly used without an initialization: drivers/gpu/drm/drm_irq.c: In function 'drm_crtc_send_vblank_event': drivers/gpu/drm/drm_irq.c:992:24: error: 'now.tv_usec' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/gpu/drm/drm_irq.c:1069:17: note: 'now.tv_usec' was declared here drivers/gpu/drm/drm_irq.c:991:23: error: 'now.tv_sec' may be used uninitialized in this function [-Werror=maybe-uninitialized] This can happen if drm_vblank_count_and_time() returns 0 in its error path. To sanitize the error case, I'm changing that function to return a zero timestamp when it fails. Fixes: e6ae8687 ("drm: idiot-proof vblank") Reviewed-by:
David Herrmann <dh.herrmann@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by:
-
- 17 Oct, 2016 8 commits
-
-
Tomeu Vizoso authored
Adds files and directories to debugfs for controlling and reading frame CRCs, per CRTC: dri/0/crtc-0/crc dri/0/crtc-0/crc/control dri/0/crtc-0/crc/data Drivers can implement the set_crc_source callback() in drm_crtc_funcs to start and stop generating frame CRCs and can add entries to the output by calling drm_crtc_add_crc_entry. v2: - Lots of good fixes suggested by Thierry. - Added documentation. - Changed the debugfs layout. - Moved to allocate the entries circular queue once when frame generation gets enabled for the first time. v3: - Use the control file just to select the source, and start and stop capture when the data file is opened and closed, respectively. - Make variable the number of CRC values per entry, per source. - Allocate entries queue each time we start capturing as now there isn't a fixed number of CRC values per entry. - Store the frame counter in the data file as a 8-digit hex number. - For sources that cannot provide useful frame numbers, place XXXXXXXX in the frame field. v4: - Build only if CONFIG_DEBUG_FS is enabled. - Use memdup_user_nul. - Consolidate calculation of the size of an entry in a helper. - Add 0x prefix to hex numbers in the data file. - Remove unnecessary snprintf and strlen usage in read callback. v5: - Made the crcs array in drm_crtc_crc_entry fixed-size - Lots of other smaller improvements suggested by Emil Velikov v7: - Move definition of drm_debugfs_crtc_crc_add to drm_internal.h v8: - Call debugfs_remove_recursive when we fail to create the minor device v9: - Register the debugfs directory for a crtc from drm_crtc_register_all() v10: - Don't let debugfs failures interrupt CRTC registration (Emil Velikov) v11: - Remove extra brace that broke compilation. Sorry! Signed-off-by:Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Acked-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by:
-
Stefan Agner authored
The current fbdev emulation does not allow to push back changes in width, height or depth to KMS, hence reject any changes with an error. This makes sure that fbdev ioctl's fail properly and user space does not assume that changes succeeded. Signed-off-by:
-
Chris Wilson authored
Now that we have the name "block" free once more, we can use it to point to the start of a block within the edid. Signed-off-by:
-
Chris Wilson authored
The "block" variable points to the entire edid, not individual blocks despite it being named such. Signed-off-by:
-
Shashank Sharma authored
HDMI 2.0/CEA-861-F introduces two new aspect ratios: - 64:27 - 256:135 This patch: - Adds new DRM flags for to represent these new aspect ratios. - Adds new cases to handle these aspect ratios while converting from user->kernel mode or vise versa. V2: Rebase V3: Align macro for DRM_MODE_PICTURE_ASPECT_256_135 (Jim Bride) V4: Added r-b from Jose. Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com> Reviewed-by:
Jose Abreu <Jose.Abreu@synopsys.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
-
Shashank Sharma authored
HDMI 2.0/CEA-861-F introduces two new aspect ratios: - 64:27 - 256:135 This patch adds enumeration for the new aspect ratios in the existing aspect ratio list. V2: rebase V3: rebase V4: Added r-b from Jose, Ack by Tomi Signed-off-by:
-
Shashank Sharma authored
Current DRM layer functions don't parse aspect ratio information while converting a user mode->kernel mode or vice versa. This causes modeset to pick mode with wrong aspect ratio, eventually causing failures in HDMI compliance test cases, due to wrong VIC. This patch adds aspect ratio information in DRM's mode conversion and mode comparision functions, to make sure kernel picks mode with right aspect ratio (as per the VIC). V2: Addressed review comments from Sean: - Fix spellings/typo - No need to handle aspect ratio none - Add a break, for default case too V3: Rebase V4: Added r-b from Jose Signed-off-by:
Lin, Jia <lin.a.jia@intel.com> Signed-off-by:
Akashdeep Sharma <akashdeep.sharma@intel.com> Reviewed-by:
Jim Bride <jim.bride@linux.intel.com> Reviewed-by:
-
Shashank Sharma authored
This patch adds drm flag bits for aspect ratio information Currently drm flag bits don't have field for mode's picture aspect ratio. This field will help the driver to pick mode with right aspect ratio, and help in setting right VIC field in avi infoframes. V2: Addressed review comments from Sean - Changed PAR-> PIC_AR V3: Rebase V3: Added r-b by Jose Signed-off-by:
-
