> > + clip->x2 = clip->y2 = 0;
> > > + }
> > > spin_unlock_irqrestore(&helper->dirty_lock, flags);
> > >
> > > - helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip_copy, 1);
> > > + if (dirty)
> >
> > Could do it the other way too, ie. just make the copy, and then check the
> > copy (can be done after dropping the lock even). Would avoid having to
> > add the 'dirty' variable.
>
> Sounds good. Let me try...
Another thing: How do we prevent userspace from doing the same, i.e.
submitting an empty rectangle? Do we need to patch up
drm_mode_dirtyfb_ioctl too? Not much point if we fix this bug in the fb
helpers and leave the barn door wide open for userspace to oops drivers
;-)
-Daniel
>
>
> Takashi
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ated to a fence (that may be a fence_collection
> subclass or just a normal fence) and then used by DRM to fence_wait() for
> all fences in the sync_file to signal. So it only commits when all
> framebuffers are ready to scanout.
>
> v2: Comments by Daniel Vetter:
> - remove s
On Thu, Oct 20, 2016 at 12:50:03PM -0200, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> If the event gets canceled we also need to put away the fence
> reference it holds.
>
> Signed-off-by: Gustavo Padovan
Reviewed-by: Daniel Vetter
I've broken my local dim scri
_context;
> + spinlock_t fence_lock;
> + unsigned long fence_seqno;
> + char timeline_name[32];
> };
>
> +extern const struct fence_ops drm_crtc_fence_ops;
> +
> +static inline struct drm_crtc *fence_to_crtc(struct fence *fence)
> +{
> + BUG_ON(fence->ops != &drm_crtc_fence_ops);
> + return container_of(fence->lock, struct drm_crtc, fence_lock);
> +}
> +
> /**
> * struct drm_mode_set - new values for a CRTC config change
> * @fb: framebuffer to use for new config
> --
> 2.5.5
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> -> fence A signals, fb 0,1 can be reused
> fb 3 and 5 being scanned out now
>
>
> We also had a quick side track w.r.t. variable refresh rate displays,
> and I think the conclusion was that there the vblank may just happen
> sooner or later. Nothing else should change. What's unclear is how
> the refresh rate would be controlled. The two obvious options are
> explicit control, and automagic based on the submit rate. But that's
> a separate topic entirely.
Thanks a lot for doing this discussion and the detailed write-up. Imo we
should bake this into the kerneldoc, as uabi documentation examples.
Gustavo, can you pls include this? I'd put it into the kerneldoc for
@out_fence, with inline struct comments we can be rather excessive in
their lenght ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
:-)
+1 on moving this out of drm_crtc_state. drm_atomic_state already has
per-crtc structs, so easy to extend them with this. And yes drivers can
still see it, but mostly they're not supposed to touch drm_atomic_state
internals - the book-keeping is all done by the core.
The per-object state structs otoh are meant to be massively mangled by
drivers.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ercise the even later error code.
Other things are mixing up in_fences, out_fences and events in different
ways, and making sure it all works out. And then maybe also mix in
nonblocking commit vs. blocking commit.
If you need something to generate fences: vgem has them. Chris Wilson can
point you at the code he's done in igt for testing the implicit fence
support in i915.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Oct 21, 2016 at 01:57:28PM +0100, Chris Wilson wrote:
> On Fri, Oct 21, 2016 at 02:30:32PM +0200, Daniel Vetter wrote:
> > On Thu, Oct 20, 2016 at 05:00:35PM +0200, Takashi Iwai wrote:
> > > On Thu, 20 Oct 2016 16:56:04 +0200,
> > > Ville Syrjälä wrote:
>
On Fri, Oct 21, 2016 at 09:02:27PM +0100, Chris Wilson wrote:
> On Fri, Oct 21, 2016 at 08:19:03PM +0200, Daniel Vetter wrote:
> > On Fri, Oct 21, 2016 at 01:57:28PM +0100, Chris Wilson wrote:
> > > I think of a use for sending an empty clip: where you don't want to
> &
fo on
> filing bugs, or a mailto: URI.
>
> Cc: Daniel Vetter
> Cc: Joe Perches
> Cc: Andrew Morton
> Signed-off-by: Jani Nikula
>
> ---
>
> Dust settled since the last time, maybe we can make URI work?
fwiw I want this, I think documenting bugzilla and irc chan
gvt: vGPU PCI configuration space virtualization
>
> Authors/maintainers added to Cc/To list. Guessing folks weren't
> aware of the regression.
The fix is in-flight. Thanks anyway for the report.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ns(+), 199 deletions(-)
>
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Oct 26, 2016 at 04:07:25PM -0400, Tejun Heo wrote:
> Hello, Daniel.
>
> On Wed, Oct 26, 2016 at 09:25:25PM +0200, Daniel Vetter wrote:
> > > > + * Note that callers must ensure that concurrent access to @ida is not
> > > > possible.
> > > >
Vlastimil Babka
Cc: Tejun Heo
Cc: Andrew Morton
Signed-off-by: Daniel Vetter
---
lib/idr.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/lib/idr.c b/lib/idr.c
index 6098336df267..52d2979a05e8 100644
--- a/lib/idr.c
+++ b/lib/idr.c
@@ -927,6 +927,9 @@ EXPORT_SYMBOL(ida_pre_get
nnector_state *state);
> >
> > I'll have to think about how to achieve that. The state isn't
> > refcounted and the driver isn't in charge of it's lifetime. I'm not
> > sure how/where to ensure the state doesn't get destroyed before its
>
igned-off-by: Gustavo Padovan
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic.c | 30 ++
> include/drm/drm_atomic.h | 2 ++
> include/drm/drm_plane.h | 2 +-
> 3 files changed, 33 insertions(+), 1 deletion(-)
>
> diff --gi
On Fri, Oct 28, 2016 at 09:30:26AM +0200, Daniel Vetter wrote:
> On Thu, Oct 27, 2016 at 05:37:06PM -0200, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > This new function should be used by drivers when setting a implicit
> > fence for the plane. It abstr
On Thu, Oct 27, 2016 at 05:37:08PM -0200, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> drm_atomic_set_fence_for_plane() is smart and won't overwrite
> plane_state->fence if the user already set an explicit fence there.
>
> Signed-off-by: Gustavo Padovan
nit: Please make sure you Cc: driver maintainers for driver
patches. Best done by putting the Cc: into the patch, then you never
forget ;-)
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/imx/imx-drm-core.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
>
ated to a fence (that may be a fence_collection
> subclass or just a normal fence) and then used by DRM to fence_wait() for
> all fences in the sync_file to signal. So it only commits when all
> framebuffers are ready to scanout.
>
> v2: Comments by Daniel Vetter:
> - remove s
crtc timeline name
>
> v4: Comments by Brian Starkey
> - Use even more meaninful name for the crtc timeline
> - add doc for timeline_name
> Comment by Daniel Vetter
> - use in-line style for comments
>
> - rebase after fence -> dma_fence re
E flag here.
>
> Comment by Daniel Vetter:
> - Add clean up code for out_fences
>
> v3: Comments by Daniel Vetter:
> - create DRM_MODE_ATOMIC_EVENT_MASK
> - userspace should fill out_fences_ptr with the crtc_ids for which
> it wants fences back.
&
On Thu, Nov 10, 2016 at 03:56:30PM +0100, Maxime Ripard wrote:
> Hi Daniel,
>
> On Tue, Nov 08, 2016 at 09:59:27AM +0100, Daniel Vetter wrote:
> > On Tue, Oct 18, 2016 at 10:29:38AM +0200, Maxime Ripard wrote:
> > > Create overscan profiles reducing the displayed zone.
On Wed, Nov 09, 2016 at 04:59:31PM +, Eric Engestrom wrote:
> On Wednesday, 2016-11-09 14:13:40 +0100, Daniel Vetter wrote:
> > On Wed, Nov 9, 2016 at 12:42 PM, Eric Engestrom
> > wrote:
> > >> Well, had to drop it again since it didn't compile:
> > >
; implementation this will break, take it out.
>> >
>> > Cc: Daniel Vetter
>> > Cc: Chris Wilson
>> > Cc: Rob Clark
>> > Signed-off-by: Peter Zijlstra (Intel)
>> > ---
>> > drivers/gpu/drm/i915/i915_gem_shr
f Gustavo's earlier
patches look really funny. I guess it could be split up again, but with
both callers in the current position. tbh I don't care whether it's this
or that, both are clear improvement over the older version.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
id sun6i_drc_unbind(struct device *dev, struct
> device *master,
> reset_control_assert(drc->reset);
> }
>
> -static struct component_ops sun6i_drc_ops = {
> +static const struct component_ops sun6i_drc_ops = {
> .bind = sun6i_drc_bind,
> .unbind = sun6i_drc_unbind,
> };
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
elease_fbi(helper);
> err_free_vram:
> - vfree(afbdev->sysram);
> + vfree(sysram);
> return ret;
> }
>
> --
> Andrew Donnellan OzLabs, ADL Canberra
> andrew.donnel...@au1.ibm.com IBM Australia Limited
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
vers.
Nack.
-Daniel
>
> return 0;
> done:
> --
> 2.10.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
nging that function
> > to return a zero timestamp when it fails.
> >
> > Fixes: e6ae8687a87b ("drm: idiot-proof vblank")
> > Reviewed-by: David Herrmann
> > Cc: Rob Clark
> > Cc: Daniel Vetter
> > Signed-off-by: Arnd Bergmann
> > ---
> > Fi
This changes the function back to only drop the reference count
> > when it was successfully allocated first.
> >
> > Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
> > Cc: Chris Wilson
> > Cc: Daniel Vetter
> > Signed-off-by: A
3_CORE
> tristate "IPUv3 core support"
> depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM
> - depends on RESET_CONTROLLER
> select GENERIC_IRQ_CHIP
> help
> Choose this if you have a i.MX5/6 system and want to use the Image
> --
> 2.10.0.297.gf6727b0
>
> ___
> 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 Tue, Oct 18, 2016 at 10:42:46AM -0700, Stefan Agner wrote:
> On 2016-10-18 00:44, Daniel Vetter wrote:
> > On Mon, Oct 17, 2016 at 02:33:21PM -0700, Stefan Agner wrote:
> >> There is no need to request a CMA backed framebuffer if fbdev
> >> emulation is not enabl
bdev_cma->fb_helper.fbdev);
> + if (fbdev_cma->fb_helper.fbdev)
> + drm_fbdev_cma_defio_fini(fbdev_cma->fb_helper.fbdev);
> drm_fb_helper_release_fbi(&fbdev_cma->fb_helper);
>
> if (fbdev_cma->fb) {
> --
> 2.10.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
(u32, clip->y2, y + height);
> > > - spin_unlock_irqrestore(&helper->dirty_lock, flags);
> > > -
> > > schedule_work(&helper->dirty_work);
> > > + spin_unlock_irqrestore(&helper->dirty_lock, flags);
> > > }
> > >
> > > /**
> > > --
> > > 2.10.1
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-de...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Ville Syrjälä
> > Intel OTC
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
its being fixed are in drm-misc, so this needs to go in through
> drm-misc as well. Daniel?
Because embarrassing build fail I already applied v1. I need a new,
real patch, no rebasing on -misc, patch to change the choice of color
...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
mesh well with
Tomeu's patches (and Tomeu's patches have been thrown out meanwhile
because of that). Still would be neat if tegra could be demidlayered
and loose it's load/unload hooks. See the kerneldoc in drm_drv.c
(especially the DOC: section).
-Daniel
--
Daniel Vetter
Software Engin
st extracting dma-buf stuff (dma_buf, fence, reservation and all
that) is ok though, it is a fairly stand-alone topic.
-Daniel
>
> > Does that make sense?
> >
> I do hope that my proposal above finds some merit with everyone.
>
> > Thanks,
> >
> > jon
>
> BR,
> Sumit.
> ___
> 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
a4 ("fence: dma-buf cross-device synchronization (v18)")
>
> Signed-off-by: Sumit Semwal
On patches 1&2 Reviewed-by: Daniel Vetter
> ---
> include/linux/fence.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/fence.
4.255291] lock(&dev->mode_config.mutex);
> [4.255291]
> *** DEADLOCK ***
>
> And i915 related kconfigs are here:
>
> CONFIG_DRM_I915=m
> CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT=y
> CONFIG_DRM_I915_USERPTR=y
> CONFIG_DRM_I915_GVT=y
> # C
nnel failed err %x\n", ret);
> +
> drm_connector_register(connector);
> drm_mode_connector_attach_encoder(connector, encoder);
>
> --
> 2.8.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
> + drm_fb_helper_restore_fbdev_mode_unlocked(&fbdev->fb_helper);
> +
> + if (fbdev->fb_helper.fbdev->state != FBINFO_STATE_RUNNING)
> + sdrm_fbdev_set_suspend(fbdev->fb_helper.fbdev, 0);
> +}
> diff --git a/drivers/gpu/drm/simpledrm/simpledrm_kms.c
> b/drivers/gpu/drm/simpledrm/simpledrm_kms.c
> index 00e50d9..92ddc116 100644
> --- a/drivers/gpu/drm/simpledrm/simpledrm_kms.c
> +++ b/drivers/gpu/drm/simpledrm/simpledrm_kms.c
> @@ -24,6 +24,13 @@ static const uint32_t sdrm_formats[] = {
> DRM_FORMAT_XRGB,
> };
>
> +void sdrm_lastclose(struct drm_device *ddev)
> +{
> + struct sdrm_device *sdrm = ddev->dev_private;
> +
> + sdrm_fbdev_restore_mode(sdrm);
> +}
> +
> static int sdrm_conn_get_modes(struct drm_connector *conn)
> {
> struct sdrm_device *sdrm = conn->dev->dev_private;
> @@ -91,8 +98,9 @@ void sdrm_display_pipe_update(struct
> drm_simple_display_pipe *pipe,
> struct sdrm_device *sdrm = pipe_to_sdrm(pipe);
>
> sdrm_crtc_send_vblank_event(&pipe->crtc);
> + sdrm_fbdev_display_pipe_update(sdrm, fb);
>
> - if (fb) {
> + if (fb && fb->funcs->dirty) {
> pipe->plane.fb = fb;
> sdrm_dirty_all_locked(sdrm);
> }
> --
> 2.8.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 Sun, Aug 14, 2016 at 06:52:04PM +0200, Noralf Trønnes wrote:
> The SimpleDRM driver binds to simple-framebuffer devices and provides a
> DRM/KMS API. It provides only a single CRTC+encoder+connector combination
> plus one initial mode.
>
> Userspace can create dumb-buffers which can be blit int
EVENT_FB_UNREGISTERED || !fb_helper ||
> + !fb_helper->dev || fb_helper->fbdev != info)
> + return NOTIFY_DONE;
> +
> + sdrm = fb_helper->dev->dev_private;
> +
> + if (sdrm && sdrm->fbdev)
> + platform_device_del(sdrm->ddev->platformdev);
> +
> + return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block sdrm_fbdev_event_notifier = {
> + .notifier_call = sdrm_fbdev_event_notify,
> +};
> +
> +void sdrm_fbdev_kickout_init(void)
> +{
> + fb_register_client(&sdrm_fbdev_event_notifier);
> +}
> +
> +void sdrm_fbdev_kickout_exit(void)
> +{
> + fb_unregister_client(&sdrm_fbdev_event_notifier);
> +}
> --
> 2.8.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
efile
> create mode 100644 drivers/gpu/drm/simpledrm/simpledrm.h
> create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_damage.c
> create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_drv.c
> create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
> create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_gem.c
> create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_kms.c
>
> --
> 2.8.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
this light cleanup would be nice.
Wrt keeping SYNC_WAIT: I think that's totally fine. Redundant since
polling is supported, but not really an issue imo either. If we're totally
lazy we could implement SYNC_WAIT internally using poll and shave off a
few lines of the implementation.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
t_locked(dev, eaction->event);
> + eaction->event = NULL;
> spin_unlock_irqrestore(&dev->event_lock, irq_flags);
> }
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
at's the
solution with spinx?
The other one is graphs - Keith showed me some neat stuff that
asciidoc can do, and I definitely wanted to integrate something like
that as a follow-up into the kerneldoc toolchain. Often a diagram is a
lot more helpful than lots of words. Can sphinx gives us that too?
Wrt reformatting: I'm not going to like it, but I hope that with a bit
of sed we can fix up any of the asciidoc comments we have already
easily - right now we don't (yet) use much of the more sophisticated
markup yet. So much better to change now than 1 year down the road.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
|6 +
> scripts/kernel-doc | 365 -
> scripts/kernel-doc-deps| 66 +
> scripts/kernel-doc-helper | 70 +
> scripts/tmpl2asciidoc | 39 +
> 8 files changed, 1709 insertions(+), 3556 deletions(-)
> delete mode 100644 Documentation/DocBook/gpu.tmpl
> create mode 100644 Documentation/DocBook/gpu.txt
> create mode 100755 scripts/asciidoc-includes
> create mode 100755 scripts/kernel-doc-deps
> create mode 100755 scripts/kernel-doc-helper
> create mode 100755 scripts/tmpl2asciidoc
>
> --
> 2.1.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
nks. :)
Awesome, applied to the CI-only topic branch to unblock the robots, will
fall out automatically once the proper patch lands upstream.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ing like:
>
> num_fences = min(info.num_fences, sync->num_fences);
> struct sync_fence_info array[num_fences];
>
> info.num_fences = sync->num_fences;
> if (num_fences &&
> copy_to_user((void * __user)(unsigned long)info.sync_fence_info, array,
> num_fences * sizeof(array)))
> return -EFAULT;
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
4,7 @@ static struct drm_encoder
> > *mdfld_dsi_connector_best_encoder(
> >
> > /*DSI connector funcs*/
> > static const struct drm_connector_funcs mdfld_dsi_connector_funcs = {
> > - .dpms = /*drm_helper_connector_dpms*/mdfld_dsi_connector_dpms,
> > + .dpms = drm_helper_connector_dpms,
> > .detect = mdfld_dsi_connector_detect,
> > .fill_modes = drm_helper_probe_single_connector_modes,
> > .set_property = mdfld_dsi_connector_set_property,
> > --
> > 1.9.1
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
"backlight", 0,
> > 100);
> > dev_priv->ops->output_init(dev);
> >
> > list_for_each_entry(connector, &dev->mode_config.connector_list,
> >
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
drm_mode_config_init(drm);
> > if (ret)
> > diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> > index 0b921ae06cd8..995fb96cb740 100644
> > --- a/include/drm/drmP.h
> > +++ b/include/drm/drmP.h
> > @@ -1049,6 +1049,7 @@ void drm_dev_ref(struct drm_device
On Sun, Dec 06, 2015 at 11:16:32AM +0100, Nicolas Iooss wrote:
> On 12/06/2015 10:35 AM, Daniel Vetter wrote:
> >> On 11/18/2015 06:58 PM, Nicolas Iooss wrote:
> >>> drm_dev_set_unique() formats its parameter using kvasprintf() but many
> >>> of its callers d
_
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Mon, Dec 07, 2015 at 11:53:01AM +0200, Jani Nikula wrote:
> On Mon, 07 Dec 2015, Daniel Vetter wrote:
> > On Sun, Dec 06, 2015 at 11:16:32AM +0100, Nicolas Iooss wrote:
> >> On 12/06/2015 10:35 AM, Daniel Vetter wrote:
> >> >> On 11/18/2
> > - move the sync framework to drivers/base/dma-buf
> >
> > Cc: Arve Hjønnevåg
> > Cc: Riley Andrews
> > Cc: Daniel Vetter
> > Cc: Rob Clark
> > Cc: Greg Hackmann
> > Cc: John Harrison
> > Signed-off-by: Gustavo Padovan
> > ---
>
31e181d 100644
> --- a/drivers/gpu/drm/i915/dvo_tfp410.c
> +++ b/drivers/gpu/drm/i915/dvo_tfp410.c
> @@ -306,7 +306,7 @@ static void tfp410_destroy(struct intel_dvo_device *dvo)
> }
> }
>
> -struct intel_dvo_dev_ops tfp410_ops = {
> +const struct intel_dvo_dev_ops tfp410_
ave doesn't explain in his MST commit why he's done this.
Dave? I can't come up with a reason, but better to test that. Lyude?
Anyway looks good to me.
Reviewed-by: Daniel Vetter
>
> drivers/gpu/drm/i915/intel_hotplug.c | 2 +-
> 1 file changed, 1 insertion(+), 1 del
On Tue, Jan 05, 2016 at 09:05:49PM +0100, Daniel Vetter wrote:
> On Tue, Jan 05, 2016 at 02:53:08PM -0500, Lyude wrote:
> > There's no reason to check for an active encoder when setting up hpd,
> > especially since a disconnected connector isn't going to have an encod
on_node+0x460/0x460
> [Tue Jan 5 15:15:44 2016] ---[ end trace 074b4bd8168aac27 ]---
>
>In attachment all the hardware details. Also you can find compiled kernel
> here:
>http://mail.gelma.net/i915
>
> Thanks a lot for your work,
> Andrea
> ___
if (!connector->polled && I915_HAS_HOTPLUG(dev) &&
intel_connector->encoder->hpd_pin > HPD_NONE)
connector->polled = DRM_CONNECTOR_POLL_HPD;
}
That yields even tidier code and gives us a place for a comment.
s too much churn)
moving forward with the kerneldoc toolchain we have makes sense. Hence I'd
like to see those patches landed before we resolve #1 if possible.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the l
On Sun, Sep 13, 2015 at 9:13 PM, Jonathan Corbet wrote:
> On Sun, 13 Sep 2015 12:36:07 +0200
> Daniel Vetter wrote:
>
>> Personally I don't care which kind of text markup we pick and wich
>> converter, as long as the project looks reasonable far away from
>> im
ringbuffer.
> *
> * The ringbuffer might not be ready to accept the commands right away
> (maybe it needs to
> --
> 2.6.0.rc0.24.gec371ff
>
> _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-
On Mon, Jan 25, 2016 at 12:19:27AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Friday 15 January 2016 11:17:30 Daniel Vetter wrote:
> > On Fri, Jan 15, 2016 at 01:13:05AM +0200, Laurent Pinchart wrote:
> > > On Thursday 14 January 2016 16:24:56 Maxime
which depends upon tmpfs
> select SHMEM
> select TMPFS
> - select STOP_MACHINE
> select DRM_KMS_HELPER
> select DRM_PANEL
> select DRM_MIPI_DSI
> --
> 1.9.1
>
> ___
> dri-devel mailing list
gt; >>>>>>On Fri, Jan 22, 2016 at 12:06:00PM +0900, Michel Dänzer wrote:
> >>>>>>>
> >>>>>>>[ Trimming KDE folks from Cc ]
> >>>>>>>
> >>>>>>>On 21.01.2016 19:09
On Mon, Jan 25, 2016 at 08:30:14PM +0100, Mario Kleiner wrote:
>
>
> On 01/25/2016 07:51 PM, Daniel Vetter wrote:
> >On Mon, Jan 25, 2016 at 05:38:30PM +0100, Mario Kleiner wrote:
> >>Readding Daniel, which somehow got dropped from the cc.
> >>
> >>O
ar treatment to radeon to avoid redundant calls.
>
> Btw. how the patch to drm_update_vblank_count() close to the bottom would
> actually look is more like:
>
> if ((diff > 1) &&
> ((vblank->inmodeset & 0x2) || (flags & DRM_CALLED_FROM_VBLIRQ)))
>
does:
>
> kbuf = kmalloc(count + 1, GFP_KERNEL);
>
> The kmalloc should use GFP_USER|__GFP_NOWARN flags since the size is
> user-controlled.
>
> On commit 92e963f50fc74041b5e9e744c330dca48e04f08d.
Care to create a patch for this and submit it please? You've done all the
debug work, might as well take credit ;-)
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
contain objects which
>are actually leasable (connectors, crtcs and planes)
> * Drop the patch which changes permissions on get resources
>ioctls
A bit lacking time to do an in-depth review, but all my major concerns
seem to be addressed. On the series.
Acked-by: Daniel Vetter
T
>waiting_seqno = f1->seqno;
> > -
> > - ),
> > -
> > - TP_printk("driver=%s timeline=%s context=%u seqno=%u " \
> > - "waits on driver=%s timeline=%s context=%u seqno=%u",
> > - __get_str(driver), __get_str(timeline), __entry->context,
>
+414,9 @@ tinydrm_dbg_spi_print(struct spi_device *spi, struct
> spi_transfer *tr,
> void _tinydrm_dbg_spi_message(struct spi_device *spi, struct spi_message *m)
> {
> struct spi_transfer *tmp;
> - struct list_head *pos;
> int i = 0;
>
> - list_for_each(pos, &
able3) / sizeof(hz_init_t));
> + setup_hazard_table(init_table1, table1, ARRAY_SIZE(init_table1));
> + setup_hazard_table(init_table2, table2, ARRAY_SIZE(init_table2));
> + setup_hazard_table(init_table3, table3, ARRAY_SIZE(init_table3));
> }
> --
> 2.14.2
>
>
or->format_supported_num = 0;
> - for (i = 0 ; i < TV_FORMAT_NUM; i++)
> + for (i = 0 ; i < ARRAY_SIZE(tv_format_names); i++)
> if (format_map & (1 << i))
>
> psb_intel_sdvo_connector->tv_format_supported[psb_intel_sdvo_connector->format_supported_num++]
> = i;
>
> --
> 2.14.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
int meminfo_proc_show(struct seq_file *m,
> > > > void *v)
> > > > show_val_kb(m, "CmaFree: ",
> > > > global_zone_page_state(NR_FREE_CMA_PAGES));
> > > > #endif
> > > > -
> > > > +#ifdef CONFIG_DMA_SHARED_BUFFER
> > > > + show_val_kb(m, "DmaBufTotal: ", dma_buf_allocated_pages());
> > > > +#endif
> > > > hugetlb_report_meminfo(m);
> > > > arch_report_meminfo(m);
> > > > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> > > > index efdc56b9d95f..5b05816bd2cd 100644
> > > > --- a/include/linux/dma-buf.h
> > > > +++ b/include/linux/dma-buf.h
> > > > @@ -507,4 +507,5 @@ int dma_buf_mmap(struct dma_buf *, struct
> > > > vm_area_struct *,
> > > > unsigned long);
> > > > int dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
> > > > void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
> > > > +long dma_buf_allocated_pages(void);
> > > > #endif /* __DMA_BUF_H__ */
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
2: warning: expecting prototype for A
> > buffer object shrink method that tries to swap out the first(). Prototype
> > was for ttm_global_swapout() instead
> >
> > Cc: Christian Koenig
> > Cc: Huang Rui
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: dri-d
+ b/include/linux/dma-buf.h
> @@ -507,4 +507,5 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct
> *,
>unsigned long);
> int dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
> void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
> +long dma_buf_allocated_pages(void);
> #endif /* __DMA_BUF_H__ */
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
EAD(BLC_PWM_CTL2);
> @@ -2037,7 +2035,7 @@ cdv_intel_dp_init(struct drm_device *dev, struct
> psb_intel_mode_device *mode_dev
> pp_on = REG_READ(PP_ON_DELAYS);
> pp_off = REG_READ(PP_OFF_DELAYS);
> pp_div = REG_READ(PP_DIVISOR);
> -
>
On Tue, Apr 20, 2021 at 09:26:00AM +, peter.enderb...@sony.com wrote:
> On 4/20/21 10:58 AM, Daniel Vetter wrote:
> > On Sat, Apr 17, 2021 at 06:38:35PM +0200, Peter Enderborg wrote:
> >> This adds a total used dma-buf memory. Details
> >> can be found in deb
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
> > + if (efifb_pci_dev)
> > + pm_runtime_put(&efifb_pci_dev->dev);
> >
> > return 0;
> > }
> > --
> > 2.30.2
> >
> > ___________
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On 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
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 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
7;t stable
> >> and
> >> can be zapped and refaulted under us while we do the walk.
> > I didn't say it would be simple :) But we also need to stop hacking
> > around the sides of all this huge page stuff and come up with sensible
> > APIs that drivers can actually implement correctly. Exposing drivers
> > to specific kinds of page levels really feels like the wrong level of
> > abstraction.
> >
> > Once we start doing this we should do it everywhere, the io_remap_pfn
> > stuff should be able to create huge special IO pages as well, for
> > instance.
>
> Oh, yes please!
>
> We easily have 16GiB of VRAM which is linear mapped into the kernel
> space for each GPU instance.
>
> Doing that with 1GiB mapping instead of 4KiB would be quite a win.
io_remap_pfn is for userspace mmaps. Kernel mappings should be as big
as possible already I think for everything.
-Daniel
> Regards,
> Christian.
>
> >
> >> On top of this, the user-space address allocator needs to know how large
> >> gpu
> >> pages are aligned in buffer objects to have a reasonable chance of aligning
> >> with CPU huge page boundaries which is a requirement to be able to insert a
> >> huge CPU page table entry, so the driver would basically need the drm
> >> helper
> >> that can do this alignment anyway.
> > Don't you have this problem anyhow?
> >
> > Jason
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On 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
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 35540c7c4416..d4a45518639c 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -85,6 +85,7 @@ struct vkms_device;
> struct vkms_config {
> bool writeback;
> bool cursor;
> + bool virtual_hw;
> /* only set when instantiated */
> struct vkms_device *dev;
> };
> @@ -127,6 +128,7 @@ int vkms_verify_crc_source(struct drm_crtc *crtc, const
> char *source_name,
> /* Composer Support */
> void vkms_composer_worker(struct work_struct *work);
> void vkms_set_composer(struct vkms_output *out, bool enabled);
> +void vkms_crtc_composer(struct vkms_crtc_state *crtc_state);
>
> /* Writeback */
> int vkms_enable_writeback_connector(struct vkms_device *vkmsdev);
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On 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
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:
> > > >
#ifndef __NVKM_PCI_AGP_H__
> > #define __NVKM_PCI_AGP_H__
> >
> > +/* SPDX-License-Identifier: MIT */
> > +#include "priv.h"
> > +#if IS_ENABLED(CONFIG_AGP)
> > void nvkm_agp_ctor(struct nvkm_pci *);
> > void nvkm_agp_dtor(struct nvkm_pci *);
> > void nvkm_agp_preinit(struct nvkm_pci *);
> > int nvkm_agp_init(struct nvkm_pci *);
> > void nvkm_agp_fini(struct nvkm_pci *);
> > -#endif
> > #else
> > static inline void nvkm_agp_ctor(struct nvkm_pci *pci) {}
> > static inline void nvkm_agp_dtor(struct nvkm_pci *pci) {}
> > @@ -17,3 +16,5 @@ static inline void nvkm_agp_preinit(struct nvkm_pci *pci)
> > {}
> > static inline int nvkm_agp_init(struct nvkm_pci *pci) { return -ENOSYS; }
> > static inline void nvkm_agp_fini(struct nvkm_pci *pci) {}
> > #endif
> > +
> > +#endif
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
noise, set the VM_PFNMAP in the
> system and cma heap's mmap handler.
>
> Cc: Daniel Vetter
> Cc: Jason Gunthorpe
> Cc: Christian Koenig
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Chris Goldsworthy
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: Hridya Valsaraj
ficial to other graphis drivers moving forward as well.
>
> Cc: Christian Koenig
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Andrew Morton
> Cc: Jason Gunthorpe
> Cc: linux...@kvack.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org
> Si
t; means there should not be a performance difference anymore, but this
> needs to be verified.
>
> Cc: Christian Koenig
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Andrew Morton
> Cc: Jason Gunthorpe
> Cc: linux...@kvack.org
> Cc: dri-de...@lists.freedeskto
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
gt;
> >
> > Also, I feel like this code to install "pte_special" huge pages does
> > not belong in the drm subsystem..
>
> I could add helpers in huge_memory.c:
>
> vmf_insert_pfn_pmd_prot_special() and
> vmf_insert_pfn_pud_prot_special()
The somewhat annoying thing is that we'd need an error code so we fall
back to pte fault handling. That's at least my understanding of how
pud/pmd fault handling works. Not sure how awkward that is going to be
with the overall fault handling flow.
But aside from that I think this makes tons of sense.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
sk3.amr.corp.intel.com
> >
> Hmm, yes with that patch it will obviously not work as intended.
>
> Given that, I think we'll need to disable the TTM huge pages for now until
> we can sort out and agree on using a page table entry bit.
Yeah :-/
I think going full pud
;open));
>
> spin_lock(&obj->vma.lock);
> - vma = vma_lookup(obj, vm, view);
> + vma = i915_vma_lookup(obj, vm, view);
> spin_unlock(&obj->vma.lock);
>
> /* vma_create() will resolve the race if another creates the vma */
> --
> 2.30.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
1701 - 1800 of 3914 matches
Mail list logo
