On Fri, Jan 6, 2023 at 5:23 PM Brian Norris wrote:
> v2:
> * add 'ret != 0' warning case for self-refresh
> * describe failing test case and relation to drm/rockchip patch better
Ugh, there's always something you remember right after you hit send: I
forgot to better summarize some of the other
If we disable vblank when entering self-refresh, vblank APIs (like
DRM_IOCTL_WAIT_VBLANK) no longer work. But user space is not aware when
we enter self-refresh, so this appears to be an API violation -- that
DRM_IOCTL_WAIT_VBLANK fails with EINVAL whenever the display is idle and
enters
The self-refresh helper framework overloads "disable" to sometimes mean
"go into self-refresh mode," and this mode activates automatically
(e.g., after some period of unchanging display output). In such cases,
the display pipe is still considered "on", and user-space is not aware
that we went into
On Fri, Jan 06, 2023 at 12:42:54PM +0100, Michel Dänzer wrote:
> On 1/6/23 02:40, Brian Norris wrote:
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > @@ -719,11 +719,11 @@ static void vop_crtc_atomic_disable(struct drm_crtc
> >
Hi Daniel
Thanks for looking into this series.
On 1/6/2023 1:49 PM, Dmitry Baryshkov wrote:
On Fri, 6 Jan 2023 at 20:41, Daniel Vetter wrote:
On Fri, Jan 06, 2023 at 05:43:23AM +0200, Dmitry Baryshkov wrote:
On Fri, 6 Jan 2023 at 02:38, Jessica Zhang wrote:
On 1/5/2023 3:33 AM, Daniel
On Thu, Jan 05, 2023 at 01:35:52PM +, Tvrtko Ursulin wrote:
>
> Okay to sum it up below with some final notes..
>
> On 04/01/2023 19:34, Matt Roper wrote:
> > On Wed, Jan 04, 2023 at 09:58:13AM +, Tvrtko Ursulin wrote:
> > >
> > > On 23/12/2022 18:28, Lucas De Marchi wrote:
> > > > On
The pull request you sent on Sat, 7 Jan 2023 00:05:01 +0100:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-01-06
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0a71553536d270e988580a3daa9fc87535908221
Thank you!
--
Deet-doot-dot, I am a bot.
On Thu, Jan 05, 2023 at 09:43:41PM +, Matthew Brost wrote:
> On Tue, Jan 03, 2023 at 01:02:15PM +, Tvrtko Ursulin wrote:
> >
> > On 02/01/2023 07:30, Boris Brezillon wrote:
> > > On Fri, 30 Dec 2022 12:55:08 +0100
> > > Boris Brezillon wrote:
> > >
> > > > On Fri, 30 Dec 2022 11:20:42
Hi Linus
Still not much, but more than last week. Dave should be back next week
from the beaching.
drm-fixes-2023-01-06:
drm-fixes for 6.2-rc3
drivers:
- i915-gvt fixes
- amdgpu/kfd fixes
- panfrost bo refcounting fix
- meson afbc corruption fix
- imx plane width fix
core:
- drm/sched fixes
-
On Fri, Jan 06, 2023 at 05:12:57PM -0500, Hang Zhang wrote:
> On Fri, Jan 6, 2023 at 4:19 PM Daniel Vetter wrote:
> > On Fri, Jan 06, 2023 at 03:25:14PM -0500, Hang Zhang wrote:
> > > On Fri, Jan 6, 2023 at 3:05 PM Daniel Vetter wrote:
> > > > On Fri, Jan 06, 2023 at 02:58:27PM -0500, Hang Zhang
On Fri, Jan 06, 2023 at 01:30:16PM -0800, Brian Norris wrote:
> On Fri, Jan 06, 2023 at 09:30:56PM +0100, Daniel Vetter wrote:
> > On Fri, Jan 06, 2023 at 11:33:06AM -0800, Brian Norris wrote:
> > > On Fri, Jan 06, 2023 at 07:17:53PM +0100, Daniel Vetter wrote:
> > > > - check that drivers which
On Fri, Jan 6, 2023 at 1:54 AM Daniel Vetter wrote:
>
> On Thu, Jan 05, 2023 at 01:40:28PM -0800, Tao Wu(吴涛@Eng) wrote:
> > Hi Daniel,
> >
> > May I know what's the requirement for adding render node support to a
> > "gpu"? Why we just export render node for every drm devices?
> > I read
On Fri, Jan 06, 2023 at 05:48:55PM +0100, Stephen Kitt wrote:
> Instead of retrieving the backlight brightness in struct
> backlight_properties manually, and then checking whether the backlight
> should be on at all, use backlight_get_brightness() which does all
> this and insulates this from
Hi Dave, Daniel,
New stuff for 6.3.
The following changes since commit 7a18e089eff02f17eaee49fc18641f5d16a8284b:
drm/amd/pm: update SMU13.0.0 reported maximum shader clock (2022-12-15
12:18:08 -0500)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
On Fri, 6 Jan 2023 at 22:57, Jessica Zhang wrote:
> On 1/4/2023 6:16 PM, Dmitry Baryshkov wrote:
> > On 05/01/2023 01:40, Jessica Zhang wrote:
> >> Initialize and use the color_fill properties for planes in DPU driver. In
> >> addition, relax framebuffer requirements within atomic commit path and
On Fri, 6 Jan 2023 at 20:41, Daniel Vetter wrote:
>
> On Fri, Jan 06, 2023 at 05:43:23AM +0200, Dmitry Baryshkov wrote:
> > On Fri, 6 Jan 2023 at 02:38, Jessica Zhang
> > wrote:
> > >
> > >
> > >
> > > On 1/5/2023 3:33 AM, Daniel Vetter wrote:
> > > > On Wed, Jan 04, 2023 at 03:40:33PM -0800,
On Fri, Jan 06, 2023 at 09:30:56PM +0100, Daniel Vetter wrote:
> On Fri, Jan 06, 2023 at 11:33:06AM -0800, Brian Norris wrote:
> > On Fri, Jan 06, 2023 at 07:17:53PM +0100, Daniel Vetter wrote:
> > > - check that drivers which use self_refresh are not using
> > >
On Fri, Jan 06, 2023 at 03:25:14PM -0500, Hang Zhang wrote:
> On Fri, Jan 6, 2023 at 3:05 PM Daniel Vetter wrote:
> > On Fri, Jan 06, 2023 at 02:58:27PM -0500, Hang Zhang wrote:
> > > On Fri, Jan 6, 2023 at 1:59 PM Daniel Vetter wrote:
> > > BTW, if this is worthed a fix and the performance of
On Fri, Jan 6, 2023 at 8:05 AM Thomas Zimmermann wrote:
>
> Hi,
>
> I've pushed this fix into drm-misc-next. It will hopefully restore the
> fbdev consoles. Sorry for the inconvenience. If things still don't work,
> stating
>
>video=1024x768-32
>
> on the kernel command line should be a safe
On 1/4/2023 6:16 PM, Dmitry Baryshkov wrote:
On 05/01/2023 01:40, Jessica Zhang wrote:
Initialize and use the color_fill properties for planes in DPU driver. In
addition, relax framebuffer requirements within atomic commit path and
add checks for NULL framebuffers. Finally, drop
On 1/4/2023 5:57 PM, Dmitry Baryshkov wrote:
On 05/01/2023 01:40, Jessica Zhang wrote:
Loosen the requirements for atomic and legacy commit so that, in cases
where solid fill planes is enabled (and FB_ID is NULL), the commit can
still go through.
In addition, add framebuffer NULL checks in
On Fri, Jan 06, 2023 at 11:33:06AM -0800, Brian Norris wrote:
> On Fri, Jan 06, 2023 at 07:17:53PM +0100, Daniel Vetter wrote:
> > Ok I think I was a bit slow here, and it makes sense. Except this now
> > means we loose this check, and I'm also not sure whether we really want
> > drivers to
This started with work on the removal of backlight_properties'
deprecated fb_blank field, much of which can be taken care of by using
helper functions provided by backlight.h instead of directly accessing
fields in backlight_properties. This patch series doesn't involve
fb_blank, but it still
Hi Daniel,
On Fri, 6 Jan 2023 18:43:36 +0100, Daniel Vetter wrote:
> On Fri, Jan 06, 2023 at 05:48:52PM +0100, Stephen Kitt wrote:
> > Instead of retrieving the backlight brightness in struct
> > backlight_properties manually, and then checking whether the backlight
> > should be on at all, use
On Thu, Jan 05, 2023 at 04:30:39PM -0300, Maíra Canal wrote:
> The structs drm_debugfs_info and drm_debugfs_entry don't have
> descriptions for their parameters, which is causing the following warnings:
>
> include/drm/drm_debugfs.h:93: warning: Function parameter or member
> 'name' not described
On Fri, Jan 06, 2023 at 08:34:13AM -0300, Maíra Canal wrote:
> Hi,
>
> Thanks for the review!
>
> On 1/6/23 05:10, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 05.01.23 um 19:43 schrieb Melissa Wen:
> > > On 01/05, Maíra Canal wrote:
> > > > With commit 359c6649cd9a ("drm/gem: Implement
On Fri, Jan 06, 2023 at 07:02:22PM +0900, Yi Xie wrote:
> I have figured out the problem with importing buffers across vgem/vkms.
>
> It's intentionally blocked by kernel here:
> https://github.com/torvalds/linux/blob/a140a6a2d5ec0329ad05cd3532a91ad0ce58dceb/drivers/gpu/drm/drm_gem.c#L307
Uh
On Fri, Jan 06, 2023 at 02:58:27PM -0500, Hang Zhang wrote:
> On Fri, Jan 6, 2023 at 1:59 PM Daniel Vetter wrote:
> >
> > On Thu, Jan 05, 2023 at 01:38:54PM -0500, Hang Zhang wrote:
> > > On Thu, Jan 5, 2023 at 5:25 AM Daniel Vetter wrote:
> > > >
> > > > On Thu, 5 Jan 2023 at 11:21, Daniel
On Mon, Dec 26, 2022 at 12:50:29PM -0300, Maíra Canal wrote:
> Replace the use of drm_debugfs_create_files() with the new
> drm_debugfs_add_files() function, which center the debugfs files
> management on the drm_device instead of drm_minor. Moreover, remove the
> debugfs_init hook and add the
On Mon, Dec 26, 2022 at 12:50:25PM -0300, Maíra Canal wrote:
> Replace the use of drm_debugfs_create_files() with the new
> drm_debugfs_add_file() function, which center the debugfs files
> management on the drm_device instead of drm_minor. Moreover, remove the
> debugfs_init hook and add the
On 12/26/22 12:50, Maíra Canal wrote:
Replace the use of drm_debugfs_create_files() with the new
drm_debugfs_add_files() function, which center the debugfs files
management on the drm_device instead of drm_minor. Moreover, remove the
debugfs_init hook and add the debugfs files directly on
On 12/26/22 12:50, Maíra Canal wrote:
Replace the use of drm_debugfs_create_files() with the new
drm_debugfs_add_file() function, which center the debugfs files
management on the drm_device instead of drm_minor. Moreover, remove the
debugfs_init hook and add the debugfs files directly on
On 1/5/2023 7:43 PM, Dmitry Baryshkov wrote:
On Fri, 6 Jan 2023 at 02:38, Jessica Zhang wrote:
On 1/5/2023 3:33 AM, Daniel Vetter wrote:
On Wed, Jan 04, 2023 at 03:40:33PM -0800, Jessica Zhang wrote:
Introduce and add support for a solid_fill property. When the solid_fill
property is
On Fri, Jan 06, 2023 at 07:17:53PM +0100, Daniel Vetter wrote:
> Ok I think I was a bit slow here, and it makes sense. Except this now
> means we loose this check, and I'm also not sure whether we really want
> drivers to implement this all.
>
> What I think we want here is a bit more:
> - for
On Fri, Jan 06, 2023 at 07:20:40PM +0100, Daniel Vetter wrote:
> On Fri, Jan 06, 2023 at 10:08:53AM -0800, Brian Norris wrote:
> > OK! Then that sounds like it at least ACKs my general idea for this
> > series. (Michel and I poked at a few ideas in the thread at [1] and
> > landed on approx. this
On Thu, Jan 05, 2023 at 01:38:54PM -0500, Hang Zhang wrote:
> On Thu, Jan 5, 2023 at 5:25 AM Daniel Vetter wrote:
> >
> > On Thu, 5 Jan 2023 at 11:21, Daniel Vetter wrote:
> > >
> > > Hi Helge
> > >
> > > On Mon, 2 Jan 2023 at 16:28, Helge Deller wrote:
> > > >
> > > > On 12/30/22 07:35, Hang
On Thu, Jan 05, 2023 at 09:16:36PM +0100, Uwe Kleine-König wrote:
> Hello Daniel,
>
> On Thu, Jan 05, 2023 at 03:33:13PM +0100, Daniel Vetter wrote:
> > On Tue, Dec 20, 2022 at 08:24:18AM +0100, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 19.12.22 um 19:31 schrieb Uwe Kleine-König:
> > > >
On 12/6/2022 03:06, Tvrtko Ursulin wrote:
On 05/12/2022 18:44, Michal Wajdeczko wrote:
On 05.12.2022 14:16, Tvrtko Ursulin wrote:
On 02/12/2022 20:14, John Harrison wrote:
[snip]
Random meaningless (to me) message that is apparently a display thing:
drm_dbg_kms(_priv->drm, "disabling %s\n",
Just a quick drive-by. For these simple cases where we just need to make
sure that memory is freed using drmm_kmalloc and friends should help
simplify things. Probably not worth it for radeon, but figured I'll throw
it out there.
For more functional code switching to drmm is harder because you
On Fri, Jan 06, 2023 at 05:43:23AM +0200, Dmitry Baryshkov wrote:
> On Fri, 6 Jan 2023 at 02:38, Jessica Zhang wrote:
> >
> >
> >
> > On 1/5/2023 3:33 AM, Daniel Vetter wrote:
> > > On Wed, Jan 04, 2023 at 03:40:33PM -0800, Jessica Zhang wrote:
> > >> Introduce and add support for a solid_fill
On Fri, Jan 06, 2023 at 05:09:34PM +0800, Jiasheng Jiang wrote:
> Add checks for the return value of alloc_workqueue and
> alloc_ordered_workqueue as they may return NULL pointer and cause NULL
> pointer dereference.
> Moreover, destroy them when fails later in order to avoid memory leak.
>
On Fri, Jan 06, 2023 at 05:48:54PM +0100, Stephen Kitt wrote:
> Instead of retrieving the backlight brightness in struct
> backlight_properties manually, and then checking whether the backlight
> should be on at all, use backlight_get_brightness() which does all
> this and insulates this from
On Fri, 6 Jan 2023 at 14:23, Stanislaw Gruszka
wrote:
>
> On Fri, Jan 06, 2023 at 11:50:05AM +0100, Daniel Vetter wrote:
> > On Thu, Dec 08, 2022 at 12:07:29PM +0100, Jacek Lawrynowicz wrote:
> > > Adds four types of GEM-based BOs for the VPU:
> > > - shmem
> > > - userptr
> > > - internal
On Fri, Jan 06, 2023 at 10:08:53AM -0800, Brian Norris wrote:
> Hi Daniel,
>
> On Fri, Jan 06, 2023 at 06:53:49PM +0100, Daniel Vetter wrote:
> > On Thu, Jan 05, 2023 at 05:40:17PM -0800, Brian Norris wrote:
> > > The self-refresh helper framework overloads "disable" to sometimes mean
> > > "go
On Fri, Jan 06, 2023 at 06:53:49PM +0100, Daniel Vetter wrote:
> On Thu, Jan 05, 2023 at 05:40:17PM -0800, Brian Norris wrote:
> > The self-refresh helper framework overloads "disable" to sometimes mean
> > "go into self-refresh mode," and this mode activates automatically
> > (e.g., after some
Not sure why git send-email didn't thread this, I can resend if
necessary.
Le 06/01/2023 17:48, Stephen Kitt a écrit :
This started with work on the removal of backlight_properties'
deprecated fb_blank field, much of which can be taken care of by using
helper functions provided by backlight.h
Hi Daniel,
On Fri, Jan 06, 2023 at 06:53:49PM +0100, Daniel Vetter wrote:
> On Thu, Jan 05, 2023 at 05:40:17PM -0800, Brian Norris wrote:
> > The self-refresh helper framework overloads "disable" to sometimes mean
> > "go into self-refresh mode," and this mode activates automatically
> > (e.g.,
Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Signed-off-by: Stephen Kitt
---
On Fri, Jan 06, 2023 at 03:53:13PM +0100, Christian König wrote:
> Am 06.01.23 um 11:53 schrieb Daniel Vetter:
> > On Fri, Jan 06, 2023 at 11:32:17AM +0100, Christian König wrote:
> > > Am 05.01.23 um 13:32 schrieb Daniel Vetter:
> > > > [SNIP]
> > > > > For the case of an master fd I actually
On Mon, Dec 12, 2022 at 8:28 PM Jagan Teki wrote:
>
> HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies
> 0 = Enable and 1 = Disable.
>
> The logic for checking these mode flags was correct before
> the MIPI_DSI*_NO_* mode flag conversion.
>
> This patch is trying to fix this
On Fri, Jan 06, 2023 at 08:57:59AM -0300, Maíra Canal wrote:
> With commit 359c6649cd9a ("drm/gem: Implement shadow-plane {begin,
> end}_fb_access with vmap"), the behavior of the shadow-plane helpers
> changed and the vunmap is now performed at the end of
> the current pageflip, instead of the
On Mon, Dec 12, 2022 at 11:59 PM Jagan Teki wrote:
>
> Split the Exynos DSI bridge chain update patches from Samsung DSIM
> bridge driver for easy to apply.
>
> Changes for v11:
> - enable bridge.pre_enable_prev_first
> Changes for v10:
> - collect Marek.V Review tag
Any update on this?
Jagan.
On Thu, Jan 05, 2023 at 05:40:17PM -0800, Brian Norris wrote:
> The self-refresh helper framework overloads "disable" to sometimes mean
> "go into self-refresh mode," and this mode activates automatically
> (e.g., after some period of unchanging display output). In such cases,
> the display pipe
On Fri, Jan 06, 2023 at 08:04:19AM +0100, Greg KH wrote:
> On Thu, Jan 05, 2023 at 05:40:17PM -0800, Brian Norris wrote:
> > The self-refresh helper framework overloads "disable" to sometimes mean
> > "go into self-refresh mode," and this mode activates automatically
> > (e.g., after some period
On Fri, Jan 06, 2023 at 05:48:55PM +0100, Stephen Kitt wrote:
> Instead of retrieving the backlight brightness in struct
> backlight_properties manually, and then checking whether the backlight
> should be on at all, use backlight_get_brightness() which does all
> this and insulates this from
On Fri, Jan 06, 2023 at 05:48:53PM +0100, Stephen Kitt wrote:
> Instead of retrieving the backlight brightness in struct
> backlight_properties manually, and then checking whether the backlight
> should be on at all, use backlight_get_brightness() which does all
> this and insulates this from
Hi Stephen,
On Fri, Jan 06, 2023 at 05:48:52PM +0100, Stephen Kitt wrote:
> Instead of retrieving the backlight brightness in struct
> backlight_properties manually, and then checking whether the backlight
> should be on at all, use backlight_get_brightness() which does all
> this and insulates
On Fri, Jan 06, 2023 at 05:48:52PM +0100, Stephen Kitt wrote:
> Instead of retrieving the backlight brightness in struct
> backlight_properties manually, and then checking whether the backlight
> should be on at all, use backlight_get_brightness() which does all
> this and insulates this from
On Thu, Jan 05, 2023 at 08:04:13PM +, Simon Ser wrote:
> To be honest, your suggestion to put the check inside framebuffer_check()
> sounds like a better idea: we wouldn't even hit any driver-specific
> code-path when the check fails. Daniel, do you think there'd be an issue
> with this
On Thu, Jan 05, 2023 at 03:02:20PM -0500, Rodrigo Vivi wrote:
> Hi Dave and Daniel,
>
> Only GVT related fixes for this round.
>
> I have another fix queued for i915_vma_unbind_async from Nirmoy that will
> target stable 5.18, but I figured it out late so I didn't run CI on that yet.
> So I'm
On Fri, Jan 06, 2023 at 05:15:28PM +, Robin Murphy wrote:
> On 2023-01-06 16:42, Jason Gunthorpe wrote:
> > The internal mechanisms support this, but instead of exposting the gfp to
> > the caller it wrappers it into iommu_map() and iommu_map_atomic()
> >
> > Fix this instead of adding more
On 2023-01-06 16:42, Jason Gunthorpe wrote:
The internal mechanisms support this, but instead of exposting the gfp to
the caller it wrappers it into iommu_map() and iommu_map_atomic()
Fix this instead of adding more variants for GFP_KERNEL_ACCOUNT.
FWIW, since we *do* have two variants
Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Signed-off-by: Stephen Kitt
---
Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Signed-off-by: Stephen Kitt
---
Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Signed-off-by: Stephen Kitt
---
There is only one call site and it can now just pass the GFP_ATOMIC to the
normal iommu_map().
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/dma-iommu.c | 2 +-
drivers/iommu/iommu.c | 7 ---
include/linux/iommu.h | 9 -
3 files changed, 1 insertion(+), 17 deletions(-)
Flow it down to alloc_pgtable_page() via pfn_to_dma_pte() and
__domain_mapping().
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/intel/iommu.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c
This is eventually called by iommufd through intel_iommu_map_pages() and
it should not be forced to atomic. Push the GFP_ATOMIC to all callers.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/intel/iommu.c | 14 +++---
drivers/iommu/intel/iommu.h | 2 +-
drivers/iommu/intel/pasid.c |
The internal mechanisms support this, but instead of exposting the gfp to
the caller it wrappers it into iommu_map() and iommu_map_atomic()
Fix this instead of adding more variants for GFP_KERNEL_ACCOUNT.
Signed-off-by: Jason Gunthorpe
---
arch/arm/mm/dma-mapping.c | 11
dma_alloc_cpu_table() and dma_alloc_page_table() are eventually called by
iommufd through s390_iommu_map_pages() and it should not be forced to
atomic. Thread the gfp parameter through the call chain starting from
s390_iommu_map_pages().
Signed-off-by: Jason Gunthorpe
---
Change the sg_alloc_table_from_pages() allocation that was hardwired to
GFP_KERNEL to use the gfp parameter like the other allocations in this
function.
Auditing says this is never called from an atomic context, so it is safe
as is, but reads wrong.
Signed-off-by: Jason Gunthorpe
---
Follow the pattern for iommu_map() and remove iommu_map_sg_atomic().
This allows __iommu_dma_alloc_noncontiguous() to use a GFP_KERNEL
allocation here, based on the provided gfp flags.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/dma-iommu.c | 5 +++--
drivers/iommu/iommu.c | 21
iommufd follows the same design as KVM and uses memory cgroups to limit
the amount of kernel memory a iommufd file descriptor can pin down. The
various internal data structures already use GFP_KERNEL_ACCOUNT to charge
its own memory.
However, one of the biggest consumers of kernel memory is the
iommufd follows the same design as KVM and uses memory cgroups to limit
the amount of kernel memory a iommufd file descriptor can pin down. The
various internal data structures already use GFP_KERNEL_ACCOUNT.
However, one of the biggest consumers of kernel memory is the IOPTEs
stored under the
On Fri, Jan 06, 2023 at 10:38:35AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Revert to the original explicit approach and document the reasoning
> behind it.
>
> v2:
> * DG2 needs to be covered too. (Matt)
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Matt Roper
> Cc: Balasubramani
On Thu, Jan 05, 2023 at 11:20:38AM -0800, Kees Cook wrote:
> Zero-length arrays are deprecated[1]. Replace struct aperture's "ranges"
> 0-length array with a flexible array. (How is the size of this array
> verified?) Detected with GCC 13, using -fstrict-flex-arrays=3:
>
>
On 06/01/2023 17:39, Krzysztof Kozlowski wrote:
On 07/12/2022 02:22, Dmitry Baryshkov wrote:
SM8350 and SM8450 platforms use the same driver and same bindings as the
existing 7nm DSI PHYs. Add corresponding compatibility strings.
Acked-by: Krzysztof Kozlowski
Signed-off-by: Dmitry Baryshkov
On 04/01/2023 10:08, Neil Armstrong wrote:
> Document the SM8550 DSI PHY which is very close from the 7nm
> and 5nm DSI PHYs found in earlier platforms.
>
> Signed-off-by: Neil Armstrong
> ---
> Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml | 1 +
> 1 file changed, 1
On 07/12/2022 02:22, Dmitry Baryshkov wrote:
> SM8350 and SM8450 platforms use the same driver and same bindings as the
> existing 7nm DSI PHYs. Add corresponding compatibility strings.
>
> Acked-by: Krzysztof Kozlowski
> Signed-off-by: Dmitry Baryshkov
> ---
>
Applied. Thanks!
Alex
On Fri, Jan 6, 2023 at 5:00 AM Liwei Song wrote:
>
> Fix below kmemleak when unload radeon driver:
>
> unreferenced object 0x9f8608ede200 (size 512):
> comm "systemd-udevd", pid 326, jiffies 4294682822 (age 716.338s)
> hex dump (first 32 bytes):
> 00 00 00 00
Applied. Thanks!
Alex
On Thu, Jan 5, 2023 at 8:37 PM Yang Li wrote:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c:65 amdgpu_gem_fault() warn:
> inconsistent indenting
>
> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3639
> Reported-by: Abaci Robot
> Signed-off-by: Yang Li
> ---
>
Applied. Thanks!
Alex
On Thu, Jan 5, 2023 at 7:30 PM Yang Li wrote:
>
> ./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:7431:3-4: Unneeded
> semicolon
> ./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:7485:4-5: Unneeded
> semicolon
>
Applied. Thanks!
Alex
On Thu, Jan 5, 2023 at 2:20 PM Harry Wentland wrote:
>
> On 12/16/22 05:23, Yi Yang wrote:
> > Smatch report warning as follows:
> >
> > Line 53679: drivers/gpu/drm/amd/display/dc/core/dc_stream.c:402
> > dc_stream_set_cursor_position() warn: variable dereferenced before
On 1/5/23 17:23, Hamza Mahfooz wrote:
> Currently, there are issues with enabling PSR-SU + DSC. This stems from
> the fact that DSC imposes a slice height on transmitted video data and
> we are not conforming to that slice height in PSR-SU regions. So, pass
> slice_height into su_y_granularity
Am 06.01.23 um 11:53 schrieb Daniel Vetter:
On Fri, Jan 06, 2023 at 11:32:17AM +0100, Christian König wrote:
Am 05.01.23 um 13:32 schrieb Daniel Vetter:
[SNIP]
For the case of an master fd I actually don't see the reason why we should
limit that? And fd can become master if it either was
On Fri, Jan 6, 2023 at 11:34 AM Adam Ford wrote:
> I got it working on an LVDS display that I have, but I didn't get it
> working on the HDMI bridge. Since we have a few tested-by people,
> it'd be nice to see this integrated so we can work on ading more
> functionality
Agreed. Hopefully, this
On Thu, Jan 5, 2023 at 4:24 AM Jagan Teki wrote:
>
> On Wed, Dec 14, 2022 at 6:29 PM Jagan Teki wrote:
> >
> > This series supports common bridge support for Samsung MIPI DSIM
> > which is used in Exynos and i.MX8MM SoC's.
> >
> > The final bridge supports both the Exynos and i.MX8M
Hi Andrzej,
On 2/22/2022 12:25 AM, Andrzej Hajda wrote:
Beside reusing existing code, the main advantage of ref_tracker is
tracking per instance of wakeref. It allows also to catch double
put.
On the other side we lose information about the first acquire and
the last release, but the advantages
Hi,
I've pushed this fix into drm-misc-next. It will hopefully restore the
fbdev consoles. Sorry for the inconvenience. If things still don't work,
stating
video=1024x768-32
on the kernel command line should be a safe override on most systems.
Best regards
Thomas
Am 06.01.23 um 12:23
Hi
On Thu, Jan 05, 2023 at 12:46:51PM -0600, Andrew Davis wrote:
> On 12/8/22 5:07 AM, Jacek Lawrynowicz wrote:
> > Adds four types of GEM-based BOs for the VPU:
> >- shmem
> >- userptr
>
> Do you have some specific need for userptr that would not
> be covered by prime import + heaps?
On Fri, Jan 06, 2023 at 11:50:05AM +0100, Daniel Vetter wrote:
> On Thu, Dec 08, 2022 at 12:07:29PM +0100, Jacek Lawrynowicz wrote:
> > Adds four types of GEM-based BOs for the VPU:
> > - shmem
> > - userptr
> > - internal
>
> Uh what do you need this for? Usually the way we do these is
On 05/01/2023 12:32, Daniel Vetter wrote:
On Fri, Dec 02, 2022 at 10:01:01AM +0100, Christian König wrote:
Am 01.12.22 um 12:09 schrieb Tvrtko Ursulin:
On 30/11/2022 14:18, Daniel Vetter wrote:
On Wed, Nov 30, 2022 at 01:34:07PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
With the
Hi Neil,
> > > +properties:
> > > + compatible:
> > > +const: visionox,vtdr6130
> > > +
> > > + vddio-supply: true
> > > + vci-supply: true
> > > + vdd-supply: true
> > These 3 looks wrong to me, as the above are not documented in panel-common.
> > But maybe I miss something and this is
On 03/01/2023 15:22, Neil Armstrong wrote:
> Document the 1080x2400 Visionox VTDR6130 AMOLED DSI Panel bindings.
>
> Signed-off-by: Neil Armstrong
> ---
> .../bindings/display/panel/visionox,vtdr6130.yaml | 53
> ++
> 1 file changed, 53 insertions(+)
Reviewed-by:
On 05/01/2023 14:24, Pin-yen Lin wrote:
> ITE IT6505 can be used in systems to switch the DP traffic between
> two downstreams, which can be USB Type-C DisplayPort alternate mode
> lane or regular DisplayPort output ports.
Use subject prefixes matching the subsystem (which you can get for
example
On Fri, Jan 06, 2023 at 11:44:58AM +0100, Daniel Vetter wrote:
> > > The problem is going to happen as soon as you have cross-vendor userspace.
> > > Which I'm kinda hoping is at least still the aspiration. Because with
> > > cross-vendor userspace you generally iterate & open all devices before
With commit 359c6649cd9a ("drm/gem: Implement shadow-plane {begin,
end}_fb_access with vmap"), the behavior of the shadow-plane helpers
changed and the vunmap is now performed at the end of
the current pageflip, instead of the end of the following pageflip.
By performing the vunmap at the end of
Hi
Am 06.01.23 um 12:34 schrieb Maíra Canal:
Hi,
Thanks for the review!
On 1/6/23 05:10, Thomas Zimmermann wrote:
Hi
Am 05.01.23 um 19:43 schrieb Melissa Wen:
On 01/05, Maíra Canal wrote:
With commit 359c6649cd9a ("drm/gem: Implement shadow-plane {begin,
end}_fb_access with vmap"), the
On Fri, Jan 6, 2023 at 12:45 PM Daniel Vetter wrote:
>
> On Fri, 6 Jan 2023 at 10:56, Stanislaw Gruszka
> wrote:
> >
> > On Fri, Jan 06, 2023 at 10:28:15AM +0100, Daniel Vetter wrote:
> > > On Thu, Jan 05, 2023 at 07:38:26PM +0200, Oded Gabbay wrote:
> > > > On Thu, Jan 5, 2023 at 6:25 PM
On 1/6/23 02:40, Brian Norris wrote:
> If we disable vblank when entering self-refresh, vblank APIs (like
> DRM_IOCTL_WAIT_VBLANK) no longer work. But user space is not aware when
> we enter self-refresh, so this appears to be an API violation -- that
> DRM_IOCTL_WAIT_VBLANK fails with EINVAL
1 - 100 of 136 matches
Mail list logo
