- 01 Jul, 2019 6 commits
-
-
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 <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190627182114.27299-2-paul@crapouillou.net # *** extracted tags *** Reviewed-by:
Sam Ravnborg <sam@ravnborg.org>
-
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:
Thomas Zimmermann <tzimmermann@suse.de> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Link: https://patchwork.freedesktop.org/patch/msgid/20190623103542.30697-5-sam@ravnborg.org
-
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:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190627155318.38053-3-steven.price@arm.com
-
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:
Daniel Vetter <daniel.vetter@ffwll.ch> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190520223500.6032-1-daniel.vetter@ffwll.ch
-
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 24 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:
-
Andrey Smirnov authored
Replace explicit polling in tc_link_training() with equivalent call to tc_poll_timeout() for simplicity. No functional change intended (not including slightly altered debug output). Signed-off-by:
-
Andrey Smirnov authored
Replace explicit polling loop with equivalent call to tc_poll_timeout() for brevity. No functional change intended. Signed-off-by:
-
Andrey Smirnov authored
Implementation of tc_poll_timeout() is almost a 100% copy-and-paste of the code for regmap_read_poll_timeout(). Replace copied code with a call to the original. While at it change tc_poll_timeout to accept "struct tc_data *" instead of "struct regmap *" for brevity. No functional change intended. Signed-off-by:
-
Rob Herring authored
The panel bindings are outside the scope of the Rockchip LVDS interface binding. The references are about to change too, so rather than update them just drop the section on the panel bindings. Cc: Sandy Huang <hjc@rock-chips.com> Cc: "Heiko Stübner" <heiko@sntech.de> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-rockchip@lists.infradead.org Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190624215649.8939-2-robh@kernel.org
-
Colin Ian King authored
There is an if block that is missing the { } curly brackets. Add these in. Addresses-Coverity: ("Structurally dead code") Fixes: 94dc57b1 ("drm/mgag200: Rewrite cursor handling") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Daniel Vetter authored
We're now guaranteed to no longer race against prepare_fb/cleanup_fb, which means we can access ->vaddr without having to hold a lock. Before the previous patches it was fairly easy to observe the cursor ->vaddr being invalid, but that's now gone, so we can upgrade to a full WARN_ON. Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Tested-by:
-
Daniel Vetter authored
The crc computation worker needs to be able to get at some data structures and framebuffer mappings, while potentially more atomic updates are going on. The solution thus far is to copy relevant bits around, but that's very tedious. Here's a new approach, which tries to be more clever, but relies on a few not-so-obvious things: - crtc_state is always updated when a plane_state changes. Therefore we can just stuff plane_state pointers into a crtc_state. That solves the problem of easily getting at the needed plane_states. - with the flushing changes from previous patches the above also holds without races due to the next atomic update being a bit eager with cleaning up pending work - we always wait for all crc work items to complete before unmapping framebuffers. - we also need to make sure that the hrtimer fires off the right worker. Keep a new distinct crc_state pointer, under the vkms_output->lock protection for this. Note that crtc->state is updated very early in the atomic commit, way before we arm the vblank event - the vblank event should always match the buffers we use to compute the crc. This also solves an issue in the hrtimer, where we've accessed drm_crtc->state without holding the right locks (we held none - oops). - in the worker itself we can then just access the plane states we need, again solving a bunch of ordering and locking issues. Accessing plane->state requires locks, accessing the private vkms_crtc_state->active_planes pointer only requires that the memory doesn't get freed too early. The idea behind vkms_crtc_state->active_planes is that this would contain all visible planes, in z-order, as a first step towards a more generic blending implementation. Note that this patch also fixes races between prepare_fb/cleanup_fb and the crc worker accessing ->vaddr. Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Daniel Vetter authored
irqs are already off. Signed-off-by:
-
