Hi
Am 16.07.22 um 20:17 schrieb Sam Ravnborg:
While discussing the way forward for the via driver
Javier came up with the proposal to move all DRI1 drivers
to their own folder.
The idea is to move the old DRI1 drivers so one do not
accidentally consider them modern drivers.
This set of patches
---
.../drm/nouveau/include/nvkm/core/subdev.h| 2 +-
drivers/gpu/drm/nouveau/nouveau_drm.c | 7 --
drivers/gpu/drm/nouveau/nvkm/core/subdev.c| 23 +++
3 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/core/su
From: "Steven Rostedt (Google)"
There's several places that open code the following logic:
TP_STRUCT__entry(__dynamic_array(char, msg, MSG_MAX)),
TP_fast_assign(vsnprintf(__get_str(msg), MSG_MAX, vaf->fmt, *vaf->va);)
To load a string created by variable array va_list.
The main issue with
Undo the 1-line change that reduced count of prdbgs from 632 to 119.
ie: s/NV_SUBDEV_DBG_##l/NV_DBG_##l/
So heres what happened: new symbol is 15 (or 10), and fails this macro
test, so gets compiled out, and the dev_dbg is excluded.
if (CONFIG_NOUVEAU_DEBUG >= (l) && _subdev->debug >= (l
clone the nvkm_printk,_,__ macro ladder into nvkm_drmdbg,_,__.
And alter debug, trace, spam macros to use the renamed ladder.
This *sets-up* to remove the _subdev->debug >= (l) condition from the
__ macro, once the bitmap-param is wired up correctly (pointing at the
right state-bit-vector), and fi
ddebug_trace() currently issues a single printk:console event.
Replace that, adding include/trace/events/dyndbg.h, which defines 2
new events:
- dyndbg:prdbg - from trace_prdbg() - if !dev
- dyndbg:devdbg - from trace_devdbg() - if !!dev
This links the legacy pr_debug API to tracefs, via dyndbg
Change nvkm_subdev.debug to a ulong, so dyndbg can maybe use it.
Move macro decl from nv-drm.c to subdev.c, and add a struct
ddebug_classes_bitmap_param and a module_param_cb() that creates the
sysfs-knob.
Finally, in nvkm_subdev_ctor(), *attempt* to set dyndbg's pointer to
the debug address, so
Undo the 1-line change that reduced count of prdbgs from 632 to 119.
ie: s/NV_SUBDEV_DBG_##l/NV_DBG_##l/
So heres what happened: new symbol is 15 (or 10), and fails this macro
test, so gets compiled out, and the dev_dbg is excluded.
if (CONFIG_NOUVEAU_DEBUG >= (l) && _subdev->debug >= (l
adds: ddebug_trace()
uses trace_console() temporarily to issue printk:console event
uses internal-ish __ftrace_trace_stack code:
4-context buffer stack, barriers per Steve Rostedt
call it from new funcs:
ddebug_printk() - print to both syslog/tracefs
ddebug_dev_printk() - dev-print to
These 2 macros used drm_debug_enabled() on DRM_UT_{DRIVER,ATOMIC}
respectively, replace those with drm_dbg_##cat invocations.
this results in new class'd prdbg callsites:
:#> grep nouveau /proc/dynamic_debug/control | grep class | wc
1161130 15584
:#> grep nouveau /proc/dynamic_debug/co
In order to use dynamic-debug's jump-label optimization in drm-debug,
its clarifying to refine drm_debug_enabled into 3 uses:
1. drm_debug_enabled - legacy, public
2. __drm_debug_enabled - optimized for dyndbg jump-label enablement.
3. _drm_debug_enabled - pr_debug instrumented, observable
1.
nouveau has additional debug variables to consider:
drivers/gpu/drm/nouveau/include/nvkm/core/device.h
131:if (_device->debug >= (l)) \
drivers/gpu/drm/nouveau/include/nvkm/core/client.h
39: if (_client->debug >= NV_DBG_##l)
add new flag, and OR it into _DPRINTK_FLAGS_ENABLED definition
CC: vincent.whitchu...@axis.com
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 38
nouveau has additional debug variables to consider:
drivers/gpu/drm/nouveau/include/nvkm/core/device.h
131:if (_device->debug >= (l)) \
drivers/gpu/drm/nouveau/include/nvkm/core/client.h
39: if (_client->debug >= NV_DBG_##l)
clone DRM.debug interface to DRM.tracebits: ie map bits to
drm-debug-categories, except this interface enables messages to
tracefs, not to syslog.
1- we reuse the class-map added previously.
this reflects the single source of both syslog/trace events
2- add a 2nd struct ddebug_classes_bitmap_p
drm_print defines all of these:
drm_dbg_{core,kms,prime,atomic,vbl,lease,_dp,_drmres}
but not drm_dbg_driver itself, which was the original drm_dbg.
To improve namespace symmetry, change the drm_dbg defn to
drm_dbg_driver, and redef grandfathered name to symmetric one.
This may help with nou
clone the nvkm_printk,_,__ macro ladder into nvkm_drmdbg,_,__.
And alter debug, trace, spam macros to use the renamed ladder.
This *sets-up* (not done yet) to remove the _subdev->debug >= (l)
condition, once the bitmap-param is wired up correctly, and figured
into dyndbg's jump-label enablement.
These 2 macros used drm_debug_enabled() on DRM_UT_{DRIVER,ATOMIC}
respectively, replace those with drm_dbg_##cat invocations.
this results in new class'd prdbg callsites:
:#> grep nouveau /proc/dynamic_debug/control | grep class | wc
1161130 15584
:#> grep nouveau /proc/dynamic_debug/co
Distinguish the condition: _DPRINTK_FLAGS_ENABLED from the bit:
_DPRINTK_FLAGS_PRINT, and re-define former in terms of latter, in
preparation to add a 2nd bit: _DPRINTK_FLAGS_TRACE
Update JUMP_LABEL code block to check _DPRINTK_FLAGS_ENABLED symbol.
Also add a 'K' to get new symbol _DPRINTK_FLAGS_
clone DRM.debug interface to DRM.tracebits: ie declare __drm_trace,
map its bits to drm-debug-categories, except this interface enables
messages to tracefs, not to syslog.
1- we reuse the drm_debug_classes class-map added previously.
this reflects the single source of both syslog/trace events
Add include/trace/events/drm.h, with 2 new events: drm_debug() &
drm_devdbg(), and call them from drm_dbg() & drm_dev_dbg(). This is
easy, cuz the callers already build the vaf that the callee wants.
This allows the 3-5k drm.debug/on-dyndbg callsites to independently
(re-)direct messages to trace
upgrade the callchain to drm_dbg() and drm_dev_dbg(); add a struct
_ddebug ptr parameter to them, and supply that additional param by
replacing the '_no_desc' flavor of dyndbg Factory macro currently used
with the flavor that supplies the descriptor.
NOTES:
The descriptor gives these fns access t
ddebug_trace() currently issues a single printk:console event.
Replace that, adding include/trace/events/dyndbg.h, which defines 2
new events:
- dyndbg:prdbg - from trace_prdbg() - if !dev
- dyndbg:devdbg - from trace_devdbg() - if !!dev
This links the legacy pr_debug API to tracefs, via dyndbg
add new flag, and OR it into _DPRINTK_FLAGS_ENABLED definition
CC: vincent.whitchu...@axis.com
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 38
1st, internals:
adds: ddebug_trace()
uses trace_console() temporarily to issue printk:console event
uses internal-ish __ftrace_trace_stack code:
4-context buffer stack, barriers per Steve Rostedt
call it from new mid-layer funcs:
ddebug_printk() - ddebug_trace or vprintk (to syslog)
d
Distinguish the condition: _DPRINTK_FLAGS_ENABLED from the bit:
_DPRINTK_FLAGS_PRINT, and re-define former in terms of latter, in
preparation to add a 2nd bit: _DPRINTK_FLAGS_TRACE
Update JUMP_LABEL code block to check _DPRINTK_FLAGS_ENABLED symbol.
Also add a 'K' to get new symbol _DPRINTK_FLAGS_
These 2 macros formerly used dev_info, and they still check
subdev->debug to gate the printing. So dyndbg control is redundant
ATM (and possibly confusing, since its off by default).
prdbg count is up from 3, or from 65 (with VMM_DEBUG here)
[7.765379] dyndbg: 516 debug prints in module nouv
upgrade the callchain to drm_dbg() and drm_dev_dbg(); add a struct
_ddebug ptr parameter to them, and supply that additional param by
replacing the '_no_desc' flavor of dyndbg Factory macro currently used
with the flavor that supplies the descriptor.
NOTES:
The descriptor gives these fns access t
These 2 macros formerly used dev_info, and they still check
subdev->debug to gate the printing. So dyndbg control is redundant
ATM (and possibly confusing, since its off by default).
prdbg count is up from 3, or from 65 (with VMM_DEBUG here)
[7.765379] dyndbg: 516 debug prints in module nouv
In order to use dynamic-debug's jump-label optimization in drm-debug,
its clarifying to refine drm_debug_enabled into 3 uses:
1. drm_debug_enabled - legacy, public
2. __drm_debug_enabled - optimized for dyndbg jump-label enablement.
3. _drm_debug_enabled - pr_debug instrumented, observable
1.
drm_print.c calls pr_debug() just once, from __drm_printfn_debug(),
which is a generic/service fn. The callsite is compile-time enabled
by DEBUG in both DYNAMIC_DEBUG=y/n builds.
For dyndbg builds, reverting this callsite back to bare printk is
correcting a few anti-features:
1- callsite is gene
drm_print.c calls pr_debug() just once, from __drm_printfn_debug(),
which is a generic/service fn. The callsite is compile-time enabled
by DEBUG in both DYNAMIC_DEBUG=y/n builds.
For dyndbg builds, reverting this callsite back to bare printk is
correcting a few anti-features:
1- callsite is gene
Add module-to-class validation:
#> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control
If a query has "class FOO", then ddebug_find_valid_class(), called
from ddebug_change(), requires that FOO is known to module X,
otherwize the query is skipped entirely for X. This protects each
module's
Add ddebug_attach_module_classes(), call it from ddebug_add_module().
It scans the classes/section its given, finds records where the
module-name matches the module being added, and adds them to the
module's maps list. No locking here, since the record
isn't yet linked into the ddebug_tables list.
lkp robot told me:
>> drivers/gpu/drm/drm_ioc32.c:989:2:
error: call to undeclared function '_dynamic_func_call_cls';
ISO C99 and later do not support implicit function declarations
[-Wimplicit-function-declaration]
DRM_DEBUG("comm=\"%s\", pid=%d, dev=0x%lx, auth=%d, %s\n",
Si
lkp robot told me:
>> drivers/gpu/drm/drm_ioc32.c:989:2:
error: call to undeclared function '_dynamic_func_call_cls';
ISO C99 and later do not support implicit function declarations
[-Wimplicit-function-declaration]
DRM_DEBUG("comm=\"%s\", pid=%d, dev=0x%lx, auth=%d, %s\n",
Si
For CONFIG_DRM_USE_DYNAMIC_DEBUG=y, wrap __drm_dbg() & __drm_dev_dbg()
in one of dyndbg's Factory macros: _dynamic_func_call_no_desc().
This adds the callsite descriptor into the code, and an entry for each
into /proc/dynamic_debug/control.
#> echo class DRM_UT_ATOMIC +p > /proc/dynamic_debug/c
enum drm_debug_category has 10 categories, but is initialized with
bitmasks which require 10 bits of underlying storage. By using
natural enumeration, and moving the BIT(cat) into drm_debug_enabled(),
the enum fits in 4 bits, allowing the category to be represented
directly in pr_debug callsites,
change drm_dev_dbg & drm_dbg to macros, which forward to the renamed
functions (with __ prefix added).
Those functions sit below the categorized layer of macros implementing
the DRM debug.category API, and implement most of it. These are good
places to insert dynamic-debug jump-label mechanics, w
drm_print defines all of these:
drm_dbg_{core,kms,prime,atomic,vbl,lease,_dp,_drmres}
but not drm_dbg_driver itself, since it was the original drm_dbg.
To improve namespace symmetry, change the drm_dbg defn to
drm_dbg_driver, and redef grandfathered name to symmetric one.
This will help with
Use DECLARE_DYNDBG_CLASSMAP across DRM:
- in .c files, since macro defines/initializes a record
- in drivers, $mod_{drv,drm,param}.c
ie where param setup is done (since a class-bitmap is a param)
- in drm/drm_print.c, since thats where it
adds the class-bitmap, and replaces module_param
Add an explanation of the new "class CLASS_NAME" syntax and meaning,
noting that the module determines if CLASS_NAME applies to it.
Signed-off-by: Jim Cromie
---
Documentation/admin-guide/dynamic-debug-howto.rst | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/admin
Like existing sections, particularly __dyndbg, this new one is an
array/address and its length. In a close imitation of __dyndbg
handling, these are defined, then passed around, as follows:
vmlinux.lds.h:
KEEP the new section, which also silences orphan section warning on
loadable modules. Add
Rework/modernize docs:
- use /proc/dynamic_debug/control in examples
its *always* there (when dyndbg is config'd), even when is not.
drop talk, its a distraction here.
- read before write. Viewing before Controlling.
control file as Catalog.
- focus on use by a system administrator
Demonstrate use of DECLARE_DYNDBG_CLASSMAP macro, and expose them as
sysfs-nodes for testing.
For each of the 4 class-map-types:
- declare a class-map of that type,
- declare the enum corresponding to those class-names
- share _base across 0..30 range
- add a __pr_debug_cls() call for eac
Add kernel_param_ops and callbacks to apply a class-map to a
sysfs-node, which then can control classes defined in that class-map.
This supports uses like:
echo 0x3 > /sys/module/drm/parameters/debug
IE add these:
- int param_set_dyndbg_classes()
- int param_get_dyndbg_classes()
- struct ke
DECLARE_DYNDBG_CLASSMAP lets modules declare a set of classnames, this
opt-in authorizes dyndbg to allow enabling of prdbgs by their class:
:#> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control
This is just the setup; following commits deliver.
The macro declares and initializes a static
`cat control` currently does octal escape, so '\n' becomes "\012".
Change this to display as "\n" instead, which reads much cleaner.
:#> head -n7 /proc/dynamic_debug/control
# filename:lineno [module]function flags format
init/main.c:1179 [main]initcall_blacklist =_ "blacklisting initcall
Walk the module's vector of callsites backwards; ie N..0. This
"corrects" the backwards appearance of a module's prdbg vector when
walked 0..N. I think this is due to linker mechanics, which I'm
inclined to treat as immutable, and the order is fixable in display.
No functional changes.
Combined
DRM issues ~10 exclusive categories of debug messages; to represent
this directly in dyndbg, add a new field: struct _ddebug.class_id:5.
This gives us 32 classes, which is a practical usability limit
with a bitmap interface:
#> echo 0x012345678 > /sys/module/drm/parameters/debug
All existing c
Provide a simple module to allow testing DYNAMIC_DEBUG behavior. It
calls do_prints() from module-init, and with a sysfs-node.
dmesg -C
dmesg -w &
modprobe test_dynamic_debug dyndbg=+p
echo 1 > /sys/module/dynamic_debug/parameters/verbose
cat /sys/module/test_dynamic_debug/parameters/d
For selftest purposes, add __pr_debug_cls(class, fmt, ...)
I didn't think we'd need to define this, since DRM effectively has it
already in drm_dbg, drm_devdbg. But test_dynamic_debug needs it in
order to demonstrate all the moving parts.
Note the __ prefix; its not intended for general use, at
dyndbg's control-parser: ddebug_parse_query(), requires that search
terms: module, func, file, lineno, are used only once in a query; a
thing cannot be named both foo and bar.
The cited commit added an overriding module modname, taken from the
module loader, which is authoritative. So it set quer
This exported fn is unused, and will not be needed. Lets dump it.
The export was added to let drm control pr_debugs, as part of using
them to avoid drm_debug_enabled overheads. But its better to just
implement the drm.debug bitmap interface, then its available for
everyone.
Fixes: a2d375eda771 (
/proc/dynamic_debug/control walks the prdbg catalog in "reverse",
fix this by adding new ddebug_tables to tail of list.
This puts init/main.c entries 1st, which looks intentional.
no functional changes.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 2 +-
1 file changed, 1 insertion(+), 1
print "old => new" flag values to the info("change") message.
no functional change.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index a56c1286ffa4..8faf584f2f4b 100644
For CONFIG_DYNAMIC_DEBUG=N, the ddebug_dyndbg_module_param_cb()
stub-fn is too permissive:
bash-5.1# modprobe drm JUNKdyndbg
bash-5.1# modprobe drm dyndbgJUNK
[ 42.933220] dyndbg param is supported only in CONFIG_DYNAMIC_DEBUG builds
[ 42.937484] ACPI: bus type drm_connector registered
This c
In https://lore.kernel.org/lkml/20211209150910.ga23...@axis.com/
Vincent's patch commented on, and worked around, a bug toggling
static_branch's, when a 2nd PRINTK-ish flag was added. The bug
results in a premature static_branch_disable when the 1st of 2 flags
was disabled.
The cited commit comp
To: jba...@akamai.com>,gre...@linuxfounation.org
CC:
intel-...@lists.freedesktop.org,nouv...@lists.freedesktop.org,dri-devel@lists.freedesktop.org
Add 'typed' "class FOO" support to dynamic-debug, where 'typed' means
either DISJOINT (like drm debug categories), or VERBOSE (like nouveau
debug-leve
On 7/15/2022 3:54 PM, Daniele Ceraolo Spurio wrote:
This patch re-introduces support for GuC v69 in parallel to v70. As this
is a quick fix, v69 has been re-introduced as the single "fallback" guc
version in case v70 is not available on disk. All v69 specific code has
been labeled as such for
On 16/07/2022 19:25, Melissa Wen wrote:
AMD GPU display manager (DM) maps DRM pixel blend modes (None,
Pre-multiplied, Coverage) to MPC hw blocks through blend configuration
options. Describe relevant elements and how to set and test them to get
the expected DRM blend mode on DCN hw.
Signed-off-
On 16/07/2022 19:25, Melissa Wen wrote:
Describe structs and enums used to set blend mode properties to MPC
blocks. Some pieces of information are already available as code
comments, and were just formatted. Others were collected and summarised
from discusssions on AMD issue tracker[1][2].
Typo
Hi all,
On Mon, 11 Jul 2022 10:05:45 +0200 Christian König
wrote:
>
> Am 11.07.22 um 04:47 schrieb Stephen Rothwell:
> >
> > Today's linux-next merge of the drm tree got a conflict in:
> >
> >drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> >
> > between commit:
> >
> >925b6e59138c ("Rever
On 16/07/2022 19:25, Melissa Wen wrote:
Add details about color correction capabilities and explain a bit about
differences between DC hw generations and also how they are mapped
between DRM and DC interface. Two schemas for DCN 2.0 and 3.0 (converted
to svg from the original png) is included to
Hi Geert,
On 12/07/22 03:50, Geert Uytterhoeven wrote:
Hi all,
This patch series contains miscellaneous fixes and cleanups for the
Atari frame buffer device driver, which were identified while working on
the Atari DRM driver.
Most of them have been tested on ARAnyM, and should be saWor
On 16/07/2022 19:25, Melissa Wen wrote:
AMDGPU DM maps DRM color management properties (degamma, ctm and gamma)
to DC color correction entities. Part of this mapping is already
documented as code comments and can be converted as kernel docs.
v2:
- rebase to amd-staging-drm-next
Reviewed-by: Har
On 7/15/22 18:58, Christian König wrote:
> Am 15.07.22 um 17:36 schrieb Thomas Zimmermann:
>> Hi
>>
>> Am 15.07.22 um 13:15 schrieb Christian König:
>>> I've stumbled over this while reviewing patches for DMA-buf and it looks
>>> like we completely messed the locking up here.
>>>
>>> In general mos
The pull request you sent on Sun, 17 Jul 2022 14:59:42 -0400:
> git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-07-17
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/55ea9bd666887ed4159df38d1494c204246cf2bc
Thank you!
--
Deet-doot-dot, I am a bo
https://bugzilla.kernel.org/show_bug.cgi?id=201957
--- Comment #83 from Danil (s48g...@gmail.com) ---
Log from what I described above - "fixed just by switching to
system-terminal(ctrl+alt+f1)", nothing crash even GPU apps keep working, just
huge mouse+UI freeze and switching to F1 terminal and ba
On 7/17/22 11:43, Maíra Canal wrote:
The igt_check_drm_format_min_pitch() function had a lot of
KUNIT_EXPECT_* calls, all of which ended up allocating and initializing
various test assertion structures on the stack.
This behavior was producing -Wframe-larger-than warnings on PowerPC, i386,
and M
Hi Dave and Daniel (and Linus),
Our 'dim' flow has a problem with fixes of fixes getting missed.
We need to take a look on that later.
Meanwhile, please allow me to quickly propagate this fix
here upstream.
Here goes drm-intel-fixes-2022-07-17:
- Fix 32b build
Thanks,
Rodrigo.
The following c
On Sun, 2022-07-17 at 09:20 -0700, Guenter Roeck wrote:
> Commit aff1e0b09b54 ("drm/i915/ttm: fix sg_table construction")
> introduces
> an additional parameter to i915_rsgt_from_mm_node(). The parameter is
> used
> to calculate segment_pages. This in turn is used in DIV_ROUND_UP() as
> divisor. So
On Sat, 2022-07-16 at 15:08 -0700, Linus Torvalds wrote:
> On Sat, Jul 16, 2022 at 2:35 PM Linus Torvalds
> wrote:
> >
> > That said, even those type simplifications do not fix the
> > fundamental
> > issue. That "DIV_ROUND_UP()" still ends up being a 64-bit divide,
> > although now it's at least
The igt_check_drm_format_min_pitch() function had a lot of
KUNIT_EXPECT_* calls, all of which ended up allocating and initializing
various test assertion structures on the stack.
This behavior was producing -Wframe-larger-than warnings on PowerPC, i386,
and MIPS architectures, such as:
drivers/gp
Add todo in the hope someone will help updating the bridge drivers.
v2:
- Updated descriptions in todo.rst
Signed-off-by: Sam Ravnborg
Acked-by: Maxime Ripard
Cc: Laurent Pinchart
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
Docum
Replace the deprecated drm_bridge_funcs.mode_fixup() with
drm_bridge_funcs.atomic_check().
drm_bridge_funcs.atomic_check() requires the atomic state operations,
update these to the default implementations.
Likewise update enable/disable to their atomic variants.
With these changes omapdrm now imp
All users are converted over to drm_bridge_funcs.atomic_check()
so it is safe to drop the mode_fixup support.
Update the comment for atomic_check with relevant parts from mode_fixup.
Signed-off-by: Sam Ravnborg
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc
Replace the deprecated drm_bridge_funcs.mode_fixup() with
drm_bridge_funcs.atomic_check().
The driver implements the state operations, so no other changes
are required for the replacement.
Signed-off-by: Sam Ravnborg
Cc: Laurent Pinchart
Cc: Kieran Bingham
Cc: linux-renesas-...@vger.kernel.org
The implementation of drm_bridge_funcs.mode_fixup is optional
so there is no need to provide an empty implementation.
Drop mtk_hdmi_bridge_mode_fixup() so the driver no longer uses the
deprecated drm_bridge_funcs.mode_fixup() operation.
Signed-off-by: Sam Ravnborg
Cc: Chun-Kuang Hu
Cc: Philipp Z
On 7/14/22 21:03, Daniel Latypov wrote:
> On Thu, Jul 14, 2022 at 4:51 PM Guenter Roeck wrote:
>>
>> On Fri, Jul 08, 2022 at 05:30:47PM -0300, Maíra Canal wrote:
>>> Considering the current adoption of the KUnit framework, convert the
>>> DRM format selftest to the KUnit API.
>>>
>>> Tested-by: Da
There are no users left of drm_bridge_chain_mode_fixup() and we
do not want to have this function available, so drop it.
Signed-off-by: Sam Ravnborg
Reviewed-by: Maxime Ripard
Cc: Laurent Pinchart
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vett
The mode_valid implementation had a call to
drm_bridge_chain_mode_fixup() which would be wrong as the mode_valid is
not allowed to change anything - only to validate the mode.
As the next bridge is often/always a connector the call had no effect
anyway. So drop it.
>From the git history I could s
Replace the deprecated drm_bridge_funcs.mode_fixup() with
drm_bridge_funcs.atomic_check().
drm_bridge_funcs.atomic_check() requires the atomic state operations,
update these to the default implementations.
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: La
Replace the deprecated drm_bridge_funcs.mode_fixup() with
drm_bridge_funcs.atomic_check().
drm_bridge_funcs.atomic_check() requires the atomic state operations,
update these to the default implementations.
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: La
When atomic_check() is defined, then mode_fixup() is ignored,
so it had no effect that drm_bridge_funcs.mode_fixup was assigned.
Embed the original implementation in the caller and drop the function.
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent P
The atomic variants of enable/disable in drm_bridge_funcs are the
preferred operations - introduce these.
The ps8640 driver used the non-atomic variants of the
drm_bridge_chain_pre_enable/
drm_bridge_chain_post_disable - convert these to the atomic variants.
v2:
- Init state operations in drm_
The drm_bridge_chain_{pre_enable,enable,disable,post_disable} has no
users left and we have atomic variants that should be used.
Drop them so they do not gain new users.
Adjust a few comments to avoid references to the dropped functions.
Signed-off-by: Sam Ravnborg
Reviewed-by: Maxime Ripard
Re
This is a collection of bridge patches that I had left unfinished
more than a year ago. Now where I have some spare time I dusted them
off for review and testing.
The patches builds, but has seen no run-time testing.
The patches are grouped like this:
1+2:
- Updates parade-ps8640 for atomic op
José Expósito wrote:
> I already fixed the warning and added the reviewed by tags, however, I
> noticed that rebasing the series on the latest drm-misc-next show this
> error:
> [...]
Sorry for the extra email. I forgot to mention that the error is only
present in UML. Running in other architectu
Hi David,
On Sat, Jul 16, 2022 at 05:32:51PM +0800, David Gow wrote:
> On Sat, Jul 9, 2022 at 7:58 PM José Expósito
> wrote:
> >
> > Extend the existing test cases to test the conversion from XRGB to
> > RGB565.
> >
> > The documentation and the color picker available on [1] are useful
> > r
Commit aff1e0b09b54 ("drm/i915/ttm: fix sg_table construction") introduces
an additional parameter to i915_rsgt_from_mm_node(). The parameter is used
to calculate segment_pages. This in turn is used in DIV_ROUND_UP() as
divisor. So far segment_pages was a constant and handled without divide
operati
On 7/16/22 20:17, Sam Ravnborg wrote:
> To have more of the dri1 specific support in one place move the dri1
> core files to the dri1 folder.
> The files continue to be part of the drm module, we just refer to the files
> with a folder name.
>
> Signed-off-by: Sam Ravnborg
> ---
This patch shows
On 7/16/22 20:17, Sam Ravnborg wrote:
> Move the DRI1 section from drm/Kconfig to a new Kconfig
> file that lives in the dri1/ directory.
> This isolates more of the DRI1 functionality.
>
> Signed-off-by: Sam Ravnborg
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martin
On 7/16/22 20:17, Sam Ravnborg wrote:
> drm/dri1 is the new home for all the legacy DRI1 drivers.
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Javier Martinez Canillas
> ---
Reviewed-by: Javier Martinez Canillas
I wonder if we should just squash patches 03/11 to 09/11 into a
single patch. A
On 7/16/22 20:17, Sam Ravnborg wrote:
> drm/dri1 is the new home for all the legacy DRI1 drivers.
> Used the opportunity to rename the file to via.c to match the
> name of the driver.
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Javier Martinez Canillas
> ---
Reviewed-by: Javier Martinez Can
On 7/16/22 20:17, Sam Ravnborg wrote:
> drm/dri1 is the new home for all the legacy DRI1 drivers.
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Javier Martinez Canillas
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 7/16/22 20:17, Sam Ravnborg wrote:
> drm/dri1 is the new home for all the legacy DRI1 drivers.
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Javier Martinez Canillas
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 7/16/22 20:17, Sam Ravnborg wrote:
> drm/dri1 is the new home for all the legacy DRI1 drivers.
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Javier Martinez Canillas
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 7/16/22 20:17, Sam Ravnborg wrote:
> drm/dri1 is the new home for all the legacy DRI1 drivers.
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Javier Martinez Canillas
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 7/16/22 20:17, Sam Ravnborg wrote:
> drm/dri1 is the new home for all the legacy DRI1 drivers.
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Javier Martinez Canillas
Ditto here and other patches.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engi
1 - 100 of 107 matches
Mail list logo
