Re: CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)

2012-09-11 Thread Daniel Lezcano 
On 09/11/2012 02:18 AM, John Stultz wrote:
> On 09/10/2012 12:45 PM, Daniel Lezcano wrote:
>> On 09/10/2012 07:14 PM, John Stultz wrote:
>>> In the meantime, I'll try to reproduce on my T61. If you could send me
>>> your .config, I'd appreciate it.
>> http://pastebin.com/qSxqfdDK
>>
>> The header of the config file shows for a v3.5-rc7 because it is the
>> result of the git-bisect. If you keep this config file for the latest
>> kernel that should reproduce the problem.
>>
>> Let me know if you were able to reproduce the problem.
> Great! With this I was able to quickly reproduce the problem and I think
> I have a fix.

Cool !

> Would you mind testing the following patch? It seems to resolve the
> issue, but I've not yet run it through my test suite to make sure it
> didn't break anything else.

No problem, I will try it this evening.

Is this problem related to all 32bits arch ?

Thanks !

  -- Daniel

> If both your and my testing comes back ok, I'll submit it to Thomas.
> 
> thanks
> -john
> 
> From f10a285a5b532a14d3330f6e60e4d7bd5627932a Mon Sep 17 00:00:00 2001
> From: John Stultz 
> Date: Mon, 10 Sep 2012 20:00:15 -0400
> Subject: [PATCH] time: Fix timeekeping_get_ns overflow on 32bit systems
> 
> Daniel Lezcano reported seeing multi-second stalls from
> keyboard input on his T61 laptop when NOHZ and CPU_IDLE
> were enabled on a 32bit kernel.
> 
> He bisected the problem down to
> 1e75fa8be9fb61e1af46b5b3b176347a4c958ca1 (time: Condense
> timekeeper.xtime into xtime_sec).
> 
> After reproducing this issue, I narrowed the problem down
> to the fact that timekeeping_get_ns() returns a 64bit
> nsec value that hasn't been accumulated. In some cases
> this value was being then stored in timespec.tv_nsec
> (which is a long).
> 
> On 32bit systems, With idle times larger then 4 seconds
> (or less, depending on the value of xtime_nsec), the
> returned nsec value would overflow 32bits. This limited
> kept time from increasing, causing timers to not expire.
> 
> The fix is to make sure we don't directly store the
> result of timekeeping_get_ns() into a tv_nsec field,
> instead using a 64bit nsec value which can then be
> added into the timespec via timespec_add_ns().
> 
> With this patch I cannot reproduce the issue.
> 
> Cc: Ingo Molnar 
> Cc: Richard Cochran 
> Cc: Prarit Bhargava 
> Cc: Thomas Gleixner 
> Cc: Daniel Lezcano 
> Reported-and-bisected-by: Daniel Lezcano 
> Signed-off-by: John Stultz 
> ---
>  kernel/time/timekeeping.c |   19 ---
>  1 file changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index 34e5eac..d3b91e7 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -303,10 +303,11 @@ void getnstimeofday(struct timespec *ts)
>  seq = read_seqbegin(&tk->lock);
>  
>  ts->tv_sec = tk->xtime_sec;
> -ts->tv_nsec = timekeeping_get_ns(tk);
> +nsecs = timekeeping_get_ns(tk);
>  
>  } while (read_seqretry(&tk->lock, seq));
>  
> +ts->tv_nsec = 0;
>  timespec_add_ns(ts, nsecs);
>  }
>  EXPORT_SYMBOL(getnstimeofday);
> @@ -345,6 +346,7 @@ void ktime_get_ts(struct timespec *ts)
>  {
>  struct timekeeper *tk = &timekeeper;
>  struct timespec tomono;
> +s64 nsec;
>  unsigned int seq;
>  
>  WARN_ON(timekeeping_suspended);
> @@ -352,13 +354,14 @@ void ktime_get_ts(struct timespec *ts)
>  do {
>  seq = read_seqbegin(&tk->lock);
>  ts->tv_sec = tk->xtime_sec;
> -ts->tv_nsec = timekeeping_get_ns(tk);
> +nsec = timekeeping_get_ns(tk);
>  tomono = tk->wall_to_monotonic;
>  
>  } while (read_seqretry(&tk->lock, seq));
>  
> -set_normalized_timespec(ts, ts->tv_sec + tomono.tv_sec,
> -ts->tv_nsec + tomono.tv_nsec);
> +ts->tv_sec += tomono.tv_sec;
> +ts->tv_nsec = 0;
> +timespec_add_ns(ts, nsec + tomono.tv_nsec);
>  }
>  EXPORT_SYMBOL_GPL(ktime_get_ts);
>  
> @@ -1244,6 +1247,7 @@ void get_monotonic_boottime(struct timespec *ts)
>  {
>  struct timekeeper *tk = &timekeeper;
>  struct timespec tomono, sleep;
> +s64 nsec;
>  unsigned int seq;
>  
>  WARN_ON(timekeeping_suspended);
> @@ -1251,14 +1255,15 @@ void get_monotonic_boottime(struct timespec *ts)
>  do {
>  seq = read_seqbegin(&tk->lock);
>  ts->tv_sec = tk->xtime_sec;
> -ts->tv_nsec = timekeeping_get_ns(tk);
> +nsec = timekeeping_get_ns(tk);
>  tomono = tk->wall_to_monotonic;
>  sleep = tk->total_sleep_time;
>  
>  } while (read_seqretry(&tk->lock, seq));
>  
> -set_normalized_timespec(ts, ts->tv_sec + tomono.tv_sec + sleep.tv_sec,
> -ts->tv_nsec + tomono.tv_nsec + sleep.tv_nsec);
> +ts->tv_sec += tomono.tv_sec + sleep.tv_sec;
> +ts->tv_nsec = 0;
> +timespec_add_ns(ts, nsec + tomono.tv_nsec + sleep.tv_nsec);
>  }
>  EXPORT_SYMBOL_GPL(get_monotonic_boottime);
>  


-- 
  Linaro.org │ Open s

Re: [RFC PATCH v6] media: add v4l2 subdev driver for S5K4ECGX sensor

2012-09-11 Thread Sylwester Nawrocki 
On 09/10/2012 08:52 PM, Francesco Lavra wrote:
> On 09/10/2012 05:04 PM, Sylwester Nawrocki wrote:
>> On 09/09/2012 06:01 PM, Francesco Lavra wrote:
 +static int s5k4ecgx_load_firmware(struct v4l2_subdev *sd)
 +{
 +  const struct firmware *fw;
 +  int err, i, regs_num;
 +  struct i2c_client *client = v4l2_get_subdevdata(sd);
 +  u16 val;
 +  u32 addr, crc, crc_file, addr_inc = 0;
 +
 +  err = request_firmware(&fw, S5K4ECGX_FIRMWARE, sd->v4l2_dev->dev);
 +  if (err) {
 +  v4l2_err(sd, "Failed to read firmware %s\n", S5K4ECGX_FIRMWARE);
 +  return err;
 +  }
 +  regs_num = *(u32 *)(fw->data);
 +  v4l2_dbg(3, debug, sd, "FW: %s size %d register sets %d\n",
 +   S5K4ECGX_FIRMWARE, fw->size, regs_num);
 +  regs_num++; /* Add header */
 +  if (fw->size != regs_num * FW_RECORD_SIZE + FW_CRC_SIZE) {
 +  err = -EINVAL;
 +  goto fw_out;
 +  }
 +  crc_file = *(u32 *)(fw->data + regs_num * FW_RECORD_SIZE);
>>>
>>> Depending on the value of regs_num, this may result in unaligned access
>>
>> Thanks for the catch. I think it is not the only place where unaligned
>> issues are possible. Since the data records are 4-byte address + 2-byte
>> value there is also an issue with reading the address entries. Assuming
>> fw->data is aligned to at least 2-bytes (not quite sure if we can assume
>> that) there should be no problem with reading 2-byte register values.
> 
> I'm not sure 2-byte alignment can be safely assumed, either.
> 
>> We could change the data types of the register values from u16 to u32,
>> wasting some memory (there is approximately 3 000 records), so there is
>> no other data types in the file structure than u32. Or use a patch as
>> below. Not sure what's better.
> 
> I prefer the approach of your patch below, but I would use get_unaligned
> to get the 2-byte values, too. Also there are another couple of
> glitches, see below.

OK, thanks for the feedback. It was also my preference. The performance
impact seems insignificant, given a write of each record takes time of
1 ms order.

>> 8<-
>>  From a970480b99bdb74e2bf48e1a321724231e6516a0 Mon Sep 17 00:00:00 2001
>> From: Sylwester Nawrocki
>> Date: Sun, 9 Sep 2012 19:56:31 +0200
>> Subject: [PATCH] s5k4ecgx: Fix unaligned access issues
>>
>> Signed-off-by: Sylwester Nawrocki
>> ---
>>   drivers/media/i2c/s5k4ecgx.c |   16 
>>   1 files changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/media/i2c/s5k4ecgx.c b/drivers/media/i2c/s5k4ecgx.c
>> index 0ef0b7d..4c6439a 100644
>> --- a/drivers/media/i2c/s5k4ecgx.c
>> +++ b/drivers/media/i2c/s5k4ecgx.c
>> @@ -24,6 +24,7 @@
>>   #include
>>   #include
>>   #include
>> +#include
>>
>>   #include
>>   #include
>> @@ -331,6 +332,7 @@ static int s5k4ecgx_load_firmware(struct v4l2_subdev *sd)
>>  const struct firmware *fw;
>>  int err, i, regs_num;
>>  u32 addr, crc, crc_file, addr_inc = 0;
>> +const u8 *ptr;
>>  u16 val;
>>
>>  err = request_firmware(&fw, S5K4ECGX_FIRMWARE, sd->v4l2_dev->dev);
>> @@ -338,7 +340,7 @@ static int s5k4ecgx_load_firmware(struct v4l2_subdev *sd)
>>  v4l2_err(sd, "Failed to read firmware %s\n", S5K4ECGX_FIRMWARE);
>>  return err;
>>  }
>> -regs_num = le32_to_cpu(*(u32 *)fw->data);
>> +regs_num = le32_to_cpu(get_unaligned((__le32 *)fw->data));
>>
>>  v4l2_dbg(3, debug, sd, "FW: %s size %d register sets %d\n",
>>   S5K4ECGX_FIRMWARE, fw->size, regs_num);
>> @@ -349,7 +351,8 @@ static int s5k4ecgx_load_firmware(struct v4l2_subdev *sd)
>>  goto fw_out;
>>  }
>>
>> -crc_file = *(u32 *)(fw->data + regs_num * FW_RECORD_SIZE);
>> +memcpy(&crc_file, fw->data + regs_num * FW_RECORD_SIZE, sizeof(u32));
> 
> crc_file should be converted from little endian to native endian.

Right, I should have verified that crc32_le() return value is in native
endianness.

>> +
>>  crc = crc32_le(~0, fw->data, regs_num * FW_RECORD_SIZE);
>>  if (crc != crc_file) {
>>  v4l2_err(sd, "FW: invalid crc (%#x:%#x)\n", crc, crc_file);
>> @@ -357,9 +360,14 @@ static int s5k4ecgx_load_firmware(struct v4l2_subdev 
>> *sd)
>>  goto fw_out;
>>  }
>>
>> +ptr = fw->data + FW_RECORD_SIZE;
>> +
>>  for (i = 1; i<  regs_num; i++) {
>> -addr = le32_to_cpu(*(u32 *)(fw->data + i * FW_RECORD_SIZE));
>> -val = le16_to_cpu(*(u16 *)(fw->data + i * FW_RECORD_SIZE + 4));
>> +addr = le32_to_cpu(get_unaligned((__le32 *)ptr));
>> +ptr += 4;
>> +val = le16_to_cpu(*(__le16 *)ptr);
>> +ptr += FW_RECORD_SIZE;
> 
> ptr is being incremented by (4 + FW_RECORD_SIZE) bytes at each iteration.

Oops, I was to quick in sending that patch out. Indeed, that's wrong.
Sangwook, FWIW, I just pushed the corrected patch to my tree
(htt

Re: mfd: Implement devicetree support for AB8500 Btemp

2012-09-11 Thread Rajanikanth HV 

On Monday 10 September 2012 07:31 PM, Arnd Bergmann wrote:
> On Monday 10 September 2012, Rajanikanth HV wrote:
>> +
>> +supplied-to:
>> +   This is a logical binding w.r.t power supply event change
>> +   across energy-management-module drivers where in the
>> +   runtime battery properties are shared along with uevent
>> +   notification.
>> +   ref: di->btemp_psy.external_power_changed =
>> +   ab8500_btemp_external_power_changed;
>> +   ab8500_btemp.c
>> +
>> +   Need for this property:
>> +   btemp, fg and charger updates power-supply properties
>> +   based on the events listed above.
>> +   Event handler invokes power supply change notifier
>> +   which in-turn invokes registered power supply class call-back
>> +   based on the 'supplied_to' string.
>> +   ref:
>> +   power_supply_changed_work(..) 
>> ./drivers/power/power_supply_core.c
>> +
>> +   example:
>> +   ab8500-btemp {
>> +   /* Other enery management module */
>> +   supplied-to = "ab8500_chargalg", "ab8500_fg";
>> +   num_supplicants = <2>;
>> +   };
>> +
> This looks like you're doing things the opposite way from everyone else.
> Normally, each device uses phandles to refer to other objects it depends
> on (gpio lines, regulators, clocks, interrupts, ...), rather than listing
> things that depend on it.
>
> Can you turn this around to be more like the others?
We discussed about this on : "13 July 2012 17:05", pasting from that
mail thread.

>> +Supplied-to:
>> + This shall be power supply class dependency where in the
runtime battery
>> + properties will be shared across fuel guage and charging
algorithm driver.
>
> I probably don't understand enough of this, but shouldn't the other
devices
> that are supplied by this have a reference to this node rather than doing
> it this way around? Why use strings here instead of phandles?

This is a logical binding w.r.t power supply event change
across energy-management-module drivers where in runtime battery
properties are shared along with uevent notification.
ref: di->btemp_psy.external_power_
changed =
 ab8500_btemp_external_power_changed;
 ref: ab8500_btemp.c

Need for this property:
 btemp, fg and charger updates power-supply properties
 based on the events listed above.
 Event handler invokes power supply change notifier
 which in-turn invokes registered power supply class call-back
 based on the 'supplied_to' string.
 ref:
   power_supply_changed_work(..) ./drivers/power/power_supply_core.c

In this case how to approach through phandle?


>
> Note also that device tree identifiers should use '-' as a word separator,
> not '_', and that a binding document should specify the exact set of
> possible values. If the properties contain strings, please list every
> valid string.
>
>> +   thermister-internal-to-battery = <1>;
>> +   li_ion_9100_battery = <0>;
> Boolean properties should be empty when enabled and not present when
> disabled. In this example, one would just write
>
>   thermister-internal-to-battery;
>
>
>   Arnd

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [RFC PATCH v6] media: add v4l2 subdev driver for S5K4ECGX sensor

2012-09-11 Thread Sangwook Lee 
Hi  Francesco

Thanks for your advice.

@ Sylwester
Thanks for your nice patch, and I will squash  and then send it again.


Thanks
Sangwook


On 10 September 2012 21:29, Sylwester Nawrocki
 wrote:
> On 09/10/2012 08:52 PM, Francesco Lavra wrote:
>> On 09/10/2012 05:04 PM, Sylwester Nawrocki wrote:
>>> On 09/09/2012 06:01 PM, Francesco Lavra wrote:
> +static int s5k4ecgx_load_firmware(struct v4l2_subdev *sd)
> +{
> +  const struct firmware *fw;
> +  int err, i, regs_num;
> +  struct i2c_client *client = v4l2_get_subdevdata(sd);
> +  u16 val;
> +  u32 addr, crc, crc_file, addr_inc = 0;
> +
> +  err = request_firmware(&fw, S5K4ECGX_FIRMWARE, sd->v4l2_dev->dev);
> +  if (err) {
> +  v4l2_err(sd, "Failed to read firmware %s\n", 
> S5K4ECGX_FIRMWARE);
> +  return err;
> +  }
> +  regs_num = *(u32 *)(fw->data);
> +  v4l2_dbg(3, debug, sd, "FW: %s size %d register sets %d\n",
> +   S5K4ECGX_FIRMWARE, fw->size, regs_num);
> +  regs_num++; /* Add header */
> +  if (fw->size != regs_num * FW_RECORD_SIZE + FW_CRC_SIZE) {
> +  err = -EINVAL;
> +  goto fw_out;
> +  }
> +  crc_file = *(u32 *)(fw->data + regs_num * FW_RECORD_SIZE);

 Depending on the value of regs_num, this may result in unaligned access
>>>
>>> Thanks for the catch. I think it is not the only place where unaligned
>>> issues are possible. Since the data records are 4-byte address + 2-byte
>>> value there is also an issue with reading the address entries. Assuming
>>> fw->data is aligned to at least 2-bytes (not quite sure if we can assume
>>> that) there should be no problem with reading 2-byte register values.
>>
>> I'm not sure 2-byte alignment can be safely assumed, either.
>>
>>> We could change the data types of the register values from u16 to u32,
>>> wasting some memory (there is approximately 3 000 records), so there is
>>> no other data types in the file structure than u32. Or use a patch as
>>> below. Not sure what's better.
>>
>> I prefer the approach of your patch below, but I would use get_unaligned
>> to get the 2-byte values, too. Also there are another couple of
>> glitches, see below.
>
> OK, thanks for the feedback. It was also my preference. The performance
> impact seems insignificant, given a write of each record takes time of
> 1 ms order.
>
>>> 8<-
>>>  From a970480b99bdb74e2bf48e1a321724231e6516a0 Mon Sep 17 00:00:00 2001
>>> From: Sylwester Nawrocki
>>> Date: Sun, 9 Sep 2012 19:56:31 +0200
>>> Subject: [PATCH] s5k4ecgx: Fix unaligned access issues
>>>
>>> Signed-off-by: Sylwester Nawrocki
>>> ---
>>>   drivers/media/i2c/s5k4ecgx.c |   16 
>>>   1 files changed, 12 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/media/i2c/s5k4ecgx.c b/drivers/media/i2c/s5k4ecgx.c
>>> index 0ef0b7d..4c6439a 100644
>>> --- a/drivers/media/i2c/s5k4ecgx.c
>>> +++ b/drivers/media/i2c/s5k4ecgx.c
>>> @@ -24,6 +24,7 @@
>>>   #include
>>>   #include
>>>   #include
>>> +#include
>>>
>>>   #include
>>>   #include
>>> @@ -331,6 +332,7 @@ static int s5k4ecgx_load_firmware(struct v4l2_subdev 
>>> *sd)
>>>  const struct firmware *fw;
>>>  int err, i, regs_num;
>>>  u32 addr, crc, crc_file, addr_inc = 0;
>>> +const u8 *ptr;
>>>  u16 val;
>>>
>>>  err = request_firmware(&fw, S5K4ECGX_FIRMWARE, sd->v4l2_dev->dev);
>>> @@ -338,7 +340,7 @@ static int s5k4ecgx_load_firmware(struct v4l2_subdev 
>>> *sd)
>>>  v4l2_err(sd, "Failed to read firmware %s\n", 
>>> S5K4ECGX_FIRMWARE);
>>>  return err;
>>>  }
>>> -regs_num = le32_to_cpu(*(u32 *)fw->data);
>>> +regs_num = le32_to_cpu(get_unaligned((__le32 *)fw->data));
>>>
>>>  v4l2_dbg(3, debug, sd, "FW: %s size %d register sets %d\n",
>>>   S5K4ECGX_FIRMWARE, fw->size, regs_num);
>>> @@ -349,7 +351,8 @@ static int s5k4ecgx_load_firmware(struct v4l2_subdev 
>>> *sd)
>>>  goto fw_out;
>>>  }
>>>
>>> -crc_file = *(u32 *)(fw->data + regs_num * FW_RECORD_SIZE);
>>> +memcpy(&crc_file, fw->data + regs_num * FW_RECORD_SIZE, sizeof(u32));
>>
>> crc_file should be converted from little endian to native endian.
>
> Right, I should have verified that crc32_le() return value is in native
> endianness.
>
>>> +
>>>  crc = crc32_le(~0, fw->data, regs_num * FW_RECORD_SIZE);
>>>  if (crc != crc_file) {
>>>  v4l2_err(sd, "FW: invalid crc (%#x:%#x)\n", crc, crc_file);
>>> @@ -357,9 +360,14 @@ static int s5k4ecgx_load_firmware(struct v4l2_subdev 
>>> *sd)
>>>  goto fw_out;
>>>  }
>>>
>>> +ptr = fw->data + FW_RECORD_SIZE;
>>> +
>>>  for (i = 1; i<  regs_num; i++) {
>>> -addr = le32_to_cpu(*(u32 *)(fw->data + i * FW_RECORD_SIZE));
>>> -val = le16_to_cpu(*(u16 *)(fw->data + i * FW_RECORD_SIZE + 4));
>>> +addr = le32_to_cpu(get_unaligned((__le

Re: [PATCH 1/6] acpi : move the acpi_idle_driver variable declaration

2012-09-11 Thread Daniel Lezcano 
On 09/07/2012 11:19 PM, Rafael J. Wysocki wrote:
> On Friday, September 07, 2012, Daniel Lezcano wrote:
>> This variable is only used in the in processor_driver.c.
>> This patch reduces the scope of the variable by moving it
>> to this file.
> 
> Well, the changelog is wrong (because the scope of the variable is
> not reduced by moving it out of the header) and I don't see the point.

Yes, you are right.

> Is there any _real_ problem with that definition in processor.h?

It is not a real problem. There is no issue fixed by this patch.
It is just reorganizing the code little by little. The intent is to
group what is related to cpuidle to the C files here processor_driver.c.


>> Signed-off-by: Daniel Lezcano 
>> Acked-by: Peter De Schrijver 
>> Tested-by: Peter De Schrijver 
>> ---
>>  drivers/acpi/processor_driver.c |2 +-
>>  include/acpi/processor.h|1 -
>>  2 files changed, 1 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/acpi/processor_driver.c 
>> b/drivers/acpi/processor_driver.c
>> index bfc31cb..e1f6330 100644
>> --- a/drivers/acpi/processor_driver.c
>> +++ b/drivers/acpi/processor_driver.c
>> @@ -113,7 +113,7 @@ static struct acpi_driver acpi_processor_driver = {
>>  
>>  DEFINE_PER_CPU(struct acpi_processor *, processors);
>>  EXPORT_PER_CPU_SYMBOL(processors);
>> -
>> +extern struct cpuidle_driver acpi_idle_driver;
>>  struct acpi_processor_errata errata __read_mostly;
>>  
>>  /* 
>> --
>> diff --git a/include/acpi/processor.h b/include/acpi/processor.h
>> index db427fa..8b2c39a 100644
>> --- a/include/acpi/processor.h
>> +++ b/include/acpi/processor.h
>> @@ -332,7 +332,6 @@ int acpi_processor_power_exit(struct acpi_processor *pr,
>>struct acpi_device *device);
>>  int acpi_processor_suspend(struct device *dev);
>>  int acpi_processor_resume(struct device *dev);
>> -extern struct cpuidle_driver acpi_idle_driver;
>>  
>>  /* in processor_thermal.c */
>>  int acpi_processor_get_limit_info(struct acpi_processor *pr);
>>
> 


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: mfd: Implement devicetree support for AB8500 Btemp

2012-09-11 Thread Arnd Bergmann 
On Tuesday 11 September 2012, Rajanikanth HV wrote:
> >> +Supplied-to:
> >> + This shall be power supply class dependency where in the
> runtime battery
> >> + properties will be shared across fuel guage and charging
> algorithm driver.
> >
> > I probably don't understand enough of this, but shouldn't the other
> devices
> > that are supplied by this have a reference to this node rather than doing
> > it this way around? Why use strings here instead of phandles?
> 
> This is a logical binding w.r.t power supply event change
> across energy-management-module drivers where in runtime battery
> properties are shared along with uevent notification.
> ref: di->btemp_psy.external_power_
> changed =
>  ab8500_btemp_external_power_changed;
>  ref: ab8500_btemp.c
> 
> Need for this property:
>  btemp, fg and charger updates power-supply properties
>  based on the events listed above.
>  Event handler invokes power supply change notifier
>  which in-turn invokes registered power supply class call-back
>  based on the 'supplied_to' string.
>  ref:
>power_supply_changed_work(..) ./drivers/power/power_supply_core.c
> 
> In this case how to approach through phandle?
> 
> 

Sorry, I really tried, but I cannot make sense of what you wrote
there. Can you try again and describe in full English sentences
how the hardware blocks are connected and what their purpose is?

Arnd

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 2/6] acpi : move cpuidle_device field out of the acpi_processor_power structure

2012-09-11 Thread Daniel Lezcano 
On 09/08/2012 12:06 AM, Rafael J. Wysocki wrote:
> On Friday, September 07, 2012, Rafael J. Wysocki wrote:
>> On Friday, September 07, 2012, Rafael J. Wysocki wrote:
>>> On Friday, September 07, 2012, Daniel Lezcano wrote:
 Currently we have the cpuidle_device field in the acpi_processor_power 
 structure.
 This adds a dependency in processor.h for cpuidle.h.

 In order to be consistent with the rest of the drivers and for the per cpu 
 states
 coming right after this patch, this one move out of the 
 acpi_processor_power
 structure the cpuidle_device field.

 Signed-off-by: Daniel Lezcano 
 Acked-by: Peter De Schrijver 
 Tested-by: Peter De Schrijver 
 ---
  drivers/acpi/processor_idle.c |   25 ++---
  include/acpi/processor.h  |2 --
  2 files changed, 18 insertions(+), 9 deletions(-)

 diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
 index de89624..084b1d2 100644
 --- a/drivers/acpi/processor_idle.c
 +++ b/drivers/acpi/processor_idle.c
 @@ -79,6 +79,8 @@ module_param(bm_check_disable, uint, );
  static unsigned int latency_factor __read_mostly = 2;
  module_param(latency_factor, uint, 0644);
  
 +static DEFINE_PER_CPU(struct cpuidle_device, acpi_cpuidle_device);
 +
>>>
>>> Well.  Why are you moving that thing into the percpu memory?  It doesn't
>>> have to be per-CPU and storing it there just wastes the room.
>>
>> Sorry, it is per-CPU already, scratch that.
> 
> Well, no, it isn't.  So I was right originally (boy, that code _is_ 
> confusing).
> 
> So originally you had per-CPU pointers called 'processors' that each pointed
> to a struct acpi_processor object created by acpi_processor_add() in slab
> memory.  Your patch doesn't touch those pointers, so they are still there.

Yes, the purpose of this patch is the same as the other patches which is
separate the cpuidle code from the rest of the acpi code. It is part of
the cleanup.

> In addition to them it creates a number of static per-CPU objects that
> previously were stored in those struct acpi_processor object mentioned above.
> These things need not be stored in percpu memory.

Agreed, this patch makes the cpuidle driver to consume more per cpu
memory. Is it acceptable to create a per cpu pointer for the cpuidle
devices which will be allocated in the processor_driver init function
like the intel_idle driver ? We keep the same memory consumption while
we are moving the cpuidle specific code the C file.

By the way, most of the cpuidle drivers for ARM are defining a static
cpuidle device structure per cpu. I guess your remark for acpi applies
to them too. Not easy to make all these drivers to converge to the same
code scheme ...

Thanks
  -- Daniel

-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 0/2] Android fixes w.r.t. 3.6 kernel

2012-09-11 Thread Andrey Konovalov 

On 09/11/2012 10:19 AM, John Stultz wrote:

On 09/10/2012 10:22 PM, Tushar Behera wrote:

Ping !!!

On 08/31/2012 09:57 AM, Tushar Behera wrote:

Required for android-3.6 tree.

Tushar Behera (2):
   netfilter: xt_quota2: Move away from NLMSG_PUT()
   netfilter: xt_quota2: Update parameter list in netlink_kernel_create

  net/netfilter/xt_quota2.c |   25 -
  1 files changed, 16 insertions(+), 9 deletions(-)


Without these patches, build of LT kernel based on llct(v3.6-rc5) fails
with following error message.


Thanks for the reminder, the patches landed in my mailbox during Linux
Plumbers, and got buried under a number of other items.
So my apologies. I've applied them and pushed them out to the
linaro-android-3.6-jstultz-rebase branch.


Merged into the linux-linaro-core-tracking branch, the llct-20120911.0 tag.

Thanks,
Andrey


thanks
-john


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev



___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)

2012-09-11 Thread John Stultz 

On 09/10/2012 11:58 PM, Daniel Lezcano wrote:

Would you mind testing the following patch? It seems to resolve the
issue, but I've not yet run it through my test suite to make sure it
didn't break anything else.

No problem, I will try it this evening.

Is this problem related to all 32bits arch ?
I believe so. Although it didn't appear in my 32bit testing w/ kvm, but 
I suspect that is due to my distro userland setting lots of timers so 
that we don't hit those multi-second idle times, which could overflow 
32bit nanoseconds, or maybe some other kvm quirk.


Anyway, let me know if your testing goes well.

Thanks so much again for noticing and bisecting this down.
-john


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Linaro Release 12.08 Postmortem Summary

2012-09-11 Thread David Zinman 
Postmortem and lessons learned for Linaro's release 2012.08

https://wiki.linaro.org/Cycles/1208/Release/Review


Highlights and Key Successes

Linaro also held its first Virtual Connect event on 13 - 17 August,
2012. This online event used Google+ Hangouts on Air and was streamed
and recorded via YouTube. Members of the various Linaro Teams provided
informative, educational and exciting sessions that allowed for public
viewing and participation.

http://plus.google.com/u/0/b/112814496864921562564/116754366033915823792/posts

The Android team created stable Jelly Bean builds from AOSP and an
Android benchmarking platform to automate many of the tests in the
AOSP codebase.

The Developer Platform Team announced USB Host enablement is now
available in LAVA and that all packaged linux-linaro kernels are now
cross-compiled and boot tested via LAVA before they are uploaded to
Linaro Overlay PPA. Additionally, U-Boot-Linaro is now based on the
latest upstream release--v2012.07.


Postmortem and Lessons Learned
==

This cycle was fairly low key: lots of people were out for vacations
and many others were attending external conferences such as Linux
Plumbers.

One issue of concern was the deployment of an infrastructure project
on the last week before release.
A the new django application was deployed on snapshots.linaro.org that
disrupted several builds on the Friday before the release. The issues
took one week to resolve.
The issues are:
 - The deployment was not communicated and broadcast properly
 - Build maintainers were not given proper warning
 - deploying new functional software on a Friday with no one
   available on the weekend for emergency
 - deploying during a release week
A big "thank you" is in order for Georgy Redkozubov (gesha) for his
help and availability in troubleshooting and getting it fixed.

An incident report has been filed here:
  
https://wiki.linaro.org/Internal/Process/DealingWithCrisis/IncidentReports/2012-08-24-Django-installation-disrupts-release


Blueprints
=
The number of high or essential priority blueprints that missed the cycle:
Android 3 out of 13
Developer Platform  0 out of 3
Infrastructure  1 out of 6
Lava2 out of 4

Total 6 out of 26

23% of high or essential priority blueprints scheduled for this cycle
were not delivered.

Total blueprints: 14 out of 49 missed the cycle.

High priority missed blueprints recap:
12.05: 19 out of 48, 39%
12.06: 13 out of 31, 42%
12.07: 14 out of 31, 45%
12.08: 6 out of 26, 23%

* Not included is data from working groups and landing teams

Source: 
https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AjEaTwrvj1bidGhNZHF0V2NjY2lOdEh6OG1OQk5oZEE#gid=5

-- 
David Zinman
Linaro Release Manager | Project Manager
Linaro.org | Open source software for ARM SoCs

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 1/6] acpi : move the acpi_idle_driver variable declaration

2012-09-11 Thread Rafael J. Wysocki 
On Tuesday, September 11, 2012, Daniel Lezcano wrote:
> On 09/07/2012 11:19 PM, Rafael J. Wysocki wrote:
> > On Friday, September 07, 2012, Daniel Lezcano wrote:
> >> This variable is only used in the in processor_driver.c.
> >> This patch reduces the scope of the variable by moving it
> >> to this file.
> > 
> > Well, the changelog is wrong (because the scope of the variable is
> > not reduced by moving it out of the header) and I don't see the point.
> 
> Yes, you are right.
> 
> > Is there any _real_ problem with that definition in processor.h?
> 
> It is not a real problem. There is no issue fixed by this patch.
> It is just reorganizing the code little by little. The intent is to
> group what is related to cpuidle to the C files here processor_driver.c.

However, it is not recommended to put "extern something" type of declarations
into *.c files.  All of them should go into headers (although not necessarily
in include/linux for that matter).

Thanks,
Rafael

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 2/6] acpi : move cpuidle_device field out of the acpi_processor_power structure

2012-09-11 Thread Rafael J. Wysocki 
On Tuesday, September 11, 2012, Daniel Lezcano wrote:
> On 09/08/2012 12:06 AM, Rafael J. Wysocki wrote:
> > On Friday, September 07, 2012, Rafael J. Wysocki wrote:
> >> On Friday, September 07, 2012, Rafael J. Wysocki wrote:
> >>> On Friday, September 07, 2012, Daniel Lezcano wrote:
>  Currently we have the cpuidle_device field in the acpi_processor_power 
>  structure.
>  This adds a dependency in processor.h for cpuidle.h.
> 
>  In order to be consistent with the rest of the drivers and for the per 
>  cpu states
>  coming right after this patch, this one move out of the 
>  acpi_processor_power
>  structure the cpuidle_device field.
> 
>  Signed-off-by: Daniel Lezcano 
>  Acked-by: Peter De Schrijver 
>  Tested-by: Peter De Schrijver 
>  ---
>   drivers/acpi/processor_idle.c |   25 ++---
>   include/acpi/processor.h  |2 --
>   2 files changed, 18 insertions(+), 9 deletions(-)
> 
>  diff --git a/drivers/acpi/processor_idle.c 
>  b/drivers/acpi/processor_idle.c
>  index de89624..084b1d2 100644
>  --- a/drivers/acpi/processor_idle.c
>  +++ b/drivers/acpi/processor_idle.c
>  @@ -79,6 +79,8 @@ module_param(bm_check_disable, uint, );
>   static unsigned int latency_factor __read_mostly = 2;
>   module_param(latency_factor, uint, 0644);
>   
>  +static DEFINE_PER_CPU(struct cpuidle_device, acpi_cpuidle_device);
>  +
> >>>
> >>> Well.  Why are you moving that thing into the percpu memory?  It doesn't
> >>> have to be per-CPU and storing it there just wastes the room.
> >>
> >> Sorry, it is per-CPU already, scratch that.
> > 
> > Well, no, it isn't.  So I was right originally (boy, that code _is_ 
> > confusing).
> > 
> > So originally you had per-CPU pointers called 'processors' that each pointed
> > to a struct acpi_processor object created by acpi_processor_add() in slab
> > memory.  Your patch doesn't touch those pointers, so they are still there.
> 
> Yes, the purpose of this patch is the same as the other patches which is
> separate the cpuidle code from the rest of the acpi code. It is part of
> the cleanup.
> 
> > In addition to them it creates a number of static per-CPU objects that
> > previously were stored in those struct acpi_processor object mentioned 
> > above.
> > These things need not be stored in percpu memory.
> 
> Agreed, this patch makes the cpuidle driver to consume more per cpu
> memory. Is it acceptable to create a per cpu pointer for the cpuidle
> devices which will be allocated in the processor_driver init function
> like the intel_idle driver ? We keep the same memory consumption while
> we are moving the cpuidle specific code the C file.

I'm not really sure what you mean hear, care to elaborate?

> By the way, most of the cpuidle drivers for ARM are defining a static
> cpuidle device structure per cpu. I guess your remark for acpi applies
> to them too.

Yes, it does.  Percpu memory is limited and should only be used for things
that really need to be stored there.

> Not easy to make all these drivers to converge to the same code scheme ...

I agree, but then I'm not sure it's a problem if they are slightly different.

Thanks,
Rafael

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

new fastmodel naming in LAVA

2012-09-11 Thread Andy Doan 
A head's up for people submitting fastmodel jobs to LAVA. We've recently 
decided on a different naming scheme for the device/device-types in the 
lab. Previously it was:


 device-type: fastmodel
 device: fastmodel01, fastmodel02

We are changing this to be:

 device-type: rtsm_ve-a15x4-a7x4
 device: rtsm_ve-a15x4-a7x4_01, rtsm_ve-a15x4-a7x4_02

and I'll also be creating a new device/type:

 device-type: rtsm_ve-a15x1-a7x1
 device: rtsm_ve-a15x1-a7x1_01, rtsm_ve-a15x1-a7x1_02


How does this affect me? You'll need to change your job you submit to 
LAVA to match this new device type.


-andy

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)

2012-09-11 Thread Daniel Lezcano 
On 09/11/2012 02:18 AM, John Stultz wrote:
> On 09/10/2012 12:45 PM, Daniel Lezcano wrote:
>> On 09/10/2012 07:14 PM, John Stultz wrote:
>>> In the meantime, I'll try to reproduce on my T61. If you could send me
>>> your .config, I'd appreciate it.
>> http://pastebin.com/qSxqfdDK
>>
>> The header of the config file shows for a v3.5-rc7 because it is the
>> result of the git-bisect. If you keep this config file for the latest
>> kernel that should reproduce the problem.
>>
>> Let me know if you were able to reproduce the problem.
> Great! With this I was able to quickly reproduce the problem and I think
> I have a fix.
> 
> Would you mind testing the following patch? It seems to resolve the
> issue, but I've not yet run it through my test suite to make sure it
> didn't break anything else.
> 
> If both your and my testing comes back ok, I'll submit it to Thomas.

Sounds like this solves the problem. Without enough background on timers
in general, I don't have an opinion about the patch itself but I can
confirm the issue is no longer occurring.

Thanks
  -- Daniel

-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

2012-09-12 Android Platform Team Meeting Agenda Posted

2012-09-11 Thread Zach Pfeffer 
Take a look at:

https://wiki.linaro.org/Platform/Android/Meetings/2012-09-12

Feel free to add to the agenda and join us in #linaro-meeting on
irc.freenode.net at 13:00 UTC on 2012/9/12.

-- 
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: 2012-09-12 Android Platform Team Meeting Agenda Posted

2012-09-11 Thread Zygmunt Krynicki 

W dniu 11.09.2012 23:56, Zach Pfeffer pisze:

Take a look at:

https://wiki.linaro.org/Platform/Android/Meetings/2012-09-12

Feel free to add to the agenda and join us in #linaro-meeting on
irc.freenode.net at 13:00 UTC on 2012/9/12.


Yay, google tester is in the agenda, thanks zach!

ZK


--
Zygmunt Krynicki
s/Linaro Validation Team/Canonical Certification Team/
s/Validation/Android/

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev