* [PATCH v2 04/20] drm: exynos: Rely on the default ->best_encoder() behavior
From: Boris Brezillon @ 2016-06-07 11:47 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, dri-devel, Daniel Vetter
Cc: Krzysztof Kozlowski, Heiko Stuebner, Stefan Agner, virtualization,
Eric Anholt, Thierry Reding, Laurent Pinchart, Benjamin Gaignard,
Alexandre Courbot, linux-samsung-soc, Joonyoung Shim,
Boris Brezillon, Alexey Brodkin, Kyungmin Park, linux-rockchip,
Chen-Yu Tsai, Kukjin Kim, linux-tegra, Stephen Warren,
linux-arm-msm, intel-gfx, Jani Nikula, Inki Dae
In-Reply-To: <1465300095-16971-1-git-send-email-boris.brezillon@free-electrons.com>
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 <boris.brezillon@free-electrons.com>
---
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 9 ---------
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 9 ---------
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 8 --------
drivers/gpu/drm/exynos/exynos_hdmi.c | 8 --------
4 files changed, 34 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 5e38e74..ad6b73c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -93,17 +93,8 @@ static int exynos_dpi_get_modes(struct drm_connector *connector)
return 0;
}
-static struct drm_encoder *
-exynos_dpi_best_encoder(struct drm_connector *connector)
-{
- struct exynos_dpi *ctx = connector_to_dpi(connector);
-
- return &ctx->encoder;
-}
-
static const struct drm_connector_helper_funcs exynos_dpi_connector_helper_funcs = {
.get_modes = exynos_dpi_get_modes,
- .best_encoder = exynos_dpi_best_encoder,
};
static int exynos_dpi_create_connector(struct drm_encoder *encoder)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 601ecf8..e07cb1f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1566,17 +1566,8 @@ static int exynos_dsi_get_modes(struct drm_connector *connector)
return 0;
}
-static struct drm_encoder *
-exynos_dsi_best_encoder(struct drm_connector *connector)
-{
- struct exynos_dsi *dsi = connector_to_dsi(connector);
-
- return &dsi->encoder;
-}
-
static const struct drm_connector_helper_funcs exynos_dsi_connector_helper_funcs = {
.get_modes = exynos_dsi_get_modes,
- .best_encoder = exynos_dsi_best_encoder,
};
static int exynos_dsi_create_connector(struct drm_encoder *encoder)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 608b0af..e8f6c92 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -378,16 +378,8 @@ static int vidi_get_modes(struct drm_connector *connector)
return drm_add_edid_modes(connector, edid);
}
-static struct drm_encoder *vidi_best_encoder(struct drm_connector *connector)
-{
- struct vidi_context *ctx = ctx_from_connector(connector);
-
- return &ctx->encoder;
-}
-
static const struct drm_connector_helper_funcs vidi_connector_helper_funcs = {
.get_modes = vidi_get_modes,
- .best_encoder = vidi_best_encoder,
};
static int vidi_create_connector(struct drm_encoder *encoder)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 58de5a4..1625d7c 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -937,17 +937,9 @@ static int hdmi_mode_valid(struct drm_connector *connector,
return MODE_OK;
}
-static struct drm_encoder *hdmi_best_encoder(struct drm_connector *connector)
-{
- struct hdmi_context *hdata = connector_to_hdmi(connector);
-
- return &hdata->encoder;
-}
-
static const struct drm_connector_helper_funcs hdmi_connector_helper_funcs = {
.get_modes = hdmi_get_modes,
.mode_valid = hdmi_mode_valid,
- .best_encoder = hdmi_best_encoder,
};
static int hdmi_create_connector(struct drm_encoder *encoder)
--
2.7.4
^ permalink raw reply related
* [PATCH v2 03/20] drm: atmel-hlcdc: Rely on the default ->best_encoder() behavior
From: Boris Brezillon @ 2016-06-07 11:47 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, dri-devel, Daniel Vetter
Cc: Krzysztof Kozlowski, Heiko Stuebner, Stefan Agner, virtualization,
Eric Anholt, Thierry Reding, Laurent Pinchart, Benjamin Gaignard,
Alexandre Courbot, linux-samsung-soc, Joonyoung Shim,
Boris Brezillon, Alexey Brodkin, Kyungmin Park, linux-rockchip,
Chen-Yu Tsai, Kukjin Kim, linux-tegra, Stephen Warren,
linux-arm-msm, intel-gfx, Jani Nikula, Inki Dae
In-Reply-To: <1465300095-16971-1-git-send-email-boris.brezillon@free-electrons.com>
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 <boris.brezillon@free-electrons.com>
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 12 ------------
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index 3d34fc4..6119b50 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -113,21 +113,9 @@ static int atmel_hlcdc_rgb_mode_valid(struct drm_connector *connector,
return atmel_hlcdc_dc_mode_valid(rgb->dc, mode);
}
-
-
-static struct drm_encoder *
-atmel_hlcdc_rgb_best_encoder(struct drm_connector *connector)
-{
- struct atmel_hlcdc_rgb_output *rgb =
- drm_connector_to_atmel_hlcdc_rgb_output(connector);
-
- return &rgb->encoder;
-}
-
static const struct drm_connector_helper_funcs atmel_hlcdc_panel_connector_helper_funcs = {
.get_modes = atmel_hlcdc_panel_get_modes,
.mode_valid = atmel_hlcdc_rgb_mode_valid,
- .best_encoder = atmel_hlcdc_rgb_best_encoder,
};
static enum drm_connector_status
--
2.7.4
^ permalink raw reply related
* [PATCH v2 02/20] drm: arc: Rely on the default ->best_encoder() behavior
From: Boris Brezillon @ 2016-06-07 11:47 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, dri-devel, Daniel Vetter
Cc: Krzysztof Kozlowski, Heiko Stuebner, Stefan Agner, virtualization,
Eric Anholt, Thierry Reding, Laurent Pinchart, Benjamin Gaignard,
Alexandre Courbot, linux-samsung-soc, Joonyoung Shim,
Boris Brezillon, Alexey Brodkin, Kyungmin Park, linux-rockchip,
Chen-Yu Tsai, Kukjin Kim, linux-tegra, Stephen Warren,
linux-arm-msm, intel-gfx, Jani Nikula, Inki Dae
In-Reply-To: <1465300095-16971-1-git-send-email-boris.brezillon@free-electrons.com>
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 <boris.brezillon@free-electrons.com>
---
drivers/gpu/drm/arc/arcpgu_hdmi.c | 18 ------------------
1 file changed, 18 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_hdmi.c b/drivers/gpu/drm/arc/arcpgu_hdmi.c
index 08b6bae..b7a8b2a 100644
--- a/drivers/gpu/drm/arc/arcpgu_hdmi.c
+++ b/drivers/gpu/drm/arc/arcpgu_hdmi.c
@@ -46,23 +46,6 @@ static int arcpgu_drm_connector_get_modes(struct drm_connector *connector)
return sfuncs->get_modes(&slave->base, connector);
}
-struct drm_encoder *
-arcpgu_drm_connector_best_encoder(struct drm_connector *connector)
-{
- struct drm_encoder_slave *slave;
- struct arcpgu_drm_connector *con =
- container_of(connector, struct arcpgu_drm_connector, connector);
-
- slave = con->encoder_slave;
- if (slave == NULL) {
- dev_err(connector->dev->dev,
- "connector_best_encoder: cannot find slave encoder for connector\n");
- return NULL;
- }
-
- return &slave->base;
-}
-
static enum drm_connector_status
arcpgu_drm_connector_detect(struct drm_connector *connector, bool force)
{
@@ -97,7 +80,6 @@ static void arcpgu_drm_connector_destroy(struct drm_connector *connector)
static const struct drm_connector_helper_funcs
arcpgu_drm_connector_helper_funcs = {
.get_modes = arcpgu_drm_connector_get_modes,
- .best_encoder = arcpgu_drm_connector_best_encoder,
};
static const struct drm_connector_funcs arcpgu_drm_connector_funcs = {
--
2.7.4
^ permalink raw reply related
* [PATCH v2 01/20] drm/atomic: Fix remaining places where !funcs->best_encoder is valid
From: Boris Brezillon @ 2016-06-07 11:47 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, dri-devel, Daniel Vetter
Cc: Krzysztof Kozlowski, Heiko Stuebner, Stefan Agner, virtualization,
Eric Anholt, Thierry Reding, Laurent Pinchart, Benjamin Gaignard,
Alexandre Courbot, linux-samsung-soc, Joonyoung Shim,
Boris Brezillon, Alexey Brodkin, Kyungmin Park, linux-rockchip,
Chen-Yu Tsai, Kukjin Kim, linux-tegra, Stephen Warren,
linux-arm-msm, intel-gfx, Jani Nikula, Inki Dae
In-Reply-To: <1465300095-16971-1-git-send-email-boris.brezillon@free-electrons.com>
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.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
drivers/gpu/drm/drm_atomic_helper.c | 4 +++-
drivers/gpu/drm/drm_fb_helper.c | 13 ++++++++++++-
include/drm/drm_modeset_helper_vtables.h | 10 ++++++++--
3 files changed, 23 insertions(+), 4 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;
diff --git a/include/drm/drm_modeset_helper_vtables.h b/include/drm/drm_modeset_helper_vtables.h
index d4619dc..4e7a53b 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -736,6 +736,11 @@ struct drm_connector_helper_funcs {
* inspect dynamic configuration state should instead use
* @atomic_best_encoder.
*
+ * You can leave this function to NULL if the connector is only
+ * attached to a single encoder and you are using the atomic helpers.
+ * In this case, the core will call drm_atomic_helper_best_encoder()
+ * for you.
+ *
* RETURNS:
*
* Encoder that should be used for the given connector and connector
@@ -752,8 +757,9 @@ struct drm_connector_helper_funcs {
* need to select the best encoder depending upon the desired
* configuration and can't select it statically.
*
- * This function is used by drm_atomic_helper_check_modeset() and either
- * this or @best_encoder is required.
+ * This function is used by drm_atomic_helper_check_modeset().
+ * If it is not implemented, the core will fallback to @best_encoder
+ * (or drm_atomic_helper_best_encoder() if @best_encoder is NULL).
*
* NOTE:
*
--
2.7.4
^ permalink raw reply related
* [PATCH v2 00/20] drm/atomic: Provide default ->best_encoder() behavior
From: Boris Brezillon @ 2016-06-07 11:47 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, dri-devel, Daniel Vetter
Cc: Krzysztof Kozlowski, Heiko Stuebner, Stefan Agner, virtualization,
Eric Anholt, Thierry Reding, Laurent Pinchart, Benjamin Gaignard,
Alexandre Courbot, linux-samsung-soc, Joonyoung Shim,
Boris Brezillon, Alexey Brodkin, Kyungmin Park, linux-rockchip,
Chen-Yu Tsai, Kukjin Kim, linux-tegra, Stephen Warren,
linux-arm-msm, intel-gfx, Jani Nikula, Inki Dae
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 sure only one encoder was attached to the
connector), but it's not automatically used, and drivers wanting
to rely on this default behavior have to explicitly assign their
->best_encoder() hook to drm_atomic_helper_best_encoder().
The first patch fixes remaining places where
drm_atomic_helper_best_encoder() should be called when ->best_encoder()
is NULL, so that drivers using the atomic helpers can get rid of the
explicit ->best_encoder assignment if they need to rely on the default
drm_atomic_helper_best_encoder() implementation.
The following patches are killing all open coded ->best_encoder()
implementations that could be replaced by
drm_atomic_helper_best_encoder().
All modifications have been compile tested except for the changed on
the intel driver.
I've also tested on an atmel board, but I recommend waiting for DRM
driver maintainers feedback before applying the associated changes.
Note that once patch 1 is applied, the other patches can be applied
independently.
Best Regards,
Boris
Changes since v1:
- remove useless ->encoder backpointers in some implementations
- documented the default behavior in the vtable doc
- added R-b/A-b tags
Boris Brezillon (20):
drm/atomic: Fix remaining places where !funcs->best_encoder is valid
drm: arc: Rely on the default ->best_encoder() behavior
drm: atmel-hlcdc: Rely on the default ->best_encoder() behavior
drm: exynos: Rely on the default ->best_encoder() behavior
drm: fsl-dcu: Rely on the default ->best_encoder() behavior
drm: i915: Rely on the default ->best_encoder() behavior where
appropriate
drm: mediatek: Rely on the default ->best_encoder() behavior
drm: msm: Rely on the default ->best_encoder() behavior where
appropriate
drm: rcar-du: Rely on the default ->best_encoder() behavior
drm: rockchip: Rely on the default ->best_encoder() behavior
drm: sti: Rely on the default ->best_encoder() behavior
drm: sun4i: Rely on the default ->best_encoder() behavior
drm: tegra: Rely on the default ->best_encoder() behavior
drm: vc4: Rely on the default ->best_encoder() behavior
drm: virtgpu: Rely on the default ->best_encoder() behavior
drm: omap: Rely on the default ->best_encoder() behavior
drm/bridge: anx78xx: Rely on the default ->best_encoder() behavior
drm/bridge: ptn3460: Rely on the default ->best_encoder() behavior
drm/bridge: ps8622: Rely on the default ->best_encoder() behavior
drm/bridge: dw-hdmi: Use drm_atomic_helper_best_encoder()
drivers/gpu/drm/arc/arcpgu_hdmi.c | 18 ------------------
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 12 ------------
drivers/gpu/drm/bridge/analogix-anx78xx.c | 8 --------
drivers/gpu/drm/bridge/dw-hdmi.c | 11 +----------
drivers/gpu/drm/bridge/nxp-ptn3460.c | 8 --------
drivers/gpu/drm/bridge/parade-ps8622.c | 10 ----------
drivers/gpu/drm/drm_atomic_helper.c | 4 +++-
drivers/gpu/drm/drm_fb_helper.c | 13 ++++++++++++-
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 9 ---------
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 9 ---------
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 8 --------
drivers/gpu/drm/exynos/exynos_hdmi.c | 8 --------
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 9 ---------
drivers/gpu/drm/i915/intel_crt.c | 1 -
drivers/gpu/drm/i915/intel_display.c | 8 --------
drivers/gpu/drm/i915/intel_dp.c | 1 -
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_dsi.c | 1 -
drivers/gpu/drm/i915/intel_dvo.c | 1 -
drivers/gpu/drm/i915/intel_hdmi.c | 1 -
drivers/gpu/drm/i915/intel_lvds.c | 1 -
drivers/gpu/drm/i915/intel_sdvo.c | 1 -
drivers/gpu/drm/i915/intel_tv.c | 1 -
drivers/gpu/drm/mediatek/mtk_dsi.c | 9 ---------
drivers/gpu/drm/msm/edp/edp_connector.c | 10 ----------
drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 8 --------
drivers/gpu/drm/msm/mdp/mdp4/mdp4_lvds_connector.c | 9 ---------
drivers/gpu/drm/omapdrm/omap_connector.c | 10 ----------
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 | 3 ---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 9 ---------
drivers/gpu/drm/rockchip/inno_hdmi.c | 9 ---------
drivers/gpu/drm/sti/sti_dvo.c | 10 ----------
drivers/gpu/drm/sti/sti_hda.c | 10 ----------
drivers/gpu/drm/sti/sti_hdmi.c | 10 ----------
drivers/gpu/drm/sun4i/sun4i_rgb.c | 10 ----------
drivers/gpu/drm/sun4i/sun4i_tv.c | 9 ---------
drivers/gpu/drm/tegra/drm.h | 2 --
drivers/gpu/drm/tegra/dsi.c | 1 -
drivers/gpu/drm/tegra/hdmi.c | 1 -
drivers/gpu/drm/tegra/output.c | 8 --------
drivers/gpu/drm/tegra/rgb.c | 1 -
drivers/gpu/drm/tegra/sor.c | 1 -
drivers/gpu/drm/vc4/vc4_dpi.c | 9 ---------
drivers/gpu/drm/vc4/vc4_hdmi.c | 9 ---------
drivers/gpu/drm/virtio/virtgpu_display.c | 10 ----------
include/drm/drm_modeset_helper_vtables.h | 10 ++++++++--
50 files changed, 24 insertions(+), 305 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH v3] virtio-net: Add initial MTU advice feature
From: Michael S. Tsirkin @ 2016-06-07 9:21 UTC (permalink / raw)
To: Aaron Conole; +Cc: netdev, linux-kernel, virtualization
In-Reply-To: <1464987432-1458-1-git-send-email-aconole@redhat.com>
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 driver will read the advised MTU and use it as the initial
> value.
>
> Signed-off-by: Aaron Conole <aconole@redhat.com>
> ---
> 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_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 */
Oops I just notices this conflicts with virtio spec which says
devices must only use features up to 24.
Please post a follow-up patch changing this to bit 3.
> @@ -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
^ permalink raw reply
* Re: [PATCH RESEND 06/14] drm/virtio: use drm_crtc_send_vblank_event()
From: Gerd Hoffmann @ 2016-06-07 8:39 UTC (permalink / raw)
To: Gustavo Padovan
Cc: David Airlie, Gustavo Padovan, open list, dri-devel,
open list:VIRTIO GPU DRIVER
In-Reply-To: <1465224105-21485-6-git-send-email-gustavo@padovan.org>
On Mo, 2016-06-06 at 11:41 -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>
> Replace the legacy drm_send_vblank_event() with the new helper function.
>
> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> ---
> drivers/gpu/drm/virtio/virtgpu_display.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c
> index d4305da..ba5e11b 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> @@ -156,7 +156,7 @@ static int virtio_gpu_page_flip(struct drm_crtc *crtc,
>
> if (event) {
> spin_lock_irqsave(&crtc->dev->event_lock, irqflags);
> - drm_send_vblank_event(crtc->dev, -1, event);
> + drm_crtc_send_vblank_event(crtc, event);
> spin_unlock_irqrestore(&crtc->dev->event_lock, irqflags);
> }
Daniel Vetter has a series in flight which drops the whole
virtio_gpu_page_flip function in favor of drm_atomic_helper_page_flip.
https://lists.freedesktop.org/archives/dri-devel/2016-May/108699.html
cheers,
Gerd
^ permalink raw reply
* Re: [PATCH v3] virtio-net: Add initial MTU advice feature
From: David Miller @ 2016-06-07 1:10 UTC (permalink / raw)
To: aconole; +Cc: netdev, mst, linux-kernel, virtualization
In-Reply-To: <1464987432-1458-1-git-send-email-aconole@redhat.com>
From: Aaron Conole <aconole@redhat.com>
Date: Fri, 3 Jun 2016 16:57:12 -0400
> 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 <aconole@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 10/20] drm: rockchip: Rely on the default ->best_encoder() behavior
From: Mark yao @ 2016-06-07 0:51 UTC (permalink / raw)
To: Boris Brezillon, David Airlie, Daniel Vetter, dri-devel,
Daniel Vetter
Cc: Krzysztof Kozlowski, Heiko Stuebner, Stefan Agner, virtualization,
Eric Anholt, Thierry Reding, Laurent Pinchart, Benjamin Gaignard,
Alexandre Courbot, linux-samsung-soc, Joonyoung Shim,
Alexey Brodkin, Kyungmin Park, linux-rockchip, Chen-Yu Tsai,
Kukjin Kim, linux-tegra, Stephen Warren, linux-arm-msm, intel-gfx,
Jani Nikula, Inki Dae, linux-mediatek, Matthi
In-Reply-To: <1464877907-27723-11-git-send-email-boris.brezillon@free-electrons.com>
On 2016年06月02日 22:31, Boris Brezillon wrote:
> All outputss 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.
Good, All connectors and encoders is 1:1 relationship on rockchip
outputs, so
Acked-by: Mark Yao <mark.yao@rock-chips.com>
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 9 ---------
> drivers/gpu/drm/rockchip/inno_hdmi.c | 9 ---------
> 2 files changed, 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index dedc65b..ca22e5e 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -964,18 +964,9 @@ static enum drm_mode_status dw_mipi_dsi_mode_valid(
> return mode_status;
> }
>
> -static struct drm_encoder *dw_mipi_dsi_connector_best_encoder(
> - struct drm_connector *connector)
> -{
> - struct dw_mipi_dsi *dsi = con_to_dsi(connector);
> -
> - return &dsi->encoder;
> -}
> -
> static struct drm_connector_helper_funcs dw_mipi_dsi_connector_helper_funcs = {
> .get_modes = dw_mipi_dsi_connector_get_modes,
> .mode_valid = dw_mipi_dsi_mode_valid,
> - .best_encoder = dw_mipi_dsi_connector_best_encoder,
> };
>
> static enum drm_connector_status
> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
> index f8b4feb..006260d 100644
> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
> @@ -579,14 +579,6 @@ inno_hdmi_connector_mode_valid(struct drm_connector *connector,
> return MODE_OK;
> }
>
> -static struct drm_encoder *
> -inno_hdmi_connector_best_encoder(struct drm_connector *connector)
> -{
> - struct inno_hdmi *hdmi = to_inno_hdmi(connector);
> -
> - return &hdmi->encoder;
> -}
> -
> static int
> inno_hdmi_probe_single_connector_modes(struct drm_connector *connector,
> uint32_t maxX, uint32_t maxY)
> @@ -613,7 +605,6 @@ static struct drm_connector_funcs inno_hdmi_connector_funcs = {
> static struct drm_connector_helper_funcs inno_hdmi_connector_helper_funcs = {
> .get_modes = inno_hdmi_connector_get_modes,
> .mode_valid = inno_hdmi_connector_mode_valid,
> - .best_encoder = inno_hdmi_connector_best_encoder,
> };
>
> static int inno_hdmi_register(struct drm_device *drm, struct inno_hdmi *hdmi)
--
Mark Yao
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PATCH] vhost/scsi: fix reuse of &vq->iov[out] in response
From: Benjamin Coddington @ 2016-06-06 22:01 UTC (permalink / raw)
To: virtualization; +Cc: Michael S. Tsirkin
The address of the iovec &vq->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
entirely instead.
Fixes: 79c14141a487 ("vhost/scsi: Convert completion path to use copy_to_iter")
Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
---
drivers/vhost/scsi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 0e6fd55..c93e125 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -88,7 +88,7 @@ struct vhost_scsi_cmd {
struct scatterlist *tvc_prot_sgl;
struct page **tvc_upages;
/* Pointer to response header iovec */
- struct iovec *tvc_resp_iov;
+ struct iovec tvc_resp_iov;
/* Pointer to vhost_scsi for our device */
struct vhost_scsi *tvc_vhost;
/* Pointer to vhost_virtqueue for the cmd */
@@ -557,7 +557,7 @@ static void vhost_scsi_complete_cmd_work(struct vhost_work *work)
memcpy(v_rsp.sense, cmd->tvc_sense_buf,
se_cmd->scsi_sense_length);
- iov_iter_init(&iov_iter, READ, cmd->tvc_resp_iov,
+ iov_iter_init(&iov_iter, READ, &cmd->tvc_resp_iov,
cmd->tvc_in_iovs, sizeof(v_rsp));
ret = copy_to_iter(&v_rsp, sizeof(v_rsp), &iov_iter);
if (likely(ret == sizeof(v_rsp))) {
@@ -1054,7 +1054,7 @@ vhost_scsi_handle_vq(struct vhost_scsi *vs, struct vhost_virtqueue *vq)
}
cmd->tvc_vhost = vs;
cmd->tvc_vq = vq;
- cmd->tvc_resp_iov = &vq->iov[out];
+ cmd->tvc_resp_iov = vq->iov[out];
cmd->tvc_in_iovs = in;
pr_debug("vhost_scsi got command opcode: %#02x, lun: %d\n",
--
2.5.5
^ permalink raw reply related
* Re: [PATCH v5 1/6] qspinlock: powerpc support qspinlock
From: Benjamin Herrenschmidt @ 2016-06-06 21:41 UTC (permalink / raw)
To: Peter Zijlstra
Cc: mpe, linux-kernel, waiman.long, virtualization, mingo, paulus,
xinhui, paulmck, linuxppc-dev
In-Reply-To: <20160606155907.GH30909@twins.programming.kicks-ass.net>
On Mon, 2016-06-06 at 17:59 +0200, Peter Zijlstra wrote:
> On Fri, Jun 03, 2016 at 02:33:47PM +1000, Benjamin Herrenschmidt wrote:
> >
> > - For the above, can you show (or describe) where the qspinlock
> > improves things compared to our current locks.
> So currently PPC has a fairly straight forward test-and-set spinlock
> IIRC. You have this because LPAR/virt muck and lock holder preemption
> issues etc..
> qspinlock is 1) a fair lock (like ticket locks) and 2) provides
> out-of-word spinning, reducing cacheline pressure.
Thanks Peter. I think I understand the theory, but I'd like see it
translate into real numbers.
> Esp. on multi-socket x86 we saw the out-of-word spinning being a big win
> over our ticket locks.
>
> And fairness, brought to us by the ticket locks a long time ago,
> eliminated starvation issues we had, where a spinner local to the holder
> would 'always' win from a spinner further away. So under heavy enough
> local contention, the spinners on 'remote' CPUs would 'never' get to own
> the lock.
I think our HW has tweaks to avoid that from happening with the simple
locks in the underlying ll/sc implementation. In any case, what I'm
asking is actual tests to verify it works as expected for us.
> pv-qspinlock tries to preserve the fairness while allowing limited lock
> stealing and explicitly managing which vcpus to wake.
Right.
> >
> > While there's
> > theory and to some extent practice on x86, it would be nice to
> > validate the effects on POWER.
> Right; so that will have to be from benchmarks which I cannot help you
> with ;-)
Precisely :-) This is what I was asking for ;-)
Cheers,
Ben.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v5 1/6] qspinlock: powerpc support qspinlock
From: Peter Zijlstra @ 2016-06-06 15:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: mpe, linux-kernel, waiman.long, virtualization, mingo, paulus,
xinhui, paulmck, linuxppc-dev
In-Reply-To: <1464928427.26773.26.camel@kernel.crashing.org>
On Fri, Jun 03, 2016 at 02:33:47PM +1000, Benjamin Herrenschmidt wrote:
> - For the above, can you show (or describe) where the qspinlock
> improves things compared to our current locks.
So currently PPC has a fairly straight forward test-and-set spinlock
IIRC. You have this because LPAR/virt muck and lock holder preemption
issues etc..
qspinlock is 1) a fair lock (like ticket locks) and 2) provides
out-of-word spinning, reducing cacheline pressure.
Esp. on multi-socket x86 we saw the out-of-word spinning being a big win
over our ticket locks.
And fairness, brought to us by the ticket locks a long time ago,
eliminated starvation issues we had, where a spinner local to the holder
would 'always' win from a spinner further away. So under heavy enough
local contention, the spinners on 'remote' CPUs would 'never' get to own
the lock.
pv-qspinlock tries to preserve the fairness while allowing limited lock
stealing and explicitly managing which vcpus to wake.
> While there's
> theory and to some extent practice on x86, it would be nice to
> validate the effects on POWER.
Right; so that will have to be from benchmarks which I cannot help you
with ;-)
^ permalink raw reply
* [PATCH RESEND 06/14] drm/virtio: use drm_crtc_send_vblank_event()
From: Gustavo Padovan @ 2016-06-06 14:41 UTC (permalink / raw)
To: dri-devel
Cc: David Airlie, open list, Gustavo Padovan,
open list:VIRTIO GPU DRIVER
In-Reply-To: <1465224105-21485-1-git-send-email-gustavo@padovan.org>
From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Replace the legacy drm_send_vblank_event() with the new helper function.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
---
drivers/gpu/drm/virtio/virtgpu_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c
index d4305da..ba5e11b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -156,7 +156,7 @@ static int virtio_gpu_page_flip(struct drm_crtc *crtc,
if (event) {
spin_lock_irqsave(&crtc->dev->event_lock, irqflags);
- drm_send_vblank_event(crtc->dev, -1, event);
+ drm_crtc_send_vblank_event(crtc, event);
spin_unlock_irqrestore(&crtc->dev->event_lock, irqflags);
}
--
2.5.5
^ permalink raw reply related
* Re: [PATCH v3] tools/virtio/ringtest: fix run-on-all.sh to work without /dev/cpu
From: Michael S. Tsirkin @ 2016-06-06 13:57 UTC (permalink / raw)
To: Mike Rapoport; +Cc: kvm, virtualization
In-Reply-To: <201606060656.u566rhsn006487@mx0a-001b2d01.pphosted.com>
It's queued in my tree and will be merged shortly.
Thanks!
On Mon, Jun 06, 2016 at 09:55:59AM +0300, Mike Rapoport wrote:
> Ping?
>
> On Tue, May 24, 2016 at 03:41:33PM +0300, Mike Rapoport wrote:
> > Michael,
> >
> > Any updates on this?
> >
> > On Wed, May 04, 2016 at 01:15:50PM +0300, Mike Rapoport wrote:
> > > /dev/cpu is only available on x86 with certain modules (e.g. msr) enabled.
> > > Using lscpu to get processors count is more portable.
> > >
> > > Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
> > > ---
> > > v3: simplify by using lscpu -p=cpu
> > > v2: use lspcu instead of /proc/cpuinfo as per Cornelia's suggestion
> > >
> > > tools/virtio/ringtest/run-on-all.sh | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/tools/virtio/ringtest/run-on-all.sh b/tools/virtio/ringtest/run-on-all.sh
> > > index 52b0f71..2e69ca8 100755
> > > --- a/tools/virtio/ringtest/run-on-all.sh
> > > +++ b/tools/virtio/ringtest/run-on-all.sh
> > > @@ -3,10 +3,10 @@
> > > #use last CPU for host. Why not the first?
> > > #many devices tend to use cpu0 by default so
> > > #it tends to be busier
> > > -HOST_AFFINITY=$(cd /dev/cpu; ls|grep -v '[a-z]'|sort -n|tail -1)
> > > +HOST_AFFINITY=$(lscpu -p=cpu | tail -1)
> > >
> > > #run command on all cpus
> > > -for cpu in $(cd /dev/cpu; ls|grep -v '[a-z]'|sort -n);
> > > +for cpu in $(seq 0 $HOST_AFFINITY)
> > > do
> > > #Don't run guest and host on same CPU
> > > #It actually works ok if using signalling
> > > --
> > > 1.9.1
> > >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
^ permalink raw reply
* Re: [PATCH] tools/virtio/ringtest: add usage example to README
From: Mike Rapoport @ 2016-06-06 6:56 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: kvm, virtualization
In-Reply-To: <20160524124104.GB4725@rapoport-lnx>
Ping?
On Tue, May 24, 2016 at 03:41:04PM +0300, Mike Rapoport wrote:
> Michael,
>
> Any updates on this?
>
> On Wed, May 04, 2016 at 09:12:55AM +0300, Mike Rapoport wrote:
> > Having typical usage example in the README file is more convinient than in
> > the git history...
> >
> > Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
> > ---
> > tools/virtio/ringtest/README | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/tools/virtio/ringtest/README b/tools/virtio/ringtest/README
> > index 34e94c4..d83707a 100644
> > --- a/tools/virtio/ringtest/README
> > +++ b/tools/virtio/ringtest/README
> > @@ -1,2 +1,6 @@
> > Partial implementation of various ring layouts, useful to tune virtio design.
> > Uses shared memory heavily.
> > +
> > +Typical use:
> > +
> > +# sh run-on-all.sh perf stat -r 10 --log-fd 1 -- ./ring
> > --
> > 1.9.1
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v3] tools/virtio/ringtest: fix run-on-all.sh to work without /dev/cpu
From: Mike Rapoport @ 2016-06-06 6:55 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: kvm, virtualization
In-Reply-To: <20160524124133.GC4725@rapoport-lnx>
Ping?
On Tue, May 24, 2016 at 03:41:33PM +0300, Mike Rapoport wrote:
> Michael,
>
> Any updates on this?
>
> On Wed, May 04, 2016 at 01:15:50PM +0300, Mike Rapoport wrote:
> > /dev/cpu is only available on x86 with certain modules (e.g. msr) enabled.
> > Using lscpu to get processors count is more portable.
> >
> > Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
> > ---
> > v3: simplify by using lscpu -p=cpu
> > v2: use lspcu instead of /proc/cpuinfo as per Cornelia's suggestion
> >
> > tools/virtio/ringtest/run-on-all.sh | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/virtio/ringtest/run-on-all.sh b/tools/virtio/ringtest/run-on-all.sh
> > index 52b0f71..2e69ca8 100755
> > --- a/tools/virtio/ringtest/run-on-all.sh
> > +++ b/tools/virtio/ringtest/run-on-all.sh
> > @@ -3,10 +3,10 @@
> > #use last CPU for host. Why not the first?
> > #many devices tend to use cpu0 by default so
> > #it tends to be busier
> > -HOST_AFFINITY=$(cd /dev/cpu; ls|grep -v '[a-z]'|sort -n|tail -1)
> > +HOST_AFFINITY=$(lscpu -p=cpu | tail -1)
> >
> > #run command on all cpus
> > -for cpu in $(cd /dev/cpu; ls|grep -v '[a-z]'|sort -n);
> > +for cpu in $(seq 0 $HOST_AFFINITY)
> > do
> > #Don't run guest and host on same CPU
> > #It actually works ok if using signalling
> > --
> > 1.9.1
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH v3] virtio-net: Add initial MTU advice feature
From: Aaron Conole @ 2016-06-03 20:57 UTC (permalink / raw)
To: virtualization, netdev, linux-kernel, Michael S. Tsirkin
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 <aconole@redhat.com>
---
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_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
^ permalink raw reply related
* Re: [PATCH 01/20] drm/atomic: Fix remaining places where !funcs->best_encoder is valid
From: Daniel Vetter @ 2016-06-03 19:01 UTC (permalink / raw)
To: Boris Brezillon
Cc: Krzysztof Kozlowski, Heiko Stuebner, David Airlie, dri-devel,
open list:VIRTIO CORE, NET..., Eric Anholt, Thierry Re ding,
Laurent Pinchart, Benjamin Gaignard, Daniel Vetter,
Alexandre Courbot, linux-samsung-soc, Joonyoung Shim,
Alexey Brodkin, Kyungmin Park, open list:ARM/Rockchip SoC...,
Chen-Yu Tsai, Kukjin Kim, linux-tegra@vger.kernel.org, Stephen
In-Reply-To: <20160603093743.000ef95b@bbrezillon>
On Fri, Jun 03, 2016 at 09:37:43AM +0200, Boris Brezillon wrote:
> On Thu, 2 Jun 2016 23:57:02 +0200
> Daniel Vetter <daniel@ffwll.ch> wrote:
>
> > On Thu, Jun 2, 2016 at 11:05 PM, Laurent Pinchart
> > <laurent.pinchart@ideasonboard.com> 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 <boris.brezillon@free-electrons.com>
> > >> ---
> > >> 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
^ permalink raw reply
* Re: [PATCH v2 -next] virtio-net: Add initial MTU advice feature
From: Michael S. Tsirkin @ 2016-06-03 16:04 UTC (permalink / raw)
To: Aaron Conole; +Cc: netdev, linux-kernel, virtualization
In-Reply-To: <1464901859-25906-1-git-send-email-aconole@redhat.com>
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 <aconole@redhat.com>
> ---
> 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
^ permalink raw reply
* Re: [PATCH V3 0/2] vhost_net polling optimization
From: Michael S. Tsirkin @ 2016-06-03 13:03 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20160602.120806.2233781548139724198.davem@davemloft.net>
On Thu, Jun 02, 2016 at 12:08:06PM -0700, David Miller wrote:
> From: Jason Wang <jasowang@redhat.com>
> 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.
^ permalink raw reply
* Re: [PATCH 09/20] drm: rcar-du: Rely on the default ->best_encoder() behavior
From: Boris Brezillon @ 2016-06-03 7:38 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Krzysztof Kozlowski, Heiko Stuebner, David Airlie, dri-devel,
virtualization, Eric Anholt, Thierry Re ding, Benjamin Gaignard,
Daniel Vetter, Alexandre Courbot, linux-samsung-soc,
Joonyoung Shim, Alexey Brodkin, Kyungmin Park, linux-rockchip,
Chen-Yu Tsai, Kukjin Kim, linux-tegra, Stephen Warren,
linux-arm-msm, intel-gfx, Jani Nikula, Inki Dae, linux-mediatek
In-Reply-To: <5863270.jtrd0Kruzj@avalon>
On Thu, 02 Jun 2016 23:57:14 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> 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 <boris.brezillon@free-electrons.com>
> > ---
> > 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 <laurent.pinchart@ideasonboard.com>
>
Thanks,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 01/20] drm/atomic: Fix remaining places where !funcs->best_encoder is valid
From: Boris Brezillon @ 2016-06-03 7:37 UTC (permalink / raw)
To: Daniel Vetter
Cc: Krzysztof Kozlowski, Heiko Stuebner, David Airlie, dri-devel,
open list:VIRTIO CORE, NET..., Eric Anholt, Thierry Re ding,
Laurent Pinchart, Benjamin Gaignard, Daniel Vetter,
Alexandre Courbot, linux-samsung-soc, Joonyoung Shim,
Alexey Brodkin, Kyungmin Park, open list:ARM/Rockchip SoC...,
Chen-Yu Tsai, Kukjin Kim, linux-tegra@vger.kernel.org, Stephen
In-Reply-To: <CAKMK7uHyqNbA8Scw2fE0geAyNt0a0XVtzf81nwWjEhbZ-gAvKw@mail.gmail.com>
On Thu, 2 Jun 2016 23:57:02 +0200
Daniel Vetter <daniel@ffwll.ch> wrote:
> On Thu, Jun 2, 2016 at 11:05 PM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> 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 <boris.brezillon@free-electrons.com>
> >> ---
> >> 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
^ permalink raw reply
* Re: [PATCH 01/20] drm/atomic: Fix remaining places where !funcs->best_encoder is valid
From: Boris Brezillon @ 2016-06-03 7:36 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Krzysztof Kozlowski, Heiko Stuebner, David Airlie, dri-devel,
virtualization, Eric Anholt, Thierry Re ding, Benjamin Gaignard,
Daniel Vetter, Alexandre Courbot, linux-samsung-soc,
Joonyoung Shim, Alexey Brodkin, Kyungmin Park, linux-rockchip,
Chen-Yu Tsai, Kukjin Kim, linux-tegra, Stephen Warren,
linux-arm-msm, intel-gfx, Jani Nikula, Inki Dae, linux-mediatek
In-Reply-To: <8671722.LHaiaBNqfE@avalon>
On Fri, 03 Jun 2016 00:05:46 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> 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 <boris.brezillon@free-electrons.com>
> > ---
> > 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
^ permalink raw reply
* Re: [PATCH v5 1/6] qspinlock: powerpc support qspinlock
From: xinhui @ 2016-06-03 7:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linux-kernel, linuxppc-dev,
virtualization
Cc: peterz, mpe, waiman.long, mingo, paulus, paulmck
In-Reply-To: <1464928427.26773.26.camel@kernel.crashing.org>
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
^ permalink raw reply
* Re: [PATCH v5 1/6] qspinlock: powerpc support qspinlock
From: Benjamin Herrenschmidt @ 2016-06-03 4:33 UTC (permalink / raw)
To: xinhui, linux-kernel, linuxppc-dev, virtualization
Cc: peterz, mpe, waiman.long, mingo, paulus, paulmck
In-Reply-To: <57510353.1020209@linux.vnet.ibm.com>
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
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.
Cheers,
Ben.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox