On Thu, 23 Jan 2025, Stephen Rothwell wrote:
> Hi all,
>
> On Wed, 8 Jan 2025 12:16:50 +1100 Stephen Rothwell
> wrote:
>>
>> On Mon, 6 Jan 2025 13:03:48 +1100 Stephen Rothwell
>> wrote:
>> >
>> > Today's linux-next merge of the drm-intel tree got a conflict in:
>> >
>> > drivers/gpu/drm/i91
On Thu, 23 Jan 2025 08:33:01 +0100
Philipp Stanner wrote:
> On Wed, 2025-01-22 at 18:16 +0100, Boris Brezillon wrote:
> > On Wed, 22 Jan 2025 15:08:20 +0100
> > Philipp Stanner wrote:
> >
> > > int drm_sched_init(struct drm_gpu_scheduler *sched,
> > > - const struct drm_sched_backend_ops
On Thu, 2025-01-23 at 09:10 +0100, Philipp Stanner wrote:
> On Wed, 2025-01-22 at 19:07 -0300, Maíra Canal wrote:
> > Hi Philipp,
> >
> > On 22/01/25 11:08, Philipp Stanner wrote:
> > > drm_sched_init() has a great many parameters and upcoming new
> > > functionality for the scheduler might add ev
Thanks for this, Maíra.
Tested-by: Phil Elwell
On Thu, 23 Jan 2025 at 07:12, Iago Toral wrote:
>
> Looks good to me:
>
> Reviewed-by: Iago Toral Quiroga
>
> El mié, 22-01-2025 a las 22:24 -0300, Maíra Canal escribió:
> > In commit e4b5ccd392b9 ("drm/v3d: Ensure job pointer is set to NULL
> > a
On Thu, 23 Jan 2025, Dmitry Baryshkov wrote:
> On Fri, Jan 17, 2025 at 10:56:35AM +0200, Dmitry Baryshkov wrote:
>> Existing DPCD access functions return an error code or the number of
>> bytes being read / write in case of partial access. However a lot of
>> drivers either (incorrectly) ignore pa
On 23/01/2025 09:35, Philipp Stanner wrote:
On Thu, 2025-01-23 at 10:29 +0100, Danilo Krummrich wrote:
On Thu, Jan 23, 2025 at 08:33:01AM +0100, Philipp Stanner wrote:
On Wed, 2025-01-22 at 18:16 +0100, Boris Brezillon wrote:
On Wed, 22 Jan 2025 15:08:20 +0100
Philipp Stanner wrote:
int
On Thu, Jan 23, 2025 at 06:07:39PM +0800, Damon Ding wrote:
> Add two new functions: one to find &analogix_dp_device.plat_data via
> &drm_dp_aux, and the other to get &analogix_dp_device.aux. Both of them
> serve for the function of getting panel from DP AUX bus, which is why
> they are included in
Add support for the STA 116QHD024002, pleace the EDID here for
subsequent reference.
00 ff ff ff ff ff ff 00 4e 81 09 00 00 00 00 00
26 21 01 04 a5 1a 0e 78 02 1e b5 9a 5f 57 94 26
0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 8e 1c 56 a0 50 00 1e 30 28 20
55 00 00 90 10 00 00
On Thu, 23 Jan 2025 18:07:42 +0800, Damon Ding wrote:
> Compared with RK3288/RK3399, the HBR2 link rate support is the main
> improvement of RK3588 eDP TX controller, and there are also two
> independent eDP display interfaces on RK3588 Soc.
>
> The newly added 'apb' reset is to ensure the APB b
On Thu, Jan 23, 2025 at 06:07:40PM +0800, Damon Ding wrote:
> The main modification is moving the DP AUX initialization from function
> analogix_dp_bind() to analogix_dp_probe(). In order to get the EDID of
> eDP panel during probing, it is also needed to advance PM operaions to
> ensure that eDP c
On Thu, Jan 23, 2025 at 06:07:41PM +0800, Damon Ding wrote:
> Move drm_of_find_panel_or_bridge() a little later and combine it with
> component_add() into a new function rockchip_dp_link_panel(). The function
> will serve as done_probing() callback of devm_of_dp_aux_populate_bus(),
> aiding to supp
On Thu, Jan 23, 2025 at 06:07:45PM +0800, Damon Ding wrote:
> The raw edid for LP079QX1-SP0V panel model is:
>
> 00 ff ff ff ff ff ff 00 16 83 00 00 00 00 00 00
> 04 17 01 00 a5 10 0c 78 06 ef 05 a3 54 4c 99 26
> 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
> 01 01 01 01 01 01 ea 4e 00 4c 60 00
On Thu, Jan 23, 2025 at 06:07:47PM +0800, Damon Ding wrote:
> Add the necessary DT changes to enable eDP0 on RK3588S EVB1 board:
> - Set pinctrl of pwm12 for backlight
> - Enable edp0/hdptxphy0/vp2
> - Assign the parent of DCLK_VOP2_SRC to PLL_V0PLL
> - Add aux-bus/panel nodes
>
> For RK3588, the
On 13/01/2025 13:13, Dmitry Baryshkov wrote:
> On Mon, Jan 13, 2025 at 12:02:54PM +0100, Krzysztof Kozlowski wrote:
>> On 13/01/2025 09:29, Dmitry Baryshkov wrote:
>>> On Fri, Jan 10, 2025 at 01:43:28PM +0100, Krzysztof Kozlowski wrote:
On 10/01/2025 10:17, Dmitry Baryshkov wrote:
> On Fri
On Thu, Jan 23, 2025 at 08:33:01AM +0100, Philipp Stanner wrote:
> On Wed, 2025-01-22 at 18:16 +0100, Boris Brezillon wrote:
> > On Wed, 22 Jan 2025 15:08:20 +0100
> > Philipp Stanner wrote:
> >
> > > int drm_sched_init(struct drm_gpu_scheduler *sched,
> > > - const struct drm_sched_backend_o
On Thu, Jan 23, 2025 at 10:35:43AM +0100, Philipp Stanner wrote:
> On Thu, 2025-01-23 at 10:29 +0100, Danilo Krummrich wrote:
> > On Thu, Jan 23, 2025 at 08:33:01AM +0100, Philipp Stanner wrote:
> > > On Wed, 2025-01-22 at 18:16 +0100, Boris Brezillon wrote:
> > > > On Wed, 22 Jan 2025 15:08:20 +01
On Wed Jan 22, 2025 at 5:23 PM CET, Marijn Suijten wrote:
> Some SoCs such as SC7280 (used in the Fairphone 5) have only a single
> DSC "hard slice" encoder. The current hardcoded use of 2:2:1 topology
> (2 LM and 2 DSC for a single interface) make it impossible to use
> Display Stream Compression
On 2025/1/15 1:50, Jerome Brunet wrote:
[ EXTERNAL EMAIL ]
On Sun 12 Jan 2025 at 23:44, Martin Blumenstingl
wrote:
Hello,
On Fri, Jan 10, 2025 at 6:39 AM Ao Xu via B4 Relay
wrote:
This patch series adds DRM support for the Amlogic S4-series SoCs.
Compared to the Amlogic G12-series, the S4
Hello.
My sincerest apologies.
I used get_maintainer to populate the recipients for this patch series,
but I must have made an error somewhere.
John Edwards
On Wed, Jan 22, 2025 at 1:55 AM Thomas Zimmermann wrote:
>
> (cc'ing Hans)
>
> Hi Hans,
>
> I think this is for you.
>
> Best regards
>
Hello,
This patch seems to have been archived but I can't seem to find it in
the drm-misc git, is there anything else I should be doing to get this
patch approved and included?
Best regards,
Jesse
On Thu, Jan 23, 2025 at 12:26:25PM +0200, Jani Nikula wrote:
> On Fri, 17 Jan 2025, Dmitry Baryshkov wrote:
> > Existing DPCD access functions return an error code or the number of
> > bytes being read / write in case of partial access. However a lot of
> > drivers either (incorrectly) ignore part
On Thu, Jan 23, 2025 at 12:05:29PM +0200, Jani Nikula wrote:
> On Fri, 17 Jan 2025, Dmitry Baryshkov wrote:
> > Switch drm_dp_aux_dev.c to use new set of DPCD read / write helpers.
>
> This might be one of the few places where the old functions and the old
> return value was used in a sensible ma
Hi Philipp,
On 23/01/25 05:10, Philipp Stanner wrote:
On Wed, 2025-01-22 at 19:07 -0300, Maíra Canal wrote:
Hi Philipp,
On 22/01/25 11:08, Philipp Stanner wrote:
drm_sched_init() has a great many parameters and upcoming new
functionality for the scheduler might add even more. Generally, the
g
Reviewed-by: Jose Maria Casanova Crespo
El 23/1/25 a las 2:24, Maíra Canal escribió:
In commit e4b5ccd392b9 ("drm/v3d: Ensure job pointer is set to NULL
after job completion"), we introduced a change to assign the job pointer
to NULL after completing a job, indicating job completion.
However,
On Thu, Jan 23, 2025 at 03:19:21PM +0530, Ekansh Gupta wrote:
>
>
>
> On 1/23/2025 1:18 PM, Dmitry Baryshkov wrote:
> > On Thu, Jan 23, 2025 at 11:16:41AM +0530, Ekansh Gupta wrote:
> >>
> >>
> >> On 10/7/2024 7:27 PM, Dmitry Baryshkov wrote:
> >>> On Mon, Oct 07, 2024 at 02:15:15PM GMT, Ekansh
On 23/01/2025 12:42, Dmitry Baryshkov wrote:
> On Thu, Jan 23, 2025 at 12:34:28PM +0100, Krzysztof Kozlowski wrote:
>> On 13/01/2025 13:13, Dmitry Baryshkov wrote:
>>> On Mon, Jan 13, 2025 at 12:02:54PM +0100, Krzysztof Kozlowski wrote:
On 13/01/2025 09:29, Dmitry Baryshkov wrote:
> On Fri
On 1/23/2025 4:43 PM, Dmitry Baryshkov wrote:
> On Thu, Jan 23, 2025 at 03:19:21PM +0530, Ekansh Gupta wrote:
>>
>>
>> On 1/23/2025 1:18 PM, Dmitry Baryshkov wrote:
>>> On Thu, Jan 23, 2025 at 11:16:41AM +0530, Ekansh Gupta wrote:
On 10/7/2024 7:27 PM, Dmitry Baryshkov wrote:
> On
On Thu, Jan 09, 2025 at 02:53:16PM +0100, Thomas Zimmermann wrote:
> Hi
>
>
> Am 22.12.24 um 06:00 schrieb Dmitry Baryshkov:
> > As pointed out by Simona, the drm_atomic_helper_check_modeset() and
> > drm_atomic_helper_check() require the former function is rerun if the
> > driver's callbacks mod
On Thu, 2025-01-23 at 08:10 -0300, Maíra Canal wrote:
> Hi Philipp,
>
> On 23/01/25 05:10, Philipp Stanner wrote:
> > On Wed, 2025-01-22 at 19:07 -0300, Maíra Canal wrote:
> > > Hi Philipp,
> > >
> > > On 22/01/25 11:08, Philipp Stanner wrote:
> > > > drm_sched_init() has a great many parameters
On Thu, 2025-01-23 at 10:29 +0100, Danilo Krummrich wrote:
> On Thu, Jan 23, 2025 at 08:33:01AM +0100, Philipp Stanner wrote:
> > On Wed, 2025-01-22 at 18:16 +0100, Boris Brezillon wrote:
> > > On Wed, 22 Jan 2025 15:08:20 +0100
> > > Philipp Stanner wrote:
> > >
> > > > int drm_sched_init(struc
On 1/23/2025 1:18 PM, Dmitry Baryshkov wrote:
> On Thu, Jan 23, 2025 at 11:16:41AM +0530, Ekansh Gupta wrote:
>>
>>
>> On 10/7/2024 7:27 PM, Dmitry Baryshkov wrote:
>>> On Mon, Oct 07, 2024 at 02:15:15PM GMT, Ekansh Gupta wrote:
InvokeV2 request is intended to support multiple enhanced inv
On Wed, 22 Jan 2025, Suraj Kandpal wrote:
> Usually retimers take around 30 to 40ms to exit all devices from
> sleep state. Extended wake timeout mechanism helps to give
> that additional time.
>
> --v2
> -Grant the requested time only if greater than 1ms [Arun/Jani]
> -Reframe commit message [Aru
On Fri, 17 Jan 2025, Dmitry Baryshkov wrote:
> Switch drm_dp_aux_dev.c to use new set of DPCD read / write helpers.
This might be one of the few places where the old functions and the old
return value was used in a sensible manner.
BR,
Jani.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers
According to the comments in include/drm/drm_print.h, the DRM_...()
functions are deprecated in favor of drm_...() or dev_...() functions.
Use drm_err()/drm_dbg_core()/drm_dbg_kms() instead of
DRM_DEV_ERROR()/DRM_ERROR()/DRM_DEV_DEBUG()/DRM_DEBUG_KMS().
Signed-off-by: Damon Ding
---
Changes in
There are two main modifications: one is expanding struct
rockchip_dp_chip_data to an array, and the other is adding
&rockchip_dp_chip_data.reg to separate different edp devices.
Signed-off-by: Damon Ding
---
Changes in v6:
- Add the description of &rockchip_dp_chip_data.reg
- Use drm_...() uni
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 Ding
Reviewed-by: Dmitry Baryshkov
---
Changes in v2:
- remove ne
The main modification is moving the DP AUX initialization from function
analogix_dp_bind() to analogix_dp_probe(). In order to get the EDID of
eDP panel during probing, it is also needed to advance PM operaions to
ensure that eDP controller and phy are prepared for AUX transmission.
In addtion, ad
According to Documentation/devicetree/bindings/display/dp-aux-bus.yaml,
it is a good way to get panel through the DP AUX bus.
Acked-by: Krzysztof Kozlowski
Signed-off-by: Damon Ding
---
Changes in v4:
- Move the dt-bindings commit before related driver commits
Changes in v5:
- Remove the unex
RK3588 integrates the Analogix eDP 1.3 TX controller IP and the HDMI/eDP
TX Combo PHY based on a Samsung IP block. There are also two independent
eDP display interface with different address on RK3588 Soc.
The patch currently adds only the basic support, specifically RGB output
up to 4K@60Hz, with
Add the necessary DT changes to enable eDP0 on RK3588S EVB1 board:
- Set pinctrl of pwm12 for backlight
- Enable edp0/hdptxphy0/vp2
- Assign the parent of DCLK_VOP2_SRC to PLL_V0PLL
- Add aux-bus/panel nodes
For RK3588, the PLL_V0PLL is specifically designed for the VOP2. This
means the clock rate
Expand enum analogix_dp_devtype with RK3588_EDP, and add max_link_rate
and max_lane_count configs for it.
Signed-off-by: Damon Ding
Reviewed-by: Dmitry Baryshkov
---
Changes in v5:
- Add the RK3588_EDP related modification in analogix_dp.h
- Move this commit above related commit on the Rockchi
Picked from:
https://patchwork.kernel.org/project/linux-rockchip/list/?series=923593
These patchs have been tested with a 1536x2048p60 eDP panel on
RK3588S EVB1 board, and HDMI 1080P/4K display also has been verified
on RK3588 EVB1 board. Furthermore, the eDP display has been rechecked
on RK3399 s
Move drm_of_find_panel_or_bridge() a little later and combine it with
component_add() into a new function rockchip_dp_link_panel(). The function
will serve as done_probing() callback of devm_of_dp_aux_populate_bus(),
aiding to support for obtaining the eDP panel via the DP AUX bus.
If failed to ge
The raw edid for LP079QX1-SP0V panel model is:
00 ff ff ff ff ff ff 00 16 83 00 00 00 00 00 00
04 17 01 00 a5 10 0c 78 06 ef 05 a3 54 4c 99 26
0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 ea 4e 00 4c 60 00 14 80 0c 10
84 00 78 a0 00 00 00 18 00 00 00 10 00 00 00 00
00 00 00 00
Add support for the eDP0 output on RK3588 SoC.
Signed-off-by: Damon Ding
---
Changes in v3:
- Remove currently unsupported property '#sound-dai-cells'
Changes in v4:
- Remove currently unsupported clock 'spdif'
---
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 28 +++
1 file
Compared with RK3288/RK3399, the HBR2 link rate support is the main
improvement of RK3588 eDP TX controller, and there are also two
independent eDP display interfaces on RK3588 Soc.
The newly added 'apb' reset is to ensure the APB bus of eDP controller
works well on the RK3588 SoC.
Signed-off-by:
The formalized struct definition will makes grf field operations more
concise and easier to extend.
Signed-off-by: Damon Ding
---
Changes in v2:
- Initialize struct rockchip_dp_chip_data rk3399_edp/rk3288_dp in order
of its members
Changes in v6:
- Pass 'dp' in drm_...() rather than 'dp->drm
Add two new functions: one to find &analogix_dp_device.plat_data via
&drm_dp_aux, and the other to get &analogix_dp_device.aux. Both of them
serve for the function of getting panel from DP AUX bus, which is why
they are included in a single commit.
Signed-off-by: Damon Ding
Reviewed-by: Dmitry Ba
Hi,
I keep finding issues in our implementation of "device exclusive
non-swap entries", and the way it messes with mapcounts is disgusting.
As a reminder, what we do here is to replace a PTE pointing to an
anonymous page by a "device exclusive non-swap entry".
As long as the original PTE is
On Fri, 17 Jan 2025, Dmitry Baryshkov wrote:
> Existing DPCD access functions return an error code or the number of
> bytes being read / write in case of partial access. However a lot of
> drivers either (incorrectly) ignore partial access or mishandle error
> codes. In other cases this results in
On Thu, Jan 23, 2025 at 12:34:28PM +0100, Krzysztof Kozlowski wrote:
> On 13/01/2025 13:13, Dmitry Baryshkov wrote:
> > On Mon, Jan 13, 2025 at 12:02:54PM +0100, Krzysztof Kozlowski wrote:
> >> On 13/01/2025 09:29, Dmitry Baryshkov wrote:
> >>> On Fri, Jan 10, 2025 at 01:43:28PM +0100, Krzysztof Ko
On Thu, Jan 23, 2025 at 06:07:44PM +0800, Damon Ding wrote:
> RK3588 integrates the Analogix eDP 1.3 TX controller IP and the HDMI/eDP
> TX Combo PHY based on a Samsung IP block. There are also two independent
> eDP display interface with different address on RK3588 Soc.
>
> The patch currently ad
On Mon, 06 Jan 2025 13:10:54 +0100, Jesse Van Gavere wrote:
> Use the atomic version of enable/disable.
>
> To support bridges where bus format negotiation is needed such as TIDSS we
> need to implement atomic_get_input_bus_fmts, prepare the driver for this by
> switching the existing operations t
On Thu, 23 Jan 2025, Damon Ding wrote:
> According to the comments in include/drm/drm_print.h, the DRM_...()
> functions are deprecated in favor of drm_...() or dev_...() functions.
>
> Use drm_err()/drm_dbg_core()/drm_dbg_kms() instead of
> DRM_DEV_ERROR()/DRM_ERROR()/DRM_DEV_DEBUG()/DRM_DEBUG_KM
On Thu, Jan 23, 2025 at 05:34:00PM +0530, Ekansh Gupta wrote:
>
>
>
> On 1/23/2025 4:43 PM, Dmitry Baryshkov wrote:
> > On Thu, Jan 23, 2025 at 03:19:21PM +0530, Ekansh Gupta wrote:
> >>
> >>
> >> On 1/23/2025 1:18 PM, Dmitry Baryshkov wrote:
> >>> On Thu, Jan 23, 2025 at 11:16:41AM +0530, Ekans
On Sun, 22 Dec 2024 07:00:40 +0200, Dmitry Baryshkov wrote:
> As pointed out by Simona, the drm_atomic_helper_check_modeset() and
> drm_atomic_helper_check() require the former function is rerun if the
> driver's callbacks modify crtc_state->mode_changed. MSM is one of the
> drivers which failed to
On Wed, 22 Jan 2025, Damon Ding wrote:
> Hi Andy,
>
> On 2025/1/9 14:28, Andy Yan wrote:
>>
>> Hi Damon,
>>
>> At 2025-01-09 11:27:10, "Damon Ding" wrote:
>>> According to the comments in include/drm/drm_print.h, the DRM_...()
>>> functions are deprecated in favor of drm_...() or dev_...() func
On Wed, Jan 22, 2025 at 04:49:21PM +0200, Jani Nikula wrote:
> On Wed, 22 Jan 2025, Gustavo Sousa wrote:
> > Quoting Jani Nikula (2025-01-22 11:02:31-03:00)
> >>On Wed, 22 Jan 2025, Gustavo Sousa wrote:
> >>> Quoting Simona Vetter (2025-01-22 08:11:53-03:00)
> On Tue, Jan 21, 2025 at 06:09:25
Hi Philipp,
On 23/01/25 09:13, Philipp Stanner wrote:
On Thu, 2025-01-23 at 08:10 -0300, Maíra Canal wrote:
Hi Philipp,
On 23/01/25 05:10, Philipp Stanner wrote:
On Wed, 2025-01-22 at 19:07 -0300, Maíra Canal wrote:
Hi Philipp,
On 22/01/25 11:08, Philipp Stanner wrote:
drm_sched_init() has
The MSM driver uses drm_atomic_helper_check() which mandates that none
of the atomic_check() callbacks toggles crtc_state->mode_changed.
Perform corresponding check before calling the drm_atomic_helper_check()
function.
Fixes: 8b45a26f2ba9 ("drm/msm/dpu: reserve cdm blocks for writeback in case of
As a preparation for calling dpu_encoder_get_topology() from different
places, move the code setting topology->needs_cdm to that function
(instead of patching topology separately).
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 41 ++
As a preparation for calling dpu_encoder_get_topology() from different
code paths, simplify its calling interface, obtaining some data pointers
internally instead passing them via arguments.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder
As pointed out by Simona, the drm_atomic_helper_check_modeset() and
drm_atomic_helper_check() require the former function is rerun if the
driver's callbacks modify crtc_state->mode_changed. MSM is one of the
drivers which failed to follow this requirement.
Rework the MSM / DPU driver to follow the
On Thu, Jan 23, 2025 at 03:41:58PM +0800, Xu Yilun wrote:
> I don't have a complete idea yet. But the goal is not to make any
> existing driver seamlessly work with secure device. It is to provide a
> generic way for bind/attestation/accept, and may save driver's effort
> if they don't care about
On Wed, 2025-01-22 at 19:07 -0300, Maíra Canal wrote:
> Hi Philipp,
>
> On 22/01/25 11:08, Philipp Stanner wrote:
> > drm_sched_init() has a great many parameters and upcoming new
> > functionality for the scheduler might add even more. Generally, the
> > great number of parameters reduces readabi
Hi Krzysztof,
At 2025-01-22 17:55:34, "Krzysztof Kozlowski" wrote:
>On 22/01/2025 10:46, Andy Yan wrote:
- The VOP interrupt is shared by several interrupt sources, such as
- frame start (VSYNC), line flag and other status interrupts.
+ For VOP version under rk3576,
On Thu, 23 Jan 2025, Jani Nikula wrote:
> From: Gustavo Sousa
>
> The header drm_print.h uses members of struct drm_device pointers, as
> such, it should include drm_device.h to let the compiler know the full
> type definition.
>
> Without such include, users of drm_print.h that don't explicitly
Quoting Jani Nikula (2025-01-23 12:14:31-03:00)
>On Thu, 23 Jan 2025, Jani Nikula wrote:
>> From: Gustavo Sousa
>>
>> The header drm_print.h uses members of struct drm_device pointers, as
>> such, it should include drm_device.h to let the compiler know the full
>> type definition.
>>
>> Without s
The expectation is that the struct drm_device based logging helpers get
passed an actual struct drm_device pointer rather than some random
struct pointer where you can dereference the ->dev member.
Add a static inline helper to convert struct drm_device to struct
device, with the main benefit bein
The expectation is that the struct drm_device based logging helpers get
passed an actual struct drm_device pointer rather than some random
struct pointer where you can dereference the ->dev member.
Convert drm_err(hdmi, ...) to dev_err(hdmi->dev, ...). This matches
current usage, but drops "[drm]
The expectation is that the struct drm_device based logging helpers get
passed an actual struct drm_device pointer rather than some random
struct pointer where you can dereference the ->dev member.
Convert drm_err(sched, ...) to dev_err(sched->dev, ...) and
similar. This matches current usage, as
From: Gustavo Sousa
The header drm_print.h uses members of struct drm_device pointers, as
such, it should include drm_device.h to let the compiler know the full
type definition.
Without such include, users of drm_print.h that don't explicitly need
drm_device.h would bump into build errors and be
Fix all cases that pass something other than struct drm_device to the
drm_device based logging helpers, and add strict type checking.
Gustavo Sousa (1):
drm/print: Include drm_device.h
Jani Nikula (4):
drm/mipi-dsi: stop passing non struct drm_device to drm_err() and
friends
drm/rockchi
The expectation is that the struct drm_device based logging helpers get
passed an actual struct drm_device pointer rather than some random
struct pointer where you can dereference the ->dev member.
Convert drm_err(host, ...) to dev_err(host->dev, ...). This matches
current usage, as struct drm_dev
On Thu, Jan 23, 2025 at 11:20:37AM +0100, David Hildenbrand wrote:
> Hi,
>
> I keep finding issues in our implementation of "device exclusive non-swap
> entries", and the way it messes with mapcounts is disgusting.
>
> As a reminder, what we do here is to replace a PTE pointing to an anonymous
>
On 22/01/25 22:24, Maíra Canal wrote:
In commit e4b5ccd392b9 ("drm/v3d: Ensure job pointer is set to NULL
after job completion"), we introduced a change to assign the job pointer
to NULL after completing a job, indicating job completion.
However, this approach created a race condition between th
On Thu, Jan 23, 2025 at 03:35:21PM +0100, Christian König wrote:
> Sending it as text mail once more.
>
> Am 23.01.25 um 15:32 schrieb Christian König:
> > Am 23.01.25 um 14:59 schrieb Jason Gunthorpe:
> > > On Wed, Jan 22, 2025 at 03:59:11PM +0100, Christian König wrote:
> > > > > > For example w
On Thu, 23 Jan 2025, Jani Nikula wrote:
> On Thu, 23 Jan 2025, Damon Ding wrote:
>> According to the comments in include/drm/drm_print.h, the DRM_...()
>> functions are deprecated in favor of drm_...() or dev_...() functions.
>>
>> Use drm_err()/drm_dbg_core()/drm_dbg_kms() instead of
>> DRM_DEV_
On Wed, Jan 22, 2025 at 04:41:32PM +0200, Jani Nikula wrote:
> Add CONFIG_DRM_HEADER_TEST to ensure drm headers are self-contained and
> pass kernel-doc. And for starters, fix one header that this catches.
>
> Jani Nikula (2):
> drm/client: include types.h to make drm_client_event.h self-contain
On Thu, Jan 23, 2025 at 07:23:33PM +0530, Vignesh Raman wrote:
> Add a drm scenario that includes a job to run IGT tests for vkms.
> It also includes helper scripts to build deqp-runner and IGT,
> which are based on the mesa-ci project.
>
> The xfails are added from drm-ci (drivers/gpu/drm/ci/xfai
On 2025-01-15 03:00, Simon Ser wrote:
> Is this 125 magic number something we can expect other hardware to
> implement as well?
>
It's based on MS's CCCS interpretation of 80 nits as 1.0f [1]. Based on
this definition one needs to use 125.0f to represent 10,000 nits,
the maximum value PQ can r
On 2025-01-17 04:04, Pekka Paalanen wrote:
> On Thu, 19 Dec 2024 21:33:35 -0700
> Alex Hung wrote:
>
>> From: Harry Wentland
>>
>> The PQ function defines a mapping of code values to nits (cd/m^2).
>> The max code value maps to 10,000 nits.
>>
>> Windows DWM's canonical composition color spac
On 2025-01-17 04:06, Pekka Paalanen wrote:
> On Thu, 16 Jan 2025 10:56:22 +0200
> Pekka Paalanen wrote:
>
>> On Thu, 19 Dec 2024 21:33:37 -0700
>> Alex Hung wrote:
>>
>>> From: Harry Wentland
>>>
>>> The BT.709 and BT.2020 OETFs are the same, the only difference
>>> being that the BT.2020 va
Sending it as text mail once more.
Am 23.01.25 um 15:32 schrieb Christian König:
Am 23.01.25 um 14:59 schrieb Jason Gunthorpe:
On Wed, Jan 22, 2025 at 03:59:11PM +0100, Christian König wrote:
For example we have cases with multiple devices are in the same IOMMU domain
and re-using their DMA ad
On 10.01.2025 16:46, Krzysztof Karas wrote:
GuC code uses in_atomic() function to determine if the current
context is atomic. As noted by the function's description it
should not be used in driver code, as it is not guaranteed to
determine atomicity correctly in every instance. This is also
poin
Am 23.01.25 um 14:59 schrieb Jason Gunthorpe:
On Wed, Jan 22, 2025 at 03:59:11PM +0100, Christian König wrote:
For example we have cases with multiple devices are in the same IOMMU domain
and re-using their DMA address mappings.
IMHO this is just another flavour of "private" address flow betwee
On Thu, 23 Jan 2025 at 05:56, Vignesh Raman wrote:
>
> Documentation/ci/gitlab-ci/images/drm-vkms.png | Bin 0 -> 73810 bytes
> .../ci/gitlab-ci/images/job-matrix.png | Bin 0 -> 2 bytes
> .../ci/gitlab-ci/images/new-project-runner.png | Bin 0 -> 607737 bytes
> .../ci/gitlab-ci/image
Am 23.01.25 um 16:02 schrieb Jason Gunthorpe:
On Thu, Jan 23, 2025 at 03:35:21PM +0100, Christian König wrote:
Sending it as text mail once more.
Am 23.01.25 um 15:32 schrieb Christian König:
Am 23.01.25 um 14:59 schrieb Jason Gunthorpe:
On Wed, Jan 22, 2025 at 03:59:11PM +0100, Christian Kön
On Thu, Jan 23, 2025 at 05:09:10PM +0200, Jani Nikula wrote:
> The expectation is that the struct drm_device based logging helpers get
> passed an actual struct drm_device pointer rather than some random
> struct pointer where you can dereference the ->dev member.
>
> Convert drm_err(sched, ...) t
Hi,
On Thu, Jan 23, 2025 at 3:21 AM Langyan Ye
wrote:
>
> Add support for the STA 116QHD024002, pleace the EDID here for
> subsequent reference.
>
> 00 ff ff ff ff ff ff 00 4e 81 09 00 00 00 00 00
> 26 21 01 04 a5 1a 0e 78 02 1e b5 9a 5f 57 94 26
> 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
Hi,
On 16/01/2025 13:16, Jayesh Choudhary wrote:
For the cases we have DRM_BRIDGE_ATTACH_NO_CONNECTOR flag set,
Any idea if any other platform than K3 is using this driver? tidss
supports DRM_BRIDGE_ATTACH_NO_CONNECTOR, so if K3 is the only user, we
could drop the legacy !DRM_BRIDGE_ATTACH_N
On Fri, Jan 24, 2025 at 12:14 AM Paul-pl Chen (陳柏霖)
wrote:
>
> On Thu, 2025-01-23 at 08:21 +0100, Krzysztof Kozlowski wrote:
> >
> > External email : Please do not click links or open attachments until
> > you have verified the sender or the content.
> >
> >
> > On 23/01/2025 07:11, Paul-pl Chen (
The purpose of synchronize_irq is to wait for any pending IRQ handlers for the
interrupt to complete, if synchronize_irq called before interrupt disabled, an
tiny timing window created, where no more pending IRQ, but interrupt not
disabled yet. Meanwhile, if the interrupt event happened in this tim
Hi,
On Wed, Jan 22, 2025 at 10:48 PM Langyan Ye
wrote:
>
> KINGDISPLAY KD110N11-51IE and STARRY 2082109QFH040022-50E are
> 10.95-inch WUXGA TFT LCD panels, which fits in nicely with the
> existing panel-boe-tv101wum-nl6 driver. Hence, we add a new
> compatible with panel specific config.
FWIW, t
Hi,
On Wed, Jan 22, 2025 at 10:48 PM Langyan Ye
wrote:
>
> The kingdisplay-kd110n11-51ie is a 10.95" TFT panel.
> which fits in nicely with the existing panel-boe-tv101wum-nl6 driver.
> From the datasheet, MIPI needs to keep the LP11 state before the
> lcm_reset pin is pulled high, so increase lp
Le jeudi 23 janvier 2025 à 07:46 -0800, Linus Torvalds a écrit :
> On Thu, 23 Jan 2025 at 05:56, Vignesh Raman
> wrote:
> >
> > Documentation/ci/gitlab-ci/images/drm-vkms.png | Bin 0 -> 73810 bytes
> > .../ci/gitlab-ci/images/job-matrix.png | Bin 0 -> 2 bytes
> > .../ci/gitlab-ci/
On Tue, 2025-01-21 at 18:15 -0500, Vivi, Rodrigo wrote:
> On Tue, Jan 21, 2025 at 11:09:34AM -0800, Alan Previn wrote:
>
>
> A 'series' of 1 patch is not a series. Cover letter is not needed.
>
> However, this patch is the size of a series and it should be
> split. I'm really surprised that some
From: Noralf Trønnes
Remove myself as maintainer for gud, mi0283qt, panel-mipi-dbi and repaper.
My fatigue illness has finally closed the door on doing development of
even moderate complexity so it's sad to let this go.
Signed-off-by: Noralf Trønnes
---
MAINTAINERS | 12
1 file ch
Hi Linus,
please pull three fixes and 9 cleanup patches for fbdev for this merge window.
This series prevents a possible crash and one memory leak in omapfb
and fixes possible misbehaviour in vga16fb.
Thanks,
Helge
The following c
1 - 100 of 163 matches
Mail list logo
