On 2024/4/23 18:20, Krzysztof Kozlowski wrote:
On 23/04/2024 12:12, Sui Jingfeng wrote:
Hi,
On 2024/4/23 16:05, Krzysztof Kozlowski wrote:
On 22/04/2024 21:19, Sui Jingfeng wrote:
Otherwise when compiled as module, this driver will not be probed on
non-DT environment. This is a
Hi,
On 2024/4/23 16:05, Krzysztof Kozlowski wrote:
On 22/04/2024 21:19, Sui Jingfeng wrote:
Otherwise when compiled as module, this driver will not be probed on
non-DT environment. This is a fundamential step to make this driver
truely OF-independent.
NAK.
:( ...
You should not need
Hi,
On 2024/4/23 03:51, Dmitry Baryshkov wrote:
On Tue, Apr 23, 2024 at 03:18:55AM +0800, Sui Jingfeng wrote:
Currently, the various display bridge drivers rely on OF infrastructures
to works very well, yet there are platforms and/or devices absence of 'OF'
support. Such as virtu
Otherwise when compiled as module, this driver will not be probed on
non-DT environment. This is a fundamential step to make this driver
truely OF-independent.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/ti-tfp410.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm
Make this driver DT-independent by calling the freshly created helpers,
which reduce boilerplate and open the door for otherwise use cases. No
functional changes for DT based systems.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/ti-tfp410.c | 41 +++---
1 file
Make this driver DT-independent by calling the freshly created helpers,
which reduce boilerplate and open the door for otherwise use cases. No
functional changes for DT based systems.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/ite-it66121.c | 57 +---
1 file
Make this driver less DT-dependent by calling the freshly created helper
functions, which reduce boilerplate. Should be no functional changes for
DT based systems.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/sii902x.c | 43 +++-
1 file changed, 14
Otherwise when compiled as module, this driver will not be probed on
non-DT environment. This is a fundamential step to make this driver
truely OF-independent.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/display-connector.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers
Make this driver less DT-dependent by using the fwnode helper functions,
should be no functional changes for DT based systems. Do the necessary
works before it can be truely DT-independent, this patch do no harms even
though there is no user yet.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm
Otherwise when compiled as module, this driver will not be probed on
non-DT environment. This is a fundamential step to make this driver
truely OF-independent.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/simple-bridge.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu
Make this driver less DT-dependent by calling the freshly created helpers,
should be no functional changes for DT based systems. But open the door for
otherwise use cases. Even though there is no user emerged yet, this still
do no harms.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge
hed before drm bridge drivers
are probed, and there has fwnode assigned to involved drm bridge instance.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/drm_bridge.c | 74
include/drm/drm_bridge.h | 16
2 files changed, 90 insertions(+)
diff --git
fp410 get nuked
* Add platform module alias
* Rebase and improve commit message and function comments
Sui Jingfeng (9):
drm/bridge: Allow using fwnode API to get the next bridge
drm/bridge: simple-bridge: Use fwnode API to acquire device properties
drm/bridge: simple-bridge:
kernel.org/lkml/20230223203713.hcse3mkbq3m6sogb@skbuf/
Cc: Andy Shevchenko
Cc: Daniel Scally
Cc: Heikki Krogerus
Cc: Sakari Ailus
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Signed-off-by: Sui Jingfeng
---
V2: Update commit message
drivers/base/swnode.c | 26 +
Hi,
On 2024/3/23 02:16, Andy Shevchenko wrote:
On Sat, Mar 23, 2024 at 02:12:14AM +0800, Sui Jingfeng wrote:
On 2024/3/23 02:05, Andy Shevchenko wrote:
Besides that, the kernel project rule is "we do not add
the dead (unused) code".
This rule is good an correct and I admit
Hi,
On 2024/3/23 02:05, Andy Shevchenko wrote:
Besides that, the kernel project rule is "we do not add
the dead (unused) code".
This rule is good an correct and I admit.
But the problem is that it is chicken-and-egg problem,
it probably have at least two user now.
it's possible that it wi
Hi,
On 2024/3/23 00:14, Andy Shevchenko wrote:
On Fri, Mar 22, 2024 at 05:00:05PM +0800, Sui Jingfeng wrote:
On 2024/3/21 04:28, Andy Shevchenko wrote:
...
By replacing it with device_get_match_data() and creating a software
graph that mimics the OF graph, everything else works fine
Hi,
On 2024/3/22 20:31, Maxime Ripard wrote:
On Fri, Mar 22, 2024 at 07:13:54PM +0800, Sui Jingfeng wrote:
Hi,
On 2024/3/22 18:31, Maxime Ripard wrote:
Which default config are you talking about? This compiles fine with all
drm-misc defconfig, x86 defconfig and allmodconfig.
The
Hi,
On 2024/3/15 00:35, Colin Ian King wrote:
There is a spelling mistake in a DRM_DEBUG_KMS message. Fix it.
Signed-off-by: Colin Ian King
Reviewed-by:Sui Jingfeng
--
Best regards,
Sui
Hi,
On 2024/3/22 17:22, Jani Nikula wrote:
On Fri, 22 Mar 2024, Sui Jingfeng wrote:
Hi,
On 2024/3/21 23:29, Maxime Ripard wrote:
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
Hi,
On 2024/3/22 18:31, Maxime Ripard wrote:
Which default config are you talking about? This compiles fine with all
drm-misc defconfig, x86 defconfig and allmodconfig.
The drm_hdmi_avi_infoframe_colorimetry() function is belong to the
drm_display_helper.ko
kernel module, it get called from
Hi,
On 2024/3/21 04:28, Andy Shevchenko wrote:
By replacing it with device_get_match_data() and creating a software
graph that mimics the OF graph, everything else works fine, except that
there isn't an out-of-box replacement for the of_device_get_match_data()
function. Because the software nod
Hi,
On 2024/3/21 22:09, Maxime Ripard wrote:
Hi,
On Wed, Mar 20, 2024 at 10:34:17AM +0100, Thomas Zimmermann wrote:
+/**
+ * drm_connector_helper_detect_ctx - Read EDID and detect connector status.
+ * @connector: The connector
+ * @ctx: Acquire context
+ * @force: Perform screen-destructive
store everything we need.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
Reviewed-by: Sui Jingfeng
--
Best regards,
Sui
Having conditional around the of_node pointer of the drm_bridge structure
turns out to make driver code use ugly #ifdef blocks. Drop the conditionals
to simplify debugfs.
Fixes: d8dfccde2709 ("drm/bridge: Drop conditionals around of_node pointers")
Signed-off-by: Sui Jingfeng
---
d
Hi,
On 2024/3/21 23:29, Maxime Ripard wrote:
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 gene
Hi,
On 2024/3/20 17:34, Thomas Zimmermann wrote:
+
+/**
+ * devm_drm_kms_helper_poll_init - initialize and enable output polling
Should be drmm_kms_helper_poll_init() here.
+ * @dev: drm_device
+ *
+ * This function initializes and then also enables output polling support for
+ * @dev si
drm/loongson forget to calldrm_kms_helper_poll_fini() on driver
leave, Opps.
Acked-by: Sui Jingfeng
---
drivers/gpu/drm/ast/ast_mode.c | 4 +++-
drivers/gpu/drm/drm_probe_helper.c | 27 +++
include/drm/drm_probe_helper.h | 2 ++
3 files changed, 32
utely necessary requirements.
Now that drm/ast becomes better than before:
Acked-by: Sui Jingfeng
---
drivers/gpu/drm/ast/ast_mode.c | 6 --
drivers/gpu/drm/drm_probe_helper.c | 29 +
include/drm/drm_probe_helper.h | 3 +++
3 files change
Hi,
On 2024/3/21 16:13, Thomas Zimmermann wrote:
Hi
Am 20.03.24 um 18:32 schrieb Sui Jingfeng:
Hi,
On 2024/3/20 17:34, Thomas Zimmermann wrote:
The struct struct ast_i2c_chan represents the Display Data Channel
(DDC); I2C is the underlying bus. Rename the structure, the variables
and the
On 2024/3/19 23:49, Neil Armstrong wrote:
On 18/03/2024 20:23, Sui Jingfeng wrote:
Hi,
On 2024/3/19 02:04, Laurent Pinchart wrote:
Improving core helpers is certainly a good idea, and if we do so, we
can
simplify drivers. What I'm concerned is that commit 00084f0c01bf
creates
a s
Hi,
On 2024/3/20 18:39, Andy Shevchenko wrote:
+Cc: Vladimir
On Tue, Mar 19, 2024 at 07:42:22AM +0800, Sui Jingfeng wrote:
This makes it possible to support (and/or test) a few drivers that
originates from DT World on the x86-64 platform. Originally, those
drivers using the
EDID property.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sui Jingfeng
--
Best regards,
Sui
present. Invoking DDC transfers
from any where within the driver now takes the lock.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sui Jingfeng
Tested-by: Sui Jingfeng
--
Best regards,
Sui
d 'state', as used in the declaration of struct
i2c_algo_bit_data. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sui Jingfeng
--
Best regards,
Sui
Hi,
On 2024/3/20 17:34, Thomas Zimmermann wrote:
The DDC code needs the AST device. Store a pointer in struct ast_ddc
and avoid internal upcasts. Improves type safety within the DDC code.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sui Jingfeng
--
Best regards,
Sui
Hi,
On 2024/3/20 17:34, Thomas Zimmermann wrote:
The DDC code needs the AST device. Pass it to ast_ddc_create() and
avoid an internal upcast. Improves type safety within the DDC code.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sui Jingfeng
--
Best regards,
Sui
itself.
Reviewed-by: Sui Jingfeng
--
Best regards,
Sui
ain header file,
which doesn't need them. Renaming files to _ddc indicates that the
code is about the DDC. I2C is really just the underlying bus here.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sui Jingfeng
--
Best regards,
Sui
: Sui Jingfeng
--
Best regards,
Sui
Hi,
On 2024/3/20 17:34, Thomas Zimmermann wrote:
Include to get of_property_read_u32() in the source
files that need it. Avoids the proxy include via .
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sui Jingfeng
--
Best regards,
Sui
wnode callback to fill
this gap. Device drivers or platform setup codes are expected to provide
a "compatible" string property. The value of this string property is used
to match against the compatible entries in the of_device_id table. Which
is consistent with the original usage style.
Sig
by: Javier Martinez Canillas
Reviewed-by: Zack Rusin
Reviewed-by: Sui Jingfeng
Tested-by: Sui Jingfeng
--
Best regards,
Sui
On 2024/3/19 03:23, Sui Jingfeng wrote:
2) It should be exist at product level kernel.
It should NOT be exist at product level kernel.
--
Best regards,
Sui
Hi,
On 2024/3/19 02:04, Laurent Pinchart wrote:
Improving core helpers is certainly a good idea, and if we do so, we can
simplify drivers. What I'm concerned is that commit 00084f0c01bf creates
a silent probe failure path,
No, I can't agree here. It doesn't creates a silent probe failure pat
Hi,
On 2024/3/19 02:04, Laurent Pinchart wrote:
Hi Sui,
On Tue, Mar 19, 2024 at 12:42:41AM +0800, Sui Jingfeng wrote:
On 2024/3/19 00:06, Laurent Pinchart wrote:
Commit 00084f0c01bf ("drm: bridge: thc63lvd1024: Switch to use
of_graph_get_remote_node()") simplified the thc63lvd1024
Hi,
On 2024/3/19 00:06, Laurent Pinchart wrote:
Commit 00084f0c01bf ("drm: bridge: thc63lvd1024: Switch to use
of_graph_get_remote_node()") simplified the thc63lvd1024 driver by
replacing hand-rolled code with a helper function.
[...]
While doing so, it
created an error code path at probe
Hi,
On 2024/3/18 23:57, Laurent Pinchart wrote:
On Mon, Mar 18, 2024 at 11:53:11PM +0800, Sui Jingfeng wrote:
On 2024/3/18 23:33, Laurent Pinchart wrote:
On Sun, Mar 17, 2024 at 01:28:00AM +0800, Sui Jingfeng wrote:
To reduce boilerplate, use of_graph_get_remote_node() helper instead of
the
Hi,
On 2024/3/18 23:33, Laurent Pinchart wrote:
Hi Sui,
Thank you for the patch.
On Sun, Mar 17, 2024 at 01:28:00AM +0800, Sui Jingfeng wrote:
To reduce boilerplate, use of_graph_get_remote_node() helper instead of
the hand-rolling code.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm
The calling of of_device_is_available() in it66121_probe() is duplicated,
as the of_graph_get_remote_node() has already do the check for us. There
is no need to call it again, thus delete the later one.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/ite-it66121.c | 6 --
1 file
To reduce boilerplate, use of_graph_get_remote_node() helper instead of
the hand-rolling code.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/thc63lvd1024.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/bridge/thc63lvd1024
To reduce boilerplate, use of_graph_get_remote_node() helper instead of
the hand-rolling code.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 31 +++
1 file changed, 4 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys
ys supports
HPD. Carry out a sanity check on 'client->irq' before using it, fall back
to polling mode if client->irq < 0 is true. Such a design increases the
overall flexibility.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/ite-it66121.c | 19 ---
1
Zimmermann)
v9:
* Revert to using get_scanout_buffer() (Sima)
* move get_scanout_buffer() to plane helper functions
Signed-off-by: Jocelyn Falempe
Acked-by: Sui Jingfeng
--
Best regards,
Sui
Hi,
On 2024/3/14 08:02, Dmitry Baryshkov wrote:
[...]
+/**
+ * dpu_rm_reserve_sspp - Reserve the required SSPP for the provided CRTC
+ * @rm: DPU Resource Manager handle
+ * @global_state: private global state
+ * @crtc: DRM CRTC handle
+ * @reqs: SSPP required features
+ */
+struct dpu_
Hi,
LGTM,
On 2024/3/11 22:49, Maxime Ripard wrote:
The new HDMI connector infrastructure allows us to remove a lot of
boilerplate, so let's switch to it.
Signed-off-by: Maxime Ripard
Acked-by: Sui Jingfeng
--
Best regards,
Sui
y the duplicated logic. This infrastructure comes with a few
requirements though, and thus we need a new initialization function.
Hopefully, this will make drivers simpler to handle, and their behaviour
more consistent.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
Reviewed-by
:
* Revert to using get_scanout_buffer() (Sima)
* move get_scanout_buffer() to plane helper functions
Signed-off-by: Jocelyn Falempe
I have done very limited test with ast2600, basically works by trigger via
debugfs interface as the cover-letter said.
so,
Tested-by: Sui Jingfeng
Hi,
I'm get attracted by your patch, so I want to comment.
Please correct or ignore me if I say something wrong.
On 2024/3/7 17:14, Jocelyn Falempe wrote:
This was initialy done for imx6, but should work on most drivers
using drm_fb_dma_helper.
v8:
* Replace get_scanout_buffer() logic with d
)
v9:
* Revert to using get_scanout_buffer() (Sima)
* move get_scanout_buffer() to plane helper functions
Signed-off-by: Jocelyn Falempe
If Thomas not objects,
Acked-by: Sui Jingfeng
Hi,
On 2024/3/7 17:14, Jocelyn Falempe wrote:
This introduces a new drm panic handler, which displays a message when a panic
occurs.
So when fbcon is disabled, you can still see a kernel panic.
This is one of the missing feature, when disabling VT/fbcon in the kernel:
https://www.reddit.com/r
Hi,
On 2024/3/7 17:14, Jocelyn Falempe wrote:
This module displays a user friendly message when a kernel panic
occurs. It currently doesn't contain any debug information,
but that can be added later.
v2
* Use get_scanout_buffer() instead of the drm client API.
(Thomas Zimmermann)
* Add
Hi,
Interesting patch! I know this patch already merged.
While study this patch, I have a few questions.
On 2024/2/8 17:51, Jocelyn Falempe wrote:
We found a regression in v5.10 on real-time server, using the
rt-kernel and the mgag200 driver. It's some really specialized
workload, with <10us
urned iosys_map is another copy of the original backup,
we can play with this local variable at will, there no need to duplicate
another time again.
I have modified and tested with fbdev generic, no problem. With this trivial
issue resolved. For fbdev-generic:
Acked-by: Sui Jingfeng
Signed-off-by: Thomas Zimmermann
Reviewed-by: Zack Rusin
Tested with drm/loongson, play with a few days.
Switch to virtual terminal, then switch back is fine.
not found problems yet. So,
Tested-by: Sui Jingfeng
Make this driver less DT-dependent by calling the freshly created helpers
and other manually improve. Should be no functional changes for DT based
systems, but do helps to reduce boilerplate.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/sii902x.c | 43
.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/ite-it66121.c | 63 +++-
1 file changed, 35 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ite-it66121.c
b/drivers/gpu/drm/bridge/ite-it66121.c
index 1c3433b5e366..a04d755fed4c 100644
--- a/drivers
Make this driver less DT-dependent by using the fwnode helper function,
should be no functional changes for DT based systems. Do the necessary
works before it can be truely subsystem independent, even though there
is no user yet, this still do no harms.
Signed-off-by: Sui Jingfeng
---
drivers
Make this driver less DT-dependent by calling the freshly created helpers,
should be no functional changes for DT based systems. But open the door for
otherwise use cases. Even though there is no user emerged yet, this still
do no harms.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge
bridge driver is probed, and there is a fwnode assigned to the instance
of specific drm bridge driver.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/drm_bridge.c | 72
include/drm/drm_bridge.h | 16
2 files changed, 88 insertions(+)
diff --git
* Add drm_bridge_find_next_bridge_by_fwnode() helper
* Add drm_bridge_set_node() helper
v2 -> v3:
* Read kernel-doc and improve function comments
* Drop the 'port' argument of it66121_read_bus_width() (Dmitry)
* Do more by covertering the sii902x drm bridge drviers
Sui
Hi,
On 2024/3/9 18:39, Dmitry Baryshkov wrote:
The code path of "creating a connector" plus the code path of "not creating a
connector"
forms a 'side-by-side' implementation imo.
Besides, I have repeated many times: the DT already speak everything.
Device drivers can completely know if there
Hi,
On 2024/3/9 18:39, Dmitry Baryshkov wrote:
On Sat, 9 Mar 2024 at 11:33, Sui Jingfeng wrote:
Hi,
On 2024/3/8 04:40, Dmitry Baryshkov wrote:
But really, there is nothing so hard about it:
- Change of_node to fw_node, apply an automatic patch changing this in
bridge drivers.
- Make
Hi,
On 2024/3/8 04:40, Dmitry Baryshkov wrote:
But really, there is nothing so hard about it:
- Change of_node to fw_node, apply an automatic patch changing this in
bridge drivers.
- Make drm_of_bridge functions convert passed of_node and comp
After this we can start cleaning up bridge drivers
On 2024/3/8 05:09, Sui Jingfeng wrote:
a most experienced
A most experienced programmer & developer.
Hi,
On 2024/3/8 04:40, Dmitry Baryshkov wrote:
But really, there is nothing so hard about it:
- Change of_node to fw_node, apply an automatic patch changing this in
bridge drivers.
- Make drm_of_bridge functions convert passed of_node and comp
After this we can start cleaning up bridge drivers
Hi,
On 2024/3/8 03:37, Dmitry Baryshkov wrote:
On Thu, 7 Mar 2024 at 21:20, Sui Jingfeng wrote:
Hi,
On 2024/3/8 02:43, Dmitry Baryshkov wrote:
+
MODULE_AUTHOR("Ajay Kumar");
MODULE_DESCRIPTION("DRM bridge infrastructure");
MODULE_LICENSE("GPL and addition
Hi,
On 2024/3/8 03:31, Dmitry Baryshkov wrote:
On Thu, 7 Mar 2024 at 19:24, Sui Jingfeng wrote:
Make this driver less DT-dependent by calling the freshly created helpers,
should be no functional changes for DT based systems. But open the door for
otherwise use cases. Even though there is no
On 2024/3/8 03:20, Sui Jingfeng wrote:
I think the drm_bridge should embeds 'struct device'
'struct device' -> 'struct device *'
Hi,
On 2024/3/8 02:43, Dmitry Baryshkov wrote:
+
MODULE_AUTHOR("Ajay Kumar");
MODULE_DESCRIPTION("DRM bridge infrastructure");
MODULE_LICENSE("GPL and additional rights");
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 3606e1a7f965..d4c95afdd662 100644
--- a/includ
drivers.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/ite-it66121.c | 63
1 file changed, 36 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ite-it66121.c
b/drivers/gpu/drm/bridge/ite-it66121.c
index 1c3433b5e366..a2cf2be86065 100644
--- a
Make this driver less DT-dependent by using the fwnode helper function,
should be no functional changes for DT based systems. Do the necessary
works before it can be truely subsystem independent, even though there
is no user yet, this still do no harms.
Signed-off-by: Sui Jingfeng
---
drivers
Make this driver less DT-dependent by calling the freshly created helpers,
should be no functional changes for DT based systems. But open the door for
otherwise use cases. Even though there is no user emerged yet, this still
do no harms.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge
-off-by: Sui Jingfeng
---
drivers/gpu/drm/drm_bridge.c | 68
include/drm/drm_bridge.h | 16 +
2 files changed, 84 insertions(+)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 521a71c61b16..1b2d3b89a61d 100644
--- a
e_set_node() helper
Sui Jingfeng (4):
drm/bridge: Add fwnode based helpers to get the next bridge
drm/bridge: simple-bridge: Use fwnode API to acquire device properties
drm-bridge: display-connector: Use fwnode API to acquire device
properties
drm-bridge: it66121: Use fwnode API to acqu
Hi,
On 2024/2/23 02:14, Maxime Ripard wrote:
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Signed-off-by: Maxime Ripard
Acked-by: Sui Jingfeng
Hi,
On 2024/2/9 19:02, Daniel Vetter wrote:
On Thu, Feb 08, 2024 at 04:27:02PM +0100, Maxime Ripard wrote:
On Wed, Feb 07, 2024 at 10:35:49AM +0100, Daniel Vetter wrote:
On Wed, Feb 07, 2024 at 01:27:59AM +0800, Sui Jingfeng wrote:
The component helper functions are the glue, which is used
Hi,
On 2024/2/13 22:38, Maxime Ripard wrote:
On Sat, Feb 10, 2024 at 12:25:33AM +0800, Sui Jingfeng wrote:
On 2024/2/9 23:15, Maxime Ripard wrote:
On Fri, Feb 09, 2024 at 12:02:48PM +0100, Daniel Vetter wrote:
On Thu, Feb 08, 2024 at 04:27:02PM +0100, Maxime Ripard wrote:
On Wed, Feb 07
Hi,
On 2024/2/9 23:15, Maxime Ripard wrote:
On Fri, Feb 09, 2024 at 12:02:48PM +0100, Daniel Vetter wrote:
On Thu, Feb 08, 2024 at 04:27:02PM +0100, Maxime Ripard wrote:
On Wed, Feb 07, 2024 at 10:35:49AM +0100, Daniel Vetter wrote:
On Wed, Feb 07, 2024 at 01:27:59AM +0800, Sui Jingfeng
Hi,
On 2024/1/29 18:29, Daniel Stone wrote:
Hi Lucas,
On Fri, 26 Jan 2024 at 17:00, Lucas Stach wrote:
The dma sync operation needs to be done with DMA_BIDIRECTIONAL when
the BO is prepared for both read and write operations. With the
current inverted if ladder it would only be synced for DM
Hi,
On 2024/2/5 16:24, Thomas Zimmermann wrote:
Hi
Am 02.02.24 um 16:23 schrieb Sui Jingfeng:
Hi,
On 2024/2/2 19:58, Thomas Zimmermann wrote:
Set the firmware framebuffer's parent device, which usually is the
graphics hardware's physical device. Integrates the framebuffer in
Hi,
On 2024/2/7 17:35, Daniel Vetter wrote:
On Wed, Feb 07, 2024 at 01:27:59AM +0800, Sui Jingfeng wrote:
The component helper functions are the glue, which is used to bind multiple
GPU cores to a virtual master platform device. Which is fine and works well
for the SoCs who contains multiple
Because we need this function to create virtial child.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 33 +++
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 9
2 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm
for the vivante GPU
ip core. As all of subcomponent are attached via the PCIe master device,
we reflect this hardware layout by binding all of the virtual child to the
the real master.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/etnaviv/Kconfig | 8 +
drivers/gpu/drm/etnaviv
;dev'. To keep it consistent, use 'dev' uniformly.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 10 +-
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 16
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/etna
ev_private member, which is deprecated according to the drm
document.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c| 65
drivers/gpu/drm/etnaviv/etnaviv_drv.h| 7 +++
drivers/gpu/drm/etnaviv/etnaviv_gem.c| 6 +-
drivers/gpu/d
space know.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 3 +++
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 8
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 16 ++--
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4
include/uapi/drm/etnaviv_drm.h| 1
gs_count: 8
axi: 0x
idle: 0x7fff
DMA seems to be stuck
address 0: 0x
address 1: 0x
state 0: 0x
state 1: 0x
last fetch 64 bit word: 0x 0x00000000
Sui Jingfeng (7):
drm/etnavi
locks, which make it possible to call this function only
on the platform where DT support is available.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 53 ---
1 file changed, 32 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/et
. Another potential benefit is that we can also put the
struct drm_device into struct etnaviv_drm_private in the future, as the
instance of struct drm_device is also unique across all GPU cores.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 70
201 - 300 of 1230 matches
Mail list logo
