Re: [PATCH 2/2] drm/mediatek: clear IRQ status before enable OVL interrupt

Acked-by: CK Hu On Thu, 2016-09-29 at 11:29 +0800, Bibby Hsieh wrote: > To make sure that the first vblank IRQ after enabling > vblank isn't too short or immediate, we have to clear > the IRQ status before enable OVL interrupt. > > Signed-off-by: Bibby Hsieh

Re: [PATCH 2/2] drm/mediatek: clear IRQ status before enable OVL interrupt

Acked-by: CK Hu On Thu, 2016-09-29 at 11:29 +0800, Bibby Hsieh wrote: > To make sure that the first vblank IRQ after enabling > vblank isn't too short or immediate, we have to clear > the IRQ status before enable OVL interrupt. > > Signed-off-by: Bibby Hsieh > --- >

Re: [PATCH v3 2/7] i2c: bcm2835: Protect against unexpected TXW/RXR interrupts

> Noralf Trønnes hat am 29. September 2016 um 00:22 > geschrieben: > > > > Den 29.09.2016 00:00, skrev Eric Anholt: > > Noralf Trønnes writes: > > > >> If an unexpected TXW or RXR interrupt occurs (msg_buf_remaining == 0), > >> the driver has no way to

Re: [PATCH v3 2/7] i2c: bcm2835: Protect against unexpected TXW/RXR interrupts

> Noralf Trønnes hat am 29. September 2016 um 00:22 > geschrieben: > > > > Den 29.09.2016 00:00, skrev Eric Anholt: > > Noralf Trønnes writes: > > > >> If an unexpected TXW or RXR interrupt occurs (msg_buf_remaining == 0), > >> the driver has no way to fill/drain the FIFO to stop the

Re: [PATCH 1/2] drm/mediatek: set vblank_disable_allowed to true

Acked-by: CK Hu On Thu, 2016-09-29 at 11:29 +0800, Bibby Hsieh wrote: > MTK DRM driver didn't set the vblank_disable_allowed to > true, it cause that the irq_handler is called every > 16.6 ms (every vblank) when the display didn't be updated. > > Signed-off-by: Bibby Hsieh

Re: [PATCH 1/2] drm/mediatek: set vblank_disable_allowed to true

Acked-by: CK Hu On Thu, 2016-09-29 at 11:29 +0800, Bibby Hsieh wrote: > MTK DRM driver didn't set the vblank_disable_allowed to > true, it cause that the irq_handler is called every > 16.6 ms (every vblank) when the display didn't be updated. > > Signed-off-by: Bibby Hsieh > --- >

[PATCH kernel v2] PCI: Enable access to custom VPD for Chelsio devices (cxgb3)

There is at least one Chelsio 10Gb card which uses VPD area to store some custom blocks (example below). However pci_vpd_size() returns the length of the first block only assuming that there can be only one VPD "End Tag" and VFIO blocks access beyond that offset (since 4e1a63555) which leads to

[PATCH kernel v2] PCI: Enable access to custom VPD for Chelsio devices (cxgb3)

There is at least one Chelsio 10Gb card which uses VPD area to store some custom blocks (example below). However pci_vpd_size() returns the length of the first block only assuming that there can be only one VPD "End Tag" and VFIO blocks access beyond that offset (since 4e1a63555) which leads to

[PATCH v3 2/3] ARM: dts: omap5 uevm: add LEDs

Signed-off-by: H. Nikolaus Schaller --- arch/arm/boot/dts/omap5-uevm.dts | 60 1 file changed, 60 insertions(+) diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts index be659e8..31ce4f8 100644 ---

[PATCH v3 3/3] ARM: dts: omap5 uevm: add USR1 button

Signed-off-by: H. Nikolaus Schaller --- arch/arm/boot/dts/omap5-uevm.dts | 25 + 1 file changed, 25 insertions(+) diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts index 31ce4f8..0f50baf 100644 ---

[PATCH v3 2/3] ARM: dts: omap5 uevm: add LEDs

Signed-off-by: H. Nikolaus Schaller --- arch/arm/boot/dts/omap5-uevm.dts | 60 1 file changed, 60 insertions(+) diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts index be659e8..31ce4f8 100644 ---

[PATCH v3 3/3] ARM: dts: omap5 uevm: add USR1 button

Signed-off-by: H. Nikolaus Schaller --- arch/arm/boot/dts/omap5-uevm.dts | 25 + 1 file changed, 25 insertions(+) diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts index 31ce4f8..0f50baf 100644 --- a/arch/arm/boot/dts/omap5-uevm.dts +++

[PATCH v3 1/3] ARM: dts: omap5 uevm: add EEPROM

Signed-off-by: H. Nikolaus Schaller --- arch/arm/boot/dts/omap5-uevm.dts | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts index 36ff7c3..be659e8 100644 --- a/arch/arm/boot/dts/omap5-uevm.dts +++

[PATCH v3 1/3] ARM: dts: omap5 uevm: add EEPROM

Signed-off-by: H. Nikolaus Schaller --- arch/arm/boot/dts/omap5-uevm.dts | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts index 36ff7c3..be659e8 100644 --- a/arch/arm/boot/dts/omap5-uevm.dts +++

[PATCH v3 0/3] ARM: dts: omap5 uevm: add LEDs, USR1 button and EEPROM

Changes V3: * remove unit addresses from LEDs [Rob Herring] 2016-09-28 20:08:23: Changes V2: * fixed subject of patches to correctly tell that it is for omap5 evm * changed default triggers a little to create a nicer default pattern 2016-09-27 07:26:14: These patches configure * the EEPROM * the

[PATCH v3 0/3] ARM: dts: omap5 uevm: add LEDs, USR1 button and EEPROM

Changes V3: * remove unit addresses from LEDs [Rob Herring] 2016-09-28 20:08:23: Changes V2: * fixed subject of patches to correctly tell that it is for omap5 evm * changed default triggers a little to create a nicer default pattern 2016-09-27 07:26:14: These patches configure * the EEPROM * the

Re: [PATCH 2/3] DT: EVM: add LEDs

> Am 29.09.2016 um 07:14 schrieb Rob Herring : > > On Tue, Sep 27, 2016 at 12:26 AM, H. Nikolaus Schaller > wrote: > > The subject gives no indication this is for OMAP. Please follow > standard patterns. > >> Signed-off-by: H. Nikolaus Schaller

Re: [PATCH 2/3] DT: EVM: add LEDs

> Am 29.09.2016 um 07:14 schrieb Rob Herring : > > On Tue, Sep 27, 2016 at 12:26 AM, H. Nikolaus Schaller > wrote: > > The subject gives no indication this is for OMAP. Please follow > standard patterns. > >> Signed-off-by: H. Nikolaus Schaller >> --- >> arch/arm/boot/dts/omap5-uevm.dts | 60

Re: [PATCH 17/26] intel_telemetry_debugfs: constify local structures

On Wed, 28 Sep 2016, Darren Hart wrote: > On Sun, Sep 11, 2016 at 03:05:59PM +0200, Julia Lawall wrote: > > Hi Julia, > > > For structure types defined in the same file or local header files, find > > top-level static structure declarations that have the following > > properties: > > 1. Never

Re: [PATCH 17/26] intel_telemetry_debugfs: constify local structures

On Wed, 28 Sep 2016, Darren Hart wrote: > On Sun, Sep 11, 2016 at 03:05:59PM +0200, Julia Lawall wrote: > > Hi Julia, > > > For structure types defined in the same file or local header files, find > > top-level static structure declarations that have the following > > properties: > > 1. Never

Re: [PATCH 2/3] DT: EVM: add LEDs

> Am 29.09.2016 um 07:14 schrieb Rob Herring : > > On Tue, Sep 27, 2016 at 12:26 AM, H. Nikolaus Schaller > wrote: > > The subject gives no indication this is for OMAP. Please follow > standard patterns. Already fixed. Please see v2. > >>

Re: [PATCH 2/3] DT: EVM: add LEDs

> Am 29.09.2016 um 07:14 schrieb Rob Herring : > > On Tue, Sep 27, 2016 at 12:26 AM, H. Nikolaus Schaller > wrote: > > The subject gives no indication this is for OMAP. Please follow > standard patterns. Already fixed. Please see v2. > >> Signed-off-by: H. Nikolaus Schaller >> --- >>

Re: [PATCH 2/3] DT: EVM: add LEDs

On Tue, Sep 27, 2016 at 12:26 AM, H. Nikolaus Schaller wrote: The subject gives no indication this is for OMAP. Please follow standard patterns. > Signed-off-by: H. Nikolaus Schaller > --- > arch/arm/boot/dts/omap5-uevm.dts | 60 >

Re: [PATCH 2/3] DT: EVM: add LEDs

On Tue, Sep 27, 2016 at 12:26 AM, H. Nikolaus Schaller wrote: The subject gives no indication this is for OMAP. Please follow standard patterns. > Signed-off-by: H. Nikolaus Schaller > --- > arch/arm/boot/dts/omap5-uevm.dts | 60 > > 1 file changed,

[PATCH][v3] mfd: intel-lpss: Avoid resuming runtime-suspended lpss unnecessarily

We have report that the intel_lpss_prepare() takes too much time during suspend, and this is because we first resume the devices from runtime suspend by resume_lpss_device(), to make sure they are in proper state before system suspend, which takes 100ms for each LPSS devices(PCI power state from

[PATCH][v3] mfd: intel-lpss: Avoid resuming runtime-suspended lpss unnecessarily

We have report that the intel_lpss_prepare() takes too much time during suspend, and this is because we first resume the devices from runtime suspend by resume_lpss_device(), to make sure they are in proper state before system suspend, which takes 100ms for each LPSS devices(PCI power state from

Re: [PATCH][v2] mfd: intel-lpss: Avoid resuming runtime-suspended lpss unnecessarily

On Wed, Sep 28, 2016 at 11:48:40PM +0200, Rafael J. Wysocki wrote: > On Wed, Sep 28, 2016 at 6:29 PM, Chen Yu wrote: > > We have report that the intel_lpss_prepare() takes too much time during > > suspend, and this is because we first resume the devices from runtime > >

Re: [PATCH][v2] mfd: intel-lpss: Avoid resuming runtime-suspended lpss unnecessarily

On Wed, Sep 28, 2016 at 11:48:40PM +0200, Rafael J. Wysocki wrote: > On Wed, Sep 28, 2016 at 6:29 PM, Chen Yu wrote: > > We have report that the intel_lpss_prepare() takes too much time during > > suspend, and this is because we first resume the devices from runtime > > suspend by

[PATCH v2 net-next] mlx5: Add ndo_poll_controller() implementation

This implements ndo_poll_controller in net_device_ops callbacks for mlx5, which is necessary to use netconsole with this driver. Acked-By: Saeed Mahameed Signed-off-by: Calvin Owens --- Changes in v2: * Only iterate channels to avoid redundant

[PATCH v2 net-next] mlx5: Add ndo_poll_controller() implementation

This implements ndo_poll_controller in net_device_ops callbacks for mlx5, which is necessary to use netconsole with this driver. Acked-By: Saeed Mahameed Signed-off-by: Calvin Owens --- Changes in v2: * Only iterate channels to avoid redundant napi_schedule() calls

Re: [PATCH v19 05/12] fpga-mgr: add fpga image information struct

On Wed, Sep 28, 2016 at 6:41 PM, Moritz Fischer wrote: Hi Moritz, > Hi Alan, > > generally ok with the change. Cool! > > On Wed, Sep 28, 2016 at 11:21 AM, Alan Tull > wrote: > >> -int fpga_mgr_buf_load(struct fpga_manager *mgr, u32

Re: [PATCH v19 05/12] fpga-mgr: add fpga image information struct

On Wed, Sep 28, 2016 at 6:41 PM, Moritz Fischer wrote: Hi Moritz, > Hi Alan, > > generally ok with the change. Cool! > > On Wed, Sep 28, 2016 at 11:21 AM, Alan Tull > wrote: > >> -int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags, const char *buf, >> - size_t

Re: [PATCH] drm/mediatek: fix a typo

Acked-by: CK Hu On Thu, 2016-09-29 at 11:22 +0800, Bibby Hsieh wrote: > Fix the typo: OD_RELAYMODE->OD_CFG > > Signed-off-by: Bibby Hsieh > --- > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |2 +- > 1 file changed, 1 insertion(+), 1

Re: [PATCH] drm/mediatek: fix a typo

Acked-by: CK Hu On Thu, 2016-09-29 at 11:22 +0800, Bibby Hsieh wrote: > Fix the typo: OD_RELAYMODE->OD_CFG > > Signed-off-by: Bibby Hsieh > --- > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

[PATCH] jiffies: add time comparison functions for 64 bit jiffies

Though the time_before and time_after family of functions were nicely extended to support jiffies64, so that the interface would be consistent, it was forgotten to also extend the before/after jiffies functions to support jiffies64. This commit brings the interface to parity between jiffies and

[PATCH] jiffies: add time comparison functions for 64 bit jiffies

Though the time_before and time_after family of functions were nicely extended to support jiffies64, so that the interface would be consistent, it was forgotten to also extend the before/after jiffies functions to support jiffies64. This commit brings the interface to parity between jiffies and

[PATCH 0/2] fix issue: vblank interrupts are never disabled

Clean the interrupt status before enable interrupt and set the vblank_disable_allowed to fix the issue. Bibby Hsieh (2): drm/mediatek: set vblank_disable_allowed to true drm/mediatek: clear IRQ status before enable OVL interrupt drivers/gpu/drm/mediatek/mtk_disp_ovl.c |1 +

[PATCH 1/2] drm/mediatek: set vblank_disable_allowed to true

MTK DRM driver didn't set the vblank_disable_allowed to true, it cause that the irq_handler is called every 16.6 ms (every vblank) when the display didn't be updated. Signed-off-by: Bibby Hsieh --- drivers/gpu/drm/mediatek/mtk_drm_drv.c |1 + 1 file changed, 1

[PATCH 0/2] fix issue: vblank interrupts are never disabled

Clean the interrupt status before enable interrupt and set the vblank_disable_allowed to fix the issue. Bibby Hsieh (2): drm/mediatek: set vblank_disable_allowed to true drm/mediatek: clear IRQ status before enable OVL interrupt drivers/gpu/drm/mediatek/mtk_disp_ovl.c |1 +

[PATCH 1/2] drm/mediatek: set vblank_disable_allowed to true

MTK DRM driver didn't set the vblank_disable_allowed to true, it cause that the irq_handler is called every 16.6 ms (every vblank) when the display didn't be updated. Signed-off-by: Bibby Hsieh --- drivers/gpu/drm/mediatek/mtk_drm_drv.c |1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 2/2] drm/mediatek: clear IRQ status before enable OVL interrupt

To make sure that the first vblank IRQ after enabling vblank isn't too short or immediate, we have to clear the IRQ status before enable OVL interrupt. Signed-off-by: Bibby Hsieh --- drivers/gpu/drm/mediatek/mtk_disp_ovl.c |1 + 1 file changed, 1 insertion(+) diff

[PATCH 2/2] drm/mediatek: clear IRQ status before enable OVL interrupt

To make sure that the first vblank IRQ after enabling vblank isn't too short or immediate, we have to clear the IRQ status before enable OVL interrupt. Signed-off-by: Bibby Hsieh --- drivers/gpu/drm/mediatek/mtk_disp_ovl.c |1 + 1 file changed, 1 insertion(+) diff --git

[PATCH] drm/mediatek: fix a typo

Fix the typo: OD_RELAYMODE->OD_CFG Signed-off-by: Bibby Hsieh --- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c

[PATCH] drm/mediatek: fix a typo

Fix the typo: OD_RELAYMODE->OD_CFG Signed-off-by: Bibby Hsieh --- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c index df33b3c..aa5f20f

linux-next: build failure after merge of the tip tree

Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: arch/x86/power/hibernate_64.c: In function 'hibernation_e820_save': arch/x86/power/hibernate_64.c:236:15: error: passing argument 1 of 'get_e820_md5' from incompatible pointer type

linux-next: build failure after merge of the tip tree

Hi all, After merging the tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: arch/x86/power/hibernate_64.c: In function 'hibernation_e820_save': arch/x86/power/hibernate_64.c:236:15: error: passing argument 1 of 'get_e820_md5' from incompatible pointer type

Re: [PATCH 2/3] zram: support page-based parallel write

Hello Minchan, On (09/22/16 15:42), Minchan Kim wrote: > zram supports stream-based parallel compression. IOW, it can support > parallel compression on SMP system only if each cpus has streams. > For example, assuming 4 CPU system, there are 4 sources for compressing > in system and each source

Re: [PATCH 2/3] zram: support page-based parallel write

Hello Minchan, On (09/22/16 15:42), Minchan Kim wrote: > zram supports stream-based parallel compression. IOW, it can support > parallel compression on SMP system only if each cpus has streams. > For example, assuming 4 CPU system, there are 4 sources for compressing > in system and each source

Re: [PATCH 08/16] md/bitmap: Rename a jump label in location_store()

On 09/28/2016 03:55 PM, Jes Sorensen wrote: SF Markus Elfring writes: From: Markus Elfring Date: Tue, 27 Sep 2016 15:46:22 +0200 Adjust jump labels according to the current Linux coding style convention. Signed-off-by: Markus

Re: [PATCH 08/16] md/bitmap: Rename a jump label in location_store()

On 09/28/2016 03:55 PM, Jes Sorensen wrote: SF Markus Elfring writes: From: Markus Elfring Date: Tue, 27 Sep 2016 15:46:22 +0200 Adjust jump labels according to the current Linux coding style convention. Signed-off-by: Markus Elfring --- drivers/md/bitmap.c | 18 +- 1

[PATCH v5 2/3] drm/mediatek: enhance the HDMI driving current

From: Junzhi Zhao In order to improve 4K resolution performance, we have to enhance the HDMI driving current when clock rate is greater than 165MHz. Signed-off-by: Junzhi Zhao Signed-off-by: Bibby Hsieh ---

[PATCH v5 3/3] drm/mediatek: modify the factor to make the pll_rate set in the 1G-2G range

From: Junzhi Zhao Currently, the code sets the "pll" to the desired multiple of the pixel clock manully(4*3m 8*3,etc). The valid range of the pll is 1G-2G, however, when the pixel clock is bigger than 167MHz, the "pll" will be set to a invalid value( > 2G), then the

[PATCH v5 2/3] drm/mediatek: enhance the HDMI driving current

From: Junzhi Zhao In order to improve 4K resolution performance, we have to enhance the HDMI driving current when clock rate is greater than 165MHz. Signed-off-by: Junzhi Zhao Signed-off-by: Bibby Hsieh --- drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 42 +--- 1

[PATCH v5 3/3] drm/mediatek: modify the factor to make the pll_rate set in the 1G-2G range

From: Junzhi Zhao Currently, the code sets the "pll" to the desired multiple of the pixel clock manully(4*3m 8*3,etc). The valid range of the pll is 1G-2G, however, when the pixel clock is bigger than 167MHz, the "pll" will be set to a invalid value( > 2G), then the "pll" will be 2GHz, thus

[PATCH v5 0/3] MT8173 HDMI 4K support

This is MT8173 HDMI 4K support PATCH v5, based on 4.8-rc1. In order to support HDMI 4K on MT8173, we have to make some modifications. 1) Make sure that mtk_hdmi_send_infoframe is sent successfully. 2) Enhance the HDMI driving current to improve performance. 3) Make sure that pixel clock is 297MHz

[PATCH v5 0/3] MT8173 HDMI 4K support

This is MT8173 HDMI 4K support PATCH v5, based on 4.8-rc1. In order to support HDMI 4K on MT8173, we have to make some modifications. 1) Make sure that mtk_hdmi_send_infoframe is sent successfully. 2) Enhance the HDMI driving current to improve performance. 3) Make sure that pixel clock is 297MHz

[PATCH v5 1/3] drm/mediatek: do mtk_hdmi_send_infoframe after HDMI clock enable

From: Junzhi Zhao The mtk_hdmi_send_infoframe have to be run after PLL and PIXEL clock of HDMI enable. Make sure that HDMI inforframes can be sent successfully. Signed-off-by: Junzhi Zhao Signed-off-by: Bibby Hsieh

[PATCH v5 1/3] drm/mediatek: do mtk_hdmi_send_infoframe after HDMI clock enable

From: Junzhi Zhao The mtk_hdmi_send_infoframe have to be run after PLL and PIXEL clock of HDMI enable. Make sure that HDMI inforframes can be sent successfully. Signed-off-by: Junzhi Zhao Signed-off-by: Bibby Hsieh --- drivers/gpu/drm/mediatek/mtk_hdmi.c | 17 +++-- 1 file

linux-next: manual merge of the tip tree with the vfs tree

Hi all, Today's linux-next merge of the tip tree got a conflict in: arch/x86/mm/fault.c between commit: df720ac12fc7 ("exceptions: detritus removal") from the vfs tree and commit: 744c193eb9a2 ("x86: Migrate exception table users off module.h and onto extable.h") from the tip tree.

linux-next: manual merge of the tip tree with the vfs tree

Hi all, Today's linux-next merge of the tip tree got a conflict in: arch/x86/mm/fault.c between commit: df720ac12fc7 ("exceptions: detritus removal") from the vfs tree and commit: 744c193eb9a2 ("x86: Migrate exception table users off module.h and onto extable.h") from the tip tree.

tracing: add #undef to fix compile error

There are several trace include files that define TRACE_INCLUDE_FILE. Include several of them in the same .c file (as I currently have in some code I am working on), and the compile will blow up with a "warning: "TRACE_INCLUDE_FILE" redefined #define TRACE_INCLUDE_FILE syscalls" Every other

tracing: add #undef to fix compile error

There are several trace include files that define TRACE_INCLUDE_FILE. Include several of them in the same .c file (as I currently have in some code I am working on), and the compile will blow up with a "warning: "TRACE_INCLUDE_FILE" redefined #define TRACE_INCLUDE_FILE syscalls" Every other

Re: [PATCH 2/2] drm/vc4: Add support for interlaced modes on HDMI.

Mark yao writes: > On 2016年09月29日 10:20, Eric Anholt wrote: >> We just needed to initialize a few more fields. >> >> Signed-off-by: Eric Anholt >> --- >> drivers/gpu/drm/vc4/vc4_crtc.c | 17 ++--- >> drivers/gpu/drm/vc4/vc4_hdmi.c | 12

Re: [PATCH 2/2] drm/vc4: Add support for interlaced modes on HDMI.

Mark yao writes: > On 2016年09月29日 10:20, Eric Anholt wrote: >> We just needed to initialize a few more fields. >> >> Signed-off-by: Eric Anholt >> --- >> drivers/gpu/drm/vc4/vc4_crtc.c | 17 ++--- >> drivers/gpu/drm/vc4/vc4_hdmi.c | 12 >>

RE: [PATCH 3/3] KVM: x86: do not scan IRR twice on APICv vmentry

> -Original Message- > From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo > Bonzini > Sent: Wednesday, September 28, 2016 5:20 AM > To: linux-kernel@vger.kernel.org; k...@vger.kernel.org > Cc: yang.zhang...@gmail.com; Wu, Feng ; > m...@redhat.com;

RE: [PATCH 3/3] KVM: x86: do not scan IRR twice on APICv vmentry

> -Original Message- > From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo > Bonzini > Sent: Wednesday, September 28, 2016 5:20 AM > To: linux-kernel@vger.kernel.org; k...@vger.kernel.org > Cc: yang.zhang...@gmail.com; Wu, Feng ; > m...@redhat.com; rkrc...@redhat.com

Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

Hi David, Please see inline: On Wed, 28 Sep 2016, David Miller wrote: > From: "R. Parameswaran" > Date: Tue, 27 Sep 2016 12:17:21 -0700 (PDT) > > > Later, in vxlan_dev_configure(), called from vxlan_dev_create(), it gets > > adjusted to account for the headers: >

Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

Hi David, Please see inline: On Wed, 28 Sep 2016, David Miller wrote: > From: "R. Parameswaran" > Date: Tue, 27 Sep 2016 12:17:21 -0700 (PDT) > > > Later, in vxlan_dev_configure(), called from vxlan_dev_create(), it gets > > adjusted to account for the headers: > > > >

Re: Runtime failure running sh:qemu in -next due to 'sh: fix copy_from_user()'

On 09/18/2016 10:17 AM, Rich Felker wrote: > On Sat, Sep 17, 2016 at 11:40:28PM -0500, Rob Landley wrote: >> >> >> On 09/16/2016 09:23 PM, Guenter Roeck wrote: >>> On 09/16/2016 04:32 PM, Rich Felker wrote: > 4.6.3 from kernel.org. That is utterly ancient and probaby very buggy. I

Re: Runtime failure running sh:qemu in -next due to 'sh: fix copy_from_user()'

On 09/18/2016 10:17 AM, Rich Felker wrote: > On Sat, Sep 17, 2016 at 11:40:28PM -0500, Rob Landley wrote: >> >> >> On 09/16/2016 09:23 PM, Guenter Roeck wrote: >>> On 09/16/2016 04:32 PM, Rich Felker wrote: > 4.6.3 from kernel.org. That is utterly ancient and probaby very buggy. I

Re: [PATCH 2/2] drm/vc4: Add support for interlaced modes on HDMI.

On 2016年09月29日 10:20, Eric Anholt wrote: We just needed to initialize a few more fields. Signed-off-by: Eric Anholt --- drivers/gpu/drm/vc4/vc4_crtc.c | 17 ++--- drivers/gpu/drm/vc4/vc4_hdmi.c | 12 drivers/gpu/drm/vc4/vc4_regs.h | 3 +++ 3

Re: [PATCH 2/2] drm/vc4: Add support for interlaced modes on HDMI.

On 2016年09月29日 10:20, Eric Anholt wrote: We just needed to initialize a few more fields. Signed-off-by: Eric Anholt --- drivers/gpu/drm/vc4/vc4_crtc.c | 17 ++--- drivers/gpu/drm/vc4/vc4_hdmi.c | 12 drivers/gpu/drm/vc4/vc4_regs.h | 3 +++ 3 files changed, 25

Re: [PATCH] perf sched: kill time stamp discrepancy between script and latency

On 09/28/2016 07:25 PM, Joonwoo Park wrote: Perf sched latency is handy to find out the maximum sched latency and the time stamp of the event. After running sched latency, if a found latency looks suspicious it's quite reasonable to run perf script subsequently and search with the time stamp

Re: [PATCH] perf sched: kill time stamp discrepancy between script and latency

On 09/28/2016 07:25 PM, Joonwoo Park wrote: Perf sched latency is handy to find out the maximum sched latency and the time stamp of the event. After running sched latency, if a found latency looks suspicious it's quite reasonable to run perf script subsequently and search with the time stamp

Re: Regression in 4.8 - CPU speed set very low

On 09/27/2016 09:51 AM, Lennart Sorensen wrote: On Mon, Sep 26, 2016 at 04:28:29PM -0500, Larry Finger wrote: Mostly I use a KDE applet named "System load" and look at the "average clock", but the same info is also available in /proc/cpuinfo as "cpu MHz". When the bug triggers, the system gets

[PATCH] perf sched: kill time stamp discrepancy between script and latency

Perf sched latency is handy to find out the maximum sched latency and the time stamp of the event. After running sched latency, if a found latency looks suspicious it's quite reasonable to run perf script subsequently and search with the time stamp given by perf sched latency to continue further

[PATCH] perf sched: kill time stamp discrepancy between script and latency

Perf sched latency is handy to find out the maximum sched latency and the time stamp of the event. After running sched latency, if a found latency looks suspicious it's quite reasonable to run perf script subsequently and search with the time stamp given by perf sched latency to continue further

Re: Regression in 4.8 - CPU speed set very low

On 09/27/2016 09:51 AM, Lennart Sorensen wrote: On Mon, Sep 26, 2016 at 04:28:29PM -0500, Larry Finger wrote: Mostly I use a KDE applet named "System load" and look at the "average clock", but the same info is also available in /proc/cpuinfo as "cpu MHz". When the bug triggers, the system gets

Re: [PATCH] netfilter: bridge: clarify bridge/netfilter message

Stefan Agner wrote: > When using bridge without bridge netfilter enabled the message > displayed is rather confusing and leads to belive that a deprecated > feature is in use. Use IS_MODULE to be explicit that the message only > affects users which use bridge netfilter as module

Re: Regression in mobility grouping?

On Wed, Sep 28, 2016 at 11:39:25AM -0400, Johannes Weiner wrote: > On Wed, Sep 28, 2016 at 11:00:15AM +0200, Vlastimil Babka wrote: > > I guess testing revert of 9c0415e could give us some idea. Commit > > 3a1086f shouldn't result in pageblock marking differences and as I said > > above, 99592d5

Re: [PATCH] netfilter: bridge: clarify bridge/netfilter message

Stefan Agner wrote: > When using bridge without bridge netfilter enabled the message > displayed is rather confusing and leads to belive that a deprecated > feature is in use. Use IS_MODULE to be explicit that the message only > affects users which use bridge netfilter as module and reword the >

Re: Regression in mobility grouping?

On Wed, Sep 28, 2016 at 11:39:25AM -0400, Johannes Weiner wrote: > On Wed, Sep 28, 2016 at 11:00:15AM +0200, Vlastimil Babka wrote: > > I guess testing revert of 9c0415e could give us some idea. Commit > > 3a1086f shouldn't result in pageblock marking differences and as I said > > above, 99592d5

[PATCH] clk: bcm2835: Clamp the PLL's requested rate to the hardware limits.

Fixes setting low-resolution video modes on HDMI. Now the PLLH_PIX divider adjusts itself until the PLLH is within bounds. Signed-off-by: Eric Anholt --- drivers/clk/bcm/clk-bcm2835.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git

[PATCH] clk: bcm2835: Clamp the PLL's requested rate to the hardware limits.

Fixes setting low-resolution video modes on HDMI. Now the PLLH_PIX divider adjusts itself until the PLLH is within bounds. Signed-off-by: Eric Anholt --- drivers/clk/bcm/clk-bcm2835.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/clk/bcm/clk-bcm2835.c

Re: Regression in 4.8 - CPU speed set very low

On 09/27/2016 06:46 AM, Rafael J. Wysocki wrote: On Tue, Sep 27, 2016 at 10:48 AM, Larry Finger wrote: On 09/26/2016 10:12 PM, Doug Smythies wrote: On 2016.09.26 18:31 Srinivas Pandruvada wrote: On Mon, 2016-09-26 at 19:48 -0500, Larry Finger wrote: On

Re: Regression in 4.8 - CPU speed set very low

On 09/27/2016 06:46 AM, Rafael J. Wysocki wrote: On Tue, Sep 27, 2016 at 10:48 AM, Larry Finger wrote: On 09/26/2016 10:12 PM, Doug Smythies wrote: On 2016.09.26 18:31 Srinivas Pandruvada wrote: On Mon, 2016-09-26 at 19:48 -0500, Larry Finger wrote: On 09/26/2016 07:21 PM, Rafael J.

[PATCH 1/2] drm/vc4: Increase timeout for HDMI_SCHEDULER_CONTROL changes.

Fixes occasional debug spew at boot when connected directly through HDMI, and probably confusing the HDMI state machine when we go trying to poke registers for the enable sequence too soon. Signed-off-by: Eric Anholt --- drivers/gpu/drm/vc4/vc4_hdmi.c | 4 ++-- 1 file changed,

[PATCH 2/2] drm/vc4: Add support for interlaced modes on HDMI.

We just needed to initialize a few more fields. Signed-off-by: Eric Anholt --- drivers/gpu/drm/vc4/vc4_crtc.c | 17 ++--- drivers/gpu/drm/vc4/vc4_hdmi.c | 12 drivers/gpu/drm/vc4/vc4_regs.h | 3 +++ 3 files changed, 25 insertions(+), 7 deletions(-)

[PATCH 1/2] drm/vc4: Increase timeout for HDMI_SCHEDULER_CONTROL changes.

Fixes occasional debug spew at boot when connected directly through HDMI, and probably confusing the HDMI state machine when we go trying to poke registers for the enable sequence too soon. Signed-off-by: Eric Anholt --- drivers/gpu/drm/vc4/vc4_hdmi.c | 4 ++-- 1 file changed, 2 insertions(+),

[PATCH 2/2] drm/vc4: Add support for interlaced modes on HDMI.

We just needed to initialize a few more fields. Signed-off-by: Eric Anholt --- drivers/gpu/drm/vc4/vc4_crtc.c | 17 ++--- drivers/gpu/drm/vc4/vc4_hdmi.c | 12 drivers/gpu/drm/vc4/vc4_regs.h | 3 +++ 3 files changed, 25 insertions(+), 7 deletions(-) diff --git

[PATCH V4 06/10] dmaengine: qcom_hidma: make error and success path common

Remove code duplication by feeding the error code from outside into successful data transfer handler. Signed-off-by: Sinan Kaya --- drivers/dma/qcom/hidma_ll.c | 34 ++ 1 file changed, 10 insertions(+), 24 deletions(-) diff --git

[PATCH V4 06/10] dmaengine: qcom_hidma: make error and success path common

Remove code duplication by feeding the error code from outside into successful data transfer handler. Signed-off-by: Sinan Kaya --- drivers/dma/qcom/hidma_ll.c | 34 ++ 1 file changed, 10 insertions(+), 24 deletions(-) diff --git a/drivers/dma/qcom/hidma_ll.c

[PATCH V4 07/10] dmaengine: qcom_hidma: bring out interrupt cause

Bring out the interrupt cause to the top level so that MSI interrupts can be hooked at a later stage. Signed-off-by: Sinan Kaya --- drivers/dma/qcom/hidma_ll.c | 72 + 1 file changed, 34 insertions(+), 38 deletions(-) diff --git

[PATCH V4 08/10] dmaengine: qcom_hidma: add a common API to setup the interrupt

Introducing the hidma_ll_setup_irq function to set up the interrupt type externally from the OS interface. Signed-off-by: Sinan Kaya --- drivers/dma/qcom/hidma.h| 2 ++ drivers/dma/qcom/hidma_ll.c | 27 +++ 2 files changed, 25 insertions(+), 4

[PATCH V4 09/10] dmaengine: qcom_hidma: protect common data structures

When MSI interrupts are supported, error and the transfer interrupt can come from multiple processor contexts. Each error interrupt is an MSI interrupt. If the channel is disabled by the first error interrupt, the remaining error interrupts will gracefully return in the interrupt handler. If an

[PATCH V4 10/10] dmaengine: qcom_hidma: add MSI support for interrupts

The interrupts can now be delivered as platform MSI interrupts on newer platforms. The code looks for a new OF and ACPI strings in order to enable the functionality. Signed-off-by: Sinan Kaya --- drivers/dma/qcom/hidma.c| 129

[PATCH V4 07/10] dmaengine: qcom_hidma: bring out interrupt cause

Bring out the interrupt cause to the top level so that MSI interrupts can be hooked at a later stage. Signed-off-by: Sinan Kaya --- drivers/dma/qcom/hidma_ll.c | 72 + 1 file changed, 34 insertions(+), 38 deletions(-) diff --git

[PATCH V4 08/10] dmaengine: qcom_hidma: add a common API to setup the interrupt

Introducing the hidma_ll_setup_irq function to set up the interrupt type externally from the OS interface. Signed-off-by: Sinan Kaya --- drivers/dma/qcom/hidma.h| 2 ++ drivers/dma/qcom/hidma_ll.c | 27 +++ 2 files changed, 25 insertions(+), 4 deletions(-) diff

[PATCH V4 09/10] dmaengine: qcom_hidma: protect common data structures

When MSI interrupts are supported, error and the transfer interrupt can come from multiple processor contexts. Each error interrupt is an MSI interrupt. If the channel is disabled by the first error interrupt, the remaining error interrupts will gracefully return in the interrupt handler. If an

[PATCH V4 10/10] dmaengine: qcom_hidma: add MSI support for interrupts

The interrupts can now be delivered as platform MSI interrupts on newer platforms. The code looks for a new OF and ACPI strings in order to enable the functionality. Signed-off-by: Sinan Kaya --- drivers/dma/qcom/hidma.c| 129 ++--

  1   2   3   4   5   6   7   8   9   10   >