On Mon, 16 Sep 2019 17:20:28 -0500
Rob Herring wrote:
> On Fri, Sep 13, 2019 at 6:17 AM Boris Brezillon
> wrote:
> >
> > The READ/WRITE flags are particularly useful if we want to avoid
> > serialization of jobs that read from the same BO but never write to it.
>
> Any data on performance dif
In dcn*_clock_source_create when dcn20_clk_src_construct fails allocated
clk_src needs release.
Signed-off-by: Navid Emamdoost
---
drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c | 3 ++-
drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 1 +
drivers/gpu/drm/amd/display/dc/dce112
0004-v10-4-9-drm-panel-Add-Boe-Himax8279d-MIPI-DSI-LCD-pa.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
0003-v10-3-9-drm-panel-Add-Boe-Himax8279d-MIPI-DSI-LCD-pa.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
0007-v10-7-9-drm-panel-Add-Boe-Himax8279d-MIPI-DSI-LCD-pa.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
(+CC Stephen Rothwell, Mark Brown)
On Mon, Sep 16, 2019 at 1:46 PM Austin Kim wrote:
>
> gcc throws compile error with below message:
GNU Make throws ...
This is probably a merge mistake in linux-next.
If so, this should be directly fixed in the linux-next.
If it is not fixed in time,
please
0002-v10-2-9-drm-panel-Add-Boe-Himax8279d-MIPI-DSI-LCD-pa.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Andrzej and Brian
On 16/9/19 12:02, Andrzej Hajda wrote:
> On 15.08.2019 02:48, Brian Masney wrote:
>> When attempting to configure this driver on a Nexus 5 phone (msm8974),
>> setting up the dummy i2c bus for TX_P0 would fail due to an -EBUSY
>> error. The downstream MSM kernel sources [1] sho
On 16/09/2019 16:04, Thierry Reding wrote:
From: Thierry Reding
There are extra registers that need to be programmed to make the level 2
cache work on GP10B, such as the stream ID register that is used when an
SMMU is used to translate memory addresses.
Signed-off-by: Thierry Reding
---
...
0001-v10-1-9-drm-panel-Add-Boe-Himax8279d-MIPI-DSI-LCD-pa.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
0009-v10-9-9-drm-panel-Add-Boe-Himax8279d-MIPI-DSI-LCD-pa.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > + /**
> > +* Pointer to a u32 array of &drm_panfrost_submit_bo_desc objects. This
> > +* field is meant to replace &drm_panfrost_submit.bo_handles which did
> > +* not provide enough information to relax synchronization between
> > +* jobs that only only read the BO they share
0006-v10-6-9-drm-panel-Add-Boe-Himax8279d-MIPI-DSI-LCD-pa.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
0008-v10-8-9-drm-panel-Add-Boe-Himax8279d-MIPI-DSI-LCD-pa.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Sep 4, 2019 at 1:58 PM Randy Dunlap wrote:
>
> On 9/4/19 6:34 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > News: this will be the last linux-next I will release until Sept 30.
> >
> > Changes since 20190903:
> >
>
> on x86_64:
>
> In file included from
> ../drivers/gpu/drm/amd/amdgpu/.
0005-v10-5-9-drm-panel-Add-Boe-Himax8279d-MIPI-DSI-LCD-pa.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Linus,
Continuing on the cleanup theme from last merge window, here is
another set of hmm and closely related patches that are largely
cleanups and bug fixes without any particularly notable functional
change.
The diffstat below covers a wide section of the kernel, but a lot of
this is caused
On Mon, Sep 16, 2019 at 12:02:09PM +0200, Andrzej Hajda wrote:
> On 15.08.2019 02:48, Brian Masney wrote:
> > When attempting to configure this driver on a Nexus 5 phone (msm8974),
> > setting up the dummy i2c bus for TX_P0 would fail due to an -EBUSY
> > error. The downstream MSM kernel sources [1
https://bugs.freedesktop.org/show_bug.cgi?id=111682
--- Comment #3 from Pierre-Eric Pelloux-Prayer
---
Created attachment 145387
--> https://bugs.freedesktop.org/attachment.cgi?id=145387&action=edit
dmesg when using cfdabd064b2d(drm/amdgpu: remove the redundant null checks)
Using the latest c
https://bugs.freedesktop.org/show_bug.cgi?id=111682
Pierre-Eric Pelloux-Prayer changed:
What|Removed |Added
Summary|use-after-free in |use-after-free in
On 16.09.2019 14:02, Brian Masney wrote:
> On Mon, Sep 16, 2019 at 01:32:58PM +0200, Enric Balletbo i Serra wrote:
>> Hi,
>>
>> On 16/9/19 12:49, Laurent Pinchart wrote:
>>> Hi Brian,
>>>
>>> On Mon, Sep 16, 2019 at 06:36:14AM -0400, Brian Masney wrote:
On Mon, Sep 16, 2019 at 12:02:09PM +0200
> From: Jason Wang
> Sent: Thursday, September 12, 2019 5:40 PM
>
> Mdev bus only support vfio driver right now, so it doesn't implement
> match method. But in the future, we may add drivers other than vfio,
> one example is virtio-mdev[1] driver. This means we need to add device
> id support in b
On Mon, Sep 16, 2019 at 05:15:25PM +0100, Robin Murphy wrote:
> On 16/09/2019 16:57, Thierry Reding wrote:
> > On Mon, Sep 16, 2019 at 04:29:18PM +0100, Robin Murphy wrote:
> > > Hi Thierry,
> > >
> > > On 16/09/2019 16:04, Thierry Reding wrote:
> > > > From: Thierry Reding
> > > >
> > > > If th
> From: Jason Wang
> Sent: Thursday, September 12, 2019 5:40 PM
>
> Currently, except for the crate and remove. The rest fields of
> mdev_parent_ops is just designed for vfio-mdev driver and may not help
> for kernel mdev driver. So follow the device id support by previous
> patch, this patch intr
Am 17.09.19 um 07:47 schrieb Jani Nikula:
On Mon, 16 Sep 2019, Marek Olšák wrote:
The purpose is to get rid of all PCI ID tables for all drivers in
userspace. (or at least stop updating them)
Mesa common code and modesetting will use this.
I'd think this would warrant a high level description
ping for a review
Am 11.09.19 um 14:03 schrieb Thomas Zimmermann:
> The ast and mgag200 drivers pin() and kmap() cursor buffers; essentially
> reimplementing vmap(). We can share some code by using the respective
> functionality from GEM VRAM buffer objects.
>
> Thomas Zimmermann (3):
> drm/vra
Hi,
> > - /* VM_PFNMAP was set by drm_gem_mmap() */
> > - vma->vm_flags &= ~VM_PFNMAP;
> > - vma->vm_flags |= VM_MIXEDMAP;
> > + vma->vm_flags |= (VM_MIXEDMAP|VM_DONTEXPAND);
>
> I'm finding this a bit hard to follow - but I think here we've lost
> VM_IO and VM_DONTDUMP which used to be
On Mon, Sep 16, 2019 at 05:07:14PM -0500, Rob Herring wrote:
> On Fri, Sep 13, 2019 at 7:29 AM Gerd Hoffmann wrote:
> >
>
> Version? Pretty sure this is not v1.
Yep, was posted as part of a longer series before.
Splitted the long series into multiple smaller ones by cherry-picking
patches into
On Tue, Sep 17, 2019 at 10:12 AM Christian König
wrote:
>
> Am 17.09.19 um 07:47 schrieb Jani Nikula:
> > On Mon, 16 Sep 2019, Marek Olšák wrote:
> >> The purpose is to get rid of all PCI ID tables for all drivers in
> >> userspace. (or at least stop updating them)
> >>
> >> Mesa common code and
Am 17.09.19 um 10:17 schrieb Daniel Vetter:
> On Tue, Sep 17, 2019 at 10:12 AM Christian König
> wrote:
>> Am 17.09.19 um 07:47 schrieb Jani Nikula:
>>> On Mon, 16 Sep 2019, Marek Olšák wrote:
The purpose is to get rid of all PCI ID tables for all drivers in
userspace. (or at least stop
On Fri, Sep 13, 2019 at 02:56:09PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 13.09.19 um 14:29 schrieb Gerd Hoffmann:
> > Factor out ttm vma setup to a new function. Reduces
> > code duplication a bit and allows to implement
> > &drm_gem_object_funcs.mmap in gem ttm helpers.
> >
> > Signed-off
On Fri, Sep 13, 2019 at 03:05:34PM +0200, Thomas Zimmermann wrote:
> > +void ttm_bo_mmap_vma_setup(struct ttm_buffer_object *bo, struct
> > vm_area_struct *vma)
> > +{
> > + vma->vm_ops = &ttm_bo_vm_ops;
> > +
> > + /*
> > +* Note: We're transferring the bo reference to
> > +* vma->vm
> > include/drm/drm_vram_mm_helper.h | 82 +++
> > diff --git a/include/drm/drm_vram_mm_helper.h
> > b/include/drm/drm_vram_mm_helper.h
> > new file mode 100644
>
> Please rebase onto the latest drm-tip. This entire file has been removed
> in a recent patch.
I did r
On Tue, Sep 17, 2019 at 01:49:57PM +1000, Ben Skeggs wrote:
> On Tue, 17 Sep 2019 at 01:04, Thierry Reding wrote:
> >
> > From: Thierry Reding
> >
> > The GPUs found on Tegra SoCs have registers that can be used to read the
> > WPR configuration. Use these registers instead of reaching into the
>
Hi Steven,
thought about that issue a bit more and I think I came up with a solution.
What you could do is to split up drm_sched_cleanup_jobs() into two
functions.
One that checks if jobs to be cleaned up are present and one which does
the actual cleanup.
This way we could call drm_sched_clea
Hi
Am 16.09.19 um 11:06 schrieb Feng Tang:
> Hi Thomas,
>
> On Mon, Sep 09, 2019 at 04:12:37PM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 04.09.19 um 08:27 schrieb Feng Tang:
>>> Hi Thomas,
>>>
>>> On Wed, Aug 28, 2019 at 12:51:40PM +0200, Thomas Zimmermann wrote:
Hi
Am 28.08.1
On Tue, Sep 17, 2019 at 01:43:13PM +1000, Ben Skeggs wrote:
> On Tue, 17 Sep 2019 at 01:18, Thierry Reding wrote:
> >
> > From: Thierry Reding
> >
> > The gk20a (as well as all subsequent Tegra instantiations of the GPU) do
> > in fact use the same apertures as regular GPUs. Prior to gv11b there
On Tue, Sep 17, 2019 at 01:47:25PM +1000, Ben Skeggs wrote:
> On Tue, 17 Sep 2019 at 01:18, Thierry Reding wrote:
> >
> > From: Thierry Reding
> >
> > The fault information register contains data about the aperture that
> > caused the failure. This can be useful in debugging aperture related
> >
On Tue, Sep 17, 2019 at 01:48:20PM +1000, Ben Skeggs wrote:
> On Tue, 17 Sep 2019 at 01:18, Thierry Reding wrote:
> >
> > From: Thierry Reding
> >
> > The engine field in the FIFO fault information registers is actually 9
> > bits wide.
> Looks like this is true for fault buffer parsing too.
Yes
On Tue, Sep 17, 2019 at 04:07:54PM +1000, Ben Skeggs wrote:
> On Tue, 17 Sep 2019 at 00:36, Thierry Reding wrote:
> >
> > From: Thierry Reding
> >
> > Hi Ben,
> >
> > I messed up the ordering of patches in my tree a bit, so these two fixes
> > got separated from the others. I don't consider these
> On September 17, 2019 at 8:23 AM Geert Uytterhoeven
> wrote:
>
>
> Commit 5cca30ebe089be23 ("drm/rcar-du: Add LVDS_LANES quirk") states
> that LVDS lanes 1 and 3 are inverted on R-Car H2 ES1 only, and that the
> problem has been fixed in newer revisions.
>
> However, the code didn't take i
Not obvious why this is needed. According to Deniel Vetter this is most
likely a historic artefact dating back to the days where drm drivers
exposed hardware registers as mmap'able gem objects, to avoid dumping
touching those registers. shmem gem objects surely don't need that ...
Signed-off-by:
On 2019-09-17 10:23 a.m., Koenig, Christian wrote:
> Am 17.09.19 um 10:17 schrieb Daniel Vetter:
>> On Tue, Sep 17, 2019 at 10:12 AM Christian König
>> wrote:
>>> Am 17.09.19 um 07:47 schrieb Jani Nikula:
On Mon, 16 Sep 2019, Marek Olšák wrote:
> The purpose is to get rid of all PCI ID t
drm_gem_object_funcs->vm_ops alone can't handle everything which needs
to be done for mmap(), tweaking vm_flags for example. So add a new
mmap() callback to drm_gem_object_funcs where this code can go to.
Note that the vm_ops field is not used in case the mmap callback is
present, it is expected
Add helper function to mmap ttm bo's using &drm_gem_object_funcs.mmap().
Note that with this code path access verification is done by
drm_gem_mmap() (which calls drm_vma_node_is_allowed(()).
The &ttm_bo_driver.verify_access() callback is is not used.
Signed-off-by: Gerd Hoffmann
---
include/drm
Switch gem shmem helper to the new mmap() workflow,
from &gem_driver.fops.mmap to &drm_gem_object_funcs.mmap.
v2: Fix vm_flags and vm_page_prot handling.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem_shmem_helper.h | 6 ++
drivers/gpu/drm/drm_gem_shmem_helper.c | 28 +-
Not obvious why this is needed. According to Deniel Vetter this is most
likely a historic artefact dating back to the days where drm drivers
exposed hardware registers as mmap'able gem objects, to avoid dumping
touching those registers.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/ttm/ttm_b
DEFINE_DRM_GEM_SHMEM_FOPS is identical
to DEFINE_DRM_GEM_FOPS now, drop it.
Signed-off-by: Gerd Hoffmann
Acked-by: Rob Herring
---
include/drm/drm_gem_shmem_helper.h | 26 -
drivers/gpu/drm/cirrus/cirrus.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_drv.c |
Wire up the new drm_gem_ttm_mmap() helper function,
use generic drm_gem_mmap for &fops.mmap and
delete dead drm_vram_mm_file_operations_mmap().
Signed-off-by: Gerd Hoffmann
Reviewed-by: Thomas Zimmermann
---
include/drm/drm_gem_vram_helper.h | 9 +--
drivers/gpu/drm/drm_gem_vram_helper
Not needed any more because we don't have vram specific fops
any more. DEFINE_DRM_GEM_FOPS() can be used instead.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Thomas Zimmermann
---
include/drm/drm_gem_vram_helper.h | 18 --
drivers/gpu/drm/ast/ast_drv.c
Factor out ttm vma setup to a new function. Reduces
code duplication a bit and allows to implement
&drm_gem_object_funcs.mmap in gem ttm helpers.
Signed-off-by: Gerd Hoffmann
---
include/drm/ttm/ttm_bo_api.h| 8 ++
drivers/gpu/drm/ttm/ttm_bo_vm.c | 47 ++---
VM_IO is wrong here, shmem uses normal ram not io memory.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 6efedab1501
Not needed any more.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 22 --
1 file changed, 22 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index e100b97ea6e3
Add mmap callback to struct drm_gem_object_funcs, which is supposed to
handle the vma setup. It will be used by both normal fops->mmap (via
drm_gem_mmap_obj()) and prime mmap (via drm_gem_prime_mmap()).
For starters the shmem and vram helpers are switched over to the new
workflow, to show things
On 2019-09-17 11:23 a.m., Michel Dänzer wrote:
> On 2019-09-17 10:23 a.m., Koenig, Christian wrote:
>> Am 17.09.19 um 10:17 schrieb Daniel Vetter:
>>> On Tue, Sep 17, 2019 at 10:12 AM Christian König
>>> wrote:
Am 17.09.19 um 07:47 schrieb Jani Nikula:
> On Mon, 16 Sep 2019, Marek Olšák
Hi Gerd
Am 17.09.19 um 10:34 schrieb Gerd Hoffmann:
> On Fri, Sep 13, 2019 at 03:05:34PM +0200, Thomas Zimmermann wrote:
>
>>> +void ttm_bo_mmap_vma_setup(struct ttm_buffer_object *bo, struct
>>> vm_area_struct *vma)
>>> +{
>>> + vma->vm_ops = &ttm_bo_vm_ops;
>>> +
>>> + /*
>>> +* Note:
> It may not be worth blocking on this, so
>
> Acked-by: Thomas Zimmermann
>
> But I still think it's not a good interface because it exposes internal
> details.
>
> Please consider another idea: how about splitting off the ttm_bo_get()
> and vma-flags setup of ttm_fbdev_mmap() into a separat
On Wed, Sep 11, 2019 at 02:03:49PM +0200, Thomas Zimmermann wrote:
> The ast and mgag200 drivers pin() and kmap() cursor buffers; essentially
> reimplementing vmap(). We can share some code by using the respective
> functionality from GEM VRAM buffer objects.
>
> Thomas Zimmermann (3):
> drm/vra
On 2019/9/17 下午3:55, Tian, Kevin wrote:
From: Jason Wang
Sent: Thursday, September 12, 2019 5:40 PM
Mdev bus only support vfio driver right now, so it doesn't implement
match method. But in the future, we may add drivers other than vfio,
one example is virtio-mdev[1] driver. This means we need
On 2019/9/17 下午4:09, Tian, Kevin wrote:
From: Jason Wang
Sent: Thursday, September 12, 2019 5:40 PM
Currently, except for the crate and remove. The rest fields of
mdev_parent_ops is just designed for vfio-mdev driver and may not help
for kernel mdev driver. So follow the device id support by p
https://bugs.freedesktop.org/show_bug.cgi?id=108898
--- Comment #6 from Eero Tamminen ---
These still happen with latest git version of kernel, Mesa etc.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing li
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #48 from Marko Popovic ---
(In reply to Pierre-Eric Pelloux-Prayer from comment #15)
> (In reply to Marko Popovic from comment #14)
> >
> > Yes, always happens at the same place with Citra emulator
>
> Could you capture a trace of
Convert Samsung Image Rotator to newer dt-schema format.
Signed-off-by: Maciej Falkowski
Signed-off-by: Marek Szyprowski
---
v3:
- remove unneded comments and descriptions
- remove unneded maxItems field from clock-names property
---
.../bindings/gpu/samsung-rotator.txt | 28 --
The Vulkan timeline semaphores allow signaling to happen on the point
of the timeline without all of the its dependencies to be created.
The current 2 implementations (AMD/Intel) of the Vulkan spec on top of
the Linux kernel are using a thread to wait on the dependencies of a
given point to materi
Hi all,
Just explaining what is being changed here compared to v6 :
We just noticed that some of our CTS runs are flaky because when
importing a dma fence into a drm syncobj we do not update the atomic
binary payload. This leads to issues when the userspace drivers tries
to add new points to the
Am 17.09.19 um 11:27 schrieb Michel Dänzer:
On 2019-09-17 11:23 a.m., Michel Dänzer wrote:
On 2019-09-17 10:23 a.m., Koenig, Christian wrote:
Am 17.09.19 um 10:17 schrieb Daniel Vetter:
On Tue, Sep 17, 2019 at 10:12 AM Christian König
wrote:
Am 17.09.19 um 07:47 schrieb Jani Nikula:
On Mon,
Am 17.09.19 um 11:24 schrieb Gerd Hoffmann:
> Not obvious why this is needed. According to Deniel Vetter this is most
> likely a historic artefact dating back to the days where drm drivers
> exposed hardware registers as mmap'able gem objects, to avoid dumping
> touching those registers.
Clearly
From: "Lowry Li (Arm Technology China)"
Adds to support register dump on lpu and dou of pipeline and gcu on D71
Changes since v1:
- For a constant format without additional arguments, use seq_puts()
instead of seq_printf().
Signed-off-by: Lowry Li (Arm Technology China)
---
.../arm/display/ko
On Tue, Sep 17, 2019 at 11:27 AM Michel Dänzer wrote:
>
> On 2019-09-17 11:23 a.m., Michel Dänzer wrote:
> > On 2019-09-17 10:23 a.m., Koenig, Christian wrote:
> >> Am 17.09.19 um 10:17 schrieb Daniel Vetter:
> >>> On Tue, Sep 17, 2019 at 10:12 AM Christian König
> >>> wrote:
> Am 17.09.19 u
On Tue, Sep 17, 2019 at 11:22:35AM +, Koenig, Christian wrote:
> Am 17.09.19 um 11:24 schrieb Gerd Hoffmann:
> > Not obvious why this is needed. According to Deniel Vetter this is most
> > likely a historic artefact dating back to the days where drm drivers
> > exposed hardware registers as mm
On Thu, 12 Sep 2019 17:40:11 +0800
Jason Wang wrote:
> Mdev bus only support vfio driver right now, so it doesn't implement
> match method. But in the future, we may add drivers other than vfio,
> one example is virtio-mdev[1] driver. This means we need to add device
> id support in bus match met
Current code is quite a mess unfortunately, so also add a todo.rst
entry to maybe fix it up eventually.
Cc: Michel Dänzer
Signed-off-by: Daniel Vetter
---
Documentation/gpu/todo.rst | 12
drivers/gpu/drm/drm_connector.c | 10 --
drivers/gpu/drm/drm_dp_helper.c | 8 +++
commit 4f5368b5541a902f6596558b05f5c21a9770dd32
Author: Daniel Vetter
Date: Fri Jun 14 08:17:23 2019 +0200
drm/kms: Catch mode_object lifetime errors
uncovered a bit a mess in dp drivers. Most drivers (from a quick look,
all except i915) register all the dp stuff in their init code, which
On Tue, Aug 27, 2019 at 07:13:41AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > Also this patch series also adjust vram helpers, and I think it has a
> > slightly different goal: Just aligning mmap paths a bit more between
> > ttm and not-ttm based drivers.
>
> Not just ttm/not-ttm. gem_driver->fop
Alright; I'm not familiar with patchwork but sounds good.
On Mon, Sep 16, 2019 at 05:36:24PM -0500, Rob Herring wrote:
> On Fri, Sep 13, 2019 at 12:43 PM Alyssa Rosenzweig
> wrote:
> >
> > Patch 1 is:
> >
> > Acked-by: Alyssa Rosenzweig
> >
> > Patch 2 is:
> >
> > Reviewed-by: Al
On Tue, Sep 10, 2019 at 01:54:48PM +0200, Michal Hocko wrote:
> On Fri 06-09-19 08:45:39, Tejun Heo wrote:
> > Hello, Daniel.
> >
> > On Fri, Sep 06, 2019 at 05:34:16PM +0200, Daniel Vetter wrote:
> > > > Hmm... what'd be the fundamental difference from slab or socket memory
> > > > which are hand
On Mon, Sep 16, 2019 at 02:23:13PM +0200, Christian König wrote:
> Ping? Any further comment on this or can't we merge at least the locking
> change?
I was at plumbers ...
>
> Christian.
>
> Am 11.09.19 um 12:53 schrieb Christian König:
> > Am 03.09.19 um 10:05 schrieb Daniel Vetter:
> > > On Th
Applied. Thanks!
Alex
On Mon, Sep 2, 2019 at 4:16 PM Kai-Heng Feng
wrote:
>
> Laptops with AMD APU doesn't restore display backlight brightness after
> system resume.
>
> This issue started when DC was introduced.
>
> Let's use BL_CORE_SUSPENDRESUME so the backlight core calls
> update_status c
On Mon, Sep 09, 2019 at 02:46:47PM +0200, Thomas Zimmermann wrote:
>
>
> Am 04.09.19 um 07:47 schrieb Gerd Hoffmann:
> > 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
Hi Lionel,
The update looks good to me.
I tried your signal-order test, seems it isn't ready to run, not sure if I can
reproduce your this issue.
-David
From: Lionel Landwerlin
Sent: Tuesday, September 17, 2019 7:03 PM
To: dri-devel@lists.freedesktop.org
Cc: Lio
On Fri, Sep 13, 2019 at 01:24:54PM -0400, Alyssa Rosenzweig wrote:
> I'm conflicted on this series.
>
> On the one hand, userspace should obviously not be able to crash the
> kernel. So the crash should be fixed in one way or another.
>
> On the other hand, userspace really has to supply all the
On 13/09/2019 18:24, Alyssa Rosenzweig wrote:
I'm conflicted on this series.
I'm on holiday, but thought I had to reply...
On the one hand, userspace should obviously not be able to crash the
kernel. So the crash should be fixed in one way or another.
On the other hand, userspace really has
Am 17.09.19 um 14:31 schrieb Daniel Vetter:
> On Mon, Sep 16, 2019 at 02:23:13PM +0200, Christian König wrote:
>> Ping? Any further comment on this or can't we merge at least the locking
>> change?
> I was at plumbers ...
>> Christian.
>>
>> Am 11.09.19 um 12:53 schrieb Christian König:
>>> Am 03.0
On Thu, 12 Sep 2019 17:40:12 +0800
Jason Wang wrote:
> Currently, except for the crate and remove. The rest fields of
> mdev_parent_ops is just designed for vfio-mdev driver and may not help
> for kernel mdev driver. So follow the device id support by previous
> patch, this patch introduces devic
On 17/09/2019 09:42, Koenig, Christian wrote:
Hi Steven,
thought about that issue a bit more and I think I came up with a solution.
What you could do is to split up drm_sched_cleanup_jobs() into two
functions.
One that checks if jobs to be cleaned up are present and one which does
the actual c
On Mon, Sep 16, 2019 at 03:16:49PM +0200, Benjamin Gaignard wrote:
> Le lun. 9 sept. 2019 à 12:29, Benjamin Gaignard
> a écrit :
> >
> > Fix warnings when W=1.
> > No code changes, only clean up in sti internal structures and functions
> > descriptions.
> >
> > Signed-off-by: Benjamin Gaignard
>
On Mon, Sep 09, 2019 at 01:42:53PM +, Ayan Halder wrote:
> Add a modifier 'DRM_FORMAT_MOD_ARM_PROTECTED' which denotes that the
> framebuffer
> is allocated in a protected system memory.
> Essentially, we want to support EGL_EXT_protected_content in our komeda
> driver.
>
> Signed-off-by: Ay
On Tue, Sep 10, 2019 at 04:59:57PM +0200, Noralf Trønnes wrote:
>
>
> Den 10.09.2019 15.51, skrev Thomas Zimmermann:
> > Hi
> >
> > Am 10.09.19 um 15:34 schrieb Noralf Trønnes:
> >>
> >>
> >> Den 10.09.2019 14.48, skrev Thomas Zimmermann:
> >>> Hi
> >>>
> >>> Am 10.09.19 um 13:52 schrieb Gerd Ho
On Wed, Sep 11, 2019 at 10:12:27AM +0100, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a literal string, fix it.
>
> Signed-off-by: Colin Ian King
Applied, thanks.
-Daniel
> ---
> drivers/gpu/drm/selftests/test-drm_framebuffer.c | 2 +-
> 1 file changed, 1 inse
On Thu, Sep 12, 2019 at 08:42:28AM +0200, Thomas Zimmermann wrote:
> Before updating the display from the console's shadow buffer, the dirty
> worker now waits for vblank. This allows several screen updates to pile
> up and acts as a rate limiter.
>
> v2:
> * don't hold helper->lock while wa
Thanks David,
I'll try to fix the test to match AMD's restrictions.
The v7 here was to fix another existing test :
dEQP-VK.api.external.fence.sync_fd.transference_temporary
Cheers,
-Lionel
On 17/09/2019 15:36, Zhou, David(ChunMing) wrote:
Hi Lionel,
The update looks good to me.
I tried you
On Fri, Aug 2, 2019 at 11:43 AM Lowry Li (Arm Technology China)
wrote:
>
> From: "Lowry Li (Arm Technology China)"
>
> Adds to print the event message when error happens and the same event
> will not be printed until next vsync.
>
> Changes since v2:
> 1. Refine komeda_sprintf();
> 2. Not using S
On Tue, Sep 17, 2019 at 12:40:51PM +, Koenig, Christian wrote:
> Am 17.09.19 um 14:31 schrieb Daniel Vetter:
> > On Mon, Sep 16, 2019 at 02:23:13PM +0200, Christian König wrote:
> >> Ping? Any further comment on this or can't we merge at least the locking
> >> change?
> > I was at plumbers ...
On Thu, Sep 12, 2019 at 06:41:21PM +0900, Tomasz Figa wrote:
> This patch is an early RFC to judge the direction we are following in
> our virtualization efforts in Chrome OS. The purpose is to start a
> discussion on how to handle buffer sharing between multiple virtio
> devices.
>
> On a side no
Am 17.09.19 um 15:13 schrieb Daniel Vetter:
> On Tue, Sep 17, 2019 at 12:40:51PM +, Koenig, Christian wrote:
>> Am 17.09.19 um 14:31 schrieb Daniel Vetter:
>>> On Mon, Sep 16, 2019 at 02:23:13PM +0200, Christian König wrote:
Ping? Any further comment on this or can't we merge at least the
Den 17.09.2019 14.55, skrev Daniel Vetter:
> On Tue, Sep 10, 2019 at 04:59:57PM +0200, Noralf Trønnes wrote:
>>
>>
>> Den 10.09.2019 15.51, skrev Thomas Zimmermann:
>>> Hi
>>>
>>> Am 10.09.19 um 15:34 schrieb Noralf Trønnes:
Den 10.09.2019 14.48, skrev Thomas Zimmermann:
> Hi
>
On Fri, Sep 13, 2019 at 02:29:01PM +0200, Gerd Hoffmann wrote:
> drm_gem_object_funcs->vm_ops alone can't handle everything which needs
> to be done for mmap(), tweaking vm_flags for example. So add a new
> mmap() callback to drm_gem_object_funcs where this code can go to.
>
> Note that the vm_op
On Fri, Sep 13, 2019 at 06:27:00PM -0400, Lyude Paul wrote:
> Some random issues with documentation that I noticed while working on
> nouveau the other day. There are no functional changes in this series.
Nice! On all three:
Reviewed-by: Daniel Vetter
>
> Lyude Paul (3):
> drm/encoder: Fix
On Tue, Sep 10, 2019 at 10:10:49AM -0700, Rob Clark wrote:
> On Tue, Sep 10, 2019 at 9:34 AM Robin Murphy wrote:
> > On 06/09/2019 22:44, Rob Clark wrote:
> > > NOTE that in discussion of previous revisions, RMRR came up. This is
> > > not really a replacement for RMRR (nor does RMRR really provi
https://bugs.freedesktop.org/show_bug.cgi?id=111232
--- Comment #10 from bibitocarlos ---
Tried with "iommu=offiommu=off amdgpu.ppfeaturemask=0x3fff", no change,
green screen.
--
You are receiving this mail because:
You are the assignee for the bug.__
1 - 100 of 153 matches
Mail list logo
