Re: [PATCH 2/3] PERF(kernel): Cleanup power events

[Arjan van de Ven]

On 10/19/2010 4:36 AM, Thomas Renninger wrote:

  static void poll_idle(void)
  {
-   trace_power_start(POWER_CSTATE, 0, smp_processor_id());
local_irq_enable();
while (!need_resched())
cpu_relax();
-   trace_power_end(0);
  }


why did you remove the idle tracepoints from this one ???

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] PERF(kernel): Cleanup power events

[Arjan van de Ven]

On 10/19/2010 4:36 AM, Thomas Renninger wrote:

New power trace events:
power:processor_idle
power:processor_frequency
power:machine_suspend


C-state/idle accounting events:
   power:power_start
   power:power_end
are replaced with:
   power:processor_idle


I think you need two trace points for this
one to enter idle
one to exit

because using magic encoding games to encode exitis a mistake; as can 
be seen in this patch.
You're currently trying to use 0 to signal end of idle, but 0 is 
also a valid idle state (namely that of polling)


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] 32k sync timer meets hwmod

[Felipe Balbi]

On Fri, Oct 22, 2010 at 02:01:22PM -0500, green wrote:

Felipe Balbi wrote at 2010-10-21 14:09 -0500:

On Thu, Oct 21, 2010 at 01:00:19PM -0500, Kevin Hilman wrote:
Hey, don't you have a 2420 device.  There were some cool 2420-based
tablets a few years ago made by some company in Finland that you may
have heard of.  ;)

I have an n810 which doesn't work :-p sucks to be me :-p


Just curious, what happened to your n810?


don't know actually. It just doesn't boot. Not even with the original
Nokia releases.

--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 3/4] staging: tidspbridge: remove gb bitmap implementation

[Ionut Nicu]

Hi Rene,

On Sat, 2010-10-23 at 15:28 -0500, Sapiens, Rene wrote:
 Hi Ionut,
 On Friday, October 22, 2010 9:09 AM Ionut Nicu wrote:
  Most likely I will have to break patch 4/4 from this series (which I
  also believe is way too big) into multiple patches and re-submit.
  
  I'm expecting some advices from the maintainers/list on how to split
  patch 4 (lst_list removal).
 
 I have a version of this patch but yours did it first :). You can break
 it by functionality so that you don't break nor affect bridge's behavior
 i.e.
 
 Patch 1 can include the removing of the wrapper from:
 drivers/staging/tidspbridge/core/_msg_sm.h
 drivers/staging/tidspbridge/core/chnl_sm.c
 drivers/staging/tidspbridge/core/io_sm.c
 drivers/staging/tidspbridge/core/msg_sm.c
 drivers/staging/tidspbridge/include/dspbridge/_chnl_sm.h
 drivers/staging/tidspbridge/include/dspbridge/cmmdefs.h
 The above files share some of the lists.
 
 Patch 2:
 drivers/staging/tidspbridge/pmgr/cmm.c
 
 Patch 3:
 drivers/staging/tidspbridge/pmgr/dev.c
 drivers/staging/tidspbridge/rmgr/drv.c
 drivers/staging/tidspbridge/rmgr/node.c
 drivers/staging/tidspbridge/rmgr/proc.c
 
 Patch 4:
 drivers/staging/tidspbridge/rmgr/rmm.c
 
 Patch 5:
 Removing of the not needed files.
 

Thanks for your suggestions. I will try to do this split-up in version 2
of this series.

Best regards,
Ionut.

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 09/10] OMAP2/3: Convert write/read functions to raw read/write

[Artem Bityutskiy]

On Mon, 2010-10-25 at 01:01 +0100, David Woodhouse wrote:
 On Thu, 2010-10-07 at 14:50 -0500, Nishanth Menon wrote:
  my comment being that by moving {read,write}[wlb] to __raw versions dont 
  solve the real issue of namespace here. fix should be in 
  arch/arm/include/asm/io.h IMHO. so that there are no overlaps as this. 
 
 Indeed. This patch is complete nonsense.

Removing from my l2 tree.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v3 08/11] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers

[Gopinath, Thara]

-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, October 22, 2010 10:22 PM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: Re: [PATCH v3 08/11] OMAP3: PM: Adding debug support to Voltage and
Smartreflex drivers

Gopinath, Thara th...@ti.com writes:

Thara Gopinath th...@ti.com writes:

 This patch adds debug support to the voltage and smartreflex drivers.
 This means a whole bunch of voltage processor and smartreflex
 parameters are now visible through the pm debugfs. By default
 only a read of these parameters are permitted. If you need to
 write into them then
 echo 1  /pm_debug/enable_sr_vp_debug

Why a read-only interface by default?   As a debug interface it seems
redundant to have to enable it.


 Read-only interface by default so that we can read these values from
 user space even if we do not want to manipulate it from user-side.


If we do not want to manipulate it from the user-side, then simply don't
write to it.   Remember, this is a debug interface, not a primary
interface.

I think the enable_sr_vp_debug flag should disappear, and it should be a
read/write interface.

If the values are changed via debugfs, then set some per-SR instance
flag that can be checked.

Basically, the current code is confusing because you're using the the
flag called 'enable' to determine whether the user *might have* written
the values.

[...]

 +   /*
 +* Getting  vp errorgain based on the voltage. If the debug option
is
 +* enabled allow the override of errorgain from user side.
 +*/

As suggested in earlier comment, please use a specific flag that this
has been overridden instead of the 'debug enabled' flag (which should
disappear, IMO)

 What do you mean by a separate flag. You want a flag to be maintained
 for just this purpose ?

Yes.  I want a flag to be maintained *specifically* for this purpose,
instead of using a much more general flag that only means a user *might*
have overridden the values, use one that specifically means a user *has*
overridden the values.

Hello Kevin,

I tried this. Couple of questions/concerns I have.
1. If you take a look at the definition of these debugfs parameters, the 
omap_vdd_info struct is not passed as an argument. The actual variables are the 
parameters. I am not sure how to extract omap_vdd_info from this. Maybe 
container_of will help, but then it will be clumsy. Same concern for 
smartreflex  err_minlimit variable. There is no way to get the sr instance 
except use container of which I am not sure will work or not
2.Also in voltage layer we export out eight parameters tat can be over-ridden 
from the user side. I do not think we should be maintaining one flag per 
variable. The design will be too very clumsy.

Regards
Thara


Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v3 09/11] OMAP3: PM: Smartreflex Class3 initialization from board files.

[Gopinath, Thara]

-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, October 22, 2010 10:08 PM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: Re: [PATCH v3 09/11] OMAP3: PM: Smartreflex Class3 initialization
from board files.

Gopinath, Thara th...@ti.com writes:

 This patch enables smartreflex class3 functionality for OMAP3430SDP,
 OMAP3630SDP, ZOOM2 and ZOOM3 boards.

This patch doesn't touch 3630sdp.

 Signed-off-by: Thara Gopinath th...@ti.com

I'm having some doubts about whether this should be done by board files or
not.  Seems like the general case will be that by default will be SoC
specific, and only boards that want something other than the default
class should need to override this.

Thoughts?

 I agree. I wanted this to be a default initcall and one to enable the
 menuconfig option for the required class driver.. But Nishant wanted
 this from board files.

And I want both.  :)

 If we have consensus in removing this init from board file, I am cool
 with it.

I want to suport a kernel that could be built with all possible classes
supported.  e.g. an omap3/4 kernel that has both class 1.5 and class 3
support.

If both are enabled in Kconfig, then either could be used.  We'll have
to pick one as the default initcall (e.g. highest class present), but if
a board file chooses to call a different one, that should override the
default one.

We can pick class 3 by default and make it a late_initcall. This way if the 
board files choose to call some other class init, that class ddriver would be 
registered. Smartreflex driver sr_register_class API will ensure that only one 
class is registered. The second registeration will fail. What say ??

Regards,
Thara
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 08/11] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers

[Cousson, Benoit]

Hi Thara,

On 9/22/2010 4:45 PM, Gopinath, Thara wrote:

This patch adds debug support to the voltage and smartreflex drivers.
This means a whole bunch of voltage processor and smartreflex
parameters are now visible through the pm debugfs. By default
only a read of these parameters are permitted. If you need to
write into them then
echo 1  /pm_debug/enable_sr_vp_debug

The voltage parameters can be viewed at
/pm_debug/voltage/vdd_x/parameter
and the smartreflex parameters can be viewed at
/pm_debug/smartreflex/sr_x/parameter


Can we start getting rid of this pm_debug miscellaneous directory?
Like powerdomain and clockdomain debug stuff, I think that voltage 
domain layer deserve its own entry in the debugfs top level directory.


I do not see the need to add a extra level a directory for that.
Moreover smartreflex should be under voltage entry and not in the same 
level as voltage.


/sys/kernel/debug/voltage/vdd_x/smartreflex/parameter

Regards,
Benoit




wherex  is mpu or core for OMAP3.

Signed-off-by: Thara Gopinathth...@ti.com
---
  arch/arm/mach-omap2/pm-debug.c|   15 ++
  arch/arm/mach-omap2/smartreflex.c |   40 +-
  arch/arm/mach-omap2/voltage.c |  210 -
  arch/arm/plat-omap/include/plat/smartreflex.h |1 -
  arch/arm/plat-omap/include/plat/voltage.h |5 +
  5 files changed, 264 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 390f1c6..879efb2 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -32,6 +32,7 @@
  #includeplat/powerdomain.h
  #includeplat/clockdomain.h
  #includeplat/dmtimer.h
+#includeplat/voltage.h

  #include prm.h
  #include cm.h
@@ -586,6 +587,18 @@ static int option_set(void *data, u64 val)
omap3_pm_off_mode_enable(val);
}

+   if (option ==enable_sr_vp_debug  val)
+   pr_notice(Beware that enabling this option will allow user 
+   to override the system defined vp and sr parameters 
+   All the updated parameters will take effect next 
+   time smartreflex is enabled. Also this option 
+   disables the automatic vp errorgain and sr errormin 
+   limit changes as per the voltage. Users will have 
+   to explicitly write values into the debug fs 
+   entries corresponding to these if they want to see 
+   them changing according to the VDD voltage\n);
+
+
return 0;
  }

@@ -642,6 +655,8 @@ static int __init pm_dbg_init(void)
(void) debugfs_create_file(wakeup_timer_milliseconds,
S_IRUGO | S_IWUGO, d,wakeup_timer_milliseconds,
pm_dbg_option_fops);
+   (void) debugfs_create_file(enable_sr_vp_debug,  S_IRUGO | S_IWUGO, d,
+   enable_sr_vp_debug,pm_dbg_option_fops);

pm_dbg_main_dir = d;
pm_dbg_init_done = 1;
diff --git a/arch/arm/mach-omap2/smartreflex.c 
b/arch/arm/mach-omap2/smartreflex.c
index 7fc3138..b5a7878 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -558,8 +558,13 @@ int sr_enable(struct voltagedomain *voltdm, unsigned long 
volt)
return -ENODATA;
}

-   /* errminlimit is opp dependent and hence linked to voltage */
-   sr-err_minlimit = volt_data-sr_errminlimit;
+   /*
+* errminlimit is opp dependent and hence linked to voltage
+* if the debug option is enabled, the user might have over ridden
+* this parameter so do not get it from voltage table
+*/
+   if (!enable_sr_vp_debug)
+   sr-err_minlimit = volt_data-sr_errminlimit;

/* Enable the clocks */
if (!sr-sr_enable) {
@@ -811,9 +816,34 @@ static int omap_sr_autocomp_store(void *data, u64 val)
return 0;
  }

+static int omap_sr_params_show(void *data, u64 *val)
+{
+   u32 *param = data;
+
+   *val = *param;
+   return 0;
+}
+
+static int omap_sr_params_store(void *data, u64 val)
+{
+   if (enable_sr_vp_debug) {
+   u32 *option = data;
+   *option = val;
+   } else {
+   pr_notice(%s: DEBUG option not enabled!\n \
+   echo 1  pm_debug/enable_sr_vp_debug - to enable\n,
+   __func__);
+   }
+
+   return 0;
+}
+
  DEFINE_SIMPLE_ATTRIBUTE(pm_sr_fops, omap_sr_autocomp_show,
omap_sr_autocomp_store, %llu\n);

+DEFINE_SIMPLE_ATTRIBUTE(sr_params_fops, omap_sr_params_show,
+   omap_sr_params_store, %llu\n);
+
  static int __init omap_smartreflex_probe(struct platform_device *pdev)
  {
struct omap_sr *sr_info = kzalloc(sizeof(struct omap_sr), GFP_KERNEL);
@@ -907,6 +937,12 @@ static int __init omap_smartreflex_probe(struct 

Re: [PATCH v3 01/11] OMAP: PM: Export the main pm debugfs directory

[Cousson, Benoit]

On 9/22/2010 4:45 PM, Gopinath, Thara wrote:

This patch makes generic pm_debug directory  global
so that other drivers can include it and use it to create
sub-entries.


That should not be needed, if we expose voltage debugfs entry in the top 
level directly.


Benoit



Signed-off-by: Thara Gopinathth...@ti.com
---
  arch/arm/mach-omap2/pm-debug.c |3 +++
  arch/arm/mach-omap2/pm.h   |1 +
  2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index af00c17..390f1c6 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -42,6 +42,7 @@ u32 enable_off_mode;
  u32 sleep_while_idle;
  u32 wakeup_timer_seconds;
  u32 wakeup_timer_milliseconds;
+struct dentry *pm_dbg_main_dir;

  #define DUMP_PRM_MOD_REG(mod, reg)\
regs[reg_count].name = #mod . #reg; \
@@ -641,6 +642,8 @@ static int __init pm_dbg_init(void)
(void) debugfs_create_file(wakeup_timer_milliseconds,
S_IRUGO | S_IWUGO, d,wakeup_timer_milliseconds,
pm_dbg_option_fops);
+
+   pm_dbg_main_dir = d;
pm_dbg_init_done = 1;

return 0;
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index f3ba1e6..c06cedd 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -55,6 +55,7 @@ extern int omap2_pm_debug;
  #define omap2_pm_dump(mode, resume, us)   do {} while (0);
  #define omap2_pm_wakeup_on_timer(seconds, milliseconds)   do {} while (0);
  #define omap2_pm_debug0
+#define pm_dbg_main_dir0
  #endif

  #if defined(CONFIG_CPU_IDLE)


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v3 01/11] OMAP: PM: Export the main pm debugfs directory

[Gopinath, Thara]

-Original Message-
From: Cousson, Benoit
Sent: Monday, October 25, 2010 3:00 PM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; khil...@deeprootsystems.com; p...@pwsan.com;
Sripathy, Vishwanath; Sawant, Anand
Subject: Re: [PATCH v3 01/11] OMAP: PM: Export the main pm debugfs directory

On 9/22/2010 4:45 PM, Gopinath, Thara wrote:
 This patch makes generic pm_debug directory  global
 so that other drivers can include it and use it to create
 sub-entries.

That should not be needed, if we expose voltage debugfs entry in the top
level directly.

Agreed. I am ok with exposing the voltage debugfs entry at the top level.

Regards
Thara 

Benoit


 Signed-off-by: Thara Gopinathth...@ti.com
 ---
   arch/arm/mach-omap2/pm-debug.c |3 +++
   arch/arm/mach-omap2/pm.h   |1 +
   2 files changed, 4 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-
debug.c
 index af00c17..390f1c6 100644
 --- a/arch/arm/mach-omap2/pm-debug.c
 +++ b/arch/arm/mach-omap2/pm-debug.c
 @@ -42,6 +42,7 @@ u32 enable_off_mode;
   u32 sleep_while_idle;
   u32 wakeup_timer_seconds;
   u32 wakeup_timer_milliseconds;
 +struct dentry *pm_dbg_main_dir;

   #define DUMP_PRM_MOD_REG(mod, reg)\
 regs[reg_count].name = #mod . #reg; \
 @@ -641,6 +642,8 @@ static int __init pm_dbg_init(void)
 (void) debugfs_create_file(wakeup_timer_milliseconds,
 S_IRUGO | S_IWUGO, d,wakeup_timer_milliseconds,
 pm_dbg_option_fops);
 +
 +   pm_dbg_main_dir = d;
 pm_dbg_init_done = 1;

 return 0;
 diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
 index f3ba1e6..c06cedd 100644
 --- a/arch/arm/mach-omap2/pm.h
 +++ b/arch/arm/mach-omap2/pm.h
 @@ -55,6 +55,7 @@ extern int omap2_pm_debug;
   #define omap2_pm_dump(mode, resume, us)   do {} while (0);
   #define omap2_pm_wakeup_on_timer(seconds, milliseconds)   do {} while (0);
   #define omap2_pm_debug0
 +#define pm_dbg_main_dir0
   #endif

   #if defined(CONFIG_CPU_IDLE)

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] PERF(kernel): Cleanup power events

[Thomas Renninger]

On Monday 25 October 2010 08:54:34 Arjan van de Ven wrote:
 On 10/19/2010 4:36 AM, Thomas Renninger wrote:
static void poll_idle(void)
{
  -   trace_power_start(POWER_CSTATE, 0, smp_processor_id());
  local_irq_enable();
  while (!need_resched())
  cpu_relax();
  -   trace_power_end(0);
}
 
 why did you remove the idle tracepoints from this one ???
Because no idle/sleep state is entered here.
State 0 does not exist or say, it means the machine is not idle.
The new event uses idle state 0 spec conform as exit sleep state.

If this should still be trackable some kind of dummy sleep state:
#define IDLE_BUSY_LOOP 0xFE
(or similar) must get defined and passed like this:
trace_processor_idle(IDLE_BUSY_LOOP, smp_processor_id());
cpu_relax()
trace_processor_idle(0, smp_processor_id());

I could imagine this is somewhat worth it to compare idle results
to no idle state at all is used.
But nobody should ever use idle=poll, comparing deep sleep states
with C1 with (idle=halt) should be sufficient?

Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] PERF(kernel): Cleanup power events

[Ingo Molnar]

* Thomas Renninger tr...@suse.de wrote:

 New power trace events:
 power:processor_idle
 power:processor_frequency
 power:machine_suspend
 
 
 C-state/idle accounting events:
   power:power_start
   power:power_end
 are replaced with:
   power:processor_idle

Well, most power saving hw models (and the code implementing them) have this 
kind of 
model:

 enter power saving mode X
 exit power saving mode

Where X is some sort of 'power saving deepness' attribute, right?

Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2 09/10] OMAP2/3: Convert write/read functions to raw read/write

[David Woodhouse]

On Mon, 2010-10-25 at 11:04 +0530, G, Manjunath Kondaiah wrote:
 David,
 
  -Original Message-
  From: David Woodhouse [mailto:dw...@infradead.org] 
  Sent: Monday, October 25, 2010 5:32 AM
  To: Menon, Nishanth
  Cc: Russell King - ARM Linux; G, Manjunath Kondaiah; 
  linux-omap@vger.kernel.org; linux-...@lists.infradead.org; 
  linux-arm-ker...@lists.infradead.org
  Subject: Re: [PATCH v2 09/10] OMAP2/3: Convert write/read 
  functions to raw read/write
  
  On Thu, 2010-10-07 at 14:50 -0500, Nishanth Menon wrote:
   my comment being that by moving {read,write}[wlb] to __raw versions 
   dont solve the real issue of namespace here. fix should be in 
   arch/arm/include/asm/io.h IMHO. so that there are no 
  overlaps as this.
  
  Indeed. This patch is complete nonsense.
 
 nonsense? There are two types of fixes proposed to fix these sparse warnings.
 1. with this patch
 2. fixing in io.h
 https://patchwork.kernel.org/patch/250171/
 
 1st option is already merged with 2.6.37 merge window.
 
 If 2 get accepted, all __raw_read/write will get replaced with readl/writel.
 
 Apart from those two, do you have any other alternate idea to fix these 
 sparse warnings?

The latter is obviously the better approach. The problem that sparse is
complaining about is the fact that you have two nested C blocks, both of
which contain a local variable called '__v'. By changing the variable
names so that they're actually unique, we fix the real problem.

The answer is not that *all* drivers which call cpu_to_le16(readw())
must be changed, which is what you seem to have assumed. And you
*certainly* can't change them to use __raw_readw(), which has
*different* semantics (and endianness in some cases), without a clear
comment in the changelog entry saying *why* that change was OK.

-- 
dwmw2

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] PERF(kernel): Cleanup power events

[Thomas Renninger]

On Monday 25 October 2010 12:04:28 Ingo Molnar wrote:
 
 * Thomas Renninger tr...@suse.de wrote:
 
  New power trace events:
  power:processor_idle
  power:processor_frequency
  power:machine_suspend
  
  
  C-state/idle accounting events:
power:power_start
power:power_end
  are replaced with:
power:processor_idle
 
 Well, most power saving hw models (and the code implementing them) have this 
 kind of 
 model:
 
  enter power saving mode X
  exit power saving mode
 
 Where X is some sort of 'power saving deepness' attribute, right?
Sure.
But ACPI and afaik this model got picked up for PCI and other (sub-)archs
as well, defines state 0 as the non-power saving mode.
Same as done here with machine suspend state (S0 is back from suspend) and
this model should get picked up when device sleep states get tracked at
some time.
It's consistent and applies to some well known specifications.

Also tracking processor_idle_{start,end} as a separate event
makes no sense and there is no need to introduce:
processor_idle_start/processor_idle_end
machine_suspend_start/machine_suspend_end
device_power_mode_start/device_power_mode_end
events.
Using state 0 as exit/end, is much nicer for kernel/
userspace implementations/code and the user.

 Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] PERF(kernel): Cleanup power events

[Ingo Molnar]

* Thomas Renninger tr...@suse.de wrote:

 On Monday 25 October 2010 12:04:28 Ingo Molnar wrote:
  
  * Thomas Renninger tr...@suse.de wrote:
  
   New power trace events:
   power:processor_idle
   power:processor_frequency
   power:machine_suspend
   
   
   C-state/idle accounting events:
 power:power_start
 power:power_end
   are replaced with:
 power:processor_idle
  
  Well, most power saving hw models (and the code implementing them) have 
  this kind of 
  model:
  
   enter power saving mode X
   exit power saving mode
  
  Where X is some sort of 'power saving deepness' attribute, right?

 Sure.

Which is is the 'saner' model?

 But ACPI and afaik this model got picked up for PCI and other (sub-)archs as 
 well, 
 defines state 0 as the non-power saving mode.

But the actual code does not actually deal with any 'state 0', does it? It 
enters an 
idle function and then exits it, right?

'power state' might be what is used for devices - but even there, we have:

  - enter power state X
  - exit power state

right?

 Same as done here with machine suspend state (S0 is back from suspend) and
 this model should get picked up when device sleep states get tracked at
 some time.

 It's consistent and applies to some well known specifications.

What we want it to be is for it to be the nicest, most understandable, most 
logical 
model - not one matching random hardware specifications.

( Hardware specifications only matter in so far that it should be possible to 
  express all the known hardware state transitions via these events 
efficiently. )

 Also tracking processor_idle_{start,end} as a separate event makes no sense 
 and 
 there is no need to introduce: processor_idle_start/processor_idle_end 
 machine_suspend_start/machine_suspend_end 
 device_power_mode_start/device_power_mode_end events.

What do you mean by makes no sense?

Are they superfluous? Inefficient? Illogical?

 Using state 0 as exit/end, is much nicer for kernel/ userspace 
 implementations/code and the user.

By that argument we should not have separate fork() and exit() syscalls either, 
but 
a set_process_state(1) and set_process_state(0) interface?

Thanks,

Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] PERF(kernel): Cleanup power events

[Thomas Renninger]

On Monday 25 October 2010 13:55:25 Ingo Molnar wrote:
 
 * Thomas Renninger tr...@suse.de wrote:
 
  On Monday 25 October 2010 12:04:28 Ingo Molnar wrote:
   
   * Thomas Renninger tr...@suse.de wrote:
   
New power trace events:
power:processor_idle
power:processor_frequency
power:machine_suspend


C-state/idle accounting events:
  power:power_start
  power:power_end
are replaced with:
  power:processor_idle
   
   Well, most power saving hw models (and the code implementing them) have 
   this kind of 
   model:
   
enter power saving mode X
exit power saving mode
   
   Where X is some sort of 'power saving deepness' attribute, right?
 
  Sure.
 
 Which is is the 'saner' model?
 
  But ACPI and afaik this model got picked up for PCI and other (sub-)archs 
  as well, 
  defines state 0 as the non-power saving mode.
 
 But the actual code does not actually deal with any 'state 0', does it?
It does. Not being idle is tracked by cpuidle driver as state 0
(arch independent):
/sys/devices/system/cpu/cpu0/cpuidle/state0/
halt/C1 on X86 is:
/sys/devices/system/cpu/cpu0/cpuidle/state1/
...

 It enters an idle function and then exits it, right?
 'power state' might be what is used for devices - but even there, we have:
 
   - enter power state X
   - exit power state
 
 right?
That is not true for PCI, probably others as well.
There you have D0 (being the maximum powered state) up to D3.
Same for PCI Bus Power States (B0, B1, B2, and B3).

Look at drivers/pci/pci.c:pci_raw_set_power_state()
To exit a power state you call:
pci_raw_set_power_state(dev, PCI_D0);

Same for suspend. Exit suspend is:
#define PM_SUSPEND_ON   ((__force suspend_state_t) 0)
so on resume we enter suspend_state_t 0.

  Same as done here with machine suspend state (S0 is back from suspend) and
  this model should get picked up when device sleep states get tracked at
  some time.
 
  It's consistent and applies to some well known specifications.
 
 What we want it to be is for it to be the nicest, most understandable, most 
 logical 
 model - not one matching random hardware specifications.
 
 ( Hardware specifications only matter in so far that it should be possible to 
   express all the known hardware state transitions via these events 
 efficiently. )
 
  Also tracking processor_idle_{start,end} as a separate event makes no sense 
  and 
  there is no need to introduce: processor_idle_start/processor_idle_end 
  machine_suspend_start/machine_suspend_end 
  device_power_mode_start/device_power_mode_end events.
 
 What do you mean by makes no sense?
 
 Are they superfluous?
Yes, you do not need two different events to track one thing.

 Illogical?
Yes, A user who wants to enable processor idle tracking does
want to enable it via:
echo power:processor_idle /sys/kernel/debug/tracing/events/enable
what do you intend to track with a:
power:power_start
event?

Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] PERF(kernel): Cleanup power events

[Mathieu Desnoyers]

* Ingo Molnar (mi...@elte.hu) wrote:
 
 * Thomas Renninger tr...@suse.de wrote:
 
  On Monday 25 October 2010 12:04:28 Ingo Molnar wrote:
   
   * Thomas Renninger tr...@suse.de wrote:
   
New power trace events:
power:processor_idle
power:processor_frequency
power:machine_suspend


C-state/idle accounting events:
  power:power_start
  power:power_end
are replaced with:
  power:processor_idle
   
   Well, most power saving hw models (and the code implementing them) have 
   this kind of 
   model:
   
enter power saving mode X
exit power saving mode
   
   Where X is some sort of 'power saving deepness' attribute, right?
 
  Sure.
 
 Which is is the 'saner' model?
 
  But ACPI and afaik this model got picked up for PCI and other (sub-)archs 
  as well, 
  defines state 0 as the non-power saving mode.
 
 But the actual code does not actually deal with any 'state 0', does it? It 
 enters an 
 idle function and then exits it, right?
 
 'power state' might be what is used for devices - but even there, we have:
 
   - enter power state X
   - exit power state
 
 right?
 
  Same as done here with machine suspend state (S0 is back from suspend) and
  this model should get picked up when device sleep states get tracked at
  some time.
 
  It's consistent and applies to some well known specifications.
 
 What we want it to be is for it to be the nicest, most understandable, most 
 logical 
 model - not one matching random hardware specifications.
 
 ( Hardware specifications only matter in so far that it should be possible to 
   express all the known hardware state transitions via these events 
 efficiently. )
 
  Also tracking processor_idle_{start,end} as a separate event makes no sense 
  and 
  there is no need to introduce: processor_idle_start/processor_idle_end 
  machine_suspend_start/machine_suspend_end 
  device_power_mode_start/device_power_mode_end events.
 
 What do you mean by makes no sense?
 
 Are they superfluous? Inefficient? Illogical?

I think it would require deep understanding of specific power modes of each
architecture to split into this topology. On the bright side, it would bring
clear understanding of which HW resource is being put to sleep, which would make
automated analysis much easier to do. But maybe it's too much pain compared to
the benefit. The related question is also: where is it best to put this logic ?
In the kernel code ? In per-arch TRACE_EVENT() handlers or in external trace
analysis plugins ?

 
  Using state 0 as exit/end, is much nicer for kernel/ userspace 
  implementations/code and the user.
 
 By that argument we should not have separate fork() and exit() syscalls 
 either, but 
 a set_process_state(1) and set_process_state(0) interface?

I'm by no mean expert on power saving hardware specs, but if it is possible for
hardware to switch between two power saving states without passing through power
state 0, then using a set state rather than an enter/exit would be more
appropriate; even if we go for a scheme introducing

processor_idle_start/processor_idle_end,
machine_suspend_start/machine_suspend_end,
device_power_mode_start/device_power_mode_end.

I must defer to you guys to figure out if some hardware actually do that for
either of CPU idle, suspend or device power modes.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency RD Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] OMAP: AM3517/05: craneboard: Add craneboard support

[srinath]

From: Srinath srin...@mistralsolutions.com

This patch adds basic board file. Detailed support will follow in
subsequent patches.

  [1] http://www.ti.com/sitara
  [2] http://www.mistralsolutions.com/products/craneboard.php

This patch has been created against omap-next branch.

Signed-off-by: Srinath srin...@mistralsolutions.com
---
 arch/arm/configs/omap2plus_defconfig |1 +
 arch/arm/mach-omap2/Kconfig  |5 ++
 arch/arm/mach-omap2/Makefile |2 +
 arch/arm/mach-omap2/board-am3517crane.c  |   74 ++
 arch/arm/plat-omap/include/plat/uncompress.h |1 +
 5 files changed, 83 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-am3517crane.c

diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index ccedde1..8c93f86 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -40,6 +40,7 @@ CONFIG_MACH_OMAP_LDP=y
 CONFIG_MACH_OVERO=y
 CONFIG_MACH_OMAP3EVM=y
 CONFIG_MACH_OMAP3517EVM=y
+CONFIG_MACH_CRANEBOARD=y
 CONFIG_MACH_OMAP3_PANDORA=y
 CONFIG_MACH_OMAP3_TOUCHBOOK=y
 CONFIG_MACH_OMAP_3430SDP=y
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index ab784bf..3688515 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -174,6 +174,11 @@ config MACH_OMAP3517EVM
default y
select OMAP_PACKAGE_CBB
 
+config MACH_CRANEBOARD
+   bool AM3517/05 CRANE board
+   depends on ARCH_OMAP3
+   select OMAP_PACKAGE_CBB
+
 config MACH_OMAP3_PANDORA
bool OMAP3 Pandora
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 7352412..f885037 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -170,6 +170,8 @@ obj-$(CONFIG_MACH_OMAP4_PANDA)  += 
board-omap4panda.o \
 
 obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
 
+obj-$(CONFIG_MACH_CRANEBOARD)  += board-am3517crane.o
+
 obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o \
   hsmmc.o
 # Platform specific device init code
diff --git a/arch/arm/mach-omap2/board-am3517crane.c 
b/arch/arm/mach-omap2/board-am3517crane.c
new file mode 100644
index 000..152f6ee
--- /dev/null
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -0,0 +1,74 @@
+/*
+ * linux/arch/arm/mach-omap2/board-am3517crane.c
+ *
+ * Copyright (C) 2010 Mistral Solutions Pvt Ltd. www.mistralsolutions.com
+ * Author: R.Srinath srin...@mistralsolutions.com
+ *
+ * Based on mach-omap2/board-am3517evm.c
+ *
+ * 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 version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any kind,
+ * whether express or implied; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/gpio.h
+#include linux/platform_device.h
+
+#include mach/hardware.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+
+#include plat/board.h
+#include plat/common.h
+
+#include mux.h
+
+/* Board initialization */
+static struct omap_board_config_kernel am3517_crane_config[] __initdata = {
+};
+
+static struct platform_device *am3517_crane_devices[] __initdata = {
+};
+
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+   { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define board_mux  NULL
+#endif
+
+static void __init am3517_crane_init_irq(void)
+{
+   omap_board_config = am3517_crane_config;
+   omap_board_config_size = ARRAY_SIZE(am3517_crane_config);
+
+   omap2_init_common_hw(NULL, NULL);
+   omap_init_irq();
+   omap_gpio_init();
+}
+
+static void __init am3517_crane_init(void)
+{
+   omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+   platform_add_devices(am3517_crane_devices,
+   ARRAY_SIZE(am3517_crane_devices));
+   omap_serial_init();
+}
+
+MACHINE_START(CRANEBOARD, AM3517/05 CRANEBOARD)
+   .boot_params= 0x8100,
+   .map_io = omap3_map_io,
+   .reserve= omap_reserve,
+   .init_irq   = am3517_crane_init_irq,
+   .init_machine   = am3517_crane_init,
+   .timer  = omap_timer,
+MACHINE_END
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h 
b/arch/arm/plat-omap/include/plat/uncompress.h
index 9036e37..229fbf2 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -145,6 +145,7 @@ static inline void __arch_decomp_setup(unsigned long 
arch_id)
/* omap3 based boards using UART3 */
DEBUG_LL_OMAP3(3, 

Re: [PATCH 2/3] PERF(kernel): Cleanup power events

[Arjan van de Ven]

On 10/25/2010 2:41 AM, Thomas Renninger wrote:

On Monday 25 October 2010 08:54:34 Arjan van de Ven wrote:

On 10/19/2010 4:36 AM, Thomas Renninger wrote:

   static void poll_idle(void)
   {
-   trace_power_start(POWER_CSTATE, 0, smp_processor_id());
local_irq_enable();
while (!need_resched())
cpu_relax();
-   trace_power_end(0);
   }

why did you remove the idle tracepoints from this one ???

Because no idle/sleep state is entered here.
State 0 does not exist or say, it means the machine is not idle.
The new event uses idle state 0 spec conform as exit sleep state.

If this should still be trackable some kind of dummy sleep state:
#define IDLE_BUSY_LOOP 0xFE
(or similar) must get defined and passed like this:
trace_processor_idle(IDLE_BUSY_LOOP, smp_processor_id());
 cpu_relax()
trace_processor_idle(0, smp_processor_id());

I could imagine this is somewhat worth it to compare idle results
to no idle state at all is used.
But nobody should ever use idle=poll, comparing deep sleep states
with C1 with (idle=halt) should be sufficient?


this is not idle=poll on the command line only.
this also gets used normally, in two cases
1) during real time operations, for some short periods of time
(think wallstreet trading)
2) by the menu governor when the next event is less than a few 
microseconds away, so short that even C1 is too much


I know that your new API tries to use 0 as exit, but 0 is already 
taken (in all power terminology at least on x86 it is) for this.


why isn't your exit a special define?


also, if you look at many other similar perf events, they ever separate 
entry/exit points:


process/do_process.cpp: 
perf_events-add_event(irq:irq_handler_entry);
process/do_process.cpp: 
perf_events-add_event(irq:irq_handler_exit);

process/do_process.cpp: perf_events-add_event(irq:softirq_entry);
process/do_process.cpp: perf_events-add_event(irq:softirq_exit);
process/do_process.cpp: 
perf_events-add_event(timer:timer_expire_entry);
process/do_process.cpp: 
perf_events-add_event(timer:timer_expire_exit);
process/do_process.cpp: 
perf_events-add_event(timer:hrtimer_expire_entry);
process/do_process.cpp: 
perf_events-add_event(timer:hrtimer_expire_exit);

process/do_process.cpp: perf_events-add_event(power:power_start);
process/do_process.cpp: perf_events-add_event(power:power_end);
process/do_process.cpp: 
perf_events-add_event(workqueue:workqueue_execute_start);
process/do_process.cpp: 
perf_events-add_event(workqueue:workqueue_execute_end);


so there is already an API consistency precedent
(and frankly, trying to multiplex in exit via a magic value is asking 
for trouble API wise)


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] PERF(kernel): Cleanup power events

[Arjan van de Ven]

On 10/25/2010 4:03 AM, Thomas Renninger wrote:

On Monday 25 October 2010 12:04:28 Ingo Molnar wrote:

* Thomas Renningertr...@suse.de  wrote:


New power trace events:
power:processor_idle
power:processor_frequency
power:machine_suspend


C-state/idle accounting events:
   power:power_start
   power:power_end
are replaced with:
   power:processor_idle

Well, most power saving hw models (and the code implementing them) have this 
kind of
model:

  enter power saving mode X
  exit power saving mode

Where X is some sort of 'power saving deepness' attribute, right?

Sure.
But ACPI and afaik this model got picked up for PCI and other (sub-)archs
as well, defines state 0 as the non-power saving mode.


correct ,... C0 is not power efficient... but it's still a valid OS 
idle state!

Also tracking processor_idle_{start,end} as a separate event!

same for S0... S0 as standby state is still valid... sure it doesn't 
save you much power... but that does not mean it's not valid.
(as indication, the Intel Moorestown platform, which is currently in 
production and available to OEMs, has such a S0 standby state)




makes no sense and there is no need to introduce:
processor_idle_start/processor_idle_end
machine_suspend_start/machine_suspend_end
device_power_mode_start/device_power_mode_end
events.
Using state 0 as exit/end, is much nicer for kernel/
userspace implementations/code and the user.
actually no; having written a few of these in userspace so far, having a 
separate end event is easier to deal with;

the actions you take on entry and exit are complete separate code paths.

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] PERF(kernel): Cleanup power events

[Arjan van de Ven]

On 10/25/2010 5:55 AM, Thomas Renninger wrote:



But the actual code does not actually deal with any 'state 0', does it?

It does. Not being idle is tracked by cpuidle driver as state 0
(arch independent):
/sys/devices/system/cpu/cpu0/cpuidle/state0/
halt/C1 on X86 is:
/sys/devices/system/cpu/cpu0/cpuidle/state1/
...

state0 is still OS idle!


the API is just weird for this, from a userspace perspective

if the kernel picks this state 0 for the idle handler, the userspace app 
gets

two events

one for going to state 0 to enter the idle state
one for going to state 0 to exit idle

but they're the exact same event in your API.

rather unpleasant from a userspace program perspective
now I need to start tracking even more state on top in powertop to be 
able to make a guess at which of the two meanings a state 0 entry has.


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] PERF(kernel): Cleanup power events

[Thomas Renninger]

On Monday 25 October 2010 15:55:08 Arjan van de Ven wrote:
 On 10/25/2010 2:41 AM, Thomas Renninger wrote:
  On Monday 25 October 2010 08:54:34 Arjan van de Ven wrote:
  On 10/19/2010 4:36 AM, Thomas Renninger wrote:
 static void poll_idle(void)
 {
  - trace_power_start(POWER_CSTATE, 0, smp_processor_id());
local_irq_enable();
while (!need_resched())
cpu_relax();
  - trace_power_end(0);
 }
  why did you remove the idle tracepoints from this one ???
  Because no idle/sleep state is entered here.
  State 0 does not exist or say, it means the machine is not idle.
  The new event uses idle state 0 spec conform as exit sleep state.
 
  If this should still be trackable some kind of dummy sleep state:
  #define IDLE_BUSY_LOOP 0xFE
  (or similar) must get defined and passed like this:
  trace_processor_idle(IDLE_BUSY_LOOP, smp_processor_id());
   cpu_relax()
  trace_processor_idle(0, smp_processor_id());
 
  I could imagine this is somewhat worth it to compare idle results
  to no idle state at all is used.
  But nobody should ever use idle=poll, comparing deep sleep states
  with C1 with (idle=halt) should be sufficient?
 
 this is not idle=poll on the command line only.
 this also gets used normally, in two cases
 1) during real time operations, for some short periods of time
  (think wallstreet trading)
 2) by the menu governor when the next event is less than a few 
 microseconds away, so short that even C1 is too much
 
 I know that your new API tries to use 0 as exit, but 0 is already 
 taken (in all power terminology at least on x86 it is) for this.
cpuidle indeed misuses C0 as poll idle state.
That's really bad/misleading, but nothing that can be changed easily.

I agree shifting C0 (cpuidle) - POLL_IDLE event
and  not idle   - real C0 (executing instructions)
or however this gets mapped makes things even worse.

Damn, it could be that easy and straight forward, but I agree that
this kills the approach to trigger state 0 event if C0 is entered
(C0 as defined as operational mode executing instructions).

 Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] PERF(kernel): Cleanup power events

[Arjan van de Ven]

On 10/25/2010 7:36 AM, Thomas Renninger wrote:

I know that your new API tries to use 0 as exit, but 0 is already
taken (in all power terminology at least on x86 it is) for this.

cpuidle indeed misuses C0 as poll idle state.
That's really bad/misleading, but nothing that can be changed easily.

I agree shifting C0 (cpuidle)-  POLL_IDLE event
and  not idle-  real C0 (executing instructions)
or however this gets mapped makes things even worse.

Damn, it could be that easy and straight forward, but I agree that
this kills the approach to trigger state 0 event if C0 is entered
(C0 as defined as operational mode executing instructions).


ok so we have

C0 idle
and
C0 no longer idle

I'd propose using the number 0 for the first one (it makes the most 
logical sense, it's the least deep idle state etc etc)


we could use -1 or INT_MAX for the later

but as a user of the API I rather like a separate we're no longer idle 
event... but if not, as long as things aren't ambigious I'll find a way 
to code around it.
basically with a separate event, I demultiplex based on event number 
between entry and exit with a special exit value I would just need a 
double demultiplex,
one on idle and then a second one on the state number to split between 
entry/exit.


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] PERF(kernel): Cleanup power events

[Thomas Renninger]

On Monday 25 October 2010 16:56:04 Ingo Molnar wrote:
 
 * Arjan van de Ven ar...@linux.intel.com wrote:
  On 10/25/2010 7:36 AM, Thomas Renninger wrote:
  ok so we have
  
  C0 idle
Ideally this should not be called C0, but expressed
as (#define) POLL_IDLE wherever possible.

In all documentations/specs/white papers about other OSes
C0 is refered to as not being idle.
Linux mis-uses it as a self-defined idle state which
is really confusing.

  and
  C0 no longer idle
  
  I'd propose using the number 0 for the first one (it makes the most
  logical sense, it's the least deep idle state etc etc)
I would use a special number for the Linux only state.

  we could use -1 or INT_MAX for the later
  but as a user of the API I rather like a separate we're no longer idle 
  event... 
  but if not, as long as things aren't ambigious I'll find a way to code 
  around it.
 
  basically with a separate event, I demultiplex based on event number 
  between entry 
  and exit with a special exit value I would just need a double 
  demultiplex,
 
 Hm, does not sound particularly smart.
 
  one on idle and then a second one on the state number to split between 
  entry/exit.
 
 The thing is, in terms of CPU idle state, if the old tracepoints give us all 
 the 
 information that the new tracepoints, why dont we simply add the tracepoints 
 to ARM 
 and be done with it? No app needs to be changed in that case, etc.
 
 Plus, lets express the suspend/resume tracepoints as 
 suspend_enter(X)/suspend_exit() 
 events as well, to keep it symmetric and consistent with the other enter/exit 
 events.
 
 The rename alone isnt a strong enough reason really. 'entering idle state X' 
 and 
 'exiting idle' is pretty much synonymous to 'enter idle state X'.
It's not only that, my patch also:
  - eleminates the never ever used type= field
  - uses a better name, currently it's power:power_{start,end}
How would you name another power event...

Altogether, it should justify the proposed cleanup(s).
But with this C0 clash, I am not sure whether:
  1) as Ingo said any clean up
  2) a minimal cleanup:
   - rename power:power_{start,end} to power:processor_idle{start,end}
   - get rid of type= field
  3) or a maximum cleanup:
   - plus not use start/end events, but use one state transition
 event.
should be done.
I think best is Jean goes with current definitions.
2. is far less intrusive and if you like to have it, I can
still send another patch.

 Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] PERF(kernel): Cleanup power events

[Arjan van de Ven]

On 10/25/2010 8:48 AM, Thomas Renninger wrote:

On Monday 25 October 2010 16:56:04 Ingo Molnar wrote:

* Arjan van de Venar...@linux.intel.com  wrote:

On 10/25/2010 7:36 AM, Thomas Renninger wrote:
ok so we have

C0 idle

Ideally this should not be called C0, but expressed
as (#define) POLL_IDLE wherever possible.

In all documentations/specs/white papers about other OSes
C0 is refered to as not being idle.
Linux mis-uses it as a self-defined idle state which
is really confusing.


sure naming is one thing

and
C0 no longer idle

I'd propose using the number 0 for the first one (it makes the most
logical sense, it's the least deep idle state etc etc)

I would use a special number for the Linux only state.


that special number is 0 though..
it makes sense in ordering, 0  1, 1  2 etc



0 makes for a really bad special number for the exit marker; not just here,
but also for your suspend hook, that one definitely needs to change
(since current commercially available SOCs already reuse 0 for this for 
standby level states)



--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 08/11] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers

[Kevin Hilman]

Gopinath, Thara th...@ti.com writes:

-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, October 22, 2010 10:22 PM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: Re: [PATCH v3 08/11] OMAP3: PM: Adding debug support to Voltage and
Smartreflex drivers

Gopinath, Thara th...@ti.com writes:

Thara Gopinath th...@ti.com writes:

 This patch adds debug support to the voltage and smartreflex drivers.
 This means a whole bunch of voltage processor and smartreflex
 parameters are now visible through the pm debugfs. By default
 only a read of these parameters are permitted. If you need to
 write into them then
 echo 1  /pm_debug/enable_sr_vp_debug

Why a read-only interface by default?   As a debug interface it seems
redundant to have to enable it.


 Read-only interface by default so that we can read these values from
 user space even if we do not want to manipulate it from user-side.


If we do not want to manipulate it from the user-side, then simply don't
write to it.   Remember, this is a debug interface, not a primary
interface.

I think the enable_sr_vp_debug flag should disappear, and it should be a
read/write interface.

If the values are changed via debugfs, then set some per-SR instance
flag that can be checked.

Basically, the current code is confusing because you're using the the
flag called 'enable' to determine whether the user *might have* written
the values.

[...]

 +   /*
 +* Getting  vp errorgain based on the voltage. If the debug option
is
 +* enabled allow the override of errorgain from user side.
 +*/

As suggested in earlier comment, please use a specific flag that this
has been overridden instead of the 'debug enabled' flag (which should
disappear, IMO)

 What do you mean by a separate flag. You want a flag to be maintained
 for just this purpose ?

Yes.  I want a flag to be maintained *specifically* for this purpose,
instead of using a much more general flag that only means a user *might*
have overridden the values, use one that specifically means a user *has*
overridden the values.

 Hello Kevin,

 I tried this. Couple of questions/concerns I have.
 1. If you take a look at the definition of these debugfs parameters, the 
 omap_vdd_info struct is not passed as an argument. The actual variables are 
 the parameters. I am not sure how to extract omap_vdd_info from this. Maybe 
 container_of will help, but then it will be clumsy. Same concern for 
 smartreflex  err_minlimit variable. There is no way to get the sr instance 
 except use container of which I am not sure will work or not
 2.Also in voltage layer we export out eight parameters tat can be over-ridden 
 from the user side. I do not think we should be maintaining one flag per 
 variable. The design will be too very clumsy.

I didn't mean to suggest one flag per varialble.  Just one flag to
indicate that the user *has* overridden the defaults.

Kevin

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv5 3/4] iovmm: replace __iounmap with omap_iounmap

[Fernando Guzman Lugo]

Omap platform is omap_iounmap function.

Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
 arch/arm/plat-omap/iovmm.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 93a34d9..5489ca9 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -821,7 +821,7 @@ void iommu_kunmap(struct iommu *obj, u32 da)
struct sg_table *sgt;
typedef void (*func_t)(const void *);
 
-   sgt = unmap_vm_area(obj, da, (func_t)__iounmap,
+   sgt = unmap_vm_area(obj, da, (func_t)omap_iounmap,
IOVMF_LINEAR | IOVMF_MMIO);
if (!sgt)
dev_dbg(obj-dev, %s: No sgt\n, __func__);
-- 
1.6.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv5 2/4] iovmm: add superpages support to fixed da address

[Fernando Guzman Lugo]

This patch adds superpages support to fixed ad address
inside iommu_kmap function.

Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
 arch/arm/plat-omap/iovmm.c |   62 +--
 1 files changed, 36 insertions(+), 26 deletions(-)

diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 34f0012..93a34d9 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -87,35 +87,43 @@ static size_t sgtable_len(const struct sg_table *sgt)
 }
 #define sgtable_ok(x)  (!!sgtable_len(x))
 
+static unsigned max_alignment(u32 addr)
+{
+   int i;
+   unsigned pagesize[] = { SZ_16M, SZ_1M, SZ_64K, SZ_4K, };
+   for (i = 0; i  ARRAY_SIZE(pagesize)  addr  (pagesize[i] - 1); i++)
+   ;
+   return (i  ARRAY_SIZE(pagesize)) ? pagesize[i] : 0;
+}
+
 /*
  * calculate the optimal number sg elements from total bytes based on
  * iommu superpages
  */
-static unsigned int sgtable_nents(size_t bytes)
+static unsigned sgtable_nents(size_t bytes, u32 da, u32 pa)
 {
-   int i;
-   unsigned int nr_entries;
-   const unsigned long pagesize[] = { SZ_16M, SZ_1M, SZ_64K, SZ_4K, };
+   unsigned nr_entries = 0, ent_sz;
 
if (!IS_ALIGNED(bytes, PAGE_SIZE)) {
pr_err(%s: wrong size %08x\n, __func__, bytes);
return 0;
}
 
-   nr_entries = 0;
-   for (i = 0; i  ARRAY_SIZE(pagesize); i++) {
-   if (bytes = pagesize[i]) {
-   nr_entries += (bytes / pagesize[i]);
-   bytes %= pagesize[i];
-   }
+   while (bytes) {
+   ent_sz = max_alignment(da | pa);
+   ent_sz = min_t(unsigned, ent_sz, iopgsz_max(bytes));
+   nr_entries++;
+   da += ent_sz;
+   pa += ent_sz;
+   bytes -= ent_sz;
}
-   BUG_ON(bytes);
 
return nr_entries;
 }
 
 /* allocate and initialize sg_table header(a kind of 'superblock') */
-static struct sg_table *sgtable_alloc(const size_t bytes, u32 flags)
+static struct sg_table *sgtable_alloc(const size_t bytes, u32 flags,
+   u32 da, u32 pa)
 {
unsigned int nr_entries;
int err;
@@ -127,9 +135,8 @@ static struct sg_table *sgtable_alloc(const size_t bytes, 
u32 flags)
if (!IS_ALIGNED(bytes, PAGE_SIZE))
return ERR_PTR(-EINVAL);
 
-   /* FIXME: IOVMF_DA_FIXED should support 'superpages' */
-   if ((flags  IOVMF_LINEAR)  (flags  IOVMF_DA_ANON)) {
-   nr_entries = sgtable_nents(bytes);
+   if (flags  IOVMF_LINEAR) {
+   nr_entries = sgtable_nents(bytes, da, pa);
if (!nr_entries)
return ERR_PTR(-EINVAL);
} else
@@ -409,7 +416,8 @@ static inline void sgtable_drain_vmalloc(struct sg_table 
*sgt)
BUG_ON(!sgt);
 }
 
-static void sgtable_fill_kmalloc(struct sg_table *sgt, u32 pa, size_t len)
+static void sgtable_fill_kmalloc(struct sg_table *sgt, u32 pa, u32 da,
+   size_t len)
 {
unsigned int i;
struct scatterlist *sg;
@@ -418,9 +426,10 @@ static void sgtable_fill_kmalloc(struct sg_table *sgt, u32 
pa, size_t len)
va = phys_to_virt(pa);
 
for_each_sg(sgt-sgl, sg, sgt-nents, i) {
-   size_t bytes;
+   unsigned bytes;
 
-   bytes = iopgsz_max(len);
+   bytes = max_alignment(da | pa);
+   bytes = min_t(unsigned, bytes, iopgsz_max(len));
 
BUG_ON(!iopgsz_ok(bytes));
 
@@ -429,6 +438,7 @@ static void sgtable_fill_kmalloc(struct sg_table *sgt, u32 
pa, size_t len)
 * 'pa' is cotinuous(linear).
 */
pa += bytes;
+   da += bytes;
len -= bytes;
}
BUG_ON(len);
@@ -695,18 +705,18 @@ u32 iommu_vmalloc(struct iommu *obj, u32 da, size_t 
bytes, u32 flags)
if (!va)
return -ENOMEM;
 
-   sgt = sgtable_alloc(bytes, flags);
+   flags = IOVMF_HW_MASK;
+   flags |= IOVMF_DISCONT;
+   flags |= IOVMF_ALLOC;
+   flags |= (da ? IOVMF_DA_FIXED : IOVMF_DA_ANON);
+
+   sgt = sgtable_alloc(bytes, flags, da, 0);
if (IS_ERR(sgt)) {
da = PTR_ERR(sgt);
goto err_sgt_alloc;
}
sgtable_fill_vmalloc(sgt, va);
 
-   flags = IOVMF_HW_MASK;
-   flags |= IOVMF_DISCONT;
-   flags |= IOVMF_ALLOC;
-   flags |= (da ? IOVMF_DA_FIXED : IOVMF_DA_ANON);
-
da = __iommu_vmap(obj, da, sgt, va, bytes, flags);
if (IS_ERR_VALUE(da))
goto err_iommu_vmap;
@@ -746,11 +756,11 @@ static u32 __iommu_kmap(struct iommu *obj, u32 da, u32 
pa, void *va,
 {
struct sg_table *sgt;
 
-   sgt = sgtable_alloc(bytes, flags);
+   sgt = sgtable_alloc(bytes, flags, da, pa);
if 

[PATCHv5 4/4] iommu: create new api to set valid da range

[Fernando Guzman Lugo]

Some IOMMUs cannot use the whole 0x0 - 0x rage.
With this new API the valid range can be set.

Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
 arch/arm/plat-omap/include/plat/iommu.h |3 ++
 arch/arm/plat-omap/iommu.c  |   33 +++
 arch/arm/plat-omap/iovmm.c  |   18 ++--
 3 files changed, 47 insertions(+), 7 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/iommu.h 
b/arch/arm/plat-omap/include/plat/iommu.h
index 33c7d41..2ea8ea3 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -103,6 +103,8 @@ struct iommu_platform_data {
const char *name;
const char *clk_name;
const int nr_tlb_entries;
+   u32 da_start;
+   u32 da_end;
 };
 
 #if defined(CONFIG_ARCH_OMAP1)
@@ -152,6 +154,7 @@ extern void flush_iotlb_all(struct iommu *obj);
 extern int iopgtable_store_entry(struct iommu *obj, struct iotlb_entry *e);
 extern size_t iopgtable_clear_entry(struct iommu *obj, u32 iova);
 
+extern int iommu_set_da_range(struct iommu *obj, u32 start, u32 end);
 extern struct iommu *iommu_get(const char *name);
 extern void iommu_put(struct iommu *obj);
 
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index 6cd151b..b3846bd 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -25,6 +25,12 @@
 
 #include iopgtable.h
 
+/* Reserve the first page for NULL */
+#define IOMMU_DEFAULT_DA_START PAGE_SIZE
+/* 0x not allowed because it is not page aligned */
+#define IOMMU_DEFAULT_DA_END   0xF000
+
+
 #define for_each_iotlb_cr(obj, n, __i, cr) \
for (__i = 0;   \
 (__i  (n))  (cr = __iotlb_read_cr((obj), __i), true);   \
@@ -830,6 +836,31 @@ static int device_match_by_alias(struct device *dev, void 
*data)
 }
 
 /**
+ * iommu_set_da_range - Set a valid device address range
+ * @obj:   target iommu
+ * @start  Start of valid range
+ * @endEnd of valid range
+ **/
+int iommu_set_da_range(struct iommu *obj, u32 start, u32 end)
+{
+   struct iommu_platform_data *pdata;
+
+   if (!obj)
+   return -EFAULT;
+
+   if (end  start || !PAGE_ALIGN(start | end))
+   return -EINVAL;
+
+   pdata = obj-dev-platform_data;
+
+   pdata-da_start = start;
+   pdata-da_end = end;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(iommu_set_da_range);
+
+/**
  * iommu_get - Get iommu handler
  * @name:  target iommu name
  **/
@@ -853,6 +884,8 @@ struct iommu *iommu_get(const char *name)
if (err)
goto err_enable;
flush_iotlb_all(obj);
+   iommu_set_da_range(obj, IOMMU_DEFAULT_DA_START,
+   IOMMU_DEFAULT_DA_END);
}
 
if (!try_module_get(obj-owner))
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 5489ca9..3809add 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -272,21 +272,25 @@ static struct iovm_struct *alloc_iovm_area(struct iommu 
*obj, u32 da,
 {
struct iovm_struct *new, *tmp;
u32 start, prev_end, alignement;
+   struct iommu_platform_data *pdata;
 
if (!obj || !bytes)
return ERR_PTR(-EINVAL);
 
+   pdata = obj-dev-platform_data;
+
start = da;
alignement = PAGE_SIZE;
 
if (flags  IOVMF_DA_ANON) {
-   /*
-* Reserve the first page for NULL
-*/
-   start = PAGE_SIZE;
+   start = pdata-da_start;
+
if (flags  IOVMF_LINEAR)
alignement = iopgsz_max(bytes);
start = roundup(start, alignement);
+   } else if (start  pdata-da_start || start  pdata-da_end ||
+   pdata-da_end - start  bytes) {
+   return ERR_PTR(-EINVAL);
}
 
tmp = NULL;
@@ -299,16 +303,16 @@ static struct iovm_struct *alloc_iovm_area(struct iommu 
*obj, u32 da,
if (prev_end  start)
break;
 
-   if (start + bytes = tmp-da_start)
+   if (tmp-da_start  start  (tmp-da_start - start) = bytes)
goto found;
 
-   if (flags  IOVMF_DA_ANON)
+   if (tmp-da_end = start  flags  IOVMF_DA_ANON)
start = roundup(tmp-da_end + 1, alignement);
 
prev_end = tmp-da_end;
}
 
-   if ((start = prev_end)  (ULONG_MAX - start + 1 = bytes))
+   if ((start = prev_end)  (pdata-da_end - start = bytes))
goto found;
 
dev_dbg(obj-dev, %s: no space to fit %08x(%x) flags: %08x\n,
-- 
1.6.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to 

[PATCHv5 0/4] iovmm: fixes for iovmm module

[Fernando Guzman Lugo]

Version 5:
* Changes in iommu: create new api to set valid da range
  - Change range variables to platform data structure.

Version 4:
* Changes in iommu: create new api to set valid da range
  - Validate range for fixed address.
  - Change way of change boundaries to avoid possible overflow
instead of style :
   start + bytes = end which start + end can overflow
use style:
   end - start  bytes

Version 3:
* change patch 2 base on Felipe Contreras' comments,
  now it uses min_t and I deleted some blank lines.
* patch create new api to set valid da range is base on
  iovmm: IVA2 MMU range is from 0x1100 to 0x
  patch and on Hiroshi's comments and now it is added to
  this set.

Version 2:
* Removed iovmm: fixes for iovmm module that patch was already
  sent.
* Modified iovmm: fix roundup for next area and end check for the
  last area patch, base on Davin Cohen's comments and rename it
  to a proper name that describes what it is doing now.

*** BLURB HERE ***

Fernando Guzman Lugo (4):
  iovmm: no gap checking for fixed address
  iovmm: add superpages support to fixed da address
  iovmm: replace __iounmap with omap_iounmap
  iommu: create new api to set valid da range

 arch/arm/plat-omap/include/plat/iommu.h |3 +
 arch/arm/plat-omap/iommu.c  |   33 
 arch/arm/plat-omap/iovmm.c  |   84 ++-
 3 files changed, 85 insertions(+), 35 deletions(-)

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv5 1/4] iovmm: no gap checking for fixed address

[Fernando Guzman Lugo]

If some fixed da address is wanted to be mapped and the page
is freed but it is used as gap, the mapping will fail.
This patch is fixing that and olny keeps the gap for
not fixed address.

Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
 arch/arm/plat-omap/iovmm.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 24ca9c4..34f0012 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -289,7 +289,7 @@ static struct iovm_struct *alloc_iovm_area(struct iommu 
*obj, u32 da,
prev_end = 0;
list_for_each_entry(tmp, obj-mmap, list) {
 
-   if (prev_end = start)
+   if (prev_end  start)
break;
 
if (start + bytes = tmp-da_start)
@@ -301,7 +301,7 @@ static struct iovm_struct *alloc_iovm_area(struct iommu 
*obj, u32 da,
prev_end = tmp-da_end;
}
 
-   if ((start  prev_end)  (ULONG_MAX - start = bytes))
+   if ((start = prev_end)  (ULONG_MAX - start + 1 = bytes))
goto found;
 
dev_dbg(obj-dev, %s: no space to fit %08x(%x) flags: %08x\n,
-- 
1.6.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] omap updates for 2.6.37

[Tony Lindgren]

Hi Linus,

Please pull omap updates from:

git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git 
omap-for-linus

There are few minor merge conflicts, but I've left them unmerged as I believe
that's the way you want them nowadays. The merge conflicts are just overlapping
additions, and a OMAP2/OMAP2 vs OMAP24XX/OMAP34XX ifdef issue where the former 
is
the way to go. Looks like the crypto device platform data got accidentally added
in both the crypto and omap trees.

I've also pushed a omap-for-linus-merged branch in case you don't want to
do the merging of the conflicts.

Regards,

Tony


The following changes since commit 33081adf8b89d5a716d7e1c60171768d39795b39:

  Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6 (2010-10-25 
08:32:05 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git 
omap-for-linus

Anand Gadiyar (3):
  omap: usb: fix build warning
  ASoC: OMAP4: MCPDM: Remove unnecessary include of plat/control.h
  omap: complete removal of machine_desc.io_pg_offst and .phys_io

Benoit Cousson (14):
  OMAP: hwmod: Rename dma_ch to dma_req
  OMAP: hwmod: Do not disable clocks if hwmod already in idle
  OMAP4: prcm: Add temporarily helper functions for rmw and read inside the 
PRM
  OMAP: hwmod: Force a softreset during _setup
  OMAP: hwmod: Fix softreset status check for some new OMAP4 IPs
  OMAP: hwmod: Fix softreset for modules with optional clocks
  OMAP4: hwmod: Add initial data for OMAP4430 ES1  ES2
  OMAP4: pm: Change l3_main to l3_main_1 during bus device init
  OMAP4: clock: Fix clock names and align with hwmod names
  OMAP4: clock: Add optional clock nodes
  OMAP4: clocks: Fix ES2 clock issues
  OMAP4: hwmod data: Add watchdog timer
  OMAP4: UART: Add uart1-4 hwmods data for omap4
  omap4 hsmmc: Fix the init if CONFIG_MMC_OMAP_HS is not set

Benoît Cousson (2):
  OMAP4: PRM: add module hard reset support
  OMAP: hwmod: Add hardreset management support

Charulatha V (1):
  OMAP2PLUS: WDT: Fix: Disable WDT after reset during init

Cory Maccarrone (1):
  HTCHERALD: MMC, I2C, HTCPLD, SPI, TSC2046

David Anders (4):
  omap4: Panda: Add DEBUG_LL support
  omap4: pandaboard: remove unused hsmmc definition
  omap4: pandaboard: Fix the init if CONFIG_MMC_OMAP_HS is not set
  omap4: pandaboard: enable the ehci port on pandaboard

Dmitry Kasatkin (1):
  omap: crypto: updates to enable omap aes

Enric Balletbo i Serra (7):
  omap3: Add minimal OMAP3 IGEP module support
  omap3: Add external VBUS power switch and overcurrent detect onIGEP v2 
board
  omap3: fix and improve the LED handling on IGEP v2 board
  omap3: Introduce function to detect the IGEP v2 hardwarerevision
  omap3: Fix handling some GPIO's for WLAN-BT combo on IGEP v2
  omap3: Add i2c eeprom driver to read EDID on IGEP v2
  omap3: Remove VMMC2 regulator on IGEP v2

Govindraj.R (8):
  OMAP2: UART: remove set_uart_globals
  OMAP clock: Add uart4_ick/fck definitions for 3630
  OMAP3: PRCM: Consider UART4 for 3630 chip in prcm_setup_regs
  OMAP3: PM: Add prepare idle and resume idle call for uart4
  OMAP3: serial: Fix uart4 handling for 3630
  serial: Add OMAP high-speed UART driver
  OMAP: SERIAL: Enable omap-serial driver in Kconfig
  OMAP3: SERIAL: Initialize all omap-uarts for zoom boards

Grazvydas Ignotas (2):
  omap: pandora: add fixed regulator for wlan
  omap: pandora: enable twl4030 charger

Hema HK (1):
  OMAP: hwmod: Set autoidle after smartidle during _sysc_enable

Igor Grinberg (5):
  omap3: Introduce CompuLab CM-T3517 module
  omap3: cm-t3517: add support for v3020 rtc
  omap3: cm-t3517: add support for usb host
  omap3: cm-t3517: add support for NAND flash
  omap3: cm-t3517: add support for TI HECC

Janusz Krzysztofik (3):
  OMAP1: Add support for SoC camera interface
  OMAP1: Amstrad Delta: add support for camera
  OMAP1: Amstrad Delta: add camera controlled LEDS trigger

Jarkko Nikula (8):
  omap: n8x0: Cleanup i2c1 and menelaus registration
  omap: n8x0: Register i2c2 and add board info with tlv320aic3xfor N810
  omap: n8x0: Mux i2s codec port pins for McBSP block
  omap2: McBSP: Remove mux code for OMAP2420 McBSP2 and do cleanups
  OMAP: McBSP: Fix CLKR and FSR signal muxing
  OMAP: McBSP: Swap CLKS source definition
  OMAP: McBSP: Remove null omap44xx ops comment
  omap: dma: Fix buffering disable bit setting for omap24xx

Jon Hunter (1):
  omap3: Prevent SDRC deadlock when L3 is changing frequency

Kevin Hilman (20):
  OMAP3: PM: whitespace cleanup around IO wakeup enable
  OMAP2+: PM: initial runtime PM core support
  OMAP1: PM: add simple runtime PM layer to manage clocks
  OMAP: hwmod: separate list locking and hwmod hardware locking

[PATCH] omap: mailbox: remove unreachable return

[Omar Ramirez Luna]

Remove unreachable return statement.

Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
 arch/arm/mach-omap2/mailbox.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index a0af532..7dc9fa6 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -437,8 +437,6 @@ static int __devinit omap2_mbox_probe(struct 
platform_device *pdev)
return ret;
}
return 0;
-
-   return ret;
 }
 
 static int __devexit omap2_mbox_remove(struct platform_device *pdev)
-- 
1.7.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCHv5 0/4] iovmm: fixes for iovmm module

[Guzman Lugo, Fernando]

Please discard this set of patches I will send them again with
The correct prefix (omap) to avoid confusion with other
Iommu componets.

Sorry for the noise.

Regards,
Fernando.

 -Original Message-
 From: Guzman Lugo, Fernando 
 Sent: Monday, October 25, 2010 1:52 PM
 To: hiroshi.d...@nokia.com
 Cc: felipe.contre...@nokia.com; t...@atomide.com; 
 linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; 
 linux-omap@vger.kernel.org; Guzman Lugo, Fernando
 Subject: [PATCHv5 0/4] iovmm: fixes for iovmm module
 
 Version 5:
 * Changes in iommu: create new api to set valid da range
   - Change range variables to platform data structure.
 
 Version 4:
 * Changes in iommu: create new api to set valid da range
   - Validate range for fixed address.
   - Change way of change boundaries to avoid possible overflow
 instead of style :
start + bytes = end which start + end can overflow
 use style:
end - start  bytes
 
 Version 3:
 * change patch 2 base on Felipe Contreras' comments,
   now it uses min_t and I deleted some blank lines.
 * patch create new api to set valid da range is base on
   iovmm: IVA2 MMU range is from 0x1100 to 0x
   patch and on Hiroshi's comments and now it is added to
   this set.
 
 Version 2:
 * Removed iovmm: fixes for iovmm module that patch was already
   sent.
 * Modified iovmm: fix roundup for next area and end check for the
   last area patch, base on Davin Cohen's comments and rename it
   to a proper name that describes what it is doing now.
 
 *** BLURB HERE ***
 
 Fernando Guzman Lugo (4):
   iovmm: no gap checking for fixed address
   iovmm: add superpages support to fixed da address
   iovmm: replace __iounmap with omap_iounmap
   iommu: create new api to set valid da range
 
  arch/arm/plat-omap/include/plat/iommu.h |3 +
  arch/arm/plat-omap/iommu.c  |   33 
  arch/arm/plat-omap/iovmm.c  |   84 
 ++-
  3 files changed, 85 insertions(+), 35 deletions(-)
 
 --
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv5 0/4] omap: iovmm - fixes for iovmm module

[Fernando Guzman Lugo]

Version 5:
* Changes in iommu: create new api to set valid da range
  - Change range variables to platform data structure.

Version 4:
* Changes in iommu: create new api to set valid da range
  - Validate range for fixed address.
  - Change way of change boundaries to avoid possible overflow
instead of style :
   start + bytes = end which start + end can overflow
use style:
   end - start  bytes

Version 3:
* change patch 2 base on Felipe Contreras' comments,
  now it uses min_t and I deleted some blank lines.
* patch create new api to set valid da range is base on
  iovmm: IVA2 MMU range is from 0x1100 to 0x
  patch and on Hiroshi's comments and now it is added to
  this set.

Version 2:
* Removed iovmm: fixes for iovmm module that patch was already
  sent.
* Modified iovmm: fix roundup for next area and end check for the
  last area patch, base on Davin Cohen's comments and rename it
  to a proper name that describes what it is doing now.

*** BLURB HERE ***

Fernando Guzman Lugo (4):
  iovmm: no gap checking for fixed address
  iovmm: add superpages support to fixed da address
  iovmm: replace __iounmap with omap_iounmap
  iommu: create new api to set valid da range

 arch/arm/plat-omap/include/plat/iommu.h |3 +
 arch/arm/plat-omap/iommu.c  |   33 
 arch/arm/plat-omap/iovmm.c  |   84 ++-
 3 files changed, 85 insertions(+), 35 deletions(-)

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv5 2/4] omap: iovmm - add superpages support to fixed da address

[Fernando Guzman Lugo]

This patch adds superpages support to fixed ad address
inside iommu_kmap function.

Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
 arch/arm/plat-omap/iovmm.c |   62 +--
 1 files changed, 36 insertions(+), 26 deletions(-)

diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 34f0012..93a34d9 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -87,35 +87,43 @@ static size_t sgtable_len(const struct sg_table *sgt)
 }
 #define sgtable_ok(x)  (!!sgtable_len(x))
 
+static unsigned max_alignment(u32 addr)
+{
+   int i;
+   unsigned pagesize[] = { SZ_16M, SZ_1M, SZ_64K, SZ_4K, };
+   for (i = 0; i  ARRAY_SIZE(pagesize)  addr  (pagesize[i] - 1); i++)
+   ;
+   return (i  ARRAY_SIZE(pagesize)) ? pagesize[i] : 0;
+}
+
 /*
  * calculate the optimal number sg elements from total bytes based on
  * iommu superpages
  */
-static unsigned int sgtable_nents(size_t bytes)
+static unsigned sgtable_nents(size_t bytes, u32 da, u32 pa)
 {
-   int i;
-   unsigned int nr_entries;
-   const unsigned long pagesize[] = { SZ_16M, SZ_1M, SZ_64K, SZ_4K, };
+   unsigned nr_entries = 0, ent_sz;
 
if (!IS_ALIGNED(bytes, PAGE_SIZE)) {
pr_err(%s: wrong size %08x\n, __func__, bytes);
return 0;
}
 
-   nr_entries = 0;
-   for (i = 0; i  ARRAY_SIZE(pagesize); i++) {
-   if (bytes = pagesize[i]) {
-   nr_entries += (bytes / pagesize[i]);
-   bytes %= pagesize[i];
-   }
+   while (bytes) {
+   ent_sz = max_alignment(da | pa);
+   ent_sz = min_t(unsigned, ent_sz, iopgsz_max(bytes));
+   nr_entries++;
+   da += ent_sz;
+   pa += ent_sz;
+   bytes -= ent_sz;
}
-   BUG_ON(bytes);
 
return nr_entries;
 }
 
 /* allocate and initialize sg_table header(a kind of 'superblock') */
-static struct sg_table *sgtable_alloc(const size_t bytes, u32 flags)
+static struct sg_table *sgtable_alloc(const size_t bytes, u32 flags,
+   u32 da, u32 pa)
 {
unsigned int nr_entries;
int err;
@@ -127,9 +135,8 @@ static struct sg_table *sgtable_alloc(const size_t bytes, 
u32 flags)
if (!IS_ALIGNED(bytes, PAGE_SIZE))
return ERR_PTR(-EINVAL);
 
-   /* FIXME: IOVMF_DA_FIXED should support 'superpages' */
-   if ((flags  IOVMF_LINEAR)  (flags  IOVMF_DA_ANON)) {
-   nr_entries = sgtable_nents(bytes);
+   if (flags  IOVMF_LINEAR) {
+   nr_entries = sgtable_nents(bytes, da, pa);
if (!nr_entries)
return ERR_PTR(-EINVAL);
} else
@@ -409,7 +416,8 @@ static inline void sgtable_drain_vmalloc(struct sg_table 
*sgt)
BUG_ON(!sgt);
 }
 
-static void sgtable_fill_kmalloc(struct sg_table *sgt, u32 pa, size_t len)
+static void sgtable_fill_kmalloc(struct sg_table *sgt, u32 pa, u32 da,
+   size_t len)
 {
unsigned int i;
struct scatterlist *sg;
@@ -418,9 +426,10 @@ static void sgtable_fill_kmalloc(struct sg_table *sgt, u32 
pa, size_t len)
va = phys_to_virt(pa);
 
for_each_sg(sgt-sgl, sg, sgt-nents, i) {
-   size_t bytes;
+   unsigned bytes;
 
-   bytes = iopgsz_max(len);
+   bytes = max_alignment(da | pa);
+   bytes = min_t(unsigned, bytes, iopgsz_max(len));
 
BUG_ON(!iopgsz_ok(bytes));
 
@@ -429,6 +438,7 @@ static void sgtable_fill_kmalloc(struct sg_table *sgt, u32 
pa, size_t len)
 * 'pa' is cotinuous(linear).
 */
pa += bytes;
+   da += bytes;
len -= bytes;
}
BUG_ON(len);
@@ -695,18 +705,18 @@ u32 iommu_vmalloc(struct iommu *obj, u32 da, size_t 
bytes, u32 flags)
if (!va)
return -ENOMEM;
 
-   sgt = sgtable_alloc(bytes, flags);
+   flags = IOVMF_HW_MASK;
+   flags |= IOVMF_DISCONT;
+   flags |= IOVMF_ALLOC;
+   flags |= (da ? IOVMF_DA_FIXED : IOVMF_DA_ANON);
+
+   sgt = sgtable_alloc(bytes, flags, da, 0);
if (IS_ERR(sgt)) {
da = PTR_ERR(sgt);
goto err_sgt_alloc;
}
sgtable_fill_vmalloc(sgt, va);
 
-   flags = IOVMF_HW_MASK;
-   flags |= IOVMF_DISCONT;
-   flags |= IOVMF_ALLOC;
-   flags |= (da ? IOVMF_DA_FIXED : IOVMF_DA_ANON);
-
da = __iommu_vmap(obj, da, sgt, va, bytes, flags);
if (IS_ERR_VALUE(da))
goto err_iommu_vmap;
@@ -746,11 +756,11 @@ static u32 __iommu_kmap(struct iommu *obj, u32 da, u32 
pa, void *va,
 {
struct sg_table *sgt;
 
-   sgt = sgtable_alloc(bytes, flags);
+   sgt = sgtable_alloc(bytes, flags, da, pa);
if 

[PATCHv5 3/4] omap: iovmm - replace __iounmap with omap_iounmap

[Fernando Guzman Lugo]

Omap platform is omap_iounmap function.

Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
 arch/arm/plat-omap/iovmm.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 93a34d9..5489ca9 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -821,7 +821,7 @@ void iommu_kunmap(struct iommu *obj, u32 da)
struct sg_table *sgt;
typedef void (*func_t)(const void *);
 
-   sgt = unmap_vm_area(obj, da, (func_t)__iounmap,
+   sgt = unmap_vm_area(obj, da, (func_t)omap_iounmap,
IOVMF_LINEAR | IOVMF_MMIO);
if (!sgt)
dev_dbg(obj-dev, %s: No sgt\n, __func__);
-- 
1.6.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv5 4/4] omap: iommu - create new api to set valid da range

[Fernando Guzman Lugo]

Some IOMMUs cannot use the whole 0x0 - 0x rage.
With this new API the valid range can be set.

Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
 arch/arm/plat-omap/include/plat/iommu.h |3 ++
 arch/arm/plat-omap/iommu.c  |   33 +++
 arch/arm/plat-omap/iovmm.c  |   18 ++--
 3 files changed, 47 insertions(+), 7 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/iommu.h 
b/arch/arm/plat-omap/include/plat/iommu.h
index 33c7d41..2ea8ea3 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -103,6 +103,8 @@ struct iommu_platform_data {
const char *name;
const char *clk_name;
const int nr_tlb_entries;
+   u32 da_start;
+   u32 da_end;
 };
 
 #if defined(CONFIG_ARCH_OMAP1)
@@ -152,6 +154,7 @@ extern void flush_iotlb_all(struct iommu *obj);
 extern int iopgtable_store_entry(struct iommu *obj, struct iotlb_entry *e);
 extern size_t iopgtable_clear_entry(struct iommu *obj, u32 iova);
 
+extern int iommu_set_da_range(struct iommu *obj, u32 start, u32 end);
 extern struct iommu *iommu_get(const char *name);
 extern void iommu_put(struct iommu *obj);
 
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index 6cd151b..b3846bd 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -25,6 +25,12 @@
 
 #include iopgtable.h
 
+/* Reserve the first page for NULL */
+#define IOMMU_DEFAULT_DA_START PAGE_SIZE
+/* 0x not allowed because it is not page aligned */
+#define IOMMU_DEFAULT_DA_END   0xF000
+
+
 #define for_each_iotlb_cr(obj, n, __i, cr) \
for (__i = 0;   \
 (__i  (n))  (cr = __iotlb_read_cr((obj), __i), true);   \
@@ -830,6 +836,31 @@ static int device_match_by_alias(struct device *dev, void 
*data)
 }
 
 /**
+ * iommu_set_da_range - Set a valid device address range
+ * @obj:   target iommu
+ * @start  Start of valid range
+ * @endEnd of valid range
+ **/
+int iommu_set_da_range(struct iommu *obj, u32 start, u32 end)
+{
+   struct iommu_platform_data *pdata;
+
+   if (!obj)
+   return -EFAULT;
+
+   if (end  start || !PAGE_ALIGN(start | end))
+   return -EINVAL;
+
+   pdata = obj-dev-platform_data;
+
+   pdata-da_start = start;
+   pdata-da_end = end;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(iommu_set_da_range);
+
+/**
  * iommu_get - Get iommu handler
  * @name:  target iommu name
  **/
@@ -853,6 +884,8 @@ struct iommu *iommu_get(const char *name)
if (err)
goto err_enable;
flush_iotlb_all(obj);
+   iommu_set_da_range(obj, IOMMU_DEFAULT_DA_START,
+   IOMMU_DEFAULT_DA_END);
}
 
if (!try_module_get(obj-owner))
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 5489ca9..3809add 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -272,21 +272,25 @@ static struct iovm_struct *alloc_iovm_area(struct iommu 
*obj, u32 da,
 {
struct iovm_struct *new, *tmp;
u32 start, prev_end, alignement;
+   struct iommu_platform_data *pdata;
 
if (!obj || !bytes)
return ERR_PTR(-EINVAL);
 
+   pdata = obj-dev-platform_data;
+
start = da;
alignement = PAGE_SIZE;
 
if (flags  IOVMF_DA_ANON) {
-   /*
-* Reserve the first page for NULL
-*/
-   start = PAGE_SIZE;
+   start = pdata-da_start;
+
if (flags  IOVMF_LINEAR)
alignement = iopgsz_max(bytes);
start = roundup(start, alignement);
+   } else if (start  pdata-da_start || start  pdata-da_end ||
+   pdata-da_end - start  bytes) {
+   return ERR_PTR(-EINVAL);
}
 
tmp = NULL;
@@ -299,16 +303,16 @@ static struct iovm_struct *alloc_iovm_area(struct iommu 
*obj, u32 da,
if (prev_end  start)
break;
 
-   if (start + bytes = tmp-da_start)
+   if (tmp-da_start  start  (tmp-da_start - start) = bytes)
goto found;
 
-   if (flags  IOVMF_DA_ANON)
+   if (tmp-da_end = start  flags  IOVMF_DA_ANON)
start = roundup(tmp-da_end + 1, alignement);
 
prev_end = tmp-da_end;
}
 
-   if ((start = prev_end)  (ULONG_MAX - start + 1 = bytes))
+   if ((start = prev_end)  (pdata-da_end - start = bytes))
goto found;
 
dev_dbg(obj-dev, %s: no space to fit %08x(%x) flags: %08x\n,
-- 
1.6.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to 

[PATCHv5 1/4] omap: iovmm - no gap checking for fixed address

[Fernando Guzman Lugo]

If some fixed da address is wanted to be mapped and the page
is freed but it is used as gap, the mapping will fail.
This patch is fixing that and olny keeps the gap for
not fixed address.

Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
 arch/arm/plat-omap/iovmm.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 24ca9c4..34f0012 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -289,7 +289,7 @@ static struct iovm_struct *alloc_iovm_area(struct iommu 
*obj, u32 da,
prev_end = 0;
list_for_each_entry(tmp, obj-mmap, list) {
 
-   if (prev_end = start)
+   if (prev_end  start)
break;
 
if (start + bytes = tmp-da_start)
@@ -301,7 +301,7 @@ static struct iovm_struct *alloc_iovm_area(struct iommu 
*obj, u32 da,
prev_end = tmp-da_end;
}
 
-   if ((start  prev_end)  (ULONG_MAX - start = bytes))
+   if ((start = prev_end)  (ULONG_MAX - start + 1 = bytes))
goto found;
 
dev_dbg(obj-dev, %s: no space to fit %08x(%x) flags: %08x\n,
-- 
1.6.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] omap: add hwspinlock device

[Tony Lindgren]

* Ohad Ben-Cohen o...@wizery.com [101024 10:45]:
 Hi Tony,
 
 On Fri, Oct 22, 2010 at 6:56 PM, Tony Lindgren t...@atomide.com wrote:
  Guys, let's try to come up with a generic interface for this instead of
  polluting the device drivers with more omap specific interfaces.
 
  We really want to keep the drivers generic and platform independent.
 
 I share this concern as well.
 
 We basically have three options here:
 
 1. Have the hwspinlock driver inside the omap folders and use pdata func ptrs
 2. Have a generic hwspinlock framework, with a small omap-specific
 implementation
 3. Have a misc driver which is currently omap specific, but can very
 easily be converted to a common framework
 
 I don't like (1) so much; it's a driver that has very little that is
 hardware specific (mainly just the two lines that actually access the
 hardware - the lock and the unlock), and it's growing. E.g., we will
 need to add it a user space interface (to allow userland IPC
 implementations), we will need to add it a virtual locks layer that
 would provide more locks than the hardware currently has, etc..
 
 In addition, there seem to be a general discontent about drivers
 piling up in the ARM folders, instead of having them visible in
 drivers/ so they can become useful for other platforms as well.
 
 Here's something Linus wrote about this awhile back:
 
 http://www.spinics.net/lists/linux-arm-msm/msg00324.html
 
 So initially I opted for (2). I have an implementation ready - it's a
 common drivers/hwspinlock/core.c framework with a small omap-specific
 part at drivers/hwspinlock/omap_hwspinlock.c. The core has all the
 logic while the latter, omap-specific implementation, is really small
 - it is basically just registering lock instances, that have a
 trylock/unlock/relax ops struct, with the common framework.
 
 But lack of additional users (besides the OMAP hardware), and lack of
 generic drivers that would use it (we have syslink, which currently
 tend to only need this from user space, i2c-omap and omap's upcoming
 resource manager), made it look like an overkill for now.
 
 So simplicity won, and (3) was eventually submitted. It exposes
 exactly the same interface like (2) would (s/omap_hwspin/hwspin/), and
 it's relatively easy to turn it back into a common framework in case
 additional users show up.
 
 But if you feel that (2) is justifiable/desirable, I would be more
 than happy to submit that version.

Yes (2) please. I would assume there will be more use of this. And then
we (or probably me again!) don't have to deal with cleaning up the drivers
again in the future.
 
  Unless somebody has better ideas, I suggest we pass a lock function
  in the platform_data to the drivers that need it, and do the omap
  specific nasty stuff in the platform code.
 
 Do you mean (1) and then pass the whole bunch of APIs
 (request/free/lock variants/unlock/get_id) via pdata ?
 
 Or do you mean a variation of (2) with only the specific locking bits
 coming from pdata func pointers ? I guess that in this case we just
 might as well go with the full (2).

Yes variation of (2) where you only pass the locking function via
platform data would be best.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] PERF(kernel): Cleanup power events

[Rafael J. Wysocki]

On Monday, October 25, 2010, Mathieu Desnoyers wrote:
 * Ingo Molnar (mi...@elte.hu) wrote:
  
  * Thomas Renninger tr...@suse.de wrote:
  
   On Monday 25 October 2010 12:04:28 Ingo Molnar wrote:

* Thomas Renninger tr...@suse.de wrote:

 New power trace events:
 power:processor_idle
 power:processor_frequency
 power:machine_suspend
 
 
 C-state/idle accounting events:
   power:power_start
   power:power_end
 are replaced with:
   power:processor_idle

Well, most power saving hw models (and the code implementing them) have 
this kind of 
model:

 enter power saving mode X
 exit power saving mode

Where X is some sort of 'power saving deepness' attribute, right?
  
   Sure.
  
  Which is is the 'saner' model?
  
   But ACPI and afaik this model got picked up for PCI and other (sub-)archs 
   as well, 
   defines state 0 as the non-power saving mode.
  
  But the actual code does not actually deal with any 'state 0', does it? It 
  enters an 
  idle function and then exits it, right?
  
  'power state' might be what is used for devices - but even there, we have:
  
- enter power state X
- exit power state
  
  right?
  
   Same as done here with machine suspend state (S0 is back from suspend) and
   this model should get picked up when device sleep states get tracked at
   some time.
  
   It's consistent and applies to some well known specifications.
  
  What we want it to be is for it to be the nicest, most understandable, most 
  logical 
  model - not one matching random hardware specifications.
  
  ( Hardware specifications only matter in so far that it should be possible 
  to 
express all the known hardware state transitions via these events 
  efficiently. )
  
   Also tracking processor_idle_{start,end} as a separate event makes no 
   sense and 
   there is no need to introduce: processor_idle_start/processor_idle_end 
   machine_suspend_start/machine_suspend_end 
   device_power_mode_start/device_power_mode_end events.
  
  What do you mean by makes no sense?
  
  Are they superfluous? Inefficient? Illogical?
 
 I think it would require deep understanding of specific power modes of each
 architecture to split into this topology. On the bright side, it would bring
 clear understanding of which HW resource is being put to sleep, which would 
 make
 automated analysis much easier to do. But maybe it's too much pain compared to
 the benefit. The related question is also: where is it best to put this logic 
 ?
 In the kernel code ? In per-arch TRACE_EVENT() handlers or in external trace
 analysis plugins ?
 
  
   Using state 0 as exit/end, is much nicer for kernel/ userspace 
   implementations/code and the user.
  
  By that argument we should not have separate fork() and exit() syscalls 
  either, but 
  a set_process_state(1) and set_process_state(0) interface?
 
 I'm by no mean expert on power saving hardware specs, but if it is possible 
 for
 hardware to switch between two power saving states without passing through 
 power
 state 0, then using a set state rather than an enter/exit would be more
 appropriate; even if we go for a scheme introducing
 
 processor_idle_start/processor_idle_end,
 machine_suspend_start/machine_suspend_end,
 device_power_mode_start/device_power_mode_end.
 
 I must defer to you guys to figure out if some hardware actually do that for
 either of CPU idle, suspend or device power modes.

Yes, you can go directly from PCI_D1 to PCI_D2, for one example.

Apart from this, attempting to put system suspend to the same bag as cpuidle
is not going to work in the long run.  They are _fundamentally_ different things
event though the power state we get into as a result of suspend is approximately
the same as we can get into via cpuidle (even in that case the energy savings
will generally be different in both cases due to wakeup events).

Thanks,
Rafael
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] PERF(kernel): Cleanup power events

[Rafael J. Wysocki]

On Monday, October 25, 2010, Arjan van de Ven wrote:
 On 10/25/2010 4:03 AM, Thomas Renninger wrote:
  On Monday 25 October 2010 12:04:28 Ingo Molnar wrote:
  * Thomas Renningertr...@suse.de  wrote:
 
  New power trace events:
  power:processor_idle
  power:processor_frequency
  power:machine_suspend
 
 
  C-state/idle accounting events:
 power:power_start
 power:power_end
  are replaced with:
 power:processor_idle
  Well, most power saving hw models (and the code implementing them) have 
  this kind of
  model:
 
enter power saving mode X
exit power saving mode
 
  Where X is some sort of 'power saving deepness' attribute, right?
  Sure.
  But ACPI and afaik this model got picked up for PCI and other (sub-)archs
  as well, defines state 0 as the non-power saving mode.
 
 correct ,... C0 is not power efficient... but it's still a valid OS 
 idle state!
 Also tracking processor_idle_{start,end} as a separate event!
 
 same for S0... S0 as standby state is still valid... sure it doesn't 
 save you much power... but that does not mean it's not valid.

If you mean ACPI S0, it is not a standby state.  It actually is the full-power
state.

 (as indication, the Intel Moorestown platform, which is currently in 
 production and available to OEMs, has such a S0 standby state)

Another naming confusion.  How smart.

  makes no sense and there is no need to introduce:
  processor_idle_start/processor_idle_end
  machine_suspend_start/machine_suspend_end
  device_power_mode_start/device_power_mode_end
  events.
  Using state 0 as exit/end, is much nicer for kernel/
  userspace implementations/code and the user.
 actually no; having written a few of these in userspace so far, having a 
 separate end event is easier to deal with;
 the actions you take on entry and exit are complete separate code paths.

That's correct, unless you go directly from one low-power state to another
(which is possible for example for PCI).  We don't do that at the moment,
but it's possible in principle and we may want to start doing that at one
point.

Thanks,
Rafael
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] USB ehci-omap: Remove second kfree() call on the same object

[Matthias Kaehlcke]

Remove second kfree() call on the same object in the error path of
ehci_hcd_omap_probe()

Signed-off-by: Matthias Kaehlcke matth...@kaehlcke.net
---
 drivers/usb/host/ehci-omap.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index e1da3c9..116ae28 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -734,7 +734,6 @@ err_uhh_ioremap:
 
 err_ioremap:
usb_put_hcd(hcd);
-   kfree(omap);
 
 err_create_hcd:
kfree(omap);
-- 
1.7.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] PERF(kernel): Cleanup power events

[Thomas Renninger]

@Ingo: Can you queue up 1/3, it's an independent fix.

On Monday 25 October 2010 06:00:17 pm Arjan van de Ven wrote:
 On 10/25/2010 8:48 AM, Thomas Renninger wrote:
 
 sure naming is one thing
Yes it should get renamed to not show:
cat /sys/devices/system/cpu/cpu0/cpuidle/state0/name
C0
This is wrong and confusing

  and
  C0 no longer idle
 
  I'd propose using the number 0 for the first one (it makes the most
  logical sense, it's the least deep idle state etc etc)
  I would use a special number for the Linux only state.
 
 that special number is 0 though..
 it makes sense in ordering, 0  1, 1  2 etc
As long as it stays a kernel and perf processor_idle internal number
it does not hurt.
But userspace tools catching the perf idle event of state 0 should never
refer to it as processor idle state 0 (or even worse C0).
Instead they should try to get the name/description of:
/sys/../state0/name
or directly refer to it as poll idle state.

Processor idle state C0 is not only defined as not being idle in the
specs, also turbostat and cpufreq-aperf use it correctly and refer to C0 when 
they show accounted not idle time.

Encouraged by your suggestions I send another version.
It's not a big deal to send 0x instead of 0 as non power saving 
state. If you can handle compatibility with it in powertop, it doesn't make 
things more complicated in kernel and perf timechart as I first thought it 
does.

  Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] PERF(kernel): Cleanup power events V2

[Thomas Renninger]

Changes in V2:
  - Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
  - Use u32 instead of u64 for cpuid, state which is by far enough

New power trace events:
power:processor_idle
power:processor_frequency
power:machine_suspend


C-state/idle accounting events:
  power:power_start
  power:power_end
are replaced with:
  power:processor_idle

and
  power:power_frequency
is replaced with:
  power:processor_frequency

power:machine_suspend
is newly introduced, a first implementation
comes from the ARM side, but it's easy to add these events
in X86 as well if needed.

the type= field got removed from both, it was never
used and the type is differed by the event type itself.

perf timechart
userspace tool gets adjusted in a separate patch.

Signed-off-by: Thomas Renninger tr...@suse.de
CC: Linus Torvalds torva...@linux-foundation.org
CC: Andrew Morton a...@linux-foundation.org
CC: Thomas Gleixner t...@linutronix.de
CC: Masami Hiramatsu masami.hiramatsu...@hitachi.com
CC: Frank Eigler f...@redhat.com
CC: Steven Rostedt rost...@goodmis.org
CC: Kevin Hilman khil...@deeprootsystems.com
CC: Peter Zijlstra pet...@infradead.org
CC: linux-omap@vger.kernel.org
CC: r...@sisk.pl
CC: linux...@lists.linux-foundation.org
CC: linux-trace-us...@vger.kernel.org
CC: Jean Pihet jean.pi...@newoldbits.com
CC: Pierre Tardy tar...@gmail.com
CC: Frederic Weisbecker fweis...@gmail.com
CC: Tejun Heo t...@kernel.org
CC: Mathieu Desnoyers mathieu.desnoy...@efficios.com
CC: Arjan van de Ven ar...@linux.intel.com
CC: Ingo Molnar mi...@elte.hu
---
 arch/x86/kernel/process.c|7 +++-
 arch/x86/kernel/process_64.c |2 +
 drivers/cpufreq/cpufreq.c|1 +
 drivers/cpuidle/cpuidle.c|1 +
 drivers/idle/intel_idle.c|1 +
 include/trace/events/power.h |   81 +-
 kernel/trace/Kconfig |   14 +++
 kernel/trace/power-traces.c  |3 ++
 8 files changed, 108 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 57d1868..6a98da3 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -374,6 +374,7 @@ void default_idle(void)
 {
if (hlt_use_halt()) {
trace_power_start(POWER_CSTATE, 1, smp_processor_id());
+   trace_processor_idle(1, smp_processor_id());
current_thread_info()-status = ~TS_POLLING;
/*
 * TS_POLLING-cleared state must be visible before we
@@ -444,6 +445,7 @@ EXPORT_SYMBOL_GPL(cpu_idle_wait);
 void mwait_idle_with_hints(unsigned long ax, unsigned long cx)
 {
trace_power_start(POWER_CSTATE, (ax4)+1, smp_processor_id());
+   trace_processor_idle((ax4)+1, smp_processor_id());
if (!need_resched()) {
if (cpu_has(current_cpu_data, X86_FEATURE_CLFLUSH_MONITOR))
clflush((void *)current_thread_info()-flags);
@@ -460,6 +462,7 @@ static void mwait_idle(void)
 {
if (!need_resched()) {
trace_power_start(POWER_CSTATE, 1, smp_processor_id());
+   trace_processor_idle(1, smp_processor_id());
if (cpu_has(current_cpu_data, X86_FEATURE_CLFLUSH_MONITOR))
clflush((void *)current_thread_info()-flags);
 
@@ -481,10 +484,12 @@ static void mwait_idle(void)
 static void poll_idle(void)
 {
trace_power_start(POWER_CSTATE, 0, smp_processor_id());
+   trace_processor_idle(1, smp_processor_id());
local_irq_enable();
while (!need_resched())
cpu_relax();
-   trace_power_end(0);
+   trace_power_end(smp_processor_id());
+   trace_processor_idle(PWR_EVENT_EXIT, smp_processor_id());
 }
 
 /*
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 3d9ea53..5f2bb98 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -142,6 +142,8 @@ void cpu_idle(void)
start_critical_timings();
 
trace_power_end(smp_processor_id());
+   trace_processor_idle(PWR_EVENT_EXIT,
+smp_processor_id());
 
/* In many cases the interrupt that ended idle
   has already called exit_idle. But some idle
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 199dcb9..33bdc41 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -355,6 +355,7 @@ void cpufreq_notify_transition(struct cpufreq_freqs *freqs, 
unsigned int state)
dprintk(FREQ: %lu - CPU: %lu, (unsigned long)freqs-new,
(unsigned long)freqs-cpu);
trace_power_frequency(POWER_PSTATE, freqs-new, freqs-cpu);
+   trace_processor_frequency(freqs-new, freqs-cpu);
srcu_notifier_call_chain(cpufreq_transition_notifier_list,
CPUFREQ_POSTCHANGE, freqs);
if 

[PATCH] PERF(userspace): Adjust perf timechart to the new power events V2

[Thomas Renninger]

Changes in V2:
  - Hanlde PWR_EVENT_EXIT instead of 0 to recon non-power state

The transition was rather smooth, only part I had to fiddle
some time was the check whether a tracepoint/event is
supported by the running kernel.

builtin-timechart must only pass -e power:xy events which
are supported by the running kernel.
For this I added the tiny helper function:
int is_valid_tracepoint(const char *event_string)
to parse-events.[hc]
which could be more generic as an interface and support
hardware/software/... events, not only tracepoints, but someone
else could extend that if needed...

Signed-off-by: Thomas Renninger tr...@suse.de
CC: Linus Torvalds torva...@linux-foundation.org
CC: Andrew Morton a...@linux-foundation.org
CC: Thomas Gleixner t...@linutronix.de
CC: Masami Hiramatsu masami.hiramatsu...@hitachi.com
CC: Frank Eigler f...@redhat.com
CC: Steven Rostedt rost...@goodmis.org
CC: Kevin Hilman khil...@deeprootsystems.com
CC: Peter Zijlstra pet...@infradead.org
CC: linux-omap@vger.kernel.org
CC: r...@sisk.pl
CC: linux...@lists.linux-foundation.org
CC: linux-trace-us...@vger.kernel.org
CC: Jean Pihet jean.pi...@newoldbits.com
CC: Pierre Tardy tar...@gmail.com
CC: Frederic Weisbecker fweis...@gmail.com
CC: Tejun Heo t...@kernel.org
CC: Mathieu Desnoyers mathieu.desnoy...@efficios.com
CC: Arjan van de Ven ar...@linux.intel.com
CC: Ingo Molnar mi...@elte.hu
---
 tools/perf/builtin-timechart.c |   89 ---
 tools/perf/util/parse-events.c |   43 +++-
 tools/perf/util/parse-events.h |1 +
 3 files changed, 116 insertions(+), 17 deletions(-)

diff --git a/tools/perf/builtin-timechart.c b/tools/perf/builtin-timechart.c
index 9bcc38f..7eaa5b5 100644
--- a/tools/perf/builtin-timechart.c
+++ b/tools/perf/builtin-timechart.c
@@ -32,6 +32,10 @@
 #include util/session.h
 #include util/svghelper.h
 
+#define SUPPORT_OLD_POWER_EVENTS 1
+#define PWR_EVENT_EXIT 0x
+
+
 static charconst *input_name = perf.data;
 static charconst *output_name = output.svg;
 
@@ -298,12 +302,25 @@ struct trace_entry {
int lock_depth;
 };
 
-struct power_entry {
+#if defined(SUPPORT_OLD_POWER_EVENTS)
+struct power_entry_old {
struct trace_entry te;
u64 type;
u64 value;
u64 cpu_id;
 };
+#endif
+
+struct power_processor_entry {
+   struct trace_entry te;
+   u64 state;
+   u64 cpu_id;
+};
+
+struct power_suspend_entry {
+   struct trace_entry te;
+   u64 state;
+};
 
 #define TASK_COMM_LEN 16
 struct wakeup_entry {
@@ -489,29 +506,46 @@ static int process_sample_event(event_t *event, struct 
perf_session *session)
te = (void *)data.raw_data;
if (session-sample_type  PERF_SAMPLE_RAW  data.raw_size  0) {
char *event_str;
-   struct power_entry *pe;
-
-   pe = (void *)te;
+#if defined(SUPPORT_OLD_POWER_EVENTS)
+   struct power_entry_old *peo;
+   peo = (void *)te;
+#endif
 
event_str = perf_header__find_event(te-type);
 
if (!event_str)
return 0;
 
-   if (strcmp(event_str, power:power_start) == 0)
-   c_state_start(pe-cpu_id, data.time, pe-value);
-
-   if (strcmp(event_str, power:power_end) == 0)
-   c_state_end(pe-cpu_id, data.time);
+   if (strcmp(event_str, power:processor_idle) == 0) {
+   struct power_processor_entry *ppe = (void *)te;
+   if (ppe-state == PWR_EVENT_EXIT)
+   c_state_end(ppe-cpu_id, data.time);
+   else
+   c_state_start(ppe-cpu_id, data.time,
+ ppe-state);
+   }
 
-   if (strcmp(event_str, power:power_frequency) == 0)
-   p_state_change(pe-cpu_id, data.time, pe-value);
+   else if (strcmp(event_str, power:processor_frequency) == 0) {
+   struct power_processor_entry *ppe = (void *)te;
+   p_state_change(ppe-cpu_id, data.time, ppe-state);
+   }
 
-   if (strcmp(event_str, sched:sched_wakeup) == 0)
+   else if (strcmp(event_str, sched:sched_wakeup) == 0)
sched_wakeup(data.cpu, data.time, data.pid, te);
 
-   if (strcmp(event_str, sched:sched_switch) == 0)
+   else if (strcmp(event_str, sched:sched_switch) == 0)
sched_switch(data.cpu, data.time, te);
+
+#if defined(SUPPORT_OLD_POWER_EVENTS)
+   else if (strcmp(event_str, power:power_start) == 0)
+   c_state_start(peo-cpu_id, data.time, peo-value);
+
+   else if (strcmp(event_str, power:power_end) == 0)
+   c_state_end(peo-cpu_id, data.time);
+
+   

[PATCH 7/8] staging: tidspbridge - fix some issues after iommu patches

[Fernando Guzman Lugo]

This patch fixes:

* In delete_node() we need to check for udsp_heap_addr in order
  to unmap the head instead of udsp_heap_res_addr which used
  to be the reserved memory a not valid anymore.

* Fix in get_io_pages() as pointed by Felipe Contreras in this
  mail:

http://marc.info/?l=linux-kernelm=128735502205183w=2

Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
 drivers/staging/tidspbridge/core/dsp-mmu.c |2 +-
 drivers/staging/tidspbridge/rmgr/node.c|2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/tidspbridge/core/dsp-mmu.c 
b/drivers/staging/tidspbridge/core/dsp-mmu.c
index 3a00087..54f3ba4 100644
--- a/drivers/staging/tidspbridge/core/dsp-mmu.c
+++ b/drivers/staging/tidspbridge/core/dsp-mmu.c
@@ -196,7 +196,7 @@ static int get_io_pages(struct mm_struct *mm, u32 uva, 
unsigned pages,
int i;
struct page *pg;
 
-   for (i = 0; i  pages; i++) {
+   for (i = 0; i  pages; i++, uva += PAGE_SIZE) {
pa = user_va2_pa(mm, uva);
 
if (!pfn_valid(__phys_to_pfn(pa)))
diff --git a/drivers/staging/tidspbridge/rmgr/node.c 
b/drivers/staging/tidspbridge/rmgr/node.c
index 3f5abcf..f7fe6c0 100644
--- a/drivers/staging/tidspbridge/rmgr/node.c
+++ b/drivers/staging/tidspbridge/rmgr/node.c
@@ -2541,7 +2541,7 @@ static void delete_node(struct node_object *hnode,
kfree(task_arg_obj.strm_out_def);
task_arg_obj.strm_out_def = NULL;
}
-   if (task_arg_obj.udsp_heap_res_addr) {
+   if (task_arg_obj.udsp_heap_addr) {
status = proc_un_map(hnode-hprocessor, (void *)
 task_arg_obj.udsp_heap_addr,
 pr_ctxt);
-- 
1.6.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/8] staging: tidspbridge - misc fixes

[Fernando Guzman Lugo]

This set of patches fix some issues found in lastest tree.

Fernando Guzman Lugo (8):
  staging: tidspbridge - remove req_addr from proc_map
  staging: tidspbridge - add kconfig parameter for DMM size
  staging: tidspbridge - change mmufault tasklet to a workqueue
  staging: tidspbridge - fix timeout in dsp_gpt_wait_overflow
  staging: tidspbridge - use GTP7 for DSP stack dump
  staging: tidspbridge - remove disabling twl when printing DSP stack
  staging: tidspbridge - fix some issues after iommu patches
  staging: tidspbridge - make sync_wait_on_event interruptible

 drivers/staging/tidspbridge/Kconfig|8 +++
 drivers/staging/tidspbridge/core/dsp-clock.c   |   13 +++--
 drivers/staging/tidspbridge/core/dsp-mmu.c |   55 +++-
 drivers/staging/tidspbridge/core/tiomap3430.c  |   20 ++-
 .../staging/tidspbridge/include/dspbridge/clk.h|4 +-
 .../tidspbridge/include/dspbridge/dsp-mmu.h|3 +
 .../tidspbridge/include/dspbridge/dspapi-ioctl.h   |1 -
 .../staging/tidspbridge/include/dspbridge/proc.h   |3 -
 .../staging/tidspbridge/include/dspbridge/sync.h   |   13 -
 drivers/staging/tidspbridge/pmgr/dspapi.c  |2 +-
 drivers/staging/tidspbridge/rmgr/node.c|4 +-
 drivers/staging/tidspbridge/rmgr/proc.c|   25 -
 12 files changed, 95 insertions(+), 56 deletions(-)

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/8] staging: tidspbridge - fix timeout in dsp_gpt_wait_overflow

[Fernando Guzman Lugo]

Timeout was not being initialized correctly and should
use time_is-before_jiffies, also make it a parameter

Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
 drivers/staging/tidspbridge/core/dsp-clock.c   |   13 +++--
 drivers/staging/tidspbridge/core/dsp-mmu.c |5 -
 .../staging/tidspbridge/include/dspbridge/clk.h|4 +++-
 3 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/tidspbridge/core/dsp-clock.c 
b/drivers/staging/tidspbridge/core/dsp-clock.c
index 46d17c7..8106d1e 100644
--- a/drivers/staging/tidspbridge/core/dsp-clock.c
+++ b/drivers/staging/tidspbridge/core/dsp-clock.c
@@ -202,13 +202,13 @@ static void mcbsp_clk_prepare(bool flag, u8 id)
  * Sets an overflow interrupt for the desired GPT waiting for a timeout
  * of 5 msecs for the interrupt to occur.
  */
-void dsp_gpt_wait_overflow(short int clk_id, unsigned int load)
+int dsp_gpt_wait_overflow(short int clk_id, unsigned int load,
+   unsigned long timeout)
 {
struct omap_dm_timer *gpt = timer[clk_id - 1];
-   unsigned long timeout;
 
if (!gpt)
-   return;
+   return -EINVAL;
 
/* Enable overflow interrupt */
omap_dm_timer_set_int_enable(gpt, OMAP_TIMER_INT_OVERFLOW);
@@ -222,14 +222,15 @@ void dsp_gpt_wait_overflow(short int clk_id, unsigned int 
load)
/* Wait 80us for timer to overflow */
udelay(80);
 
-   timeout = msecs_to_jiffies(5);
+   timeout = jiffies + msecs_to_jiffies(timeout);
/* Check interrupt status and wait for interrupt */
while (!(omap_dm_timer_read_status(gpt)  OMAP_TIMER_INT_OVERFLOW)) {
-   if (time_is_after_jiffies(timeout)) {
+   if (time_is_before_jiffies(timeout)) {
pr_err(%s: GPTimer interrupt failed\n, __func__);
-   break;
+   return -ETIME;
}
}
+   return 0;
 }
 
 /*
diff --git a/drivers/staging/tidspbridge/core/dsp-mmu.c 
b/drivers/staging/tidspbridge/core/dsp-mmu.c
index 6d7501a..2d4e897 100644
--- a/drivers/staging/tidspbridge/core/dsp-mmu.c
+++ b/drivers/staging/tidspbridge/core/dsp-mmu.c
@@ -65,7 +65,10 @@ static void mmu_fault_print_stack(struct bridge_dev_context 
*dev_context)
 
dsp_clk_enable(DSP_CLK_GPT8);
 
-   dsp_gpt_wait_overflow(DSP_CLK_GPT8, 0xfffe);
+   if (dsp_gpt_wait_overflow(DSP_CLK_GPT8, 0xfffe, 10)) {
+   pr_err(%s: error sending interrupt to DSP\n, __func__);
+   return;
+   }
 
/* Clear MMU interrupt */
tmp = iommu_read_reg(mmu, MMU_IRQSTATUS);
diff --git a/drivers/staging/tidspbridge/include/dspbridge/clk.h 
b/drivers/staging/tidspbridge/include/dspbridge/clk.h
index b239503..6fe1ff2 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/clk.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/clk.h
@@ -62,7 +62,9 @@ extern void dsp_clk_exit(void);
  */
 extern void dsp_clk_init(void);
 
-void dsp_gpt_wait_overflow(short int clk_id, unsigned int load);
+int dsp_gpt_wait_overflow(short int clk_id, unsigned int load,
+   unsigned long timeout);
+
 
 /*
  *   dsp_clk_enable 
-- 
1.6.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 6/8] staging: tidspbridge - remove disabling twl when printing DSP stack

[Fernando Guzman Lugo]

Now the SHM segments are not in lock tlbs, instead
they are in translation tables. So we cannot disable
twl in order to get the DSP stack dump.

Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
 drivers/staging/tidspbridge/core/dsp-mmu.c |8 
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/tidspbridge/core/dsp-mmu.c 
b/drivers/staging/tidspbridge/core/dsp-mmu.c
index 157b743..3a00087 100644
--- a/drivers/staging/tidspbridge/core/dsp-mmu.c
+++ b/drivers/staging/tidspbridge/core/dsp-mmu.c
@@ -43,14 +43,6 @@ static void mmu_fault_print_stack(struct bridge_dev_context 
*dev_context)
if (!dummy_addr)
return;
 
-   /*
-* Before acking the MMU fault, let's make sure MMU can only
-* access entry #0. Then add a new entry so that the DSP OS
-* can continue in order to dump the stack.
-*/
-   tmp = iommu_read_reg(mmu, MMU_CNTL);
-   tmp = ~MMU_CNTL_TWL_EN;
-   iommu_write_reg(mmu, tmp, MMU_CNTL);
fa = iommu_read_reg(mmu, MMU_FAULT_AD);
e.da = fa  PAGE_MASK;
e.pa = virt_to_phys(dummy_addr);
-- 
1.6.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/8] staging: tidspbridge - change mmufault tasklet to a workqueue

[Fernando Guzman Lugo]

We don't need to manage the mmufault inside a tasklet
it is safer using a workqueue.

Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
 drivers/staging/tidspbridge/core/dsp-mmu.c |   34 ++--
 1 files changed, 22 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/tidspbridge/core/dsp-mmu.c 
b/drivers/staging/tidspbridge/core/dsp-mmu.c
index 983c95a..6d7501a 100644
--- a/drivers/staging/tidspbridge/core/dsp-mmu.c
+++ b/drivers/staging/tidspbridge/core/dsp-mmu.c
@@ -28,7 +28,8 @@
 
 #define MMU_CNTL_TWL_EN(1  2)
 
-static struct tasklet_struct mmu_tasklet;
+static struct workqueue_struct *mmu_wq;
+static struct work_struct fault_work;
 
 #ifdef CONFIG_TIDSPBRIDGE_BACKTRACE
 static void mmu_fault_print_stack(struct bridge_dev_context *dev_context)
@@ -37,7 +38,10 @@ static void mmu_fault_print_stack(struct bridge_dev_context 
*dev_context)
u32 fa, tmp;
struct iotlb_entry e;
struct iommu *mmu = dev_context-dsp_mmu;
-   dummy_addr = (void *)__get_free_page(GFP_ATOMIC);
+
+   dummy_addr = (void *)__get_free_page(GFP_KERNEL);
+   if (!dummy_addr)
+   return;
 
/*
 * Before acking the MMU fault, let's make sure MMU can only
@@ -76,19 +80,19 @@ static void mmu_fault_print_stack(struct bridge_dev_context 
*dev_context)
 #endif
 
 
-static void fault_tasklet(unsigned long data)
+static void mmu_fault_work(struct work_struct *work)
 {
-   struct iommu *mmu = (struct iommu *)data;
struct bridge_dev_context *dev_ctx;
struct deh_mgr *dm;
u32 fa;
+
dev_get_deh_mgr(dev_get_first(), dm);
dev_get_bridge_context(dev_get_first(), dev_ctx);
 
if (!dm || !dev_ctx)
return;
 
-   fa = iommu_read_reg(mmu, MMU_FAULT_AD);
+   fa = iommu_read_reg(dev_ctx-dsp_mmu, MMU_FAULT_AD);
 
 #ifdef CONFIG_TIDSPBRIDGE_BACKTRACE
print_dsp_trace_buffer(dev_ctx);
@@ -109,7 +113,8 @@ static int mmu_fault_callback(struct iommu *mmu)
return -EPERM;
 
iommu_write_reg(mmu, 0, MMU_IRQENABLE);
-   tasklet_schedule(mmu_tasklet);
+   queue_work(mmu_wq, fault_work);
+
return 0;
 }
 
@@ -126,10 +131,16 @@ struct iommu *dsp_mmu_init()
 
mmu = iommu_get(iva2);
 
-   if (!IS_ERR(mmu)) {
-   tasklet_init(mmu_tasklet, fault_tasklet, (unsigned long)mmu);
-   mmu-isr = mmu_fault_callback;
+   if (IS_ERR(mmu))
+   return mmu;
+
+   mmu-isr = mmu_fault_callback;
+   mmu_wq = create_workqueue(dsp-mmu_wq);
+   if (!mmu_wq) {
+   iommu_put(mmu);
+   return ERR_PTR(-ENOMEM);
}
+   INIT_WORK(fault_work, mmu_fault_work);
 
return mmu;
 }
@@ -143,9 +154,8 @@ struct iommu *dsp_mmu_init()
  */
 void dsp_mmu_exit(struct iommu *mmu)
 {
-   if (mmu)
-   iommu_put(mmu);
-   tasklet_kill(mmu_tasklet);
+   iommu_put(mmu);
+   destroy_workqueue(mmu_wq);
 }
 
 /**
-- 
1.6.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/8] staging: tidspbridge - use GTP7 for DSP stack dump

[Fernando Guzman Lugo]

DSP stack dump is changed to GTP7 due to GPT8 is used
by DSP side apps

Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
 drivers/staging/tidspbridge/core/dsp-mmu.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/tidspbridge/core/dsp-mmu.c 
b/drivers/staging/tidspbridge/core/dsp-mmu.c
index 2d4e897..157b743 100644
--- a/drivers/staging/tidspbridge/core/dsp-mmu.c
+++ b/drivers/staging/tidspbridge/core/dsp-mmu.c
@@ -63,9 +63,9 @@ static void mmu_fault_print_stack(struct bridge_dev_context 
*dev_context)
 
load_iotlb_entry(mmu, e);
 
-   dsp_clk_enable(DSP_CLK_GPT8);
+   dsp_clk_enable(DSP_CLK_GPT7);
 
-   if (dsp_gpt_wait_overflow(DSP_CLK_GPT8, 0xfffe, 10)) {
+   if (dsp_gpt_wait_overflow(DSP_CLK_GPT7, 0xfffe, 10)) {
pr_err(%s: error sending interrupt to DSP\n, __func__);
return;
}
@@ -75,7 +75,7 @@ static void mmu_fault_print_stack(struct bridge_dev_context 
*dev_context)
iommu_write_reg(mmu, tmp, MMU_IRQSTATUS);
 
dump_dsp_stack(dev_context);
-   dsp_clk_disable(DSP_CLK_GPT8);
+   dsp_clk_disable(DSP_CLK_GPT7);
 
iopgtable_clear_entry(mmu, fa);
free_page((unsigned long)dummy_addr);
-- 
1.6.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/8] staging: tidspbridge - remove req_addr from proc_map

[Fernando Guzman Lugo]

The device address is assigned by tidspbridge no need for that parameter 
anymore.

Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
 .../tidspbridge/include/dspbridge/dspapi-ioctl.h   |1 -
 .../staging/tidspbridge/include/dspbridge/proc.h   |3 --
 drivers/staging/tidspbridge/pmgr/dspapi.c  |2 +-
 drivers/staging/tidspbridge/rmgr/node.c|2 +-
 drivers/staging/tidspbridge/rmgr/proc.c|   25 +--
 5 files changed, 14 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/tidspbridge/include/dspbridge/dspapi-ioctl.h 
b/drivers/staging/tidspbridge/include/dspbridge/dspapi-ioctl.h
index 8da5bd8..db06468 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/dspapi-ioctl.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/dspapi-ioctl.h
@@ -138,7 +138,6 @@ union trapped_args {
void *hprocessor;
void *pmpu_addr;
u32 ul_size;
-   void *req_addr;
void *__user *pp_map_addr;
u32 ul_map_attr;
} args_proc_mapmem;
diff --git a/drivers/staging/tidspbridge/include/dspbridge/proc.h 
b/drivers/staging/tidspbridge/include/dspbridge/proc.h
index 2d12aab..74344bd 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/proc.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/proc.h
@@ -524,8 +524,6 @@ extern int proc_invalidate_memory(void *hprocessor,
  *  hprocessor  :   The processor handle.
  *  pmpu_addr  :   Starting address of the memory region to map.
  *  ul_size  :   Size of the memory region to map.
- *  req_addr   :   Requested DSP start address. Offset-adjusted actual
- *   mapped address is in the last argument.
  *  pp_map_addr   :   Ptr to DSP side mapped u8 address.
  *  ul_map_attr   :   Optional endianness attributes, virt to phys 
flag.
  *  Returns:
@@ -546,7 +544,6 @@ extern int proc_invalidate_memory(void *hprocessor,
 extern int proc_map(void *hprocessor,
   void *pmpu_addr,
   u32 ul_size,
-  void *req_addr,
   void **pp_map_addr, u32 ul_map_attr,
   struct process_context *pr_ctxt);
 
diff --git a/drivers/staging/tidspbridge/pmgr/dspapi.c 
b/drivers/staging/tidspbridge/pmgr/dspapi.c
index 0187c47..d1e1185 100644
--- a/drivers/staging/tidspbridge/pmgr/dspapi.c
+++ b/drivers/staging/tidspbridge/pmgr/dspapi.c
@@ -952,7 +952,7 @@ u32 procwrap_map(union trapped_args *args, void *pr_ctxt)
status = proc_map(args-args_proc_mapmem.hprocessor,
  args-args_proc_mapmem.pmpu_addr,
  args-args_proc_mapmem.ul_size,
- args-args_proc_mapmem.req_addr, map_addr,
+ map_addr,
  args-args_proc_mapmem.ul_map_attr, pr_ctxt);
if (!status) {
if (put_user(map_addr, args-args_proc_mapmem.pp_map_addr)) {
diff --git a/drivers/staging/tidspbridge/rmgr/node.c 
b/drivers/staging/tidspbridge/rmgr/node.c
index a660247..3f5abcf 100644
--- a/drivers/staging/tidspbridge/rmgr/node.c
+++ b/drivers/staging/tidspbridge/rmgr/node.c
@@ -430,7 +430,7 @@ int node_allocate(struct proc_object *hprocessor,
map_attrs |= DSP_MAPVIRTUALADDR;
status = proc_map(hprocessor, (void *)attr_in-pgpp_virt_addr,
  pnode-create_args.asa.task_arg_obj.heap_size,
- NULL, (void **)mapped_addr, map_attrs,
+ (void **)mapped_addr, map_attrs,
  pr_ctxt);
if (status)
pr_err(%s: Failed to map memory for Heap: 0x%x\n,
diff --git a/drivers/staging/tidspbridge/rmgr/proc.c 
b/drivers/staging/tidspbridge/rmgr/proc.c
index 7a15a02..5e5eb75 100644
--- a/drivers/staging/tidspbridge/rmgr/proc.c
+++ b/drivers/staging/tidspbridge/rmgr/proc.c
@@ -1314,10 +1314,10 @@ func_end:
  *  Maps a MPU buffer to DSP address space.
  */
 int proc_map(void *hprocessor, void *pmpu_addr, u32 ul_size,
-   void *req_addr, void **pp_map_addr, u32 ul_map_attr,
+   void **pp_map_addr, u32 ul_map_attr,
struct process_context *pr_ctxt)
 {
-   u32 va_align;
+   u32 da;
u32 pa_align;
u32 size_align;
int status = 0;
@@ -1336,7 +1336,6 @@ int proc_map(void *hprocessor, void *pmpu_addr, u32 
ul_size,
 #endif
 
/* Calculate the page-aligned PA, VA and size */
-   va_align = PG_ALIGN_LOW((u32) req_addr, PG_SIZE4K);
pa_align = PG_ALIGN_LOW((u32) pmpu_addr, PG_SIZE4K);
size_align = PG_ALIGN_HIGH(ul_size + (u32) pmpu_addr - pa_align,
   PG_SIZE4K);
@@ -1351,26 +1350,26 @@ int proc_map(void *hprocessor, void *pmpu_addr, u32 
ul_size,
/* Add mapping to the page tables. */
if (!status) {
/* 

[PATCH 2/8] staging: tidspbridge - add kconfig parameter for DMM size

[Fernando Guzman Lugo]

A new kconfig parameter for DMM size is added. Also DMM is
allocated after the end of SHM area. So that the checks on
DSP are still valid and we avoid using areas between SHM
which are not mapped reducing the probability of shared
memory corruption.

NOTE: This patch has a dependency on this patch:

omap: iommu - create new api to set valid da range

Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
 drivers/staging/tidspbridge/Kconfig|8 
 drivers/staging/tidspbridge/core/tiomap3430.c  |   20 ++--
 .../tidspbridge/include/dspbridge/dsp-mmu.h|3 +++
 3 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/tidspbridge/Kconfig 
b/drivers/staging/tidspbridge/Kconfig
index 672008f..37e47f5 100644
--- a/drivers/staging/tidspbridge/Kconfig
+++ b/drivers/staging/tidspbridge/Kconfig
@@ -42,6 +42,14 @@ config TIDSPBRIDGE_MEMPOOL_SIZE
  Allocate specified size of memory at booting time to avoid allocation
  failure under heavy memory fragmentation after some use time.
 
+config TIDSPBRIDGE_DMM_SIZE
+   hex DMM capable memory size (Byte)
+   depends on TIDSPBRIDGE
+   default 0x1000
+   help
+ Memory size of DSP virtual address for Dynamic Memory Mapping.
+ Please make sure the size is 4K aligned.
+
 config TIDSPBRIDGE_DEBUG
bool Debug Support
depends on TIDSPBRIDGE
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c 
b/drivers/staging/tidspbridge/core/tiomap3430.c
index c28dcf1..88c8c71 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -345,7 +345,6 @@ static int bridge_brd_start(struct bridge_dev_context 
*dev_ctxt,
OMAP343X_CONTROL_IVA2_BOOTMOD));
}
}
-
if (!status) {
(*pdata-dsp_prm_rmw_bits)(OMAP3430_RST2_IVA2_MASK, 0,
OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL);
@@ -362,6 +361,11 @@ static int bridge_brd_start(struct bridge_dev_context 
*dev_ctxt,
if (!status) {
dev_context-dsp_mmu = mmu;
sm_sg = dev_context-sh_s;
+   /* Set valid range to map shared memory */
+   status = iommu_set_da_range(mmu, sm_sg-seg0_da,
+   sm_sg-seg1_da + sm_sg-seg1_size);
+   }
+   if (!status) {
sg0_da = iommu_kmap(mmu, sm_sg-seg0_da, sm_sg-seg0_pa,
sm_sg-seg0_size, IOVMF_ENDIAN_LITTLE | IOVMF_ELSZ_32);
if (IS_ERR_VALUE(sg0_da)) {
@@ -411,7 +415,19 @@ static int bridge_brd_start(struct bridge_dev_context 
*dev_ctxt,
l4_i++;
}
}
-
+   if (!status) {
+   /* Set valid range for DMM mappings */
+   if (MAX_DSP_MMU_DA - CONFIG_TIDSPBRIDGE_DMM_SIZE 
+   sm_sg-seg1_da + sm_sg-seg1_size) {
+   dev_err(bridge, DMM size too big!\n);
+   status = -ENOMEM;
+   } else {
+   status = iommu_set_da_range(mmu,
+   sm_sg-seg1_da + sm_sg-seg1_size,
+   sm_sg-seg1_da + sm_sg-seg1_size +
+   CONFIG_TIDSPBRIDGE_DMM_SIZE);
+   }
+   }
/* Lock the above TLB entries and get the BIOS and load monitor timer
 * information */
if (!status) {
diff --git a/drivers/staging/tidspbridge/include/dspbridge/dsp-mmu.h 
b/drivers/staging/tidspbridge/include/dspbridge/dsp-mmu.h
index cb38d4c..bbbe9e6 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/dsp-mmu.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/dsp-mmu.h
@@ -22,6 +22,9 @@
 #include plat/iommu.h
 #include plat/iovmm.h
 
+/* Last patch is not mapped to detect buffer overflow in DSP side */
+#define MAX_DSP_MMU_DA 0xF000
+
 /**
  * dsp_mmu_init() - initialize dsp_mmu module and returns a handle
  *
-- 
1.6.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 8/8] staging: tidspbridge - make sync_wait_on_event interruptible

[Fernando Guzman Lugo]

So that avoid non-killable process.

Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
 .../staging/tidspbridge/include/dspbridge/sync.h   |   13 +++--
 1 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/tidspbridge/include/dspbridge/sync.h 
b/drivers/staging/tidspbridge/include/dspbridge/sync.h
index e2651e7..df05b8f 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/sync.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/sync.h
@@ -80,13 +80,22 @@ void sync_set_event(struct sync_object *event);
  * This functios will wait until @event is set or until timeout. In case of
  * success the function will return 0 and
  * in case of timeout the function will return -ETIME
+ * in case of signal the function will return -ERESTARTSYS
  */
 
 static inline int sync_wait_on_event(struct sync_object *event,
unsigned timeout)
 {
-   return wait_for_completion_timeout(event-comp,
-   msecs_to_jiffies(timeout)) ? 0 : -ETIME;
+   int res;
+
+   res = wait_for_completion_interruptible_timeout(event-comp,
+   msecs_to_jiffies(timeout));
+   if (!res)
+   res = -ETIME;
+   else if (res  0)
+   res = 0;
+
+   return res;
 }
 
 /**
-- 
1.6.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 8/8] staging: tidspbridge - make sync_wait_on_event interruptible

[Felipe Contreras]

On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo x0095...@ti.com wrote:
 So that avoid non-killable process.

It would be useful to interrupt these tasks from user-space. A
separate ioctl to do that would be needed.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Arjan van de Ven]

On 10/25/2010 4:33 PM, Thomas Renninger wrote:

Changes in V2:
   - Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
   - Use u32 instead of u64 for cpuid, state which is by far enough

New power trace events:
power:processor_idle
power:processor_frequency
power:machine_suspend


C-state/idle accounting events:
   power:power_start
   power:power_end
are replaced with:
   power:processor_idle

and
   power:power_frequency
is replaced with:
   power:processor_frequency

power:machine_suspend
is newly introduced, a first implementation
comes from the ARM side, but it's easy to add these events
in X86 as well if needed.

the type= field got removed from both, it was never
used and the type is differed by the event type itself.

perf timechart
userspace tool gets adjusted in a separate patch.



Acked-by: Arjan van de Ven ar...@linux.intel.com

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] OMAP: DSS2: Add NEC NL8048HL11-01B display panel

[Samreen]

From: Erik Gilling konk...@android.com

NEC WVGA LCD NL8048HL11-01B panel support has been added.
This panel is being used in zoom2/zoom3/3630 sdp boards.

Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Rajkumar N rajkumar.nagara...@ti.com
Signed-off-by: Samreen samr...@ti.com
CC: Subbu Venkatesh subramani.venkat...@windriver.com
CC: Erik Gilling konk...@android.com
---
 Version3:
- Optimized the init sequence by using struct array in the function
init_nec_8048_wvga_lcd()
- Changed the spi_send() to nec_8048_spi_send() to maintain consistency
- Added better decription in MODULE_DESCRIPTION()
 Version2:
- the brightness updation is removed from the nec_8048_panel_enable()
to assure the user set brightness value is not over written
- error checking added where ever missing
- cosmetic changes are also included

 This panel driver has orginated from panel-zoom2 from the L25.x 
 releases.Refer Commit:
 
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=75fc121865125d9e3ca3b36f1f19f86b394e1f6b

 drivers/video/omap2/displays/Kconfig   |7 +
 drivers/video/omap2/displays/Makefile  |1 +
 .../omap2/displays/panel-nec-nl8048hl11-01b.c  |  325 
 3 files changed, 333 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c

diff --git a/drivers/video/omap2/displays/Kconfig 
b/drivers/video/omap2/displays/Kconfig
index 12327bb..f8152cf 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -20,6 +20,13 @@ config PANEL_SHARP_LQ043T1DG01
 help
   LCD Panel used in TI's OMAP3517 EVM boards
 
+config PANEL_NEC_NL8048HL11_01B
+   tristate NEC NL8048HL11-01B Panel
+   depends on OMAP2_DSS
+   help
+   This NEC NL8048HL11-01B panel is TFT LCD
+   used in the Zoom2/3/3630 sdp boards.
+
 config PANEL_TAAL
 tristate Taal DSI Panel
 depends on OMAP2_DSS_DSI
diff --git a/drivers/video/omap2/displays/Makefile 
b/drivers/video/omap2/displays/Makefile
index aa38609..8ece91c 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -1,6 +1,7 @@
 obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
 obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
 obj-$(CONFIG_PANEL_SHARP_LQ043T1DG01) += panel-sharp-lq043t1dg01.o
+obj-$(CONFIG_PANEL_NEC_NL8048HL11_01B) += panel-nec-nl8048hl11-01b.o
 
 obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
 obj-$(CONFIG_PANEL_TOPPOLY_TDO35S) += panel-toppoly-tdo35s.o
diff --git a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c 
b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
new file mode 100644
index 000..925e0fa
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
@@ -0,0 +1,325 @@
+/*
+ * Support for NEC-nl8048hl11-01b panel driver
+ *
+ * Copyright (C) 2010 Texas Instruments Inc.
+ * Author: Erik Gilling konk...@android.com
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/delay.h
+#include linux/spi/spi.h
+#include linux/backlight.h
+#include linux/fb.h
+
+#include plat/display.h
+
+#define LCD_XRES   800
+#define LCD_YRES   480
+/*
+ * NEC PIX Clock Ratings
+ * MIN:21.8MHz TYP:23.8MHz MAX:25.7MHz
+ */
+#define LCD_PIXEL_CLOCK23800
+
+struct nec_8048_data {
+   struct backlight_device *bl;
+};
+
+static const struct {
+   unsigned char addr;
+   unsigned char dat;
+} nec_8048_init_seq[] = {
+   { 3, 0x01 }, { 0, 0x00 }, { 1, 0x01 }, { 4, 0x00 }, { 5, 0x14 },
+   { 6, 0x24 }, { 16, 0xD7 }, { 17, 0x00 }, { 18, 0x00 }, { 19, 0x55 },
+   { 20, 0x01 }, { 21, 0x70 }, { 22, 0x1E }, { 23, 0x25 }, { 24, 0x25 },
+   { 25, 0x02 }, { 26, 0x02 }, { 27, 0xA0 }, { 32, 0x2F }, { 33, 0x0F },
+   { 34, 0x0F }, { 35, 0x0F }, { 36, 0x0F }, { 37, 0x0F }, { 38, 0x0F },
+   { 39, 0x00 }, { 40, 0x02 }, { 41, 0x02 }, { 42, 0x02 }, { 43, 0x0F },
+   { 44, 0x0F }, { 45, 0x0F }, { 46, 0x0F }, { 47, 0x0F }, { 48, 0x0F },
+   { 49, 0x0F }, { 50, 0x00 }, { 51, 0x02 }, { 52, 0x02 }, { 53, 0x02 },
+   { 80, 0x0C }, { 83, 0x42 }, { 84, 0x42 }, { 85, 0x41 }, { 86, 0x14 },
+   { 89, 0x88 }, { 90, 0x01 }, { 91, 0x00 }, { 92, 0x02 }, { 93, 0x0C },
+   { 94, 0x1C }, { 95, 0x27 }, { 98, 0x49 }, { 99, 0x27 }, { 102, 0x76 },
+ 

[PATCH v4] OMAP3: DSS: Kconfig changes to enable display options on OMAP3

[Samreen]

The defconfig options for display are taken in the respective Kconfig
to enable display by default on OMAP3 platforms

Signed-off-by: Samreen samr...@ti.com
---
 Version4:
   Remove the enabling of the display panels by default.

 Version3:
   Eliminate the separate default number of FBs for
 different architecture. Keeping default FBs as 3 as before.

 Version2:
Enables by default NEC panel used in zoom2/3/3630sdp, instead of 
 Sharp LQ043T1DG01 panel enabled in previous version of this patch.

 drivers/video/omap2/dss/Kconfig|6 --
 drivers/video/omap2/omapfb/Kconfig |1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig
index 43b6440..f3244a2 100644
--- a/drivers/video/omap2/dss/Kconfig
+++ b/drivers/video/omap2/dss/Kconfig
@@ -1,6 +1,7 @@
 menuconfig OMAP2_DSS
 tristate OMAP2/3 Display Subsystem support (EXPERIMENTAL)
 depends on ARCH_OMAP2 || ARCH_OMAP3
+   default y
 help
   OMAP2/3 Display Subsystem support.
 
@@ -9,7 +10,7 @@ if OMAP2_DSS
 config OMAP2_VRAM_SIZE
int VRAM size (MB)
range 0 32
-   default 0
+   default 4
help
  The amount of SDRAM to reserve at boot time for video RAM use.
  This VRAM will be used by omapfb and other drivers that need
@@ -102,7 +103,8 @@ config OMAP2_DSS_FAKE_VSYNC
 config OMAP2_DSS_MIN_FCK_PER_PCK
int Minimum FCK/PCK ratio (for scaling)
range 0 32
-   default 0
+   default 4  if ARCH_OMAP2 || ARCH_OMAP3
+   default 0  if ARCH_OMAP4
help
  This can be used to adjust the minimum FCK/PCK ratio.
 
diff --git a/drivers/video/omap2/omapfb/Kconfig 
b/drivers/video/omap2/omapfb/Kconfig
index 65149b2..923bf48 100644
--- a/drivers/video/omap2/omapfb/Kconfig
+++ b/drivers/video/omap2/omapfb/Kconfig
@@ -1,6 +1,7 @@
 menuconfig FB_OMAP2
 tristate OMAP2/3 frame buffer support (EXPERIMENTAL)
 depends on FB  OMAP2_DSS
+   default y
 
select OMAP2_VRAM
select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
-- 
1.5.6.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/8] staging: tidspbridge - misc fixes

[Greg KH]

On Mon, Oct 25, 2010 at 07:51:38PM -0500, Fernando Guzman Lugo wrote:
 This set of patches fix some issues found in lastest tree.
 
 Fernando Guzman Lugo (8):
   staging: tidspbridge - remove req_addr from proc_map
   staging: tidspbridge - add kconfig parameter for DMM size
   staging: tidspbridge - change mmufault tasklet to a workqueue
   staging: tidspbridge - fix timeout in dsp_gpt_wait_overflow
   staging: tidspbridge - use GTP7 for DSP stack dump
   staging: tidspbridge - remove disabling twl when printing DSP stack
   staging: tidspbridge - fix some issues after iommu patches
   staging: tidspbridge - make sync_wait_on_event interruptible

Are any of these really applicable for .37 after .37-rc1?  Or can they
wait for .38?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] OMAP3: Enable display on ZOOM2/3/3630SDP

[Samreen]

From: Kishore Y kishor...@ti.com

Enable Display on zoom2, zoom3 and 3630sdp boards.

Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Kishore Y kishor...@ti.com
Signed-off-by: Samreen samr...@ti.com
---
 arch/arm/mach-omap2/board-3630sdp.c |1 +
 arch/arm/mach-omap2/board-zoom2.c   |1 +
 arch/arm/mach-omap2/board-zoom3.c   |1 +
 3 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-3630sdp.c 
b/arch/arm/mach-omap2/board-3630sdp.c
index b359c3f..d6ba94a 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -210,6 +210,7 @@ static void __init omap_sdp_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
omap_serial_init();
zoom_peripherals_init();
+   zoom_display_init();
board_smc91x_init();
board_flash_init(sdp_flash_partitions, chip_sel_sdp);
enable_board_wakeup_source();
diff --git a/arch/arm/mach-omap2/board-zoom2.c 
b/arch/arm/mach-omap2/board-zoom2.c
index 3ad9ecf..1db4d95 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -138,6 +138,7 @@ static void __init omap_zoom2_init(void)
board_nand_init(zoom_nand_partitions,
ARRAY_SIZE(zoom_nand_partitions), ZOOM_NAND_CS);
zoom_debugboard_init();
+   zoom_display_init();
 }
 
 MACHINE_START(OMAP_ZOOM2, OMAP Zoom2 board)
diff --git a/arch/arm/mach-omap2/board-zoom3.c 
b/arch/arm/mach-omap2/board-zoom3.c
index 6ca0b83..6e012f6 100644
--- a/arch/arm/mach-omap2/board-zoom3.c
+++ b/arch/arm/mach-omap2/board-zoom3.c
@@ -117,6 +117,7 @@ static void __init omap_zoom_init(void)
board_nand_init(zoom_nand_partitions,
 ARRAY_SIZE(zoom_nand_partitions), ZOOM_NAND_CS);
zoom_debugboard_init();
+   zoom_display_init();
 
omap_mux_init_gpio(64, OMAP_PIN_OUTPUT);
usb_ehci_init(ehci_pdata);
-- 
1.5.6.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/2] OMAP3: Display Support

[Samreen]

This patch series adds the Display Support for OMAP3 platforms
and the corresponding changes in the board files.

Version2:
   - Optimised to configure INTBR from gpio to PWM1 mode setting and 
   enabling of the PWM1 mode only when its not in PWM1 mode.

Kishore Y (2):
  OMAP3: ZOOM2/3/3630SDP: Add display board file for OMAP3
  OMAP3: Enable display on ZOOM2/3/3630SDP

 arch/arm/mach-omap2/Makefile  |3 +
 arch/arm/mach-omap2/board-3630sdp.c   |1 +
 arch/arm/mach-omap2/board-zoom-display.c  |  167 +
 arch/arm/mach-omap2/board-zoom-peripherals.c  |   49 +++-
 arch/arm/mach-omap2/board-zoom2.c |1 +
 arch/arm/mach-omap2/board-zoom3.c |1 +
 arch/arm/mach-omap2/include/mach/board-zoom.h |2 +
 7 files changed, 222 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-zoom-display.c

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] omap: dma: Add read-back to DMA interrupt handler to avoid spurious interrupts

[Shilimkar, Santosh]

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Mathias Nyman
 Sent: Monday, October 25, 2010 8:05 PM
 To: linux-omap@vger.kernel.org
 Cc: Mathias Nyman
 Subject: [PATCH] omap: dma: Add read-back to DMA interrupt handler to
 avoid spurious interrupts
 
 Flush the writes to IRQSTATUS_L0 register in the DMA interrupt handler by
 reading the register
 directly after write. This prevents the spurious DMA interrupts noted when
 using VDD_OPP 1

Good fix Mathias.
Actually we should also clear other status lines as well when
used with multiple master initiator scenario's. But that need some
additional fixes as well. 

 Signed-off-by: Mathias Nyman mathias.ny...@nokia.com

Acked-by: Santosh Shilimkar santosh.shilim...@ti.com

 ---
  arch/arm/plat-omap/dma.c |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
 index f5c5b8d..2c28265 100644
 --- a/arch/arm/plat-omap/dma.c
 +++ b/arch/arm/plat-omap/dma.c
 @@ -1983,6 +1983,8 @@ static int omap2_dma_handle_ch(int ch)
 
   dma_write(OMAP2_DMA_CSR_CLEAR_MASK, CSR(ch));
   dma_write(1  ch, IRQSTATUS_L0);
 + /* read back the register to flush the write */
 + dma_read(IRQSTATUS_L0);
 
   /* If the ch is not chained then chain_id will be -1 */
   if (dma_chan[ch].chain_id != -1) {
 --
 1.5.6.5
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap 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-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] tidspbridge: convert OMAP3430 adaptation layer to use new SCM DSP boot control fns

[Paul Walmsley]

Hi Omar,

On Fri, 22 Oct 2010, Omar Ramirez Luna wrote:

  arch/arm/mach-omap2/dsp.c |4 
  arch/arm/plat-omap/include/plat/dsp.h |4 
  drivers/staging/tidspbridge/core/tiomap3430.c |   13 ++---

Could you please split the tiomap3430.c change into a separate patch?  
That should go in via the staging tree once this series is accepted.  The 
rest should go in via Tony.  Patch two needs to be acked by Kevin.


- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html