Hello.
On 09/26/2013 09:21 PM, Guennadi Liakhovetski wrote:
The Lager board uses a DA9210 voltage regulator to supply DVFS power to the
CA15 cores on the r8a7790 SoC. This patch adds CPUFreq support for that
board using the cpufreq-cpu0 driver.
Signed-off-by: Guennadi Liakhovetski
---
v2
2013.09.26. 8:18 keltezéssel, Hans-Christian Egtvedt írta:
> Around Wed 25 Sep 2013 21:50:01 +0200 or thereabout, Gabor Juhos wrote:
>
> Tuning subject to
>
> avr32: cast syscall_return to silence compiler warning
This is indeed better, thanks.
>
>> The patch fixes the following compiler warni
On Sep 19, 2013, at 12:54 PM, Stephen Warren wrote:
> From: Stephen Warren
>
> ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any
> node that has a reg property must include a unit address in its name
> with value matching the first entry in its reg property. Conversely, if
>
On Thu, 2013-09-26 at 10:40 +0200, Peter Zijlstra wrote:
> On Thu, Sep 26, 2013 at 08:46:29AM +0200, Ingo Molnar wrote:
> > > +/*
> > > + * MCS lock defines
> > > + *
> > > + * This file contains the main data structure and API definitions of MCS
> > > lock.
> >
> > A (very) short blurb about wha
On Thu, 2013-09-26 at 09:09 +0800, zhang.y...@zte.com.cn wrote:
> Hi all,
>
> Task processes all its owned robust futex when it is exiting,
> to ensure the futexes can be taken by other tasks.
>
> Though this can not work good in sometimes.
> Think about this scene：
> 1. A robust mutex is shared
Hi Mateusz,
On Thursday, September 26, 2013 06:59:29 PM Mateusz Krawczuk wrote:
> Add DTS for s5pc110 boards: goni, aquila, smdkc110
> s5pv210: smdkv210, tiny210
> Torbreck is replaced by FriendlyARM Tiny210 board.
Could you please explain what do you mean by "replaced" here?
Looking at the cur
On 9/26/13 11:51 AM, Jiri Olsa wrote:
but it's still faster, since we finally get perf a chance to sleep ;-)
new time:
real0m30.392s
user0m0.041s
sys 0m0.389s
old time:
real0m32.235s
user0m3.080s
sys 0m14.444s
excellent.
> From: Joe Perches [mailto:j...@perches.com]
> >
> > The W: link is dead.
> >
> > Given wimax never really took off, is there any point in keeping this in
> > the kernel at all ?
> > We turned off the drivers in Fedora a while ago, and just threw out the
> > userspace parts.
> > I wouldn't be su
> > -rw-r--r-- 1 mroos mroos 97 Sep 20 21:56
> > include/generated/uapi/linux/version.h
> > -rw-r--r-- 1 mroos mroos 97 Aug 10 2012 ./include/linux/version.h
>
> It's not the it doesn't get updated.
>
> It's that the file in your GIT tree is unsync'd.
>
> You need to "rm include/linux/version.
On Thu, Sep 26, 2013 at 5:34 PM, J. Bruce Fields wrote:
> On Thu, Sep 26, 2013 at 10:58:05AM +0200, Miklos Szeredi wrote:
>> On Wed, Sep 25, 2013 at 11:07 PM, Zach Brown wrote:
>> >> A client-side copy will be slower, but I guess it does have the
>> >> advantage that the application can track pro
Arjan, are you referring to the fact that Intel/SNB systems can exploit
memory self-refresh only when the entire system goes idle? Is that why
this
patchset won't turn out to be that useful on those platforms?
no we can use other things (CKE and co) all the time.
Ah, ok..
just that we fo
On 9/26/2013 9:37 AM, Kumar Gala wrote:
+++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
@@ -0,0 +1,6 @@
+/include/ "qcom-msm8974.dtsi"
+
+/ {
+ model = "Qualcomm APQ8074 Dragonboard";
+ compatible = "qcom,apq8074-dragonboard", "qcom,apq8074";
+};
diff --git a/arch/arm/boot/dt
On Thu, 26 Sep 2013 13:35:32 -0400 Peter Hurley
wrote:
> The issue with a single large kmalloc is that it may fail where
> 3 separate, page-or-less kmallocs would not have.
Or vmalloc fails first, because of internal fragmentation of the vmap
arena. This problem plus vmalloc's slowness are the
Zoltan Kiss wrote:
>On 25/09/13 18:56, Konrad Rzeszutek Wilk wrote:
>> On Wed, Sep 18, 2013 at 05:04:17PM +0100, Zoltan Kiss wrote:
>>> Hi,
>>>
>>> I haven't got a reply in the past 2 weeks, so I would like to bump
>>> the patch, just to make sure it haven't fell off the radar.
>>
>> Hey,
>>
>> I
On Thu, 2013-09-26 at 13:44 -0400, David Miller wrote:
> From: Joe Perches
> Date: Wed, 25 Sep 2013 12:37:18 -0700
[]
> Pulled, thanks Joe.
> That should be about it for networking right?
Yes for drivers/net/...
There are some more files like:
include/linux/etherdevice.h
include/linux/inetdevic
On Mon, Sep 23, 2013 at 06:00:49PM -0300, Gustavo Padovan wrote:
> Hi John,
>
> First Bluetooth fixes to 3.12, it includes:
>
> * 3 patches to add device id for 3 new hardwares.
>
> * 2 patches from Johan to fix the rfkill behaviour during setup stage
>
> * a small clean up in the rfcomm TTY co
On Thu, Sep 26, 2013 at 04:29:41PM +0100, Charles Keepax wrote:
Please include some context in replies...
> I had considered adding something like a recursive regulator get
> that works it's way up the tree but this felt rather invasive and
> most places the user code does the regulator get rathe
Hi Chris,
On Thu, Sep 26, 2013 at 06:24:53PM +0100, Chris Metcalf wrote:
> It turns out the kernel relies on barrier() to force a reload of the
> percpu offset value. Since we can't easily modify the definition of
> barrier() to include "tp" as an output register, we instead provide a
> definitio
On Thu, Sep 26, 2013 at 02:56:17PM +, Zuckerman, Boris wrote:
> To work with persistent memory as efficiently as we can work with RAM we need
> a bit more than "commit". It's reasonable to expect that we get some
> additional support from CPUs that goes beyond mfence and mflush. That may
> i
On Sun, Sep 22, 2013 at 08:05:59PM -0600, David Ahern wrote:
> When recording raw_syscalls for the entire system, e.g.,
> perf record -e raw_syscalls:*,sched:sched_switch -a -- sleep 1
>
> you end up with a negative feedback loop as perf itself calls
> write() fairly often. This patch mmap's t
On Thu, Sep 26, 2013 at 06:58:40PM +0200, Oleg Nesterov wrote:
> Peter,
>
> Sorry. Unlikely I will be able to read this patch today. So let me
> ask another potentially wrong question without any thinking.
>
> On 09/26, Peter Zijlstra wrote:
> >
> > +void __get_online_cpus(void)
> > +{
> > +again
On Thu, Sep 26, 2013 at 04:22:48AM +, Jongman Heo wrote:
>
> Hi,
>
> >
> >--- Original Message ---
> >Sender : J. Bruce Fields
> >Date : 2013-09-25 23:05 (GMT+09:00)
> >Title : Re: Regression caused by commit 4bdc33ed ("NFSDv4.2: Add NFS v4.2
> >support to the NFS server")
> >
> >On
From: Joe Perches
Date: Wed, 25 Sep 2013 12:37:18 -0700
> The following changes since commit 294da3abaa73a0b69fd54e442b0b5bd9455b7be6:
>
> irda: Remove extern from function prototypes (2013-09-24 12:54:17 -0700)
>
> are available in the git repository at:
>
> git://repo.or.cz/linux-2.6/tri
On Thu, Sep 26, 2013 at 09:43:38AM -0700, Linus Torvalds wrote:
> On Thu, Sep 26, 2013 at 9:24 AM, Frederic Weisbecker
> wrote:
> >
> > * Turn __ARCH_IRQ_EXIT_ON_IRQ_STACK old ad-hoc style symbol to proper
> > Kconfig
> > (CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK)
> >
> > * Activates it to powerpc as w
It turns out the kernel relies on barrier() to force a reload of the
percpu offset value. Since we can't easily modify the definition of
barrier() to include "tp" as an output register, we instead provide a
definition of __my_cpu_offset as extended assembly that includes a fake
stack read to hazar
When coming from a page fault (for example), interrupts might
be enabled as we enter the code to return from interrupt.
Cc: sta...@vger.kernel.org
Signed-off-by: Chris Metcalf
---
arch/tile/kernel/intvec_32.S | 3 +++
arch/tile/kernel/intvec_64.S | 3 +++
2 files changed, 6 insertions(+)
diff -
On 09/25/2013 08:49 AM, Henrique de Moraes Holschuh wrote:
On Tue, 24 Sep 2013, Sherry Hurwitz wrote:
You can direct AMD microcode issues to me now.
We are setting up some systems in the lab and trying to duplicate
the problem now.
Thank you!
If you're going to be taking care of AMD microcode
On 09/26/2013 11:04 AM, Greg KH wrote:
On Thu, Sep 26, 2013 at 07:31:47AM -0400, Peter Hurley wrote:
On 09/26/2013 03:33 AM, Andrew Morton wrote:
On Tue, 17 Sep 2013 20:22:42 -0400 Peter Hurley
wrote:
Looking over vmalloc.c, the critical section footprint of the vmap_area_lock
could definit
On Thu, Sep 26, 2013 at 6:34 AM, David Ahern wrote:
> On 9/25/13 11:20 PM, Sonny Rao wrote:
>>
>> We recently ran into a corrupt perf data file which mostly looked okay
>> but the section size for data was set to 0. This caused perf report to
>> get into an infinite loop in __perf_session_process
While handling punch-hole fallocate, it's useless to truncate page cache
before removing the range from extent tree (or block map in indirect case)
because page cache can be re-populated (by read-ahead or read(2) or mmap-ed
read) immediately after truncating page cache, but before updating extent
t
From: Masoud Sharbiani
Two entries for the same system type were added, with two different vendor
names: 'Dell' and 'Dell, Inc.'. Since a prefix match is being used, we can
eliminate the latter.
Signed-off-by: Masoud Sharbiani
---
arch/x86/kernel/reboot.c |8
1 file changed, 8 d
From: Meelis Roos
Date: Thu, 26 Sep 2013 16:12:55 +0300 (EEST)
> -rw-r--r-- 1 mroos mroos 97 Sep 20 21:56
> include/generated/uapi/linux/version.h
> -rw-r--r-- 1 mroos mroos 97 Aug 10 2012 ./include/linux/version.h
It's not the it doesn't get updated.
It's that the file in your GIT tree is un
Hi all,
I have a strange problem, which has been on going on for ages, and I finally
decided to look at it (as it is a pain in the arse).
Brief details:
Samsung N145 Plus running Slack 14 with handbuilt kernel
Kernel: Linux 3.11.1 #3 SMP Mon Sep 23 19:09:00 BST 2013 i686 Intel(R) Atom(TM)
CPU
Add support for the Z clock on r8a7790, driving the four SoC's CA15 cores,
and its parent - PLL0. This is required for CPUFreq support on this SoC.
Signed-off-by: Guennadi Liakhovetski
---
v2: changed clock alias to "cpu0" instead of deprecated "cpufreq-cpu0" to
comply with changes, introduced i
On 09/26/2013 11:32 AM, Andi Kleen wrote:
On Thu, Sep 26, 2013 at 07:52:23AM -0400, Peter Hurley wrote:
On 09/25/2013 11:20 PM, Andi Kleen wrote:
Lin Ming writes:
Would you like below patch?
The loop body keeps rather complex state. It could easily
get confused by parallel RCU changes.
So
Add DT nodes for the four I2C interfacces on r8a7790.
Signed-off-by: Guennadi Liakhovetski
---
v2: part two of former [PATCH 2/4], set i2c bus status to "disabled" by
default.
arch/arm/boot/dts/r8a7790.dtsi | 40
1 files changed, 40 insertions(+), 0 d
There are four I2C interfaces on r8a7790, each of them can be connected to
one of the two respective I2C controllers, e.g. interface #0 can be
configured to work with I2C0 or with IIC0. Additionally some of those
interfaces can also use one of several pin sets. Interface #3 is special,
because it c
On Lager a da9210 regulator is used to supply DVFS power to the SoC. This
patch series adds I2C and Z-clock support on r8a7790 and CPUFreq support
for the Lager board. Please note, that patch 4/4 is an RFC as explained
inline.
Developed on top of today's
git://git.kernel.org/pub/scm/linux/ker
This patch adds clock definitions for the 4 I2C interfaces on r8a7790 and
clock aliases, suitable for the DT mode.
Signed-off-by: Guennadi Liakhovetski
---
v2: part one of former [PATCH 2/4]
arch/arm/mach-shmobile/clock-r8a7790.c | 10 ++
1 files changed, 10 insertions(+), 0 deletion
The Lager board uses a DA9210 voltage regulator to supply DVFS power to the
CA15 cores on the r8a7790 SoC. This patch adds CPUFreq support for that
board using the cpufreq-cpu0 driver.
Signed-off-by: Guennadi Liakhovetski
---
v2: added 'status = "okay";' to the i2c bus
arch/arm/boot/dts/r8a779
From: Meelis Roos
Date: Thu, 26 Sep 2013 16:12:55 +0300 (EEST)
> As it happens, 198144 is the value from Aug 10 2012 and it happens to be
> 00030600 hex. Here is the culprit, we are not rebuilding
> include/linux/version.h.
That explains everything, thanks for tracking it down.
--
To unsubscri
> > *** BLURB HERE ***
>
> I think you need to read your emails a bit better :)
Oops.
> > Alexander Usyskin (1):
> > mei: cancel stall timers in mei_reset
> >
> > Tomas Winkler (2):
> > mei: make me client counters less error prone
> > mei: bus: stop wait for read during cl state transi
Am 26.09.2013 18:06, schrieb Ramkumar Ramachandra:
> Richard Weinberger wrote:
>> And, of course, this makes your patch valid.
>> Can you also please ensure that your new defconfigs are minimal?
>
> Yeah, it's close to a minimal configuration for the 3.10 kernel
> (latest at the time of patch subm
Em Sat, 17 Aug 2013 23:48:51 +0300
Alexey Khoroshilov escreveu:
> dmx_section_feed_release_filter() locks dvbdmx->mutex and
> if the feed is still filtering, it calls feed->stop_filtering(feed).
> stop_filtering() is implemented by dmx_section_feed_stop_filtering()
> that first of all try to lock
Madhavan, All,
On 2013-09-22 22:35 +0530, Madhavan Srinivasan spake thusly:
> In file included from scripts/kconfig/zconf.tab.c:2537:0:
> scripts/kconfig/menu.c: In function ‘get_symbol_str’:
> scripts/kconfig/menu.c:586:18: warning: ‘jump’ may be used uninitialized in
> this function [-Wmaybe-uni
Peter,
Sorry. Unlikely I will be able to read this patch today. So let me
ask another potentially wrong question without any thinking.
On 09/26, Peter Zijlstra wrote:
>
> +void __get_online_cpus(void)
> +{
> +again:
> + /* See __srcu_read_lock() */
> + __this_cpu_inc(__cpuhp_refcount);
>
On 09/26/2013 09:28 PM, Arjan van de Ven wrote:
> On 9/26/2013 6:42 AM, Srivatsa S. Bhat wrote:
>> On 09/26/2013 08:29 AM, Andrew Morton wrote:
>>> On Thu, 26 Sep 2013 03:50:16 +0200 Andi Kleen
>>> wrote:
>>>
On Wed, Sep 25, 2013 at 06:21:29PM -0700, Andrew Morton wrote:
> On Wed, 25 Sep
The tegra114 driver wasn't currently handling the cs_change
functionality. cs_change is meant to invert the decisions of whether
or not to deactivate CS after each transfer. Without cs_change, after
every transfer (other than the last in the message) the normal behavior
is to leave CS active. For t
On 09/26/2013 10:48 PM, Tejun Heo wrote:
> Hello,
>
> On Wed, Sep 25, 2013 at 02:30:51AM +0800, Zhang Yanfei wrote:
>> +/**
>> + * memory_map_bottom_up - Map [map_start, map_end) bottom up
>> + * @map_start: start address of the target memory range
>> + * @map_end: end address of the target memory
Add DTS for s5pc110 boards: goni, aquila, smdkc110
s5pv210: smdkv210, tiny210
Torbreck is replaced by FriendlyARM Tiny210 board.
Signed-off-by: Mateusz Krawczuk
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/Makefile | 6 +
arch/arm/boot/dts/s5pv210-aquila.dts | 407
Add generic device tree for s5pv210 and s5pv210-pinctrl
Signed-off-by: Mateusz Krawczuk
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/s5pv210-pinctrl.dtsi | 820 +
arch/arm/boot/dts/s5pv210.dtsi | 498
2 files changed, 1318 inser
This patch adds board file that will be used to boot S5PV210/S5PC110-based
boards using Device Tree.
Signed-off-by: Mateusz Krawczuk
Signed-off-by: Kyungmin Park
---
arch/arm/mach-s5pv210/Kconfig | 14 +
arch/arm/mach-s5pv210/Makefile | 2 +-
arch/arm/mach-s5pv210/mach-s
This patch series add initial device tree support for mach s5pv210.
It was tested on goni, aquila and tiny210.
Mateusz Krawczuk (3):
ARM: s5pv210: Add board file for boot using Device Tree
Samsung: DT: Add Device tree for s5pv210
Samsung: DT: Add Device tree for S5PC110/S5PV210 Boards
arch
On 25/09/13 18:56, Konrad Rzeszutek Wilk wrote:
On Wed, Sep 18, 2013 at 05:04:17PM +0100, Zoltan Kiss wrote:
Hi,
I haven't got a reply in the past 2 weeks, so I would like to bump
the patch, just to make sure it haven't fell off the radar.
Hey,
I have this in my queue to put on 3.13 as it is
Hello tejun,
On 09/26/2013 11:39 PM, Zhang Yanfei wrote:
> On 09/26/2013 10:46 PM, Tejun Heo wrote:
>> On Wed, Sep 25, 2013 at 02:29:06AM +0800, Zhang Yanfei wrote:
>>> +/**
>>> + * memory_map_top_down - Map [map_start, map_end) top down
>>> + * @map_start: start address of the target memory range
> CC: "Michal Hocko" , "Andrew Morton"
> , "David Rientjes" ,
> "KAMEZAWA Hiroyuki" , "KOSAKI Motohiro"
> , linux...@kvack.org,
> cgro...@vger.kernel.org, x...@kernel.org, linux-a...@vger.kernel.org,
> linux-kernel@vger.kernel.org
>On Wed, Sep 18, 2013 at 02:19:46PM -0400, Johannes Weiner wrot
Hi Christian,
Em Wed, 14 Aug 2013 22:58:47 +0200
Christian Volkmann escreveu:
> A split for ds3000/ts2020 code forgot to change the TEVII_S471 code.
> Change the TEVII_S471 according the changes to TEVII_S470.
>
> Signed-off-by: Christian Volkmann
> ---
> drivers/media/pci/cx23885/cx23885-dvb
On 09/26/2013 11:37 PM, Zhang Yanfei wrote:
> Hello tejun,
>
> Thanks for your quick comments first:)
>
> On 09/26/2013 10:45 PM, Tejun Heo wrote:
>> Hello,
>>
>> On Wed, Sep 25, 2013 at 02:27:48AM +0800, Zhang Yanfei wrote:
>>> +#ifdef CONFIG_MOVABLE_NODE
>>> +static inline void memblock_set_bot
On 09/26/2013 11:34 AM, J. Bruce Fields wrote:
On Thu, Sep 26, 2013 at 10:58:05AM +0200, Miklos Szeredi wrote:
On Wed, Sep 25, 2013 at 11:07 PM, Zach Brown wrote:
A client-side copy will be slower, but I guess it does have the
advantage that the application can track progress to some degree, a
On 25.09.13 09:49, Ville Syrjälä wrote:
On Wed, Sep 25, 2013 at 06:32:10AM +0200, Mario Kleiner wrote:
On 23.09.13 10:38, Ville Syrjälä wrote:
On Sat, Sep 21, 2013 at 12:07:36AM +0200, Mario Kleiner wrote:
On 09/17/2013 10:55 PM, Daniel Vetter wrote:
On Tue, Sep 17, 2013 at 9:50 PM, Peter Hur
Thanks Peter.
Well. I'am afraid my testing was wrong, because Karel reports
it fixes the problem...
But. I applied this patch to my 3.11 tree (last commit is bff157b3a)
which also has the additional patch (03e12617 "tty: disassociate_ctty()
sends the extra SIGCONT"), and
TET_CONFIG=CFG T
On 09/26/2013 10:53 PM, Tejun Heo wrote:
> On Wed, Sep 25, 2013 at 02:35:14AM +0800, Zhang Yanfei wrote:
>> From: Tang Chen
>>
>> The hot-Pluggable field in SRAT specifies which memory is hotpluggable.
>> As we mentioned before, if hotpluggable memory is used by the kernel,
>> it cannot be hot-rem
On Thu, Sep 26, 2013 at 9:24 AM, Frederic Weisbecker wrote:
>
> * Turn __ARCH_IRQ_EXIT_ON_IRQ_STACK old ad-hoc style symbol to proper Kconfig
> (CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK)
>
> * Activates it to powerpc as well.
>
> * Fix a bit the changelog of patch 6/8
Ack on the whole series.
I guess
On Thu, Sep 26, 2013 at 06:14:26PM +0200, Oleg Nesterov wrote:
> On 09/26, Peter Zijlstra wrote:
> >
> > On Thu, Sep 26, 2013 at 05:53:21PM +0200, Oleg Nesterov wrote:
> > > On 09/26, Peter Zijlstra wrote:
> > > > void cpu_hotplug_done(void)
> > > > {
> > > > - cpu_hotplug.active_writer = N
On Sep 25, 2013, at 5:35 PM, Rohit Vaswani wrote:
> On 9/25/2013 12:49 PM, Kumar Gala wrote:
>> On Sep 23, 2013, at 10:13 PM, Rohit Vaswani wrote:
>>
>>> This patch adds basic board support for APQ8074 Dragonboard
>>> which belongs to the Snapdragon 800 family.
>>> For now, just support a basic
On Fri, Sep 20, 2013 at 07:40:38AM -0700, Andi Kleen wrote:
> [This has kernel and user parts, so will need
> review/ack/merges from both perf kernel and user land maintainers]
> [v2: Address Peter's feedback for the kernel parts]
>
> This is currently the last part of the TSX PMU code,
> just add
All arch overriden implementations of do_softirq() share the following
common code: disable irqs (to avoid races with the pending check),
check if there are softirqs pending, then execute __do_softirq() on
a specific stack.
Consolidate the common parts such that archs only worry about the
stack sw
On Thu, Sep 26, 2013 at 10:12:23AM +0800, Fengguang Wu wrote:
> drivers/staging/dgnc/dgnc_driver.c:510:3-7: WARNING: casting value returned
> by k[cmz]alloc to (char *) is useless.
> drivers/staging/dgnc/dgnc_driver.c:502:2-19: WARNING: casting value returned
> by k[cmz]alloc to (struct dgnc_boar
x86-64 runs irq_exit() under the irq stack. So it can afford
to run softirqs in hardirq exit without the need to switch
the stacks. The hardirq stack is good enough for that.
Now x86-64 runs softirqs in the hardirq stack anyway, so what we
mostly skip is some needless per cpu refcounting updates t
The 64-bit cmpxchg operation on the lockref is ordered by virtue of
hazarding between the cmpxchg operation and the reference count
manipulation. On weakly ordered memory architectures (such as ARM), it
can be of great benefit to omit the barrier instructions where they are
not needed.
This patch
For clarity, comment the various stack choices for softirqs
processing, whether we execute them from ksoftirqd or
local_irq_enable() calls.
Their use on irq_exit() is already commented.
Signed-off-by: Frederic Weisbecker
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Ingo Molnar
Cc: Thomas
Before processing softirqs on hardirq exit, we already
do the check for pending softirqs while hardirqs are
guaranteed to be disabled.
So we can take a shortcut and safely jump to the arch
specific implementation directly.
Signed-off-by: Frederic Weisbecker
Cc: Benjamin Herrenschmidt
Cc: Paul M
Now that powerpc runs irq_exit() under the irq stack,
let the softirq core know about that so that we spare
the needless stack switch on irq exit's softirq processing.
Signed-off-by: Frederic Weisbecker
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Pete
Hi,
Series is fixed to address Linus and Ben comments:
* Turn __ARCH_IRQ_EXIT_ON_IRQ_STACK old ad-hoc style symbol to proper Kconfig
(CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK)
* Activates it to powerpc as well.
* Fix a bit the changelog of patch 6/8
This applies on top of 06367d58f487a592de50e6e23273
do_softirq() has a debug check that verifies that it is not nesting
on softirqs processing, nor miscounting the softirq part of the preempt
count.
But making sure that softirqs processing don't nest is actually a more
generic concern that applies to any caller of __do_softirq().
Do take it one st
The commit facd8b80c67a3cf64a467c4a2ac5fb31f2e6745b
("irq: Sanitize invoke_softirq") converted irq exit
calls of do_softirq() to __do_softirq() on all architectures,
assuming it was only used there for its irq disablement
properties.
But as a side effect, the softirqs processed in the end
of the h
If irq_exit() is called on the arch's specified irq stack,
it should be safe to run softirqs inline under that same
irq stack as it is near empty by the time we call irq_exit().
For example if we use the same stack for both hard and soft irqs here,
the worst case scenario is:
hardirq -> softirq ->
On 09/26, Peter Zijlstra wrote:
>
> On Thu, Sep 26, 2013 at 05:53:21PM +0200, Oleg Nesterov wrote:
> > On 09/26, Peter Zijlstra wrote:
> > > void cpu_hotplug_done(void)
> > > {
> > > - cpu_hotplug.active_writer = NULL;
> > > - mutex_unlock(&cpu_hotplug.lock);
> > > + /* Signal the writer is done,
On 25.09.13 16:13, Steven Rostedt wrote:
On Wed, 25 Sep 2013 06:32:10 +0200
Mario Kleiner wrote:
But given the new situation, your proposal is great! If we push the
clock readouts into the get_scanoutpos routine, we can make this robust
without causing grief for the rt people and without the
On Thu, Sep 26, 2013 at 05:53:21PM +0200, Oleg Nesterov wrote:
> On 09/26, Peter Zijlstra wrote:
> > void cpu_hotplug_done(void)
> > {
> > - cpu_hotplug.active_writer = NULL;
> > - mutex_unlock(&cpu_hotplug.lock);
> > + /* Signal the writer is done, no fast path yet. */
> > + __cpuhp_stat
Em Thu, Sep 26, 2013 at 09:18:48PM +0530, Ramkumar Ramachandra escreveu:
> David Ahern wrote:
> > Did you create a tarfile after this change, unpack it somewhere out of three
> > and then verify perf builds?
>
> Yeah, it builds fine. In fact, the archive generated from the current
> upstream is br
On Fri, Sep 27, 2013 at 12:03:01AM +0800, Zhang Yanfei wrote:
> Ah, I see. You are saying another issue. He is worrying that if we use
> kexec to load the kernel high, say we have 16GB, we put the kernel in
> 15.99GB (just an example), so we only have less than 100MB above the kernel.
>
> But as I
Richard Weinberger wrote:
> And, of course, this makes your patch valid.
> Can you also please ensure that your new defconfigs are minimal?
Yeah, it's close to a minimal configuration for the 3.10 kernel
(latest at the time of patch submission). I was aiming to minimize the
diff between the curren
On 09/26/2013 11:48 PM, Tejun Heo wrote:
> On Thu, Sep 26, 2013 at 11:43:02PM +0800, Zhang Yanfei wrote:
>>> As Yinghai pointed out in another thread, do we need to worry about
>>> falling back to top-down?
>>
>> I've explained to him. Nop, we don't need to worry about that. Because even
>> the min
On Mon, Sep 23, 2013 at 12:31:32PM +0200, Daniel Mack wrote:
> On 23.09.2013 12:19, Mark Brown wrote:
> > On Sun, Sep 22, 2013 at 09:51:45PM +0200, Daniel Mack wrote:
> >> Here are some trivial things for the ti_dac7512 driver.
> >>
> >> Mark, can you take them through your spi tree?
> >
> > I can
From: Darbha Sriharsha
Adds support for the bq24735 charger chipset. The bq24735 is a
high-efficiency, synchronous battery charger.
It allows control of the charging current, input current, and the charger
voltage DAC's through SMBus.
Signed-off-by: Darbha Sriharsha
Signed-off-by: Rhyland Klei
Hi!
I got this in dmesg and lost my X session :-(.
Pavel
shrink_slab: i915_gem_inactive_scan+0x0/0xc0 negative objects to
delete nr=-973650123
shrink_slab: i915_gem_inactive_scan+0x0/0xc0 negative objects to
delete nr=-10845
On Tue, Sep 17, 2013 at 06:42:30PM +, KY Srinivasan wrote:
>
>
> > -Original Message-
> > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> > Sent: Friday, September 13, 2013 11:33 AM
> > To: KY Srinivasan; Haiyang Zhang
> > Cc: de...@linuxdriverproject.org; linux-kernel@
On 9/26/2013 6:42 AM, Srivatsa S. Bhat wrote:
On 09/26/2013 08:29 AM, Andrew Morton wrote:
On Thu, 26 Sep 2013 03:50:16 +0200 Andi Kleen wrote:
On Wed, Sep 25, 2013 at 06:21:29PM -0700, Andrew Morton wrote:
On Wed, 25 Sep 2013 18:15:21 -0700 Arjan van de Ven
wrote:
On 9/25/2013 4:47 PM,
On 09/26/2013 11:50 PM, Tejun Heo wrote:
> On Thu, Sep 26, 2013 at 11:37:34PM +0800, Zhang Yanfei wrote:
+ WARN_ONCE(1, "memblock: Failed to allocate memory in bottom up "
+ "direction. Now try top down direction.\n");
+ }
>>>
>>> You and I would know what
On Thu, Sep 26, 2013 at 04:34:04PM +0100, Linus Torvalds wrote:
> On Thu, Sep 26, 2013 at 8:13 AM, Will Deacon wrote:
> >
> > This patch implements a dummy implementation for asm-generic, falling
> > back to the usual cmpxchg64 code.
>
> I don't like the "let's add dummy operations for everybody
On Thu, Sep 26, 2013 at 11:37:34PM +0800, Zhang Yanfei wrote:
> >> + WARN_ONCE(1, "memblock: Failed to allocate memory in bottom up "
> >> + "direction. Now try top down direction.\n");
> >> + }
> >
> > You and I would know what was going on and what the consequence of t
David Ahern wrote:
> Did you create a tarfile after this change, unpack it somewhere out of three
> and then verify perf builds?
Yeah, it builds fine. In fact, the archive generated from the current
upstream is broken.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
On Thu, Sep 26, 2013 at 11:43:02PM +0800, Zhang Yanfei wrote:
> > As Yinghai pointed out in another thread, do we need to worry about
> > falling back to top-down?
>
> I've explained to him. Nop, we don't need to worry about that. Because even
> the min_pfn_mapped becomes ISA_END_ADDRESS in the se
On 09/26/2013 10:49 PM, Tejun Heo wrote:
> On Wed, Sep 25, 2013 at 02:34:34AM +0800, Zhang Yanfei wrote:
>> From: Tang Chen
>>
>> Memory reserved for crashkernel could be large. So we should not allocate
>> this memory bottom up from the end of kernel image.
>>
>> When SRAT is parsed, we will be a
> > It would be better to keep counting and just do RDPMC on the switch
> > points, and then subtract for counting. For sampling could need a MSR
> > write to enable/disable. Still somewhat expensive, but nowhere near as
> > bad as a full switch.
>
> This is essentially an optimized event switc
On Thu, Sep 26, 2013 at 11:09:46PM +0800, Michael wang wrote:
> > + if (sync)
> > + p->se.last_sync_wakeup = sched_clock_cpu(cpu);
>
> Forgive me but I'm trying to understand it... why not 'current' but 'p'
> here? we want the get off speed of waker or the working time of wakee?
Becau
Hello tejun,
On 09/26/2013 10:48 PM, Tejun Heo wrote:
> Hello,
>
> On Wed, Sep 25, 2013 at 02:30:51AM +0800, Zhang Yanfei wrote:
>> +/**
>> + * memory_map_bottom_up - Map [map_start, map_end) bottom up
>> + * @map_start: start address of the target memory range
>> + * @map_end: end address of the
Joe Perches wrote:
> No code is eliminated by the preprocessor
> with the #define I suggest.
Sorry, I misunderstood. I assumed you meant comparing to:
#ifdef RPC_DEBUG
#define dfprintk(...) ...
#else
#define dfprintk(...) do {} while(0)
#endif
sort of t
On Thu, Sep 26, 2013 at 04:35:33PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 26, 2013 at 04:39:30AM -0700, Paul Turner wrote:
> > It is my intuition that there are a few common objects with fairly
> > polarized behavior: I.e. For condition variables and producer
> > consumer queues, a wakeup stro
301 - 400 of 779 matches
Mail list logo
