https://bugs.freedesktop.org/show_bug.cgi?id=109345
--- Comment #44 from Allan Cairns ---
Created attachment 144231
--> https://bugs.freedesktop.org/attachment.cgi?id=144231=edit
Log for Good
These are the logs for the bisects that booted to Firepro (2nd Card)
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=109345
--- Comment #43 from Allan Cairns ---
Created attachment 144230
--> https://bugs.freedesktop.org/attachment.cgi?id=144230=edit
Log for bad
Christian provided bisect kernels (DRM1 to 11). These examples booted to
Southern Island card (1st
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.2-wip
head: a6be3268e01a878e00f88555d16d65f88471d9e9
commit: 13688847c9d85d358d30dc4d6b128a42c6448106 [94/126] drm/scheduler: rework
job destruction
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gnu-gcc
Hi,
This patch series doesn't help with the OOM errors due to GDS. Reproducible
with:
AMD_DEBUG=testgdsmm glxgears & AMD_DEBUG=testgdsmm glxgears
Marek
On Fri, May 10, 2019 at 10:13 AM Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> This avoids OOM situations when we have lots
https://bugs.freedesktop.org/show_bug.cgi?id=110214
--- Comment #91 from komqin...@zoho.eu ---
xfce4-terminal and Geany bugs seem to be this
https://bugs.freedesktop.org/show_bug.cgi?id=110355 and solved with mesa
19.0.4.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110371
--- Comment #10 from babblebo...@gmail.com ---
Best I can tell, and I may be wrong, the error checking code was moved from the
DC part straight into DRM which now replicates the exact bug which was reverted
by the above DC commits but were never
https://bugzilla.kernel.org/show_bug.cgi?id=203471
--- Comment #7 from Haxk20 (haxk...@gmail.com) ---
(In reply to Michel Dänzer from comment #3)
> Please attach the corresponding Xorg log file and the output of glxinfo
> (both with and without DRI_PRIME=1).
Is there anything more you need to
On Fri, May 10, 2019 at 5:13 AM Knut Omang wrote:
> On Fri, 2019-05-10 at 03:23 -0700, Brendan Higgins wrote:
> > > On Fri, May 10, 2019 at 7:49 AM Knut Omang wrote:
> > > >
> > > > On Thu, 2019-05-09 at 22:18 -0700, Frank Rowand wrote:
> > > > > On 5/9/19 4:40 PM, Logan Gunthorpe wrote:
> > > >
On Fri, May 10, 2019 at 07:53:23PM +, Kuehling, Felix wrote:
> From: Philip Yang
>
> While the page is migrating by NUMA balancing, HMM failed to detect this
> condition and still return the old page. Application will use the new
> page migrated, but driver pass the old page physical address
https://bugs.freedesktop.org/show_bug.cgi?id=110661
--- Comment #1 from u.ra...@gmail.com ---
Created attachment 144222
--> https://bugs.freedesktop.org/attachment.cgi?id=144222=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the
https://bugzilla.kernel.org/show_bug.cgi?id=202799
--- Comment #9 from Clément Guérin (li...@protonmail.com) ---
I'm still seeing this bug with linux 5.1.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=110661
Bug ID: 110661
Summary: RX480 idling at over 70°C
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity:
On Fri, May 10, 2019 at 07:53:24PM +, Kuehling, Felix wrote:
> Don't set this flag by default in hmm_vma_do_fault. It is set
> conditionally just a few lines below. Setting it unconditionally
> can lead to handle_mm_fault doing a non-blocking fault, returning
> -EBUSY and unlocking mmap_sem
https://bugs.freedesktop.org/show_bug.cgi?id=110661
--- Comment #2 from u.ra...@gmail.com ---
Created attachment 144223
--> https://bugs.freedesktop.org/attachment.cgi?id=144223=edit
Xorg log
--
You are receiving this mail because:
You are the assignee for the
Don't set this flag by default in hmm_vma_do_fault. It is set
conditionally just a few lines below. Setting it unconditionally
can lead to handle_mm_fault doing a non-blocking fault, returning
-EBUSY and unlocking mmap_sem unexpectedly.
Signed-off-by: Felix Kuehling
---
mm/hmm.c | 2 +-
1 file
These problems were found in AMD-internal testing as we're working on
adopting HMM. They are rebased against glisse/hmm-5.2-v3. We'd like to get
them applied to a mainline Linux kernel as well as drm-next and
amd-staging-drm-next sooner rather than later.
Currently the HMM in amd-staging-drm-next
From: Philip Yang
While the page is migrating by NUMA balancing, HMM failed to detect this
condition and still return the old page. Application will use the new
page migrated, but driver pass the old page physical address to GPU,
this crash the application later.
Use pte_protnone(pte) to return
On Fri, May 10, 2019 at 1:48 PM Koenig, Christian
wrote:
> Well another question is why do we want to prevent that in the first place?
>
> I mean the worst thing that can happen is that we account a BO multiple
> times.
That's one of the problems. The other one is the BO outliving the
lifetime
Am 10.05.19 um 17:25 schrieb Kenny Ho:
> [CAUTION: External Email]
>
> On Fri, May 10, 2019 at 11:08 AM Koenig, Christian
> wrote:
>> Am 10.05.19 um 16:57 schrieb Kenny Ho:
>>> On Fri, May 10, 2019 at 8:28 AM Christian König
>>> wrote:
Am 09.05.19 um 23:04 schrieb Kenny Ho:
>> So the drm
Am 10.05.19 um 17:07 schrieb Kenny Ho:
> [CAUTION: External Email]
>
> On Fri, May 10, 2019 at 8:31 AM Christian König
> wrote:
>> I think it is a good approach to try to add a global limit first and
>> when that's working go ahead with limiting device specific resources.
> What are some of the
The pull request you sent on Fri, 10 May 2019 18:50:23 +0200:
> https://github.com/bzolnier/linux.git tags/fbdev-v5.2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/cccd559e98c05b669bdc37b01802f920cff1d6dd
Thank you!
--
Deet-doot-dot, I am a bot.
Hi Linus,
Please pull fbdev changes for v5.2. They are:
- 4 small fixes for fb core
- updates for udlfb, sm712fb, macfb and atafb drivers
- redundant code removals from amba-clcd and atmel_lcdfb drivers
- minor fixes/cleanups for other fb drivers
Please see the signed tag description for
Dear Yannick,
Thank you for your patch,
In your patch, you have removed clk_disable() & clk_enable().
Could you please double confirm ?
thanks
Philippe :-)
On 5/10/19 5:03 PM, Yannick Fertré wrote:
> Clk_round_rate returns rounded clock without changing
> the hardware in any way.
> This
Dear Yannick,
Thank you for your patch,
Acked-by: Philippe Cornu
Dear Benjamin,
If you are fine with this patch, please push it *after* the patch named
"drm/stm: dsi: add support of an optional regulator" (if I well
understood those two patches)
Thank you
Philippe :-)
On 5/10/19 5:02 PM,
Dear Yannick,
Thank you for your patch,
Reviewed-by: Philippe Cornu
Philippe :-)
On 5/10/19 4:20 PM, Yannick Fertré wrote:
> The dsi physical layer is powered by the 1v8 power controller supply.
>
> Signed-off-by: Yannick Fertré
> ---
> arch/arm/boot/dts/stm32mp157c.dtsi | 1 +
> 1 file
Dear Yannick,
Thank you for your patch,
I like better the new shorter commit heading, thank you.
On 5/10/19 4:20 PM, Yannick Fertré wrote:
> Add support of an optional regulator for the phy part of the DSI
> controller.
>
> Signed-off-by: Yannick Fertré
> ---
>
On Fri, May 10, 2019 at 01:08:49PM +0200, Maxime Ripard wrote:
> So far, the drm_format_plane_cpp function was operating on the format's
> fourcc and was doing a lookup to retrieve the drm_format_info structure and
> return the cpp.
>
> However, this is inefficient since in most cases, we will
Dear Yannick,
Thank you for your patch,
(already ;-)
Reviewed-by: Philippe Cornu
Philippe :)
On 5/10/19 4:20 PM, Yannick Fertré wrote:
> This patch adds documentation of a new property phy-dsi-supply to the
> STM32 DSI controller.
>
> Signed-off-by: Yannick Fertré
> ---
>
On 2019-05-10 5:42 p.m., Daniel Vetter wrote:
> On Fri, May 10, 2019 at 09:29:58AM -0500, Alex Deucher wrote:
>> This breaks multiple graphics cards in the Amigaone x5000
>> on PPC.
>>
>> This reverts commit 3d42f1ddc47a69c0ce155f9f30d764c4d689a5fa.
>>
>> Bug:
Hi,
On Thu, 2019-05-09 at 11:39 -0700, Eric Anholt wrote:
> Paul Kocialkowski writes:
>
> > The binner BO is not required until the V3D is in use, so avoid
> > allocating it at probe and do it on the first non-dumb BO allocation.
> >
> > Keep track of which clients are using the V3D and
On 2019-05-10 4:29 p.m., Alex Deucher wrote:
> This breaks multiple graphics cards in the Amigaone x5000
> on PPC.
>
> This reverts commit 3d42f1ddc47a69c0ce155f9f30d764c4d689a5fa.
>
> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=109345
It's not clear to me yet that this was really a
https://bugs.freedesktop.org/show_bug.cgi?id=109345
--- Comment #42 from Michel Dänzer ---
Allan, please attach the /etc/X11/xorg.conf(.bak) file and the Xorg log files
from the good and bad cases.
--
You are receiving this mail because:
You are the assignee for the
On Fri, May 10, 2019 at 09:29:58AM -0500, Alex Deucher wrote:
> This breaks multiple graphics cards in the Amigaone x5000
> on PPC.
>
> This reverts commit 3d42f1ddc47a69c0ce155f9f30d764c4d689a5fa.
>
> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=109345
> Signed-off-by: Alex Deucher
> CC:
On Fri, May 10, 2019 at 11:08 AM Koenig, Christian
wrote:
> Am 10.05.19 um 16:57 schrieb Kenny Ho:
> > On Fri, May 10, 2019 at 8:28 AM Christian König
> > wrote:
> >> Am 09.05.19 um 23:04 schrieb Kenny Ho:
> So the drm cgroup container is separate to other cgroup containers?
In cgroup-v1, which
On Fri, May 10, 2019 at 11:28 AM Petr Mladek wrote:
>
> On Thu 2019-05-09 22:06:33, Daniel Vetter wrote:
> > console_trylock, called from within printk, can be called from pretty
> > much anywhere. Including try_to_wake_up. Note that this isn't common,
> > usually the box is in pretty bad shape
On Fri, May 10, 2019 at 8:31 AM Christian König
wrote:
>
> I think it is a good approach to try to add a global limit first and
> when that's working go ahead with limiting device specific resources.
What are some of the global drm resource limit/allocation that would
be useful to implement? I
Am 10.05.19 um 16:57 schrieb Kenny Ho:
> [CAUTION: External Email]
>
> On Fri, May 10, 2019 at 8:28 AM Christian König
> wrote:
>> Am 09.05.19 um 23:04 schrieb Kenny Ho:
>>> + /* only allow bo from the same cgroup or its ancestor to be imported
>>> */
>>> + if (drmcgrp != NULL &&
>>> +
Hi Lucas,
On Fri, May 03, 2019 at 01:10:26PM +0200, Guido Günther wrote:
> Hi Lucas,
> On Wed, Apr 17, 2019 at 03:50:15PM +0200, Lucas Stach wrote:
> >
> > Hi all,
> >
> > v1 cover letter:
> >
> > the following patches finally implement one of the longstanding TODO
> > items in the etnaviv
On Fri, May 10, 2019 at 11:15 AM Petr Mladek wrote:
> On Thu 2019-05-09 18:43:12, Daniel Vetter wrote:
> > One thing to keep in mind is that the kernel is already dying, and
> > things will come crashing down later on
>
> This is important information. I havn't seen it mentioned earlier.
I
Clk_round_rate returns rounded clock without changing
the hardware in any way.
This function couldn't replace set_rate/get_rate calls.
Todo comment has been removed & a new log inserted.
Signed-off-by: Yannick Fertré
---
drivers/gpu/drm/stm/ltdc.c | 10 +++---
1 file changed, 3
Check version of DSI hardware IP. Only versions 1.30 & 1.31
are supported.
Signed-off-by: Yannick Fertré
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
On Fri, May 10, 2019 at 8:28 AM Christian König
wrote:
>
> Am 09.05.19 um 23:04 schrieb Kenny Ho:
> > + /* only allow bo from the same cgroup or its ancestor to be imported
> > */
> > + if (drmcgrp != NULL &&
> > + !drmcgrp_is_self_or_ancestor(drmcgrp, obj->drmcgrp))
On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski
wrote:
>
> Hi,
>
> On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:
> > DRM API for generating uevent for a status changes of connector's
> > property.
> >
> > This uevent will have following details related to the status change:
> >
> >
On Fri, 2019-05-10 at 09:56 +0200, Daniel Vetter wrote:
> On Fri, May 10, 2019 at 9:42 AM Paul Kocialkowski
> wrote:
> > Hi,
> >
> > So this thread has drifted off from IGT to a general DRM improvement,
> > so renaming the thread and adding some CCs.
> >
> > It's about avoiding full reprobes
On Tue, Dec 4, 2018 at 2:29 PM Rob Herring wrote:
>
> On Sat, Dec 1, 2018 at 10:54 AM Rob Clark wrote:
> >
> > This solves a problem we see with drm/msm, caused by getting
> > iommu_dma_ops while we attach our own domain and manage it directly at
> > the iommu API level:
> >
> >
This breaks multiple graphics cards in the Amigaone x5000
on PPC.
This reverts commit 3d42f1ddc47a69c0ce155f9f30d764c4d689a5fa.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=109345
Signed-off-by: Alex Deucher
CC: Aaron Ma
---
drivers/gpu/vga/vgaarb.c | 2 +-
1 file changed, 1
Hi,
Resending this with the right CC.
Also changed my mind in the meantime and my latest proposal is at:
https://lists.freedesktop.org/archives/dri-devel/2019-May/217442.html
On Fri, 2019-05-10 at 10:06 +0200, Daniel Vetter wrote:
> On Fri, May 10, 2019 at 10:01 AM Paul Kocialkowski
> wrote:
>
Add support of an optional regulator for the phy part of the DSI
controller.
Signed-off-by: Yannick Fertré
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 45 ++-
1 file changed, 39 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
Stupid me, patch #3 has a rebase error so please ignore this version.
@Marek: This set is fixing the GDS problem for my constructed test case,
you probably try it also in a real world scenario when it lands.
Christian.
Am 10.05.19 um 16:13 schrieb Christian König:
We are already doing this
The dsi physical layer is powered by the 1v8 power controller supply.
Signed-off-by: Yannick Fertré
---
arch/arm/boot/dts/stm32mp157c.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi
b/arch/arm/boot/dts/stm32mp157c.dtsi
index 2afeee6..6b14f1e 100644
This property is already defined into stm32mp157c.dtsi file.
Signed-off-by: Yannick Fertré
---
arch/arm/boot/dts/stm32mp157c-dk2.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts
b/arch/arm/boot/dts/stm32mp157c-dk2.dts
index 020ea0f..09f6e7b 100644
Move regulators reg11 & reg18 from device-tree files stm32mp157c-ed1.dts
& stm32mp157c-dk2.dts to file stm32mp157c.dtsi.
Signed-off-by: Yannick Fertré
---
arch/arm/boot/dts/stm32mp157c-dk2.dts | 8
arch/arm/boot/dts/stm32mp157c-ed1.dts | 16
This patch adds documentation of a new property phy-dsi-supply to the
STM32 DSI controller.
Signed-off-by: Yannick Fertré
---
Documentation/devicetree/bindings/display/st,stm32-ltdc.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git
The DSI controller needs a new property that powers its physical layer.
Binding has been updated to documented this property.
Device tree of stm32mp157c soc.
Move reg18 & reg11 to stm32mp157c device tree file.
Remove property phy-dsi-supply property to stm32mp157c-dk2.dts file.
Changes in v2:
-
https://bugs.freedesktop.org/show_bug.cgi?id=109345
--- Comment #41 from Alex Deucher ---
I'll send out a patch to revert the change.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
We are already doing this for DMA-buf imports and also for
amdgpu VM BOs for quite a while now.
If this doesn't run into any problems we are probably going
to stop removing BOs from the LRU altogether.
Signed-off-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 9
From: Chunming Zhou
heavy gpu job could occupy memory long time, which lead other user fail to get
memory.
basically pick up Christian idea:
1. Reserve the BO in DC using a ww_mutex ticket (trivial).
2. If we then run into this EBUSY condition in TTM check if the BO we need
memory for (or
From: Chunming Zhou
add ticket for display bo, so that it can preempt busy bo.
Change-Id: I9f031cdcc8267de00e819ae303baa0a52df8ebb9
Signed-off-by: Chunming Zhou
Reviewed-by: Christian König
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 21 ++-
1 file changed, 16
This avoids OOM situations when we have lots of threads
submitting at the same time.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
https://bugs.freedesktop.org/show_bug.cgi?id=110639
wangfengjuan changed:
What|Removed |Added
Version|18.0|19.1
--
You are receiving this mail
That looks better than I thought it would be.
I think it is a good approach to try to add a global limit first and
when that's working go ahead with limiting device specific resources.
The only major issue I can see is on patch #4, see there for further
details.
Christian.
Am 09.05.19 um
Am 09.05.19 um 23:04 schrieb Kenny Ho:
This new drmcgrp resource limits the largest GEM buffer that can be
allocated in a cgroup.
Change-Id: I0830d56775568e1cf215b56cc892d5e7945e9f25
Signed-off-by: Kenny Ho
---
include/linux/cgroup_drm.h | 2 ++
kernel/cgroup/drm.c| 59
Am 09.05.19 um 23:04 schrieb Kenny Ho:
The drm resource being measured and limited here is the GEM buffer
objects. User applications allocate and free these buffers. In
addition, a process can allocate a buffer and share it with another
process. The consumer of a shared buffer can also
Hi,
On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:
> DRM API for generating uevent for a status changes of connector's
> property.
>
> This uevent will have following details related to the status change:
>
> HOTPLUG=1, CONNECTOR= and PROPERTY=
>
> Need ACK from this uevent from
https://bugs.freedesktop.org/show_bug.cgi?id=110248
--- Comment #2 from Eero Tamminen ---
Thanks, I can verify that the Meson doesn't anymore fail.
However, it doesn't seem to disable all tests:
$ grep tests
On Fri, May 10, 2019 at 11:08:42AM +0100, Colin King wrote:
> From: Colin Ian King
>
> In the case where is_enable is false and lo_base_addr is non-zero the
> variable ret has not been initialized and is being checked for non-zero
> and potentially garbage is being returned. Fix this by not
So far, the drm_format_plane_height/width functions were operating on the
format's fourcc and was doing a lookup to retrieve the drm_format_info
structure and return the cpp.
However, this is inefficient since in most cases, we will have the
drm_format_info pointer already available so we
The Rockchip VOP driver has a function, scl_vop_cal_scl_fac, that will
lookup the drm_format_info structure from the fourcc passed to it by its
caller.
However, its only caller already derefences the drm_format_info structure
it has access to to retrieve that fourcc. Change the prototype of that
drm_format_num_planes() is basically a lookup in the drm_format_info table
plus an access to the num_planes field of the appropriate entry.
Most drivers are using this function while having access to the entry
already, which means that we will perform an unnecessary lookup. Removing
the call to
drm_format_horz_chroma_subsampling and drm_format_vert_chroma_subsampling
are basically a lookup in the drm_format_info table plus an access to the
hsub and vsub fields of the appropriate entry.
Most drivers are using this function while having access to the entry
already, which means that we
So far, the drm_format_plane_cpp function was operating on the format's
fourcc and was doing a lookup to retrieve the drm_format_info structure and
return the cpp.
However, this is inefficient since in most cases, we will have the
drm_format_info pointer already available so we shouldn't have to
On Fri, May 10, 2019 at 09:13:26AM +, Ardelean, Alexandru wrote:
> On Wed, 2019-05-08 at 16:26 +0300, Alexandru Ardelean wrote:
> > On Wed, 2019-05-08 at 15:20 +0300, Dan Carpenter wrote:
> > >
> > >
> > > On Wed, May 08, 2019 at 02:28:35PM +0300, Alexandru Ardelean wrote:
> > > > -static
drm_get_format_info directly calls into drm_format_info, but takes directly
a struct drm_mode_fb_cmd2 pointer, instead of the fourcc directly. It's
shorter to not dereference it, and we can customise the behaviour at the
driver level if we want to, so let's switch to it where it makes sense.
https://bugs.freedesktop.org/show_bug.cgi?id=110248
Petri Latvala changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On Thu, May 09, 2019 at 10:11:01PM -0700, Frank Rowand wrote:
> >> You *can* run in-kernel test using modules; but there is no framework
> >> for the in-kernel code found in the test modules, which means each of
> >> the in-kernel code has to create their own in-kernel test
> >> infrastructure.
>
> On Fri, May 10, 2019 at 7:27 PM Brendan Higgins
> wrote:
> >
> > > On Thu, May 2, 2019 at 8:03 AM Brendan Higgins
> > > wrote:
> > > >
> > > > Add KUnit to root Kconfig and Makefile allowing it to actually be built.
> > > >
> > > > Signed-off-by: Brendan Higgins
> > >
> > > You need to make
> On Thu, May 2, 2019 at 8:03 AM Brendan Higgins
> wrote:
> >
> > Add KUnit to root Kconfig and Makefile allowing it to actually be built.
> >
> > Signed-off-by: Brendan Higgins
>
> You need to make sure
> to not break git-bisect'abililty.
>
>
> With this commit, I see build error.
>
> CC
> On Thu, May 2, 2019 at 8:02 AM Brendan Higgins
> wrote:
> >
> > ## TLDR
> >
> > I rebased the last patchset on 5.1-rc7 in hopes that we can get this in
> > 5.2.
> >
> > Shuah, I think you, Greg KH, and myself talked off thread, and we agreed
> > we would merge through your tree when the time
> On Fri, May 10, 2019 at 7:49 AM Knut Omang wrote:
> >
> > On Thu, 2019-05-09 at 22:18 -0700, Frank Rowand wrote:
> > > On 5/9/19 4:40 PM, Logan Gunthorpe wrote:
> > > >
> > > >
> > > > On 2019-05-09 5:30 p.m., Theodore Ts'o wrote:
> > > >> On Thu, May 09, 2019 at 04:20:05PM -0600, Logan
From: Colin Ian King
In the case where is_enable is false and lo_base_addr is non-zero the
variable ret has not been initialized and is being checked for non-zero
and potentially garbage is being returned. Fix this by not returning
ret but instead returning -EINVAL on the zero lo_base_addr case.
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: c16fd9be70faf3c49a61700efd16018dd910e390
commit: f26ae6a652f2e75a3a12ac22b7da5797978436c4 [5/6] drm/i915: SRM revocation
check for HDCP1.4 and 2.2
If you fix the issue, kindly add following tag
Reported-by: kbuild test
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: c16fd9be70faf3c49a61700efd16018dd910e390
commit: 6498bf5800a302ef69e7f4914e727893f278bb2f [4/6] drm: revocation check at
drm subsystem
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
From: Greg Hackmann
The show_fdinfo handler exports the same information available through
debugfs on a per-buffer basis.
Signed-off-by: Greg Hackmann
Signed-off-by: Chenbo Feng
---
drivers/dma-buf/dma-buf.c | 15 +++
1 file changed, 15 insertions(+)
diff --git
Hi Ted,
I'll try answering this again.
The first time I was a little flippant in part of my answer because I
thought your comments somewhat flippant. This time I'll provide a
more complete answer.
On 5/8/19 7:13 PM, Frank Rowand wrote:
> On 5/8/19 6:58 PM, Theodore Ts'o wrote:
>> On Wed, May
On Thu, May 2, 2019 at 8:03 AM Brendan Higgins
wrote:
>
> Add KUnit to root Kconfig and Makefile allowing it to actually be built.
>
> Signed-off-by: Brendan Higgins
You need to make sure
to not break git-bisect'abililty.
With this commit, I see build error.
CC kunit/test.o
Currently, all dma-bufs share the same anonymous inode. While we can count
how many dma-buf fds or mappings a process has, we can't get the size of
the backing buffers or tell if two entries point to the same dma-buf. And
in debugfs, we can get a per-buffer breakdown of size and reference count,
From: Greg Hackmann
This patch adds complimentary DMA_BUF_SET_NAME and DMA_BUF_GET_NAME
ioctls, which lets userspace processes attach a free-form name to each
buffer.
This information can be extremely helpful for tracking and accounting
shared buffers. For example, on Android, we know what
From: Greg Hackmann
By traversing /proc/*/fd and /proc/*/map_files, processes with CAP_ADMIN
can get a lot of fine-grained data about how shmem buffers are shared
among processes. stat(2) on each entry gives the caller a unique
ID (st_ino), the buffer's size (st_size), and even the number of
On 5/9/19 4:40 PM, Logan Gunthorpe wrote:
>
>
> On 2019-05-09 5:30 p.m., Theodore Ts'o wrote:
>> On Thu, May 09, 2019 at 04:20:05PM -0600, Logan Gunthorpe wrote:
>>>
>>> The second item, arguably, does have significant overlap with kselftest.
>>> Whether you are running short tests in a light
On (05/09/19 22:06), Daniel Vetter wrote:
[..]
> +/* Functions for the contended case */
> +
> +struct semaphore_waiter {
> + struct list_head list;
> + struct task_struct *task;
> + bool up;
> +};
> +
> /**
> * up - release the semaphore
> * @sem: the semaphore to release
> @@
On Thu, 2019-05-09 at 22:18 -0700, Frank Rowand wrote:
> On 5/9/19 4:40 PM, Logan Gunthorpe wrote:
> >
> >
> > On 2019-05-09 5:30 p.m., Theodore Ts'o wrote:
> >> On Thu, May 09, 2019 at 04:20:05PM -0600, Logan Gunthorpe wrote:
> >>>
> >>> The second item, arguably, does have significant overlap
On Wed, 2019-05-08 at 17:58 -0700, Randy Dunlap wrote:
> On 5/8/19 12:01 AM, Alastair D'Silva wrote:
> > From: Alastair D'Silva
> >
> > Some buffers may only be partially filled with useful data, while
> > the rest
> > is padded (typically with 0x00 or 0xff).
> >
> > This patch introduces a
On Fri, May 10, 2019 at 7:49 AM Knut Omang wrote:
>
> On Thu, 2019-05-09 at 22:18 -0700, Frank Rowand wrote:
> > On 5/9/19 4:40 PM, Logan Gunthorpe wrote:
> > >
> > >
> > > On 2019-05-09 5:30 p.m., Theodore Ts'o wrote:
> > >> On Thu, May 09, 2019 at 04:20:05PM -0600, Logan Gunthorpe wrote:
> >
On Fri, May 10, 2019 at 10:01 AM Paul Kocialkowski
wrote:
>
> Hi,
>
> On Fri, 2019-05-10 at 09:56 +0200, Daniel Vetter wrote:
> > On Fri, May 10, 2019 at 9:42 AM Paul Kocialkowski
> > wrote:
> > > Hi,
> > >
> > > So this thread has drifted off from IGT to a general DRM improvement,
> > > so
Hi,
On Fri, 2019-05-10 at 09:56 +0200, Daniel Vetter wrote:
> On Fri, May 10, 2019 at 9:42 AM Paul Kocialkowski
> wrote:
> > Hi,
> >
> > So this thread has drifted off from IGT to a general DRM improvement,
> > so renaming the thread and adding some CCs.
> >
> > It's about avoiding full
On Fri, May 10, 2019 at 9:42 AM Paul Kocialkowski
wrote:
>
> Hi,
>
> So this thread has drifted off from IGT to a general DRM improvement,
> so renaming the thread and adding some CCs.
>
> It's about avoiding full reprobes (which may include slow EDID reads,
> etc) when a connector change was
On Fri, May 10, 2019 at 7:50 AM Sergey Senozhatsky
wrote:
>
> On (05/09/19 22:06), Daniel Vetter wrote:
> [..]
> > +/* Functions for the contended case */
> > +
> > +struct semaphore_waiter {
> > + struct list_head list;
> > + struct task_struct *task;
> > + bool up;
> > +};
> > +
> >
Hi,
So this thread has drifted off from IGT to a general DRM improvement,
so renaming the thread and adding some CCs.
It's about avoiding full reprobes (which may include slow EDID reads,
etc) when a connector change was detected, by providing information
about the connector and the new state to
From: Colin Ian King
There is a spelling mistake in a DRM_ERROR error message. Fix this.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/df_v3_6.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/df_v3_6.c
https://bugs.freedesktop.org/show_bug.cgi?id=101473
qmaster...@gmail.com changed:
What|Removed |Added
Resolution|--- |FIXED
100 matches
Mail list logo
