https://bugs.freedesktop.org/show_bug.cgi?id=99801
--- Comment #25 from Matthew Treinish ---
(In reply to Jean-Yves Avenard from comment #21)
> Adding some likely unhelpful info.
> But I've had similar (though not the same) problem since I got this screen.
> However, unlike most comments, I do no
https://bugs.freedesktop.org/show_bug.cgi?id=105218
--- Comment #6 from Timothy Arceri ---
(In reply to Timothy Arceri from comment #5)
> Ok built it correctly this time.
>
> No crash with Mesa git and LLVM 7 the sample runs fine on my RX580. Possible
> there is a bug in LLVM 6.
Ok I tested the
https://bugs.freedesktop.org/show_bug.cgi?id=105218
--- Comment #5 from Timothy Arceri ---
Ok built it correctly this time.
No crash with Mesa git and LLVM 7 the sample runs fine on my RX580. Possible
there is a bug in LLVM 6.
--
You are receiving this mail because:
You are the assignee for th
https://bugs.freedesktop.org/show_bug.cgi?id=102553
--- Comment #14 from Stefano Cipriani ---
The patch works as expected! However when I set the state to battery I get in
dmesg:
[drm:si_dpm_set_power_state [amdgpu]] *ERROR* invalid pcie lane request: 7
and the same message with 15 instead of 7
On Fri, 2018-03-30 at 19:19 +, Souza, Jose wrote:
> On Fri, 2018-03-30 at 11:28 -0700, Pandiyan, Dhinakaran wrote:
> > On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote:
> > > IGT tests could be improved with sink status, knowing for sure that
> > > hardware have activate or exi
amdgpu driver lacks of modeset module option other drm drivers provide
for enforcing or disabling the driver load. Interestingly, the
amdgpu_mode variable declaration is already found in the header file,
but the actual implementation seems to have been forgotten.
This patch adds the missing piece
amdgpu driver checks vgacon_text_force() after some initializations
but without cleaning up. This will result in leaks.
Move the check of vgacon_text_force() to the beginning of
amdgpu_init() for fixing it and also for optimization.
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/amd/amdgpu/am
Maxime Ripard writes:
> Some drivers duplicate the logic to create a property to store a per-plane
> alpha.
>
> This is especially useful if we ever want to support extra protocols for
> Wayland like:
> https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html
>
> Let's create
I've been keeping my eye on what's going on with drm/scheduler, and I'm
definitely interested in using it. I've got some questions about how to
fit it to this HW, though.
For this HW, most rendering jobs have two phases: binning and rendering,
and the HW has two small FIFOs for descriptions of ea
On Fri, Mar 30, 2018 at 12:46:42PM -0600, Logan Gunthorpe wrote:
>
>
> On 29/03/18 07:58 PM, Jerome Glisse wrote:
> > On Thu, Mar 29, 2018 at 10:25:52AM -0600, Logan Gunthorpe wrote:
> >>
> >>
> >> On 29/03/18 10:10 AM, Christian König wrote:
> >>> Why not? I mean the dma_map_resource() function
On Fri, 2018-03-30 at 11:28 -0700, Pandiyan, Dhinakaran wrote:
> On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote:
> > IGT tests could be improved with sink status, knowing for sure that
> > hardware have activate or exit PSR.
> >
> > Cc: Dhinakaran Pandiyan
> > Cc: Rodrigo Vivi
>
Ville Syrjala writes:
> From: Ville Syrjälä
>
> Up to now we've used the plane's modifier list as the primary
> source of information for which modifiers are supported by a
> given plane. In order to allow auxiliary metadata to be embedded
> within the bits of the modifier we need to stop doing
Boris Brezillon writes:
> ->atomic_async_update() requires that drivers update the plane->state
> object before returning. Make sure at least common properties have been
> updated.
>
> Cc: Gustavo Padovan
> Signed-off-by: Boris Brezillon
> ---
> Hello,
>
> This is a problem I had when debugging
Boris Brezillon writes:
> From: Gustavo Padovan
>
> Add support for async updates of cursors by using the new atomic
> interface for that. Basically what this commit does is do what
> vc4_update_plane() did but through atomic.
My r-b still applies with your fixes here. Go ahead and push when
y
https://bugs.freedesktop.org/show_bug.cgi?id=102553
--- Comment #13 from Alex Deucher ---
Created attachment 138450
--> https://bugs.freedesktop.org/attachment.cgi?id=138450&action=edit
possible fix
Thanks for looking into this. Good start! The attached patch should fix it.
--
You are rece
https://bugzilla.kernel.org/show_bug.cgi?id=199101
Samuel Grahn (samuel.gr...@outlook.com) changed:
What|Removed |Added
CC||samuel.gr...@out
On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote:
> IGT tests could be improved with sink status, knowing for sure that
> hardware have activate or exit PSR.
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
> ---
>
> v3: rebased
>
> drivers
https://bugs.freedesktop.org/show_bug.cgi?id=105819
Bug ID: 105819
Summary: Window system hang due to GPU Fault
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severi
On Fri, 2018-03-30 at 10:36 -0700, Pandiyan, Dhinakaran wrote:
>
>
> On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote:
> > For Geminilake and Cannonlake+ the Y-coordinate support must be
> > enabled in PSR2_CTL too.
> >
> > Spec: 7713 and 7720
> >
> > Cc: Dhinakaran Pandiyan
> >
On Wed, Mar 28, 2018 at 03:30:45PM -0700, José Roberto de Souza wrote:
> In the 2 eDP1.4a pannels tested set or not set bit have no effect
> but is better set it and comply with specification.
>
> Signed-off-by: José Roberto de Souza
> Cc: Dhinakaran Pandiyan
> Reviewed-by: Rodrigo Vivi
patche
On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote:
> For Geminilake and Cannonlake+ the Y-coordinate support must be
> enabled in PSR2_CTL too.
>
> Spec: 7713 and 7720
>
> Cc: Dhinakaran Pandiyan
> Reviewed-by: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
> ---
>
> v3:
https://bugs.freedesktop.org/show_bug.cgi?id=105725
--- Comment #5 from hjpries...@gmail.com ---
Created attachment 138448
--> https://bugs.freedesktop.org/attachment.cgi?id=138448&action=edit
dmesg of drm-next-4.17-wip (date of clone 2018-03-29)
--
You are receiving this mail because:
You ar
https://bugs.freedesktop.org/show_bug.cgi?id=105725
--- Comment #4 from hjpries...@gmail.com ---
Harry,
I have build a kernel using the:
git clone -b drm-next-4.17-wip git://people.freedesktop.org/~agd5f/linux
I did the clone about 2018-29-03 20:00 UTC
The warnings are still there.
root@
From: Fabio Estevam
The freescale.com domain will stop working soon, so use
the nxp.com domain instead.
Signed-off-by: Fabio Estevam
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4923621..794c130 100644
--- a/MAINTAINERS
+++
https://bugs.freedesktop.org/show_bug.cgi?id=105218
--- Comment #4 from Matias N. Goldberg ---
This is an example of how JSON settings look in my CMake setup:
https://i.imgur.com/mj77iEz.png
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=105218
--- Comment #3 from Matias N. Goldberg ---
Hi!
Thanks for starting to look into this!
First:
glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Radeon RX 560 Series (POLARIS11 / DRM 3.19.0 / 4.14.11,
LLVM 6.0.0)
OpenGL
https://bugs.freedesktop.org/show_bug.cgi?id=104854
taij...@posteo.de changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=105760
taij...@posteo.de changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
Stefan Schake writes:
> The hardware supports a CTM with S0.9 values. We therefore only allow
> a value of 1.0 or fractional only and reject all others with integer
> parts. This restriction is mostly inconsequential in practice since
> commonly used transformation matrices have all scalars <= 1.
Stefan Schake writes:
> We are an atomic driver so the gamma LUT should also be exposed as a
> CRTC property through the DRM atomic color management. This will also
> take care of the legacy path for us.
>
> Signed-off-by: Stefan Schake
> ---
> v2: Use drm_color_lut_size for LUT length
>
> driv
https://bugs.freedesktop.org/show_bug.cgi?id=105760
--- Comment #1 from taij...@posteo.de ---
OK, I think I've managed to narrow this one down a bit.
If I build the kernel from commit 09695ad78f1f5f315c7e9c5090f0c7b846a43690,
which is also tagged as 'drm-next-4.17', then everything is shiny. Howe
From: Colin Ian King
Trivial fix to spelling mistake in DRM_ERROR error message text
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/
https://bugs.freedesktop.org/show_bug.cgi?id=104063
taij...@posteo.de changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On Thu, Mar 29, 2018 at 11:33:34PM -0700, Christoph Hellwig wrote:
> On Thu, Mar 29, 2018 at 09:58:54PM -0400, Jerome Glisse wrote:
> > dma_map_resource() is the right API (thought its current implementation
> > is fill with x86 assumptions). So i would argue that arch can decide to
> > implement i
On Fri, 30 Mar 2018 17:09:03 +0200
Boris Brezillon wrote:
> Rework the atomic commit logic to handle async page flip requests in
> the atomic update path.
>
> Async page flips are a bit more complicated than async cursor updates
> (already handled in the vc4_atomic_commit() function) in that you
On 30 March 2018 at 14:30, Alex Deucher wrote:
> On Fri, Mar 30, 2018 at 8:28 AM, Daniel Stone wrote:
>> Taken from the drm-next pull for 4.17-rc1 (694f54f680f7), and manually
>
> Reviewed-by: Alex Deucher
Both pushed, thanks a lot Alex!
Cheers,
Daniel
_
The last user of vc4_queue_seqno_cb() (async page flip handling code)
is gone. Get rid of this function and all the related structs and
fields.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/vc4/vc4_drv.h | 14 --
drivers/gpu/drm/vc4/vc4_gem.c | 39 ---
Rework the atomic commit logic to handle async page flip requests in
the atomic update path.
Async page flips are a bit more complicated than async cursor updates
(already handled in the vc4_atomic_commit() function) in that you need
to wait for fences on the new framebuffers to be signaled before
Hello,
This is an attempt at simplifying the async page flip handling in VC4
in order to get rid of vc4_queue_seqno_cb() and its dependencies and
rely on fences instead.
The reason I'm sending this as an RFC is because I'm pretty sure we can
put some of the code added in patch 1 in drm_atomic_hel
On Fri, Mar 30, 2018 at 11:00 AM, Daniel Stone wrote:
> Hi Alex,
>
> On 30 March 2018 at 15:47, Alex Deucher wrote:
>> On Fri, Mar 30, 2018 at 10:11 AM, Daniel Stone wrote:
>>> I intend to remove create_handle when all drivers are converted over
>>> to placing BOs directly inside drm_framebuffer
Hi Alex,
On 30 March 2018 at 15:47, Alex Deucher wrote:
> On Fri, Mar 30, 2018 at 10:11 AM, Daniel Stone wrote:
>> I intend to remove create_handle when all drivers are converted over
>> to placing BOs directly inside drm_framebuffer. For most drivers
>> there's a relatively easy conversion to u
->atomic_async_update() requires that drivers update the plane->state
object before returning. Make sure at least common properties have been
updated.
Cc: Gustavo Padovan
Signed-off-by: Boris Brezillon
---
Hello,
This is a problem I had when debugging the VC4 ->atomic_async_update()
implementat
On Fri, Mar 30, 2018 at 10:11 AM, Daniel Stone wrote:
> Hi,
> I've been working on a getfb2[0] ioctl, which amongst other things
> supports multi-planar framebuffers as well as modifiers. getfb
> currently calls the framebuffer's handle_create hook, which doesn't
> support multiple planes.
>
> Tha
Hi,
On 30-03-18 15:25, Hans de Goede wrote:
Hi,
On 30-03-18 14:44, Chris Wilson wrote:
Quoting Hans de Goede (2018-03-30 13:37:40)
Hi,
On 30-03-18 14:30, Chris Wilson wrote:
Quoting Hans de Goede (2018-03-30 13:27:15)
Before this commit the WaSkipStolenMemoryFirstPage workaround code was
s
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone
Cc: Dave Airlie
Cc: Gerd Hoffmann
Now exynos_drm_fb is just an empty wrapper around drm_framebuffer, we
can drop it.
Signed-off-by: Daniel Stone
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fb.c | 28
1 file changed, 8 insertions(+), 20
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle function the same as the GEM framebuffer helper, we
can reuse that.
Signed-off-by: Daniel Stone
Cc: Thierry Reding
Cc: linux-te...@vger.kernel.o
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone
Cc: Alex Deucher
Cc: Christian Kön
Now cirrus_framebuffer is just an empty wrapper around drm_framebuffer,
we can drop it.
Signed-off-by: Daniel Stone
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
---
drivers/gpu/drm/cirrus/cirrus_drv.h | 9 ++---
drivers/gpu/drm/cirrus/cirrus_fbdev.c |
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone
Cc: Russell King
---
drivers/gpu/
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone
Cc: Patrik Jakobsson
---
drivers/
This can be calculated from the GEM BO DMA address as well as the offset
stored in the base framebuffer.
Signed-off-by: Daniel Stone
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fb.c | 8 +++-
1 file changed, 3 insertions(+), 5
Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we
can remove it.
Signed-off-by: Daniel Stone
Cc: Sandy Huang
Cc: Heiko Stübner
---
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 54 ++---
drivers/gpu/drm/rockchip/rockchip_drm_fb.h | 3 --
drivers/gp
Now that mtk_drm_fb is an empty wrapper around drm_framebuffer, we can
just delete it.
Signed-off-by: Daniel Stone
Cc: CK Hu
Cc: Philipp Zabel
---
drivers/gpu/drm/mediatek/mtk_drm_fb.c | 40 ---
1 file changed, 14 insertions(+), 26 deletions(-)
diff --git a/dri
Since tegra_fb is now the same as drm_framebuffer, we can just replace
the type completely.
Signed-off-by: Daniel Stone
Cc: Thierry Reding
Cc: linux-te...@vger.kernel.org
---
drivers/gpu/drm/tegra/drm.h | 6 +-
drivers/gpu/drm/tegra/fb.c | 34 ++
2 files ch
User framebuffers are created with either bo->pages or bo->vaddr set,
depending on whether or not an IOMMU is present. On the other hand, the
framebuffer created for fbdev emulation has a vaddr mapping made if
bo->pages is set after creation. This is set up in fbdev probe.
Remove the special case
A FB with no object is something we should be shouting very loudly
about, not quietly logging as debug.
Signed-off-by: Daniel Stone
Cc: CK Hu
Cc: Philipp Zabel
---
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/m
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle function the same as the GEM framebuffer helper, we
can reuse that.
Signed-off-by: Daniel Stone
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone
Cc: Inki Dae
Cc: Joonyoung Shim
C
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone
Cc: Alex Deucher
Cc: Christian Kön
drm_framebuffer already stores num_planes for us.
Signed-off-by: Daniel Stone
Cc: Thierry Reding
Cc: linux-te...@vger.kernel.org
---
drivers/gpu/drm/tegra/drm.h | 1 -
drivers/gpu/drm/tegra/fb.c | 6 ++
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dr
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone
Cc: Tomi Valkeinen
---
drivers/gp
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone
Cc: Alex Deucher
Cc: Christian Kön
drm_framebuffer already holds per-plane pitch and offsets, which is
filled out for us when we create the framebuffer. Nuke our local copy in
the plane struct.
Signed-off-by: Daniel Stone
Cc: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_fb.c | 22 +-
1 file changed, 9 inse
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone
Cc: Sandy Huang
Cc: Heiko Stübner
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone
Cc: CK Hu
Cc: Philipp Zabel
---
Now that our destroy function is the same as the helper, use that
directly.
Signed-off-by: Daniel Stone
Cc: Thierry Reding
Cc: linux-te...@vger.kernel.org
---
drivers/gpu/drm/tegra/fb.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/tegra/f
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone
Cc: Dave Airlie
Cc: Gerd Hoffmann
Hi,
I've been working on a getfb2[0] ioctl, which amongst other things
supports multi-planar framebuffers as well as modifiers. getfb
currently calls the framebuffer's handle_create hook, which doesn't
support multiple planes.
Thanks to Noralf's recent work, drivers can just store GEM objects
dire
https://bugs.freedesktop.org/show_bug.cgi?id=105170
--- Comment #7 from Alex Deucher ---
Does anything change if you try the cards in different slots in the
motherboard?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-
https://bugs.freedesktop.org/show_bug.cgi?id=105170
Alex Deucher changed:
What|Removed |Added
Attachment #137452|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=105170
--- Comment #6 from erhar...@mailbox.org ---
Created attachment 138443
--> https://bugs.freedesktop.org/attachment.cgi?id=138443&action=edit
journalctl -k (kernel 4.16_rc7)
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=105170
--- Comment #5 from erhar...@mailbox.org ---
Still no luck with kernel 4.15.14 or 4.16_rc7.
The 2nd card in this system got no problems with the ring test (R9 290).
# lspci | grep -i vga
01:00.0 VGA compatible controller: Advanced Micro Devices
On Fri, Mar 30, 2018 at 8:28 AM, Daniel Stone wrote:
> Taken from the drm-next pull for 4.17-rc1 (694f54f680f7), and manually
> reconciled:
>
> core:
> - Dropped DRM_MODE_TYPE_ALL and DRM_MODE_FLAG_ALL; these are purely
> internal details of the bits accepted by the currently running
>
On Fri, Mar 30, 2018 at 8:28 AM, Daniel Stone wrote:
> Nouveau has made a very deliberate choice to hide its actual kernel ABI
> behind libdrm. i915 is no longer out of date.
>
> Signed-off-by: Daniel Stone
Acked-by: Alex Deucher
> ---
> include/drm/README | 6 +-
> 1 file changed, 1 inse
Hi,
On 30-03-18 14:44, Chris Wilson wrote:
Quoting Hans de Goede (2018-03-30 13:37:40)
Hi,
On 30-03-18 14:30, Chris Wilson wrote:
Quoting Hans de Goede (2018-03-30 13:27:15)
Before this commit the WaSkipStolenMemoryFirstPage workaround code was
skipping the first 4k by passing 4096 as start
https://bugzilla.kernel.org/show_bug.cgi?id=199101
--- Comment #10 from Thomas Crider (tcride...@gmail.com) ---
just fyi I do not get the flicker on 4.16 rc3, this may help to shorten the
time it takes to bisect
--
You are receiving this mail because:
You are watching the assignee of the bug.
__
During probe there may not be any connectors yet if e.g. the panel
failed or hasn't been probed yet. I hitting this in practice the panels
probing was being delayed due to using a gpio backlight.
Fix this by returning -EPROBE_DEFER so the probing will be retried.
Signed-off-by: Sjoerd Simons
--
https://bugzilla.kernel.org/show_bug.cgi?id=199101
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
On 29/03/18 05:44 AM, Christian König wrote:
> Am 28.03.2018 um 21:53 schrieb Logan Gunthorpe:
>>
>> On 28/03/18 01:44 PM, Christian König wrote:
>>> Well, isn't that exactly what dma_map_resource() is good for? As far as
>>> I can see it makes sure IOMMU is aware of the access route and
>>> tran
It is bus specific aspect to map a given device on the bus and
relevant firmware description of its DMA configuration.
So, this change introduces 'dma_configure' as bus callback
giving flexibility to busses for implementing its own dma
configuration function.
The change eases the addition of new b
Hi,
On Thu, Mar 29, 2018 at 02:24:40PM +0100, Emil Velikov wrote:
> On 29 March 2018 at 13:31, Sebastian Reichel
> wrote:
> > Hi,
> >
> > On Thu, Mar 29, 2018 at 12:00:18PM +0100, Emil Velikov wrote:
> >> On 29 March 2018 at 11:40, Tomi Valkeinen wrote:
> >> > omap_framebuffer_get_next_connector
Fixes the following sparse warnings:
drivers/gpu/drm/tegra/dc.c:2181:69: warning:
Using plain integer as NULL pointer
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/tegra/dc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegr
On Tue, Mar 27, 2018 at 01:30:04PM +0200, Michael Grzeschik wrote:
> On Mon, Mar 26, 2018 at 06:17:44PM +0200, Michael Grzeschik wrote:
> > We move drm_kms_helper_poll_init behind the drm_fbdev_cma_init so the
> > set_par will be called and fb will be active.
> >
>
> As this commit message is not
Hi,
On Thu, Mar 29, 2018 at 12:00:18PM +0100, Emil Velikov wrote:
> On 29 March 2018 at 11:40, Tomi Valkeinen wrote:
> > omap_framebuffer_get_next_connector() is not used, remove it.
> >
> Seems to have been unused for a few years now.
> Namely since commit 5a35876e2830511cb8110667fc426c6a6165a59
On 28/03/18 12:28 PM, Christian König wrote:
> I'm just using amdgpu as blueprint because I'm the co-maintainer of it
> and know it mostly inside out.
Ah, I see.
> The resource addresses are translated using dma_map_resource(). As far
> as I know that should be sufficient to offload all the a
Hi,
On Thu, Mar 29, 2018 at 03:49:08PM +0300, Tomi Valkeinen wrote:
> On 29/03/18 15:31, Sebastian Reichel wrote:
> > Hi,
> >
> > On Thu, Mar 29, 2018 at 12:00:18PM +0100, Emil Velikov wrote:
> >> On 29 March 2018 at 11:40, Tomi Valkeinen wrote:
> >>> omap_framebuffer_get_next_connector() is not
Before this commit the WaSkipStolenMemoryFirstPage workaround code was
skipping the first 4k by passing 4096 as start of the address range passed
to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and
reserve the firmware framebuffer so that we can inherit it would always
fail,
When the definition of this struct was removed a forward declaration and an
unused struct member were still left around. Remove them because they serve
no purpose.
Fixes 44b460cfe554 ("drm: imx: remove struct imx_drm_crtc and
imx_drm_crtc_helper_funcs")
Signed-off-by: Leonard Crestez
---
drive
On 28/03/18 10:02 AM, Christian König wrote:
> Yeah, that looks very similar to what I picked up from the older
> patches, going to read up on that after my vacation.
Yeah, I was just reading through your patchset and there are a lot of
similarities. Though, I'm not sure what you're trying to a
On 2018-03-28 09:34, Boris Brezillon wrote:
> Hi Peter,
>
> On Mon, 26 Mar 2018 09:35:02 +0200
> Peter Rosin wrote:
>
>> I have an sama5d31-based system with 64MB of memory and a 1920x1080
>> LVDS display wired for 16-bpp. When I enable legacy fbdev support,
>> the contiguous memory allocator in
With each bus implementing its own DMA configuration callback,
there is no need for bus to explicitly have force_dma in its
global structure. This patch modifies of_dma_configure API to
accept an input parameter which specifies if implicit DMA
configuration is required even when it is not described
On 28/03/18 09:07 AM, Christian König wrote:
> Am 28.03.2018 um 14:38 schrieb Christoph Hellwig:
>> On Sun, Mar 25, 2018 at 12:59:54PM +0200, Christian König wrote:
>>> From: "wda...@nvidia.com"
>>>
>>> Add an interface to find the first device which is upstream of both
>>> devices.
>> Please wo
On 29/03/18 10:10 AM, Christian König wrote:
> Why not? I mean the dma_map_resource() function is for P2P while other
> dma_map_* functions are only for system memory.
Oh, hmm, I wasn't aware dma_map_resource was exclusively for mapping
P2P. Though it's a bit odd seeing we've been working under
On 28/03/18 01:44 PM, Christian König wrote:
> Well, isn't that exactly what dma_map_resource() is good for? As far as
> I can see it makes sure IOMMU is aware of the access route and
> translates a CPU address into a PCI Bus address.
> I'm using that with the AMD IOMMU driver and at least the
Fix to return error code -ENOMEM from the eviction fence create fail
error handling case instead of 0, as done elsewhere in this function.
Fixes: a46a2cd103a8 ("drm/amdgpu: Add GPUVM memory management functions for
KFD")
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gp
Fixes the following sparse warning:
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c:1150:6: warning:
symbol 'kfd_dev_is_large_bar' was not declared. Should it be static?
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
The driver registers the poll helper but has no output plug handler
registered. Therefor kms_hotplug_event doesn't trigger any configuration
changes on the framebuffer. The initial configuration setup, after
drm_kms_helper_poll_init is started, will also be missed. This is
running the framebuffer u
Passing NULL pointer to PTR_ERR will result in return value of 0
indicating success which is clearly not what it is intended here.
This patch returns -EINVAL instead.
Fixes: 5ec7e02854b3 ("drm/amdkfd: Add ioctls for GPUVM memory management")
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/amd/amd
Quoting Hans de Goede (2018-03-30 13:37:40)
> Hi,
>
> On 30-03-18 14:30, Chris Wilson wrote:
> > Quoting Hans de Goede (2018-03-30 13:27:15)
> >> Before this commit the WaSkipStolenMemoryFirstPage workaround code was
> >> skipping the first 4k by passing 4096 as start of the address range passed
>
1 - 100 of 109 matches
Mail list logo
