On 21/03/24 12:17, Jani Nikula wrote:
> On Thu, 21 Mar 2024, Aravind Iddamsetty
> wrote:
>> On 21/03/24 02:23, Rodrigo Vivi wrote:
>>> On Wed, Mar 20, 2024 at 04:14:25PM +0530, Aravind Iddamsetty wrote:
In scenarios where drm_dev_put is directly called by driver we want to
release devm
On Tue, 19 Mar 2024, Jani Nikula wrote:
> Resend because I forgot to Cc: dri-devel on the original submission.
Pushed to drm-intel-next, thanks for the reviews and acks.
BR,
Jani.
>
> Jani Nikula (6):
> drm/mst: read sideband messaging cap
> drm/i915/mst: improve debug logging of DP MST mod
On 20/03/2024 18:04, Conor Dooley wrote:
> On Wed, Mar 13, 2024 at 07:28:55PM +0100, Krzysztof Kozlowski wrote:
>
>> + clock-names:
>> +items:
>> + - const: dp
>
>> + phy-names:
>> +items:
>> + - const: dp
>
> The items lists here are redundant when you only have a single ite
On Thu, Mar 21, 2024 at 03:07:52PM +0800, Guo Mengqi wrote:
> commit 73a82b22963d ("drm/atomic: Fix potential use-after-free
> in nonblocking commits") introduced drm_dev_get/put() to
> drm_atomic_helper_shutdown(). And this cause problem in vkms driver exit
> process.
>
> vkms_exit()
> drm_dev_
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 helper ast_i2c_create() to ddc-like terms. No functio
lyesconfig
(https://download.01.org/0day-ci/archive/20240321/202403211604.am8tdovd-...@intel.com/config)
compiler: m68k-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240321/202403211604.am8tdovd-...@intel.com/reproduce)
If you fix the issue in a sepa
Hi Maxime,
> On 20 Mar 2024, at 14.23, Maxime Ripard wrote:
>
> Hi Sean,
>
> On Fri, Mar 08, 2024 at 09:35:27AM +0100, Sean Nyekjaer wrote:
>> I’m using a stm32mp157 with a sn65dsi83 DSI2LVDS bridge. The LVDS
>> display is having a minimum clock of 25.2 MHz, typical of 27,2 MHz and
>> a max of
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 h
Hi Raphael,
> On 20 Mar 2024, at 15.14, Raphael Gallais-Pou
> wrote:
>
>
> On 3/8/24 09:35, Sean Nyekjaer wrote:
>> Hi,
>
>
> Hi Sean,
>
>
> Sorry for not responding earlier.
NP :)
>
> I've also added Antonio Borneo, which is the author of the implementation of
> the
> mode_valid() hoo
Hi,
On 2024/3/20 17:34, Thomas Zimmermann wrote:
Implement polling for VGA and SIL164 connectors. Set the flag
DRM_CONNECTOR_POLL_DISCONNECT for each to detect the removal of the
monitor cable. Implement struct drm_connector_helper_funcs.detect_ctx
for each type of connector by testing for EDID
Hi,
On 2024/3/20 17:34, Thomas Zimmermann wrote:
Automatically clean up the conncetor-poll thread as part of the DRM
device release. The new helper drmm_kms_helper_poll_init() provides
a shared implementation for all drivers.
Signed-off-by: Thomas Zimmermann
Nice feature!
It seems that dr
Il 01/02/24 13:53, AngeloGioacchino Del Regno ha scritto:
This series performs some cleanups for DDP component CRTC search and
correctly iounmaps the previously of_iomap() calls from drm_ddp_comp.
Tested on MT8195 Cherry Tomato
Hello CK,
gentle ping for this series.
Cheers,
Angelo
AngeloGi
commit 73a82b22963d ("drm/atomic: Fix potential use-after-free
in nonblocking commits") introduced drm_dev_get/put() to
drm_atomic_helper_shutdown(). And this cause problem in vkms driver exit
process.
vkms_exit()
drm_dev_put()
vkms_release()
drm_atomic_helper_shutdown()
drm_de
在 2024/3/21 15:39, Greg KH 写道:
On Thu, Mar 21, 2024 at 03:07:52PM +0800, Guo Mengqi wrote:
commit 73a82b22963d ("drm/atomic: Fix potential use-after-free
in nonblocking commits") introduced drm_dev_get/put() to
drm_atomic_helper_shutdown(). And this cause problem in vkms driver exit
process.
Jani Nikula (3):
drm/displayid: move drm_displayid.h to drm_displayd_internal.h
drm/edid: move all internal declarations to drm_crtc_internal.h
drm/edid: group struct drm_edid based declarations together
drivers/gpu/drm/drm_crtc_internal.h | 6 ++
drivers/gpu/drm/drm_
There are no exported symbols for displayid, and it's all internal
interfaces. Move the header to drivers/gpu/drm/drm_displayd_internal.h.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_displayid.c | 3 ++-
.../gpu/drm/drm_displayid_internal.h
The declarations for internal EDID functions are a bit scattered. Put
them all in drm_crtc_internal.h.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_crtc_internal.h | 6 ++
drivers/gpu/drm/drm_displayid.c | 1 +
drivers/gpu/drm/drm_eld.c | 4 +++-
drivers/gpu/drm/drm_inter
Keep the declarations for struct drm_edid based functions together.
Signed-off-by: Jani Nikula
---
include/drm/drm_edid.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 6eadc4f12c07..19814bb1103c 100644
--- a/incl
Am 20.03.24 um 20:44 schrieb Sunil Khatri:
Refractor devcoredump code into new files since its
functionality is expanded further and better to slit
and devcoredump to have its own file.
Signed-off-by: Sunil Khatri
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/Makefile
Hi
Am 21.03.24 um 10:00 schrieb Sui Jingfeng:
Hi,
On 2024/3/20 17:34, Thomas Zimmermann wrote:
Automatically clean up the conncetor-poll thread as part of the DRM
device release. The new helper drmm_kms_helper_poll_init() provides
a shared implementation for all drivers.
Signed-off-by: Thoma
Add a struct drm_edid based function to get the vendor and product ID
from an EDID. Add a separate struct for defining this part of the EDID,
with defined byte order for product code and serial number.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 15 +++
include/drm/dr
Jani Nikula (4):
drm/edid: add drm_edid_get_product_id()
drm/edid: add drm_edid_print_product_id()
drm/i915/bios: switch to struct drm_edid and struct
drm_edid_product_id
drm/i915/bios: return drm_edid_product_id from get_lvds_pnp_id()
drivers/gpu/drm/drm_edid.c| 50
To avoid accessing and parsing the raw EDID with drm_edid_raw(), switch
to the struct drm_edid based function to extract product id, and use the
drm printer function to debug log it.
The underlying assumption is that struct drm_edid_product_id and struct
lvds_pnp_id describe identical data, albeit
Add a function to print a decoded EDID vendor and product id to a drm
printer, optinally with the raw data.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 35 +++
include/drm/drm_edid.h | 3 +++
2 files changed, 38 insertions(+)
diff --git a/dri
Use a more suitable type to avoid the cast.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_bios.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 5e111a8cce
On 21/03/24 02:22, Rodrigo Vivi wrote:
> On Wed, Mar 20, 2024 at 04:14:26PM +0530, Aravind Iddamsetty wrote:
>> PCI subsystem provides callbacks to inform the driver about a request to
>> do function level reset by user, initiated by writing to sysfs entry
>> /sys/bus/pci/devices/.../reset. This
On 21/03/24 04:31, Lucas De Marchi wrote:
> On Wed, Mar 20, 2024 at 04:14:26PM +0530, Aravind Iddamsetty wrote:
>> PCI subsystem provides callbacks to inform the driver about a request to
>> do function level reset by user, initiated by writing to sysfs entry
>> /sys/bus/pci/devices/.../reset. Th
On Thu, Mar 21, 2024 at 08:37:15AM +0100, Krzysztof Kozlowski wrote:
> On 20/03/2024 18:04, Conor Dooley wrote:
> > On Wed, Mar 13, 2024 at 07:28:55PM +0100, Krzysztof Kozlowski wrote:
> >
> >> + clock-names:
> >> +items:
> >> + - const: dp
> >
> >> + phy-names:
> >> +items:
> >> +
Hi,
Thanks for those patches, that's really a good enhancement to the ast
driver, and fits well with the BMC virtual connector.
I've reviewed the whole series, and it looks good to me.
Reviewed-by: Jocelyn Falempe
--
Jocelyn
On 20/03/2024 10:34, Thomas Zimmermann wrote:
Detect the statu
drm-misc-next-2024-03-21-1:
drm-misc-next for v6.10:
UAPI Changes:
- Move some nouveau magic constants to uapi.
Cross-subsystem Changes:
- Move drm-misc to gitlab and freedesktop hosting.
- Add entries for panfrost.
Core Changes:
- Improve placement for TTM bo's in idle/busy handling.
- Improve
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 operations, if necessary
> + *
> + * Det
Hi Heiko,
On 3/20/24 14:12, Heiko Stuebner wrote:
From: Heiko Stuebner
Similar to other variants, the LTK050H3148W wants to run in video mode
when displaying data. So far only the Synopsis DSI driver was using this
panel and it is always switching to video mode, independent of this flag
being
Hi Heiko,
On 3/20/24 14:12, Heiko Stuebner wrote:
From: Heiko Stuebner
The init sequence specifies the 0x11 and 0x29 dsi commands, which are
the exit-sleep and display-on commands.
In the actual prepare step the driver already uses the appropriate
function calls for those, so drop the duplica
Commit 9bb66c179f50 ("drm/i915: Reserve some kernel space per
vm") has reserved an object for kernel space usage.
Userspace, though, needs to know the full address range.
In the former patch the reserved space was substructed from the
total amount of the VM space. Add it back when the user reques
Hi,
Here's a series that creates some extra infrastructure specifically
targeted at HDMI controllers.
The idea behind this series came from a recent discussion on IRC during
which we discussed infoframes generation of i915 vs everything else.
Infoframes generation code still requires some decent
A lot of the various HDMI drivers duplicate some logic that depends on
the HDMI spec itself and not really a particular hardware
implementation.
Output BPC or format selection, infoframe generation are good examples
of such areas.
This creates a lot of boilerplate, with a lot of variations, which
We just introduced a new initialization function for our connectors, so
let's build a kunit test suite for it as well.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 123 +
1 file changed, 123 insertions(+)
We'll add automatic selection of the output BPC in a following patch,
but let's add it to the HDMI connector state already.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c | 5 +
drivers/gpu/drm/drm_atomic_state_helper.c | 20 +++
The next features we will need to share across drivers will need to
store some parameters for drivers to use, such as the selected output
format.
Let's create a new connector sub-state dedicated to HDMI controllers,
that will eventually store everything we need.
Reviewed-by: Dave Stevenson
Signe
Now that we're tracking the output bpc count in the connector state,
let's add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/Makefile | 1 +
.../gpu/drm/tests/drm_atomic_state_helper_test.c
Just like BPC, we'll add support for automatic selection of the output
format for HDMI connectors.
Let's add the needed defaults and fields for now.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c | 2 ++
drivers/gpu/drm/drm_atom
A lot of HDMI drivers have some variation of the formula to calculate
the TMDS character rate from a mode, but few of them actually take all
parameters into account.
Let's create a helper to provide that rate taking all parameters into
account.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime R
The previous patch added an helper to compute the TMDS character rate on
an HDMI connector. Let's add a few tests to make sure it works as
expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 323 +
1 fil
Now that we track the HDMI output format as part of the connector state,
let's add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests/drm_atomic_state_helper_test.c | 32 +++
drivers/gpu/drm/tests/drm_connector_tes
The previous patch adds a new hook for HDMI connectors to filter out
configurations based on the TMDS character rate. Let's add some tests to
make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests/drm_atomic_state_helper_test.c | 65
Most HDMI drivers have some code to calculate the TMDS character rate,
usually to adjust an internal clock to match what the mode requires.
Since the TMDS character rates mostly depends on the resolution, whether
we need to repeat pixels or not, the bpc count and the format, we can
now derive it f
The previous patch stores in the connector state the expected TMDS
character rate matching the configuration of the HDMI connector. Let's
add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests/drm_atomic_state_helper_tes
Most of the HDMI controllers have an upper TMDS character rate limit
they can't exceed. On "embedded"-grade display controllers, it will
typically be lower than what high-grade monitors can provide these days,
so drivers will filter the TMDS character rate based on the controller
capabilities.
To
Now that we have all the infrastructure needed, we can add some code
that will, for a given connector state and mode, compute the best output
format and bpc.
The algorithm is equivalent to the one already found in i915 and vc4.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic_state_h
The previous patch added the bpc and format an HDMI connector needs to
be set up with for a given connector state.
Let's add a few tests to make sure it works as expected.
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests/drm_atomic_state_helper_test.c | 507 +
drivers/gp
The previous commit added the infrastructure to the connector state to
track what RGB Quantization should be used in a given state for an HDMI
connector.
Let's add some kunit tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests
This had a bunch of kunit tests to make sure our code to handle the
Broadcast RGB property behaves properly.
This requires bringing a bit of infrastructure to create mock HDMI
connectors, with custom EDIDs.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests/drm_atom
The i915 driver has a property to force the RGB range of an HDMI output.
The vc4 driver then implemented the same property with the same
semantics. KWin has support for it, and a PR for mutter is also there to
support it.
Both drivers implementing the same property with the same semantics,
plus th
HDMI controller drivers will need to figure out the RGB range they need
to configure based on a mode and property values. Let's expose that in
the HDMI connector state so drivers can just use that value.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c
The vc4_dummy_plane structure was introduced as a mean to add
mock-specific fields.
However, we never really used it and it's still strictly equivalent to
vc4_plane (which is in the same situation vs drm_plane), so we can
simply remove the vc4_dummy_plane structure and make the mock code
cleaner.
The new HDMI connector infrastructure allows us to remove a lot of
boilerplate, so let's switch to it.
Acked-by: Sui Jingfeng
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 643 +
drivers/gpu/drm/vc4/vc4_hdmi.h | 44 +--
drivers/gp
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 generate them in the HDMI
connector state, we can gen
The previous patch added the generation of the infoframes matching an
HDMI connector state. Let's add a few tests to make sure it works as
expected.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 219 +
1 file changed, 219 insertions(+)
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Reviewed-by: Heiko Stuebner
Acked-by: Heiko Stuebner
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 143 +--
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Reviewed-by: Jernej Skrabec
Acked-by: Sui Jingfeng
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 80 ++
1
There has been some discussions recently about the infoframes sent by
drivers and if they were properly generated.
In parallel, there's been some interest in creating an infoframe-decode
tool similar to edid-decode.
Both would be much easier if we were to expose the infoframes programmed
in the h
Now that we have a plane create helper for kunit mocked drivers, let's
convert to it in vc4.
Reviewed-by: Maíra Canal
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/tests/vc4_mock_plane.c | 34 +++---
1 file changed, 8 insertions(+), 26 deletions(-)
diff --git a/d
On 3/20/24 02:05, Randy Dunlap wrote:
>
>
> On 3/19/24 22:42, Tomi Valkeinen wrote:
>> On 20/03/2024 00:51, Sean Anderson wrote:
>>> Fix a few errors in the kerneldoc. Mostly this addresses missing/renamed
>>> members.
>>>
>>> Signed-off-by: Sean Anderson
>>> ---
>>>
>>> Changes in v2:
>>> - New
On 3/20/24 01:57, Tomi Valkeinen wrote:
> On 20/03/2024 00:51, Sean Anderson wrote:
>> The feedback we get from the DPRX is per-lane. Make changes using this
>> information, instead of picking the maximum values from all lanes. This
>> results in more-consistent training on marginal links.
>>
>> Si
On Thu, 21 Mar 2024, Amogh Cheluvaraj wrote:
> Fix the duplicate C declaration warnings found on
> Documentation/gpu/drm-kms.rst that was found by
> compiling htmldocs
Please paste the warnings here.
BR,
Jani.
>
> Signed-off-by: Amogh Cheluvaraj
> ---
> Documentation/gpu/drm-kms.rst | 6
Fix the duplicate C declaration warnings found on
Documentation/gpu/drm-kms.rst that was found by
compiling htmldocs
Signed-off-by: Amogh Cheluvaraj
---
Documentation/gpu/drm-kms.rst | 6 --
1 file changed, 6 deletions(-)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-km
Hi, I want to confirm the status of this patch and whether need any
additional information.
On Fri, 23 Feb 2024 at 22:48, Abhinav Kumar wrote:
>
>
>
> On 2/22/2024 3:43 AM, Dmitry Baryshkov wrote:
> > The DPU driver provides support for 4:2:0 planar YCbCr plane formats.
> > Extend it to also support 4:2:2 and 4:4:4 plat formats.
> >
>
> I checked myself and also internally on this. On sm
On 3/20/24 02:14, Tomi Valkeinen wrote:
> On 20/03/2024 00:51, Sean Anderson wrote:
>> Sort the members of struct zynqmp_dp to reduce padding necessary for
>> alignment.
>>
>> Signed-off-by: Sean Anderson
>> ---
>>
>> Changes in v2:
>> - New
>>
>> drivers/gpu/drm/xlnx/zynqmp_dp.c | 28 ++
On 3/20/24 02:53, Tomi Valkeinen wrote:
> On 20/03/2024 00:51, Sean Anderson wrote:
>> Retraining the link can take a while, and might involve waiting for
>> DPCD reads/writes to complete. This is inappropriate for an IRQ handler.
>> Just schedule this work for later completion. This is racy, but w
On 3/20/24 03:49, Tomi Valkeinen wrote:
> On 20/03/2024 00:51, Sean Anderson wrote:
>
>> +/**
>> + * enum test_pattern - Test patterns for test testing
>
> "for test testing"? =)
>
>> @@ -1655,6 +2321,9 @@ static void zynqmp_dp_hpd_irq_work_func(struct
>> work_struct *work)
>> u8 status[D
On Tue, 05 Mar 2024 17:22:33 +0100, Thomas Zimmermann wrote:
> Backlight drivers implement struct backlight_ops.check_fb, which
> uses struct fb_info in its interface. Replace the callback with one
> that does not use fb_info.
>
> In DRM, we have several drivers that implement backlight support. B
On Thu, 21 Mar 2024, Lee Jones wrote:
> On Tue, 05 Mar 2024 17:22:33 +0100, Thomas Zimmermann wrote:
> > Backlight drivers implement struct backlight_ops.check_fb, which
> > uses struct fb_info in its interface. Replace the callback with one
> > that does not use fb_info.
> >
> > In DRM, we have
Hi Dave, Sima,
here's the drm-misc-next-fixes PR for this week.
Best regards
Thomas
drm-misc-next-fixes-2024-03-21:
Short summary of fixes pull:
core:
- fix rounding in drm_fixp2int_round()
bridge:
- fix documentation for DRM_BRIDGE_OP_EDID
nouveau:
- don't check devinit disable on GSP
sun4i
On Thu, Mar 14, 2024 at 06:20:58PM +0100, Jernej Škrabec wrote:
> Dne četrtek, 14. marec 2024 ob 15:42:24 CET je Maxime Ripard napisal(a):
> > On Sun, Mar 10, 2024 at 02:32:29PM +0100, Frank Oltmanns wrote:
> > > Allow the dclk to reset its rate when a rate change is initiated from an
> > > ancesto
On 21/03/2024 18:08, Sean Anderson wrote:
On 3/20/24 03:49, Tomi Valkeinen wrote:
On 20/03/2024 00:51, Sean Anderson wrote:
+/**
+ * enum test_pattern - Test patterns for test testing
"for test testing"? =)
@@ -1655,6 +2321,9 @@ static void zynqmp_dp_hpd_irq_work_func(struct
work_struct *
On 3/21/24 12:31, Tomi Valkeinen wrote:
> On 21/03/2024 18:08, Sean Anderson wrote:
>> On 3/20/24 03:49, Tomi Valkeinen wrote:
>>> On 20/03/2024 00:51, Sean Anderson wrote:
>>>
+/**
+ * enum test_pattern - Test patterns for test testing
>>>
>>> "for test testing"? =)
>>>
@@ -1655,6 +
On Mon, Mar 18, 2024 at 11:01:25AM -0700, Abhinav Kumar wrote:
> On 3/15/2024 8:57 AM, Johan Hovold wrote:
> > On Thu, Mar 14, 2024 at 09:30:57AM -0700, Abhinav Kumar wrote:
> >> The race condition is between the time we get disconnect event and set
> >> link_ready to false, a commit can come in.
On 3/18/24 06:28, Lucas De Marchi wrote:
On Sun, Mar 17, 2024 at 09:14:14AM -0700, Guenter Roeck wrote:
Hi,
On Thu, Jan 18, 2024 at 04:16:12PM -0800, Lucas De Marchi wrote:
Now that all the issues with 32bits are fixed, enable it again.
Reviewed-by: Matt Roper
Signed-off-by: Lucas De Marchi
On 21/03/2024 17:52, Sean Anderson wrote:
On 3/20/24 02:53, Tomi Valkeinen wrote:
On 20/03/2024 00:51, Sean Anderson wrote:
Retraining the link can take a while, and might involve waiting for
DPCD reads/writes to complete. This is inappropriate for an IRQ handler.
Just schedule this work for la
On 3/21/2024 8:43 AM, Dmitry Baryshkov wrote:
On Fri, 23 Feb 2024 at 22:48, Abhinav Kumar wrote:
On 2/22/2024 3:43 AM, Dmitry Baryshkov wrote:
The DPU driver provides support for 4:2:0 planar YCbCr plane formats.
Extend it to also support 4:2:2 and 4:4:4 plat formats.
I checked myself
On 3/21/24 13:25, Tomi Valkeinen wrote:
> On 21/03/2024 17:52, Sean Anderson wrote:
>> On 3/20/24 02:53, Tomi Valkeinen wrote:
>>> On 20/03/2024 00:51, Sean Anderson wrote:
Retraining the link can take a while, and might involve waiting for
DPCD reads/writes to complete. This is inappropr
On Thu, 21 Mar 2024 at 19:36, Abhinav Kumar wrote:
>
>
>
> On 3/21/2024 8:43 AM, Dmitry Baryshkov wrote:
> > On Fri, 23 Feb 2024 at 22:48, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 2/22/2024 3:43 AM, Dmitry Baryshkov wrote:
> >>> The DPU driver provides support for 4:2:0 planar YCbCr plane
On Sat, 16 Mar 2024 12:45:27 +0300, Dan Carpenter wrote:
> The "num_levels" variable is used to store error codes from
> device_property_count_u32() so it needs to be signed. This doesn't
> cause an issue at runtime because devm_kcalloc() won't allocate negative
> sizes. However, it's still worth
when CONFIG_DEV_COREDUMP is not defined in that case
when amdgpu_coredump() is called it does not find it's
definition and the build fails.
This happens as the header is defined without the
CONFIG_DEV_COREDUMP ifdef and due to which header isn't
enabled.
Pulling the header out of such ifdef so in
On Tue, 19 Mar 2024, Thomas Zimmermann wrote:
> The field fb_blank in struct backlight_properties has been marked for
> removal. Remove it in favor of the power and state fields.
>
> Patches 1 to 5 prepare several backlight drivers. They remove fb_blank
> or replace driver code with existing help
On 3/21/2024 11:09 AM, Dmitry Baryshkov wrote:
On Thu, 21 Mar 2024 at 19:36, Abhinav Kumar wrote:
On 3/21/2024 8:43 AM, Dmitry Baryshkov wrote:
On Fri, 23 Feb 2024 at 22:48, Abhinav Kumar wrote:
On 2/22/2024 3:43 AM, Dmitry Baryshkov wrote:
The DPU driver provides support for 4:2:0
Hi Linus,
please pull fixes and cleanups for the fbdev subsystem for kernel 6.9-rc1.
Beside the typical bunch of smaller fixes, the Linux console now allows fonts
up to a size of 64 x 128 pixels.
Thanks!
Helge
The following change
On 3/21/24 19:29, Helge Deller wrote:
Hi Linus,
please pull fixes and cleanups for the fbdev subsystem for kernel 6.9-rc1.
Linus, please wait
There is one new "unused variable warning" introduced with those patches.
I'll fix it up and send a new pull request tomorrow...
Helge
Beside
On Thu, 21 Mar 2024 at 20:28, Abhinav Kumar wrote:
>
>
>
> On 3/21/2024 11:09 AM, Dmitry Baryshkov wrote:
> > On Thu, 21 Mar 2024 at 19:36, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 3/21/2024 8:43 AM, Dmitry Baryshkov wrote:
> >>> On Fri, 23 Feb 2024 at 22:48, Abhinav Kumar
> >>> wrote:
On 21/03/2024 20:01, Sean Anderson wrote:
On 3/21/24 13:25, Tomi Valkeinen wrote:
On 21/03/2024 17:52, Sean Anderson wrote:
On 3/20/24 02:53, Tomi Valkeinen wrote:
On 20/03/2024 00:51, Sean Anderson wrote:
Retraining the link can take a while, and might involve waiting for
DPCD reads/writes t
On 3/21/24 15:08, Tomi Valkeinen wrote:
> On 21/03/2024 20:01, Sean Anderson wrote:
>> On 3/21/24 13:25, Tomi Valkeinen wrote:
>>> On 21/03/2024 17:52, Sean Anderson wrote:
On 3/20/24 02:53, Tomi Valkeinen wrote:
> On 20/03/2024 00:51, Sean Anderson wrote:
>> Retraining the link can ta
Acked-by: Alex Deucher
On Thu, Mar 21, 2024 at 2:14 PM Sunil Khatri wrote:
>
> when CONFIG_DEV_COREDUMP is not defined in that case
> when amdgpu_coredump() is called it does not find it's
> definition and the build fails.
>
> This happens as the header is defined without the
> CONFIG_DEV_COREDU
Implement live video input format setting for ZynqMP DPSUB.
ZynqMP DPSUB can operate in 2 modes: DMA-based and live.
In the live mode, DPSUB receives a live video signal from FPGA-based CRTC.
DPSUB acts as a DRM encoder bridge in such a scenario. To properly tune
into the incoming video signal, D
Set layer mode of operation (live or dma-based) during layer creation.
Each DPSUB layer mode of operation is defined by corresponding DT node port
connection, so it is possible to assign it during layer object creation.
Previously it was set in layer enable functions, although it is too late
as se
Update live format defines to match DPSUB AV_BUF_LIVE_VID_CONFIG register
layout.
Reviewed-by: Laurent Pinchart
Signed-off-by: Anatoliy Klymenko
---
drivers/gpu/drm/xlnx/zynqmp_disp_regs.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_di
DPSUB in bridge mode supports multiple input media bus formats.
Announce the list of supported input media bus formats via
drm_bridge.atomic_get_input_bus_fmts callback.
Introduce a set of live input formats, supported by DPSUB.
Rename zynqmp_disp_layer_drm_formats() to zynqmp_disp_layer_formats()
Avoid usage of global zynqmp_dpsub.dma_enabled flag in DPSUB layer
context. This flag signals whether the driver runs in DRM CRTC or DRM
bridge mode, assuming that all display layers share the same live or
non-live mode of operation. Using per-layer mode instead of global flag
will simplify future
Program live video input format according to selected media bus format.
In the bridge mode of operation, DPSUB is connected to FPGA CRTC which
almost certainly supports a single media bus format as its output. Expect
this to be delivered via the new bridge atomic state. Program DPSUB
registers acc
Add optional drm_crtc_helper_funcs.select_output_bus_format callback. This
callback allows to negotiate compatible media bus format on the link
between CRTC and connected DRM encoder or DRM bridge chain. A good usage
example is the CRTC implemented as FPGA soft IP. This kind of CRTC will
most certa
1 - 100 of 156 matches
Mail list logo
