date:20110317

Re: [PATCH 1/2] arm: mach-omap2: devices: fix omap3_l3_init() return value

2011-03-17 Thread Cousson, Benoit


Hi Santosh,

On 3/17/2011 6:52 AM, Shilimkar, Santosh wrote:

-Original Message-
From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-
arm-kernel-boun...@lists.infradead.org] On Behalf Of Aaro Koskinen
Sent: Wednesday, March 16, 2011 10:46 PM
To: linux-omap@vger.kernel.org; linux-arm-
ker...@lists.infradead.org; t...@atomide.com
Cc: Aaro Koskinen
Subject: [PATCH 1/2] arm: mach-omap2: devices: fix omap3_l3_init()
return value

Fix the return value for the successful case.

Signed-off-by: Aaro Koskinenaaro.koski...@nokia.com
---
  arch/arm/mach-omap2/devices.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-
omap2/devices.c
index 0d2d6a9..d478f53 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -65,7 +65,7 @@ static int __init omap3_l3_init(void)

WARN(IS_ERR(od), could not build omap_device for %s\n,
oh_name);

-   return PTR_ERR(od);
+   return IS_ERR(od) ? PTR_ERR(od) : 0;
  }
  postcore_initcall(omap3_l3_init);


Maybe we should initialize that before, because in theory the timer12 
secure violation should have been captured easily with this code?


Regards,
Benoit
--
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: [RFCv2 2/2] AM35x: voltage: Basic initialization

2011-03-17 Thread Premi, Sanjeev

 -Original Message-
 From: Sripathy, Vishwanath 
 Sent: Wednesday, March 16, 2011 4:33 PM
 To: Premi, Sanjeev; linux-omap@vger.kernel.org
 Subject: RE: [RFCv2 2/2] AM35x: voltage: Basic initialization

  -Original Message-
  From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
  ow...@vger.kernel.org] On Behalf Of Sanjeev Premi
  Sent: Wednesday, March 16, 2011 1:02 PM
  To: linux-omap@vger.kernel.org
  Cc: Sanjeev Premi
  Subject: [RFCv2 2/2] AM35x: voltage: Basic initialization

  This patch adds the basic initialization of voltage layer
  for AM35x. Since AM35x doesn't support voltage scaling,
  Many functions emply fucntions have been defined to plug
  into existing voltage layer.

  Signed-off-by: Sanjeev Premi pr...@ti.com
  ---

[snip]...[snip]

  +/**
  + * AM35x - Empty initialization of voltage processor
  + */
  +static void __init am3517_vp_init(struct omap_vdd_info *vdd)
  +{
  +}
  +
  +/**
* omap_voltage_early_init()- Volatage driver early init
*/
   static int __init omap_voltage_early_init(void)
   {
  int i;

  -   if (cpu_is_omap34xx()) {
  +   if (cpu_is_omap3505() || cpu_is_omap3517()) {
  +   vdd_info= am3517_vdd_info;
  +   nr_scalable_vdd =
  AM3517_NR_SCALABLE_VDD;
 As you have mentioned that there is no voltage scaling supported, then
 shoudn't nr_scalable_vdd = 0?
 If nr_scalable_vdd is 0, then you probably would not need any 
 other TPS
 specific changes in Voltage.c as VP and VC initialization itself is
 skipped.

[sp] Yes, there is no voltage scaling; but there are two problems in the
 flow.
 Notice I had this value 0 in previous RFC; and yes I expected the
 vp and vc to be excluded as you say; however, code isn't really
 meant to do so.
 Few loops using nr_scalable_vdd fail as value 0 doesn't meet the
 entry criteria. This problem is/was easily fixes by an additional
 if statement.

 The things, however, get stuck in HWMOD again when the parent of
 omap3xxx_l3_main_hwmod is set as core. Changing this causes
 another cascade of changes leading to almost duplicating the complete
 hwmod structure for AM35x.

 Easy solution was to set use core. Rest of the changes in the patch
 ensure that code flows properly - and there is no scaling.

~sanjeev

 Vishwa
  +   vc_init = am3517_vc_init;
  +   vp_init = am3517_vp_init;
  +   vdd_data_configure  = am3517_vdd_data_configure;
  +   } else if (cpu_is_omap34xx()) {
  vdd_info = omap3_vdd_info;
  nr_scalable_vdd = OMAP3_NR_SCALABLE_VDD;
  vc_init = omap3_vc_init;
  --
--
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 1/2] arm: mach-omap2: devices: fix omap3_l3_init() return value

2011-03-17 Thread Santosh Shilimkar

 -Original Message-
 From: Cousson, Benoit [mailto:b-cous...@ti.com]
 Sent: Thursday, March 17, 2011 1:50 PM
 To: Shilimkar, Santosh
 Cc: Aaro Koskinen; linux-omap@vger.kernel.org; linux-arm-
 ker...@lists.infradead.org; t...@atomide.com
 Subject: Re: [PATCH 1/2] arm: mach-omap2: devices: fix
 omap3_l3_init() return value

 Hi Santosh,

 On 3/17/2011 6:52 AM, Shilimkar, Santosh wrote:
  -Original Message-
  From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-
  arm-kernel-boun...@lists.infradead.org] On Behalf Of Aaro
 Koskinen
  Sent: Wednesday, March 16, 2011 10:46 PM
  To: linux-omap@vger.kernel.org; linux-arm-
  ker...@lists.infradead.org; t...@atomide.com
  Cc: Aaro Koskinen
  Subject: [PATCH 1/2] arm: mach-omap2: devices: fix
 omap3_l3_init()
  return value
 
  Fix the return value for the successful case.
 
  Signed-off-by: Aaro Koskinenaaro.koski...@nokia.com
  ---
arch/arm/mach-omap2/devices.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
 
  diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-
  omap2/devices.c
  index 0d2d6a9..d478f53 100644
  --- a/arch/arm/mach-omap2/devices.c
  +++ b/arch/arm/mach-omap2/devices.c
  @@ -65,7 +65,7 @@ static int __init omap3_l3_init(void)
 
 WARN(IS_ERR(od), could not build omap_device for %s\n,
  oh_name);
 
  -  return PTR_ERR(od);
  +  return IS_ERR(od) ? PTR_ERR(od) : 0;
}
postcore_initcall(omap3_l3_init);

 Maybe we should initialize that before, because in theory the
 timer12 secure violation should have been captured easily with
 this code?

The firewall exceptions handling is removed from L3 handler because
PPA has the trap implemented. We faced issues when the trap was
enabled in both places.

Regards
Santosh
--
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] OMAP4: PandaBoard: remove unused power regulators

2011-03-17 Thread Anand Gadiyar

David Anders wrote:
 the pandaboard does not use the VUSIM or VAUX1 power regulators on the
TWL6030
 and are left floating. if the VUSIM and VAUX1 power regulators are
initilized,
 noise on the unloaded regulators generates an overcurrent interrupt
causing the
 system to power down. this patch removes the initialization of the
unused power
 regulators of VUSIM and VAUX1.

 Signed-off-by: David Anders x0132...@ti.com

For what it's worth, thanks for tracking this down!

Acked-by: Anand Gadiyar gadi...@ti.com

 ---
  arch/arm/mach-omap2/board-omap4panda.c |   28

  1 files changed, 0 insertions(+), 28 deletions(-)

 diff --git a/arch/arm/mach-omap2/board-omap4panda.c
 b/arch/arm/mach-omap2/board-omap4panda.c
 index e944025..abc913b 100644
 --- a/arch/arm/mach-omap2/board-omap4panda.c
 +++ b/arch/arm/mach-omap2/board-omap4panda.c
 @@ -220,19 +220,6 @@ static int __init
 omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers)
   return 0;
  }

 -static struct regulator_init_data omap4_panda_vaux1 = {
 - .constraints = {
 - .min_uV = 100,
 - .max_uV = 300,
 - .apply_uV   = true,
 - .valid_modes_mask   = REGULATOR_MODE_NORMAL
 - | REGULATOR_MODE_STANDBY,
 - .valid_ops_mask  = REGULATOR_CHANGE_VOLTAGE
 - | REGULATOR_CHANGE_MODE
 - | REGULATOR_CHANGE_STATUS,
 - },
 -};
 -
  static struct regulator_init_data omap4_panda_vaux2 = {
   .constraints = {
   .min_uV = 120,
 @@ -288,19 +275,6 @@ static struct regulator_init_data omap4_panda_vpp =
{
   },
  };

 -static struct regulator_init_data omap4_panda_vusim = {
 - .constraints = {
 - .min_uV = 120,
 - .max_uV = 290,
 - .apply_uV   = true,
 - .valid_modes_mask   = REGULATOR_MODE_NORMAL
 - | REGULATOR_MODE_STANDBY,
 - .valid_ops_mask  = REGULATOR_CHANGE_VOLTAGE
 - | REGULATOR_CHANGE_MODE
 - | REGULATOR_CHANGE_STATUS,
 - },
 -};
 -
  static struct regulator_init_data omap4_panda_vana = {
   .constraints = {
   .min_uV = 210,
 @@ -356,12 +330,10 @@ static struct twl4030_platform_data
omap4_panda_twldata = {
   /* Regulators */
   .vmmc   = omap4_panda_vmmc,
   .vpp= omap4_panda_vpp,
 - .vusim  = omap4_panda_vusim,
   .vana   = omap4_panda_vana,
   .vcxio  = omap4_panda_vcxio,
   .vdac   = omap4_panda_vdac,
   .vusb   = omap4_panda_vusb,
 - .vaux1  = omap4_panda_vaux1,
   .vaux2  = omap4_panda_vaux2,
   .vaux3  = omap4_panda_vaux3,
   .usb= omap4_usbphy_data,
 --
 1.7.0.4

 --
 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 v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4

2011-03-17 Thread Tomi Valkeinen

Hi,

On Wed, 2011-03-16 at 18:49 -0500, Stephan Raue wrote:

 i tried this test tree with omap2plus_defconfig.
 
 it seems the kernel crashes and poweroff the board on loading this hdmi 
 stuff, but dont print any crashlog. is there a way any backtraces will 
 be printed?
 output from serial console: http://paste.pocoo.org/show/354850/
 kernel config (omap2plus_defconfig, added squashfs support, added 
 support to include initramfs in kernel, build omapfb stuff statically 
 into the kernel): http://paste.pocoo.org/show/354853/

Have the HDMI on your setup worked in any (prebuilt) image? What I'm
asking is if you are sure the HDMI HW works on your board?

Powering off quietly sounds strange. Is your power supply sufficient?
Well, I don't think that would explain the first crash you posted...

 Tomi


--
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] omap3: beaglexm: fix user button.

2011-03-17 Thread Javier Martin

User push button in Beagleboard xM is 4 instead of 7.

Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
 arch/arm/mach-omap2/board-omap3beagle.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
b/arch/arm/mach-omap2/board-omap3beagle.c
index 46d814a..abf87d1 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -615,6 +615,10 @@ static void __init omap3_beagle_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3_beagle_init_rev();
omap3_beagle_i2c_init();
+   /* xM version uses pin 4 instead of 7 for user button */
+   if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+   gpio_buttons[0].gpio = 4;
+   }
platform_add_devices(omap3_beagle_devices,
ARRAY_SIZE(omap3_beagle_devices));
omap_serial_init();
-- 
1.7.0.4

--
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] OMAP4: PandaBoard: remove unused power regulators

2011-03-17 Thread Kevin Hilman

David Anders x0132...@ti.com writes:

 the pandaboard does not use the VUSIM or VAUX1 power regulators on the TWL6030
 and are left floating. if the VUSIM and VAUX1 power regulators are initilized,
 noise on the unloaded regulators generates an overcurrent interrupt causing 
 the
 system to power down. this patch removes the initialization of the unused 
 power
 regulators of VUSIM and VAUX1.

 Signed-off-by: David Anders x0132...@ti.com

Thanks for finding and fixing the root cause.

Tested-by: Kevin Hilman khil...@ti.com

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 01/19] OMAP3: hwmod: add SmartReflex IRQs

2011-03-17 Thread Kevin Hilman

Hi Nishanth,

Nishanth Menon n...@ti.com writes:

 OMAP3 SmartReflex IRQs in hwmod structures with the same naming as
 present in OMAP4. Without these IRQs being registered, SmartReflex
 driver will be unable to get the IRQ numbers to handle notifications

 Signed-off-by: Nishanth Menon n...@ti.com
 ---
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   17 +
  1 files changed, 17 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 index 196a834..2d464bc 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 @@ -378,6 +378,15 @@ static struct omap_hwmod_ocp_if omap3_l4_core__i2c3 = {
   .user   = OCP_USER_MPU | OCP_USER_SDMA,
  };
  
 +
 +static struct omap_hwmod_irq_info omap3_smartreflex_mpu_irqs[] = {
 + {.name = sr1_irq, .irq = 18},
 +};
 +
 +static struct omap_hwmod_irq_info omap3_smartreflex_core_irqs[] = {
 + {.name = sr2_irq, .irq = 19},
 +};

The name here doesn't seem to be needed.

Kevin

  /* L4 CORE - SR1 interface */
  static struct omap_hwmod_addr_space omap3_sr1_addr_space[] = {
   {
 @@ -2925,6 +2934,8 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2 |
   CHIP_IS_OMAP3430ES3_0 |
   CHIP_IS_OMAP3430ES3_1),
 + .mpu_irqs   = omap3_smartreflex_mpu_irqs,
 + .mpu_irqs_cnt   = ARRAY_SIZE(omap3_smartreflex_mpu_irqs),
   .flags  = HWMOD_SET_DEFAULT_CLOCKACT,
  };
  
 @@ -2945,6 +2956,8 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
   .slaves = omap3_sr1_slaves,
   .slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
 + .mpu_irqs   = omap3_smartreflex_mpu_irqs,
 + .mpu_irqs_cnt   = ARRAY_SIZE(omap3_smartreflex_mpu_irqs),
  };
  
  /* SR2 */
 @@ -2971,6 +2984,8 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2 |
   CHIP_IS_OMAP3430ES3_0 |
   CHIP_IS_OMAP3430ES3_1),
 + .mpu_irqs   = omap3_smartreflex_core_irqs,
 + .mpu_irqs_cnt   = ARRAY_SIZE(omap3_smartreflex_core_irqs),
   .flags  = HWMOD_SET_DEFAULT_CLOCKACT,
  };
  
 @@ -2991,6 +3006,8 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
   .slaves = omap3_sr2_slaves,
   .slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
 + .mpu_irqs   = omap3_smartreflex_core_irqs,
 + .mpu_irqs_cnt   = ARRAY_SIZE(omap3_smartreflex_core_irqs),
  };
  
  /*
--
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 02/19] OMAP3+: voltage: fix build warning

2011-03-17 Thread Kevin Hilman

Nishanth Menon n...@ti.com writes:

 Handle the case for a future SoC where sys_ck_name might be
 uninitialized. Fixes the build warning:
 arch/arm/mach-omap2/voltage.c: In function 'omap_voltage_late_init':
 arch/arm/mach-omap2/voltage.c:86:8: warning: 'sys_ck_name' may be used 
 uninitialized in this function

 Signed-off-by: Nishanth Menon n...@ti.com

This one seems to be already fixed in l-o commit:

commit c0718df4d666cc5fd8837ac93c82995a17bfdbf5
Author: Paul Walmsley p...@pwsan.com
Date:   Thu Mar 10 22:17:45 2011 -0700

OMAP2+: voltage: reorganize, split code from data

Kevin

 ---
  arch/arm/mach-omap2/voltage.c |8 ++--
  1 files changed, 6 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
 index e0cbd93..56961df 100644
 --- a/arch/arm/mach-omap2/voltage.c
 +++ b/arch/arm/mach-omap2/voltage.c
 @@ -91,10 +91,14 @@ static int __init _config_common_vdd_data(struct 
 omap_vdd_info *vdd)
* XXX Clockfw should handle this, or this should be in a
* struct record
*/
 - if (cpu_is_omap24xx() || cpu_is_omap34xx())
 + if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
   sys_ck_name = sys_ck;
 - else if (cpu_is_omap44xx())
 + } else if (cpu_is_omap44xx()) {
   sys_ck_name = sys_clkin_ck;
 + } else {
 + pr_err(%s: Unsupported OMAP\n, __func__);
 + return -EINVAL;
 + }
  
   /*
* Sys clk rate is require to calculate vp timeout value and
--
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 03/19] OMAP3+: voltage: remove initial voltage

2011-03-17 Thread Kevin Hilman

Nishanth Menon n...@ti.com writes:

 Blindly setting a 1.2V setting in the initial structure may not even
 match the default voltages stored in the voltage table which are
 supported for the domain. For example, OMAP3430 core domain does not
 use 1.2V and ends up generating a warning on the first transition.

 Further, since omap2_set_init_voltage is called as part of the pm
 framework's initialization sequence to configure the voltage required
 for the current OPP, the call does(and has to) setup the system
 voltage(curr_volt as a result) using the right mechanisms appropriate
 for the system at that point of time. This also overrides
 initialization we are currently doing in voltage.c making it
 redundant. So, remove the wrong and redundant initialization.

 Signed-off-by: Nishanth Menon n...@ti.com

Thanks queuing for 2.6.39 fixes (branch: for_2.6.39/pm-fixes)

Note: Nishanth, I queued the one with updated changelog from the tarball
you sent.)

Kevin

 ---
  arch/arm/mach-omap2/voltage.c |1 -
  1 files changed, 0 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
 index 56961df..1b40aa0 100644
 --- a/arch/arm/mach-omap2/voltage.c
 +++ b/arch/arm/mach-omap2/voltage.c
 @@ -116,7 +116,6 @@ static int __init _config_common_vdd_data(struct 
 omap_vdd_info *vdd)
   sys_clk_speed /= 1000;
  
   /* Generic voltage parameters */
 - vdd-curr_volt = 120;
   vdd-volt_scale = vp_forceupdate_scale_voltage;
   vdd-vp_enabled = false;
--
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 04/19] OMAP3+: voltage: remove spurious pr_notice for debugfs

2011-03-17 Thread Kevin Hilman

Nishanth Menon n...@ti.com writes:

 cat of debugfs entry for vp_volt provides voltage. The additional pr_notice
 is just spam on console and provides no additional information.

 Signed-off-by: Nishanth Menon n...@ti.com

Thanks, queueing for 2.6.39-rc fixes cycle.

Kevin

 ---
  arch/arm/mach-omap2/voltage.c |1 -
  1 files changed, 0 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
 index 1b40aa0..53c399f 100644
 --- a/arch/arm/mach-omap2/voltage.c
 +++ b/arch/arm/mach-omap2/voltage.c
 @@ -150,7 +150,6 @@ static int vp_volt_debug_get(void *data, u64 *val)
   }
  
   vsel = vdd-read_reg(prm_mod_offs, vdd-vp_data-voltage);
 - pr_notice(curr_vsel = %x\n, vsel);
  
   if (!vdd-pmic_info-vsel_to_uv) {
   pr_warning(PMIC function to convert vsel to voltage
--
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/2] omap3: voltage: remove unnecessary param passing

2011-03-17 Thread Sanjeev Premi

It is not necessary to pass the params prm_mod and
prm_irqst_mod to omap_voltage_early_init().

Signed-off-by: Sanjeev Premi pr...@ti.com
---
 arch/arm/mach-omap2/voltage.c |   18 ++
 arch/arm/mach-omap2/voltage.h |3 +--
 arch/arm/mach-omap2/voltagedomains3xxx_data.c |5 +
 arch/arm/mach-omap2/voltagedomains44xx_data.c |6 +-
 4 files changed, 17 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index c6facf7..ce3098a 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -1096,12 +1096,22 @@ int __init omap_voltage_late_init(void)
 }
 
 /* XXX document */
-int __init omap_voltage_early_init(s16 prm_mod, s16 prm_irqst_ocp_mod,
-  struct omap_vdd_info *omap_vdd_array[],
+int __init omap_voltage_early_init(struct omap_vdd_info *omap_vdd_array[],
   u8 omap_vdd_count)
 {
-   prm_mod_offs = prm_mod;
-   prm_irqst_ocp_mod_offs = prm_irqst_ocp_mod;
+   if (cpu_is_omap44xx()) {
+   prm_mod_offs = OMAP4430_PRM_DEVICE_INST;
+   prm_irqst_ocp_mod_offs = OMAP4430_PRM_OCP_SOCKET_INST;
+   } else if (cpu_is_omap34xx()) {
+   prm_mod_offs = OMAP3430_GR_MOD;
+   prm_irqst_ocp_mod_offs = OCP_MOD;
+   } else {
+   /* TODO:
+* What should be done for OMAP24xx?
+* Would we even reach here?
+*/
+   }
+
vdd_info = omap_vdd_array;
nr_scalable_vdd = omap_vdd_count;
return 0;
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index e9f5408..b56530e 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -151,8 +151,7 @@ struct omap_volt_data *omap_voltage_get_voltdata(struct 
voltagedomain *voltdm,
unsigned long volt);
 unsigned long omap_voltage_get_nom_volt(struct voltagedomain *voltdm);
 struct dentry *omap_voltage_get_dbgdir(struct voltagedomain *voltdm);
-int __init omap_voltage_early_init(s16 prm_mod, s16 prm_irqst_mod,
-  struct omap_vdd_info *omap_vdd_array[],
+int __init omap_voltage_early_init(struct omap_vdd_info *omap_vdd_array[],
   u8 omap_vdd_count);
 #ifdef CONFIG_PM
 int omap_voltage_register_pmic(struct voltagedomain *voltdm,
diff --git a/arch/arm/mach-omap2/voltagedomains3xxx_data.c 
b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
index def230f..6f6999d 100644
--- a/arch/arm/mach-omap2/voltagedomains3xxx_data.c
+++ b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
@@ -70,8 +70,6 @@ static struct omap_vdd_info *omap3_vdd_info[] = {
 /* OMAP3 specific voltage init functions */
 static int __init omap3xxx_voltage_early_init(void)
 {
-   s16 prm_mod = OMAP3430_GR_MOD;
-   s16 prm_irqst_ocp_mod = OCP_MOD;
 
if (!cpu_is_omap34xx())
return 0;
@@ -88,8 +86,7 @@ static int __init omap3xxx_voltage_early_init(void)
omap3_vdd2_info.volt_data = omap34xx_vddcore_volt_data;
}
 
-   return omap_voltage_early_init(prm_mod, prm_irqst_ocp_mod,
-  omap3_vdd_info,
+   return omap_voltage_early_init(omap3_vdd_info,
   ARRAY_SIZE(omap3_vdd_info));
 };
 core_initcall(omap3xxx_voltage_early_init);
diff --git a/arch/arm/mach-omap2/voltagedomains44xx_data.c 
b/arch/arm/mach-omap2/voltagedomains44xx_data.c
index cb64996..208a67d 100644
--- a/arch/arm/mach-omap2/voltagedomains44xx_data.c
+++ b/arch/arm/mach-omap2/voltagedomains44xx_data.c
@@ -81,9 +81,6 @@ static struct omap_vdd_info *omap4_vdd_info[] = {
 /* OMAP4 specific voltage init functions */
 static int __init omap44xx_voltage_early_init(void)
 {
-   s16 prm_mod = OMAP4430_PRM_DEVICE_INST;
-   s16 prm_irqst_ocp_mod = OMAP4430_PRM_OCP_SOCKET_INST;
-
if (!cpu_is_omap44xx())
return 0;
 
@@ -95,8 +92,7 @@ static int __init omap44xx_voltage_early_init(void)
omap4_vdd_iva_info.volt_data = omap44xx_vdd_iva_volt_data;
omap4_vdd_core_info.volt_data = omap44xx_vdd_core_volt_data;
 
-   return omap_voltage_early_init(prm_mod, prm_irqst_ocp_mod,
-  omap4_vdd_info,
+   return omap_voltage_early_init(omap4_vdd_info,
   ARRAY_SIZE(omap4_vdd_info));
 };
 core_initcall(omap44xx_voltage_early_init);
-- 
1.7.2.2

--
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 2/2] omap3: voltage: fix variable type and name

2011-03-17 Thread Sanjeev Premi

In all usages, variables prm_mod_offs and prm_irqst_ocp_mod_offs
are expected to be u16 but have been declared as s16.

In addition, renamed prm_irqst_ocp_mod_offs to ocp_sysreg_prm_offs
for better association with the TRM. Original name perhaps came
from the current usage of this offset to reach PRM_IRQSTATUS_MPU
offset.

Signed-off-by: Sanjeev Premi pr...@ti.com
---
 arch/arm/mach-omap2/voltage.c |   18 +-
 1 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index ce3098a..c686eca 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -51,8 +51,8 @@ static struct omap_vdd_info **vdd_info;
 static int nr_scalable_vdd;
 
 /* XXX document */
-static s16 prm_mod_offs;
-static s16 prm_irqst_ocp_mod_offs;
+static u16 prm_mod_offs;
+static u16 ocp_sysreg_prm_offs;
 
 static struct dentry *voltage_dir;
 
@@ -447,8 +447,8 @@ static int vp_forceupdate_scale_voltage(struct 
omap_vdd_info *vdd,
 */
while (timeout++  VP_TRANXDONE_TIMEOUT) {
vdd-write_reg(vdd-vp_data-prm_irqst_data-tranxdone_status,
-  prm_irqst_ocp_mod_offs, prm_irqst_reg);
-   if (!(vdd-read_reg(prm_irqst_ocp_mod_offs, prm_irqst_reg) 
+  ocp_sysreg_prm_offs, prm_irqst_reg);
+   if (!(vdd-read_reg(ocp_sysreg_prm_offs, prm_irqst_reg) 
  vdd-vp_data-prm_irqst_data-tranxdone_status))
break;
udelay(1);
@@ -481,7 +481,7 @@ static int vp_forceupdate_scale_voltage(struct 
omap_vdd_info *vdd,
 * Depends on SMPSWAITTIMEMIN/MAX and voltage change
 */
timeout = 0;
-   omap_test_timeout((vdd-read_reg(prm_irqst_ocp_mod_offs, prm_irqst_reg) 

+   omap_test_timeout((vdd-read_reg(ocp_sysreg_prm_offs, prm_irqst_reg) 
   vdd-vp_data-prm_irqst_data-tranxdone_status),
  VP_TRANXDONE_TIMEOUT, timeout);
if (timeout = VP_TRANXDONE_TIMEOUT)
@@ -498,8 +498,8 @@ static int vp_forceupdate_scale_voltage(struct 
omap_vdd_info *vdd,
timeout = 0;
while (timeout++  VP_TRANXDONE_TIMEOUT) {
vdd-write_reg(vdd-vp_data-prm_irqst_data-tranxdone_status,
-  prm_irqst_ocp_mod_offs, prm_irqst_reg);
-   if (!(vdd-read_reg(prm_irqst_ocp_mod_offs, prm_irqst_reg) 
+  ocp_sysreg_prm_offs, prm_irqst_reg);
+   if (!(vdd-read_reg(ocp_sysreg_prm_offs, prm_irqst_reg) 
  vdd-vp_data-prm_irqst_data-tranxdone_status))
break;
udelay(1);
@@ -1101,10 +1101,10 @@ int __init omap_voltage_early_init(struct omap_vdd_info 
*omap_vdd_array[],
 {
if (cpu_is_omap44xx()) {
prm_mod_offs = OMAP4430_PRM_DEVICE_INST;
-   prm_irqst_ocp_mod_offs = OMAP4430_PRM_OCP_SOCKET_INST;
+   ocp_sysreg_prm_offs = OMAP4430_PRM_OCP_SOCKET_INST;
} else if (cpu_is_omap34xx()) {
prm_mod_offs = OMAP3430_GR_MOD;
-   prm_irqst_ocp_mod_offs = OCP_MOD;
+   ocp_sysreg_prm_offs = OCP_MOD;
} else {
/* TODO:
 * What should be done for OMAP24xx?
-- 
1.7.2.2

--
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/3] ARM: OMAP2+: gpmc warning fixes

2011-03-17 Thread Balaji T K

Applies on omap-for-linus branch
Boot tested on OMAP4430 SDP and OMAP3630SDP

Balaji T K (3):
  ARM: OMAP2+: correct GPMC IRQ
  ARM: OMAP2+: GPMC set dummy irq chip
  ARM: OMAP4: correct GPMC IRQ number

 arch/arm/mach-omap2/gpmc.c |   13 -
 arch/arm/plat-omap/include/plat/irqs.h |2 +-
 2 files changed, 9 insertions(+), 6 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 3/3] ARM: OMAP4: correct GPMC IRQ number

2011-03-17 Thread Balaji T K

OMAP4 GPMC IRQ is not same as OMAP3 IRQ. Fix it.

Resolve following warning in OMAP4
[0.429290] gpmc: irq-20 could not claim: err -22

Signed-off-by: Balaji T K balaj...@ti.com
---
 arch/arm/mach-omap2/gpmc.c |   10 ++
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index d81d536..493505c 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -693,6 +693,7 @@ static int __init gpmc_init(void)
 {
u32 l, irq;
int cs, ret = -EINVAL;
+   int gpmc_irq;
char *ck = NULL;
 
if (cpu_is_omap24xx()) {
@@ -701,12 +702,15 @@ static int __init gpmc_init(void)
l = OMAP2420_GPMC_BASE;
else
l = OMAP34XX_GPMC_BASE;
+   gpmc_irq = INT_34XX_GPMC_IRQ;
} else if (cpu_is_omap34xx()) {
ck = gpmc_fck;
l = OMAP34XX_GPMC_BASE;
+   gpmc_irq = INT_34XX_GPMC_IRQ;
} else if (cpu_is_omap44xx()) {
ck = gpmc_ck;
l = OMAP44XX_GPMC_BASE;
+   gpmc_irq = OMAP44XX_IRQ_GPMC;
}
 
if (WARN_ON(!ck))
@@ -745,11 +749,11 @@ static int __init gpmc_init(void)
irq++;
}
 
-   ret = request_irq(INT_34XX_GPMC_IRQ,
+   ret = request_irq(gpmc_irq,
gpmc_handle_irq, IRQF_SHARED, gpmc, gpmc_base);
if (ret)
pr_err(gpmc: irq-%d could not claim: err %d\n,
-   INT_34XX_GPMC_IRQ, ret);
+   gpmc_irq, ret);
return ret;
 }
 postcore_initcall(gpmc_init);
@@ -758,8 +762,6 @@ static irqreturn_t gpmc_handle_irq(int irq, void *dev)
 {
u8 cs;
 
-   if (irq != INT_34XX_GPMC_IRQ)
-   return IRQ_HANDLED;
/* check cs to invoke the irq */
cs = ((gpmc_read_reg(GPMC_PREFETCH_CONFIG1))  CS_NUM_SHIFT)  0x7;
if (OMAP_GPMC_IRQ_BASE+cs = OMAP_GPMC_IRQ_END)
-- 
1.7.0.4

--
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 v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4

2011-03-17 Thread Janorkar, Mayuresh

Raue,

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Valkeinen, Tomi
 Sent: Thursday, March 17, 2011 4:41 PM
 To: Stephan Raue
 Cc: K, Mythri P; linux-omap@vger.kernel.org
 Subject: Re: [PATCH v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4

 Hi,

 On Wed, 2011-03-16 at 18:49 -0500, Stephan Raue wrote:

  i tried this test tree with omap2plus_defconfig.

  it seems the kernel crashes and poweroff the board on loading this hdmi
  stuff, but dont print any crashlog. is there a way any backtraces will
  be printed?
  output from serial console: http://paste.pocoo.org/show/354850/
  kernel config (omap2plus_defconfig, added squashfs support, added
  support to include initramfs in kernel, build omapfb stuff statically
  into the kernel): http://paste.pocoo.org/show/354853/

Is it possible for you to enable low-level debugging and pass omapfb.debug=1 
omapdss.debug=1 in your bootargs?
This would show the Framebuffer and DSSDBG prints. We would get an idea if 
kernel is getting stuck in DSS/OMAPFB.

Let me know if you any help in enabling debug prints.

Also one more suggestion/ question, are you seeing a hang if DSS is not enabled 
in kernel?

-Thanks,
Mayuresh

 Have the HDMI on your setup worked in any (prebuilt) image? What I'm
 asking is if you are sure the HDMI HW works on your board?

 Powering off quietly sounds strange. Is your power supply sufficient?
 Well, I don't think that would explain the first crash you posted...

  Tomi

 --
 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 V3 06/19] OMAP3+: voltage: use volt_data pointer instead values

2011-03-17 Thread Kevin Hilman

Nishanth Menon n...@ti.com writes:

 Voltage values can get confusing in meaning with various SmartReflex
 classes being active. Depending on the class used, the actual voltage
 selected might be a variant. For example:
 With SmartReflex AVS class 3:
 a) If we don't have SR enabled, we will go to volt_nominal.
 b) If have SR enabled, we go to volt_nominal, then enable SR and
expect it to adjust voltage. We don't really care about the
resultant voltage.
 Essentially, when we ask voltage layer to scale to voltage x for OPP
 y, it always means x is the nominal voltage for OPP y.

 Now, once we introduce SmartReflex AVS class 1.5:
 a) If you are booting for the first time OR if you never enabled SR
before, we always go to volt_nominal.
 b) If you enable SR and the OPP is calibrated, we will not enable SR
again when that OPP is accessed anymore, but when we set voltage for
an OPP, the voltage achieved will be volt_calibrated.
 c) If recalibration timeout triggers or SR is disabled after a
calibration, the calibrated values are not valid anymore, at this point,
setting the voltage will mean volt_dynamic_nominal.
 So, depending on which state the system is at, voltage for that OPP
 we are setting has not 1 single value anymore, but 3 possible valid
 values.

 For upper layers(DVFS/cpufreq OMAP SoC layers) to use voltage values, it
 will need to know which type of voltage AVS strategy is being used and
 the corresponding system state from voltage layer perspective. This
 would replicate the role of voltage layer, SmartReflex AVS in the upper
 layers and make the corresponding implementations complex.

 Since each voltage domain contains a set of volt_data structs representing
 a voltage point that is supported for that domain, volt_data is a more
 accurate representation of the voltage point we are interested in going to,
 and the actual translation of this voltage point to the voltage value is
 done inside the voltage layer. Doing this allows the users of the voltage
 layer to be blissfully ignorant of any complexity of the underneath
 layers and simplify the implementation of dependent layers.

 Signed-off-by: Nishanth Menon n...@ti.com

Mostly coding style and/or readability comments below...

 ---
  arch/arm/mach-omap2/pm.c |3 +-
  arch/arm/mach-omap2/smartreflex-class3.c |3 +-
  arch/arm/mach-omap2/voltage.c|   75 
 +-
  arch/arm/mach-omap2/voltage.h|   17 +--
  4 files changed, 59 insertions(+), 39 deletions(-)

 diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
 index 2c3a253..2372744 100644
 --- a/arch/arm/mach-omap2/pm.c
 +++ b/arch/arm/mach-omap2/pm.c
 @@ -209,7 +209,8 @@ static int __init omap2_set_init_voltage(char *vdd_name, 
 char *clk_name,
   goto exit;
   }
  
 - omap_voltage_scale_vdd(voltdm, bootup_volt);
 + omap_voltage_scale_vdd(voltdm,
 + omap_voltage_get_voltdata(voltdm, bootup_volt));

coding style: to avoid wrapping (which IMO affects readabiliyt), assign
volt_data to it's own variable then pass it to scale_vdd.

   return 0;
  
  exit:
 diff --git a/arch/arm/mach-omap2/smartreflex-class3.c 
 b/arch/arm/mach-omap2/smartreflex-class3.c
 index f438cf4..2ee48af 100644
 --- a/arch/arm/mach-omap2/smartreflex-class3.c
 +++ b/arch/arm/mach-omap2/smartreflex-class3.c
 @@ -15,7 +15,8 @@
  
  static int sr_class3_enable(struct voltagedomain *voltdm)
  {
 - unsigned long volt = omap_voltage_get_nom_volt(voltdm);
 + unsigned long volt = omap_get_operation_voltage(
 + omap_voltage_get_nom_volt(voltdm));

readability/wrapping

Also, the name of the new function doesn't follow the naming convention
of the rest of the voltage layer: e.g. omap_voltage_...

   if (!volt) {
   pr_warning(%s: Curr voltage unknown. Cannot enable sr_%s\n,
 diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
 index 76bcaee..a12ac1e 100644
 --- a/arch/arm/mach-omap2/voltage.c
 +++ b/arch/arm/mach-omap2/voltage.c
 @@ -58,7 +58,7 @@ static struct dentry *voltage_dir;
  
  /* Init function pointers */
  static int vp_forceupdate_scale_voltage(struct omap_vdd_info *vdd,
 - unsigned long target_volt);
 + struct omap_volt_data *target_volt);
  
  static u32 omap3_voltage_read_reg(u16 mod, u8 offset)
  {
 @@ -164,13 +164,20 @@ static int vp_volt_debug_get(void *data, u64 *val)
  static int nom_volt_debug_get(void *data, u64 *val)
  {
   struct omap_vdd_info *vdd = (struct omap_vdd_info *) data;
 + struct omap_volt_data *volt_data;
  
   if (!vdd) {
   pr_warning(Wrong paramater passed\n);
   return -EINVAL;
   }
  
 - *val = omap_voltage_get_nom_volt(vdd-voltdm);
 + volt_data = omap_voltage_get_nom_volt(vdd-voltdm);
 + if (IS_ERR_OR_NULL(volt_data)) {
 + pr_warning(%s: No

Re: [PATCH V3 09/19] OMAP3+: SR: disable interrupt by default

2011-03-17 Thread Kevin Hilman

Nishanth Menon n...@ti.com writes:

 We will enable and disable interrupt on a need basis in the class
 driver. We need to keep the IRQ disabled by default else the
 forceupdate or vcbypass events could trigger events that we don't
 need/expect to handle.

 This is a preparation for SmartReflex AVS class drivers such as
 class 2 and class 1.5 which would need to use interrupts. Existing
 SmartReflex AVS class 3 driver does not require to use interrupts
 and is not impacted by this change.

 Signed-off-by: Nishanth Menon n...@ti.com

Thanks, queueing for 2.6.40

Kevin

 ---
  arch/arm/mach-omap2/smartreflex.c |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/smartreflex.c 
 b/arch/arm/mach-omap2/smartreflex.c
 index 7096300..f9057ad 100644
 --- a/arch/arm/mach-omap2/smartreflex.c
 +++ b/arch/arm/mach-omap2/smartreflex.c
 @@ -267,6 +267,7 @@ static int sr_late_init(struct omap_sr *sr_info)
   0, name, (void *)sr_info);
   if (ret)
   goto error;
 + disable_irq(sr_info-irq);
   }
  
   if (pdata  pdata-enable_on_init)
--
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 10/19] OMAP3+: SR: enable/disable SR only on need

2011-03-17 Thread Kevin Hilman

Nishanth Menon n...@ti.com writes:

 Since we already know the state of the autocomp enablement, we can
 see if the requested state is different from the current state and
 enable/disable SR only on the need basis.

 Signed-off-by: Nishanth Menon n...@ti.com

Thanks, queuing for 2.6.40.

Kevin

 ---
  arch/arm/mach-omap2/smartreflex.c |   11 +++
  1 files changed, 7 insertions(+), 4 deletions(-)

 diff --git a/arch/arm/mach-omap2/smartreflex.c 
 b/arch/arm/mach-omap2/smartreflex.c
 index f9057ad..2b6fdc7 100644
 --- a/arch/arm/mach-omap2/smartreflex.c
 +++ b/arch/arm/mach-omap2/smartreflex.c
 @@ -806,10 +806,13 @@ static int omap_sr_autocomp_store(void *data, u64 val)
   return -EINVAL;
   }
  
 - if (!val)
 - sr_stop_vddautocomp(sr_info);
 - else
 - sr_start_vddautocomp(sr_info);
 + /* control enable/disable only if there is a delta in value */
 + if (sr_info-autocomp_active != val) {
 + if (!val)
 + sr_stop_vddautocomp(sr_info);
 + else
 + sr_start_vddautocomp(sr_info);
 + }
  
   return 0;
  }
--
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 11/19] OMAP3+: SR: fix cosmetic indentation

2011-03-17 Thread Kevin Hilman

Nishanth Menon n...@ti.com writes:

 Error label case seems to have a 2 tab indentation when just 1 is
 necessary.

 Signed-off-by: Nishanth Menon n...@ti.com

Thanks, queuing for 2.6.40.

Kevin

 ---
  arch/arm/mach-omap2/smartreflex.c |   20 ++--
  1 files changed, 10 insertions(+), 10 deletions(-)

 diff --git a/arch/arm/mach-omap2/smartreflex.c 
 b/arch/arm/mach-omap2/smartreflex.c
 index 2b6fdc7..1e52d61 100644
 --- a/arch/arm/mach-omap2/smartreflex.c
 +++ b/arch/arm/mach-omap2/smartreflex.c
 @@ -276,16 +276,16 @@ static int sr_late_init(struct omap_sr *sr_info)
   return ret;
  
  error:
 - iounmap(sr_info-base);
 - mem = platform_get_resource(sr_info-pdev, IORESOURCE_MEM, 0);
 - release_mem_region(mem-start, resource_size(mem));
 - list_del(sr_info-node);
 - dev_err(sr_info-pdev-dev, %s: ERROR in registering
 - interrupt handler. Smartreflex will
 - not function as desired\n, __func__);
 - kfree(name);
 - kfree(sr_info);
 - return ret;
 + iounmap(sr_info-base);
 + mem = platform_get_resource(sr_info-pdev, IORESOURCE_MEM, 0);
 + release_mem_region(mem-start, resource_size(mem));
 + list_del(sr_info-node);
 + dev_err(sr_info-pdev-dev, %s: ERROR in registering
 + interrupt handler. Smartreflex will
 + not function as desired\n, __func__);
 + kfree(name);
 + kfree(sr_info);
 + return ret;
  }
  
  static void sr_v1_disable(struct omap_sr *sr)
--
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 12/19] OMAP3+: SR: introduce class start,stop and priv data

2011-03-17 Thread Kevin Hilman

Nishanth Menon n...@ti.com writes:

 Certain class drivers such as class 1.5 drivers, will need specific
 notification that they have to be started up or stopped independent
 of smart reflex operation. They also may need private data to be
 used for operations of their own, provide the same.
 This allows the class driver to initialize it's internal data structures
 on a need basis in preparation for the specific domain's autocomp usage.
 The resultant operation is as follows:
 when autocomp is set to 1 - class drivers' start is called
 The existing enable/disable is still used as before by the SmartReflex
 core driver to enable disable the class operation.
 When autocomp is set to 0 - class drivers' stop is called, signaling
 the end of usage for that domain.

 Signed-off-by: Nishanth Menon n...@ti.com

Please also fixup the comments and printks to use the start/stop
terminology instead of the init/deinit terminology.

Thanks,

Kevin

 ---
  arch/arm/mach-omap2/smartreflex.c |   14 ++
  arch/arm/mach-omap2/smartreflex.h |6 ++
  2 files changed, 20 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/smartreflex.c 
 b/arch/arm/mach-omap2/smartreflex.c
 index 1e52d61..592e9a0 100644
 --- a/arch/arm/mach-omap2/smartreflex.c
 +++ b/arch/arm/mach-omap2/smartreflex.c
 @@ -220,6 +220,13 @@ static void sr_start_vddautocomp(struct omap_sr *sr)
   return;
   }
  
 + if (sr_class-start 
 + sr_class-start(sr-voltdm, sr_class-class_priv_data)) {
 + dev_err(sr-pdev-dev,
 + %s: SRClass initialization failed\n, __func__);
 + return;
 + }
 +
   if (!sr_class-enable(sr-voltdm))
   sr-autocomp_active = true;
  }
 @@ -235,6 +242,13 @@ static void sr_stop_vddautocomp(struct omap_sr *sr)
  
   if (sr-autocomp_active) {
   sr_class-disable(sr-voltdm, 1);
 + if (sr_class-stop 
 + sr_class-stop(sr-voltdm,
 + sr_class-class_priv_data)) {
 + dev_err(sr-pdev-dev,
 + %s: SR[%d]Class deinitialization failed\n,
 + __func__, sr-srid);
 + }
   sr-autocomp_active = false;
   }
  }
 diff --git a/arch/arm/mach-omap2/smartreflex.h 
 b/arch/arm/mach-omap2/smartreflex.h
 index 5f35b9e..d4b8bee 100644
 --- a/arch/arm/mach-omap2/smartreflex.h
 +++ b/arch/arm/mach-omap2/smartreflex.h
 @@ -168,6 +168,8 @@ struct omap_sr_pmic_data {
   *
   * @enable:  API to enable a particular class smaartreflex.
   * @disable: API to disable a particular class smartreflex.
 + * @start:   API to do class specific initialization (optional)
 + * @stop:API to do class specific deinitialization (optional)
   * @configure:   API to configure a particular class smartreflex.
   * @notify:  API to notify the class driver about an event in SR.
   *   Not needed for class3.
 @@ -175,14 +177,18 @@ struct omap_sr_pmic_data {
   * @class_type:  specify which smartreflex class.
   *   Can be used by the SR driver to take any class
   *   based decisions.
 + * @class_priv_data: Class specific private data (optional)
   */
  struct omap_sr_class_data {
   int (*enable)(struct voltagedomain *voltdm);
   int (*disable)(struct voltagedomain *voltdm, int is_volt_reset);
 + int (*start)(struct voltagedomain *voltdm, void *class_priv_data);
 + int (*stop)(struct voltagedomain *voltdm, void *class_priv_data);
   int (*configure)(struct voltagedomain *voltdm);
   int (*notify)(struct voltagedomain *voltdm, u32 status);
   u8 notify_flags;
   u8 class_type;
 + void *class_priv_data;
  };
  
  /**
--
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 13/19] OMAP3+: SR: Reuse sr_[start|stop]_vddautocomp functions

2011-03-17 Thread Kevin Hilman

Nishanth Menon n...@ti.com writes:

 From: Jarkko Nikula jhnik...@gmail.com

 sr_start_vddautocomp and sr_stop_autocomp functions can be reused from
 omap_sr_enable, omap_sr_disable and omap_sr_disable_reset_volt and by
 adding one additional argument sr_stop_autocomp. This allows us to have
 a single point where SR enable and disable operations are controlled from.

 [n...@ti.com: synced it up with class start/stop as well. autocomp flag
  should only be disabled when SR is disabled for that domain]
 Signed-off-by: Nishanth Menon n...@ti.com
 Signed-off-by: Jarkko Nikula jhnik...@gmail.com
 ---
 Side note: Jarkko has'nt seen this rev as I just finished the rebase and 
 tested
 but adding his signed-off anyways as he is primary contributor to the idea
 and the patch.

This one looks fine, but will wait to apply it since it depends on the
previous one which needs some minor fixups.

Kevin

  arch/arm/mach-omap2/smartreflex.c |   66 
 +
  1 files changed, 23 insertions(+), 43 deletions(-)

 diff --git a/arch/arm/mach-omap2/smartreflex.c 
 b/arch/arm/mach-omap2/smartreflex.c
 index 592e9a0..d839fa6 100644
 --- a/arch/arm/mach-omap2/smartreflex.c
 +++ b/arch/arm/mach-omap2/smartreflex.c
 @@ -211,8 +211,12 @@ static void sr_set_regfields(struct omap_sr *sr)
   }
  }
  
 -static void sr_start_vddautocomp(struct omap_sr *sr)
 +static void sr_start_vddautocomp(struct omap_sr *sr, bool class_start)
  {
 + int r;
 + if (sr-autocomp_active)
 + return;
 +
   if (!sr_class || !(sr_class-enable) || !(sr_class-configure)) {
   dev_warn(sr-pdev-dev,
   %s: smartreflex class driver not registered\n,
 @@ -220,19 +224,24 @@ static void sr_start_vddautocomp(struct omap_sr *sr)
   return;
   }
  
 - if (sr_class-start 
 + if (class_start  sr_class-start 
   sr_class-start(sr-voltdm, sr_class-class_priv_data)) {
   dev_err(sr-pdev-dev,
   %s: SRClass initialization failed\n, __func__);
   return;
   }
  
 - if (!sr_class-enable(sr-voltdm))
 + r = sr_class-enable(sr-voltdm);
 + if (!r  class_start)
   sr-autocomp_active = true;
  }
  
 -static void sr_stop_vddautocomp(struct omap_sr *sr)
 +static void sr_stop_vddautocomp(struct omap_sr *sr, bool class_stop,
 + int is_volt_reset)
  {
 + if (!sr-autocomp_active)
 + return;
 +
   if (!sr_class || !(sr_class-disable)) {
   dev_warn(sr-pdev-dev,
   %s: smartreflex class driver not registered\n,
 @@ -240,15 +249,13 @@ static void sr_stop_vddautocomp(struct omap_sr *sr)
   return;
   }
  
 - if (sr-autocomp_active) {
 - sr_class-disable(sr-voltdm, 1);
 + sr_class-disable(sr-voltdm, is_volt_reset);
 + if (class_stop) {
   if (sr_class-stop 
 - sr_class-stop(sr-voltdm,
 - sr_class-class_priv_data)) {
 + sr_class-stop(sr-voltdm, sr_class-class_priv_data))
   dev_err(sr-pdev-dev,
   %s: SR[%d]Class deinitialization failed\n,
   __func__, sr-srid);
 - }
   sr-autocomp_active = false;
   }
  }
 @@ -285,7 +292,7 @@ static int sr_late_init(struct omap_sr *sr_info)
   }
  
   if (pdata  pdata-enable_on_init)
 - sr_start_vddautocomp(sr_info);
 + sr_start_vddautocomp(sr_info, true);
  
   return ret;
  
 @@ -693,16 +700,7 @@ void omap_sr_enable(struct voltagedomain *voltdm)
   return;
   }
  
 - if (!sr-autocomp_active)
 - return;
 -
 - if (!sr_class || !(sr_class-enable) || !(sr_class-configure)) {
 - dev_warn(sr-pdev-dev, %s: smartreflex class driver not
 - registered\n, __func__);
 - return;
 - }
 -
 - sr_class-enable(voltdm);
 + sr_start_vddautocomp(sr, false);
  }
  
  /**
 @@ -726,16 +724,7 @@ void omap_sr_disable(struct voltagedomain *voltdm)
   return;
   }
  
 - if (!sr-autocomp_active)
 - return;
 -
 - if (!sr_class || !(sr_class-disable)) {
 - dev_warn(sr-pdev-dev, %s: smartreflex class driver not
 - registered\n, __func__);
 - return;
 - }
 -
 - sr_class-disable(voltdm, 0);
 + sr_stop_vddautocomp(sr, false, 0);
  }
  
  /**
 @@ -759,16 +748,7 @@ void omap_sr_disable_reset_volt(struct voltagedomain 
 *voltdm)
   return;
   }
  
 - if (!sr-autocomp_active)
 - return;
 -
 - if (!sr_class || !(sr_class-disable)) {
 - dev_warn(sr-pdev-dev, %s: smartreflex class driver not
 - registered\n, __func__);
 - return;
 - }
 -
 - sr_class-disable(voltdm, 1);
 + sr_stop_vddautocomp(sr, false, 1);
  }
  
  /**
 @@ -823,9

Re: [PATCH V3 14/19] OMAP3+: SR: introduce notifiers flags

2011-03-17 Thread Kevin Hilman

Nishanth Menon n...@ti.com writes:

 SmartReflex IP V1 and V2 have different registers and offsets.
 Currently, we pass the status as is to the class driver. However,
 since we don't pass the version of the underlying SR hardware
 to the Class driver, it will not be unable to make consistent
 sense of the status bits coming over to it.

 A class driver should be able to function without dependency
 on the exact IP version it is actually running on. We hence
 introduce our own translation in software level for a generic
 notification flag.

 As part of this change, we will now call the notifier iff we get
 a match with the notifier flags that the class driver requested.

 Signed-off-by: Nishanth Menon n...@ti.com

Patch is mostly fine, minor coding style comments below.

Kevin

 ---
  arch/arm/mach-omap2/smartreflex.c |   73 
 +++--
  arch/arm/mach-omap2/smartreflex.h |6 +++
  2 files changed, 76 insertions(+), 3 deletions(-)

 diff --git a/arch/arm/mach-omap2/smartreflex.c 
 b/arch/arm/mach-omap2/smartreflex.c
 index d839fa6..21944e2 100644
 --- a/arch/arm/mach-omap2/smartreflex.c
 +++ b/arch/arm/mach-omap2/smartreflex.c
 @@ -123,27 +123,94 @@ static struct omap_sr *_sr_lookup(struct voltagedomain 
 *voltdm)
   return ERR_PTR(-ENODATA);
  }
  
 +static inline u32 notifier_to_irqen_v1(u8 notify_flags)
 +{
 + u32 val;

insert blank line

 + val = (notify_flags  SR_NOTIFY_MCUACCUM) ?
 + ERRCONFIG_MCUACCUMINTEN : 0;
 + val |= (notify_flags  SR_NOTIFY_MCUVALID) ?
 + ERRCONFIG_MCUVALIDINTEN : 0;
 + val |= (notify_flags  SR_NOTIFY_MCUBOUND) ?
 + ERRCONFIG_MCUBOUNDINTEN : 0;
 + val |= (notify_flags  SR_NOTIFY_MCUDISACK) ?
 + ERRCONFIG_MCUDISACKINTEN : 0;

insert blank line

same for all tehe functions below

 + return val;
 +}
 +
 +static inline u32 notifier_to_irqen_v2(u8 notify_flags)
 +{
 + u32 val;
 + val = (notify_flags  SR_NOTIFY_MCUACCUM) ?
 + IRQENABLE_MCUACCUMINT : 0;
 + val |= (notify_flags  SR_NOTIFY_MCUVALID) ?
 + IRQENABLE_MCUVALIDINT : 0;
 + val |= (notify_flags  SR_NOTIFY_MCUBOUND) ?
 + IRQENABLE_MCUBOUNDSINT : 0;
 + val |= (notify_flags  SR_NOTIFY_MCUDISACK) ?
 + IRQENABLE_MCUDISABLEACKINT : 0;
 + return val;
 +}
 +
 +static inline u8 irqstat_to_notifier_v1(u32 status)
 +{
 + u8 val;
 + val = (status  ERRCONFIG_MCUACCUMINTST) ?
 + SR_NOTIFY_MCUACCUM : 0;
 + val |= (status  ERRCONFIG_MCUVALIDINTEN) ?
 + SR_NOTIFY_MCUVALID : 0;
 + val |= (status  ERRCONFIG_MCUBOUNDINTEN) ?
 + SR_NOTIFY_MCUBOUND : 0;
 + val |= (status  ERRCONFIG_MCUDISACKINTEN) ?
 + SR_NOTIFY_MCUDISACK : 0;
 + return val;
 +}
 +
 +static inline u8 irqstat_to_notifier_v2(u32 status)
 +{
 + u8 val;
 + val = (status  IRQENABLE_MCUACCUMINT) ?
 + SR_NOTIFY_MCUACCUM : 0;
 + val |= (status  IRQENABLE_MCUVALIDINT) ?
 + SR_NOTIFY_MCUVALID : 0;
 + val |= (status  IRQENABLE_MCUBOUNDSINT) ?
 + SR_NOTIFY_MCUBOUND : 0;
 + val |= (status  IRQENABLE_MCUDISABLEACKINT) ?
 + SR_NOTIFY_MCUDISACK : 0;
 + return val;
 +}
 +
 +
  static irqreturn_t sr_interrupt(int irq, void *data)
  {
   struct omap_sr *sr_info = (struct omap_sr *)data;
   u32 status = 0;
 + u32 value = 0;
  
   if (sr_info-ip_type == SR_TYPE_V1) {
 + /* Status bits are one bit before enable bits in v1 */
 + value = notifier_to_irqen_v1(sr_class-notify_flags)  1;
 +
   /* Read the status bits */
   status = sr_read_reg(sr_info, ERRCONFIG_V1);
 + status = value;
  
   /* Clear them by writing back */
 - sr_write_reg(sr_info, ERRCONFIG_V1, status);
 + sr_modify_reg(sr_info, ERRCONFIG_V1, value, status);
 +
 + value = irqstat_to_notifier_v1(status);
   } else if (sr_info-ip_type == SR_TYPE_V2) {
 + value = notifier_to_irqen_v2(sr_class-notify_flags);
   /* Read the status bits */
 - sr_read_reg(sr_info, IRQSTATUS);
 + status = sr_read_reg(sr_info, IRQSTATUS);
 + status = value;
  
   /* Clear them by writing back */
   sr_write_reg(sr_info, IRQSTATUS, status);
 + value = irqstat_to_notifier_v2(status);
   }
  
   if (sr_class-notify)
 - sr_class-notify(sr_info-voltdm, status);
 + sr_class-notify(sr_info-voltdm, value);
  
   return IRQ_HANDLED;
  }
 diff --git a/arch/arm/mach-omap2/smartreflex.h 
 b/arch/arm/mach-omap2/smartreflex.h
 index d4b8bee..2976bf6 100644
 --- a/arch/arm/mach-omap2/smartreflex.h
 +++ b/arch/arm/mach-omap2/smartreflex.h
 @@ -142,6 +142,12 @@
  #define OMAP3430_SR_ERRWEIGHT0x04
  #define OMAP3430_SR_ERRMAXLIMIT  0x02
  
 +/* Smart reflex notifiers for class drivers

Re: [PATCH V3 15/19] OMAP3+: SR: introduce notifier_control

2011-03-17 Thread Kevin Hilman

Nishanth Menon n...@ti.com writes:

 We need some mechanism from class drivers to control when notifiers
 should be triggered and when not, currently we have none, which makes
 Class driver usage of the interrupt events almost impossible.

 Introduce an SmartReflex driver API for doing the same. This is useful
 for SmartReflex AVS class 1.5 or 2 drivers.

 Signed-off-by: Nishanth Menon n...@ti.com
 ---
  arch/arm/mach-omap2/smartreflex.c |   57 
 +
  arch/arm/mach-omap2/smartreflex.h |8 +
  2 files changed, 65 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/smartreflex.c 
 b/arch/arm/mach-omap2/smartreflex.c
 index 21944e2..f6e44a1 100644
 --- a/arch/arm/mach-omap2/smartreflex.c
 +++ b/arch/arm/mach-omap2/smartreflex.c
 @@ -712,6 +712,63 @@ void sr_disable(struct voltagedomain *voltdm)
  }
  
  /**
 + * sr_notifier_control() - control the notifier mechanism
 + * @voltdm:  VDD pointer to which the SR module to be configured belongs to.
 + * @enable:  true to enable notifiers and false to disable the same
 + *
 + * SR modules allow an MCU interrupt mechanism that vary based on the IP
 + * revision, we allow the system to generate interrupt if the class driver
 + * has capability to handle the same. it is upto the class driver to ensure
 + * the proper sequencing and handling for a clean implementation. returns
 + * 0 if all goes fine, else returns failure results
 + */
 +int sr_notifier_control(struct voltagedomain *voltdm, bool enable)
 +{
 + struct omap_sr *sr = _sr_lookup(voltdm);
 + u32 value = 0;

insert blank line

 + if (IS_ERR_OR_NULL(sr)) {

checking for NULL should suffice

 + pr_warning(%s: sr corresponding to domain not found\n,
 + __func__);
 + return -EINVAL;
 + }
 + if (!sr-autocomp_active)
 + return -EINVAL;
 +
 + /* if I could never register an isr, why bother?? */

s/isr/ISR/

 + if (!(sr_class  sr_class-notify  sr_class-notify_flags 
 + sr-irq)) {
 + dev_warn(sr-pdev-dev,
 + %s: unable to setup irq without handling mechanism\n,
 + __func__);

s/irq/IRQ/

 + return -EINVAL;
 + }
 +
 + switch (sr-ip_type) {
 + case SR_TYPE_V1:
 + value = notifier_to_irqen_v1(sr_class-notify_flags);
 + sr_modify_reg(sr, ERRCONFIG_V1, value,
 + (enable) ? value : 0);
 + break;
 + case SR_TYPE_V2:
 + value = notifier_to_irqen_v2(sr_class-notify_flags);
 + sr_write_reg(sr, (enable) ? IRQENABLE_SET : IRQENABLE_CLR,
 + value);
 + break;
 + default:
 +  dev_warn(sr-pdev-dev, %s: unknown type of sr??\n,
 +  __func__);
 + return -EINVAL;
 + }
 +
 + if (enable)
 + enable_irq(sr-irq);
 + else
 + disable_irq_nosync(sr-irq);
 +
 + return 0;
 +}

I'm not all that familiar with the SR IRQs, but why do you need to
disable them at the IP an at the INTC?  It seems like one of the two
should suffice, and it seems like the INTC would be the most efficient.

Kevin

 +/**
   * sr_register_class() - API to register a smartreflex class parameters.
   * @class_data:  The structure containing various sr class specific data.
   *
 diff --git a/arch/arm/mach-omap2/smartreflex.h 
 b/arch/arm/mach-omap2/smartreflex.h
 index 2976bf6..4a1ada4 100644
 --- a/arch/arm/mach-omap2/smartreflex.h
 +++ b/arch/arm/mach-omap2/smartreflex.h
 @@ -242,6 +242,7 @@ void omap_sr_register_pmic(struct omap_sr_pmic_data 
 *pmic_data);
  /* Smartreflex driver hooks to be called from Smartreflex class driver */
  int sr_enable(struct voltagedomain *voltdm, unsigned long volt);
  void sr_disable(struct voltagedomain *voltdm);
 +int sr_notifier_control(struct voltagedomain *voltdm, bool enable);
  int sr_configure_errgen(struct voltagedomain *voltdm);
  int sr_configure_minmax(struct voltagedomain *voltdm);
  
 @@ -250,6 +251,13 @@ int sr_register_class(struct omap_sr_class_data 
 *class_data);
  #else
  static inline void omap_sr_enable(struct voltagedomain *voltdm) {}
  static inline void omap_sr_disable(struct voltagedomain *voltdm) {}
 +
 +static inline int sr_notifier_control(struct voltagedomain *voltdm,
 + bool enable)
 +{
 + return -EINVAL;
 +}
 +
  static inline void omap_sr_disable_reset_volt(
   struct voltagedomain *voltdm) {}
  static inline void omap_sr_register_pmic(
--
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 17/19] OMAP3+: SR: make enable path use volt_data pointer

2011-03-17 Thread Kevin Hilman

Nishanth Menon n...@ti.com writes:

 Passing the volt_data pointers across allows us to save us the effort
 of looking up the voltage data pointer from the voltage value at
 multiple layers, we need to look at the voltage data in DVFS layer
 for further processing, so modify the APIs to pass the voltage data
 pointer all the way through to lower layers to the SmartReflex AVS class
 drivers.

 Signed-off-by: Nishanth Menon n...@ti.com

Isn't volt_data already reachable from voltdm?

I'd rather than clutter up the APIs with another argument, especially
one that should be derivable from the current one

Kevin

 ---
  arch/arm/mach-omap2/smartreflex-class3.c |   13 +++--
  arch/arm/mach-omap2/smartreflex.c|   22 ++
  arch/arm/mach-omap2/smartreflex.h|8 +---
  3 files changed, 18 insertions(+), 25 deletions(-)

 diff --git a/arch/arm/mach-omap2/smartreflex-class3.c 
 b/arch/arm/mach-omap2/smartreflex-class3.c
 index 2ee48af..1d3eb11 100644
 --- a/arch/arm/mach-omap2/smartreflex-class3.c
 +++ b/arch/arm/mach-omap2/smartreflex-class3.c
 @@ -13,19 +13,12 @@
  
  #include smartreflex.h
  
 -static int sr_class3_enable(struct voltagedomain *voltdm)
 +static int sr_class3_enable(struct voltagedomain *voltdm,
 + struct omap_volt_data *volt_data)
  {
 - unsigned long volt = omap_get_operation_voltage(
 - omap_voltage_get_nom_volt(voltdm));
 -
 - if (!volt) {
 - pr_warning(%s: Curr voltage unknown. Cannot enable sr_%s\n,
 - __func__, voltdm-name);
 - return -ENODATA;
 - }
  
   omap_vp_enable(voltdm);
 - return sr_enable(voltdm, volt);
 + return sr_enable(voltdm, volt_data);
  }
  
  static int sr_class3_disable(struct voltagedomain *voltdm, int is_volt_reset)
 diff --git a/arch/arm/mach-omap2/smartreflex.c 
 b/arch/arm/mach-omap2/smartreflex.c
 index b1a7cfe..5c549b9 100644
 --- a/arch/arm/mach-omap2/smartreflex.c
 +++ b/arch/arm/mach-omap2/smartreflex.c
 @@ -306,7 +306,7 @@ static void sr_start_vddautocomp(struct omap_sr *sr, bool 
 class_start)
   return;
   }
  
 - r = sr_class-enable(sr-voltdm);
 + r = sr_class-enable(sr-voltdm, omap_voltage_get_nom_volt(sr-voltdm));
   if (!r  class_start)
   sr-autocomp_active = true;
  }
 @@ -626,7 +626,7 @@ int sr_configure_minmax(struct voltagedomain *voltdm)
  /**
   * sr_enable() - Enables the smartreflex module.
   * @voltdm:  VDD pointer to which the SR module to be configured belongs to.
 - * @volt:The voltage at which the Voltage domain associated with
 + * @volt_data:   The voltage at which the Voltage domain associated with
   *   the smartreflex module is operating at.
   *   This is required only to program the correct Ntarget value.
   *
 @@ -634,10 +634,9 @@ int sr_configure_minmax(struct voltagedomain *voltdm)
   * enable a smartreflex module. Returns 0 on success. Returns error
   * value if the voltage passed is wrong or if ntarget value is wrong.
   */
 -int sr_enable(struct voltagedomain *voltdm, unsigned long volt)
 +int sr_enable(struct voltagedomain *voltdm, struct omap_volt_data *volt_data)
  {
   u32 nvalue_reciprocal;
 - struct omap_volt_data *volt_data;
   struct omap_sr *sr = _sr_lookup(voltdm);
   int ret;
  
 @@ -647,19 +646,16 @@ int sr_enable(struct voltagedomain *voltdm, unsigned 
 long volt)
   return -EINVAL;
   }
  
 - volt_data = omap_voltage_get_voltdata(sr-voltdm, volt);
 -
 - if (IS_ERR(volt_data)) {
 - dev_warn(sr-pdev-dev, %s: Unable to get voltage table
 - for nominal voltage %ld\n, __func__, volt);
 - return -ENODATA;
 + if (IS_ERR_OR_NULL(volt_data)) {
 + dev_warn(sr-pdev-dev, %s: bad voltage data\n, __func__);
 + return -EINVAL;
   }
  
   nvalue_reciprocal = sr_retrieve_nvalue(sr, volt_data-sr_efuse_offs);
  
   if (!nvalue_reciprocal) {
   dev_warn(sr-pdev-dev, %s: NVALUE = 0 at voltage %ld\n,
 - __func__, volt);
 + __func__, omap_get_operation_voltage(volt_data));
   return -ENODATA;
   }
  
 @@ -816,13 +812,15 @@ int sr_register_class(struct omap_sr_class_data 
 *class_data)
   * omap_sr_enable() -  API to enable SR clocks and to call into the
   *   registered smartreflex class enable API.
   * @voltdm:  VDD pointer to which the SR module to be configured belongs to.
 + * @volt_data:   Voltage data to go to
   *
   * This API is to be called from the kernel in order to enable
   * a particular smartreflex module. This API will do the initial
   * configurations to turn on the smartreflex module and in turn call
   * into the registered smartreflex class enable API.
   */
 -void omap_sr_enable(struct voltagedomain *voltdm)
 +void omap_sr_enable(struct voltagedomain *voltdm,
 + struct

[GIT PULL] omap changes for v2.6.39 merge window

2011-03-17 Thread Tony Lindgren

Hi Linus,

Please pull omap changes for this merge window from:

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

To summarize, this contains omap3 and 4 PM updates, new ti816x
processor support, changes many drivers to use common hwmod
platform code, thumb-2 changes, early init changes and a bunch
of clean-up patches.

Looks like there are again few minor merge conflicts that
git mergetool handles automatically except for the following
two conflicts.

I've also attached the relevant parts of the conflict resolution
patch to the end of this message, here's what's conflicting:

1. arch/arm/mach-omap2/usb-musb.c

In usb_musb_init, platform_device_register can be left out.

And the following part

if (cpu_is_omap44xx())
omap4430_phy_init(dev);

needs to be added towards the end of the function after
dev = pdev-dev is initialized so dev_err works properly
in omap4430_phy_init.

2. drivers/usb/musb/musb_core.h

In struct musb_context_registers the ifdef block is not needed
at all.

Regards,

Tony


The following changes since commit 521cb40b0c44418a4fd36dc633f575813d59a43d:

  Linux 2.6.38 (2011-03-14 18:20:32 -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

Aaro Koskinen (7):
  arm: plat-omap: dma: make omap_dma_in_1510_mode() static
  arm: mach-omap1: board-h2: make h2_nand_platdata static
  arm: mach-omap1: board-innovator: make innovator_mmc_init() static
  arm: mach-omap1: board-htcherald: make htcpld_chips and htcpld_pfdata 
static
  arm: mach-omap1: board-h3: make nand_platdata static
  arm: mach-omap1: board-voiceblue: add missing include
  arm: plat-omap: iommu: fix request_mem_region() error path

Abhilash Vadakkepat Koyamangalath (1):
  audio : AM3517 : Adding i2c info for AIC23 codec

Adrian Hunter (3):
  OMAP: OneNAND: fix 104MHz support
  OMAP: OneNAND: determine frequency in one place
  OMAP: OneNAND: let boards determine OneNAND frequency

Anand Gadiyar (4):
  arm: omap4: usb: explicitly configure MUSB pads
  arm: omap4: 4430sdp: drop ehci support
  omap: mmc: split out init for 2420
  OMAP4: hwmod data: enable HSMMC

Anand S Sawant (1):
  OMAP2+: smartreflex: remove SR debug directory in omap_sr_remove()

Andy Green (1):
  OMAP2+: Common CPU DIE ID reading code reads wrong registers for OMAP4430

Avinash.H.M (1):
  omap: hwmod: add syss reset done flags to omap2, omap3 hwmods

Balaji T K (2):
  OMAP4: Fix -EINVAL for vana, vcxio, vdac
  OMAP2: add regulator for MMC1

Benoit Cousson (15):
  OMAP4: hwmod data: Add hwspinlock
  OMAP4: hwmod data: Add McSPI
  OMAP4: hwmod data: Add timer
  OMAP4: hwmod data: Add DSS, DISPC, DSI12, RFBI, HDMI and VENC
  OMAP4: hwmod data: Add mailbox
  OMAP4: hwmod data: Add DMIC
  OMAP4: hwmod data: Add McBSP
  OMAP4: hwmod data: Add AESS, McPDM, bandgap, counter_32k, MMC, KBD, ISS  
IPU
  OMAP4: hwmod data: Add USBOTG
  OMAP4: hwmod data: Add rev and dev_attr fields in McSPI
  OMAP4: hwmod data: Prevent timer1 to be reset and idle during init
  omap4: clockdomain: Fix the CPUx domain name
  Revert OMAP4: hwmod data: Prevent timer1 to be reset and idle during 
init
  OMAP3: hwmod data: Fix incorrect SmartReflex - L4 CORE interconnect links
  OMAP3: hwmod data: Remove masters port links for interconnects.

Charulatha V (7):
  OMAP2420: hwmod data: Add McSPI
  OMAP2430: hwmod data: Add McSPI
  OMAP3: hwmod data: Add McSPI
  OMAP: devices: Modify McSPI device to adapt to hwmod framework
  OMAP2420: hwmod data: Add McBSP
  OMAP2430: hwmod data: Add McBSP
  OMAP3: hwmod data: Add McBSP

Dave Martin (5):
  ARM: omap4: Provide do_wfi() for Thumb-2
  ARM: omap4: Convert END() to ENDPROC() for correct linkage with 
CONFIG_THUMB2_KERNEL
  ARM: omap3: Remove hand-encoded SMC instructions
  ARM: omap3: Thumb-2 compatibility for sram34xx.S
  ARM: omap3: Thumb-2 compatibility for sleep34xx.S

David Cohen (5):
  omap: IOMMU: add missing function declaration
  omap: iommu: print module name on error messages
  OMAP2+: IOMMU: don't print fault warning on specific layer
  omap: IOMMU: add support to callback during fault handling
  omap: iovmm: don't check 'da' to set IOVMF_DA_FIXED flag

Eyal Reizer (2):
  omap3evm: add support for the WL12xx WLAN module to the AM/DM3xx 
Evaluation Module
  omap: omap3evm: add support for the WL12xx WLAN module to the omap3evm

Felipe Balbi (8):
  arm: omap: i2c: fix compile warning
  arm: omap1: fix compile warning
  arm: omap1: fix compile warnings
  arm: omap1: fix a bunch of section mismatches
  arm: omap2: irq: fix compile warning:
  arm: omap2: clksel: fix compile warningOrganization: Texas Instruments\n
  OMAP3: l3: Introduce l3-interconnect error

Re: [PATCH V3 18/19] OMAP3630+: SR: add support for class 1.5

2011-03-17 Thread Kevin Hilman

Nishanth Menon n...@ti.com writes:

 Traditional SmartReflex AVS(Automatic Voltage Scaling) classes are:
 * Class 0 - Product test calibration
   Silicon is calibration at production floor and fused with voltages
   for each OPP
 * Class 1 - Boot time calibration
   Silicon is calibrated once at boot time and voltages are stored for
   the lifetime of operation.
 * Class 2 - Continuous s/w calibration
   SR module notifies s/w for any change in the system which is desired
   and the s/w makes runtime decisions in terms of setting the voltage,
   this mechanism could be used in the system which does not have PMIC
   capable of SR without using the voltage controller and voltage
   processor blocks.
 * Class 3 - Continuous h/w calibration
   SR module is switch on after reaching a voltage level and SR
   continuously monitors the system and makes runtime adjustments without
   s/w involvement.

 OMAP3430 has used SmartReflex AVS and with a a PMIC which understands the SR
 protocol, Class 3 has been used. With OMAP3630 onwards, a new SmartReflex AVS
 class of operation Class 1.5 was introduced.
 * Class 1.5 - Periodic s/w calibration
   This uses the h/w calibration loop and at the end of calibration
   stores the voltages to be used run time, periodic recalibration is
   performed as well.

 The operational mode is describes as the following:
 * SmartReflex AVS h/w calibration loop is essential to identify the optimal
   voltage for a given OPP.
 * Once this optimal voltage is detected, SmartReflex AVS loop is disabled in
   class 1.5 mode of operation.
 * Until there is a need for a recalibration, any further transition to an OPP
   voltage which is calibrated can use the calibrated voltage and does not
   require enabling the SR AVS h/w loop.
 * On a periodic basis (recommendation being once approximately every 24 
 hours),
   software is expected to perform a recalibration to find a new optimal
   voltage which is compensated for device aging.
   - For performing this recalibration, the start voltage does not need to
   be the nominal voltage anymore. instead, the system can start with a
   voltage which is 50mV higher than the previously calibrated voltage to
   identify the new optimal voltage as the aging factor within a period of
   1 day is not going to be anywhere close to 50mV.
   - This new starting point for recalibration is called a dynamic
   nominal voltage for that voltage point.
 In short, with the introduction of SmartReflex class 1.5, there are three new
 voltages possible in a system's DVFS transition:
 * Nominal Voltage - The maximum voltage needed for a worst possible device
   in the worst possible conditions. This is the voltage we choose as
   the starting point for the h/w loop to optimize for the first time
   calibration on system bootup.
 * Dynamic Nominal Voltage - Worst case voltage for a specific device in
   considering the system aging on the worst process device.
 * Calibrated Voltage - Best voltage for the current device at a given point
   of time.

 In terms of the implementation, doing calibration involves waiting for the
 SmartReflex h/w loop to settle down, and doing this as part of the DVFS flow
 itself is to increase the latency of DVFS transition when there is a need to
 calibrate that opp. instead, the calibration is performed out of path using
 a workqueue statemachine. The workqueue waits for the system stabilization,
 then enables VP interrupts to monitor for system instability interms of 
 voltage
 oscillations that are reported back to the system as interrupts, in case of
 prolonged system oscillations, nominal voltage is chosen as a safe voltage and
 this event is logged in the system log for developer debug and fixing.

 For the recalibration, a common workqueue for all domains is started at the
 start of the class initialization and it resets the calibrated voltages
 on a periodic basis. For distros that may choose not to do the recommended
 periodic recalibration, instead choose to perform boot time calibration,
 kconfig configuration option is provided to do so.

 TODO:
 a) Cpuidle and suspend paths are not integrated with SmartReflex driver at
this point.
 b) Since the SR registers are accessed and controlled in parallel to DVFS
some sort of mechanism is necessary to be introduced along with OMAP
DVFS layer to ensure mutual exclusivity
 c) Additional debug interfaces for vmin analysis for platform characterization
and addition of system margin needs to be introduced from SmartReflex
perspective.

 This implementation also includes the following contributors:
 Tony Lindgren for suggestion on using interrupt based mechanism instead of
 polling to detect voltage oscillations.
 Peter 'p2' De Schrijver for debating alternatives on recalibration mechanisms
 Paul Walmsey, Eduardo Valentin, Ambresh K, Igor

Re: [PATCH V3 11/19] OMAP3+: SR: fix cosmetic indentation

2011-03-17 Thread Kevin Hilman

Aaro Koskinen aaro.koski...@nokia.com writes:

 Hi,

 On Thu, 17 Mar 2011, Kevin Hilman wrote:

 Thanks, queuing for 2.6.40.

 [...]

 -   iounmap(sr_info-base);
 -   mem = platform_get_resource(sr_info-pdev, IORESOURCE_MEM, 0);
 -   release_mem_region(mem-start, resource_size(mem));
 -   list_del(sr_info-node);
 -   dev_err(sr_info-pdev-dev, %s: ERROR in registering
 -   interrupt handler. Smartreflex will
 -   not function as desired\n, __func__);
 -   kfree(name);
 -   kfree(sr_info);
 -   return ret;
 +   iounmap(sr_info-base);
 +   mem = platform_get_resource(sr_info-pdev, IORESOURCE_MEM, 0);
 +   release_mem_region(mem-start, resource_size(mem));
 +   list_del(sr_info-node);
 +   dev_err(sr_info-pdev-dev, %s: ERROR in registering
 +   interrupt handler. Smartreflex will
 +   not function as desired\n, __func__);
 +   kfree(name);
 +   kfree(sr_info);
 +   return ret;

 Just FYI, this code is partly broken and probably need to be fixed in .39.

OK

 Some of those resources are also freed by omap_sr_probe() when
 sr_late_init() fails and that cannot be correct.

Got a patch around to fix that?  Sounds like something we should get
into the .39-rc cycle.

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 1/2] omap3: voltage: remove unnecessary param passing

2011-03-17 Thread Kevin Hilman

Sanjeev Premi pr...@ti.com writes:

 It is not necessary to pass the params prm_mod and
 prm_irqst_mod to omap_voltage_early_init().

 Signed-off-by: Sanjeev Premi pr...@ti.com

Hi Sanjeev,

I also started working on cleaning some of this up, but I took a
slightly different approach[1], namely I make these offsets part of the
VDD structure so that this data stays in the data files.

I'm still working on the series, but the work-in-progress is in my
pm-wip/voltdm branch, which I expect to post for comment tomorrow.

Kevin

[1] 
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=commit;h=185cdf40ad978a466106b52fce9b68ca7081f358
[2] 
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=shortlog;h=refs/heads/pm-wip/voltdm

 ---
  arch/arm/mach-omap2/voltage.c |   18 ++
  arch/arm/mach-omap2/voltage.h |3 +--
  arch/arm/mach-omap2/voltagedomains3xxx_data.c |5 +
  arch/arm/mach-omap2/voltagedomains44xx_data.c |6 +-
  4 files changed, 17 insertions(+), 15 deletions(-)

 diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
 index c6facf7..ce3098a 100644
 --- a/arch/arm/mach-omap2/voltage.c
 +++ b/arch/arm/mach-omap2/voltage.c
 @@ -1096,12 +1096,22 @@ int __init omap_voltage_late_init(void)
  }
  
  /* XXX document */
 -int __init omap_voltage_early_init(s16 prm_mod, s16 prm_irqst_ocp_mod,
 -struct omap_vdd_info *omap_vdd_array[],
 +int __init omap_voltage_early_init(struct omap_vdd_info *omap_vdd_array[],
  u8 omap_vdd_count)
  {
 - prm_mod_offs = prm_mod;
 - prm_irqst_ocp_mod_offs = prm_irqst_ocp_mod;
 + if (cpu_is_omap44xx()) {
 + prm_mod_offs = OMAP4430_PRM_DEVICE_INST;
 + prm_irqst_ocp_mod_offs = OMAP4430_PRM_OCP_SOCKET_INST;
 + } else if (cpu_is_omap34xx()) {
 + prm_mod_offs = OMAP3430_GR_MOD;
 + prm_irqst_ocp_mod_offs = OCP_MOD;
 + } else {
 + /* TODO:
 +  * What should be done for OMAP24xx?
 +  * Would we even reach here?
 +  */
 + }
 +
   vdd_info = omap_vdd_array;
   nr_scalable_vdd = omap_vdd_count;
   return 0;
 diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
 index e9f5408..b56530e 100644
 --- a/arch/arm/mach-omap2/voltage.h
 +++ b/arch/arm/mach-omap2/voltage.h
 @@ -151,8 +151,7 @@ struct omap_volt_data *omap_voltage_get_voltdata(struct 
 voltagedomain *voltdm,
   unsigned long volt);
  unsigned long omap_voltage_get_nom_volt(struct voltagedomain *voltdm);
  struct dentry *omap_voltage_get_dbgdir(struct voltagedomain *voltdm);
 -int __init omap_voltage_early_init(s16 prm_mod, s16 prm_irqst_mod,
 -struct omap_vdd_info *omap_vdd_array[],
 +int __init omap_voltage_early_init(struct omap_vdd_info *omap_vdd_array[],
  u8 omap_vdd_count);
  #ifdef CONFIG_PM
  int omap_voltage_register_pmic(struct voltagedomain *voltdm,
 diff --git a/arch/arm/mach-omap2/voltagedomains3xxx_data.c 
 b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
 index def230f..6f6999d 100644
 --- a/arch/arm/mach-omap2/voltagedomains3xxx_data.c
 +++ b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
 @@ -70,8 +70,6 @@ static struct omap_vdd_info *omap3_vdd_info[] = {
  /* OMAP3 specific voltage init functions */
  static int __init omap3xxx_voltage_early_init(void)
  {
 - s16 prm_mod = OMAP3430_GR_MOD;
 - s16 prm_irqst_ocp_mod = OCP_MOD;
  
   if (!cpu_is_omap34xx())
   return 0;
 @@ -88,8 +86,7 @@ static int __init omap3xxx_voltage_early_init(void)
   omap3_vdd2_info.volt_data = omap34xx_vddcore_volt_data;
   }
  
 - return omap_voltage_early_init(prm_mod, prm_irqst_ocp_mod,
 -omap3_vdd_info,
 + return omap_voltage_early_init(omap3_vdd_info,
  ARRAY_SIZE(omap3_vdd_info));
  };
  core_initcall(omap3xxx_voltage_early_init);
 diff --git a/arch/arm/mach-omap2/voltagedomains44xx_data.c 
 b/arch/arm/mach-omap2/voltagedomains44xx_data.c
 index cb64996..208a67d 100644
 --- a/arch/arm/mach-omap2/voltagedomains44xx_data.c
 +++ b/arch/arm/mach-omap2/voltagedomains44xx_data.c
 @@ -81,9 +81,6 @@ static struct omap_vdd_info *omap4_vdd_info[] = {
  /* OMAP4 specific voltage init functions */
  static int __init omap44xx_voltage_early_init(void)
  {
 - s16 prm_mod = OMAP4430_PRM_DEVICE_INST;
 - s16 prm_irqst_ocp_mod = OMAP4430_PRM_OCP_SOCKET_INST;
 -
   if (!cpu_is_omap44xx())
   return 0;
  
 @@ -95,8 +92,7 @@ static int __init omap44xx_voltage_early_init(void)
   omap4_vdd_iva_info.volt_data = omap44xx_vdd_iva_volt_data;
   omap4_vdd_core_info.volt_data = omap44xx_vdd_core_volt_data;
  
 - return omap_voltage_early_init(prm_mod, prm_irqst_ocp_mod,
 -

Re: [PATCH 2/2] omap3: voltage: fix variable type and name

2011-03-17 Thread Kevin Hilman

Sanjeev Premi pr...@ti.com writes:

 In all usages, variables prm_mod_offs and prm_irqst_ocp_mod_offs
 are expected to be u16 but have been declared as s16.

What kind of problem is that causing?

Kevin

 In addition, renamed prm_irqst_ocp_mod_offs to ocp_sysreg_prm_offs
 for better association with the TRM. Original name perhaps came
 from the current usage of this offset to reach PRM_IRQSTATUS_MPU
 offset.

 Signed-off-by: Sanjeev Premi pr...@ti.com
 ---
  arch/arm/mach-omap2/voltage.c |   18 +-
  1 files changed, 9 insertions(+), 9 deletions(-)

 diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
 index ce3098a..c686eca 100644
 --- a/arch/arm/mach-omap2/voltage.c
 +++ b/arch/arm/mach-omap2/voltage.c
 @@ -51,8 +51,8 @@ static struct omap_vdd_info **vdd_info;
  static int nr_scalable_vdd;
  
  /* XXX document */
 -static s16 prm_mod_offs;
 -static s16 prm_irqst_ocp_mod_offs;
 +static u16 prm_mod_offs;
 +static u16 ocp_sysreg_prm_offs;
  
  static struct dentry *voltage_dir;
  
 @@ -447,8 +447,8 @@ static int vp_forceupdate_scale_voltage(struct 
 omap_vdd_info *vdd,
*/
   while (timeout++  VP_TRANXDONE_TIMEOUT) {
   vdd-write_reg(vdd-vp_data-prm_irqst_data-tranxdone_status,
 -prm_irqst_ocp_mod_offs, prm_irqst_reg);
 - if (!(vdd-read_reg(prm_irqst_ocp_mod_offs, prm_irqst_reg) 
 +ocp_sysreg_prm_offs, prm_irqst_reg);
 + if (!(vdd-read_reg(ocp_sysreg_prm_offs, prm_irqst_reg) 
 vdd-vp_data-prm_irqst_data-tranxdone_status))
   break;
   udelay(1);
 @@ -481,7 +481,7 @@ static int vp_forceupdate_scale_voltage(struct 
 omap_vdd_info *vdd,
* Depends on SMPSWAITTIMEMIN/MAX and voltage change
*/
   timeout = 0;
 - omap_test_timeout((vdd-read_reg(prm_irqst_ocp_mod_offs, prm_irqst_reg) 
 
 + omap_test_timeout((vdd-read_reg(ocp_sysreg_prm_offs, prm_irqst_reg) 
  vdd-vp_data-prm_irqst_data-tranxdone_status),
 VP_TRANXDONE_TIMEOUT, timeout);
   if (timeout = VP_TRANXDONE_TIMEOUT)
 @@ -498,8 +498,8 @@ static int vp_forceupdate_scale_voltage(struct 
 omap_vdd_info *vdd,
   timeout = 0;
   while (timeout++  VP_TRANXDONE_TIMEOUT) {
   vdd-write_reg(vdd-vp_data-prm_irqst_data-tranxdone_status,
 -prm_irqst_ocp_mod_offs, prm_irqst_reg);
 - if (!(vdd-read_reg(prm_irqst_ocp_mod_offs, prm_irqst_reg) 
 +ocp_sysreg_prm_offs, prm_irqst_reg);
 + if (!(vdd-read_reg(ocp_sysreg_prm_offs, prm_irqst_reg) 
 vdd-vp_data-prm_irqst_data-tranxdone_status))
   break;
   udelay(1);
 @@ -1101,10 +1101,10 @@ int __init omap_voltage_early_init(struct 
 omap_vdd_info *omap_vdd_array[],
  {
   if (cpu_is_omap44xx()) {
   prm_mod_offs = OMAP4430_PRM_DEVICE_INST;
 - prm_irqst_ocp_mod_offs = OMAP4430_PRM_OCP_SOCKET_INST;
 + ocp_sysreg_prm_offs = OMAP4430_PRM_OCP_SOCKET_INST;
   } else if (cpu_is_omap34xx()) {
   prm_mod_offs = OMAP3430_GR_MOD;
 - prm_irqst_ocp_mod_offs = OCP_MOD;
 + ocp_sysreg_prm_offs = OCP_MOD;
   } else {
   /* TODO:
* What should be done for OMAP24xx?
--
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: [RFCv2 2/2] AM35x: voltage: Basic initialization

2011-03-17 Thread Paul Walmsley

On Thu, 17 Mar 2011, Premi, Sanjeev wrote:

   The things, however, get stuck in HWMOD again when the parent of
 
 [sp] Being more specific:
  The parent here refers to parent vdd i.e. vdd_name.
 
 ~sanjeev
 
   omap3xxx_l3_main_hwmod is set as core. Changing this causes
   another cascade of changes leading to almost duplicating 
  the complete
   hwmod structure for AM35x.

There shouldn't be any vdd_name entries set in the hwmod data.  That 
struct omap_hwmod field will be removed.

Instead, voltage domain data should be associated with the powerdomain.  

Kevin has patches for some of this forthcoming.


- 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

Re: [PATCH v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4

2011-03-17 Thread Stephan Raue


Am 17.03.2011 17:20, schrieb Janorkar, Mayuresh:

Raue,


-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Valkeinen, Tomi
Sent: Thursday, March 17, 2011 4:41 PM
To: Stephan Raue
Cc: K, Mythri P; linux-omap@vger.kernel.org
Subject: Re: [PATCH v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4

Hi,

On Wed, 2011-03-16 at 18:49 -0500, Stephan Raue wrote:


i tried this test tree with omap2plus_defconfig.

it seems the kernel crashes and poweroff the board on loading this hdmi
stuff, but dont print any crashlog. is there a way any backtraces will
be printed?
output from serial console: http://paste.pocoo.org/show/354850/
kernel config (omap2plus_defconfig, added squashfs support, added
support to include initramfs in kernel, build omapfb stuff statically
into the kernel): http://paste.pocoo.org/show/354853/

Is it possible for you to enable low-level debugging and pass omapfb.debug=1 
omapdss.debug=1 in your bootargs?
This would show the Framebuffer and DSSDBG prints. We would get an idea if 
kernel is getting stuck in DSS/OMAPFB.

Let me know if you any help in enabling debug prints.

Also one more suggestion/ question, are you seeing a hang if DSS is not enabled 
in kernel?

-Thanks,
Mayuresh

i have done, there is not more output with enable low level debugging 
and passing this options... :-(


disabling DSS lets boot the kernel and start initramfs (see: 
http://paste.pocoo.org/show/355262/)



Have the HDMI on your setup worked in any (prebuilt) image? What I'm
asking is if you are sure the HDMI HW works on your board?
yes, prebuild ubuntu images based on TI's 2.6.35 kernel with hdmi 
support gives me output on my monitor.

Powering off quietly sounds strange. Is your power supply sufficient?
Well, I don't think that would explain the first crash you posted...
i have seen the board dont poweroff, i have also added LED support so 
the LED's begins to flash after kernel start. but only for a very short 
time until the kernel crashes. so i was thinking it does a power off, 
but the chips on the board are not cold even after some minutes/hours, 
so the board is powered on. The powersupply is the recommended 
powersupply from digikey, so its ok.

--
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 3/7] OMAP: PM CONSTRAINTS: implement wake-up latency constraints

2011-03-17 Thread Kevin Hilman

Jean Pihet jean.pi...@newoldbits.com writes:

 Implement the wake-up latency constraints using an internal
 unified function _set_dev_constraint at OMAP PM level,
 which calls the corresponding function at omap device level.

 The actual constraints management code is at the omap device level.

 Note: the bus throughput function is implemented but currently is
 a no-op.

 Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints
 on MPU, CORE and PER.

 Signed-off-by: Jean Pihet j-pi...@ti.com
 ---
  arch/arm/plat-omap/omap-pm-constraints.c |  174 
 --
  1 files changed, 91 insertions(+), 83 deletions(-)

 diff --git a/arch/arm/plat-omap/omap-pm-constraints.c 
 b/arch/arm/plat-omap/omap-pm-constraints.c
 index c8b4e4c..c6735da 100644
 --- a/arch/arm/plat-omap/omap-pm-constraints.c
 +++ b/arch/arm/plat-omap/omap-pm-constraints.c
 @@ -24,6 +24,7 @@
  /* Interface documentation is in mach/omap-pm.h */
  #include plat/omap-pm.h
  #include plat/omap_device.h
 +#include plat/common.h
  
  static bool off_mode_enabled;
  static u32 dummy_context_loss_counter;
 @@ -32,119 +33,126 @@ static u32 dummy_context_loss_counter;
   * Device-driver-originated constraints (via board-*.c files)
   */
  
 -int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t)
 +/*
 + * Generic function to omap_device layer for the constraints API.
 + */
 +static int _set_dev_constraint(enum omap_pm_constraint_class class,
 +struct device *req_dev, struct device *dev,
 +long t)
  {
 - if (!dev || t  -1) {
 + int ret = 0;
 +
 + if (!req_dev || !dev || t  -1) {
   WARN(1, OMAP PM: %s: invalid parameter(s), __func__);
   return -EINVAL;
 - };
 -
 - if (t == -1)
 - pr_debug(OMAP PM: remove max MPU wakeup latency constraint: 
 -  dev %s\n, dev_name(dev));
 - else
 - pr_debug(OMAP PM: add max MPU wakeup latency constraint: 
 -  dev %s, t = %ld usec\n, dev_name(dev), t);
 + }
  
 - /*
 -  * For current Linux, this needs to map the MPU to a
 -  * powerdomain, then go through the list of current max lat
 -  * constraints on the MPU and find the smallest.  If
 -  * the latency constraint has changed, the code should
 -  * recompute the state to enter for the next powerdomain
 -  * state.
 -  *
 -  * TI CDP code can call constraint_set here.
 -  */
 + /* Try to catch non omap_device for dev */

comment should be 'only valid for omap_devices'

 + if (dev-parent == omap_device_parent) {
 + if (t == -1)
 + pr_debug(OMAP PM: remove constraint of class %d 
 +  from req_dev %s on dev %s\n,
 +  class, dev_name(req_dev), dev_name(dev));
 + else
 + pr_debug(OMAP PM: add constraint of class %d 
 +  from req_dev %s on dev %s, t = %ld\n,
 +  class, dev_name(req_dev), dev_name(dev), t);
 +
 + /* Call the omap_device API */

comment not needed

 + ret = omap_device_set_dev_constraint(class, req_dev, dev, t);

Calling a function which doesn't yet exist. 

Patches should be ordered such that the kernel still compiles after each patch.

 + } else {
 + pr_err(OMAP-PM set_wakeup_lat: Error: platform device 
 +not valid\n);

comment should be 'Error: not an omap_device'.

 + return -EINVAL;
 + }
  
 - return 0;
 + return ret;
  }

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 v2 4/7] OMAP: PM CONSTRAINTS: implement the constraints management code

2011-03-17 Thread Kevin Hilman

Jean Pihet jean.pi...@newoldbits.com writes:

 The code at omap device level manages the constraints: storage,
 tracking of requesters and dispatching to the low level
 code (e.g. powerdomain for the wake-up latency constraints).

 Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints
 on MPU, CORE and PER.

 Signed-off-by: Jean Pihet j-pi...@ti.com

Subject prefix should be: OMAP2+: omap_device: ...

 ---
  arch/arm/plat-omap/include/plat/omap_device.h |   14 ++
  arch/arm/plat-omap/omap_device.c  |  202 
 +
  2 files changed, 216 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/plat-omap/include/plat/omap_device.h 
 b/arch/arm/plat-omap/include/plat/omap_device.h
 index e4c349f..d4766c4 100644
 --- a/arch/arm/plat-omap/include/plat/omap_device.h
 +++ b/arch/arm/plat-omap/include/plat/omap_device.h
 @@ -32,9 +32,11 @@
  #define __ARCH_ARM_PLAT_OMAP_INCLUDE_MACH_OMAP_DEVICE_H
  
  #include linux/kernel.h
 +#include linux/plist.h
  #include linux/platform_device.h
  
  #include plat/omap_hwmod.h
 +#include plat/omap-pm.h
  
  extern struct device omap_device_parent;
  
 @@ -73,6 +75,15 @@ struct omap_device {
   s8  pm_lat_level;
   u8  hwmods_cnt;
   u8  _state;
 +
 +};
 +
 +/* Linked list for the devices constraints entries */
 +struct omap_device_constraints_entry {
 + struct device   *req_dev;
 + void*target;
 + unsigned long   constraint_value;

constratint_ prefix not needed

Also, should this be 'long' (instead of unsigned long' to match the
value from the API below?

 + struct plist_node   node;
  };
  
  /* Device driver interface (call via platform_data fn ptrs) */
 @@ -107,6 +118,9 @@ void __iomem *omap_device_get_rt_va(struct omap_device 
 *od);
  int omap_device_align_pm_lat(struct platform_device *pdev,
u32 new_wakeup_lat_limit);
  struct powerdomain *omap_device_get_pwrdm(struct omap_device *od);
 +int omap_device_set_dev_constraint(enum omap_pm_constraint_class class,
 +struct device *req_dev,
 +struct device *dev, long t);
  u32 omap_device_get_context_loss_count(struct platform_device *pdev);
  
  /* Other */
 diff --git a/arch/arm/plat-omap/omap_device.c 
 b/arch/arm/plat-omap/omap_device.c
 index 9bbda9a..9199d3e 100644
 --- a/arch/arm/plat-omap/omap_device.c
 +++ b/arch/arm/plat-omap/omap_device.c
 @@ -292,10 +292,205 @@ static void _add_optional_clock_clkdev(struct 
 omap_device *od,
   }
  }
  
 +/* plist that stores the devices wake-up latency constraints */
 +static struct plist_head _wkup_lat_constraints_list;
 +/* Spinlock that protects the constraints lists */
 +static spinlock_t _constraints_lock;
 +/* Mutex that protects the constraints lists ops */
 +static struct mutex _constraints_mutex;
 +
 +/*
 + * _store_constraint: add/update/remove a constraint from a plist
 + *
 + * @constraints_list: plist to use
 + * @req_dev: constraint requester, used to track the requests
 + * @target: target which the constraint applies to (e.g. power domain ID or
 + *  ptr for wake-up latency constraints)
 + * @value: constraint value. The plist is sorted by the value. -1 remove the
 + *  constraint from the list
 + * @ascending: return the lowest constraint value if set to 1, return the
 + *  highest value if not.
 + *
 + * Returns the strongest constraint value for the given target, 0 in the
 + * case there is no constraint on the given target or a negative value in
 + * case of error.
 + * The caller must check the validity of the parameters.
 + */
 +static long _store_constraint(struct plist_head *constraints_list,
 +   struct device *req_dev, void *target,
 +   long value, int ascending)
 +{
 + struct omap_device_constraints_entry *user;
 + int found = 0, ret = 0;
 +
 + mutex_lock(_constraints_mutex);
 +
 + /* Check if the constraint requester is already in the list */
 + plist_for_each_entry(user, constraints_list, node) {
 + if (user-req_dev == req_dev) {
 + found = 1;
 + break;
 + }
 + }

You should probably release the mutex here so it's not held over the
kzalloc (which can sleep.)

Minor: I'm not a fan of this common 'found = 1' technique.  Rather, use
a temporary list iterator, e.g:

struct omap_device_constraints_entry *user = NULL, *tmp_user;

plist_for_each_entry(tmp_user, constraints_list, node) {
if (user-req_dev == req_dev) {
user = tmp_user;
break;
}
}

Then, rather than checking 'found' below, check 'user'.

 + if (value = 0) {
 + /* Add new entry to the list or update existing request */
 +

Re: [PATCH v2 5/7] OMAP: PM CONSTRAINTS: add a power domains state update function in hwmod

2011-03-17 Thread Kevin Hilman

Jean Pihet jean.pi...@newoldbits.com writes:

 Hwmod is queried from the omap device layer to change the power domains
 next power state. Hwmod retrieves the correct power domain and if it
 exists it calls the corresponding power domain function.

 Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints
 on MPU, CORE and PER.

 Signed-off-by: Jean Pihet j-pi...@ti.com

Subject prefix should be: OMAP2+: omap_hwmod: ...

 ---
  arch/arm/mach-omap2/omap_hwmod.c |   29 
 +-
  arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
  2 files changed, 29 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-omap2/omap_hwmod.c 
 b/arch/arm/mach-omap2/omap_hwmod.c
 index cf8cc9b..8caf2c5 100644
 --- a/arch/arm/mach-omap2/omap_hwmod.c
 +++ b/arch/arm/mach-omap2/omap_hwmod.c
 @@ -142,6 +142,7 @@
  #include powerdomain.h
  #include plat/clock.h
  #include plat/omap_hwmod.h
 +#include plat/omap_device.h
  #include plat/prcm.h
  
  #include cm2xxx_3xxx.h
 @@ -2277,11 +2278,37 @@ ohsps_unlock:
   return ret;
  }
  
 +/*
 + * omap_hwmod_update_power_state - Update the power domain power state of

I think 'set_next_power_state' is a better name for this function.

 + * @oh
 + *
 + * @oh: struct omap_hwmod* to which the requesting device belongs to.
 + * @min_latency: the allowed wake-up latency for the power domain of @oh.
 + *
 + * Finds the power domain next power state that fulfills the constraint.
 + * Applies the constraint to the power domain by calling
 + * pwrdm_wakeuplat_update_pwrst.

This needs to be updated as this function doesn't know anything about
constraints.

 + * Returns 0 upon success.
 + */
 +int omap_hwmod_update_power_state(struct omap_hwmod *oh, long min_latency)
 +{
 + struct powerdomain *pwrdm = omap_hwmod_get_pwrdm(oh);
 +
 + if (!PTR_ERR(pwrdm)) {
 + pr_err(omap_hwmod: Error: could not find parent 

s/parent//

instead of omap_hwmod:, use %s with __func__ so the function name is
printed on error.

 + powerdomain for %s\n, oh-name);
 + return -EINVAL;
 + }
 +
 + return pwrdm_wakeuplat_update_pwrst(pwrdm, min_latency);

Again, this function doesn't exist yet in the series.

 +}
 +
  /**
   * omap_hwmod_get_context_loss_count - get lost context count
   * @oh: struct omap_hwmod *
   *
 - * Query the powerdomain of of @oh to get the context loss
 + * Query the powerdomain of @oh to get the context loss
   * count for this device.
   *
   * Returns the context loss count of the powerdomain assocated with @oh
 diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h 
 b/arch/arm/plat-omap/include/plat/omap_hwmod.h
 index 65bcad4..f27110e 100644
 --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
 +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
 @@ -597,6 +597,7 @@ int omap_hwmod_for_each_by_class(const char *classname,
void *user);
  
  int omap_hwmod_set_postsetup_state(struct omap_hwmod *oh, u8 state);
 +int omap_hwmod_update_power_state(struct omap_hwmod *oh, long min_latency);
  u32 omap_hwmod_get_context_loss_count(struct omap_hwmod *oh);
  
  /*

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 v2 6/7] OMAP: PM CONSTRAINTS: control power domains next state

2011-03-17 Thread Kevin Hilman

Jean Pihet jean.pi...@newoldbits.com writes:

 When a wake-up constraint is requested or removed the omap device layer
 dispatches the updated strongest constraint value.
 The power domains get the next power state programmed directly in the
 registers via pwrdm_wakeuplat_update_pwrst.

 Note about PM QOS: the MPU and CORE power domains get the next power
 state via cpuidle, which get the strongest wake-up latency constraint
 by querying PM QOS. The usage of PM QOS is temporary, until a generic
 solution is in place.

 Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints
 on MPU, CORE and PER.

 Signed-off-by: Jean Pihet j-pi...@ti.com

Subject prefix should be: OMAP2+: powerdomain: ...

 ---
  arch/arm/mach-omap2/powerdomain.c |  100 
 +
  arch/arm/mach-omap2/powerdomain.h |   24 -
  2 files changed, 122 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/mach-omap2/powerdomain.c 
 b/arch/arm/mach-omap2/powerdomain.c
 index eaed0df..54ac955 100644
 --- a/arch/arm/mach-omap2/powerdomain.c
 +++ b/arch/arm/mach-omap2/powerdomain.c
 @@ -19,6 +19,7 @@
  #include linux/list.h
  #include linux/errno.h
  #include linux/string.h
 +
  #include cm2xxx_3xxx.h
  #include prcm44xx.h
  #include cm44xx.h
 @@ -176,6 +177,105 @@ static int _pwrdm_post_transition_cb(struct powerdomain 
 *pwrdm, void *unused)
   return 0;
  }
  
 +/*
 + * Test if the current powerdomain is MPU or CORE
 + *
 + * This function is only used by pwrdm_wakeuplat_update_pwrst
 + * which applies the MPU and CORE power domains constraints using PM QOS.
 + *
 + * This will disappear when all power domains will be controlled directly
 + * from the wake-up latency constraints framework
 + */
 +static inline int is_pwrdm_mpu_or_core(struct powerdomain *pwrdm)
 +{
 + if ((pwrdm == pwrdm_lookup(mpu_pwrdm)) ||
 + (pwrdm == pwrdm_lookup(core_pwrdm)))
 + return 1;
 + else
 + return 0;
 +}

I think Paul pointed this out in the earlier review, but instead of
doing this using string compare each time, set a flag in the powerdomain
at init time can be checked here with a simple check.

 +/**
 + * pwrdm_wakeuplat_update_pwrst - Update power domain power state if needed
 + * @pwrdm: struct powerdomain * to which requesting device belongs to.
 + * @min_latency: the allowed wake-up latency for the given power domain. A
 + *  value of 0 means 'no constraint' on the pwrdm.
 + *
 + * Finds the power domain next power state that fulfills the constraint.
 + * Programs a new target state if it is different from current power state.
 + *
 + * Returns 0 upon success.
 + */
 +int pwrdm_wakeuplat_update_pwrst(struct powerdomain *pwrdm, long min_latency)
 +{
 + int ret = 0, new_state = 0;
 +
 + if (!pwrdm) {
 + WARN(1, powerdomain: %s: invalid parameter(s), __func__);
 + return -EINVAL;
 + }
 +
 + /*
 +  * Apply constraints to MPU and CORE via the PM QOS API.
 +  * Every power domain struct has a pm_qos_request_list field
 +  */
 + if (is_pwrdm_mpu_or_core(pwrdm)) {
 + if (pm_qos_request_active((pwrdm-pm_qos_request)))
 + pm_qos_remove_request((pwrdm-pm_qos_request));
 +
 + if (min_latency  0)
 + pm_qos_add_request((pwrdm-pm_qos_request),
 +PM_QOS_CPU_DMA_LATENCY,
 +min_latency);
 +
 + return 0;
 + }
 +
 + /*
 +  * Apply constraints to pwrdm other than MPU and CORE by programming
 +  * the pwrdm next power state.
 +  */
 +
 + /* Find power state with wakeup latency  minimum constraint */
 + for (new_state = 0x0; new_state  PWRDM_MAX_PWRSTS; new_state++) {
 + if (min_latency == 0 ||
 + pwrdm-wakeup_lat[new_state] = min_latency)
 + break;
 + }
 +
 + switch (new_state) {
 + case PWRDM_FUNC_PWRST_OFF:
 + new_state = PWRDM_POWER_OFF;
 + break;
 + case PWRDM_FUNC_PWRST_OSWR:
 + pwrdm_set_logic_retst(pwrdm, PWRDM_POWER_OFF);
 + new_state = PWRDM_POWER_RET;
 + break;
 + case PWRDM_FUNC_PWRST_CSWR:
 + pwrdm_set_logic_retst(pwrdm, PWRDM_POWER_RET);
 + new_state = PWRDM_POWER_RET;
 + break;
 + case PWRDM_FUNC_PWRST_ON:
 + new_state = PWRDM_POWER_ON;
 + break;
 + default:
 + pr_warn(powerdomain: requested latency constraint not 
 + supported %s set to ON state\n, pwrdm-name);
 + new_state = PWRDM_POWER_ON;
 + break;
 + }
 +
 + if (pwrdm_read_pwrst(pwrdm) != new_state)
 + ret = omap_set_pwrdm_state(pwrdm, new_state);
 +
 + pr_debug(powerdomain: %s pwrst: curr=%d, prev=%d next=%d 
 +  min_latency=%ld, set_state=%d\n, pwrdm-name,
 +

Re: [PATCH v2 7/7] OMAP: PM CONSTRAINTS: add power domains wake-up latency figures

2011-03-17 Thread Kevin Hilman

Jean Pihet jean.pi...@newoldbits.com writes:

 Figures are added to the power domains structs.

 Note: the figures are preliminary figures. More accurate measurements
 are needed. Also the conditions of measurements shall be investigated
 and described.

 Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints
 on MPU, CORE and PER.

 Signed-off-by: Jean Pihet j-pi...@ti.com

Subject should be: OMAP3: powerdomain data: ...

 ---
  arch/arm/mach-omap2/powerdomains3xxx_data.c |   63 
 +++
  1 files changed, 63 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c 
 b/arch/arm/mach-omap2/powerdomains3xxx_data.c
 index e1bec56..64973d1 100644
 --- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
 +++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
 @@ -31,6 +31,9 @@
  
  /*
   * Powerdomains
 + *
 + * The wakeup_lat values are derived from measurements on
 + * the actual target.

Which actual target.

Exactly how were they measured?  and between which events?

Kevin

   */
  
  static struct powerdomain iva2_pwrdm = {
 @@ -52,6 +55,12 @@ static struct powerdomain iva2_pwrdm = {
   [2] = PWRSTS_OFF_ON,
   [3] = PWRDM_POWER_ON,
   },
 + .wakeup_lat = {
 + [PWRDM_FUNC_PWRST_OFF] = 1100,
 + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
 + [PWRDM_FUNC_PWRST_CSWR] = 350,
 + [PWRDM_FUNC_PWRST_ON] = 0,
 + },
  };
  
  static struct powerdomain mpu_3xxx_pwrdm = {
 @@ -68,6 +77,12 @@ static struct powerdomain mpu_3xxx_pwrdm = {
   .pwrsts_mem_on= {
   [0] = PWRSTS_OFF_ON,
   },
 + .wakeup_lat = {
 + [PWRDM_FUNC_PWRST_OFF] = 95,
 + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
 + [PWRDM_FUNC_PWRST_CSWR] = 45,
 + [PWRDM_FUNC_PWRST_ON] = 0,
 + },
  };
  
  /*
 @@ -98,6 +113,12 @@ static struct powerdomain core_3xxx_pre_es3_1_pwrdm = {
   [0] = PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */
   [1] = PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */
   },
 + .wakeup_lat = {
 + [PWRDM_FUNC_PWRST_OFF] = 100,
 + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
 + [PWRDM_FUNC_PWRST_CSWR] = 60,
 + [PWRDM_FUNC_PWRST_ON] = 0,
 + },
  };
  
  static struct powerdomain core_3xxx_es3_1_pwrdm = {
 @@ -121,6 +142,12 @@ static struct powerdomain core_3xxx_es3_1_pwrdm = {
   [0] = PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */
   [1] = PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */
   },
 + .wakeup_lat = {
 + [PWRDM_FUNC_PWRST_OFF] = 100,
 + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
 + [PWRDM_FUNC_PWRST_CSWR] = 60,
 + [PWRDM_FUNC_PWRST_ON] = 0,
 + },
  };
  
  static struct powerdomain dss_pwrdm = {
 @@ -136,6 +163,12 @@ static struct powerdomain dss_pwrdm = {
   .pwrsts_mem_on= {
   [0] = PWRDM_POWER_ON,  /* MEMONSTATE */
   },
 + .wakeup_lat = {
 + [PWRDM_FUNC_PWRST_OFF] = 70,
 + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
 + [PWRDM_FUNC_PWRST_CSWR] = 20,
 + [PWRDM_FUNC_PWRST_ON] = 0,
 + },
  };
  
  /*
 @@ -157,6 +190,12 @@ static struct powerdomain sgx_pwrdm = {
   .pwrsts_mem_on= {
   [0] = PWRDM_POWER_ON,  /* MEMONSTATE */
   },
 + .wakeup_lat = {
 + [PWRDM_FUNC_PWRST_OFF] = 1000,
 + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
 + [PWRDM_FUNC_PWRST_CSWR] = UNSUP_STATE,
 + [PWRDM_FUNC_PWRST_ON] = 0,
 + },
  };
  
  static struct powerdomain cam_pwrdm = {
 @@ -172,6 +211,12 @@ static struct powerdomain cam_pwrdm = {
   .pwrsts_mem_on= {
   [0] = PWRDM_POWER_ON,  /* MEMONSTATE */
   },
 + .wakeup_lat = {
 + [PWRDM_FUNC_PWRST_OFF] = 850,
 + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
 + [PWRDM_FUNC_PWRST_CSWR] = 35,
 + [PWRDM_FUNC_PWRST_ON] = 0,
 + },
  };
  
  static struct powerdomain per_pwrdm = {
 @@ -187,6 +232,12 @@ static struct powerdomain per_pwrdm = {
   .pwrsts_mem_on= {
   [0] = PWRDM_POWER_ON,  /* MEMONSTATE */
   },
 + .wakeup_lat = {
 + [PWRDM_FUNC_PWRST_OFF] = 200,
 + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
 + [PWRDM_FUNC_PWRST_CSWR] = 110,
 + [PWRDM_FUNC_PWRST_ON] = 0,
 + },
  };
  
  static struct powerdomain emu_pwrdm = {
 @@ -201,6 +252,12 @@ static struct powerdomain neon_pwrdm = {
   .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
   .pwrsts   = PWRSTS_OFF_RET_ON,
   .pwrsts_logic_ret = PWRDM_POWER_RET,
 + .wakeup_lat = {
 + [PWRDM_FUNC_PWRST_OFF] = 200,
 + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
 + [PWRDM_FUNC_PWRST_CSWR] = 35,
 + [PWRDM_FUNC_PWRST_ON] = 0,
 + },
  };
  
  static struct powerdomain

Re: [PATCH v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4

2011-03-17 Thread Stephan Raue


Am 17.03.2011 21:16, schrieb Stephan Raue:

Am 17.03.2011 17:20, schrieb Janorkar, Mayuresh:

...
Is it possible for you to enable low-level debugging and pass 
omapfb.debug=1 omapdss.debug=1 in your bootargs?
This would show the Framebuffer and DSSDBG prints. We would get an 
idea if kernel is getting stuck in DSS/OMAPFB.


Let me know if you any help in enabling debug prints.

Also one more suggestion/ question, are you seeing a hang if DSS is 
not enabled in kernel?


-Thanks,
Mayuresh

i have done, there is not more output with enable low level debugging 
and passing this options... :-(


disabling DSS lets boot the kernel and start initramfs (see: 
http://paste.pocoo.org/show/355262/)

an update:

compiled with DSS/HDMI support as modules, loading modules with:

  modprobe omapdss
  modprobe omapfb

and doing a

  dmesg

in the init script gives me:

  modprobe: can't load module omapdss 
(kernel/drivers/video/omap2/dss/omapdss.ko): invalid module format
  modprobe: can't load module cfbcopyarea 
(kernel/drivers/video/cfbcopyarea.ko): invalid module format


see: http://paste.pocoo.org/show/355300/ line 254,255,514,515

why? the complete kernel with modules is rebuild from scratch

thanks much

Stephan
--
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 0/4] OMAP: DMA: mstandby mode and runtime pm support

2011-03-17 Thread Kevin Hilman

G, Manjunath Kondaiah manj...@ti.com writes:

 Patch series to support mstandby mode handling and enabling runtime PM
 support for DMA driver.

I still have the same problems as with the previous revision: 


This is still not runtime-suspending when I use my DMA test in linking
mode.

If I put a large enough period between transfers, it should autosuspend
during transfers.  It seems to do auto-suspend and resume once, but then
it never suspends again.

I tested with my dmatest module[1], and loaded with:

  # insmod ./dmatest.ko linking=1 forever=1 forever_period=1024

Not only does it not auto-suspend between transfers (which I expected),
it also doesn't suspend after removing the module which stops all active
channels.

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 v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4

2011-03-17 Thread Stephan Raue


Am 17.03.2011 22:13, schrieb Stephan Raue:

Am 17.03.2011 21:16, schrieb Stephan Raue:
an update:

compiled with DSS/HDMI support as modules, loading modules with:

  modprobe omapdss
  modprobe omapfb

and doing a

  dmesg

in the init script gives me:

  modprobe: can't load module omapdss 
(kernel/drivers/video/omap2/dss/omapdss.ko): invalid module format
  modprobe: can't load module cfbcopyarea 
(kernel/drivers/video/cfbcopyarea.ko): invalid module format


see: http://paste.pocoo.org/show/355300/ line 254,255,514,515

why? the complete kernel with modules is rebuild from scratch

next update:

disable:

CONFIG_LOCALVERSION_AUTO
CONFIG_MODULE_FORCE_LOAD
CONFIG_MODULE_FORCE_UNLOAD
CONFIG_MODVERSIONS
CONFIG_MODULE_SRCVERSION_ALL

gives:

[3.934814] Bad mode in data abort handler detected
[3.939941] Internal error: Oops - bad mode: 0 [#1] SMP
[3.945404] last sysfs file: /sys/devices/virtual/graphics/fbcon/cursor_blink
[3.952911] Modules linked in: omapdss(+)
[3.957122] CPU: 0Not tainted  (2.6.38 #1)
[3.961791] PC is at 0x0018
[3.965179] LR is at omap_dsshw_probe+0x1d4/0x358 [omapdss]
[3.971008] pc : [0018]lr : [bf000d14]psr: 6092
[3.971038] sp : ef149d08  ip : c0e2bcd8  fp : 
[3.983093] r10: 0028  r9 : c0ef4338  r8 : 
[3.988555] r7 : bf012904  r6 :   r5 : ef947c40  r4 : 
[3.995422] r3 : f08fc000  r2 : 02102006  r1 : ef149cf0  r0 : 
[4.002288] Flags: nZCv  IRQs off  FIQs on  Mode IRQ_32  ISA ARM  Segment 
user
[4.009857] Control: 10c53c7d  Table: af3b404a  DAC: 0015
[4.015899] Process modprobe (pid: 559, stack limit = 0xef1482f8)
[4.022308] Stack: (0xef149d08 to 0xef14a000)
[4.026885] 9d00:    ef149cf0 02102006 f08fc000 
 ef947c40
[4.035461] 9d20:  bf012904  c0ef4338 0028  
c0e2bcd8 ef149d08
[4.044067] 9d40: bf000d14 0018 6092  bf013050 ef947c40 
 bf000d14
[4.052642] 9d60: ef954008 ef95403c bf012904 c067b8b4 c067b8a0 c067aacc 
 ef954008
[4.061248] 9d80: ef95403c bf012904  c067abf0 bf012904 ef149da0 
c067ab88 c0679d38
[4.069824] 9da0: ef84f658 ef949730 bf012904 bf012904 ef1e7a60 c09cac08 
 c067a3d0
[4.078430] 9dc0: bf00e65b 0468  bf012904 c09b4d90 c09b0b28 
bf012848 
[4.087005] 9de0: 0028 c067ae44  bf013034 c09b4d90 c09b0b28 
bf012848 
[4.095611] 9e00: 0028 bf00053c c09b4d90 efa72690 c0aa1380 c09b4d98 
c09b4dcc bf012848
[4.104217] 9e20: bf012848  0028 c067b8b4 c067b8a0 c067aacc 
 c09b4d98
[4.112792] 9e40: c09b4dcc bf012848  c067abf0 bf012848 ef149e60 
c067ab88 c0679d38
[4.121398] 9e60: ef84f658 ef9491b0 bf012848 bf012848 ef1e7c60 c09cac08 
 c067a3d0
[4.129974] 9e80: bf00e09e 0468  bf012848  ef27f9a0 
bf01d000 
[4.138580] 9ea0: 0028 c067ae44 c067b8d8   ef27f9a0 
bf01d000 
[4.147155] 9ec0: 0028 bf01d064 bf012ed4 c0431694  0001 
bf012ed4 bf012ed4
[4.155761] 9ee0: 0001 bf012ed4  ef27f9a0 bf012f1c 0001 
0028 c04af9e4
[4.164337] 9f00: bf012ee0 000aa048 0003 c04ad17c c0ef4330 c07f45bc 
bf013018 000aa048
[4.172943] 9f20:  f08d9000 000201b0 f08ec450 f08ec2dc f08f11a8 
ef385800 00014740
[4.181518] 9f40: 000186a0   0023 0024 0019 
 000f
[4.190124] 9f60:  bf011a34 0016    
 0080
[4.198699] 9f80: 6010 400368e0   0080 c043b5c8 
ef148000 
[4.207305] 9fa0: 0003 c043b400 400368e0  4020e000 000201b0 
000aa048 0003
[4.215881] 9fc0: 400368e0   0080   
000aa048 0003
[4.224487] 9fe0: bee1a880 bee1a870 00036138 401ab0a0 6010 4020e000 
 
[4.233093] [bf000d14] (omap_dsshw_probe+0x1d4/0x358 [omapdss]) from 
[f08fc000] (0xf08fc000)
[4.242340] Code: e59ff410 eabb ea9a eafa (ea78)
[4.248748] [ cut here ]
[4.253601] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:98 
l3_interrupt_handler+0xb8/0x134()
[4.262664] L3 standard error: SOURCE:DSS  at address 0x10
[4.268402] Modules linked in: omapdss(+)
[4.272644] [c044239c] (unwind_backtrace+0x0/0xe4) from [c047457c] 
(warn_slowpath_common+0x4c/0x64)
[4.282531] [c047457c] (warn_slowpath_common+0x4c/0x64) from [c0474614] 
(warn_slowpath_fmt+0x2c/0x3c)
[4.292572] [c0474614] (warn_slowpath_fmt+0x2c/0x3c) from [c0455898] 
(l3_interrupt_handler+0xb8/0x134)
[4.302734] [c0455898] (l3_interrupt_handler+0xb8/0x134) from [c04b46f8] 
(handle_IRQ_event+0x6c/0x15c)
[4.312896] [c04b46f8] (handle_IRQ_event+0x6c/0x15c) from [c04b6344] 
(handle_level_irq+0xdc/0x160)
[4.322692] [c04b6344]

Re: [PATCH] OMAP4: PM: remove redundant #ifdef CONFIG_PM

2011-03-17 Thread Kevin Hilman

Nishanth Menon n...@ti.com writes:

 pm44xx.c is built only when CONFIG_PM is setup,
 remove redundant CONFIG_PM check.

 This also fixes:
 https://bugzilla.kernel.org/show_bug.cgi?id=25022

 Reported-by: Martin Etti ettl.mar...@gmx.de

 Signed-off-by: Nishanth Menon n...@ti.com

Thanks, queuing for 2.6.39-rc fixes cycle (branch: for_2.6.39/pm-fixes)

Kevin

 ---
  arch/arm/mach-omap2/pm44xx.c |2 --
  1 files changed, 0 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
 index 76cfff2..59a870b 100644
 --- a/arch/arm/mach-omap2/pm44xx.c
 +++ b/arch/arm/mach-omap2/pm44xx.c
 @@ -105,13 +105,11 @@ static int __init omap4_pm_init(void)
  
   pr_err(Power Management for TI OMAP4.\n);
  
 -#ifdef CONFIG_PM
   ret = pwrdm_for_each(pwrdms_setup, NULL);
   if (ret) {
   pr_err(Failed to setup powerdomains\n);
   goto err2;
   }
 -#endif
  
  #ifdef CONFIG_SUSPEND
   suspend_set_ops(omap_pm_ops);
--
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 0/2] [pm-wip/cpufreq] OMAP: CPUfreq cleanup and SMP support

2011-03-17 Thread Kevin Hilman

Santosh Shilimkar santosh.shilim...@ti.com writes:

 This series is an attempt to clean-up OMAP CPUfreq driver.
   - The OMAP1 and OMAP2PLUS cpufreq support is split to avoid
 any #ifdefery
   - The omap2plus_cupfreq support is updated to work on
 SMP_ON_UP builds
   - SMP support is added which can be used on OMAP4

 The series is generated against Kevin's latest cpufreq branch.

Thanks, adding to pm-wip/cpufreq branch.

Kevin

 The following changes since commit 444a22eb04ae07aef45cd4d0154f6f2bbe76daa9:
   Kevin Hilman (1):
 cpufreq: fixup after new OPP layer merged

 Santosh Shilimkar (2):
   OMAP: cpufreq: Split OMAP1 and OMAP2PLUS CPUfreq drivers.
   OMAP2PLUS: cpufreq: Add SMP support to cater OMAP4430

  arch/arm/mach-omap1/Makefile   |3 +
  .../cpu-omap.c = mach-omap1/omap1-cpufreq.c}  |   68 +++--
  arch/arm/mach-omap2/Makefile   |3 +
  .../cpu-omap.c = mach-omap2/omap2plus-cpufreq.c}  |  156 
 +---
  arch/arm/plat-omap/Makefile|1 -
  5 files changed, 128 insertions(+), 103 deletions(-)
  copy arch/arm/{plat-omap/cpu-omap.c = mach-omap1/omap1-cpufreq.c} (75%)
  rename arch/arm/{plat-omap/cpu-omap.c = mach-omap2/omap2plus-cpufreq.c} 
 (55%)
--
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 v12 4/9] OMAP2+: dmtimer: convert to platform devices

2011-03-17 Thread Kevin Hilman

Tony Lindgren t...@atomide.com writes:

 * Kevin Hilman khil...@ti.com [110311 16:00]:
 Tony Lindgren t...@atomide.com writes:
 
  * DebBarma, Tarun Kanti tarun.ka...@ti.com [110310 20:18]:
   From: Hilman, Kevin
   
   I guess Tony has the final say here, but personally, I don't really like
   the special treatment of a system timer, unless it is an init-time only
   special treatment.  Since we now have dynamically configurable
   clocksources, the concept of a system timer doesn't really exist (except
   for in early boot.)  At any time during runtime, we could dynamically
   switch the clocksource to a different timer device.  At this point, one
   would expect runtime PM for the previous timer to kick in and idle the
   timer.  That cannot happen with this approach.
 
  I am open to suggestions.
 
  There's no need to dynamically change the clocksource. We can to set up
  things so we have a system timer running with minimal code and faster
  clock rate. Then we can use a separate timer with the 32KiHZ source
  just to provide wake-up events for idle modes. And this second wake-up
  timer can be just a regular device driver.
 
  The system timer code needs to be fast. And I don't want to add any
  dependencies to anything except clock framework. Like I've said, the
  rest of the timers can be just a regular device driver.
 
 There are a couple problems with this approach.  The special case
 handling of a system timer leads to duplicate code (this series is a
 good example.)

 I think the related inline functions can be shared.
  

The way it is currently coded results in duplicate code.  One of them
uses the clock API directly, the other uses runtime PM.

 The other problem is PM.
 
 If we switch away from the original system timer (for whatever reason),
 since it is not a regular device, it will not have runtime PM We'll then
 need special case PM code for the system timer, which I think is wasted
 effort.

 This should not cause problems either, there should not be any need to
 switch the timers in the setup what I'm thinking.

 In the long run, think local timer for runtime, and then wakeup timer
 that gets only programmed when we enter idle. The local timer will
 continue operating normally after we wake-up and the wakeup timer
 will be just one shot event. Of course in the omap[23] case the
 local timer is really a faster dmtimer, but in the omap4+ case there's
 are real local timers.

 If this can be done such that the system timer is eventually a regular
 device driver, then that should be fine. 

 In this setup there should not be need to mess with the system timer
 after boot as we don't need to switch clock sources.

I think we're confusing terminology.  By system timer, I think you mean
the clockevent, right?

The situation you described above requires switching clockevents for
sure.  

In addition, we already have a usecase for switching the clocksource as
well.  We currently setup a single clocksource using the timer_32k (not
a dmtimer.)  However, we already have use-cases where we would like to
switch to a higher resolution clocksource (e.g. trace infrastructure for
PM instrumentation.)

The whole point of switching these to real drivers is so they can use
runtime PM.Then, as soon as they are unused, runtime PM will kick in
and ensure the hardware is properly idle.

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: [RFC][PATCH 1/3] OMAP PM: Seggregate Voltage layer parameters

2011-03-17 Thread Kevin Hilman

Vishwanath BS vishwanath...@ti.com writes:

 Voltage layer takes various parameters which can be broadly classified as
 1. OMAP/VP specific parameters
 2. PMIC specific parameters
 3. Board specific parameters

For readability sake, this could be broken up along into 3 patches for
these 3 items.


 This patch attempts to categorize the parameters in current voltage layer into
 above buckets. This will make voltage layer to work with different kinds of 
 PMIC
 and boards.

 TODO: Provide infrastructure to use VC I2C (I2C4) for PMIC configuration 
 (useful
 for cases where PMIC is connected to OMAP only via I2C4.

 Signed-off-by: Vishwanath BS vishwanath...@ti.com
 ---
  arch/arm/mach-omap2/omap_opp_data.h   |8 ++
  arch/arm/mach-omap2/omap_twl.c|  108 -
  arch/arm/mach-omap2/opp3xxx_data.c|   50 
  arch/arm/mach-omap2/opp4xxx_data.c|   38 ++
  arch/arm/mach-omap2/voltage.c |  167 
 -
  arch/arm/mach-omap2/voltage.h |  115 +++--
  arch/arm/mach-omap2/voltagedomains3xxx_data.c |4 +
  arch/arm/mach-omap2/voltagedomains44xx_data.c |4 +
  8 files changed, 393 insertions(+), 101 deletions(-)

 diff --git a/arch/arm/mach-omap2/omap_opp_data.h 
 b/arch/arm/mach-omap2/omap_opp_data.h
 index c784c12..70d61d2 100644
 --- a/arch/arm/mach-omap2/omap_opp_data.h
 +++ b/arch/arm/mach-omap2/omap_opp_data.h
 @@ -86,11 +86,19 @@ extern int __init omap_init_opp_table(struct omap_opp_def 
 *opp_def,
  
  extern struct omap_volt_data omap34xx_vddmpu_volt_data[];
  extern struct omap_volt_data omap34xx_vddcore_volt_data[];
 +extern struct omap_vp_param omap34xx_mpu_vp_data;
 +extern struct omap_vp_param omap34xx_core_vp_data;
 +
  extern struct omap_volt_data omap36xx_vddmpu_volt_data[];
  extern struct omap_volt_data omap36xx_vddcore_volt_data[];
 +extern struct omap_vp_param omap36xx_mpu_vp_data;
 +extern struct omap_vp_param omap36xx_core_vp_data;
  
  extern struct omap_volt_data omap44xx_vdd_mpu_volt_data[];
  extern struct omap_volt_data omap44xx_vdd_iva_volt_data[];
  extern struct omap_volt_data omap44xx_vdd_core_volt_data[];
 +extern struct omap_vp_param omap44xx_mpu_vp_data;
 +extern struct omap_vp_param omap44xx_iva_vp_data;
 +extern struct omap_vp_param omap44xx_core_vp_data;
  
  #endif   /* __ARCH_ARM_MACH_OMAP2_OMAP_OPP_DATA_H */
 diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
 index 0a8e74e..f96d4b2 100644
 --- a/arch/arm/mach-omap2/omap_twl.c
 +++ b/arch/arm/mach-omap2/omap_twl.c
 @@ -29,7 +29,6 @@
  #define OMAP3_VP_VSTEPMIN_VSTEPMIN   0x1
  #define OMAP3_VP_VSTEPMAX_VSTEPMAX   0x04
  #define OMAP3_VP_VLIMITTO_TIMEOUT_US 200
 -
  #define OMAP3430_VP1_VLIMITTO_VDDMIN 0x14
  #define OMAP3430_VP1_VLIMITTO_VDDMAX 0x42
  #define OMAP3430_VP2_VLIMITTO_VDDMIN 0x18
 @@ -44,12 +43,10 @@
  #define OMAP4_VDD_MPU_SR_VOLT_REG0x55
  #define OMAP4_VDD_IVA_SR_VOLT_REG0x5B
  #define OMAP4_VDD_CORE_SR_VOLT_REG   0x61
 -
  #define OMAP4_VP_CONFIG_ERROROFFSET  0x00
  #define OMAP4_VP_VSTEPMIN_VSTEPMIN   0x01
  #define OMAP4_VP_VSTEPMAX_VSTEPMAX   0x04
  #define OMAP4_VP_VLIMITTO_TIMEOUT_US 200
 -
  #define OMAP4_VP_MPU_VLIMITTO_VDDMIN 0xA
  #define OMAP4_VP_MPU_VLIMITTO_VDDMAX 0x39
  #define OMAP4_VP_IVA_VLIMITTO_VDDMIN 0xA
 @@ -146,101 +143,96 @@ static u8 twl6030_uv_to_vsel(unsigned long uv)
  static struct omap_volt_pmic_info omap3_mpu_volt_info = {
   .slew_rate  = 4000,
   .step_size  = 12500,
 - .on_volt= 120,
 - .onlp_volt  = 100,
 - .ret_volt   = 975000,
 - .off_volt   = 60,
 - .volt_setup_time= 0xfff,
 - .vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
 - .vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
 - .vp_vstepmax= OMAP3_VP_VSTEPMAX_VSTEPMAX,
 + .vp_timeout_us  = OMAP3_VP_VLIMITTO_TIMEOUT_US,
 + .i2c_slave_addr = OMAP3_SRI2C_SLAVE_ADDR,
 + .pmic_reg   = OMAP3_VDD_MPU_SR_CONTROL_REG,
 + .vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
 + .vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
 + .vp_vstepmax= OMAP3_VP_VSTEPMAX_VSTEPMAX,

Please check the resulting indentation, and be sure it aligns with existing.

   .vp_vddmin  = OMAP3430_VP1_VLIMITTO_VDDMIN,
   .vp_vddmax  = OMAP3430_VP1_VLIMITTO_VDDMAX,
 - .vp_timeout_us  = OMAP3_VP_VLIMITTO_TIMEOUT_US,
 - .i2c_slave_addr = OMAP3_SRI2C_SLAVE_ADDR,
 - .pmic_reg   = OMAP3_VDD_MPU_SR_CONTROL_REG,
   .vsel_to_uv = twl4030_vsel_to_uv,
   .uv_to_vsel = twl4030_uv_to_vsel,
 + .on_cmd = twl4030_uv_to_vsel,
 + .onlp_cmd   = twl4030_uv_to_vsel,
 + .ret_cmd= twl4030_uv_to_vsel,
 + .off_cmd= twl4030_uv_to_vsel,

Re: [RFC][PATCH 3/3] OMAP PM: Add Board specific parameters for OMAP Volatge layer

2011-03-17 Thread Kevin Hilman

Menon, Nishanth n...@ti.com writes:

[...]

 my overall suggestion - when I fill in board file params - I should say:
 I use PMIC x, i have oscillator with ramp y uSec - the params should
 talk my language as a board developers - I dont want to know indepth
 details of voltage VP/VC registers and what they should contain. it is
 upto voltage layer to translate, add, bit shift or do what ever is
 necessary to take my board and pmic level details to register details.

Completely agree with Nishanth.

See my comments on PATCH 1/3 which say basically the same thing.

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: [GIT PULL] omap changes for v2.6.39 merge window

2011-03-17 Thread Linus Torvalds

On Thu, Mar 17, 2011 at 11:30 AM, Tony Lindgren t...@atomide.com wrote:

 Please pull omap changes for this merge window from:

Gaah. Guys, this whole ARM thing is a f*cking pain in the ass.

You need to stop stepping on each others toes. There is no way that
your changes to those crazy clock-data files should constantly result
in those annoying conflicts, just because different people in
different ARM trees do some masturbatory renaming of some random
device. Seriously.

That usb_musb_init() thing in arch/arm/mach-omap2/usb-musb.c also
seems to be totally insane. I wonder what kind of insanity I'm missing
just because I don't happen to see the merge conflicts, just because
people were lucky enough to happen to not touch the same file within a
few lines.

Somebody needs to get a grip in the ARM community. I do want to do
these merges, just to see how screwed up things are, but guys, this is
just ridiculous. The pure amount of crazy churn is annoying in itself,
but when I then get these independent pull requests from four
different people, and they touch the same files, that indicates that
something is wrong.

And stop the crazy renaming already! Just leave it off. Don't rename
boards and drivers just because, at least not when there clearly are
clashes. There's no point. I'm not even talking about the file renames
(which happened and can also make it fun to try to resolve the
conflicts when somebody else then makes _other_ changes), but about
the stupid change human-readable names in board files just to annoy
whoever needs to merge the crap.

Somebody in the ARM community really needs to step up and tell people
to stop dicking around.

(I'm replying to the omap pull request, because that's the one I did
last, but I don't know who to blame. I don't care. It really doesn't
matter. I realize thar ARM vendors do crazy shit and haven't figured
out this whole platform thing yet, but you guys need to push back on
the people sending you crap).

   Linus
--
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: [GIT PULL] omap changes for v2.6.39 merge window

2011-03-17 Thread Linus Torvalds

On Thu, Mar 17, 2011 at 11:30 AM, Tony Lindgren t...@atomide.com wrote:

 Please pull omap changes for this merge window from:

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

Btw, that generic hardware spinlock thing needs to be hidden from
sane people and architectures that don't need it.

Make platforms that need it select it or something. It looks like
nobody but an OMAP4 could _possibly_ ever want to answer 'y' to that
question, SO DON'T ASK IT!

 Linus
--
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 v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4

2011-03-17 Thread Tomi Valkeinen

On Thu, 2011-03-17 at 16:13 -0500, Stephan Raue wrote:

 compiled with DSS/HDMI support as modules, loading modules with:
 
modprobe omapdss
modprobe omapfb
 
 and doing a
 
dmesg
 
 in the init script gives me:
 
modprobe: can't load module omapdss 
 (kernel/drivers/video/omap2/dss/omapdss.ko): invalid module format
modprobe: can't load module cfbcopyarea 
 (kernel/drivers/video/cfbcopyarea.ko): invalid module format
 
 see: http://paste.pocoo.org/show/355300/ line 254,255,514,515
 
 why? the complete kernel with modules is rebuild from scratch

I don't see how that could be a problem in DSS. I mostly use DSS as
modules, so it works ok. Are you sure DSS compiled fine, and those
modules are right for the kernel you run? Can you load any other module
compiled at that time?

 Tomi


--
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

FW: omap2+ voltage: Few queries

2011-03-17 Thread Premi, Sanjeev

Hi all,
 
While trying to understand the voltage layer, i have few comments and
doubts. This is not a comprehensive list, but for starters:
 
1) Functions omap3_voltage_read_reg(), omap3_voltage_write_reg()
   which in turn call omap2_prm_read_mod_reg and omap2_prm_write_mod_reg() 
 
   These functions are always called via function pointer contained
   in omap_vdd_info.
 
   What is the need for additional layer?
   shouldn't be just do the following:
 
 vdd-read_reg = omap2_prm_read_mod_reg ;
 vdd-write_reg = omap2_prm_write_mod_reg  ;
 
   Same holds good for similar functions for OMAP4.
 
2) Structure omap_volt_data is used to describe the nominal voltage
   for each OPP, However, presence of sr_efuse_offs, sr_errminlimit,
   vp_errgain make assumptions on presence of SmartReflex and VP.
 
   Value 0 to these fields cannot safely be used to indicate the
   not used status - esp for sr_xx fields.
 
   Shouldn't we delink them. something like:
 
   struct omap_volt_data {
u32 volt_nominal;
u8 vp_errgain; /* Assuming that value 0 is equiv to not used */
struct volt_sr_data* sr_data;
   }
 
3) Struct omap_volt_pmic_info should be trimmed to keep only PMIC
   related info. Will make it easier to add support for other PMICs.
 
   Suggestion:
 
   struct omap_pmic_info {
int slew_rate;
int step_size;

u8 i2c_slave_addr;
u8 pmic_reg;
struct omap_pmic_extra_info * extra;
unsigned long (*vsel_to_uv) (const u8 vsel);
u8 (*uv_to_vsel) (unsigned long uV);
};
 
   BTW, what does the PMIC register indicate? target addr on PMIC?
 
/* Not all PMICs would be able to support these features */
   struct omap_pmic_extra_info {

u32 on_volt;
u32 onlp_volt;
u32 ret_volt;
u32 off_volt;

};
 
   extra is just random name, even aux standing for auxilliary
   should do.
 
   struct omap_vp_info { /* just random name for this mail only */
u8 vp_erroroffset;
u8 vp_vstepmin;
u8 vp_vstepmax;
u8 vp_vddmin;
u8 vp_vddmax;
u8 vp_timeout_us;
};
 
   Can this/ Should this be combined with an existing structure?
   e.g. omap_vp_common_data?
 
I have some work-in-progress changes. Based on the responses, i will
tailor them and send across tomorrow.
 
Best regards,
Sanjeev

(folks in cc: sorry for resend. Original mail in
  was mistakenly sent in HTML format;
  and not delivered to the list)
 --
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/2] omap3: voltage: fix variable type and name

2011-03-17 Thread Premi, Sanjeev

 -Original Message-
 From: Hilman, Kevin 
 Sent: Friday, March 18, 2011 1:42 AM
 To: Premi, Sanjeev
 Cc: linux-omap@vger.kernel.org
 Subject: Re: [PATCH 2/2] omap3: voltage: fix variable type and name

 Sanjeev Premi pr...@ti.com writes:

  In all usages, variables prm_mod_offs and prm_irqst_ocp_mod_offs
  are expected to be u16 but have been declared as s16.

 What kind of problem is that causing?

[sp] No, it wasn't causing any problems 0 because offset value wouldn't
 reach the signed / unsigned limits; but didn't seem right while
 reading the code.

~sanjeev

 Kevin

  In addition, renamed prm_irqst_ocp_mod_offs to ocp_sysreg_prm_offs
  for better association with the TRM. Original name perhaps came
  from the current usage of this offset to reach PRM_IRQSTATUS_MPU
  offset.

[snip]...[snip]
--
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 1/2] omap3: voltage: remove unnecessary param passing

2011-03-17 Thread Premi, Sanjeev

 -Original Message-
 From: Hilman, Kevin 
 Sent: Friday, March 18, 2011 1:41 AM
 To: Premi, Sanjeev
 Cc: linux-omap@vger.kernel.org
 Subject: Re: [PATCH 1/2] omap3: voltage: remove unnecessary 
 param passing
 
 Sanjeev Premi pr...@ti.com writes:
 
  It is not necessary to pass the params prm_mod and
  prm_irqst_mod to omap_voltage_early_init().
 
  Signed-off-by: Sanjeev Premi pr...@ti.com
 
 Hi Sanjeev,
 
 I also started working on cleaning some of this up, but I took a
 slightly different approach[1], namely I make these offsets 
 part of the
 VDD structure so that this data stays in the data files.
 
 I'm still working on the series, but the work-in-progress is in my
 pm-wip/voltdm branch, which I expect to post for comment tomorrow.
 
 Kevin
 
 [1] 
 http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-p
 m.git;a=commit;h=185cdf40ad978a466106b52fce9b68ca7081f358

[sp] I had considered this, but the PRM offset wouldn't change for
 each VDD. Therefore, opted to keep static in the file just as
 few other files e.g. control.c

~sanjeev

 [2] 
 http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-p
m.git;a=shortlog;h=refs/heads/pm-wip/voltdm
 
  ---
   arch/arm/mach-omap2/voltage.c |   18 
 ++
   arch/arm/mach-omap2/voltage.h |3 +--
   arch/arm/mach-omap2/voltagedomains3xxx_data.c |5 +
   arch/arm/mach-omap2/voltagedomains44xx_data.c |6 +-
   4 files changed, 17 insertions(+), 15 deletions(-)
 
  diff --git a/arch/arm/mach-omap2/voltage.c 
 b/arch/arm/mach-omap2/voltage.c
  index c6facf7..ce3098a 100644
  --- a/arch/arm/mach-omap2/voltage.c
  +++ b/arch/arm/mach-omap2/voltage.c
  @@ -1096,12 +1096,22 @@ int __init omap_voltage_late_init(void)
   }
   
   /* XXX document */
  -int __init omap_voltage_early_init(s16 prm_mod, s16 
 prm_irqst_ocp_mod,
  -  struct omap_vdd_info 
 *omap_vdd_array[],
  +int __init omap_voltage_early_init(struct omap_vdd_info 
 *omap_vdd_array[],
 u8 omap_vdd_count)
   {
  -   prm_mod_offs = prm_mod;
  -   prm_irqst_ocp_mod_offs = prm_irqst_ocp_mod;
  +   if (cpu_is_omap44xx()) {
  +   prm_mod_offs = OMAP4430_PRM_DEVICE_INST;
  +   prm_irqst_ocp_mod_offs = OMAP4430_PRM_OCP_SOCKET_INST;
  +   } else if (cpu_is_omap34xx()) {
  +   prm_mod_offs = OMAP3430_GR_MOD;
  +   prm_irqst_ocp_mod_offs = OCP_MOD;
  +   } else {
  +   /* TODO:
  +* What should be done for OMAP24xx?
  +* Would we even reach here?
  +*/
  +   }
  +
  vdd_info = omap_vdd_array;
  nr_scalable_vdd = omap_vdd_count;
  return 0;
  diff --git a/arch/arm/mach-omap2/voltage.h 
 b/arch/arm/mach-omap2/voltage.h
  index e9f5408..b56530e 100644
  --- a/arch/arm/mach-omap2/voltage.h
  +++ b/arch/arm/mach-omap2/voltage.h
  @@ -151,8 +151,7 @@ struct omap_volt_data 
 *omap_voltage_get_voltdata(struct voltagedomain *voltdm,
  unsigned long volt);
   unsigned long omap_voltage_get_nom_volt(struct 
 voltagedomain *voltdm);
   struct dentry *omap_voltage_get_dbgdir(struct 
 voltagedomain *voltdm);
  -int __init omap_voltage_early_init(s16 prm_mod, s16 prm_irqst_mod,
  -  struct omap_vdd_info 
 *omap_vdd_array[],
  +int __init omap_voltage_early_init(struct omap_vdd_info 
 *omap_vdd_array[],
 u8 omap_vdd_count);
   #ifdef CONFIG_PM
   int omap_voltage_register_pmic(struct voltagedomain *voltdm,
  diff --git a/arch/arm/mach-omap2/voltagedomains3xxx_data.c 
 b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
  index def230f..6f6999d 100644
  --- a/arch/arm/mach-omap2/voltagedomains3xxx_data.c
  +++ b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
  @@ -70,8 +70,6 @@ static struct omap_vdd_info *omap3_vdd_info[] = {
   /* OMAP3 specific voltage init functions */
   static int __init omap3xxx_voltage_early_init(void)
   {
  -   s16 prm_mod = OMAP3430_GR_MOD;
  -   s16 prm_irqst_ocp_mod = OCP_MOD;
   
  if (!cpu_is_omap34xx())
  return 0;
  @@ -88,8 +86,7 @@ static int __init 
 omap3xxx_voltage_early_init(void)
  omap3_vdd2_info.volt_data = omap34xx_vddcore_volt_data;
  }
   
  -   return omap_voltage_early_init(prm_mod, prm_irqst_ocp_mod,
  -  omap3_vdd_info,
  +   return omap_voltage_early_init(omap3_vdd_info,
 ARRAY_SIZE(omap3_vdd_info));
   };
   core_initcall(omap3xxx_voltage_early_init);
  diff --git a/arch/arm/mach-omap2/voltagedomains44xx_data.c 
 b/arch/arm/mach-omap2/voltagedomains44xx_data.c
  index cb64996..208a67d 100644
  --- a/arch/arm/mach-omap2/voltagedomains44xx_data.c
  +++ b/arch/arm/mach-omap2/voltagedomains44xx_data.c
  @@ -81,9 +81,6 @@ static struct omap_vdd_info *omap4_vdd_info[] = {
   /* OMAP4 specific voltage init functions */
   static int __init omap44xx_voltage_early_init(void)
   {
  -   s16

RE: [PATCH v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4

2011-03-17 Thread Anand Gadiyar

 i tried this test tree with omap2plus_defconfig.

 it seems the kernel crashes and poweroff the board on loading
 this hdmi stuff, but dont print any crashlog. is there a
 way any backtraces will be printed?
 output from serial console: http://paste.pocoo.org/show/354850/
 kernel config (omap2plus_defconfig, added squashfs support, added
 support to include initramfs in kernel, build omapfb stuff statically
 into the kernel): http://paste.pocoo.org/show/354853/

 i am using a own toolchain to crosscompile with gcc-4.5.2,
 binutils-2.21...

Just a hunch, but could you please turn off CONFIG_OMAP2_DSS_SDI
and try again?

- Anand
--
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 v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4

2011-03-17 Thread Anand Gadiyar

 i tried this test tree with omap2plus_defconfig.

 it seems the kernel crashes and poweroff the board on loading
 this hdmi stuff, but dont print any crashlog. is there a
 way any backtraces will be printed?
 output from serial console: http://paste.pocoo.org/show/354850/
 kernel config (omap2plus_defconfig, added squashfs support, added
 support to include initramfs in kernel, build omapfb stuff statically
 into the kernel): http://paste.pocoo.org/show/354853/

 i am using a own toolchain to crosscompile with gcc-4.5.2,
 binutils-2.21...

Just a hunch, but could you please turn off CONFIG_OMAP2_DSS_SDI
and try again?

- Anand
--
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 v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4

2011-03-17 Thread Anand Gadiyar

 i tried this test tree with omap2plus_defconfig.

 it seems the kernel crashes and poweroff the board on loading
 this hdmi stuff, but dont print any crashlog. is there a
 way any backtraces will be printed?
 output from serial console: http://paste.pocoo.org/show/354850/
 kernel config (omap2plus_defconfig, added squashfs support, added
 support to include initramfs in kernel, build omapfb stuff statically
 into the kernel): http://paste.pocoo.org/show/354853/

 i am using a own toolchain to crosscompile with gcc-4.5.2,
 binutils-2.21...

Just a hunch, but could you please turn off CONFIG_OMAP2_DSS_SDI
and try again?

- Anand
--
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 v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4

2011-03-17 Thread Anand Gadiyar

 i tried this test tree with omap2plus_defconfig.

 it seems the kernel crashes and poweroff the board on loading
 this hdmi stuff, but dont print any crashlog. is there a
 way any backtraces will be printed?
 output from serial console: http://paste.pocoo.org/show/354850/
 kernel config (omap2plus_defconfig, added squashfs support, added
 support to include initramfs in kernel, build omapfb stuff statically
 into the kernel): http://paste.pocoo.org/show/354853/

 i am using a own toolchain to crosscompile with gcc-4.5.2,
 binutils-2.21...

Just a hunch, but could you please turn off CONFIG_OMAP2_DSS_SDI
and try again?

- Anand
--
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 v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4

2011-03-17 Thread Anand Gadiyar

 i tried this test tree with omap2plus_defconfig.

 it seems the kernel crashes and poweroff the board on loading
 this hdmi stuff, but dont print any crashlog. is there a
 way any backtraces will be printed?
 output from serial console: http://paste.pocoo.org/show/354850/
 kernel config (omap2plus_defconfig, added squashfs support, added
 support to include initramfs in kernel, build omapfb stuff statically
 into the kernel): http://paste.pocoo.org/show/354853/

 i am using a own toolchain to crosscompile with gcc-4.5.2,
 binutils-2.21...

Just a hunch, but could you please turn off CONFIG_OMAP2_DSS_SDI
and try again?

- Anand
--
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 v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4

2011-03-17 Thread Anand Gadiyar

 i tried this test tree with omap2plus_defconfig.

 it seems the kernel crashes and poweroff the board on loading
 this hdmi stuff, but dont print any crashlog. is there a
 way any backtraces will be printed?
 output from serial console: http://paste.pocoo.org/show/354850/
 kernel config (omap2plus_defconfig, added squashfs support, added
 support to include initramfs in kernel, build omapfb stuff statically
 into the kernel): http://paste.pocoo.org/show/354853/

 i am using a own toolchain to crosscompile with gcc-4.5.2,
 binutils-2.21...

Just a hunch, but could you please turn off CONFIG_OMAP2_DSS_SDI
and try again?

- Anand
--
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

57 matches

Mail list logo