Re: arm: pmu: support pmu/perf on OMAP4 - booting problem on pandaboard

[Ming Lei]

Hi Avik,

2011/4/5 Avik Sil avik...@linux.vnet.ibm.com:
 Even after using ioremapped addresses in omap_writel() I'm getting the oops.
 Can you please point me to the location in mainline, where these l3 clocks
 are enabled?

I guess you can find here:

 l3_main_3_ick  l3_instr_ick: arch/arm/mach-omap2/clock44xx_data.c

the clocks are set as ENABLE_ON_INIT.

thanks,
-- 
Ming Lei
--
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

[Barry Song]

2011/4/1 Arnd Bergmann a...@arndb.de:
 On Friday 01 April 2011, Ingo Molnar wrote:
 IMO the right answer is what Linus and Thomas outlined:

    1) provide a small number of clean examples and clean abstractions
    2) to not pull new crap from that point on
    3) do this gradually but consistently

 I.e. make all your requirements technical and actionable - avoid sweeping,
 impossible to meet requirements. Do not require people to clean up all of the
 existing mess straight away (they cannot realistically do it), do not 
 summarily
 block the flow of patches, but be firm about drawing a line in the sand and 
 be
 firm about not introducing new mess in a gradually growing list of 
 well-chosen
 areas of focus.

 Rinse, repeat.

 I believe getting to point 1 is the hard part here. There are a lot of things
 that are wrong with the mach-* (and also plat-*) implementations, and I don't
 think we have one today that can really serve as an example. Most decisions
 made in there made a lot of sense when they were introduced, and declaring
 code that was perfectly acceptable yesterday to be unacceptable crap today
 is not going to be met with much understanding by the someone who just
 wants to add support for one more board to 100 already existing ones in the
 same SoC family.

 I would actually suggest a different much more radical start: Fork the way
 that platforms are managed today, and start an alternative way of setting
 up boards and devices together with the proven ARM core kernel infrastructure,
 based on these observations (please correct me if some of them they don't make
 sense):

 1. The core arch code is not a problem (Russell does a great job here)
 2. The platform specific code contains a lot of crap that doesn't belong there
   (not enough reviewers to push back on crap)
 3. The amount of crap in platform specfic files is growing exponentially,
   despite the best efforts of a handful of people to clean it up.
 4. Having one source file per board does not scale any more.
 5. Discoverable hardware would solve this, but is not going to happen
   in practice.
 6. Board firmware would not solve this and is usually not present.
 7. Boot loaders can not be trusted to pass valid information
 8. Device tree blobs can solve a lot of the problems, and nobody has
   come up with a better solution.

ARM BSP is still blasting! we are planning to merge our new ARM
cortex-a9 SoC into kernel. So I am just wondering whether traditional
ARM BSP way can still be accepted, or we must move to use device tree?
but i have't seen any arm device tree codes enter mainline yet. but we
can get those patches from linaro 2.6.38. So what's the plan for
merging arm device tree?

What i have seen is that the BSP architecture of different ARM SoC
companies is even different.

samsung has three levels:
plat-samsung
plat-s3c24xx
 mach-s3c2410
 mach-s3c2440
plat-s5p
 mach-s5pv210
 mach-s5pv310

TI has two levels:
plat-omap
mach-omap1
mach-omap2

Nvidia has one level:
mach-tegra

I didn't find any rule about what codes should be placed in what
directories. Different companies have different ways. It looks like
the only agreement is board files are in mach-xxx. Any suggestions for
that?

BTW, we don't want to dick around, which Linus has been very angry.
we want to fix more issues this email pointed out before we send
patches.

 9. All interesting work is going into a handful of platforms, all of which
   are ARMv7 based.
 10. We do not want to discontinue support for old boards that work fine.
 11. Massive changes to existing platforms would cause massive breakage.
 12. Supporting many different boards with a single kernel binary is a
    useful goal.
 13. Infrastructure code should be cross-platform, not duplicated across
    platforms.
 14. 32 bit ARM is hitting the wall in the next years (Cortex-A15 is
    actually adding PAE support, which has failed to solve this on
    other architectures).
 15. We need to solve the platform problem before 64 bit support comes
    and adds another dimension to the complexity.

 Based on these assumptions, my preferred strategy would be to a new
 mach-nocrap directory with a documented set of rules (to be adapted when
 necessary):

 * Strictly no crap
  * No board files
  * No hardcoded memory maps
  * No lists of interrupts and GPIOs
 * All infrastructure added must be portable to all ARMv7 based SoCs.
  (ARMv6 can be added later)
 * 64 bit safe code only.
 * SMP safe code only.
 * All board specific information must come from a device tree and
  be run-time detected.
 * Must use the same device drivers as existing platforms
 * Should share platform drivers (interrupt controller, gpio, timer, ...)
  with existing platforms where appropriate.
 * Code quality takes priority over stability in mach-nocrap, but must not
  break other platforms.

 Until we have something 

Re: Issue with DSS DSI: Complex IO not powering on

[Archit Taneja]

Hi,

On Wednesday 06 April 2011 07:25 AM, Juha Kuikka wrote:

Hi,
I am working on a custom board with DM3730 and a DSI panel and I have
a problem in powering on the DSI complex IO block.

The DSS DSI initialization fails with:
omapdss DSI: dsi_complexio_init
omapdss DSI error: complexio reset not done!-- my own addition
omapdss DSI error: failed to set complexio power state to 1

Can you check if the necessary pad/pin-muxing has been done for the DSI 
lanes?


Archit

The DSI PLL is used and configured according to the example values in
the TRM (not proper for our panel but they should enable the complex
IO to at least power on, right).

Output form DSS DEBUG:
omapdss DSI: LP_CLK_DIV 6, LP_CLK 750
omapdss DISPC: lck = 9000 (1)
omapdss DISPC: pck = 3000 (3)
- DSI PLL -
dsi pll source = dss2_alwon_fclk
Fint 200 regn 13
CLKIN4DDR 108000  regm 270
dsi1_pll_fck 9000regm3 12 (on)
dsi2_pll_fck 9000regm4 12 (on)
- DSI -
dsi fclk source = dsi2_pll_fclk
DSI_FCLK 9000
DDR_CLK 27000
TxByteClkHS 6750
LP_CLK 750
VP_CLK 9000
VP_PCLK 3000

As far as I can tell these values fill all the requirements set in the
TRM for clock rates and their ratios.

After the fail in dsi_complexio_init I dump all registers:

DSI_REVISION0010
DSI_SYSCONFIG   0011
DSI_SYSSTATUS   0001
DSI_IRQSTATUS   00080080
DSI_IRQENABLE   
DSI_CTRL0100
DSI_COMPLEXIO_CFG1  48200321
DSI_COMPLEXIO_IRQ_STATUS
DSI_COMPLEXIO_IRQ_ENABLE
DSI_CLK_CTRLa0304006
DSI_TIMING1 7fff7fff
DSI_TIMING2 7fff7fff
DSI_VM_TIMING1  
DSI_VM_TIMING2  
DSI_VM_TIMING3  
DSI_CLK_TIMING  0101
DSI_TX_FIFO_VC_SIZE 
DSI_RX_FIFO_VC_SIZE 
DSI_COMPLEXIO_CFG2  
DSI_RX_FIFO_VC_FULLNESS 
DSI_VM_TIMING4  
DSI_TX_FIFO_VC_EMPTINESS
DSI_VM_TIMING5  
DSI_VM_TIMING6  
DSI_VM_TIMING7  
DSI_STOPCLK_TIMING  0080
DSI_VC_CTRL(0)  
DSI_VC_TE(0)
DSI_VC_LONG_PACKET_HEADER(0)
DSI_VC_LONG_PACKET_PAYLOAD(0)   
DSI_VC_SHORT_PACKET_HEADER(0)   
DSI_VC_IRQSTATUS(0) 
DSI_VC_IRQENABLE(0) 
DSI_VC_CTRL(1)  
DSI_VC_TE(1)
DSI_VC_LONG_PACKET_HEADER(1)
DSI_VC_LONG_PACKET_PAYLOAD(1)   
DSI_VC_SHORT_PACKET_HEADER(1)   
DSI_VC_IRQSTATUS(1) 
DSI_VC_IRQENABLE(1) 
DSI_VC_CTRL(2)  
DSI_VC_TE(2)
DSI_VC_LONG_PACKET_HEADER(2)
DSI_VC_LONG_PACKET_PAYLOAD(2)   
DSI_VC_SHORT_PACKET_HEADER(2)   
DSI_VC_IRQSTATUS(2) 
DSI_VC_IRQENABLE(2) 
DSI_VC_CTRL(3)  
DSI_VC_TE(3)
DSI_VC_LONG_PACKET_HEADER(3)
DSI_VC_LONG_PACKET_PAYLOAD(3)   
DSI_VC_SHORT_PACKET_HEADER(3)   
DSI_VC_IRQSTATUS(3) 
DSI_VC_IRQENABLE(3) 
DSI_DSIPHY_CFG0 1e481d3a
DSI_DSIPHY_CFG1 420a1a6a
DSI_DSIPHY_CFG2 b81a
DSI_DSIPHY_CFG5 6000
DSI_PLL_CONTROL 
DSI_PLL_STATUS  0383
DSI_PLL_GO  
DSI_PLL_CONFIGURATION1  05d90e19
DSI_PLL_CONFIGURATION2  0005600e

Of special interest is the DSI_COMPLEXIO_CFG1. RESET_DONE is not set,
not does the PWR_STATUS match the command given. The
LDO_POWER_GOOD_STATE is asserted however.

The DSI is powered and all the clocks seem to be on and the DSI PLL
locks. Just the complex IO will not power on. I am using a 2.6.32.9
kernel so it is not the latest but I wanted to ask if someone had any
idea where to look next before porting the latest onto our board.

Thanks,
  - Juha

--
Duck tape is like the force, it has a light side and a dark side and
it holds the universe together.
--
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 

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

[Santosh Shilimkar]

On 4/6/2011 3:52 AM, Linus Walleij wrote:

2011/4/5 Santosh Shilimkarsantosh.shilim...@ti.com:


The only issue I see is the clock-events implemented using
local timers capabilities in low power modes. The local timers
won't be able wakeup CPU from DORMANT or OFF state and hence
you will need an additional wakeup capable clock-event
working together with the local timers using clock-notifiers.


And this is because the IRQs it emits are local and thus cannot wake
the system? This sounds way backwards... A simple naïve solution
would have been to just route out an external IRQ line back from a
selected timer and into the GIC so it will be able to wake up the
system, right?


Even the GIC would be dead is certain low power modes. It's need
GIC extension to route these signals and seems that it's bit
tricky hardware implementation since the timer logic
needs to be moved to ALWAYS ON power domain.

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

[Santosh Shilimkar]

On 4/6/2011 3:46 AM, Linus Walleij wrote:

2011/4/5 Santosh Shilimkarsantosh.shilim...@ti.com:

[Me]

(And third it will also eventually need to hook into the timer-based
delay framework that I think Nokia is working on to be really
useful, else all delays become unpredictable.)


Do you mean udelay()/mdelay() here ?


Yes. Stephen Boyd from Qualcomm has floated patches to fix it for the
ARM architecture, I just pushed him again. We use it in our
ST-Ericsson products.


I remember the post.


Ideally you'd want that to go along with the A15 timer stuff so that this
monotonic high-precision timer is also used for udelay()/mdelay().


The A15 counter which is always available and running can be used
to emulate this.

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

[Bryan Wu]

On Wed, Apr 6, 2011 at 2:11 PM, Barry Song 21cn...@gmail.com wrote:
 2011/4/1 Arnd Bergmann a...@arndb.de:
 On Friday 01 April 2011, Ingo Molnar wrote:
 IMO the right answer is what Linus and Thomas outlined:

    1) provide a small number of clean examples and clean abstractions
    2) to not pull new crap from that point on
    3) do this gradually but consistently

 I.e. make all your requirements technical and actionable - avoid sweeping,
 impossible to meet requirements. Do not require people to clean up all of 
 the
 existing mess straight away (they cannot realistically do it), do not 
 summarily
 block the flow of patches, but be firm about drawing a line in the sand and 
 be
 firm about not introducing new mess in a gradually growing list of 
 well-chosen
 areas of focus.

 Rinse, repeat.

 I believe getting to point 1 is the hard part here. There are a lot of things
 that are wrong with the mach-* (and also plat-*) implementations, and I don't
 think we have one today that can really serve as an example. Most decisions
 made in there made a lot of sense when they were introduced, and declaring
 code that was perfectly acceptable yesterday to be unacceptable crap today
 is not going to be met with much understanding by the someone who just
 wants to add support for one more board to 100 already existing ones in the
 same SoC family.

 I would actually suggest a different much more radical start: Fork the way
 that platforms are managed today, and start an alternative way of setting
 up boards and devices together with the proven ARM core kernel 
 infrastructure,
 based on these observations (please correct me if some of them they don't 
 make
 sense):

 1. The core arch code is not a problem (Russell does a great job here)
 2. The platform specific code contains a lot of crap that doesn't belong 
 there
   (not enough reviewers to push back on crap)
 3. The amount of crap in platform specfic files is growing exponentially,
   despite the best efforts of a handful of people to clean it up.
 4. Having one source file per board does not scale any more.
 5. Discoverable hardware would solve this, but is not going to happen
   in practice.
 6. Board firmware would not solve this and is usually not present.
 7. Boot loaders can not be trusted to pass valid information
 8. Device tree blobs can solve a lot of the problems, and nobody has
   come up with a better solution.

 ARM BSP is still blasting! we are planning to merge our new ARM
 cortex-a9 SoC into kernel.

As far as I know, Barry is working on a new SoC family based on
Cortex-A9. He asked me/Eric personally before about this issue, it is
quite confused for new comers. On one hand, they wanna follow the
mainline style to join our upstream family, on the other hand if they
duplicate some crap from other SoC families, they will bring us
trouble or more crap.

 So I am just wondering whether traditional
 ARM BSP way can still be accepted, or we must move to use device tree?
 but i have't seen any arm device tree codes enter mainline yet. but we
 can get those patches from linaro 2.6.38. So what's the plan for
 merging arm device tree?


I suggest you need a dedicated guy who will work on DT supporting for
your SoC. As I can tell from this thread, DT will be heavily supported
by other SoC soon.

 What i have seen is that the BSP architecture of different ARM SoC
 companies is even different.

 samsung has three levels:
 plat-samsung
            plat-s3c24xx
                     mach-s3c2410
                     mach-s3c2440
            plat-s5p
                     mach-s5pv210
                     mach-s5pv310

 TI has two levels:
 plat-omap
            mach-omap1
            mach-omap2

 Nvidia has one level:
 mach-tegra

 I didn't find any rule about what codes should be placed in what
 directories. Different companies have different ways. It looks like
 the only agreement is board files are in mach-xxx. Any suggestions for
 that?


That's totally frustrated for a new comer, I think. It's that possible
we do more unification firstly and then allow new comers to follow,
like:
plat-common (or just named 'plat')- common plat-common framework for
all ARM based SoC, which might contains IRQ framework, GPIO, Timer,
Clock, PWM or other common things
SoC players just need add one file to enable the platform common
things on their SoC such as plat-omap.c, plat-imx.c, plat-samsung.c
and etc.

mach-'soc' - for machine or board related code, such as mach-omap,
mach-imx .., or maybe we can also introduce mach-common to share other
machine or board layer common code. I guess it will be some machine
related API common functions.

It's just a simple idea, we still need lots of work to make that happen.

Thanks,
-Bryan

 BTW, we don't want to dick around, which Linus has been very angry.
 we want to fix more issues this email pointed out before we send
 patches.

 9. All interesting work is going into a handful of platforms, all of which
   are ARMv7 based.
 10. 

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

[Catalin Marinas]

On Wed, 2011-04-06 at 00:19 +0100, Linus Walleij wrote:
 2011/4/1 Linus Torvalds torva...@linux-foundation.org:
 
  If you have discoverable hardware, use it.
 
  But by discoverable hardware I mean something like PCI config
  cycles. IOW, real hardware features.
 
 The ARM AMBA architecture actually has such a thing, or a
 little of it, found in drivers/amba/bus.c.
 
 Basically it requires you to get the physical address and size of
 each peripheral, then at offset -0x10 from the end address (usually
 at even 4K pages), if you find the magic number 0xB105F00D
 (ARM has a sense of humour, obviously) you can find something
 alike the PCI IDs at offset -0x20, manufacturer ID, version number
 and revision of the hardware.

I don't think this was ever part of the AMBA specification. It was just
some convention used within ARM for the PrimeCell peripherals. Other
AMBA licensees did something else so it's not a reliable mechanism (I
think ARM gave up on this as well in recent peripherals).

 IMO the world would have been much better off if
 ARM mandated that all vendors *must* use this scheme
 for their hardware blocks if they are to license the AMBA
 bus incarnations, but they don't.

As you said, it had limitations like not providing IRQ or DMA
information, so not entirely useful.

FDT may have its problems but so far is a more generic approach for
specifying such information.

-- 
Catalin


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

Re: [PATCH 0/4] iommu: Prevent oops in iommu_get() and while arch_iommu is in use

[Laurent Pinchart]

Hi David,

On Tuesday 05 April 2011 13:54:09 David Cohen wrote:
 On Tue, Apr 5, 2011 at 2:23 PM, Laurent Pinchart wrote:

[snip]

  We only have iommu2.ko at the moment. I've heard about an iommu1.ko being
  worked on, but I don't have more information. We don't know whether the
  OMAP5 will be able to use the same IOMMU implementation. Without more
  information, I'm quite reluctant to design and implement a generic
  solution that will end up being useless because we missed information in
  the design stage.
 
 One implementation belongs to mach-omap1 and other to mach-omap2. Not sure
 if it's a good plan to get them together.

My point is that we have a single implementation at the moment. Not one in 
mach-omap1 and one in mach-omap2, just one. I don't like solving problems with 
generic solutions when there's a single use case.

 IMO the third option from Laurent solves the issue for now and don't make it
 more difficult to implement a better standard to OMAP.

-- 
Regards,

Laurent Pinchart
--
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: OMAP4 DSS clock setup

[Tomi Valkeinen]

Paul, Benoit,

On Mon, 2011-04-04 at 09:53 +0300, Tomi Valkeinen wrote:
 Hi Paul, Benoit,
 
 On Fri, 2011-04-01 at 20:12 -0600, Paul Walmsley wrote:
 
  Based on the E-mail thread so far, I'd say that changing the clock aliases 
  is the way to go for right now.  The clock aliases are not hardware data; 
  they just control how the clock hardware is mapped to the drivers.
 
 I'd very much prefer this option. Below is a patch for this.
 
 If Benoit doesn't complain too much about this, I'd like to get this
 merged as soon as possible, as OMAP4 DSS is currently crashing in the
 mainline kernel.
 
 I can either handle it myself if I get your acks, or you can send a pull
 request for this if you have some other patches going in also.

Ping. Can I get an ack/nack from you for the patch below?

 Tomi

  Of course, at some point soon, those clock aliases are going to go away.  
  But hopefully you all will have converted the driver over to PM runtime at 
  that point.
  
  Once that happens, there's another problem: omap_hwmod_enable() is defined 
  that the hardware registers should be accessible by the MPU after it 
  completes.  So by that definition, the hwmod code should be 
  enabling/disabling that dss_clk clock too when it enables/idles/shuts down 
  the hwmod.  Probably we'd need to mark that struct omap_hwmod_opt_clk with 
  some flag.  Then we'd need some kind of way for the DSS to tell the hwmod 
  code whether it is or isn't reliant on the PRCM-provided functional clock 
  for its internal functional clock.  Maybe something like 
  omap_hwmod_{release,require}_system_fclk()?
 
 Hmm, right. I guess no other HW module has clock setups like this?
 
 Currently DSS can use clk_enable/disable() for the system fclk when its
 using DSI PLL for the fclk. So omap_hwmod_{release,require}_system_fclk
 sounds like a simple solution to this.
 
 Not directly related, but something I've been wondering about is how to
 abstract the DSI/HDMI PLLs in DSS. What do you think, would it be
 possible/worth it to create struct clks for the clocks coming out of
 those PLLs? These would, of course, be DSS internal clks. I'm not very
 familiar with the clock framework, so I don't really have any idea what
 this would require and what would be the pros and cons.
 
 ---
 
 From fceb48b2e22217dccc85b33362b6a17e5a00 Mon Sep 17 00:00:00 2001
 From: Tomi Valkeinen tomi.valkei...@ti.com
 Date: Mon, 4 Apr 2011 09:26:19 +0300
 Subject: [PATCH] OMAP4: clock data: Change DSS clock aliases
 
 DSS driver has used fck and ick clocks on OMAP2/3 to get DSS HW up and
 running, and also to get the pixel clock's source clock rate from the
 fck.
 
 On OMAP4 the clock data is set up in a different way, as there's no ick,
 dss_fck points to a fake clock which just affects DSS's MODULEMODE, and
 dss_dss_clk if the DSS_FCK.
 
 From DSS driver's point of view the dss_fck sounds like an ick, and
 dss_dss_clk is the fck. While this is not entirely correct from HW point
 of view, especially for the ick, configuring the clock aliases that way
 makes DSS just work with OMAP4's clock setup.
 
 In the (hopefully near) future DSS driver will be reworked to use
 pm_runtime support which should clean up the clock code.
 
 Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
 ---
  arch/arm/mach-omap2/clock44xx_data.c |9 ++---
  1 files changed, 2 insertions(+), 7 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/clock44xx_data.c 
 b/arch/arm/mach-omap2/clock44xx_data.c
 index 276992d..8c96567 100644
 --- a/arch/arm/mach-omap2/clock44xx_data.c
 +++ b/arch/arm/mach-omap2/clock44xx_data.c
 @@ -3116,14 +3116,9 @@ static struct omap_clk omap44xx_clks[] = {
   CLK(NULL,   dsp_fck,  dsp_fck,   
 CK_443X),
   CLK(omapdss_dss,  sys_clk,  dss_sys_clk,   
 CK_443X),
   CLK(omapdss_dss,  tv_clk,   dss_tv_clk,
 CK_443X),
 - CLK(omapdss_dss,  dss_clk,  dss_dss_clk,   
 CK_443X),
   CLK(omapdss_dss,  video_clk,dss_48mhz_clk, 
 CK_443X),
 - CLK(omapdss_dss,  fck,  dss_fck,   
 CK_443X),
 - /*
 -  * On OMAP4, DSS ick is a dummy clock; this is needed for compatibility
 -  * with OMAP2/3.
 -  */
 - CLK(omapdss_dss,  ick,  dummy_ck,  
 CK_443X),
 + CLK(omapdss_dss,  fck,  dss_dss_clk,   
 CK_443X),
 + CLK(omapdss_dss,  ick,  dss_fck,   
 CK_443X),
   CLK(NULL,   efuse_ctrl_cust_fck,  efuse_ctrl_cust_fck,   
 CK_443X),
   CLK(NULL,   emif1_fck,emif1_fck, 
 CK_443X),
   CLK(NULL,   emif2_fck,emif2_fck, 
 CK_443X),


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

What is missing from musb - linux-omap merge?

[Jarkko Nikula]

Hi

I've been trying to hunt why the OMAP3 retention on Nokia N900 went
broken in 2.6.39-rc and reason is somewhere around musb code merge with
linux-omap code or vise versa.

I bisected this into:

commit 0df0914d414a504b975f3cc66ace0c16ef55b7f3
Merge: 6899608 05f6894
Author: Linus Torvalds torva...@linux-foundation.org
Date:   Thu Mar 17 19:28:15 2011 -0700

Merge branch 'omap-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6

Yep, there were conflicts resolved by Linus but those didn't look that
they explain the problem.

So then I went to check the linux-omap branch omap-for-linus that got
pulled to vanilla. Top commit was:

commit 05f689400ea5fa3d71af82f910c8b140f87ad1f3
Merge: 17fe12c 02b7b94
Author: Tony Lindgren t...@atomide.com
Date:   Mon Mar 14 11:22:22 2011 -0700

Merge branches 'devel-mux' and 'devel-misc' into omap-for-linus

Here retention and usb networking are working so all were fine in
linux-omap in 2.6.38-rc7.

Then back to vanilla and checking the usb pull.

commit 971f115a50afbe409825c9f3399d5a3b9aca4381
Merge: 2e270d8 500132a
Author: Linus Torvalds torva...@linux-foundation.org
Date:   Wed Mar 16 15:04:26 2011 -0700

Merge branch 'usb-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6

Yes, musb doesn't compile here... trivial build fix attached as it's
not our interest now (but will bother all bisecters). Here retention
works but usb networking doesn't.

Then I went testing patches from linux-omap/omap-for-linus on top of
vanilla commit that precedes the omap-for-linus pull:

commit 6899608533410557e6698cb9d4ff6df553916e98
Merge: 411f5c7 92c260f
Author: Linus Torvalds torva...@linux-foundation.org
Date:   Thu Mar 17 19:13:18 2011 -0700

Merge branch 'for-linus' of
git://codeaurora.org/quic/kernel/davidb/linux-ms

Some amount of conflict resolving, mostly trivial, some testing and
came around these commits (note local commit ids):

commit 5cd15f0ba7594e4cd1dd01a100dc94013930a6a9
Author: Hema HK hem...@ti.com
Date:   Thu Feb 17 12:07:17 2011 +0530

OMAP2430: hwmod data: Add USBOTG

- Retention ok

commit 2d982bb2593ab64151c4a01758735e67d7db5d36
Author: Hema HK hem...@ti.com
Date:   Thu Feb 17 12:07:18 2011 +0530

OMAP3xxx: hwmod data: Add USBOTG

commit 6dc0c8ee8bdaac3ad11c4313431d8d7b3c886ede
Author: Hema HK hem...@ti.com
Date:   Thu Feb 17 12:07:19 2011 +0530

AM35xx: hwmod data: Add USBOTG
 
- These don't boot

commit 4bd3924ed10bef872e1fbfbb590fb7132df7dd4c
Author: Hema HK hem...@ti.com
Date:   Thu Feb 17 12:07:21 2011 +0530

OMAP2+: musb: hwmod adaptation for musb registration

- Boots, usb networking works and but no retention


Then arch/arm/mach-omap2 diff between

vanilla 0df0914d414a504b975f3cc66ace0c16ef55b7f3 (l-o pull)
and
l-o 05f689400ea5fa3d71af82f910c8b140f87ad1f3 (for linus)

doesn't show any suspicious to me. E.g. no differences in
omap_hwmod_3xxx_data.c and clock3xxx_data.c changes are just those
clock name changes that Linus complained. Rest seems to be unrelated.

 Kconfig|1 
 Makefile   |2 
 board-3430sdp.c|   10 
 board-3630sdp.c|   10 
 board-4430sdp.c|1 
 board-am3517crane.c|   10 
 board-am3517evm.c  |   12 
 board-cm-t35.c |   10 
 board-cm-t3517.c   |   10 
 board-devkit8000.c |   10 
 board-igep0020.c   |   10 
 board-igep0030.c   |   10 
 board-omap3beagle.c|   10 
 board-omap3evm.c   |   14 -
 board-omap3pandora.c   |   10 
 board-omap3stalker.c   |   10 
 board-omap3touchbook.c |   10 
 board-omap4panda.c |   11 
 board-overo.c  |   10 
 board-zoom.c   |   10 
 clock3xxx_data.c   |   19 +
 clock44xx_data.c   |   10 
 include/mach/board-zoom.h.orig |   11 
 include/mach/debug-macro.S |   13 
 omap4-common.c |7 
 omap_phy_internal.c|   29 +-
 pm.h   |2 
 sleep24xx.S|2 
 sleep34xx.S|2 
 sram242x.S |3 
 sram243x.S |3 
 sram34xx.S |1 
 usb-ehci.c |  522 -
 usb-host.c |  574 +
 usb-musb.c |3 
 35 files changed, 737 insertions(+), 645 deletions(-)

These findings made me thinking are there some patch or patchset
missing for musb as there are these musb build breakages and usb
networking not working in mainline issues, retention breaks only when
applying patches from linux-omap/omap-for-linus but what are ok in
linux-omap 2.6.38-rc7?

-- 
Jarkko
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 241fc94..5298949 100644
--- 

Re: What is missing from musb - linux-omap merge?

[Felipe Balbi]

Hi,

On Wed, Apr 06, 2011 at 04:23:34PM +0300, Jarkko Nikula wrote:
 Hi
 
 I've been trying to hunt why the OMAP3 retention on Nokia N900 went
 broken in 2.6.39-rc and reason is somewhere around musb code merge with
 linux-omap code or vise versa.
 
 I bisected this into:

I guess it's the missing Hema's patch which should be queued already.
Here it is:

commit 84cebd52a4b5d590af476869dc5b786fe567c095
Author: Hema HK hem...@ti.com
Date:   Thu Mar 17 16:11:58 2011 +0530

usb: musb: Fix for merge issue

There was conflict while merging 2 patches. Enabling vbus code
is wrongly moved to error check if loop.

This is a fix to resolve the merge issue.

Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 419ca3e..9ecb057 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1880,12 +1880,12 @@ int usb_gadget_probe_driver(struct usb_gadget_driver 
*driver,
if (retval  0) {
DBG(1, add_hcd failed, %d\n, retval);
goto err2;
-
-   if ((musb-xceiv-last_event == USB_EVENT_ID)
-musb-xceiv-set_vbus)
-   otg_set_vbus(musb-xceiv, 1);
}
 
+   if ((musb-xceiv-last_event == USB_EVENT_ID)
+musb-xceiv-set_vbus)
+   otg_set_vbus(musb-xceiv, 1);
+
hcd-self.uses_pio_for_control = 1;
 
if (musb-xceiv-last_event == USB_EVENT_NONE)


you might also need the one below:

commit ee262c660a855864efa78181cf7b7095b6416098
Author: Hema HK hem...@ti.com
Date:   Tue Mar 22 16:02:12 2011 +0530

usb: musb: Fix the crash issue during reboot

Below crash observed with commit 7acc6197b76edd0b932a7cbcc6cfad0a8a87f026
(usb: musb: Idle path retention and offmode support for OMAP3)
during board reboot.

The musb clock was disabled when musb_shutdown() was called by
platform_drv_shutdown in which there are register accesses.
call pm_runtime_get_sync() and pm_runtime_put_sync() in the
musb_shutdown function.

/ # [  172.368774] Unhandled fault: imprecise external abort (0x1406) at 
0x400f
[  172.376190] Internal error: : 1406 [#1] SMP
[  172.380554] last sysfs file: 
/sys/devices/platform/omap/omap_i2c.4/i2c-4/i2c-dev/i2c-4/dev
[  172.389221] Modules linked in:
[  172.392456] CPU: 0Tainted: GW(2.6.38-06671-geddecbb #33)
[  172.399475] PC is at do_raw_spin_unlock+0x50/0xc0
[  172.404418] LR is at _raw_spin_unlock_irqrestore+0x24/0x44
[  172.410186] pc : [c069bfdc]lr : [c085a7f8]psr: 6093
[  172.410186] sp : ee993e40  ip : c0d00240  fp : bea9cf14
[  172.422241] r10:   r9 : ee992000  r8 : c04b2fa8
[  172.427703] r7 :   r6 : c0fa46c0  r5 : ef966124  r4 : ef966124
[  172.434539] r3 : ef92cbc0  r2 : ef92cbc0  r1 :   r0 : ef966124
[  172.441406] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  
Segment user
[  172.448974] Control: 10c5387d  Table: ae8d804a  DAC: 0015
[  172.454986] Process init (pid: 1094, stack limit = 0xee9922f8)
[  172.461120] Stack: (0xee993e40 to 0xee994000)
[  172.465667] 3e40: a013 c085a7f8 ef966124 a013 c0fa46c0 c0761ab4 
c0761a70 ef95c008
[  172.474273] 3e60: ef95c014 c06e2fd0 c06e2fbc c06dea90  01234567 
28121969 c04fccb4
[  172.482849] 3e80:  c04fcd04 c0a302bc c04fce44 c0a02600 0001 
 c085cd04
[  172.491424] 3ea0:  0002 c09ea000 c085afc0 ee993f24  
00040001 0445
[  172.49] 3ec0: a8eb9d34 0027    c0a56a4c 
 
[  172.508575] 3ee0: 0002 6093  c0519aac 0002 0080 
 c0550420
[  172.517150] 3f00:  0002 ee97 c0a56a3c c0a56a20 0002 
c0a56a3c 
[  172.525726] 3f20: c0a56a3c 000a c1580e00 c0a56a20 0002 c0a56a3c 
c1580e00 c0a56a20
[  172.534301] 3f40: ef92cbc0 c05173a0 0001 ef92cbc0 c0576190 c04e3174 
2013 c0517324
[  172.542877] 3f60: ef815c00 ee90b720 c04e3174 c0576190 0001 ef92cbc0 
c04b2f00 
[  172.551483] 3f80: 0058 c0517324     
 
[  172.560058] 3fa0: 0058 c04b2de0   fee1dead 28121969 
01234567 
[  172.568634] 3fc0:    0058  0001 
400aa000 bea9cf14
[  172.577209] 3fe0: 000ea148 bea9c958 000aa750 40225728 6010 fee1dead 
 
[  172.585784] [c069bfdc] (do_raw_spin_unlock+0x50/0xc0) from 
[c085a7f8] (_raw_spin_unlock_irqrestore+0x24/0x44)
[  172.596588] [c085a7f8] (_raw_spin_unlock_irqrestore+0x24/0x44) 

Re: What is missing from musb - linux-omap merge?

[Jarkko Nikula]

On Wed, 6 Apr 2011 16:34:40 +0300
Felipe Balbi ba...@ti.com wrote:

 Hi,
 
 On Wed, Apr 06, 2011 at 04:23:34PM +0300, Jarkko Nikula wrote:
  Hi
  
  I've been trying to hunt why the OMAP3 retention on Nokia N900 went
  broken in 2.6.39-rc and reason is somewhere around musb code merge with
  linux-omap code or vise versa.
  
  I bisected this into:
 
 I guess it's the missing Hema's patch which should be queued already.
 Here it is:
 
 commit 84cebd52a4b5d590af476869dc5b786fe567c095
 Author: Hema HK hem...@ti.com
 Date:   Thu Mar 17 16:11:58 2011 +0530
 
 usb: musb: Fix for merge issue
 
Yeah, that was missing from the commits I was testing but it was in
where I started bisecting and where I noticed the retention issue so
this don't fix it.

 you might also need the one below:
 
 commit ee262c660a855864efa78181cf7b7095b6416098
 Author: Hema HK hem...@ti.com
 Date:   Tue Mar 22 16:02:12 2011 +0530
 
 usb: musb: Fix the crash issue during reboot
 
Applies fine to 2.6.39-rc2 but still doesn't fix the retention issue.

-- 
Jarkko
--
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: What is missing from musb - linux-omap merge?

[Kevin Hilman]

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

 On Wed, 6 Apr 2011 16:34:40 +0300
 Felipe Balbi ba...@ti.com wrote:

 Hi,
 
 On Wed, Apr 06, 2011 at 04:23:34PM +0300, Jarkko Nikula wrote:
  Hi
  
  I've been trying to hunt why the OMAP3 retention on Nokia N900 went
  broken in 2.6.39-rc and reason is somewhere around musb code merge with
  linux-omap code or vise versa.
  
  I bisected this into:
 
 I guess it's the missing Hema's patch which should be queued already.
 Here it is:
 
 commit 84cebd52a4b5d590af476869dc5b786fe567c095
 Author: Hema HK hem...@ti.com
 Date:   Thu Mar 17 16:11:58 2011 +0530
 
 usb: musb: Fix for merge issue
 
 Yeah, that was missing from the commits I was testing but it was in
 where I started bisecting and where I noticed the retention issue so
 this don't fix it.

 you might also need the one below:
 
 commit ee262c660a855864efa78181cf7b7095b6416098
 Author: Hema HK hem...@ti.com
 Date:   Tue Mar 22 16:02:12 2011 +0530
 
 usb: musb: Fix the crash issue during reboot
 
 Applies fine to 2.6.39-rc2 but still doesn't fix the retention issue.

Without actually trying this myself, what is likely affecting retention
is probably a missing (or failed) reset of the MUSB module.

Retention was also broken on several platforms before the MUSB cleanup 
hwmod conversion because the reset happens during hwmod init.  Because
most bootloaders are using MUSB, they often leave it in a state that
prevents idle (and thus retention), so a hwmod reset is the most
reliable way go get the IP into a known state.

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

[GIT PULL] OMAP PM fixes for 2.6.39-rc

[Kevin Hilman]

Tony,

Please pull the following OMAP PM fixes for the 2.6.39-rc fixes cycle.

Thanks,

Kevin

The following changes since commit 6221f222c0ebf1acdf7abcf927178f40e1a65e2a:

  Linux 2.6.39-rc2 (2011-04-05 18:30:43 -0700)

are available in the git repository at:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git 
for_2.6.39/pm-fixes

Aaro Koskinen (5):
  OMAP3+: smartreflex: fix sr_late_init() error path in probe
  OMAP3+: smartreflex: request the memory region
  OMAP3+: smartreflex: fix ioremap leak on probe error
  OMAP3+: smartreflex: delete instance from sr_list on probe error
  OMAP3+: smartreflex: delete debugfs entries on probe error

Nishanth Menon (3):
  OMAP3+: voltage: remove initial voltage
  OMAP3+: voltage: remove spurious pr_notice for debugfs
  OMAP4: PM: remove redundant #ifdef CONFIG_PM

Shweta Gulati (1):
  OMAP4: Intialize IVA Device in addition to DSP device.

 arch/arm/mach-omap2/pm.c  |1 +
 arch/arm/mach-omap2/pm44xx.c  |2 --
 arch/arm/mach-omap2/smartreflex.c |   23 ++-
 arch/arm/mach-omap2/voltage.c |2 --
 4 files changed, 19 insertions(+), 9 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

Re: [PATCH] OMAP2+: SR Layer Cleanup.

[Kevin Hilman]

Hi Shweta,

Shweta Gulati shweta.gul...@ti.com writes:

 As a part of Voltage Layer Cleanup Patches,
 submitted by Kevin Hilman, Voltage domain
 Information is removed from hwmod,
 So the patch removes 'vdd_name' info from omap_hwmod
 and adds that info into dev_attr as SR code uses vdd_name
 to get voltagedomain sructure info.

 Tested on OMAP3630 SDP and OMAP4430 SDP Board

 Signed-off-by: Shweta Gulati shweta.gul...@ti.com

Thanks for this.  It looks good.

 ---
 It apllies over Voltage Layer Cleanup Patch by
 Kevin Hilman: 
  https://patchwork.kernel.org/patch/657421/ 

Can you rebase on top of my pm-wip/voltdm_a branch?  It currently
doesn't apply there because the some of the voltage domain names were
changed, e.g. mpu - mpu_iva, wkup - wakeup.

Thanks,

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: mourning the loss of David Brownell

[Tony Lindgren]

* Jidong Xiao jidong.x...@gmail.com [110405 20:33]:
 
 Me too. David and the other developers you mentioned here helped me a
 lot. So sad, he is so young.

Dave certainly contributed a lot and helped many people. 
He also helped a lot with omap development.

Regards,

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

[PATCH/RFC 0/6] ARM: runtime PM: consolidate runtime PM implementations

[Kevin Hilman]

This series aims to consolidate OMAP and SH-mobile runtime PM
implementations around the new device power domains.

In 2.6.39, device power domains were added (commit
7538e3db6e015e890825fbd9f8659952896ddd5b, PM: add support for device
power domains).  In converting both OMAP and SH-mobile to use device
power domains, the overlap between implementations was almost 100%.  

To share the runtime PM implementation based on simple clock gating,
move it to arch/arm/common and initialize it from OMAP and SH-mobile.

Also, OMAP was the only user of platform_bus_set_pm_ops().  Now that
it has been converted to device power domains, remove
platform_bus_set_pm_ops().

Kevin Hilman (6):
  ARM: sh-mobile: runtime PM: convert to device powerdomains
  OMAP2+: PM: move runtime PM implementation to use device power
domains
  OMAP1: runtime PM: drop platform bus implementation
  ARM: move SH-mobile runtime PM to arm/common for sharing with other
platforms
  ARM: use common clock-based runtime PM implementation on SH-mobile 
OMAP1
  Revert driver core: platform_bus: allow runtime override of
dev_pm_ops

 arch/arm/common/Makefile|1 +
 arch/arm/common/pm_runtime_clock.c  |  176 +++
 arch/arm/include/asm/pm_runtime.h   |   17 
 arch/arm/mach-omap1/Makefile|2 +-
 arch/arm/mach-omap1/pm_bus.c|  100 
 arch/arm/mach-omap1/pm_runtime.c|   18 
 arch/arm/mach-omap2/Makefile|6 +-
 arch/arm/mach-omap2/pm_bus.c|   85 -
 arch/arm/mach-shmobile/pm_runtime.c |  152 +-
 arch/arm/plat-omap/omap_device.c|   22 +
 drivers/base/platform.c |   35 ---
 include/linux/platform_device.h |3 -
 12 files changed, 241 insertions(+), 376 deletions(-)
 create mode 100644 arch/arm/common/pm_runtime_clock.c
 create mode 100644 arch/arm/include/asm/pm_runtime.h
 delete mode 100644 arch/arm/mach-omap1/pm_bus.c
 create mode 100644 arch/arm/mach-omap1/pm_runtime.c
 delete mode 100644 arch/arm/mach-omap2/pm_bus.c

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

[PATCH/RFC 1/6] ARM: sh-mobile: runtime PM: convert to device powerdomains

[Kevin Hilman]

Remove the deprecated use of weak platform_bus symbols in favor of using
the new device power domains.

Cc: Magnus Damm d...@opensource.se
Cc: Paul Mundt let...@linux-sh.org
Signed-off-by: Kevin Hilman khil...@ti.com
---
 arch/arm/mach-shmobile/pm_runtime.c |   20 +++-
 1 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-shmobile/pm_runtime.c 
b/arch/arm/mach-shmobile/pm_runtime.c
index 94912d3..6c75c3f 100644
--- a/arch/arm/mach-shmobile/pm_runtime.c
+++ b/arch/arm/mach-shmobile/pm_runtime.c
@@ -66,7 +66,7 @@ static void platform_pm_runtime_bug(struct device *dev,
dev_err(dev, runtime pm suspend before resume\n);
 }
 
-int platform_pm_runtime_suspend(struct device *dev)
+static int platform_pm_runtime_suspend(struct device *dev)
 {
struct pm_runtime_data *prd = __to_prd(dev);
 
@@ -82,7 +82,7 @@ int platform_pm_runtime_suspend(struct device *dev)
return 0;
 }
 
-int platform_pm_runtime_resume(struct device *dev)
+static int platform_pm_runtime_resume(struct device *dev)
 {
struct pm_runtime_data *prd = __to_prd(dev);
 
@@ -98,12 +98,20 @@ int platform_pm_runtime_resume(struct device *dev)
return 0;
 }
 
-int platform_pm_runtime_idle(struct device *dev)
+static int platform_pm_runtime_idle(struct device *dev)
 {
/* suspend synchronously to disable clocks immediately */
return pm_runtime_suspend(dev);
 }
 
+static struct dev_power_domain platform_pm_power_domain = {
+   .ops = {
+   .runtime_suspend = platform_pm_runtime_suspend,
+   .runtime_resume = platform_pm_runtime_resume,
+   .runtime_idle = platform_pm_runtime_idle,
+   },
+};
+
 static int platform_bus_notify(struct notifier_block *nb,
   unsigned long action, void *data)
 {
@@ -114,10 +122,12 @@ static int platform_bus_notify(struct notifier_block *nb,
 
if (action == BUS_NOTIFY_BIND_DRIVER) {
prd = devres_alloc(__devres_release, sizeof(*prd), GFP_KERNEL);
-   if (prd)
+   if (prd) {
devres_add(dev, prd);
-   else
+   dev-pwr_domain = platform_pm_power_domain;
+   } else {
dev_err(dev, unable to alloc memory for runtime pm\n);
+   }
}
 
return 0;
-- 
1.7.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

[PATCH/RFC 5/6] ARM: use common clock-based runtime PM implementation on SH-mobile OMAP1

[Kevin Hilman]

Signed-off-by: Kevin Hilman khil...@ti.com
---
 arch/arm/mach-omap1/Makefile|2 +-
 arch/arm/mach-omap1/pm_runtime.c|   18 ++
 arch/arm/mach-shmobile/pm_runtime.c |   23 +++
 3 files changed, 42 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-omap1/pm_runtime.c
 create mode 100644 arch/arm/mach-shmobile/pm_runtime.c

diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index 1913c2d..04c60f9 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -11,7 +11,7 @@ obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
 obj-$(CONFIG_OMAP_32K_TIMER)   += timer32k.o
 
 # Power Management
-obj-$(CONFIG_PM) += pm.o sleep.o
+obj-$(CONFIG_PM) += pm.o sleep.o pm_runtime.o
 
 # DSP
 obj-$(CONFIG_OMAP_MBOX_FWK)+= mailbox_mach.o
diff --git a/arch/arm/mach-omap1/pm_runtime.c b/arch/arm/mach-omap1/pm_runtime.c
new file mode 100644
index 000..bbceb64
--- /dev/null
+++ b/arch/arm/mach-omap1/pm_runtime.c
@@ -0,0 +1,18 @@
+/*
+ * Runtime PM support code for TI OMAP1
+ *
+ *  Copyright (C) 2011 Texas Instruments, Inc.
+ *  Author: Kevin Hilman khil...@ti.com
+ *
+ */
+#include linux/kernel.h
+#include linux/init.h
+
+#include asm/pm_runtime.h
+
+static int __init omap1_pm_runtime_init(void)
+{
+   pm_runtime_clock_init();
+   return 0;
+}
+core_initcall(omap1_pm_runtime_init);
diff --git a/arch/arm/mach-shmobile/pm_runtime.c 
b/arch/arm/mach-shmobile/pm_runtime.c
new file mode 100644
index 000..edc0fa5
--- /dev/null
+++ b/arch/arm/mach-shmobile/pm_runtime.c
@@ -0,0 +1,23 @@
+/*
+ * arch/arm/mach-shmobile/pm_runtime.c
+ *
+ * Runtime PM support code for SuperH Mobile ARM
+ *
+ *  Copyright (C) 2009-2010 Magnus Damm
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file COPYING in the main directory of this archive
+ * for more details.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+
+#include asm/pm_runtime.h
+
+static int __init sh_pm_runtime_init(void)
+{
+   pm_runtime_clock_init();
+   return 0;
+}
+core_initcall(sh_pm_runtime_init);
-- 
1.7.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

[PATCH/RFC 6/6] Revert driver core: platform_bus: allow runtime override of dev_pm_ops

[Kevin Hilman]

This reverts commit c64a0926710153b9d44c979d2942f4a8648fd74e.

The platform_bus_set_pm_ops() is deprecated in favor of the new device
power domain infrastructre implemented in commit
7538e3db6e015e890825fbd9f8659952896ddd5b (PM: add support for device
power domains)

Signed-off-by: Kevin Hilman khil...@ti.com
---
 drivers/base/platform.c |   35 ---
 include/linux/platform_device.h |3 ---
 2 files changed, 0 insertions(+), 38 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index f051cff..46335ca 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -976,41 +976,6 @@ struct bus_type platform_bus_type = {
 };
 EXPORT_SYMBOL_GPL(platform_bus_type);
 
-/**
- * platform_bus_get_pm_ops() - return pointer to busses dev_pm_ops
- *
- * This function can be used by platform code to get the current
- * set of dev_pm_ops functions used by the platform_bus_type.
- */
-const struct dev_pm_ops * __init platform_bus_get_pm_ops(void)
-{
-   return platform_bus_type.pm;
-}
-
-/**
- * platform_bus_set_pm_ops() - update dev_pm_ops for the platform_bus_type
- *
- * @pm: pointer to new dev_pm_ops struct to be used for platform_bus_type
- *
- * Platform code can override the dev_pm_ops methods of
- * platform_bus_type by using this function.  It is expected that
- * platform code will first do a platform_bus_get_pm_ops(), then
- * kmemdup it, then customize selected methods and pass a pointer to
- * the new struct dev_pm_ops to this function.
- *
- * Since platform-specific code is customizing methods for *all*
- * devices (not just platform-specific devices) it is expected that
- * any custom overrides of these functions will keep existing behavior
- * and simply extend it.  For example, any customization of the
- * runtime PM methods should continue to call the pm_generic_*
- * functions as the default ones do in addition to the
- * platform-specific behavior.
- */
-void __init platform_bus_set_pm_ops(const struct dev_pm_ops *pm)
-{
-   platform_bus_type.pm = pm;
-}
-
 int __init platform_bus_init(void)
 {
int error;
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index d96db98..53745dc 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -145,9 +145,6 @@ extern struct platform_device 
*platform_create_bundle(struct platform_driver *dr
struct resource *res, unsigned int 
n_res,
const void *data, size_t size);
 
-extern const struct dev_pm_ops * platform_bus_get_pm_ops(void);
-extern void platform_bus_set_pm_ops(const struct dev_pm_ops *pm);
-
 /* early platform driver interface */
 struct early_platform_driver {
const char *class_str;
-- 
1.7.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

[PATCH/RFC 4/6] ARM: move SH-mobile runtime PM to arm/common for sharing with other platforms

[Kevin Hilman]

There is really nothing SH-mobile specific about this runtime PM
implementation.  Any platform wanting to implement runtime PM based on
simple clock gating can use this implementation.

Signed-off-by: Kevin Hilman khil...@ti.com
---
 arch/arm/common/Makefile|1 +
 arch/arm/common/pm_runtime_clock.c  |  176 ++
 arch/arm/include/asm/pm_runtime.h   |   17 
 arch/arm/mach-shmobile/pm_runtime.c |  179 ---
 4 files changed, 194 insertions(+), 179 deletions(-)
 create mode 100644 arch/arm/common/pm_runtime_clock.c
 create mode 100644 arch/arm/include/asm/pm_runtime.h
 delete mode 100644 arch/arm/mach-shmobile/pm_runtime.c

diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index e7521bca..efa79c7 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_ARCH_IXP23XX)+= uengine.o
 obj-$(CONFIG_PCI_HOST_ITE8152)  += it8152.o
 obj-$(CONFIG_COMMON_CLKDEV)+= clkdev.o
 obj-$(CONFIG_ARM_TIMER_SP804)  += timer-sp.o
+obj-$(CONFIG_PM_RUNTIME)   += pm_runtime_clock.o
diff --git a/arch/arm/common/pm_runtime_clock.c 
b/arch/arm/common/pm_runtime_clock.c
new file mode 100644
index 000..453fc95
--- /dev/null
+++ b/arch/arm/common/pm_runtime_clock.c
@@ -0,0 +1,176 @@
+/*
+ * Generic Runtime PM support code for managing device clocks
+ *
+ *  Copyright (C) 2009-2010 Magnus Damm
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file COPYING in the main directory of this archive
+ * for more details.
+ */
+
+#include linux/init.h
+#include linux/kernel.h
+#include linux/io.h
+#include linux/pm_runtime.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include linux/bitmap.h
+#include linux/err.h
+
+#ifdef CONFIG_PM_RUNTIME
+#define BIT_ONCE 0
+#define BIT_ACTIVE 1
+#define BIT_CLK_ENABLED 2
+
+struct pm_runtime_data {
+   unsigned long flags;
+   struct clk *clk;
+};
+
+static void __devres_release(struct device *dev, void *res)
+{
+   struct pm_runtime_data *prd = res;
+
+   dev_dbg(dev, __devres_release()\n);
+
+   if (test_bit(BIT_CLK_ENABLED, prd-flags))
+   clk_disable(prd-clk);
+
+   if (test_bit(BIT_ACTIVE, prd-flags))
+   clk_put(prd-clk);
+}
+
+static struct pm_runtime_data *__to_prd(struct device *dev)
+{
+   return devres_find(dev, __devres_release, NULL, NULL);
+}
+
+static void platform_pm_runtime_init(struct device *dev,
+struct pm_runtime_data *prd)
+{
+   if (prd  !test_and_set_bit(BIT_ONCE, prd-flags)) {
+   prd-clk = clk_get(dev, NULL);
+   if (!IS_ERR(prd-clk)) {
+   set_bit(BIT_ACTIVE, prd-flags);
+   dev_info(dev, clocks managed by runtime pm\n);
+   }
+   }
+}
+
+static void platform_pm_runtime_bug(struct device *dev,
+   struct pm_runtime_data *prd)
+{
+   if (prd  !test_and_set_bit(BIT_ONCE, prd-flags))
+   dev_err(dev, runtime pm suspend before resume\n);
+}
+
+static int platform_pm_runtime_suspend(struct device *dev)
+{
+   struct pm_runtime_data *prd = __to_prd(dev);
+
+   dev_dbg(dev, platform_pm_runtime_suspend()\n);
+
+   platform_pm_runtime_bug(dev, prd);
+
+   if (prd  test_bit(BIT_ACTIVE, prd-flags)) {
+   clk_disable(prd-clk);
+   clear_bit(BIT_CLK_ENABLED, prd-flags);
+   }
+
+   return 0;
+}
+
+static int platform_pm_runtime_resume(struct device *dev)
+{
+   struct pm_runtime_data *prd = __to_prd(dev);
+
+   dev_dbg(dev, platform_pm_runtime_resume()\n);
+
+   platform_pm_runtime_init(dev, prd);
+
+   if (prd  test_bit(BIT_ACTIVE, prd-flags)) {
+   clk_enable(prd-clk);
+   set_bit(BIT_CLK_ENABLED, prd-flags);
+   }
+
+   return 0;
+}
+
+static int platform_pm_runtime_idle(struct device *dev)
+{
+   /* suspend synchronously to disable clocks immediately */
+   return pm_runtime_suspend(dev);
+}
+
+static struct dev_power_domain platform_pm_power_domain = {
+   .ops = {
+   .runtime_suspend = platform_pm_runtime_suspend,
+   .runtime_resume = platform_pm_runtime_resume,
+   .runtime_idle = platform_pm_runtime_idle,
+   },
+};
+
+static int platform_bus_notify(struct notifier_block *nb,
+  unsigned long action, void *data)
+{
+   struct device *dev = data;
+   struct pm_runtime_data *prd;
+
+   dev_dbg(dev, platform_bus_notify() %ld !\n, action);
+
+   if (action == BUS_NOTIFY_BIND_DRIVER) {
+   prd = devres_alloc(__devres_release, sizeof(*prd), GFP_KERNEL);
+   if (prd) {
+   devres_add(dev, prd);
+   dev-pwr_domain = platform_pm_power_domain;
+   } else {
+   dev_err(dev, unable to 

[PATCH/RFC 3/6] OMAP1: runtime PM: drop platform bus implementation

[Kevin Hilman]

Current runtime PM implementation on OMAP1 is is based on a deprecated
interface: platform_bus_set_pm_ops().  Subsequent patch will convert
OMAP1 runtime PM to an implementation shared with SH-mobile, and based
on the new device power domain infrastructure in the common PM core.

Signed-off-by: Kevin Hilman khil...@ti.com
---
 arch/arm/mach-omap1/Makefile |2 +-
 arch/arm/mach-omap1/pm_bus.c |  100 --
 2 files changed, 1 insertions(+), 101 deletions(-)
 delete mode 100644 arch/arm/mach-omap1/pm_bus.c

diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index af98117..1913c2d 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -11,7 +11,7 @@ obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
 obj-$(CONFIG_OMAP_32K_TIMER)   += timer32k.o
 
 # Power Management
-obj-$(CONFIG_PM) += pm.o sleep.o pm_bus.o
+obj-$(CONFIG_PM) += pm.o sleep.o
 
 # DSP
 obj-$(CONFIG_OMAP_MBOX_FWK)+= mailbox_mach.o
diff --git a/arch/arm/mach-omap1/pm_bus.c b/arch/arm/mach-omap1/pm_bus.c
deleted file mode 100644
index 6588c22..000
--- a/arch/arm/mach-omap1/pm_bus.c
+++ /dev/null
@@ -1,100 +0,0 @@
-/*
- * Runtime PM support code for OMAP1
- *
- * Author: Kevin Hilman, Deep Root Systems, LLC
- *
- * Copyright (C) 2010 Texas Instruments, Inc.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed as is without any
- * warranty of any kind, whether express or implied.
- */
-#include linux/init.h
-#include linux/kernel.h
-#include linux/io.h
-#include linux/pm_runtime.h
-#include linux/platform_device.h
-#include linux/mutex.h
-#include linux/clk.h
-#include linux/err.h
-
-#include plat/omap_device.h
-#include plat/omap-pm.h
-
-#ifdef CONFIG_PM_RUNTIME
-static int omap1_pm_runtime_suspend(struct device *dev)
-{
-   struct clk *iclk, *fclk;
-   int ret = 0;
-
-   dev_dbg(dev, %s\n, __func__);
-
-   ret = pm_generic_runtime_suspend(dev);
-
-   fclk = clk_get(dev, fck);
-   if (!IS_ERR(fclk)) {
-   clk_disable(fclk);
-   clk_put(fclk);
-   }
-
-   iclk = clk_get(dev, ick);
-   if (!IS_ERR(iclk)) {
-   clk_disable(iclk);
-   clk_put(iclk);
-   }
-
-   return 0;
-};
-
-static int omap1_pm_runtime_resume(struct device *dev)
-{
-   struct clk *iclk, *fclk;
-
-   dev_dbg(dev, %s\n, __func__);
-
-   iclk = clk_get(dev, ick);
-   if (!IS_ERR(iclk)) {
-   clk_enable(iclk);
-   clk_put(iclk);
-   }
-
-   fclk = clk_get(dev, fck);
-   if (!IS_ERR(fclk)) {
-   clk_enable(fclk);
-   clk_put(fclk);
-   }
-
-   return pm_generic_runtime_resume(dev);
-};
-
-static int __init omap1_pm_runtime_init(void)
-{
-   const struct dev_pm_ops *pm;
-   struct dev_pm_ops *omap_pm;
-
-   if (!cpu_class_is_omap1())
-   return -ENODEV;
-
-   pm = platform_bus_get_pm_ops();
-   if (!pm) {
-   pr_err(%s: unable to get dev_pm_ops from platform_bus\n,
-   __func__);
-   return -ENODEV;
-   }
-
-   omap_pm = kmemdup(pm, sizeof(struct dev_pm_ops), GFP_KERNEL);
-   if (!omap_pm) {
-   pr_err(%s: unable to alloc memory for new dev_pm_ops\n,
-   __func__);
-   return -ENOMEM;
-   }
-
-   omap_pm-runtime_suspend = omap1_pm_runtime_suspend;
-   omap_pm-runtime_resume = omap1_pm_runtime_resume;
-
-   platform_bus_set_pm_ops(omap_pm);
-
-   return 0;
-}
-core_initcall(omap1_pm_runtime_init);
-#endif /* CONFIG_PM_RUNTIME */
-- 
1.7.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

[PATCH/RFC 2/6] OMAP2+: PM: move runtime PM implementation to use device power domains

[Kevin Hilman]

In commit 7538e3db6e015e890825fbd9f8659952896ddd5b (PM: add support
for device power domains) a better way for handling platform-specific
power hooks was introduced.

Rather than using the platform_bus dev_pm_ops overrides
(platform_bus_set_pm_ops()), this patch moves the OMAP runtime PM
implementation over to using device power domains.

Since OMAP is the only user of platform_bus_set_pm_ops(), that
interface can be removed (and will be in a forthcoming patch.)

Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Magnus Damm magnus.d...@gmail.com
Cc: Rafael J. Wysocki r...@sisk.pl
Signed-off-by: Kevin Hilman khil...@ti.com
---
 arch/arm/mach-omap2/Makefile |6 +-
 arch/arm/mach-omap2/pm_bus.c |   85 --
 arch/arm/plat-omap/omap_device.c |   22 ++
 3 files changed, 25 insertions(+), 88 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/pm_bus.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index a45cd64..b353584 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -59,10 +59,10 @@ endif
 # Power Management
 ifeq ($(CONFIG_PM),y)
 obj-$(CONFIG_ARCH_OMAP2)   += pm24xx.o
-obj-$(CONFIG_ARCH_OMAP2)   += sleep24xx.o pm_bus.o
+obj-$(CONFIG_ARCH_OMAP2)   += sleep24xx.o
 obj-$(CONFIG_ARCH_OMAP3)   += pm34xx.o sleep34xx.o \
-  cpuidle34xx.o pm_bus.o
-obj-$(CONFIG_ARCH_OMAP4)   += pm44xx.o pm_bus.o
+  cpuidle34xx.o
+obj-$(CONFIG_ARCH_OMAP4)   += pm44xx.o
 obj-$(CONFIG_PM_DEBUG) += pm-debug.o
 obj-$(CONFIG_OMAP_SMARTREFLEX)  += sr_device.o smartreflex.o
 obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3)  += smartreflex-class3.o
diff --git a/arch/arm/mach-omap2/pm_bus.c b/arch/arm/mach-omap2/pm_bus.c
deleted file mode 100644
index 5acd2ab..000
--- a/arch/arm/mach-omap2/pm_bus.c
+++ /dev/null
@@ -1,85 +0,0 @@
-/*
- * Runtime PM support code for OMAP
- *
- * Author: Kevin Hilman, Deep Root Systems, LLC
- *
- * Copyright (C) 2010 Texas Instruments, Inc.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed as is without any
- * warranty of any kind, whether express or implied.
- */
-#include linux/init.h
-#include linux/kernel.h
-#include linux/io.h
-#include linux/pm_runtime.h
-#include linux/platform_device.h
-#include linux/mutex.h
-
-#include plat/omap_device.h
-#include plat/omap-pm.h
-
-#ifdef CONFIG_PM_RUNTIME
-static int omap_pm_runtime_suspend(struct device *dev)
-{
-   struct platform_device *pdev = to_platform_device(dev);
-   int r, ret = 0;
-
-   dev_dbg(dev, %s\n, __func__);
-
-   ret = pm_generic_runtime_suspend(dev);
-
-   if (!ret  dev-parent == omap_device_parent) {
-   r = omap_device_idle(pdev);
-   WARN_ON(r);
-   }
-
-   return ret;
-};
-
-static int omap_pm_runtime_resume(struct device *dev)
-{
-   struct platform_device *pdev = to_platform_device(dev);
-   int r;
-
-   dev_dbg(dev, %s\n, __func__);
-
-   if (dev-parent == omap_device_parent) {
-   r = omap_device_enable(pdev);
-   WARN_ON(r);
-   }
-
-   return pm_generic_runtime_resume(dev);
-};
-#else
-#define omap_pm_runtime_suspend NULL
-#define omap_pm_runtime_resume NULL
-#endif /* CONFIG_PM_RUNTIME */
-
-static int __init omap_pm_runtime_init(void)
-{
-   const struct dev_pm_ops *pm;
-   struct dev_pm_ops *omap_pm;
-
-   pm = platform_bus_get_pm_ops();
-   if (!pm) {
-   pr_err(%s: unable to get dev_pm_ops from platform_bus\n,
-   __func__);
-   return -ENODEV;
-   }
-
-   omap_pm = kmemdup(pm, sizeof(struct dev_pm_ops), GFP_KERNEL);
-   if (!omap_pm) {
-   pr_err(%s: unable to alloc memory for new dev_pm_ops\n,
-   __func__);
-   return -ENOMEM;
-   }
-
-   omap_pm-runtime_suspend = omap_pm_runtime_suspend;
-   omap_pm-runtime_resume = omap_pm_runtime_resume;
-
-   platform_bus_set_pm_ops(omap_pm);
-
-   return 0;
-}
-core_initcall(omap_pm_runtime_init);
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 9bbda9a..93cd2fb 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -536,6 +536,27 @@ int omap_early_device_register(struct omap_device *od)
return 0;
 }
 
+static int _od_runtime_suspend(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+
+   return omap_device_idle(pdev);
+}
+
+static int _od_runtime_resume(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+
+   return omap_device_enable(pdev);
+}
+
+static struct dev_power_domain omap_device_power_domain = {
+   .ops = {
+   .runtime_suspend = 

Re: [PATCH v4 0/4] OMAP: DMA: mstandby mode and runtime pm support

[G, Manjunath Kondaiah]

Kevin/Paul,

On Mon, Mar 28, 2011 at 07:56:58PM +0530, G, Manjunath Kondaiah wrote:
 Patch series to support mstandby mode handling and enabling runtime PM
 support for DMA driver.
If you don't have further comments, can you pls ack these patches for
merging?

-Manjunath

[...]
--
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/4] TI816X: prcm: Add module and register offsets

[Pedanekar, Hemant]

Hello,

Pedanekar, Hemant wrote on Friday, March 25, 2011 9:50 PM:

 This patch adds PRCM register offsets for TI816X device as
 required for the
 clock data.

 Signed-off-by: Hemant Pedanekar hema...@ti.com
 ---
  arch/arm/mach-omap2/cm816x.h   |  228
 
  arch/arm/mach-omap2/prm2xxx_3xxx.h |   17 +++
  2 files changed, 245 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/mach-omap2/cm816x.h

 diff --git a/arch/arm/mach-omap2/cm816x.h
 b/arch/arm/mach-omap2/cm816x.h
 new file mode 100644
 index 000..b1dbd3d
 --- /dev/null
 +++ b/arch/arm/mach-omap2/cm816x.h
 @@ -0,0 +1,228 @@
 +/*
 + * TI816X CM register access macros. Also contains CM module offsets. + *
 + * Copyright (C) 2010 Texas Instruments, Inc. - http://www.ti.com/ + *
 + * This program is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU General Public License as
 + * published by the Free Software Foundation version 2. + *
 + * This program is distributed as is WITHOUT ANY WARRANTY of any
 + * kind, whether express or implied; without even the
 implied warranty
 + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + */
 +
 +#ifndef __ARCH_ARM_MACH_OMAP2_CM816X_H
 +#define __ARCH_ARM_MACH_OMAP2_CM816X_H
 +
 +#include prcm-common.h
 +
 +#define TI816X_CM_REGADDR(module, reg)
   \
 + OMAP2_L4_IO_ADDRESS(TI816X_PRCM_BASE + (module) + (reg)) +
 +/*
 + * TI816X CM module offsets
 + */
 +
 +#define TI816X_CM_DEVICE_MOD 0x0100  /* 256B */
 +#define TI816X_CM_DPLL_MOD   0x0300  /* 256B */
 +#define TI816X_CM_ACTIVE_MOD 0x0400  /* 256B */
 +#define TI816X_CM_DEFAULT_MOD0x0500
 /* 256B */
 +#define TI816X_CM_IVAHD0_MOD 0x0600  /* 256B */
 +#define TI816X_CM_IVAHD1_MOD 0x0700  /* 256B */
 +#define TI816X_CM_IVAHD2_MOD 0x0800  /* 256B */
 +#define TI816X_CM_SGX_MOD0x0900  /* 256B */
 +#define TI816X_CM_ALWON_MOD  0x1400  /* 1KB */
 +
 +/*
 + * Clock domain register offsets - these are generally
 CLKSTCTRL registers for
 + * respective modules.
 + */
 +
 +/* ALWON */
 +#define TI816X_CM_ALWON_MPU_CLKDM0x001C
 +#define TI816X_CM_ALWON_L3_SLOW_CLKDM0x
 +#define TI816X_CM_ETHERNET_CLKDM 0x0004
 +#define TI816X_CM_MMU_CLKDM  0x000C
 +#define TI816X_CM_MMUCFG_CLKDM   0x0010
 +
 +/* ACTIVE */
 +#define TI816X_CM_ACTIVE_GEM_CLKDM   0x
 +
 +/* IVAHD0 */
 +#define TI816X_CM_IVAHD0_CLKDM   0x
 +
 +/* IVAHD1 */
 +#define TI816X_CM_IVAHD1_CLKDM   0x
 +
 +/* IVAHD2 */
 +#define TI816X_CM_IVAHD2_CLKDM   0x
 +
 +/* SGX */
 +#define TI816X_CM_SGX_CLKDM  0x
 +
 +/* DEFAULT */
 +#define TI816X_CM_DEFAULT_L3_MED_CLKDM   0x0004
 +#define TI816X_CM_DEFAULT_DUCATI_CLKDM   0x0018
 +#define TI816X_CM_DEFAULT_PCI_CLKDM  0x0010
 +#define TI816X_CM_DEFAULT_L3_SLOW_CLKDM  0x0014
 +
 +/*
 + * CM register addresses
 + */
 +
 +/* CM_DPLL */
 +#define TI816X_CM_DPLL_SYSCLK1_CLKSEL
 TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x)
 +#define TI816X_CM_DPLL_SYSCLK2_CLKSEL
 TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0004)
 +#define TI816X_CM_DPLL_SYSCLK3_CLKSEL
 TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0008)
 +#define TI816X_CM_DPLL_SYSCLK4_CLKSEL
 TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x000C)
 +#define TI816X_CM_DPLL_SYSCLK5_CLKSEL
 TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0010)
 +#define TI816X_CM_DPLL_SYSCLK6_CLKSEL
 TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0014)
 +#define TI816X_CM_DPLL_SYSCLK7_CLKSEL
 TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0018)
 +#define TI816X_CM_DPLL_SYSCLK10_CLKSEL
 TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0024)
 +#define TI816X_CM_DPLL_SYSCLK11_CLKSEL
 TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x002C)
 +#define TI816X_CM_DPLL_SYSCLK12_CLKSEL
 TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0030)
 +#define TI816X_CM_DPLL_SYSCLK13_CLKSEL
 TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0034)
 +#define TI816X_CM_DPLL_SYSCLK15_CLKSEL
 TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0038)
 +#define TI816X_CM_DPLL_VPB3_CLKSEL
 TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0040)
 +#define TI816X_CM_DPLL_VPC1_CLKSEL
 TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0044)
 +#define TI816X_CM_DPLL_VPD1_CLKSEL
 TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0048)
 +#define TI816X_CM_DPLL_SYSCLK19_CLKSEL
 TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x004C)
 +#define TI816X_CM_DPLL_SYSCLK20_CLKSEL
 TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0050)
 +#define TI816X_CM_DPLL_SYSCLK21_CLKSEL
 TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0054)
 +#define TI816X_CM_DPLL_SYSCLK22_CLKSEL
 TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0058)
 +#define TI816X_CM_DPLL_APA_CLKSEL
 TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 

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

[Arnd Bergmann]

On Wednesday 06 April 2011, Catalin Marinas wrote:
 On Wed, 2011-04-06 at 00:19 +0100, Linus Walleij wrote:
  2011/4/1 Linus Torvalds torva...@linux-foundation.org:
  Basically it requires you to get the physical address and size of
  each peripheral, then at offset -0x10 from the end address (usually
  at even 4K pages), if you find the magic number 0xB105F00D
  (ARM has a sense of humour, obviously) you can find something
  alike the PCI IDs at offset -0x20, manufacturer ID, version number
  and revision of the hardware.
 
 I don't think this was ever part of the AMBA specification. It was just
 some convention used within ARM for the PrimeCell peripherals. Other
 AMBA licensees did something else so it's not a reliable mechanism (I
 think ARM gave up on this as well in recent peripherals).

Do you think there is a way to get ARM ltd to make a better effort
at this with a future specification? I suppose it would be extremely
helpful if there was a way to specify more of the required information,
and to require everybody to fill in correct data, in the same way that
architecture compliance gets enforced on the CPU core.

Arnd
--
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: Issue with DSS DSI: Complex IO not powering on

[Juha Kuikka]

On Tue, Apr 5, 2011 at 11:16 PM, Archit Taneja arc...@ti.com wrote:
 Hi,

 On Wednesday 06 April 2011 07:25 AM, Juha Kuikka wrote:

 Hi,
 I am working on a custom board with DM3730 and a DSI panel and I have
 a problem in powering on the DSI complex IO block.

 The DSS DSI initialization fails with:
 omapdss DSI: dsi_complexio_init
 omapdss DSI error: complexio reset not done!-- my own addition
 omapdss DSI error: failed to set complexio power state to 1

 Can you check if the necessary pad/pin-muxing has been done for the DSI
 lanes?

Thank you for the advice! Turns out they were not. After configuring
them the DSI powers on correctly.

Unfortunately I ran into another issue, it seems that dispc is not
giving us FRAMEDONE interrupt, currently investigating why.

Any input is appreciated.

Clocking:
omapdss DSI: PLL init
omapdss DSI: PLL init done
omapdss DSI: dsi_pll_set_clock_div()
omapdss DSI: DSI Fint 200
omapdss DSI: clkin (dss2_fck) rate 2600, highfreq 0
omapdss DSI: CLKIN4DDR = 2 * 180 / 13 * 2600 / 1 = 72000
omapdss DSI: Data rate on 1 DSI lane 360 Mbps
omapdss DSI: Clock lane freq 18000 Hz
omapdss DSI: regm3 = 8, dsi1_pll_fclk = 9000
omapdss DSI: regm4 = 8, dsi2_pll_fclk = 9000
omapdss DSI: PLL config done
omapdss DSI: PLL OK
omapdss DISPC: lck = 9000 (1)
omapdss DISPC: pck = 3000 (3)

DISPC is using DSI_DPLL1 as fclk.

Logs:
mapdss MANAGER: omap_dss_mgr_apply(lcd)
omapdss OVERLAY: check_overlay 0: (0,0 480x800 - 0x800) disp (480x800)
omapdss MANAGER: configure_overlay(0)
omapdss DISPC: dispc_setup_plane 0, pa 8143, sw 480, 0,0, 480x800
- 480x800, ilace 0, cmode 40, rot 0, mir 0 flicker_filter 0
omapdss DISPC: calc_rot(0): scrw 480, 480x800
omapdss DISPC: offset0 0, offset1 0, row_inc 1, pix_inc 1
omapdss DISPC: 0,0 480x800 - 480x800
omapdss DISPC: vid[0] attributes = c
omapdss DISPC: fifo(0) low/high old 960/1023, new 512/960
omapdss DISPC: dispc_enable_plane 0, 1
omapdss DSI: starting auto update
omapdss DSI: dsi_display_enable_te(0)
omapdss DSI: dsi_display_set_update_mode(2)
dsi_display_update lcd_ix=0
omapdss DSI: dsi_display_update(0,0 480x800)
omapdss MANAGER: dispc_setup_partial_planes 0,0 480x800
omapdss MANAGER: configure_overlay(0)
omapdss DISPC: dispc_setup_plane 0, pa 8143, sw 480, 0,0, 480x800
- 480x800, ilace 0, cmode 40, rot 0, mir 0 flicker_filter 0
omapdss DISPC: calc_rot(0): scrw 480, 480x800
omapdss DISPC: offset0 0, offset1 0, row_inc 1, pix_inc 1
omapdss DISPC: 0,0 480x800 - 480x800
omapdss DISPC: vid[0] attributes = ad
omapdss DISPC: fifo(0) low/high old 512/960, new 512/960
omapdss DISPC: dispc_enable_plane 0, 1
omapdss MANAGER: configure_overlay(1)
omapdss DISPC: dispc_enable_plane 1, 0
omapdss MANAGER: configure_overlay(2)
omapdss DISPC: dispc_enable_plane 2, 0
omapdss MANAGER: configure_manager(0)
omapdss DSI: dsi_vc_config_vp(0)
omapdss DSI: dsi_vc_enable channel 0, enable 0
omapdss DSI: dsi_vc_enable channel 0, enable 1
omapdss DSI: dsi_update_screen_dispc(0,0 480x800)
omapdss DSI: dsi_display_enable_te(0)
omapdss DSI: dsi_display_set_update_mode(2)
omapdss DSI error: framedone timeout
omapdss DSI error: failed update 0,0 480x800
omapdss DISPC error: timeout waiting for FRAME DONE

 - Juha


 Archit

 The DSI PLL is used and configured according to the example values in
 the TRM (not proper for our panel but they should enable the complex
 IO to at least power on, right).

 Output form DSS DEBUG:
 omapdss DSI: LP_CLK_DIV 6, LP_CLK 750
 omapdss DISPC: lck = 9000 (1)
 omapdss DISPC: pck = 3000 (3)
 - DSI PLL -
 dsi pll source = dss2_alwon_fclk
 Fint 200         regn 13
 CLKIN4DDR 108000      regm 270
 dsi1_pll_fck 9000        regm3 12 (on)
 dsi2_pll_fck 9000        regm4 12 (on)
 - DSI -
 dsi fclk source = dsi2_pll_fclk
 DSI_FCLK 9000
 DDR_CLK 27000
 TxByteClkHS 6750
 LP_CLK 750
 VP_CLK 9000
 VP_PCLK 3000

 As far as I can tell these values fill all the requirements set in the
 TRM for clock rates and their ratios.

 After the fail in dsi_complexio_init I dump all registers:

 DSI_REVISION                        0010
 DSI_SYSCONFIG                       0011
 DSI_SYSSTATUS                       0001
 DSI_IRQSTATUS                       00080080
 DSI_IRQENABLE                       
 DSI_CTRL                            0100
 DSI_COMPLEXIO_CFG1                  48200321
 DSI_COMPLEXIO_IRQ_STATUS            
 DSI_COMPLEXIO_IRQ_ENABLE            
 DSI_CLK_CTRL                        a0304006
 DSI_TIMING1                         7fff7fff
 DSI_TIMING2                         7fff7fff
 DSI_VM_TIMING1                      
 DSI_VM_TIMING2                      
 DSI_VM_TIMING3                      
 DSI_CLK_TIMING                      0101
 DSI_TX_FIFO_VC_SIZE                 
 DSI_RX_FIFO_VC_SIZE                 
 DSI_COMPLEXIO_CFG2                  
 DSI_RX_FIFO_VC_FULLNESS             

FINANCIAL LENDER

[Ronald C. Foster]

establish your finance with our offer  financial lending amount 
we are financial lender via we give out financial amount
which ranges from $5,000.00 to $100,000,000.00 at 2.5%,and also 
we cover all insurance measures for the financial amount you 
will be lending as our lending process is urgent and effective 
as due to your compliance with the lending process.

info details needed:
a.amount
b.duration time
c.full address contact details
d.direct phone number
contact:
operations manager
mr ronald.c.foster
zenith home lender inc.
zenithfinhlronaldfos...@gmail.com 





Sent via the WebMail system at meckcom.net


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

FINANCIAL LENDER

[Ronald C. Foster]

establish your finance with our offer  financial lending amount 
we are financial lender via we give out financial amount
which ranges from $5,000.00 to $100,000,000.00 at 2.5%,and also 
we cover all insurance measures for the financial amount you 
will be lending as our lending process is urgent and effective 
as due to your compliance with the lending process.

info details needed:
a.amount
b.duration time
c.full address contact details
d.direct phone number
contact:
operations manager
mr ronald.c.foster
zenith home lender inc.
zenithfinhlronaldfos...@gmail.com 





Sent via the WebMail system at meckcom.net


 
   
--
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/RFC 0/6] ARM: runtime PM: consolidate runtime PM implementations

[Rafael J. Wysocki]

On Thursday, April 07, 2011, Kevin Hilman wrote:
 This series aims to consolidate OMAP and SH-mobile runtime PM
 implementations around the new device power domains.
 
 In 2.6.39, device power domains were added (commit
 7538e3db6e015e890825fbd9f8659952896ddd5b, PM: add support for device
 power domains).  In converting both OMAP and SH-mobile to use device
 power domains, the overlap between implementations was almost 100%.  
 
 To share the runtime PM implementation based on simple clock gating,
 move it to arch/arm/common and initialize it from OMAP and SH-mobile.
 
 Also, OMAP was the only user of platform_bus_set_pm_ops().  Now that
 it has been converted to device power domains, remove
 platform_bus_set_pm_ops().

Please, don't do it this way.

First, we'll still need platform_bus_set_pm_ops() on shmobile and the reason
is that we want to override the platform bus type PM ops for _all_ devices on
that platform, which power domains are not really suitable for.

Second, we're going to introduce code for handling real power domains for
shmobile that would conflict with the way you're using power domains for
overriding the default PM ops.

Besides, the way you've used power domains appears to assume that drivers
will not define their own runtime PM callbacks, because if they do, those
callbacks will be called _in_ _addition_ to the power domain callbacks you're
trying to add (from the default platform bus type callbacks).

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

Re: Issue with DSS DSI: Complex IO not powering on

[Archit Taneja]

Hi,

On Thursday 07 April 2011 08:19 AM, Juha Kuikka wrote:

On Tue, Apr 5, 2011 at 11:16 PM, Archit Tanejaarc...@ti.com  wrote:

Hi,

On Wednesday 06 April 2011 07:25 AM, Juha Kuikka wrote:


Hi,
I am working on a custom board with DM3730 and a DSI panel and I have
a problem in powering on the DSI complex IO block.

The DSS DSI initialization fails with:
omapdss DSI: dsi_complexio_init
omapdss DSI error: complexio reset not done!-- my own addition
omapdss DSI error: failed to set complexio power state to 1


Can you check if the necessary pad/pin-muxing has been done for the DSI
lanes?


Thank you for the advice! Turns out they were not. After configuring
them the DSI powers on correctly.

Unfortunately I ran into another issue, it seems that dispc is not
giving us FRAMEDONE interrupt, currently investigating why.

Any input is appreciated.


A couple of questions:

It is a command mode or video mode panel?
Are other commands to the panel going through successfully?
Could you point to the kernel source you are using?



Clocking:
omapdss DSI: PLL init
omapdss DSI: PLL init done
omapdss DSI: dsi_pll_set_clock_div()
omapdss DSI: DSI Fint 200
omapdss DSI: clkin (dss2_fck) rate 2600, highfreq 0
omapdss DSI: CLKIN4DDR = 2 * 180 / 13 * 2600 / 1 = 72000
omapdss DSI: Data rate on 1 DSI lane 360 Mbps
omapdss DSI: Clock lane freq 18000 Hz
omapdss DSI: regm3 = 8, dsi1_pll_fclk = 9000
omapdss DSI: regm4 = 8, dsi2_pll_fclk = 9000
omapdss DSI: PLL config done
omapdss DSI: PLL OK
omapdss DISPC: lck = 9000 (1)
omapdss DISPC: pck = 3000 (3)



90 Mhz for DISPC and DSI FCLK seems to be a bit low, you may want to 
increase that.


Archit


DISPC is using DSI_DPLL1 as fclk.

Logs:
mapdss MANAGER: omap_dss_mgr_apply(lcd)
omapdss OVERLAY: check_overlay 0: (0,0 480x800 -  0x800) disp (480x800)
omapdss MANAGER: configure_overlay(0)
omapdss DISPC: dispc_setup_plane 0, pa 8143, sw 480, 0,0, 480x800
-  480x800, ilace 0, cmode 40, rot 0, mir 0 flicker_filter 0
omapdss DISPC: calc_rot(0): scrw 480, 480x800
omapdss DISPC: offset0 0, offset1 0, row_inc 1, pix_inc 1
omapdss DISPC: 0,0 480x800 -  480x800
omapdss DISPC: vid[0] attributes = c
omapdss DISPC: fifo(0) low/high old 960/1023, new 512/960
omapdss DISPC: dispc_enable_plane 0, 1
omapdss DSI: starting auto update
omapdss DSI: dsi_display_enable_te(0)
omapdss DSI: dsi_display_set_update_mode(2)
dsi_display_update lcd_ix=0
omapdss DSI: dsi_display_update(0,0 480x800)
omapdss MANAGER: dispc_setup_partial_planes 0,0 480x800
omapdss MANAGER: configure_overlay(0)
omapdss DISPC: dispc_setup_plane 0, pa 8143, sw 480, 0,0, 480x800
-  480x800, ilace 0, cmode 40, rot 0, mir 0 flicker_filter 0
omapdss DISPC: calc_rot(0): scrw 480, 480x800
omapdss DISPC: offset0 0, offset1 0, row_inc 1, pix_inc 1
omapdss DISPC: 0,0 480x800 -  480x800
omapdss DISPC: vid[0] attributes = ad
omapdss DISPC: fifo(0) low/high old 512/960, new 512/960
omapdss DISPC: dispc_enable_plane 0, 1
omapdss MANAGER: configure_overlay(1)
omapdss DISPC: dispc_enable_plane 1, 0
omapdss MANAGER: configure_overlay(2)
omapdss DISPC: dispc_enable_plane 2, 0
omapdss MANAGER: configure_manager(0)
omapdss DSI: dsi_vc_config_vp(0)
omapdss DSI: dsi_vc_enable channel 0, enable 0
omapdss DSI: dsi_vc_enable channel 0, enable 1
omapdss DSI: dsi_update_screen_dispc(0,0 480x800)
omapdss DSI: dsi_display_enable_te(0)
omapdss DSI: dsi_display_set_update_mode(2)
omapdss DSI error: framedone timeout
omapdss DSI error: failed update 0,0 480x800
omapdss DISPC error: timeout waiting for FRAME DONE

  - Juha



Archit


The DSI PLL is used and configured according to the example values in
the TRM (not proper for our panel but they should enable the complex
IO to at least power on, right).

Output form DSS DEBUG:
omapdss DSI: LP_CLK_DIV 6, LP_CLK 750
omapdss DISPC: lck = 9000 (1)
omapdss DISPC: pck = 3000 (3)
- DSI PLL -
dsi pll source = dss2_alwon_fclk
Fint 200 regn 13
CLKIN4DDR 108000  regm 270
dsi1_pll_fck 9000regm3 12 (on)
dsi2_pll_fck 9000regm4 12 (on)
- DSI -
dsi fclk source = dsi2_pll_fclk
DSI_FCLK 9000
DDR_CLK 27000
TxByteClkHS 6750
LP_CLK 750
VP_CLK 9000
VP_PCLK 3000

As far as I can tell these values fill all the requirements set in the
TRM for clock rates and their ratios.

After the fail in dsi_complexio_init I dump all registers:

DSI_REVISION0010
DSI_SYSCONFIG   0011
DSI_SYSSTATUS   0001
DSI_IRQSTATUS   00080080
DSI_IRQENABLE   
DSI_CTRL0100
DSI_COMPLEXIO_CFG1  48200321
DSI_COMPLEXIO_IRQ_STATUS
DSI_COMPLEXIO_IRQ_ENABLE
DSI_CLK_CTRLa0304006
DSI_TIMING1 7fff7fff
DSI_TIMING2 7fff7fff
DSI_VM_TIMING1  
DSI_VM_TIMING2 

Re: [PATCH/RFC 2/6] OMAP2+: PM: move runtime PM implementation to use device power domains

[Grant Likely]

On Wed, Apr 06, 2011 at 05:02:45PM -0700, Kevin Hilman wrote:
 In commit 7538e3db6e015e890825fbd9f8659952896ddd5b (PM: add support
 for device power domains) a better way for handling platform-specific
 power hooks was introduced.
 
 Rather than using the platform_bus dev_pm_ops overrides
 (platform_bus_set_pm_ops()), this patch moves the OMAP runtime PM
 implementation over to using device power domains.
 
 Since OMAP is the only user of platform_bus_set_pm_ops(), that
 interface can be removed (and will be in a forthcoming patch.)
 
 Cc: Grant Likely grant.lik...@secretlab.ca
 Cc: Magnus Damm magnus.d...@gmail.com
 Cc: Rafael J. Wysocki r...@sisk.pl
 Signed-off-by: Kevin Hilman khil...@ti.com

Looks right to me.

Reviewed-by: Grant Likely grant.lik...@secretlab.ca

 ---
  arch/arm/mach-omap2/Makefile |6 +-
  arch/arm/mach-omap2/pm_bus.c |   85 
 --
  arch/arm/plat-omap/omap_device.c |   22 ++
  3 files changed, 25 insertions(+), 88 deletions(-)
  delete mode 100644 arch/arm/mach-omap2/pm_bus.c
 
 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
 index a45cd64..b353584 100644
 --- a/arch/arm/mach-omap2/Makefile
 +++ b/arch/arm/mach-omap2/Makefile
 @@ -59,10 +59,10 @@ endif
  # Power Management
  ifeq ($(CONFIG_PM),y)
  obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
 -obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o pm_bus.o
 +obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
  obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o \
 -cpuidle34xx.o pm_bus.o
 -obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o pm_bus.o
 +cpuidle34xx.o
 +obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o
  obj-$(CONFIG_PM_DEBUG)   += pm-debug.o
  obj-$(CONFIG_OMAP_SMARTREFLEX)  += sr_device.o smartreflex.o
  obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3)+= smartreflex-class3.o
 diff --git a/arch/arm/mach-omap2/pm_bus.c b/arch/arm/mach-omap2/pm_bus.c
 deleted file mode 100644
 index 5acd2ab..000
 --- a/arch/arm/mach-omap2/pm_bus.c
 +++ /dev/null
 @@ -1,85 +0,0 @@
 -/*
 - * Runtime PM support code for OMAP
 - *
 - * Author: Kevin Hilman, Deep Root Systems, LLC
 - *
 - * Copyright (C) 2010 Texas Instruments, Inc.
 - *
 - * This file is licensed under the terms of the GNU General Public
 - * License version 2. This program is licensed as is without any
 - * warranty of any kind, whether express or implied.
 - */
 -#include linux/init.h
 -#include linux/kernel.h
 -#include linux/io.h
 -#include linux/pm_runtime.h
 -#include linux/platform_device.h
 -#include linux/mutex.h
 -
 -#include plat/omap_device.h
 -#include plat/omap-pm.h
 -
 -#ifdef CONFIG_PM_RUNTIME
 -static int omap_pm_runtime_suspend(struct device *dev)
 -{
 - struct platform_device *pdev = to_platform_device(dev);
 - int r, ret = 0;
 -
 - dev_dbg(dev, %s\n, __func__);
 -
 - ret = pm_generic_runtime_suspend(dev);
 -
 - if (!ret  dev-parent == omap_device_parent) {
 - r = omap_device_idle(pdev);
 - WARN_ON(r);
 - }
 -
 - return ret;
 -};
 -
 -static int omap_pm_runtime_resume(struct device *dev)
 -{
 - struct platform_device *pdev = to_platform_device(dev);
 - int r;
 -
 - dev_dbg(dev, %s\n, __func__);
 -
 - if (dev-parent == omap_device_parent) {
 - r = omap_device_enable(pdev);
 - WARN_ON(r);
 - }
 -
 - return pm_generic_runtime_resume(dev);
 -};
 -#else
 -#define omap_pm_runtime_suspend NULL
 -#define omap_pm_runtime_resume NULL
 -#endif /* CONFIG_PM_RUNTIME */
 -
 -static int __init omap_pm_runtime_init(void)
 -{
 - const struct dev_pm_ops *pm;
 - struct dev_pm_ops *omap_pm;
 -
 - pm = platform_bus_get_pm_ops();
 - if (!pm) {
 - pr_err(%s: unable to get dev_pm_ops from platform_bus\n,
 - __func__);
 - return -ENODEV;
 - }
 -
 - omap_pm = kmemdup(pm, sizeof(struct dev_pm_ops), GFP_KERNEL);
 - if (!omap_pm) {
 - pr_err(%s: unable to alloc memory for new dev_pm_ops\n,
 - __func__);
 - return -ENOMEM;
 - }
 -
 - omap_pm-runtime_suspend = omap_pm_runtime_suspend;
 - omap_pm-runtime_resume = omap_pm_runtime_resume;
 -
 - platform_bus_set_pm_ops(omap_pm);
 -
 - return 0;
 -}
 -core_initcall(omap_pm_runtime_init);
 diff --git a/arch/arm/plat-omap/omap_device.c 
 b/arch/arm/plat-omap/omap_device.c
 index 9bbda9a..93cd2fb 100644
 --- a/arch/arm/plat-omap/omap_device.c
 +++ b/arch/arm/plat-omap/omap_device.c
 @@ -536,6 +536,27 @@ int omap_early_device_register(struct omap_device *od)
   return 0;
  }
  
 +static int _od_runtime_suspend(struct device *dev)
 +{
 + struct platform_device *pdev = to_platform_device(dev);
 +
 + return omap_device_idle(pdev);
 +}
 +
 +static int _od_runtime_resume(struct device *dev)
 +{
 + struct