Hi
Am 04.09.19 um 08:27 schrieb Feng Tang:
>> Thank you for testing. But don't get too excited, because the patch
>> simulates a bug that was present in the original mgag200 code. A
>> significant number of frames are simply skipped. That is apparently the
>> reason why it's faster.
>
> Thanks fo
On 9/4/19 1:15 AM, Andy Lutomirski wrote:
On Sep 3, 2019, at 3:15 PM, Thomas Hellström (VMware)
wrote:
On 9/4/19 12:08 AM, Thomas Hellström (VMware) wrote:
On 9/3/19 11:46 PM, Andy Lutomirski wrote:
On Tue, Sep 3, 2019 at 2:05 PM Thomas Hellström (VMware)
wrote:
On 9/3/19 10:51 PM, Dave
https://bugs.freedesktop.org/show_bug.cgi?id=108979
--- Comment #6 from Timothy Arceri ---
Is this still a problem?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
htt
On 03/09/2019 18:34, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> Missing "Move" in the subject after "dss: " ?
>
That was intentional to keep the subject short enough. But it looks like
it is just bellow 76 chars (80 - 4 char indent) even with "Move" added
to it.
BR,
Jy
Hi all,
Today's linux-next merge of the drm tree got conflicts in:
drivers/gpu/drm/amd/display/dc/calcs/Makefile
drivers/gpu/drm/amd/display/dc/dml/Makefile
drivers/gpu/drm/amd/display/dc/dsc/Makefile
between commit:
30851871d5ab ("kbuild: change *FLAGS_.o to take the path relative
to
https://bugs.freedesktop.org/show_bug.cgi?id=108973
Timothy Arceri changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
Hi Thomas,
On Wed, Aug 28, 2019 at 12:51:40PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 28.08.19 um 11:37 schrieb Rong Chen:
> > Hi Thomas,
> >
> > On 8/28/19 1:16 AM, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 27.08.19 um 14:33 schrieb Chen, Rong A:
> >>> Both patches have little impact on
Switch qxl to use drm_gem_object_funcs callbacks
instead of drm_driver callbacks.
Signed-off-by: Gerd Hoffmann
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/qxl/qxl_drv.c| 8
drivers/gpu/drm/qxl/qxl_object.c | 12
2 files changed, 12 insertions(+), 8 deletions(-)
d
select isn't recursive, so we can't turn on DRM_TTM + DRM_TTM_HELPER
in config DRM_VRAM_HELPER, we have to select them on the vram users
instead.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/Kconfig | 2 --
drivers/gpu/drm/ast/Kconfig | 2 ++
drivers/gpu/drm/bochs
Now with ttm_buffer_object being a subclass of drm_gem_object we can
easily lookup ttm_buffer_object for a given drm_gem_object, which in
turn allows to create common helper functions.
This patch starts off with a drm_gem_ttm_print_info() helper function
which adds some ttm specific lines to the d
Gerd Hoffmann (7):
drm: add drm_print_bits
drm/ttm: add drm gem ttm helpers, starting with
drm_gem_ttm_print_info()
drm/vram: use drm_gem_ttm_print_info
drm/vram: add vram-mm debugfs file
drm/qxl: use drm_gem_object_funcs callbacks
drm/qxl: use drm_gem_ttm_print_info
drm/vram: f
Signed-off-by: Gerd Hoffmann
Acked-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem_vram_helper.c | 4 +++-
drivers/gpu/drm/Kconfig | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu
New helper to print named bits of some value (think flags fields).
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_print.h | 3 +++
drivers/gpu/drm/drm_print.c | 33 +
2 files changed, 36 insertions(+)
diff --git a/include/drm/drm_print.h b/include/drm/drm_
Signed-off-by: Gerd Hoffmann
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/qxl/qxl_drv.h| 1 +
drivers/gpu/drm/qxl/qxl_object.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 9e034c5fa87d..d4051409ce64 100644
--- a/
Wire up drm_mm_print() for vram helpers, using a new
debugfs file, so one can see how vram is used:
# cat /sys/kernel/debug/dri/0/vram-mm
0x-0x0300: 768: used
0x0300-0x0600: 768: used
0x0600-0x0900: 768: used
https://bugs.freedesktop.org/show_bug.cgi?id=111551
--- Comment #2 from yanhua <78666...@qq.com> ---
Created attachment 145260
--> https://bugs.freedesktop.org/attachment.cgi?id=145260&action=edit
The previous dmesg.txt has messages been overwriten. from the dmesg-full.txt
can see more inform
https://bugs.freedesktop.org/show_bug.cgi?id=111555
Bug ID: 111555
Summary: [amdgpu/Navi] [powerplay] Failed to send message
errors
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #46 from Tom Seewald (tseew...@gmail.com) ---
Will these patches[1] be back ported to 5.2/5.3 or will we need to wait until
this hopefully lands in 5.4?
[1] https://patchwork.freedesktop.org/series/64505/
--
You are receiving this m
On Thu 29 Aug 09:50 PDT 2019, Denis Efremov wrote:
> "unlikely(WARN_ON(x))" is excessive. WARN_ON() already uses unlikely()
> internally.
>
> Signed-off-by: Denis Efremov
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: Joe Perches
> Cc: Andrew Morton
> Cc: linux-arm-...@vger.kernel.org
> Cc: dri-devel
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu
>
> This patch add mutex description for mt8183 display
Applied to mediatek-drm-next-5.5 [1], thanks.
[1]
https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-next-5.5
Reg
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu
>
> Update device tree binding documention for the display subsystem for
> Mediatek MT8183 SOCs
Applied to mediatek-drm-next-5.5 [1], thanks.
[1]
https://github.com/ckhu-mediatek/linux.git
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu
>
> Update device tree binding documention for the display subsystem for
> Mediatek MT8183 SOCs
Applied to mediatek-drm-next-5.5 [1], thanks.
[1]
https://github.com/ckhu-mediatek/linux.git
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu
>
> Update device tree binding documention for the display subsystem for
> Mediatek MT8183 SOCs
Applied to mediatek-drm-next-5.5 [1], thanks.
[1]
https://github.com/ckhu-mediatek/linux.git
https://bugs.freedesktop.org/show_bug.cgi?id=111482
--- Comment #8 from Andrew Sheldon ---
I just did some more tests, and in my case, it wasn't strictly the refresh
rate, but the timings being too aggressive (which I needed to do to lower the
pixel clock enough due to driver limits, which are qu
Hi Rob,
On Tue, Sep 3, 2019 at 9:12 PM Rob Clark wrote:
> In the mean time, it is a bit ugly, but I guess something like this should
> work:
Yes, this works on a i.MX53 board, thanks:
Tested-by: Fabio Estevam
Is this something you could submit for 5.3?
Thanks
__
https://bugs.freedesktop.org/show_bug.cgi?id=108718
--- Comment #3 from Matias N. Goldberg ---
I'm on:
OpenGL renderer string: AMD RAVEN (DRM 3.30.0, 5.1.15-050115-generic, LLVM
8.0.1)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.2.0-devel
(git-8305766 2019-07-11 bionic-oibaf-p
On Tue, Sep 3, 2019 at 12:31 PM Fabio Estevam wrote:
>
> Hi Jonathan,
>
> On Tue, Sep 3, 2019 at 4:25 PM Jonathan Marek wrote:
> >
> > Hi,
> >
> > I tried this and it works with patches 4+5 from Rob's series and
> > changing gpummu to use sg_phys(sg) instead of sg->dma_address
> > (dma_address is
https://bugs.freedesktop.org/show_bug.cgi?id=111077
--- Comment #23 from Matt Turner ---
Can you make an apitrace of the application that demonstrates the problem?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
> On Sep 3, 2019, at 3:15 PM, Thomas Hellström (VMware)
> wrote:
>
>> On 9/4/19 12:08 AM, Thomas Hellström (VMware) wrote:
>>> On 9/3/19 11:46 PM, Andy Lutomirski wrote:
>>> On Tue, Sep 3, 2019 at 2:05 PM Thomas Hellström (VMware)
>>> wrote:
On 9/3/19 10:51 PM, Dave Hansen wrote:
>>
Thomas, this series has garnered a nak and a whole pile of thoroughly
confused reviewers.
Could you take another stab at this along with a more ample changelog
explaining the context of the problem? I suspect that's a better place
to start than having us all piece together the disparate parts of
On 9/4/19 12:08 AM, Thomas Hellström (VMware) wrote:
On 9/3/19 11:46 PM, Andy Lutomirski wrote:
On Tue, Sep 3, 2019 at 2:05 PM Thomas Hellström (VMware)
wrote:
On 9/3/19 10:51 PM, Dave Hansen wrote:
On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote:
So the question here should really be, can
On 9/3/19 11:46 PM, Andy Lutomirski wrote:
On Tue, Sep 3, 2019 at 2:05 PM Thomas Hellström (VMware)
wrote:
On 9/3/19 10:51 PM, Dave Hansen wrote:
On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote:
So the question here should really be, can we determine already at mmap
time whether backing me
Noticed this while working on adding a drm_dp_decode_sideband_req().
DP_POWER_DOWN_PHY/DP_POWER_UP_PHY both use the same struct as
DP_ENUM_PATH_RESOURCES, so we can just combine their cases.
Changes since v2:
* Fix commit message
Signed-off-by: Lyude Paul
Reviewed-by: Dave Airlie
Cc: Daniel Vet
On Tue, Sep 3, 2019 at 2:05 PM Thomas Hellström (VMware)
wrote:
>
> On 9/3/19 10:51 PM, Dave Hansen wrote:
> > On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote:
> >> So the question here should really be, can we determine already at mmap
> >> time whether backing memory will be unencrypted and a
On Wed, 4 Sep 2019 at 06:48, Lyude Paul wrote:
>
> Declare local pointer to the drm_dp_link_address_ack_reply struct
> instead of constantly dereferencing it through the union in
> txmsg->reply. Then, invert the order of conditionals so we don't have to
> do the bulk of the work inside them, and c
On Tue, Sep 3, 2019 at 1:46 PM Thomas Hellström (VMware)
wrote:
>
> On 9/3/19 6:22 PM, Christoph Hellwig wrote:
> > On Tue, Sep 03, 2019 at 04:32:45PM +0200, Thomas Hellström (VMware) wrote:
> >> Is this a layer violation concern, that is, would you be ok with a similar
> >> helper for TTM, or is
On Wed, 4 Sep 2019 at 06:48, Lyude Paul wrote:
>
> And it's helper, we'll be using this in just a moment.
>
Reviewed-by: Dave Airlie
> Cc: Juston Li
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Daniel Vetter
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/drm_dp_mst
On Wed, 4 Sep 2019 at 06:48, Lyude Paul wrote:
>
> Noticed this while working on adding a drm_dp_decode_sideband_req().
> DP_POWER_DOWN_PHY/DP_POWER_UP_PHY both use the same struct, so we can
> just combine their cases.
both use the same struct as enum path resources?
Since otherwise the patch d
https://bugs.freedesktop.org/show_bug.cgi?id=109389
Czcibor Bohusz-Dobosz changed:
What|Removed |Added
Attachment #145256|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=204725
--- Comment #51 from Dmitri Seletski (drj...@gmail.com) ---
Created attachment 284811
--> https://bugzilla.kernel.org/attachment.cgi?id=284811&action=edit
.config file
--
You are receiving this mail because:
You are watching the assignee of th
https://bugzilla.kernel.org/show_bug.cgi?id=204725
--- Comment #50 from Dmitri Seletski (drj...@gmail.com) ---
(In reply to Mike Lothian from comment #49)
> Did you try it?
https://youtu.be/_6CRYa4MzuU
Have a look at video please.
Console works for sure. Ill add .config that I have now.
--
Yo
https://bugzilla.kernel.org/show_bug.cgi?id=204725
--- Comment #49 from Mike Lothian (m...@fireburn.co.uk) ---
Did you try it?
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.
https://bugzilla.kernel.org/show_bug.cgi?id=204725
Dmitri Seletski (drj...@gmail.com) changed:
What|Removed |Added
URL||https://youtu.be/_6CR
https://bugzilla.kernel.org/show_bug.cgi?id=204725
--- Comment #48 from Dmitri Seletski (drj...@gmail.com) ---
(In reply to Mike Lothian from comment #47)
> It's selected automatically if you set DRM_FBDEV_EMULATION - which is
> "Enable legacy fbdev support for your modesetting driver" and unset a
On 9/3/19 10:51 PM, Dave Hansen wrote:
On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote:
So the question here should really be, can we determine already at mmap
time whether backing memory will be unencrypted and adjust the *real*
vma->vm_page_prot under the mmap_sem?
Possibly, but that requi
On Thu, Aug 29, 2019 at 09:45:18AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> This was useful for debugging fps drops. I suspect it will be useful
> again.
>
> Signed-off-by: Rob Clark
I'm a simple man, I see tracepoints patches and R-b tracepoints patches :)
Reviewed-by: Sean Paul
> -
On Thu, Aug 29, 2019 at 09:45:17AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> In addition, moving to kms->flush_commit() lets us drop the only user
> of kms->commit().
>
> Signed-off-by: Rob Clark
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 13 --
> d
https://bugs.freedesktop.org/show_bug.cgi?id=109389
Czcibor Bohusz-Dobosz changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote:
> So the question here should really be, can we determine already at mmap
> time whether backing memory will be unencrypted and adjust the *real*
> vma->vm_page_prot under the mmap_sem?
>
> Possibly, but that requires populating the buffer with m
On Thu, Aug 29, 2019 at 09:45:16AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Now that flush/wait/complete is decoupled from the "synchronous" part of
> atomic commit_tail(), add support to defer flush to a timer that expires
> shortly before vblank for async commits. In this way, multiple at
Finally! For a very long time, our MST helpers have had one very
annoying issue: They don't know how to reprobe the topology state when
coming out of suspend. This means that if a user has a machine connected
to an MST topology and decides to suspend their machine, we lose all
topology changes that
For very subtle mistakes with topology refs, it can be rather difficult
to trace them down with the debugging info that we already have. I had
one such issue recently while trying to implement suspend/resume
reprobing for MST, and ended up coming up with this.
Inspired by Chris Wilson's wakeref tr
Currently we only print mstb/port pointer addresses in our malloc and
topology refcount functions using the hashed-by-default %p, but
unfortunately if you're trying to debug a use-after-free error caused by
a refcounting error then this really isn't terribly useful. On the other
hand though, everyt
Currently, every single piece of code in amdgpu that loops through
connectors does it incorrectly and doesn't use the proper list iteration
helpers, drm_connector_list_iter_begin() and
drm_connector_list_iter_end(). Yeesh.
So, do that.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry We
Once upon a time, hotplugging devices on MST branches actually worked in
DRM. Now, it only works in amdgpu (likely because of how it's hotplug
handlers are implemented). On both i915 and nouveau, hotplug
notifications from MST branches are noticed - but trying to respond to
them causes messaging ti
Yes-you read that right. Currently there is literally no locking in
place for any of the drm_dp_mst_port struct members that can be modified
in response to a link address response, or a connection status response.
Which literally means if we're unlucky enough to have any sort of
hotplugging event h
This probably hasn't caused any problems up until now since it's
probably nearly impossible to encounter this in the wild, however if we
were to receive a connection status notification from the MST hub after
resume while we're in the middle of reprobing the link addresses for a
topology then there
In order for suspend/resume reprobing to work, we need to be able to
perform sideband communications during suspend/resume, along with
runtime PM suspend/resume. In order to do so, we also need to make sure
that nouveau doesn't bother grabbing a runtime PM reference to do so,
since otherwise we'll
The names for these functions are rather confusing. drm_dp_add_port()
sounds like a function that would simply create a port and add it to a
topology, and do nothing more. Similarly, drm_dp_update_port() would be
assumed to be the function that should be used to update port
information after initia
https://bugs.freedesktop.org/show_bug.cgi?id=109389
--- Comment #5 from Czcibor Bohusz-Dobosz ---
Created attachment 145256
--> https://bugs.freedesktop.org/attachment.cgi?id=145256&action=edit
Galactic Civilizations III memleak log with DXVK
For comparison, I also attach a similar log that I
Turns out we've been forgetting for a while now to actually destroy any
of the mutexes that we create in drm_dp_mst_topology_mgr. So, let's do
that.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_to
Since we're going to be reprobing the entire topology state on resume
now using sideband transactions, we need to ensure that we actually have
short HPD irqs enabled before calling drm_dp_mst_topology_mgr_resume().
So, do that.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
C
Which reduces indentation and makes this function more legible.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 90 +--
1 file changed, 45 insertions(+), 45 delet
There's a couple of changes here, so to summarize:
* Remove the big ugly mgr->up_req_recv.have_eomt conditional to save on
indenting
* Store &mgr->up_req_recv.initial_hdr in a variable so we don't keep
going over 80 character long lines
* De-duplicate code for calling drm_dp_send_up_ack_reply(
Declare local pointer to the drm_dp_link_address_ack_reply struct
instead of constantly dereferencing it through the union in
txmsg->reply. Then, invert the order of conditionals so we don't have to
do the bulk of the work inside them, and can wrap lines even less. Then
finally, rearrange variable
This will allow us to add some locking for port->* members, in
particular the PDT and ->connector, which can't be done from
drm_dp_destroy_port() since we don't know what locks the caller might be
holding.
Changes since v2:
* Clarify commit message
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Since we're going to be implementing suspend/resume reprobing very soon,
we need to make sure we are extra careful to ensure that our locking
actually protects the topology state where we expect it to. Turns out
this isn't the case with drm_dp_port_setup_pdt() and
drm_dp_port_teardown_pdt(), both o
And it's helper, we'll be using this in just a moment.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/d
These are most certainly accessed from far more than the mgr work. In
fact, up_req_recv is -only- ever accessed from outside the mgr work.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Signed-off-by: Lyude Paul
---
include/drm/drm_dp_mst_helper.h | 8 ++-
Unfortunately the DP MST helpers do not have much in the way of
debugging utilities. So, let's add some!
This adds basic debugging output for down sideband requests that we send
from the driver, so that we can actually discern what's happening when
sideband requests timeout.
Since there wasn't re
Makes things easier to read.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Reviewed-by: Daniel Vetter
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 35 ++-
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/driv
* Remove the big ugly have_eomt conditional
* Store &mgr->down_rep_recv.initial_hdr in a var to make line wrapping
easier
* Remove duplicate memset() calls
* Actually wrap lines
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Reviewed-by: Daniel Vetter
Signed-off-by: Lyude
Use more pointers so we don't have to write out
txmsg->reply.u.path_resources each time. Also, fix line wrapping +
rearrange local variables.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Reviewed-by: Daniel Vetter
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_
Noticed this while working on adding a drm_dp_decode_sideband_req().
DP_POWER_DOWN_PHY/DP_POWER_UP_PHY both use the same struct, so we can
just combine their cases.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
---
drivers/gpu/d
Yes, apparently we've been testing this for every single driver load for
quite a long time now. At least that means our PBN calculation is solid!
Anyway, introduce self tests for MST and move this into there.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Reviewed-by: Daniel
When reprobing an MST topology during resume, we have to account for the
fact that while we were suspended it's possible that mstbs may have been
removed from any ports in the topology. Since iterating downwards in the
topology requires that we hold &mgr->lock, destroying MSTBs from this
context wo
This seems to be some leftover detritus from before the port/mstb kref
cleanup and doesn't do anything anymore, so get rid of it.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Reviewed-by: Daniel Vetter
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c |
A simple convienence function that returns a drm_printer which prints
using pr_err()
Changes since v1:
* Make __drm_printfn_err() more consistent with DRM_ERROR() - danvet
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Reviewed-by: Daniel Vetter
Signed-off-by: Lyude Paul
-
This is the large series for adding MST suspend/resume reprobing that
I've been working on for quite a while now. In addition, I:
- Refactored and cleaned up any code I ended up digging through in the
process of understanding how some parts of these helpers worked.
- Added some debugging tools a
On 9/3/19 6:22 PM, Christoph Hellwig wrote:
On Tue, Sep 03, 2019 at 04:32:45PM +0200, Thomas Hellström (VMware) wrote:
Is this a layer violation concern, that is, would you be ok with a similar
helper for TTM, or is it that you want to force the graphics drivers into
adhering strictly to the DMA
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #64 from tempel.jul...@gmail.com ---
I can try that. But I really wonder why there are differences between systems
showing the issue or not.
--
You are receiving this mail because:
You are the assignee for the bug.__
On Tue, Sep 3, 2019 at 4:12 PM Daniel Vetter wrote:
> On Tue, Sep 3, 2019 at 9:45 PM Kenny Ho wrote:
> > On Tue, Sep 3, 2019 at 3:57 AM Daniel Vetter wrote:
> > > Iterating over minors for cgroups sounds very, very wrong. Why do we care
> > > whether a buffer was allocated through kms dumb vs re
https://bugs.freedesktop.org/show_bug.cgi?id=109389
--- Comment #4 from Czcibor Bohusz-Dobosz ---
Created attachment 145255
--> https://bugs.freedesktop.org/attachment.cgi?id=145255&action=edit
Galactic Civilizations III memleak log without DXVK
As far as I'm understanding the logs that I've g
On Thu, Aug 29, 2019 at 09:45:15AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> With atomic commit, ->prepare_commit() and ->complete_commit() may not
> be evenly balanced (although ->complete_commit() will complete each
> crtc that had been previously prepared). So these will no longer be
> a
On 9/3/19 9:55 PM, Dave Hansen wrote:
On 9/3/19 12:51 PM, Daniel Vetter wrote:
The thing we need to stop is having mixed encryption rules under one VMA.
The point here is that we want this. We need to be able to move the
buffer between device ptes and system memory ptes, transparently,
behind u
On Thu, Aug 29, 2019 at 09:45:13AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Prep work for async commits, in which case this will be called after we
> no longer have the atomic state object.
>
> This drops some wait_for_vblanks(), but those should be unnecessary, as
> we call this after wait
On Thu, Aug 29, 2019 at 09:45:14AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Add ->flush_commit(crtc_mask). Currently a no-op, but kms backends
> should migrate writing flush registers to this hook, so we can decouple
> pushing updates to hardware, and flushing the updates.
>
> Once we add
On 2019-09-03 20:08, Jernej Škrabec wrote:
> Hi!
>
> Dne torek, 03. september 2019 ob 20:00:33 CEST je Neil Armstrong napisal(a):
>> Hi,
>>
>> Le 03/09/2019 à 11:53, Neil Armstrong a écrit :
>>> Hi,
>>>
>>> On 03/09/2019 07:51, Cheng-Yi Chiang wrote:
From: Yakir Yang
When transmitti
On Sun, Sep 1, 2019 at 10:28 PM Gerd Hoffmann wrote:
>
> On Fri, Aug 30, 2019 at 10:49:25AM -0700, David Riley wrote:
> > Hi Gerd,
> >
> > On Fri, Aug 30, 2019 at 4:16 AM Gerd Hoffmann wrote:
> > >
> > > Hi,
> > >
> > > > > > - kfree(vbuf->data_buf);
> > > > > > + kvfree(vbuf->data_buf)
On Tue, Sep 3, 2019 at 8:07 PM Mikhail Gavrilov
wrote:
>
> On Tue, 3 Sep 2019 at 13:21, Hillf Danton wrote:
> >
> > Describe the problems you are experiencing please.
> > Say is the screen locked up? Machine lockedup?
> > Anything unnormal after you see the warning?
> >
>
> According to my observ
On Tue, Sep 3, 2019 at 10:01 PM Sasha Levin wrote:
>
> On Tue, Sep 03, 2019 at 07:03:47PM +0200, Greg KH wrote:
> >On Tue, Sep 03, 2019 at 06:40:43PM +0200, Michel Dänzer wrote:
> >> On 2019-09-03 6:23 p.m., Sasha Levin wrote:
> >> > From: Yu Zhao
> >> >
> >> > [ Upstream commit 89f23b6efef554766
On Tue, Sep 3, 2019 at 9:45 PM Kenny Ho wrote:
>
> On Tue, Sep 3, 2019 at 3:57 AM Daniel Vetter wrote:
> >
> > On Thu, Aug 29, 2019 at 02:05:18AM -0400, Kenny Ho wrote:
> > > To allow other subsystems to iterate through all stored DRM minors and
> > > act upon them.
> > >
> > > Also exposes drm_m
On Tue, Sep 03, 2019 at 07:03:47PM +0200, Greg KH wrote:
On Tue, Sep 03, 2019 at 06:40:43PM +0200, Michel Dänzer wrote:
On 2019-09-03 6:23 p.m., Sasha Levin wrote:
> From: Yu Zhao
>
> [ Upstream commit 89f23b6efef554766177bf51aa754bce14c3e7da ]
Hold your horses!
This commit and c4a32b266da7bb
On 9/3/19 12:51 PM, Daniel Vetter wrote:
>> The thing we need to stop is having mixed encryption rules under one VMA.
> The point here is that we want this. We need to be able to move the
> buffer between device ptes and system memory ptes, transparently,
> behind userspace back, without races. And
https://bugzilla.kernel.org/show_bug.cgi?id=203781
sehell...@gmail.com changed:
What|Removed |Added
Kernel Version|5.3-rc6, 5.2.x, 5.1.x |5.3-rc7, 5.2.x, 5.1.x
--
You are r
On Tue, Sep 3, 2019 at 9:38 PM Dave Hansen wrote:
>
> This whole thing looks like a fascinating collection of hacks. :)
>
> ttm is taking a stack-alllocated "VMA" and handing it to vmf_insert_*()
> which obviously are expecting "real" VMAs that are linked into the mm.
> It's extracting some pgprot
On Tue, Sep 3, 2019 at 8:50 PM Tejun Heo wrote:
>
> Hello, Daniel.
>
> On Tue, Sep 03, 2019 at 09:55:50AM +0200, Daniel Vetter wrote:
> > > * While breaking up and applying control to different types of
> > > internal objects may seem attractive to folks who work day in and
> > > day out with
On Tue, Sep 3, 2019 at 3:57 AM Daniel Vetter wrote:
>
> On Thu, Aug 29, 2019 at 02:05:18AM -0400, Kenny Ho wrote:
> > To allow other subsystems to iterate through all stored DRM minors and
> > act upon them.
> >
> > Also exposes drm_minor_acquire and drm_minor_release for other subsystem
> > to ha
This whole thing looks like a fascinating collection of hacks. :)
ttm is taking a stack-alllocated "VMA" and handing it to vmf_insert_*()
which obviously are expecting "real" VMAs that are linked into the mm.
It's extracting some pgprot_t information from the real VMA, making a
psuedo-temporary VM
Hi Jonathan,
On Tue, Sep 3, 2019 at 4:25 PM Jonathan Marek wrote:
>
> Hi,
>
> I tried this and it works with patches 4+5 from Rob's series and
> changing gpummu to use sg_phys(sg) instead of sg->dma_address
> (dma_address isn't set now that dma_map_sg isn't used).
Thanks for testing it. I haven'
1 - 100 of 255 matches
Mail list logo
