Typical dmabuf file reading steps:
1. dmabuf_fd = dmabuf_alloc(len, heap_fd)
2. vaddr = mmap(NULL, len, PROT_READ | PROT_WRITE, MAP_SHARED, dmabuf_fd, 0)
3. file_fd = open(file_path, O_RDONLY)
4. read(file_fd, vaddr, len)
dmabuf's attachment/map/fence model uses remap_pfn_range for mmap, which
lac
On Wed, Apr 30, 2025 at 4:36 PM Arnaldo Carvalho de Melo
wrote:
>
> On Wed, Apr 30, 2025 at 08:21:59AM -0700, Ian Rogers wrote:
> > On Thu, Apr 3, 2025 at 1:24 PM Ian Rogers wrote:
> > >
> > > DRM clients expose information through usage stats as documented in
> > > Documentation/gpu/drm-usage-st
On Tue, 06 May 2025 12:27:14 +0300, Svyatoslav Ryhel wrote:
> Add support for panels used in LG P880/P895 which are based on Renesas IC
> (not related to Renesas RISC-V architecture just the same manufacturer).
>
Applied to drm-misc-next, thanks!
[1/4] dt-bindings: display: panel: Document Renes
From: Michael Kelley
Current deferred I/O code works only for framebuffer memory that is
allocated with vmalloc(). The code assumes that the underlying page
refcount can be used by the mm subsystem to manage each framebuffer
page's lifecycle, which is consistent with vmalloc'ed memory, but not
wi
Look mom, no generic soup!
Anyway - this is just the last of the cleanup stuff I ended up while
working on cleaning up the gem shmem patch series. It simplifies the use
of generics and also adds a type alias for some very long types
currently in use. Also, drop one unused constant I noticed.
Appl
Add support for panels used in LG P880/P895 which are based on Renesas IC
(not related to Renesas RISC-V architecture just the same manufacturer).
---
Changes in v3:
- switch to devm_drm_panel_alloc
- rebased on top of drm-misc-next
Changes in v2:
- added IC vendor compatible ass fallback
- renam
On Wed, Apr 30, 2025 at 08:21:59AM -0700, Ian Rogers wrote:
> On Thu, Apr 3, 2025 at 1:24 PM Ian Rogers wrote:
> >
> > DRM clients expose information through usage stats as documented in
> > Documentation/gpu/drm-usage-stats.rst (available online at
> > https://docs.kernel.org/gpu/drm-usage-stats.
On Thu, Apr 3, 2025 at 1:24 PM Ian Rogers wrote:
>
> DRM clients expose information through usage stats as documented in
> Documentation/gpu/drm-usage-stats.rst (available online at
> https://docs.kernel.org/gpu/drm-usage-stats.html). Add a tool like
> PMU, similar to the hwmon PMU, that exposes D
On Sat, Apr 19, 2025 at 07:50:01AM +0800, Mauro Carvalho Chehab wrote:
> As reported by Andy, the Kernel build system runs kernel-doc script for DRM,
> when W=1. Due to Python's normal behavior, its JIT compiler will create
> a bytecode and store it under scripts/lib/*/__pycache__. As one may be u
As reported by Andy, the Kernel build system runs kernel-doc script for DRM,
when W=1. Due to Python's normal behavior, its JIT compiler will create
a bytecode and store it under scripts/lib/*/__pycache__. As one may be using
O= and even having the sources on a read-only mount point, disable its
c
DRM clients expose information through usage stats as documented in
Documentation/gpu/drm-usage-stats.rst (available online at
https://docs.kernel.org/gpu/drm-usage-stats.html). Add a tool like
PMU, similar to the hwmon PMU, that exposes DRM information.
v3: Minor tweak to the test so the skip (ex
Add tests that exercise the new drm_xe_vm_get_property uapi,
specifically for ioctl input validation and for determining that
pagefaults are correctly tracked and returned by the reporter.
drm_xe_vm_get_property ioctl to be added by
https://patchwork.freedesktop.org/series/145529/
v2:
- Remove en
This series adds the infrastructure needed for the refcounting
allocations for panels similar to Luca's efforts with bridges.
Underlying intention and idea is the same - avoid use-after-free
situations in panels. Get reference to panel when in use and put
the reference back (down) when not in use.
This patch series is aimed at providing UM with detailed memory profiling
information in debug builds. It is achieved through a device-wide list of
DRM GEM objects, and also implementing the ability to label BO's from UM
through a new IOCTL.
The new debugfs file shows a list of driver DRM GEM obje
Hi Janusz,
thanks for a quick response.
> > throughout the series you modify the code right after
> > introducing it.
>
> Yes, that split among patches reflects my way of getting to a solution that
> not only resolves the issue but also tries to address comments I got and take
> care of resul
Hi Krzysztof,
Thank you for looking at it.
On Thursday, 6 March 2025 12:00:40 CET Krzysztof Karas wrote:
> Hi Janusz,
>
> throughout the series you modify the code right after
> introducing it.
Yes, that split among patches reflects my way of getting to a solution that
not only resolves the i
Hi Janusz,
throughout the series you modify the code right after
introducing it. How about changing the order of things a bit:
1) order the functions in a symmetrical way between
register/unregister steps and group them as you see necessary,
(At that point you would not be fixing the issue ye
Starting with commit ec3e00b4ee27 ("drm/i915: stop registering if
drm_dev_register() fails"), we may return from i915_driver_register()
immediately, skipping remaining registration steps. However, the
_unregister() counterpart called at device remove knows nothing about that
skip and executes reve
There's an incresing number of machines supporting multiple page sizes
and, on these machines, the host and a guest can be running with
different pages sizes.
In addition to this, there might be devices that have a required and/or
preferred page size for mapping memory.
In this series, we extend
On Fri, 14 Feb 2025 16:08:40 +0100, Krzysztof Kozlowski wrote:
> Changes in v3:
> - Define bitfields in patches 1-3, so move there parts from patch #4
> - Use FIELD_GET
> - Keep separate cached->bit_clk_div and pix_clk_div
> - I think this implements entire feedback from Dmitry
> - Link to v2:
>
Changes in v3:
- Define bitfields in patches 1-3, so move there parts from patch #4
- Use FIELD_GET
- Keep separate cached->bit_clk_div and pix_clk_div
- I think this implements entire feedback from Dmitry
- Link to v2:
https://lore.kernel.org/r/20250203-drm-msm-phy-pll-cfg-reg-v2-0-862b136c5...@l
The mdp1-mem is not supported on the SM8550 & SM8650 SoCs, so properly document
the mdp0-mem and cpu-cfg interconnect entries.
This fixes the following errors:
display-subsystem@ae0: interconnects: [[200, 3, 7, 32, 1, 7]] is too short
from schema $id:
http://devicetree.org/schemas/dis
Hi,
On Wed, Jan 22, 2025 at 1:30 AM Langyan Ye
wrote:
>
> Hi Doug,
> Can you spare some time to help review it? Thanks a lot.
Sure. Let me see if I can figure out what's here:
v1:
- both panel patches got reviewed-by from Neil (nice!)
- wasn't well threaded
- After v4 was already out there, Dmi
Hi Doug,
Can you spare some time to help review it? Thanks a lot.
On Fri, Jan 17, 2025 at 5:14 PM Langyan Ye <
yelang...@huaqin.corp-partner.google.com> wrote:
> Fix the workflow of the previous email and resend it with all necessary
> recipient entries
>
> Changes in v3:
> - Link to v2:
> https:
Fix the workflow of the previous email and resend it with all necessary
recipient entries
Changes in v3:
- Link to v2:
https://lore.kernel.org/all/20250117050410.933312-1-yelang...@huaqin.corp-partner.google.com/
Changes in v2:
- PATCH 1/4: Add compatible for KINGDISPLAY KD110N11-51IE
- PATCH 2
On 2025/1/13 17:36, Dmitry Baryshkov wrote:
On Mon, Jan 13, 2025 at 05:26:56PM +0800, Yongxing Mou wrote:
On 2025/1/13 17:02, Dmitry Baryshkov wrote:
On Mon, Jan 13, 2025 at 04:03:07PM +0800, Yongxing Mou wrote:
This series introduces support to enable the Mobile Display Subsystem (MDSS)
On Mon, Jan 13, 2025 at 05:26:56PM +0800, Yongxing Mou wrote:
>
>
> On 2025/1/13 17:02, Dmitry Baryshkov wrote:
> > On Mon, Jan 13, 2025 at 04:03:07PM +0800, Yongxing Mou wrote:
> > > This series introduces support to enable the Mobile Display Subsystem
> > > (MDSS)
> > > , Display Processing Un
On 2025/1/13 17:02, Dmitry Baryshkov wrote:
On Mon, Jan 13, 2025 at 04:03:07PM +0800, Yongxing Mou wrote:
This series introduces support to enable the Mobile Display Subsystem (MDSS)
, Display Processing Unit (DPU), DisplayPort controller for the Qualcomm
QCS8300 target. It includes the addit
On Mon, Jan 13, 2025 at 04:03:07PM +0800, Yongxing Mou wrote:
> This series introduces support to enable the Mobile Display Subsystem (MDSS)
> , Display Processing Unit (DPU), DisplayPort controller for the Qualcomm
> QCS8300 target. It includes the addition of the hardware catalog, compatible
> s
This series introduces support to enable the Mobile Display Subsystem (MDSS)
, Display Processing Unit (DPU), DisplayPort controller for the Qualcomm
QCS8300 target. It includes the addition of the hardware catalog, compatible
string, and their YAML bindings.
Signed-off-by: Yongxing Mou
---
Chan
Looking at both i915 and nouveau DP drivers, both are setting the first
LTTPR (if found) in transparent mode first and then in non-transparent
mode, just like the DP v2.0 specification mentions in section 3.6.6.1.
Being part of the standard, setting the LTTPR in a specific operation mode
can be ea
On Fri, 20 Dec 2024 02:15:27 +0800, Jason-JH.Lin wrote:
> This patch series updates the compatible strings for the MediaTek OVL
> in the MT8188 dts and the corresponding dt-binding.
> The changes ensure that the MT8188 OVL device is correctly identified
> and managed by the appropriate drivers.
>
This patch series updates the compatible strings for the MediaTek OVL
in the MT8188 dts and the corresponding dt-binding.
The changes ensure that the MT8188 OVL device is correctly identified
and managed by the appropriate drivers.
The first patch is adding the MT8188 compatible strings, refer to:
Hi,
This patch set allocates the restricted DMA-bufs via the TEE subsystem.
This a big update compared to the previous patch set [1].
The TEE subsystem handles the DMA-buf allocations since it is the TEE
(OP-TEE, AMD-TEE, TS-TEE, or perhaps a future QTEE) which sets up the
restrictions for the me
Improves several parts of the devicetree:
1. The eDP panel bindings
2. Add a lid switch
3. Add bluetooth and describe wlan (depends on [1])
[1]:
https://lore.kernel.org/all/20241007-x1e80100-pwrseq-qcp-v1-0-f7166510a...@linaro.org/
---
I seem to get a warning that the pci17cb vendor is undocumen
This series brings small improvements to the DRM documentation, logging and
a warning on an incorrect code path.
Signed-off-by: Luca Ceresoli
---
Changes in v3:
- patch 3: various fixes suggested by Jani Nikula and kernel test robot
- Updated reviewed-by tags
- Link to v2:
https://lore.kernel.or
On Sat, Oct 26, 2024 at 10:02:51AM +0800, Jinjie Ruan wrote:
>
>
> On 2024/10/25 22:33, Maxime Ripard wrote:
> > On Wed, Oct 23, 2024 at 09:35:59AM +0800, Jinjie Ruan wrote:
> >>
> >>
> >> On 2024/10/18 16:12, Jinjie Ruan wrote:
> >>>
> >>>
> >>> On 2024/10/18 15:55, Maxime Ripard wrote:
> H
On 2024/10/25 22:33, Maxime Ripard wrote:
> On Wed, Oct 23, 2024 at 09:35:59AM +0800, Jinjie Ruan wrote:
>>
>>
>> On 2024/10/18 16:12, Jinjie Ruan wrote:
>>>
>>>
>>> On 2024/10/18 15:55, Maxime Ripard wrote:
Hi,
On Thu, Oct 17, 2024 at 02:31:21PM GMT, Jinjie Ruan wrote:
> Fix
On Wed, Oct 23, 2024 at 09:35:59AM +0800, Jinjie Ruan wrote:
>
>
> On 2024/10/18 16:12, Jinjie Ruan wrote:
> >
> >
> > On 2024/10/18 15:55, Maxime Ripard wrote:
> >> Hi,
> >>
> >> On Thu, Oct 17, 2024 at 02:31:21PM GMT, Jinjie Ruan wrote:
> >>> Fix some memory leaks in drm tests.
> >>>
> >>> Ch
On 2024/10/18 16:12, Jinjie Ruan wrote:
>
>
> On 2024/10/18 15:55, Maxime Ripard wrote:
>> Hi,
>>
>> On Thu, Oct 17, 2024 at 02:31:21PM GMT, Jinjie Ruan wrote:
>>> Fix some memory leaks in drm tests.
>>>
>>> Changes in v3:
>>> - Adjust drm/drm_edid.h header to drm_kunit_helpers.c.
>>> - Drop t
On Tue, Oct 08, 2024 at 04:37:42PM +0200, Frieder Schrempf wrote:
> Frieder Schrempf (4):
...
> arm64: dts: imx8mm-kontron: Add support for display bridges on BL
> i.MX8MM
> arm64: dts: imx8mm-kontron: Add DL (Display-Line) overlay with LVDS
> support
Applied both, thanks!
On 2024/10/18 15:55, Maxime Ripard wrote:
> Hi,
>
> On Thu, Oct 17, 2024 at 02:31:21PM GMT, Jinjie Ruan wrote:
>> Fix some memory leaks in drm tests.
>>
>> Changes in v3:
>> - Adjust drm/drm_edid.h header to drm_kunit_helpers.c.
>> - Drop the "helper" in the helper name.
>> - s/fllowing/followi
On 2024/10/18 15:55, Maxime Ripard wrote:
> Hi,
>
> On Thu, Oct 17, 2024 at 02:31:21PM GMT, Jinjie Ruan wrote:
>> Fix some memory leaks in drm tests.
>>
>> Changes in v3:
>> - Adjust drm/drm_edid.h header to drm_kunit_helpers.c.
>> - Drop the "helper" in the helper name.
>> - s/fllowing/followi
Hi,
On Thu, Oct 17, 2024 at 02:31:21PM GMT, Jinjie Ruan wrote:
> Fix some memory leaks in drm tests.
>
> Changes in v3:
> - Adjust drm/drm_edid.h header to drm_kunit_helpers.c.
> - Drop the "helper" in the helper name.
> - s/fllowing/following/
> - Add Acked-by.
This creates build failures since
Fix some memory leaks in drm tests.
Changes in v3:
- Adjust drm/drm_edid.h header to drm_kunit_helpers.c.
- Drop the "helper" in the helper name.
- s/fllowing/following/
- Add Acked-by.
Changes in v2:
- Fix it with new introduced helper instead of drm_mode_destroy().
- Update the commit message.
This add support for the display bridges (DSI->LVDS and DSI->HDMI)
on the BL i.MX8MM and the 7" LVDS panel in a separate overlay.
Only one of the interfaces (HDMI or LVDS) is supported at the same
time. Enabling the LVDS overlay will disable the HDMI interface.
* Patch 1 and 2: Add the necessary
On 05/10/2024 00:40, Caleb Connolly wrote:
Hi Jocelyn,
On 10/09/2024 08:56, Jocelyn Falempe wrote:
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 use
Hi Jocelyn,
On 10/09/2024 08:56, Jocelyn Falempe wrote:
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 input, or a terminal because this is bette
Le 17/09/24 - 18:02, José Expósito a écrit :
> Hi Louis,
>
> Thanks for making this change even more atomic.
>
> > To simplify the memory managment this series replace all manual drm
> > object managment by drm-managed one. This way the VKMS code don't have to
> > manage it directly and the DRM
Hi Louis,
Thanks for making this change even more atomic.
> To simplify the memory managment this series replace all manual drm
> object managment by drm-managed one. This way the VKMS code don't have to
> manage it directly and the DRM core will handle the object destruction.
>
> No functiona
To simplify the memory managment this series replace all manual drm
object managment by drm-managed one. This way the VKMS code don't have to
manage it directly and the DRM core will handle the object destruction.
No functional changes are intended in this series. This series depends on
[1] (fo
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 input, or a terminal because this is better done in
userspace.
If you're curious on how it looks li
On 09/09/24 15:20, Tomi Valkeinen wrote:
> On 09/09/2024 12:31, Aradhya Bhatia wrote:
>> Hi,
>>
>> Thank you, Francesco and Max, for testing and reporting this!
>>
>> On 09/09/24 13:45, Tomi Valkeinen wrote:
>>> Hi,
>>>
>>> On 06/09/2024 14:43, Francesco Dolcini wrote:
+Max
Hello
On 09/09/2024 12:31, Aradhya Bhatia wrote:
Hi,
Thank you, Francesco and Max, for testing and reporting this!
On 09/09/24 13:45, Tomi Valkeinen wrote:
Hi,
On 06/09/2024 14:43, Francesco Dolcini wrote:
+Max
Hello Aradhya,
On Tue, Jul 16, 2024 at 02:12:44PM +0530, Aradhya Bhatia wrote:
The a
On Mon, Sep 09, 2024 at 11:15:28AM +0300, Tomi Valkeinen wrote:
> Hi,
>
> On 06/09/2024 14:43, Francesco Dolcini wrote:
> > +Max
> >
> > Hello Aradhya,
> >
> > On Tue, Jul 16, 2024 at 02:12:44PM +0530, Aradhya Bhatia wrote:
> > > The addition of the 2nd OLDI TX (and a 2nd DSS in AM62Px) creates
Hi,
Thank you, Francesco and Max, for testing and reporting this!
On 09/09/24 13:45, Tomi Valkeinen wrote:
> Hi,
>
> On 06/09/2024 14:43, Francesco Dolcini wrote:
>> +Max
>>
>> Hello Aradhya,
>>
>> On Tue, Jul 16, 2024 at 02:12:44PM +0530, Aradhya Bhatia wrote:
>>> The addition of the 2nd OLDI T
Hi,
On 06/09/2024 14:43, Francesco Dolcini wrote:
+Max
Hello Aradhya,
On Tue, Jul 16, 2024 at 02:12:44PM +0530, Aradhya Bhatia wrote:
The addition of the 2nd OLDI TX (and a 2nd DSS in AM62Px) creates a need
for some major changes for a full feature experience.
1. The OF graph needs to be upd
+Max
Hello Aradhya,
On Tue, Jul 16, 2024 at 02:12:44PM +0530, Aradhya Bhatia wrote:
> The addition of the 2nd OLDI TX (and a 2nd DSS in AM62Px) creates a need
> for some major changes for a full feature experience.
>
> 1. The OF graph needs to be updated to accurately show the data flow.
> 2. Th
This patch series adds support for the Microchip's MIPI DSI Controller
wrapper driver that uses the Synopsys DesignWare MIPI DSI host controller
bridge for SAM9X75 SoC series.
Changelogs are available in respective patches.
Manikandan Muralidharan (4):
dt-bindings: display: bridge: add sam9x75-
After testing, there are more parameters that we're programming which
affect how UBWC tiles are laid out in memory and therefore affect
the Mesa implementation of VK_EXT_host_image_copy [1], which includes a
CPU implementation of tiling and detiling images. In particular we have:
1. ubwc_mode, whi
This patch series aims to add support for RZ/G2UL DU.
The LCD controller is composed of Frame Compression Processor (FCPVD),
Video Signal Processor (VSPD), and Display Unit (DU).
The output of LCDC is connected display parallel interface (DPI) and
supports a maximum resolution of WXGA along with
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 within TI-DSS.
- Some history and hardware desc
This series adds a new panic screen, with the kmsg data embedded in a QR code.
The main advantage of QR code, is that you can copy/paste the debug data to a
bug report.
The QR code encoder is written in rust, and is very specific to drm panic.
The reason is that it is called in a panic handler,
On 7/1/24 19:11, Zack Rusin wrote:
> This small series fixes all known prime/dumb_buffer/buffer dirty
> tracking issues. Fixing of dumb-buffers turned out to be a lot more
> complex than I wanted it to be. There's not much that can be done
> there because the driver has to support old userspace (ou
Running IGT tests on Qualcomm Dragonboard820c uncovered two issues with
the HDMI Connector implementation and with its integration into the
drm_bridge_connector. Fix those issues.
Note, I'm not fully satisfied with the drm_bridge_connector move. Maybe
it's better to add drm_bridge_funcs::connector
This small series fixes all known prime/dumb_buffer/buffer dirty
tracking issues. Fixing of dumb-buffers turned out to be a lot more
complex than I wanted it to be. There's not much that can be done
there because the driver has to support old userspace (our Xorg driver
expects those to not be gem b
On Sat, 15 Jun 2024 00:58:51 +0300, Danila Tikhonov wrote:
> This series adds MDSS and DPU support for SM7150.
>
> Changes in v3:
> - Swap DPU and MDSS patches (Krzysztof)
> - Add an explanation of the abbreviation DPU in patch 1 (Krzysztof)
> - Switch qseed3_1_4 on qseed3_2_4 in patch 2 (Dmitry
This series adds MDSS and DPU support for SM7150.
Changes in v3:
- Swap DPU and MDSS patches (Krzysztof)
- Add an explanation of the abbreviation DPU in patch 1 (Krzysztof)
- Switch qseed3_1_4 on qseed3_2_4 in patch 2 (Dmitry)
- Drop LM_4 and LM_5 in patch 2 (Dmitry)
- Add Krzysztof's R-b tag to p
This kingdisplay panel uses the jd9365da controller, so add it to
panel-jadard-jd9365da-h3.c driver, but because the init_code and timing
are different, some variables are added in struct jadard_panel_des to
control it.
In addition, since sending init_code in the enable() function takes a long
DT bits required for HDMI TX support in APQ8098 (msm8998 cousin)
Supersedes
Changes in v3
- Address Rob's comments on patch 2:
- 'maxItems: 5' for clocks in the 8996 if/then schema
- match the order of 8996 for the clock-names in common
---
Arnaud Vrac (1):
arm64: dts: qcom: add HDMI
Hi,
This is the new version of my patch series aiming at improving the
trace events around gpu jobs.
The main ideas implemented are: trace dependencies between jobs and
identify the GPU running jobs (because 'ring' is not a unique attribute).
Changes from v2:
* dropped all amdgpu changes. The goa
On Tue, May 21, 2024 at 2:47 PM Ian Forbes wrote:
>
> Fixes a bug where modes that are too large for the device are exposed
> and set causing a black screen on boot.
>
> v2: Fixed llvmpipe over-alignment bug.
> v3: Fix comment formatting.
>
> Ian Forbes (4):
> drm/vmwgfx: Filter modes which exce
Fixes a bug where modes that are too large for the device are exposed
and set causing a black screen on boot.
v2: Fixed llvmpipe over-alignment bug.
v3: Fix comment formatting.
Ian Forbes (4):
drm/vmwgfx: Filter modes which exceed graphics memory
drm/vmwgfx: 3D disabled should not effect STDU
Hi Raphael
On 2/23/24 13:36, Raphael Gallais-Pou wrote:
This serie aims to enable display support for the stm32mp135f-dk board
Those are only patches of the device-tree since the driver support has
already been added [1].
It respectivelly:
- adds support for the display controller on s
PCI subsystem provides callbacks to inform the driver about a request to
do function level reset by user, initiated by writing to sysfs entry
/sys/bus/pci/devices/.../reset. This will allow the driver to handle FLR
without the need to do unbind and rebind as the driver needs to
reinitialize the dev
On Tue, 02 Apr 2024 05:57:14 +0300, Dmitry Baryshkov wrote:
> Fix several warnings produced by the display nodes.
>
> Please excuse me for the spam for sending v3 soon after v2.
>
>
Applied, thanks!
[1/4] dt-bindings: display/msm: sm8150-mdss: add DP node
https://gitlab.freedesktop.org
On Tue, 02 Apr 2024 05:57:14 +0300, Dmitry Baryshkov wrote:
> Fix several warnings produced by the display nodes.
>
> Please excuse me for the spam for sending v3 soon after v2.
>
>
Applied, thanks!
[2/4] arm64: dts: qcom: sc8180x: drop legacy property #stream-id-cells
commit: 7fb5680b
Fix several warnings produced by the display nodes.
Please excuse me for the spam for sending v3 soon after v2.
Signed-off-by: Dmitry Baryshkov
---
Changes in v3:
- Added tags which I forgot in v2
- Added the Fixes tag to the dp_p1 fix
- Link to v2:
https://lore.kernel.org/r/20240402-fd-fix-sch
The LG SW43408 panel is used on Google Pixel3 devices. For a long time
we could not submit the driver, as the panel was not coming up from the
reset. The panel seems to be picky about some of the delays during init
and it also uses non-standard payload for MIPI_DSI_COMPRESSION_MODE.
Signed-off-by:
This patch-set is a prerequisite for a standalone TTM shrinker
and for exhaustive TTM eviction using sleeping dma_resv locks,
which is the motivation for it.
Currently when unlocking the TTM lru list lock, iteration needs
to be restarted from the beginning, rather from the next LRU list
node. This
This series is a follow up for 1a5e81de180e ("Revert "drm/panel-edp: Add
auo_b116xa3_mode""). It's found that 2 different AUO panels use the same
product id. One of them requires an overridden mode, while the other should
use the mode directly from edid.
Match the panel for both name and id. If no
Remove unused code, better input validation, and gup ufence
implementation. gup ufence implementation based some internal i915
patches. Tested with [1].
Matt
[1] https://patchwork.freedesktop.org/series/130417/
Matthew Brost (4):
drm/xe: Remove used xe_sync_entry_wait
drm/xe: Validate user f
Hi,
this series does basically two things:
1. Disables automatic load balancing as adviced by the hardware
workaround.
2. Assigns all the CCS slices to one single user engine. The user
will then be able to query only one CCS engine
I'm using here the "Requires: " tag, but I'm not sure the
This serie aims to enable display support for the stm32mp135f-dk board
Those are only patches of the device-tree since the driver support has
already been added [1].
It respectivelly:
- adds support for the display controller on stm32mp135
- adds pinctrl for the display controller
On Fri, 16 Feb 2024 11:10:47 +0100, Luca Weiss wrote:
> Introduce the bindings and panel driver for the LCD panel with the model
> number 9A-3R063-1102B from DJN which is using the HX83112A driver IC. It
> is used on the Fairphone 4 smartphone.
>
> Then we can add the panel to the device dts and
This patchset adds support for display for X1E80100.
The support for embedded DisplayPort on this platform will not
be enabled using the connetor type from driver match data,
but through some 'is-edp' property via DT. This subsequent work
will be part of a separate patchset.
Signed-off-by: Abel Ve
Hi,
On Fri, 16 Feb 2024 11:10:47 +0100, Luca Weiss wrote:
> Introduce the bindings and panel driver for the LCD panel with the model
> number 9A-3R063-1102B from DJN which is using the HX83112A driver IC. It
> is used on the Fairphone 4 smartphone.
>
> Then we can add the panel to the device dts
Introduce the bindings and panel driver for the LCD panel with the model
number 9A-3R063-1102B from DJN which is using the HX83112A driver IC. It
is used on the Fairphone 4 smartphone.
Then we can add the panel to the device dts and also enable the GPU.
Signed-off-by: Luca Weiss
---
Changes in v
This patch series introduces LVDS controller support for the SAM9X75 SoC. The
LVDS controller is designed to work with Microchip's sam9x7 series
System-on-Chip (SoC) devices, providing Low Voltage Differential Signaling
capabilities.
Patch series Changelog:
- Include configs: at91: Enable LVDS ser
From: Neil Armstrong
Hi,
On Tue, 02 Jan 2024 17:15:43 +0100, Manuel Traut wrote:
> This adds support for the BOE TH101MB31IG002 LCD Panel used in PineTab2 [1]
> and
> PineTab-V [2] as well as the devictrees for the PineTab2 v0.1 and v2.0.
>
> The BOE LCD Panel patch was retrieved from [3]. The
Hi,
This small patchset adds three new IOCTLs that can be used to attach,
detach, or transfer from/to a DMABUF object.
This interface is being used at Analog Devices, to transfer data from
high-speed transceivers to USB in a zero-copy fashion, using also the
DMABUF import interface to the IIO sub
Over the last several years the DPU driver has been actively developed,
while the MDP5 is mostly in the maintenance mode. This results in some
features being available only in the DPU driver. For example, bandwidth
scaling, writeback support, properly supported bonded DSI aka dual DSI
support, DSC
This patch series aims to add several features of the dw-mipi-dsi phy
driver that are missing or need to be updated.
First patch update a PM macro.
Second patch adds runtime PM functionality to the driver.
Third patch adds a clock provider generated by the PHY itself. As
explained in the commit
This adds support for the BOE TH101MB31IG002 LCD Panel used in PineTab2 [1] and
PineTab-V [2] as well as the devictrees for the PineTab2 v0.1 and v2.0.
The BOE LCD Panel patch was retrieved from [3]. The function-name prefix has
been adapted and the LCD init section was simplified.
The PineTab2 d
Hello,
This patch-set adds support for the family of SSD133x Solomon controllers,
such as the SSD1331. These are used for RGB Dot Matrix OLED/PLED panels.
This is a v3 that addresses issues pointed out in v2:
https://lore.kernel.org/dri-devel/20231218132045.2066576-1-javi...@redhat.com/
The pat
I'm going to merge this patchset through drm-misc-next
Am 06.12.23 um 14:50 schrieb Thomas Zimmermann:
Replace the global instance of screen_info with the per-device instance
that is set by the sysfb code. The use of the global screen_info should
be limited and ideally be pushed into per-archite
Hi,
this is just a resend of this series:
https://patchwork.freedesktop.org/series/125583/
but I removed patch one that introduces guc_to_i915()
Thanks,
Andi
Changelog:
==
v2 -> v3:
- Remove patch 1 that contained guc_to_i915()
v1 -> v2:
- add the gt_to_guc() helper and change files
Replace the global instance of screen_info with the per-device instance
that is set by the sysfb code. The use of the global screen_info should
be limited and ideally be pushed into per-architecture code.
v3:
* better const correctness in efifb (Sui)
* fix build for deferred takeov
This series includes patches to update the V3D kernel module
that drives the VideoCore VI GPU in Raspberry Pi 4 to also support
the Video Core VII iteration present in Raspberry Pi 5.
The first patch in the series adds a small uAPI update required for
TFU jobs, the second patch addresses the bulk
On Wed, 18 Oct 2023 17:41:22 +0800, Andy Yan wrote:
> From: Andy Yan
>
>
> This is a preparation for the upcoming support for rk3588 vop.
>
> Patch 1 make the bpp calculation covery more format
> Patch 2 remove formats that are unsupported by cluster windows
> Patch 3 add more formats
> Patch 4
1 - 100 of 379 matches
Mail list logo
