On Tue, 20 Sep 2022 01:06:52 -0700, Jani Nikula wrote:
>
> On Mon, 19 Sep 2022, "Dixit, Ashutosh" wrote:
> > On Mon, 19 Sep 2022 05:13:18 -0700, Jani Nikula wrote:
> >>
> >> On Mon, 19 Sep 2022, Badal Nilawar wrote:
> >> > For MTL SAMedia updated relevant functions and places in the code to get
On Mon, 19 Sep 2022 09:49:07 -0700, Andi Shyti wrote:
>
> Hi Badal,
Hi Andi,
Badal is out for a bit so I am sending out this version.
> On Mon, Sep 19, 2022 at 05:29:05PM +0530, Badal Nilawar wrote:
> > Updated the CAGF functions to get actual resolved frequency of
> > 3D and SAMedia
>
> can
On Mon, 19 Sep 2022 15:49:17 -0700, Matt Roper wrote:
>
> On Mon, Sep 19, 2022 at 03:46:47PM -0700, Matt Roper wrote:
> > On Mon, Sep 19, 2022 at 05:29:05PM +0530, Badal Nilawar wrote:
> > > Updated the CAGF functions to get actual resolved frequency of
> > > 3D and SAMedia
> > >
> > > Bspec:
From: Badal Nilawar
Add support for C6 residency and C state type for MTL SAMedia. Also add
mtl_drpc.
v2: Fixed review comments (Ashutosh)
v3: Sort registers and fix whitespace errors in intel_gt_regs.h (Matt R)
Remove MTL_CC_SHIFT (Ashutosh)
Adapt to RC6 residency register code
From: Badal Nilawar
Update CAGF functions for MTL to get actual resolved frequency of 3D and
SAMedia.
v2: Update MTL_MIRROR_TARGET_WP1 position/formatting (MattR)
Move MTL branches in cagf functions to top (MattR)
Fix commit message (Andi)
Bspec: 66300
Signed-off-by: Ashutosh Dixit
This series includes the code changes to get CAGF, RC State and C6
Residency of MTL.
v2: Included "Use GEN12 RPSTAT register" patch
v3:
- Rebased
- Dropped "Use GEN12 RPSTAT register" patch from this series
going to send separate series for it
v4:
- Included "drm/i915/gt: Change RC6
Previously RC6 residency functions directly accepted RC6 residency register
MMIO offsets (there are four RC6 residency registers). This worked but
required an assumption on the residency register layout so was not future
proof.
Therefore change RC6 residency functions to accept register ID's
On 10/13/2022 13:32, Daniele Ceraolo Spurio wrote:
We're observing sporadic HuC delayed load timeouts in CI, due to mei_pxp
binding completing later than we expected. HuC is still loaded when the
bind occurs, but in the meantime i915 has started allowing submission to
the VCS engines even if HuC
On Wed, Oct 12, 2022 at 05:03:32PM -0700, Daniele Ceraolo Spurio wrote:
> The render and media GuCs share the same interrupt enable register, so
> we can no longer disable interrupts when we disable communication for
> one of the GuCs as this would impact the other GuC. Instead, we keep the
>
The bspec was just updated with a correction to the forcewake domain
required when accessing registers in the CCS engine ranges (0x1a000 -
0x1 and 0x26000 - 0x27fff) on PVC; these ranges require a wake on
the RENDER domain, not the GT domain.
Bspec: 67609
Signed-off-by: Matt Roper
---
In case mipi_dsi_attach() fails, call drm_panel_remove() to avoid memory leak.
Fixes: 849b2e3ff9698 ("drm/panel: Add Sitronix ST7701 panel driver")
Signed-off-by: Marek Vasut
---
Cc: Guido Günther
Cc: Jagan Teki
Cc: Laurent Pinchart
Cc: Linus Walleij
Cc: Sam Ravnborg
Cc: Thierry Reding
---
There are two command register files, CMD1 and CMD2, where only the CMD2
contains additional register sub-files BK0..3 . Pull the register file
selection call into separate function instead of duplicating it all over
the driver. The CMD2BK2 file is undocumented in datasheet, and is used
for BIST.
MTL's graphics IP (Xe_LPG) once again changes the multicast register
types and steering details. Key changes from past platforms:
* The number of instances of some MCR types (NODE, OAAL2, and GAM) vary
according to the MTL subplatform and cannot be read from fuse
registers. However
MTL's media IP (Xe_LPM+) only has a single type of steering ("OAADDRM")
which selects between media slice 0 and media slice 1. We'll always
steer to media slice 0 unless it is fused off (which is the case when
VD0, VE0, and SFC0 are all reported as unavailable).
Bspec: 67789
Signed-off-by: Matt
Rather than treating multicast registers as 'i915_reg_t' let's define
them as a completely new type. This will allow the compiler to help us
make sure we're using multicast-aware functions to operate on multicast
registers.
This plan does break down a bit in places where we're just maintaining
Let's be more explicit about which of our workarounds are updating MCR
registers.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 433 +++---
.../gpu/drm/i915/gt/intel_workarounds_types.h | 4 +-
2 files changed, 263 insertions(+), 174 deletions(-)
On Xe_HP the fault registers are now in a multicast register range.
However as part of the GAM these registers follow special rules and we
need only read from the "primary" GAM's instance to get the information
we need. So a single intel_gt_mcr_read_any() (which will automatically
steer to the
Xe_HP has some MCR registers that need to be polled for completion of
operations like TLB invalidation. Those registers are in the GAM range,
which rolls up the status from each unit into the 'primary' instance's
value. This makes it useful to have a dedicated 'wait for register'
function that
Let's drop a few register definitions that are unused anywhere in the
driver today. Since the referenced offsets are part of what is now
considered a multicast register region, the current definitions would
not be correct for use on any future platform.
Signed-off-by: Matt Roper
---
There are cases where we wish to read from any non-terminated MCR
register instance (or the primary instance in the case of GAM ranges),
clear/set some bits, and then write the value back out to the register
in a multicast manner. Adding a "multicast RMW" will avoid the need to
open-code this.
Rather than using the same _MMIO() macro to define MCR registers as
singleton registers, let's use a new MCR_REG() macro to make it clear
that these registers are special and should be handled accordingly. For
now MCR_REG() will still generate an i915_reg_t with the given offset,
but we'll change
Rather than relying on the implicit behavior of intel_uncore_*()
functions, let's always use the intel_gt_mcr_*() functions to operate on
multicast/replicated registers.
v2:
- Add TLB invalidation registers
v3:
- Switch more uncore operations in mmio_invalidate_full() to MCR
operations for
MCR registers can be placed on the GuC's save/restore list, but at the
moment they are always handled in a multicast manner (i.e., the GuC
reads one instance to save the value and then does a multicast write to
restore that single value to all instances). In the future the GuC will
probably give
Gen8 was the first time our hardware had multicast registers (or at
least the first time the multicast nature was exposed and MMIO accesses
could be steered). There are some registers that transitioned from
singleton behavior to multicast during the gen7 -> gen8 transition;
let's duplicate the
Starting in Xe_HP, several registers our driver works with have been
converted from singleton registers into replicated registers with
multicast behavior. Although the registers are still located at the
same MMIO offsets as on previous platforms, let's duplicate the register
definitions in
We have a few registers that have existed for several hardware
generations, but are only used by the driver on Xe_HP and beyond. In
cases where the Xe_HP version of the register is now replicated and uses
multicast behavior, but earlier generations were singleton, let's change
the register prefix
On Fri, Oct 14, 2022 at 09:32:55PM +0530, Balasubramani Vivekanandan wrote:
> On 30.09.2022 17:45, Matt Roper wrote:
> > MTL once again changes the multicast register types and steering
> > details. Key changes from past platforms:
> > * The number of instances of some MCR types (NODE, OAAL2,
On Tue, Oct 11, 2022 at 08:38:51AM -0700, Radhakrishna Sripada wrote:
Platforms prior to MTL do not have a separate media and graphics version.
On platforms where GMD id is not supported, reuse the graphics ip version,
release info for media.
The rest of the IP graphics, display versions would
On Tue, 04 Oct 2022 14:09:07 +0200, Krzysztof Kozlowski wrote:
> For devices connectable by SPI bus (e.g. already using
> "spi-max-frequency" property), reference the "spi-peripheral-props.yaml"
> schema to allow using all SPI device properties, even these which device
> bindings author did not
There's no reason to have "status" properties in examples. "okay" is the
default, and "disabled" turns off some schema checks ('required'
specifically).
A meta-schema check for this is pending, so hopefully the last time to
fix these.
Fix the indentation in intel,phy-thunderbay-emmc while we're
On 10/13/22 02:13, Maxime Ripard wrote:
The firmware allows to query for its clocks the operating range of a
given clock. We'll need this for some drivers (KMS, in particular) to
infer the state of some configuration options, so let's create a
function to do so.
Acked-by: Stephen Boyd
On 10/13/22 02:13, Maxime Ripard wrote:
We'll need the clock IDs in more drivers than just the clock driver from
now on, so let's move them in the firmware header.
Signed-off-by: Maxime Ripard
Reviewed-by: Florian Fainelli
--
Florian
On 10/13/22 02:13, Maxime Ripard wrote:
A significant number of RaspberryPi drivers using the firmware don't
have a phandle to it, so end up scanning the device tree to find a node
with the firmware compatible.
That code is duplicated everywhere, so let's introduce a helper instead.
Quoting Maxime Ripard (2022-10-13 02:13:09)
> We'll need the clock IDs in more drivers than just the clock driver from
> now on, so let's move them in the firmware header.
>
> Signed-off-by: Maxime Ripard
> ---
Acked-by: Stephen Boyd
Hi Xiaoyong!
I have tested this and arrived at the same Fluster score:
173/239 - AOM
11/13 - Chromium 8bit
Reviewed-by: Daniel Almeida
Tested-by: Daniel Almeida
On Fri, Oct 14, 2022 at 8:22 AM Nathan Chancellor wrote:
>
> After commit 8799c0be89eb ("drm/amd/display: Fix vblank refcount in vrr
> transition"), a build with CONFIG_DEBUG_FS=n is broken due to a
> misplaced brace, along the lines of:
Thanks, applied.
Linus
On 14/10/2022 17:51, Jordan Justen wrote:
On 2022-10-14 03:58:12, Matthew Auld wrote:
On 14/10/2022 08:20, Jordan Justen wrote:
Acked-by: Jordan Justen
Thanks. Can I take that as ack for merging the series from Mesa POV? I
think Lionel was going to test this, but I think keeps getting
On 10/14/22 17:55, Marek Vasut wrote:
On 10/14/22 15:42, Yannick FERTRE wrote:
Hi Marek,
Hello Yannick,
The genmask of regsiter SSCR, BPCR & others were setted accordly to
the chipset stm32f4.
So that means:
F4 -> 2048x2048 framebuffer
H7/MP1 -> 4096x4096 framebuffer
?
Worse
F4 is
On Mon, Sep 12, 2022 at 12:29 AM Tomeu Vizoso
wrote:
>
> And use it to store expectations about what the DRM drivers are
> supposed to pass in the IGT test suite.
>
> Also include a configuration file that points to the out-of-tree CI
> scripts.
>
> By storing the test expectations along the code
On 2022-10-14 03:58:12, Matthew Auld wrote:
> On 14/10/2022 08:20, Jordan Justen wrote:
> > Acked-by: Jordan Justen
>
> Thanks. Can I take that as ack for merging the series from Mesa POV? I
> think Lionel was going to test this, but I think keeps getting swamped
> with other stuff. We kind of
On 30.09.2022 20:08, Konrad Dybcio wrote:
> Add support for the Sony TD4353 JDI 2160x1080 display panel used in
> some Sony Xperia XZ2 and XZ2 Compact smartphones. Due to the specifics
> of smartphone manufacturing, it is impossible to retrieve a better name
> for this panel.
>
> This revision
On 14/10/2022 11:15, Guillaume Ranquet wrote:
> Add mt8195 SoC bindings for hdmi and hdmi-ddc
>
> Signed-off-by: Guillaume Ranquet
> ---
> .../bindings/display/mediatek/mediatek,hdmi.yaml | 67
> +-
> .../display/mediatek/mediatek,mt8195-hdmi-ddc.yaml | 51
On 30.09.2022 17:45, Matt Roper wrote:
> MTL once again changes the multicast register types and steering
> details. Key changes from past platforms:
> * The number of instances of some MCR types (NODE, OAAL2, and GAM) vary
>according to the MTL subplatform and cannot be read from fuse
>
On 10/14/22 15:42, Yannick FERTRE wrote:
Hi Marek,
Hello Yannick,
The genmask of regsiter SSCR, BPCR & others were setted accordly to the
chipset stm32f4.
So that means:
F4 -> 2048x2048 framebuffer
H7/MP1 -> 4096x4096 framebuffer
?
We should then also update
Currently, if we encounter unimplemented functions, it is difficult to
tell what caused them just by looking at dmesg and that is compounded by
the fact that it is often hard to reproduce said issues. So, to have
access to more detailed debugging information, add a WARN() to
dal_irq_service_ack()
After commit 8799c0be89eb ("drm/amd/display: Fix vblank refcount in vrr
transition"), a build with CONFIG_DEBUG_FS=n is broken due to a
misplaced brace, along the lines of:
In file included from
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_trace.h:39,
from
Add dt-binding documentation of dpi for MediaTek MT8195 SoC.
Acked-by: Krzysztof Kozlowski
Signed-off-by: Guillaume Ranquet
---
Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
Add basic support for the mediatek hdmi phy on MT8195 SoC
Signed-off-by: Guillaume Ranquet
---
drivers/phy/mediatek/Makefile | 1 +
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c | 546 +
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.h | 131 +++
Add the DPI1 hdmi path support in mtk dpi driver
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 143 ++--
drivers/gpu/drm/mediatek/mtk_dpi_regs.h | 5 ++
2 files changed, 141 insertions(+), 7 deletions(-)
diff --git
Adds hdmi and hdmi-ddc support for v2 IP.
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/Makefile |2 +
drivers/gpu/drm/mediatek/mtk_hdmi_common.c | 14 +
drivers/gpu/drm/mediatek/mtk_hdmi_common.h |1 +
drivers/gpu/drm/mediatek/mtk_hdmi_ddc_v2.c | 367
Add HDMI audio support for v2
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_hdmi_common.c | 1 +
drivers/gpu/drm/mediatek/mtk_hdmi_ddc_v2.c | 2 +-
drivers/gpu/drm/mediatek/mtk_hdmi_v2.c | 213 +
drivers/gpu/drm/mediatek/mtk_hdmi_v2.h
Make cec device optional in order to support newer versions of the
hdmi IP which doesn't require it
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_hdmi.c| 8 +++--
drivers/gpu/drm/mediatek/mtk_hdmi_common.c | 54 --
Create a common "framework" that can be used to add support for
different hdmi IPs within the mediatek range of products.
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/Makefile | 3 +-
drivers/gpu/drm/mediatek/mtk_hdmi.c| 620 ++---
Add a flag to indicate support for frame colorimetry.
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_hdmi_common.c | 11 +++
drivers/gpu/drm/mediatek/mtk_hdmi_common.h | 1 +
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_common.c
To prepare support for newer chips that need to share their address
range with a dedicated ddc driver, use a regmap.
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 43 +++--
1 file changed, 13 insertions(+), 30 deletions(-)
diff --git
Some phys, such as mt8195, needs to have a configure callback defined.
Reviewed-by: AngeloGioacchino Del Regno
Signed-off-by: Guillaume Ranquet
---
drivers/phy/mediatek/phy-mtk-hdmi.c | 12
drivers/phy/mediatek/phy-mtk-hdmi.h | 1 +
2 files changed, 13 insertions(+)
diff --git
Add a compatible for the HDMI PHY on MT8195
Acked-by: Krzysztof Kozlowski
Signed-off-by: Guillaume Ranquet
---
Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
Add mt8195 SoC bindings for hdmi and hdmi-ddc
Signed-off-by: Guillaume Ranquet
---
.../bindings/display/mediatek/mediatek,hdmi.yaml | 67 +-
.../display/mediatek/mediatek,mt8195-hdmi-ddc.yaml | 51
2 files changed, 104 insertions(+), 14 deletions(-)
diff
and the dpi/drm_drv adjustements to
support hdmi.
Based on next-20221014
test branch with dts and various "in flight" patches available here:
https://gitlab.com/granquet/linux/-/tree/granquet/linux-next_HDMI
I haven't updated the vdosys/mmsys/ethdr and mutex patches in a while
in that test
On 10/14/2022 4:58 PM, Matthew Auld wrote:
On 14/10/2022 14:14, Nirmoy Das wrote:
Currently i915_ttm_to_gem() returns NULL for ttm ghost
object which makes it unclear when we should add a NULL
check for a caller of i915_ttm_to_gem() as ttm ghost
objects are expected behaviour for certain
On 14/10/2022 14:14, Nirmoy Das wrote:
Currently i915_ttm_to_gem() returns NULL for ttm ghost
object which makes it unclear when we should add a NULL
check for a caller of i915_ttm_to_gem() as ttm ghost
objects are expected behaviour for certain cases.
Create a separate function to detect ttm
Hi Francesco
On Thu, 13 Oct 2022 at 13:58, Francesco Dolcini wrote:
>
> Hello Max, Marek, Dave et al.
>
> On Tue, Jun 28, 2022 at 08:18:36PM +0200, Max Krummenacher wrote:
> > From: Max Krummenacher
> >
> > The property is used to set the enum bus_format and infer the bpc
> > for a panel
Hi Marek,
The genmask of regsiter SSCR, BPCR & others were setted accordly to the
chipset stm32f4.
You can see more details on page 493 of reference manual RM0090:
https://www.st.com/resource/en/reference_manual/DM00031020-.pdf
With future hardware, all of these registers will aligned on
On Tue, 20 Sep 2022 13:04, AngeloGioacchino Del Regno
wrote:
>Il 19/09/22 18:56, Guillaume Ranquet ha scritto:
>> Adds hdmi and hdmi-ddc support for mt8195.
>>
>> Signed-off-by: Guillaume Ranquet
>>
>> diff --git a/drivers/gpu/drm/mediatek/Makefile
>> b/drivers/gpu/drm/mediatek/Makefile
>>
Currently i915_ttm_to_gem() returns NULL for ttm ghost
object which makes it unclear when we should add a NULL
check for a caller of i915_ttm_to_gem() as ttm ghost
objects are expected behaviour for certain cases.
Create a separate function to detect ttm ghost object and
use that in places where
Hi Marek,
thanks for the patch.
Reviewed-by: Yannick Fertre
On 10/12/22 01:10, Marek Vasut wrote:
STM32MP15xx RM0436 Rev 6 "35.7.3 LTDC synchronization size configuration
register (LTDC_SSCR)" on page 1784 and onward indicates VSH and similar
bits are all [11:0] instead of [10:0] wide. Fix
Hi,
On Fri, 14 Oct 2022 at 08:46, AngeloGioacchino Del Regno <
angelogioacchino.delre...@collabora.com> wrote:
> Il 13/10/22 21:31, Justin Green ha scritto:
> > Signed-off-by: Justin Green
>
> Reviewed-by: AngeloGioacchino Del Regno <
> angelogioacchino.delre...@collabora.com>
>
And also:
On Fri, Oct 14, 2022 at 02:07:09AM +0200, Danilo Krummrich wrote:
> Hi Liviu,
>
> On 10/12/22 17:07, Liviu Dudau wrote:
> > Hi Danilo,
> >
> > Appologies again for the delay in reviewing this as I was at XDC last week.
>
> No worries, thanks for following up.
>
> > Looking at the documentation
https://bugzilla.kernel.org/show_bug.cgi?id=216583
Artem S. Tashkinov (a...@gmx.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
On 14/10/2022 08:20, Jordan Justen wrote:
Acked-by: Jordan Justen
Thanks. Can I take that as ack for merging the series from Mesa POV? I
think Lionel was going to test this, but I think keeps getting swamped
with other stuff. We kind of urgently need to land this series.
On 2022-10-04
Instead of putting that into the job sync object.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
index
This now matches much better what this is doing.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 4 ++--
drivers/gpu/drm/scheduler/sched_entity.c | 4 ++--
include/drm/gpu_scheduler.h | 13 ++---
3 files changed, 10 insertions(+), 11
Instead of putting that into the job sync object.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c| 56 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_sync.h| 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 10 +++-
3 files changed, 52
This is always the job anyway.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 20
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.h | 3 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 4 +---
3 files changed, 10 insertions(+), 17 deletions(-)
diff
Add a new function to update job dependencies from a resv obj.
Signed-off-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 49 ++
include/drm/gpu_scheduler.h| 5 +++
2 files changed, 39 insertions(+), 15 deletions(-)
diff --git
Init the DRM scheduler base class while allocating the job.
This makes the whole handling much more cleaner.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 8 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
Entirely remove the sync obj in the job.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 21 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.h | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 9 +
drivers/gpu/drm/amd/amdgpu/amdgpu_job.h | 1 -
This was buggy because when we had to wait for entities which were
killed as well we would just deadlock.
Instead move all the dependency handling into the callbacks so that
will all happen asynchronously.
Signed-off-by: Christian König
---
drivers/gpu/drm/scheduler/sched_entity.c | 197
Instead return the fence directly. Avoids memory allocation to store the
fence.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 42 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 12 +++
3
Not used any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 26 --
include/drm/gpu_scheduler.h| 2 --
2 files changed, 28 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
This moves the memory allocation out of the critical code path.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 13 -
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 12 +++-
Use the new common scheduler functions to figure out what to wait for.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
We leaked dependency fences when processes were beeing killed.
Additional to that grab a reference to the last scheduled fence.
Signed-off-by: Christian König
---
drivers/gpu/drm/scheduler/sched_entity.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
Hi guys,
rebased those patches on top of amd-staging-drm-next since the
amdgpu changes are quite substencial.
Please review and comment,
Christian.
Make sure that we always have a CPU round trip to let the submission
code correctly decide if a TLB flush is necessary or not.
Signed-off-by: Christian König
CC: sta...@vger.kernel.org # 5.19+
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 9 -
1 file changed, 8 insertions(+), 1
Setting this flag on a scheduler fence prevents pipelining of jobs
depending on this fence. In other words we always insert a full CPU
round trip before dependen jobs are pushed to the pipeline.
Signed-off-by: Christian König
CC: sta...@vger.kernel.org # 5.19+
---
On Thu, 13 Oct 2022, Ville Syrjälä wrote:
> On Thu, Oct 13, 2022 at 09:41:21PM +0300, Ville Syrjälä wrote:
>> On Tue, Oct 11, 2022 at 04:49:35PM +0300, Jani Nikula wrote:
>> > For normal connector detect, there's really no point in trying dual mode
>> > detect if the connector is disconnected. We
Il 13/10/22 21:31, Justin Green ha scritto:
Tested on MT8195 and confirmed both correct video output and improved DRAM
bandwidth performance.
v4:
* Move modifier validation to format_mod_supported function.
* Add modifiers to drm_universal_plane_init() call.
* Make comparisons to
Hi Jernej,
On Thu, Oct 13, 2022 at 08:23:51PM +0200, Jernej Škrabec wrote:
> Dne četrtek, 13. oktober 2022 ob 15:19:06 CEST je Maxime Ripard napisal(a):
> > Now that the core can deal fine with analog TV modes, let's convert the
> > sun4i TV driver to leverage those new features.
> >
> >
Acked-by: Jordan Justen
On 2022-10-04 04:49:15, Matthew Auld wrote:
> On some platforms we potentially have different alignment restrictions
> depending on the memory type. We also now have different alignment
> restrictions for the same region across different kernel versions.
> Extend the
Am 13.10.22 um 23:07 schrieb Fabio M. De Francesco:
The use of kmap() is being deprecated in favor of kmap_local_page().
There are two main problems with kmap(): (1) It comes with an overhead as
the mapping space is restricted and protected by a global lock for
synchronization and (2) it also
On 10/14/2022 4:25 AM, Rob Clark wrote:
From: Rob Clark
First patch fixes a recently introduced memory corruption, the remaining
two are cleanups.
Rob Clark (3):
drm/msm/a6xx: Fix kvzalloc vs state_kcalloc usage
drm/msm/a6xx: Skip snapshotting unused GMU buffers
drm/msm/a6xx: Remove
On Sun, Oct 09, 2022 at 11:58:18PM -0700, Niranjana Vishwanathapura wrote:
Add support for handling out fence for vm_bind call.
v2: Reset vma->vm_bind_fence.syncobj to NULL at the end
of vm_bind call.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
On Tue, Oct 11, 2022 at 06:41:23PM +0100, Matthew Auld wrote:
On 11/10/2022 17:27, Matthew Auld wrote:
On 10/10/2022 07:58, Niranjana Vishwanathapura wrote:
Each VM creates a root_obj and shares it with all of its private objects
to use it as dma_resv object. This has a performance advantage
94 matches
Mail list logo
