On Fri, Nov 26, 2021 at 9:34 PM Maxime Ripard wrote:
>
> On Thu, Nov 25, 2021 at 09:44:14PM +0530, Jagan Teki wrote:
> > On Thu, Nov 25, 2021 at 9:40 PM Maxime Ripard wrote:
> > >
> > > On Thu, Nov 25, 2021 at 07:55:41PM +0530, Jagan Teki wrote:
> > > > Hi,
> > > >
> > > > On Thu, Nov 25, 2021 at
Hi Kieran,
On Fri, Nov 26, 2021 at 3:45 PM Kieran Bingham
wrote:
>
> The bridge probe ordering for DSI devices has been clarified and further
> documented in
>
> To support connecting with the SN65DSI86 device after commit c3b75d4734cb
> ("drm/bridge: sn65dsi86: Register and attach our DSI device
On Tue, Nov 30, 2021 at 08:05:08AM +0800, davidcomponent...@gmail.com wrote:
> From: Yang Guang
>
> coccinelle report:
> ./drivers/video/fbdev/core/fbcon.c:2680:8-16:
> WARNING: use scnprintf or sprintf
> ./drivers/video/fbdev/core/fbcon.c:2655:8-16:
> WARNING: use scnprintf or sprintf
>
> Use s
> > >
> > > Simpledrm is just a driver, but this is platform setup code. Why is this
> > > code located here and not under arch/ or drivers/firmware/?
> > >
Agreed. Creating platform devices is something for platform code and
not really a DRM driver.
> > > I know that other drivers do similar thi
On 16-11-21, 18:07, Peter Collingbourne wrote:
> It has been observed that with certain monitors such as the HP Z27n,
> the register 0x825e reads a value of 0x79 when the HDMI cable is
> connected and 0x78 when it is disconnected, i.e. bit 0 appears
> to correspond to the HDMI connection status and
Hi Kieran,
Thank you for the patch.
On Fri, Nov 26, 2021 at 09:35:14AM +, Kieran Bingham wrote:
> On platforms with an external clock, both the group and crtc must be
> handled accordingly to correctly pass through the external clock and
> configure the DU to use the external rate.
>
> The C
MT8195 have two mmsys. Modify drm for MT8195 multi-mmsys support.
The two mmsys (vdosys0 and vdosys1) will bring up two drm drivers,
only one drm driver register as the drm device.
Each drm driver binds its own component. The last bind drm driver
allocates and registers the drm device to drm core.
Add merge async reset control in mtk_merge_stop. Async hw doesn't do self
reset on each sof signal(start of frame), so need to reset the async to
clear the hw status for the next merge start.
Signed-off-by: Nancy.Lin
---
drivers/gpu/drm/mediatek/mtk_disp_merge.c | 4
1 file changed, 4 inser
This is a preparation for adding support for mt8195 vdosys1 mutex.
The vdosys1 path component contains ovl_adaptor, merge5,
and dp_intf1. Ovl_adaptor is composed of several sub-elements,
so change it to support multi-bit control.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mtk-mutex.c | 24
Add plane color encoding information for color space conversion.
It's a preparation for adding support for mt8195 ovl_adaptor mdp_rdma
csc control.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 1 +
drivers/gpu/drm/mediatek/mtk_drm_plane.h |
Add mt8195 vdosys1 clock driver name and routing table to
the driver data of mtk-mmsys.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mt8195-mmsys.h| 136 +
drivers/soc/mediatek/mtk-mmsys.c | 10 ++
include/linux/soc/mediatek/mtk-mmsys.h | 2 +
3 files ch
Add merge new advance config API. The original merge API is
mtk_ddp_comp_funcs function prototype. The API interface parameters
cannot be modified, so add a new config API for extension. This is
the preparation for ovl_adaptor merge control.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
--
The hardware path of vdosys1 with DPTx output need to go through by several
modules, such as, OVL_ADAPTOR and MERGE.
Add DRM and these modules support by the patches below:
Changes in v9:
- rebase on kernel-5.16-rc1
- rebase on vdosys0 series v13. (ref [5])
- fix ovl_adaptor sub driver is brough
Add ovl_adaptor driver for MT8195.
Ovl_adaptor is an encapsulated module and designed for simplified
DRM control flow. This module is composed of 8 RDMAs, 4 MERGEs and
an ETHDR. Two RDMAs merge into one layer, so this module support 4
layers.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
-
Add display node for vdosys1.
Signed-off-by: Nancy.Lin
---
arch/arm64/boot/dts/mediatek/mt8195.dtsi | 222 +++
1 file changed, 222 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
index e136761345db..a69a7b57e070
Add vdosys1 ETHDR definition.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
---
.../display/mediatek/mediatek,ethdr.yaml | 147 ++
1 file changed, 147 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
diff --git
Add drm ovl_adaptor sub driver. Bring up ovl_adaptor sub driver if
the component exists in the path.
Signed-off-by: Nancy.Lin
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 16
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 30 ---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp
Add merge mute/unmute setting for MT8195.
MT8195 Vdosys1 merge1~merge4 support HW mute function.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_disp_merge.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp
Add driver data of mt8195 vdosys1 to mediatek-drm.
Signed-off-by: Nancy.Lin
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 36430f956b4f..e851
Add vdosys1 RDMA definition.
Signed-off-by: Nancy.Lin
---
.../arm/mediatek/mediatek,mdp-rdma.yaml | 77 +++
1 file changed, 77 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/mediatek/mediatek,mdp-rdma.yaml
diff --git
a/Documentation/devicetree/bi
Add MDP_RDMA driver for MT8195. MDP_RDMA is the DMA engine of
the ovl_adaptor component.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/Makefile | 3 +-
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 7 +
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
dr
Add merge start/stop API for cmdq support. The ovl_adaptor merges
are configured with each drm plane update. Need to enable/disable
merge with cmdq making sure all the settings taken effect in the
same vblank.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_
ETHDR is a part of ovl_adaptor.
ETHDR is designed for HDR video and graphics conversion in the external
display path. It handles multiple HDR input types and performs tone
mapping, color space/color format conversion, and then combine
different layers, output the required HDR or SDR signal to the
s
Add mmsys config API. The config API is used for config mmsys reg.
Some mmsys regs need to be setting according to the HW engine binding
to the mmsys simultaneously.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mt8195-mmsys.h| 62 ++
drivers/soc/mediatek/mtk-mmsy
Add mtk-mutex support for mt8195 vdosys1.
The vdosys1 path component contains ovl_adaptor, merge5,
and dp_intf1. Ovl_adaptor is composed of several sub-elements.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mtk-mutex.c | 54
1 file changed, 54 insertions(+)
MT8195 vdosys1 has more than 32 reset bits and a different reset base
than other chips. Modify mmsys for support 64 bit and different reset
base.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mt8195-mmsys.h | 1 +
drivers/soc/mediatek/mtk-mmsys.c| 21 -
drivers/soc/m
Add vdosys1 reset control bit for MT8195 platform.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
---
include/dt-bindings/reset/mt8195-resets.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/dt-bindings/reset/mt8195-resets.h
b/include/dt-bindings/reset/mt8195-re
MT8195 vdosys1 merge1 to merge4 have HW mute function.
Add MERGE additional mute property description.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
Acked-By: AngeloGioacchino Del Regno
---
.../devicetree/bindings/display/mediatek/mediatek,merge.yaml | 4
1 file changed, 4 insertio
Add cmdq support for mtk-mmsys config API.
The mmsys config register settings need to take effect with the other
HW settings(like OVL_ADAPTOR...) at the same vblanking time.
If we use CPU to write the mmsys reg, we can't guarantee all the
settings can be written in the same vblanking time.
Cmdq is
Hi Kieran,
Thank you for the patch.
On Fri, Nov 26, 2021 at 10:15:18AM +, Kieran Bingham wrote:
> The bridge probe ordering for DSI devices has been clarified and further
> documented in
In what ? :-)
> To support connecting with the SN65DSI86 device after commit c3b75d4734cb
> ("drm/bridge
Hi Kieran,
Thank you for the patch.
On Fri, Nov 26, 2021 at 10:15:17AM +, Kieran Bingham wrote:
> The debug reporting for the clock calculations was erroneously reporting
> the last calculation of fout, rather than the fout that was determined
> to have the least error, and therefore be the v
Hi Kieran,
Thank you for the patch.
On Fri, Nov 26, 2021 at 10:15:16AM +, Kieran Bingham wrote:
> The RCAR_MIPI_DSI uses the DRM_MIPI_DSI interface.
>
> Ensure that it is selected when the option is enabled.
>
> Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
I'll squash it
Hi Kieran,
Thank you for the patch.
On Fri, Nov 26, 2021 at 10:15:15AM +, Kieran Bingham wrote:
> From: Kieran Bingham
>
> Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> d
Hi Kieran,
Thank you for the patch.
On Mon, Nov 29, 2021 at 05:08:45PM +, Kieran Bingham wrote:
> The DSI output names were not added when the DSI pipeline support was
> introduced.
>
> Add the correct labels for these outputs, and fix the sort order to
> match 'enum rcar_du_output' while we
Hi Vinod
On 11/15/2021 10:22 PM, Vinod Koul wrote:
Display Stream Compression (DSC) parameters need to be calculated. Add
helpers and struct msm_display_dsc_config in msm_drv for this
msm_display_dsc_config uses drm_dsc_config for DSC parameters.
Signed-off-by: Vinod Koul
---
drivers/gpu/drm
While working on supporting the Intel HDR backlight interface, I noticed
that there's a couple of laptops that will very rarely manage to boot up
without detecting Intel HDR backlight support - even though it's supported
on the system. One example of such a laptop is the Lenovo P17 1st
generation.
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/vc4/vc4_kms.c
between commits:
f927767978d2 ("drm/vc4: kms: Fix return code check")
d354699e2292 ("drm/vc4: kms: Don't duplicate pending commit")
from the drm-misc-fixes tree and commit:
16e101051f32 (
On Wed, Nov 17, 2021 at 03:50:36PM +0100, Maxime Ripard wrote:
> The firmware can free all the resources it was using to run the display
> engine that won't be needed once the kernel has taken over.
>
> Thus, we need a phandle to the firmware DT node to be able to send that
> message when relevant
On Wed, Nov 17, 2021 at 03:33:39PM +0100, Sascha Hauer wrote:
> The RK3568 has HDMI_TX_AVDD0V9 and HDMI_TX_AVDD_1V8 supply inputs needed
> for the HDMI port. add support for these to the driver for boards which
> have them supplied by switchable regulators.
>
> Signed-off-by: Sascha Hauer
> ---
>
When the CMM is enabled, an offset of 25 pixels must be subtracted from
the HDS (horizontal display start) and HDE (horizontal display end)
registers. Fix the timings calculation, and take this into account in
the mode validation.
This fixes a visible horizontal offset in the image with VGA monito
On Mon, 15 Nov 2021 20:21:48 +, Sean Paul wrote:
> From: Sean Paul
>
> This patch adds the bindings for the MSM DisplayPort HDCP registers
> which are required to write the HDCP key into the display controller as
> well as the registers to enable HDCP authentication/key
> exchange/encryption.
On Sun, Nov 14, 2021 at 11:07:16PM +0300, Dmitry Osipenko wrote:
> From: Anton Bambura
>
> LQ101R1SX03 is compatible with LQ101R1SX01, document it.
Then sounds like '"sharp,lq101r1sx03", "sharp,lq101r1sx01"' would be the
appropriate compatible value. Do that, and you don't need a driver
change
On Sun, 14 Nov 2021 23:04:30 +0300, Dmitry Osipenko wrote:
> From: Svyatoslav Ryhel
>
> Add HannStar HSD101PWW2 10.1" WXGA (1280x800) TFT-LCD LVDS panel
> to the list of compatibles.
>
> Signed-off-by: Svyatoslav Ryhel
> ---
> .../devicetree/bindings/display/panel/panel-simple.yaml | 2
On Mon, Nov 29, 2021 at 10:18 AM Rob Clark wrote:
>
> From: Rob Clark
>
> Elsewhere we treat zero as "no fence" and __msm_gem_submit_destroy()
> skips removal from fence_idr. We could alternately change this to use
> negative values for "no fence" but I think it is more clear to not allow
> zero
Hi Rodrigo,
That will really be helpful!
I know drawing the line is a difficult problem (and can even make things
harder when searching), but maybe it would make sense to keep generic
acronyms not specific to amdgpu in a separate list. I bet a number of
them would be useful in the scope of other
With asynchronous migrations, the vma state may be several migrations
ahead of the state that matches the request we're capturing.
Address that by introducing an i915_vma_snapshot structure that
can be used to snapshot relevant state at request submission.
In order to make sure we access the correc
On Mon, 08 Nov 2021 19:33:22 +0100, David Heidelberg wrote:
> Sync all formats from simplefb.h into documentation.
>
> Signed-off-by: David Heidelberg
> ---
> .../bindings/display/simple-framebuffer.yaml | 12
> 1 file changed, 12 insertions(+)
>
Applied, thanks!
On Thu, Nov 25, 2021 at 10:40 AM Rodrigo Siqueira
wrote:
>
> In the DC driver, we have multiple acronyms that are not obvious most of
> the time. This commit introduces a DC glossary in order to make it
> easier to navigate through our driver.
>
> Signed-off-by: Rodrigo Siqueira
> ---
> Document
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #86 from James Zhu (jam...@amd.com) ---
Hi @kolAflash, thanks so much for your effort on this verification!
Would you mind help apply those patches on 5.12 stable to check also?
it should be automatically merged. Thanks! James
--
Yo
On Fri, Nov 19, 2021 at 9:24 PM Hector Martin wrote:
>
> On 18/11/2021 18.19, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 17.11.21 um 15:58 schrieb Hector Martin:
> >> @@ -897,5 +898,21 @@ static struct platform_driver
> >> simpledrm_platform_driver = {
> >>
> >>module_platform_driver(simpledr
The patch d1af5cd86997 ("drm: get rid of DRM_DEBUG_* log
calls in drm core, files drm_a*.c") fails when the drm_device
cannot be found in the parameter plane_state. Fix it.
Reported-by: kernel test robot
Fixes: d1af5cd86997 ("drm: get rid of DRM_DEBUG_* log calls in drm core, files
drm_a*.c")
Si
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #85 from kolAflash (kolafl...@kolahilft.de) ---
(In reply to James Zhu from comment #77)
> Created attachment 299697 [details]
> backport patch for 5.10 stable.
>
> Hi @kolAflash, before I send out them to public for review,. could yo
Am So., 28. Nov. 2021 um 21:20 Uhr schrieb Rikard Falkeborn
:
>
> The only usage of cooling_ops is to pass its address to
> thermal_of_cooling_device_register(), which takes a pointer to const
> struct thermal_cooling_device_ops as input. Make it const to allow the
> compiler to put it in read-only
From: Rob Clark
Elsewhere we treat zero as "no fence" and __msm_gem_submit_destroy()
skips removal from fence_idr. We could alternately change this to use
negative values for "no fence" but I think it is more clear to not allow
zero as a valid fence_id.
Signed-off-by: Rob Clark
---
drivers/gp
On Thu, Nov 25, 2021 at 11:48 PM wrote:
>
> From: Guangming
>
> For previous version, it uses 'sg_table.nent's to traverse sg_table in pages
> free flow.
> However, 'sg_table.nents' is reassigned in 'dma_map_sg', it means the number
> of
> created entries in the DMA adderess space.
> So, use 'sg
On Mon, Nov 29, 2021 at 4:48 AM Thomas Zimmermann wrote:
>
> Clean up the last non-legacy users of DRM's hashtable code and put
> the code behind CONFIG_DRM_LEGACY.
>
> TTM only includes the header file, but does not use the hashtable.
> The vmwgfx driver uses the hashtable internally. Copy the DR
On Wed, 2021-11-24 at 12:25 +, Liu, Yi L wrote:
> > From: Jason Gunthorpe
> > Sent: Fri, 1 Oct 2021 14:52:51 -0300
> >
> > The css_driver's main purpose is to create/destroy the mdev and
> > relay the
> > shutdown, irq, sch_event, and chp_event css_driver ops to the
> > single
> > created vfi
The DSI output names were not added when the DSI pipeline support was
introduced.
Add the correct labels for these outputs, and fix the sort order to
match 'enum rcar_du_output' while we are here.
Fixes: b291fdcf5114 ("drm: rcar-du: Add r8a779a0 device support")
Suggested-by: Biju Das
Signed-off
Currently the msm_dp_*** functions implement the same sequence which would
happen when drm_bridge is used. hence get rid of this intermediate layer
and align with the drm_bridge usage to avoid customized implementation.
Signed-off-by: Kuogee Hsieh
Changes in v2:
-- revise commit text
-- rename d
On 11/24/2021 11:45 AM, Dmitry Baryshkov wrote:
On 15/11/2021 21:48, Kuogee Hsieh wrote:
Currently the msm_dp_*** functions implement the same sequence which
would
happen when drm_bridge is used. hence get rid of this intermediate layer
and align with the drm_bridge usage to avoid customized
If a dma_fence_array is reported signaled by a call to
dma_fence_is_signaled(), it may leak the PENDING_ERROR status.
Fix this by clearing the PENDING_ERROR status if we return true in
dma_fence_array_signaled().
v2:
- Update Cc list, and add R-b.
Fixes: 1f70b8b812f3 ("dma-fence: Propagate error
On 2021-11-29 04:20, Pekka Paalanen wrote:
> On Fri, 26 Nov 2021 11:54:55 -0500
> Harry Wentland wrote:
>
>> On 2021-11-18 04:50, Pekka Paalanen wrote:
>>> On Mon, 15 Nov 2021 15:17:45 +0530
>>> Bhanuprakash Modem wrote:
>>>
From the Plane Color Management feature design, userspace ca
Il 29/11/21 15:53, Dmitry Baryshkov ha scritto:
Hi,
On Mon, 29 Nov 2021 at 17:15, AngeloGioacchino Del Regno
wrote:
Il 29/11/21 03:20, Dmitry Baryshkov ha scritto:
Hi,
On 25/11/2021 18:09, AngeloGioacchino Del Regno wrote:
Since commit 8f59ee9a570c ("drm/msm/dsi: Adjust probe order"), the
On 2021-11-18 04:19, Pekka Paalanen wrote:
> On Mon, 15 Nov 2021 15:17:52 +0530
> Bhanuprakash Modem wrote:
>
>> Negative check for:
>> * plane gamma lut sizes
>> * plane degamma lut sizes
>> * plane ctm matrix sizes
>>
>> Cc: Harry Wentland
>> Cc: Ville Syrjälä
>> Cc: Juha-Pekka Heikkila
Hi,
On Mon, 29 Nov 2021 at 17:15, AngeloGioacchino Del Regno
wrote:
>
> Il 29/11/21 03:20, Dmitry Baryshkov ha scritto:
> > Hi,
> >
> > On 25/11/2021 18:09, AngeloGioacchino Del Regno wrote:
> >> Since commit 8f59ee9a570c ("drm/msm/dsi: Adjust probe order"), the
> >> DSI host gets initialized ear
On Wed, 17 Nov 2021 10:45:21 +0100, Maxime Ripard wrote:
> The conversion to DRM commit helpers (f3c420fe19f8, "drm/vc4: kms: Convert to
> atomic helpers") introduced a number of issues in corner cases, most of them
> showing themselves in the form of either a vblank timeout or use-after-free
> err
Il 29/11/21 03:20, Dmitry Baryshkov ha scritto:
Hi,
On 25/11/2021 18:09, AngeloGioacchino Del Regno wrote:
Since commit 8f59ee9a570c ("drm/msm/dsi: Adjust probe order"), the
DSI host gets initialized earlier, but this caused unability to probe
the entire stack of components because they all dep
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
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 +--
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
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
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
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
TTM already requires this, and we require it for delayed destroy.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
---
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
We will need the lock to unbind the vma, and wait for bind to complete.
Remove the special casing for the !ww path, and force ww locking for all.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_drv.h | 7 ++-
drivers/gpu/drm/i915/i915_gem.c | 26 ++
2
We are moving away from short term pinning, and need a way to evict
objects locked by the current context. Pass the ww context to all
eviction functions, so that they can evict objects that are already
locked by the current ww context.
On top of that, this slightly improves ww handling because the
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
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
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
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
[mlankhorst: Remove ne
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
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
New version of the series, with feedback from previous series added.
First 11 patches are clean, some small fixes might required still for all to
pass.
Maarten Lankhorst (16):
drm/i915: Remove unused bits of i915_vma/active api
drm/i915: Change shrink ordering to use locking around unbinding
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
On 25-10-2021 17:02, Matthew Auld wrote:
> On Thu, 21 Oct 2021 at 11:37, Maarten Lankhorst
> wrote:
>> 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_res
On 21-10-2021 19:48, Matthew Auld wrote:
> On Thu, 21 Oct 2021 at 11:37, Maarten Lankhorst
> wrote:
>> Signed-off-by: Maarten Lankhorst
> Needs a proper commit message.
What about this?
>> ---
>> drivers/gpu/drm/i915/i915_gem.c | 9 -
>> 1 file changed, 8 insertions(+), 1 deletion(-)
(Switching to my @linux.intel.com address)
Quoting Christian König (2021-11-29 14:55:37)
> Am 29.11.21 um 13:46 schrieb Thomas Hellström:
> > On Mon, 2021-11-29 at 13:33 +0100, Christian König wrote:
> >> Am 29.11.21 um 13:23 schrieb Thomas Hellström:
> >>> Hi, Christian,
> >>>
> >>> On Mon, 2021-
Hi Nícolas,
On Thu, Nov 25, 2021 at 1:37 AM Nícolas F. R. A. Prado
wrote:
>
> Hi Igor,
>
> just some nits on the commit message.
>
> On Mon, Nov 22, 2021 at 04:43:52PM -0300, Igor Torrente wrote:
> > The `drm_mode_config_init` was deprecated since c3b790e commit, and it's
>
> When referring to o
Am 29.11.21 um 13:46 schrieb Thomas Hellström:
On Mon, 2021-11-29 at 13:33 +0100, Christian König wrote:
Am 29.11.21 um 13:23 schrieb Thomas Hellström:
Hi, Christian,
On Mon, 2021-11-29 at 09:21 +0100, Christian König wrote:
Am 29.11.21 um 08:35 schrieb Thomas Hellström:
If a dma_fence_array
On Mon, 2021-11-29 at 13:33 +0100, Christian König wrote:
> Am 29.11.21 um 13:23 schrieb Thomas Hellström:
> > Hi, Christian,
> >
> > On Mon, 2021-11-29 at 09:21 +0100, Christian König wrote:
> > > Am 29.11.21 um 08:35 schrieb Thomas Hellström:
> > > > If a dma_fence_array is reported signaled by
On 21-10-2021 19:39, Matthew Auld wrote:
> On Thu, 21 Oct 2021 at 11:37, Maarten Lankhorst
> wrote:
>> 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 fil
On 22-10-2021 12:59, Matthew Auld wrote:
> On Thu, 21 Oct 2021 at 18:30, Matthew Auld
> wrote:
>> On Thu, 21 Oct 2021 at 11:36, Maarten Lankhorst
>> wrote:
>>> Big delta, but boils down to moving set_pages to i915_vma.c, and removing
>>> the special handling, all callers use the defaults anyway.
From: Zhi Wang
To support the new mdev interfaces and the re-factor patches from
Christoph, which moves the GVT-g code into a dedicated module, the GVT-g
initialization path has to be separated into two phases:
a) Early initialization.
The early initialization of GVT requires to be done when lo
From: Zhi Wang
To support the early init of GVT-g, which will be put in i915, after the
GVT-g is moved into a dedicated module, we need to save the MMIO snapshot
in the early init of GVT-g, when the HW hasn't been touched.
v3:
- Fix errors when CONFIG_DRM_I915_WERROR is turned on. (Jani)
Cc: C
Am 29.11.21 um 13:23 schrieb Thomas Hellström:
Hi, Christian,
On Mon, 2021-11-29 at 09:21 +0100, Christian König wrote:
Am 29.11.21 um 08:35 schrieb Thomas Hellström:
If a dma_fence_array is reported signaled by a call to
dma_fence_is_signaled(), it may leak the PENDING_ERROR status.
Fix this
Hi, Christian,
On Mon, 2021-11-29 at 09:21 +0100, Christian König wrote:
> Am 29.11.21 um 08:35 schrieb Thomas Hellström:
> > If a dma_fence_array is reported signaled by a call to
> > dma_fence_is_signaled(), it may leak the PENDING_ERROR status.
> >
> > Fix this by clearing the PENDING_ERROR st
Am 25.11.21 um 16:59 schrieb Daniel Vetter:
[SNIP]
+ *
+ * For example when asking for WRITE fences then the KERNEL fences are returned
+ * as well. Similar when asked for READ fences then both WRITE and KERNEL
+ * fences are returned as well.
+ */
+enum dma_resv_usage {
+ /**
+* @
Instead of distingting between shared and exclusive fences specify
the fence usage while adding fences.
Rework all drivers to use this interface instead and deprecate the old one.
v2: some kerneldoc comments suggested by Daniel
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c
This change adds the dma_resv_usage enum and allows us to specify why a
dma_resv object is queried for its containing fences.
Additional to that a dma_resv_usage_rw() helper function is added to aid
retrieving the fences for a read or write userspace submission.
This is then deployed to the diffe
Not needed any more now we have that inside the framework.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 52 +++--
2 files changed, 6 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/dr
1 - 100 of 148 matches
Mail list logo
