Am 30.01.24 um 04:04 schrieb Matthew Brost:
Rather then loop over entities until one with a ready job is found,
re-queue the run job worker when drm_sched_entity_pop_job() returns NULL.
Fixes: 6dbd9004a55 ("drm/sched: Drain all entities in DRM sched run job worker")
Signed-off-by: Matthew Brost
Hi,
[for this reply dropping the Debian bugreport to avoid later followups
sending the ack to the mailinglist and adding noise]
On Sun, Jan 28, 2024 at 11:44:59AM +0100, Linux regression tracking (Thorsten
Leemhuis) wrote:
> On 27.01.24 14:14, Salvatore Bonaccorso wrote:
> >
> > In Debian
Hi Conor,
On 24/01/24 10:10 pm, Conor Dooley wrote:
> On Wed, Jan 24, 2024 at 03:30:16PM +0530, Dharma Balasubiramani wrote:
>> Converted the text bindings to YAML and validated them individually using
>> following commands
>>
>> $ make dt_binding_check
Hi Andrew,
>
> On 1/26/24 1:25 AM, Kasireddy, Vivek wrote:
> Currently this driver creates a SGT table using the CPU as the
> target device, then performs the dma_sync operations against
> that SGT. This is backwards to how DMA-BUFs are supposed to behave.
> This may have
On 1/29/2024 9:28 PM, Dmitry Baryshkov wrote:
On Tue, 30 Jan 2024 at 06:10, Abhinav Kumar wrote:
On 1/29/2024 5:43 PM, Dmitry Baryshkov wrote:
On Tue, 30 Jan 2024 at 03:07, Abhinav Kumar wrote:
On 1/29/2024 4:03 PM, Dmitry Baryshkov wrote:
On Tue, 30 Jan 2024 at 01:51, Abhinav
On Tue, 30 Jan 2024 at 06:10, Abhinav Kumar wrote:
>
>
>
> On 1/29/2024 5:43 PM, Dmitry Baryshkov wrote:
> > On Tue, 30 Jan 2024 at 03:07, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 1/29/2024 4:03 PM, Dmitry Baryshkov wrote:
> >>> On Tue, 30 Jan 2024 at 01:51, Abhinav Kumar
> >>> wrote:
On 1/29/2024 5:43 PM, Dmitry Baryshkov wrote:
On Tue, 30 Jan 2024 at 03:07, Abhinav Kumar wrote:
On 1/29/2024 4:03 PM, Dmitry Baryshkov wrote:
On Tue, 30 Jan 2024 at 01:51, Abhinav Kumar wrote:
On 1/27/2024 9:33 PM, Dmitry Baryshkov wrote:
On Sun, 28 Jan 2024 at 07:16, Paloma
Hi Chunming,
In this email thread, Christian mentioned a very special virtualization
environment where multiple guess processes relies on a host proxy process to
talk to kfd. Such setup has a hard confliction with SVM concept as SVM means
shared virtual address space in *one* process while the
On 1/28/24 19:30, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20240125:
>
> New trees: i2c-host-fixes, i2c-host
>
on riscv 64-bit or powerpc 64-bit:
WARNING: unmet direct dependencies detected for FB_IOMEM_HELPERS
Depends on [n]: HAS_IOMEM [=y] && FB_CORE [=n]
Selected by [m]:
Hi Felix,
Following your thread, you mentioned many times that SVM API cannot run in
virtualization env, I still don't get it why.
Why you often said need a host proxy process? Cannot HW report page fault
interrupt per VF via vfid? Isn't it sriov env?
Regargs,
-Chunming
From: Dave Airlie
Timur pointed this out before, and it just slipped my mind,
but this might help some things work better, around pcie power
management.
Fixes: 8d55b0a940bb ("nouveau/gsp: add some basic registry entries.")
Signed-off-by: Dave Airlie
---
Rather then loop over entities until one with a ready job is found,
re-queue the run job worker when drm_sched_entity_pop_job() returns NULL.
Fixes: 6dbd9004a55 ("drm/sched: Drain all entities in DRM sched run job worker")
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/scheduler/sched_main.c
On Fri, Jan 26, 2024 at 06:30:02PM +0100, Thomas Gleixner wrote:
> On Wed, Jan 24 2024 at 20:59, Byungchul Park wrote:
>
> Why is lockdep in the subsystem prefix here? You are changing the CPU
> hotplug (not hotplus) code, right?
>
> > cb92173d1f0 ("locking/lockdep, cpu/hotplug: Annotate AP
Hi all,
After merging the amdgpu tree, today's linux-next build (htmldocs)
produced this warning:
drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_dio.h:1: warning: no
structured comments found
drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_dio.h:1: warning: no
structured comments found
Hi all,
After merging the amdgpu tree, today's linux-next build (htmldocs)
produced this warning:
drivers/gpu/drm/amd/display/dc/inc/hw/opp.h:1: warning: no structured comments
found
drivers/gpu/drm/amd/display/dc/inc/hw/opp.h:1: warning: no structured comments
found
Introduced by commit
Hi all,
After merging the amdgpu tree, today's linux-next build (htmldocs)
produced these warnings:
drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:132: warning: Incorrect use of
kernel-doc format: * @@overlap_only: Whether overlapping of different
planes is allowed.
On Tue, 30 Jan 2024 at 03:07, Abhinav Kumar wrote:
>
>
>
> On 1/29/2024 4:03 PM, Dmitry Baryshkov wrote:
> > On Tue, 30 Jan 2024 at 01:51, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 1/27/2024 9:33 PM, Dmitry Baryshkov wrote:
> >>> On Sun, 28 Jan 2024 at 07:16, Paloma Arellano
> >>>
Serial is Reviewed-by: QIang Yu
On Wed, Jan 24, 2024 at 11:00 AM Erico Nunes wrote:
>
> v1 reference:
> https://patchwork.kernel.org/project/dri-devel/cover/20240117031212.1104034-1-nunes.er...@gmail.com/
>
> Changes v1 -> v2:
> - Dropped patch 1 which aimed to fix
>
On 1/29/2024 4:03 PM, Dmitry Baryshkov wrote:
On Tue, 30 Jan 2024 at 01:51, Abhinav Kumar wrote:
On 1/27/2024 9:33 PM, Dmitry Baryshkov wrote:
On Sun, 28 Jan 2024 at 07:16, Paloma Arellano wrote:
On 1/25/2024 1:26 PM, Dmitry Baryshkov wrote:
On 25/01/2024 21:38, Paloma Arellano
On Tue, Jan 30, 2024 at 6:55 AM Erico Nunes wrote:
>
> On Wed, Jan 24, 2024 at 1:38 PM Qiang Yu wrote:
> >
> > On Wed, Jan 24, 2024 at 11:00 AM Erico Nunes wrote:
> > >
> > > There are several unexplained and unreproduced cases of rendering
> > > timeouts with lima, for which one theory is high
On 1/27/2024 9:33 PM, Dmitry Baryshkov wrote:
On Sun, 28 Jan 2024 at 07:16, Paloma Arellano wrote:
On 1/25/2024 1:26 PM, Dmitry Baryshkov wrote:
On 25/01/2024 21:38, Paloma Arellano wrote:
INTF_CONFIG2 register cannot have widebus enabled when DP format is
YUV420. Therefore, program the
On Tue, 30 Jan 2024 at 01:51, Abhinav Kumar wrote:
>
>
>
> On 1/27/2024 9:33 PM, Dmitry Baryshkov wrote:
> > On Sun, 28 Jan 2024 at 07:16, Paloma Arellano
> > wrote:
> >>
> >>
> >> On 1/25/2024 1:26 PM, Dmitry Baryshkov wrote:
> >>> On 25/01/2024 21:38, Paloma Arellano wrote:
>
The example you used to prove that KFD is a design failure, is against *any*
design which utilize system allocator and hmm. The way that one proxy process
running on host to handle many guest processes, doesn’t fit into the concept of
“share address space b/t cpu and gpu”. The shared address
On Mon, 29 Jan 2024 at 09:08, Abhinav Kumar wrote:
>
> On 1/28/2024 10:12 PM, Dmitry Baryshkov wrote:
> > On Mon, 29 Jan 2024 at 07:03, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 1/28/2024 7:42 PM, Dmitry Baryshkov wrote:
> >>> On Mon, 29 Jan 2024 at 04:58, Abhinav Kumar
> >>> wrote:
>
On 1/26/2024 6:40 PM, Dmitry Baryshkov wrote:
On Sat, 27 Jan 2024 at 02:58, Paloma Arellano wrote:
On 1/25/2024 1:23 PM, Dmitry Baryshkov wrote:
On 25/01/2024 21:38, Paloma Arellano wrote:
YUV420 format is supported only in the VSC SDP packet and not through
MSA. Hence add an API which
On 1/28/2024 9:12 PM, Dmitry Baryshkov wrote:
On Mon, 29 Jan 2024 at 06:33, Abhinav Kumar wrote:
On 1/28/2024 8:12 PM, Dmitry Baryshkov wrote:
On Mon, 29 Jan 2024 at 06:01, Abhinav Kumar wrote:
On 1/28/2024 7:23 PM, Dmitry Baryshkov wrote:
On Mon, 29 Jan 2024 at 05:06, Abhinav Kumar
On Wed, Jan 24, 2024 at 1:38 PM Qiang Yu wrote:
>
> On Wed, Jan 24, 2024 at 11:00 AM Erico Nunes wrote:
> >
> > There are several unexplained and unreproduced cases of rendering
> > timeouts with lima, for which one theory is high IRQ latency coming from
> > somewhere else in the system.
> >
ding_check] Error 2
make: *** [Makefile:240: __sub-make] Error 2
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240129-x1e80100-display-v1-1-0d9eb8254...@linaro.org
The base for the series is generally the latest rc1. A different de
Hi Thomas,
My patch was based on drm-tip because I found drm-tip is broken
As long as drm-tip can build, I am all good.
Thanks,
Oak
> -Original Message-
> From: Thomas Hellström
> Sent: Monday, January 29, 2024 3:26 PM
> To: Christian König ; Zeng, Oak
> ;
Hi,
On 1/29/24 17:48, Christian König wrote:
Am 27.01.24 um 16:53 schrieb Oak Zeng:
This fixes a build failure on drm-tip. This issue was introduced during
merge of "drm/ttm: replace busy placement with flags v6". For some
reason, the xe_bo.c part of above change is not merged. Manually merge
On 2024-01-29 14:03, Christian König wrote:
Am 29.01.24 um 18:52 schrieb Felix Kuehling:
On 2024-01-29 11:28, Christian König wrote:
Am 29.01.24 um 17:24 schrieb Felix Kuehling:
On 2024-01-29 10:33, Christian König wrote:
Am 29.01.24 um 16:03 schrieb Felix Kuehling:
On 2024-01-25 13:32,
Hi Christian,
Even though this email thread was started to discuss shared virtual address
space b/t multiple GPU devices, I eventually found you even don’t agree with a
shared virtual address space b/t CPU and GPU program. So let’s forget about
multiple GPU devices for now. I will try explain
LGTM.
Reviewed-by: Ian Forbes
Hi Maxime
On 1/26/2024 4:45 AM, Maxime Ripard wrote:
On Wed, Jan 17, 2024 at 09:36:20AM -0800, Abhinav Kumar wrote:
Hi Jani and Maxime
On 1/17/2024 2:16 AM, Jani Nikula wrote:
On Wed, 17 Jan 2024, Maxime Ripard wrote:
Hi,
On Tue, Jan 16, 2024 at 02:22:03PM -0800, Jessica Zhang wrote:
Am 29.01.24 um 18:52 schrieb Felix Kuehling:
On 2024-01-29 11:28, Christian König wrote:
Am 29.01.24 um 17:24 schrieb Felix Kuehling:
On 2024-01-29 10:33, Christian König wrote:
Am 29.01.24 um 16:03 schrieb Felix Kuehling:
On 2024-01-25 13:32, Daniel Vetter wrote:
On Wed, Jan 24, 2024 at
On Mon, Jan 29, 2024 at 12:10:52PM -0500, Luben Tuikov wrote:
> On 2024-01-29 02:44, Christian König wrote:
> > Am 26.01.24 um 17:29 schrieb Matthew Brost:
> >> On Fri, Jan 26, 2024 at 11:32:57AM +0100, Christian König wrote:
> >>> Am 25.01.24 um 18:30 schrieb Matthew Brost:
> On Thu, Jan 25,
On 2024-01-29 11:28, Christian König wrote:
Am 29.01.24 um 17:24 schrieb Felix Kuehling:
On 2024-01-29 10:33, Christian König wrote:
Am 29.01.24 um 16:03 schrieb Felix Kuehling:
On 2024-01-25 13:32, Daniel Vetter wrote:
On Wed, Jan 24, 2024 at 09:33:12AM +0100, Christian König wrote:
Am
6.6-stable review patch. If anyone has any objections, please let me know.
--
From: Zack Rusin
commit 4e3b70da64a53784683cfcbac2deda5d6e540407 upstream.
Cursor planes on virtualized drivers have special meaning and require
that the clients handle them in specific ways, e.g.
6.6-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Zimmermann
commit 9cf5ca1f485cae406968947a92bf304603999fa1 upstream.
Non-KMS drivers have been removed from DRM. Update the TODO list
accordingly.
Signed-off-by: Thomas Zimmermann
On Mon, Jan 29, 2024 at 03:41:22AM +, dharm...@microchip.com wrote:
> I will proceed with updating the clock names to include "lvds pll" and
> adjusting the clocks minitems to 3. Does this seem appropriate to you?
>
> Please let me know if there are any additional considerations or
>
On 2024-01-29 02:44, Christian König wrote:
> Am 26.01.24 um 17:29 schrieb Matthew Brost:
>> On Fri, Jan 26, 2024 at 11:32:57AM +0100, Christian König wrote:
>>> Am 25.01.24 um 18:30 schrieb Matthew Brost:
On Thu, Jan 25, 2024 at 04:12:58PM +0100, Christian König wrote:
> Am 24.01.24 um
6.7-stable review patch. If anyone has any objections, please let me know.
--
From: Zack Rusin
commit 4e3b70da64a53784683cfcbac2deda5d6e540407 upstream.
Cursor planes on virtualized drivers have special meaning and require
that the clients handle them in specific ways, e.g.
6.7-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Zimmermann
commit 9cf5ca1f485cae406968947a92bf304603999fa1 upstream.
Non-KMS drivers have been removed from DRM. Update the TODO list
accordingly.
Signed-off-by: Thomas Zimmermann
Document the new DMABUF based API.
Signed-off-by: Paul Cercueil
---
v2: - Explicitly state that the new interface is optional and is
not implemented by all drivers.
- The IOCTLs can now only be called on the buffer FD returned by
IIO_BUFFER_GET_FD_IOCTL.
- Move the page up a
Implement iio_dma_buffer_attach_dmabuf(), iio_dma_buffer_detach_dmabuf()
and iio_dma_buffer_transfer_dmabuf(), which can then be used by the IIO
DMA buffer implementations.
Signed-off-by: Paul Cercueil
---
v3: Update code to provide the functions that will be used as callbacks
for the new
Use the functions provided by the buffer-dma core to implement the
DMABUF userspace API in the buffer-dmaengine IIO buffer implementation.
Since we want to be able to transfer an arbitrary number of bytes and
not necesarily the full DMABUF, the associated scatterlist is converted
to an array of
Add the necessary infrastructure to the IIO core to support a new
optional DMABUF based interface.
With this new interface, DMABUF objects (externally created) can be
attached to a IIO buffer, and subsequently used for data transfer.
A userspace application can then use this interface to share
This function can be used to initiate a scatter-gather DMA transfer,
where the address and size of each segment is located in one entry of
the dma_vec array.
The major difference with dmaengine_prep_slave_sg() is that it supports
specifying the lengths of each DMA transfer; as trying to override
Add implementation of the .device_prep_slave_dma_vec() callback.
Signed-off-by: Paul Cercueil
---
v3: New patch
v5: Implement .device_prep_slave_dma_vec() instead of v3's
.device_prep_slave_dma_array().
v6: Use new prototype for axi_dmac_alloc_desc() as it changed upstream.
---
will gladly send a follow-up patch to use __free() where it
makes sense.
For performance numbers, I'll point you to the cover letter for my v5
patchset [2].
This patchset was based on next-20240129.
Cheers,
-Paul
[1] https://lore.kernel.org/all/20230322092118.9213-1-p...@crapouillou.net/
[2
On 1/29/2024 10:46, Jani Nikula wrote:
On Mon, 29 Jan 2024, Mario Limonciello wrote:
On 1/29/2024 03:39, Jani Nikula wrote:
On Fri, 26 Jan 2024, Mario Limonciello wrote:
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index
On 29.01.24 10:20, Frieder Schrempf wrote:
> On 26.01.24 19:28, Dave Airlie wrote:
>> Just FYI this conflictted pretty heavily with drm-misc-next changes in
>> the same area, someone should check drm-tip has the correct
>> resolution, I'm not really sure what is definitely should be.
>>
>> Dave.
>
Am 27.01.24 um 16:53 schrieb Oak Zeng:
This fixes a build failure on drm-tip. This issue was introduced during
merge of "drm/ttm: replace busy placement with flags v6". For some
reason, the xe_bo.c part of above change is not merged. Manually merge
the missing part to drm_tip
Mhm, I provided
On Mon, 29 Jan 2024, Mario Limonciello wrote:
> On 1/29/2024 03:39, Jani Nikula wrote:
>> On Fri, 26 Jan 2024, Mario Limonciello wrote:
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
>>> index 9caba10315a8..c7e1563a46d3
Am 29.01.24 um 17:24 schrieb Felix Kuehling:
On 2024-01-29 10:33, Christian König wrote:
Am 29.01.24 um 16:03 schrieb Felix Kuehling:
On 2024-01-25 13:32, Daniel Vetter wrote:
On Wed, Jan 24, 2024 at 09:33:12AM +0100, Christian König wrote:
Am 23.01.24 um 20:37 schrieb Zeng, Oak:
[SNIP]
Yes
On 2024-01-29 10:33, Christian König wrote:
Am 29.01.24 um 16:03 schrieb Felix Kuehling:
On 2024-01-25 13:32, Daniel Vetter wrote:
On Wed, Jan 24, 2024 at 09:33:12AM +0100, Christian König wrote:
Am 23.01.24 um 20:37 schrieb Zeng, Oak:
[SNIP]
Yes most API are per device based.
One
On 1/29/2024 07:54, Rafael J. Wysocki wrote:
On Fri, Jan 26, 2024 at 7:55 PM Mario Limonciello
wrote:
The ACPI specification allows for an EDID to be up to 512 bytes but
the _DDC EDID fetching code will only try up to 256 bytes.
Modify the code to instead start at 512 bytes and work it's way
On 1/29/2024 03:39, Jani Nikula wrote:
On Fri, 26 Jan 2024, Mario Limonciello wrote:
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops.
Attempt to fetch this EDID if it exists and prefer it over the EDID
that is provided by the
Just FYI this conflictted pretty heavily with drm-misc-next changes in
the same area, someone should check drm-tip has the correct
resolution, I'm not really sure what is definitely should be.
FWIW, this looks rather messy now. The drm-tip doesn't build.
There was a new call to
Am 29.01.24 um 16:03 schrieb Felix Kuehling:
On 2024-01-25 13:32, Daniel Vetter wrote:
On Wed, Jan 24, 2024 at 09:33:12AM +0100, Christian König wrote:
Am 23.01.24 um 20:37 schrieb Zeng, Oak:
[SNIP]
Yes most API are per device based.
One exception I know is actually the kfd SVM API. If you
That we include so many C files with relative paths seems to be odd.
Apart from that looks good to me.
Christian.
Am 26.01.24 um 16:48 schrieb Rodrigo Siqueira:
In 2022, we got a great patchset from a GSoC project introducing unit
tests to the amdgpu display. Since version 3, this effort was
On Mon, 29 Jan 2024 at 15:19, Abel Vesa wrote:
>
> Add definitions for the display hardware used on the Qualcomm X1E80100
> platform.
>
> Co-developed-by: Abhinav Kumar
> Signed-off-by: Abhinav Kumar
> Signed-off-by: Abel Vesa
> ---
> .../drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h | 449
On Mon, 29 Jan 2024 at 15:19, Abel Vesa wrote:
>
> Add support for MDSS on X1E80100.
>
> Signed-off-by: Abel Vesa
> ---
> drivers/gpu/drm/msm/msm_mdss.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
> index
On Mon, Jan 29, 2024 at 08:49:35AM -0600, Lucas De Marchi wrote:
> On Wed, Jan 24, 2024 at 07:27:58AM -0800, Yury Norov wrote:
> > On Wed, Jan 24, 2024 at 08:03:53AM -0600, Lucas De Marchi wrote:
> > > On Wed, Jan 24, 2024 at 09:58:26AM +0200, Jani Nikula wrote:
> > > > On Tue, 23 Jan 2024, Lucas
On Mon, 29 Jan 2024 at 15:19, Abel Vesa wrote:
>
> From: Abhinav Kumar
>
> On platforms where the endpoint used is on port@0, looking for port@1
> instead results in just ignoring the max link-frequencies altogether.
> Look at port@0 first, then, if not found, look for port@1.
NAK. Platforms do
On 2024-01-25 13:32, Daniel Vetter wrote:
On Wed, Jan 24, 2024 at 09:33:12AM +0100, Christian König wrote:
Am 23.01.24 um 20:37 schrieb Zeng, Oak:
[SNIP]
Yes most API are per device based.
One exception I know is actually the kfd SVM API. If you look at the svm_ioctl
function, it is
On Wed, Jan 24, 2024 at 07:27:58AM -0800, Yury Norov wrote:
On Wed, Jan 24, 2024 at 08:03:53AM -0600, Lucas De Marchi wrote:
On Wed, Jan 24, 2024 at 09:58:26AM +0200, Jani Nikula wrote:
> On Tue, 23 Jan 2024, Lucas De Marchi wrote:
> > From: Yury Norov
> >
> > Generalize __GENMASK() to
Le lundi 29 janvier 2024 à 14:32 +0100, Paul Cercueil a écrit :
> Le lundi 29 janvier 2024 à 14:17 +0100, Christian König a écrit :
> > Am 29.01.24 um 14:06 schrieb Paul Cercueil:
> > > Hi Christian,
> > >
> > > Le lundi 29 janvier 2024 à 13:52 +0100, Christian König a écrit :
> > > > Am 27.01.24
On Fri, Jan 26, 2024 at 7:55 PM Mario Limonciello
wrote:
>
> The ACPI specification allows for an EDID to be up to 512 bytes but
> the _DDC EDID fetching code will only try up to 256 bytes.
>
> Modify the code to instead start at 512 bytes and work it's way
> down instead.
>
> Link:
>
Le lundi 29 janvier 2024 à 14:17 +0100, Christian König a écrit :
> Am 29.01.24 um 14:06 schrieb Paul Cercueil:
> > Hi Christian,
> >
> > Le lundi 29 janvier 2024 à 13:52 +0100, Christian König a écrit :
> > > Am 27.01.24 um 17:50 schrieb Jonathan Cameron:
> > > > > > > +
Hi Werner,
On 1/19/24 17:04, Werner Sembach wrote:
> Am 19.01.24 um 09:44 schrieb Hans de Goede:
>> So my proposal would be an ioctl interface (ioctl only no r/w)
>> using /dev/rgbkbd0 /dev/rgbkdb1, etc. registered as a misc chardev.
>>
>> For per key controllable rgb LEDs we need to discuss a
Hi,
On 1/19/24 21:15, Pavel Machek wrote:
> Hi!
>
2. Implement per-key keyboards as auxdisplay
- Pro:
- Already has a concept for led positions
- Is conceptually closer to "multiple leds forming a singular
entity"
- Con:
From: Abhinav Kumar
On platforms where the endpoint used is on port@0, looking for port@1
instead results in just ignoring the max link-frequencies altogether.
Look at port@0 first, then, if not found, look for port@1.
Signed-off-by: Abhinav Kumar
Signed-off-by: Abel Vesa
---
Add support for MDSS on X1E80100.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/msm_mdss.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 455b2e3a0cdd..eddf7fdbb60a 100644
---
Add definitions for the display hardware used on the Qualcomm X1E80100
platform.
Co-developed-by: Abhinav Kumar
Signed-off-by: Abhinav Kumar
Signed-off-by: Abel Vesa
---
.../drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h | 449 +
Document the DPU for Qualcomm X1E80100 platform in the SM8650 schema, as
they are similar.
Signed-off-by: Abel Vesa
---
Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
Document the MDSS hardware found on the Qualcomm X1E80100 platform.
Signed-off-by: Abel Vesa
---
.../bindings/display/msm/qcom,x1e80100-mdss.yaml | 249 +
1 file changed, 249 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.yaml
This patchset adds support for display for X1E80100.
The support for embedded DisplayPort on this platform will not
be enabled using the connetor type from driver match data,
but through some 'is-edp' property via DT. This subsequent work
will be part of a separate patchset.
Signed-off-by: Abel
Am 29.01.24 um 14:06 schrieb Paul Cercueil:
Hi Christian,
Le lundi 29 janvier 2024 à 13:52 +0100, Christian König a écrit :
Am 27.01.24 um 17:50 schrieb Jonathan Cameron:
+ iio_buffer_dmabuf_put(attach);
+
+out_dmabuf_put:
+ dma_buf_put(dmabuf);
As below. Feels like a
Am 29.01.24 um 11:31 schrieb Julia Zhang:
As vram objects don't have backing pages and thus can't implement
drm_gem_object_funcs.get_sg_table callback. This removes drm dma-buf
callbacks in virtgpu_gem_map_dma_buf()/virtgpu_gem_unmap_dma_buf()
and implement virtgpu specific map/unmap/attach
Hi,
On Mon, 2024-01-29 at 12:15 +0100, Hans de Goede wrote:
> Hi Philipp,
>
> On 1/23/24 10:43, Philipp Stanner wrote:
> > When the PCI devres API was introduced to this driver, it was
> > wrongly
> > assumed that initializing the device with pcim_enable_device()
> > instead
> > of
Hi Christian,
Le lundi 29 janvier 2024 à 13:52 +0100, Christian König a écrit :
> Am 27.01.24 um 17:50 schrieb Jonathan Cameron:
> > > > > + iio_buffer_dmabuf_put(attach);
> > > > > +
> > > > > +out_dmabuf_put:
> > > > > + dma_buf_put(dmabuf);
> > > > As below. Feels like a
Am 27.01.24 um 17:50 schrieb Jonathan Cameron:
+ iio_buffer_dmabuf_put(attach);
+
+out_dmabuf_put:
+ dma_buf_put(dmabuf);
As below. Feels like a __free(dma_buf_put) bit of magic would be a
nice to have.
I'm working on the patches right now, just one quick question.
Having a
of_property_read_u32 returns 0 when success, so reverse the
return value to get the true value.
Fixes: f8449c8f7355 ("backlight: ktz8866: Add support for Kinetic KTZ8866
backlight")
Signed-off-by: Jianhua Lu
---
drivers/video/backlight/ktz8866.c | 6 +++---
1 file changed, 3 insertions(+), 3
Am 26.01.24 um 18:24 schrieb Andrew Davis:
On 1/25/24 2:30 PM, Daniel Vetter wrote:
On Tue, Jan 23, 2024 at 04:12:26PM -0600, Andrew Davis wrote:
Currently this driver creates a SGT table using the CPU as the
target device, then performs the dma_sync operations against
that SGT. This is
Thomas Zimmermann writes:
> If the firmware framebuffer has been reloacted, the sysfb code
> fixes the screen_info state before it creates the framebuffer's
> platform device. Efifb will automatically receive a screen_info
> with updated values. Hence remove the tracking from efifb.
>
>
Javier Martinez Canillas writes:
> Thomas Zimmermann writes:
>
>> On ARM PCI systems, the PCI hierarchy might be reconfigured during
>> boot and the firmware framebuffer might move as a result of that.
>> The values in screen_info will then be invalid.
>>
>> Work around this problem by tracking
Thomas Zimmermann writes:
> On ARM PCI systems, the PCI hierarchy might be reconfigured during
> boot and the firmware framebuffer might move as a result of that.
> The values in screen_info will then be invalid.
>
> Work around this problem by tracking the framebuffer's initial
> location
Thomas Zimmermann writes:
> There will be no EFI framebuffer device for disabled parent devices
> and thus we never probe efifb in that case. Hence remove the tracking
> code from efifb.
>
> Signed-off-by: Thomas Zimmermann
> ---
Nice cleanup.
Reviewed-by: Javier Martinez Canillas
--
Best
Thomas Zimmermann writes:
> Test if the firmware framebuffer's parent PCI device, if any, has
> been enabled. If not, the firmware framebuffer is most likely not
> working. Hence, do not create a device for the firmware framebuffer
> on disabled PCI devices.
>
> So far, efifb tracked the status
Thomas Zimmermann writes:
> The EFI device has the correct parent device set. This allows Linux
> to handle the power management internally. Hence, remove the manual
> PM management for the parent device from efifb.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez
Thomas Zimmermann writes:
> Set the firmware framebuffer's parent device, which usually is the
> graphics hardware's physical device. Integrates the framebuffer in
> the Linux device hierarchy and lets Linux handle dependencies among
> devices. For example, the graphics hardware won't be
Hi Philipp,
On 1/23/24 10:43, Philipp Stanner wrote:
> When the PCI devres API was introduced to this driver, it was wrongly
> assumed that initializing the device with pcim_enable_device() instead
> of pci_enable_device() will make all PCI functions managed.
>
> This is wrong and was caused by
Thomas Zimmermann writes:
> Add screen_info_get_pci_dev() to find the PCI device of an instance
> of screen_info. Does nothing on systems without PCI bus.
>
> Signed-off-by: Thomas Zimmermann
> ---
[...]
> +struct pci_dev *screen_info_pci_dev(const struct screen_info *si)
> +{
> + struct
Hi Nirmoy,
On Monday, 29 January 2024 10:24:07 CET Nirmoy Das wrote:
> Hi Janusz,
>
> There seems to be a regression in CI related to this:
>
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129026v2/bat-dg1-7/
igt@gem_lmem_swapping@random-engi...@lmem0.html#dmesg-warnings1053
>
> Please
On Fri, 2024-01-26 at 16:22 -0600, Lucas De Marchi wrote:
> On Fri, Jan 26, 2024 at 04:16:58PM -0600, Lucas De Marchi wrote:
> > On Thu, Jan 18, 2024 at 05:38:16PM +0100, Thomas Hellström wrote:
> > >
> > > On 1/17/24 13:27, Thomas Hellström wrote:
> > > >
> > > > On 1/17/24 11:47, Thomas
On Mon, Jan 29, 2024 at 12:36:12PM +0200, Hogander, Jouni wrote:
> On Tue, 2024-01-23 at 12:28 +0200, Imre Deak wrote:
> > [...]
> > +void
> > +intel_dp_queue_modeset_retry_for_link(struct intel_atomic_state *state,
> > + struct intel_encoder *encoder,
> > +
On Mon, 29 Jan 2024 17:20:47 +0800 (CST)
"Andy Yan" wrote:
> Hi Boris：
>
> Thanks for you great work。
>
> One thing please take note：
> commit (arm64: dts: rockchip: rk3588: Add GPU nodes) in [1] seems remove the
> "disabled" status
> of usb_host2_xhci, this may cause a boot issue on some
This patch series aims to add several features of the dw-mipi-dsi phy
driver that are missing or need to be updated.
First patch update a PM macro.
Second patch adds runtime PM functionality to the driver.
Third patch adds a clock provider generated by the PHY itself. As
explained in the
DSISRC __
__\_
|\
pll4_p_ck ->| 1 |dsi_k
ck_dsi_phy ->| 0 |
|/
A DSI clock is missing in the clock framework. Looking at the
clk_summary, it appears that 'ck_dsi_phy' is not
1 - 100 of 140 matches
Mail list logo
