g W=1 kernel build warning(s):
>
> drivers/gpu/drm/imx/ipuv3-plane.c: In function ‘ipu_planes_assign_pre’:
> drivers/gpu/drm/imx/ipuv3-plane.c:746:42: warning: variable ‘crtc_state’ set
> but not used [-Wunused-but-set-variable]
>
> Cc: Philipp Zabel
> Cc: David Airlie
&
On Wed, Nov 18, 2020 at 3:40 AM John Stultz wrote:
> On Fri, Nov 13, 2020 at 12:39 PM Daniel Vetter wrote:
> > On Thu, Nov 12, 2020 at 08:11:02PM -0800, John Stultz wrote:
> > > On Thu, Nov 12, 2020 at 1:32 AM Daniel Vetter wrote:
> > > > On Thu, Nov 12, 2020 at
f
/dev/fb0. And we should probably also delay the hotplug handling until
the first open. fbcon also fake-opens the fbdev file, so it's the same
code path.
-Daniel
>
> Best regards
> Thomas
>
> > return 0;
> >
> > err_poll_fini:
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
fbmem.c
seems to not store any blanking state at all, so this is probably all
ill-defined.
Important part is to do this only for the user fb_open case, since
fbcon will do its own thing too.
Plus I guess we need to document that this is the uapi we're having
for fbdev clients, so ideally this should be cc'ed widely so we can
get some acks from former fbdev maintainers.
Also ideally we'd have an igt for this uapi to make sure it never
breaks again. Something like:
1. open the kms driver for this, make sure display is completely off.
2. close kms file
3. open fbdev file
4. check (through opening kms side again) that the display has been enabled.
See
https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#validating-changes-with-igt
for some details on our validation testing, there's already a very
basic fbdev testcase there.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> + cmd = *buf;
> + if (cmd == HALCYON_HEADER2)
> state = state_header2;
> else if ((cmd & HALCYON_HEADER1MASK) == HALCYON_HEADER1)
> state = state_header1;
> --
> 2.29.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Nov 18, 2020 at 5:02 PM Bjorn Helgaas wrote:
>
> On Fri, Nov 06, 2020 at 10:39:16AM +0100, Daniel Vetter wrote:
> > On Thu, Nov 5, 2020 at 3:17 PM Bjorn Helgaas wrote:
> > > On Thu, Nov 05, 2020 at 11:46:06AM +0200, Joonas Lahtinen wrote:
> > > > Quotin
__x64_sys_ioctl+0x91/0xc0
> > >> [ 21.083167] do_syscall_64+0x38/0x90
> > >> [ 21.086755] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > >> [ 21.091813] RIP: 0033:0x7f5b3cf1350b
> > >> [ 21.095403] Code: 0f 1e fa 48 8b 05 85 39 0d 00 64 c7 00 26 00 00 00
> > >> 48 c7 c0 ff ff ff ff c3 66
> > 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01
> > c3 48 8b 0d 55 39 0d 00 f7
> > d8 64 89 01 48
> > >> [ 21.114154] RSP: 002b:7ffef1966588 EFLAGS: 0246 ORIG_RAX:
> > >> 0010
> > >> [ 21.121730] RAX: ffda RBX: 7ffef19665c0 RCX:
> > >> 7f5b3cf1350b
> > >> [ 21.128870] RDX: 7ffef19665c0 RSI: c02464bb RDI:
> > >> 0009
> > >> [ 21.136013] RBP: c02464bb R08: 0040 R09:
> > >> 0004
> > >> [ 21.143157] R10: 0002 R11: 0246 R12:
> > >> 561ec9d10060
> > >> [ 21.150295] R13: 0009 R14: 561eca2cc9a0 R15:
> > >> 0040
> >
> > --
> > Thomas Zimmermann
> > Graphics Driver Developer
> > SUSE Software Solutions Germany GmbH
> > Maxfeldstr. 5, 90409 Nürnberg, Germany
> > (HRB 36809, AG Nürnberg)
> > Geschäftsführer: Felix Imendörffer
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1
> 1PT, UK
> Registration No: 1397386 (Wales)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Dec 9, 2020 at 12:33 PM Sumera Priyadarsini
wrote:
>
> On Wed, Dec 9, 2020 at 6:24 AM Daniel Vetter wrote:
> >
> > On Wed, Dec 09, 2020 at 02:07:35AM +0530, Sumera Priyadarsini wrote:
> > > Update the vkms documentation to contain steps to:
> >
On Wed, Dec 9, 2020 at 12:29 PM Tomi Valkeinen wrote:
>
> On 09/12/2020 02:48, Daniel Vetter wrote:
> > On Tue, Dec 08, 2020 at 03:50:59PM +0800, Tian Tao wrote:
> >> Use devm_drm_irq_install to register interrupts so that
> >> drm_irq_uninstall is not needed to be c
On Wed, Dec 9, 2020 at 1:06 PM Tomi Valkeinen wrote:
>
> On 09/12/2020 13:56, Daniel Vetter wrote:
> > On Wed, Dec 9, 2020 at 12:29 PM Tomi Valkeinen
> > wrote:
> >>
> >> On 09/12/2020 02:48, Daniel Vetter wrote:
> >>> On Tue, Dec 08, 2020
On Tue, Dec 08, 2020 at 11:54:57AM -0800, Jiaying Liang wrote:
>
> On 12/8/20 9:12 AM, Nicolas Dufresne wrote:
> > Le mercredi 18 novembre 2020 à 00:06 -0800, Wendy Liang a écrit :
> > > Create AI engine device/partition hierarchical structure.
> > >
> > > Each AI engine device can have multiple
itle case (Daniel)
> - Add examples to run tests directly (Daniel)
> - Add examples to run subtests (Melissa)
>
> Changes in v3:
> - Add example using run-tests.sh script(Daniel)
Reviewed-by: Daniel Vetter
> ---
> Documentation/gpu/vkms.rst | 70 +++
On Wed, Dec 09, 2020 at 02:28:18PM -0600, Bjorn Andersson wrote:
> On Tue 08 Dec 17:52 CST 2020, Daniel Vetter wrote:
>
> > On Tue, Dec 08, 2020 at 04:02:16PM -0600, Bjorn Andersson wrote:
> > > On Tue 08 Dec 06:47 CST 2020, Thierry Reding wrote:
> > >
> > &g
Android because
everything's pinned all the time anyway.
Also I thought sysfs was one value one file, dumping an entire list into
dev_info_map with properties we'll need to extend (once you care about
dma_resv you also want to know which attachments are dynamic) does not
smell like sysfs design at all.
So yeah, why? worksformeonandroidweneeditthere not good enough for uapi of
something this core to how the gpu stack works on linux in general, at
least imo.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Dec 10, 2020 at 11:55 AM Greg KH wrote:
>
> On Thu, Dec 10, 2020 at 11:27:27AM +0100, Daniel Vetter wrote:
> > On Thu, Dec 10, 2020 at 11:10:45AM +0100, Greg KH wrote:
> > > On Thu, Dec 10, 2020 at 10:58:50AM +0100, Christian König wrote:
> > > > In gene
On Thu, Dec 10, 2020 at 1:06 PM Greg KH wrote:
>
> On Thu, Dec 10, 2020 at 12:26:01PM +0100, Daniel Vetter wrote:
> > On Thu, Dec 10, 2020 at 11:55 AM Greg KH wrote:
> > >
> > > On Thu, Dec 10, 2020 at 11:27:27AM +0100, Daniel Vetter wrote:
> > > > On T
On Thu, Nov 19, 2020 at 12:14 AM Bjorn Helgaas wrote:
>
> On Wed, Nov 18, 2020 at 10:57:26PM +0100, Daniel Vetter wrote:
> > On Wed, Nov 18, 2020 at 5:02 PM Bjorn Helgaas wrote:
> > > On Fri, Nov 06, 2020 at 10:39:16AM +0100, Daniel Vetter wrote:
> > > > On
ed with pte_mkspecial (which pup_fast rejects in the
fastpath), and only architectures supporting that support the
pin_user_pages_fast fastpath.
Reviewed-by: John Hubbard
Signed-off-by: Daniel Vetter
Cc: Christoph Hellwig
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Gli
The exynos g2d interface is very unusual, but it looks like the
userptr objects are persistent. Hence they need FOLL_LONGTERM.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc
ner, since in e.g. drivers/gpu we
don't do that. Per Dan this seems to be copypasta from places which do
care about pagecache consistency, but not needed. Hence remove it for
slightly less confusion.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Mo
Acked-by: Bjorn Helgaas
Reviewed-by: Dan Williams
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: Greg Kroah-Hartman
Cc: linux...@kvack.org
Cc: linux-arm-ker...@list
subsystem. In
most places this is solved by passing struct kvm * down the call
stacks as an additional parameter, since that contains the
mmu_notifier.
Compile tested on all affected arch.
Signed-off-by: Daniel Vetter
Cc: Christoph Hellwig
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc
ce without mmap support
allowing to adjust the ->f_mapping makes no sense.
Reviewed-by: Greg Kroah-Hartman
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...@k
for the correct mm_struct.
Motivated by discussions with Christoph Hellwig and Jason Gunthorpe.
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
time for
everyone (which required some sysfs changes). Does indeed look a lot
cleaner and a lot less invasive than I feared at first.
I feel like this is ready for some wider soaking. Since the remaining bits
are all kinda connnected probably simplest if it all goes through -mm.
Cheers, Daniel
Dani
names.
Reviewed-by: Greg Kroah-Hartman
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: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kerne
driver is loaded and using it.
Fix this by adding the same iomem_is_exclusive() check we already have
on the sysfs side in pci_mmap_resource().
Acked-by: Bjorn Helgaas
References: 90a545e98126 ("restrict /dev/mem to idle io memory ranges")
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorp
is to wire up an mmu_notifier ... somehow. Probably means any
invalidate is a fatal fault for this vfio device, but then this
shouldn't ever happen if userspace is reasonable.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubb
Support io userptr operations on io memory").
Acked-by: Tomasz Figa
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: linux-arm-ker...@lists.i
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
msung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
--
v2: Fix inversion in the retry check (John).
v4: While at it, use offset_in_page (Chris Wilson)
---
include/linux/mm.h | 3 ++-
mm/memory.c| 46 +++
d-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
Cc: Mauro Carvalho Chehab
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
These are persistent, not just for the duration of a dma operation.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
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: linux-samsung
& (VM_IO | VM_PFNMAP). Such
ptes are marked with pte_mkspecial (which pup_fast rejects in the
fastpath), and only architectures supporting that support the
pin_user_pages_fast fastpath.
Signed-off-by: Daniel Vetter
Cc: Christoph Hellwig
Cc: Jason Gunthorpe
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: K
ed with pte_mkspecial (which pup_fast rejects in the
fastpath), and only architectures supporting that support the
pin_user_pages_fast fastpath.
Reviewed-by: John Hubbard
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc:
set properly.
tbh I'll just go ahead and delete it if it's broken :-)
Userspace we have to keep working (and there's actually people
creating new products on top of drm display drivers using fbdev
emulation and /dev/fb/0 interface!), but kernel internal stuff like
fbcon
On Fri, Nov 20, 2020 at 9:28 AM Hans Verkuil wrote:
>
> On 20/11/2020 09:06, Hans Verkuil wrote:
> > On 19/11/2020 15:41, Daniel Vetter wrote:
> >> The media model assumes that buffers are all preallocated, so that
> >> when a media pipeline is running we nev
On Fri, Nov 20, 2020 at 7:32 AM Sumit Semwal wrote:
>
> Hi Daniel,
>
>
> On Wed, 18 Nov 2020 at 13:16, Daniel Vetter wrote:
> >
> > On Wed, Nov 18, 2020 at 3:40 AM John Stultz wrote:
> > > On Fri, Nov 13, 2020 at 12:39 PM Daniel Vetter wrote:
> > &g
w, testing all very much welcome.
Cheers, Daniel
Daniel Vetter (3):
mm: Track mmu notifiers in fs_reclaim_acquire/release
mm: Extract might_alloc() debug check
locking/selftests: Add testcases for fs_reclaim
include/linux/sched/mm.h | 16 ++
lib/locking-selftes
Cc: Paul E. McKenney
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
Cc: Andrew Morton
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Vlastimil Babka
Cc: Mathieu Desnoyers
Cc: Sebastian Andrzej Siewior
Cc: Michel Lespinasse
Cc: Daniel Vetter
Cc: Waiman Long
Cc: Thomas Gl
Cc: Thomas Hellström (Intel)
Cc: Andrew Morton
Cc: Jason Gunthorpe
Cc: linux...@kvack.org
Cc: linux-r...@vger.kernel.org
Cc: Maarten Lankhorst
Cc: Christian König
Cc: "Matthew Wilcox (Oracle)"
Signed-off-by: Daniel Vetter
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
Cc: linux-ke
't do this, so another
small thing we could standardize between drm and ttm drivers.
Plus I don't really see a need for unamp_mapping_range where we don't
want to indiscriminately shoot down all ptes.
Cc: Thomas Hellstrom
Cc: Brian Paul
Signed-off-by: Daniel Vetter
Cc: Christian K
: Jason Gunthorpe
Cc: linux...@kvack.org
Cc: linux-r...@vger.kernel.org
Cc: Maarten Lankhorst
Cc: Christian König
Cc: "Matthew Wilcox (Oracle)"
Signed-off-by: Daniel Vetter
---
mm/mmu_notifier.c | 7 ---
mm/page_alloc.c | 31 ---
2 files changed, 20 ins
On Fri, Nov 20, 2020 at 11:04 AM Christian König
wrote:
>
> Am 20.11.20 um 10:54 schrieb Daniel Vetter:
> > Random observation while trying to review Christian's patch series to
> > stop looking at struct page for dma-buf imports.
> >
> > This was
On Fri, Nov 20, 2020 at 11:39 AM Hans Verkuil wrote:
>
> On 20/11/2020 10:18, Daniel Vetter wrote:
> > On Fri, Nov 20, 2020 at 9:28 AM Hans Verkuil wrote:
> >>
> >> On 20/11/2020 09:06, Hans Verkuil wrote:
> >>> On 19/11/2020 15:41, Daniel Vetter
On Fri, Nov 20, 2020 at 11:08:31AM +0100, Christian König wrote:
> Am 20.11.20 um 11:05 schrieb Daniel Vetter:
> > On Fri, Nov 20, 2020 at 11:04 AM Christian König
> > wrote:
> > > Am 20.11.20 um 10:54 schrieb Daniel Vetter:
> > > > Random observation whil
p us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
>
> url:
> https://github.com/0day-ci/linux/commits/Daniel-Vetter/follow_pfn-and-other-iomap-races/20201128-004421
> base: git://l
t drm_device *dev,
> unsigned long flags)
> if (ret)
> goto out_err;
>
> + ret = -ENOMEM;
> +
> dev_priv->mmu = psb_mmu_driver_init(dev, 1, 0, 0);
> if (!dev_priv->mmu)
> goto out_err;
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Nov 20, 2020 at 09:23:12PM +0900, Tomasz Figa wrote:
> On Fri, Nov 20, 2020 at 9:08 PM Hans Verkuil wrote:
> >
> > On 20/11/2020 11:51, Daniel Vetter wrote:
> > > On Fri, Nov 20, 2020 at 11:39 AM Hans Verkuil wrote:
> > >>
> > >> On 20/11
On Fri, Nov 20, 2020 at 02:30:29PM -0400, Jason Gunthorpe wrote:
> On Thu, Nov 19, 2020 at 03:41:46PM +0100, Daniel Vetter wrote:
> > @@ -4805,21 +4824,15 @@ EXPORT_SYMBOL(follow_pte_pmd);
> > * Return: zero and the pfn at @pfn on success, -ve otherwise.
> > */
>
On Fri, Nov 20, 2020 at 02:07:19PM -0400, Jason Gunthorpe wrote:
> On Fri, Nov 20, 2020 at 10:54:43AM +0100, Daniel Vetter wrote:
> > diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> > index d5ece7a9a403..f94405d43fd1 100644
> > --- a/include/linux/sched/m
On Wed, Nov 25, 2020 at 9:13 AM Jason Gunthorpe wrote:
>
> On Tue, Nov 24, 2020 at 03:28:14PM +0100, Daniel Vetter wrote:
> > On Fri, Nov 20, 2020 at 02:30:29PM -0400, Jason Gunthorpe wrote:
> > > On Thu, Nov 19, 2020 at 03:41:46PM +0100, Daniel Vetter wrote:
> &g
#x27;m not sure why the bridge state would not be there.
Lack of state on first modeset usually means your
drm_mode_config_reset didn't create one. Or whatever it is you're
using. I didn't look whether you're wiring this up correctly or not.
We might even want to add a -
Cc: linux-...@vger.kernel.org
Cc: Thomas Hellström (Intel)
Cc: Andrew Morton
Cc: Jason Gunthorpe
Cc: linux...@kvack.org
Cc: linux-r...@vger.kernel.org
Cc: Maarten Lankhorst
Cc: Christian König
Cc: "Matthew Wilcox (Oracle)"
Signed-off-by: Daniel Vetter
Cc: Peter Zijlstra
Cc: Ingo Molnar
't do this, so another
small thing we could standardize between drm and ttm drivers.
Plus I don't really see a need for unamp_mapping_range where we don't
want to indiscriminately shoot down all ptes.
Cc: Thomas Hellstrom
Cc: Brian Paul
Signed-off-by: Daniel Vetter
Cc: Christian K
ej Siewior
Cc: Michel Lespinasse
Cc: Daniel Vetter
Cc: Waiman Long
Cc: Thomas Gleixner
Cc: Randy Dunlap
Cc: linux...@kvack.org
Cc: linux-fsde...@vger.kernel.org
Cc: Dave Chinner
Cc: Qian Cai
Cc: linux-...@vger.kernel.org
Cc: "Matthew Wilcox (Oracle)"
Signed-off-by: Daniel Vetter
land. Last version that landed in -mm (v2) broke xfs pretty badly.
Unfortuantely I don't have a working email from Qian anymore, who reported
the xfs issue. Maybe Dave Chinner instead?
Cheers, Daniel
Daniel Vetter (3):
mm: Track mmu notifiers in fs_reclaim_acquire/release
mm: Extract m
)
Cc: Andrew Morton
Cc: Jason Gunthorpe
Cc: linux...@kvack.org
Cc: linux-r...@vger.kernel.org
Cc: Maarten Lankhorst
Cc: Christian König
Cc: "Matthew Wilcox (Oracle)"
Signed-off-by: Daniel Vetter
---
mm/mmu_notifier.c | 7 ---
mm/page_alloc.c | 31 +++
On Wed, Nov 25, 2020 at 5:25 PM Daniel Vetter wrote:
>
> Random observation while trying to review Christian's patch series to
> stop looking at struct page for dma-buf imports.
>
> This was originally added in
>
> commit 58aa6622d32af7d2c08d45085f44c54554a16ed7
> Aut
On Mon, Nov 23, 2020 at 10:51:25AM +0100, Daniel Vetter wrote:
> On Fri, Nov 20, 2020 at 4:23 PM Matti Hamalainen wrote:
> >
> > Commit 03e0d26fcf79 ("drm/nouveau: slowpath for pushbuf ioctl") included
> > a logic-bug which results in the relocations not actually ge
t->reservedbuffer = ioremap( \
> > + pci_resource_start(ast->base.pdev, 0) + (unsigned
> > long)ast->vram_size, \
> > + pci_resource_len(dev->pdev, 0) - ast->vram_size);
>
> Use pci_iomap_range() instead. The function's offset parameter is
> vram_size, the function's maxlen parameter is 0.
>
> You also won't need pci_iounmap(). pci_iomap_range() sets up the cleanup
> for you.
>
> > + if (!ast->reservedbuffer) {
>
> No braces around single-line branch.
>
> > + DRM_INFO("failed to map reserved buffer! \n");
>
> Use drm_info() instead
>
> > + }
> > + }
> > +
> > ret = ast_mode_config_init(ast);
> > if (ret)
> > return ERR_PTR(ret);
> > diff --git a/drivers/gpu/drm/ast/ast_mm.c b/drivers/gpu/drm/ast/ast_mm.c
> > index 8392ebde504b..c6fd24493fb3 100644
> > --- a/drivers/gpu/drm/ast/ast_mm.c
> > +++ b/drivers/gpu/drm/ast/ast_mm.c
> > @@ -90,6 +90,7 @@ int ast_mm_init(struct ast_private *ast)
> > int ret;
> >
> > vram_size = ast_get_vram_size(ast);
> > + ast->vram_size = (uint32_t) vram_size;
>
> You don't need to store vram_size. Look at dev->vram_mm->vram_size instead.
>
> >
> > ret = drmm_vram_helper_init(dev, pci_resource_start(dev->pdev, 0),
> > vram_size);
> > --
> > 2.18.4
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
> ___
> 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 Wed, Dec 16, 2020 at 5:16 PM Paul E. McKenney wrote:
>
> On Wed, Dec 16, 2020 at 10:52:06AM +0100, Daniel Vetter wrote:
> > On Wed, Dec 16, 2020 at 2:14 AM syzbot
> > wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following is
On Thu, Dec 17, 2020 at 9:40 AM Jiaying Liang wrote:
>
>
> On 12/15/20 7:23 AM, Alex Deucher wrote:
> > On Mon, Dec 14, 2020 at 7:24 PM Jiaying Liang
> > wrote:
> >> On 12/11/20 11:39 AM, Daniel Vetter wrote:
> >>> Hi all
> >>>
> >&g
pp));
> + pp.order = orders[i];
> + pools[i] = page_pool_create(&pp);
> +
> + if (IS_ERR(pools[i])) {
> + int j;
> +
> + pr_err("%s: page pool creation failed!\n", __func__);
> + for (j = 0; j < i; j++)
> + page_pool_destroy(pools[j]);
> + return PTR_ERR(pools[i]);
> + }
> + }
>
> exp_info.name = "system";
> exp_info.ops = &system_heap_ops;
> --
> 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
On Fri, Dec 18, 2020 at 5:10 PM Steven Rostedt wrote:
>
> On Thu, 17 Dec 2020 11:03:20 +0100
> Daniel Vetter wrote:
>
> > I think we're tripping over the might_sleep() all the mutexes have,
> > and that's not as good as yours, but good enough to catch a mis
r on variable val
drm/amdgpu: Fix spelling mistake "Heterogenous" -> "Heterogeneous"
Daniel Vetter (6):
char/agp: Disable frontend without CONFIG_DRM_LEGACY
Merge tag 'drm-misc-next-2020-11-27-1' of
git://anongit.freedesktop.org/drm/drm-misc into dr
t just against
creative compilers doing funny stuff that might really break code
logic. I guess for symmetry we could throw the WRITE_ONCE on the write
side, but it really shouldn't matter, the entire thing is racy by
design. We0d also only ever need the write once on the unregister
call.
-Daniel
>
> Best regards,
> Pavel
> --
> http://www.livejournal.com/~pavelmachek
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
AL;
> > + goto out;
> > + }
> >
> > r = crtc->gamma_store;
> > g = r + crtc->gamma_size;
> > @@ -940,8 +944,9 @@ static int setcmap_legacy(struct fb_cmap *cmap, struct
> > fb_info *info)
&
irectly:
# tests/kms_flip --device drm:/dev/dri/card0
I'm not sure whether there's an option that's always going to select
the vkms device. I'm also not sure you can pass these options to
run-tests.sh, I kinda don't use that one myself ...
Aside from that looks all good to me.
-Daniel
> +
> TODO
>
>
> --
> 2.25.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
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
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
> > 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
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
On Tue, Jan 19, 2021 at 11:08:12AM -0800, Yiwei Zhang wrote:
> On Mon, Jan 18, 2021 at 11:03 PM Daniel Vetter wrote:
> >
> > On Tue, Jan 19, 2021 at 12:41 AM Yiwei Zhang wrote:
> > >
> > > On the success of virtio_gpu_object_create, add size of newly allocated
+
> + ldev->mode_info[index].encoder = lencoder;
> +
> + return 0;
> +}
> diff --git a/drivers/gpu/drm/loongson/loongson_plane.c
> b/drivers/gpu/drm/loongson/loongson_plane.c
> new file mode 100644
> index ..288b6c894222
> --- /dev/null
> +++ b/drivers/gpu/drm/loongson/loongson_plane.c
> @@ -0,0 +1,102 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +
> +#include "loongson_drv.h"
> +
> +static void loongson_plane_atomic_update(struct drm_plane *plane,
> + struct drm_plane_state *old_state)
> +{
> + struct loongson_crtc *lcrtc;
> + struct loongson_device *ldev;
> + struct drm_plane_state *state = plane->state;
> + u32 gpu_addr = 0;
> + u32 fb_addr = 0;
> + u32 reg_val = 0;
> + u32 reg_offset;
> + u32 pitch;
> + u8 depth;
> + u32 x, y;
> +
> + if (!state->crtc || !state->fb)
> + return;
> +
> + pitch = state->fb->pitches[0];
> + lcrtc = to_loongson_crtc(state->crtc);
> + ldev = lcrtc->ldev;
> + reg_offset = lcrtc->reg_offset;
> + x = state->crtc->x;
> + y = state->crtc->y;
> + depth = state->fb->format->cpp[0] << 3;
> +
> + gpu_addr = loongson_gpu_offset(state);
> + reg_val = (pitch + 255) & ~255;
> + ls_mm_wreg_locked(ldev, FB_STRI_REG + reg_offset, reg_val);
> +
> + switch (depth) {
> + case 12 ... 16:
> + fb_addr = gpu_addr + y * pitch + ALIGN(x, 64) * 2;
> + break;
> + case 24 ... 32:
> + default:
> + fb_addr = gpu_addr + y * pitch + ALIGN(x, 64) * 4;
> + break;
> + }
> +
> + ls_mm_wreg_locked(ldev, FB_ADDR0_REG + reg_offset, fb_addr);
> + ls_mm_wreg_locked(ldev, FB_ADDR1_REG + reg_offset, fb_addr);
> + reg_val = lcrtc->cfg_reg | CFG_ENABLE;
> + ls_mm_wreg_locked(ldev, FB_CFG_REG + reg_offset, reg_val);
> +}
> +
> +static const uint32_t loongson_formats[] = {
> + DRM_FORMAT_RGB565,
> + DRM_FORMAT_RGB888,
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_ARGB,
> +};
> +
> +static const uint64_t loongson_format_modifiers[] = { DRM_FORMAT_MOD_LINEAR,
> + DRM_FORMAT_MOD_INVALID };
> +
> +static const struct drm_plane_funcs loongson_plane_funcs = {
> + .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
> + .destroy = drm_plane_cleanup,
> + .disable_plane = drm_atomic_helper_disable_plane,
> + .reset = drm_atomic_helper_plane_reset,
> + .update_plane = drm_atomic_helper_update_plane,
> +};
> +
> +static const struct drm_plane_helper_funcs loongson_plane_helper_funcs = {
> + .prepare_fb = drm_gem_vram_plane_helper_prepare_fb,
> + .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb,
> + .atomic_update = loongson_plane_atomic_update,
> +};
> +
> +int loongson_plane_init(struct loongson_crtc *lcrtc)
> +{
> + struct loongson_device *ldev;
> + int crtc_id;
> + int ret;
> +
> + ldev = lcrtc->ldev;
> + crtc_id = lcrtc->crtc_id;
> +
> + lcrtc->plane = devm_kzalloc(ldev->dev->dev, sizeof(*lcrtc->plane),
> + GFP_KERNEL);
> + if (!lcrtc->plane)
> + return -ENOMEM;
> +
> + ret = drm_universal_plane_init(ldev->dev, lcrtc->plane, BIT(crtc_id),
> +&loongson_plane_funcs, loongson_formats,
> +ARRAY_SIZE(loongson_formats),
> +loongson_format_modifiers,
> +DRM_PLANE_TYPE_PRIMARY, NULL);
> + if (ret) {
> + DRM_ERROR("fail to init planed crtc %d\n", crtc_id);
> + return ret;
> + }
> +
> + drm_plane_helper_add(lcrtc->plane, &loongson_plane_helper_funcs);
> +
> + return 0;
> +}
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
t; > >
> > > And now the drm-intel tree.
> > >
> > > I have used the drm-intel tree from next-20210108 for today.
> >
> > This is still affecting the drm and drm-intel trees.
>
> I think the fix for this is in drm-misc-next, Maarten can you send me
> a -next PR to fix this?
I've pulled drm-misc-next into drm-next now, so as long as all other
drm trees are merged after drm, this should be solved now.
drm-intel-next also has their msm build breakage fixed (I acked the
patch already), so hopefully we should be all clean again.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Jan 20, 2021 at 10:51 AM Yiwei Zhang wrote:
>
> On Wed, Jan 20, 2021 at 1:11 AM Daniel Vetter wrote:
> >
> > On Tue, Jan 19, 2021 at 11:08:12AM -0800, Yiwei Zhang wrote:
> > > On Mon, Jan 18, 2021 at 11:03 PM Daniel Vetter wrote:
> > > >
> &g
stinct mappings of each attachment is exposed in a
> > separate file.
> > 3) The per-buffer statistics are now in /sys/kernel/dmabuf/buffers
> > inorder to make the interface expandable in future.
> >
> > All of the improvements above are based on suggesti
if (ret) {
> - dev_err(dev, "Failed to init encoder: %d\n", ret);
> - return ret;
> - }
> -
> ret = drm_bridge_attach(encoder, bridge, NULL, 0);
> if (ret) {
> dev_err(dev, "Unable to attach bridge\n");
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
e =
> drm_bridge_to_panel_bridge(bridge);
> + struct drm_connector *connector = &panel_bridge->connector;
> +
> + /* Cleanup the connector if we know it was initialized */
> + if (!!panel_bridge->connector.dev)
> + drm_connector_cleanup(connec
t; Cc: # v5.8+
> Signed-off-by: Paul Cercueil
Does what it says on the tin^Wcommit message.
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/ingenic/
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, Jan 20, 2021 at 1:35 PM Paul Cercueil
> > wrote:
> >>
> >> If we don't call drm_connector_cleanup() manually in
On Wed, Jan 20, 2021 at 2:21 PM Paul Cercueil wrote:
>
>
>
> Le mer. 20 janv. 2021 à 14:01, Daniel Vetter a
> écrit :
> > On Wed, Jan 20, 2021 at 1:36 PM Paul Cercueil
> > wrote:
> >>
> >> Since the encoders have been devm-allocated, they will be f
t depend on any fb console symbols. At least
> +* attempt to load fbcon to avoid leaving the system without a usable
> +* console.
> +*/
> + if (IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION) &&
> + IS_MODULE(CONFIG_FRAMEBUFFER_CONSOLE) &&
> + !IS_ENABLED(CONFIG_EXPERT) &&
> + !module_loaded("fbcon"))
> + request_module_nowait("fbcon");
> +
> + return drm_dp_aux_dev_init();
> }
>
> static void __exit drm_kms_helper_exit(void)
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> I am still getting this warning.
> >
> > I now get this warning from the drm tree merge.
Drat, I missed that when merging.
> Bhawan sent out the fix today:
> https://patchwork.freedesktop.org/patch/415092/
Applied directly to drm-next, thanks.
-Daniel
>
> Alex
>
> >
> > --
> > Cheers,
> > Stephen Rothwell
> ___
> 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
callbacks
> -* there's no reason this is a core function.
> +* This hook is deprecated, drivers should instead use
> +* drm_fbdev_generic_setup() which takes care of any necessary
> +* hotplug event forwarding already without further involvement by
> +
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
_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
/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 {
> >
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
rce, it
> feels like an unnecessary rework for something that is slowly getting
> replaced by bridges.
>
> Since all the users that matter have been converted, let's remove the
> TODO item.
>
> Signed-off-by: Maxime Ripard
Acked-by: Daniel Vetter
>
> ---
>
>
On Thu, Jan 21, 2021 at 9:28 AM Christoph Hellwig wrote:
>
> On Thu, Jan 21, 2021 at 09:25:40AM +0100, Daniel Vetter wrote:
> > On Thu, Jan 21, 2021 at 8:55 AM Christoph Hellwig wrote:
> > >
> > > drm_fb_helper_modinit has a lot of boilerplate for what is not v
for DRM_I915_WERROR
> Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] &&
> !COMPILE_TEST [=y]
> Selected by [m]:
> - DRM_I915_DEBUG [=y] && HAS_IOMEM [=y] && EXPERT [=y] && DRM_I915 [=m]
>
> Maybe introduced
On Fri, Jan 22, 2021 at 8:29 AM Stephen Rothwell wrote:
>
> Hi Daniel,
>
> On Fri, 22 Jan 2021 08:17:58 +0100 Daniel Vetter wrote:
> >
> > Hm that has been in drm-intel-gt-next for a few days, is that tree not
> > in linux-next?
>
> It is not.
Adding -
u implement here,
to support the full use cases on Android's closed stacks. And it is uapi.
Tech debt isn't measured in lines of code, but in how expensive it's going
to be to fix up the mess in the future. uapi is expensive no matter how
few lines are used to implement it.
So yeah this needs to be properly thought out, properly implemented (not
just on the virtual demo stack but something that looks like actual
production stack), with open drivers, proper alignment with other efforts
like tracking memory with cgroups, and the interactions with dma-buf
tracking resolved, and igt testcases (this is meant to be generic after
all), and at least solid proposals for rolling this out across the drm
drivers, and ...
In other words, new uapi needs to be done right.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
h other pin leaks if you have them. Setting it
to 0 kinda defeats the warning.
-Daniel
>
> Not calling ttm_bo_unpin() makes ttm_bo_release() throw
> a WARN() because of the pin.
>
> Clearing pin_count (which is how ttm fixes things up
> in the error path) works.
>
> I'm open to better ideas.
>
> take care,
> Gerd
>
> ___
> 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; > 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
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
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
1101 - 1200 of 3914 matches
Mail list logo
