On Fri, Feb 07, 2025 at 02:49:50PM +0100, Simona Vetter wrote:
> When you're that harmful with your calling out, eventually I'm going to be
> fed up, and you get a live round shot across your bow. And if that then
> causes you to ragequit, because you can't actually deal with the heat
> you've been
On Fri, Feb 07, 2025 at 06:35:22PM +0100, Louis Chauvet wrote:
> During the creation of drmm_ variants for writeback connector, one
> function was renamed, but not the kernel doc.
>
> To remove the warning, use the proper name in kernel doc.
>
> Fixes: 135d8fc7af44 ("drm: writeback: Create an hel
On Sun, Feb 09, 2025 at 06:30:24PM +0100, Danilo Krummrich wrote:
> +config NOVA_CORE
> + tristate "Nova Core GPU driver"
> + depends on PCI
> + depends on RUST
> + depends on RUST_FW_LOADER_ABSTRACTIONS
> + default n
Tiny nit, if you happen to respin this, "default n" is alway
alar variable")
> Fixes: 774bcfb731765d ("drm/msm/dpu: add support for virtual planes")
> Signed-off-by: Ethan Carter Edwards
> ---
> Changes in v2:
> - Return explicit 0 when no error occurs
> - Add hardening mailing lists
> - Link to v1:
> https://lore
off-by: Ethan Carter Edwards
---
Changes in v2:
- Return explicit 0 when no error occurs
- Add hardening mailing lists
- Link to v1:
https://lore.kernel.org/r/20250209-dpu-v1-1-0db666884...@ethancedwards.com
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 7 +++
1 file changed, 3 insertions(+),
thin the loop and return explicit 0 if there was no error.
>
> for (i = 0; i < num_planes; i++) {
> struct drm_plane_state *plane_state = states[i];
>
> ---
> base-commit: a64dcfb451e254085a7daee5fe51bf22959d52d3
> change-id: 20250209-dpu-c3fac78fc617
>
> Best regards,
> --
> Ethan Carter Edwards
>
--
With best wishes
Dmitry
From: Michael Kelley
When a Hyper-V framebuffer device is removed, or the driver is unbound
from a device, any allocated and/or mapped memory must be released. In
particular, MMIO address space that was mapped to the framebuffer must
be unmapped. Current code unmaps the wrong address, resulting i
On 2/9/2025 1:42 PM, Marijn Suijten wrote:
Ordering issues here cause an uninitialized (default STANDALONE)
usecase to be programmed (which appears to be a MUX) in some cases
when msm_dsi_host_register() is called, leading to the slave PLL in
bonded-DSI mode to source from a clock parent (dsi1
On Sun, Feb 09, 2025 at 10:42:54PM +0100, Marijn Suijten wrote:
> When DSC is enabled the number of interfaces is forced to be 1, and
> documented that it is a "power-optimal" layout to use two DSC encoders
> together with two Layer Mixers. However, the same layout (two DSC
> hard-slice encoders w
On Sun, Feb 09, 2025 at 10:42:53PM +0100, Marijn Suijten wrote:
> Ordering issues here cause an uninitialized (default STANDALONE)
> usecase to be programmed (which appears to be a MUX) in some cases
> when msm_dsi_host_register() is called, leading to the slave PLL in
> bonded-DSI mode to source f
When switching to drm_edid, we slightly changed how to get edid by
removing the possibility of getting them from dc_link when in aux
transaction mode. As MST doesn't initialize the connector with
`drm_connector_init_with_ddc()`, restore the original behavior to avoid
functional changes.
Fixes: 48e
This series covers a step-up towards supporting the DUALPIPE DSC
topology, also known as 2:2:2 topology (on active-CTL hardware). It
involves 2 layer mixers, 2 DSC compression encoders, and 2 interfaces
(on DSI, this is called bonded-DSI) where bandwidth constraints (e.g. 4k
panels at 120Hz) requi
When configuring the timing of DSI hosts (interfaces) in
dsi_timing_setup() all values written to registers are taking
bonded-mode into account by dividing the original mode width by 2
(half the data is sent over each of the two DSI hosts), but the full
width instead of the interface width is passe
Ordering issues here cause an uninitialized (default STANDALONE)
usecase to be programmed (which appears to be a MUX) in some cases
when msm_dsi_host_register() is called, leading to the slave PLL in
bonded-DSI mode to source from a clock parent (dsi1vco) that is off.
This should seemingly not be
When DSC is enabled the number of interfaces is forced to be 1, and
documented that it is a "power-optimal" layout to use two DSC encoders
together with two Layer Mixers. However, the same layout (two DSC
hard-slice encoders with two LMs) is also used when the display is
fed with data over two ins
On 2/6/25 13:42, Ryosuke Yasuoka wrote:
> Virtio gpu supports the drm_panic module, which displays a message to
> the screen when a kernel panic occurs. It is supported where it has
> vmapped shmem BO.
>
> Signed-off-by: Jocelyn Falempe
> Signed-off-by: Ryosuke Yasuoka
> ---
Applied to misc-nex
Add the initial nova-core driver stub.
nova-core is intended to serve as a common base for nova-drm (the
corresponding DRM driver) and the vGPU manager VFIO driver, serving as a
hard- and firmware abstraction layer for GSP-based NVIDIA GPUs.
The Nova project, including nova-core and nova-drm, in
Add the initial documentation of the Nova project.
The initial project documentation consists out of a brief introduction
of the project, as well as project guidelines both general and nova-core
specific and a task list for nova-core specifically.
The task list is divided into tasks for general R
On Wed, Nov 13, 2024 at 02:18:43AM +0530, Akhil P Oommen wrote:
> On 10/30/2024 12:32 PM, Akhil P Oommen wrote:
> > From: Puranam V G Tejaswi
> >
> > Enable GPU for sa8775p-ride platform and provide path for zap
> > shader.
> >
> > Signed-off-by: Puranam V G Tejaswi
> > Signed-off-by: Akhil P O
Hello all,
This patch series adds support for the dual OLDI TXes supported in Texas
Instruments' AM62x and AM62Px family of SoCs. The OLDI TX hardware supports
single-lvds, lvds-clone, and dual-lvds modes. These TXes have now been
represented through DRM bridges within TI-DSS.
* Some history and
From: Aradhya Bhatia
Reduce tab size from 8 spaces to 4 spaces to make the bindings
consistent, and easy to expand.
Acked-by: Rob Herring (Arm)
Reviewed-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Signed-off-by: Aradhya Bhatia
Signed-off-by: Aradhya Bhatia
---
.../bindings/display/ti/
From: Aradhya Bhatia
The OLDI transmitters (TXes) do not have registers of their own, and are
dependent on the source video-ports (VPs) from the DSS to provide
configuration data. This hardware doesn't directly sit on the internal
bus of the SoC, but does so via the DSS. Hence, the OLDI TXes are
From: Aradhya Bhatia
The AM62x and AM62Px SoCs feature 2 OLDI TXes each, which makes it
possible to connect them in dual-link or cloned single-link OLDI display
modes. The current OLDI support in tidss_dispc.c can only support for
a single OLDI TX, connected to a VP and doesn't really support
con
The display on Lenovo Xiaoxin Pro 13 2019 (Lenovo XiaoXinPro-13API 2019)
briefly shows a garbled screen upon wakeup from S3 with kernel v6.13.2,
but not with v6.14-rc1. I have bisected to
04d6273faed083e619fc39a738ab0372b6a4db20 ("Revert "drm/amd/display: Fix
green screen issue after suspend"")
On Wed, Feb 05, 2025 at 07:44:19PM +, Zhi Wang wrote:
> On 05/02/2025 18.10, Danilo Krummrich wrote:
> > On Wed, Feb 05, 2025 at 03:56:46PM +0200, Zhi Wang wrote:
> >> On Tue, 4 Feb 2025 20:03:12 +0100
> >> Danilo Krummrich wrote:
> >>> diff --git a/Documentation/gpu/nova/guidelines.rst
> >>
On Fri, Feb 07, 2025 at 05:23:37PM +0900, Alexandre Courbot wrote:
> On Wed Feb 5, 2025 at 10:56 PM JST, Zhi Wang wrote:
> > On Tue, 4 Feb 2025 20:03:12 +0100
> > Danilo Krummrich wrote:
> >> + regressions with all 2nd level drivers.
> >> diff --git a/Documentation/gpu/nova/core/todo.rst
> >> b
https://bugzilla.kernel.org/show_bug.cgi?id=198387
peter.eszl...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Tested only on OpenBSD. Before:
$ cat drm-name.c
#include
#include
#include
int
main(void)
{
int fd = open("/dev/dri/renderD128", O_RDONLY);
puts(drmGetRenderDeviceNameFromFd(fd));
puts(drm
On Mon, Feb 3, 2025 at 6:52 AM Nick Chan wrote:
>
> Apple SoCs come with a 2-wire interface named DWI. On some iPhones, iPads
> and iPod touches the backlight controller is connected via this interface.
> This series adds a backlight driver for backlight controllers connected
> this way.
>
> Chang
On Thu, Feb 06, 2025 at 09:58:36AM -0800, Linus Torvalds wrote:
Good morning to everyone.
> On Thu, 6 Feb 2025 at 01:19, Hector Martin wrote:
> >
> > If shaming on social media does not work, then tell me what does,
> > because I'm out of ideas.
> Because if we have issues in the kernel develop
On Tue, Feb 04, 2025 at 08:59:08AM +0100, Christian König wrote:
> Am 26.01.25 um 10:32 schrieb Zhaoyu Liu:
> > TTM always uses pin_count and ttm_resource_is_swapped() together to
> > determine whether a BO is unevictable.
> > Now use ttm_resource_unevictable() to replace them.
> >
> > Signed-off-
Some newer high refresh rate consumer monitors (including those by Samsung)
make use of DisplayID 2.1 timing blocks in their EDID data, notably for
their highest refresh rate modes. Such modes won't be available as of now.
Implement partial support for such blocks in order to enable native
support
Hello Thomas!
> No it's not. Major code abstractions behind preprocessor tokens are
> terrible to maintain.
Hmm, don't get me wrong but I'm not sure if the changes were really
checked in detail. At first sight it might look like I'm adding tons of
new macro ridden code in those header files repl
On 06/02/2025 19:46, Abhinav Kumar wrote:
Widebus allows the DP controller to operate in 2 pixel per clock mode.
The mode validation logic validates the mode->clock against the max
DP pixel clock. However the max DP pixel clock limit assumes widebus
is already enabled. Adjust the mode validation
On Thu, Feb 6, 2025 at 9:02 AM Sasha Finkelstein via B4 Relay
wrote:
>
> Hi.
>
> This patch series adds support for a secondary display controller
> present on Apple M1/M2 chips and used to drive the display of the
> "touchbar" touch panel present on those.
>
> Signed-off-by: Sasha Finkelstein
>
The MSM DisplayPort driver implements several HDMI codec functions
in the driver, e.g. it manually manages HDMI codec device registration,
returning ELD and plugged_cb support. In order to reduce code
duplication reuse drm_hdmi_audio_* helpers and drm_bridge_connector
integration.
As a part of thi
Create the DisplayPort subconnector property for DP connectors managed
through drm_bridge_connector, removing the need to create it manually by
the drivers.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_bridge_connector.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/dr
DRM HDMI Codec framework is useful not only for the HDMI bridges, but
also for the DisplayPort bridges. Add new DRM_BRIDGE_OP_DisplayPort
define in order to distinguish DP bridges. Create HDMI codec device
automatically for DP bridges which have declared audio support.
Note, unlike HDMI devices, w
A lot of DisplayPort bridges use HDMI Codec in order to provide audio
support. Present DRM HDMI Audio support has been written with the HDMI
and in particular DRM HDMI Connector framework support, however those
audio helpers can be easily reused for DisplayPort drivers too.
Patches by Hermes Wu th
On Fri, Jan 17, 2025 at 11:50:50AM +0200, Dmitry Baryshkov wrote:
> If the created connector type supports subconnector type property,
> create and attach corresponding it. The default subtype value is 0,
> which maps to the DRM_MODE_SUBCONNECTOR_Unknown type. Also remove
> subconnector creation fr
Hi Jayesh,
Thank you for testing this out, and reporting the error I had
overlooked.
On 04/02/25 17:59, Jayesh Choudhary wrote:
> Hello Aradhya,
>
> On 27/01/25 00:45, Aradhya Bhatia wrote:
>> The encoder-bridge ops occur by looping over the new connector states of
>> the display pipelines. The
The encoder-bridge ops occur by looping over the new connector states of
the display pipelines. The enable sequence runs as follows -
- pre_enable(bridge),
- enable(encoder),
- enable(bridge),
while the disable sequnce runs as follows -
- disable(bridge),
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:
bridge[n]_pre_enable
...
bridge[1]_pre_enable
crtc_enable
encoder_enable
bridge[1]
From: Aradhya Bhatia
The way any singular display pipeline, in need of a modeset, gets
enabled is as follows -
crtc enable
(all) bridge pre-enable
encoder enable
(all) bridge enable
- and the disable sequence is exactly the reverse of this.
The crtc operations o
From: Aradhya Bhatia
The cdns-dsi controller requires that it be turned on completely before
the input DPI's source has begun streaming[0]. Not having that, allows
for a small window before cdns-dsi enable and after cdns-dsi disable
where the previous entity (in this case tidss's videoport) to co
From: Aradhya Bhatia
At present, the DSI mode configuration check happens during the
_atomic_enable() phase, which is not really the best place for this.
Moreover, if the mode is not valid, the driver gives a warning and
continues the hardware configuration.
Move the DSI mode configuration check
From: Aradhya Bhatia
Change the existing (and deprecated) bridge hooks, to the bridge
atomic APIs.
Add drm helpers for duplicate_state, destroy_state, and bridge_reset
bridge hooks.
Further add support for the input format negotiation hook.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Tomi Valk
From: Aradhya Bhatia
Once the DSI Link and DSI Phy are initialized, the code needs to wait
for Clk and Data Lanes to be ready, before continuing configuration.
This is in accordance with the DSI Start-up procedure, found in the
Technical Reference Manual of Texas Instrument's J721E SoC[0] which
h
From: Aradhya Bhatia
Add a helper API that can be used by the DSI hosts to find the required
input bus format for the given output dsi pixel format.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Tomi Valkeinen
Signed-off-by: Aradhya Bhatia
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/drm_
From: Aradhya Bhatia
Instead of manually finding the next bridge/panel, and maintaining the
panel-bridge (in-case the next entity is a panel), switch to using the
automatically managing devm_drm_of_get_bridge() API.
Drop the drm_panel support completely from the driver while at it.
Reviewed-by:
From: Aradhya Bhatia
Check for the return value of the phy_mipi_dphy_get_default_config()
call, and in case of an error, return back the same.
Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework")
Cc: sta...@vger.kernel.org
Reviewed-by: Tomi Valkeinen
Reviewed-by: Dmitry Baryshkov
From: Aradhya Bhatia
The crtc_* mode parameters do not get generated (duplicated in this
case) from the regular parameters before the mode validation phase
begins.
The rest of the code conditionally uses the crtc_* parameters only
during the bridge enable phase, but sticks to the regular paramet
Hello all,
This series provides some crucial fixes and improvements for the Cadence's DSI
TX (cdns-dsi) controller found commonly in Texas Instruments' J7 family of SoCs,
as well as in Sitara AM62P and AM62L SoCs.
Along with that, this series aims to fix the color-shift issue that has been
going
From: Aradhya Bhatia
The driver code doesn't have a Phy de-initialization path as yet, and so
it does not clear the phy_initialized flag while suspending. This is a
problem because after resume the driver looks at this flag to determine
if a Phy re-initialization is required or not. It is in fact
From: Aradhya Bhatia
Fix the OF node pointer passed to the of_drm_find_bridge() call to find
the next bridge in the display chain.
The code to find the next panel (and create its panel-bridge) works
fine, but to find the next (non-panel) bridge does not.
To find the next bridge in the pipeline,
On 06/02/2025 22:21, Nicolas Dufresne wrote:
> Le mercredi 05 février 2025 à 10:13 +0100, Krzysztof Kozlowski a écrit :
>> On 03/02/2025 16:31, Florent Tomasin wrote:
>>> Hi Krzysztof
>>>
>>> On 30/01/2025 13:25, Krzysztof Kozlowski wrote:
On 30/01/2025 14:08, Florent Tomasin wrote:
> Allo
61 matches
Mail list logo
