07.06.2021 01:40, Dmitry Osipenko пишет:
> 01.06.2021 07:21, Dmitry Osipenko пишет:
>> This series adds memory bandwidth management to the NVIDIA Tegra DRM driver,
>> which is done using interconnect framework. It fixes display corruption that
>> happens due to insufficient memory bandwidth.
>>
>>
From: "Christian König"
Date: 2021-06-21 00:59:27
To: Bernard Zhao ,Alex Deucher
,David Airlie ,Daniel Vetter
,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org
Subject: Re: [PATCH 0/4] delete useless function return values & remove
meaningless if(r)
Make sure the FIFO_CLEAR bit is latched in when configuring the
controller, so that the FIFO is really cleared. And then clear
the FIFO_CLEAR bit, since it is not self-clearing.
Fixes: 45d59d704080 ("drm: Add new driver for MXSFB controller")
Signed-off-by: Marek Vasut
Cc: Daniel Abrecht
Cc:
In case there is a bridge connected to the LCDIF, use bus_format
from the bridge, otherwise behave as before and use bus_format
from the connector. This way, even if there are multiple bridges
in the display pipeline, the LCDIF will use the correct format.
Signed-off-by: Marek Vasut
Cc: Daniel
Hi Dave,
On Sun, Jun 20, 2021 at 09:42:27PM +0300, Laurent Pinchart wrote:
> On Sun, Jun 20, 2021 at 03:29:03PM +0100, Dave Stevenson wrote:
> > On Sun, 20 Jun 2021 at 04:26, Laurent Pinchart wrote:
> > >
> > > Hi Maxime,
> > >
> > > I'm testing this, and I'm afraid it causes an issue with all
The iMX8MM and iMX8MN do not support the overlay plane, so they
are MXSFB V4. Add the compatible strings to reflect this. Note
that iMX8MQ does support the overlay plane, so it is MXSFB V6.
Signed-off-by: Marek Vasut
Cc: Daniel Abrecht
Cc: Emil Velikov
Cc: Laurent Pinchart
Cc: Lucas Stach
In case the DRAM is under high load, the MXSFB FIFO might underflow
and that causes visible artifacts. This could be triggered on i.MX8MM
using e.g. "$ memtester 128M" on a device with 1920x1080 panel. The
first "Stuck Address" test of the memtester will completely corrupt
the image on the panel
There is some sort of corner case behavior of the controller,
which could rarely be triggered at least on i.MX6SX connected
to 800x480 DPI panel and i.MX8MM connected to DPI->DSI->LVDS
bridged 1920x1080 panel (and likely on other setups too), where
the image on the panel shifts to the right and
Patching the connector format is causing various problematic
side effects. Implement .atomic_get_input_bus_fmts callback
instead, which sets up the input (DSI-end) format, and that
format can then be used in pipeline format negotiation between
the DSI-end of this bridge and the other component
https://bugzilla.kernel.org/show_bug.cgi?id=213391
--- Comment #22 from dimit...@gmail.com ---
Updated initrd also to 20210315, ran under 5.12.11-200.fc33 for a day or so
without issues, now under 5.12.12-200.fc33, we'll see how it goes.
For reference what's the best way to check the
According to .update_status() is supposed to
return 0 on success and a negative error code otherwise. Adapt
lm3630a_bank_a_update_status() to actually do it.
While touching that also add the error code to the failure message.
Signed-off-by: Uwe Kleine-König
---
The practical upside here is that this only needs a single API call to
program the hardware which (depending on the underlaying hardware) can
be more effective and prevents glitches.
Up to now the return value of the pwm functions was ignored. Fix this
and propagate the error to the caller.
Hi Dave,
On Sun, Jun 20, 2021 at 03:29:03PM +0100, Dave Stevenson wrote:
> On Sun, 20 Jun 2021 at 04:26, Laurent Pinchart wrote:
> >
> > Hi Maxime,
> >
> > I'm testing this, and I'm afraid it causes an issue with all the
> > I2C-controlled bridges. I'm focussing on the newly merged ti-sn65dsi83
>
Am 19.06.21 um 08:43 schrieb Bernard Zhao:
Function radeon_fence_driver_init always returns success,
the function type maybe coule be changed to void.
This patch series will first delete the check of the return
value of the function call radeon_fence_driver_init, then,
optimise the function
Hi Laurent
On Sun, 20 Jun 2021 at 04:26, Laurent Pinchart
wrote:
>
> Hi Maxime,
>
> I'm testing this, and I'm afraid it causes an issue with all the
> I2C-controlled bridges. I'm focussing on the newly merged ti-sn65dsi83
> driver at the moment, but other are affected the same way.
>
> With this
On Thu, Jun 17, 2021 at 10:16:57AM -0500, Alex Sierra wrote:
> v1:
> AMD is building a system architecture for the Frontier supercomputer with a
> coherent interconnect between CPUs and GPUs. This hardware architecture allows
> the CPUs to coherently access GPU device memory. We have hardware in
https://bugzilla.kernel.org/show_bug.cgi?id=213391
--- Comment #21 from Dominic Letz (dominic.l...@berlin.de) ---
So I'm running since 16th on 20210315 and it has been stable so far vs.
multiple freezes a day before.
--
You may reply to this email to add a comment.
You are receiving this mail
On Tue, Jun 15, 2021 at 09:26:16AM -0700, Saravana Kannan wrote:
On Tue, Jun 15, 2021 at 8:50 AM Sasha Levin wrote:
From: Saravana Kannan
[ Upstream commit 9bf3797796f570b34438235a6a537df85832bdad ]
On sunxi boards that use HDMI output, HDMI device probe keeps being
avoided indefinitely
mt8192 has different routing registers than mt8183
Signed-off-by: Yongqiang Niu
---
drivers/soc/mediatek/mt8192-mmsys.h | 68 +
drivers/soc/mediatek/mtk-mmsys.c| 11 ++
2 files changed, 79 insertions(+)
create mode 100644
This patch add some more ddp component
OVL_2L2 is ovl which include 2 layers overlay
POSTMASK control round corner for display frame
RDMA4 read dma buffer
Change-Id: I464ea2dce6a312de8fad2cdbd94a4c71ab45af8f
Signed-off-by: Yongqiang Niu
Reviewed-by: Chun-Kuang Hu
Reviewed-by: Enric Balletbo i
base 5.13-rc1
Change since v5:
- squash ddp component into one patch
- add 8192 mmsys compatible data
Yongqiang Niu (2):
soc: mediatek: mmsys: add comp OVL_2L2/POSTMASK/RDMA4
soc: mediatek: mmsys: Add mt8192 mmsys routing table
drivers/soc/mediatek/mt8192-mmsys.h| 68
Currently, direct copies of drm_file->master pointers should be
protected by drm_device.master_mutex when being dereferenced. This is
because drm_file->master is not invariant for the lifetime of
drm_file. If drm_file is not the creator of master, then
drm_file->is_master is false, and a call to
While checking the master status of the DRM file in
drm_is_current_master(), the device's master mutex should be
held. Without the mutex, the pointer fpriv->master may be freed
concurrently by another process calling drm_setmaster_ioctl(). This
could lead to use-after-free errors when the pointer
This patch series addresses potential use-after-free errors when dereferencing
pointers to struct drm_master. These were identified after one such bug was
caught by Syzbot in drm_getunique():
https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803
The series is broken up
Hi Rajeev
On Sat, Jun 19, 2021 at 04:10:30PM +0530, Rajeev Nandan wrote:
> Add Samsung 13.3" FHD eDP AMOLED panel.
>
> Signed-off-by: Rajeev Nandan
> Reviewed-by: Douglas Anderson
> ---
>
> Changes in v4:
> - New
>
> Changes in v5:
> - Remove "uses_dpcd_backlight" property, not required now.
Hi Rajeev
On Sat, Jun 19, 2021 at 04:10:26PM +0530, Rajeev Nandan wrote:
> Some panels support backlight control over DP AUX channel using
> VESA's standard backlight control interface.
> Using new DRM eDP backlight helpers, add support to create and
> register a backlight for those panels in
26 matches
Mail list logo
