date:20160603

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

2016-06-03 Thread Aaron Conole

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 driver will read the advised MTU and use it as the initial
value.

Signed-off-by: Aaron Conole 
---
v2->v3:
* Added a check for the MTU, and a bit clear for it being out of range.

 drivers/net/virtio_net.c| 10 ++
 include/uapi/linux/virtio_net.h |  3 +++
 2 files changed, 13 insertions(+)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index e0638e5..192f321 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1780,6 +1780,7 @@ static int virtnet_probe(struct virtio_device *vdev)
struct net_device *dev;
struct virtnet_info *vi;
u16 max_queue_pairs;
+   int mtu;
 
if (!vdev->config->get) {
dev_err(&vdev->dev, "%s failure: config access disabled\n",
@@ -1896,6 +1897,14 @@ static int virtnet_probe(struct virtio_device *vdev)
if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
vi->has_cvq = true;
 
+   if (virtio_has_feature(vdev, VIRTIO_NET_F_MTU)) {
+   mtu = virtio_cread16(vdev,
+offsetof(struct virtio_net_config,
+ mtu));
+   if (virtnet_change_mtu(dev, mtu))
+   __virtio_clear_bit(vdev, VIRTIO_NET_F_MTU);
+   }
+
if (vi->any_header_sg)
dev->needed_headroom = vi->hdr_len;
 
@@ -2067,6 +2076,7 @@ static unsigned int features[] = {
VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ,
VIRTIO_NET_F_CTRL_MAC_ADDR,
VIRTIO_F_ANY_LAYOUT,
+   VIRTIO_NET_F_MTU,
 };
 
 static struct virtio_driver virtio_net_driver = {
diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
index ec32293..1ab4ea6 100644
--- a/include/uapi/linux/virtio_net.h
+++ b/include/uapi/linux/virtio_net.h
@@ -55,6 +55,7 @@
 #define VIRTIO_NET_F_MQ22  /* Device supports Receive Flow
 * Steering */
 #define VIRTIO_NET_F_CTRL_MAC_ADDR 23  /* Set MAC address */
+#define VIRTIO_NET_F_MTU 25/* Initial MTU advice */
 
 #ifndef VIRTIO_NET_NO_LEGACY
 #define VIRTIO_NET_F_GSO   6   /* Host handles pkts w/ any GSO type */
@@ -73,6 +74,8 @@ struct virtio_net_config {
 * Legal values are between 1 and 0x8000
 */
__u16 max_virtqueue_pairs;
+   /* Default maximum transmit unit advice */
+   __u16 mtu;
 } __attribute__((packed));
 
 /*
-- 
2.5.5

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

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

2016-06-03 Thread Daniel Vetter

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.
> > >
> > > On Thursday 02 Jun 2016 16:31:28 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 drm_atomic_helper_best_encoder().  
> > >
> > > Could you please update include/drm/drm_modeset_helper_vtables.h to 
> > > document
> > > this new behaviour ?  
> > 
> > Thanks for reminding me. Please update hooks for both
> > atomic_best_encoder and best_encoder. Also mention that it's only
> > optional for atomic drivers. There's lots of examples in that file for
> > the wording usually used.
> 
> Hm, I haven't changed anything for the ->atomic_best_encoder() hook, or
> am I missing something?

Before you needed atomic_best_encoder or best_encoder (well that's the
idea at least), now both are optional. Kerneldoc needs to be adjusted in
both places to match new reality after your patch.
-Daniel

> 
> > 
> > > The only drawback I see in this patch is the additional object lookup
> > > performed by drm_atomic_helper_best_encoder() at runtime. I wonder if we 
> > > could
> > > somehow cache the information, as the assignment can't change when 
> > > there's a
> > > 1:1 correspondence between encoders and connectors.  
> > 
> > drm_encoder_find is an idr lookup. That should be plenty fast,
> > especially for modeset code. Usually what's too expensive even for
> > modeset code is linear list walks. But Chris just submitted patches to
> > convert most of them into simple lookups.
> > -Daniel
> > 
> > >>> Signed-off-by: Boris Brezillon   
> > >> ---
> > >>  drivers/gpu/drm/drm_atomic_helper.c |  4 +++-
> > >>  drivers/gpu/drm/drm_fb_helper.c | 13 -
> > >>  2 files changed, 15 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > >> b/drivers/gpu/drm/drm_atomic_helper.c index f6a3350..849d029 100644
> > >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > >> @@ -300,8 +300,10 @@ update_connector_routing(struct drm_atomic_state
> > >> *state, if (funcs->atomic_best_encoder)
> > >>   new_encoder = funcs->atomic_best_encoder(connector,
> > >>connector_state);
> > >> - else
> > >> + else if (funcs->best_encoder)
> > >>   new_encoder = funcs->best_encoder(connector);
> > >> + else
> > >> + new_encoder = drm_atomic_helper_best_encoder(connector);
> > >>
> > >>   if (!new_encoder) {
> > >>   DRM_DEBUG_ATOMIC("No suitable encoder found for 
> > >> [CONNECTOR:%d:%s]\n",
> > >> diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > >> b/drivers/gpu/drm/drm_fb_helper.c index 7c2eb75..d44389a 100644
> > >> --- a/drivers/gpu/drm/drm_fb_helper.c
> > >> +++ b/drivers/gpu/drm/drm_fb_helper.c
> > >> @@ -2000,7 +2000,18 @@ static int drm_pick_crtcs(struct drm_fb_helper
> > >> *fb_helper, my_score++;
> > >>
> > >>   connector_funcs = connector->helper_private;
> > >> - encoder = 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->dev->mode_config.funcs->atomic_commit &&
> > >> + !connector_funcs->best_encoder)
> > >> + encoder = drm_atomic_helper_best_encoder(connector);
> > >> + else
> > >> + encoder = connector_funcs->best_encoder(connector);
> > >> +
> > >>   if (!encoder)
> > >>   goto out;  
> > >
> > > --
> > > Regards,
> > >
> > > Laurent Pinchart
> > >  
> > 
> > 
> > 
> 
> 
> 
> -- 
> Boris Brezillon, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

-- 
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

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

2016-06-03 Thread Michael S. Tsirkin

On Thu, Jun 02, 2016 at 05:10:59PM -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 driver will read the advised MTU and use it as the initial
> value.
> 
> Signed-off-by: Aaron Conole 
> ---
> v1->v2:
> * Fixed omitted hunk from virtio_net.h
> * Squashed to a single commit
> * Fixed commit message.
> 
>  drivers/net/virtio_net.c| 7 +++
>  include/uapi/linux/virtio_net.h | 3 +++
>  2 files changed, 10 insertions(+)
> 
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index e0638e5..ef5ee01 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1896,6 +1896,12 @@ static int virtnet_probe(struct virtio_device *vdev)
>   if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
>   vi->has_cvq = true;
>  
> + if (virtio_has_feature(vdev, VIRTIO_NET_F_MTU)) {
> + dev->mtu = virtio_cread16(vdev,
> +   offsetof(struct virtio_net_config,
> +mtu));
> + }
> +
>   if (vi->any_header_sg)
>   dev->needed_headroom = vi->hdr_len;
>  

One comment though: I think we should validate the mtu.
If it's invalid, clear VIRTIO_NET_F_MTU and ignore.

> @@ -2067,6 +2073,7 @@ static unsigned int features[] = {
>   VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ,
>   VIRTIO_NET_F_CTRL_MAC_ADDR,
>   VIRTIO_F_ANY_LAYOUT,
> + VIRTIO_NET_F_MTU,
>  };
>  
>  static struct virtio_driver virtio_net_driver = {
> diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
> index ec32293..1ab4ea6 100644
> --- a/include/uapi/linux/virtio_net.h
> +++ b/include/uapi/linux/virtio_net.h
> @@ -55,6 +55,7 @@
>  #define VIRTIO_NET_F_MQ  22  /* Device supports Receive Flow
>* Steering */
>  #define VIRTIO_NET_F_CTRL_MAC_ADDR 23/* Set MAC address */
> +#define VIRTIO_NET_F_MTU 25  /* Initial MTU advice */
>  
>  #ifndef VIRTIO_NET_NO_LEGACY
>  #define VIRTIO_NET_F_GSO 6   /* Host handles pkts w/ any GSO type */
> @@ -73,6 +74,8 @@ struct virtio_net_config {
>* Legal values are between 1 and 0x8000
>*/
>   __u16 max_virtqueue_pairs;
> + /* Default maximum transmit unit advice */
> + __u16 mtu;
>  } __attribute__((packed));
>  
>  /*
> -- 
> 2.5.5
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH V3 0/2] vhost_net polling optimization

2016-06-03 Thread Michael S. Tsirkin

On Thu, Jun 02, 2016 at 12:08:06PM -0700, David Miller wrote:
> From: Jason Wang 
> Date: Wed,  1 Jun 2016 01:56:32 -0400
> 
> > This series tries to optimize vhost_net polling at two points:
> > 
> > - Stop rx polling for reduicng the unnecessary wakeups during
> >   handle_rx().
> > - Conditonally enable tx polling for reducing the unnecessary
> >   traversing and spinlock touching.
> > 
> > Test shows about 17% improvement on rx pps.
> > 
> > Please review
> > 
> > Changes from V2:
> > - Don't enable rx vq if we meet an err or rx vq is empty
> > Changes from V1:
> > - use vhost_net_disable_vq()/vhost_net_enable_vq() instead of open
> >   coding.
> > - Add a new patch for conditionally enable tx polling.
> 
> Michael, please review this patch series.
> 
> Thanks.

thanks for the reminder, I plan to review next week.

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

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

2016-06-03 Thread Boris Brezillon

On Thu, 02 Jun 2016 23:57:14 +0300
Laurent Pinchart  wrote:

> Hi Boris,
> 
> Thank you for the patch.
> 
> On Thursday 02 Jun 2016 16:31:36 Boris Brezillon wrote:
> > 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 
> > ---
> >  drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 12 
> >  drivers/gpu/drm/rcar-du/rcar_du_encoder.h |  3 ---
> >  drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c |  1 -
> >  drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c |  1 -
> >  drivers/gpu/drm/rcar-du/rcar_du_vgacon.c  |  1 -
> >  5 files changed, 18 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c index 4e939e4..55149e9 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > @@ -27,18 +27,6 @@
> >  #include "rcar_du_vgacon.h"
> > 
> >  /*
> > ---
> > -- - * Common connector functions
> > - */
> > -
> > -struct drm_encoder *
> > -rcar_du_connector_best_encoder(struct drm_connector *connector)
> > -{
> > -   struct rcar_du_connector *rcon = to_rcar_connector(connector);
> > -
> > -   return rcar_encoder_to_drm_encoder(rcon->encoder);
> > -}
> > -
> > -/*
> > ---
> > -- * Encoder
> >   */
> > 
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
> > b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h index 719b6f2a..a8669c3 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
> > @@ -49,9 +49,6 @@ struct rcar_du_connector {
> >  #define to_rcar_connector(c) \
> > container_of(c, struct rcar_du_connector, connector)
> > 
> > -struct drm_encoder *
> > -rcar_du_connector_best_encoder(struct drm_connector *connector);
> > -
> >  int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> >  enum rcar_du_encoder_type type,
> >  enum rcar_du_output output,
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c index 6c92714..612b4d5 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c
> > @@ -52,7 +52,6 @@ static int rcar_du_hdmi_connector_mode_valid(struct
> > drm_connector *connector, static const struct drm_connector_helper_funcs
> > connector_helper_funcs = { .get_modes = rcar_du_hdmi_connector_get_modes,
> > .mode_valid = rcar_du_hdmi_connector_mode_valid,
> > -   .best_encoder = rcar_du_connector_best_encoder,
> >  };
> > 
> >  static enum drm_connector_status
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c index e905f5d..6afd0af 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
> > @@ -59,7 +59,6 @@ static int rcar_du_lvds_connector_get_modes(struct
> > drm_connector *connector)
> > 
> >  static const struct drm_connector_helper_funcs connector_helper_funcs = {
> > .get_modes = rcar_du_lvds_connector_get_modes,
> > -   .best_encoder = rcar_du_connector_best_encoder,
> >  };
> > 
> >  static enum drm_connector_status
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vgacon.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_vgacon.c index 9d7e5c9..68f7ffa 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_vgacon.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_vgacon.c
> > @@ -28,7 +28,6 @@ static int rcar_du_vga_connector_get_modes(struct
> > drm_connector *connector)
> > 
> >  static const struct drm_connector_helper_funcs connector_helper_funcs = {
> > .get_modes = rcar_du_vga_connector_get_modes,
> > -   .best_encoder = rcar_du_connector_best_encoder,
> >  };
> > 
> >  static enum drm_connector_status  
> 
> You can also remove
> 
> rcon->encoder = renc;
> 
> from rcar_du_vga_connector_init(), it's not needed anymore. The same code in 
> rcar_du_hdmi_connector_init() has to stay for now though, as it's used to 
> locate the slave encoder in the HDMI support code. That should change when 
> the 
> driver will be converted to use drm_bridge.
> 
> I can also fix this during the conversion to drm_bridge if you don't want to 
> resubmit. In any case,

There will be a v2 anyway, so I'll squash this change in the patch.

> 
> Reviewed-by: Laurent Pinchart 
> 

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

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

2016-06-03 Thread Boris Brezillon

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.
> >
> > On Thursday 02 Jun 2016 16:31:28 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 drm_atomic_helper_best_encoder().  
> >
> > Could you please update include/drm/drm_modeset_helper_vtables.h to document
> > this new behaviour ?  
> 
> Thanks for reminding me. Please update hooks for both
> atomic_best_encoder and best_encoder. Also mention that it's only
> optional for atomic drivers. There's lots of examples in that file for
> the wording usually used.

Hm, I haven't changed anything for the ->atomic_best_encoder() hook, or
am I missing something?

> 
> > The only drawback I see in this patch is the additional object lookup
> > performed by drm_atomic_helper_best_encoder() at runtime. I wonder if we 
> > could
> > somehow cache the information, as the assignment can't change when there's a
> > 1:1 correspondence between encoders and connectors.  
> 
> drm_encoder_find is an idr lookup. That should be plenty fast,
> especially for modeset code. Usually what's too expensive even for
> modeset code is linear list walks. But Chris just submitted patches to
> convert most of them into simple lookups.
> -Daniel
> 
> >>> Signed-off-by: Boris Brezillon   
> >> ---
> >>  drivers/gpu/drm/drm_atomic_helper.c |  4 +++-
> >>  drivers/gpu/drm/drm_fb_helper.c | 13 -
> >>  2 files changed, 15 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >> b/drivers/gpu/drm/drm_atomic_helper.c index f6a3350..849d029 100644
> >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> @@ -300,8 +300,10 @@ update_connector_routing(struct drm_atomic_state
> >> *state, if (funcs->atomic_best_encoder)
> >>   new_encoder = funcs->atomic_best_encoder(connector,
> >>connector_state);
> >> - else
> >> + else if (funcs->best_encoder)
> >>   new_encoder = funcs->best_encoder(connector);
> >> + else
> >> + new_encoder = drm_atomic_helper_best_encoder(connector);
> >>
> >>   if (!new_encoder) {
> >>   DRM_DEBUG_ATOMIC("No suitable encoder found for 
> >> [CONNECTOR:%d:%s]\n",
> >> diff --git a/drivers/gpu/drm/drm_fb_helper.c
> >> b/drivers/gpu/drm/drm_fb_helper.c index 7c2eb75..d44389a 100644
> >> --- a/drivers/gpu/drm/drm_fb_helper.c
> >> +++ b/drivers/gpu/drm/drm_fb_helper.c
> >> @@ -2000,7 +2000,18 @@ static int drm_pick_crtcs(struct drm_fb_helper
> >> *fb_helper, my_score++;
> >>
> >>   connector_funcs = connector->helper_private;
> >> - encoder = 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->dev->mode_config.funcs->atomic_commit &&
> >> + !connector_funcs->best_encoder)
> >> + encoder = drm_atomic_helper_best_encoder(connector);
> >> + else
> >> + encoder = connector_funcs->best_encoder(connector);
> >> +
> >>   if (!encoder)
> >>   goto out;  
> >
> > --
> > Regards,
> >
> > Laurent Pinchart
> >  
> 
> 
> 



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

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

2016-06-03 Thread Boris Brezillon

On Fri, 03 Jun 2016 00:05:46 +0300
Laurent Pinchart  wrote:

> Hi Boris,
> 
> Thank you for the patch.
> 
> On Thursday 02 Jun 2016 16:31:28 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 drm_atomic_helper_best_encoder().  
> 
> Could you please update include/drm/drm_modeset_helper_vtables.h to document 
> this new behaviour ?

Sure.

> 
> The only drawback I see in this patch is the additional object lookup 
> performed by drm_atomic_helper_best_encoder() at runtime. I wonder if we 
> could 
> somehow cache the information, as the assignment can't change when there's a 
> 1:1 correspondence between encoders and connectors.
> 
> > Signed-off-by: Boris Brezillon 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c |  4 +++-
> >  drivers/gpu/drm/drm_fb_helper.c | 13 -
> >  2 files changed, 15 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c index f6a3350..849d029 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -300,8 +300,10 @@ update_connector_routing(struct drm_atomic_state
> > *state, if (funcs->atomic_best_encoder)
> > new_encoder = funcs->atomic_best_encoder(connector,
> >  connector_state);
> > -   else
> > +   else if (funcs->best_encoder)
> > new_encoder = funcs->best_encoder(connector);
> > +   else
> > +   new_encoder = drm_atomic_helper_best_encoder(connector);
> > 
> > if (!new_encoder) {
> > DRM_DEBUG_ATOMIC("No suitable encoder found for 
> > [CONNECTOR:%d:%s]\n",
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c index 7c2eb75..d44389a 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -2000,7 +2000,18 @@ static int drm_pick_crtcs(struct drm_fb_helper
> > *fb_helper, my_score++;
> > 
> > connector_funcs = connector->helper_private;
> > -   encoder = 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->dev->mode_config.funcs->atomic_commit &&
> > +   !connector_funcs->best_encoder)
> > +   encoder = drm_atomic_helper_best_encoder(connector);
> > +   else
> > +   encoder = connector_funcs->best_encoder(connector);
> > +
> > if (!encoder)
> > goto out;  
> 



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v5 1/6] qspinlock: powerpc support qspinlock

2016-06-03 Thread xinhui




On 2016年06月03日 12:33, Benjamin Herrenschmidt wrote:

On Fri, 2016-06-03 at 12:10 +0800, xinhui wrote:

On 2016年06月03日 09:32, Benjamin Herrenschmidt wrote:

On Fri, 2016-06-03 at 11:32 +1000, Benjamin Herrenschmidt wrote:

On Thu, 2016-06-02 at 17:22 +0800, Pan Xinhui wrote:


Base code to enable qspinlock on powerpc. this patch add some
#ifdef
here and there. Although there is no paravirt related code, we

can

successfully build a qspinlock kernel after apply this patch.

This is missing the IO_SYNC stuff ... It means we'll fail to do a
full
sync to order vs MMIOs.

You need to add that back in the unlock path.


Well, and in the lock path as well...


Oh, yes. I missed IO_SYNC stuff.

thank you, Ben :)


Ok couple of other things that would be nice from my perspective (and
Michael's) if you can produce them:

  - Some benchmarks of the qspinlock alone, without the PV stuff,
so we understand how much of the overhead is inherent to the
qspinlock and how much is introduced by the PV bits.

  - For the above, can you show (or describe) where the qspinlock
improves things compared to our current locks. While there's
theory and to some extent practice on x86, it would be nice to
validate the effects on POWER.

  - Comparative benchmark with the PV stuff in on a bare metal system
to understand the overhead there.

  - Comparative benchmark with the PV stuff under pHyp and KVM


Will do such benchmark tests in next days.
thanks for your kind suggestions. :)


Spinlocks are fiddly and a critical piece of infrastructure, it's
important we fully understand the performance implications before we
decide to switch to a new model.


yes, We really need understand how {pv}qspinlock works in more complex cases.

thanks
xinhui

Cheers,
Ben.



___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

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

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

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

Re: [PATCH V3 0/2] vhost_net polling optimization

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

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

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

Re: [PATCH v5 1/6] qspinlock: powerpc support qspinlock

8 matches

Site Navigation

Mail list logo

Footer information