If allocating the DMA buffer fails, mana_hwc_destroy_wq was called
without previously storing the pointer to the queue.
In order to avoid leaking the pointer to the queue, store it as soon as
it is allocated.
Addresses-Coverity-ID: 1484720 ("Resource leak")
Signed-off-by: José Expósito
---
driv
On Thu, Nov 4, 2021 at 8:05 PM Sean Paul wrote:
>
> From: Sean Paul
>
> This patch adds the register ranges required for HDCP key injection and
> HDCP TrustZone interaction as described in the dt-bindings for the
> sc7180 dp controller. Now that these are supported, change the
> compatible string
next-20211208]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Sascha-Hauer/drm-rockchip-RK356x-VO
On Wed, Dec 8, 2021 at 10:01 AM Dmitry Baryshkov
wrote:
>
> msm_ioremap() functions take additional argument dbgname used to output
> single debug line telling IO range. Drop that extra argument, use
> resource name instead.
For some history, the dbgname traces were used by an older tool that
cou
On 12/2/21 10:35 PM, Anusha Srivatsa wrote:
> diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
> index 391a4e2b8604..fd2d3ab38ebb 100644
> --- a/arch/x86/kernel/early-quirks.c
> +++ b/arch/x86/kernel/early-quirks.c
> @@ -554,6 +554,7 @@ static const struct pci_device_id
On Thu, Nov 4, 2021 at 8:04 PM Sean Paul wrote:
>
> From: Sean Paul
>
> Just me with another revision of HDCP support for msm.
>
> This v4 patch series is mostly a retread of v3 with the following
> changes:
> - rebased on Bjorn's displayport-controller register refactor
> - another change to the
When an application having open file access to a node forks, its shared
mappings also get reflected in the address space of child process even
though it cannot access them with the object permissions applied. With the
existing permission checks on the gem objects, it might be reasonable to
also cre
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 divided the driver life cycle of operation into four states,
resume (including
While the panel is only capable of showing 6bpc, the bus interface is
8bpc.
Signed-off-by: Lucas Stach
---
It seems there is no totally solid definition on what the panel bpc
should describe, bus or panel information, but this is the notion
currently enforced by the simple panel driver.
---
driv
From: Mark Yacoub
[Why]
The user space can allocate a LUT of any size. We must validate that it
is the expected MTK_LUT_SIZE.
[How]
Bring the .atomic_check function internal to mediatek driver and check
that the new CRTC state LUT size is equal to MTK_LUT_SIZE.
Fixes igt@kms_color@pipe-A-invali
Hi Geert,
On Wed, Dec 08, 2021 at 07:23:25PM +0100, Geert Uytterhoeven wrote:
> On Wed, Dec 8, 2021 at 7:00 PM Laurent Pinchart wrote:
> > On Wed, Dec 08, 2021 at 11:57:21AM +, Kieran Bingham wrote:
> > > Quoting Geert Uytterhoeven (2021-12-08 10:30:53)
> > > > Use the dev_err_probe() helper,
On 12/8/2021 11:30 AM, Felix Kuehling wrote:
Am 2021-12-08 um 11:58 a.m. schrieb Felix Kuehling:
Am 2021-12-08 um 6:31 a.m. schrieb Alistair Popple:
On Tuesday, 7 December 2021 5:52:43 AM AEDT Alex Sierra wrote:
Avoid long term pinning for Coherent device type pages. This could
interfere wit
Hi Laurent,
On Wed, Dec 8, 2021 at 7:00 PM Laurent Pinchart
wrote:
> On Wed, Dec 08, 2021 at 11:57:21AM +, Kieran Bingham wrote:
> > Quoting Geert Uytterhoeven (2021-12-08 10:30:53)
> > > Use the dev_err_probe() helper, instead of open-coding the same
> > > operation.
> > >
> > > Signed-off-b
msm_ioremap() functions take additional argument dbgname used to output
single debug line telling IO range. Drop that extra argument, use
resource name instead.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 8 +
Hello,
On Wed, Dec 08, 2021 at 11:57:21AM +, Kieran Bingham wrote:
> Quoting Geert Uytterhoeven (2021-12-08 10:30:53)
> > Use the dev_err_probe() helper, instead of open-coding the same
> > operation.
> >
> > Signed-off-by: Geert Uytterhoeven
> > ---
> > drivers/gpu/drm/rcar-du/rcar_du_drv.
On 07/12/2021 23:15, John Harrison wrote:
On 12/7/2021 09:53, Adrian Larumbe wrote:
Beginning with DG2, all successive devices will require GuC FW to be
present and loaded at probe() time. This change alters error handling in
the FW init and load functions so that the driver's probe() functio
On Tue, Dec 7, 2021 at 1:31 AM Hector Martin wrote:
>
> This code is required for both simplefb and simpledrm, so let's move it
> into the OF core instead of having it as an ad-hoc initcall in the
> drivers.
>
> Signed-off-by: Hector Martin
> ---
> drivers/of/platform.c | 5 +
> dr
On 07.12.21 21:45, Dan Moulding wrote:
There is a pretty obvious typo in there:
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -359,7 +359,7 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, struct
nouveau_channel *chan, bool e
fobj
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.
Changes in V4:
-- split this patch as stand alone patch
Changes in v5:
-- rebase on msm-next branc
Hi,
Could add a patch version to the subject?
On 12/8/21 4:12 PM, Sascha Hauer wrote:
> This enabled the VOP2 display controller along with hdmi and the
> required port routes which is enough to get a picture out of the
> hdmi port of the board.
>
> Signed-off-by: Sascha Hauer
> ---
> .../boot
Am 2021-12-08 um 11:58 a.m. schrieb Felix Kuehling:
> Am 2021-12-08 um 6:31 a.m. schrieb Alistair Popple:
>> On Tuesday, 7 December 2021 5:52:43 AM AEDT Alex Sierra wrote:
>>> Avoid long term pinning for Coherent device type pages. This could
>>> interfere with their own device memory manager.
>>
Hi,
On 12/8/21 4:12 PM, Sascha Hauer wrote:
> From: Andy Yan
>
> The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568.
> It replaces the VOP unit found in the older Rockchip SoCs.
>
> This driver has been derived from the downstream Rockchip Kernel and
> heavily modified:
>
> -
Am 2021-12-08 um 6:31 a.m. schrieb Alistair Popple:
> On Tuesday, 7 December 2021 5:52:43 AM AEDT Alex Sierra wrote:
>> Avoid long term pinning for Coherent device type pages. This could
>> interfere with their own device memory manager.
>> If caller tries to get user device coherent pages with PIN
Hi,
On Tue, Dec 7, 2021 at 8:44 PM Stephen Boyd wrote:
>
> Quoting Rob Clark (2021-12-07 13:57:52)
> > From: Rob Clark
> >
> > Otherwise we don't get another shot at it if the bridge probes before
> > the dsi host is registered. It seems like this is what *most* (but not
> > all) of the other b
Hi Sascha,
Am Mittwoch, 8. Dezember 2021, 16:12:30 CET schrieb Sascha Hauer:
> On the rk3568 we have this (simplified) situation:
>
> .. .-..-.
> -| hpll |--.--| /n ||dclk_vop0|-
> `´ | `-´`-´
> | .-..-.
Am 08.12.21 um 11:08 schrieb Lionel Landwerlin:
On 08/12/2021 11:28, Christian König wrote:
Am 08.12.21 um 03:39 schrieb Bas Nieuwenhuizen:
dma_fence_chain_find_seqno only ever returns the top fence in the
chain or an unsignalled fence. Hence if we request a seqno that
is already signalled i
On 2021-12-08 15:12, Sascha Hauer wrote:
Signed-off-by: Sascha Hauer
---
.../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 6 ++
1 file changed, 6 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
b/Documentation/devicetree/
On 2021-12-08 11:16 a.m., Yann Dirson wrote:
Hi Rodrigo,
On 2021-12-07 2:49 p.m., Yann Dirson wrote:
On Thu, Dec 02, 2021 at 11:01:32AM -0500, Rodrigo Siqueira wrote:
In the DC driver, we have multiple acronyms that are not obvious
most of
the time; the same idea is valid for amdgpu. Thi
Hi Rodrigo,
> On 2021-12-07 2:49 p.m., Yann Dirson wrote:
> >
> >> On Thu, Dec 02, 2021 at 11:01:32AM -0500, Rodrigo Siqueira wrote:
> >>> In the DC driver, we have multiple acronyms that are not obvious
> >>> most of
> >>> the time; the same idea is valid for amdgpu. This commit
> >>> introduces
Hi Matt and Ram,
On Wed, Dec 08, 2021 at 07:46:13PM +0530, Ramalingam C wrote:
> From: Matthew Auld
>
> If the device needs 64K minimum GTT pages for device local-memory,
> like on XEHPSDV, then we need to fail the allocation if we can't
> meet it, instead of falling back to 4K pages, otherwise
Hi Ram and Matt,
> On some platforms the hw has dropped support for 4K GTT pages when
> dealing with LMEM, and due to the design of 64K GTT pages in the hw, we
> can only mark the *entire* page-table as operating in 64K GTT mode,
> since the enable bit is still on the pde, and not the pte. And sin
Hi Ram,
On Wed, Dec 08, 2021 at 07:46:11PM +0530, Ramalingam C wrote:
> From: Matthew Auld
>
> LMEM should be allocated at 64K granularity, since 4K page support will
> eventually be dropped for LMEM when using the PPGTT.
>
> Signed-off-by: Matthew Auld
> Signed-off-by: Stuart Summers
> Signe
Hi Ram,
Reviewed-by: Andi Shyti
but just two notes on the patchstyle, no need to resend:
1. would be nice to have [PATCH v2...] otherwise it's difficult
to see if I'm reading the correct version. (I don't see the
difficulty 'git format-patch -v 2...')
> Add a new platform flag, has_64k_p
From: Matthew Auld
Conditionally allocate LMEM with 64K granularity, since 4K page support
for LMEM will be dropped on some platforms when using the PPGTT.
v2:
updated commit msg [Thomas]
Signed-off-by: Matthew Auld
Signed-off-by: Stuart Summers
Signed-off-by: Ramalingam C
Cc: Joonas Lahti
On 2021-12-07 2:49 p.m., Yann Dirson wrote:
On Thu, Dec 02, 2021 at 11:01:32AM -0500, Rodrigo Siqueira wrote:
In the DC driver, we have multiple acronyms that are not obvious
most of
the time; the same idea is valid for amdgpu. This commit introduces
a DC
and amdgpu glossary in order to mak
On 2021-12-08 at 17:23:26 +0200, Andi Shyti wrote:
> Hi Ram,
>
> > +static int intel_memory_region_memtest(struct intel_memory_region *mem,
> > + void *caller)
> > +{
> > + struct drm_i915_private *i915 = mem->i915;
> > + int err = 0;
> > +
> > + if (!mem->io
From: Chris Wilson
This extends the previous sanitychecking of device memory to read/write
all the memory on the device during the device probe, ala memtest86,
as an optional module parameter: i915.memtest=1. This is not expected to
be fast, but a reasonably thorough verfification that the device
From: Chris Wilson
As we setup the memory regions for the device, give each a quick test to
verify that we can read and write to the full iomem range. This ensures
that our physical addressing for the device's memory is correct, and
some reassurance that the memory is functional.
v2: wrapper for
From: Chris Wilson
Remove the portion of stolen memory reserved for private use from driver
access.
Signed-off-by: Chris Wilson
cc: Matthew Auld
Signed-off-by: Ramalingam C
Reviewed-by: Matthew Auld
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 3 +++
1 file chan
Changes for introducing the quick test on the device memory range and
also a test of detailed validation for each addr of the range with read
and write.
Detailed testing is optionally enabled with a modparam i915.memtest=1
And third patch fixes the driver accessible stolen memory.
v2: Adding a w
Hi Ram and Chris,
> param(char *, guc_firmware_path, NULL, 0400) \
> param(char *, huc_firmware_path, NULL, 0400) \
> param(char *, dmc_firmware_path, NULL, 0400) \
> + param(bool, memtest, false, 0400) \
this partially answers my previous question...
[...]
> - if (IS_
Hi Ram,
> +static int intel_memory_region_memtest(struct intel_memory_region *mem,
> +void *caller)
> +{
> + struct drm_i915_private *i915 = mem->i915;
> + int err = 0;
> +
> + if (!mem->io_start)
> + return 0;
> +
> + if (IS_ENABLED(
Hi Ram,
On Wed, Dec 08, 2021 at 08:27:58PM +0530, Ramalingam C wrote:
> From: Chris Wilson
>
> Remove the portion of stolen memory reserved for private use from driver
> access.
>
> Signed-off-by: Chris Wilson
> cc: Matthew Auld
> Signed-off-by: Ramalingam C
> Reviewed-by: Matthew Auld
Rev
On Wed, Dec 08, 2021 at 08:27:58PM +0530, Ramalingam C wrote:
> From: Chris Wilson
>
> Remove the portion of stolen memory reserved for private use from driver
> access.
>
> Signed-off-by: Chris Wilson
> cc: Matthew Auld
> Signed-off-by: Ramalingam C
> Reviewed-by: Matthew Auld
> ---
> driv
"vpll" is a misnomer. A clock input to a device should be named after
the usage in the device, not after the clock that drives it. On the
rk3568 the same clock is driven by the HPLL.
To fix that, this patch renames the vpll clock to ref clock. The clock
name "vpll" is left for compatibility to old
This is the second round of the vop2 series. There are still some issues open,
but I thought it's about time to let people see and test it. I integrated the
review feedback I got from v1. Other changes include:
All framesync waiting is gone from the driver which makes it more straight
forward. To
None of the upstream device tree files has a "unwedge" pinctrl
specified. Make it optional.
Signed-off-by: Sascha Hauer
---
.../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/roc
From: Michael Riesch
Enable the RK356x Video Output Processor (VOP) 2 on the Pine64
Quartz64 Model A.
Signed-off-by: Michael Riesch
Signed-off-by: Sascha Hauer
---
.../boot/dts/rockchip/rk3566-quartz64-a.dts | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm64
Add a new dw_hdmi_plat_data struct and new compatible for rk3568.
Signed-off-by: Benjamin Gaignard
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 31 +
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
The binding specifies the clock order to "cec", "grf", "vpll". Reorder
the clocks accordingly.
Signed-off-by: Sascha Hauer
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64
With upcoming VOP2 support VOP won't be the only choice anymore, so make
the VOP driver optional.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/rockchip/Kconfig| 8
drivers/gpu/drm/rockchip/Makefile | 3 ++-
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
3 f
This enabled the VOP2 display controller along with hdmi and the
required port routes which is enough to get a picture out of the
hdmi port of the board.
Signed-off-by: Sascha Hauer
---
.../boot/dts/rockchip/rk3568-evb1-v10.dts | 31 +++
1 file changed, 31 insertions(+)
diff
From: Benjamin Gaignard
Define a new compatible for rk3568 HDMI.
This version of HDMI hardware block needs two new clocks hclk_vio and hclk
to provide phy reference clocks.
Signed-off-by: Benjamin Gaignard
Reviewed-by: Rob Herring
Link:
https://lore.kernel.org/r/20210707120323.401785-2-benjam
The VOP2 is found on newer Rockchip SoCs like the rk3568 or the rk3566.
The binding differs slightly from the existing VOP binding, so add a new
binding file for it.
Signed-off-by: Sascha Hauer
---
.../display/rockchip/rockchip-vop2.yaml | 118 ++
1 file changed, 118 insert
Add support for the HDMI port found on RK3568.
Signed-off-by: Sascha Hauer
---
arch/arm64/boot/dts/rockchip/rk356x.dtsi | 26 +++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
b/arch/arm64/boot/dts/rockchip/rk356x.dts
The VOP2 is the display output controller on the RK3568. Add the node
for it to the dtsi file along with the required display-subsystem node
and the iommu node.
Signed-off-by: Sascha Hauer
---
arch/arm64/boot/dts/rockchip/rk3566.dtsi | 4 ++
arch/arm64/boot/dts/rockchip/rk3568.dtsi | 4 ++
arc
On the rk3568 we have this (simplified) situation:
.. .-..-.
-| hpll |--.--| /n ||dclk_vop0|-
`´ | `-´`-´
| .-..-.
`--| /m ||dclk_vop1|-
| `-´`-´
From: Andy Yan
The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568.
It replaces the VOP unit found in the older Rockchip SoCs.
This driver has been derived from the downstream Rockchip Kernel and
heavily modified:
- All nonstandard DRM properties have been removed
- dropped str
The driver returns an error when devm_phy_optional_get() fails leaving
the previously enabled clock turned on. Change order and enable the
clock only after the phy has been acquired.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 14 +++---
1 file changed,
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
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 41 +++--
1
Signed-off-by: Sascha Hauer
---
.../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 6 ++
1 file changed, 6 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.ya
"vpll" is a misnomer. A clock input to a device should be named after
the usage in the device, not after the clock that drives it. On the
rk3568 the same clock is driven by the HPLL.
To fix that, this patch renames the vpll clock to ref clock. The clock
name "vpll" is left for compatibility to old
Add a device node to drm_encoder which corresponds with the port node
in the DT description of the encoder. This allows drivers to find the
of_graph link between a crtc and an encoder.
Signed-off-by: Sascha Hauer
---
include/drm/drm_encoder.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a
On 12/8/21 15:34, Matthew Auld wrote:
On Wed, 8 Dec 2021 at 14:16, Ramalingam C wrote:
From: Matthew Auld
LMEM should be allocated at 64K granularity, since 4K page support will
eventually be dropped for LMEM when using the PPGTT.
s/will eventually be dropped/has been dropped/ as per Thoma
From: Chris Wilson
This extends the previous sanitychecking of device memory to read/write
all the memory on the device during the device probe, ala memtest86,
as an optional module parameter: i915.memtest=1. This is not expected to
be fast, but a reasonably thorough verfification that the device
From: Chris Wilson
As we setup the memory regions for the device, give each a quick test to
verify that we can read and write to the full iomem range. This ensures
that our physical addressing for the device's memory is correct, and
some reassurance that the memory is functional.
v2: wrapper for
From: Chris Wilson
Remove the portion of stolen memory reserved for private use from driver
access.
Signed-off-by: Chris Wilson
cc: Matthew Auld
Signed-off-by: Ramalingam C
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 3 +++
1 file changed, 3 insertions(+)
dif
Changes for introducing the quick test on the device memory range and
also a test of detailed validation for each addr of the range with read
and write.
Detailed testing is optionally enabled with a modparam i915.memtest=1
And third patch fixes the driver accessible stolen memory.
v2: Adding a w
On Wed, 8 Dec 2021 at 14:16, Ramalingam C wrote:
>
> From: Matthew Auld
>
> LMEM should be allocated at 64K granularity, since 4K page support will
> eventually be dropped for LMEM when using the PPGTT.
s/will eventually be dropped/has been dropped/ as per Thomas' suggestion.
>
> Signed-off-by:
From: Matthew Auld
If the device needs 64K minimum GTT pages for device local-memory,
like on XEHPSDV, then we need to fail the allocation if we can't
meet it, instead of falling back to 4K pages, otherwise we can't
safely support the insertion of device local-memory pages for
this vm, since the
From: Matthew Auld
On some platforms the hw has dropped support for 4K GTT pages when
dealing with LMEM, and due to the design of 64K GTT pages in the hw, we
can only mark the *entire* page-table as operating in 64K GTT mode,
since the enable bit is still on the pde, and not the pte. And since we
From: Matthew Auld
LMEM should be allocated at 64K granularity, since 4K page support will
eventually be dropped for LMEM when using the PPGTT.
Signed-off-by: Matthew Auld
Signed-off-by: Stuart Summers
Signed-off-by: Ramalingam C
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Reviewed-by: Lucas De Ma
From: Stuart Summers
Add a new platform flag, has_64k_pages, to mark the requirement of 64K
GTT page sizes or larger for device local memory access.
Also implies that we require or at least support the compact PT layout
for the ppGTT when using 64K GTT pages.
v2: More explanation for the flag [
Preparational patches for 64k page support.
Matthew Auld (3):
drm/i915/xehpsdv: set min page-size to 64K
drm/i915/gtt/xehpsdv: move scratch page to system memory
drm/i915: enforce min page size for scratch
Stuart Summers (1):
drm/i915: Add has_64k_pages flag
drivers/gpu/drm/i915/gem/i91
On Wed, Dec 08, 2021 at 10:31:58PM +1100, Alistair Popple wrote:
> On Tuesday, 7 December 2021 5:52:43 AM AEDT Alex Sierra wrote:
> > Avoid long term pinning for Coherent device type pages. This could
> > interfere with their own device memory manager.
> > If caller tries to get user device coheren
On 08-12-2021 13:07, Matthew Auld wrote:
> On Mon, 29 Nov 2021 at 13:58, Maarten Lankhorst
> wrote:
>> 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 stil
On 12/7/21 17:51, Ramalingam C wrote:
From: Matthew Auld
If the device needs 64K minimum GTT pages for device local-memory,
like on XEHPSDV, then we need to fail the allocation if we can't
meet it, instead of falling back to 4K pages, otherwise we can't
safely support the insertion of device
On 07-12-2021 12:01, Matthew Auld wrote:
> On Mon, 29 Nov 2021 at 13:57, Maarten Lankhorst
> wrote:
>> Now that freeing objects takes the object lock when destroying the
>> backing pages, we can confidently take the object lock even for dead
>> objects.
> That looks to be a future patch, at least
On 12/7/21 17:51, Ramalingam C wrote:
From: Matthew Auld
On some platforms the hw has dropped support for 4K GTT pages when
dealing with LMEM, and due to the design of 64K GTT pages in the hw, we
can only mark the *entire* page-table as operating in 64K GTT mode,
since the enable bit is still
On 12/8/21 13:59, Matthew Auld wrote:
On Wed, 8 Dec 2021 at 12:43, Thomas Hellström (Intel)
wrote:
Hi,
On 12/7/21 17:51, Ramalingam C wrote:
From: Stuart Summers
Add a new platform flag, has_64k_pages, for platforms supporting
base page sizes of 64k.
Signed-off-by: Stuart Summers
Signed
On 07-12-2021 11:44, Matthew Auld wrote:
> On Mon, 29 Nov 2021 at 13:57, Maarten Lankhorst
> wrote:
>> 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 n
On Wed, 08 Dec 2021, Ville Syrjälä wrote:
> On Wed, Dec 08, 2021 at 07:46:19AM +, cgel@gmail.com wrote:
>> From: luo penghao
>>
>> This value will be overwritten by the following if statement, even
>> if the if is not executed, the value will not be used
>>
>> The clang_analyzer complai
On Wed, Dec 08, 2021 at 07:46:19AM +, cgel@gmail.com wrote:
> From: luo penghao
>
> This value will be overwritten by the following if statement, even
> if the if is not executed, the value will not be used
>
> The clang_analyzer complains as follows:
>
> Value stored to 'port_mask' is
On Wed, 8 Dec 2021 at 12:43, Thomas Hellström (Intel)
wrote:
>
> Hi,
>
> On 12/7/21 17:51, Ramalingam C wrote:
> > From: Stuart Summers
> >
> > Add a new platform flag, has_64k_pages, for platforms supporting
> > base page sizes of 64k.
> >
> > Signed-off-by: Stuart Summers
> > Signed-off-by: Ra
On 12/7/21 17:51, Ramalingam C wrote:
From: Matthew Auld
LMEM should be allocated at 64K granularity, since 4K page support will
eventually be dropped for LMEM when using the PPGTT.
Signed-off-by: Matthew Auld
Signed-off-by: Stuart Summers
Signed-off-by: Ramalingam C
Cc: Joonas Lahtinen
Hi,
On 12/7/21 17:51, Ramalingam C wrote:
From: Stuart Summers
Add a new platform flag, has_64k_pages, for platforms supporting
base page sizes of 64k.
Signed-off-by: Stuart Summers
Signed-off-by: Ramalingam C
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_drv.h | 2
Hi Kieran,
On Wed, Dec 8, 2021 at 12:57 PM Kieran Bingham
wrote:
> Quoting Geert Uytterhoeven (2021-12-08 10:30:53)
> > Use the dev_err_probe() helper, instead of open-coding the same
> > operation.
> >
> > Signed-off-by: Geert Uytterhoeven
> > ---
> > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 5
On Mon, 29 Nov 2021 at 13:58, Maarten Lankhorst
wrote:
>
> 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_g
On Wed, 8 Dec 2021 at 11:49, Matthew Auld
wrote:
>
> On Mon, 29 Nov 2021 at 13:58, Maarten Lankhorst
> wrote:
> >
> > 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 pinni
Quoting Geert Uytterhoeven (2021-12-08 10:30:53)
> Use the dev_err_probe() helper, instead of open-coding the same
> operation.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drive
On Mon, 29 Nov 2021 at 13:58, Maarten Lankhorst
wrote:
>
> 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
On Tuesday, 7 December 2021 5:52:43 AM AEDT Alex Sierra wrote:
> Avoid long term pinning for Coherent device type pages. This could
> interfere with their own device memory manager.
> If caller tries to get user device coherent pages with PIN_LONGTERM flag
> set, those pages will be migrated back t
On Fri, 03 Dec 2021, Kees Cook wrote:
> The link_status array was not large enough to read the Adjust Request
> Post Cursor2 register. Adjust the size to include it. Found with a
> -Warray-bounds build:
>
> drivers/gpu/drm/drm_dp_helper.c: In function
> 'drm_dp_get_adjust_request_post_cursor':
>
On 2021-12-08 at 11:12:07 +, Matthew Auld wrote:
> On 08/12/2021 10:20, Ramalingam C wrote:
> > From: Chris Wilson
> >
> > As we setup the memory regions for the device, give each a quick test to
> > verify that we can read and write to the full iomem range. This ensures
> > that our physical
On 08/12/2021 10:20, Ramalingam C wrote:
From: Chris Wilson
As we setup the memory regions for the device, give each a quick test to
verify that we can read and write to the full iomem range. This ensures
that our physical addressing for the device's memory is correct, and
some reassurance that
Use the dev_err_probe() helper, instead of open-coding the same
operation.
Signed-off-by: Geert Uytterhoeven
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du
The Renesas RZ/G2{L, LC} SoC (a.k.a R9A07G044) has a Bifrost Mali-G31 GPU,
add a compatible string for it.
Signed-off-by: Biju Das
Reviewed-by: Lad Prabhakar
---
v2->v3:
* Moved optional clock-names and reset-names to SoC-specific conditional
schemas.
* minimum number of reset for the generic
RZ/G2L SoC embeds Mali-G31 bifrost GPU.
This patch series aims to add support for the same
It is tested with latest drm-misc-next + mesa 21.3.0 +
out of tree patch for (du + DSI) +
platform specific mesa configuration for RZ/G2L.
Tested the kmscube application.
test logs:-
root@smarc-rzg2l:~#
Hi
Am 07.12.21 um 10:24 schrieb Thomas Zimmermann:
Hi
Am 07.12.21 um 09:55 schrieb Dan Carpenter:
I appologize. This thread has been really frustrating. I got mixed up
because I recently sent patches for ingenic and vc4. Also we are
working against different trees so maybe that is part of t
From: Chris Wilson
Remove the portion of stolen memory reserved for private use from driver
access.
Signed-off-by: Chris Wilson
cc: Matthew Auld
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i
1 - 100 of 119 matches
Mail list logo
