/* this should unref the ttm bo */
> - drm_gem_object_unreference_unlocked(&bo->gem_base);
> + drm_gem_object_put_unlocked(&bo->gem_base);
> }
> }
>
> --
> 2.7.4
>
> --
> You received this message beca
@lists.freedesktop.org
> Cc: Benjamin Gaignard
> Cc: Boris Brezillon
> Cc: ch...@chris-wilson.co.uk
> Cc: "Christian König"
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Cc: David Airlie
> Cc: "David (ChunMing) Zhou"
> Cc: Eric Anholt
> Cc: freedr...
Cc: virtualization@lists.linux-foundation.org
> Signed-off-by: Ville Syrjälä
> Reviewed-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/virtio/virtgpu_display.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_disp
t. Since the buggy code uses the same expression for page frame and
offset I don't think there's a security bug. You might still want to cc:
stable (since without you defacto can't ever use this feature).
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/qxl/qxl_io
turn 0;
> -}
> -
> static void qxl_conn_destroy(struct drm_connector *connector)
> {
> struct qxl_output *qxl_output =
> @@ -1081,7 +1032,6 @@ static const struct drm_connector_funcs
> qxl_connector_funcs = {
> .dpms = drm_helper_connector_dpms,
> .detect = qx
erge with 4.17-rcX soon?
For backmerge requests you need to cc/ping the drm-misc maintainers.
Adding them. I think the hold-up also was that Dave was on vacations
still.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
_dev_unref(dev);
> + drm_dev_put(dev);
> return r;
> }
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
> index 94b99c90425a..259c85fcd32c 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.c
> +++ b/drivers/gpu/drm
On Thu, Apr 26, 2018 at 3:14 PM, Alexandre Belloni
wrote:
> Hi,
>
> On 26/04/2018 15:45:44+0300, Laurent Pinchart wrote:
>> Hi Daniel,
>>
>> On Thursday, 26 April 2018 15:36:15 EEST Daniel Vetter wrote:
>> > On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaisha
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualization@lists.linux-foundation.org
---
drivers/gpu/drm/qxl/qxl_release.c | 7 ---
1 file changed, 7 deletions(-)
diff
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Signed-off-by: Daniel Vetter
Cc: David Airlie
Cc: Gerd Hoffmann
Cc: virtualization@lists.linux-foundation.org
---
drivers/gpu/drm/virtio/virtgpu_fence.c | 7 ---
1 file changed, 7 deletions
The trivial enable_signaling implementation matches the default code.
v2: Fix up commit message to match patch better (Eric).
Cc: Eric Anholt
Reviewed-by: Eric Anholt
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualization@lists.linux-foundation.org
---
drivers
The trivial enable_signaling implementation matches the default code.
v2: Fix up commit message to match patch better (Eric).
Cc: Eric Anholt
Reviewed-by: Eric Anholt
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualization@lists.linux-foundation.org
---
drivers
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Reviewed-by: Eric Anholt
Signed-off-by: Daniel Vetter
Cc: David Airlie
Cc: Gerd Hoffmann
Cc: virtualization@lists.linux-foundation.org
---
drivers/gpu/drm/virtio/virtgpu_fence.c | 7 ---
1
The trivial enable_signaling implementation matches the default code.
v2: Fix up commit message to match patch better (Eric).
Cc: Eric Anholt
Reviewed-by: Eric Anholt
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualization@lists.linux-foundation.org
---
drivers
On Thu, May 03, 2018 at 04:26:02PM +0200, Daniel Vetter wrote:
> dma_fence_default_wait is the default now, same for the trivial
> enable_signaling implementation.
>
> Reviewed-by: Eric Anholt
> Signed-off-by: Daniel Vetter
> Cc: David Airlie
> Cc: Gerd Hoffmann
Nobody's using cirrus because they care
> about color fidelity and it'll use less CPU to update. There's
> precedent here, mgag200 defaults to 16bpp on sufficiently memory-
> impaired devices.
Yeah nouveau does the same fallback to 16bpp if there's not enough vram.
s are
> + * removed.
> + */
This looks like misplaced copypasta. You only need this once I think.
-Daniel
> static inline int
> drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
> const char *name, bool primar
On Fri, Aug 31, 2018 at 10:56:56AM +0200, Daniel Vetter wrote:
> On Thu, Aug 30, 2018 at 11:00:05PM +0200, Michał Mirosław wrote:
> > Interpret (otherwise-invalid) NULL apertures argument to mean all-memory
> > range. This will allow to remove several duplicates of this code from
(+), 172 deletions(-)
>
> --
> 2.18.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
_
c | 24 ++---
> drivers/video/fbdev/core/fbmem.c | 63 +++-
> include/drm/drm_fb_helper.h | 12 +
> include/linux/fb.h | 2 +
> 13 files changed, 89 insertions(+), 172 deletions(-)
>
> --
> 2.18.0
>
> _
*fb_info);
> +extern int remove_conflicting_pci_framebuffers(struct pci_dev *pdev, int
> res_id,
> +const char *name);
> extern int remove_conflicting_framebuffers(struct apertures_struct *a,
> const
On Mon, Sep 03, 2018 at 01:31:34PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Monday, September 03, 2018 09:43:15 AM Daniel Vetter wrote:
> > On Sat, Sep 01, 2018 at 04:08:41PM +0200, Michał Mirosław wrote:
> > > This series cleans up duplicated code for replacing firmware FB
ged) plus gem-shmem support
for it (still in flight) from Noralf should be able to pull that off. That
gives you the fb_mmap implementation, but with 100% generic code instead
of a driver specific hack like Max did.
>
> Signed-off-by: Peter Wu
lgtm. Acked-by: Daniel Vetter
I'll leave mer
le()")
Cc: # v4.14+
Reviewed-by: Daniel Vetter
I'll let Gerd pick this one up, after some testing. Also adding Laurent.
-Daniel
> "crtc_funcs->disable" call would crash (resulting in suspend failure).
> Fix this by converting the suspend/resume functions to use the
>
256 bytes)?
>
> If not, maybe add comment to explain why you chose 1024.
EDID in the wild can be up to 512 bytes.
-Daniel
>
> > +};
> > +
> > #define VIRTIO_GPU_EVENT_DISPLAY (1 << 0)
> >
> > struct virtio_gpu_config {
> > --
> > 2.9.
nd stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.go
etry logic resides), if you don't
have a i2c_adapater (because the hw has some magic "give me an edid"
block). For virtual hw we hopefully don't randomly drop bits on the floor
between the guest and host. Imo totally fine as-is.
E.g. we also don't feed th
ice VGA,edid=on' for testing.
>
> Signed-off-by: Gerd Hoffmann
I liked v3 more, but Acked-by: Daniel Vetter on
either wone.
-Daniel
> ---
> drivers/gpu/drm/bochs/bochs.h | 2 ++
> drivers/gpu/drm/bochs/bochs_hw.c | 30 ++
&
anout < vgdev->num_scanouts; scanout++) {
> + resp_buf = kzalloc(sizeof(struct virtio_gpu_resp_edid),
> +GFP_KERNEL);
> + if (!resp_buf)
> + return -ENOMEM;
> +
> + cmd_p = virtio_gpu_alloc_cmd_resp
> +
On Tue, Oct 30, 2018 at 11:28:24AM +0200, Jani Nikula wrote:
> On Tue, 30 Oct 2018, Daniel Vetter wrote:
> > On Mon, Oct 29, 2018 at 09:05:20PM +0100, Gerd Hoffmann wrote:
> >> On Mon, Oct 29, 2018 at 07:44:28PM +0200, Jani Nikula wrote:
> >> > On Mon, 29
On Wed, Nov 21, 2018 at 09:54:22AM +0100, Gerd Hoffmann wrote:
> On Tue, Oct 30, 2018 at 10:38:04AM +0100, Daniel Vetter wrote:
> > On Tue, Oct 30, 2018 at 07:32:06AM +0100, Gerd Hoffmann wrote:
> > > linux guest driver implementation of the VIRTIO_GPU_F_EDID feature.
> >
t;. That's what this patch
> > series is
> > about.
>
> The series:
> Reviewed-by: Linus Walleij
Since your reviewed it all, and there's a pile of acks for the driver
parts too: Want to go ahead and apply it too?
Thanks, Daniel
--
On Wed, Nov 21, 2018 at 08:21:29PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Wednesday, 21 November 2018 11:42:33 EET Daniel Vetter wrote:
> > On Thu, Nov 15, 2018 at 11:38:35PM +0100, Linus Walleij wrote:
> > > On Thu, Nov 15, 2018 at 11:17 PM Fernando Ramos
On Sat, Nov 24, 2018 at 10:17:13PM +0100, Linus Walleij wrote:
> On Wed, Nov 21, 2018 at 10:42 AM Daniel Vetter wrote:
> > On Thu, Nov 15, 2018 at 11:38:35PM +0100, Linus Walleij wrote:
> > > On Thu, Nov 15, 2018 at 11:17 PM Fernando Ramos
> > > wrote:
> > >
On Thu, Nov 29, 2018 at 3:45 PM Linus Walleij wrote:
>
> On Mon, Nov 26, 2018 at 3:12 PM Daniel Vetter wrote:
> > On Sat, Nov 24, 2018 at 10:17:13PM +0100, Linus Walleij wrote:
>
> > > It was especially scary.
> > >
> > > But I think I managed to apply
Doesn't do anything with atomic.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualization@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
---
drivers/gpu/drm/qxl/qxl_display.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/dr
drm_crtc_helper.h includes.
Signed-off-by: Daniel Vetter
Cc: linux-arm-ker...@lists.infradead.org
Cc: virtualization@lists.linux-foundation.org
Cc: etna...@lists.freedesktop.org
Cc: linux-samsung-...@vger.kernel.org
Cc: intel-...@lists.freedesktop.org
Cc: linux-media...@lists.infradead.org
Cc: linux-amlo
drm_crtc_helper.h includes.
Signed-off-by: Daniel Vetter
Cc: linux-arm-ker...@lists.infradead.org
Cc: virtualization@lists.linux-foundation.org
Cc: etna...@lists.freedesktop.org
Cc: linux-samsung-...@vger.kernel.org
Cc: intel-...@lists.freedesktop.org
Cc: linux-media...@lists.infradead.org
Cc: linux-amlo
On Mon, Dec 10, 2018 at 02:40:25PM +0100, Benjamin Gaignard wrote:
> Le lun. 10 déc. 2018 à 12:10, Benjamin Gaignard
> a écrit :
> >
> > Le lun. 10 déc. 2018 à 11:24, Thierry Reding
> > a écrit :
> > >
> > > On Mon, Dec 10, 2018 at 11:11:33AM +0100, Dan
's a bit a lack of gpu drivers from the arm world in upstream,
which is probabyl why this patch series doesn't come with a user. Might be
better to first upstream the driver before talking about additional
infrastructure that it needs.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
kernel page allocations. And this also seems the primary motivation for
this patch series, so I think that's really what we should use to judge
these patches.
Of course then there's the seemingly eternal chicken/egg problem of
upstream gpu drivers for SoCs :(
-Daniel
--
Dani
On Wed, Jul 29, 2015 at 01:16:14PM +0100, Mel Gorman wrote:
> On Wed, Jul 29, 2015 at 12:55:54PM +0200, Daniel Vetter wrote:
> > On Wed, Jul 29, 2015 at 11:49:45AM +0100, Mel Gorman wrote:
> > > On Mon, Jul 13, 2015 at 05:35:15PM +0900, Gioh Kim wrote:
> > > > My ARM
d *vaddr)
> +{
> + WARN_ONCE(1, "not implemented");
> +}
> +
> +int virtgpu_gem_prime_mmap(struct drm_gem_object *obj,
> +struct vm_area_struct *area)
> +{
> + WARN_ONCE(1, "not implemented");
> + return ENOSYS;
This can get called by userspace, so please don't WARN here. Also missing
negate sign:
return -ENOSYS;
Cheers, Daniel
> +}
> --
> 1.8.3.1
>
> ___
> 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
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
eative at errno
abuse, e.g. we already use -ENOENT to signal any kind of lookup failure in
ioctls (even if the fd itself is obviously there so not possible that the
fd isn't there).
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_
__
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
_fixup,
> > .mode_set = exynos_dsi_mode_set,
> > .enable = exynos_dsi_enable,
> > .disable = exynos_dsi_disable,
> > --
> > 2.5.0
> >
> ___
> dri-devel mailing list
> dri-de...@lists.f
t; + DRM_DEBUG_KMS("CRTC fixup failed\n");
> + goto done;
> + }
> }
> DRM_DEBUG_KMS("[CRTC:%d:%s]\n", crtc->base.id, crtc->name);
>
> --
> 2.5.0
>
--
Daniel Vetter
Software Engineer, Intel Corporatio
rivers/gpu/drm/virtio/virtgpu_display.c | 8
> 33 files changed, 244 deletions(-)
>
> --
> 2.5.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.o
adjusted_mode))) {
>
>You haven't run the patch thru scripts/checkpatch.pl, have you? :-)
> (It curses on assignment inside the *if* expression.)
pre-existing, so checkpatch.pl doesn't get a vote ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
h
c,
> >> }
> >>
> >> static const struct drm_crtc_helper_funcs lcdc_crtc_helper_funcs = {
> >> - .mode_fixup = atmel_hlcdc_crtc_mode_fixup,
> >>.mode_set = drm_helper_crtc_mode_set,
> >>.mode_set_nofb = atmel_hlcdc_crtc_mode_set_nofb,
> >>.mode_set_base = drm_helper_crtc_mode_set_base,
> >> @@ -349,4 +341,3 @@ fail:
> >>atmel_hlcdc_crtc_destroy(&crtc->base);
> >>return ret;
> >> }
> >> -
> >
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
| 8
> drivers/gpu/drm/sti/sti_crtc.c | 9 -
> drivers/gpu/drm/udl/udl_modeset.c | 9 -
> drivers/gpu/drm/virtio/virtgpu_display.c | 8
> 22 files changed, 12 insertions(+), 158 deletions(-)
>
> --
> 2.5.0
&
m_atomic_helper_page_flip,
> -#endif
> + .page_flip = virtio_gpu_page_flip,
> .reset = drm_atomic_helper_crtc_reset,
> .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> --
On Mon, Mar 30, 2015 at 4:49 PM, Daniel Vetter wrote:
> On Mon, Mar 30, 2015 at 02:23:47PM +0200, Gerd Hoffmann wrote:
>> > > Signed-off-by: Dave Airlie
>> > > Signed-off-by: Gerd Hoffmann
>> >
>> > Standard request from my side for new drm drivers
On Fri, May 27, 2016 at 09:46:03AM +0200, Gerd Hoffmann wrote:
> On Mi, 2016-05-25 at 18:37 +0200, Daniel Vetter wrote:
> > On Fri, Oct 2, 2015 at 1:58 PM, Gerd Hoffmann wrote:
> > > Signed-off-by: Gerd Hoffmann
> >
> > So I entirely missed this, but this
(vgdev, handle,
> + plane->state->crtc_x,
> + plane->state->crtc_y,
> + plane->state->crtc_w,
> +
On Fri, May 27, 2016 at 09:50:27AM +0200, Daniel Vetter wrote:
> On Fri, May 27, 2016 at 09:46:03AM +0200, Gerd Hoffmann wrote:
> > On Mi, 2016-05-25 at 18:37 +0200, Daniel Vetter wrote:
> > > On Fri, Oct 2, 2015 at 1:58 PM, Gerd Hoffmann wrote:
> > > >
ke care of your troubles. Using the old crtc is
definitely not what you want.
Another option is that virtio isn't happy about bashing in plane state for
disabled crtc. Again helpers have you covered, look at the active_only
parameter for drm_atomic_helper_commit_planes().
Aside, if you wond
ly it means to
compare the entire fb (including backing storage pointer/offsets and
everything).
So would be a bit more work to wire up for atomic userspace, but indeed a
lot less work to implement. I'm totally happy if you go with that tradeoff
;-)
Cheers, Daniel
--
Daniel Vetter
Softw
bo = gem_to_virtio_gpu_obj(vgfb->obj);
> --
> 1.8.3.1
>
> _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engi
ing upset about certain things).
I'll pick up your patch into my nonblocking atomic branch to make sure
virtio isn't accidentally broken. btw can you pls drop an ack or r-b
onto my virtio conversion? I already added your tested-by.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel
f an object (since chicken-egg: you want the
list of properties before creating a new framebuffer, so can't use
that framebuffer to enumerate them).
But really not a big concern.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
vgfb = to_virtio_gpu_framebuffer(plane->state->fb);
> bo = gem_to_virtio_gpu_obj(vgfb->obj);
> --
> 1.8.3.1
>
> _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel
your tested-by.
>
> Grr, mail is not in my dri-devel folder. Guess that is the
> "avoid-duplicates" mailman option at work.
>
> Feel free to just add the r-b too. Or I'll send it for the next version
> of the series.
Added your r-b locally so it won't get
gain. The fix is to get off
those pages again (either by unpinning timely, or registering an
mmu_notifier if the driver wants to keep the pages pinned indefinitely, as
a caching optimization).
At least that's my guess, and iirc it was c
connector_funcs->best_encoder(connector);
>> +
>> + /*
>> + * If the DRM device implements atomic hooks and ->best_encoder() is
>> + * NULL we fallback to the default drm_atomic_helper_best_encoder()
>> + * helper.
>> + */
>> + if (fb_helper-
On Fri, Jun 03, 2016 at 09:37:43AM +0200, Boris Brezillon wrote:
> On Thu, 2 Jun 2016 23:57:02 +0200
> Daniel Vetter wrote:
>
> > On Thu, Jun 2, 2016 at 11:05 PM, Laurent Pinchart
> > wrote:
> > > Hi Boris,
> > >
> > > Thank you for the patch.
&g
uncs {
>* need to select the best encoder depending upon the desired
>* configuration and can't select it statically.
>*
> - * This function is used by drm_atomic_helper_check_modeset() and either
> - * this or @best_encoder is required.
> +
encoder *encoder)
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 223129d..47fe241 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -1512,7 +1512,6 @@ static const struct drm_connector_funcs
> intel_tv_connector_f
gpu/drm/tegra/hdmi.c | 1 -
> drivers/gpu/drm/tegra/output.c | 8
> drivers/gpu/drm/tegra/rgb.c| 1 -
> drivers/gpu/drm/tegra/sor.c| 1 -
> drivers/gpu/
On Fri, Jun 10, 2016 at 05:24:12PM +0200, Daniel Vetter wrote:
> On Tue, Jun 07, 2016 at 01:48:01PM +0200, Boris Brezillon wrote:
> > For all outputs except dp_mst, we have a 1:1 relationship between
> > connectors and encoders and the driver is relying on the atomic helpers:
>
> This adds a compile-time check in the driver to ensure we only
> attempt to call that function if either CONFIG_FB=y or
> both subsystems are configured as loadable modules.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 0b6320dfdfea ("drm/virtio: make fbdev support really o
gt; virtio_gpu_cmd_submit(vgdev, buf, exbuf->size,
> --
> 2.9.3
>
> ___________
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Softwar
+{
> + struct drm_gem_object *obj;
> +
> + if (buf->ops == &virtgpu_dmabuf_ops) {
> + obj = buf->priv;
> + if (obj->dev == dev) {
> + /*
> + * Importing dmabuf exported from our own gem
On Sat, Oct 05, 2019 at 02:41:54PM +0900, Tomasz Figa wrote:
> Hi Daniel, Gerd,
>
> On Tue, Sep 17, 2019 at 10:23 PM Daniel Vetter wrote:
> >
> > On Thu, Sep 12, 2019 at 06:41:21PM +0900, Tomasz Figa wrote:
> > > This patch is an early RFC to judge the direction
On Tue, Oct 08, 2019 at 07:49:39PM +0900, Tomasz Figa wrote:
> On Tue, Oct 8, 2019 at 7:03 PM Daniel Vetter wrote:
> >
> > On Sat, Oct 05, 2019 at 02:41:54PM +0900, Tomasz Figa wrote:
> > > Hi Daniel, Gerd,
> > >
> > > On Tue, Sep 17, 2019 at 10:23 PM Da
On Wed, Oct 16, 2019 at 12:19:02PM +0900, Tomasz Figa wrote:
> On Wed, Oct 9, 2019 at 12:04 AM Daniel Vetter wrote:
> >
> > On Tue, Oct 08, 2019 at 07:49:39PM +0900, Tomasz Figa wrote:
> > > On Tue, Oct 8, 2019 at 7:03 PM Daniel Vetter wrote:
> > > >
> &
%cvirgl %cedid\n",
> + vgdev->has_virgl_3d ? '+' : '-',
> + vgdev->has_edid ? '+' : '-');
Maybe we should move the various yesno/onoff/enableddisabled helpers from
i915_utils.h to drm_utils.h and use them m
On Fri, Oct 18, 2019 at 02:23:52PM +0200, Gerd Hoffmann wrote:
> Be consistent with the rest of the code base.
>
> Signed-off-by: Gerd Hoffmann
Assuming sparse is all still pleased:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++--
> driv
: Linus Walleij
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/cirrus/cirrus.c | 2 +-
drivers/gpu/drm/drm_simple_kms_helper.c | 2 +-
drivers/gpu/drm/pl111/pl111_display.c | 4 ++--
include/drm/drm_simple_kms_helper.h | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff
g the prepare/cleanup_fb functions to match full atomic
helpers.
-Daniel
>
> Best regards
> Thomas
>
> Am 22.10.19 um 17:55 schrieb Daniel Vetter:
> > Passing the wrong type feels icky, everywhere else we use the pipe as
> > the first parameter. Spotted while discussing patches
On Wed, Oct 23, 2019 at 08:47:57AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 22.10.19 um 21:03 schrieb Daniel Vetter:
> > On Tue, Oct 22, 2019 at 7:16 PM Thomas Zimmermann
> > wrote:
> >>
> >> Hi,
> >>
> >> there are two types
: Emil Velikov
Cc: virtualization@lists.linux-foundation.org
Cc: Linus Walleij
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/cirrus/cirrus.c | 2 +-
drivers/gpu/drm/drm_simple_kms_helper.c | 2 +-
drivers/gpu/drm/pl111/pl111_display.c | 4 ++--
drivers/gpu/drm/xen/xen_drm_front_kms.c
On Wed, Oct 23, 2019 at 3:18 PM Jani Nikula wrote:
>
> On Tue, 22 Oct 2019, Daniel Vetter wrote:
> > On Fri, Oct 18, 2019 at 01:38:32PM +0200, Gerd Hoffmann wrote:
> >> Signed-off-by: Gerd Hoffmann
> >> ---
> >> drivers/gpu/drm/virtio/virtgpu_kms.
On Wed, Oct 23, 2019 at 05:40:32PM +0200, Linus Walleij wrote:
> On Wed, Oct 23, 2019 at 12:13 PM Daniel Vetter wrote:
>
> > Passing the wrong type feels icky, everywhere else we use the pipe as
> > the first parameter. Spotted while discussing patches with Thomas
> >
virtgpu_drv.c
> @@ -138,7 +138,7 @@ static void virtio_gpu_remove(struct virtio_device *vdev)
>
> drm_dev_unregister(dev);
> virtio_gpu_deinit(dev);
> - drm_put_dev(dev);
> + drm_dev_put(dev);
> }
>
> static void virtio_gpu_config_changed(struct v
Checking both is one too much, so wrap a WARN_ON around it to stope
the copypasta.
Signed-off-by: Daniel Vetter
Cc: David Airlie
Cc: Gerd Hoffmann
Cc: virtualization@lists.linux-foundation.org
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
> -
> - if (crtc->state->event) {
> - spin_lock_irq(&crtc->dev->event_lock);
> - drm_crtc_send_vblank_event(crtc, crtc->state->event);
> - crtc->state->event = NULL;
>
On Mon, Jan 13, 2020 at 10:01 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 13.01.20 um 00:00 schrieb Daniel Vetter:
> > On Fri, Jan 10, 2020 at 12:57:07PM +0100, Thomas Zimmermann wrote:
> >> In drm_atomic_helper_fake_vblank() the DRM core sends out V
efault value to some other/better place in the atomic
helpers, not sure what the best one is.
Plus then in the documentation patch also highlight the link between
crtc_state->no_vblank and drm_dev_has_vblank respectively
drm_device.num_crtcs.
That should plug this issue once for all across the board.
) specific to simple pipe helpers feels kinda
wrong. Simple pipe tends to have a higher ratio of drivers for hw without
vblank support, but by far not the only ones. Having that special case
feels confusing to me (and likely will trip up some people, vblank and
event handling is already a huge source o
On Fri, Jan 17, 2020 at 08:17:10AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 17.01.20 um 00:59 schrieb Daniel Vetter:
> > On Thu, Jan 16, 2020 at 05:22:34PM +, Emil Velikov wrote:
> >> Hi all,
> >>
> >> On Thu, 16 Jan 2020 at 07:37, Thomas Zimmerm
blank.h
> @@ -206,6 +206,7 @@ struct drm_vblank_crtc {
> };
>
> int drm_vblank_init(struct drm_device *dev, unsigned int num_crtcs);
> +bool drm_crtc_has_vblank(const struct drm_crtc *crtc);
> u64 drm_crtc_vblank_count(struct drm_crtc *crtc);
&g
*
> + * Another usage is CRTCs feeding a writeback connector operating in
> + * oneshot mode. In this case the VBLANK event is only generated when
> + * a job is queued to the writeback connector, and we want the core
> + * to fake VBLANK events when this
On Wed, Jan 22, 2020 at 09:53:42AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 22.01.20 um 09:31 schrieb Daniel Vetter:
> > On Mon, Jan 20, 2020 at 01:20:48PM +0100, Thomas Zimmermann wrote:
> >> The new interface drm_crtc_has_vblank() return true if vblanking has
>
re lacks vblank support entirely,
> + * drivers can set &struct drm_crtc_state.no_vblank in
> + * &struct drm_simple_display_pipe_funcs.check and let DRM's
> + * atomic helper fake a vblank event.
>*/
> void (*update)(struct drm_sim
le automatic vblank events explictly.
>
> v4:
> * separate commit from core vblank changes
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Gerd Hoffmann
On all the driver patches:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/xen/xen_drm_front_kms.c | 13
; (it's an event from the
compositor).
Maybe the confusion is with the helper function that generates the
fake_vblank, since it's not really a fake vblank at all, it's just "send
out this atomic completion event now, I'm not going to do it as part of
the vblank processing si
evice *dev = pci_get_drvdata(pdev);
>
> - drm_atomic_helper_shutdown(dev);
> drm_dev_unregister(dev);
> - bochs_unload(dev);
> + drm_atomic_helper_shutdown(dev);
> drm_dev_put(dev);
> }
>
> --
> 2.18.1
>
--
Daniel Vetter
Software E
qxl_ring_free(qdev->command_ring);
> - qxl_ring_free(qdev->cursor_ring);
> - qxl_ring_free(qdev->release_ring);
> qxl_gem_fini(qdev);
> qxl_bo_fini(qdev);
> + flush_work(&qdev->gc_work);
> + qxl_ring_free(qdev->command_r
201 - 300 of 422 matches
Mail list logo
