All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Airlie <airlied@gmail.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	Daniel Stone <daniels@collabora.com>,
	Jonathan Corbet <corbet@lwn.net>, David Airlie <airlied@linux.ie>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"moderated list:DMA BUFFER SHARING FRAMEWORK" 
	<linaro-mm-sig@lists.linaro.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	"open list:KERNEL SELFTEST FRAMEWORK" 
	<linux-kselftest@vger.kernel.org>, Shuah Khan <shuah@kernel.org>,
	"open list:DMA BUFFER SHARING FRAMEWORK" 
	<linux-media@vger.kernel.org>
Subject: Re: [PATCH v6] Add udmabuf misc device
Date: Fri, 6 Jul 2018 14:00:55 +1000	[thread overview]
Message-ID: <CAPM=9tyRRSPa2xk1ZjWLVYG2mro=wMNFK3T70m0TtME-wg9dBA@mail.gmail.com> (raw)
In-Reply-To: <20180704080005.juutrwri4kxm7yim@sirius.home.kraxel.org>

On 4 July 2018 at 18:00, Gerd Hoffmann <kraxel@redhat.com> wrote:
> On Wed, Jul 04, 2018 at 09:26:39AM +0200, Tomeu Vizoso wrote:
>> On 07/04/2018 07:53 AM, Gerd Hoffmann wrote:
>> > On Tue, Jul 03, 2018 at 10:37:57AM +0200, Daniel Vetter wrote:
>> > > On Tue, Jul 03, 2018 at 09:53:58AM +0200, Gerd Hoffmann wrote:
>> > > > A driver to let userspace turn memfd regions into dma-bufs.
>> > > >
>> > > > Use case:  Allows qemu create dmabufs for the vga framebuffer or
>> > > > virtio-gpu ressources.  Then they can be passed around to display
>> > > > those guest things on the host.  To spice client for classic full
>> > > > framebuffer display, and hopefully some day to wayland server for
>> > > > seamless guest window display.
>> > > >
>> > > > qemu test branch:
>> > > >    https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf
>> > > >
>> > > > Cc: David Airlie <airlied@linux.ie>
>> > > > Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
>> > > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>> > > > Cc: Daniel Vetter <daniel@ffwll.ch>
>> > > > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
>> > >
>> > > I think some ack for a 2nd use-case, like virtio-wl or whatever would be
>> > > really cool. To give us some assurance that this is generically useful.
>> >
>> > Tomeu?  Laurent?
>>
>> Sorry, but I think I will need some help to understand how this could help
>> in the virtio-wl case [adding Zach Reizner to CC].
>>
>> Any graphics buffers that are allocated with memfd will be shared with the
>> compositor via wl_shm, without need for dmabufs.
>
> Within one machine, yes.  Once virtualization is added to the mix things
> become more complicated ...
>
> When using virtio-gpu the guest will allocate graphics buffers from
> normal (guest) ram, then register these buffers (which are allowed to be
> scattered) with the host as resource.
>
> qemu can use memfd to allocate guest ram.  Now, with the help of
> udmabuf, qemu can create a *host* dma-buf for the *guest* graphics
> buffer.
>
> That dma-buf can be used by qemu internally (mmap it to get a linear
> mapping of the resource, to avoid copying).  It can be passed on to
> spice-client, to display the guest framebuffer.
>
> And I think it could also be quite useful to pass guest wayland windows
> to the host compositor, without mapping host-allocated buffers into the
> guest, so we don't have do deal with the "find some address space for
> the mapping" issue in the first place.  There are more things needed to
> complete this of course, but it's a building block ...

There is a use case where I think we have to deal with the "find some address
space" problem. For GL4.4 ARB_buffer_storage and Vulkan memory mangement
there is the concept of coherent buffers between GPU and CPU. From the
virgl point of view, we'd create a host buffer in GL, and then create
a mapping from
it on the host that we'd need to present in the guest userspace as a
linear buffer.

Just in case we think this can solve all our problems :-)

Dave.

WARNING: multiple messages have this Message-ID (diff)
From: Dave Airlie <airlied@gmail.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	Daniel Stone <daniels@collabora.com>,
	Jonathan Corbet <corbet@lwn.net>, David Airlie <airlied@linux.ie>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"moderated list:DMA BUFFER SHARING FRAMEWORK" 
	<linaro-mm-sig@lists.linaro.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	"open list:KERNEL SELFTEST FRAMEWORK" 
	<linux-kselftest@vger.kernel.org>, Shuah Khan <shuah@kernel.org>,
	"open list:DMA BUFFER SHARING FRAMEWORK" 
	<linux-media@vger.kernel.org>
Subject: Re: [PATCH v6] Add udmabuf misc device
Date: Fri, 6 Jul 2018 14:00:55 +1000	[thread overview]
Message-ID: <CAPM=9tyRRSPa2xk1ZjWLVYG2mro=wMNFK3T70m0TtME-wg9dBA@mail.gmail.com> (raw)
In-Reply-To: <20180704080005.juutrwri4kxm7yim@sirius.home.kraxel.org>

On 4 July 2018 at 18:00, Gerd Hoffmann <kraxel@redhat.com> wrote:
> On Wed, Jul 04, 2018 at 09:26:39AM +0200, Tomeu Vizoso wrote:
>> On 07/04/2018 07:53 AM, Gerd Hoffmann wrote:
>> > On Tue, Jul 03, 2018 at 10:37:57AM +0200, Daniel Vetter wrote:
>> > > On Tue, Jul 03, 2018 at 09:53:58AM +0200, Gerd Hoffmann wrote:
>> > > > A driver to let userspace turn memfd regions into dma-bufs.
>> > > >
>> > > > Use case:  Allows qemu create dmabufs for the vga framebuffer or
>> > > > virtio-gpu ressources.  Then they can be passed around to display
>> > > > those guest things on the host.  To spice client for classic full
>> > > > framebuffer display, and hopefully some day to wayland server for
>> > > > seamless guest window display.
>> > > >
>> > > > qemu test branch:
>> > > >    https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf
>> > > >
>> > > > Cc: David Airlie <airlied@linux.ie>
>> > > > Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
>> > > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>> > > > Cc: Daniel Vetter <daniel@ffwll.ch>
>> > > > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
>> > >
>> > > I think some ack for a 2nd use-case, like virtio-wl or whatever would be
>> > > really cool. To give us some assurance that this is generically useful.
>> >
>> > Tomeu?  Laurent?
>>
>> Sorry, but I think I will need some help to understand how this could help
>> in the virtio-wl case [adding Zach Reizner to CC].
>>
>> Any graphics buffers that are allocated with memfd will be shared with the
>> compositor via wl_shm, without need for dmabufs.
>
> Within one machine, yes.  Once virtualization is added to the mix things
> become more complicated ...
>
> When using virtio-gpu the guest will allocate graphics buffers from
> normal (guest) ram, then register these buffers (which are allowed to be
> scattered) with the host as resource.
>
> qemu can use memfd to allocate guest ram.  Now, with the help of
> udmabuf, qemu can create a *host* dma-buf for the *guest* graphics
> buffer.
>
> That dma-buf can be used by qemu internally (mmap it to get a linear
> mapping of the resource, to avoid copying).  It can be passed on to
> spice-client, to display the guest framebuffer.
>
> And I think it could also be quite useful to pass guest wayland windows
> to the host compositor, without mapping host-allocated buffers into the
> guest, so we don't have do deal with the "find some address space for
> the mapping" issue in the first place.  There are more things needed to
> complete this of course, but it's a building block ...

There is a use case where I think we have to deal with the "find some address
space" problem. For GL4.4 ARB_buffer_storage and Vulkan memory mangement
there is the concept of coherent buffers between GPU and CPU. From the
virgl point of view, we'd create a host buffer in GL, and then create
a mapping from
it on the host that we'd need to present in the guest userspace as a
linear buffer.

Just in case we think this can solve all our problems :-)

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: airlied at gmail.com (Dave Airlie)
Subject: [PATCH v6] Add udmabuf misc device
Date: Fri, 6 Jul 2018 14:00:55 +1000	[thread overview]
Message-ID: <CAPM=9tyRRSPa2xk1ZjWLVYG2mro=wMNFK3T70m0TtME-wg9dBA@mail.gmail.com> (raw)
In-Reply-To: <20180704080005.juutrwri4kxm7yim@sirius.home.kraxel.org>

On 4 July 2018 at 18:00, Gerd Hoffmann <kraxel at redhat.com> wrote:
> On Wed, Jul 04, 2018 at 09:26:39AM +0200, Tomeu Vizoso wrote:
>> On 07/04/2018 07:53 AM, Gerd Hoffmann wrote:
>> > On Tue, Jul 03, 2018 at 10:37:57AM +0200, Daniel Vetter wrote:
>> > > On Tue, Jul 03, 2018 at 09:53:58AM +0200, Gerd Hoffmann wrote:
>> > > > A driver to let userspace turn memfd regions into dma-bufs.
>> > > >
>> > > > Use case:  Allows qemu create dmabufs for the vga framebuffer or
>> > > > virtio-gpu ressources.  Then they can be passed around to display
>> > > > those guest things on the host.  To spice client for classic full
>> > > > framebuffer display, and hopefully some day to wayland server for
>> > > > seamless guest window display.
>> > > >
>> > > > qemu test branch:
>> > > >    https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf
>> > > >
>> > > > Cc: David Airlie <airlied at linux.ie>
>> > > > Cc: Tomeu Vizoso <tomeu.vizoso at collabora.com>
>> > > > Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
>> > > > Cc: Daniel Vetter <daniel at ffwll.ch>
>> > > > Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
>> > >
>> > > I think some ack for a 2nd use-case, like virtio-wl or whatever would be
>> > > really cool. To give us some assurance that this is generically useful.
>> >
>> > Tomeu?  Laurent?
>>
>> Sorry, but I think I will need some help to understand how this could help
>> in the virtio-wl case [adding Zach Reizner to CC].
>>
>> Any graphics buffers that are allocated with memfd will be shared with the
>> compositor via wl_shm, without need for dmabufs.
>
> Within one machine, yes.  Once virtualization is added to the mix things
> become more complicated ...
>
> When using virtio-gpu the guest will allocate graphics buffers from
> normal (guest) ram, then register these buffers (which are allowed to be
> scattered) with the host as resource.
>
> qemu can use memfd to allocate guest ram.  Now, with the help of
> udmabuf, qemu can create a *host* dma-buf for the *guest* graphics
> buffer.
>
> That dma-buf can be used by qemu internally (mmap it to get a linear
> mapping of the resource, to avoid copying).  It can be passed on to
> spice-client, to display the guest framebuffer.
>
> And I think it could also be quite useful to pass guest wayland windows
> to the host compositor, without mapping host-allocated buffers into the
> guest, so we don't have do deal with the "find some address space for
> the mapping" issue in the first place.  There are more things needed to
> complete this of course, but it's a building block ...

There is a use case where I think we have to deal with the "find some address
space" problem. For GL4.4 ARB_buffer_storage and Vulkan memory mangement
there is the concept of coherent buffers between GPU and CPU. From the
virgl point of view, we'd create a host buffer in GL, and then create
a mapping from
it on the host that we'd need to present in the guest userspace as a
linear buffer.

Just in case we think this can solve all our problems :-)

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: airlied@gmail.com (Dave Airlie)
Subject: [PATCH v6] Add udmabuf misc device
Date: Fri, 6 Jul 2018 14:00:55 +1000	[thread overview]
Message-ID: <CAPM=9tyRRSPa2xk1ZjWLVYG2mro=wMNFK3T70m0TtME-wg9dBA@mail.gmail.com> (raw)
Message-ID: <20180706040055.Xc2aQwbC9s-W5z5YzucixAIg5MhD0R-ipthDKjIT7co@z> (raw)
In-Reply-To: <20180704080005.juutrwri4kxm7yim@sirius.home.kraxel.org>

On 4 July 2018@18:00, Gerd Hoffmann <kraxel@redhat.com> wrote:
> On Wed, Jul 04, 2018@09:26:39AM +0200, Tomeu Vizoso wrote:
>> On 07/04/2018 07:53 AM, Gerd Hoffmann wrote:
>> > On Tue, Jul 03, 2018@10:37:57AM +0200, Daniel Vetter wrote:
>> > > On Tue, Jul 03, 2018@09:53:58AM +0200, Gerd Hoffmann wrote:
>> > > > A driver to let userspace turn memfd regions into dma-bufs.
>> > > >
>> > > > Use case:  Allows qemu create dmabufs for the vga framebuffer or
>> > > > virtio-gpu ressources.  Then they can be passed around to display
>> > > > those guest things on the host.  To spice client for classic full
>> > > > framebuffer display, and hopefully some day to wayland server for
>> > > > seamless guest window display.
>> > > >
>> > > > qemu test branch:
>> > > >    https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf
>> > > >
>> > > > Cc: David Airlie <airlied at linux.ie>
>> > > > Cc: Tomeu Vizoso <tomeu.vizoso at collabora.com>
>> > > > Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
>> > > > Cc: Daniel Vetter <daniel at ffwll.ch>
>> > > > Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
>> > >
>> > > I think some ack for a 2nd use-case, like virtio-wl or whatever would be
>> > > really cool. To give us some assurance that this is generically useful.
>> >
>> > Tomeu?  Laurent?
>>
>> Sorry, but I think I will need some help to understand how this could help
>> in the virtio-wl case [adding Zach Reizner to CC].
>>
>> Any graphics buffers that are allocated with memfd will be shared with the
>> compositor via wl_shm, without need for dmabufs.
>
> Within one machine, yes.  Once virtualization is added to the mix things
> become more complicated ...
>
> When using virtio-gpu the guest will allocate graphics buffers from
> normal (guest) ram, then register these buffers (which are allowed to be
> scattered) with the host as resource.
>
> qemu can use memfd to allocate guest ram.  Now, with the help of
> udmabuf, qemu can create a *host* dma-buf for the *guest* graphics
> buffer.
>
> That dma-buf can be used by qemu internally (mmap it to get a linear
> mapping of the resource, to avoid copying).  It can be passed on to
> spice-client, to display the guest framebuffer.
>
> And I think it could also be quite useful to pass guest wayland windows
> to the host compositor, without mapping host-allocated buffers into the
> guest, so we don't have do deal with the "find some address space for
> the mapping" issue in the first place.  There are more things needed to
> complete this of course, but it's a building block ...

There is a use case where I think we have to deal with the "find some address
space" problem. For GL4.4 ARB_buffer_storage and Vulkan memory mangement
there is the concept of coherent buffers between GPU and CPU. From the
virgl point of view, we'd create a host buffer in GL, and then create
a mapping from
it on the host that we'd need to present in the guest userspace as a
linear buffer.

Just in case we think this can solve all our problems :-)

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Dave Airlie <airlied@gmail.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Daniel Stone <daniels@collabora.com>,
	Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	David Airlie <airlied@linux.ie>, Jonathan Corbet <corbet@lwn.net>,
	open list <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"moderated list:DMA BUFFER SHARING FRAMEWORK"
	<linaro-mm-sig@lists.linaro.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	"open list:KERNEL SELFTEST FRAMEWORK"
	<linux-kselftest@vger.kernel.org>, Shuah Khan <shuah@kernel.org>,
	"open list:DMA BUFFER SHARING FRAMEWORK"
	<linux-media@vger.kernel.org>
Subject: Re: [PATCH v6] Add udmabuf misc device
Date: Fri, 6 Jul 2018 14:00:55 +1000	[thread overview]
Message-ID: <CAPM=9tyRRSPa2xk1ZjWLVYG2mro=wMNFK3T70m0TtME-wg9dBA@mail.gmail.com> (raw)
In-Reply-To: <20180704080005.juutrwri4kxm7yim@sirius.home.kraxel.org>

On 4 July 2018 at 18:00, Gerd Hoffmann <kraxel@redhat.com> wrote:
> On Wed, Jul 04, 2018 at 09:26:39AM +0200, Tomeu Vizoso wrote:
>> On 07/04/2018 07:53 AM, Gerd Hoffmann wrote:
>> > On Tue, Jul 03, 2018 at 10:37:57AM +0200, Daniel Vetter wrote:
>> > > On Tue, Jul 03, 2018 at 09:53:58AM +0200, Gerd Hoffmann wrote:
>> > > > A driver to let userspace turn memfd regions into dma-bufs.
>> > > >
>> > > > Use case:  Allows qemu create dmabufs for the vga framebuffer or
>> > > > virtio-gpu ressources.  Then they can be passed around to display
>> > > > those guest things on the host.  To spice client for classic full
>> > > > framebuffer display, and hopefully some day to wayland server for
>> > > > seamless guest window display.
>> > > >
>> > > > qemu test branch:
>> > > >    https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf
>> > > >
>> > > > Cc: David Airlie <airlied@linux.ie>
>> > > > Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
>> > > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>> > > > Cc: Daniel Vetter <daniel@ffwll.ch>
>> > > > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
>> > >
>> > > I think some ack for a 2nd use-case, like virtio-wl or whatever would be
>> > > really cool. To give us some assurance that this is generically useful.
>> >
>> > Tomeu?  Laurent?
>>
>> Sorry, but I think I will need some help to understand how this could help
>> in the virtio-wl case [adding Zach Reizner to CC].
>>
>> Any graphics buffers that are allocated with memfd will be shared with the
>> compositor via wl_shm, without need for dmabufs.
>
> Within one machine, yes.  Once virtualization is added to the mix things
> become more complicated ...
>
> When using virtio-gpu the guest will allocate graphics buffers from
> normal (guest) ram, then register these buffers (which are allowed to be
> scattered) with the host as resource.
>
> qemu can use memfd to allocate guest ram.  Now, with the help of
> udmabuf, qemu can create a *host* dma-buf for the *guest* graphics
> buffer.
>
> That dma-buf can be used by qemu internally (mmap it to get a linear
> mapping of the resource, to avoid copying).  It can be passed on to
> spice-client, to display the guest framebuffer.
>
> And I think it could also be quite useful to pass guest wayland windows
> to the host compositor, without mapping host-allocated buffers into the
> guest, so we don't have do deal with the "find some address space for
> the mapping" issue in the first place.  There are more things needed to
> complete this of course, but it's a building block ...

There is a use case where I think we have to deal with the "find some address
space" problem. For GL4.4 ARB_buffer_storage and Vulkan memory mangement
there is the concept of coherent buffers between GPU and CPU. From the
virgl point of view, we'd create a host buffer in GL, and then create
a mapping from
it on the host that we'd need to present in the guest userspace as a
linear buffer.

Just in case we think this can solve all our problems :-)

Dave.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2018-07-06  4:01 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-03  7:53 [PATCH v6] Add udmabuf misc device Gerd Hoffmann
2018-07-03  7:53 ` Gerd Hoffmann
2018-07-03  7:53 ` Gerd Hoffmann
2018-07-03  7:53 ` kraxel
2018-07-03  7:53 ` Gerd Hoffmann
2018-07-03  8:37 ` Daniel Vetter
2018-07-03  8:37   ` Daniel Vetter
2018-07-03  8:37   ` Daniel Vetter
2018-07-03  8:37   ` daniel
2018-07-03  8:37   ` Daniel Vetter
2018-07-03  8:37   ` Daniel Vetter
2018-07-04  5:53   ` Gerd Hoffmann
2018-07-04  5:53     ` Gerd Hoffmann
2018-07-04  5:53     ` Gerd Hoffmann
2018-07-04  5:53     ` kraxel
2018-07-04  5:53     ` Gerd Hoffmann
2018-07-04  5:53     ` Gerd Hoffmann
2018-07-04  7:26     ` Tomeu Vizoso
2018-07-04  7:26       ` Tomeu Vizoso
2018-07-04  7:26       ` Tomeu Vizoso
2018-07-04  7:26       ` tomeu.vizoso
2018-07-04  7:26       ` Tomeu Vizoso
2018-07-04  7:26       ` Tomeu Vizoso
2018-07-04  8:00       ` Gerd Hoffmann
2018-07-04  8:00         ` Gerd Hoffmann
2018-07-04  8:00         ` Gerd Hoffmann
2018-07-04  8:00         ` kraxel
2018-07-04  8:00         ` Gerd Hoffmann
2018-07-04  8:00         ` Gerd Hoffmann
2018-07-06  4:00         ` Dave Airlie [this message]
2018-07-06  4:00           ` Dave Airlie
2018-07-06  4:00           ` Dave Airlie
2018-07-06  4:00           ` airlied
2018-07-06  4:00           ` Dave Airlie
2018-07-06  4:00           ` Dave Airlie
2018-08-30 15:17         ` Tomeu Vizoso
2018-08-30 15:17           ` Tomeu Vizoso
2018-08-30 15:17           ` tomeu.vizoso
2018-08-30 15:17           ` Tomeu Vizoso
2018-08-31  7:04           ` Gerd Hoffmann
2018-08-31  7:04             ` Gerd Hoffmann
2018-08-31  7:04             ` Gerd Hoffmann
2018-08-31  7:04             ` kraxel
2018-08-31  7:04             ` Gerd Hoffmann
2018-07-04  8:08     ` Daniel Vetter
2018-07-04  8:08       ` Daniel Vetter
2018-07-04  8:08       ` Daniel Vetter
2018-07-04  8:08       ` daniel
2018-07-04  8:08       ` Daniel Vetter
2018-07-04  8:08       ` Daniel Vetter
2018-07-04  8:58       ` Gerd Hoffmann
2018-07-04  8:58         ` Gerd Hoffmann
2018-07-04  8:58         ` Gerd Hoffmann
2018-07-04  8:58         ` kraxel
2018-07-04  8:58         ` Gerd Hoffmann
2018-07-04  8:58         ` Gerd Hoffmann
2018-07-04  9:19         ` Daniel Vetter
2018-07-04  9:19           ` Daniel Vetter
2018-07-04  9:19           ` Daniel Vetter
2018-07-04  9:19           ` daniel
2018-07-04  9:19           ` Daniel Vetter
2018-07-04  9:19           ` Daniel Vetter
2018-08-27  9:34           ` Gerd Hoffmann
2018-08-27  9:34             ` Gerd Hoffmann
2018-08-27  9:34             ` kraxel
2018-08-27  9:34             ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPM=9tyRRSPa2xk1ZjWLVYG2mro=wMNFK3T70m0TtME-wg9dBA@mail.gmail.com' \
    --to=airlied@gmail.com \
    --cc=airlied@linux.ie \
    --cc=corbet@lwn.net \
    --cc=daniels@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kraxel@redhat.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=shuah@kernel.org \
    --cc=tomeu.vizoso@collabora.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.