On 2024-10-17 09:06, Andy Yan wrote:
>
>
> Hi Robin,
>
> Thanks for your comment。
>
> At 2024-10-17 01:38:23, "Robin Murphy" wrote:
>> On 2024-09-20 9:20 am, Andy Yan wrote:
>>> From: Andy Yan
>>>
>>> The vop mmu support translate physical address upper 4 GB to iova
>>> below 4 GB. So set dm
Am 16.10.24 um 18:43 schrieb Adrián Larumbe:
On 16.10.2024 15:12, Christian König wrote:
Am 15.10.24 um 01:31 schrieb Adrián Larumbe:
Doesn't make any functional difference because generic dma_fence is the
first panfrost_fence structure member, but I guess it doesn't hurt either.
As discussed
Dave, Simona
This week's -next PR. Note the implicit fencing uapi fix.
Thanks,
Thomas
drm-xe-next-2024-10-17:
UAPI Changes:
- (Implicit) Fix the exec unnecessary implicit fencing (Matt Brost)
Driver Changes:
- Fix an inverted if statement (Colin)
- Fixes around display d3cold vs non-d3cold runt
Avoid hardcoding the LSPCON settle timeout because it takes a longer
time on certain chips made by certain vendors. Use the function that
already exists to determine the timeout.
Reviewed-by: Ankit Nautiyal
Signed-off-by: Giedrius Statkevičius
---
v2: add documentation about the parameter, apply
Am 17.10.24 um 04:47 schrieb Raag Jadav:
On Mon, Sep 30, 2024 at 01:08:41PM +0530, Raag Jadav wrote:
Introduce device wedged event, which will notify userspace of wedged
(hanged/unusable) state of the DRM device through a uevent. This is
useful especially in cases where the device is no longer o
Hi Dave & Sima,
Here goes drm-intel-fixes towards v6.12-rc4.
Just two DP MST fixes this round.
Regards, Joonas
***
drm-intel-fixes-2024-10-17:
- Two DP bandwidth related MST fixes
The following changes since commit 8e929cb546ee42c9a61d24fae60605e9e3192354:
Linux 6.12-rc3 (2024-10-13 14:33
Hello,
Our static analysis tool has identified a potential null-pointer dereference or
redundant null check related to the wait-completion synchronization mechanism in
amdgpu_dm.c in Linux 6.11.
Consider the following execution scenario:
dmub_aux_setconfig_callback() //731
if (adev->d
On Thu, 2024-10-17 at 12:08 +0200, Boris Brezillon wrote:
> On Thu, 17 Oct 2024 10:51:32 +0200
> Erik Faye-Lund wrote:
>
> > On Wed, 2024-10-16 at 16:18 +0200, Boris Brezillon wrote:
> > > On Wed, 16 Oct 2024 16:05:55 +0200
> > > Erik Faye-Lund wrote:
> > >
> > > > On Wed, 2024-10-16 at 15:02
Il 16/10/24 18:09, Rob Herring ha scritto:
On Wed, Oct 16, 2024 at 10:26 AM AngeloGioacchino Del Regno
wrote:
Il 16/10/24 16:00, Rob Herring ha scritto:
On Wed, Oct 16, 2024 at 4:23 AM AngeloGioacchino Del Regno
wrote:
Il 15/10/24 15:48, Rob Herring ha scritto:
On Tue, Oct 15, 2024 at 10:
On Wed, 2024-10-16 at 13:20 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> When writing to a drm_sched_entity's run-queue, writers are protected
> through the lock drm_sched_entity.rq_lock. This naming, however,
> frequently collides with the separate internal lock of struct
> drm_sched_
The `drm_atomic_helper_shutdown(dev)` is called only if
`priv->is_registered` is true, ensuring that it runs only when the device
has been properly registered. Otherwise, if it encounters a defer probe,
the following call trace will appear.
WARNING: CPU: 0 PID: 13 at drivers/gpu/drm/drm_atomic_sta
rn :warn : [ 111.104334] ---[ end trace ]---
kern :info : [ 111.116715] ok 4 drm_test_framebuffer_free
kern :info : [ 111.124711] ok 5 drm_test_framebuffer_init
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/ar
On 10/14/2024, Dmitry Baryshkov wrote:
[...]
+static int it6263_bridge_atomic_check(struct drm_bridge *bridge,
+struct drm_bridge_state *bridge_state,
+struct drm_crtc_state *crtc_state,
+
On Thu, 17 Oct 2024 10:51:32 +0200
Erik Faye-Lund wrote:
> On Wed, 2024-10-16 at 16:18 +0200, Boris Brezillon wrote:
> > On Wed, 16 Oct 2024 16:05:55 +0200
> > Erik Faye-Lund wrote:
> >
> > > On Wed, 2024-10-16 at 15:02 +0100, Robin Murphy wrote:
> > > > On 2024-10-16 2:50 pm, Erik Faye-Lun
On Wed, 2024-10-16 at 16:18 +0200, Boris Brezillon wrote:
> On Wed, 16 Oct 2024 16:05:55 +0200
> Erik Faye-Lund wrote:
>
> > On Wed, 2024-10-16 at 15:02 +0100, Robin Murphy wrote:
> > > On 2024-10-16 2:50 pm, Erik Faye-Lund wrote:
> > > > On Wed, 2024-10-16 at 15:16 +0200, Erik Faye-Lund wrote:
The SI9022 HDMI transmitter can be configured with a bus-width of 16,
18, or 24 bits. Introduce a bus-width property to the input endpoint,
specifying the number of parallel RGB input bits connected to the
transmitter.
Signed-off-by: Wadim Egorov
Reviewed-by: Krzysztof Kozlowski
---
v3: Add Revi
This patch series introduces a bus-width property for the SI9022 HDMI
transmitter, allowing the input bus format to be configured based on the
number of RGB input pins. The default is set to 24-bit if unspecified.
v3:
- Add Reviewed-by tag from Krzysztof
- Ensure bus_width is set/defaults to 2
Introduce a bus-width property to define the number of parallel RGB
input pins connected to the transmitter. The input bus formats are updated
accordingly. If the property is not specified, default to 24-bit bus-width.
Signed-off-by: Wadim Egorov
---
v3: Ensure bus_width is set/defaults to 24 eve
Just a friendly reminder.
09/10/24 16:15, Anastasia Belova пишет:
Switch to a managed drm device to cleanup some error handling
and make future work easier.
Fix dereference of NULL in meson_drv_bind_master by removing
drm_dev_put(drm) before meson_encoder_*_remove and
component_unbind_all where
On 16/10/2024 16:35, Bjorn Andersson wrote:
>>> @@ -1064,7 +1064,7 @@
>>> };
>>>
>>> gpi_dma0: dma-controller@90 {
>>> - #dma-cells = <3>;
>>> + #dma-cells = <4>;
>>> compatible = "qcom,sc7280-gpi-dma",
>>> "qcom
On 17/10/2024 08:12, Akhil P Oommen wrote:
> On Wed, Oct 16, 2024 at 09:50:04AM +0200, Krzysztof Kozlowski wrote:
>> On 15/10/2024 21:35, Akhil P Oommen wrote:
>>> On Mon, Oct 14, 2024 at 09:40:13AM +0200, Krzysztof Kozlowski wrote:
On Sat, Oct 12, 2024 at 01:59:30AM +0530, Akhil P Oommen wrot
Hi Robin,
Thanks for your comment。
At 2024-10-17 01:38:23, "Robin Murphy" wrote:
>On 2024-09-20 9:20 am, Andy Yan wrote:
>> From: Andy Yan
>>
>> The vop mmu support translate physical address upper 4 GB to iova
>> below 4 GB. So set dma mask to 64 bit to indicate we support address
>>> 4GB.
On Wed, 2024-10-16 at 13:20 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Leftovers from the earlier "DRM scheduler fixes and improvements"
> series.
>
> It looks the fixes have now propagated back to drm-misc-next so this
> should now
> be mergeable.
>
> It also needed a small rebase
Changes in v13:
- Added comment in commit description of patch [1/3] to warn about
new port scheme.
- The series is now fully reviewed, tested, hence *ready*.
Changes in v12:
- Added comment to describe graph for OVL_ADAPTOR in patch [3/3]
as suggested by CK Hu.
Changes in v11:
- Added
It is impossible to add each and every possible DDP path combination
for each and every possible combination of SoC and board: right now,
this driver hardcodes configuration for 10 SoCs and this is going to
grow larger and larger, and with new hacks like the introduction of
mtk_drm_route which is a
The display IPs in MediaTek SoCs support being interconnected with
different instances of DDP IPs (for example, merge0 or merge1) and/or
with different DDP IPs (for example, rdma can be connected with either
color, dpi, dsi, merge, etc), forming a full Display Data Path that
ends with an actual dis
Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths
per HW instance (so potentially up to six displays for multi-vdo SoCs).
The MMSYS or VDOSYS is always the first component in the DDP pipeline,
so it only supports an output port with multiple endpoints - where each
endpoint def
Hi Jens,
On Tue, 15 Oct 2024 at 15:47, Jens Wiklander wrote:
>
> Hi,
>
> This patch set allocates the restricted DMA-bufs via the TEE subsystem.
> This a complete rewrite compared to the previous patch set [1], and other
> earlier proposals [2] and [3] with a separate restricted heap.
>
> The TEE
bochs uses pcim_enable_device(), which causes pci_request_region() to
implicitly set up devres callbacks which will release the region on
driver detach. Despite this, the driver calls pci_release_regions()
manually on driver teardown.
Implicit devres has been deprecated in PCI in commit 81fcf28e74
Hi Dave, Simona,
A new pull request for drm-misc-next.
Cheers,
Maarten
drm-misc-next-2024-10-17:
drm-misc-next for v6.13:
Cross-subsystem Changes:
- Small fixes to dma-buf.
Core Changes:
- Convert many drivers to use video aperture helpers and remove the DRM
one.
Driver Changes:
- Add core
On Tue, 15 Oct 2024 00:31:36 +0100
Adrián Larumbe wrote:
> Drop the deprecated DRM driver allocation method in favour of
> devm_drm_dev_alloc(). Overall just make it the same as in Panthor.
> Also discard now superfluous generic and platform device pointers inside
> the main panfrost device struc
On Thu, Oct 17, 2024 at 04:58:12AM -0700, Christoph Hellwig wrote:
> On Wed, Oct 16, 2024 at 02:44:45PM -0300, Jason Gunthorpe wrote:
> > > > FWIW, I've been expecting this series to be rebased on top of Leon's
> > > > new DMA API series so it doesn't have this issue..
> > >
> > > That's not going
On 2024/10/17 20:13, Maxime Ripard wrote:
> On Thu, Oct 17, 2024 at 09:33:07AM GMT, Jinjie Ruan wrote:
diff --git a/include/drm/drm_kunit_helpers.h
b/include/drm/drm_kunit_helpers.h
index e7cc17ee4934..1e7fd4be550c 100644
--- a/include/drm/drm_kunit_helpers.h
+++ b/incl
On Thu, Oct 17, 2024 at 12:58:48PM +1100, Alistair Popple wrote:
> Actually I think the rule should be don't look at the page at
> all. hmm_range_fault() is about mirroring PTEs, no assumption should
> even be made about the existence or otherwise of a struct page.
We are not there yet..
> > We
Hi Dave, Sima,
here are the fixes from the misc tree for this week.
Best regards
Thomas
drm-misc-fixes-2024-10-17:
Short summary of fixes pull:
ast:
- Clear EDID on unplugged connectors
host1x:
- Fix boot on Tegra186
- Set DMA parameters
mgag200:
- Revert VBLANK support
panel:
- himax-hx8319
Il 16/10/24 16:17, Hsin-Te Yuan ha scritto:
In commit 9f428b95ac89 ("drm/mediatek: Add new color format MACROs in
OVL"), some new color formats are defined in the MACROs to make the
switch statement more concise. That commit was intended to be a no-op
cleanup. However, there are typos in these fo
On Thu, Oct 17, 2024 at 06:12:55AM -0700, Christoph Hellwig wrote:
> On Thu, Oct 17, 2024 at 10:05:39AM -0300, Jason Gunthorpe wrote:
> > Broadly I think whatever flow NVMe uses for P2P will apply to ODP as
> > well.
>
> ODP is a lot simpler than NVMe for P2P actually :(
What is your thinking the
Hi Jens,
On Tue, 15 Oct 2024 at 15:47, Jens Wiklander wrote:
>
> Add support in the OP-TEE backend driver for restricted memory
> allocation. The support is limited to only the SMC ABI and for secure
> video buffers.
>
> OP-TEE is probed for the range of restricted physical memory and a
> memory
On Thu, Oct 17, 2024 at 09:33:07AM GMT, Jinjie Ruan wrote:
> >> diff --git a/include/drm/drm_kunit_helpers.h
> >> b/include/drm/drm_kunit_helpers.h
> >> index e7cc17ee4934..1e7fd4be550c 100644
> >> --- a/include/drm/drm_kunit_helpers.h
> >> +++ b/include/drm/drm_kunit_helpers.h
> >> @@ -4,6 +4,7 @
Hi Jinjie,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on linus/master v6.12-rc3 next-20241017]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
On Thu, Oct 17, 2024 at 06:49:30AM -0700, Christoph Hellwig wrote:
> On Thu, Oct 17, 2024 at 10:46:44AM -0300, Jason Gunthorpe wrote:
> > On Thu, Oct 17, 2024 at 06:12:55AM -0700, Christoph Hellwig wrote:
> > > On Thu, Oct 17, 2024 at 10:05:39AM -0300, Jason Gunthorpe wrote:
> > > > Broadly I think
Hi Erik,
On 17/10/2024 09:51, Erik Faye-Lund wrote:
On Wed, 2024-10-16 at 16:18 +0200, Boris Brezillon wrote:
On Wed, 16 Oct 2024 16:05:55 +0200
Erik Faye-Lund wrote:
On Wed, 2024-10-16 at 15:02 +0100, Robin Murphy wrote:
On 2024-10-16 2:50 pm, Erik Faye-Lund wrote:
On Wed, 2024-10-16 at 1
Hi Maxime
On 10/17/2024 7:31 AM, Maxime Ripard wrote:
On Wed, Oct 16, 2024 at 06:21:06PM GMT, Jessica Zhang wrote:
Changes in v3:
- Dropped support for CWB on DP connectors for now
- Dropped unnecessary PINGPONG array in *_setup_cwb()
- Add a check to make sure CWB and CDM aren't supported simu
Non-contiguous VRAM cannot be mapped in Xe nor can non-visible VRAM
easily be accessed. Add ttm_bo_access, which is similar to
ttm_bo_vm_access, to access such memory.
Visible VRAM access is only supported at the momement but a follow up
can add GPU access to non-visible VRAM.
Suggested-by: Thoma
Patches should be split but quick RFC for feedback.
Matt
Matthew Brost (1):
drm/ttm, drm/xe: Add ttm_bo_access
drivers/gpu/drm/ttm/ttm_bo_vm.c | 20 +-
drivers/gpu/drm/xe/xe_bo.c | 48 +
include/drm/ttm/ttm_bo.h| 2 ++
3 files changed,
From: "Wachowski, Karol"
commit 39bc27bd688066a63e56f7f64ad34fae03fbe3b8 upstream.
Lack of check for copy-on-write (COW) mapping in drm_gem_shmem_mmap
allows users to call mmap with PROT_WRITE and MAP_PRIVATE flag
causing a kernel panic due to BUG_ON in vmf_insert_pfn_prot:
BUG_ON((vma->vm_flags
02410171619.be977af4-...@intel.com
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20241017/202410171619.be977af4-...@intel.com
kern :warn : [ 111.593780] [ cut here ]
kern :warn : [ 111.593995] WARNING: CPU: 0 P
On Tue, Oct 15, 2024 at 05:16:58PM -0700, Alan Previn wrote:
> Add missing tag for "Wa_14019159160 - Case 2" (for existing
> PXP code that ensures run alone mode bit is set to allow
> PxP-decryption.
>
> v5: - remove the max IP_VER check since new platforms that
>i915 supports needs this
Hi Raag,
Em 30/09/2024 04:38, Raag Jadav escreveu:
Introduce device wedged event, which will notify userspace of wedged
(hanged/unusable) state of the DRM device through a uevent. This is
useful especially in cases where the device is no longer operating as
expected even after a hardware reset a
On Tue, Oct 15, 2024 at 09:06:04AM -0700, Doug Anderson wrote:
> Hi,
>
> On Tue, Oct 15, 2024 at 4:46 AM Jean Delvare wrote:
> >
> > Since commit 0166dc11be91 ("of: make CONFIG_OF user selectable"), it
> > is possible to test-build any driver which depends on OF on any
> > architecture by explici
On 10/15/2024 4:46 AM, Jean Delvare wrote:
Since commit 0166dc11be91 ("of: make CONFIG_OF user selectable"), it
is possible to test-build any driver which depends on OF on any
architecture by explicitly selecting OF. Therefore depending on
COMPILE_TEST as an alternative is no longer needed.
T
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/display/intel_dp_mst.c
between commit:
69b3d8721267 ("drm/i915/dp_mst: Handle error during DSC BW overhead/slice
calculation")
from the drm-fixes tree and commit:
f2e2092a979c ("drm/i915/display: U
This was supposed to be an unlock instead of a lock. The original
code will lead to a deadlock.
Fixes: ee52489d1210 ("drm/amdgpu: Place NPS mode request on unload")
Signed-off-by: Dan Carpenter
---
>From static analysis, not testing.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 2 +-
1 file c
Matthew Brost writes:
> On Thu, Oct 17, 2024 at 04:49:11PM +1100, Alistair Popple wrote:
>>
>> Matthew Brost writes:
>>
>> > On Thu, Oct 17, 2024 at 02:21:13PM +1100, Alistair Popple wrote:
>> >>
>> >> Matthew Brost writes:
>> >>
>> >> > On Thu, Oct 17, 2024 at 12:49:55PM +1100, Alistair
From: Zichen Xie
This was found by a static analyzer.
There may be potential integer overflow issue in
exynos_drm_gem_dumb_create(). args->size is defined
as "__u64" while args->pitch and args->height are
both defined as "__u32". The result of
"args->pitch * args->height" will be limited to
"__u3
On Fri, Oct 18, 2024 at 08:58:02AM +1100, Alistair Popple wrote:
>
> Matthew Brost writes:
>
> > On Thu, Oct 17, 2024 at 04:49:11PM +1100, Alistair Popple wrote:
> >>
> >> Matthew Brost writes:
> >>
> >> > On Thu, Oct 17, 2024 at 02:21:13PM +1100, Alistair Popple wrote:
> >> >>
> >> >> Matth
Hi Jinjie,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.12-rc3 next-20241017]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
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
---
drivers/gpu/drm/mxsfb/Kconfig | 1 +
drivers/gpu/drm/mxsfb/lcdif_drv.c | 17 -
2 files chan
Hi,
This patch series aims to use drm_bridge_connector in the i.MX8MP LCDIF
driver so that bridge drivers don't need to initialize DRM connectors.
Patch 1-3 add HDMI connectors to some i.MX8MP platforms's DT as preparation
work. The Synopsys DW HDMI bridge core driver would try to find the bridg
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 we are using, hence
the next bridge can be found in dw_hdmi_parse_dt() according to the port
index, and furth
Add a HDMI connector to connect with i.MX8MP HDMI TX output.
This is a preparation for making the i.MX8MP LCDIF driver use
drm_bridge_connector which requires the DRM_BRIDGE_ATTACH_NO_CONNECTOR
flag. With that flag, the DW HDMI bridge core driver would
try to attach the next bridge which is the HD
Add a HDMI connector to connect with i.MX8MP HDMI TX output.
This is a preparation for making the i.MX8MP LCDIF driver use
drm_bridge_connector which requires the DRM_BRIDGE_ATTACH_NO_CONNECTOR
flag. With that flag, the DW HDMI bridge core driver would
try to attach the next bridge which is the HD
On 10/14/2024, Dmitry Baryshkov wrote:
> On Sun, Oct 13, 2024 at 10:48:54AM +, Biju Das wrote:
[...]
> +static int it6263_bridge_attach(struct drm_bridge *bridge,
> + enum drm_bridge_attach_flags flags) {
> + struct it6263 *it = bridge_to_it6263(bridge);
>>
Mika Penttilä writes:
> Hi,
>
> On 10/18/24 00:58, Alistair Popple wrote:
>> Matthew Brost writes:
>>
>>> On Thu, Oct 17, 2024 at 04:49:11PM +1100, Alistair Popple wrote:
Matthew Brost writes:
> On Thu, Oct 17, 2024 at 02:21:13PM +1100, Alistair Popple wrote:
>> Matthew Bros
Matthew Brost writes:
> On Fri, Oct 18, 2024 at 08:58:02AM +1100, Alistair Popple wrote:
>>
>> Matthew Brost writes:
>>
>> > On Thu, Oct 17, 2024 at 04:49:11PM +1100, Alistair Popple wrote:
>> >>
>> >> Matthew Brost writes:
>> >>
>> >> > On Thu, Oct 17, 2024 at 02:21:13PM +1100, Alistair
When dma_fence_unwrap_merge is called on fence chains where the fences
aren't ordered by context, the merging logic breaks down and we end up
inserting fences twice. Doing this repeatedly leads to the number of
fences going up exponentially, and in some gaming workloads we'll end up
running out of
Hi Linus,
Weekly fixes, msm and xe are the two main ones, with a bunch of
scattered fixes including a largish revert in mgag200, then amdgpu,
vmwgfx and scattering of other minor ones.
All seems pretty regular,
Regards,
Dave.
drm-fixes-2024-10-18:
drm fixes for 6.12-rc4
msm:
- Display:
- move
On 10/18/2024 1:10 AM, Dan Carpenter wrote:
> This was supposed to be an unlock instead of a lock. The original
> code will lead to a deadlock.
>
> Fixes: ee52489d1210 ("drm/amdgpu: Place NPS mode request on unload")
> Signed-off-by: Dan Carpenter
Thanks, this is being taken care with a foll
On 10/18/24 08:59, Alistair Popple wrote:
> Matthew Brost writes:
>
>> On Fri, Oct 18, 2024 at 08:58:02AM +1100, Alistair Popple wrote:
>>> Matthew Brost writes:
>>>
On Thu, Oct 17, 2024 at 04:49:11PM +1100, Alistair Popple wrote:
> Matthew Brost writes:
>
>> On Thu, Oct 17, 2
Hi Dave and Simona,
drm-xe-fixes for 6.12-rc4. Mostly some error path fixes and locking
adjustements. Timestamp bit width fixes delta time calculations in
userspace and one display fix for tile4 modifier in LNL/BMG.
thanks
Lucas De Marchi
drm-xe-fixes-2024-10-17:
Driver Changes:
- New workaroun
Hi,
On 10/18/24 00:58, Alistair Popple wrote:
> Matthew Brost writes:
>
>> On Thu, Oct 17, 2024 at 04:49:11PM +1100, Alistair Popple wrote:
>>> Matthew Brost writes:
>>>
On Thu, Oct 17, 2024 at 02:21:13PM +1100, Alistair Popple wrote:
> Matthew Brost writes:
>
>> On Thu, Oct 17
On Wed, 16 Oct 2024 23:06:50 +0300, Cristian Ciocaltea wrote:
> The Rockchip RK3588 SoC family integrates the Synopsys DesignWare HDMI
> 2.1 Quad-Pixel (QP) TX controller, which is a new IP block, quite
> different from those used in the previous generations of Rockchip SoCs.
>
> The controller su
On Wed, Oct 16, 2024 at 07:16:43PM GMT, Dave Stevenson wrote:
> Hi Stefan
>
> On Tue, 15 Oct 2024 at 22:13, Stefan Wahren wrote:
> >
> > Hi Dave,
> >
> > Am 15.10.24 um 11:32 schrieb Dave Stevenson:
> > > On Mon, 14 Oct 2024 at 22:16, Stefan Wahren wrote:
> > >>
> > >> Am 14.10.24 um 12:54 schri
On Wed, Oct 16, 2024 at 06:21:06PM GMT, Jessica Zhang wrote:
> Changes in v3:
> - Dropped support for CWB on DP connectors for now
> - Dropped unnecessary PINGPONG array in *_setup_cwb()
> - Add a check to make sure CWB and CDM aren't supported simultaneously
> (Dmitry)
> - Document cwb_enabled c
On Fri, 04 Oct 2024 16:00:41 +0530, Soutrik Mukhopadhyay wrote:
> This series adds support for the DisplayPort controller
> and eDP PHY v5 found on the Qualcomm SA8775P platform.
>
Applied, thanks!
[1/5] dt-bindings: phy: Add eDP PHY compatible for sa8775p
commit: 7adb3d221a4d6a4f5e0793c
e_reused = true;
ret = auxiliary_device_init(adev);
if (ret) {
---
base-commit: d61a00525464bfc5fe92c6ad713350988e492b88
change-id: 20241017-drm-aux-bridge-mark-of-node-reused-5c2ee740ff19
Best regards,
--
Abel Vesa
On Thu, Oct 17, 2024 at 04:49:11PM +1100, Alistair Popple wrote:
>
> Matthew Brost writes:
>
> > On Thu, Oct 17, 2024 at 02:21:13PM +1100, Alistair Popple wrote:
> >>
> >> Matthew Brost writes:
> >>
> >> > On Thu, Oct 17, 2024 at 12:49:55PM +1100, Alistair Popple wrote:
> >> >>
> >> >> Matth
On Wed, Oct 16, 2024 at 08:53:05PM -0700, Lizhi Hou wrote:
>
> On 10/14/24 19:13, Matthew Brost wrote:
> > On Fri, Oct 11, 2024 at 04:12:41PM -0700, Lizhi Hou wrote:
> > > Add interfaces for user application to submit command and wait for its
> > > completion.
> > >
> > > Co-developed-by: Min Ma
On Thu, Oct 17, 2024 at 05:10:07PM +0200, Thomas Hellström wrote:
> When using mutex_acquire_nest() with a nest_lock, lockdep refcounts the
> number of acquired lockdep_maps of mutexes of the same class, and also
> keeps a pointer to the first acquired lockdep_map of a class. That pointer
> is then
On Thu, Oct 17, 2024 at 06:35:26PM +0300, Abel Vesa wrote:
> There are some cases where sharing the of_node renders different resources
> providers confused about the same resource being shared by two different
> devices.
Can you be more specific about what type of issue you are trying to
avoid he
Userspace might poll a syncobj with the query ioctl. Call
dma_fence_enable_sw_signaling to ensure dma_fence_is_signaled returns
true in finite time.
---
panvk hits this issue when timeline semaphore is enabled. It uses the
transfer ioctl to propagate fences. dma_fence_unwrap_merge converts the
On Thu, 17 Oct 2024 at 16:59, Maxime Ripard wrote:
>
> On Thu, Oct 17, 2024 at 05:26:46PM GMT, Stefan Wahren wrote:
> > Am 17.10.24 um 16:27 schrieb Maxime Ripard:
> > > On Wed, Oct 16, 2024 at 07:16:43PM GMT, Dave Stevenson wrote:
> > > > Hi Stefan
> > > >
> > > > On Tue, 15 Oct 2024 at 22:13, St
On Thu, Oct 17, 2024 at 09:59:10AM +0200, Christian König wrote:
> Am 17.10.24 um 04:47 schrieb Raag Jadav:
> > On Mon, Sep 30, 2024 at 01:08:41PM +0530, Raag Jadav wrote:
> > > Introduce device wedged event, which will notify userspace of wedged
> > > (hanged/unusable) state of the DRM device thro
Hi Jinjie,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.12-rc3 next-20241017]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
On Thu, Oct 17, 2024 at 05:11:37AM +, Arnd Bergmann wrote:
> On Thu, Oct 17, 2024, at 00:26, Sean Christopherson wrote:
> > On Tue, Oct 15, 2024, Arnd Bergmann wrote:
> >> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> >> index 46301c06d18a..985cb78d8256 100644
> >>
Am 17.10.24 um 18:37 schrieb Dave Stevenson:
On Thu, 17 Oct 2024 at 16:59, Maxime Ripard wrote:
On Thu, Oct 17, 2024 at 05:26:46PM GMT, Stefan Wahren wrote:
Am 17.10.24 um 16:27 schrieb Maxime Ripard:
On Wed, Oct 16, 2024 at 07:16:43PM GMT, Dave Stevenson wrote:
Hi Stefan
On Tue, 15 Oct 202
When using mutex_acquire_nest() with a nest_lock, lockdep refcounts the
number of acquired lockdep_maps of mutexes of the same class, and also
keeps a pointer to the first acquired lockdep_map of a class. That pointer
is then used for various comparison-, printing- and checking purposes,
but there
Reports indicates that some userspace applications try to merge more than
80k of fences into a single dma_fence_array leading to a warning from
kzalloc() that the requested size becomes to big.
While that is clearly an userspace bug we should probably handle that case
gracefully in the kernel.
So
From: Karol Wachowski
Allow TILE_FUSE register to disable more than 1 tile.
The driver should not prevent such configurations from being functional.
Signed-off-by: Karol Wachowski
Reviewed-by: Jacek Lawrynowicz
Signed-off-by: Jacek Lawrynowicz
---
drivers/accel/ivpu/ivpu_hw_btrs.c | 12 +++--
From: Karol Wachowski
Defer root page table allocation and unify context init/fini functions.
Move allocation of the root page table from the file_priv_open function to
perform a lazy allocation approach during ivpu_bo_pin().
By doing so, we avoid the overhead of allocating page tables for simpl
From: Andrzej Kacprowski
Copy engine was deprecated by the FW and is no longer supported.
Compute engine includes all copy engine functionality and should be used
instead.
This change does not affect user space as the copy engine was never
used outside of a couple of tests.
Signed-off-by: Andrz
- Remove support for deprecated and unused copy engine
- Improved open() performance by lazy allocating MMU page tables
- Error handling fixes in MMU code
- Extend VPU address ranges to allow bigger workloads
Andrzej Kacprowski (1):
accel/ivpu: Remove copy engine support
Karol Wachowski (9)
From: Karol Wachowski
Ensure that all buffers that were created only partially through
allocated scatter-gather table are unmapped from MMU600 in case of errors.
Signed-off-by: Karol Wachowski
Reviewed-by: Jacek Lawrynowicz
Signed-off-by: Jacek Lawrynowicz
---
drivers/accel/ivpu/ivpu_mmu_con
From: Karol Wachowski
Remove custom ivpu_id_alloc() wrapper used for ID allocations
and replace it with standard xa_alloc_cyclic() API.
The idea behind ivpu_id_alloc() was to have monotonic IDs, so the driver
is easier to debug because same IDs are not reused all over. The same
can be achieved j
From: Karol Wachowski
Don't leave a context descriptor in case CFGI_ALL flush fails.
Mark it as invalid (by clearing valid bit) so nothing is left in
partially-initialized state.
Signed-off-by: Karol Wachowski
Reviewed-by: Jacek Lawrynowicz
Signed-off-by: Jacek Lawrynowicz
---
drivers/accel/
From: Karol Wachowski
Do not allocate preemption buffers when Mid Inference Preemption (MIP)
is disabled through test mode.
Rename IVPU_TEST_MODE_PREEMPTION_DISABLE to IVPU_TEST_MODE_MIP_DISABLE
to better describe that this test mode only disables MIP - job level
preemption will still occur.
Si
From: Karol Wachowski
Secondary preemption buffer is accessible by NPU's DMA and can be
allocated with addresses above 4 GB. Move secondary preemption buffer
allocation from SHAVE range which is much smaller (2GB) to DMA range.
This allows to allocate more command queues with corresponding
preemp
From: Karol Wachowski
Increase DMA address range to:
* 128 GB on 37xx (due to MMU limitations)
* 256 GB on other generations
Merge User and DMA ranges on 40xx and above as it is possible
to access whole 256 GBs from both FW and DMA.
Increase User range on 37xx from 255MB to 511MB
to allow load
From: Maciej Falkowski
Add CONFIG_DRM_ACCEL_IVPU_DEBUG option that:
- Adds -DDEBUG that enables printk regardless of the kernel config
- Enables unsafe module params (that are now disabled by default)
Signed-off-by: Maciej Falkowski
Reviewed-by: Jacek Lawrynowicz
Signed-off-by: Jacek Lawryno
From: Karol Wachowski
Use XArray for dynamic command queue ID allocations instead of fixed
ones. This is required by upcoming changes to UAPI that will allow to
manage command queues by user space instead of having predefined number
of queues in a context.
Signed-off-by: Karol Wachowski
Reviewe
1 - 100 of 105 matches
Mail list logo
