Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Tested-by: Jyri Sarha
Cc: Tomi Valkeinen
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Cc: Emma Anholt
Cc: Maxime Ripard
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Cc: R
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Cc: Yong Wu
Cc: Joerg Roedel
Cc: Will Deacon
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Cc: Tomas Winkler
Cc: Vitaly Lubart
Cc: Daniele Ceraolo Spurio
Cc: Rodrigo Vivi
Cc: Arnd Bergman
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Acked-by: Sebastian Reichel
Tested-by: Linus Walleij
Cc:
Cc: Daniel Vetter
Cc: "Rafael J. Wysock
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: Kai Vehmanen
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Cc:
Cc:
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Cc: Russell King
Cc: Saravana
Use an aggregate driver instead of component ops so that we can get
proper driver probe ordering of the aggregate device with respect to all
the component devices that make up the aggregate device.
Acked-by: Mark Brown
Cc: Jaroslav Kysela
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
There aren't any users anymore so drop it.
Cc: Laurent Pinchart
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Cc: Russell King
Cc: Saravana Kannan
Signed-off-by: Stephen Boyd
---
drivers/gpu/drm/drm_of.c | 85 +---
inclu
The struct is unused now so drop it along with the functions that use
it.
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Cc: Russell King
Cc: Saravana Kannan
Signed-off-by: Stephen Boyd
---
drivers/base/component.c | 148 +---
https://bugzilla.kernel.org/show_bug.cgi?id=215445
Satadru Pramanik (sata...@umich.edu) changed:
What|Removed |Added
CC||sata...@umich.edu
On Thu 06 Jan 12:44 PST 2022, Kuogee Hsieh wrote:
> DP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose
> and expect DP source return correct checksum. During drm edid read,
> correct edid checksum is calculated and stored at
> connector::real_edid_checksum.
>
Interesting, thank
On Thu 06 Jan 10:14 PST 2022, Rob Clark wrote:
> From: Rob Clark
>
> System suspend uses pm_runtime_force_suspend(), which cheekily bypasses
> the runpm reference counts. This doesn't actually work so well when the
> GPU is active. So add a reasonable delay waiting for the GPU to become
> idle
https://bugzilla.kernel.org/show_bug.cgi?id=206475
--- Comment #22 from rends...@gmail.com (rends...@gmail.com) ---
I resolved my issue by disabling p-state 7 when gaming, with cf. this comment
https://www.reddit.com/r/linux_gaming/comments/gbqe0e/comment/fp8r35a
--
You may reply to this email t
From: John Harrison
Update to the latest GuC version. This includes a suite of interface
changes and new features with corresponding i915 side changes.
v2: Rebased to latest tree.
Signed-off-by: John Harrison
John Harrison (3):
drm/i915/guc: Temporarily bump the GuC load timeout
drm/i91
From: John Harrison
If the GuC fails to load, it is useful to know what firmware file /
version was attempted. So move the version info report to before the
load attempt rather than only after a successful load.
If the GuC does fail to load, then make the error messages visible
rather than being
From: John Harrison
There is a known (but exceedingly unlikely) race condition where the
asynchronous frequency management code could reduce the GT clock while
a GuC reload is in progress (during a full GT reset). A fix is in
progress but there are complex locking issues to be resolved. In the
me
From: John Harrison
Update to the latest GuC release.
The latest GuC firmware introduces a number of interface changes:
GuC may return NO_RESPONSE_RETRY message for requests sent over CTB.
Add support for this reply and try resending the request again as a
new CTB message.
A KLV (key-length-va
Quoting Kuogee Hsieh (2022-01-06 09:14:56)
> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> index 39558a2..ba70387 100644
> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> @@ -1189,12 +1190,20 @@ static int dp_ctrl_link_train_
Quoting Kuogee Hsieh (2022-01-06 09:14:56)
> @@ -1189,12 +1190,20 @@ static int dp_ctrl_link_train_2(struct
> dp_ctrl_private *ctrl,
>
> *training_step = DP_TRAINING_2;
>
> - if (drm_dp_tps3_supported(ctrl->panel->dpcd))
> + if (drm_dp_tps4_supported(ctrl->panel->dpcd)) {
> +
Quoting Kuogee Hsieh (2022-01-06 12:44:54)
> DP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose
> and expect DP source return correct checksum. During drm edid read,
> correct edid checksum is calculated and stored at
> connector::real_edid_checksum.
>
> The problem is struct dp_p
From: John Harrison
There is a race (already documented in the code) whereby a context can
be (re-)queued for submission at the same time as it is being banned
due to a hang and reset. That leads to a hang/reset report from GuC
for a context which i915 thinks is already banned.
While the race is
On 1/6/2022 16:31, john.c.harri...@intel.com wrote:
From: John Harrison
There is a race (already documented in the code) whereby a context can
be (re-)queued for submission at the same time as it is being banned
due to a hang and reset. That leads to a hang/reset report from GuC
for a context w
Quoting Dmitry Baryshkov (2022-01-05 23:06:56)
> The round_pixclk() callback returns different rate only on MDP4 in HDMI
> (DTV) case. Stop using this callback in other cases to simplify
> mode_valid callbacks.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
Quoting Dmitry Baryshkov (2022-01-05 15:10:27)
> No code uses lm_max_width from resource manager, so drop it. Instead of
> calculating the lm_max_width, code can use max_mixer_width field from
> the hw catalog.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
Quoting Dmitry Baryshkov (2022-01-05 15:10:28)
> Add missing calls to dpu_hw_dspp_destroy() to free resources allocated
> for DSPP hardware blocks.
>
> Fixes: e47616df008b ("drm/msm/dpu: add support for color processing blocks in
> dpu driver")
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by
From: Kuogee Hsieh
Some DP sinkers prefer to use tps4 instead of tps3 during training #2.
This patch will use tps4 to perform link training #2 if sinker's DPCD
supports it.
Changes in V2:
-- replace dp_catalog_ctrl_set_pattern() with
dp_catalog_ctrl_set_pattern_state_bit()
Changes in V3:
--
Quoting Dmitry Baryshkov (2022-01-05 15:10:29)
> INTF blocks are not really handled by resource manager, they are
> assigned at dpu_encoder_setup_display using dpu_encoder_get_intf().
> Then this allocation is passed to RM and then returned to then
> dpu_encoder.
> So allocate them outside of RM an
Quoting Dmitry Baryshkov (2022-01-05 15:10:30)
> Now as dpu_hw_intf is not hanled by dpu_rm_get_assigned_resources, there
> is no point in embedding the (empty) struct dpu_hw_blk into dpu_hw_intf
> (and using typecasts between dpu_hw_blk and dpu_hw_intf). Drop it and
> use dpu_hw_intf directly.
>
>
Quoting Dmitry Baryshkov (2022-01-05 15:10:30)
> Now as dpu_hw_intf is not hanled by dpu_rm_get_assigned_resources, there
s/hanled/handled/
> is no point in embedding the (empty) struct dpu_hw_blk into dpu_hw_intf
> (and using typecasts between dpu_hw_blk and dpu_hw_intf). Drop it and
> use dpu_h
Quoting Dmitry Baryshkov (2022-01-05 15:10:31)
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> index bf4d72356a12..2301ac114920 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> @@ -78,6 +78,10
In commit 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for display
enable and disable") the DP driver received a drm_bridge instance, which
is always attached to the encoder as a root bridge. However it conflicts
with the panel_bridge support for eDP panels. Change panel_bridge
attachment to
I noticed that commit 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for
display
enable and disable") conflicts with the panel-edp (panel bridge)
support. Both bridges will try to attach directly to the drm encoder
itself. I started writing lengthy letter describing what is broken and
how it s
There is little point in having both connector and root bridge
implementation in the same driver. Move connector's functionality to the
bridge to let next bridge in chain to override it.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 22 +++---
drivers/gpu/drm/msm/dp/
Currently DP driver will allocate panel bridge for eDP panels.
Simplify this code to just check if there is any next bridge in the
chain (be it a panel bridge or regular bridge). Rename panel_bridge
field to next_bridge accordingly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_d
Refactoring DP code transformed several functions into empty stubs.
Remove them.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 35 -
1 file changed, 35 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp
Remove unused dp_display_en/disable prototypes. While we are at it,
remove extra 'data' argument that is unused.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_dis
dp_bridge's functions are thin wrappers around the msm_dp_display_*
family. Squash dp_bridge callbacks into respective msm_dp_display
functions, removing the latter functions from public space.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Makefile| 1 -
drivers/gpu/drm/msm/d
After changing dp_parser code to always check for the next bridge, it
does not check connector type anymore. Remove connector type from the
dp_paser_parse() arguments list and from the struct msm_dp_desc fields
list.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 9 +++
This patch series adds support for the Pine64 touch panel to the
rockpro64 single board computer.
This panel attaches to the dsi port and includes an i2c touch screen.
The first two patches involve making the reset pin to the Feiyang
fy07024di26a30d panel optional. On the rockpro64 and quartz64-a
Quoting Dmitry Baryshkov (2022-01-06 18:01:25)
> I noticed that commit 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for
> display
> enable and disable") conflicts with the panel-edp (panel bridge)
> support. Both bridges will try to attach directly to the drm encoder
> itself. I started writ
https://bugzilla.kernel.org/show_bug.cgi?id=215001
--- Comment #5 from Javier Martinez Canillas (jav...@dowhile0.org) ---
Created attachment 300235
--> https://bugzilla.kernel.org/attachment.cgi?id=300235&action=edit
[PATCH] video: vga16fb: Only probe for EGA and VGA 16 color graphic cards
Can
https://bugzilla.kernel.org/show_bug.cgi?id=215001
Javier Martinez Canillas (jav...@dowhile0.org) changed:
What|Removed |Added
Attachment #300235|0 |1
On 07/01/2022 05:16, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-01-06 18:01:25)
I noticed that commit 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for
display
enable and disable") conflicts with the panel-edp (panel bridge)
support. Both bridges will try to attach directly to the
Hi Linus,
There is only the amdgpu runtime pm regression fix in here. I'm going
to be away next week, I'll probably pre-send you the drm-next main PR
before I go, if I can get it done today!
Dave.
drm-fixes-2022-01-07:
drm fixes for 5.16 final
amdgpu:
- suspend/resume fix
- fix runtime PM regre
Quoting Dmitry Baryshkov (2022-01-06 18:01:26)
> In commit 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for display
> enable and disable") the DP driver received a drm_bridge instance, which
> is always attached to the encoder as a root bridge. However it conflicts
> with the panel_bridge sup
Quoting Dmitry Baryshkov (2022-01-06 18:01:27)
> Currently DP driver will allocate panel bridge for eDP panels.
> Simplify this code to just check if there is any next bridge in the
> chain (be it a panel bridge or regular bridge). Rename panel_bridge
> field to next_bridge accordingly.
>
> Signed-
On Thu, Jan 6, 2022 at 4:48 PM Chunfeng Yun wrote:
>
> On Mon, 2022-01-03 at 15:53 +0100, AngeloGioacchino Del Regno wrote:
> > All the headers for phy-mtk-mipi-{dsi,dsi-mt8173,dsi-mt8183}.c were
> > included from phy-mtk-mipi-dsi.h, but this isn't optimal: in order to
> > increase readability and
On 2022/1/7 上午3:13, Andrey Grodzovsky wrote:
>
> On 2022-01-06 12:18 a.m., JingWen Chen wrote:
>> On 2022/1/6 下午12:59, JingWen Chen wrote:
>>> On 2022/1/6 上午2:24, Andrey Grodzovsky wrote:
On 2022-01-05 2:59 a.m., Christian König wrote:
> Am 05.01.22 um 08:34 schrieb JingWen Chen:
>>
On 07/01/2022 06:37, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-01-06 18:01:26)
In commit 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for display
enable and disable") the DP driver received a drm_bridge instance, which
is always attached to the encoder as a root bridge. However it
This patch series adds support for the Pine64 touch panel to the
rockpro64 single board computer.
This panel attaches to the dsi port and includes an i2c touch screen.
The first two patches involve making the reset pin to the Feiyang
fy07024di26a30d panel optional. On the rockpro64 and quartz64-a
Some implementations do not use the reset signal, instead tying it to dvdd.
Make the reset gpio optional to permit this.
Signed-off-by: Peter Geis
---
.../bindings/display/panel/feiyang,fy07024di26a30d.yaml | 1 -
1 file changed, 1 deletion(-)
diff --git
a/Documentation/devicetree/bin
Some implementations do not use the reset signal, instead tying it to dvdd.
Make the reset gpio optional to permit this.
Signed-off-by: Peter Geis
---
drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu
On 07/01/2022 06:42, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-01-06 18:01:27)
Currently DP driver will allocate panel bridge for eDP panels.
Simplify this code to just check if there is any next bridge in the
chain (be it a panel bridge or regular bridge). Rename panel_bridge
field to
hi Jason, Steve, Greg, DRM-folks,
This patchset plumbs debug streams, from dynamic-debug, and from
drm.debug, into tracefs. Enabling traffic is done on both source &
destination:
# enable at source
echo module usbcore +T > /proc/dynamic_debug/control
# enable events into
Distinguish the condition: _DPRINTK_FLAGS_ENABLED from the bit:
_DPRINTK_FLAGS_PRINT, in preparation to add _DPRINTK_FLAGS_TRACE next.
Also add a 'K' to get _DPRINTK_FLAGS_PRINTK, to insure is not used
elsewhere with a stale meaning.
CC: vincent.whitchu...@axis.com
Signed-off-by: Jim Cromie
---
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 25
adds: dynamic_trace()
uses trace_console() temporarily to issue printk:console event
uses internal-ish __ftrace_trace_stack code:
4-context buffer stack, barriers per Steve
call it from new funcs:
dynamic_printk() - print to both syslog/tracefs
dynamic_dev_printk() - dev-print to both
DRM defines/uses a 10 enum drm_debug_category to create exclusive
classes of debug messages. To support this directly in dynamic-debug,
add the following:
- struct _ddebug.class_id 4 bits is enough for drm_debug_category
and the query support:
- struct _ddebug_query.class_id
- ddebug_chan
In commit HEAD~1, pr_debug temporarily issued a printk:console event.
Replace that use with 2 new events:
bash-5.1# ls events/dyndbg/
devdbg enable filter prdbg
..called from pr_debug(), dev_dbg() respectively for dyndbg builds.
This links the old pr_debug API to tracefs, via dyndbg, allo
commit:HEAD~1 added pr_debug(), dev_dbg() params to the new events,
but didn't actually capture the params. Do that now; add the other
TP_* parts: __fields, fast-assign, and printk elements for the
desccriptor and device params.
The message capture part is copied from printk:console, it gets the
enum drm_debug_category has 10 hardcoded values, which could be
"simplified" as sequential BIT(x)s. But lets take it one step
further, removing the explicit initializations (other than starting at
1), and move the BIT() operation into drm_debug_enabled().
This gives us a more compact representati
DRM.debug API is used thousands of times in drivers/gpu/drm/*; when
these are implemented using dynamic-debug, DYNAMIC_DEBUG_METADATA adds
a struct _ddebug (56 bytes) per site.
Since i915 will have ~2k callsites, and amdgpu ~4k, the memory costs
are substantial, and thus made configurable.
For a
drm_dev_dbg() & _drm_dbg() sit below the categorized layer of the DRM
debug API, and thus implement most of it. These are good places to
insert dynamic-debug jump-label mechanics, allowing DRM to avoid the
runtime cost of drm_debug_enabled().
Set up for this by changing the func names by adding '
Change __drm_dbg() macro to be CONFIG_DRM_USE_DYNAMIC_DEBUG dependent:
N- keep straight mapping to exported ___drm_dbg()
Y- wrap ___drm_dbg() inside _dynamic_func_call_no_desc()
This patch places ~1/2 of drm.debug API messages behind dyndbg's
JUMP_LABEL/NOOP optimization.
The CONFIG_DRM_USE_D
make drm_dev_dbg() macro CONFIG_DRM_USE_DYNAMIC_DEBUG dependent:
=N direct forwarding: drm_dev_dbg -> __drm_dev_dbg()
=Y wrap __drm_dev_dbg in _dynamic_func_call_no_desc().
This adds the metadata which creates a /proc/dynamic_debug/control
entry for each callsite, and exposes it for selective
__drm_debug() and __drm_dev_dbg() currently printk to syslog. These 2
underlay the vast bulk of DRM.debug api calls; they are a significant
source of debugging info, and could add useful context to debug traces.
Wire them to emit 2 new trace_*() events: drm_prdbg and drm_devdbg.
These events kee
A recent commit adding trace-events to drm noted:
trace_*() additions are strictly redundant with printks to syslog,
not properly placed to reduce overall work.
That was because it didn't have the struct _ddebug *descriptor, whose
.flags specify TRACE and PRINTK actions on a controlled call
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
Upgrade the current use of _dynamic_func_call_no_desc(), adding the
suffix and the category arg. The arg has been available via the
macros implementing the drm.debug api, but dyndbg lacked a simple way
to represent it and use it until recently.
Signed-off-by: Jim Cromie
---
include/drm/drm_prin
DEFINE_DYNAMIC_DEBUG_CLASSBITS(fsname, var, bitmap_desc, classes..)
allows users to create a drm.debug style (bitmap) sysfs interface, to
control sets of pr_debug's according to their .class_id's
1st, due to a recent commit, this already works:
echo "module drm class 1 +p ; module drm class 3
Replace trace-drm-*()s category param with struct _ddebug *desc; it
has .classid field, which is the category.
This brings the events closer in line with those added for dyndbg; at
least the 1st param, and possibly the struct device (tb-checked).
There are still differences in the tail of the prot
if CONFIG_DRM_USE_DYNDBG=y, use new macro to create the sysfs bitmap
to control drm.debug callsites.
DEFINE_DYNAMIC_DEBUG_CLASSBITS( debug, __drm_debug,
"drm.debug - control summary",
/* inline vector of dyndbg.class_id (uint:4, 0 is reserved) */
DRM_UT_CORE,
DRM_UT
On 2022/1/7 上午11:57, JingWen Chen wrote:
> On 2022/1/7 上午3:13, Andrey Grodzovsky wrote:
>> On 2022-01-06 12:18 a.m., JingWen Chen wrote:
>>> On 2022/1/6 下午12:59, JingWen Chen wrote:
On 2022/1/6 上午2:24, Andrey Grodzovsky wrote:
> On 2022-01-05 2:59 a.m., Christian König wrote:
>> Am 0
https://bugzilla.kernel.org/show_bug.cgi?id=215001
--- Comment #7 from Kris Karas (bugs-...@moonlit-rail.com) ---
Hi Javier - I tested the (updated) patch from comment 6 on three different
systems, two servers with a character-graphic BIOS (expected to use VGA16), and
my development system with a
101 - 176 of 176 matches
Mail list logo
