On Wed, 19 May 2021, Zhenyu Wang wrote:
> Reviewed-by: Zhenyu Wang
>
> Thanks!
Thanks for the review. Please also let Greg know whether he can pick
this up via the debugfs tree; I don't care either way.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
On 5/18/21 6:30 PM, Christian König wrote:
Am 18.05.21 um 18:07 schrieb Thomas Hellström:
On 5/18/21 5:42 PM, Christian König wrote:
Am 18.05.21 um 17:38 schrieb Thomas Hellström:
On 5/18/21 5:28 PM, Christian König wrote:
Am 18.05.21 um 17:20 schrieb Thomas Hellström:
On 5/18/21 5:18 P
On 5/18/21 3:23 PM, Christoph Hellwig wrote:
On Mon, May 17, 2021 at 11:46:35PM +0200, Thomas Hellström wrote:
Apart from the caching aliasing Mattew brought up, doesn't the
remap_pfn_range_xxx() family require the mmap_sem held in write mode since
it modifies the vma structure? remap_io_sg()
On 5/18/21 5:00 PM, Matthew Auld wrote:
On Tue, 18 May 2021 at 14:21, Christoph Hellwig wrote:
On Mon, May 17, 2021 at 06:06:44PM +0100, Matthew Auld wrote:
Looks like it is caused by the validation failure then. Which means the
existing code is doing something wrong in its choice of the pa
On Sat, 2021-04-24 at 07:50 +0800, Chun-Kuang Hu wrote:
> Hi, Jitao:
>
> Jitao Shi 於 2021年4月20日 週二 下午9:26寫道：
> >
> > Reset dsi HW to default when power on. Prevent the setting differet
> > between bootloader and kernel.
> >
> > Signed-off-by: Jitao Shi
> > ---
> > drivers/gpu/drm/mediatek/mtk_d
[AMD Official Use Only]
I have reverted Chris' patch, still hit this failure.
Just see two lines in Chris' patch. Any BO in cpu domian would be swapout
first. That is why we hit this issue frequently now. But the bug is there long
time ago.
- for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
-
On Sat, 2021-04-24 at 00:36 +0800, Chun-Kuang Hu wrote:
> Hi, Jitao:
>
> Jitao Shi 於 2021年4月20日 週二 下午9:26寫道：
> >
> > Add the drm_panel_prepare_power and drm_panel_unprepare_power control.
> > Turn on panel power(drm_panel_prepare_power) and control before dsi
> > enable. And then dsi enable, send
[AMD Official Use Only]
yes, we really dont swapout SG BOs.
The problems is that before we validate a userptr BO, we create this BO in CPU
domain by default. So this BO has chance to swapout.
we set flag TTM_PAGE_FLAG_SG on userptr BO in popluate() which is too late.
I have not try to revert Chr
On Wed, 19 May 2021 at 08:01, Lyude Paul wrote:
>
> Looks like these tests might still need to be fixed up a bit:
>
> [ 34.785042] (null): [drm:drm_dp_sideband_parse_req [drm_kms_helper]]
> connection status reply parse length fail 2 1
> [ 34.785082] (null): [drm:drm_dp_sideband_parse_req [
Hi Bjorn
I had a quick glance on the series and before getting to other things
wanted to know how you are initializing two different connectors for
DP & EDP resp.
The connector type for DP should be DRM_MODE_CONNECTOR_DisplayPort and
eDP should be DRM_MODE_CONNECTOR_eDP.
We need both to be cr
On Thu, May 06, 2021 at 12:13:17PM -0700, Matthew Brost wrote:
> From: Chris Wilson
>
> The different submission backends each have their own preferred
> behaviour and interrupt setup. Let each handle their own interrupts.
>
> This becomes more useful later as we to extract the use of auxiliary
Swapping SG BOs makes no sense, because TTM doesn't own the pages of
this type of BO.
Last I checked, userptr BOs (and other SG BOs) were protected from
swapout by the fact that they would not be added to the swap-LRU. But it
looks like Christian just removed the swap-LRU. I guess this broke t
On Thu, May 06, 2021 at 12:13:16PM -0700, Matthew Brost wrote:
> From: Chris Wilson
>
> Since we setup the submission method for the engines once, it is easy to
> assign an enum and use that instead of probing into the backends.
>
> Signed-off-by: Matthew Brost
> Signed-off-by: Chris Wilson
>
[AMD Official Use Only]
To observe the issue. I made one kfdtest case for debug.
It just alloc a userptr memory and detect if memory is corrupted.
I can hit this failure in 2 minutes. :(
diff --git a/tests/kfdtest/src/KFDMemoryTest.cpp
b/tests/kfdtest/src/KFDMemoryTest.cpp
index 70c8033..a72f53f
Signed-off-by: xinhui pan
---
drivers/gpu/drm/ttm/ttm_device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index 510e3e001dab..a9772fcc8f9c 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_devic
cpu 1 cpu 2
kfd alloc BO A(userptr) alloc BO B(GTT)
->init -> validate -> init -> validate -> populate
init_user_pages -> swapout BO A //hit ttm
pages limit
-> g
On 2021.05.18 18:17:05 +0200, Greg Kroah-Hartman wrote:
> There is no need to keep the dentry around for the debugfs kvmgt cache
> file, as we can just look it up when we want to remove it later on.
> Simplify the structure by removing the dentry and relying on debugfs
> to find the dentry to remov
On Thu, May 06, 2021 at 12:13:15PM -0700, Matthew Brost wrote:
> From: Chris Wilson
>
> Now that we no longer switch back and forth between guc and execlists,
> we no longer need to restore the backend's vfunc and can leave them set
> after initialisation. The only catch is that we lose the submi
On Tue, May 18, 2021 at 08:03:27PM -0300, Jason Gunthorpe wrote:
> Logically during fork all these device exclusive pages should be
> reverted back to their CPU pages, write protected and the CPU page PTE
> copied to the fork.
>
> We should not copy the device exclusive page PTE to the fork. I thi
Add entry fpr i915 new parallel submission uAPI plan.
v2:
(Daniel Vetter):
- Expand logical order explaination
- Add dummy header
- Only allow N BBs in execbuf IOCTL
- Configure parallel submission per slot not per gem context
Cc: Tvrtko Ursulin
Cc: Tony Ye
CC: Carl Zhang
Cc: Daniel V
Add entry for i915 GuC submission / DRM scheduler integration plan.
Follow up patch with details of new parallel submission uAPI to come.
v2:
(Daniel Vetter)
- Expand explaination of why bonding isn't supported for GuC
submission
- CC some of the DRM scheduler maintainers
- Add priority
Subject and patches say it all.
v2: Address comments, patches has details of changes
Signed-off-by: Matthew Brost
Matthew Brost (2):
drm/doc/rfc: i915 GuC submission / DRM scheduler
drm/doc/rfc: i915 new parallel submission uAPI plan
Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 +++
On Wed, 12 May 2021 at 23:33, Philipp Zabel wrote:
>
> Hi Dave, Daniel,
>
> The following changes since commit 6efb943b8616ec53a5e444193dccf1af9ad627b5:
>
> Linux 5.13-rc1 (2021-05-09 14:17:44 -0700)
>
> are available in the Git repository at:
>
> git://git.pengutronix.de/git/pza/linux.git tag
On Tue, May 18, 2021 at 04:29:14PM -0400, Peter Xu wrote:
> On Tue, May 18, 2021 at 04:45:09PM -0300, Jason Gunthorpe wrote:
> > On Tue, May 18, 2021 at 02:01:36PM -0400, Peter Xu wrote:
> > > > > Indeed it'll be odd for a COW page since for COW page then it means
> > > > > after
> > > > > parent/
On 2021-05-18 16:19, Harry Wentland wrote:
On 2021-05-18 3:56 a.m., Pekka Paalanen wrote:
On Mon, 17 May 2021 15:39:03 -0400
Vitaly Prosyak wrote:
On 2021-05-17 12:48 p.m., Sebastian Wick wrote:
On 2021-05-17 10:57, Pekka Paalanen wrote:
On Fri, 14 May 2021 17:05:11 -0400
Harry Wentland wr
On Tue, May 18, 2021 at 4:17 PM Daniel Vetter wrote:
>
> On Tue, May 18, 2021 at 7:40 PM Christian König
> wrote:
> >
> > Am 18.05.21 um 18:48 schrieb Daniel Vetter:
> > > On Tue, May 18, 2021 at 2:49 PM Christian König
> > > wrote:
> > >> Hi Jason & Daniel,
> > >>
> > >> Am 18.05.21 um 07:59 sc
Looks like these tests might still need to be fixed up a bit:
[ 34.785042] (null): [drm:drm_dp_sideband_parse_req [drm_kms_helper]]
connection status reply parse length fail 2 1
[ 34.785082] (null): [drm:drm_dp_sideband_parse_req [drm_kms_helper]]
resource status reply parse length fail 2
On Tue, May 18, 2021 at 8:38 PM LABBE Corentin wrote:
> The only solution is to remove "reg = <0>;" and calling the node "port".
> Does it is acceptable ?
It's what I've done in the past at least so looks like the right thing to me.
It is only used in this device tree:
arch/arm/boot/dts/gemini-d
>
> We basically don't know during CS if a BO is shared or not.
Who doesn't know? We should be able to track this quite easily,
userspace either imports or exports buffers,
it can surely keep track of these and flag them.
Is this a userspace might lie to use worry or do you have some really
broke
After removing drm_pci_alloc/free, some instances where drm_pci_free()
would have kfreed the dma handle were skipped.
Ensure these handles are freed properly.
Signed-off-by: Joseph Kogut
---
drivers/gpu/drm/drm_bufs.c | 1 +
drivers/gpu/drm/r128/ati_pcigart.c | 2 ++
2 files changed, 3
On Tue, May 18, 2021 at 7:40 PM Christian König
wrote:
>
> Am 18.05.21 um 18:48 schrieb Daniel Vetter:
> > On Tue, May 18, 2021 at 2:49 PM Christian König
> > wrote:
> >> Hi Jason & Daniel,
> >>
> >> Am 18.05.21 um 07:59 schrieb Daniel Vetter:
> >>> On Tue, May 18, 2021 at 12:49 AM Jason Ekstrand
On Wed, Apr 07, 2021 at 06:42:35PM +1000, Alistair Popple wrote:
[...]
> +static bool try_to_protect(struct page *page, struct mm_struct *mm,
> +unsigned long address, void *arg)
> +{
> + struct ttp_args ttp = {
> + .mm = mm,
> + .address = addr
On 2021-05-18 2:48 p.m., Andrey Grodzovsky wrote:
On 2021-05-18 2:13 p.m., Christian König wrote:
Am 18.05.21 um 20:09 schrieb Andrey Grodzovsky:
On 2021-05-18 2:02 p.m., Christian König wrote:
Am 18.05.21 um 19:43 schrieb Andrey Grodzovsky:
On 2021-05-18 12:33 p.m., Christian König wro
On Tue, May 18, 2021 at 04:45:09PM -0300, Jason Gunthorpe wrote:
> On Tue, May 18, 2021 at 02:01:36PM -0400, Peter Xu wrote:
> > > > Indeed it'll be odd for a COW page since for COW page then it means
> > > > after
> > > > parent/child writting to the page it'll clone into two, then it's a
> > >
* Alistair Popple [210407 04:43]:
> The behaviour of try_to_unmap_one() is difficult to follow because it
> performs different operations based on a fairly large set of flags used
> in different combinations.
>
> TTU_MUNLOCK is one such flag. However it is exclusively used by
> try_to_munlock() w
On Tue, May 18, 2021 at 02:01:36PM -0400, Peter Xu wrote:
> > > Indeed it'll be odd for a COW page since for COW page then it means after
> > > parent/child writting to the page it'll clone into two, then it's a
> > > mistery on
> > > which one will be the one that "exclusived owned" by the device
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #27 from James Zhu (jam...@amd.com) ---
Hi Jeromec, thanks for your feedback, can you also add drm.debug=0x1ff
modprobe? I need log: case 1 dmesg and
/sys/kernel/debug/dri/0/amdgpu_fence_info (if you can). James.
--
You may reply to
On 2021-05-18 2:13 p.m., Christian König wrote:
Am 18.05.21 um 20:09 schrieb Andrey Grodzovsky:
On 2021-05-18 2:02 p.m., Christian König wrote:
Am 18.05.21 um 19:43 schrieb Andrey Grodzovsky:
On 2021-05-18 12:33 p.m., Christian König wrote:
Am 18.05.21 um 18:17 schrieb Andrey Grodzovsky:
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #26 from Jerome C (m...@jeromec.com) ---
(In reply to Jerome C from comment #25)
> I forgot to mention... I'm on kernel 5.13.4
5.12.4 I mean
--
You may reply to this email to add a comment.
You are receiving this mail because:
You
Le Mon, May 17, 2021 at 07:26:24PM -0500, Rob Herring a écrit :
> On Tue, May 11, 2021 at 04:54:48PM +, Corentin Labbe wrote:
> > Converts display/faraday,tve200.txt to yaml.
> >
> > Signed-off-by: Corentin Labbe
> > ---
> > .../bindings/display/faraday,tve200.txt | 54 ---
> >
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #25 from Jerome C (m...@jeromec.com) ---
I forgot to mention... I'm on kernel 5.13.4
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #24 from Jerome C (m...@jeromec.com) ---
(In reply to James Zhu from comment #21)
> Hi Jeromec, to isolate the cause, can you help run two experiments
> separately?
> 1. To run suspend/resume without launching Xorg, just on text mode.
Am 18.05.21 um 20:09 schrieb Andrey Grodzovsky:
On 2021-05-18 2:02 p.m., Christian König wrote:
Am 18.05.21 um 19:43 schrieb Andrey Grodzovsky:
On 2021-05-18 12:33 p.m., Christian König wrote:
Am 18.05.21 um 18:17 schrieb Andrey Grodzovsky:
On 2021-05-18 11:15 a.m., Christian König wrote:
Am 18.05.21 um 19:32 schrieb Thomas Hellström:
[SNIP]
PTE handling is the domain of TTM, drivers should never mess with
that directly.
Hmm. May I humbly suggest a different view on this:
I agree fully for ttm_bo_type_device bos but for ttm_bo_type_kernel,
TTM has no business whatsoever with
On 2021-05-18 2:02 p.m., Christian König wrote:
Am 18.05.21 um 19:43 schrieb Andrey Grodzovsky:
On 2021-05-18 12:33 p.m., Christian König wrote:
Am 18.05.21 um 18:17 schrieb Andrey Grodzovsky:
On 2021-05-18 11:15 a.m., Christian König wrote:
Am 18.05.21 um 17:03 schrieb Andrey Grodzovsky
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #23 from James Zhu (jam...@amd.com) ---
Hi kolAflash,
VCN IP is for video acceleration(for video playback), if vcn ip didn't handle
suspend/resume process properly, we do observe other IP blocks be affected. For
your case it is displa
Am 18.05.21 um 19:43 schrieb Andrey Grodzovsky:
On 2021-05-18 12:33 p.m., Christian König wrote:
Am 18.05.21 um 18:17 schrieb Andrey Grodzovsky:
On 2021-05-18 11:15 a.m., Christian König wrote:
Am 18.05.21 um 17:03 schrieb Andrey Grodzovsky:
On 2021-05-18 10:07 a.m., Christian König wrote:
On Tue, May 18, 2021 at 02:33:34PM -0300, Jason Gunthorpe wrote:
> On Tue, May 18, 2021 at 01:27:42PM -0400, Peter Xu wrote:
>
> > I also have a pure and high level question regarding a process fork() when
> > there're device exclusive ptes: would the two processes then own the device
> > together
On 2021-05-18 12:33 p.m., Christian König wrote:
Am 18.05.21 um 18:17 schrieb Andrey Grodzovsky:
On 2021-05-18 11:15 a.m., Christian König wrote:
Am 18.05.21 um 17:03 schrieb Andrey Grodzovsky:
On 2021-05-18 10:07 a.m., Christian König wrote:
In a separate discussion with Daniel we once
Am 18.05.21 um 18:48 schrieb Daniel Vetter:
On Tue, May 18, 2021 at 2:49 PM Christian König
wrote:
Hi Jason & Daniel,
Am 18.05.21 um 07:59 schrieb Daniel Vetter:
On Tue, May 18, 2021 at 12:49 AM Jason Ekstrand wrote:
On Mon, May 17, 2021 at 3:15 PM Daniel Vetter wrote:
On Mon, May 17, 202
On Tue, May 18, 2021 at 01:27:42PM -0400, Peter Xu wrote:
> I also have a pure and high level question regarding a process fork() when
> there're device exclusive ptes: would the two processes then own the device
> together? Is this a real usecase?
If the pages are MAP_SHARED then yes. All VMAs
On 5/18/21 7:17 PM, Christian König wrote:
Am 18.05.21 um 19:10 schrieb Thomas Hellström:
On 5/18/21 5:29 PM, Christian König wrote:
Am 18.05.21 um 17:25 schrieb Thomas Hellström:
On 5/18/21 5:17 PM, Christian König wrote:
Am 18.05.21 um 17:11 schrieb Thomas Hellström:
On 5/18/21 5:
Alistair,
While I got one reply below to your previous email, I also looked at the rest
code (majorly restore and fork sides) today and added a few more comments.
On Tue, May 18, 2021 at 11:19:05PM +1000, Alistair Popple wrote:
[...]
> > > diff --git a/mm/memory.c b/mm/memory.c
> > > index 3a57
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #22 from kolAflash (kolafl...@kolahilft.de) ---
@James
What do you mean by video acceleration?
Is this about 3D / DRI acceleration like in video games?
Or do you mean just "video" playback (movie, mp4, webm, h264, vp8, ...)
acceleratio
Am 18.05.21 um 19:10 schrieb Thomas Hellström:
On 5/18/21 5:29 PM, Christian König wrote:
Am 18.05.21 um 17:25 schrieb Thomas Hellström:
On 5/18/21 5:17 PM, Christian König wrote:
Am 18.05.21 um 17:11 schrieb Thomas Hellström:
On 5/18/21 5:07 PM, Christian König wrote:
Am 18.05.21 um
On 5/18/21 5:29 PM, Christian König wrote:
Am 18.05.21 um 17:25 schrieb Thomas Hellström:
On 5/18/21 5:17 PM, Christian König wrote:
Am 18.05.21 um 17:11 schrieb Thomas Hellström:
On 5/18/21 5:07 PM, Christian König wrote:
Am 18.05.21 um 16:55 schrieb Thomas Hellström:
From: Maarten
Am 18.05.21 um 18:49 schrieb Maarten Lankhorst:
Op 18-05-2021 om 17:07 schreef Christian König:
Am 18.05.21 um 16:55 schrieb Thomas Hellström:
From: Maarten Lankhorst
This allows other drivers that may not setup the vma in the same way
to use the ttm bo helpers.
Uff can you please explain
Op 18-05-2021 om 17:07 schreef Christian König:
> Am 18.05.21 um 16:55 schrieb Thomas Hellström:
>> From: Maarten Lankhorst
>>
>> This allows other drivers that may not setup the vma in the same way
>> to use the ttm bo helpers.
>
> Uff can you please explain why exactly you need that?
>
> Providi
On Tue, May 18, 2021 at 2:49 PM Christian König
wrote:
>
> Hi Jason & Daniel,
>
> Am 18.05.21 um 07:59 schrieb Daniel Vetter:
> > On Tue, May 18, 2021 at 12:49 AM Jason Ekstrand
> > wrote:
> >> On Mon, May 17, 2021 at 3:15 PM Daniel Vetter wrote:
> >>> On Mon, May 17, 2021 at 9:38 PM Christian
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #21 from James Zhu (jam...@amd.com) ---
Hi Jeromec, to isolate the cause, can you help run two experiments separately?
1. To run suspend/resume without launching Xorg, just on text mode.
2. To disable video acceleration (VCN IP). I ne
Am 18.05.21 um 18:17 schrieb Andrey Grodzovsky:
On 2021-05-18 11:15 a.m., Christian König wrote:
Am 18.05.21 um 17:03 schrieb Andrey Grodzovsky:
On 2021-05-18 10:07 a.m., Christian König wrote:
In a separate discussion with Daniel we once more iterated over the
dma_resv requirements and I c
Am 18.05.21 um 18:07 schrieb Thomas Hellström:
On 5/18/21 5:42 PM, Christian König wrote:
Am 18.05.21 um 17:38 schrieb Thomas Hellström:
On 5/18/21 5:28 PM, Christian König wrote:
Am 18.05.21 um 17:20 schrieb Thomas Hellström:
On 5/18/21 5:18 PM, Christian König wrote:
Am 18.05.21 um 17
On Tue, May 18, 2021 at 06:17:05PM +0200, Greg Kroah-Hartman wrote:
> There is no need to keep the dentry around for the debugfs kvmgt cache
> file, as we can just look it up when we want to remove it later on.
> Simplify the structure by removing the dentry and relying on debugfs
> to find the den
Fix NULL pointer dereference caused by update_inactive()
trying to list_del() an uninitialized mm_list who's
prev/next pointers are NULL.
Signed-off-by: Alexey Minnekhanov
---
drivers/gpu/drm/msm/msm_gem.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b
On 2021-05-18 11:15 a.m., Christian König wrote:
Am 18.05.21 um 17:03 schrieb Andrey Grodzovsky:
On 2021-05-18 10:07 a.m., Christian König wrote:
In a separate discussion with Daniel we once more iterated over the
dma_resv requirements and I came to the conclusion that this approach
here w
There is no need to keep the dentry around for the debugfs kvmgt cache
file, as we can just look it up when we want to remove it later on.
Simplify the structure by removing the dentry and relying on debugfs
to find the dentry to remove when we want to.
By doing this change, we remove the last in-
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #20 from Jerome C (m...@jeromec.com) ---
(In reply to James Zhu from comment #19)
> Created attachment 296841 [details]
> to fix suspend/resume hung issue
>
> Hi @kolAflash and @jeromec, Can you help check if this patch can fix the
>
On 5/18/21 5:42 PM, Christian König wrote:
Am 18.05.21 um 17:38 schrieb Thomas Hellström:
On 5/18/21 5:28 PM, Christian König wrote:
Am 18.05.21 um 17:20 schrieb Thomas Hellström:
On 5/18/21 5:18 PM, Christian König wrote:
Am 18.05.21 um 17:15 schrieb Thomas Hellström:
On 5/18/21 10:2
Am 18.05.21 um 17:38 schrieb Thomas Hellström:
On 5/18/21 5:28 PM, Christian König wrote:
Am 18.05.21 um 17:20 schrieb Thomas Hellström:
On 5/18/21 5:18 PM, Christian König wrote:
Am 18.05.21 um 17:15 schrieb Thomas Hellström:
On 5/18/21 10:26 AM, Thomas Hellström wrote:
We are calling t
On 5/18/21 5:28 PM, Christian König wrote:
Am 18.05.21 um 17:20 schrieb Thomas Hellström:
On 5/18/21 5:18 PM, Christian König wrote:
Am 18.05.21 um 17:15 schrieb Thomas Hellström:
On 5/18/21 10:26 AM, Thomas Hellström wrote:
We are calling the eviction_valuable driver callback at evictio
Am 18.05.21 um 17:25 schrieb Thomas Hellström:
On 5/18/21 5:17 PM, Christian König wrote:
Am 18.05.21 um 17:11 schrieb Thomas Hellström:
On 5/18/21 5:07 PM, Christian König wrote:
Am 18.05.21 um 16:55 schrieb Thomas Hellström:
From: Maarten Lankhorst
This allows other drivers that ma
Am 18.05.21 um 17:20 schrieb Thomas Hellström:
On 5/18/21 5:18 PM, Christian König wrote:
Am 18.05.21 um 17:15 schrieb Thomas Hellström:
On 5/18/21 10:26 AM, Thomas Hellström wrote:
We are calling the eviction_valuable driver callback at eviction
time to
determine whether we actually can
On 5/18/21 5:17 PM, Christian König wrote:
Am 18.05.21 um 17:11 schrieb Thomas Hellström:
On 5/18/21 5:07 PM, Christian König wrote:
Am 18.05.21 um 16:55 schrieb Thomas Hellström:
From: Maarten Lankhorst
This allows other drivers that may not setup the vma in the same way
to use the ttm
On 5/18/21 5:18 PM, Christian König wrote:
Am 18.05.21 um 17:15 schrieb Thomas Hellström:
On 5/18/21 10:26 AM, Thomas Hellström wrote:
We are calling the eviction_valuable driver callback at eviction
time to
determine whether we actually can evict a buffer object.
The upcoming i915 TTM ba
Am 18.05.21 um 17:15 schrieb Thomas Hellström:
On 5/18/21 10:26 AM, Thomas Hellström wrote:
We are calling the eviction_valuable driver callback at eviction time to
determine whether we actually can evict a buffer object.
The upcoming i915 TTM backend needs the same functionality for swapout
https://bugzilla.kernel.org/show_bug.cgi?id=211277
jam...@amd.com (jam...@amd.com) changed:
What|Removed |Added
CC||jam...@amd.com
--- Comm
Am 18.05.21 um 17:11 schrieb Thomas Hellström:
On 5/18/21 5:07 PM, Christian König wrote:
Am 18.05.21 um 16:55 schrieb Thomas Hellström:
From: Maarten Lankhorst
This allows other drivers that may not setup the vma in the same way
to use the ttm bo helpers.
Uff can you please explain why
On 5/18/21 10:26 AM, Thomas Hellström wrote:
We are calling the eviction_valuable driver callback at eviction time to
determine whether we actually can evict a buffer object.
The upcoming i915 TTM backend needs the same functionality for swapout,
and that might actually be beneficial to other d
Am 18.05.21 um 17:03 schrieb Andrey Grodzovsky:
On 2021-05-18 10:07 a.m., Christian König wrote:
In a separate discussion with Daniel we once more iterated over the
dma_resv requirements and I came to the conclusion that this approach
here won't work reliable.
The problem is as following:
1.
On 5/18/21 5:07 PM, Christian König wrote:
Am 18.05.21 um 16:55 schrieb Thomas Hellström:
From: Maarten Lankhorst
This allows other drivers that may not setup the vma in the same way
to use the ttm bo helpers.
Uff can you please explain why exactly you need that?
Providing the BO is not m
Am 18.05.21 um 16:55 schrieb Thomas Hellström:
From: Maarten Lankhorst
This allows other drivers that may not setup the vma in the same way
to use the ttm bo helpers.
Uff can you please explain why exactly you need that?
Providing the BO is not much of a problem, but having the BO at
differ
On 2021-05-18 10:07 a.m., Christian König wrote:
In a separate discussion with Daniel we once more iterated over the
dma_resv requirements and I came to the conclusion that this approach
here won't work reliable.
The problem is as following:
1. device A schedules some rendering with into a b
On Tue, 18 May 2021 at 14:21, Christoph Hellwig wrote:
>
> On Mon, May 17, 2021 at 06:06:44PM +0100, Matthew Auld wrote:
> > > Looks like it is caused by the validation failure then. Which means the
> > > existing code is doing something wrong in its choice of the page
> > > protection bit. I re
On 5/18/21 1:59 PM, Christian König wrote:
Can you send me the patch directly and not just on CC?
Thanks,
Christian.
Original patch sent. Pls remember to CC lists on reply, though.
The reason we need this is because of i915's strange mmap functionality
which allows a bo to be mapped at mul
Hi Maxime,
On Tue, May 18, 2021 at 4:33 PM Maxime Ripard wrote:
> On Tue, May 18, 2021 at 09:51:31AM +0200, Geert Uytterhoeven wrote:
> > Convert the Solomon SSD1307 Framebuffer Device Tree binding
> > documentation to json-schema.
> >
> > Fix the spelling of the "pwms" property.
> > Document def
Series applied to drm-misc-next.
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=b67f7599c90ae36a5174826132f7690fa13d462c
On Tue, 18 May 2021 at 16:19, Dafna Hirschfeld
wrote:
>
> ChromeOS EC ANX7688 is a display bridge that converts HDMI 2.0 to
> DisplayPort 1.3 Ultra-HDi (4096x2160p60). I
Hi
On Tue, May 18, 2021 at 09:51:31AM +0200, Geert Uytterhoeven wrote:
> Convert the Solomon SSD1307 Framebuffer Device Tree binding
> documentation to json-schema.
>
> Fix the spelling of the "pwms" property.
> Document default values.
> Make properties with default values not required.
>
> Sig
On 2021-05-17 4:34 a.m., Pekka Paalanen wrote:
> On Fri, 14 May 2021 17:04:51 -0400
> Harry Wentland wrote:
>
>> On 2021-04-30 8:53 p.m., Sebastian Wick wrote:
>>> On 2021-04-26 20:56, Harry Wentland wrote:
>
> ...
>
Another reason I'm proposing to define the color space (and gamma) of
>
On Fri, May 14, 2021 at 09:18:00PM +0800, Kevin Tang wrote:
> Maxime Ripard 于2021年4月30日周五 下午5:22写道：
> > > + info = drm_format_info(fb->format->format);
> >
> > Here fb->format is the result of drm_format_info(fb->format->format)
>
> info->num_planes == 3? I will fix it on next version
It's no
On Wed, May 12, 2021 at 09:53:06PM +0800, Kevin Tang wrote:
> > > +struct dsi_reg {
> > > + union _0x00 {
> > > + u32 val;
> > > + struct _DSI_VERSION {
> > > + u32 dsi_version: 16;
> > > + u32 reserved: 16;
> > > + } bits;
> > > +
(resending patchset with Rb tags)
ANX7688 is a typec port controller that also converts HDMI to DP.
It is found on Acer Chromebook R13 (elm) and on Pine64 PinePhone.
On Acer Chromebook R13 (elm), the device is powered-up and controller by the
Embedded Controller. Therefore its operation is transpa
ChromeOS EC ANX7688 is a display bridge that converts HDMI 2.0 to
DisplayPort 1.3 Ultra-HDi (4096x2160p60). It is an Analogix ANX7688 chip
which is connected to and operated by the ChromeOS Embedded Controller
(See google,cros-ec.yaml). It is accessed using I2C tunneling through
the EC and therefor
From: Enric Balletbo i Serra
This driver adds support for the ChromeOS EC ANX7688 HDMI to DP converter
For our use case, the only reason the Linux kernel driver is necessary is
to reject resolutions that require more bandwidth than what is available
on the DP side. DP bandwidth and lane count ar
On 2021-05-18 3:56 a.m., Pekka Paalanen wrote:
> On Mon, 17 May 2021 15:39:03 -0400
> Vitaly Prosyak wrote:
>
>> On 2021-05-17 12:48 p.m., Sebastian Wick wrote:
>>> On 2021-05-17 10:57, Pekka Paalanen wrote:
On Fri, 14 May 2021 17:05:11 -0400
Harry Wentland wrote:
> On
On Tue, May 18, 2021 at 09:58:09PM +1000, Alistair Popple wrote:
> On Tuesday, 18 May 2021 12:17:32 PM AEST Peter Xu wrote:
> > On Wed, Apr 07, 2021 at 06:42:31PM +1000, Alistair Popple wrote:
> > > +static inline struct page *pfn_swap_entry_to_page(swp_entry_t entry)
> > > +{
> > > + struct pa
> > +
> > +static struct pci_driver hyperv_pci_driver = {
> > + .name = KBUILD_MODNAME,
> > + .id_table = hyperv_pci_tbl,
> > + .probe =hyperv_pci_probe,
> > + .remove = hyperv_pci_remove,
> > +};
>
> The PCI code doesn't do anything. Do you need t
In a separate discussion with Daniel we once more iterated over the
dma_resv requirements and I came to the conclusion that this approach
here won't work reliable.
The problem is as following:
1. device A schedules some rendering with into a buffer and exports it
as DMA-buf.
2. device B import
[Public]
Reviewed-by: Alex Deucher
From: Grodzovsky, Andrey
Sent: Tuesday, May 18, 2021 10:01 AM
To: dri-devel@lists.freedesktop.org ;
amd-...@lists.freedesktop.org ;
linux-...@vger.kernel.org ;
ckoenig.leichtzumer...@gmail.com ;
daniel.vet...@ffwll.ch ; Went
Ping
Andrey
On 2021-05-17 3:31 p.m., Andrey Grodzovsky wrote:
Access to those must be prevented post pci_remove
v6: Drop BOs list, unampping VRAM BAR is enough.
v8:
Add condition of xgmi.connected_to_cpu to MTTR
handling and remove MTTR handling from the old place.
Signed-off-by: Andrey Grodz
Hi,
On Tue, May 18, 2021 at 5:42 AM Rob Herring wrote:
>
> On Mon, May 17, 2021 at 3:09 PM Douglas Anderson
> wrote:
> >
> > These are described in panel-common.yaml but if I don't list them in
> > panel-simple then I get yells when running 'dt_binding_check' in a
> > future patch. List them al
1 - 100 of 202 matches
Mail list logo
