[PATCH 0/5] ASoC: OMAP4: Device tree support for DMIC, McPDM

[PATCH 0/5] ASoC: OMAP4: Device tree support for DMIC, McPDM

[Peter Ujfalusi]

Hello,

The following series adds device tree support for omap-dmic, omap-mcpdm ASoC
DAI drivers.

The OMAP4 platform patches have dependency on the DMIC driver series:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg59161.html

Regards,
Peter
---
Peter Ujfalusi (5):
  ASoC: omap-dmic: Add device tree bindings
  ASoC: omap-mcpdm: Add device tree bindings
  OMAP4: devices: Do not create dmic device if the dtb has been
    provided
  OMAP4: devices: Do not create mcpdm device if the dtb has been
    provided
  ARM: OMAP4: DTS: Support for dmic, and McPDM in device tree

 .../bindings/sound/soc/omap/omap-dmic.txt          |   13 +++++++++++++
 .../bindings/sound/soc/omap/omap-mcpdm.txt         |   13 +++++++++++++
 arch/arm/boot/dts/omap4-panda.dts                  |    4 ++++
 arch/arm/boot/dts/omap4.dtsi                       |    9 +++++++++
 arch/arm/mach-omap2/devices.c                      |    8 ++++++++
 sound/soc/omap/omap-dmic.c                         |    8 ++++++++
 sound/soc/omap/omap-mcpdm.c                        |    8 ++++++++
 7 files changed, 63 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/soc/omap/omap-dmic.txt
 create mode 100644 Documentation/devicetree/bindings/sound/soc/omap/omap-mcpdm.txt

-- 
1.7.8.rc4

[PATCH 0/5] ASoC: OMAP4: Device tree support for DMIC, McPDM

[Peter Ujfalusi]

Hello,

The following series adds device tree support for omap-dmic, omap-mcpdm ASoC
DAI drivers.

The OMAP4 platform patches have dependency on the DMIC driver series:
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg59161.html

Regards,
Peter
---
Peter Ujfalusi (5):
  ASoC: omap-dmic: Add device tree bindings
  ASoC: omap-mcpdm: Add device tree bindings
  OMAP4: devices: Do not create dmic device if the dtb has been
    provided
  OMAP4: devices: Do not create mcpdm device if the dtb has been
    provided
  ARM: OMAP4: DTS: Support for dmic, and McPDM in device tree

 .../bindings/sound/soc/omap/omap-dmic.txt          |   13 +++++++++++++
 .../bindings/sound/soc/omap/omap-mcpdm.txt         |   13 +++++++++++++
 arch/arm/boot/dts/omap4-panda.dts                  |    4 ++++
 arch/arm/boot/dts/omap4.dtsi                       |    9 +++++++++
 arch/arm/mach-omap2/devices.c                      |    8 ++++++++
 sound/soc/omap/omap-dmic.c                         |    8 ++++++++
 sound/soc/omap/omap-mcpdm.c                        |    8 ++++++++
 7 files changed, 63 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/soc/omap/omap-dmic.txt
 create mode 100644 Documentation/devicetree/bindings/sound/soc/omap/omap-mcpdm.txt

-- 
1.7.8.rc4

[PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Peter Ujfalusi]

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 .../bindings/sound/soc/omap/omap-dmic.txt          |   13 +++++++++++++
 sound/soc/omap/omap-dmic.c                         |    8 ++++++++
 2 files changed, 21 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/soc/omap/omap-dmic.txt

diff --git a/Documentation/devicetree/bindings/sound/soc/omap/omap-dmic.txt b/Documentation/devicetree/bindings/sound/soc/omap/omap-dmic.txt
new file mode 100644
index 0000000..f6d9e66
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/soc/omap/omap-dmic.txt
@@ -0,0 +1,13 @@
+* Texas Instruments OMAP4 Digital Microphone Module
+
+Required properties:
+  - compatible : "ti,omap4-dmic"
+  - ti,hwmods  : List of hwmod names associated with DMIC, in most case
+		 it is "dmic".
+
+Example:
+
+dmic_dai: dmic@4012e000 {
+	compatible = "ti,omap4-dmic";
+	ti,hwmods = "dmic";
+};
diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
index 9c73c0c..b71bd11 100644
--- a/sound/soc/omap/omap-dmic.c
+++ b/sound/soc/omap/omap-dmic.c
@@ -32,6 +32,7 @@
 #include <linux/io.h>
 #include <linux/slab.h>
 #include <linux/pm_runtime.h>
+#include <linux/of_device.h>
 #include <plat/dma.h>
 
 #include <sound/core.h>
@@ -532,10 +533,17 @@ static int __devexit asoc_dmic_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id omap_dmic_of_match[] = {
+	{ .compatible = "ti,omap4-dmic", },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, omap_dmic_of_match);
+
 static struct platform_driver asoc_dmic_driver = {
 	.driver = {
 		.name = "omap-dmic",
 		.owner = THIS_MODULE,
+		.of_match_table = omap_dmic_of_match,
 	},
 	.probe = asoc_dmic_probe,
 	.remove = __devexit_p(asoc_dmic_remove),
-- 
1.7.8.rc4

[PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Peter Ujfalusi]

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 .../bindings/sound/soc/omap/omap-dmic.txt          |   13 +++++++++++++
 sound/soc/omap/omap-dmic.c                         |    8 ++++++++
 2 files changed, 21 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/soc/omap/omap-dmic.txt

diff --git a/Documentation/devicetree/bindings/sound/soc/omap/omap-dmic.txt b/Documentation/devicetree/bindings/sound/soc/omap/omap-dmic.txt
new file mode 100644
index 0000000..f6d9e66
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/soc/omap/omap-dmic.txt
@@ -0,0 +1,13 @@
+* Texas Instruments OMAP4 Digital Microphone Module
+
+Required properties:
+  - compatible : "ti,omap4-dmic"
+  - ti,hwmods  : List of hwmod names associated with DMIC, in most case
+		 it is "dmic".
+
+Example:
+
+dmic_dai: dmic at 4012e000 {
+	compatible = "ti,omap4-dmic";
+	ti,hwmods = "dmic";
+};
diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
index 9c73c0c..b71bd11 100644
--- a/sound/soc/omap/omap-dmic.c
+++ b/sound/soc/omap/omap-dmic.c
@@ -32,6 +32,7 @@
 #include <linux/io.h>
 #include <linux/slab.h>
 #include <linux/pm_runtime.h>
+#include <linux/of_device.h>
 #include <plat/dma.h>
 
 #include <sound/core.h>
@@ -532,10 +533,17 @@ static int __devexit asoc_dmic_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id omap_dmic_of_match[] = {
+	{ .compatible = "ti,omap4-dmic", },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, omap_dmic_of_match);
+
 static struct platform_driver asoc_dmic_driver = {
 	.driver = {
 		.name = "omap-dmic",
 		.owner = THIS_MODULE,
+		.of_match_table = omap_dmic_of_match,
 	},
 	.probe = asoc_dmic_probe,
 	.remove = __devexit_p(asoc_dmic_remove),
-- 
1.7.8.rc4

Re: [PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Mark Brown]

On Fri, Dec 02, 2011 at 11:52:56AM +0200, Peter Ujfalusi wrote:

> +Required properties:
> +  - compatible : "ti,omap4-dmic"
> +  - ti,hwmods  : List of hwmod names associated with DMIC, in most case
> +		 it is "dmic".

Shouldn't there also be a regs property giving the register window?

[PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Mark Brown]

On Fri, Dec 02, 2011 at 11:52:56AM +0200, Peter Ujfalusi wrote:

> +Required properties:
> +  - compatible : "ti,omap4-dmic"
> +  - ti,hwmods  : List of hwmod names associated with DMIC, in most case
> +		 it is "dmic".

Shouldn't there also be a regs property giving the register window?

Re: [PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Cousson, Benoit]

On 12/2/2011 1:25 PM, Mark Brown wrote:
> On Fri, Dec 02, 2011 at 11:52:56AM +0200, Peter Ujfalusi wrote:
>
>> +Required properties:
>> +  - compatible : "ti,omap4-dmic"
>> +  - ti,hwmods  : List of hwmod names associated with DMIC, in most case
>> +		 it is "dmic".
>
> Shouldn't there also be a regs property giving the register window?

Not for the moment, because we are still using the hwmod database to 
retrieve the base address + irq + dma.

I need to have the support for resource name before replacing the hwmod 
data by a real "reg" + "reg-names" attributes.

I'll send a series with that ASAP.

Regards,
Benoit

[PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Cousson, Benoit]

On 12/2/2011 1:25 PM, Mark Brown wrote:
> On Fri, Dec 02, 2011 at 11:52:56AM +0200, Peter Ujfalusi wrote:
>
>> +Required properties:
>> +  - compatible : "ti,omap4-dmic"
>> +  - ti,hwmods  : List of hwmod names associated with DMIC, in most case
>> +		 it is "dmic".
>
> Shouldn't there also be a regs property giving the register window?

Not for the moment, because we are still using the hwmod database to 
retrieve the base address + irq + dma.

I need to have the support for resource name before replacing the hwmod 
data by a real "reg" + "reg-names" attributes.

I'll send a series with that ASAP.

Regards,
Benoit

Re: [PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Peter Ujfalusi]

On 12/02/2011 02:25 PM, Mark Brown wrote:
> On Fri, Dec 02, 2011 at 11:52:56AM +0200, Peter Ujfalusi wrote:
> 
>> +Required properties:
>> +  - compatible : "ti,omap4-dmic"
>> +  - ti,hwmods  : List of hwmod names associated with DMIC, in most case
>> +		 it is "dmic".
> 
> Shouldn't there also be a regs property giving the register window?

As of now we receive all these information via OMAP hwmod.
All the properties (addresses, irq, etc) of the HW IP will be coming
from DT as soon as I can remove the ti,hwmod property.

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

[PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Peter Ujfalusi]

On 12/02/2011 02:25 PM, Mark Brown wrote:
> On Fri, Dec 02, 2011 at 11:52:56AM +0200, Peter Ujfalusi wrote:
> 
>> +Required properties:
>> +  - compatible : "ti,omap4-dmic"
>> +  - ti,hwmods  : List of hwmod names associated with DMIC, in most case
>> +		 it is "dmic".
> 
> Shouldn't there also be a regs property giving the register window?

As of now we receive all these information via OMAP hwmod.
All the properties (addresses, irq, etc) of the HW IP will be coming
from DT as soon as I can remove the ti,hwmod property.

-- 
P?ter

Re: [PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Mark Brown]

On Fri, Dec 02, 2011 at 02:32:59PM +0200, Peter Ujfalusi wrote:

> As of now we receive all these information via OMAP hwmod.
> All the properties (addresses, irq, etc) of the HW IP will be coming
> from DT as soon as I can remove the ti,hwmod property.

Oh, right.  We should really be churning the device tree like this - the
idea is that the device tree should be stable and independant of kernel
versions.  It would be better if we were able to go straight to the one
without hwmod, especially if Benoit is able to get the underlying
changes done soon (which sounded like it might be the case).  Could we
define and implement the "real" version now (it should be reasonable to
code blind except possibly for the DMA channel as it's such a direct
mapping) with hwmod left in there as something that's legacy for old
kernels?

[PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Mark Brown]

On Fri, Dec 02, 2011 at 02:32:59PM +0200, Peter Ujfalusi wrote:

> As of now we receive all these information via OMAP hwmod.
> All the properties (addresses, irq, etc) of the HW IP will be coming
> from DT as soon as I can remove the ti,hwmod property.

Oh, right.  We should really be churning the device tree like this - the
idea is that the device tree should be stable and independant of kernel
versions.  It would be better if we were able to go straight to the one
without hwmod, especially if Benoit is able to get the underlying
changes done soon (which sounded like it might be the case).  Could we
define and implement the "real" version now (it should be reasonable to
code blind except possibly for the DMA channel as it's such a direct
mapping) with hwmod left in there as something that's legacy for old
kernels?

Re: [PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Cousson, Benoit]

On 12/2/2011 2:02 PM, Mark Brown wrote:
> On Fri, Dec 02, 2011 at 02:32:59PM +0200, Peter Ujfalusi wrote:
>
>> As of now we receive all these information via OMAP hwmod.
>> All the properties (addresses, irq, etc) of the HW IP will be coming
>> from DT as soon as I can remove the ti,hwmod property.
>
> Oh, right.  We should really be churning the device tree like this - the
> idea is that the device tree should be stable and independant of kernel
> versions.  It would be better if we were able to go straight to the one
> without hwmod, especially if Benoit is able to get the underlying
> changes done soon (which sounded like it might be the case).

I wish it were that easy... but there are too many bindings that are not 
yet there in DT core.

Even if the reg-names and interrupts-names are accepted, which is still 
not obvious due to a little bit of resistance, we still do not have dma 
request bindings, nor clock bindings, nor pin mux.
All these information are provided today by hwmod, so it will still be 
there for a couple of more merge windows.

The important point for me, it to avoid having to change the driver 
whenever these bindings will be there. This will be OK today for reg and 
interrupts since they both go through Linux resources.

> Could we define and implement the "real" version now (it should be reasonable to
> code blind except possibly for the DMA channel as it's such a direct
> mapping) with hwmod left in there as something that's legacy for old
> kernels?

I think DT churn is unavoidable due to the ongoing effort to add clock, 
regulator, dma, pin mux into DT core.
I don't think we should wait to have all that ready to start migrating 
to DT.

Regards,
Benoit

[PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Cousson, Benoit]

On 12/2/2011 2:02 PM, Mark Brown wrote:
> On Fri, Dec 02, 2011 at 02:32:59PM +0200, Peter Ujfalusi wrote:
>
>> As of now we receive all these information via OMAP hwmod.
>> All the properties (addresses, irq, etc) of the HW IP will be coming
>> from DT as soon as I can remove the ti,hwmod property.
>
> Oh, right.  We should really be churning the device tree like this - the
> idea is that the device tree should be stable and independant of kernel
> versions.  It would be better if we were able to go straight to the one
> without hwmod, especially if Benoit is able to get the underlying
> changes done soon (which sounded like it might be the case).

I wish it were that easy... but there are too many bindings that are not 
yet there in DT core.

Even if the reg-names and interrupts-names are accepted, which is still 
not obvious due to a little bit of resistance, we still do not have dma 
request bindings, nor clock bindings, nor pin mux.
All these information are provided today by hwmod, so it will still be 
there for a couple of more merge windows.

The important point for me, it to avoid having to change the driver 
whenever these bindings will be there. This will be OK today for reg and 
interrupts since they both go through Linux resources.

> Could we define and implement the "real" version now (it should be reasonable to
> code blind except possibly for the DMA channel as it's such a direct
> mapping) with hwmod left in there as something that's legacy for old
> kernels?

I think DT churn is unavoidable due to the ongoing effort to add clock, 
regulator, dma, pin mux into DT core.
I don't think we should wait to have all that ready to start migrating 
to DT.

Regards,
Benoit

Re: [PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Mark Brown]

On Fri, Dec 02, 2011 at 02:31:13PM +0100, Cousson, Benoit wrote:

> Even if the reg-names and interrupts-names are accepted, which is
> still not obvious due to a little bit of resistance, we still do not

Yeah, it seems like there's very little traction on any of the problems
with legacy bindings that device tree has.  

> have dma request bindings, nor clock bindings, nor pin mux.
> All these information are provided today by hwmod, so it will still
> be there for a couple of more merge windows.

At least the DMA bindings seem fairly well sorted - we just merged the
Tegra audio bindings which define a Tegra property for the DMA request
signal.  There's a reasonable amount of variation in how these things
get plumbed together.

> The important point for me, it to avoid having to change the driver
> whenever these bindings will be there. This will be OK today for reg
> and interrupts since they both go through Linux resources.

This is also OK for clocks since they'll go through the clock API so
nothing needs doing there either.

> >Could we define and implement the "real" version now (it should be reasonable to
> >code blind except possibly for the DMA channel as it's such a direct
> >mapping) with hwmod left in there as something that's legacy for old
> >kernels?

> I think DT churn is unavoidable due to the ongoing effort to add
> clock, regulator, dma, pin mux into DT core.
> I don't think we should wait to have all that ready to start
> migrating to DT.

Well, it does make the whole process a bit silly.  If we're planning to
discard hwmod it seems like we shouldn't be transitioning it into device
tree in the first place and instead just add the new properties to the
bindings as we go.  If hwmod must go into the device tree somehow is it
not possible to keep the hwmod data in its own binding (referencing the
nodes it affects rather than being in their bindings).

[PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Mark Brown]

On Fri, Dec 02, 2011 at 02:31:13PM +0100, Cousson, Benoit wrote:

> Even if the reg-names and interrupts-names are accepted, which is
> still not obvious due to a little bit of resistance, we still do not

Yeah, it seems like there's very little traction on any of the problems
with legacy bindings that device tree has.  

> have dma request bindings, nor clock bindings, nor pin mux.
> All these information are provided today by hwmod, so it will still
> be there for a couple of more merge windows.

At least the DMA bindings seem fairly well sorted - we just merged the
Tegra audio bindings which define a Tegra property for the DMA request
signal.  There's a reasonable amount of variation in how these things
get plumbed together.

> The important point for me, it to avoid having to change the driver
> whenever these bindings will be there. This will be OK today for reg
> and interrupts since they both go through Linux resources.

This is also OK for clocks since they'll go through the clock API so
nothing needs doing there either.

> >Could we define and implement the "real" version now (it should be reasonable to
> >code blind except possibly for the DMA channel as it's such a direct
> >mapping) with hwmod left in there as something that's legacy for old
> >kernels?

> I think DT churn is unavoidable due to the ongoing effort to add
> clock, regulator, dma, pin mux into DT core.
> I don't think we should wait to have all that ready to start
> migrating to DT.

Well, it does make the whole process a bit silly.  If we're planning to
discard hwmod it seems like we shouldn't be transitioning it into device
tree in the first place and instead just add the new properties to the
bindings as we go.  If hwmod must go into the device tree somehow is it
not possible to keep the hwmod data in its own binding (referencing the
nodes it affects rather than being in their bindings).

Re: [PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Cousson, Benoit]

On 12/2/2011 3:00 PM, Mark Brown wrote:
> On Fri, Dec 02, 2011 at 02:31:13PM +0100, Cousson, Benoit wrote:
>
>> Even if the reg-names and interrupts-names are accepted, which is
>> still not obvious due to a little bit of resistance, we still do not
>
> Yeah, it seems like there's very little traction on any of the problems
> with legacy bindings that device tree has.
>
>> have dma request bindings, nor clock bindings, nor pin mux.
>> All these information are provided today by hwmod, so it will still
>> be there for a couple of more merge windows.
>
> At least the DMA bindings seem fairly well sorted - we just merged the
> Tegra audio bindings which define a Tegra property for the DMA request
> signal.  There's a reasonable amount of variation in how these things
> get plumbed together.

Mmm, I missed that series, but I'm not sure it is doing the right thing.
- First the name is missing :-(
- Secondly a dma-channel is not a dma-request... So I'm not sure what 
that series is supposed to add...
I should reply on that, thanks for pointing this series.

>> The important point for me, it to avoid having to change the driver
>> whenever these bindings will be there. This will be OK today for reg
>> and interrupts since they both go through Linux resources.
>
> This is also OK for clocks since they'll go through the clock API so
> nothing needs doing there either.

Yep, my point was about the DT churn that this will generate.

>>> Could we define and implement the "real" version now (it should be reasonable to
>>> code blind except possibly for the DMA channel as it's such a direct
>>> mapping) with hwmod left in there as something that's legacy for old
>>> kernels?
>
>> I think DT churn is unavoidable due to the ongoing effort to add
>> clock, regulator, dma, pin mux into DT core.
>> I don't think we should wait to have all that ready to start
>> migrating to DT.
>
> Well, it does make the whole process a bit silly.  If we're planning to
> discard hwmod it seems like we shouldn't be transitioning it into device
> tree in the first place and instead just add the new properties to the
> bindings as we go.  If hwmod must go into the device tree somehow is it
> not possible to keep the hwmod data in its own binding (referencing the
> nodes it affects rather than being in their bindings).

Yeah, maybe, but it was done like that due to a bunch of constraints and 
mainly because a lot a binding were missing. The other issue is that we 
still do not know what will remain in the hwmod data and where it should go.
So this idea was to do that in several phases in order to allow people 
adapting their drivers without having to wait the DT + OMAP core stuff 
to completely sorted out.

At the end, the effort should be only at OMAP core level, so the driver 
should not be affected if we decide to move hwmod stuff into DT or not.

At least, that's the idea.

Regards,
Benoit

[PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Cousson, Benoit]

On 12/2/2011 3:00 PM, Mark Brown wrote:
> On Fri, Dec 02, 2011 at 02:31:13PM +0100, Cousson, Benoit wrote:
>
>> Even if the reg-names and interrupts-names are accepted, which is
>> still not obvious due to a little bit of resistance, we still do not
>
> Yeah, it seems like there's very little traction on any of the problems
> with legacy bindings that device tree has.
>
>> have dma request bindings, nor clock bindings, nor pin mux.
>> All these information are provided today by hwmod, so it will still
>> be there for a couple of more merge windows.
>
> At least the DMA bindings seem fairly well sorted - we just merged the
> Tegra audio bindings which define a Tegra property for the DMA request
> signal.  There's a reasonable amount of variation in how these things
> get plumbed together.

Mmm, I missed that series, but I'm not sure it is doing the right thing.
- First the name is missing :-(
- Secondly a dma-channel is not a dma-request... So I'm not sure what 
that series is supposed to add...
I should reply on that, thanks for pointing this series.

>> The important point for me, it to avoid having to change the driver
>> whenever these bindings will be there. This will be OK today for reg
>> and interrupts since they both go through Linux resources.
>
> This is also OK for clocks since they'll go through the clock API so
> nothing needs doing there either.

Yep, my point was about the DT churn that this will generate.

>>> Could we define and implement the "real" version now (it should be reasonable to
>>> code blind except possibly for the DMA channel as it's such a direct
>>> mapping) with hwmod left in there as something that's legacy for old
>>> kernels?
>
>> I think DT churn is unavoidable due to the ongoing effort to add
>> clock, regulator, dma, pin mux into DT core.
>> I don't think we should wait to have all that ready to start
>> migrating to DT.
>
> Well, it does make the whole process a bit silly.  If we're planning to
> discard hwmod it seems like we shouldn't be transitioning it into device
> tree in the first place and instead just add the new properties to the
> bindings as we go.  If hwmod must go into the device tree somehow is it
> not possible to keep the hwmod data in its own binding (referencing the
> nodes it affects rather than being in their bindings).

Yeah, maybe, but it was done like that due to a bunch of constraints and 
mainly because a lot a binding were missing. The other issue is that we 
still do not know what will remain in the hwmod data and where it should go.
So this idea was to do that in several phases in order to allow people 
adapting their drivers without having to wait the DT + OMAP core stuff 
to completely sorted out.

At the end, the effort should be only at OMAP core level, so the driver 
should not be affected if we decide to move hwmod stuff into DT or not.

At least, that's the idea.

Regards,
Benoit

Re: [PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Mark Brown]

On Fri, Dec 02, 2011 at 03:59:01PM +0100, Cousson, Benoit wrote:
> On 12/2/2011 3:00 PM, Mark Brown wrote:

> >At least the DMA bindings seem fairly well sorted - we just merged the
> >Tegra audio bindings which define a Tegra property for the DMA request
> >signal.  There's a reasonable amount of variation in how these things
> >get plumbed together.

> Mmm, I missed that series, but I'm not sure it is doing the right thing.
> - First the name is missing :-(
> - Secondly a dma-channel is not a dma-request... So I'm not sure
> what that series is supposed to add...

The idea is that the thing going into the block is the request line,
this is sufficient to identify to the DMA controller code which hardware
is being talked about.

> >This is also OK for clocks since they'll go through the clock API so
> >nothing needs doing there either.

> Yep, my point was about the DT churn that this will generate.

Adding new things isn't churn in quite the same way - extending bindings
is a more natural process than dropping old bits of binding.

> At the end, the effort should be only at OMAP core level, so the
> driver should not be affected if we decide to move hwmod stuff into
> DT or not.

Well, the binding will at least need to be updated.  Though of course
if we manage to ship the DTS for the OMAP with the kernel then it won't
really matter if we churn the binding and we may as well not document it
at all, treating it as an internal part of the kernel that happens to go
through device tree.

[PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Mark Brown]

On Fri, Dec 02, 2011 at 03:59:01PM +0100, Cousson, Benoit wrote:
> On 12/2/2011 3:00 PM, Mark Brown wrote:

> >At least the DMA bindings seem fairly well sorted - we just merged the
> >Tegra audio bindings which define a Tegra property for the DMA request
> >signal.  There's a reasonable amount of variation in how these things
> >get plumbed together.

> Mmm, I missed that series, but I'm not sure it is doing the right thing.
> - First the name is missing :-(
> - Secondly a dma-channel is not a dma-request... So I'm not sure
> what that series is supposed to add...

The idea is that the thing going into the block is the request line,
this is sufficient to identify to the DMA controller code which hardware
is being talked about.

> >This is also OK for clocks since they'll go through the clock API so
> >nothing needs doing there either.

> Yep, my point was about the DT churn that this will generate.

Adding new things isn't churn in quite the same way - extending bindings
is a more natural process than dropping old bits of binding.

> At the end, the effort should be only at OMAP core level, so the
> driver should not be affected if we decide to move hwmod stuff into
> DT or not.

Well, the binding will at least need to be updated.  Though of course
if we manage to ship the DTS for the OMAP with the kernel then it won't
really matter if we churn the binding and we may as well not document it
at all, treating it as an internal part of the kernel that happens to go
through device tree.

Re: [PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Mark Brown]

On Fri, Dec 02, 2011 at 11:52:56AM +0200, Peter Ujfalusi wrote:

> @@ -0,0 +1,13 @@
> +* Texas Instruments OMAP4 Digital Microphone Module
> +
> +Required properties:
> +  - compatible : "ti,omap4-dmic"
> +  - ti,hwmods  : List of hwmod names associated with DMIC, in most case
> +		 it is "dmic".

Actually thinking about this some more I think what's concerning me is
the documentation as much as anything else - if it was just an internal,
unpublished interface of the OMAP core code which happened to use device
tree I probably wouldn't have worried about it churning.

[PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Mark Brown]

On Fri, Dec 02, 2011 at 11:52:56AM +0200, Peter Ujfalusi wrote:

> @@ -0,0 +1,13 @@
> +* Texas Instruments OMAP4 Digital Microphone Module
> +
> +Required properties:
> +  - compatible : "ti,omap4-dmic"
> +  - ti,hwmods  : List of hwmod names associated with DMIC, in most case
> +		 it is "dmic".

Actually thinking about this some more I think what's concerning me is
the documentation as much as anything else - if it was just an internal,
unpublished interface of the OMAP core code which happened to use device
tree I probably wouldn't have worried about it churning.

Re: [PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Peter Ujfalusi]

On 12/03/2011 01:22 PM, Mark Brown wrote:
> On Fri, Dec 02, 2011 at 11:52:56AM +0200, Peter Ujfalusi wrote:
> 
>> @@ -0,0 +1,13 @@
>> +* Texas Instruments OMAP4 Digital Microphone Module
>> +
>> +Required properties:
>> +  - compatible : "ti,omap4-dmic"
>> +  - ti,hwmods  : List of hwmod names associated with DMIC, in most case
>> +		 it is "dmic".
> 
> Actually thinking about this some more I think what's concerning me is
> the documentation as much as anything else - if it was just an internal,
> unpublished interface of the OMAP core code which happened to use device
> tree I probably wouldn't have worried about it churning.

Actually it is documented here:
Documentation/devicetree/bindings/arm/omap/omap.txt

In order to move all OMAP drivers to DT - as Benoit already mentioned -
we need additional work in DT.
At this point of time if we add the DT representation we anyways need to
change it as the core will receive the features, and we still need to
fall back to hwmod to get the drivers working.
As soon as we can migrate away from the hwmod we will do, but having
this in place helps us to migrate other parts to DT.

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

[PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Peter Ujfalusi]

On 12/03/2011 01:22 PM, Mark Brown wrote:
> On Fri, Dec 02, 2011 at 11:52:56AM +0200, Peter Ujfalusi wrote:
> 
>> @@ -0,0 +1,13 @@
>> +* Texas Instruments OMAP4 Digital Microphone Module
>> +
>> +Required properties:
>> +  - compatible : "ti,omap4-dmic"
>> +  - ti,hwmods  : List of hwmod names associated with DMIC, in most case
>> +		 it is "dmic".
> 
> Actually thinking about this some more I think what's concerning me is
> the documentation as much as anything else - if it was just an internal,
> unpublished interface of the OMAP core code which happened to use device
> tree I probably wouldn't have worried about it churning.

Actually it is documented here:
Documentation/devicetree/bindings/arm/omap/omap.txt

In order to move all OMAP drivers to DT - as Benoit already mentioned -
we need additional work in DT.
At this point of time if we add the DT representation we anyways need to
change it as the core will receive the features, and we still need to
fall back to hwmod to get the drivers working.
As soon as we can migrate away from the hwmod we will do, but having
this in place helps us to migrate other parts to DT.

-- 
P?ter

Re: [PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Mark Brown]

On Mon, Dec 05, 2011 at 03:45:04PM +0200, Peter Ujfalusi wrote:
> On 12/03/2011 01:22 PM, Mark Brown wrote:

> > Actually thinking about this some more I think what's concerning me is
> > the documentation as much as anything else - if it was just an internal,
> > unpublished interface of the OMAP core code which happened to use device
> > tree I probably wouldn't have worried about it churning.

> Actually it is documented here:
> Documentation/devicetree/bindings/arm/omap/omap.txt

That's not exactly the point...

> In order to move all OMAP drivers to DT - as Benoit already mentioned -
> we need additional work in DT.
> At this point of time if we add the DT representation we anyways need to
> change it as the core will receive the features, and we still need to
> fall back to hwmod to get the drivers working.
> As soon as we can migrate away from the hwmod we will do, but having
> this in place helps us to migrate other parts to DT.

And what I'm saying is that my main concern is that you're publishing
documenting a binding which isn't intended to be the the final binding
and which there's no intention that anyone should use directly anyway.

[PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Mark Brown]

On Mon, Dec 05, 2011 at 03:45:04PM +0200, Peter Ujfalusi wrote:
> On 12/03/2011 01:22 PM, Mark Brown wrote:

> > Actually thinking about this some more I think what's concerning me is
> > the documentation as much as anything else - if it was just an internal,
> > unpublished interface of the OMAP core code which happened to use device
> > tree I probably wouldn't have worried about it churning.

> Actually it is documented here:
> Documentation/devicetree/bindings/arm/omap/omap.txt

That's not exactly the point...

> In order to move all OMAP drivers to DT - as Benoit already mentioned -
> we need additional work in DT.
> At this point of time if we add the DT representation we anyways need to
> change it as the core will receive the features, and we still need to
> fall back to hwmod to get the drivers working.
> As soon as we can migrate away from the hwmod we will do, but having
> this in place helps us to migrate other parts to DT.

And what I'm saying is that my main concern is that you're publishing
documenting a binding which isn't intended to be the the final binding
and which there's no intention that anyone should use directly anyway.

Re: [PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Peter Ujfalusi]

On 12/05/2011 05:46 PM, Mark Brown wrote:
> And what I'm saying is that my main concern is that you're publishing
> documenting a binding which isn't intended to be the the final binding
> and which there's no intention that anyone should use directly anyway.

I felt it is the right thing to document the current situation.
The documentation will be updated as we can move away from the
"ti,hwmods" tag from DT.
I can place comment in the documentation for omap-dmic, omap-mcpdm
stating that the use of "ti,hwmods" is required at the moment, but it is
temporally solution.

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

[PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Peter Ujfalusi]

On 12/05/2011 05:46 PM, Mark Brown wrote:
> And what I'm saying is that my main concern is that you're publishing
> documenting a binding which isn't intended to be the the final binding
> and which there's no intention that anyone should use directly anyway.

I felt it is the right thing to document the current situation.
The documentation will be updated as we can move away from the
"ti,hwmods" tag from DT.
I can place comment in the documentation for omap-dmic, omap-mcpdm
stating that the use of "ti,hwmods" is required at the moment, but it is
temporally solution.

-- 
P?ter

Re: [PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Mark Brown]

On Wed, Dec 07, 2011 at 10:45:25AM +0200, Peter Ujfalusi wrote:

> I felt it is the right thing to document the current situation.

If we're going to document bindings like this it feels like we should
have a split in the directories in the same way that we handle the
different stability levels for sysfs documentation.

> The documentation will be updated as we can move away from the
> "ti,hwmods" tag from DT.
> I can place comment in the documentation for omap-dmic, omap-mcpdm
> stating that the use of "ti,hwmods" is required at the moment, but it is
> temporally solution.

At the very least, yes.

[PATCH 1/5] ASoC: omap-dmic: Add device tree bindings

[Mark Brown]

On Wed, Dec 07, 2011 at 10:45:25AM +0200, Peter Ujfalusi wrote:

> I felt it is the right thing to document the current situation.

If we're going to document bindings like this it feels like we should
have a split in the directories in the same way that we handle the
different stability levels for sysfs documentation.

> The documentation will be updated as we can move away from the
> "ti,hwmods" tag from DT.
> I can place comment in the documentation for omap-dmic, omap-mcpdm
> stating that the use of "ti,hwmods" is required at the moment, but it is
> temporally solution.

At the very least, yes.

[PATCH 2/5] ASoC: omap-mcpdm: Add device tree bindings

[Peter Ujfalusi]

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 .../bindings/sound/soc/omap/omap-mcpdm.txt         |   13 +++++++++++++
 sound/soc/omap/omap-mcpdm.c                        |    8 ++++++++
 2 files changed, 21 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/soc/omap/omap-mcpdm.txt

diff --git a/Documentation/devicetree/bindings/sound/soc/omap/omap-mcpdm.txt b/Documentation/devicetree/bindings/sound/soc/omap/omap-mcpdm.txt
new file mode 100644
index 0000000..e94bb96
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/soc/omap/omap-mcpdm.txt
@@ -0,0 +1,13 @@
+* Texas Instruments OMAP4 McPDM
+
+Required properties:
+  - compatible : "ti,omap4-mcpdm"
+  - ti,hwmods  : List of hwmod names associated with McPDM, in most case
+                 it is "mcpdm".
+
+Example:
+
+mcpdm_dai: mcpdm@40132000 {
+	compatible = "ti,omap4-mcpdm";
+	ti,hwmods = "mcpdm";
+};
diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
index b50ac60..c95fc70 100644
--- a/sound/soc/omap/omap-mcpdm.c
+++ b/sound/soc/omap/omap-mcpdm.c
@@ -33,6 +33,7 @@
 #include <linux/irq.h>
 #include <linux/slab.h>
 #include <linux/pm_runtime.h>
+#include <linux/of_device.h>
 
 #include <sound/core.h>
 #include <sound/pcm.h>
@@ -510,10 +511,17 @@ static int __devexit asoc_mcpdm_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id omap_mcpdm_of_match[] = {
+	{ .compatible = "ti,omap4-mcpdm", },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, omap_mcpdm_of_match);
+
 static struct platform_driver asoc_mcpdm_driver = {
 	.driver = {
 		.name	= "omap-mcpdm",
 		.owner	= THIS_MODULE,
+		.of_match_table = omap_mcpdm_of_match,
 	},
 
 	.probe	= asoc_mcpdm_probe,
-- 
1.7.8.rc4

[PATCH 2/5] ASoC: omap-mcpdm: Add device tree bindings

[Peter Ujfalusi]

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 .../bindings/sound/soc/omap/omap-mcpdm.txt         |   13 +++++++++++++
 sound/soc/omap/omap-mcpdm.c                        |    8 ++++++++
 2 files changed, 21 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/soc/omap/omap-mcpdm.txt

diff --git a/Documentation/devicetree/bindings/sound/soc/omap/omap-mcpdm.txt b/Documentation/devicetree/bindings/sound/soc/omap/omap-mcpdm.txt
new file mode 100644
index 0000000..e94bb96
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/soc/omap/omap-mcpdm.txt
@@ -0,0 +1,13 @@
+* Texas Instruments OMAP4 McPDM
+
+Required properties:
+  - compatible : "ti,omap4-mcpdm"
+  - ti,hwmods  : List of hwmod names associated with McPDM, in most case
+                 it is "mcpdm".
+
+Example:
+
+mcpdm_dai: mcpdm at 40132000 {
+	compatible = "ti,omap4-mcpdm";
+	ti,hwmods = "mcpdm";
+};
diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
index b50ac60..c95fc70 100644
--- a/sound/soc/omap/omap-mcpdm.c
+++ b/sound/soc/omap/omap-mcpdm.c
@@ -33,6 +33,7 @@
 #include <linux/irq.h>
 #include <linux/slab.h>
 #include <linux/pm_runtime.h>
+#include <linux/of_device.h>
 
 #include <sound/core.h>
 #include <sound/pcm.h>
@@ -510,10 +511,17 @@ static int __devexit asoc_mcpdm_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id omap_mcpdm_of_match[] = {
+	{ .compatible = "ti,omap4-mcpdm", },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, omap_mcpdm_of_match);
+
 static struct platform_driver asoc_mcpdm_driver = {
 	.driver = {
 		.name	= "omap-mcpdm",
 		.owner	= THIS_MODULE,
+		.of_match_table = omap_mcpdm_of_match,
 	},
 
 	.probe	= asoc_mcpdm_probe,
-- 
1.7.8.rc4

[PATCH 3/5] OMAP4: devices: Do not create dmic device if the dtb has been provided

[Peter Ujfalusi]

If dtb is provided of will create the needed devices dynamically so there
is no need to create the platform device for DMIC here.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 arch/arm/mach-omap2/devices.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 35d5dff..d7ca473 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -344,6 +344,10 @@ static void omap_init_dmic(void)
 	struct omap_hwmod *oh;
 	struct platform_device *pdev;
 
+	/* If dtb is there, the devices will be created dynamically */
+	if (of_have_populated_dt())
+		return;
+
 	oh = omap_hwmod_lookup("dmic");
 	if (!oh) {
 		printk(KERN_ERR "Could not look up mcpdm hw_mod\n");
-- 
1.7.8.rc4

[PATCH 3/5] OMAP4: devices: Do not create dmic device if the dtb has been provided

[Peter Ujfalusi]

If dtb is provided of will create the needed devices dynamically so there
is no need to create the platform device for DMIC here.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 arch/arm/mach-omap2/devices.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 35d5dff..d7ca473 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -344,6 +344,10 @@ static void omap_init_dmic(void)
 	struct omap_hwmod *oh;
 	struct platform_device *pdev;
 
+	/* If dtb is there, the devices will be created dynamically */
+	if (of_have_populated_dt())
+		return;
+
 	oh = omap_hwmod_lookup("dmic");
 	if (!oh) {
 		printk(KERN_ERR "Could not look up mcpdm hw_mod\n");
-- 
1.7.8.rc4

[PATCH 4/5] OMAP4: devices: Do not create mcpdm device if the dtb has been provided

[Peter Ujfalusi]

If dtb is provided of will create the needed devices dynamically so there
is no need to create the platform device for McPDM here.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 arch/arm/mach-omap2/devices.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index d7ca473..469f875 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -323,6 +323,10 @@ static void omap_init_mcpdm(void)
 	struct omap_hwmod *oh;
 	struct platform_device *pdev;
 
+	/* If dtb is there, the devices will be created dynamically */
+	if (of_have_populated_dt())
+		return;
+
 	oh = omap_hwmod_lookup("mcpdm");
 	if (!oh) {
 		printk(KERN_ERR "Could not look up mcpdm hw_mod\n");
-- 
1.7.8.rc4

[PATCH 4/5] OMAP4: devices: Do not create mcpdm device if the dtb has been provided

[Peter Ujfalusi]

If dtb is provided of will create the needed devices dynamically so there
is no need to create the platform device for McPDM here.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 arch/arm/mach-omap2/devices.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index d7ca473..469f875 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -323,6 +323,10 @@ static void omap_init_mcpdm(void)
 	struct omap_hwmod *oh;
 	struct platform_device *pdev;
 
+	/* If dtb is there, the devices will be created dynamically */
+	if (of_have_populated_dt())
+		return;
+
 	oh = omap_hwmod_lookup("mcpdm");
 	if (!oh) {
 		printk(KERN_ERR "Could not look up mcpdm hw_mod\n");
-- 
1.7.8.rc4

[PATCH 5/5] ARM: OMAP4: DTS: Support for dmic, and McPDM in device tree

[Peter Ujfalusi]

Add DT support for dmic, and McPDM on OMAP4 platforms.
Panda board does not have DMIC lines accessable, so
disable the dmic on panda.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 arch/arm/boot/dts/omap4-panda.dts |    4 ++++
 arch/arm/boot/dts/omap4.dtsi      |    9 +++++++++
 2 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
index c702657..b73b641 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -27,3 +27,7 @@
 		reg = <0x80000000 0x40000000>; /* 1 GB */
 	};
 };
+
+&dmic_dai {
+	status = "disabled";
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4c61c82..00cfb73 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -99,5 +99,14 @@
 			reg = <0x48241000 0x1000>,
 			      <0x48240100 0x0100>;
 		};
+
+		dmic_dai: dmic@4012e000 {
+			compatible = "ti,omap4-dmic";
+			ti,hwmods = "dmic";
+		};
+		mcpdm_dai: mcpdm@40132000 {
+			compatible = "ti,omap4-mcpdm";
+			ti,hwmods = "mcpdm";
+		};
 	};
 };
-- 
1.7.8.rc4

[PATCH 5/5] ARM: OMAP4: DTS: Support for dmic, and McPDM in device tree

[Peter Ujfalusi]

Add DT support for dmic, and McPDM on OMAP4 platforms.
Panda board does not have DMIC lines accessable, so
disable the dmic on panda.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 arch/arm/boot/dts/omap4-panda.dts |    4 ++++
 arch/arm/boot/dts/omap4.dtsi      |    9 +++++++++
 2 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
index c702657..b73b641 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -27,3 +27,7 @@
 		reg = <0x80000000 0x40000000>; /* 1 GB */
 	};
 };
+
+&dmic_dai {
+	status = "disabled";
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4c61c82..00cfb73 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -99,5 +99,14 @@
 			reg = <0x48241000 0x1000>,
 			      <0x48240100 0x0100>;
 		};
+
+		dmic_dai: dmic at 4012e000 {
+			compatible = "ti,omap4-dmic";
+			ti,hwmods = "dmic";
+		};
+		mcpdm_dai: mcpdm at 40132000 {
+			compatible = "ti,omap4-mcpdm";
+			ti,hwmods = "mcpdm";
+		};
 	};
 };
-- 
1.7.8.rc4