The debug print for enabling SDP CRC16 is applicable only for DP2.0, but
this debug print was not within the uhbr check and was always printed.
Fis this by adding proper checks and returning.
Signed-off-by: Arun R Murthy
---
.../gpu/drm/i915/display/intel_dp_link_training.c| 12 +++-
> From: Tvrtko Ursulin
>
> According to the comment in i915_gem_object_can_bypass_llc the
> purpose of the function is to return false if the platform/object
> has a caching mode where GPU can bypass the LLC.
>
> So far the only platforms which allegedly can do this are Jasperlake
> and
[snip]
> @@ -326,10 +330,10 @@ int i915_gem_get_caching_ioctl(struct drm_device *dev,
> void *data,
> goto out;
> }
>
> - if (i915_gem_object_has_cache_level(obj, I915_CACHE_LLC) ||
> - i915_gem_object_has_cache_level(obj, I915_CACHE_L3_LLC))
> + if
> -Original Message-
> From: Intel-gfx On Behalf Of
> Animesh Manna
> Sent: Thursday, November 10, 2022 8:33 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 4/4] drm/i915/panelreplay: enable/disable panel
> replay
>
> TRANS_DP2_CTL register is programmed to
> -Original Message-
> From: Intel-gfx On Behalf Of
> Animesh Manna
> Sent: Thursday, November 10, 2022 8:33 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 3/4] drm/i915/panelreplay: Initializaton and
> compute config for panel replay
>
> As panel replay feature
> -Original Message-
> From: Intel-gfx On Behalf Of
> Animesh Manna
> Sent: Thursday, November 10, 2022 8:33 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 2/4] drm/i915/panelreplay: Added
> HAS_PANEL_REPLAY() macro
>
> Platforms having Display 13 and above will
> -Original Message-
> From: Intel-gfx On Behalf Of
> Animesh Manna
> Sent: Thursday, November 10, 2022 8:33 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 1/4] drm/i915/panelreplay: dpcd register
> definition for panelreplay
>
> DPCD register definition added to
> -Original Message-
> From: Intel-gfx On Behalf Of Ankit
> Nautiyal
> Sent: Thursday, July 13, 2023 4:04 PM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 08/19] drm/i915/dp: Remove extra logs for
> printing DSC info
>
> DSC
> -Original Message-
> From: Intel-gfx On Behalf Of Ankit
> Nautiyal
> Sent: Thursday, July 13, 2023 4:03 PM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 02/19] drm/i915/dp: Move compressed bpp check
> with 420 format inside the
== Series Details ==
Series: dma-buf/dma-resv: Stop leaking on krealloc() failure
URL : https://patchwork.freedesktop.org/series/120699/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13384_full -> Patchwork_120699v1_full
== Series Details ==
Series: series starting with [RFC,1/2] drm/i915: Refactor PAT/object cache
handling
URL : https://patchwork.freedesktop.org/series/120686/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13384_full -> Patchwork_120686v1_full
== Series Details ==
Series: eventfd: simplify signal helpers
URL : https://patchwork.freedesktop.org/series/120668/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13383_full -> Patchwork_120668v1_full
Summary
---
== Series Details ==
Series: dma-buf/dma-resv: Stop leaking on krealloc() failure
URL : https://patchwork.freedesktop.org/series/120699/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13384 -> Patchwork_120699v1
Summary
== Series Details ==
Series: fix DRM_USE_DYNAMIC_DEBUG regression (rev2)
URL : https://patchwork.freedesktop.org/series/113363/
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: fix DRM_USE_DYNAMIC_DEBUG regression (rev2)
URL : https://patchwork.freedesktop.org/series/113363/
State : warning
== Summary ==
Error: dim checkpatch failed
075f00fa91b5 drm: use correct ccflags-y syntax
da5e4e98a0f2 test-dyndbg: fixup CLASSMAP usage error
== Series Details ==
Series: series starting with [RFC,1/2] drm/i915: Refactor PAT/object cache
handling
URL : https://patchwork.freedesktop.org/series/120686/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13384 -> Patchwork_120686v1
From: Ville Syrjälä
Currently dma_resv_get_fences() will leak the previously
allocated array if the fence iteration got restarted and
the krealloc_array() fails.
Free the old array by hand, and make sure we still clear
the returned *fences so the caller won't end up accessing
freed memory. Some
== Series Details ==
Series: series starting with [RFC,1/2] drm/i915: Refactor PAT/object cache
handling
URL : https://patchwork.freedesktop.org/series/120686/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked
== Series Details ==
Series: series starting with [RFC,1/2] drm/i915: Refactor PAT/object cache
handling
URL : https://patchwork.freedesktop.org/series/120686/
State : warning
== Summary ==
Error: dim checkpatch failed
49bef4e97877 drm/i915: Refactor PAT/object cache handling
Traceback (most
On 7/13/23 09:36, Jim Cromie wrote:
> Add some basic info on classmap usage and api
>
> Signed-off-by: Jim Cromie
> ---
> .../admin-guide/dynamic-debug-howto.rst | 64 ++-
> 1 file changed, 63 insertions(+), 1 deletion(-)
>
> diff --git
Hi Jim,
On 7/13/23 09:36, Jim Cromie wrote:
> Signed-off-by: Jim Cromie
> ---
> lib/Kconfig.debug | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index d4fbbcc395d2..82d11ac63758 100644
> --- a/lib/Kconfig.debug
> +++
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Do not use stolen on MTL
URL : https://patchwork.freedesktop.org/series/120683/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13384 -> Patchwork_120683v1
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Do not use stolen on MTL
URL : https://patchwork.freedesktop.org/series/120683/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On Wed, Jul 12, 2023 at 04:34:15PM -0700, Matt Atwood wrote:
> Wa_14011274333 applies to RKL, ADL-S, ADL-P and TGL. ALlocate buffer
> pinned to GGTT and add WA to restore impacted registers.
You should explain the approach you're taking to implement this
workaround since someone reading the
Hi Jim
On Thu, Jul 13, 2023 at 10:36:23AM -0600, Jim Cromie wrote:
> We currently have 3 defns for __UNIQUE_ID(); gcc and clang are using
> __COUNTER__ for real uniqueness, 3rd just uses __LINE__, which should
> fail on this (and harder to avoid situations):
>
> DECLARE_FOO(); DECLARE_FOO();
>
On Thu, 13 Jul 2023 12:05:36 +0200
Christian Brauner wrote:
> Hey everyone,
>
> This simplifies the eventfd_signal() and eventfd_signal_mask() helpers
> by removing the count argument which is effectively unused.
We have a patch under review which does in fact make use of the
signaling value:
== Series Details ==
Series: eventfd: simplify signal helpers
URL : https://patchwork.freedesktop.org/series/120668/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13383 -> Patchwork_120668v1
Summary
---
**SUCCESS**
== Series Details ==
Series: eventfd: simplify signal helpers
URL : https://patchwork.freedesktop.org/series/120668/
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: eventfd: simplify signal helpers
URL : https://patchwork.freedesktop.org/series/120668/
State : warning
== Summary ==
Error: dim checkpatch failed
aae8a1d97489 eventfd: simplify eventfd_signal()
-:436: WARNING:SUSPECT_CODE_INDENT: suspect code indent for
On Tue, 11 Jul 2023, Gustavo Sousa wrote:
> Quoting Jani Nikula (2023-07-11 08:02:14-03:00)
>>This reverts commit 88e9664434c994e97a9f6f8cdd1535495c660cea.
>>
>>__diag_ignore_all() only works for GCC 8 or later.
>>
>>-Woverride-init (from -Wextra, enabled in i915 Makefile) combined with
Signed-off-by: Jim Cromie
---
lib/Kconfig.debug | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index d4fbbcc395d2..82d11ac63758 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -2696,13 +2696,14 @@ config TEST_STATIC_KEYS
Add a DRM_CLASSMAP_USE declaration to 2nd batch of helpers and *_drv.c
files. For drivers, add the decl just above the module's PARAMs,
since it identifies the "inherited" drm.debug param.
Note: with CONFIG_DRM_USE_DYNAMIC_DEBUG=y, a module not also declaring
DRM_CLASSMAP_USE will have its
Add some basic info on classmap usage and api
Signed-off-by: Jim Cromie
---
.../admin-guide/dynamic-debug-howto.rst | 64 ++-
1 file changed, 63 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst
We currently have 3 defns for __UNIQUE_ID(); gcc and clang are using
__COUNTER__ for real uniqueness, 3rd just uses __LINE__, which should
fail on this (and harder to avoid situations):
DECLARE_FOO(); DECLARE_FOO();
Its 2023, can we haz a no-fallback __UNIQUE_ID ?
NOTE:
This also changes
Lots of burn-in testing needed before signing, upstreaming.
I set default Y to maximize testing by default.
NOTE: without __UNIQUE_ID fix in HEAD~1, this population of
DRM_CLASSMAP_USE()rs experienced name collisions in several different
@lkp-robot allyes and randconfigs, probably because the
To make the 2 test modules buildable with CONFIG_DYNAMIC_DEBUG_CORE,
add CFLAGS_$ofile defns to supply -DDYNAMIC_DEBUG_MODULE to cc.
And change the Kconfig entry to allow building with just _CORE.
Signed-off-by: Jim Cromie
---
lib/Kconfig.debug | 10 +-
lib/Makefile | 2 ++
2
move macro from test-dynamic-debug.c into header, and refine it.
Distinguish the 2 use cases of DYNDBG_CLASSMAP_PARAM*
1.DYNDBG_CLASSMAP_PARAM_REF
for DRM, to pass in extern __drm_debug by name.
dyndbg keeps bits in it, so drm can still use it as before/remaining.
Extract input validation code, from param_set_dyndbg_module_classes()
(the sys-node >handler) to new: ddebug_classparam_clamp_input(kp),
call it from former. It takes kernel-param arg, so it can complain
about "foo: bad input".
Reuse ddparam_clamp_input(kp) in ddebug_sync_classbits(),
to
DECLARE_DYNDBG_CLASSMAP() has a design error; it fails a basic K
rule: "define once, refer many times".
When DRM_USE_DYNAMIC_DEBUG=y, DECLARE_DYNDBG_CLASSMAP() is used across
DRM core & drivers; they all repeat the same classmap-defn args, which
must match for the modules to respond together when
Remove the NAMED class types; these 2 classmap types accept class
names at the PARAM interface, for example:
echo +DRM_UT_CORE,-DRM_UT_KMS > /sys/module/drm/parameters/debug_names
The code works, but its only used by test-dynamic-debug, and wasn't
asked for by anyone else, so simplify things
old_bits arg is currently a pointer to the input bits, but this could
allow inadvertent changes to the input by the fn. Disallow this.
And constify new_bits while here.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 21 +++--
1 file changed, 11 insertions(+), 10
check for actual changes before announcing them, declutter logs.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 2a5cbb68d88d..a8973d1a6896 100644
---
Change function's 1st arg-type, and deref in the caller.
The fn doesn't need any other fields in the struct.
no functional change.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/dynamic_debug.c
currently, for verbose=3, these are logged (blank lines for clarity):
dyndbg: query 0: "class DRM_UT_CORE +p" mod:*
dyndbg: split into words: "class" "DRM_UT_CORE" "+p"
dyndbg: op='+'
dyndbg: flags=0x1
dyndbg: *flagsp=0x1 *maskp=0x
dyndbg: parsed: func="" file="" module=""
ARRAY_SIZE works here, since array decl is complete.
no functional change
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index
Add query_module param to ddebug_apply_class_bitmap(). This allows
its caller to update just one module, or all (as currently). We'll
use this later to propagate drm.debug to each USEr as they're
modprobed.
No functional change.
Signed-off-by: Jim Cromie
---
after `modprobe i915`, heres the
rename param_set_dyndbg_classes: add _module_ name & arg, old name is
wrapper to new. New arg allows caller to specify that only one module
is affected by a prdbgs update.
Outer fn preserves kernel_param interface, passing NULL to inner fn.
This selectivity will be used later to narrow the scope
Classmaps are stored/linked in a section/array, but are each added to
the module's ddebug_table.maps list-head.
This is unnecessary; even when ddebug_attach_classmap() is handling
the builtin section (with classmaps for multiple builtin modules), its
contents are ordered, so a module's possibly
Incorrect CFLAGS- usage failed to add -DDYNAMIC_DEBUG_MODULE,
which broke builds with:
CONFIG_DRM_USE_DYNAMIC_DEBUG=y
CONFIG_DYNAMIC_DEBUG_CORE=y
but without DYNAMIC_DEBUG
Nobody noticed because a larger regression emerged.
Also add subdir-ccflags so that all drivers pick up the addition.
struct ddebug_class_param keeps a ref to the state-storage of the
param, make both flavors use the same unsigned long under-type.
ISTM this is simpler and safer.
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 2 +-
lib/dynamic_debug.c | 2 +-
2 files changed, 2
more careful reading of test output reveals:
lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing
categories\n"
lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n"
class:MID
lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI
hi Jason, Daniel, Greg, etal
Heres another run at the regression, adequately explained in V3 here:
https://lore.kernel.org/lkml/20230125203743.564009-1-jim.cro...@gmail.com/
https://patchwork.freedesktop.org/series/113363/
V3 exposed an init-ordering issue with jump-label, fixed by Jason with
> -Original Message-
> From: Nikula, Jani
> Sent: Thursday, July 13, 2023 6:39 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915: Allow panel drrs modes to have
> differing sync polarities
>
> On Wed, 12 Jul 2023, "Srinivas,
From: Tvrtko Ursulin
Commit 9275277d5324 ("drm/i915: use pat_index instead of cache_level") has
introduced PAT indices to i915 internal APIs, partially replacing the
usage of driver internal cache_level, but has also added a few
questionable design decisions which this patch tries to improve
From: Tvrtko Ursulin
According to the comment in i915_gem_object_can_bypass_llc the purpose of
the function is to return false if the platform/object has a caching mode
where GPU can bypass the LLC.
So far the only platforms which allegedly can do this are Jasperlake and
Elkhartlake, and that
== Series Details ==
Series: DSC misc fixes (rev4)
URL : https://patchwork.freedesktop.org/series/117662/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13380_full -> Patchwork_117662v4_full
Summary
---
**FAILURE**
On 7/13/2023 4:56 PM, Andrzej Hajda wrote:
On 13.07.2023 16:45, Nirmoy Das wrote:
On 7/12/2023 12:06 AM, Nirmoy Das wrote:
Use smem on MTL due to a HW bug in MTL that prevents
reading from stolen memory using LMEM BAR.
v2: improve stolen skip detection(Andrzej)
Cc: Oak Zeng
Cc: Jani
Use smem on MTL due to a HW bug in MTL that prevents
reading from stolen memory using LMEM BAR.
Cc: Oak Zeng
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Andi Shyti
Cc: Andrzej Hajda
Signed-off-by: Nirmoy Das
Reviewed-by: Oak Zeng
Reviewed-by: Andrzej Hajda
Reviewed-by: Andi Shyti
---
Use smem on MTL due to a HW bug in MTL that prevents
reading from stolen memory using LMEM BAR.
v2 and v3: improve stolen skip detection(Andrzej)
Cc: Oak Zeng
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Andi Shyti
Cc: Andrzej Hajda
Signed-off-by: Nirmoy Das
Reviewed-by: Oak Zeng
Reviewed-by:
On 13.07.2023 16:45, Nirmoy Das wrote:
On 7/12/2023 12:06 AM, Nirmoy Das wrote:
Use smem on MTL due to a HW bug in MTL that prevents
reading from stolen memory using LMEM BAR.
v2: improve stolen skip detection(Andrzej)
Cc: Oak Zeng
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Andi Shyti
On Thu, Jul 13, 2023 at 07:33:05AM -0700, Sean Christopherson wrote:
> On Thu, Jul 13, 2023, Christian Brauner wrote:
> > diff --git a/fs/eventfd.c b/fs/eventfd.c
> > index dc9e01053235..077be5da72bd 100644
> > --- a/fs/eventfd.c
> > +++ b/fs/eventfd.c
> > @@ -43,9 +43,10 @@ struct eventfd_ctx {
>
On 7/12/2023 12:06 AM, Nirmoy Das wrote:
Use smem on MTL due to a HW bug in MTL that prevents
reading from stolen memory using LMEM BAR.
v2: improve stolen skip detection(Andrzej)
Cc: Oak Zeng
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Andi Shyti
Cc: Andrzej Hajda
Signed-off-by: Nirmoy Das
On Thu, Jul 13, 2023, Christian Brauner wrote:
> diff --git a/fs/eventfd.c b/fs/eventfd.c
> index dc9e01053235..077be5da72bd 100644
> --- a/fs/eventfd.c
> +++ b/fs/eventfd.c
> @@ -43,9 +43,10 @@ struct eventfd_ctx {
> int id;
> };
>
> -__u64 eventfd_signal_mask(struct eventfd_ctx *ctx,
Hi Andi,
On 7/13/2023 2:31 PM, Andi Shyti wrote:
Hi Nirmoy and Jonathan,
@@ -202,6 +202,13 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
{
struct intel_engine_cs *engine = rq->engine;
+ /*
+* Aux invalidations on Aux CCS platforms require
+*
-Original Message-
From: Nirmoy Das
Sent: Thursday, July 13, 2023 7:12 AM
To: Andi Shyti
Cc: Cavitt, Jonathan ; Intel GFX
; Roper, Matthew D
; Chris Wilson ; Mika
Kuoppala
Subject: Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/gt: Ensure memory quiesced
before invalidation
>
>Hi Andi,
>
On Thu, Jul 13, 2023 at 1:06 PM Christian Brauner wrote:
>
> Ever since the evenfd type was introduced back in 2007 in commit
> e1ad7468c77d ("signal/timer/event: eventfd core") the eventfd_signal()
> function only ever passed 1 as a value for @n. There's no point in
> keeping that additional
For vfio_ap_ops.c:
Reviewed-by: Tony Krowiak
On 7/13/23 6:05 AM, Christian Brauner wrote:
Ever since the evenfd type was introduced back in 2007 in commit
e1ad7468c77d ("signal/timer/event: eventfd core") the eventfd_signal()
function only ever passed 1 as a value for @n. There's no point in
On Thu, 13 Jul 2023, Suraj Kandpal wrote:
> Up until now we only verified one or two of the dsc pps
> params like bits_per_component and bits_per_pixel this
> patch series aim to readout almost all PPS param and get
> them compared.
> Along with that some work on making a common function to
>
On 7/13/2023 6:17 PM, Jani Nikula wrote:
On Thu, 13 Jul 2023, Suraj Kandpal wrote:
Add function to read any PPS register based on the
intel_dsc_pps enum provided. Add a function which will call the
new pps read function and place it in crtc state. Only PPS0 and
PPS1 are readout the rest of
On Wed, 12 Jul 2023, "Srinivas, Vidya" wrote:
>> -Original Message-
>> From: Nikula, Jani
>> Sent: Wednesday, July 12, 2023 1:44 PM
>> To: Srinivas, Vidya ; intel-
>> g...@lists.freedesktop.org
>> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Allow panel drrs modes to have
>> differing sync
> On Thu, 13 Jul 2023, Suraj Kandpal wrote:
> > Add function to read any PPS register based on the intel_dsc_pps enum
> > provided. Add a function which will call the new pps read function and
> > place it in crtc state. Only PPS0 and
> > PPS1 are readout the rest of the registers will be read
> On Thu, 13 Jul 2023, Suraj Kandpal wrote:
> > In intel_vdsc_get_config we only read the primary dsc engine register
> > and not take into account if the other dsc engine is in use and if
> > both registers have the same value or not this patche fixes that by
> > adding a check.
> >
> >
On Thu, 13 Jul 2023, Jani Nikula wrote:
> On Thu, 13 Jul 2023, "Bhadane, Dnyaneshwar"
> wrote:
>>> -Original Message-
>>> From: Tvrtko Ursulin
>>> Sent: Thursday, July 13, 2023 5:55 PM
>>> To: Bhadane, Dnyaneshwar ; Jani Nikula
>>> ; intel-gfx@lists.freedesktop.org; Ursulin,
>>> Tvrtko
On Thu, 13 Jul 2023, "Bhadane, Dnyaneshwar"
wrote:
>> -Original Message-
>> From: Tvrtko Ursulin
>> Sent: Thursday, July 13, 2023 5:55 PM
>> To: Bhadane, Dnyaneshwar ; Jani Nikula
>> ; intel-gfx@lists.freedesktop.org; Ursulin,
>> Tvrtko
>> Cc: Srivatsa, Anusha ; Shankar, Uma
>>
>>
Hi Uwe,
Let's add some fuel to keep the thread alive ;-)
On Wed, Jul 12, 2023 at 6:13 PM Uwe Kleine-König
wrote:
> On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> > On Wed, 12 Jul 2023, Uwe Kleine-König
> > wrote:
> > > Hello,
> > >
> > > while I debugged an issue in the
On 2023-07-12 09:53, Christian König wrote:
> Am 12.07.23 um 15:38 schrieb Uwe Kleine-König:
>> Hello Maxime,
>>
>> On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote:
>>> On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
> Background is that this makes merge
On Wed, Jul 12, 2023 at 12:46:33PM +0200, Christian König wrote:
> Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
> > Hello,
> >
> > while I debugged an issue in the imx-lcdc driver I was constantly
> > irritated about struct drm_device pointer variables being named "dev"
> > because with that
Hi
Am 12.07.23 um 18:10 schrieb Uwe Kleine-König:
Hello Jani,
On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
Hello,
while I debugged an issue in the imx-lcdc driver I was constantly
irritated about struct drm_device pointer
Hello Jani,
On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> > Hello,
> >
> > while I debugged an issue in the imx-lcdc driver I was constantly
> > irritated about struct drm_device pointer variables being named "dev"
> > because with
On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> Hello Jani,
>
> On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
>> On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
>> > Hello,
>> >
>> > while I debugged an issue in the imx-lcdc driver I was constantly
>> > irritated about struct
Am 12.07.23 um 15:38 schrieb Uwe Kleine-König:
Hello Maxime,
On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote:
On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
Background is that this makes merge conflicts easier to handle and detect.
Really?
FWIW, I agree with
Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
Hello,
while I debugged an issue in the imx-lcdc driver I was constantly
irritated about struct drm_device pointer variables being named "dev"
because with that name I usually expect a struct device pointer.
I think there is a big benefit when
Hi
Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
Hello,
while I debugged an issue in the imx-lcdc driver I was constantly
irritated about struct drm_device pointer variables being named "dev"
because with that name I usually expect a struct device pointer.
Rather than renaming dev in all
On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> Hello,
>
> while I debugged an issue in the imx-lcdc driver I was constantly
> irritated about struct drm_device pointer variables being named "dev"
> because with that name I usually expect a struct device pointer.
>
> I think there is a big benefit
On Tue, 27 Jun 2023 16:43:15 +0200, Julia Lawall wrote:
> The functions vmalloc_array and vcalloc were introduced in
>
> commit a8749a35c399 ("mm: vmalloc: introduce array allocation functions")
>
> but are not used much yet. This series introduces uses of
> these functions, to protect against
Ever since the evenfd type was introduced back in 2007 in commit
e1ad7468c77d ("signal/timer/event: eventfd core") the eventfd_signal()
function only ever passed 1 as a value for @n. There's no point in
keeping that additional argument.
Signed-off-by: Christian Brauner
---
arch/x86/kvm/hyperv.c
On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> On Wed, Jul 12, 2023 at 12:46:33PM +0200, Christian König wrote:
> > Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
> > > Hello,
> > >
> > > while I debugged an issue in the imx-lcdc driver I was constantly
> > > irritated about struct drm_device
Hello Maxime,
On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote:
> On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
> > > Background is that this makes merge conflicts easier to handle and detect.
> >
> > Really?
>
> FWIW, I agree with Christian here.
>
> > Each
On Wed, Jul 12, 2023 at 10:52 AM Jani Nikula wrote:
>
> On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> > Hello,
> >
> > while I debugged an issue in the imx-lcdc driver I was constantly
> > irritated about struct drm_device pointer variables being named "dev"
> > because with that name I usually
Hello Thomas,
On Wed, Jul 12, 2023 at 12:19:37PM +0200, Thomas Zimmermann wrote:
> Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
> > Hello,
> >
> > while I debugged an issue in the imx-lcdc driver I was constantly
> > irritated about struct drm_device pointer variables being named "dev"
> >
Hi
Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
Hello,
while I debugged an issue in the imx-lcdc driver I was constantly
irritated about struct drm_device pointer variables being named "dev"
because with that name I usually expect a struct device pointer.
I think there is a big benefit when
On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
> > Background is that this makes merge conflicts easier to handle and detect.
>
> Really?
FWIW, I agree with Christian here.
> Each file (apart from include/drm/drm_crtc.h) is only touched once. So
> unless I'm missing something
Hello,
while I debugged an issue in the imx-lcdc driver I was constantly
irritated about struct drm_device pointer variables being named "dev"
because with that name I usually expect a struct device pointer.
I think there is a big benefit when these are all renamed to "drm_dev".
I have no strong
On Thu, Jul 13, 2023 at 08:52:12AM +0200, Geert Uytterhoeven wrote:
> Hi Uwe,
>
> Let's add some fuel to keep the thread alive ;-)
>
> On Wed, Jul 12, 2023 at 6:13 PM Uwe Kleine-König
> wrote:
> > On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> > > I think this is an unnecessary
The eventfd_signal_mask() helper was introduced for io_uring and similar
to eventfd_signal() it always passed 1 for @n. So don't bother with that
argument at all.
Signed-off-by: Christian Brauner
---
drivers/gpu/drm/i915/gvt/interrupt.c | 2 +-
fs/eventfd.c | 9 +
On 12/07/2023 20:31, Sean Paul wrote:
>>> 216 struct drm_device *ddev
>>> 234 struct drm_device *drm_dev
>>> 611 struct drm_device *drm
>>>4190 struct drm_device *dev
>>>
>>> This series starts with renaming struct drm_crtc::dev to drm_dev. If
>>> it's not only me and others like
On Thu, Jul 13, 2023 at 12:03:05PM +0300, Jani Nikula wrote:
> On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> > Hello Jani,
> >
> > On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> >> On Wed, 12 Jul 2023, Uwe Kleine-König
> >> wrote:
> >> > Hello,
> >> >
> >> > while I debugged an
Hi Uwe,
On Wed 12 Jul 23, 11:46, Uwe Kleine-König wrote:
> Hello,
>
> while I debugged an issue in the imx-lcdc driver I was constantly
> irritated about struct drm_device pointer variables being named "dev"
> because with that name I usually expect a struct device pointer.
Well personally I
Hey everyone,
This simplifies the eventfd_signal() and eventfd_signal_mask() helpers
by removing the count argument which is effectively unused.
---
---
base-commit: 6be357f00aad4189130147fdc6f568cf776a4909
change-id: 20230713-vfs-eventfd-signal-0b0d167ad6ec
Hi Jani,
On Thu, Jul 13, 2023 at 11:03 AM Jani Nikula wrote:
> On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> > On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> >> On Wed, 12 Jul 2023, Uwe Kleine-König
> >> wrote:
> >> > while I debugged an issue in the imx-lcdc driver I was
1 - 100 of 159 matches
Mail list logo
