Hi Ramalingam,
On Wed, Oct 27, 2021 at 5:22 PM Ramalingam C wrote:
>
> From: Matt Roper
>
> DG2 unifies render compression and media compression into a single
> format for the first time. The programming and buffer layout is
> supposed to match compression on older gen12 platforms, but the
> ac
On 06/12/2021 13:14, Laurent Pinchart wrote:
Hi Arnd,
Thank you for the patch.
On Sun, Dec 05, 2021 at 02:15:56PM +0100, Arnd Bergmann wrote:
From: Arnd Bergmann
Using the SET_RUNTIME_PM_OPS() macro causes a warning about the
referenced functions when they are marked static but not __maybe_u
When updating the error capture code and introducing vma snapshots,
we introduced code to hold the vma in memory while capturing it,
calling i915_active_acquire_if_busy(). Now that function isn't relevant
for perma-pinned vmas and caused important vmas to be dropped from the
coredump. Like for exam
On 07/12/2021 17: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() function will
fail if GuC could not be loaded.
Si
On 07/12/2021 14:05, Matthew Auld wrote:
On 07/12/2021 13:10, Tvrtko Ursulin wrote:
On 18/10/2021 10:10, Matthew Auld wrote:
For cached objects we can allocate our pages directly in shmem. This
should make it possible(in a later patch) to utilise the existing
i915-gem shrinker code for such
On 12/8/21 09:30, Tvrtko Ursulin wrote:
...
Apart from the code organisation questions, on the practical level -
do you need writeback from the TTM backend or while I am proposing
to remove it from the "legacy" paths, I can propose removing it from
the TTM flow as well?
Yeah, if that is
On Wed, 08 Dec 2021, cgel@gmail.com wrote:
> From: luo penghao
>
> The existence of offset is meaningless, so it should be deleted.
>
> The clang_analyzer complains as follows:
>
> Value stored to 'offset' is never read
>
> Reported-by: Zeal Robot
> Signed-off-by: luo penghao
I've said the
On 18/11/2021 16:59, Sebastian Andrzej Siewior wrote:
This is a revert of commits
d67739268cf0e ("drm/i915/gt: Mark up the nested engine-pm timeline lock as
irqsafe")
6c69a45445af9 ("drm/i915/gt: Mark context->active_count as protected by
timeline->mutex")
6dcb85a0ad99 ("drm/i915: H
On 08/12/2021 08:39, Thomas Hellström wrote:
On 12/8/21 09:30, Tvrtko Ursulin wrote:
...
Apart from the code organisation questions, on the practical level -
do you need writeback from the TTM backend or while I am proposing
to remove it from the "legacy" paths, I can propose removing it
Hi,
> Subject: RE: [PATCH v2 1/3] dt-bindings: gpu: mali-bifrost: Document
> RZ/G2L support
>
> Hi Robin,
>
> Thanks for the feedback.
>
> > Subject: Re: [PATCH v2 1/3] dt-bindings: gpu: mali-bifrost: Document
> > RZ/G2L support
> >
> > On 2021-12-06 15:00, Biju Das wrote:
> > > The Renesas RZ/
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 it returns a NULL fence. Some callers are
not prepared to handle this, like the syncobj transfer f
On 12/8/21 10:24, Tvrtko Ursulin wrote:
On 08/12/2021 08:39, Thomas Hellström wrote:
On 12/8/21 09:30, Tvrtko Ursulin wrote:
...
Apart from the code organisation questions, on the practical level
- do you need writeback from the TTM backend or while I am
proposing to remove it from the
https://bugzilla.kernel.org/show_bug.cgi?id=53391
Stijn Tintel (stijn+b...@linux-ipv6.be) changed:
What|Removed |Added
Status|NEW |RESOLVED
On 06/12/2021 04:29, Srivatsa, Anusha wrote:
-Original Message-
From: Tvrtko Ursulin
Sent: Friday, December 3, 2021 2:57 PM
To: Srivatsa, Anusha ; intel-
g...@lists.freedesktop.org
Cc: x...@kernel.org; dri-devel@lists.freedesktop.org; Ingo Molnar
; Borislav Petkov ; Dave Hansen
; Joona
https://bugzilla.kernel.org/show_bug.cgi?id=205185
Stijn Tintel (stijn+b...@linux-ipv6.be) changed:
What|Removed |Added
Status|NEW |RESOLVED
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 it returns a NULL fence. Some callers are
not prepare
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.
Signed-off-by:
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
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.
Chris Wilson (
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
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
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:~#
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
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
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
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 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 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 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
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 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
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
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
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
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
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 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, 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 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 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 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 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
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 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 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
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
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 [
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: 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
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
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:
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
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
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
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
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
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
"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
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
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
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,
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
On the rk3568 we have this (simplified) situation:
.. .-..-.
-| hpll |--.--| /n ||dclk_vop0|-
`´ | `-´`-´
| .-..-.
`--| /m ||dclk_vop1|-
| `-´`-´
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
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 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
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
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
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
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
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
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
"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
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
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
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 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_
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
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
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
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
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
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
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
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
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 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 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 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
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
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/
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
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|-
> `´ | `-´`-´
> | .-..-.
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
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 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 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,
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
1 - 100 of 119 matches
Mail list logo
