Re: [PATCH] musb: am35x: fix compile error due to control apis

2010-12-27 Thread Felipe Balbi 

On Thu, Dec 23, 2010 at 12:16:22PM -0500, Ben Gamari wrote:

On Fri,  3 Dec 2010 23:42:45 +0530, Ajay Kumar Gupta ajay.gu...@ti.com wrote:

As the control.h have been moved to new location and it's
uses are not allowed to drivers directly so moving the phy
control, interrupt clear and reset functionality to board
files.


Is this change slated to go into 2.6.37? As it stands it looks like
2.6.37 will be released with completely broken musb support on many boards
(including the BeagleBoard).


yes, it is.

--
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: [GIT PULL] OMAP USB Changes for Merge Window

2010-12-27 Thread Felipe Balbi 

Hi,

On Thu, Dec 23, 2010 at 12:39:20PM -0800, Tony Lindgren wrote:

* Felipe Balbi ba...@ti.com [101223 00:47]:

Hi Tony,

please queue the following two patches for Merge Window.

The following changes since commit b79540fcbbcf9b379c9197f63c5a883bbe3adfd4:

   Linux-omap rebuilt: Merged branches from Paul and Kevin and mux changes 
(2010-12-22 19:13:33 -0800)


This can't be pulled as it would pull in tons of non-mainline
commits from the linux-omap master branch.


heh, my bad. Craneboard wasn't in mainline then I rebased on top of your
tree.


Everybody, all the pullable branches must be based on something
in the mainline kernel, like a recent -rc tag. If that won't work,
then some commit needs to be agreed on separately that will go
to mainline, like the omap-for-linus branch.


Makes sense.


Further, please wait few days before sending the pull request
in case somebody wants to ack your patches. Sending a pull request
with the patches to be reviewed is kind of pointless.. Sure in this


the patches were actually for reference, much like Greg does with the
USB patches.


case these are pretty trivial patches, but still.


patch 1 was pending on l-o for weeks, only patch 2 is new.


Anyways, I'll apply these into a temporary branch and will
merge into omap-for-linus within next few days assuming no
problems.


good, 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 v2] staging: tidspbridge: protect dmm_map properly

2010-12-27 Thread Ohad Ben-Cohen 
Hi Felipe,

On Tue, Dec 21, 2010 at 6:44 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 Wouldn't you want the proc_*_dma() operations to finish before
 unmaping the pages?

Yes, but that's not what your patch is doing exactly: it serializes
the execution of proc_begin_dma(), proc_end_dma(), proc_map() and
proc_un_map() using a single global mutex and by that prevents their
concurrent execution (system-wide).

I understand your intention: you don't want proc_un_map() to kick in
in the middle of a proc_*_dma() operation. That's fine, but the patch
has a side effect, which serializes the DMA operations themselves, and
prevents their concurrent execution (even if they are for separate
memory addresses, or invoked by different processes, etc...).

Looking ahead, this DMM code is going to be extracted into an
independent module, where it will be shared between dspbridge and
syslink (the IPC framework for OMAP4 and forth): both projects use
this DMM concept, and it won't make sense for syslink to duplicate the
code. So even if today's dspbridge use cases doesn't have a lot of
concurrency, and performance is satisfying even in light of your
patch, we still want the code to be ready for more demanding use cases
(several remote processors, several multimedia processes running on
the host, several concurrent multimedia streams, etc...). If we use
coarse-grained locking now, it will just make it harder to remove it
later when scalability issues will show up (see the BKL removal
efforts...).

So I prefer we don't add any locking to the proc_*_dma() API at all.
Instead, let's just take a reference count every time a map_obj is
found (and therefore is about to be used), and release it after it is
used. And now, inside proc_un_map(), if we notice that our map_obj is
still being used, it means the application called us prematurely and
we can't proceed. Something like (revised the patch from my previous
email):

diff --git a/drivers/staging/tidspbridge/include/dspbridge/drv.h
b/drivers/staging/tidspbridge/include/dspbridge/drv.h
index c1f363e..cad0626 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/drv.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/drv.h
@@ -25,6 +25,7 @@

 #include dspbridge/drvdefs.h
 #include linux/idr.h
+#include linux/atomic.h

 #define DRV_ASSIGN 1
 #define DRV_RELEASE0
@@ -106,6 +107,7 @@ struct dmm_map_object {
u32 num_usr_pgs;
struct page **pages;
struct bridge_dma_map_info dma_info;
+   atomic_t refcnt;
 };

 /* Used for DMM reserved memory accounting */
diff --git a/drivers/staging/tidspbridge/rmgr/proc.c
b/drivers/staging/tidspbridge/rmgr/proc.c
index b47d7aa..d060692 100644
--- a/drivers/staging/tidspbridge/rmgr/proc.c
+++ b/drivers/staging/tidspbridge/rmgr/proc.c
@@ -112,9 +112,37 @@ static s32 get_envp_count(char **envp);
 static char **prepend_envp(char **new_envp, char **envp, s32 envp_elems,
   s32 cnew_envp, char *sz_var);

+/* Increase map_obj's reference count */
+static inline void map_obj_get(struct dmm_map_object *map_obj)
+{
+   atomic_inc(map_obj-refcnt);
+}
+
+/* Decrease map_obj's reference count */
+static inline void map_obj_put(struct dmm_map_object *map_obj)
+{
+   atomic_dec(map_obj-refcnt);
+}
+
+/**
+ * is_map_obj_used() - check out whether a given map_obj is still being used
+ * @map_obj:   a dmm map object
+ *
+ * Returns 'true' if a given map_obj is being used, or 'false' otherwise.
+ *
+ * This function must be used while the dmm map list spinlock is taken,
+ * otherwise it is not safe to use its answer (if the list is not locked,
+ * someone can find and start using a map_obj immediately after this functions
+ * replys 'false'.
+ */
+static inline bool is_map_obj_used(struct dmm_map_object *map_obj)
+{
+   return atomic_read(map_obj-refcnt) ? true : false;
+}
+
 /* remember mapping information */
-static struct dmm_map_object *add_mapping_info(struct process_context *pr_ctxt,
-   u32 mpu_addr, u32 dsp_addr, u32 size)
+static struct dmm_map_object *create_mapping_info(u32 mpu_addr, u32 dsp_addr,
+   u32 size)
 {
struct dmm_map_object *map_obj;

@@ -144,11 +172,15 @@ static struct dmm_map_object
*add_mapping_info(struct process_context *pr_ctxt,
map_obj-size = size;
map_obj-num_usr_pgs = num_usr_pgs;

+   return map_obj;
+}
+
+static void add_mapping_info(struct process_context *pr_ctxt,
+   struct dmm_map_object *map_obj)
+{
spin_lock(pr_ctxt-dmm_map_lock);
list_add(map_obj-link, pr_ctxt-dmm_map_list);
spin_unlock(pr_ctxt-dmm_map_lock);
-
-   return map_obj;
 }

 static int match_exact_map_obj(struct dmm_map_object *map_obj,
@@ -162,10 +194,18 @@ static int match_exact_map_obj(struct
dmm_map_object *map_obj,
map_obj-size == size;
 }

-static void

[OMAP4] Cpufreq_utils on Android

2010-12-27 Thread sumeet linux 
Hi,

I am working on CPUFREQ governors for OMAP4 on android OS.
I need to check this CPUFREQ functionality (dynamic voltage and
frequency scaling).
I came across below utility,
http://elinux.org/OMAP_Power_Management#Cpufreq_utils
I tried different ways to build it with android platform code, but did
not get success.
If anyone had already used this utility for android platform kindly
share the info/steps.

Thanks in advance.

Regards,
Sumeet
--
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

2010-12-27 Thread Felipe Contreras 
o...@wizery.com wrote:
 On Tue, Dec 21, 2010 at 6:44 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
  Wouldn't you want the proc_*_dma() operations to finish before
  unmaping the pages?
 
 Yes, but that's not what your patch is doing exactly: it serializes
 the execution of proc_begin_dma(), proc_end_dma(), proc_map() and
 proc_un_map() using a single global mutex and by that prevents their
 concurrent execution (system-wide).
 
 I understand your intention: you don't want proc_un_map() to kick in
 in the middle of a proc_*_dma() operation. That's fine, but the patch
 has a side effect, which serializes the DMA operations themselves, and
 prevents their concurrent execution (even if they are for separate
 memory addresses, or invoked by different processes, etc...).

Yeah, but as I said, the proc_map() and proc_un_map() operations are
_already_ serialized, and those are the main operations used by both
gst-dsp, and TI's openmax, which are the only known users of this
driver.

So, effectively, serializing the proc_begin_dma() and proc_end_dma()
would not affect anyone negatively for the time being.

 Looking ahead, this DMM code is going to be extracted into an
 independent module, where it will be shared between dspbridge and
 syslink (the IPC framework for OMAP4 and forth): both projects use
 this DMM concept, and it won't make sense for syslink to duplicate the
 code. So even if today's dspbridge use cases doesn't have a lot of
 concurrency, and performance is satisfying even in light of your
 patch, we still want the code to be ready for more demanding use cases
 (several remote processors, several multimedia processes running on
 the host, several concurrent multimedia streams, etc...). If we use
 coarse-grained locking now, it will just make it harder to remove it
 later when scalability issues will show up (see the BKL removal
 efforts...).
 
 So I prefer we don't add any locking to the proc_*_dma() API at all.
 Instead, let's just take a reference count every time a map_obj is
 found (and therefore is about to be used), and release it after it is
 used. And now, inside proc_un_map(), if we notice that our map_obj is
 still being used, it means the application called us prematurely and
 we can't proceed. Something like (revised the patch from my previous
 email):

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

 diff --git a/drivers/staging/tidspbridge/include/dspbridge/drv.h
 b/drivers/staging/tidspbridge/include/dspbridge/drv.h
 index c1f363e..cad0626 100644
 --- a/drivers/staging/tidspbridge/include/dspbridge/drv.h
 +++ b/drivers/staging/tidspbridge/include/dspbridge/drv.h
 @@ -25,6 +25,7 @@
 
  #include dspbridge/drvdefs.h
  #include linux/idr.h
 +#include linux/atomic.h
 
  #define DRV_ASSIGN 1
  #define DRV_RELEASE0
 @@ -106,6 +107,7 @@ struct dmm_map_object {
 u32 num_usr_pgs;
 struct page **pages;
 struct bridge_dma_map_info dma_info;
 +   atomic_t refcnt;
  };
 
  /* Used for DMM reserved memory accounting */
 diff --git a/drivers/staging/tidspbridge/rmgr/proc.c
 b/drivers/staging/tidspbridge/rmgr/proc.c
 index b47d7aa..d060692 100644
 --- a/drivers/staging/tidspbridge/rmgr/proc.c
 +++ b/drivers/staging/tidspbridge/rmgr/proc.c
 @@ -112,9 +112,37 @@ static s32 get_envp_count(char **envp);
  static char **prepend_envp(char **new_envp, char **envp, s32 envp_elems,
s32 cnew_envp, char *sz_var);
 
 +/* Increase map_obj's reference count */
 +static inline void map_obj_get(struct dmm_map_object *map_obj)
 +{
 +   atomic_inc(map_obj-refcnt);
 +}
 +
 +/* Decrease map_obj's reference count */
 +static inline void map_obj_put(struct dmm_map_object *map_obj)
 +{
 +   atomic_dec(map_obj-refcnt);
 +}
 +
 +/**
 + * is_map_obj_used() - check out whether a given map_obj is still being used
 + * @map_obj:   a dmm map object
 + *
 + * Returns 'true' if a given map_obj is being used, or 'false' otherwise.
 + *
 + * This function must be used while the dmm map list spinlock is taken,
 + * otherwise it is not safe to use its answer (if the list is not locked,
 + * someone can find and start using a map_obj immediately after this 
 functions
 + * replys 'false'.
 + */
 +static inline bool is_map_obj_used(struct dmm_map_object *map_obj)
 +{
 +   return atomic_read(map_obj-refcnt) ? true : false;
 +}
 +
  /* remember mapping information */
 -static struct dmm_map_object *add_mapping_info(struct process_context 
 *pr_ctxt,
 -   u32 mpu_addr, u32 dsp_addr, u32 size)
 +static struct dmm_map_object *create_mapping_info(u32 mpu_addr, u32 dsp_addr,
 +

RE: omapfb: no driver for display error with linux-2.6.37-rc7

2010-12-27 Thread Janorkar, Mayuresh 
Felipe, Elvis,

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Elvis Dowson
 Sent: Monday, December 27, 2010 11:30 AM
 To: Felipe Contreras
 Cc: Linux OMAP Mailing List
 Subject: Re: omapfb: no driver for display error with linux-2.6.37-rc7
 
 
 On Dec 27, 2010, at 4:39 AM, Felipe Contreras wrote:
 
 
  [2.175872] omapfb omapfb: no driver for display
[Mayuresh]: This clearly shows that there is something went wrong in 
registering displays. So OMAPFB has not found any registered displays.

Try passing omapdss.debug=1, omapfb.debug=1 in your bootargs and the log would 
be self explanatory.

  [2.180999] omapfb omapfb: failed to setup omapfb
 
  My bootargs are as follows:
 
  mmcargs=setenv bootargs console=ttyO2,115200n8 vram=12M
 omapfb.vram=0:2M omapfb.mode=480x272mr...@60 root=/dev/mmcblk0p2 rw
 rootfstype=ext3 rootwait
 
  Do you have a proper CONFIG_OMAP2_VRAM_SIZE in your config?
 
 
 I've set the VRAM to 12, but the number of framebuffers to 1. Should it be
  1 ?
 
[Mayuresh]: No that should not matter. 12MB of vram for 1 FB is fine.
And your bootargs state that you need 480*272*2 Bytes of memory. So 12 MB of 
total VRAM size is more than enough.
But your bootargs state that you are providing only 2MB to FB0.
Please try using omapfb.vram=0:5M.
But if the problem is with the memory then OMAPFB would throw an error:
Failed to allocate memory. (Yet your kernel execution has not reached there).

 CONFIG_OMAP2_VRAM_SIZE=12
 CONFIG_FB_OMAP2=y
 CONFIG_FB_OMAP2_NUM_FBS=1
 
 
 I've pasted a section of my .config file below. This is with
 omap2plus_defconfig, for  a custom beagleboard.
 
 
 #
 # Graphics support
 #
 # CONFIG_DRM is not set
 # CONFIG_VGASTATE is not set
 # CONFIG_VIDEO_OUTPUT_CONTROL is not set
 CONFIG_FB=y
 CONFIG_FIRMWARE_EDID=y
 # CONFIG_FB_DDC is not set
 # CONFIG_FB_BOOT_VESA_SUPPORT is not set
 CONFIG_FB_CFB_FILLRECT=y
 CONFIG_FB_CFB_COPYAREA=y
 CONFIG_FB_CFB_IMAGEBLIT=y
 # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
 # CONFIG_FB_SYS_FILLRECT is not set
 # CONFIG_FB_SYS_COPYAREA is not set
 # CONFIG_FB_SYS_IMAGEBLIT is not set
 # CONFIG_FB_FOREIGN_ENDIAN is not set
 # CONFIG_FB_SYS_FOPS is not set
 # CONFIG_FB_SVGALIB is not set
 # CONFIG_FB_MACMODES is not set
 # CONFIG_FB_BACKLIGHT is not set
 CONFIG_FB_MODE_HELPERS=y
 CONFIG_FB_TILEBLITTING=y
 
 #
 # Frame buffer hardware drivers
 #
 # CONFIG_FB_ARMCLCD is not set
 # CONFIG_FB_UVESA is not set
 # CONFIG_FB_S1D13XXX is not set
 # CONFIG_FB_TMIO is not set
 # CONFIG_FB_VIRTUAL is not set
 # CONFIG_FB_METRONOME is not set
 # CONFIG_FB_MB862XX is not set
 # CONFIG_FB_BROADSHEET is not set
 # CONFIG_FB_OMAP_BOOTLOADER_INIT is not set
 CONFIG_OMAP2_VRAM=y
 CONFIG_OMAP2_VRFB=y
 CONFIG_OMAP2_DSS=y
 CONFIG_OMAP2_VRAM_SIZE=12
 CONFIG_OMAP2_DSS_DEBUG_SUPPORT=y
 # CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS is not set
 CONFIG_OMAP2_DSS_DPI=y
 # CONFIG_OMAP2_DSS_RFBI is not set
 CONFIG_OMAP2_DSS_VENC=y
 # CONFIG_OMAP2_DSS_SDI is not set
 # CONFIG_OMAP2_DSS_DSI is not set
 # CONFIG_OMAP2_DSS_FAKE_VSYNC is not set
 CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0
 CONFIG_FB_OMAP2=y
 # CONFIG_FB_OMAP2_DEBUG_SUPPORT is not set
 CONFIG_FB_OMAP2_NUM_FBS=1
 
 #
 # OMAP2/3 Display Device Drivers
 #
 # CONFIG_PANEL_GENERIC is not set
 # CONFIG_PANEL_SHARP_LS037V7DW01 is not set
 # CONFIG_PANEL_SHARP_LQ043T1DG01 is not set
 # CONFIG_PANEL_TOPPOLY_TDO35S is not set
 # CONFIG_PANEL_TPO_TD043MTEA1 is not set

[Mayuresh]: I guess, you need to enable atleast one panel driver over here.
Try enabling PANEL_GENERIC or SHARP_LS037V7DW01.

 CONFIG_BACKLIGHT_LCD_SUPPORT=y
 CONFIG_LCD_CLASS_DEVICE=y
 # CONFIG_LCD_L4F00242T03 is not set
 # CONFIG_LCD_LMS283GF05 is not set
 # CONFIG_LCD_LTV350QV is not set
 # CONFIG_LCD_TDO24M is not set
 # CONFIG_LCD_VGG2432A4 is not set
 CONFIG_LCD_PLATFORM=y
 # CONFIG_LCD_S6E63M0 is not set
 CONFIG_BACKLIGHT_CLASS_DEVICE=y
 CONFIG_BACKLIGHT_GENERIC=y
 # CONFIG_BACKLIGHT_ADP8860 is not set
 
 #
 # Display device support
 #
 CONFIG_DISPLAY_SUPPORT=y
 
 #
 # Display hardware drivers
 #
 
 #
 # Console display driver support
 #
 CONFIG_DUMMY_CONSOLE=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
 # CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
 CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
 CONFIG_FONTS=y
 CONFIG_FONT_8x8=y
 CONFIG_FONT_8x16=y
 # CONFIG_FONT_6x11 is not set
 # CONFIG_FONT_7x14 is not set
 # CONFIG_FONT_PEARL_8x8 is not set
 # CONFIG_FONT_ACORN_8x8 is not set
 # CONFIG_FONT_MINI_4x6 is not set
 # CONFIG_FONT_SUN8x16 is not set
 # CONFIG_FONT_SUN12x22 is not set
 # CONFIG_FONT_10x18 is not set
 # CONFIG_LOGO is not set
 
 
 Elvis Dowson
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at

Re: [QUESTION] what's the problem with CBUS ?

2010-12-27 Thread Felipe Balbi 

Adding Tony,

forgot initially

On Mon, Dec 27, 2010 at 07:13:09PM +0200, Felipe Balbi wrote:

Hi Tony,

What was the problem you saw with N810 which caused the need for
commit fc8c2f1dba400e9a0d1d82756e0e2f52dfe2f4b6, quoted below ?

I mean, looking into the code, all retu_rtc_do_reset() does is setup a
few default values on a few registers and that'll only be used if the
calibration register has a value of 'zero', so I'm suspecting something
(NOLO ?) toggles the gpio reset line on retu before giving control back
to kernel ?!?

Also, the rtc-reset_occured flag seems to be quite useless as it's
never read, only written.

When you figured you needed to disable retu_rtc_do_reset() did you get
any Kernel Oops or N810 simply got stuck ? If it got stuck, it could be
that nothing is calling complete(rtc-sync), which would mean no RTC
IRQ is happening after a reset.


Author: Tony Lindgren t...@atomide.com
Date:   Wed Nov 24 17:21:37 2010 -0800

   cbus: Disable retu_rtc_do_reset for now
   Otherwise interrupts get enabled too early.
   This is only a temporary fix to boot N810. For
   some reason N800 does not need this.
   Signed-off-by: Tony Lindgren t...@atomide.com

diff --git a/drivers/cbus/retu-rtc.c b/drivers/cbus/retu-rtc.c
index c0fe481..34fb689 100644
--- a/drivers/cbus/retu-rtc.c
+++ b/drivers/cbus/retu-rtc.c
@@ -309,9 +309,10 @@ static int __init retu_rtc_probe(struct platform_device 
*pdev)
* power */
   if (retu_read_reg(RETU_REG_RTCCALR)  0x00ff)
   rtc-reset_occurred = 0;
+#if 0
   else
   retu_rtc_do_reset(rtc);
-
+#endif
   rtc-rtc = rtc_device_register(pdev-name, pdev-dev, 
   retu_rtc_ops, THIS_MODULE);



--
balbi


--
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] TWD: enable one-shot mode

2010-12-27 Thread Linus Walleij 
2010/12/24 Russell King - ARM Linux li...@arm.linux.org.uk:
 Allow one shot timer mode to be used with the TWD.  This allows
 NOHZ mode to be used on SMP systems using the TWD localtimer.

 Tested on Versatile Express.

 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
 ---
 Acks/Tested-by's would be appreciated, thanks.

Tested on the U8500 and doesn't seem to break anything...

Local interrupts after a few minutes of use before patching
(and enabling NO_HZ):
LOC:   8203   8224

After patching;
LOC:233322

Looks like it's working, too.

Tested-by: Linus Walleij linus.wall...@stericsson.com

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

[PATCH 2/5] ASoC: DMIC codec: Adding a generic DMIC codec

2010-12-27 Thread David Lambert 
This codec is to be used by the DMIC driver to
control the DMIC codec.  This driver will be used on future implementations
of the DMIC driver to support codec specific features.

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

Signed-off-by: David Lambert dlamb...@ti.com
---
 sound/soc/codecs/dmic.c |   79 +++
 1 files changed, 79 insertions(+), 0 deletions(-)
 create mode 100644 sound/soc/codecs/dmic.c

diff --git a/sound/soc/codecs/dmic.c b/sound/soc/codecs/dmic.c
new file mode 100644
index 000..6f54bc5
--- /dev/null
+++ b/sound/soc/codecs/dmic.c
@@ -0,0 +1,79 @@
+/*
+ * dmic.c  --  SoC audio for Generic Digital MICs
+ *
+ * Author: Liam Girdwood l...@slimlogic.co.uk
+ *
+ * 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
+ *
+ */
+
+#include linux/platform_device.h
+#include linux/slab.h
+#include sound/core.h
+#include sound/pcm.h
+#include sound/soc.h
+#include sound/soc-dapm.h
+
+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,
+   },
+};
+
+static struct snd_soc_codec_driver soc_dmic = {};
+
+static int __devinit dmic_dev_probe(struct platform_device *pdev)
+{
+   return snd_soc_register_codec(pdev-dev,
+   soc_dmic, dmic_dai, 1);
+}
+
+static int __devexit dmic_dev_remove(struct platform_device *pdev)
+{
+   snd_soc_unregister_codec(pdev-dev);
+   return 0;
+}
+
+static struct platform_driver dmic_driver = {
+   .driver = {
+   .name = dmic-codec,
+   .owner = THIS_MODULE,
+   },
+   .probe = dmic_dev_probe,
+   .remove = __devexit_p(dmic_dev_remove),
+};
+
+static int __init dmic_init(void)
+{
+   return platform_driver_register(dmic_driver);
+}
+module_init(dmic_init);
+
+static void __exit dmic_exit(void)
+{
+   platform_driver_unregister(dmic_driver);
+}
+module_exit(dmic_exit);
+
+MODULE_DESCRIPTION(Generic DMIC driver);
+MODULE_AUTHOR(Liam Girdwood l...@slimlogic.co.uk);
+MODULE_LICENSE(GPL);
-- 
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

[PATCH 0/5] Adding OMAP DMIC driver to kernel

2010-12-27 Thread David Lambert 
This is a patch series to add the OMAP Digital Microphone
driver for OMAP4.

It includes the driver, a generic DMIC codec, platform devices,
as well as HWMOD entries for OMAP44xx chipsets.

David Lambert (5):
  ASoC: DMIC: Adding the OMAP DMIC driver
  ASoC: DMIC codec: Adding a generic DMIC codec
  ASoC: DMIC: Adding OMAP DMIC driver to build
  OMAP4: hwmod: add entries for DMIC driver
  MAP4: DMIC: Add DMIC codec platform devices

 arch/arm/mach-omap2/board-4430sdp.c|   11 +
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   91 +
 arch/arm/plat-omap/devices.c   |   35 ++
 arch/arm/plat-omap/include/plat/dmic.h |   83 
 sound/soc/codecs/Kconfig   |3 +
 sound/soc/codecs/Makefile  |2 +
 sound/soc/codecs/dmic.c|   79 
 sound/soc/omap/Kconfig |5 +
 sound/soc/omap/Makefile|2 +
 sound/soc/omap/omap-dmic.c |  596 
 sound/soc/omap/omap-dmic.h |   38 ++
 11 files changed, 945 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/plat-omap/include/plat/dmic.h
 create mode 100644 sound/soc/codecs/dmic.c
 create mode 100644 sound/soc/omap/omap-dmic.c
 create mode 100644 sound/soc/omap/omap-dmic.h

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

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

2010-12-27 Thread David Lambert 
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 ++
 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

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

2010-12-27 Thread David Lambert 
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
---
 arch/arm/mach-omap2/board-4430sdp.c |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

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,
+};
+
+static inline void omap_dmic_init(void)
+{
+   platform_device_register(codec_dmic0);
+}
+
 static void __init omap_4430sdp_init(void)
 {
int status;
@@ -528,6 +538,7 @@ static void __init omap_4430sdp_init(void)
spi_register_board_info(sdp4430_spi_board_info,
ARRAY_SIZE(sdp4430_spi_board_info));
}
+   omap_dmic_init();
 }
 
 static void __init omap_4430sdp_map_io(void)
-- 
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

2010-12-27 Thread Ohad Ben-Cohen 
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.

 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.

 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.

 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.

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

Thanks,
Ohad.
--
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