Send DPCD command to downstream before anx7625 power down,
let downstream monitor enter into standby mode.
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 40 ---
1 file changed, 35 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analo
On Mon, Jan 10, 2022 at 08:41:26PM -0400, Jason Gunthorpe wrote:
> On Mon, Jan 10, 2022 at 07:34:49PM +, Matthew Wilcox wrote:
>
> > Finally, it may be possible to stop using scatterlist to describe the
> > input to the DMA-mapping operation. We may be able to get struct
> > scatterlist down
On Mon, Jan 10, 2022 at 6:44 PM Linus Torvalds
wrote:
>
> I'll double-check to see if a revert fixes it at the top of my tree.
Yup. It reverts cleanly, and the end result builds and works fine, and
doesn't show the horrendous flickering.
I have done that revert, and will continue the merge windo
On Mon, Jan 10, 2022 at 6:22 PM Linus Torvalds
wrote:
>
> and I guess I'll do the few more bisections to pick out the exact one.
a896f870f8a5f23ec961d16baffd3fda1f8be57c is the first bad commit.
Attaching ther BISECT_LOG in case anybody cares.
I'll double-check to see if a revert fixes it at th
On Mon, 03 Jan 2022 10:35:01 +0100, Linus Walleij wrote:
> The panel ACX424AKP seems to only be used in prototypes, whereas
> real products use the 10 pixels shorter ACX424AKM. Extend the
> ACX424AKP bindings to also cover the ACX424AKM. The ACX424AKM
> was used in a few different mobile phones fro
Using DefaultGPUNode now instead of system memory, usage similar to
other tests. Also cleaned up pSmall, which I originally intended to
just let float away on the mistaken assumption that it would be
cleaned up automatically at the end of the test.
Basic test for the new hsaKmtAvailableMemory libr
On Mon, Jan 10, 2022 at 5:21 PM Linus Torvalds
wrote:
>
> I'll see if I can bisect it at least partially.
It seems to be very reliable. I can see the flickering even at early
boot before gdb has started - the graphical screen where you type the
encrypted disk password at boot already shows it as
Add an ioctl to inquire memory available for allocation by libhsakmt
per node, allowing for space consumed by page translation tables.
This ioctl is the underlying mechanism for the new memory availability
library call posted for review here:
https://lists.freedesktop.org/archives/amd-gfx/2022
On Mon, Jan 10, 2022 at 5:21 PM Linus Torvalds
wrote:
>
> It also seems to depend a bit on the screen contents - or possibly on
> what else is going on. Hiding the browser window makes it happen less,
> I think. But I suspect that's about "less gpu activity" than anything
> else.
Actually, someti
On Mon, Jan 10, 2022 at 5:11 PM Alex Deucher wrote:
>
> We are putting together a system to try and repro the issue. Does it
> happen with a single monitor or only with two?
Nope. With a single monitor everything seems to look fine. And when I
plug in the second monitor, it immediately starts ha
On Mon, Jan 10, 2022 at 8:04 PM Linus Torvalds
wrote:
>
> On Mon, Jan 10, 2022 at 2:13 PM Alex Deucher wrote:
> >
> > Sounds like something related to watermarks. That said, we haven't
> > really touched the display code for DCE11 cards in quite a while. Can
> > you provide your dmesg output?
>
On Mon, Jan 10, 2022 at 2:13 PM Alex Deucher wrote:
>
> Sounds like something related to watermarks. That said, we haven't
> really touched the display code for DCE11 cards in quite a while. Can
> you provide your dmesg output?
I'm not seeing anything that would look interesting, but here's the
On Mon, Jan 10, 2022 at 07:34:49PM +, Matthew Wilcox wrote:
> Finally, it may be possible to stop using scatterlist to describe the
> input to the DMA-mapping operation. We may be able to get struct
> scatterlist down to just dma_address and dma_length, with chaining
> handled through an encl
Fix typo: separate arguments with comma rather than dot.
Signed-off-by: Lucas De Marchi
---
include/linux/dma-buf-map.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
index 278d489e4bdd..19fa0b5ae5ec 100644
--- a/
On 2022-01-05 10:22 a.m., philip yang wrote:
On 2021-12-22 7:37 p.m., Rajneesh Bhardwaj wrote:
Recoverable page faults are represented by the xnack mode setting inside
a kfd process and are used to represent the device page faults. For CR,
we don't consider negative values which are typically
On 2021-12-22 7:37 p.m., Rajneesh Bhardwaj wrote:
In CRIU resume stage, resume all the shared virtual memory ranges from
the data stored inside the resuming kfd process during CRIU restore
phase. Also setup xnack mode and free up the resources.
Signed-off-by: Rajneesh Bhardwaj
---
drivers/gpu
On 2022-01-05 9:43 a.m., philip yang wrote:
On 2021-12-22 7:37 p.m., Rajneesh Bhardwaj wrote:
During CRIU restore phase, the VMAs for the virtual address ranges are
not at their final location yet so in this stage, only cache the data
required to successfully resume the svm ranges during an im
On 2022-01-10 4:48 p.m., Daniel Phillips wrote:
Basic test for the new hsaKmtAvailableMemory library call. This is
a standalone test, does not modify any of the other tests just to
be on the safe side. More elaborate tests coming soon.
Change-Id: I738600d4b74cc5dba6b857e4c793f6b14b7d2283
Signed-
On 2022-01-10 3:54 p.m., Daniel Phillips wrote:
From: Daniel Phillips
This is weird. Looks like you've set up the your user email in your
.gitconfig incorrectly. Or you changed it after you commited this patch
locally.
Add an ioctl to inquire memory available for allocation by libhsakmt
Jitao Shi writes:
> "auo,kd101n80-45na" 2st LCD SPEC update, need to modify the timing
> between IOVCC and mipi data.
> The 2st version of SPEC modifies the timing requirements from IOVCC to
> Mipi Data. IOVCC is now required to take precedence over MIPI DATA,
> otherwise there is a risk of leaka
On 2021-12-22 7:37 p.m., Rajneesh Bhardwaj wrote:
From: David Yat Sin
Checkpoint contents of queue MQD's on CRIU dump and restore them during
CRIU restore.
Signed-off-by: David Yat Sin
David has an update for this patch to fix up the doorbell offset in the
restored SDMA MQD.
Regards,
F
On 2021-12-22 7:36 p.m., Rajneesh Bhardwaj wrote:
This adds support to create userptr BOs on restore and introduces a new
ioctl to restart memory notifiers for the restored userptr BOs.
When doing CRIU restore MMU notifications can happen anytime after we call
amdgpu_mn_register. Prevent MMU noti
On 2021-12-22 7:37 p.m., Rajneesh
Bhardwaj wrote:
A KFD process may contain a number of virtual address ranges for shared
virtual memory management and each such range can have many SVM
attributes spanning across various nodes within the process boundary.
Thi
On 2021-12-22 7:36 p.m., Rajneesh Bhardwaj wrote:
This implements the KFD CRIU Restore ioctl that lays the basic
foundation for the CRIU restore operation. It provides support to
create the buffer objects corresponding to Non-Paged system memory
mapped for GPU and/or CPU access and lays basic fou
On 2021-12-22 7:36 p.m., Rajneesh Bhardwaj wrote:
This IOCTL is expected to be called as a precursor to the actual
Checkpoint operation. This does the basic discovery into the target
process seized by CRIU and relays the information to the userspace that
utilizes it to start the Checkpoint operat
new ioctl cmd added to query zone device type. This will be
used once the test_hmm adds zone device coherent type.
Signed-off-by: Alex Sierra
---
lib/test_hmm.c | 14 ++
lib/test_hmm_uapi.h | 8
2 files changed, 22 insertions(+)
diff --git a/lib/test_hmm.c b/lib/test_
Add two more parameters to set spm_addr_dev0 & spm_addr_dev1
addresses. These two parameters configure the start SP
addresses for each device in test_hmm driver.
Consequently, this configures zone device type as coherent.
Signed-off-by: Alex Sierra
---
v2:
Add more mknods for device coherent type
Device Coherent type uses device memory that is coherently accesible by
the CPU. This could be shown as SP (special purpose) memory range
at the BIOS-e820 memory enumeration. If no SP memory is supported in
system, this could be faked by setting CONFIG_EFI_FAKE_MEMMAP.
Currently, test_hmm only sup
Test cases such as migrate_fault and migrate_multiple, were modified to
explicit migrate from device to sys memory without the need of page
faults, when using device coherent type.
Snapshot test case updated to read memory device type first and based
on that, get the proper returned results migrat
In order to configure device coherent in test_hmm, two module parameters
should be passed, which correspond to the SP start address of each
device (2) spm_addr_dev0 & spm_addr_dev1. If no parameters are passed,
private device type is configured.
Signed-off-by: Alex Sierra
---
lib/test_hmm.c
Coherent device type memory on VRAM to RAM migration, has similar access
as System RAM from the CPU. This flag sets the source from the sender.
Which in Coherent type case, should be set as
MIGRATE_VMA_SELECT_DEVICE_COHERENT.
Signed-off-by: Alex Sierra
Reviewed-by: Felix Kuehling
---
drivers/gp
When CPU is connected throug XGMI, it has coherent
access to VRAM resource. In this case that resource
is taken from a table in the device gmc aperture base.
This resource is used along with the device type, which could
be DEVICE_PRIVATE or DEVICE_COHERENT to create the device
page map region.
Sig
This case is used to migrate pages from device memory, back to system
memory. Device coherent type memory is cache coherent from device and CPU
point of view.
Signed-off-by: Alex Sierra
---
v2:
condition added when migrations from device coherent pages.
---
include/linux/migrate.h | 1 +
mm/migr
Device memory that is cache coherent from device and CPU point of view.
This is used on platforms that have an advanced system bus (like CAPI
or CXL). Any page of a process can be migrated to such memory. However,
no one should be allowed to pin such memory so that it can always be
evicted.
Signed
This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory
owned by a device that can be mapped into CPU page tables like
MEMORY_DEVICE_GENERIC and can also be migrated like
MEMORY_DEVICE_PRIVATE.
Christoph, the suggestion to incorporate Ralph Campbell’s refcount
cleanup patch into our
Avoid long term pinning for Coherent device type pages. This could
interfere with their own device memory manager. For now, we are just
returning error for PIN_LONGTERM Coherent device type pages. Eventually,
these type of pages will get migrated to system memory, once the device
migration pages su
On Mon, Jan 10, 2022 at 5:05 PM Daniel Vetter wrote:
>
> On Mon, Jan 10, 2022 at 10:30 PM Linus Torvalds
> wrote:
> >
> > On Thu, Jan 6, 2022 at 10:12 PM Dave Airlie wrote:
> > >
> > > git://anongit.freedesktop.org/drm/drm tags/drm-next-2022-01-07
> >
> > Gaah. I merged things and it built cle
On 2021-12-22 7:36 p.m., Rajneesh Bhardwaj wrote:
Checkpoint-Restore in userspace (CRIU) is a powerful tool that can
snapshot a running process and later restore it on same or a remote
machine but expects the processes that have a device file (e.g. GPU)
associated with them, provide necessary dri
On Mon, Jan 10, 2022 at 10:30 PM Linus Torvalds
wrote:
>
> On Thu, Jan 6, 2022 at 10:12 PM Dave Airlie wrote:
> >
> > git://anongit.freedesktop.org/drm/drm tags/drm-next-2022-01-07
>
> Gaah. I merged things and it built cleanly, and I pushed it out.
>
> But then I actually *booted* it, and that
Basic test for the new hsaKmtAvailableMemory library call. This is
a standalone test, does not modify any of the other tests just to
be on the safe side. More elaborate tests coming soon.
Change-Id: I738600d4b74cc5dba6b857e4c793f6b14b7d2283
Signed-off-by: Daniel Phillips
---
tests/kfdtest/src/KF
On Thu, Jan 6, 2022 at 10:12 PM Dave Airlie wrote:
>
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2022-01-07
Gaah. I merged things and it built cleanly, and I pushed it out.
But then I actually *booted* it, and that's not pretty.
It *works", but it's almost unusable because of random
The pull request you sent on Fri, 7 Jan 2022 16:12:06 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2022-01-07
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8d0749b4f83bf4768ceae45ee6a79e6e7eddfc2a
Thank you!
--
Deet-doot-dot, I am a bot.
https://kor
Add a library call to inquire memory available for allocation per
node. Uses the AMDKFD_IOC_AVAILABLE_MEMORY ioctl available in KFD
ioctl version 1.7
Change-Id: Id770fc2261e9e076f2fbce7dcdac640a6354ddbe
---
include/hsakmt.h | 11 +++
include/linux/kfd_ioctl.h | 18 +++
On 2022-01-05 10:56 a.m., Felix Kuehling wrote:
Am 2022-01-05 um 4:09 a.m. schrieb Jiasheng Jiang:
As the possible failure of the allocation, kmemdup() may return NULL
pointer.
Therefore, it should be better to check the 'props2' in order to prevent
the dereference of NULL pointer.
Fixes: 3a871
[Public]
This is missing your signed-off-by. Additionally, for UAPI changes, we need a
link the patches for the userspace component that will make use of it.
Alex
From: amd-gfx on behalf of Daniel
Phillips
Sent: Monday, January 10, 2022 3:54 PM
To: amd-...@l
On Thu, Jan 6, 2022 at 10:12 PM Dave Airlie wrote:
>
> nouveau_fence.c is the only conflict I've seen and I've taken the result from
> our rerere cache in the merge above. It's non trivial, would be good to have
> Christian confirm it as well.
Thanks, that conflict really ended up being one that
Each DP link training contains link training 1 followed by link
training 2. There is maximum of 5 retries of DP link training
before declared link training failed. It is required to stop link
training at end of link training 2 if it is failed so that next
link training 1 can start freshly. This pa
From: Kuogee Hsieh
Some DP sinkers prefer to use tps4 instead of tps3 during training #2.
This patch will use tps4 to perform link training #2 if sinker's DPCD
supports it.
Changes in V2:
-- replace dp_catalog_ctrl_set_pattern() with
dp_catalog_ctrl_set_pattern_state_bit()
Changes in V3:
--
DP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose
and expect DP source return correct checksum. During drm edid read,
correct edid checksum is calculated and stored at
connector::real_edid_checksum.
The problem is struct dp_panel::connector never be assigned, instead the
connect
Current DP drivers have regulators, clocks, irq and phy are grouped
together within a function and executed not in a symmetric manner.
This increase difficulty of code maintenance and limited code scalability.
This patch divides the driver life cycle of operation into four states,
resume (including
Add checking aux read/write status at both dp_link_parse_sink_count()
and dp_link_parse_sink_status_filed() to avoid long timeout delay if
dp aux read/write failed at timeout due to cable unplugged. Also make
sure dp controller had been initialized before start dpcd read and write.
Changes in V4:
Group below 5 dp driver related patches into one series.
Kuogee Hsieh (5):
drm/msm/dp: dp_link_parse_sink_count() return immediately if aux read
failed
drm/msm/dp: do not initialize phy until plugin interrupt received
drm/msm/dp: populate connector of struct dp_panel
drm/msm/dp: add
From: Daniel Phillips
Add an ioctl to inquire memory available for allocation by libhsakmt
per node, allowing for space consumed by page translation tables.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 1 +
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c| 14 ++
drivers/gp
On Wed, 29 Dec 2021 18:03:55 +0100, Luca Weiss wrote:
> Document the compatible for the wled block found in PM6150L.
>
> Signed-off-by: Luca Weiss
> ---
> Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring
TLDR: I want to introduce a new data type:
struct phyr {
phys_addr_t addr;
size_t len;
};
and use it to replace bio_vec as well as using it to replace the array
of struct pages used by get_user_pages() and friends.
---
There are two distinct problems I want to address: doing I/O
Applied. Thanks!
Alex
On Mon, Jan 10, 2022 at 11:34 AM Harry Wentland wrote:
>
> On 2022-01-09 13:42, José Expósito wrote:
> > The function performs a check on the "adev" input parameter, however, it
> > is used before the check.
> >
> > Initialize the "dev" variable after the sanity check to a
On Mon, 27 Dec 2021 20:59:34 -0800, Bjorn Andersson wrote:
> The Qualcomm SM8350 platform comes with a single DisplayPort controller,
> add support for this in the DisplayPort driver.
>
> Signed-off-by: Bjorn Andersson
> ---
> .../devicetree/bindings/display/msm/dp-controller.yaml| 1 +
> dr
> Whether it's worth the effort depends on whether anyone really cares
> about getting the full performance out of this particular GPU.
>
> At this stage I think the main UABI change would be to add the opposite
> flag to kbase, (e.g. "PANFROST_JD_DOESNT_NEED_COHERENCY_ON_GPU"[1]) to
> opt-in to a
> > This feature adds an extra IDVS group size field to the JM_CONFIG
> > register. In kbase, the value is configurable via the device tree; kbase
> > uses 0xF as a default if no value is specified. Until we find a device
> > demanding otherwise, let's always set the 0xF default on devices which
>
Hi Christian
I have reverted the change from the amd-staging-drm-next as per the
discussion. Thank you.
Regards
Rajneesh
On 1/4/2022 1:08 PM, Felix Kuehling wrote:
[+Adrian]
Am 2021-12-23 um 2:05 a.m. schrieb Christian König:
Am 22.12.21 um 21:53 schrieb Daniel Vetter:
On Mon, Dec 20
On Mon, Jan 10, 2022 at 05:06:03PM +0300, Dmitry Baryshkov wrote:
> On Mon, 10 Jan 2022 at 15:56, Rajeev Nandan wrote:
> >
> > In most cases, the default values of DSI PHY tuning registers should be
> > sufficient as they are fully optimized. However, in some cases where
> > extreme board parasiti
panel_bridge pointer never used anywhere except the one it
looked up at nwl_dsi_bridge_attach.
Drop it from the nwl_dsi structure.
Reviewed-by: Guido Günther
Signed-off-by: Jagan Teki
---
Changes for v2:
- collect Guido r-b
Note: This is patch is part of switching of devm_drm_of_get_bridge
se
There is always a struct vma_resource guaranteed to be alive when we
access a corresponding struct vma_snapshot.
So ditch the latter and instead of allocating vma_snapshots, reference
the already existning vma_resource.
This requires a couple of extra members in struct vma_resource but that's
a s
Add a selftest to exercise asynchronous migration and -unbining.
Extend the gem_migrate selftest to perform the migrations while
depending on a spinner and a bound vma set up on the migrated
buffer object.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i9
Implement async (non-blocking) unbinding by not syncing the vma before
calling unbind on the vma_resource.
Add the resulting unbind fence to the object's dma_resv from where it is
picked up by the ttm migration code.
Ideally these unbind fences should be coalesced with the migration blit
fence to a
A pin-count is already held by vma->pages so taking an additional pin
during async binds is not necessary.
When we introduce async unbinding we have other means of keeping the
object pages alive.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_vma.c | 5
When introducing asynchronous unbinding, the vma itself may no longer
be alive when the actual binding or unbinding takes place.
Update the gtt i915_vma_ops accordingly to take a struct i915_vma_resource
instead of a struct i915_vma for the bind_vma() and unbind_vma() ops.
Similarly change the ins
Introduce vma resources, sort of similar to TTM resources, needed for
asynchronous bind management. Initially we will use them to hold
completion of unbinding when we capture data from a vma, but they will
be used extensively in upcoming patches for asynchronous vma unbinding.
v6:
- Some document
This patch series introduces infrastructure for asynchronous vma
unbinding. The single enabled use-case is initially at buffer object
migration where we otherwise sync when unbinding vmas before migration.
This in theory allows us to pipeline any number of migrations, but in
practice the number i
On 09/01/2022 17:12, Alyssa Rosenzweig wrote:
> The IDVS group size feature was missing. It is used on some Bifrost and
> Valhall GPUs, and is the last kernel-relevant Bifrost feature we're
> missing.
>
> This feature adds an extra IDVS group size field to the JM_CONFIG
> register. In kbase, the v
On Mon, 10 Jan 2022 18:25:35 +0530, Rajeev Nandan wrote:
> In most cases, the default values of DSI PHY tuning registers should be
> sufficient as they are fully optimized. However, in some cases where
> extreme board parasitics cause the eye shape to degrade, the override
> bits can be used to imp
On Sun, Jan 9, 2022 at 11:38 PM Geert Uytterhoeven wrote:
>
> The commit that merged this branch made a seemingly innocent change to
> the top Makefile:
"Seemingly" innocent?
Or something darker and more sinister, related to the unrelenting
slaughter of flightless fowl?
You be the judge.
On 09/01/2022 16:37, Alyssa Rosenzweig wrote:
> Update a comment stating create_bo took no flags, since it now takes a
> bit mask of optional flags NOEXEC and HEAP.
>
> Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Steven Price
I'll push this to drm-misc-next.
Thanks,
Steve
> ---
> include
On 2022-01-09 13:42, José Expósito wrote:
> The function performs a check on the "adev" input parameter, however, it
> is used before the check.
>
> Initialize the "dev" variable after the sanity check to avoid a possible
> NULL pointer dereference.
>
> Fixes: e27c41d5b0681 ("drm/amd/display: Sup
On Tue, Jan 04, 2022 at 08:48:57PM +0200, Jani Nikula wrote:
> Take bit 7 into account when reading sink count from
> DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
On Tue, Jan 04, 2022 at 08:48:56PM +0200, Jani Nikula wrote:
> DP_SINK_COUNT_ESI and DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0 have the same
> contents as DP_SINK_COUNT and DP_DEVICE_SERVICE_IRQ_VECTOR,
> respectively.
IIRC there was an oversight in the earlier spec revisions that
showed bit 7 as reserved
On Fri, Dec 31, 2021 at 03:23:31PM +0200, Jani Nikula wrote:
> On Wed, 12 Jul 2017, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Make the atomic private object stuff less special by introducing proper
> > base classes for the object and its state. Drivers can embed these in
On Mon, 10 Jan 2022 at 16:35, Jagan Teki wrote:
>
> Hi Robert,
>
> On Mon, Jan 10, 2022 at 9:02 PM Robert Foss wrote:
> >
> > Hey Jagan,
> >
> > This is a mistake on my end, I must have been looking at reviewing
> > this series and then accidentally included it with another batch of
> > patches.
On Fri, Jan 7, 2022 at 6:42 PM Linus Torvalds
wrote:
>
> On Thu, Jan 6, 2022 at 7:23 PM Dave Airlie wrote:
> >
> > There is only the amdgpu runtime pm regression fix in here.
>
> Thanks, from a quick test it works for me - the backlight actually
> does eventually go away.
>
> It does so only on t
Hi Robert,
On Mon, Jan 10, 2022 at 9:02 PM Robert Foss wrote:
>
> Hey Jagan,
>
> This is a mistake on my end, I must have been looking at reviewing
> this series and then accidentally included it with another batch of
> patches. Thank you for catching this.
Thanks for the response.
>
> I would
Hey Jagan,
This is a mistake on my end, I must have been looking at reviewing
this series and then accidentally included it with another batch of
patches. Thank you for catching this.
I would suggest reverting these two patches[1][2]. Is that ok with you?
[1]
https://cgit.freedesktop.org/drm/dr
On 1/10/22 14:21, Matthew Auld wrote:
On 07/01/2022 14:23, Thomas Hellström wrote:
Implement async (non-blocking) unbinding by not syncing the vma before
calling unbind on the vma_resource.
Add the resulting unbind fence to the object's dma_resv from where it is
picked up by the ttm migration
On 10/01/2022 14:36, Thomas Hellström wrote:
On 1/10/22 14:59, Matthew Auld wrote:
On 07/01/2022 14:23, Thomas Hellström wrote:
Add a selftest to exercise asynchronous migration and -unbining.
Extend the gem_migrate selftest to perform the migrations while
depending on a spinner and a bound vm
On 1/10/22 14:59, Matthew Auld wrote:
On 07/01/2022 14:23, Thomas Hellström wrote:
Add a selftest to exercise asynchronous migration and -unbining.
Extend the gem_migrate selftest to perform the migrations while
depending on a spinner and a bound vma set up on the migrated
buffer object.
Sign
On Fri, 7 Jan 2022 at 14:24, Thomas Hellström
wrote:
>
> There is always a struct vma_resource guaranteed to be alive when we
> access a corresponding struct vma_snapshot.
>
> So ditch the latter and instead of allocating vma_snapshots, reference
> the already existning vma_resource.
>
> This requ
On 24/12/2021 08:56, Alexey Sheplyakov wrote:
> Hi,
>
> On 23.12.2021 18:11, Alyssa Rosenzweig wrote:
>>> The kernel driver itself can't guess which jobs need a such a strict
>>> affinity, so setting proper requirements is the responsibility of
>>> the userspace (Mesa). However the userspace is no
On Mon, 10 Jan 2022 at 15:56, Rajeev Nandan wrote:
>
> Add support for MSM DSI PHY tuning configuration. Current design is
> to support drive strength and drive level/amplitude tuning for
> 10nm PHY version, but this can be extended to other PHY versions.
>
> Signed-off-by: Rajeev Nandan
> ---
>
On Mon, 10 Jan 2022 at 15:56, Rajeev Nandan wrote:
>
> In most cases, the default values of DSI PHY tuning registers should be
> sufficient as they are fully optimized. However, in some cases where
> extreme board parasitics cause the eye shape to degrade, the override
> bits can be used to improv
On 07/01/2022 14:23, Thomas Hellström wrote:
Add a selftest to exercise asynchronous migration and -unbining.
Extend the gem_migrate selftest to perform the migrations while
depending on a spinner and a bound vma set up on the migrated
buffer object.
Signed-off-by: Thomas Hellström
---
driver
On 07/01/2022 14:23, Thomas Hellström wrote:
Implement async (non-blocking) unbinding by not syncing the vma before
calling unbind on the vma_resource.
Add the resulting unbind fence to the object's dma_resv from where it is
picked up by the ttm migration code.
Ideally these unbind fences should
This duck tape workaround is no longer required, unbind and destroy are
fixed to take the obj->resv mutex before destroying and obj->mm.lock has
been removed, always requiring obj->resv as well.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_obj
Now that we require the object lock for all ops, some code handling
race conditions can be removed.
This is required to not take short-term pins inside execbuf.
Signed-off-by: Maarten Lankhorst
Acked-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_vma.c | 55 +--
Add a flag PIN_VALIDATE, to indicate we don't need to pin and only
protected by the object lock.
This removes the need to unpin, which is done by just releasing the
lock.
eb_reserve is slightly reworked for readability, but the same steps
are still done:
- First pass pins with NONBLOCK.
- Second
Because we will start to require the obj->resv lock for unbinding,
ensure these shrinker functions also take the lock.
This requires some function signature changes, to ensure that the
ww context is passed around, but is mostly straightforward.
Previously this was split up into several patches, b
Now that we cannot unbind kill the currently locked object directly
because we're removing short term pinning, we may have to unbind the
object from gtt manually, using a i915_gem_evict_vm() call.
Changes since v1:
- Remove -ENOSPC warning, can still happen with concurrent mmaps
where we can't u
i915_gem_evict_vm will need to be able to evict objects that are
locked by the current ctx. By testing if the current context already
locked the object, we can do this correctly. This allows us to
evict the entire vm even if we already hold some objects' locks.
Previously, this was spread over sev
Previously, short term pinning in execbuf was required because i915_vma was
effectively independent from objects, and has its own refcount, locking,
lifetime rules and pinning.
This series removes the separate locking, by requiring vma->obj->resv to be
held when pinning and unbinding. This will al
We want to remove more members of i915_vma, which requires the locking to be
held more often.
Start requiring gem object lock for i915_vma_unbind, as it's one of the
callers that may unpin pages.
Some special care is needed when evicting, because the last reference to the
object may be held by th
Explicit assignment of connector to bridge type during bridge
addition is optional.
Some of the bridges like ICN6211 has panel to be connected and
that panel driver has taken care of associated connector type
of it.
Drop it.
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/bridge/chipone-icn6211.
Hi All,
On 1/7/22 20:02, Rajat Jain wrote:
> Allow a privacy screen provider to stash its private data pointer in the
> drm_privacy_screen, and update the drm_privacy_screen_register() call to
> accept that. Also introduce a *_get_drvdata() so that it can retrieved
> back when needed.
>
> This al
1 - 100 of 164 matches
Mail list logo
