On Mon, Dec 02, 2024 at 02:20:04PM +0100, Maxime Ripard wrote:
> Hi,
>
> Sorry, I've been drowning under work and couldn't review that series before.
No worries, at this point I'm more concerned about my IGT series rather
than this one.
>
> I'll review the driver API for now, and we can focus o
Hi Christian,
Thanks for your patch!
On 02/12/24 11:06, Christian Gmeiner wrote:
From: Christian Gmeiner
Add a new ioctl, DRM_IOCTL_V3D_PERFMON_SET_GLOBAL, to allow
configuration of a global performance monitor (perfmon).
Use the global perfmon for all jobs to ensure consistent
performance tr
On 2024/12/3 20:00, Uwe Kleine-König wrote:
> Hello,
>
> On Tue, Dec 03, 2024 at 08:33:22AM +0800, Zijun Hu wrote:
>> This patch series is to constify the following API:
>> struct device *device_find_child(struct device *dev, void *data,
>> int (*match)(struct device *dev, void *data)
On Mon, Dec 02, 2024 at 02:27:49PM +0100, Maxime Ripard wrote:
> Hi,
>
> On Sun, Dec 01, 2024 at 02:44:13AM +0200, Dmitry Baryshkov wrote:
> > Use the helper function to update the connector's information. This
> > makes sure that HDMI-related events are handled in a generic way.
> > Currently it
On Tue, Dec 03, 2024 at 08:23:45PM +0800, Zijun Hu wrote:
> On 2024/12/3 20:00, Uwe Kleine-König wrote:
> > Hello,
> >
> > On Tue, Dec 03, 2024 at 08:33:22AM +0800, Zijun Hu wrote:
> >> This patch series is to constify the following API:
> >> struct device *device_find_child(struct device *dev, vo
Am 15.11.24 um 16:01 schrieb Thomas Hellström:
Provide a helper to shrink ttm_tt page-vectors on a per-page
basis. A ttm_backup backend could then in theory get away with
allocating a single temporary page for each struct ttm_tt.
This is accomplished by splitting larger pages before trying to
ba
On Tue, Dec 3, 2024 at 1:59 AM Danylo Piliaiev
wrote:
>
> This adds MSM_PARAM_UCHE_TRAP_BASE that will be used by Mesa
> implementation for VK_KHR_shader_clock and GL_ARB_shader_clock.
>
> Signed-off-by: Danylo Piliaiev
> ---
> drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 6 --
> drivers/gpu/d
On Tue, Dec 03, 2024 at 11:00:47AM +0530, Ekansh Gupta wrote:
> Memory intensive applications(which requires more tha 4GB) that wants
> to offload tasks to DSP might have to split the tasks to multiple
> user PD to make the resources available.
>
> For every call to DSP, fastrpc driver passes the
On Tue, 3 Dec 2024 at 07:22, Ekansh Gupta wrote:
>
>
>
> On 12/2/2024 6:18 PM, Dmitry Baryshkov wrote:
> > On Mon, Dec 02, 2024 at 03:27:43PM +0530, Ekansh Gupta wrote:
> >>
> >> On 11/22/2024 12:23 AM, Dmitry Baryshkov wrote:
> >>> On Thu, Nov 21, 2024 at 12:12:17PM +0530, Ekansh Gupta wrote:
> >
Hello,
On Tue, Dec 03, 2024 at 08:33:22AM +0800, Zijun Hu wrote:
> This patch series is to constify the following API:
> struct device *device_find_child(struct device *dev, void *data,
> int (*match)(struct device *dev, void *data));
> To :
> struct device *device_find_child(struct
Hi,
On 24/11/2024 16:36, Aradhya Bhatia wrote:
Hello all,
This patch series add support for the dual OLDI TXes supported in Texas
Instruments' AM62x and AM62Px family of SoCs. The OLDI TXes support single-lvds
lvds-clone, and dual-lvds modes. These have now been represented through DRM
bridges
On Tue, Dec 03, 2024 at 10:59:20AM +0100, Danylo Piliaiev wrote:
> This adds MSM_PARAM_UCHE_TRAP_BASE that will be used by Mesa
> implementation for VK_KHR_shader_clock and GL_ARB_shader_clock.
Could you please spend more words, describing what it is and why is it
necessary for those extensions. F
On 2024/12/3 20:41, Greg Kroah-Hartman wrote:
> On Tue, Dec 03, 2024 at 08:23:45PM +0800, Zijun Hu wrote:
>> On 2024/12/3 20:00, Uwe Kleine-König wrote:
>>> Hello,
>>>
>>> On Tue, Dec 03, 2024 at 08:33:22AM +0800, Zijun Hu wrote:
This patch series is to constify the following API:
struct
On Tue, Dec 03, 2024 at 02:09:59PM +0100, Danylo wrote:
>
>
>
> On 12/3/24 13:52, Dmitry Baryshkov wrote:
> > On Tue, Dec 03, 2024 at 10:59:20AM +0100, Danylo Piliaiev wrote:
> > > This adds MSM_PARAM_UCHE_TRAP_BASE that will be used by Mesa
> > > implementation for VK_KHR_shader_clock and GL_AR
On Tue, Dec 03, 2024 at 09:01:31AM +0100, Krzysztof Kozlowski wrote:
> On 03/12/2024 04:31, Abhinav Kumar wrote:
> > Document the assigned-clock-parents better for the DP controller node
> > to indicate its functionality better.
>
>
> You change the clocks entirely, not "document". I would say th
On Mon, Dec 02, 2024 at 07:31:41PM -0800, Abhinav Kumar wrote:
> On some chipsets the display port controller can support more
> than one pixel stream (multi-stream transport). To support MST
> on such chipsets, add the binding for stream 1 pixel clock for
> display port controller. Since this mode
Am 03.12.24 um 15:24 schrieb Oleksandr Natalenko:
On středa 13. listopadu 2024 14:48:38, středoevropský standardní čas Tvrtko
Ursulin wrote:
From: Tvrtko Ursulin
As commit 746ae46c1113 ("drm/sched: Mark scheduler work queues with
WQ_MEM_RECLAIM")
points out, ever since
a6149f039369 ("drm/sch
On 2024/12/3 22:07, Thomas Weißschuh wrote:
> On 2024-12-03 08:58:26-0500, James Bottomley wrote:
>> On Tue, 2024-12-03 at 21:02 +0800, Zijun Hu wrote:
>>> On 2024/12/3 20:41, Greg Kroah-Hartman wrote:
On Tue, Dec 03, 2024 at 08:23:45PM +0800, Zijun Hu wrote:
>> [...]
> or squash such patc
Am 03.12.24 um 14:42 schrieb Thomas Hellström:
On Tue, 2024-12-03 at 14:12 +0100, Christian König wrote:
Am 15.11.24 um 16:01 schrieb Thomas Hellström:
Provide a helper to shrink ttm_tt page-vectors on a per-page
basis. A ttm_backup backend could then in theory get away with
allocating a single
On Mon, Dec 02, 2024 at 12:41:59PM -0800, Abhinav Kumar wrote:
> MMSS_DP_INTF_CONFIG has already been setup by the main datapath
> for DP to account for widebus to be used/unused etc.
>
> In current implementation, TPG only switches the DP controller
> to use the main datapath stream OR use the te
On Tue, Dec 03, 2024 at 11:25:11AM +0530, Arun R Murthy wrote:
> Add variables for histogram drm_property, its corrsponding crtc_state
> variables and define the structure pointed by the blob property.
Missing description of the data format. How can other drivers implememt
it if the format is not
SST with 128b/132b channel coding needs this too. Extract to a separate
helper, independent of MST.
v2: Clean up kernel-doc a bit
Cc: Lyude Paul
Reviewed-by: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_helper.c | 57 +++
drivers/gpu/drm/displa
Add some mst topology manager independent payload helpers.
v2 of [1] with some kernel-doc cleanups.
BR,
Jani.
[1] https://lore.kernel.org/r/cover.1731942780.git.jani.nik...@intel.com
Jani Nikula (3):
drm/dp: extract drm_dp_dpcd_poll_act_handled()
drm/dp: extract drm_dp_dpcd_write_payload()
SST with 128b/132b channel coding needs this too. Extract to a separate
helper, independent of MST.
Pass timeout in as a parameter, anticipating that we can reduce the
timeout for SST.
v2: Clean up kernel-doc a bit
Cc: Lyude Paul
Reviewed-by: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/
SST with 128b/132b channel coding needs this too. Extract to a separate
helper, independent of MST.
Cc: Lyude Paul
Reviewed-by: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_helper.c | 14 ++
drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
inc
Hi Louis,
Patches 1 and 2:
Reviewed-by: José Expósito
I noticed a bug in this patch:
> 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.
>
> Sig
On Tue, 03 Dec 2024 14:41:31 +0100, Michal Wilczynski wrote:
> Add power domain support to the Thead TH1520 clock controller bindings.
> This enables devices to specify their power domain dependencies,
> improving power management for components like the GPU.
>
> Signed-off-by: Michal Wilczynski
On Tue, 2024-12-03 at 22:56 +0800, Zijun Hu wrote:
> On 2024/12/3 22:07, Thomas Weißschuh wrote:
> > On 2024-12-03 08:58:26-0500, James Bottomley wrote:
> > > On Tue, 2024-12-03 at 21:02 +0800, Zijun Hu wrote:
> > > > On 2024/12/3 20:41, Greg Kroah-Hartman wrote:
> > > > > On Tue, Dec 03, 2024 at 0
On 03/12/2024 14:41, Michal Wilczynski wrote:
> As support for clocks from new subsystems is being added to the T-Head
> TH1520 SoC, the header file name should reflect this broader scope. The
No, there is no such rule, so "should" is not appropriate.
> existing header file 'thead,th1520-clk-ap.
On Tue, 2024-12-03 at 15:51 +0100, Christian König wrote:
> Am 03.12.24 um 14:42 schrieb Thomas Hellström:
> > On Tue, 2024-12-03 at 14:12 +0100, Christian König wrote:
> > > Am 15.11.24 um 16:01 schrieb Thomas Hellström:
> > > > Provide a helper to shrink ttm_tt page-vectors on a per-page
> > > >
On 03/12/2024 14:41, Michal Wilczynski wrote:
> The address space controlling the Video Output (VO) subsystem clocks
> also contains control registers for GPU resets. To properly synchronize
> access to this shared address space, create a syscon Device Tree node
> for the VO registers and reference
On 03/12/2024 14:41, Michal Wilczynski wrote:
> The device tree bindings for the T-Head TH1520 SoC clocks currently
> support only the Application Processor (AP) subsystem. This commit
> extends the bindings to include the Video Output (VO) subsystem clocks.
>
> Update the YAML schema to define th
On 03/12/2024 14:41, Michal Wilczynski wrote:
> As support for clocks from new subsystems is being added to the T-Head
> TH1520 SoC, the Device Tree binding YAML schema file name should reflect
> this broader scope. The existing schema file 'thead,th1520-clk-ap.yaml'
> includes the '-ap' suffix, i
On Sun, 01 Dec 2024, Dmitry Baryshkov wrote:
> Reading access to connector->eld can happen at the same time the
> drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
> order to protect connector->eld from concurrent access.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Jani
On 03/12/2024 14:41, Michal Wilczynski wrote:
> +
> +title: T-HEAD TH1520 Power Domain Controller
> +
> +maintainers:
> + - Michal Wilczynski
> +
> +description: |
> + The T-HEAD TH1520 SoC includes a power domain controller responsible for
> + managing the power states of various hardware doma
On 03/12/2024 14:41, Michal Wilczynski wrote:
> The IMG BXM-4-64 GPU is integrated into the T-Head TH1520 SoC. This
> commit adds the compatible string "img,img-bxm-4-64" to the device tree
> match table in the drm/imagination driver, enabling support for this
> GPU.
>
> By including this GPU in t
On 03/12/2024 14:41, Michal Wilczynski wrote:
> The DRM Imagination GPU requires a power-domain driver, but the driver
> for "thead,th1520-aon" is not yet available. To ensure that the 'aon'
> node and its child 'pd' node are properly recognized and probed by the
> kernel, add "simple-bus" to the c
On 03/12/2024 14:41, Michal Wilczynski wrote:
> The Video Output (VO) module on the T-Head TH1520 SoC has its own set of
> clocks that need proper management. This commit introduces the
> clk-th1520-vo driver to support the VO subsystem clocks.
>
> Currently, only the clock gates are implemented,
On 03/12/2024 14:41, Michal Wilczynski wrote:
> 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 initial
On Wed, Nov 20, 2024 at 07:52:18AM -0500, Zack Rusin wrote:
> On Wed, Nov 20, 2024 at 5:22 AM Jani Nikula
> wrote:
> >
> > On Wed, 20 Nov 2024, Thomas Zimmermann wrote:
> > > Hi
> > >
> > >
> > > Am 19.11.24 um 20:40 schrieb Ian Forbes:
> > >> Most compositors are using a change in EDID as an in
On 03/12/2024 14:41, Michal Wilczynski wrote:
> The T-Head TH1520 SoC contains multiple power islands that can be
> programmatically turned on and off using the AON (Always-On) protocol
> and a hardware mailbox [1]. The relevant mailbox driver has already been
> merged into the mainline kernel in c
Hi Tomi,
Thank you for the patch.
On Tue, Dec 03, 2024 at 10:01:35AM +0200, Tomi Valkeinen wrote:
> From: Tomi Valkeinen
>
> Extend the Renesas DSI display bindings to support the r8a779h0 V4M.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> .../devicetree/bindings
Hi Jens,
On Thu, 28 Nov 2024 at 20:39, Jens Wiklander wrote:
>
> Add support in the OP-TEE backend driver for restricted memory
> allocation.
>
> The restricted memory can be allocated from a static carveout, but also
> be dynamically allocated from CMA and turned into restricted memory by
> OP-T
Hi Tomi,
Thank you for the patch.
On Tue, Dec 03, 2024 at 10:01:36AM +0200, Tomi Valkeinen wrote:
> From: Tomi Valkeinen
>
> Extend the Renesas DU display bindings to support the r8a779h0 V4M.
>
> Signed-off-by: Tomi Valkeinen
> ---
> Documentation/devicetree/bindings/display/renesas,du.yaml
From: Tomi Valkeinen
Extend the Renesas DU display bindings to support the r8a779h0 V4M.
Signed-off-by: Tomi Valkeinen
---
Documentation/devicetree/bindings/display/renesas,du.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml
b/
On 12/2/24 5:45 PM, Neil Armstrong wrote:
> Hi,
>
> On 30/11/2024 00:04, Cristian Ciocaltea wrote:
>> Commit d3d6b1bf85ae ("drm: bridge: dw_hdmi: fix preference of RGB modes
>> over YUV420") changed the order of the output bus formats, but missed to
>> update accordingly the affected comment block
On 03/12/2024 04:31, Abhinav Kumar wrote:
> Display port controller on some MSM chipsets are capable of supporting
> multiple streams. In order to distinguish the streams better, describe
> the current pixel clock better to emphasize that it drives the stream 0.
>
This should be squashed with patc
On 11/29/2024 9:50 PM, Dmitry Baryshkov wrote:
> On Fri, 29 Nov 2024 at 09:59, Xiangxu Yin wrote:
>>
>> Add the ability to configure lane mapping for the DP controller. This is
>> required when the platform's lane mapping does not follow the default
>> order (0, 1, 2, 3). The mapping rules are
On 11/29/2024 9:52 PM, Dmitry Baryshkov wrote:
> On Fri, 29 Nov 2024 at 09:59, Xiangxu Yin wrote:
>>
>> Introduce a maximum width constraint for modes during validation. This
>> ensures that the modes are filtered based on hardware capabilities,
>> specifically addressing the line buffer limita
Video Format Data Blocks (VFDBs) contain the necessary information that
needs to be fed to the Optimized Video Timings (OVT) Algorithm.
Also, we require OVT support to cover modes that aren't supported by
earlier standards (e.g. CVT). So, parse all of the relevant VFDB data
and feed it to the OVT A
On 11/29/2024 9:53 PM, Dmitry Baryshkov wrote:
> On Fri, 29 Nov 2024 at 09:59, Xiangxu Yin wrote:
>>
>> Add a mechanism to retry Link Training 2 by lowering the pattern level
>> when the link training #2 first attempt fails. This approach enhances
>> compatibility, particularly addressing issue
On 12/2/2024 5:32 PM, Dmitry Baryshkov wrote:
> On Mon, 2 Dec 2024 at 11:05, Xiangxu Yin wrote:
>>
>>
>>
>> On 11/29/2024 9:52 PM, Dmitry Baryshkov wrote:
>>> On Fri, 29 Nov 2024 at 09:59, Xiangxu Yin wrote:
Introduce a maximum width constraint for modes during validation. This
> -Original Message-
> From: Dmitry Baryshkov
> Sent: Saturday, November 30, 2024 3:17 PM
> To: Shankar, Uma
> Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org; intel-
> x...@lists.freedesktop.org; ville.syrj...@linux.intel.com;
> harry.wentl...@amd.com; pekka.paala
On 12/2/2024 12:51 PM, Vinod Koul wrote:
On 21-11-24, 18:31, Jyothi Kumar Seerapu wrote:
GSI hardware generates an interrupt for each transfer completion.
For multiple messages within a single transfer, this results in
N interrupts for N messages, leading to significant software
interrupt lat
Hi Tomi,
Thank you for the patch.
On Tue, Dec 03, 2024 at 10:01:43AM +0200, Tomi Valkeinen wrote:
> From: Tomi Valkeinen
>
> Add support for the mini DP output on the Gray Hawk board.
>
> Signed-off-by: Tomi Valkeinen
Assuming this has passed the DT checks,
Reviewed-by: Laurent Pinchart
>
Fixes up errors on HDMI and interrupt controllers that weren't
noticed before merging.
Fixes: de9bc2dba3db ("arm64: dts: broadcom: Add display pipeline support to
BCM2712")
Signed-off-by: Dave Stevenson
---
arch/arm64/boot/dts/broadcom/bcm2712.dtsi | 8
1 file changed, 4 insertions(+),
Hi,
On 2024/12/2 22:57, Maxime Ripard wrote:
On Fri, Nov 29, 2024 at 11:16:50PM +0800, Chen-Yu Tsai wrote:
On Fri, Nov 29, 2024 at 10:55 PM Maxime Ripard wrote:
On Fri, Nov 29, 2024 at 10:12:02PM +0800, Sui Jingfeng wrote:
Hi,
On 2024/11/29 18:51, Maxime Ripard wrote:
On Wed, Nov 27, 2024
Hi Dave,
Am 02.12.24 um 15:31 schrieb Dave Stevenson:
Support comes from gpiolib, so permit it through the binding.
Sorry for the nitpicking, but gpiolib is a software part of Linux and we
should describe the hardware here.
Best regards
Signed-off-by: Dave Stevenson
---
Documentation/devi
On Mon, Dec 02, 2024 at 09:13:18PM +0800, Yongbang Shi wrote:
> From: baihan li
>
> Add dp aux read/write functions. They are basic functions
> and will be used later.
>
> Signed-off-by: Baihan Li
> Signed-off-by: Yongbang Shi
> ---
> ChangeLog:
> v5 -> v6:
> - adding do{} while(0) in macro
On Tue, 3 Dec 2024 at 15:58, Jens Wiklander wrote:
>
> Hi Sumit,
>
> On Tue, Dec 3, 2024 at 9:27 AM Sumit Garg wrote:
> >
> > Hi Jens,
> >
> > On Thu, 28 Nov 2024 at 20:39, Jens Wiklander
> > wrote:
> > >
> > > The OP-TEE backend driver has two internal function pointers to convert
> > > betwee
The previous patch just adding the compatible missed out that the
number of interrupts changed
Fixes: 62948c62abca ("dt-bindings: display: Add BCM2712 HDMI bindings")
Signed-off-by: Dave Stevenson
---
.../bindings/display/brcm,bcm2711-hdmi.yaml| 44 +++---
1 file changed,
From: Tomi Valkeinen
Add support for the mini DP output on the Gray Hawk board.
Signed-off-by: Tomi Valkeinen
---
.../boot/dts/renesas/r8a779h0-gray-hawk-single.dts | 95 ++
1 file changed, 95 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a779h0-gray-hawk-single
From: Tomi Valkeinen
Add display related clocks for DU, DSI, FCPVD, and VSPD.
Signed-off-by: Tomi Valkeinen
---
drivers/clk/renesas/r8a779h0-cpg-mssr.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/clk/renesas/r8a779h0-cpg-mssr.c
b/drivers/clk/renesas/r8a779h0-cpg-mssr.c
ind
From: Tomi Valkeinen
Fix the indent on the two regulators.
Signed-off-by: Tomi Valkeinen
---
.../boot/dts/renesas/r8a779h0-gray-hawk-single.dts | 24 +++---
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a779h0-gray-hawk-single.dts
From: Tomi Valkeinen
Add the device nodes for supporting DU and DSI.
Signed-off-by: Tomi Valkeinen
---
arch/arm64/boot/dts/renesas/r8a779h0.dtsi | 77 +++
1 file changed, 77 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a779h0.dtsi
b/arch/arm64/boot/dts
From: Tomi Valkeinen
The driver checks for bit 16 (using CLOCKSET1_LOCK define) in CLOCKSET1
register when waiting for the PPI clock. However, the right bit to check
is bit 17 (CLOCKSET1_LOCK_PHY define). Not only that, but there's
nothing in the documents for bit 16 for V3U nor V4H.
So, fix the
From: Tomi Valkeinen
Add support for DSI on r8a779h0. As it is identical to DSI on r8a779g0,
all we need is to handle the compatible string.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/r
From: Tomi Valkeinen
Add support for r8a779h0. It is very similar to r8a779g0, but has only
one output.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 19 +++
drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.h | 1 +
drivers/gpu/drm/renesas/rc
From: Tomi Valkeinen
Extend the Renesas DSI display bindings to support the r8a779h0 V4M.
Signed-off-by: Tomi Valkeinen
---
.../devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/display/br
Add everything needed to support the DSI output on Renesas r8a779h0
(V4M) SoC, and the DP output (via sn65dsi86 DSI to DP bridge) on the
Renesas grey-hawk board.
Overall the DSI and the board design is almost identical to Renesas
r8a779g0 and white-hawk board.
Signed-off-by: Tomi Valkeinen
---
T
On 03/12/2024 04:31, Abhinav Kumar wrote:
> On some chipsets the display port controller can support more
Which chipsets?
> than one pixel stream (multi-stream transport). To support MST
> on such chipsets, add the binding for stream 1 pixel clock for
> display port controller. Since this mode is
On 03/12/2024 04:31, Abhinav Kumar wrote:
> Document the assigned-clock-parents better for the DP controller node
> to indicate its functionality better.
You change the clocks entirely, not "document". I would say that's an
ABI break if it really is a Linux requirement. You could avoid any
proble
On 11/29/2024 4:18 PM, Krzysztof Kozlowski wrote:
> On 29/11/2024 08:57, Xiangxu Yin wrote:
>> Extended DP support for QCS615 USB or DP phy. Differentiated between
>> USBC and DP PHY using the match table’s type, dynamically generating
>> different types of cfg and layout attributes during initi
On 03/12/2024 10:35, Thomas Zimmermann wrote:
Hi
Am 03.12.24 um 10:22 schrieb Jocelyn Falempe:
On 03/12/2024 09:48, Thomas Zimmermann wrote:
Hi
Am 15.11.24 um 14:40 schrieb Jocelyn Falempe:
drm_log is a simple logger that uses the drm_client API to print the
kmsg boot log on the screen. Th
Hi Jens,
On Thu, 28 Nov 2024 at 20:39, Jens Wiklander wrote:
>
> The OP-TEE backend driver has two internal function pointers to convert
> between the subsystem type struct tee_param and the OP-TEE type struct
> optee_msg_param.
>
> The conversion is done from one of the types to the other, which
Hi all,
this is a v2, which is quite different than the v1. The LVDS differential
voltage swing is now specified as arrays of min, max in microvolts. Two
arrays, one for data-lanes and one for clock-lane can be specified.
Additionally, because LVDS voltage swing depends on near-end termination
thi
Add a optional properties to change LVDS output voltage. This should not
be static as this depends mainly on the connected display voltage
requirement. We have three properties:
- "ti,lvds-termination-ohms", which sets near end termination,
- "ti,lvds-vod-swing-data-microvolt" and
- "ti,lvds-vod-sw
Add properties which can be used to specify LVDS differential output
voltage. Since this also depends on near-end signal termination also
include property which sets this. LVDS differential output voltage is
specified with an array (min, max), which should match the one from
connected device.
Sign
Set custom differential output voltage for LVDS, to fulfill requirements
of the connected display. LVDS differential voltage for data-lanes and
clock output has to be between 200 mV and 600 mV.
Driver sets 200 Ohm near-end termination by default.
Signed-off-by: Andrej Picej
---
Changes in v2:
- u
Hi Tomi,
Thank you for the patch.
On Tue, Dec 03, 2024 at 10:01:40AM +0200, Tomi Valkeinen wrote:
> From: Tomi Valkeinen
>
> Add support for r8a779h0. It is very similar to r8a779g0, but has only
> one output.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/renesas/rcar-du/rcar_du_
Hi Tomi,
Thank you for the patch.
On Tue, Dec 03, 2024 at 10:01:41AM +0200, Tomi Valkeinen wrote:
> From: Tomi Valkeinen
>
> Fix the indent on the two regulators.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> .../boot/dts/renesas/r8a779h0-gray-hawk-single.dts | 2
> -Original Message-
> From: dri-devel On Behalf Of Dmitry
> Baryshkov
> Sent: Saturday, November 30, 2024 3:08 PM
> To: Shankar, Uma
> Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org; intel-
> x...@lists.freedesktop.org; ville.syrj...@linux.intel.com;
> harry.went
On Mon, 02 Dec 2024, Matthew Auld wrote:
> On 02/12/2024 11:43, Jani Nikula wrote:
>> On Tue, 26 Nov 2024, Matthew Brost wrote:
>>> Don't open code vmap of a BO, use ttm_bo_access helper which is safe for
>>> non-contiguous BOs and non-visible BOs.
>>>
>>> Suggested-by: Matthew Auld
>>> Signed-o
> -Original Message-
> From: Dmitry Baryshkov
> Sent: Saturday, November 30, 2024 3:13 PM
> To: Shankar, Uma
> Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org; intel-
> x...@lists.freedesktop.org; ville.syrj...@linux.intel.com;
> harry.wentl...@amd.com; pekka.paala
> -Original Message-
> From: Dmitry Baryshkov
> Sent: Saturday, November 30, 2024 3:14 PM
> To: Shankar, Uma
> Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org; intel-
> x...@lists.freedesktop.org; ville.syrj...@linux.intel.com;
> harry.wentl...@amd.com; pekka.paala
On 03/12/2024 09:48, Thomas Zimmermann wrote:
Hi
Am 15.11.24 um 14:40 schrieb Jocelyn Falempe:
drm_log is a simple logger that uses the drm_client API to print the
kmsg boot log on the screen. This is not a full replacement to fbcon,
as it will only print the kmsg. It will never handle user in
On 03/12/2024 10:56, Laurent Pinchart wrote:
Hi Tomi,
Thank you for the patch.
On Tue, Dec 03, 2024 at 10:01:40AM +0200, Tomi Valkeinen wrote:
From: Tomi Valkeinen
Add support for r8a779h0. It is very similar to r8a779g0, but has only
one output.
Signed-off-by: Tomi Valkeinen
---
drivers
On Mon, Dec 02, 2024 at 01:40:59PM -0500, Genes Lists wrote:
>
> 6.12.1 on same system with same userspace works fine (as did 6.12)
> while 6.13-rc1 boots, but without working graphics using gnome with
> wayland.
>
> Laptop is raptor lake with Intel XE (lspci attached).
> No kernel errors are log
Prepare the work for drm_panic support. This is used to map the
current framebuffer, so the CPU can overwrite it with the panic
message.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/i915/display/intel_bo.c| 10 +
drivers/gpu/drm/i915/display/intel_bo.h| 2 ++
drivers/gpu/d
This adds drm_panic support for a wide range of Intel GPU. I've
tested it only on 3 laptops, haswell (with 128MB of eDRAM),
cometlake and alderlake.
* DPT: if I disable tiling on a framebuffer using DPT, then it
displays some other memory location. As DPT is enabled only for
tiled framebuff
The vaddr of the fbdev framebuffer is private to the struct
intel_fbdev, so this function is needed to access it for drm_panic.
Also the struct i915_vma is different between i915 and xe, so it
requires a few functions to access fbdev->vma->iomap.
Signed-off-by: Jocelyn Falempe
---
v2:
* Add int
drm_panic draws in linear framebuffer, so it's easier to re-use the
current framebuffer, and disable tiling in the panic handler, to show
the panic screen.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/i915/display/i9xx_plane.c | 23 +++
.../drm/i915/display/intel_displa
drm_panic draws in linear framebuffer, so it's easier to re-use the
current framebuffer, and disable tiling in the panic handler, to show
the panic screen.
Signed-off-by: Jocelyn Falempe
---
.../drm/i915/display/skl_universal_plane.c| 20 +++
1 file changed, 20 insertions(+)
This is a first draft of drm_panic support for i915.
I've tested it on the 3 intel laptops I have at my disposal.
one Haswell with 128MB of eDRAM, one Cometlake and one Alderlake.
I tested panic in both fbdev console and gnome desktop.
I still have an issue with Alderlake, and it doesn't work wh
Am 03.12.24 um 06:00 schrieb Raag Jadav:
On Mon, Dec 02, 2024 at 10:07:59AM +0200, Raag Jadav wrote:
On Fri, Nov 29, 2024 at 10:40:14AM -0300, André Almeida wrote:
Hi Raag,
Em 28/11/2024 12:37, Raag Jadav escreveu:
Introduce device wedged event, which notifies userspace of 'wedged'
(hanged/un
Hi Sumit,
On Tue, Dec 3, 2024 at 9:27 AM Sumit Garg wrote:
>
> Hi Jens,
>
> On Thu, 28 Nov 2024 at 20:39, Jens Wiklander
> wrote:
> >
> > The OP-TEE backend driver has two internal function pointers to convert
> > between the subsystem type struct tee_param and the OP-TEE type struct
> > optee_
On Tue, 03 Dec 2024, Maxime Ripard wrote:
> On Mon, Dec 02, 2024 at 05:44:27PM +0200, Jani Nikula wrote:
>> >> It's super tempting for people to just get their jobs done. If doing
>> >> the right thing adds yet another hurdle, we may see more stuff being
>> >> added in drivers instead of drm core.
On Mon, Dec 02, 2024 at 04:39:02PM -0800, Abhinav Kumar wrote:
> msm_dp_hpd_unplug_handle() checks if the display was already disabled and if
> so does not transition to ST_DISCONNECT_PENDING state and goes directly to
> ST_DISCONNECTED. The same result can be achieved with the !power_on check.
>
On Mon, Dec 02, 2024 at 04:39:03PM -0800, Abhinav Kumar wrote:
> ST_DISPLAY_OFF check in msm_dp_bridge_atomic_enable() is used to check
> that if the display was disabled while still hotplugged, phy needs
> to be re-initialized. This can be replaced with a different check as
> it just means the hpd
On 03/12/2024 12:06, Jani Nikula wrote:
On Fri, 15 Nov 2024, Jocelyn Falempe wrote:
Move the color conversions, blit and fill functions to drm_draw.c,
so that they can be re-used by drm_log.
drm_draw is internal to the drm subsystem, and shouldn't be used by
gpu drivers.
I started looking at
1 - 100 of 248 matches
Mail list logo
