Re: [PATCH RESEND 06/14] drm/virtio: use drm_crtc_send_vblank_event()

2016-06-07 Thread Gerd Hoffmann
On Mo, 2016-06-06 at 11:41 -0300, Gustavo Padovan wrote: > From: Gustavo Padovan > > Replace the legacy drm_send_vblank_event() with the new helper function. > > Signed-off-by: Gustavo Padovan > --- >

[PATCH] vhost/scsi: fix reuse of >iov[out] in response

2016-06-07 Thread Benjamin Coddington
The address of the iovec >iov[out] is not guaranteed to contain the scsi command's response iovec throughout the lifetime of the command. Rather, it is more likely to contain an iovec from an immediately following command after looping back around to vhost_get_vq_desc(). Pass along the iovec

Re: [PATCH v3] virtio-net: Add initial MTU advice feature

2016-06-07 Thread Michael S. Tsirkin
On Fri, Jun 03, 2016 at 04:57:12PM -0400, Aaron Conole wrote: > This commit adds the feature bit and associated mtu device entry for the > virtio network device. When a virtio device comes up, it checks the > feature bit for the VIRTIO_NET_F_MTU feature. If such feature bit is > enabled, the

Re: [PATCH V3 1/2] vhost_net: stop polling socket during rx processing

2016-06-07 Thread David Miller
From: Jason Wang Date: Wed, 1 Jun 2016 01:56:33 -0400 > We don't stop rx polling socket during rx processing, this will lead > unnecessary wakeups from under layer net devices (E.g > sock_def_readable() form tun). Rx will be slowed down in this > way. This patch avoids this

[PATCH v2 00/20] drm/atomic: Provide default ->best_encoder() behavior

2016-06-07 Thread Boris Brezillon
Hello, This patch series aims at replacing all dummy ->best_encoder() implementations where we have a 1:1 relationship between encoders and connectors. The core already provides the drm_atomic_helper_best_encoder() function which is taking the first encoder attached to the connector (after making

[PATCH v2 01/20] drm/atomic: Fix remaining places where !funcs->best_encoder is valid

2016-06-07 Thread Boris Brezillon
Adapt drm_pick_crtcs() and update_connector_routing() to fallback to drm_atomic_helper_best_encoder() if funcs->best_encoder() is NULL so that DRM drivers can leave this hook unassigned if they know they want to use drm_atomic_helper_best_encoder(). Update the vtables documentation accordingly.

[PATCH v2 06/20] drm: i915: Rely on the default ->best_encoder() behavior where appropriate

2016-06-07 Thread Boris Brezillon
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: we can drop the custom ->best_encoder() implementation and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon

[PATCH v2 03/20] drm: atmel-hlcdc: Rely on the default ->best_encoder() behavior

2016-06-07 Thread Boris Brezillon
We have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon ---

[PATCH v2 02/20] drm: arc: Rely on the default ->best_encoder() behavior

2016-06-07 Thread Boris Brezillon
We have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder(), and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon ---

[PATCH v2 05/20] drm: fsl-dcu: Rely on the default ->best_encoder() behavior

2016-06-07 Thread Boris Brezillon
We have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon ---

[PATCH v2 09/20] drm: rcar-du: Rely on the default ->best_encoder() behavior

2016-06-07 Thread Boris Brezillon
All outputs have a 1:1 relationship between connectors and encoders, and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementations and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon

[PATCH v2 04/20] drm: exynos: Rely on the default ->best_encoder() behavior

2016-06-07 Thread Boris Brezillon
We have 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementations and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon ---

[PATCH v2 11/20] drm: sti: Rely on the default ->best_encoder() behavior

2016-06-07 Thread Boris Brezillon
All outputs have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementations and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon

[PATCH v2 10/20] drm: rockchip: Rely on the default ->best_encoder() behavior

2016-06-07 Thread Boris Brezillon
All outputs have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementations and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon

[PATCH v2 12/20] drm: sun4i: Rely on the default ->best_encoder() behavior

2016-06-07 Thread Boris Brezillon
All outputs have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementations and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon

Re: [PATCH V3 2/2] vhost_net: conditionally enable tx polling

2016-06-07 Thread Michael S. Tsirkin
On Wed, Jun 01, 2016 at 01:56:34AM -0400, Jason Wang wrote: > We always poll tx for socket, this is sub optimal since: > > - it will be only used when we exceed the sndbuf of the socket. > - since we use two independent polls for tx and vq, this will slightly > increase the waitqueue traversing

[PATCH v2 16/20] drm: omap: Rely on the default ->best_encoder() behavior

2016-06-07 Thread Boris Brezillon
We have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementation and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon

[PATCH v2 13/20] drm: tegra: Rely on the default ->best_encoder() behavior

2016-06-07 Thread Boris Brezillon
All outputs have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementation and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon

[PATCH v2 17/20] drm/bridge: anx78xx: Rely on the default ->best_encoder() behavior

2016-06-07 Thread Boris Brezillon
We have a 1:1 relationship between connectors and encoders, and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder(), and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon ---

[PATCH v2 08/20] drm: msm: Rely on the default ->best_encoder() behavior where appropriate

2016-06-07 Thread Boris Brezillon
For all outputs except DSI we have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon

[PATCH v2 19/20] drm/bridge: ps8622: Rely on the default ->best_encoder() behavior

2016-06-07 Thread Boris Brezillon
We have a 1:1 relationship between connectors and encoders, and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder(), and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon ---

[PATCH v2 20/20] drm/bridge: dw-hdmi: Use drm_atomic_helper_best_encoder()

2016-06-07 Thread Boris Brezillon
We have a 1:1 relationship between connectors and encoders, which means we can rely on the drm_atomic_helper_best_encoder() behavior. We still have to explicitly assign ->best_encoder() to drm_atomic_helper_best_encoder(), because the automated fallback to drm_atomic_helper_best_encoder() when

[PATCH v2 18/20] drm/bridge: ptn3460: Rely on the default ->best_encoder() behavior

2016-06-07 Thread Boris Brezillon
We have a 1:1 relationship between connectors and encoders, and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder(), and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon ---

[PATCH v2 14/20] drm: vc4: Rely on the default ->best_encoder() behavior

2016-06-07 Thread Boris Brezillon
All outputs have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementations and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon

Re: [PATCH V3 1/2] vhost_net: stop polling socket during rx processing

2016-06-07 Thread Michael S. Tsirkin
On Wed, Jun 01, 2016 at 01:56:33AM -0400, Jason Wang wrote: > We don't stop rx polling socket during rx processing, this will lead > unnecessary wakeups from under layer net devices (E.g > sock_def_readable() form tun). Rx will be slowed down in this > way. This patch avoids this by stop polling

Re: [PATCH v2 01/20] drm/atomic: Fix remaining places where !funcs->best_encoder is valid

2016-06-07 Thread Daniel Vetter
On Tue, Jun 07, 2016 at 01:47:56PM +0200, Boris Brezillon wrote: > Adapt drm_pick_crtcs() and update_connector_routing() to fallback to > drm_atomic_helper_best_encoder() if funcs->best_encoder() is NULL so > that DRM drivers can leave this hook unassigned if they know they want > to use