[PATCH 1/1] eventfd: fix incorrect filename is a comment
Comment in eventfd.h referred to 'include/asm-generic/fcntl.h' while the correct path is 'include/uapi/asm-generic/fcntl.h'. Signed-off-by: Martin Sustrik --- include/linux/eventfd.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/eventfd.h b/include/linux/eventfd.h index 3c3ef19..cf5d2af 100644 --- a/include/linux/eventfd.h +++ b/include/linux/eventfd.h @@ -13,7 +13,7 @@ #include /* - * CAREFUL: Check include/asm-generic/fcntl.h when defining + * CAREFUL: Check include/uapi/asm-generic/fcntl.h when defining * new flags, since they might collide with O_* ones. We want * to re-use O_* flags that couldn't possibly have a meaning * from eventfd, in order to leave a free define-space for -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] Add 4 tracepoint events for vfs
On Thu, Jan 31, 2013 at 03:40:38PM +0800, chenggang@gmail.com wrote: > @@ -1391,12 +1394,16 @@ generic_file_aio_read(struct kiocb *iocb, const > struct iovec *iov, > unsigned long seg = 0; > size_t count; > loff_t *ppos = &iocb->ki_pos; > + const unsigned char *f_name; > > count = 0; > retval = generic_segment_checks(iov, &nr_segs, &count, VERIFY_WRITE); > if (retval) > return retval; > > + f_name = filp->f_path.dentry->d_name.name; > + trace_generic_file_aio_read(pos, iov_length(iov, nr_segs), f_name); And just what is going to prevent that f_name of yours from being freed just as you are passing it to the function you are calling? IOW, NAK. BTW, I would like to point out that *ANY* hooks in VFS have all the stability granted to driver API - removal fodder whenever it becomes convenient. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] printk: Avoid softlockups in console_unlock()
On Fri, Jan 18, 2013 at 3:09 AM, Andrew Morton
wrote:
> On Thu, 17 Jan 2013 22:04:42 +0100
> Jan Kara wrote:
>
>> ...
>>
>> So I played a bit with this. To make things easier for me I added
>> artificial mdelay(len*10) (effectively simulating console able to print 100
>> characters per second) just after call_console_drivers() so that I can
>> trigger issues even on a machine easily available to me. Booting actually
>> doesn't trigger any problems because there aren't enough things happening
>> in parallel on common machine during boot but
>> echo t >/proc/sysrq-trigger &
>> for i in /lib/modules/3.8.0-rc3-0-default/kernel/fs/*/*.ko; do
>> name=`basename $i`; name=${name%.ko}; modprobe $name
>> done
>> easily triggers the problem (as modprobe uses both RCU & IPIs to signal all
>> CPUs).
>>
>> Adding
>> touch_nmi_watchdog();
>> touch_all_softlockup_watchdogs();
>> rcu_cpu_stall_reset();
>
> I'm not sure that touch_all_softlockup_watchdogs() is needed?
> touch_nmi_watchdog() itself calls touch_softlockup_watchdog().
>
> If the rcu_cpu_stall_reset() is needed here then presumably it is
> needed elsewhere and we should put a call to rcu_cpu_stall_reset() into
> (the increasingly misnamed) touch_nmi_watchdog().
>
>> into the printk loop did stop all the warnings and the machine eventually
>> came alive again after finishing printing sysrq-t output (while printing
>> the machine was responding to ping but ssh stopped working after a while -
>> not sure what was happening but apparently some IO requests weren't
>> completing and maybe networking started dropping packets because it
>> accumulated too much RCU work).
>>
>> So your suggestion seems certainly plausible. I was just wondering
>> a) Above three lines can be pretty expensive on big machines as they
>> iterate over all CPUs. So we should probably limit it to once per jiffy or
>> something like that?
>
> I guess so - is it hard to test the effects of such a change? Maybe do
> a few MB of printks with the output disabled with `dmesg -n' and see
> what effect such a patch has?
>
> If it does need ratelimiting, I'd worry about using jiffies for that.
> If the kernel is spending a long time with interrupts disabled, jiffies
> might not be incrementing. Using the CPU timestamp would be better
> (eg, sched_clock()).
http://lxr.free-electrons.com/source/kernel/sched/clock.c#L75
I am puzzled because of this definition(above link).Sched_clock is
dependent on jiffies and jiffies is blocked so how sched_clock would
be better(I am 100% missing something very obvious)?
Is it that sched_clock is not dependent on jiffies?
>
>> b) Above three lines can make softlockup detection pretty useless if
>> there's enough printk traffic (it would be enough to printk() something
>> every 10s or so which can happen with netfilter logging packets or so).
>
> Yes, that is a concern.
>
>> But if we touch the watchdogs only if we spend more than 1 jiffy in the
>> console_unlock() we should hopefully touch those watchdogs only in rare
>> cases of heavy printk traffic.
>
> yup. Another option might be to do the touch_nmi_watchdog() only if
> there is a "large" amount of data being emitted within
> console_unlock(). Like your 1000 character threshold.
>
>> PS: sysrq-t was ~200 KB on that freshly booted machine so on a busy machine
>> that would trigger softlockups with 115200 serial console as well (I
>> actually do remember seeing it in some customer's reports). So it's not
>> just boot.
>
> Yes, we have hit this before. Large printks over slow console devices.
> See the sad little touch_nmi_watchdog() in lib/show_mem.c, for
> example. I actually thought we'd fixed this in printk itself but it
> seems not - the two touch_nmi_watchdog()s in there are for special
> cases.
>
> Actually, a bit of grepping for touch_nmi_watchdog() is interesting. A
> number of serial drivers are doing it, which makes me wonder why your
> customers weren't saved by that - using the wrong driver, perhaps? If
> we can get this fixed centrally then a lot of those calls should be
> removeable.
>
> The presence of all those touch_nmi_watchdog() calls around the place
> has implications for the testing of your patch, btw ;)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] Add 4 tracepoint events for vfs
From: chenggang@gmail.com This version changed some type definition according to Steven's advise. Thanks for Steven. If the engineers want to analyze the file access behavior of some applications without source code, perf tools with some appropriate tracepoints events in the VFS subsystem are excellent choice. The system engineers or developers of server software require to know what files are accessed by the target processes with in a period of time. Then they can find the hot applications and the hot files. For this requirements, we added 2 tracepoint events at the begin of generic_file_aio_read() and generic_file_aio_write(). Many database systems use their own page cache subsystems and use the direct IO to access the disks. Sometimes, the system engineers want to know the misses rate of the database system's page cache. This requirements can be satisfied by recording the database's file access behavior through the way of direct IO. So, we added 2 tracepoint events at the direct IO branch in generic_file_aio_read() and generic_file_aio_write(). Then, we will extend the perf's function by python script to use these new tracepoint events. The 4 new tracepoint events are: 1) generic_file_aio_read Format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:int common_padding; offset:8; size:4; signed:1; field:long long pos;offset:16; size:8; signed:1; field:unsigned long bytes; offset:24; size:8; signed:0; field:__data_loc char[] fname; offset:32; size:4; signed:1; 2) generic_file_aio_write Format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:int common_padding; offset:8; size:4; signed:1; field:long long pos;offset:16; size:8; signed:1; field:unsigned long bytes; offset:24; size:8; signed:0; field:__data_loc char[] fname; offset:32; size:4; signed:1; 3) direct_io_read Format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:int common_padding; offset:8; size:4; signed:1; field:long long pos;offset:16; size:8; signed:1; field:unsigned long bytes; offset:24; size:8; signed:0; field:unsigned char fname[100]; offset:32; size:100; signed:0; 4) direct_io_write Format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:int common_padding; offset:8; size:4; signed:1; field:long long pos;offset:16; size:8; signed:1; field:unsigned long bytes; offset:24; size:8; signed:0; field:unsigned char fname[100]; offset:32; size:100; signed:0; Cc: Steven Rostedt Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: David Ahern Cc: Peter Zijlstra Cc: Paul Mackerras Cc: Arnaldo Carvalho de Melo Cc: Arjan van de Ven Cc: Namhyung Kim Cc: Yanmin Zhang Cc: Wu Fengguang Cc: Mike Galbraith Cc: Andrew Morton Signed-off-by: Chenggang Qin --- include/trace/events/vfs.h | 62 mm/filemap.c | 18 + 2 files changed, 80 insertions(+) create mode 100644 include/trace/events/vfs.h diff --git a/include/trace/events/vfs.h b/include/trace/events/vfs.h new file mode 100644 index 000..11c9acc --- /dev/null +++ b/include/trace/events/vfs.h @@ -0,0 +1,62 @@ +#undef TRACE_SYSTEM +#define TRACE_SYSTEM vfs +#define TRACE_INCLUDE_FILE vfs + +#if !defined(_TRACE_EVENTS_VFS_H) || defined(TRACE_HEADER_MULTI_READ) +#define _TRACE_EVENTS_VFS_H + +#include + +#include + +DECLARE_EVENT_CLASS(vfs_filerw_template, + + TP_PROTO(long long pos, unsigned long bytes, const unsigned char *fname), + + TP_ARGS(pos, bytes, fname), + +TP_STRUCT__entry( + __field(long long, pos ) + __field(
Re: [RFC 2/2] sched/fair: prefer a CPU in the "lowest" idle state
On Thu, 31 Jan 2013 15:30:02 +0800, Michael Wang wrote: > On 01/31/2013 02:58 PM, Namhyung Kim wrote: >> But AFAIK the number of states in cpuidle is usually less than 10 so maybe >> we can change the weight then, but there's no promise... > > And I just got another case we should take care: > > group 0 cpu 0 cpu 1 > power index 8 power index 8 > > > group 1 cpu 2 cpu 3 > power index 0 load 15 > > so load of group 0 is 16 and group 1 is 15, but group 0 is better... Maybe it's not. The cpus in group 0 are in a lower power state so that there will be a benefit to select cpu 2 from the power' PoV IMHO. Also such a low power state has a longer exit latency so that we should choose cpu2 to get a better performance and it's the basic idea of this patchset I believe. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V
>>> On 30.01.13 at 19:12, KY Srinivasan wrote: > Presumably, Hyper-V emulation is only to run enlightened Windows. The issue > with > Xen is not that it emulates Hyper-V, but this emulation is turned on while > running Linux. > That is the reason I chose to check for Xen. Would you prefer a DMI check > for the Hyper-V > platform. I consider DMI checks to be too fragile here - in particular with the eventual passing through of host DMI attributes to guests, this sets you up for mistakes. Instead, I would envision you scanning the whole CPUID range "reserved" for virtualization (starting at 0x4000) and see whether you get back anything other than the Hyper-V identification (much like the way xen_cpuid_base() scans for the Xen range). Of course that's under the premise that you're right in assuming Hyper-V would never emulate any other hypervisor's interface. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
On 01/31/2013 02:36 PM, Alexandre Courbot wrote: > On Thu, Jan 31, 2013 at 1:54 PM, Mark Zhang wrote: >> Display controller don't know whether the panel has EDID EEPROM but the >> panel driver knows. So why we need to make display controller queries >> EDID blindly? Since panel driver knows about all "video modes/panel >> size" stuffs, why not we let it handle all these things? > > The DC actually does know whether the connected panel supports EDID - > in this case, the output node will have a property for the DDC bus, > e.g. > > nvidia,ddc-i2c-bus = <&lcd_ddc>; > > If no DDC bus is specified or if transfer fails, the DC driver can > still query the panel driver for hardcoded modes. > Strictly speaking, according to my understanding, "nvidia,ddc-i2c-bus" means tegra has a hardware ddc channel, this doesn't mean we can get the EDID from this DDC surely. > Also passing a function pointer to get_modes() does not relief the DC > driver from probing for the DDC bus. You will still have to handle > both conditions (DDC bus present or not), the check will just be moved > into your callback function. > Yes. But panel driver decides whether the DDC probing is needed. If the panel has an EEPROM, it can call the function which display controller provides to do a DDC probing, it not, panel driver just ignores this function pointer and return the hardcoded modes directly. > Alex. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 2/2] sched/fair: prefer a CPU in the "lowest" idle state
On 01/31/2013 02:58 PM, Namhyung Kim wrote:
> On Thu, 31 Jan 2013 14:39:20 +0800, Michael Wang wrote:
>> On 01/31/2013 01:16 PM, Namhyung Kim wrote:
>>> Anyway, I have an idea with this in mind. It's like adding a new "idle
>>> load" to each idle cpu rather than special casing the idle cpus like
>>> above. IOW an idle cpu will get very small load weight depends on how
>>> deep it's slept so that it can be compared to other cpus in a same way
>>> but we can find prefered (lowest load) cpu among the idle cpus.
>>>
>>> The simple way I can think of is adding idle_level to a rq load in
>>> weighted_cpuload():
>>>
>>> static unsigned long weighted_cpuload(const int cpu)
>>> {
>>> return cpu_rq(cpu)->load.weight + cpuidle_get_state(cpu);
>>> }
>>
>> Hmm... then we don't need changes in find_idlest_cpu(), just compare the
>> load as before, but it works only when the appendix state value is
>> smaller than the lowest load of one task, which is 15 currently, I'm not
>> sure whether we have the promise...
>
> You said about a nice 19 process, right? But I found that SCHED_IDLE
> task will have weight of 3. :(
>
> #define WEIGHT_IDLEPRIO3
I missed that policy :)
>
>
> But AFAIK the number of states in cpuidle is usually less than 10 so maybe
> we can change the weight then, but there's no promise...
And I just got another case we should take care:
group 0 cpu 0 cpu 1
power index 8 power index 8
group 1 cpu 2 cpu 3
power index 0 load 15
so load of group 0 is 16 and group 1 is 15, but group 0 is better...
Regards,
Michael Wang
>
> Thanks,
> Namhyung
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] suspend: enable freeze timeout configuration through sys
2013/01/31 13:55, fli24 wrote:
At present, the value of timeout for freezing is 20s, which is
meaningless in case that one thread is frozen with mutex locked
and another thread is trying to lock the mutex, as this time of
freezing will fail unavoidably.
And if there is no new wakeup event registered, the system will
waste at most 20s for such meaningless trying of freezing.
With this patch, the value of timeout can be configured to smaller
value, so such meaningless trying of freezing will be aborted in
earlier time, and later freezing can be also triggered in earlier
time. And more power will be saved.
In normal case on mobile phone, it costs real little time to freeze
processes. On some platform, it only costs about 20ms to freeze
user space processes and 10ms to freeze kernel freezable threads.
Signed-off-by: Liu Chuansheng
Signed-off-by: Li Fei
---
Documentation/power/freezing-of-tasks.txt |5 +
include/linux/freezer.h |5 +
kernel/power/main.c | 27 +++
kernel/power/process.c|4 ++--
4 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/Documentation/power/freezing-of-tasks.txt
b/Documentation/power/freezing-of-tasks.txt
index 6ec291e..85894d8 100644
--- a/Documentation/power/freezing-of-tasks.txt
+++ b/Documentation/power/freezing-of-tasks.txt
@@ -223,3 +223,8 @@ since they ask the freezer to skip freezing this task,
since it is anyway
only after the entire suspend/hibernation sequence is complete.
So, to summarize, use [un]lock_system_sleep() instead of directly using
mutex_[un]lock(&pm_mutex). That would prevent freezing failures.
+
+V. Miscellaneous
+/sys/power/pm_freeze_timeout controls how long it will cost at most to freeze
+all user space processes or all freezable kernel threads, in unit of
millisecond.
+The default value is 2, with range of unsigned integer.
diff --git a/include/linux/freezer.h b/include/linux/freezer.h
index e4238ce..5a24a33 100644
--- a/include/linux/freezer.h
+++ b/include/linux/freezer.h
@@ -13,6 +13,11 @@ extern bool pm_freezing; /* PM freezing in
effect */
extern bool pm_nosig_freezing;/* PM nosig freezing in effect
*/
/*
+ * Timeout for stopping processes
+ */
+extern unsigned int sys_freeze_process_timeout_msecs;
+
+/*
* Check if a process has been frozen
*/
static inline bool frozen(struct task_struct *p)
diff --git a/kernel/power/main.c b/kernel/power/main.c
index 1c16f91..453ead1 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -553,6 +553,30 @@ power_attr(pm_trace_dev_match);
#endif /* CONFIG_PM_TRACE */
+#ifdef CONFIG_FREEZER
+static ssize_t pm_freeze_timeout_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%u\n", sys_freeze_process_timeout_msecs);
+}
+
+static ssize_t pm_freeze_timeout_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buf, size_t n)
+{
+ unsigned long val;
+
+ if (kstrtoul(buf, 10, &val))
+ return -EINVAL;
+
+ sys_freeze_process_timeout_msecs = val;
+ return n;
+}
+
+power_attr(pm_freeze_timeout);
+
+#endif /* CONFIG_FREEZER*/
+
static struct attribute * g[] = {
&state_attr.attr,
#ifdef CONFIG_PM_TRACE
@@ -576,6 +600,9 @@ static struct attribute * g[] = {
&pm_print_times_attr.attr,
#endif
#endif
+#ifdef CONFIG_FREEZER
+ &pm_freeze_timeout_attr.attr,
+#endif
NULL,
};
diff --git a/kernel/power/process.c b/kernel/power/process.c
index d5a258b..ba45a26 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -21,7 +21,7 @@
/*
* Timeout for stopping processes
*/
-#define TIMEOUT(20 * HZ)
+unsigned int __read_mostly sys_freeze_process_timeout_msecs = 2;
2 does not mean 20 seconds since we can select HZ other than 1000.
So (20 * HZ) is better than 2.
Thanks,
Yasuaki Ishimatsu
static int try_to_freeze_tasks(bool user_only)
{
@@ -36,7 +36,7 @@ static int try_to_freeze_tasks(bool user_only)
do_gettimeofday(&start);
- end_time = jiffies + TIMEOUT;
+ end_time = jiffies + msecs_to_jiffies(sys_freeze_process_timeout_msecs);
if (!user_only)
freeze_workqueues_begin();
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] dma: pl330: Convert to devm_ioremap_resource()
On Thu, Jan 31, 2013 at 12:37:04PM +0530, Sachin Kamat wrote: > Use the newly introduced devm_ioremap_resource() instead of > devm_request_and_ioremap() which provides more consistent error handling. > > Signed-off-by: Sachin Kamat > Cc: Vinod Koul > Cc: Thierry Reding > Cc: Greg Kroah-Hartman > --- > This change is based against linux-next tree (20130128). > This change however introduces the followign sparse warning: > drivers/dma/pl330.c:2883:22: warning: incorrect type in argument 1 (different > address spaces) > drivers/dma/pl330.c:2883:22:expected void const *ptr > drivers/dma/pl330.c:2883:22:got void [noderef] *base > drivers/dma/pl330.c:2884:34: warning: incorrect type in argument 1 (different > address spaces) > drivers/dma/pl330.c:2884:34:expected void const *ptr > drivers/dma/pl330.c:2884:34:got void [noderef] *base Yes, those are false positives. They can be fixed with the two patches I posted a few hours ago, starting here: https://lkml.org/lkml/2013/1/30/455 Note that the first patch is against sparse. The problem, in a nutshell, is that sparse complains that the pointer address spaces and noderef attributes differ. In the case of the IS_ERR() function and friends the attributes aren't relevant because only the pointer value is only used arithmetically. Unfortunately there is no way you can cast away these attributes without causing other warnings, so the solution is somewhat more complex. Thierry pgpCPRP8EcLU6.pgp Description: PGP signature
Re: [PATCH 1/1] dma: pl330: Convert to devm_ioremap_resource()
On Thu, Jan 31, 2013 at 12:37:04PM +0530, Sachin Kamat wrote: > Use the newly introduced devm_ioremap_resource() instead of > devm_request_and_ioremap() which provides more consistent error handling. > > Signed-off-by: Sachin Kamat > Cc: Vinod Koul > Cc: Thierry Reding > Cc: Greg Kroah-Hartman > --- > This change is based against linux-next tree (20130128). > This change however introduces the followign sparse warning: > drivers/dma/pl330.c:2883:22: warning: incorrect type in argument 1 (different > address spaces) > drivers/dma/pl330.c:2883:22:expected void const *ptr > drivers/dma/pl330.c:2883:22:got void [noderef] *base > drivers/dma/pl330.c:2884:34: warning: incorrect type in argument 1 (different > address spaces) > drivers/dma/pl330.c:2884:34:expected void const *ptr > drivers/dma/pl330.c:2884:34:got void [noderef] *base These are known, a patch has been posted for both the kernel and sparse to fix this up. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/8] cputime: Safely read cputime of full dynticks CPUs
On Thu, Jan 31, 2013 at 1:38 AM, Frederic Weisbecker wrote: > 2013/1/28 Sedat Dilek : >> On Mon, Jan 28, 2013 at 8:04 PM, Frederic Weisbecker >> wrote: >>> While remotely reading the cputime of a task running in a >>> full dynticks CPU, the values stored in utime/stime fields >>> of struct task_struct may be stale. Its values may be those >>> of the last kernel <-> user transition time snapshot and >>> we need to add the tickless time spent since this snapshot. >>> >>> To fix this, flush the cputime of the dynticks CPUs on >>> kernel <-> user transition and record the time / context >>> where we did this. Then on top of this snapshot and the current >>> time, perform the fixup on the reader side from task_times() >>> accessors. >>> >>> Signed-off-by: Frederic Weisbecker >>> Cc: Andrew Morton >>> Cc: Ingo Molnar >>> Cc: Li Zhong >>> Cc: Namhyung Kim >>> Cc: Paul E. McKenney >>> Cc: Paul Gortmaker >>> Cc: Peter Zijlstra >>> Cc: Steven Rostedt >>> Cc: Thomas Gleixner >>> [fixed kvm module related build errors] >>> Signed-off-by: Sedat Dilek >>> >> >> Can you explain a bit what is the difference between "3.8-rc4-nohz3" >> and "full-dynticks-cputime-for-mingo" patchsets? > > 3.8-rc4-nohz3 is the latest experimental tree that implements full > dynticks. It includes an earlier version of full dynticks cputime and > many other things to make the full dynticks possible: nohz printk, > many tweaks on the scheduler and timers...etc > So, dynticks-cputime will go into 3.9? What about the other parts? Coming later? >> >> Does the latter need no more EXPORT_SYMBOL_GPL for vtime_guest_enter() >> and vtime_guest_exit() when CONFIG_KVM=m (see [1])? > > It doesn't need export symbol on vtime_guest_() APIs, only on > guest_enter and guest_exit. > I verified this by building by myself. - Sedat - > Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] i2c-i801: SMBus patch for Intel Avoton DeviceIDs
On Wed, 30 Jan 2013 17:25:32 -0800, Seth Heasley wrote:
> This patch adds the PCU SMBus DeviceID for the Intel Avoton SOC.
>
> Signed-off-by: Seth Heasley
> ---
> Change notes for v2:
> * corrected order of DeviceID defines
>
> Documentation/i2c/busses/i2c-i801 |1 +
> drivers/i2c/busses/Kconfig|1 +
> drivers/i2c/busses/i2c-i801.c |3 +++
> 3 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/i2c/busses/i2c-i801
> b/Documentation/i2c/busses/i2c-i801
> index 157416e..8d71d57 100644
> --- a/Documentation/i2c/busses/i2c-i801
> +++ b/Documentation/i2c/busses/i2c-i801
> @@ -22,6 +22,7 @@ Supported adapters:
>* Intel Panther Point (PCH)
>* Intel Lynx Point (PCH)
>* Intel Lynx Point-LP (PCH)
> + * Intel Avoton (SOC)
> Datasheets: Publicly available at the Intel website
>
> On Intel Patsburg and later chipsets, both the normal host SMBus controller
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index bdca511..77d2887 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -106,6 +106,7 @@ config I2C_I801
> Panther Point (PCH)
> Lynx Point (PCH)
> Lynx Point-LP (PCH)
> + Avoton (SOC)
>
> This driver can also be built as a module. If so, the module
> will be called i2c-i801.
> diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
> index 3092387..b00c29d 100644
> --- a/drivers/i2c/busses/i2c-i801.c
> +++ b/drivers/i2c/busses/i2c-i801.c
> @@ -53,6 +53,7 @@
>Panther Point (PCH) 0x1e22 32 hard yes yes yes
>Lynx Point (PCH) 0x8c22 32 hard yes yes yes
>Lynx Point-LP (PCH) 0x9c22 32 hard yes yes yes
> + Avoton (SOC) 0x1f3c 32 hard yes yes yes
>
>Features supported by this driver:
>Software PEC no
> @@ -162,6 +163,7 @@
> #define PCI_DEVICE_ID_INTEL_PATSBURG_SMBUS_IDF1 0x1d71
> #define PCI_DEVICE_ID_INTEL_PATSBURG_SMBUS_IDF2 0x1d72
> #define PCI_DEVICE_ID_INTEL_PANTHERPOINT_SMBUS 0x1e22
> +#define PCI_DEVICE_ID_INTEL_AVOTON_SMBUS 0x1f3c
> #define PCI_DEVICE_ID_INTEL_DH89XXCC_SMBUS 0x2330
> #define PCI_DEVICE_ID_INTEL_5_3400_SERIES_SMBUS 0x3b30
> #define PCI_DEVICE_ID_INTEL_LYNXPOINT_SMBUS 0x8c22
> @@ -798,6 +800,7 @@ static DEFINE_PCI_DEVICE_TABLE(i801_ids) = {
> { PCI_DEVICE(PCI_VENDOR_ID_INTEL,
> PCI_DEVICE_ID_INTEL_PANTHERPOINT_SMBUS) },
> { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_LYNXPOINT_SMBUS)
> },
> { PCI_DEVICE(PCI_VENDOR_ID_INTEL,
> PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_SMBUS) },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_AVOTON_SMBUS) },
> { 0, }
> };
>
Reviewed-by: Jean Delvare
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] digsig: Fix memory leakage in digsig_verify_rsa()
On Thu, Jan 31, 2013 at 3:02 AM, James Morris wrote: > What's the practical impact of this? Could an attacker kill the machine? > > It might be possible slowly to eat the whole memory if there were too many memory verifications. This is a bug and the patch will be applied to stable. Should go to mainline as well. I suggest to apply it and also couple of other patches I sent yesterday. thanks. - Dmitry > On Wed, 30 Jan 2013, Kasatkin, Dmitry wrote: > >> On Fri, Jan 25, 2013 at 4:54 PM, Dmitry Kasatkin >> wrote: >> > From: YOSHIFUJI Hideaki >> > >> > digsig_verify_rsa() does not free kmalloc'ed buffer returned by >> > mpi_get_buffer(). >> > >> > Signed-off-by: YOSHIFUJI Hideaki >> > Signed-off-by: Dmitry Kasatkin >> > Cc: sta...@vger.kernel.org >> > --- >> > lib/digsig.c |2 ++ >> > 1 file changed, 2 insertions(+) >> > >> > diff --git a/lib/digsig.c b/lib/digsig.c >> > index 8c0e629..dc2be7e 100644 >> > --- a/lib/digsig.c >> > +++ b/lib/digsig.c >> > @@ -162,6 +162,8 @@ static int digsig_verify_rsa(struct key *key, >> > memset(out1, 0, head); >> > memcpy(out1 + head, p, l); >> > >> > + kfree(p); >> > + >> > err = pkcs_1_v1_5_decode_emsa(out1, len, mblen, out2, &len); >> > if (err) >> > goto err; >> > -- >> > 1.7.10.4 >> > >> >> James, can you please apply this patch. >> >> - Dmitry >> > > -- > James Morris > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] dma: pl330: Convert to devm_ioremap_resource()
Use the newly introduced devm_ioremap_resource() instead of devm_request_and_ioremap() which provides more consistent error handling. Signed-off-by: Sachin Kamat Cc: Vinod Koul Cc: Thierry Reding Cc: Greg Kroah-Hartman --- This change is based against linux-next tree (20130128). This change however introduces the followign sparse warning: drivers/dma/pl330.c:2883:22: warning: incorrect type in argument 1 (different address spaces) drivers/dma/pl330.c:2883:22:expected void const *ptr drivers/dma/pl330.c:2883:22:got void [noderef] *base drivers/dma/pl330.c:2884:34: warning: incorrect type in argument 1 (different address spaces) drivers/dma/pl330.c:2884:34:expected void const *ptr drivers/dma/pl330.c:2884:34:got void [noderef] *base --- drivers/dma/pl330.c |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c index 316a43e..142fe4d 100644 --- a/drivers/dma/pl330.c +++ b/drivers/dma/pl330.c @@ -25,6 +25,7 @@ #include #include #include +#include #include "dmaengine.h" #define PL330_MAX_CHAN 8 @@ -2878,9 +2879,9 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id) pi->mcbufsz = pdat ? pdat->mcbuf_sz : 0; res = &adev->res; - pi->base = devm_request_and_ioremap(&adev->dev, res); - if (!pi->base) - return -ENXIO; + pi->base = devm_ioremap_resource(&adev->dev, res); + if (IS_ERR(pi->base)) + return PTR_ERR(pi->base); amba_set_drvdata(adev, pdmac); -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 00/15] memory-hotplug: hot-remove physical memory
On 01/31/2013 02:19 PM, Simon Jeons wrote: Hi Tang, On Thu, 2013-01-31 at 11:31 +0800, Tang Chen wrote: Hi Simon, Please see below. :) On 01/31/2013 09:22 AM, Simon Jeons wrote: Sorry, I still confuse. :( update node_states[N_NORMAL_MEMORY] to node_states[N_MEMORY] or node_states[N_NORMAL_MEMOR] present 0...ZONE_MOVABLE? node_states is what? node_states[N_NORMAL_MEMOR] or node_states[N_MEMORY]? Are you asking what node_states[] is ? node_states[] is an array of nodemask, extern nodemask_t node_states[NR_NODE_STATES]; For example, node_states[N_NORMAL_MEMOR] represents which nodes have normal memory. If N_MEMORY == N_HIGH_MEMORY == N_NORMAL_MEMORY, node_states[N_MEMORY] is node_states[N_NORMAL_MEMOR]. So it represents which nodes have 0 ... ZONE_MOVABLE. Sorry, how can nodes_state[N_NORMAL_MEMORY] represents a node have 0 ... *ZONE_MOVABLE*, the comment of enum nodes_states said that N_NORMAL_MEMORY just means the node has regular memory. Hi Simon, Let's say it in this way. If we don't have CONFIG_HIGHMEM, N_HIGH_MEMORY == N_NORMAL_MEMORY. We don't have a separate macro to represent highmem because we don't have highmem. This is easy to understand, right ? Now, think it just like above: If we don't have CONFIG_MOVABLE_NODE, N_MEMORY == N_HIGH_MEMORY == N_NORMAL_MEMORY. This means we don't allow a node to have only movable memory, not we don't have movable memory. A node could have normal memory and movable memory. So nodes_state[N_NORMAL_MEMORY] represents a node have 0 ... *ZONE_MOVABLE*. I think the point is: CONFIG_MOVABLE_NODE means we allow a node to have only movable memory. So without CONFIG_MOVABLE_NODE, it doesn't mean a node cannot have movable memory. It means the node cannot have only movable memory. It can have normal memory and movable memory. 1) With CONFIG_MOVABLE_NODE: N_NORMAL_MEMORY: nodes who have normal memory. normal memory only normal and highmem normal and highmem and movablemem normal and movablemem N_MEMORY: nodes who has memory (any memory) normal memory only normal and highmem normal and highmem and movablemem normal and movablemem We can have movablemem. highmem only - highmem and movablemem --- movablemem only -- We can have movablemem only.*** 2) With out CONFIG_MOVABLE_NODE: N_MEMORY == N_NORMAL_MEMORY: (Here, I omit N_HIGH_MEMORY) normal memory only normal and highmem normal and highmem and movablemem normal and movablemem We can have movablemem. No movablemem only --- We cannot have movablemem only. *** The semantics is not that clear here. So we can only try to understand it from the code where we use N_MEMORY. :) That is my understanding of this. Thanks. :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASoC: fsl: Fix multiple symbol definitions
On Thu, Jan 31, 2013 at 08:06:58AM +0100, Thierry Reding wrote: > That does indeed look much better than fiddling with the Makefile. My > automated ARM builds of linux-next were failing for a few days because > of this, so I guess the fix (as well as the MMC one) just hadn't made it > into linux-next yet. The last -next was on the 29th, once it's rebuilt the fix should be there. signature.asc Description: Digital signature
Re: Uhhuh. NMI received for unknown reason 2c on CPU 0.
On Thu, Jan 31, 2013 at 01:54:56AM +0100, Rafael J. Wysocki wrote: > On Thursday, January 31, 2013 12:47:40 AM Jiri Slaby wrote: > > On 01/31/2013 12:12 AM, Jiri Slaby wrote: > > > I think I will start with commenting parts of `power' script to see > > > exactly which of the power savings cause this. > > > > ... NMI watchdog. If I remove it from the script, the problem > > disappears. If I try it alone, I have those NMIs. > > Well, beats me. :-( > > I suspect that it doesn't quiesce itself sufficiently before image restoration > and we get some crosstalk between the boot kernel and the image kernel. Well, I did what Jiri said causes it: echo 0 > /proc/sys/kernel/nmi_watchdog No NMI. BUT(!), if I start powertop and set all tunables in the "Tunables" tab to "Good", then suspend to disk, when I resume I get the NMI and this time the unknown reason is 0x3c. Sounds like this needs bisection... Btw, this is latest -rc5 + tip/master and Jiri triggers it on 3.7-stable ... Btw, this e1000e thing has another problem: when I unplug the network cable and replug it again, it cannot ping local network anymore. Normally, when you plug the network cable back in, it does some sort if link detection saying eth link is back up but it doesn't say it on that box - only a reboot fixes it. Hmm. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 3/7] zswap: add to mm/
On Tue, Jan 29, 2013 at 03:40:23PM -0600, Seth Jennings wrote: > zswap is a thin compression backend for frontswap. It receives > pages from frontswap and attempts to store them in a compressed > memory pool, resulting in an effective partial memory reclaim and > dramatically reduced swap device I/O. > > Additionally, in most cases, pages can be retrieved from this > compressed store much more quickly than reading from tradition > swap devices resulting in faster performance for many workloads. > > This patch adds the zswap driver to mm/ > > Signed-off-by: Seth Jennings > --- > mm/Kconfig | 15 ++ > mm/Makefile | 1 + > mm/zswap.c | 656 > > 3 files changed, 672 insertions(+) > create mode 100644 mm/zswap.c > > diff --git a/mm/Kconfig b/mm/Kconfig > index 278e3ab..14b9acb 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -446,3 +446,18 @@ config FRONTSWAP > and swap data is stored as normal on the matching swap device. > > If unsure, say Y to enable frontswap. > + > +config ZSWAP > + bool "In-kernel swap page compression" > + depends on FRONTSWAP && CRYPTO > + select CRYPTO_LZO > + select ZSMALLOC Again, I'm asking why zswap should have a dependent on CRPYTO? Couldn't we support it as a option? I'd like to use zswap without CRYPTO like zram. > + default n > + help > + Zswap is a backend for the frontswap mechanism in the VMM. > + It receives pages from frontswap and attempts to store them > + in a compressed memory pool, resulting in an effective > + partial memory reclaim. In addition, pages and be retrieved > + from this compressed store much faster than most tradition > + swap devices resulting in reduced I/O and faster performance > + for many workloads. > diff --git a/mm/Makefile b/mm/Makefile > index 3a46287..1b1ed5c 100644 > --- a/mm/Makefile > +++ b/mm/Makefile > @@ -32,6 +32,7 @@ obj-$(CONFIG_HAVE_MEMBLOCK) += memblock.o > obj-$(CONFIG_BOUNCE) += bounce.o > obj-$(CONFIG_SWAP) += page_io.o swap_state.o swapfile.o > obj-$(CONFIG_FRONTSWAP) += frontswap.o > +obj-$(CONFIG_ZSWAP) += zswap.o > obj-$(CONFIG_HAS_DMA)+= dmapool.o > obj-$(CONFIG_HUGETLBFS) += hugetlb.o > obj-$(CONFIG_NUMA) += mempolicy.o > diff --git a/mm/zswap.c b/mm/zswap.c > new file mode 100644 > index 000..a6c2928 > --- /dev/null > +++ b/mm/zswap.c > @@ -0,0 +1,656 @@ > +/* > + * zswap-drv.c - zswap driver file > + * > + * zswap is a backend for frontswap that takes pages that are in the > + * process of being swapped out and attempts to compress them and store > + * them in a RAM-based memory pool. This results in a significant I/O > + * reduction on the real swap device and, in the case of a slow swap > + * device, can also improve workload performance. > + * > + * Copyright (C) 2012 Seth Jennings > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version 2 > + * of the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > +*/ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* > +* statistics > +**/ > +/* Number of memory pages used by the compressed pool */ > +static atomic_t zswap_pool_pages = ATOMIC_INIT(0); > +/* The number of compressed pages currently stored in zswap */ > +static atomic_t zswap_stored_pages = ATOMIC_INIT(0); Just nitpicking. It seems future zsmalloc users want to gather information like this so it might be nice to add them into zsmalloc's internal like malloc_stats(2) > + > +/* > + * The statistics below are not protected from concurrent access for > + * performance reasons so they may not be a 100% accurate. However, > + * the do provide useful information on roughly how many times a > + * certain event is occurring. > +*/ > +static u64 zswap_pool_limit_hit; > +static u64 zswap_reject_compress_poor; > +static u64 zswap_reject_zsmalloc_fail; > +static u64 zswap_reject_kmemcache_fail; > +static u64 zswap_duplicate_entry; > + > +/* > +* tunables > +**/ > +/* Enable/disable zswap (disabled by default, fixed at boot for now) */ > +static bool zswap_enabled; > +module_param_named(enabled, zswap_enabled, bool, 0); > + > +/* Compressor to be used by zswap (fixed at boot for now) */ > +#define ZSWAP_COMPRESSOR_DEFAULT "lzo" > +static char *zswap_compressor = ZSWAP_CO
Re: [PATCH] ASoC: fsl: Fix multiple symbol definitions
On Thu, Jan 31, 2013 at 09:42:17AM +0800, Shawn Guo wrote: > On Wed, Jan 30, 2013 at 09:24:31PM +0100, Thierry Reding wrote: > > Commit 25b8d31 (ASoC: fsl: fix multiple definition of init_module) fixed > > a build error due to multiple symbol definitions when building as a > > module. However, it causes the build to break when the driver is builtin > > because the imx-pcm.o object is included multiple times. Solve the issue > > by adding imx-pcm.o to each of the modules that require it, but only add > > it to the kernel once when one or both drivers are builtin. > > > > Signed-off-by: Thierry Reding > > Thanks, Thierry. The Kconfig is already complex. To avoid having them > even more complex, I have chosen to revert my patch and have a little > surgery on the code [1] to make it match the Kconfig rational. > > Shawn > > [1] http://thread.gmane.org/gmane.linux.alsa.devel/105018 That does indeed look much better than fiddling with the Makefile. My automated ARM builds of linux-next were failing for a few days because of this, so I guess the fix (as well as the MMC one) just hadn't made it into linux-next yet. Thierry pgpjjn_2WZVU1.pgp Description: PGP signature
Re: [PATCH 1/5] e1000e: fix resuming from runtime-suspend
Rafael J. Wysocki wrote:
On Tuesday, January 29, 2013 10:32:14 AM Konstantin Khlebnikov wrote:
Rafael J. Wysocki wrote:
On Monday, January 28, 2013 04:05:33 PM Bjorn Helgaas wrote:
[+cc Rafael, author of patch you cited]
On Fri, Jan 18, 2013 at 4:42 AM, Konstantin Khlebnikov
wrote:
Bug was introduced in commit 23606cf5d1192c2b17912cb2ef6e62f9b11de133
("e1000e / PCI / PM: Add basic runtime PM support (rev. 4)") in v2.6.35
Signed-off-by: Konstantin Khlebnikov
Cc: e1000-de...@lists.sourceforge.net
Cc: Jeff Kirsher
Cc: Bruce Allan
---
drivers/net/ethernet/intel/e1000e/netdev.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index fbf75fd..2853c11 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5691,14 +5691,17 @@ static int e1000_runtime_suspend(struct device *dev)
struct pci_dev *pdev = to_pci_dev(dev);
struct net_device *netdev = pci_get_drvdata(pdev);
struct e1000_adapter *adapter = netdev_priv(netdev);
+ int retval;
+ bool wake;
- if (e1000e_pm_ready(adapter)) {
- bool wake;
+ if (!e1000e_pm_ready(adapter))
+ return 0;
- __e1000_shutdown(pdev,&wake, true);
- }
+ retval = __e1000_shutdown(pdev,&wake, true);
+ if (!retval)
+ e1000_power_off(pdev, true, wake);
- return 0;
+ return retval;
}
static int e1000_idle(struct device *dev)
I'd like the changelog to say what the bug is and how it is being fixed in
general terms.
Ok, my bad.
Problem: ethernet device does not work (no carrier signal).
Right after boot it goes to runtime-suspend and never wake up.
Original code (before your commit) calls pci_prepare_to_sleep() and it
calls pci_enable_wake() and switches device to one of D3 state.
The original code in what function?
Oh, I screwed up again. That commit adds support of runtime-pm,
so there is no original code. But runtime-pm in 'igb' works in this way:
igb_runtime_suspend() -> pci_prepare_to_sleep() -> pci_enable_wake()
It seems redundant, because pci_pm_runtime_suspend() do the same thing
after calling ->runtime_suspend callback. Or rather it did it before commit
42eca2302146fed51335b95128e949ee6f54478f ("PCI: Don't touch card regs after
runtime suspend D3") and third patch aimed fix this damage.
More over seems like calling pci_enable_wake() from e1000e isn't enough for my
case,
because my enthernet cannot wakeup from runtime-suspend without third patch.
Which third patch?
third patch in this patchset:
"[PATCH 3/5] PCI: revert preparing for wakeup in runtime-suspend finalization"
Seems like it's because pci_enable_wake() and pci_finish_runtime_suspend()
calls different pratform-pm callbacks -- platform_pci_run_wake() /
platform_pci_sleep_wake().
That's correct, for historical reasons. We'll need to merge these things, but
for now the are separate (because of the way ACPI handles system suspend and
runtime PM).
Ok, I have not read yet all code and documentation. But it seems runtime-pm
engine needs some sort of runtime debug-mode which would warn about strange or
ineffective actions in drivers, probably just script for parsing kernel-log
and tracking states for all devices and buses.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: sdhci-esdhc-imx: Remove unused variables
On Thu, Jan 31, 2013 at 08:31:20AM +0800, Shawn Guo wrote: > On Wed, Jan 30, 2013 at 09:11:21PM +0100, Thierry Reding wrote: > > Commit 3f175a6 (mmc: sdhci-esdhc-imx: remove ESDHC_CD_GPIO handling from > > IO accessory) removed all the code that was using these variables, so it > > is safe to drop them. > > > > Signed-off-by: Thierry Reding > > Thanks for the fixing, Thierry. But Chris has already queued a fix [1] > from Fabio. Okay, great! Thierry pgpbBrcItnAt0.pgp Description: PGP signature
Re: [RFC 2/2] sched/fair: prefer a CPU in the "lowest" idle state
On Thu, 31 Jan 2013 14:39:20 +0800, Michael Wang wrote:
> On 01/31/2013 01:16 PM, Namhyung Kim wrote:
>> Anyway, I have an idea with this in mind. It's like adding a new "idle
>> load" to each idle cpu rather than special casing the idle cpus like
>> above. IOW an idle cpu will get very small load weight depends on how
>> deep it's slept so that it can be compared to other cpus in a same way
>> but we can find prefered (lowest load) cpu among the idle cpus.
>>
>> The simple way I can think of is adding idle_level to a rq load in
>> weighted_cpuload():
>>
>> static unsigned long weighted_cpuload(const int cpu)
>> {
>> return cpu_rq(cpu)->load.weight + cpuidle_get_state(cpu);
>> }
>
> Hmm... then we don't need changes in find_idlest_cpu(), just compare the
> load as before, but it works only when the appendix state value is
> smaller than the lowest load of one task, which is 15 currently, I'm not
> sure whether we have the promise...
You said about a nice 19 process, right? But I found that SCHED_IDLE
task will have weight of 3. :(
#define WEIGHT_IDLEPRIO3
But AFAIK the number of states in cpuidle is usually less than 10 so maybe
we can change the weight then, but there's no promise...
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Add a python script to statistic direct io behavior
From: chenggang@gmail.com This patch depends on a prev patch: https://lkml.org/lkml/2013/1/29/47 If the engineers want to analyze the direct io behavior of some applications without source code, perf tools with some appropriate tracepoints events in the VFS subsystem are excellent choice. Many database systems use their own page cache subsystems and use the direct IO to access the disks. Sometimes, the system engineers need to know the misses rate of the database system's page cache. This requirements can be satisfied by recording the database's file access behavior through the way of direct IO. So, we use 2 tracepoint events to record the system wide's direct IO behavior. The 2 tracepoint events are: 1) vfs:direct_io_read 2) vfs:direct_io_write they were introduced by the patch: https://lkml.org/lkml/2013/1/29/47 The script direct-io.py are introduced by this patch can record the 2 tracepoint events, analyse the sample data, and give a concise report. usage: "perf script record direct-io\n" "perf script report direct-io [comm|pid]\n" Cc: Peter Zijlstra Cc: Paul Mackerras Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Cc: David Ahern Cc: Arjan van de Ven Cc: Namhyung Kim Cc: Yanmin Zhang Cc: Wu Fengguang Cc: Mike Galbraith Cc: Andrew Morton Signed-off-by: Chenggang Qin --- tools/perf/scripts/python/bin/direct-io-record |2 + tools/perf/scripts/python/bin/direct-io-report | 21 +++ tools/perf/scripts/python/direct-io.py | 185 3 files changed, 208 insertions(+) create mode 100755 tools/perf/scripts/python/bin/direct-io-record create mode 100644 tools/perf/scripts/python/bin/direct-io-report create mode 100644 tools/perf/scripts/python/direct-io.py diff --git a/tools/perf/scripts/python/bin/direct-io-record b/tools/perf/scripts/python/bin/direct-io-record new file mode 100755 index 000..4857097 --- /dev/null +++ b/tools/perf/scripts/python/bin/direct-io-record @@ -0,0 +1,2 @@ +#!/bin/bash +perf record -e vfs:direct_io_read -e vfs:direct_io_write $@ diff --git a/tools/perf/scripts/python/bin/direct-io-report b/tools/perf/scripts/python/bin/direct-io-report new file mode 100644 index 000..828d9c6 --- /dev/null +++ b/tools/perf/scripts/python/bin/direct-io-report @@ -0,0 +1,21 @@ +#!/bin/bash +# description: direct_io statistic +# args: [comm|pid] +n_args=0 +for i in "$@" +do +if expr match "$i" "-" > /dev/null ; then + break +fi +n_args=$(( $n_args + 1 )) +done +if [ "$n_args" -gt 1 ] ; then +echo "usage: perf script report direct-io [comm|pid]" +exit +fi + +if [ "$n_args" -gt 0 ] ; then +comm=$1 +shift +fi +perf script $@ -s "$PERF_EXEC_PATH"/scripts/python/direct-io.py $comm diff --git a/tools/perf/scripts/python/direct-io.py b/tools/perf/scripts/python/direct-io.py new file mode 100644 index 000..321ff8e --- /dev/null +++ b/tools/perf/scripts/python/direct-io.py @@ -0,0 +1,185 @@ +# direct IO counts +# (c) 2013, Chenggang Qin +# Licensed under the terms of the GNU GPL License version 2 + +# Displays system-wide file direct IO behavior. +# It helps us to investigate which processes trigger a direct IO, +# and what files are accessed by these processes. +# +# options +# comm, pid: show details of the file r/w behavior of a special process. + +import os, sys + +sys.path.append(os.environ['PERF_EXEC_PATH'] + \ + '/scripts/python/Perf-Trace-Util/lib/Perf/Trace') + +from perf_trace_context import * +from Core import * +from Util import * + +usage = "perf script record direct-io\n" \ + "perf script report direct-io [comm|pid]\n" + +for_comm = None +for_pid = None +pid_2_comm = None + +if len(sys.argv) > 2: + sys.exit(usage) + +if len(sys.argv) > 1: + try: + for_pid = int(sys.argv[1]) + except: + for_comm = sys.argv[1] + +file_write = autodict() +file_read = autodict() + +file_write_bytes = autodict() +file_read_bytes = autodict() + +comm_read_info = autodict() +comm_write_info = autodict() + +wevent_count = 0 +revent_count = 0 + +comm_revent_count = 0; +comm_wevent_count = 0; + +def trace_begin(): + print "Press control+C to stop and show the summary" + +def trace_end(): + if (for_comm is not None) or (for_pid is not None): + print_direct_io_event_for_comm() + else: + print_direct_io_event_totals() + +def vfs__direct_io_write(event_name, context, common_cpu, + common_secs, common_nsecs, common_pid, common_comm, + pos, bytes, fname): + global wevent_count + global comm_wevent_count + global pid_2_comm + + if (for_comm is not None) or (for_pid is not None): + if (common_comm != for_comm) and (common_pid != for_pid): + return + else: + if (pid_2_comm is None) and (for_pid is not None): + pid_2_comm = common_comm + comm_write_in
Re: [RFC] arm: use built-in byte swap function
On Wed, Jan 30, 2013 at 08:09:00PM -0600, Kim Phillips wrote: > diff --git a/arch/Kconfig b/arch/Kconfig > index 40e2b12..c8798b9 100644 > --- a/arch/Kconfig > +++ b/arch/Kconfig > @@ -141,6 +141,16 @@ config ARCH_USE_BUILTIN_BSWAP >instructions should set this. And it shouldn't hurt to set it >on architectures that don't have such instructions. > > +config ARCH_DEFINES_BUILTIN_BSWAP > + depends on ARCH_USE_BUILTIN_BSWAP > + bool > + help > + ARCH selects this when it wants to control HAVE_BUILTIN_BSWAPxx This is what threw me off: if ARCH selects this, I don't think we want to have a help text and the option be user visible? Normally such options are only bool and are selected automatically by hm.. ARCH, as you say above and do so below. :-) > + definitions over those in the generic compiler headers. It > + can be dependent on a combination of byte swapping instruction > + availability, the instruction set version, and the state > + of support in different compiler versions. > + > config HAVE_SYSCALL_WRAPPERS > bool > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 73027aa..b5868c2 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -57,6 +57,8 @@ config ARM > select CLONE_BACKWARDS > select OLD_SIGSUSPEND3 > select OLD_SIGACTION > + select ARCH_USE_BUILTIN_BSWAP > + select ARCH_DEFINES_BUILTIN_BSWAP > help Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] regulator: max8997: Use of_get_child_count()
On Wed, Jan 30, 2013 at 08:52:49PM +0800, Axel Lin wrote: > Signed-off-by: Axel Lin Applied both, thanks. signature.asc Description: Digital signature
Re: [PATCH] regulator: tps65090: Fix using wrong dev argument for calling of_regulator_match
On Wed, Jan 30, 2013 at 08:28:20PM +0800, Axel Lin wrote: > The dev parameter is the device requesting the data. > In this case it should be &pdev->dev rather than pdev->dev.parent. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH V3] regulators: anatop: add set_voltage_time_sel interface
On Thu, Jan 31, 2013 at 11:23:53AM -0500, Anson Huang wrote: > some of anatop's regulators(cpu, vddpu and vddsoc) have > register settings about LDO's step time, which will impact > the LDO ramp up speed, need to use set_voltage_time_sel > interface to add necessary delay everytime LDOs' voltage > is increased. Applied, thanks. It does seem like... > +#define LDO_RAMP_UP_UNIT_IN_CYCLES 64 /* 64 cycles per step */ > +#define LDO_RAMP_UP_FREQ_IN_MHZ 24 /* cycle based on 24M OSC */ ...this ought to go into device tree too (at least the oscillator frequency). Please do also use subject lines appropriate to the subsystem. signature.asc Description: Digital signature
Re: [RFC 2/2] sched/fair: prefer a CPU in the "lowest" idle state
On 01/31/2013 01:16 PM, Namhyung Kim wrote:
> Hi Sebastian and Michael,
>
> On Thu, 31 Jan 2013 10:12:35 +0800, Michael Wang wrote:
>> On 01/31/2013 05:19 AM, Sebastian Andrzej Siewior wrote:
>>> If a new CPU has to be choosen for a task, then the scheduler first selects
>>> the group with the least load. This group is returned if its load is lower
>>> compared to the group to which the task is currently assigned.
>>> If there are several groups with completely idle CPU(s) (the CPU is in
>>> an idle state like C1) then the first group is returned.
>>> This patch extends this decision by considering the idle state of CPU(s)
>>> in the group and the first group with a CPU in the lowest idle state
>>> wins (C1 is prefered over C2). If there is a CPU which is not in an idle
>>> state (C0) but has no tasks assigned then it is consider as a valid target.
>>> Should there be no CPU in an idle state at disposal then the loadavg is
>>> used as a fallback.
> [snip]
>>> @@ -3181,8 +3182,10 @@ find_idlest_group(struct sched_domain *sd, struct
>>> task_struct *p,
>>> int this_cpu, int load_idx)
>>> {
>>> struct sched_group *idlest = NULL, *group = sd->groups;
>>> + struct sched_group *idle_group = NULL;
>>> unsigned long min_load = ULONG_MAX, this_load = 0;
>>> int imbalance = 100 + (sd->imbalance_pct-100)/2;
>>> + int least_idle_cpu = INT_MAX;
>>>
>>> do {
>>> unsigned long load, avg_load;
>>> @@ -3208,6 +3211,25 @@ find_idlest_group(struct sched_domain *sd, struct
>>> task_struct *p,
>>> load = target_load(i, load_idx);
>>>
>>> avg_load += load;
>>> + if (!local_group && sd->prefer_lp && least_idle_cpu) {
>>> + int idle_level;
>>> +
>>> + idle_level = cpuidle_get_state(i);
>>> + /*
>>> +* Select the CPU which is in the lowest
>>> +* possible power state. Take the active
>>> +* CPU only if its run queue is empty.
>>> +*/
>>> + if (!idle_level) {
>>> + if (idle_cpu(i)) {
>>> + least_idle_cpu = idle_level;
>>> + idle_group = group;
>>> + }
>>> + } else if (least_idle_cpu > idle_level) {
>>> + least_idle_cpu = idle_level;
>>> + idle_group = group;
>>> + }
>>> + }
>>> }
>>>
>>> /* Adjust by relative CPU power of the group */
>>> @@ -3221,6 +3243,8 @@ find_idlest_group(struct sched_domain *sd, struct
>>> task_struct *p,
>>> }
>>> } while (group = group->next, group != sd->groups);
>>>
>>> + if (idle_group)
>>> + return idle_group;
>>
>> I'm not sure, but just concern about this case:
>>
>> group 0 cpu 0 cpu 1
>> least idle 4 task
>>
>> group 1 cpu 2 cpu 3
>> 1 task 1 task
>>
>> The previous logical will pick group 1 and now it will take group 0, and
>> that cause more imbalance, doesn't it?
>>
>> May be check that state in find_idlest_cpu() will be better?
>
> Right, at least find_idlest_cpu() should also check the idle_level IMHO.
>
> Anyway, I have an idea with this in mind. It's like adding a new "idle
> load" to each idle cpu rather than special casing the idle cpus like
> above. IOW an idle cpu will get very small load weight depends on how
> deep it's slept so that it can be compared to other cpus in a same way
> but we can find prefered (lowest load) cpu among the idle cpus.
>
> The simple way I can think of is adding idle_level to a rq load in
> weighted_cpuload():
>
> static unsigned long weighted_cpuload(const int cpu)
> {
> return cpu_rq(cpu)->load.weight + cpuidle_get_state(cpu);
> }
Hmm... then we don't need changes in find_idlest_cpu(), just compare the
load as before, but it works only when the appendix state value is
smaller than the lowest load of one task, which is 15 currently, I'm not
sure whether we have the promise...
Regards,
Michael Wang
>
> What do you think?
>
> Thanks,
> Namhyung
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
On Thu, Jan 31, 2013 at 1:54 PM, Mark Zhang wrote: > Display controller don't know whether the panel has EDID EEPROM but the > panel driver knows. So why we need to make display controller queries > EDID blindly? Since panel driver knows about all "video modes/panel > size" stuffs, why not we let it handle all these things? The DC actually does know whether the connected panel supports EDID - in this case, the output node will have a property for the DDC bus, e.g. nvidia,ddc-i2c-bus = <&lcd_ddc>; If no DDC bus is specified or if transfer fails, the DC driver can still query the panel driver for hardcoded modes. Also passing a function pointer to get_modes() does not relief the DC driver from probing for the DDC bus. You will still have to handle both conditions (DDC bus present or not), the check will just be moved into your callback function. Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm: dts: omap4-panda: Add I2c pinctrl data
Booting 3.8-rc4 on omap4 panda results in the following error
[0.27] omap_i2c 4807.i2c: did not get pins for i2c error: -19
[0.445770] omap_i2c 4807.i2c: bus 0 rev0.11 at 400 kHz
[0.473937] omap_i2c 48072000.i2c: did not get pins for i2c error: -19
[0.474670] omap_i2c 48072000.i2c: bus 1 rev0.11 at 400 kHz
[0.474822] omap_i2c 4806.i2c: did not get pins for i2c error: -19
[0.476379] omap_i2c 4806.i2c: bus 2 rev0.11 at 100 kHz
[0.477294] omap_i2c 4835.i2c: did not get pins for i2c error: -19
[0.477996] omap_i2c 4835.i2c: bus 3 rev0.11 at 400 kHz
[0.483398] Switching to clocksource 32k_counter
This happens because omap4 panda dts file is not adapted to use i2c through
pinctrl framework. Populating i2c pinctrl data to get rid of the error.
Tested on omap4460 panda with 3.8-rc4 kernel.
Signed-off-by: Sourav Poddar
Reported-by: Luciano Coelho
---
arch/arm/boot/dts/omap4-panda.dts | 40 +
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..f951e6b 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -110,9 +110,40 @@
0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN |
MODE3 */
>;
};
+
+ i2c1_pins: pinmux_i2c1_pins {
+ pinctrl-single,pins = <
+ 0xe2 0x118/* i2c1_scl PULLUP | INPUTENABLE |
MODE0 */
+ 0xe4 0x118/* i2c1_sda PULLUP | INPUTENABLE |
MODE0 */
+ >;
+ };
+
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins = <
+ 0xe6 0x118/* i2c2_scl PULLUP | INPUTENABLE |
MODE0 */
+ 0xe8 0x118/* i2c2_sda PULLUP | INPUTENABLE |
MODE0 */
+ >;
+ };
+
+ i2c3_pins: pinmux_i2c3_pins {
+ pinctrl-single,pins = <
+ 0xea 0x118/* i2c3_scl PULLUP | INPUTENABLE |
MODE0 */
+ 0xec 0x118 /* i2c3_sda PULLUP | INPUTENABLE | MODE0
*/
+ >;
+ };
+
+ i2c4_pins: pinmux_i2c4_pins {
+ pinctrl-single,pins = <
+ 0xee 0x118/* i2c4_scl PULLUP | INPUTENABLE |
MODE0 */
+ 0xf0 0x118 /* i2c4_sda PULLUP | INPUTENABLE | MODE0
*/
+ >;
+ };
};
&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins>;
+
clock-frequency = <40>;
twl: twl@48 {
@@ -139,10 +170,16 @@
/include/ "twl6030.dtsi"
&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins>;
+
clock-frequency = <40>;
};
&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3_pins>;
+
clock-frequency = <10>;
/*
@@ -156,6 +193,9 @@
};
&i2c4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c4_pins>;
+
clock-frequency = <40>;
};
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Avoid high order memory allocating with kmalloc, when read large seq file
Hi Rientjes
Thanks a lot for your info, yes, you are right, I just re-send the patch,
could you please review?
Br
Xiaobing
-Original Message-
From: David Rientjes [mailto:rient...@google.com]
Sent: Wednesday, January 30, 2013 5:49 AM
To: Tu, Xiaobing
Cc: linux-kernel@vger.kernel.org; Tang, Guifang; Chen, LinX Z; Andrew Morton
Subject: Re: Avoid high order memory allocating with kmalloc, when read large
seq file
On Tue, 29 Jan 2013, xtu4 wrote:
> Subject: [PATCH] [SEQ_FILE] Avoid high order memory allocating with
> kmalloc when read large seq file
>
> currently, when dumpstate access /proc/xxx/binder , this binder
> include lots of info, it will use seq_read in kernel, in this
> function, it will trigger high order memory alloc, when read binder
> info or other large file, this will cause memory presure when system
> don't have contious high order memory, it will lead to high kswap
> workload to reclaim the page. so change kmalloc to vmalloc, it can
> avoid contiously high order memory allocating.
> [ 4356.532357] dumpstate: page allocation failure: order:4, mode:0x40d0
> [ 4356.532400] Pid: 18256, comm: dumpstate Tainted: G C
> 3.0.34-141128-g4be7088 #1
> [ 4356.532416] Call Trace:
> [ 4356.532443] [] ? printk+0x1d/0x1f [ 4356.532467]
> [] warn_alloc_failed+0xbf/0xf0 [ 4356.532491] []
> __alloc_pages_nodemask+0x4ba/0x6a0
> [ 4356.532521] [] __get_free_pages+0x1c/0x30 [ 4356.532541]
> [] kmalloc_order_trace+0x21/0xd0 [ 4356.532561]
> [] ? seq_read+0x137/0x390 [ 4356.532579] []
> __kmalloc+0x20a/0x230 [ 4356.532596] [] ?
> seq_read+0x137/0x390 [ 4356.532616] [] ? put_page+0x2c/0x40
> [ 4356.532634] [] ? kfree+0xcd/0x160 [ 4356.532655]
> [] ? mutex_unlock+0xd/0x10 [ 4356.532675] []
> seq_read+0x149/0x390 [ 4356.532697] [] vfs_read+0x8c/0x160
> [ 4356.532716] [] ? seq_lseek+0x180/0x180 [ 4356.532735]
> [] sys_read+0x3d/0x70 [ 4356.532755] []
> syscall_call+0x7/0xb [ 4356.532777] [] ?
> log_dir_items+0x33d/0x40c
> Signed-off-by: xiaobing tu
> Signed-off-by: linX z chen
> Signed-off-by: guifang tang
> Change-Id: I892c97d02cf25e59b23c9bc68dff754ea01c1d56
> ---
> fs/seq_file.c | 18 +++---
> 1 files changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/fs/seq_file.c b/fs/seq_file.c index dba43c3..20b8e36
> 100644
> --- a/fs/seq_file.c
> +++ b/fs/seq_file.c
> @@ -209,8 +209,17 @@ ssize_t seq_read(struct file *file, char __user
> *buf, size_t size, loff_t *ppos)
> if (m->count < m->size)
> goto Fill;
> m->op->stop(m, p);
> -kfree(m->buf);
> -m->buf = kmalloc(m->size <<= 1, GFP_KERNEL);
> +if (m->size > 2 * PAGE_SIZE) {
> +vfree(m->buf);
> +} else
> +kfree(m->buf);
> +m->size <<= 1;
> +if (m->size > 2 * PAGE_SIZE) {
> +m->buf = vmalloc(m->size);
> +} else
> +m->buf = kmalloc(m->size <<= 1, GFP_KERNEL);
I thought m->size was already shifted.
Your patch is severely mangled, please check out
Documentation/SubmittingPatches and Documentation/email-clients.txt.
> +
> +
> if (!m->buf)
> goto Enomem;
> m->count = 0;
> @@ -325,7 +334,10 @@ EXPORT_SYMBOL(seq_lseek); int seq_release(struct
> inode *inode, struct file *file) {
> struct seq_file *m = file->private_data;
> -kfree(m->buf);
> +if (m->size > 2 * PAGE_SIZE) {
> +vfree(m->buf);
> +} else
> +kfree(m->buf);
> kfree(m);
> return 0;
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 00/15] memory-hotplug: hot-remove physical memory
Hi Tang,
On Thu, 2013-01-31 at 11:31 +0800, Tang Chen wrote:
> Hi Simon,
>
> Please see below. :)
>
> On 01/31/2013 09:22 AM, Simon Jeons wrote:
> >
> > Sorry, I still confuse. :(
> > update node_states[N_NORMAL_MEMORY] to node_states[N_MEMORY] or
> > node_states[N_NORMAL_MEMOR] present 0...ZONE_MOVABLE?
> >
> > node_states is what? node_states[N_NORMAL_MEMOR] or
> > node_states[N_MEMORY]?
>
> Are you asking what node_states[] is ?
>
> node_states[] is an array of nodemask,
>
> extern nodemask_t node_states[NR_NODE_STATES];
>
> For example, node_states[N_NORMAL_MEMOR] represents which nodes have
> normal memory.
> If N_MEMORY == N_HIGH_MEMORY == N_NORMAL_MEMORY, node_states[N_MEMORY] is
> node_states[N_NORMAL_MEMOR]. So it represents which nodes have 0 ...
> ZONE_MOVABLE.
>
Sorry, how can nodes_state[N_NORMAL_MEMORY] represents a node have 0 ...
*ZONE_MOVABLE*, the comment of enum nodes_states said that
N_NORMAL_MEMORY just means the node has regular memory.
>
> > Why check !z1->wait_table in function move_pfn_range_left and function
> > __add_zone? I think zone->wait_table is initialized in
> > free_area_init_core, which will be called during system initialization
> > and hotadd_new_pgdat path.
>
> I think,
>
> free_area_init_core(), in the for loop,
> |--> size = zone_spanned_pages_in_node();
> |--> if (!size)
>continue; If zone is empty, we jump
> out the for loop.
> |--> init_currently_empty_zone()
>
> So, if the zone is empty, wait_table is not initialized.
>
> In move_pfn_range_left(z1, z2), we move pages from z2 to z1. But z1
> could be empty.
> So we need to check it and initialize z1->wait_table because we are
> moving pages into it.
thanks.
>
>
> > There is a zone populated check in function online_pages. But zone is
> > populated in free_area_init_core which will be called during system
> > initialization and hotadd_new_pgdat path. Why still need this check?
> >
>
> Because we could also rebuild zone list when we offline pages.
>
> __offline_pages()
> |--> zone->present_pages -= offlined_pages;
> |--> if (!populated_zone(zone)) {
>build_all_zonelists(NULL, NULL);
>}
>
> If the zone is empty, and other zones on the same node is not empty, the
> node
> won't be offlined, and next time we online pages of this zone, the pgdat
> won't
> be initialized again, and we need to check populated_zone(zone) when
> onlining
> pages.
thanks.
>
> Thanks. :)
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Avoid high order memory allocating with kmalloc, when read large seq file
Hi Morton
Thank you very much for your kindly info, In android system,, when you read
/sys/kernel/debug/binder/proc/xxx, xxx is the process id , it will trigger high
order kmalloc.
But we can't limit the size of binder info, because we need this to debug the
binder related issue.
I had re-send the patch, how do you think for about using vmalloc instaed of
kmalloc when malloc high order allocating? Memory gragment should not be the
issue, because this is very quick to free such memory.
Br
Xiaobing
-Original Message-
From: Andrew Morton [mailto:a...@linux-foundation.org]
Sent: Wednesday, January 30, 2013 8:25 AM
To: Tu, Xiaobing
Cc: linux-kernel@vger.kernel.org; Tang, Guifang; Chen, LinX Z; Arve Hjønnevåg
Subject: Re: Avoid high order memory allocating with kmalloc, when read large
seq file
On Tue, 29 Jan 2013 14:14:14 +0800
xtu4 wrote:
> @@ -209,8 +209,17 @@ ssize_t seq_read(struct file *file, char __user
> *buf, size_t size, loff_t *ppos)
> if (m->count < m->size)
> goto Fill;
> m->op->stop(m, p);
> -kfree(m->buf);
> -m->buf = kmalloc(m->size <<= 1, GFP_KERNEL);
> +if (m->size > 2 * PAGE_SIZE) {
> +vfree(m->buf);
> +} else
> +kfree(m->buf);
> +m->size <<= 1;
> +if (m->size > 2 * PAGE_SIZE) {
> +m->buf = vmalloc(m->size);
> +} else
> +m->buf = kmalloc(m->size <<= 1, GFP_KERNEL);
> +
> +
> if (!m->buf)
> goto Enomem;
> m->count = 0;
> @@ -325,7 +334,10 @@ EXPORT_SYMBOL(seq_lseek);
The conventional way of doing this is to attempt the kmalloc with __GFP_NOWARN
and if that failed, fall back to vmalloc().
Using vmalloc is generally not a good thing, mainly because of fragmentation
issues, but for short-lived allocations like this, that shouldn't be too bad.
But really, the binder code is being obnoxious here and it would be best to fix
it up. Please identify with some care which part of the binder code is causing
this problem. binder_stats_show(), from a guess? It looks like that
function's output size is proportional to the number of processes on
binder_procs? If so, there is no upper bound, is there? Problem!
btw, binder_debug_no_lock should just go away. That list needs locking.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] regulators: anatop: add set_voltage_time_sel interface
On Thu, Jan 31, 2013 at 11:23:53AM -0500, Anson Huang wrote: > some of anatop's regulators(cpu, vddpu and vddsoc) have > register settings about LDO's step time, which will impact > the LDO ramp up speed, need to use set_voltage_time_sel > interface to add necessary delay everytime LDOs' voltage > is increased. > > offset 0x170: > bit [24-25]: cpu > bit [26-27]: vddpu > bit [28-29]: vddsoc > > field definition: > 0'b00: 64 cycles of 24M clock; > 0'b01: 128 cycles of 24M clock; > 0'b02: 256 cycles of 24M clock; > 0'b03: 512 cycles of 24M clock; > > Signed-off-by: Anson Huang Acked-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
resend----[PATCH] Avoid high order memory allocating with kmalloc, when read large seq file
[SEQ_FILE] Avoid high order memory allocating with kmalloc
when read large seq file
currently, when dumpstate access /proc/xxx/binder , this binder include
lots of info,
it will use seq_read in kernel, in this function, it will trigger high
order memory alloc,
when read binder info or other large file, this will cause memory
presure when system
don't have contious high order memory, it will lead to high kswap
workload to reclaim the
page. so change kmalloc to vmalloc, it can avoid contiously high order
memory allocating.
[ 4356.532357] dumpstate: page allocation failure: order:4, mode:0x40d0
[ 4356.532400] Pid: 18256, comm: dumpstate Tainted: G C
3.0.34-141128-g4be7088 #1
[ 4356.532416] Call Trace:
[ 4356.532443] [] ? printk+0x1d/0x1f
[ 4356.532467] [] warn_alloc_failed+0xbf/0xf0
[ 4356.532491] [] __alloc_pages_nodemask+0x4ba/0x6a0
[ 4356.532521] [] __get_free_pages+0x1c/0x30
[ 4356.532541] [] kmalloc_order_trace+0x21/0xd0
[ 4356.532561] [] ? seq_read+0x137/0x390
[ 4356.532579] [] __kmalloc+0x20a/0x230
[ 4356.532596] [] ? seq_read+0x137/0x390
[ 4356.532616] [] ? put_page+0x2c/0x40
[ 4356.532634] [] ? kfree+0xcd/0x160
[ 4356.532655] [] ? mutex_unlock+0xd/0x10
[ 4356.532675] [] seq_read+0x149/0x390
[ 4356.532697] [] vfs_read+0x8c/0x160
[ 4356.532716] [] ? seq_lseek+0x180/0x180
[ 4356.532735] [] sys_read+0x3d/0x70
[ 4356.532755] [] syscall_call+0x7/0xb
[ 4356.532777] [] ? log_dir_items+0x33d/0x40c
the m->size is very huge
<3>[ 1185.457656, 1] xiaobing >> seq_read: m->size 8192
<3>[ 1185.463462, 1] xiaobing >> seq_read: m->size 16384
<3>[ 1185.470472, 1] xiaobing >> seq_read: m->size 32768
<3>[ 1185.481201, 0] xiaobing >> seq_read: m->size 8192
<3>[ 1185.488071, 0] xiaobing >> seq_read: m->size 16384
<3>[ 1185.495892, 0] xiaobing >> seq_read: m->size 32768
<3>[ 1185.504841, 0] xiaobing >> seq_read: m->size 65536
<3>[ 1185.517180, 0] xiaobing >> seq_read: m->size 131072
<3>[ 1185.536286, 0] xiaobing >> seq_read: m->size 262144
some times even more then 262144 byte
Signed-off-by: xiaobing tu
Change-Id: I892c97d02cf25e59b23c9bc68dff754ea01c1d56
---
fs/seq_file.c | 22 +-
1 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/fs/seq_file.c b/fs/seq_file.c
index dba43c3..19df826 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -12,7 +12,7 @@
#include
#include
-
+#include
/**
*seq_open -initialize sequential file
*@file: file we initialize
@@ -116,7 +116,13 @@ static int traverse(struct seq_file *m, loff_t offset)
Eoverflow:
m->op->stop(m, p);
kfree(m->buf);
-m->buf = kmalloc(m->size <<= 1, GFP_KERNEL);
+
+is_vmalloc_addr(m->buf) ? vfree(m->buf) : kfree(m->buf);
+m->size <<= 1;
+if (m->size <= (2 * PAGE_SIZE))
+m->buf = kmalloc(m->size, GFP_KERNEL);
+else
+m->buf = vmalloc(m->size);
return !m->buf ? -ENOMEM : -EAGAIN;
}
@@ -209,8 +215,14 @@ ssize_t seq_read(struct file *file, char __user
*buf, size_t size, loff_t *ppos)
if (m->count < m->size)
goto Fill;
m->op->stop(m, p);
-kfree(m->buf);
-m->buf = kmalloc(m->size <<= 1, GFP_KERNEL);
+is_vmalloc_addr(m->buf) ? vfree(m->buf) : kfree(m->buf);
+m->size <<= 1;
+if (m->size > 2 * PAGE_SIZE)
+m->buf = vmalloc(m->size);
+else
+m->buf = kmalloc(m->size, GFP_KERNEL);
+
+
if (!m->buf)
goto Enomem;
m->count = 0;
@@ -325,7 +337,7 @@ EXPORT_SYMBOL(seq_lseek);
int seq_release(struct inode *inode, struct file *file)
{
struct seq_file *m = file->private_data;
-kfree(m->buf);
+is_vmalloc_addr(m->buf) ? vfree(m->buf) : kfree(m->buf);
kfree(m);
return 0;
}
--
1.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drm/radeon: Calling object_unrefer() when creating fb failure
From: liu chuansheng
Date: Thu, 31 Jan 2013 22:13:00 +0800
Subject: [PATCH] drm/radeon: Calling object_unrefer() when creating fb
failure
When kzalloc() failed in radeon_user_framebuffer_create(), need to
call object_unreference() to match the object_reference().
Signed-off-by: liu chuansheng
Signed-off-by: xueminsu
---
drivers/gpu/drm/radeon/radeon_display.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index ff3def7..05c96fa 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1115,8 +1115,10 @@ radeon_user_framebuffer_create(struct drm_device *dev,
}
radeon_fb = kzalloc(sizeof(*radeon_fb), GFP_KERNEL);
- if (radeon_fb == NULL)
+ if (radeon_fb == NULL) {
+ drm_gem_object_unreference_unlocked(obj);
return ERR_PTR(-ENOMEM);
+ }
ret = radeon_framebuffer_init(dev, radeon_fb, mode_cmd, obj);
if (ret) {
--
1.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git pull] revert the console lockdep
Hi Linus, as suggested lets undo the console lock lockdep tracking for now, Dave. The following changes since commit 2e51b231a8d716ea5aacde0bd95ac789cea195b0: Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux (2013-01-30 12:02:26 +1100) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to ff0d05bf73620eb7dc8aee7423e992ef87870bdf: Revert "console: implement lockdep support for console_lock" (2013-01-31 15:46:56 +1100) Dave Airlie (1): Revert "console: implement lockdep support for console_lock" kernel/printk.c | 9 - 1 file changed, 9 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 4/4] sd: change to auto suspend mode
On Wed, Jan 30, 2013 at 10:38:26AM -0500, Alan Stern wrote:
> On Wed, 30 Jan 2013, Aaron Lu wrote:
>
> > From: Lin Ming
> >
> > Uses block layer runtime pm helper functions in
> > scsi_runtime_suspend/resume for devices that take advantage of it.
> >
> > Remove scsi_autopm_* from sd open/release path and check_events path.
> >
> > Signed-off-by: Lin Ming
> > Signed-off-by: Aaron Lu
>
> A couple of very minor suggestions...
>
> > --- a/drivers/scsi/scsi_pm.c
> > +++ b/drivers/scsi/scsi_pm.c
>
> > @@ -144,18 +144,44 @@ static int scsi_bus_restore(struct device *dev)
> >
> > #ifdef CONFIG_PM_RUNTIME
> >
> > +static int scsi_blk_runtime_suspend(struct device *dev)
> > +{
> > + struct scsi_device *sdev = to_scsi_device(dev);
>
> For this routine and the other new ones, it may be slightly more
> efficient to pass both dev and sdev as arguments (this depends on how
> smart the compiler's optimizer is). The caller already knows both of
> them, after all.
What about passing only scsi_device? When device is needed, I can use
&sdev->sdev_gendev. Is this equally efficient?
> > static int scsi_runtime_suspend(struct device *dev)
> > {
> > int err = 0;
> > - const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
> >
> > dev_dbg(dev, "scsi_runtime_suspend\n");
> > if (scsi_is_sdev_device(dev)) {
> > - err = scsi_dev_type_suspend(dev,
> > - pm ? pm->runtime_suspend : NULL);
> > - if (err == -EAGAIN)
> > - pm_schedule_suspend(dev, jiffies_to_msecs(
> > - round_jiffies_up_relative(HZ/10)));
> > + struct scsi_device *sdev = to_scsi_device(dev);
>
> There should be a blank line between the declaration and the
> executable code.
OK, will change this.
> > @@ -185,10 +233,17 @@ static int scsi_runtime_idle(struct device *dev)
> >
> > /* Insert hooks here for targets, hosts, and transport classes */
> >
> > - if (scsi_is_sdev_device(dev))
> > - err = pm_schedule_suspend(dev, 100);
> > - else
> > + if (scsi_is_sdev_device(dev)) {
> > + struct scsi_device *sdev = to_scsi_device(dev);
>
> Blank line.
>
> > + if (sdev->request_queue->dev) {
> > + pm_runtime_mark_last_busy(dev);
> > + err = pm_runtime_autosuspend(dev);
> > + } else {
> > + err = pm_schedule_suspend(dev, 100);
> > + }
> > + } else {
> > err = pm_runtime_suspend(dev);
> > + }
> > return err;
Shall we ignore the return value for these pm_xxx_suspend functions?
I mean we do not need to record the return value for them and return it,
since pm core doesn't care the return value of idle callback.
Thanks,
Aaron
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH v5 1/4] zram: Fix deadlock bug in partial write
On Wed, Jan 30, 2013 at 05:21:12PM +0900, Minchan Kim wrote: > Hi Greg, > > On Tue, Jan 29, 2013 at 11:20:06PM -0500, Greg Kroah-Hartman wrote: > > On Mon, Jan 28, 2013 at 09:38:23AM +0900, Minchan Kim wrote: > > > Now zram allocates new page with GFP_KERNEL in zram I/O path > > > if IO is partial. Unfortunately, It may cuase deadlock with > > > reclaim path so this patch solves the problem. > > > > > > Cc: sta...@vger.kernel.org > > > Cc: Jerome Marchand > > > Acked-by: Nitin Gupta > > > Signed-off-by: Minchan Kim > > > --- > > > drivers/staging/zram/zram_drv.c |4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > Due to the discussion on this series, I don't know what patch to apply, > > so care to do a v6 of this with the patches that everyone has finally > > agreed on? > > I already sent v6. > https://lkml.org/lkml/2013/1/29/680 Greg, If you have a trouble to merge it, let me know it. Will resend it when linux-next comes in. Thanks. -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Query related to MSR(Magnetic Stripe Reader) Device Driver
Hi Greg, On Tue, Jan 29, 2013 at 7:03 PM, Greg KH wrote: > On Mon, Jan 28, 2013 at 03:25:08PM +0530, Priyaranjan Das wrote: >> Hi Greg, >> >> On Tue, Jan 22, 2013 at 10:06 PM, Greg KH wrote: >> > On Tue, Jan 22, 2013 at 03:02:32PM +0530, Priyaranjan Das wrote: >> >> Hi All, >> >> >> >> I am working on MSR(Magnetic Stripe Reader) for a product . I wish to >> >> know whether any MSR( Magnetic Stripe/card Reader) driver is available >> >> in the current source or not. I need this for reference. Could anyone >> >> please help me? >> > >> > Most of these types of devices that I have worked with always show up as >> > a keyboard device (ps/2 pass-through or a USB hid device.) What type of >> > interface does your device present to the operating system? >> > >> >> The MSR will be a part of a SoC. It is a memory mapped device hence >> there is no interface like USB. > > Ok, that's different. But how will your driver want to communicate the > reader data to userspace? That will probably determine where you want > to put it. > > I would recommend making it an input device and sending keystrokes that > you read from the card, so you can properly integrate into userspace > applications that are used to using a card reader. > >> MSR IP contains an ADC which the driver will read and interpret the >> data. I am planning to write a Driver for the same. Will this driver >> fall under drivers/mfd/* ? > > As per the above, I would think drivers/input/ wouldn't you? > > Hope this helps, > Thanks for your help!. Yes, you are right, it should be under drivers/input. I am trying to prepare the design right now. Regards, Priyaranjan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: circular locking dependency detected
On Thu, Jan 31, 2013 at 11:26:53AM +1100, Linus Torvalds wrote: > On Thu, Jan 31, 2013 at 11:13 AM, Russell King wrote: > > > > Which may or may not be a good thing depending how you look at it; it > > means that once your kernel blanks, you get a lockdep dump. At that > > point you lose lockdep checking for everything else because lockdep > > disables itself after the first dump. > > Fair enough, we may want to revert the lockdep checking for > console_lock, and make re-enabling it part of the patch-series that > fixes the locking. > > Daniel/Dave? Does that sound reasonable? Reverting the patch is fine with me. Just let me know so I can queue it up again for 3.9. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 2/7] zsmalloc: promote to lib/
On Wed, Jan 30, 2013 at 10:28:41AM -0600, Seth Jennings wrote: > On 01/29/2013 04:51 PM, Andrew Morton wrote: > > On Tue, 29 Jan 2013 15:40:22 -0600 > > Seth Jennings wrote: > > > >> This patch promotes the slab-based zsmalloc memory allocator > >> from the staging tree to lib/ > > > > Hate to rain on the parade, but... we haven't reviewed zsmalloc > > yet. At least, I haven't, and I haven't seen others do so. > > > > So how's about we forget that zsmalloc was previously in staging and > > send the zsmalloc code out for review? With a very good changelog > > explaining why it exists, what problems it solves, etc. > > > > > > I peeked. > > > > Don't answer any of the below questions - they are examples of > > concepts which should be accessible to readers of the > > hopefully-forthcoming very-good-changelog. > > > > - kmap_atomic() returns a void* - there's no need to cast its return value. > > > > - Remove private MAX(), use the (much better implemented) max(). > > > > - It says "This was one of the major issues with its predecessor > > (xvmalloc)", but drivers/staging/ramster/xvmalloc.c is still in the tree. > > > > - USE_PGTABLE_MAPPING should be done via Kconfig. > > > > - USE_PGTABLE_MAPPING is interesting and the changelog should go into > > some details. What are the pros and cons here? Why do the two > > options exist? Can we eliminate one mode or the other? > > > > - Various functions are obscure and would benefit from explanatory > > comments. Good comments explain "why it exists", more than "what it > > does". > > > > These include get_size_class_index, get_fullness_group, > > insert_zspage, remove_zspage, fix_fullness_group. > > > > Also a description of this handle encoding thing - what do these > > "handles" refer to? Why is stuff being encoded into them and how? > > > > - I don't understand how the whole thing works :( If I allocate a > > 16 kbyte object with zs_malloc(), what do I get? 16k of > > contiguous memory? How can it do that if > > USE_PGTABLE_MAPPING=false? Obviously it can't so it's doing > > something else. But what? > > > > - What does zs_create_pool() do and how do I use it? It appears > > to create a pool of all possible object sizes. But why do we need > > more than one such pool kernel-wide? > > > > - I tried to work out the actual value of ZS_SIZE_CLASSES but it > > made my head spin. > > > > - We really really don't want to merge zsmalloc! It would be far > > better to use an existing allocator (perhaps after modifying it) > > than to add yet another new one. The really-good-changelog should > > be compelling on this point, please. > > > > See, I (and I assume others) are totally on first base here and we need > > to get through this before we can get onto zswap. Sorry. > > drivers/staging is where code goes to be ignored :( > > I've noticed :-/ > > Thank you very much for your review! I'll work with Nitin and Minchan > to beef up the documentation so that the answers to your questions are > more readily apparent in the code/comments. Actually, Kconfig of USE_PGTABLE_MAPPING is my plan. Will do it if anyone has no objection. -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 2/4] block: add runtime pm helpers
On Wed, Jan 30, 2013 at 10:54:53AM -0500, Alan Stern wrote:
> On Wed, 30 Jan 2013, Aaron Lu wrote:
>
> > From: Lin Ming
> >
> > Add runtime pm helper functions:
> >
> > void blk_pm_runtime_init(struct request_queue *q, struct device *dev)
> > - Initialization function for drivers to call.
> >
> > int blk_pre_runtime_suspend(struct request_queue *q)
> > - If any requests are in the queue, mark last busy and return -EBUSY.
> > Otherwise set q->rpm_status to RPM_SUSPENDING and return 0.
> >
> > void blk_post_runtime_suspend(struct request_queue *q, int err)
> > - If the suspend succeeded then set q->rpm_status to RPM_SUSPENDED.
> > Otherwise set it to RPM_ACTIVE.
> >
> > void blk_pre_runtime_resume(struct request_queue *q)
> > - Set q->rpm_status to RPM_RESUMING.
> >
> > void blk_post_runtime_resume(struct request_queue *q, int err)
> > - If the resume succeeded then set q->rpm_status to RPM_ACTIVE
> > and call __blk_run_queue, then mark last busy and autosuspend.
> > Otherwise set q->rpm_status to RPM_SUSPENDED.
> >
> > Signed-off-by: Lin Ming
> > Signed-off-by: Aaron Lu
>
> > +void blk_pm_runtime_init(struct request_queue *q, struct device *dev)
> > +{
> > + q->dev = dev;
> > + q->rpm_status = RPM_ACTIVE;
> > + pm_runtime_set_autosuspend_delay(q->dev, -1);
> > + pm_runtime_use_autosuspend(q->dev);
> > + pm_runtime_mark_last_busy(q->dev);
> > + pm_runtime_autosuspend(q->dev);
>
> This last line is no longer needed. It can't do anything useful, since
> autosuspends are disabled (the delay is -1).
Right, thanks.
And the mark_last_busy can probably be removed too, it didn't make much
sense here and we can add "driver should call pm_runtime_mark_last_busy
and pm_runtime_autosuspend in its runtime idle callback" to the kernel
doc. What do you think?
Thanks,
Aaron
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: zsmalloc: remove unused pool name
On Wed, Jan 30, 2013 at 12:29:57PM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 30, 2013 at 06:21:59PM +0100, Greg Kroah-Hartman wrote:
> > On Wed, Jan 30, 2013 at 09:41:55AM -0600, Seth Jennings wrote:
> > > On 01/30/2013 09:36 AM, Seth Jennings wrote:> zs_create_pool()
> > > currently takes a name argument which is
> > > > never used in any useful way.
> > > >
> > > > This patch removes it.
> > > >
> > > > Signed-off-by: Seth Jennings
> > >
> > > Crud, forgot the Acks...
> > >
> > > Acked-by: Nitin Gupta
> > > Acked-by: Rik van Riel
> >
> > {sigh} you just made me have to edit your patch by hand, you now owe me
> > a beer...
> >
> Should we codify that :-)
>
>
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index c379a2a..f879c60 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -94,6 +94,7 @@ includes updates for subsystem X. Please apply."
> The maintainer will thank you if you write your patch description in a
> form which can be easily pulled into Linux's source code management
> system, git, as a "commit log". See #15, below.
> +If the maintainer has to hand-edit your patch, you owe them a beer.
>
> If your description starts to get long, that's a sign that you probably
> need to split up your patch. See #3, next.
Yes we do need to codify this, but let's be fair, not everyone likes
beer:
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index c379a2a..d1bec01 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -93,7 +93,9 @@ includes updates for subsystem X. Please apply."
The maintainer will thank you if you write your patch description in a
form which can be easily pulled into Linux's source code management
-system, git, as a "commit log". See #15, below.
+system, git, as a "commit log". See #15, below. If the maintainer has
+to hand-edit your patch, you owe them the beverage of their choice the
+next time you see them.
If your description starts to get long, that's a sign that you probably
need to split up your patch. See #3, next.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Wed, Jan 30, 2013 at 06:15:12PM -0700, Toshi Kani wrote: > > Please make it a "real" pointer, and not a void *, those shouldn't be > > used at all if possible. > > How about changing the "void *handle" to acpi_dev_node below? > >struct acpi_dev_nodeacpi_node; > > Basically, it has the same challenge as struct device, which uses > acpi_dev_node as well. We can add other FW node when needed (just like > device also has *of_node). That sounds good to me. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 1/9] staging: zsmalloc: add gfp flags to zs_create_pool
On Wed, Jan 30, 2013 at 11:11:47AM -0500, Konrad Rzeszutek Wilk wrote: > On Mon, Jan 28, 2013 at 11:59:17AM +0900, Minchan Kim wrote: > > On Fri, Jan 25, 2013 at 07:56:29AM -0800, Dan Magenheimer wrote: > > > > From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] > > > > Subject: Re: [PATCHv2 1/9] staging: zsmalloc: add gfp flags to > > > > zs_create_pool > > > > > > > > On 01/24/2013 07:33 PM, Minchan Kim wrote: > > > > > Hi Seth, frontswap guys > > > > > > > > > > On Tue, Jan 8, 2013 at 5:24 AM, Seth Jennings > > > > > wrote: > > > > >> zs_create_pool() currently takes a gfp flags argument > > > > >> that is used when growing the memory pool. However > > > > >> it is not used in allocating the metadata for the pool > > > > >> itself. That is currently hardcoded to GFP_KERNEL. > > > > >> > > > > >> zswap calls zs_create_pool() at swapon time which is done > > > > >> in atomic context, resulting in a "might sleep" warning. > > > > > > > > > > I didn't review this all series, really sorry but totday I saw Nitin > > > > > added Acked-by so I'm afraid Greg might get it under my radar. I'm not > > > > > strong against but I would like know why we should call frontswap_init > > > > > under swap_lock? Is there special reason? > > > > > > > > The call stack is: > > > > > > > > SYSCALL_DEFINE2(swapon.. <-- swapon_mutex taken here > > > > enable_swap_info() <-- swap_lock taken here > > > > frontswap_init() > > > > __frontswap_init() > > > > zswap_frontswap_init() > > > > zs_create_pool() > > > > > > > > It isn't entirely clear to me why frontswap_init() is called under > > > > lock. Then again, I'm not entirely sure what the swap_lock protects. > > > > There are no comments near the swap_lock definition to tell me. > > > > > > > > I would guess that the intent is to block any writes to the swap > > > > device until frontswap_init() has completed. > > > > > > > > Dan care to weigh in? > > > > > > I think frontswap's first appearance needs to be atomic, i.e. > > > the transition from (a) frontswap is not present and will fail > > > all calls, to (b) frontswap is fully functional... that transition > > > must be atomic. And, once Konrad's module patches are in, the > > To be fair it can be "delayed". Say the swap disk is in heavy usage and > the backend is registered. The time between the backend going online and > the frontswap_store functions calling in the backend can be delayed (so > we can use a racy unsigned long to check when the backend is on). > > Obviously the opposite is not acceptable (so unsigned long says > backend is enabled, but in reality the backend has not yet been > initialized). > > > > opposite transition must be atomic also. But there are most > > > likely other ways to do those transitions atomically that > > > don't need to hold swap_lock. > > Right. The opposite transition would be when a backend is unloaded. > Which is something we don't do yet. For that to work we would need > to make the "gatekeeper" (this unsigned long I've been referring to) > be atomic. Or at least in some fashion - either via spinlocks or perhaps > using static_key to patch the branching of the code. Naturally to > unload a module extra things such as flushing all the pages the backend > has to the disk is required. > > > > It could be raced once swap_info is registered. > > But what's the problem if we call frontswap_init before calling > > _enable_swap_info out of lock? > > So, we have two locks - the mutex and the spin_lock. I think we are > fine without the spinlock (swap_lock). > > > Swap subsystem never do I/O before it register new swap_info_struct. > > > > And IMHO, if frontswap is to be atomic, it would be better to have > > own scheme without dependency of swap_lock if it's possible. > > I think that can be independent of that lock. We are still under > the mutex (swapon_mutex) which protects us against two threads doing > swapon/swapoff and messing things up. > > > > > > Honestly, I never really focused on the initialization code > > > so I am very open to improvements as long as they work for > > > all the various frontswap backends. > > > > How about this? > > > > From 157a3edf49feb93be0595574beb153b322ddf7d2 Mon Sep 17 00:00:00 2001 > > From: Minchan Kim > > Date: Mon, 28 Jan 2013 11:34:00 +0900 > > Subject: [PATCH] frontswap: Get rid of swap_lock dependency > > > > Frontswap initialization routine depends on swap_lock, which want > > to be atomic about frontswap's first appearance. > > IOW, frontswap is not present and will fail all calls OR frontswap is > > fully functional but if new swap_info_struct isn't registered > > by enable_swap_info, swap subsystem doesn't start I/O so there is no race > > between init procedure and page I/O working on frontswap. > > > > So let's remove unncessary swap_lock dependency. > > This looks good. I hadn't yet had a chance to test it out though. I hope you pick up if it pass your test. Thanks, Konrad! -- Kind regards, Minchan Kim
Re: [RFC 1/2] cpuidle: trace state of the CPU
On Wed, 30 Jan 2013 22:19:16 +0100, Sebastian Andrzej Siewior wrote:
> This patch adds an interface to cpuidle in order to retrieve the current
> idle state of a given CPU. Zero means the CPU is not in an idle state. Either
> because a cpuidle driver is not available or because the CPU is busy
> executing code. Values greater than zero the CPU indicate that the CPU
> is in some kind of idle state. The larger the value, the deeper the idle
> state.
>
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> drivers/cpuidle/cpuidle.c | 13 -
> include/linux/cpuidle.h |2 ++
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> index e1f6860..3594e0c 100644
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -23,6 +23,7 @@
> #include "cpuidle.h"
>
> DEFINE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
> +static DEFINE_PER_CPU(unsigned int, cpu_state);
What about making it 'int' as cpuidle_get_state() returns int type?
>
> DEFINE_MUTEX(cpuidle_lock);
> LIST_HEAD(cpuidle_detected_devices);
> @@ -40,13 +41,23 @@ void disable_cpuidle(void)
> off = 1;
> }
>
> +int cpuidle_get_state(int cpu)
> +{
> + return per_cpu(cpu_state, cpu);
> +}
> +
> static int __cpuidle_register_device(struct cpuidle_device *dev);
>
> static inline int cpuidle_enter(struct cpuidle_device *dev,
> struct cpuidle_driver *drv, int index)
> {
> struct cpuidle_state *target_state = &drv->states[index];
> - return target_state->enter(dev, drv, index);
> + int ret;
> +
> + per_cpu(cpu_state, smp_processor_id()) = index + 1;
> + ret = target_state->enter(dev, drv, index);
> + per_cpu(cpu_state, smp_processor_id()) = 0;
Maybe we can use local variable 'cpu' for this duplicated
smp_processor_id() call as it's never executed on another cpu in
between?
Thanks,
Namhyung
> + return ret;
> }
>
> static inline int cpuidle_enter_tk(struct cpuidle_device *dev,
> diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
> index 24cd1037..256baeb 100644
> --- a/include/linux/cpuidle.h
> +++ b/include/linux/cpuidle.h
> @@ -155,6 +155,7 @@ extern int cpuidle_wrap_enter(struct cpuidle_device *dev,
> struct cpuidle_driver *drv, int index,
> int (*enter)(struct cpuidle_device *dev,
> struct cpuidle_driver *drv, int index));
> +extern int cpuidle_get_state(int cpu);
> extern int cpuidle_play_dead(void);
>
> extern struct cpuidle_driver *cpuidle_get_cpu_driver(struct cpuidle_device
> *dev);
> @@ -186,6 +187,7 @@ static inline int cpuidle_wrap_enter(struct
> cpuidle_device *dev,
> int (*enter)(struct cpuidle_device *dev,
> struct cpuidle_driver *drv, int index))
> { return -ENODEV; }
> +static inline int cpuidle_get_state(int cpu) {return 0; }
> static inline int cpuidle_play_dead(void) {return -ENODEV; }
> #endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 2/2] sched/fair: prefer a CPU in the "lowest" idle state
Hi Sebastian and Michael,
On Thu, 31 Jan 2013 10:12:35 +0800, Michael Wang wrote:
> On 01/31/2013 05:19 AM, Sebastian Andrzej Siewior wrote:
>> If a new CPU has to be choosen for a task, then the scheduler first selects
>> the group with the least load. This group is returned if its load is lower
>> compared to the group to which the task is currently assigned.
>> If there are several groups with completely idle CPU(s) (the CPU is in
>> an idle state like C1) then the first group is returned.
>> This patch extends this decision by considering the idle state of CPU(s)
>> in the group and the first group with a CPU in the lowest idle state
>> wins (C1 is prefered over C2). If there is a CPU which is not in an idle
>> state (C0) but has no tasks assigned then it is consider as a valid target.
>> Should there be no CPU in an idle state at disposal then the loadavg is
>> used as a fallback.
[snip]
>> @@ -3181,8 +3182,10 @@ find_idlest_group(struct sched_domain *sd, struct
>> task_struct *p,
>>int this_cpu, int load_idx)
>> {
>> struct sched_group *idlest = NULL, *group = sd->groups;
>> +struct sched_group *idle_group = NULL;
>> unsigned long min_load = ULONG_MAX, this_load = 0;
>> int imbalance = 100 + (sd->imbalance_pct-100)/2;
>> +int least_idle_cpu = INT_MAX;
>>
>> do {
>> unsigned long load, avg_load;
>> @@ -3208,6 +3211,25 @@ find_idlest_group(struct sched_domain *sd, struct
>> task_struct *p,
>> load = target_load(i, load_idx);
>>
>> avg_load += load;
>> +if (!local_group && sd->prefer_lp && least_idle_cpu) {
>> +int idle_level;
>> +
>> +idle_level = cpuidle_get_state(i);
>> +/*
>> + * Select the CPU which is in the lowest
>> + * possible power state. Take the active
>> + * CPU only if its run queue is empty.
>> + */
>> +if (!idle_level) {
>> +if (idle_cpu(i)) {
>> +least_idle_cpu = idle_level;
>> +idle_group = group;
>> +}
>> +} else if (least_idle_cpu > idle_level) {
>> +least_idle_cpu = idle_level;
>> +idle_group = group;
>> +}
>> +}
>> }
>>
>> /* Adjust by relative CPU power of the group */
>> @@ -3221,6 +3243,8 @@ find_idlest_group(struct sched_domain *sd, struct
>> task_struct *p,
>> }
>> } while (group = group->next, group != sd->groups);
>>
>> +if (idle_group)
>> +return idle_group;
>
> I'm not sure, but just concern about this case:
>
> group 0 cpu 0 cpu 1
> least idle 4 task
>
> group 1 cpu 2 cpu 3
> 1 task 1 task
>
> The previous logical will pick group 1 and now it will take group 0, and
> that cause more imbalance, doesn't it?
>
> May be check that state in find_idlest_cpu() will be better?
Right, at least find_idlest_cpu() should also check the idle_level IMHO.
Anyway, I have an idea with this in mind. It's like adding a new "idle
load" to each idle cpu rather than special casing the idle cpus like
above. IOW an idle cpu will get very small load weight depends on how
deep it's slept so that it can be compared to other cpus in a same way
but we can find prefered (lowest load) cpu among the idle cpus.
The simple way I can think of is adding idle_level to a rq load in
weighted_cpuload():
static unsigned long weighted_cpuload(const int cpu)
{
return cpu_rq(cpu)->load.weight + cpuidle_get_state(cpu);
}
What do you think?
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Bug#695182: [RFC] Reproducible OOM with just a few sleeps
On Thu, 2013-01-31 at 06:40 +1100, paul.sz...@sydney.edu.au wrote: > Dear Pavel and Dave, > > > The assertion was that 4GB with no PAE passed a forkbomb test (ooming) > > while 4GB of RAM with PAE hung, thus _PAE_ is broken. > > Yes, PAE is broken. Still, maybe the above needs slight correction: > non-PAE HIGHMEM4G passed the "sleep test": no OOM, nothing unexpected; > whereas PAE OOMed then hung (tested with various RAM from 3GB to 64GB). > > The feeling I get is that amd64 is proposed as a drop-in replacement for > PAE, that support and development of PAE is gone, that PAE is dead. PAE was a stop-gap that kept x86-32 alive on servers until x86-64 came along (though it was supposed to be ia64...). That's why I was surprised you were still trying to run a 32-bit kernel. The fundamental problem with Linux on 32-bit systems for the past ~10 years has been that RAM sizes approached and exceeded the 32-bit virtual address space and the kernel can't keep it all mapped. Whenever a task makes a system call the kernel will continue to use the same virtual memory mappings to access that task's memory, as well as its own memory. Which means both of those have to fit within the virtual address space. (The alternative of using separate address spaces is pretty bad for performance - see OS X as an example. And it only helps you as far as 4GB RAM.) The usual split on 32-bit machines is 3GB virtual address space for each task and 1GB for the kernel. Part of that 1GB is reserved for memory- mapped I/O and temporary mappings, and the rest is mapped to the beginning of RAM (lowmem). All the remainder of RAM is highmem, available for allocation by tasks but not for the kernel's private data (in general). Switching to PAE does not change the amount of lowmem, but it does make hardware page table entries (which of course live in lowmem) twice as big. This increases the pressure on lowmem a little, which probably explains the negative result of your 'sleep test'. However if you then try to take full advantage of the 64GB range of PAE, as you saw earlier, the shortage of lowmem relative to highmem becomes completely untenable. Ben. -- Ben Hutchings If more than one person is responsible for a bug, no one is at fault. signature.asc Description: This is a digitally signed message part
Re: [RFC PATCH 0/4] SUNRPC: rework cache upcall to avoid NFSd root swapping
31.01.2013 03:00, J. Bruce Fields пишет: On Tue, Jan 15, 2013 at 11:09:23AM +0300, Stanislav Kinsbursky wrote: The main idea of this patch set is to call cache request not on kthread upcall, but on userspace daemon cache_read call. This fixes the problem with gaining of wrong dentry path after calling d_path() in kthread root context (svc_export_request() callback), which always work in init root context, but containers can work in "root jail" - i.e. have it's own nested root. Sorry for the delay. This looks good to me--committing pending some testing. What's left now for basic containerized nfsd support? Sure, thanks! Not that many patches left: NFSd fs per-net (to get the proper context from the superblock), disabling UMH tracker for a while (again selecting proper root issue) and removing of error patch for state tracker in current net != &init_net. They are simple so I'm going to re-send them soon. Just wanna work a bit more on per-net service shutdown first since it looks more urgent. -- Best regards, Stanislav Kinsbursky -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv5] tty: Added a CONFIG_TTY option to allow removal of TTY
On Wed, Jan 30, 2013 at 05:15:19PM -0800, Joe Millenbach wrote: > The option allows you to remove TTY and compile without errors. This > saves space on systems that won't support TTY interfaces anyway. > bloat-o-meter output is below. > > The bulk of this patch consists of Kconfig changes adding "depends on > TTY" to various serial devices and similar drivers that require the TTY > layer. Ideally, these dependencies would occur on a common intermediate > symbol, but many drivers select rather than depend on features, and > "select" does not respect dependencies. > > bloat-o-meter output filtered to not show removed entries to save space > > $ scripts/bloat-o-meter min min-no-tty | awk '$3 != "-"' > add/remove: 0/225 grow/shrink: 2/12 up/down: 8/-29628 (-29620) > function old new delta > chr_dev_init 138 145 +7 > linux_banner 123 124 +1 > static.__warned 132 131 -1 > unregister_console 106 101 -5 > start_kernel 467 462 -5 > register_console 545 540 -5 > copy_from_user40 35 -5 > sys_setsid 105 98 -7 > sys_vhangup 27 15 -12 > do_exit 13631346 -17 > arch_local_irq_save 136 116 -20 > bitmap_zero 44 22 -22 > release_task 587 562 -25 > static.spin_unlock_irqrestore223 187 -36 > > Signed-off-by: Joe Millenbach > Reviewed-by: Josh Triplett > Reviewed-by: Jamey Sharp > --- > v5: Rebasing to 3.8 rc5 and minimized driver/input changes based on input > from Dmitry Torokhov. This isn't going to work because I've already applied this to my tree. Can you just make a tiny patch against the tty-next git tree to fix up the differences here for the Input drivers and I can apply that? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Questin about swap_slot free and invalidate page
When I reviewed zswap, I was curious about frontswap_store.
It said following as.
* If frontswap already contains a page with matching swaptype and
* offset, the frontswap implementation may either overwrite the data and
* return success or invalidate the page from frontswap and return failure.
It didn't say why it happens. we already have __frontswap_invalidate_page
and call it whenever swap_slot frees. If we don't free swap slot,
scan_swap_map can't find the slot for swap out so I thought overwriting of
data shouldn't happen in frontswap.
As I looked the code, the curplit is reuse_swap_page. It couldn't free swap
slot if the page founded is PG_writeback but miss calling
frontswap_invalidate_page
so data overwriting on frontswap can happen. I'm not sure frontswap guys
already discussed it long time ago.
If we can fix it, we can remove duplication entry handling logic
in all of backend of frontswap. All of backend should handle it although
it's pretty rare. Of course, zram could be fixed. It might be trivial now
but more there are many backend of frontswap, more it would be a headache.
If we are trying to fix it in swap layer, we might fix it following as
int reuse_swap_page(struct page *page)
{
..
..
if (count == 1) {
if (!PageWriteback(page)) {
delete_from_swap_cache(page);
SetPageDirty(page);
} else {
frontswap_invalidate_page();
swap_slot_free_notify();
}
}
}
But not sure, it is worth at the moment and there might be other places
to be fixed.(I hope Hugh can point out if we are missing something if he
has a time)
If we are reluctant to it, at least, we should write out comment above
frontswap_store about that to notice curious guys who spend many
time to know WHY and smart guys who are going to fix it with nice way.
Mr. Frontswap, What do you think about it?
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v4 5/8] MFD: ti_am335x_tscadc: Add DT support
On Thu, Jan 31, 2013 at 09:41:11, Patil, Rachna wrote:
> On Wed, Jan 30, 2013 at 16:10:09, Koen Kooi wrote:
> >
> > Op 24 jan. 2013, om 04:45 heeft "Patil, Rachna" het
> > volgende geschreven:
> >
> > > From: "Patil, Rachna"
> > >
> > > Make changes to add DT support in the MFD core driver.
> > >
> > > Signed-off-by: Patil, Rachna
> > > ---
> > > Changes in v4:
> > > Non-standard properties prefixed with vendor name.
> > >
> > > drivers/mfd/ti_am335x_tscadc.c | 28 +++-
> > > 1 file changed, 23 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/mfd/ti_am335x_tscadc.c
> > > b/drivers/mfd/ti_am335x_tscadc.c index e9f3fb5..87b446b 100644
> > > --- a/drivers/mfd/ti_am335x_tscadc.c
> > > +++ b/drivers/mfd/ti_am335x_tscadc.c
> > > @@ -22,6 +22,8 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > +#include
> > >
> > > #include #include
> > >
> > > @@ -64,20 +66,31 @@ staticint ti_tscadc_probe(struct
> > > platform_device *pdev)
> > > struct resource *res;
> > > struct clk *clk;
> > > struct mfd_tscadc_board *pdata = pdev->dev.platform_data;
> > > + struct device_node *node = pdev->dev.of_node;
> > > struct mfd_cell *cell;
> > > int err, ctrl;
> > > int clk_value, clock_rate;
> > > - int tsc_wires, adc_channels = 0, total_channels;
> > > + int tsc_wires = 0, adc_channels = 0, total_channels;
> > >
> > > - if (!pdata) {
> > > + if (!pdata && !pdev->dev.of_node) {
> > > dev_err(&pdev->dev, "Could not find platform data\n");
> > > return -EINVAL;
> > > }
> > >
> > > - if (pdata->adc_init)
> > > - adc_channels = pdata->adc_init->adc_channels;
> > > + if (pdev->dev.platform_data) {
> > > + if (pdata->tsc_init)
> > > + tsc_wires = pdata->tsc_init->wires;
> > > +
> > > + if (pdata->adc_init)
> > > + adc_channels = pdata->adc_init->adc_channels;
> > > + } else {
> > > + node = of_find_node_by_name(pdev->dev.of_node, "tsc");
> > > + of_property_read_u32(node, "ti,wires", &tsc_wires);
> > > +
> > > + node = of_find_node_by_name(pdev->dev.of_node, "adc");
> > > + of_property_read_u32(node, "ti,adc-channels", &adc_channels);
> > > + }
> >
> > Since AM335x is DT only, why is there a platform data codepath and why is
> > it the first branch it tries? And I guess the next question is related to
> > the first: why doesn't it work when used with DT? When I copy over the
> > nodes from the evm.dts to my board I get "tsc tsc: Missing platform data"
> > in dmesg.
>
> This IP came up 1st on AM335x, but it is not platform dependent. The driver
> can be used on other platforms where-in DT is not supported.
> According to the maintainers platform data takes precedence over DT. Hence
> the order.
>
Rachana,
I see no point adding support for platform_data when you know that none of
older platforms are going to use this driver and all future platforms _must_
follow device-tree model.
So I agree that you should remove board file dependency from the driver.
> I do not see "Missing platform data" error msg in the latest driver. I am not
> able to trace from where this got populated.
>
Can you share the branch which you have tested?
Thanks,
Vaibhav
> >
> > What are the chances this driver will work when applied on top of 3.8-rcX?
> > Has it even been tested with that? Has it been tested at all?
>
> This driver has been tested on top of v3.8-rc3 on a AM335x EVM.
>
> Regards,
> Rachna
>
> ___
> devicetree-discuss mailing list
> devicetree-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V2] suspend: enable freeze timeout configuration through sys
Hello Rafael,
I update it as below in V3, do you think it makes sense?
At present, the value of timeout for freezing is 20s, which is
meaningless in case that one thread is frozen with mutex locked
and another thread is trying to lock the mutex, as this time of
freezing will fail unavoidably.
And if there is no new wakeup event registered, the system will
waste at most 20s for such meaningless trying of freezing.
With this patch, the value of timeout can be configured to smaller
value, so such meaningless trying of freezing will be aborted in
earlier time, and later freezing can be also triggered in earlier
time. And more power will be saved.
In normal case on mobile phone, it costs real little time to freeze
processes. On some platform, it only costs about 20ms to freeze
user space processes and 10ms to freeze kernel freezable threads.
Thanks a lot!
Best Regards,
Li Fei
TEL: +86 (0)21 6116 5140
Mob: +86 (0)139 1696 7435
Platform System Integration Shanghai
> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> Sent: Wednesday, January 30, 2013 9:10 PM
> To: Li, Fei
> Cc: a...@linux-foundation.org; linux-kernel@vger.kernel.org;
> linux...@vger.kernel.org; Liu, Chuansheng
> Subject: Re: [PATCH V2] suspend: enable freeze timeout configuration through
> sys
>
> On Wednesday, January 30, 2013 02:23:39 PM fli24 wrote:
> >
> > At present, the timeout value for freezing tasks is fixed as 20s,
> > which is too long for handheld device usage, especially for mobile
> > phone.
> >
> > In order to improve user experience, we enable freeze timeout
> > configuration through sys, so that we can tune the value easily
> > for concrete usage, such as smaller value for handheld device such
> > as mobile phone.
>
> As I said, I'd like to know what's the exact problem you need to work around
> using this.
>
> Thanks,
> Rafael
>
>
> > Signed-off-by: Liu Chuansheng
> > Signed-off-by: Li Fei
> > ---
> > Documentation/power/freezing-of-tasks.txt |5 +
> > include/linux/freezer.h |5 +
> > kernel/power/main.c | 27
> +++
> > kernel/power/process.c|4 ++--
> > 4 files changed, 39 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/power/freezing-of-tasks.txt
> b/Documentation/power/freezing-of-tasks.txt
> > index 6ec291e..85894d8 100644
> > --- a/Documentation/power/freezing-of-tasks.txt
> > +++ b/Documentation/power/freezing-of-tasks.txt
> > @@ -223,3 +223,8 @@ since they ask the freezer to skip freezing this task,
> since it is anyway
> > only after the entire suspend/hibernation sequence is complete.
> > So, to summarize, use [un]lock_system_sleep() instead of directly using
> > mutex_[un]lock(&pm_mutex). That would prevent freezing failures.
> > +
> > +V. Miscellaneous
> > +/sys/power/pm_freeze_timeout controls how long it will cost at most to
> freeze
> > +all user space processes or all freezable kernel threads, in unit of
> > millisecond.
> > +The default value is 2, with range of unsigned integer.
> > diff --git a/include/linux/freezer.h b/include/linux/freezer.h
> > index e4238ce..5a24a33 100644
> > --- a/include/linux/freezer.h
> > +++ b/include/linux/freezer.h
> > @@ -13,6 +13,11 @@ extern bool pm_freezing; /* PM freezing in effect
> */
> > extern bool pm_nosig_freezing; /* PM nosig freezing in effect
> > */
> >
> > /*
> > + * Timeout for stopping processes
> > + */
> > +extern unsigned int sys_freeze_process_timeout_msecs;
> > +
> > +/*
> > * Check if a process has been frozen
> > */
> > static inline bool frozen(struct task_struct *p)
> > diff --git a/kernel/power/main.c b/kernel/power/main.c
> > index 1c16f91..453ead1 100644
> > --- a/kernel/power/main.c
> > +++ b/kernel/power/main.c
> > @@ -553,6 +553,30 @@ power_attr(pm_trace_dev_match);
> >
> > #endif /* CONFIG_PM_TRACE */
> >
> > +#ifdef CONFIG_FREEZER
> > +static ssize_t pm_freeze_timeout_show(struct kobject *kobj,
> > + struct kobj_attribute *attr, char *buf)
> > +{
> > + return sprintf(buf, "%u\n", sys_freeze_process_timeout_msecs);
> > +}
> > +
> > +static ssize_t pm_freeze_timeout_store(struct kobject *kobj,
> > + struct kobj_attribute *attr,
> > + const char *buf, size_t n)
> > +{
> > + unsigned long val;
> > +
> > + if (kstrtoul(buf, 10, &val))
> > + return -EINVAL;
> > +
> > + sys_freeze_process_timeout_msecs = val;
> > + return n;
> > +}
> > +
> > +power_attr(pm_freeze_timeout);
> > +
> > +#endif /* CONFIG_FREEZER*/
> > +
> > static struct attribute * g[] = {
> > &state_attr.attr,
> > #ifdef CONFIG_PM_TRACE
> > @@ -576,6 +600,9 @@ static struct attribute * g[] = {
> > &pm_print_times_attr.attr,
> > #endif
> > #endif
> > +#ifdef CONFIG_FREEZER
> > + &pm_freeze_timeout_attr.attr,
> > +#endif
> > NULL,
> > };
> >
> > diff --gi
[PATCH V3] suspend: enable freeze timeout configuration through sys
At present, the value of timeout for freezing is 20s, which is
meaningless in case that one thread is frozen with mutex locked
and another thread is trying to lock the mutex, as this time of
freezing will fail unavoidably.
And if there is no new wakeup event registered, the system will
waste at most 20s for such meaningless trying of freezing.
With this patch, the value of timeout can be configured to smaller
value, so such meaningless trying of freezing will be aborted in
earlier time, and later freezing can be also triggered in earlier
time. And more power will be saved.
In normal case on mobile phone, it costs real little time to freeze
processes. On some platform, it only costs about 20ms to freeze
user space processes and 10ms to freeze kernel freezable threads.
Signed-off-by: Liu Chuansheng
Signed-off-by: Li Fei
---
Documentation/power/freezing-of-tasks.txt |5 +
include/linux/freezer.h |5 +
kernel/power/main.c | 27 +++
kernel/power/process.c|4 ++--
4 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/Documentation/power/freezing-of-tasks.txt
b/Documentation/power/freezing-of-tasks.txt
index 6ec291e..85894d8 100644
--- a/Documentation/power/freezing-of-tasks.txt
+++ b/Documentation/power/freezing-of-tasks.txt
@@ -223,3 +223,8 @@ since they ask the freezer to skip freezing this task,
since it is anyway
only after the entire suspend/hibernation sequence is complete.
So, to summarize, use [un]lock_system_sleep() instead of directly using
mutex_[un]lock(&pm_mutex). That would prevent freezing failures.
+
+V. Miscellaneous
+/sys/power/pm_freeze_timeout controls how long it will cost at most to freeze
+all user space processes or all freezable kernel threads, in unit of
millisecond.
+The default value is 2, with range of unsigned integer.
diff --git a/include/linux/freezer.h b/include/linux/freezer.h
index e4238ce..5a24a33 100644
--- a/include/linux/freezer.h
+++ b/include/linux/freezer.h
@@ -13,6 +13,11 @@ extern bool pm_freezing; /* PM freezing in
effect */
extern bool pm_nosig_freezing; /* PM nosig freezing in effect */
/*
+ * Timeout for stopping processes
+ */
+extern unsigned int sys_freeze_process_timeout_msecs;
+
+/*
* Check if a process has been frozen
*/
static inline bool frozen(struct task_struct *p)
diff --git a/kernel/power/main.c b/kernel/power/main.c
index 1c16f91..453ead1 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -553,6 +553,30 @@ power_attr(pm_trace_dev_match);
#endif /* CONFIG_PM_TRACE */
+#ifdef CONFIG_FREEZER
+static ssize_t pm_freeze_timeout_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%u\n", sys_freeze_process_timeout_msecs);
+}
+
+static ssize_t pm_freeze_timeout_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buf, size_t n)
+{
+ unsigned long val;
+
+ if (kstrtoul(buf, 10, &val))
+ return -EINVAL;
+
+ sys_freeze_process_timeout_msecs = val;
+ return n;
+}
+
+power_attr(pm_freeze_timeout);
+
+#endif /* CONFIG_FREEZER*/
+
static struct attribute * g[] = {
&state_attr.attr,
#ifdef CONFIG_PM_TRACE
@@ -576,6 +600,9 @@ static struct attribute * g[] = {
&pm_print_times_attr.attr,
#endif
#endif
+#ifdef CONFIG_FREEZER
+ &pm_freeze_timeout_attr.attr,
+#endif
NULL,
};
diff --git a/kernel/power/process.c b/kernel/power/process.c
index d5a258b..ba45a26 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -21,7 +21,7 @@
/*
* Timeout for stopping processes
*/
-#define TIMEOUT(20 * HZ)
+unsigned int __read_mostly sys_freeze_process_timeout_msecs = 2;
static int try_to_freeze_tasks(bool user_only)
{
@@ -36,7 +36,7 @@ static int try_to_freeze_tasks(bool user_only)
do_gettimeofday(&start);
- end_time = jiffies + TIMEOUT;
+ end_time = jiffies + msecs_to_jiffies(sys_freeze_process_timeout_msecs);
if (!user_only)
freeze_workqueues_begin();
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] checkpatch: fix USLEEP_RANGE test
On Wed, 2013-01-30 at 11:15 -0800, Bruce Allan wrote:
> Do not test udelay() for a value less than 10usec when passed a variable
> instead of a hard-coded number;
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -3237,9 +3237,9 @@ sub process {
[]
> # prefer usleep_range over udelay
> - if ($line =~ /\budelay\s*\(\s*(\w+)\s*\)/) {
> + if ($line =~ /\budelay\s*\(\s*(\d+)\s*\)/) {
> # ignore udelay's < 10, however
> - if (! (($1 =~ /(\d+)/) && ($1 < 10)) ) {
> + if (! ($1 < 10) ) {
> CHK("USLEEP_RANGE",
> "usleep_range is preferred over udelay; see
> Documentation/timers/timers-howto.txt\n" . $line);
> }
Thanks Bruce.
Just a trivial comment:
Maybe this would be a little neater as
if ($line =~ \budelay\s*\(\s*(\d+)\s*\) &&
$1 >= 10) {
CHK(etc...)
}
No worries though.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
On 01/31/2013 12:24 PM, Alexandre Courbot wrote: > On Thu, Jan 31, 2013 at 12:51 PM, Mark Zhang wrote: >>> DDC access is a property of the display controller, not the panel >>> itself. The panel might be hooked up to a display controller's DDC/I2C >>> channel as the target, but it isn't the host/controller of the DDC/I2C >>> channel. As such, placing the nvidia,ddc property into the display >>> controller node makes sense. >>> >> >> Yes, DC triggers the DDC access and is the host of the DDC/I2C channel. >> So I think it's reasonable to put nvidia,ddc property into the display >> controller node. But the video mode info in EDID which be fetched via >> DDC is the property of the panel, so this info should be provided by >> panel driver. Actually display controller cares about the video modes, >> not the way to get these info. So I think it's better to do the whole >> work like this: >> >> 1) display controller relied on CDF to call "display_entity_get_modes" >> 2) panel driver calls the function which is hooked to display controller >> to get the video modes via DDC. >> 3) if the video modes can't be fetched via DDC, panel driver provides >> the info(either by hard-coded or defined in DT) anyway > > This would require a callback dedicated to this in display_entity and > would break its simple design. We just need to add a function pointer param which can be used by panel driver in "display_entity_get_modes", don't we? > >> Just like I said above, display controller should not query DDC >> directly. Since CDF already defines these for us, display controller >> should call CDF's functions, like: display_entity_get_modes, >> display_entity_get_size... I think this is the key difference I wanna >> talk about. And also in this way, display controller doesn't need to >> care about this 2 steps logics, just call "display_entity_get_modes" is OK. > > Well the fact is that it *is* the display controller that queries DDC > directly. The panel is just a bus here, and the EDID EEPROM could > perfectly work without it. If you model what you described with DT > nodes, I'm afraid you will end up with something both complex (with DC > node referencing panel node and back again for the EDID bus) and that > does not picture reality accurately. Display controller don't know whether the panel has EDID EEPROM but the panel driver knows. So why we need to make display controller queries EDID blindly? Since panel driver knows about all "video modes/panel size" stuffs, why not we let it handle all these things? > > Alex. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] regulators: anatop: add set_voltage_time_sel interface
On Wed, Jan 30, 2013 at 02:30:47PM -0700, Troy Kisky wrote:
> On 1/30/2013 3:37 PM, Anson Huang wrote:
> >some of anatop's regulators(vppcpu, vddpu and vddsoc) have
> >register settings about LDO's step time, which will impact
> >the LDO ramp up speed, need to use set_voltage_time_sel
> >interface to add necessary delay everytime LDOs' voltage
> >is increased.
> >
> >offset 0x170:
> >bit [24-25]: vddcpu
> >bit [26-27]: vddpu
> >bit [28-29]: vddsoc
> >
> >field definition:
> >0'b00: 64 cycles of 24M clock;
> >0'b01: 128 cycles of 24M clock;
> >0'b02: 256 cycles of 24M clock;
> >0'b03: 512 cycles of 24M clock;
> >
> >Signed-off-by: Anson Huang
> >---
> > drivers/regulator/anatop-regulator.c | 42
> > ++
> > 1 file changed, 42 insertions(+)
> >
> >diff --git a/drivers/regulator/anatop-regulator.c
> >b/drivers/regulator/anatop-regulator.c
> >index 8f39cac..a857b9c 100644
> >--- a/drivers/regulator/anatop-regulator.c
> >+++ b/drivers/regulator/anatop-regulator.c
> >@@ -31,12 +31,18 @@
> > #include
> > #include
> >+#define LDO_RAMP_UP_UNIT_IN_CYCLES 64 /* 64 cycles per step */
> >+#define LDO_RAMP_UP_FREQ_IN_MHZ 24 /* cycle based on 24M OSC */
> >+
> > struct anatop_regulator {
> > const char *name;
> > u32 control_reg;
> > struct regmap *anatop;
> > int vol_bit_shift;
> > int vol_bit_width;
> >+u32 delay_reg;
> >+int delay_bit_shift;
> >+int delay_bit_width;
> > int min_bit_val;
> > int min_voltage;
> > int max_voltage;
> >@@ -55,6 +61,33 @@ static int anatop_regmap_set_voltage_sel(struct
> >regulator_dev *reg,
> > return regulator_set_voltage_sel_regmap(reg, selector);
> > }
> >+static int anatop_regmap_set_voltage_time_sel(struct regulator_dev *reg,
> >+unsigned int old_sel,
> >+unsigned int new_sel)
> >+{
> >+struct anatop_regulator *anatop_reg = rdev_get_drvdata(reg);
> >+u32 val;
> >+int ret = 0;
> >+
> >+/* check whether need to care about LDO ramp up speed */
> >+if (anatop_reg->delay_reg) {
> >+/*
> >+ * the delay for LDO ramp up time is
> >+ * based on the register setting, we need
> >+ * to calculate how many steps LDO need to
> >+ * ramp up, and how much delay needed. (us)
> >+ */
> >+regmap_read(anatop_reg->anatop, anatop_reg->delay_reg, &val);
> >+val = (val >> anatop_reg->delay_bit_shift) &
> >+((1 << anatop_reg->delay_bit_width) - 1);
> >+ret = new_sel > old_sel ? (new_sel - old_sel) *
>
> The (new_sel > old_sel) could be part of the above if.
>
> if (anatop_reg->delay_reg && new_sel > old_sel)
[Anson Huang]Good point, accepted. Please help review my v3 patch,thanks!
>
> >+((LDO_RAMP_UP_UNIT_IN_CYCLES << val) /
> >+LDO_RAMP_UP_FREQ_IN_MHZ + 1) : 0;
> >+}
> >+
> >+return ret;
> >+}
> >+
> > static int anatop_regmap_get_voltage_sel(struct regulator_dev *reg)
> > {
> > struct anatop_regulator *anatop_reg = rdev_get_drvdata(reg);
> >@@ -67,6 +100,7 @@ static int anatop_regmap_get_voltage_sel(struct
> >regulator_dev *reg)
> > static struct regulator_ops anatop_rops = {
> > .set_voltage_sel = anatop_regmap_set_voltage_sel,
> >+.set_voltage_time_sel = anatop_regmap_set_voltage_time_sel,
> > .get_voltage_sel = anatop_regmap_get_voltage_sel,
> > .list_voltage = regulator_list_voltage_linear,
> > .map_voltage = regulator_map_voltage_linear,
> >@@ -143,6 +177,14 @@ static int anatop_regulator_probe(struct
> >platform_device *pdev)
> > goto anatop_probe_end;
> > }
> >+/* read LDO ramp up setting, only for core reg */
> >+of_property_read_u32(np, "anatop-delay-reg-offset",
> >+ &sreg->delay_reg);
> >+of_property_read_u32(np, "anatop-delay-bit-width",
> >+ &sreg->delay_bit_width);
> >+of_property_read_u32(np, "anatop-delay-bit-shift",
> >+ &sreg->delay_bit_shift);
> >+
> > rdesc->n_voltages = (sreg->max_voltage - sreg->min_voltage) / 25000 + 1
> > + sreg->min_bit_val;
> > rdesc->min_uV = sreg->min_voltage;
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpufreq: SPEAr: Notify all policy->cpus of frequency change
On 31 January 2013 10:23, Viresh Kumar wrote: > SPEAr cpufreq driver supports dual core Cortex-A9 SoC's, where cpus share > policy > structure. Whenever we update frequency of a cpu, we must notify all > policy->cpus. > > Signed-off-by: Viresh Kumar Find it attached too. 0001-cpufreq-SPEAr-Notify-all-policy-cpus-of-frequency-ch.patch Description: Binary data
[PATCH] cpufreq: SPEAr: Notify all policy->cpus of frequency change
SPEAr cpufreq driver supports dual core Cortex-A9 SoC's, where cpus share policy structure. Whenever we update frequency of a cpu, we must notify all policy->cpus. Signed-off-by: Viresh Kumar --- drivers/cpufreq/spear-cpufreq.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/cpufreq/spear-cpufreq.c b/drivers/cpufreq/spear-cpufreq.c index 4575cfe..63c6a7f 100644 --- a/drivers/cpufreq/spear-cpufreq.c +++ b/drivers/cpufreq/spear-cpufreq.c @@ -157,7 +157,9 @@ static int spear_cpufreq_target(struct cpufreq_policy *policy, freqs.new = newfreq / 1000; freqs.new /= mult; - cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE); + + for_each_cpu(freqs.cpu, policy->cpus) + cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE); if (mult == 2) ret = spear1340_set_cpu_rate(srcclk, newfreq); @@ -170,7 +172,8 @@ static int spear_cpufreq_target(struct cpufreq_policy *policy, freqs.new = clk_get_rate(spear_cpufreq.clk) / 1000; } - cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE); + for_each_cpu(freqs.cpu, policy->cpus) + cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE); return ret; } -- 1.7.12.rc2.18.g61b472e -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpufreq: exynos: simplify .init() for setting policy->cpus
On 31 January 2013 10:22, Viresh Kumar wrote: > With the recent changes in cpufreq core, we just need to set mask of all > possible cpus into policy->cpus. Rest would be done by core. > > Signed-off-by: Viresh Kumar Oops! Sent the wrong patch again. Ignore this mail :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 9/9] devcg: propagate local changes down the hierarchy
Quoting a...@redhat.com (a...@redhat.com):
...
> New exceptions allowing additional access to devices won't be propagated, but
> it'll be possible to add an exception to access all of part of the newly
> allowed device(s).
Is that intended to apply only to only in the DEFAULT_DENY case? If so
that should be made clear. If not,
...
> @@ -515,11 +673,13 @@ memset(&ex, 0, sizeof(ex));
>&parent->exceptions);
> devcgroup->behavior = DEVCG_DEFAULT_ALLOW;
> devcgroup->local.behavior = DEVCG_DEFAULT_ALLOW;
> + rc = propagate_behavior(devcgroup);
> break;
> case DEVCG_DENY:
> dev_exception_clean_all(devcgroup);
> devcgroup->behavior = DEVCG_DEFAULT_DENY;
> devcgroup->local.behavior = DEVCG_DEFAULT_DENY;
> + rc = propagate_behavior(devcgroup);
> break;
> default:
> rc = -EINVAL;
> @@ -610,9 +770,14 @@ case '\0':
>*/
> if (devcgroup->behavior == DEVCG_DEFAULT_ALLOW) {
> dev_exception_rm(devcgroup, &ex);
> - return 0;
> + rc = propagate_exception(devcgroup);
Let's say the default in both parent A and child B is ALLOW, and both
have a blacklist entry for "b 8:* rwm". Now I
echo "b 8:* rwm" > A/devices.allow
removing the blacklist entry. Here you are propagating that to the
child B, which I would argue is actually propagating a new allow to
a child. Which you said you wouldn't do.
> + return rc;
> }
> - return dev_exception_add(devcgroup, &ex);
> + rc = dev_exception_add(devcgroup, &ex);
> + if (!rc)
> + /* if a local behavior wasn't explicitely choosen, pick
> it */
> + devcgroup->local.behavior = devcgroup->behavior;
> + break;
> case DEVCG_DENY:
> /*
>* If the default policy is to deny by default, try to remove
> @@ -621,13 +786,22 @@ return 0;
>*/
> if (devcgroup->behavior == DEVCG_DEFAULT_DENY) {
> dev_exception_rm(devcgroup, &ex);
> - return 0;
> + rc = propagate_exception(devcgroup);
> + return rc;
> }
> - return dev_exception_add(devcgroup, &ex);
> + rc = dev_exception_add(devcgroup, &ex);
> + if (rc)
> + return rc;
> + /* we only propagate new restrictions */
> + rc = propagate_exception(devcgroup);
> + if (!rc)
> + /* if a local behavior wasn't explicitely choosen, pick
> it */
> + devcgroup->local.behavior = devcgroup->behavior;
> + break;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Extend interfaces to access PCIe capabilities registers
On Fri, Jan 25, 2013 at 5:55 PM, Myron Stowe wrote: > This series is a minor extension to Jiang Liu's recent efforts - [PATCH v3 > 00/32] provide interfaces to access PCIe capabilities registers - which > adds an additional PCI Express accessor for obtaining a device's > Capabilities Register. > > Reference: https://lkml.org/lkml/2012/8/1/253 > --- > > Myron Stowe (2): > PCI: Use PCI Express Capability accessors > PCI: introduce accessor to retrieve PCIe Capabilities Register > > > drivers/pci/access.c|4 ++-- > drivers/pci/pcie/portdrv_core.c |2 +- > include/linux/pci.h | 11 ++- > 3 files changed, 13 insertions(+), 4 deletions(-) I applied these to pci/misc for v3.9. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] mm: accelerate mm_populate() treatment of THP pages
On Wed, Jan 30, 2013 at 7:05 PM, Hugh Dickins wrote: > On Wed, 30 Jan 2013, Michel Lespinasse wrote: > >> This change adds a page_mask argument to follow_page. >> >> follow_page sets *page_mask to HPAGE_PMD_NR - 1 when it encounters a THP >> page, >> and to 0 in other cases. >> >> __get_user_pages() makes use of this in order to accelerate populating >> THP ranges - that is, when both the pages and vmas arrays are NULL, >> we don't need to iterate HPAGE_PMD_NR times to cover a single THP page >> (and we also avoid taking mm->page_table_lock that many times). >> >> Other follow_page() call sites can safely ignore the value returned in >> *page_mask. >> >> Signed-off-by: Michel Lespinasse > > I certainly like the skipping. > > And (b) why can't we just omit the additional arg, and get it from the > page found? You've explained the unreliability of the !FOLL_GET case > to me privately, but that needs to be spelt out in the commit comment > (and I'd love if we found a counter-argument, the extra arg of interest > to almost no-one does irritate me). Right. My understanding is that after calling follow_page() without the FOLL_GET flag, you really can't do much with the returned page pointer other than checking it for IS_ERR(). We don't get a reference to the page, so it could get migrated away as soon as follow_page() releases the page table lock. In the most extreme case, the memory corresponding to that page could get offlined / dereferencing the page pointer could fail. I actually think the follow_page API is very error prone in this way, as the returned page pointer is very tempting to use, but can't be safely used. I almost wish we could return something like ERR_PTR(-ESTALE) or whatever, just to make remove any temptations of dereferencing that page pointer. Now I agree the extra argument isn't pretty, but I don't have any better ideas for communicating the size of the page that got touched. > But (a) if the additional arg has to exist, then I'd much prefer it > to be page_size than page_mask - I realize there's a tiny advantage to > subtracting 1 from an immediate than from a variable, but I don't think > it justifies the peculiar interface. mask makes people think of masking. Yes, I started with a page_size in bytes and then I moved to the page_mask. I agree the performance advantage is tiny, and I don't mind switching back to bytes if people are happier with it. I think one benefit of the page_mask implementation might be that it's easier for people to see that page_increment will end up in the [1..HPAGE_PMD_NR] range. Would a page size in 4k page units work out ? (I'm just not sure how to call such a quantity, though). -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
On Thu, Jan 31, 2013 at 12:51 PM, Mark Zhang wrote: >> DDC access is a property of the display controller, not the panel >> itself. The panel might be hooked up to a display controller's DDC/I2C >> channel as the target, but it isn't the host/controller of the DDC/I2C >> channel. As such, placing the nvidia,ddc property into the display >> controller node makes sense. >> > > Yes, DC triggers the DDC access and is the host of the DDC/I2C channel. > So I think it's reasonable to put nvidia,ddc property into the display > controller node. But the video mode info in EDID which be fetched via > DDC is the property of the panel, so this info should be provided by > panel driver. Actually display controller cares about the video modes, > not the way to get these info. So I think it's better to do the whole > work like this: > > 1) display controller relied on CDF to call "display_entity_get_modes" > 2) panel driver calls the function which is hooked to display controller > to get the video modes via DDC. > 3) if the video modes can't be fetched via DDC, panel driver provides > the info(either by hard-coded or defined in DT) anyway This would require a callback dedicated to this in display_entity and would break its simple design. > Just like I said above, display controller should not query DDC > directly. Since CDF already defines these for us, display controller > should call CDF's functions, like: display_entity_get_modes, > display_entity_get_size... I think this is the key difference I wanna > talk about. And also in this way, display controller doesn't need to > care about this 2 steps logics, just call "display_entity_get_modes" is OK. Well the fact is that it *is* the display controller that queries DDC directly. The panel is just a bus here, and the EDID EEPROM could perfectly work without it. If you model what you described with DT nodes, I'm afraid you will end up with something both complex (with DC node referencing panel node and back again for the EDID bus) and that does not picture reality accurately. Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 9/9] devcg: propagate local changes down the hierarchy
Quoting a...@redhat.com (a...@redhat.com):
> +/**
> + * propagate_behavior - propagates a change in the behavior down in hierarchy
> + * @devcg_root: device cgroup that changed behavior
> + *
> + * returns: 0 in case of success, != 0 in case of error
> + *
> + * This is one of the two key functions for hierarchy implementation.
> + * All cgroup's children recursively will have the behavior changed and
> + * exceptions copied from the parent then its local behavior and exceptions
> + * re-evaluated and applied if they're still allowed. Refer to
> + * Documentation/cgroups/devices.txt for more details.
> + */
> +static int propagate_behavior(struct dev_cgroup *devcg_root)
> +{
> + struct cgroup *root = devcg_root->css.cgroup;
> + struct dev_cgroup *parent, *devcg, *tmp;
> + int rc = 0;
> + LIST_HEAD(pending);
> +
> + get_online_devcg(root, &pending);
> +
> + list_for_each_entry_safe(devcg, tmp, &pending, propagate_pending) {
> + parent = cgroup_to_devcgroup(devcg->css.cgroup->parent);
> +
> + /* first copy parent's state */
> + devcg->behavior = parent->behavior;
> + dev_exception_clean(&devcg->exceptions);
> + rc = dev_exceptions_copy(&devcg->exceptions,
> &parent->exceptions);
> + if (rc) {
> + devcg->behavior = DEVCG_DEFAULT_DENY;
> + break;
> + }
> +
> + if (devcg->local.behavior == DEVCG_DEFAULT_DENY &&
> + devcg->behavior == DEVCG_DEFAULT_ALLOW) {
> + devcg->behavior = DEVCG_DEFAULT_DENY;
> + }
I think you might need another special case here. If A and it's
child B are both ALLOW, and A switches to DENY, then if I read this
right B will be switched to DENY, but its local->exceptions will
not be cleared. They won't be immediately applied, so at first it's
ok. But if B then adds an exception, what happens? It'll call
revalidate_exceptions on the full old list plus new exception. If
any exceptions aren't allowed by the parent then it won't be applied,
but it's possible that it is allowed in the parent but (its sense
now being inverted from blacklist to whitelist) not intended to be
allowed in the child. But there will be nothing to stop it.
So do you need
if (devcg->local.behavior == DEVCG_DEFAULT_ALLOW &&
devcg->behavior == DEVCG_DEFAULT_DENY) {
dev_exception_clean(&devcg->local.exceptions);
}
here?
> + if (devcg->local.behavior == devcg->behavior)
> + rc = revalidate_exceptions(devcg);
> + if (rc)
> + break;
> + list_del_init(&devcg->propagate_pending);
> + }
> +
> + return rc;
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
On Thu, Jan 31, 2013 at 5:27 AM, Stephen Warren wrote: > So this looks like a reasonable binding to me. The one issue is that > it's very generic, and if we go this route, we'll probably end up with > tens or hundreds of identical or extremely similar simple bindings, and > associated drivers. > > We can avoid this instead by defining something like a "simple-lcd" > binding, and associated driver, that will work for perhaps 90%, 95%, > 99%, even 100%(?) of panels. That seems totally doable indeed. Actually the right way to do this might be by extending the simple DPI panel driver Laurent included in his patchset. > Just like the above, but with: > > compatible="simple-panel", "chunghwa,claa101wa01a" > > instead, and the driver binding to "simple-panel" rather than > "chunghwa,claa101wa01a". Just out of curiosity, why don't we rather define compatible="chunghwa,claa101wa01a", "simple-panel" in that order? I thought DT compatible strings should go from more to less specific. The device would still bind to "simple-panel" if no more specific driver exists. > The driver can assume that a specific set of supplies (and perhaps > GPIOs) is always present, and that the /sequence/ of manipulating those > is fixed. This will avoid the need for anything like the power sequences > code. If a particular panel doesn't fit those assumptions, including the > exact sequence of manipulations for each state transition (which should > be documented in the binding) then it can get a custom driver, this also > avoiding having to define custom sequences in DT. > > Things that might be parameterized/optional: > > * Perhaps some GPIOs aren't always present. > * If some regulators aren't SW-controllable, DT should still provide a > fixed/dummy regulator so the driver doesn't care. How about making all regulators and GPIO optional in the driver? > * Wait times between regulator/GPIO/... manipulation could be specified > in DT. > * For panels without EDID, CDF DT bindings can provide the list of > supported modes, otherwise we assume that the display controller that > drives the panel has been told how to access the EDID, just like it > would for an "external" display. Excellent. Thanks for the feedback. Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v4 5/8] MFD: ti_am335x_tscadc: Add DT support
On Wed, Jan 30, 2013 at 16:10:09, Koen Kooi wrote:
>
> Op 24 jan. 2013, om 04:45 heeft "Patil, Rachna" het volgende
> geschreven:
>
> > From: "Patil, Rachna"
> >
> > Make changes to add DT support in the MFD core driver.
> >
> > Signed-off-by: Patil, Rachna
> > ---
> > Changes in v4:
> > Non-standard properties prefixed with vendor name.
> >
> > drivers/mfd/ti_am335x_tscadc.c | 28 +++-
> > 1 file changed, 23 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/mfd/ti_am335x_tscadc.c
> > b/drivers/mfd/ti_am335x_tscadc.c index e9f3fb5..87b446b 100644
> > --- a/drivers/mfd/ti_am335x_tscadc.c
> > +++ b/drivers/mfd/ti_am335x_tscadc.c
> > @@ -22,6 +22,8 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> >
> > #include #include
> >
> > @@ -64,20 +66,31 @@ static int ti_tscadc_probe(struct platform_device
> > *pdev)
> > struct resource *res;
> > struct clk *clk;
> > struct mfd_tscadc_board *pdata = pdev->dev.platform_data;
> > + struct device_node *node = pdev->dev.of_node;
> > struct mfd_cell *cell;
> > int err, ctrl;
> > int clk_value, clock_rate;
> > - int tsc_wires, adc_channels = 0, total_channels;
> > + int tsc_wires = 0, adc_channels = 0, total_channels;
> >
> > - if (!pdata) {
> > + if (!pdata && !pdev->dev.of_node) {
> > dev_err(&pdev->dev, "Could not find platform data\n");
> > return -EINVAL;
> > }
> >
> > - if (pdata->adc_init)
> > - adc_channels = pdata->adc_init->adc_channels;
> > + if (pdev->dev.platform_data) {
> > + if (pdata->tsc_init)
> > + tsc_wires = pdata->tsc_init->wires;
> > +
> > + if (pdata->adc_init)
> > + adc_channels = pdata->adc_init->adc_channels;
> > + } else {
> > + node = of_find_node_by_name(pdev->dev.of_node, "tsc");
> > + of_property_read_u32(node, "ti,wires", &tsc_wires);
> > +
> > + node = of_find_node_by_name(pdev->dev.of_node, "adc");
> > + of_property_read_u32(node, "ti,adc-channels", &adc_channels);
> > + }
>
> Since AM335x is DT only, why is there a platform data codepath and why is it
> the first branch it tries? And I guess the next question is related to the
> first: why doesn't it work when used with DT? When I copy over the nodes from
> the evm.dts to my board I get "tsc tsc: Missing platform data" in dmesg.
This IP came up 1st on AM335x, but it is not platform dependent. The driver can
be used on other platforms where-in DT is not supported.
According to the maintainers platform data takes precedence over DT. Hence the
order.
I do not see "Missing platform data" error msg in the latest driver. I am not
able to trace from where this got populated.
>
> What are the chances this driver will work when applied on top of 3.8-rcX?
> Has it even been tested with that? Has it been tested at all?
This driver has been tested on top of v3.8-rc3 on a AM335x EVM.
Regards,
Rachna
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8-rc5 xfs corruption
On Wed, Jan 30, 2013 at 10:16:47PM -0500, CAI Qian wrote: > Hello, > > (Sorry to post to xfs mailing lists but unsure about which one is the > best for this.) Trimmed to just x...@oss.sgi.com. > I have seen something like this once during testing on a system with a > EMC VNX FC/multipath back-end. This is a trace from the verifier code that was added in 3.8-rc1 so I doubt it has anything to do with any problem you've seen in the past Can you tell us what workload you were running and what hardware you are using as per: http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F As it is, if you mounted the filesystem after this problem was detected, log recovery probably propagated it to disk. I'd suggest that you run xfs_repair -n on the device and post the output so we can see if any corruption has actaully made it to disk. If no corruption made it to disk, it's possible that we've got the incorrect verifier attached to the buffer. > [ 3025.063024] 8801a0d5: 2e 2e 2f 2e 2e 2f 75 73 72 2f 6c 69 62 2f 6d > 6f ../../usr/lib/mo The start of a block contains a path and the only type of block that can contain this format of metadata is remote symlink block. Remote symlink blocks don't have a verifier attached to them as there is nothing that can currently be used to verify them as correct. I can't see exactly how this can occur as stale buffers have the verifier ops cleared before being returned to the new user, and newly allocated xfs_bufs are zeroed before being initialised. I really need to know what you are doing to be able to get to the bottom of it Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] mtd: devices: elm: Removes literals in elm DT node
Hi Artem, On Thu, Jan 24, 2013 at 14:00:38, Peter Korsgaard wrote: > > "Philip" == Philip Avinash writes: > > Philip> As part of removing generalized dependency, replace > Philip> literal fields in DT compatible field with <52> for am335x > Philip> platforms. > > Acked-by: Peter Korsgaard Can you please accept this patch for am3352 compatibility in ELM node. Peter, Thanks for ack. Thanks Avinash > > -- > Bye, Peter Korsgaard > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpuidle: fix new C-states not functional after AC disconnect
>> Rafael, is possible to apply the patch [1/2] I previously sent ? >> >> https://patchwork.kernel.org/patch/1878691/ > > I need to talk about this with Len. That should happen tomorrow if everything > goes well. Hi Rafael, Have you made a decision on picking up Daniel's first change yet? I think it really is the cleanest way to solve this problem. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tty: Fix ptmx open without closed slave.
Hi Ilya, On Wed, 2012-12-19 at 23:00 +0400, Ilya Zykov wrote: > When we are opening ptmx, we have closed pts, by description. > Now only if we open and after close all pts' descriptions, pty_close() sets > this bit correctly > > Signed-off-by: Ilya Zykov > --- > drivers/tty/pty.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c > index 1ce1362..7b69307 100644 > --- a/drivers/tty/pty.c > +++ b/drivers/tty/pty.c > @@ -659,6 +659,7 @@ static int ptmx_open(struct inode *inode, struct file > *filp) > retval = ptm_driver->ops->open(tty, filp); > if (retval) > goto err_release; > + set_bit(TTY_OTHER_CLOSED, &tty->flags); /* THE SLAVE STILL CLOSED */ I'm not sure this is a good idea. Ideally, if you were only trying to make the logic "more correct", this change would be here, instead: mutex_unlock(&tty_mutex); set_bit(TTY_PTY_LOCK, &tty->flags); /* LOCK THE SLAVE */ + set_bit(TTY_OTHER_CLOSED, &tty->flags); /* THE SLAVE STILL CLOSED */ tty->driver_data = inode; tty_add_file(tty, filp); Of course, that would be a bad idea because then the master pty_open() would fail because of the test in pty_open(). Setting TTY_OTHER_CLOSED after the open() -- as you've done -- appears to leave a race open when this bit is not set but while a slave open() may still be attempted. But as far as I can tell, this change doesn't actually affect any code branches -- that is, doesn't actually do anything -- so no such race exists. Is that correct? Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
On 01/31/2013 04:19 AM, Stephen Warren wrote:
> On 01/30/2013 12:20 AM, Mark Zhang wrote:
>> On 01/30/2013 11:02 AM, Alexandre Courbot wrote:
>>> Add support for the Chunghwa CLAA101WA01A display panel.
>
>>> +static int panel_claa101_get_modes(struct display_entity *entity,
>>> + const struct videomode **modes)
>>> +{
>>> + /* TODO get modes from EDID? */
>>
>> Why not move the "nvidia,ddc" from encoder's DT to panel's DT? In that
>> case, you can get EDID here. I know drm has some helpers to fetch EDID
>> but I recall there are some other functions which has no drm
>> dependencies which may be suitable for you.
>
> DDC access is a property of the display controller, not the panel
> itself. The panel might be hooked up to a display controller's DDC/I2C
> channel as the target, but it isn't the host/controller of the DDC/I2C
> channel. As such, placing the nvidia,ddc property into the display
> controller node makes sense.
>
Yes, DC triggers the DDC access and is the host of the DDC/I2C channel.
So I think it's reasonable to put nvidia,ddc property into the display
controller node. But the video mode info in EDID which be fetched via
DDC is the property of the panel, so this info should be provided by
panel driver. Actually display controller cares about the video modes,
not the way to get these info. So I think it's better to do the whole
work like this:
1) display controller relied on CDF to call "display_entity_get_modes"
2) panel driver calls the function which is hooked to display controller
to get the video modes via DDC.
3) if the video modes can't be fetched via DDC, panel driver provides
the info(either by hard-coded or defined in DT) anyway
> Re: the other discussion in this thread: Probably the simplest is if
> tegradrm/other-CDF-users do something like:
>
> 1) If DDC I2C channel available for this display channel, query DDC.
Just like I said above, display controller should not query DDC
directly. Since CDF already defines these for us, display controller
should call CDF's functions, like: display_entity_get_modes,
display_entity_get_size... I think this is the key difference I wanna
talk about. And also in this way, display controller doesn't need to
care about this 2 steps logics, just call "display_entity_get_modes" is OK.
Mark
> 2) If not, or perhaps also if that fails, query the panel driver for the
> mode list.
>
> That would cover all bases very simply.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
MIPS atomic_set_mask and atomic_clear_mask
Hello, everybody: Does MIPS need the functions atomic_set_mask and atomic_clear_mask? Or how can I implement these functions. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ACPI / scan: Clean up acpi_bus_get_parent()
2013/01/31 7:04, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki
Make acpi_bus_get_parent() more straightforward and remove an
unnecessary local variable ret from it.
Signed-off-by: Rafael J. Wysocki
---
Acked-by: Yasuaki Ishimatsu
drivers/acpi/scan.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
Index: test/drivers/acpi/scan.c
===
--- test.orig/drivers/acpi/scan.c
+++ test/drivers/acpi/scan.c
@@ -871,29 +871,23 @@ EXPORT_SYMBOL(acpi_bus_unregister_driver
--
*/
static struct acpi_device *acpi_bus_get_parent(acpi_handle handle)
{
+ struct acpi_device *device = NULL;
acpi_status status;
- int ret;
- struct acpi_device *device;
/*
* Fixed hardware devices do not appear in the namespace and do not
* have handles, but we fabricate acpi_devices for them, so we have
* to deal with them specially.
*/
- if (handle == NULL)
+ if (!handle)
return acpi_root;
do {
status = acpi_get_parent(handle, &handle);
- if (status == AE_NULL_ENTRY)
- return NULL;
if (ACPI_FAILURE(status))
- return acpi_root;
-
- ret = acpi_bus_get_device(handle, &device);
- if (ret == 0)
- return device;
- } while (1);
+ return status == AE_NULL_ENTRY ? NULL : acpi_root;
+ } while (acpi_bus_get_device(handle, &device));
+ return device;
}
acpi_status
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 00/15] memory-hotplug: hot-remove physical memory
Hi Simon,
Please see below. :)
On 01/31/2013 09:22 AM, Simon Jeons wrote:
Sorry, I still confuse. :(
update node_states[N_NORMAL_MEMORY] to node_states[N_MEMORY] or
node_states[N_NORMAL_MEMOR] present 0...ZONE_MOVABLE?
node_states is what? node_states[N_NORMAL_MEMOR] or
node_states[N_MEMORY]?
Are you asking what node_states[] is ?
node_states[] is an array of nodemask,
extern nodemask_t node_states[NR_NODE_STATES];
For example, node_states[N_NORMAL_MEMOR] represents which nodes have
normal memory.
If N_MEMORY == N_HIGH_MEMORY == N_NORMAL_MEMORY, node_states[N_MEMORY] is
node_states[N_NORMAL_MEMOR]. So it represents which nodes have 0 ...
ZONE_MOVABLE.
Why check !z1->wait_table in function move_pfn_range_left and function
__add_zone? I think zone->wait_table is initialized in
free_area_init_core, which will be called during system initialization
and hotadd_new_pgdat path.
I think,
free_area_init_core(), in the for loop,
|--> size = zone_spanned_pages_in_node();
|--> if (!size)
continue; If zone is empty, we jump
out the for loop.
|--> init_currently_empty_zone()
So, if the zone is empty, wait_table is not initialized.
In move_pfn_range_left(z1, z2), we move pages from z2 to z1. But z1
could be empty.
So we need to check it and initialize z1->wait_table because we are
moving pages into it.
There is a zone populated check in function online_pages. But zone is
populated in free_area_init_core which will be called during system
initialization and hotadd_new_pgdat path. Why still need this check?
Because we could also rebuild zone list when we offline pages.
__offline_pages()
|--> zone->present_pages -= offlined_pages;
|--> if (!populated_zone(zone)) {
build_all_zonelists(NULL, NULL);
}
If the zone is empty, and other zones on the same node is not empty, the
node
won't be offlined, and next time we online pages of this zone, the pgdat
won't
be initialized again, and we need to check populated_zone(zone) when
onlining
pages.
Thanks. :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH 4/4] GPU/i915: Fix acpi_bus_get_device() check in drivers/gpu/drm/i915/intel_opregion.c
I forgot to change subject. So I resend a patch. --- acpi_bus_get_device() returns int not acpi_status. The patch change not to apply ACPI_FAILURE() to the return value of acpi_bus_get_device(). Signed-off-by: Yasuaki Ishimatsu --- drivers/gpu/drm/i915/intel_opregion.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-pm/drivers/gpu/drm/i915/intel_opregion.c === --- linux-pm.orig/drivers/gpu/drm/i915/intel_opregion.c 2013-01-31 11:39:37.075849905 +0900 +++ linux-pm/drivers/gpu/drm/i915/intel_opregion.c 2013-01-31 11:52:18.796850274 +0900 @@ -347,7 +347,7 @@ static void intel_didl_outputs(struct dr int i = 0; handle = DEVICE_ACPI_HANDLE(&dev->pdev->dev); - if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &acpi_dev))) + if (!handle || acpi_bus_get_device(handle, &acpi_dev)) return; if (acpi_is_video_device(acpi_dev)) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH 3/4] PNPACPI: Fix acpi_bus_get_device() check in drivers/pnp/pnpacpi/core.c
I forgot to chnage subject. So I resend a patch.
---
acpi_bus_get_device() returns int not acpi_status.
The patch change not to apply ACPI_FAILURE() to the return value of
acpi_bus_get_device().
Signed-off-by: Yasuaki Ishimatsu
---
drivers/pnp/pnpacpi/core.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Index: linux-pm/drivers/pnp/pnpacpi/core.c
===
--- linux-pm.orig/drivers/pnp/pnpacpi/core.c2013-01-31 11:04:43.0
+0900
+++ linux-pm/drivers/pnp/pnpacpi/core.c 2013-01-31 11:38:47.659849883 +0900
@@ -90,7 +90,7 @@ static int pnpacpi_set_resources(struct
pnp_dbg(&dev->dev, "set resources\n");
handle = DEVICE_ACPI_HANDLE(&dev->dev);
- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &acpi_dev))) {
+ if (!handle || acpi_bus_get_device(handle, &acpi_dev)) {
dev_dbg(&dev->dev, "ACPI device not found in %s!\n", __func__);
return -ENODEV;
}
@@ -123,7 +123,7 @@ static int pnpacpi_disable_resources(str
dev_dbg(&dev->dev, "disable resources\n");
handle = DEVICE_ACPI_HANDLE(&dev->dev);
- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &acpi_dev))) {
+ if (!handle || acpi_bus_get_device(handle, &acpi_dev)) {
dev_dbg(&dev->dev, "ACPI device not found in %s!\n", __func__);
return 0;
}
@@ -145,7 +145,7 @@ static bool pnpacpi_can_wakeup(struct pn
acpi_handle handle;
handle = DEVICE_ACPI_HANDLE(&dev->dev);
- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &acpi_dev))) {
+ if (!handle || acpi_bus_get_device(handle, &acpi_dev)) {
dev_dbg(&dev->dev, "ACPI device not found in %s!\n", __func__);
return false;
}
@@ -160,7 +160,7 @@ static int pnpacpi_suspend(struct pnp_de
int error = 0;
handle = DEVICE_ACPI_HANDLE(&dev->dev);
- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &acpi_dev))) {
+ if (!handle || acpi_bus_get_device(handle, &acpi_dev)) {
dev_dbg(&dev->dev, "ACPI device not found in %s!\n", __func__);
return 0;
}
@@ -197,7 +197,7 @@ static int pnpacpi_resume(struct pnp_dev
acpi_handle handle = DEVICE_ACPI_HANDLE(&dev->dev);
int error = 0;
- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &acpi_dev))) {
+ if (!handle || acpi_bus_get_device(handle, &acpi_dev)) {
dev_dbg(&dev->dev, "ACPI device not found in %s!\n", __func__);
return -ENODEV;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3] regulators: anatop: add set_voltage_time_sel interface
some of anatop's regulators(cpu, vddpu and vddsoc) have
register settings about LDO's step time, which will impact
the LDO ramp up speed, need to use set_voltage_time_sel
interface to add necessary delay everytime LDOs' voltage
is increased.
offset 0x170:
bit [24-25]: cpu
bit [26-27]: vddpu
bit [28-29]: vddsoc
field definition:
0'b00: 64 cycles of 24M clock;
0'b01: 128 cycles of 24M clock;
0'b02: 256 cycles of 24M clock;
0'b03: 512 cycles of 24M clock;
Signed-off-by: Anson Huang
---
.../bindings/regulator/anatop-regulator.txt|8
drivers/regulator/anatop-regulator.c | 41
2 files changed, 49 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
index 357758c..758eae2 100644
--- a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
@@ -9,6 +9,11 @@ Required properties:
- anatop-min-voltage: Minimum voltage of this regulator
- anatop-max-voltage: Maximum voltage of this regulator
+Optional properties:
+- anatop-delay-reg-offset: Anatop MFD step time register offset
+- anatop-delay-bit-shift: Bit shift for the step time register
+- anatop-delay-bit-width: Number of bits used in the step time register
+
Any property defined as part of the core regulator
binding, defined in regulator.txt, can also be used.
@@ -23,6 +28,9 @@ Example:
anatop-reg-offset = <0x140>;
anatop-vol-bit-shift = <9>;
anatop-vol-bit-width = <5>;
+ anatop-delay-reg-offset = <0x170>;
+ anatop-delay-bit-shift = <24>;
+ anatop-delay-bit-width = <2>;
anatop-min-bit-val = <1>;
anatop-min-voltage = <725000>;
anatop-max-voltage = <130>;
diff --git a/drivers/regulator/anatop-regulator.c
b/drivers/regulator/anatop-regulator.c
index 8f39cac..0df9c6a 100644
--- a/drivers/regulator/anatop-regulator.c
+++ b/drivers/regulator/anatop-regulator.c
@@ -31,12 +31,18 @@
#include
#include
+#define LDO_RAMP_UP_UNIT_IN_CYCLES 64 /* 64 cycles per step */
+#define LDO_RAMP_UP_FREQ_IN_MHZ 24 /* cycle based on 24M OSC */
+
struct anatop_regulator {
const char *name;
u32 control_reg;
struct regmap *anatop;
int vol_bit_shift;
int vol_bit_width;
+ u32 delay_reg;
+ int delay_bit_shift;
+ int delay_bit_width;
int min_bit_val;
int min_voltage;
int max_voltage;
@@ -55,6 +61,32 @@ static int anatop_regmap_set_voltage_sel(struct
regulator_dev *reg,
return regulator_set_voltage_sel_regmap(reg, selector);
}
+static int anatop_regmap_set_voltage_time_sel(struct regulator_dev *reg,
+ unsigned int old_sel,
+ unsigned int new_sel)
+{
+ struct anatop_regulator *anatop_reg = rdev_get_drvdata(reg);
+ u32 val;
+ int ret = 0;
+
+ /* check whether need to care about LDO ramp up speed */
+ if (anatop_reg->delay_bit_width && new_sel > old_sel) {
+ /*
+* the delay for LDO ramp up time is
+* based on the register setting, we need
+* to calculate how many steps LDO need to
+* ramp up, and how much delay needed. (us)
+*/
+ regmap_read(anatop_reg->anatop, anatop_reg->delay_reg, &val);
+ val = (val >> anatop_reg->delay_bit_shift) &
+ ((1 << anatop_reg->delay_bit_width) - 1);
+ ret = (new_sel - old_sel) * ((LDO_RAMP_UP_UNIT_IN_CYCLES <<
+ val) / LDO_RAMP_UP_FREQ_IN_MHZ + 1);
+ }
+
+ return ret;
+}
+
static int anatop_regmap_get_voltage_sel(struct regulator_dev *reg)
{
struct anatop_regulator *anatop_reg = rdev_get_drvdata(reg);
@@ -67,6 +99,7 @@ static int anatop_regmap_get_voltage_sel(struct regulator_dev
*reg)
static struct regulator_ops anatop_rops = {
.set_voltage_sel = anatop_regmap_set_voltage_sel,
+ .set_voltage_time_sel = anatop_regmap_set_voltage_time_sel,
.get_voltage_sel = anatop_regmap_get_voltage_sel,
.list_voltage = regulator_list_voltage_linear,
.map_voltage = regulator_map_voltage_linear,
@@ -143,6 +176,14 @@ static int anatop_regulator_probe(struct platform_device
*pdev)
goto anatop_probe_end;
}
+ /* read LDO ramp up setting, only for core reg */
+ of_property_read_u32(np, "anatop-delay-reg-offset",
+&sreg->delay_reg);
+ of_property_read_u32(np, "anatop-delay-bit-width",
+&sreg->delay_bit_width);
+ of_property_read_u32(np, "anatop-delay-bit-shift",
+&sreg->delay_bit_shift);
+
rdesc->n_voltages = (sreg->max_voltage - sreg->min_voltage) / 25000 + 1
[RESEND PATCH 2/4] ACPI/dock: Fix acpi_bus_get_device() check in drivers/acpi/ddock.c
I forgot to change subject. So I resend a patch. --- acpi_bus_get_device() returns int not acpi_status. The patch change not to apply ACPI_SUCCESS() to the return value of acpi_bus_get_device(). Signed-off-by: Yasuaki Ishimatsu --- drivers/acpi/dock.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-pm/drivers/acpi/dock.c === --- linux-pm.orig/drivers/acpi/dock.c 2013-01-31 11:39:40.574849906 +0900 +++ linux-pm/drivers/acpi/dock.c2013-01-31 11:50:11.329850213 +0900 @@ -836,7 +836,7 @@ static ssize_t show_docked(struct device struct dock_station *dock_station = dev->platform_data; - if (ACPI_SUCCESS(acpi_bus_get_device(dock_station->handle, &tmp))) + if (!acpi_bus_get_device(dock_station->handle, &tmp)) return snprintf(buf, PAGE_SIZE, "1\n"); return snprintf(buf, PAGE_SIZE, "0\n"); } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH 1/4] ACPI/PM: Fix acpi_bus_get_device() check in drivers/acpi/device_pm.c
I fogot to change subject. So I resend a patch.
---
acpi_bus_get_device() returns int not acpi_status.
The patch change not to apply ACPI_FAILURE() to the return value of
acpi_bus_get_device().
Signed-off-by: Yasuaki Ishimatsu
---
drivers/acpi/device_pm.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-pm/drivers/acpi/device_pm.c
===
--- linux-pm.orig/drivers/acpi/device_pm.c 2013-01-31 11:04:30.0
+0900
+++ linux-pm/drivers/acpi/device_pm.c 2013-01-31 11:28:51.366849592 +0900
@@ -213,7 +213,7 @@ int acpi_pm_device_sleep_state(struct de
acpi_handle handle = DEVICE_ACPI_HANDLE(dev);
struct acpi_device *adev;
- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &adev))) {
+ if (!handle || acpi_bus_get_device(handle, &adev)) {
dev_dbg(dev, "ACPI handle without context in %s!\n", __func__);
return -ENODEV;
}
@@ -290,7 +290,7 @@ int acpi_pm_device_run_wake(struct devic
return -EINVAL;
handle = DEVICE_ACPI_HANDLE(phys_dev);
- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &adev))) {
+ if (!handle || acpi_bus_get_device(handle, &adev)) {
dev_dbg(phys_dev, "ACPI handle without context in %s!\n",
__func__);
return -ENODEV;
@@ -334,7 +334,7 @@ int acpi_pm_device_sleep_wake(struct dev
return -EINVAL;
handle = DEVICE_ACPI_HANDLE(dev);
- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &adev))) {
+ if (!handle || acpi_bus_get_device(handle, &adev)) {
dev_dbg(dev, "ACPI handle without context in %s!\n", __func__);
return -ENODEV;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] Fix acpi_bus_get_device() check
acpi_bus_get_device() returns int not acpi_status. The patch change not to apply ACPI_FAILURE() to the return value of acpi_bus_get_device(). Signed-off-by: Yasuaki Ishimatsu --- drivers/gpu/drm/i915/intel_opregion.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-pm/drivers/gpu/drm/i915/intel_opregion.c === --- linux-pm.orig/drivers/gpu/drm/i915/intel_opregion.c 2013-01-31 11:39:37.075849905 +0900 +++ linux-pm/drivers/gpu/drm/i915/intel_opregion.c 2013-01-31 11:52:18.796850274 +0900 @@ -347,7 +347,7 @@ static void intel_didl_outputs(struct dr int i = 0; handle = DEVICE_ACPI_HANDLE(&dev->pdev->dev); - if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &acpi_dev))) + if (!handle || acpi_bus_get_device(handle, &acpi_dev)) return; if (acpi_is_video_device(acpi_dev)) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] Fix acpi_bus_get_device() check
acpi_bus_get_device() returns int not acpi_status.
The patch change not to apply ACPI_FAILURE() to the return value of
acpi_bus_get_device().
Signed-off-by: Yasuaki Ishimatsu
---
drivers/pnp/pnpacpi/core.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Index: linux-pm/drivers/pnp/pnpacpi/core.c
===
--- linux-pm.orig/drivers/pnp/pnpacpi/core.c2013-01-31 11:04:43.0
+0900
+++ linux-pm/drivers/pnp/pnpacpi/core.c 2013-01-31 11:38:47.659849883 +0900
@@ -90,7 +90,7 @@ static int pnpacpi_set_resources(struct
pnp_dbg(&dev->dev, "set resources\n");
handle = DEVICE_ACPI_HANDLE(&dev->dev);
- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &acpi_dev))) {
+ if (!handle || acpi_bus_get_device(handle, &acpi_dev)) {
dev_dbg(&dev->dev, "ACPI device not found in %s!\n", __func__);
return -ENODEV;
}
@@ -123,7 +123,7 @@ static int pnpacpi_disable_resources(str
dev_dbg(&dev->dev, "disable resources\n");
handle = DEVICE_ACPI_HANDLE(&dev->dev);
- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &acpi_dev))) {
+ if (!handle || acpi_bus_get_device(handle, &acpi_dev)) {
dev_dbg(&dev->dev, "ACPI device not found in %s!\n", __func__);
return 0;
}
@@ -145,7 +145,7 @@ static bool pnpacpi_can_wakeup(struct pn
acpi_handle handle;
handle = DEVICE_ACPI_HANDLE(&dev->dev);
- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &acpi_dev))) {
+ if (!handle || acpi_bus_get_device(handle, &acpi_dev)) {
dev_dbg(&dev->dev, "ACPI device not found in %s!\n", __func__);
return false;
}
@@ -160,7 +160,7 @@ static int pnpacpi_suspend(struct pnp_de
int error = 0;
handle = DEVICE_ACPI_HANDLE(&dev->dev);
- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &acpi_dev))) {
+ if (!handle || acpi_bus_get_device(handle, &acpi_dev)) {
dev_dbg(&dev->dev, "ACPI device not found in %s!\n", __func__);
return 0;
}
@@ -197,7 +197,7 @@ static int pnpacpi_resume(struct pnp_dev
acpi_handle handle = DEVICE_ACPI_HANDLE(&dev->dev);
int error = 0;
- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &acpi_dev))) {
+ if (!handle || acpi_bus_get_device(handle, &acpi_dev)) {
dev_dbg(&dev->dev, "ACPI device not found in %s!\n", __func__);
return -ENODEV;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
3.8-rc5 xfs corruption
Hello, (Sorry to post to xfs mailing lists but unsure about which one is the best for this.) I have seen something like this once during testing on a system with a EMC VNX FC/multipath back-end. Kernel config file is here, http://people.redhat.com/qcai/stable/.config [ 3025.063024] 8801a0d5: 2e 2e 2f 2e 2e 2f 75 73 72 2f 6c 69 62 2f 6d 6f ../../usr/lib/mo [ 3025.071743] XFS (dm-1): Internal error xfs_bmbt_verify at line 747 of file fs/xfs/xfs_bmap_btree.c. Caller 0xa01c375e [ 3025.071743] [ 3025.084589] Pid: 275, comm: xfsaild/dm-1 Tainted: GF3.8.0-rc5 #1 [ 3025.091636] Call Trace: [ 3025.094176] [] xfs_error_report+0x3f/0x50 [xfs] [ 3025.100415] [] ? xfs_bmbt_write_verify+0xe/0x10 [xfs] [ 3025.107163] [] xfs_corruption_error+0x5e/0x90 [xfs] [ 3025.113744] [] ? xfs_bmbt_write_verify+0xe/0x10 [xfs] [ 3025.120495] [] xfs_bmbt_verify+0x76/0x1c0 [xfs] [ 3025.126737] [] ? xfs_bmbt_write_verify+0xe/0x10 [xfs] [ 3025.133481] [] ? xfs_bdstrat_cb+0x65/0xd0 [xfs] [ 3025.139714] [] xfs_bmbt_write_verify+0xe/0x10 [xfs] [ 3025.146287] [] _xfs_buf_ioapply+0x5e/0x370 [xfs] [ 3025.152565] [] ? try_to_wake_up+0x2d0/0x2d0 [ 3025.158442] [] ? xfs_bdstrat_cb+0x65/0xd0 [xfs] [ 3025.164669] [] xfs_buf_iorequest+0x4a/0xa0 [xfs] [ 3025.170979] [] xfs_bdstrat_cb+0x65/0xd0 [xfs] [ 3025.177032] [] __xfs_buf_delwri_submit+0x171/0x1e0 [xfs] [ 3025.184038] [] ? xfs_buf_delwri_submit_nowait+0x20/0x30 [xfs] [ 3025.191491] [] ? xfs_trans_ail_cursor_first+0x80/0xb0 [xfs] [ 3025.198755] [] xfs_buf_delwri_submit_nowait+0x20/0x30 [xfs] [ 3025.206030] [] xfsaild+0x222/0x5e0 [xfs] [ 3025.211665] [] ? xfs_trans_ail_cursor_first+0xb0/0xb0 [xfs] [ 3025.218890] [] kthread+0xc0/0xd0 [ 3025.223784] [] ? kthread_create_on_node+0x120/0x120 [ 3025.230317] [] ret_from_fork+0x7c/0xb0 [ 3025.235721] [] ? kthread_create_on_node+0x120/0x120 [ 3025.242248] XFS (dm-1): Corruption detected. Unmount and run xfs_repair [ 3025.248865] XFS (dm-1): xfs_do_force_shutdown(0x8) called from line 1340 of file fs/xfs/xfs_buf.c. Return address = 0xa0197411 Does this ring any bell? Regards, CAI Qian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] Fix acpi_bus_get_device() check
acpi_bus_get_device() returns int not acpi_status. The patch change not to apply ACPI_SUCCESS() to the return value of acpi_bus_get_device(). Signed-off-by: Yasuaki Ishimatsu --- drivers/acpi/dock.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-pm/drivers/acpi/dock.c === --- linux-pm.orig/drivers/acpi/dock.c 2013-01-31 11:39:40.574849906 +0900 +++ linux-pm/drivers/acpi/dock.c2013-01-31 11:50:11.329850213 +0900 @@ -836,7 +836,7 @@ static ssize_t show_docked(struct device struct dock_station *dock_station = dev->platform_data; - if (ACPI_SUCCESS(acpi_bus_get_device(dock_station->handle, &tmp))) + if (!acpi_bus_get_device(dock_station->handle, &tmp)) return snprintf(buf, PAGE_SIZE, "1\n"); return snprintf(buf, PAGE_SIZE, "0\n"); } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] Fix acpi_bus_get_device() check
acpi_bus_get_device() returns int not acpi_status.
The patch change not to apply ACPI_FAILURE() to the return value of
acpi_bus_get_device().
Signed-off-by: Yasuaki Ishimatsu
---
drivers/acpi/device_pm.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-pm/drivers/acpi/device_pm.c
===
--- linux-pm.orig/drivers/acpi/device_pm.c 2013-01-31 11:04:30.0
+0900
+++ linux-pm/drivers/acpi/device_pm.c 2013-01-31 11:28:51.366849592 +0900
@@ -213,7 +213,7 @@ int acpi_pm_device_sleep_state(struct de
acpi_handle handle = DEVICE_ACPI_HANDLE(dev);
struct acpi_device *adev;
- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &adev))) {
+ if (!handle || acpi_bus_get_device(handle, &adev)) {
dev_dbg(dev, "ACPI handle without context in %s!\n", __func__);
return -ENODEV;
}
@@ -290,7 +290,7 @@ int acpi_pm_device_run_wake(struct devic
return -EINVAL;
handle = DEVICE_ACPI_HANDLE(phys_dev);
- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &adev))) {
+ if (!handle || acpi_bus_get_device(handle, &adev)) {
dev_dbg(phys_dev, "ACPI handle without context in %s!\n",
__func__);
return -ENODEV;
@@ -334,7 +334,7 @@ int acpi_pm_device_sleep_wake(struct dev
return -EINVAL;
handle = DEVICE_ACPI_HANDLE(dev);
- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &adev))) {
+ if (!handle || acpi_bus_get_device(handle, &adev)) {
dev_dbg(dev, "ACPI handle without context in %s!\n", __func__);
return -ENODEV;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] Fix acpi_bus_get_device() check
Some functions use ACPI_SUCCESS/FAILURE for checking return value of
acpi_bus_get_device().
Following patches change not to apply ACPI_SUCCESS/FAILURE to the
return value of acpi_bus_get_device().
[PATCH 1/4] ACPI/PM: Fix acpi_bus_get_device() check in drivers/acpi/device_pm.c
[PATCH 2/4] ACPI/dock: Fix acpi_bus_get_device() check in drivers/acpi/ddock.c
[PATCH 3/4] PNPACPI: Fix acpi_bus_get_device() check in
drivers/pnp/pnpacpi/core.c
[PATCH 4/4] GPU/i915: Fix acpi_bus_get_device() check in
drivers/gpu/drm/i915/intel_opregion.c
2013/01/31 7:03, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki
Since acpi_bus_get_device() returns int and not acpi_status, change
acpi_match_device() so that it doesn't apply ACPI_FAILURE() to the
return value of acpi_bus_get_device().
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/scan.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -491,9 +491,9 @@ const struct acpi_device_id *acpi_match_
const struct device *dev)
{
struct acpi_device *adev;
+ acpi_handle handle = ACPI_HANDLE(dev);
- if (!ids || !ACPI_HANDLE(dev)
- || ACPI_FAILURE(acpi_bus_get_device(ACPI_HANDLE(dev), &adev)))
+ if (!ids || !handle || acpi_bus_get_device(handle, &adev))
return NULL;
return __acpi_match_device(adev, ids);
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Tue, 2013-01-29 at 23:58 -0500, Greg KH wrote:
> On Thu, Jan 10, 2013 at 04:40:19PM -0700, Toshi Kani wrote:
> > +/*
> > + * Hot-plug device information
> > + */
>
> Again, stop it with the "generic" hotplug term here, and everywhere
> else. You are doing a very _specific_ type of hotplug devices, so spell
> it out. We've worked hard to hotplug _everything_ in Linux, you are
> going to confuse a lot of people with this type of terms.
Agreed. I will clarify in all places.
> > +union shp_dev_info {
> > + struct shp_cpu {
> > + u32 cpu_id;
> > + } cpu;
>
> What is this? Why not point to the system device for the cpu?
This info is used to on-line a new CPU and create its system/cpu device.
In other word, a system/cpu device is created as a result of CPU
hotplug.
> > + struct shp_memory {
> > + int node;
> > + u64 start_addr;
> > + u64 length;
> > + } mem;
>
> Same here, why not point to the system device?
Same as above.
> > + struct shp_hostbridge {
> > + } hb;
> > +
> > + struct shp_node {
> > + } node;
>
> What happened here with these? Empty structures? Huh?
They are place holders for now. PCI bridge hot-plug and node hot-plug
are still very much work in progress, so I have not integrated them into
this framework yet.
> > +};
> > +
> > +struct shp_device {
> > + struct list_headlist;
> > + struct device *device;
>
> No, make it a "real" device, embed the device into it.
This device pointer is used to send KOBJ_ONLINE/OFFLINE event during CPU
online/offline operation in order to maintain the current behavior. CPU
online/offline operation only changes the state of CPU, so its
system/cpu device continues to be present before and after an operation.
(Whereas, CPU hot-add/delete operation creates or removes a system/cpu
device.) So, this "*device" needs to be a pointer to reference an
existing device that is to be on-lined/off-lined.
> But, again, I'm going to ask why you aren't using the existing cpu /
> memory / bridge / node devices that we have in the kernel. Please use
> them, or give me a _really_ good reason why they will not work.
We cannot use the existing system devices or ACPI devices here. During
hot-plug, ACPI handler sets this shp_device info, so that cpu and memory
handlers (drivers/cpu.c and mm/memory_hotplug.c) can obtain their target
device information in a platform-neutral way. During hot-add, we first
creates an ACPI device node (i.e. device under /sys/bus/acpi/devices),
but platform-neutral modules cannot use them as they are ACPI-specific.
Also, its system device (i.e. device under /sys/devices/system) has not
been created until the hot-add operation completes.
> > + enum shp_class class;
> > + union shp_dev_info info;
> > +};
> > +
> > +/*
> > + * Hot-plug request
> > + */
> > +struct shp_request {
> > + /* common info */
> > + enum shp_operation operation; /* operation */
> > +
> > + /* hot-plug event info: only valid for hot-plug operations */
> > + void*handle;/* FW handle */
> > + u32 event; /* FW event */
>
> What is this?
The shp_request describes a hotplug or online/offline operation that is
requested. In case of hot-plug request, the "*handle" describes a
target device (which is an ACPI device object) and the "event" describes
a type of request, such as hot-add or hot-delete.
Thanks,
-Toshi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] regulators: anatop: add set_voltage_time_sel interface
On Thu, Jan 31, 2013 at 10:57:06AM -0500, Anson Huang wrote:
> some of anatop's regulators(cpu, vddpu and vddsoc) have
> register settings about LDO's step time, which will impact
> the LDO ramp up speed, need to use set_voltage_time_sel
> interface to add necessary delay everytime LDOs' voltage
> is increased.
>
> offset 0x170:
> bit [24-25]: cpu
> bit [26-27]: vddpu
> bit [28-29]: vddsoc
>
> field definition:
> 0'b00: 64 cycles of 24M clock;
> 0'b01: 128 cycles of 24M clock;
> 0'b02: 256 cycles of 24M clock;
> 0'b03: 512 cycles of 24M clock;
>
> Signed-off-by: Anson Huang
> ---
> .../bindings/regulator/anatop-regulator.txt|8
> drivers/regulator/anatop-regulator.c | 42
>
> 2 files changed, 50 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
> b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
> index 357758c..758eae2 100644
> --- a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
> +++ b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
> @@ -9,6 +9,11 @@ Required properties:
> - anatop-min-voltage: Minimum voltage of this regulator
> - anatop-max-voltage: Maximum voltage of this regulator
>
> +Optional properties:
> +- anatop-delay-reg-offset: Anatop MFD step time register offset
> +- anatop-delay-bit-shift: Bit shift for the step time register
> +- anatop-delay-bit-width: Number of bits used in the step time register
> +
> Any property defined as part of the core regulator
> binding, defined in regulator.txt, can also be used.
>
> @@ -23,6 +28,9 @@ Example:
> anatop-reg-offset = <0x140>;
> anatop-vol-bit-shift = <9>;
> anatop-vol-bit-width = <5>;
> + anatop-delay-reg-offset = <0x170>;
> + anatop-delay-bit-shift = <24>;
> + anatop-delay-bit-width = <2>;
> anatop-min-bit-val = <1>;
> anatop-min-voltage = <725000>;
> anatop-max-voltage = <130>;
> diff --git a/drivers/regulator/anatop-regulator.c
> b/drivers/regulator/anatop-regulator.c
> index 8f39cac..fe79d24 100644
> --- a/drivers/regulator/anatop-regulator.c
> +++ b/drivers/regulator/anatop-regulator.c
> @@ -31,12 +31,18 @@
> #include
> #include
>
> +#define LDO_RAMP_UP_UNIT_IN_CYCLES 64 /* 64 cycles per step */
> +#define LDO_RAMP_UP_FREQ_IN_MHZ 24 /* cycle based on 24M OSC */
> +
> struct anatop_regulator {
> const char *name;
> u32 control_reg;
> struct regmap *anatop;
> int vol_bit_shift;
> int vol_bit_width;
> + u32 delay_reg;
> + int delay_bit_shift;
> + int delay_bit_width;
> int min_bit_val;
> int min_voltage;
> int max_voltage;
> @@ -55,6 +61,33 @@ static int anatop_regmap_set_voltage_sel(struct
> regulator_dev *reg,
> return regulator_set_voltage_sel_regmap(reg, selector);
> }
>
> +static int anatop_regmap_set_voltage_time_sel(struct regulator_dev *reg,
> + unsigned int old_sel,
> + unsigned int new_sel)
> +{
> + struct anatop_regulator *anatop_reg = rdev_get_drvdata(reg);
> + u32 val;
> + int ret = 0;
> +
> + /* check whether need to care about LDO ramp up speed */
> + if (anatop_reg->delay_bit_width) {
I would agree with Troy Kisky that the check of (new_sel > old_sel)
could be done in "if" statement, as the whole "if" block is only
needed in case that we are increasing the voltage.
Shawn
> + /*
> + * the delay for LDO ramp up time is
> + * based on the register setting, we need
> + * to calculate how many steps LDO need to
> + * ramp up, and how much delay needed. (us)
> + */
> + regmap_read(anatop_reg->anatop, anatop_reg->delay_reg, &val);
> + val = (val >> anatop_reg->delay_bit_shift) &
> + ((1 << anatop_reg->delay_bit_width) - 1);
> + ret = new_sel > old_sel ? (new_sel - old_sel) *
> + ((LDO_RAMP_UP_UNIT_IN_CYCLES << val) /
> + LDO_RAMP_UP_FREQ_IN_MHZ + 1) : 0;
> + }
> +
> + return ret;
> +}
> +
> static int anatop_regmap_get_voltage_sel(struct regulator_dev *reg)
> {
> struct anatop_regulator *anatop_reg = rdev_get_drvdata(reg);
> @@ -67,6 +100,7 @@ static int anatop_regmap_get_voltage_sel(struct
> regulator_dev *reg)
>
> static struct regulator_ops anatop_rops = {
> .set_voltage_sel = anatop_regmap_set_voltage_sel,
> + .set_voltage_time_sel = anatop_regmap_set_voltage_time_sel,
> .get_voltage_sel = anatop_regmap_get_voltage_sel,
> .list_voltage = regulator_list_voltage_linear,
> .map_voltage = regulator_map_voltage_linear,
> @@ -143,6 +177,14 @@ static int anatop_regulator_probe(struct platform_device
> *pdev)
> goto anatop_probe_end;
> }
>
> + /* read LDO ramp up setting, only for core
Re: [PATCH 2/3] mm: accelerate mm_populate() treatment of THP pages
On Wed, 30 Jan 2013, Michel Lespinasse wrote:
> This change adds a page_mask argument to follow_page.
>
> follow_page sets *page_mask to HPAGE_PMD_NR - 1 when it encounters a THP page,
> and to 0 in other cases.
>
> __get_user_pages() makes use of this in order to accelerate populating
> THP ranges - that is, when both the pages and vmas arrays are NULL,
> we don't need to iterate HPAGE_PMD_NR times to cover a single THP page
> (and we also avoid taking mm->page_table_lock that many times).
>
> Other follow_page() call sites can safely ignore the value returned in
> *page_mask.
>
> Signed-off-by: Michel Lespinasse
I certainly like the skipping.
But (a) if the additional arg has to exist, then I'd much prefer it
to be page_size than page_mask - I realize there's a tiny advantage to
subtracting 1 from an immediate than from a variable, but I don't think
it justifies the peculiar interface. mask makes people think of masking.
And (b) why can't we just omit the additional arg, and get it from the
page found? You've explained the unreliability of the !FOLL_GET case
to me privately, but that needs to be spelt out in the commit comment
(and I'd love if we found a counter-argument, the extra arg of interest
to almost no-one does irritate me).
Hugh
>
> ---
> arch/ia64/xen/xencomm.c| 3 ++-
> arch/powerpc/kernel/vdso.c | 9 +
> arch/s390/mm/pgtable.c | 3 ++-
> include/linux/mm.h | 2 +-
> mm/ksm.c | 10 +++---
> mm/memory.c| 25 +++--
> mm/migrate.c | 7 +--
> mm/mlock.c | 4 +++-
> 8 files changed, 44 insertions(+), 19 deletions(-)
>
> diff --git a/arch/ia64/xen/xencomm.c b/arch/ia64/xen/xencomm.c
> index 73d903ca2d64..c5dcf3a574e9 100644
> --- a/arch/ia64/xen/xencomm.c
> +++ b/arch/ia64/xen/xencomm.c
> @@ -44,6 +44,7 @@ xencomm_vtop(unsigned long vaddr)
> {
> struct page *page;
> struct vm_area_struct *vma;
> + long page_mask;
>
> if (vaddr == 0)
> return 0UL;
> @@ -98,7 +99,7 @@ xencomm_vtop(unsigned long vaddr)
> return ~0UL;
>
> /* We assume the page is modified. */
> - page = follow_page(vma, vaddr, FOLL_WRITE | FOLL_TOUCH);
> + page = follow_page(vma, vaddr, FOLL_WRITE | FOLL_TOUCH, &page_mask);
> if (IS_ERR_OR_NULL(page))
> return ~0UL;
>
> diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
> index 1b2076f049ce..a529502d60f9 100644
> --- a/arch/powerpc/kernel/vdso.c
> +++ b/arch/powerpc/kernel/vdso.c
> @@ -156,6 +156,7 @@ static void dump_one_vdso_page(struct page *pg, struct
> page *upg)
> static void dump_vdso_pages(struct vm_area_struct * vma)
> {
> int i;
> + long page_mask;
>
> if (!vma || is_32bit_task()) {
> printk("vDSO32 @ %016lx:\n", (unsigned long)vdso32_kbase);
> @@ -163,8 +164,8 @@ static void dump_vdso_pages(struct vm_area_struct * vma)
> struct page *pg = virt_to_page(vdso32_kbase +
> i*PAGE_SIZE);
> struct page *upg = (vma && vma->vm_mm) ?
> - follow_page(vma, vma->vm_start + i*PAGE_SIZE, 0)
> - : NULL;
> + follow_page(vma, vma->vm_start + i*PAGE_SIZE,
> + 0, &page_mask) : NULL;
> dump_one_vdso_page(pg, upg);
> }
> }
> @@ -174,8 +175,8 @@ static void dump_vdso_pages(struct vm_area_struct * vma)
> struct page *pg = virt_to_page(vdso64_kbase +
> i*PAGE_SIZE);
> struct page *upg = (vma && vma->vm_mm) ?
> - follow_page(vma, vma->vm_start + i*PAGE_SIZE, 0)
> - : NULL;
> + follow_page(vma, vma->vm_start + i*PAGE_SIZE,
> + 0, &page_mask) : NULL;
> dump_one_vdso_page(pg, upg);
> }
> }
> diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
> index ae44d2a34313..63e897a6cf45 100644
> --- a/arch/s390/mm/pgtable.c
> +++ b/arch/s390/mm/pgtable.c
> @@ -792,9 +792,10 @@ void thp_split_vma(struct vm_area_struct *vma)
> {
> unsigned long addr;
> struct page *page;
> + long page_mask;
>
> for (addr = vma->vm_start; addr < vma->vm_end; addr += PAGE_SIZE) {
> - page = follow_page(vma, addr, FOLL_SPLIT);
> + page = follow_page(vma, addr, FOLL_SPLIT, &page_mask);
> }
> }
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index d5716094f191..6dc0ce370df5 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1636,7 +1636,7 @@ int vm_insert_mixed(struct vm_area_struct *vma,
> unsigned long addr,
> unsigned long pfn
Re: [PATCH 1/2] ACPI / scan: Fix acpi_bus_get_device() check in acpi_match_device()
2013/01/31 7:03, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki
Since acpi_bus_get_device() returns int and not acpi_status, change
acpi_match_device() so that it doesn't apply ACPI_FAILURE() to the
return value of acpi_bus_get_device().
Signed-off-by: Rafael J. Wysocki
---
I have no objection.
Acked-by: Yasuaki Ishimatsu
drivers/acpi/scan.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -491,9 +491,9 @@ const struct acpi_device_id *acpi_match_
const struct device *dev)
{
struct acpi_device *adev;
+ acpi_handle handle = ACPI_HANDLE(dev);
- if (!ids || !ACPI_HANDLE(dev)
- || ACPI_FAILURE(acpi_bus_get_device(ACPI_HANDLE(dev), &adev)))
+ if (!ids || !handle || acpi_bus_get_device(handle, &adev))
return NULL;
return __acpi_match_device(adev, ids);
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2] regulators: anatop: add set_voltage_time_sel interface
some of anatop's regulators(cpu, vddpu and vddsoc) have
register settings about LDO's step time, which will impact
the LDO ramp up speed, need to use set_voltage_time_sel
interface to add necessary delay everytime LDOs' voltage
is increased.
offset 0x170:
bit [24-25]: cpu
bit [26-27]: vddpu
bit [28-29]: vddsoc
field definition:
0'b00: 64 cycles of 24M clock;
0'b01: 128 cycles of 24M clock;
0'b02: 256 cycles of 24M clock;
0'b03: 512 cycles of 24M clock;
Signed-off-by: Anson Huang
---
.../bindings/regulator/anatop-regulator.txt|8
drivers/regulator/anatop-regulator.c | 42
2 files changed, 50 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
index 357758c..758eae2 100644
--- a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
@@ -9,6 +9,11 @@ Required properties:
- anatop-min-voltage: Minimum voltage of this regulator
- anatop-max-voltage: Maximum voltage of this regulator
+Optional properties:
+- anatop-delay-reg-offset: Anatop MFD step time register offset
+- anatop-delay-bit-shift: Bit shift for the step time register
+- anatop-delay-bit-width: Number of bits used in the step time register
+
Any property defined as part of the core regulator
binding, defined in regulator.txt, can also be used.
@@ -23,6 +28,9 @@ Example:
anatop-reg-offset = <0x140>;
anatop-vol-bit-shift = <9>;
anatop-vol-bit-width = <5>;
+ anatop-delay-reg-offset = <0x170>;
+ anatop-delay-bit-shift = <24>;
+ anatop-delay-bit-width = <2>;
anatop-min-bit-val = <1>;
anatop-min-voltage = <725000>;
anatop-max-voltage = <130>;
diff --git a/drivers/regulator/anatop-regulator.c
b/drivers/regulator/anatop-regulator.c
index 8f39cac..fe79d24 100644
--- a/drivers/regulator/anatop-regulator.c
+++ b/drivers/regulator/anatop-regulator.c
@@ -31,12 +31,18 @@
#include
#include
+#define LDO_RAMP_UP_UNIT_IN_CYCLES 64 /* 64 cycles per step */
+#define LDO_RAMP_UP_FREQ_IN_MHZ 24 /* cycle based on 24M OSC */
+
struct anatop_regulator {
const char *name;
u32 control_reg;
struct regmap *anatop;
int vol_bit_shift;
int vol_bit_width;
+ u32 delay_reg;
+ int delay_bit_shift;
+ int delay_bit_width;
int min_bit_val;
int min_voltage;
int max_voltage;
@@ -55,6 +61,33 @@ static int anatop_regmap_set_voltage_sel(struct
regulator_dev *reg,
return regulator_set_voltage_sel_regmap(reg, selector);
}
+static int anatop_regmap_set_voltage_time_sel(struct regulator_dev *reg,
+ unsigned int old_sel,
+ unsigned int new_sel)
+{
+ struct anatop_regulator *anatop_reg = rdev_get_drvdata(reg);
+ u32 val;
+ int ret = 0;
+
+ /* check whether need to care about LDO ramp up speed */
+ if (anatop_reg->delay_bit_width) {
+ /*
+* the delay for LDO ramp up time is
+* based on the register setting, we need
+* to calculate how many steps LDO need to
+* ramp up, and how much delay needed. (us)
+*/
+ regmap_read(anatop_reg->anatop, anatop_reg->delay_reg, &val);
+ val = (val >> anatop_reg->delay_bit_shift) &
+ ((1 << anatop_reg->delay_bit_width) - 1);
+ ret = new_sel > old_sel ? (new_sel - old_sel) *
+ ((LDO_RAMP_UP_UNIT_IN_CYCLES << val) /
+ LDO_RAMP_UP_FREQ_IN_MHZ + 1) : 0;
+ }
+
+ return ret;
+}
+
static int anatop_regmap_get_voltage_sel(struct regulator_dev *reg)
{
struct anatop_regulator *anatop_reg = rdev_get_drvdata(reg);
@@ -67,6 +100,7 @@ static int anatop_regmap_get_voltage_sel(struct
regulator_dev *reg)
static struct regulator_ops anatop_rops = {
.set_voltage_sel = anatop_regmap_set_voltage_sel,
+ .set_voltage_time_sel = anatop_regmap_set_voltage_time_sel,
.get_voltage_sel = anatop_regmap_get_voltage_sel,
.list_voltage = regulator_list_voltage_linear,
.map_voltage = regulator_map_voltage_linear,
@@ -143,6 +177,14 @@ static int anatop_regulator_probe(struct platform_device
*pdev)
goto anatop_probe_end;
}
+ /* read LDO ramp up setting, only for core reg */
+ of_property_read_u32(np, "anatop-delay-reg-offset",
+&sreg->delay_reg);
+ of_property_read_u32(np, "anatop-delay-bit-width",
+&sreg->delay_bit_width);
+ of_property_read_u32(np, "anatop-delay-bit-shift",
+&sreg->delay_bit_shift);
+
rdesc->n_voltages = (sreg->max_voltage - sreg->min_vo
RE: [PATCH 2/4] ARM: imx: set CKO1 parent clock source in imx6q sabresd
Shawn,
Thank your feedback, please see the comments inline
Best Regards
Gary
> -Original Message-
> From: Shawn Guo [mailto:shawn@linaro.org]
> Sent: Tuesday, January 29, 2013 19:29
> To: Zhang Quan-B13634
> Cc: ker...@pengutronix.de; li...@arm.linux.org.uk;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 2/4] ARM: imx: set CKO1 parent clock source in imx6q
> sabresd
>
> Gary,
>
> For arch/arm/ patches, list linux-arm-ker...@lists.infradead.org rather than
> linux-kernel@vger.kernel.org should be copied.
[Gary-b13634] agree
>
> One comment blow.
>
> On Tue, Jan 29, 2013 at 03:49:39PM +0800, Gary Zhang wrote:
> > in imx6q sabresd board, wm8962 uses CKO1 as MCLK. set ahb as CKO1
> > parent clock source
> >
> > Signed-off-by: Gary Zhang
> > ---
> > arch/arm/mach-imx/mach-imx6q.c | 32
> > 1 files changed, 32 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-imx/mach-imx6q.c
> > b/arch/arm/mach-imx/mach-imx6q.c index 4eb1b3a..ee3f357 100644
> > --- a/arch/arm/mach-imx/mach-imx6q.c
> > +++ b/arch/arm/mach-imx/mach-imx6q.c
> > @@ -151,6 +151,36 @@ static void __init imx6q_sabrelite_init(void)
> >imx6q_sabrelite_cko1_setup();
> > }
> >
> > +static void __init imx6q_sabresd_cko1_setup(void) {
> > + struct clk *cko1_sel, *ahb, *cko1;
> > + unsigned long rate;
> > +
> > + cko1_sel = clk_get_sys(NULL, "cko1_sel");
> > + ahb = clk_get_sys(NULL, "ahb");
> > + cko1 = clk_get_sys(NULL, "cko1");
> > + if (IS_ERR(cko1_sel) || IS_ERR(ahb) || IS_ERR(cko1)) {
> > + pr_err("cko1 setup failed!\n");
> > + goto put_clk;
> > + }
> > + clk_set_parent(cko1_sel, ahb);
> > + rate = clk_round_rate(cko1, 2400);
> > + clk_set_rate(cko1, rate);
> > +
> > + return;
> > +put_clk:
> > + if (!IS_ERR(cko1_sel))
> > + clk_put(cko1_sel);
> > + if (!IS_ERR(ahb))
> > + clk_put(ahb);
> > + if (!IS_ERR(cko1))
> > + clk_put(cko1);
> > +}
>
> So the only difference between this function and imx6q_sabrelite_cko1_setup()
> is the frequency set on cko1? If so, we should consolidate them with
> frequency
> passed in as a parameter.
[Gary-b13634] OK, I will do it.
>
> Shawn
>
> > +static void __init imx6q_sabresd_init(void) {
> > + imx6q_sabresd_cko1_setup();
> > +}
> > +
> > static void __init imx6q_1588_init(void) {
> >struct regmap *gpr;
> > @@ -193,6 +223,8 @@ static void __init imx6q_init_machine(void) {
> >if (of_machine_is_compatible("fsl,imx6q-sabrelite"))
> >imx6q_sabrelite_init();
> > + else if (of_machine_is_compatible("fsl,imx6q-sabresd"))
> > + imx6q_sabresd_init();
> >
> >of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> >
> > --
> > 1.7.0.4
> >
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] arm: dts: omap4-sdp: Add I2c pinctrl data
On Wed, Jan 30, 2013 at 14:36:10, Coelho, Luciano wrote: > On Wed, 2013-01-30 at 14:18 +0530, Santosh Shilimkar wrote: > > On Wednesday 30 January 2013 02:13 PM, Kumar, Anil wrote: > > > Hi Sourav, > > > > > > On Wed, Jan 30, 2013 at 12:10:18, Poddar, Sourav wrote: > > >> Hi Luciano, > > >> On Wednesday 30 January 2013 11:55 AM, Luciano Coelho wrote: > > >>> Hi Sourav, > > >>> > > >>> On Mon, 2013-01-28 at 16:47 +0530, Sourav Poddar wrote: > > Booting 3.8-rc4 om omap 4430sdp results in the following error > > > > omap_i2c 4807.i2c: did not get pins for i2c error: -19 > > [1.024261] omap_i2c 4807.i2c: bus 0 rev0.12 at 100 kHz > > [1.030181] omap_i2c 48072000.i2c: did not get pins for i2c error: > > -19 > > [1.037384] omap_i2c 48072000.i2c: bus 1 rev0.12 at 400 kHz > > [1.043762] omap_i2c 4806.i2c: did not get pins for i2c error: > > -19 > > [1.050964] omap_i2c 4806.i2c: bus 2 rev0.12 at 100 kHz > > [1.056823] omap_i2c 4807a000.i2c: did not get pins for i2c error: > > -19 > > [1.064025] omap_i2c 4807a000.i2c: bus 3 rev0.12 at 400 kHz > > > > This happens because omap4 dts file is not adapted to use i2c through > > pinctrl > > framework. Populating i2c pinctrl data to get rid of the error. > > > > Tested on omap4430 sdp with 3.8-rc4 kernel. > > > > Signed-off-by: Sourav Poddar > > Reported-by: Santosh Shilimkar > > --- > > >>> Could you do the same thing for panda? I'm getting the same kind of > > >>> errors with it: > > > > > > omap4 uses pinctrl-single driver for pinmux with DT. Currently > > > pinctrl-single driver is getting up after I2C driver. So I2c cannot > > > use pinctrl. The below patch solve this issue > > > > > > http://www.gossamer-threads.com/lists/linux/kernel/1669067 > > > > > > Can you try with this ? it may solve it. > > > > > OMAP i2c driver already takes care of -EPROBE_DEFER. The issue > > as you see from the log is not probe failure but missing the > > pin information in DT blob. And thats what patch does. > > Yes, Santosh is right. I tried this patch, but it didn't fix the > warnings. Sorry, I misunderstood this issue. Anil
[PATCH] cpufreq: exynos: simplify .init() for setting policy->cpus
With the recent changes in cpufreq core, we just need to set mask of all
possible cpus into policy->cpus. Rest would be done by core.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/exynos-cpufreq.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index 7012ea8..81eb84a 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -227,19 +227,7 @@ static int exynos_cpufreq_cpu_init(struct cpufreq_policy
*policy)
/* set the transition latency value */
policy->cpuinfo.transition_latency = 10;
- /*
-* EXYNOS4 multi-core processors has 2 cores
-* that the frequency cannot be set independently.
-* Each cpu is bound to the same speed.
-* So the affected cpu is all of the cpus.
-*/
- if (num_online_cpus() == 1) {
- cpumask_copy(policy->related_cpus, cpu_possible_mask);
- cpumask_copy(policy->cpus, cpu_online_mask);
- } else {
- policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
- cpumask_setall(policy->cpus);
- }
+ cpumask_setall(policy->cpus);
return cpufreq_frequency_table_cpuinfo(policy, exynos_info->freq_table);
}
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 8/9] devcg: refactor dev_exception_clean()
On 2013/1/31 4:50, Tejun Heo wrote: > Hello, > > On Wed, Jan 30, 2013 at 12:49 PM, Aristeu Rozanski > that's not > intentional. thanks for catching this >> >> Tejun, you want me to resubmit the whole series or just the next patch >> (where I was supposed to move that chunk)? > > If it doesn't affect the next patch, just posting an updated version > of this patch should be enough, I think. Which tree are these patches > planned to go through? > It used to be -mm tree, but I bet Andrew would be happy to see you route them through your tree. ;) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 2/2] sched/fair: prefer a CPU in the "lowest" idle state
On 01/31/2013 05:19 AM, Sebastian Andrzej Siewior wrote:
> If a new CPU has to be choosen for a task, then the scheduler first selects
> the group with the least load. This group is returned if its load is lower
> compared to the group to which the task is currently assigned.
> If there are several groups with completely idle CPU(s) (the CPU is in
> an idle state like C1) then the first group is returned.
> This patch extends this decision by considering the idle state of CPU(s)
> in the group and the first group with a CPU in the lowest idle state
> wins (C1 is prefered over C2). If there is a CPU which is not in an idle
> state (C0) but has no tasks assigned then it is consider as a valid target.
> Should there be no CPU in an idle state at disposal then the loadavg is
> used as a fallback.
>
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> include/linux/sched.h |1 +
> kernel/sched/core.c |6 --
> kernel/sched/fair.c | 24
> 3 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index d211247..c2f6a44 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -934,6 +934,7 @@ struct sched_domain {
> unsigned int wake_idx;
> unsigned int forkexec_idx;
> unsigned int smt_gain;
> + unsigned int prefer_lp;
> int flags; /* See SD_* */
> int level;
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 26058d0..fad16e6 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4971,7 +4971,7 @@ set_table_entry(struct ctl_table *entry,
> static struct ctl_table *
> sd_alloc_ctl_domain_table(struct sched_domain *sd)
> {
> - struct ctl_table *table = sd_alloc_ctl_entry(13);
> + struct ctl_table *table = sd_alloc_ctl_entry(14);
>
> if (table == NULL)
> return NULL;
> @@ -5001,7 +5001,9 @@ sd_alloc_ctl_domain_table(struct sched_domain *sd)
> sizeof(int), 0644, proc_dointvec_minmax, false);
> set_table_entry(&table[11], "name", sd->name,
> CORENAME_MAX_SIZE, 0444, proc_dostring, false);
> - /* &table[12] is terminator */
> + set_table_entry(&table[12], "prefer_lp", &sd->prefer_lp,
> + sizeof(int), 0644, proc_dointvec_minmax, false);
> + /* &table[13] is terminator */
>
> return table;
> }
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 5eea870..bff9800 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -3181,8 +3182,10 @@ find_idlest_group(struct sched_domain *sd, struct
> task_struct *p,
> int this_cpu, int load_idx)
> {
> struct sched_group *idlest = NULL, *group = sd->groups;
> + struct sched_group *idle_group = NULL;
> unsigned long min_load = ULONG_MAX, this_load = 0;
> int imbalance = 100 + (sd->imbalance_pct-100)/2;
> + int least_idle_cpu = INT_MAX;
>
> do {
> unsigned long load, avg_load;
> @@ -3208,6 +3211,25 @@ find_idlest_group(struct sched_domain *sd, struct
> task_struct *p,
> load = target_load(i, load_idx);
>
> avg_load += load;
> + if (!local_group && sd->prefer_lp && least_idle_cpu) {
> + int idle_level;
> +
> + idle_level = cpuidle_get_state(i);
> + /*
> + * Select the CPU which is in the lowest
> + * possible power state. Take the active
> + * CPU only if its run queue is empty.
> + */
> + if (!idle_level) {
> + if (idle_cpu(i)) {
> + least_idle_cpu = idle_level;
> + idle_group = group;
> + }
> + } else if (least_idle_cpu > idle_level) {
> + least_idle_cpu = idle_level;
> + idle_group = group;
> + }
> + }
> }
>
> /* Adjust by relative CPU power of the group */
> @@ -3221,6 +3243,8 @@ find_idlest_group(struct sched_domain *sd, struct
> task_struct *p,
> }
> } while (group = group->next, group != sd->groups);
>
> + if (idle_group)
> + return idle_group;
Hi, Sebastian
I'm not sure, but just concern about this case:
group 0 cpu 0 cpu 1
least idle 4 task
group 1 cpu 2 cpu 3
1 task 1 task
The
Re: [PATCH, RFC 00/16] Transparent huge page cache
On Tue, 29 Jan 2013, Kirill A. Shutemov wrote: > Hugh Dickins wrote: > > On Mon, 28 Jan 2013, Kirill A. Shutemov wrote: > > > From: "Kirill A. Shutemov" > > > > > > Here's first steps towards huge pages in page cache. > > > > > > The intend of the work is get code ready to enable transparent huge page > > > cache for the most simple fs -- ramfs. > > > > > > It's not yet near feature-complete. It only provides basic infrastructure. > > > At the moment we can read, write and truncate file on ramfs with huge > > > pages in > > > page cache. The most interesting part, mmap(), is not yet there. For now > > > we split huge page on mmap() attempt. > > > > > > I can't say that I see whole picture. I'm not sure if I understand locking > > > model around split_huge_page(). Probably, not. > > > Andrea, could you check if it looks correct? > > > > > > Next steps (not necessary in this order): > > > - mmap(); > > > - migration (?); > > > - collapse; > > > - stats, knobs, etc.; > > > - tmpfs/shmem enabling; > > > - ... > > > > > > Kirill A. Shutemov (16): > > > block: implement add_bdi_stat() > > > mm: implement zero_huge_user_segment and friends > > > mm: drop actor argument of do_generic_file_read() > > > radix-tree: implement preload for multiple contiguous elements > > > thp, mm: basic defines for transparent huge page cache > > > thp, mm: rewrite add_to_page_cache_locked() to support huge pages > > > thp, mm: rewrite delete_from_page_cache() to support huge pages > > > thp, mm: locking tail page is a bug > > > thp, mm: handle tail pages in page_cache_get_speculative() > > > thp, mm: implement grab_cache_huge_page_write_begin() > > > thp, mm: naive support of thp in generic read/write routines > > > thp, libfs: initial support of thp in > > > simple_read/write_begin/write_end > > > thp: handle file pages in split_huge_page() > > > thp, mm: truncate support for transparent huge page cache > > > thp, mm: split huge page on mmap file page > > > ramfs: enable transparent huge page cache > > > > > > fs/libfs.c | 54 +--- > > > fs/ramfs/inode.c|6 +- > > > include/linux/backing-dev.h | 10 +++ > > > include/linux/huge_mm.h |8 ++ > > > include/linux/mm.h | 15 > > > include/linux/pagemap.h | 14 ++- > > > include/linux/radix-tree.h |3 + > > > lib/radix-tree.c| 32 +-- > > > mm/filemap.c| 204 > > > +++ > > > mm/huge_memory.c| 62 +++-- > > > mm/memory.c | 22 + > > > mm/truncate.c | 12 +++ > > > 12 files changed, 375 insertions(+), 67 deletions(-) > > > > Interesting. > > > > I was starting to think about Transparent Huge Pagecache a few > > months ago, but then got washed away by incoming waves as usual. > > > > Certainly I don't have a line of code to show for it; but my first > > impression of your patches is that we have very different ideas of > > where to start. A second impression confirms that we have very different ideas of where to start. I don't want to be dismissive, and please don't let me discourage you, but I just don't find what you have very interesting. I'm sure you'll agree that the interesting part, and the difficult part, comes with mmap(); and there's no point whatever to THPages without mmap() (of course, I'm including exec and brk and shm when I say mmap there). (There may be performance benefits in working with larger page cache size, which Christoph Lameter explored a few years back, but that's a different topic: I think 2MB - if I may be x86_64-centric - would not be the unit of choice for that, unless SSD erase block were to dominate.) I'm interested to get to the point of prototyping something that does support mmap() of THPageCache: I'm pretty sure that I'd then soon learn a lot about my misconceptions, and have to rework for a while (or give up!); but I don't see much point in posting anything without that. I don't know if we have 5 or 50 places which "know" that a THPage must be Anon: some I'll spot in advance, some I sadly won't. It's not clear to me that the infrastructural changes you make in this series will be needed or not, if I pursue my approach: some perhaps as optimizations on top of the poorly performing base that may emerge from going about it my way. But for me it's too soon to think about those. Something I notice that we do agree upon: the radix_tree holding the 4k subpages, at least for now. When I first started thinking towards THPageCache, I was fascinated by how we could manage the hugepages in the radix_tree, cutting out unnecessary levels etc; but after a while I realized that although there's probably nice scope for cleverness there (significantly constrained by RCU expectations), it would only be about optimization. Let's be simple and stupid about radix_tree for now, the problems that need
Re: [PATCH 0/3] Enable multiple MSI feature in pSeries
Hi all Any comments about my patchset? Thanks Mike 在 2013-01-15二的 15:38 +0800，Mike Qiu写道： > Currently, multiple MSI feature hasn't been enabled in pSeries, > These patches try to enbale this feature. > > These patches have been tested by using ipr driver, and the driver patch > has been made by Wen Xiong : > > [PATCH 0/7] Add support for new IBM SAS controllers > > Test platform: One partition of pSeries with one cpu core(4 SMTs) and >RAID bus controller: IBM PCI-E IPR SAS Adapter (ASIC) in POWER7 > OS version: SUSE Linux Enterprise Server 11 SP2 (ppc64) with 3.8-rc3 kernel > > IRQ 21 and 22 are assigned to the ipr device which support 2 mutiple MSI. > > The test results is shown by 'cat /proc/interrups': > CPU0 CPU1 CPU2 CPU3 > 16: 240458 261601 226310 200425 XICS Level IPI > 17: 0 0 0 0 XICS Level RAS_EPOW > 18: 10 0 3 2 XICS Level > hvc_console > 19: 122182 28481 28527 28864 XICS Level ibmvscsi > 20:5067388226108118 XICS Level eth0 > 21: 6 5 5 5 XICS Level host1-0 > 22:817814816813 XICS Level host1-1 > LOC: 398077 316725 231882 203049 Local timer interrupts > SPU: 1659919961903 Spurious interrupts > CNT: 0 0 0 0 Performance > monitoring interrupts > MCE: 0 0 0 0 Machine check exceptions > > Mike Qiu (3): > irq: Set multiple MSI descriptor data for multiple IRQs > irq: Add hw continuous IRQs map to virtual continuous IRQs support > powerpc/pci: Enable pSeries multiple MSI feature > > arch/powerpc/kernel/msi.c|4 -- > arch/powerpc/platforms/pseries/msi.c | 62 - > include/linux/irq.h |4 ++ > include/linux/irqdomain.h|3 ++ > kernel/irq/chip.c| 40 - > kernel/irq/irqdomain.c | 61 + > 6 files changed, 158 insertions(+), 16 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
