rs/virtio/virtio_vdpa.c | 2 +-
> include/linux/virtio_config.h| 11 +++
> 10 files changed, 19 insertions(+), 14 deletions(-)
I assume this will be merged through the virtio tree, here
is my ack for merging the drivers/platform/mellanox/ part
through the virtio tree:
Ac
c: Daniel Jordan
> Cc: Daniel Lezcano
> Cc: Dave Hansen
> Cc: Davidlohr Bueso
> Cc: "David S. Miller"
> Cc: Dietmar Eggemann
> Cc: Gonglei
> Cc: Greg Kroah-Hartman
> Cc: Guenter Roeck
> Cc: Hans de Goede
> Cc: Heiko Carstens
> Cc: Herbert Xu
Hi,
On 3/30/21 9:09 AM, Thomas Zimmermann wrote:
> Hi
>
> Am 29.03.21 um 16:50 schrieb Hans de Goede:
>> Hi,
>>
>> On 3/29/21 2:31 PM, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 25.03.21 um 12:29 schrieb Hans de Goede:
>>&
Hi,
On 3/29/21 2:31 PM, Thomas Zimmermann wrote:
> Hi
>
> Am 25.03.21 um 12:29 schrieb Hans de Goede:
>> Hi,
>>
>> On 3/18/21 11:29 AM, Thomas Zimmermann wrote:
>>> This patchset adds support for simple-framebuffer platform devices and
>>> a hando
Hi,
On 3/18/21 11:29 AM, Thomas Zimmermann wrote:
> This patchset adds support for simple-framebuffer platform devices and
> a handover mechanism for native drivers to take-over control of the
> hardware.
>
> The new driver, called simpledrm, binds to a simple-frambuffer platform
> device. The
Hi Tom,
Quick self intro: I have take over drivers/platform/x86
maintainership from Andy.
On 10/17/20 6:09 PM, t...@redhat.com wrote:
> From: Tom Rix
>
> This is a upcoming change to clean up a new warning treewide.
> I am wondering if the change could be one mega patch (see below) or
> normal
:
Reviewed-by: Hans de Goede
Regards,
Hans
Thomas Zimmermann (4):
drm: Document struct drm_crtc_state.no_vblank for faking VBLANK events
drm/ast: Set struct drm_crtc_state.no_vblank in atomic_check()
drm/cirrus: Let DRM core send VBLANK events
drm/simple-kms: Let DRM core send
Hi,
On 08-04-19 11:21, Thomas Zimmermann wrote:
Signed-off-by: Thomas Zimmermann
Patch looks good to me (although perhaps it needs a commit msg):
Reviewed-by: Hans de Goede
Regards,
Hans
---
drivers/gpu/drm/vboxvideo/Kconfig| 1 +
drivers/gpu/drm/vboxvideo/vbox_drv.h | 6
Zimmermann
Nice cleanup, thank you, patch looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
---
drivers/gpu/drm/vboxvideo/Kconfig | 1 +
drivers/gpu/drm/vboxvideo/vbox_drv.c | 5 +-
drivers/gpu/drm/vboxvideo/vbox_drv.h | 58 +--
drivers/gpu/drm/vboxvideo/vbox_fb.c
Hi,
On 11-03-19 17:51, Christian König wrote:
Am 11.03.19 um 17:39 schrieb Hans de Goede:
Hi,
On 07-02-19 09:59, Thomas Zimmermann wrote:
Almost all TTM-based drivers use the same values for the mmap-able
range of BO addresses. Each driver therefore duplicates the
DRM_FILE_PAGE_OFFSET
Hi,
On 07-02-19 09:59, Thomas Zimmermann wrote:
Almost all TTM-based drivers use the same values for the mmap-able
range of BO addresses. Each driver therefore duplicates the
DRM_FILE_PAGE_OFFSET constant. OTOH, the mmap range's size is not
configurable by drivers.
This patch set replaces
file_page_offset parameter from ttm_bo_device_init()
drm/ttm: Quick-test mmap offset in ttm_bo_mmap()
drm: Use the same mmap-range offset and size for GEM and TTM
The first patch looks good to me:
Reviewed-by: Hans de Goede
The vboxvideo bits in the other patches look good to me to:
Acked
Acked-by: Hans de Goede hdego...@redhat.com
On 01/31/2011 08:36 AM, Amit Shah wrote:
The outvq needs to be woken up on host notifications so that buffers
consumed by the host can be reclaimed, outvq freed, and application
writes may proceed again.
The need for this is now finally noticed
Hi,
On 10/19/2010 07:45 AM, Amit Shah wrote:
If the host is slow in reading data or doesn't read data at all,
blocking write calls not only blocked the program that called write()
but the entire guest itself.
To overcome this, let's not block till the host signals it has given
back the
Hi,
Ok replying to my own reply, because I misread the code.
On 10/19/2010 08:55 AM, Hans de Goede wrote:
Hi,
On 10/19/2010 07:45 AM, Amit Shah wrote:
If the host is slow in reading data or doesn't read data at all,
blocking write calls not only blocked the program that called write
Hi,
On 10/19/2010 09:32 AM, Amit Shah wrote:
On (Tue) Oct 19 2010 [09:23:00], Hans de Goede wrote:
3) This patch will cause processes filling the virtqueue fast enough to
block
to never wake up again, due to a missing waitqueue wakeup, see:
https://bugzilla.redhat.com/show_bug.cgi
, port-inbuf
will be NULL even though there may be buffers left in the virtqueue.
This causes poll() to block even though there is data ready to be read, this
patch fixes this by using port_has_data(port) instead of the
port-inbuf != NULL check.
Signed-off-By: Hans de Goede hdego...@redhat.com
Regards
, port-inbuf
will be NULL even though there may be buffers left in the virtqueue.
This causes poll() to block even though there is data to be read, this patch
fixes this by using the alredy defined will_read_block utility function
instead of the port-inbuf != NULL check.
Signed-off-By: Hans de Goede
Hi,
On 09/15/2010 03:46 PM, Amit Shah wrote:
On (Wed) Sep 15 2010 [15:37:21], Hans de Goede wrote:
--- linux-2.6.35.x86_64/drivers/char/virtio_console.c~ 2010-08-02
00:11:14.0 +0200
+++ linux-2.6.35.x86_64/drivers/char/virtio_console.c 2010-09-15
13:39:29.043505000 +0200
Hi,
On 09/15/2010 03:25 PM, Amit Shah wrote:
On (Wed) Sep 15 2010 [15:04:53], Hans de Goede wrote:
Hi All,
I found this while working on a Linux agent for spice, the symptom I was
seeing was select blocking on the spice vdagent virtio serial port even
though there were messages queued up
20 matches
Mail list logo
