- 04 Dec, 2017 1 commit
-
-
Lucas Stach authored
Dma-bufs should already be device coherent, as they are only pulled in the CPU domain via the begin/end cpu_access calls. As we cache the mapping set up by dma_map_sg a CPU sync at this point will not actually guarantee proper coherency on non-coherent architectures, so we can as well stop pretending. This is an important performance fix for architectures which need explicit cache synchronization and userspace doing lots of dma-buf imports. Improves Weston on Etnaviv performance 5x, where before this patch > 90% of Weston CPU time was spent synchronizing caches for buffers which are already device coherent. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20171130173428.8666-1-l.stach@pengutronix.de
-
- 01 Dec, 2017 4 commits
-
-
David Lechner authored
This adds a new driver for display panels based on the Ilitek ILI9225 controller. This was developed for a no-name panel with a red PCB that is commonly marketed for Arduino. See <https://github.com/Nkawu/TFT_22_ILI9225>. Signed-off-by:
David Lechner <david@lechnology.com> Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
-
David Lechner authored
This exports the mipi_dbi_buf_copy() and mipi_dbi_spi_cmd_max_speed() functions so that they can be shared with other drivers. Signed-off-by:
-
David Lechner authored
This adds a new binding for display panels that use an Ilitek ILI9225 controller. The "ilitek,ili9225-2.2in-176x220" device listed has no identification markings whatsoever and an hour of googling turned up nothing, hence the use of the size and resolution in the name instead of a model name. An example of this nameless device can be found at: https://github.com/Nkawu/TFT_22_ILI9225Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
David Lechner authored
This adds the vendor prefix ilitek for ILI Technology Corporation (ILITEK). This prefix is already used several places and I will be adding more. Signed-off-by:
-
- 30 Nov, 2017 7 commits
-
-
Noralf Trønnes authored
Add entry for conversion of drivers to new helpers. Signed-off-by:
-
Noralf Trønnes authored
Replace driver's code with the generic helpers that do the same thing. Remove todo entry. Signed-off-by:
Stefan Agner <stefan@agner.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20171106191812.38927-6-noralf@tronnes.org
-
Noralf Trønnes authored
Replace driver's code with the generic helpers that do the same thing. Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Brian Starkey <brian.starkey@arm.com> Signed-off-by:
Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171106191812.38927-4-noralf@tronnes.org
-
Noralf Trønnes authored
Add drm_mode_config_helper_suspend/resume() which takes care of atomic modeset suspend/resume for simple use cases. The suspend state is stored in struct drm_mode_config. Signed-off-by:
-
Noralf Trønnes authored
Fix docs to reflect code and drm_kms_helper_poll_disable() docs by saying that calling drm_kms_helper_poll_enable() is fine even if output polling is not enabled. Signed-off-by:
-
Chen-Yu Tsai authored
The sun4i DRM driver maintains a list of compatible strings it uses to check if a device node within the display component graph is a TCON. The TCON driver also has this list, used to bind the TCON driver to the device. These two lists are identical. Instead of maintaining two identical lists, export the list from the TCON driver for the DRM driver to use. Suggested-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171127084632.25511-1-wens@csie.org
-
Andrey Gusakov authored
Add copyright lines for Zodiac who paid for driver development. Signed-off-by:
Andrey Gusakov <andrey.gusakov@cogentembedded.com> Acked-by:
Chris Healy <cphealy@gmail.com> Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-8-git-send-email-andrey.gusakov@cogentembedded.com
-
- 29 Nov, 2017 2 commits
-
-
Mark Yao authored
For personal reasons, Mark Yao will leave rockchip, can not continue maintain drm/rockchip, Sandy Huang and Heiko Stübner will take over drm/rockchip. Cc: Sandy Huang <hjc@rock-chips.com> Cc: Heiko Stübner <heiko@sntech.de> Signed-off-by:
Mark Yao <mark.yao@rock-chips.com> Acked-by:
Heiko Stuebner <heiko@sntech.de> [seanpaul added Heiko] Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20171129142459.32351-1-seanpaul@chromium.org
-
Ville Syrjälä authored
We're currently calling ktime_to_timespec64() on stack garbage hence the debug output for vblank timestamps also contains garbage. Let's assing something to the ktime_t first before we go converting it to a timespec. While at it micro-optimize the ktime_to_timespec64() calls away when vblank debugging isn't enabled. Fixes: 67680d3c ("drm: vblank: use ktime_t instead of timeval") Cc: Arnd Bergmann <arnd@arndb.de> Cc: Keith Packard <keithp@keithp.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171113150210.11311-1-ville.syrjala@linux.intel.comAcked-by:
Arnd Bergmann <arnd@arndb.de>
-
- 27 Nov, 2017 1 commit
-
-
Arnd Bergmann authored
The normal DRM vblank interrupt events started using monotonic times in commit c61eef72 ("drm: add support for monotonic vblank timestamps"), which is useful for a number of reasons, including the possible y2038 overflow. The VIA_WAIT_IRQ ioctl uses the same drm_wait_vblank_reply as DRM_IOCTL_WAIT_VBLANK, but still uses wall-clock time. This converts it to using monotonic time as well, which is more consistent, and avoids problems with the y2038 overflow as well as synchronization issues when the real time skips. I could not find the matching user space that calls the VIA_WAIT_IRQ ioctl to verify that this is safe, but it very likely is. Please either test or review the user space side before applying this. Signed-off-by:
-
- 23 Nov, 2017 2 commits
-
-
Vasyl Gomonovych authored
NULL check before some freeing functions is not needed. drivers/dma-buf/dma-buf.c:1183:2-26: WARNING: NULL check before freeing debugfs_remove_recursive Generated by: scripts/coccinelle/free/ifnullfree.cocci Signed-off-by:
Vasyl Gomonovych <gomonovych@gmail.com> Signed-off-by:
Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/1511364161-6074-1-git-send-email-gomonovych@gmail.com
-
Chris Wilson authored
Simple va_args equivalent to the existing drm_printf() for use with the drm_printer. v2: Fixup kerneldoc to match final parameter names. v3: Turn it into a kerneldoc comment Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123084051.30203-1-chris@chris-wilson.co.uk
-
- 22 Nov, 2017 2 commits
-
-
Ville Syrjälä authored
Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from 3D to 2D mode in a timely fashion if the source simply stops sending the HDMI infoframe. The suggested workaround is to keep sending the infoframe even when strictly not necessary (ie. no VIC and no S3D). HDMI 1.4 does allow for this behaviour, stating that sending the infoframe is optional in this case. The infoframe was first specified in HDMI 1.4, so in theory sinks predating that may not appreciate us sending an uknown infoframe their way. To avoid regressions let's try to determine if the sink supports the infoframe or not. Unfortunately there's no direct way to do that, so instead we'll just check if we managed to parse any HDMI 1.4 4k or stereo modes from the EDID, and if so we assume the sink will accept the infoframe. Also if the EDID contains the HDMI 2.0 HDMI Forum VSDB we can assume the sink is prepared to receive the infoframe. v2: Fix getting has_hdmi_infoframe from display_info Always fail constructing the infoframe if the display possibly can't handle it Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:Shashank Sharma <shashank.sharma@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171113170427.4150-3-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
HDMI 2.0 Appendix F suggest that we should keep sending the infoframe when switching from 3D to 2D mode, even if the infoframe isn't strictly necessary (ie. not needed to transmit the VIC or stereo information). This is a workaround against some sinks that fail to realize that they should switch from 3D to 2D mode when the source stop transmitting the infoframe. v2: Handle unpack() as well Pull the length calculation into a helper Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Hans Verkuil <hans.verkuil@cisco.com> Cc: linux-media@vger.kernel.org Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> #v1 Signed-off-by:
-
- 21 Nov, 2017 3 commits
-
-
Chris Wilson authored
Ages ago Rob Clark noted, "Currently with fence-array, we have a potential deadlock situation. If we fence_add_callback() on an array-fence, the array-fence's lock is acquired first, and in it's ->enable_signaling() callback, it will install cbs on it's array-member fences, so the array-member's lock is acquired second. But in the signal path, the array-member's lock is acquired first, and the array-fence's lock acquired second." Rob proposed either extensive changes to dma-fence to unnest the fence-array signaling, or to defer the signaling onto a workqueue. This is a more refined version of the later, that should keep the latency of the fence signaling to a minimum by using an irq-work, which is executed asap. Reported-by:
Rob Clark <robdclark@gmail.com> Suggested-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Daniel Vetter authored
Bake in the conflict between the drm_print.h extraction and the addition of DRM_DEBUG_LEASES since we lost it a few too many times. Also fix a new use of drm_plane_helper_check_state in msm to follow Ville's conversion in commit a01cb8ba Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Nov 1 22:16:19 2017 +0200 drm: Move drm_plane_helper_check_state() into drm_atomic_helper.c Acked-by:
-
Arvind Yadav authored
platform_get_irq_byname() can fail here and we must check its return value. Signed-off-by:
Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/f4b4f1b2cfa5e302ef7ffad4e3efb0d3147709d3.1510914877.git.arvind.yadav.cs@gmail.com
-
- 20 Nov, 2017 10 commits
-
-
Dave Stevenson authored
NV12 (YUV420 2 plane) and NV16 (YUV422 2 plane) were supported, but NV21 and NV61 (same but with Cb and Cr swapped) weren't. Add them. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.org> Signed-off-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
-
Dave Stevenson authored
The hardware has enums for altering the Cr and Cb order, so use this instead of having a flag which swaps the order the pointers are presented to the hardware (that only worked for 3 plane formats anyway). Explicitly sets .pixel_order in each case, rather than relying on then default XYCBCR order being a value 0. Signed-off-by:
-
Dave Stevenson authored
Filling out the list of supported formats based on those the hardware can support. Signed-off-by:
-
Ville Syrjälä authored
drm_plane_helper_check_update() isn't a transitional helper, so let's rename it to drm_atomic_helper_check_plane_state() and move it into drm_atomic_helper.c. v2: Fix the WARNs about plane_state->crtc matching crtc_state->crtc Cc: Daniel Vetter <daniel@ffwll.ch> Suggested-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Ville Syrjälä authored
drm_plane_helper_check_state() is supposed to do things the atomic way, so it should not be inspecting crtc->enabled. Rather we should be looking at crtc_state->enable. We have a slight complication due to drm_plane_helper_check_update() reusing drm_plane_helper_check_state() for non-atomic drivers. Thus we'll have to pass the crtc_state in manally and construct a fake crtc_state in drm_plane_helper_check_update(). v2: Fix the WARNs about plane_state->crtc matching crtc_state->crtc Signed-off-by:
-
Ville Syrjälä authored
Try to fix the code to actually clip the plane to the crtc bounds instead of the user provided crtc coordinates (which would be a no-op since those are exactly the coordinates before clipping). Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by:
Sinclair Yeh <syeh@vmware.com>
-
Ville Syrjälä authored
Atomic drivers have no reason to use drm_plane_helper_check_update() instead of drm_plane_helper_check_state(). So let's switch over. Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by:
-
Ville Syrjälä authored
Throw away the bugs crtc coords vs. fb size check. Crtc coords don't define the viewport inside the fb, that's a job for the src coords, which have been checked by the core already. Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by:
-
Greg Kroah-Hartman authored
There is no need to #define the license of the driver, just put it in the MODULE_LICENSE() line directly as a text string. This allows tools that check that the module license matches the source code license to work properly, as there is no need to unwind the unneeded dereference, especially when the string is defined in a .h file far away from the .c file it is used in. Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: David Airlie <airlied@linux.ie> Reported-by:
Philippe Ombredanne <pombredanne@nexb.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
-
Lucas Stach authored
The i2c adapter on DP AUX is purely a software construct. Linking it to the device node of the parent device is wrong, as it leads to 2 devices sharing the same device node, which is bad practice, as well as the i2c trying to populate children of the i2c adapter by looking at the child device nodes of the parent device. Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
- 17 Nov, 2017 2 commits
-
-
Lukasz Majewski authored
The Mitsubishi AA070MC01 is a 7.0" WVGA (800x480) TFT panel working in 8 bit ISP mode (pin 19 "mode" HIGH for 20 pin TFT connector). Signed-off-by:
Lukasz Majewski <lukma@denx.de> Acked-by:
-
Lukasz Majewski authored
The Tianma TM070RVHG71 is a 7" WVGA (800x480) TFT LCD panel connected via LVDS and can be supported by the simple-panel binding. Signed-off-by:
-
- 16 Nov, 2017 4 commits
-
-
Maciej Purski authored
If the sink device is in HDMI mode, enable infoframe interrupt in scdt irq handle function else call start_video function immediately, because in DVI mode, there is no infoframe interrupt provided. Rename start_hdmi function to start_video and get rid of the old start_video function. In start_video, if the sink is DVI and mode is MHL1 or MHl2, write appropriate values to registers else the path should remain the same as in HDMI mode. Signed-off-by:
Maciej Purski <m.purski@samsung.com> Signed-off-by:
-
Marek Szyprowski authored
The maximum pixel clock depends on the version of the connected MHL adapter. Add mode_valid callback to filter out modes with too high pixel clock to avoid failure in mode_fixup later. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
-
Sandy Huang authored
RK3126 vop register layout is similar with rk3036, so some feature can reuse with rk3036. RK3126 support two overlay plane and one hwc plane, max output resolution is 1080p. it support IOMMU, and its IOMMU same as rk3288's Signed-off-by:
Sandy Huang <hjc@rock-chips.com> Reviewed-by:
-
Sandy Huang authored
Signed-off-by:
-
- 15 Nov, 2017 2 commits
-
-
Liviu Dudau authored
drm_gem_cma_prime_import_sg_table() will fail if the number of entries in the sg_table > 1. However, you can have a device that uses an IOMMU engine and can map a discontiguous buffer with multiple entries that have consecutive sg_dma_addresses, effectively making it contiguous. Allow for that scenario by testing the entries in the sg_table for contiguous coverage. Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Daniel Vetter authored
It's useful for syncing async connector work like link retraining. v2: Make it work (Manasi&Ville) Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
