- 30 May, 2018 1 commit
-
-
Eric Anholt authored
Signed-off-by:
Eric Anholt <eric@anholt.net> Fixes: 65101d8c ("drm/vc4: Expose performance counters to userspace") Link: https://patchwork.freedesktop.org/patch/msgid/20180409205813.7077-1-eric@anholt.netReviewed-by:
Boris Brezillon <boris.brezillon@bootlin.com>
-
- 15 May, 2018 5 commits
-
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for v4.18: UAPI Changes: - Fix render node number regression from control node removal. Driver Changes: - Small header fix for virgl, used by qemu. - Use vm_fault_t in qxl. Signed-off-by:
Dave Airlie <airlied@redhat.com> # gpg: Signature made Tue 15 May 2018 06:16:03 PM AEST # gpg: using RSA key FE558C72A67013C3 # gpg: Can't check signature: public key not found Link: https://patchwork.freedesktop.org/patch/msgid/e63306b9-67a0-74ab-8883-08b3d9db72d2@mblankhorst.nl
-
git://people.freedesktop.org/~gabbayo/linuxDave Airlie authored
This is amdkfd pull for 4.18. The major new features are: - Add support for GFXv9 dGPUs (VEGA) - Add support for userptr memory mapping In addition, there are a couple of small fixes and improvements, such as: - Fix lock handling - Fix rollback packet in kernel kfd_queue - Optimize kfd signal handling - Fix CP hang in APU Signed-off-by:
-
Dave Airlie authored
Merge tag 'exynos-drm-next-for-v4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next - Add S5PV210 FIMD variant support. - Add IPP v2 framework. . it is a rewritten version of the Exynos mem-to-mem image processing framework which supprts color space conversion, image up/down-scaling and rotation. This new version replaces existing userspace API with new easy-to-use and simple ones so we have already applied the use of these API to real user, Tizen Platform[1], and also makes existing Scaler, FIMC, GScaler and Rotator drivers to use IPP v2 core API. And below are patch lists we have applied to a real user, https://git.tizen.org/cgit/platform/adaptation/samsung_exynos/libtdm-exynos/log/?h=tizen&qt=grep&q=ipp https://git.tizen.org/cgit/platform/adaptation/samsung_exynos/libtdm-exynos/commit/?h=tizen&id=b59be207365d10efd489e6f71c8a045b558c44fe https://git.tizen.org/cgit/platform/kernel/linux-exynos/log/?h=tizen&qt=grep&q=ipp TDM(Tizen Display Manager) is a Display HAL for Tizen platform. Ps. Only real user using IPP API is Tizen. [1] https://www.tizen.org/ - Two cleanups . One is to just remove mode_set callback from MIPI-DSI driver because drm_display_mode data is already available from crtc atomic state. . And other is to just use new return type, vm_fault_t for page fault handler. Signed-off-by:
-
Dave Airlie authored
Merge branch 'mediatek-drm-next-4.18' of https://github.com/ckhu-mediatek/linux.git-tags into drm-next Signed-off-by:
-
git://linuxtv.org/pinchartl/mediaDave Airlie authored
Signed-off-by:
-
- 14 May, 2018 4 commits
-
-
Souptick Joarder authored
Use new return type vm_fault_t for fault handler. For now, this is just documenting that the function returns a VM_FAULT value rather than an errno. Once all instances are converted, vm_fault_t will become a distinct type. Reference id -> 1c8f4220 ("mm: change return type to vm_fault_t") Signed-off-by:
Souptick Joarder <jrdr.linux@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20180417133844.GA30256@jordon-HP-15-Notebook-PCSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Dave Airlie authored
Although the kernel doesn't use this, qemu imports these headers and it's best to keep them consistent. This define is also something userspace may want to use. Signed-off-by:
-
Eric Anholt authored
drm_minor_alloc() does multiplication on this enum, so the removal ended up moving render nodes down from 128 base to 64. This caused Mesa's surfaceless backend to be unable to open the render nodes, since it was still looking up at 128. v2: Add a comment warning the next person. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180509001425.12574-1-eric@anholt.net
-
https://github.com/jsarha/linuxDave Airlie authored
tilcdc v4.18 pull request Signed-off-by:
-
- 13 May, 2018 1 commit
-
-
Andrzej Hajda authored
The callback was used only to copy provided mode to context for later usage. Since the mode is always available from crtc atomic state this code can be removed. Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
Inki Dae <inki.dae@samsung.com>
-
- 11 May, 2018 11 commits
-
-
Maarten Lankhorst authored
drm-misc-next is still based on v4.16-rc7, and was getting a bit stale. Signed-off-by:Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
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. This patch was once reviewed and merged, and later reverted due to lack of DRM client protection, while adding aspect ratio bits in user modes. This is a re-spin of the series, with DRM client cap protection. The previous series can be found here: https://pw-emeril.freedesktop.org/series/10850/Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> (V2) Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com> (V2) Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> V3: rebase V4: rebase V5: corrected the macro name for an aspect ratio, in a switch case. V6: rebase V7: rebase V8: rebase V9: rebase V10: rebase V11: rebase V12: rebase V13: rebase V14: rebase Acked-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). Background: This patch was once reviewed and merged, and later reverted due to lack of DRM cap protection. This is a re-spin of this patch, this time with DRM cap protection, to avoid aspect ratio information, when the client doesn't request for it. Review link: https://pw-emeril.freedesktop.org/patch/104068/ Background discussion: https://patchwork.kernel.org/patch/9379057/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> (V2) Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com> (V4) Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> V3: modified the aspect-ratio check in drm_mode_equal as per new flags provided by Ville. https://patchwork.freedesktop.org/patch/188043/ V4: rebase V5: rebase V6: As recommended by Ville, avoided matching of aspect-ratio in drm_fb_helper, while trying to find a common mode among connectors for the target clone mode. V7: rebase V8: rebase V9: rebase V10: rebase V11: rebase V12: rebase V13: rebase V14: rebase Acked-by:
-
Ankit Nautiyal authored
We parse the EDID and add all the modes in the connector's modelist. This adds CEA modes with aspect ratio information too, regardless of whether user space requested this information or not. This patch: -prunes the modes with aspect-ratio information, from the drm_mode_get_connector modelist supplied to the user, if the user-space has not set the aspect ratio DRM client cap. However if such a mode is unique in the list, it is kept in the list, with aspect-ratio flags reset. -prepares a list of exposed modes, which is used to find unique modes if aspect-ratio is not allowed. -adds a new list_head 'exposed_head' in drm_mode_display, to traverse the list of exposed modes. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jose Abreu <jose.abreu@synopsys.com> Signed-off-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> V3: As suggested by Ville, modified the mechanism of pruning of modes with aspect-ratio, if the aspect-ratio is not supported. Instead of straight away pruning such a mode, the mode is retained with aspect ratio bits set to zero, provided it is unique. V4: rebase V5: Addressed review comments from Ville: -used a pointer to store last valid mode. -avoided, modifying of picture_aspect_ratio in kernel mode, instead only flags bits of user mode are reset (if aspect-ratio is not supported). V6: As suggested by Ville, corrected the mode pruning logic and elaborated the mode pruning logic and the assumptions taken. V7: rebase V8: rebase V9: rebase V10: rebase V11: Fixed the issue caused in kms_3d test, and enhanced the pruning logic to correctly identify and prune modes with aspect-ratio, if aspect-ratio cap is not set. V12: As suggested by Ville, added another list_head in drm_mode_display to traverse the list of exposed modes and avoided duplication of modes. V13: Minor modifications, as suggested by Ville. v14: As suggested by Daniel Vetter and Ville Syrjala, corrected the pruning logic to avoid any dependency in the order of mode with aspect-ratio. Reviewed-by:
-
Ankit Nautiyal authored
If the user-space does not support aspect-ratio, and requests for a modeset with mode having aspect ratio bits set, then the given user-mode must be rejected. Secondly, while preparing a user-mode from kernel mode, the aspect-ratio info must not be given, if aspect-ratio is not supported by the user. This patch: 1. rejects the modes with aspect-ratio info, during modeset, if the user does not support aspect ratio. 2. does not load the aspect-ratio info in user-mode structure, if aspect ratio is not supported. 3. adds helper functions for determining if aspect-ratio is expected in user-mode and for allowing/disallowing the aspect-ratio, if its not expected. Signed-off-by:
-
Ankit Nautiyal authored
To enable aspect-ratio support in DRM, blindly exposing the aspect ratio information along with mode, can break things in existing non-atomic user-spaces which have no intention or support to use this aspect ratio information. To avoid this, a new drm client cap is required to enable a non-atomic user-space to advertise if it supports modes with aspect-ratio. Based on this cap value, the kernel will take a call on exposing the aspect ratio info in modes or not. This patch adds the client cap for aspect-ratio. Since no atomic-userspaces blow up on receiving aspect-ratio information, the client cap for aspect-ratio is always enabled for atomic clients. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by:
-
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:
-
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:
-
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
-
- 09 May, 2018 11 commits
-
-
Andrzej Pietrasiewicz authored
Exynos Scaler is a hardware module, which processes graphic data fetched from memory and transfers the resultant dato another memory buffer. Graphics data can be up/down-scaled, rotated, flipped and converted color space. Scaler hardware modules are a part of Exynos5420 and newer Exynos SoCs. Signed-off-by:
Andrzej Pietrasiewicz <andrzej.p@samsung.com> Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Marek Szyprowski authored
This patch adapts Exynos DRM FIMC driver to new IPP v2 core API. The side effect of this conversion is a switch to driver component API to register properly in the Exynos DRM core. Signed-off-by:
-
Marek Szyprowski authored
This patch adapts Exynos DRM GScaler driver to new IPP v2 core API. The side effect of this conversion is a switch to driver component API to register properly in the Exynos DRM core. During the conversion driver has been adapted to support more specific compatible strings to distinguish between Exynos5250 and Exynos5420 (different hardware limits). Support for Exynos5433 variant has been added too (different limits table, removed dependency on ARCH_EXYNOS5). Signed-off-by:
Hoegeun Kwon <hoegeun.kwon@samsung.com> Signed-off-by:
-
Marek Szyprowski authored
This patch adapts Exynos DRM rotator driver to new IPP v2 core API. The side effect of this conversion is a switch to driver component API to register properly in the Exynos DRM core. Signed-off-by:
-
Marek Szyprowski authored
This patch adds Exynos IPP v2 subsystem and userspace API. New userspace API is focused ONLY on memory-to-memory image processing. The two remainging operation modes of obsolete IPP v1 API (framebuffer writeback and local-path output with image processing) can be implemented using standard DRM features: writeback connectors and additional DRM planes with scaling features. V2 IPP userspace API is based on stateless approach, which much better fits to memory-to-memory image processing model. It also provides support for all image formats, which are both already defined in DRM API and supported by the existing IPP hardware modules. The API consists of the following ioctls: - DRM_IOCTL_EXYNOS_IPP_GET_RESOURCES: to enumerate all available image processing modules, - DRM_IOCTL_EXYNOS_IPP_GET_CAPS: to query capabilities and supported image formats of given IPP module, - DRM_IOCTL_EXYNOS_IPP_GET_LIMITS: to query hardware limitiations for selected image format of given IPP module, - DRM_IOCTL_EXYNOS_IPP_COMMIT: to perform operation described by the provided structures (source and destination buffers, operation rectangle, transformation, etc). The proposed userspace API is extensible. In the future more advanced image processing operations can be defined to support for example blending. Userspace API is fully functional also on DRM render nodes, so it is not limited to the root/privileged client. Internal driver API also has been completely rewritten. New IPP core performs all possible input validation, checks and object life-time control. The drivers can focus only on writing configuration to hardware registers. Stateless nature of DRM_IOCTL_EXYNOS_IPP_COMMIT ioctl simplifies the driver API. Minimal driver needs to provide a single callback for starting processing and an array with supported image formats. Signed-off-by:
-
David Lechner authored
This fixes setting the clock divider on the TI OMAP-L138 LCDK board. The clock drivers for OMAP-L138 are being covernted to the common clock framework. When this happens, clk_set_rate() will no longer return an error. However, on this SoC, the clock rate cannot actually be changed because the clock has to maintain a fixed ratio to the ARM clock. So after attempting to set the clock rate, we need to check to see if the new rate is actually close enough. If not, then follow the previous error path to adjust the divider in LCDC IP block to compensate for not being able to change the parent clock rate. Tested working on a TI OMAP-L138 LCDK board. Signed-off-by:
David Lechner <david@lechnology.com> Signed-off-by:
Jyri Sarha <jsarha@ti.com>
-
Paweł Chmiel authored
This patch brings back possibility to use drivers depending on DRM_EXYNOS, on Samsung S5PV210/S5PC110 series based systems. Fixes: dbbc925b ("drm/exynos: depend on ARCH_EXYNOS for DRM_EXYNOS") Signed-off-by:
Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> Signed-off-by:
-
Tomasz Figa authored
This patch adds support for FIMD variant found on S5PV210 SoC. Except CLKSEL bit availability, it is identical to Exynos4210. Tested-by:
Tomasz Figa <tomasz.figa@gmail.com> Signed-off-by:
-
Souptick Joarder authored
Use new return type vm_fault_t for fault handler in struct vm_operations_struct. Signed-off-by:
Matthew Wilcox <mawilcox@microsoft.com> Signed-off-by:
-
Inki Dae authored
Merge tag 'exynos-drm-fixes-for-v4.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into exynos-drm-next Fixup pagefault issue of mixer driver - it makes sure to check shadow register for interlace scan. - it corrects chroma_addr[1], height and vertical position values. And trivial cleanup - it just removes duplicated drm_bridge_attach.
-
Peter Rosin authored
drm_bridge_attach takes care of these assignments, so there is no need to open-code them a second time. Signed-off-by:
Peter Rosin <peda@axentia.se> Signed-off-by:
-
- 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:
-
