Works for me.
Am 20.10.21 um 21:37 schrieb Jason Gunthorpe:
On Wed, Oct 20, 2021 at 08:41:24AM +0200, Christian König wrote:
I think the patch subject needs updating to reflect that we're disabling
PUD/PMDs completely.
With that fixed,
Everyone is OK with this?
drm/ttm: remove ttm_bo_vm_inse
On Thu, 2021-10-21 at 09:04 +0200, Christian König wrote:
> Works for me.
+1
/Thomas
>
> Am 20.10.21 um 21:37 schrieb Jason Gunthorpe:
> > On Wed, Oct 20, 2021 at 08:41:24AM +0200, Christian König wrote:
> >
> > > > I think the patch subject needs updating to reflect that we're
> > > > disabli
From: Sankeerth Billakanti
Add edp controller and phy DT nodes for sc7280.
Signed-off-by: Sankeerth Billakanti
Signed-off-by: Krishna Manikandan
Changes in v2:
- Move regulator definitions to board file (Matthias Kaehlcke)
- Move the gpio definitions to board file (Matthias Kaehlcke)
On 10/20/21 18:12, Dan Williams wrote:
> On Wed, Oct 20, 2021 at 10:09 AM Joao Martins
> wrote:
>> On 10/19/21 20:21, Dan Williams wrote:
>>> On Tue, Oct 19, 2021 at 9:02 AM Jason Gunthorpe wrote:
On Tue, Oct 19, 2021 at 04:13:34PM +0100, Joao Martins wrote:
> On 10/19/21 00:06, Jason G
From: Sankeerth Billakanti
The Qualcomm SC7280 platform supports an eDP controller, add
compatible string for it to dp-controller.
Signed-off-by: Sankeerth Billakanti
---
Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Docume
On 10/19/21 20:21, Dan Williams wrote:
> On Tue, Oct 19, 2021 at 9:02 AM Jason Gunthorpe wrote:
>>
>> On Tue, Oct 19, 2021 at 04:13:34PM +0100, Joao Martins wrote:
>>> On 10/19/21 00:06, Jason Gunthorpe wrote:
On Mon, Oct 18, 2021 at 12:37:30PM -0700, Dan Williams wrote:
>> device-da
Add mdss and mdp DT nodes for sc7280.
Signed-off-by: Krishna Manikandan
Changes in v2:
- Rename display dt nodes (Stephen Boyd)
- Add clock names one per line for readability (Stephen Boyd)
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 90
1 file changed, 9
This series will add eDP controller support for Qualcomm SC7280
platform. These patches are baseline changes with which we can enable
eDP display on sc7280. The sc7280 eDP controller can also support
additional features such as which will be enabled in subsequent patch series.
This is base
Some built-in modules will failed to use dma-buf heap to allocate
memory if the heap drivers is too late to be initialized.
To fix this issue, move initialization of dma-buf heap drivers in
subsys_initcall() which is more earlier to be called.
Signed-off-by: Shuosheng Huang
---
drivers/dma-buf/h
Add DSI controller and PHY nodes for sc7280.
Signed-off-by: Rajeev Nandan
Signed-off-by: Krishna Manikandan
Reviewed-by: Matthias Kaehlcke
Changes in v2:
- Drop flags from interrupts (Stephen Boyd)
- Rename dsi-opp-table (Stephen Boyd)
- Rename dsi phy node (Stephen Boyd)
---
arc
From: Sankeerth Billakanti
The eDP controller on SC7280 is similar to the eDP/DP controllers
supported by the current driver implementation.
SC7280 supports one EDP and one DP controller which can operate
concurrently.
The following are some required changes to support eDP on sc7280:
1. SC7280
MSM Mobile Display Subsystem (MDSS) encapsulates sub-blocks
like DPU display controller, DSI, EDP etc. Add required DPU
device tree bindings for SC7280.
Signed-off-by: Krishna Manikandan
Changes in v2:
- Drop target from description (Stephen Boyd)
- Drop items from compatible (Stephen Boyd)
https://bugzilla.kernel.org/show_bug.cgi?id=214029
--- Comment #20 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Christian König from comment #19)
> Created attachment 299277 [details]
> Potential fix
Fixes the leak as it does in bug #214447. Thanks!
--
You may reply to this email to ad
Hi,
We've encountered an issue with the RaspberryPi DSI panel that prevented the
whole display driver from probing.
The issue is described in detail in the commit 7213246a803f ("drm/vc4: dsi:
Only register our component once a DSI device is attached"), but the basic idea
is that since the panel i
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device. This also avoids leaking the device when we detach
the bridge.
Acked-by: Sam Ravnborg
Tested-by: John Stultz
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/adv7511/adv7511.h | 1 -
drivers
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Acked-by: Sam Ravnborg
Tested-by: John Stultz
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/adv7511/ad
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 20 ++
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/lontium-lt8912b.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/lontium-lt8912b.c | 11 +++
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device.
Acked-by: Sam Ravnborg
Tested-by: John Stultz
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
di
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Acked-by: Sam Ravnborg
Tested-by: John Stultz
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/lontium-lt
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 38 +-
1 file changed, 8 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 31 +
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device. This also avoids leaking the device on removal.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/parade-ps8640.c | 15 +--
1 file changed, 5 insertions(+), 10 de
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/parade-ps8640.c | 100
Commit 24417d5b0c00 ("drm/bridge: ti-sn65dsi83: Implement .detach
callback") moved the unregistration of the bridge DSI device and bridge
itself to the detach callback.
While this is correct for the DSI device detach and unregistration, the
bridge is added in the driver probe, and should thus be r
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device. This also avoids leaking the device when we detach
the bridge but don't remove its driver.
Acked-by: Sam Ravnborg
Tested-by: Laurent Pinchart
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/ti-s
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Acked-by: Sam Ravnborg
Tested-by: Laurent Pinchart
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/ti-sn
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device. This also avoids leaking the device when we detach
the bridge.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 22 +++---
1 file changed, 7
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 77 ++
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device. This also avoids leaking the device when we detach
the bridge.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/tc358775.c | 13 -
1 file changed, 4 insertions(+
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Acked-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/tc358775.c | 37 ++
From: Rob Clark
Switch to the documented order dsi-host vs bridge probe.
Tested-by: Amit Pundir
Tested-by: Caleb Connolly
Tested-by: John Stultz
Signed-off-by: Rob Clark
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/msm/dsi/dsi.c | 50 ---
drivers/gpu/drm
Without proper care and an agreement between how DSI hosts and devices
drivers register their MIPI-DSI entities and potential components, we can
end up in a situation where the drivers can never probe.
Most drivers were taking evasive maneuvers to try to workaround this,
but not all of them were f
From: mwezdeck
The idea behind the commit:
1. when resource is created, let user space decide
if resource should be pinned or not
2. transfer_*_host needs pinned memory. If it is not
pinned, then pin it.
3. during execbuffer, decide which bo handles should
be pinned based on
On Tue, Oct 19, 2021 at 03:02:13PM +0300, Laurent Pinchart wrote:
> Hi Maxime,
>
> Thank you for the patch.
>
> On Wed, Sep 29, 2021 at 10:42:28AM +0200, Maxime Ripard wrote:
> > of_graph_get_port_by_id doesn't modify the device_node pointer it takes
> > as argument, so we can make it const.
>
>
On 10/20/21 20:24, Naresh Kamboju wrote:
> Following kernel crash noticed on linux next 20211020 tag.
> while booting on arm64 architecture dragonboard 410c device.
>
> I see the following config is enabled in 20211020 tag builds.
> CONFIG_STACKDEPOT=y
>
> Crash log,
> [ 18.583097] Unable to ha
On Tue, 19 Oct 2021 20:10:28 +0200, Jernej Skrabec wrote:
> Driver never uses virtual address of DRM CMA buffers. Switch to CMA
> helpers which don't deal with virtual mapping.
>
> This was actually already the case before commit ad408c766cef
> ("drm/sun4i: Use DRM_GEM_CMA_VMAP_DRIVER_OPS for GEM
Hi,
On Wed, Oct 20, 2021 at 06:09:32PM +0800, Kevin Tang wrote:
> Maxime Ripard 于2021年9月28日周二 下午5:28写道：
> > > > > +static int sprd_dsi_find_panel(struct sprd_dsi *dsi)
> > > > > +{
> > > > > + struct device *dev = dsi->host.dev;
> > > > > + struct device_node *child, *lcds_node;
> > > > >
On Thu, 21 Oct 2021, Vlastimil Babka wrote:
> On 10/20/21 20:24, Naresh Kamboju wrote:
>> Following kernel crash noticed on linux next 20211020 tag.
>> while booting on arm64 architecture dragonboard 410c device.
>>
>> I see the following config is enabled in 20211020 tag builds.
>> CONFIG_STACKD
https://bugzilla.kernel.org/show_bug.cgi?id=214029
--- Comment #21 from Christian König (christian.koe...@amd.com) ---
No problem. It just took me a while to realize what the issue is.
The patches bisected didn't caused it, but rather just made it more likely to
appear.
Can I add your mail as Te
https://bugzilla.kernel.org/show_bug.cgi?id=214197
--- Comment #7 from vele...@gmail.com ---
Kernel 5.14.14 already has it but it's not fixed. I got mostly the same dmesg
message but somewhat different:
[ 367.167527] amdgpu :03:00.0: amdgpu: RAS: optional ras ta ucode is not
available
[ 367
Am 20.10.21 um 19:47 schrieb Christian König:
Am 20.10.21 um 19:43 schrieb Alex Deucher:
On Wed, Oct 20, 2021 at 1:32 PM Christian König
wrote:
We need to cleanup the fences for ghost objects as well.
Signed-off-by: Christian König
CC:
Does this fix this bug?
https://bugzilla.kernel.org
[AMD Official Use Only]
> -Original Message-
> From: Christian König
> Sent: Thursday, October 21, 2021 5:06 PM
> To: Alex Deucher ; Huang, Ray
>
> Cc: Maling list - DRI developers
> Subject: Re: [PATCH] drm/ttm: fix memleak in ttm_transfered_destroy
>
>
>
> Am 20.10.21 um 19:47 schr
On Thu, Oct 21, 2021 at 09:44:45AM +0200, Maksym Wezdecki wrote:
> From: mwezdeck
>
> The idea behind the commit:
> 1. when resource is created, let user space decide
> if resource should be pinned or not
> 2. transfer_*_host needs pinned memory. If it is not
> pinned, then pin it.
DP_INTF is similar to DPI but does not have the exact same feature set
or register layouts.
DP_INTF is the sink of the display pipeline that is connected to the
DisplayPort controller and encoder unit. It takes the same clocks as
DPI.
Signed-off-by: Markus Schneider-Pargmann
---
Notes:
Chan
Hi everyone,
this series is built around the DisplayPort driver. The dpi/dpintf
driver and the added helper functions are required for the DisplayPort
driver to work.
In v5 I reworked the mtk-dpi so that dpintf is only using the same three clocks
as dpi does. This lead to the removal of the separ
This is a new driver that supports the integrated DisplayPort phy for
mediatek SoCs, especially the mt8195. The phy is integrated into the
DisplayPort controller and will be created by the mtk-dp driver. This
driver expects a struct regmap to be able to work on the same registers
as the DisplayPort
dpintf is the displayport interface hardware unit. This unit is similar
to dpi and can reuse most of the code.
This patch adds support for mt8195-dpintf to this dpi driver. Main
differences are:
- Some features/functional components are not available for dpintf
which are now excluded from code
Similar to HDMI, DP uses audio infoframes as well which are structured
very similar to the HDMI ones.
This patch adds a helper function to pack the HDMI audio infoframe for
DP, called hdmi_audio_infoframe_pack_for_dp().
hdmi_audio_infoframe_pack_only() is split into two parts. One of them
packs th
This controller is present on several mediatek hardware. Currently
mt8195 and mt8395 have this controller without a functional difference,
so only one compatible field is added.
The controller can have two forms, as a normal display port and as an
embedded display port.
Signed-off-by: Markus Schn
This patch adds two helper functions that extract the frequency and word
length from a struct cea_sad.
For these helper functions new defines are added that help translate the
'freq' and 'byte2' fields into real numbers.
Signed-off-by: Markus Schneider-Pargmann
---
Notes:
Changes v2 -> v3:
This patch adds a DisplayPort driver for the Mediatek mt8195 SoC and a
according phy driver mediatek-dp-phy.
It supports both functional units on the mt8195, the embedded
DisplayPort as well as the external DisplayPort units. It offers
hot-plug-detection, audio up to 8 channels, and DisplayPort 1.
Hi Dave,
New drm-misc-fixes without the vc4 changes. I feel that needs some more
discussion first.
drm-misc-fixes-2021-10-21-1:
drm-misc-fixes for v5.15-rc7:
- Rebased, to remove vc4 patches.
- Fix mxsfb crash on unload.
- Use correct sync parameters for Feixin K101-IM2BYL02.
- Assorted kmb mode
On Wed, 20 Oct 2021, Khaled Almahallawy wrote:
> DPCD 248h name was changed from “PHY_TEST_PATTERN” in DP 1.4 to
> “LINK_QUAL_PATTERN_SELECT” in DP 2.0.
Please use ASCII double quotes ". Please reflow the commit message to
limit line lenghts to about 72 characters.
> Also, DPCD 248h [6:0] is th
On Wed, 20 Oct 2021, Khaled Almahallawy wrote:
> This series updates DPCD 248h register name and PHY test patterns names to
> follow DP 2.0 Specs.
> Also updates the DP PHY CTS codes of the affected drivers (i915, amd, msm)
> No functional changes expected.
>
> Reference: “DPCD 248h/10Bh/10Ch/1
[Public]
> -Original Message-
> From: Bhawanpreet Lakha
> Sent: Thursday, October 21, 2021 3:47 AM
> To: Zuo, Jerry ; dri-devel@lists.freedesktop.org;
> ly...@redhat.com
> Cc: Wentland, Harry ; Lin, Wayne ;
> Kazlauskas, Nicholas
> ; Lipski, Mikita ;
> intel-...@lists.freedesktop.org
>
The signaled bit is already used for quick testing if a fence is signaled.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/Makefile| 1 -
drivers/gpu/drm/i915/dma_resv_utils.c| 17 -
drivers/gpu/drm/i915/dma_resv_utils.h| 13
Use a single null-terminated array for simplicity instead of a linked
list. This might slightly speed up execbuf when many vma's may be marked
as capture, but definitely removes an allocation from a signaling path.
We are not allowed to allocate memory in eb_move_to_gpu, but we can't
enforce it ye
gen6_ppgtt_unpin_all is unused, kill it.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 11 ---
drivers/gpu/drm/i915/gt/gen6_ppgtt.h | 1 -
2 files changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
b/driv
The i915_request fence wait behaves differently for timeout = 0
compared to expected dma-fence behavior.
i915 behavior:
- Unsignaled: -ETIME
- Signaled: 0 (= timeout)
Expected:
- Unsignaled: 0
- Signaled: 1
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_request.c | 57 +
This allows us to finally get rid of all the assumptions that vma->obj is NULL.
Changes since v1:
- Ensure the mock_ring vma is pinned to prevent a fault.
- Pin it high to avoid failure in evict_for_vma selftest.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/mock_engine.c | 38 ++
From: Christian König
Simplifying the code a bit.
Signed-off-by: Christian König
[mlankhorst: Handle timeout = 0 correctly, use new i915_request_wait_timeout.]
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 65
1 file changed, 20 inser
When reworking the code to move the eviction fence to the object,
the best code is removed code.
Remove some functions that are unused, and change the function definition
if it's only used in 1 place.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i
We currently have to special case vma->obj being NULL because
of gen6 ppgtt and mock_engine. Fix gen6 ppgtt, so we may soon
be able to remove a few checks. As the object only exists as
a fake object pointing to ggtt, we have no backing storage,
so no real object is created. It just has to look real
It's just an alias to vma->obj->base.resv, no need to duplicate it.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
drivers/gpu/drm/i915/i915_vma.c| 9 -
drivers/gpu/drm/i915/i915_vma.h
Resetting will clear the CONTEXT_VALID_BIT, so wait until after that to test.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/in
Call drop_pages with the gem object lock held, instead of the other
way around. This will allow us to drop the vma bindings with the
gem object lock held.
We plan to require the object lock for unpinning in the future,
and this is an easy target.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Nir
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
i915_gem_execbuf will call i915_gem_evict_vm() after failing to pin
all objects in the first round. We are about to remove those short-term
pins, but even without those the objects are still locked. Add a special
case to allow i915_gem_evict_vm to evict locked objects as well.
This might also allo
Big delta, but boils down to moving set_pages to i915_vma.c, and removing
the special handling, all callers use the defaults anyway. We only remap
in ggtt, so default case will fall through.
Because we still don't require locking in i915_vma_unpin(), handle this by
using xchg in get_pages(), as it
Be thorough..
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 22c891720c6d..7c5ed5957fe2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu
vma->obj and vma->resv are now never NULL, and some checks can be removed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 48 ---
dr
Now that we require locking to evict, multiple vmas from the same object
might not be evicted. This is expected and required, because execbuf will
move to short-term pinning by using the lock only. This will cause these
tests to fail, because they create a ton of vma's for the same object.
Unbind
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_gem.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 981e383d1a5d..6aa9e465b48e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/dr
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_object.h| 8 --
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 4 +--
drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 2 +-
drivers/gpu/drm/i915/gt/intel_engin
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.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 18
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
Now that freeing objects takes the object lock when destroying the
backing pages, we can confidently take the object lock even for dead
objects.
Use this fact to take the object lock in the shrinker, without requiring
a reference to the object, so all calls to unbind take the object lock.
This is
i915_vma_wait_for_bind needs the vma lock held, fix the caller.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_vma.c | 40 +++--
1 file changed, 28 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915
In the next commit, we don't evict when refcount = 0, so we need to
call drain freed objects, because we want to pin new bo's in the same
place, causing a test failure.
Furthermore, since each subtest is separated, it's a lot better to use
i915_live_selftests, so each subtest starts with a clean s
In the next commit, we don't evict when refcount = 0.
igt_vm_isolation() continuously tries to pin/unpin at same address,
but also calls put() on the object, which means the object may not
be unpinned in time.
Instead of this, re-use the same object over and over, so they can
be unbound as requir
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
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 4 ++--
drivers/g
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 | 40 +--
TTM already requires this, and we require it for delayed destroy.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
inde
Am 21.10.21 um 12:35 schrieb Maarten Lankhorst:
From: Christian König
Simplifying the code a bit.
Signed-off-by: Christian König
[mlankhorst: Handle timeout = 0 correctly, use new i915_request_wait_timeout.]
Signed-off-by: Maarten Lankhorst
LGTM, do you want to push it or should I pick it
Op 21-10-2021 om 12:38 schreef Christian König:
> Am 21.10.21 um 12:35 schrieb Maarten Lankhorst:
>> From: Christian König
>>
>> Simplifying the code a bit.
>>
>> Signed-off-by: Christian König
>> [mlankhorst: Handle timeout = 0 correctly, use new
>> i915_request_wait_timeout.]
>> Signed-off-by:
On 21/10/2021 12:06, Maarten Lankhorst wrote:
Op 21-10-2021 om 12:38 schreef Christian König:
Am 21.10.21 um 12:35 schrieb Maarten Lankhorst:
From: Christian König
Simplifying the code a bit.
Signed-off-by: Christian König
[mlankhorst: Handle timeout = 0 correctly, use new i915_request_wa
tree: git://anongit.freedesktop.org/drm-intel drm-intel-gt-next
head: ab5d964c001b9efffcbfa4d67a30186b67d79771
commit: a035154da45d19e09dc68454673ff257a660aece [5/10] drm/i915/dmabuf: add
paranoid flush-on-acquire
config: x86_64-randconfig-a004-20211021 (attached as .config)
compiler: clang
On Tue, Oct 19, 2021 at 12:30:40PM -0400, Felix Kuehling wrote:
> Am 2021-10-19 um 7:36 a.m. schrieb Christian König:
> > Am 13.10.21 um 16:07 schrieb Daniel Vetter:
> >> On Tue, Oct 05, 2021 at 01:37:26PM +0200, Christian König wrote:
> >>> Simplifying the code a bit.
> >>>
> >>> Signed-off-by: Ch
On Tue, Oct 19, 2021 at 01:49:08PM +0200, Christian König wrote:
> Am 13.10.21 um 16:14 schrieb Daniel Vetter:
> > On Tue, Oct 05, 2021 at 01:37:28PM +0200, Christian König wrote:
> > > Simplifying the code a bit. Also drop the RCU read side lock since the
> > > object is locked anyway.
> > >
> >
On Tue, Oct 19, 2021 at 05:51:38PM +0200, Christian König wrote:
> Am 19.10.21 um 16:30 schrieb Daniel Vetter:
> > On Tue, Oct 19, 2021 at 03:02:26PM +0200, Christian König wrote:
> > > Am 13.10.21 um 16:23 schrieb Daniel Vetter:
> > > > On Tue, Oct 05, 2021 at 01:37:38PM +0200, Christian König wro
On Tue, Oct 05, 2021 at 01:37:38PM +0200, Christian König wrote:
> Makes the handling a bit more complex, but avoids the use of
> dma_resv_get_excl_unlocked().
>
> v2: improve coding and documentation
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/drm_gem_atomic_helper.c | 13 ++
On Wed, Oct 20, 2021 at 11:09:58AM -0300, Jason Gunthorpe wrote:
> On Wed, Oct 20, 2021 at 08:34:33AM +0200, Thomas Hellström wrote:
>
> > Follow up question: If we resurrect this in the proper way (and in that case
> > only for x86_64) is there something we need to pay particular attention to
> >
On Wed, Oct 20, 2021 at 04:37:02PM -0300, Jason Gunthorpe wrote:
> On Wed, Oct 20, 2021 at 08:41:24AM +0200, Christian König wrote:
>
> > > I think the patch subject needs updating to reflect that we're disabling
> > > PUD/PMDs completely.
> > > With that fixed,
>
> Everyone is OK with this?
>
>
In theory if clflush_work_create() somehow fails here, and we don't yet
have mm.pages populated then we end up resetting cache_dirty, which is
likely wrong, since that will potentially skip the flush-on-acquire, if
it was needed.
It looks like intel_user_framebuffer_dirty() can arrive here before
We seem to have an unfortunate issue where we arrive from:
i915_gem_object_flush_if_display+0x86/0xd0 [i915]
intel_user_framebuffer_dirty+0x1a/0x50 [i915]
drm_mode_dirtyfb_ioctl+0xfb/0x1b0
Which can be before the pages are populated(and pinned for display), and
so i915_gem_object_has_
Move it next to its partner in crime; gpu_write_needs_clflush.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 12
drivers/gpu/drm/i915/gem/i915_gem_object.h | 15 ++-
drivers/gpu/drm/i915/i915_gem.c| 2 +-
Should not be needed. Even with non-coherent display, we should be using
device local-memory there, and not system memory.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 10 ++
drivers/gpu/drm/i915/gem/i915_gem_object.c | 7 +--
dr
1 - 100 of 252 matches
Mail list logo
