On Wed, 22 Mar 2023 at 19:04, Zongmin Zhou wrote:
>
> The allocated memory for qdev->dumb_heads should be released
> in qxl_destroy_monitors_object before qxl suspend.
> otherwise,qxl_create_monitors_object will be called to
> reallocate memory for qdev->dumb_heads after qxl resume,
> it will
ni_patch_single_dependency_table_based_on_leakage() return zero or
negative error code. But ni_patch_dependency_tables_based_on_leakage()
doesn't check the return value of the first function call. It's same for
ni_dpm_init(). It's better to add this error code check.
Signed-off-by: Su Hui
---
-tip
next-20231031]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Tatsuyuki-Ishi
Hi Sui,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.6 next-20231031]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
On Wed, 1 Nov 2023 at 11:46, Luben Tuikov wrote:
>
> On 2023-10-31 09:33, Danilo Krummrich wrote:
> >
> > On 10/26/23 19:25, Luben Tuikov wrote:
> >> On 2023-10-26 12:39, Danilo Krummrich wrote:
> >>> On 10/23/23 05:22, Luben Tuikov wrote:
> The GPU scheduler has now a variable number of
Hi Luben,
On Tue, Oct 31, 2023 at 08:51:17PM -0400, Luben Tuikov wrote:
> Hi,
>
> (PSA: luben.tui...@amd.com should've bounced :-) I'm removing it from the To:
> field.)
>
> On 2023-10-30 20:26, Danilo Krummrich wrote:
> > Currently, job flow control is implemented simply by limiting the
On Tue, Oct 31, 2023 at 03:36:30PM -0300, Helen Koike wrote:
>
>
> On 30/10/2023 08:36, Bagas Sanjaya wrote:
> > On 30/10/2023 13:12, Julia Lawall wrote:
> > >
> > >
> > > On Mon, 30 Oct 2023, Bagas Sanjaya wrote:
> > >
> > > > Hi Julia,
> > > >
> > > > The submitter touched one of CI
On 2023-10-31 09:33, Danilo Krummrich wrote:
>
> On 10/26/23 19:25, Luben Tuikov wrote:
>> On 2023-10-26 12:39, Danilo Krummrich wrote:
>>> On 10/23/23 05:22, Luben Tuikov wrote:
The GPU scheduler has now a variable number of run-queues, which are set
up at
drm_sched_init() time.
-tip
next-20231031]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Tatsuyuki-Ishi
Hi,
(PSA: luben.tui...@amd.com should've bounced :-) I'm removing it from the To:
field.)
On 2023-10-30 20:26, Danilo Krummrich wrote:
> Currently, job flow control is implemented simply by limiting the number
> of jobs in flight. Therefore, a scheduler is initialized with a credit
> limit that
Lots of burn-in testing needed before signing, upstreaming.
NOTE: I set default Y to maximize testing by default.
Is there a better way to do this ?
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
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
Incorrectly spelled CFLAGS- failed to add -DDYNAMIC_DEBUG_MODULE,
which broke builds with:
CONFIG_DRM_USE_DYNAMIC_DEBUG=y
CONFIG_DYNAMIC_DEBUG_CORE=y
CONFIG_DYNAMIC_DEBUG=n
Also add subdir-ccflags so that all drivers pick up the addition.
Fixes: 84ec67288c10 ("drm_print: wrap drm_*_dbg in
dyndbg's dynamic prefixing (by +tmfsl flags) is needlessly expensive.
When an enabled (with +p) pr_debug is called, _DPRINTK_FLAGS_INCL_ANY
prefix decorations are sprintf'd into stack-mem for every call.
This string (or part of it) could be cached once its 1st generated,
and retrieved
Refactor the split of duties between outer & inner fns.
The outer fn was previously just an inline unlikely forward to inner,
which did all the work.
Now, outer handles +t and +l flags itself, and calls inner only when
_DPRINTK_FLAGS_INCL_LOOKUP is needed.
No functional change.
But it does
Reserve bit 7 to remember that a pr-debug callsite is/was:
- enabled, with +p
- wants a dynamic-prefix, with one+ of module:function:sourcfile
- was previously called
- was thus saved in the cache. NOT YET.
Its unclear whether any cache fetch would be faster than 2-3 field
fetches, but theres
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
Add some basic info on classmap usage and api
cc: linux-...@vger.kernel.org
Signed-off-by: Jim Cromie
---
v5- adjustments per Randy Dunlap, me
v7b- checkpatch fixes
---
.../admin-guide/dynamic-debug-howto.rst | 60 ++-
1 file changed, 59 insertions(+), 1 deletion(-)
diff
move the DYNDBG_CLASSMAP_PARAM macro from test-dynamic-debug.c into
the header, and refine it, by distinguishing the 2 use cases:
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
2.DYNDBG_CLASSMAP_PARAM
DECLARE_DYNDBG_CLASSMAP() has a design error; its usage 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
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
The fn currently says "add-module", then "skipping" if the module has
no prdbgs. Just check 1st and return quietly.
no functional change
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/lib/dynamic_debug.c
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 b0e11f6bfaa2..b07aab422604 100644
---
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
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
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
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
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
This appears in the control-file to report an unknown class-name, which
indicates that the class_id is not authorized, and dyndbg will ignore
changes to it. Generally, this means that a DYNDBG_CLASSMAP_DEFINE or
DYNDBG_CLASSMAP_USE is missing.
But the word "unknown" appears in quite a few prdbg
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, DRM-folk
(v7d - refreshed onto v6.6, patch-21 squashed into 14)
This patchest fixes the chicken-egg initialization problem in the 1st
version of ddebug-class-maps, that DRM-CI uncovered.
The root-problem was DECLARE_DYNDBG_CLASSMAP, which broke the K rule:
"define once, refer many".
Hi Tatsuyuki,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.6 next-20231031
On Sun, Oct 22, 2023 at 08:02:36PM +0200, Thomas Hellström wrote:
> Add the first version of the VM_BIND locking document which is
> intended to be part of the xe driver upstreaming agreement.
>
> The document describes and discuss the locking used during exec-
> functions, evicton and for
On Fri, 2023-10-27 at 10:13 +0300, Jani Nikula wrote:
> On Thu, 26 Oct 2023, Zhanjun Dong wrote:
>
alan:snip
> I'll note that nobody checks intel_pxp_init() return status, so this
> silently skips PXP.
>
> BR,
> Jani.
alan:snip
> > + if (intel_gt_is_wedged(gt))
> > + return
Hi,
On 10/31/23 17:07, Hans de Goede wrote:
> Hi Andy,
>
> On 10/24/23 18:11, Andy Shevchenko wrote:
>> On Tue, Oct 24, 2023 at 06:57:38PM +0300, Andy Shevchenko wrote:
>>> It's a dirty hack in the driver that pokes GPIO registers behind
>>> the driver's back. Moreoever it might be problematic
On Wed, 2023-11-01 at 05:29 +1000, Dave Airlie wrote:
> >
> > static const struct nv_gsp_registry_entries r535_registry_entries[] = {
> > { "RMSecBusResetEnable", 1 },
> > { "RMForcePcieConfigSave", 1 },
> > };
> >
> > #define NV_GSP_REG_NUM_ENTRIES
On Tue, Oct 31, 2023 at 1:09 PM José Pekkarinen
wrote:
>
> Reported by coccinelle, the following patch will move the
> following 1 element arrays to flexible arrays.
>
> drivers/gpu/drm/radeon/atombios.h:5523:32-48: WARNING use flexible-array
> member instead
>
On Wed, 1 Nov 2023 at 01:53, Timur Tabi wrote:
>
> On Tue, Oct 31, 2023 at 12:20 AM Dave Airlie wrote:
> > +#define NV_GSP_REG_NUM_ENTRIES 2
> > +
> > +static const struct nv_gsp_registry_entries
> > r535_registry_entries[NV_GSP_REG_NUM_ENTRIES] = {
> > + { "RMSecBusResetEnable", 1 },
> >
On 10/31/23 15:16, Emma Anholt wrote:
I am not active in the Linux kernel and don't want to see patches.
Signed-off-by: Emma Anholt
Acked-by: Maíra Canal
Best Regards,
- Maíra
---
MAINTAINERS | 4
1 file changed, 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index
On 30/10/2023 08:36, Bagas Sanjaya wrote:
On 30/10/2023 13:12, Julia Lawall wrote:
On Mon, 30 Oct 2023, Bagas Sanjaya wrote:
Hi Julia,
The submitter touched one of CI scripts for the DRM subsystem. To test
this patch, there must be a way to run these scripts locally (which
may requires
I am not active in the Linux kernel and don't want to see patches.
Signed-off-by: Emma Anholt
---
MAINTAINERS | 4
1 file changed, 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 01fb9ee6b951..31854c48711e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5378,7 +5378,6 @@ T:
On Mon, Oct 30, 2023 at 6:23 PM Bjorn Andersson
wrote:
>
> During USB transfers on the SC8280XP __arm_smmu_tlb_sync() is seen to
> typically take 1-2ms to complete. As expected this results in poor
> performance, something that has been mitigated by proposing running the
> iommu in non-strict
ut format negotiation hook
>
> Tomi Valkeinen (1):
> drm/bridge: tc358767: Fix link properties discovery
>
> drivers/gpu/drm/bridge/tc358767.c | 32
> 1 file changed, 32 insertions(+)
> ---
> base-commit: 79d94360d50fcd487edcfe11
On Tue, 31 Oct 2023 16:33:44 +0800, Moudy Ho wrote:
> Added the configuration for MT8195 RDMA. In comparison to MT8183, it
> no longer shares SRAM with RSZ, and there are now preconfigured 5 mbox.
>
> Signed-off-by: Moudy Ho
> Reviewed-by: AngeloGioacchino Del Regno
>
> ---
>
Issues were reported with commit 1cfb4d612127
("drm/amdgpu: put MQDs in VRAM") on an ADLINK Ampere
Altra Developer Platform (AVA developer platform).
Various ARM systems seem to have problems related
to PCIe and MMIO access. In this case, I'm not sure
if this is specific to the ADLINK platform
On Tue, 31 Oct 2023 16:33:43 +0800, Moudy Ho wrote:
> To simplify maintenance and avoid branches, the identical component
> should be merged and placed in the path belonging to the MDP
> (from display/* to media/*).
>
> In addition, currently only MDP utilizes RDMA through CMDQ, and the
>
Hi,
I would like to ask the device tree maintainers if you are willing
to take this through your tree or should I push the entire series
through drm-misc/drm-misc-next.
Best Regards,
- Maíra
On 10/31/23 04:38, Iago Toral Quiroga wrote:
BCM2712, Raspberry Pi 5's SoC, contains a V3D core. So
On 10/31/23 17:45, Thomas Hellström wrote:
On Tue, 2023-10-31 at 17:39 +0100, Danilo Krummrich wrote:
On 10/31/23 12:25, Thomas Hellström wrote:
On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
Add an abstraction layer between the drm_gpuva mappings of a
particular
drm_gem_object
On 10/31/23 17:50, Thomas Hellström wrote:
On Tue, 2023-10-31 at 17:30 +0100, Danilo Krummrich wrote:
On 10/31/23 12:45, Jani Nikula wrote:
On Tue, 31 Oct 2023, Thomas Hellström
wrote:
On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
+ * Returns: a pointer to the _gpuvm_bo on
On 10/31/23 11:32, Thomas Hellström wrote:
On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
Add an abstraction layer between the drm_gpuva mappings of a
particular
drm_gem_object and this GEM object itself. The abstraction represents
a
combination of a drm_gem_object and drm_gpuvm.
On 2023-10-31 17:45, Alex Deucher wrote:
On Sat, Oct 28, 2023 at 8:05 AM José Pekkarinen
wrote:
On 2023-10-27 20:55, Deucher, Alexander wrote:
> [Public]
>
>> -Original Message-
>> From: José Pekkarinen
>> Sent: Friday, October 27, 2023 12:59 PM
>> To: Deucher, Alexander ; Koenig,
On Tue, 31 Oct 2023 16:33:57 +0800, Moudy Ho wrote:
> Add a compatible string for the PADDING block in MediaTek MT8195 that
> is controlled by MDP3.
>
> Signed-off-by: Moudy Ho
> ---
> .../bindings/display/mediatek/mediatek,padding.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1
Reported by coccinelle, the following patch will move the
following 1 element arrays to flexible arrays.
drivers/gpu/drm/radeon/atombios.h:5523:32-48: WARNING use flexible-array member
instead
(https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays)
On Tue, Oct 31, 2023 at 08:38:58AM +0100, Iago Toral Quiroga wrote:
> BCM2712, Raspberry Pi 5's SoC, contains a V3D core. So add its specific
> compatible to the bindings.
>
> Signed-off-by: Iago Toral Quiroga
> Reviewed-by: Maíra Canal
Acked-by: Conor Dooley
Thanks,
Conor.
> ---
>
On Tue, 2023-10-31 at 17:41 +0100, Danilo Krummrich wrote:
> On 10/31/23 12:34, Thomas Hellström wrote:
> > On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
> > > Currently the DRM GPUVM offers common infrastructure to track GPU
> > > VA
> > > allocations and mappings, generically
We're not doing anything special in atomic_mode_set so we can simply
merge it into atomic_enable.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 80 ++
1 file changed, 51 insertions(+), 29 deletions(-)
On Tue, 2023-10-31 at 17:30 +0100, Danilo Krummrich wrote:
> On 10/31/23 12:45, Jani Nikula wrote:
> > On Tue, 31 Oct 2023, Thomas Hellström
> > wrote:
> > > On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
> > > > + * Returns: a pointer to the _gpuvm_bo on success, NULL on
> > >
> > >
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 101 ++-
1 file changed, 41 insertions(+), 60 deletions(-)
container_of_const() allows to preserve the pointer constness and is
thus more flexible than inline functions.
Let's switch all our instances of container_of() to container_of_const().
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 16
1 file
The coeff_csc matrix isn't used anymore, let's remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 70
1 file changed, 70 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
The colorimetry field of hdmi_data_info is not used anywhere so we can
get rid of it. This was the last field left in that structure so we can
get rid of it too.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 15 ---
1 file changed, 15 deletions(-)
diff
The inno_hdmi mode_valid implementation always return MODE_OK which is
what the core assumes when we don't have an implementation.
Let's get rid of it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 8
1 file changed, 8 deletions(-)
diff --git
The sun4i_hdmi driver still uses the non-atomic variants of the encoder
hooks, so let's convert to their atomic equivalents.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git
The drm_dev field in the inno_hdmi struct stores a pointer to the DRM
device but is never used anywhere in the driver. Let's remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
atomic_check and mode_valid do not check for the same things which can
lead to surprising result if the userspace commits a mode that didn't go
through mode_valid. Let's merge the two implementations into a function
called by both.
Signed-off-by: Maxime Ripard
---
The new HDMI connector infrastructure allows us to remove a lot of
boilerplate, so let's switch to it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 636 +
drivers/gpu/drm/vc4/vc4_hdmi.h | 44 +--
We're not doing anything special in atomic_mode_set so we can simply
merge it into atomic_enable.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 38 +-
1 file changed, 14 insertions(+), 24 deletions(-)
diff --git
The CSC_* enum has no users left, so let's remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index c342bc8b3a23..f05417c6b637
The code to upload infoframes to the controller uses a weird construct
which, based on the previous function call return code, will either
disable or enable that infoframe.
In order to get rid of that argument, let's split the function to
disable the infoframe into a separate function and make it
The inno_hdmi driver relies on its own internal infoframe type matching
the hardware.
This works fine, but in order to make further reworks easier, let's
switch to the HDMI spec definition of those types.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 71
The register mask and bits to enable or disable a given infoframe
depends on its type.
This is currently passed as an argument to the function that writes an
infoframe, but let's create a helper function to retrieve them based on
the type to make further reworks easier.
Signed-off-by: Maxime
The tmds_rate field in the inno_hdmi structure is used mostly to
configure the internal i2c controller divider through a call to the
inno_hdmi_i2c_init() function.
We can simply make that rate an argument to that function, which also
removes a workaround to initialize the divider at probe time
The inno_hdmi encoder still uses the !atomic variants of enable, disable
and modeset. Convert to their atomic equivalents.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git
The sink_has_audio flag is not used anywhere in the driver so let's get
rid of it. It's redundant with drm_display_info.has_audio anyway.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 2 --
1 file changed, 2 deletions(-)
diff --git
The driver maintains a copy of the adjusted mode but doesn't use it
anywhere. Remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
The driver has a lot of logic to deal with multiple input formats, but
hardcodes it to RGB. This means that most of that code has been dead
code, so let's get rid of it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 39 +---
1 file
The mode's VIC is only ever used in the inno_hdmi_setup() function so
there's no need to store it in the main structure.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git
Similarly to the input format, the driver has a lot of code to deal with
various output format, but the driver hardcodes it to RGB always.
Let's get rid of the dead code.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 57
1 file
The mode_fixup implementation doesn't do anything, so we can simply
remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index
Infoframes in KMS is usually handled by a bunch of low-level helpers
that require quite some boilerplate for drivers. This leads to
discrepancies with how drivers generate them, and which are actually
sent.
Now that we have everything needed to generate them in the HDMI
connector state, we can
A lot of HDMI drivers have some variation of the formula to calculate
the TMDS character rate from a mode, but few of them actually take all
parameters into account.
Let's create a helper to provide that rate taking all parameters into
account.
Signed-off-by: Maxime Ripard
---
Most HDMI drivers have some code to calculate the TMDS character rate,
usually to adjust an internal clock to match what the mode requires.
Since the TMDS character rates mostly depends on the resolution, whether
we need to repeat pixels or not, the bpc count and the format, we can
now derive it
Now that we have all the infrastructure needed, we can add some code
that will, for a given connector state and mode, compute the best output
format and bpc.
The algorithm is the same one than the one already found in i915 and
vc4.
Signed-off-by: Maxime Ripard
---
Even though we were rolling our own custom state for the vc4 HDMI
controller driver, we were still using the generic helper to destroy
that state.
It was mostly working since the underlying state is the first member of
our state so the pointers are probably equal in all relevant cases, but
it's
There has been some discussions recently about the infoframes sent by
drivers and if they were properly generated.
In parallel, there's been some interest in creating an infoframe-decode
tool similar to edid-decode.
Both would be much easier if we were to expose the infoframes programmed
in the
Most of the HDMI controllers have an upper TMDS character rate limit
they can't exceed. On "embedded"-grade display controllers, it will
typically be lower than what high-grade monitors can provide these days,
so drivers will filter the TMDS character rate based on the controller
capabilities.
To
Just like BPC, we'll add support for automatic selection of the output
format for HDMI connectors.
Let's add the needed defaults and fields for now.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c | 2 ++
drivers/gpu/drm/drm_atomic_state_helper.c | 4 +++-
HDMI controller drivers will need to figure out the RGB range they need
to configure based on a mode and property values. Let's expose that in
the HDMI connector state so drivers can just use that value.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c | 4 ++-
We'll add automatic selection of the output BPC in a following patch,
but let's add it to the HDMI connector state already.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c | 1 +
drivers/gpu/drm/drm_atomic_state_helper.c | 8 +++-
drivers/gpu/drm/drm_connector.c
The i915 driver has a property to force the RGB range of an HDMI output.
The vc4 driver then implemented the same property with the same
semantics. KWin has support for it, and a PR for mutter is also there to
support it.
Both drivers implementing the same property with the same semantics,
plus
The next features we will need to share across drivers will need to
store some parameters for drivers to use, such as the selected output
format.
Let's create a new connector state dedicated to HDMI controllers, that
will eventually store everything we need.
Signed-off-by: Maxime Ripard
---
A lot of the various HDMI drivers duplicate some logic that depends on
the HDMI spec itself and not really a particular hardware
implementation.
Output BPC or format selection, infoframe generation are good examples
of such areas.
This creates a lot of boilerplate, with a lot of variations,
Hi,
Here's a series that creates a subclass of drm_connector specifically
targeted at HDMI controllers.
The idea behind this series came from a recent discussion on IRC during
which we discussed infoframes generation of i915 vs everything else.
Infoframes generation code still requires some
On 10/31/23 11:08, Thomas Hellström wrote:
On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
Use drm_WARN() and drm_WARN_ON() variants to indicate drivers the
context the failing VM resides in.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/drm_gpuvm.c | 32
On Tue, 2023-10-31 at 17:39 +0100, Danilo Krummrich wrote:
> On 10/31/23 12:25, Thomas Hellström wrote:
> > On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
> > > Add an abstraction layer between the drm_gpuva mappings of a
> > > particular
> > > drm_gem_object and this GEM object
On 10/31/23 12:34, Thomas Hellström wrote:
On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
Currently the DRM GPUVM offers common infrastructure to track GPU VA
allocations and mappings, generically connect GPU VA mappings to
their
backing buffers and perform more complex mapping
1 - 100 of 244 matches
Mail list logo
