On 5/15/24 8:27 AM, Marek Vasut wrote:
The DW HDMI driver core is responsible for parsing the 'ddc-i2c-bus' property,
move the property description into the DW HDMI common DT schema too, so this
property can be used on all devices integrating the DW HDMI core.
Signed-off-by: Marek Vasut
---
+
On 5/15/24 5:12 AM, Liu Ying wrote:
On 5/15/24 06:04, Marek Vasut wrote:
The DW HDMI driver core is responsible for parsing the 'ddc-i2c-bus' property,
move the property description into the DW HDMI common DT schema too, so this
property can be used on all devices integrating the DW HDMI core.
The DW HDMI driver core is responsible for parsing the 'ddc-i2c-bus' property,
move the property description into the DW HDMI common DT schema too, so this
property can be used on all devices integrating the DW HDMI core.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: Conor Dooley
Cc: Dan
Applied to drm-misc-next
On 13.05.2024 14:04, Jacek Lawrynowicz wrote:
> There are couple of major new features in this patchset:
> * Hardware scheduler support (disabled by default)
> * Profiling support
> * Expose NPU busy time in sysfs
>
> Other then that, there are two small random fixe
Hi Joakim,
Sorry for reply so late.
On Wed, 2024-01-31 at 14:53 +0100, Joakim Bech wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> On Fri, Jan 12, 2024 at 05:20:10PM +0800, Yong Wu wrote:
> > Add "struct res
On Fri, 2024-01-12 at 10:49 +0100, Daniel Vetter wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> On Fri, Jan 12, 2024 at 10:41:14AM +0100, Daniel Vetter wrote:
> > On Fri, Jan 12, 2024 at 05:20:11PM +0800, Yon
Hi Nicolas,
Thanks for the review.
On 15/05/24 01:52, Nicolas Dufresne wrote:
> Le samedi 11 mai 2024 à 22:38 +0530, Devarsh Thakkar a écrit :
>> Hi Andy,
>>
>> Thanks for the quick review.
>> On 10/05/24 20:40, Andy Shevchenko wrote:
>>> On Fri, May 10, 2024 at 12:10:01AM +0530, Devarsh Thakkar
On 5/15/24 06:04, Marek Vasut wrote:
> The DW HDMI driver core is responsible for parsing the 'ddc-i2c-bus' property,
> move the property description into the DW HDMI common DT schema too, so this
> property can be used on all devices integrating the DW HDMI core.
>
> Signed-off-by: Marek Vasut
>
From: Dave Airlie
When a buffer is evicted for memory pressure or TTM evict all,
the placement is set to the eviction domain, this means the
buffer never gets revalidated on the next exec to the correct domain.
I think this should be fine to use the initial domain from the
object creation, as le
The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller
which fits in nicely with the existing panel-himax-hx83102 driver. Hence,
we add a new compatible with panel specific config.
Signed-off-by: Cong Yang
Reviewed-by: Douglas Anderson
Reviewed-by: Linus Walleij
---
Chage since
The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel with himax-hx83102
controller. Hence, we add a new compatible with panel specific config.
Signed-off-by: Cong Yang
Acked-by: Conor Dooley
---
Chage since V7:
- No change.
V6:
https://lore.kernel.org/all/20240511021326.288728-7-yangco...@huaqin.c
The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller
which fits in nicely with the existing panel-himax-hx83102 driver. Hence,
we add a new compatible with panel specific config.
Signed-off-by: Cong Yang
Reviewed-by: Douglas Anderson
Reviewed-by: Linus Walleij
---
Chage s
The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel with himax-hx83102
controller. Hence, we add a new compatible with panel specific config.
Signed-off-by: Cong Yang
Acked-by: Conor Dooley
---
Chage since V7:
- No change.
V6:
https://lore.kernel.org/all/20240511021326.288728-5-yangco...@huaq
The Starry HX83102 based mipi panel should never have been part of the boe
tv101wum-n16 driver. Discussion with Doug and Linus in V1 [1], we need a
separate driver to enable the hx83102 controller.
In hx83102 driver, add DSI commands as macros. So it can add some panels
with same control model in
DRM_PANEL_HIMAX_HX83102 is being split out from DRM_PANEL_BOE_TV101WUM_NL6.
Since the arm64 defconfig had the BOE panel driver enabled, let's also
enable the himax driver.
Signed-off-by: Cong Yang
Reviewed-by: Douglas Anderson
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(
In V1, discussed with Doug and Linus [1], we need break out as separate
driver for the himax83102-j02 controller. Beacuse "starry,himax83102-j02"
and in this series "BOE nv110wum-l60" "IVO t109nw41" panels use same
controller, they have some common CMDS. So add new documentation for
this panels.
F
Discussion with Doug and Linus in V1, we need a
separate driver to enable the hx83102 controller.
So this series this series mainly Break out as separate driver
for Starry-himax83102-j02 panels from boe tv101wum driver.
Then add BOE nv110wum-l60 and IVO t109nw41 in himax-hx83102 driver.
Add comp
On Tue, May 14, 2024 at 11:15:55PM +0200, Michal Wajdeczko wrote:
>
>
> On 14.05.2024 22:31, Matthew Brost wrote:
> > On Tue, May 14, 2024 at 11:13:14AM -0700, John Harrison wrote:
> >> On 5/14/2024 07:58, Michal Wajdeczko wrote:
> >>> On 13.05.2024 18:53, John Harrison wrote:
> On 5/12/2024
On 5/13/24 17:51, Rob Clark wrote:
From: Rob Clark
When debugging faults, it is useful to know how the BO is mapped (cached
vs WC, gpu readonly, etc).
Signed-off-by: Rob Clark
---
Acked-by: Konrad Dybcio
Konrad
On 5/14/2024 13:41, Michal Wajdeczko wrote:
On 14.05.2024 20:13, John Harrison wrote:
On 5/14/2024 07:58, Michal Wajdeczko wrote:
On 13.05.2024 18:53, John Harrison wrote:
On 5/12/2024 08:36, Michal Wajdeczko wrote:
We already provide the content of the GuC log in debugsfs, but it
is in a tex
The DW HDMI driver core is responsible for parsing the 'ddc-i2c-bus' property,
move the property description into the DW HDMI common DT schema too, so this
property can be used on all devices integrating the DW HDMI core.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: Conor Dooley
Cc: Dan
On 5/14/2024 14:15, Michal Wajdeczko wrote:
On 14.05.2024 22:31, Matthew Brost wrote:
On Tue, May 14, 2024 at 11:13:14AM -0700, John Harrison wrote:
On 5/14/2024 07:58, Michal Wajdeczko wrote:
On 13.05.2024 18:53, John Harrison wrote:
On 5/12/2024 08:36, Michal Wajdeczko wrote:
We already pr
Hi Rob,
>
> On Mon, May 13, 2024 at 11:27 AM Christian König
> wrote:
> >
> > Am 10.05.24 um 18:34 schrieb Zack Rusin:
> > > Hey,
> > >
> > > so this is a bit of a silly problem but I'd still like to solve it
> > > properly. The tldr is that virtualized drivers abuse
> > > drm_driver::gem_prime_
On 14.05.2024 22:31, Matthew Brost wrote:
> On Tue, May 14, 2024 at 11:13:14AM -0700, John Harrison wrote:
>> On 5/14/2024 07:58, Michal Wajdeczko wrote:
>>> On 13.05.2024 18:53, John Harrison wrote:
On 5/12/2024 08:36, Michal Wajdeczko wrote:
> We already provide the content of the GuC
Hi,
Le mardi 14 mai 2024 à 23:45 +0300, Laurent Pinchart a écrit :
> > And finally, none of this fixes the issue that the heap allocation are not
> > being
> > accounted properly and allow of an easy memory DoS. So uaccess should be
> > granted
> > with care, meaning that defaulting a "desktop"
On Mon, May 13, 2024 at 11:06:24AM -0400, Nicolas Dufresne wrote:
> Le lundi 13 mai 2024 à 15:51 +0200, Maxime Ripard a écrit :
> > On Mon, May 13, 2024 at 09:42:00AM -0400, Nicolas Dufresne wrote:
> > > Le lundi 13 mai 2024 à 10:29 +0200, Maxime Ripard a écrit :
> > > > On Wed, May 08, 2024 at 10:
On Mon, May 13, 2024 at 11:10:00AM -0400, Nicolas Dufresne wrote:
> Le lundi 13 mai 2024 à 11:34 +0300, Laurent Pinchart a écrit :
> > On Mon, May 13, 2024 at 10:29:22AM +0200, Maxime Ripard wrote:
> > > On Wed, May 08, 2024 at 10:36:08AM +0200, Daniel Vetter wrote:
> > > > On Tue, May 07, 2024 at
On 14.05.2024 20:13, John Harrison wrote:
> On 5/14/2024 07:58, Michal Wajdeczko wrote:
>> On 13.05.2024 18:53, John Harrison wrote:
>>> On 5/12/2024 08:36, Michal Wajdeczko wrote:
We already provide the content of the GuC log in debugsfs, but it
is in a text format where each log dwor
On Tue, May 14, 2024 at 11:13:14AM -0700, John Harrison wrote:
> On 5/14/2024 07:58, Michal Wajdeczko wrote:
> > On 13.05.2024 18:53, John Harrison wrote:
> > > On 5/12/2024 08:36, Michal Wajdeczko wrote:
> > > > We already provide the content of the GuC log in debugsfs, but it
> > > > is in a text
Le samedi 11 mai 2024 à 22:38 +0530, Devarsh Thakkar a écrit :
> Hi Andy,
>
> Thanks for the quick review.
> On 10/05/24 20:40, Andy Shevchenko wrote:
> > On Fri, May 10, 2024 at 12:10:01AM +0530, Devarsh Thakkar wrote:
> > > If neither of the flags to round down (V4L2_SEL_FLAG_LE) or round up
> >
On Tue, May 14, 2024 at 2:20 PM Nirujogi, Pratap
wrote:
>
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> Hi Stephen,
>
> Thank you for reporting this warning, I will address this in the next amdgpu
> patchset I will be submitting in this week.
Should be fixed with this patch:
htt
On Mon, May 13, 2024 at 08:51:47AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> When debugging faults, it is useful to know how the BO is mapped (cached
> vs WC, gpu readonly, etc).
>
> Signed-off-by: Rob Clark
Reviewed-by: Akhil P Oommen
-Akhil
> ---
> drivers/gpu/drm/msm/adreno/adreno_g
On Wed, May 08, 2024 at 07:46:31PM +0200, Konrad Dybcio wrote:
> Memory barriers help ensure instruction ordering, NOT time and order
> of actual write arrival at other observers (e.g. memory-mapped IP).
> On architectures employing weak memory ordering, the latter can be a
> giant pain point, and
https://bugzilla.kernel.org/show_bug.cgi?id=210467
Jothi Prasath (jothiprasa...@gmail.com) changed:
What|Removed |Added
CC||jothiprasa...@gm
[AMD Official Use Only - AMD Internal Distribution Only]
Hi Stephen,
Thank you for reporting this warning, I will address this in the next amdgpu
patchset I will be submitting in this week.
Thanks,
Pratap
-Original Message-
From: Stephen Rothwell
Sent: Tuesday, May 14, 2024 3:14 AM
To
On 5/14/2024 07:58, Michal Wajdeczko wrote:
On 13.05.2024 18:53, John Harrison wrote:
On 5/12/2024 08:36, Michal Wajdeczko wrote:
We already provide the content of the GuC log in debugsfs, but it
is in a text format where each log dword is printed as hexadecimal
number, which does not scale wel
Consensus on the mailing lists is that panels shouldn't use a table of
init commands but should instead use init functions. With the recently
introduced mipi_dsi_dcs_write_seq_multi() this is not only clean/easy
but also saves space. Measuring before/after this change:
$ scripts/bloat-o-meter \
Consensus on the mailing lists is that panels shouldn't use a table of
init commands but should instead use init functions. We'll use the
same concepts as the recently introduced
mipi_dsi_generic_write_seq_multi() to make this clean/easy and also
not bloat the driver too much. Measuring before/afte
Consensus on the mailing lists is that panels shouldn't use a table of
init commands but should instead use init functions. With the recently
introduced mipi_dsi_dcs_write_seq_multi() this is not only clean/easy
but also saves space. Measuring before/after this change:
$ scripts/bloat-o-meter \
This is a mechanical conversion of the novatek-nt36672e driver to use
the new mipi_dsi_dcs_write_seq_multi(). The new function is easier for
clients to understand and using it also causes smaller code to be
generated. Specifically:
$ scripts/bloat-o-meter \
...after/panel-novatek-nt36672e.ko \
The current mipi_dsi_*_write_seq() macros are non-intutitive because
they contain a hidden "return" statement that will return out of the
_caller_ of the macro. Let's mark them as deprecated and instead
introduce some new macros that are more intuitive.
These new macros are less optimal when an er
We really don't expect these errors to be printed over and over
again. When a driver hits the error it should bail out. Just use a
normal error print.
This gives a nice space savings for users of these functions:
$ scripts/bloat-o-meter \
.../before/panel-novatek-nt36672e.ko \
.../after/panel
Through a cooperative effort between Hsin-Yi Wang and Dmitry
Baryshkov, we have realized the dev_err() in the
mipi_dsi_*_write_seq() macros was causing quite a bit of bloat to the
kernel. Let's hoist this call into drm_mipi_dsi.c by adding a "chatty"
version of the functions that includes the print
The mipi_dsi_generic_write_seq() macro makes a call to
mipi_dsi_generic_write() which returns a type ssize_t. The macro then
stores it in an int and checks to see if it's negative. This could
theoretically be a problem if "ssize_t" is larger than "int".
To see the issue, imagine that "ssize_t" is
The mipi_dsi_dcs_write_seq() macro makes a call to
mipi_dsi_dcs_write_buffer() which returns a type ssize_t. The macro
then stores it in an int and checks to see if it's negative. This
could theoretically be a problem if "ssize_t" is larger than "int".
To see the issue, imagine that "ssize_t" is 3
The consensus of many DRM folks is that we want to move away from DSI
drivers defining tables of init commands. Instead, we want to move to
init functions that can use common DRM functions. The issue thus far
has been that using the macros mipi_dsi_generic_write_seq() and
mipi_dsi_dcs_write_seq() b
On Mon, May 13, 2024 at 4:31 PM Jakub Kicinski wrote:
>
> On Fri, 10 May 2024 16:21:11 -0700 Mina Almasry wrote:
> > Device Memory TCP
>
> Sorry Mina, this is too big to apply during the merge window :(
No worries at all. I'll repost once it re-opens with any feedback I
get in the meantime.
--
Hello Rob,
On Fri, 10 May 2024 11:44:49 -0500
Rob Herring wrote:
> On Fri, May 10, 2024 at 09:10:36AM +0200, Luca Ceresoli wrote:
[...]
> > Overall approach
> >
> >
> > Device tree overlays appear as the most natural solution to support the
> > addition and removal of devices
Hi,
On 2024/5/15 00:22, Maxime Ripard wrote:
Hi,
On Tue, May 14, 2024 at 11:40:43PM +0800, Sui Jingfeng wrote:
Because a lot of implementations has already added it into their drived
class, promote it into drm_bridge core may benifits a lot. drm bridge is
a driver, it should know the underlyin
Hello Rob,
+cc Srinivas and Miquèl for the NVMEM cell discussion below
On Fri, 10 May 2024 11:36:25 -0500
Rob Herring wrote:
> On Fri, May 10, 2024 at 09:10:37AM +0200, Luca Ceresoli wrote:
> > Add bindings for the GE SUNH add-on connector. This is a physical,
> > hot-pluggable connector that a
Hi,
On Tue, May 14, 2024 at 11:40:43PM +0800, Sui Jingfeng wrote:
> Because a lot of implementations has already added it into their drived
> class, promote it into drm_bridge core may benifits a lot. drm bridge is
> a driver, it should know the underlying hardware entity.
Is there some actual be
Am 14.05.24 um 17:14 schrieb Tvrtko Ursulin:
On 13/05/2024 14:49, Tvrtko Ursulin wrote:
On 09/05/2024 13:40, Tvrtko Ursulin wrote:
On 08/05/2024 19:09, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Last few days I was looking at the situation with VRAM over
subscription, what
happens versus
The pointer of 'struct device' can also be used as a key to search drm
bridge instance from the global bridge list, traditionally, fwnode and
'OF' based APIs requires the system has decent fwnode/OF Graph support.
While the drm_find_bridge_by_dev() function introduced in this series
don't has such
Normally, the drm_bridge::of_node member won't be used by drm bridge driver
instances, as display driver instances will use the device node fetched
from its backing device directly. The drm_bridge::of_node is mainly for
finding the drm bridge instance associated. Hence, display bridge drivers
don't
Because a lot of implementations has already added it into their drived
class, promote it into drm_bridge core may benifits a lot. drm bridge is
a driver, it should know the underlying hardware entity.
Sui Jingfeng (2):
drm/bridge: Support finding bridge with struct device
drm/bridge: Switch t
Add the documentation for VOP2 video ports reset clocks.
One reset can be set per video port.
Signed-off-by: Detlev Casanova
---
.../display/rockchip/rockchip-vop2.yaml | 27 +++
1 file changed, 27 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/rockc
This adds the needed clock resets for all rk3588(s) based SOCs.
Signed-off-by: Detlev Casanova
---
arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
index 6a
At the end of initialization, each VP clock needs to be reset before
they can be used.
Failing to do so can put the VOP in an undefined state where the
generated HDMI signal is either lost or not matching the selected mode.
Signed-off-by: Detlev Casanova
---
drivers/gpu/drm/rockchip/rockchip_dr
The clock reset must be used when the VOP is configured. Skipping it can
put the VOP in an unknown state where the HDMI signal is either lost or
not matching the selected mode.
This adds support for rk3588(s) based SoCs.
Detlev Casanova (3):
drm/rockchip: vop2: Add clock resets support
arm64:
On 13/05/2024 14:49, Tvrtko Ursulin wrote:
On 09/05/2024 13:40, Tvrtko Ursulin wrote:
On 08/05/2024 19:09, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Last few days I was looking at the situation with VRAM over
subscription, what
happens versus what perhaps should happen. Browsing through
Hello,
On Tue, May 14, 2024 at 12:26:15AM +0800, Sui Jingfeng wrote:
> On 5/13/24 16:02, Liu Ying wrote:
> > The connector is created by either this ADV7511 bridge driver or
> > any DRM device driver/previous bridge driver, so this ADV7511
> > bridge driver should not let the next bridge driver cr
Hi. I recently looked at the todos of drm and found the topic
interesting. I wanted to get started with this issue but having some
trouble identifying the devices. What would be the right approach to get
started?
Thanks,
Manas
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 723adadf19b6bd8a54881b0e7d04ba56c4e8f401
commit: 723adadf19b6bd8a54881b0e7d04ba56c4e8f401 [10/10] drm-tip:
2024y-05m-14d-12h-21m-31s UTC integration manifest
reproduce:
(https://download.01.org/0day-ci/archive/20240514
On 13.05.2024 18:53, John Harrison wrote:
> On 5/12/2024 08:36, Michal Wajdeczko wrote:
>> We already provide the content of the GuC log in debugsfs, but it
>> is in a text format where each log dword is printed as hexadecimal
>> number, which does not scale well with large GuC log buffers.
>>
>
Problem statement: During the system boot time, an application request
for the bulk volume of cleared range bias memory when the clear_avail
is zero, we dont fallback into normal allocation method as we had an
unnecessary clear_avail check which prevents the fallback method leads
to fb allocation f
Allocate cleared blocks in the bias range when the DRM
buddy's clear avail is zero. This will validate the bias
range allocation in scenarios like system boot when no
cleared blocks are available and exercise the fallback
path too. The resulting blocks should always be dirty.
v1:(Matthew)
- move
This drm printer wrapper can be used to increase the robustness of
the captured output generated by any other drm_printer to make sure
we didn't lost any intermediate lines of the output by adding line
numbers to each output line. Helpful for capturing some crash data.
Signed-off-by: Michal Wajdec
u_encoder_phys_wb_wait_for_commit_done;
@@ -685,7 +695,6 @@ struct dpu_encoder_phys *dpu_encoder_phys_wb_init(struct
drm_device *dev,
dpu_encoder_phys_wb_init_ops(&phys_enc->ops);
phys_enc->intf_mode = INTF_MODE_WB_LINE;
- phys_enc->irq[INTR_IDX_WB_DONE] = phys_enc->hw_wb->caps->intr_wb_done;
atomic_set(&wb_enc->wbirq_refcount, 0);
---
base-commit: 75fa778d74b786a1608d55d655d42b480a6fa8bd
change-id: 20240514-dpu-revert-ams-9410abc1ee48
Best regards,
--
// Caleb (they/them)
In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
compile time. We thus need to #ifdef functions and their callsites which
unconditionally use these I/O accessors. In the include/video/vga.h
these are conveniently all those functions with the vga_io_* prefix.
Co-developed-by:
Hi,
This is a follow up in my ongoing effort of making inb()/outb() and
similar I/O port accessors compile-time optional. Previously I sent this
as a treewide series titled "treewide: Remove I/O port accessors for
HAS_IOPORT=n" with the latest being its 5th version[0]. With a significant
subset of
Hi
Am 14.05.24 um 14:55 schrieb Jani Nikula:
Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.
Signed-off-by: Jani Nikula
---
Cc: Xinliang Liu
Cc: Tian Tao
Cc: Xinwei Kong
Cc: Sumit Semwal
Cc: Yongqin Liu
Cc: John Stultz
Cc: Maarten Lankhorst
Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.
Signed-off-by: Jani Nikula
---
Cc: Philipp Zabel
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Pengutronix Kernel Team
Cc: Fabio Estevam
Cc: i..
Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.
Signed-off-by: Jani Nikula
---
Cc: Philipp Zabel
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Pengutronix Kernel Team
Cc: Fabio Estevam
Cc: i..
Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.
Signed-off-by: Jani Nikula
---
Cc: Thierry Reding
Cc: Mikko Perttunen
Cc: Jonathan Hunter
Cc: linux-te...@vger.kernel.org
---
drivers/gpu/drm/tegra/drm.h| 2 +-
drivers/gpu/drm/tegra/output.c |
Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.
Simplify the flow by updating the EDID property when the EDID is read
instead of at .get_modes.
Signed-off-by: Jani Nikula
---
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Sean Paul
Cc:
Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.
Signed-off-by: Jani Nikula
---
Cc: Sui Jingfeng
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
---
drivers/gpu/drm/loongson/lsdc_output_7a2000.c | 15 +++
1 file changed,
Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.
Signed-off-by: Jani Nikula
---
Cc: Sui Jingfeng
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
---
drivers/gpu/drm/loongson/lsdc_output_7a1000.c | 15 +++
1 file changed,
Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.
Signed-off-by: Jani Nikula
---
Cc: Xinliang Liu
Cc: Tian Tao
Cc: Xinwei Kong
Cc: Sumit Semwal
Cc: Yongqin Liu
Cc: John Stultz
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
---
.
Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.
The functional change is that the CEC physical address gets invalidated
when the EDID could not be read.
Signed-off-by: Jani Nikula
---
Cc: Inki Dae
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Krzysztof
Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.
Signed-off-by: Jani Nikula
---
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zi
Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.
The functional change is that the CEC physical address gets invalidated
when the EDID could not be read.
Signed-off-by: Jani Nikula
---
Cc: Alain Volmat
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Th
The dimensions are available in display info, so there's no need for raw
EDID access. While at it, move the debug logging to where the EDID is
actually read.
Signed-off-by: Jani Nikula
---
Cc: Sandy Huang
Cc: "Heiko Stübner"
Cc: Andy Yan
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Z
Convert more drivers to struct drm_edid.
Compile tested only.
Jani Nikula (11):
drm/rockchip: cdn-dp: get rid of drm_edid_raw()
drm/sti/sti_hdmi: convert to struct drm_edid
drm/bridge: analogix_dp: convert to struct drm_edid
drm/exynos: hdmi: convert to struct drm_edid
drm/hisilicon/hib
Hi Janusz,
On Tue, Apr 23, 2024 at 06:23:10PM +0200, Janusz Krzysztofik wrote:
> From: Chris Wilson
>
> The breadcrumbs use a GT wakeref for guarding the interrupt, but are
> disarmed during release of the engine wakeref. This leaves a hole where
> we may attach a breadcrumb just as the engine i
Hi
Am 14.05.24 um 14:34 schrieb Manas Ghandat:
Hi. I recently looked at the todos of drm and found the topic
interesting. I wanted to get started with this issue but having some
trouble identifying the devices. What would be the right approach to
get started?
Sorry, there's already someone w
Il 14/05/24 11:46, Alexandre Mergnat ha scritto:
Hi Angelo,
Gentle ping because I'm stuck if I rebase my serie on top of yours.
Sorry, I was unable to find time to get back to this... I plan to look at it
between today and tomorrow.
In the meanwhile - does your platform use OVL_ADAPTOR?
If
5.15-stable review patch. If anyone has any objections, please let me know.
--
From: Zack Rusin
commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.
Correctly set the length of the drm_event to the size of the structure
that's actually used.
The length of the drm_event w
5.10-stable review patch. If anyone has any objections, please let me know.
--
From: Zack Rusin
commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.
Correctly set the length of the drm_event to the size of the structure
that's actually used.
The length of the drm_event w
5.4-stable review patch. If anyone has any objections, please let me know.
--
From: Zack Rusin
commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.
Correctly set the length of the drm_event to the size of the structure
that's actually used.
The length of the drm_event wa
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Zack Rusin
commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.
Correctly set the length of the drm_event to the size of the structure
that's actually used.
The length of the drm_event w
6.1-stable review patch. If anyone has any objections, please let me know.
--
From: Zack Rusin
commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.
Correctly set the length of the drm_event to the size of the structure
that's actually used.
The length of the drm_event wa
6.6-stable review patch. If anyone has any objections, please let me know.
--
From: Zack Rusin
commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.
Correctly set the length of the drm_event to the size of the structure
that's actually used.
The length of the drm_event wa
6.6-stable review patch. If anyone has any objections, please let me know.
--
From: Zack Rusin
commit 27906e5d78248b19bcdfdae72049338c828897bb upstream.
Stop printing the TT memory decryption status info each time tt is created
and instead print it just once.
Reduces the spam
Use the new KMEM_CACHE() macro instead of direct kmem_cache_create
to simplify the creation of SLAB caches.
Signed-off-by: cuitao
---
drivers/gpu/drm/lima/lima_sched.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_sched.c
b/drivers/gpu/drm/lima
Use the new KMEM_CACHE() macro instead of direct kmem_cache_create
to simplify the creation of SLAB caches.
Signed-off-by: cuitao
---
drivers/gpu/drm/xe/xe_hw_fence.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_hw_fence.c b/drivers/gpu/drm/xe/xe_h
Simplify child iteration using for_each_child macro
instead of using manual for loop. There is no functional
change.
Cc: John Harrison
Cc: Tvrtko Ursulin
Signed-off-by: Nirmoy Das
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 64 ++-
1 file changed, 33 insertions(+), 31 d
6.8-stable review patch. If anyone has any objections, please let me know.
--
From: Zack Rusin
commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.
Correctly set the length of the drm_event to the size of the structure
that's actually used.
The length of the drm_event wa
6.8-stable review patch. If anyone has any objections, please let me know.
--
From: Zack Rusin
commit 27906e5d78248b19bcdfdae72049338c828897bb upstream.
Stop printing the TT memory decryption status info each time tt is created
and instead print it just once.
Reduces the spam
On 4/24/24 11:03 AM, Manikandan Muralidharan wrote:
> Replace regmap_read with regmap_read_poll_timeout to neatly handle
> retries
>
Reviewed-by: Hari Prasath Gujulan Elango
> Signed-off-by: Manikandan Muralidharan
> ---
> .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 44 +++-
Hi Angelo,
Gentle ping because I'm stuck if I rebase my serie on top of yours.
On 02/05/2024 18:53, Alexandre Mergnat wrote:
On 30/04/2024 13:33, AngeloGioacchino Del Regno wrote:
Il 30/04/24 12:17, Alexandre Mergnat ha scritto:
Hi Angelo,
On 09/04/2024 14:02, AngeloGioacchino Del Regno wr
1 - 100 of 112 matches
Mail list logo
