Hi Bjorn,
> Subject: Re: [PATCH v2 1/5] PCI/P2PDMA: Don't enforce ACS check for
> functions of same device
>
> On Thu, Oct 24, 2024 at 05:58:48AM +, Kasireddy, Vivek wrote:
> > > Subject: Re: [PATCH v2 1/5] PCI/P2PDMA: Don't enforce ACS check for
> > > functions of same device
> > >
> > > On
On 24.10.24 22:29, Matthew Brost wrote:
On Thu, Oct 24, 2024 at 02:41:57PM +0200, Christian König wrote:
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
Really, yikes.
Not really IME. Unless Chris
Virtual wide planes give high amount of flexibility, but it is not
always enough:
In parallel multirect case only the half of the usual width is supported
for tiled formats. Thus the whole width of two tiled multirect
rectangles can not be greater than max_linewidth, which is not enough
for some p
On Thu, Oct 10, 2024 at 06:43:35PM -0400, Stephen Boyd wrote:
> Quoting Dmitry Baryshkov (2024-09-19 03:40:19)
> > On Sat, Aug 31, 2024 at 09:06:51PM GMT, Stephen Boyd wrote:
> > > diff --git a/Documentation/devicetree/bindings/usb/usb-switch.yaml
> > > b/Documentation/devicetree/bindings/usb/usb-
On Wed, Oct 23, 2024 at 02:44:10PM +0200, Rouven Czerwinski wrote:
> The LXD M9189A panel is based on the EK79007AD3 DSI display controller.
> It currently supports only 4 lane operation.
>
> Signed-off-by: Rouven Czerwinski
> ---
> MAINTAINERS | 6 +
> drivers/gpu
On Thu, Oct 24, 2024 at 12:56:58AM +0530, Akhil P Oommen wrote:
> On 10/22/2024 11:19 AM, Krzysztof Kozlowski wrote:
> > On Mon, Oct 21, 2024 at 05:23:43PM +0530, Akhil P Oommen wrote:
> >> Add a new schema which extends opp-v2 to support a new vendor specific
> >> property required for Adreno GPUs
Hi Jani,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on next-20241024]
[cannot apply to drm-exynos/exynos-drm-next shawnguo/for-next
drm-xe/drm-xe-next linus/master v6.12-rc4]
[If your patch is applied to the
From: Qiang Yu
This is used when radeonsi export small texture's modifier
to user with eglExportDMABUFImageQueryMESA().
mesa changes is available here:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31658
Signed-off-by: Qiang Yu
---
include/uapi/drm/drm_fourcc.h | 1 +
1 file chang
On Tue, Oct 22, 2024 at 03:16:06AM +0530, Akhil P Oommen wrote:
> From: Puranam V G Tejaswi
>
> Enable GPU for sa8775p-ride platform and provide path for zap
> shader.
>
> Signed-off-by: Puranam V G Tejaswi
> Signed-off-by: Akhil P Oommen
> ---
> arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi | 8
On Tue, Oct 22, 2024 at 03:16:05AM +0530, Akhil P Oommen wrote:
> From: Puranam V G Tejaswi
>
> Add gpu and gmu nodes for sa8775p chipset. As of now all
> SKUs have the same GPU fmax, so there is no requirement of
> speed bin support.
>
> Signed-off-by: Puranam V G Tejaswi
> Signed-off-by: Akhi
On Wed, 23 Oct 2024 17:50:02 +0100, Dave Stevenson wrote:
> From: Maxime Ripard
>
> The BCM2712 has a completely different HVS than the previous
> generations, so let's add a new compatible for it.
>
> Signed-off-by: Maxime Ripard
> Signed-off-by: Dave Stevenson
> ---
> Documentation/device
On Fri, Oct 25, 2024 at 04:28:18AM +, Murthy, Arun R wrote:
> > > Subject: Re: [PATCH] drm/i915/display: plane property for async
> > > supported modifiers
> > >
> > > On Wed, Oct 16, 2024 at 04:54:09PM +0300, Ville Syrjälä wrote:
> > > > On Wed, Oct 16, 2024 at 04:30:19PM +0300, Ville Syrjälä
On Thu, Oct 24, 2024 at 11:55:37AM +0200, Herve Codina wrote:
> Both the TI SN65DSI83 and SN65DSI84 bridges have an IRQ pin to signal
> errors using interrupt.
>
> This interrupt is not documented in the binding.
>
> Add the missing interrupts property.
>
> Signed-off-by: Herve Codina
Acked-by
On 21/10/2024 22:18, Matthew Brost wrote:
Add xe_bo_vm_access which is wrapper around ttm_bo_vm_access which takes
rpm refs for device access.
Suggested-by: Thomas Hellström
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Auld
On Thu, 24 Oct 2024 15:54:31 +0100
Akash Goel wrote:
> This commit fixes the potential misalignment between the value of device
> tree property "dma-coherent" and default value of COHERENCY_ENABLE
> register.
> Panthor driver didn't explicitly program the COHERENCY_ENABLE register
> with the desi
Hi Dave,
kernel test robot noticed the following build errors:
[auto build test ERROR on 91e21479c81dd4e9e22a78d7446f92f6b96a7284]
url:
https://github.com/intel-lab-lkp/linux/commits/Dave-Stevenson/drm-vc4-Limit-max_bpc-to-8-on-Pi0-3/20241024-005239
base
On 24/10/2024 12:50, Dario Binacchi wrote:
From: Michael Trimarchi
The shutdown function can be called when the display is already
unprepared. For example during reboot this trigger a kernel
backlog. Calling the drm_panel_unprepare, allow us to avoid
to trigger the kernel warning.
Tested-by: D
Hi Maarten,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on drm-exynos/exynos-drm-next linus/master v6.12-rc4
next-20241024]
[cannot apply to tj-cgroup/for-next drm-xe/drm-xe-next akpm-mm/mm-everything
drm-intel/for
Hi Jani,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on next-20241024]
[cannot apply to drm-exynos/exynos-drm-next shawnguo/for-next
drm-xe/drm-xe-next linus/master v6.12-rc4]
[If your patch is applied to
Hi Jani,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on next-20241024]
[cannot apply to drm-exynos/exynos-drm-next shawnguo/for-next
drm-xe/drm-xe-next linus/master v6.12-rc4]
[If your patch is applied to the
On Wed, Oct 23, 2024 at 11:30:31AM +0300, Dan Carpenter wrote:
> The devm_drm_dev_alloc() function returns error pointers, it never
> returns NULL. Change that check to IS_ERR().
>
> The devm_gpiod_get_optional() function returns a mix of error pointers
> if there is an error, or NULL if there is
On Wed, Oct 23, 2024 at 9:19 PM Kuninori Morimoto
wrote:
>
>
> Hi Rob, Saravana, Tomi, Laurent, Sakari, Mark
>
> This is v8 patch-set
>
> Current Of-graph has "endpoint base" for loop, but doesn't have
> "port base" loop. "endpoint base" loop only is not enough.
> This patch-set add new "port base
+Robin for the MMU details
On Thu, 24 Oct 2024 15:54:30 +0100
Akash Goel wrote:
> Mali GPU Arch spec forbids the GPU PTEs to indicate Inner or Outer
> shareability when no_coherency protocol is selected. Doing so results in
> unexpected or undesired snooping of the CPU caches on some platforms,
> > Subject: Re: [PATCH] drm/i915/display: plane property for async
> > supported modifiers
> >
> > On Wed, Oct 16, 2024 at 04:54:09PM +0300, Ville Syrjälä wrote:
> > > On Wed, Oct 16, 2024 at 04:30:19PM +0300, Ville Syrjälä wrote:
> > > > On Wed, Oct 16, 2024 at 11:06:26AM +0530, Arun R Murthy wro
Make dpu_rm_print_state() also output the SSPP allocation state.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dp
Hi Yongbang,
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-rc4 next-20241024]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to
On Wed, Oct 23, 2024 at 04:15:31PM +0200, Philipp Stanner wrote:
> drm_sched_job_init()'s name suggests that after the function succeeded,
> parameter "job" will be fully initialized. This is not the case; some
> members are only later set, notably drm_sched_job.sched by
> drm_sched_job_arm().
>
>
Use the drm_rect_fp_to_int() helper instead of using the hand-written
code.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.
Split dpu_plane_atomic_check() function into two pieces:
dpu_plane_atomic_check_nosspp() performing generic checks on the pstate,
without touching the associated SSPP blocks,
and
dpu_plane_atomic_check_sspp(), which takes into account used SSPPs.
Signed-off-by: Dmitry Baryshkov
---
drivers/gp
On Wed, 23 Oct 2024 17:50:05 +0100, Dave Stevenson wrote:
> From: Maxime Ripard
>
> The BCM2712 has a MOPLET controller which is basically a TXP without the
> transpose feature.
>
> Express that by adding a new compatible for it.
>
> Signed-off-by: Maxime Ripard
> Signed-off-by: Dave Stevens
Hi Dave,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 91e21479c81dd4e9e22a78d7446f92f6b96a7284]
url:
https://github.com/intel-lab-lkp/linux/commits/Dave-Stevenson/drm-vc4-Limit-max_bpc-to-8-on-Pi0-3/20241024-005239
base
With all subsystems and drivers either declaring their dependence on
HAS_IOPORT or fencing I/O port specific code sections we can finally
make inb()/outb() and friends compile-time dependent on HAS_IOPORT as
suggested by Linus in the linked mail. The main benefit of this is that
on platforms such a
On Thu, Oct 17, 2024 at 12:51:08PM +1100, Alistair Popple wrote:
>
> Matthew Brost writes:
>
> > On Wed, Oct 16, 2024 at 03:00:08PM +1100, Alistair Popple wrote:
> >>
> >> Matthew Brost writes:
> >>
> >> > Avoid multiple CPU page faults to the same device page racing by trying
> >> > to lock
In preparation for virtualized planes support, move pstate->pipe
initialization from dpu_plane_reset() to dpu_plane_atomic_check(). In
case of virtual planes the plane's pipe will not be known up to the
point of atomic_check() callback.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dis
Only several SSPP blocks support such features as YUV output or scaling,
thus different DRM planes have different features. Properly utilizing
all planes requires the attention of the compositor, who should
prefer simpler planes to YUV-supporting ones. Otherwise it is very easy
to end up in a situ
Max upscale / downscale factors are constant between platforms. In
preparation to adding support for virtual planes and allocating SSPP
blocks on demand move max scaling factors out of the HW catalog and
handle them in the dpu_plane directly. If any of the scaling blocks gets
different limitations,
The virt_formats / virt_num_formats are not used by the current driver
and are not going to be used in future since formats for virtual planes
are handled in a different way, by forbidding unsupported combinations
during atomic_check. Drop those fields now.
Reviewed-by: Abhinav Kumar
Signed-off-b
As promised in the basic wide planes support ([1]) here comes a series
supporting 2*max_linewidth for all the planes.
Note: Unlike v1 and v2 this series finally includes support for
additional planes - having more planes than the number of SSPP blocks.
Note: this iteration features handling of ro
On Wed, 23 Oct 2024 17:50:03 +0100, Dave Stevenson wrote:
> From: Maxime Ripard
>
> The BCM2712 has 3 different pixelvalves that are similar to the ones
> found in the previous generations but with slightly different
> capabilities.
>
> Express that using a new set of compatibles.
>
> Signed-
On Wed, Oct 23, 2024 at 05:50:28PM +0100, Dave Stevenson wrote:
> From: Dom Cobley
>
> For performance/power it is beneficial to adjust gpu clocks with arm clock.
> This is how the downstream cpufreq driver works
>
> Signed-off-by: Dom Cobley
> Signed-off-by: Dave Stevenson
> ---
> drivers/cl
On Thu, Oct 24, 2024 at 02:41:57PM +0200, Christian König wrote:
> 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
Really, yikes.
> kzalloc() that the requested size becomes to big.
>
> While that i
On Wed, 23 Oct 2024 17:50:22 +0100, Dave Stevenson wrote:
> There are a few minor changes in the display list generation
> for the D-step of the chip, so add them.
>
> Signed-off-by: Dave Stevenson
Reviewed-by: Maxime Ripard
Thanks!
Maxime
On Wed, Oct 23, 2024 at 11:13:43PM -0700, Saravana Kannan wrote:
> fwnode needs to be set for a device for fw_devlink to be able to
> track/enforce its dependencies correctly. Without this, you'll see error
> messages like this when the supplier has probed and tries to make sure
> all its fwnode co
On 24/10/2024 16:34, Petr Mladek wrote:
On Wed 2024-10-23 14:00:13, Jocelyn Falempe wrote:
The console is already suspended in printk.c.
Does this mean that drm_log_client_suspend() is called
after suspend_console(), please?
To be honest, I wasn't able to tell which one is called first, and
Hi Maarten,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on drm-exynos/exynos-drm-next next-20241024]
[cannot apply to tj-cgroup/for-next drm-xe/drm-xe-next akpm-mm/mm-everything
drm-intel/for-linux-next drm-intel/for-linux
Hi Dave and Simona,
drm-xe-fixes for 6.12-rc5 with commits mostly improving error handling.
The g2h flush helps some LNL we are seeing, but we still have other 2
similar ones - however they didn't make it in time to drm-xe-next to be
properly tested, so I'm leaving for later.
There are 2 conflic
On Thu, Oct 24, 2024 at 12:33 PM Jani Nikula wrote:
>
> We stopped using the driver initialized date in commit 7fb8af6798e8
> ("drm: deprecate driver date") and (eventually) started returning "0"
> for drm_version ioctl instead.
>
> Finish the job, and remove the unused date member from struct
> d
On Wed, 23 Oct 2024 17:50:06 +0100, Dave Stevenson wrote:
> From: Maxime Ripard
>
> The BCM2712 SoC comes with a new variation of the videocore display
> pipeline. Let's create a new compatible for it.
>
> Signed-off-by: Maxime Ripard
> Signed-off-by: Dave Stevenson
> ---
> Documentation/de
On Wed, 23 Oct 2024 17:50:04 +0100, Dave Stevenson wrote:
> From: Maxime Ripard
>
> The BCM2712 has a MOP controller which is basically a new revision of
> the TXP.
>
> Express that by adding a new compatible for it.
>
> Signed-off-by: Maxime Ripard
> Signed-off-by: Dave Stevenson
> ---
>
On Wed, 23 Oct 2024 17:50:01 +0100, Dave Stevenson wrote:
> From: Maxime Ripard
>
> The BCM2712 HDMI controller uses a slightly different HDMI controller
> than the BCM2711, and a completely different PHY.
>
> Let's introduce a new compatible for it.
>
> Signed-off-by: Maxime Ripard
> Signed
On Sat, 19 Oct 2024 00:49:11 +0300, Dmitry Baryshkov wrote:
> One of the features that drm_bridge_connector can't handle currently is
> setting of the ycbcr_420_allowed flag on the connector. Add the flag to
> the drm_bridge struct and propagate it to the drm_connector as AND of
> all flags in the
Hi Yongbang,
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-rc4 next-20241024]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to
On Thu, Oct 24, 2024 at 07:52:11PM +0200, Thomas Hellstrom wrote:
> Hi, Dave & Simona,
>
> This week's drm-xe-next PR
>
> Thanks,
> Thomas
>
>
> drm-xe-next-2024-10-24:
> UAPI Changes:
> - Define and parse OA sync properties (Ashutosh)
>
> Driver Changes:
> - Add caller info to xe_gt_reset_asy
On Thu, Oct 24, 2024 at 05:58:48AM +, Kasireddy, Vivek wrote:
> > Subject: Re: [PATCH v2 1/5] PCI/P2PDMA: Don't enforce ACS check for
> > functions of same device
> >
> > On Sun, Oct 20, 2024 at 10:21:29PM -0700, Vivek Kasireddy wrote:
> > > Functions of the same PCI device (such as a PF and a
In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
compile time. We thus need to add HAS_IOPORT as dependency for those
drivers using them unconditionally. Some 8250 serial drivers support
MMIO only use, so fence only the parts requiring I/O ports and print an
error message if
In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
compile time. As hexagon does not support I/O port access it also
the GENERIC_IOMAP mechanism of dynamically choosing between I/O port and
MMIO access doesn't work so don't select it.
Reviewed-by: Brian Cain
Co-developed-by:
Hi All,
This is a follow up in my long running effort of making inb()/outb() and
similar I/O port accessors compile-time optional. After initially
sending this as a treewide series with the latest revision at[0]
we switched to per subsystem series. Now though as we're left with only
5 patches left
In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
compile time. We thus need to add HAS_IOPORT as dependency for those
drivers using them.
Co-developed-by: Arnd Bergmann
Signed-off-by: Arnd Bergmann
Signed-off-by: Niklas Schnelle
---
drivers/bluetooth/Kconfig | 6 +++---
Hi, Dave & Simona,
This week's drm-xe-next PR
Thanks,
Thomas
drm-xe-next-2024-10-24:
UAPI Changes:
- Define and parse OA sync properties (Ashutosh)
Driver Changes:
- Add caller info to xe_gt_reset_async (Nirmoy)
- A large forcewake rework / cleanup (Himal)
- A g2h response timeout fix (Badal)
On Fri, Sep 13, 2024 at 05:34:54PM +0300, Dan Carpenter wrote:
> The iommu_paging_domain_alloc() function doesn't return NULL pointers,
> it returns error pointers. Update the check to match.
>
> Fixes: 45c690aea8ee ("drm/tegra: Use iommu_paging_domain_alloc()")
> Signed-off-by: Dan Carpenter
>
On 10/24/24 17:06, Christoph Hellwig wrote:
On Thu, Oct 24, 2024 at 03:23:06PM +0100, Pavel Begunkov wrote:
That's not what this series does. It adds the new memory_provider_ops
set of hooks, with once implementation for dmabufs, and one for
io_uring zero copy.
First, it's not a _new_ abstrac
Jani Nikula writes:
Hello Jani,
> We stopped using the driver initialized date in commit 7fb8af6798e8
> ("drm: deprecate driver date") and (eventually) started returning "0"
> for drm_version ioctl instead.
>
> Finish the job, and remove the unused date member from struct
> drm_driver, its initi
We stopped using the driver initialized date in commit 7fb8af6798e8
("drm: deprecate driver date") and (eventually) started returning "0"
for drm_version ioctl instead.
Finish the job, and remove the unused date member from struct
drm_driver, its initialization from drivers, along with the common
On 2024-10-23 23:50, Kasireddy, Vivek wrote:
>> I'd echo many of Bjorn's concerns. In addition, I think the name of the
>> pci_devs_are_p2pdma_compatible() isn't quite right. Specifically this is
>> dealing with PCI functions within a single device that are known to
>> allow P2P traffic. So I th
On Wed, 23 Oct 2024 17:50:00 +0100, Dave Stevenson wrote:
> The frame count values moved within registers DISPSTAT1 and
> DISPSTAT2 with GEN5, so update the accessor function to
> accommodate that.
>
> Fixes: b51cd7ad143d ("drm/vc4: hvs: Fix frame count register readout")
>
> [ ... ]
Reviewed-by
On Wed, 23 Oct 2024 17:49:59 +0100, Dave Stevenson wrote:
> Use of_device_get_match_data to retrieve the generation value
> as set in the struct of_device_id, rather than manually comparing
> compatible strings.
>
> Signed-off-by: Dave Stevenson
>
> [ ... ]
Reviewed-by: Maxime Ripard
Thanks!
On Wed, 23 Oct 2024 17:50:26 +0100, Dave Stevenson wrote:
> It is permitted for a plane to be configured such that none
> of it is on-screen via either negative dest rectangle X,Y
> offset, or an offset that is greater than the crtc dimensions.
>
> These planes were resized via drm_atomic_helper_c
On Wed, 23 Oct 2024 17:50:23 +0100, Dave Stevenson wrote:
> The D-step has increased FIFO sizes of the MAI_THR blocks,
> resulting in changes to the register masking. Add support for
> it.
>
> Signed-off-by: Dave Stevenson
>
> [ ... ]
Reviewed-by: Maxime Ripard
Thanks!
Maxime
On Wed, 23 Oct 2024 17:50:21 +0100, Dave Stevenson wrote:
> THe registers have been moved around, and a couple of minor changes
> made, so adapt for this.
>
> Signed-off-by: Dave Stevenson
Reviewed-by: Maxime Ripard
Thanks!
Maxime
On 10/24/2024 03:17, Dan Carpenter wrote:
This NULL check is reversed so the function doesn't work.
Fixes: dad01f93f432 ("drm/amdgpu: validate hw_fini before function call")
Signed-off-by: Dan Carpenter
Thanks!
Reviewed-by: Mario Limonciello
Also applied to amd-staging-drm-next.
---
dr
On 21/10/2024 15:06, Boris Brezillon wrote:
> On Tue, 15 Oct 2024 00:31:37 +0100
> Adrián Larumbe wrote:
>
>> Just in case we're dealing with a yet not recognised device.
>
> While I can see how problematic it would be if we expose a GPU that
> requires kernel quirks we don't know about, I suspe
>
> On Mon, Sep 30, 2024 at 10:18:06AM +0200, Maxime Ripard wrote:
> > On Sun, Sep 29, 2024 at 02:34:36AM GMT, Sandor Yu wrote:
> > > > > +static void cdns_hdmi_sink_config(struct cdns_mhdp8501_device
> > > > > +*mhdp) {
> > > > > + struct drm_display_info *display =
> &mhdp->curr_conn->displ
On 10/24/24 10:23, Christoph Hellwig wrote:
On Wed, Oct 23, 2024 at 03:34:53PM +0100, Pavel Begunkov wrote:
It doesn't care much what kind of memory it is, nor it's important
for internals how it's imported, it's user addresses -> pages for
user convenience sake. All the net_iov setup code is in
On 21/10/2024 22:18, Matthew Brost wrote:
Non-contiguous VRAM cannot easily be mapped in TTM nor can non-visible
VRAM easily be accessed. Add ttm_bo_access, which is similar to
ttm_bo_vm_access, to access such memory.
v4:
- Fix checkpatch warnings (CI)
v5:
- Fix checkpatch warnings (CI)
Rep
Add a test which double checks that fences are in the expected order
after a merge.
While at it also switch to using a mock array for the complex test
instead of a merge.
Signed-off-by: Christian König
---
drivers/dma-buf/st-dma-fence-unwrap.c | 69 ++-
1 file changed, 6
On Fri, Oct 11, 2024 at 04:29:25PM +0200, Louis Chauvet wrote:
> On 11/10/24 - 12:49, Maxime Ripard wrote:
> > On Tue, Oct 08, 2024 at 11:23:22AM GMT, Louis Chauvet wrote:
> > >
> > > Hi,
> > >
> > > > > + * The YUV color representation were acquired via the colour python
> > > > > framework.
>
On Thu, Oct 24, 2024 at 02:05:53PM +0100, Will Deacon wrote:
> My recollection is hazy, but I seem to remember VFIO using the largest
> page sizes in the IOMMU 'pgsize_bitmap' for map() requests but then
> using the smallest page size for unmap() requests, so you'd end up
> cracking block mappings
Hi Jason,
On Fri, Oct 18, 2024 at 02:19:26PM -0300, Jason Gunthorpe wrote:
> Of the page table implementations (AMD v1/2, VT-D SS, ARM32, DART)
> arm_lpae is unique in how it handles partial unmap of large IOPTEs.
>
> All other drivers will unmap the large IOPTE and return it's length. For
> exa
Hi Dave, Sima,
this is the PR for drm-misc-fixes.
Best regards
Thomas
drm-misc-fixes-2024-10-24:
Short summary of fixes pull:
bridge:
- aux: Fix assignment of OF node
- tc358767: Add missing of_node_put() in error path
The following changes since commit 83f000784844cb9d4669ef1a3366479db3197b33:
On Tue, Oct 22, 2024 at 01:58:47PM -0400, Nicolas Dufresne wrote:
> Hi,
>
> Le mardi 22 octobre 2024 à 09:19 -0700, John Stultz a écrit :
> > On Tue, Oct 22, 2024 at 1:38 AM Maxime Ripard wrote:
> > >
> > > I wanted to follow-up on the discussion we had at Plumbers with John and
> > > T.J. about
Hi guys,
turned out that userspace can also merge dma_fence_chain contains
which can result in really huge arrays.
Fix those merges to sort the arrays and remove the duplicates.
Additional to that start to use kvzalloc() for dma_fence_array
containers so that can handle much larger arrays if nece
> -Original Message-
> From: dri-devel On Behalf Of
> Arun R Murthy
> Sent: Wednesday, September 25, 2024 8:38 PM
> To: intel...@lists.freedesktop.org; intel-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org
> Cc: Murthy, Arun R
> Subject: [PATCHv4 5/7] drm/i915/histogram:
Il 23/10/24 21:13, Saravana Kannan ha scritto:
fwnode needs to be set for a device for fw_devlink to be able to
track/enforce its dependencies correctly. Without this, you'll see error
messages like this when the supplier has probed and tries to make sure
all its fwnode consumers are linked to it
Hi
Am 24.10.24 um 12:46 schrieb Dario Binacchi:
Use aperture helpers to remove all generic graphics drivers before
loading mxsfb. Makes mxsfb compatible with simpledrm.
Co-developed-by: Michael Trimarchi
Signed-off-by: Michael Trimarchi
Signed-off-by: Dario Binacchi
---
drivers/gpu/drm/m
Use aperture helpers to remove all generic graphics drivers before
loading mxsfb. Makes mxsfb compatible with simpledrm.
Co-developed-by: Michael Trimarchi
Signed-off-by: Michael Trimarchi
Signed-off-by: Dario Binacchi
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 10 ++
1 file changed, 10
Hi Maarten,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on drm-exynos/exynos-drm-next next-20241024]
[cannot apply to tj-cgroup/for-next drm-xe/drm-xe-next akpm-mm/mm-everything
drm-intel/for-linux-next drm-intel/for-linux
Both the TI SN65DSI83 and SN65DSI84 bridges have an IRQ pin to signal
errors using interrupt.
This interrupt is not documented in the binding.
Add the missing interrupts property.
Signed-off-by: Herve Codina
---
.../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 3 +++
1 file cha
In some cases observed during ESD tests, the TI SN65DSI83 cannot recover
from errors by itself. A full restart of the bridge is needed in those
cases to have the bridge output LVDS signals again.
The TI SN65DSI83 has some error detection capabilities. Introduce an
error recovery mechanism based on
Hi,
Usually the TI SN65DSI83 recovers from error by itself but during ESD
tests, we have some cases where the TI SN65DSI83 didn't recover.
In order to handle those cases, this series adds support for a recovery
mechanism.
Best regards,
Hervé Codina
Herve Codina (2):
dt-bindings: display: brid
On Mon, Oct 21, 2024 at 01:18:20PM +0200, Niklas Schnelle wrote:
> On Mon, 2024-10-21 at 12:58 +0200, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 21.10.24 um 12:08 schrieb Arnd Bergmann:
> > > On Mon, Oct 21, 2024, at 07:52, Thomas Zimmermann wrote:
> > > > Am 08.10.24 um 14:39 schrieb Niklas Schne
On 23/10/2024 13:56, Christian König wrote:
Am 23.10.24 um 14:24 schrieb Tvrtko Ursulin:
[SNIP]
To fold or not the special placements (GWS, GDS & co) is also
tangential. In my patch I just preserved the legacy behaviour so it
can easily be tweaked on top.
Yeah, but again the original behav
Hi,
On Thu, Oct 10, 2024 at 07:39:06PM +0200, Louis Chauvet wrote:
> Currently drm_writeback_connector are created by
> drm_writeback_connector_init or drm_writeback_connector_init_with_encoder.
> Both of the function uses drm_connector_init and drm_encoder_init, but
> there is no way to properly
This NULL check is reversed so the function doesn't work.
Fixes: dad01f93f432 ("drm/amdgpu: validate hw_fini before function call")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/
Matthew Brost writes:
> On Tue, Oct 22, 2024 at 12:18:52PM +0300, Mika Kuoppala wrote:
>> Matthew Brost writes:
>>
>> > Non-contiguous VRAM cannot easily be mapped in TTM nor can non-visible
>> > VRAM easily be accessed. Add ttm_bo_access, which is similar to
>> > ttm_bo_vm_access, to access su
The patchset adds a new driver for Samsung AMS427AP24 panel with S6E88A0
controller. Patches are based on current branch drm-misc-next.
Changes in v3:
- Patch 2: Dropped the second "bindings" in the commit subject.
- Patch 2: Applied 4 spaces indentation in the example.
- Patch 3: Made struct s
On Wed, 23 Oct 2024 16:39:43 -0700 Matthew Brost
wrote:
> Part of series [1]. Sending as individual patch ahead of that series as
> this is a prerequisite for merging.
That's news to me - singleton patches are perfectly OK?
On Wed, 23 Oct 2024 16:39:44 -0700 Matthew Brost
wrote:
> Implement
The frame count values moved within registers DISPSTAT1 and
DISPSTAT2 with GEN5, so update the accessor function to
accommodate that.
Fixes: b51cd7ad143d ("drm/vc4: hvs: Fix frame count register readout")
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_hvs.c | 45 +
Hi Tejun,
Thanks a lot for your review.
On Wed, Oct 23, 2024 at 09:40:28AM -1000, Tejun Heo wrote:
> On Wed, Oct 23, 2024 at 09:52:53AM +0200, Maarten Lankhorst wrote:
> > New submission!
> > I've added documentation for each call, and integrated the renaming from
> > drm cgroup to dev cgroup, ba
1 - 100 of 107 matches
Mail list logo
