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

Hi Boris, Thank you for the patch. On Thursday 02 Jun 2016 16:31:43 Boris Brezillon wrote: > 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 >

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

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 >

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

[PATCH v5 6/6] powerpc: pseries: Add pv-qspinlock build config/make

pseries has PowerVM support, the default option is Y. Signed-off-by: Pan Xinhui --- arch/powerpc/kernel/Makefile | 1 + arch/powerpc/platforms/pseries/Kconfig | 8 2 files changed, 9 insertions(+) diff --git a/arch/powerpc/kernel/Makefile

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

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. Signed-off-by: Pan Xinhui --- arch/powerpc/include/asm/qspinlock.h

[PATCH v5 5/6] pv-qspinlock: use cmpxchg_release in __pv_queued_spin_unlock

cmpxchg_release is light-wight than cmpxchg, On some arch like ppc, barrier impact the performace too much. Suggested-by: Boqun Feng Signed-off-by: Pan Xinhui --- kernel/locking/qspinlock_paravirt.h | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH v5 2/6] powerpc: pseries/Kconfig: Add qspinlock build config

pseries will use qspinlock by default. Signed-off-by: Pan Xinhui --- arch/powerpc/platforms/pseries/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig index bec90fb..f669323

[PATCH v5 0/6] powerPC/pSeries use pv-qpsinlock as the default spinlock implemention

change from v4: BUG FIX. thanks boqun reporting this issue. struct __qspinlock has different layout in bigendian mahcine. native_queued_spin_unlock() may write value to a wrong address. now fix it. sorry for not even doing a test on bigendian machine before!!!

[PATCH v5 3/6] powerpc: lib/locks.c: Add cpu yield/wake helper function

pv-qspinlock core has pv_wait/pv_kick which will give a better performace by yielding and kicking cpu at some cases. lets support them by adding two corresponding helper functions. Signed-off-by: Pan Xinhui --- arch/powerpc/include/asm/spinlock.h | 4

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

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. Signed-off-by: Pan Xinhui --- arch/powerpc/include/asm/qspinlock.h

[PATCH v5 4/6] pv-qspinlock: powerpc support pv-qspinlock

As we need let pv-qspinlock-kernel run on all environment which might have no powervm, we should runtime choose which qspinlock version to use. The default pv-qspinlock use native version. pv_lock initialization should be done in bootstage with irq disabled. And if there is PHYP, restore

[PATCH v5 2/6] powerpc: pseries/Kconfig: Add qspinlock build config

pseries will use qspinlock by default. Signed-off-by: Pan Xinhui --- arch/powerpc/platforms/pseries/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig index bec90fb..f669323

[PATCH v5 0/6] powerPC/pSeries use pv-qpsinlock as the default spinlock implemention

change from v4: BUG FIX. thanks boqun reporting this issue. struct __qspinlock has different layout in bigendian mahcine. native_queued_spin_unlock() may write value to a wrong address. now fix it. sorry for not even doing a test on bigendian machine before!!!

Re: [PATCH v5 0/6] powerPC/pSeries use pv-qpsinlock as the default spinlock implemention

On 2016年06月02日 17:33, Peter Zijlstra wrote: I'm thinking one copy a day is quite enough... sorry for noise. In recent days, our smtp server has some bugs that mails' Message-Id is changed by accident. So I resend them just for sure. sorry again...

[PATCH v5 0/6] powerPC/pSeries use pv-qpsinlock as the default spinlock implemention

From: root change from v4: BUG FIX. thanks boqun reporting this issue. struct __qspinlock has different layout in bigendian mahcine. native_queued_spin_unlock() may write value to a wrong address. now fix it. change

[PATCH v5 0/6] powerPC/pSeries use pv-qpsinlock as the default spinlock implemention

From: root change from v4: BUG FIX. thanks boqun reporting this issue. struct __qspinlock has different layout in bigendian mahcine. native_queued_spin_unlock() may write value to a wrong address. now fix it. change

[PATCH v5 4/6] pv-qspinlock: powerpc support pv-qspinlock

As we need let pv-qspinlock-kernel run on all environment which might have no powervm, we should runtime choose which qspinlock version to use. The default pv-qspinlock use native version. pv_lock initialization should be done in bootstage with irq disabled. And if there is PHYP, restore

[PATCH v5 3/6] powerpc: lib/locks.c: Add cpu yield/wake helper function

pv-qspinlock core has pv_wait/pv_kick which will give a better performace by yielding and kicking cpu at some cases. lets support them by adding two corresponding helper functions. Signed-off-by: Pan Xinhui --- arch/powerpc/include/asm/spinlock.h | 4

Re: [PATCH v5 0/6] powerPC/pSeries use pv-qpsinlock as the default spinlock implemention

I'm thinking one copy a day is quite enough... ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH v5 5/6] pv-qspinlock: use cmpxchg_release in __pv_queued_spin_unlock

cmpxchg_release is light-wight than cmpxchg, On some arch like ppc, barrier impact the performace too much. Suggested-by: Boqun Feng Signed-off-by: Pan Xinhui --- kernel/locking/qspinlock_paravirt.h | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH v5 0/6] powerPC/pSeries use pv-qpsinlock as the default spinlock implemention

On Thu, Jun 02, 2016 at 05:47:47PM +0800, xinhui wrote: > > > On 2016年06月02日 17:33, Peter Zijlstra wrote: > > > > > >I'm thinking one copy a day is quite enough... > > > sorry for noise. > In recent days, our smtp server has some bugs that mails' Message-Id is > changed by accident. > So I

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

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 12/20] drm: sun4i: Rely on the default ->best_encoder() behavior

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 18/20] drm/bridge: ptn3460: Rely on the default ->best_encoder() behavior

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 19/20] drm/bridge: ps8622: Rely on the default ->best_encoder() behavior

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 20/20] drm/bridge: dw-hdmi: Use drm_atomic_helper_best_encoder()

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 16/20] drm: omap: Rely on the default ->best_encoder() behavior

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 10/20] drm: rockchip: Rely on the default ->best_encoder() behavior

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. Signed-off-by: Boris Brezillon

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

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 08/20] drm: msm: Rely on the default ->best_encoder() behavior where appropriate

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 07/20] drm: mediatek: Rely on the default ->best_encoder() behavior

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 00/20] drm/atomic: Provide default ->best_encoder() behavior

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 04/20] drm: exynos: Rely on the default ->best_encoder() behavior

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 05/20] drm: fsl-dcu: Rely on the default ->best_encoder() behavior

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 14/20] drm: vc4: Rely on the default ->best_encoder() behavior

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 17/20] drm/bridge: anx78xx: Rely on the default ->best_encoder() behavior

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 15/20] drm: virtgpu: Rely on the default ->best_encoder() behavior

The virtgpu output exposes 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 02/20] drm: arc: Rely on the default ->best_encoder() behavior

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 03/20] drm: atmel-hlcdc: Rely on the default ->best_encoder() behavior

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 01/20] drm/atomic: Fix remaining places where !funcs->best_encoder is valid

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(). Signed-off-by: Boris Brezillon

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

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 06/20] drm: i915: Rely on the default ->best_encoder() behavior where appropriate

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 -next 1/2] virtio: Start feature MTU support

This commit adds the feature bit and associated mtu device entry for the virtio network device. Future commits will make use of these bits to support negotiated MTU. Signed-off-by: Aaron Conole --- include/uapi/linux/virtio_net.h | 2 ++ 1 file changed, 2 insertions(+) diff

[PATCH -next 2/2] virtio_net: Read the advised MTU

This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it exists, read the advised MTU and use it. No proper error handling is provided for the case where a user changes the negotiated MTU. A future commit will add proper error handling. Instead, a warning is emitted if the guest

Re: [PATCH -next 2/2] virtio_net: Read the advised MTU

Hi Rick, In the future, please don't cut the list. Rick Jones writes: > On 06/02/2016 08:43 AM, Aaron Conole wrote: >> This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it >> exists, read the advised MTU and use it. >> >> No proper error handling is

Re: [PATCH -next 1/2] virtio: Start feature MTU support

"Michael S. Tsirkin" writes: > On Thu, Jun 02, 2016 at 11:43:30AM -0400, Aaron Conole wrote: >> This commit adds the feature bit and associated mtu device entry for the >> virtio network device. Future commits will make use of these bits to >> support negotiated MTU. > > why

Re: [PATCH -next 2/2] virtio_net: Read the advised MTU

"Michael S. Tsirkin" writes: > On Thu, Jun 02, 2016 at 11:43:31AM -0400, Aaron Conole wrote: >> This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it >> exists, read the advised MTU and use it. >> >> No proper error handling is provided for the case where a

Re: [PATCH -next 2/2] virtio_net: Read the advised MTU

Hi, [auto build test ERROR on next-20160602] url: https://github.com/0day-ci/linux/commits/Aaron-Conole/virtio-net-Advised-MTU-feature/20160603-000714 config: i386-allmodconfig (attached as .config) compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430 reproduce: # save the attached

Re: [PATCH -next 2/2] virtio_net: Read the advised MTU

kbuild test robot <l...@intel.com> writes: > Hi, > > [auto build test ERROR on next-20160602] > > url: > https://github.com/0day-ci/linux/commits/Aaron-Conole/virtio-net-Advised-MTU-feature/20160603-000714 > config: i386-allmodconfig (attached as .config) > c

[PATCH -next 0/2] virtio-net: Advised MTU feature

The following series adds the ability for a hypervisor to set an MTU on the guest during feature negotiation phase. This is useful for VM orchestration when, for instance, tunneling is involved and the MTU of the various systems should be homogenous. The first patch adds the feature bit as

Re: [PATCH -next 2/2] virtio_net: Read the advised MTU

On Thu, Jun 02, 2016 at 11:43:31AM -0400, Aaron Conole wrote: > This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it > exists, read the advised MTU and use it. > > No proper error handling is provided for the case where a user changes the > negotiated MTU. A future commit

Re: [PATCH -next 1/2] virtio: Start feature MTU support

On Thu, Jun 02, 2016 at 11:43:30AM -0400, Aaron Conole wrote: > This commit adds the feature bit and associated mtu device entry for the > virtio network device. Future commits will make use of these bits to > support negotiated MTU. why split it out? Pls squash with the next patch. >

Re: [PATCH -next 2/2] virtio_net: Read the advised MTU

On 06/02/2016 10:06 AM, Aaron Conole wrote: Rick Jones writes: One of the things I've been doing has been setting-up a cluster (OpenStack) with JumboFrames, and then setting MTUs on instance vNICs by hand to measure different MTU sizes. It would be a shame if such a thing

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

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 >