On Tue, 18 Aug 2020 at 15:32, Gerd Hoffmann wrote:
>
> Hi,
>
> > I guess things are never quite so easy :-). It looks like Daniel's
> > patch is in drm-misc-fixes and Sidong's patch is in drm-misc-next. On
> > their own they're fine, but once they are merged in drm-tip the build
> > error shows
On Tue, 9 Apr 2019 at 17:12, kra...@redhat.com wrote:
>
> Hi,
>
> > If not for TTM, what would be the alternative? One VMA manager per
> > memory region per device?
>
> Depends pretty much on the device.
>
> The cirrus is a display device with only 4 MB of vram. You can't fit
> much in there.
On Sat, 12 Jan 2019 at 07:13, Dave Airlie wrote:
>
> On Thu, 10 Jan 2019 at 18:17, Gerd Hoffmann wrote:
> >
> > Also set prime_handle_to_fd and prime_fd_to_handle to NULL,
> > so drm will not advertive DRM_PRIME_CAP_{IMPORT,EXPORT} to
> > userspace.
It's b
On Thu, 10 Jan 2019 at 18:17, Gerd Hoffmann wrote:
>
> Also set prime_handle_to_fd and prime_fd_to_handle to NULL,
> so drm will not advertive DRM_PRIME_CAP_{IMPORT,EXPORT} to
> userspace.
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Dave Airlie
> ---
> drivers/gpu/
On Thu, 10 Jan 2019 at 21:16, Gerd Hoffmann wrote:
>
> Also set prime_handle_to_fd and prime_fd_to_handle to NULL,
> so drm will not advertive DRM_PRIME_CAP_{IMPORT,EXPORT} to
> userspace.
Reviewed-by: Dave Airlie
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/
On Thu, 13 Dec 2018 at 23:49, Gerd Hoffmann wrote:
>
> Signed-off-by: Gerd Hoffmann
Seems correct to me,
Reviewed-by: Dave Airlie
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/m
On Thu, 18 Oct 2018 at 17:00, Gerd Hoffmann wrote:
>
> > > > This to me feels more like a bind/unbind operation rather than a
> > > > populate/unpopulate operation,
> > > >
> > > > bind is " Bind the backend pages into the aperture in the location"
> > > >
> > > > whereas populate is
> > > >
> > >
On Thu, 18 Oct 2018 at 16:11, Gerd Hoffmann wrote:
>
> On Thu, Oct 18, 2018 at 11:41:52AM +1000, Dave Airlie wrote:
> > On Mon, 1 Oct 2018 at 20:33, Gerd Hoffmann wrote:
> > >
> > > Remove the virtio_gpu_object_{attach,detach} calls from move_notify()
> >
On Mon, 1 Oct 2018 at 20:33, Gerd Hoffmann wrote:
>
> Remove the virtio_gpu_object_{attach,detach} calls from move_notify()
> callback. Add them to the ttm_tt_{populate,unpopulate} callbacks, which
> is the correct place to handle this.
>
> The new ttm_tt_{populate,unpopulate} callbacks call the
On Mon, 1 Oct 2018 at 20:33, Gerd Hoffmann wrote:
>
> Track whenever the virtio_gpu_object is already created (i.e. host knows
> about it) in a new variable. Add checks to virtio_gpu_object_attach()
> to do nothing on objects not created yet.
>
> Make virtio_gpu_ttm_bo_destroy() use the new varia
Reviewed-by: Dave Airlie
On Fri, 5 Oct 2018 at 22:52, Gerd Hoffmann wrote:
>
> The feature allows the guest request an EDID blob (describing monitor
> capabilities) for a given scanout (aka virtual monitor connector).
>
> It brings a new command message, which has just a scanou
On Fri, 5 Oct 2018 at 22:10, Gerd Hoffmann wrote:
>
> Recent qemu (latest master branch, upcoming 3.1 release) got support
> for EDID data. This patch adds guest driver support.
>
> EDID support in qemu is not (yet) enabled by default, so please use
> 'qemu -device VGA,edid=on' for testing.
The
For the series,
Reviewed-by: Dave Airlie
On Wed, 29 Aug 2018 at 22:20, Gerd Hoffmann wrote:
>
> Use the dma mapping api and properly add iommu mappings for
> objects, unless virtio is in iommu quirk mode.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/virt
off-by: Gerd Hoffmann
Reviewed-by: Dave Airlie
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
> drivers/gpu/drm/virtio/virtgpu_display.c | 4
> drivers/gpu/drm/virtio/virtgpu_plane.c | 2 +-
> 3 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu
On 17 June 2018 at 21:02, Greg KH wrote:
> On Sun, Jun 17, 2018 at 12:38:06PM +0200, Mike Galbraith wrote:
>> On Sun, 2018-06-17 at 11:36 +0200, Greg KH wrote:
>> >
>> > And if you revert that patch, does everything work again?
>>
>> Yes.
>
> Great, Dave, care to revert this in 4.18 so I can queue
ntries but not enough for the request.
>
> Ping airlied, can you please either pick it up or review so I can commit
> myself?
Just in case it got lost from my phone,
Reviewed-by: Dave Airlie
>
> thanks,
> Gerd
>
>> Cc: sta...@vger.kernel.org
>> Report
Reviewed-by: Dave Airlie
On Fri., 20 Apr. 2018, 17:23 Gerd Hoffmann, wrote:
> On Tue, Apr 03, 2018 at 11:59:04AM +0200, Gerd Hoffmann wrote:
> > Wait until we have enough space in the virt queue to actually queue up
> > our request. Avoids the guest spinning in case we
>
> this work is based on the virtio_wl driver in the ChromeOS kernel by
> Zach Reizner, currently at:
>
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/virtio/virtio_wl.c
>
> There's two features missing in this patch when compared with virtio_wl:
>
> * All
On 9 August 2017 at 09:42, Joe Kniss wrote:
> Because all drivers currently use gem objects for framebuffer planes,
> the virtual create_handle() is not required. This change adds a
> struct drm_gem_object *gems[4] field to drm_framebuffer and removes
> create_handle() function pointer from drm_f
>
> I'm traveling and cannot make progress this week. The merge window is
> also real close so this series will therefore probably miss it unless
> something unexpected happens...
Don't worry you missed the merge window for drm already, we don't merge
things after -rc6. Please remember the Linus m
On 3 April 2017 at 17:08, Gerd Hoffmann wrote:
> Lookup format using virtio_gpu_translate_format()
> instead of hardcoding it. Fixes xorg display on
> bigendian guests (i.e. ppc64).
>
> Signed-off-by: Gerd Hoffmann
For the series,
Reviewed-by: Dave Airlie
> ---
> d
On 11 September 2015 at 01:04, Emil Velikov wrote:
> On 10 September 2015 at 15:52, Gerd Hoffmann wrote:
>> Hi,
>>
>>> > Dave? Looking at the ioctls they are all fine for render nodes, there
>>> > isn't anything modesetting related in the device-specific ioctls.
>>> >
>>> > Correct?
>>> >
>>>
> > --- /dev/null
> > +++ b/include/uapi/drm/virtgpu_drm.h
> > @@ -0,0 +1,163 @@
>
> > +
> > +struct drm_virtgpu_3d_box {
> > + uint32_t x, y, z;
> > + uint32_t w, h, d;
> > +};
> > +
> There was a similar case (multiple variables declared on a single
> line) in drm core that caused con
>>
>>
>> Can the various in-kernel GPU drivers benefit from this? If so, wiring
>> up one or more of those would be helpful?
>
>
> I'm sure that other in-kernel GPU drivers can have benefit.
> It must be helpful.
>
> If I was familiar with other in-kernel GPU drivers code, I tried to patch
> them.
On 25 March 2015 at 08:50, Daniel Stone wrote:
> Hi,
>
> On 24 March 2015 at 16:07, Gerd Hoffmann wrote:
>> +static int virtio_gpu_crtc_page_flip(struct drm_crtc *crtc,
>> +struct drm_framebuffer *fb,
>> +struct drm_pending_v
On 21 October 2014 03:09, Josh Boyer wrote:
> On Mon, Oct 20, 2014 at 10:05 AM, Michael S. Tsirkin wrote:
>> On Mon, Oct 20, 2014 at 03:58:49PM +0200, Cornelia Huck wrote:
>>> Commit f5866db6 (virtio_console: enable VQs early) tried to make
>>> sure that DRIVER_OK was set when virtio_console star
On 14 September 2014 19:16, Michael S. Tsirkin wrote:
> On Thu, Sep 11, 2014 at 05:09:33PM +0200, Gerd Hoffmann wrote:
>> Signed-off-by: Gerd Hoffmann
>> ---
>> docs/specs/virtio-gpu.txt | 165
>> ++
>> 1 file changed, 165 insertions(+)
>> create mod
www.kraxel.org/cgit/qemu/log/?h=rebase/vga-wip
> https://www.kraxel.org/cgit/linux/log/?h=virtio-gpu-rebase
>
> The qemu patches are in a reasonable state. The linux kernel patches
> are not cleaned up yet, you probably want to look at the final tree
> only.
>
> Work has been
>> Can the host refuse due to lack of resources?
>
> Yes. virtgpu_ctrl_hdr.type in the response will be set to
> VIRTGPU_RESP_ERR_* then. Current implementation does that only on
> malloc() failure, there is no accounting (yet) to limit the amout of
> memory the guest is allowed to allocate.
We
>
> We have almost 1000 more uses of the non-macro version than the "macro"
> version in the kernel today:
> $ git grep -w DEFINE_PCI_DEVICE_TABLE | wc -l
> 262
> $ git grep "const struct pci_device_id" | wc -l
> 1254
did you check for non-const ones? just to see if we have any of the
broken case
>> correct.
>>
>> If I have an indirect ring and I'm adding sgs to it and the host is
>> delayed (say I've got a thread consuming things from the vring and its
>> off doing something interesting),
>> I'd really like to get ENOSPC back from virtqueue_add. However if the
>> indirect addition fails du
31 matches
Mail list logo