On 29/01/2024 14:18, Abel Vesa wrote:
> Document the DPU for Qualcomm X1E80100 platform in the SM8650 schema, as
> they are similar.
>
> Signed-off-by: Abel Vesa
> ---
> Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
On 29/01/2024 14:18, Abel Vesa wrote:
> Document the MDSS hardware found on the Qualcomm X1E80100 platform.
>
> Signed-off-by: Abel Vesa
> ---
Please document dependencies, including the ones not in the tree this is
targeting. You have build failures, so that deserves some note.
> .../bindings
Hi, Oak
On 1/29/24 21:29, Zeng, Oak wrote:
Hi Thomas,
My patch was based on drm-tip because I found drm-tip is broken
Yes, but drm-tip is rebuilt and force-pushed every time any of the
merged branches adds a new commit, so any commit needs to land in any of
the included branches, an
On Fri, Jan 26, 2024 at 07:43:29PM +0300, Dmitry Osipenko wrote:
> On 1/26/24 13:18, Boris Brezillon wrote:
> > On Thu, 25 Jan 2024 18:24:04 +0100
> > Daniel Vetter wrote:
> >
> >> On Fri, Jan 05, 2024 at 09:46:03PM +0300, Dmitry Osipenko wrote:
> >>> Add lockless drm_gem_shmem_get_pages() helper
https://bugzilla.kernel.org/show_bug.cgi?id=218435
Bug ID: 218435
Summary: UBSAN: array-index-out-of-bounds in
radeon_atombios.c:2620:43
Product: Drivers
Version: 2.5
Hardware: All
OS: Linux
Stat
https://bugzilla.kernel.org/show_bug.cgi?id=218435
--- Comment #1 from Sergey Belyashov (sergey.belyas...@gmail.com) ---
Created attachment 305790
--> https://bugzilla.kernel.org/attachment.cgi?id=305790&action=edit
dmesg output
--
You may reply to this email to add a comment.
You are receivi
On Thu, Jan 25, 2024 at 10:07:03AM +0100, Boris Brezillon wrote:
> On Fri, 5 Jan 2024 21:46:16 +0300
> Dmitry Osipenko wrote:
>
> > *
> > * This function Increases the use count and allocates the backing pages if
> > * use-count equals to zero.
> > + *
> > + * Note that this function doesn
Am 30.01.24 um 01:21 schrieb Zeng, Oak:
The example you used to prove that KFD is a design failure, is against
*any* design which utilize system allocator and hmm. The way that one
proxy process running on host to handle many guest processes, doesn’t
fit into the concept of “share address spa
Hi, Oak,
On 1/30/24 01:21, Zeng, Oak wrote:
The example you used to prove that KFD is a design failure, is against
*any* design which utilize system allocator and hmm. The way that one
proxy process running on host to handle many guest processes, doesn’t
fit into the concept of “share addres
On Mon, Jan 29, 2024 at 11:05:12AM -0800, Abhinav Kumar wrote:
>
>
> Hi Maxime
>
> On 1/26/2024 4:45 AM, Maxime Ripard wrote:
> > On Wed, Jan 17, 2024 at 09:36:20AM -0800, Abhinav Kumar wrote:
> > > Hi Jani and Maxime
> > >
> > > On 1/17/2024 2:16 AM, Jani Nikula wrote:
> > > > On Wed, 17 Jan 2
On Fri, Jan 26, 2024 at 05:42:50PM +0100, Christian König wrote:
> Am 25.01.24 um 19:01 schrieb Daniel Vetter:
> > On Thu, Jan 25, 2024 at 04:00:16PM +0100, Christian König wrote:
> > > Am 24.01.24 um 11:58 schrieb Paul Cercueil:
> > > > [SNIP]
> > > > > > The problem was then that dma_buf_unmap_at
Hi Michael,
On Mon, Jan 29, 2024 at 5:06 PM Michael Walle wrote:
>
> >> Just FYI this conflictted pretty heavily with drm-misc-next changes in
> >> the same area, someone should check drm-tip has the correct
> >> resolution, I'm not really sure what is definitely should be.
> >
> > FWIW, this loo
Am 30.01.24 um 10:01 schrieb Daniel Vetter:
On Fri, Jan 26, 2024 at 05:42:50PM +0100, Christian König wrote:
[SNIP]
Well I think we should have some solution, but I'm not sure if it should be
part of DMA-buf.
Essentially a DMA-buf exports the buffers as he uses it and the importer (or
the DMA-b
Hi Dario,
>> Just FYI this conflictted pretty heavily with drm-misc-next changes in
>> the same area, someone should check drm-tip has the correct
>> resolution, I'm not really sure what is definitely should be.
>
> FWIW, this looks rather messy now. The drm-tip doesn't build.
>
> There was a ne
Problem:
The computer in the bios initialization process, unplug the HDMI display,
wait until the system up, plug in the HDMI display, did not enter the
hotplug interrupt function, the display is not bright.
Fix:
After the above problem occurs, and the hpd ack interrupt bit is 1,
the interrupt sho
Problem:
The computer in the bios initialization process, unplug the HDMI display,
wait until the system up, plug in the HDMI display, did not enter the
hotplug interrupt function, the display is not bright.
Fix:
After the above problem occurs, and the hpd ack interrupt bit is 1,
the interrupt sho
Hi Christian,
(Your email software is configured for HTML btw)
Le mardi 30 janvier 2024 à 10:23 +0100, Christian König a écrit :
> Am 30.01.24 um 10:01 schrieb Daniel Vetter:
>
> >
> > On Fri, Jan 26, 2024 at 05:42:50PM +0100, Christian König wrote:
> >
> > > [SNIP]
> > > Well I think we
On 1/30/24 11:39, Daniel Vetter wrote:
> On Thu, Jan 25, 2024 at 10:07:03AM +0100, Boris Brezillon wrote:
>> On Fri, 5 Jan 2024 21:46:16 +0300
>> Dmitry Osipenko wrote:
>>
>>> *
>>> * This function Increases the use count and allocates the backing pages if
>>> * use-count equals to zero.
>>
On 1/30/24 11:34, Daniel Vetter wrote:
> On Fri, Jan 26, 2024 at 07:43:29PM +0300, Dmitry Osipenko wrote:
>> On 1/26/24 13:18, Boris Brezillon wrote:
>>> On Thu, 25 Jan 2024 18:24:04 +0100
>>> Daniel Vetter wrote:
>>>
On Fri, Jan 05, 2024 at 09:46:03PM +0300, Dmitry Osipenko wrote:
> Add
Add struct drm_pixmap to wrap the source parameters for all drawing
operations. This consists of the format, the clipping rectangle, the
line pitch and source data buffers. Also add a helper that creates a
pixmap from a framebuffer.
Existing code uses struct drm_framebuffer for drawing. Converting
Store the source-buffer parameters of drm_fb_memcpy() in struct
drm_pixmap. Update the function's interface and all of its callers.
Callers of drm_fb_memcpy() initialize the pixmap's instance from a
pre-existing instance of struct drm_framebuffer. There's potential
to simplify some of that code in
Implement drm_fb_xfrm() with struct drm_pixmap and adapt all
callers. The internal instances if struct drm_pixmap will eventually
be pushed into external callers of the format-helper interface.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_format_helper.c | 76 +---
Store the source-buffer parameters of drm_fb_xrgb_to_rgb565()
in struct drm_pixmap. Update the function's interface and all of its
callers.
Callers of drm_fb_xrgb_to_rgb565() initialize the pixmap's
instance from a pre-existing instance of struct drm_framebuffer.
There's potential to simpl
Store the source-buffer parameters of drm_fb_xrgb_to_abgr()
in struct drm_pixmap. Update the function's interface and all of its
callers.
Callers of drm_fb_xrgb_to_abgr() initialize the pixmap's
instance from a pre-existing instance of struct drm_framebuffer.
There's potential to s
Store the source-buffer parameters of drm_fb_xrgb_to_rgba5551()
in struct drm_pixmap. Update the function's interface and all of its
callers.
Callers of drm_fb_xrgb_to_rgba5551() initialize the pixmap's
instance from a pre-existing instance of struct drm_framebuffer.
There's potential to s
This RFC patchset implements various features required for DRM panic
handling [1] and should (for now) be seen in that context.
Most of all, the patchset replaces struct drm_framebuffer with struct
drm_pixmap in the format-conversion helpers. DRM pixmap represents a
source of pixel data for the bl
Store the source-buffer parameters of drm_fb_swab() in struct
drm_pixmap. Update the function's interface and all of its callers.
Callers of drm_fb_swab() initialize the pixmap's instance from a
pre-existing instance of struct drm_framebuffer. There's potential
to simplify some of that code in a l
Store the source-buffer parameters of drm_fb_xrgb_to_argb()
in struct drm_pixmap. Update the function's interface and all of its
callers.
Callers of drm_fb_xrgb_to_argb() initialize the pixmap's
instance from a pre-existing instance of struct drm_framebuffer.
There's potential to s
Store the source-buffer parameters of drm_fb_xrgb_to_gray8()
in struct drm_pixmap. Update the function's interface and all of its
callers.
Callers of drm_fb_xrgb_to_gray8() initialize the pixmap's
instance from a pre-existing instance of struct drm_framebuffer.
There's potential to simplif
Store the source-buffer parameters of drm_fb_xrgb_to_mono()
in struct drm_pixmap. Update the function's interface and all of its
callers.
Callers of drm_fb_xrgb_to_mono() initialize the pixmap's
instance from a pre-existing instance of struct drm_framebuffer.
There's potential to simplify
Store the source-buffer parameters of drm_fb_xrgb_to_xrgb1555()
in struct drm_pixmap. Update the function's interface and all of its
callers.
Callers of drm_fb_xrgb_to_xrgb1555() initialize the pixmap's
instance from a pre-existing instance of struct drm_framebuffer.
There's potential to s
Add support for blitting characters. An instance of struct font_desc
stores the the character shapes. The blitting source pixmap contains
a reference to a character's glyph, which can then be blitted to the
destination. drm_pixmap_init_from_font_desc() sets up the pixmap.
struct drm_pixmap;
d
Store the source-buffer parameters of drm_fb_xrgb_to_argb1555()
in struct drm_pixmap. Update the function's interface and all of its
callers.
Callers of drm_fb_xrgb_to_argb1555() initialize the pixmap's
instance from a pre-existing instance of struct drm_framebuffer.
There's potential to s
Store the source-buffer parameters of drm_fb_xrgb_to_xrgb2101010()
in struct drm_pixmap. Update the function's interface and all of its
callers.
Callers of drm_fb_xrgb_to_xrgb2101010() initialize the pixmap's
instance from a pre-existing instance of struct drm_framebuffer.
There's potentia
Add drm_fb_fill(), which fills areas with a single static color, and
implement support for XRGB888 and RGB565. There's common infrastructure
code to move over the destination area and a per-line draw function for
each color format.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_format_
Store the source-buffer parameters of drm_fb_xrgb_to_xbgr()
in struct drm_pixmap. Update the function's interface and all of its
callers.
Callers of drm_fb_xrgb_to_xbgr() initialize the pixmap's
instance from a pre-existing instance of struct drm_framebuffer.
There's potential to s
Store the source-buffer parameters of drm_fb_xrgb_to_rgb888()
in struct drm_pixmap. Update the function's interface and all of its
callers.
Callers of drm_fb_xrgb_to_rgb888() initialize the pixmap's
instance from a pre-existing instance of struct drm_framebuffer.
There's potential to simpl
Store the source-buffer parameters of drm_fb_xrgb_to_argb2101010()
in struct drm_pixmap. Update the function's interface and all of its
callers.
Callers of drm_fb_xrgb_to_argb2101010() initialize the pixmap's
instance from a pre-existing instance of struct drm_framebuffer.
There's potentia
Add a color palette to struct drm_format_conv_state. The palette
points to an array of struct drm_color_lut. It allows to blit from
an index color formats to a component-based destination.
The palette exists independently from the source pixmap and is
thus stored struct drm_format_conv_state inste
Store the source-buffer parameters of drm_fb_xrgb_to_rgb332()
in struct drm_pixmap. Update the function's interface and all of its
callers.
Callers of drm_fb_xrgb_to_rgb332() initialize the pixmap's
instance from a pre-existing instance of struct drm_framebuffer.
There's potential to simpl
Implemented for drawing fonts, the C1-to-XRGB blitting code writes
single bits into an XRGB-based buffer. The color is read from the
given palette.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_format_helper.c | 39 +
include/drm/drm_format_helper.h
Make the implementations of drm_fb_xfrm() independent from struct
framebuffer and rename several variables. Done to simplify further
cleanups; no functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_format_helper.c | 66 ++---
1 file changed, 33 in
Store the source-buffer parameters of drm_fb_blit() in struct
drm_pixmap. Update the function's interface and all of its callers.
Callers of drm_fb_blit() initialize the pixmap's instance from a
pre-existing instance of struct drm_framebuffer. There's potential
to simplify some of that code in a l
On Tue, 30 Jan 2024 09:34:29 +0100
Daniel Vetter wrote:
> On Fri, Jan 26, 2024 at 07:43:29PM +0300, Dmitry Osipenko wrote:
> > On 1/26/24 13:18, Boris Brezillon wrote:
> > > On Thu, 25 Jan 2024 18:24:04 +0100
> > > Daniel Vetter wrote:
> > >
> > >> On Fri, Jan 05, 2024 at 09:46:03PM +0300,
Hi
Am 29.01.24 um 12:04 schrieb Javier Martinez Canillas:
Thomas Zimmermann writes:
Add screen_info_get_pci_dev() to find the PCI device of an instance
of screen_info. Does nothing on systems without PCI bus.
Signed-off-by: Thomas Zimmermann
---
[...]
+struct pci_dev *screen_info_pci_de
On Tue, 2024-01-16 at 15:07 +0200, Jani Nikula wrote:
> We've lacked a device specific debug printer. Add one. Take category
> into account too.
>
> __builtin_return_address(0) is inaccurate here, so don't use it. If
> necessary, we can later pass __func__ to drm_dbg_printer() by wrapping
> it ins
On Tue, 2024-01-16 at 15:07 +0200, Jani Nikula wrote:
> Prefer the device specific debug printer.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/display/drm_dp_mst_topology.c | 23 +++
> 1 file changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/di
On Tue, 2024-01-16 at 15:07 +0200, Jani Nikula wrote:
> Prefer the device specific debug printer.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_mode_config.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_mode_config.c
> b/drivers/gpu/
Thomas Zimmermann writes:
> Hi
>
> Am 29.01.24 um 12:04 schrieb Javier Martinez Canillas:
>> Thomas Zimmermann writes:
>>
>>> Add screen_info_get_pci_dev() to find the PCI device of an instance
>>> of screen_info. Does nothing on systems without PCI bus.
>>>
>>> Signed-off-by: Thomas Zimmermann
On Tue, 2024-01-16 at 15:07 +0200, Jani Nikula wrote:
> Use the existing drm printer infrastructure instead of local macros.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/display/drm_dp_helper.c | 17 +---
> .../drm/i915/display/intel_crtc_state_dump.c | 5 ++--
> driver
On Tue, 2024-01-16 at 15:07 +0200, Jani Nikula wrote:
> Prefer the device specific debug printer.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display_driver.c | 3 ++-
> drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c| 3 ++-
> drivers/gpu/drm/i915/gt/intel_res
On Tue, 2024-01-16 at 15:07 +0200, Jani Nikula wrote:
> There's already a related drm_printer. Use it to preserve the context
> instead of a separate pr_err().
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c | 6 +++---
> drivers/gpu/drm/i915/selftests/
On Tue, 2024-01-16 at 15:07 +0200, Jani Nikula wrote:
> Prefer the device specific debug printer.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/xe/xe_gt.c | 2 +-
> drivers/gpu/drm/xe/xe_gt_topology.c | 4 +++-
> drivers/gpu/drm/xe/xe_reg_sr.c | 2 +-
> 3 files changed, 5
On Tue, 2024-01-16 at 15:07 +0200, Jani Nikula wrote:
> Convert the remaining drm_debug_printer users over to drm_dbg_printer,
> as it can handle the cases without struct drm_device pointer, and also
> provides drm debug category and prefix support. Remove drm_debug_printer
> altogether.
>
> Signe
On Tue, Jan 30, 2024 at 10:23:03AM +0100, Christian König wrote:
> Am 30.01.24 um 10:01 schrieb Daniel Vetter:
> > On Fri, Jan 26, 2024 at 05:42:50PM +0100, Christian König wrote:
> > > [SNIP]
> > > Well I think we should have some solution, but I'm not sure if it should
> > > be
> > > part of DMA
On Tue, 2024-01-16 at 15:07 +0200, Jani Nikula wrote:
> Avoid forward declarations in subsequent changes, but separate this
> movement to an independent change.
>
> Signed-off-by: Jani Nikula
> ---
> include/drm/drm_print.h | 190
> 1 file changed, 95 ins
On Tue, 2024-01-16 at 15:07 +0200, Jani Nikula wrote:
> With few users for drm_err_printer(), it's still feasible to convert it
> to be device specific. Use drm_err() under the hood.
>
> While at it, make the prefix optional.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_print.c
On Tue, Jan 30, 2024 at 10:48:23AM +0100, Paul Cercueil wrote:
> Le mardi 30 janvier 2024 à 10:23 +0100, Christian König a écrit :
> > I would say we start with the DMA-API by getting away from sg_tables
> > to something cleaner and state oriented.
>
> FYI I am already adding a 'dma_vec' object
On Sun, Jan 28, 2024 at 06:25:15PM -0300, André Almeida wrote:
> AMD GPUs can do async flips with changes on more properties than just
> the FB ID, so implement a custom check_async_props for AMD planes.
>
> Allow amdgpu to do async flips with overlay planes as well.
>
> Signed-off-by: André Alme
/archive/20240130/202401301825.pvnlzurt-...@intel.com/config)
compiler: powerpc64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240130/202401301825.pvnlzurt-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new
> Do we really need this much flexibility, especially for the first driver
> adding the first few additional properties?
AFAIU we'd like to allow more props as well, e.g. cursor position…
On Mon, Jan 29, 2024 at 06:31:19PM +0800, Julia Zhang wrote:
> As vram objects don't have backing pages and thus can't implement
> drm_gem_object_funcs.get_sg_table callback. This removes drm dma-buf
> callbacks in virtgpu_gem_map_dma_buf()/virtgpu_gem_unmap_dma_buf()
> and implement virtgpu specif
Hi Hans,
Am 29.01.24 um 14:24 schrieb Hans de Goede:
Hi Werner,
On 1/19/24 17:04, Werner Sembach wrote:
Am 19.01.24 um 09:44 schrieb Hans de Goede:
So my proposal would be an ioctl interface (ioctl only no r/w)
using /dev/rgbkbd0 /dev/rgbkdb1, etc. registered as a misc chardev.
For per ke
On Tue, Jan 30, 2024 at 12:10:31PM +0100, Daniel Vetter wrote:
> On Mon, Jan 29, 2024 at 06:31:19PM +0800, Julia Zhang wrote:
> > As vram objects don't have backing pages and thus can't implement
> > drm_gem_object_funcs.get_sg_table callback. This removes drm dma-buf
> > callbacks in virtgpu_gem_m
Hi
Am 23.01.24 um 15:56 schrieb Jocelyn Falempe:
On 23/01/2024 13:56, Thomas Zimmermann wrote:
Hi,
FYI for points 1 and 2, I'm typing up a patchset that introduces
drm_pixmap for the source buffer. I'll post it when I have something
ready.
Thanks, I didn't have time to look into this yet
Hi folks,
Here's a small but a different set of patches for making two relatively
minor changes to runtime PM API. I restarted version numbering as this is
meaningfully different from the previous set.
pm_runtime_get_if_active() loses its second argument as it only made sense
to have ign_usage_co
There are two ways to opportunistically increment a device's runtime PM
usage count, calling either pm_runtime_get_if_active() or
pm_runtime_get_if_in_use(). The former has an argument to tell whether to
ignore the usage count or not, and the latter simply calls the former with
ign_usage_count set
Hi Maintainers,
There are some flaky tests reported for amdgpu driver testing in drm-ci.
# Board Name: hp-11A-G6-EE-grunt
# IGT Version: 1.28-gb0cc8160e
# Linux Version: 6.7.0-rc3
Pipeline url:
https://gitlab.freedesktop.org/vigneshraman/linux/-/jobs/54373774
# Reported by deqp-runner
amdgpu/a
Hi,
This is the v6 of my patchset that adds a new DMABUF import interface to
FunctionFS.
Given that the cache coherency issue that has been discussed after my
v5 is a tangential problem and not directly related to this new
interface, I decided to drop the dma_buf_begin/end_access() functions
for
Add a new 'sg_was_mapped' field to the struct usb_request. This field
can be used to indicate that the scatterlist associated to the USB
transfer has already been mapped into the DMA space, and it does not
have to be done internally.
Signed-off-by: Paul Cercueil
---
drivers/usb/gadget/udc/core.c
This exact same code was duplicated in two different places.
Signed-off-by: Paul Cercueil
---
drivers/usb/gadget/function/f_fs.c | 48 +-
1 file changed, 27 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/
This patch introduces three new ioctls. They all should be called on a
data endpoint (ie. not ep0). They are:
- FUNCTIONFS_DMABUF_ATTACH, which takes the file descriptor of a DMABUF
object to attach to the endpoint.
- FUNCTIONFS_DMABUF_DETACH, which takes the file descriptor of the
DMABUF to
Add documentation for the three ioctls used to attach or detach
externally-created DMABUFs, and to request transfers from/to previously
attached DMABUFs.
Signed-off-by: Paul Cercueil
---
v3: New patch
---
Documentation/usb/functionfs.rst | 36
1 file changed, 36
Hi
Am 29.01.24 um 12:36 schrieb Javier Martinez Canillas:
Thomas Zimmermann writes:
Test if the firmware framebuffer's parent PCI device, if any, has
been enabled. If not, the firmware framebuffer is most likely not
working. Hence, do not create a device for the firmware framebuffer
on disabl
Am 30.01.24 um 11:40 schrieb Daniel Vetter:
On Tue, Jan 30, 2024 at 10:48:23AM +0100, Paul Cercueil wrote:
Le mardi 30 janvier 2024 à 10:23 +0100, Christian König a écrit :
I would say we start with the DMA-API by getting away from sg_tables
to something cleaner and state oriented.
FYI I am
Hi
Am 29.01.24 um 11:41 schrieb Javier Martinez Canillas:
Thomas Zimmermann writes:
Hello Thomas,
The plain values as stored in struct screen_info need to be decoded
before being used. Add helpers that decode the type of video output
and the framebuffer I/O aperture.
Old or non-x86 systems
Am 30.01.24 um 12:16 schrieb Daniel Vetter:
On Tue, Jan 30, 2024 at 12:10:31PM +0100, Daniel Vetter wrote:
On Mon, Jan 29, 2024 at 06:31:19PM +0800, Julia Zhang wrote:
As vram objects don't have backing pages and thus can't implement
drm_gem_object_funcs.get_sg_table callback. This removes drm
Am 29.01.24 um 21:25 schrieb Thomas Hellström:
Hi,
On 1/29/24 17:48, Christian König wrote:
Am 27.01.24 um 16:53 schrieb Oak Zeng:
This fixes a build failure on drm-tip. This issue was introduced during
merge of "drm/ttm: replace busy placement with flags v6". For some
reason, the xe_bo.c part
On 1/30/24 15:31, Christian König wrote:
Am 29.01.24 um 21:25 schrieb Thomas Hellström:
Hi,
On 1/29/24 17:48, Christian König wrote:
Am 27.01.24 um 16:53 schrieb Oak Zeng:
This fixes a build failure on drm-tip. This issue was introduced
during
merge of "drm/ttm: replace busy placement with
Hi,
On 1/27/24 20:53, Gustavo A. R. Silva wrote:
On 1/27/24 09:11, David Laight wrote:
From: Linus Torvalds
Sent: 26 January 2024 22:36
On Fri, 26 Jan 2024 at 14:24, Kees Cook wrote:
I think xe has some other weird problems too. This may be related
(under
allocating):
../drivers/gpu/d
The hdmi-connector nodes are now functional and the new way to model
hdmi nodes with, so deprecate the port property and make port@0 and
port@1 a requirement. Also update example.
Signed-off-by: Johan Jonker
---
.../display/rockchip/rockchip,dw-hdmi.yaml| 27 ---
1 file chang
Most Rockchip hdmi nodes are part of a power domain.
Add a power-domains property. Fix example.
Signed-off-by: Johan Jonker
---
.../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git
a/Documentation/devicetree/bindings
Fix rk3288 hdmi ports node so that it matches the
rockchip,dw-hdmi.yaml binding.
Signed-off-by: Johan Jonker
---
arch/arm/boot/dts/rockchip/rk3288.dtsi | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/rockchip/rk3288.dtsi
b/arch/arm/boot/
Fix rk322x hdmi ports node so that it matches the
rockchip,dw-hdmi.yaml binding.
Signed-off-by: Johan Jonker
---
arch/arm/boot/dts/rockchip/rk322x.dtsi | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/rockchip/rk322x.dtsi
b/arch/arm/boot/
Fix rk3328 hdmi ports node so that it matches the
rockchip,dw-hdmi.yaml binding.
Signed-off-by: Johan Jonker
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
b/arch/arm64/boot
Fix rk3399 hdmi ports node so that it matches the
rockchip,dw-hdmi.yaml binding.
Signed-off-by: Johan Jonker
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/
Some ARM SOCs have a separate display controller and GPU, each with
different drivers. For mediatek mt8173, the GPU driver is powervr,
and the display driver is mediatek. In the case of mediatek mt8183,
the GPU driver is panfrost, and the display driver is mediatek.
With rockchip rk3288/rk3399, the
For mediatek mt8173, the GPU driver is powervr and for mediatek
mt8183, the GPU driver is panfrost. So add support in drm-ci to
test panfrost and powervr GPU driver for mediatek SOCs and update
xfails. Powervr driver was merged in linux kernel, but there's no
mediatek support yet. So disable the mt
For Amlogic Meson SOC the display driver is meson. Currently,
in drm-ci for meson, only the display driver is tested.
So rename the meson job to indicate that display driver is tested.
Rename the name of xfail files for meson (g12b), to include
information about the tested driver and update xfails
For amlogic meson SOC the GPU driver is panfrost. So add
support in drm-ci to test panfrost driver for amlogic meson
SOC and update xfails. Skip KMS tests for panfrost driver
since it is not a not a KMS driver.
Signed-off-by: Vignesh Raman
---
v2:
- Add panfrost GPU jobs for amlogic meson SOC
Enable CONFIG_DRM_ANALOGIX_ANX7625 in the arm64 defconfig to get
display driver probed on the mt8183-kukui-jacuzzi-juniper machine.
arch/arm64/configs/defconfig has CONFIG_DRM_ANALOGIX_ANX7625=m,
but drm-ci don't have initrd with modules, so add
CONFIG_DRM_ANALOGIX_ANX7625=y in CI arm64 config.
S
For rockchip rk3288 and rk3399, the GPU driver is panfrost.
So add support in drm-ci to test panfrost driver for rockchip
SOC and update xfails. Skip KMS tests for panfrost driver
since it is not a not a KMS driver.
Signed-off-by: Vignesh Raman
---
v2:
- Add panfrost GPU jobs for rockchip SOC
For mediatek mt8173 and mt8183, the display driver is mediatek.
Currently, in drm-ci for mediatek, only the display driver is
tested. So rename the mediatek job to indicate that display driver is
tested. Rename the name of xfail files for mediatek (mt8173 and mt8183),
to include information about t
For rockchip rk3288 and rk3399, the display driver is rockchip.
Currently, in drm-ci for rockchip, only the display driver is
tested. So rename the rockchip job to indicate that display
driver is tested.
Rename the name of xfail files for rockchip (rk3288 and rk3399),
to include information about
zlib.net is not allowing tarball download anymore and results
in below error in kernel+rootfs_arm32 container build,
urllib.error.HTTPError: HTTP Error 403: Forbidden
urllib.error.HTTPError: HTTP Error 415: Unsupported Media Type
Uprev mesa which includes a fix for this issue.
https://gitlab.freed
Uprev IGT and add amd, v3d, vc4 and vgem specific
tests to testlist. Have testlist.txt per driver
and include a base testlist so that the driver
specific tests will run only on those hardware.
Signed-off-by: Vignesh Raman
---
v3:
- New patch in series to uprev IGT and update testlist.
---
dr
On Sat, Jan 27, 2024 at 04:28:08PM +0100, Dario Binacchi wrote:
> Allow 'port' property (coming from panel-common.yaml) to be used in DTS:
>
> st/stm32f769-disco-mb1166-reva09.dtb: panel@0: 'port' does not match any of
> the regexes: 'pinctrl-[0-9]+'
>
> Signed-off-by: Dario Binacchi
> Cc: Al
On Tue, Jan 30, 2024 at 06:42:04AM +, dharm...@microchip.com wrote:
> Hi Conor,
>
> On 24/01/24 10:10 pm, Conor Dooley wrote:
> > On Wed, Jan 24, 2024 at 03:30:16PM +0530, Dharma Balasubiramani wrote:
> >> Converted the text bindings to YAML and validated them individually using
> >> followin
Hi Adam,
On 06-01-24, 16:19, Adam Ford wrote:
> From: Lucas Stach
>
> This adds the driver for the Samsung HDMI PHY found on the
> i.MX8MP SoC.
>
> Signed-off-by: Lucas Stach
> Signed-off-by: Adam Ford
> ---
> V2: Fixed some whitespace found from checkpatch
> Change error handling when
We had a request to add shared buffer stats to fdinfo for amdgpu and
while implementing that, Christian mentioned that just looking at
the GEM handle count doesn't take into account buffers shared with other
subsystems like V4L or RDMA. Those subsystems don't use GEM, so it
doesn't really matter f
1 - 100 of 160 matches
Mail list logo
