alloc a page with relevant gfp attributes, copy and
> add_to_swap_cache()? Or perhaps that doesn't work well from a shrinker
> either?
So before we toss everything and go an a great rewrite-the-world tour,
what if we just try to split up big objects. So for objects which are
On Wed, Mar 24, 2021 at 01:00:28PM +0100, Christian König wrote:
> Am 24.03.21 um 12:55 schrieb Daniel Vetter:
> > On Wed, Mar 24, 2021 at 11:19:13AM +0100, Thomas Hellström (Intel) wrote:
> > > On 3/23/21 4:45 PM, Christian König wrote:
> > > > Am 23.03.21
kernel is not doing this, the kernel is
objectively wrong. (And I know it doesn't do this in most cases, because
otherwise I wouldn't be able to use this GNOME session on an Intel laptop,
where modifiers are blacklisted.)
Cheers,
Daniel
___
dri
co.uk/
What's really worrying here is the silent (accidental maybe, commit
message doesn't explain anything) change to the argument of
set_to_gtt_domain(). I've decided to just go with what we have right now,
but please double-check this matches the old version you've had before
, runtime pm resume is on the critical path for dma-fence
(we might need to wake up the device for e.g. atomic modeset commits), so
definitely can't have a dma_resv_lock in here.
-Daniel
>
> Signed-off-by: Maarten Lankhorst
> Reviewed-by: Thomas Hellström
> ---
> drivers/gpu/d
uff that wasn't
reset yet, so I picked up the old version here:
https://lore.kernel.org/intel-gfx/20210128162612.927917-29-maarten.lankho...@linux.intel.com/
That one looks a lot more reasonable.
-Daniel
> ---
> drivers/gpu/drm/i915/gem/i915_gem_domain.c | 41 ++
l-gfx/20210128162612.927917-31-maarten.lankho...@linux.intel.com/
because too much conflicts with this version here.
-Daniel
> ---
> drivers/gpu/drm/i915/Makefile | 1 -
> drivers/gpu/drm/i915/gem/i915_gem_fence.c | 95 -
> drivers/gpu/drm/i915/gem/i915_ge
)?
>
That's correct. Not passing any modifiers is the same as explicitly passing
INVALID, both of which mean 'the driver will figure it out somehow'; that
driver-specific determination is not the same as explicit LINEAR.
(I cannot regret enough that INVA
rg/intel-gfx/20210128162612.927917-32-maarten.lankho...@linux.intel.com/
Cheers, Daniel
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.h| 3 +
> drivers/gpu/drm/i915/gem/i915_gem_pages.c | 12 +++
> .../gpu/drm/i915/gt/selftest_workarounds.c| 95 +--
> 3 f
n vm_access callback, generic_access_phys
should be used here instead.
I've applied this, but can you pls do a follow up patch here?
Thanks, Daniel
> ---
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 24 ++--
> 1 file changed, 22 insertions(+), 2 deletions(-)
>
&g
lore.kernel.org/intel-gfx/20210128162612.927917-45-maarten.lankho...@linux.intel.com/
There was some functional changes in the test, so I figured that's the
safer path.
-Daniel
> ---
> drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 10 +-
> 1 file changed,
global reset also thrashes mmaps, but it's a global
reset we're talking about here, everything is thrash anyway. Plus/minus
fenced gtt mmaps really doesn't change the tally.
The real solution is per-engine reset here, and making sure that works as
well as absolutely possible.
Maart
by: Maarten Lankhorst
This partially reverts
https://lore.kernel.org/intel-gfx/cam0jshohkzhivgi-x37w2rxyqhm1vbqb8uzavyexejuwe0l...@mail.gmail.com/
which I'm going to throw out anyway. So not merged this one here.
-Daniel
> ---
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 ++
On Tue, Mar 23, 2021 at 04:50:54PM +0100, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
Fixes a commit I'll drop anyway, so didn't bother with this one.
-Daniel
> ---
> drivers/gpu/drm/i915/selftests/i915_scheduler.c | 2 +-
> 1 file changed, 1 in
On Wed, Mar 24, 2021 at 07:15:36PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 24, 2021 at 06:00:12PM +0100, Daniel Vetter wrote:
> > On Tue, Mar 23, 2021 at 04:50:52PM +0100, Maarten Lankhorst wrote:
> > > We get a lockdep splat when the reset mutex is held, because it can b
l it a false positive, that's always a
bit a bold statement for lockdep splats which needs extroadinary evidence.
So maybe drop that part.
Also maybe good to reference the commit which added async ggtt pte writes
for reference here.
With those things on the commit message addressed:
Acked-by:
bsw fix, but the others are for lmem enabling, so imo can
go in through the usual way.
-Daniel
> ---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 3 ++-
> drivers/gpu/drm/i915/gem/i915_gem_internal.c | 3 ++-
> drivers/gpu/drm/i915/gem/i915_gem_object_types.h |
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
On Wed, Mar 24, 2021 at 01:07:44PM +0100, Christian König wrote:
>
>
> Am 24.03.21 um 13:01 schrieb Daniel Vetter:
> > On Wed, Mar 24, 2021 at 01:00:28PM +0100, Christian König wrote:
> > > Am 24.03.21 um 12:55 schrieb Daniel Vetter:
> > > > On Wed, Mar
t; +static unsigned long ttm_dma32_pages_limit;
> +
> +MODULE_PARM_DESC(dma32_pages_limit, "Limit for the allocated DMA32 pages");
> +module_param_named(dma32_pages_limit, ttm_dma32_pages_limit, ulong, 0644);
> +
> +static atomic_long_t ttm_pages_allocated;
> +s
w it's
just the TODO file
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Jason Ekstrand
Cc: Dave Airlie
Acked-by: Dave Airlie
Acked-by: Rodrigo Vivi
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/TODO.txt | 41 +++
1 file changed, 41 insert
Airlie
Acked-by: Rodrigo Vivi
Acked-by: Dave Airlie
Signed-off-by: Daniel Vetter
---
Documentation/gpu/index.rst | 1 +
Documentation/gpu/rfc.rst | 17 +
2 files changed, 18 insertions(+)
create mode 100644 Documentation/gpu/rfc.rst
diff --git a/Documentation/gpu/index.rst b
On Thu, Mar 25, 2021 at 9:07 AM Christian König
wrote:
>
> Am 24.03.21 um 20:29 schrieb Daniel Vetter:
> > On Wed, Mar 24, 2021 at 02:48:45PM +0100, Christian König wrote:
> >> The shrinker based approach still has some flaws. Especially that we need
> >> tempor
-i-apply-my-patch
We need to hard-reset drm-misc-next-fixes back, please re-apply the
patches (both of them) to drm-misc-fixes. Also adding drm-misc
maintainers.
-Daniel
>
> Thank you,
>
> Oleksandr
>
> > ---
> > drivers/gpu/drm/xen/xen_drm_front_conn.h |
'll fix for tomorrow.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
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
On Thu, Mar 25, 2021 at 10:27 AM Christian König
wrote:
>
> Am 25.03.21 um 09:31 schrieb Daniel Vetter:
> > On Thu, Mar 25, 2021 at 9:07 AM Christian König
> > wrote:
> >> Am 24.03.21 um 20:29 schrieb Daniel Vetter:
> >>> On Wed, Mar 24, 2021 at
size is *not* necessarily aligned to the CPU page table sizes and DAX
> > would benefit from better handling of this mismatch.
> >
> >> On top of this, unless we want to do the walk trying increasingly smaller
> >> sizes of vmf_insert_xxx(), we'd have to use
On Thu, Mar 25, 2021 at 10:48 AM Tvrtko Ursulin
wrote:
>
>
> On 24/03/2021 17:18, Jason Ekstrand wrote:
> > On Wed, Mar 24, 2021 at 6:36 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 24/03/2021 09:52, Daniel Vetter wrote:
> >>> On
arily) required.
> > Changes since v6:
> > - Ensure userptr validity is checked in set_domain through a special path.
> > Changes since v7:
> > - Chane kvfree to kvfree().
>
> v8: Change "Chane kvfree to kvfree()" to "Change kfree() to kvfree()" ?
propval << RT4831_BLOVP_SHIFT);
> + if (ret)
> + return ret;
> +
> + ret = device_property_read_u8(dev, "richtek,channel-use", &propval);
> + if (ret) {
> + dev_err(dev, "richtek,channel-use DT property missing\n&q
On Thu, Mar 25, 2021 at 04:22:11PM +0800, ChiYuan Huang wrote:
> Dear reviewers:
>
>Didn't get any response about this backlight patch.
> Is there any part need to be refined?
Thanks for the reminders and sorry for the delay. Have just replied
to the original
ries.
On the series: Acked-by: Daniel Vetter
> ---
> tests/meson.build | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/tests/meson.build b/tests/meson.build
> index 54a1a3c7..8e3cd390 100644
> --- a/tests/meson.build
> +++ b/tests/meson.build
>
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
) contained somewhere separate (Jason)
Cc: Simon Ser
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Jason Ekstrand
Cc: Dave Airlie
Acked-by: Jason Ekstrand
Acked-by: Simon Ser
Acked-by: Rodrigo Vivi
Acked-by: Dave Airlie
Signed-off-by: Daniel Vetter
---
Documentation/gpu/index.rst
d i915_request_cancel().
>
> Associated timeout value is stored in rq->context.watchdog.timeout_us.
>
> v2:
> * Log expiration.
>
> v3:
> * Include more information about user timeline in the log message.
>
> v4:
> * Remove obsolete comment and fix formatting
faced with a chain of requests which have
> > all been marked as in error.
> >
> > Because in cases where we end up with a stream of cancelled requests we
> > want to turn of request coalescing so they each will get individually
>
> turn off
Fixed while applying.
-Da
t; Signed-off-by: Tvrtko Ursulin
> Cc: Daniel Vetter
> Acked-by: Daniel Vetter
Entire series merged, thanks for the patches.
-Daniel
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +++--
> drivers/gpu/drm/i915/i915_params.c | 5 +
> drivers/gpu/drm/i915/i915_
On Thu, Mar 25, 2021 at 11:58:59PM +0100, Daniel Vetter wrote:
> Motivated by the pre-review process for i915 gem/gt features, but
> probably useful in general for complex stuff.
>
> v2: Add reminder to not forget userspace projects in the discussion
> (Simon, Jason)
>
>
rom
> the kernel side either. (Although disclaimer my memory may be leaky - Daniel
> suspects old hangcheck had some stricter, more indiscriminatory, angles to it.
> But apart from being prone to both false negatives and false positives I can't
> remember that myself.)
>
> Sh
x27;s a huge thing, tons of work, but finally
we have it merged.
Cheers, Daniel
The following changes since commit 06debd6e1b28029e6e77c41e59a162868f377897:
Merge tag 'drm-intel-next-2021-03-16' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2021-03-18 08:06:34
+1000)
On Fri, Mar 26, 2021 at 2:31 PM Jani Nikula wrote:
>
> On Fri, 26 Mar 2021, Daniel Vetter wrote:
> > The rough plan we discussed somewhat ad-hoc with Jani&Rodrigo (Joonas was
> > out this week, but back next) is that they send out a pull with what's
> > the
On Thu, Feb 18, 2021 at 11:15 PM Alex Deucher wrote:
>
> Hi Dave, Daniel,
>
> Fixes for 5.12.
>
> The following changes since commit 4c3a3292730c56591472717d8c5c0faf74f6c6bb:
>
> drm/amd/display: fix unused variable warning (2021-02-05 09:49:44 +1000)
>
> are avai
This is v3 of the series.
Changelog:
v2 -> v3:
* Turn Documentation into yaml format
v3 -> v4:
* Fix reference error in yaml file
v4 -> v5:
* More yaml file documentation fixes
Daniel Mack (2):
dt-bindings: display: add bindings for newhaven,1.8-128160EF
This patch adds support for Newhaven's NHD-1.8-128160EF display, featuring
an Ilitek ILI9163 controller.
Signed-off-by: Daniel Mack
Acked-by: Daniel Vetter
---
drivers/gpu/drm/tiny/Kconfig | 13 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ili9163.c
This adds documentation for a new ILI9163 based, SPI connected display.
Signed-off-by: Daniel Mack
---
.../display/panel/ilitek,ili9163.yaml | 69 +++
1 file changed, 69 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/ilitek,ili9163
It's common used to drive the display WLED. There're four channels
Nitpicking but I was expecting the original typo be converted to
"commonly".
With that addressed:
Reviewed-by: Daniel Thompson
Daniel.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Sun, Mar 28, 2021 at 11:24:17PM +0800, cy_huang wrote:
> From: ChiYuan Huang
>
> Adds DT binding document for Richtek RT4831 backlight.
>
> Signed-off-by: ChiYuan Huang
Reviewed-by: Daniel Thompson
___
dri-devel mailing
This adds documentation for a new ILI9163 based, SPI connected display.
Signed-off-by: Daniel Mack
---
.../display/panel/ilitek,ili9163.yaml | 69 +++
1 file changed, 69 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/ilitek,ili9163
This patch adds support for Newhaven's NHD-1.8-128160EF display, featuring
an Ilitek ILI9163 controller.
Signed-off-by: Daniel Mack
Acked-by: Daniel Vetter
---
drivers/gpu/drm/tiny/Kconfig | 13 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ili9163.c
This is v3 of the series.
Changelog:
v2 -> v3:
* Turn Documentation into yaml format
v3 -> v4:
* Fix reference error in yaml file
v4 -> v5:
* More yaml file documentation fixes
v5 -> v6:
* More yaml file documentation fixes
Daniel Mack (2):
This adds documentation for a new ILI9163 based, SPI connected display.
Signed-off-by: Daniel Mack
---
.../display/panel/ilitek,ili9163.yaml | 69 +++
1 file changed, 69 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/ilitek,ili9163
This patch adds support for Newhaven's NHD-1.8-128160EF display, featuring
an Ilitek ILI9163 controller.
Signed-off-by: Daniel Mack
Acked-by: Daniel Vetter
---
drivers/gpu/drm/tiny/Kconfig | 13 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ili9163.c
This adds documentation for a new ILI9163 based, SPI connected display.
Signed-off-by: Daniel Mack
---
.../display/panel/ilitek,ili9163.yaml | 69 +++
1 file changed, 69 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/ilitek,ili9163
Fix ordering of patches
Daniel Mack (2):
dt-bindings: display: add bindings for newhaven,1.8-128160EF
drm/tiny: add driver for newhaven,1.8-128160EF
.../display/panel/ilitek,ili9163.yaml | 69 +++
drivers/gpu/drm/tiny/Kconfig | 13 +
drivers/gpu/dr
This patch adds support for Newhaven's NHD-1.8-128160EF display, featuring
an Ilitek ILI9163 controller.
Signed-off-by: Daniel Mack
Acked-by: Daniel Vetter
---
drivers/gpu/drm/tiny/Kconfig | 13 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ili9163.c
Fix ordering of patches
v7 -> v8:
* More yaml file documentation fixes
Daniel Mack (2):
dt-bindings: display: add bindings for newhaven,1.8-128160EF
drm/tiny: add driver for newhaven,1.8-128160EF
.../display/panel/ilitek,ili9163.yaml | 69 +++
drivers/gp
This patch adds support for Newhaven's NHD-1.8-128160EF display, featuring
an Ilitek ILI9163 controller.
Signed-off-by: Daniel Mack
Acked-by: Daniel Vetter
---
drivers/gpu/drm/tiny/Kconfig | 13 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ili9163.c
This adds documentation for a new ILI9163 based, SPI connected display.
Signed-off-by: Daniel Mack
---
.../display/panel/ilitek,ili9163.yaml | 69 +++
1 file changed, 69 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/ilitek,ili9163
backlight_class->dev_groups = bl_device_groups;
> backlight_class->pm = &backlight_class_dev_pm_ops;
> INIT_LIST_HEAD(&backlight_dev_list);
> - mutex_init(&backlight_dev_list_mutex);
> BLOCKING_INIT_NOTIFIER_HEAD(&backlight_notifier);
On Mon, 4 Jan 2021
On Wed, Jan 13, 2021 at 10:08 PM Chris Wilson wrote:
> Quoting Daniel Vetter (2021-01-13 20:50:11)
> > On Wed, Jan 13, 2021 at 4:43 PM Chris Wilson
> > wrote:
> > >
> > > Quoting Daniel Vetter (2021-01-13 14:06:04)
> > > > We have too many peopl
maybe because of this: [2]?
>
> BR,
> Jani.
>
>
> [1] https://cgit.freedesktop.org/drm/drm-misc
> [2] http://lore.kernel.org/r/20210114113107.62210...@canb.auug.org.au
Patch for that just got committted, so this shouldn't be too big a
window for drm-misc-next to be ex
On Thu, Jan 14, 2021 at 4:27 AM Jerome Glisse wrote:
>
> On Wed, Jan 13, 2021 at 09:31:11PM +0100, Daniel Vetter wrote:
> > On Wed, Jan 13, 2021 at 5:56 PM Jerome Glisse wrote:
> > > On Fri, Jan 08, 2021 at 03:40:07PM +0100, Daniel Vetter wrote:
> > > > On Thu,
On Thu, Jan 14, 2021 at 10:23 AM Chris Wilson wrote:
>
> Quoting Daniel Vetter (2021-01-14 09:02:57)
> > On Wed, Jan 13, 2021 at 10:08 PM Chris Wilson
> > wrote:
> > > Quoting Daniel Vetter (2021-01-13 20:50:11)
> > > > On Wed, Jan 13, 2021
initializer
> macro.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/vc4/vc4_bo.c | 14 --
> drivers/gpu/drm/vc4/vc4_drv.c | 7 +--
> drivers/gpu/drm/vc4/vc4_drv.h | 3 ---
> 3 files changed, 1 insertion(+), 23 del
On Thu, Jan 14, 2021 at 09:45:37AM +, Chris Wilson wrote:
> Quoting Daniel Vetter (2021-01-14 09:30:32)
> > On Thu, Jan 14, 2021 at 10:23 AM Chris Wilson
> > wrote:
> > > The only other problem I see with the implementation is that there's
> > > n
On Thu, Jan 14, 2021 at 10:11:01AM +0100, Daniel Vetter wrote:
> On Thu, Jan 14, 2021 at 10:04 AM Jani Nikula
> wrote:
> >
> > On Wed, 13 Jan 2021, Lee Jones wrote:
> > > On Wed, 13 Jan 2021, Sam Ravnborg wrote:
> > >
> > >> Hi Lee,
> > &
On Thu, Jan 14, 2021 at 10:26 AM Daniel Vetter wrote:
>
> On Thu, Jan 14, 2021 at 4:27 AM Jerome Glisse wrote:
> >
> > On Wed, Jan 13, 2021 at 09:31:11PM +0100, Daniel Vetter wrote:
> > > On Wed, Jan 13, 2021 at 5:56 PM Jerome Glisse wrote:
> > > > O
On Thu, Jan 14, 2021 at 11:49 AM Christian König
wrote:
>
> Am 13.01.21 um 17:56 schrieb Jerome Glisse:
> > On Fri, Jan 08, 2021 at 03:40:07PM +0100, Daniel Vetter wrote:
> >> On Thu, Jan 07, 2021 at 11:25:41AM -0500, Felix Kuehling wrote:
> >>> Am 2021-01-07 u
On Thu, Jan 14, 2021 at 2:37 PM Christian König
wrote:
>
> Am 14.01.21 um 12:52 schrieb Daniel Vetter:
> > [SNIP]
> >>> I had a new idea, i wanted to think more about it but have not yet,
> >>> anyway here it is. Adding a new callback to dma fence which ask
cma helpers) about leaking mmaps, which keeps too many fb
alive, so maybe we have gained a refcount leak somewhere recently. But
could also be totally unrelated.
-Daniel
>
> Christian.
>
> >
> > [1] https://pastebin.com/n0FE7Hsu
> > [2] https://pastebin.com
On Thu, Jan 14, 2021 at 3:13 PM Christian König
wrote:
>
> Am 14.01.21 um 14:57 schrieb Daniel Vetter:
> > On Thu, Jan 14, 2021 at 2:37 PM Christian König
> > wrote:
> >> Am 14.01.21 um 12:52 schrieb Daniel Vetter:
> >>> [SNIP]
> >>>>> I
On Thu, Jan 14, 2021 at 07:52:45PM +0530, Sumera Priyadarsini wrote:
> Fix typo in intro chapter in drm_vblank.c.
> Change 'sacn' to 'scan'.
>
> Signed-off-by: Sumera Priyadarsini
Nice catch, applied.
-Daniel
> ---
> drivers/gpu/drm/drm_vblank.c | 2 +
On Thu, Jan 14, 2021 at 4:08 PM Christian König
wrote:
> Am 14.01.21 um 15:23 schrieb Daniel Vetter:
> > On Thu, Jan 14, 2021 at 3:13 PM Christian König
> > wrote:
> >> Am 14.01.21 um 14:57 schrieb Daniel Vetter:
> >>> On Thu, Jan 14, 2021 at 2:37 PM Chr
On Thu, Jan 14, 2021 at 4:56 PM Geert Uytterhoeven wrote:
>
> Hi Daniel,
>
> CC linux-fbdev
>
> On Tue, Jan 12, 2021 at 5:00 PM Daniel Vetter wrote:
> > On Sat, Jan 9, 2021 at 12:11 AM Linus Torvalds
> > wrote:
> > > On Fri, Jan 8, 2021 at 11:13 AM Philli
On Thu, Jan 14, 2021 at 5:01 PM Christian König
wrote:
>
> Am 14.01.21 um 16:40 schrieb Daniel Vetter:
> > [SNIP]
> >> So I think we have to somehow solve this in the kernel or we will go in
> >> circles all the time.
> >>
> >>> So from that
;vm_ops;
I think this should be done in core, otherwise we have tons of refcount
leaks. I think this was an oversight when we've done that refactoring.
Also drivers can easily overwrite this one if they really have to, but not
assigned this is a clear bug.
-Daniel
> +
>
On Thu, Jan 14, 2021 at 08:08:06PM +0100, Christian König wrote:
> Am 14.01.21 um 17:36 schrieb Daniel Vetter:
> > On Thu, Jan 14, 2021 at 5:01 PM Christian König
> > wrote:
> > > Am 14.01.21 um 16:40 schrieb Daniel Vetter:
> > > > [SNIP]
> > > > &
chances for an invalid
dereference.
v2: Add a note to the @map_dma_buf hook that exporters shouldn't do
fancy caching tricks, which would blow up with this address scrambling
trick here (Chris)
Enable by default when CONFIG_DMA_API_DEBUG is enabled.
Reviewed-by: Chris Wilson
Signed-off-by: Dani
On Fri, Jan 15, 2021 at 2:09 PM Christian König
wrote:
>
> Am 15.01.21 um 14:02 schrieb Daniel Vetter:
> > have too many people abusing the struct page they can get at but
> > really shouldn't in importers. Aside from that the backing page might
> > simply not ex
On Fri, Jan 15, 2021 at 12:06 PM Simon Ser wrote:
>
> On Tuesday, December 22nd, 2020 at 2:59 PM, Daniel Vetter
> wrote:
>
> > > + * type:
> > > + * Immutable property describing the type of the plane.
> > > + *
> > &
lly this should also go boom when you do it in places like
serving (hmm) page faults, which I think we want. Just locking
dma_resv_lock wont go boom like that (since taking the dma_resv_lock from
a page fault handler is explicitly allowed, it nests within mmap_lock).
Conceptually I think it
* drm_fbdev_generic_setup() which takes care of any necessary
* hotplug event forwarding already without further involvement by
* the driver.
Can you pls respin, with the function change dropped and the fixme
replaced with the above?
Thanks, Daniel
> - *
> -
as GEM CMA object
> > functions")
> > Reported-by: Kieran Bingham
> > Tested-by: Kieran Bingham
>
> Re-tested just fine this side ;-)
> - https://paste.ubuntu.com/p/Jgz6xMKNJX/
Reviewed-by: Daniel Vetter
>
> Thanks
>
> Kieran
>
&g
Christian)
Reviewed-by: Chris Wilson (v2)
Signed-off-by: Daniel Vetter
Cc: Chris Wilson
Cc: Sumit Semwal
Cc: "Christian König"
Cc: David Stevens
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/Kconfig | 8 +++
code (Christian)
v4: #ifdef, not #if (0day)
Reviewed-by: Chris Wilson (v2)
Signed-off-by: Daniel Vetter
Cc: Chris Wilson
Cc: Sumit Semwal
Cc: "Christian König"
Cc: David Stevens
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/Kconfig | 8
code (Christian)
v4: #ifdef, not #if (0day)
v5: sg_table can also be an ERR_PTR (Chris, Christian)
Reviewed-by: Chris Wilson (v2)
Signed-off-by: Daniel Vetter
Cc: Chris Wilson
Cc: Sumit Semwal
Cc: "Christian König"
Cc: David Stevens
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lis
n with the helpers. Drivers use
> > + * drm_kms_helper_hotplug_event() to call this hook to inform the
> > fbdev
>
> I don't understand this. Maybe it's "Drivers implementing fbdev
> emulation use drm_kms_helper_hotplug_event() to call ..." ?
Yeah this just do
On Sun, Jan 17, 2021 at 03:29:05AM -0800, syzbot wrote:
> syzbot has bisected this issue to:
>
> commit ea40d7857d5250e5400f38c69ef9e17321e9c4a2
> Author: Daniel Vetter
> Date: Fri Oct 9 23:21:56 2020 +
>
> drm/vkms: fbdev emulation support
Not sure you want
ed.
> >
> > Signed-off-by: Simon Ser
> > Reviewed-by: Daniel Vetter
> > Cc: Pekka Paalanen
> > ---
> > include/drm/drm_plane.h | 21 +
> > 1 file changed, 13 insertions(+), 8 deletions(-)
> >
> > diff --git a/include/dr
o drm-misc-next, but some patch
monkey help would be really great :-)
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, Jan 18, 2021 at 01:03:55AM +, Yue Zou wrote:
> Remove superfluous semicolons after function definitions.
>
> Signed-off-by: Yue Zou
Thanks for your patch, applied.
-Daniel
> ---
> include/linux/vgaarb.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(
you want this in -fixes, then I think hand-roll it. But devm_ for drm
objects really is the wrong fix.
-Daniel
>
> -Paul
>
> > > Fixes: c369cb27c267 ("drm/ingenic: Support multiple panels/bridges")
> > > Cc: # 5.8+
> > > Signed-off-by: Paul Cercuei
> For the series: Reviewed-by: Roland Scheidegger
Series merged, thanks for taking a look.
-Daniel
>
> Roland
>
> Am 12.01.21 um 09:49 schrieb Daniel Vetter:
> > Hi Roland,
> >
> > Hopefully you had a nice start into the new year! Ping for some
> &g
On Fri, Jan 15, 2021 at 07:52:53PM +0100, Christian König wrote:
> Am 15.01.21 um 17:47 schrieb Daniel Vetter:
> > We have too many people abusing the struct page they can get at but
> > really shouldn't in importers. Aside from that the backing page might
> > simply
patch
>
> Signed-off-by: Thomas Zimmermann
> Tested-by: Andy Lavr
> Acked-by: Sam Ravnborg
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_agpsupport.c | 9 ++---
> drivers/gpu/drm/drm_bufs.c | 4 ++--
> drivers/gpu/drm/drm_edid.c
> > niggly little warnings.
> >
> > Penultimate set, promise. :)
>
>
> Thank you for all that work. For all the vmwgfx bits:
> Reviewed-by: Zack Rusin
I pulled all the non-vmxgfx patches to drm-misc-next, I'll leave the vmw
stuff to Zack.
Thanks for your work here!
-Dani
pls holler if they're stuck).
Note that we have some build issue on some of the configs sfr uses, so drm
trees are still stuck on old versions in linux-next. Hopefully should get
resolved soon, the bugfix is in some subtree I've heard.
-Daniel
--
Da
xa9
> >
> > Any idea what's going wrong here?
>
> I meanwhile posted an updated patchset with a fix in patch 1. [1] Maybe
> you can apply this one and test.
>
> The original bug report and testing is at [2]. Apparently, DRM core has
> to be changed together with
On Mon, Jan 18, 2021 at 03:09:45PM +, Lee Jones wrote:
> On Mon, 18 Jan 2021, Daniel Vetter wrote:
>
> > On Fri, Jan 15, 2021 at 06:27:15PM +, Zack Rusin wrote:
> > >
> > > > On Jan 15, 2021, at 13:15, Lee Jones wrote:
> > > >
> > &g
901 - 1000 of 26155 matches
Mail list logo