Re: [PATCH v2] staging: tidspbridge: protect dmm_map properly

[Felipe Contreras]

On Tue, Dec 28, 2010 at 8:33 AM, Ohad Ben-Cohen o...@wizery.com wrote:
 On Mon, Dec 27, 2010 at 3:55 PM, Felipe Contreras
 felipe.contre...@nokia.com wrote:
 So, effectively, serializing the proc_begin_dma() and proc_end_dma()
 would not affect anyone negatively for the time being.

 You can never really tell who is using the kernel (or will be using
 this kernel version), how and under which workload.

No, but it's better to address real issues rather than hypothetical.

However, as I sad, everybody is using proc_map() and proc_un_map()
which take a lock, and there are no complaints. This patch would make
proc_begin_dma() and proc_end_dma() as slow as the map operations, so
even these hypothetical users would not get affected negatively.

 For the long-term goal I agree with that approach, however, first, I
 think my patch should be applied, since it's fixing a problem using an
 already existing and actively excersised mechanism. In fact, I think
 this should be pushed to 2.6.37 as:

  1) prevents a kernel panic
  2) the issue is reproducible and clearly identified
  3) the patch is small and obvious

 Both patches are (IMHO). But frankly I don't mind your patch will be
 applied now as long as it doesn't stay. I can rebase my patch against
 it after it is applied, and send separately.

Ok, can I get your Ack? I guess Omar would be able to push it to Greg,
and perhaps it would make .37.

 This approach looks cleaner, however, we need a flag in
 remove_mapping_information() in order to force the removal, otherwise
 there will be memory leaks. Imagine a process crashes, and
 remove_mapping_information() returns -EBUSY.

 Can't happen; both proc_*_dma() operations decrease the reference
 count before exiting, so it's not up to the application.

Then why did you add that check for is_map_obj_used(), and then return
-EBUSY? If that can happen, then it can happen when the application is
crashing; user-space crashes while kernel-space is in the middle of a
proc_*_dma() operation.

 Sure, but I see this as a broader effort to have finer locking, part of
 this should be to remove the already existing proc_lock.

 Having bad locking is not an excuse for adding more.

No, but not being a permanent solution is not an excuse for not fixing
a kernel panic right away.

 Anyway, as I said, I don't really mind your patch will be applied as
 long as it is a temporary workaround.

Can you Ack?

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

Re: [PATCH v2] staging: tidspbridge: protect dmm_map properly

[Ohad Ben-Cohen]

On Tue, Dec 28, 2010 at 12:36 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 You can never really tell who is using the kernel (or will be using
 this kernel version), how and under which workload.

 No, but it's better to address real issues rather than hypothetical.

Right. and both patches do that. one adds locks, and one doesn't.

 However, as I sad, everybody is using proc_map() and proc_un_map()
 which take a lock, and there are no complaints.

I didn't complain about that; I didn't like you adding locks to the DMA API.

 Ok, can I get your Ack?

Frankly, I don't like the locks you are adding. But as I said, I
wouldn't resist them as long as it's temporary.

 Then why did you add that check for is_map_obj_used(), and then return
 -EBUSY? If that can happen, then it can happen when the application is
 crashing; user-space crashes while kernel-space is in the middle of a
 proc_*_dma() operation.

I still don't know how exactly you triggered the bug: is gst-dsp
multithreaded ? and one of its threads invoked proc_un_map() while
another thread called proc_begin_dma() ?

Anyhow, a thread that is calling proc_*_dma() will both increase the
reference count and decrease it back before going back to user space.
Otherwise your patch would be problematic as well - who will unlock
the mutex you take in proc_*_dma() ?

 Sure, but I see this as a broader effort to have finer locking, part of
 this should be to remove the already existing proc_lock.

 Having bad locking is not an excuse for adding more.

 No, but not being a permanent solution is not an excuse for not fixing
 a kernel panic right away.

Right. But we have a fix that doesn't add any additional locking... I
don't see why it can't be taken now, but as I said, I wouldn't resist
staging it for the next cycle.
--
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/5] ASoC: DMIC: Adding the OMAP DMIC driver

[Felipe Balbi]

Hi,

On Mon, Dec 27, 2010 at 10:17:02PM -0600, David Lambert wrote:

This patch adds support for the OMAP4 digital microphone DAI.

This DAI can support support recording in 2, 4, or 6 channels

When provided with a 19.2Mhz functional clock, can encode at 96Khz or
192Khz (all
channels must have the same sample rate).

Details of the hardware interface can be found in the OMAP4 TRM in Section 23.7

Signed-off-by: David Lambert dlamb...@ti.com
---
arch/arm/plat-omap/include/plat/dmic.h |   83 +
sound/soc/omap/omap-dmic.c |  596 
sound/soc/omap/omap-dmic.h |   38 ++
3 files changed, 717 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/dmic.h
create mode 100644 sound/soc/omap/omap-dmic.c
create mode 100644 sound/soc/omap/omap-dmic.h

diff --git a/arch/arm/plat-omap/include/plat/dmic.h 
b/arch/arm/plat-omap/include/plat/dmic.h
new file mode 100644
index 000..8a988bf
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/dmic.h
@@ -0,0 +1,83 @@
+/*
+ * omap-dmic.h  --  OMAP Digital Microphone Controller
+ *
+ * Author: Liam Girdwood l...@slimlogic.co.uk
+ *David Lambert dlamb...@ti.com
+ *Misael Lopez Cruz misael.lo...@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.
+ */
+
+#ifndef __ASM_ARCH_OMAP_DMIC_H
+#define __ASM_ARCH_OMAP_DMIC_H
+
+#define OMAP44XX_DMIC_L3_BASE  0x4902e000
+
+#define OMAP_DMIC_REVISION 0x00
+#define OMAP_DMIC_SYSCONFIG0x10
+#define OMAP_DMIC_IRQSTATUS_RAW0x24
+#define OMAP_DMIC_IRQSTATUS0x28
+#define OMAP_DMIC_IRQENABLE_SET0x2C
+#define OMAP_DMIC_IRQENABLE_CLR0x30
+#define OMAP_DMIC_IRQWAKE_EN   0x34
+#define OMAP_DMIC_DMAENABLE_SET0x38
+#define OMAP_DMIC_DMAENABLE_CLR0x3C
+#define OMAP_DMIC_DMAWAKEEN0x40
+#define OMAP_DMIC_CTRL 0x44
+#define OMAP_DMIC_DATA 0x48
+#define OMAP_DMIC_FIFO_CTRL0x4C
+#define OMAP_DMIC_FIFO_DMIC1R_DATA 0x50
+#define OMAP_DMIC_FIFO_DMIC1L_DATA 0x54
+#define OMAP_DMIC_FIFO_DMIC2R_DATA 0x58
+#define OMAP_DMIC_FIFO_DMIC2L_DATA 0x5C
+#define OMAP_DMIC_FIFO_DMIC3R_DATA 0x60
+#define OMAP_DMIC_FIFO_DMIC3L_DATA 0x64
+
+/*
+ * DMIC_IRQ bit fields
+ * IRQSTATUS_RAW, IRQSTATUS, IRQENABLE_SET, IRQENABLE_CLR
+ */
+
+#define OMAP_DMIC_IRQ  (1  0)
+#define OMAP_DMIC_IRQ_FULL (1  1)
+#define OMAP_DMIC_IRQ_ALMST_EMPTY  (1  2)
+#define OMAP_DMIC_IRQ_EMPTY(1  3)
+#define OMAP_DMIC_IRQ_MASK 0x07
+
+/*
+ * DMIC_DMAENABLE bit fields
+ */
+
+#define OMAP_DMIC_DMA_ENABLE   0x1
+
+/*
+ * DMIC_CTRL bit fields
+ */
+
+#define OMAP_DMIC_UP1_ENABLE   0x0001
+#define OMAP_DMIC_UP2_ENABLE   0x0002
+#define OMAP_DMIC_UP3_ENABLE   0x0004
+#define OMAP_DMIC_FORMAT   0x0008
+#define OMAP_DMIC_POLAR1   0x0010
+#define OMAP_DMIC_POLAR2   0x0020
+#define OMAP_DMIC_POLAR3   0x0040
+#define OMAP_DMIC_POLAR_MASK   0x0070
+#define OMAP_DMIC_CLK_DIV_SHIFT7
+#define OMAP_DMIC_CLK_DIV_MASK 0x0380
+#defineOMAP_DMIC_RESET 0x0400
+
+#define OMAP_DMIC_ENABLE_MASK  0x007
+
+#define OMAP_DMICOUTFORMAT_LJUST   (0  3)
+#define OMAP_DMICOUTFORMAT_RJUST   (1  3)
+
+/*
+ * DMIC_FIFO_CTRL bit fields
+ */
+
+#define OMAP_DMIC_THRES_MAX0xF
+
+


one blank line only. BTW, are these used anywwhere outside the dmic.c
driver ? If not, it's better to move the definitions there.


+#endif
diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
new file mode 100644
index 000..6ba05bd
--- /dev/null
+++ b/sound/soc/omap/omap-dmic.c
@@ -0,0 +1,596 @@
+/*
+ * omap-dmic.c  --  OMAP ASoC DMIC DAI driver
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * Author: Liam Girdwood l...@slimlogic.co.uk
+ *David Lambert dlamb...@ti.com
+ *Misael Lopez Cruz misael.lo...@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.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#undef DEBUG
+
+#include linux/init.h
+#include linux/module.h
+#include 

Re: [PATCH 5/5] MAP4: DMIC: Add DMIC codec platform devices

[Felipe Balbi]

Hi,

$SUBJECT should read OMAP4 instead of MAP4

On Mon, Dec 27, 2010 at 10:17:06PM -0600, David Lambert wrote:

This creates the DMIC codec platform devices.

The platform devices create an instance of the driver during boot up.

Signed-off-by: David Lambert dlamb...@ti.com


is this a virtual device ? If not, where's HWMOD for it ?


diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index df5a425..bf271e5 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -505,6 +505,16 @@ static void __init omap_sfh7741prox_init(void)
}
}

+static struct platform_device codec_dmic0 = {
+   .name   = dmic-codec,
+   .id = 0,


if this is the only device, should id be -1 instead ?


+};
+
+static inline void omap_dmic_init(void)
+{
+   platform_device_register(codec_dmic0);


Another option would be to use
platform_device_register_simple(dmi-codec, -1);

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

Re: [PATCH 3/5] ASoC: DMIC: Adding OMAP DMIC driver to build

[Mark Brown]

On Mon, Dec 27, 2010 at 10:17:04PM -0600, David Lambert wrote:
 Adds the OMAP DMIC driver and codec to the build.
 
 Signed-off-by: David Lambert dlamb...@ti.com
 ---
  sound/soc/codecs/Kconfig  |3 +++
  sound/soc/codecs/Makefile |2 ++
  sound/soc/omap/Kconfig|5 +
  sound/soc/omap/Makefile   |2 ++

This should be one of the last patches in the series, but given the sort
of drivers you're introducing I'd expect the drivers to just directly
add the build system stuff in the patch.

  4 files changed, 12 insertions(+), 0 deletions(-)
 
 diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
 index 0f33db2..f6c6d31 100644
 --- a/sound/soc/codecs/Kconfig
 +++ b/sound/soc/codecs/Kconfig
 @@ -166,6 +166,9 @@ config SND_SOC_L3
  config SND_SOC_DA7210
  tristate
  
 +config SND_SOC_DMIC
 + tristate
 +
  config SND_SOC_MAX98088
 tristate
  
 diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
 index 10e5e09..9139cf9 100644
 --- a/sound/soc/codecs/Makefile
 +++ b/sound/soc/codecs/Makefile
 @@ -14,6 +14,7 @@ snd-soc-cs42l51-objs := cs42l51.o
  snd-soc-cs4270-objs := cs4270.o
  snd-soc-cx20442-objs := cx20442.o
  snd-soc-da7210-objs := da7210.o
 +snd-soc-dmic-objs := dmic.o
  snd-soc-l3-objs := l3.o
  snd-soc-max98088-objs := max98088.o
  snd-soc-pcm3008-objs := pcm3008.o
 @@ -91,6 +92,7 @@ obj-$(CONFIG_SND_SOC_CS42L51)   += snd-soc-cs42l51.o
  obj-$(CONFIG_SND_SOC_CS4270) += snd-soc-cs4270.o
  obj-$(CONFIG_SND_SOC_CX20442)+= snd-soc-cx20442.o
  obj-$(CONFIG_SND_SOC_DA7210) += snd-soc-da7210.o
 +obj-$(CONFIG_SND_SOC_DMIC)   += snd-soc-dmic.o
  obj-$(CONFIG_SND_SOC_L3) += snd-soc-l3.o
  obj-$(CONFIG_SND_SOC_JZ4740_CODEC)   += snd-soc-jz4740-codec.o
  obj-$(CONFIG_SND_SOC_MAX98088)   += snd-soc-max98088.o
 diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
 index a088db6..548b13c 100644
 --- a/sound/soc/omap/Kconfig
 +++ b/sound/soc/omap/Kconfig
 @@ -9,6 +9,9 @@ config SND_OMAP_SOC_MCBSP
  config SND_OMAP_SOC_MCPDM
   tristate
  
 +config SND_OMAP_SOC_DMIC
 + tristate
 +
  config SND_OMAP_SOC_N810
   tristate SoC Audio support for Nokia N810
   depends on SND_OMAP_SOC  MACH_NOKIA_N810  I2C
 @@ -103,6 +106,8 @@ config SND_OMAP_SOC_SDP4430
   depends on TWL4030_CORE  SND_OMAP_SOC  MACH_OMAP_4430SDP
   select SND_OMAP_SOC_MCPDM
   select SND_SOC_TWL6040
 + select SND_SOC_DMIC
 + select SND_OMAP_SOC_DMIC
   help
 Say Y if you want to add support for SoC audio on Texas Instruments
 SDP4430.
 diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
 index ba9fc65..6ff27f5 100644
 --- a/sound/soc/omap/Makefile
 +++ b/sound/soc/omap/Makefile
 @@ -1,9 +1,11 @@
  # OMAP Platform Support
  snd-soc-omap-objs := omap-pcm.o
 +snd-soc-omap-dmic-objs := omap-dmic.o
  snd-soc-omap-mcbsp-objs := omap-mcbsp.o
  snd-soc-omap-mcpdm-objs := omap-mcpdm.o mcpdm.o
  
  obj-$(CONFIG_SND_OMAP_SOC) += snd-soc-omap.o
 +obj-$(CONFIG_SND_OMAP_SOC_DMIC) += snd-soc-omap-dmic.o
  obj-$(CONFIG_SND_OMAP_SOC_MCBSP) += snd-soc-omap-mcbsp.o
  obj-$(CONFIG_SND_OMAP_SOC_MCPDM) += snd-soc-omap-mcpdm.o
  
 -- 
 1.7.0.4
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] staging: tidspbridge: protect dmm_map properly

[Felipe Contreras]

On Tue, Dec 28, 2010 at 12:56 PM, Ohad Ben-Cohen o...@wizery.com wrote:
 On Tue, Dec 28, 2010 at 12:36 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 You can never really tell who is using the kernel (or will be using
 this kernel version), how and under which workload.

 No, but it's better to address real issues rather than hypothetical.

 Right. and both patches do that. one adds locks, and one doesn't.

 However, as I sad, everybody is using proc_map() and proc_un_map()
 which take a lock, and there are no complaints.

 I didn't complain about that; I didn't like you adding locks to the DMA API.

 Ok, can I get your Ack?

 Frankly, I don't like the locks you are adding. But as I said, I
 wouldn't resist them as long as it's temporary.

 Then why did you add that check for is_map_obj_used(), and then return
 -EBUSY? If that can happen, then it can happen when the application is
 crashing; user-space crashes while kernel-space is in the middle of a
 proc_*_dma() operation.

 I still don't know how exactly you triggered the bug: is gst-dsp
 multithreaded ? and one of its threads invoked proc_un_map() while
 another thread called proc_begin_dma() ?

I haven't investigated why that happens, but kernel-space should not
panic regardless of what user-space does.

 Anyhow, a thread that is calling proc_*_dma() will both increase the
 reference count and decrease it back before going back to user space.
 Otherwise your patch would be problematic as well - who will unlock
 the mutex you take in proc_*_dma() ?

I'm saying that user-space might crash *before* proc_*_dma() finishes,
before the reference count has been decreased.

In my patch there would be no issue because proc_un_map() would wait
until proc_*_dma() has released the lock.

 Sure, but I see this as a broader effort to have finer locking, part of
 this should be to remove the already existing proc_lock.

 Having bad locking is not an excuse for adding more.

 No, but not being a permanent solution is not an excuse for not fixing
 a kernel panic right away.

 Right. But we have a fix that doesn't add any additional locking... I
 don't see why it can't be taken now, but as I said, I wouldn't resist
 staging it for the next cycle.

Because:
 1) Your patch changes 114 lines, mine 18
 2) It hasn't been reviewed, nor tested by other people
 3) At least I see a potential issue
 4) 2.6.37 is imminent

IMO one patch has chances going into 2.6.37, the other one doesn't. I
don't see the problem of pushing my patch to 2.6.37, and once your
patch has been properly reviewed, and tested, put it for the 2.6.38
merge window. Anyway, it's looking more and more that this patch would
not be ack'ed in time, so I guess we would have to wait to see what
other people (Omar?) say, which would probably be 2.6.38 timeline.

Cheers.

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

Re: [PATCH v2] staging: tidspbridge: protect dmm_map properly

[Ohad Ben-Cohen]

On Tue, Dec 28, 2010 at 2:12 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 I haven't investigated why that happens, but kernel-space should not
 panic regardless of what user-space does.

Agree of course. But that's not what we were discussing...

 Anyhow, a thread that is calling proc_*_dma() will both increase the
 reference count and decrease it back before going back to user space.
 Otherwise your patch would be problematic as well - who will unlock
 the mutex you take in proc_*_dma() ?

 I'm saying that user-space might crash *before* proc_*_dma() finishes,
 before the reference count has been decreased.

 In my patch there would be no issue because proc_un_map() would wait
 until proc_*_dma() has released the lock.

But what will happen if, as you say, user-space would crash before
proc_*_dma() has released the lock ? how could proc_un_map() run ?

 Because:
  1) Your patch changes 114 lines, mine 18
  2) It hasn't been reviewed, nor tested by other people
  3) At least I see a potential issue
  4) 2.6.37 is imminent

 IMO one patch has chances going into 2.6.37, the other one doesn't. I
 don't see the problem of pushing my patch to 2.6.37, and once your
 patch has been properly reviewed, and tested, put it for the 2.6.38
 merge window. Anyway, it's looking more and more that this patch would
 not be ack'ed in time, so I guess we would have to wait to see what
 other people (Omar?) say, which would probably be 2.6.38 timeline.

This is all good, and I have no problem with it. As I said, I don't
resist your patch as a temporary fix. But it doesn't mean I like it...
--
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] staging: tidspbridge: protect dmm_map properly

[Felipe Contreras]

On Tue, Dec 28, 2010 at 2:18 PM, Ohad Ben-Cohen o...@wizery.com wrote:
 On Tue, Dec 28, 2010 at 2:12 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 I haven't investigated why that happens, but kernel-space should not
 panic regardless of what user-space does.

 Agree of course. But that's not what we were discussing...

Well, hopefully after applying your patch it would be easier to figure that out.

 Anyhow, a thread that is calling proc_*_dma() will both increase the
 reference count and decrease it back before going back to user space.
 Otherwise your patch would be problematic as well - who will unlock
 the mutex you take in proc_*_dma() ?

 I'm saying that user-space might crash *before* proc_*_dma() finishes,
 before the reference count has been decreased.

 In my patch there would be no issue because proc_un_map() would wait
 until proc_*_dma() has released the lock.

 But what will happen if, as you say, user-space would crash before
 proc_*_dma() has released the lock ? how could proc_un_map() run ?

user-space crashed, not kernel-space; the code would continue to run
and eventually release the lock.

 This is all good, and I have no problem with it. As I said, I don't
 resist your patch as a temporary fix. But it doesn't mean I like it...

Yeah, so the chances of getting this fixed on 2.6.37 are dimmed.

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

Re: [PATCH v2] staging: tidspbridge: protect dmm_map properly

[Ohad Ben-Cohen]

On Tue, Dec 28, 2010 at 2:24 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 user-space crashed, not kernel-space; the code would continue to run
 and eventually release the lock.

So you'll have to be more specific about the scenario you are describing.

If there's a user thread that is still running the proc_*_dma()
function, and we agree that this thread keeps running until completion
and then returns to user space, what's the problem ?

If that user thread will crash, drv_remove_all_resources() will clean
up all map_obj's.

 Yeah, so the chances of getting this fixed on 2.6.37 are dimmed.

I wouldn't worry about that.. In the worst case, Cc:
sta...@kernel.org will push the fix into 2.6.37.x..
--
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 0/2] Move twl*-irq.c to threaded_irq infrastructure

[Felipe Balbi]

Hi all,

This is truly untested. I only compile tested thus far
as I'm not sure it's the right path. It looks like that's
what's supposed to be done, but I wanted to check with you
guys before going any further.

In a few minutes, I'll be starting to test these two
patches and will try to find any possible errors with them
but, please, give it a good review as IMO it's a rather
invasive change.

Thomas, I've got one extra question for you. I remember
reading you suggested all drivers should actually try
to use threaded IRQ infrastructure for handling the IRQ
and the hardirq handler would only check if the IRQ
is coming from this device. Is that how you expect
theaded IRQ to be used ? What's the purpose ?

Please, correct me if I'm wrong, but I came to the
conclusion that threaded IRQs can be reniced and
preempted which would mean we could be setting IRQ
priorities from userland and we could also be running
N IRQ threads if we have N cpu cores. Is that correct ?
Is that your goal ?

I tried searching for some more documentation on
the threaded IRQ infrastructure but couldn't find
much by grepping Documentation/ maybe my match string
wasn't good enough. Anyway, let me know what are your
feeling about the following two patches and what would
be your goal should we move all IRQ handlers to threaded
IRQ infrastructure as I remember you suggested.

Happy new year all.

Felipe Balbi (2):
  mfd: twl6030-irq: move to threaded_irq
  mfd: twl4030-irq: move to threaded_irq

 drivers/mfd/twl4030-irq.c |  133 +-
 drivers/mfd/twl6030-irq.c |  141 -
 2 files changed, 91 insertions(+), 183 deletions(-)

-- 
1.7.3.4.598.g85356

--
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 2/2] mfd: twl4030-irq: move to threaded_irq

[Felipe Balbi]

... and while at that, also start using
handle_nested_irq() as we should.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/mfd/twl4030-irq.c |  133 ++---
 1 files changed, 42 insertions(+), 91 deletions(-)

diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
index 5d3a147..e88d0c6 100644
--- a/drivers/mfd/twl4030-irq.c
+++ b/drivers/mfd/twl4030-irq.c
@@ -278,91 +278,56 @@ static const struct sih sih_modules_twl5031[8] = {
 
 static unsigned twl4030_irq_base;
 
-static struct completion irq_event;
-
 /*
  * This thread processes interrupts reported by the Primary Interrupt Handler.
  */
-static int twl4030_irq_thread(void *data)
+static irqreturn_t twl4030_irq_thread(int irq, void *unused)
 {
-   long irq = (long)data;
-   static unsigned i2c_errors;
-   static const unsigned max_i2c_errors = 100;
-
-
-   current-flags |= PF_NOFREEZE;
-
-   while (!kthread_should_stop()) {
-   int ret;
-   int module_irq;
-   u8 pih_isr;
-
-   /* Wait for IRQ, then read PIH irq status (also blocking) */
-   wait_for_completion_interruptible(irq_event);
-
-   ret = twl_i2c_read_u8(TWL4030_MODULE_PIH, pih_isr,
- REG_PIH_ISR_P1);
-   if (ret) {
-   pr_warning(twl4030: I2C error %d reading PIH ISR\n,
-   ret);
-   if (++i2c_errors = max_i2c_errors) {
-   printk(KERN_ERR Maximum I2C error count
-exceeded.  Terminating %s.\n,
-   __func__);
-   break;
-   }
-   complete(irq_event);
-   continue;
-   }
+   int ret;
+   int module_irq;
+   u8 pih_isr;
 
-   /* these handlers deal with the relevant SIH irq status */
-   local_irq_disable();
-   for (module_irq = twl4030_irq_base;
-   pih_isr;
-   pih_isr = 1, module_irq++) {
-   if (pih_isr  0x1) {
-   struct irq_desc *d = irq_to_desc(module_irq);
-
-   if (!d) {
-   pr_err(twl4030: Invalid SIH IRQ: %d\n,
-  module_irq);
-   return -EINVAL;
-   }
-
-   /* These can't be masked ... always warn
-* if we get any surprises.
-*/
-   if (d-status  IRQ_DISABLED)
-   note_interrupt(module_irq, d,
-   IRQ_NONE);
-   else
-   d-handle_irq(module_irq, d);
+   disable_irq_nosync(irq);
+
+   ret = twl_i2c_read_u8(TWL4030_MODULE_PIH, pih_isr,
+   REG_PIH_ISR_P1);
+   if (ret) {
+   pr_warning(twl4030: I2C error %d reading PIH ISR\n,
+   ret);
+   return IRQ_NONE;
+   }
+
+   /* these handlers deal with the relevant SIH irq status */
+   local_irq_disable();
+   for (module_irq = twl4030_irq_base;
+   pih_isr;
+   pih_isr = 1, module_irq++) {
+   if (pih_isr  0x1) {
+   struct irq_desc *d = irq_to_desc(module_irq);
+
+   if (!d) {
+   pr_err(twl4030: Invalid SIH IRQ: %d\n,
+   module_irq);
+   return IRQ_NONE;
}
-   }
-   local_irq_enable();
 
-   enable_irq(irq);
+   /* These can't be masked ... always warn
+* if we get any surprises.
+*/
+   if (d-status  IRQ_DISABLED)
+   note_interrupt(module_irq, d,
+   IRQ_NONE);
+   else
+   handle_nested_irq(module_irq);
+   }
}
 
+   local_irq_enable();
+   enable_irq(irq);
+
return 0;
 }
 
-/*
- * handle_twl4030_pih() is the desc-handle method for the twl4030 interrupt.
- * This is a chained interrupt, so there is no desc-action method for it.
- * Now we need to query the interrupt controller in the twl4030 to determine
- * which module is generating the interrupt request.  However, we can't do i2c
- * transactions in interrupt context, so we must defer that work to a kernel
- * thread.  All 

[RFC/PATCH 1/2] mfd: twl6030-irq: move to threaded_irq

[Felipe Balbi]

... and while at that, also start using
handle_nested_irq() as we should.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/mfd/twl6030-irq.c |  141 -
 1 files changed, 49 insertions(+), 92 deletions(-)

diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index aaedb11..1530411 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -84,99 +84,64 @@ static int twl6030_interrupt_mapping[24] = {
 
 static unsigned twl6030_irq_base;
 
-static struct completion irq_event;
-
 /*
  * This thread processes interrupts reported by the Primary Interrupt Handler.
  */
-static int twl6030_irq_thread(void *data)
+static irqreturn_t twl6030_irq_thread(int irq, void *unused)
 {
-   long irq = (long)data;
-   static unsigned i2c_errors;
-   static const unsigned max_i2c_errors = 100;
int ret;
-
-   current-flags |= PF_NOFREEZE;
-
-   while (!kthread_should_stop()) {
-   int i;
-   union {
+   int i;
+   union {
u8 bytes[4];
u32 int_sts;
-   } sts;
-
-   /* Wait for IRQ, then read PIH irq status (also blocking) */
-   wait_for_completion_interruptible(irq_event);
-
-   /* read INT_STS_A, B and C in one shot using a burst read */
-   ret = twl_i2c_read(TWL_MODULE_PIH, sts.bytes,
-   REG_INT_STS_A, 3);
-   if (ret) {
-   pr_warning(twl6030: I2C error %d reading PIH ISR\n,
-   ret);
-   if (++i2c_errors = max_i2c_errors) {
-   printk(KERN_ERR Maximum I2C error count
-exceeded.  Terminating %s.\n,
-   __func__);
-   break;
-   }
-   complete(irq_event);
-   continue;
-   }
-
+   } sts;
 
+   disable_irq_nosync(irq);
 
-   sts.bytes[3] = 0; /* Only 24 bits are valid*/
+   /* read INT_STS_A, B and C in one shot using a burst read */
+   ret = twl_i2c_read(TWL_MODULE_PIH, sts.bytes,
+   REG_INT_STS_A, 3);
+   if (ret) {
+   pr_warning(twl6030: I2C error %d reading PIH ISR\n,
+   ret);
+   return IRQ_NONE;
+   }
 
-   for (i = 0; sts.int_sts; sts.int_sts = 1, i++) {
-   local_irq_disable();
-   if (sts.int_sts  0x1) {
-   int module_irq = twl6030_irq_base +
-   twl6030_interrupt_mapping[i];
-   struct irq_desc *d = irq_to_desc(module_irq);
 
-   if (!d) {
-   pr_err(twl6030: Invalid SIH IRQ: %d\n,
-  module_irq);
-   return -EINVAL;
-   }
+   sts.bytes[3] = 0; /* Only 24 bits are valid*/
 
-   /* These can't be masked ... always warn
-* if we get any surprises.
-*/
-   if (d-status  IRQ_DISABLED)
-   note_interrupt(module_irq, d,
-   IRQ_NONE);
-   else
-   d-handle_irq(module_irq, d);
+   for (i = 0; sts.int_sts; sts.int_sts = 1, i++) {
+   local_irq_disable();
+   if (sts.int_sts  0x1) {
+   int module_irq = twl6030_irq_base +
+   twl6030_interrupt_mapping[i];
+   struct irq_desc *d = irq_to_desc(module_irq);
 
+   if (!d) {
+   pr_err(twl6030: Invalid SIH IRQ: %d\n,
+   module_irq);
+   return IRQ_NONE;
}
-   local_irq_enable();
-   }
-   ret = twl_i2c_write(TWL_MODULE_PIH, sts.bytes,
-   REG_INT_STS_A, 3); /* clear INT_STS_A */
-   if (ret)
-   pr_warning(twl6030: I2C error in clearing PIH ISR\n);
 
-   enable_irq(irq);
+   /* These can't be masked ... always warn
+* if we get any surprises.
+*/
+   if (d-status  IRQ_DISABLED)
+   note_interrupt(module_irq, d,
+   IRQ_NONE);
+   else
+   handle_nested_irq(module_irq);
+
+   

Re: [PATCH 1/5] ASoC: DMIC: Adding the OMAP DMIC driver

[Mark Brown]

On Mon, Dec 27, 2010 at 10:17:02PM -0600, David Lambert wrote:

 + case 1920:
 + if (div == 5)
 + div_sel = 0x1;
 + else if (div == 8)
 + div_sel = 0x0;
 + break;

A switch statement for the valid div values would feel more natural,
together with a default case to report errors though that's handled
below so could be skipped.

 + /* Acknowledge irq event */
 + omap_dmic_write(dmic, OMAP_DMIC_IRQSTATUS, irq_status);
 + if (irq_status  OMAP_DMIC_IRQ_FULL)

Blank line between these two.

 + dev_dbg(dmic-dev, DMIC FIFO error %x\n, irq_status);
 +
 + if (irq_status  OMAP_DMIC_IRQ_EMPTY)
 + dev_dbg(dmic-dev, DMIC FIFO error %x\n, irq_status);

I'd expect these errors to be displayed by default.

 + if (irq_status  OMAP_DMIC_IRQ)
 + dev_dbg(dmic-dev, DMIC write request\n);

A comment explaining why we don't actually do anything with the request
would be helpful.  Given that we're ignoring the event it'd seem better
to just leave it masked and not take the interrupt in the first place.

 +static int omap_dmic_dai_startup(struct snd_pcm_substream *substream,
 +   struct snd_soc_dai *dai)
 +{
 + struct omap_dmic *dmic = snd_soc_dai_get_drvdata(dai);
 +
 + if (!dmic-active++)
 + pm_runtime_get_sync(dmic-dev);

The pm_runtime API does refcounting for you so you should be able to
just skip the active count check here, IIRC there's a pm_runtime API you
could use to query if the DMIC is enabled so you could skip the local
refcount entirely.

 +static int omap_dmic_dai_hw_free(struct snd_pcm_substream *substream,
 +   struct snd_soc_dai *dai)
 +{
 + struct omap_dmic *dmic = snd_soc_dai_get_drvdata(dai);
 + struct omap_dmic_link *link = dmic-link;
 + int ret = 0;
 +
 + if (dmic-active == 1) {
 + ret = omap_dmic_close(dmic);
 + link-channels = 0;
 + }

I'd feel a bit more happy if this were done in the same place as the
drop of the refcount though this should actually be OK I think.

 + switch (freq) {
 + case 1920:
 + case 2400:
 + case 24576000:
 + case 1200:
 + dmic-clk_freq = freq;
 + break;
 + default:
 + dev_err(dai-dev, clk freq not supported %d\n, freq);
 + ret = -EINVAL;
 + goto err_freq;
 + }

Can't you ask the parent clock what rate it's set to?

 + ret = request_threaded_irq(dmic-irq, NULL, omap_dmic_irq_handler,
 +IRQF_ONESHOT, DMIC, (void *)dmic);
 + if (ret) {
 + dev_err(dmic-dev, irq request failed\n);
 + goto err_irq;
 + }

Does this really need to be a threaded IRQ - the IRQ was just reading
from CPU registers as far as I remember?

 +MODULE_AUTHOR(David Lambert dlamb...@ti.com);
 +MODULE_DESCRIPTION(OMAP DMIC SoC Interface);
 +MODULE_LICENSE(GPL);

Should have a MODULE_ALIAS too in case it gets built modular.
--
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/5] ASoC: DMIC codec: Adding a generic DMIC codec

[Mark Brown]

On Mon, Dec 27, 2010 at 10:17:03PM -0600, David Lambert wrote:

 At this time, the codec driver just registers the codec DAI.

If it's doing more than that it's going to be a separate driver anyway I
expect.

 +static struct snd_soc_dai_driver dmic_dai = {
 + .name = dmic-hifi,
 + .capture = {
 + .stream_name = Capture,
 + .channels_min = 1,
 + .channels_max = 8,
 + .rates = SNDRV_PCM_RATE_CONTINUOUS,
 + .formats = SNDRV_PCM_FMTBIT_S32_LE
 + | SNDRV_PCM_FMTBIT_S24_LE
 + | SNDRV_PCM_FMTBIT_S16_LE,

Hrm, so.  DMIC signals are inherantly stereo, though obviously you can
bind multiple DMICs in parallel using the same clock line so from the
CPU side the channel limit makes sense.  Similarly the format here
really makes very little odds on a PDM interface.

What we probably want here is wildcards for both channel and format
limits which we can use to say this is meaningless, just match
anything in case the other end needs it (like a CPU PDM interface does
to set up the DMA).

 +static struct platform_driver dmic_driver = {
 + .driver = {
 + .name = dmic-codec,

Just -dmic.

 +MODULE_DESCRIPTION(Generic DMIC driver);
 +MODULE_AUTHOR(Liam Girdwood l...@slimlogic.co.uk);
 +MODULE_LICENSE(GPL);

MODULE_ALIAS().
--
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] staging: tidspbridge: protect dmm_map properly

[Ohad Ben-Cohen]

On Tue, Dec 28, 2010 at 2:12 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 On Tue, Dec 28, 2010 at 12:56 PM, Ohad Ben-Cohen o...@wizery.com wrote:
 I still don't know how exactly you triggered the bug: is gst-dsp
 multithreaded ? and one of its threads invoked proc_un_map() while
 another thread called proc_begin_dma() ?

 I haven't investigated why that happens

Btw, I still think you should look into this.

The kernel panic will be solved, but you may still have a race there
that can lead to data corruption: if proc_un_map will be fast enough,
it will acquire the proc_lock mutex before proc_begin_dma(), and then
you will miss a cache operation.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 1/2] mfd: twl6030-irq: move to threaded_irq

[Mark Brown]

On Tue, Dec 28, 2010 at 03:59:49PM +0200, Felipe Balbi wrote:

 + disable_irq_nosync(irq);

You shouldn't need this any more; the driver used to be faffing around
with this because it wasn't using genirq for this in the past.

 + for (i = 0; sts.int_sts; sts.int_sts = 1, i++) {
 + local_irq_disable();

Simiarly here as far as I know; the original code predates genirq
support for this so is doing some hairy stuff that is no longer
required and may actually be harmful.

What I'd expect to see from a conversion like this would be that most of
the locking/IRQ management stuff would be dropped and the bus_lock() and
bus_sync_unlock() operations would be implemented.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 1/2] mfd: twl6030-irq: move to threaded_irq

[Felipe Balbi]

Hi,

On Tue, Dec 28, 2010 at 03:46:17PM +, Mark Brown wrote:

On Tue, Dec 28, 2010 at 03:59:49PM +0200, Felipe Balbi wrote:


+   disable_irq_nosync(irq);


You shouldn't need this any more; the driver used to be faffing around
with this because it wasn't using genirq for this in the past.


+   for (i = 0; sts.int_sts; sts.int_sts = 1, i++) {
+   local_irq_disable();


Simiarly here as far as I know; the original code predates genirq
support for this so is doing some hairy stuff that is no longer
required and may actually be harmful.


Aa, true. Forgot that one.


What I'd expect to see from a conversion like this would be that most of
the locking/IRQ management stuff would be dropped and the bus_lock() and
bus_sync_unlock() operations would be implemented.


I'll look into it, thanks.

--
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 v6 01/10] OMAP3: PM: Adding voltage driver support.

[Anand Sawant]

Thara,

Here are some comments on the voltage layer; many of them are
cosmetic in nature.

 -Original Message-
 From: Thara Gopinath [mailto:th...@ti.com]
 Sent: Monday, December 20, 2010 10:29 PM
 To: linux-omap@vger.kernel.org; linux-arm-
 ker...@lists.infradead.org
 Cc: khil...@deeprootsystems.com; p...@pwsan.com; b-
 cous...@ti.com; vishwanath...@ti.com; saw...@ti.com;
 n...@ti.com; Thara Gopinath
 Subject: [PATCH v6 01/10] OMAP3: PM: Adding voltage driver
 support.

 This patch adds voltage driver support for OMAP3. The driver
 allows  configuring the voltage controller and voltage
 processors during init and exports APIs to enable/disable
 voltage processors, scale voltage and reset voltage.
 The driver maintains the global voltage table on a per
 VDD basis which contains the various voltages supported by
 the
 VDD along with per voltage dependent data like smartreflex
 efuse offset, errminlimit and voltage processor errorgain.
 The driver also allows the voltage parameters dependent on
 the
 PMIC to be passed from the PMIC file through an API.
 The driver allows scaling of VDD voltages either through
 vc bypass method or through vp forceupdate method the
 choice being configurable through the board file.

 This patch contains code originally in linux omap pm branch
 smartreflex driver.  Major contributors to this driver are
 Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
 Nishant Menon, Kevin Hilman. The separation of PMIC
 parameters
 into a separate structure which can be populated from
 the PMIC file is based on the work of Lun Chang from
 Motorola
 in an internal tree.

 Signed-off-by: Thara Gopinath th...@ti.com
 ---
 This patch has 14 checkpatch.pl above 80-chars warnings for
 the definitions of omap34xx_vddmpu_volt_data,
 omap36xx_vddmpu_volt_data,
 omap34xx_vddcore_volt_data and omap36xx_vddcore_volt_data
 structures.
 IMHO splitting of the entries in these structures affects
 readability and looks very ugly. Hence they are left as is.

  arch/arm/mach-omap2/Makefile  |3 +-
  arch/arm/mach-omap2/control.h |   17 +
  arch/arm/mach-omap2/pm.c  |8 +
  arch/arm/mach-omap2/voltage.c | 1226
 +
  arch/arm/plat-omap/include/plat/voltage.h |  134 
  5 files changed, 1387 insertions(+), 1 deletions(-)
  create mode 100644 arch/arm/mach-omap2/voltage.c
  create mode 100644 arch/arm/plat-
 omap/include/plat/voltage.h

 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-
 omap2/Makefile
 index 7c79683..5034797 100644
 --- a/arch/arm/mach-omap2/Makefile
 +++ b/arch/arm/mach-omap2/Makefile
 @@ -57,7 +57,8 @@ endif
  ifeq ($(CONFIG_PM),y)
  obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
  obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o pm_bus.o
 -obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
 cpuidle34xx.o pm_bus.o
 +obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
 voltage.o \
 +cpuidle34xx.o pm_bus.o
  obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o pm_bus.o
  obj-$(CONFIG_PM_DEBUG)   += pm-debug.o

 diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-
 omap2/control.h
 index 5289461..9fe32dc 100644
 --- a/arch/arm/mach-omap2/control.h
 +++ b/arch/arm/mach-omap2/control.h
 @@ -148,6 +148,15 @@
  #define OMAP343X_CONTROL_TEST_KEY_11
   (OMAP2_CONTROL_GENERAL + 0x00f4)
  #define OMAP343X_CONTROL_TEST_KEY_12
   (OMAP2_CONTROL_GENERAL + 0x00f8)
  #define OMAP343X_CONTROL_TEST_KEY_13
   (OMAP2_CONTROL_GENERAL + 0x00fc)
 +#define OMAP343X_CONTROL_FUSE_OPP1_VDD1
 (OMAP2_CONTROL_GENERAL + 0x0110)
 +#define OMAP343X_CONTROL_FUSE_OPP2_VDD1
 (OMAP2_CONTROL_GENERAL + 0x0114)
 +#define OMAP343X_CONTROL_FUSE_OPP3_VDD1
 (OMAP2_CONTROL_GENERAL + 0x0118)
 +#define OMAP343X_CONTROL_FUSE_OPP4_VDD1
 (OMAP2_CONTROL_GENERAL + 0x011c)
 +#define OMAP343X_CONTROL_FUSE_OPP5_VDD1
 (OMAP2_CONTROL_GENERAL + 0x0120)
 +#define OMAP343X_CONTROL_FUSE_OPP1_VDD2
 (OMAP2_CONTROL_GENERAL + 0x0124)
 +#define OMAP343X_CONTROL_FUSE_OPP2_VDD2
 (OMAP2_CONTROL_GENERAL + 0x0128)
 +#define OMAP343X_CONTROL_FUSE_OPP3_VDD2
 (OMAP2_CONTROL_GENERAL + 0x012c)
 +#define OMAP343X_CONTROL_FUSE_SR
 (OMAP2_CONTROL_GENERAL + 0x0130)
  #define OMAP343X_CONTROL_IVA2_BOOTADDR
   (OMAP2_CONTROL_GENERAL + 0x0190)
  #define OMAP343X_CONTROL_IVA2_BOOTMOD
   (OMAP2_CONTROL_GENERAL + 0x0194)
  #define OMAP343X_CONTROL_DEBOBS(i)   (OMAP2_CONTROL_GENERAL +
 0x01B0 \
 @@ -164,6 +173,14 @@
  #define OMAP343X_CONTROL_SRAMLDO5(OMAP2_CONTROL_GENERAL +
 0x02C0)
  #define OMAP343X_CONTROL_CSI (OMAP2_CONTROL_GENERAL +
 0x02C4)

 +/* OMAP3630 only CONTROL_GENERAL register offsets */
 +#define OMAP3630_CONTROL_FUSE_OPP1G_VDD1
 (OMAP2_CONTROL_GENERAL + 0x0110)
 +#define OMAP3630_CONTROL_FUSE_OPP50_VDD1
 (OMAP2_CONTROL_GENERAL + 0x0114)
 +#define OMAP3630_CONTROL_FUSE_OPP100_VDD1
 (OMAP2_CONTROL_GENERAL + 0x0118)
 +#define 

RE: [PATCH v6 09/10] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers

[Anand Sawant]

Thara,

Few comments on the changes in voltage layer ...

 -Original Message-
 From: Thara Gopinath [mailto:th...@ti.com]
 Sent: Monday, December 20, 2010 10:29 PM
 To: linux-omap@vger.kernel.org; linux-arm-
 ker...@lists.infradead.org
 Cc: khil...@deeprootsystems.com; p...@pwsan.com; b-
 cous...@ti.com; vishwanath...@ti.com; saw...@ti.com;
 n...@ti.com; Thara Gopinath
 Subject: [PATCH v6 09/10] OMAP3: PM: Adding debug support to
 Voltage and Smartreflex drivers

 This patch adds debug support to the voltage and smartreflex
 drivers.
 This means a whole bunch of voltage processor and
 smartreflex
 parameters are now visible through the pm debugfs.
 The voltage parameters can be viewed at
 /debug/voltage/vdd_x/parameter
 and the smartreflex parameters can be viewed at
 /debug/voltage/vdd_x/smartreflex/parameter

 Also smartreflex n-target values are now exposed out at
   /debug/voltage/vdd_x/smartreflex/nvalue/voltage

 The interface to access smartreflex n-target values is a
 read-write interface which means user has the flexibility
 to change the n-target values for any opp.

 Signed-off-by: Thara Gopinath th...@ti.com
 ---
  arch/arm/mach-omap2/smartreflex.c |   46
 -
  arch/arm/mach-omap2/voltage.c |   66
 +
  2 files changed, 110 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/mach-omap2/smartreflex.c
 b/arch/arm/mach-omap2/smartreflex.c
 index eee23d0..52a05b3 100644
 --- a/arch/arm/mach-omap2/smartreflex.c
 +++ b/arch/arm/mach-omap2/smartreflex.c
 @@ -31,6 +31,7 @@
  #include pm.h

  #define SMARTREFLEX_NAME_LEN 16
 +#define NVALUE_NAME_LEN  40
  #define SR_DISABLE_TIMEOUT   200

  struct omap_sr {
 @@ -817,8 +818,9 @@ static int __init omap_sr_probe(struct
 platform_device *pdev)
   struct omap_sr *sr_info = kzalloc(sizeof(struct
 omap_sr), GFP_KERNEL);
   struct omap_sr_data *pdata = pdev-dev.platform_data;
   struct resource *mem, *irq;
 - struct dentry *vdd_dbg_dir, *dbg_dir;
 - int ret = 0;
 + struct dentry *vdd_dbg_dir, *dbg_dir, *nvalue_dir;
 + struct omap_volt_data *volt_data;
 + int i, ret = 0;

   if (!sr_info) {
   dev_err(pdev-dev, %s: unable to allocate
 sr_info\n,
 @@ -897,6 +899,46 @@ static int __init omap_sr_probe(struct
 platform_device *pdev)

   (void) debugfs_create_file(autocomp, S_IRUGO |
 S_IWUGO, dbg_dir,
   (void *)sr_info, pm_sr_fops);
 + (void) debugfs_create_x32(errweight, S_IRUGO,
 dbg_dir,
 + sr_info-err_weight);
 + (void) debugfs_create_x32(errmaxlimit, S_IRUGO,
 dbg_dir,
 + sr_info-err_maxlimit);
 + (void) debugfs_create_x32(errminlimit, S_IRUGO,
 dbg_dir,
 + sr_info-err_minlimit);
 +
 + nvalue_dir = debugfs_create_dir(nvalue, dbg_dir);
 + if (IS_ERR(nvalue_dir)) {
 + dev_err(pdev-dev, %s: Unable to create
 debugfs directory
 + for n-values\n, __func__);
 + return PTR_ERR(nvalue_dir);
 + }
 +
 + omap_voltage_get_volttable(sr_info-voltdm,
 volt_data);
 + if (!volt_data) {
 + dev_warn(pdev-dev, %s: No Voltage table for
 the
 +  corresponding vdd vdd_%s. Cannot create
 debugfs
 + entries for n-values\n,
 + __func__, sr_info-voltdm-name);
 + return -ENODATA;
 + }
 +
 + for (i = 0; i  sr_info-nvalue_count; i++) {
 + char *name;
 + char volt_name[32];
 +
 + name = kzalloc(NVALUE_NAME_LEN + 1, GFP_KERNEL);
 + if (!name) {
 + dev_err(pdev-dev, %s: Unable to
 allocate memory
 +  for n-value directory name\n,
 __func__);
 + return -ENOMEM;
 + }
 +
 + strcpy(name, volt_);
 + sprintf(volt_name, %d,
 volt_data[i].volt_nominal);
 + strcat(name, volt_name);
 + (void) debugfs_create_x32(name, S_IRUGO |
 S_IWUGO, nvalue_dir,
 + (sr_info-nvalue_table[i].nvalue));
 + }

   return ret;

 diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-
 omap2/voltage.c
 index 875667f..b27fa4f 100644
 --- a/arch/arm/mach-omap2/voltage.c
 +++ b/arch/arm/mach-omap2/voltage.c
 @@ -250,6 +250,47 @@ static void omap3_voltage_write_reg(u32
 val, u16 mod, u8 offset)
   omap2_prm_write_mod_reg(val, mod, offset);
  }

 +/* Voltage debugfs support */

Add comment for the function.

 +static int vp_volt_debug_get(void *data, u64 *val)
 +{
 + struct omap_vdd_info *vdd = (struct omap_vdd_info *)
 data;
 + u8 vsel;
 +
 + if (!vdd) {
 + pr_warning(Wrong paramater passed\n);
 + return -EINVAL;
 + }
 +
 + vsel = vdd-read_reg(vdd-vp_reg.prm_mod, vdd-
 vp_offs.voltage);
 + pr_notice(curr_vsel = %x\n, vsel);
 +
 + if 

[RFC/PATCH 0/3] TWL4030 IRQ Changes

[Felipe Balbi]

Hi all,

I dropped the twl6030-irq.c changes because that
thing is a bit messy. I hope the original author
will feel inspired and fix that one up.

Anyway, twl4030-irq.c seems to be going to the
right direction now. Thanks to Mark Brown for
pointing out the need to drop the locking and
implement bus_lock/bus_sync_unlock methods.

Compile tested only with omap2plus_defconfig.

I'll test after merge window to be sure I have
all the newest code.

Felipe Balbi (3):
  mfd: twl4030-irq: move to threaded_irq
  mfd: twl4030-irq: drop the workqueue hackery
  mfd: twl4030-irq: implement bus_*lock

 drivers/mfd/twl4030-irq.c |  363 +---
 1 files changed, 140 insertions(+), 223 deletions(-)

-- 
1.7.3.4.598.g85356

--
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 2/3] mfd: twl4030-irq: drop the workqueue hackery

[Felipe Balbi]

Finally that workqueue isn't needed anymore.
Drop that hackery and move the spinlock_t to
a mutex so we can issue I2C operations with
a lock held.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/mfd/twl4030-irq.c |  226 +++--
 1 files changed, 96 insertions(+), 130 deletions(-)

diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
index 91331a7..298956d 100644
--- a/drivers/mfd/twl4030-irq.c
+++ b/drivers/mfd/twl4030-irq.c
@@ -31,6 +31,7 @@
 #include linux/interrupt.h
 #include linux/irq.h
 #include linux/slab.h
+#include linux/mutex.h
 
 #include linux/i2c/twl.h
 
@@ -434,46 +435,36 @@ static inline void activate_irq(int irq)
 
 /*--*/
 
-static DEFINE_SPINLOCK(sih_agent_lock);
-
-static struct workqueue_struct *wq;
-
 struct sih_agent {
int irq_base;
const struct sih*sih;
 
u32 imr;
-   boolimr_change_pending;
-   struct work_struct  mask_work;
-
u32 edge_change;
-   struct work_struct  edge_work;
+
+   struct mutexirq_lock;
 };
 
-static void twl4030_sih_do_mask(struct work_struct *work)
+/*--*/
+
+static void twl4030_sih_mask(unsigned irq)
 {
-   struct sih_agent*agent;
-   const struct sih*sih;
+   struct sih_agent*agent = get_irq_chip_data(irq);
+   const struct sih*sih = agent-sih;
+
union {
u8  bytes[4];
u32 word;
}   imr;
+
int status;
 
-   agent = container_of(work, struct sih_agent, mask_work);
-
-   /* see what work we have */
-   spin_lock_irq(sih_agent_lock);
-   if (agent-imr_change_pending) {
-   sih = agent-sih;
-   /* byte[0] gets overwritten as we write ... */
-   imr.word = cpu_to_le32(agent-imr  8);
-   agent-imr_change_pending = false;
-   } else
-   sih = NULL;
-   spin_unlock_irq(sih_agent_lock);
-   if (!sih)
-   return;
+   agent-imr |= BIT(irq - agent-irq_base);
+
+   mutex_lock(agent-irq_lock);
+
+   /* byte[0] gets overwritten as we write ... */
+   imr.word = cpu_to_le32(agent-imr  8);
 
/* write the whole mask ... simpler than subsetting it */
status = twl_i2c_write(sih-module, imr.bytes,
@@ -481,111 +472,42 @@ static void twl4030_sih_do_mask(struct work_struct *work)
if (status)
pr_err(twl4030: %s, %s -- %d\n, __func__,
write, status);
+   mutex_unlock(agent-irq_lock);
 }
 
-static void twl4030_sih_do_edge(struct work_struct *work)
+static void twl4030_sih_unmask(unsigned irq)
 {
-   struct sih_agent*agent;
-   const struct sih*sih;
-   u8  bytes[6];
-   u32 edge_change;
-   int status;
-
-   agent = container_of(work, struct sih_agent, edge_work);
-
-   /* see what work we have */
-   spin_lock_irq(sih_agent_lock);
-   edge_change = agent-edge_change;
-   agent-edge_change = 0;
-   sih = edge_change ? agent-sih : NULL;
-   spin_unlock_irq(sih_agent_lock);
-   if (!sih)
-   return;
-
-   /* Read, reserving first byte for write scratch.  Yes, this
-* could be cached for some speedup ... but be careful about
-* any processor on the other IRQ line, EDR registers are
-* shared.
-*/
-   status = twl_i2c_read(sih-module, bytes + 1,
-   sih-edr_offset, sih-bytes_edr);
-   if (status) {
-   pr_err(twl4030: %s, %s -- %d\n, __func__,
-   read, status);
-   return;
-   }
+   struct sih_agent*agent = get_irq_chip_data(irq);
+   const struct sih*sih = agent-sih;
 
-   /* Modify only the bits we know must change */
-   while (edge_change) {
-   int i = fls(edge_change) - 1;
-   struct irq_desc *d = irq_to_desc(i + agent-irq_base);
-   int byte = 1 + (i  2);
-   int off = (i  0x3) * 2;
-
-   if (!d) {
-   pr_err(twl4030: Invalid IRQ: %d\n,
-  i + agent-irq_base);
-   return;
-   }
+   union {
+   u8  bytes[4];
+   u32 word;
+   }   imr;
 
-   bytes[byte] = ~(0x03  off);
+   int status;
 
-   raw_spin_lock_irq(d-lock);
-   if (d-status  IRQ_TYPE_EDGE_RISING)
-   bytes[byte] |= BIT(off + 1);
-   if 

[RFC/PATCH 1/3] mfd: twl4030-irq: move to threaded_irq

[Felipe Balbi]

... and while at that, also start using
handle_nested_irq() as we should.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/mfd/twl4030-irq.c |  131 +
 1 files changed, 38 insertions(+), 93 deletions(-)

diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
index 5d3a147..91331a7 100644
--- a/drivers/mfd/twl4030-irq.c
+++ b/drivers/mfd/twl4030-irq.c
@@ -30,7 +30,6 @@
 #include linux/init.h
 #include linux/interrupt.h
 #include linux/irq.h
-#include linux/kthread.h
 #include linux/slab.h
 
 #include linux/i2c/twl.h
@@ -278,91 +277,50 @@ static const struct sih sih_modules_twl5031[8] = {
 
 static unsigned twl4030_irq_base;
 
-static struct completion irq_event;
-
 /*
  * This thread processes interrupts reported by the Primary Interrupt Handler.
  */
-static int twl4030_irq_thread(void *data)
+static irqreturn_t twl4030_irq_thread(int irq, void *unused)
 {
-   long irq = (long)data;
-   static unsigned i2c_errors;
-   static const unsigned max_i2c_errors = 100;
-
-
-   current-flags |= PF_NOFREEZE;
-
-   while (!kthread_should_stop()) {
-   int ret;
-   int module_irq;
-   u8 pih_isr;
-
-   /* Wait for IRQ, then read PIH irq status (also blocking) */
-   wait_for_completion_interruptible(irq_event);
-
-   ret = twl_i2c_read_u8(TWL4030_MODULE_PIH, pih_isr,
- REG_PIH_ISR_P1);
-   if (ret) {
-   pr_warning(twl4030: I2C error %d reading PIH ISR\n,
-   ret);
-   if (++i2c_errors = max_i2c_errors) {
-   printk(KERN_ERR Maximum I2C error count
-exceeded.  Terminating %s.\n,
-   __func__);
-   break;
-   }
-   complete(irq_event);
-   continue;
-   }
+   int ret;
+   int module_irq;
+   u8 pih_isr;
+
+   ret = twl_i2c_read_u8(TWL4030_MODULE_PIH, pih_isr,
+   REG_PIH_ISR_P1);
+   if (ret) {
+   pr_warning(twl4030: I2C error %d reading PIH ISR\n,
+   ret);
+   return IRQ_NONE;
+   }
 
-   /* these handlers deal with the relevant SIH irq status */
-   local_irq_disable();
-   for (module_irq = twl4030_irq_base;
-   pih_isr;
-   pih_isr = 1, module_irq++) {
-   if (pih_isr  0x1) {
-   struct irq_desc *d = irq_to_desc(module_irq);
-
-   if (!d) {
-   pr_err(twl4030: Invalid SIH IRQ: %d\n,
-  module_irq);
-   return -EINVAL;
-   }
-
-   /* These can't be masked ... always warn
-* if we get any surprises.
-*/
-   if (d-status  IRQ_DISABLED)
-   note_interrupt(module_irq, d,
-   IRQ_NONE);
-   else
-   d-handle_irq(module_irq, d);
+   /* these handlers deal with the relevant SIH irq status */
+   for (module_irq = twl4030_irq_base;
+   pih_isr;
+   pih_isr = 1, module_irq++) {
+   if (pih_isr  0x1) {
+   struct irq_desc *d = irq_to_desc(module_irq);
+
+   if (!d) {
+   pr_err(twl4030: Invalid SIH IRQ: %d\n,
+   module_irq);
+   return IRQ_NONE;
}
-   }
-   local_irq_enable();
 
-   enable_irq(irq);
+   /* These can't be masked ... always warn
+* if we get any surprises.
+*/
+   if (d-status  IRQ_DISABLED)
+   note_interrupt(module_irq, d,
+   IRQ_NONE);
+   else
+   handle_nested_irq(module_irq);
+   }
}
 
-   return 0;
-}
-
-/*
- * handle_twl4030_pih() is the desc-handle method for the twl4030 interrupt.
- * This is a chained interrupt, so there is no desc-action method for it.
- * Now we need to query the interrupt controller in the twl4030 to determine
- * which module is generating the interrupt request.  However, we can't do i2c
- * transactions in interrupt context, so we 

[RFC/PATCH 3/3] mfd: twl4030-irq: implement bus_*lock

[Felipe Balbi]

drop all the locking around mask/unmask and
implement bus_lock and bus_sync_unlock methods.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/mfd/twl4030-irq.c |   30 ++
 1 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
index 298956d..ff7bb93 100644
--- a/drivers/mfd/twl4030-irq.c
+++ b/drivers/mfd/twl4030-irq.c
@@ -461,8 +461,6 @@ static void twl4030_sih_mask(unsigned irq)
 
agent-imr |= BIT(irq - agent-irq_base);
 
-   mutex_lock(agent-irq_lock);
-
/* byte[0] gets overwritten as we write ... */
imr.word = cpu_to_le32(agent-imr  8);
 
@@ -472,7 +470,6 @@ static void twl4030_sih_mask(unsigned irq)
if (status)
pr_err(twl4030: %s, %s -- %d\n, __func__,
write, status);
-   mutex_unlock(agent-irq_lock);
 }
 
 static void twl4030_sih_unmask(unsigned irq)
@@ -487,7 +484,6 @@ static void twl4030_sih_unmask(unsigned irq)
 
int status;
 
-   mutex_lock(agent-irq_lock);
agent-imr = ~BIT(irq - agent-irq_base);
 
/* byte[0] gets overwritten as we write ... */
@@ -499,7 +495,6 @@ static void twl4030_sih_unmask(unsigned irq)
if (status)
pr_err(twl4030: %s, %s -- %d\n, __func__,
write, status);
-   mutex_unlock(agent-irq_lock);
 }
 
 static int twl4030_sih_set_type(unsigned irq, unsigned trigger)
@@ -517,7 +512,6 @@ static int twl4030_sih_set_type(unsigned irq, unsigned 
trigger)
if (trigger  ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
return -EINVAL;
 
-   mutex_lock(agent-irq_lock);
if ((desc-status  IRQ_TYPE_SENSE_MASK) != trigger) {
u8  bytes[6];
u32 edge_change;
@@ -537,7 +531,7 @@ static int twl4030_sih_set_type(unsigned irq, unsigned 
trigger)
if (status) {
pr_err(twl4030: %s, %s -- %d\n, __func__,
read, status);
-   goto out;
+   return status;
}
 
/* Modify only the bits we know must change */
@@ -550,8 +544,7 @@ static int twl4030_sih_set_type(unsigned irq, unsigned 
trigger)
if (!d) {
pr_err(twl4030: Invalid IRQ: %d\n,
i + agent-irq_base);
-   status = -ENODEV;
-   goto out;
+   return -ENODEV;
}
 
bytes[byte] = ~(0x03  off);
@@ -574,17 +567,30 @@ static int twl4030_sih_set_type(unsigned irq, unsigned 
trigger)
write, status);
}
 
-out:
-   mutex_unlock(agent-irq_lock);
-
return status;
 }
 
+static void twl4030_sih_bus_lock(unsigned int irq)
+{
+   struct sih_agent*agent = get_irq_chip_data(irq);
+
+   mutex_lock(agent-irq_lock);
+}
+
+static void twl4030_sih_bus_sync_unlock(unsigned int irq)
+{
+   struct sih_agent*agent = get_irq_chip_data(irq);
+
+   mutex_unlock(agent-irq_lock);
+}
+
 static struct irq_chip twl4030_sih_irq_chip = {
.name   = twl4030,
.mask   = twl4030_sih_mask,
.unmask = twl4030_sih_unmask,
.set_type   = twl4030_sih_set_type,
+   .bus_lock   = twl4030_sih_bus_lock,
+   .bus_sync_unlock = twl4030_sih_bus_sync_unlock,
 };
 
 /*--*/
-- 
1.7.3.4.598.g85356

--
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 2/5] OMAP4: Adding voltage driver support

[Anand Sawant]

Thara,

 -Original Message-
 From: Thara Gopinath [mailto:th...@ti.com]
 Sent: Monday, December 20, 2010 10:31 PM
 To: linux-omap@vger.kernel.org; linux-arm-
 ker...@lists.infradead.org
 Cc: khil...@deeprootsystems.com; p...@pwsan.com; b-
 cous...@ti.com; vishwanath...@ti.com; saw...@ti.com;
 n...@ti.com; Thara Gopinath
 Subject: [PATCH v5 2/5] OMAP4: Adding voltage driver support

 OMAP4 has three scalable voltage domains vdd_mpu, vdd_iva
 and vdd_core. This patch adds the voltage tables and other
 configurable voltage processor and voltage controller
 settings to control these three scalable domains in OMAP4.

 Signed-off-by: Thara Gopinath th...@ti.com
 ---
 This patch has 9 checkpatch.pl above 80-chars warnings for
 the definitions of omap44xx_vdd_mpu_volt_data,
 omap44xx_vdd_iva_volt_data
 and omap44xx_vdd_core_volt_data.
 IMHO splitting of the entries in these structures affects
 readability and looks very ugly. Hence they are left as is.

  arch/arm/mach-omap2/Makefile  |2 +-
  arch/arm/mach-omap2/control.h |   12 ++
  arch/arm/mach-omap2/voltage.c |  279
 +
  arch/arm/plat-omap/include/plat/voltage.h |   12 ++
  4 files changed, 304 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-
 omap2/Makefile
 index ae29a00..9a73b82 100644
 --- a/arch/arm/mach-omap2/Makefile
 +++ b/arch/arm/mach-omap2/Makefile
 @@ -61,7 +61,7 @@ obj-$(CONFIG_ARCH_OMAP2)+=
 pm24xx.o
  obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o pm_bus.o
  obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
 voltage.o \
  cpuidle34xx.o pm_bus.o
 -obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o pm_bus.o
 +obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o voltage.o
 pm_bus.o
  obj-$(CONFIG_PM_DEBUG)   += pm-debug.o
  obj-$(CONFIG_OMAP_SMARTREFLEX)  += sr_device.o
 smartreflex.o
  obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3)+= smartreflex-
 class3.o
 diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-
 omap2/control.h
 index 9fe32dc..81940ef 100644
 --- a/arch/arm/mach-omap2/control.h
 +++ b/arch/arm/mach-omap2/control.h
 @@ -181,6 +181,18 @@
  #define OMAP3630_CONTROL_FUSE_OPP50_VDD2
 (OMAP2_CONTROL_GENERAL + 0x0128)
  #define OMAP3630_CONTROL_FUSE_OPP100_VDD2
 (OMAP2_CONTROL_GENERAL + 0x012C)

 +/* OMAP44xx control efuse offsets */
 +#define OMAP44XX_CONTROL_FUSE_IVA_OPP50  0x22C
 +#define OMAP44XX_CONTROL_FUSE_IVA_OPP100 0x22F
 +#define OMAP44XX_CONTROL_FUSE_IVA_OPPTURBO   0x232
 +#define OMAP44XX_CONTROL_FUSE_IVA_OPPNITRO   0x235
 +#define OMAP44XX_CONTROL_FUSE_MPU_OPP50  0x240
 +#define OMAP44XX_CONTROL_FUSE_MPU_OPP100 0x243
 +#define OMAP44XX_CONTROL_FUSE_MPU_OPPTURBO   0x246
 +#define OMAP44XX_CONTROL_FUSE_MPU_OPPNITRO   0x249
 +#define OMAP44XX_CONTROL_FUSE_CORE_OPP50 0x254
 +#define OMAP44XX_CONTROL_FUSE_CORE_OPP1000x257
 +
  /* AM35XX only CONTROL_GENERAL register offsets */
  #define AM35XX_CONTROL_MSUSPENDMUX_6
 (OMAP2_CONTROL_GENERAL + 0x0038)
  #define AM35XX_CONTROL_DEVCONF2
 (OMAP2_CONTROL_GENERAL + 0x0310)
 diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-
 omap2/voltage.c
 index b27fa4f..ed6079c 100644
 --- a/arch/arm/mach-omap2/voltage.c
 +++ b/arch/arm/mach-omap2/voltage.c
 @@ -29,6 +29,10 @@
  #include plat/voltage.h

  #include prm-regbits-34xx.h
 +#include prm-regbits-44xx.h
 +#include prm44xx.h
 +#include prcm44xx.h
 +#include prminst44xx.h
  #include control.h

  #define VP_IDLE_TIMEOUT  200
 @@ -190,6 +194,51 @@ static struct omap_vdd_info
 omap3_vdd_info[] = {

  #define OMAP3_NR_SCALABLE_VDD ARRAY_SIZE(omap3_vdd_info)


My comments on the patch

[PATCH v6 01/10] OMAP3: PM: Adding voltage driver support

are applicable here. Please refer to

http://marc.info/?l=linux-omapm=129355306112127w=2

for more details.

Best Regards,

Anand S Sawant

 +/* OMAP4 VDD sturctures */
 +static struct omap_vdd_info omap4_vdd_info[] = {
 + {
 + .vp_offs = {
 + .vpconfig =
 OMAP4_PRM_VP_MPU_CONFIG_OFFSET,
 + .vstepmin =
 OMAP4_PRM_VP_MPU_VSTEPMIN_OFFSET,
 + .vstepmax =
 OMAP4_PRM_VP_MPU_VSTEPMAX_OFFSET,
 + .vlimitto =
 OMAP4_PRM_VP_MPU_VLIMITTO_OFFSET,
 + .vstatus = OMAP4_PRM_VP_MPU_STATUS_OFFSET,
 + .voltage =
 OMAP4_PRM_VP_MPU_VOLTAGE_OFFSET,
 + },
 + .voltdm = {
 + .name = mpu,
 + },
 + },
 + {
 + .vp_offs = {
 + .vpconfig =
 OMAP4_PRM_VP_IVA_CONFIG_OFFSET,
 + .vstepmin =
 OMAP4_PRM_VP_IVA_VSTEPMIN_OFFSET,
 + .vstepmax =
 OMAP4_PRM_VP_IVA_VSTEPMAX_OFFSET,
 + .vlimitto =
 OMAP4_PRM_VP_IVA_VLIMITTO_OFFSET,
 + .vstatus = OMAP4_PRM_VP_IVA_STATUS_OFFSET,
 

Re: [RFC/PATCH 0/3] TWL4030 IRQ Changes

[Felipe Balbi]

Hi,

On Tue, Dec 28, 2010 at 07:14:16PM +0200, Felipe Balbi wrote:

I dropped the twl6030-irq.c changes because that
thing is a bit messy. I hope the original author
will feel inspired and fix that one up.

Anyway, twl4030-irq.c seems to be going to the
right direction now. Thanks to Mark Brown for
pointing out the need to drop the locking and
implement bus_lock/bus_sync_unlock methods.

Compile tested only with omap2plus_defconfig.

I'll test after merge window to be sure I have
all the newest code.


when we finally move to struct irq_data, the below could
be used. BTW, Thomas do you have any plans for exposing
irq_data_to_desc() ?

8-- cut here --

From 6069e3ddb34608fef0cb3dca3e544fca8deb3840 Mon Sep 17 00:00:00 2001
From: Felipe Balbi ba...@ti.com
Date: Tue, 28 Dec 2010 19:33:22 +0200
Subject: [PATCH] mfd: twl4030-irq: switch to new methods
Organization: Texas Instruments\n

Move everybody to struct irq_data-based
methods.

NYET-Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/mfd/twl4030-irq.c |   86 -
 1 files changed, 61 insertions(+), 25 deletions(-)

diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
index ff7bb93..ad6197c 100644
--- a/drivers/mfd/twl4030-irq.c
+++ b/drivers/mfd/twl4030-irq.c
@@ -447,10 +447,14 @@ struct sih_agent {
 
 /*--*/
 
-static void twl4030_sih_mask(unsigned irq)

+/* REVISIT define it here until IRQ Subsystem exports its implementation */
+#define irq_data_to_desc(data) container_of(data, struct irq_desc, irq_data)
+
+static void twl4030_sih_mask(struct irq_data *data)
 {
-   struct sih_agent*agent = get_irq_chip_data(irq);
-   const struct sih*sih = agent-sih;
+   struct irq_desc *d = irq_data_to_desc(data);
+   struct sih_agent*agent;
+   const struct sih*sih;
 
 	union {

u8  bytes[4];
@@ -458,7 +462,13 @@ static void twl4030_sih_mask(unsigned irq)
}   imr;
 
 	int			status;

+   int irq = data-irq;
 
+	if (!d)

+   return;
+
+   agent = d-chip_data;
+   sih = agent-sih;
agent-imr |= BIT(irq - agent-irq_base);
 
 	/* byte[0] gets overwritten as we write ... */

@@ -472,10 +482,11 @@ static void twl4030_sih_mask(unsigned irq)
write, status);
 }
 
-static void twl4030_sih_unmask(unsigned irq)

+static void twl4030_sih_unmask(struct irq_data *data)
 {
-   struct sih_agent*agent = get_irq_chip_data(irq);
-   const struct sih*sih = agent-sih;
+   struct irq_desc *d = irq_data_to_desc(data);
+   struct sih_agent*agent;
+   const struct sih*sih;
 
 	union {

u8  bytes[4];
@@ -483,7 +494,13 @@ static void twl4030_sih_unmask(unsigned irq)
}   imr;
 
 	int			status;

+   int irq = data-irq;
+
+   if (!d)
+   return;
 
+	agent = d-chip_data;

+   sih = agent-sih;
agent-imr = ~BIT(irq - agent-irq_base);
 
 	/* byte[0] gets overwritten as we write ... */

@@ -497,14 +514,15 @@ static void twl4030_sih_unmask(unsigned irq)
write, status);
 }
 
-static int twl4030_sih_set_type(unsigned irq, unsigned trigger)

+static int twl4030_sih_set_type(struct irq_data *data, unsigned trigger)
 {
-   struct sih_agent*agent = get_irq_chip_data(irq);
-   const struct sih*sih = agent-sih;
-   struct irq_desc *desc = irq_to_desc(irq);
+   struct irq_desc *d = irq_data_to_desc(data);
+   struct sih_agent*agent;
+   const struct sih*sih;
int status = 0;
+   int irq = data-irq;
 
-	if (!desc) {

+   if (!d) {
pr_err(twl4030: Invalid IRQ: %d\n, irq);
return -EINVAL;
}
@@ -512,12 +530,15 @@ static int twl4030_sih_set_type(unsigned irq, unsigned 
trigger)
if (trigger  ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
return -EINVAL;
 
-	if ((desc-status  IRQ_TYPE_SENSE_MASK) != trigger) {

+   agent = d-chip_data;
+   sih = agent-sih;
+
+   if ((d-status  IRQ_TYPE_SENSE_MASK) != trigger) {
u8  bytes[6];
u32 edge_change;
 
-		desc-status = ~IRQ_TYPE_SENSE_MASK;

-   desc-status |= trigger;
+   d-status = ~IRQ_TYPE_SENSE_MASK;
+   d-status |= trigger;
agent-edge_change |= BIT(irq - agent-irq_base);
edge_change = agent-edge_change;
 
@@ -537,7 +558,6 @@ static int twl4030_sih_set_type(unsigned irq, unsigned trigger)

/* Modify only the bits we know must change */
while 

Re: [RFC/PATCH 1/2] mfd: twl6030-irq: move to threaded_irq

[David Brownell]

--- On Tue, 12/28/10, Mark Brown broo...@opensource.wolfsonmicro.com wrote:

 F

 You shouldn't need this any more; the driver used to be
 faffing around
 with this because it wasn't using genirq for
 this in the past.

Originally it couldn't, since genirq didn't
support threaded IRQ handling...

...

 
 Simiarly here as far as I know; the original code predates
 genirq
 support for this so is doing some hairy stuff that is no
 longer
 required and may actually be harmful.
 
 What I'd expect to see from a conversion like this would be
 that most of
 the locking/IRQ management stuff would be dropped

I'd expect that genirq solve all the issues and
that its support be used.  That's not the same
as dropping anything except the initial code to
handle what genirq didn't ... some locking/etc
would still mostly need doing, but where genirq
now handles it, that'd be preferable.
 and the
 bus_lock() and
 bus_sync_unlock() operations would be implemented.
h
ISTR maybe four or five genirq updates in the
area of threaded IRQ management, added so that
issues the twl4030 driver needed to be solved
could be solved in generic ways.

The first was just having threaded IRQ handlers,
and another was I think removing the initial
quick'n'dirty thread-per-irq restriction; there
was no point in having a few dozen IRQ threads
in e.g. a twl4030 driver, since two could never
do constructive work concurrently.

I'm glad to see this conversion finally start.
Even if all the threaded IRQ hooks don't get used
to best advantage, it'll be an improvement.

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

Re: [RFC/PATCH 0/3] TWL4030 IRQ Changes

[Mark Brown]

On Tue, Dec 28, 2010 at 07:36:04PM +0200, Felipe Balbi wrote:

 when we finally move to struct irq_data, the below could
 be used. BTW, Thomas do you have any plans for exposing
 irq_data_to_desc() ?

The general idea is to move to struct irq_data sooner rather than later
(all the existing MFD drivers have already been converted).

 -static void twl4030_sih_mask(unsigned irq)
 +/* REVISIT define it here until IRQ Subsystem exports its implementation */
 +#define irq_data_to_desc(data)   container_of(data, struct irq_desc, 
 irq_data)

It looks like all you're using this for is to get the chip_data?  If
that is the case you're looking for irq_data_get_irq_chip_data() which
will go directly from the irq_data to the chip_data.  I may have missed
something, I only scanned the code.
--
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

OMAP Color Rotation

[David Lynch Jr.]

I am looking for an example of programing the color rotation
registers. 
I need to swap red and blue in software. 
This should be fairly easy, but some code usi_ng the color rotation
registers would help. 
DISPC_CPR_COEF_R  



-- 
Dave Lynch  DLA Systems
Software Development:Embedded Linux
717.587.7774   dh...@dlasys.nethttp://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too
numerous to list.

Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction.
Albert Einstein



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

Re: [RFC/PATCH 1/2] mfd: twl6030-irq: move to threaded_irq

[Mark Brown]

On Tue, Dec 28, 2010 at 09:40:03AM -0800, David Brownell wrote:

  What I'd expect to see from a conversion like this would be
  that most of
  the locking/IRQ management stuff would be dropped

 I'd expect that genirq solve all the issues and
 that its support be used.  That's not the same
 as dropping anything except the initial code to
 handle what genirq didn't ... some locking/etc
 would still mostly need doing, but where genirq
 now handles it, that'd be preferable.

It should solve everything - there's rather a lot of I2C/SPI connected
MFDs using genirq fully now without any hassle, the APIs are really
straightforward and easy to use.

  and the
  bus_lock() and
  bus_sync_unlock() operations would be implemented.

 ISTR maybe four or five genirq updates in the
 area of threaded IRQ management, added so that
 issues the twl4030 driver needed to be solved
 could be solved in generic ways.

Yup - the main one on top of threaded IRQs was the bus_lock() and
bus_sync_unlock() methods.

 The first was just having threaded IRQ handlers,
 and another was I think removing the initial
 quick'n'dirty thread-per-irq restriction; there
 was no point in having a few dozen IRQ threads
 in e.g. a twl4030 driver, since two could never
 do constructive work concurrently.

The thread per IRQ thing is dealt with too, the secondary IRQs share the
thread used for demux.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 3/3] mfd: twl4030-irq: implement bus_*lock

[Mark Brown]

On Tue, Dec 28, 2010 at 07:14:19PM +0200, Felipe Balbi wrote:

 +static void twl4030_sih_bus_sync_unlock(unsigned int irq)
 +{
 +   struct sih_agent*agent = get_irq_chip_data(irq);
 +
 +   mutex_unlock(agent-irq_lock);
 +}

I suspect you need to do some sort of sync with the hardware here - the
_sync bit of the name comes from the fact that the mask and unmask stuff
is still called with IRQs disabled and so can't touch and I2C chip, this
is called after reenabling them give a chance for the updates done to
be reflected in the hardware.  The implementation everyone else has done
is to update a register cache in the other functions then write that
out here before dropping the mutex.

  static struct irq_chip twl4030_sih_irq_chip = {
   .name   = twl4030,
   .mask   = twl4030_sih_mask,
   .unmask = twl4030_sih_unmask,
   .set_type   = twl4030_sih_set_type,
 + .bus_lock   = twl4030_sih_bus_lock,
 + .bus_sync_unlock = twl4030_sih_bus_sync_unlock,
  };

I just realised that this collides with the conversion to the irq_
versions that has been done on the driver in -next by either myself or
Lennart (we both submitted essentially the same patches and a couple of
his went in) - that was a purely mechanical conversion that didn't
address any of the issues this patch addresses but they're touching the
same code.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 3/3] mfd: twl4030-irq: implement bus_*lock

[Felipe Balbi]

Hi,

On Tue, 2010-12-28 at 23:58 +, Mark Brown wrote:
 On Tue, Dec 28, 2010 at 07:14:19PM +0200, Felipe Balbi wrote:
 
  +static void twl4030_sih_bus_sync_unlock(unsigned int irq)
  +{
  +   struct sih_agent*agent = get_irq_chip_data(irq);
  +
  +   mutex_unlock(agent-irq_lock);
  +}
 
 I suspect you need to do some sort of sync with the hardware here - the
 _sync bit of the name comes from the fact that the mask and unmask stuff
 is still called with IRQs disabled and so can't touch and I2C chip, this
 is called after reenabling them give a chance for the updates done to
 be reflected in the hardware.  The implementation everyone else has done
 is to update a register cache in the other functions then write that
 out here before dropping the mutex.

now that I look at some gpio chips I see what you're saying, will update
that tomorrow. Thanks

   static struct irq_chip twl4030_sih_irq_chip = {
  .name   = twl4030,
  .mask   = twl4030_sih_mask,
  .unmask = twl4030_sih_unmask,
  .set_type   = twl4030_sih_set_type,
  +   .bus_lock   = twl4030_sih_bus_lock,
  +   .bus_sync_unlock = twl4030_sih_bus_sync_unlock,
   };
 
 I just realised that this collides with the conversion to the irq_
 versions that has been done on the driver in -next by either myself or
 Lennart (we both submitted essentially the same patches and a couple of
 his went in) - that was a purely mechanical conversion that didn't
 address any of the issues this patch addresses but they're touching the
 same code.

no problem. This will actually only be able on 2.6.39 merge window
anyway, so I'll have plenty of time to rebase on 2.6.38 and get these
patches queued.

ps: sorry the mail change, out of the office.

-- 
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: [RFC/PATCH 0/3] TWL4030 IRQ Changes

[Felipe Balbi]

Hi,

On Tue, 2010-12-28 at 17:41 +, Mark Brown wrote:
  when we finally move to struct irq_data, the below could
  be used. BTW, Thomas do you have any plans for exposing
  irq_data_to_desc() ?
 
 The general idea is to move to struct irq_data sooner rather than later
 (all the existing MFD drivers have already been converted).

Great, I'll put this one together then.

  -static void twl4030_sih_mask(unsigned irq)
  +/* REVISIT define it here until IRQ Subsystem exports its implementation */
  +#define irq_data_to_desc(data) container_of(data, struct irq_desc, 
  irq_data)
 
 It looks like all you're using this for is to get the chip_data?  If
 that is the case you're looking for irq_data_get_irq_chip_data() which
 will go directly from the irq_data to the chip_data.  I may have missed
 something, I only scanned the code.

you're right, just didn't know that was such a helper. BTW, quite a big
name.

-- 
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 1/5] ASoC: DMIC: Adding the OMAP DMIC driver

[Lambert, David]

On Tue, Dec 28, 2010 at 5:14 AM, Felipe Balbi ba...@ti.com wrote:
 Hi,

 On Mon, Dec 27, 2010 at 10:17:02PM -0600, David Lambert wrote:

 This patch adds support for the OMAP4 digital microphone DAI.

 This DAI can support support recording in 2, 4, or 6 channels

 When provided with a 19.2Mhz functional clock, can encode at 96Khz or
 192Khz (all
 channels must have the same sample rate).

 Details of the hardware interface can be found in the OMAP4 TRM in Section
 23.7

 Signed-off-by: David Lambert dlamb...@ti.com
 ---
 arch/arm/plat-omap/include/plat/dmic.h |   83 +
 sound/soc/omap/omap-dmic.c             |  596
 
 sound/soc/omap/omap-dmic.h             |   38 ++
 3 files changed, 717 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/plat-omap/include/plat/dmic.h
 create mode 100644 sound/soc/omap/omap-dmic.c
 create mode 100644 sound/soc/omap/omap-dmic.h

 diff --git a/arch/arm/plat-omap/include/plat/dmic.h
 b/arch/arm/plat-omap/include/plat/dmic.h
 new file mode 100644
 index 000..8a988bf
 --- /dev/null
 +++ b/arch/arm/plat-omap/include/plat/dmic.h
 @@ -0,0 +1,83 @@
 +/*
 + * omap-dmic.h  --  OMAP Digital Microphone Controller
 + *
 + * Author: Liam Girdwood l...@slimlogic.co.uk
 + *        David Lambert dlamb...@ti.com
 + *        Misael Lopez Cruz misael.lo...@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.
 + */
 +
 +#ifndef __ASM_ARCH_OMAP_DMIC_H
 +#define __ASM_ARCH_OMAP_DMIC_H
 +
 +#define OMAP44XX_DMIC_L3_BASE  0x4902e000
 +
 +#define OMAP_DMIC_REVISION             0x00
 +#define OMAP_DMIC_SYSCONFIG            0x10
 +#define OMAP_DMIC_IRQSTATUS_RAW                0x24
 +#define OMAP_DMIC_IRQSTATUS            0x28
 +#define OMAP_DMIC_IRQENABLE_SET                0x2C
 +#define OMAP_DMIC_IRQENABLE_CLR                0x30
 +#define OMAP_DMIC_IRQWAKE_EN           0x34
 +#define OMAP_DMIC_DMAENABLE_SET                0x38
 +#define OMAP_DMIC_DMAENABLE_CLR                0x3C
 +#define OMAP_DMIC_DMAWAKEEN            0x40
 +#define OMAP_DMIC_CTRL                 0x44
 +#define OMAP_DMIC_DATA                 0x48
 +#define OMAP_DMIC_FIFO_CTRL            0x4C
 +#define OMAP_DMIC_FIFO_DMIC1R_DATA     0x50
 +#define OMAP_DMIC_FIFO_DMIC1L_DATA     0x54
 +#define OMAP_DMIC_FIFO_DMIC2R_DATA     0x58
 +#define OMAP_DMIC_FIFO_DMIC2L_DATA     0x5C
 +#define OMAP_DMIC_FIFO_DMIC3R_DATA     0x60
 +#define OMAP_DMIC_FIFO_DMIC3L_DATA     0x64
 +
 +/*
 + * DMIC_IRQ bit fields
 + * IRQSTATUS_RAW, IRQSTATUS, IRQENABLE_SET, IRQENABLE_CLR
 + */
 +
 +#define OMAP_DMIC_IRQ                  (1  0)
 +#define OMAP_DMIC_IRQ_FULL             (1  1)
 +#define OMAP_DMIC_IRQ_ALMST_EMPTY      (1  2)
 +#define OMAP_DMIC_IRQ_EMPTY            (1  3)
 +#define OMAP_DMIC_IRQ_MASK             0x07
 +
 +/*
 + * DMIC_DMAENABLE bit fields
 + */
 +
 +#define OMAP_DMIC_DMA_ENABLE           0x1
 +
 +/*
 + * DMIC_CTRL bit fields
 + */
 +
 +#define OMAP_DMIC_UP1_ENABLE           0x0001
 +#define OMAP_DMIC_UP2_ENABLE           0x0002
 +#define OMAP_DMIC_UP3_ENABLE           0x0004
 +#define OMAP_DMIC_FORMAT               0x0008
 +#define OMAP_DMIC_POLAR1               0x0010
 +#define OMAP_DMIC_POLAR2               0x0020
 +#define OMAP_DMIC_POLAR3               0x0040
 +#define OMAP_DMIC_POLAR_MASK           0x0070
 +#define OMAP_DMIC_CLK_DIV_SHIFT                7
 +#define OMAP_DMIC_CLK_DIV_MASK         0x0380
 +#define        OMAP_DMIC_RESET                 0x0400
 +
 +#define OMAP_DMIC_ENABLE_MASK          0x007
 +
 +#define OMAP_DMICOUTFORMAT_LJUST       (0  3)
 +#define OMAP_DMICOUTFORMAT_RJUST       (1  3)
 +
 +/*
 + * DMIC_FIFO_CTRL bit fields
 + */
 +
 +#define OMAP_DMIC_THRES_MAX            0xF
 +
 +

 one blank line only. BTW, are these used anywwhere outside the dmic.c
 driver ? If not, it's better to move the definitions there.


They were originally in the omap-dmic.h header, but it was suggested
that we move
them to a platform header so that the driver could be more
architecture independent
and we could put the platform specific details here.  I'm OK putting
them just about
anywhere, as long as we have consensus.

 +#endif
 diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
 new file mode 100644
 index 000..6ba05bd
 --- /dev/null
 +++ b/sound/soc/omap/omap-dmic.c
 @@ -0,0 +1,596 @@
 +/*
 + * omap-dmic.c  --  OMAP ASoC DMIC DAI driver
 + *
 + * Copyright (C) 2010 Texas Instruments
 + *
 + * Author: Liam Girdwood l...@slimlogic.co.uk
 + *        David Lambert dlamb...@ti.com
 + *        Misael Lopez Cruz misael.lo...@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.
 + *
 + * This program is distributed in the hope that it will be useful, but
 + * WITHOUT 

Re: [PATCH 3/5] ASoC: DMIC: Adding OMAP DMIC driver to build

[Lambert, David]

On Tue, Dec 28, 2010 at 5:40 AM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
 On Mon, Dec 27, 2010 at 10:17:04PM -0600, David Lambert wrote:
 Adds the OMAP DMIC driver and codec to the build.

 Signed-off-by: David Lambert dlamb...@ti.com
 ---
  sound/soc/codecs/Kconfig  |    3 +++
  sound/soc/codecs/Makefile |    2 ++
  sound/soc/omap/Kconfig    |    5 +
  sound/soc/omap/Makefile   |    2 ++

 This should be one of the last patches in the series, but given the sort
 of drivers you're introducing I'd expect the drivers to just directly
 add the build system stuff in the patch.


OK... I can put the makefile and kconfig changes in with the DMIC driver and the
DMIC codec.

  4 files changed, 12 insertions(+), 0 deletions(-)

 diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
 index 0f33db2..f6c6d31 100644
 --- a/sound/soc/codecs/Kconfig
 +++ b/sound/soc/codecs/Kconfig
 @@ -166,6 +166,9 @@ config SND_SOC_L3
  config SND_SOC_DA7210
          tristate

 +config SND_SOC_DMIC
 +     tristate
 +
  config SND_SOC_MAX98088
         tristate

 diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
 index 10e5e09..9139cf9 100644
 --- a/sound/soc/codecs/Makefile
 +++ b/sound/soc/codecs/Makefile
 @@ -14,6 +14,7 @@ snd-soc-cs42l51-objs := cs42l51.o
  snd-soc-cs4270-objs := cs4270.o
  snd-soc-cx20442-objs := cx20442.o
  snd-soc-da7210-objs := da7210.o
 +snd-soc-dmic-objs := dmic.o
  snd-soc-l3-objs := l3.o
  snd-soc-max98088-objs := max98088.o
  snd-soc-pcm3008-objs := pcm3008.o
 @@ -91,6 +92,7 @@ obj-$(CONFIG_SND_SOC_CS42L51)       += snd-soc-cs42l51.o
  obj-$(CONFIG_SND_SOC_CS4270) += snd-soc-cs4270.o
  obj-$(CONFIG_SND_SOC_CX20442)        += snd-soc-cx20442.o
  obj-$(CONFIG_SND_SOC_DA7210) += snd-soc-da7210.o
 +obj-$(CONFIG_SND_SOC_DMIC)   += snd-soc-dmic.o
  obj-$(CONFIG_SND_SOC_L3)     += snd-soc-l3.o
  obj-$(CONFIG_SND_SOC_JZ4740_CODEC)   += snd-soc-jz4740-codec.o
  obj-$(CONFIG_SND_SOC_MAX98088)       += snd-soc-max98088.o
 diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
 index a088db6..548b13c 100644
 --- a/sound/soc/omap/Kconfig
 +++ b/sound/soc/omap/Kconfig
 @@ -9,6 +9,9 @@ config SND_OMAP_SOC_MCBSP
  config SND_OMAP_SOC_MCPDM
       tristate

 +config SND_OMAP_SOC_DMIC
 +     tristate
 +
  config SND_OMAP_SOC_N810
       tristate SoC Audio support for Nokia N810
       depends on SND_OMAP_SOC  MACH_NOKIA_N810  I2C
 @@ -103,6 +106,8 @@ config SND_OMAP_SOC_SDP4430
       depends on TWL4030_CORE  SND_OMAP_SOC  MACH_OMAP_4430SDP
       select SND_OMAP_SOC_MCPDM
       select SND_SOC_TWL6040
 +     select SND_SOC_DMIC
 +     select SND_OMAP_SOC_DMIC
       help
         Say Y if you want to add support for SoC audio on Texas Instruments
         SDP4430.
 diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
 index ba9fc65..6ff27f5 100644
 --- a/sound/soc/omap/Makefile
 +++ b/sound/soc/omap/Makefile
 @@ -1,9 +1,11 @@
  # OMAP Platform Support
  snd-soc-omap-objs := omap-pcm.o
 +snd-soc-omap-dmic-objs := omap-dmic.o
  snd-soc-omap-mcbsp-objs := omap-mcbsp.o
  snd-soc-omap-mcpdm-objs := omap-mcpdm.o mcpdm.o

  obj-$(CONFIG_SND_OMAP_SOC) += snd-soc-omap.o
 +obj-$(CONFIG_SND_OMAP_SOC_DMIC) += snd-soc-omap-dmic.o
  obj-$(CONFIG_SND_OMAP_SOC_MCBSP) += snd-soc-omap-mcbsp.o
  obj-$(CONFIG_SND_OMAP_SOC_MCPDM) += snd-soc-omap-mcpdm.o

 --
 1.7.0.4




--
David Lambert
OMAP™ Multimedia
214-567-5692
--
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/7 v2] OMAP: McSPI: Hwmod adaptation + runtime conversion

[Govindraj]

Hi Grant,


On Wed, Dec 1, 2010 at 7:31 PM, Govindraj.R govindraj.r...@ti.com wrote:
 Changes invloves:
 
 1) Addition of hwmod data for omap2/3/4.
 1) McSPI driver hwmod adaptation with cleanup of base address
   macros and using omap-device API's.
 2) Runtime Conversion of McSPI driver


Any comments on this patch series?
I need your review comments or ack on
patch 6/6 and patch 7/7.

I hope this patch series can be merged with LO
tree with your ack.

--
Thanks
Govindraj.R



 Changes from v1:
 ---
 1) Fixing patch 5/5 comments for hwmod+runtime
   Split the patch 5/5 to hwmod adaptation
   and then runtime conversion
   http://www.mail-archive.com/linux-omap@vger.kernel.org/msg33387.html

 Testing Updates:
 
 Was tested using data transfer test module available at:
 http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=blob;f=mcspi/test_code/
 utils/mcspi_modules/omap_mcspi_datatest.c;
 h=e42ec10c5c844abdde6a7175a268b379fbbdb655;
 hb=5d9a755d50e58de861c5e8991f2f607bc49b5dc3

 System wide suspend and ret/off counts observation,
 ensured that no behavioral difference with and without
 this patch series.

 Benoit Cousson (1):
  OMAP4: hwmod data: Add McSPI

 Charulatha V (5):
  OMAP2420: hwmod data: Add McSPI
  OMAP2430: hwmod data: Add McSPI
  OMAP3: hwmod data: Add McSPI
  OMAP3: clocks: Update clock domain name for mcspi fck
  OMAP: devices: Modify McSPI device to adapt to hwmod framework

 Govindraj.R (1):
  OMAP: runtime: McSPI driver runtime conversion

  arch/arm/mach-omap2/clock3xxx_data.c       |    4 +
  arch/arm/mach-omap2/devices.c              |  189 ---
  arch/arm/mach-omap2/omap_hwmod_2420_data.c |  156 
  arch/arm/mach-omap2/omap_hwmod_2430_data.c |  219 ++
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  280 
 
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  267 ++
  arch/arm/plat-omap/include/plat/mcspi.h    |   11 +
  drivers/spi/omap2_mcspi.c                  |  225 +++---
  8 files changed, 1051 insertions(+), 300 deletions(-)


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




-- 
---
Regards,
Govindraj.R
--
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 v6 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition

[Grant Likely]

On Fri, Dec 24, 2010 at 01:21:25PM +0100, Gregory CLEMENT wrote:
 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).
 
 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
 
 * Change from v5 to v6:
 Rebase on linus/master (after 2.6.37-rc7)
 Use CONFIG_SUSPEND instead of CONFIG_PM
 Didn't use legacy PM methods anymore. Instead, add a struct dev_pm_ops and 
 add the resume method there.
 Fix multi-line comment style
 
 Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com

Hi Gregory,

Patch does not apply, but I cannot immediately isolate the damage.
Please see if you can figure out the issue on your end.  Is it your
mailer?  I could fudge it, but in the long run it is better if this
issue can get sorted out now.

Also, a few other minor nitpicks (I won't reject a patch over these,
but it helps to have them right):

Please prefix spi patch names with spi[/driver]:.  It is the format
for all spi patches I take through my tree, and if it already follows
that convention, then I don't need to edit it manually.

Second, please keep the line length in the patch description short; in
general I find that a textwidth limit of 70 characters is about right
for the purpose of reading/replying in email.  A lot of maintainers
use text email clients like mutt in 80 column terminal windows.
Keeping a reasonable right hand margin in the text body is simply
friendly.

Finally, in changelogs it is easier to read if there is some kind of
itemization ticks.  For example:

* Change from v5 to v6:
  - Rebase on linus/master (after 2.6.37-rc7)
  - Use CONFIG_SUSPEND instead of CONFIG_PM
  - Didn't use legacy PM methods anymore. Instead, add a struct
dev_pm_ops and add the resume method there.
  - Fix multi-line comment style
 
g.

 ---
  drivers/spi/omap2_mcspi.c |   40 
  1 files changed, 40 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
 index 2a651e6..a17ea97 100644
 --- a/drivers/spi/omap2_mcspi.c
 +++ b/drivers/spi/omap2_mcspi.c
 @@ -1305,10 +1305,50 @@ static int __exit omap2_mcspi_remove(struct 
 platform_device *pdev)
  /* work with hotplug and coldplug */
  MODULE_ALIAS(platform:omap2_mcspi);
  +#ifdef  CONFIG_SUSPEND
 +/*
 + * 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 device *dev)
 +{
 + struct spi_master   *master = dev_get_drvdata(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
 +#define  omap2_mcspi_resume  NULL
 +#endif
 +
 +static const struct dev_pm_ops omap2_mcspi_pm_ops = {
 + .resume = omap2_mcspi_resume,
 +};
 +
  static struct platform_driver omap2_mcspi_driver = {
   .driver = {
   .name = omap2_mcspi,
   .owner =THIS_MODULE,
 + .pm =   omap2_mcspi_pm_ops
 +

Drop the extra line.

   },
   .remove =   __exit_p(omap2_mcspi_remove),
  };
 -- 
 1.7.0.4
 
--

Re: [PATCH 0/7 v2] OMAP: McSPI: Hwmod adaptation + runtime conversion

[Grant Likely]

On Wed, Dec 29, 2010 at 12:57:35PM +0530, Govindraj wrote:
 Hi Grant,
 
 
 On Wed, Dec 1, 2010 at 7:31 PM, Govindraj.R govindraj.r...@ti.com wrote:
  Changes invloves:
  
  1) Addition of hwmod data for omap2/3/4.
  1) McSPI driver hwmod adaptation with cleanup of base address
    macros and using omap-device API's.
  2) Runtime Conversion of McSPI driver
 
 
 Any comments on this patch series?
 I need your review comments or ack on
 patch 6/6 and patch 7/7.
 
 I hope this patch series can be merged with LO
 tree with your ack.

I the process of going through my backlog at the moment.  I should be
able to get to it tomorrow.

g.

 
 --
 Thanks
 Govindraj.R
 
 
 
  Changes from v1:
  ---
  1) Fixing patch 5/5 comments for hwmod+runtime
    Split the patch 5/5 to hwmod adaptation
    and then runtime conversion
    http://www.mail-archive.com/linux-omap@vger.kernel.org/msg33387.html
 
  Testing Updates:
  
  Was tested using data transfer test module available at:
  http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=blob;f=mcspi/test_code/
  utils/mcspi_modules/omap_mcspi_datatest.c;
  h=e42ec10c5c844abdde6a7175a268b379fbbdb655;
  hb=5d9a755d50e58de861c5e8991f2f607bc49b5dc3
 
  System wide suspend and ret/off counts observation,
  ensured that no behavioral difference with and without
  this patch series.
 
  Benoit Cousson (1):
   OMAP4: hwmod data: Add McSPI
 
  Charulatha V (5):
   OMAP2420: hwmod data: Add McSPI
   OMAP2430: hwmod data: Add McSPI
   OMAP3: hwmod data: Add McSPI
   OMAP3: clocks: Update clock domain name for mcspi fck
   OMAP: devices: Modify McSPI device to adapt to hwmod framework
 
  Govindraj.R (1):
   OMAP: runtime: McSPI driver runtime conversion
 
   arch/arm/mach-omap2/clock3xxx_data.c       |    4 +
   arch/arm/mach-omap2/devices.c              |  189 ---
   arch/arm/mach-omap2/omap_hwmod_2420_data.c |  156 
   arch/arm/mach-omap2/omap_hwmod_2430_data.c |  219 ++
   arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  280 
  
   arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  267 
  ++
   arch/arm/plat-omap/include/plat/mcspi.h    |   11 +
   drivers/spi/omap2_mcspi.c                  |  225 +++---
   8 files changed, 1051 insertions(+), 300 deletions(-)
 
 
  --
  To unsubscribe from this list: send the line unsubscribe linux-omap in
  the body of a message to majord...@vger.kernel.org
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
 
 
 
 -- 
 ---
 Regards,
 Govindraj.R
--
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