Hi
Am 17.11.20 um 17:22 schrieb Ville Syrjälä:
> On Mon, Nov 16, 2020 at 09:04:28PM +0100, Thomas Zimmermann wrote:
>> If fbdev uses a shadow framebuffer, call the damage handler. Otherwise
>> the update might not make it to the screen.
>>
>> Signed-off-by: Thomas Zimmermann
>> Fixes: 222ec45f4c6
Hi "Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20201117]
[cannot apply to linus/master v5.10-rc4 v5.10-rc3 v5.10-rc2 v5.10-rc4]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
On Wed, Nov 18, 2020 at 3:40 AM John Stultz wrote:
> On Fri, Nov 13, 2020 at 12:39 PM Daniel Vetter wrote:
> > On Thu, Nov 12, 2020 at 08:11:02PM -0800, John Stultz wrote:
> > > On Thu, Nov 12, 2020 at 1:32 AM Daniel Vetter wrote:
> > > > On Thu, Nov 12, 2020 at 11:09:04AM +0530, Sumit Semwal wr
On Tue, Nov 17, 2020 at 9:07 PM Andrey Grodzovsky
wrote:
>
>
> On 11/17/20 2:49 PM, Daniel Vetter wrote:
> > On Tue, Nov 17, 2020 at 02:18:49PM -0500, Andrey Grodzovsky wrote:
> >> On 11/17/20 1:52 PM, Daniel Vetter wrote:
> >>> On Tue, Nov 17, 2020 at 01:38:14PM -0500, Andrey Grodzovsky wrote:
>
I didnt' format the thing correctly :-(
Fixes: 39aead8373b3 ("fbcon: Disable accelerated scrolling")
Reported-by: Stephen Rothwell
Cc: Stephen Rothwell
Signed-off-by: Daniel Vetter
---
Documentation/gpu/todo.rst | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/gpu/todo.rst
Hi all,
After merging the drm-misc tree, today's linux-next build (htmldocs)
produced this warning:
Documentation/gpu/todo.rst:302: WARNING: Unexpected indentation.
Documentation/gpu/todo.rst:303: WARNING: Block quote ends without a blank line;
unexpected unindent.
Introduced by commit
39aea
On Fri, Nov 13, 2020 at 12:39 PM Daniel Vetter wrote:
> On Thu, Nov 12, 2020 at 08:11:02PM -0800, John Stultz wrote:
> > On Thu, Nov 12, 2020 at 1:32 AM Daniel Vetter wrote:
> > > On Thu, Nov 12, 2020 at 11:09:04AM +0530, Sumit Semwal wrote:
> > > > On Tue, 10 Nov 2020 at 09:19, John Stultz
> >
On 2020-11-17 2:49 p.m., Daniel Vetter wrote:
> On Tue, Nov 17, 2020 at 02:18:49PM -0500, Andrey Grodzovsky wrote:
>>
>> On 11/17/20 1:52 PM, Daniel Vetter wrote:
>>> On Tue, Nov 17, 2020 at 01:38:14PM -0500, Andrey Grodzovsky wrote:
On 6/22/20 5:53 AM, Daniel Vetter wrote:
> On Sun, Jun 2
Hi Dave, Daniel,
Updates for 5.11.
The following changes since commit 512bce50a41c528fa15c4c014293e7bebf018658:
Merge v5.10-rc3 into drm-next (2020-11-10 14:36:36 +0100)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/linux tags/amd-drm-next-5.11-2020-11-17
for
On Tue, Nov 17, 2020 at 2:05 PM Rob Herring wrote:
>
> Now that we have a graph schema, rework the display related schemas to use
> it. Mostly this is adding a reference to graph.yaml and dropping duplicate
> parts from schemas.
>
> In panel-common.yaml, 'ports' is dropped. Any binding using 'port
On Mon, 16 Nov 2020 11:17:56 +0100 Mauro Carvalho Chehab wrote:
> Kernel-doc has always be limited to a probably bad documented
> rule:
>
> The kernel-doc markups should appear *imediatelly before* the
> function or data structure that it documents.
Applied 1-3 to net-next, thanks!
__
It's probably full of bugs ready for exploiting by userspace. And
there's not going to be any userspace for this without any of the drm
legacy drivers enabled too. So just couple it together.
Signed-off-by: Daniel Vetter
Cc: David Airlie
Cc: Adam Jackson
---
drivers/char/agp/Makefile | 6 +
On Tue, Nov 17, 2020 at 6:49 PM Guido Günther wrote:
> This panel from Shenzhen Yashi Changhua Intelligent Technology Co
> uses the same driver IC but a different LCD.
>
> Signed-off-by: Guido Günther
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
On Tue, Nov 17, 2020 at 6:49 PM Guido Günther wrote:
> Add prefix for Shenzhen Yashi Changhua Intelligent Technology Co., Ltd.
>
> Signed-off-by: Guido Günther
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation
On Tue, Nov 17, 2020 at 6:49 PM Guido Günther wrote:
> The panel uses the same driver IC and has the same resolution but a
> slightly different default mode. It seems it can work with the same
> init sequence.
>
> Signed-off-by: Guido Günther
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
__
On Tue, Nov 17, 2020 at 6:49 PM Guido Günther wrote:
> This can be used to use different modes for differnt panels via OF
> device match.
>
> Signed-off-by: Guido Günther
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
___
dri-devel mailing list
dri
On Tue, Nov 17, 2020 at 6:49 PM Guido Günther wrote:
> We've seen some (non permanent) burn in and bad white balance
> on some of the panels. Adding this bit from a vendor supplied
> sequence fixes it.
>
> Fixes: 72967d5616d3 ("drm/panel: Add panel driver for the Mantix
> MLAF057WE51-X DSI panel
On Tue, Nov 17, 2020 at 6:49 PM Guido Günther wrote:
> Less code and easier probe deferral debugging.
>
> Signed-off-by: Guido Günther
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https:/
On 2020-11-17 09:26, Stephen Boyd wrote:
I don't know what this debug print is for but it is super chatty,
throwing 8 lines of debug prints in the logs every time we update a
plane. It looks like it has no value. Let's nuke it so we can get
better logs.
Cc: Sean Paul
Cc: Abhinav Kumar
Signed-o
On 11/17/20 2:49 PM, Daniel Vetter wrote:
On Tue, Nov 17, 2020 at 02:18:49PM -0500, Andrey Grodzovsky wrote:
On 11/17/20 1:52 PM, Daniel Vetter wrote:
On Tue, Nov 17, 2020 at 01:38:14PM -0500, Andrey Grodzovsky wrote:
On 6/22/20 5:53 AM, Daniel Vetter wrote:
On Sun, Jun 21, 2020 at 02:03:08A
Now that we have a graph schema, rework the display related schemas to use
it. Mostly this is adding a reference to graph.yaml and dropping duplicate
parts from schemas.
In panel-common.yaml, 'ports' is dropped. Any binding using 'ports'
should be one with more than 1 port node, and the binding mu
On Tue, Nov 17, 2020 at 8:24 PM Sam Ravnborg wrote:
> > Cc: phone-de...@vger.kernel.org
> > Cc: Stephan Gerhold
> > Signed-off-by: Linus Walleij
> Fixes: ??
It's no regression actually: for the current hardware we just
invert the buffers twice and it looks OK. Buffers are declared
BGR and the
From: Leo Ruan
The generic fbdev has to be setup before enabling output polling.
Otherwise the fbdev client is not ready to handle delayed events.
Since f53705fd, the generic fbdev is setup after the output polling
init. During fbdev setup, when fbdev probes attached outputs and a
status changes
On 2020-11-16 18:56, Chen Zhou wrote:
Fix to return a negative error code from the error handling case
instead of 0 in function dpu_mdss_init(), as done elsewhere in this
function.
Fixes: 070e64dc1bbc ("drm/msm/dpu: Convert to a chained irq chip")
Reported-by: Hulk Robot
Signed-off-by: Chen Zho
On 2020-11-16 18:36, Wei Li wrote:
When it fail to create crtc_event kthread, it just jump to
err_msm_uninit,
while the 'ret' is not updated. So assign the return code before that.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Reported-by: Hulk Robot
Signed-off-by: Wei Li
Reviewed-
On Tue, Nov 17, 2020 at 02:18:49PM -0500, Andrey Grodzovsky wrote:
>
> On 11/17/20 1:52 PM, Daniel Vetter wrote:
> > On Tue, Nov 17, 2020 at 01:38:14PM -0500, Andrey Grodzovsky wrote:
> > > On 6/22/20 5:53 AM, Daniel Vetter wrote:
> > > > On Sun, Jun 21, 2020 at 02:03:08AM -0400, Andrey Grodzovsky
On Mon, Nov 16, 2020 at 05:41:12PM +, Lee Jones wrote:
> In the macro for_each_oldnew_crtc_in_state() 'crtc_state' is provided
> as a container for state->crtcs[i].new_state, but is not utilised in
> some use-cases, so we fake-use it instead.
>
> Fixes the following W=1 kernel build warning(s)
On Mon, Nov 16, 2020 at 05:41:08PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/vc4/vc4_hdmi.c: In function ‘vc4_hdmi_set_audio_infoframe’:
> drivers/gpu/drm/vc4/vc4_hdmi.c:334:6: warning: variable ‘ret’ set but not
> used [-Wunused-but-set-vari
Hi Linus
On Tue, Nov 17, 2020 at 06:54:13PM +0100, Linus Walleij wrote:
> I was confused when the graphics came out with blue
> penguins on the DPI panel.
>
> It turns out that the so-called "packed RGB666" mode
> on the DSI formatter is incorrect: this mode is the
> actual RGB888 mode, and the m
On 11/17/20 1:52 PM, Daniel Vetter wrote:
On Tue, Nov 17, 2020 at 01:38:14PM -0500, Andrey Grodzovsky wrote:
On 6/22/20 5:53 AM, Daniel Vetter wrote:
On Sun, Jun 21, 2020 at 02:03:08AM -0400, Andrey Grodzovsky wrote:
No point to try recovery if device is gone, just messes up things.
Signed-o
On Tue, Nov 17, 2020 at 08:33:46AM +, Lee Jones wrote:
> On Mon, 16 Nov 2020, Christian König wrote:
>
> > Am 16.11.20 um 18:41 schrieb Lee Jones:
> > > Fixes the following W=1 kernel build warning(s):
> > >
> > > drivers/gpu/drm/ttm/ttm_tt.c:45: warning: Function parameter or member
> > >
On Tue, Nov 17, 2020 at 06:13:40PM +, Lee Jones wrote:
> On Tue, 17 Nov 2020, Lee Jones wrote:
>
> > On Tue, 17 Nov 2020, Daniel Vetter wrote:
> >
> > > On Mon, Nov 16, 2020 at 05:40:33PM +, Lee Jones wrote:
> > > > Fixes the following W=1 kernel build warning(s):
> > > >
> > > > driver
On Mon, Nov 16, 2020 at 09:33:48PM +0100, Christian König wrote:
> Am 16.11.20 um 18:41 schrieb Lee Jones:
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/gpu/drm/ttm/ttm_bo.c:51: warning: Function parameter or member
> > 'ttm_global_mutex' not described in 'DEFINE_MUTEX'
>
On Mon, Nov 16, 2020 at 9:41 AM Lee Jones wrote:
>
> Very little attempt has been made to document these functions.
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Function parameter or
> member 'ctl' not described in 'mdp5_ctl_set_
On Mon, Nov 16, 2020 at 05:40:51PM +, Lee Jones wrote:
> ... and demote non-conformant kernel-doc header.
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nvkm/core/firmware.c:71: warning: Function parameter
> or member 'subdev' not described in 'nvkm_firmwar
On Tue, Nov 17, 2020 at 01:38:14PM -0500, Andrey Grodzovsky wrote:
>
> On 6/22/20 5:53 AM, Daniel Vetter wrote:
> > On Sun, Jun 21, 2020 at 02:03:08AM -0400, Andrey Grodzovsky wrote:
> > > No point to try recovery if device is gone, just messes up things.
> > >
> > > Signed-off-by: Andrey Grodzov
On Tue, Nov 17, 2020 at 8:11 AM Colin King wrote:
>
> From: Colin Ian King
>
> There are two spelling mistakes in dev_warn messages. Fix these.
>
> Signed-off-by: Colin Ian King
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 4 ++--
> 1 file changed, 2 inse
On 6/22/20 5:53 AM, Daniel Vetter wrote:
On Sun, Jun 21, 2020 at 02:03:08AM -0400, Andrey Grodzovsky wrote:
No point to try recovery if device is gone, just messes up things.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 16
drivers/gpu/drm
The iMX DRM LVDS driver uses Common Clock Framework thus it cannot be
built on platforms without it (e.g. compile test on MIPS with RALINK and
SOC_RT305X):
/usr/bin/mips-linux-gnu-ld: drivers/gpu/drm/imx/imx-ldb.o: in function
`imx_ldb_encoder_disable':
imx-ldb.c:(.text+0x400): undefined
On Tue, 17 Nov 2020, Lee Jones wrote:
> On Tue, 17 Nov 2020, Daniel Vetter wrote:
>
> > On Mon, Nov 16, 2020 at 05:40:33PM +, Lee Jones wrote:
> > > Fixes the following W=1 kernel build warning(s):
> > >
> > > drivers/gpu/drm/drm_dp_mst_topology.c: In function
> > > ‘drm_dp_send_query_stre
On Tue, 17 Nov 2020, Daniel Vetter wrote:
> On Mon, Nov 16, 2020 at 05:40:33PM +, Lee Jones wrote:
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/gpu/drm/drm_dp_mst_topology.c: In function
> > ‘drm_dp_send_query_stream_enc_status’:
> > drivers/gpu/drm/drm_dp_mst_topol
On Tue, Nov 17, 2020 at 1:00 PM Rafael J. Wysocki
wrote:
>
> On 11/16/2020 10:05 PM, Steven Rostedt wrote:
> > On Mon, 16 Nov 2020 12:55:29 -0800
> > Peiyong Lin wrote:
> >
> >> Hi there,
> >>
> >> May I ask whether the merge window has passed? If so is it possible to
> >> ask for a review?
> > T
On 11/16/2020 10:05 PM, Steven Rostedt wrote:
On Mon, 16 Nov 2020 12:55:29 -0800
Peiyong Lin wrote:
Hi there,
May I ask whether the merge window has passed? If so is it possible to
ask for a review?
This is up to the maintainers of power management to accept this.
Rafael?
I'd say up to th
The init sequence consist of a number of unknown settings
for the display controller. This patch achieves two things:
- Fix an error that must have happened when the driver was
converted from the backlight subsystem: the 0xb8
configuration command was lost and added as a tail to
the previous
A later version of the s6e63m0 driver in the Samsung
GT-I9070 vendor tree provides 28 different backlight
levels making use of elaborate control of the ACL
and ELVSS regulator. Implement this more fine-grained
backlight control.
Cc: Stephan Gerhold
Cc: Paweł Chmiel
Signed-off-by: Linus Walleij
Fix up the format of the manufacturer command set table
to be TAB-indented and lowercase. Add the MCS_TEMP_SWIRE
command that we will make use of.
Cc: Stephan Gerhold
Cc: Paweł Chmiel
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 17 +
1 file
I was confused when the graphics came out with blue
penguins on the DPI panel.
It turns out that the so-called "packed RGB666" mode
on the DSI formatter is incorrect: this mode is the
actual RGB888 mode, and the mode called RGB888 is
BGR888.
The claims that the MCDE had inverse RGB/BGR buffer
for
The panel uses the same driver IC and has the same resolution but a
slightly different default mode. It seems it can work with the same
init sequence.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 16
1 file changed, 16 insertions(+)
diff -
We've seen some (non permanent) burn in and bad white balance
on some of the panels. Adding this bit from a vendor supplied
sequence fixes it.
Fixes: 72967d5616d3 ("drm/panel: Add panel driver for the Mantix MLAF057WE51-X
DSI panel")
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-
This panel from Shenzhen Yashi Changhua Intelligent Technology Co
uses the same driver IC but a different LCD.
Signed-off-by: Guido Günther
---
.../devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/
This can be used to use different modes for differnt panels via OF
device match.
Signed-off-by: Guido Günther
---
.../gpu/drm/panel/panel-mantix-mlaf057we51.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.
Less code and easier probe deferral debugging.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 24 +++
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
b/drivers/gpu/drm/panel/panel-sitr
Add prefix for Shenzhen Yashi Changhua Intelligent Technology Co., Ltd.
Signed-off-by: Guido Günther
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
b/Documentation/devicetree
This adds new panel type to the mantix driver as found on the Librem 5 and
fixes a glitch in the init sequence (affecting both panels). The fix is at the
start of the series to make backporting simpler.
It also adds a patch to make st7703 use dev_err_probe().
Guido Günther (6):
drm/panel: st7703
On Tue, Nov 17, 2020 at 05:33:35PM +0100, Christian König wrote:
> ttm_module.h deals with internals of TTM and should never
> be include outside of it.
>
> Signed-off-by: Christian König
Maybe also move it to drivers/gpu/drm/ttm/ttm_internal.h. We're using the
_interal.h suffix in a few other p
On Mon, Nov 16, 2020 at 05:40:33PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/drm_dp_mst_topology.c: In function
> ‘drm_dp_send_query_stream_enc_status’:
> drivers/gpu/drm/drm_dp_mst_topology.c:3263:6: warning: variable ‘len’ set
> but not us
On Tue, Nov 17, 2020 at 03:06:15PM +0100, Christian König wrote:
> Increase the ammount of system memory drivers can use to about 90% of
> the total available.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> dif
On Thu, Nov 5, 2020 at 11:16 PM Viresh Kumar wrote:
>
> On 05-11-20, 11:24, Rob Clark wrote:
> > On Tue, Nov 3, 2020 at 7:04 PM Viresh Kumar wrote:
> > >
> > > On 03-11-20, 08:50, Rob Clark wrote:
> > > > sorry, it didn't apply cleanly (which I guess is due to some other
> > > > dependencies that
On Tue, Nov 17, 2020 at 04:14:46PM +0100, Sebastian Reichel wrote:
> Hi,
>
> On Mon, Nov 16, 2020 at 09:52:16PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 16, 2020 at 09:04:35PM +0100, Thomas Zimmermann wrote:
> > > If the damage handling fails, restore the damage area. The next invocation
> > >
On 2020-11-17 3:06 p.m., Christian König wrote:
Increase the ammount of system memory drivers can use to about 90% of
the total available.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/t
As far as I can tell this has never been used by any
userspace application.
The number of BOs in the system is far better suited in
debugfs than sysfs and we now should be able to add other
information here as well.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c
ttm_module.h deals with internals of TTM and should never
be include outside of it.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 -
drivers/gpu/drm/nouveau/nouveau_drv.h | 1 -
drivers/gpu/drm/qx
Only initialize the DMA coherent pools if they are used.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 5daf812551
Instead of printing this on the per device pool.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 70 --
1 file changed, 50 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 24ae7c
On Mon, Nov 16, 2020 at 09:04:28PM +0100, Thomas Zimmermann wrote:
> If fbdev uses a shadow framebuffer, call the damage handler. Otherwise
> the update might not make it to the screen.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 222ec45f4c69 ("drm/fb_helper: Support framebuffers in I/O memory"
From: Thomas Zimmermann
commit 06ad8d339524bf94b89859047822c31df6ace239 upstream.
The gma500 driver expects 3 pipelines in several it's IRQ functions.
Accessing struct drm_device.vblank[], this fails with devices that only
have 2 pipelines. An example KASAN report is shown below.
[ 62.26768
From: Thomas Zimmermann
commit 06ad8d339524bf94b89859047822c31df6ace239 upstream.
The gma500 driver expects 3 pipelines in several it's IRQ functions.
Accessing struct drm_device.vblank[], this fails with devices that only
have 2 pipelines. An example KASAN report is shown below.
[ 62.26768
From: Thomas Zimmermann
commit 06ad8d339524bf94b89859047822c31df6ace239 upstream.
The gma500 driver expects 3 pipelines in several it's IRQ functions.
Accessing struct drm_device.vblank[], this fails with devices that only
have 2 pipelines. An example KASAN report is shown below.
[ 62.26768
From: Thomas Zimmermann
commit 06ad8d339524bf94b89859047822c31df6ace239 upstream.
The gma500 driver expects 3 pipelines in several it's IRQ functions.
Accessing struct drm_device.vblank[], this fails with devices that only
have 2 pipelines. An example KASAN report is shown below.
[ 62.26768
From: Thomas Zimmermann
commit 06ad8d339524bf94b89859047822c31df6ace239 upstream.
The gma500 driver expects 3 pipelines in several it's IRQ functions.
Accessing struct drm_device.vblank[], this fails with devices that only
have 2 pipelines. An example KASAN report is shown below.
[ 62.26768
From: Thomas Zimmermann
commit 06ad8d339524bf94b89859047822c31df6ace239 upstream.
The gma500 driver expects 3 pipelines in several it's IRQ functions.
Accessing struct drm_device.vblank[], this fails with devices that only
have 2 pipelines. An example KASAN report is shown below.
[ 62.26768
When we have mixed DMA32 and non DMA32 device in one system
it could otherwise happen that the DMA32 device gets pages
it can't work with.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm
Hi,
On Mon, Nov 16, 2020 at 09:52:16PM +0100, Daniel Vetter wrote:
> On Mon, Nov 16, 2020 at 09:04:35PM +0100, Thomas Zimmermann wrote:
> > If the damage handling fails, restore the damage area. The next invocation
> > of the damage worker will then perform the update.
> >
> > Signed-off-by: Thom
Tested-by: Nirmoy Das Tested on commit 96fb3cbef165db97c999a02efe2287ba4b8c1ceb (HEAD,
drm-misc/drm-misc-next)
On 11/16/20 8:14 PM, Christian König wrote:
Reorder the code to fix checking if blitting is available.
Signed-off-by: Christian König
Fixes: f5a89a5cae81 drm/amdgpu/ttm: use multi
Increase the ammount of system memory drivers can use to about 90% of
the total available.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index a958135
This is just another feature which is only used by VMWGFX, so move
it into the driver instead.
I've tried to add the accounting sysfs file to the kobject of the drm
minor, but I'm not 100% sure if this works as expected.
Signed-off-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gp
TTM implements a rather extensive accounting of allocated memory.
There are two reasons for this:
1. It tries to block userspace allocating a huge number of very small
BOs without accounting for the kmalloced memory.
2. Make sure we don't over allocate and run into an OOM situation
during s
Hi, Vinod:
Chun-Kuang Hu 於 2020年11月17日 週二 上午7:14寫道:
>
> Mediatek MIPI DSI phy driver is moved from drivers/gpu/drm/mediatek to
> drivers/phy/mediatek, so add the new folder to the Mediatek DRM drivers'
> information.
>
> Signed-off-by: Chun-Kuang Hu
If you apply this patch, please add acked-by
Hi, Vinod:
Chunfeng Yun 於 2020年11月17日 週二 上午11:36寫道:
>
> Hi CK,
> On Tue, 2020-11-17 at 07:14 +0800, Chun-Kuang Hu wrote:
> > mtk_mipi_dsi_phy is currently placed inside mediatek drm driver, but it's
> > more suitable to place a phy driver into phy driver folder, so move
> > mtk_mipi_dsi_phy drive
Hi
Am 17.11.20 um 07:10 schrieb Yang Yingliang:
> Return -ENOMEM when allocating refill memory failed.
>
> Fixes: 71e8831f6407 ("drm/omap: DMM/TILER support for OMAP4+ platform")
> Reported-by: Hulk Robot
> Signed-off-by: Yang Yingliang
> ---
> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 1 +
>
By default, SHMEM GEM helpers map pages using writecombine. Only a few
drivers require this setting. Others revert it to default mappings
flags. Some could benefit from caching, but don't care.
Unify the behaviour by switching the SHMEM GEM code to use cached
mappings (i.e., PAGE_KERNEL actually);
Cached page mappings are now the default for SHMEM GEM objects. Remove
the obsolete create function for cached mappings.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 26 --
drivers/gpu/drm/mgag200/mgag200_drv.c | 1 -
drivers/gpu/drm/udl
SHMEM-buffer backing storage is allocated from system memory; which is
typically cachable. The default mode for SHMEM objects is writecombine
though.
Unify SHMEM semantics by defaulting to cached mappings. The exception
is pages imported via dma-buf. DMA memory is usually not cached.
DRM drivers
On Tue, Nov 17, 2020 at 3:43 AM Laurent Pinchart
wrote:
>
> Hi Rob,
>
> Thank you for the patch.
>
> On Mon, Nov 16, 2020 at 07:37:03PM -0600, Rob Herring wrote:
> > Now that we have a graph schema, rework the display related schemas to use
> > it. Mostly this is adding a reference to graph.yaml a
From: Colin Ian King
There are two spelling mistakes in dev_warn messages. Fix these.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
b/d
Hi Lee,
On Mon, 2020-11-16 at 17:41 +, Lee Jones wrote:
> They're taking up too much space on the stack.
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/ipu-v3/ipu-di.c: In function ‘ipu_di_sync_config_noninterlaced’:
> drivers/gpu/ipu-v3/ipu-di.c:391:1: warning: the f
On Tue, 17 Nov 2020 at 11:56, Philipp Zabel wrote:
>
> On Mon, 2020-11-16 at 19:14 +0100, Krzysztof Kozlowski wrote:
> > The iMX DRM drivers use Common Clock Framework thus they cannot be built
> > on platforms without it (e.g. compile test on MIPS with RALINK and
> > SOC_RT305X):
> >
> > /usr
On Tue, 17 Nov 2020, Daniel Vetter wrote:
> On Tue, Nov 17, 2020 at 10:34:04AM +, Lee Jones wrote:
> > Daniel,
> >
> > For some reason, you're not appearing in the recipents list when I
> > reply to all. You're not in the Mail-Followup-To header. Any idea
> > why this might be?
>
> No idea
On Mon, 2020-11-16 at 19:14 +0100, Krzysztof Kozlowski wrote:
> The iMX DRM drivers use Common Clock Framework thus they cannot be built
> on platforms without it (e.g. compile test on MIPS with RALINK and
> SOC_RT305X):
>
> /usr/bin/mips-linux-gnu-ld: drivers/gpu/drm/imx/imx-ldb.o: in functio
On Tue, Nov 17, 2020 at 10:34:04AM +, Lee Jones wrote:
> Daniel,
>
> For some reason, you're not appearing in the recipents list when I
> reply to all. You're not in the Mail-Followup-To header. Any idea
> why this might be?
No idea either, could be my mutt not setting the reply headers lik
Daniel,
For some reason, you're not appearing in the recipents list when I
reply to all. You're not in the Mail-Followup-To header. Any idea
why this might be?
Anyway, please see below:
On Tue, 17 Nov 2020, Daniel Vetter wrote:
> On Fri, Nov 13, 2020 at 10:01:57PM +, Lee Jones wrote:
> > O
On Fri, Nov 13, 2020 at 10:01:57PM +, Lee Jones wrote:
> On Fri, 13 Nov 2020, 21:31 Daniel Vetter, wrote:
>
> > On Fri, Nov 13, 2020 at 9:53 PM Lee Jones wrote:
> > >
> > >
> > >
> > > On Fri, 13 Nov 2020, 20:50 Daniel Vetter, wrote:
> > >>
> > >> On Thu, Nov 12, 2020 at 09:25:16PM +0100, S
Hi,
On Mon, Nov 16, 2020 at 11:22:53AM +0200, Laurent Pinchart wrote:
> On Thu, Nov 12, 2020 at 10:08:21AM +0200, Tomi Valkeinen wrote:
> > On 11/11/2020 17:58, Laurent Pinchart wrote:
> >
> > diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> > b/drivers/gpu/drm/omapdrm/di
On Thu, Oct 29, 2020 at 02:33:47PM +0100, Daniel Vetter wrote:
> These are leftovers from 13aff184ed9f ("drm/qxl: remove dead qxl fbdev
> emulation code").
>
> v2: Somehow these structs provided the struct qxl_device pre-decl,
> reorder the header to not anger compilers.
>
> Acked-by: Gerd Hoffma
On 17/11/2020 10:19, Marc Zyngier wrote:
> Hi Neil,
>
> On 2020-11-17 08:49, Neil Armstrong wrote:
>> Hi Marc,
>>
>> On 16/11/2020 21:07, Marc Zyngier wrote:
>>> Hi all,
>>>
>>> Having recently moved over to a top-of-the-tree u-boot on one of my
>>> VIM3L systems in order to benefit from unrelated
Hi Rob,
Thank you for the patch.
On Mon, Nov 16, 2020 at 07:37:03PM -0600, Rob Herring wrote:
> Now that we have a graph schema, rework the display related schemas to use
> it. Mostly this is adding a reference to graph.yaml and dropping duplicate
> parts from schemas.
>
> Cc: Thierry Reding
>
Hi Neil,
On 2020-11-17 08:49, Neil Armstrong wrote:
Hi Marc,
On 16/11/2020 21:07, Marc Zyngier wrote:
Hi all,
Having recently moved over to a top-of-the-tree u-boot on one of my
VIM3L systems in order to benefit from unrelated improvements
(automatic PCIe detection, EFI...), I faced the issue
On 16/11/2020 21:07, Marc Zyngier wrote:
> Removing the meson-dw-hdmi module and re-inserting it results in a hang
> as the driver writes to HDMITX_TOP_SW_RESET. Similar effects can be seen
> when booting with mainline u-boot and using the u-boot provided DT (which
> is highly desirable).
>
> The
On 16/11/2020 21:07, Marc Zyngier wrote:
> Removing the meson-dw-hdmi module results in the following splat:
>
> i[ 43.340509] WARNING: CPU: 0 PID: 572 at drivers/regulator/core.c:2125
> _regulator_put.part.0+0x16c/0x174
> [...]
> [ 43.454870] CPU: 0 PID: 572 Comm: modprobe Tainted: G
On 16/11/2020 21:07, Marc Zyngier wrote:
> Removing the meson DRM module results in the following splats:
>
> [ 42.689228] WARNING: CPU: 0 PID: 572 at drivers/gpu/drm/drm_irq.c:192
> drm_irq_uninstall+0x130/0x160 [drm]
> [...]
> [ 42.812820] Hardware name: , BIOS 2021.01-rc2-00012-gde865f7ee
1 - 100 of 124 matches
Mail list logo