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 b
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);
> -
> +
> /* Pull
signed 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
; 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-de...@lists.freedesktop.org
> > Signed-off-by: Lee Jone
",
> > > > 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
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
://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-04-15' of
git
+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 synchro
> + pm_runtime_put(_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
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
e.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
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
->display_count = 0;/* Currently no users */
> dev_priv->suspended = false;/* And not suspended */
> - spin_lock_init(_ctrl_lock);
> mutex_init(_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
gt; > >
> > > 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
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
>
> spin_lock(>vma.lock);
> - vma = vma_lookup(obj, vm, view);
> + vma = i915_vma_lookup(obj, vm, view);
> spin_unlock(>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
tel.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/pmd_mkspecial shoul
ike 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
ld 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.freedesktop.org
> Cc: linux-kern
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
> Signed-off-b
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
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
> > f
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
> >
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 | 2 --
mm/
rt 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: lin
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.org
Cc: lin
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_follow_pfn
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
>
> >
> > ---
> > 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
d 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
gain (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
pu/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 {
> > DRM_DEBUG
_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
> > 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
ant in there. Can you pls do that and respin your
patch?
Thanks, Daniel
> {
> assert_spin_locked(>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 Valsaraju
&g
_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
;
> config->writeback = enable_writeback;
> + config->virtual_hw = enable_virtual_hw;
>
> return vkms_create(config);
> }
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 35540c7c4416..d4a45518639c 100644
> --- a/drivers
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
=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: Bartlomiej Zolnierkiewicz
> Cc: Sam Ravnborg
>
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
| 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(-)
--
Daniel
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
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 we want to be able to
scan out imported dma-buf and hence request they be used in uncache
;
> -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
> > Cc: sta...@
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
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
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 the PCI bu
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 on i
rivers/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(>dev);
> + struct panel_lvds *lvds = platform_get_drvdata(pdev);
>
> drm_panel_remove(>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:
> > > > >
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 Android
are always dma-buf, and always stay around as dma-buf fd throughout
their lifetime) can be lis
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()
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
quot; : "little",
> -format);
> + snprintf(buf->str, sizeof(buf->str), "%p4cc", );
>
> 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. Unfortunatel
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
This 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 want to
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
rom 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 Williams
d 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
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 Hubbard
av 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/cpu/sgx/encl.c
+
ed-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-arm-ker...@lists.infradead.org
Cc: li
-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 | 11
ed 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 6575 matches
Mail list logo
