Hi, Pi-Hsun:
On Mon, 2019-11-18 at 14:18 +0800, Pi-Hsun Shih wrote:
> The mtk_drm_ddp_comp_for_plane can return NULL, but the usage doesn't
> check for it. Add check for it.
Reviewed-by: CK Hu
>
> Fixes: d6b53f68356f ("drm/mediatek: Add helper to get component for a plane")
> Signed-off-by: Pi
Hi, Daniel:
On Fri, 2019-11-15 at 10:21 +0100, Daniel Vetter wrote:
> Aside: There's a few other fb_create implementations which
> simply check for valid buffer format (or an approximation thereof),
> and then call drm_gem_fb_create. For atomic drivers at least we could
> walk all planes and make
The i index i always 0..3 in these statements so there
is no need to tag "& 3" to clamp it to 3 here. Make
the operator precedence explicit even if it's correct
as it is, the paranthesis creates less cognitive stress
for humans.
Cc: Stephan Gerhold
Signed-off-by: Linus Walleij
---
drivers/gpu/d
The MCDE DSI include file redefines some commands that
already exist in the common header.
Cc: Stephan Gerhold
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/mcde/mcde_dsi.c | 2 +-
drivers/gpu/drm/mcde/mcde_dsi_regs.h | 11 ---
2 files changed, 1 insertion(+), 12 deletions(-)
Hi Navid,
On 19-11-21 12:31, Navid Emamdoost wrote:
> On Fri, Oct 4, 2019 at 2:09 PM Navid Emamdoost
> wrote:
> >
> > In imx_pd_bind, the duplicated memory for imxpd->edid via kmemdup should
> > be released in drm_of_find_panel_or_bridge or imx_pd_register fail.
> >
> > Fixes: ebc944613567 ("drm:
https://bugs.freedesktop.org/show_bug.cgi?id=110605
NAGENDRA changed:
What|Removed |Added
Alias||NAGENDRA
--
You are receiving this mail bec
The fake offset is going to stay, so change the calling convention for
drm_gem_object_funcs.mmap to include the fake offset. Update all users
accordingly.
Note that this reverts 83b8a6f242ea ("drm/gem: Fix mmap fake offset
handling for drm_gem_object_funcs.mmap") and on top then adds the fake
off
Use the shared address space of the drm device (see drm_open() in
drm_file.c) for dma-bufs too. That removes a difference betweem drm
device mmap vmas and dma-buf mmap vmas and fixes corner cases like
dropping ptes (using madvise(DONTNEED) for example) not working
properly.
Also remove amdgpu dri
Tested on qemu, with bochs (vram helpers) and cirrus (shmem helpers).
Cc'ing intel-gfx for CI coverage.
Gerd Hoffmann (2):
drm: call drm_gem_object_funcs.mmap with fake offset
drm: share address space for dma bufs
include/drm/drm_gem.h | 4 +---
drivers/gpu/drm/amd/amdg
On Thu, Nov 21, 2019 at 04:42:10PM +, Ruhl, Michael J wrote:
> >-Original Message-
> >From: Intel-gfx On Behalf Of Gerd
> >Hoffmann
> >Sent: Thursday, November 21, 2019 5:38 AM
> >To: dri-devel@lists.freedesktop.org
> >Cc: David Airlie ; intel-...@lists.freedesktop.org; open
> >list
>
From: Lucas Stach
[ Upstream commit eb0200a4357da100064971689d3a0e9e3cf57f33 ]
On a NOP double buffer update where current buffer address is the same
as the next buffer address, the SDW_UPDATE bit clears too late. As we
are now using this bit to determine when it is safe to signal flip
completio
From: Lucas Stach
[ Upstream commit eb0200a4357da100064971689d3a0e9e3cf57f33 ]
On a NOP double buffer update where current buffer address is the same
as the next buffer address, the SDW_UPDATE bit clears too late. As we
are now using this bit to determine when it is safe to signal flip
completio
On 11/21/19 1:54 AM, Jan Kara wrote:
On Thu 21-11-19 00:29:59, John Hubbard wrote:
Otherwise this looks fine and might be a worthwhile cleanup to feed
Andrew for 5.5 independent of the gut of the changes.
Reviewed-by: Christoph Hellwig
Thanks for the reviews! Say, it sounds like your view
On Thu, Nov 21, 2019 at 07:26:05AM +, Chris Wilson wrote:
> Quoting kernel test robot (2019-11-21 07:19:43)
> > Greetings,
> >
> > 0day kernel testing robot got the below dmesg and the first bad commit is
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> >
>
On Thu, 2019-11-21 at 10:28 +0100, Daniel Vetter wrote:
> On Thu, Nov 21, 2019 at 9:26 AM Timo Aaltonen
> wrote:
> > On 9.10.2019 18.50, Daniel Vetter wrote:
> > > On Thu, Oct 03, 2019 at 11:31:25AM -0700, Juston Li wrote:
> > > > From: Daniel Stone
> > > >
> > > > getfb2 allows us to pass multi
Hey Linus,
Two sets of fixes in here, one for amdgpu, and one for i915. The
amdgpu ones are pretty small, i915's CI system seems to have a few
problems in the last week or so, there is one major regression fix for
fb_mmap, but there are a bunch of other issues fixed in there as well,
oops, screen
Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device
states.
v2: convert to pci_dev quirk
put a proper technical explanation of the issue as a in-code comment
v3: disable it only for certain combinations of intel and nvidia hardware
v4: simplify quirk by setting flag on
so while trying to test with d3cold disabled, I noticed that I run
into the exact same error. And I verified that the
\_SB.PCI0.PEG0.PG00._STA returns 1, which indicates it should still be
turned on.
On Thu, Nov 21, 2019 at 11:50 PM Karol Herbst wrote:
>
> On Thu, Nov 21, 2019 at 11:39 PM Rafael
On Thu, Nov 21, 2019 at 11:39 PM Rafael J. Wysocki wrote:
>
> On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg
> wrote:
> >
> > On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Thu, Nov 21, 201
On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg
wrote:
>
> On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg
> > wrote:
> > >
> > > On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg wrote:
> > > > On Thu, Nov 21, 2019 at
On 11/21/19 8:59 AM, Dan Williams wrote:
On Thu, Nov 21, 2019 at 12:57 AM John Hubbard wrote:
On 11/21/19 12:05 AM, Christoph Hellwig wrote:
So while this looks correct and I still really don't see the major
benefit of the new code organization, especially as it bloats all
put_page callers.
On 11/21/19 1:35 PM, Alex Williamson wrote:
On Wed, 20 Nov 2019 23:13:39 -0800
John Hubbard wrote:
As it says in the updated comment in gup.c: current FOLL_LONGTERM
behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
FS DAX check requirement on vmas.
However, the corresponding
On 11/21/19 1:49 AM, Jan Kara wrote:
On Thu 21-11-19 00:29:59, John Hubbard wrote:
On 11/21/19 12:03 AM, Christoph Hellwig wrote:
Otherwise this looks fine and might be a worthwhile cleanup to feed
Andrew for 5.5 independent of the gut of the changes.
Reviewed-by: Christoph Hellwig
Thanks
On Wed, 20 Nov 2019 23:13:39 -0800
John Hubbard wrote:
> As it says in the updated comment in gup.c: current FOLL_LONGTERM
> behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
> FS DAX check requirement on vmas.
>
> However, the corresponding restriction in get_user_pages_remote
On Fri, Nov 1, 2019 at 4:37 PM Rob Herring wrote:
>
> Add missing docbook comments to madvise fields in struct
> drm_gem_shmem_object which fixes these warnings:
>
> include/drm/drm_gem_shmem_helper.h:87: warning: Function parameter or member
> 'madv' not described in 'drm_gem_shmem_object'
> inc
On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. Wysocki wrote:
> On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg
> wrote:
> >
> > On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg wrote:
> > > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> > > > On Thu, Nov 21, 20
On Thu, 21 Nov 2019 at 20:21, james qian wang (Arm Technology China)
wrote:
>
> On Thu, Nov 21, 2019 at 10:49:26AM +0100, Daniel Vetter wrote:
> > On Thu, Nov 21, 2019 at 07:12:55AM +, james qian wang (Arm Technology
> > China) wrote:
> > > There are some restrictions if HW works on side_by_s
On Wed, Nov 20, 2019 at 10:54 PM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from include/trace/define_trace.h:102,
> from drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h:502,
Applied. thanks!
Alex
On Thu, Nov 21, 2019 at 11:54 AM Colin King wrote:
>
> From: Colin Ian King
>
> The pointer write_frame is being initialized with a value that is
> never read and it is being updated later with a new value. The
> initialization is redundant and can be removed.
>
> Address
These are useful for other users of afbc, e.g. rockchip.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_afbc.c| 84 +++
drivers/gpu/drm/drm_fourcc.c | 11 +++-
drivers/gpu/drm/drm_framebuffer.c | 71
AFBC helpers are available. Use those which increase code readability.
Signed-off-by: Andrzej Pietrasiewicz
---
.../drm/arm/display/komeda/komeda_framebuffer.c | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_framebu
This patch adds support for afbc handling. afbc is a compressed format
which reduces the necessary memory bandwidth.
Co-developed-by: Mark Yao
Signed-off-by: Mark Yao
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 29
drivers/gpu/drm/rockchip/rockc
There are afbc helpers available.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/arm/malidp_drv.c | 121 +--
1 file changed, 20 insertions(+), 101 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 37d92a0631
v2..v3:
- addressed (some) comments from Daniel Stone, Liviu Dudau, Daniel Vetter
and Brian Starkey - thank you all
In this iteration some rework has been done. The checking logic is now moved
to framebuffer_check() so it is common to all drivers. But the common part
is not good for komeda, so th
On Thu, Nov 21, 2019 at 12:57 AM John Hubbard wrote:
>
> On 11/21/19 12:05 AM, Christoph Hellwig wrote:
> > So while this looks correct and I still really don't see the major
> > benefit of the new code organization, especially as it bloats all
> > put_page callers.
> >
> > I'd love to see code si
From: Colin Ian King
The pointer write_frame is being initialized with a value that is
never read and it is being updated later with a new value. The
initialization is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgp
Hi,
cc'ing the drm/bridge maintainers which I think are missing (Andrzej
Hajda and Neil Armstrong)
Missatge de Matthias Brugger del dia dl., 7
d’oct. 2019 a les 13:04:
>
>
>
> On 07/10/2019 10:22, Ulrich Hecht wrote:
> > From: Jitao Shi
> >
> > This patch adds drm_bridge driver for parade DSI
Hi Dave and Daniel,
A special thanks to our CI and to Chris here.
https://intel-gfx-ci.01.org/tree/drm-intel-fixes/index.html
For finding and providing the quick fix for 5.4 on time to avoid
the bad corruption with fbdev mmap.
Plus other kernel oops and corruption fixes.
There was a conflict h
>-Original Message-
>From: Intel-gfx On Behalf Of Gerd
>Hoffmann
>Sent: Thursday, November 21, 2019 5:38 AM
>To: dri-devel@lists.freedesktop.org
>Cc: David Airlie ; intel-...@lists.freedesktop.org; open list
>; Maxime Ripard ; Gerd
>Hoffmann
>Subject: [Intel-gfx] [PATCH 2/2] drm: share ad
On Thu, Nov 21, 2019 at 5:06 PM Karol Herbst wrote:
>
> On Thu, Nov 21, 2019 at 4:47 PM Rafael J. Wysocki wrote:
> >
> > On Thu, Nov 21, 2019 at 1:53 PM Karol Herbst wrote:
> > >
> > > On Thu, Nov 21, 2019 at 12:46 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Thu, Nov 21, 2019 at 12:34:22
> -Original Message-
> From: amd-gfx On Behalf Of
> Bjorn Helgaas
> Sent: Thursday, November 21, 2019 9:02 AM
> To: linux-...@vger.kernel.org
> Cc: Zhou, David(ChunMing) ; Frederick Lawler
> ; Dave Airlie ; linux-
> ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; Bjorn Helgaas
> ;
Reviewed-by: Alex Deucher
From: Krzysztof Kozlowski
Sent: Thursday, November 21, 2019 8:29 AM
To: linux-ker...@vger.kernel.org
Cc: Krzysztof Kozlowski ; Deucher, Alexander
; Koenig, Christian ;
Zhou, David(ChunMing) ; David Airlie ;
Daniel Vetter ; amd-...@lis
On Thu, Nov 21, 2019 at 4:47 PM Rafael J. Wysocki wrote:
>
> On Thu, Nov 21, 2019 at 1:53 PM Karol Herbst wrote:
> >
> > On Thu, Nov 21, 2019 at 12:46 PM Mika Westerberg
> > wrote:
> > >
> > > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> > > > On Thu, Nov 21, 2019 at 12:2
On Thu, Nov 21, 2019 at 1:53 PM Karol Herbst wrote:
>
> On Thu, Nov 21, 2019 at 12:46 PM Mika Westerberg
> wrote:
> >
> > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Wed, Nov 20, 2019 at
On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg
wrote:
>
> On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg wrote:
> > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Wed, Nov 20, 20
From: Bjorn Helgaas
Previously we masked PCIe Link Control 2 register values with "7 << 9",
which was apparently intended to be the Transmit Margin field, but instead
was the high order bit of Transmit Margin, the Enter Modified Compliance
bit, and the Compliance SOS bit.
Correct the mask to "7
From: Bjorn Helgaas
Replace hard-coded magic numbers with the descriptive PCI_EXP_LNKCTL2
definitions. No functional change intended.
Link: https://lore.kernel.org/r/20191112173503.176611-4-helg...@kernel.org
Signed-off-by: Bjorn Helgaas
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdg
From: Bjorn Helgaas
Replace hard-coded magic numbers with the descriptive PCI_EXP_LNKCTL2
definitions. No functional change intended.
Link: https://lore.kernel.org/r/20191112173503.176611-4-helg...@kernel.org
Signed-off-by: Bjorn Helgaas
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/c
From: Bjorn Helgaas
Previously we masked PCIe Link Control 2 register values with "7 << 9",
which was apparently intended to be the Transmit Margin field, but instead
was the high order bit of Transmit Margin, the Enter Modified Compliance
bit, and the Compliance SOS bit.
Correct the mask to "7
From: Bjorn Helgaas
Use pcie_capability_read_word() and similar instead of using
pci_read_config_word() directly. Add #defines to replace some magic
numbers. Fix typos in use of Transmit Margin field.
These are currently on my pci/misc branch for v5.5. Let me know if you see
any issues.
Bjo
From: Frederick Lawler
Commit 8c0d3a02c130 ("PCI: Add accessors for PCI Express Capability")
added accessors for the PCI Express Capability so that drivers didn't
need to be aware of differences between v1 and v2 of the PCI
Express Capability.
Replace pci_read_config_word() and pci_write_config_
From: Frederick Lawler
Commit 8c0d3a02c130 ("PCI: Add accessors for PCI Express Capability")
added accessors for the PCI Express Capability so that drivers didn't
need to be aware of differences between v1 and v2 of the PCI
Express Capability.
Replace pci_read_config_word() and pci_write_config_
From: Bjorn Helgaas
Add definitions for the Enter Compliance and Transmit Margin fields of the
PCIe Link Control 2 register.
Link: https://lore.kernel.org/r/20191112173503.176611-2-helg...@kernel.org
Signed-off-by: Bjorn Helgaas
Reviewed-by: Alex Deucher
---
include/uapi/linux/pci_regs.h | 2
On Thu, Nov 21, 2019 at 02:52:59PM +0100, Daniel Vetter wrote:
> On Thu, Nov 21, 2019 at 11:38:06AM +0100, Gerd Hoffmann wrote:
> > The fake offset is going to stay, so change the calling convention for
> > drm_gem_object_funcs.mmap to include the fake offset. Update all users
> > accordingly.
>
On Mon, Nov 18, 2019 at 12:42:25PM -0500, Alex Deucher wrote:
> On Mon, Nov 18, 2019 at 3:37 AM Frederick Lawler wrote:
> >
> > Commit 8c0d3a02c130 ("PCI: Add accessors for PCI Express Capability")
> > added accessors for the PCI Express Capability so that drivers didn't
> > need to be aware of di
On Thu, Nov 21, 2019 at 11:38:07AM +0100, Gerd Hoffmann wrote:
> Use the shared address space of the drm device (see drm_open() in
> drm_file.c) for dma-bufs too. That removes a difference betweem drm
> device mmap vmas and dma-buf mmap vmas and fixes corner cases like
> unmaps not working properl
On Thu, Nov 21, 2019 at 11:38:06AM +0100, Gerd Hoffmann wrote:
> The fake offset is going to stay, so change the calling convention for
> drm_gem_object_funcs.mmap to include the fake offset. Update all users
> accordingly.
Please add to the commit message:
Note that this reverts 83b8a6f242ea ("
https://bugzilla.kernel.org/show_bug.cgi?id=205049
--- Comment #15 from Pierre-Eric Pelloux-Prayer
(pierre-eric.pelloux-pra...@amd.com) ---
I opened a Merge Request for Mesa to address this issue:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2836
Testing it and reporting the results
https://bugzilla.kernel.org/show_bug.cgi?id=205589
--- Comment #4 from p...@spth.de ---
Today, I've also installed a 5.1.21 kernel from Ubuntu on my Debian GNU/Linux
testing system, and logged into XFCE thrice. I did not see the green screen
crash with that kernel, though one I got a crash (system
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu/drm/amd/acp/Kconfig | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu/drm/sun4i/Kconfig | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --g
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu/drm/vc4/Kconfig | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/driver
On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg
wrote:
>
> On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg wrote:
> > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Wed, Nov 20, 20
On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg wrote:
> On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki wrote:
> > > > > last week o
On Thu, Nov 21, 2019 at 12:46 PM Mika Westerberg
wrote:
>
> On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki wrote:
> > > > > last week or so I
Hi Maxime,
On Sun, Nov 3, 2019 at 11:02 PM Maxime Ripard wrote:
>
> On Fri, Nov 01, 2019 at 07:42:55PM +0530, Jagan Teki wrote:
> > Hi Maxime,
> >
> > On Tue, Oct 29, 2019 at 2:24 PM Maxime Ripard wrote:
> > >
> > > On Tue, Oct 29, 2019 at 04:03:56AM +0530, Jagan Teki wrote:
> > > > > > explicit
On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg
> wrote:
> >
> > On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki wrote:
> > > > last week or so I found systems where the GPU was under the "PCI
> > > > Express Root Po
On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg
wrote:
>
> On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki wrote:
> > > last week or so I found systems where the GPU was under the "PCI
> > > Express Root Port" (name from lspci) and on those systems all of that
> > > seems to work. So
On Thu, Nov 21, 2019 at 12:17 PM Mika Westerberg
wrote:
>
> On Thu, Nov 21, 2019 at 12:03:52PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote:
> > > > with the branch and patc
On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki wrote:
> > last week or so I found systems where the GPU was under the "PCI
> > Express Root Port" (name from lspci) and on those systems all of that
> > seems to work. So I am wondering if it's indeed just the 0x1901 one,
> > which also e
On Thu, Nov 21, 2019 at 12:03:52PM +0100, Rafael J. Wysocki wrote:
> On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg
> wrote:
> >
> > On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote:
> > > with the branch and patch applied:
> > > https://gist.githubusercontent.com/karolherbst/03c4c81
On Thu, Nov 21, 2019 at 12:08 PM Rafael J. Wysocki wrote:
>
> On Thu, Nov 21, 2019 at 12:03 PM Rafael J. Wysocki wrote:
> >
> > On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote:
> > > > with the branch and patch
On Thu, Nov 21, 2019 at 12:03 PM Rafael J. Wysocki wrote:
>
> On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg
> wrote:
> >
> > On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote:
> > > with the branch and patch applied:
> > > https://gist.githubusercontent.com/karolherbst/03c4c8141b0fa
On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg
wrote:
>
> On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote:
> > with the branch and patch applied:
> > https://gist.githubusercontent.com/karolherbst/03c4c8141b0fa292d781badfa186479e/raw/5c62640afbc57d6e69ea924c338bd2836e770d02/gistfile
Tested on qemu, with bochs (vram helpers) and cirrus (shmem helpers).
Cc'ing intel-gfx for CI coverage.
Gerd Hoffmann (2):
drm: call drm_gem_object_funcs.mmap with fake offset
drm: share address space for dma bufs
include/drm/drm_gem.h | 4 +---
drivers/gpu/drm/drm_gem.c
The fake offset is going to stay, so change the calling convention for
drm_gem_object_funcs.mmap to include the fake offset. Update all users
accordingly.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem.h | 4 +---
drivers/gpu/drm/drm_gem.c | 3 ---
drivers/gp
Use the shared address space of the drm device (see drm_open() in
drm_file.c) for dma-bufs too. That removes a difference betweem drm
device mmap vmas and dma-buf mmap vmas and fixes corner cases like
unmaps not working properly.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/drm_prime.c | 4
On Thu, Nov 21, 2019 at 11:18 AM Gerd Hoffmann wrote:
>
> On Thu, Nov 21, 2019 at 09:49:53AM +0100, Daniel Vetter wrote:
> > On Thu, Nov 21, 2019 at 09:02:59AM +0100, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > > update-object-after-move works fine.
> > > > >
> > > > > try zap mappings with mad
On Thu, Nov 21, 2019 at 10:49:26AM +0100, Daniel Vetter wrote:
> On Thu, Nov 21, 2019 at 07:12:55AM +, james qian wang (Arm Technology
> China) wrote:
> > There are some restrictions if HW works on side_by_side, expose it via
> > config_id to user.
> >
> > Signed-off-by: James Qian Wang (Arm T
On 20/11/2019 09:57, Andy Shevchenko wrote:
> New GCC warns about inappropriate use of strncpy():
>
> drivers/staging/fbtft/fbtft-core.c: In function ‘fbtft_framebuffer_alloc’:
> drivers/staging/fbtft/fbtft-core.c:665:2: warning: ‘strncpy’ specified bound
> 16 equals destination size [-Wstringop-
On Thu, Nov 21, 2019 at 09:49:53AM +0100, Daniel Vetter wrote:
> On Thu, Nov 21, 2019 at 09:02:59AM +0100, Gerd Hoffmann wrote:
> > Hi,
> >
> > > > update-object-after-move works fine.
> > > >
> > > > try zap mappings with madvise(dontneed) has no bad effects (after vram
> > > > move, trying to
On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote:
> with the branch and patch applied:
> https://gist.githubusercontent.com/karolherbst/03c4c8141b0fa292d781badfa186479e/raw/5c62640afbc57d6e69ea924c338bd2836e770d02/gistfile1.txt
Thanks for testing. Too bad it did not help :( I suppose t
On Wed, Nov 20, 2019 at 04:24:48PM -0800, Rob Clark wrote:
> On Wed, Nov 20, 2019 at 2:56 AM Daniel Vetter wrote:
> >
> > For locking semantics it really doesn't matter when we grab the
> > ticket. But for lockdep validation it does: the acquire ctx is a fake
> > lockdep. Since other drivers might
On Thu 21-11-19 00:29:59, John Hubbard wrote:
> >
> > Otherwise this looks fine and might be a worthwhile cleanup to feed
> > Andrew for 5.5 independent of the gut of the changes.
> >
> > Reviewed-by: Christoph Hellwig
> >
>
> Thanks for the reviews! Say, it sounds like your view here is that
On Thu, Nov 21, 2019 at 07:12:55AM +, james qian wang (Arm Technology
China) wrote:
> There are some restrictions if HW works on side_by_side, expose it via
> config_id to user.
>
> Signed-off-by: James Qian Wang (Arm Technology China)
>
> ---
> drivers/gpu/drm/arm/display/include/malidp_p
On Thu 21-11-19 00:29:59, John Hubbard wrote:
> On 11/21/19 12:03 AM, Christoph Hellwig wrote:
> > Otherwise this looks fine and might be a worthwhile cleanup to feed
> > Andrew for 5.5 independent of the gut of the changes.
> >
> > Reviewed-by: Christoph Hellwig
> >
>
> Thanks for the reviews!
On Wed 20-11-19 23:13:47, John Hubbard wrote:
> Add tracking of pages that were pinned via FOLL_PIN.
>
> As mentioned in the FOLL_PIN documentation, callers who effectively set
> FOLL_PIN are required to ultimately free such pages via put_user_page().
> The effect is similar to FOLL_GET, and may b
On Thu, Nov 21, 2019 at 9:26 AM Timo Aaltonen wrote:
>
> On 9.10.2019 18.50, Daniel Vetter wrote:
> > On Thu, Oct 03, 2019 at 11:31:25AM -0700, Juston Li wrote:
> >> From: Daniel Stone
> >>
> >> getfb2 allows us to pass multiple planes and modifiers, just like addfb2
> >> over addfb.
> >>
> >> Ch
sure, this is a issue.
but it wiil build succesed on local drm-next branch.
and you can submit this patch to fix this issue.
thanks.
Reviewed-by: Kevin Wang
From: Stephen Rothwell
Sent: Thursday, November 21, 2019 11:54 AM
To: Thomas Gleixner; Ingo Molnar; H. Pete
On 11/21/19 12:05 AM, Christoph Hellwig wrote:
So while this looks correct and I still really don't see the major
benefit of the new code organization, especially as it bloats all
put_page callers.
I'd love to see code size change stats for an allyesconfig on this
commit.
Right, I'm running t
On 11/21/19 12:10 AM, Christoph Hellwig wrote:
Should this be two patches, one for th core infrastructure and one for
the user? These changes also look like another candidate to pre-load.
OK, I'll split them up.
thanks,
--
John Hubbard
NVIDIA
___
On Thu, Nov 21, 2019 at 09:02:59AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > update-object-after-move works fine.
> > >
> > > try zap mappings with madvise(dontneed) has no bad effects (after vram
> > > move, trying to force re-creating the ptes).
> >
> > Well if it's broken the zapping wouldn
On Thu, Nov 21, 2019 at 09:10:21AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > Aside: the amdgpu isn't great because it's racy, userspace could have
> > guessed the fd and already started an mmap before we managed to update
> > stuff.
>
> Can't see that race. When I read the code correctly the fd
On Thu, Nov 21, 2019 at 8:59 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 20.11.19 um 12:47 schrieb Daniel Vetter:
> > Hi all,
> >
> > I've been looking at dma_buf_v(un)map, with a goal to standardize
> > locking for at least dynamic dma-buf exporters/importers, most likely
> > by requiring dma_resv_
On 11/21/19 12:08 AM, Christoph Hellwig wrote:
On Wed, Nov 20, 2019 at 11:13:36PM -0800, John Hubbard wrote:
+static int pin_goldfish_pages(unsigned long first_page,
+ unsigned long last_page,
+ unsigned int last_page_size,
+
On Thu, Nov 21, 2019 at 02:54:03PM +1100, Stephen Rothwell wrote:
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
> index f940526c5889..63e734a125fb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
> +++ b/drivers/gpu/drm/amd/amdgpu/am
On 11/21/19 12:03 AM, Christoph Hellwig wrote:
On Wed, Nov 20, 2019 at 11:13:32PM -0800, John Hubbard wrote:
There are four locations in gup.c that have a fair amount of code
duplication. This means that changing one requires making the same
changes in four places, not to mention reading the sam
On 11/21/19 12:06 AM, Christoph Hellwig wrote:
On Wed, Nov 20, 2019 at 11:13:31PM -0800, John Hubbard wrote:
A subsequent patch requires access to gup flags, so
pass the flags argument through to the __gup_device_*
functions.
Looks fine, but why not fold this into the patch using the flags.
On 9.10.2019 18.50, Daniel Vetter wrote:
> On Thu, Oct 03, 2019 at 11:31:25AM -0700, Juston Li wrote:
>> From: Daniel Stone
>>
>> getfb2 allows us to pass multiple planes and modifiers, just like addfb2
>> over addfb.
>>
>> Changes since v1:
>> - unused modifiers set to 0 instead of DRM_FORMAT_MO
D32 is simple version of D71, the difference is:
- Only has one pipeline
- Drop the periph block and merge it to GCU
v2: Rebase.
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../drm/arm/display/include/malidp_product.h | 3 +-
.../arm/display/komeda/d71/d71_component.c| 2 +-
1 - 100 of 123 matches
Mail list logo
