Am 08.04.21 um 06:59 schrieb David Stevens:
From: David Stevens
This reverts commit 86bbd89d5da66fe760049ad3f04adc407ec0c4d6.
Using the singleton stub fence in drm_syncobj_assign_null_handle means
that all syncobjs created in an already signaled state or any syncobjs
signaled by userspace will
On Wed, 07 Apr 2021, Benjamin Tissoires wrote:
> On Tue, Apr 6, 2021 at 10:56 AM Lee Jones wrote:
> >
> > On Fri, 26 Mar 2021, Lee Jones wrote:
> >
> > > This set is part of a larger effort attempting to clean-up W=1
> > > kernel builds, which are currently overwhelmingly riddled with
> > > niggl
Hello Robert
I am sorry that I make a mistake about the compiling error of lt8912b,
the reason is that lt8912b miss the header file .
Although there are many files reference gpiod_set_value_cansleep() and
devm_gpiod_get_optional(), they all include
and not occur the compiling error like lt89
Am 07.04.21 um 21:04 schrieb Alex Deucher:
On Wed, Apr 7, 2021 at 3:23 AM Dave Airlie wrote:
On Wed, 7 Apr 2021 at 06:54, Alex Deucher wrote:
On Fri, Apr 2, 2021 at 12:22 PM Christian König
wrote:
Hey Alex,
the TTM and scheduler changes should already be in the drm-misc-next
branch (not
On Tue, Apr 06, 2021 at 10:29:38AM +0200, Thomas Zimmermann wrote:
> The implementation of drm_driver.dumb_map_offset is the same for several
> TTM-based drivers. Provide a common function in GEM-TTM helpers.
For the series:
Acked-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signatu
Fix the following gcc warning:
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c:163:6: warning: variable
‘ret’ set but not used [-Wunused-but-set-variable].
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c | 3 +--
1 file changed, 1 insertion(+), 2
Hi,
On Thu, Mar 18, 2021 at 11:29:19AM +0100, Thomas Zimmermann wrote:
> Make sure required hardware clocks are enabled while the firmware
> framebuffer is in use.
>
> The basic code has been taken from the simplefb driver and adapted
> to DRM. Clocks are released automatically via devres helpers
Hey Zhang,
On Thu, 8 Apr 2021 at 09:10, zhangjianhua (E) wrote:
>
> Hello Robert
>
> I am sorry that I make a mistake about the compiling error of lt8912b,
>
> the reason is that lt8912b miss the header file .
>
> Although there are many files reference gpiod_set_value_cansleep() and
>
> devm_gpi
Hey Zhang,
On Thu, 8 Apr 2021 at 05:54, Zhang Jianhua wrote:
>
> If CONFIG_DRM_LONTIUM_LT8912B=m, the following errors will be seen while
> compiling lontium-lt8912b.c
>
> drivers/gpu/drm/bridge/lontium-lt8912b.c: In function
> ‘lt8912_hard_power_on’:
> drivers/gpu/drm/bridge/lontium-lt8912b.c:2
From: Xuezhi Zhang
Fix the following coccicheck warning:
drivers/gpu/drm//panel/panel-tpo-td043mtea1.c:217:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm//panel/panel-tpo-td043mtea1.c:189:8-16:
WARNING: use scnprintf or sprintf
Signed-off-by: Xuezhi Zhang
---
drivers/gpu/drm/panel/p
On Wednesday, April 7th, 2021 at 3:51 PM, Ville Syrjälä
wrote:
> > +* To find out the list of formats that support modifiers, userspace
> > +* must use the plane IN_FORMATS blob property.
> > */
>
> Addfb2+modifiers predates the IN_FORMATS blob, so this doesn't
> match reality.
TBH
From: Xuezhi Zhang
Fix the following coccicheck warning:
drivers/gpu/drm//panel/panel-dsi-cm.c:271:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm//panel/panel-dsi-cm.c:251:8-16:
WARNING: use scnprintf or sprintf
Signed-off-by: Xuezhi Zhang
---
drivers/gpu/drm/panel/panel-dsi-cm.c |
From: Xuezhi Zhang
Fix the following coccicheck warning:
drivers/gpu/drm//panel/panel-dsi-cm.c:271:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm//panel/panel-dsi-cm.c:251:8-16:
WARNING: use scnprintf or sprintf
Signed-off-by: Xuezhi Zhang
---
v2: change snprint to snprintf in subjec
Trying to set CONFIG_CMA=y with CONFIG_DMA_CMA=n revealed that we have
three drivers that select these options. Random drivers should not
override user settings of such core knobs. Let's use "imply DMA_CMA"
instead, such that user configuration and dependencies are respected.
Cc: Joel Stanley
Cc:
Random drivers should not override a user configuration of core knobs
(e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
dependencies and manual overrides.
"This is similar to "select" as it enforces a lower limit on another
symbol except that the "implied" symbol's value may still b
Random drivers should not override a user configuration of core knobs
(e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
dependencies and manual overrides.
"This is similar to "select" as it enforces a lower limit on another
symbol except that the "implied" symbol's value may still b
https://bugzilla.kernel.org/show_bug.cgi?id=211425
Andreas (icedragon...@web.de) changed:
What|Removed |Added
Kernel Version|5.11.11 |5.11.12
--- Comment #16 f
> > +
> > + if (vgdev->has_resource_blob) {
> > + params.blob_mem = VIRTGPU_BLOB_MEM_GUEST;
> > + params.blob_flags = VIRTGPU_BLOB_FLAG_USE_SHAREABLE;
> >
>
> This creates some log spam with crosvm + virgl_3d + vanilla linux, since
> transfers don't work for guest
On Thu, Apr 8, 2021 at 4:03 PM Christian König wrote:
>
> Am 08.04.21 um 06:59 schrieb David Stevens:
> > From: David Stevens
> >
> > This reverts commit 86bbd89d5da66fe760049ad3f04adc407ec0c4d6.
> >
> > Using the singleton stub fence in drm_syncobj_assign_null_handle means
> > that all syncobjs
[Bug][DP501]
If ASPEED P2A (PCI to AHB) bridge is disabled and disallowed for
CVE_2019_6260 item3, and then the monitor's EDID is unable read through
Parade DP501.
The reason is the DP501's FW is mapped to BMC addressing space rather
than Host addressing space.
The resolution is that using "pci_iom
From: David Stevens
Allocate a new private stub fence in drm_syncobj_assign_null_handle,
instead of using a static stub fence.
When userspace creates a fence with DRM_SYNCOBJ_CREATE_SIGNALED or when
userspace signals a fence via DRM_IOCTL_SYNCOBJ_SIGNAL, the timestamp
obtained when the fence is
Am 08.04.21 um 11:30 schrieb David Stevens:
On Thu, Apr 8, 2021 at 4:03 PM Christian König wrote:
Am 08.04.21 um 06:59 schrieb David Stevens:
From: David Stevens
This reverts commit 86bbd89d5da66fe760049ad3f04adc407ec0c4d6.
Using the singleton stub fence in drm_syncobj_assign_null_handle me
Sorry, I forgot to checkpatch this, I'll resend it momentarily.
-David
On Thu, Apr 8, 2021 at 6:34 PM David Stevens wrote:
>
> From: David Stevens
>
> Allocate a new private stub fence in drm_syncobj_assign_null_handle,
> instead of using a static stub fence.
>
> When userspace creates a fence
If CONFIG_DRM_LONTIUM_LT8912B=m, the following errors will be seen while
compiling lontium-lt8912b.c
drivers/gpu/drm/bridge/lontium-lt8912b.c: In function
‘lt8912_hard_power_on’:
drivers/gpu/drm/bridge/lontium-lt8912b.c:252:2: error: implicit
declaration of function ‘gpiod_set_value_cansleep’; did
Am 08.04.21 um 11:34 schrieb David Stevens:
From: David Stevens
Allocate a new private stub fence in drm_syncobj_assign_null_handle,
instead of using a static stub fence.
When userspace creates a fence with DRM_SYNCOBJ_CREATE_SIGNALED or when
userspace signals a fence via DRM_IOCTL_SYNCOBJ_SIG
From: David Stevens
Allocate a new private stub fence in drm_syncobj_assign_null_handle,
instead of using a static stub fence.
When userspace creates a fence with DRM_SYNCOBJ_CREATE_SIGNALED or when
userspace signals a fence via DRM_IOCTL_SYNCOBJ_SIGNAL, the timestamp
obtained when the fence is
Pushed to
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=7513ce49027c8218a6fce7ec45c3289b903ba4bd
On Thu, 8 Apr 2021 at 11:38, Zhang Jianhua wrote:
>
> If CONFIG_DRM_LONTIUM_LT8912B=m, the following errors will be seen while
> compiling lontium-lt8912b.c
>
> drivers/gpu/drm/bridge/lontium
On Thu, Mar 18, 2021 at 11:29:15AM +0100, Thomas Zimmermann wrote:
> Platform devices might operate on firmware framebuffers, such as VESA or
> EFI. Before a native driver for the graphics hardware can take over the
> device, it has to remove any platform driver that operates on the firmware
> fram
On Thu, Mar 18, 2021 at 11:29:14AM +0100, Thomas Zimmermann wrote:
> Fbdev's helpers for handling conflicting framebuffers are related to
> framebuffer apertures, not console emulation. Therefore move them into a
> drm_aperture.h, which will contain the interfaces for the new aperture
> helpers.
>
From: David Stevens
Allocate a new private stub fence in drm_syncobj_assign_null_handle,
instead of using a static stub fence.
When userspace creates a fence with DRM_SYNCOBJ_CREATE_SIGNALED or when
userspace signals a fence via DRM_IOCTL_SYNCOBJ_SIGNAL, the timestamp
obtained when the fence is
Am 08.04.21 um 11:54 schrieb David Stevens:
From: David Stevens
Allocate a new private stub fence in drm_syncobj_assign_null_handle,
instead of using a static stub fence.
When userspace creates a fence with DRM_SYNCOBJ_CREATE_SIGNALED or when
userspace signals a fence via DRM_IOCTL_SYNCOBJ_SIG
On Thu, Apr 08, 2021 at 11:20:10AM +0200, David Hildenbrand wrote:
> Random drivers should not override a user configuration of core knobs
> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
> dependencies and manual overrides.
>
> "This is similar to "select" as it enforces a lower
On Thu, Apr 08, 2021 at 11:20:11AM +0200, David Hildenbrand wrote:
> Random drivers should not override a user configuration of core knobs
> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
> dependencies and manual overrides.
>
> "This is similar to "select" as it enforces a lower
On 08.04.21 11:56, Mike Rapoport wrote:
On Thu, Apr 08, 2021 at 11:20:11AM +0200, David Hildenbrand wrote:
Random drivers should not override a user configuration of core knobs
(e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
dependencies and manual overrides.
"This is similar to
On Thu, 08 Apr 2021 08:39:10 +
Simon Ser wrote:
> On Wednesday, April 7th, 2021 at 3:51 PM, Ville Syrjälä
> wrote:
>
> > > + * To find out the list of formats that support modifiers, userspace
> > > + * must use the plane IN_FORMATS blob property.
> > >*/
> >
> > Addfb2+modifiers p
Pushing to drm-misc-next works for me. Thanks for the quick responses.
-David
On Thu, Apr 8, 2021 at 6:56 PM Christian König wrote:
>
> Am 08.04.21 um 11:54 schrieb David Stevens:
> > From: David Stevens
> >
> > Allocate a new private stub fence in drm_syncobj_assign_null_handle,
> > instead of
On Thu, Apr 01, 2021 at 06:56:09AM +1000, Dave Airlie wrote:
> I think this is due to this pull, on arm32.
>
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dmub/src/dmub_srv.c:
> In function ‘dmub_srv_hw_init’:
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/am
On Mon, Mar 29, 2021 at 10:31:01AM -0300, Jason Gunthorpe wrote:
> On Tue, Mar 16, 2021 at 04:33:03PM +0100, Daniel Vetter wrote:
> > Both kvm (in bd2fae8da794 ("KVM: do not assume PTE is writable after
> > follow_pfn")) and vfio (in 07956b6269d3 ("vfio/type1: Use
> > follow_pte()")) have lost thei
Trying to set CONFIG_CMA=y with CONFIG_DMA_CMA=n revealed that we have
three drivers that select these options. Random drivers should not
override user settings of such core knobs. Let's use "imply DMA_CMA"
instead, such that user configuration and dependencies are respected.
v1 -> v2:
- Fix DRM_C
Random drivers should not override a user configuration of core knobs
(e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
dependencies and manual overrides.
"This is similar to "select" as it enforces a lower limit on another
symbol except that the "implied" symbol's value may still b
Random drivers should not override a user configuration of core knobs
(e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
dependencies and manual overrides.
"This is similar to "select" as it enforces a lower limit on another
symbol except that the "implied" symbol's value may still b
On Tue, Mar 30, 2021 at 10:34:12AM +0200, Hans de Goede wrote:
> Hi,
>
> On 3/30/21 9:09 AM, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 29.03.21 um 16:50 schrieb Hans de Goede:
> >> Hi,
> >>
> >> On 3/29/21 2:31 PM, Thomas Zimmermann wrote:
> >>> Hi
> >>>
> >>> Am 25.03.21 um 12:29 schrieb Hans d
On Thu, Apr 08, 2021 at 12:05:21PM +0200, David Hildenbrand wrote:
> Trying to set CONFIG_CMA=y with CONFIG_DMA_CMA=n revealed that we have
> three drivers that select these options. Random drivers should not
> override user settings of such core knobs. Let's use "imply DMA_CMA"
> instead, such tha
On Fri, Mar 26, 2021 at 10:31:10AM +, Tvrtko Ursulin wrote:
>
> On 26/03/2021 09:10, Daniel Vetter wrote:
> > On Wed, Mar 24, 2021 at 12:13:28PM +, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > "Watchdog" aka "restoring hangcheck" aka default request/fence expiry -
> > >
Hi,
I have just a few nits below plus the points that others made.
Am 22.02.21 um 14:28 schrieb Kevin Tang:
Adds drm support for the Unisoc's display subsystem.
This is drm kms driver, this driver provides support for the
application framework in Android, Yocto and more.
Application framework
On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand wrote:
>
> Random drivers should not override a user configuration of core knobs
> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
> dependencies and manual overrides.
>
> "This is similar to "select" as it enforces a lower limit on
On 08.04.21 12:20, Arnd Bergmann wrote:
On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand wrote:
Random drivers should not override a user configuration of core knobs
(e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
dependencies and manual overrides.
"This is similar to "select
Am 08.04.21 um 09:13 schrieb Christian König:
Am 07.04.21 um 21:04 schrieb Alex Deucher:
On Wed, Apr 7, 2021 at 3:23 AM Dave Airlie wrote:
On Wed, 7 Apr 2021 at 06:54, Alex Deucher
wrote:
On Fri, Apr 2, 2021 at 12:22 PM Christian König
wrote:
Hey Alex,
the TTM and scheduler changes should
On Fri, Mar 26, 2021 at 06:55:01AM +0100, Christoph Hellwig wrote:
> Hi all,
>
> i915 has some reason to want to avoid the track_pfn_remap overhead in
> remap_pfn_range. Add a function to the core VM to do just that rather
> than reinventing the functionality poorly in the driver.
>
> Note that
On 08.04.21 12:27, David Hildenbrand wrote:
On 08.04.21 12:20, Arnd Bergmann wrote:
On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand wrote:
Random drivers should not override a user configuration of core knobs
(e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
dependencies and m
On Mon, Mar 29, 2021 at 09:23:35PM +0300, Imre Deak wrote:
> Hi Stephen,
>
> thanks for the report.
>
> On Mon, Mar 29, 2021 at 09:01:17AM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > On Fri, 26 Mar 2021 19:58:38 +1100 Stephen Rothwell
> > wrote:
> > >
> > > After merging the drm-intel-f
On Thu, Apr 8, 2021 at 12:29 PM David Hildenbrand wrote:
> On 08.04.21 12:20, Arnd Bergmann wrote:
> > On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand wrote:
> >>
> >> Random drivers should not override a user configuration of core knobs
> >> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to st
On Fri, Mar 26, 2021 at 10:35:33AM +, Simon Ser wrote:
> Reviewed-by: Simon Ser
>
> I'll push this shortly to drm-misc-next.
I also pushed the 2nd patch, seems to have been lost in the applying?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_
Ah, I haven't seen the second patch...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Apr 01, 2021 at 04:40:33PM +0300, Jani Nikula wrote:
> On Fri, 26 Mar 2021, Lyude Paul wrote:
> > Since it's been asked quite a few times on some of the various DP
> > related patch series I've submitted to use the new DRM printk helpers,
> > and it technically wasn't really trivial to do
On Tue, Mar 30, 2021 at 09:54:48AM +0800, Tian Tao wrote:
> Fix the following coccicheck warning:
> drivers/gpu/drm/panel//panel-tpo-td043mtea1.c:217:8-16: WARNING:
> use scnprintf or sprintf
> drivers/gpu/drm/panel//panel-tpo-td043mtea1.c:189:8-16: WARNING:
> use scnprintf or sprintf
>
> Signed-o
Hi,
please see my comments below.
Best regards
Thomas
Am 22.02.21 um 14:28 schrieb Kevin Tang:
Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem.
It's support multi planes, scaler, rotation, PQ(Picture Quality) and more.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-
On Wed, Apr 07, 2021 at 12:17:49PM +0200, Michal Simek wrote:
>
>
> On 3/30/21 11:31 AM, Dan Carpenter wrote:
> > The dp->train_set[] for this driver is only two characters, not four so
> > this memsets too much. Fortunately, this ends up corrupting a struct
> > hole and not anything important.
In particular, it does not prevent a configuration with 'DRM_CMA=m'
I assume you meant "DRM_CMA=n" ? DRM_CMA cannot be built as a module.
Ok, at least that makes it easier.
and 'DRMA_ASPEED_GFX=y', or any build failures from such
a configuration.
I don't follow. "DRM_CMA=n" and 'DRMA_ASPEE
On Thu, Apr 01, 2021 at 04:17:03PM +0800, Wan Jiabing wrote:
> struct drm_gem_object is declared twice. One is declared
> at 40th line. The blew one is not needed. Remove the duplicate.
>
> Signed-off-by: Wan Jiabing
Pushed to drm-misc-next, thanks for your patch.
-Daniel
> ---
> drivers/gpu/d
On Thu, Apr 01, 2021 at 03:54:13PM +0200, Christian König wrote:
> Switch back to using a spinlock again by moving the IOMMU unmap outside
> of the locked region.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_pool.c | 40 +++---
> include/linux/sh
Hi,
just trivial points below. In any case
Acked-by: Thomas Zimmermann
Am 31.03.21 um 11:21 schrieb Daniel Mack:
This patch adds support for Newhaven's NHD-1.8-128160EF display, featuring
an Ilitek ILI9163 controller.
Signed-off-by: Daniel Mack
Acked-by: Daniel Vetter
---
drivers/gpu/drm
On Thu, 08 Apr 2021, Daniel Vetter wrote:
> I think Dave caught up on pulls to drm-next, so after a backmerge of that
> to drm-misc-next I think should be all fine to apply directly, no need for
> topic branch.
Yup. We've done the backmerges to drm-intel-next and drm-intel-gt-next,
and are all in
From: Xuezhi Zhang
Fix the following coccicheck warning:
drivers/gpu/drm//nouveau/nouveau_hwmon.c:44:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm//nouveau/nouveau_hwmon.c:57:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm//nouveau/nouveau_hwmon.c:90:8-16:
WARNING: use scnpri
On Mon, Apr 05, 2021 at 10:45:23AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> One would normally hope not to be under enough memory pressure to need
> to swap GEM objects to disk backed swap. But memory backed zram swap
> (as enabled on chromebooks, for example) can actually be quite fast
> a
On Tue, Apr 06, 2021 at 10:29:38AM +0200, Thomas Zimmermann wrote:
> The implementation of drm_driver.dumb_map_offset is the same for several
> TTM-based drivers. Provide a common function in GEM-TTM helpers.
Out of curiosity, why does this not fit for radeon/amdgpu?
-Daniel
>
> Thomas Zimmerman
Am 08.04.21 um 13:08 schrieb Daniel Vetter:
On Thu, Apr 01, 2021 at 03:54:13PM +0200, Christian König wrote:
Switch back to using a spinlock again by moving the IOMMU unmap outside
of the locked region.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 40 +++---
On Tue, Apr 06, 2021 at 11:08:55AM +0200, Thomas Zimmermann wrote:
> Implement mmap via struct drm_gem_object_functions.mmap for amdgpu,
> radeon and nouveau. This allows for using common DRM helpers for
> the mmap-related callbacks in struct file_operations and struct
> drm_driver. The drivers hav
On Tue, Apr 06, 2021 at 07:55:14PM +0800, Huang Guobin wrote:
> From: Guobin Huang
>
> spinlock can be initialized automatically with DEFINE_SPINLOCK()
> rather than explicitly calling spin_lock_init().
>
> Reported-by: Hulk Robot
> Signed-off-by: Guobin Huang
Applied to drm-misc-next, thanks
On Thu, Apr 08, 2021 at 12:59:19PM +0300, Pekka Paalanen wrote:
> On Thu, 08 Apr 2021 08:39:10 +
> Simon Ser wrote:
>
> > On Wednesday, April 7th, 2021 at 3:51 PM, Ville Syrjälä
> > wrote:
> >
> > > > +* To find out the list of formats that support modifiers,
> > > > userspace
> >
On Thu, Apr 08, 2021 at 01:17:32PM +0200, Christian König wrote:
> Am 08.04.21 um 13:08 schrieb Daniel Vetter:
> > On Thu, Apr 01, 2021 at 03:54:13PM +0200, Christian König wrote:
> > > Switch back to using a spinlock again by moving the IOMMU unmap outside
> > > of the locked region.
> > >
> > >
Hi
Am 08.04.21 um 13:16 schrieb Daniel Vetter:
On Tue, Apr 06, 2021 at 10:29:38AM +0200, Thomas Zimmermann wrote:
The implementation of drm_driver.dumb_map_offset is the same for several
TTM-based drivers. Provide a common function in GEM-TTM helpers.
Out of curiosity, why does this not fit f
On Tue, Apr 06, 2021 at 04:21:16PM -0300, Leandro Ribeiro wrote:
> This patch is to emphasize how userspace should use the plane format list and
> the IN_FORMATS blob. The plane format list contains the formats that do not
> require modifiers, and the blob property has the formats that support
> mo
On Thu, Apr 08, 2021 at 12:20:50PM +0200, Arnd Bergmann wrote:
> On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand wrote:
> >
> > Random drivers should not override a user configuration of core knobs
> > (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
> > dependencies and manual ov
Hi
Am 08.04.21 um 13:19 schrieb Daniel Vetter:
On Tue, Apr 06, 2021 at 11:08:55AM +0200, Thomas Zimmermann wrote:
Implement mmap via struct drm_gem_object_functions.mmap for amdgpu,
radeon and nouveau. This allows for using common DRM helpers for
the mmap-related callbacks in struct file_operat
On Thu, Apr 08, 2021 at 01:34:03PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 08.04.21 um 13:16 schrieb Daniel Vetter:
> > On Tue, Apr 06, 2021 at 10:29:38AM +0200, Thomas Zimmermann wrote:
> > > The implementation of drm_driver.dumb_map_offset is the same for several
> > > TTM-based drivers. Pro
On Thu, Apr 08, 2021 at 06:34:48PM +0900, David Stevens wrote:
> From: David Stevens
>
> Allocate a new private stub fence in drm_syncobj_assign_null_handle,
> instead of using a static stub fence.
>
> When userspace creates a fence with DRM_SYNCOBJ_CREATE_SIGNALED or when
> userspace signals a
On 08/04/21 12:05, Daniel Vetter wrote:
On Mon, Mar 29, 2021 at 10:31:01AM -0300, Jason Gunthorpe wrote:
On Tue, Mar 16, 2021 at 04:33:03PM +0100, Daniel Vetter wrote:
Both kvm (in bd2fae8da794 ("KVM: do not assume PTE is writable after
follow_pfn")) and vfio (in 07956b6269d3 ("vfio/type1: Use
On Thu, Apr 08, 2021 at 01:38:59PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 08.04.21 um 13:19 schrieb Daniel Vetter:
> > On Tue, Apr 06, 2021 at 11:08:55AM +0200, Thomas Zimmermann wrote:
> > > Implement mmap via struct drm_gem_object_functions.mmap for amdgpu,
> > > radeon and nouveau. This al
On Thu, Apr 08, 2021 at 01:40:59PM +0200, Paolo Bonzini wrote:
> On 08/04/21 12:05, Daniel Vetter wrote:
> > On Mon, Mar 29, 2021 at 10:31:01AM -0300, Jason Gunthorpe wrote:
> > > On Tue, Mar 16, 2021 at 04:33:03PM +0100, Daniel Vetter wrote:
> > > > Both kvm (in bd2fae8da794 ("KVM: do not assume P
On Thu, Apr 8, 2021 at 9:06 AM Lee Jones wrote:
>
> On Wed, 07 Apr 2021, Benjamin Tissoires wrote:
>
> > On Tue, Apr 6, 2021 at 10:56 AM Lee Jones wrote:
> > >
> > > On Fri, 26 Mar 2021, Lee Jones wrote:
> > >
> > > > This set is part of a larger effort attempting to clean-up W=1
> > > > kernel b
On Thu, Apr 8, 2021 at 1:00 PM David Hildenbrand wrote:
> >
> > It is a somewhat awkward way to say "prevent this symbol from
> > being =y if the dependency is =m".
>
> What would be the right thing to do in the case here then to achieve the
> "if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id
On 4/8/21 7:25 AM, Michał Mirosław wrote:
On Thu, Apr 08, 2021 at 06:13:44AM +0200, Michał Mirosław wrote:
On Fri, Apr 02, 2021 at 07:02:32PM +0300, Dmitry Osipenko wrote:
02.04.2021 00:19, Michał Mirosław пишет:
On Fri, Mar 26, 2021 at 04:34:13PM +0200, Mikko Perttunen wrote:
On 3/23/21 12:1
On 08.04.21 13:44, Arnd Bergmann wrote:
On Thu, Apr 8, 2021 at 1:00 PM David Hildenbrand wrote:
It is a somewhat awkward way to say "prevent this symbol from
being =y if the dependency is =m".
What would be the right thing to do in the case here then to achieve the
"if DRMA_ASPEED_GFX is ena
err was not used after being assigned -EINVAL and was given a new value,
so here add goto to handle the error case.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/radeon/r600.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index
On Thu, Apr 8, 2021 at 2:00 PM David Hildenbrand wrote:
>
> On 08.04.21 13:44, Arnd Bergmann wrote:
> > On Thu, Apr 8, 2021 at 1:00 PM David Hildenbrand wrote:
> >>>
> >>> It is a somewhat awkward way to say "prevent this symbol from
> >>> being =y if the dependency is =m".
> >>
> >> What would b
Am 08.04.21 um 13:31 schrieb Daniel Vetter:
On Thu, Apr 08, 2021 at 01:17:32PM +0200, Christian König wrote:
Am 08.04.21 um 13:08 schrieb Daniel Vetter:
On Thu, Apr 01, 2021 at 03:54:13PM +0200, Christian König wrote:
[SNIP]
EXPORT_SYMBOL(unregister_shrinker);
+/**
+ * sync_shrinker - Wait
On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand wrote:
> > This is something you could do using a hidden helper symbol like
> >
> > config DRMA_ASPEED_GFX
> > bool "Aspeed display driver"
> > select DRM_WANT_CMA
> >
> > config DRM_WANT_CMA
> > bool
> > help
> >
On Thu, Apr 8, 2021 at 6:28 AM Christian König
wrote:
>
> Am 08.04.21 um 09:13 schrieb Christian König:
> > Am 07.04.21 um 21:04 schrieb Alex Deucher:
> >> On Wed, Apr 7, 2021 at 3:23 AM Dave Airlie wrote:
> >>> On Wed, 7 Apr 2021 at 06:54, Alex Deucher
> >>> wrote:
> On Fri, Apr 2, 2021 at
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:941:13: warning:
‘dm_dmub_trace_high_irq’ defined but not used [-Wunused-function]
941 | static void dm_dmub_trace_high_irq(void *interrupt_params)
| ^~
Fixes: 83b39e1fc3ea ("drm/amd/display: Log D
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Reported-by: Hulk Robot
Signed-off-by: He Ying
---
v2:
- Use 'return PTR_ERR()' instead of 'ret = PTR_ERR();return ret;'.
drivers/phy/mediatek/phy-mtk-hdmi.c | 4 +---
1
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Reviewed-by: Chunfeng Yun
Reported-by: Hulk Robot
Signed-off-by: He Ying
---
v2:
- Use 'return PTR_ERR();' instead of 'ret = PTR_ERR();return ret;'.
drivers/phy/mediatek
The DRM_SIL_SII8620 kconfig has a weak `imply` dependency
on EXTCON, which causes issues when sii8620 is built
as a builtin and EXTCON is built as a module.
The symptoms are 'undefined reference' errors caused
by the symbols in EXTCON not being available
to the sii8620 driver.
Signed-off-by: Robe
On Thu, Apr 8, 2021 at 6:03 AM Daniel Vetter wrote:
>
> On Thu, Apr 01, 2021 at 06:56:09AM +1000, Dave Airlie wrote:
> > I think this is due to this pull, on arm32.
> >
> > /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dmub/src/dmub_srv.c:
> > In function ‘dmub_srv_hw_in
On Thu, Apr 08, 2021 at 08:52:57AM +, Carlis wrote:
> From: Xuezhi Zhang
>
> Fix the following coccicheck warning:
> drivers/gpu/drm//panel/panel-dsi-cm.c:271:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm//panel/panel-dsi-cm.c:251:8-16:
> WARNING: use scnprintf or sprintf
>
>
On Thu, Apr 08, 2021 at 08:31:18AM +, Carlis wrote:
> From: Xuezhi Zhang
>
> Fix the following coccicheck warning:
> drivers/gpu/drm//panel/panel-tpo-td043mtea1.c:217:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm//panel/panel-tpo-td043mtea1.c:189:8-16:
> WARNING: use scnprintf
On Thu, Apr 8, 2021 at 2:50 PM Linus Walleij wrote:
>
> On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand wrote:
>
> > > This is something you could do using a hidden helper symbol like
> > >
> > > config DRMA_ASPEED_GFX
> > > bool "Aspeed display driver"
> > > select DRM_WANT_CMA
Hi Stephen,
On Tue, Mar 30, 2021 at 11:56:15AM -0700, Stephen Boyd wrote:
> Quoting Maxime Ripard (2021-03-30 08:35:27)
> > Hi Stephen,
> >
> > On Mon, Mar 29, 2021 at 06:52:01PM -0700, Stephen Boyd wrote:
> > > Trimming Cc list way down, sorry if that's too much.
> > >
> > > Quoting Maxime Ripa
On Wed, 07 Apr 2021, Hans Verkuil wrote:
> On 07/04/2021 12:31, Jani Nikula wrote:
>> On Wed, 07 Apr 2021, Hans Verkuil wrote:
>>> It is the most complete EDID parser I know based on the various standards.
>>
>> Does it support pure DisplayID in addition to DisplayID blocks embedded
>> to EDID e
On Thu, 8 Apr 2021 13:30:16 +0200
Daniel Vetter wrote:
> On Thu, Apr 08, 2021 at 12:59:19PM +0300, Pekka Paalanen wrote:
> > The point of these documentation patches is to establish the convention
> > that:
> >
> > - drm_mode_get_plane::format_type_ptr is the list of pixel formats that
> > ca
1 - 100 of 156 matches
Mail list logo
