On Fri, Jan 17, 2025 at 11:46:57AM -0500, Detlev Casanova wrote:
> From: Sugar Zhang
>
> Register the dw-hdmi-qp bridge driver as an HDMI audio codec.
>
> The register values computation functions (for n) are based on the
> downstream driver, as well as the register writing functions.
>
> The d
If DRM_FORMAT_MOD_LINEAR stays, then most of this discussion is irrelevant.
If you don't like the new linear modifiers, don't use them. If that's you,
bye.
For the rest, there are multiple solutions:
1) New vendor-agnostic linear modifiers. The reason why we would want them
is that they define ro
Hi AngeloGioacchino,
kernel test robot noticed the following build warnings:
[auto build test WARNING on next-20250113]
[cannot apply to robh/for-next pza/reset/next linus/master pza/imx-drm/next
drm-misc/drm-misc-next v6.13-rc7 v6.13-rc6 v6.13-rc5 v6.13-rc7]
[If your patch is applied to the wro
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 efficient.
Selected power profile will be displayed in this format-
$ cat slpc_power_profile
[base]power_saving
$ echo power_sa
On Fri, Jan 17, 2025 at 12:24:14PM -0800, 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 efficient.
>
> Selected power profile will be displayed in this
On 1/15/2025 5:14 PM, Dmitry Baryshkov wrote:
On Wed, Jan 15, 2025 at 04:40:39PM -0800, Abhinav Kumar wrote:
On 1/15/2025 4:32 PM, Dmitry Baryshkov wrote:
On Wed, Jan 15, 2025 at 11:41:27AM -0800, Abhinav Kumar wrote:
On 1/15/2025 12:27 AM, Dmitry Baryshkov wrote:
On Tue, Jan 14, 2025
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 efficient.
Selected power profile will be displayed in this format-
$ cat slpc_power_profile
[base]power_saving
$ echo power_sa
On Mon, Jan 13, 2025 at 05:12:01PM +0530, Tejas Upadhyay wrote:
Next time, please identify the patch with 'drm/xe/uapi' to get
it more visible to maintainers.
> In order to avoid having userspace to use MI_MEM_FENCE,
> we are adding a mechanism for userspace to generate a
> PCI memory barrier wit
On Fri, Jan 17, 2025 at 2:14 PM Ian Forbes wrote:
>
> Fixes: d6667f0ddf46 ("drm/vmwgfx: Fix handling of dumb buffers")
> Signed-off-by: Ian Forbes
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 1 +
> 2 files changed, 2 insertions(+), 1 deleti
Fixes: d6667f0ddf46 ("drm/vmwgfx: Fix handling of dumb buffers")
Signed-off-by: Ian Forbes
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
b/drivers
On 17.01.25 18:29, Michal Koutný wrote:
On Thu, Jan 16, 2025 at 09:20:08AM +0100, Friedrich Vock
wrote:
These pools are allocated on-demand, so if a
cgroup has not made any allocations for a specific device, there will be
no pool corresponding to that device's memory.
Here I understand.
Po
On Fri, Jan 17, 2025 at 10:26:16AM +0200, Gwan-gyeong Mun wrote:
>
>
> On 12/18/24 1:33 AM, Matthew Brost wrote:
> > This patch introduces support for GPU Shared Virtual Memory (SVM) in the
> > Direct Rendering Manager (DRM) subsystem. SVM allows for seamless
> > sharing of memory between the CPU
On Fri, Jan 17, 2025 at 10:21:53AM -0800, Belgaumkar, Vinay wrote:
>
> On 1/17/2025 6:29 AM, Rodrigo Vivi wrote:
> > On Thu, Jan 16, 2025 at 03:51:03PM -0800, Belgaumkar, Vinay wrote:
> > > On 1/16/2025 2:57 PM, Rodrigo Vivi wrote:
> > > > On Fri, Jan 10, 2025 at 03:21:51PM -0800, Vinay Belgaumkar
Hi AngeloGioacchino,
kernel test robot noticed the following build errors:
[auto build test ERROR on next-20250113]
[cannot apply to robh/for-next pza/reset/next linus/master pza/imx-drm/next
drm-misc/drm-misc-next v6.13-rc7 v6.13-rc6 v6.13-rc5 v6.13-rc7]
[If your patch is applied to the wrong g
On 1/17/2025 6:29 AM, Rodrigo Vivi wrote:
On Thu, Jan 16, 2025 at 03:51:03PM -0800, Belgaumkar, Vinay wrote:
On 1/16/2025 2:57 PM, Rodrigo Vivi wrote:
On Fri, Jan 10, 2025 at 03:21:51PM -0800, Vinay Belgaumkar wrote:
Default SLPC power profile is Base(0). Power Saving mode(1)
has conservativ
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"). Exclude it like is done for i915 and other
> drivers wi
On Thu, Jan 16, 2025 at 09:20:08AM +0100, Friedrich Vock
wrote:
> These pools are allocated on-demand, so if a
> cgroup has not made any allocations for a specific device, there will be
> no pool corresponding to that device's memory.
Here I understand.
> Pools have a hierarchy of their own (th
On Fri, Jan 17, 2025 at 05:05:42PM +0100, Marek Szyprowski wrote:
> On 17.01.2025 15:30, Andy Shevchenko wrote:
> > On Fri, Jan 17, 2025 at 04:09:58PM +0200, Andy Shevchenko wrote:
> >> On Fri, Jan 17, 2025 at 02:57:52PM +0100, Marek Szyprowski wrote:
> >>> On 16.01.2025 13:42, Andy Shevchenko wrot
From: Matthew Leung
Currently, MHI host only performs firmware transfer via BHI in PBL and
BHIe from SBL. To support BHIe transfer directly from PBL, a policy
needs to be added.
With this policy, BHIe will be used to transfer firmware in PBL if the
MHI controller has BHIe regs, sets seg_len, and
From: Youssef Samir
AIC200 device will support MSI-X while AIC100 devices will keep using
MSI. pci_alloc_irq_vectors() will try to allocate MSI-X vectors if it
is supported by the target device, otherwise, it will fallback to MSI.
Add support for MSI-X vectors allocation for AIC200 devices.
Sig
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-by: Youssef Samir
Signed-off-by: Youssef Samir
Signed-off-by: Jeffrey Hugo
Reviewed-by: Lizhi Hou
---
drivers/acc
From: Youssef Samir
During the initialization of the qaic device, pci_select_bars() is
used to fetch a bitmask of the BARs exposed by the device. On devices
that have Virtual Functions capabilities, the bitmask includes SR-IOV
BARs.
Use a mask to filter out SR-IOV BARs if they exist.
Signed-off
As the number of cards supported by the driver grows, their
configurations will differ. The driver needs to become more dynamic
to support these configurations. Currently, each card may differ in
the exposed BARs, the regions they map to, and the family.
Create config structs for each card, and le
From: Youssef Samir
Devices use 1 MSI vector for the MHI controller and as many vectors as
the DMA bridge channels on the device. During the probing of the
device, the driver allocates 32 MSI vectors, which is usually more
than what is needed for AIC100 devices, which is wasting resources.
Alloc
From: Matthew Leung
Refactor the firmware loading code to have distinct helper functions for
BHI and BHIe operations. This lays the foundation for separating the
firmware loading protocol from the firmware being loaded and the EE it
is loaded in.
Signed-off-by: Matthew Leung
Reviewed-by: Yousse
Initial support to the driver to boot up AIC200. AIC200 uses BHIe
without BHI, which is something that the MHI bus has not supported until
now. While the MHI changes are listed first to facilitate cross-tree
merging, they are not needed until the last change in the series.
Also, AIC200 is a differ
Hi AngeloGioacchino,
kernel test robot noticed the following build errors:
[auto build test ERROR on next-20250113]
[cannot apply to robh/for-next pza/reset/next linus/master pza/imx-drm/next
drm-misc/drm-misc-next v6.13-rc7 v6.13-rc6 v6.13-rc5 v6.13-rc7]
[If your patch is applied to the wrong g
On 14.01.25 09:08, Vivek Kasireddy wrote:
There are cases when we try to pin a folio but discover that it has
not been faulted-in. So, we try to allocate it in memfd_alloc_folio()
but there is a chance that we might encounter a crash/failure
(VM_BUG_ON(!h->resv_huge_pages)) if there are no active
From: Sugar Zhang
Register the dw-hdmi-qp bridge driver as an HDMI audio codec.
The register values computation functions (for n) are based on the
downstream driver, as well as the register writing functions.
The driver uses the generic HDMI Codec framework in order to implement
the HDMI audio
Use the simple-audio-card driver with the hdmi0 QP node as CODEC and
the i2s5 device as CPU.
The simple-audio-card,mclk-fs value is set to 128 as it is done in
the downstream driver.
The #sound-dai-cells value is set to 0 in the hdmi0 node so that it can be
used as an audio codec node.
Signed-of
To support HDMI audio on the rk3588 based devices, the generic HDMI
Codec framework is used in the dw-hdmi-qp DRM bridge driver.
The implementation is mainly based on the downstream driver, ported to the
generic HDMI Codec framework [1] recently merged in the DRM tree.
The parameters computation h
On 1/7/2025 10:42 PM, Manivannan Sadhasivam wrote:
On Fri, Dec 13, 2024 at 02:33:35PM -0700, Jeffrey Hugo wrote:
From: Matthew Leung
Currently, mhi host only performs firmware transfer via BHI in PBL and
s/mhi/MHI here and below.
Done
BHIe from SBL. To support BHIe transfer directly fr
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"). Exclude it like is done for i915 and other
drivers with dedicated maintainers.
Signed-off-by: Lucas De Marchi
---
MAINTAINE
Hi,
On Thu, Jan 16, 2025 at 5:00 PM Andy Yan wrote:
>
> Add an eDP panel entry for BOE NV140FHM-NZ.
>
> No datasheet found for this panel, so the timing
> is based on a similar NV140FHM-N41 datasheet that
> I can find on internet[0].
>
> edid:
> 00 ff ff ff ff ff ff 00 09 e5 09 0b 00 00 00 00
> 0
Hi Dave, Simona,
Fixes for 6.14.
The following changes since commit 24c61d553302ee49e9c21dd251275ba8c36dcfe4:
Merge tag 'drm-msm-next-2025-01-07' of gitlab.freedesktop.org:drm/msm into
drm-next (2025-01-13 11:14:07 +1000)
are available in the Git repository at:
https://gitlab.freedesktop.
On 1/7/2025 10:24 PM, Manivannan Sadhasivam wrote:
On Fri, Dec 13, 2024 at 02:33:34PM -0700, Jeffrey Hugo wrote:
From: Matthew Leung
Refactor the firmware loading code to have distinct helper functions for
BHI and BHIe operations. This lays the foundation for separating the
firmware loading pr
On 12/13/2024 11:51 AM, Jeffrey Hugo wrote:
From: Youssef Samir
aic100_image_table is currently defined as a "const char *" array,
this can potentially lead to the accidental modification of the
pointers inside. Also, checkpatch.pl gives a warning about it.
Change the type to a "const char * c
Currently, only one pair of mixers is supported, so a non-zero counter
value is sufficient to identify the correct mixer within that pair.
However, future implementations may involve multiple mixer pairs. With
the current implementation, all mixers within the second pair would be
incorrectly select
On 17.01.2025 15:30, Andy Shevchenko wrote:
> On Fri, Jan 17, 2025 at 04:09:58PM +0200, Andy Shevchenko wrote:
>> On Fri, Jan 17, 2025 at 02:57:52PM +0100, Marek Szyprowski wrote:
>>> On 16.01.2025 13:42, Andy Shevchenko wrote:
If the selector register is represented in each page, its value
>>
To support high-resolution cases that exceed the width limitation of
a pair of SSPPs, or scenarios that surpass the maximum MDP clock rate,
additional pipes are necessary to enable parallel data processing
within the SSPP width constraints and MDP clock rate.
Request 4 mixers and 4 DSCs for high-r
The content of every half of screen is sent out via one interface in
dual-DSI case. The content for every interface is blended by a LM
pair in quad-pipe case, thus a LM pair should not blend any content
that cross the half of screen in this case. Clip plane into pipes per
left and right half screen
Currently, only 2 pipes are used at most for a plane. A stage structure
describes the configuration for a mixer pair. So only one stage is needed
for current usage cases. The quad-pipe case will be added in future and 2
stages are used in the case. So extend the stage to an array with array size
ST
The stage contains configuration for a mixer pair. Currently the plane
supports just one stage and 2 pipes. Quad-pipe support will require
handling 2 stages and 4 pipes at the same time. In preparation for that
add a separate define, PIPES_PER_PLANE, to denote number of pipes that
can be used by th
There are 2 pipes in a drm plane at most currently, while 4 pipes are
required for quad-pipe case. Generalize the handling to pipe pair and
ease handling to another pipe pair later. Store pipes in array with
removing dedicated r_pipe.
Signed-off-by: Jun Nie
Reviewed-by: Dmitry Baryshkov
---
dri
Add pipe as trace argument in trace_dpu_crtc_setup_mixer() to ease
converting pipe into pipe array later.
Signed-off-by: Jun Nie
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 10 +-
2 files changed, 6 ins
Up to now the driver has been using encoder to allocate hardware resources.
Switch it to use CRTC id so that mixer number can be known in
dpu_plane_virtual_assign_resources() via CRTC id for sspp alloation.
Because the mixer allocation is done in drm_atomic_helper_check_modeset()
as part of CRTC o
Current code only supports usage cases with one pair of mixers at
most. To support quad-pipe usage case, two pairs of mixers need to
be reserved. The lm_count for all pairs is cleared if a peer
allocation fails in current implementation. Reset the current lm_count
to an even number instead of compl
Currently if DSC support is requested, the driver only supports using
2 DSC blocks. We need 4 DSC in quad-pipe topology in future. So Only
configure DSC engines in use, instead of the maximum number of DSC
engines.
Signed-off-by: Jun Nie
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dis
Currently, SSPPs are assigned to a maximum of two pipes. However,
quad-pipe usage scenarios require four pipes and involve configuring
two stages. In quad-pipe case, the first two pipes share a set of
mixer configurations and enable multi-rect mode when certain
conditions are met. The same applies
The capability stored in sblk and pipe_hw_caps is checked only for
SSPP of the first pipe in the pair with current implementation. That
of the 2nd pipe, r_pipe, is not checked and may violate hardware
capability. Move requirement check to dpu_plane_atomic_check_pipe()
for the check of every pipe.
There are 2 interfaces and 4 pingpong in quad pipe. Map the 2nd
interface to 3rd PP instead of the 2nd PP.
Signed-off-by: Jun Nie
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 15 +--
1 file changed, 13 insertions(+), 2 d
It is more likely that resource allocation may fail in complex usage
case, such as quad-pipe case, than existing usage cases.
A resource type ID is printed on failure in the current implementation,
but the raw ID number is not explicit enough to help easily understand
which resource caused the fail
2 or more SSPPs and dual-DSI interface are need for super wide panel.
And 4 DSC are preferred for power optimal in this case due to width
limitation of SSPP and MDP clock rate constrain. This patch set
extends number of pipes to 4 and revise related mixer blending logic
to support quad pipe. All th
Currently, if DSC is enabled, only 2 DSC engines are supported so far.
More usage cases will be added, such as 4 DSC in 4:4:2 topology. So
get the real number of DSCs to decide whether DSC merging is needed.
Signed-off-by: Jun Nie
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/
On 17.01.2025 15:09, Andy Shevchenko wrote:
> On Fri, Jan 17, 2025 at 02:57:52PM +0100, Marek Szyprowski wrote:
>> On 16.01.2025 13:42, Andy Shevchenko wrote:
>>> If the selector register is represented in each page, its value
>>> in accordance to the debugfs is stale because it gets synchronized
On Fri, Jan 17, 2025 at 04:30:59PM +0200, Andy Shevchenko wrote:
> On Fri, Jan 17, 2025 at 04:09:58PM +0200, Andy Shevchenko wrote:
> @@ -69,7 +69,7 @@ struct lt9611uxc {
> static const struct regmap_range_cfg lt9611uxc_ranges[] = {
> {
> .name = "register_range",
> -
On Fri, Jan 17, 2025 at 03:50:09PM +0100, Maxime Ripard wrote:
> On Thu, Jan 16, 2025 at 12:34:12PM +0100, Simona Vetter wrote:
> > On Wed, Jan 15, 2025 at 10:05:29PM +0100, Maxime Ripard wrote:
> > > All the bridge atomic hooks were using the old_bridge_state name for
> > > their drm_bridge_state
On Fri, Jan 17, 2025 at 04:11:31PM +0100, Simona Vetter wrote:
> On Wed, Jan 08, 2025 at 12:02:03AM +, Deucher, Alexander wrote:
> > [Public]
> >
> > > -Original Message-
> > > From: Sasha Levin
> > > Sent: Thursday, January 2, 2025 7:42 PM
> > > To: stable-comm...@vger.kernel.org; ou
On Fri, Jan 17, 2025 at 04:11:31PM +0100, Simona Vetter wrote:
> On Wed, Jan 08, 2025 at 12:02:03AM +, Deucher, Alexander wrote:
> > [Public]
> >
> > > -Original Message-
> > > From: Sasha Levin
> > > Sent: Thursday, January 2, 2025 7:42 PM
> > > To: stable-comm...@vger.kernel.org; ou
On Wed, Jan 08, 2025 at 12:02:03AM +, Deucher, Alexander wrote:
> [Public]
>
> > -Original Message-
> > From: Sasha Levin
> > Sent: Thursday, January 2, 2025 7:42 PM
> > To: stable-comm...@vger.kernel.org; oushixi...@kylinos.cn
> > Cc: Deucher, Alexander ; Koenig, Christian
> > ; Pan,
On Thu, Jan 16, 2025 at 12:34:12PM +0100, Simona Vetter wrote:
> On Wed, Jan 15, 2025 at 10:05:29PM +0100, Maxime Ripard wrote:
> > All the bridge atomic hooks were using the old_bridge_state name for
> > their drm_bridge_state parameter. However, this state is the current
> > state being committed
On Wed, Jan 15, 2025 at 11:06:53AM +0100, Christian König wrote:
> Am 15.01.25 um 09:55 schrieb Simona Vetter:
> > > > If we add something
> > > > new, we need clear rules and not just "here's the kvm code that uses
> > > > it".
> > > > That's how we've done dma-buf at first, and it was a terrible
On Fri, Jan 17, 2025 at 03:17:32PM +0100, Sasha Finkelstein wrote:
> On Fri, 17 Jan 2025 at 11:24, Maxime Ripard wrote:
> > >
> > > I was thinking about using drmm_ here, as the DRM device is also created
> > > and destroyed each time. But I might be mistaken here.
> >
> > Ah, right, it makes sens
On Thu, Jan 16, 2025 at 12:07:47PM -0400, Jason Gunthorpe wrote:
> On Thu, Jan 16, 2025 at 04:13:13PM +0100, Christian König wrote:
> >> But this, fundamentally, is importers creating attachments and then
> >> *ignoring the lifetime rules of DMABUF*. If you created an attachment,
> >> got a move an
On Thu, 16 Jan 2025 15:25:56 +0100, Louis-Alexis Eyraud wrote:
> This patchset adds the support of the ARM Mali G57 MC2 GPU (Valhall-JM,
> dual core), integrated in the Mediatek MT8370 SoC, to the panfrost driver
> and to the mt8370.dtsi include file.
>
> I've testing this patchset on a Mediatek
On Fri, Jan 17, 2025 at 04:09:58PM +0200, Andy Shevchenko wrote:
> On Fri, Jan 17, 2025 at 02:57:52PM +0100, Marek Szyprowski wrote:
> > On 16.01.2025 13:42, Andy Shevchenko wrote:
> > > If the selector register is represented in each page, its value
> > > in accordance to the debugfs is stale beca
On Fri, Jan 17, 2025 at 02:57:52PM +0100, Marek Szyprowski wrote:
> On 16.01.2025 13:42, Andy Shevchenko wrote:
> > If the selector register is represented in each page, its value
> > in accordance to the debugfs is stale because it gets synchronized
> > only after the real page switch happens. Syn
On Thu, Jan 16, 2025 at 03:51:03PM -0800, Belgaumkar, Vinay wrote:
>
> On 1/16/2025 2:57 PM, Rodrigo Vivi wrote:
> > On Fri, Jan 10, 2025 at 03:21:51PM -0800, Vinay Belgaumkar wrote:
> > > Default SLPC power profile is Base(0). Power Saving mode(1)
> > > has conservative up/down thresholds and is
On Fri, 17 Jan 2025 at 11:24, Maxime Ripard wrote:
> >
> > I was thinking about using drmm_ here, as the DRM device is also created
> > and destroyed each time. But I might be mistaken here.
>
> Ah, right, it makes sense then, thanks!
> Maxime
Not sure i understand. The drm device is created in p
On Wed, Jan 15, 2025 at 12:20:07PM +, Daniel Stone wrote:
> On Wed, 15 Jan 2025 at 04:05, Marek Olšák wrote:
> > On Tue, Jan 14, 2025 at 12:58 PM Daniel Stone wrote:
> >> AMD hardware is the only hardware I know of which doesn't support
> >> overaligning. Say (not hypothetically) we have a GP
Dear All,
On 16.01.2025 13:42, Andy Shevchenko wrote:
> If the selector register is represented in each page, its value
> in accordance to the debugfs is stale because it gets synchronized
> only after the real page switch happens. Synchronize cache for
> the page selector.
>
> Before (offset foll
Hi,
On Thu, Dec 05, 2024 at 03:17:57PM -0800, John Stultz wrote:
> On Tue, Dec 3, 2024 at 11:04 AM Andrew Davis wrote:
> > On 12/3/24 1:44 AM, Maxime Ripard wrote:
> > > On Mon, Dec 02, 2024 at 11:12:23AM -0800, John Stultz wrote:
> > >> Hrm. I'm not sure I see the value in enumerating things in
On Fri, Jan 17, 2025 at 09:57:40AM +0800, Baolu Lu wrote:
> On 1/15/25 21:01, Jason Gunthorpe wrote:
> > On Wed, Jan 15, 2025 at 11:57:05PM +1100, Alexey Kardashevskiy wrote:
> > > On 15/1/25 00:35, Jason Gunthorpe wrote:
> > > > On Tue, Jun 18, 2024 at 07:28:43AM +0800, Xu Yilun wrote:
> > > >
>
Hi Tomi,
On 15/01/25 13:47, Tomi Valkeinen wrote:
> Hi,
>
> On 14/01/2025 18:32, Aradhya Bhatia wrote:
>
>>> But generally speaking, yes, it's good to keep fixes simple, and do
>>> cleanups later on top. Keeping that in mind, maybe this current patch is
>>> fine as it is. Although... if the init
Hi Dmitry,
On 14/01/25 16:54, Dmitry Baryshkov wrote:
> On Tue, Jan 14, 2025 at 11:26:25AM +0530, Aradhya Bhatia wrote:
>> Move the bridge pre_enable call before crtc enable, and the bridge
>> post_disable call after the crtc disable.
>>
>> The sequence of enable after this patch will look like:
>
On Thu, 16 Jan 2025 18:47:15 +0100, Louis Chauvet wrote:
> Add drmm_alloc_ordered_workqueue(), a helper that provides managed ordered
> workqueue cleanup. The workqueue will be destroyed with the final
> reference of the DRM device.
>
> Reviewed-by: Thomas Zimmermann
>
> [ ... ]
Reviewed-by: Ma
On Thu, 16 Jan 2025 10:56:35 +0100, Geert Uytterhoeven wrote:
> When adding the Device memory controller (DMEM), "select PAGE_COUNTER"
> was added to CGROUP_RDMA, presumably instead of CGROUP_DMEM.
> While commit e33b51499a0a6bca ("cgroup/dmem: Select PAGE_COUNTER") added
> the missing select to CG
On Fri, Jan 17, 2025 at 11:40:15AM +, Simon Ser wrote:
> On Friday, January 17th, 2025 at 12:32, Ville Syrjälä
> wrote:
>
> > > + * When used with atomic uAPI, one event will be delivered per CRTC
> > > included in
> > > + * the atomic commit. A CRTC is included in an atomic commit if one o
On Friday, January 17th, 2025 at 12:32, Ville Syrjälä
wrote:
> > + * When used with atomic uAPI, one event will be delivered per CRTC
> > included in
> > + * the atomic commit. A CRTC is included in an atomic commit if one of its
> > + * properties is set, or if a property is set on a connector
On Thu, Jan 16, 2025 at 04:25:35PM +, Simon Ser wrote:
> It's not obvious off-hand which CRTCs will get a page-flip event
> when using this flag in an atomic commit, because it's all
> implicitly implied based on the contents of the atomic commit.
> Document requirements for using this flag and
On Fri, Jan 17, 2025 at 12:01:01PM +0100, Uwe Kleine-König wrote:
> On Sun, Jan 12, 2025 at 10:06:42PM +0100, Greg KH wrote:
> > That's fine, the issue is that you are the only ones with "duplicate"
> > commits in the tree that are both tagged for stable, every release.
>
> Isn't a solution as eas
On Thu, 16 Jan 2025 16:25:35 +
Simon Ser wrote:
> It's not obvious off-hand which CRTCs will get a page-flip event
> when using this flag in an atomic commit, because it's all
> implicitly implied based on the contents of the atomic commit.
> Document requirements for using this flag and
>
On Sun, Jan 12, 2025 at 10:06:42PM +0100, Greg KH wrote:
> That's fine, the issue is that you are the only ones with "duplicate"
> commits in the tree that are both tagged for stable, every release.
Isn't a solution as easy as teaching your tooling not to create/accept
commits on -next with Cc: st
Hi
Am 14.01.25 um 22:38 schrieb Sasha Finkelstein via B4 Relay:
[...]
+
+static int adp_setup_mode_config(struct adp_drv_private *adp)
+{
+ struct drm_device *drm = &adp->drm;
+ int ret;
+ u32 size;
+
+ ret = drmm_mode_config_init(drm);
+ if (ret)
+ r
Gens 4 to 6 and Gen7 use the same pattern for detecting the installed
TX chips. Merge the code into a single branch.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_main.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_
Reorganize ast_post_gpu() so that it first branches by Gen and then
by config mode and TX chip. This will later make it possible to split
up the function by Gen.
The helper ast_init_3rdtx() only handles Gen4 and Gen5, so leave it
out from the other Gens.
Signed-off-by: Thomas Zimmermann
---
dri
Move DRAM detection before TX-chip detection. Both steps are independent
from each other. Detection of the TX-chip is now next to posting those
chips, which can be done in a single step.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_main.c | 4 +---
1 file changed, 1 insertion(+),
Detection and initialization of TX chips is mixed up with each other
and other device-probing code. Move it into one place and reorganize
branches by Aspeed Gen.
This series is another step towards separating the TX code from the
rest of the driver and making each hardware gen self-contained.
Tes
Remove the call to ast_dp_launch() from ast_detect_tx_chip() and
perform it unconditionally in ast_post_gpu().
Also add error handling: the detection code apparently used
ast_dp_launch() to test for a working ASTDP, falling back to VGA on
errors. As the VBIOS reports ASTDP, silently ignoring error
Gen7 only supports ASTDP. Gens 4 to 6 support various TX chips,
except ASTDP. These boards detect the TX chips by reading the SoC
scratch register as VGACRD1.
Gens 1 to 3 only support SIL164. These boards read the DVO bit from
VGACRA3. Hence move this test behind a branch, so that it does not
run
Wide-screen support is relevant for mode validation. Do not detect it
before setting up the mode-setting pipeline. Gets the function call out
of the way of other initialization code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 d
Align variable names and register constants for TX-chip detection
to the names in the register manual.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_main.c | 6 +++---
drivers/gpu/drm/ast/ast_reg.h | 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/
Only Gen4 and later read the installed TX chip from the SoC. So only
warn on those generations about unsupported chips.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_main.c | 40 +++---
1 file changed, 22 insertions(+), 18 deletions(-)
diff --git a/dri
On Fri, Jan 17, 2025 at 05:43:57AM +0200, Dmitry Baryshkov wrote:
> On Thu, Jan 16, 2025 at 05:01:03PM +0100, Maxime Ripard wrote:
> > Hi Dmitry,
> >
> > On Wed, Jan 15, 2025 at 12:21:39PM +0200, Dmitry Baryshkov wrote:
> > > On Tue, Jan 14, 2025 at 10:38:53PM +0100, Sasha Finkelstein via B4 Relay
Hi,
On Thu, Jan 16, 2025 at 07:52:30PM +0100, Sasha Finkelstein wrote:
> On Wed, 15 Jan 2025 at 11:21, Dmitry Baryshkov
> wrote:
> > > + ret = drm_simple_encoder_init(drm, &adp->encoder,
> > > DRM_MODE_ENCODER_DSI);
> >
> > This is being deprecated, please use drm_encoder_init() /
> > drmm_e
Applied to drm-misc-next
On 1/14/2025 9:44 AM, Jacek Lawrynowicz wrote:
> Slawek moved to another project and Maciej will be replacing him.
>
> Signed-off-by: Jacek Lawrynowicz
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINER
+ enum drm_mode_subconnector subtype;
/**
* @interlace_allowed: Indicate that the bridge can handle interlaced
* modes.
---
base-commit: 8defad9f57376a89914d16757717a27b567de04e
change-id: 20250117-subconnector-246b6fe49488
Best regards,
--
Dmitry Baryshkov
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 because the xe_drm_pagemap_map_dma() and
xe_devm_add() functions were buil
On Thu, 19 Dec 2024 21:33:49 -0700
Alex Hung wrote:
> From: Harry Wentland
>
> Add kernel doc for AMD color pipeline.
>
> Signed-off-by: Alex Hung
> Signed-off-by: Harry Wentland
> ---
> .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 122 +++---
> 1 file changed, 102 insertions
1 - 100 of 131 matches
Mail list logo
