- 11 May, 2018 5 commits
-
-
Ville Syrjälä authored
AVI infoframe can only carry none, 4:3, or 16:9 picture aspect ratios. Return an error if the user asked for something different. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: "Lin, Jia" <lin.a.jia@intel.com> Cc: Akashdeep Sharma <akashdeep.sharma@intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Hans Verkuil <hans.verkuil@cisco.com> Cc: linux-media@vger.kernel.org Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Jose Abreu <joabreu@synopsys.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-6-git-send-email-ankit.k.nautiyal@intel.com
-
Ville Syrjälä authored
If the user mode would specify an aspect ratio other than 4:3 or 16:9 we now silently ignore it. Maybe a better apporoach is to return an error? Let's try that. Also we must be careful that we don't try to send illegal picture aspect in the infoframe as it's only capable of signalling none, 4:3, and 16:9. Currently we're sending these bogus infoframes whenever the cea mode specifies some other aspect ratio. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: 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 <shashank.sharma@intel.com> Signed-off-by:
-
Ville Syrjälä authored
commit 6dffd431 ("drm: Add aspect ratio parsing in DRM layer") cause us to not send out any VICs in the AVI infoframes. That commit was since reverted, but if and when we add aspect ratio handing back we need to be more careful. Let's handle this by considering the aspect ratio as a requirement for cea mode matching only if the passed in mode actually has a non-zero aspect ratio field. This will keep userspace that doesn't provide an aspect ratio working as before by matching it to the first otherwise equal cea mode. And once userspace starts to provide the aspect ratio it will be considerd a hard requirement for the match. Also change the hdmi mode matching to use drm_mode_match() for consistency, but we don't match on aspect ratio there since the spec doesn't list a specific aspect ratio for those modes. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: "Lin, Jia" <lin.a.jia@intel.com> Cc: Akashdeep Sharma <akashdeep.sharma@intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
Use drm_mode_equal_no_clocks_no_stereo() in drm_match_hdmi_mode_clock_tolerance() for consistency as we also use it in drm_match_hdmi_mode() and the cea mode matching functions. This doesn't actually change anything since the input mode comes from detailed timings and we match it against edid_4k_modes[] which. So none of those modes can have stereo flags set. Signed-off-by:
-
Ville Syrjälä authored
Make mode matching less confusing by allowing the caller to specify which parts of the modes should match via some flags. Signed-off-by:
-
- 10 May, 2018 1 commit
-
-
Andy Shevchenko authored
The new helper returns index of the matching string in an array. We are going to use it here. Acked-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180503184119.22355-1-andriy.shevchenko@linux.intel.com
-
- 08 May, 2018 5 commits
-
-
Matt Atwood authored
DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8 bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended receiver capabilities. For panels that use this new feature wait interval would be increased by 512 ms, when spec is max 16 ms. This behavior is described in table 2-158 of DP 1.4 spec address 0000eh. With the introduction of DP 1.4 spec main link clock recovery was standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value. To avoid breaking panels that are not spec compiant we now warn on invalid values. V2: commit title/message, masking all 7 bits, warn on out of spec values. V3: commit message, make link train clock recovery follow DP 1.4 spec. V4: style changes V5: typo V6: print statement revisions, DP_REV to DPCD_REV, comment correction V7: typo V8: Style V9: Strip out DPCD_REV_XX into seperate patch v10: DPCD_REV_XX to DP_DPCD_REV_XX Signed-off-by:
Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Matt Atwood authored
As more differentation occurs between DP spec. Its useful to have these as macros in a drm_dp_helper. v2: DPCD_REV_XX to DP_DPCD_REV_XX Signed-off-by:
-
Dan Carpenter authored
If the loop times out then we want to exit with "to" set to zero, but in the current code it's set to -1. Fixes: c575b7ee ("drm/xen-front: Add support for Xen PV display frontend") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Signed-off-by:
-
Dan Carpenter authored
The xen_drm_front_shbuf_alloc() function was returning a mix of error pointers and NULL and the the caller wasn't checking correctly. I've changed it to always return error pointer consistently. Fixes: c575b7ee ("drm/xen-front: Add support for Xen PV display frontend") Signed-off-by:
-
Dan Carpenter authored
drm_dev_alloc() returns error pointers, it never returns NULL. Fixes: c575b7ee ("drm/xen-front: Add support for Xen PV display frontend") Signed-off-by:
-
- 07 May, 2018 1 commit
-
-
Ezequiel Garcia authored
The sync_debug.h header is internal, and only used by sw_sync.c. Therefore, SW_SYNC is always defined and there is no need for the stubs. Remove them and make the code simpler. Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180504180037.10661-1-ezequiel@collabora.com
-
- 04 May, 2018 7 commits
-
-
Maarten Lankhorst authored
Signed-off-by:
-
Maarten Lankhorst authored
We want to add more DRM selftests, and there's not much point in having a Kconfig option for every single one of them, so make a generic one. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
-
Maarten Lankhorst authored
With the previous patch drm_atomic_helper_check_plane_state correctly calculates clipping and the xf86-video-intel ddx is fixed to fall back to GPU correctly when SetPlane fails, we can remove the hack where we try to pan/zoom when out of min/max scaling range. This was already poor behavior where the screen didn't show what was requested, and now instead we reject it outright. This simplifies check_sprite_plane a lot. Changes since v1: - Set crtc_h to the height correctly. - Reject < 3x3 rectangles instead of making them invisible for <gen9. For gen9+ skl_update_scaler_plane will reject them. Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Maarten Lankhorst authored
Instead of relying on a scale which may increase rounding errors, clip src by doing: src * (dst - clip) / dst and rounding the result away from 1, so the new coordinates get closer to 1. We won't need to fix up with a magic macro afterwards, because our scaling factor will never go to the other side of 1. Changes since v1: - Adjust dst immediately, else drm_rect_width/height on dst gives bogus results. Change since v2: - Get rid of macros and use 64-bits math. Signed-off-by:
-
Maarten Lankhorst authored
When calculating limits we want to be as pessimistic as possible, so we have to explicitly say whether we want to round up or down to accurately calculate whether we are below min_scale or above max_scale. Signed-off-by:
-
Jia-Ju Bai authored
adv7511_probe() is never called in atomic context. This function is only set as ".probe" in struct i2c_driver. Despite never getting called from atomic context, adv7511_probe() calls mdelay() to busily wait. This is not necessary and can be replaced with usleep_range() to avoid busy waiting. This is found by a static analysis tool named DCNS written by myself. And I also manually check it. Signed-off-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Archit Taneja <architt@codeaurora.org> Link: https://patchwork.freedesktop.org/patch/msgid/1523435622-4329-1-git-send-email-baijiaju1990@gmail.com
-
Peter Rosin authored
Could perhaps prevent some confusion. Signed-off-by:
Peter Rosin <peda@axentia.se> Reviewed-by:
-
- 03 May, 2018 17 commits
-
-
Eric Anholt authored
This driver will be used to support Mesa on the Broadcom 7268 and 7278 platforms. V3D 3.3 introduces an MMU, which means we no longer need CMA or vc4's complicated CL/shader validation scheme. This massively changes the GEM behavior, so I've forked off to a new driver. v2: Mark SUBMIT_CL as needing DRM_AUTH. coccinelle fixes from kbuild test robot. Drop personal git link from MAINTAINERS. Don't double-map dma-buf imported BOs. Add kerneldoc about needing MMU eviction. Drop prime vmap/unmap stubs. Delay mmap offset setup to mmap time. Use drm_dev_init instead of _alloc. Use ktime_get() for wait_bo timeouts. Drop drm_can_sleep() usage, since we don't modeset. Switch page tables back to WC (debug change to coherent had slipped in). Switch drm_gem_object_unreference_unlocked() to drm_gem_object_put_unlocked(). Simplify overflow mem handling by not sharing overflow mem between jobs. v3: no changes v4: align submit_cl to 64 bits (review by airlied), check zero flags in other ioctls. Signed-off-by:Eric Anholt <eric@anholt.net> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v4) Acked-by: Dave Airlie <airlied@linux.ie> (v3, requested submit_cl change) Link: https://patchwork.freedesktop.org/patch/msgid/20180430181058.30181-3-eric@anholt.net
-
Eric Anholt authored
These OpenGL ES GPUs are present in the 7268 and 7278 set top box chips. v2: no changes v3: move to gpu/, fix typo Signed-off-by:
Rob Herring <robh@kernel.org>
-
Eric Anholt authored
I had originally asked Stefan Schake to drop the pad field from the syncobj changes that just landed, because I couldn't come up with a reason to align to 64 bits. Talking with Dave Airlie about the new v3d driver's submit ioctl, we came up with a reason: sizeof() on 64-bit platforms may align to 64 bits, in which case the userspace will be submitting the aligned size and the final 32 bits won't be zero-padded by the kernel. If userspace doesn't zero-fill, then a future ABI change adding a 32-bit field at the end could potentially cause the kernel to read undefined data from old userspace (our userspace happens to use structure initialization that zero-fills, but as a general rule we try not to rely on that in the kernel). Signed-off-by:
Stefan Schake <stschake@gmail.com>
-
Linus Walleij authored
Commit a30933c27602 ("drm/pl111: Support the Versatile Express") Added a second module using the builtin_platform_driver() call, which works fine as long as you do not try to build the PL111 driver as a module, because a module can only have one initcall and cause the following build bug: (...) multiple definition of `init_module' (...) Reported-by:Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180503140431.5798-1-linus.walleij@linaro.org
-
Daniel Vetter authored
With the ioctl and driver prep done, we can remove everything else. Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Airlie <airlied@linux.ie> Link: https://patchwork.freedesktop.org/patch/msgid/20180420065159.4531-4-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
It's going away. v2: Try harder to find them all. Reviewed-by:
-
Satendra Singh Thakur authored
In the func drm_atomic_set_crtc_for_plane, with the current code, if crtc of the plane_state and crtc passed as argument to the func are same, entire func will executed in vein. It will get state of crtc and clear and set the bits in plane_mask. All these steps are not required for same old crtc. Ideally, we should do nothing in this case, this patch handles the same, and causes the program to return without doing anything in such scenario. Signed-off-by:
Satendra Singh Thakur <satendra.t@samsung.com> Cc: Madhur Verma <madhur.verma@samsung.com> Cc: Hemanshu Srivastava <hemanshu.s@samsung.com> Signed-off-by:
-
Daniel Vetter authored
I shouldn't have pushed this, CI was right - I failed to remove the BUG_ON(!ops->wait); Reported-by:
-
Daniel Vetter authored
The trivial enable_signaling implementation matches the default code. v2: Fix up commit message to match patch better (Eric). Cc: Eric Anholt <eric@anholt.net> Reviewed-by:
-
Daniel Vetter authored
dma_fence_default_wait is the default now, same for the trivial enable_signaling implementation. Reviewed-by:
-
Daniel Vetter authored
Almost everyone uses dma_fence_default_wait. Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Daniel Vetter authored
When this was introduced in commit a519435a Author: Christian König <christian.koenig@amd.com> Date: Tue Oct 20 16:34:16 2015 +0200 dma-buf/fence: add fence_wait_any_timeout function v2 there was a restriction added that this only works if the dma-fence uses the dma_fence_default_wait hook. Which works for amdgpu, which is the only caller. Well, until you share some buffers with e.g. i915, then you get an -EINVAL. But there's really no reason for this, because all drivers must support callbacks. The special ->wait hook is only as an optimization; if the driver needs to create a worker thread for an active callback, then it can avoid to do that if it knows that there's a process context available already. So ->wait is just an optimization, just using the logic in dma_fence_default_wait() should work for all drivers. Let's remove this restriction. Signed-off-by:
-
Daniel Vetter authored
Many drivers have a trivial implementation for ->enable_signaling. Let's make it optional by assuming that signalling is already available when the callback isn't present. Signed-off-by:
-
Daniel Vetter authored
Noticed while I was typing docs. Entirely unused. v2: Remove reference in @timeline_value_str too. While at it clarify why timeline_value_str has a fence parameter - we don't have an explicit timeline structure unfortunately. Cc: Eric Anholt <eric@anholt.net> Reviewed-by: Christian König <christian.koenig@amd.com> (v1) Reviewed-by:
-
Daniel Vetter authored
Control nodes are no more! Reviewed-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
-
Daniel Vetter authored
Control nodes are no more! Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
We've disabled control nodes in commit 8a357d10 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Oct 28 10:10:50 2016 +0200 drm: Nerf DRM_CONTROL nodes and there was only a minor uapi break that we've paper over with commit 6449b088 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Dec 9 14:56:56 2016 +0100 drm: Add fake controlD* symlinks for backwards compat Since then Keith has also added real control nodes with a proper&useable uapi in the form of drm leases. It's time to remove the control node leftovers. Cc: Keith Packard <keithp@keithp.com> Reviewed-by:
-
- 02 May, 2018 4 commits
-
-
Ville Syrjälä authored
An overeager sed has corrupted the drm_rect_rotation_inv() documentation. Fix it up. Looks like it wasn't entirely correct before the sed fail either. We were missing _rect_ from the function names, which also explains why the sed hit these by accident. Signed-off-by:
-
Linus Walleij authored
The Versatile Express has 8 MB of dedicated video RAM (VRAM) on the motherboard, which is what we should be using for the PL111 if available. On this platform, the memory backplane is constructed so that only this memory will work properly with the CLCD on the motherboard, using any other memory area just gives random snow on the display. The CA9 Versatile Express also has a PL111 instance on its core tile that can address all memory, and this does not have the restriction. The memory is assigned to the device using the memory-region device tree property and a "shared-dma-pool" reserved memory pool like this: reserved-memory { #address-cells = <1>; #size-cells = <1>; ranges; vram: vram@48000000 { compatible = "shared-dma-pool"; reg = <0x48000000 0x00800000>; no-map; }; }; clcd@1f000 { compatible = "arm,pl111", "arm,primecell"; (...) memory-region = <&vram>; }·; Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Mali DP Maintainers <malidp@foss.arm.com> Reviewed-by:Robin Murphy <robin.murphy@arm.com> Signed-off-by:
-
Linus Walleij authored
The Versatile Express uses a special configuration controller deeply embedded in the system motherboard FPGA to multiplex the two to three (!) display controller instances out to the single SiI9022 bridge. Set up an extra file with the logic to probe to the FPGA mux register on the system controller bus, then parse the device tree to see if there is a CLCD or HDLCD instance on the core tile (also known as the daughterboard) by looking in the root of the device tree for compatible nodes. - If there is a HDLCD on the core tile, and there is a driver for it, we exit probe and deactivate the motherboard CLCD. We do not touch the DVI mux in this case, to make sure we don't break HDLCD. - If there is a CLCD on both the motherboard and the core tile (only the CA9 has this) the core tile CLCD takes precedence and get muxed to the DVI connector. - Only if there is no working graphics on the core tile, the motherboard CLCD is probed and muxed to the DVI connector. Core tile graphics should always take precedence as it can address all memory and is also faster, however the motherboard CLCD is good to have around for diagnostics and testing. It is possible to test the motherboard CLCD by setting the status = "disabled" property on the core tile CLCD or HDLCD. Scale down the Versatile Express to 16BPP so we can support a 1024x768 display despite the bus bandwidth restrictions on this platform. (The motherboard CLCD supports slightly lower resolution.) Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Pawel Moll <pawel.moll@arm.com> Acked-by:
-
Colin Ian King authored
Trivial fix to spelling mistake in DRM_ERROR error message Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
