https://bugs.freedesktop.org/show_bug.cgi?id=111324
Bug ID: 111324
Summary: ha
Product: DRI
Version: unspecified
Hardware: All
OS: Windows (All)
Status: NEW
Severity: normal
Priority:
Am 07.08.19 um 23:19 schrieb Daniel Vetter:
> On Wed, Jul 31, 2019 at 10:55:02AM +0200, Daniel Vetter wrote:
>> On Thu, Jun 27, 2019 at 09:28:11AM +0200, Christian König wrote:
>>> Hi Daniel,
>>>
>>> those fails look like something random to me and not related to my patch
>>> set. Correct?
>> First
Hi, Jitao:
On Wed, 2019-08-07 at 14:02 +0800, Jitao Shi wrote:
> The factor depends on the divider of DPI in MT8183, therefore,
> we should fix this factor to the right and new one.
>
Reviewed-by: CK Hu
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 18 ++
Hi Jason,
this mail also somehow ended up to be rejected by our spam filter and
I'm not sure why :(
Anyway, feel free to add my Acked-by. From the technical point I would
give an r-b as well, but I'm not a native speaker of English.
Cheers,
Christian.
Am 08.08.19 um 06:47 schrieb Jason Ekstra
On Thu, Aug 8, 2019 at 9:09 AM Koenig, Christian
wrote:
>
> Am 07.08.19 um 23:19 schrieb Daniel Vetter:
> > On Wed, Jul 31, 2019 at 10:55:02AM +0200, Daniel Vetter wrote:
> >> On Thu, Jun 27, 2019 at 09:28:11AM +0200, Christian König wrote:
> >>> Hi Daniel,
> >>>
> >>> those fails look like someth
Adding a pile of people since there's lots of discussoins going on around this.
-Daniel
On Wed, Aug 7, 2019 at 10:50 PM Daniel Vetter wrote:
>
> On Fri, Jun 14, 2019 at 08:10:20AM +0100, Chris Wilson wrote:
> > Signed-off-by: Chris Wilson
>
> Not sure this works, 2 thoughts way down ...
>
> > --
Hi Ray,
at 00:03, Huang, Ray wrote:
May I know the all firmware version in your system?
# cat amdgpu_firmware_info
VCE feature version: 0, firmware version: 0x
UVD feature version: 0, firmware version: 0x
MC feature version: 0, firmware version: 0x
ME feature version:
On Wed, Aug 07, 2019 at 06:57:24AM +, Koenig, Christian wrote:
> Am 06.08.19 um 22:03 schrieb Jason Gunthorpe:
> > On Tue, Aug 06, 2019 at 02:58:58PM -0400, Alex Deucher wrote:
> >> On Tue, Aug 6, 2019 at 1:51 PM Kuehling, Felix
> >> wrote:
> >>> On 2019-08-06 13:44, Jason Gunthorpe wrote:
>
On Tue, Aug 6, 2019 at 7:13 PM Will Deacon wrote:
>
> On Wed, Jul 24, 2019 at 03:20:59PM +0100, Will Deacon wrote:
> > On Wed, Jul 24, 2019 at 04:16:49PM +0200, Andrey Konovalov wrote:
> > > On Wed, Jul 24, 2019 at 4:02 PM Will Deacon wrote:
> > > > On Tue, Jul 23, 2019 at 08:03:29PM +0200, Andre
On 8/7/19 7:36 PM, Ira Weiny wrote:
On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
On Wed 07-08-19 10:37:26, Jan Kara wrote:
On Fri 02-08-19 12:14:09, John Hubbard wrote:
On 8/2/19 7:52 AM, Jan Kara wrote:
On Fri 02-08-19 07:24:43, Matthew Wilcox wrote:
On Fri, Aug 02, 2019 at
On Tue, Aug 06, 2019 at 07:05:45PM +0300, Christoph Hellwig wrote:
> All users pass PAGE_SIZE here, and if we wanted to support single
> entries for huge pages we should really just add a HMM_FAULT_HUGEPAGE
> flag instead that uses the huge page size instead of having the
> caller calculate that si
On 8/7/19 3:33 AM, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in comm
On Tue, Aug 06, 2019 at 07:05:47PM +0300, Christoph Hellwig wrote:
> pte_index is an internal arch helper in various architectures,
> without consistent semantics. Open code that calculation of a PMD
> index based on the virtual address instead.
>
> Signed-off-by: Christoph Hellwig
> ---
> mm/h
On 8/7/19 3:33 AM, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in comm
at 14:29, Huang, Ray wrote:
-Original Message-
From: Kai-Heng Feng
Sent: Thursday, August 08, 2019 1:45 AM
To: Huang, Ray
Cc: Deucher, Alexander ; Koenig, Christian
; Zhou, David(ChunMing)
; amd-gfx list ;
dri-devel@lists.freedesktop.org; LKML ;
Anthony Wong
Subject: Re: [Regression]
On 06/08/2019 21:25, Alyssa Rosenzweig wrote:
>>> It's not obvious to me when it actually needs to be enabled. Besides the
>>> errata, it's only when... device_nr=1 for a compute-only job in kbase?
>>>
>>> I'm afraid I don't know nearly enough about how kbase plumbs CL to grok
>>> the signifiance..
On Fri, Jul 26, 2019 at 07:23:13PM +0200, Andrzej Pietrasiewicz wrote:
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
> Reviewed-by: Neil Armstrong
This patch results in a crash when running qemu:versatilepb.
Unable to handle kernel NULL point
On 06/08/2019 22:08, Rob Herring wrote:
On Tue, Aug 6, 2019 at 2:25 PM Alyssa Rosenzweig
wrote:
While newer kbase include only the numbers of errata, older kbase
releases included one-line descriptions for each errata, which is useful
for those working on the driver. Import these descriptions.
Hi,
After commit 005440066f92 ("drm/amdgpu: enable gfxoff again on raven series
(v2)”), browsers on Raven Ridge systems cause serious corruption like this:
https://launchpadlibrarian.net/436319772/Screenshot%20from%202019-08-07%2004-20-34.png
Firmwares for Raven Ridge is up-to-date.
Kai-Heng
Hi John,
john.hubb...@gmail.com writes:
> diff --git a/arch/powerpc/mm/book3s64/iommu_api.c
> b/arch/powerpc/mm/book3s64/iommu_api.c
> index b056cae3388b..e126193ba295 100644
> --- a/arch/powerpc/mm/book3s64/iommu_api.c
> +++ b/arch/powerpc/mm/book3s64/iommu_api.c
> @@ -203,6 +202,7 @@ static voi
On Tue, Aug 06, 2019 at 07:05:42PM +0300, Christoph Hellwig wrote:
> There is only a single place where the pgmap is passed over a function
> call, so replace it with local variables in the places where we deal
> with the pgmap.
>
> Signed-off-by: Christoph Hellwig
> mm/hmm.c | 62 ++
On Tue, Aug 06, 2019 at 07:05:38PM +0300, Christoph Hellwig wrote:
>
> Hi Jérôme, Ben, Felix and Jason,
>
> below is a series against the hmm tree which cleans up various minor
> bits and allows HMM_MIRROR to be built on all architectures.
>
> Diffstat:
>
> 11 files changed, 94 insertions(+
Ah-ha! Thank you for the detailed explanation; this makes a lot more
sense now :)
> In practice all this only really matters on the T62x GPU. All other GPUs
> have only one core group[1]. So it only really makes sense to use JS2 on
> the T62x where you want to use both JS1 and JS2 to run two indep
Hi Dave & Daniel -
drm-intel-fixes-2019-08-08:
drm/i915 fixes for v5.3-rc4:
- Fix GLK DSI escape clock setting
- Fix a memleak on HDCP revoked Ksv error path
BR,
Jani.
The following changes since commit e21a712a9685488f5ce80495b37b9fdbe96c230d:
Linux 5.3-rc3 (2019-08-04 18:40:12 -0700)
are
On Tue, Aug 06, 2019 at 11:47:44PM +, Kuehling, Felix wrote:
> On 2019-08-06 19:15, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > The sequence of mmu_notifier_unregister_no_release(),
> > mmu_notifier_call_srcu() is identical to mmu_notifier_put() with the
> > free_notifier callback
On Wed, Aug 07, 2019 at 03:30:38PM +0100, Steven Price wrote:
> On 07/08/2019 15:15, Matthew Wilcox wrote:
> > On Tue, Aug 06, 2019 at 11:40:00PM -0700, Christoph Hellwig wrote:
> >> On Tue, Aug 06, 2019 at 12:09:38PM -0700, Matthew Wilcox wrote:
> >>> Has anyone looked at turning the interface ins
On Wed, Aug 07, 2019 at 01:38:08PM +0100, Mark Rutland wrote:
> > I *believe* that there are not alias mappings (that I don't control
> > myself) for pages coming from
> > shmem_file_setup()/shmem_read_mapping_page()..
>
> AFAICT, that's regular anonymous memory, so there will be a cacheable
> a
On Wed, Aug 07, 2019 at 05:49:59PM +0100, Mark Rutland wrote:
> I'm fairly confident that the linear/direct map cacheable alias is not
> torn down when pages are allocated. The gneeric page allocation code
> doesn't do so, and I see nothing the shmem code to do so.
It is not torn down anywhere.
>
https://bugzilla.kernel.org/show_bug.cgi?id=203471
--- Comment #12 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to vr00m from comment #11)
> ICYMI, I was able to solve the tearing problem with raven ridge using
> iommu=soft boot param.
Tearing isn't related to the IOMMU. Scatter/gather s
On Thu, Aug 8, 2019 at 9:09 AM Koenig, Christian
wrote:
>
> Am 07.08.19 um 23:19 schrieb Daniel Vetter:
> > On Wed, Jul 31, 2019 at 10:55:02AM +0200, Daniel Vetter wrote:
> >> On Thu, Jun 27, 2019 at 09:28:11AM +0200, Christian König wrote:
> >>> Hi Daniel,
> >>>
> >>> those fails look like someth
On Wed, Aug 07, 2019 at 10:30:04AM -0700, Rob Clark wrote:
> So, we do end up using GFP_HIGHUSER, which appears to get passed thru
> when shmem gets to the point of actually allocating pages.. not sure
> if that just ends up being a hint, or if it guarantees that we don't
> get something in the lin
On 2019-08-08 8:29 a.m., Huang, Ray wrote:
>> From: Kai-Heng Feng
>> at 00:03, Huang, Ray wrote:
>>
>>> May I know the all firmware version in your system?
>
> Seems to the issue we encountered with IOMMU enabled. Could you please
> disable iommu in SBIOS or GRUB?
The driver needs to work with
On 2019-08-08 7:31 a.m., Alex Deucher wrote:
> On Wed, Aug 7, 2019 at 11:49 PM Mikhail Gavrilov
> wrote:
>>
>> Unfortunately error "gnome-shell: page allocation failure: order:4,
>> mode:0x40cc0(GFP_KERNEL|__GFP_COMP),
>> nodemask=(null),cpuset=/,mems_allowed=0" still happens even with
>> applying
> -Original Message-
> From: Michel Dänzer
> Sent: Thursday, August 08, 2019 4:10 PM
> To: Huang, Ray ; Kai-Heng Feng
>
> Cc: Zhou, David(ChunMing) ; LKML ker...@vger.kernel.org>; dri-devel@lists.freedesktop.org; Anthony Wong
> ; amd-gfx list g...@lists.freedesktop.org>; Deucher, Alexan
śr., 24 lip 2019 o 10:25 Bartosz Golaszewski napisał(a):
>
> From: Bartosz Golaszewski
>
> While working on my other series related to gpio-backlight[1] I noticed
> that we could simplify the driver if we made the only user of platform
> data use GPIO lookups and device properties. This series tr
https://bugs.freedesktop.org/show_bug.cgi?id=111331
Bug ID: 111331
Summary: bu
Product: DRI
Version: unspecified
Hardware: All
OS: Windows (All)
Status: NEW
Severity: normal
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=22
--- Comment #7 from Wiktor Kaczor ---
I have the same problem using the Lenovo 530S-14ARR with Ryzen 5 2500U.
The XFCE4 compositing makes the system immediately freeze as soon as I log in
on Manjaro with the 5.2.4-1 kernel.
On the 5.3rc2 kern
Now that we have the DT validation in place, let's convert the device tree
bindings for the Amlogic Display Controller over to YAML schemas.
The original example has a leftover "dmc" memory cell, that has been
removed in the yaml rewrite.
The port connection table has been dropped in favor of a d
Now that we have the DT validation in place, let's convert the device tree
bindings for the Amlogic Synopsys DW-HDMI specifics over to YAML schemas.
The original example and usage of clock-names uses a reversed "isfr"
and "iahb" clock-names, the rewritten YAML bindings uses the reversed
instead of
This patchset converts the existing text bindings to YAML schemas.
Those bindings have a lot of texts, thus is interesting to convert.
All have been tested using :
$ make ARCH=arm64 dtbs_check
Issues with the amlogic arm64 DTs has already been identified thanks
to the validation scripts. The DT
The amlogic,meson-dw-hdmi.txt and amlogic,meson-vpu.txt has been
converted to YAML schemas, update MAINTAINERS to match them again.
Signed-off-by: Neil Armstrong
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6426db5198f0..
drm-misc-fixes-2019-08-08:
drm-misc-fixes for v5.3-rc4:
- Suspend fix for rockchip
- Fix unterminated strncpy cmdline mode parser
The following changes since commit 58540594570778fd149cd8c9b2bff61f2cefa8c9:
drm/bochs: Use shadow buffer for bochs framebuffer console (2019-08-01
15:01:42 +0200)
https://bugs.freedesktop.org/show_bug.cgi?id=111331
Andre Klapper changed:
What|Removed |Added
Product|DRI |Spam
Group|
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 a single patch this time with a new ioctl.
Cheers,
Lionel Landwerlin (1):
drm/syncobj: add sideband payload
drivers/gpu/drm/drm_internal.h | 2 ++
drivers/gpu/drm/drm_ioctl.c| 3 ++
drivers/gpu/drm/drm_syncobj.c | 63 +++---
include/drm/drm_syn
https://bugs.freedesktop.org/show_bug.cgi?id=22
Michel Dänzer changed:
What|Removed |Added
CC||mar...@gmail.com,
|
Am 08.08.19 um 11:04 schrieb Lionel Landwerlin:
> 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 thre
Rename the embedded struct vma_offset_manager, it is named _vma_manager
now. ttm_bo_device.vma_manager is a pointer now, pointing to the
embedded ttm_bo_device._vma_manager by default.
Add ttm_bo_device_init_with_vma_manager() function which allows to
initialize ttm with a different vma manager.
From: Christoph Hellwig
We should only call dma_max_mapping_size for devices that have a DMA mask
set, otherwise we can run into a NULL pointer dereference that will crash
the system.
Also we need to do right shift to get the sectors from the size in bytes,
not a left shift.
Fixes: bdd17bdef7d8
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
turm allows to create common helper functions.
This patch starts off with a gem_ttm_bo_device_init() helper function
which initializes ttm with the vma offset m
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_ttm.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 3a24145dd516..bcf48b062a85 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem_vram_helper.h | 6 +--
drivers/gpu/drm/drm_gem_vram_helper.c | 48 ---
drivers/gpu/drm/drm_vram_mm_helper.c | 6 +--
.../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 1 -
drivers/gpu/drm/Kconfig
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem_vram_helper.h | 3 ---
drivers/gpu/drm/drm_gem_vram_helper.c | 22 +-
2 files changed, 1 insertion(+), 24 deletions(-)
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index 701d2c46a
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h| 4 +---
drivers/gpu/drm/qxl/qxl_object.h | 5 -
drivers/gpu/drm/qxl/qxl_drv.c| 1 -
drivers/gpu/drm/qxl/qxl_dumb.c | 17 -
drivers/gpu/drm/qxl/qxl_ioctl.c | 5 +++--
drivers/gpu/drm/qxl/qxl_ttm.c
Christoph Hellwig (1):
scsi: core: fix the dma_max_mapping_size call
Gerd Hoffmann (7):
ttm: turn ttm_bo_device.vma_manager into a pointer
drm/ttm: add gem_ttm_bo_device_init()
drm/vram: switch vram helpers to the new gem_ttm_bo_device_init()
drm/qxl: switch qxl to the new gem_ttm_bo_d
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem_ttm_helper.h | 2 ++
drivers/gpu/drm/drm_gem_ttm_helper.c | 22 ++
2 files changed, 24 insertions(+)
diff --git a/include/drm/drm_gem_ttm_helper.h b/include/drm/drm_gem_ttm_helper.h
index 43c9db3583cc..78e4d8930fec 100
On 08/08/2019 12:32, Koenig, Christian wrote:
Am 08.08.19 um 11:04 schrieb Lionel Landwerlin:
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
Dave, Daniel
A single memory leak fix from Colin Ian King.
The following changes since commit f536579c148249505b388d525ac1866e080fd66a:
Merge tag 'drm-fixes-5.3-2019-08-07' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2019-08-08 13:25:50
+1000)
are available in the Git repos
Am 08.08.19 um 11:36 schrieb Gerd Hoffmann:
> Rename the embedded struct vma_offset_manager, it is named _vma_manager
> now. ttm_bo_device.vma_manager is a pointer now, pointing to the
> embedded ttm_bo_device._vma_manager by default.
>
> Add ttm_bo_device_init_with_vma_manager() function which al
On Wed, Aug 07, 2019 at 10:48:56AM +0200, Daniel Vetter wrote:
> >other drm drivers how do they guarantee addressability without an
> >iommu?)
>
> We use shmem to get at swappable pages. We generally just assume that
> the gpu can get at those pages, but things fall apart in fun ways:
> -
On Wed, Aug 07, 2019 at 09:09:53AM -0700, Rob Clark wrote:
> > > (Eventually I'd like to support pages passed in from userspace.. but
> > > that is down the road.)
> >
> > Eww. Please talk to the iommu list before starting on that.
>
> This is more of a long term goal, we can't do it until we hav
On 08/08/2019 12:42, Lionel Landwerlin wrote:
On 08/08/2019 12:32, Koenig, Christian wrote:
Am 08.08.19 um 11:04 schrieb Lionel Landwerlin:
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 imp
The omapfb platform devices does not have a DMA mask set. The
traditional arm DMA code ignores, but the generic dma-direct/swiotlb
has stricter checks and thus fails mappings without a DMA mask.
As we use swiotlb for arm with LPAE now, omap needs to catch up
and actually set a DMA mask.
Fixes: ad
On Thu, Aug 08, 2019 at 09:58:27AM +0200, Christoph Hellwig wrote:
> On Wed, Aug 07, 2019 at 05:49:59PM +0100, Mark Rutland wrote:
> > For arm64, we can tear down portions of the linear map, but that has to
> > be done explicitly, and this is only possible when using rodata_full. If
> > not using r
On Thu, Aug 08, 2019 at 11:36:55AM +0200, Gerd Hoffmann wrote:
> From: Christoph Hellwig
>
> We should only call dma_max_mapping_size for devices that have a DMA mask
> set, otherwise we can run into a NULL pointer dereference that will crash
> the system.
>
> Also we need to do right shift to g
On Thu, Aug 08, 2019 at 11:20:53AM +0100, Mark Rutland wrote:
> On Thu, Aug 08, 2019 at 09:58:27AM +0200, Christoph Hellwig wrote:
> > On Wed, Aug 07, 2019 at 05:49:59PM +0100, Mark Rutland wrote:
> > > For arm64, we can tear down portions of the linear map, but that has to
> > > be done explicitly
Hi,
On Fri, Jul 05, 2019 at 07:17:21PM +0200, Lucas Stach wrote:
> This allows to decouple the cmdbuf suballocator create and mapping
> the region into the GPU address space. Allowing multiple AS to share
> a single cmdbuf suballoc.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/
https://bugs.freedesktop.org/show_bug.cgi?id=110865
--- Comment #6 from Martin ---
Sadly it did not help.
the MCLK is still fixed at 2000MHz.
How can I verify that I did everything correctly?
I just rebuilt Kernel 5.2.6 from Fedoras srpm and added the patch in the spec
file.
Or could it be that
We can't free "workload" until after the printk or it's a use after
free.
Fixes: 2089a76ade90 ("drm/i915/gvt: Checking workload's gma earlier")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/gvt/scheduler.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gp
On Thu, Aug 08, 2019 at 11:20:53AM +0100, Mark Rutland wrote:
> On Thu, Aug 08, 2019 at 09:58:27AM +0200, Christoph Hellwig wrote:
> > On Wed, Aug 07, 2019 at 05:49:59PM +0100, Mark Rutland wrote:
> > > For arm64, we can tear down portions of the linear map, but that has to
> > > be done explicitly
On Thu, Aug 08, 2019 at 09:48:49AM +, Koenig, Christian wrote:
> Am 08.08.19 um 11:36 schrieb Gerd Hoffmann:
> > Rename the embedded struct vma_offset_manager, it is named _vma_manager
> > now. ttm_bo_device.vma_manager is a pointer now, pointing to the
> > embedded ttm_bo_device._vma_manager
Quoting Dan Carpenter (2019-08-08 11:32:36)
> We can't free "workload" until after the printk or it's a use after
> free.
>
> Fixes: 2089a76ade90 ("drm/i915/gvt: Checking workload's gma earlier")
> Signed-off-by: Dan Carpenter
That's the simpler patch,
Reviewed-by: Chris Wilson
-Chris
_
Am 08.08.19 um 09:29 schrieb Daniel Vetter:
> On Thu, Aug 8, 2019 at 9:09 AM Koenig, Christian
> wrote:
>> Am 07.08.19 um 23:19 schrieb Daniel Vetter:
>>> On Wed, Jul 31, 2019 at 10:55:02AM +0200, Daniel Vetter wrote:
On Thu, Jun 27, 2019 at 09:28:11AM +0200, Christian König wrote:
> Hi D
On 05.08.2019 14:23, Thierry Reding wrote:
> From: Thierry Reding
>
> Store capabilities in max_* fields and add separate fields for the
> currently selected settings.
>
> Cc: Rob Clark
> Signed-off-by: Thierry Reding
For bridge and core part:
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
On Thu, Aug 8, 2019 at 1:05 PM Koenig, Christian
wrote:
> Am 08.08.19 um 09:29 schrieb Daniel Vetter:
> > On Thu, Aug 8, 2019 at 9:09 AM Koenig, Christian
> > wrote:
> >> Am 07.08.19 um 23:19 schrieb Daniel Vetter:
> >>> On Wed, Jul 31, 2019 at 10:55:02AM +0200, Daniel Vetter wrote:
> On Thu
On 05.08.2019 14:23, Thierry Reding wrote:
> From: Thierry Reding
>
> Rather than storing capabilities as flags in an integer, use a separate
> boolean per capability. This simplifies the code that checks for these
> capabilities.
>
> Cc: Rob Clark
> Signed-off-by: Thierry Reding
> ---
> driver
On 05.08.2019 14:23, Thierry Reding wrote:
> From: Thierry Reding
>
> The DP specification uses the term "default framing" instead of "non-
> enhanced framing".
>
> Signed-off-by: Thierry Reding
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/gpu/drm/bridge/tc358767.c | 3 +--
On Thu, Aug 08, 2019 at 11:55:06AM +0200, Christoph Hellwig wrote:
> On Wed, Aug 07, 2019 at 10:48:56AM +0200, Daniel Vetter wrote:
> > >other drm drivers how do they guarantee addressability without an
> > >iommu?)
> >
> > We use shmem to get at swappable pages. We generally just assume t
On Thu, Aug 08, 2019 at 12:35:21PM +0200, Gerd Hoffmann wrote:
> On Thu, Aug 08, 2019 at 09:48:49AM +, Koenig, Christian wrote:
> > Am 08.08.19 um 11:36 schrieb Gerd Hoffmann:
> > > Rename the embedded struct vma_offset_manager, it is named _vma_manager
> > > now. ttm_bo_device.vma_manager is
Hi Daniel, Dave,
Here is a do-over of the previous drm-misc-next PR.
As I said last time, there's a bunch of patches scattered all around
the core and the usual active drivers. The amount of patches is a bit
huge (and it only got worse since), but nothing seems to really stand
out.
Sean (thanks!
On 8/8/19 2:02 PM, Daniel Vetter wrote:
On Thu, Aug 08, 2019 at 12:35:21PM +0200, Gerd Hoffmann wrote:
On Thu, Aug 08, 2019 at 09:48:49AM +, Koenig, Christian wrote:
Am 08.08.19 um 11:36 schrieb Gerd Hoffmann:
Rename the embedded struct vma_offset_manager, it is named _vma_manager
now. tt
Hi Greg,
Thank you for the patch.
On Thu, Jun 13, 2019 at 01:57:49PM +0200, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc
Am 08.08.19 um 14:43 schrieb Thomas Hellström (VMware):
> On 8/8/19 2:02 PM, Daniel Vetter wrote:
>> On Thu, Aug 08, 2019 at 12:35:21PM +0200, Gerd Hoffmann wrote:
>>> On Thu, Aug 08, 2019 at 09:48:49AM +, Koenig, Christian wrote:
Am 08.08.19 um 11:36 schrieb Gerd Hoffmann:
> Rename th
Hi,
Hopefully all good this time.
Cheers,
Lionel Landwerlin (1):
drm/syncobj: add sideband payload
drivers/gpu/drm/drm_internal.h | 4 ++
drivers/gpu/drm/drm_ioctl.c| 5 +++
drivers/gpu/drm/drm_syncobj.c | 79 +-
include/drm/drm_syncobj.h | 9
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
We clear the callback list on kref_put so that by the time we
release the fence it is unused. No one should be adding to the cb_list
that they don't themselves hold a reference for.
This small change is actually making the structure 16% smaller.
Signed-off-by: Christian König
Reviewed-by: Chris
On Mon, 2019-08-05 at 14:23 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Make use of the newly added drm_dp_aux_rd_interval() helper in existing
> DP link training helpers and add comments about minimum required delays
> mandated by the DP specification.
This patch does not add any co
On Mon, 2019-08-05 at 14:23 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Remove a gratuituous blank line in one place and add a blank line in
> another to improve readability.
Seems like the comment description is outdated here as well.
> Signed-off-by: Thierry Reding
> ---
> drive
Hi,
Thank you for your remarks. I will take them into account while preparing RFCv2.
On Mon, 2019-07-29 at 10:52 +0900, Chanwoo Choi wrote:
> Hi,
>
> On 19. 7. 23. 오후 9:20, Artur Świgoń wrote:
> > This patch adds interconnect functionality to the exynos-bus devfreq
> > driver.
> >
> > The SoC t
Hi,
Thank you for your comments.
On Tue, 2019-08-06 at 13:41 +, Leonard Crestez wrote:
> On 23.07.2019 15:21, Artur Świgoń wrote:
>
> > +static int exynos_bus_icc_aggregate(struct icc_node *node, u32 avg_bw,
> > + u32 peak_bw, u32 *agg_avg, u32 *agg_peak)
> > +{
On Mon, 2019-08-05 at 14:23 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Use existing parsing helpers to probe a DisplayPort link.
>
> Signed-off-by: Thierry Reding
Reviewed-by: Philipp Zabel
regards
Philipp
___
dri-devel mailing list
dr
We clear the callback list on kref_put so that by the time we
release the fence it is unused. No one should be adding to the cb_list
that they don't themselves hold a reference for.
This small change is actually making the structure 16% smaller.
v2: add the comment to the code as well.
Signed-of
The propursal is fine with me.
one question:
how to wait sideband payload? Following patch will show that?
-David
在 2019/8/8 21:14, Lionel Landwerlin 写道:
> The Vulkan timeline semaphores allow signaling to happen on the point
> of the timeline without all of the its dependencies to be created.
On Mon, 2019-08-05 at 14:23 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> While probing the DisplayPort link, query the fast training capability.
> If supported, drivers can use the fast link training sequence instead of
> the more involved full link training sequence.
>
> Signed-off-b
Hi,
On Wed, 2019-08-07 at 17:21 +0300, Georgi Djakov wrote:
> Hi Artur,
>
> On 8/1/19 10:59, Artur Świgoń wrote:
> > Hi Georgi,
> >
> > On Fri, 2019-07-26 at 11:05 +0300, Georgi Djakov wrote:
> > > Hi Artur,
> > >
> > > On 7/23/19 15:20, Artur Świgoń wrote:
> > > > This patch adds interconnect
https://bugs.freedesktop.org/show_bug.cgi?id=110865
--- Comment #7 from Alex Deucher ---
(In reply to Martin from comment #6)
> Sadly it did not help.
> the MCLK is still fixed at 2000MHz.
>
> How can I verify that I did everything correctly?
You can add a printk to the patch to verify that it'
On Mon, 2019-08-05 at 14:23 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Use microsecond sleeps for the clock recovery and channel equalization
> delays during link training. The duration of these delays can be from
> 100 us up to 16 ms. It is rude to busy-loop for that amount of time.
On Mon, 2019-08-05 at 14:23 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> If the transmitter supports pre-emphasis post cursor2 the sink will
> request adjustments in a similar way to how it requests adjustments to
> the voltage swing and pre-emphasis settings.
>
> Add a helper to extr
https://bugs.freedesktop.org/show_bug.cgi?id=110865
--- Comment #8 from Alex Deucher ---
looks like the DC code does not set up the multi_monitor_in_sync flag properly.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-d
Interesting question :)
I didn't see any usecase for that.
This sideband payload value is used for a wait so waiting on the wait
value for another wait is bit meta :)
Do you have a use case for that?
-Lionel
On 08/08/2019 16:23, Chunming Zhou wrote:
The propursal is fine with me.
one quest
1 - 100 of 265 matches
Mail list logo
