From: Dave Airlie
This fixes a bug introduced in be1213a341a289afc51f89181c310e368fba0b66
drm/ttm: remove TTM_MEMTYPE_FLAG_FIXED v2
On vmwgfx this causes a Command buffer error WARN to trigger.
This is because the old code used to check if bo->ttm was true,
and the new code doesn't, fix it
On Thu, 24 Sep 2020 at 15:20, Dave Airlie wrote:
>
> From: Dave Airlie
>
> Don't use explicit move notify for moves just do it in the driver side.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 62
> 1 file changed, 44 insertions(+),
On Thu, 24 Sep 2020 at 15:19, Dave Airlie wrote:
>
> This refactors how TTM moves get called between core and drivers.
>
> 1) puts the driver in charge of all moves, and enforces
> drivers have a move callback.
> 2) moves move_notify actions around moves to the driver side
> 3) moves
On 29. 09. 20, 14:34, Peilin Ye wrote:
> the work in general? I couldn't think of how do we clean up subsystems
> one by one, while keeping a `console_font` in `struct vc_data`.
Hi,
feel free to change struct vc_data's content as you need, of course.
Only the UAPI _definitions_ have to be
On Wed, Sep 30, 2020 at 06:03:03AM +0200, Roland Scheidegger (VMware) wrote:
> Sigend-off-by: Roland Scheidegger
^^^
typo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Dave, Daniel
One important fix for recent breakage.
The following changes since commit a1b8638ba1320e6684aa98233c15255eb803fac7:
Linux 5.9-rc7 (2020-09-27 14:38:10 -0700)
are available in the Git repository at:
git://people.freedesktop.org/~sroland/linux vmwgfx-fixes-5.9
for you to fetch
From: Zack Rusin
ttm_mem_type_manager_func.get_node was changed to return -ENOSPC
instead of setting the node pointer to NULL. Unfortunately
vmwgfx still had two places where it was explicitly converting
-ENOSPC to 0 causing regressions. This fixes those spots by
allowing -ENOSPC to be returned.
On Wed, 30 Sep 2020 at 12:17, Zack Rusin wrote:
>
>
> > On Sep 29, 2020, at 22:07, Dave Airlie wrote:
> >
> > From: Dave Airlie
> >
> > This seems to fix the failure I'm seeing with 5.9-rc7 under
> > vmplayer.
> >
> > Signed-off-by: Dave Airlie
> > ---
> > drivers/gpu/drm/vmwgfx/vmwgfx_thp.c |
> On Sep 29, 2020, at 22:07, Dave Airlie wrote:
>
> From: Dave Airlie
>
> This seems to fix the failure I'm seeing with 5.9-rc7 under
> vmplayer.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Wed, 30 Sep 2020 at 11:09, Dave Airlie wrote:
>
> Hey Roland (et al),
>
> I took the opportunity to boot vmwgfx from Linus 5.9-rc7 on VMware
> Player 15.5.6.build.16341506.
>
> Pretty much stock fedora 32 userspace, all updates as of today.
>
> It isn't pretty, can someone look into this
From: Dave Airlie
This seems to fix the failure I'm seeing with 5.9-rc7 under
vmplayer.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
On (20/09/29 17:09), Peter Zijlstra wrote:
> > 2. The registration and unregistration of consoles should not longer
> >be handled by console_lock (semaphore). It should be possible to
> >call most consoles without a sleeping lock. It should remove all
> >these deadlocks between
On Wed, 30 Sep 2020 at 00:52, Daniel Vetter wrote:
>
> On Thu, Sep 17, 2020 at 3:15 PM Daniel Vetter wrote:
> >
> > Ben, did you have a chance to look at this?
>
> Ping
> -Daniel
>
> > On Mon, Aug 3, 2020 at 1:22 PM Maarten Lankhorst
> > wrote:
> > >
> > > Op 02-08-2020 om 20:18 schreef Daniel
On Wed, Sep 30, 2020 at 12:59:58AM +0300, Ville Syrjälä wrote:
> On Wed, Sep 30, 2020 at 12:11:48AM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 29, 2020 at 02:01:44PM -0700, Matt Roper wrote:
> > > On Tue, Sep 29, 2020 at 11:30:22PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Sep 29, 2020 at
Hi,
On Thu, Sep 24, 2020 at 01:23:31PM +0100, Lee Jones wrote:
> On Thu, 24 Sep 2020, Krzysztof Kozlowski wrote:
>
> > On Wed, 23 Sep 2020 at 22:01, Jonathan Cameron wrote:
> > >
> > > On Wed, 23 Sep 2020 11:53:33 -0500
> > > Dan Murphy wrote:
> > >
> > > > Hello
> > > >
> > > > On 9/22/20
While I thought I had this correct (since it actually did reject modes
like I expected during testing), Ville Syrjala from Intel pointed out
that the logic here isn't correct. max_clock refers to the max data rate
supported by the DP encoder. So, limiting it to the output of ds_clock (which
refers
Ville also pointed out that I got a lot of the logic here wrong as well, whoops.
While I don't think anyone's likely using 3D output with nouveau, the next patch
will make nouveau_conn_mode_valid() make a lot less sense. So, let's just get
rid of it and open-code it like before, while taking care
On Wed, Sep 30, 2020 at 12:11:48AM +0300, Ville Syrjälä wrote:
> On Tue, Sep 29, 2020 at 02:01:44PM -0700, Matt Roper wrote:
> > On Tue, Sep 29, 2020 at 11:30:22PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 29, 2020 at 08:20:22PM +, Souza, Jose wrote:
> > > > On Tue, 2020-09-29 at 23:02
On Tue, Sep 29, 2020 at 2:33 AM Gerd Hoffmann wrote:
> On Wed, Sep 23, 2020 at 05:31:56PM -0700, Gurchetan Singh wrote:
> > Useful for upcoming blob resources.
>
> Pushed to drm-misc-next (whole series).
>
Thanks -- sent over a 32-bit/64-bit bug fix and requested a virtio-spec
vote.
>
>
From: Alistair Delva
We encountered this issue when booting blob with a 32-bit kernel.
The implementation doesn't match v6 of the virtio-spec change, so fix
this.
Fixes: ff886cbdcc44 ("virtio-gpu api: blob resources")
Signed-off-by: Alistair Delva
---
include/uapi/linux/virtio_gpu.h | 2 +-
1
On Tue, Sep 29, 2020 at 02:01:44PM -0700, Matt Roper wrote:
> On Tue, Sep 29, 2020 at 11:30:22PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 29, 2020 at 08:20:22PM +, Souza, Jose wrote:
> > > On Tue, 2020-09-29 at 23:02 +0300, Ville Syrjälä wrote:
> > > > On Tue, Sep 29, 2020 at 07:33:45PM
On Tue, Sep 29, 2020 at 11:30:22PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 29, 2020 at 08:20:22PM +, Souza, Jose wrote:
> > On Tue, 2020-09-29 at 23:02 +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 29, 2020 at 07:33:45PM +, Souza, Jose wrote:
> > > > On Tue, 2020-09-29 at 17:41 +0530,
On Tue, 2020-09-29 at 23:30 +0300, Ville Syrjälä wrote:
> On Tue, Sep 29, 2020 at 08:20:22PM +, Souza, Jose wrote:
> > On Tue, 2020-09-29 at 23:02 +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 29, 2020 at 07:33:45PM +, Souza, Jose wrote:
> > > > On Tue, 2020-09-29 at 17:41 +0530, Tejas
On Tue, Sep 29, 2020 at 9:53 PM Peter Collingbourne wrote:
> The fbdev driver is used by Android's FVP configuration. Using the
> DRM driver together with DRM's fbdev emulation results in a failure
> to boot Android. The root cause is that Android's generic fbdev
> userspace driver relies on the
On Tue, Sep 29, 2020 at 08:20:22PM +, Souza, Jose wrote:
> On Tue, 2020-09-29 at 23:02 +0300, Ville Syrjälä wrote:
> > On Tue, Sep 29, 2020 at 07:33:45PM +, Souza, Jose wrote:
> > > On Tue, 2020-09-29 at 17:41 +0530, Tejas Upadhyay wrote:
> > > > JSL has update in vswing table for eDP
> >
On Tue, Sep 29, 2020 at 8:44 PM Daniel Vetter wrote:
> On Tue, Sep 29, 2020 at 7:49 PM Peter Collingbourne wrote:
> But aside from all this, why is this blocking the migration from fbdev
> to drm? With fbdev you don't have buffer allocations, nor dma-buf
> support, and somehow android can boot.
On Tue, 2020-09-29 at 23:02 +0300, Ville Syrjälä wrote:
> On Tue, Sep 29, 2020 at 07:33:45PM +, Souza, Jose wrote:
> > On Tue, 2020-09-29 at 17:41 +0530, Tejas Upadhyay wrote:
> > > JSL has update in vswing table for eDP
> >
> > Would be nice to mention in the commit description why PCH is
On Mon, 28 Sep 2020 12:30:54 -0500, Alexandru Gagniuc wrote:
> The sii902x chip family requires IO and core voltages to reach the
> correct voltage before chip initialization. Add binding for describing
> the two supplies.
>
> Signed-off-by: Alexandru Gagniuc
> ---
> Changes since v1:
> *
On Tue, Sep 29, 2020 at 8:31 AM Jan Kiszka wrote:
>
> On 10.09.20 20:18, Deucher, Alexander wrote:
> > [AMD Public Use]
> >
> >
> >
> >> -Original Message-
> >> From: amd-gfx On Behalf Of
> >> Daniel Vetter
> >> Sent: Monday, September 7, 2020 3:15 AM
> >> To: Jan Kiszka ; amd-gfx list
On Tue, Sep 29, 2020 at 07:33:45PM +, Souza, Jose wrote:
> On Tue, 2020-09-29 at 17:41 +0530, Tejas Upadhyay wrote:
> > JSL has update in vswing table for eDP
>
> Would be nice to mention in the commit description why PCH is being used,
> that would avoid Ville's question.
If the thing has
On Tue, 2020-09-29 at 17:41 +0530, Tejas Upadhyay wrote:
> JSL has update in vswing table for eDP
Would be nice to mention in the commit description why PCH is being used, that
would avoid Ville's question.
>
> BSpec: 21257
>
> Changes since V1 :
> - IS_ELKHARTLAKE and IS_JASPERLAKE is
On Fri, Sep 25, 2020 at 03:07:43PM +0200, Maxime Ripard wrote:
> There's cross-talk on the RPi4 between the 2.4GHz channels used by the WiFi
> chip and some resolutions, most notably 1440p at 60Hz.
>
> In such a case, we can either reject entirely the mode, or lower slightly
> the pixel frequency
On Wed, 23 Sep 2020 17:03:39 +0200, Krzysztof Kozlowski wrote:
> Add common properties appearing in DTSes (iommus, power-domains) to fix
> dtbs_check warnings like:
>
> arch/arm/boot/dts/exynos4210-i9100.dt.yaml: rotator@1281:
> 'iommus', 'power-domains' do not match any of the regexes:
On Tue, Sep 29, 2020 at 7:49 PM Peter Collingbourne wrote:
>
> On Tue, Sep 29, 2020 at 9:52 AM Daniel Vetter wrote:
> >
> > On Tue, Sep 29, 2020 at 06:48:28PM +0200, Daniel Vetter wrote:
> > > On Tue, Sep 29, 2020 at 09:30:08AM -0700, Peter Collingbourne wrote:
> > > > On Tue, Sep 29, 2020 at
On Tue, Sep 29, 2020 at 7:49 PM Peter Collingbourne wrote:
>
> On Tue, Sep 29, 2020 at 9:52 AM Daniel Vetter wrote:
> >
> > On Tue, Sep 29, 2020 at 06:48:28PM +0200, Daniel Vetter wrote:
> > > On Tue, Sep 29, 2020 at 09:30:08AM -0700, Peter Collingbourne wrote:
> > > > On Tue, Sep 29, 2020 at
On Tue, 2020-09-29 at 21:09 +0300, Ville Syrjälä wrote:
> On Tue, Sep 29, 2020 at 01:54:13PM -0400, Lyude Paul wrote:
> > On Mon, 2020-09-28 at 16:01 +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 22, 2020 at 05:05:10PM -0400, Lyude Paul wrote:
> > > > While I thought I had this correct (since it
On Tue, Sep 29, 2020 at 01:54:13PM -0400, Lyude Paul wrote:
> On Mon, 2020-09-28 at 16:01 +0300, Ville Syrjälä wrote:
> > On Tue, Sep 22, 2020 at 05:05:10PM -0400, Lyude Paul wrote:
> > > While I thought I had this correct (since it actually did reject modes
> > > like I expected during testing),
On Tue, Sep 22, 2020 at 03:55:05PM +0800, Chunfeng Yun wrote:
> Convert phy-mtk-xsphy.txt to YAML schema mediatek,xsphy.yaml
>
> Signed-off-by: Chunfeng Yun
> ---
> .../bindings/phy/mediatek,xsphy.yaml | 203 ++
> .../devicetree/bindings/phy/phy-mtk-xsphy.txt | 109
On Mon, 2020-09-28 at 16:01 +0300, Ville Syrjälä wrote:
> On Tue, Sep 22, 2020 at 05:05:10PM -0400, Lyude Paul wrote:
> > While I thought I had this correct (since it actually did reject modes
> > like I expected during testing), Ville Syrjala from Intel pointed out
> > that the logic here isn't
https://bugzilla.kernel.org/show_bug.cgi?id=209417
--- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) ---
yeah, if it was working with 5.7.0 and not working with 5.8.0, you can just do
a bit bisect on
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ between the
v5.7 and
Hi Christian
Am 29.09.20 um 17:35 schrieb Christian König:
> Am 29.09.20 um 17:14 schrieb Thomas Zimmermann:
>> The new helper ttm_kmap_obj_to_dma_buf() extracts address and location
>> from and instance of TTM's kmap_obj and initializes struct dma_buf_map
>> with these values. Helpful for
On Fri, 2020-09-25 at 19:53 -0400, Ilia Mirkin wrote:
> On Fri, Sep 25, 2020 at 6:08 PM Lyude Paul wrote:
> > On Tue, 2020-09-22 at 17:22 -0400, Ilia Mirkin wrote:
> > > On Tue, Sep 22, 2020 at 5:14 PM Lyude Paul wrote:
> > > > On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote:
> > > > > Can
On Thu, Sep 24, 2020 at 09:38:07PM +0200, Sam Ravnborg wrote:
> Hi Guido.
>
> On Mon, Sep 21, 2020 at 06:55:52PM +0200, Guido Günther wrote:
> > We need to reset both for the panel to show an image.
> >
> > Signed-off-by: Guido Günther
> > ---
> >
https://bugzilla.kernel.org/show_bug.cgi?id=209417
--- Comment #3 from Juan (juantxor...@gmail.com) ---
(In reply to Alex Deucher from comment #2)
> Can you bisect?
I never did it but I'm happy to help. It will take a while for me to do it,
though. Any guidance would be appreciated.
I assume
On Tue, Sep 29, 2020 at 06:56:57PM +0200, Daniel Vetter wrote:
> On Tue, Sep 29, 2020 at 12:52:03PM +0200, Martin Hostettler wrote:
> > On Tue, Sep 29, 2020 at 10:12:46AM +0900, Tetsuo Handa wrote:
> > > On 2020/09/29 2:59, Martin Hostettler wrote:
> > > > On Sun, Sep 27, 2020 at 08:46:30PM +0900,
On Tue, Sep 29, 2020 at 12:52:03PM +0200, Martin Hostettler wrote:
> On Tue, Sep 29, 2020 at 10:12:46AM +0900, Tetsuo Handa wrote:
> > On 2020/09/29 2:59, Martin Hostettler wrote:
> > > On Sun, Sep 27, 2020 at 08:46:30PM +0900, Tetsuo Handa wrote:
> > >> VT_RESIZEX was introduced in Linux 1.3.3,
On Tue, Sep 29, 2020 at 12:51:24PM -0300, Melissa Wen wrote:
> On 09/29, Daniel Vetter wrote:
> > - debugfs cleanup has moved forward thanks to the cleanup Wambui has
> > done
> >
> > Cc: Wambui Karuga
> > Cc: Greg Kroah-Hartman
> > Cc: Melissa Wen
> > Signed-off-by: Daniel Vetter
> > ---
>
On Tue, Sep 29, 2020 at 06:48:28PM +0200, Daniel Vetter wrote:
> On Tue, Sep 29, 2020 at 09:30:08AM -0700, Peter Collingbourne wrote:
> > On Tue, Sep 29, 2020 at 2:32 AM Daniel Vetter wrote:
> > >
> > > On Tue, Sep 29, 2020 at 09:28:56AM +0200, Neil Armstrong wrote:
> > > > Hi,
> > > >
> > > > On
On Tue, Sep 29, 2020 at 09:30:08AM -0700, Peter Collingbourne wrote:
> On Tue, Sep 29, 2020 at 2:32 AM Daniel Vetter wrote:
> >
> > On Tue, Sep 29, 2020 at 09:28:56AM +0200, Neil Armstrong wrote:
> > > Hi,
> > >
> > > On 28/09/2020 22:08, Peter Collingbourne wrote:
> > > > Also revert the
On Tue, Sep 29, 2020 at 05:03:33PM +0200, Daniel Vetter wrote:
> - debugfs cleanup has moved forward thanks to the cleanup Wambui has
> done
>
> Cc: Wambui Karuga
> Cc: Greg Kroah-Hartman
> Cc: Melissa Wen
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/todo.rst | 3 ---
> 1 file
On 09/29, Daniel Vetter wrote:
> - debugfs cleanup has moved forward thanks to the cleanup Wambui has
> done
>
> Cc: Wambui Karuga
> Cc: Greg Kroah-Hartman
> Cc: Melissa Wen
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/todo.rst | 3 ---
> 1 file changed, 3 deletions(-)
>
>
Hi,
On Fri, 25 Sep 2020 at 09:46, Daniel Vetter wrote:
> Hopefully we'll have the drm crash recorder RSN, but meanwhile
> compositors would like to know a bit better why they get an EBUSY.
Thanks a lot, this is super helpful! Both patches are:
Reviewed-by: Daniel Stone
Cheers,
Daniel
On Tue, Sep 29, 2020 at 5:35 PM Christian König
wrote:
>
> Am 29.09.20 um 17:14 schrieb Thomas Zimmermann:
> > The new helper ttm_kmap_obj_to_dma_buf() extracts address and location
> > from and instance of TTM's kmap_obj and initializes struct dma_buf_map
> > with these values. Helpful for
Am 29.09.20 um 17:14 schrieb Thomas Zimmermann:
The new helper ttm_kmap_obj_to_dma_buf() extracts address and location
from and instance of TTM's kmap_obj and initializes struct dma_buf_map
with these values. Helpful for TTM-based drivers.
We could completely drop that if we use the same
At least sparc64 requires I/O-specific access to framebuffers. This
patch updates the fbdev console accordingly.
For drivers with direct access to the framebuffer memory, the callback
functions in struct fb_ops test for the type of memory and call the rsp
fb_sys_ of fb_cfb_ functions.
For
GEM's vmap and vunmap interfaces now wrap memory pointers in struct
dma_buf_map.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_client.c | 18 +++---
drivers/gpu/drm/drm_gem.c | 28 ++--
drivers/gpu/drm/drm_internal.h | 5 +++--
This patch replaces the vmap/vunmap's use of raw pointers in GEM object
functions with instances of struct dma_buf_map. GEM backends are
converted as well.
For most GEM backends, this simply change the returned type. GEM VRAM
helpers are also updated to indicate whether the returned framebuffer
The new helper ttm_kmap_obj_to_dma_buf() extracts address and location
from and instance of TTM's kmap_obj and initializes struct dma_buf_map
with these values. Helpful for TTM-based drivers.
Signed-off-by: Thomas Zimmermann
---
include/drm/ttm/ttm_bo_api.h | 24
DRM's fbdev console uses regular load and store operations to update
framebuffer memory. The bochs driver on sparc64 requires the use of
I/O-specific load and store operations. We have a workaround, but need
a long-term solution to the problem.
This patchset changes GEM's vmap/vunmap interfaces
The parameters map and is_iomem are always of the same value. Removed them
to prepares the function for conversion to struct dma_buf_map.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff
Instances of struct dma_buf_map should be useful throughout DRM's
memory management code. Furthermore, several drivers can now use
generic fbdev emulation.
Signed-off-by: Thomas Zimmermann
---
Documentation/gpu/todo.rst | 24 ++--
1 file changed, 22 insertions(+), 2
Kernel DRM clients now store their framebuffer address in an instance
of struct dma_buf_map. Depending on the buffer's location, the address
refers to system or I/O memory.
Callers of drm_client_buffer_vmap() receive a copy of the value in
the call's supplied arguments. It can be accessed and
On Tue, Sep 29, 2020 at 04:27:51PM +0200, Petr Mladek wrote:
> Upstreaming the console handling will be the next big step. I am sure
> that there will be long discussion about it. But there might be
> few things that would help removing printk_deferred().
>
> 1. Messages will be printed on
- debugfs cleanup has moved forward thanks to the cleanup Wambui has
done
Cc: Wambui Karuga
Cc: Greg Kroah-Hartman
Cc: Melissa Wen
Signed-off-by: Daniel Vetter
---
Documentation/gpu/todo.rst | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/gpu/todo.rst
On Tue, Sep 29, 2020 at 1:55 AM Michal Simek wrote:
>
> Hi Rob,
>
> On 28. 09. 20 17:59, Rob Herring wrote:
> > The default sizes in examples for 'reg' are 1 cell each. Fix the
> > incorrect sizes in zynqmp examples:
> >
> >
On Thu, Sep 17, 2020 at 3:15 PM Daniel Vetter wrote:
>
> Ben, did you have a chance to look at this?
Ping
-Daniel
> On Mon, Aug 3, 2020 at 1:22 PM Maarten Lankhorst
> wrote:
> >
> > Op 02-08-2020 om 20:18 schreef Daniel Vetter:
> > > Purely conjecture, but I think the original locking
On Tue, Sep 29, 2020 at 2:34 PM Peilin Ye wrote:
>
> On Fri, Sep 25, 2020 at 03:25:51PM +0200, Daniel Vetter wrote:
> > I think the only way to make this work is that we have one place which
> > takes in the userspace uapi struct, and then converts it once into a
> > kernel_console_font. With all
https://bugzilla.kernel.org/show_bug.cgi?id=209417
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
On 20/09/2020 19:59, Jyri Sarha wrote:
> We already have a private data member for maximum display width so
> let's use it and get rid of the redundant tilcdc_crtc_max_width().
>
> The LCDC version probing is moved to before reading the device tree
> properties so that the version information is
On x64 we get:
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:751:10: warning: conversion
from 'long unsigned int' to 'unsigned int' changes value from
'18446744073709551613' to '4294967293' [-Woverflow]
The registers are 32 bit, so fix by casting to u32.
Fixes: fb43aa0acdfd ("drm:
-Original Message-
From: Ville Syrjälä
Sent: 29 September 2020 18:23
To: Surendrakumar Upadhyay, TejaskumarX
Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Ausmus,
James ; Roper, Matthew D ;
Souza, Jose ; De Marchi, Lucas
; Pandey, Hariom
Subject: Re:
On Tue, Sep 29, 2020 at 05:41:27PM +0530, Tejas Upadhyay wrote:
> JSL has update in vswing table for eDP
>
> BSpec: 21257
>
> Changes since V1 :
> - IS_ELKHARTLAKE and IS_JASPERLAKE is replaced with
> HAS_PCH_MCC(EHL) and HAS_PCH_JSP(JSL) respectively
What do vswing values have
On Mon, Sep 28, 2020 at 08:20:59PM +0300, Jani Nikula wrote:
> On Mon, 28 Sep 2020, Ville Syrjälä wrote:
> > On Mon, Sep 28, 2020 at 07:15:43AM -0700, James Ausmus wrote:
> >> On Mon, Sep 28, 2020 at 04:43:11PM +0300, Jani Nikula wrote:
> >> > On Mon, 28 Sep 2020, Tejas Upadhyay
> >> > wrote:
>
Quoting Christoph Hellwig (2020-09-28 15:37:41)
> On Mon, Sep 28, 2020 at 01:13:38PM +0300, Joonas Lahtinen wrote:
> > I think we have a gap that after splitting the drm-intel-next pull requests
> > into
> > two the drm-intel/for-linux-next branch is now missing material from
> >
JSL has update in vswing table for eDP
BSpec: 21257
Changes since V1 :
- IS_ELKHARTLAKE and IS_JASPERLAKE is replaced with
HAS_PCH_MCC(EHL) and HAS_PCH_JSP(JSL) respectively
- Reverted EHL/JSL PCI ids split change
Signed-off-by: Tejas Upadhyay
---
On Tue, Sep 29, 2020 at 01:23:06PM +0200, Christian König wrote:
> We need to use ttm_bo_init_reserved here to make sure
> that the BO is pinned before it becomes visible on the LRU.
>
> Signed-off-by: Christian König
Reviewed-by: Gerd Hoffmann #
Tested-by: Gerd Hoffmann #
From: Wen Yang
[ Upstream commit 47340e46f34a3b1d80e40b43ae3d7a8da34a3541 ]
The call to of_find_matching_node returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
On Tue, Sep 29, 2020 at 01:23:06PM +0200, Christian König wrote:
> We need to use ttm_bo_init_reserved here to make sure
> that the BO is pinned before it becomes visible on the LRU.
>
> Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
But maybe let Gerd test this first before
On Tue, Sep 29, 2020 at 11:39:21AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 29.09.20 um 11:19 schrieb Daniel Vetter:
> > On Mon, Sep 28, 2020 at 11:13:06AM +0200, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 28.09.20 um 10:53 schrieb Daniel Vetter:
> >>> On Mon, Sep 28, 2020 at 9:22 AM Thomas
From: Wen Yang
[ Upstream commit 47340e46f34a3b1d80e40b43ae3d7a8da34a3541 ]
The call to of_find_matching_node returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
Am 29.09.20 um 12:53 schrieb Daniel Vetter:
On Tue, Sep 29, 2020 at 11:51:15AM +0200, Gerd Hoffmann wrote:
Otherwise ttm throws a WARN because we try to pin without a reservation.
Fixes: 9d36d4320462 ("drm/qxl: switch over to the new pin interface")
Signed-off-by: Gerd Hoffmann
---
We need to use ttm_bo_init_reserved here to make sure
that the BO is pinned before it becomes visible on the LRU.
Signed-off-by: Christian König
---
drivers/gpu/drm/qxl/qxl_object.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_object.c
From: Wen Yang
[ Upstream commit 47340e46f34a3b1d80e40b43ae3d7a8da34a3541 ]
The call to of_find_matching_node returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
Also revert the follow-up change "drm: pl111: Absorb the external
register header".
This reverts commits 7e4e589db76a3cf4c1f534eb5a09cc6422766b93
and 0fb8125635e8eb5483fb095f98dcf0651206a7b8.
The fbdev driver is used by Android's FVP configuration. Using the
DRM driver together with DRM's fbdev
From: Wen Yang
[ Upstream commit 47340e46f34a3b1d80e40b43ae3d7a8da34a3541 ]
The call to of_find_matching_node returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
Am 29.09.20 um 13:09 schrieb Christian König:
> Am 29.09.20 um 11:14 schrieb Daniel Vetter:
>> On Mon, Sep 28, 2020 at 01:22:13PM +0200, Christian König wrote:
>>> Am 28.09.20 um 09:37 schrieb Thomas Zimmermann:
Hi
Am 28.09.20 um 08:50 schrieb Christian König:
> Am 27.09.20 um
Am 29.09.20 um 11:14 schrieb Daniel Vetter:
On Mon, Sep 28, 2020 at 01:22:13PM +0200, Christian König wrote:
Am 28.09.20 um 09:37 schrieb Thomas Zimmermann:
Hi
Am 28.09.20 um 08:50 schrieb Christian König:
Am 27.09.20 um 21:16 schrieb Sam Ravnborg:
Hi Thomas.
struct simap {
From: Wen Yang
[ Upstream commit 47340e46f34a3b1d80e40b43ae3d7a8da34a3541 ]
The call to of_find_matching_node returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
On Tue, Sep 29, 2020 at 11:51:15AM +0200, Gerd Hoffmann wrote:
> Otherwise ttm throws a WARN because we try to pin without a reservation.
>
> Fixes: 9d36d4320462 ("drm/qxl: switch over to the new pin interface")
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/qxl/qxl_object.c | 2 +-
> 1
Otherwise ttm throws a WARN because we try to pin without a reservation.
Fixes: 9d36d4320462 ("drm/qxl: switch over to the new pin interface")
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_object.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
In case we have a shadow surface on shutdown release
it so it doesn't leak.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index
qxl_primary_atomic_disable must check whenever the framebuffer bo has a
shadow surface and in case it has check the shadow primary status.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/qxl/qxl_display.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 65de1f69af58..5bef8f121e54 100644
---
v2: repost, add a pin fix.
Gerd Hoffmann (4):
drm/qxl: use drmm_mode_config_init
drm/qxl: release shadow on shutdown
drm/qxl: handle shadow in primary destroy
drm/qxl: use qxl pin function
drivers/gpu/drm/qxl/qxl_display.c | 11 +--
drivers/gpu/drm/qxl/qxl_object.c | 2 +-
2
On 9/28/2020 5:48 PM, Ville Syrjälä wrote:
On Mon, Sep 21, 2020 at 04:32:02PM +0530, Karthik B S wrote:
Without async flip support in the kernel, fullscreen apps where game
resolution is equal to the screen resolution, must perform an extra blit
per frame prior to flipping.
Asynchronous page
Hi
Am 29.09.20 um 11:19 schrieb Daniel Vetter:
> On Mon, Sep 28, 2020 at 11:13:06AM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 28.09.20 um 10:53 schrieb Daniel Vetter:
>>> On Mon, Sep 28, 2020 at 9:22 AM Thomas Zimmermann
>>> wrote:
Hi
Am 26.09.20 um 18:42 schrieb Daniel
On Wed, Sep 23, 2020 at 05:31:56PM -0700, Gurchetan Singh wrote:
> Useful for upcoming blob resources.
Pushed to drm-misc-next (whole series).
thanks,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Mon, Sep 21, 2020 at 09:10:22PM +0800, Qinglang Miao wrote:
> Simplify the return expression.
Pushed to drm-misc-next.
thanks,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Tue, Sep 29, 2020 at 09:28:56AM +0200, Neil Armstrong wrote:
> Hi,
>
> On 28/09/2020 22:08, Peter Collingbourne wrote:
> > Also revert the follow-up change "drm: pl111: Absorb the external
> > register header".
> >
> > This reverts commits 7e4e589db76a3cf4c1f534eb5a09cc6422766b93
> > and
Hi Sam,
Is there anything more to change ?
Thanks,
Neil
On 15/09/2020 14:19, Neil Armstrong wrote:
> This adds support bindings and support for the TDO TL070WSH30 TFT-LCD panel
> module shipped with the Amlogic S400 Development Kit.
> The panel has a 1024×600 resolution and uses 24 bit RGB per
1 - 100 of 151 matches
Mail list logo
