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 invoke
> >> requests like CRC check, performance coun
> > On Wed, Jan 08, 2025 at 11:09:00AM +0530, Arun R Murthy wrote:
> > > Expose drm plane function to create formats/modifiers blob. This
> > > function can be used to expose list of supported formats/modifiers
> > > for sync/async flips.
> > >
> > > Signed-off-by: Arun R Murthy
> > > ---
> > > d
On Wed, Jan 22, 2025 at 08:55:12AM -0400, Jason Gunthorpe wrote:
> On Wed, Jan 22, 2025 at 12:32:56PM +0800, Xu Yilun wrote:
> > On Tue, Jan 21, 2025 at 01:43:03PM -0400, Jason Gunthorpe wrote:
> > > On Tue, Jun 25, 2024 at 05:12:10AM +0800, Xu Yilun wrote:
> > >
> > > > When VFIO works as a TEE u
On Wed, 2025-01-22 at 20:37 -0800, Matthew Brost wrote:
> On Wed, Jan 22, 2025 at 06:04:58PM +0100, Boris Brezillon wrote:
> > On Wed, 22 Jan 2025 16:14:59 +
> > Tvrtko Ursulin wrote:
> >
> > > On 22/01/2025 15:51, Boris Brezillon wrote:
> > > > On Wed, 22 Jan 2025 15:08:20 +0100
> > > > Phil
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 *ops,
> > - struct workqueue_struct *submit_wq,
> > - u32 num_rqs, u
On 23/01/2025 07:11, Paul-pl Chen (陳柏霖) wrote:
>
> Hi Krzysztof
>
> I hope this email finds you well. I have a couple of questions
> regarding the EXDMA commit patch and decoupling:
>
> 1. Would removing the example from the EXDMA commit patch be sufficient
> to achieve decoupling for EXDMA YAM
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
> after job completion"), we introduced a change to assign the job
> pointer
> to NULL after completing a job, indic
The starry-2082109qfh040022-50e 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 lp11_before_reset flag.
Signed-off-by: Langyan Ye
Reviewed-by: N
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 lp11_before_reset flag.
Signed-off-by: Langyan Ye
Reviewed-by: Nei
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.
Signed-off-by: Langyan Ye
---
.../devicetree/bindings/display/panel/boe,
Provides a single binding patch with correct alphabetical order for
both panels, and adjusts alphabetical order for compatible properties.
Changes in v4:
- PATCH 1/3: Single bindings patch for both panels with proper alphabetical
order
- PATCH 2/3: Adjust the alphabetical order of the compatible
On Thu, Jan 23, 2025 at 2:11 PM Paul-pl Chen (陳柏霖)
wrote:
>
> On Sat, 2025-01-18 at 10:22 +0100, Krzysztof Kozlowski wrote:
> >
> > External email : Please do not click links or open attachments until
> > you have verified the sender or the content.
> >
> >
> > On 14/01/2025 06:49, Paul-pl Chen (陳
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 invoke
>> requests like CRC check, performance counter enablement and polling
>> mode for RPC invocations. CRC check is gettin
On Wed, Jan 22, 2025 at 06:04:58PM +0100, Boris Brezillon wrote:
> On Wed, 22 Jan 2025 16:14:59 +
> Tvrtko Ursulin wrote:
>
> > On 22/01/2025 15:51, Boris Brezillon wrote:
> > > On Wed, 22 Jan 2025 15:08:20 +0100
> > > Philipp Stanner wrote:
> > >
> > >> --- a/drivers/gpu/drm/panthor/pant
Hello Brian, Many thanks for the fix. I am adding my tested-by.
Tested-by: Vidya Srinivas
> -Original Message-
> From: Brian Geffon
> Sent: 16 January 2025 21:24
> To: intel-...@lists.freedesktop.org
> Cc: Wilson, Chris P ; Saarinen, Jani
> ; Mistat, Tomasz ;
> Srinivas, Vidya ; ville.s
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 the DRM
scheduler workqueue and the IRQ ex
On 12/13/2024 2:14 PM, Dmitry Baryshkov wrote:
Continue migration to the MDSS-revision based checks and replace
DPU_DATA_HCTL_EN feature bit with the core_major_ver >= 5 check.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 3 +--
drivers/gpu/drm/msm/
On 12/13/2024 2:14 PM, Dmitry Baryshkov wrote:
Continue migration to the MDSS-revision based checks and replace
DPU_CTL_VM_CFG feature bit with the core_major_ver >= 7 check.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h | 8 ++--
drivers
On 12/13/2024 2:14 PM, Dmitry Baryshkov wrote:
Continue migration to the MDSS-revision based checks and replace
DPU_CTL_DSPP_SUB_BLOCK_FLUSH feature bit with the core_major_ver >= 7
check.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 3 +--
drivers/
On 12/13/2024 2:14 PM, Dmitry Baryshkov wrote:
Continue migration to the MDSS-revision based checks and replace
DPU_CTL_FETCH_ACTIVE feature bit with the core_major_ver >= 7 check.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 3 +--
drivers/gpu/drm/
On 1/22/2025 1:53 AM, Dmitry Baryshkov wrote:
On Tue, Jan 21, 2025 at 04:58:03PM -0800, Abhinav Kumar wrote:
On 12/13/2024 2:14 PM, Dmitry Baryshkov wrote:
Continue migration to the MDSS-revision based checks and replace
DPU_CTL_ACTIVE_CFG feature bit with the core_major_ver >= 5 check.
S
Hi,
On Wed, Jan 22, 2025 at 1:30 AM Langyan Ye
wrote:
>
> Hi Doug,
> Can you spare some time to help review it? Thanks a lot.
Sure. Let me see if I can figure out what's here:
v1:
- both panel patches got reviewed-by from Neil (nice!)
- wasn't well threaded
- After v4 was already out there, Dmi
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/i915/display/intel_display_driver.c
> >
> > between commit:
>
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 partial access or mishandle error
> codes. In other c
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 readability and has already caused
one missnaming in:
commit 6f1cacf4eba7 ("
On 2025-01-15 02:56, Simon Ser wrote:
> Is this "ignore" something we could do at the core DRM level, instead
> of doing it in all drivers? e.g. by silently ignoring user-space requests
> to set the property?
>
I think it'd be better to reject setting the property. The problem
is that a client
Hi,
On Wed, Jan 22, 2025 at 12:23 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
On Wednesday, January 22nd, 2025 at 20:48, Harry Wentland
wrote:
> On 2025-01-13 13:23, Simon Ser wrote:
>
> > > v4:
> > > - Don't block setting of COLOR_RANGE and COLOR_ENCODING
> > > when client cap is set
> >
> > Can you remind me why these should not be blocked?
>
> I initially blocked se
On 2025-01-13 13:23, Simon Ser wrote:
>> v4:
>> - Don't block setting of COLOR_RANGE and COLOR_ENCODING
>>when client cap is set
>
> Can you remind me why these should not be blocked?
>
I initially blocked setting these when the client cap was set
but that caused some IGT tests to blow u
On Wed, Jan 22, 2025 at 08:37:51AM +0100, Thomas Zimmermann wrote:
> another friendly ping for a review of this patch
>
>
> Am 03.01.25 um 10:55 schrieb Thomas Zimmermann:
> > Removing the bochs PCI device should mark the DRM device as unplugged
> > without removing it. Hence clear the respective
On Wed, Jan 22, 2025 at 05:37:53PM +0800, Damon Ding wrote:
> Hi Dmitry,
>
> On 2025/1/22 16:17, Damon Ding wrote:
> > Hi Dmitry,
> >
> > On 2025/1/9 20:48, Dmitry Baryshkov wrote:
> > > On Thu, Jan 09, 2025 at 11:27:17AM +0800, Damon Ding wrote:
> > > > Move drm_of_find_panel_or_bridge() a littl
On Wed, Jan 22, 2025 at 11:03:57AM +0530, Suraj Kandpal wrote:
> Extended wake timeout request helps to give additional
> time by reading the DPCD register through which sink requests the
> minimal amount of time required to wake the sink up.
> Source device shall keep retying the AUX tansaction t
On Wed, Jan 22, 2025 at 05:23:44PM +0100, 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 Compr
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 *ops,
> -struct workqueue_struct *submit_wq,
> -u32 num_rqs, u32 credit_limit, unsigned int hang_l
On 2025-01-21 16:58:24, Luca Weiss wrote:
> Hi Marijn,
>
> On Tue Jan 21, 2025 at 12:06 AM 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 singl
On Wed, 22 Jan 2025 16:14:59 +
Tvrtko Ursulin wrote:
> On 22/01/2025 15:51, Boris Brezillon wrote:
> > On Wed, 22 Jan 2025 15:08:20 +0100
> > Philipp Stanner wrote:
> >
> >> --- a/drivers/gpu/drm/panthor/panthor_sched.c
> >> +++ b/drivers/gpu/drm/panthor/panthor_sched.c
> >> @@ -3272,6 +3
Hi Dave, Simona,
Fixes for 6.14.
The following changes since commit 97e5c9e4139087a67c2469488360a6d6afdd4b69:
drm/amd/display: fix CEC DC_DEBUG_MASK documentation (2025-01-16 16:23:22
-0500)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-d
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 panels with mainline, which is exactly what's
installed on the Fa
On 22/01/2025 15:51, Boris Brezillon wrote:
On Wed, 22 Jan 2025 15:08:20 +0100
Philipp Stanner wrote:
--- a/drivers/gpu/drm/panthor/panthor_sched.c
+++ b/drivers/gpu/drm/panthor/panthor_sched.c
@@ -3272,6 +3272,7 @@ group_create_queue(struct panthor_group *group,
const str
Hi Maxime,
On Wed, 8 Jan 2025 17:02:04 +0100
Maxime Ripard wrote:
[...]
> > > > And we'll also need some flag in drm_bridge to indicate that the device
> > > > is gone, similar to what drm_dev_enter()/drm_dev_exit() provides,
> > > > because now your bridge driver sticks around for much longer
On Sun, Nov 24, 2024 at 05:02:12PM +0900, Hironori KIKUCHI wrote:
> This is a display panel used in the recent revision of the Anbernic
> RG35XX Plus, a handheld gaming device from Anbernic.
> It is 3.45 inches in size (diagonally) with a resolution of 640x480.
>
> It has the same interface (pins
[AMD Official Use Only - AMD Internal Distribution Only]
Hey,
We can certainly talk about it and explore a bit more on the request.
Regards
Shashank
From: robert.d...@yahoo.fr
Sent: Wednesday, January 22, 2025 4:42 PM
To: dri-devel@lists.freedesktop.org; amd-gfx l
On Wed, 22 Jan 2025 15:08:20 +0100
Philipp Stanner wrote:
> --- a/drivers/gpu/drm/panthor/panthor_sched.c
> +++ b/drivers/gpu/drm/panthor/panthor_sched.c
> @@ -3272,6 +3272,7 @@ group_create_queue(struct panthor_group *group,
> const struct drm_panthor_queue_create *args)
> {
>
Hello,
Do you plan to migrate some of the GPU-Open repos to this Gitlab org ? Or is it
for a very distant future as the priority for the next years is on Wayland
AMD-specific optimisations/interfaces/protocols ? (or give in to the second
principle of thermodynamics :D )
Le mercredi 22 janvi
Am 22.01.25 um 16:23 schrieb Philipp Stanner:
On Wed, 2025-01-22 at 16:06 +0100, Christian König wrote:
Am 22.01.25 um 15:48 schrieb Philipp Stanner:
On Wed, 2025-01-22 at 15:34 +0100, Christian König wrote:
Am 22.01.25 um 15:08 schrieb Philipp Stanner:
drm_sched_init() has a great many param
On Wed, Jan 22, 2025 at 04:06:10PM +0100, Christian König wrote:
> Am 22.01.25 um 15:48 schrieb Philipp Stanner:
> > On Wed, 2025-01-22 at 15:34 +0100, Christian König wrote:
> > > Am 22.01.25 um 15:08 schrieb Philipp Stanner:
> > > > drm_sched_init() has a great many parameters and upcoming new
>
On Wed, 2025-01-22 at 16:06 +0100, Christian König wrote:
> Am 22.01.25 um 15:48 schrieb Philipp Stanner:
> > On Wed, 2025-01-22 at 15:34 +0100, Christian König wrote:
> > > Am 22.01.25 um 15:08 schrieb Philipp Stanner:
> > > > drm_sched_init() has a great many parameters and upcoming new
> > > > f
Am 22.01.25 um 15:48 schrieb Philipp Stanner:
On Wed, 2025-01-22 at 15:34 +0100, Christian König wrote:
Am 22.01.25 um 15:08 schrieb Philipp Stanner:
drm_sched_init() has a great many parameters and upcoming new
functionality for the scheduler might add even more. Generally, the
great number of
On Wed, Jan 22, 2025 at 03:48:54PM +0100, Philipp Stanner wrote:
> On Wed, 2025-01-22 at 15:34 +0100, Christian König wrote:
> > Am 22.01.25 um 15:08 schrieb Philipp Stanner:
> > > drm_sched_init() has a great many parameters and upcoming new
> > > functionality for the scheduler might add even mor
Am 22.01.25 um 15:37 schrieb Jason Gunthorpe:
My main interest has been what data structure is produced in the
attach APIs.
Eg today we have a struct dma_buf_attachment that returns a sg_table.
I'm expecting some kind of new data structure, lets call it "physical
list" that is some efficient co
[AMD Official Use Only - AMD Internal Distribution Only]
Introducing AMDGPU Composition Stack (ACS).
ACS is simply AMD's fork of Weston compositor, with some additional advanced
features. We have created ACS considering the following primary goals in mind:
* To act as a staging area for Wayl
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:25PM -0300, Gustavo Sousa wrote:
> The header drm_print.h uses member
On Wed, 2025-01-22 at 15:34 +0100, Christian König wrote:
> Am 22.01.25 um 15:08 schrieb Philipp Stanner:
> > 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 readability and
Ensure drm headers build, are self-contained, have header guards, and
have no kernel-doc warnings, when CONFIG_DRM_HEADER_TEST=y.
The mechanism follows similar patters used in i915, xe, and usr/include.
To cover include/drm, we need to recurse there using the top level
Kbuild and the new include/
drm_client_event.h uses bool without types.h, include it.
Fixes: bf17766f1083 ("drm/client: Move suspend/resume into DRM client
callbacks")
Cc: Thomas Zimmermann
Signed-off-by: Jani Nikula
---
include/drm/drm_client_event.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_
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-contained
drm: ensure drm headers are self-contained and pass kernel-doc
K
On Wed, Jan 22, 2025 at 02:29:09PM +0100, Christian König wrote:
> I'm having all kind of funny phenomena with AMDs mail servers since coming
> back from xmas vacation.
:(
A few years back our IT fully migrated our email to into Office 365
cloud and gave up all the crazy half on-prem stuff they
Am 22.01.25 um 15:08 schrieb Philipp Stanner:
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 readability and has already caused
one missnaming in:
commit 6f1cacf4eba7 ("drm/nouve
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:25PM -0300, Gustavo Sousa wrote:
The header drm_print.h uses members of struct drm_device pointers, as
such, it
On Wed, Jan 22, 2025 at 03:08:20PM +0100, 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 readability and has already caused
> one missnaming in:
>
> co
On 1/17/2025 2:46 AM, Konrad Dybcio wrote:
> On 15.01.2025 8:59 PM, Dmitry Baryshkov wrote:
>> On Thu, Jan 16, 2025 at 01:07:17AM +0530, Akhil P Oommen wrote:
>>> On 1/9/2025 7:27 PM, Konrad Dybcio wrote:
On 8.01.2025 11:42 PM, Akhil P Oommen wrote:
> Adreno X1-85 has an additional bit whi
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 readability and has already caused
one missnaming in:
commit 6f1cacf4eba7 ("drm/nouveau: Improve variable name in
nouveau_sched_init
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:25PM -0300, Gustavo Sousa wrote:
>>> 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
On Wed, 22 Jan 2025, Krzysztof Karas wrote:
> Hi Ingyu,
>
>> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
>> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
>> index d60a6ca0cae5..8d22d8f2243d 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
>> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
>> @@ -31
Am 22.01.25 um 12:04 schrieb Simona Vetter:
On Tue, Jan 21, 2025 at 01:36:33PM -0400, Jason Gunthorpe wrote:
On Tue, Jan 21, 2025 at 05:11:32PM +0100, Simona Vetter wrote:
On Mon, Jan 20, 2025 at 03:48:04PM -0400, Jason Gunthorpe wrote:
On Mon, Jan 20, 2025 at 07:50:23PM +0100, Simona Vetter w
On Wed, Jan 22, 2025 at 12:04:19PM +0100, Simona Vetter wrote:
> I'm kinda leaning towards entirely separate dma-buf interfaces for the new
> phyr stuff, because I fear that adding that to the existing ones will only
> make the chaos worse.
Lets see when some patches come up, if importers have t
Hi Ingyu,
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index d60a6ca0cae5..8d22d8f2243d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -311,7 +311,7 @@ static struct intel_context *gen8_ggtt_b
On Wed, Jan 22, 2025 at 12:32:56PM +0800, Xu Yilun wrote:
> On Tue, Jan 21, 2025 at 01:43:03PM -0400, Jason Gunthorpe wrote:
> > On Tue, Jun 25, 2024 at 05:12:10AM +0800, Xu Yilun wrote:
> >
> > > When VFIO works as a TEE user in VM, it means an attester (e.g. PCI
> > > subsystem) has already move
Quoting Simona Vetter (2025-01-22 08:11:53-03:00)
>On Tue, Jan 21, 2025 at 06:09:25PM -0300, Gustavo Sousa wrote:
>> 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 suc
On Wed, 22 Jan 2025 at 13:25, Joel Granados wrote:
>
> On Tue, Jan 21, 2025 at 02:40:16PM +0100, Alexander Gordeev wrote:
> > On Fri, Jan 10, 2025 at 03:16:08PM +0100, Joel Granados wrote:
> >
> > Hi Joel,
> >
> > > Add the const qualifier to all the ctl_tables in the tree except for
> > > watchdo
On Tue, Jan 21, 2025 at 02:40:16PM +0100, Alexander Gordeev wrote:
> On Fri, Jan 10, 2025 at 03:16:08PM +0100, Joel Granados wrote:
>
> Hi Joel,
>
> > Add the const qualifier to all the ctl_tables in the tree except for
> > watchdog_hardlockup_sysctl, memory_allocation_profiling_sysctls,
> > load
Hi,
merged into drm-misc-fixes. Should reach upstream by next week. Thanks
for the patch.
Best regards
Thomas
Am 22.01.25 um 10:02 schrieb Arnd Bergmann:
From: Arnd Bergmann
In the combination of DRM_KMS_HELPER=m, DRM_GEM_SHMEM_HELPER=y,
DRM_FBDEV_EMULATION=y,
The shmem code fails to lin
On 22/01/2025 12:26, Michal Wilczynski wrote:
>>>
>>> These power-domain constants are defined by the AON firmware protocol,
>>> which dictates the exact IDs (e.g., 1 for NPU). They are not just array
>>> indices; we must use these specific values to communicate with the
>>> firmware correctly. Usi
Hi Haoxiang,
For reasons that I have not uncovered yet, the work email servers never
delivered your message, I have discovered it today accidentally while
looking in a backup I have at home.
On Thu, Dec 19, 2024 at 05:02:56PM +0800, Haoxiang Li wrote:
> Add check for the return value of komeda_ge
On 1/22/25 08:46, Krzysztof Kozlowski wrote:
> On 21/01/2025 22:42, Michal Wilczynski wrote:
>>
>>
>> On 1/21/25 11:02, Krzysztof Kozlowski wrote:
>>> On Mon, Jan 20, 2025 at 06:20:58PM +0100, Michal Wilczynski wrote:
The T-Head TH1520 SoC contains multiple power islands that can be
pr
Hello,
On Mon, 4 Nov 2024 at 23:28, Rodrigo Vivi wrote:
>
> On Mon, Nov 04, 2024 at 02:09:46PM +0200, Giedrius Statkevičius wrote:
> > Hello,
> >
> > Kind ping.
>
> There was a pipe underun in CI... I honestly don't believe this patch is
> causing it, but anyway I decided to trigger a retest ther
On Tue, Jan 21, 2025 at 06:09:25PM -0300, Gustavo Sousa wrote:
> 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 ne
On Tue, Jan 21, 2025 at 01:36:33PM -0400, Jason Gunthorpe wrote:
> On Tue, Jan 21, 2025 at 05:11:32PM +0100, Simona Vetter wrote:
> > On Mon, Jan 20, 2025 at 03:48:04PM -0400, Jason Gunthorpe wrote:
> > > On Mon, Jan 20, 2025 at 07:50:23PM +0100, Simona Vetter wrote:
> > > > On Mon, Jan 20, 2025 at
On Tue, Jan 21, 2025 at 02:21:57PM -0500, Marek Olšák wrote:
> On Mon, Jan 20, 2025 at 1:41 PM Simona Vetter
> wrote:
>
> > On Mon, Jan 20, 2025 at 08:58:20AM +0100, Thomas Zimmermann wrote:
> > > Hi
> > >
> > >
> > > Am 18.01.25 um 03:37 schrieb Marek Olšák:
> > > [...]
> > > >
> > > > 3) Implem
On Wed 22 Jan 2025 at 17:50, Ao Xu wrote:
> 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
On 22/01/2025 11:14, Andy Yan wrote:
> Hi,
>
> At 2025-01-22 16:04:59, "Krzysztof Kozlowski" wrote:
>> On Tue, Jan 21, 2025 at 06:34:57PM +0800, Andy Yan wrote:
>>> From: Andy Yan
>>>
>>> Add vop found on rk3576, the main difference between rk3576 and the
>>> previous vop is that each VP has it
Hi,
At 2025-01-22 16:04:59, "Krzysztof Kozlowski" wrote:
>On Tue, Jan 21, 2025 at 06:34:57PM +0800, Andy Yan wrote:
>> From: Andy Yan
>>
>> Add vop found on rk3576, the main difference between rk3576 and the
>> previous vop is that each VP has its own interrupt line.
>>
>> Signed-off-by: Andy
Hi
At 2025-01-22 16:04:59, "Krzysztof Kozlowski" wrote:
>On Tue, Jan 21, 2025 at 06:34:57PM +0800, Andy Yan wrote:
>> From: Andy Yan
>>
>> Add vop found on rk3576, the main difference between rk3576 and the
>> previous vop is that each VP has its own interrupt line.
>>
>> Signed-off-by: Andy
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, the interrupt is shared by several
>>> interrupt
>>> + sources, suc
On Tue, Jan 21, 2025 at 04:58:03PM -0800, Abhinav Kumar wrote:
>
>
> On 12/13/2024 2:14 PM, Dmitry Baryshkov wrote:
> > Continue migration to the MDSS-revision based checks and replace
> > DPU_CTL_ACTIVE_CFG feature bit with the core_major_ver >= 5 check.
> >
> > Signed-off-by: Dmitry Baryshkov
Hi
At 2025-01-22 17:43:34, "Krzysztof Kozlowski" wrote:
>On 22/01/2025 10:29, Andy Yan wrote:
>>
>> Hi
>> At 2025-01-22 16:03:00, "Krzysztof Kozlowski" wrote:
>>> On Tue, Jan 21, 2025 at 06:34:44PM +0800, Andy Yan wrote:
From: Andy Yan
Propertie "rockchip,grf" is required for r
On 22/01/2025 10:29, Andy Yan wrote:
>
> Hi
> At 2025-01-22 16:03:00, "Krzysztof Kozlowski" wrote:
>> On Tue, Jan 21, 2025 at 06:34:44PM +0800, Andy Yan wrote:
>>> From: Andy Yan
>>>
>>> Propertie "rockchip,grf" is required for rk3566/8.
>>
>> Fix typos.
>>
>> Why? What we see from the diff...
>
Hi Dmitry,
On 2025/1/22 16:17, Damon Ding wrote:
Hi Dmitry,
On 2025/1/9 20:48, Dmitry Baryshkov wrote:
On Thu, Jan 09, 2025 at 11:27:17AM +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()
Hi Doug,
Can you spare some time to help review it? Thanks a lot.
On Fri, Jan 17, 2025 at 5:14 PM Langyan Ye <
yelang...@huaqin.corp-partner.google.com> wrote:
> Fix the workflow of the previous email and resend it with all necessary
> recipient entries
>
> Changes in v3:
> - Link to v2:
> https:
Hi
At 2025-01-22 16:03:00, "Krzysztof Kozlowski" wrote:
>On Tue, Jan 21, 2025 at 06:34:44PM +0800, Andy Yan wrote:
>> From: Andy Yan
>>
>> Propertie "rockchip,grf" is required for rk3566/8.
>
>Fix typos.
>
>Why? What we see from the diff...
This property is used in dts, see vop dt node in rk35
> On Wed, Jan 08, 2025 at 11:09:00AM +0530, Arun R Murthy wrote:
> > Expose drm plane function to create formats/modifiers blob. This
> > function can be used to expose list of supported formats/modifiers for
> > sync/async flips.
> >
> > Signed-off-by: Arun R Murthy
> > ---
> > drivers/gpu/drm/d
Lockdep detects the following issue on led-backlight removal:
[ 142.315935] [ cut here ]
[ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455
led_sysfs_enable+0x54/0x80
...
[ 142.500725] Call trace:
[ 142.503176] led_sysfs_enable+0x54/0x80 (P
From: Arnd Bergmann
In the combination of DRM_KMS_HELPER=m, DRM_GEM_SHMEM_HELPER=y,
DRM_FBDEV_EMULATION=y,
The shmem code fails to link against the KMS helpers:
x86_64-linux-ld: vmlinux.o: in function `drm_fbdev_shmem_driver_fbdev_probe':
(.text+0xeec601): undefined reference to `drm_fb_helper_
Hi Andy,
On 2025/1/11 18:28, Andy Yan wrote:
Hi Damon,
At 2025-01-09 11:27:25, "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
- Add aux-bus/panel nodes
Signed-off-by: Damon Ding
---
C
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_...() functions.
Use drm_err()/drm_dbg_core()/drm_dbg_kms() instead of
On certain 4K panels, the BIOS framebuffer
exceeds the panel's required dimensions,
leading to display corruption.
This patch introduces a validation check to address the issue.
Signed-off-by: Atharva Tiwari
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 6 +++---
1 file changed, 3 insertions(
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 Tue, 2025-01-21 at 16:15 +0100, Philipp Stanner wrote:
> Changes in v2:
> - Document what run_job() is allowed to return. (Tvrtko)
> - Delete confusing comment about putting the fence. (Danilo)
> - Apply Danilo's RB to patch 1.
> - Delete info about job recovery for entities in patch 3.
On 21/01/2025 22:58, Michal Wilczynski wrote:
>>> +maintainers:
>>> + - Michal Wilczynski
>>> +
>>> +properties:
>>> + compatible:
>>> +enum:
>>> + - thead,th1520-reset
>>> +
>>> + reg:
>>> +maxItems: 1
>>> +
>>> + "#reset-cells":
>>> +const: 0
>>
>> Should this be "const: 1"
1 - 100 of 108 matches
Mail list logo
