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(-)
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 ++
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
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:
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
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
---
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
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
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=edit
The previous dmesg.txt has messages been overwriten. from the dmesg-full.txt
can see more information
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
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:
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
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]
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]
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://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
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
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
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,
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
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
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
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
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
> ---
>
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
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=edit
.config file
--
You are receiving this mail because:
You are watching the assignee of the bug.
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.
--
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
https://bugzilla.kernel.org/show_bug.cgi?id=204725
Dmitri Seletski (drj...@gmail.com) changed:
What|Removed |Added
URL|
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
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
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 --
>
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
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
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
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,
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
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
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
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
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
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
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=edit
Galactic Civilizations III memleak log with DXVK
For comparison, I also attach a similar log that I made
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
---
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
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
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 >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
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
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
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
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
* Remove the big ugly have_eomt conditional
* Store >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 Paul
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
---
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
---
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:
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 >lock, destroying MSTBs from this
context would
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
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
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
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
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=edit
Galactic Civilizations III memleak log without DXVK
As far as I'm understanding the logs that I've gotten,
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
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
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
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);
> > > > > > +
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
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
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
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
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.
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
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
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
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
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
On Tue, Sep 3, 2019 at 5:20 AM Daniel Vetter wrote:
>
> On Tue, Sep 3, 2019 at 10:24 AM Koenig, Christian
> wrote:
> >
> > Am 03.09.19 um 10:02 schrieb Daniel Vetter:
> > > On Thu, Aug 29, 2019 at 02:05:17AM -0400, Kenny Ho wrote:
> > >> With this RFC v4, I am hoping to have some consensus on a
Hi Tejun,
Thanks for looking into this. I can definitely help where I can and I
am sure other experts will jump in if I start misrepresenting the
reality :) (as Daniel already have done.)
Regarding your points, my understanding is that there isn't really a
TTM vs GEM situation anymore (there is
The -modesetting ddx has a totally broken idea of how atomic works:
- doesn't disable old connectors, assuming they get auto-disable like
with the legacy setcrtc
- assumes ASYNC_FLIP is wired through for the atomic ioctl
- not a single call to TEST_ONLY
Iow the implementation is a 1:1
It's never been wired up. Only userspace that tried to use it (and
didn't actually check whether anything works, but hey it builds) is
the -modesetting atomic implementation. And we just shut that up.
If there's anyone else then we need to silently accept this flag no
matter what, and find a new
It's the only flag anyone actually cares about. Plus if we're unlucky,
the atomic ioctl might need a different flag for async flips. So
better to abstract this away from the uapi a bit.
Cc: Maarten Lankhorst
Cc: Michel Dänzer
Cc: Alex Deucher
Cc: Adam Jackson
Cc: Sean Paul
Cc: David Airlie
---
drivers/gpu/drm/drm_ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 3c015dd3c94b..1cb7b4c3c87c 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -335,7 +335,7 @@
https://bugs.freedesktop.org/show_bug.cgi?id=111229
--- Comment #9 from weden...@yandex.ru ---
I'll do more testing, but it seems that unbind works with kernel 5.3-rc7.
There is still this error in the log:
[drm:amdgpu_pci_remove [amdgpu]] *ERROR* Device removal is currently not
supported
It's never been wired up. Only userspace that tried to use it (and
didn't actually check whether anything works, but hey it builds) is
the -modesetting atomic implementation. And we just shut that up.
If there's anyone else then we need to silently accept this flag no
matter what, and find a new
It's the only flag anyone actually cares about. Plus if we're unlucky,
the atomic ioctl might need a different flag for async flips. So
better to abstract this away from the uapi a bit.
Cc: Maarten Lankhorst
Cc: Michel Dänzer
Cc: Alex Deucher
Cc: Adam Jackson
Cc: Sean Paul
Cc: David Airlie
1 - 100 of 254 matches
Mail list logo
