Hi Arun,
the hw generation doesn't matter. This error message here:
amdgpu: Move buffer fallback to memcpy unavailable
indicates that the detection of linear buffers still doesn't work as
expected or that we have a bug somewhere else.
Maybe the limiting when SDMA moves are not available isn'
On 10/17/22 04:49, Jagan Teki wrote:
On Sun, Oct 16, 2022 at 3:16 AM Marek Vasut wrote:
On 10/5/22 17:13, Jagan Teki wrote:
Samsung MIPI DSIM controller is common DSI IP that can be used in various
SoCs like Exynos, i.MX8M Mini/Nano.
In order to access this DSI controller between various pla
On 10/17/22 05:54, Jagan Teki wrote:
On Sun, Oct 16, 2022 at 2:53 AM Marek Vasut wrote:
On 10/5/22 17:13, Jagan Teki wrote:
Look like an explicit fixing up of mode_flags is required for DSIM IP
present in i.MX8M Mini/Nano SoCs.
At least the LCDIF + DSIM needs active low sync polarities in or
On 10/17/22 05:58, Jagan Teki wrote:
On Sun, Oct 16, 2022 at 3:31 AM Marek Vasut wrote:
On 10/5/22 17:13, Jagan Teki wrote:
[...]
@@ -1321,6 +1322,32 @@ static void samsung_dsim_atomic_post_disable(struct
drm_bridge *bridge,
pm_runtime_put_sync(dsi->dev);
}
+#define MAX_INPUT_SE
On 14/10/2022 at 22:51, Rob Herring wrote:
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 indentati
On Mon, Oct 17, 2022 at 12:49 PM Marek Vasut wrote:
>
> On 10/17/22 04:49, Jagan Teki wrote:
> > On Sun, Oct 16, 2022 at 3:16 AM Marek Vasut wrote:
> >>
> >> On 10/5/22 17:13, Jagan Teki wrote:
> >>> Samsung MIPI DSIM controller is common DSI IP that can be used in various
> >>> SoCs like Exynos,
On Mon, Oct 17, 2022 at 12:53 PM Marek Vasut wrote:
>
> On 10/17/22 05:54, Jagan Teki wrote:
> > On Sun, Oct 16, 2022 at 2:53 AM Marek Vasut wrote:
> >>
> >> On 10/5/22 17:13, Jagan Teki wrote:
> >>> Look like an explicit fixing up of mode_flags is required for DSIM IP
> >>> present in i.MX8M Min
On Thu, 2022-10-13 at 09:39 +0200, Javier Martinez Canillas wrote:
> > In absence of such test results I think the most reasonable thing is to
> > keep the logic that nobody complained about for 10+ years.
> >
>
> I agree with Michal and Thomas on this. I don't see a strong reason to not
> use th
On Mon, 17 Oct 2022 at 17:07, Christian König wrote:
>
> Hi Arun,
>
> the hw generation doesn't matter. This error message here:
>
> amdgpu: Move buffer fallback to memcpy unavailable
>
> indicates that the detection of linear buffers still doesn't work as
> expected or that we have a bug somewher
Am 17.10.22 um 10:01 schrieb Dave Airlie:
On Mon, 17 Oct 2022 at 17:07, Christian König wrote:
Hi Arun,
the hw generation doesn't matter. This error message here:
amdgpu: Move buffer fallback to memcpy unavailable
indicates that the detection of linear buffers still doesn't work as
expected
Hi John,
Your patch contribution causes a kernel panic on MK808 with Rockchip rk3066a
SoC.
Would you like to contribute to fix this issue?
The assumtion that drm_fbdev_generic_setup() does what rockchip_drm_fbdev_init
did is not true!
A revert makes it work again.
Johan
==
[7.975906]
On Fri, 14 Oct 2022, Ashutosh Dixit wrote:
> 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 chang
The function get_umc_v6_7_channel_index() is defined in the umc_v6_7.c
file, but not called elsewhere, so delete this unused function.
drivers/gpu/drm/amd/amdgpu/umc_v6_7.c:60:24: warning: unused function
'get_umc_v6_7_channel_index'.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2413
Rep
The function dsi_update_bits() is defined in the dw-mipi-dsi-rockchip.c
file, but not called elsewhere, so delete this unused function.
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c:367:20: warning: unused
function 'dsi_update_bits'.
https://bugzilla.openanolis.cn/show_bug.cgi?id=2414
Reported
On 10/17/22 09:43, Jagan Teki wrote:
On Mon, Oct 17, 2022 at 12:49 PM Marek Vasut wrote:
On 10/17/22 04:49, Jagan Teki wrote:
On Sun, Oct 16, 2022 at 3:16 AM Marek Vasut wrote:
On 10/5/22 17:13, Jagan Teki wrote:
Samsung MIPI DSIM controller is common DSI IP that can be used in various
So
On 2022-10-13 09:02:44, Abhinav Kumar wrote:
> On 10/13/2022 2:36 AM, Marijn Suijten wrote:
> > On 2022-10-12 16:03:06, Abhinav Kumar wrote:
> >> [..]
> >> But I would like to hold back this change till Vinod clarifies because
> >> Vinod had mentioned that with drm_dsc_compute_rc_parameters() he wa
Hi,
On 17.10.2022 10:48, Marek Vasut wrote:
> On 10/17/22 09:43, Jagan Teki wrote:
>> On Mon, Oct 17, 2022 at 12:49 PM Marek Vasut wrote:
>>> On 10/17/22 04:49, Jagan Teki wrote:
On Sun, Oct 16, 2022 at 3:16 AM Marek Vasut wrote:
>
> On 10/5/22 17:13, Jagan Teki wrote:
>> Samsun
The function amdgpu_ucode_print_imu_hdr() is defined in the amdgpu_ucode.c
file, but not called elsewhere, so delete this unused function.
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:129:6: warning: no previous prototype
for function 'amdgpu_ucode_print_imu_hdr'.
Link: https://bugzilla.openanolis.
Hi,
This is the v12 series to introduce i.MX8qm/qxp Display Processing Unit(DPU)
DRM support.
DPU is comprised of a blit engine for 2D graphics, a display controller
and a command sequencer. Outside of DPU, optional prefetch engines can
fetch data from memory prior to some DPU fetchunits of bli
This patch adds bindings for i.MX8qxp/qm Display Processing Unit.
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
v7->v12:
* No change.
v6->v7:
* Add Rob's R-b tag back.
v5->v6:
* Use graph schema. So, drop Rob's R-b tag as review is needed.
v4->v5:
* No change.
v3->v4:
* Improve compat
This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Gasket.
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
v4->v12:
* No change.
v3->v4:
* Improve compatible property by using enum instead of oneOf+const. (Rob)
* Add Rob's R-b tag.
v2->v3:
* No change.
v1->v2:
* Use new dt
This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Channel.
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
v10->v12:
* No change.
v9->v10:
* Add Rob's R-b tag.
v8->v9:
* Reference 'interrupts-extended' schema instead of 'interrupts' to require
an additional interrupt(r_r
Add myself as the maintainer of the i.MX8qxp DPU DRM driver.
Acked-by: Laurentiu Palcu
Signed-off-by: Liu Ying
---
v11->v12:
* No change.
v10->v11:
* Rebase upon v6.0-rc1.
v9->v10:
* Add Laurentiu's A-b tag.
v1->v9:
* No change.
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
di
Artificially use 'plane' and 'old_plane_state' to avoid 'not used' warning.
The precedent has already been set by other macros in the same file.
Acked-by: Daniel Vetter
Signed-off-by: Liu Ying
---
v6->v12:
* No change.
v5->v6:
* Fix commit message typo - s/Artifically/Artificially/
v4->v5:
* N
On Fri, 24 Jun 2022, Inki Dae wrote:
> 22. 6. 16. 16:22에 hongao 이(가) 쓴 글:
>> Once EDID is parsed, the monitor HDMI support information is available
>> through drm_display_info.is_hdmi.
>>
>> This driver calls drm_detect_hdmi_monitor() to receive the same
>> information, which is less efficient.
>
Den 16.10.2022 19.51, skrev Mateusz Kwiatkowski:
> Hi Maxime, Noralf & everyone,
>
> I'd like to address Noralf here in particular, and refer to these discussions
> from the past:
>
> -
> https://lore.kernel.org/linux-arm-kernel/2f607c7d-6da1-c8df-1c02-8dd344a92...@gmail.com/
> -
> https://l
Hi Johan,
On Mon, Oct 17, 2022 at 10:11:32AM +0200, Johan Jonker wrote:
> Your patch contribution causes a kernel panic on MK808 with Rockchip rk3066a
> SoC.
> Would you like to contribute to fix this issue?
> The assumtion that drm_fbdev_generic_setup() does what
> rockchip_drm_fbdev_init did i
Den 16.10.2022 20.52, skrev Mateusz Kwiatkowski:
> Hi Maxime,
>
>> static int vc4_vec_connector_get_modes(struct drm_connector *connector)
>> {
>> -struct drm_connector_state *state = connector->state;
>> struct drm_display_mode *mode;
>>
>> -mode = drm_mode_duplicate(connector
Den 13.10.2022 15.19, skrev Maxime Ripard:
> The drm_tv_create_properties() function will create a bunch of properties,
> but it's up to each and every driver using that function to properly reset
> the state of these properties leading to inconsistent behaviours.
>
> Let's create a helper that
Den 13.10.2022 15.18, skrev Maxime Ripard:
> As part of the command line parsing rework coming in the next patches,
> we'll need to lookup drm_connector_tv_mode values by their name, already
> defined in drm_tv_mode_enum_list.
>
> In order to avoid any code duplication, let's do a function that
The Panfrost DRM interface to user space is uesd in Mesa for targets
other than C/Linux. Specifically the header file needs to compile in C++
code and for FreeBSD which shares the same UABI.
The first patch fixes the C++ compilation issue by removing the
(unnecessary) type name from internal struc
The two structs internal to struct panfrost_dump_object_header were
named, but sadly that is incompatible with C++, causing an error: "an
anonymous union may only have public non-static data members".
However nothing refers to struct pan_reg_hdr and struct pan_bomap_hdr
and there's no need to expo
__le32 and __le64 types aren't portable and are not available on
FreeBSD (which uses the same uAPI).
Instead of attempting to always output little endian, just use native
endianness in the dumps. Tools can detect the endianness in use by
looking at the 'magic' field, but equally we don't expect bi
Add {begin,end}_fb_access helpers to run at the beginning and end of
an atomic commit. The begin_fb_access helper aquires resources that
are necessary to perform the atomic commit. It it similar to prepare_fb,
except that the resources are to be released at the end of the commit.
Resources acquired
Call drm_gem_fb_begin_cpu_access() and drm_gem_fb_end_cpu_access() in
the simple pipe's {begin,end}_fb_access helpers. This allows to abort
commits correctly after observing an error.
Remove the corresponding CPU-access calls from the driver's damage
handler. It runs during the atomic-apply phase
Call drm_gem_fb_begin_cpu_access() and drm_gem_fb_end_cpu_access() in
the simple pipe's {begin,end}_fb_access helpers. This allows to abort
commits correctly after observing an error.
Remove the corresponding CPU-access calls from the driver's damage
handler. It runs during the atomic-apply phase
This patchset adds the callbacks begin_fb_access and end_fb_access
to struct drm_plane_helper_funcs. They provide hooks to acquire and
release resources that are only held during the commit. It adds
related simple-KMS helpers and converts a number of drivers.
A number of drivers call drm_gem_fb_be
Handle drm_gem_{begin,end}_cpu_access() in shadow-plane helpers during
a commit. The functions synchronizes imported dma-buf objects with the
exporter's state. If this fail (as signalled by an error code), atomic-
commit helpers can now still abort the commit.
Several drivers already reserved CPU
Move the vmap code for shadow-plane helpers from prepare_fb to
begin_fb_access helpers. Vunmap is now performed at the end of
the current pageflip, instead of the end of the following pageflip.
Reduces the duration of the mapping from while the framebuffer is
being displayed to just the atomic com
Am Montag, 17. Oktober 2022, 12:05:16 CEST schrieb John Keeping:
> Hi Johan,
>
> On Mon, Oct 17, 2022 at 10:11:32AM +0200, Johan Jonker wrote:
> > Your patch contribution causes a kernel panic on MK808 with Rockchip
> > rk3066a SoC.
> > Would you like to contribute to fix this issue?
> > The assu
Den 13.10.2022 15.19, skrev Maxime Ripard:
> Now that the core can deal fine with analog TV modes, let's convert the vc4
> VEC driver to leverage those new features.
>
> We've added some backward compatibility to support the old TV mode property
> and translate it into the new TV norm property.
Den 17.10.2022 13.15, skrev Thomas Zimmermann:
> Call drm_gem_fb_begin_cpu_access() and drm_gem_fb_end_cpu_access() in
> the simple pipe's {begin,end}_fb_access helpers. This allows to abort
> commits correctly after observing an error.
>
> Remove the corresponding CPU-access calls from the dri
Hello Thomas,
On 10/17/22 13:15, Thomas Zimmermann wrote:
> Handle drm_gem_{begin,end}_cpu_access() in shadow-plane helpers during
> a commit. The functions synchronizes imported dma-buf objects with the
> exporter's state. If this fail (as signalled by an error code), atomic-
> commit helpers can
On Fri, Oct 14, 2022 at 03:51:04PM -0500, Rob Herring wrote:
> 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
> f
Hi Hamza,
On 10/14/22 11:31, Hamza Mahfooz wrote:
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
On 17/10/2022 09:59, Marijn Suijten wrote:
> On 2022-10-13 09:02:44, Abhinav Kumar wrote:
>> On 10/13/2022 2:36 AM, Marijn Suijten wrote:
>>> On 2022-10-12 16:03:06, Abhinav Kumar wrote:
[..]
But I would like to hold back this change till Vinod clarifies because
Vinod had mentione
On Wed, Oct 12, 2022 at 12:20 PM Hsin-Yi Wang wrote:
>
> Some bridges are able to update HDCP status from userspace request if
> they support HDCP.
>
> HDCP property is the same as other connector properties that need to be
> created after the connecter is initialized and before the connector is
>
On 2022-10-17 09:06, Rodrigo Siqueira wrote:
Hi Hamza,
On 10/14/22 11:31, Hamza Mahfooz wrote:
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.
-This is purely a timing issue. Here, sometimes Job free
is happening before the job is done.
To fix this issue moving 'dma_fence_cb' callback from
job(struct drm_sched_job) to scheduler fence (struct drm_sched_fence).
- Added drm_sched_fence_set_parent() function(and others *_parent_cb)
in sched_
On 10/13/22 13:02, Simon Ser wrote:
So no tests that actually verify that the kernel properly rejects
stuff stuff like modesets, gamma LUT updates, plane movement,
etc.?
Pondering this a bit more, it just occurred to me the current driver
level checks might easily lead to confusing behaviour. E
On Mon, Oct 10, 2022 at 11:37:37AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 07.10.22 um 14:49 schrieb Thierry Reding:
> > From: Thierry Reding
> >
> > In order to support framebuffers residing in system memory, allow the
> > memory-region property to override the framebuffer memory specificat
Am 17.10.22 um 16:30 schrieb Arvind Yadav:
-This is purely a timing issue. Here, sometimes Job free
is happening before the job is done.
To fix this issue moving 'dma_fence_cb' callback from
job(struct drm_sched_job) to scheduler fence (struct drm_sched_fence).
- Added drm_sched_fence_set_parent
On Mon, Oct 10, 2022 at 10:12:34AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 07.10.22 um 14:49 schrieb Thierry Reding:
> > From: Thierry Reding
> >
> > Simple framebuffers can be set up in system memory, which cannot be
> > requested and/or I/O remapped using the I/O resource helpers. Add a
>
Hi,
Smatch warns:
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c:755
dw_mipi_dsi_rockchip_set_lcdsel() warn: unsigned
'dsi->cdata->lcdsel_grf_reg'
is never less than zero.
static void dw_mipi_dsi_rockchip_set_lcdsel(struct dw_mipi_dsi_rockchip
*dsi,
On Mon, Oct 17, 2022 at 5:04 AM Jiapeng Chong
wrote:
>
> The function amdgpu_ucode_print_imu_hdr() is defined in the amdgpu_ucode.c
> file, but not called elsewhere, so delete this unused function.
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:129:6: warning: no previous
> prototype for function
On Mon, 17 Oct 2022, Geert Uytterhoeven wrote:
Below is the list of build error/warning regressions/improvements in
v6.1-rc1[1] compared to v6.0[2].
Summarized:
- build errors: +25/-13
[1]
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/9abf2313adc1ca1b6180c508c25f22f9395cc780/
(all
This reverts commit 981f09295687f856d5345e19c7084aca481c1395.
It turns out this breaks Mutter.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Lyude Paul
Cc: Jonas Ådahl
---
drivers/gpu/drm/drm_mode_config.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_mode_config
A typical DP-MST unplug removes a KMS connector. However care must
be taken to properly synchronize with user-space. The expected
sequence of events is the following:
1. The kernel notices that the DP-MST port is gone.
2. The kernel marks the connector as disconnected, then sends a
uevent to ma
On Mon, Oct 17, 2022 at 03:32:01PM +, Simon Ser wrote:
> A typical DP-MST unplug removes a KMS connector. However care must
> be taken to properly synchronize with user-space. The expected
> sequence of events is the following:
>
> 1. The kernel notices that the DP-MST port is gone.
> 2. The k
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, for instance we
have had reports of this condition being triggered when removing a
secondary displ
Series is
Reviewed-by: Alyssa Rosenzweig
Thank you for this, please push to the appropriate trees so we can fix
the Mesa build.
On Mon, Oct 17, 2022 at 11:46:00AM +0100, Steven Price wrote:
> The Panfrost DRM interface to user space is uesd in Mesa for targets
> other than C/Linux. Spec
On 2022-10-17 11:38, Hamza Mahfooz wrote:
> 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, for instance we
> have had reports of this cond
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, for instance we
have had reports of this condition being triggered when removing a
secondary displ
On 10/17/2022 6:37 AM, Caleb Connolly wrote:
On 17/10/2022 09:59, Marijn Suijten wrote:
On 2022-10-13 09:02:44, Abhinav Kumar wrote:
On 10/13/2022 2:36 AM, Marijn Suijten wrote:
On 2022-10-12 16:03:06, Abhinav Kumar wrote:
[..]
But I would like to hold back this change till Vinod clarifi
When booting a kernel compiled with CONFIG_CFI_CLANG on a machine with
an RX 6700 XT, there is a CFI failure in kfd_destroy_mqd_cp():
[ 12.894543] CFI failure at kfd_destroy_mqd_cp+0x2a/0x40 [amdgpu] (target:
hqd_destroy_v10_3+0x0/0x260 [amdgpu]; expected type: 0x8594d794)
Clang's kernel Con
On 14.10.2022 16:02, Matt Roper wrote:
> 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 g
On 14.10.2022 16:02, Matt Roper wrote:
> 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'
On 14.10.2022 16:02, Matt Roper wrote:
> 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 platfor
Applied. Thanks!
On Thu, Oct 13, 2022 at 2:25 PM Guenter Roeck wrote:
>
> Building 32-bit images may fail with the following error.
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_util_32.c:
> In function ‘dml32_UseMinimumDCFCLK’:
> drivers/gpu/drm/amd/amdgpu/../d
On 14.10.2022 16:02, Matt Roper wrote:
> 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 we
On 14.10.2022 16:02, Matt Roper wrote:
> 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
Applied. Thanks!
On Fri, Oct 14, 2022 at 3:03 AM Christian König
wrote:
>
> 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 mappi
On 14.10.2022 16:02, Matt Roper wrote:
> 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_a
On 14.10.2022 16:02, Matt Roper wrote:
> 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
On 14.10.2022 16:02, Matt Roper wrote:
> 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
Applied. Thanks!
On Sun, Oct 16, 2022 at 1:42 PM Fabio M. De Francesco
wrote:
>
> kmap() is being deprecated in favor of kmap_local_page().
>
> There are two main problems with kmap(): (1) It comes with an overhead as
> mapping space is restricted and protected by a global lock for
> synchroniza
On 14.10.2022 16:02, Matt Roper wrote:
> 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 operat
On 14.10.2022 16:02, Matt Roper wrote:
> 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 instance
On 14.10.2022 16:02, Matt Roper wrote:
> 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
Applied. Thanks!
Alex
On Mon, Oct 17, 2022 at 12:30 PM Nathan Chancellor wrote:
>
> When booting a kernel compiled with CONFIG_CFI_CLANG on a machine with
> an RX 6700 XT, there is a CFI failure in kfd_destroy_mqd_cp():
>
> [ 12.894543] CFI failure at kfd_destroy_mqd_cp+0x2a/0x40 [amdgpu]
On 14.10.2022 16:02, Matt Roper wrote:
> 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 d
On 14.10.2022 16:02, Matt Roper wrote:
> 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 b
On 14.10.2022 16:02, Matt Roper wrote:
> 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 un
Hi Laurent
On Sat, 15 Oct 2022 at 18:14, Laurent Pinchart
wrote:
>
> Hi Maxime (and Dave),
>
> Thank you for the patch.
>
> On Thu, Oct 13, 2022 at 11:56:50AM +0200, Maxime Ripard wrote:
> > From: Dave Stevenson
> >
> > DPI hasn't really been used up until now, so the default has
> > been meanin
Hi Laurent
On Sat, 15 Oct 2022 at 18:29, Laurent Pinchart
wrote:
>
> Hi Maxime and Chris,
>
> Thank you for the patch.
>
> On Thu, Oct 13, 2022 at 11:56:48AM +0200, Maxime Ripard wrote:
> > From: Chris Morgan
> >
> > The RGB565 format with padding over 24 bits
> > (MEDIA_BUS_FMT_RGB565_1X24_CPAD
Hello,
This series moves all drivers to a dynamic dma-buf locking specification.
>From now on all dma-buf importers are made responsible for holding
dma-buf's reservation lock around all operations performed over dma-bufs
in accordance to the locking specification. This allows us to utilize
reserv
Add unlocked variant of dma_buf_map/unmap_attachment() that will
be used by drivers that don't take the reservation lock explicitly.
Acked-by: Sumit Semwal
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 53 +++
inclu
Add unlocked variant of dma_buf_vmap/vunmap() that will be utilized
by drivers that don't take the reservation lock explicitly.
Acked-by: Sumit Semwal
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 43 +++
include/li
The new common dma-buf locking convention will require buffer importers
to hold the reservation lock around mapping operations. Make DRM GEM core
to take the lock around the vmapping operations and update DRM drivers to
use the locked functions for the case where DRM core now holds the lock.
This p
Prepare DRM prime core to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Reviewed-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_prime.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
dif
Prepare Armada driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/armada/armada_gem.c | 8
1 file changed, 4 insertions(+), 4 deletions(-
Prepare i915 driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions
and handling cases where importer now holds the reservation lock.
Acked-by: Christian König
Reviewed-by: Michael J. Ruhl
Signed-off-by: Dmitry Osipenko
---
dri
Prepare gntdev driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Acked-by: Juergen Gross
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/xen/gntdev-dmabuf.c | 8
1 file changed, 4 insertions(
Prepare OMAP DRM driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletio
Prepare Etnaviv driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
Prepare Tegra DRM driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/gem.c | 17 +
1 file changed, 9 insertions(+), 8 deleti
Prepare Tegra video decoder driver to the common dynamic dma-buf
locking convention by starting to use the unlocked versions of dma-buf
API functions.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/media/platform/nvidia/tegra-vde/dmabuf-cache.c | 6 +++---
1 file changed,
Prepare InfiniBand drivers to the common dynamic dma-buf locking
convention by starting to use the unlocked versions of dma-buf API
functions.
Acked-by: Jason Gunthorpe
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/infiniband/core/umem_dmabuf.c | 7 ---
1 file change
Prepare fastrpc to the common dynamic dma-buf locking convention by
starting to use the unlocked versions of dma-buf API functions.
Acked-by: Christian König
Acked-by: Srinivas Kandagatla
Signed-off-by: Dmitry Osipenko
---
drivers/misc/fastrpc.c | 6 +++---
1 file changed, 3 insertions(+), 3 d
Prepare V4L2 memory allocators to the common dynamic dma-buf locking
convention by starting to use the unlocked versions of dma-buf API
functions.
Acked-by: Tomasz Figa
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/media/common/videobuf2/videobuf2-dma-contig.c | 11 +
1 - 100 of 175 matches
Mail list logo
