== Series Details ==
Series: drm/i915: implement internal workqueues (rev3)
URL : https://patchwork.freedesktop.org/series/117618/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13203 -> Patchwork_117618v3
Summary
---
== Series Details ==
Series: drm/i915: implement internal workqueues (rev3)
URL : https://patchwork.freedesktop.org/series/117618/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915: implement internal workqueues (rev3)
URL : https://patchwork.freedesktop.org/series/117618/
State : warning
== Summary ==
Error: dim checkpatch failed
722468704c00 drm/i915: use pointer to i915 instead of rpm in wakeref
0b06c13ceb1d drm/i915: add a dedica
On 2023.05.31 02:04:11 +, Zhi Wang wrote:
> Remove unused variable gma_bottom in scan_workload() and scan_wa_ctx().
> commit be1da7070aea ("drm/i915/gvt: vGPU command scanner") introduces
> gma_bottom in several functions to calculate the size of the command
> buffer. However, some of them are
== Series Details ==
Series: drm/i915: Use 18 fast wake AUX sync len (rev2)
URL : https://patchwork.freedesktop.org/series/118517/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13203 -> Patchwork_118517v2
Summary
---
== Series Details ==
Series: drm/display & drm/i915: more struct drm_edid conversions (rev2)
URL : https://patchwork.freedesktop.org/series/116813/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13203 -> Patchwork_116813v2
S
== Series Details ==
Series: drm/display & drm/i915: more struct drm_edid conversions (rev2)
URL : https://patchwork.freedesktop.org/series/116813/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: Do not access i915_gem_object members from frontbuffer tracking (rev2)
URL : https://patchwork.freedesktop.org/series/118475/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13202 -> Patchwork_118475v2
== Series Details ==
Series: Do not access i915_gem_object members from frontbuffer tracking (rev2)
URL : https://patchwork.freedesktop.org/series/118475/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: Move dma-buf mmap() reservation locking down to exporters (rev4)
URL : https://patchwork.freedesktop.org/series/116000/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13202 -> Patchwork_116000v4
The code after the return will not be executed, so remove them.
Eliminate the following warning:
drivers/gpu/drm/i915/display/intel_color.c:1808 intel_color_prepare_commit()
warn: ignoring unreachable code.
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5342
Sig
== Series Details ==
Series: Move dma-buf mmap() reservation locking down to exporters (rev4)
URL : https://patchwork.freedesktop.org/series/116000/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x8
Remove unused variable gma_bottom in scan_workload() and scan_wa_ctx().
commit be1da7070aea ("drm/i915/gvt: vGPU command scanner") introduces
gma_bottom in several functions to calculate the size of the command
buffer. However, some of them are set but actually unused.
When compiling the code with
== Series Details ==
Series: drm/i915: Use 18 fast wake fast wake AUX sync len
URL : https://patchwork.freedesktop.org/series/118504/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13202 -> Patchwork_118504v1
Summary
---
== Series Details ==
Series: drm/i915/gvt: remove unused variable gma_bottom in command parser
URL : https://patchwork.freedesktop.org/series/118512/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/118512/revisions/1/mbox/ not
applied
Applying: drm
== Series Details ==
Series: Change HDCP GSC message flow to use same object
URL : https://patchwork.freedesktop.org/series/118499/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13202 -> Patchwork_118499v1
Summary
---
== Series Details ==
Series: Change HDCP GSC message flow to use same object
URL : https://patchwork.freedesktop.org/series/118499/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bit
== Series Details ==
Series: drm/i915/display: Fix a use-after-free when intel_edp_init_connector
fails (rev2)
URL : https://patchwork.freedesktop.org/series/112091/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13202 -> Patchwork_112091v2
On Fri, 2023-05-26 at 17:52 -0700, Ceraolo Spurio, Daniele wrote:
> The full authentication via the GSC requires an heci packet submission
> to the GSC FW via the GSC CS. The GSC has new PXP command for this
> (literally called NEW_HUC_AUTH).
> The intel_huc_auth fuction is also updated to handle b
On 5/30/2023 5:20 PM, John Harrison wrote:
On 5/30/2023 17:11, Ceraolo Spurio, Daniele wrote:
On 5/30/2023 4:51 PM, John Harrison wrote:
On 5/26/2023 17:52, Daniele Ceraolo Spurio wrote:
In the previous patch we extracted the offset of the legacy-style HuC
binary located within the GSC-enab
On 5/30/2023 17:14, Ceraolo Spurio, Daniele wrote:
On 5/30/2023 5:01 PM, John Harrison wrote:
On 5/30/2023 08:29, Daniele Ceraolo Spurio wrote:
Before we add the second step of the MTL HuC auth (via GSC), we need to
have the ability to differentiate between them. To do so, the huc
authenticatio
On 5/30/2023 17:11, Ceraolo Spurio, Daniele wrote:
On 5/30/2023 4:51 PM, John Harrison wrote:
On 5/26/2023 17:52, Daniele Ceraolo Spurio wrote:
In the previous patch we extracted the offset of the legacy-style HuC
binary located within the GSC-enabled blob, so now we can use that to
load the Hu
On 5/30/2023 5:01 PM, John Harrison wrote:
On 5/30/2023 08:29, Daniele Ceraolo Spurio wrote:
Before we add the second step of the MTL HuC auth (via GSC), we need to
have the ability to differentiate between them. To do so, the huc
authentication check is duplicated for GuC and GSC auth, with
On 5/30/2023 4:51 PM, John Harrison wrote:
On 5/26/2023 17:52, Daniele Ceraolo Spurio wrote:
In the previous patch we extracted the offset of the legacy-style HuC
binary located within the GSC-enabled blob, so now we can use that to
load the HuC via DMA if the fuse is set that way.
Note that
On 5/30/2023 17:06, Ceraolo Spurio, Daniele wrote:
On 5/30/2023 4:30 PM, John Harrison wrote:
On 5/26/2023 17:52, Daniele Ceraolo Spurio wrote:
The new binaries that support the 2-step authentication contain the
legacy-style binary, which we can use for loading the HuC via DMA. To
find out wher
On 5/30/2023 4:30 PM, John Harrison wrote:
On 5/26/2023 17:52, Daniele Ceraolo Spurio wrote:
The new binaries that support the 2-step authentication contain the
legacy-style binary, which we can use for loading the HuC via DMA. To
find out where this is located in the image, we need to parse
On 5/30/2023 08:29, Daniele Ceraolo Spurio wrote:
Before we add the second step of the MTL HuC auth (via GSC), we need to
have the ability to differentiate between them. To do so, the huc
authentication check is duplicated for GuC and GSC auth, with meu
meu?
binaries being considered fully aut
On 5/26/2023 17:52, Daniele Ceraolo Spurio wrote:
In the previous patch we extracted the offset of the legacy-style HuC
binary located within the GSC-enabled blob, so now we can use that to
load the HuC via DMA if the fuse is set that way.
Note that we now need to differentiate between "GSC-enabl
On 5/26/2023 17:52, Daniele Ceraolo Spurio wrote:
The new binaries that support the 2-step authentication contain the
legacy-style binary, which we can use for loading the HuC via DMA. To
find out where this is located in the image, we need to parse the
manifest of the GSC-enabled HuC binary. The
On 5/26/2023 17:52, Daniele Ceraolo Spurio wrote:
Now that each FW has its own reserved area, we can keep them always
pinned and skip the pin/unpin dance on reset. This will make things
easier for the 2-step HuC authentication, which requires the FW to be
pinned in GGTT after the xfer is complete
== Series Details ==
Series: drm/i915_drm.h: fix a typo (rev2)
URL : https://patchwork.freedesktop.org/series/118479/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13200 -> Patchwork_118479v2
Summary
---
**SUCCESS**
Hi Tejas,
On Wed, May 17, 2023 at 07:27:54PM +0530, Tejas Upadhyay wrote:
> From: Chris Wilson
>
> Allow compute contexts to submit the maximal amount of work without
> blocking userspace.
>
> The original size for user LRC ring's (SZ_16K) was chosen to minimise
> memory consumption, without be
== Series Details ==
Series: HDCP Cleanup (rev4)
URL : https://patchwork.freedesktop.org/series/117938/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13200 -> Patchwork_117938v4
Summary
---
**SUCCESS**
No regressi
== Series Details ==
Series: HDCP Cleanup (rev4)
URL : https://patchwork.freedesktop.org/series/117938/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: HDCP Cleanup (rev4)
URL : https://patchwork.freedesktop.org/series/117938/
State : warning
== Summary ==
Error: dim checkpatch failed
2eb29163dd05 drm/i915/hdcp: Rename dev_priv to i915
01eb36f170a2 drm/i915/hdcp: Move away from master naming to arbiter
-:248: CHEC
Hi Tejas,
Just one note...
On Wed, May 17, 2023 at 07:27:54PM +0530, Tejas Upadhyay wrote:
> From: Chris Wilson
>
> Allow compute contexts to submit the maximal amount of work without
> blocking userspace.
>
> The original size for user LRC ring's (SZ_16K) was chosen to minimise
> memory consu
On 5/26/2023 16:55, john.c.harri...@intel.com wrote:
From: Michal Wajdeczko
For easier debug of any unexpected error responses from GuC that
might be related to non-blocking fast requests, track action code (and
stack if under DEBUG_GUC config) for every H2G request.
Signed-off-by: Michal Wajd
Hi Tejas,
On Wed, May 17, 2023 at 06:52:30PM +0530, Tejas Upadhyay wrote:
> Wa_14016712196 implementation for mtl
>
> Bspec: 72197
>
> V2:
> - Fix kernel test robot warnings
>
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202305121525.3ewdgoby-...@intel
On 5/26/2023 16:55, john.c.harri...@intel.com wrote:
From: Michal Wajdeczko
Instead of printing message fence twice, include HXG header of the
unexpected message and its len.
Signed-off-by: Michal Wajdeczko
Signed-off-by: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i91
On 5/26/2023 16:55, john.c.harri...@intel.com wrote:
From: Michal Wajdeczko
In addition to the already defined REQUEST HXG message format,
which is used when sender expects some confirmation or data,
HXG protocol includes definition of the FAST REQUEST message,
that may be used when sender does
Hi Tejas,
On Wed, May 17, 2023 at 07:27:54PM +0530, Tejas Upadhyay wrote:
> From: Chris Wilson
>
> Allow compute contexts to submit the maximal amount of work without
> blocking userspace.
>
> The original size for user LRC ring's (SZ_16K) was chosen to minimise
> memory consumption, without be
Hi Nathan,
On Tue, May 30, 2023 at 11:37:56AM -0700, Nathan Chancellor wrote:
> When building ARCH=i386 allmodconfig, the following warning occurs:
>
> In file included from include/linux/device.h:15,
>from include/linux/node.h:18,
>from include/linux/cpu
> Subject: [PATCH 2/2] drm/i915/gt: Fix parameter in
> gmch_ggtt_insert_{entries,page}()
>
> When building with clang's -Wincompatible-function-pointer-types-strict,
> the following warnings occur:
>
> drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c:102:23: error: incompatible
> function pointer type
> Subject: [PATCH 1/2] drm/i915/gt: Fix second parameter type of pre-gen8
> pte_encode callbacks
>
> When booting a kernel compiled with CONFIG_CFI_CLANG (kCFI), there is a CFI
> failure in ggtt_probe_common() when trying to call hsw_pte_encode() via an
> indirect call:
>
> [5.030027] CFI
Hi Nathan,
On Tue, May 30, 2023 at 11:24:39AM -0700, Nathan Chancellor wrote:
> When building with clang's -Wincompatible-function-pointer-types-strict,
> the following warnings occur:
>
> drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c:102:23: error: incompatible
> function pointer types assigning
Hi Nathan,
On Tue, May 30, 2023 at 11:24:38AM -0700, Nathan Chancellor wrote:
> When booting a kernel compiled with CONFIG_CFI_CLANG (kCFI), there is a
> CFI failure in ggtt_probe_common() when trying to call hsw_pte_encode()
> via an indirect call:
>
> [5.030027] CFI failure at ggtt_probe_
Replace all occurences of ADL -> ALDERLAKE in
platform and subplatform defines. This way there is a
consistent pattern to how platforms are referred. While
the change is minor and could be combined to have lesser patches,
splitting to per subpaltform for easier cherrypicks, if needed.
Anusha Sriva
Follow consistent naming convention. Replace ADLP with
ALDERLAKE_P
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel
Driver refers to the platfrom Alderlake S as ADLS in places
and ALDERLAKE_S in some. Making the consistent change
to avoid confusion of the right naming convention for
the platform.
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c| 2 +-
drivers/gpu/drm/i915/i915_drv.
Follow consistent naming convention. Replace ADLP with
ALDERLAKE_P.
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_step.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/
Driver refers to the platfrom Alderlake P as ADLP in places
and ALDERLAKE_P in some. Making the consistent change
to avoid confusion of the right naming convention for
the platform.
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 2 +-
drivers/gpu/drm/i915
Follow consistent naming convention. Replace ADLP with
ALDERLAKE_P
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/
drm_warn(&i915->drm, "caller with insufficient PXP reply size
%u (%ld)\n",
+ drm_warn(&i915->drm, "caller with insufficient PXP reply size
%u (%zu)\n",
reply_size, msg_out_size_max);
reply_size = msg_out_size_max;
}
---
base-commit: 08264f85c5c05ecc38d409c84d48cfb00ccd3bc4
change-id: 20230530-i915-pxp-size_t-wformat-1d73ed1f8d23
Best regards,
--
Nathan Chancellor
When booting a kernel compiled with CONFIG_CFI_CLANG (kCFI), there is a
CFI failure in ggtt_probe_common() when trying to call hsw_pte_encode()
via an indirect call:
[5.030027] CFI failure at ggtt_probe_common+0xd1/0x130 [i915] (target:
hsw_pte_encode+0x0/0x30 [i915]; expected type: 0xf5c1d
When building with clang's -Wincompatible-function-pointer-types-strict,
the following warnings occur:
drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c:102:23: error: incompatible
function pointer types assigning to 'void (*)(struct i915_address_space *,
dma_addr_t, u64, unsigned int, u32)' (aka 'voi
change-id:
20230530-i915-gt-cache_level-wincompatible-function-pointer-types-strict-32a5c65249a5
Best regards,
--
Nathan Chancellor
== Series Details ==
Series: drm/i915: Remove i915_drm_suspend_mode (rev2)
URL : https://patchwork.freedesktop.org/series/112607/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13200_full -> Patchwork_112607v2_full
Summary
-
On MTL, if the GSC Proxy init flows haven't completed, submissions to the
GSC engine will fail. Those init flows are dependent on the mei's
gsc_proxy component that is loaded in parallel with i915 and a
worker that could potentially start after i915 driver init is done.
That said, all subsytems th
Hi Thomas,
> > > - if (helper->funcs->fb_dirty) {
> > > - drm_fb_helper_memory_range_to_clip(info, pos, ret,
> > > &damage_area);
> > > - drm_fb_helper_damage(helper, damage_area.x1, damage_area.y1,
> > > - drm_rect_width(&damage_area),
> > > -
Before we add the second step of the MTL HuC auth (via GSC), we need to
have the ability to differentiate between them. To do so, the huc
authentication check is duplicated for GuC and GSC auth, with meu
binaries being considered fully authenticated only after the GSC auth
step.
To report the diff
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the callbacks. Fbdev-generic was the
only caller of the DRM helpers, so remove them from the helper
module.
v4:
* generate deferred-I/O helpers
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Exynos does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirel
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Gma500 does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirel
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the fbdev callbacks. i915 was the only
caller of the DRM helpers, so remove them from the helper module.
i915's fbdev emulation is still incomplete as it do
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Armada does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirel
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Fbdev-dma does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions enti
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Msm does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.
Export drm_fb_helper_damage() and drm_fb_helper_damage_range(), which
handle damage areas for fbdev emulation. This is a temporary export
that allows to move the DRM I/O helpers for fbdev into drivers. Only
fbdev-generic and i915 need them. Both will be updated to implement
damage handling by thems
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Tegra does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely
For framebuffers in I/O and system memory, add macros that set
struct fb_ops to the respective callback functions.
For deferred I/O, add macros that generate callback functions with
damage handling. Add initializer macros that set struct fb_ops to
the generated callbacks.
These macros can remove
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Radeon does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirel
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Omapdrm does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entire
DRM provides a number of wrappers around fbdev cfb_() sys_(), fb_io_()
and fb_sys_() helpers. The DRM functions don't provide any additional
functionality for most DRM drivers. So remove them and call the fbdev
I/O helpers directly.
The DRM fbdev I/O wrappers were originally added because
does no
Many fbdev drivers use the same set of fb_ops helpers. Add Kconfig
options to select them at once. This will help with making DRM's
fbdev emulation code more modular, but can also be used to simplify
fbdev's driver configs.
v3:
* fix select statement (Jingfeng)
Signed-off-by: Thomas Zimme
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the callbacks. Fbdev-generic was the
only caller of the DRM helpers, so remove them from the helper
module.
v4:
* generate deferred-I/O helpers
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the fbdev callbacks. i915 was the only
caller of the DRM helpers, so remove them from the helper module.
i915's fbdev emulation is still incomplete as it do
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Gma500 does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirel
Export drm_fb_helper_damage() and drm_fb_helper_damage_range(), which
handle damage areas for fbdev emulation. This is a temporary export
that allows to move the DRM I/O helpers for fbdev into drivers. Only
fbdev-generic and i915 need them. Both will be updated to implement
damage handling by thems
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Radeon does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirel
For framebuffers in I/O and system memory, add macros that set
struct fb_ops to the respective callback functions.
For deferred I/O, add macros that generate callback functions with
damage handling. Add initializer macros that set struct fb_ops to
the generated callbacks.
These macros can remove
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Exynos does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirel
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Tegra does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Fbdev-dma does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions enti
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Armada does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirel
Many fbdev drivers use the same set of fb_ops helpers. Add Kconfig
options to select them at once. This will help with making DRM's
fbdev emulation code more modular, but can also be used to simplify
fbdev's driver configs.
v3:
* fix select statement (Jingfeng)
Signed-off-by: Thomas Zimme
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Omapdrm does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entire
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Msm does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.
DRM provides a number of wrappers around fbdev cfb_() sys_(), fb_io_()
and fb_sys_() helpers. The DRM functions don't provide any additional
functionality for most DRM drivers. So remove them and call the fbdev
I/O helpers directly.
The DRM fbdev I/O wrappers were originally added because
does no
> -Original Message-
> From: Luca Coelho
> Sent: Tuesday, May 30, 2023 1:08 PM
> To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/mtl: Reset only one lane in case of
> MFD
>
> On Tue, 2023-05-30 at 09:30 +, Kahola, Mika wrote:
> > > -
Instead of using a global workqueue for the SW fence selftest,
allocate a separate one temporarily only while running the test.
Cc: Tetsuo Handa
Cc: Jani Nikula
Cc: Ville Syrjälä
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Luca Coelho
---
drivers/gpu/drm/i915/selftests/i915_sw_fence.c | 16 ++
In order to avoid flush_scheduled_work() usage, add a dedicated
workqueue in the drm_i915_private structure. In this way, we don't
need to use the system queue anymore.
This change is mostly mechanical and based on Tetsuo's original
patch[1].
Link: https://patchwork.freedesktop.org/series/114608
Currently a pointer to an intel_runtime_pm structure is stored in the
wake reference structures so the runtime data can be accessed. We can
save the entire device information (drm_i915_private) instead, since
we'll need to reference the new workqueue we'll add in subsequent
patches.
Reviewed-by:
Hi,
This series implements internal workqueues in the i915 driver in order
to avoid using the system queue. We add one generic workqueue in the
drm_i915_private structure, one specific for wake references and one
in a self-test.
This is based on Tetsuo's work[1] and is required to get rid of the
== Series Details ==
Series: drm/i915: Remove i915_drm_suspend_mode (rev2)
URL : https://patchwork.freedesktop.org/series/112607/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13200 -> Patchwork_112607v2
Summary
---
HW default for wake sync pulses is 18. 10 precarge and 8 preamble. There is
no reason to change this especially as it is causing problems with certain
eDP panels.
v3: Change "Fixes:" commit
v2: Remove "fast wake" repeat from subject
Signed-off-by: Jouni Högander
Fixes: e1c71f8f9180 ("drm/i915: F
On Tue, 2023-05-30 at 09:30 +, Kahola, Mika wrote:
> > -Original Message-
> > From: Luca Coelho
> > Sent: Tuesday, May 30, 2023 11:38 AM
> > To: Kahola, Mika ; intel-
> > g...@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915/mtl: Reset only one lane
> > in case of MF
On Tue, 2023-05-30 at 12:14 +0300, Jani Nikula wrote:
> On Mon, 29 May 2023, Jouni Högander wrote:
> > HW default for wake sync pulses is 18. 10 precarge and 8 preamble.
> > There is
> > no reason to change this especially as it is causing problems with
> > certain
> > eDP panels.
> >
> > Signed-
On Tue, 2023-05-30 at 09:06 +, Murthy, Arun R wrote:
> > -Original Message-
> > From: Intel-gfx On Behalf
> > Of Jouni
> > Högander
> > Sent: Monday, May 29, 2023 6:30 PM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [Intel-gfx] [PATCH] drm/i915: Use 18 fast wake fast wake
> > A
== Series Details ==
Series: drm/i915: Remove i915_drm_suspend_mode (rev2)
URL : https://patchwork.freedesktop.org/series/112607/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
> -Original Message-
> From: Luca Coelho
> Sent: Tuesday, May 30, 2023 11:38 AM
> To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/mtl: Reset only one lane in case of
> MFD
>
> Looks good, I only have some nitpicks.
>
> On Wed, 2023-05-24 at
1 - 100 of 119 matches
Mail list logo
