Commit 1bdb542da7 ("drm/ingenic: Simplify code by using hwdescs
array") caused the dma_hwdesc_phys_f{0,1} variables to be used while
uninitialized in a mmio register write, which most certainly broke the
ingenic-drm driver.
However, the very same patchset also submitted commit 6055466203
("drm/ingenic: Upload palette before frame"), which restored a correct
behaviour by doing the register writes in a different place in the code.
What's left of this, is just to remove the bogus register writes in the
probe function.
Signed-off-by: Paul Cercueil <[email protected]>
Reported-by: kernel test robot <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Acked-by: Sam Ravnborg <[email protected]>
When using C8 color mode, make sure that the palette is always uploaded
before a frame; otherwise the very first frame will have wrong colors.
Do that by changing the link order of the DMA descriptors.
v3: Fix ingenic_drm_get_new_priv_state() called instead of
ingenic_drm_get_priv_state()
Signed-off-by: Paul Cercueil <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Tested-by: Nikolaus Schaller <[email protected]>
Reviewed-by: Christophe Branchereau <[email protected]>
Setting the DMA descriptor chain register in the probe function has been
fine until now, because we only ever had one descriptor per foreground.
As the driver will soon have real descriptor chains, and the DMA
descriptor chain register updates itself to point to the current
descriptor being processed, this register needs to be reset after a full
modeset to point to the first descriptor of the chain.
Signed-off-by: Paul Cercueil <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Tested-by: Nikolaus Schaller <[email protected]>
Reviewed-by: Christophe Branchereau <[email protected]>
Until now, the ingenic-drm as well as the ingenic-ipu drivers used to
put state-specific information in their respective private structure.
Add boilerplate code to support private objects in the two drivers, so
that state-specific information can be put in the state-specific private
structure.
Signed-off-by: Paul Cercueil <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Tested-by: Nikolaus Schaller <[email protected]>
Reviewed-by: Christophe Branchereau <[email protected]>
Instead of having one 'hwdesc' variable for the plane #0, one for the
plane #1 and one for the palette, use a 'hwdesc[3]' array, where the
DMA hardware descriptors are indexed by the plane's number.
v2: dma_hwdesc_addr() extended to support palette hwdesc. The palette
hwdesc is now hwdesc[3] to simplify things. Add
ingenic_drm_configure_hwdesc*() functions to factorize code.
Signed-off-by: Paul Cercueil <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Tested-by: Nikolaus Schaller <[email protected]>
Reviewed-by: Christophe Branchereau <[email protected]>
Today's -next fails building arm64 defconfig as follows:
ERROR: modpost: module drm_cma_helper uses symbol dma_buf_vunmap from
namespace DMA_BUF, but does not import it.
ERROR: modpost: module drm_cma_helper uses symbol dma_buf_vmap from
namespace DMA_BUF, but does not import it.
Fix this by importing DMA_BUF namespace into drm_cma_helper.ko. Also
fix the problem with drm_shmem_helper.ko.
Reported-by: Linux Kernel Functional Testing <[email protected]>
Fixes: 4b2b5e142f ("drm: Move GEM memory managers into modules")
Signed-off-by: Marcel Ziswiler <[email protected]>
Signed-off-by: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
The left shift of unsigned int 32 bit integer constant 1 is evaluated
using 32 bit arithmetic and then assigned to a signed 64 bit integer.
In the case where value is 32 or more this can lead to an overflow
(value can be in range 0..MAX_CAPSET_ID (63). Fix this by shifting
the value 1ULL instead.
Addresses-Coverity: ("Uninitentional integer overflow")
Fixes: 4fb530e5ca ("drm/virtio: implement context init: support init ioctl")
Signed-off-by: Colin Ian King <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Gerd Hoffmann <[email protected]>
The left shift of unsigned int 32 bit integer constant 1 is evaluated
using 32 bit arithmetic and then assigned to a signed 64 bit integer.
In the case where i is 32 or more this can lead to an overflow. Fix
this by shifting the value 1ULL instead.
Addresses-Coverity: ("Uninitentional integer overflow")
Fixes: 8d6b006e1f ("drm/virtio: implement context init: handle VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK")
Signed-off-by: Colin Ian King <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Gerd Hoffmann <[email protected]>
When built without CONFIG_PWM there are no references to
ti_sn65dsi86_read_u16(), avoid the W=1 build warning by marking the
function as __maybe_unused.
__maybe_unused is used insted of a #ifdef guard as it looks slighly
cleaner and it avoids issues if in the future other permutations of the
config options would use the function.
Reported-by: kernel test robot <[email protected]>
Fixes: cea86c5bb4 ("drm/bridge: ti-sn65dsi86: Implement the pwm_chip")
Signed-off-by: Bjorn Andersson <[email protected]>
Reviewed-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Robert Foss <[email protected]>
In this patch(https://patchwork.freedesktop.org/patch/310349),
it add a new IOCTL to support dma-buf user to set debug name.
But it also added a limitation of this IOCTL, it needs the
attachments of dmabuf should be empty, otherwise it will fail.
For the original series, the idea was that allowing name change
mid-use could confuse the users about the dma-buf.
However, the rest of the series also makes sure each dma-buf have a unique
inode(https://patchwork.freedesktop.org/patch/310387/), and any accounting
should probably use that, without relying on the name as much.
So, removing this restriction will let dma-buf userspace users to use it
more comfortably and without any side effect.
Signed-off-by: Guangming Cao <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Christian König <[email protected]>
Signed-off-by: Christian König <[email protected]>
Without proper care and an agreement between how DSI hosts and devices
drivers register their MIPI-DSI entities and potential components, we can
end up in a situation where the drivers can never probe.
Most drivers were taking evasive maneuvers to try to workaround this,
but not all of them were following the same conventions, resulting in
various incompatibilities between DSI hosts and devices.
Now that we have a sequence agreed upon and documented, let's convert
kirin to it.
Acked-by: John Stultz <[email protected]>
Tested-by: John Stultz <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Commit 24417d5b0c ("drm/bridge: ti-sn65dsi83: Implement .detach
callback") moved the unregistration of the bridge DSI device and bridge
itself to the detach callback.
While this is correct for the DSI device detach and unregistration, the
bridge is added in the driver probe, and should thus be removed as part
of its remove callback.
Acked-by: Sam Ravnborg <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
Fixes: 24417d5b0c ("drm/bridge: ti-sn65dsi83: Implement .detach callback")
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
The SN65DSI86 provides the ability to supply a PWM signal on GPIO 4,
with the primary purpose of controlling the backlight of the attached
panel. Add an implementation that exposes this using the standard PWM
framework, to allow e.g. pwm-backlight to expose this to the user.
Signed-off-by: Bjorn Andersson <[email protected]>
Reviewed-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
The multi-register u16 write operation can use regmap_bulk_write()
instead of two separate regmap_write() calls.
It's uncertain if this has any effect on the actual updates of the
underlying registers, but this at least gives the hardware the
opportunity and saves us one transation on the bus.
Signed-off-by: Bjorn Andersson <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
The existing pxa driver and the upcoming addition of PWM support in the
TI sn565dsi86 DSI/eDP bridge driver both has a single PWM channel and
thereby a need for a of_xlate function with the period as its single
argument.
Introduce a common helper function in the core that can be used as
of_xlate by such drivers and migrate the pxa driver to use this.
Signed-off-by: Bjorn Andersson <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Tested-by: Steev Klimaszewski <[email protected]>
Tested-By: Steev Klimaszewski <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
The new driver incorrectly unwinds after errors, as clang points out:
drivers/dma-buf/st-dma-resv.c:295:7: error: variable 'i' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
if (r) {
^
drivers/dma-buf/st-dma-resv.c:336:9: note: uninitialized use occurs here
while (i--)
^
drivers/dma-buf/st-dma-resv.c:295:3: note: remove the 'if' if its condition is always false
if (r) {
^~~~~~~~
drivers/dma-buf/st-dma-resv.c:288:6: error: variable 'i' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
if (r) {
^
drivers/dma-buf/st-dma-resv.c:336:9: note: uninitialized use occurs here
while (i--)
^
drivers/dma-buf/st-dma-resv.c:288:2: note: remove the 'if' if its condition is always false
if (r) {
^~~~~~~~
drivers/dma-buf/st-dma-resv.c:280:10: note: initialize the variable 'i' to silence this warning
int r, i;
^
= 0
Skip cleaning up the bits that have not been allocated at this point.
Fixes: 1d51775cd3 ("dma-buf: add dma_resv selftest v4")
Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Christian König <[email protected]>
Since commit 875a4d5368 ("drm/vc4: drv: Disable the CRTC at boot
time"), during the initial setup of the driver we call into the VC4 HDMI
controller hooks to make sure the controller is properly disabled.
However, we were never making sure that the device was properly powered
while doing so. This never resulted in any (reported) issue in practice,
but since the introduction of commit 4209f03fcb8e ("drm/vc4: hdmi: Warn
if we access the controller while disabled") we get a loud complaint
when we do that kind of access.
Let's make sure we have the HDMI controller properly powered while
disabling it.
Fixes: 875a4d5368 ("drm/vc4: drv: Disable the CRTC at boot time")
Signed-off-by: Maxime Ripard <[email protected]>
Reviewed-by: Nicolas Saenz Julienne <[email protected]>
Tested-by: Nicolas Saenz Julienne <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
We've had many silent hangs where the kernel would look like it just
stalled due to the access to one of the HDMI registers while the
controller was disabled.
Add a warning if we're about to do that so that it's at least not silent
anymore.
Reviewed-by: Dave Stevenson <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Paul Cercueil