Hi
thanks for the patch.
Am 22.01.25 um 07:46 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 link against the KMS helpers:
x86_64-linux-ld: vmlinux.o: in function `drm_fbdev_shmem_driv
Hi,
thanks for the bug report. Arnd just sent a fix, I think.
https://lore.kernel.org/dri-devel/20250122064655.1095176-1-a...@kernel.org/T/#u
Best regards
Thomas
Am 21.01.25 um 13:06 schrieb Marc Kleine-Budde:
Hello,
while working on something completely different, I stumbled over this
link
Alexander Stein writes:
> Hi,
>
> I'm sorry I'm late to the party.
>
> Am Mittwoch, 14. August 2024, 12:37:26 CET schrieb Esben Haabendal:
>> Using the correct bit helps. The documentation specifies bit 0 in both
>> registers to be controlling polarity of dpi_vsync_input and
>> dpi_hsync_input po
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
>>> programmatically turned on and off using the AON (Always
On 21/01/2025 22:31, Michal Wilczynski wrote:
>>> +#define TH1520_AON_VDEC_PD 1
>>> +#define TH1520_AON_NPU_PD 2
>>> +#define TH1520_AON_VENC_PD 3
>>> +#define TH1520_AON_GPU_PD 4
>>> +#define TH1520_AON_DSP0_PD 5
>>> +#define TH1520_AON_DSP1_PD 6
>>
>> I don't see these being used in the driver.
On 21/01/2025 22:29, Michal Wilczynski wrote:
>
>
> On 1/21/25 10:47, Krzysztof Kozlowski wrote:
>> On Mon, Jan 20, 2025 at 06:20:54PM +0100, Michal Wilczynski wrote:
>>> properties:
>>>compatible:
>>> -const: thead,th1520-clk-ap
>>> +enum:
>>> + - thead,th1520-clk-ap
>>> +
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 call to drm_dev_put()
from bochs_pci_remove().
Fixes a double unref in devm_drm
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_
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 [Arun]
--v3
-Move the function to drm_core [Dmitry/Jani]
S
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 till the
extended timeout that is being granted for LTTPRs from the
sink
Add DPCD registers required to configure Extended Wake Timeout
for LTTPR.
Signed-off-by: Suraj Kandpal
Reviewed-by: Arun R Murthy
---
include/drm/display/drm_dp.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
inde
Retimers in H/w usually takes 30 to 40ms to wake up all the devices. To
get this we use the Extended Wake Time feature in which the sink device
tells us the minimum amount of time it requires to wake up and we need
to do a write to grant this request else we need to wake up within 1ms
of low power
On Tue, Jan 21, 2025 at 02:14:56AM +0100, Xaver Hugl wrote:
> > +It is the responsibility of the consumer to make sure that the device or
> > +its resources are not in use by any process before attempting recovery.
> I'm not convinced this is actually doable in practice, outside of
> killing all ap
> 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 [Arun]
>
> --v3
> -Move the function to drm_cor
On Tue, Jan 21, 2025 at 01:59:47AM +0100, Xaver Hugl wrote:
> Hi,
>
> I experimented with using this in KWin, and
> https://invent.kde.org/plasma/kwin/-/merge_requests/7027/diffs?commit_id=6da40f1b9e2bc94615a436de4778880cee16f940
> makes it fall back to a software renderer when a rebind is require
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 moved the device to RUN state. So VFIO & DPDK
> > are all TEE users, no
On Mon, Jan 20, 2025 at 02:44:13PM +0100, Christian König wrote:
> Am 21.06.24 um 00:02 schrieb Xu Yilun:
> > On Thu, Jan 16, 2025 at 04:13:13PM +0100, Christian König wrote:
> > > Am 15.01.25 um 18:09 schrieb Jason Gunthorpe:
> > >
> > > On Wed, Jan 15, 2025 at 05:34:23PM +0100, Christian K
Changes the samsung-s6e88a0-ams452ef01 panel to use multi style functions
for improved error handling.
Reviewed-by: Douglas Anderson
Signed-off-by: Tejas Vipin
---
Changes in v2:
- changed s6e88a0_ams452ef01_off to return void
Link to v1:
https://lore.kernel.org/all/20250121134819.251718-1
From: Shixiong Ou
Convert platform_get_resource(), devm_ioremap_resource() to a single call to
devm_platform_get_and_ioremap_resource().
Signed-off-by: Shixiong Ou
---
V1 -> V2: Add Missing commit message.
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 dele
From: Shixiong Ou
Convert platform_get_resource(), devm_ioremap_resource() to a single call to
devm_platform_get_and_ioremap_resource().
Signed-off-by: Shixiong Ou
---
V1 -> V2: Add Missing commit message.
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 4 +---
drivers/gpu/drm/bridge/mic
在 2025/1/21 18:16, Dmitry Baryshkov 写道:
On Tue, Jan 21, 2025 at 04:13:36PM +0800, oushixiong1...@163.com wrote:
From: Shixiong Ou
Missing commit message
I will add commit message on v2, thanks.
Signed-off-by: Shixiong Ou
This doesn't match your email address, so SoB is missing.
The SMA
在 2025/1/21 18:16, Dmitry Baryshkov 写道:
On Tue, Jan 21, 2025 at 03:50:41PM +0800, oushixiong1...@163.com wrote:
From: Shixiong Ou
Missing commit message
I will add commit message on v2, thanks.
Signed-off-by: Shixiong Ou
This doesn't match your email address, so SoB is missing.
The SM
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
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 8 ++--
driv
Hi Abhinav,
On Wed, 22 Jan 2025 at 02:28, Abhinav Kumar wrote:
>
>
>
> On 12/13/2024 2:14 PM, Dmitry Baryshkov wrote:
> > Stop declaring DPU_DSPP_PCC as a part of the DSPP features, use the
> > presence of the PCC sblk to check whether PCC is present in the hardware
> > or not.
> >
> > Signed-off
On 12/13/2024 2:14 PM, Dmitry Baryshkov wrote:
Continue migration to the MDSS-revision based checks and replace
DPU_CTL_HAS_LAYER_EXT4 feature bit with the core_major_ver >= 9 check.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h | 12 ++---
The pull request you sent on Fri, 17 Jan 2025 15:22:44 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-next-2025-01-17
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/96c84703f1cf6ea43617f9565166681cd71df104
Thank you!
--
Deet-doot-dot, I am a bot.
ht
On 12/13/2024 2:14 PM, Dmitry Baryshkov wrote:
Stop declaring DPU_DSPP_PCC as a part of the DSPP features, use the
presence of the PCC sblk to check whether PCC is present in the hardware
or not.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h |
On Fri, Jan 17, 2025 at 12:42:48PM -0500, Rodrigo Vivi wrote:
On Fri, Jan 17, 2025 at 08:45:29AM -0800, Lucas De Marchi wrote:
When the xe driver was added, it didn't extend the exclude entries for
drm-misc, as done in commit 5a44d50f0072 ("MAINTAINERS: Update drm-misc
entry to match all drivers
On Tue, Jan 21, 2025 at 11:09:34AM -0800, Alan Previn wrote:
> The GuC-Error-Capture is currently reaching into xe_devcoredump
> structure to store its own place-holder snaphot to workaround
> the race between G2H-Error-Capture-Notification vs Drm-Scheduler
> triggering GuC-Submission-exec-queue-ti
On Tue, 21 Jan 2025 at 14:59, Rodrigo Vivi wrote:
>
> I'm pushing this soon to drm-intel-next, unless Linus want to take
> this one directly to his tree
Let's just go through the proper channels and go through the drm tree.
Unless I've issed something, I think this is only an active issue on
par
The TUXEDO Sirius 16 Gen1 and TUXEDO Sirius 16 Gen2 devices have a per-key
controllable RGB keyboard backlight. The firmware API for it is implemented
via WMI.
To make the backlight userspace configurable this driver emulates a
LampArray HID device and translates the input from hidraw to the
corre
Hi,
after some other work, picked this up again.
Only coding style changes vs v4.
I now got my feet a little wet with hid-bpf regarding something else, and
with that knowledge I would leave the long arrays in the beginning in the
kernel code for the time being:
sirius_16_ansii_kbl_mapping and si
On Tue, Jan 21, 2025 at 06:52:03AM -0800, Guenter Roeck wrote:
> The scale() functions detects invalid parameters, but continues
> its calculations anyway. This causes bad results if negative values
> are used for unsigned operations. Worst case, a division by 0 error
> will be seen if source_min =
On 1/20/25 14:00, Laurent Pinchart wrote:
On Fri, Jan 10, 2025 at 01:23:40PM -0800, James Jones wrote:
On 12/19/24 10:03, Simona Vetter wrote:
On Thu, Dec 19, 2024 at 09:02:27AM +, Daniel Stone wrote:
On Wed, 18 Dec 2024 at 10:32, Brian Starkey wrote:
On Wed, Dec 18, 2024 at 11:24:58AM +
On 1/21/25 09:35, Philipp Zabel wrote:
> On Mo, 2025-01-20 at 18:21 +0100, Michal Wilczynski wrote:
>> Add a YAML schema for the T-HEAD TH1520 SoC reset controller. This
>> controller manages resets for subsystems such as the GPU within the
>> TH1520 SoC.
>
> This mentions "resets", plural, but
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
>> programmatically turned on and off using the AON (Always-On) protocol
>> and a hardware mailbox [1]. The relev
On 1/21/25 10:56, Krzysztof Kozlowski wrote:
> On Mon, Jan 20, 2025 at 06:20:57PM +0100, Michal Wilczynski wrote:
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>
> How/where do you use this header?
Indeed, it's used by the power-domain d
On 1/21/25 10:52, Krzysztof Kozlowski wrote:
> On Mon, Jan 20, 2025 at 06:20:56PM +0100, Michal Wilczynski wrote:
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 0fa7c5728f1e..c56a1fb6e02a 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -20184,6 +20184,7 @@ M: Fu Wei
>> L: linux-r
On 1/21/25 10:47, Krzysztof Kozlowski wrote:
> On Mon, Jan 20, 2025 at 06:20:54PM +0100, Michal Wilczynski wrote:
>> properties:
>>compatible:
>> -const: thead,th1520-clk-ap
>> +enum:
>> + - thead,th1520-clk-ap
>> + - thead,th1520-clk-vo
>>
>>reg:
>> maxItems: 1
On Fri, Jan 17, 2025 at 11:47:41AM +0200, Gwan-gyeong Mun wrote:
> Hi,
> This kernel oops, which I reported before, was caused by my incorrect
> modification (incorrect applying of review comments) of this patch
> "[v3,19/30] drm/xe: Add SVM device memory mirroring"
> ( the kernel oops occurred bec
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 forced to include the
Hi,
On Tue, Jan 21, 2025 at 5:48 AM Tejas Vipin wrote:
>
> @@ -136,12 +113,8 @@ static int s6e88a0_ams452ef01_prepare(struct drm_panel
> *panel)
> static int s6e88a0_ams452ef01_unprepare(struct drm_panel *panel)
> {
> struct s6e88a0_ams452ef01 *ctx = to_s6e88a0_ams452ef01(panel);
> -
On Tue, Jan 21, 2025 at 2:11 PM Ian Forbes wrote:
>
> On Fri, Jan 17, 2025 at 1:20 PM Zack Rusin wrote:
> >
> > You're going to have to explain that one in the commit message a lot
> > better because as is it doesn't make sense to me. Especially the
> > !vbo->is_dumb in vmw_bo_free.
> >
> > z
>
>
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) Implementing DRM_FORMAT_MOD_LINEAR as having 256B pitch and offset
> > > alignment. This
The GuC-Error-Capture is currently reaching into xe_devcoredump
structure to store its own place-holder snaphot to workaround
the race between G2H-Error-Capture-Notification vs Drm-Scheduler
triggering GuC-Submission-exec-queue-timeout/kill.
Part of that race workaround design included GuC-Error-C
On Fri, Jan 17, 2025 at 1:20 PM Zack Rusin wrote:
>
> You're going to have to explain that one in the commit message a lot
> better because as is it doesn't make sense to me. Especially the
> !vbo->is_dumb in vmw_bo_free.
>
> z
The dirty tracker is freed later in vmw_bo_release when it's a
cohere
The order of the devcoredump event flow is:
drm-scheduler -> guc-submission-execq-timed-out-job ->
guc-submission-kill-job -> xe-devcoredump (once the work
is confirmed to have been killed).
As we are aware, the GuC-FW IRQ for error-capture delivery
and extraction could have happened before the st
Hi Dmitry,
On 21/01/25 16:20, Dmitry Baryshkov wrote:
> On Mon, Jan 20, 2025 at 11:18:22PM +0530, Aradhya Bhatia wrote:
>> Hi Dmitry,
>>
>> On 20/01/25 14:08, Dmitry Baryshkov wrote:
>>> On Fri, Jan 17, 2025 at 06:37:00PM +0530, Aradhya Bhatia wrote:
Hi Dmitry,
On 14/01/25 16:54, Dm
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 moved the device to RUN state. So VFIO & DPDK
> are all TEE users, no need to manipulate TDISP state between them.
> AFAICS, this is the most pre
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 01:59:01PM -0400, Jason Gunthorpe wrote:
> > > > On Mon, Jan 20, 2025 at
On 1/21/2025 10:06 AM, Manivannan Sadhasivam wrote:
On Tue, Jan 21, 2025 at 08:29:32AM -0700, Jeffrey Hugo wrote:
On 1/20/2025 10:16 PM, Manivannan Sadhasivam wrote:
On Fri, Jan 17, 2025 at 10:09:43AM -0700, Jeffrey Hugo wrote:
Add basic support for the new AIC200 product. The PCIe Device ID i
Adding the following formats
- DRM_FORMAT_RX106
- DRM_FORMAT_GXRX106106
- DRM_FORMAT_RX124
- DRM_FORMAT_GXRX124124
- DRM_FORMAT_AXBXGXRX124124124124
- DRM_FORMAT_RX142
- DRM_FORMAT_GXRX142142
- DRM_FORMAT_AXBXGXRX142142142142
They are useful for communicatin
On Tue, Jan 21, 2025 at 08:29:32AM -0700, Jeffrey Hugo wrote:
> On 1/20/2025 10:16 PM, Manivannan Sadhasivam wrote:
> > On Fri, Jan 17, 2025 at 10:09:43AM -0700, Jeffrey Hugo wrote:
> > > Add basic support for the new AIC200 product. The PCIe Device ID is
> > > 0xa110. With this, we can turn on the
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 01:59:01PM -0400, Jason Gunthorpe wrote:
> > > On Mon, Jan 20, 2025 at 01:14:12PM +0100, Christian König wrote:
> > > What is going wrong wit
On 21/01/25 - 11:45, José Expósito wrote:
> On Mon, Jan 20, 2025 at 06:26:07PM +0100, Louis Chauvet wrote:
> > On 20/01/25 - 17:23, José Expósito wrote:
> > > > A specific allocation for the CRTC is not strictly necessary at this
> > > > point, but in order to implement dynamic configuration of VKM
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 single interface) make it impossible to use
> Display Strea
On 1/20/2025 10:16 PM, Manivannan Sadhasivam wrote:
On Fri, Jan 17, 2025 at 10:09:43AM -0700, Jeffrey Hugo wrote:
Add basic support for the new AIC200 product. The PCIe Device ID is
0xa110. With this, we can turn on the lights for AIC200 by leveraging
much of the existing driver.
Co-developed-b
The documentation for drm_sched_backend_ops.run_job() mentions a certain
function called drm_sched_job_recovery(). This function does not exist.
What's actually meant is drm_sched_resubmit_jobs(), which is by now also
deprecated.
Remove the mention of the removed function.
Discourage the behavior
drm_sched_backend_ops.timedout_job()'s documentation is outdated. It
mentions the deprecated function drm_sched_resubmit_job(). Furthermore,
it does not point out the important distinction between hardware and
firmware schedulers.
Since firmware schedulers tyipically only use one entity per schedu
From: Philipp Stanner
drm_sched_backend_ops.run_job() returns a dma_fence for the scheduler.
That fence is signalled by the driver once the hardware completed the
associated job. The scheduler does not increment the reference count on
that fence, but implicitly expects to inherit this fence from
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. (Danilo, me)
- Set the term "ring" as fix term for both HW rings a
The scale() functions detects invalid parameters, but continues
its calculations anyway. This causes bad results if negative values
are used for unsigned operations. Worst case, a division by 0 error
will be seen if source_min == source_max.
On top of that, after v6.13, the sequence of WARN_ON() f
To allows the userspace to test many hardware configuration, introduce a
new interface to configure CRTCs and encoders.
The CRTCs and encoders are created in their own directory. To link the
CRTC, symlinks are used in the `possible_crtcs` folders.
The current interface is:
/config/vkms
DE
On Sat, Jan 18, 2025 at 06:47:27PM +0100, Michal Wajdeczko wrote:
>
>
> On 17.01.2025 22:57, Vinay Belgaumkar wrote:
> > Default SLPC power profile is Base(0). Power Saving mode(1)
> > has conservative up/down thresholds and is suitable for use with
> > apps that typically need to be power effici
In order to support multiple configuration, add the possibility to change
the encoder type.
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_configfs.c | 57
1 file changed, 57 insertions(+)
diff --git a/drivers/gpu/drm/vkms/vkms_configfs.c
b/driv
To allows the userspace to identify the device once it is enabled, create
a file to fetch it.
This file can only be read once the device is enabled, and will return the
device name, which can later be used to use it.
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_configfs.c | 16 +++
A connector can't be identified by a name, so add a configfs file to
retrieve its id.
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_configfs.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/vkms/vkms_configfs.c
b/drivers/gpu/drm/vkms/vkms_c
To allows the userspace to test many hardware configuration, introduce a
new interface to change a connector type.
The type of a connector can be changed by editing the file type and by
writing the connector type number.
The current interface is:
/config/vkms
DEVICE_1
┣━ enable
To allows the userspace to test many hardware configuration, introduce a
new interface to create and configure connectors.
The connectors are created by creating a directory in the `connectors`
directory.
Connectors and encoders can be linked by creating a symlink in the
possible_encoders directo
To allows the userspace to test many hardware configuration, introduce a
new interface to configure the available formats per planes. VKMS
supports many formats, so the userspace can choose any combination of
them.
The supported formats are configured by writing in the file
supported_formats:
- `+
As a connector can be connected and disconnected once a device is created,
create a file to allow changing this status.
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_configfs.c | 45
1 file changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/
Due to limitation of ConfigFS, the max len of EDID is PAGE_SIZE (4kB on
x86), it should be sufficient for many tests. One possible evolution is
using a ConfigFS blob to allow bigger EDID.
The EDID can be changed at any time. As for physical display, you need
to trigger an HPD event to refresh the
To avoid having dangling pointers in struct vkms_config, remove all of
them when the device is destroyed.
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_config.c | 23 +++
drivers/gpu/drm/vkms/vkms_config.h | 3 ++-
drivers/gpu/drm/vkms/vkms_drv.c| 2 +-
3 f
To allows the userspace to test many hardware configuration, introduce a
new interface to create and configure planes.
The planes are created by creating a directory in the `planes` directory.
The type of plane is configured by writing 0 (Overlay), 1 (primary) or 2
(cursor) in the file `type`.
As
To allows the userspace to test many hardware configuration, introduce a
new interface to configure the available rotation per planes. VKMS
supports any rotation and reflection, so the userspace can choose any
combination.
The supported rotations are configured by writing a rotation bitmask to
the
VKMS is manly used to test userspace program and its behavior. The current
implementation is not very configurable as you can only have one device,
with few specific planes.
This is the introduction of a basic interface to dynamically create new
devices.
The new interface is:
/config/vkms
DEVIC
In preparation for introduction of ConfigFS support, expose the
vkms_destroy/create helper to remove a vkms device.
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_drv.c | 4 ++--
drivers/gpu/drm/vkms/vkms_drv.h | 3 +++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/d
e aims to be extendable (new property can easly be added in
objects) and easy to use (objects are created simply by creating folders,
and configured by writing files).
This series depends on
https://lore.kernel.org/all/20250121-google-remove-crtc-index-from-parameter-v3-0-cac00a3c3...@bootlin.com/
S
Changes the samsung-s6e88a0-ams452ef01 panel to use multi style functions
for improved error handling.
Signed-off-by: Tejas Vipin
---
.../panel/panel-samsung-s6e88a0-ams452ef01.c | 89 +++
1 file changed, 31 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/panel/pane
On Tue, Jan 21, 2025 at 03:34:20AM +, Murthy, Arun R wrote:
> > On Wed, Jan 08, 2025 at 11:09:02AM +0530, Arun R Murthy wrote:
> > > Populate the list of formats/modifiers supported by async flip.
> > > Register a async property and expose the same to user through blob.
> > >
> > > Signed-off-b
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,
> loadpin_sysctl_table and the ones calling register_net_sysctl (./net,
> drivers/inifi
On Tue, Jan 21, 2025 at 08:33:09AM +0100, Marek Szyprowski wrote:
> On 17.01.2025 18:28, Andy Shevchenko wrote:
> > On Fri, Jan 17, 2025 at 05:05:42PM +0100, Marek Szyprowski wrote:
> > Does it fail in the same way?
>
> Yes, the hw revision is reported as zero in this case: LT9611 revision:
> 0x
Hi
Am 20.01.25 um 11:37 schrieb Jocelyn Falempe:
On 17/01/2025 11:29, Thomas Zimmermann wrote:
Only Gen4 and later read the installed TX chip from the SoC. So only
warn on those generations about unsupported chips.
Thanks, it looks good to me.
Reviewed-by: Jocelyn Falempe
Thanks for revi
On 1/21/25 07:42, oushixiong1...@163.com wrote:
From: Shixiong Ou
Signed-off-by: Shixiong Ou
---
drivers/video/fbdev/sh_mobile_lcdcfb.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
That patch did not apply any longer to git head.
I fixed it up manually and applied it to fbde
Hello,
while working on something completely different, I stumbled over this
linker problem, during final linking of the kernel.
- ARCH=arm64
- linux: v6.13
- gcc version 12.2.0 (Debian 12.2.0-14)
- GNU ld (GNU Binutils for Debian) 2.40
- .config is attached
| aarch64-linux-gnu-ld: Unexpected GO
On Tue, 21 Jan 2025, Atharva Tiwari wrote:
> 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
See [1], [2], and [3].
Please ad
On Tue, Jan 21, 2025 at 12:27:18PM +0100, Luca Ceresoli wrote:
> Hi Dmitry,
>
> On Thu, 16 Jan 2025 12:56:25 +0200
> Dmitry Baryshkov wrote:
>
> [...]
>
> > > Idea 3:
> > >
> > > The idea is that if the panel driver framework always creates a panel
> > > bridge, it will never need to be creat
Hi Maxime,
On Thu, 16 Jan 2025 13:26:25 +0100
Maxime Ripard wrote:
[...]
> > And then there is the panel bridge. My understanding (which I'd love to
> > get clarified in case it is not accurate) is that DRM bridges expect to
> > always interact with "the next bridge", which cannot work for the
Hi Dmitry,
On Thu, 16 Jan 2025 12:56:25 +0200
Dmitry Baryshkov wrote:
[...]
> > Idea 3:
> >
> > The idea is that if the panel driver framework always creates a panel
> > bridge, it will never need to be created on the fly automagically by
> > its consumers, so the whole problem would disappea
On Tue, Jan 21, 2025 at 12:10:25PM +0100, Geert Uytterhoeven wrote:
> Hi Dmitry,
>
> CC sfr
>
> On Tue, Jan 21, 2025 at 11:44 AM Dmitry Baryshkov
> wrote:
> > On Tue, 21 Jan 2025 at 11:13, Geert Uytterhoeven
> > wrote:
> > > On Tue, Jan 7, 2025 at 12:31 PM Dmitry Baryshkov
> > > wrote:
> > >
Hi Dmitry,
CC sfr
On Tue, Jan 21, 2025 at 11:44 AM Dmitry Baryshkov
wrote:
> On Tue, 21 Jan 2025 at 11:13, Geert Uytterhoeven wrote:
> > On Tue, Jan 7, 2025 at 12:31 PM Dmitry Baryshkov
> > wrote:
> > > On Sat, 14 Dec 2024 15:37:04 +0200, Dmitry Baryshkov wrote:
> > > > While working on the ge
To allow emulation of different kind of encoders, make the encoder type
configurable.
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_config.c | 1 +
drivers/gpu/drm/vkms/vkms_config.h | 2 ++
drivers/gpu/drm/vkms/vkms_output.c | 2 +-
3 files changed, 4 insertions(+), 1 deletion(-)
VKMS driver supports all the pixel formats for planes, but for testing it
can be useful to only advertise few of them. This new configuration
interface will allow configuring the pixel format per planes.
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_config.c | 75 +++
VKMS driver does not currently support connector hotpluging. Add
an option to change the connector status once a device is created.
Signed-off-by: José Expósito
[adpated it for my implementation]
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_config.c | 10 ++
drivers/gpu/dr
To allow emulation of different kind of connector, make the connector type
configurable.
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_config.c | 1 +
drivers/gpu/drm/vkms/vkms_config.h | 1 +
drivers/gpu/drm/vkms/vkms_output.c | 2 +-
3 files changed, 3 insertions(+), 1 deletion(-)
The current vkms driver only allows the usage of one connector,
possibly with a writeback connector. This new configuration structure aims
to make the configuration more flexible.
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_config.c | 62 +-
dri
1 - 100 of 166 matches
Mail list logo
