- 03 Jul, 2019 7 commits
-
-
Rob Herring authored
This reverts commit 220df83a. Turns out drm_gem_dumb_map_offset really only worked for the dumb buffer case, so revert the name change. Signed-off-by:
Rob Herring <robh@kernel.org>
-
Rob Herring authored
This reverts commit 583bbf46. Turns out we need mmap to work on imported BOs even if the current code is buggy. Signed-off-by:
-
Thomas Zimmermann authored
PRIME functionality is now provided by GEM object functions. The driver callback functions are obsolete. So this patch renames them and turns them into static internal functions of the VRAM helper library. The implementation of gem_prime_mmap is now unused and the patch removes it. v3: * kept each renamed function at its original location within file * kept documentation Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
Gerd Hoffmann <kraxel@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190702115012.4418-6-tzimmermann@suse.de
-
Thomas Zimmermann authored
The vbox driver uses VRAM helpers for memory management. These helpers provide a basic implementation of PRIME functions, so the vbox driver's empty implmentation can be removed. As a side effect of this change, vbox can now use generic framebuffer emulation. Signed-off-by:
-
Thomas Zimmermann authored
The GEM object's free function is now called through struct drm_gem_object_funcs.free. The function struct drm_driver.gem_prime_mmap is now required for mmap'ing GEM objects to userspace. v2: * set drm_driver.gem_prime_mmap to drm_gem_prime_mmap() Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Thomas Zimmermann authored
VRAM PRIME helpers are now called through GEM object functions. The driver callback functions are obsolete. Signed-off-by:
-
Thomas Zimmermann authored
PRIME functionality is now provided via the callback functions in struct drm_gem_object_funcs. The driver-structure functions are obsolete. As a side effect of this patch, VRAM-based drivers get basic PRIME support automatically without having to set any flags or additional fields. v2: - use existing PRIME functions for object's table v3: - move object table to EOF so it can refer to internal interfaces Signed-off-by:
-
- 01 Jul, 2019 7 commits
-
-
Paul Cercueil authored
Add support for the LCD panels with a serial 8-bit bus, where the color components of each 24-bit pixel are sent sequentially. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190627182114.27299-3-paul@crapouillou.net # *** extracted tags *** Reviewed-by:
Sam Ravnborg <sam@ravnborg.org>
-
Paul Cercueil authored
Add support for the LCD panels that must be driven with the Sharp-specific signals SPL, CLS, REV, PS. An example of such panel is the LS020B1DD01D supported by the panel-simple DRM panel driver. Signed-off-by:
-
Paul Cercueil authored
Simplify a bit the probe function by using the newly introduced devm_platform_ioremap_resource(), instead of having to call platform_get_resource() followed by devm_ioremap_resource(). Signed-off-by:
-
Neil Armstrong authored
When using an I2S source using a different clock source (usually the I2S audio HW uses dedicated PLLs, different from the HDMI PHY PLL), fixed CTS values will cause some frequent audio drop-out and glitches as reported on Amlogic, Allwinner and Rockchip SoCs setups. Setting the CTS in automatic mode will let the HDMI controller generate automatically the CTS value to match the input audio clock. The DesignWare DW-HDMI User Guide explains: For Automatic CTS generation Write "0" on the bit field "CTS_manual", Register 0x3205: AUD_CTS3 The DesignWare DW-HDMI Databook explains : If "CTS_manual" bit equals 0b this registers contains "audCTS[19:0]" generated by the Cycle time counter according to specified timing. Cc: Jernej Skrabec <jernej.skrabec@siol.net> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Tested-by:
Jernej Skrabec <jernej.skrabec@siol.net> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190612085147.26971-1-narmstrong@baylibre.com
-
Lucas Stach authored
To get the chip into the expected state, even when the hardware reset pin isn't connected, do a software reset in this case. It isn't as thorough as the hardware reset, as the I2C communication block can not be reset for obvious reasons, but it's getting the chip into a defined state. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
-
Matt Redfearn authored
In contrast to all of the DSI panel drivers in drivers/gpu/drm/panel which attach to the DSI host via mipi_dsi_attach() at probe time, the ADV7533 bridge device does not. Instead it defers this to the point that the upstream device connects to its bridge via drm_bridge_attach(). The generic Synopsys MIPI DSI host driver does not register it's own drm_bridge until the MIPI DSI has attached. But it does not call drm_bridge_attach() on the downstream device until the upstream device has attached. This leads to a chicken and the egg failure and the DRM pipeline does not complete. Since all other mipi_dsi_device drivers call mipi_dsi_attach() in probe(), make the adv7533 mipi_dsi_device do the same. This ensures that the Synopsys MIPI DSI host registers it's bridge such that it is available for the upstream device to connect to. Signed-off-by:
Matt Redfearn <matt.redfearn@thinci.com> Signed-off-by:
-
Sam Ravnborg authored
Drop use of the deprecated header file drmP.h from the sole user in the stm driver. Replace with necessary include files. Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190630061922.7254-4-sam@ravnborg.org
-
- 30 Jun, 2019 5 commits
-
-
Sam Ravnborg authored
I have agreed with Boris Brezillon that we will share the maintainer role for the drm/atmel_hlcdc driver. Nicolas Ferre from Microchip has donated a few boards that allows me to test things - thanks! Signed-off-by:
Boris Brezillon <bbrezillon@kernel.org> Acked-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Claudiu Beznea <claudiu.beznea@microchip.com> Cc: Peter Rosin <peda@axentia.se> Link: https://patchwork.freedesktop.org/patch/msgid/20190627211643.GA19853@ravnborg.org
-
Sam Ravnborg authored
Drop use of the deprecated drmP.h header file. Replace with necessary include files to fix build. Signed-off-by:
-
Sam Ravnborg authored
Drop the use of the deprecated drmP.h header file. Clean up list of include files and sort them. Signed-off-by:
-
Sam Ravnborg authored
This makes migration away from drmP.h simple as we do not need to duplicate dependencies required by mga_drv.h Signed-off-by:
-
Sam Ravnborg authored
Opencode all macros used from the deprecated drm_os_linux.h header file. The DRM_WAIT_ON used 3 * HZ as timeout. This was translated to 3000 msec. The return value of mga_driver_fence_wait() was not used, so make it return void to simplify code a bit. v2: - fixed timeout to 3000 msec (original value was 3 * Hz) - drop unused return value from mga_driver_fence_wait() Signed-off-by:
-
- 28 Jun, 2019 5 commits
-
-
Steven Price authored
panfrost_ioctl_mmap_bo() contains a reimplementation of drm_gem_map_offset() but with a bug - it allows mapping imported objects (without going through the exporter). Fix this by switching to use the newly renamed drm_gem_map_offset() function instead which has the bonus of simplifying the code. Signed-off-by:
Steven Price <steven.price@arm.com> Reviewed-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Signed-off-by:
-
Steven Price authored
drm_gem_dumb_map_offset() is a useful helper for non-dumb clients, so rename it to remove the _dumb and add a comment that it can be used by shmem clients. Signed-off-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Daniel Vetter authored
That's purely for the uapi layer to implement the ALLOW_MODESET flag. Drivers should instead look at the state, e.g. through drm_atomic_crtc_needs_modeset(), which vmwgfx already does. Also remove the confusing comment, since checking allow_modeset is at best a micro optimization. v2: Rebase Reviewed-by:
Deepak Rawat <drawat@vmware.com> Signed-off-by:
-
Christian König authored
They are not used that often and certainly not in a hot path. Make them normal functions instead of an inline. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
-
Thomas Zimmermann authored
The ast driver's struct ast_framebuffer is a buffer object with GEM interface. There are already GEM framebuffer helpers that implement the same functionality. Convert ast to these. Signed-off-by:
-
- 27 Jun, 2019 16 commits
-
-
Daniel Vetter authored
vc4 has switched to using drm_fb->obj[], so we can just use the helper unchanged. v2: Make it compile ... oops. Cc: Eric Anholt <eric@anholt.net> Cc: Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190625204208.5614-4-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
msm has switched over to drm_fb->obj[] a while ago already, so we can just use the helper. v2: Make it compile ... oops. Cc: Eric Anholt <eric@anholt.net> Cc: Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
-
Daniel Vetter authored
With commit 5f6ed987 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Jun 14 22:35:57 2019 +0200 drm/prime: automatically set gem_obj->resv on import we consistently set drm_gem_bo.resv for imported buffers. Which means we don't need to check the dma-buf in the prepare_fb helper, but can generalize them so they're also useful for display+render drivers which use gem_bo.resv to track their own rendering for their own scanout buffers. Cc: Emil Velikov <emil.velikov@collabora.com> Cc: Eric Anholt <eric@anholt.net> Cc: Rob Clark <robdclark@gmail.com> Reviewed-by:
-
Thomas Zimmermann authored
The mgag200 driver's struct mga_framebuffer is a buffer object with GEM interface. There are already GEM framebuffer helpers that implement the same functionality. Convert mgag200 to these. Signed-off-by:
-
Andrey Smirnov authored
Transfer size of zero means a request to do an address-only transfer. Since the HW support this, we probably shouldn't be just ignoring such requests. While at it allow DP_AUX_I2C_MOT flag to pass through, since it is supported by the HW as well. Signed-off-by:
Andrey Smirnov <andrew.smirnov@gmail.com> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Andrey Gusakov <andrey.gusakov@cogentembedded.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Cory Tusar <cory.tusar@zii.aero> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
-
Andrey Smirnov authored
We don't need 8 byte array, DP_LINK_STATUS_SIZE (6) should be enough. This also gets rid of a magic number as a bonus. Signed-off-by:
-
Andrey Smirnov authored
tc_get_display_props() never reads more than a byte via AUX, so there's no need to reserve 8 for that purpose. No function change intended. Signed-off-by:
-
Andrey Smirnov authored
We never pass anything but 100 as timeout_ms to tc_aux_wait_busy(), so we may as well hardcode that value and simplify function's signature. Signed-off-by:
-
Andrey Smirnov authored
tc_wait_pll_lock() is always called as a follow-up for updating PLLUPDATE and PLLEN bit of a given PLL control register. To simplify things, merge the two operation into a single helper function tc_pllupdate() and convert the rest of the code to use it. No functional change intended. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Andrey Smirnov authored
Move common code converting clock rate to an appropriate constant and configuring SYS_PLLPARAM register into a separate routine and convert the rest of the code to use it. No functional change intended. Signed-off-by:
-
Andrey Smirnov authored
Don't assume that requested data transfer size is the same as amount of data that was transferred. Change the code to get that information from DP0_AUXSTATUS instead. Since the check for AUX_BUSY in tc_aux_get_status() is pointless (it will always called after tc_aux_wait_busy()) and there's only one user of it, inline its code into tc_aux_transfer() instead of trying to accommodate the change above. Signed-off-by:
-
Andrey Smirnov authored
According to the datasheet tc358767 can transfer up to 16 bytes via its AUX channel, so the artificial limit of 8 appears to be too low. However only up to 15-bytes seem to be actually supported and trying to use 16-byte transfers results in transfers failing sporadically (with bogus status in case of I2C transfers), so limit it to 15. Signed-off-by:
-
Andrey Smirnov authored
Simplify AUX data write by dropping index arithmetic and shifting and replacing it with a call to a helper function that does two things: 1. Copies user-provided data into a write buffer 2. Transfers contents of the write buffer to up to 4 32-bit registers on the chip Note that separate data endianness fix: tmp = (tmp << 8) | buf[i]; that was reserved for DP_AUX_I2C_WRITE looks really strange, since it will place data differently depending on the passed user-data size. E.g. for a write of 1 byte, data transferred to the chip would look like: [byte0] [dummy1] [dummy2] [dummy3] whereas for a write of 4 bytes we'd get: [byte3] [byte2] [byte1] [byte0] Since there's no indication in the datasheet that I2C write buffer should be treated differently than AUX write buffer and no comment in the original code explaining why it was done this way, that special I2C write buffer transformation was dropped in this patch. Signed-off-by: -
Andrey Smirnov authored
Simplify AUX data read by removing index arithmetic and shifting with a helper function that does two things: 1. Fetch data from up to 4 32-bit registers from the chip 2. Copy read data into user provided array. Signed-off-by: -
Andrey Smirnov authored
A very unfortunate aspect of tc_write()/tc_read() macro helpers is that they capture quite a bit of context around them and thus require the caller to have magic variables 'ret' and 'tc' as well as label 'err'. That makes a number of code paths rather counter-intuitive and somewhat clunky, for example tc_stream_clock_calc() ends up being like this: int ret; tc_write(DP0_VIDMNGEN1, 32768); return 0; err: return ret; which is rather surprising when you read the code for the first time. Since those helpers arguably aren't really saving that much code and there's no way of fixing them without making them too verbose to be worth it change the driver code to not use them at all. Signed-off-by:
-
Andrey Smirnov authored
Simplify tc_set_video_mode() by replacing explicit shifting using macros from <linux/bitfield.h>. No functional change intended. Signed-off-by:
-
