Hi Marek,
2024년 4월 25일 (목) 오후 6:49, Marek Szyprowski 님이 작성:
>
> When reading EDID fails and driver reports no modes available, the DRM
> core adds an artificial 1024x786 mode to the connector. Unfortunately
> some variants of the Exynos HDMI (like the one in Exynos4 SoCs) are not
> able to drive s
On 14/05/24 00:49, Rob Herring wrote:
> On Sun, May 12, 2024 at 01:00:52AM +0530, Aradhya Bhatia wrote:
>> Reduce tab size from 8 spaces to 4 spaces to make the bindings
>> consistent, and easy to expand.
>
> "Re-indent the example" would be more specific than "minor cleanups" in
> the subject
On 14/05/24 01:05, Rob Herring wrote:
> On Sun, May 12, 2024 at 01:00:54AM +0530, Aradhya Bhatia wrote:
>> The DSS in AM625 SoC has 2 OLDI TXes. Refer the OLDI schema to add the
>> properties.
>>
>> Signed-off-by: Aradhya Bhatia
>> ---
>> .../bindings/display/ti/ti,am65x-dss.yaml | 136 +++
Hi Rob,
Thank you for reviewing the patches!
On 14/05/24 01:00, Rob Herring wrote:
> On Mon, May 13, 2024 at 02:07:44PM +0530, Aradhya Bhatia wrote:
>> Hi Laurent,
>>
>> Thank you for reviewing the patches!
>>
>> On 13-May-24 01:04, Laurent Pinchart wrote:
>>> Hi Aradhya,
>>>
>>> Thank you for th
On Mon, May 13, 2024 at 1:09 PM Christian König
wrote:
>
> Am 10.05.24 um 18:34 schrieb Zack Rusin:
> > Hey,
> >
> > so this is a bit of a silly problem but I'd still like to solve it
> > properly. The tldr is that virtualized drivers abuse
> > drm_driver::gem_prime_import_sg_table (at least vmwgf
Hi all,
Today's linux-next merge of the devicetree tree got a conflict in:
Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml
between commit:
90ed42ceda76 ("dt-bindings: display: novatek, nt36523: define ports")
from the drm tree and commit:
9fa6bcf23e44 ("dt-bindings:
-Original Message-
From: Robert Foss
Sent: Tuesday, May 14, 2024 1:45 AM
To: Kuro Chung (鐘仕廷)
Cc: Allen Chen ; Pin-yen Lin ;
Kenneth Hung (洪家倫) ; Kuro Chung
; Andrzej Hajda
; Neil Armstrong ; Laurent
Pinchart ; Jonas Karlman ;
Jernej Skrabec ; Maarten Lankhorst
; Maxime Ripard ; Th
TC9595 datasheet Video Path0 Control (VPCTRL0) Register bit FRMSYNC description
says "This bit should be disabled only in video mode transmission where Host
transmits video timing together with video data and where pixel clock source
is from DSI clock." . This driver always sources pixel clock from
On Fri, 10 May 2024 16:21:11 -0700 Mina Almasry wrote:
> Device Memory TCP
Sorry Mina, this is too big to apply during the merge window :(
--
pw-bot: defer
On Mon, May 13, 2024 at 11:27 AM Christian König
wrote:
>
> Am 10.05.24 um 18:34 schrieb Zack Rusin:
> > Hey,
> >
> > so this is a bit of a silly problem but I'd still like to solve it
> > properly. The tldr is that virtualized drivers abuse
> > drm_driver::gem_prime_import_sg_table (at least vmwg
Merge the identical if/elif code blocks and remove the following two
warnings reported by make includecheck:
asm/ioctl.h is included more than once
linux/types.h is included more than once
Signed-off-by: Thorsten Blum
---
include/uapi/drm/drm.h | 8 +---
1 file changed, 1 in
Hey,
Understood. Thanks a lot and sorry for any inconvenience.
Mohamed
On Mon, May 13, 2024 at 11:28 PM Danilo Krummrich wrote:
> Hi Mohamed,
>
> Thank you for fixing this up!
>
> On 5/9/24 22:43, Mohamed Ahmed wrote:
> > Allows PTE kind and tile mode on BO create with VM_BIND,
> > and adds a
On Thu, May 9, 2024 at 11:43 AM Krzysztof Kozlowski
wrote:
> SPI-attached devices could have more than one chip-select, thus their
> bindings are supposed to constrain the 'reg' property to match hardware.
> Add missing 'reg' constrain for SPI-attached display panels.
>
> Signed-off-by: Krzysztof
On Sat, May 11, 2024 at 4:14 AM Cong Yang
wrote:
> The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller
> which fits in nicely with the existing panel-himax-hx83102 driver. Hence,
> we add a new compatible with panel specific config.
>
> Signed-off-by: Cong Yang
Reviewed-by:
On Sat, May 11, 2024 at 4:13 AM Cong Yang
wrote:
> The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller
> which fits in nicely with the existing panel-himax-hx83102 driver. Hence,
> we add a new compatible with panel specific config.
>
> Signed-off-by: Cong Yang
Reviewed-
Hi Mohamed,
Thank you for fixing this up!
On 5/9/24 22:43, Mohamed Ahmed wrote:
Allows PTE kind and tile mode on BO create with VM_BIND,
and adds a GETPARAM to indicate this change. This is needed to support
It's usually better to use imperative verb form for commit messages. No
need to send
All users of drm_do_get_edid() have been converted to
drm_edid_read_custom(). Remove the unused function to prevent new users
from creeping in.
Signed-off-by: Jani Nikula
---
Cc: Robert Foss
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
---
drivers/gpu/drm/drm_edid.c | 28 -
On Sat, May 11, 2024 at 4:13 AM Cong Yang
wrote:
> The Starry HX83102 based mipi panel should never have been part of the boe
> tv101wum-n16 driver. Discussion with Doug and Linus in V1 [1], we need a
> separate driver to enable the hx83102 controller.
>
> In hx83102 driver, add DSI commands as m
On Thu, May 9, 2024 at 11:43 AM Krzysztof Kozlowski
wrote:
> DSI-attached devices could respond to more than one virtual channel
> number, thus their bindings are supposed to constrain the 'reg' property
> to match hardware. Add missing 'reg' constrain for DSI-attached display
> panels, based on
On Wed, May 8, 2024 at 10:53 PM Douglas Anderson wrote:
> This is a mechanical conversion of the novatek-nt36672e driver to use
> the new mipi_dsi_dcs_write_seq_multi(). The new function is easier for
> clients to understand and using it also causes smaller code to be
> generated. Specifically:
>
On Mon, 13 May 2024, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Export drm_plane_has_format() so that drivers can use it.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_crtc_internal.h | 2 --
> drivers/gpu/drm/drm_plane.c | 1 +
> include/d
On Mon, 13 May 2024, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Rename drm_plane_check_pixel_format() to drm_plane_has_format()
> and change the return type accordingly. Allows one to write
> more natural code.
>
> Also matches drm_any_plane_has_format() better.
>
> Signed-off-by: Ville Syrjä
On Sun, May 12, 2024 at 01:00:54AM +0530, Aradhya Bhatia wrote:
> The DSS in AM625 SoC has 2 OLDI TXes. Refer the OLDI schema to add the
> properties.
>
> Signed-off-by: Aradhya Bhatia
> ---
> .../bindings/display/ti/ti,am65x-dss.yaml | 136 +-
> 1 file changed, 135 insertion
On Mon, May 13, 2024 at 02:07:44PM +0530, Aradhya Bhatia wrote:
> Hi Laurent,
>
> Thank you for reviewing the patches!
>
> On 13-May-24 01:04, Laurent Pinchart wrote:
> > Hi Aradhya,
> >
> > Thank you for the patch.
> >
> > On Sun, May 12, 2024 at 01:00:53AM +0530, Aradhya Bhatia wrote:
> >> Ad
On Sun, May 12, 2024 at 01:00:52AM +0530, Aradhya Bhatia wrote:
> Reduce tab size from 8 spaces to 4 spaces to make the bindings
> consistent, and easy to expand.
"Re-indent the example" would be more specific than "minor cleanups" in
the subject.
Otherwise,
Acked-by: Rob Herring (Arm)
>
> S
On Sat, May 11, 2024 at 12:22 AM Stephen Rothwell wrote:
>
> Hi Marcelo,
>
> On Sat, 11 May 2024 13:37:17 +1000 Stephen Rothwell
> wrote:
> >
> > Thanks for doing this.
> >
> > I haven't tested it, but just a couple of little things:
> >
> > On Fri, 10 May 2024 21:02:02 -0300 Marcelo Mendes Spes
From: Ville Syrjälä
I don't think the display hardware really has such chroma
plane tile row alignment requirements as outlined in
commit d156135e6a54 ("drm/i915/tgl: Make sure a semiplanar
UV plane is tile row size aligned")
Bspec had the same exact thing to say about earlier hardware
as well,
From: Ville Syrjälä
Currently we still use the SKL+ PLANE_SURF alignment even
for TGL+ even though the hardware no longer needs it.
Introduce a separate tgl_plane_min_alignment() and update
it to more accurately reflect the hardware requirements.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/d
From: Ville Syrjälä
Now that all pre-skl platforms have their own .min_alignment()
functions the remainder of intel_surf_alignment() can be hoisted
into skl_univerals_plane.c (and renamed appropriately).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fb.c | 77 +-
From: Ville Syrjälä
Extract the necessary chunks from intel_surf_alignment()
into per-platform variants for all pre-skl primary/sprite
planes.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_plane.c | 69 -
drivers/gpu/drm/i915/display/intel_fb.c |
From: Ville Syrjälä
Different planes could have different alignment requirements
even for the same format/modifier. Collect the alignment
requirements across all planes capable of scanning out the
fb such that the alignment used when pinning the normal ggtt
view is satisfactory to all those plane
From: Ville Syrjälä
Different hardware generations have different scanout alignment
requirements. Introduce a new vfunc that will allow us to
make that distinction without horrible if-ladders.
For now we directly plug in the existing intel_surf_alignment()
and intel_cursor_alignment() functions.
From: Ville Syrjälä
Split intel_cursor_alignment() into per-platform variants.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cursor.c | 40 +++--
drivers/gpu/drm/i915/display/intel_fb.c | 16 -
drivers/gpu/drm/i915/display/intel_fb.h | 3 -
From: Ville Syrjälä
Export drm_plane_has_format() so that drivers can use it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc_internal.h | 2 --
drivers/gpu/drm/drm_plane.c | 1 +
include/drm/drm_plane.h | 2 ++
3 files changed, 3 insertions(+), 2 deletions(-)
di
From: Ville Syrjälä
Rename drm_plane_check_pixel_format() to drm_plane_has_format()
and change the return type accordingly. Allows one to write
more natural code.
Also matches drm_any_plane_has_format() better.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic.c| 7 ++-
From: Ville Syrjälä
intel_surf_alignment() in particular has devolved into
a complete mess. Redesign the code so that we can handle
alignment restrictions in a nicer. Also adjust alignment
for TGL+ to actually match the hardware requirements.
Ville Syrjälä (9):
drm: Rename drm_plane_check_pixe
On Mon, May 13, 2024 at 7:42 PM Robert Foss wrote:
>
> On Mon, May 6, 2024 at 11:36 AM kuro wrote:
> >
> > From: Kuro
> >
> > ITE added a FIFO reset bit for input video. When system power resume,
> > the TTL input of it6505 may get some noise before video signal stable
> > and the hardware funct
On Mon, May 6, 2024 at 11:36 AM kuro wrote:
>
> From: Kuro
>
> ITE added a FIFO reset bit for input video. When system power resume,
> the TTL input of it6505 may get some noise before video signal stable
> and the hardware function reset is required.
> But the input FIFO reset will also trigger
On Fri, 10 May 2024 16:26:03 +0300, Jani Nikula wrote:
> Resend of the remaining patches from [1].
>
> BR,
> Jani.
>
> [1] https://lore.kernel.org/r/cover.1713273659.git.jani.nik...@intel.com
>
> [...]
Fixed checkpatch issue in "drm/bochs: switch to struct drm_edid"
Applied, thanks!
[1/6] drm
On Fri, May 10, 2024 at 3:26 PM Jani Nikula wrote:
>
> Prefer struct drm_edid based functions over struct edid.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> ---
> driver
On Fri, May 10, 2024 at 3:26 PM Jani Nikula wrote:
>
> Prefer struct drm_edid based functions over struct edid.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> ---
> .../dr
Am 10.05.24 um 18:34 schrieb Zack Rusin:
Hey,
so this is a bit of a silly problem but I'd still like to solve it
properly. The tldr is that virtualized drivers abuse
drm_driver::gem_prime_import_sg_table (at least vmwgfx and xen do,
virtgpu and xen punt on it) because there doesn't seem to be a
On Fri, May 10, 2024 at 3:26 PM Jani Nikula wrote:
>
> Prefer struct drm_edid based functions over struct edid.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> ---
> .../gp
On Fri, May 10, 2024 at 3:26 PM Jani Nikula wrote:
>
> Prefer struct drm_edid based functions over struct edid.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> Cc: Russell King
> ---
> drivers/gpu/drm/i2c/tda998x_drv.c | 19 ++-
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
>
On Fri, May 10, 2024 at 3:27 PM Jani Nikula wrote:
>
> Prefer struct drm_edid based functions over struct edid.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> Cc: Gerd Hoffmann
> Cc: virtualizat...@lists.linux.dev
> ---
> drivers/gpu/drm/tiny/bochs.c | 23 ++-
> 1 file changed,
On Fri, May 10, 2024 at 3:34 PM Jani Nikula wrote:
>
> Prefer struct drm_edid based functions over struct edid.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> Cc: David Airlie
> Cc: Gerd Hoffmann
> Cc: Gurchetan Singh
> Cc: Chia-I Wu
> Cc: virtualizat...@lists.linux.dev
> ---
> drivers/gpu/drm/v
On Fri, May 10, 2024 at 5:09 PM Jani Nikula wrote:
>
> amdgpu_connector_edid() copies the EDID from edid_blob_ptr as a side
> effect if amdgpu_connector->edid isn't initialized. However, everywhere
> that the returned EDID is used, the EDID should have been set
> beforehands.
>
> Only the drm EDID
On Wed, May 08, 2024 at 01:51:48PM -0700, Douglas Anderson wrote:
> This is a mechanical conversion of the novatek-nt36672e driver to use
> the new mipi_dsi_dcs_write_seq_multi(). The new function is easier for
> clients to understand and using it also causes smaller code to be
> generated. Specifi
On Fri, May 10, 2024 at 5:08 PM Jani Nikula wrote:
>
> radeon_connector_edid() copies the EDID from edid_blob_ptr as a side
> effect if radeon_connector->edid isn't initialized. However, everywhere
> that the returned EDID is used, the EDID should have been set
> beforehands.
>
> Only the drm EDID
On Mon, 13 May 2024 at 10:55, Liu Ying wrote:
>
> The connector is created by either this ADV7511 bridge driver or
> any DRM device driver/previous bridge driver, so this ADV7511
> bridge driver should not let the next bridge driver create connector.
>
> If the next bridge is a HDMI connector, the
Hi,
On Sat, May 11, 2024 at 4:00 PM Dmitry Baryshkov
wrote:
>
> Follow the pattern of mipi_dsi_dcs_*_multi() and wrap several existing
> MIPI DSI functions to use the context for processing. This simplifies
> and streamlines driver code to use simpler code pattern.
>
> Note, msleep function is al
On Fri, May 10, 2024 at 5:08 PM Jani Nikula wrote:
>
> Prefer the parsed results for is_hdmi and has_audio in display info over
> calling drm_detect_hdmi_monitor() and drm_detect_monitor_audio(),
> respectively.
>
> Cc: Alex Deucher
> Cc: Christian König
> Cc: Pan, Xinhui
> Cc: amd-...@lists.fr
On 5/12/2024 08:36, Michal Wajdeczko wrote:
We already provide the content of the GuC log in debugsfs, but it
is in a text format where each log dword is printed as hexadecimal
number, which does not scale well with large GuC log buffers.
To allow more efficient access to the GuC log, which coul
On Mon, May 13, 2024 at 6:30 PM Sui Jingfeng wrote:
>
> Hi,
>
>
> On 5/13/24 16:02, Liu Ying wrote:
> > The connector is created by either this ADV7511 bridge driver or
> > any DRM device driver/previous bridge driver, so this ADV7511
> > bridge driver should not let the next bridge driver create
Hi,
On Fri, May 10, 2024 at 7:13 PM Cong Yang
wrote:
>
> The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller
> which fits in nicely with the existing panel-himax-hx83102 driver. Hence,
> we add a new compatible with panel specific config.
>
> Signed-off-by: Cong Yang
> --
Hi,
On Fri, May 10, 2024 at 7:14 PM Cong Yang
wrote:
>
> The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller
> which fits in nicely with the existing panel-himax-hx83102 driver. Hence,
> we add a new compatible with panel specific config.
>
> Signed-off-by: Cong Yang
> ---
>
Hi,
On Fri, May 10, 2024 at 7:13 PM Cong Yang
wrote:
>
> +static int hx83102_prepare(struct drm_panel *panel)
> +{
> + struct hx83102 *ctx = panel_to_hx83102(panel);
> + struct mipi_dsi_device *dsi = ctx->dsi;
> + struct device *dev = &dsi->dev;
> + int ret;
> +
> +
On Mon, May 13, 2024 at 4:16 AM Marek Vasut wrote:
>
> TC9595 datasheet Video Path0 Control (VPCTRL0) Register bit FRMSYNC
> description
> says "This bit should be disabled only in video mode transmission where Host
> transmits video timing together with video data and where pixel clock source
>
The Graphics and DRM Microconference was accepted for Linux Plumbers
2024! Please, submit your proposal in the following page:
https://lpc.events/event/18/abstracts/
Remember to select "Graphics & DRM MC" in the Track field. The deadline
for submissions is Sunday 30th June. The accepte
On Mon, 13 May 2024 at 16:17, Rob Herring wrote:
>
> On Thu, May 09, 2024 at 11:42:50AM +0200, Krzysztof Kozlowski wrote:
> > Hi,
> >
> > Cleanups for display panel bindings.
> >
> > Rob, maybe you could take entire set if it applies? I based it on
> > linux-next, so letl me know if I need to reba
On Mon, 13 May 2024 23:30:57 +0800, Sui Jingfeng wrote:
> The checks on the existence of bridge->encoder in the implementation of
> drm_bridge_funcs::attach() is not necessary, as it has already been checked
> in the drm_bridge_attach() function call by previous bridge or KMS driver.
> The drm_brid
On Mon, May 13, 2024 at 03:44:00PM +0200, AngeloGioacchino Del Regno wrote:
> Il 13/05/24 08:15, CK Hu (胡俊光) ha scritto:
> > On Fri, 2024-05-10 at 12:14 +0200, AngeloGioacchino Del Regno wrote:
> > > Il 10/05/24 11:34, CK Hu (胡俊光) ha scritto:
> > > > On Thu, 2024-05-09 at 11:27 +0200, AngeloGioacch
Hi,
On 5/13/24 16:02, Liu Ying wrote:
The connector is created by either this ADV7511 bridge driver or
any DRM device driver/previous bridge driver, so this ADV7511
bridge driver should not let the next bridge driver create connector.
If the next bridge is a HDMI connector, the next bridge dri
On Mon, May 13, 2024 at 12:03:07PM +0300, Marius Vlad wrote:
> Hi all,
> On Mon, May 13, 2024 at 10:08:38AM +0200, José Expósito wrote:
> > On Fri, May 10, 2024 at 06:19:45PM +0200, Louis Chauvet wrote:
> > > Le 09/05/24 - 18:18, Jim Shargo a écrit :
> > > > Sima--thanks SO MUCH for going through w
On Mon, May 13, 2024 at 02:14:51AM -0400, Deming Wang wrote:
> The mapings should be replaced by mappings.
>
> Signed-off-by: Deming Wang
Reviewed-by: Rodrigo Vivi
and pushed to drm-intel-gt-next
thanks for the patch
> ---
> drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 2 +-
> 1 file chan
From: Rob Clark
When debugging faults, it is useful to know how the BO is mapped (cached
vs WC, gpu readonly, etc).
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 1 +
drivers/gpu/drm/msm/msm_gpu.c | 6 --
drivers/gpu/drm/msm/msm_gpu.h | 1 +
3 f
Hi,
On 5/13/24 16:02, Liu Ying wrote:
The connector is created by either this ADV7511 bridge driver or
any DRM device driver/previous bridge driver, so this ADV7511
bridge driver should not let the next bridge driver create connector.
If the next bridge is a HDMI connector, the next bridge dri
Hi,
On Mon, May 13, 2024 at 2:30 AM Maxime Ripard wrote:
>
> Hi,
>
> On Wed, May 08, 2024 at 01:51:46PM -0700, Douglas Anderson wrote:
> > Through a cooperative effort between Hsin-Yi Wang and Dmitry
> > Baryshkov, we have realized the dev_err() in the
> > mipi_dsi_*_write_seq() macros was causin
On Fri, May 10, 2024 at 07:12:14PM +0100, Matthew Auld wrote:
> Hopefully make it clearer when to use devm vs drmm.
>
> Signed-off-by: Matthew Auld
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> ---
> drivers/gpu/drm/drm_managed.c | 42 +++
> 1 file
This is a note to let you know that I've just added the patch titled
drm/vmwgfx: Fix invalid reads in fence signaled events
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
The checks on the existence of bridge->encoder in the implementation of
drm_bridge_funcs::attach() is not necessary, as it has already been checked
in the drm_bridge_attach() function call by previous bridge or KMS driver.
The drm_bridge_attach() will quit with a negative error code returned if
it
The checks on the existence of bridge->encoder in the implementation of
drm_bridge_funcs::attach() is not necessary, as it has already been checked
in the drm_bridge_attach() function call by previous bridge or KMS driver.
The drm_bridge_attach() will quit with a negative error code returned if
it
In the lt9611uxc_connector_init() function, the check on the existence
of bridge->encoder is not necessary, as it has already been checked in
the drm_bridge_attach() function. And the check on the drm bridge core
happens before check in the implementation. Hence, it is guaranteed that
the .encoder
In the dw_mipi_dsi_bridge_attach() function, the check on the existence
of bridge->encoder is not necessary, as it has already been checked in
the drm_bridge_attach() function invocked by previous bridge or KMS driver.
The previous drm_bridge_attach() will quit with a negative error code
returned i
In the ge_b850v3_lvds_create_connector function, the check on the existence
of bridge->encoder is not necessary, as it has already been checked in the
drm_bridge_attach() function called by upstream bridge or driver. Hence, it
is guaranteed that the .encoder member of the drm_bridge instance is not
In the cdns_mhdp_connector_init() function, the check on the existence
of bridge->encoder is not necessary, as it has already been checked in
the drm_bridge_attach() function. As the cdns_mhdp_connector_init() is
only called by cdns_mhdp_attach(), it is guaranteed that the .encoder
member of the st
In the adv7511_connector_init() function, the check on the existence of
bridge->encoder is not necessary. As it has already been checked in the
drm_bridge_attach() which happens prior to the adv7511_bridge_attach()
get called. Also note that the adv7511_connector_init() is only called by
adv7511_br
In it6505_bridge_attach(), the check on the existence of 'bridge->encoder'
is not necessary, as it has already been checked in the drm_bridge_attach()
which happens prior to it6505_bridge_attach() get called. Note that the
it6505_bridge_attach() will only be called by .attach() of the previous
brid
Because the existence of 'bridge->encoder' has already been checked before
the panel_bridge_attach() function get called, and the drm_bridge_attach()
will quit with a negative error code returned if it fails for some reasons.
Hence, it is guaranteed that the .encoder member of the drm_bridge instan
Because the existence of 'bridge->encoder' has already been checked before
the ptn3460_bridge_attach() function get called, and drm_bridge_attach()
will quit with a negative error code returned if it fails for some reasons.
Hence, it is guaranteed that the .encoder member of the drm_bridge instance
Because the existence of 'bridge->encoder' has already been checked before
the simple_bridge_attach() function get called, and drm_bridge_attach()
will quit with a negative error code returned if it fails for some reasons.
Hence, it is guaranteed that the .encoder member of the drm_bridge instance
Because the existence of bridge->encoder has already been checked before
the simple_bridge_attach() function get called, And drm_bridge_attach()
will quit with a negative error code returned if it fails for some reasons.
Hence, it is guaranteed that the .encoder member of the drm_bridge instance
is
The checks on the existence of bridge->encoder in the implementation of
drm_bridge_funcs::attach() is not necessary, as it has already been checked
in the drm_bridge_attach() function call by previous bridge or KMS driver.
The drm_bridge_attach() will quit with a negative error code returned if
it
Revert "drm/nouveau/firmware: Fix SG_DEBUG error with nvkm_firmware_ctor()"
a222a6470d7eea91193946e8162066fa88da64c2
The errors I reported are the same as those quoted in the pull request for the
revert.
On 13/05/2024 08:43, Jani Nikula wrote:
> On Sat, 11 May 2024, Chris Clayton wrote:
>> Mmm,
This is a note to let you know that I've just added the patch titled
drm/vmwgfx: Fix invalid reads in fence signaled events
to the 5.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/vmwgfx: Fix invalid reads in fence signaled events
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/vmwgfx: Fix invalid reads in fence signaled events
to the 5.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/vmwgfx: Fix invalid reads in fence signaled events
to the 4.19-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/vmwgfx: Fix invalid reads in fence signaled events
to the 6.6-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/ttm: Print the memory decryption status just once
to the 6.6-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
d
This is a note to let you know that I've just added the patch titled
drm/vmwgfx: Fix invalid reads in fence signaled events
to the 6.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/ttm: Print the memory decryption status just once
to the 6.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
d
On 13/05/2024 16:11, Paneer Selvam, Arunpravin wrote:
Hi Matthew,
On 5/13/2024 1:49 PM, Matthew Auld wrote:
On 12/05/2024 08:59, Arunpravin Paneer Selvam wrote:
Allocate cleared blocks in the bias range when the DRM
buddy's clear avail is zero. This will validate the bias
range allocation in s
Hi Dave,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm-tip/drm-tip linus/master v6.9 next-20240513]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
Hi Matthew,
On 5/13/2024 1:49 PM, Matthew Auld wrote:
On 12/05/2024 08:59, Arunpravin Paneer Selvam wrote:
Allocate cleared blocks in the bias range when the DRM
buddy's clear avail is zero. This will validate the bias
range allocation in scenarios like system boot when no
cleared blocks are av
Le lundi 13 mai 2024 à 11:34 +0300, Laurent Pinchart a écrit :
> On Mon, May 13, 2024 at 10:29:22AM +0200, Maxime Ripard wrote:
> > On Wed, May 08, 2024 at 10:36:08AM +0200, Daniel Vetter wrote:
> > > On Tue, May 07, 2024 at 04:07:39PM -0400, Nicolas Dufresne wrote:
> > > > Hi,
> > > >
> > > > Le
On 5/13/24 9:57 AM, Marek Szyprowski wrote:
On 13.05.2024 04:16, Marek Vasut wrote:
Initialize the bridge on attach already, to force lanes into LP11
state, since attach does trigger attach of downstream bridges which
may trigger (e)DP AUX channel mode read.
This fixes a corner case where DSIM
Le lundi 13 mai 2024 à 15:51 +0200, Maxime Ripard a écrit :
> On Mon, May 13, 2024 at 09:42:00AM -0400, Nicolas Dufresne wrote:
> > Le lundi 13 mai 2024 à 10:29 +0200, Maxime Ripard a écrit :
> > > On Wed, May 08, 2024 at 10:36:08AM +0200, Daniel Vetter wrote:
> > > > On Tue, May 07, 2024 at 04:07:
On Tue, 07 May 2024 15:54:08 +, Paweł Anikiel wrote:
> Add a DisplayPort bus type and a multi-stream-support property
> indicating whether the interface supports MST.
>
> Signed-off-by: Paweł Anikiel
> ---
> .../devicetree/bindings/media/video-interfaces.yaml| 7 +++
> include/
1 - 100 of 216 matches
Mail list logo
