Hi Greg,
On Mon, Oct 21, 2024 at 8:39 AM Greg KH wrote:
> On Sun, Oct 20, 2024 at 05:36:29PM +0300, Laurent Pinchart wrote:
> > On Fri, Oct 18, 2024 at 04:31:21PM +0200, Greg KH wrote:
> > > On Fri, Oct 18, 2024 at 05:25:22PM +0300, Laurent Pinchart wrote:
> > > > On Fri, Oct 18, 2024 at 04:09:26
Add "jeida-30" and "vesa-30" data mappings that are compatible with JEIDA
and VESA respectively.
Signed-off-by: Liu Ying
---
v3:
* New patch.
.../bindings/display/lvds-data-mapping.yaml | 31 +++
1 file changed, 31 insertions(+)
diff --git a/Documentation/devicetree/bindings/
Add myself as the maintainer of ITE IT6263 LVDS TO HDMI BRIDGE DRIVER.
Signed-off-by: Liu Ying
---
v3:
* No change.
v2:
* New patch. (Maxime)
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index a858224b59d5..615ba0e905af 100644
--- a/MAINTAI
ITE IT6263 LVDS to HDMI converter is populated on NXP IMX-LVDS-HDMI
and IMX-DLVDS-HDMI adapter cards. The adapter cards can connect to
i.MX8MP EVK base board to support video output through HDMI connectors.
Build the ITE IT6263 driver as a module.
Signed-off-by: Liu Ying
---
v3:
* No change.
v2
One ITE IT6263 LVDS to HDMI converter is populated on NXP IMX-LVDS-HDMI
and IMX-DLVDS-HDMI adapter cards.
Card IMX-LVDS-HDMI supports single LVDS link(IT6263 link1).
Card IMX-DLVDS-HDMI supports dual LVDS links(IT6263 link1 and link2).
Only one card can be enabled with one i.MX8MP EVK.
Add dedic
Add basic HDMI video output support. Currently, only RGB888 output
pixel format is supported. At the LVDS input side, the driver
supports single LVDS link and dual LVDS links with "jeida-24" LVDS
mapping.
Product link:
https://www.ite.com.tw/en/product/cate1/IT6263
Signed-off-by: Liu Ying
---
v
Document ITE IT6263 LVDS to HDMI converter.
Product link:
https://www.ite.com.tw/en/product/cate1/IT6263
Signed-off-by: Liu Ying
---
v3:
* Reference lvds-dual-ports.yaml. (Dmitry)
* Add data-mapping DT property. (Dmitry, Biju)
* Allow data-mirror.
* Drop ite,lvds-link-num-data-lanes DT propert
"advantech,idk-2121wr" panel is a dual-link LVDS display device.
lvds-dual-ports.yaml documents dual-link LVDS display common properties.
Reference the ports property defined in lvds-dual-ports.yaml to save lines.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Liu Ying
---
v3:
* New patch. (Dmit
This schema documents LVDS panels with dual links. lvds-dual-ports.yaml
documents dual-link LVDS display common properties. Reference the ports
property defined in lvds-dual-ports.yaml to save lines.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Liu Ying
---
v3:
* New patch. (Dmitry)
.../pa
Dual-link LVDS displays receive odd pixels and even pixels separately from
dual LVDS links. One link receives odd pixels and the other receives even
pixels. Some of those displays may also use only one LVDS link to receive
all pixels, being odd and even agnostic. Document common properties for
t
drm_of_lvds_get_dual_link_pixel_order() gets LVDS dual-link source pixel
order. Similar to it, add it's counterpart function
drm_of_lvds_get_dual_link_pixel_order_sink() to get LVDS dual-link sink
pixel order.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Liu Ying
---
v3:
* New patch. (Dmitry)
Add two media bus formats that identify 30-bit RGB pixels transmitted
by a LVDS link with five differential data pairs, serialized into 7
time slots, using standard SPWG/VESA or JEIDA data mapping.
Signed-off-by: Liu Ying
---
v3:
* New patch.
.../media/v4l/subdev-formats.rst | 156
Add MEDIA_BUS_FMT_RGB101010_1X7X5_{JEIDA,SPWG} support in
drm_of_lvds_get_data_mapping() function implementation so that function
callers may get the two LVDS data mappings.
Signed-off-by: Liu Ying
---
v3:
* New patch.
drivers/gpu/drm/drm_of.c | 6 ++
1 file changed, 6 insertions(+)
diff -
Multiple display modes could be read from a display device's EDID.
Use clk_round_rate() to validate the "ldb" clock rate for each mode
in drm_bridge_funcs::mode_valid() to filter unsupported modes out.
Also, since this driver doesn't directly reference pixel clock, use
clk_round_rate() to validate
The next bridge in bridge chain could be a panel bridge or a non-panel
bridge. Use devm_drm_of_get_bridge() to replace the combination
function calls of of_drm_find_panel() and devm_drm_panel_bridge_add()
to get either a panel bridge or a non-panel bridge, instead of getting
a panel bridge only.
The LVDS panel "multi-inno,mi1010ait-1cp" used on this platform has
a typical pixel clock rate of 70MHz. Set "media_disp2_pix" clock rate
to that rate, instead of the original 68.9MHz. The LVDS serial clock
is controlled by "media_ldb" clock. It should run at 490MHz(7-fold the
pixel clock rate d
Hi,
This patch series aims to add ITE IT6263 LVDS to HDMI converter on
i.MX8MP EVK. Combined with LVDS receiver and HDMI 1.4a transmitter,
the IT6263 supports LVDS input and HDMI 1.4 output by conversion
function. IT6263 product link can be found at [1].
Patch 1 is a preparation patch to allow
On Sun, Oct 20, 2024 at 05:36:29PM +0300, Laurent Pinchart wrote:
> On Fri, Oct 18, 2024 at 04:31:21PM +0200, Greg KH wrote:
> > On Fri, Oct 18, 2024 at 05:25:22PM +0300, Laurent Pinchart wrote:
> > > On Fri, Oct 18, 2024 at 04:09:26PM +0200, Greg KH wrote:
> > > > On Fri, Oct 18, 2024 at 03:36:48P
hi
>-Original Message-
>From: Dmitry Baryshkov
>Sent: Sunday, October 20, 2024 9:57 PM
>To: Hermes Wu (吳佳宏)
>Cc: Andrzej Hajda ; Neil Armstrong
>; Robert Foss ; Laurent Pinchart
>; Jonas Karlman ; Jernej
>Skrabec ; Maarten Lankhorst
>; Maxime Ripard ;
>Thomas Zimmermann ; David Air
Functions of the same PCI device (such as a PF and a VF) share the
same bus and have a common root port and typically, the PF provisions
resources for the VF. Therefore, they can be considered compatible
as far as P2P access is considered.
Currently, although the distance (2) is correctly calculat
If the importer has allow_peer2peer set to true, then we can expect that
it would be able to handle VRAM addresses. Therefore, in this specific
case and only while running in VF mode, do not migrate the BO to System
RAM before exporting it.
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/xe/x
While testing [1] and [2] with a SRIOV enabled dGPU, it was noticed
that migrating a BO to System RAM before exporting it as a dmabuf
results in considerable performance degradation while running in a
Guest VM. For example, running a simple 3D app such as weston-simple-egl
would yield ~50 FPS inste
If a BO's is_devmem_external flag is set, it means that it is an
imported dmabuf BO that has a backing store in VRAM. Therefore, we
need to add XE_PPGTT_PTE_DM to the PTE flags as part of vm_bind.
v2:
- Use a cursor to iterate over the entries in the dma_addr array
instead of relying on SG itera
To properly import a dmabuf that is associated with a VF (or that
originates in a Guest VM that includes a VF), we need to know where
in LMEM the VF's allocated regions exist. Therefore, introduce a
new helper to return the object that backs the VF's regions in LMEM.
v2:
- Make the helper return t
For BOs of type ttm_bo_type_sg, that are backed by PCI BAR addresses
associated with a VF, we need to adjust and translate these addresses
to LMEM addresses to make the BOs usable by the PF. Otherwise, the BOs
(i.e, PCI BAR addresses) are only accessible by the CPU and not by
the GPU.
In order to
On 10/14/24 20:07, Peter Shkenev wrote:
> Currently, virtio uses its own dumb_map_offset implementation,
> virtio_gpu_mode_dumb_mmap. It works similarly to generic implementation,
> drm_gem_dumb_map_offset, and using the generic implementation is
> preferable (and making drivers to do so is a task
On 8/13/24 06:49, Vivek Kasireddy wrote:
> +long virtgpu_dma_buf_import_sgt(struct virtio_gpu_mem_entry **ents,
> + unsigned int *nents,
> + struct virtio_gpu_object *bo,
> + struct dma_buf_attachment *attach)
> +{
On 10/18/2024, Dmitry Baryshkov wrote:
> On Fri, Oct 18, 2024 at 02:48:13PM +0800, Liu Ying wrote:
>> Initialize a connector by calling drm_bridge_connector_init() for
>> each encoder so that down stream bridge drivers don't need to create
>> connectors any more.
>>
>> Signed-off-by: Liu Ying
>> -
On 10/18/2024, Dmitry Baryshkov wrote:
> On Fri, Oct 18, 2024 at 02:48:12PM +0800, Liu Ying wrote:
>> Set DW HDMI platform data's output_port to 1 in imx8mp_dw_hdmi_probe()
>> so that dw_hdmi_probe() called by imx8mp_dw_hdmi_probe() can tell the
>> DW HDMI bridge core driver about the output port w
From: Dongwon Kim
Having a fence linked to a virtio_gpu_framebuffer in the plane update
sequence would cause conflict when several planes referencing the same
framebuffer (e.g. Xorg screen covering multi-displays configured for an
extended mode) and those planes are updated concurrently. So it is
From: Dongwon Kim
Use drm_gem_plane_helper_prepare_fb() helper for explicit framebuffer
synchronization. We need to wait for explicit fences in a case of
Venus and native contexts when guest user space uses explicit fencing.
Signed-off-by: Dongwon Kim
[dmitry.osipe...@collabora.com>: Edit commi
From: Pierre-Eric Pelloux-Prayer
Xorg context creation fails for native contexts that use
VIRTGPU_CONTEXT_INIT because context is already initialized implicitly
when dumb buffer is created. Fix it by not creating default vrend context
if context_init is supported.
Signed-off-by: Pierre-Eric Pell
On Sat, Oct 19, 2024 at 10:41 AM Thomas Böhler wrote:
>
> The file drivers/gpu/drm/drm_panic_qr.rs has some lints that Clippy
> complains about. This series cleans them up by either allowing what is
> written or conforming to what Clippy expects where it makes sense.
Applied to `rust-next` -- tha
On 19.10.2024 17:18, Dmitry Baryshkov wrote:
> On Sun, Sep 08, 2024 at 02:04:45PM +0200, Heiner Kallweit wrote:
>> Series with DRM core improvements/refactorings.
>>
>> Heiner Kallweit (6):
>> drm/sysfs: Remove version attribute
>> drm/sysfs: Drop unused drm_class_device_(un)register
>> drm:
From: Christian Gmeiner
This patch adds a new ioctl, DRM_IOCTL_V3D_PERFMON_SET_GLOBAL, which
allows the configuration of a global performance monitor (perfmon).
The global perfmon is used for all jobs, ensuring consistent performance
tracking across submissions.
Signed-off-by: Christian Gmeiner
On Wed, Oct 16, 2024 at 10:55:56AM +0200, Thomas Hellström wrote:
> Following the design direction communicated here:
>
> https://lore.kernel.org/linux-mm/b7491378-defd-4f1c-31e2-29e4c77e2...@amd.com/T/#ma918844aa8a6efe8768fdcda0c6590d5c93850c9
>
> Export a LRU walker for driver shrinker use. The
On Wed, Oct 16, 2024 at 10:55:56AM +0200, Thomas Hellström wrote:
> Following the design direction communicated here:
>
> https://lore.kernel.org/linux-mm/b7491378-defd-4f1c-31e2-29e4c77e2...@amd.com/T/#ma918844aa8a6efe8768fdcda0c6590d5c93850c9
>
> Export a LRU walker for driver shrinker use. The
On Wed, Oct 16, 2024 at 10:55:54AM +0200, Thomas Hellström wrote:
> 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 large
On Fri, Oct 11, 2024 at 07:40:27PM -0700, Vivek Kasireddy wrote:
> If a BO's is_devmem_external flag is set, it means that it is an
> imported dmabuf BO that has a backing store in VRAM. Therefore, we
> need to add XE_PPGTT_PTE_DM to the PTE flags as part of vm_bind.
>
So here if we land on a DPA
On Tue, Oct 15, 2024 at 11:41:56PM -0600, Kasireddy, Vivek wrote:
> Hi Matt,
>
> >
> > On Fri, Oct 11, 2024 at 07:40:26PM -0700, Vivek Kasireddy wrote:
> > > For BOs of type ttm_bo_type_sg, that are backed by PCI BAR addresses
> > > associated with a VF, we need to adjust and translate these addr
On 18/10/2024 10:26, Zhu Yanjun wrote:
External email: Use caution opening links or attachments
在 2024/10/16 17:16, Yonatan Maman 写道:
On 16/10/2024 7:23, Christoph Hellwig wrote:
On Tue, Oct 15, 2024 at 06:23:44PM +0300, Yonatan Maman wrote:
From: Yonatan Maman
This patch series aims
On Fri, Oct 18, 2024 at 04:31:21PM +0200, Greg KH wrote:
> On Fri, Oct 18, 2024 at 05:25:22PM +0300, Laurent Pinchart wrote:
> > On Fri, Oct 18, 2024 at 04:09:26PM +0200, Greg KH wrote:
> > > On Fri, Oct 18, 2024 at 03:36:48PM +0200, Geert Uytterhoeven wrote:
> > > > On Fri, Oct 18, 2024 at 3:10 PM
On Wed, Oct 16, 2024 at 03:54:12PM +0800, Hermes Wu via B4 Relay wrote:
> This is a v6 patch-set.
>
> There are lots of failure items while running HDCP CTS using UNIGRAF DPR-100.
> In Order to fix those failures, HDCP flow needs to be changed.
>
> The DisplayPort AUX protocol supports I2C transp
On Wed, Oct 16, 2024 at 03:54:22PM +0800, Hermes Wu via B4 Relay wrote:
> From: Hermes Wu
>
> DisplayPort AUX protocol supports I2C transport which is capable of
> reading EDID or supports MCCS.
>
> In drm_dp_helper, drm_dp_i2c_xfer() packs I2C requests into a
> sequence of AUX requests.
> it650
On Wed, Oct 16, 2024 at 03:54:19PM +0800, Hermes Wu via B4 Relay wrote:
> From: Hermes Wu
>
> When running the HDCP CTS test with UNIGRAF DPR-100.
> KSV list must be read from DP_AUX_HDCP_KSV_FIFO in an AUX request,
> and can not separate with multiple read requests.
>
> The AUX operation comman
On Wed, Oct 16, 2024 at 03:54:16PM +0800, Hermes Wu via B4 Relay wrote:
> From: Hermes Wu
>
> A HDCP source device shall support max downstream to 127 devices.
> Change definition MAX_HDCP_DOWN_STREAM_COUNT to 127
>
> KSVs shall save for DRM blocked devices check.
> This results in struct it6505
On Wed, Oct 16, 2024 at 03:54:14PM +0800, Hermes Wu via B4 Relay wrote:
> From: Hermes Wu
>
> The original AUX operation using data registers is limited to 4 bytes.
> The AUX operation command CMD_AUX_I2C_EDID_READ uses AUX FIFO and
> is capable of reading 16 bytes.
> This improves the speed of E
On Wed, Oct 16, 2024 at 03:54:15PM +0800, Hermes Wu via B4 Relay wrote:
> From: Hermes Wu
>
> HDCP KSV list readback can choose to use AUX FIFO or
> general data register.
> For some DisplayPort devices, the KSV list must be read
> in 5 byte boundaries.
> The original AUX read command does not su
On Sun, Oct 20, 2024 at 01:35:29AM +0530, Aradhya Bhatia wrote:
> From: Aradhya Bhatia
>
> 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
>
On Sun, Oct 20, 2024 at 01:35:30AM +0530, Aradhya Bhatia wrote:
> 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-ds
On Sun, Oct 20, 2024 at 01:35:28AM +0530, Aradhya Bhatia wrote:
> 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 t
On Sun, Oct 20, 2024 at 01:35:27AM +0530, Aradhya Bhatia wrote:
> 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
>
On Sun, 20 Oct 2024 21:37:41 +1300, Ryan Walklin wrote:
> The Anbernic RG35XX devices use an SPI LCD panel from an unknown OEM,
> with an NV3052C driver chip.
>
> As discussed previously, the integrating vendor and device name are
> preferred instead of the OEM serial. A previous patch corrected t
On Sun, Oct 20, 2024 at 01:24:01AM +0530, Aradhya Bhatia wrote:
> From: Aradhya Bhatia
>
> Initialize the Phy during the cdns-dsi _resume(), and de-initialize it
> during the _suspend().
>
> Also power-off the Phy from bridge_disable.
Please describe why, not what. Especially, if it is consider
On Sun, Oct 20, 2024 at 01:24:00AM +0530, Aradhya Bhatia wrote:
> 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.
>
> Dr
On Sun, Oct 20, 2024 at 09:37:41PM +1300, Ryan Walklin wrote:
> The Anbernic RG35XX devices use an SPI LCD panel from an unknown OEM,
> with an NV3052C driver chip.
>
> As discussed previously, the integrating vendor and device name are
> preferred instead of the OEM serial. A previous patch corre
This is a note to let you know that I've just added the patch titled
drm/vmwgfx: Cleanup kms setup without 3d
to the 6.11-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:
drm-vmwgfx-cl
The Anbernic RG35XX devices use an SPI LCD panel from an unknown OEM,
with an NV3052C driver chip.
As discussed previously, the integrating vendor and device name are
preferred instead of the OEM serial. A previous patch corrected the
device tree binding and of_device_id in the NV3052C driver, how
58 matches
Mail list logo
