https://bugs.freedesktop.org/show_bug.cgi?id=107518
--- Comment #6 from Shawn Anastasio ---
Could you point me towards the applicable routines that perform the reset on
hibernate? They may provide some more insight into the situation.
--
You are receiving this mail because:
You are the assignee
On Fri, Jul 27, 2018 at 02:54:40PM +0300, Anton Vasilyev wrote:
> If qxl_device_init fails on creating resources and does not report it,
> then qxl module will catch null pointer exception on remove, or on
> probe's error path.
>
> The patch adds error path with resources release into qxl_device_i
On Fri, Jul 20, 2018 at 01:27:43PM +0200, Thomas Zimmermann wrote:
> In the Cirrus driver, the regular clean-up code also performs the clean-up
> of a failed initialization. If the fbdev's framebuffer was not initialized,
> the clean-up will fail within drm_framebuffer_unregister_private. Booting
>
On Tue, Aug 07, 2018 at 07:36:47PM +0100, Chris Wilson wrote:
> Since commit 9ea0dfbf972 ("dma-buf: make map_atomic and map function
> pointers optional"), the core provides the no-op functions when map and
> map_atomic are not provided, so we no longer need assert that are
> supplied by a dma-buf
Hi Thierry/Sean
Thanks for your comments.
Yes, I agree with you as well at the moment the generic "truly,nt35597"
string doesnt have enough information to support multiple panels.
I am more comfortable renaming the compatible to
"qcom,sdm845-mtp-2k-display" as we have all the pieces needed f
>
> I've resent the pull requests with the missing [GIT PULL] tag added,
> sorry for the noise.
>
Since we are at -rc8 and this is late, I've just dropped these fixes
into drm-next, once they land in Linus,
you might want to nominate for stable, but I'd like to avoid sending
Linus anything non-wor
https://bugs.freedesktop.org/show_bug.cgi?id=107538
Bug ID: 107538
Summary: Intel-gpu-tools 1.23 tag fails compilation on Clang
due to implicit declaration of function
Product: DRI
Version: XOrg git
Hardware: All
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: b4941f6ef111906b39a86f5b912f72e519c97a98
commit: beee6f9526180c5505d96d152b030b4ca495a7d1 [1/3] drm/amdgpu/pp: endian
fixes for process_pptables_v1_0.c
reproduce:
# apt-get install sparse
git checkou
msm_drm.h file derived from drm-next kernel uapi header.
Remove freedreno/msm/msm_drm.h to maintain only
one copy of msm_drm.h and change freedreno Makefile
accordingly.
Signed-off-by: Tanmay Shah
---
Makefile.sources | 1 +
freedreno/Makefile.sources | 1 -
Hi, this is an automated email from Rob's (experimental) review bot. I
found a couple of common problems with your patch. Please see below.
On Wed, 1 Aug 2018 20:51:28 +0200, Maxime Jourdan wrote:
> This removes the meson_canvas files within the meson/drm layer
> and makes use of the new canvas m
Hi, this is an automated email from Rob's (experimental) review bot. I
found a couple of common problems with your patch. Please see below.
On Mon, 30 Jul 2018 10:11:23 +0200, Enric Balletbo i Serra wrote:
> From: Lin Huang
>
> These are required to support DDR DVFS on rk3399 platform. The patch
Currently, nouveau will re-write the DP_MSTM_CTRL register for an MST
hub every time it receives a long HPD pulse on DP. This isn't actually
necessary and additionally, has some unintended side effects.
With the P50 I've got here, rewriting DP_MSTM_CTRL constantly seems to
make it rather likely (1
When probing a new MST device, it's not safe to make any assumptions
about it's current state. While most well mannered MST hubs will just
disable the branching unit on hotplug disconnects, this isn't enough to
save us from various other scenarios that might have resulted in
something writing to th
This fixes some annoying issues on the P50-P52 with displays not being
detected if they aren't plugged in at boot, and sometimes even when they
are plugged in at boot.
See: https://bugzilla.redhat.com/show_bug.cgi?id=1477182
Lyude Paul (2):
drm/nouveau: Only write DP_MSTM_CTRL when needed
drm
https://bugs.freedesktop.org/show_bug.cgi?id=107536
dwagner changed:
What|Removed |Added
Severity|blocker |major
--
You are receiving this mail because
https://bugs.freedesktop.org/show_bug.cgi?id=107536
--- Comment #2 from dwagner ---
Created attachment 141029
--> https://bugs.freedesktop.org/attachment.cgi?id=141029&action=edit
X11 log
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=107536
--- Comment #1 from dwagner ---
Created attachment 141028
--> https://bugs.freedesktop.org/attachment.cgi?id=141028&action=edit
dmesg, ending at crash
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=107536
Bug ID: 107536
Summary: gfx_v8_0_priv_reg_irq [amdgpu]] *ERROR* Illegal
register access in command stream
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=107152
dwagner changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #38 from dwagner ---
*** Bug 107152 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri
https://bugs.freedesktop.org/show_bug.cgi?id=106529
--- Comment #1 from Mariusz Mazur ---
I've tried the same thing with only the DP ultrawide monitor connected and got
the same issue. dc logs, reading code and some kernel tracers (ftrace) on DC
link training code basically tell me that the impor
https://bugs.freedesktop.org/show_bug.cgi?id=106529
Mariusz Mazur changed:
What|Removed |Added
Summary|Kernels 4.16+ confuse KDE |dc=1 kernels somehow
https://bugs.freedesktop.org/show_bug.cgi?id=104300
--- Comment #8 from Mariusz Mazur ---
Ok, I've managed to narrow down my issue to displayport link training code
somehow triggering a monitor disconnect while attempting to wake it up. So my
issue is completely unrelated, none of my comments her
Hi Dave,
More fixes for 4.19:
- Fixes for scheduler
- Fix for SR-IOV
- Fixes for display
The following changes since commit df36b2fb8390d98453fff1aae3927095fe9ff36c:
drm/ttm: clean up non-x86 definitions on ttm_tt (2018-08-01 17:23:56 -0500)
are available in the git repository at:
git://pe
Reviewed-by: Andrey Grodzovsky
But I still have questions about entity->last_user (didn't notice this
before) -
Looks to me there is a race condition with it's current usage, let's say
process A was preempted after doing drm_sched_entity_flush->cmpxchg(...)
now process B working on same
On Wed, 2018-08-08 at 22:41 -0700, Rodrigo Vivi wrote:
> One more CFL ID added to spec.
>
> Align with kernel commit d0e062ebb3a4 ("drm/i915/cfl:
> Add a new CFL PCI ID.")
>
Reviewed-by: José Roberto de Souza
> Cc: José Roberto de Souza
> Signed-off-by: Rodrigo Vivi
> ---
> intel/intel_chip
https://bugs.freedesktop.org/show_bug.cgi?id=100189
--- Comment #16 from Francesco Turco ---
I did a git bisect too, and I get the same bad commit as in comment 7.
I'm trying to build Mesa with Gallium for Intel/i915. But recent versions of
Mesa make my web browser Falkon crash at startup.
--
On Thu, Aug 09, 2018 at 12:53:49PM +0200, Thierry Reding wrote:
> On Fri, Aug 03, 2018 at 01:03:45PM +0200, Linus Walleij wrote:
> > On Fri, Aug 3, 2018 at 4:49 AM Abhinav Kumar
> > wrote:
> >
> > Hi Abhinav,
> >
> > > From: "abhin...@codeaurora.org"
> > >
> > > Add support for Truly NT35597 p
On 08/06/2018 04:14 AM, Christian König wrote:
Am 03.08.2018 um 20:41 schrieb Andrey Grodzovsky:
On 08/06/2018 08:44 AM, Christian König wrote:
Am 03.08.2018 um 16:54 schrieb Andrey Grodzovsky:
[SNIP]
>
> Second of all, even after we removed the entity from rq in
> drm_s
https://bugs.freedesktop.org/show_bug.cgi?id=87278
Julien Isorce changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=107152
--- Comment #13 from Andrey Grodzovsky ---
(In reply to dwagner from comment #12)
> Indeed, I found my theory confirmed by many experiments: If I use a script
> like
> > #!/bin/bash
> > cd /sys/class/drm/card0/device
> > echo manual >power_dpm_f
Hi
Am 09.08.2018 um 17:27 schrieb Gerd Hoffmann:
>> diff --git a/drivers/gpu/drm/bochs/bochs_mm.c
>> b/drivers/gpu/drm/bochs/bochs_mm.c
>> index 39cd08416773..c9c7097030ca 100644
>> --- a/drivers/gpu/drm/bochs/bochs_mm.c
>> +++ b/drivers/gpu/drm/bochs/bochs_mm.c
>> @@ -430,7 +430,7 @@ static void
https://bugs.freedesktop.org/show_bug.cgi?id=104481
--- Comment #6 from Luis Mendes ---
(In reply to Julien Isorce from comment #5)
> (In reply to Luis Mendes from comment #0)
> > I can also provide the apitrace trace file, but it takes around 1GB of data.
>
> Just provide it through google driv
> diff --git a/drivers/gpu/drm/qxl/qxl_gem.c b/drivers/gpu/drm/qxl/qxl_gem.c
> index f5c1e7872e92..89606c819d82 100644
> --- a/drivers/gpu/drm/qxl/qxl_gem.c
> +++ b/drivers/gpu/drm/qxl/qxl_gem.c
> @@ -40,7 +40,7 @@ void qxl_gem_object_free(struct drm_gem_object *gobj)
> qxl_surface_evict(qdev
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/cirrus/cirrus_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c
> b/drivers/gpu/drm/cirrus/cirrus_main.c
> index 60d54e10a34d..57f8fe6d020b 100644
> --- a/drivers/gpu/dr
> diff --git a/drivers/gpu/drm/bochs/bochs_mm.c
> b/drivers/gpu/drm/bochs/bochs_mm.c
> index 39cd08416773..c9c7097030ca 100644
> --- a/drivers/gpu/drm/bochs/bochs_mm.c
> +++ b/drivers/gpu/drm/bochs/bochs_mm.c
> @@ -430,7 +430,7 @@ static void bochs_bo_unref(struct bochs_bo **bo)
> re
https://bugs.freedesktop.org/show_bug.cgi?id=104481
--- Comment #5 from Julien Isorce ---
(In reply to Luis Mendes from comment #0)
> I can also provide the apitrace trace file, but it takes around 1GB of data.
Just provide it through google drive or other similar way, see
https://bugs.freedeskt
Am 09.08.2018 um 16:22 schrieb Daniel Vetter:
On Thu, Aug 9, 2018 at 3:58 PM, Christian König
wrote:
Am 09.08.2018 um 15:38 schrieb Daniel Vetter:
On Thu, Aug 09, 2018 at 01:37:07PM +0200, Christian König wrote:
[SNIP]
See to me the explicit fence in the reservation object is not even remotel
On Thu, Aug 9, 2018 at 3:58 PM, Christian König
wrote:
> Am 09.08.2018 um 15:38 schrieb Daniel Vetter:
>>
>> On Thu, Aug 09, 2018 at 01:37:07PM +0200, Christian König wrote:
>>>
>>> Hi everyone,
>>>
>>> This set of patches tries to improve read after write hazard handling
>>> for reservation objec
On Thu, Aug 09, 2018 at 04:46:55PM +0300, Dmitry Osipenko wrote:
> On Thursday, 9 August 2018 16:10:35 MSK Thierry Reding wrote:
> > On Thu, Aug 09, 2018 at 03:53:03PM +0300, Dmitry Osipenko wrote:
> > > On Thursday, 9 August 2018 13:45:41 MSK Thierry Reding wrote:
> > > > On Fri, Aug 03, 2018 at 0
On Thu, Aug 9, 2018 at 5:48 AM, Nayan Deshmukh
wrote:
> We no longer have sched parameter so remove its description
> as well
>
> Signed-off-by: Nayan Deshmukh
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/scheduler/gpu_scheduler.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/
Am 09.08.2018 um 15:38 schrieb Daniel Vetter:
On Thu, Aug 09, 2018 at 01:37:07PM +0200, Christian König wrote:
Hi everyone,
This set of patches tries to improve read after write hazard handling
for reservation objects.
It allows us to specify for each shared fence if it represents a write
oper
On Thu, Aug 09, 2018 at 01:37:07PM +0200, Christian König wrote:
> Hi everyone,
>
> This set of patches tries to improve read after write hazard handling
> for reservation objects.
>
> It allows us to specify for each shared fence if it represents a write
> operation.
>
> Based on this the i915
On Thu, Aug 9, 2018 at 1:42 PM, Hans de Goede wrote:
> Taking over the console involves allocating mem with GFP_KERNEL, talking
> to drm drivers, etc. So this should not be done from an atomic context.
>
> But the console-output trigger deferred console takeover may happen from an
> atomic context
On Thu, Aug 09, 2018 at 03:53:03PM +0300, Dmitry Osipenko wrote:
> On Thursday, 9 August 2018 13:45:41 MSK Thierry Reding wrote:
> > On Fri, Aug 03, 2018 at 02:30:47PM +0300, Dmitry Osipenko wrote:
> > > On Friday, 3 August 2018 13:50:55 MSK Thierry Reding wrote:
> > > > On Wed, Aug 01, 2018 at 06:
Quoting Daniel Vetter (2018-08-09 13:45:44)
> dma_fence_default_wait is the default now, same for the trivial
> enable_signaling implementation.
>
> Also remove the ->signaled callback, vgem can't peek ahead with a
> fastpath, returning false is the default implementation.
>
> v2: Protect the mea
On Mon, Jul 16, 2018 at 09:46:24AM +0200, Thomas Zimmermann wrote:
> This patch unifies the naming of DRM functions for reference counting
> of struct drm_device. The resulting code is more aligned with the rest
> of the Linux kernel interfaces.
>
> Signed-off-by: Thomas Zimmermann
Applied to dr
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Also remove the ->signaled callback, vgem can't peek ahead with a
fastpath, returning false is the default implementation.
v2: Protect the meaningful space! (Chris)
Signed-off-by: Daniel Vetter
Cc:
Am 09.08.2018 um 14:25 schrieb Huang Rui:
On Thu, Aug 09, 2018 at 03:18:55PM +0800, Koenig, Christian wrote:
Am 09.08.2018 um 08:18 schrieb Huang Rui:
On Wed, Aug 08, 2018 at 06:47:49PM +0800, Christian König wrote:
Am 08.08.2018 um 11:59 schrieb Huang Rui:
I continue to work for bulk moving
On Thu, Aug 09, 2018 at 03:18:55PM +0800, Koenig, Christian wrote:
> Am 09.08.2018 um 08:18 schrieb Huang Rui:
> > On Wed, Aug 08, 2018 at 06:47:49PM +0800, Christian König wrote:
> >> Am 08.08.2018 um 11:59 schrieb Huang Rui:
> >>> I continue to work for bulk moving that based on the proposal by
Am 09.08.2018 um 14:08 schrieb Chris Wilson:
Quoting Christian König (2018-08-09 12:37:08)
void reservation_object_add_shared_fence(struct reservation_object *obj,
struct dma_fence *fence)
{
- struct reservation_object_list *old, *fobj = obj->s
https://bugs.freedesktop.org/show_bug.cgi?id=105684
--- Comment #43 from Paul Menzel ---
I just tried with Linux master, and the page fault didn’t happen anymore.
/boot/config-4.18.0-rc8-4-gfedb8da96355:CONFIG_SLAB_FREELIST_HARDENED=y
Out of curiosity, I’ll try to bisect this.
--
You
Quoting Christian König (2018-08-09 12:37:08)
> void reservation_object_add_shared_fence(struct reservation_object *obj,
> struct dma_fence *fence)
> {
> - struct reservation_object_list *old, *fobj = obj->staged;
> + struct reservation_object_
Taking over the console involves allocating mem with GFP_KERNEL, talking
to drm drivers, etc. So this should not be done from an atomic context.
But the console-output trigger deferred console takeover may happen from an
atomic context, which leads to "BUG: sleeping function called from invalid
co
Add a helper to access the shared fences in an reservation object.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 7 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 3 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 ++--
drivers/gpu/
We now note that all fences are potential writers.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 -
Wait for all write operations before page flipping.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/intel_display.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display
Note if the added fence is a write by using the lsb in the fenc pointer.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c| 8 +++-
drivers/dma-buf/reservation.c| 59 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
That allows us to only retreive fences of write operations.
Signed-off-by: Christian König
---
drivers/dma-buf/reservation.c| 19 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 3 ++-
drivers/gpu/drm/amd/
No need for that any more. Just replace the list when there isn't enough
room any more for at least one additional fence.
Signed-off-by: Christian König
---
drivers/dma-buf/reservation.c | 180 ++
include/linux/reservation.h | 4 -
2 files changed, 60
Hi everyone,
This set of patches tries to improve read after write hazard handling for
reservation objects.
It allows us to specify for each shared fence if it represents a write
operation.
Based on this the i915 driver is modified to always wait for all writes before
pageflip and the previou
Hi,
On 09-08-18 12:03, Bartlomiej Zolnierkiewicz wrote:
On Monday, August 06, 2018 05:54:16 PM Hans de Goede wrote:
Taking over the console involves allocating mem with GFP_KERNEL, talking
to drm drivers, etc. So this should not be done from an atomic context.
But the console-output trigger de
The hotplug detection routine of i915 uses drm_helper_hpd_irq_event(). This
helper can detect changing of status of connector, but it can not detect
changing of edid.
Following scenario requires detection of changing of edid.
1) plug display device to a connector
2) system suspend
3) unplug 1)
On Fri, Aug 03, 2018 at 01:03:45PM +0200, Linus Walleij wrote:
> On Fri, Aug 3, 2018 at 4:49 AM Abhinav Kumar wrote:
>
> Hi Abhinav,
>
> > From: "abhin...@codeaurora.org"
> >
> > Add support for Truly NT35597 panel used
> > in MSM reference platforms.
> >
> > This panel supports both single DSI
On Fri, Aug 03, 2018 at 02:30:47PM +0300, Dmitry Osipenko wrote:
> On Friday, 3 August 2018 13:50:55 MSK Thierry Reding wrote:
> > On Wed, Aug 01, 2018 at 06:08:07PM +0300, Dmitry Osipenko wrote:
> > > From time to time new bugs are popping up, causing some host1x client to
> > > fail its initializ
On Monday, August 06, 2018 05:54:16 PM Hans de Goede wrote:
> Taking over the console involves allocating mem with GFP_KERNEL, talking
> to drm drivers, etc. So this should not be done from an atomic context.
>
> But the console-output trigger deferred console takeover may happen from an
> atomic
On Fri, Jun 15, 2018 at 03:37:49PM -0700, Nick Desaulniers wrote:
> Fixes commit 8cfe83419cdb ("drm/panel: simple: Add
> support for KEO TX31D200VM0BAA")
>
> drivers/gpu/drm/panel/panel-simple.c:1250:27: warning: implicit conversion
> from
> 'double' to 'u32' (aka 'unsigned int') changes va
https://bugs.freedesktop.org/show_bug.cgi?id=105684
--- Comment #42 from jian-h...@endlessm.com ---
(In reply to Vlastimil Babka from comment #41)
> (In reply to jian-hong from comment #40)
> > Created attachment 140819 [details]
> > 4.18.0-rc6 Build config file
>
> Paul Menzel posted this bug to
We no longer have sched parameter so remove its description
as well
Signed-off-by: Nayan Deshmukh
---
drivers/gpu/drm/scheduler/gpu_scheduler.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index bfa8
On 08/08/18 23:47, Jordan Crouse wrote:
Add the nodes to describe the Adreno GPU and GMU devices.
Signed-off-by: Jordan Crouse
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 121 +++
1 file changed, 121 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/a
Hi Daniel,
On Thu, Aug 9, 2018 at 2:27 PM Daniel Vetter wrote:
>
> On Fri, Jul 20, 2018 at 2:21 PM, Nayan Deshmukh
> wrote:
> > entity has a scheduler field and we don't need the sched argument
> > in any of the functions where entity is provided.
> >
> > Signed-off-by: Nayan Deshmukh
>
> This
On Fri, Jul 20, 2018 at 2:21 PM, Nayan Deshmukh
wrote:
> entity has a scheduler field and we don't need the sched argument
> in any of the functions where entity is provided.
>
> Signed-off-by: Nayan Deshmukh
This breaks the make htmldocs build a bit:
./drivers/gpu/drm/scheduler/gpu_scheduler.c
On Thu, Apr 26, 2018 at 10:07 AM, Jyri Sarha wrote:
> Add device_link from panel device (supplier) to drm device (consumer)
> when drm_panel_attach() is called. This patch should protect the
> master drm driver if an attached panel driver unbinds while it is in
> use. The device_link should make s
Quoting Daniel Vetter (2018-08-09 09:33:49)
> On Wed, Jul 04, 2018 at 11:29:08AM +0200, Daniel Vetter wrote:
> > static void vgem_fence_release(struct dma_fence *base)
> > {
> > struct vgem_fence *fence = container_of(base, typeof(*fence), base);
> > @@ -76,11 +66,7 @@ static void vgem_fenc
On Wed, Jul 04, 2018 at 11:29:08AM +0200, Daniel Vetter wrote:
> dma_fence_default_wait is the default now, same for the trivial
> enable_signaling implementation.
>
> Also remove the ->signaled callback, vgem can't peek ahead with a
> fastpath, returning false is the default implementation.
>
>
https://bugzilla.kernel.org/show_bug.cgi?id=198123
--- Comment #49 from Daniel Vetter (dan...@ffwll.ch) ---
Created attachment 25
--> https://bugzilla.kernel.org/attachment.cgi?id=25&action=edit
insert huge sleep into lut load path
Maybe this helps in blowing up the race and perhaps she
https://bugs.freedesktop.org/show_bug.cgi?id=105684
Vlastimil Babka changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
Am 09.08.2018 um 08:18 schrieb Huang Rui:
On Wed, Aug 08, 2018 at 06:47:49PM +0800, Christian König wrote:
Am 08.08.2018 um 11:59 schrieb Huang Rui:
I continue to work for bulk moving that based on the proposal by Christian.
Background:
amdgpu driver will move all PD/PT and PerVM BOs into idle
78 matches
Mail list logo
