date:20101124

On Wed, Nov 24, 2010 at 12:53, Axel Lin axel@gmail.com wrote:

Add Patch description.

 Signed-off-by: Axel Lin axel@gmail.com
 ---
  sound/soc/omap/osk5912.c |   11 ---
  1 files changed, 8 insertions(+), 3 deletions(-)

 diff --git a/sound/soc/omap/osk5912.c b/sound/soc/omap/osk5912.c
 index 18d053d..7e75e77 100644
 --- a/sound/soc/omap/osk5912.c
 +++ b/sound/soc/omap/osk5912.c

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] OMAP: ZOOM2: Change GPIO to enable LCD NEC NL8048HL11-01B on OMAP34x-II MDP

2010-11-24 Thread Tomi Valkeinen

Hi,

On Tue, 2010-11-23 at 19:00 -0600, ext Omar Ramirez Luna wrote:
 From: Yanick Saugy yanick.sa...@heig-vd.ch
 
 The PIN which controls LCD's reset signal (VGA_nRESET/h_GPIO_96) was not
 configured as a GPIO. We had to modify the OMAP MUX, and select this PIN
 (CAM_XCLKA) as an output GPIO (OMAP_MUX_MODE4). (kernel 2.6.35)
 
 Be aware of changing this PIN will probably disable the camera, because
 it was previously configured as a camera clock.
 
 Signed-off-by: Yanick Saugy yanick.sa...@heig-vd.ch
 Acked-by: Tony Lindgren t...@atomide.com
 Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
 ---
 
 I'm not sure if this patch was forgotten, hence resending. Without
 it, a blanks screen is seen on zoom2 board.

Yes, I seem to have missed this.

But I'm a bit confused. You say that this will disable camera. Is there
a camera connected to the board, and it won't work after this? 

 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

Re: [PATCH v4 2/5] OMAP: mailbox: fix rx interrupt disable in omap4

On Wed, Nov 24, 2010 at 13:52, Felipe Balbi ba...@ti.com wrote:
 On Wed, Nov 24, 2010 at 10:46:04AM +0530, Varadarajan, Charulatha wrote:

 diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
 index 48e161c..a1c6bd9 100644
 --- a/arch/arm/plat-omap/mailbox.c
 +++ b/arch/arm/plat-omap/mailbox.c
 @@ -358,6 +358,10 @@ int omap_mbox_register(struct device *parent, struct
 omap_mbox **list)
                        ret = PTR_ERR(mbox-dev);
                        goto err_out;
                }
 +               if (cpu_is_omap44xx())

 Do not use cpu_is* checks in plat-omap/*

 see the previous thread.

Referring to [1], I do not find why cpu_is* checks is used in plat-omap and
why it can't be avoided.

In [1], it was suggested to create the pdata field that will be
populated at init
time using the cpu_is* check. But in this version, I am finding that
this is done
in plat-omap. This can be handled in mach-omap layer itself and can be passed
as a pdata field which can be extracted during probe.

[1] https://patchwork.kernel.org/patch/337131/
--
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 v4 2/5] OMAP: mailbox: fix rx interrupt disable in omap4

2010-11-24 Thread Felipe Balbi


On Wed, Nov 24, 2010 at 02:20:40PM +0530, Varadarajan, Charulatha wrote:

On Wed, Nov 24, 2010 at 13:52, Felipe Balbi ba...@ti.com wrote:

On Wed, Nov 24, 2010 at 10:46:04AM +0530, Varadarajan, Charulatha wrote:


diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 48e161c..a1c6bd9 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -358,6 +358,10 @@ int omap_mbox_register(struct device *parent, struct
omap_mbox **list)
                       ret = PTR_ERR(mbox-dev);
                       goto err_out;
               }
+               if (cpu_is_omap44xx())


Do not use cpu_is* checks in plat-omap/*


see the previous thread.


Referring to [1], I do not find why cpu_is* checks is used in plat-omap and
why it can't be avoided.

In [1], it was suggested to create the pdata field that will be
populated at init
time using the cpu_is* check. But in this version, I am finding that
this is done
in plat-omap. This can be handled in mach-omap layer itself and can be passed
as a pdata field which can be extracted during probe.

[1] https://patchwork.kernel.org/patch/337131/


true, since I saw mbox-rev, I confused that with something that was
coming from pdata, sorry. You're right, this is not the right way to do
it.

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

RE: [PATCH 00/13] OMAP3: OFF mode fixes

2010-11-24 Thread Santosh Shilimkar

(Sorry. You will see two replies from me on your email)
 -Original Message-
 From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com]
 Sent: Wednesday, November 24, 2010 11:04 AM
 To: 'Kevin Hilman'
 Cc: Nishanth Menon; 'linux-omap'; 'Jean Pihet'; Vishwanath Sripathy;
 'Tony'
 Subject: RE: [PATCH 00/13] OMAP3: OFF mode fixes

  -Original Message-
  From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
  ow...@vger.kernel.org] On Behalf Of Kevin Hilman
  Sent: Wednesday, November 24, 2010 2:06 AM
  To: Santosh Shilimkar
  Cc: Nishanth Menon; linux-omap; Jean Pihet; Vishwanath Sripathy; Tony
  Subject: Re: [PATCH 00/13] OMAP3: OFF mode fixes

[...]
   And we should treat ROM code as a hardware. Secure services
   don't give  you garrulity of saving per each secure module. To
   get CPU OFF working on secure device, secure RAM must be saved.
   So I still think it is CPU specific code and pretty much relevant
   to CPU IDLE OFF state considering ROM code.
   Ofcourse this not related to GP device because we never enter Secure
   world again after the boot-up.
   So moving this code to a separate file is fine but it still related
   to CPU.

  Sure, it's still *related* to the CPU, but what I am arguing is that
it
  should not be related to CPU *idle*.

  My undersanding is this (please correct me):

  Secure RAM context only needs to be saved/updated when something in it
  changes changes (e.g. secure driver usage.)  Therefore, any
  driver/device usage that has a side effect of changing secure RAM
should
  be responsible for updating secure RAM.

 This assumption holds true largely but not completely. There are more
 Secure APIs which are outside of any secure driver usage which can also
 alter the state of secure RAM. OMAP4, we have more APIs apart from
secure
 RAM where the secure HW registers, firewalls, cache controllers,
interrupt
 controllers are managed using secure APIs. All of this is must for
correct
 CPU OFF functioning.

  The approach taken in $SUBJECT series is basically: since we don't
know
  who is using/changing secure RAM, we better save it (or have the
option
  to) during every off-mode transition.  This approach is what I do not
  like.  It's pushing work (and intellegence) that should be in the
  drivers into the PM core where it does not belong.

 The problem is because the secure RAM is not portioned per device basis
 but managed as a whole. If we had per secure device portioning then the
 respective device drivers saving it's context would have worked
perfectly.
 And the fact is it's not the secure device driver context, but it's a
 Secure software context which runs in parallel with HLOS on HS devices.

  Rather, I want to follow the same approach we follow for every other
  device driver.  Drivers must assume they can lose context.  Therefore
  it's up to them to save it.

  IOW, the drivers that *change* secure RAM should be responsible for
  ensuring that any of the changes they make are saved.

 As I mentioned above its not just the driver context but the whole
 secure software context. I will check with ROM team if it can be made
 more granular for future OMAPs so that we can have the usual strategy
 of respective components taking care of there save/restore. This will
 also save huge latency we incure while saving whole RAM on every MPU
 OFF transition.

I had a discussion with ROM team and they conformed that the secure
context can get changed with protected applications (PA for FW, secure
keys) as well as with secure drivers like crypto, aes etc.

This can be centralized and some APIs can be provided by the secure
middleware to know whether the context needs to be save or not.
Secure middleware manages all the secure driver interfaces as well
as PA's. This is the centralized place where all state knowledge is
available. This component also can take care of doing a secure context
save job based on needs. The only concern from them was that
which security middleware to be used is not fixed and its
upto customers to decide. Few of them develop this on there own.

So with clarity now, I concur with your idea of moving out the secure
context save from CPUIDLE code.
The only problem I see is how do we support multiple security
middleware's with a common infrastructure.

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: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl

2010-11-24 Thread Tomi Valkeinen

On Tue, 2010-11-23 at 23:46 +0530, ext Hiremath, Vaibhav wrote:
 Hi,
 
 While supporting one of customer I came across one interesting issue and 
 finding with WAITFORVSYNC ioctl - 
 
 Problem Statement - 
 ---
 With WAITFORVSYNC lots of tearing artifacts are visible on LCD output, but 
 WAITFORGO works fine without any issues.
 
 Debugging/Findings - 
 
 
 Technically both, WAITFORVSYNC and WAITFORGO wait on VSYNC interrupt - but 
 there is slight difference in their implementation/processing. 

No, that's not quite right.

WAITFORVSYNC waits for the next vsync.

WAITFORGO waits until the the config changes for the particular overlay
have been applied to the HW, which may take multiple vsyncs if there are
already pending config changes. Or, if there are no changes to be
applied, it doesn't wait at all.

 WAITFORGO ioctl ensures that dirty  shadow_dirty flags (software flag) are 
 cleared, making sure that hardware state and software state always stays in 
 sync. It makes 4 attempts to do so - inside loop it checks for dirty flags 
 and call wait_for_vsync API. In ideal usecase scenario it should come out in 
 single iteration. 
 
 On the other hand WAITFORVSYNC is unconditional wait on VSYNC interrupt. The 
 processing continues with an assumption that HW and SW states are in sync.
 
 Since WAITFORGO ioctl seems to be working in all conditions I started 
 debugging with it and I observed that dirty and shadow_dirty flags are 
 getting cleared on 2nd attempt in some cases. This forced me to think about 
 the window between VFP start and VSYNC.
 
 
 Root-cause (How the behavior impact software)-
 --
 
 The DSS registers are shadow registers, meaning: after updating the HW 
 registers software must write 1 to GO_LCD bit to indicate that we are 
 finished with register update and HW can now read it on next VFP start (not 
 the vsync). This is the way software and hardware handshaking is done.
 
 In Linux Display driver, we have 2 flags, dirty and shadow_dirty, first one 
 indicates software bookkeeping registers are updated and later indicates that 
 shadow registers are written but DSS HW has not yet read it (which happens on 
 VFP start).
 
 Now, if the PAN ioctl is called in the above mentioned window then DSS 
 hardware is not going to read the shadow register (setting dirty flags), DMA 
 will still happen on old buffer. Then immediately after PAN ioctl we are 
 calling WAITFORVSYNC ioctl, which is unconditional wait for VSYNC interrupt 
 and then application moves on writing to another buffer (which is now same as 
 where DMA is happening). So here we are breaking and going out-of-sync to 
 handle our ping-pong mechanism in application. As soon as the flow breaks, we 
 see the artefacts on screen.
 
 I have created Public Wiki page explaining above issue with more details and 
 pictorial diagrams, you can refer it under 
 http://processors.wiki.ti.com/index.php/OMAP35x_Linux_-_DSS_FAQ
 
 
 Suggestions/Recommendation - 
 --
 
 From User application point of view, user won't care about driver internal 
 implementation. Application believes that WAITFORVSYNC will only return after 
 displaying (DMAing) previous buffer and now with addition to 
 FBIO_WAITFORVSYNC standard ioctl interface this is very well expected from 
 user application as a standard behavior.
 
 I would recommend having WAITFORGO like implementation under WAITFORVSYNC, 
 merging WAITFORGO with WAITFORVSYNC, and killing WAITFORGO (since we have 
 FBIO_WAITFORVSYNC standard ioctl). 
 Also WAITFORGO ioctl is OMAP specific custom ioctl.  

I have to say that I'm not quite sure what WAITFORVSYNC should do. The
name implies that it should wait for the next vsync, which is what it
does for omapfb.

Changing it to WAITFORGO would alter the behaviour. Sometimes it would
not wait at all, sometimes it could wait for multiple vsyncs.

But I see the problem. Perhaps we should have a WAITFORVSYNC which would
wait until the changes are applied, or the next VSYNC if there are no
changes. That doesn't quite sound like what WAITFORVSYNC name implies,
but it would perhaps be more right (from users point of view) than the
current implementation.

 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

Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.

2010-11-24 Thread Thomas Petazzoni

Hello Mark,

On Fri, 3 Sep 2010 19:20:52 +0100
Mark Brown broo...@opensource.wolfsonmicro.com wrote:

 Essentially all that needs doing is that when regulator_set_voltage() is
 called instead of merging with the machine constraints and applying the
 setting immediately we store the constraints that are specified in the
 consumer then iterate over all enabled consumers applying all the
 constraints that they've set in addition to those from the machine.
 This results in a configuration which is the lowest possible voltage
 which satisfies all the constraints that have been supplied and for
 supplies with only one consumer it gives the same behaviour as we have
 currently.

I went ahead and implemented this (without looking at previous existing
code since I couldn't find it). What about the following patch ?

I've tested it with a dummy platform driver and a dummy regulator
driver, making sure that the correct voltage gets set at the regulator
level. My testing had a device requesting a voltage [83, 833000]
and another device [822000, 831000]. Without the patch, as the
regulator_set_voltage() gets called for the second device last, the
voltage is set at 822000 which is not acceptable for the first device.
With the patch, the 83 voltage is kept, since it satisfies both
consumers. If the second device had [822000,828000] has its voltage
requirements, then regulator_set_voltage() would fail with -EINVAL since
it is not possible to find a voltage level that satisfies both
consumers.

If you're ok with it, I'll submit it the proper way.

Thanks,

Thomas


From fa0edfc1a4428aead4502fcba248084c1194da53 Mon Sep 17 00:00:00 2001
From: Thomas Petazzoni t-petazz...@ti.com
Date: Wed, 24 Nov 2010 10:34:35 +0100
Subject: [PATCH] regulator: Take into account the requirements of all consumers

Extend the regulator_set_voltage() function to take into account the
voltage requirements of all consumers of the regulator being changed,
in order to set the voltage to the minimum voltage acceptable to all
consumers. The existing behaviour was that the latest
regulator_set_voltage() call would win over previous
regulator_set_voltage() calls even if setting the voltage to a
non-acceptable level from other consumers.

Signed-off-by: Thomas Petazzoni t-petazz...@ti.com
---
 drivers/regulator/core.c |   27 +++
 1 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index f1d10c9..12a1cae 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -132,6 +132,28 @@ static int regulator_check_voltage(struct regulator_dev 
*rdev,
return 0;
 }
 
+/* Make sure we select a voltage that suits the needs of all
+ * regulator consumers
+ */
+static int regulator_check_consumers(struct regulator_dev *rdev,
+int *min_uV, int *max_uV)
+{
+   struct regulator *regulator;
+
+   list_for_each_entry(regulator, rdev-consumer_list, list)
+   {
+   if (*max_uV  regulator-max_uV)
+   *max_uV = regulator-max_uV;
+   if (*min_uV  regulator-min_uV)
+   *min_uV = regulator-min_uV;
+   }
+
+   if (*min_uV  *max_uV)
+   return -EINVAL;
+
+   return 0;
+}
+
 /* current constraint check */
 static int regulator_check_current_limit(struct regulator_dev *rdev,
int *min_uA, int *max_uA)
@@ -1636,6 +1658,11 @@ int regulator_set_voltage(struct regulator *regulator, 
int min_uV, int max_uV)
goto out;
regulator-min_uV = min_uV;
regulator-max_uV = max_uV;
+
+   ret = regulator_check_consumers(rdev, min_uV, max_uV);
+   if (ret  0)
+   goto out;
+
ret = rdev-desc-ops-set_voltage(rdev, min_uV, max_uV);
 
 out:
-- 
1.7.0.4



-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.

2010-11-24 Thread Mark Brown

On Wed, Nov 24, 2010 at 10:45:44AM +0100, Thomas Petazzoni wrote:

 I went ahead and implemented this (without looking at previous existing
 code since I couldn't find it). What about the following patch ?

That's pretty much exactly what the old code did - told you it was
trivial :)
--
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] omap: boards w/ wl12xx should select REGULATOR_FIXED_VOLTAGE

2010-11-24 Thread Ohad Ben-Cohen

Power to the wl12xx wlan device is controlled by a fixed regulator.

Boards that have the wl12xx should select REGULATOR_FIXED_VOLTAGE so
users will not be baffled.

Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
 arch/arm/mach-omap2/Kconfig |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index fc3a181..cc386da 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -190,6 +190,7 @@ config MACH_OMAP3_PANDORA
depends on ARCH_OMAP3
default y
select OMAP_PACKAGE_CBB
+   select REGULATOR_FIXED_VOLTAGE
 
 config MACH_OMAP3_TOUCHBOOK
bool OMAP3 Touch Book
@@ -235,6 +236,7 @@ config MACH_OMAP_ZOOM2
select SERIAL_8250
select SERIAL_CORE_CONSOLE
select SERIAL_8250_CONSOLE
+   select REGULATOR_FIXED_VOLTAGE
 
 config MACH_OMAP_ZOOM3
bool OMAP3630 Zoom3 board
@@ -244,6 +246,7 @@ config MACH_OMAP_ZOOM3
select SERIAL_8250
select SERIAL_CORE_CONSOLE
select SERIAL_8250_CONSOLE
+   select REGULATOR_FIXED_VOLTAGE
 
 config MACH_CM_T35
bool CompuLab CM-T35 module
-- 
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: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl

2010-11-24 Thread Hiremath, Vaibhav

 -Original Message-
 From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
 Sent: Wednesday, November 24, 2010 2:28 PM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org
 Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl

 On Tue, 2010-11-23 at 23:46 +0530, ext Hiremath, Vaibhav wrote:
  Hi,

  While supporting one of customer I came across one interesting issue and
 finding with WAITFORVSYNC ioctl -

  Problem Statement -
  ---
  With WAITFORVSYNC lots of tearing artifacts are visible on LCD output,
 but WAITFORGO works fine without any issues.

  Debugging/Findings -

  Technically both, WAITFORVSYNC and WAITFORGO wait on VSYNC interrupt -
 but there is slight difference in their implementation/processing.

 No, that's not quite right.

 WAITFORVSYNC waits for the next vsync.

[Hiremath, Vaibhav] Yes, certainly.

 WAITFORGO waits until the the config changes for the particular overlay
 have been applied to the HW, which may take multiple vsyncs if there are
 already pending config changes. Or, if there are no changes to be
 applied, it doesn't wait at all.

[Hiremath, Vaibhav] Yes, completely agreed. But in the panning use-case where 
if we assume there will be always config change when you enter WAIFORGO ioctl 
it waits for next VSYNC, and as you mentioned it may wait for multiple vsyncs 
to make sure that config change gets applied to HW.

  WAITFORGO ioctl ensures that dirty  shadow_dirty flags (software flag)
 are cleared, making sure that hardware state and software state always
 stays in sync. It makes 4 attempts to do so - inside loop it checks for
 dirty flags and call wait_for_vsync API. In ideal usecase scenario it
 should come out in single iteration.
snip

  Suggestions/Recommendation -
  --

  From User application point of view, user won't care about driver
 internal implementation. Application believes that WAITFORVSYNC will only
 return after displaying (DMAing) previous buffer and now with addition to
 FBIO_WAITFORVSYNC standard ioctl interface this is very well expected from
 user application as a standard behavior.

  I would recommend having WAITFORGO like implementation under
 WAITFORVSYNC, merging WAITFORGO with WAITFORVSYNC, and killing WAITFORGO
 (since we have FBIO_WAITFORVSYNC standard ioctl).
  Also WAITFORGO ioctl is OMAP specific custom ioctl.

 I have to say that I'm not quite sure what WAITFORVSYNC should do. 
[Hiremath, Vaibhav] Me neither.

 The
 name implies that it should wait for the next vsync, which is what it
 does for omapfb.

 Changing it to WAITFORGO would alter the behaviour. Sometimes it would
 not wait at all, sometimes it could wait for multiple vsyncs.
[Hiremath, Vaibhav] I am quite not sure, whether it makes sense from 
application point of view to wait for vsync if config is not changed. What 
could be the use-case for such requirement, where application won't change 
anything but still would like to wait on vsync?

And as far as wait on multiple vsync is concerned, it does make sense to coat 
WAITFORVSYNC ioctl makes sure that your change got applied to HW. 

I am not aware of other architectures, but I believe this is something OMAP 
specific stuff. And for other platforms, WAITFORVSYNC means changes applied to 
HW (why does apps care about whether it is vsync or anything else?).

Thanks,
Vaibhav

 But I see the problem. Perhaps we should have a WAITFORVSYNC which would
 wait until the changes are applied, or the next VSYNC if there are no
 changes. That doesn't quite sound like what WAITFORVSYNC name implies,
 but it would perhaps be more right (from users point of view) than the
 current implementation.

  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

Re: [PATCH v2 2/4] drivers: hwspinlock: add OMAP implementation

2010-11-24 Thread Ohad Ben-Cohen

On Wed, Nov 24, 2010 at 1:23 AM, Ionut Nicu ionut.n...@mindbit.ro wrote:
 At iounmap_base you unmap state-io_base, but that's set only after this
 check. You should probably iounmap(io_base).

Of course. Thanks.



 Regards,
 Ionut.


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

--
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] ASoC: Return proper error for omap3pandora_soc_init

2010-11-24 Thread Liam Girdwood

On Wed, 2010-11-24 at 15:20 +0800, Axel Lin wrote:
 Return PTR_ERR(omap3pandora_dac_reg) instead of 0 if regulator_get failed.
 
 Signed-off-by: Axel Lin axel@gmail.com
 ---
  sound/soc/omap/omap3pandora.c |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
 
 diff --git a/sound/soc/omap/omap3pandora.c b/sound/soc/omap/omap3pandora.c
 index bff9864..8047c52 100644
 --- a/sound/soc/omap/omap3pandora.c
 +++ b/sound/soc/omap/omap3pandora.c
 @@ -307,6 +307,7 @@ static int __init omap3pandora_soc_init(void)
   pr_err(PREFIX Failed to get DAC regulator from %s: %ld\n,
   dev_name(omap3pandora_snd_device-dev),
   PTR_ERR(omap3pandora_dac_reg));
 + ret = PTR_ERR(omap3pandora_dac_reg);
   goto fail3;
   }
  

Acked-by: Liam Girdwood l...@slimlogic.co.uk
-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

--
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] ASoC: Fix resource reclaim for osk5912

2010-11-24 Thread Liam Girdwood

On Wed, 2010-11-24 at 14:07 +0530, Varadarajan, Charulatha wrote:
 On Wed, Nov 24, 2010 at 12:53, Axel Lin axel@gmail.com wrote:
 
 Add Patch description.
 
  Signed-off-by: Axel Lin axel@gmail.com
  ---

Please resubmit with a patch description and Jarkko's Ack.

Thanks

Liam 
-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

--
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 v5] OMAP2+: PM: omap device: API's for handling mstandby mode

Certain errata in OMAP2+ processors will require forcing
master standby to no standby mode before completing on going
operation. Without this, the results will be unpredictable.

Since current implementation of PM run time framework does not support
changing sysconfig settings during middle of the on going operation,
these API's will support the same. One API will force the device's
sysconfig mstandby mode settings to no standby and other API will
release no standby mode and sets it to smart standby or no
standby˝ depending on HWMOD_SWSUP_MSTANDBY value.

These API's should be used by device drivers only incase of
erratum applicable to their modules if there is no other methods
to resolve.

These API's are required for multiple DMA errata which require
putting DMA controller in no mstandby mode before stopping dma.

The applicable errata:
1. Erratum ID: i557(Applicable for omap36xx all ES versions)
The channel hangs when the Pause bit (DMA4_CDPi [7] ) is cleared
through config port while in Standby.

2. Erratum ID: i541
sDMA FIFO draining does not finish. Applicable to all omap2+ except
omap4.

3. Erratum ID:i88
The sDMA to be put in no mstandby mode before disabling the channel
after completing the data transfer operation.
Applicable only for OMAP3430 ES1.0

Also fixes typo HWMOD_SWSUP_MSTDBY to HWMOD_SWSUP_MSTANDBY in
omap_hwmod.h

Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Cc: linux-arm-ker...@lists.infradead.org
---
Change summary:
v3: Review comments incorporated for:
https://patchwork.kernel.org/patch/282212/
v4: added mutex changes
v5: typo fixes for errata and erratum

 arch/arm/mach-omap2/omap_hwmod.c  |   43 -
 arch/arm/plat-omap/include/plat/omap_device.h |2 +
 arch/arm/plat-omap/include/plat/omap_hwmod.h  |4 +-
 arch/arm/plat-omap/omap_device.c  |   64 +
 4 files changed, 111 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5a30658..de78441 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1427,6 +1427,48 @@ int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh, 
u8 idlemode)
 }
 
 /**
+ * omap_hwmod_set_master_standbymode - set the hwmod's OCP mstandby mode
+ * @oh: struct omap_hwmod *
+ * @midlemode: flag to set mstandby to either no standby or smart standby
+ *
+ * Sets the IP block's OCP mstandby mode in hardware, and updates our
+ * local copy.  Intended to be used by drivers that have some erratum
+ * that requires direct manipulation of the MIDLEMODE bits.  Returns
+ * -EINVAL if @oh is null, or passes along the return value from
+ * _set_master_standbymode().
+ *
+ * Any users of this function should be scrutinized carefully.
+ */
+int omap_hwmod_set_master_standbymode(struct omap_hwmod *oh, u8 idlemode)
+{
+   u32 v;
+   u8 sf;
+   int retval = 0;
+
+   if (!oh)
+   return -EINVAL;
+
+   if (!oh-class-sysc)
+   return -EINVAL;
+
+   v = oh-_sysc_cache;
+   sf = oh-class-sysc-sysc_flags;
+
+   if (sf  SYSC_HAS_MIDLEMODE) {
+   if (idlemode)
+   idlemode = HWMOD_IDLEMODE_NO;
+   else
+   idlemode = (oh-flags  HWMOD_SWSUP_MSTANDBY) ?
+   HWMOD_IDLEMODE_NO : HWMOD_IDLEMODE_SMART;
+   }
+   retval = _set_master_standbymode(oh, idlemode, v);
+   if (!retval)
+   _write_sysconfig(v, oh);
+
+   return retval;
+}
+
+/**
  * omap_hwmod_register - register a struct omap_hwmod
  * @oh: struct omap_hwmod *
  *
@@ -2116,4 +2158,3 @@ int omap_hwmod_for_each_by_class(const char *classname,
 
return ret;
 }
-
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h 
b/arch/arm/plat-omap/include/plat/omap_device.h
index 28e2d1a..4fbf7c1 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -116,6 +116,8 @@ int omap_device_enable_hwmods(struct omap_device *od);
 int omap_device_disable_clocks(struct omap_device *od);
 int omap_device_enable_clocks(struct omap_device *od);
 
+int omap_device_require_no_mstandby(struct platform_device *pdev);
+int omap_device_release_no_mstandby(struct platform_device *pdev);
 
 /*
  * Entries should be kept in latency order ascending
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h 
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 7eaa8ed..c7ff65a 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -354,7 +354,7 @@ struct omap_hwmod_omap4_prcm {
  *
  * HWMOD_SWSUP_SIDLE: omap_hwmod code should manually bring module in and out
  * of idle, rather than relying on module smart-idle
- * HWMOD_SWSUP_MSTDBY: omap_hwmod code should manually bring module in and out
+ * HWMOD_SWSUP_MSTANDBY:

Re: [PATCH 1/2] ASoC: Return proper error for omap3pandora_soc_init

2010-11-24 Thread Mark Brown

On Wed, Nov 24, 2010 at 03:20:48PM +0800, Axel Lin wrote:
 Return PTR_ERR(omap3pandora_dac_reg) instead of 0 if regulator_get failed.
 
 Signed-off-by: Axel Lin axel@gmail.com

Applied, thanks.
--
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 v4 1/5] OMAP: mailbox: change full flag per mailbox queue instead of global

On Tue, Nov 23, 2010 at 11:21 PM, Varadarajan, Charulatha ch...@ti.com wrote:
 On Wed, Nov 24, 2010 at 02:56, Hari Kanigeri h-kanige...@ti.com wrote:
 From: Fernando Guzman Lugo x0095...@ti.com

 The variable rq_full flag is a global variable, so if there are multiple
 mailbox users there will be conflicts. Now there is a full flag per
 mailbox queue.

 Reported-by: Ohad Ben-Cohen o...@wizery.com
 Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
 Signed-off-by: Hari Kanigeri h-kanige...@ti.com
 ---
  arch/arm/plat-omap/include/plat/mailbox.h |    1 +
  arch/arm/plat-omap/mailbox.c              |    9 +++--
  2 files changed, 8 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/plat-omap/include/plat/mailbox.h 
 b/arch/arm/plat-omap/include/plat/mailbox.h
 index 9976565..13f2ef3 100644
 --- a/arch/arm/plat-omap/include/plat/mailbox.h
 +++ b/arch/arm/plat-omap/include/plat/mailbox.h
 @@ -48,6 +48,7 @@ struct omap_mbox_queue {
        struct tasklet_struct   tasklet;
        int     (*callback)(void *);
        struct omap_mbox        *mbox;
 +       bool full;
  };

  struct omap_mbox {
 diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
 index d2fafb8..48e161c 100644
 --- a/arch/arm/plat-omap/mailbox.c
 +++ b/arch/arm/plat-omap/mailbox.c
 @@ -33,7 +33,6 @@

  static struct workqueue_struct *mboxd;
  static struct omap_mbox **mboxes;
 -static bool rq_full;

  static int mbox_configured;
  static DEFINE_MUTEX(mbox_configured_lock);
 @@ -148,6 +147,12 @@ static void mbox_rx_work(struct work_struct *work)

                if (mq-callback)
                        mq-callback((void *)msg);
 +               spin_lock_irq(mq-lock);
 +               if (mq-full) {
 +                       mq-full = false;
 +                       omap_mbox_enable_irq(mq-mbox, IRQ_RX);
 +               }
 +               spin_unlock_irq(mq-lock);
        }
  }

 @@ -170,7 +175,7 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
        while (!mbox_fifo_empty(mbox)) {
                if (unlikely(kfifo_avail(mq-fifo)  sizeof(msg))) {
                        omap_mbox_disable_irq(mbox, IRQ_RX);
 -                       rq_full = true;
 +                       mq-full = true;

 Should this also be inside spin_lock_irq?


Not needed. this is already run from interrupt context.

Thank you,
Best regards,
Hari
--
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 v5 00/14] OMAP: DMA: hwmod and DMA as platform device

Patch series to convert DMA library into platform driver using platform
device model and adapting hwmod for omap2+.

The initial patches in the patch series(first 6 patches) prepares
existing DMA library for getting converted into platform driver.

steps used:
1. The low level read/write macros are converted into static inline functions
so that, these functions can be moved to respective mach-omap driver
files later.
(Thanks to Tony and Kevin for their suggestions on handling all omap register
offset without adding extra enums)
2. Implements generic errata handling for all OMAP DMA errata.
3. DMA hwmod data is updated for respective hwmod db files.
4. The DMA library is split into two layers.
a. The generic code is retained in plat-omap/dma.c
b. The machine specific code and API's are moved to
respective mach-omap dma files.
5. All cpu_*is_* checks are replaced with device attributes and cpu_*is_*
are used only in mach-omap init functions.
6. Desriptor autoloading feature is added and followed by applicable erratum
for the same.
7. The sysconfig register access for errata handling is replaced with API's
Note: This feature has dependency on the patch:
https://patchwork.kernel.org/patch/352481/
8. PM runtime API's are used.

Patch series applies on top of latest linux omap master branch:
*
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
Branch: master
commit 25f7615faa843731af4eda7d05077f1c5132e1a9
Merge: 784bee8 8973a21
Author: Tony Lindgren t...@atomide.com

Linux-omap rebuilt: Updated to -rc3
*

Test Report:

Build:
omap2plus_defconfig: Success
omap_h2_1610_defconfig : Success

Boot:
OMAP2430SDP: Success
OMAP3630Zoom3 : Success
OMAP4430Blaze(ES2.1) : Success
OMAP1 : Not tested

Unit tests:
Test results are same as v4 test results which can be acccessed at:
OMAP4BLAZE : http://pastebin.com/HVnim30G
OMAP3630ZOOM3: http://pastebin.com/JJwrtP4F
OMAP243SDP : http://pastebin.com/mz7cVQL3

Test cases executed:
1. All applicable TI DMA tests which are located at:
http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=tree;f=dma/test_code;h=0d00de3c0fe6933b405c62da63f694883f3e4b8f;hb=2c50a5a58dea0ffc2d31b827935aeef9b9d11253

2. Use case tests : TI MMC tests are executed with different types of
file systems such as DOS, ext2, ext3 etc on omap4 blaze and omap3630 zoom3.
More information can be found at:
http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=tree;f=mmc/test_code;h=d0bc1984eef46ac45719efb02b5c1f4193422a1b;hb=2c50a5a58dea0ffc2d31b827935aeef9b9d11253

Dependencies:

This patch series has dependency on omap_device patch:
https://patchwork.kernel.org/patch/352481/

Changelist summary:
v4: Review comments fixed:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg37879.html
https://patchwork.kernel.org/patch/308362/
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38268.html

v3:
Review comments fixed:
http://www.listware.net/201008/linux-omap/89002-patch-v2-0011-omap-dma-hwmod-and-dma-as-platform-driver.html
- created and tested on latest linux-omap master branch(2.6.36 kernel)

v2:
The review comments which are fixed can be found at:
http://www.spinics.net/lists/linux-omap/msg34291.html
http://www.spinics.net/lists/linux-omap/msg34292.html
http://www.spinics.net/lists/linux-omap/msg34078.html
http://www.spinics.net/lists/linux-omap/msg34083.html

v1:
These changes are based on comments received during internal discussions which
has changes(compared to previous version) such as:
- Code optimization
- Patches are rearranged in more meaningful way so that git bisect works at any
intermediate patch in the series.
- Build tested for all omap's(OMAP1 and OMAP2PLUS)
- Boot tested for OMAP3 and OMAP4(appreciate if some one tests on OMAP1/2)
- Applicalbe tests are executed on OMAP3 and OMAP4 boards
- Rebased and added descriptor autoloading feature(only for omap3630 and omap4)

Patch Summary:
**

Benoit Cousson (1):
OMAP4: hwmod data: add system DMA

G, Manjunath Kondaiah (12):
OMAP: DMA: Replace read/write macros with functions
OMAP: DMA: Introduce errata handling feature
OMAP2420: hwmod data: add system DMA
OMAP2430: hwmod data: add system DMA
OMAP3: hwmod data: add system DMA
OMAP1: DMA: Implement in platform device model
OMAP2+: DMA: hwmod: Device registration
OMAP: DMA: Convert DMA library into platform driver
OMAP: DMA: Use DMA device attributes
OMAP3630: DMA: Add work around for erratum i557
OMAP2+: DMA: Replace sysconfig register access with API's
OMAP: PM: DMA: Enable runtime pm

Venkatraman S (1):
OMAP2+: DMA: descriptor autoloading feature

arch/arm/mach-omap1/Makefile |2 +-
arch/arm/mach-omap1/dma.c | 691 +++

[PATCH v5 01/14] OMAP: DMA: Replace read/write macros with functions

Prepare DMA library to get converted into DMA driver using platform
device model using hwmod infrastucture for omap2+ and resource structures
for omap1.

The low level read/write macros are replaced with static inline
functions and register offsets are handled through static register
offset tables mapped through  enumeration constants.

These low level read/write functions along with static register offset
tables will be moved to respective mach-omap dma files in the later
patches of this series.

There are no functionality changes with these changes except change in
logic for handling 16bit registers of OMAP1.

Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
 arch/arm/plat-omap/dma.c  |  517 -
 arch/arm/plat-omap/include/plat/dma.h |  151 ++
 2 files changed, 345 insertions(+), 323 deletions(-)

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 2c28265..df0f326 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -40,6 +40,96 @@
 
 #undef DEBUG
 
+static u16 reg_map_omap1[] = {
+   [GCR]   = 0x400,
+   [GSCR]  = 0x404,
+   [GRST1] = 0x408,
+   [HW_ID] = 0x442,
+   [PCH2_ID]   = 0x444,
+   [PCH0_ID]   = 0x446,
+   [PCH1_ID]   = 0x448,
+   [PCHG_ID]   = 0x44a,
+   [PCHD_ID]   = 0x44c,
+   [CAPS_0]= 0x44e,
+   [CAPS_1]= 0x452,
+   [CAPS_2]= 0x456,
+   [CAPS_3]= 0x458,
+   [CAPS_4]= 0x45a,
+   [PCH2_SR]   = 0x460,
+   [PCH0_SR]   = 0x480,
+   [PCH1_SR]   = 0x482,
+   [PCHD_SR]   = 0x4c0,
+
+   /* Common Registers */
+   [CSDP]  = 0x00,
+   [CCR]   = 0x02,
+   [CICR]  = 0x04,
+   [CSR]   = 0x06,
+   [CEN]   = 0x10,
+   [CFN]   = 0x12,
+   [CSFI]  = 0x14,
+   [CSEI]  = 0x16,
+   [CPC]   = 0x18, /* 15xx only */
+   [CSAC]  = 0x18,
+   [CDAC]  = 0x1a,
+   [CDEI]  = 0x1c,
+   [CDFI]  = 0x1e,
+   [CLNK_CTRL] = 0x28,
+
+   /* Channel specific register offsets */
+   [CSSA]  = 0x08,
+   [CDSA]  = 0x0c,
+   [COLOR] = 0x20,
+   [CCR2]  = 0x24,
+   [LCH_CTRL]  = 0x2a,
+};
+
+static u16 reg_map_omap2[] = {
+   [REVISION]  = 0x00,
+   [GCR]   = 0x78,
+   [IRQSTATUS_L0]  = 0x08,
+   [IRQSTATUS_L1]  = 0x0c,
+   [IRQSTATUS_L2]  = 0x10,
+   [IRQSTATUS_L3]  = 0x14,
+   [IRQENABLE_L0]  = 0x18,
+   [IRQENABLE_L1]  = 0x1c,
+   [IRQENABLE_L2]  = 0x20,
+   [IRQENABLE_L3]  = 0x24,
+   [SYSSTATUS] = 0x28,
+   [OCP_SYSCONFIG] = 0x2c,
+   [CAPS_0]= 0x64,
+   [CAPS_2]= 0x6c,
+   [CAPS_3]= 0x70,
+   [CAPS_4]= 0x74,
+
+   /* Common register offsets */
+   [CCR]   = 0x80,
+   [CLNK_CTRL] = 0x84,
+   [CICR]  = 0x88,
+   [CSR]   = 0x8c,
+   [CSDP]  = 0x90,
+   [CEN]   = 0x94,
+   [CFN]   = 0x98,
+   [CSEI]  = 0xa4,
+   [CSFI]  = 0xa8,
+   [CDEI]  = 0xac,
+   [CDFI]  = 0xb0,
+   [CSAC]  = 0xb4,
+   [CDAC]  = 0xb8,
+
+   /* Channel specific register offsets */
+   [CSSA]  = 0x9c,
+   [CDSA]  = 0xa0,
+   [CCEN]  = 0xbc,
+   [CCFN]  = 0xc0,
+   [COLOR] = 0xc4,
+
+   /* OMAP4 specific registers */
+   [CDP]   = 0xd0,
+   [CNDP]  = 0xd4,
+   [CCDN]  = 0xd8,
+};
+
 #ifndef CONFIG_ARCH_OMAP1
 enum { DMA_CH_ALLOC_DONE, DMA_CH_PARAMS_SET_DONE, DMA_CH_STARTED,
DMA_CH_QUEUED, DMA_CH_NOTSTARTED, DMA_CH_PAUSED, DMA_CH_LINK_ENABLED
@@ -138,6 +228,9 @@ static int omap_dma_reserve_channels;
 static spinlock_t dma_chan_lock;
 static struct omap_dma_lch *dma_chan;
 static void __iomem *omap_dma_base;
+static u16 *reg_map;
+static u8 dma_stride;
+static enum omap_reg_offsets dma_common_ch_start, dma_common_ch_end;
 
 static const u8 omap1_dma_irq[OMAP1_LOGICAL_DMA_CH_COUNT] = {
INT_DMA_CH0_6, INT_DMA_CH1_7, INT_DMA_CH2_8, INT_DMA_CH3,
@@ -154,23 +247,48 @@ static inline void omap_enable_channel_irq(int lch);
 #define REVISIT_24XX() printk(KERN_ERR FIXME: no %s on 24xx\n, \

[PATCH v5 02/14] OMAP: DMA: Introduce errata handling feature

Implement errata handling to use flags instead of cpu_is_* and
cpu_class_* in the code.

The errata flags are initialized at init time and during runtime we are
using the errata variable (via the IS_DMA_ERRATA macro) to execute the
required errata workaround.

Reused errata handling patch from: Peter Ujfalusi
peter.ujfal...@nokia.com
https://patchwork.kernel.org/patch/231191/

Changes to above patch:
1. Changes are done for converting all the existing errata work arounds
to use this feature.
2. Detailed description for each errata is added.
3. Fixed bug in SET_DMA_ERRATA macro
4. Bit shifting in macro definitions are replaced with BIT() macro

Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Peter Ujfalusi peter.ujfal...@nokia.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
 arch/arm/plat-omap/dma.c  |  152 ++---
 arch/arm/plat-omap/include/plat/dma.h |   12 +++
 2 files changed, 114 insertions(+), 50 deletions(-)

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index df0f326..f73b302 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -144,6 +144,7 @@ enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED };
 #define OMAP_FUNC_MUX_ARM_BASE (0xfffe1000 + 0xec)
 
 static int enable_1510_mode;
+static u32 errata;
 
 static struct omap_dma_global_context_registers {
u32 dma_irqenable_l0;
@@ -1088,31 +1089,17 @@ void omap_start_dma(int lch)
 
cur_lch = next_lch;
} while (next_lch != -1);
-   } else if (cpu_is_omap242x() ||
-   (cpu_is_omap243x()   omap_type() = OMAP2430_REV_ES1_0)) {
-
-   /* Errata: Need to write lch even if not using chaining */
+   } else if (IS_DMA_ERRATA(DMA_ERRATA_PARALLEL_CHANNELS))
dma_write(lch, CLNK_CTRL, lch);
-   }
 
omap_enable_channel_irq(lch);
 
l = dma_read(CCR, lch);
 
-   /*
-* Errata: Inter Frame DMA buffering issue (All OMAP2420 and
-* OMAP2430ES1.0): DMA will wrongly buffer elements if packing and
-* bursting is enabled. This might result in data gets stalled in
-* FIFO at the end of the block.
-* Workaround: DMA channels must have BUFFERING_DISABLED bit set to
-* guarantee no data will stay in the DMA FIFO in case inter frame
-* buffering occurs.
-*/
-   if (cpu_is_omap2420() ||
-   (cpu_is_omap2430()  (omap_type() == OMAP2430_REV_ES1_0)))
-   l |= OMAP_DMA_CCR_BUFFERING_DISABLE;
-
+   if (IS_DMA_ERRATA(DMA_ERRATA_IFRAME_BUFFERING))
+   l |= OMAP_DMA_CCR_BUFFERING_DISABLE;
l |= OMAP_DMA_CCR_EN;
+
dma_write(l, CCR, lch);
 
dma_chan[lch].flags |= OMAP_DMA_ACTIVE;
@@ -1128,8 +1115,8 @@ void omap_stop_dma(int lch)
dma_write(0, CICR, lch);
 
l = dma_read(CCR, lch);
-   /* OMAP3 Errata i541: sDMA FIFO draining does not finish */
-   if (cpu_is_omap34xx()  (l  OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
+   if (IS_DMA_ERRATA(DMA_ERRATA_i541) 
+   (l  OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
int i = 0;
u32 sys_cf;
 
@@ -1229,11 +1216,7 @@ dma_addr_t omap_get_dma_src_pos(int lch)
else
offset = dma_read(CSAC, lch);
 
-   /*
-* omap 3.2/3.3 erratum: sometimes 0 is returned if CSAC/CDAC is
-* read before the DMA controller finished disabling the channel.
-*/
-   if (!cpu_is_omap15xx()  offset == 0)
+   if (IS_DMA_ERRATA(DMA_ERRATA_3_3)  offset == 0)
offset = dma_read(CSAC, lch);
 
if (cpu_class_is_omap1())
@@ -1814,7 +1797,7 @@ int omap_stop_dma_chain_transfers(int chain_id)
 {
int *channels;
u32 l, i;
-   u32 sys_cf;
+   u32 sys_cf = 0;
 
/* Check for input params */
if (unlikely((chain_id  0 || chain_id = dma_lch_count))) {
@@ -1829,15 +1812,13 @@ int omap_stop_dma_chain_transfers(int chain_id)
}
channels = dma_linked_lch[chain_id].linked_dmach_q;
 
-   /*
-* DMA Errata:
-* Special programming model needed to disable DMA before end of block
-*/
-   sys_cf = dma_read(OCP_SYSCONFIG, 0);
-   l = sys_cf;
-   /* Middle mode reg set no Standby */
-   l = ~((1  12)|(1  13));
-   dma_write(l, OCP_SYSCONFIG, 0);
+   if (IS_DMA_ERRATA(DMA_ERRATA_i88)) {
+   sys_cf = dma_read(OCP_SYSCONFIG, 0);
+   l = sys_cf;
+   /* Middle mode reg set no Standby */
+   l = ~((1  12)|(1  13));
+   dma_write(l, OCP_SYSCONFIG, 0);
+   }
 
for (i = 0; i  dma_linked_lch[chain_id].no_of_lchs_linked; i++) {
 
@@ -1856,8 +1837,8 @@ int omap_stop_dma_chain_transfers(int chain_id)
/*

[PATCH v5 03/14] OMAP2420: hwmod data: add system DMA

Add OMAP2420 DMA hwmod data and also add required
DMA device attributes.

Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |   87 
 arch/arm/plat-omap/include/plat/dma.h  |   11 
 2 files changed, 98 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a1a3dd6..81aa0d9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -38,6 +38,7 @@ static struct omap_hwmod omap2420_iva_hwmod;
 static struct omap_hwmod omap2420_l3_main_hwmod;
 static struct omap_hwmod omap2420_l4_core_hwmod;
 static struct omap_hwmod omap2420_wd_timer2_hwmod;
+static struct omap_hwmod omap2420_dma_system_hwmod;
 
 /* L3 - L4_CORE interface */
 static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
@@ -557,6 +558,89 @@ static struct omap_hwmod omap2420_i2c2_hwmod = {
.flags  = HWMOD_16BIT_REG,
 };
 
+/* system dma */
+static struct omap_hwmod_class_sysconfig omap2420_dma_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x002c,
+   .syss_offs  = 0x0028,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+  SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+  SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+  MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+   .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_dma_hwmod_class = {
+   .name = dma,
+   .sysc = omap2420_dma_sysc,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+   .dev_caps  = RESERVE_CHANNEL | DMA_LINKED_LCH | GLOBAL_PRIORITY |
+   IS_CSSA_32 | IS_CDSA_32,
+   .lch_count = 32,
+};
+
+static struct omap_hwmod_irq_info omap2420_dma_system_irqs[] = {
+   { .name = 0, .irq = 12 }, /* INT_24XX_SDMA_IRQ0 */
+   { .name = 1, .irq = 13 }, /* INT_24XX_SDMA_IRQ1 */
+   { .name = 2, .irq = 14 }, /* INT_24XX_SDMA_IRQ2 */
+   { .name = 3, .irq = 15 }, /* INT_24XX_SDMA_IRQ3 */
+};
+
+static struct omap_hwmod_addr_space omap2420_dma_system_addrs[] = {
+   {
+   .pa_start   = 0x48056000,
+   .pa_end = 0x4a0560ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* dma_system - L3 */
+static struct omap_hwmod_ocp_if omap2420_dma_system__l3 = {
+   .master = omap2420_dma_system_hwmod,
+   .slave  = omap2420_l3_main_hwmod,
+   .clk= l3_div_ck,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap2420_dma_system_masters[] = {
+   omap2420_dma_system__l3,
+};
+
+/* l4_cfg - dma_system */
+static struct omap_hwmod_ocp_if omap2420_l4_core__dma_system = {
+   .master = omap2420_l4_core_hwmod,
+   .slave  = omap2420_dma_system_hwmod,
+   .clk= l4_div_ck,
+   .addr   = omap2420_dma_system_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap2420_dma_system_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap2420_dma_system_slaves[] = {
+   omap2420_l4_core__dma_system,
+};
+
+static struct omap_hwmod omap2420_dma_system_hwmod = {
+   .name   = dma,
+   .class  = omap2420_dma_hwmod_class,
+   .mpu_irqs   = omap2420_dma_system_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap2420_dma_system_irqs),
+   .main_clk   = l3_div_ck,
+   .slaves = omap2420_dma_system_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap2420_dma_system_slaves),
+   .masters= omap2420_dma_system_masters,
+   .masters_cnt= ARRAY_SIZE(omap2420_dma_system_masters),
+   .dev_attr   = dma_dev_attr,
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+   .flags  = HWMOD_NO_IDLEST,
+};
+
 static __initdata struct omap_hwmod *omap2420_hwmods[] = {
omap2420_l3_main_hwmod,
omap2420_l4_core_hwmod,
@@ -569,6 +653,9 @@ static __initdata struct omap_hwmod *omap2420_hwmods[] = {
omap2420_uart3_hwmod,
omap2420_i2c1_hwmod,
omap2420_i2c2_hwmod,
+
+   /* dma_system class*/
+   omap2420_dma_system_hwmod,
NULL,
 };
 
diff --git a/arch/arm/plat-omap/include/plat/dma.h 
b/arch/arm/plat-omap/include/plat/dma.h
index 2378399..c466566 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -295,6

[PATCH v5 04/14] OMAP2430: hwmod data: add system DMA

Add OMAP2430 DMA hwmod data and also add required
DMA device attributes.

Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |   87 
 arch/arm/plat-omap/include/plat/dma.h  |1 +
 2 files changed, 88 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 7cf0d3a..bf5c029 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -38,6 +38,7 @@ static struct omap_hwmod omap2430_iva_hwmod;
 static struct omap_hwmod omap2430_l3_main_hwmod;
 static struct omap_hwmod omap2430_l4_core_hwmod;
 static struct omap_hwmod omap2430_wd_timer2_hwmod;
+static struct omap_hwmod omap2430_dma_system_hwmod;
 
 /* L3 - L4_CORE interface */
 static struct omap_hwmod_ocp_if omap2430_l3_main__l4_core = {
@@ -569,6 +570,89 @@ static struct omap_hwmod omap2430_i2c2_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
 };
 
+/* dma_system */
+static struct omap_hwmod_class_sysconfig omap2430_dma_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x002c,
+   .syss_offs  = 0x0028,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+  SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+  SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+  MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+   .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2430_dma_hwmod_class = {
+   .name = dma,
+   .sysc = omap2430_dma_sysc,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+   .dev_caps  = RESERVE_CHANNEL | DMA_LINKED_LCH | GLOBAL_PRIORITY |
+   IS_CSSA_32 | IS_CDSA_32 | IS_RW_PRIORITY,
+   .lch_count = 32,
+};
+
+static struct omap_hwmod_irq_info omap2430_dma_system_irqs[] = {
+   { .name = 0, .irq = 12 }, /* INT_24XX_SDMA_IRQ0 */
+   { .name = 1, .irq = 13 }, /* INT_24XX_SDMA_IRQ1 */
+   { .name = 2, .irq = 14 }, /* INT_24XX_SDMA_IRQ2 */
+   { .name = 3, .irq = 15 }, /* INT_24XX_SDMA_IRQ3 */
+};
+
+static struct omap_hwmod_addr_space omap2430_dma_system_addrs[] = {
+   {
+   .pa_start   = 0x48056000,
+   .pa_end = 0x4a0560ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* dma_system - L3 */
+static struct omap_hwmod_ocp_if omap2430_dma_system__l3 = {
+   .master = omap2430_dma_system_hwmod,
+   .slave  = omap2430_l3_main_hwmod,
+   .clk= l3_div_ck,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap2430_dma_system_masters[] = {
+   omap2430_dma_system__l3,
+};
+
+/* l4_cfg - dma_system */
+static struct omap_hwmod_ocp_if omap2430_l4_core__dma_system = {
+   .master = omap2430_l4_core_hwmod,
+   .slave  = omap2430_dma_system_hwmod,
+   .clk= l4_div_ck,
+   .addr   = omap2430_dma_system_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap2430_dma_system_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap2430_dma_system_slaves[] = {
+   omap2430_l4_core__dma_system,
+};
+
+static struct omap_hwmod omap2430_dma_system_hwmod = {
+   .name   = dma,
+   .class  = omap2430_dma_hwmod_class,
+   .mpu_irqs   = omap2430_dma_system_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap2430_dma_system_irqs),
+   .main_clk   = l3_div_ck,
+   .slaves = omap2430_dma_system_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap2430_dma_system_slaves),
+   .masters= omap2430_dma_system_masters,
+   .masters_cnt= ARRAY_SIZE(omap2430_dma_system_masters),
+   .dev_attr   = dma_dev_attr,
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+   .flags  = HWMOD_NO_IDLEST,
+};
+
 static __initdata struct omap_hwmod *omap2430_hwmods[] = {
omap2430_l3_main_hwmod,
omap2430_l4_core_hwmod,
@@ -581,6 +665,9 @@ static __initdata struct omap_hwmod *omap2430_hwmods[] = {
omap2430_uart3_hwmod,
omap2430_i2c1_hwmod,
omap2430_i2c2_hwmod,
+
+   /* dma_system class*/
+   omap2430_dma_system_hwmod,
NULL,
 };
 
diff --git a/arch/arm/plat-omap/include/plat/dma.h 
b/arch/arm/plat-omap/include/plat/dma.h
index c466566..4b51d2b 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++

[PATCH v5 05/14] OMAP3: hwmod data: add system DMA

Add OMAP3 DMA hwmod data

Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   96 
 1 files changed, 96 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 a8bed84..a928024 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -45,6 +45,7 @@ static struct omap_hwmod omap3xxx_wd_timer2_hwmod;
 static struct omap_hwmod omap3xxx_i2c1_hwmod;
 static struct omap_hwmod omap3xxx_i2c2_hwmod;
 static struct omap_hwmod omap3xxx_i2c3_hwmod;
+static struct omap_hwmod omap3xxx_dma_system_hwmod;
 
 /* L3 - L4_CORE interface */
 static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -739,6 +740,98 @@ static struct omap_hwmod omap3xxx_i2c3_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
 };
 
+/* dma_system - L3 */
+static struct omap_hwmod_ocp_if omap3xxx_dma_system__l3 = {
+   .master = omap3xxx_dma_system_hwmod,
+   .slave  = omap3xxx_l3_main_hwmod,
+   .clk= core_l3_ick,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+   .dev_caps  = RESERVE_CHANNEL | DMA_LINKED_LCH | GLOBAL_PRIORITY |
+   IS_CSSA_32 | IS_CDSA_32 | IS_RW_PRIORITY,
+   .lch_count = 32,
+};
+
+static struct omap_hwmod_class_sysconfig omap3xxx_dma_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x002c,
+   .syss_offs  = 0x0028,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+  SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+  SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+  MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+   .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_dma_hwmod_class = {
+   .name = dma,
+   .sysc = omap3xxx_dma_sysc,
+};
+
+/* dma_system */
+static struct omap_hwmod_irq_info omap3xxx_dma_system_irqs[] = {
+   { .name = 0, .irq = 12 }, /* INT_24XX_SDMA_IRQ0 */
+   { .name = 1, .irq = 13 }, /* INT_24XX_SDMA_IRQ1 */
+   { .name = 2, .irq = 14 }, /* INT_24XX_SDMA_IRQ2 */
+   { .name = 3, .irq = 15 }, /* INT_24XX_SDMA_IRQ3 */
+};
+
+static struct omap_hwmod_addr_space omap3xxx_dma_system_addrs[] = {
+   {
+   .pa_start   = 0x48056000,
+   .pa_end = 0x4a0560ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dma_system_masters[] = {
+   omap3xxx_dma_system__l3,
+};
+
+/* l4_cfg - dma_system */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__dma_system = {
+   .master = omap3xxx_l4_core_hwmod,
+   .slave  = omap3xxx_dma_system_hwmod,
+   .clk= core_l4_ick,
+   .addr   = omap3xxx_dma_system_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap3xxx_dma_system_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dma_system_slaves[] = {
+   omap3xxx_l4_core__dma_system,
+};
+
+static struct omap_hwmod omap3xxx_dma_system_hwmod = {
+   .name   = dma,
+   .class  = omap3xxx_dma_hwmod_class,
+   .mpu_irqs   = omap3xxx_dma_system_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap3xxx_dma_system_irqs),
+   .main_clk   = core_l3_ick,
+   .prcm = {
+   .omap2 = {
+   .module_offs= CORE_MOD,
+   .prcm_reg_id= 1,
+   .module_bit = OMAP3430_ST_SDMA_SHIFT,
+   .idlest_reg_id  = 1,
+   .idlest_idle_bit= OMAP3430_ST_SDMA_SHIFT,
+   },
+   },
+   .slaves = omap3xxx_dma_system_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap3xxx_dma_system_slaves),
+   .masters= omap3xxx_dma_system_masters,
+   .masters_cnt= ARRAY_SIZE(omap3xxx_dma_system_masters),
+   .dev_attr   = dma_dev_attr,
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+   .flags  = HWMOD_NO_IDLEST,
+};
+
 static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_l3_main_hwmod,
omap3xxx_l4_core_hwmod,
@@ -754,6 +847,9 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_i2c1_hwmod,
omap3xxx_i2c2_hwmod,
omap3xxx_i2c3_hwmod,
+
+

[PATCH v5 06/14] OMAP4: hwmod data: add system DMA

From: Benoit Cousson b-cous...@ti.com

Add OMAP4 DMA hwmod data

Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  100 
 1 files changed, 100 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 0d5c6eb..7197204 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -22,6 +22,7 @@
 
 #include plat/omap_hwmod.h
 #include plat/cpu.h
+#include plat/dma.h
 
 #include omap_hwmod_common_data.h
 
@@ -35,6 +36,7 @@
 #define OMAP44XX_DMA_REQ_START  1
 
 /* Backward references (IPs with Bus Master capability) */
+static struct omap_hwmod omap44xx_dma_system_hwmod;
 static struct omap_hwmod omap44xx_dmm_hwmod;
 static struct omap_hwmod omap44xx_emif_fw_hwmod;
 static struct omap_hwmod omap44xx_l3_instr_hwmod;
@@ -215,6 +217,14 @@ static struct omap_hwmod_ocp_if 
omap44xx_l3_main_1__l3_main_2 = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* dma_system - l3_main_2 */
+static struct omap_hwmod_ocp_if omap44xx_dma_system__l3_main_2 = {
+   .master = omap44xx_dma_system_hwmod,
+   .slave  = omap44xx_l3_main_2_hwmod,
+   .clk= l3_div_ck,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* l4_cfg - l3_main_2 */
 static struct omap_hwmod_ocp_if omap44xx_l4_cfg__l3_main_2 = {
.master = omap44xx_l4_cfg_hwmod,
@@ -226,6 +236,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_cfg__l3_main_2 
= {
 /* l3_main_2 slave ports */
 static struct omap_hwmod_ocp_if *omap44xx_l3_main_2_slaves[] = {
omap44xx_l3_main_1__l3_main_2,
+   omap44xx_dma_system__l3_main_2,
omap44xx_l4_cfg__l3_main_2,
 };
 
@@ -1043,6 +1054,92 @@ static struct omap_hwmod omap44xx_uart4_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
 };
 
+/*
+ * 'dma' class
+ * dma controller for data exchange between memory to memory (i.e. internal or
+ * external memory) and gp peripherals to memory or memory to gp peripherals
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_dma_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x002c,
+   .syss_offs  = 0x0028,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+  SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+  SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+  MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+   .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_dma_hwmod_class = {
+   .name = dma,
+   .sysc = omap44xx_dma_sysc,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+   .dev_caps  = RESERVE_CHANNEL | DMA_LINKED_LCH | GLOBAL_PRIORITY |
+   IS_CSSA_32 | IS_CDSA_32 | IS_RW_PRIORITY,
+   .lch_count = 32,
+};
+
+/* dma_system */
+static struct omap_hwmod_irq_info omap44xx_dma_system_irqs[] = {
+   { .name = 0, .irq = 12 + OMAP44XX_IRQ_GIC_START },
+   { .name = 1, .irq = 13 + OMAP44XX_IRQ_GIC_START },
+   { .name = 2, .irq = 14 + OMAP44XX_IRQ_GIC_START },
+   { .name = 3, .irq = 15 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_dma_system_addrs[] = {
+   {
+   .pa_start   = 0x4a056000,
+   .pa_end = 0x4a0560ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap44xx_dma_system_masters[] = {
+   omap44xx_dma_system__l3_main_2,
+};
+
+/* l4_cfg - dma_system */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__dma_system = {
+   .master = omap44xx_l4_cfg_hwmod,
+   .slave  = omap44xx_dma_system_hwmod,
+   .clk= l4_div_ck,
+   .addr   = omap44xx_dma_system_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap44xx_dma_system_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_dma_system_slaves[] = {
+   omap44xx_l4_cfg__dma_system,
+};
+
+static struct omap_hwmod omap44xx_dma_system_hwmod = {
+   .name   = dma_system,
+   .class  = omap44xx_dma_hwmod_class,
+   .mpu_irqs   = omap44xx_dma_system_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap44xx_dma_system_irqs),
+   .main_clk   = l3_div_ck,
+   .prcm = {
+   .omap4 = {
+   .clkctrl_reg = OMAP4430_CM_SDMA_SDMA_CLKCTRL,
+   },
+

[PATCH v5 07/14] OMAP1: DMA: Implement in platform device model

Implement OMAP1 DMA as platform device and add support for
registering through platform device layer using resource
structures.

Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
 arch/arm/mach-omap1/dma.c |  179 +
 1 files changed, 179 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap1/dma.c

diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
new file mode 100644
index 000..b56ee21
--- /dev/null
+++ b/arch/arm/mach-omap1/dma.c
@@ -0,0 +1,179 @@
+/*
+ * OMAP1/OMAP7xx - specific DMA driver
+ *
+ * Copyright (C) 2003 - 2008 Nokia Corporation
+ * Author: Juha YrjÃ¶lÃ¤ juha.yrj...@nokia.com
+ * DMA channel linking for 1610 by Samuel Ortiz samuel.or...@nokia.com
+ * Graphics DMA and LCD DMA graphics tranformations
+ * by Imre Deak imre.d...@nokia.com
+ * OMAP2/3 support Copyright (C) 2004-2007 Texas Instruments, Inc.
+ * Some functions based on earlier dma-omap.c Copyright (C) 2001 RidgeRun, Inc.
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Converted DMA library into platform driver
+ *   - G, Manjunath Kondaiah manj...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/err.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/init.h
+#include linux/device.h
+
+#include plat/dma.h
+#include plat/tc.h
+#include plat/irqs.h
+
+#define OMAP1_DMA_BASE (0xfffed800)
+
+static struct resource res[] __initdata = {
+   [0] = {
+   .start  = OMAP1_DMA_BASE,
+   .end= OMAP1_DMA_BASE + SZ_2K - 1,
+   .flags  = IORESOURCE_MEM,
+   },
+   [1] = {
+   .name   = 0,
+   .start  = INT_DMA_CH0_6,
+   .flags  = IORESOURCE_IRQ,
+   },
+   [2] = {
+   .name   = 1,
+   .start  = INT_DMA_CH1_7,
+   .flags  = IORESOURCE_IRQ,
+   },
+   [3] = {
+   .name   = 2,
+   .start  = INT_DMA_CH2_8,
+   .flags  = IORESOURCE_IRQ,
+   },
+   [4] = {
+   .name   = 3,
+   .start  = INT_DMA_CH3,
+   .flags  = IORESOURCE_IRQ,
+   },
+   [5] = {
+   .name   = 4,
+   .start  = INT_DMA_CH4,
+   .flags  = IORESOURCE_IRQ,
+   },
+   [6] = {
+   .name   = 5,
+   .start  = INT_DMA_CH5,
+   .flags  = IORESOURCE_IRQ,
+   },
+   [7] = {
+   .name   = 6,
+   .start  = INT_DMA_LCD,
+   .flags  = IORESOURCE_IRQ,
+   },
+   /* irq's for omap16xx and omap7xx */
+   [8] = {
+   .name   = 7,
+   .start  = 53 + IH2_BASE,
+   .flags  = IORESOURCE_IRQ,
+   },
+   [9] = {
+   .name   = 8,
+   .start  = 54 + IH2_BASE,
+   .flags  = IORESOURCE_IRQ,
+   },
+   [10] = {
+   .name  = 9,
+   .start = 55 + IH2_BASE,
+   .flags = IORESOURCE_IRQ,
+   },
+   [11] = {
+   .name  = 10,
+   .start = 56 + IH2_BASE,
+   .flags = IORESOURCE_IRQ,
+   },
+   [12] = {
+   .name  = 11,
+   .start = 57 + IH2_BASE,
+   .flags = IORESOURCE_IRQ,
+   },
+   [13] = {
+   .name  = 12,
+   .start = 58 + IH2_BASE,
+   .flags = IORESOURCE_IRQ,
+   },
+   [14] = {
+   .name  = 13,
+   .start = 59 + IH2_BASE,
+   .flags = IORESOURCE_IRQ,
+   },
+   [15] = {
+   .name  = 14,
+   .start = 60 + IH2_BASE,
+   .flags = IORESOURCE_IRQ,
+   },
+   [16] = {
+   .name  = 15,
+   .start = 61 + IH2_BASE,
+   .flags = IORESOURCE_IRQ,
+   },
+   [17] = {
+   .name  = 16,
+   .start = 62 + IH2_BASE,
+   .flags = IORESOURCE_IRQ,
+   },
+};
+
+static int __init omap1_system_dma_init(void)
+{
+   struct omap_system_dma_plat_info*p;
+   struct platform_device  *pdev;
+   int ret;
+
+   pdev = platform_device_alloc(omap_dma_system, 0);
+   if (!pdev) {
+   pr_err(%s: Unable to device alloc for dma\n,
+   __func__);
+   return -ENOMEM;
+   }
+
+   ret = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
+   if (ret) {
+   dev_err(pdev-dev, %s: Unable to add

[PATCH v5 08/14] OMAP2+: DMA: hwmod: Device registration

Prepare OMAP2+ DMA to use hwmod infrastructure so that DMA can register
as platform device.

Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
 arch/arm/mach-omap2/dma.c |   74 +
 1 files changed, 74 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/dma.c

diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
new file mode 100644
index 000..e2c897a
--- /dev/null
+++ b/arch/arm/mach-omap2/dma.c
@@ -0,0 +1,74 @@
+/*
+ * OMAP2+ DMA driver
+ *
+ * Copyright (C) 2003 - 2008 Nokia Corporation
+ * Author: Juha YrjÃ¶lÃ¤ juha.yrj...@nokia.com
+ * DMA channel linking for 1610 by Samuel Ortiz samuel.or...@nokia.com
+ * Graphics DMA and LCD DMA graphics tranformations
+ * by Imre Deak imre.d...@nokia.com
+ * OMAP2/3 support Copyright (C) 2004-2007 Texas Instruments, Inc.
+ * Some functions based on earlier dma-omap.c Copyright (C) 2001 RidgeRun, Inc.
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Added OMAP4 support - Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Converted DMA library into platform driver
+ * - G, Manjunath Kondaiah manj...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/err.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/init.h
+#include linux/device.h
+
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
+#include plat/dma.h
+
+static struct omap_device_pm_latency omap2_dma_latency[] = {
+   {
+   .deactivate_func = omap_device_idle_hwmods,
+   .activate_func   = omap_device_enable_hwmods,
+   .flags   = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+   },
+};
+
+/* One time initializations */
+static int __init omap2_system_dma_init_dev(struct omap_hwmod *oh, void 
*unused)
+{
+   struct omap_device  *od;
+   struct omap_system_dma_plat_info*p;
+   char*name = omap_dma_system;
+
+   p = kzalloc(sizeof(struct omap_system_dma_plat_info), GFP_KERNEL);
+   if (!p) {
+   pr_err(%s: Unable to allocate pdata for %s:%s\n,
+   __func__, name, oh-name);
+   return -ENOMEM;
+   }
+
+   od = omap_device_build(name, 0, oh, p, sizeof(*p),
+   omap2_dma_latency, ARRAY_SIZE(omap2_dma_latency), 0);
+   kfree(p);
+   if (IS_ERR(od)) {
+   pr_err(%s: Cant build omap_device for %s:%s.\n,
+   __func__, name, oh-name);
+   return IS_ERR(od);
+   }
+
+   return 0;
+}
+
+static int __init omap2_system_dma_init(void)
+{
+   return (omap_hwmod_for_each_by_class(dma,
+   omap2_system_dma_init_dev, NULL));
+}
+arch_initcall(omap2_system_dma_init);
-- 
1.7.1

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

[PATCH v5 11/14] OMAP2+: DMA: descriptor autoloading feature

From: Venkatraman S svenk...@ti.com

Add sDMA driver support for descriptor autoloading feature.
Descriptor autoloading is OMAP sDMA v5 hardware capability that can be
exploited for scatter gather scenarios, currently available in OMAP3630
and OMAP4430.

The feature works as described below.
1. A sDMA channel is programmed to be in 'linked list' mode.
2) The client (sDMA user) provides a list of descriptors in a linked
list format
3) Each of the 'descriptor' (element in the linked list) contains an
updated set of DMA configuration register values.
4) Client starts DMA transfer.
5) sDMA controller loads the first element to its register configuration
memory and executes the transfer.
6) After completion, loads the next element (in linked list) to
configuration memory and executes the transfer, without MCU
intervention.
7) Interrupt is generated after all transfers are completed; this can be
configured to be done differently.

Configurations and additional features
1) Fast mode  non-fast mode
Fast mode/non-fast decides on how the first transfer begins. In non-fast
mode, the first element in the linked list is loaded only after
completing the
transfer according to the configurations already in the sDMA channel
registers.
In fast mode, the loading of the first element precedes the transfer.

2) Pause / resume of transfers
A transfer can be paused after a descriptor set has been loaded,
provided the pause bit' is set in the linked list element.
An ongoing transfer cannot be paused. If the 'pause bit' is set,
transfer is not started after loading the register set from memory.
Such a transfer can be resumed later.

3) Descriptor types
Three possible configurations of descriptors (initialized as linked list
elements) are possible.
Type 1 provides the maximum flexibility, which contains most register
definitions of a DMA logical channel.
Fewer options are present in type 2.
Type 3 can just modify source/destinations address of transfers. In all
transfers, unmodified registers settings are maintained for the next
transfer.

Patch provides options / API for
1) Setting up a descriptor loading for DMA channel for sg type transfers
2) configuration with linked list elements
3) Starting / pause and resume of the said transfers, query state
4) Clearing the sglist mode

Signed-off-by: Venkatraman S svenk...@ti.com
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
 arch/arm/mach-omap2/dma.c  |  249 
 arch/arm/mach-omap2/include/mach/dma.h |   87 +++
 arch/arm/plat-omap/dma.c   |2 +-
 arch/arm/plat-omap/include/plat/dma.h  |  108 ++
 4 files changed, 445 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index 2ce1969..290b40c 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -39,6 +39,7 @@
 static u32 errata;
 static u8 dma_stride;
 static int dma_chan_count;
+static int dma_caps0_status;
 
 static struct omap_dma_dev_attr *d;
 static struct dma_link_info *dma_linked_lch;
@@ -253,6 +254,76 @@ static inline void omap2_disable_lnk(int lch)
dma_chan[lch].flags = ~OMAP_DMA_ACTIVE;
 }
 
+static inline void omap_dma_list_set_ntype(struct omap_dma_sglist_node *node,
+  int value)
+{
+   node-num_of_elem |= ((value)  29);
+}
+
+static void omap_set_dma_sglist_pausebit(
+   struct omap_dma_list_config_params *lcfg, int nelem, int set)
+{
+   struct omap_dma_sglist_node *sgn = lcfg-sghead;
+
+   if (nelem  0  nelem  lcfg-num_elem) {
+   lcfg-pausenode = nelem;
+   sgn += nelem;
+
+   if (set)
+   sgn-next_desc_add_ptr |= DMA_LIST_DESC_PAUSE;
+   else
+   sgn-next_desc_add_ptr = ~(DMA_LIST_DESC_PAUSE);
+   }
+}
+
+static int dma_sglist_set_phy_params(struct omap_dma_sglist_node *sghead,
+   dma_addr_t phyaddr, int nelem)
+{
+   struct omap_dma_sglist_node *sgcurr, *sgprev;
+   dma_addr_t elem_paddr = phyaddr;
+
+   for (sgprev = sghead;
+   sgprev  sghead + nelem;
+   sgprev++) {
+
+   sgcurr = sgprev + 1;
+   sgprev-next = sgcurr;
+   elem_paddr += (int)sizeof(*sgcurr);
+   sgprev-next_desc_add_ptr = elem_paddr;
+
+   switch (sgcurr-desc_type) {
+   case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE1:
+   omap_dma_list_set_ntype(sgprev, 1);
+   break;
+
+   case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE2a:
+   /* intentional no break */
+   case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE2b:
+   omap_dma_list_set_ntype(sgprev, 2);
+

[PATCH v5 12/14] OMAP3630: DMA: Add work around for erratum i557

DMA4 channel fails to continue with descriptor load when
pause bit is cleared through config port access while in
mstandby.

Work around: Software should configure DMA in no standby mode
or force standby before clearing the pause bit(CDPi[7]) using
mstandby mode control API's.

Applicable for all versions of OMAP3630 silicons.

Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
 arch/arm/mach-omap2/dma.c |   18 ++
 arch/arm/plat-omap/include/plat/dma.h |1 +
 2 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index 290b40c..86c8d20 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -689,6 +689,17 @@ static u32 configure_dma_errata(void)
if (cpu_is_omap34xx()  (omap_type() != OMAP2_DEVICE_TYPE_GP))
SET_DMA_ERRATA(DMA_ROMCODE_BUG);
 
+   /*
+* Erratum i557 - DMA4 channel fails to continue with descriptor load
+* when pause bit is cleared through config port access while in
+* standby.
+* Work around: Software should configure DMA in no standby mode or
+* Force standby before clearing the pause bit(CDPi[7]).
+* Applicable for all versions of OMAP3630 silicons.
+*/
+   if (cpu_is_omap3630())
+   SET_DMA_ERRATA(DMA_ERRATA_i557);
+
return errata;
 }
 
@@ -1431,12 +1442,19 @@ int omap_resume_dma_sglist_transfers(int lch, int 
pauseafter)
 */
wmb();
 
+   if (IS_DMA_ERRATA(DMA_ERRATA_i557))
+   omap_device_require_no_mstandby(pd);
+
/* Clear pause bit in CDP */
l = dma_read(CDP, lch);
l = ~(DMA_LIST_CDP_PAUSEMODE);
dma_write(l, CDP, lch);
 
omap_start_dma(lch);
+
+   if (IS_DMA_ERRATA(DMA_ERRATA_i88))
+   omap_device_release_no_mstandby(pd);
+
return 0;
 }
 EXPORT_SYMBOL(omap_resume_dma_sglist_transfers);
diff --git a/arch/arm/plat-omap/include/plat/dma.h 
b/arch/arm/plat-omap/include/plat/dma.h
index fd378f6..e18603d 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -285,6 +285,7 @@
 #define DMA_ERRATA_i88 BIT(0x4)
 #define DMA_ERRATA_3_3 BIT(0x5)
 #define DMA_ROMCODE_BUGBIT(0x6)
+#define DMA_ERRATA_i557BIT(0x7)
 
 /* Attributes for OMAP DMA Contrller */
 #define DMA_LINKED_LCH BIT(0x0)
-- 
1.7.1

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

[PATCH v5 13/14] OMAP2+: DMA: Replace sysconfig register access with API's

Few errata in OMAP2+ DMA driver require forcing DMA controller
mstandby mode to 'no standby' mode. Current implementation
directly access sysconfig registers for this operation.

Since there are API's for controlling mstandby mode, cleanup
sysconfig register access and replace the same with API's.

Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
 arch/arm/mach-omap1/dma.c |2 ++
 arch/arm/mach-omap2/dma.c |   15 ++-
 arch/arm/plat-omap/dma.c  |   13 -
 arch/arm/plat-omap/include/plat/dma.h |   17 ++---
 4 files changed, 14 insertions(+), 33 deletions(-)

diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
index 80c3380..57f5415 100644
--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -642,6 +642,8 @@ static int __init omap1_system_dma_init(void)
p-clear_channel_int= NULL;
p-set_global_params= NULL;
p-disable_irq_lch  = NULL;
+   p-require_no_mstandby  = NULL;
+   p-release_no_mstandby  = NULL;
 
p-errata = configure_dma_errata();
 
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index 86c8d20..b50ecee 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -1156,7 +1156,6 @@ int omap_stop_dma_chain_transfers(int chain_id)
 {
int *channels;
u32 l, i;
-   u32 sys_cf = 0;
 
/* Check for input params */
if (unlikely((chain_id  0 || chain_id = dma_chan_count))) {
@@ -1171,13 +1170,9 @@ int omap_stop_dma_chain_transfers(int chain_id)
}
channels = dma_linked_lch[chain_id].linked_dmach_q;
 
-   if (IS_DMA_ERRATA(DMA_ERRATA_i88)) {
-   sys_cf = dma_read(OCP_SYSCONFIG, 0);
-   l = sys_cf;
-   /* Middle mode reg set no Standby */
-   l = ~((1  12)|(1  13));
-   dma_write(l, OCP_SYSCONFIG, 0);
-   }
+   if (IS_DMA_ERRATA(DMA_ERRATA_i88))
+   omap_device_require_no_mstandby(pd);
+
for (i = 0; i  dma_linked_lch[chain_id].no_of_lchs_linked; i++) {
 
/* Stop the Channel transmission */
@@ -1196,7 +1191,7 @@ int omap_stop_dma_chain_transfers(int chain_id)
OMAP_DMA_CHAIN_QINIT(chain_id);
 
if (IS_DMA_ERRATA(DMA_ERRATA_i88))
-   dma_write(sys_cf, OCP_SYSCONFIG, 0);
+   omap_device_release_no_mstandby(pd);
 
return 0;
 }
@@ -1540,6 +1535,8 @@ static int __init omap2_system_dma_init_dev(struct 
omap_hwmod *oh, void *unused)
p-dma_write= dma_write;
p-dma_read = dma_read;
p-clear_sglist_mode= omap2_clear_dma_sglist_mode;
+   p-require_no_mstandby  = omap_device_require_no_mstandby;
+   p-release_no_mstandby  = omap_device_release_no_mstandby;
 
p-clear_lch_regs   = NULL;
p-get_gdma_dev = NULL;
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 8563370..a859c70 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -39,6 +39,7 @@
 static struct omap_system_dma_plat_info *p;
 static struct omap_dma_dev_attr *d;
 static struct omap_dma_lch *dma_chan;
+static struct platform_device  *pd;
 
 static int enable_1510_mode;
 static int dma_lch_count;
@@ -523,14 +524,8 @@ void omap_stop_dma(int lch)
if (IS_DMA_ERRATA(DMA_ERRATA_i541) 
(l  OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
int i = 0;
-   u32 sys_cf;
 
-   /* Configure No-Standby */
-   l = p-dma_read(OCP_SYSCONFIG, lch);
-   sys_cf = l;
-   l = ~DMA_SYSCONFIG_MIDLEMODE_MASK;
-   l |= DMA_SYSCONFIG_MIDLEMODE(DMA_IDLEMODE_NO_IDLE);
-   p-dma_write(l , OCP_SYSCONFIG, 0);
+   p-require_no_mstandby(pd);
 
l = p-dma_read(CCR, lch);
l = ~OMAP_DMA_CCR_EN;
@@ -547,8 +542,7 @@ void omap_stop_dma(int lch)
if (i = 100)
printk(KERN_ERR DMA drain did not complete on 
lch %d\n, lch);
-   /* Restore OCP_SYSCONFIG */
-   p-dma_write(sys_cf, OCP_SYSCONFIG, lch);
+   p-release_no_mstandby(pd);
} else {
l = ~OMAP_DMA_CCR_EN;
p-dma_write(l, CCR, lch);
@@ -727,6 +721,7 @@ static int __devinit omap_system_dma_probe(struct 
platform_device *pdev)
return -EINVAL;
}
 
+   pd  = pdev;
d   = p-dma_attr;
errata  = p-errata;
 
diff --git a/arch/arm/plat-omap/include/plat/dma.h 
b/arch/arm/plat-omap/include/plat/dma.h
index e18603d..9cb9fbd 100644

[PATCH v5 14/14] OMAP: PM: DMA: Enable runtime pm

Enable runtime pm and use pm_runtime_get_sync and pm_runtime_put
for OMAP DMA driver.

Since DMA driver callback will happen from interrupt context and
DMA client driver will release all DMA resources from interrupt
context itself, pm_runtime_put_sync() cannot be used in DMA driver.
Instead, pm_runtime_put() is used which is asynchronous call and
gets executed in work queue.

Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
 arch/arm/plat-omap/dma.c |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index a859c70..527ebfc 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -32,6 +32,7 @@
 #include linux/io.h
 #include linux/slab.h
 #include linux/delay.h
+#include linux/pm_runtime.h
 
 #include plat/dma.h
 #include plat/tc.h
@@ -302,6 +303,7 @@ int omap_request_dma(int dev_id, const char *dev_name,
unsigned long flags;
struct omap_dma_lch *chan;
 
+   pm_runtime_get_sync(pd-dev);
spin_lock_irqsave(dma_chan_lock, flags);
for (ch = 0; ch  dma_chan_count; ch++) {
if (free_ch == -1  dma_chan[ch].dev_id == -1) {
@@ -312,6 +314,7 @@ int omap_request_dma(int dev_id, const char *dev_name,
}
if (free_ch == -1) {
spin_unlock_irqrestore(dma_chan_lock, flags);
+   pm_runtime_put(pd-dev);
return -EBUSY;
}
chan = dma_chan + free_ch;
@@ -403,6 +406,7 @@ void omap_free_dma(int lch)
omap_clear_dma(lch);
p-clear_sglist_mode(lch);
}
+   pm_runtime_put(pd-dev);
spin_lock_irqsave(dma_chan_lock, flags);
dma_chan[lch].dev_id = -1;
dma_chan[lch].next_lch = -1;
@@ -734,6 +738,9 @@ static int __devinit omap_system_dma_probe(struct 
platform_device *pdev)
dma_chan= d-chan;
enable_1510_mode= d-dev_caps  ENABLE_1510_MODE;
 
+   pm_runtime_enable(pd-dev);
+   pm_runtime_get_sync(pd-dev);
+
spin_lock_init(dma_chan_lock);
for (ch = 0; ch  dma_chan_count; ch++) {
unsigned long flags;
@@ -760,6 +767,14 @@ static int __devinit omap_system_dma_probe(struct 
platform_device *pdev)
dma_chan[1].dev_id = 1;
}
p-show_dma_caps();
+
+   /*
+* Note: If dma channels are reserved through boot paramters,
+* then dma device is always enabled.
+*/
+   if (!omap_dma_reserve_channels)
+   pm_runtime_put(pd-dev);
+
return 0;
 }
 
-- 
1.7.1

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

Re: [PATCH v4 2/5] OMAP: mailbox: fix rx interrupt disable in omap4

On Wed, Nov 24, 2010 at 2:50 AM, Varadarajan, Charulatha ch...@ti.com wrote:
 On Wed, Nov 24, 2010 at 13:52, Felipe Balbi ba...@ti.com wrote:
 On Wed, Nov 24, 2010 at 10:46:04AM +0530, Varadarajan, Charulatha wrote:

 diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
 index 48e161c..a1c6bd9 100644
 --- a/arch/arm/plat-omap/mailbox.c
 +++ b/arch/arm/plat-omap/mailbox.c
 @@ -358,6 +358,10 @@ int omap_mbox_register(struct device *parent, struct
 omap_mbox **list)
                        ret = PTR_ERR(mbox-dev);
                        goto err_out;
                }
 +               if (cpu_is_omap44xx())

 Do not use cpu_is* checks in plat-omap/*

 see the previous thread.

 Referring to [1], I do not find why cpu_is* checks is used in plat-omap and
 why it can't be avoided.

 In [1], it was suggested to create the pdata field that will be
 populated at init
 time using the cpu_is* check. But in this version, I am finding that
 this is done
 in plat-omap. This can be handled in mach-omap layer itself and can be passed
 as a pdata field which can be extracted during probe.

 [1] https://patchwork.kernel.org/patch/337131/


Here are these  reasons why I did this way.

- The function omap_mbox_register is called only once during probe
time, and I thought it was ok to call cpu check once during probe
time. Since each mbox instance needs to be aware of the rev field this
was the right place to add since this function iterates through the
list during probe time. There are already calls to cpu_is_omap44xx in
mailbox probe function.

- platform data is not present for mailbox module. I could add it for
revision sake but I would prefer not to do that since this will be a
throw away code once the hwmod infrastructure is ready (note: mailbox
hwmod patches are under review), and amount of mailbox driver rework
might be considerable.

- I could wait till the hwmod patches are ready to include this
change, but don't want to put the dependency with hwmod since this is
a critical fix and want to make it available in the mainline kernel.

Please let me know what you suggest.

Thank you,
Best regards,
Hari Kanigeri
--
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 v4 1/5] OMAP: mailbox: change full flag per mailbox queue instead of global

On Wed, Nov 24, 2010 at 18:17, Kanigeri, Hari h-kanige...@ti.com wrote:
 On Tue, Nov 23, 2010 at 11:21 PM, Varadarajan, Charulatha ch...@ti.com 
 wrote:
 On Wed, Nov 24, 2010 at 02:56, Hari Kanigeri h-kanige...@ti.com wrote:
 From: Fernando Guzman Lugo x0095...@ti.com

 The variable rq_full flag is a global variable, so if there are multiple
 mailbox users there will be conflicts. Now there is a full flag per
 mailbox queue.

 Reported-by: Ohad Ben-Cohen o...@wizery.com
 Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
 Signed-off-by: Hari Kanigeri h-kanige...@ti.com
 ---
  arch/arm/plat-omap/include/plat/mailbox.h |    1 +
  arch/arm/plat-omap/mailbox.c              |    9 +++--
  2 files changed, 8 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/plat-omap/include/plat/mailbox.h 
 b/arch/arm/plat-omap/include/plat/mailbox.h
 index 9976565..13f2ef3 100644
 --- a/arch/arm/plat-omap/include/plat/mailbox.h
 +++ b/arch/arm/plat-omap/include/plat/mailbox.h
 @@ -48,6 +48,7 @@ struct omap_mbox_queue {
        struct tasklet_struct   tasklet;
        int     (*callback)(void *);
        struct omap_mbox        *mbox;
 +       bool full;
  };

  struct omap_mbox {
 diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
 index d2fafb8..48e161c 100644
 --- a/arch/arm/plat-omap/mailbox.c
 +++ b/arch/arm/plat-omap/mailbox.c
 @@ -33,7 +33,6 @@

  static struct workqueue_struct *mboxd;
  static struct omap_mbox **mboxes;
 -static bool rq_full;

  static int mbox_configured;
  static DEFINE_MUTEX(mbox_configured_lock);
 @@ -148,6 +147,12 @@ static void mbox_rx_work(struct work_struct *work)

                if (mq-callback)
                        mq-callback((void *)msg);
 +               spin_lock_irq(mq-lock);
 +               if (mq-full) {
 +                       mq-full = false;
 +                       omap_mbox_enable_irq(mq-mbox, IRQ_RX);
 +               }
 +               spin_unlock_irq(mq-lock);
        }
  }

 @@ -170,7 +175,7 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
        while (!mbox_fifo_empty(mbox)) {
                if (unlikely(kfifo_avail(mq-fifo)  sizeof(msg))) {
                        omap_mbox_disable_irq(mbox, IRQ_RX);
 -                       rq_full = true;
 +                       mq-full = true;

 Should this also be inside spin_lock_irq?


 Not needed. this is already run from interrupt context.

oh ok.


 Thank you,
 Best regards,
 Hari

--
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 v4 5/5] OMAP: mailbox: add notification support for multiple readers

On Tue, Nov 23, 2010 at 11:29 PM, Varadarajan, Charulatha ch...@ti.com wrote:
 On Wed, Nov 24, 2010 at 02:56, Hari Kanigeri h-kanige...@ti.com wrote:
 In the current mailbox driver, the mailbox internal pointer for
 callback can be directly manipulated by the Users, so a second
 User can easily corrupt the first user's callback pointer.
 The initial effort to correct this issue can be referred here:
 https://patchwork.kernel.org/patch/107520/

 Along with fixing the above stated issue, this patch  adds the
 flexibility option to register notifications from
 multiple readers to the events received on a mailbox instance.
 The discussion regarding this can be referred here.
 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30671.html

 Signed-off-by: Hari Kanigeri h-kanige...@ti.com
 Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
 ---
  arch/arm/plat-omap/include/plat/mailbox.h |    7 +-
  arch/arm/plat-omap/mailbox.c              |  104 
 -
  2 files changed, 62 insertions(+), 49 deletions(-)


 snip

 @@ -363,10 +372,13 @@ int omap_mbox_register(struct device *parent, struct 
 omap_mbox **list)
                        ret = PTR_ERR(mbox-dev);
                        goto err_out;
                }
 +

 Do this change in the patch where the below code was added.

I am sorry I didn't get you. you mean BLOCKING_INIT_NOTIFIER_HEAD line
? yes, it is needed for this patch.

                if (cpu_is_omap44xx())
                        mbox-rev = OMAP_MBOX_IP_VERSION_2;
                else
                        mbox-rev = OMAP_MBOX_IP_LEGACY;
 +
 +               BLOCKING_INIT_NOTIFIER_HEAD(mbox-notifier);
        }
        return 0;

 --
 1.7.0





-- 
Thank you,
Best regards,
Hari Kanigeri
--
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 v4 5/5] OMAP: mailbox: add notification support for multiple readers

On Wed, Nov 24, 2010 at 18:39, Kanigeri, Hari h-kanige...@ti.com wrote:
 On Tue, Nov 23, 2010 at 11:29 PM, Varadarajan, Charulatha ch...@ti.com 
 wrote:
 On Wed, Nov 24, 2010 at 02:56, Hari Kanigeri h-kanige...@ti.com wrote:
 In the current mailbox driver, the mailbox internal pointer for
 callback can be directly manipulated by the Users, so a second
 User can easily corrupt the first user's callback pointer.
 The initial effort to correct this issue can be referred here:
 https://patchwork.kernel.org/patch/107520/

 Along with fixing the above stated issue, this patch  adds the
 flexibility option to register notifications from
 multiple readers to the events received on a mailbox instance.
 The discussion regarding this can be referred here.
 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30671.html

 Signed-off-by: Hari Kanigeri h-kanige...@ti.com
 Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
 ---
  arch/arm/plat-omap/include/plat/mailbox.h |    7 +-
  arch/arm/plat-omap/mailbox.c              |  104 
 -
  2 files changed, 62 insertions(+), 49 deletions(-)


 snip

 @@ -363,10 +372,13 @@ int omap_mbox_register(struct device *parent, struct 
 omap_mbox **list)
                        ret = PTR_ERR(mbox-dev);
                        goto err_out;
                }
 +

 Do this change in the patch where the below code was added.

 I am sorry I didn't get you. you mean BLOCKING_INIT_NOTIFIER_HEAD line
 ? yes, it is needed for this patch.

No. I was saying that adding a new line could be done in the patch where this
piece of code (below 4 lines) was introduced. Sorry if that was not clear :-(


                if (cpu_is_omap44xx())
                        mbox-rev = OMAP_MBOX_IP_VERSION_2;
                else
                        mbox-rev = OMAP_MBOX_IP_LEGACY;
 +
 +               BLOCKING_INIT_NOTIFIER_HEAD(mbox-notifier);
        }
        return 0;

 --
 1.7.0





 --
 Thank you,
 Best regards,
 Hari Kanigeri

--
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 v4 4/5] OMAP: mailbox: send message in process context

On Tue, Nov 23, 2010 at 11:26 PM, Varadarajan, Charulatha ch...@ti.com wrote:
 On Wed, Nov 24, 2010 at 02:56, Hari Kanigeri h-kanige...@ti.com wrote:
 Schedule the Tasklet to send only when mailbox fifo is full and there are
 pending messages in kifo, else send the message directly in the Process

 Typo - kifo

Thanks :). My bad I I think overlooked Felipe's comment on my previous patch.

Thank you,
Best regards,
Hari Kanigeri
--
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 v4 5/5] OMAP: mailbox: add notification support for multiple readers

On Wed, Nov 24, 2010 at 7:12 AM, Varadarajan, Charulatha ch...@ti.com wrote:
 On Wed, Nov 24, 2010 at 18:39, Kanigeri, Hari h-kanige...@ti.com wrote:
 On Tue, Nov 23, 2010 at 11:29 PM, Varadarajan, Charulatha ch...@ti.com 
 wrote:
 On Wed, Nov 24, 2010 at 02:56, Hari Kanigeri h-kanige...@ti.com wrote:
 In the current mailbox driver, the mailbox internal pointer for
 callback can be directly manipulated by the Users, so a second
 User can easily corrupt the first user's callback pointer.
 The initial effort to correct this issue can be referred here:
 https://patchwork.kernel.org/patch/107520/

 Along with fixing the above stated issue, this patch  adds the
 flexibility option to register notifications from
 multiple readers to the events received on a mailbox instance.
 The discussion regarding this can be referred here.
 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30671.html

 Signed-off-by: Hari Kanigeri h-kanige...@ti.com
 Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
 ---
  arch/arm/plat-omap/include/plat/mailbox.h |    7 +-
  arch/arm/plat-omap/mailbox.c              |  104 
 -
  2 files changed, 62 insertions(+), 49 deletions(-)


 snip

 @@ -363,10 +372,13 @@ int omap_mbox_register(struct device *parent, struct 
 omap_mbox **list)
                        ret = PTR_ERR(mbox-dev);
                        goto err_out;
                }
 +

 Do this change in the patch where the below code was added.

 I am sorry I didn't get you. you mean BLOCKING_INIT_NOTIFIER_HEAD line
 ? yes, it is needed for this patch.

 No. I was saying that adding a new line could be done in the patch where this
 piece of code (below 4 lines) was introduced. Sorry if that was not clear :-(

Got it. extra line can be removed.

Thank you,
Best regards,
Hari Kanigeri
--
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: No more software ECC in omap2.c NAND driver. Why?

2010-11-24 Thread Ghorai, Sukumar



 [..snip..]
 % mkfs.jffs2 --little-endian --no-cleanmarkers --pad 2048 --pagesize 2048
 --eraseblock 131072 -d /tmp/tmp.h9dKGpcNFw -D root.devices -o root.jffs2
 
  nand write.i ${loadaddr} 0x00c0 0x200
  nand write.i ${loadaddr} 0x0420 0x200
 
  [Ghorai] why you writing in two places?
 
 Redundant images.
 
  Following that, the board is updated, from Linux, using 'flash_eraseall
 -
  q'
  and 'nandwrite -p -q' on all partitions, except that containing MLO.
  [Ghorai]
 
  1. can you send the exact comment you used to write in nand? Which
 partition?
 
 flash_eraseall -q /dev/mtd7
 nandwrite -p -q /dev/mtd7 root.jffs2
 flash_eraseal -q /dev/mtd9
 nandwrite -p -q /dev/mtd9 root.jffs2
 
  2. What is the last kernel you used and was working perfectly?
 v2.6.32_OMAPPSP_03.00.01.06.patch1

[Ghorai] I followed the steps you mentioned. Also I used the following command 
to mount the jffs2 FS and working fine.
mount -t jffs2 /dev/mtdblock3 /mnt/nand

I have tested in zoom3 -
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xbc (Micron NAND 512MiB 1,8V 
16-bit).

And using the latest kernel -
Uncompressing Linux... done, booting the kernel.
[0.00] Linux version 2.6.37-rc3-00102-gea49b16 (a0393...@omapldc12) 
(gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #20 SMP Wed Nov 24 17:27:21 
IST 2010 

Would you please share your latest log? 
--
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 RESEND] ASoC: Fix resource reclaim for osk5912

2010-11-24 Thread Axel Lin

In current implementation, there are resources leak in the error path.
This patch properly reclaims the allocated resources in the error path.

Also adds a missing clk_put in osk_soc_exit.

Signed-off-by: Axel Lin axel@gmail.com
Acked-by: Jarkko Nikula jhnik...@gmail.com
---
 sound/soc/omap/osk5912.c |   11 ---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/sound/soc/omap/osk5912.c b/sound/soc/omap/osk5912.c
index 18d053d..7e75e77 100644
--- a/sound/soc/omap/osk5912.c
+++ b/sound/soc/omap/osk5912.c
@@ -177,7 +177,8 @@ static int __init osk_soc_init(void)
tlv320aic23_mclk = clk_get(dev, mclk);
if (IS_ERR(tlv320aic23_mclk)) {
printk(KERN_ERR Could not get mclk clock\n);
-   return -ENODEV;
+   err = PTR_ERR(tlv320aic23_mclk);
+   goto err2;
}
 
/*
@@ -188,7 +189,7 @@ static int __init osk_soc_init(void)
if (clk_set_rate(tlv320aic23_mclk, CODEC_CLOCK)) {
printk(KERN_ERR Cannot set MCLK for AIC23 CODEC\n);
err = -ECANCELED;
-   goto err1;
+   goto err3;
}
}
 
@@ -196,9 +197,12 @@ static int __init osk_soc_init(void)
   (uint) clk_get_rate(tlv320aic23_mclk), CODEC_CLOCK);
 
return 0;
-err1:
+
+err3:
clk_put(tlv320aic23_mclk);
+err2:
platform_device_del(osk_snd_device);
+err1:
platform_device_put(osk_snd_device);
 
return err;
@@ -207,6 +211,7 @@ err1:
 
 static void __exit osk_soc_exit(void)
 {
+   clk_put(tlv320aic23_mclk);
platform_device_unregister(osk_snd_device);
 }
 
-- 
1.7.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

Re: [PATCH ver. 2] PM: add synchronous runtime interface for interrupt handlers

2010-11-24 Thread Alan Stern

On Tue, 23 Nov 2010, Rafael J. Wysocki wrote:

  Or maybe you think that when pm_runtime_put_sync detects the 
  usage_count has decremented to 0 and the device is irq-safe, it should 
  call rpm_suspend directly instead of calling rpm_idle?
 
 That also would work for me, actually.

Okay, then consider this proposal.  I'll introduce a new
pm_runtime_put_sync_suspend() function which decrements the usage_count
and calls rpm_suspend directly if the count drops to 0.  Then interrupt
handlers could use this function in place of pm_runtime_put_sync(),
provided the device was irq-safe.

Not only that, pm_runtime_put_sync_suspend() would be available for
anyone to use.  It must be reasonably common for runtime_idle routines
to do nothing but call pm_runtime_suspend().  The new API call would
save a little overhead.

Alan Stern

--
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: DSP Bridge video decode of above VGA videos

2010-11-24 Thread James Adams

Many thanks for the help Rene, it makes a huge difference being told
whereabouts in the gigabytes of source to start looking!

You are quite correct in that the error comes from NODE_Create.
Node_Create calls DISP_NodeCreate
DISP_NodeCreate calls SendMessage
SendMessage succeeds, but after CHNL_IsIOComplete reads back a status
code from chnlIOC.pBuf which has the error code in it.

My understanding is that this means that the dsp bridge kernel has sent
a message across to the TI DSP, but the DSP is reporting out of memory.

Unfortunately, I don't know where to go from here, any tips?

I've looked at the DSP bridge documents but I still don't really have a
handle on the memory allocation.
My understanding is that:
1) The DSP and ARM share access to the same memory chips
2) The DSP bridge allocates shm_size memory for page tables and
communications
3) The DSP bridge assigns phys_mempool_size memory at a fixed address
for the DSP to store its own data inside
I don't understand where the streaming data gets allocated.

I've tried increasing phys_mempool_size but it behaves the same.

I've added printk to the allocation routines in mem.c, but none of these
are failing.  (Although I suspect they are irrelevant and it is some
memory manager running on the DSP that is failing)

Testing some other sizes I find that 800x480, 854x480, 864x480,
800x512 and 854x480 play, but
960x480, 800x528, 800x544, 880x480 do not.

Is it possible that the TI binaries will always return EMEMORY if too
high a resolution is requested?

Any advice much appreciated!




On Wed, Nov 24, 2010 at 12:38 AM, Sapiens, Rene rene.sapi...@ti.com wrote:
 Hi James,

 The second error log is the stack trace when the watchdog timer calls
 SYNC_EnterCS.

 Actually is not the WDT calling the function to get into the critical
 section, it is the WDT being disabled when the DSP is going to OFF
 state. This should fine.

 The stack trace is shown below.


 1) Is this trace printed after the 'if (in_interrupt())' statement?
 2) Can you check under drivers/dsp/bridge/ to see where is or under
 which context io_dispatchpm called?

 To get the assertions failing you should be in the context of an
 interrupt, the code base that i have is not that way for that reason i
 ask for your io_dispatchpm function.

 [c0412864] (dump_stack+0x0/0x14) from [c0278c18]
 (SYNC_EnterCS+0x48/0xe4)
 [c0278bd0] (SYNC_EnterCS+0x0/0xe4) from [c0279e24]
 (REG_GetValue+0x60/0xa0)
  r5:c05ba390 r4:c04f092c
 [c0279dc4] (REG_GetValue+0x0/0xa0) from [c027987c]
 (CFG_GetObject+0x60/0xe0)
  r7:cfa87a80 r6:0002 r5:cf98fe94 r4:0002
 [c027981c] (CFG_GetObject+0x0/0xe0) from [c02913c0]
 (DRV_GetFirstDevObject+0
 x1c/0x4c)
  r5:c05ba3c0 r4:
 [c02913a4] (DRV_GetFirstDevObject+0x0/0x4c) from [c02858e4]
 (DEV_GetFirst+0x
 10/0x44)
 [c02858d4] (DEV_GetFirst+0x0/0x44) from [c027d430]
 (dsp_wdt_enable+0x44/0xe0
 )
  r5:c05ba3c0 r4:
 [c027d3ec] (dsp_wdt_enable+0x0/0xe0) from [c02820fc]
 (handle_hibernation_fro
 mDSP+0x148/0x1ec)
  r5:cfaa r4:8000
 [c0281fb4] (handle_hibernation_fromDSP+0x0/0x1ec) from [c02810c0]
 (WMD_DEV_C
 trl+0xfc/0x130)
  r7:cf98e000 r6:cf98ff34 r5:cc5f6a88 r4:cfb89e00
 [c0280fc4] (WMD_DEV_Ctrl+0x0/0x130) from [c027dc24]
 (io_mbox_msg+0x70/0x1d8)
  r7:cf98e000 r6:c05496c4 r5:cc5f6a88 r4:cfb89e00
 [c027dbb4] (io_mbox_msg+0x0/0x1d8) from [c0059308]
 (mbox_rx_work+0xf4/0x100)
  r5:cc5f6a88 r4:200a
 [c0059214] (mbox_rx_work+0x0/0x100) from [c007ebb0]
 (run_workqueue+0xc8/0x18
 4)
 [c007eae8] (run_workqueue+0x0/0x184) from [c007f2dc]
 (worker_thread+0x104/0x
 118)
  r9: r8: r7:cf811040 r6:cf94e140 r5:cf94e148
 r4:cf98e000
 [c007f1d8] (worker_thread+0x0/0x118) from [c0082cb4]
 (kthread+0x54/0x80)
  r7: r6: r5:c007f1d8 r4:cf94e140
 [c0082c60] (kthread+0x0/0x80) from [c0070b1c] (do_exit+0x0/0x7bc)
  r5: r4:
 drivers/dsp/bridge/services/sync.c, line 358: Assertion (0) failed.

 Regards,
 Rene Sapiens

--
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: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl

2010-11-24 Thread Ville Syrjälä

On Wed, Nov 24, 2010 at 03:39:44PM +0530, ext Hiremath, Vaibhav wrote:

  -Original Message-
  From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
  Sent: Wednesday, November 24, 2010 2:28 PM
  To: Hiremath, Vaibhav
  Cc: linux-omap@vger.kernel.org
  Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl

  On Tue, 2010-11-23 at 23:46 +0530, ext Hiremath, Vaibhav wrote:
   Hi,

   While supporting one of customer I came across one interesting issue and
  finding with WAITFORVSYNC ioctl -

   Problem Statement -
   ---
   With WAITFORVSYNC lots of tearing artifacts are visible on LCD output,
  but WAITFORGO works fine without any issues.

   Debugging/Findings -

   Technically both, WAITFORVSYNC and WAITFORGO wait on VSYNC interrupt -
  but there is slight difference in their implementation/processing.

  No, that's not quite right.

  WAITFORVSYNC waits for the next vsync.

 [Hiremath, Vaibhav] Yes, certainly.

  WAITFORGO waits until the the config changes for the particular overlay
  have been applied to the HW, which may take multiple vsyncs if there are
  already pending config changes. Or, if there are no changes to be
  applied, it doesn't wait at all.

 [Hiremath, Vaibhav] Yes, completely agreed. But in the panning use-case where 
 if we assume there will be always config change when you enter WAIFORGO ioctl 
 it waits for next VSYNC, and as you mentioned it may wait for multiple vsyncs 
 to make sure that config change gets applied to HW.

   WAITFORGO ioctl ensures that dirty  shadow_dirty flags (software flag)
  are cleared, making sure that hardware state and software state always
  stays in sync. It makes 4 attempts to do so - inside loop it checks for
  dirty flags and call wait_for_vsync API. In ideal usecase scenario it
  should come out in single iteration.
 snip

   Suggestions/Recommendation -
   --

   From User application point of view, user won't care about driver
  internal implementation. Application believes that WAITFORVSYNC will only
  return after displaying (DMAing) previous buffer and now with addition to
  FBIO_WAITFORVSYNC standard ioctl interface this is very well expected from
  user application as a standard behavior.

   I would recommend having WAITFORGO like implementation under
  WAITFORVSYNC, merging WAITFORGO with WAITFORVSYNC, and killing WAITFORGO
  (since we have FBIO_WAITFORVSYNC standard ioctl).
   Also WAITFORGO ioctl is OMAP specific custom ioctl.

  I have to say that I'm not quite sure what WAITFORVSYNC should do. 
 [Hiremath, Vaibhav] Me neither.

  The
  name implies that it should wait for the next vsync, which is what it
  does for omapfb.

  Changing it to WAITFORGO would alter the behaviour. Sometimes it would
  not wait at all, sometimes it could wait for multiple vsyncs.
 [Hiremath, Vaibhav] I am quite not sure, whether it makes sense from 
 application point of view to wait for vsync if config is not changed. What 
 could be the use-case for such requirement, where application won't change 
 anything but still would like to wait on vsync?

 And as far as wait on multiple vsync is concerned, it does make sense to coat 
 WAITFORVSYNC ioctl makes sure that your change got applied to HW. 

 I am not aware of other architectures, but I believe this is something OMAP 
 specific stuff. And for other platforms, WAITFORVSYNC means changes applied 
 to HW (why does apps care about whether it is vsync or anything else?).

WAITFORVSYNC waits for the next vsync (or actually vblank in many
cases). That's it. I don't see any point in trying to shoehorn
other functionality into it.

If you want to standardise WAITFORGO type of stuff then just add
another standard ioctl for it.

-- 
Ville Syrjälä
--
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 ver. 2] PM: add synchronous runtime interface for interrupt handlers

2010-11-24 Thread Alan Stern

On Tue, 23 Nov 2010, Kevin Hilman wrote:

 While I like the idea of the symmetry of having both _get_sync() and
 _put_sync() callable from an interrupt handler, I can't currently think
 of a situation where we would need to _put_sync() in the ISR.  A
 standard _put() should suffice for all cases I can imagine.

It's wasteful to go through the context switch to the workqueue process
if you don't need to.  And it's time consuming; you want to power down 
the device as soon as possible once the interrupt handler is finished, 
right?

What do you think of the pm_runtime_put_sync_suspend() proposal?

Alan Stern

--
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 02/13] OMAP3: PM: Errata i581 suppport: dll kick strategy

2010-11-24 Thread Sripathy, Vishwanath

Nishant,

On Fri, Nov 19, 2010 at 7:24 AM, Nishanth Menon n...@ti.com wrote:
 From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com

 Errata i581 impacts OMAP3 platforms.
 PRCM DPLL control FSM removes SDRC_IDLEREQ before DPLL3 locks causing
 the DPLL not to be locked at times.

 IMPORTANT: this is not a complete workaround implementation as recommended
 by the silicon errata. this is a support logic for detecting lockups and
 attempting to recover where possible and is known to provide stability
 in multiple platforms.

How does this WA work when Core enters off mode? SRAM contents are
lost when Core enters off. So how this code is copied to SRAM upon
wakeup? Where is this code placed when Core entered off mode?

Vishwa

 Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
 ---
  arch/arm/mach-omap2/sleep34xx.S |   52 +++---
  1 files changed, 47 insertions(+), 5 deletions(-)

 diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
 index 8f207b2..5a4468f 100644
 --- a/arch/arm/mach-omap2/sleep34xx.S
 +++ b/arch/arm/mach-omap2/sleep34xx.S
 @@ -42,6 +42,7 @@
                                OMAP3430_PM_PREPWSTST)
  #define PM_PWSTCTRL_MPU_P      OMAP3430_PRM_BASE + MPU_MOD + 
 OMAP2_PM_PWSTCTRL
  #define CM_IDLEST1_CORE_V      OMAP34XX_CM_REGADDR(CORE_MOD, CM_IDLEST1)
 +#define CM_IDLEST_CKGEN_V      OMAP34XX_CM_REGADDR(PLL_MOD, CM_IDLEST)
  #define SRAM_BASE_P            0x4020
  #define CONTROL_STAT           0x480022F0
  #define SCRATCHPAD_MEM_OFFS    0x310 /* Move this as correct place is
 @@ -554,31 +555,67 @@ skip_l2_inval:

  /* Make sure SDRC accesses are ok */
  wait_sdrc_ok:
 +
 +/* DPLL3 must be locked before accessing the SDRC. Maybe the HW ensures 
 this. */
 +       ldr     r4, cm_idlest_ckgen
 +wait_dpll3_lock:
 +       ldr     r5, [r4]
 +       tst     r5, #1
 +       beq     wait_dpll3_lock
 +
         ldr     r4, cm_idlest1_core
 +wait_sdrc_ready:
         ldr     r5, [r4]
 -        and     r5, r5, #0x2
 -        cmp     r5, #0
 -        bne     wait_sdrc_ok
 +        tst     r5, #0x2
 +        bne     wait_sdrc_ready
 +       /* allow DLL powerdown upon hw idle req */
         ldr     r4, sdrc_power
         ldr     r5, [r4]
         bic     r5, r5, #0x40
         str     r5, [r4]
 -wait_dll_lock:
 +is_dll_in_lock_mode:
 +
         /* Is dll in lock mode? */
         ldr     r4, sdrc_dlla_ctrl
         ldr     r5, [r4]
         tst     r5, #0x4
         bxne    lr
         /* wait till dll locks */
 -        ldr     r4, sdrc_dlla_status
 +wait_dll_lock_timed:
 +       ldr     r4, wait_dll_lock_counter
 +       add     r4, r4, #1
 +       str     r4, wait_dll_lock_counter
 +       ldr     r4, sdrc_dlla_status
 +        mov    r6, #8          /* Wait 20uS for lock */
 +wait_dll_lock:
 +       subs    r6, r6, #0x1
 +       beq     kick_dll
         ldr     r5, [r4]
         and     r5, r5, #0x4
         cmp     r5, #0x4
         bne     wait_dll_lock
         bx      lr

 +       /* disable/reenable DLL if not locked */
 +kick_dll:
 +       ldr     r4, sdrc_dlla_ctrl
 +       ldr     r5, [r4]
 +       mov     r6, r5
 +       bic     r6, #(13)     /* disable dll */
 +       str     r6, [r4]
 +       dsb
 +       orr     r6, r6, #(13) /* enable dll */
 +       str     r6, [r4]
 +       dsb
 +       ldr     r4, kick_counter
 +       add     r4, r4, #1
 +       str     r4, kick_counter
 +       b       wait_dll_lock_timed
 +
  cm_idlest1_core:
        .word   CM_IDLEST1_CORE_V
 +cm_idlest_ckgen:
 +       .word   CM_IDLEST_CKGEN_V
  sdrc_dlla_status:
        .word   SDRC_DLLA_STATUS_V
  sdrc_dlla_ctrl:
 @@ -615,5 +652,10 @@ control_stat:
        .word   CONTROL_STAT
  kernel_flush:
        .word v7_flush_dcache_all
 +       /* these 2 words need to be at the end !!! */
 +kick_counter:
 +       .word   0
 +wait_dll_lock_counter:
 +       .word   0
  ENTRY(omap34xx_cpu_suspend_sz)
        .word   . - omap34xx_cpu_suspend
 --
 1.6.3.3


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

[PATCH v5 0/3] OMAP: Add opp data

Major changes in V5:
rebased to k.org 2.6.37-rc3
introduced omap_opp_data.h
couple of whitespace and offline license suggestion cleanups

V4: http://marc.info/?l=linux-omapm=128993367112637w=2
V3: http://marc.info/?l=linux-omapm=128984926812800w=2
V2: http://marc.info/?t=12875366533r=1w=2

Kevin Hilman (1):
  OMAP3: remove OPP interfaces from OMAP PM layer

Nishanth Menon (2):
  omap: opp: add OMAP3 OPP table data and common init
  omap4: opp: add OPP table data

 Documentation/arm/OMAP/omap_pm|   25 +++
 arch/arm/mach-omap2/Kconfig   |4 +
 arch/arm/mach-omap2/Makefile  |6 ++
 arch/arm/mach-omap2/io.c  |3 +-
 arch/arm/mach-omap2/omap_opp_data.h   |   72 +++
 arch/arm/mach-omap2/opp.c |   93 +
 arch/arm/mach-omap2/opp3xxx_data.c|  107 +
 arch/arm/mach-omap2/opp4xxx_data.c|   57 +++
 arch/arm/mach-omap2/pm.h  |   14 
 arch/arm/plat-omap/include/plat/omap-pm.h |   31 +++--
 arch/arm/plat-omap/omap-pm-noop.c |   11 +---
 11 files changed, 390 insertions(+), 33 deletions(-)
 create mode 100644 arch/arm/mach-omap2/omap_opp_data.h
 create mode 100644 arch/arm/mach-omap2/opp.c
 create mode 100644 arch/arm/mach-omap2/opp3xxx_data.c
 create mode 100644 arch/arm/mach-omap2/opp4xxx_data.c

Bloat-o-meter report for omap2plus_defconfig Vs 2.6.37-rc3:
add/remove: 22/3 grow/shrink: 4/3 up/down: 3149/-64 (3085)
function old new   delta
opp_add- 568+568
opp_set_availability   - 520+520
omap_init_opp_table- 328+328
omap34xx_opp_def_list  - 208+208
static.__func__13783   13954+171
opp_find_freq_floor- 164+164
omap36xx_opp_def_list  - 160+160
opp_find_freq_ceil - 144+144
opp_find_freq_exact- 128+128
find_device_opp- 124+124
opp_get_opp_count  - 120+120
omap44xx_opp_def_list  -  96 +96
opp_get_voltage-  76 +76
opp_get_freq   -  76 +76
omap3_opp_init -  76 +76
dev_opp_list_lock  -  72 +72
omap4_opp_init -  48 +48
vermagic  45  60 +15
linux_banner 133 148 +15
opp_enable -   8  +8
opp_disable-   8  +8
dev_opp_list   -   8  +8
kernel_config_data 13899   13906  +7
__initcall_omap4_opp_init6 -   4  +4
__initcall_omap3_opp_init6 -   4  +4
omap_table_init-   1  +1
omap_pm_cpu_set_freq  28  24  -4
mpu_opps   4   -  -4
l3_opps4   -  -4
dsp_opps   4   -  -4
omap_pm_if_early_init 20   8 -12
omap2_init_common_hw 464 428 -36

 Regards,
 Nishanth Menon
--
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 v5 2/3] omap4: opp: add OPP table data

This patch adds OPP tables for OMAP4. New file has been added to keep
the OMAP4 opp tables and the registration of these tables with the
generic opp framework by OMAP SoC OPP interface.

Based on:
http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=blob;f=arch/arm/mach-omap2/opp44xx_data.c;h=252e3d0cb6050a64f390b9311c1c4977d74f762a;hb=refs/heads/omap4_next

Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
v5:
added ARCH_HAS_OPP after rebase to rc3
V4: http://marc.info/?t=12899337926r=1w=2
switched data to .c file
v3: http://marc.info/?l=linux-omapm=128984926712794w=2
* switched to using device_initcall to autoinitialize the
  opp tables
v2: https://patchwork.kernel.org/patch/266921/

 arch/arm/mach-omap2/Kconfig|2 +
 arch/arm/mach-omap2/Makefile   |1 +
 arch/arm/mach-omap2/opp4xxx_data.c |   57 
 arch/arm/mach-omap2/pm.h   |5 +++
 4 files changed, 65 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/opp4xxx_data.c

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 102a7df..f85188d 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -46,6 +46,8 @@ config ARCH_OMAP4
select ARM_GIC
select PL310_ERRATA_588369
select ARM_ERRATA_720789
+   select ARCH_HAS_OPP
+   select PM_OPP if PM
 
 comment OMAP Core Type
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fbbb6b3..ea217f5 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_ARCH_OMAP2)  += sdrc2xxx.o
 ifeq ($(CONFIG_PM_OPP),y)
 obj-y  += opp.o
 obj-$(CONFIG_ARCH_OMAP3)   += opp3xxx_data.o
+obj-$(CONFIG_ARCH_OMAP4)   += opp4xxx_data.o
 endif
 
 # Power Management
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c 
b/arch/arm/mach-omap2/opp4xxx_data.c
new file mode 100644
index 000..a11fa56
--- /dev/null
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -0,0 +1,57 @@
+/*
+ * OMAP4 OPP table definitions.
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Nishanth Menon
+ * Kevin Hilman
+ * Thara Gopinath
+ * Copyright (C) 2010 Nokia Corporation.
+ *  Eduardo Valentin
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include linux/module.h
+
+#include plat/cpu.h
+
+#include omap_opp_data.h
+
+static struct omap_opp_def __initdata omap44xx_opp_def_list[] = {
+   /* MPU OPP1 - OPP50 */
+   OPP_INITIALIZER(mpu, true, 3, 110),
+   /* MPU OPP2 - OPP100 */
+   OPP_INITIALIZER(mpu, true, 6, 120),
+   /* MPU OPP3 - OPP-Turbo */
+   OPP_INITIALIZER(mpu, false, 8, 126),
+   /* MPU OPP4 - OPP-SB */
+   OPP_INITIALIZER(mpu, false, 100800, 135),
+   /* L3 OPP1 - OPP50 */
+   OPP_INITIALIZER(l3_main_1, true, 1, 93),
+   /* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
+   OPP_INITIALIZER(l3_main_1, true, 2, 110),
+   /* TODO: add IVA, DSP, aess, fdif, gpu */
+};
+
+/**
+ * omap4_opp_init() - initialize omap4 opp table
+ */
+static int __init omap4_opp_init(void)
+{
+   int r = -ENODEV;
+
+   if (!cpu_is_omap44xx())
+   return r;
+
+   r = omap_init_opp_table(omap44xx_opp_def_list,
+   ARRAY_SIZE(omap44xx_opp_def_list));
+
+   return r;
+}
+device_initcall(omap4_opp_init);
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 2031f15..a43e069 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -22,11 +22,16 @@ extern int omap3_idle_init(void);
 
 #if defined(CONFIG_PM_OPP)
 extern int omap3_opp_init(void);
+extern int omap4_opp_init(void);
 #else
 static inline int omap3_opp_init(void)
 {
return -EINVAL;
 }
+static inline int omap4_opp_init(void)
+{
+   return -EINVAL;
+}
 #endif
 
 struct cpuidle_params {
-- 
1.6.3.3

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

[PATCH v5 1/3] omap: opp: add OMAP3 OPP table data and common init

Add OPP data for OMAP34xx and OMAP36xx and initialization functions
to populate OPP tables based on current SoC.
introduce an OMAP generic opp initialization routine which OMAP3
and OMAP4+ SoCs can use to register their OPP definitions.

Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Nishanth Menon n...@ti.com
---
v5: introduced new header for data structures to be used by data files
bit of licensing + whitespace cleanups
introduced ARCH_HAS_OPP after rebasing to rc3

v4: http://marc.info/?t=12899337928r=1w=2
Comments from Thomas addressed:
* Data switched to .c file and included in opp.c
* init_table will fail with -EEXIST if already called
* minor comment improvements
Not addressed:
* request for board files to explicitly call init table
  as discussed http://marc.info/?l=linux-omapm=128992417530385w=2

v3: http://marc.info/?t=12898493916r=1w=2
* added documentation for custom opp modification
  by board files
* switched to using device_initcall to autoinitialize the
  opp tables
v2: https://patchwork.kernel.org/patch/266911/

 Documentation/arm/OMAP/omap_pm  |   25 
 arch/arm/mach-omap2/Kconfig |2 +
 arch/arm/mach-omap2/Makefile|6 ++
 arch/arm/mach-omap2/omap_opp_data.h |   72 +++
 arch/arm/mach-omap2/opp.c   |   93 ++
 arch/arm/mach-omap2/opp3xxx_data.c  |  107 +++
 arch/arm/mach-omap2/pm.h|9 +++
 7 files changed, 314 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/omap_opp_data.h
 create mode 100644 arch/arm/mach-omap2/opp.c
 create mode 100644 arch/arm/mach-omap2/opp3xxx_data.c

diff --git a/Documentation/arm/OMAP/omap_pm b/Documentation/arm/OMAP/omap_pm
index 5389440..9012bb0 100644
--- a/Documentation/arm/OMAP/omap_pm
+++ b/Documentation/arm/OMAP/omap_pm
@@ -127,3 +127,28 @@ implementation needs:
 10. (*pdata-cpu_set_freq)(unsigned long f)
 
 11. (*pdata-cpu_get_freq)(void)
+
+Customizing OPP for platform
+
+Defining CONFIG_PM should enable OPP layer for the silicon
+and the registration of OPP table should take place automatically.
+However, in special cases, the default OPP table may need to be
+tweaked, for e.g.:
+ * enable default OPPs which are disabled by default, but which
+   could be enabled on a platform
+ * Disable an unsupported OPP on the platform
+ * Define and add a custom opp table entry
+in these cases, the board file needs to do additional steps as follows:
+arch/arm/mach-omapx/board-xyz.c
+   #include pm.h
+   
+   static void __init omap_xyz_init_irq(void)
+   {
+   
+   /* Initialize the default table */
+   omapx_opp_init();
+   /* Do customization to the defaults */
+   
+   }
+NOTE: omapx_opp_init will be omap3_opp_init or as required
+based on the omap family.
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index ab784bf..102a7df 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -35,6 +35,8 @@ config ARCH_OMAP3
select CPU_V7
select USB_ARCH_HAS_EHCI
select ARM_L1_CACHE_SHIFT_6 if !ARCH_OMAP4
+   select ARCH_HAS_OPP
+   select PM_OPP if PM
 
 config ARCH_OMAP4
bool TI OMAP4
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 60e51bc..fbbb6b3 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -47,6 +47,12 @@ obj-$(CONFIG_ARCH_OMAP3) += mux34xx.o
 obj-$(CONFIG_ARCH_OMAP2)   += sdrc2xxx.o
 # obj-$(CONFIG_ARCH_OMAP3) += sdrc3xxx.o
 
+# OPP table initialization
+ifeq ($(CONFIG_PM_OPP),y)
+obj-y  += opp.o
+obj-$(CONFIG_ARCH_OMAP3)   += opp3xxx_data.o
+endif
+
 # Power Management
 ifeq ($(CONFIG_PM),y)
 obj-$(CONFIG_ARCH_OMAP2)   += pm24xx.o
diff --git a/arch/arm/mach-omap2/omap_opp_data.h 
b/arch/arm/mach-omap2/omap_opp_data.h
new file mode 100644
index 000..46ac27d
--- /dev/null
+++ b/arch/arm/mach-omap2/omap_opp_data.h
@@ -0,0 +1,72 @@
+/*
+ * OMAP SoC specific OPP Data helpers
+ *
+ * Copyright (C) 2009-2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Nishanth Menon
+ * Kevin Hilman
+ * Copyright (C) 2010 Nokia Corporation.
+ *  Eduardo Valentin
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed 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
+ *

[PATCH v3 3/3] OMAP3: remove OPP interfaces from OMAP PM layer

From: Kevin Hilman khil...@deeprootsystems.com

With new OPP layer, OPP users will access OPP API directly instead of
using OMAP PM layer, so remove all notions of OPPs from the OMAP PM
layer.

Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---

posted for completeness sake - no change involved
v3: no longer explicitly calling the init_table, instead
depending on the device_initcall to initialize as needed

v2: https://patchwork.kernel.org/patch/266931/

 arch/arm/mach-omap2/io.c  |3 +-
 arch/arm/plat-omap/include/plat/omap-pm.h |   31 +---
 arch/arm/plat-omap/omap-pm-noop.c |   11 +-
 3 files changed, 12 insertions(+), 33 deletions(-)

diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 40562dd..2fe4e02 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -327,8 +327,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params 
*sdrc_cs0,
else if (cpu_is_omap44xx())
omap44xx_hwmod_init();
 
-   /* The OPP tables have to be registered before a clk init */
-   omap_pm_if_early_init(mpu_opps, dsp_opps, l3_opps);
+   omap_pm_if_early_init();
 
if (cpu_is_omap2420())
omap2420_clk_init();
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h 
b/arch/arm/plat-omap/include/plat/omap-pm.h
index 728fbb9..62c3fe9 100644
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -17,27 +17,10 @@
 #include linux/device.h
 #include linux/cpufreq.h
 #include linux/clk.h
+#include linux/opp.h
 
 #include powerdomain.h
 
-/**
- * struct omap_opp - clock frequency-to-OPP ID table for DSP, MPU
- * @rate: target clock rate
- * @opp_id: OPP ID
- * @min_vdd: minimum VDD1 voltage (in millivolts) for this OPP
- *
- * Operating performance point data.  Can vary by OMAP chip and board.
- */
-struct omap_opp {
-   unsigned long rate;
-   u8 opp_id;
-   u16 min_vdd;
-};
-
-extern struct omap_opp *mpu_opps;
-extern struct omap_opp *dsp_opps;
-extern struct omap_opp *l3_opps;
-
 /*
  * agent_id values for use with omap_pm_set_min_bus_tput():
  *
@@ -59,9 +42,11 @@ extern struct omap_opp *l3_opps;
  * framework starts.  The _if_ is to avoid name collisions with the
  * PM idle-loop code.
  */
-int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table,
-struct omap_opp *dsp_opp_table,
-struct omap_opp *l3_opp_table);
+#ifdef CONFIG_OMAP_PM_NONE
+#define omap_pm_if_early_init() 0
+#else
+int __init omap_pm_if_early_init(void);
+#endif
 
 /**
  * omap_pm_if_init - OMAP PM init code called after clock fw init
@@ -69,7 +54,11 @@ int __init omap_pm_if_early_init(struct omap_opp 
*mpu_opp_table,
  * The main initialization code.  OPP tables are passed in here.  The
  * _if_ is to avoid name collisions with the PM idle-loop code.
  */
+#ifdef CONFIG_OMAP_PM_NONE
+#define omap_pm_if_init() 0
+#else
 int __init omap_pm_if_init(void);
+#endif
 
 /**
  * omap_pm_if_exit - OMAP PM exit code
diff --git a/arch/arm/plat-omap/omap-pm-noop.c 
b/arch/arm/plat-omap/omap-pm-noop.c
index e129ce8..ca75abb 100644
--- a/arch/arm/plat-omap/omap-pm-noop.c
+++ b/arch/arm/plat-omap/omap-pm-noop.c
@@ -26,10 +26,6 @@
 
 #include plat/powerdomain.h
 
-struct omap_opp *dsp_opps;
-struct omap_opp *mpu_opps;
-struct omap_opp *l3_opps;
-
 /*
  * Device-driver-originated constraints (via board-*.c files)
  */
@@ -308,13 +304,8 @@ int omap_pm_get_dev_context_loss_count(struct device *dev)
 
 
 /* Should be called before clk framework init */
-int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table,
-struct omap_opp *dsp_opp_table,
-struct omap_opp *l3_opp_table)
+int __init omap_pm_if_early_init(void)
 {
-   mpu_opps = mpu_opp_table;
-   dsp_opps = dsp_opp_table;
-   l3_opps = l3_opp_table;
return 0;
 }
 
-- 
1.6.3.3

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

Re: [PATCH 00/13] OMAP3: OFF mode fixes

2010-11-24 Thread Jean Pihet

Nishant,

On Wed, Nov 24, 2010 at 10:22 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
 (Sorry. You will see two replies from me on your email)
 -Original Message-
 From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com]
 Sent: Wednesday, November 24, 2010 11:04 AM
 To: 'Kevin Hilman'
 Cc: Nishanth Menon; 'linux-omap'; 'Jean Pihet'; Vishwanath Sripathy;
 'Tony'
 Subject: RE: [PATCH 00/13] OMAP3: OFF mode fixes

  -Original Message-
  From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
  ow...@vger.kernel.org] On Behalf Of Kevin Hilman
  Sent: Wednesday, November 24, 2010 2:06 AM
  To: Santosh Shilimkar
  Cc: Nishanth Menon; linux-omap; Jean Pihet; Vishwanath Sripathy; Tony
  Subject: Re: [PATCH 00/13] OMAP3: OFF mode fixes

 [...]
   And we should treat ROM code as a hardware. Secure services
   don't give  you garrulity of saving per each secure module. To
   get CPU OFF working on secure device, secure RAM must be saved.
   So I still think it is CPU specific code and pretty much relevant
   to CPU IDLE OFF state considering ROM code.
   Ofcourse this not related to GP device because we never enter Secure
   world again after the boot-up.
   So moving this code to a separate file is fine but it still related
   to CPU.

  Sure, it's still *related* to the CPU, but what I am arguing is that
 it
  should not be related to CPU *idle*.

  My undersanding is this (please correct me):

  Secure RAM context only needs to be saved/updated when something in it
  changes changes (e.g. secure driver usage.)  Therefore, any
  driver/device usage that has a side effect of changing secure RAM
 should
  be responsible for updating secure RAM.

 This assumption holds true largely but not completely. There are more
 Secure APIs which are outside of any secure driver usage which can also
 alter the state of secure RAM. OMAP4, we have more APIs apart from
 secure
 RAM where the secure HW registers, firewalls, cache controllers,
 interrupt
 controllers are managed using secure APIs. All of this is must for
 correct
 CPU OFF functioning.

  The approach taken in $SUBJECT series is basically: since we don't
 know
  who is using/changing secure RAM, we better save it (or have the
 option
  to) during every off-mode transition.  This approach is what I do not
  like.  It's pushing work (and intellegence) that should be in the
  drivers into the PM core where it does not belong.

 The problem is because the secure RAM is not portioned per device basis
 but managed as a whole. If we had per secure device portioning then the
 respective device drivers saving it's context would have worked
 perfectly.
 And the fact is it's not the secure device driver context, but it's a
 Secure software context which runs in parallel with HLOS on HS devices.

  Rather, I want to follow the same approach we follow for every other
  device driver.  Drivers must assume they can lose context.  Therefore
  it's up to them to save it.

  IOW, the drivers that *change* secure RAM should be responsible for
  ensuring that any of the changes they make are saved.

 As I mentioned above its not just the driver context but the whole
 secure software context. I will check with ROM team if it can be made
 more granular for future OMAPs so that we can have the usual strategy
 of respective components taking care of there save/restore. This will
 also save huge latency we incure while saving whole RAM on every MPU
 OFF transition.

 I had a discussion with ROM team and they conformed that the secure
 context can get changed with protected applications (PA for FW, secure
 keys) as well as with secure drivers like crypto, aes etc.

 This can be centralized and some APIs can be provided by the secure
 middleware to know whether the context needs to be save or not.
 Secure middleware manages all the secure driver interfaces as well
 as PA's. This is the centralized place where all state knowledge is
 available. This component also can take care of doing a secure context
 save job based on needs. The only concern from them was that
 which security middleware to be used is not fixed and its
 upto customers to decide. Few of them develop this on there own.

 So with clarity now, I concur with your idea of moving out the secure
 context save from CPUIDLE code.
 The only problem I see is how do we support multiple security
 middleware's with a common infrastructure.

When the code is split into the pure sleep code and the secure code
parts, I would like to have the sleep code part cleaned up.
BTW I rebased my clean-up patch on top of the 13 patches you sent and
performed some testing. It is working OK AFAICT (also stands for As
far as I can test TM).

Can this happen before the .38 merge window?

 Regards
 Santosh

Thanks,
Jean
--
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 00/13] OMAP3: OFF mode fixes


Jean Pihet had written, on 11/24/2010 11:11 AM, the following:
[...]

When the code is split into the pure sleep code and the secure code
parts, I would like to have the sleep code part cleaned up.
BTW I rebased my clean-up patch on top of the 13 patches you sent and
performed some testing. It is working OK AFAICT (also stands for As
far as I can test TM).
I could help with testing on EMU zoom3 and SDP3430 If you could host a 
tree somewhere. Maybe some folks could pitch in for testing with N900 
which has HS device as well.




Can this happen before the .38 merge window?
I plan to work on this set over the next week - hopefully we can do the 
testing and posting by then. will probably post offline my initial 
versions for sync up.


--
Regards,
Nishanth Menon
--
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 02/13] OMAP3: PM: Errata i581 suppport: dll kick strategy


Sripathy, Vishwanath had written, on 11/24/2010 10:51 AM, the following:

On Fri, Nov 19, 2010 at 7:24 AM, Nishanth Menon n...@ti.com wrote:

From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com

Errata i581 impacts OMAP3 platforms.
PRCM DPLL control FSM removes SDRC_IDLEREQ before DPLL3 locks causing
the DPLL not to be locked at times.

IMPORTANT: this is not a complete workaround implementation as recommended
by the silicon errata. this is a support logic for detecting lockups and
attempting to recover where possible and is known to provide stability
in multiple platforms.


How does this WA work when Core enters off mode? SRAM contents are
lost when Core enters off. So how this code is copied to SRAM upon
wakeup? Where is this code placed when Core entered off mode?


It depends on the location of wait_sdram_ok - ideally speaking yep, you 
are right the current wait_sdram_ok for OFF makes no sense at all as it 
wakes off the ddr. For retention though, it makes sense. after the 
discussion we had on Jean's series 
http://marc.info/?t=12853255524r=1w=2, I am pretty sure that 
refactor that Jean is doing will help us clean this mess up.


Maybe we can refactor this as part of Jean's cleanups.



Vishwa

Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
---
 arch/arm/mach-omap2/sleep34xx.S |   52 +++---
 1 files changed, 47 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 8f207b2..5a4468f 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -42,6 +42,7 @@
   OMAP3430_PM_PREPWSTST)
 #define PM_PWSTCTRL_MPU_P  OMAP3430_PRM_BASE + MPU_MOD + OMAP2_PM_PWSTCTRL
 #define CM_IDLEST1_CORE_V  OMAP34XX_CM_REGADDR(CORE_MOD, CM_IDLEST1)
+#define CM_IDLEST_CKGEN_V  OMAP34XX_CM_REGADDR(PLL_MOD, CM_IDLEST)
 #define SRAM_BASE_P0x4020
 #define CONTROL_STAT   0x480022F0
 #define SCRATCHPAD_MEM_OFFS0x310 /* Move this as correct place is
@@ -554,31 +555,67 @@ skip_l2_inval:

 /* Make sure SDRC accesses are ok */
 wait_sdrc_ok:
+
+/* DPLL3 must be locked before accessing the SDRC. Maybe the HW ensures this. 
*/
+   ldr r4, cm_idlest_ckgen
+wait_dpll3_lock:
+   ldr r5, [r4]
+   tst r5, #1
+   beq wait_dpll3_lock
+
ldr r4, cm_idlest1_core
+wait_sdrc_ready:
ldr r5, [r4]
-and r5, r5, #0x2
-cmp r5, #0
-bne wait_sdrc_ok
+tst r5, #0x2
+bne wait_sdrc_ready
+   /* allow DLL powerdown upon hw idle req */
ldr r4, sdrc_power
ldr r5, [r4]
bic r5, r5, #0x40
str r5, [r4]
-wait_dll_lock:
+is_dll_in_lock_mode:
+
/* Is dll in lock mode? */
ldr r4, sdrc_dlla_ctrl
ldr r5, [r4]
tst r5, #0x4
bxnelr
/* wait till dll locks */
-ldr r4, sdrc_dlla_status
+wait_dll_lock_timed:
+   ldr r4, wait_dll_lock_counter
+   add r4, r4, #1
+   str r4, wait_dll_lock_counter
+   ldr r4, sdrc_dlla_status
+movr6, #8  /* Wait 20uS for lock */
+wait_dll_lock:
+   subsr6, r6, #0x1
+   beq kick_dll
ldr r5, [r4]
and r5, r5, #0x4
cmp r5, #0x4
bne wait_dll_lock
bx  lr

+   /* disable/reenable DLL if not locked */
+kick_dll:
+   ldr r4, sdrc_dlla_ctrl
+   ldr r5, [r4]
+   mov r6, r5
+   bic r6, #(13) /* disable dll */
+   str r6, [r4]
+   dsb
+   orr r6, r6, #(13) /* enable dll */
+   str r6, [r4]
+   dsb
+   ldr r4, kick_counter
+   add r4, r4, #1
+   str r4, kick_counter
+   b   wait_dll_lock_timed
+
 cm_idlest1_core:
   .word   CM_IDLEST1_CORE_V
+cm_idlest_ckgen:
+   .word   CM_IDLEST_CKGEN_V
 sdrc_dlla_status:
   .word   SDRC_DLLA_STATUS_V
 sdrc_dlla_ctrl:
@@ -615,5 +652,10 @@ control_stat:
   .word   CONTROL_STAT
 kernel_flush:
   .word v7_flush_dcache_all
+   /* these 2 words need to be at the end !!! */
+kick_counter:
+   .word   0
+wait_dll_lock_counter:
+   .word   0
 ENTRY(omap34xx_cpu_suspend_sz)
   .word   . - omap34xx_cpu_suspend
--
1.6.3.3





--
Regards,
Nishanth Menon
--
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 ver. 2] PM: add synchronous runtime interface for interrupt handlers

Alan Stern st...@rowland.harvard.edu writes:

 On Tue, 23 Nov 2010, Kevin Hilman wrote:

 While I like the idea of the symmetry of having both _get_sync() and
 _put_sync() callable from an interrupt handler, I can't currently think
 of a situation where we would need to _put_sync() in the ISR.  A
 standard _put() should suffice for all cases I can imagine.

 It's wasteful to go through the context switch to the workqueue process
 if you don't need to.  And it's time consuming; you want to power down 
 the device as soon as possible once the interrupt handler is finished, 
 right?

 What do you think of the pm_runtime_put_sync_suspend() proposal?

That should be fine.

Thinking of this some more, I don't have any use cases currently where
we would any sort of put in the ISR, since the ISR is usually an
indicator that something else will be accessing the device shortly after
the ISR is finished.

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

[PATCH] OMAP: UART: don't resume UARTs that are not enabled.

Add additional check to omap_uart_resume_idle() so that only
enabled (specfically, idle-enabled) UARTs are allowed to resume.
This matches the existing check in prepare idle.

Cc: Govindraj R. govindraj.r...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
Unless there are any objections, this will be queued in pm-next for 2.6.38.

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

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index becf0e3..bc934db 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -406,7 +406,7 @@ void omap_uart_resume_idle(int num)
struct omap_uart_state *uart;
 
list_for_each_entry(uart, uart_list, node) {
-   if (num == uart-num) {
+   if (num == uart-num  uart-can_sleep) {
omap_uart_enable_clocks(uart);
 
/* Check for IO pad wakeup */
-- 
1.7.2.1

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

Re: DSP Bridge video decode of above VGA videos

2010-11-24 Thread Uribe de Leon, Armando

Hi James,

It seems that this question is more intended to the TI SN team, anyway
I have taken a look at the mail chain and from your conclusions below
seems that you are facing memory allocation issues. I think it is
probably you are getting a SYS_EALLOC coming in from the call to
UTILS_allocatePrivateBuffer()  where the buffer is being allocated.

Some nodes may need to allocate very large buffers, possibly larger
than any heap size configured in the base image. In order to support
these nodes, external memory requirements can be configured for up to
16 profiles of a node. This will allow the ARM OS to allocate a
private heap for a node.You can check your SN .tcf file to look at the
configured profiles, for example if you are using the h264 TI SN the
file is h264vdec_sn.tcf. You will see the 16 profiles listed there.
And you must use the profile that fits your needs.

TI H264 has two decoding modes: FRAME and STREAMING. I recall that for
FRAME mode the max resolution allowed is VGA: profile 3; although for
STREAMING there are 7 profiles, but I am not familiar with those
profiles and how STREAMING mode works.

I am looping SN folks, they might help more accurately, also I am
thinking that we can remove the  linux-omap@vger.kernel.org list in
the subsequent mails.

Rijo, Guruprasad,

Do you know if it is possible decode H264 videos with resolution above 640x480?

I am copying the original James query:

We are running Android on a custom Gumstix Overo Water platform. We
have ported the 25.12 Zoom2 release to do this.

It is almost working except that when trying to decode H264 videos
with resolution above 640x480 (either horizontally or vertically, e.g.
640*544) the DSP module appears to crash. Decoding anything at VGA or
below is working fine.

DSP bridge is configured with 0x60 memory (but larger doesn't seem
to help).  Is anyone aware of other configuration options that we
should be checking (e.g. in DSP bridge, OMAP video drivers, or
android?) that might cause large video decodes to fail?


Thanks and regards,
Armando.



On Wed, Nov 24, 2010 at 10:01 AM, James Adams james.r.ad...@gmail.com wrote:
 Many thanks for the help Rene, it makes a huge difference being told
 whereabouts in the gigabytes of source to start looking!

 You are quite correct in that the error comes from NODE_Create.
 Node_Create calls DISP_NodeCreate
 DISP_NodeCreate calls SendMessage
 SendMessage succeeds, but after CHNL_IsIOComplete reads back a status
 code from chnlIOC.pBuf which has the error code in it.

 My understanding is that this means that the dsp bridge kernel has sent
 a message across to the TI DSP, but the DSP is reporting out of memory.

 Unfortunately, I don't know where to go from here, any tips?

 I've looked at the DSP bridge documents but I still don't really have a
 handle on the memory allocation.
 My understanding is that:
 1) The DSP and ARM share access to the same memory chips
 2) The DSP bridge allocates shm_size memory for page tables and
 communications
 3) The DSP bridge assigns phys_mempool_size memory at a fixed address
 for the DSP to store its own data inside
 I don't understand where the streaming data gets allocated.

 I've tried increasing phys_mempool_size but it behaves the same.

 I've added printk to the allocation routines in mem.c, but none of these
 are failing.  (Although I suspect they are irrelevant and it is some
 memory manager running on the DSP that is failing)

 Testing some other sizes I find that 800x480, 854x480, 864x480,
 800x512 and 854x480 play, but
 960x480, 800x528, 800x544, 880x480 do not.

 Is it possible that the TI binaries will always return EMEMORY if too
 high a resolution is requested?

 Any advice much appreciated!




 On Wed, Nov 24, 2010 at 12:38 AM, Sapiens, Rene rene.sapi...@ti.com wrote:
 Hi James,

 The second error log is the stack trace when the watchdog timer calls
 SYNC_EnterCS.

 Actually is not the WDT calling the function to get into the critical
 section, it is the WDT being disabled when the DSP is going to OFF
 state. This should fine.

 The stack trace is shown below.


 1) Is this trace printed after the 'if (in_interrupt())' statement?
 2) Can you check under drivers/dsp/bridge/ to see where is or under
 which context io_dispatchpm called?

 To get the assertions failing you should be in the context of an
 interrupt, the code base that i have is not that way for that reason i
 ask for your io_dispatchpm function.

 [c0412864] (dump_stack+0x0/0x14) from [c0278c18]
 (SYNC_EnterCS+0x48/0xe4)
 [c0278bd0] (SYNC_EnterCS+0x0/0xe4) from [c0279e24]
 (REG_GetValue+0x60/0xa0)
  r5:c05ba390 r4:c04f092c
 [c0279dc4] (REG_GetValue+0x0/0xa0) from [c027987c]
 (CFG_GetObject+0x60/0xe0)
  r7:cfa87a80 r6:0002 r5:cf98fe94 r4:0002
 [c027981c] (CFG_GetObject+0x0/0xe0) from [c02913c0]
 (DRV_GetFirstDevObject+0
 x1c/0x4c)
  r5:c05ba3c0 r4:
 [c02913a4] (DRV_GetFirstDevObject+0x0/0x4c) from [c02858e4]
 (DEV_GetFirst+0x
 10/0x44)
 [c02858d4]

Re: [PATCH v2 1/4] drivers: hwspinlock: add generic framework

2010-11-24 Thread Ohad Ben-Cohen

Hi Mugdha,

On Wed, Nov 24, 2010 at 9:44 AM, Kamoolkar, Mugdha mug...@ti.com wrote:
 How do multiple clients get a handle that they can use? Are they expected to
 share the handle they get from the call above?

Currently, yes.

 What if they are independent
 clients with no means of communication between them? There may be a need of
 an API that returns the handle for a specific ID. For example, a module over
 the hwspinlock driver that does some level of management of IDs (e.g. name
 to ID mapping) and enables users to get multi-core as well as multi-client
 protection on Linux.

I'm not sure I understand the use case. Can you please elaborate ?

 For example:
 struct hwspinlock *hwspinlock_get_handle(unsigned int id);

I'm afraid such an API will be easily abused, e.g., drivers that will
try to use a predefined hwspinlock id without taking care of reserving
it early enough will probably use it to overcome an oops this
hwspinlock has already been assigned to someone else.

So let me suggest we should first understand the use case for the API
you propose, and then see how we solve it ?

 Why are some of the APIs hwspinlock_ and others hwspin_?

I'm following the regular spinlock naming, which nicely avoids having
the word 'lock' twice in the API. So you get APIs like hwspin_lock,
hwspin_unlock, hwspin_trylock. In our case we still have stuff like
hwspinlock_request and hwspinlock_free. I can probably make it
hwspin_lock_request, does that look nicer ?

 +  int hwspin_lock_timeout(struct hwspinlock *hwlock, unsigned long timeout);
 +   - lock a previously-assigned hwspinlock with a timeout limit (specified 
 in
 +     jiffies). If the hwspinlock is already taken, the function will busy
 loop
 +     waiting for it to be released, but give up when the timeout meets
 jiffies.
 +     If timeout is 0, the function will never give up (therefore if a faulty
 +     remote core never releases the hwspinlock, it will deadlock).
 If timeout is 0, shouldn't it rather behave as a trylock? If timeout is
 MAX_SCHEDULE_TIMEOUT, then it should behave as a wait-forever.

Good point, thanks!

 +  int hwspin_trylock(struct hwspinlock *hwlock);
 +   - attempt to lock a previously-assigned hwspinlock, but immediately fail
 if
 +     it is already taken.
 +     Upon a successful return from this function, preemption is disabled so
 +     caller must not sleep, and is advised to release the hwspinlock as soon
 as
 +     possible, in order to minimize remote cores polling on the hardware
 +     interconnect.
 +     Returns 0 on success and an appropriate error code otherwise (most
 +     notably -EBUSY if the hwspinlock was already taken).
 +     The function will never sleep.
 Is this function needed at all if timeout 0 behaves similar to trylock?

Yeah. Drivers should use the _trylock version when applicable because
it'd make the code more readable, and it's more intuitive (just like
the spin_trylock API).

 +  struct hwspinlock *hwspinlock_unregister(unsigned int id);
 +   - to be called from the underlying vendor-specific implementation, in
 order
 +     to unregister an existing (and unused) hwspinlock instance.
 +     Can be called from an atomic context (will not sleep) but not from
 +     within interrupt context.
 +     Returns the address of hwspinlock on success, or NULL on error (e.g.
 +     if the hwspinlock is sill in use).
 Does this need to be called for all hwspinlocks?

Currently, yes.

I actually am planning an improvement that would allow registering a
block of hwspinlocks; I don't think that the multiple calls of
register/unregister is that bad (it happens only once at boot), but I
want to allow sharing of the owner, ops and dev members of the
hwspinlock instances (to save some memory).

Anyway, it's not a big improvement, so I planned first to get things
merged and then look into stuff like that.

 +int __hwspin_lock_timeout(struct hwspinlock *hwlock, unsigned long to,
 +                                     int mode, unsigned long *flags)
 +{
 +     int ret;
 +
 +     for (;;) {
 +             /* Try to take the hwspinlock */
 +             ret = __hwspin_trylock(hwlock, mode, flags);
 +             if (ret != -EBUSY)
 +                     break;
 +
 +             /*
 +              * The lock is already taken, let's check if the user wants
 +              * us to try again
 +              */
 +             if (to  time_is_before_eq_jiffies(to))
 +                     return -ETIMEDOUT;
 +
 +             /*
 +              * Allow platform-specific relax handlers to prevent
 +              * hogging the interconnect (no sleeping, though)
 +              */
 +             if (hwlock-ops-relax)
 +                     hwlock-ops-relax(hwlock);
 There should be a way to have an escape mechanism for the case where a 
 deadlock
 has occurred due to remote side taking the spinlock and crashing.

This is exactly what the timeout parameter is for..

Thanks,
Ohad.
--
To unsubscribe from this list: send the line

Re: [PATCH ver. 2] PM: add synchronous runtime interface for interrupt handlers

2010-11-24 Thread Rafael J. Wysocki

On Wednesday, November 24, 2010, Alan Stern wrote:
 On Tue, 23 Nov 2010, Rafael J. Wysocki wrote:
 
   Or maybe you think that when pm_runtime_put_sync detects the 
   usage_count has decremented to 0 and the device is irq-safe, it should 
   call rpm_suspend directly instead of calling rpm_idle?
  
  That also would work for me, actually.
 
 Okay, then consider this proposal.  I'll introduce a new
 pm_runtime_put_sync_suspend() function which decrements the usage_count
 and calls rpm_suspend directly if the count drops to 0.  Then interrupt
 handlers could use this function in place of pm_runtime_put_sync(),
 provided the device was irq-safe.
 
 Not only that, pm_runtime_put_sync_suspend() would be available for
 anyone to use.  It must be reasonably common for runtime_idle routines
 to do nothing but call pm_runtime_suspend().  The new API call would
 save a little overhead.

Fine by me.

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

Re: [PATCH] OMAP: UART: don't resume UARTs that are not enabled.

2010-11-24 Thread Felipe Balbi

Hi,

On Wed, 2010-11-24 at 11:09 -0800, Kevin Hilman wrote:
 Add additional check to omap_uart_resume_idle() so that only
 enabled (specfically, idle-enabled) UARTs are allowed to resume.

typo: specifically

-- 
balbi

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

Re: [PATCH v7 00/11] OMAP: GPIO: Implement GPIO as a platform device


Hi Charu,

On 11/23/2010 3:56 PM, Varadarajan, Charulatha wrote:

Implement OMAP GPIO module in platform device model. OMAP2+ specific GPIO
module uses hwmod FW.

Tested on OMAP2430, OMAP44430, OMAP3430 SDP boards, OMAP4430 Blaze board


How did you get some top secret samples of the ultra new *44430* device 
running at 16.5 GHz?

That device should not be released publicly before 10 years ;-)

Benoit


and zoom3 board. Verified that this patch series does not break the OMAP1
build.

Version History:
---
v7 Series:
- Use gpio iclks as main_clk in OMAP3  OMAP4
- Implement GPIO as a platform device (use hwmod FW for OMAP2+)
  and the implementation is similar to current GPIO code. Does not
  modify the gpio suspend/ resume/ prepare for odle and resume after
  idle code and these modifications would be done in a separate patch
  series. This was suggested by Kevin in another internal email thread.

v6 Series:
Some links for v6 series:
https://patchwork.kernel.org/patch/189742/
https://patchwork.kernel.org/patch/189822/
https://patchwork.kernel.org/patch/189832/
Comments Fixed in v6:
-use PM runtime APIs for gpio in cpu idle/resume after
  idle path when interrupts are enabled.
-Do not use omap_device_* calls in the gpio driver
-Use clock alias names for debounce clocks while using clock
  framework APIs to do clk_get.
-do a kfree of pdata after doing omap_device_build()
-use PM runtime APIs during probe before and after accessing
  gpio registers
-Remove sysconfig register access from GPIO driver
-Use ARRAY_SIZE instead on size_of in OMAP1 gpio_init

v5 Series:
Some links for v5 series:
https://patchwork.kernel.org/patch/117790/
https://patchwork.kernel.org/patch/117789/
https://patchwork.kernel.org/patch/117788/
https://patchwork.kernel.org/patch/117785/
https://patchwork.kernel.org/patch/117796/
Comments Fixed in v5:
- Use dev_pm_ops instead of sys_dev_class
- Use runtime suspend/resume hooks for GPIO device
- extend the usage of mod_usage flag to all cpu classes.(Earlier it was
used only for OMAP2+)
- Make gpio_context as part of gpio_bank structure

v4 Series:
Some links for v4 series:
https://patchwork.kernel.org/patch/107411/
Comments Fixed in v4:
- Remove gpio_bank_count from dev_attr field and derive it from
hwmod class iteration count
- Add TODOs for future omap gpio code cleanup related activity
- Rename gpio's platform_data 'method' to 'bank_type'
- Rename gpio's platform_data 'gpio_bank_bits' to 'gpio_bank_width'
- Add 'rev' field to gpio class in hwmod datbase and get 'bank_type'
based on 'rev' field
- Filename removed from file description when a new file is created

v3 Series:
Some of the v3 links:
https://patchwork.kernel.org/patch/106224/
Comments Fixed in v3:
- .module_offs populated in hwmod structures
- If not defined CONFIG_PM_RUNTIME is not handled in GPIO driver
- No changes to mach-omap2/clock-data.c to handle clocks by dev ptr
 as it is taken care using clock get by name in hwmod  omap_device layer
- Using ick instead of arm_gpio_ck for OMAP15xx clock
- SoC base addresses moved to plat-omap/omap.h that should be
 used only by the omap_hwmod__data.c file
- OMAP2/3 hwmod structures naming convention changed as it is
 followed in OMAP4
- omap24xx_gpio_init() uses cpu_is_omap24xx() instead of separate
 checks for 2420  2430 in OMAP2 specific init call (mach-omap layer)
- Reason for using postcore_initcall is added to patch description
- Comments added for usage of dbck_flag and other elements
 in dev_attr structure
- Uses dev_dbg() and dev_err() instead of pr_dbg() and pr_err()
- Corrects the gpio clock details in OMAP4 hwmod database

v2 series:
Some important links to patch v2 series and comments:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30262.html
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28787.html
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30263.html
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30295.html
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30259.html
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28933.html
Comments Fixed in V2:
- GPIO dev attr was added for SoC specific chip info (eg., gpio bank count)
- Removed omap_gpio_init() usage from board files
- platform_get_resource() used instead of pdata-base for
 OMAP2+ base addresses
- postcore_initcall used for gpio init instead of making
 GPIO as an early platform device. SoC specific gpio_init
 needs to be done before machine_init functions access gpio
 APIs. Hence making SoC specific gpio_init as postcore_initcall.
- getting gpio dbck is moved to omap_set_gpio_debounce()
 instead of doing it in probe

v1 series:
Some important links to patch v1 series and comments:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26934.html
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg27860.html

Re: [PATCH v7 05/11] OMAP2420: hwmod data: Add GPIO


On 11/23/2010 3:56 PM, Varadarajan, Charulatha wrote:

Add GPIO hwmod data for OMAP2420

Signed-off-by: Charulatha Vch...@ti.com
---
  arch/arm/mach-omap2/omap_hwmod_2420_data.c |  229 
  arch/arm/plat-omap/include/plat/gpio.h |5 +
  2 files changed, 234 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a1a3dd6..c951061 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -17,6 +17,7 @@
  #includeplat/dma.h
  #includeplat/serial.h
  #includeplat/i2c.h
+#includeplat/gpio.h
  #includeplat/omap24xx.h

Do you still need that header file?



  #include omap_hwmod_common_data.h
@@ -38,6 +39,10 @@ static struct omap_hwmod omap2420_iva_hwmod;
  static struct omap_hwmod omap2420_l3_main_hwmod;
  static struct omap_hwmod omap2420_l4_core_hwmod;
  static struct omap_hwmod omap2420_wd_timer2_hwmod;
+static struct omap_hwmod omap2420_gpio1_hwmod;
+static struct omap_hwmod omap2420_gpio2_hwmod;
+static struct omap_hwmod omap2420_gpio3_hwmod;
+static struct omap_hwmod omap2420_gpio4_hwmod;

  /* L3 -  L4_CORE interface */
  static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
@@ -557,6 +562,224 @@ static struct omap_hwmod omap2420_i2c2_hwmod = {
.flags  = HWMOD_16BIT_REG,
  };

+/* l4_wkup -  gpio1 */
+static struct omap_hwmod_addr_space omap2420_gpio1_addr_space[] = {
+   {
+   .pa_start   = 0x48018000,
+   .pa_end = 0x480181ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__gpio1 = {
+   .master =omap2420_l4_wkup_hwmod,
+   .slave  =omap2420_gpio1_hwmod,
+   .clk= gpios_ick,
+   .addr   = omap2420_gpio1_addr_space,
+   .addr_cnt   = ARRAY_SIZE(omap2420_gpio1_addr_space),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup -  gpio2 */
+static struct omap_hwmod_addr_space omap2420_gpio2_addr_space[] = {
+   {
+   .pa_start   = 0x4801a000,
+   .pa_end = 0x4801a1ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__gpio2 = {
+   .master =omap2420_l4_wkup_hwmod,
+   .slave  =omap2420_gpio2_hwmod,
+   .clk= gpios_ick,
+   .addr   = omap2420_gpio2_addr_space,
+   .addr_cnt   = ARRAY_SIZE(omap2420_gpio2_addr_space),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup -  gpio3 */
+static struct omap_hwmod_addr_space omap2420_gpio3_addr_space[] = {
+   {
+   .pa_start   = 0x4801c000,
+   .pa_end = 0x4801c1ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__gpio3 = {
+   .master =omap2420_l4_wkup_hwmod,
+   .slave  =omap2420_gpio3_hwmod,
+   .clk= gpios_ick,
+   .addr   = omap2420_gpio3_addr_space,
+   .addr_cnt   = ARRAY_SIZE(omap2420_gpio3_addr_space),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup -  gpio4 */
+static struct omap_hwmod_addr_space omap2420_gpio4_addr_space[] = {
+   {
+   .pa_start   = 0x4801e000,
+   .pa_end = 0x4801e1ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__gpio4 = {
+   .master =omap2420_l4_wkup_hwmod,
+   .slave  =omap2420_gpio4_hwmod,
+   .clk= gpios_ick,
+   .addr   = omap2420_gpio4_addr_space,
+   .addr_cnt   = ARRAY_SIZE(omap2420_gpio4_addr_space),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* gpio dev_attr */
+static struct omap_gpio_dev_attr gpio_dev_attr = {
+   .bank_width = 32,
+   .dbck_flag = false,
+};
+
+static struct omap_hwmod_class_sysconfig omap242x_gpio_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .syss_offs  = 0x0014,
+   .sysc_flags = (SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+  SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+   .sysc_fields=omap_hwmod_sysc_type1,
+};
+
+/*
+ * 'gpio' class
+ * general purpose io module
+ */
+static struct omap_hwmod_class omap242x_gpio_hwmod_class = {
+   .name = gpio,
+   .sysc =omap242x_gpio_sysc,
+   .rev = 0,
+};
+
+/* gpio1 */
+static struct omap_hwmod_irq_info omap242x_gpio1_irqs[] = {
+   { .name = gpio_mpu_irq, .irq = 29 }, /* INT_24XX_GPIO_BANK1 */
+};
+
+static struct omap_hwmod_ocp_if *omap2420_gpio1_slaves[] = {
+   omap2420_l4_wkup__gpio1,
+};
+
+static struct omap_hwmod omap2420_gpio1_hwmod = {
+   .name

[PATCH v5 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition

2010-11-24 Thread Gregory CLEMENT

As request by Grant Likely, there is no more cover letter. Full changelog is 
following.
I am still reluctant to add this changelog in the patch description, as it adds 
no value to
the patch itself: when it was needed I try to updat comments or patch 
description.
I understand that Grant Likely would need an ack from other user as this patch 
fix a corner case.
Kevin Hilman made a few comments on this patch so he could add his Ack by or 
at least his Review by.


Changelog:
* Change from v1 to v2:
Rebase on linus/master (after 2.6.37-rc1)
Do some clean-up and fix indentation on both patches
Add more explanations for patch 2

* Change from v2 to v3:
Use directly resume function of spi_master instead of using function
from spi_device as Grant Likely pointed it out.
Force this transition explicitly for each CS used by a device.

* Change from v3 to v4:
Patch clean-up according to Kevin Hilman and checkpatch.
Now force CS to be in inactive state only if it was inactive when it was
suspended.

* Change from v4 to v5:
Rebase on linus/master (after 2.6.37-rc3)
Collapse some lines as pointed by Grant Likely
Fix a spelling


== CUT HERE ==
When SPI wake up from OFF mode, CS is in the wrong state: force it to the 
inactive state.

During the system life, I monitored the CS behavior using a oscilloscope.
I also activated debug in omap2_mcspi, so I saw when driver disable the clocks 
and restore context when device is not used.
Each time the CS was in the correct state.
It was only when system was put suspend to ram with off-mode activated that on 
resume the CS was in wrong state( ie activated).

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 drivers/spi/omap2_mcspi.c |   33 +
 1 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..dcc024a 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -1305,11 +1305,44 @@ static int __exit omap2_mcspi_remove(struct 
platform_device *pdev)
 /* work with hotplug and coldplug */
 MODULE_ALIAS(platform:omap2_mcspi);

+#ifdef CONFIG_PM
+/* When SPI wake up from off-mode, CS is in activate state. If it was in
+ * unactive state when driver was suspend, then force it to unactive state at
+ * wake up.
+ */
+static int omap2_mcspi_resume(struct platform_device *pdev)
+{
+   struct spi_master   *master = dev_get_drvdata(pdev-dev);
+   struct omap2_mcspi  *mcspi = spi_master_get_devdata(master);
+   struct omap2_mcspi_cs *cs;
+
+   omap2_mcspi_enable_clocks(mcspi);
+   list_for_each_entry(cs, omap2_mcspi_ctx[master-bus_num - 1].cs,
+   node) {
+   if ((cs-chconf0  OMAP2_MCSPI_CHCONF_FORCE) == 0) {
+
+   /* We need to toggle CS state for OMAP take this
+* change in account.
+*/
+   MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 1);
+   __raw_writel(cs-chconf0, cs-base + 
OMAP2_MCSPI_CHCONF0);
+   MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 0);
+   __raw_writel(cs-chconf0, cs-base + 
OMAP2_MCSPI_CHCONF0);
+   }
+   }
+   omap2_mcspi_disable_clocks(mcspi);
+   return 0;
+}
+#else
+#defineomap2_mcspi_resume  NULL
+#endif
+
 static struct platform_driver omap2_mcspi_driver = {
.driver = {
.name = omap2_mcspi,
.owner =THIS_MODULE,
},
+   .resume =   omap2_mcspi_resume,
.remove =   __exit_p(omap2_mcspi_remove),
 };
 -- 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

How to (get a struct device* to) map a DMA buffer for McBSP?

2010-11-24 Thread Michael Poole

I am trying to write a device driver to stream data via a McBSP
module.  Most of it is a pretty thin layer, thanks to all the
framework in plat-omap/mcbsp.c and .../mcbsp.h.  However, I am getting
stuck on the read() and write() implementation -- in particular,
retrieving the device pointer for the DMA mapping functions.

To pick dma_map_single(dev, ptr, size, dir) as an example, the ARM
implementation of dma_map_single() looks like it requires dev != NULL.
 struct omap_mcbsp's dev field would be the natural thing to pass,
but the mcbsp_ptr array is not an exported symbol, and there is no
function declared in mcbsp.h that will expose either the omap_mcbsp
struct or the device struct inside it.

Is there a good way to get the right struct device* for the McBSP
module that this device driver is using?  Would a patch be accepted to
add a function that would return the struct device * given the McBSP
id (and if so, should it use EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL())?

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

Re: [PATCH] OMAP: UART: don't resume UARTs that are not enabled.

* Felipe Balbi m...@felipebalbi.com [101124 12:39]:
 Hi,
 
 On Wed, 2010-11-24 at 11:09 -0800, Kevin Hilman wrote:
  Add additional check to omap_uart_resume_idle() so that only
  enabled (specfically, idle-enabled) UARTs are allowed to resume.
 
 typo: specifically

Also, without this patch, system with PM enabled hangs in
cases where only one serial port is initialized instead of
all of them. So I'll queue it as a fix during the -rc cycle.

Regards,

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

Re: [PATCH v7 06/11] OMAP2430: hwmod data: Add GPIO


On 11/23/2010 3:56 PM, Varadarajan, Charulatha wrote:

Add GPIO hwmod data for OMAP2430

Signed-off-by: Charulatha Vch...@ti.com


Acked-by: Benoit Cousson b-cous...@ti.com


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

diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 7cf0d3a..397471c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -17,6 +17,7 @@
  #includeplat/dma.h
  #includeplat/serial.h
  #includeplat/i2c.h
+#includeplat/gpio.h
  #includeplat/omap24xx.h


Just check if that include is still needed.

Benoit



  #include omap_hwmod_common_data.h
@@ -38,6 +39,11 @@ static struct omap_hwmod omap2430_iva_hwmod;
  static struct omap_hwmod omap2430_l3_main_hwmod;
  static struct omap_hwmod omap2430_l4_core_hwmod;
  static struct omap_hwmod omap2430_wd_timer2_hwmod;
+static struct omap_hwmod omap2430_gpio1_hwmod;
+static struct omap_hwmod omap2430_gpio2_hwmod;
+static struct omap_hwmod omap2430_gpio3_hwmod;
+static struct omap_hwmod omap2430_gpio4_hwmod;
+static struct omap_hwmod omap2430_gpio5_hwmod;

  /* L3 -  L4_CORE interface */
  static struct omap_hwmod_ocp_if omap2430_l3_main__l4_core = {
@@ -569,6 +575,272 @@ static struct omap_hwmod omap2430_i2c2_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
  };

+/* l4_wkup -  gpio1 */
+static struct omap_hwmod_addr_space omap2430_gpio1_addr_space[] = {
+   {
+   .pa_start   = 0x4900C000,
+   .pa_end = 0x4900C1ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__gpio1 = {
+   .master =omap2430_l4_wkup_hwmod,
+   .slave  =omap2430_gpio1_hwmod,
+   .clk= gpios_ick,
+   .addr   = omap2430_gpio1_addr_space,
+   .addr_cnt   = ARRAY_SIZE(omap2430_gpio1_addr_space),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup -  gpio2 */
+static struct omap_hwmod_addr_space omap2430_gpio2_addr_space[] = {
+   {
+   .pa_start   = 0x4900E000,
+   .pa_end = 0x4900E1ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__gpio2 = {
+   .master =omap2430_l4_wkup_hwmod,
+   .slave  =omap2430_gpio2_hwmod,
+   .clk= gpios_ick,
+   .addr   = omap2430_gpio2_addr_space,
+   .addr_cnt   = ARRAY_SIZE(omap2430_gpio2_addr_space),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup -  gpio3 */
+static struct omap_hwmod_addr_space omap2430_gpio3_addr_space[] = {
+   {
+   .pa_start   = 0x4901,
+   .pa_end = 0x490101ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__gpio3 = {
+   .master =omap2430_l4_wkup_hwmod,
+   .slave  =omap2430_gpio3_hwmod,
+   .clk= gpios_ick,
+   .addr   = omap2430_gpio3_addr_space,
+   .addr_cnt   = ARRAY_SIZE(omap2430_gpio3_addr_space),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup -  gpio4 */
+static struct omap_hwmod_addr_space omap2430_gpio4_addr_space[] = {
+   {
+   .pa_start   = 0x49012000,
+   .pa_end = 0x490121ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__gpio4 = {
+   .master =omap2430_l4_wkup_hwmod,
+   .slave  =omap2430_gpio4_hwmod,
+   .clk= gpios_ick,
+   .addr   = omap2430_gpio4_addr_space,
+   .addr_cnt   = ARRAY_SIZE(omap2430_gpio4_addr_space),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_core -  gpio5 */
+static struct omap_hwmod_addr_space omap2430_gpio5_addr_space[] = {
+   {
+   .pa_start   = 0x480B6000,
+   .pa_end = 0x480B61ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_core__gpio5 = {
+   .master =omap2430_l4_core_hwmod,
+   .slave  =omap2430_gpio5_hwmod,
+   .clk= gpio5_ick,
+   .addr   = omap2430_gpio5_addr_space,
+   .addr_cnt   = ARRAY_SIZE(omap2430_gpio5_addr_space),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* gpio dev_attr */
+static struct omap_gpio_dev_attr gpio_dev_attr = {
+   .bank_width = 32,
+   .dbck_flag = false,
+};
+
+static struct omap_hwmod_class_sysconfig omap243x_gpio_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .syss_offs  = 0x0014,
+   .sysc_flags = (SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+

Re: [PATCH v7 07/11] OMAP3: hwmod data: Add GPIO


On 11/23/2010 3:56 PM, Varadarajan, Charulatha wrote:

Add GPIO hwmod data for OMAP3

Signed-off-by: Charulatha Vch...@ti.com
Signed-off-by: Rajendra Nayakrna...@ti.com


Acked-by: Benoit Cousson b-cous...@ti.com


---
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  360 
  1 files changed, 360 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 a8bed84..9ca2206 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -20,6 +20,7 @@
  #includeplat/serial.h
  #includeplat/l4_3xxx.h
  #includeplat/i2c.h
+#includeplat/gpio.h
  #includeplat/omap34xx.h

  #include omap_hwmod_common_data.h
@@ -45,6 +46,12 @@ static struct omap_hwmod omap3xxx_wd_timer2_hwmod;
  static struct omap_hwmod omap3xxx_i2c1_hwmod;
  static struct omap_hwmod omap3xxx_i2c2_hwmod;
  static struct omap_hwmod omap3xxx_i2c3_hwmod;
+static struct omap_hwmod omap3xxx_gpio1_hwmod;
+static struct omap_hwmod omap3xxx_gpio2_hwmod;
+static struct omap_hwmod omap3xxx_gpio3_hwmod;
+static struct omap_hwmod omap3xxx_gpio4_hwmod;
+static struct omap_hwmod omap3xxx_gpio5_hwmod;
+static struct omap_hwmod omap3xxx_gpio6_hwmod;

  /* L3 -  L4_CORE interface */
  static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -739,6 +746,351 @@ static struct omap_hwmod omap3xxx_i2c3_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
  };

+/* l4_wkup -  gpio1 */
+static struct omap_hwmod_addr_space omap3xxx_gpio1_addrs[] = {
+   {
+   .pa_start   = 0x4831,
+   .pa_end = 0x483101ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_wkup__gpio1 = {
+   .master =omap3xxx_l4_wkup_hwmod,
+   .slave  =omap3xxx_gpio1_hwmod,
+   .addr   = omap3xxx_gpio1_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap3xxx_gpio1_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -  gpio2 */
+static struct omap_hwmod_addr_space omap3xxx_gpio2_addrs[] = {
+   {
+   .pa_start   = 0x4905,
+   .pa_end = 0x490501ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio2 = {
+   .master =omap3xxx_l4_per_hwmod,
+   .slave  =omap3xxx_gpio2_hwmod,
+   .addr   = omap3xxx_gpio2_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap3xxx_gpio2_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -  gpio3 */
+static struct omap_hwmod_addr_space omap3xxx_gpio3_addrs[] = {
+   {
+   .pa_start   = 0x49052000,
+   .pa_end = 0x490521ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio3 = {
+   .master =omap3xxx_l4_per_hwmod,
+   .slave  =omap3xxx_gpio3_hwmod,
+   .addr   = omap3xxx_gpio3_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap3xxx_gpio3_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -  gpio4 */
+static struct omap_hwmod_addr_space omap3xxx_gpio4_addrs[] = {
+   {
+   .pa_start   = 0x49054000,
+   .pa_end = 0x490541ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio4 = {
+   .master =omap3xxx_l4_per_hwmod,
+   .slave  =omap3xxx_gpio4_hwmod,
+   .addr   = omap3xxx_gpio4_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap3xxx_gpio4_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -  gpio5 */
+static struct omap_hwmod_addr_space omap3xxx_gpio5_addrs[] = {
+   {
+   .pa_start   = 0x49056000,
+   .pa_end = 0x490561ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio5 = {
+   .master =omap3xxx_l4_per_hwmod,
+   .slave  =omap3xxx_gpio5_hwmod,
+   .addr   = omap3xxx_gpio5_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap3xxx_gpio5_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -  gpio6 */
+static struct omap_hwmod_addr_space omap3xxx_gpio6_addrs[] = {
+   {
+   .pa_start   = 0x49058000,
+   .pa_end = 0x490581ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio6 = {
+   .master =omap3xxx_l4_per_hwmod,
+   .slave  =omap3xxx_gpio6_hwmod,
+   .addr   = omap3xxx_gpio6_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap3xxx_gpio6_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/*
+ * 'gpio' class
+ * general

Re: [PATCH v7 09/11] OMAP2+: GPIO: device registration


On 11/23/2010 3:56 PM, Varadarajan, Charulatha wrote:

Use omap_device_build() API to do platform_device_register of
GPIO devices. For OMAP2+ chips, the device specific data defined
in the centralized hwmod database will be used.

gpio_init needs to be done before machine_init functions access
gpio APIs. Hence gpio_init is made as a postcore_initcall.

Signed-off-by: Charulatha Vch...@ti.com
Reviewed-by: Basak, Parthap-bas...@ti.com


Acked-by: Benoit Cousson b-cous...@ti.com


---
  arch/arm/mach-omap2/gpio.c |  103 
  1 files changed, 103 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/mach-omap2/gpio.c

diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
new file mode 100644
index 000..e5c9b6a
--- /dev/null
+++ b/arch/arm/mach-omap2/gpio.c
@@ -0,0 +1,104 @@
+/*
+ * OMAP2+ specific gpio initialization
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author:
+ * Charulatha Vch...@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.
+ */
+
+#includelinux/gpio.h
+#includelinux/err.h
+#includelinux/slab.h
+#includelinux/interrupt.h
+
+#includeplat/omap_hwmod.h
+#includeplat/omap_device.h
+
+static struct omap_device_pm_latency omap_gpio_latency[] = {
+   [0] = {
+   .deactivate_func = omap_device_idle_hwmods,
+   .activate_func   = omap_device_enable_hwmods,
+   .flags   = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+   },
+};
+
+static int omap2_gpio_dev_init(struct omap_hwmod *oh, void *unused)
+{
+   struct omap_device *od;
+   struct omap_gpio_platform_data *pdata;
+   struct omap_gpio_dev_attr *dev_attr;
+   char *name = omap_gpio;
+   int id;
+
+   /*
+* extract the device id from name field available in the
+* hwmod database and use the same for constructing ids for
+* gpio devices.
+* CAUTION: Make sure the name in the hwmod database does
+* not change. If changed, make corresponding change here
+* or make use of static variable mechanism to handle this.
+*/
+   sscanf(oh-name, gpio%d,id);
+
+   pdata = kzalloc(sizeof(struct omap_gpio_platform_data), GFP_KERNEL);
+   if (!pdata) {
+   pr_err(gpio%d: Memory allocation failed\n, id);
+   return -ENOMEM;
+   }
+
+   dev_attr = (struct omap_gpio_dev_attr *)oh-dev_attr;
+   pdata-bank_width = dev_attr-bank_width;
+   pdata-dbck_flag = dev_attr-dbck_flag;
+   pdata-virtual_irq_start = IH_GPIO_BASE + 32 * (id - 1);
+
+   switch (oh-class-rev) {
+   case 0:
+   case 1:
+   pdata-bank_type = METHOD_GPIO_24XX;
+   break;
+   case 2:
+   pdata-bank_type = METHOD_GPIO_44XX;
+   break;
+   default:
+   WARN(1, Invalid gpio bank_type\n);
+   kfree(pdata);
+   return -EINVAL;
+   }
+
+   od = omap_device_build(name, id - 1, oh, pdata,
+   sizeof(*pdata), omap_gpio_latency,
+   ARRAY_SIZE(omap_gpio_latency),
+   false);
+   kfree(pdata);
+
+   if (IS_ERR(od)) {
+   WARN(1, Cant build omap_device for %s:%s.\n,
+   name, oh-name);
+   return PTR_ERR(od);
+   }
+
+   gpio_bank_count++;
+   return 0;
+}
+
+/*
+ * gpio_init needs to be done before
+ * machine_init functions access gpio APIs.
+ * Hence gpio_init is a postcore_initcall.
+ */
+static int __init omap2_gpio_init(void)
+{
+   return omap_hwmod_for_each_by_class(gpio, omap2_gpio_dev_init,
+   NULL);
+}
+postcore_initcall(omap2_gpio_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 v7 11/11] OMAP: GPIO: Remove omap_gpio_init()

* Varadarajan, Charulatha ch...@ti.com [101123 06:47]:
 Remove the usage of omap_gpio_init() from all omap board files
 since omap_gpio_init() does nothing, after gpio is implemented
 as a platform device.

Great, glad to see these go!

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

Re: [PATCH 2.6.37-rc1] ASoC: OMAP: fix OMAP1 compilation problem

* Jarkko Nikula jhnik...@gmail.com [101122 23:16]:
 On Mon, 22 Nov 2010 17:48:24 -0700 (MST)
 Paul Walmsley p...@pwsan.com wrote:
 
   Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
  
  Thanks for fixing this.  What do you think about the following patch 
  instead?  It should avoid any compiler issues.
  
 Hmm.. looks like Janusz's patch is still in Liam's for-2.6.37
 branch only.
 
  +/*
  + * The following functions are only required on an OMAP1-only build.
  + * mach-omap2/mcbsp.c contains the real functions
  + */
  +#ifndef CONFIG_ARCH_OMAP2PLUS
  +int omap2_mcbsp_set_clks_src(u8 id, u8 fck_src_id)
  +{
 
 Would that create a new problem if we are able to compile some day
 omap1 and omap2 support into same kernel? I agree with you that passing
 these via platform_data sounds the right solution.

This should not be a problem because there's no ifdef else and
in that case the functions would be there.

In general, the way to avoid problems like this is to make all
code under drivers arch independent and pass the platform data
from arch specific code.

In this case the ASoC platform data should be passed from
arch/arm/*omap*/ board-*.c files to make the drivers generic.

We are going to get rid of cpu_is_omap macros in the drivers,
so please consider this when patching the ASoC drivers.

Anyways, Paul's patch should be merged during the -rc cycle
because it is currently blocking Amstrad delta being built:

http://armlinux.simtec.co.uk/kautobuild/

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

Re: [PATCH 0/6] OMAP cleanups

* Aaro Koskinen aaro.koski...@nokia.com [101118 09:50]:
 Some small OMAP cleanups to eliminate noise from compilation/sparse
 checks:

Thanks, will queue these for 2.6.38 merge window.

Regards,

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

Re: OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled

Paul Walmsley p...@pwsan.com writes:

 The console semaphore must be held while the OMAP UART devices are
 disabled, lest a console write cause an ARM abort (and a kernel crash)
 when the underlying console device is inaccessible.  These crashes
 only occur when the console is on one of the OMAP internal serial
 ports.

 While this problem has been latent in the PM idle loop for some time,
 the crash was not triggerable with an unmodified kernel until commit
 6f251e9db1093c187addc309b5f2f7fe3efd2995 (OMAP: UART: omap_device
 conversions, remove implicit 8520 assumptions).  After this patch, a
 console write often occurs after the console UART has been disabled in
 the idle loop, crashing the system.  Several users have encountered
 this bug:

 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38396.html

 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg36602.html

 The same commit also introduced new code that disabled the UARTs
 during init, in omap_serial_init_port().  The kernel will also crash
 in this code when earlyconsole and extra debugging is enabled:

 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg36411.html

 The minimal fix for the -rc series is to hold the console semaphore
 while the OMAP UARTs are disabled.  This is a somewhat overbroad fix,
 since the console may not be located on an OMAP UART, as is the case
 with the GPMC UART on Zoom3.  While it is technically possible to
 determine which devices the console or earlyconsole is actually
 running on, it is not a trivial problem to solve, and the code to do
 so is not really appropriate for the -rc series.

 The right long-term fix is to ensure that no code outside of the OMAP
 serial driver can disable an OMAP UART.  As I understand it, code to
 implement this is under development by TI.

Yes, what is underway is a conversion of the omap-serial driver to use
runtime PM so we can finally rid ourselves of the hackery in
mach-omap2/serial.c.  The PM stuff there is a real mess to understand
and maintain, and rather fragile, obviously.  Once the serial driver
itself is in charge of when to disable the UARTs, this becomes a much
easier problem to manage.

 This patch is a collaboration between Paul Walmsley p...@pwsan.com
 and Tony Lindgren t...@atomide.com.  Thanks to Ming Lei
 tom.leim...@gmail.com and Pramod pramod.gu...@ti.com for their
 feedback on earlier versions of this patch.

 Signed-off-by: Paul Walmsley p...@pwsan.com
 Signed-off-by: Tony Lindgren t...@atomide.com
 Cc: Kevin Hilman khil...@deeprootsystems.com
 Cc: Ming Lei tom.leim...@gmail.com
 Cc: Pramod pramod.gu...@ti.com
 Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
 Cc: Jean Pihet jean.pi...@newoldbits.com
 Cc: Govindraj.R govindraj.r...@ti.com

Acked-by: Kevin Hilman khil...@deeprootsystems.com

Very nice.  I've been exploring various solutions to this problem as
well, but this one is much cleaner.  Also, I hadn't discovered the 'try'
version of the console semaphore, so was running into recursive locking.

Anyways, tested on omap35xx: omap3evm (uart1/core console) and beagle
(uart3/per console) and omap34xx/n900 (uart3/per console) using both
retention-idle and off-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: [PATCH v5 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition

Gregory CLEMENT gregory.clem...@free-electrons.com writes:

 As request by Grant Likely, there is no more cover letter. Full changelog is 
 following.
 I am still reluctant to add this changelog in the patch description, as it 
 adds no value to
 the patch itself: when it was needed I try to updat comments or patch 
 description.

You're right, the changelog should not be in the patch description.
This bit of meta-description and changelog should go after the '---'
just after your signoff.  That way, git tools can still auto-apply the
email, and git ignores stuff after the '---' so it doesn't end up in the
git history.

 I understand that Grant Likely would need an ack from other user as this 
 patch fix a corner case.
 Kevin Hilman made a few comments on this patch so he could add his Ack by 
 or at least his Review by.

I haven't actually tested it, only reviewed it, so you can add a
Reviewed by for me, but I'm not SPI-aware enough to ack this patch or
test it thoroughly.  Also,  I have some more comments below...

Also, in the last patch I suggested you do more of a save/restore of
this value instead of a restore to a hard-coded value.  IOW, save the
value in the suspend method, restore it in resume. I thought you had
agreed to that.  I'm not an SPI expert, so not sure if it makes sense,
but it seems more robust that way and more future proof.


 Changelog:
 * Change from v1 to v2:
 Rebase on linus/master (after 2.6.37-rc1)
 Do some clean-up and fix indentation on both patches
 Add more explanations for patch 2

 * Change from v2 to v3:
 Use directly resume function of spi_master instead of using function
 from spi_device as Grant Likely pointed it out.
 Force this transition explicitly for each CS used by a device.

 * Change from v3 to v4:
 Patch clean-up according to Kevin Hilman and checkpatch.
 Now force CS to be in inactive state only if it was inactive when it was
 suspended.

 * Change from v4 to v5:
 Rebase on linus/master (after 2.6.37-rc3)
 Collapse some lines as pointed by Grant Likely
 Fix a spelling


 == CUT HERE ==
 When SPI wake up from OFF mode, CS is in the wrong state: force it to the 
 inactive state.

 During the system life, I monitored the CS behavior using a oscilloscope.
 I also activated debug in omap2_mcspi, so I saw when driver disable the 
 clocks and restore context when device is not used.
 Each time the CS was in the correct state.
 It was only when system was put suspend to ram with off-mode activated that 
 on resume the CS was in wrong state( ie activated).

 Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
 ---

This is where any changelog and extra info for reviewers should go.

  drivers/spi/omap2_mcspi.c |   33 +
  1 files changed, 33 insertions(+), 0 deletions(-)

 diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
 index 2a651e6..dcc024a 100644
 --- a/drivers/spi/omap2_mcspi.c
 +++ b/drivers/spi/omap2_mcspi.c
 @@ -1305,11 +1305,44 @@ static int __exit omap2_mcspi_remove(struct 
 platform_device *pdev)
  /* work with hotplug and coldplug */
  MODULE_ALIAS(platform:omap2_mcspi);

 +#ifdef   CONFIG_PM
 +/* When SPI wake up from off-mode, CS is in activate state. If it was in
 + * unactive state when driver was suspend, then force it to unactive state at
 + * wake up.
 + */

please fix multi-line comment style.  Search for 'multi-line' in
CodingStyle.

 +static int omap2_mcspi_resume(struct platform_device *pdev)
 +{
 + struct spi_master   *master = dev_get_drvdata(pdev-dev);
 + struct omap2_mcspi  *mcspi = spi_master_get_devdata(master);
 + struct omap2_mcspi_cs *cs;
 +
 + omap2_mcspi_enable_clocks(mcspi);
 + list_for_each_entry(cs, omap2_mcspi_ctx[master-bus_num - 1].cs,
 + node) {
 + if ((cs-chconf0  OMAP2_MCSPI_CHCONF_FORCE) == 0) {
 +
 + /* We need to toggle CS state for OMAP take this
 +  * change in account.
 +  */

multi-line coding style

 + MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 1);
 + __raw_writel(cs-chconf0, cs-base + 
 OMAP2_MCSPI_CHCONF0);
 + MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 0);
 + __raw_writel(cs-chconf0, cs-base + 
 OMAP2_MCSPI_CHCONF0);
 + }
 + }
 + omap2_mcspi_disable_clocks(mcspi);
 + return 0;
 +}
 +#else
 +#define  omap2_mcspi_resume  NULL
 +#endif
 +
  static struct platform_driver omap2_mcspi_driver = {
   .driver = {
   .name = omap2_mcspi,
   .owner =THIS_MODULE,
   },
 + .resume =   omap2_mcspi_resume,
   .remove =   __exit_p(omap2_mcspi_remove),
  };
  -- 1.7.0.4

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

Re: OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled

* Kevin Hilman khil...@deeprootsystems.com [101124 16:32]:
 Paul Walmsley p...@pwsan.com writes:

snip

 Acked-by: Kevin Hilman khil...@deeprootsystems.com
 
 Very nice.  I've been exploring various solutions to this problem as
 well, but this one is much cleaner.  Also, I hadn't discovered the 'try'
 version of the console semaphore, so was running into recursive locking.
 
 Anyways, tested on omap35xx: omap3evm (uart1/core console) and beagle
 (uart3/per console) and omap34xx/n900 (uart3/per console) using both
 retention-idle and off-idle.

Thanks, queuing this as fix for the -rc cycle.

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

Re: [PATCH v7 00/11] OMAP: GPIO: Implement GPIO as a platform device

Varadarajan, Charulatha ch...@ti.com writes:

 Implement OMAP GPIO module in platform device model. OMAP2+ specific GPIO
 module uses hwmod FW.

 Tested on OMAP2430, OMAP44430, OMAP3430 SDP boards, OMAP4430 Blaze board
 and zoom3 board. Verified that this patch series does not break the OMAP1
 build.

 Version History:
 ---
 v7 Series:
 - Use gpio iclks as main_clk in OMAP3  OMAP4
 - Implement GPIO as a platform device (use hwmod FW for OMAP2+)
  and the implementation is similar to current GPIO code. Does not
  modify the gpio suspend/ resume/ prepare for odle and resume after
  idle code and these modifications would be done in a separate patch
  series. This was suggested by Kevin in another internal email thread.

OK, I'm ready to merge this series, and we can deal with the runtime PM
conversion in another series as that's where the tricky part lies.

However, I'd like one more rebase/retest due to some other dependencies.
Can you rebase/retest using my current pm-core branch?   That includes
several dependencies that are also targetted for 2.6.38:

- misc. PM fixes
- i2c hwmod + runtime PM conversion (my pm-hwmod-i2c branch)
- several board file changes/updates (Tony's devel-board branch)
- hwmod core fixes (Paul's hwmod_a_2.6.38 branch)
- wdt hwmod cleanups (Paul's wdt_2.6.38 branch)

Also, can you collect the acks from Benoît and update your changelogs to
include them.  Thanks.

Please be sure your board file changes are updated for the board file
changes in the devel-board branch.

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: [PATCH v3 3/3] OMAP3: remove OPP interfaces from OMAP PM layer

2010-11-24 Thread Paul Walmsley

On Wed, 24 Nov 2010, Nishanth Menon wrote:

 From: Kevin Hilman khil...@deeprootsystems.com
 
 With new OPP layer, OPP users will access OPP API directly instead of
 using OMAP PM layer, so remove all notions of OPPs from the OMAP PM
 layer.
 
 Signed-off-by: Nishanth Menon n...@ti.com
 Signed-off-by: Kevin Hilman khil...@deeprootsystems.com

Acked-by: Paul Walmsley p...@pwsan.com

 ---
 
 posted for completeness sake - no change involved
 v3: no longer explicitly calling the init_table, instead
 depending on the device_initcall to initialize as needed
 
 v2: https://patchwork.kernel.org/patch/266931/
 
  arch/arm/mach-omap2/io.c  |3 +-
  arch/arm/plat-omap/include/plat/omap-pm.h |   31 +---
  arch/arm/plat-omap/omap-pm-noop.c |   11 +-
  3 files changed, 12 insertions(+), 33 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
 index 40562dd..2fe4e02 100644
 --- a/arch/arm/mach-omap2/io.c
 +++ b/arch/arm/mach-omap2/io.c
 @@ -327,8 +327,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params 
 *sdrc_cs0,
   else if (cpu_is_omap44xx())
   omap44xx_hwmod_init();
  
 - /* The OPP tables have to be registered before a clk init */
 - omap_pm_if_early_init(mpu_opps, dsp_opps, l3_opps);
 + omap_pm_if_early_init();
  
   if (cpu_is_omap2420())
   omap2420_clk_init();
 diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h 
 b/arch/arm/plat-omap/include/plat/omap-pm.h
 index 728fbb9..62c3fe9 100644
 --- a/arch/arm/plat-omap/include/plat/omap-pm.h
 +++ b/arch/arm/plat-omap/include/plat/omap-pm.h
 @@ -17,27 +17,10 @@
  #include linux/device.h
  #include linux/cpufreq.h
  #include linux/clk.h
 +#include linux/opp.h
  
  #include powerdomain.h
  
 -/**
 - * struct omap_opp - clock frequency-to-OPP ID table for DSP, MPU
 - * @rate: target clock rate
 - * @opp_id: OPP ID
 - * @min_vdd: minimum VDD1 voltage (in millivolts) for this OPP
 - *
 - * Operating performance point data.  Can vary by OMAP chip and board.
 - */
 -struct omap_opp {
 - unsigned long rate;
 - u8 opp_id;
 - u16 min_vdd;
 -};
 -
 -extern struct omap_opp *mpu_opps;
 -extern struct omap_opp *dsp_opps;
 -extern struct omap_opp *l3_opps;
 -
  /*
   * agent_id values for use with omap_pm_set_min_bus_tput():
   *
 @@ -59,9 +42,11 @@ extern struct omap_opp *l3_opps;
   * framework starts.  The _if_ is to avoid name collisions with the
   * PM idle-loop code.
   */
 -int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table,
 -  struct omap_opp *dsp_opp_table,
 -  struct omap_opp *l3_opp_table);
 +#ifdef CONFIG_OMAP_PM_NONE
 +#define omap_pm_if_early_init() 0
 +#else
 +int __init omap_pm_if_early_init(void);
 +#endif
  
  /**
   * omap_pm_if_init - OMAP PM init code called after clock fw init
 @@ -69,7 +54,11 @@ int __init omap_pm_if_early_init(struct omap_opp 
 *mpu_opp_table,
   * The main initialization code.  OPP tables are passed in here.  The
   * _if_ is to avoid name collisions with the PM idle-loop code.
   */
 +#ifdef CONFIG_OMAP_PM_NONE
 +#define omap_pm_if_init() 0
 +#else
  int __init omap_pm_if_init(void);
 +#endif
  
  /**
   * omap_pm_if_exit - OMAP PM exit code
 diff --git a/arch/arm/plat-omap/omap-pm-noop.c 
 b/arch/arm/plat-omap/omap-pm-noop.c
 index e129ce8..ca75abb 100644
 --- a/arch/arm/plat-omap/omap-pm-noop.c
 +++ b/arch/arm/plat-omap/omap-pm-noop.c
 @@ -26,10 +26,6 @@
  
  #include plat/powerdomain.h
  
 -struct omap_opp *dsp_opps;
 -struct omap_opp *mpu_opps;
 -struct omap_opp *l3_opps;
 -
  /*
   * Device-driver-originated constraints (via board-*.c files)
   */
 @@ -308,13 +304,8 @@ int omap_pm_get_dev_context_loss_count(struct device 
 *dev)
  
  
  /* Should be called before clk framework init */
 -int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table,
 -  struct omap_opp *dsp_opp_table,
 -  struct omap_opp *l3_opp_table)
 +int __init omap_pm_if_early_init(void)
  {
 - mpu_opps = mpu_opp_table;
 - dsp_opps = dsp_opp_table;
 - l3_opps = l3_opp_table;
   return 0;
  }
  
 -- 
 1.6.3.3
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 


- 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

[RFC/PATCH v6 10/12] v4l: Add a media_device pointer to the v4l2_device structure

The pointer will later be used to register/unregister media entities
when registering/unregistering a v4l2_subdev or a video_device.

With the introduction of media devices, device drivers need to store a
pointer to a driver-specific structure in the device's drvdata.
v4l2_device can't claim ownership of the drvdata anymore.

To maintain compatibility with drivers that rely on v4l2_device storing
a pointer to itself in the device's drvdata, v4l2_device_register() will
keep doing so if the drvdata is NULL.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 Documentation/video4linux/v4l2-framework.txt |   17 -
 drivers/media/video/v4l2-device.c|   13 +++--
 include/media/v4l2-device.h  |4 
 3 files changed, 23 insertions(+), 11 deletions(-)

diff --git a/Documentation/video4linux/v4l2-framework.txt 
b/Documentation/video4linux/v4l2-framework.txt
index 4db1def..aeb2a22 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -83,11 +83,17 @@ You must register the device instance:
 
v4l2_device_register(struct device *dev, struct v4l2_device *v4l2_dev);
 
-Registration will initialize the v4l2_device struct and link dev-driver_data
-to v4l2_dev. If v4l2_dev-name is empty then it will be set to a value derived
-from dev (driver name followed by the bus_id, to be precise). If you set it
-up before calling v4l2_device_register then it will be untouched. If dev is
-NULL, then you *must* setup v4l2_dev-name before calling v4l2_device_register.
+Registration will initialize the v4l2_device struct. If the dev-driver_data
+field is NULL, it will be linked to v4l2_dev. Drivers that use the media
+device framework in addition to the V4L2 framework need to set
+dev-driver_data manually to point to the driver-specific device structure
+that embed the struct v4l2_device instance. This is achieved by a
+dev_set_drvdata() call before registering the V4L2 device instance.
+
+If v4l2_dev-name is empty then it will be set to a value derived from dev
+(driver name followed by the bus_id, to be precise). If you set it up before
+calling v4l2_device_register then it will be untouched. If dev is NULL, then
+you *must* setup v4l2_dev-name before calling v4l2_device_register.
 
 You can use v4l2_device_set_name() to set the name based on a driver name and
 a driver-global atomic_t instance. This will generate names like ivtv0, ivtv1,
@@ -108,6 +114,7 @@ You unregister with:
 
v4l2_device_unregister(struct v4l2_device *v4l2_dev);
 
+If the dev-driver_data field points to v4l2_dev, it will be reset to NULL.
 Unregistering will also automatically unregister all subdevs from the device.
 
 If you have a hotpluggable device (e.g. a USB device), then when a disconnect
diff --git a/drivers/media/video/v4l2-device.c 
b/drivers/media/video/v4l2-device.c
index 318e911..8447466 100644
--- a/drivers/media/video/v4l2-device.c
+++ b/drivers/media/video/v4l2-device.c
@@ -46,9 +46,8 @@ int v4l2_device_register(struct device *dev, struct 
v4l2_device *v4l2_dev)
if (!v4l2_dev-name[0])
snprintf(v4l2_dev-name, sizeof(v4l2_dev-name), %s %s,
dev-driver-name, dev_name(dev));
-   if (dev_get_drvdata(dev))
-   v4l2_warn(v4l2_dev, Non-NULL drvdata on register\n);
-   dev_set_drvdata(dev, v4l2_dev);
+   if (!dev_get_drvdata(dev))
+   dev_set_drvdata(dev, v4l2_dev);
return 0;
 }
 EXPORT_SYMBOL_GPL(v4l2_device_register);
@@ -71,10 +70,12 @@ EXPORT_SYMBOL_GPL(v4l2_device_set_name);
 
 void v4l2_device_disconnect(struct v4l2_device *v4l2_dev)
 {
-   if (v4l2_dev-dev) {
+   if (v4l2_dev-dev == NULL)
+   return;
+
+   if (dev_get_drvdata(v4l2_dev-dev) == v4l2_dev)
dev_set_drvdata(v4l2_dev-dev, NULL);
-   v4l2_dev-dev = NULL;
-   }
+   v4l2_dev-dev = NULL;
 }
 EXPORT_SYMBOL_GPL(v4l2_device_disconnect);
 
diff --git a/include/media/v4l2-device.h b/include/media/v4l2-device.h
index 6648036..b649c74 100644
--- a/include/media/v4l2-device.h
+++ b/include/media/v4l2-device.h
@@ -21,6 +21,7 @@
 #ifndef _V4L2_DEVICE_H
 #define _V4L2_DEVICE_H
 
+#include media/media-device.h
 #include media/v4l2-subdev.h
 
 /* Each instance of a V4L2 device should create the v4l2_device struct,
@@ -39,6 +40,9 @@ struct v4l2_device {
   Note: dev might be NULL if there is no parent device
   as is the case with e.g. ISA devices. */
struct device *dev;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+   struct media_device *mdev;
+#endif
/* used to keep track of the registered subdevs */
struct list_head subdevs;
/* lock this struct; can be used by the driver as well if this
-- 
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

[RFC/PATCH v6 11/12] v4l: Make video_device inherit from media_entity

V4L2 devices are media entities. As such they need to inherit from
(include) the media_entity structure.

When registering/unregistering the device, the media entity is
automatically registered/unregistered. The entity is acquired on device
open and released on device close.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
 Documentation/video4linux/v4l2-framework.txt |   38 +++--
 drivers/media/video/v4l2-dev.c   |   47 +++---
 include/media/v4l2-dev.h |7 
 3 files changed, 84 insertions(+), 8 deletions(-)

diff --git a/Documentation/video4linux/v4l2-framework.txt 
b/Documentation/video4linux/v4l2-framework.txt
index aeb2a22..f231bc20 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -71,6 +71,10 @@ sub-device instances, the video_device struct stores V4L2 
device node data
 and in the future a v4l2_fh struct will keep track of filehandle instances
 (this is not yet implemented).
 
+The V4L2 framework also optionally integrates with the media framework. If a
+driver sets the struct v4l2_device mdev field, sub-devices and video nodes
+will automatically appear in the media framework as entities.
+
 
 struct v4l2_device
 --
@@ -84,11 +88,14 @@ You must register the device instance:
v4l2_device_register(struct device *dev, struct v4l2_device *v4l2_dev);
 
 Registration will initialize the v4l2_device struct. If the dev-driver_data
-field is NULL, it will be linked to v4l2_dev. Drivers that use the media
-device framework in addition to the V4L2 framework need to set
+field is NULL, it will be linked to v4l2_dev.
+
+Drivers that want integration with the media device framework need to set
 dev-driver_data manually to point to the driver-specific device structure
 that embed the struct v4l2_device instance. This is achieved by a
-dev_set_drvdata() call before registering the V4L2 device instance.
+dev_set_drvdata() call before registering the V4L2 device instance. They must
+also set the struct v4l2_device mdev field to point to a properly initialized
+and registered media_device instance.
 
 If v4l2_dev-name is empty then it will be set to a value derived from dev
 (driver name followed by the bus_id, to be precise). If you set it up before
@@ -532,6 +539,21 @@ If you use v4l2_ioctl_ops, then you should set either 
.unlocked_ioctl or
 The v4l2_file_operations struct is a subset of file_operations. The main
 difference is that the inode argument is omitted since it is never used.
 
+If integration with the media framework is needed, you must initialize the
+media_entity struct embedded in the video_device struct (entity field) by
+calling media_entity_init():
+
+   struct media_pad *pad = my_vdev-pad;
+   int err;
+
+   err = media_entity_init(vdev-entity, 1, pad, 0);
+
+The pads array must have been previously initialized. There is no need to
+manually set the struct media_entity type and name fields.
+
+A reference to the entity will be automatically acquired/released when the
+video device is opened/closed.
+
 v4l2_file_operations and locking
 
 
@@ -561,6 +583,9 @@ for you.
return err;
}
 
+If the v4l2_device parent device has a non-NULL mdev field, the video device
+entity will be automatically registered with the media device.
+
 Which device is registered depends on the type argument. The following
 types exist:
 
@@ -636,6 +661,13 @@ release, of course) will return an error as well.
 When the last user of the video device node exits, then the vdev-release()
 callback is called and you can do the final cleanup there.
 
+Don't forget to cleanup the media entity associated with the video device if
+it has been initialized:
+
+   media_entity_cleanup(vdev-entity);
+
+This can be done from the release callback.
+
 
 video_device helper functions
 -
diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
index 035db52..511e1ee 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
@@ -278,6 +278,9 @@ static int v4l2_mmap(struct file *filp, struct 
vm_area_struct *vm)
 static int v4l2_open(struct inode *inode, struct file *filp)
 {
struct video_device *vdev;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+   struct media_entity *entity = NULL;
+#endif
int ret = 0;
 
/* Check if the video device is available */
@@ -291,6 +294,16 @@ static int v4l2_open(struct inode *inode, struct file 
*filp)
/* and increase the device refcount */
video_get(vdev);
mutex_unlock(videodev_lock);
+#if defined(CONFIG_MEDIA_CONTROLLER)
+   if (vdev-v4l2_dev  vdev-v4l2_dev-mdev) {
+   entity = media_entity_get(vdev-entity);
+   if (!entity) {
+   ret =

[RFC/PATCH v6 01/12] media: Media device node support

The media_devnode structure provides support for registering and
unregistering character devices using a dynamic major number. Reference
counting is handled internally, making device drivers easier to write
without having to solve the open/disconnect race condition issue over
and over again.

The code is based on video/v4l2-dev.c.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/Kconfig |   13 ++
 drivers/media/Makefile|   10 +-
 drivers/media/media-devnode.c |  321 +
 include/media/media-devnode.h |   97 +
 4 files changed, 439 insertions(+), 2 deletions(-)
 create mode 100644 drivers/media/media-devnode.c
 create mode 100644 include/media/media-devnode.h

diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index a28541b..6b946e6 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -14,6 +14,19 @@ if MEDIA_SUPPORT
 comment Multimedia core support
 
 #
+# Media controller
+#
+
+config MEDIA_CONTROLLER
+   bool Media Controller API (EXPERIMENTAL)
+   depends on EXPERIMENTAL
+   ---help---
+ Enable the media controller API used to query media devices internal
+ topology and configure it dynamically.
+
+ This API is mostly used by camera interfaces in embedded platforms.
+
+#
 # V4L core and enabled API's
 #
 
diff --git a/drivers/media/Makefile b/drivers/media/Makefile
index 499b081..3a08991 100644
--- a/drivers/media/Makefile
+++ b/drivers/media/Makefile
@@ -2,7 +2,13 @@
 # Makefile for the kernel multimedia device drivers.
 #
 
+media-objs := media-devnode.o
+
+ifeq ($(CONFIG_MEDIA_CONTROLLER),y)
+  obj-$(CONFIG_MEDIA_SUPPORT) += media.o
+endif
+
 obj-y += common/ IR/ video/
 
-obj-$(CONFIG_VIDEO_DEV) += radio/
-obj-$(CONFIG_DVB_CORE)  += dvb/
+obj-$(CONFIG_VIDEO_DEV)+= radio/
+obj-$(CONFIG_DVB_CORE) += dvb/
diff --git a/drivers/media/media-devnode.c b/drivers/media/media-devnode.c
new file mode 100644
index 000..7804b70
--- /dev/null
+++ b/drivers/media/media-devnode.c
@@ -0,0 +1,321 @@
+/*
+ * Media device node
+ *
+ * Copyright (C) 2010 Nokia Corporation
+ *
+ * Based on drivers/media/video/v4l2_dev.c code authored by
+ * Mauro Carvalho Chehab mche...@infradead.org (version 2)
+ * Alan Cox, a...@lxorguk.ukuu.org.uk (version 1)
+ *
+ * Contacts: Laurent Pinchart laurent.pinch...@ideasonboard.com
+ *  Sakari Ailus sakari.ai...@maxwell.research.nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ * --
+ *
+ * Generic media device node infrastructure to register and unregister
+ * character devices using a dynamic major number and proper reference
+ * counting.
+ */
+
+#include linux/errno.h
+#include linux/init.h
+#include linux/module.h
+#include linux/kernel.h
+#include linux/kmod.h
+#include linux/slab.h
+#include linux/mm.h
+#include linux/smp_lock.h
+#include linux/string.h
+#include linux/types.h
+#include linux/uaccess.h
+#include asm/system.h
+
+#include media/media-devnode.h
+
+#define MEDIA_NUM_DEVICES  256
+#define MEDIA_NAME media
+
+static dev_t media_dev_t;
+
+/*
+ * Active devices
+ */
+static DEFINE_MUTEX(media_devnode_lock);
+static DECLARE_BITMAP(media_devnode_nums, MEDIA_NUM_DEVICES);
+
+/* Called when the last user of the media device exits. */
+static void media_devnode_release(struct device *cd)
+{
+   struct media_devnode *mdev = to_media_devnode(cd);
+
+   mutex_lock(media_devnode_lock);
+
+   /* Delete the cdev on this minor as well */
+   cdev_del(mdev-cdev);
+
+   /* Mark device node number as free */
+   clear_bit(mdev-minor, media_devnode_nums);
+
+   mutex_unlock(media_devnode_lock);
+
+   /* Release media_devnode and perform other cleanups as needed. */
+   if (mdev-release)
+   mdev-release(mdev);
+}
+
+static struct bus_type media_bus_type = {
+   .name = MEDIA_NAME,
+};
+
+static ssize_t media_read(struct file *filp, char __user *buf,
+   size_t sz, loff_t *off)
+{
+   struct media_devnode *mdev = media_devnode_data(filp);
+
+   if (!mdev-fops-read)
+   return -EINVAL;
+   if (!media_devnode_is_registered(mdev))
+   return -EIO;
+   return mdev-fops-read(filp, buf, sz, off);
+}
+
+static ssize_t media_write(struct file *filp,

[RFC/PATCH v6 00/12] Media controller (core and V4L2)

Hi everybody,

Here is the sixth version of the media controller core and V4L2 patches, and
the first one to be sent outside of the linux-media mailing list.

For those who haven't heard about the media controller yet, let me quote the
documentation (Documentation/DocBook/v4l/media-controller.xml).

Discovering a [media] device internal topology, and configuring it at runtime,
is one of the goals of the media controller API. To achieve this, hardware
devices are modelled as an oriented graph of building blocks called entities
connected through pads.

While originally developed to solve problems found in V4L and embedded devices,
the API aims at being useful (and hopefully used) by audio drivers as well,
especially for devices that combine video and audio capabilities.

I want to emphasize that the media controller API does *not* replace the V4L,
DVB or ALSA APIs. It complements them.

The first user of the media controller API is the OMAP3 ISP driver. You can
find it (as well as these patches and other V4L-specific patches) in a git tree
at http://git.linuxtv.org/pinchartl/media.git (media-0004-omap3isp branch). The
OMAP3 ISP driver patches are regularly posted for review on the linux-media
list.

I'm looking forward to the storm of comments that will start in response to
this e-mail. Hopefully it won't hurt (too much) :-).

Laurent Pinchart (10):
  media: Media device node support
  media: Media device
  media: Entities, pads and links
  media: Media device information query
  media: Entities, pads and links enumeration
  media: Links setup
  media: Entity locking and pipeline management
  v4l: Add a media_device pointer to the v4l2_device structure
  v4l: Make video_device inherit from media_entity
  v4l: Make v4l2_subdev inherit from media_entity

Sakari Ailus (2):
  media: Entity graph traversal
  media: Reference count and power handling

 Documentation/DocBook/media-entities.tmpl  |   24 +
 Documentation/DocBook/media.tmpl   |3 +
 Documentation/DocBook/v4l/media-controller.xml |   89 +++
 Documentation/DocBook/v4l/media-func-close.xml |   59 ++
 Documentation/DocBook/v4l/media-func-ioctl.xml |  116 
 Documentation/DocBook/v4l/media-func-open.xml  |   94 +++
 .../DocBook/v4l/media-ioc-device-info.xml  |  133 
 .../DocBook/v4l/media-ioc-enum-entities.xml|  287 +
 Documentation/DocBook/v4l/media-ioc-enum-links.xml |  202 ++
 Documentation/DocBook/v4l/media-ioc-setup-link.xml |   90 +++
 Documentation/media-framework.txt  |  380 +++
 Documentation/video4linux/v4l2-framework.txt   |   72 ++-
 drivers/media/Kconfig  |   13 +
 drivers/media/Makefile |   10 +-
 drivers/media/media-device.c   |  379 +++
 drivers/media/media-devnode.c  |  321 +
 drivers/media/media-entity.c   |  680 
 drivers/media/video/v4l2-dev.c |   47 ++-
 drivers/media/video/v4l2-device.c  |   52 ++-
 drivers/media/video/v4l2-subdev.c  |   41 ++-
 include/linux/Kbuild   |1 +
 include/linux/media.h  |  127 
 include/media/media-device.h   |   92 +++
 include/media/media-devnode.h  |   97 +++
 include/media/media-entity.h   |  144 +
 include/media/v4l2-dev.h   |7 +
 include/media/v4l2-device.h|4 +
 include/media/v4l2-subdev.h|   10 +
 28 files changed, 3547 insertions(+), 27 deletions(-)
 create mode 100644 Documentation/DocBook/v4l/media-controller.xml
 create mode 100644 Documentation/DocBook/v4l/media-func-close.xml
 create mode 100644 Documentation/DocBook/v4l/media-func-ioctl.xml
 create mode 100644 Documentation/DocBook/v4l/media-func-open.xml
 create mode 100644 Documentation/DocBook/v4l/media-ioc-device-info.xml
 create mode 100644 Documentation/DocBook/v4l/media-ioc-enum-entities.xml
 create mode 100644 Documentation/DocBook/v4l/media-ioc-enum-links.xml
 create mode 100644 Documentation/DocBook/v4l/media-ioc-setup-link.xml
 create mode 100644 Documentation/media-framework.txt
 create mode 100644 drivers/media/media-device.c
 create mode 100644 drivers/media/media-devnode.c
 create mode 100644 drivers/media/media-entity.c
 create mode 100644 include/linux/media.h
 create mode 100644 include/media/media-device.h
 create mode 100644 include/media/media-devnode.h
 create mode 100644 include/media/media-entity.h

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

[RFC/PATCH v6 06/12] media: Media device information query

Create the following ioctl and implement it at the media device level to
query device information.

- MEDIA_IOC_DEVICE_INFO: Query media device information

The ioctl and its data structure are defined in the new kernel header
linux/media.h available to userspace applications.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 Documentation/DocBook/media-entities.tmpl  |   12 ++
 Documentation/DocBook/v4l/media-controller.xml |   10 ++
 Documentation/DocBook/v4l/media-func-close.xml |   59 +
 Documentation/DocBook/v4l/media-func-ioctl.xml |  116 +
 Documentation/DocBook/v4l/media-func-open.xml  |   94 ++
 .../DocBook/v4l/media-ioc-device-info.xml  |  132 
 drivers/media/media-device.c   |   57 +
 include/linux/Kbuild   |1 +
 include/linux/media.h  |   45 +++
 include/media/media-device.h   |3 +
 10 files changed, 529 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/DocBook/v4l/media-func-close.xml
 create mode 100644 Documentation/DocBook/v4l/media-func-ioctl.xml
 create mode 100644 Documentation/DocBook/v4l/media-func-open.xml
 create mode 100644 Documentation/DocBook/v4l/media-ioc-device-info.xml
 create mode 100644 include/linux/media.h

diff --git a/Documentation/DocBook/media-entities.tmpl 
b/Documentation/DocBook/media-entities.tmpl
index 61d6f11..6af3375 100644
--- a/Documentation/DocBook/media-entities.tmpl
+++ b/Documentation/DocBook/media-entities.tmpl
@@ -11,6 +11,10 @@
 !ENTITY func-select link 
linkend='func-select'functionselect()/function/link
 !ENTITY func-write link 
linkend='func-write'functionwrite()/function/link
 
+!ENTITY media-func-close link 
linkend='media-func-close'functionclose()/function/link
+!ENTITY media-func-ioctl link 
linkend='media-func-ioctl'functionioctl()/function/link
+!ENTITY media-func-open link 
linkend='media-func-open'functionopen()/function/link
+
 !-- Ioctls --
 !ENTITY VIDIOC-CROPCAP link 
linkend='vidioc-cropcap'constantVIDIOC_CROPCAP/constant/link
 !ENTITY VIDIOC-DBG-G-CHIP-IDENT link 
linkend='vidioc-dbg-g-chip-ident'constantVIDIOC_DBG_G_CHIP_IDENT/constant/link
@@ -87,6 +91,8 @@
 !ENTITY VIDIOC-TRY-FMT link 
linkend='vidioc-g-fmt'constantVIDIOC_TRY_FMT/constant/link
 !ENTITY VIDIOC-UNSUBSCRIBE-EVENT link 
linkend='vidioc-subscribe-event'constantVIDIOC_UNSUBSCRIBE_EVENT/constant/link
 
+!ENTITY MEDIA-IOC-DEVICE-INFO link 
linkend='media-ioc-device-info'constantMEDIA_IOC_DEVICE_INFO/constant/link
+
 !-- Types --
 !ENTITY v4l2-std-id link linkend='v4l2-std-id'v4l2_std_id/link
 
@@ -181,6 +187,8 @@
 !ENTITY v4l2-vbi-format structnbsp;link 
linkend='v4l2-vbi-format'v4l2_vbi_format/link
 !ENTITY v4l2-window structnbsp;link 
linkend='v4l2-window'v4l2_window/link
 
+!ENTITY media-device-info structnbsp;link 
linkend='media-device-info'media_device_info/link
+
 !-- Error Codes --
 !ENTITY EACCES errorcodeEACCES/errorcode error code
 !ENTITY EAGAIN errorcodeEAGAIN/errorcode error code
@@ -322,6 +330,10 @@
 !ENTITY sub-media-indices SYSTEM media-indices.tmpl
 
 !ENTITY sub-media-controller SYSTEM v4l/media-controller.xml
+!ENTITY sub-media-open SYSTEM v4l/media-func-open.xml
+!ENTITY sub-media-close SYSTEM v4l/media-func-close.xml
+!ENTITY sub-media-ioctl SYSTEM v4l/media-func-ioctl.xml
+!ENTITY sub-media-ioc-device-info SYSTEM v4l/media-ioc-device-info.xml
 
 !-- Function Reference --
 !ENTITY close SYSTEM v4l/func-close.xml
diff --git a/Documentation/DocBook/v4l/media-controller.xml 
b/Documentation/DocBook/v4l/media-controller.xml
index f89228d..a46b786 100644
--- a/Documentation/DocBook/v4l/media-controller.xml
+++ b/Documentation/DocBook/v4l/media-controller.xml
@@ -74,3 +74,13 @@
 pad to a sink pad./para
   /section
 /chapter
+
+appendix id=media-user-func
+  titleFunction Reference/title
+  !-- Keep this alphabetically sorted. --
+  sub-media-open;
+  sub-media-close;
+  sub-media-ioctl;
+  !-- All ioctls go here. --
+  sub-media-ioc-device-info;
+/appendix
diff --git a/Documentation/DocBook/v4l/media-func-close.xml 
b/Documentation/DocBook/v4l/media-func-close.xml
new file mode 100644
index 000..be149c8
--- /dev/null
+++ b/Documentation/DocBook/v4l/media-func-close.xml
@@ -0,0 +1,59 @@
+refentry id=media-func-close
+  refmeta
+refentrytitlemedia close()/refentrytitle
+manvol;
+  /refmeta
+
+  refnamediv
+refnamemedia-close/refname
+refpurposeClose a media device/refpurpose
+  /refnamediv
+
+  refsynopsisdiv
+funcsynopsis
+  funcsynopsisinfo#include lt;unistd.hgt;/funcsynopsisinfo
+  funcprototype
+   funcdefint functionclose/function/funcdef
+   paramdefint parameterfd/parameter/paramdef
+  /funcprototype
+/funcsynopsis
+  /refsynopsisdiv
+
+  refsect1
+titleArguments/title
+
+variablelist
+  varlistentry
+   termparameterfd/parameter/term
+

[RFC/PATCH v6 02/12] media: Media device

The media_device structure abstracts functions common to all kind of
media devices (v4l2, dvb, alsa, ...). It manages media entities and
offers a userspace API to discover and configure the media device
internal topology.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 Documentation/DocBook/media-entities.tmpl  |2 +
 Documentation/DocBook/media.tmpl   |3 +
 Documentation/DocBook/v4l/media-controller.xml |   56 +
 Documentation/media-framework.txt  |   68 
 drivers/media/Makefile |2 +-
 drivers/media/media-device.c   |  100 
 include/media/media-device.h   |   66 
 7 files changed, 296 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/DocBook/v4l/media-controller.xml
 create mode 100644 Documentation/media-framework.txt
 create mode 100644 drivers/media/media-device.c
 create mode 100644 include/media/media-device.h

diff --git a/Documentation/DocBook/media-entities.tmpl 
b/Documentation/DocBook/media-entities.tmpl
index be34dcb..61d6f11 100644
--- a/Documentation/DocBook/media-entities.tmpl
+++ b/Documentation/DocBook/media-entities.tmpl
@@ -321,6 +321,8 @@
 !ENTITY sub-media-entities SYSTEM media-entities.tmpl
 !ENTITY sub-media-indices SYSTEM media-indices.tmpl
 
+!ENTITY sub-media-controller SYSTEM v4l/media-controller.xml
+
 !-- Function Reference --
 !ENTITY close SYSTEM v4l/func-close.xml
 !ENTITY ioctl SYSTEM v4l/func-ioctl.xml
diff --git a/Documentation/DocBook/media.tmpl b/Documentation/DocBook/media.tmpl
index f11048d..73464b0 100644
--- a/Documentation/DocBook/media.tmpl
+++ b/Documentation/DocBook/media.tmpl
@@ -106,6 +106,9 @@ Foundation. A copy of the license is included in the 
chapter entitled
 sub-remote_controllers;
 /chapter
 /part
+part id=media_common
+sub-media-controller;
+/part
 
 sub-fdl-appendix;
 
diff --git a/Documentation/DocBook/v4l/media-controller.xml 
b/Documentation/DocBook/v4l/media-controller.xml
new file mode 100644
index 000..253ddb4
--- /dev/null
+++ b/Documentation/DocBook/v4l/media-controller.xml
@@ -0,0 +1,56 @@
+partinfo
+  authorgroup
+author
+  firstnameLaurent/firstname
+  surnamePinchart/surname
+  
affiliationaddressemaillaurent.pinch...@ideasonboard.com/email/address/affiliation
+  contribInitial version./contrib
+/author
+  /authorgroup
+  copyright
+year2010/year
+holderLaurent Pinchart/holder
+  /copyright
+
+  revhistory
+!-- Put document revisions here, newest first. --
+revision
+  revnumber1.0.0/revnumber
+  date2010-11-10/date
+  authorinitialslp/authorinitials
+  revremarkInitial revision/revremark
+/revision
+  /revhistory
+/partinfo
+
+titleMedia Controller API/title
+
+chapter id=media_controller
+  titleMedia Controller/title
+
+  section id=media-controller-intro
+titleIntroduction/title
+paraMedia devices increasingly handle multiple related functions. Many 
USB
+cameras include microphones, video capture hardware can also output video,
+or SoC camera interfaces also perform memory-to-memory operations similar 
to
+video codecs./para
+paraIndependent functions, even when implemented in the same hardware, 
can
+be modelled as separate devices. A USB camera with a microphone will be
+presented to userspace applications as V4L2 and ALSA capture devices. The
+devices' relationships (when using a webcam, end-users shouldn't have to
+manually select the associated USB microphone), while not made available
+directly to applications by the drivers, can usually be retrieved from
+sysfs./para
+paraWith more and more advanced SoC devices being introduced, the current
+approach will not scale. Device topologies are getting increasingly complex
+and can't always be represented by a tree structure. Hardware blocks are
+shared between different functions, creating dependencies between seemingly
+unrelated devices./para
+paraKernel abstraction APIs such as V4L2 and ALSA provide means for
+applications to access hardware parameters. As newer hardware expose an
+increasingly high number of those parameters, drivers need to guess what
+applications really require based on limited information, thereby
+implementing policies that belong to userspace./para
+paraThe media controller API aims at solving those problems./para
+  /section
+/chapter
diff --git a/Documentation/media-framework.txt 
b/Documentation/media-framework.txt
new file mode 100644
index 000..84fa43a
--- /dev/null
+++ b/Documentation/media-framework.txt
@@ -0,0 +1,68 @@
+Linux kernel media framework
+
+
+This document describes the Linux kernel media framework, its data structures,
+functions and their usage.
+
+
+Introduction
+
+
+The media controller API is documented in DocBook format in

[RFC/PATCH v6 09/12] media: Entity locking and pipeline management

Link states must not be modified while streaming is in progress on a
graph they belong or connect to. The entity locking API helps drivers
enforcing that requirement.

When starting streaming on a graph, drivers lock all entities in the
graph with a call to media_entity_graph_lock(). Similarly, when stopping
the stream, they unlock the entities with a call to
media_entity_graph_unlock().

The media_entity_graph_lock() function takes a pointer to a media
pipeline and stores it in every entity in the graph. Drivers should
embed the media_pipeline structure in higher-level pipeline structures
and can then access the pipeline through the media_entity structure.

Link configuration will fail with -EBUSY if either end of the link is a
locked entity.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 Documentation/media-framework.txt |   35 
 drivers/media/media-entity.c  |   64 +
 include/media/media-entity.h  |   10 ++
 3 files changed, 109 insertions(+), 0 deletions(-)

diff --git a/Documentation/media-framework.txt 
b/Documentation/media-framework.txt
index e2987b7..3131e1e 100644
--- a/Documentation/media-framework.txt
+++ b/Documentation/media-framework.txt
@@ -343,3 +343,38 @@ and sink entities.
 In other words, activating or deactivating a link propagates reference count
 changes through the graph, and the final state is identical to what it would
 have been if the link had been active or inactive from the start.
+
+
+Entity locking and pipelines
+
+
+When starting streaming, drivers must lock all entities in the graph to
+prevent link states from being modified during streaming by calling
+
+   media_entity_graph_lock(struct media_entity *entity,
+   struct media_pipeline *pipe);
+
+The function will lock all entities connected to the given entity through
+active links, either directly or indirectly.
+
+The media_pipeline instance pointed to by the pipe argument will be stored in
+every entity in the graph. Drivers should embed the media_pipeline structure
+in higher-level pipeline structures and can then access the pipeline through
+the media_entity pipe field.
+
+Calls to media_entity_graph_lock() can be nested. The pipeline pointer must be
+identical for all nested calls to the function.
+
+When stopping the stream, drivers must unlock the entities with
+
+   media_entity_graph_unlock(struct media_entity *entity);
+
+If multiple calls to media_entity_graph_lock() have been made the same number
+of media_entity_graph_unlock() calls are required to unlock the graph. The
+media_entity pipe field is reset to NULL on the last nested unlock call.
+
+Link configuration will fail with -EBUSY if either end of the link is a
+locked entity. If other operations need to be disallowed on locked entities
+(such as changing entities configuration parameters) drivers can explictly
+check the media_entity lock_count field to find out if an entity is locked.
+This operation must be done with the media_device graph_mutex held.
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index 5ebda28..3e2670e 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -196,6 +196,67 @@ media_entity_graph_walk_next(struct media_entity_graph 
*graph)
 }
 EXPORT_SYMBOL_GPL(media_entity_graph_walk_next);
 
+/**
+ * media_entity_graph_lock - Lock all entities in a graph
+ * @entity: Starting entity
+ * @pipe: Media pipeline to be assigned to all entities in the graph.
+ *
+ * Lock all entities connected to a given entity through active links, either
+ * directly or indirectly. The given pipeline is assigned to every entity in
+ * the graph and stored in the media_entity pipe field.
+ *
+ * Calls to this function can be nested, in which case the same number of
+ * media_entity_graph_unlock() calls will be required to unlock the graph. The
+ * pipeline pointer must be identical for all nested calls to
+ * media_entity_graph_lock().
+ */
+void media_entity_graph_lock(struct media_entity *entity,
+struct media_pipeline *pipe)
+{
+   struct media_device *mdev = entity-parent;
+   struct media_entity_graph graph;
+
+   mutex_lock(mdev-graph_mutex);
+
+   media_entity_graph_walk_start(graph, entity);
+
+   while ((entity = media_entity_graph_walk_next(graph))) {
+   entity-lock_count++;
+   WARN_ON(entity-pipe  entity-pipe != pipe);
+   entity-pipe = pipe;
+   }
+
+   mutex_unlock(mdev-graph_mutex);
+}
+EXPORT_SYMBOL_GPL(media_entity_graph_lock);
+
+/**
+ * media_entity_graph_unlock - Unlock all entities in a graph
+ * @entity: Starting entity
+ *
+ * Unlock all entities connected to a given entity through active links, either
+ * directly or indirectly. The media_entity pipe field is reset to NULL on the
+ * last nested unlock call.
+ */
+void

[RFC/PATCH v6 07/12] media: Entities, pads and links enumeration

Create the following two ioctls and implement them at the media device
level to enumerate entities, pads and links.

- MEDIA_IOC_ENUM_ENTITIES: Enumerate entities and their properties
- MEDIA_IOC_ENUM_LINKS: Enumerate all pads and links for a given entity

Entity IDs can be non-contiguous. Userspace applications should
enumerate entities using the MEDIA_ENTITY_ID_FLAG_NEXT flag. When the
flag is set in the entity ID, the MEDIA_IOC_ENUM_ENTITIES will return
the next entity with an ID bigger than the requested one.

Only forward links that originate at one of the entity's source pads are
returned during the enumeration process.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
 Documentation/DocBook/media-entities.tmpl  |8 +
 Documentation/DocBook/v4l/media-controller.xml |2 +
 .../DocBook/v4l/media-ioc-device-info.xml  |3 +-
 .../DocBook/v4l/media-ioc-enum-entities.xml|  287 
 Documentation/DocBook/v4l/media-ioc-enum-links.xml |  202 ++
 drivers/media/media-device.c   |  123 +
 include/linux/media.h  |   81 ++
 include/media/media-entity.h   |   24 +--
 8 files changed, 706 insertions(+), 24 deletions(-)
 create mode 100644 Documentation/DocBook/v4l/media-ioc-enum-entities.xml
 create mode 100644 Documentation/DocBook/v4l/media-ioc-enum-links.xml

diff --git a/Documentation/DocBook/media-entities.tmpl 
b/Documentation/DocBook/media-entities.tmpl
index 6af3375..6e7dae4 100644
--- a/Documentation/DocBook/media-entities.tmpl
+++ b/Documentation/DocBook/media-entities.tmpl
@@ -92,6 +92,8 @@
 !ENTITY VIDIOC-UNSUBSCRIBE-EVENT link 
linkend='vidioc-subscribe-event'constantVIDIOC_UNSUBSCRIBE_EVENT/constant/link
 
 !ENTITY MEDIA-IOC-DEVICE-INFO link 
linkend='media-ioc-device-info'constantMEDIA_IOC_DEVICE_INFO/constant/link
+!ENTITY MEDIA-IOC-ENUM-ENTITIES link 
linkend='media-ioc-enum-entities'constantMEDIA_IOC_ENUM_ENTITIES/constant/link
+!ENTITY MEDIA-IOC-ENUM-LINKS link 
linkend='media-ioc-enum-links'constantMEDIA_IOC_ENUM_LINKS/constant/link
 
 !-- Types --
 !ENTITY v4l2-std-id link linkend='v4l2-std-id'v4l2_std_id/link
@@ -188,6 +190,10 @@
 !ENTITY v4l2-window structnbsp;link 
linkend='v4l2-window'v4l2_window/link
 
 !ENTITY media-device-info structnbsp;link 
linkend='media-device-info'media_device_info/link
+!ENTITY media-entity-desc structnbsp;link 
linkend='media-entity-desc'media_entity_desc/link
+!ENTITY media-links-enum structnbsp;link 
linkend='media-links-enum'media_links_enum/link
+!ENTITY media-pad-desc structnbsp;link 
linkend='media-pad-desc'media_pad_desc/link
+!ENTITY media-link-desc structnbsp;link 
linkend='media-link-desc'media_link_desc/link
 
 !-- Error Codes --
 !ENTITY EACCES errorcodeEACCES/errorcode error code
@@ -334,6 +340,8 @@
 !ENTITY sub-media-close SYSTEM v4l/media-func-close.xml
 !ENTITY sub-media-ioctl SYSTEM v4l/media-func-ioctl.xml
 !ENTITY sub-media-ioc-device-info SYSTEM v4l/media-ioc-device-info.xml
+!ENTITY sub-media-ioc-enum-entities SYSTEM v4l/media-ioc-enum-entities.xml
+!ENTITY sub-media-ioc-enum-links SYSTEM v4l/media-ioc-enum-links.xml
 
 !-- Function Reference --
 !ENTITY close SYSTEM v4l/func-close.xml
diff --git a/Documentation/DocBook/v4l/media-controller.xml 
b/Documentation/DocBook/v4l/media-controller.xml
index a46b786..2c4fd2b 100644
--- a/Documentation/DocBook/v4l/media-controller.xml
+++ b/Documentation/DocBook/v4l/media-controller.xml
@@ -83,4 +83,6 @@
   sub-media-ioctl;
   !-- All ioctls go here. --
   sub-media-ioc-device-info;
+  sub-media-ioc-enum-entities;
+  sub-media-ioc-enum-links;
 /appendix
diff --git a/Documentation/DocBook/v4l/media-ioc-device-info.xml 
b/Documentation/DocBook/v4l/media-ioc-device-info.xml
index ffd0fb8..aa25c31 100644
--- a/Documentation/DocBook/v4l/media-ioc-device-info.xml
+++ b/Documentation/DocBook/v4l/media-ioc-device-info.xml
@@ -27,7 +27,8 @@
   varlistentry
termparameterfd/parameter/term
listitem
- parafd;/para
+ paraFile descriptor returned by
+ link 
linkend='media-func-open'functionopen()/function/link./para
/listitem
   /varlistentry
   varlistentry
diff --git a/Documentation/DocBook/v4l/media-ioc-enum-entities.xml 
b/Documentation/DocBook/v4l/media-ioc-enum-entities.xml
new file mode 100644
index 000..edb1acc
--- /dev/null
+++ b/Documentation/DocBook/v4l/media-ioc-enum-entities.xml
@@ -0,0 +1,287 @@
+refentry id=media-ioc-enum-entities
+  refmeta
+refentrytitleioctl MEDIA_IOC_ENUM_ENTITIES/refentrytitle
+manvol;
+  /refmeta
+
+  refnamediv
+refnameMEDIA_IOC_ENUM_ENTITIES/refname
+refpurposeEnumerate entities and their properties/refpurpose
+  /refnamediv
+
+  refsynopsisdiv
+funcsynopsis
+  funcprototype
+   funcdefint functionioctl/function/funcdef
+   paramdefint

[RFC/PATCH v6 08/12] media: Links setup

Create the following ioctl and implement it at the media device level to
setup links.

- MEDIA_IOC_SETUP_LINK: Modify the properties of a given link

The only property that can currently be modified is the ACTIVE link flag
to activate/deactivate a link. Links marked with the IMMUTABLE link flag
can not be activated or deactivated.

Activating and deactivating a link has effects on entities' use count.
Those changes are automatically propagated through the graph.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
 Documentation/DocBook/media-entities.tmpl  |2 +
 Documentation/DocBook/v4l/media-controller.xml |1 +
 Documentation/DocBook/v4l/media-ioc-setup-link.xml |   90 +
 Documentation/media-framework.txt  |   49 +
 drivers/media/media-device.c   |   45 +
 drivers/media/media-entity.c   |  208 
 include/linux/media.h  |1 +
 include/media/media-entity.h   |8 +
 8 files changed, 404 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/DocBook/v4l/media-ioc-setup-link.xml

diff --git a/Documentation/DocBook/media-entities.tmpl 
b/Documentation/DocBook/media-entities.tmpl
index 6e7dae4..679c585 100644
--- a/Documentation/DocBook/media-entities.tmpl
+++ b/Documentation/DocBook/media-entities.tmpl
@@ -94,6 +94,7 @@
 !ENTITY MEDIA-IOC-DEVICE-INFO link 
linkend='media-ioc-device-info'constantMEDIA_IOC_DEVICE_INFO/constant/link
 !ENTITY MEDIA-IOC-ENUM-ENTITIES link 
linkend='media-ioc-enum-entities'constantMEDIA_IOC_ENUM_ENTITIES/constant/link
 !ENTITY MEDIA-IOC-ENUM-LINKS link 
linkend='media-ioc-enum-links'constantMEDIA_IOC_ENUM_LINKS/constant/link
+!ENTITY MEDIA-IOC-SETUP-LINK link 
linkend='media-ioc-setup-link'constantMEDIA_IOC_SETUP_LINK/constant/link
 
 !-- Types --
 !ENTITY v4l2-std-id link linkend='v4l2-std-id'v4l2_std_id/link
@@ -342,6 +343,7 @@
 !ENTITY sub-media-ioc-device-info SYSTEM v4l/media-ioc-device-info.xml
 !ENTITY sub-media-ioc-enum-entities SYSTEM v4l/media-ioc-enum-entities.xml
 !ENTITY sub-media-ioc-enum-links SYSTEM v4l/media-ioc-enum-links.xml
+!ENTITY sub-media-ioc-setup-link SYSTEM v4l/media-ioc-setup-link.xml
 
 !-- Function Reference --
 !ENTITY close SYSTEM v4l/func-close.xml
diff --git a/Documentation/DocBook/v4l/media-controller.xml 
b/Documentation/DocBook/v4l/media-controller.xml
index 2c4fd2b..2dc25e1 100644
--- a/Documentation/DocBook/v4l/media-controller.xml
+++ b/Documentation/DocBook/v4l/media-controller.xml
@@ -85,4 +85,5 @@
   sub-media-ioc-device-info;
   sub-media-ioc-enum-entities;
   sub-media-ioc-enum-links;
+  sub-media-ioc-setup-link;
 /appendix
diff --git a/Documentation/DocBook/v4l/media-ioc-setup-link.xml 
b/Documentation/DocBook/v4l/media-ioc-setup-link.xml
new file mode 100644
index 000..84323d0
--- /dev/null
+++ b/Documentation/DocBook/v4l/media-ioc-setup-link.xml
@@ -0,0 +1,90 @@
+refentry id=media-ioc-setup-link
+  refmeta
+refentrytitleioctl MEDIA_IOC_SETUP_LINK/refentrytitle
+manvol;
+  /refmeta
+
+  refnamediv
+refnameMEDIA_IOC_SETUP_LINK/refname
+refpurposeModify the properties of a link/refpurpose
+  /refnamediv
+
+  refsynopsisdiv
+funcsynopsis
+  funcprototype
+   funcdefint functionioctl/function/funcdef
+   paramdefint parameterfd/parameter/paramdef
+   paramdefint parameterrequest/parameter/paramdef
+   paramdefstruct media_link_desc *parameterargp/parameter/paramdef
+  /funcprototype
+/funcsynopsis
+  /refsynopsisdiv
+
+  refsect1
+titleArguments/title
+
+variablelist
+  varlistentry
+   termparameterfd/parameter/term
+   listitem
+ paraFile descriptor returned by
+ link 
linkend='media-func-open'functionopen()/function/link./para
+   /listitem
+  /varlistentry
+  varlistentry
+   termparameterrequest/parameter/term
+   listitem
+ paraMEDIA_IOC_ENUM_LINKS/para
+   /listitem
+  /varlistentry
+  varlistentry
+   termparameterargp/parameter/term
+   listitem
+ para/para
+   /listitem
+  /varlistentry
+/variablelist
+  /refsect1
+
+  refsect1
+titleDescription/title
+
+paraTo change link properties applications fill a media-link-desc; with
+link identification information (source and sink pad) and the new requested
+link flags. They then call the MEDIA_IOC_SETUP_LINK ioctl with a pointer to
+that structure./para
+paraThe only configurable property is the constantACTIVE/constant 
link
+flag to activate/deactivate a link. Links marked with the
+constantIMMUTABLE/constant link flag can not be activated or
+deactivated./para
+paraLink activation has no side effect on other links. If an active link
+at the sink pad prevents the link from being

[RFC/PATCH v6 04/12] media: Entity graph traversal

From: Sakari Ailus sakari.ai...@maxwell.research.nokia.com

Add media entity graph traversal. The traversal follows active links by
depth first. Traversing graph backwards is prevented by comparing the next
possible entity in the graph with the previous one. Multiply connected
graphs are thus not supported.

Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Vimarsh Zutshi vimarsh.zut...@nokia.com
---
 Documentation/media-framework.txt |   42 +
 drivers/media/media-entity.c  |  115 +
 include/media/media-entity.h  |   15 +
 3 files changed, 172 insertions(+), 0 deletions(-)

diff --git a/Documentation/media-framework.txt 
b/Documentation/media-framework.txt
index 0332162..27a38a1 100644
--- a/Documentation/media-framework.txt
+++ b/Documentation/media-framework.txt
@@ -215,3 +215,45 @@ Links have flags that describe the link capabilities and 
state.
MEDIA_LINK_FLAG_ACTIVE must also be set since an immutable link is
always active.
 
+
+Graph traversal
+---
+
+The media framework provides APIs to iterate over entities in a graph.
+
+To iterate over all entities belonging to a media device, drivers can use the
+media_device_for_each_entity macro, defined in include/media/media-device.h.
+
+   struct media_entity *entity;
+
+   media_device_for_each_entity(entity, mdev) {
+   /* entity will point to each entity in turn */
+   ...
+   }
+
+Drivers might also need to iterate over all entities in a graph that can be
+reached only through active links starting at a given entity. The media
+framework provides a depth-first graph traversal API for that purpose.
+
+Note that graphs with cycles (whether directed or undirected) are *NOT*
+supported by the graph traversal API. To prevent infinite loops, the graph
+traversal code limits the maximum depth to MEDIA_ENTITY_ENUM_MAX_DEPTH,
+currently defined as 16.
+
+Drivers initiate a graph traversal by calling
+
+   media_entity_graph_walk_start(struct media_entity_graph *graph,
+ struct media_entity *entity);
+
+The graph structure, provided by the caller, is initialized to start graph
+traversal at the given entity.
+
+Drivers can then retrieve the next entity by calling
+
+   media_entity_graph_walk_next(struct media_entity_graph *graph);
+
+When the graph traversal is complete the function will return NULL.
+
+Graph traversal can be interrupted at any moment. No cleanup function call is
+required and the graph structure can be freed normally.
+
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index e4ba2bc..6230f74 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -84,6 +84,121 @@ media_entity_cleanup(struct media_entity *entity)
 }
 EXPORT_SYMBOL_GPL(media_entity_cleanup);
 
+/* 
-
+ * Graph traversal
+ */
+
+static struct media_entity *
+media_entity_other(struct media_entity *entity, struct media_link *link)
+{
+   if (link-source-entity == entity)
+   return link-sink-entity;
+   else
+   return link-source-entity;
+}
+
+/* push an entity to traversal stack */
+static void stack_push(struct media_entity_graph *graph,
+  struct media_entity *entity)
+{
+   if (graph-top == MEDIA_ENTITY_ENUM_MAX_DEPTH - 1) {
+   WARN_ON(1);
+   return;
+   }
+   graph-top++;
+   graph-stack[graph-top].link = 0;
+   graph-stack[graph-top].entity = entity;
+}
+
+static struct media_entity *stack_pop(struct media_entity_graph *graph)
+{
+   struct media_entity *entity;
+
+   entity = graph-stack[graph-top].entity;
+   graph-top--;
+
+   return entity;
+}
+
+#define stack_peek(en) ((en)-stack[(en)-top - 1].entity)
+#define link_top(en)   ((en)-stack[(en)-top].link)
+#define stack_top(en)  ((en)-stack[(en)-top].entity)
+
+/**
+ * media_entity_graph_walk_start - Start walking the media graph at a given 
entity
+ * @graph: Media graph structure that will be used to walk the graph
+ * @entity: Starting entity
+ *
+ * This function initializes the graph traversal structure to walk the entities
+ * graph starting at the given entity. The traversal structure must not be
+ * modified by the caller during graph traversal. When done the structure can
+ * safely be freed.
+ */
+void media_entity_graph_walk_start(struct media_entity_graph *graph,
+  struct media_entity *entity)
+{
+   graph-top = 0;
+   graph-stack[graph-top].entity = NULL;
+   stack_push(graph, entity);
+}
+EXPORT_SYMBOL_GPL(media_entity_graph_walk_start);
+
+/**
+ * media_entity_graph_walk_next - Get the next entity in the graph
+ * @graph: Media graph structure
+ *
+ * Perform a

[RFC/PATCH v6 05/12] media: Reference count and power handling

From: Sakari Ailus sakari.ai...@maxwell.research.nokia.com

Basically these are the interface functions:

media_entity_get() - acquire entity
media_entity_put() - release entity

If the entity is of node type, the power change is distributed to
all connected entities. For non-nodes it only affects that very
node. A mutex is used to serialise access to the entity graph.

In the background there's a depth-first search algorithm that traverses the
active links in the graph. All these functions parse the graph to implement
whatever they're to do.

The module counters are increased/decreased in media_entity_get/put to
prevent module unloading when an entity is referenced.

Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com
---
 Documentation/media-framework.txt |   37 +
 drivers/media/media-device.c  |1 +
 drivers/media/media-entity.c  |  146 +
 include/media/media-device.h  |4 +
 include/media/media-entity.h  |   15 
 5 files changed, 203 insertions(+), 0 deletions(-)

diff --git a/Documentation/media-framework.txt 
b/Documentation/media-framework.txt
index 27a38a1..9fdbc50 100644
--- a/Documentation/media-framework.txt
+++ b/Documentation/media-framework.txt
@@ -257,3 +257,40 @@ When the graph traversal is complete the function will 
return NULL.
 Graph traversal can be interrupted at any moment. No cleanup function call is
 required and the graph structure can be freed normally.
 
+
+Reference counting and power handling
+-
+
+Before accessing type-specific entities operations (such as the V4L2
+sub-device operations), drivers must acquire a reference to the entity. This
+ensures that the entity will be powered on and ready to accept requests.
+Similarly, after being done with an entity, drivers must release the
+reference.
+
+   media_entity_get(struct media_entity *entity)
+
+The function will increase the entity reference count. If the entity is a node
+(MEDIA_ENTITY_TYPE_NODE type), the reference count of all entities it is
+connected to, both directly or indirectly, through active links is increased.
+This ensures that the whole media pipeline will be ready to process
+
+Acquiring a reference to an entity increases the media device module reference
+count to prevent module unloading when an entity is being used.
+
+media_entity_get will return a pointer to the entity if successful, or NULL
+otherwise.
+
+   media_entity_put(struct media_entity *entity)
+
+The function will decrease the entity reference count and, for node entities,
+like media_entity_get, the reference count of all connected entities. Calling
+media_entity_put with a NULL argument is valid and will return immediately.
+
+When the first reference to an entity is acquired, or the last reference
+released, the entity's set_power operation is called. Entity drivers must
+implement the operation if they need to perform any power management task,
+such as turning powers or clocks on or off. If no power management is
+required, drivers don't need to provide a set_power operation. The operation
+is allowed to fail when turning power on, in which case the media_entity_get
+function will return NULL.
+
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 2163610..52e5985 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -73,6 +73,7 @@ int __must_check media_device_register(struct media_device 
*mdev)
mdev-entity_id = 1;
INIT_LIST_HEAD(mdev-entities);
spin_lock_init(mdev-lock);
+   mutex_init(mdev-graph_mutex);
 
/* Register the device node. */
mdev-devnode.fops = media_device_fops;
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index 6230f74..c15f16b 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -23,6 +23,7 @@
 #include linux/module.h
 #include linux/slab.h
 #include media/media-entity.h
+#include media/media-device.h
 
 /**
  * media_entity_init - Initialize a media entity
@@ -196,6 +197,151 @@ media_entity_graph_walk_next(struct media_entity_graph 
*graph)
 EXPORT_SYMBOL_GPL(media_entity_graph_walk_next);
 
 /* 
-
+ * Power state handling
+ */
+
+/* Apply use count to an entity. */
+static void media_entity_use_apply_one(struct media_entity *entity, int change)
+{
+   entity-use_count += change;
+   WARN_ON(entity-use_count  0);
+}
+
+/*
+ * Apply use count change to an entity and change power state based on
+ * new use count.
+ */
+static int media_entity_power_apply_one(struct media_entity *entity, int 
change)
+{
+   int ret;
+
+   if (entity-use_count == 0  change  0 
+   entity-ops  entity-ops-set_power) {
+

[RFC/PATCH v6 03/12] media: Entities, pads and links

As video hardware pipelines become increasingly complex and
configurable, the current hardware description through v4l2 subdevices
reaches its limits. In addition to enumerating and configuring
subdevices, video camera drivers need a way to discover and modify at
runtime how those subdevices are connected. This is done through new
elements called entities, pads and links.

An entity is a basic media hardware building block. It can correspond to
a large variety of logical blocks such as physical hardware devices
(CMOS sensor for instance), logical hardware devices (a building block
in a System-on-Chip image processing pipeline), DMA channels or physical
connectors.

A pad is a connection endpoint through which an entity can interact with
other entities. Data (not restricted to video) produced by an entity
flows from the entity's output to one or more entity inputs. Pads should
not be confused with physical pins at chip boundaries.

A link is a point-to-point oriented connection between two pads, either
on the same entity or on different entities. Data flows from a source
pad to a sink pad.

Links are stored in the source entity. To make backwards graph walk
faster, a copy of all links is also stored in the sink entity. The copy
is known as a backlink and is only used to help graph traversal.

The entity API is made of three functions:

- media_entity_init() initializes an entity. The caller must provide an
array of pads as well as an estimated number of links. The links array
is allocated dynamically and will be reallocated if it grows beyond the
initial estimate.

- media_entity_cleanup() frees resources allocated for an entity. It
must be called during the cleanup phase after unregistering the entity
and before freeing it.

- media_entity_create_link() creates a link between two entities. An
entry in the link array of each entity is allocated and stores pointers
to source and sink pads.

When a media device is unregistered, all its entities are unregistered
automatically.

The code is based on Hans Verkuil hverk...@xs4all.nl initial work.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
 Documentation/DocBook/v4l/media-controller.xml |   20 +++
 Documentation/media-framework.txt  |  149 
 drivers/media/Makefile |2 +-
 drivers/media/media-device.c   |   53 +
 drivers/media/media-entity.c   |  147 +++
 include/media/media-device.h   |   19 +++
 include/media/media-entity.h   |  118 +++
 7 files changed, 507 insertions(+), 1 deletions(-)
 create mode 100644 drivers/media/media-entity.c
 create mode 100644 include/media/media-entity.h

diff --git a/Documentation/DocBook/v4l/media-controller.xml 
b/Documentation/DocBook/v4l/media-controller.xml
index 253ddb4..f89228d 100644
--- a/Documentation/DocBook/v4l/media-controller.xml
+++ b/Documentation/DocBook/v4l/media-controller.xml
@@ -53,4 +53,24 @@
 implementing policies that belong to userspace./para
 paraThe media controller API aims at solving those problems./para
   /section
+
+  section id=media-controller-model
+titleMedia device model/title
+paraDiscovering a device internal topology, and configuring it at 
runtime,
+is one of the goals of the media controller API. To achieve this, hardware
+devices are modelled as an oriented graph of building blocks called 
entities
+connected through pads./para
+paraAn entity is a basic media hardware or software building block. It 
can
+correspond to a large variety of logical blocks such as physical hardware
+devices (CMOS sensor for instance), logical hardware devices (a building
+block in a System-on-Chip image processing pipeline), DMA channels or
+physical connectors./para
+paraA pad is a connection endpoint through which an entity can interact
+with other entities. Data (not restricted to video) produced by an entity
+flows from the entity's output to one or more entity inputs. Pads should 
not
+be confused with physical pins at chip boundaries./para
+paraA link is a point-to-point oriented connection between two pads,
+either on the same entity or on different entities. Data flows from a 
source
+pad to a sink pad./para
+  /section
 /chapter
diff --git a/Documentation/media-framework.txt 
b/Documentation/media-framework.txt
index 84fa43a..0332162 100644
--- a/Documentation/media-framework.txt
+++ b/Documentation/media-framework.txt
@@ -13,6 +13,30 @@ Documentation/DocBook/v4l/media-controller.xml. This 
document will focus on
 the kernel-side implementation of the media framework.
 
 
+Abstract media device model
+---
+
+Discovering a device internal topology, and configuring it at runtime, is one
+of the goals of the media framework. To achieve this,

[RFC/PATCH v6 12/12] v4l: Make v4l2_subdev inherit from media_entity

V4L2 subdevices are media entities. As such they need to inherit from
(include) the media_entity structure.

When registering/unregistering the subdevice, the media entity is
automatically registered/unregistered. The entity is acquired on device
open and released on device close.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
 Documentation/video4linux/v4l2-framework.txt |   23 ++
 drivers/media/video/v4l2-device.c|   39 
 drivers/media/video/v4l2-subdev.c|   41 -
 include/media/v4l2-subdev.h  |   10 ++
 4 files changed, 104 insertions(+), 9 deletions(-)

diff --git a/Documentation/video4linux/v4l2-framework.txt 
b/Documentation/video4linux/v4l2-framework.txt
index f231bc20..d0fb880 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -268,6 +268,26 @@ A sub-device driver initializes the v4l2_subdev struct 
using:
 Afterwards you need to initialize subdev-name with a unique name and set the
 module owner. This is done for you if you use the i2c helper functions.
 
+If integration with the media framework is needed, you must initialize the
+media_entity struct embedded in the v4l2_subdev struct (entity field) by
+calling media_entity_init():
+
+   struct media_pad *pads = my_sd-pads;
+   int err;
+
+   err = media_entity_init(sd-entity, npads, pads, 0);
+
+The pads array must have been previously initialized. There is no need to
+manually set the struct media_entity type and name fields, but the revision
+field must be initialized if needed.
+
+A reference to the entity will be automatically acquired/released when the
+subdev device node (if any) is opened/closed.
+
+Don't forget to cleanup the media entity before the sub-device is destroyed:
+
+   media_entity_cleanup(sd-entity);
+
 A device (bridge) driver needs to register the v4l2_subdev with the
 v4l2_device:
 
@@ -277,6 +297,9 @@ This can fail if the subdev module disappeared before it 
could be registered.
 After this function was called successfully the subdev-dev field points to
 the v4l2_device.
 
+If the v4l2_device parent device has a non-NULL mdev field, the sub-device
+entity will be automatically registered with the media device.
+
 You can unregister a sub-device using:
 
v4l2_device_unregister_subdev(sd);
diff --git a/drivers/media/video/v4l2-device.c 
b/drivers/media/video/v4l2-device.c
index 8447466..7ac4d0f 100644
--- a/drivers/media/video/v4l2-device.c
+++ b/drivers/media/video/v4l2-device.c
@@ -115,8 +115,11 @@ void v4l2_device_unregister(struct v4l2_device *v4l2_dev)
 EXPORT_SYMBOL_GPL(v4l2_device_unregister);
 
 int v4l2_device_register_subdev(struct v4l2_device *v4l2_dev,
-   struct v4l2_subdev *sd)
+   struct v4l2_subdev *sd)
 {
+#if defined(CONFIG_MEDIA_CONTROLLER)
+   struct media_entity *entity = sd-entity;
+#endif
struct video_device *vdev;
int err;
 
@@ -134,7 +137,16 @@ int v4l2_device_register_subdev(struct v4l2_device 
*v4l2_dev,
err = v4l2_ctrl_add_handler(v4l2_dev-ctrl_handler, sd-ctrl_handler);
if (err)
return err;
-
+#if defined(CONFIG_MEDIA_CONTROLLER)
+   /* Register the entity. */
+   if (v4l2_dev-mdev) {
+   err = media_device_register_entity(v4l2_dev-mdev, entity);
+   if (err  0) {
+   module_put(sd-owner);
+   return err;
+   }
+   }
+#endif
sd-v4l2_dev = v4l2_dev;
spin_lock(v4l2_dev-lock);
list_add_tail(sd-list, v4l2_dev-subdevs);
@@ -149,26 +161,39 @@ int v4l2_device_register_subdev(struct v4l2_device 
*v4l2_dev,
if (sd-flags  V4L2_SUBDEV_FL_HAS_DEVNODE) {
err = __video_register_device(vdev, VFL_TYPE_SUBDEV, -1, 1,
  sd-owner);
-   if (err  0)
+   if (err  0) {
v4l2_device_unregister_subdev(sd);
+   return err;
+   }
}
-
-   return err;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+   entity-v4l.major = VIDEO_MAJOR;
+   entity-v4l.minor = vdev-minor;
+#endif
+   return 0;
 }
 EXPORT_SYMBOL_GPL(v4l2_device_register_subdev);
 
 void v4l2_device_unregister_subdev(struct v4l2_subdev *sd)
 {
+   struct v4l2_device *v4l2_dev;
+
/* return if it isn't registered */
if (sd == NULL || sd-v4l2_dev == NULL)
return;
 
-   spin_lock(sd-v4l2_dev-lock);
+   v4l2_dev = sd-v4l2_dev;
+
+   spin_lock(v4l2_dev-lock);
list_del(sd-list);
-   spin_unlock(sd-v4l2_dev-lock);
+   spin_unlock(v4l2_dev-lock);
sd-v4l2_dev = NULL;
 
module_put(sd-owner);
+#if defined(CONFIG_MEDIA_CONTROLLER)
+

[RFC/PATCH v3 0/7] OMAP3 ISP driver

Hi everybody,

Here's the third version of the OMAP3 ISP driver patches (and the first one to
be posted to linux-omap), updated to 2.6.37-rc3 and the latest changes in the
media controller and sub-device APIs. The patches have been posted to the
linux-media mailing list minutes ago and I managed not to CC linux-omap by
mistake, sorry about that :-( Please CC the linux-media mailing list when
answering.

You can find the patches in http://git.linuxtv.org/pinchartl/media.git as
usual (media-00043-omap3isp).

The driver is in a pretty good shape now, its public API has been cleaned up
quite a lot compared to the previous submission. We still have a couple of
private ioctls that will need to change (that's on my loong todo list).

Laurent Pinchart (5):
  v4l: subdev: Generic ioctl support
  v4l: Remove module_name argument to the v4l2_i2c_new_subdev*
functions
  v4l: Add subdev sensor g_skip_frames operation
  v4l: Include linux/videodev2.h in media/v4l2-ctrls.h
  OMAP3 ISP driver

Stanimir Varbanov (1):
  omap3: Export omap3isp platform device structure

Tuukka Toivonen (1):
  ARM: OMAP3: Update Camera ISP definitions for OMAP3630

 Documentation/video4linux/v4l2-framework.txt  |5 +
 arch/arm/mach-omap2/devices.c |   46 +-
 arch/arm/mach-omap2/devices.h |   17 +
 arch/arm/plat-omap/include/plat/omap34xx.h|   16 +-
 drivers/media/radio/radio-si4713.c|2 +-
 drivers/media/video/Kconfig   |   15 +
 drivers/media/video/Makefile  |2 +
 drivers/media/video/au0828/au0828-cards.c |4 +-
 drivers/media/video/bt8xx/bttv-cards.c|   22 +-
 drivers/media/video/cafe_ccic.c   |2 +-
 drivers/media/video/cx18/cx18-i2c.c   |8 +-
 drivers/media/video/cx231xx/cx231xx-cards.c   |4 +-
 drivers/media/video/cx23885/cx23885-cards.c   |2 +-
 drivers/media/video/cx23885/cx23885-video.c   |4 +-
 drivers/media/video/cx88/cx88-cards.c |9 +-
 drivers/media/video/cx88/cx88-video.c |7 +-
 drivers/media/video/davinci/vpfe_capture.c|1 -
 drivers/media/video/davinci/vpif_capture.c|1 -
 drivers/media/video/davinci/vpif_display.c|2 +-
 drivers/media/video/em28xx/em28xx-cards.c |   18 +-
 drivers/media/video/fsl-viu.c |2 +-
 drivers/media/video/isp/Makefile  |   13 +
 drivers/media/video/isp/cfa_coef_table.h  |  601 +++
 drivers/media/video/isp/gamma_table.h |   90 +
 drivers/media/video/isp/isp.c | 1977 ++
 drivers/media/video/isp/isp.h |  400 +
 drivers/media/video/isp/ispccdc.c | 2189 +
 drivers/media/video/isp/ispccdc.h |  220 +++
 drivers/media/video/isp/ispccp2.c | 1100 +
 drivers/media/video/isp/ispccp2.h |  101 ++
 drivers/media/video/isp/ispcsi2.c | 1265 ++
 drivers/media/video/isp/ispcsi2.h |  169 ++
 drivers/media/video/isp/ispcsiphy.c   |  246 +++
 drivers/media/video/isp/ispcsiphy.h   |   77 +
 drivers/media/video/isp/isph3a.h  |  117 ++
 drivers/media/video/isp/isph3a_aewb.c |  356 
 drivers/media/video/isp/isph3a_af.c   |  410 +
 drivers/media/video/isp/isphist.c |  505 ++
 drivers/media/video/isp/isphist.h |   40 +
 drivers/media/video/isp/isppreview.c  | 2091 +++
 drivers/media/video/isp/isppreview.h  |  214 +++
 drivers/media/video/isp/ispqueue.c| 1135 +
 drivers/media/video/isp/ispqueue.h|  184 +++
 drivers/media/video/isp/ispreg.h  | 1655 +++
 drivers/media/video/isp/ispresizer.c  | 1711 +++
 drivers/media/video/isp/ispresizer.h  |  149 ++
 drivers/media/video/isp/ispstat.c | 1093 
 drivers/media/video/isp/ispstat.h |  168 ++
 drivers/media/video/isp/ispvideo.c| 1199 ++
 drivers/media/video/isp/ispvideo.h|  183 ++
 drivers/media/video/isp/luma_enhance_table.h  |  154 ++
 drivers/media/video/isp/noise_filter_table.h  |   90 +
 drivers/media/video/ivtv/ivtv-i2c.c   |   23 +-
 drivers/media/video/mxb.c |   12 +-
 drivers/media/video/pvrusb2/pvrusb2-hdw.c |6 +-
 drivers/media/video/s5p-fimc/fimc-capture.c   |3 +-
 drivers/media/video/saa7134/saa7134-cards.c   |8 +-
 drivers/media/video/saa7134/saa7134-core.c|4 +-
 drivers/media/video/sh_vou.c  |2 +-
 drivers/media/video/soc_camera.c  |2 +-
 drivers/media/video/usbvision/usbvision-i2c.c |6 +-
 drivers/media/video/v4l2-common.c |   15 +-
 drivers/media/video/v4l2-subdev.c |2 +-
 drivers/media/video/via-camera.c  |2 +-
 drivers/media/video/vino.c

[RFC/PATCH v3 1/7] v4l: subdev: Generic ioctl support

Instead of returning an error when receiving an ioctl call with an
unsupported command, forward the call to the subdev core::ioctl handler.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 Documentation/video4linux/v4l2-framework.txt |5 +
 drivers/media/video/v4l2-subdev.c|2 +-
 2 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/Documentation/video4linux/v4l2-framework.txt 
b/Documentation/video4linux/v4l2-framework.txt
index d0fb880..1bb5f22 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -407,6 +407,11 @@ VIDIOC_UNSUBSCRIBE_EVENT
To properly support events, the poll() file operation is also
implemented.
 
+Private ioctls
+
+   All ioctls not in the above list are passed directly to the sub-device
+   driver through the core::ioctl operation.
+
 
 I2C sub-device drivers
 --
diff --git a/drivers/media/video/v4l2-subdev.c 
b/drivers/media/video/v4l2-subdev.c
index 438c70f..b57be91 100644
--- a/drivers/media/video/v4l2-subdev.c
+++ b/drivers/media/video/v4l2-subdev.c
@@ -267,7 +267,7 @@ static long subdev_do_ioctl(struct file *file, unsigned int 
cmd, void *arg)
}
 #endif
default:
-   return -ENOIOCTLCMD;
+   return v4l2_subdev_call(sd, core, ioctl, cmd, arg);
}
 
return 0;
-- 
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

[RFC/PATCH v3 3/7] v4l: Add subdev sensor g_skip_frames operation

Some buggy sensors generate corrupt frames when the stream is started.
This new operation return the number of corrupt frames to skip when
starting the stream.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 include/media/v4l2-subdev.h |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 4704a0a..356d16475e 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -343,9 +343,13 @@ struct v4l2_subdev_vbi_ops {
  *   This is needed for some sensors, which always corrupt
  *   several top lines of the output image, or which send their
  *   metadata in them.
+ * @g_skip_frames: number of frames to skip at stream start. This is needed for
+ *buggy sensors that generate faulty frames when they are
+ *turned on.
  */
 struct v4l2_subdev_sensor_ops {
int (*g_skip_top_lines)(struct v4l2_subdev *sd, u32 *lines);
+   int (*g_skip_frames)(struct v4l2_subdev *sd, u32 *frames);
 };
 
 /*
-- 
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

[RFC/PATCH v3 4/7] v4l: Include linux/videodev2.h in media/v4l2-ctrls.h

The later makes extensive use of structures defined in the former.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 include/media/v4l2-ctrls.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index 9b7bea9..3b133b7 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -23,6 +23,7 @@
 
 #include linux/list.h
 #include linux/device.h
+#include linux/videodev2.h
 
 /* forward references */
 struct v4l2_ctrl_handler;
-- 
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

[RFC/PATCH v3 5/7] ARM: OMAP3: Update Camera ISP definitions for OMAP3630

From: Tuukka Toivonen tuukka.o.toivo...@nokia.com

Add new/changed base address definitions and resources for
OMAP3630 ISP.

The OMAP3430 CSI2PHY block is same as the OMAP3630 CSIPHY2
block. But the later name is chosen as it gives more symmetry
to the names.

Signed-off-by: Tuukka Toivonen tuukka.o.toivo...@nokia.com
Signed-off-by: Vimarsh Zutshi vimarsh.zut...@nokia.com
---
 arch/arm/mach-omap2/devices.c  |   28 
 arch/arm/plat-omap/include/plat/omap34xx.h |   16 
 2 files changed, 36 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 5a0c148..d5da345 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -109,13 +109,33 @@ static struct resource omap3isp_resources[] = {
.flags  = IORESOURCE_MEM,
},
{
-   .start  = OMAP3430_ISP_CSI2A_BASE,
-   .end= OMAP3430_ISP_CSI2A_END,
+   .start  = OMAP3430_ISP_CSI2A_REGS1_BASE,
+   .end= OMAP3430_ISP_CSI2A_REGS1_END,
.flags  = IORESOURCE_MEM,
},
{
-   .start  = OMAP3430_ISP_CSI2PHY_BASE,
-   .end= OMAP3430_ISP_CSI2PHY_END,
+   .start  = OMAP3430_ISP_CSIPHY2_BASE,
+   .end= OMAP3430_ISP_CSIPHY2_END,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .start  = OMAP3630_ISP_CSI2A_REGS2_BASE,
+   .end= OMAP3630_ISP_CSI2A_REGS2_END,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .start  = OMAP3630_ISP_CSI2C_REGS1_BASE,
+   .end= OMAP3630_ISP_CSI2C_REGS1_END,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .start  = OMAP3630_ISP_CSIPHY1_BASE,
+   .end= OMAP3630_ISP_CSIPHY1_END,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .start  = OMAP3630_ISP_CSI2C_REGS2_BASE,
+   .end= OMAP3630_ISP_CSI2C_REGS2_END,
.flags  = IORESOURCE_MEM,
},
{
diff --git a/arch/arm/plat-omap/include/plat/omap34xx.h 
b/arch/arm/plat-omap/include/plat/omap34xx.h
index 98fc8b4..b9e8588 100644
--- a/arch/arm/plat-omap/include/plat/omap34xx.h
+++ b/arch/arm/plat-omap/include/plat/omap34xx.h
@@ -56,8 +56,12 @@
 #define OMAP3430_ISP_RESZ_BASE (OMAP3430_ISP_BASE + 0x1000)
 #define OMAP3430_ISP_SBL_BASE  (OMAP3430_ISP_BASE + 0x1200)
 #define OMAP3430_ISP_MMU_BASE  (OMAP3430_ISP_BASE + 0x1400)
-#define OMAP3430_ISP_CSI2A_BASE(OMAP3430_ISP_BASE + 0x1800)
-#define OMAP3430_ISP_CSI2PHY_BASE  (OMAP3430_ISP_BASE + 0x1970)
+#define OMAP3430_ISP_CSI2A_REGS1_BASE  (OMAP3430_ISP_BASE + 0x1800)
+#define OMAP3430_ISP_CSIPHY2_BASE  (OMAP3430_ISP_BASE + 0x1970)
+#define OMAP3630_ISP_CSI2A_REGS2_BASE  (OMAP3430_ISP_BASE + 0x19C0)
+#define OMAP3630_ISP_CSI2C_REGS1_BASE  (OMAP3430_ISP_BASE + 0x1C00)
+#define OMAP3630_ISP_CSIPHY1_BASE  (OMAP3430_ISP_BASE + 0x1D70)
+#define OMAP3630_ISP_CSI2C_REGS2_BASE  (OMAP3430_ISP_BASE + 0x1DC0)
 
 #define OMAP3430_ISP_END   (OMAP3430_ISP_BASE + 0x06F)
 #define OMAP3430_ISP_CBUFF_END (OMAP3430_ISP_CBUFF_BASE   + 0x077)
@@ -69,8 +73,12 @@
 #define OMAP3430_ISP_RESZ_END  (OMAP3430_ISP_RESZ_BASE+ 0x0AB)
 #define OMAP3430_ISP_SBL_END   (OMAP3430_ISP_SBL_BASE + 0x0FB)
 #define OMAP3430_ISP_MMU_END   (OMAP3430_ISP_MMU_BASE + 0x06F)
-#define OMAP3430_ISP_CSI2A_END (OMAP3430_ISP_CSI2A_BASE   + 0x16F)
-#define OMAP3430_ISP_CSI2PHY_END   (OMAP3430_ISP_CSI2PHY_BASE + 0x007)
+#define OMAP3430_ISP_CSI2A_REGS1_END   (OMAP3430_ISP_CSI2A_REGS1_BASE + 0x16F)
+#define OMAP3430_ISP_CSIPHY2_END   (OMAP3430_ISP_CSIPHY2_BASE + 0x00B)
+#define OMAP3630_ISP_CSI2A_REGS2_END   (OMAP3630_ISP_CSI2A_REGS2_BASE + 0x3F)
+#define OMAP3630_ISP_CSI2C_REGS1_END   (OMAP3630_ISP_CSI2C_REGS1_BASE + 0x16F)
+#define OMAP3630_ISP_CSIPHY1_END   (OMAP3630_ISP_CSIPHY1_BASE + 0x00B)
+#define OMAP3630_ISP_CSI2C_REGS2_END   (OMAP3630_ISP_CSI2C_REGS2_BASE + 0x3F)
 
 #define OMAP34XX_HSUSB_OTG_BASE(L4_34XX_BASE + 0xAB000)
 #define OMAP34XX_USBTLL_BASE   (L4_34XX_BASE + 0x62000)
-- 
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

[RFC/PATCH v3 6/7] omap3: Export omap3isp platform device structure

From: Stanimir Varbanov svarba...@mm-sol.com

The omap3isp platform device requires platform data. As the data can be
provided by a kernel module, the device can't be registered during arch
initialization.

Remove the omap3isp platform device registration from
omap_init_camera(), and export the platform device structure to let
board code register/unregister it.

Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 arch/arm/mach-omap2/devices.c |   18 --
 arch/arm/mach-omap2/devices.h |   17 +
 2 files changed, 33 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/mach-omap2/devices.h

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index d5da345..c2275d3 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -34,6 +34,8 @@
 #include mux.h
 #include control.h
 
+#include devices.h
+
 #if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
 
 static struct resource cam_resources[] = {
@@ -144,16 +146,28 @@ static struct resource omap3isp_resources[] = {
}
 };
 
-static struct platform_device omap3isp_device = {
+static void omap3isp_release(struct device *dev)
+{
+   /* Zero the device structure to avoid re-initialization complaints from
+* kobject when the device will be re-registered.
+*/
+   memset(dev, 0, sizeof(*dev));
+   dev-release = omap3isp_release;
+}
+
+struct platform_device omap3isp_device = {
.name   = omap3isp,
.id = -1,
.num_resources  = ARRAY_SIZE(omap3isp_resources),
.resource   = omap3isp_resources,
+   .dev = {
+   .release= omap3isp_release,
+   },
 };
+EXPORT_SYMBOL_GPL(omap3isp_device);
 
 static inline void omap_init_camera(void)
 {
-   platform_device_register(omap3isp_device);
 }
 #else
 static inline void omap_init_camera(void)
diff --git a/arch/arm/mach-omap2/devices.h b/arch/arm/mach-omap2/devices.h
new file mode 100644
index 000..f312d49
--- /dev/null
+++ b/arch/arm/mach-omap2/devices.h
@@ -0,0 +1,17 @@
+/*
+ * arch/arm/mach-omap2/devices.h
+ *
+ * OMAP2 platform device setup/initialization
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP_DEVICES_H
+#define __ARCH_ARM_MACH_OMAP_DEVICES_H
+
+extern struct platform_device omap3isp_device;
+
+#endif
-- 
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

Re: [PATCH v5 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition

2010-11-24 Thread David Brownell



--- On Wed, 11/24/10, Kevin Hilman khil...@deeprootsystems.com wrote:

  I'm not SPI-aware enough to ack
 this patch or
 test it thoroughly.

Heh, my excuse is usually not enough time
or sometimes no test setup ... ;)

In this case I can at least ack the fix in
principle.  CS active means an active trransfer,
which must not happen during OFF  or other
suspend states.


Acked-by: David Brownell dbrown...@users.sourceforge.net



 Also, in the last patch I suggested you do more of a
 save/restore of
 this value instead of a restore to a hard-coded
 value.  IOW, save the
 value in the suspend method, restore it in resume.


More correct to restart
message queue processing
after resume, if it's non-empty, and to have
cleanly stopped it (between messages) before
entering suspend states like OFF.


--
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 1/4] drivers: hwspinlock: add generic framework

2010-11-24 Thread David Brownell

My rule of thumb is that nothing is generic
until at least three whatever-it-is instances
plug in to it.  Sometimes this is called
the Rule of Three.

Other than OMAP, what's providing hardware
spinlocks that plug into this framework?

- Dave

--
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 v7 00/11] OMAP: GPIO: Implement GPIO as a platform device

On Thu, Nov 25, 2010 at 02:28, Cousson, Benoit b-cous...@ti.com wrote:
 Hi Charu,

 On 11/23/2010 3:56 PM, Varadarajan, Charulatha wrote:

 Implement OMAP GPIO module in platform device model. OMAP2+ specific GPIO
 module uses hwmod FW.

 Tested on OMAP2430, OMAP44430, OMAP3430 SDP boards, OMAP4430 Blaze board

 How did you get some top secret samples of the ultra new *44430* device
 running at 16.5 GHz?
 That device should not be released publicly before 10 years ;-)

Typo!! My bad :-( !!!
Thanks for finding it. But nice to know that *44430* device would be
running at 16.5 GHz ;-)


 Benoit

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 v7 00/11] OMAP: GPIO: Implement GPIO as a platform device

Kevin,

On Thu, Nov 25, 2010 at 07:10, Kevin Hilman khil...@deeprootsystems.com wrote:
 Varadarajan, Charulatha ch...@ti.com writes:

 Implement OMAP GPIO module in platform device model. OMAP2+ specific GPIO
 module uses hwmod FW.

 Tested on OMAP2430, OMAP44430, OMAP3430 SDP boards, OMAP4430 Blaze board
 and zoom3 board. Verified that this patch series does not break the OMAP1
 build.

 Version History:
 ---
 v7 Series:
 - Use gpio iclks as main_clk in OMAP3  OMAP4
 - Implement GPIO as a platform device (use hwmod FW for OMAP2+)
  and the implementation is similar to current GPIO code. Does not
  modify the gpio suspend/ resume/ prepare for odle and resume after
  idle code and these modifications would be done in a separate patch
  series. This was suggested by Kevin in another internal email thread.

 OK, I'm ready to merge this series, and we can deal with the runtime PM
 conversion in another series as that's where the tricky part lies.

Thanks.


 However, I'd like one more rebase/retest due to some other dependencies.
 Can you rebase/retest using my current pm-core branch?

Sure I will do that.

 That includes
 several dependencies that are also targetted for 2.6.38:

 - misc. PM fixes
 - i2c hwmod + runtime PM conversion (my pm-hwmod-i2c branch)
 - several board file changes/updates (Tony's devel-board branch)
 - hwmod core fixes (Paul's hwmod_a_2.6.38 branch)
 - wdt hwmod cleanups (Paul's wdt_2.6.38 branch)

 Also, can you collect the acks from Benoît and update your changelogs to
 include them.  Thanks.

Sure.


 Please be sure your board file changes are updated for the board file
 changes in the devel-board branch.

Okay. But if it is different, should I send only the board files changes on
devel-board  branch as a separate patch mentioning the dependencies on
my patch series?
--
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 v7 05/11] OMAP2420: hwmod data: Add GPIO

Benoit,

On Thu, Nov 25, 2010 at 03:43, Cousson, Benoit b-cous...@ti.com wrote:
 On 11/23/2010 3:56 PM, Varadarajan, Charulatha wrote:

 Add GPIO hwmod data for OMAP2420

 Signed-off-by: Charulatha Vch...@ti.com
 ---
  arch/arm/mach-omap2/omap_hwmod_2420_data.c |  229
 
  arch/arm/plat-omap/include/plat/gpio.h     |    5 +
  2 files changed, 234 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
 b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
 index a1a3dd6..c951061 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
 @@ -17,6 +17,7 @@
  #includeplat/dma.h
  #includeplat/serial.h
  #includeplat/i2c.h
 +#includeplat/gpio.h
  #includeplat/omap24xx.h

 Do you still need that header file?

Yes, for the gpio_dev_attr



  #include omap_hwmod_common_data.h
 @@ -38,6 +39,10 @@ static struct omap_hwmod omap2420_iva_hwmod;
  static struct omap_hwmod omap2420_l3_main_hwmod;
  static struct omap_hwmod omap2420_l4_core_hwmod;
  static struct omap_hwmod omap2420_wd_timer2_hwmod;
 +static struct omap_hwmod omap2420_gpio1_hwmod;
 +static struct omap_hwmod omap2420_gpio2_hwmod;
 +static struct omap_hwmod omap2420_gpio3_hwmod;
 +static struct omap_hwmod omap2420_gpio4_hwmod;

  /* L3 -  L4_CORE interface */
  static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
 @@ -557,6 +562,224 @@ static struct omap_hwmod omap2420_i2c2_hwmod = {
        .flags          = HWMOD_16BIT_REG,
  };

 +/* l4_wkup -  gpio1 */
 +static struct omap_hwmod_addr_space omap2420_gpio1_addr_space[] = {
 +       {
 +               .pa_start       = 0x48018000,
 +               .pa_end         = 0x480181ff,
 +               .flags          = ADDR_TYPE_RT
 +       },
 +};
 +
 +static struct omap_hwmod_ocp_if omap2420_l4_wkup__gpio1 = {
 +       .master         =omap2420_l4_wkup_hwmod,
 +       .slave          =omap2420_gpio1_hwmod,
 +       .clk            = gpios_ick,
 +       .addr           = omap2420_gpio1_addr_space,
 +       .addr_cnt       = ARRAY_SIZE(omap2420_gpio1_addr_space),
 +       .user           = OCP_USER_MPU | OCP_USER_SDMA,
 +};
 +
 +/* l4_wkup -  gpio2 */
 +static struct omap_hwmod_addr_space omap2420_gpio2_addr_space[] = {
 +       {
 +               .pa_start       = 0x4801a000,
 +               .pa_end         = 0x4801a1ff,
 +               .flags          = ADDR_TYPE_RT
 +       },
 +};
 +
 +static struct omap_hwmod_ocp_if omap2420_l4_wkup__gpio2 = {
 +       .master         =omap2420_l4_wkup_hwmod,
 +       .slave          =omap2420_gpio2_hwmod,
 +       .clk            = gpios_ick,
 +       .addr           = omap2420_gpio2_addr_space,
 +       .addr_cnt       = ARRAY_SIZE(omap2420_gpio2_addr_space),
 +       .user           = OCP_USER_MPU | OCP_USER_SDMA,
 +};
 +
 +/* l4_wkup -  gpio3 */
 +static struct omap_hwmod_addr_space omap2420_gpio3_addr_space[] = {
 +       {
 +               .pa_start       = 0x4801c000,
 +               .pa_end         = 0x4801c1ff,
 +               .flags          = ADDR_TYPE_RT
 +       },
 +};
 +
 +static struct omap_hwmod_ocp_if omap2420_l4_wkup__gpio3 = {
 +       .master         =omap2420_l4_wkup_hwmod,
 +       .slave          =omap2420_gpio3_hwmod,
 +       .clk            = gpios_ick,
 +       .addr           = omap2420_gpio3_addr_space,
 +       .addr_cnt       = ARRAY_SIZE(omap2420_gpio3_addr_space),
 +       .user           = OCP_USER_MPU | OCP_USER_SDMA,
 +};
 +
 +/* l4_wkup -  gpio4 */
 +static struct omap_hwmod_addr_space omap2420_gpio4_addr_space[] = {
 +       {
 +               .pa_start       = 0x4801e000,
 +               .pa_end         = 0x4801e1ff,
 +               .flags          = ADDR_TYPE_RT
 +       },
 +};
 +
 +static struct omap_hwmod_ocp_if omap2420_l4_wkup__gpio4 = {
 +       .master         =omap2420_l4_wkup_hwmod,
 +       .slave          =omap2420_gpio4_hwmod,
 +       .clk            = gpios_ick,
 +       .addr           = omap2420_gpio4_addr_space,
 +       .addr_cnt       = ARRAY_SIZE(omap2420_gpio4_addr_space),
 +       .user           = OCP_USER_MPU | OCP_USER_SDMA,
 +};
 +
 +/* gpio dev_attr */
 +static struct omap_gpio_dev_attr gpio_dev_attr = {
 +       .bank_width = 32,
 +       .dbck_flag = false,
 +};
 +

snip

  };

 diff --git a/arch/arm/plat-omap/include/plat/gpio.h
 b/arch/arm/plat-omap/include/plat/gpio.h

 That change should not necessarily be there, it is not directly related to
 the subject.

 Maybe that should be in an extra patch just before that one.

I merged these two patches because of a comment to introduce
new variables/structures only in the patch where they are used.
Since omap_gpio_dev_attr is being used by hwmod DB I merged
these two patches. Do you think that hwmod DB patches should not
be merged with other patches?


 Beside these 2 minor comments, that patch seems good to me.

 Almost-acked-by: Benoit Cousson b-cous...@ti.com

Thanks.


 Regards,
 Benoit

 index 5bef86d..24892a6 100644
 ---

Re: [PATCH v7 07/11] OMAP3: hwmod data: Add GPIO