Add regulator_get_linear_step(), which returns the voltage step size
between VSEL values for linear regulators. This is intended for use
by regulator consumers which build their own voltage-to-VSEL tables.
Signed-off-by: Paul Walmsley
Reviewed-by: Andrew Chew
Cc: Matthew Longnecker
---
Appli
On Fri, Jun 7, 2013 at 8:48 AM, Vladimir Pantelic wrote:
> luke.leighton wrote:
>>
>> On Thu, Jun 6, 2013 at 1:51 PM, Vladimir Pantelic
>> wrote:
>>
>>> 4 days? WTF? since when did setting an ultimatum to the kernel
>>> community work?
>>
>>
>> i was only informed of the opportunity 2 days ago,
On Fri, Jun 07, 2013 at 12:07:23AM +0800, Jiang Liu wrote:
> zram_slot_free_notify() is free-running without any protection from
> concurrent operations. So there are race conditions between
> zram_bvec_read()/zram_bvec_write() and zram_slot_free_notify(),
> and possible consequences include:
> 1)
Hi Ben, Willy,
On Fri, Jun 07, 2013 at 06:42:05AM +0100, Ben Hutchings wrote:
> On Tue, 2013-06-04 at 19:23 +0200, Willy Tarreau wrote:
> > 2.6.32-longterm review patch. If anyone has any objections, please let me
> > know.
> >
> > --
> > data exposure
> >
> > From: Jamie Iles
On Thu, Jun 6, 2013 at 2:10 PM, Russell King - ARM Linux
wrote:
> If companies are going to go off and invent the square wheel, and that
> makes *them* suffer the loss of being able to merge back into the
> mainline kernel, thereby making *their* job of moving forward with
> their kernel versions
Hello Jiang,
On Fri, Jun 07, 2013 at 12:07:22AM +0800, Jiang Liu wrote:
> Memory for zram->disk object may have already been freed after returning
> from destroy_device(zram), then it's unsafe for zram_reset_device(zram)
> to access zram->disk again.
>
> We can't solve this bug by flipping the or
On Fri, Jun 07, 2013 at 08:25:55AM +0300, Mika Westerberg wrote:
> On Thu, Jun 06, 2013 at 03:43:36PM +0200, Christian Ruppert wrote:
> > When the process at the source of an i2c transfer is killed in the
> > middle of the transfer, the transfer is interrupted. Interrupted
> > transfers might cause
On Wed, Jun 5, 2013 at 7:22 PM, Stephen Warren wrote:
>> diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
>
>> +int pinctrl_pm_select_default_state(struct device *dev)
>
>> +int pinctrl_pm_select_sleep_state(struct device *dev)
>
>> +int pinctrl_pm_select_idle_state(struct device *dev
On Thu, Jun 6, 2013 at 2:02 PM, Tomasz Figa wrote:
> On Thursday 06 of June 2013 13:49:38 luke.leighton wrote:
>> On Thu, Jun 6, 2013 at 1:43 PM, Tomasz Figa
> wrote:
>> > Luke,
>> >
>> > On Thursday 06 of June 2013 13:24:57 luke.leighton wrote:
>> >> On Thu, Jun 6, 2013 at 1:01 AM, Tomasz Figa
Hi,
On Fri, 7 Jun 2013 15:26:56 +0800 Peng Tao wrote:
>
> On Fri, Jun 7, 2013 at 2:28 PM, Stephen Rothwell
> wrote:
> >
> > After merging the akpm tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > In file included from
> > drivers/staging/lustre/include/linux/l
Hi Ferruh,
On Tue, Jun 4, 2013 at 11:34 AM, Ferruh Yigit wrote:
> This driver is for Cypress TrueTouch(tm) Standard Product controllers,
> Generation4 devices.
>
> This is third version of submission code, modifications:
> - code re-structured to match with existing Generation3 driver code.
> - c
luke.leighton wrote:
On Thu, Jun 6, 2013 at 1:51 PM, Vladimir Pantelic wrote:
4 days? WTF? since when did setting an ultimatum to the kernel
community work?
i was only informed of the opportunity 2 days ago, vladimir. this is
an important meeting. of course the linux kernel community is
On Fri, 2013-06-07 at 01:27 -0600, Daniel Hamacher wrote:
> checkpatch provided a warning on line 38. It recommended seq_puts instead of
> seq_printf.
> Since the return value of printf is ignored, I decided to switch to the
> seq_puts
> function since it is just regular character output.
> sourc
On Thu, Jun 6, 2013 at 1:21 PM, Lee Jones wrote:
> Somehow, probably due to a merge error the call to u8500_of_init_devices()
> has re-appeared in next, causing this error:
>
> arch/arm/mach-ux500/cpu-db8500.c: In function ‘u8500_init_machine’:
> arch/arm/mach-ux500/cpu-db8500.c:268:2: error: imp
On Thu, Jun 06, 2013 at 10:08:28AM -0700, Guenter Roeck wrote:
> On Thu, Jun 06, 2013 at 03:00:55PM +0200, Johannes Thumshirn wrote:
> > On Thu, Jun 06, 2013 at 04:31:10AM -0700, Guenter Roeck wrote:
> > > On Thu, Jun 06, 2013 at 12:51:03PM +0200, Johannes Thumshirn wrote:
> > > > On Mon, Jun 03, 2
On Fri, Jun 07, 2013 at 09:28:32AM +0200, Hector Palacios wrote:
> I wasn't sure that everybody involved agreed with the patch.
> @Juergen, would the patch break your platform?
> Additionally, the guys from Crystalfontz didn't comment on it, but
> their platform is also using a 18bit data bus width
On Thu, Jun 6, 2013 at 1:51 PM, Vladimir Pantelic wrote:
> 4 days? WTF? since when did setting an ultimatum to the kernel
> community work?
i was only informed of the opportunity 2 days ago, vladimir. this is
an important meeting. of course the linux kernel community is
entirely free to:
* c
On Thu, Jun 6, 2013 at 4:44 PM, Heiko Stübner wrote:
> There exist controllers that don't support to set the pull to up or down
> separately but instead automatically set the pull direction based on
> embedded knowledge inside the controller, for example depending on the
> selected mux function o
Apply now for your cheap loan at 2% percent interest rate. Provide the details
below if interested:
Name:
Loan Amount:
Duration:
Phone Number:
Country:
Best regards.
COMMERCIAL FINANCE LOAN
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to maj
checkpatch provided a warning on line 38. It recommended seq_puts instead of
seq_printf.
Since the return value of printf is ignored, I decided to switch to the seq_puts
function since it is just regular character output.
source:: http://lwn.net/Articles/22355/
I also added braces on a for loop,
Hi Hector,
On 07.06.2013 09:28, Hector Palacios wrote:
> On 06/07/2013 09:21 AM, maxime.rip...@free-electrons.com wrote:
>> Hi Hector,
>>
>> On Fri, May 24, 2013 at 03:33:19PM +0200, Juergen Beisert wrote:
>>> Someone told me, Qt5 cannot handle this special RGB666 mode (even not the
>>> def_rgb666
On Fri, Jun 07, 2013 at 09:02:43AM +0200, Steffen Klassert wrote:
> On Thu, Jun 06, 2013 at 08:55:49PM +0800, Fengguang Wu wrote:
> > Greetings,
> >
> > I got the below dmesg and the first bad commit is
> >
> > commit 4c4d41f200db375b2d2cc6d0a1de0606c8266398
> > Author: Fan Du
> > Date: Thu Ju
Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are
smaller than 'unsigned long' cfs_rq->load.weight. We don't need u64
vaiables to describe them. unsigned long is more efficient and convenience.
Signed-off-by: Alex Shi
---
kernel/sched/debug.c | 4 ++--
kernel/sched/sched.h
A framebuffer of this format is set up by SHIELD's bootloader.
Signed-off-by: Alexandre Courbot
Acked-by: Olof Johansson
---
Changes from v2:
- Fixed typo in format (Thanks Alexander van Heukelum!)
Changes from v1:
- Added description to motivate the change
- Added ack
Documentation/devicetre
There are some 64 bits variables in cfs_rq/tg etc. That ask expersive
operations in 32 bit machine. But in fact, long type is enough for them.
So do this change lead more efficient code and without data lose.
Regards
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Like as runnable_load_avg, blocked_load_avg variable, long type is
enough for removed_load in 64 bit or 32 bit machine.
Then we avoid the expensive atomic64 operations on 32 bit machine.
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 10 ++
kernel/sched/sched.h | 3 ++-
2 files cha
Since tg->load_avg is smaller than tg->load_weight, we don't need a
atomic64_t variable for load_avg in 32 bit machine.
The same reason for cfs_rq->tg_load_contrib.
The atomic_long_t/unsigned long variable type are more efficient and
convenience for them.
Signed-off-by: Alex Shi
---
kernel/sche
Since no one use it.
Signed-off-by: Alex Shi
---
kernel/sched/sched.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 874731f..09e2719 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -148,7 +148,6 @@ struct task_group {
Hi Maxime,
On 06/07/2013 09:21 AM, maxime.rip...@free-electrons.com wrote:
Hi Hector,
On Fri, May 24, 2013 at 03:33:19PM +0200, Juergen Beisert wrote:
Someone told me, Qt5 cannot handle this special RGB666 mode (even not the
def_rgb666_shift memory layout mentioned above). My test are based on
On 06/07/2013 04:22 PM, Alexander van Heukelum wrote:
static struct simplefb_format simplefb_formats[] = {
{ "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
+ { "a8b8g8r8", 32, {0, 8}, {8, 8}, {16, 8}, {31, 8} },
Hi,
31? I assume in practice this doesn't influence anything, bu
checkpatch provided a warning on line 38. It recommended seq_puts instead of
seq_printf.
Since the return value of printf is ignored, I decided to switch to the seq_puts
function since it is just regular character output.
source:: http://lwn.net/Articles/22355/
I also added braces on a for loop,
On Fri, Jun 7, 2013 at 2:28 PM, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from
> drivers/staging/lustre/include/linux/libcfs/linux/libcfs.h:49:0,
> from drivers/sta
On Thu, Jun 6, 2013 at 8:02 PM, Dave Martin wrote:
>> +static int __attribute__((used)) __tegra_smc_stack[10];
>
> Use __used instead of using GCC attributes directly.
>
>> +
>> +/*
>> + * With EABI, subtype and arg already end up in r0, r1 and r2 as they are
>> + * function arguments, but we pre
The following 2 variables only used under CONFIG_SMP, so better to move
their definiation into CONFIG_SMP too.
atomic64_t load_avg;
atomic_t runnable_avg;
Signed-off-by: Alex Shi
---
kernel/sched/sched.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/sched/sched.h
On Thu, Jun 06, 2013 at 08:55:49PM +0800, Fengguang Wu wrote:
> Greetings,
>
> I got the below dmesg and the first bad commit is
>
> commit 4c4d41f200db375b2d2cc6d0a1de0606c8266398
> Author: Fan Du
> Date: Thu Jun 6 10:15:54 2013 +0800
>
> xfrm: add LINUX_MIB_XFRMACQUIREERROR statistic co
There are div64_long() to handle the s64/long division. But no
macro do u64/ul division in kernel.
It is necessary on some scenarios. So add this macro. And fixed
the coding style error.
Signed-off-by: Alex Shi
---
include/linux/math64.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-
To get the latest runnable info, we need do this cpuload update after
task_tick.
Signed-off-by: Alex Shi
---
kernel/sched/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 6f226c2..05176b8 100644
--- a/kernel/sched/core.c
+
On Fri, Jun 7, 2013, at 8:01, Alexandre Courbot wrote:
> A framebuffer of this format is set up by SHIELD's bootloader. This
> allows us to use it as a framebuffer console.
>
> Signed-off-by: Alexandre Courbot
> Acked-by: Olof Johansson
> ---
> Changes from v1:
> - Added description to motivate
blocked_load_avg sometime is too heavy and far bigger than runnable load
avg, that make balance make wrong decision. So remove it.
Changlong tested this patch, found ltp cgroup stress testing get better
performance: https://lkml.org/lkml/2013/5/23/65
---
3.10-rc1 patch1-7 patch1-8
Except using runnable load average in background, move_tasks is also
the key functions in load balance. We need consider the runnable load
average in it in order to the apple to apple load comparison.
Morten had caught a div u64 bug on ARM, thanks!
Signed-off-by: Alex Shi
---
kernel/sched/fair.
They are the base values in load balance, update them with rq runnable
load average, then the load balance will consider runnable load avg
naturally.
We also try to include the blocked_load_avg as cpu load in balancing,
but that cause kbuild performance drop 6% on every Intel machine, and
aim7/olt
Peter&Ingo:
v8: add a marco div64_ul and used it in task_h_load()
v7: rebasing on tip/sched/core tree.
I tested on Intel core2, NHM, SNB, IVB, 2 and 4 sockets machines with
benchmark kbuild, aim7, dbench, tbench, hackbench, oltp, and netperf
loopback etc.
On SNB EP 4 sockets machine, the hackbe
Remove CONFIG_FAIR_GROUP_SCHED that covers the runnable info, then
we can use runnable load variables.
Signed-off-by: Alex Shi
---
include/linux/sched.h | 7 +--
kernel/sched/core.c | 7 +--
kernel/sched/fair.c | 13 ++---
kernel/sched/sched.h | 10 ++
4 files chan
We need initialize the se.avg.{decay_count, load_avg_contrib} for a
new forked task.
Otherwise random values of above variables cause mess when do new task
enqueue:
enqueue_task_fair
enqueue_entity
enqueue_entity_load_avg
and make forking balancing imbalance since incorrect
The wakeuped migrated task will __synchronize_entity_decay(se); in
migrate_task_fair, then it needs to set
`se->avg.last_runnable_update -= (-se->avg.decay_count) << 20'
before update_entity_load_avg, in order to avoid slept time is updated
twice for se.avg.load_avg_contrib in both __syncchronize a
Hi Hector,
On Fri, May 24, 2013 at 03:33:19PM +0200, Juergen Beisert wrote:
> Someone told me, Qt5 cannot handle this special RGB666 mode (even not the
> def_rgb666_shift memory layout mentioned above). My test are based on Qt4.
> Qt5 needs a regular RGB888 mode, which should silently be convert
On Thu, Jun 6, 2013 at 9:26 PM, Jassi Brar wrote:
> On Thu, Jun 6, 2013 at 12:58 PM, Alexandre Courbot
> wrote:
>> Boot loaders on some Tegra devices can be unlocked but do not let the
>> system operate without SecureOS. SecureOS prevents access to some
>> registers and requires the operating sy
On Wed, Jun 5, 2013 at 3:58 PM, Andy Shevchenko
wrote:
> To support some (legacy) firmwares and platforms let's make life easier for
> their customers.
>
> This patch extracts SFI GPIO API from arch/x86/platform/mrst/mrst.c.
>
> Signed-off-by: Andy Shevchenko
> Acked-by: Len Brown
> Cc: Grant L
On Wed, Jun 5, 2013 at 7:22 AM, Alexandre Courbot wrote:
> FLAG_ACTIVE_LOW, on the other hand, is *only* set and used through
> sysfs operations. Independently, the active low property can be
> specified in gpio phandles and retrieved by
> of_get_(named_)gpio_flags() - only it has to be kept in a
701 - 749 of 749 matches
Mail list logo
