On Sat, 30 Mar 2024 at 04:39, Abhinav Kumar wrote:
>
>
>
> On 3/26/2024 2:23 PM, Miguel Ojeda wrote:
> > Clang 14 in an (essentially) defconfig arm64 build for next-20240326
> > reports [1]:
> >
> > drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:843:6: error:
> > variable 'out' set but not
Hi Krzysztof,
> -Original Message-
> From: Krzysztof Kozlowski
> Sent: Sunday, March 31, 2024 5:33 AM
> To: Inki Dae ; Seung-Woo Kim
> ; Kyungmin Park ; David
> Airlie ; Daniel Vetter ; Krzysztof
> Kozlowski ; Alim Akhtar
>
> Cc: dri-devel@lists.freedesktop.org;
On 05/04/24 03:55, Rodrigo Vivi wrote:
> On Tue, Apr 02, 2024 at 02:28:55PM +0530, Aravind Iddamsetty wrote:
>> PCI subsystem provides callbacks to inform the driver about a request to
>> do function level reset by user, initiated by writing to sysfs entry
>> /sys/bus/pci/devices/.../reset. This
Enable LVDS serializer support for display pipeline.
Signed-off-by: Dharma Balasubiramani
Acked-by: Hari Prasath Gujulan Elango
Acked-by: Nicolas Ferre
---
Changelog
v4 -> v5
v3 -> v4
v2 -> v3
- No Changes.
---
arch/arm/configs/at91_dt_defconfig | 1 +
1 file changed, 1 insertion(+)
diff
On Thu, Apr 04, 2024 at 07:14:48PM +0100, Alex Constantino wrote:
> This reverts commit 5a838e5d5825c85556011478abde708251cc0776.
>
> Changes from commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") would
> result in a '[TTM] Buffer eviction failed' exception whenever it reached a
> timeout.
Add the newly added LVDS controller for the SAM9X7 SoC to the existing
MAINTAINERS entry.
Signed-off-by: Dharma Balasubiramani
Reviewed-by: Neil Armstrong
Acked-by: Nicolas Ferre
---
Changelog
v4 -> v5
v3 -> v4
- No changes.
v2 -> v3
- Move the entry before "MICROCHIP SAMA5D2-COMPATIBLE ADC
Add the 'sam9x75-lvds' compatible binding, which describes the Low Voltage
Differential Signaling (LVDS) Controller found on some Microchip's sam9x7
series System-on-Chip (SoC) devices. This binding will be used to define
the properties and configuration for the LVDS Controller in DT.
Add a new LVDS controller driver for sam9x7 which does the following:
- Prepares and enables the LVDS Peripheral clock
- Defines its connector type as DRM_MODE_CONNECTOR_LVDS and adds itself
to the global bridge list.
- Identifies its output endpoint as panel and adds it to the encoder
display
This patch series introduces LVDS controller support for the SAM9X75 SoC. The
LVDS controller is designed to work with Microchip's sam9x7 series
System-on-Chip (SoC) devices, providing Low Voltage Differential Signaling
capabilities.
Patch series Changelog:
- Include configs: at91: Enable LVDS
Hi Linus,
Weekly fixes, mostly xe and i915, amdgpu on a week off, otherwise a
nouveau fix for a crash with new vulkan cts tests, and a couple of
cleanups and misc fixes.
Dave.
drm-fixes-2024-04-05:
drm fixes for v6.9-rc3
display:
- fix typos in kerneldoc
prime:
- unbreak dma-buf export for
On Thu, Apr 04, 2024 at 11:33:29PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Remove the tall tale about fastboot vs. user mode vs.
> adjusted mode. crtc->mode == crtc->state->mode, so none
> of this makes any sense. I suppose it may have been true
> long ago in the past.
>
>
Hi Jason,
> -Original Message-
> From: Jason Gunthorpe
> Sent: Thursday, April 4, 2024 8:39 PM
> To: Zeng, Oak
> Cc: dri-devel@lists.freedesktop.org; intel...@lists.freedesktop.org; Brost,
> Matthew ; thomas.hellst...@linux.intel.com;
> Welty, Brian ; Ghimiray, Himal Prasad
> ; Bommu,
On Thu, Apr 04, 2024 at 11:33:28PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> crtc->mode is legacy junk and shouldn't really be used with
> atomic drivers.
>
> Most (all?) atomic drivers do end up still calling
> drm_atomic_helper_update_legacy_modeset_state() at some
> point, so
On Thu, Apr 04, 2024 at 11:33:27PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Prefer drm_mode_destroy() over bare kfree(), for consistency
> and setting a good example.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_client_modeset.c | 4 ++--
> 1 file changed, 2
On Thu, Apr 04, 2024 at 11:33:26PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Drop the "has" from drm_connector_has_preferred_mode() to better
> describe what it does.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_client_modeset.c | 8
> 1 file changed, 4
On Thu, Apr 04, 2024 at 11:33:25PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The modes[] array contains pointers to modes on the connectors'
> mode lists, which are protected by dev->mode_config.mutex.
> Thus we need to extend modes[] the same protection or by the
> time we use it
Hi all,
After merging the drm-intel tree, today's linux-next build (htmldocs)
produced these warnings:
include/drm/display/drm_dp_helper.h:126: warning: Function parameter or struct
member 'mode' not described in 'drm_dp_as_sdp'
include/drm/display/drm_dp_helper.h:126: warning: Excess struct
On Wed, Jan 17, 2024 at 05:12:06PM -0500, Oak Zeng wrote:
> +/**
> + * xe_svm_build_sg() - build a scatter gather table for all the physical
> pages/pfn
> + * in a hmm_range.
> + *
> + * @range: the hmm range that we build the sg table from. range->hmm_pfns[]
> + * has the pfn numbers of pages
I didn't pay close enough attention the last time I tried to fix this
problem - while we currently do correctly take care to make sure we don't
probe a connected eDP port more then once, we don't do the same thing for
eDP ports we found to be disconnected.
So, fix this and make sure we only ever
GSP has its own state for keeping track of whether or not a given display
connector is plugged in or not, and enforces this state on the driver. In
particular, AUX transactions on a DisplayPort connector which GSP says is
disconnected can never succeed - and can in some cases even cause
unexpected
Fixes for a few issues I've been seeing around regarding DP aux
transactions with nouveau and GSP support - mainly stemming from the
fact that GSP returns an error for aux transactions that are attempted
on disconnected ports. Some of these issues somehow manage to make
runtime PM fail on my
Peter, can you please review version 7 of "x86/vmware: Add TDX hypercall
support" patch.
It addresses the concern you had in previous version. Thanks.
On Tue, Apr 02, 2024 at 02:28:55PM +0530, Aravind Iddamsetty wrote:
> PCI subsystem provides callbacks to inform the driver about a request to
> do function level reset by user, initiated by writing to sysfs entry
> /sys/bus/pci/devices/.../reset. This will allow the driver to handle FLR
> without
On 04.04.2024 11:31, Maíra Canal wrote:
> On 4/4/24 11:00, Adrián Larumbe wrote:
> > This changeset is heavily inspired by commit 509433d8146c ("drm/v3d: Expose
> > the total GPU usage stats on sysfs"). The point is making broader GPU
> > occupancy numbers available through the sysfs interface, so
On Tue, 02 Apr 2024 05:57:14 +0300, Dmitry Baryshkov wrote:
> Fix several warnings produced by the display nodes.
>
> Please excuse me for the spam for sending v3 soon after v2.
>
>
Applied, thanks!
[2/4] arm64: dts: qcom: sc8180x: drop legacy property #stream-id-cells
commit:
On 4/4/24 01:26, Vivek Kasireddy wrote:
Since the memfd pages associated with a udmabuf may be migrated
as part of udmabuf create, we need to verify the data coherency
after successful migration. The new tests added in this patch try
to do just that using 4k sized pages and also 2 MB sized huge
From: Ville Syrjälä
Switch to the canonical [CONNECTOR:%d:%s] etc. format for
printing out kms objects.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client_modeset.c | 65 +++-
1 file changed, 35 insertions(+), 30 deletions(-)
diff --git
From: Ville Syrjälä
Use a consistent method for picking the first mode from the
connnector's mode list.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client_modeset.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git
From: Ville Syrjälä
Use the array notation rather that the pointer notation for
function arguments. This makes it clear to the reader that
we are in fact dealing with an array rather than a single
pointer. Functionally the two are equivalent.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Switch to per-device debugs so that we know which
device we're dealing with.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_probe_helper.c | 35 ++
1 file changed, 16 insertions(+), 19 deletions(-)
diff --git
From: Ville Syrjälä
Use drm_dev_dbg() & co. so that we know which device we're
dealing with.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client_modeset.c | 117 ++-
1 file changed, 60 insertions(+), 57 deletions(-)
diff --git
From: Ville Syrjälä
The modes used by the client code live on the connectors' mode
lists, which are not owned by the client code, and thus it has
no business modifying the modes. Mark the modes const to make
that fact abundantly clear.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Get rid of all the redundant debugs and just wait until the end
to print which mode (and of which type) we picked.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client_modeset.c | 65 +---
1 file changed, 31 insertions(+), 34 deletions(-)
From: Ville Syrjälä
Remove the tall tale about fastboot vs. user mode vs.
adjusted mode. crtc->mode == crtc->state->mode, so none
of this makes any sense. I suppose it may have been true
long ago in the past.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client_modeset.c | 10
From: Ville Syrjälä
crtc->mode is legacy junk and shouldn't really be used with
atomic drivers.
Most (all?) atomic drivers do end up still calling
drm_atomic_helper_update_legacy_modeset_state() at some
point, so crtc->mode does still get populated, and this
does work for now. But eventually
From: Ville Syrjälä
Prefer drm_mode_destroy() over bare kfree(), for consistency
and setting a good example.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client_modeset.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
From: Ville Syrjälä
Drop the "has" from drm_connector_has_preferred_mode() to better
describe what it does.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client_modeset.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
From: Ville Syrjälä
The modes[] array contains pointers to modes on the connectors'
mode lists, which are protected by dev->mode_config.mutex.
Thus we need to extend modes[] the same protection or by the
time we use it the elements may already be pointing to
freed/reused memory.
Cc:
From: Ville Syrjälä
Various improvements to the drm/client code:
- Fix a use after free (fairly routinely hit by i915 CI)
- Debug print improvements
- Cleanups/etc.
Ville Syrjälä (12):
drm/client: Fully protect modes[] with dev->mode_config.mutex
drm/client:
Hi AngeloGioacchino,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on robh/for-next pza/reset/next linus/master v6.9-rc2
next-20240404]
[cannot apply to pza/imx-drm/next]
[If your patch is applied
On 4/2/2024 2:00 AM, Martin Habets wrote:
> On Fri, Mar 29, 2024 at 05:00:34PM +, Easwar Hariharan wrote:
>> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
>> with more appropriate terms. Inspired by and following on to Wolfram's
>> series to fix drivers/i2c/[1], fix
On 4/2/2024 1:29 AM, Simon Horman wrote:
> On Fri, Mar 29, 2024 at 05:00:34PM +, Easwar Hariharan wrote:
>> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
>> with more appropriate terms. Inspired by and following on to Wolfram's
>> series to fix drivers/i2c/[1], fix the
This reverts commit 5a838e5d5825c85556011478abde708251cc0776.
Changes from commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") would
result in a '[TTM] Buffer eviction failed' exception whenever it reached a
timeout.
Due to a dependency to DMA_FENCE_WARN this also restores some code deleted
Changes since v1:
- replace new code logic in v1 with past code version by reverting
commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait")
- add missing code dependency from
commit d72277b6c37d ("dma-buf: nuke DMA_FENCE_TRACE macros v2")
---
Hi,
To clarify, the reason for my original
On 4/4/24 18:44, Lucas Stach wrote:
Am Donnerstag, dem 04.04.2024 um 15:15 +0200 schrieb Helge Deller:
On 4/4/24 14:18, Lucas Stach wrote:
This change strips $abs_srctree of the input file containing the
PNM data in the generated output. The motivation for this change
is Yocto emitting a build
Hi Dave and Sima,
Here goes drm-intel-fixes-2024-04-04:
Display fixes:
- A few DisplayPort related fixes (Imre, Arun, Ankit, Ville)
- eDP PSR fixes (Jouni)
Core/GT fixes:
- Remove some VM space restrictions on older platforms (Andi)
- Disable automatic load CCS load balancing (Andi)
Thanks,
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 2b3d5988ae2cb5cd945ddbc653f0a71706231fdd Add linux-next specific
files for 20240404
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202404041707.4bl4ifti-...@intel.com
https
On 04/04/2024 10:13, Jerome Brunet wrote:
On Wed 03 Apr 2024 at 09:46, Neil Armstrong wrote:
The VCLK and VCLK_DIV clocks have supplementary bits.
The VCLK gate has a "SOFT RESET" bit to toggle after the whole
VCLK sub-tree rate has been set, this is implemented in
the gate enable callback.
On Thu, Apr 4, 2024 at 12:15 AM Yoshinori Sato
wrote:
>
> Fix extrnal fdt initialize and bootargs.
What is the problem you are trying to solve?
And a typo.
>
> Signed-off-by: Yoshinori Sato
> ---
> arch/sh/Kconfig | 23 +++
> arch/sh/include/asm/setup.h | 1 +
Am Donnerstag, dem 04.04.2024 um 15:15 +0200 schrieb Helge Deller:
> On 4/4/24 14:18, Lucas Stach wrote:
> > This change strips $abs_srctree of the input file containing the
> > PNM data in the generated output. The motivation for this change
> > is Yocto emitting a build warning
> >
> >
On Wed, Sep 28, 2022 at 02:23:01PM +0800, Jianglei Nie wrote:
> fbtft_probe_common() allocates a memory chunk for "info" with
> fbtft_framebuffer_alloc(). When "display->buswidth == 0" is true, the
> function returns without releasing the "info", which will lead to a
> memory leak.
>
> Fix it by
From: Arnd Bergmann
Calling a function through an incompatible pointer type causes breaks
kcfi, so clang warns about the assignment:
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowof.c:73:10: error: cast from
'void (*)(const void *)' to 'void (*)(void *)' converts to incompatible
function
On 1/5/24 21:46, Dmitry Osipenko wrote:
> From: Boris Brezillon
>
> If some the pages or sgt allocation failed, we shouldn't release the
> pages ref we got earlier, otherwise we will end up with unbalanced
> get/put_pages() calls. We should instead leave everything in place
> and let the BO
ni,
Observed warning "include/drm/drm_print.h:536:35: warning: '%4.4s'
directive argument is null [-Wformat-overflow=]" when building the
modules with "defconfig+kselftest-ftrace"(
https://github.com/torvalds/linux/blob/master/tools/testing/
Convert udl to use struct drm_edid and its helpers. Also clean up
a few things in the process.
Patches 1 and 2 add a custom EDID probe function similar to the
existing drm_probe_ddc(). The seconds patch is necessary to make
it useful for udl.
Patch 3 fixes a bug.
Patches 4 to 6 convert the
Protect the code in udl_get_edid_block() with drm_dev_enter() and
drm_dev_exit(), so that all callers automatically invoke it. The
function uses hardware resources, which can be hot-unplugged at
any time. The other code in udl_connector_detect() does not use the
resources of the hardware device
Udl's struct udl_connector is an empty wrapper around struct
drm_connector. Remove it. Allocate the connector as part of struct
udl_device and inline the init function into its only caller.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/udl/udl_drv.h | 10 +--
DisplayLink devices do not generate hotplug events. Remove the poll
flag DRM_CONNECTOR_POLL_HPD, as it may not be specified together with
DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT.
Signed-off-by: Thomas Zimmermann
Fixes: afdfc4c6f55f ("drm/udl: Fixed problem with UDL adpater
Provide separate implementations of .get_modes() and .detect_ctx()
from struct drm_connector. Switch to struct drm_edid.
Udl's .detect() helper used to fetch the EDID from the adapter and the
.get_modes() helper provided display modes from the data. Switching to
the new helpers around struct
Clean up Makefile before listing new object files. No functional
changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/udl/Makefile | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/udl/Makefile b/drivers/gpu/drm/udl/Makefile
index
EDID read functions do not validate their return data. So they might
return the required number of bytes of probing, but with invalid
data. Therefore test for the presence of an EDID header similar to
the code in edid_block_check().
Signed-off-by: Thomas Zimmermann
---
Move the logic from drm_probe_ddc() into drm_edid_probe_custom(),
which receives the EDID read function as argument. Allows drivers
without DDC to implement similar functionality without duplicating
the code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_edid.c | 22
On 3/19/2024 3:16 PM, Maxime Ripard wrote:
On Mon, Mar 18, 2024 at 04:37:58PM +0200, Jani Nikula wrote:
On Mon, 11 Mar 2024, Mitul Golani wrote:
An Adaptive-Sync-capable DP protocol converter indicates its
support by setting the related bit in the DPCD register. This
is valid for DP and
Hi Dave and Sima,
Please pull the drm-xe-fixes for this week targeting v6.9-rc3.
This is a little late in the week as I was waiting a critical fix to be
applied to get our CI back. This is mainly due to some stress tests
creating hundreds of exec queues and that not playing nice with the
On 4/4/24 11:00, Adrián Larumbe wrote:
This changeset is heavily inspired by commit 509433d8146c ("drm/v3d: Expose
the total GPU usage stats on sysfs"). The point is making broader GPU
occupancy numbers available through the sysfs interface, so that for every
job slot, its number of processed
On Thu, 04 Apr 2024 14:40:51 +0200, Arnd Bergmann wrote:
> Both the exynos and rockchip drivers ran into link failures after
> a Kconfig cleanup:
>
> aarch64-linux-ld: drivers/gpu/drm/exynos/exynos_dp.o: in function
> `exynos_dp_resume':
> exynos_dp.c:(.text+0xc0): undefined reference to
On Thu, Apr 04, 2024 at 09:59:03AM -0400, Harry Wentland wrote:
>
Hi all,
>
> On 2024-04-04 06:24, Pekka Paalanen wrote:
> > On Wed, 3 Apr 2024 17:32:46 -0400
> > Leo Li wrote:
> >
> >> On 2024-03-28 10:33, Pekka Paalanen wrote:
> >>> On Fri, 15 Mar 2024 13:09:56 -0400
> >>> wrote:
> >>>
>
This changeset is heavily inspired by commit 509433d8146c ("drm/v3d: Expose
the total GPU usage stats on sysfs"). The point is making broader GPU
occupancy numbers available through the sysfs interface, so that for every
job slot, its number of processed jobs and total processing time are
On 2024-04-04 06:24, Pekka Paalanen wrote:
> On Wed, 3 Apr 2024 17:32:46 -0400
> Leo Li wrote:
>
>> On 2024-03-28 10:33, Pekka Paalanen wrote:
>>> On Fri, 15 Mar 2024 13:09:56 -0400
>>> wrote:
>>>
From: Leo Li
These patches aim to make the amdgpgu KMS driver play nicer
On Thu, Apr 04, 2024 at 01:59:25PM +0900, Yoshinori Sato wrote:
> This is an updated version of something I wrote about 7 years ago.
> Minimum support for R2D-plus and LANDISK.
> I think R2D-1 will work if you add AX88796 to dts.
> And board-specific functions and SCI's SPI functions are not
On 4/4/24 14:18, Lucas Stach wrote:
This change strips $abs_srctree of the input file containing the
PNM data in the generated output. The motivation for this change
is Yocto emitting a build warning
WARNING: linux-foo-6.8-r0 do_package_qa: QA Issue:
File
Serial is Reviewed-by: Qiang Yu
On Tue, Apr 2, 2024 at 6:43 AM Erico Nunes wrote:
>
> Patch 1 is a fix for a crash which triggers on removing the module on
> kernels with CONFIG_DEBUG_SHIRQ enabled, such as the Fedora kernel.
>
> Patch 2 is a fix to this warning:
>
From: Arnd Bergmann
Both the exynos and rockchip drivers ran into link failures after
a Kconfig cleanup:
aarch64-linux-ld: drivers/gpu/drm/exynos/exynos_dp.o: in function
`exynos_dp_resume':
exynos_dp.c:(.text+0xc0): undefined reference to `analogix_dp_resume'
aarch64-linux-ld:
Reviewed-by: Qiang Yu
On Tue, Apr 2, 2024 at 5:20 AM Erico Nunes wrote:
>
> There is a race condition in which a rendering job might take just long
> enough to trigger the drm sched job timeout handler but also still
> complete before the hard reset is done by the timeout handler.
> This runs
On Tue, Apr 2, 2024 at 5:20 AM Erico Nunes wrote:
>
> This is needed because we want to reset those devices in device-agnostic
> code such as lima_sched.
> In particular, masking irqs will be useful before a hard reset to
> prevent race conditions.
>
> Signed-off-by: Erico Nunes
> ---
>
On Mon, 04 Mar 2024 18:48:57 -0600, Adam Ford wrote:
> The IRQ registration currently assumes that the GPIO is dedicated
> to it, but that may not necessarily be the case. If the board has
> another device sharing the GPIO, it won't be registered and the
> hot-plug detect fails to function.
>
>
On Mon, Mar 04, 2024 at 06:48:57PM -0600, Adam Ford wrote:
> The IRQ registration currently assumes that the GPIO is dedicated
> to it, but that may not necessarily be the case. If the board has
> another device sharing the GPIO, it won't be registered and the
> hot-plug detect fails to function.
This change strips $abs_srctree of the input file containing the
PNM data in the generated output. The motivation for this change
is Yocto emitting a build warning
WARNING: linux-foo-6.8-r0 do_package_qa: QA Issue:
File
On Tue, Mar 5, 2024 at 2:18 AM Laurent Pinchart
wrote:
>
> Hello Adam,
>
> Thank you for the patch.
>
> On Mon, Mar 04, 2024 at 06:48:57PM -0600, Adam Ford wrote:
> > The IRQ registration currently assumes that the GPIO is dedicated
> > to it, but that may not necessarily be the case. If the
On Sun, Mar 31, 2024 at 10:45 AM Krzysztof Kozlowski
wrote:
> virtio core already sets the .owner, so driver does not need to.
>
> Acked-by: Bartosz Golaszewski
> Acked-by: Viresh Kumar
> Signed-off-by: Krzysztof Kozlowski
Acked-by: Linus Walleij
Yours,
Linus Walleij
Hi Dave, Sima,
here's the drm-misc-fixes PR for this week.
Best regards
Thomas
drm-misc-fixes-2024-04-04:
Short summary of fixes pull:
display:
- fix typos in kerneldoc
nouveau:
- uvmm: fix remap address calculation
- minor cleanups
panfrost:
- fix power-transition timeouts
prime:
- unbreak
PREEMPT_RT has a different locking implementation for ww_mutex. The
base mutex of struct ww_mutex is declared as struct WW_MUTEX_BASE. The
latter is defined as `mutex' for non-PREEMPT_RT builds and `rt_mutex'
for PREEMPT_RT builds.
Using mutex_lock() directly on the base mutex in
On Wed, 3 Apr 2024 17:32:46 -0400
Leo Li wrote:
> On 2024-03-28 10:33, Pekka Paalanen wrote:
> > On Fri, 15 Mar 2024 13:09:56 -0400
> > wrote:
> >
> >> From: Leo Li
> >>
> >> These patches aim to make the amdgpgu KMS driver play nicer with
> >> compositors
> >> when building multi-plane
The DSI device for the panel was registered by the DSI host, so it is an
error to unregister it from the panel driver. Drop the call to
mipi_dsi_device_unregister().
Fixes: c7f66d32dd43 ("drm/panel: add support for rm69299 visionox panel")
Signed-off-by: Dmitry Baryshkov
---
Use .init_load_uA part of the bulk regulator API instead of calling
register_set_load() manually.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-visionox-rm69299.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git
It is pointless to set register load before disabling the register. This
vote is going to be dropped as soon as the register is disabled. Drop
these register_set_load calls.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-novatek-nt36672e.c | 17 -
1 file
Use .init_load_uA part of the bulk regulator API instead of calling
register_set_load() manually.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-novatek-nt36672e.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git
Use .init_load_uA part of the bulk regulator API instead of calling
register_set_load() manually.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-novatek-nt36672a.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git
The DSI device for the panel was registered by the DSI host, so it is an
error to unregister it from the panel driver. Drop the call to
mipi_dsi_device_unregister().
Fixes: ea4f9975625a ("drm/panel: Add support for Novatek NT36672E panel driver")
Signed-off-by: Dmitry Baryshkov
---
-nt36672a.c | 11 +++-
drivers/gpu/drm/panel/panel-novatek-nt36672e.c | 35 +++---
drivers/gpu/drm/panel/panel-visionox-rm69299.c | 18 ++---
3 files changed, 9 insertions(+), 55 deletions(-)
---
base-commit: a6bd6c997f5a0e2667d4d82fef8c970108f2
change-id: 20240404
On Tue, 2024-04-02 at 12:33 +0200, Julien Panis wrote:
[...]
> +static int am65_cpsw_run_xdp(struct am65_cpsw_common *common, struct
> am65_cpsw_port *port,
> + struct xdp_buff *xdp, int desc_idx, int cpu, int
> *len)
> +{
> + struct am65_cpsw_rx_chn *rx_chn =
On Thu, 04 Apr 2024 10:16:34 +0200, AngeloGioacchino Del Regno wrote:
> Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths
> per HW instance (so potentially up to six displays for multi-vdo SoCs).
>
> The MMSYS or VDOSYS is always the first component in the DDP pipeline,
>
On Wed 03 Apr 2024 at 09:46, Neil Armstrong wrote:
> The VCLK and VCLK_DIV clocks have supplementary bits.
>
> The VCLK gate has a "SOFT RESET" bit to toggle after the whole
> VCLK sub-tree rate has been set, this is implemented in
> the gate enable callback.
>
> The VCLK_DIV clocks as enable
On Wed, 3 Apr 2024 07:44:54 -0400
Zack Rusin wrote:
> On Wed, Apr 3, 2024 at 3:43 AM Pekka Paalanen
> wrote:
> >
> > On Tue, 2 Apr 2024 19:28:13 -0400
> > Zack Rusin wrote:
> >
> > > The table of primary plane formats wasn't sorted at all, leading to
> > > applications picking our least
Old and new state parameters are swapped, so the old state was cleared
instead of the new duplicated state.
Fixes: 903674588a48 ("drm/atomic-helper: Add format-conversion state to
shadow-plane state")
Signed-off-by: Lucas Stach
Tested-by: Leonard Göhrs
---
The display IPs in MediaTek SoCs support being interconnected with
different instances of DDP IPs (for example, merge0 or merge1) and/or
with different DDP IPs (for example, rdma can be connected with either
color, dpi, dsi, merge, etc), forming a full Display Data Path that
ends with an actual
It is impossible to add each and every possible DDP path combination
for each and every possible combination of SoC and board: right now,
this driver hardcodes configuration for 10 SoCs and this is going to
grow larger and larger, and with new hacks like the introduction of
mtk_drm_route which is
Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths
per HW instance (so potentially up to six displays for multi-vdo SoCs).
The MMSYS or VDOSYS is always the first component in the DDP pipeline,
so it only supports an output port with multiple endpoints - where each
endpoint
The display IPs in MediaTek SoCs are *VERY* flexible and those support
being interconnected with different instances of DDP IPs (for example,
merge0 or merge1) and/or with different DDP IPs (for example, rdma can
be connected with either color, dpi, dsi, merge, etc), forming a full
Display Data
Move the simple component check to a new mtk_ddp_is_simple_comp()
internal helper to reduce code duplication.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 57 +++--
1 file changed, 31 insertions(+), 26
1 - 100 of 122 matches
Mail list logo
