+Cc: dri-devel@lists.freedesktop.org
On 30/11/24 - 13:49, Ananta Srikar Puranam wrote:
> Dear Louis Chauvet,
Hi Srikar!
> I was able to successfully compile Linux with VKMS enabled and have set up
> igt-gpu-tests in a QEMU machine. I can now run some tests successfully.
Congratulation!
> I h
The no_capture_mute flag might differ from platform to platform,
especially in the case of the wrapping implementations, like the
upcoming DRM HDMI Codec framework. Move the flag next to all other flags
in struct hdmi_codec_pdata.
Acked-by: Mark Brown
Signed-off-by: Dmitry Baryshkov
---
drivers
Drop driver-specific implementation and use the generic HDMI Codec
framework in order to implement the HDMI audio support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 68 ++
drivers/gpu/drm/vc4/vc4_hdmi.h | 2 --
2 files changed,
Make the Lontium LT9611 DSI-to-HDMI bridge driver use the DRM HDMI Codec
framework. This enables programming of Audio InfoFrames using the HDMI
Connector interface and also enables support for the missing features,
including the ELD retrieval and better hotplug support.
Signed-off-by: Dmitry Barys
Use the helper function to update the connector's information. This
makes sure that HDMI-related events are handled in a generic way.
Currently it is limited to the HDMI state reporting to the sound system.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 9 +++--
1 file
Extend drm_bridge_connector code to read the EDID and use it to update
connector status if the bridge chain implements HDMI bridge. Performing
it from the generic location minimizes individual bridge's code and
enforces standard behaviour from all corresponding drivers.
Signed-off-by: Dmitry Barys
The HDMI Connectors need to perform a variety of tasks when the HDMI
connector state changes. Such tasks include setting or invalidating CEC
address, notifying HDMI codec driver, updating scrambler data, etc.
Implementing such tasks in a driver-specific callbacks is error prone.
Start implementing
The upcoming DRM connector HDMI codec implementation is going to use
codec-specific data in the .get_dai_id to get drm_connector. Pass data
to the callback, as it is done with other hdmi_codec_ops callbacks.
Acked-by: Mark Brown
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/adv7511
Add necessary glue code to be able to use new HDMI codec framework from
the DRM bridge drivers. The drm_bridge implements a limited set of the
hdmi_codec_ops interface, with the functions accepting both
drm_connector and drm_bridge instead of just a generic void pointer.
This framework is integrat
Several DRM drivers implement HDMI codec support (despite its name it
applies to both HDMI and DisplayPort drivers). Implement generic
framework to be used by these drivers. This removes a requirement to
implement get_eld() callback and provides default implementation for
codec's plug handling.
Th
While porting lt9611 DSI-to-HDMI bridge driver to use HDMI Connector
framework, I stumbled upon an issue while handling the Audio InfoFrames.
The HDMI codec callbacks weren't receiving the drm_atomic_state, so
there was no simple way to get the drm_connector that stayed at the end
of the bridge cha
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/sti/sti_hdmi.c | 2 ++
1 file changed, 2 insertions(+
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 4 ++--
1 file changed, 2 insertions
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 2 ++
1 file changed, 2 insert
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/radeon/radeon_audio.c | 2 ++
1 file changed, 2 inser
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_audio.c | 2 ++
1 file changed, 2 insertion
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/i915/display/intel_audio.c | 3 +++
1 file changed, 3
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
1 file chan
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/ite-it66121.c | 2 ++
1 file changed, 2 insert
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 2 ++
1 file changed, 2 i
The connector->eld is accessed by the .get_eld() callback. This access
can collide with the drm_edid_to_eld() updating the data at the same
time. Add drm_connector.eld_mutex to protect the data from concurrenct
access. Individual drivers are not updated (to reduce possible issues
while applying the
The connector->eld is accessed by the .get_eld() callback. This access
can collide with the drm_edid_to_eld() updating the data at the same
time. Add drm_connector.eld_mutex to protect the data from concurrenct
access.
The individual drivers were just compile tested. I propose to merge the
drm_con
On 11/29/2024 9:03 PM, Konrad Dybcio wrote:
> On 28.11.2024 11:25 AM, Neil Armstrong wrote:
>> The Adreno GPU Management Unit (GMU) can also scale the DDR Bandwidth
>> along the Frequency and Power Domain level, until now we left the OPP
>> core scale the OPP bandwidth via the interconnect path.
>>
On 11/28/2024 3:55 PM, Neil Armstrong wrote:
> The Adreno GPU Management Unit (GMU) can also scale DDR Bandwidth along
> the Frequency and Power Domain level, but by default we leave the
> OPP core scale the interconnect ddr path.
>
> While scaling via the interconnect path was sufficient, newer G
On 11/28/2024 3:55 PM, Neil Armstrong wrote:
> Even if the code uses ARRAY_SIZE() to fill those tables,
> it's still a best practice to not use magic values for
> tables in structs.
>
> Suggested-by: Dmitry Baryshkov
> Signed-off-by: Neil Armstrong
Reviewed-by: Akhil P Oommen
-Akhil
> ---
>
On 11/27/2024 9:17 PM, neil.armstr...@linaro.org wrote:
> On 27/11/2024 16:29, Akhil P Oommen wrote:
>> On 11/25/2024 1:42 PM, Neil Armstrong wrote:
>>> On 23/11/2024 23:46, Akhil P Oommen wrote:
On Sun, Nov 24, 2024 at 02:52:46AM +0530, Akhil P Oommen wrote:
> On Tue, Nov 19, 2024 at 06:5
On 11/30/2024 7:01 PM, Konrad Dybcio wrote:
> On 25.11.2024 5:33 PM, Akhil P Oommen wrote:
>> There are a few chipsets which don't have system cache a.k.a LLC.
>> Currently, the assumption in the driver is that the system cache
>> availability correlates with the presence of GMU or RPMH, which
>> i
Hi Damon,
Am Freitag, 29. November 2024, 03:43:57 CET schrieb Damon Ding:
> On 2024/11/27 19:04, Heiko Stübner wrote:
> > Am Mittwoch, 27. November 2024, 12:00:10 CET schrieb Damon Ding:
> >> On 2024/11/27 17:29, Heiko Stübner wrote:
> >>> Am Mittwoch, 27. November 2024, 08:51:51 CET schrieb Damon
On Sat, Nov 30, 2024 at 07:57:17PM +0100, Nikolaus Voss wrote:
> Hi Dmitry,
>
> On Sat, 30 Nov 2024, Dmitry Baryshkov wrote:
> > On Tue, Nov 26, 2024 at 04:45:54PM +0100, Nikolaus Voss wrote:
> > > LDB clock has to be a fixed multiple of the pixel clock.
> > > As LDB and pixel clock are derived fr
From: Jens Glathe
Add compatible values for the HP Omnibook X Laptop 14-fe0750ng,
using "hp,omnibook-x14"
The laptop is based on the Snapdragon X Elite (x1e80100) SoC.
PDF link: https://www8.hp.com/h20195/V2/GetPDF.aspx/c08989140
Acked-by: Krzysztof Kozlowski
Signed-off-by: Jens Glathe
---
From: Jens Glathe
Introduce device tree for the HP Omnibook X Laptop 14-fe0750ng
(hp-omnibook-x14). It is a Laptop based on the Qualcomm Snapdragon
X Elite SoC. There seem to be other SKUs, some with Wifi-7 (WCN7850)
instead of Wifi-6E (WCN6855). This dt explicitly supports WCN6855,
I haven't fou
From: Jens Glathe
add "hp,omnibook-x14" as compatible device for QSEECOM
This is required to get access to efivars and uefi boot loader support.
Signed-off-by: Jens Glathe
---
drivers/firmware/qcom/qcom_scm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/firmware/qcom/qcom_scm.c
From: Jens Glathe
Seems to be like NV140DRM-N61 but with touch. Haven't disassembled
the lid to look.
Due to lack of information, use the delay_200_500_e200 timings like
many other BOE panels do for now.
The raw EDID of the panel is:
00 ff ff ff ff ff ff 00 09 e5 93 0c 00 00 00 00
25 21 01 04
Introduce device tree for the HP Omnibook X Laptop 14-fe0750ng
(hp-omnibook-x14). It is a Laptop based on the Qualcomm Snapdragon
X Elite SoC. There seem to be other SKUs, some with Wifi-7 (WCN7850)
instead of Wifi-6E (WCN6855). This dt explicitly supports WCN6855,
I haven't found a good way yet to
On 11/30/24 10:38 AM, Dmitry Baryshkov wrote:
> On Sat, Nov 30, 2024 at 01:56:31AM +0200, Cristian Ciocaltea wrote:
>> Provide the basic support to enable using YUV420 as an RGB fallback when
>> computing the best output format and color depth.
>
> The HDMI Connector functionality has pretty good
On Mon, Nov 04, 2024 at 01:41:03PM -0800, Zhanjun Dong wrote:
> GuC to host communication is interrupt driven, the handling has 3
> parts: interrupt context, tasklet and request queue worker.
> During GuC reset prepare, interrupt is disabled before destroy
> contexts steps start. The IRQ and worker
Hello,
On Mon, Nov 25, 2024 at 05:33:06PM +0800, Liu Ying wrote:
> +struct platform_driver dc_de_driver = {
> + .probe = dc_de_probe,
> + .remove_new = dc_de_remove,
Please use .remove here. Also in a few other patches of this series.
Best regards
Uwe
> + .driver = {
> +
On Sat, 30 Nov 2024 at 10:29, Dmitry Baryshkov
wrote:
> > +
> > +static int summit_resume(struct device *dev)
> > +{
> > + return summit_set_brightness(dev);
>
> Doesn't the generic code already handle that for you?
Apparently not, I have commented out the pm ops, entered sleep
and the displa
After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.
Convert all platform drivers below drivers/auxdisplay to use .remove(),
with the eventual goal to drop struct platform_driver::remove_new().
> Because the of_dma_configure() will returns '-EPROBE_DEFER' if the probe
return?
…
> Stop pretending that it will always suceess, quit if it fail.
succeed?failed?
How do you think about to add any tags (
On 25.11.2024 5:33 PM, Akhil P Oommen wrote:
> There are a few chipsets which don't have system cache a.k.a LLC.
> Currently, the assumption in the driver is that the system cache
> availability correlates with the presence of GMU or RPMH, which
> is not true. For instance, Snapdragon 6 Gen 1 has R
Update my email address as I am no longer working at Bootlin and have
started my own consulting company: sys-base.
Signed-off-by: Paul Kocialkowski
---
MAINTAINERS | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index c1fcc56bf2fb..ce165fd
On 25.11.2024 8:11 PM, Maud Spierings via B4 Relay wrote:
> From: Maud Spierings
>
> The Asus vivobook s15 uses the ATNA56AC03 panel.
> This panel is controlled by the atna33xc20 driver instead of the generic
> edp-panel driver
>
> Signed-off-by: Maud Spierings
> ---
Reviewed-by: Konrad Dybcio
On Sat, Nov 30, 2024 at 12:15:25PM +0100, Sasha Finkelstein wrote:
> On Sat, 30 Nov 2024 at 10:29, Dmitry Baryshkov
> wrote:
> > > +
> > > +static int summit_resume(struct device *dev)
> > > +{
> > > + return summit_set_brightness(dev);
> >
> > Doesn't the generic code already handle that for
Hi Jocelyn,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 44cff6c5b0b17a78bc0b30372bcd816cf6dd282a]
url:
https://github.com/intel-lab-lkp/linux/commits/Jocelyn-Falempe/drm-i915-fbdev-Add-intel_fbdev_getvaddr/20241130-002536
base
On Tue, Nov 26, 2024 at 09:38:00AM +0800, Yongbang Shi wrote:
>
> 在 2024/11/22 9:42, Dmitry Baryshkov 写道:
> > On Mon, Nov 18, 2024 at 10:28:01PM +0800, Yongbang Shi wrote:
> > > From: baihan li
> > >
> > > Add dp aux read/write functions. They are basic functions
> > > and will be used later.
>
On Tue, Nov 26, 2024 at 09:42:45AM +, Bauer, Markus wrote:
> sn65dsi83.c: fix dual-channel LVDS output also divide porches
Please use drm/bridge: ti-sn65dsi83: as subject prefix. Drop the first
line of the commit message.
>
> When generating dual-channel LVDS to a single display, the
> horiz
On Tue, Nov 26, 2024 at 06:57:14PM +0530, Uma Shankar wrote:
> From: Chaitanya Kumar Borah
>
> Add helper to initialize 1D segmented LUT
>
> Signed-off-by: Chaitanya Kumar Borah
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/drm_colorop.c | 27 ++-
> include/drm/
On Tue, Nov 26, 2024 at 06:57:12PM +0530, Uma Shankar wrote:
> From: Chaitanya Kumar Borah
>
> Add support for color ops that can be programmed
> by 1 dimensional multi segmented Look Up Tables.
>
> Signed-off-by: Chaitanya Kumar Borah
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/drm_
On Tue, Nov 26, 2024 at 06:57:10PM +0530, Uma Shankar wrote:
> Add capability property which a colorop can expose it's
> hardware's abilities. It's a blob property that can be
> filled with respective data structures depending on the
> colorop. The user space is expected to read this property
> and
On Tue, Nov 26, 2024 at 06:57:07PM +0530, Uma Shankar wrote:
> From: Chaitanya Kumar Borah
>
> Add support for 3x3 Color Transformation Matrices in Color Pipeline.
>
> Signed-off-by: Chaitanya Kumar Borah
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/drm_atomic.c | 3 +++
> drive
On Tue, Nov 26, 2024 at 04:45:54PM +0100, Nikolaus Voss wrote:
> LDB clock has to be a fixed multiple of the pixel clock.
> As LDB and pixel clock are derived from different clock sources
> (at least on imx8mp), this constraint cannot be satisfied for
> any pixel clock, which leads to flickering an
On Tue, Nov 26, 2024 at 05:34:22PM +0100, Sasha Finkelstein via B4 Relay wrote:
> From: Sasha Finkelstein
>
> This is the display panel used for the touchbar on laptops that have it.
>
> Co-developed-by: Nick Chan
> Signed-off-by: Nick Chan
> Signed-off-by: Sasha Finkelstein
> ---
> drivers/
On Wed, Nov 27, 2024 at 11:02:20AM +0800, Xin Ji wrote:
> Update HDCP content_protection to DRM_MODE_CONTENT_PROTECTION_UNDESIRED
> in bridge .atomic_disable().
PLease describe why, not what.
>
> Signed-off-by: Xin Ji
> ---
> drivers/gpu/drm/bridge/analogix/anx7625.c | 25 ++---
On Wed, Nov 27, 2024 at 03:51:53PM +0800, Damon Ding wrote:
> Add support to configurate link rate, lane count, voltage swing and
> pre-emphasis with phy_configure(). It is helpful in application scenarios
> where analogix controller is mixed with the phy of other vendors.
>
> Signed-off-by: Damon
On Sat, Nov 30, 2024 at 01:56:32AM +0200, Cristian Ciocaltea wrote:
> Evaluating the requirement to use a limited RGB quantization range
> involves a verification of the output format, among others, but this is
> currently performed before actually computing the format, hence relying
> on the old c
On Sat, Nov 30, 2024 at 01:56:33AM +0200, Cristian Ciocaltea wrote:
> Provide the necessary constraints verification in
> sink_supports_format_bpc() in order to support handling of YUV420
> output format.
>
> Signed-off-by: Cristian Ciocaltea
> ---
> drivers/gpu/drm/display/drm_hdmi_state_helper
On Sat, Nov 30, 2024 at 01:56:34AM +0200, Cristian Ciocaltea wrote:
> Introduce the switch to YUV420 when computing the best output format and
> RGB cannot be supported for a given color depth.
>
> While at it, add a minor improvement to the debug message indicating the
> supported format.
>
> Si
420 output format as an RGB fallback
>
> drivers/gpu/drm/display/drm_hdmi_state_helper.c | 55
> -
> 1 file changed, 45 insertions(+), 10 deletions(-)
> ---
> base-commit: f486c8aa16b8172f63bddc70116a0c897a7f3f02
> change-id: 20241130-hdmi-conn-yuv-e1fa596df768
>
--
With best wishes
Dmitry
On Wed, Nov 27, 2024 at 02:35:45PM -0600, Guy Chronister wrote:
> Signed-off-by: Guy Chronister
> ---
> drivers/gpu/drm/drm_panel_orientation_quirks.c | 7 +++
> 1 file changed, 7 insertions(+)
It seems that you didn't break the subject / commit message properly.
Please add an empty line aft
On Tue, Nov 26, 2024 at 02:12:19PM +, Sandor Yu wrote:
>
> >
> > On Tue, Nov 05, 2024 at 02:05:51PM +, Sandor Yu wrote:
> > > >
> > > > On Tue, Oct 29, 2024 at 02:02:14PM +0800, Sandor Yu wrote:
> > > > > Add Cadence HDP-TX DisplayPort and HDMI PHY driver for i.MX8MQ.
> > > > >
> > > > >
On Tue, Nov 26, 2024 at 02:12:04PM +, Sandor Yu wrote:
> >
> >
> > On 5 November 2024 14:05:51 GMT, Sandor Yu wrote:
> > >>
> > >> On Tue, Oct 29, 2024 at 02:02:14PM +0800, Sandor Yu wrote:
> > >> > Add Cadence HDP-TX DisplayPort and HDMI PHY driver for i.MX8MQ.
> > >> >
> > >> > Cadence HDP
62 matches
Mail list logo
