[PATCH v7 03/13] x86/apic: Split local APIC timer setup from the APIC setup

apic_bsp_setup() sets up the local APIC, I/O APIC and APIC timer. The local APIC and I/O APIC setup belongs to interrupt delivery mode setup. Setting up the local APIC timer for booting CPU is another job and has nothing to do with interrupt delivery mode setup. Split local APIC timer setup from

[PATCH v7 03/13] x86/apic: Split local APIC timer setup from the APIC setup

apic_bsp_setup() sets up the local APIC, I/O APIC and APIC timer. The local APIC and I/O APIC setup belongs to interrupt delivery mode setup. Setting up the local APIC timer for booting CPU is another job and has nothing to do with interrupt delivery mode setup. Split local APIC timer setup from

[PATCH v7 09/13] x86/init: add intr_mode_init to x86_init_ops

X86 and XEN initialize interrupt delivery mode in different way. Ordinary conditional function calls will make the code mess. Add an unconditional x86_init_ops function which defaults to the standard function and can be overridden by the early platform code. Signed-off-by: Dou Liyang

[PATCH v7 09/13] x86/init: add intr_mode_init to x86_init_ops

X86 and XEN initialize interrupt delivery mode in different way. Ordinary conditional function calls will make the code mess. Add an unconditional x86_init_ops function which defaults to the standard function and can be overridden by the early platform code. Signed-off-by: Dou Liyang ---

[PATCH v7 08/13] x86/ioapic: Refactor the delay logic in timer_irq_works()

Kernel use timer_irq_works() to detects the timer IRQs. It calls mdelay(10) to delay ten ticks and check whether the timer IRQ work or not. The mdelay() depends on the loops_per_jiffy which is set up in calibrate_delay(). Current kernel defaults the IRQ 0 is available when it calibrates delay.

[PATCH v7 06/13] x86/apic: Mark the apic_intr_mode extern for sanity check cleanup

Calling native_smp_prepare_cpus() to prepare for SMP bootup, does some sanity checking, enables APIC mode and disables SMP feature. Now, APIC mode setup has been unified to apic_intr_mode_init(), some sanity checks are redundant and need to be cleanup. Mark the apic_intr_mode extern to refine

[PATCH v7 08/13] x86/ioapic: Refactor the delay logic in timer_irq_works()

Kernel use timer_irq_works() to detects the timer IRQs. It calls mdelay(10) to delay ten ticks and check whether the timer IRQ work or not. The mdelay() depends on the loops_per_jiffy which is set up in calibrate_delay(). Current kernel defaults the IRQ 0 is available when it calibrates delay.

[PATCH v7 06/13] x86/apic: Mark the apic_intr_mode extern for sanity check cleanup

Calling native_smp_prepare_cpus() to prepare for SMP bootup, does some sanity checking, enables APIC mode and disables SMP feature. Now, APIC mode setup has been unified to apic_intr_mode_init(), some sanity checks are redundant and need to be cleanup. Mark the apic_intr_mode extern to refine

Re: [PATCH 2/2] net: ethernet: nixge: Add support for National Instruments XGE netdev

Hi Moritz, [auto build test WARNING on net-next/master] [also build test WARNING on v4.12 next-20170713] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Moritz-Fischer/dt-bindings-net-Add

[PATCH v7 10/13] x86/xen: Bypass intr mode setup in enlighten_pv system

XEN PV overrides smp_prepare_cpus(). xen_pv_smp_prepare_cpus() initializes interrupts in the XEN PV specific way and does not invoke native_smp_prepare_cpus(). As a consequence, x86_init.intr_mode_init() is not invoked either. The invocation of x86_init.intr_mode_init() will be moved from

[PATCH v7 10/13] x86/xen: Bypass intr mode setup in enlighten_pv system

XEN PV overrides smp_prepare_cpus(). xen_pv_smp_prepare_cpus() initializes interrupts in the XEN PV specific way and does not invoke native_smp_prepare_cpus(). As a consequence, x86_init.intr_mode_init() is not invoked either. The invocation of x86_init.intr_mode_init() will be moved from

Re: [PATCH 2/2] net: ethernet: nixge: Add support for National Instruments XGE netdev

Hi Moritz, [auto build test WARNING on net-next/master] [also build test WARNING on v4.12 next-20170713] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Moritz-Fischer/dt-bindings-net-Add

[PATCH v7 13/13] x86/apic: Remove the init_bsp_APIC()

The init_bsp_APIC() which works for the virtual wire mode is used in ISA irq initialization at the booting time. Currently, enable and setup the interrupt mode has been unified and advanced just behind the timer IRQ setup. Kernel switches to the final interrupt delivery mode directly. So

[PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier

Linux uses acpi_early_init() to put the ACPI table management into the late stage from the early stage where the mapped ACPI tables is temporary and should be unmapped. But, now initializing interrupt delivery mode should map and parse the DMAR table earlier in the early stage. This causes an

[PATCH v7 13/13] x86/apic: Remove the init_bsp_APIC()

The init_bsp_APIC() which works for the virtual wire mode is used in ISA irq initialization at the booting time. Currently, enable and setup the interrupt mode has been unified and advanced just behind the timer IRQ setup. Kernel switches to the final interrupt delivery mode directly. So

[PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier

Linux uses acpi_early_init() to put the ACPI table management into the late stage from the early stage where the mapped ACPI tables is temporary and should be unmapped. But, now initializing interrupt delivery mode should map and parse the DMAR table earlier in the early stage. This causes an

[PATCH v7 11/13] x86/time: Initialize interrupt mode behind timer init

In start_kernel(), firstly, it works on the default interrupy mode, then switch to the final mode. Normally, Booting with BIOS reset is OK. But, At dump-capture kernel, it boot up without BIOS reset, default mode may not be compatible with the actual registers, that causes the delivery interrupt

[PATCH v7 11/13] x86/time: Initialize interrupt mode behind timer init

In start_kernel(), firstly, it works on the default interrupy mode, then switch to the final mode. Normally, Booting with BIOS reset is OK. But, At dump-capture kernel, it boot up without BIOS reset, default mode may not be compatible with the actual registers, that causes the delivery interrupt

[PATCH v7 04/13] x86/apic: Move logical APIC ID away from apic_bsp_setup()

apic_bsp_setup() sets and returns logical APIC ID for initializing cpu0_logical_apicid in SMP-capable system. The id has nothing to do with the initialization of local APIC and I/O APIC. And apic_bsp_setup() should be called for interrupt mode setup intently. Move the id setup into a separate

[PATCH v7 05/13] x86/apic: Unify interrupt mode setup for SMP-capable system

In the SMP-capable system, enable and setup the interrupt delivery mode in native_smp_prepare_cpus(). This design mixs the APIC and SMP together, it has highly coupling. Make the initialization of interrupt mode independent, Unify and refine it to apic_intr_mode_init() for SMP-capable system.

[PATCH v7 07/13] x86/apic: Unify interrupt mode setup for UP system

In UniProcessor kernel with UP_LATE_INIT=y, it enables and setups interrupt delivery mode in up_late_init(). Unify it to apic_intr_mode_init(), remove APIC_init_uniprocessor(). Signed-off-by: Dou Liyang --- arch/x86/include/asm/apic.h | 1 -

[PATCH v7 04/13] x86/apic: Move logical APIC ID away from apic_bsp_setup()

apic_bsp_setup() sets and returns logical APIC ID for initializing cpu0_logical_apicid in SMP-capable system. The id has nothing to do with the initialization of local APIC and I/O APIC. And apic_bsp_setup() should be called for interrupt mode setup intently. Move the id setup into a separate

[PATCH v7 05/13] x86/apic: Unify interrupt mode setup for SMP-capable system

In the SMP-capable system, enable and setup the interrupt delivery mode in native_smp_prepare_cpus(). This design mixs the APIC and SMP together, it has highly coupling. Make the initialization of interrupt mode independent, Unify and refine it to apic_intr_mode_init() for SMP-capable system.

[PATCH v7 07/13] x86/apic: Unify interrupt mode setup for UP system

In UniProcessor kernel with UP_LATE_INIT=y, it enables and setups interrupt delivery mode in up_late_init(). Unify it to apic_intr_mode_init(), remove APIC_init_uniprocessor(). Signed-off-by: Dou Liyang --- arch/x86/include/asm/apic.h | 1 - arch/x86/kernel/apic/apic.c | 47

[PATCH v7 01/13] x86/apic: Construct a selector for the interrupt delivery mode

Now, there are many switches in kernel which are used to determine the final interrupt delivery mode, as shown below: 1) kconfig: CONFIG_X86_64; CONFIG_X86_LOCAL_APIC; CONFIG_x86_IO_APIC 2) kernel option: disable_apic; skip_ioapic_setup 3) CPU Capability: boot_cpu_has(X86_FEATURE_APIC) 4) MP

[PATCH v7 02/13] x86/apic: Prepare for unifying the interrupt delivery modes setup

There are three positions for initializing the interrupt delivery modes: 1) In IRQ initial function, may setup the through-local-APIC virtual wire mode. 2) In an SMP-capable system, will try to switch to symmetric I/O model when preparing the cpus in native_smp_prepare_cpus(). 3) In UP

[PATCH v7 01/13] x86/apic: Construct a selector for the interrupt delivery mode

Now, there are many switches in kernel which are used to determine the final interrupt delivery mode, as shown below: 1) kconfig: CONFIG_X86_64; CONFIG_X86_LOCAL_APIC; CONFIG_x86_IO_APIC 2) kernel option: disable_apic; skip_ioapic_setup 3) CPU Capability: boot_cpu_has(X86_FEATURE_APIC) 4) MP

[PATCH v7 02/13] x86/apic: Prepare for unifying the interrupt delivery modes setup

There are three positions for initializing the interrupt delivery modes: 1) In IRQ initial function, may setup the through-local-APIC virtual wire mode. 2) In an SMP-capable system, will try to switch to symmetric I/O model when preparing the cpus in native_smp_prepare_cpus(). 3) In UP

[PATCH v7 00/13] Unify the interrupt delivery mode and do its setup in advance

[Background] MP specification defines three different interrupt delivery modes as follows: 1. PIC Mode 2. Virtual Wire Mode 3. Symmetric I/O Mode They will be setup in the different periods of booting time: 1. *PIC Mode*, the default interrupt delivery modes, will be set first. 2. *Virtual

[PATCH v7 00/13] Unify the interrupt delivery mode and do its setup in advance

[Background] MP specification defines three different interrupt delivery modes as follows: 1. PIC Mode 2. Virtual Wire Mode 3. Symmetric I/O Mode They will be setup in the different periods of booting time: 1. *PIC Mode*, the default interrupt delivery modes, will be set first. 2. *Virtual

Re: [PATCH] usb: gadget: functions: add ftrace export over USB

Hi Felipe, On Friday 09 June 2017 03:58 PM, Felipe Balbi wrote: Felipe Balbi writes: Allow for ftrace data to be exported over a USB Gadget Controller. With this, we have a potentially very fast pipe for transmitting ftrace data to a Host PC for further

Re: [PATCH] usb: gadget: functions: add ftrace export over USB

Hi Felipe, On Friday 09 June 2017 03:58 PM, Felipe Balbi wrote: Felipe Balbi writes: Allow for ftrace data to be exported over a USB Gadget Controller. With this, we have a potentially very fast pipe for transmitting ftrace data to a Host PC for further analysis. Note that in order to

Re: [PATCH v2 0/3] pwm: add pwm AO on meson gx

Hi Thierry, > I /think/ Jeremy Kerr (To'ed) would be a good person to contact about > this. > > Jeremy, anything you can do about this? OK, all sorted. I've updated Jerome's entry in the database to suit. Cheers, Jeremy

Re: [PATCH v2 0/3] pwm: add pwm AO on meson gx

Hi Thierry, > I /think/ Jeremy Kerr (To'ed) would be a good person to contact about > this. > > Jeremy, anything you can do about this? OK, all sorted. I've updated Jerome's entry in the database to suit. Cheers, Jeremy

Re: [PATCH 1/4] drm/atomic: implement drm_atomic_helper_commit_tail for runtime_pm users

On Fri, Jul 14, 2017 at 1:43 AM, Laurent Pinchart wrote: >> Commit 52055bafa1ff ("drm: rcar-du: Move plane commit code from CRTC >> start to CRTC resume") changed the order of the plane commit and CRTC >> enable operations to accommodate the runtime PM

Re: [PATCH 1/4] drm/atomic: implement drm_atomic_helper_commit_tail for runtime_pm users

On Fri, Jul 14, 2017 at 1:43 AM, Laurent Pinchart wrote: >> Commit 52055bafa1ff ("drm: rcar-du: Move plane commit code from CRTC >> start to CRTC resume") changed the order of the plane commit and CRTC >> enable operations to accommodate the runtime PM requirements. However, >> this introduced

Re: [PATCH] usb: gadget: functions: add ftrace export over USB

Hi Felipe, On Friday 09 June 2017 11:43 AM, Felipe Balbi wrote: +static void notrace ftrace_write(struct trace_export *ftrace, const void *buf, +unsigned int len) +{ + struct usb_ftrace *trace = ftrace_to_trace(ftrace); + struct

Re: [PATCH] usb: gadget: functions: add ftrace export over USB

Hi Felipe, On Friday 09 June 2017 11:43 AM, Felipe Balbi wrote: +static void notrace ftrace_write(struct trace_export *ftrace, const void *buf, +unsigned int len) +{ + struct usb_ftrace *trace = ftrace_to_trace(ftrace); + struct

Re: [PATCH 03/32] ring-buffer: Add interface for setting absolute time stamps

On Mon, Jun 26, 2017 at 05:49:04PM -0500, Tom Zanussi wrote: > Define a new function, tracing_set_time_stamp_abs(), which can be used > to enable or disable the use of absolute timestamps rather than time > deltas for a trace array. > > This resets the buffer to prevent a mix of time deltas and

Re: [PATCH 03/32] ring-buffer: Add interface for setting absolute time stamps

On Mon, Jun 26, 2017 at 05:49:04PM -0500, Tom Zanussi wrote: > Define a new function, tracing_set_time_stamp_abs(), which can be used > to enable or disable the use of absolute timestamps rather than time > deltas for a trace array. > > This resets the buffer to prevent a mix of time deltas and

Re: [PATCH 0/2] i2c: move include files out of include/linux/i2c

On 2017-07-13 11:46, Wolfram Sang wrote: > Hi peda, > > On Sun, May 21, 2017 at 10:37:41PM +0200, Wolfram Sang wrote: >> It doesn't make sense to use include/linux/i2c for client drivers which may >> in >> fact rather be hwmon or input or whatever devices. As a result, I want to >> deprecate

Re: [PATCH 0/2] i2c: move include files out of include/linux/i2c

On 2017-07-13 11:46, Wolfram Sang wrote: > Hi peda, > > On Sun, May 21, 2017 at 10:37:41PM +0200, Wolfram Sang wrote: >> It doesn't make sense to use include/linux/i2c for client drivers which may >> in >> fact rather be hwmon or input or whatever devices. As a result, I want to >> deprecate

Re: [PATCH 08/17] tty: New RISC-V SBI console driver

Palmer Dabbelt writes: > On Thu, 13 Jul 2017 05:32:26 PDT (-0700), james.ho...@imgtec.com wrote: >> On Thu, Jul 13, 2017 at 09:59:53PM +1000, Michael Ellerman wrote: >>> >>> I think it's fairly uncontroversial to have the early console in arch >>> code, especially in a case

Re: [PATCH 08/17] tty: New RISC-V SBI console driver

Palmer Dabbelt writes: > On Thu, 13 Jul 2017 05:32:26 PDT (-0700), james.ho...@imgtec.com wrote: >> On Thu, Jul 13, 2017 at 09:59:53PM +1000, Michael Ellerman wrote: >>> >>> I think it's fairly uncontroversial to have the early console in arch >>> code, especially in a case like this where

Re: [Eas-dev] [PATCH V3 2/3] cpufreq: schedutil: Process remote callback for shared policies

On 13-07-17, 19:02, Saravana Kannan wrote: > Honestly, this seems like such a chip/platform specific decision. There's no > reason that one can't have a chip where you can change the frequency of any > CPU from any other CPU. If there's such a limitation, we should let that be > handled at the CPU

Re: [Eas-dev] [PATCH V3 2/3] cpufreq: schedutil: Process remote callback for shared policies

On 13-07-17, 19:02, Saravana Kannan wrote: > Honestly, this seems like such a chip/platform specific decision. There's no > reason that one can't have a chip where you can change the frequency of any > CPU from any other CPU. If there's such a limitation, we should let that be > handled at the CPU

Re: linux-next: manual merge of the rdma tree with Linus' tree

On Fri, Jul 14, 2017 at 01:50:26PM +1000, Stephen Rothwell wrote: > Hi all, > > On Fri, 14 Jul 2017 06:34:16 +0300 Leon Romanovsky wrote: > > > > Sorry Doug, but it is not expected at all for the code which will go to > > 4.14. > > > > Both patches in question were targeted for

Re: linux-next: manual merge of the rdma tree with Linus' tree

On Fri, Jul 14, 2017 at 01:50:26PM +1000, Stephen Rothwell wrote: > Hi all, > > On Fri, 14 Jul 2017 06:34:16 +0300 Leon Romanovsky wrote: > > > > Sorry Doug, but it is not expected at all for the code which will go to > > 4.14. > > > > Both patches in question were targeted for 4.13 and you was

Re: linux-next: manual merge of the rdma tree with Linus' tree

On Fri, Jul 14, 2017 at 12:12:33AM -0400, Doug Ledford wrote: > On Fri, 2017-07-14 at 06:34 +0300, Leon Romanovsky wrote: > > On Thu, Jul 13, 2017 at 09:17:13PM -0400, Doug Ledford wrote: > > > On Fri, 2017-07-14 at 11:14 +1000, Stephen Rothwell wrote: > > > > Hi Doug, > > > > > > > > Today's

Re: linux-next: manual merge of the rdma tree with Linus' tree

On Fri, Jul 14, 2017 at 12:12:33AM -0400, Doug Ledford wrote: > On Fri, 2017-07-14 at 06:34 +0300, Leon Romanovsky wrote: > > On Thu, Jul 13, 2017 at 09:17:13PM -0400, Doug Ledford wrote: > > > On Fri, 2017-07-14 at 11:14 +1000, Stephen Rothwell wrote: > > > > Hi Doug, > > > > > > > > Today's

Re: [PATCH] mm/mremap: Fail map duplication attempts for private mappings

On 07/14/2017 04:03 AM, Mike Kravetz wrote: > On 07/13/2017 12:11 PM, Vlastimil Babka wrote: >> [+CC linux-api] >> >> On 07/13/2017 05:58 PM, Mike Kravetz wrote: >>> mremap will create a 'duplicate' mapping if old_size == 0 is >>> specified. Such duplicate mappings make no sense for private >>>

Re: [PATCH] mm/mremap: Fail map duplication attempts for private mappings

On 07/14/2017 04:03 AM, Mike Kravetz wrote: > On 07/13/2017 12:11 PM, Vlastimil Babka wrote: >> [+CC linux-api] >> >> On 07/13/2017 05:58 PM, Mike Kravetz wrote: >>> mremap will create a 'duplicate' mapping if old_size == 0 is >>> specified. Such duplicate mappings make no sense for private >>>

Re: [PATCH] Crypto_user: Make crypto user API available for all net ns

On Thu, Jul 13, 2017 at 04:51:10PM +0200, Stephan Müller wrote: > Am Donnerstag, 13. Juli 2017, 16:22:32 CEST schrieb Christian Langrock: > > Hi Christian, > > > With this patch it's possible to use crypto user API form all > > network namespaces, not only form the initial net ns. > > Is this

Re: [PATCH] Crypto_user: Make crypto user API available for all net ns

On Thu, Jul 13, 2017 at 04:51:10PM +0200, Stephan Müller wrote: > Am Donnerstag, 13. Juli 2017, 16:22:32 CEST schrieb Christian Langrock: > > Hi Christian, > > > With this patch it's possible to use crypto user API form all > > network namespaces, not only form the initial net ns. > > Is this

Re: [PATCH 17/18] arm: dts: sun8i: Add BananaPI M2-Magic DTS

On Thu, Jul 13, 2017 at 10:13 PM, Maxime Ripard wrote: > The Bananapi M2-Magic is a board with an A33, a USB host and USB OTG > connectors, and 8GB eMMC, an AP6212 WiFi/Bluetooth chip and connectors for > DSI, CSI and GPIOs. > > Signed-off-by: Maxime Ripard

Re: [PATCH 17/18] arm: dts: sun8i: Add BananaPI M2-Magic DTS

On Thu, Jul 13, 2017 at 10:13 PM, Maxime Ripard wrote: > The Bananapi M2-Magic is a board with an A33, a USB host and USB OTG > connectors, and 8GB eMMC, an AP6212 WiFi/Bluetooth chip and connectors for > DSI, CSI and GPIOs. > > Signed-off-by: Maxime Ripard Reviewed-by: Chen-Yu Tsai Has BPI

[PATCH] ARM: mm: iomap: use is_vmalloc_addr

Instead of manually checking the bounds of VMALLOC_START and VMALLOC_END, use is_vmalloc_addr. Such function was specifically designed for that purpose. Signed-off-by: Gustavo A. R. Silva --- arch/arm/mm/iomap.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)

[PATCH] ARM: mm: iomap: use is_vmalloc_addr

Instead of manually checking the bounds of VMALLOC_START and VMALLOC_END, use is_vmalloc_addr. Such function was specifically designed for that purpose. Signed-off-by: Gustavo A. R. Silva --- arch/arm/mm/iomap.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

Re: [PATCH 09/18] drm/sun4i: tcon: Adjust dotclock dividers range

On Thu, Jul 13, 2017 at 10:13 PM, Maxime Ripard wrote: > It seems like the dotclock dividers are a bit less strict range, and can > operate even with a smaller than 6 divider. Loose the boundaries a bit. > > Signed-off-by: Maxime Ripard

Re: [PATCH 09/18] drm/sun4i: tcon: Adjust dotclock dividers range

On Thu, Jul 13, 2017 at 10:13 PM, Maxime Ripard wrote: > It seems like the dotclock dividers are a bit less strict range, and can > operate even with a smaller than 6 divider. Loose the boundaries a bit. > > Signed-off-by: Maxime Ripard > --- > drivers/gpu/drm/sun4i/sun4i_dotclock.c | 20

Re: linux-next: manual merge of the rdma tree with Linus' tree

On Fri, 2017-07-14 at 06:34 +0300, Leon Romanovsky wrote: > On Thu, Jul 13, 2017 at 09:17:13PM -0400, Doug Ledford wrote: > > On Fri, 2017-07-14 at 11:14 +1000, Stephen Rothwell wrote: > > > Hi Doug, > > > > > > Today's linux-next merge of the rdma tree got conflicts in: > > > > > >

Re: linux-next: manual merge of the rdma tree with Linus' tree

On Fri, 2017-07-14 at 06:34 +0300, Leon Romanovsky wrote: > On Thu, Jul 13, 2017 at 09:17:13PM -0400, Doug Ledford wrote: > > On Fri, 2017-07-14 at 11:14 +1000, Stephen Rothwell wrote: > > > Hi Doug, > > > > > > Today's linux-next merge of the rdma tree got conflicts in: > > > > > >

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On Fri, Jul 14, 2017 at 11:47:32AM +0800, Li, Aubrey wrote: > On 2017/7/13 23:20, Paul E. McKenney wrote: > > On Thu, Jul 13, 2017 at 04:53:11PM +0200, Peter Zijlstra wrote: > >> On Thu, Jul 13, 2017 at 10:48:55PM +0800, Li, Aubrey wrote: > >> > >>> - totally from arch_cpu_idle_enter entry to

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On Fri, Jul 14, 2017 at 11:47:32AM +0800, Li, Aubrey wrote: > On 2017/7/13 23:20, Paul E. McKenney wrote: > > On Thu, Jul 13, 2017 at 04:53:11PM +0200, Peter Zijlstra wrote: > >> On Thu, Jul 13, 2017 at 10:48:55PM +0800, Li, Aubrey wrote: > >> > >>> - totally from arch_cpu_idle_enter entry to

Re: [PATCH] cpufreq: schedutil: Update cached "current frequency" when limits change

On 13-07-17, 18:52, Saravana Kannan wrote: > On 07/11/2017 10:24 PM, Viresh Kumar wrote: > >On 11-07-17, 19:24, Saravana Kannan wrote: > >>Currently, the governor calculates the next frequency, set the current CPU > >>frequency (policy->cur). It also assumes the current CPU frequency doesn't >

Re: [PATCH] cpufreq: schedutil: Update cached "current frequency" when limits change

On 13-07-17, 18:52, Saravana Kannan wrote: > On 07/11/2017 10:24 PM, Viresh Kumar wrote: > >On 11-07-17, 19:24, Saravana Kannan wrote: > >>Currently, the governor calculates the next frequency, set the current CPU > >>frequency (policy->cur). It also assumes the current CPU frequency doesn't >

Re: [PATCH 08/18] drm/sun4i: tcon: Add TRI finish interrupt for vblank

On Thu, Jul 13, 2017 at 10:13 PM, Maxime Ripard wrote: > The "CPU" (or Intel 8080) interface uses a different interrupt called > TRI_FINISH (most likely TRI being for trigger) to notify the end of frames, > and hence the VBLANK period. > > And that interrupt to

Re: [PATCH 2/2] mfd: ds1374: Add Dallas/Maxim DS1374 Multi Function Device

On 07/13/2017 12:54 PM, Moritz Fischer wrote: From: Moritz Fischer Add support for the Maxim/Dallas DS1374 RTC/WDT with trickle charger. The device can either be configured as simple RTC, as simple RTC with Alarm (IRQ) as well as simple RTC with watchdog timer. Break

linux-next: Tree for Jul 14

Hi all, Please do not add any v4.14 material to you linux-next included branches until after v4.13-rc1 has been released. Changes since 20170713: The rdma tree gained a conflict against Linus' tree. The random tree gained a conflict against Linus' tree. Non-merge commits (relative to Linus

Re: [PATCH 08/18] drm/sun4i: tcon: Add TRI finish interrupt for vblank

On Thu, Jul 13, 2017 at 10:13 PM, Maxime Ripard wrote: > The "CPU" (or Intel 8080) interface uses a different interrupt called > TRI_FINISH (most likely TRI being for trigger) to notify the end of frames, > and hence the VBLANK period. > > And that interrupt to the possible VBLANK interrupts

Re: [PATCH 2/2] mfd: ds1374: Add Dallas/Maxim DS1374 Multi Function Device

On 07/13/2017 12:54 PM, Moritz Fischer wrote: From: Moritz Fischer Add support for the Maxim/Dallas DS1374 RTC/WDT with trickle charger. The device can either be configured as simple RTC, as simple RTC with Alarm (IRQ) as well as simple RTC with watchdog timer. Break up the old monolithic

linux-next: Tree for Jul 14

Hi all, Please do not add any v4.14 material to you linux-next included branches until after v4.13-rc1 has been released. Changes since 20170713: The rdma tree gained a conflict against Linus' tree. The random tree gained a conflict against Linus' tree. Non-merge commits (relative to Linus

Re: [PATCH 07/18] drm/sun4i: tcon: Don't rely on encoders to set the TCON mode

On Thu, Jul 13, 2017 at 10:13 PM, Maxime Ripard wrote: > Just like we did for the TCON enable and disable, for historical reasons we > used to rely on the encoders calling the TCON mode_set function, while the > CRTC has a callback for that. > > Let's implement

Re: [PATCH 07/18] drm/sun4i: tcon: Don't rely on encoders to set the TCON mode

On Thu, Jul 13, 2017 at 10:13 PM, Maxime Ripard wrote: > Just like we did for the TCON enable and disable, for historical reasons we > used to rely on the encoders calling the TCON mode_set function, while the > CRTC has a callback for that. > > Let's implement it in order to reduce the

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 2017/7/14 2:28, Peter Zijlstra wrote: > On Thu, Jul 13, 2017 at 11:13:28PM +0800, Li, Aubrey wrote: >> On 2017/7/13 22:53, Peter Zijlstra wrote: > >>> Fixing C-state selection by creating an alternative idle path sounds so >>> very wrong. >> >> This only happens on the arch which has multiple

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 2017/7/14 2:28, Peter Zijlstra wrote: > On Thu, Jul 13, 2017 at 11:13:28PM +0800, Li, Aubrey wrote: >> On 2017/7/13 22:53, Peter Zijlstra wrote: > >>> Fixing C-state selection by creating an alternative idle path sounds so >>> very wrong. >> >> This only happens on the arch which has multiple

Re: linux-next: manual merge of the rdma tree with Linus' tree

Hi all, On Fri, 14 Jul 2017 06:34:16 +0300 Leon Romanovsky wrote: > > Sorry Doug, but it is not expected at all for the code which will go to 4.14. > > Both patches in question were targeted for 4.13 and you was expected to > see the merge conflicts during last month or so,

Re: linux-next: manual merge of the rdma tree with Linus' tree

Hi all, On Fri, 14 Jul 2017 06:34:16 +0300 Leon Romanovsky wrote: > > Sorry Doug, but it is not expected at all for the code which will go to 4.14. > > Both patches in question were targeted for 4.13 and you was expected to > see the merge conflicts during last month or so, prior to merge

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 2017/7/13 23:20, Paul E. McKenney wrote: > On Thu, Jul 13, 2017 at 04:53:11PM +0200, Peter Zijlstra wrote: >> On Thu, Jul 13, 2017 at 10:48:55PM +0800, Li, Aubrey wrote: >> >>> - totally from arch_cpu_idle_enter entry to arch_cpu_idle_exit return costs >>> 9122ns - 15318ns. >>> In this

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 2017/7/13 23:20, Paul E. McKenney wrote: > On Thu, Jul 13, 2017 at 04:53:11PM +0200, Peter Zijlstra wrote: >> On Thu, Jul 13, 2017 at 10:48:55PM +0800, Li, Aubrey wrote: >> >>> - totally from arch_cpu_idle_enter entry to arch_cpu_idle_exit return costs >>> 9122ns - 15318ns. >>> In this

Re: [PATCH 06/18] drm/sun4i: tcon: Don't rely on encoders to enable the TCON

On Thu, Jul 13, 2017 at 10:13 PM, Maxime Ripard wrote: > So far, we've required all the TCON-connected encoders to call the TCON > enable and disable functions. > > This was made this way because in the RGB/LVDS case, the TCON is the CRTC > and the encoder.

Re: [PATCH 06/18] drm/sun4i: tcon: Don't rely on encoders to enable the TCON

On Thu, Jul 13, 2017 at 10:13 PM, Maxime Ripard wrote: > So far, we've required all the TCON-connected encoders to call the TCON > enable and disable functions. > > This was made this way because in the RGB/LVDS case, the TCON is the CRTC > and the encoder. However, in all the other cases (HDMI,

Re: [PATCH 2/2] net: ethernet: nixge: Add support for National Instruments XGE netdev

Hi Andrew, On Thu, Jul 13, 2017 at 6:34 PM, Andrew Lunn wrote: >> > > + /* not sure if this is the correct way of dealing with this ... */ >> > > + ndev->phydev->supported &= ~(SUPPORTED_Autoneg); >> > > + ndev->phydev->advertising = ndev->phydev->supported; >> > > +

Re: [PATCH 2/2] net: ethernet: nixge: Add support for National Instruments XGE netdev

Hi Andrew, On Thu, Jul 13, 2017 at 6:34 PM, Andrew Lunn wrote: >> > > + /* not sure if this is the correct way of dealing with this ... */ >> > > + ndev->phydev->supported &= ~(SUPPORTED_Autoneg); >> > > + ndev->phydev->advertising = ndev->phydev->supported; >> > > + ndev->phydev->autoneg =

[PATCH 1/2] x86/timers: Move the simple udelay calibration to tsc.h

Commit dd759d93f4dd ("x86/timers: Add simple udelay calibration") adds an static function in x86 boot-time initializations. But, this function is actually related to TSC, should be maintained in tsc.c, not in setup.c. Move simple_udelay_calibration() from setup.c to tsc.c and repalce its name

[PATCH 2/2] x86/timers: Make recalibrate_cpu_khz() void

recalibrate_cpu_khz() is called from powernow K7 and Pentium 4/Xeon CPU freq driver. It recalibrates cpu frequency in case of SMP = n and doesn't need to return anything. Mark it void, also remove the #else branch. Signed-off-by: Dou Liyang ---

[PATCH 2/2] x86/timers: Make recalibrate_cpu_khz() void

recalibrate_cpu_khz() is called from powernow K7 and Pentium 4/Xeon CPU freq driver. It recalibrates cpu frequency in case of SMP = n and doesn't need to return anything. Mark it void, also remove the #else branch. Signed-off-by: Dou Liyang --- arch/x86/include/asm/timer.h | 2 +-

[PATCH 1/2] x86/timers: Move the simple udelay calibration to tsc.h

Commit dd759d93f4dd ("x86/timers: Add simple udelay calibration") adds an static function in x86 boot-time initializations. But, this function is actually related to TSC, should be maintained in tsc.c, not in setup.c. Move simple_udelay_calibration() from setup.c to tsc.c and repalce its name

Re: linux-next: manual merge of the rdma tree with Linus' tree

On Thu, Jul 13, 2017 at 09:17:13PM -0400, Doug Ledford wrote: > On Fri, 2017-07-14 at 11:14 +1000, Stephen Rothwell wrote: > > Hi Doug, > > > > Today's linux-next merge of the rdma tree got conflicts in: > > > > drivers/infiniband/core/uverbs_cmd.c > > drivers/infiniband/core/verbs.c > > > >

Re: linux-next: manual merge of the rdma tree with Linus' tree

On Thu, Jul 13, 2017 at 09:17:13PM -0400, Doug Ledford wrote: > On Fri, 2017-07-14 at 11:14 +1000, Stephen Rothwell wrote: > > Hi Doug, > > > > Today's linux-next merge of the rdma tree got conflicts in: > > > > drivers/infiniband/core/uverbs_cmd.c > > drivers/infiniband/core/verbs.c > > > >

Re: [PATCH] IB/hfi1: fix spelling mistake in variable name continious

On 7/13/2017 6:13 PM, Colin King wrote: From: Colin Ian King Trivial fix to spelling mistake, rename variable 'continious' to the correct spelling 'continuous' Signed-off-by: Colin Ian King --- Thanks! Acked-by: Dennis Dalessandro

Re: [PATCH] IB/hfi1: fix spelling mistake in variable name continious

On 7/13/2017 6:13 PM, Colin King wrote: From: Colin Ian King Trivial fix to spelling mistake, rename variable 'continious' to the correct spelling 'continuous' Signed-off-by: Colin Ian King --- Thanks! Acked-by: Dennis Dalessandro

Re: [PATCH v8 1/5] x86: add simple udelay calibration

Hi, Lu At 07/13/2017 11:00 AM, Lu Baolu wrote: Hi, On 07/13/2017 09:39 AM, Dou Liyang wrote: Hi, Lu At 07/13/2017 09:17 AM, Lu Baolu wrote: Hi, On 07/12/2017 04:02 PM, Dou Liyang wrote: Hi, Lu At 05/05/2017 08:50 PM, Boris Ostrovsky wrote: On 05/05/2017 01:41 AM, Lu Baolu wrote: Hi,

Re: [PATCH v8 1/5] x86: add simple udelay calibration

Hi, Lu At 07/13/2017 11:00 AM, Lu Baolu wrote: Hi, On 07/13/2017 09:39 AM, Dou Liyang wrote: Hi, Lu At 07/13/2017 09:17 AM, Lu Baolu wrote: Hi, On 07/12/2017 04:02 PM, Dou Liyang wrote: Hi, Lu At 05/05/2017 08:50 PM, Boris Ostrovsky wrote: On 05/05/2017 01:41 AM, Lu Baolu wrote: Hi,

Re: [PATCH 02/17] pci: Add a generic, weakly-linked pcibios_align_resource

Hi Palmer, [auto build test ERROR on linus/master] [also build test ERROR on next-20170713] [cannot apply to v4.12] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Palmer-Dabbelt/lib-Add-shared

Re: [PATCH 02/17] pci: Add a generic, weakly-linked pcibios_align_resource

Hi Palmer, [auto build test ERROR on linus/master] [also build test ERROR on next-20170713] [cannot apply to v4.12] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Palmer-Dabbelt/lib-Add-shared

Re: [PATCH 05/18] drm/sun4i: tcon: remove unused function

On Thu, Jul 13, 2017 at 10:13 PM, Maxime Ripard wrote: > Even though that function is defined in the TCON header, it's not defined > nor used anywhere. Remove the prototype. > > Signed-off-by: Maxime Ripard Reviewed-by: Chen-Yu

Re: [PATCH 05/18] drm/sun4i: tcon: remove unused function

On Thu, Jul 13, 2017 at 10:13 PM, Maxime Ripard wrote: > Even though that function is defined in the TCON header, it's not defined > nor used anywhere. Remove the prototype. > > Signed-off-by: Maxime Ripard Reviewed-by: Chen-Yu Tsai

Re: [PATCH 04/18] drm/sun4i: Remove useless atomic_check

On Thu, Jul 13, 2017 at 10:12 PM, Maxime Ripard wrote: > The atomic_check callback is optional, and we don't implement anything in > some parts of our drivers. Let's remove it. > > Signed-off-by: Maxime Ripard Reviewed-by:

Re: [PATCH 04/18] drm/sun4i: Remove useless atomic_check

On Thu, Jul 13, 2017 at 10:12 PM, Maxime Ripard wrote: > The atomic_check callback is optional, and we don't implement anything in > some parts of our drivers. Let's remove it. > > Signed-off-by: Maxime Ripard Reviewed-by: Chen-Yu Tsai

  1   2   3   4   5   6   7   8   9   10   >