> Add DPCD registers required to configure Extended Wake Timeout for LTTPR.
>
> Signed-off-by: Suraj Kandpal
> ---
Reviewed-by: Arun R Murthy
Thanks and Regards,
Arun R Murthy
> include/drm/display/drm_dp.h | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff
From: Shixiong Ou
Signed-off-by: Shixiong Ou
---
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
index a7a6b70220eb..33f81b53771d 100644
--- a/drivers
On 17.01.2025 18:28, Andy Shevchenko wrote:
> 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 17.01.2025 18:28, Andy Shevchenko wrote:
> 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:
From: Hermes Wu
Fix a typo where V compare incorrectly compares av[] with av[] itself,
which can result in HDCP failure.
The loop of V compare is expected to iterate for 5 times
which compare V array form av[0][] to av[4][].
It should check loop counter reach the last statement "i == 5"
before r
From: Shixiong Ou
Signed-off-by: Shixiong Ou
---
drivers/video/fbdev/sh_mobile_lcdcfb.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c
b/drivers/video/fbdev/sh_mobile_lcdcfb.c
index 6b37b188af31..69c9067eff88 100644
--- a/drivers
> > On Thu, Jan 16, 2025 at 01:33:43PM +, Murthy, Arun R wrote:
> > > > On Thu, Jan 16, 2025 at 12:33:20PM +, Murthy, Arun R wrote:
> > > > > > > > On Fri, Jan 10, 2025 at 01:15:29AM +0530, Arun R Murthy wrote:
> > > > > > > > > Display Histogram is an array of bins and can be
> > > > > > >
The hdptxphy is a combo transmit-PHY for HDMI2.1 TMDS Link, FRL Link, DP
and eDP Link. Therefore, it is better to name it hdptxphy0 other than
hdptxphy_hdmi0, which will be referenced by both hdmi0 and edp0 nodes.
Signed-off-by: Damon Ding
---
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
The hdptxphy is a combo transmit-PHY for HDMI2.1 TMDS Link, FRL Link, DP
and eDP Link. Therefore, it is better to name it hdptxphy0 other than
hdptxphy_hdmi0, which will be referenced by both hdmi0 and edp0 nodes.
Acked-by: Rob Herring (Arm)
Signed-off-by: Damon Ding
---
.../bindings/display/ro
The PHY is based on a Samsung IP block that supports HDMI 2.1, and eDP
1.4b. RK3588 integrates the Analogix eDP 1.3 TX controller IP and the
HDMI/eDP TX Combo PHY to support eDP display.
Add basic support for RBR/HBR/HBR2 link rates, and the voltage swing and
pre-emphasis configurations of each li
Adding the '_MASK' suffix to all registers in order to ensures consistency
in the naming convention for register macros throughout the file.
Signed-off-by: Damon Ding
Reviewed-by: Dmitry Baryshkov
---
Changes in v4:
- Split the older patch related to the renaming of registers into three
diff
Complete the register names of CMN_REG(0081) and CMN_REG(0087) to their
full version, and it can help to better match the datasheet.
Signed-off-by: Damon Ding
Reviewed-by: Dmitry Baryshkov
---
drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 6 +++---
1 file changed, 3 insertions(+), 3 delet
According to the datasheet, setting the dig_clk_sel bit of CMN_REG(0097)
to 1'b1 selects LCPLL as the reference clock, while setting it to 1'b0
selects the ROPLL.
Signed-off-by: Damon Ding
Reviewed-by: Dmitry Baryshkov
---
drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 4 ++--
1 file chang
Picked from:
https://patchwork.kernel.org/project/linux-rockchip/list/?series=923593
These patchs have been tested with a 1536x2048p60 eDP panel on
RK3588S EVB1 board, and HDMI 1080P/4K display also has been verified
on RK3588 EVB1 board.
Damon Ding (6):
phy: phy-rockchip-samsung-hdptx: Swap th
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
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
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
Add DPCD registers required to configure Extended Wake Timeout
for LTTPR.
Signed-off-by: Suraj Kandpal
---
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
index a6f8b098c56f..480370bba1de
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
On Mon, Jan 20, 2025 at 09:25:25AM -0400, Jason Gunthorpe wrote:
> On Mon, Jun 24, 2024 at 03:59:53AM +0800, Xu Yilun wrote:
> > > But it also seems to me that VFIO should be able to support putting
> > > the device into the RUN state
> >
> > Firstly I think VFIO should support putting device into
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-by: Youssef Samir
> Signed-off-by: Youssef Sa
On Fri, Jan 17, 2025 at 10:09:38AM -0700, Jeffrey Hugo wrote:
> 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 tra
On Fri, Jan 17, 2025 at 10:09:37AM -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 protocol from the firmware being loaded and th
> -Original Message-
> From: Dmitry Baryshkov
> Sent: Friday, January 17, 2025 11:50 AM
> To: Kandpal, Suraj
> Cc: intel...@lists.freedesktop.org; intel-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; Murthy, Arun R
> Subject: Re: [PATCH 2/2] drm/i915/lttpr: Enable Exte
Marijn Suijten 于2025年1月20日周一 04:58写道：
>
> On 2025-01-17 15:32:44, Jun Nie wrote:
> > Dmitry Baryshkov 于2025年1月16日周四 16:32写道：
> > >
> > > On Thu, Jan 16, 2025 at 03:26:05PM +0800, Jun Nie wrote:
> > > > Request 4 mixers and 4 DSC for the case that both dual-DSI and DSC are
> > > > enabled.
> > >
>
> 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-by: Arun R Murthy
> > ---
> > drivers/gpu/drm/i915/display/skl_universal_
> +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 apps that aren't the one trying to recover the GPU.
Is this just about
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 required to
recover the GPU.
Making it also survive the rebind properly is mo
Marijn Suijten 于2025年1月20日周一 05:15写道：
>
> On 2025-01-18 00:00:51, Jun Nie wrote:
> > There are 2 interfaces and 4 pingpong in quad pipe. Map the 2nd
> > interface to 3rd PP instead of the 2nd PP.
>
> Can you explain why this patch uses the number of LMs, instead of dividing the
> number of PPs div
Some SoCs such as SC7280 (used in the FairPhone 5) have only a single
DSC "hard slice" encoder. The current hardcoded use of 2:2:1 topology
(2 LM and 2 DSC for a single interface) make it impossible to use
Display Stream Compression panels with mainline, which is exactly what's
installed on the Fa
On Mon, Jan 20, 2025 at 11:03 PM Link Mauve wrote:
>
> when building with today’s nightly compiler (maybe that’s relevant?).
Ah, that explains it! The type changes with beta (1.85.0), and I can
also reproduce it in CE.
We should probably try to backport the cleanups we did before the
remapping,
Hi Christian,
kernel test robot noticed the following build errors:
[auto build test ERROR on linus/master]
[also build test ERROR on v6.13 next-20250120]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as
On Mon, Jan 20, 2025 at 10:52:48PM +0100, Miguel Ojeda wrote:
> Hi Emmanuel,
Hi Miguel,
>
> On Mon, Jan 20, 2025 at 1:45 PM Emmanuel Gil Peyrot
> wrote:
> >
> > In C, the char type is specified with “The implementation shall define char
> > to
> > have the same range, representation, and behav
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 +, Simona Vetter wrote:
> >>
Hi Emmanuel,
On Mon, Jan 20, 2025 at 1:45 PM Emmanuel Gil Peyrot
wrote:
>
> In C, the char type is specified with “The implementation shall define char to
> have the same range, representation, and behavior as either signed char or
> unsigned char.”
>
> On x86 it defaults to signed char, and on A
On Tue, Dec 17, 2024 at 11:13:05AM +0100, Michel Dänzer wrote:
> On 2024-12-17 10:14, Brian Starkey wrote:
> > On Sun, Dec 15, 2024 at 03:53:14PM +, Marek Olšák wrote:
> >> The comment explains the problem with DRM_FORMAT_MOD_LINEAR.
> >>
> >> Signed-off-by: Marek Olšák
> >>
> >> diff --git a/
On Mon, Jan 20, 2025 at 08:58:20AM +0100, Thomas Zimmermann wrote:
> 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 is what we do today. Even if Intel and some AMD chips
> > can do 64B or 128B ali
Some minor comments below, apart from that looks good!
Typo in the commit title: s/supports/support/
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 5ef87cb5b242..316c643e0dea 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -913
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-by: Arun R Murthy
> ---
> drivers/gpu/drm/i915/display/skl_universal_plane.c | 51
On Wed, Jan 08, 2025 at 11:09:00AM +0530, Arun R Murthy wrote:
> Expose drm plane function to create formats/modifiers blob. This
> function can be used to expose list of supported formats/modifiers for
> sync/async flips.
>
> Signed-off-by: Arun R Murthy
> ---
> drivers/gpu/drm/drm_plane.c | 44
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 with your email? You replied to Simona, but
> > Simona Vetter is dropped fr
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 with your email? You replied to Simona, but
> Simona Vetter is dropped from the To/CC
> list??? I added the address back, but seems like a weird
Am 20.01.25 um 18:13 schrieb Danilo Krummrich:
On Mon, Jan 20, 2025 at 04:52:37PM +, Tvrtko Ursulin wrote:
Idea is to add a helper for popping jobs from the entity with the goal
of making amdgpu use it in the next patch. That way amdgpu will decouple
itself a tiny bit more from scheduler imp
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 is what we do today. Even if Intel and some AMD chips
> > can do 64B o
On Mon, Jan 20, 2025 at 01:14:12PM +0100, Christian König wrote:
What is going wrong with your email? You replied to Simona, but
Simona Vetter is dropped from the To/CC
list??? I added the address back, but seems like a weird thing to
happen.
> Please take another look at what is proposed here.
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, Dmitry Baryshkov wrote:
>>> On Tue, Jan 14, 2025 at 11:26:25AM +0530, Aradhya Bhatia wrote:
Move the bridge pre_enable call before crt
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 VKMS (configFS),
> > it will be easier to have one allocation per CRTC.
> >
> > Reviewed-by: Maxime Ripard
> > Signed-of
VO clocks reside in a different address space from the AP clocks on the
T-HEAD SoC. Add the device tree node of a clock-controller to handle
VO address space as well.
Signed-off-by: Michal Wilczynski
---
arch/riscv/boot/dts/thead/th1520.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --g
Add mailbox device tree node. This work is based on the vendor kernel [1].
Link: https://github.com/revyos/thead-kernel.git [1]
Reviewed-by: Drew Fustini
Signed-off-by: Michal Wilczynski
---
arch/riscv/boot/dts/thead/th1520.dtsi | 16
1 file changed, 16 insertions(+)
diff --g
Several RISC-V boards feature Imagination GPUs that are compatible with
the PowerVR driver. An example is the IMG BXM-4-64 GPU on the Lichee Pi
4A board. This commit adjusts the driver's Kconfig dependencies to allow
the PowerVR driver to be compiled on the RISC-V architecture.
By enabling compila
The DRM Imagination GPU requires a power-domain driver. In the T-HEAD
TH1520 SoC implements power management capabilities through the E902
core, which can be communicated with through the mailbox, using firmware
protocol.
Add AON node, which servers as a power-domain controller.
Signed-off-by: Mi
Add a device tree node for the IMG BXM-4-64 GPU present in the T-HEAD
TH1520 SoC used by the Lichee Pi 4A board. This node enables support for
the GPU using the drm/imagination driver.
By adding this node, the kernel can recognize and initialize the GPU,
providing graphics acceleration capabilitie
T-HEAD TH1520 SoC requires to put the GPU out of the reset state as part
of the power-up sequence.
Signed-off-by: Michal Wilczynski
---
arch/riscv/boot/dts/thead/th1520.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/riscv/boot/dts/thead/th1520.dtsi
b/arch/riscv/boot/dts/the
Add a new SoC-specific compatible ("thead,th1520-gpu") for the T-HEAD
TH1520 GPU, alongside the Imagination BXM family compatible
("img,img-bxm"). This documents the GPU integration on the T-HEAD
platform.
Also adjust clock name constraints to accommodate a second clock named
"sys" instead of "me
Certain platforms, such as the T-Head TH1520 and Banana Pi BPI-F3,
require a controlled GPU reset sequence during the power-up procedure
to ensure proper initialization. Without this reset, the GPU may remain
in an undefined state, potentially leading to stability or performance
issues.
This commi
Introduce reset controller driver for the T-HEAD TH1520 SoC. The
controller manages hardware reset lines for various SoC subsystems, such
as the GPU. By exposing these resets via the Linux reset subsystem,
drivers can request and control hardware resets to reliably initialize
or recover key compone
The T-Head TH1520 SoC integrates a variety of clocks for its subsystems,
including the Application Processor (AP) and the Video Output (VO) [1].
Up until now, the T-Head clock driver only supported AP clocks.
This commit extends the driver to provide clock functionality for the VO
subsystem. At th
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.
Signed-off-by: Michal Wilczynski
---
.../bindings/reset/thead,th1520-reset.yaml| 44 +++
MAINTAINERS
T-Head SoCs feature separate power domains (power islands) for major
components like the GPU, Audio, and NPU. To manage the power states of
these components effectively, the kernel requires generic power domain
support.
This commit enables `CONFIG_PM_GENERIC_DOMAINS` for T-Head SoCs,
allowing the
The IMG BXM-4-64 GPU is integrated into the T-Head TH1520 SoC. This
commit adds the compatible string "img,img-bxm" to the device tree match
table in the drm/imagination driver, enabling support for this GPU.
By including this GPU in the compatible devices list, the driver can
initialize and manag
The kernel communicates with the E902 core through the mailbox
transport using AON firmware protocol. Add dt-bindings to document it
the dt node.
Signed-off-by: Michal Wilczynski
---
.../bindings/firmware/thead,th1520-aon.yaml | 53 +++
MAINTAINERS
Many RISC-V boards featuring Imagination Technologies GPUs require a
reset line to be de-asserted as part of the GPU power-up sequence. To
support this, add a 'resets' property (and corresponding 'reset-names')
to the GPU device tree bindings. This ensures the GPU can be properly
initialized on the
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 relevant mailbox driver has already been
merged into the mainline kernel in commit 5d4d263e1c6b ("mailbox:
Introduce support for T-
The T-Head TH1520 SoC uses an E902 co-processor running Always-On (AON)
firmware to manage power, clock, and other system resources [1]. This
patch introduces a driver implementing the AON firmware protocol,
allowing the Linux kernel to communicate with the firmware via mailbox
channels. Through a
Add a separate compatible string "thead,th1520-clk-vo" to describe the
Video Output (VO) subsystem clock controller in the T-Head TH1520 SoC.
The VO subsystem configures the clock gates for HDMI, MIPI, and GPU
components. Meanwhile, the existing AP sub-system clock controller
remains responsible fo
The LicheePi 4A board, featuring the T-HEAD TH1520 SoC, includes an Imagination
Technologies BXM-4-64 GPU. Initial support for this GPU was provided through a
downstream driver [1]. Recently, efforts have been made to upstream support for
the Rogue family GPUs, which the BXM-4-64 is part of [2].
W
On Mon, Jan 20, 2025 at 04:52:39PM +, Tvrtko Ursulin wrote:
> The code assumes queue node is the first element in struct
> drm_sched_job.
I'd add that this assumption lies in doing the NULL check after the
container_of(). Without saying that, it might not be that obvious.
> Since this is not
On Mon, Jan 20, 2025 at 04:52:37PM +, Tvrtko Ursulin wrote:
> Idea is to add a helper for popping jobs from the entity with the goal
> of making amdgpu use it in the next patch. That way amdgpu will decouple
> itself a tiny bit more from scheduler implementation details.
I object to adding thi
Extract out two copies of the identical code to function epilogue to make
it smaller and more readable.
Signed-off-by: Tvrtko Ursulin
Cc: Christian König
Cc: Danilo Krummrich
Cc: Matthew Brost
Cc: Philipp Stanner
---
drivers/gpu/drm/scheduler/sched_main.c | 48 +++---
1 f
Rq->lock only protects the tree walk so lets move the rest out.
Signed-off-by: Tvrtko Ursulin
Cc: Christian König
Cc: Danilo Krummrich
Cc: Matthew Brost
Cc: Philipp Stanner
---
drivers/gpu/drm/scheduler/sched_main.c | 31 ++
1 file changed, 17 insertions(+), 14 deleti
Two patches extracted from my deadline scheduler RFC. I think they are making
the entity selection logic a bit easier on the eyes but as opinions may vary
please have a look and see what you think.
Cc: Christian König
Cc: Danilo Krummrich
Cc: Matthew Brost
Cc: Philipp Stanner
Tvrtko Ursulin (
On Mon, Jan 20, 2025 at 12:46 AM Chen-Yu Tsai wrote:
>
> On Sun, Jan 19, 2025 at 5:24 AM Jassi Brar wrote:
> >
> > On Thu, Dec 19, 2024 at 11:08 AM Jason-JH.Lin
> > wrote:
> > >
> > > 1. Add compatible name and iommus property to mediatek,gce-mailbox.yaml
> > >for MT8196.
> > >
> > >- T
The code assumes queue node is the first element in struct
drm_sched_job. Since this is not documented it can be very fragile so lets
just remove the internal helper and explicitly check for "nothing
dequeued", before converting the node to a sched job.
Signed-off-by: Tvrtko Ursulin
Cc: Christian
Dependency tracking via xarray uses xa_limit_32b so there is not need for
the struct member to be unsigned long.
At the same time re-order some struct members and take u32 credits outside
of the pointer sandwich and avoid a hole.
Pahole report before:
/* size: 160, cachelines: 3, members:
Amdgpu is the only driver which peeks into scheduler internals in this way
so lets make it use the previously added helper. This allows removing the
local copy of the to_drm_sched_job macro.
Signed-off-by: Tvrtko Ursulin
Cc: Christian König
Cc: Danilo Krummrich
Cc: Matthew Brost
Cc: Philipp St
At one point I thought I wanted to add a member to struct drm_sched_job. As I
noticed there is a hole in the struct, I went to re-order some members to get
rid of it (the hole), at which point I was greeted by a subtle bug cause by the
frequent pattern of:
job = to_drm_sched_job(spsc_queue_peek|p
Idea is to add a helper for popping jobs from the entity with the goal
of making amdgpu use it in the next patch. That way amdgpu will decouple
itself a tiny bit more from scheduler implementation details.
Signed-off-by: Tvrtko Ursulin
Cc: Christian König
Cc: Danilo Krummrich
Cc: Matthew Brost
> A specific allocation for the CRTC is not strictly necessary at this
> point, but in order to implement dynamic configuration of VKMS (configFS),
> it will be easier to have one allocation per CRTC.
>
> Reviewed-by: Maxime Ripard
> Signed-off-by: Louis Chauvet
> ---
> drivers/gpu/drm/vkms/vkm
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önig wrote:
Granted, let me try to improve this.
Here is a real world examp
Hi Jyothi,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 55bcd2e0d04c1171d382badef1def1fd04ef66c5]
url:
https://github.com/intel-lab-lkp/linux/commits/Jyothi-Kumar-Seerapu/dmaengine-qcom-gpi-Add-GPI-Block-event-interrupt-support/20250120-180058
base
On Mon, Jan 20, 2025 at 08:45:51PM +1100, Alexey Kardashevskiy wrote:
> > For CC I'm expecting the KVM fd to be the handle for the cVM, so any
> > RPCs that want to call into the secure world need the KVM FD to get
> > the cVM's identifier. Ie a "bind to cVM" RPC will need the PCI
> > information
On Mon, Jun 24, 2024 at 03:59:53AM +0800, Xu Yilun wrote:
> > But it also seems to me that VFIO should be able to support putting
> > the device into the RUN state
>
> Firstly I think VFIO should support putting device into *LOCKED* state.
> From LOCKED to RUN, there are many evidence fetching and
Hi, I already have DT binding for my panel.Please help review the patch for
V4. Thank you very much.
On Thu, Jan 16, 2025 at 10:04 PM Dmitry Baryshkov <
dmitry.barysh...@linaro.org> wrote:
> On Thu, Jan 16, 2025 at 09:05:30PM +0800, Langyan Ye wrote:
> > The kingdisplay-kd110n11-51ie and starry-2
This is a DSI bridge, so set the bridge type accordingly.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/nwl-dsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index 1e5b2a37cb8c9..6f2581e0034b4 100644
--- a/dr
This is a DSI to LVDS bridge, so set the bridge type accordingly.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index 336380114eea9..9e959
On 2025-01-18 00:00:51, Jun Nie wrote:
> There are 2 interfaces and 4 pingpong in quad pipe. Map the 2nd
> interface to 3rd PP instead of the 2nd PP.
Can you explain why this patch uses the number of LMs, instead of dividing the
number of PPs divided by the number of physical encoders? This detai
On 2025-01-17 15:32:44, Jun Nie wrote:
> Dmitry Baryshkov 于2025年1月16日周四 16:32写道：
> >
> > On Thu, Jan 16, 2025 at 03:26:05PM +0800, Jun Nie wrote:
> > > Request 4 mixers and 4 DSC for the case that both dual-DSI and DSC are
> > > enabled.
> >
> > Why? What is the issue that you are solving?
>
>
Il 18/01/25 17:06, Krzysztof Kozlowski ha scritto:
mediatek_mt8192_supplies are exactly the same as
mediatek_mt8183_b_supplies. mediatek_mt8188_data is exactly the same as
&mediatek_mt8183_b_data. There is never point in duplicating all these
structures - it only raises questions or encourages
In C, the char type is specified with “The implementation shall define char to
have the same range, representation, and behavior as either signed char or
unsigned char.”
On x86 it defaults to signed char, and on ARM it defaults to unsigned char.
This carries over to Rust’s FFI, which aliases its c
From: Pierre-Eric Pelloux-Prayer
commit 6fb15dcbcf4f212930350eaee174bb60ed40a536 upstream.
The call to radeon_vm_clear_freed might clear bo_va->bo, so
we have to check it before dereferencing it.
Signed-off-by: Pierre-Eric Pelloux-Prayer
Acked-by: Alex Deucher
Signed-off-by: Alex Deucher
[De
Il 17/01/25 23:04, kernel test robot ha scritto:
Hi AngeloGioacchino,
kernel test robot noticed the following build warnings:
CK, if there's no other concern about this submission, and you deem it ready to
be applied - can you please resolve this error while applying by adding
`#include ` b
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 polarity. Bit 1 is reserved, and should
Am 17.01.25 um 15:42 schrieb Simona Vetter:
On Wed, Jan 15, 2025 at 11:06:53AM +0100, Christian König wrote:
[SNIP]
Anything missing?
Well as far as I can see this use case is not a good fit for the DMA-buf
interfaces in the first place. DMA-buf deals with devices and buffer
exchange.
What's
Am 16.01.25 um 15:28 schrieb Maarten Lankhorst:
When testing on my tiled display, initially the tiled display is
detected correctly:
[90376.523692] xe :67:00.0: [drm:drm_client_firmware_config.isra.0 [drm]]
fallback: Not all outputs enabled
[90376.523713] xe :67:00.0: [drm:drm_client
Hi
Am 16.01.25 um 15:28 schrieb Maarten Lankhorst:
Tiled displays have a different x/y offset to begin with. Instead of
attempting to remember this, just apply a delta instead.
Hope this works..
As far as I understand the tile code, this makes sense.
Signed-off-by: Maarten Lankhorst
Ac
On Mon, 20 Jan 2025, Lu Yao wrote:
> Add null pointer check before use fb.
> Reported by smatch.
If new_plane_state->uapi.visible is true, fb will be non-NULL too, but
smatch is unable to see that.
Adding these checks makes one believe that this is not something you can
rely on.
BR,
Jani.
>
>
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
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mai
On 17/01/2025 11:29, Thomas Zimmermann wrote:
Gens 4 to 6 and Gen7 use the same pattern for detecting the installed
TX chips. Merge the code into a single branch.
Thanks, it looks good to me.
Reviewed-by: Jocelyn Falempe
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_main.c
On 17/01/2025 11:29, Thomas Zimmermann wrote:
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 thi
On 17/01/2025 11:29, Thomas Zimmermann wrote:
Align variable names and register constants for TX-chip detection
to the names in the register manual.
Thanks, it looks good to me.
Reviewed-by: Jocelyn Falempe
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_main.c | 6 +++---
1 - 100 of 121 matches
Mail list logo
