On Tue, Apr 20, 2021 at 09:26:00AM +, peter.enderb...@sony.com wrote:
> On 4/20/21 10:58 AM, Daniel Vetter wrote:
> > On Sat, Apr 17, 2021 at 06:38:35PM +0200, Peter Enderborg wrote:
> >> This adds a total used dma-buf memory. Details
> >> can be found in deb
EAD(BLC_PWM_CTL2);
> @@ -2037,7 +2035,7 @@ cdv_intel_dp_init(struct drm_device *dev, struct
> psb_intel_mode_device *mode_dev
> pp_on = REG_READ(PP_ON_DELAYS);
> pp_off = REG_READ(PP_OFF_DELAYS);
> pp_div = REG_READ(PP_DIVISOR);
> -
>
+ b/include/linux/dma-buf.h
> @@ -507,4 +507,5 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct
> *,
>unsigned long);
> int dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
> void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
> +long dma_buf_allocated_pages(void);
> #endif /* __DMA_BUF_H__ */
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
2: warning: expecting prototype for A
> > buffer object shrink method that tries to swap out the first(). Prototype
> > was for ttm_global_swapout() instead
> >
> > Cc: Christian Koenig
> > Cc: Huang Rui
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: dri-d
int meminfo_proc_show(struct seq_file *m,
> > > > void *v)
> > > > show_val_kb(m, "CmaFree: ",
> > > > global_zone_page_state(NR_FREE_CMA_PAGES));
> > > > #endif
> > > > -
> > > > +#ifdef CONFIG_DMA_SHARED_BUFFER
> > > > + show_val_kb(m, "DmaBufTotal: ", dma_buf_allocated_pages());
> > > > +#endif
> > > > hugetlb_report_meminfo(m);
> > > > arch_report_meminfo(m);
> > > > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> > > > index efdc56b9d95f..5b05816bd2cd 100644
> > > > --- a/include/linux/dma-buf.h
> > > > +++ b/include/linux/dma-buf.h
> > > > @@ -507,4 +507,5 @@ int dma_buf_mmap(struct dma_buf *, struct
> > > > vm_area_struct *,
> > > > unsigned long);
> > > > int dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
> > > > void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
> > > > +long dma_buf_allocated_pages(void);
> > > > #endif /* __DMA_BUF_H__ */
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_fb_helper {
> */
> bool deferred_setup;
>
> + /**
> +* @no_dpms_blank:
> +*
> +* A flag indicating that the driver doesn't support blanking.
> +* Then fbcon core code falls back to its generic handler.
> +*/
> + bool no_dpms_blank;
> +
> /**
> * @preferred_bpp:
> *
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
7; of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2021-04-15 15:24:17
+0200)
drm/i915 fixes
--------
Daniel Vetter (1):
Merge tag 'drm-intel-fixes-2021
408,6 +408,16 @@ void unregister_shrinker(struct shrinker *shrinker)
> }
> EXPORT_SYMBOL(unregister_shrinker);
>
> +/**
> + * sync_shrinker - Wait for all running shrinkers to complete.
Maybe make it clear this is a barrier type thing, it wont stop shrinkers
at all, just synchronize
> > + if (efifb_pci_dev)
> > + pm_runtime_put(&efifb_pci_dev->dev);
> >
> > return 0;
> > }
> > --
> > 2.30.2
> >
> > ___________
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Apr 12, 2021 at 08:23:33AM -0700, Rob Clark wrote:
> On Mon, Apr 12, 2021 at 7:28 AM Daniel Vetter wrote:
> >
> > On Thu, Apr 08, 2021 at 08:23:42AM -0700, Rob Clark wrote:
> > > On Thu, Apr 8, 2021 at 4:15 AM Daniel Vetter wrote:
> > > >
> > &g
On Thu, Apr 08, 2021 at 08:23:42AM -0700, Rob Clark wrote:
> On Thu, Apr 8, 2021 at 4:15 AM Daniel Vetter wrote:
> >
> > On Mon, Apr 05, 2021 at 10:45:23AM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > One would normally hope not to be und
T_RESIZEX sets it to
> the same values it already has.
>
> Exactly because setting a font line number to anything else than the
> font size isn't exactly sensible.
>
> But if your screen looks different than it used to, that is obviously
> interesting and says something actually changed (outside of the
> message itself).
>
>Linus
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
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 bd2
ay_free(syncobjs, args->count_handles);
>
> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> index 9f12efaaa93a..6ffb4b2c6371 100644
> --- a/include/linux/dma-fence.h
> +++ b/include/linux/dma-fence.h
> @@ -587,6 +587,7 @@ static inline signed long dma_fence_wait(struct dma_fence
> *fence, bool intr)
> }
>
> struct dma_fence *dma_fence_get_stub(void);
> +struct dma_fence *dma_fence_allocate_private_stub(void);
> u64 dma_fence_context_alloc(unsigned num);
>
> #define DMA_FENCE_TRACE(f, fmt, args...) \
> --
> 2.31.0.208.g409f899ff0-goog
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
fig ui tends
to suck.
If you want to change this, we need automatic conflict resolution like apt
and other package managers have, with suggestions how to fix the config if
you want to enable a driver, but some of its requirements are missing. The
current approach of hiding driver symbols complete if any of their
dependencies are off is really not great.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
unt = 0;/* Currently no users */
> dev_priv->suspended = false;/* And not suspended */
> - spin_lock_init(&power_ctrl_lock);
> mutex_init(&power_mutex);
>
> if (dev_priv->ops->init_pm)
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
; dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
t drm_file *file_priv,
> struct drm_gem_object *obj,
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
t; > > Introduced by commit
> > >
> > > 8840e3bd981f ("drm/i915: Fix the GT fence revocation runtime PM logic")
> >
> > This warning now exists in Linus' tree.
> >
> > --
> > Cheers,
> > Stephen Rothwell
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
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 Wed, Mar 24, 2021 at 08:17:10PM +0100, Daniel Vetter wrote:
> On Wed, Mar 24, 2021 at 09:52:11AM -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
7;t stable
> >> and
> >> can be zapped and refaulted under us while we do the walk.
> > I didn't say it would be simple :) But we also need to stop hacking
> > around the sides of all this huge page stuff and come up with sensible
> > APIs that drivers can actually implement correctly. Exposing drivers
> > to specific kinds of page levels really feels like the wrong level of
> > abstraction.
> >
> > Once we start doing this we should do it everywhere, the io_remap_pfn
> > stuff should be able to create huge special IO pages as well, for
> > instance.
>
> Oh, yes please!
>
> We easily have 16GiB of VRAM which is linear mapped into the kernel
> space for each GPU instance.
>
> Doing that with 1GiB mapping instead of 4KiB would be quite a win.
io_remap_pfn is for userspace mmaps. Kernel mappings should be as big
as possible already I think for everything.
-Daniel
> Regards,
> Christian.
>
> >
> >> On top of this, the user-space address allocator needs to know how large
> >> gpu
> >> pages are aligned in buffer objects to have a reasonable chance of aligning
> >> with CPU huge page boundaries which is a requirement to be able to insert a
> >> huge CPU page table entry, so the driver would basically need the drm
> >> helper
> >> that can do this alignment anyway.
> > Don't you have this problem anyhow?
> >
> > Jason
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Mar 25, 2021 at 10:16 AM Daniel Vetter wrote:
>
> On Thu, Mar 25, 2021 at 7:53 AM Oleksandr Andrushchenko
> wrote:
> >
> > Hi,
> >
> > On 3/25/21 8:19 AM, Wan Jiabing wrote:
> > > struct xen_drm_front_drm_info has been declared.
> > > R
vers/gpu/drm/xen/xen_drm_front_conn.h
> > @@ -16,7 +16,6 @@
> > struct drm_connector;
> > struct xen_drm_front_drm_info;
> >
> > -struct xen_drm_front_drm_info;
> >
> > int xen_drm_front_conn_init(struct xen_drm_front_drm_info *drm_info,
> > struct drm_connector *connector);
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Mar 24, 2021 at 09:52:11AM -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
;open));
>
> spin_lock(&obj->vma.lock);
> - vma = vma_lookup(obj, vm, view);
> + vma = i915_vma_lookup(obj, vm, view);
> spin_unlock(&obj->vma.lock);
>
> /* vma_create() will resolve the race if another creates the vma */
> --
> 2.30.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
sk3.amr.corp.intel.com
> >
> Hmm, yes with that patch it will obviously not work as intended.
>
> Given that, I think we'll need to disable the TTM huge pages for now until
> we can sort out and agree on using a page table entry bit.
Yeah :-/
I think going full pud
gt;
> >
> > Also, I feel like this code to install "pte_special" huge pages does
> > not belong in the drm subsystem..
>
> I could add helpers in huge_memory.c:
>
> vmf_insert_pfn_pmd_prot_special() and
> vmf_insert_pfn_pud_prot_special()
The somewhat annoying thing is that we'd need an error code so we fall
back to pte fault handling. That's at least my understanding of how
pud/pmd fault handling works. Not sure how awkward that is going to be
with the overall fault handling flow.
But aside from that I think this makes tons of sense.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Mar 24, 2021 at 04:15:37AM +0200, Laurent Pinchart wrote:
> On Wed, Jan 20, 2021 at 06:38:03PM +0100, Daniel Vetter wrote:
> > On Wed, Jan 20, 2021 at 6:12 PM Paul Cercueil wrote:
> > > Le mer. 20 janv. 2021 à 17:03, Daniel Vetter a écrit :
> > > > On Wed
t; means there should not be a performance difference anymore, but this
> needs to be verified.
>
> Cc: Christian Koenig
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Andrew Morton
> Cc: Jason Gunthorpe
> Cc: linux...@kvack.org
> Cc: dri-de...@lists.freedeskto
ficial to other graphis drivers moving forward as well.
>
> Cc: Christian Koenig
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Andrew Morton
> Cc: Jason Gunthorpe
> Cc: linux...@kvack.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org
> Si
> #else
> -#define vga_put(pdev, rsrc)
> +static inline void vga_put(struct pci_dev *pdev, unsigned int rsrc)
> +{
> +}
> #endif
>
>
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Mar 19, 2021 at 08:24:07AM +, Lee Jones wrote:
> On Thu, 18 Mar 2021, Daniel Vetter wrote:
>
> > On Wed, Mar 17, 2021 at 9:32 PM Daniel Vetter wrote:
> > >
> > > On Wed, Mar 17, 2021 at 9:17 AM Lee Jones wrote:
> > > >
&g
> - * callers need to make sure to eventually unreference the returned property
> + * callers need to make sure to eventually unreferenced the returned property
> * again, using drm_property_blob_put().
> *
> * Return:
> --
> 2.26.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Mar 17, 2021 at 9:32 PM Daniel Vetter wrote:
>
> On Wed, Mar 17, 2021 at 9:17 AM Lee Jones wrote:
> >
> > On Thu, 11 Mar 2021, Lee Jones wrote:
> >
> > > On Thu, 11 Mar 2021, Daniel Vetter wrote:
> > >
> > > > On Mon, Mar 08, 2021
On Wed, Mar 17, 2021 at 9:17 AM Lee Jones wrote:
>
> On Thu, 11 Mar 2021, Lee Jones wrote:
>
> > On Thu, 11 Mar 2021, Daniel Vetter wrote:
> >
> > > On Mon, Mar 08, 2021 at 09:19:32AM +, Lee Jones wrote:
> > > > On Fri, 05 Mar 2021, Roland Scheidegge
On Wed, Mar 17, 2021 at 8:22 AM Christoph Hellwig wrote:
> On Tue, Mar 16, 2021 at 04:52:44PM +0100, Daniel Vetter wrote:
> > My understanding is mostly, but with some objections. And I kinda
> > don't want to let this die in a bikeshed and then not getting rid of
> &
On Tue, Mar 16, 2021 at 4:46 PM Christoph Hellwig wrote:
>
> On Tue, Mar 16, 2021 at 04:33:02PM +0100, Daniel Vetter wrote:
> > The media model assumes that buffers are all preallocated, so that
> > when a media pipeline is running we never miss a deadline because the
> >
nzini
Cc: Jason Gunthorpe
Cc: Cornelia Huck
Cc: Peter Xu
Cc: Alex Williamson
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: k...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
include/linux/mm.h |
Support io userptr operations on io memory").
Acked-by: Tomasz Figa
Acked-by: Hans Verkuil
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc
u_notifier, and that's
all _GPL stuff.
Signed-off-by: Daniel Vetter
Cc: Christoph Hellwig
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.o
Assuming no objections I'd like to lande these three patches in my topic
branch for 5.13, for sufficient amounts of testing in linux-next before
the merge window.
Ack/review especially on the two mm patches very much thought after.
Cheers, Daniel
Daniel Vetter (3):
mm: Add unsafe_follo
On Fri, Mar 12, 2021 at 05:10:43PM +0100, Dmitry Vyukov wrote:
> On Fri, Mar 12, 2021 at 3:22 PM Daniel Vetter wrote:
> >
> > On Fri, Mar 12, 2021 at 11:46:27AM +0100, Dmitry Vyukov wrote:
> > > On Fri, Mar 12, 2021 at 11:26 AM syzbot
> > > wrote:
> > &g
On Mon, Mar 15, 2021 at 10:11 PM Jason Ekstrand wrote:
>
> On Wed, Sep 30, 2020 at 4:55 AM Daniel Vetter wrote:
> >
> > On Wed, Sep 30, 2020 at 11:39:06AM +0200, Michel Dänzer wrote:
> > > On 2020-03-17 10:21 p.m., Jason Ekstrand wrote:
> > > > Explicit s
On Sat, Mar 13, 2021 at 10:57 PM Bjorn Helgaas wrote:
>
> [+cc Krzysztof, Pali, Oliver]
>
> On Thu, Feb 04, 2021 at 05:58:31PM +0100, Daniel Vetter wrote:
> > Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
> > the region") /dev/kmem
> > 0x0
> >
> >
> > ---
> > This report is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkal...@googlegroups.com.
> >
> > syzbot will keep track of this issue. See:
> > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "syzkaller-bugs" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to syzkaller-bugs+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/syzkaller-bugs/9cd8d505bd545452%40google.com.
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
info *info, struct vm_area_struct *vma);
> extern void fb_deferred_io_init(struct fb_info *info);
> -extern void fb_deferred_io_open(struct fb_info *info,
> - struct inode *inode,
> - struct file *file);
> extern void fb_deferred_io_cleanup(struct fb_info *info);
> extern int fb_deferred_io_fsync(struct file *file, loff_t start,
> loff_t end, int datasync);
> --
> 2.30.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ext again (they
are queued up for 5.13 in drm-misc-next, I checked that).
Sorry for the confusion here.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
/drivers/gpu/drm/radeon/radeon_kms.c
> > @@ -518,6 +518,7 @@ int radeon_info_ioctl(struct drm_device *dev, void
> > *data, struct drm_file *filp)
> > *value = rdev->config.si.backend_enable_mask;
> > } else {
> >
_text_mode_force;
> static bool vga_hardscroll_enabled;
> --
> 2.30.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ized
> > Memory access of size 16 starts at 88814ffe3c98
> > Data copied to user address 2100
> > =
>
> compat_drm_wait_vblank would need to initialize
>
> req.reply.tval_usec = req32.reply.tval_usec;
>
> before calling drm_ioctl_kernel, since it's not aliased by any
> req.request.* member, and drm_wait_vblank_ioctl doesn't always write to
> it.
I've fixed this in
commit e926c474ebee404441c838d18224cd6f246a71b7
Author: Daniel Vetter
Date: Mon Feb 22 11:06:43 2021 +0100
drm/compat: Clear bounce structures
Or at least tried to.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
anything important in there. Can you pls do that and respin your
patch?
Thanks, Daniel
> {
> assert_spin_locked(&dev->event_lock);
>
> --
> 1.8.3.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bfc1b86e3e73..434adb869522 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5793,7 +5793,7 @@ M: David Airlie
> M: Daniel Vetter
> L: dr
noise, set the VM_PFNMAP in the
> system and cma heap's mmap handler.
>
> Cc: Daniel Vetter
> Cc: Jason Gunthorpe
> Cc: Christian Koenig
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Chris Goldsworthy
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: Hridya Valsaraj
#ifndef __NVKM_PCI_AGP_H__
> > #define __NVKM_PCI_AGP_H__
> >
> > +/* SPDX-License-Identifier: MIT */
> > +#include "priv.h"
> > +#if IS_ENABLED(CONFIG_AGP)
> > void nvkm_agp_ctor(struct nvkm_pci *);
> > void nvkm_agp_dtor(struct nvkm_pci *);
> > void nvkm_agp_preinit(struct nvkm_pci *);
> > int nvkm_agp_init(struct nvkm_pci *);
> > void nvkm_agp_fini(struct nvkm_pci *);
> > -#endif
> > #else
> > static inline void nvkm_agp_ctor(struct nvkm_pci *pci) {}
> > static inline void nvkm_agp_dtor(struct nvkm_pci *pci) {}
> > @@ -17,3 +16,5 @@ static inline void nvkm_agp_preinit(struct nvkm_pci *pci)
> > {}
> > static inline int nvkm_agp_init(struct nvkm_pci *pci) { return -ENOSYS; }
> > static inline void nvkm_agp_fini(struct nvkm_pci *pci) {}
> > #endif
> > +
> > +#endif
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Feb 25, 2021 at 2:27 PM Gerd Hoffmann wrote:
>
> On Thu, Feb 25, 2021 at 11:32:08AM +0100, Daniel Vetter wrote:
> > On Thu, Feb 25, 2021 at 11:25:20AM +0100, Gerd Hoffmann wrote:
> > > On Thu, Feb 25, 2021 at 10:09:42AM +0100, Daniel Vetter wrote:
> > > >
On Thu, Feb 25, 2021 at 11:25:20AM +0100, Gerd Hoffmann wrote:
> On Thu, Feb 25, 2021 at 10:09:42AM +0100, Daniel Vetter wrote:
> > On Wed, Feb 24, 2021 at 11:55 AM Sumera Priyadarsini
> > wrote:
> > >
> > > Add a virtual hardware or vblank-less mode as a modul
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 35540c7c4416..d4a45518639c 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -85,6 +85,7 @@ struct vkms_device;
> struct vkms_config {
> bool writeback;
> bool cursor;
> + bool virtual_hw;
> /* only set when instantiated */
> struct vkms_device *dev;
> };
> @@ -127,6 +128,7 @@ int vkms_verify_crc_source(struct drm_crtc *crtc, const
> char *source_name,
> /* Composer Support */
> void vkms_composer_worker(struct work_struct *work);
> void vkms_set_composer(struct vkms_output *out, bool enabled);
> +void vkms_crtc_composer(struct vkms_crtc_state *crtc_state);
>
> /* Writeback */
> int vkms_enable_writeback_connector(struct vkms_device *vkmsdev);
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Feb 23, 2021 at 2:42 AM Linus Torvalds
wrote:
>
> On Mon, Feb 22, 2021 at 2:25 AM Daniel Vetter wrote:
> >
> > Cc all the mailing lists ... my usual script crashed and I had to
> > hand-roll the email and screwed it up ofc :-/
>
> Oh, and my reply thus a
did you mean 'aty_st_8'?
> [-Werror=implicit-function-declaration]
> 2004 | aty_st_lcd(POWER_MANAGEMENT, pm, par);
>
> Signed-off-by: Randy Dunlap
> Reported-by: kernel test robot
> Cc: linux-fb...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: Bart
Cc all the mailing lists ... my usual script crashed and I had to
hand-roll the email and screwed it up ofc :-/
-Daniel
On Mon, Feb 22, 2021 at 11:23 AM Daniel Vetter wrote:
>
> Hi Linus,
>
> Another small pull from you to ponder.
>
> This is the first part of a patch series I&
ventpoll.c| 4 ++--
include/linux/eventpoll.h | 2 +-
init/Kconfig | 11 +++
kernel/Makefile | 2 +-
tools/testing/selftests/seccomp/seccomp_bpf.c | 2 +-
6 files changed, 19 insertions(+), 5 deletions(-)
On Tue, Feb 16, 2021 at 09:21:46AM +0100, Christian König wrote:
> The last user went away in the 5.11 cycle.
>
> Signed-off-by: Christian König
Nice.
Reviewed-by: Daniel Vetter
I think would be good to still stuff this into 5.12 before someone
resurrects this zombie
If you do want to solve this at the dma-buf level I can try and point you
at the respective i915 and amdgpu code that makes the magic work - I've
had to fix it a few times in the past. I'm not sure whether we'd need to
pass the dynamic nature through though, i.e. whether
Daniel
>
> -Kees
>
> > Cc: Kees Cook
> > Cc: Andy Lutomirski
> > Cc: Will Drewry
> > Cc: Andrew Morton
> > Cc: Dave Airlie
> > Cc: Daniel Vetter
> > Cc: Lucas Stach
> > Cc: Rasmus Villemoes
> > Cc: Cyrill Gorcunov
On Wed, Feb 10, 2021 at 04:12:58PM +, Lee Jones wrote:
> On Wed, 10 Feb 2021, Daniel Vetter wrote:
>
> > On Wed, Feb 10, 2021 at 08:23:41AM +, Lee Jones wrote:
> > > On Tue, 09 Feb 2021, Julia Lawall wrote:
> > >
> > > > Use getter and setter fun
On Thu, Feb 11, 2021 at 04:21:51PM +0800, Kevin Tang wrote:
> Daniel Vetter 于2021年2月3日周三 下午10:15写道：
>
> > On Tue, Jan 05, 2021 at 09:46:05PM +0800, Kevin Tang wrote:
> > > Adds DPU(Display Processor Unit) support for the Unisoc's display
> > subsystem.
> &g
On Wed, Feb 10, 2021 at 10:40 PM Bjorn Helgaas wrote:
>
> On Fri, Feb 05, 2021 at 02:36:32PM +0100, Daniel Vetter wrote:
> > We are already doing this for all the regular sysfs files on PCI
> > devices, but not yet on the legacy io files on the PCI buses. Thus far
> > no
first cut merged sooner than later if
possible. And the other prep work has been in -next since -rc1.
Thanks, Daniel
On Fri, Feb 5, 2021 at 2:36 PM Daniel Vetter wrote:
>
> We are already doing this for all the regular sysfs files on PCI
> devices, but not yet on the legacy io files on
On Wed, Feb 10, 2021 at 5:39 PM Suren Baghdasaryan wrote:
>
> On Wed, Feb 10, 2021 at 5:06 AM Daniel Vetter wrote:
> >
> > On Tue, Feb 09, 2021 at 12:16:51PM -0800, Suren Baghdasaryan wrote:
> > > On Tue, Feb 9, 2021 at 12:03 PM Daniel Vetter wrote:
> > > &
gt;
> > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
> > drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +-
> > drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
> > 3 files changed, 3 insertions(+), 3 deletions(-)
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
-
> > drivers/video/backlight/qcom-wled.c |
> > 2 +-
>
> This patch is fine.
>
> Could you please split it out and submit it separately though please.
Or just apply the entire patch through backlight tree, there's nothing
going
> diff --git a/drivers/gpu/drm/panel/panel-lvds.c
> b/drivers/gpu/drm/panel/panel-lvds.c
> index 66c7d765b8f7..59a8d99e777d 100644
> --- a/drivers/gpu/drm/panel/panel-lvds.c
> +++ b/drivers/gpu/drm/panel/panel-lvds.c
> @@ -244,7 +244,7 @@ static int panel_lvds_probe(struct platform_device *pdev)
>
> static int panel_lvds_remove(struct platform_device *pdev)
> {
> - struct panel_lvds *lvds = dev_get_drvdata(&pdev->dev);
> + struct panel_lvds *lvds = platform_get_drvdata(pdev);
>
> drm_panel_remove(&lvds->panel);
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Feb 09, 2021 at 12:16:51PM -0800, Suren Baghdasaryan wrote:
> On Tue, Feb 9, 2021 at 12:03 PM Daniel Vetter wrote:
> >
> > On Tue, Feb 9, 2021 at 6:46 PM Christian König
> > wrote:
> > >
> > >
> > >
> > > Am 09.02.21 um 18:33 sch
On Tue, Feb 09, 2021 at 12:53:27PM -0800, John Hubbard wrote:
> On 2/9/21 5:37 AM, Daniel Vetter wrote:
> > On Tue, Feb 9, 2021 at 1:57 PM Alistair Popple wrote:
> > >
> > > On Tuesday, 9 February 2021 9:27:05 PM AEDT Daniel Vetter wrote:
> > > > >
accounting needs with cgroups. That should work, and it will
allow Android to handle all the Android-ism in a clean way in upstream
code. Or that's at least the plan.
I think the only thing we identified that Android still needs on top
is the dma-buf sysfs stuff, so that shared buffers (which on An
On Tue, Feb 9, 2021 at 2:35 PM Jason Gunthorpe wrote:
>
> On Tue, Feb 09, 2021 at 11:57:28PM +1100, Alistair Popple wrote:
> > On Tuesday, 9 February 2021 9:27:05 PM AEDT Daniel Vetter wrote:
> > > >
> > > > Recent changes to pin_user_pages() prevent the
On Tue, Feb 9, 2021 at 1:57 PM Alistair Popple wrote:
>
> On Tuesday, 9 February 2021 9:27:05 PM AEDT Daniel Vetter wrote:
> > >
> > > Recent changes to pin_user_pages() prevent the creation of pinned pages in
> > > ZONE_MOVABLE. This series allows pinned page
| 1 +
> mm/migrate.c | 82 +---
> tools/testing/selftests/vm/hmm-tests.c| 49 +
> 14 files changed, 524 insertions(+), 101 deletions(-)
>
> --
> 2.20.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
,
> -format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
> -format);
> + snprintf(buf->str, sizeof(buf->str), "%p4cc", &format);
>
> return buf->str;
> }
> --
> 2.29.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Feb 8, 2021 at 9:51 PM John Stultz wrote:
> On Mon, Feb 8, 2021 at 2:08 AM Daniel Vetter wrote:
> > On Sat, Feb 06, 2021 at 05:47:48AM +, John Stultz wrote:
> > > By default dma_buf_export() sets the exporter name to be
> > > KBUILD_MODNAME. Unfortunately t
On Mon, Feb 8, 2021 at 12:49 PM Michel Dänzer wrote:
>
> On 2021-02-05 9:53 p.m., Daniel Vetter wrote:
> > On Fri, Feb 5, 2021 at 7:37 PM Kees Cook wrote:
> >>
> >> On Fri, Feb 05, 2021 at 04:37:52PM +, Chris Wilson wrote:
> >>> Userspace has discov
can cause some minor confusion with tooling, and there is
> the future potential where multiple heap types may be exported
> by the same module (but would all have the same name).
>
> So to avoid all this, set the exporter exp_name to the heap name.
>
> Cc: Daniel Vetter
> Cc
t; >
> > On Thu, Feb 04, 2021 at 05:58:30PM +0100, Daniel Vetter wrote:
> > > We are already doing this for all the regular sysfs files on PCI
> > > devices, but not yet on the legacy io files on the PCI buses. Thus far
> > > now problem, but in the next patch I wa
erstanding is that Linus
wants to have visibility into conflict-y stuff and doesn't mind at all
resolving conflicts. Hence for 5.12 I think we're fine as-is.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ace from iomem_get_mapping() when userspace calls
mmap(). This also works, but Greg didn't really like that just to work
around an ordering issue when the kernel loads initially.
v2: Improve commit message (Bjorn)
Signed-off-by: Daniel Vetter
Cc: Stephen Rothwell
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan
ed and thought it's part of this patch already. So v3 with
matching subject to enabled it for drm?
-Daniel
>
> > Otherwise, yeah, this looks good. Was the
> > export due to the 0-day bot failure reports?
>
> Yes.
> -Chris
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
t; > Signed-off-by: Chris Wilson
> > Cc: Kees Cook
> > Cc: Andy Lutomirski
> > Cc: Will Drewry
> > Cc: Andrew Morton
> > Cc: Dave Airlie
> > Cc: Daniel Vetter
> > Cc: Lucas Stach
> > ---
> > init/Kconfig
On Fri, Feb 5, 2021 at 11:04 AM Pali Rohár wrote:
>
> On Friday 05 February 2021 10:59:50 Daniel Vetter wrote:
> > On Thu, Feb 4, 2021 at 11:24 PM Pali Rohár wrote:
> > >
> > > On Thursday 04 February 2021 15:50:19 Bjorn Helgaas wrote:
> > > > [+cc Ol
The following commit has been merged into the x86/sgx branch of tip:
Commit-ID: dc9b7be557ca94301ea5c06c0d72307e642ffb18
Gitweb:
https://git.kernel.org/tip/dc9b7be557ca94301ea5c06c0d72307e642ffb18
Author:Daniel Vetter
AuthorDate:Thu, 04 Feb 2021 19:45:19 +01:00
Committer
On Thu, Feb 4, 2021 at 10:50 PM Bjorn Helgaas wrote:
>
> [+cc Oliver, Pali, Krzysztof]
>
> s/also/Also/ in subject
>
> On Thu, Feb 04, 2021 at 05:58:30PM +0100, Daniel Vetter wrote:
> > We are already doing this for all the regular sysfs files on PCI
> > devices
On Fri, Feb 5, 2021 at 3:26 AM Jarkko Sakkinen wrote:
>
> On Thu, Feb 04, 2021 at 07:45:19PM +0100, Daniel Vetter wrote:
> > References:
> > https://lore.kernel.org/dri-devel/20201127164131.2244124-1-daniel.vet...@ffwll.ch/
>
> What is the difference between this an
.
Wire it up exactly like the existing code. Note that
pci_remove_legacy_files() doesn't need a check since the one for
pci_bus->legacy_io is sufficient.
Signed-off-by: Daniel Vetter
Cc: Stephen Rothwell
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hub
nen
Cc: Borislav Petkov
Cc: linux-...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
arch/x86/kernel/cpu/sgx/encl.c | 8
1 file changed, 8 deletions(-)
diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
index ee50a5010277..20a2dd5ba2b4 100644
--- a/arch/x86/kernel/c
Acked-by: Bjorn Helgaas
Reviewed-by: Dan Williams
Signed-off-by: Daniel Vetter
Cc: Stephen Rothwell
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: Greg Kroah-Hartman
Cc: linux...@kvack.org
Cc: linux-ar
linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
Daniel Vetter (2):
PCI: also set up legacy files only after sysfs init
PCI: Revoke mappings like devmem
drivers/pci/pci-sysfs.c
them up.
>
> In general I think we need to make it possible that both the in kernel OOM
> killer as well as userspace processes and handlers have access to that kind
> of data.
>
> The fdinfo approach as suggested in the other thread sounds like the easiest
> solution to me.
Yeah for OOM handling cgroups alone isn't enough as the interface - we
need to make sure that oom killer takes into account the system memory
usage (ideally zone aware, for CMA pools).
But to track that we still need that infrastructure first I think.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Feb 03, 2021 at 02:11:09PM -0800, Rob Clark wrote:
> On Wed, Feb 3, 2021 at 1:58 PM Stephen Boyd wrote:
> >
> > Quoting Rob Clark (2021-02-03 09:29:09)
> > > On Wed, Feb 3, 2021 at 2:10 AM Daniel Vetter wrote:
> > > >
> > > > On Tue, F
On Wed, Feb 3, 2021 at 5:14 PM Daniel Vetter wrote:
>
> On Tue, Jan 19, 2021 at 5:03 PM Daniel Vetter wrote:
> >
> > On Tue, Jan 19, 2021 at 4:20 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Tue, Jan 19, 2021 at 03:34:47PM +0100, Daniel Vetter wrot
On Thu, Feb 4, 2021 at 9:13 AM Christian König wrote:
>
> Am 03.02.21 um 21:14 schrieb Hridya Valsaraju:
> > On Wed, Feb 3, 2021 at 2:25 AM Daniel Vetter wrote:
> >> On Mon, Feb 01, 2021 at 01:02:30PM -0800, Hridya Valsaraju wrote:
> >>> On Mon, Feb 1, 2021
1 - 100 of 1562 matches
Mail list logo
