[PATCH 00/11] ASoC: OMAP: HDMI: Use DSS audio interface and prepare for OMAP5

[Ricardo Neri]

Hello,

The ASoC HDMI codec used to be embedded in the DSS HDMI driver. In order
to give the OMAP HDMI code a more logical arrangement and to remove
some dependency breaks[1][2], such ASoC HDMI codec was removed[3]. Instead, the
DSS HDMI audio functionality[4] is now provided through the new DSS device 
driver
audio interface [5]. Hence, the ASoC HDMI support for OMAP needs to be changed
to use this new DSS device driver audio interface. Under this new approach:

 * The HDMI audio functionality provided by the OMAP is now regarded as a
   CPU DAI rather than a codec. Hence, the CPU DAI will perform the operations
   that were performed previously by the codec (using the DSS dev driver audio
   interface).
 * A new ASoC HDMI OMAP codec is introduced as a dummy component. In the
   future, this component will examine the features supported by the sink
   and limit the number of channels, sample rates and formats that are exposed
   to the user.

Also, this set of patches paves the way to the introduction of the HDMI audio
functionality for OMAP5. The goal is to use the same set of ASoC drivers
for OMAP4 and OMAP5 (DSS will be in charge of selecting the correct set
of functions at run time). For this, several patches are submitted for:

 * Generalizing the build files to encompass not only OMAP4.
 * In the HDMI sound card driver, renaming the the functions and structures
   from omap4_ to omap_.

This set includes the suggestions and improvements that Mark Brown kindly 
provided
some time ago [6][7].

Please note that this set of patches will not build unless the patches from [4],
[5] and [8] are present. All these patches have been accepted and should be
upstream for K3.5.

This implementation was validated on top of:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git v3.4-rc7

and Liam Girdwood's:
git://gitorious.org/omap-audio/linux-audio.git lrg/topic/3.5-dev

Thanks,

Ricardo

[1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67295.html
[2] http://www.spinics.net/lists/linux-omap/msg66178.html
[3] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67809.html
[4] http://www.spinics.net/lists/linux-omap/msg69466.html
[5] http://www.spinics.net/lists/linux-omap/msg69451.html
[6] 
http://mailman.alsa-project.org/pipermail/alsa-devel/2012-February/049064.html
[7] 
http://mailman.alsa-project.org/pipermail/alsa-devel/2012-February/049065.html
[8] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg66600.html

Ricardo Neri (11):
  ASoC: OMAP: HDMI: Introduce codec
  ASoC: OMAP: HDMI: Update the platform device names
  ASoC: OMAP: HDMI: Change error values in HDMI CPU DAI
  ASoC: OMAP: HDMI: Create a structure for private data of the CPU DAI
  ASoC: OMAP: HDMI: Use the DSS audio interface
  ASoC: OMAP: HDMI: Expand configuration of hw_params
  ASoC: OMAP: HDMI: Improve how the display state is verified
  ASoC: OMAP: HDMI: Expand capabilities of the HDMI DAI
  ASoC: OMAP: HDMI: Make build config options more generic
  ASoC: OMAP: HDMI: Make sound card naming more generic
  ASoC: OMAP: HDMI: Rename sound card driver

 sound/soc/codecs/Kconfig |4 +
 sound/soc/codecs/Makefile|2 +
 sound/soc/codecs/omap-hdmi.c |   69 +++
 sound/soc/omap/Kconfig   |8 +-
 sound/soc/omap/Makefile  |4 +-
 sound/soc/omap/omap-hdmi-card.c  |   87 ++
 sound/soc/omap/omap-hdmi.c   |  238 +++---
 sound/soc/omap/omap-hdmi.h   |4 +-
 sound/soc/omap/omap4-hdmi-card.c |  121 ---
 9 files changed, 395 insertions(+), 142 deletions(-)
 create mode 100644 sound/soc/codecs/omap-hdmi.c
 create mode 100644 sound/soc/omap/omap-hdmi-card.c
 delete mode 100644 sound/soc/omap/omap4-hdmi-card.c

-- 
1.7.5.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 09/11] ASoC: OMAP: HDMI: Make build config options more generic

[Ricardo Neri]

Make Kconfig and Makefile more generic to encompass not only
OMAP4 but other OMAP processors featuring HDMI.

Also, relax the dependency list to depend only on any OMAP processor
supporting OMAP2_DSS and OMAP4_DSS_HDMI. As HDMI support for
future OMAP versions is added, the dependency list must change
accordingly.

Signed-off-by: Ricardo Neri 
---
 sound/soc/omap/Kconfig  |6 +++---
 sound/soc/omap/Makefile |2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index 13afb2c..57a2fa7 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -109,9 +109,9 @@ config SND_OMAP_SOC_OMAP_ABE_TWL6040
  - PandaBoard (4430)
  - PandaBoardES (4460)
 
-config SND_OMAP_SOC_OMAP4_HDMI
-   tristate "SoC Audio support for Texas Instruments OMAP4 HDMI"
-   depends on SND_OMAP_SOC && OMAP4_DSS_HDMI && OMAP2_DSS && ARCH_OMAP4
+config SND_OMAP_SOC_OMAP_HDMI
+   tristate "SoC Audio support for Texas Instruments OMAP HDMI"
+   depends on SND_OMAP_SOC && OMAP4_DSS_HDMI && OMAP2_DSS
select SND_OMAP_SOC_HDMI
select SND_SOC_OMAP_HDMI_CODEC
select OMAP4_DSS_HDMI_AUDIO
diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
index 1d656bc..b4ef308 100644
--- a/sound/soc/omap/Makefile
+++ b/sound/soc/omap/Makefile
@@ -41,4 +41,4 @@ obj-$(CONFIG_SND_OMAP_SOC_OMAP3_PANDORA) += 
snd-soc-omap3pandora.o
 obj-$(CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE) += snd-soc-omap3beagle.o
 obj-$(CONFIG_SND_OMAP_SOC_ZOOM2) += snd-soc-zoom2.o
 obj-$(CONFIG_SND_OMAP_SOC_IGEP0020) += snd-soc-igep0020.o
-obj-$(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) += snd-soc-omap4-hdmi.o
+obj-$(CONFIG_SND_OMAP_SOC_OMAP_HDMI) += snd-soc-omap4-hdmi.o
-- 
1.7.5.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 11/11] ASoC: OMAP: HDMI: Rename sound card source file

[Ricardo Neri]

Rename sound card driver source file to encompass not only OMAP4 but future
OMAP versions that feature HDMI.

Signed-off-by: Ricardo Neri 
---
 sound/soc/omap/Makefile  |4 +-
 sound/soc/omap/omap-hdmi-card.c  |   87 ++
 sound/soc/omap/omap4-hdmi-card.c |   87 --
 3 files changed, 89 insertions(+), 89 deletions(-)
 create mode 100644 sound/soc/omap/omap-hdmi-card.c
 delete mode 100644 sound/soc/omap/omap4-hdmi-card.c

diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
index b4ef308..0e14dd3 100644
--- a/sound/soc/omap/Makefile
+++ b/sound/soc/omap/Makefile
@@ -25,7 +25,7 @@ snd-soc-omap3pandora-objs := omap3pandora.o
 snd-soc-omap3beagle-objs := omap3beagle.o
 snd-soc-zoom2-objs := zoom2.o
 snd-soc-igep0020-objs := igep0020.o
-snd-soc-omap4-hdmi-objs := omap4-hdmi-card.o
+snd-soc-omap-hdmi-card-objs := omap-hdmi-card.o
 
 obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-n810.o
 obj-$(CONFIG_SND_OMAP_SOC_RX51) += snd-soc-rx51.o
@@ -41,4 +41,4 @@ obj-$(CONFIG_SND_OMAP_SOC_OMAP3_PANDORA) += 
snd-soc-omap3pandora.o
 obj-$(CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE) += snd-soc-omap3beagle.o
 obj-$(CONFIG_SND_OMAP_SOC_ZOOM2) += snd-soc-zoom2.o
 obj-$(CONFIG_SND_OMAP_SOC_IGEP0020) += snd-soc-igep0020.o
-obj-$(CONFIG_SND_OMAP_SOC_OMAP_HDMI) += snd-soc-omap4-hdmi.o
+obj-$(CONFIG_SND_OMAP_SOC_OMAP_HDMI) += snd-soc-omap-hdmi-card.o
diff --git a/sound/soc/omap/omap-hdmi-card.c b/sound/soc/omap/omap-hdmi-card.c
new file mode 100644
index 000..eaa2ea0
--- /dev/null
+++ b/sound/soc/omap/omap-hdmi-card.c
@@ -0,0 +1,87 @@
+/*
+ * omap-hdmi-card.c
+ *
+ * OMAP ALSA SoC machine driver for TI OMAP HDMI
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: Ricardo Neri 
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME "omap-hdmi-audio"
+
+static struct snd_soc_dai_link omap_hdmi_dai = {
+   .name = "HDMI",
+   .stream_name = "HDMI",
+   .cpu_dai_name = "omap-hdmi-audio-dai",
+   .platform_name = "omap-pcm-audio",
+   .codec_name = "hdmi-audio-codec",
+   .codec_dai_name = "omap-hdmi-hifi",
+};
+
+static struct snd_soc_card snd_soc_omap_hdmi = {
+   .name = "OMAPHDMI",
+   .owner = THIS_MODULE,
+   .dai_link = &omap_hdmi_dai,
+   .num_links = 1,
+};
+
+static __devinit int omap_hdmi_probe(struct platform_device *pdev)
+{
+   struct snd_soc_card *card = &snd_soc_omap_hdmi;
+   int ret;
+
+   card->dev = &pdev->dev;
+
+   ret = snd_soc_register_card(card);
+   if (ret) {
+   dev_err(&pdev->dev, "snd_soc_register_card failed (%d)\n", ret);
+   card->dev = NULL;
+   return ret;
+   }
+   return 0;
+}
+
+static int __devexit omap_hdmi_remove(struct platform_device *pdev)
+{
+   struct snd_soc_card *card = platform_get_drvdata(pdev);
+
+   snd_soc_unregister_card(card);
+   card->dev = NULL;
+   return 0;
+}
+
+static struct platform_driver omap_hdmi_driver = {
+   .driver = {
+   .name = DRV_NAME,
+   .owner = THIS_MODULE,
+   },
+   .probe = omap_hdmi_probe,
+   .remove = __devexit_p(omap_hdmi_remove),
+};
+
+module_platform_driver(omap_hdmi_driver);
+
+MODULE_AUTHOR("Ricardo Neri ");
+MODULE_DESCRIPTION("OMAP HDMI machine ASoC driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:" DRV_NAME);
diff --git a/sound/soc/omap/omap4-hdmi-card.c b/sound/soc/omap/omap4-hdmi-card.c
deleted file mode 100644
index eaa2ea0..000
--- a/sound/soc/omap/omap4-hdmi-card.c
+++ /dev/null
@@ -1,87 +0,0 @@
-/*
- * omap-hdmi-card.c
- *
- * OMAP ALSA SoC machine driver for TI OMAP HDMI
- * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
- * Author: Ricardo Neri 
- *
- * 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 Publ

[PATCH 05/11] ASoC: OMAP: HDMI: Use the DSS audio interface

[Ricardo Neri]

Instead of accessing the HDMI IP directly, the CPU DAI driver takes
advantage of the audio interface provided by the DSS device driver.
The ASoC driver will link the DSS audio functionality with ALSA by
calling the appropriate DSS device driver functions at the relevant
moments. For this, three new DAI operations are added: trigger, prepare
and shutdown operations.

At the moment, it is assumed that only one HDMI display is available
in the system, as it is the case in OMAP4. However, in the future,
one DAI for each HDMI display should be provided.

Signed-off-by: Ricardo Neri 
---
 sound/soc/omap/Kconfig |1 +
 sound/soc/omap/omap-hdmi.c |   77 
 2 files changed, 78 insertions(+), 0 deletions(-)

diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index 9ccfa5e..13afb2c 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -114,6 +114,7 @@ config SND_OMAP_SOC_OMAP4_HDMI
depends on SND_OMAP_SOC && OMAP4_DSS_HDMI && OMAP2_DSS && ARCH_OMAP4
select SND_OMAP_SOC_HDMI
select SND_SOC_OMAP_HDMI_CODEC
+   select OMAP4_DSS_HDMI_AUDIO
help
  Say Y if you want to add support for SoC HDMI audio on Texas 
Instruments
  OMAP4 chips
diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c
index a6656b2..ff6132a 100644
--- a/sound/soc/omap/omap-hdmi.c
+++ b/sound/soc/omap/omap-hdmi.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include "omap-pcm.h"
@@ -39,6 +40,7 @@
 
 struct hdmi_priv {
struct omap_pcm_dma_data dma_params;
+   struct omap_dss_device *dssdev;
 };
 
 static int omap_hdmi_dai_startup(struct snd_pcm_substream *substream,
@@ -57,6 +59,14 @@ static int omap_hdmi_dai_startup(struct snd_pcm_substream 
*substream,
return 0;
 }
 
+static int omap_hdmi_dai_prepare(struct snd_pcm_substream *substream,
+   struct snd_soc_dai *dai)
+{
+   struct hdmi_priv *priv = snd_soc_dai_get_drvdata(dai);
+
+   return priv->dssdev->driver->audio_enable(priv->dssdev);
+}
+
 static int omap_hdmi_dai_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params,
struct snd_soc_dai *dai)
@@ -83,6 +93,37 @@ static int omap_hdmi_dai_hw_params(struct snd_pcm_substream 
*substream,
return err;
 }
 
+static int omap_hdmi_dai_trigger(struct snd_pcm_substream *substream, int cmd,
+   struct snd_soc_dai *dai)
+{
+   struct hdmi_priv *priv = snd_soc_dai_get_drvdata(dai);
+   int err = 0;
+
+   switch (cmd) {
+   case SNDRV_PCM_TRIGGER_START:
+   case SNDRV_PCM_TRIGGER_RESUME:
+   case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+   err = priv->dssdev->driver->audio_start(priv->dssdev);
+   break;
+   case SNDRV_PCM_TRIGGER_STOP:
+   case SNDRV_PCM_TRIGGER_SUSPEND:
+   case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+   priv->dssdev->driver->audio_stop(priv->dssdev);
+   break;
+   default:
+   err = -EINVAL;
+   }
+   return err;
+}
+
+static void omap_hdmi_dai_shutdown(struct snd_pcm_substream *substream,
+   struct snd_soc_dai *dai)
+{
+   struct hdmi_priv *priv = snd_soc_dai_get_drvdata(dai);
+
+   priv->dssdev->driver->audio_disable(priv->dssdev);
+}
+
 static const struct snd_soc_dai_ops omap_hdmi_dai_ops = {
.startup= omap_hdmi_dai_startup,
.hw_params  = omap_hdmi_dai_hw_params,
@@ -103,6 +144,7 @@ static __devinit int omap_hdmi_probe(struct platform_device 
*pdev)
int ret;
struct resource *hdmi_rsrc;
struct hdmi_priv *hdmi_data;
+   bool hdmi_dev_found = false;
 
hdmi_data = devm_kzalloc(&pdev->dev, sizeof(*hdmi_data), GFP_KERNEL);
if (hdmi_data == NULL) {
@@ -129,14 +171,49 @@ static __devinit int omap_hdmi_probe(struct 
platform_device *pdev)
hdmi_data->dma_params.name = "HDMI playback";
hdmi_data->dma_params.sync_mode = OMAP_DMA_SYNC_PACKET;
 
+   /*
+* TODO: We assume that there is only one DSS HDMI device. Future
+* OMAP implementations may support more than one HDMI devices and
+* we should provided separate audio support for all of them.
+*/
+   /* Find an HDMI device. */
+   for_each_dss_dev(hdmi_data->dssdev) {
+   omap_dss_get_device(hdmi_data->dssdev);
+
+   if (!hdmi_data->dssdev->driver) {
+   omap_dss_put_device(hdmi_data->dssdev);
+   continue;
+   }
+
+   if (hdmi_data->dssdev->type == OMAP_DISPLAY_TYPE_HDMI) {
+   hdmi_dev_found = true;
+   break;
+   }
+   }
+
+   if (!hdmi_dev_found) {
+   dev_err(&pdev->dev, "no driver for HDMI display found\n");
+   retur

[PATCH 08/11] ASoC: OMAP: HDMI: Expand capabilities of the HDMI DAI

[Ricardo Neri]

According to the HDMI specification, a source is permitted to
transmit L-PCM audio in the following sample rates: 32kHz, 44.1kHz,
48kHz, 88.2kHz, 96kHz, 176.4kHz or 192kHz.

It also supports up to 8 audio channels.

The sink may not necessarily support all these sample rates and
channels. However, as this CPU DAI describes the HDMI source, it
makes sense to include them. The limitation of capabilities as
supported by the sink should be done in the ASoC HDMI codec.

Signed-off-by: Ricardo Neri 
---
 sound/soc/omap/omap-hdmi.c |2 +-
 sound/soc/omap/omap-hdmi.h |4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c
index ec7c7e6..a08245d 100644
--- a/sound/soc/omap/omap-hdmi.c
+++ b/sound/soc/omap/omap-hdmi.c
@@ -253,7 +253,7 @@ static const struct snd_soc_dai_ops omap_hdmi_dai_ops = {
 static struct snd_soc_dai_driver omap_hdmi_dai = {
.playback = {
.channels_min = 2,
-   .channels_max = 2,
+   .channels_max = 8,
.rates = OMAP_HDMI_RATES,
.formats = OMAP_HDMI_FORMATS,
},
diff --git a/sound/soc/omap/omap-hdmi.h b/sound/soc/omap/omap-hdmi.h
index 34c298d..6ad2bf4 100644
--- a/sound/soc/omap/omap-hdmi.h
+++ b/sound/soc/omap/omap-hdmi.h
@@ -28,7 +28,9 @@
 #define OMAP_HDMI_AUDIO_DMA_PORT 0x8c
 
 #define OMAP_HDMI_RATES(SNDRV_PCM_RATE_32000 | \
-   SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000)
+   SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 | \
+   SNDRV_PCM_RATE_88200 | SNDRV_PCM_RATE_96000 | \
+   SNDRV_PCM_RATE_176400 | SNDRV_PCM_RATE_192000)
 
 #define OMAP_HDMI_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \
SNDRV_PCM_FMTBIT_S24_LE)
-- 
1.7.5.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 07/11] ASoC: OMAP: HDMI: Improve how the display state is verified

[Ricardo Neri]

Before starting to play audio, we need to make sure that the
display is active and the current video mode supports audio. instead
of using the overlay manager in the machine driver, we use the DSS audio
interface's audio_supported function. As we already have a pointer to
the correct dssdev, we do not have to look for it every time audio is
to be played. Also, the CPU DAI startup function is called earlier
than the card hw_param function. Hence and we can detect the state of
the display earlier.

While there, add a error message if the constraint cannot be applied.

Signed-off-by: Ricardo Neri 

squash to improve err
---
 sound/soc/omap/omap-hdmi.c   |9 -
 sound/soc/omap/omap4-hdmi-card.c |   34 --
 2 files changed, 8 insertions(+), 35 deletions(-)

diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c
index fc4815a..ec7c7e6 100644
--- a/sound/soc/omap/omap-hdmi.c
+++ b/sound/soc/omap/omap-hdmi.c
@@ -51,6 +51,7 @@ struct hdmi_priv {
 static int omap_hdmi_dai_startup(struct snd_pcm_substream *substream,
  struct snd_soc_dai *dai)
 {
+   struct hdmi_priv *priv = snd_soc_dai_get_drvdata(dai);
int err;
/*
 * Make sure that the period bytes are multiple of the DMA packet size.
@@ -58,9 +59,15 @@ static int omap_hdmi_dai_startup(struct snd_pcm_substream 
*substream,
 */
err = snd_pcm_hw_constraint_step(substream->runtime, 0,
 SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 128);
-   if (err < 0)
+   if (err < 0) {
+   dev_err(dai->dev, "could not apply constraint\n");
return err;
+   }
 
+   if (!priv->dssdev->driver->audio_supported(priv->dssdev)) {
+   dev_err(dai->dev, "audio not supported\n");
+   return -ENODEV;
+   }
return 0;
 }
 
diff --git a/sound/soc/omap/omap4-hdmi-card.c b/sound/soc/omap/omap4-hdmi-card.c
index 99e96c6..6c3255f 100644
--- a/sound/soc/omap/omap4-hdmi-card.c
+++ b/sound/soc/omap/omap4-hdmi-card.c
@@ -29,39 +29,6 @@
 
 #define DRV_NAME "omap-hdmi-audio"
 
-static int omap4_hdmi_dai_hw_params(struct snd_pcm_substream *substream,
-   struct snd_pcm_hw_params *params)
-{
-   int i;
-   struct omap_overlay_manager *mgr = NULL;
-   struct device *dev = substream->pcm->card->dev;
-
-   /* Find DSS HDMI device */
-   for (i = 0; i < omap_dss_get_num_overlay_managers(); i++) {
-   mgr = omap_dss_get_overlay_manager(i);
-   if (mgr && mgr->device
-   && mgr->device->type == OMAP_DISPLAY_TYPE_HDMI)
-   break;
-   }
-
-   if (i == omap_dss_get_num_overlay_managers()) {
-   dev_err(dev, "HDMI display device not found!\n");
-   return -ENODEV;
-   }
-
-   /* Make sure HDMI is power-on to avoid L3 interconnect errors */
-   if (mgr->device->state != OMAP_DSS_DISPLAY_ACTIVE) {
-   dev_err(dev, "HDMI display is not active!\n");
-   return -EIO;
-   }
-
-   return 0;
-}
-
-static struct snd_soc_ops omap4_hdmi_dai_ops = {
-   .hw_params = omap4_hdmi_dai_hw_params,
-};
-
 static struct snd_soc_dai_link omap4_hdmi_dai = {
.name = "HDMI",
.stream_name = "HDMI",
@@ -69,7 +36,6 @@ static struct snd_soc_dai_link omap4_hdmi_dai = {
.platform_name = "omap-pcm-audio",
.codec_name = "hdmi-audio-codec",
.codec_dai_name = "omap-hdmi-hifi",
-   .ops = &omap4_hdmi_dai_ops,
 };
 
 static struct snd_soc_card snd_soc_omap4_hdmi = {
-- 
1.7.5.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 10/11] ASoC: OMAP: HDMI: Make sound card naming more generic

[Ricardo Neri]

Rename all the relevant structures, variables and functions to not
make specific reference to OMAP4. This is to make the driver encompass
future OMAP versions that feature HDMI and not only OMAP4. These
changes are only in naming. There are not functional changes.

Signed-off-by: Ricardo Neri 
---
 sound/soc/omap/omap4-hdmi-card.c |   28 ++--
 1 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/sound/soc/omap/omap4-hdmi-card.c b/sound/soc/omap/omap4-hdmi-card.c
index 6c3255f..eaa2ea0 100644
--- a/sound/soc/omap/omap4-hdmi-card.c
+++ b/sound/soc/omap/omap4-hdmi-card.c
@@ -1,7 +1,7 @@
 /*
- * omap4-hdmi-card.c
+ * omap-hdmi-card.c
  *
- * OMAP ALSA SoC machine driver for TI OMAP4 HDMI
+ * OMAP ALSA SoC machine driver for TI OMAP HDMI
  * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
  * Author: Ricardo Neri 
  *
@@ -29,7 +29,7 @@
 
 #define DRV_NAME "omap-hdmi-audio"
 
-static struct snd_soc_dai_link omap4_hdmi_dai = {
+static struct snd_soc_dai_link omap_hdmi_dai = {
.name = "HDMI",
.stream_name = "HDMI",
.cpu_dai_name = "omap-hdmi-audio-dai",
@@ -38,16 +38,16 @@ static struct snd_soc_dai_link omap4_hdmi_dai = {
.codec_dai_name = "omap-hdmi-hifi",
 };
 
-static struct snd_soc_card snd_soc_omap4_hdmi = {
-   .name = "OMAP4HDMI",
+static struct snd_soc_card snd_soc_omap_hdmi = {
+   .name = "OMAPHDMI",
.owner = THIS_MODULE,
-   .dai_link = &omap4_hdmi_dai,
+   .dai_link = &omap_hdmi_dai,
.num_links = 1,
 };
 
-static __devinit int omap4_hdmi_probe(struct platform_device *pdev)
+static __devinit int omap_hdmi_probe(struct platform_device *pdev)
 {
-   struct snd_soc_card *card = &snd_soc_omap4_hdmi;
+   struct snd_soc_card *card = &snd_soc_omap_hdmi;
int ret;
 
card->dev = &pdev->dev;
@@ -61,7 +61,7 @@ static __devinit int omap4_hdmi_probe(struct platform_device 
*pdev)
return 0;
 }
 
-static int __devexit omap4_hdmi_remove(struct platform_device *pdev)
+static int __devexit omap_hdmi_remove(struct platform_device *pdev)
 {
struct snd_soc_card *card = platform_get_drvdata(pdev);
 
@@ -70,18 +70,18 @@ static int __devexit omap4_hdmi_remove(struct 
platform_device *pdev)
return 0;
 }
 
-static struct platform_driver omap4_hdmi_driver = {
+static struct platform_driver omap_hdmi_driver = {
.driver = {
.name = DRV_NAME,
.owner = THIS_MODULE,
},
-   .probe = omap4_hdmi_probe,
-   .remove = __devexit_p(omap4_hdmi_remove),
+   .probe = omap_hdmi_probe,
+   .remove = __devexit_p(omap_hdmi_remove),
 };
 
-module_platform_driver(omap4_hdmi_driver);
+module_platform_driver(omap_hdmi_driver);
 
 MODULE_AUTHOR("Ricardo Neri ");
-MODULE_DESCRIPTION("OMAP4 HDMI machine ASoC driver");
+MODULE_DESCRIPTION("OMAP HDMI machine ASoC driver");
 MODULE_LICENSE("GPL");
 MODULE_ALIAS("platform:" DRV_NAME);
-- 
1.7.5.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 06/11] ASoC: OMAP: HDMI: Expand configuration of hw_params

[Ricardo Neri]

Expand the configuration of the hw_params to include the IEC-60958
channel status word and the CEA-861 audio infoframe. The configuration
of such structures depends on the snd_pcm_hw_params received. A
omap_dss_audio is used to pass the configuration parameters to DSS.

Signed-off-by: Ricardo Neri 
---
 sound/soc/omap/omap-hdmi.c |  116 +++-
 1 files changed, 115 insertions(+), 1 deletions(-)

diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c
index ff6132a..fc4815a 100644
--- a/sound/soc/omap/omap-hdmi.c
+++ b/sound/soc/omap/omap-hdmi.c
@@ -30,6 +30,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #include 
@@ -40,6 +42,9 @@
 
 struct hdmi_priv {
struct omap_pcm_dma_data dma_params;
+   struct omap_dss_audio dss_audio;
+   struct snd_aes_iec958 iec;
+   struct snd_cea_861_aud_if cea;
struct omap_dss_device *dssdev;
 };
 
@@ -72,6 +77,8 @@ static int omap_hdmi_dai_hw_params(struct snd_pcm_substream 
*substream,
struct snd_soc_dai *dai)
 {
struct hdmi_priv *priv = snd_soc_dai_get_drvdata(dai);
+   struct snd_aes_iec958 *iec = &priv->iec;
+   struct snd_cea_861_aud_if *cea = &priv->cea;
int err = 0;
 
switch (params_format(params)) {
@@ -82,7 +89,8 @@ static int omap_hdmi_dai_hw_params(struct snd_pcm_substream 
*substream,
priv->dma_params.packet_size = 32;
break;
default:
-   err = -EINVAL;
+   dev_err(dai->dev, "format not supported!\n");
+   return -EINVAL;
}
 
priv->dma_params.data_type = OMAP_DMA_DATA_TYPE_S32;
@@ -90,6 +98,109 @@ static int omap_hdmi_dai_hw_params(struct snd_pcm_substream 
*substream,
snd_soc_dai_set_dma_data(dai, substream,
 &priv->dma_params);
 
+   /*
+* fill the IEC-60958 channel status word
+*/
+
+   /* specify IEC-60958-3 (commercial use) */
+   iec->status[0] &= ~IEC958_AES0_PROFESSIONAL;
+
+   /* specify that the audio is LPCM*/
+   iec->status[0] &= ~IEC958_AES0_NONAUDIO;
+
+   iec->status[0] |= IEC958_AES0_CON_NOT_COPYRIGHT;
+
+   iec->status[0] |= IEC958_AES0_CON_EMPHASIS_NONE;
+
+   iec->status[0] |= IEC958_AES1_PRO_MODE_NOTID;
+
+   iec->status[1] = IEC958_AES1_CON_GENERAL;
+
+   iec->status[2] |= IEC958_AES2_CON_SOURCE_UNSPEC;
+
+   iec->status[2] |= IEC958_AES2_CON_CHANNEL_UNSPEC;
+
+   switch (params_rate(params)) {
+   case 32000:
+   iec->status[3] |= IEC958_AES3_CON_FS_32000;
+   break;
+   case 44100:
+   iec->status[3] |= IEC958_AES3_CON_FS_44100;
+   break;
+   case 48000:
+   iec->status[3] |= IEC958_AES3_CON_FS_48000;
+   break;
+   case 88200:
+   iec->status[3] |= IEC958_AES3_CON_FS_88200;
+   break;
+   case 96000:
+   iec->status[3] |= IEC958_AES3_CON_FS_96000;
+   break;
+   case 176400:
+   iec->status[3] |= IEC958_AES3_CON_FS_176400;
+   break;
+   case 192000:
+   iec->status[3] |= IEC958_AES3_CON_FS_192000;
+   break;
+   default:
+   dev_err(dai->dev, "rate not supported!\n");
+   return -EINVAL;
+   }
+
+   /* specify the clock accuracy */
+   iec->status[3] |= IEC958_AES3_CON_CLOCK_1000PPM;
+
+   /*
+* specify the word length. The same word length value can mean
+* two different lengths. Hence, we need to specify the maximum
+* word length as well.
+*/
+   switch (params_format(params)) {
+   case SNDRV_PCM_FORMAT_S16_LE:
+   iec->status[4] |= IEC958_AES4_CON_WORDLEN_20_16;
+   iec->status[4] &= ~IEC958_AES4_CON_MAX_WORDLEN_24;
+   break;
+   case SNDRV_PCM_FORMAT_S24_LE:
+   iec->status[4] |= IEC958_AES4_CON_WORDLEN_24_20;
+   iec->status[4] |= IEC958_AES4_CON_MAX_WORDLEN_24;
+   break;
+   default:
+   dev_err(dai->dev, "format not supported!\n");
+   return -EINVAL;
+   }
+
+   /*
+* Fill the CEA-861 audio infoframe (see spec for details)
+*/
+
+   cea->db1_ct_cc = (params_channels(params) - 1)
+   & CEA861_AUDIO_INFOFRAME_DB1CC;
+   cea->db1_ct_cc |= CEA861_AUDIO_INFOFRAME_DB1CT_FROM_STREAM;
+
+   cea->db2_sf_ss = CEA861_AUDIO_INFOFRAME_DB2SF_FROM_STREAM;
+   cea->db2_sf_ss |= CEA861_AUDIO_INFOFRAME_DB2SS_FROM_STREAM;
+
+   cea->db3 = 0; /* not used, all zeros */
+
+   /*
+* The OMAP HDMI IP requires to use the 8-channel channel code when
+* transmitting more than two channels.
+*/
+   if (params_channels(params) == 2)
+   cea->db4_ca = 0x0;
+   else
+   cea->db4_ca = 0x13;
+
+   cea-

[PATCH 02/11] ASoC: OMAP: HDMI: Update the platform device names

[Ricardo Neri]

In order to utilize the new OMAP HDMI codec and the updated name of
the device of the CPU DAI, update the names at the drivers accordingly.

While there, also update the name of the machine driver to be more
generic and encompass more OMAP processors featuring HDMI and not
only OMAP4.

Signed-off-by: Ricardo Neri 
---
 sound/soc/omap/omap-hdmi.c   |2 +-
 sound/soc/omap/omap4-hdmi-card.c |   10 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c
index 38e0def..0925a46 100644
--- a/sound/soc/omap/omap-hdmi.c
+++ b/sound/soc/omap/omap-hdmi.c
@@ -35,7 +35,7 @@
 #include "omap-pcm.h"
 #include "omap-hdmi.h"
 
-#define DRV_NAME "hdmi-audio-dai"
+#define DRV_NAME "omap-hdmi-audio-dai"
 
 static struct omap_pcm_dma_data omap_hdmi_dai_dma_params = {
.name = "HDMI playback",
diff --git a/sound/soc/omap/omap4-hdmi-card.c b/sound/soc/omap/omap4-hdmi-card.c
index 28d689b..99e96c6 100644
--- a/sound/soc/omap/omap4-hdmi-card.c
+++ b/sound/soc/omap/omap4-hdmi-card.c
@@ -27,7 +27,7 @@
 #include 
 #include 
 
-#define DRV_NAME "omap4-hdmi-audio"
+#define DRV_NAME "omap-hdmi-audio"
 
 static int omap4_hdmi_dai_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
@@ -65,10 +65,10 @@ static struct snd_soc_ops omap4_hdmi_dai_ops = {
 static struct snd_soc_dai_link omap4_hdmi_dai = {
.name = "HDMI",
.stream_name = "HDMI",
-   .cpu_dai_name = "hdmi-audio-dai",
+   .cpu_dai_name = "omap-hdmi-audio-dai",
.platform_name = "omap-pcm-audio",
-   .codec_name = "omapdss_hdmi",
-   .codec_dai_name = "hdmi-audio-codec",
+   .codec_name = "hdmi-audio-codec",
+   .codec_dai_name = "omap-hdmi-hifi",
.ops = &omap4_hdmi_dai_ops,
 };
 
@@ -106,7 +106,7 @@ static int __devexit omap4_hdmi_remove(struct 
platform_device *pdev)
 
 static struct platform_driver omap4_hdmi_driver = {
.driver = {
-   .name = "omap4-hdmi-audio",
+   .name = DRV_NAME,
.owner = THIS_MODULE,
},
.probe = omap4_hdmi_probe,
-- 
1.7.5.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 04/11] ASoC: OMAP: HDMI: Create a structure for private data of the CPU DAI

[Ricardo Neri]

Create a struct hdmi_priv to store the relevant data of the CPU DAI
driver. As more data is added to the driver, having all the data
in the same location eases its handling. At the moment, only the DMA
configuration parameters are included in the structure.

Also, the required memory is allocated using devm_kzalloc rather than
using a static global variable.

Signed-off-by: Ricardo Neri 
---
 sound/soc/omap/omap-hdmi.c |   28 +++-
 1 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c
index b889f76..a6656b2 100644
--- a/sound/soc/omap/omap-hdmi.c
+++ b/sound/soc/omap/omap-hdmi.c
@@ -37,9 +37,8 @@
 
 #define DRV_NAME "omap-hdmi-audio-dai"
 
-static struct omap_pcm_dma_data omap_hdmi_dai_dma_params = {
-   .name = "HDMI playback",
-   .sync_mode = OMAP_DMA_SYNC_PACKET,
+struct hdmi_priv {
+   struct omap_pcm_dma_data dma_params;
 };
 
 static int omap_hdmi_dai_startup(struct snd_pcm_substream *substream,
@@ -62,23 +61,24 @@ static int omap_hdmi_dai_hw_params(struct snd_pcm_substream 
*substream,
struct snd_pcm_hw_params *params,
struct snd_soc_dai *dai)
 {
+   struct hdmi_priv *priv = snd_soc_dai_get_drvdata(dai);
int err = 0;
 
switch (params_format(params)) {
case SNDRV_PCM_FORMAT_S16_LE:
-   omap_hdmi_dai_dma_params.packet_size = 16;
+   priv->dma_params.packet_size = 16;
break;
case SNDRV_PCM_FORMAT_S24_LE:
-   omap_hdmi_dai_dma_params.packet_size = 32;
+   priv->dma_params.packet_size = 32;
break;
default:
err = -EINVAL;
}
 
-   omap_hdmi_dai_dma_params.data_type = OMAP_DMA_DATA_TYPE_S32;
+   priv->dma_params.data_type = OMAP_DMA_DATA_TYPE_S32;
 
snd_soc_dai_set_dma_data(dai, substream,
-&omap_hdmi_dai_dma_params);
+&priv->dma_params);
 
return err;
 }
@@ -102,6 +102,13 @@ static __devinit int omap_hdmi_probe(struct 
platform_device *pdev)
 {
int ret;
struct resource *hdmi_rsrc;
+   struct hdmi_priv *hdmi_data;
+
+   hdmi_data = devm_kzalloc(&pdev->dev, sizeof(*hdmi_data), GFP_KERNEL);
+   if (hdmi_data == NULL) {
+   dev_err(&pdev->dev, "Cannot allocate memory for HDMI data\n");
+   return -ENOMEM;
+   }
 
hdmi_rsrc = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!hdmi_rsrc) {
@@ -109,7 +116,7 @@ static __devinit int omap_hdmi_probe(struct platform_device 
*pdev)
return -ENODEV;
}
 
-   omap_hdmi_dai_dma_params.port_addr =  hdmi_rsrc->start
+   hdmi_data->dma_params.port_addr =  hdmi_rsrc->start
+ OMAP_HDMI_AUDIO_DMA_PORT;
 
hdmi_rsrc = platform_get_resource(pdev, IORESOURCE_DMA, 0);
@@ -118,8 +125,11 @@ static __devinit int omap_hdmi_probe(struct 
platform_device *pdev)
return -ENODEV;
}
 
-   omap_hdmi_dai_dma_params.dma_req =  hdmi_rsrc->start;
+   hdmi_data->dma_params.dma_req =  hdmi_rsrc->start;
+   hdmi_data->dma_params.name = "HDMI playback";
+   hdmi_data->dma_params.sync_mode = OMAP_DMA_SYNC_PACKET;
 
+   dev_set_drvdata(&pdev->dev, hdmi_data);
ret = snd_soc_register_dai(&pdev->dev, &omap_hdmi_dai);
return ret;
 }
-- 
1.7.5.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 01/11] ASoC: OMAP: HDMI: Introduce codec

[Ricardo Neri]

Introduce codec for HDMI. At the moment, this is a dummy codec. In the
future it will parse the EDID to modify the supported parameters, such
as the number of channels and the sample rates. At the moment, it blindly
supports all the sample rates and audio channels described in the HDMI
1.4a specification.

Signed-off-by: Ricardo Neri 
---
 sound/soc/codecs/Kconfig |4 ++
 sound/soc/codecs/Makefile|2 +
 sound/soc/codecs/omap-hdmi.c |   69 ++
 sound/soc/omap/Kconfig   |1 +
 4 files changed, 76 insertions(+), 0 deletions(-)
 create mode 100644 sound/soc/codecs/omap-hdmi.c

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 59d8efa..7cac665 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -42,6 +42,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_MAX9850 if I2C
select SND_SOC_MAX9768 if I2C
select SND_SOC_MAX9877 if I2C
+   select SND_SOC_OMAP_HDMI_CODEC if OMAP4_DSS_HDMI
select SND_SOC_PCM3008
select SND_SOC_RT5631 if I2C
select SND_SOC_SGTL5000 if I2C
@@ -226,6 +227,9 @@ config SND_SOC_MAX98095
 config SND_SOC_MAX9850
tristate
 
+config SND_SOC_OMAP_HDMI_CODEC
+   tristate
+
 config SND_SOC_PCM3008
tristate
 
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 6662eb0..7e475c9 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -29,6 +29,7 @@ snd-soc-max9768-objs := max9768.o
 snd-soc-max98088-objs := max98088.o
 snd-soc-max98095-objs := max98095.o
 snd-soc-max9850-objs := max9850.o
+snd-soc-omap-hdmi-codec-objs := omap-hdmi.o
 snd-soc-pcm3008-objs := pcm3008.o
 snd-soc-rt5631-objs := rt5631.o
 snd-soc-sgtl5000-objs := sgtl5000.o
@@ -135,6 +136,7 @@ obj-$(CONFIG_SND_SOC_MAX9768)   += snd-soc-max9768.o
 obj-$(CONFIG_SND_SOC_MAX98088) += snd-soc-max98088.o
 obj-$(CONFIG_SND_SOC_MAX98095) += snd-soc-max98095.o
 obj-$(CONFIG_SND_SOC_MAX9850)  += snd-soc-max9850.o
+obj-$(CONFIG_SND_SOC_OMAP_HDMI_CODEC) += snd-soc-omap-hdmi-codec.o
 obj-$(CONFIG_SND_SOC_PCM3008)  += snd-soc-pcm3008.o
 obj-$(CONFIG_SND_SOC_RT5631)   += snd-soc-rt5631.o
 obj-$(CONFIG_SND_SOC_SGTL5000)  += snd-soc-sgtl5000.o
diff --git a/sound/soc/codecs/omap-hdmi.c b/sound/soc/codecs/omap-hdmi.c
new file mode 100644
index 000..1bf5c74
--- /dev/null
+++ b/sound/soc/codecs/omap-hdmi.c
@@ -0,0 +1,69 @@
+/*
+ * ALSA SoC codec driver for HDMI audio on OMAP processors.
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: Ricardo Neri 
+ *
+ * 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 
+#include 
+
+#define DRV_NAME "hdmi-audio-codec"
+
+static struct snd_soc_codec_driver omap_hdmi_codec;
+
+static struct snd_soc_dai_driver omap_hdmi_codec_dai = {
+   .name = "omap-hdmi-hifi",
+   .playback = {
+   .channels_min = 2,
+   .channels_max = 8,
+   .rates = SNDRV_PCM_RATE_32000 |
+   SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |
+   SNDRV_PCM_RATE_88200 | SNDRV_PCM_RATE_96000 |
+   SNDRV_PCM_RATE_176400 | SNDRV_PCM_RATE_192000,
+   .formats = SNDRV_PCM_FMTBIT_S16_LE |
+   SNDRV_PCM_FMTBIT_S24_LE,
+   },
+};
+
+static __devinit int omap_hdmi_codec_probe(struct platform_device *pdev)
+{
+   return snd_soc_register_codec(&pdev->dev, &omap_hdmi_codec,
+   &omap_hdmi_codec_dai, 1);
+}
+
+static __devexit int omap_hdmi_codec_remove(struct platform_device *pdev)
+{
+   snd_soc_unregister_codec(&pdev->dev);
+   return 0;
+}
+
+static struct platform_driver omap_hdmi_codec_driver = {
+   .driver = {
+   .name   = DRV_NAME,
+   .owner  = THIS_MODULE,
+   },
+
+   .probe  = omap_hdmi_codec_probe,
+   .remove = __devexit_p(omap_hdmi_codec_remove),
+};
+
+module_platform_driver(omap_hdmi_codec_driver);
+
+MODULE_AUTHOR("Ricardo Neri ");
+MODULE_DESCRIPTION("ASoC OMAP HDMI codec driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:" DRV_NAME);
diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index deafbfa..9ccfa5e 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -113,6 +113,7 @@ config SND_OMAP_SOC_OMAP4_HDMI
tristate "So

[PATCH 03/11] ASoC: OMAP: HDMI: Change error values in HDMI CPU DAI

[Ricardo Neri]

When getting the needed resources fails, return -ENODEV. This is more
in line with other drivers do and it gives a more descriptive error.

Signed-off-by: Ricardo Neri 
---
 sound/soc/omap/omap-hdmi.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c
index 0925a46..b889f76 100644
--- a/sound/soc/omap/omap-hdmi.c
+++ b/sound/soc/omap/omap-hdmi.c
@@ -106,7 +106,7 @@ static __devinit int omap_hdmi_probe(struct platform_device 
*pdev)
hdmi_rsrc = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!hdmi_rsrc) {
dev_err(&pdev->dev, "Cannot obtain IORESOURCE_MEM HDMI\n");
-   return -EINVAL;
+   return -ENODEV;
}
 
omap_hdmi_dai_dma_params.port_addr =  hdmi_rsrc->start
@@ -115,7 +115,7 @@ static __devinit int omap_hdmi_probe(struct platform_device 
*pdev)
hdmi_rsrc = platform_get_resource(pdev, IORESOURCE_DMA, 0);
if (!hdmi_rsrc) {
dev_err(&pdev->dev, "Cannot obtain IORESOURCE_DMA HDMI\n");
-   return -EINVAL;
+   return -ENODEV;
}
 
omap_hdmi_dai_dma_params.dma_req =  hdmi_rsrc->start;
-- 
1.7.5.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 8/8] gpio/omap: fix missing check in *_runtime_suspend()

[Shilimkar, Santosh]

On Fri, May 18, 2012 at 5:26 AM, Kevin Hilman  wrote:
> Tony Lindgren  writes:
>
>> * Kevin Hilman  [120517 15:29]:
>>>
>>> I just noticed that this patch has caused some strange problems, notably
>>> with the GPIO IRQ used by smsc911x NIC (Overo, Zoom3, 2430SDP, etc. etc.)
>>>
>>> The patch itself is OK, but it has exposed a bug in other parts of the
>>> context restore path that was previously hidden.
>>>
>>> We seem to have been finding lots of GPIO bugs by just testing the
>>> network chips with GPIO IRQs.  Can I suggest that a platform with a GPIO
>>> IRQ NIC be added to the test platforms you're using?
>>
>> Yes considering the breakage it's pretty obvious the original series was
>> never properly tested on omaps.
>
> Agreed.
>
Actually OMAP4 network interface as well uses the GPIO as a interrupt line but
that didn't show the issue. But I agree more and more test scenario's are needed
for infrastructure components like GPIO/DMA/TImer because of their multiple
types of usages.

>> Regarding this fix, using gpio/next + this patch fixes nfsroot for 2430sdp,
>> and gets zoom3 nfsroot booting going a bit better.
>>
>> However, at least on zoom3 nfsroot now takes several _minutes_ to get to
>> login: with gpio/next + this patch. The system is totally unusable.
>>
>> It seems that the GPIO interrupt wake-up events are not properly working
>> now?
>>
>> Reverting the "gpio/omap: fix missing check in *_runtime_suspend()"
>> patch seems to fix the issue.
>
> Argh, then $SUBJECT patch here has caused brokeness in multiple ways.
> It managed to break both runtime suspend and runtime resume at the same
> time. :(
>
> The change added by this patch to runtime_suspend effectively disables
> the fix I did in 68942edb09 (gpio/omap: fix wakeups on level-triggered GPIOs)
> causing the sluggish network problems to reappear, since that GPIO IRQ
> is no longer causing wakeups.
>
That's pretty bad.

> Simple fix is below, which just moves the check added in $SUBJECT patch
> below the workaround for the edge/level fix.  Can you confirm it works
> on Zoom3 (applies on gpio/next + my previous fix.)
>
> I didn't notice the same problem on Overo, but I guess it's because
> Overo had some enabled non-wakeup GPIOs in the same bank, so it didn't
> bypass the level-triggered IRQ fix.
>
>>> Subject: [PATCH] gpio/omap: fix broken context restore for non-OFF mode
>>>  transitions
>>>
>>> The fix in commit 1b12870 (gpio/omap: fix missing check in
>>> *_runtime_suspend()) exposed another bug in the context restore path.
>>
>> Kevin, looks like commit 1b12870 does not exist in gpio/next?
>
> Will update the changelog.
>
> Because of this new problem, I have to add the patch below too, so
> I'll get them both queued up for Grant
>
> In the mean time, they're availble in my for_3.5/fixes/gpio-2 branch.
>
> Kevin
>
> [1]
> From afb4f0836dc3c432aa999fc98a80bf75e1481e04 Mon Sep 17 00:00:00 2001
> From: Kevin Hilman 
> Date: Thu, 17 May 2012 16:42:16 -0700
> Subject: [PATCH] gpio/omap: (re)fix wakeups on level-triggered GPIOs
>
> commit 1b1287032 (gpio/omap: fix missing check in *_runtime_suspend())
> broke wakeups on level-triggered GPIOs by adding the enabled
> non-wakeup GPIO check before the workaround that enables wakeups
> on level-triggered IRQs, effectively disabling that workaround.
>
> To fix, move the enabled non-wakeup GPIO check after the
> level-triggered IRQ workaround.
>
> Reported-by: Tony Lindgren 
>
> Cc: Tarun Kanti DebBarma 
> Signed-off-by: Kevin Hilman 
> ---
Thanks for the Fix Kevin.
Acked-by: Santosh Shilimkar 
--
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: [PATCHv5 3/8] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control register change

[Shilimkar, Santosh]

On Thu, May 17, 2012 at 10:45 PM, Kevin Hilman  wrote:
> "Shilimkar, Santosh"  writes:
>
>> On Wed, May 16, 2012 at 10:21 PM, Kevin Hilman  wrote:
>>> Santosh Shilimkar  writes:
>>>
 Kevin,

 On Wednesday 16 May 2012 02:46 PM, Santosh Shilimkar wrote:
> On Wednesday 16 May 2012 03:14 AM, Kevin Hilman wrote:
>> Santosh,
>>
>> Tero Kristo  writes:
>>
>>> From: Santosh Shilimkar 
>>>
>>> GIC distributor control register has changed between CortexA9 r1pX and
>>> r2pX. The Control Register secure banked version is now composed of 2
>>> bits:
>>>      bit 0 == Secure Enable
>>>      bit 1 == Non-Secure Enable
>>> The Non-Secure banked register has not changed.
>>
>> For those without the r1pX TRM handy, please include what this look like
>> before (presumably 1 bit?)  The changelog and in-code comments should
>> both be enhanced.
>>
> You are right. There was only one bit previously which was used for
> secure/non-secure mode. So ROM over-writes the non-secure bit
> accidentally.
>
>>> Since the ROM Code is based on the r1pX GIC, the CPU1 GIC restoration
>>> will cause a problem to CPU0 Non-Secure SW.
>>
>> Please describe the problem, so we can better understand the specifics
>> of the workaround.
>>
 Below is the updated changelog.
>>>
>>> Much better, thanks.  But it still took me several reads to fully
>>> understand.  Maybe it's because the cold I have is stuffing up my head,
>>> so it takes me awhile to understand...  Anyways, some minor comments to
>>> help clarify...
>>>
>>> Sorry to be so picky about changelogs, but this is a really nasty bug,
>>> and the workaround has some rather important side effects, so I want the
>>> description of the bug and the workaround to be well described.
>>>
 --
 ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control
 register change

 With MPUSS programmed to OSWR(Open Switch retention), GIC context is
 lost. On the CPU wakeup paths, ROM code gets executed which will setup
 GIC secure configurations and restore the GIC context if it was saved
 based on SAR_BACKUP_STATUS.

 The ROM Code GIC distributor restoration is split in two parts:
 CPU specific register done by each CPU and common register done by
 only one CPU. If the GIC Distributor Control Register = 1, the
 second CPU will not do the common GIC restoration.
>>>
>>> s/second CPU/second CPU to wake up/
>>>
>> ok
 GIC distributor control register has changed between CortexA9 r1pX and
 r2pX. The Control Register secure banked version is now composed of 2
 bits vs only one bit before r1px:
>>>
>>> before r1pX?
>> I mean r1px, r0px etc.
>>>
      bit 0 == Secure Enable
      bit 1 == Non-Secure Enable
>>>
>>> And what did this look like for r1pX?    Presumably bit0 was non-secure
>>> enable?
>>>
>> Yes. Same bit is used. It's banked bit which has secure and non-secure view.
>>
 Hence the value of Control register will be 3 and not 1 as the r1pX
 based ROM code expects.
>>>
>>> Why will it be 3?
>>>
>>> Will it be 3 on GP devices?
>>>
>> Yes. Because you have 2 bits. Since both bits will be set [ Bit 1 will
>> be set by ROM code]
>> and bit 0 will be set by Linux.
>
> Why will the secure enable bit be set on GP devices?
>
 So he CPU1 on it's wakeup ROM code path, will
>>>
>>> s/it's/its/
>>>
>> ok
 go to the GIC initialization procedure and will so reset the full GIC
 and NS GIC distributor Enable bit will get cleared.
>>>
>>> This is where it's confusing.
>>>
>> Hmm.
>>
>>> On r2pX, NS enable bit is bit 1.  It's not mentioned here, but I'm
>>> assuming that it's bit 0 on r1pX, right? (I can't seem to find an r1pX
>>> TRM)
>>>
>> Yes. As I mentioned earlier, will make that more clear.
>>
>>> Since ROM code is r1pX-based, I would assume that it would continue to
>>> clear bit 0, which is only now the secure enable bit?
>>>
>>> Or, is it the case that ROM code clears all the bits?  That should be 
>>> described.
>>>
>> ROM code reads the register value and compares it with value == 1
>> " If the GIC Distributor Control Register = 1, the
>> second CPU will not do the common GIC restoration"
>> On r2Px, the value becomes 3 and entire ROM code logic goofs up
>> and take wrong code path.
>
> That part is clear.
>
> What's not at all clear is what the ROM code does *after* this.  Does it
> clear both bits?  or just bit 0?  Since it's r1pX based, I would expect
> that it doesn't touch anything other than bit 0.
>
Actually since the condition of control register == 1 is not satisfied,
It re-inits entire GIC thinking it's not configured at all. So everything
will be cleared and including non-secure GIC dist. enable bit.

 Since the GIC distributor gets disabled in a live system, CPU1 will
 hang because the interrupts stop firing.
      1) Before doing the CPU1 wakeup, CPU0 m

Re: [PATCHv2 15/19] ARM: OMAP4430: PM: workaround for DDR corruption on second CS

[Shilimkar, Santosh]

On Thu, May 17, 2012 at 10:17 PM, Kevin Hilman  wrote:
> "Shilimkar, Santosh"  writes:
>
>> On Thu, May 17, 2012 at 5:45 AM, Kevin Hilman  wrote:
>>> Tero Kristo  writes:
>>>
 From: Santosh Shilimkar 

 Work around for Errata ID: i632 "LPDDR2 Corruption After OFF Mode
 Transition When CS1 Is Used On EMIF" which impacts OMAP443x silicon
 The issue occurs when EMIF_SDRAM_CONFIG is restored first before
 EMIF_SDRAM_CONFIG_2 is not yet restored, the register configuration
 is not set properly, we apply the required workaround allowing
 the restore sequence to work properly.
>>>
>>> Please summarize the workaround here as well.
>>>
>> ok
 Signed-off-by: Santosh Shilimkar 
 [t-kri...@ti.com: moved workaround from omap-sar.c to pm44xx.c]
 Signed-off-by: Tero Kristo 
 ---
  .../include/mach/ctrl_module_wkup_44xx.h           |    2 +
  arch/arm/mach-omap2/pm44xx.c                       |   37 
 
  2 files changed, 39 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h 
 b/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
 index a0af9ba..b763a79 100644
 --- a/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
 +++ b/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
 @@ -28,6 +28,8 @@
  #define OMAP4_CTRL_MODULE_WKUP_IP_REVISION           0x
  #define OMAP4_CTRL_MODULE_WKUP_IP_HWINFO             0x0004
  #define OMAP4_CTRL_MODULE_WKUP_IP_SYSCONFIG          0x0010
 +#define OMAP4_CTRL_SECURE_EMIF1_SDRAM_CONFIG2_REG    0x0114
 +#define OMAP4_CTRL_SECURE_EMIF2_SDRAM_CONFIG2_REG    0x011c
  #define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_0  0x0460
  #define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_1  0x0464
  #define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_2  0x0468
 diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
 index 215b80e..dfaa254 100644
 --- a/arch/arm/mach-omap2/pm44xx.c
 +++ b/arch/arm/mach-omap2/pm44xx.c
 @@ -17,12 +17,18 @@
  #include 
  #include 
  #include 
 +#include 
 +
 +#include 
 +#include 

  #include "common.h"
  #include "clockdomain.h"
  #include "powerdomain.h"
  #include "pm.h"

 +#define EMIF_SDRAM_CONFIG2_OFFSET    0xc
 +
  struct power_state {
       struct powerdomain *pwrdm;
       u32 next_state;
 @@ -215,6 +221,37 @@ static int __init omap4_pm_init(void)

       pr_err("Power Management for TI OMAP4.\n");

 +     /*
 +      * Work around for OMAP443x Errata i632: "LPDDR2 Corruption After OFF
 +      * Mode Transition When CS1 Is Used On EMIF":
 +      * Overwrite EMIF1/EMIF2
 +      * SECURE_EMIF1_SDRAM_CONFIG2_REG
 +      * SECURE_EMIF2_SDRAM_CONFIG2_REG
 +      */
 +     if (cpu_is_omap443x()) {
>>>
>>> This should probably be done later in this function, after PM_ERRATUM
>>> flags are setup, and then it should use a PM_ERRATUM flag instead of cpu_is*
>>>
>> ok
>>
 +             void __iomem *secure_ctrl_mod;
 +             void __iomem *emif1;
 +             void __iomem *emif2;
 +             u32 val;
 +
 +             secure_ctrl_mod = ioremap(OMAP4_CTRL_MODULE_WKUP, SZ_4K);
 +             emif1 = ioremap(OMAP44XX_EMIF1_BASE, SZ_1M);
 +             emif2 = ioremap(OMAP44XX_EMIF2_BASE, SZ_1M);
 +
 +             BUG_ON(!secure_ctrl_mod || !emif1 || !emif2);
>>>
>>> Please avoid BUG_ON() and use proper error recovery.  This is not a
>>> condition where the entire kernel should panic.
>>>
>> Agree. WARN_ON() should suffice.
>
> A WARN_ON() is ok (but noisy).  Better is a pr_warn() with some proper
> error recovery.
>
OK
--
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: [PATCHv2 10/19] ARM: OMAP4: PM: Work-around for ROM code BUG of IVAHD/TESLA

[Shilimkar, Santosh]

On Thu, May 17, 2012 at 10:15 PM, Kevin Hilman  wrote:
> "Shilimkar, Santosh"  writes:
>
>> On Thu, May 17, 2012 at 4:35 AM, Kevin Hilman  wrote:
>>> Tero Kristo  writes:
>>>
 From: Santosh Shilimkar 

 The ROM BUG is when MPU Domain OFF wake up sequence that can compromise
 IVA and Tesla execution.

 At wakeup from MPU OFF on HS device only (not GP device), when
 restoring the Secure RAM, the ROM Code reconfigures the clocks the
 same way it is done at Cold Reset.
>>>
>>> Ouch.
>>>
 The IVAHD Clocks and Power Domain settings are:
       IVAHD_CM2 IVAHD_CLKCTRL_MODULE_MODE = DISABLE
       IVAHD_CM2 SL2_CLKCTRL_MODULE_MODE = DISABLE
       IVAHD_CM2 SL2_CLKSTCTRL_CLKTRCTRL = HW_AUTO
       IVAHD_PRM IVAHD_PWRSTCTRL_POWERSTATE = OFF
 The TESLA Clocks and Power Domain settings are:
       TESLA_CM1 TESLA_CLKCTRL_MODULE_MODE = DISABLE
       TESLA_CM1 TESLA_CLKSTCTRL_CLKTRCTRL = HW_AUTO
       TESLA_PRM TESLA_PWRSTCTRL_POWERSTATE = OFF

 This patch fixes the low power OFF mode code so that the these
 registers are saved and restore across MPU OFF state.

 Also because of this limitation, MPU OFF alone is not targeted without
 device OFF to avoid IVAHD and TESLA execution impact
>>>
>>> I don't see where this restriction is implemented.
>>>
>> It's handled and the patch is in mainline for some time.
>> We de-scoped MPU OFF from OMAP4430 devices in SW and
>> hardware team de-scoped it in hardware from OMAP4460 onwards.
>> Deepest state on MPUSS cluster is OSWR.
>
> The question was about the changelog.
>
> The changelog makes it sound like the restriction is part of the patch,
> but it is not.  Please update the changlog to clarify that, ideally
> adding a reference to the commit you mentioned.
>
Agree.
--
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: [PATCHv2 06/19] ARM: OMAP4: PM: Add SAR backup support towards device OFF

[Shilimkar, Santosh]

On Thu, May 17, 2012 at 10:12 PM, Kevin Hilman  wrote:
> "Shilimkar, Santosh"  writes:
>
>> On Thu, May 17, 2012 at 4:28 AM, Kevin Hilman  wrote:
>>> Tero Kristo  writes:
>>>
 From: Santosh Shilimkar 

 The SAR RAM is maintained during Device OFF mode.
>>>
>>> so why is this patch bothering to save and restore it?
>>>
>> SAR RAM is maintained(not powered down) but somebody needs to
>> feel the contents which will be preserved :-)
>>
>>> -ECONFUSED
>>>
 The register layout
 is fixed in SAR ROM. SAR is split into 4 banks with different
 privilege accesses based on device type

  ---
  Access mode          Bank    Address Range
  ---
  HS/GP : Public               1       0x4A32_6000 - 0x4A32_6FFF (4kB)
  HS/GP : Public               2       0x4A32_7000 - 0x4A32_73FF (1kB)

  HS/EMU : Secured
  GP : Public          3       0x4A32_8000 - 0x4A32_87FF (2kB)

  HS/GP :Secure
  write once.          4       0x4A32_9000 - 0x4A32_93FF (1kB)
  ---

 The save process is done entirely by software and restore is done by
 hardware using the auto-restore feature. The restore feature is enabled
 by default and cannot be disabled. The software must save the data
 to be restored in a dedicated location in SAR RAM.
>>>
>>> Some general comments:
>>>
>>> - can the cluster PM notifier be used for the save path?
>>>
>> Nope. This is for device OFF only case. CPU Cluster state as such
>> has no dependency.
>
> Yeah, I see now.  I like your idea of a device-off notifier chain
> modeled on the CPU PM notifier chain.
>
>>> - This patch adds lots of data that is immediately removed by the next
>>>  patch.  Probably the two just need to be combined.
>>>
>> iormap() hunk from this patch can be completely dropped since
>> it is getting fixed in next patch. Other infrastructure is maintained.
>
> Look again at how much stuff is deleted in the next patch that is added
> in this patch, and think about how a reviewer is supposed to follow that
> easily.
>
OK. With me. Actually with proposed split of further patch, things can
be sorted out in different patches quite well.

>>> - BUG_ON() should not be used unless there is absolutely no recovery
>>>  path, since it casues a full kernel panic.   Instead, some error
>>>  recovery should be added.
>>>
>> WARN_ON should suffice.
>
> Not really.  Error recovery should be added.
>
Agree
--
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 8/8] gpio/omap: fix missing check in *_runtime_suspend()

[DebBarma, Tarun Kanti]

On Fri, May 18, 2012 at 3:51 AM, Kevin Hilman  wrote:
> Tarun, Santosh,
>
> Tarun Kanti DebBarma  writes:
>
>> We do checking for bank->enabled_non_wakeup_gpios in order
>> to skip redundant operations. Somehow, the check got missed
>> while doing the cleanup series.
>>
>> Just to make sure that we do context restore correctly in
>> *_runtime_resume(), the bank->workaround_enabled check is
>> moved after context restore. Otherwise, it would prevent
>> context restore when bank->enabled_non_wakeup_gpios is 0.
>>
>> Cc: Kevin Hilman 
>> Cc: Tony Lindgren 
>> Cc: Santosh Shilimkar 
>> Cc: Cousson, Benoit 
>> Cc: Grant Likely 
>> Signed-off-by: Tarun Kanti DebBarma 
>
> I just noticed that this patch has caused some strange problems, notably
> with the GPIO IRQ used by smsc911x NIC (Overo, Zoom3, 2430SDP, etc. etc.)
>
> The patch itself is OK, but it has exposed a bug in other parts of the
> context restore path that was previously hidden.
>
> We seem to have been finding lots of GPIO bugs by just testing the
> network chips with GPIO IRQs.  Can I suggest that a platform with a GPIO
> IRQ NIC be added to the test platforms you're using?
>
>> ---
>>  drivers/gpio/gpio-omap.c |   13 -
>>  1 files changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> index d238f84..59a4af1 100644
>> --- a/drivers/gpio/gpio-omap.c
>> +++ b/drivers/gpio/gpio-omap.c
>> @@ -1160,6 +1160,9 @@ static int omap_gpio_runtime_suspend(struct device 
>> *dev)
>>
>>       spin_lock_irqsave(&bank->lock, flags);
>>
>> +     if (!bank->enabled_non_wakeup_gpios)
>> +             goto update_gpio_context_count;
>> +
>>       /*
>>        * Only edges can generate a wakeup event to the PRCM.
>>        *
>> @@ -1235,11 +1238,6 @@ static int omap_gpio_runtime_resume(struct device 
>> *dev)
>>       __raw_writel(bank->context.risingdetect,
>>                    bank->base + bank->regs->risingdetect);
>>
>> -     if (!bank->workaround_enabled) {
>> -             spin_unlock_irqrestore(&bank->lock, flags);
>> -             return 0;
>> -     }
>> -
>
> My moving this below, you exposed some buggy code that can now get
> executed in non-OFF mode, wherease before $SUBJECT patch, it would never
> be exectued in non-OFF mode.
>
>>       if (bank->get_context_loss_count) {
>>               context_lost_cnt_after =
>>                       bank->get_context_loss_count(bank->dev);
>
> ...right below this line, we have:
>
>                if (context_lost_cnt_after != bank->context_loss_count ||
>                                                !context_lost_cnt_after) {
>                        omap_gpio_restore_context(bank);
>
> While we've never hit off-mode, context_lost_cnt_after will always be
> zero.  However, becasue of the !context_lost_cnt_after check there, we
> will *always* restore the bank context, even though context has never
> been lost.
>
> I have no idea why that !context_lost_cnt_after check is there, but
> clearly it is wrong.  Now that you moved the 'workraound_enabled' check
> below this section, as long as off-mode is disabled, the some GPIO
> context will be restored here on *every* runtime PM transition.
>
> The patch below fixes the problem.
>
> Grant, after Tarun/Santosh have a chance to review/ack this, can you
> still get this in for 3.5?  If not, getting it into -rc should be fine.
>
> Kevin
>
>
> From 83874df8e0dd78a3609f5ba81d608df7217fd212 Mon Sep 17 00:00:00 2001
> From: Kevin Hilman 
> Date: Thu, 17 May 2012 14:52:56 -0700
> Subject: [PATCH] gpio/omap: fix broken context restore for non-OFF mode
>  transitions
>
> The fix in commit 1b12870 (gpio/omap: fix missing check in
> *_runtime_suspend()) exposed another bug in the context restore path.
>
> Currently, the per-bank context restore happens whenever the context
> loss count is different in runtime suspend and runtime resume *and*
> whenever the per-bank contex_loss_count == 0:
>
>        if (context_lost_cnt_after != bank->context_loss_count ||
>                                        !context_lost_cnt_after) {
>                omap_gpio_restore_context(bank);
>
> Restoring context when the context_lost_cnt_after == 0 is clearly
> wrong, since this will be true until the first off-mode transition
> (which could be never, if off-mode is never enabled.)  This check
> causes the context to be restored on *every* runtime PM transition.
>
> Before commit 1b12870 (gpio/omap: fix missing check in
> *_runtime_suspend()), this code was never executed in non-OFF mode, so
> there were never spurious context restores happening.  After that
> change though, spurious context restores could happen.
>
> To fix, simply remove the !context_lost_cnt_after check. It is not
> needed.
>
> This bug was found when noticing that the smc911x NIC on 3530/Overo
> was not working, and git bisect tracked it down to this patch.  It
> seems that the spurious context restore was causing the smsc911x to
> not be properly probed on thi

Re: [PATCH 8/8] gpio/omap: fix missing check in *_runtime_suspend()

[DebBarma, Tarun Kanti]

On Fri, May 18, 2012 at 5:26 AM, Kevin Hilman  wrote:
> Tony Lindgren  writes:
>
>> * Kevin Hilman  [120517 15:29]:
>>>
>>> I just noticed that this patch has caused some strange problems, notably
>>> with the GPIO IRQ used by smsc911x NIC (Overo, Zoom3, 2430SDP, etc. etc.)
>>>
>>> The patch itself is OK, but it has exposed a bug in other parts of the
>>> context restore path that was previously hidden.
>>>
>>> We seem to have been finding lots of GPIO bugs by just testing the
>>> network chips with GPIO IRQs.  Can I suggest that a platform with a GPIO
>>> IRQ NIC be added to the test platforms you're using?
>>
>> Yes considering the breakage it's pretty obvious the original series was
>> never properly tested on omaps.
>
> Agreed.
>
>> Regarding this fix, using gpio/next + this patch fixes nfsroot for 2430sdp,
>> and gets zoom3 nfsroot booting going a bit better.
>>
>> However, at least on zoom3 nfsroot now takes several _minutes_ to get to
>> login: with gpio/next + this patch. The system is totally unusable.
>>
>> It seems that the GPIO interrupt wake-up events are not properly working
>> now?
>>
>> Reverting the "gpio/omap: fix missing check in *_runtime_suspend()"
>> patch seems to fix the issue.
>
> Argh, then $SUBJECT patch here has caused brokeness in multiple ways.
> It managed to break both runtime suspend and runtime resume at the same
> time. :(
>
> The change added by this patch to runtime_suspend effectively disables
> the fix I did in 68942edb09 (gpio/omap: fix wakeups on level-triggered GPIOs)
> causing the sluggish network problems to reappear, since that GPIO IRQ
> is no longer causing wakeups.
>
> Simple fix is below, which just moves the check added in $SUBJECT patch
> below the workaround for the edge/level fix.  Can you confirm it works
> on Zoom3 (applies on gpio/next + my previous fix.)
>
> I didn't notice the same problem on Overo, but I guess it's because
> Overo had some enabled non-wakeup GPIOs in the same bank, so it didn't
> bypass the level-triggered IRQ fix.
>
>>> Subject: [PATCH] gpio/omap: fix broken context restore for non-OFF mode
>>>  transitions
>>>
>>> The fix in commit 1b12870 (gpio/omap: fix missing check in
>>> *_runtime_suspend()) exposed another bug in the context restore path.
>>
>> Kevin, looks like commit 1b12870 does not exist in gpio/next?
>
> Will update the changelog.
>
> Because of this new problem, I have to add the patch below too, so
> I'll get them both queued up for Grant
>
> In the mean time, they're availble in my for_3.5/fixes/gpio-2 branch.
>
> Kevin
>
> [1]
> From afb4f0836dc3c432aa999fc98a80bf75e1481e04 Mon Sep 17 00:00:00 2001
> From: Kevin Hilman 
> Date: Thu, 17 May 2012 16:42:16 -0700
> Subject: [PATCH] gpio/omap: (re)fix wakeups on level-triggered GPIOs
>
> commit 1b1287032 (gpio/omap: fix missing check in *_runtime_suspend())
> broke wakeups on level-triggered GPIOs by adding the enabled
> non-wakeup GPIO check before the workaround that enables wakeups
> on level-triggered IRQs, effectively disabling that workaround.
>
> To fix, move the enabled non-wakeup GPIO check after the
> level-triggered IRQ workaround.
>
> Reported-by: Tony Lindgren 
> Cc: Santosh Shilimkar 
> Cc: Tarun Kanti DebBarma 
> Signed-off-by: Kevin Hilman 

Acked-by: Tarun Kanti DebBarma 

> ---
>  drivers/gpio/gpio-omap.c |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index b570a6a..c4ed172 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -1157,9 +1157,6 @@ static int omap_gpio_runtime_suspend(struct device *dev)
>
>        spin_lock_irqsave(&bank->lock, flags);
>
> -       if (!bank->enabled_non_wakeup_gpios)
> -               goto update_gpio_context_count;
> -
>        /*
>         * Only edges can generate a wakeup event to the PRCM.
>         *
> @@ -1180,6 +1177,9 @@ static int omap_gpio_runtime_suspend(struct device *dev)
>                __raw_writel(wake_hi | bank->context.risingdetect,
>                             bank->base + bank->regs->risingdetect);
>
> +       if (!bank->enabled_non_wakeup_gpios)
> +               goto update_gpio_context_count;
> +
>        if (bank->power_mode != OFF_MODE) {
>                bank->power_mode = 0;
>                goto update_gpio_context_count;
> --
> 1.7.9.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: OMAP2+: fix gpmc request_irq

[Ming Lei]

The IRQ52 on OMAP2+ is not a shared interrupt line. If IRQF_SHARED
is passed to request_irq and dev_id is set as NULL, request_irq will
return -EINVAL.

This patch just removes the flag of IRQF_SHARED to make the irq
registration successful.

Cc: Kevin Hilman 
Cc: Tony Lindgren 
Signed-off-by: Ming Lei 
---
 arch/arm/mach-omap2/gpmc.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 2286410..e45d31b 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -769,7 +769,7 @@ static int __init gpmc_init(void)
irq++;
}
 
-   ret = request_irq(gpmc_irq, gpmc_handle_irq, IRQF_SHARED, "gpmc", NULL);
+   ret = request_irq(gpmc_irq, gpmc_handle_irq, 0, "gpmc", NULL);
if (ret)
pr_err("gpmc: irq-%d could not claim: err %d\n",
gpmc_irq, ret);
-- 
1.7.9.5

--
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: [RESEND/PATCHv2] Input: omap-keypad: dynamically handle register offsets

[Poddar, Sourav]

On Thu, May 17, 2012 at 8:55 PM, Dmitry Torokhov
 wrote:
> Hi Sourav,
>
> On Thu, May 17, 2012 at 07:01:49PM +0530, Poddar, Sourav wrote:
>> Hi Dmitry,
>>
>> Gentle Ping on this..
>
> The patch has been committed to my 'next' branch for 3.5 on 05/11/12:
>
Thanks.
> http://git.kernel.org/?p=linux/kernel/git/dtor/input.git;a=commit;h=f77621cc640a7c50b3d8c5254ecc5d91eaa99d0d
>
> Thanks.
>
> --
> Dmitry
--
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 8/8] gpio/omap: fix missing check in *_runtime_suspend()

[Tony Lindgren]

* Kevin Hilman  [120517 17:00]:
> 
> Argh, then $SUBJECT patch here has caused brokeness in multiple ways.
> It managed to break both runtime suspend and runtime resume at the same
> time. :(
> 
> The change added by this patch to runtime_suspend effectively disables
> the fix I did in 68942edb09 (gpio/omap: fix wakeups on level-triggered GPIOs)
> causing the sluggish network problems to reappear, since that GPIO IRQ
> is no longer causing wakeups.
>
> Simple fix is below, which just moves the check added in $SUBJECT patch
> below the workaround for the edge/level fix.  Can you confirm it works
> on Zoom3 (applies on gpio/next + my previous fix.)

Thanks yes having both of your fixes applied fixes the issues I was
seeing, so for both:

Tested-by: Tony Lindgren 
 
> I didn't notice the same problem on Overo, but I guess it's because
> Overo had some enabled non-wakeup GPIOs in the same bank, so it didn't
> bypass the level-triggered IRQ fix.

Makes sense for why it only appears on some boards.
 
> In the mean time, they're availble in my for_3.5/fixes/gpio-2 branch.

I'll merge that also into l-o master for some more testing before
the merge window.

Regards,

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

Re: [GIT PULL] misc omap fixes for 3.5

[Tony Lindgren]

* Ohad Ben-Cohen  [120516 02:58]:
> Hi Tony,
> 
> Two important fixes from Juan that are necessary to utilize the DSP on
> OMAP4, and a trivial hwspinlock cleanup.
> 
> I tried to keep things as simple as possible, but please tell me if
> you want this pull request anyway differently (e.g. split to two
> separate fixes/cleanups requests, use an annotated signed tag, etc..).

In general, yes fixes, cleanup, and devel should be all separate.

These all look like valid -rc1 fixes for me though, so pulling into
fixes-omap4-dsp branch and merging into l-o master for testing.

Regards,

Tony
 
> The following changes since commit d48b97b403d23f6df0b990cee652bdf9a52337a3:
> 
>   Linux 3.4-rc6 (2012-05-06 15:07:32 -0700)
> 
> are available in the git repository at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/ohad/linux.git for-tony
> 
> Juan Gutierrez (2):
>   ARM: OMAP: enable mailbox irq per instance
>   ARM: OMAP4: fix irq and clock name for dsp-iommu
> 
> Ohad Ben-Cohen (1):
>   ARM: OMAP4: hwspinlocks_init() should be static
> 
>  arch/arm/mach-omap2/hwspinlock.c |2 +-
>  arch/arm/mach-omap2/mailbox.c|2 --
>  arch/arm/mach-omap2/omap-iommu.c |6 ++
>  arch/arm/plat-omap/mailbox.c |   13 +
>  4 files changed, 12 insertions(+), 11 deletions(-)
> 
> 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

Re: [PATCH 8/8] gpio/omap: fix missing check in *_runtime_suspend()

[Kevin Hilman]

Tony Lindgren  writes:

> * Kevin Hilman  [120517 15:29]:
>> 
>> I just noticed that this patch has caused some strange problems, notably
>> with the GPIO IRQ used by smsc911x NIC (Overo, Zoom3, 2430SDP, etc. etc.)
>> 
>> The patch itself is OK, but it has exposed a bug in other parts of the
>> context restore path that was previously hidden.
>> 
>> We seem to have been finding lots of GPIO bugs by just testing the
>> network chips with GPIO IRQs.  Can I suggest that a platform with a GPIO
>> IRQ NIC be added to the test platforms you're using? 
>
> Yes considering the breakage it's pretty obvious the original series was
> never properly tested on omaps.

Agreed.

> Regarding this fix, using gpio/next + this patch fixes nfsroot for 2430sdp,
> and gets zoom3 nfsroot booting going a bit better.
>
> However, at least on zoom3 nfsroot now takes several _minutes_ to get to
> login: with gpio/next + this patch. The system is totally unusable.
>
> It seems that the GPIO interrupt wake-up events are not properly working
> now?
>
> Reverting the "gpio/omap: fix missing check in *_runtime_suspend()"
> patch seems to fix the issue.

Argh, then $SUBJECT patch here has caused brokeness in multiple ways.
It managed to break both runtime suspend and runtime resume at the same
time. :(

The change added by this patch to runtime_suspend effectively disables
the fix I did in 68942edb09 (gpio/omap: fix wakeups on level-triggered GPIOs)
causing the sluggish network problems to reappear, since that GPIO IRQ
is no longer causing wakeups.

Simple fix is below, which just moves the check added in $SUBJECT patch
below the workaround for the edge/level fix.  Can you confirm it works
on Zoom3 (applies on gpio/next + my previous fix.)

I didn't notice the same problem on Overo, but I guess it's because
Overo had some enabled non-wakeup GPIOs in the same bank, so it didn't
bypass the level-triggered IRQ fix.

>> Subject: [PATCH] gpio/omap: fix broken context restore for non-OFF mode
>>  transitions
>> 
>> The fix in commit 1b12870 (gpio/omap: fix missing check in
>> *_runtime_suspend()) exposed another bug in the context restore path.
>
> Kevin, looks like commit 1b12870 does not exist in gpio/next?

Will update the changelog.

Because of this new problem, I have to add the patch below too, so
I'll get them both queued up for Grant

In the mean time, they're availble in my for_3.5/fixes/gpio-2 branch.

Kevin

[1]
>From afb4f0836dc3c432aa999fc98a80bf75e1481e04 Mon Sep 17 00:00:00 2001
From: Kevin Hilman 
Date: Thu, 17 May 2012 16:42:16 -0700
Subject: [PATCH] gpio/omap: (re)fix wakeups on level-triggered GPIOs

commit 1b1287032 (gpio/omap: fix missing check in *_runtime_suspend())
broke wakeups on level-triggered GPIOs by adding the enabled
non-wakeup GPIO check before the workaround that enables wakeups
on level-triggered IRQs, effectively disabling that workaround.

To fix, move the enabled non-wakeup GPIO check after the
level-triggered IRQ workaround.

Reported-by: Tony Lindgren 
Cc: Santosh Shilimkar 
Cc: Tarun Kanti DebBarma 
Signed-off-by: Kevin Hilman 
---
 drivers/gpio/gpio-omap.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index b570a6a..c4ed172 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1157,9 +1157,6 @@ static int omap_gpio_runtime_suspend(struct device *dev)
 
spin_lock_irqsave(&bank->lock, flags);
 
-   if (!bank->enabled_non_wakeup_gpios)
-   goto update_gpio_context_count;
-
/*
 * Only edges can generate a wakeup event to the PRCM.
 *
@@ -1180,6 +1177,9 @@ static int omap_gpio_runtime_suspend(struct device *dev)
__raw_writel(wake_hi | bank->context.risingdetect,
 bank->base + bank->regs->risingdetect);
 
+   if (!bank->enabled_non_wakeup_gpios)
+   goto update_gpio_context_count;
+
if (bank->power_mode != OFF_MODE) {
bank->power_mode = 0;
goto update_gpio_context_count;
-- 
1.7.9.2

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

Re: [PATCH 8/8] gpio/omap: fix missing check in *_runtime_suspend()

[Grant Likely]

On Thu, 17 May 2012 15:21:07 -0700, Kevin Hilman  wrote:
> Tarun, Santosh,
> 
> Tarun Kanti DebBarma  writes:
> 
> > We do checking for bank->enabled_non_wakeup_gpios in order
> > to skip redundant operations. Somehow, the check got missed
> > while doing the cleanup series.
> >
> > Just to make sure that we do context restore correctly in
> > *_runtime_resume(), the bank->workaround_enabled check is
> > moved after context restore. Otherwise, it would prevent
> > context restore when bank->enabled_non_wakeup_gpios is 0.
> >
> > Cc: Kevin Hilman 
> > Cc: Tony Lindgren 
> > Cc: Santosh Shilimkar 
> > Cc: Cousson, Benoit 
> > Cc: Grant Likely 
> > Signed-off-by: Tarun Kanti DebBarma 
> 
> I just noticed that this patch has caused some strange problems, notably
> with the GPIO IRQ used by smsc911x NIC (Overo, Zoom3, 2430SDP, etc. etc.)
> 
> The patch itself is OK, but it has exposed a bug in other parts of the
> context restore path that was previously hidden.
> 
> We seem to have been finding lots of GPIO bugs by just testing the
> network chips with GPIO IRQs.  Can I suggest that a platform with a GPIO
> IRQ NIC be added to the test platforms you're using? 
> 
> > ---
> >  drivers/gpio/gpio-omap.c |   13 -
> >  1 files changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> > index d238f84..59a4af1 100644
> > --- a/drivers/gpio/gpio-omap.c
> > +++ b/drivers/gpio/gpio-omap.c
> > @@ -1160,6 +1160,9 @@ static int omap_gpio_runtime_suspend(struct device 
> > *dev)
> >  
> > spin_lock_irqsave(&bank->lock, flags);
> >  
> > +   if (!bank->enabled_non_wakeup_gpios)
> > +   goto update_gpio_context_count;
> > +
> > /*
> >  * Only edges can generate a wakeup event to the PRCM.
> >  *
> > @@ -1235,11 +1238,6 @@ static int omap_gpio_runtime_resume(struct device 
> > *dev)
> > __raw_writel(bank->context.risingdetect,
> >  bank->base + bank->regs->risingdetect);
> >  
> > -   if (!bank->workaround_enabled) {
> > -   spin_unlock_irqrestore(&bank->lock, flags);
> > -   return 0;
> > -   }
> > -
> 
> My moving this below, you exposed some buggy code that can now get
> executed in non-OFF mode, wherease before $SUBJECT patch, it would never
> be exectued in non-OFF mode.
> 
> > if (bank->get_context_loss_count) {
> > context_lost_cnt_after =
> > bank->get_context_loss_count(bank->dev);
> 
> ...right below this line, we have:
> 
>   if (context_lost_cnt_after != bank->context_loss_count ||
>   !context_lost_cnt_after) {
>   omap_gpio_restore_context(bank);
> 
> While we've never hit off-mode, context_lost_cnt_after will always be
> zero.  However, becasue of the !context_lost_cnt_after check there, we
> will *always* restore the bank context, even though context has never
> been lost.
> 
> I have no idea why that !context_lost_cnt_after check is there, but
> clearly it is wrong.  Now that you moved the 'workraound_enabled' check
> below this section, as long as off-mode is disabled, the some GPIO
> context will be restored here on *every* runtime PM transition.
> 
> The patch below fixes the problem.
> 
> Grant, after Tarun/Santosh have a chance to review/ack this, can you
> still get this in for 3.5?  If not, getting it into -rc should be fine.

Yes.  Do you have any other omap patches?  Do you want to send me a
pull req?

g.

> > Kevin
> 
> 
> From 83874df8e0dd78a3609f5ba81d608df7217fd212 Mon Sep 17 00:00:00 2001
> From: Kevin Hilman 
> Date: Thu, 17 May 2012 14:52:56 -0700
> Subject: [PATCH] gpio/omap: fix broken context restore for non-OFF mode
>  transitions
> 
> The fix in commit 1b12870 (gpio/omap: fix missing check in
> *_runtime_suspend()) exposed another bug in the context restore path.
> 
> Currently, the per-bank context restore happens whenever the context
> loss count is different in runtime suspend and runtime resume *and*
> whenever the per-bank contex_loss_count == 0:
> 
>   if (context_lost_cnt_after != bank->context_loss_count ||
>   !context_lost_cnt_after) {
>   omap_gpio_restore_context(bank);
> 
> Restoring context when the context_lost_cnt_after == 0 is clearly
> wrong, since this will be true until the first off-mode transition
> (which could be never, if off-mode is never enabled.)  This check
> causes the context to be restored on *every* runtime PM transition.
> 
> Before commit 1b12870 (gpio/omap: fix missing check in
> *_runtime_suspend()), this code was never executed in non-OFF mode, so
> there were never spurious context restores happening.  After that
> change though, spurious context restores could happen.
> 
> To fix, simply remove the !context_lost_cnt_after check. It is not
> needed.
> 
> This bug was found when noticing that the smc911x NIC on 3530/Overo
> was not working, and git bisect tracked 

Re: [PATCH 8/8] gpio/omap: fix missing check in *_runtime_suspend()

[Tony Lindgren]

* Kevin Hilman  [120517 15:29]:
> 
> I just noticed that this patch has caused some strange problems, notably
> with the GPIO IRQ used by smsc911x NIC (Overo, Zoom3, 2430SDP, etc. etc.)
> 
> The patch itself is OK, but it has exposed a bug in other parts of the
> context restore path that was previously hidden.
> 
> We seem to have been finding lots of GPIO bugs by just testing the
> network chips with GPIO IRQs.  Can I suggest that a platform with a GPIO
> IRQ NIC be added to the test platforms you're using? 

Yes considering the breakage it's pretty obvious the original series was
never properly tested on omaps.

Regarding this fix, using gpio/next + this patch fixes nfsroot for 2430sdp,
and gets zoom3 nfsroot booting going a bit better.

However, at least on zoom3 nfsroot now takes several _minutes_ to get to
login: with gpio/next + this patch. The system is totally unusable.

It seems that the GPIO interrupt wake-up events are not properly working
now?

Reverting the "gpio/omap: fix missing check in *_runtime_suspend()"
patch seems to fix the issue.

> Subject: [PATCH] gpio/omap: fix broken context restore for non-OFF mode
>  transitions
> 
> The fix in commit 1b12870 (gpio/omap: fix missing check in
> *_runtime_suspend()) exposed another bug in the context restore path.

Kevin, looks like commit 1b12870 does not exist in gpio/next?

Regards,

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

Re: [PATCH 8/8] gpio/omap: fix missing check in *_runtime_suspend()

[Kevin Hilman]

Tarun, Santosh,

Tarun Kanti DebBarma  writes:

> We do checking for bank->enabled_non_wakeup_gpios in order
> to skip redundant operations. Somehow, the check got missed
> while doing the cleanup series.
>
> Just to make sure that we do context restore correctly in
> *_runtime_resume(), the bank->workaround_enabled check is
> moved after context restore. Otherwise, it would prevent
> context restore when bank->enabled_non_wakeup_gpios is 0.
>
> Cc: Kevin Hilman 
> Cc: Tony Lindgren 
> Cc: Santosh Shilimkar 
> Cc: Cousson, Benoit 
> Cc: Grant Likely 
> Signed-off-by: Tarun Kanti DebBarma 

I just noticed that this patch has caused some strange problems, notably
with the GPIO IRQ used by smsc911x NIC (Overo, Zoom3, 2430SDP, etc. etc.)

The patch itself is OK, but it has exposed a bug in other parts of the
context restore path that was previously hidden.

We seem to have been finding lots of GPIO bugs by just testing the
network chips with GPIO IRQs.  Can I suggest that a platform with a GPIO
IRQ NIC be added to the test platforms you're using? 

> ---
>  drivers/gpio/gpio-omap.c |   13 -
>  1 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index d238f84..59a4af1 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -1160,6 +1160,9 @@ static int omap_gpio_runtime_suspend(struct device *dev)
>  
>   spin_lock_irqsave(&bank->lock, flags);
>  
> + if (!bank->enabled_non_wakeup_gpios)
> + goto update_gpio_context_count;
> +
>   /*
>* Only edges can generate a wakeup event to the PRCM.
>*
> @@ -1235,11 +1238,6 @@ static int omap_gpio_runtime_resume(struct device *dev)
>   __raw_writel(bank->context.risingdetect,
>bank->base + bank->regs->risingdetect);
>  
> - if (!bank->workaround_enabled) {
> - spin_unlock_irqrestore(&bank->lock, flags);
> - return 0;
> - }
> -

My moving this below, you exposed some buggy code that can now get
executed in non-OFF mode, wherease before $SUBJECT patch, it would never
be exectued in non-OFF mode.

>   if (bank->get_context_loss_count) {
>   context_lost_cnt_after =
>   bank->get_context_loss_count(bank->dev);

...right below this line, we have:

if (context_lost_cnt_after != bank->context_loss_count ||
!context_lost_cnt_after) {
omap_gpio_restore_context(bank);

While we've never hit off-mode, context_lost_cnt_after will always be
zero.  However, becasue of the !context_lost_cnt_after check there, we
will *always* restore the bank context, even though context has never
been lost.

I have no idea why that !context_lost_cnt_after check is there, but
clearly it is wrong.  Now that you moved the 'workraound_enabled' check
below this section, as long as off-mode is disabled, the some GPIO
context will be restored here on *every* runtime PM transition.

The patch below fixes the problem.

Grant, after Tarun/Santosh have a chance to review/ack this, can you
still get this in for 3.5?  If not, getting it into -rc should be fine.

Kevin


>From 83874df8e0dd78a3609f5ba81d608df7217fd212 Mon Sep 17 00:00:00 2001
From: Kevin Hilman 
Date: Thu, 17 May 2012 14:52:56 -0700
Subject: [PATCH] gpio/omap: fix broken context restore for non-OFF mode
 transitions

The fix in commit 1b12870 (gpio/omap: fix missing check in
*_runtime_suspend()) exposed another bug in the context restore path.

Currently, the per-bank context restore happens whenever the context
loss count is different in runtime suspend and runtime resume *and*
whenever the per-bank contex_loss_count == 0:

if (context_lost_cnt_after != bank->context_loss_count ||
!context_lost_cnt_after) {
omap_gpio_restore_context(bank);

Restoring context when the context_lost_cnt_after == 0 is clearly
wrong, since this will be true until the first off-mode transition
(which could be never, if off-mode is never enabled.)  This check
causes the context to be restored on *every* runtime PM transition.

Before commit 1b12870 (gpio/omap: fix missing check in
*_runtime_suspend()), this code was never executed in non-OFF mode, so
there were never spurious context restores happening.  After that
change though, spurious context restores could happen.

To fix, simply remove the !context_lost_cnt_after check. It is not
needed.

This bug was found when noticing that the smc911x NIC on 3530/Overo
was not working, and git bisect tracked it down to this patch.  It
seems that the spurious context restore was causing the smsc911x to
not be properly probed on this platform.

Cc: Tarun Kanti DebBarma 
Cc: Santosh Shilimkar 
Signed-off-by: Kevin Hilman 
---
 drivers/gpio/gpio-omap.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/driver

Re: [PATCH 2/9] ARM: OMAP2+: Remove unused max number of timers definition

[Kevin Hilman]

Jon Hunter  writes:

> From: Jon Hunter 
>
> The OMAP2+ timer code has a definition for the maximum number of timers that
> OMAP2+ devices have. This defintion is not used anywhere in the code and
> appears to be left over. Furthermore the definition is not accurate for OMAP4
> devices that only have 11 timers available because the 12th timer is reserved
> as a secure timer. Therefore, remove this definition.

changelog nit: the 12th timer is secure on OMAP3 HS devices also.

Kevin

> Signed-off-by: Jon Hunter 
> ---
>  arch/arm/mach-omap2/timer.c |3 ---
>  1 files changed, 0 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 840929b..c030dfe 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -69,9 +69,6 @@
>  #define OMAP3_SECURE_TIMER   1
>  #endif
>  
> -/* MAX_GPTIMER_ID: number of GPTIMERs on the chip */
> -#define MAX_GPTIMER_ID   12
> -
>  static u32 sys_timer_reserved;
>  
>  /* Clockevent 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: [PATCH V3 1/2] of: Add generic device tree DMA helpers

[Stephen Warren]

On 05/16/2012 03:16 PM, Jassi Brar wrote:
> On 17 May 2012 01:12, Arnd Bergmann  wrote:
...
>> More importantly, you make it very hard to add devices in a board file
>> to a dma controller that already has descriptions for some channels,
>> because you cannot easily extend the chan-map unless you rewrite all of it.
>>
> I am not sure I understand the point.

Ah yes, Arnd has a good point.

If the DMA request routing information is in each client node, then it's
trivial to add DMA clients to board files; you just put the
board-specific nodes and properties in the board file, and there's no
possibility of conflicts; you aren't having to add to or override any
existing property in the base SoC file.

(As background, most ARM device trees are separated out into 1 file
defining all the SoC devices e.g. soc.dtsi, and a separate file for each
board e.g. board.dts, which includes the SoC file.)

Now, the DMA node for an on-SoC DMAC would be in soc.dtsi. Typically,
the DMAC is connected to many on-SoC devices, and hence soc.dtsi would
need to specify the routing information for all those devices to avoid
duplicating it in every board.dts. Now, if you have some DMA requests
that go off-SoC, the board.dts file might want to add to the routing
table to indicate what clients connect to those DMA requests. However,
there's no way in the device tree compiler right now to add to a
property; you can only completely replace it. That would entail
duplicating the entire routing information from soc.dtsi into each
board.dts that wanted to add to it - a bad situation. Splitting the
routing information into chunks in the client nodes avoids this issue
entirely.
--
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/7] remoteproc: resource table overhaul

[Ohad Ben-Cohen]

Hi Michal,

On Sat, Mar 17, 2012 at 8:39 AM, Ohad Ben-Cohen  wrote:
> IOW: you can probably just wait a bit until this patch is ready and
> take it into your tree. It will most likely bring back the behavior you
> need :)

Does something like the attached help ?

Thanks,
Ohad.


0001-remoteproc-allocate-vrings-on-demand-free-when-not-n.patch
Description: Binary data

Re: [PATCHv5 3/8] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control register change

[Kevin Hilman]

"Shilimkar, Santosh"  writes:

> On Wed, May 16, 2012 at 10:21 PM, Kevin Hilman  wrote:
>> Santosh Shilimkar  writes:
>>
>>> Kevin,
>>>
>>> On Wednesday 16 May 2012 02:46 PM, Santosh Shilimkar wrote:
 On Wednesday 16 May 2012 03:14 AM, Kevin Hilman wrote:
> Santosh,
>
> Tero Kristo  writes:
>
>> From: Santosh Shilimkar 
>>
>> GIC distributor control register has changed between CortexA9 r1pX and
>> r2pX. The Control Register secure banked version is now composed of 2
>> bits:
>>      bit 0 == Secure Enable
>>      bit 1 == Non-Secure Enable
>> The Non-Secure banked register has not changed.
>
> For those without the r1pX TRM handy, please include what this look like
> before (presumably 1 bit?)  The changelog and in-code comments should
> both be enhanced.
>
 You are right. There was only one bit previously which was used for
 secure/non-secure mode. So ROM over-writes the non-secure bit
 accidentally.

>> Since the ROM Code is based on the r1pX GIC, the CPU1 GIC restoration
>> will cause a problem to CPU0 Non-Secure SW.
>
> Please describe the problem, so we can better understand the specifics
> of the workaround.
>
>>> Below is the updated changelog.
>>
>> Much better, thanks.  But it still took me several reads to fully
>> understand.  Maybe it's because the cold I have is stuffing up my head,
>> so it takes me awhile to understand...  Anyways, some minor comments to
>> help clarify...
>>
>> Sorry to be so picky about changelogs, but this is a really nasty bug,
>> and the workaround has some rather important side effects, so I want the
>> description of the bug and the workaround to be well described.
>>
>>> --
>>> ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control
>>> register change
>>>
>>> With MPUSS programmed to OSWR(Open Switch retention), GIC context is
>>> lost. On the CPU wakeup paths, ROM code gets executed which will setup
>>> GIC secure configurations and restore the GIC context if it was saved
>>> based on SAR_BACKUP_STATUS.
>>>
>>> The ROM Code GIC distributor restoration is split in two parts:
>>> CPU specific register done by each CPU and common register done by
>>> only one CPU. If the GIC Distributor Control Register = 1, the
>>> second CPU will not do the common GIC restoration.
>>
>> s/second CPU/second CPU to wake up/
>>
> ok
>>> GIC distributor control register has changed between CortexA9 r1pX and
>>> r2pX. The Control Register secure banked version is now composed of 2
>>> bits vs only one bit before r1px:
>>
>> before r1pX?
> I mean r1px, r0px etc.
>>
>>>      bit 0 == Secure Enable
>>>      bit 1 == Non-Secure Enable
>>
>> And what did this look like for r1pX?    Presumably bit0 was non-secure
>> enable?
>>
> Yes. Same bit is used. It's banked bit which has secure and non-secure view.
>
>>> Hence the value of Control register will be 3 and not 1 as the r1pX
>>> based ROM code expects.
>>
>> Why will it be 3?
>>
>> Will it be 3 on GP devices?
>>
> Yes. Because you have 2 bits. Since both bits will be set [ Bit 1 will
> be set by ROM code]
> and bit 0 will be set by Linux.

Why will the secure enable bit be set on GP devices?

>>> So he CPU1 on it's wakeup ROM code path, will
>>
>> s/it's/its/
>>
> ok
>>> go to the GIC initialization procedure and will so reset the full GIC
>>> and NS GIC distributor Enable bit will get cleared.
>>
>> This is where it's confusing.
>>
> Hmm.
>
>> On r2pX, NS enable bit is bit 1.  It's not mentioned here, but I'm
>> assuming that it's bit 0 on r1pX, right? (I can't seem to find an r1pX
>> TRM)
>>
> Yes. As I mentioned earlier, will make that more clear.
>
>> Since ROM code is r1pX-based, I would assume that it would continue to
>> clear bit 0, which is only now the secure enable bit?
>>
>> Or, is it the case that ROM code clears all the bits?  That should be 
>> described.
>>
> ROM code reads the register value and compares it with value == 1
> " If the GIC Distributor Control Register = 1, the
> second CPU will not do the common GIC restoration"
> On r2Px, the value becomes 3 and entire ROM code logic goofs up
> and take wrong code path.

That part is clear.  

What's not at all clear is what the ROM code does *after* this.  Does it
clear both bits?  or just bit 0?  Since it's r1pX based, I would expect
that it doesn't touch anything other than bit 0.

>>> Since the GIC distributor gets disabled in a live system, CPU1 will
>>> hang because the interrupts stop firing.
>>>      1) Before doing the CPU1 wakeup, CPU0 must disable
>>>         the GIC distributor and wait for it to be enabled.
>>
>> what does 'disable GIC distributor' mean.  secure? non-secure? both?
>>
> HLOS is a non-secure view so it can disable only non-secure bit.

The changelog is not talking about the HLOS, it's talking about the ROM
code, which presumably can set/clear both bits.

>>>      2) CPU1 must re-enable the GIC distributor on
>>>

Re: [PATCH 0/9] ARM: OMAP: DMTIMER clean-up in preparation for device-tree

[Paul Walmsley]

On Thu, 17 May 2012, Jon Hunter wrote:

> Yes that's right. What is your preference here, the options are ...
> 
> 1. Move the clkt_clksel.c file to arch/arm/plat-omap and change the
> omap2_xxx API names to omap_xxx.
> 2. Add the functions in clkt_clksel.c to arch/arm/plat-omap/clock.c and
> get rid of clkt_clksel.c altogether.

#1.


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

Re: [PATCHv2 15/19] ARM: OMAP4430: PM: workaround for DDR corruption on second CS

[Kevin Hilman]

"Shilimkar, Santosh"  writes:

> On Thu, May 17, 2012 at 5:45 AM, Kevin Hilman  wrote:
>> Tero Kristo  writes:
>>
>>> From: Santosh Shilimkar 
>>>
>>> Work around for Errata ID: i632 "LPDDR2 Corruption After OFF Mode
>>> Transition When CS1 Is Used On EMIF" which impacts OMAP443x silicon
>>> The issue occurs when EMIF_SDRAM_CONFIG is restored first before
>>> EMIF_SDRAM_CONFIG_2 is not yet restored, the register configuration
>>> is not set properly, we apply the required workaround allowing
>>> the restore sequence to work properly.
>>
>> Please summarize the workaround here as well.
>>
> ok
>>> Signed-off-by: Santosh Shilimkar 
>>> [t-kri...@ti.com: moved workaround from omap-sar.c to pm44xx.c]
>>> Signed-off-by: Tero Kristo 
>>> ---
>>>  .../include/mach/ctrl_module_wkup_44xx.h           |    2 +
>>>  arch/arm/mach-omap2/pm44xx.c                       |   37 
>>> 
>>>  2 files changed, 39 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h 
>>> b/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
>>> index a0af9ba..b763a79 100644
>>> --- a/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
>>> +++ b/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
>>> @@ -28,6 +28,8 @@
>>>  #define OMAP4_CTRL_MODULE_WKUP_IP_REVISION           0x
>>>  #define OMAP4_CTRL_MODULE_WKUP_IP_HWINFO             0x0004
>>>  #define OMAP4_CTRL_MODULE_WKUP_IP_SYSCONFIG          0x0010
>>> +#define OMAP4_CTRL_SECURE_EMIF1_SDRAM_CONFIG2_REG    0x0114
>>> +#define OMAP4_CTRL_SECURE_EMIF2_SDRAM_CONFIG2_REG    0x011c
>>>  #define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_0  0x0460
>>>  #define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_1  0x0464
>>>  #define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_2  0x0468
>>> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
>>> index 215b80e..dfaa254 100644
>>> --- a/arch/arm/mach-omap2/pm44xx.c
>>> +++ b/arch/arm/mach-omap2/pm44xx.c
>>> @@ -17,12 +17,18 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>> +
>>> +#include 
>>> +#include 
>>>
>>>  #include "common.h"
>>>  #include "clockdomain.h"
>>>  #include "powerdomain.h"
>>>  #include "pm.h"
>>>
>>> +#define EMIF_SDRAM_CONFIG2_OFFSET    0xc
>>> +
>>>  struct power_state {
>>>       struct powerdomain *pwrdm;
>>>       u32 next_state;
>>> @@ -215,6 +221,37 @@ static int __init omap4_pm_init(void)
>>>
>>>       pr_err("Power Management for TI OMAP4.\n");
>>>
>>> +     /*
>>> +      * Work around for OMAP443x Errata i632: "LPDDR2 Corruption After OFF
>>> +      * Mode Transition When CS1 Is Used On EMIF":
>>> +      * Overwrite EMIF1/EMIF2
>>> +      * SECURE_EMIF1_SDRAM_CONFIG2_REG
>>> +      * SECURE_EMIF2_SDRAM_CONFIG2_REG
>>> +      */
>>> +     if (cpu_is_omap443x()) {
>>
>> This should probably be done later in this function, after PM_ERRATUM
>> flags are setup, and then it should use a PM_ERRATUM flag instead of cpu_is*
>>
> ok
>
>>> +             void __iomem *secure_ctrl_mod;
>>> +             void __iomem *emif1;
>>> +             void __iomem *emif2;
>>> +             u32 val;
>>> +
>>> +             secure_ctrl_mod = ioremap(OMAP4_CTRL_MODULE_WKUP, SZ_4K);
>>> +             emif1 = ioremap(OMAP44XX_EMIF1_BASE, SZ_1M);
>>> +             emif2 = ioremap(OMAP44XX_EMIF2_BASE, SZ_1M);
>>> +
>>> +             BUG_ON(!secure_ctrl_mod || !emif1 || !emif2);
>>
>> Please avoid BUG_ON() and use proper error recovery.  This is not a
>> condition where the entire kernel should panic.
>>
> Agree. WARN_ON() should suffice.

A WARN_ON() is ok (but noisy).  Better is a pr_warn() with some proper
error recovery.

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

Re: [PATCHv2 10/19] ARM: OMAP4: PM: Work-around for ROM code BUG of IVAHD/TESLA

[Kevin Hilman]

"Shilimkar, Santosh"  writes:

> On Thu, May 17, 2012 at 4:35 AM, Kevin Hilman  wrote:
>> Tero Kristo  writes:
>>
>>> From: Santosh Shilimkar 
>>>
>>> The ROM BUG is when MPU Domain OFF wake up sequence that can compromise
>>> IVA and Tesla execution.
>>>
>>> At wakeup from MPU OFF on HS device only (not GP device), when
>>> restoring the Secure RAM, the ROM Code reconfigures the clocks the
>>> same way it is done at Cold Reset.
>>
>> Ouch.
>>
>>> The IVAHD Clocks and Power Domain settings are:
>>>       IVAHD_CM2 IVAHD_CLKCTRL_MODULE_MODE = DISABLE
>>>       IVAHD_CM2 SL2_CLKCTRL_MODULE_MODE = DISABLE
>>>       IVAHD_CM2 SL2_CLKSTCTRL_CLKTRCTRL = HW_AUTO
>>>       IVAHD_PRM IVAHD_PWRSTCTRL_POWERSTATE = OFF
>>> The TESLA Clocks and Power Domain settings are:
>>>       TESLA_CM1 TESLA_CLKCTRL_MODULE_MODE = DISABLE
>>>       TESLA_CM1 TESLA_CLKSTCTRL_CLKTRCTRL = HW_AUTO
>>>       TESLA_PRM TESLA_PWRSTCTRL_POWERSTATE = OFF
>>>
>>> This patch fixes the low power OFF mode code so that the these
>>> registers are saved and restore across MPU OFF state.
>>>
>>> Also because of this limitation, MPU OFF alone is not targeted without
>>> device OFF to avoid IVAHD and TESLA execution impact
>>
>> I don't see where this restriction is implemented.
>>
> It's handled and the patch is in mainline for some time.
> We de-scoped MPU OFF from OMAP4430 devices in SW and
> hardware team de-scoped it in hardware from OMAP4460 onwards.
> Deepest state on MPUSS cluster is OSWR.

The question was about the changelog.

The changelog makes it sound like the restriction is part of the patch,
but it is not.  Please update the changlog to clarify that, ideally
adding a reference to the commit you mentioned.

Kevin

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

Re: [PATCHv2 06/19] ARM: OMAP4: PM: Add SAR backup support towards device OFF

[Kevin Hilman]

"Shilimkar, Santosh"  writes:

> On Thu, May 17, 2012 at 4:28 AM, Kevin Hilman  wrote:
>> Tero Kristo  writes:
>>
>>> From: Santosh Shilimkar 
>>>
>>> The SAR RAM is maintained during Device OFF mode.
>>
>> so why is this patch bothering to save and restore it?
>>
> SAR RAM is maintained(not powered down) but somebody needs to
> feel the contents which will be preserved :-)
>
>> -ECONFUSED
>>
>>> The register layout
>>> is fixed in SAR ROM. SAR is split into 4 banks with different
>>> privilege accesses based on device type
>>>
>>>  ---
>>>  Access mode          Bank    Address Range
>>>  ---
>>>  HS/GP : Public               1       0x4A32_6000 - 0x4A32_6FFF (4kB)
>>>  HS/GP : Public               2       0x4A32_7000 - 0x4A32_73FF (1kB)
>>>
>>>  HS/EMU : Secured
>>>  GP : Public          3       0x4A32_8000 - 0x4A32_87FF (2kB)
>>>
>>>  HS/GP :Secure
>>>  write once.          4       0x4A32_9000 - 0x4A32_93FF (1kB)
>>>  ---
>>>
>>> The save process is done entirely by software and restore is done by
>>> hardware using the auto-restore feature. The restore feature is enabled
>>> by default and cannot be disabled. The software must save the data
>>> to be restored in a dedicated location in SAR RAM.
>>
>> Some general comments:
>>
>> - can the cluster PM notifier be used for the save path?
>>
> Nope. This is for device OFF only case. CPU Cluster state as such
> has no dependency.

Yeah, I see now.  I like your idea of a device-off notifier chain
modeled on the CPU PM notifier chain.

>> - This patch adds lots of data that is immediately removed by the next
>>  patch.  Probably the two just need to be combined.
>>
> iormap() hunk from this patch can be completely dropped since
> it is getting fixed in next patch. Other infrastructure is maintained.

Look again at how much stuff is deleted in the next patch that is added
in this patch, and think about how a reviewer is supposed to follow that
easily.

>> - BUG_ON() should not be used unless there is absolutely no recovery
>>  path, since it casues a full kernel panic.   Instead, some error
>>  recovery should be added.
>>
> WARN_ON should suffice.

Not really.  Error recovery should be added.

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

Re: [PATCHv2 04/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode

[Kevin Hilman]

"Shilimkar, Santosh"  writes:

> On Thu, May 17, 2012 at 12:34 PM, Shilimkar, Santosh
>  wrote:
>> On Thu, May 17, 2012 at 4:12 AM, Kevin Hilman  wrote:
>>> Tero Kristo  writes:
>>>
 From: Rajendra Nayak 

 SAR/ROM code restores only CORE DPLL to its original state
 post wakeup from OFF mode.
 The rest of the DPLL's in OMAP4 platform (MPU/IVA/ABE/USB/PER)
 are saved and restored here during an OFF transition.

 [n...@ti.com: minor cleanups]
 Signed-off-by: Nishanth Menon 
 Signed-off-by: Rajendra Nayak 
 Signed-off-by: Santosh Shilimkar 
 Signed-off-by: Tero Kristo 
>>>
>>> Some general comments:
>>>
>>> - the register dump/print doesn't belong here.  If needed, should be a
>>>  debug feature if needed.
>>>
>>> - Rather than hooking into omap4_enter_lowpower(), should use
>>>  the cluster PM enter/exit notifier chain.
>>>
>> This is again specific to device OFF only and not related to CPU
>> cluster state as such. So I don't think notifiers should be used here.
>>
>> O.w even when we attempt just MPU OSWR C-state, all these functions will
>> get called in notifier chain.
>>
> Just a thought, we can have a separate notifier chain for device OFF. It can
> allow use to get rid of 'enable_off_mode" kind of flags and can be
> used by many drivers too.

Yes, I like this idea.

It allows a much cleaner collection of all the activities needed for
device off.

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

Re: [PATCH 0/9] ARM: OMAP: DMTIMER clean-up in preparation for device-tree

[Jon Hunter]

Hi Tarun,

On 05/17/2012 12:07 AM, DebBarma, Tarun Kanti wrote:
> On Thu, May 17, 2012 at 1:44 AM, Jon Hunter  wrote:
>> Hi Benoit,
>>
>> On 05/16/2012 04:28 AM, Cousson, Benoit wrote:
>>> Hi Jon,
>>>
>>> On 5/16/2012 1:35 AM, Jon Hunter wrote:
 From: Jon Hunter

 In order to migrate the dmtimer driver to support device-tree I found
 that it
 was first necessary to clean-up the timer platform data. The goal of this
 series is to simplify the timer platform data structure from ...

 struct dmtimer_platform_data {
 int (*set_timer_src)(struct platform_device *pdev, int source);
 int timer_ip_version;
 u32 needs_manual_reset:1;
 bool reserved;
 bool loses_context;
 int (*get_context_loss_count)(struct device *dev);
 };

 to ...

 struct dmtimer_platform_data {
 int (*set_timer_src)(struct platform_device *pdev, int source);
>>>
>>> I guess that custom set_timer_src should not be there at all anymore.
>>> Well at least for OMAP2+.
>>> We should just use the regular clock API to change the parent. I do not
>>> see why we should add that wrapper on top of the clock API and thus
>>> store some internal clock name inside the timer device init code.
> Whatever is done within omap2_dm_timer_set_src() in mach-omap2/timer.c
> can be implemented inside omap_dm_timer_set_source() in plat-omap/dmtimer.c
> directly whereby we continue to use the generic clock APIs provided in
> include/linux/clk.h.

Have you looked at the OMAP1 code for this?

Today it is not using the clock framework at all. So first we need to
change the OMAP1 code to use the clock framework for dmtimers and then
we can move the function.

>> I have been looking into this and in order to get rid for the above
>> function pointer we would need to move at a minimum the following
>> functions from omap-mach2/clkt_clksel.c into the platform code.
>>
>> _get_clksel_by_parent()
>> _get_div_and_fieldval()
>> _write_clksel_reg()
>> omap2_init_clksel_parent()
>> omap2_clksel_set_parent()
>>
>> However, it may be simpler just to move the clkt_clksel.c file
>> completely. I have tested the above functions on omap1 and they are
>> working well. However, before doing this we would need to get Paul's
>> buy-in that this is the right thing to do.
> I am not sure if this is really needed though.

It is needed so that OMAP1 can use the clksel functions and so we can
migrate OMAP1 and OMAP2+ to use a common function for changing the
parent clock.

Cheers
Jon
--
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/9] ARM: OMAP: DMTIMER clean-up in preparation for device-tree

[Jon Hunter]

Hi Paul,

On 05/16/2012 06:30 PM, Paul Walmsley wrote:
> Hello Jon,
> 
> On Wed, 16 May 2012, Jon Hunter wrote:
> 
>> I have been looking into this and in order to get rid for the above
>> function pointer we would need to move at a minimum the following
>> functions from omap-mach2/clkt_clksel.c into the platform code.
> 
> By platform code, do you mean arch/arm/plat-omap?

Yes, exactly.

>> _get_clksel_by_parent()
>> _get_div_and_fieldval()
>> _write_clksel_reg()
>> omap2_init_clksel_parent()
>> omap2_clksel_set_parent()
>>
>> However, it may be simpler just to move the clkt_clksel.c file
>> completely. I have tested the above functions on omap1 and they are
>> working well. However, before doing this we would need to get Paul's
>> buy-in that this is the right thing to do.
>>
>> Paul, do you have any thoughts on this? We were trying to see if we
>> could eliminate the dmtimer function pointer for setting the timer clock
>> source.
> 
> So, just to see if I'm understanding you correctly, you are planning to 
> implement clksel clocks in the clock framework for OMAP1, and then use 
> clk_set_parent() in the DMTIMER driver ?
> 
> If so, then yes, that sounds like the right thing to do.

Yes that's right. What is your preference here, the options are ...

1. Move the clkt_clksel.c file to arch/arm/plat-omap and change the
omap2_xxx API names to omap_xxx.
2. Add the functions in clkt_clksel.c to arch/arm/plat-omap/clock.c and
get rid of clkt_clksel.c altogether.

> Eventually both OMAP2+ and OMAP1 will presumably switch to the common 
> clock framework, once things settle down a bit and can be tested.
> 
>> Also, the only other minor issue I see is that for omap1 devices instead
>> of having "sys_ck" as the name the clock name is "armxor_ck". We cannot
>> rename armxor_ck as it is used by many peripherals but we could use a
>> #define to workaround this or add a dummy clock node.
> 
> OMAP1 clockfw uses clkdev just like OMAP2+, so you should be able to 
> define as many clock aliases as you want in mach-omap1/clock_data.c.

Yes, I saw that I have been adding the timer clocks to the OMAP1
clock_data.c. So it is working well, I just need a little guidance on
the appropriate way to move the clksel functions.

Thanks!
Jon
--
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: [RESEND/PATCHv2] Input: omap-keypad: dynamically handle register offsets

[Dmitry Torokhov]

Hi Sourav,

On Thu, May 17, 2012 at 07:01:49PM +0530, Poddar, Sourav wrote:
> Hi Dmitry,
> 
> Gentle Ping on this..

The patch has been committed to my 'next' branch for 3.5 on 05/11/12:

http://git.kernel.org/?p=linux/kernel/git/dtor/input.git;a=commit;h=f77621cc640a7c50b3d8c5254ecc5d91eaa99d0d

Thanks.

-- 
Dmitry
--
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 -next] mmc: omap_hsmmc: pass IRQF_ONESHOT to request_threaded_irq

[Chris Ball]

Hi,

On Thu, May 17 2012, S, Venkatraman wrote:
> On Thu, May 17, 2012 at 7:57 AM, Ming Lei  wrote:
>> The flag of IRQF_ONESHOT should be passed to request_threaded_irq,
>> otherwise the following failure message should be dumped because
>> hardware handler is defined as NULL:
>>
>> [    3.383483] genirq: Threaded irq requested with handler=NULL and
>> !ONESHOT for irq 368
>> [    3.392730] omap_hsmmc: probe of omap_hsmmc.0 failed with error -22
>>
>> The patch fixes one kernel hang bug which is caused by mmc card
>> probe failure and root device can't be brought up.
>>
>> Signed-off-by: Ming Lei 
>
> Right thing to do!
> Acked-by: Venkatraman S 

Thanks, pushed to mmc-next for 3.5 with a stable@ tag added.

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

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

[Russell King - ARM Linux]

On Thu, May 17, 2012 at 02:52:36PM +0100, Mark Brown wrote:
> On Thu, May 17, 2012 at 02:22:23PM +0100, Russell King - ARM Linux wrote:
> 
> > DMA on the other hand seems to have cases where you can make a choice
> > between two or more providers of the service.  The impression that I'm
> > getting from this thread is that it's difficult to describe that kind
> > of relationship in DT - DT is good at describing "A provides X to C"
> > but not "A _or_ B provides X to C and you can chose either A or B
> > depending on  to satisfy X".
> 
> A similar thing exists in a lot of clock trees - often the final clock
> block before an IP block includes a mux which could come from one of a
> number of sources.

At least there, the problem is easier, because we have in place a way
to represent muxes separately from everything else.

DMA engine is totally different; there is no representation of this, and
I don't see a sane way that it _could_ be represented given the existing
structure - certainly not without a major rework.

The first problem is that there is no support for any kind of layering in
dma engine at all.

The second problem is that you're actually dealing with muxes at two
levels - when you have an external mux to the DMA engine, you normally
already have a mux internally within the DMA engine.  And you need to
set these muxes dynamically according to the next DMA activity that the
physical DMA channel is about to process.

That becomes even more fun when you have setups like on the Realview
platforms where you have one set of bits which multiplex several
different DMA request signals, so changing the mux for one signal
changes others.  What this means is that you may only find out that
you can't route the DMA request when you try to change the muxes to
route your DMA request into the DMA controller.

It's all _very_ icky and horrible.  Clock muxes are much saner.

That said, I'm quite prepared to say "ok, we just don't bother dealing
with that DMA issue on platforms like Realview, hard luck if your
hardware team thought it was a good idea, we don't support 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 -next] mmc: omap_hsmmc: pass IRQF_ONESHOT to request_threaded_irq

[S, Venkatraman]

On Thu, May 17, 2012 at 7:57 AM, Ming Lei  wrote:
> The flag of IRQF_ONESHOT should be passed to request_threaded_irq,
> otherwise the following failure message should be dumped because
> hardware handler is defined as NULL:
>
> [    3.383483] genirq: Threaded irq requested with handler=NULL and
> !ONESHOT for irq 368
> [    3.392730] omap_hsmmc: probe of omap_hsmmc.0 failed with error -22
>
> The patch fixes one kernel hang bug which is caused by mmc card
> probe failure and root device can't be brought up.
>
> Signed-off-by: Ming Lei 
Right thing to do!
Acked-by: Venkatraman S 

> ---
>  drivers/mmc/host/omap_hsmmc.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index ebaf62a..9a7a60a 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1981,7 +1981,7 @@ static int __devinit omap_hsmmc_probe(struct 
> platform_device *pdev)
>                ret = request_threaded_irq(mmc_slot(host).card_detect_irq,
>                                           NULL,
>                                           omap_hsmmc_detect,
> -                                          IRQF_TRIGGER_RISING | 
> IRQF_TRIGGER_FALLING,
> +                                          IRQF_TRIGGER_RISING | 
> IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
>                                           mmc_hostname(mmc), host);
>                if (ret) {
>                        dev_dbg(mmc_dev(host->mmc),
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

[Mark Brown]

On Thu, May 17, 2012 at 02:22:23PM +0100, Russell King - ARM Linux wrote:

> DMA on the other hand seems to have cases where you can make a choice
> between two or more providers of the service.  The impression that I'm
> getting from this thread is that it's difficult to describe that kind
> of relationship in DT - DT is good at describing "A provides X to C"
> but not "A _or_ B provides X to C and you can chose either A or B
> depending on  to satisfy X".

A similar thing exists in a lot of clock trees - often the final clock
block before an IP block includes a mux which could come from one of a
number of sources.
--
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: [RESEND/PATCHv2] Input: omap-keypad: dynamically handle register offsets

[Poddar, Sourav]

Hi Dmitry,

Gentle Ping on this..

~Sourav
On Wed, May 9, 2012 at 3:37 PM, Poddar, Sourav  wrote:
> Hi Dmitry,
>
> On Wed, May 9, 2012 at 3:14 PM, Poddar, Sourav  wrote:
>> Hi Dmitry,
>>
>> I did some minor fixes to the patch which you suggested above and
>> the keypad is functional now.
>>
>> Changes:
>> - Move "pm_runtime_enable" before using "pm_runtime_get_sync".
>>
>> Sending the patch inlined..(also attached).
>>
>> From: G, Manjunath Kondaiah 
>> Date: Mon, 10 Oct 2011 20:52:05 +0530
>> Subject: [PATCH] Input: omap-keypad: dynamically handle register offsets
>>
>> Keypad controller register offsets are different for omap4
>> and omap5. Handle these offsets through static mapping and
>> assign these mappings during run time.
>>
>> Tested on omap4430 sdp with 3.4-rc3.
>> Tested on omap5430evm with 3.1-custom kernel.
>>
>> Cc: Andrew Morton 
>> Signed-off-by: Felipe Balbi 
>> Signed-off-by: G, Manjunath Kondaiah 
>> Signed-off-by: Sourav Poddar 
>> Signed-off-by: Dmitry Torokhov 
>> ---
>>  drivers/input/keyboard/Kconfig        |    4 +-
>>  drivers/input/keyboard/omap4-keypad.c |  120 
>> +---
>>  2 files changed, 95 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
>> index f354813..33bbdee 100644
>> --- a/drivers/input/keyboard/Kconfig
>> +++ b/drivers/input/keyboard/Kconfig
>> @@ -512,9 +512,9 @@ config KEYBOARD_OMAP
>>          module will be called omap-keypad.
>>
>>  config KEYBOARD_OMAP4
>> -       tristate "TI OMAP4 keypad support"
>> +       tristate "TI OMAP4+ keypad support"
>>        help
>> -         Say Y here if you want to use the OMAP4 keypad.
>> +         Say Y here if you want to use the OMAP4+ keypad.
>>
>>          To compile this driver as a module, choose M here: the
>>          module will be called omap4-keypad.
>> diff --git a/drivers/input/keyboard/omap4-keypad.c
>> b/drivers/input/keyboard/omap4-keypad.c
>> index e809ac0..d7102e8 100644
>> --- a/drivers/input/keyboard/omap4-keypad.c
>> +++ b/drivers/input/keyboard/omap4-keypad.c
>> @@ -68,19 +68,52 @@
>>
>>  #define OMAP4_MASK_IRQSTATUSDISABLE    0x
>>
>> +enum {
>> +       KBD_REVISION_OMAP4 = 0,
>> +       KBD_REVISION_OMAP5,
>> +};
>> +
>>  struct omap4_keypad {
>>        struct input_dev *input;
>>
>>        void __iomem *base;
>> -       int irq;
>> +       unsigned int irq;
>>
>>        unsigned int rows;
>>        unsigned int cols;
>> +       u32 reg_offset;
>> +       u32 irqreg_offset;
>>        unsigned int row_shift;
>>        unsigned char key_state[8];
>>        unsigned short keymap[];
>>  };
>>
>> +static int kbd_readl(struct omap4_keypad *keypad_data, u32 offset)
>> +{
>> +       return __raw_readl(keypad_data->base +
>> +                               keypad_data->reg_offset + offset);
>> +}
>> +
>> +static void kbd_writel(struct omap4_keypad *keypad_data, u32 offset, u32 
>> value)
>> +{
>> +       __raw_writel(value,
>> +                    keypad_data->base + keypad_data->reg_offset + offset);
>> +}
>> +
>> +static int kbd_read_irqreg(struct omap4_keypad *keypad_data, u32 offset)
>> +{
>> +       return __raw_readl(keypad_data->base +
>> +                               keypad_data->irqreg_offset + offset);
>> +}
>> +
>> +static void kbd_write_irqreg(struct omap4_keypad *keypad_data,
>> +                            u32 offset, u32 value)
>> +{
>> +       __raw_writel(value,
>> +                    keypad_data->base + keypad_data->irqreg_offset + 
>> offset);
>> +}
>> +
>> +
>>  /* Interrupt handler */
>>  static irqreturn_t omap4_keypad_interrupt(int irq, void *dev_id)
>>  {
>> @@ -91,12 +124,11 @@ static irqreturn_t omap4_keypad_interrupt(int
>> irq, void *dev_id)
>>        u32 *new_state = (u32 *) key_state;
>>
>>        /* Disable interrupts */
>> -       __raw_writel(OMAP4_VAL_IRQDISABLE,
>> -                    keypad_data->base + OMAP4_KBD_IRQENABLE);
>> +       kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQENABLE,
>> +                        OMAP4_VAL_IRQDISABLE);
>>
>> -       *new_state = __raw_readl(keypad_data->base + OMAP4_KBD_FULLCODE31_0);
>> -       *(new_state + 1) = __raw_readl(keypad_data->base
>> -                                               + OMAP4_KBD_FULLCODE63_32);
>> +       *new_state = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE31_0);
>> +       *(new_state + 1) = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE63_32);
>>
>>        for (row = 0; row < keypad_data->rows; row++) {
>>                changed = key_state[row] ^ keypad_data->key_state[row];
>> @@ -121,12 +153,13 @@ static irqreturn_t omap4_keypad_interrupt(int
>> irq, void *dev_id)
>>                sizeof(keypad_data->key_state));
>>
>>        /* clear pending interrupts */
>> -       __raw_writel(__raw_readl(keypad_data->base + OMAP4_KBD_IRQSTATUS),
>> -                       keypad_data->base + OMAP4_KBD_IRQSTATUS);
>> +       kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS,
>> +                        kbd_read_irqreg(keypad_dat

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

[Russell King - ARM Linux]

On Wed, May 16, 2012 at 07:42:20PM +, Arnd Bergmann wrote:
> On Wednesday 16 May 2012, Jassi Brar wrote:
> >  The assumed model of the DMAC, in this binding, has P peripheral
> > interfaces (P request signals) that could request a data transfer
> > and C physical channels that actually do the data transfers, hence,
> > at most C out of P peripherals could be served by the DMAC at any
> > point of time. Usually C := P, but not always. Usually, any of the
> > physical channels could be employed by the DMAC driver to serve any
> > client.
> >  The DMAC driver identifies a client by its i/f number, 'peri_id'
> > on the given DMAC. For example, TX for SPI has 7th while RX_TX
> > (half-duplex) for MMC has 10th peripheral interface (request-signal)
> > on a given DMAC. Usually, any of the physical channels could be
> > employed by the DMAC driver to serve a client.
> 
> I'm still anything but convinced by this model. Basically it's the
> exact opposite of what we do for every other subsystem (irq, pinctrl,
> regulator, gpio, ...), where the device using some infrastructure
> contains the information about who provides it, whereas here you
> move all the information into the device that provides the functionality,
> and have no handle in the device using it by which the driver can
> identify it.

I think the biggest difference between DMA and other subsystems is that
other systems have only one provider.

DMA on the other hand seems to have cases where you can make a choice
between two or more providers of the service.  The impression that I'm
getting from this thread is that it's difficult to describe that kind
of relationship in DT - DT is good at describing "A provides X to C"
but not "A _or_ B provides X to C and you can chose either A or B
depending on  to satisfy 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

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

[Russell King - ARM Linux]

On Thu, May 10, 2012 at 11:00:53AM -0600, Stephen Warren wrote:
> To solve Russell's HW, we need some way of representing the mux directly
> in DT irrespective of how the DMA controller or DMA client specify what
> they're connected to. Anything else isn't representing the HW in DT.

Note that it's now no longer _just_ my hardware.

The Spear family of SoCs have a very similar setup - they mux the DMA
request signals between the PL08x and their peripherals.  It looks like
each of the 16 DMA requests to the PL08x can be independently muxed
between four possibilities via a common register.

See arch/arm/plat-spear/pl080.c in current arm-soc.
--
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] arm/dts: OMAP4: Add Variscite OMAP4 System-On-Modeule support

[Uri Yosef]

Hi Tony,

This is the updated DTS patch for Vatiscite OMAP4 SOM support

Regatds,
Uri Yosef


Signed-off-by: Uri Yosef 

---
 arch/arm/boot/dts/omap4-var_som.dts |   96 +++
 1 files changed, 96 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap4-var_som.dts

diff --git a/arch/arm/boot/dts/omap4-var_som.dts 
b/arch/arm/boot/dts/omap4-var_som.dts
new file mode 100644
index 000..d41161d
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-var_som.dts
@@ -0,0 +1,96 @@
+/*
+ * Copyright (C) 2012 Variscite Ltd. - http://www.variscite.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.
+ */
+/dts-v1/;
+
+/include/ "omap4.dtsi"
+
+/ {
+   model = "Variscite OMAP4 SOM";
+   compatible = "var,omap4-var_som", "ti,omap4430", "ti,omap4";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x4000>; /* 1 GB */
+   };
+
+   vdd_eth: fixedregulator@0 {
+   compatible = "regulator-fixed";
+   regulator-name = "VDD_ETH";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   enable-active-high;
+   regulator-boot-on;
+   };
+};
+
+&i2c1 {
+   clock-frequency = <40>;
+
+   twl: twl@48 {
+   reg = <0x48>;
+   /* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
+   interrupts = <0 7 4>; /* IRQ_SYS_1N cascaded to gic */
+   interrupt-parent = <&gic>;
+   };
+};
+
+/include/ "twl6030.dtsi"
+
+&i2c2 {
+   clock-frequency = <40>;
+};
+
+&i2c3 {
+   clock-frequency = <40>;
+
+   /*
+* Temperature Sensor
+* http://www.ti.com/lit/ds/symlink/tmp105.pdf
+*/
+   tmp105@49 {
+   compatible = "ti,tmp105";
+   reg = <0x49>;
+   };
+};
+
+&i2c4 {
+   clock-frequency = <40>;
+};
+
+&mcspi1 {
+   eth@0 {
+   compatible = "ks8851";
+   spi-max-frequency = <2400>;
+   reg = <0>;
+   interrupt-parent = <&gpio6>;
+   interrupts = <11>; /* gpio line 171 */
+   vdd-supply = <&vdd_eth>;
+   };
+};
+
+&mmc1 {
+   vmmc-supply = <&vmmc>;
+   ti,bus-width = <8>;
+   ti,non-removable;
+};
+
+&mmc2 {
+   status = "disable";
+};
+
+&mmc3 {
+   status = "disable";
+};
+
+&mmc4 {
+   status = "disable";
+};
+
+&mmc5 {
+   ti,bus-width = <4>;
+};
-- 
1.7.5.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 0/3] mmc: omap: driver registration cleanups

[Chris Ball]

Hi,

On Thu, May 10 2012, T Krishnamoorthy, Balaji wrote:
> On Tue, May 8, 2012 at 5:05 PM, Venkatraman S  wrote:
>> Cleanups for the legacy omap mmc driver to remove clutter and
>> make it well behaved as module.
>>
>> Venkatraman S (3):
>>  mmc: omap: convert to per instance workqueue
>>  mmc: omap: make it behave well as module
>>  mmc: omap: convert to module_platform_driver
>
> Looks good to me, So
> Acked-by: Balaji T K 

Thanks, pushed to mmc-next for 3.5.

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
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/9] ARM: OMAP: DMTIMER clean-up in preparation for device-tree

[Cousson, Benoit]

On 5/16/2012 3:34 PM, Jon Hunter wrote:

Hi Benoit,

On 05/16/2012 04:28 AM, Cousson, Benoit wrote:

Hi Jon,

On 5/16/2012 1:35 AM, Jon Hunter wrote:

From: Jon Hunter

In order to migrate the dmtimer driver to support device-tree I found
that it
was first necessary to clean-up the timer platform data. The goal of this
series is to simplify the timer platform data structure from ...

struct dmtimer_platform_data {
 int (*set_timer_src)(struct platform_device *pdev, int source);
 int timer_ip_version;
 u32 needs_manual_reset:1;
 bool reserved;
 bool loses_context;
 int (*get_context_loss_count)(struct device *dev);
};

to ...

struct dmtimer_platform_data {
 int (*set_timer_src)(struct platform_device *pdev, int source);


I guess that custom set_timer_src should not be there at all anymore.
Well at least for OMAP2+.
We should just use the regular clock API to change the parent. I do not
see why we should add that wrapper on top of the clock API and thus
store some internal clock name inside the timer device init code.


Yes I really wanted to eliminate that function pointer too, but it was a
little trickier. The OMAP2+ code does use the clock framework to switch
the parent already, but the problem is that the OMAP1 code does not. So
we cannot have a common function for OMAP1 and OMAP2+.

One option would be to move the OMAP2+ function into the dmtimer because
it already uses the clock framework and then only populate the function
pointer for OMAP1. However, I admit this is ugly.

Let me look at this some more to see what I can do. I can at least test
on my old omap1 board now for prototyping :-)

Did you look at the rest of the series? Let me know if you are ok with
the approach and have any concerns on my hwmod changes/fix-ups ;-)


No, I'll keep that for next week, after my vacation :-)

Regards,
Benoit
--
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] ARM: omap: clock: Get rid of unwanted clkdm assocations within clks

[Rajendra Nayak]

clkdm assocations with clocks in the clock framework are useful
only for 'gate' clocks which have enable/disable ops populated.
Get rid of the clkdm_names populated in any other type of clocks.

Signed-off-by: Rajendra Nayak 
---
 arch/arm/mach-omap2/clock2420_data.c |   16 
 arch/arm/mach-omap2/clock2430_data.c |   15 ---
 arch/arm/mach-omap2/clock3xxx_data.c |   44 --
 3 files changed, 0 insertions(+), 75 deletions(-)

diff --git a/arch/arm/mach-omap2/clock2420_data.c 
b/arch/arm/mach-omap2/clock2420_data.c
index bace930..914d12a 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -56,14 +56,12 @@ static struct clk func_32k_ck = {
.name   = "func_32k_ck",
.ops= &clkops_null,
.rate   = 32768,
-   .clkdm_name = "wkup_clkdm",
 };
 
 static struct clk secure_32k_ck = {
.name   = "secure_32k_ck",
.ops= &clkops_null,
.rate   = 32768,
-   .clkdm_name = "wkup_clkdm",
 };
 
 /* Typical 12/13MHz in standalone mode, will be 26Mhz in chassis mode */
@@ -79,7 +77,6 @@ static struct clk sys_ck = {  /* (*12, *13, 19.2, 26, 
38.4)MHz */
.name   = "sys_ck", /* ~ ref_clk also */
.ops= &clkops_null,
.parent = &osc_ck,
-   .clkdm_name = "wkup_clkdm",
.recalc = &omap2xxx_sys_clk_recalc,
 };
 
@@ -87,7 +84,6 @@ static struct clk alt_ck = {  /* Typical 54M or 48M, 
may not exist */
.name   = "alt_ck",
.ops= &clkops_null,
.rate   = 5400,
-   .clkdm_name = "wkup_clkdm",
 };
 
 /* Optional external clock input for McBSP CLKS */
@@ -180,7 +176,6 @@ static struct clk func_54m_ck = {
.name   = "func_54m_ck",
.ops= &clkops_null,
.parent = &apll54_ck,   /* can also be alt_clk */
-   .clkdm_name = "wkup_clkdm",
.init   = &omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(PLL_MOD, CM_CLKSEL1),
.clksel_mask= OMAP24XX_54M_SOURCE_MASK,
@@ -192,7 +187,6 @@ static struct clk core_ck = {
.name   = "core_ck",
.ops= &clkops_null,
.parent = &dpll_ck, /* can also be 32k */
-   .clkdm_name = "wkup_clkdm",
.recalc = &followparent_recalc,
 };
 
@@ -200,7 +194,6 @@ static struct clk func_96m_ck = {
.name   = "func_96m_ck",
.ops= &clkops_null,
.parent = &apll96_ck,
-   .clkdm_name = "wkup_clkdm",
.recalc = &followparent_recalc,
 };
 
@@ -226,7 +219,6 @@ static struct clk func_48m_ck = {
.name   = "func_48m_ck",
.ops= &clkops_null,
.parent = &apll96_ck,/* 96M or Alt */
-   .clkdm_name = "wkup_clkdm",
.init   = &omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(PLL_MOD, CM_CLKSEL1),
.clksel_mask= OMAP24XX_48M_SOURCE_MASK,
@@ -241,7 +233,6 @@ static struct clk func_12m_ck = {
.ops= &clkops_null,
.parent = &func_48m_ck,
.fixed_div  = 4,
-   .clkdm_name = "wkup_clkdm",
.recalc = &omap_fixed_divisor_recalc,
 };
 
@@ -323,7 +314,6 @@ static struct clk sys_clkout = {
.name   = "sys_clkout",
.ops= &clkops_null,
.parent = &sys_clkout_src,
-   .clkdm_name = "wkup_clkdm",
.clksel_reg = OMAP2420_PRCM_CLKOUT_CTRL,
.clksel_mask= OMAP24XX_CLKOUT_DIV_MASK,
.clksel = sys_clkout_clksel,
@@ -359,7 +349,6 @@ static struct clk sys_clkout2 = {
.name   = "sys_clkout2",
.ops= &clkops_null,
.parent = &sys_clkout2_src,
-   .clkdm_name = "wkup_clkdm",
.clksel_reg = OMAP2420_PRCM_CLKOUT_CTRL,
.clksel_mask= OMAP2420_CLKOUT2_DIV_MASK,
.clksel = sys_clkout2_clksel,
@@ -407,7 +396,6 @@ static struct clk mpu_ck = {/* Control cpu */
.name   = "mpu_ck",
.ops= &clkops_null,
.parent = &core_ck,
-   .clkdm_name = "mpu_clkdm",
.init   = &omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(MPU_MOD, CM_CLKSEL),
.clksel_mask= OMAP24XX_CLKSEL_MPU_MASK,
@@ -541,7 +529,6 @@ static struct clk core_l3_ck = {/* Used for ick and 
fck, interconnect */
.name   = "core_l3_ck",
.ops= &clkops_null,
.parent = &core_ck,
-   .clkdm_name = "core_l3_clkdm",
.clksel_reg = OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL1),
.clksel_mask= OMAP24XX_CLKSEL_L3_MASK,
.clksel = core_l3_clksel,
@@ -597,7

Re: [PATCH 2/6] ARM: OMAP2+: PM: introduce power domains functional states

[Santosh Shilimkar]

Jean,
On Tuesday 08 May 2012 02:10 PM, Jean Pihet wrote:
> Paul,
> 
> On Mon, May 7, 2012 at 11:28 AM, Paul Walmsley  wrote:
>> Hi
>>
>> On Wed, 18 Apr 2012, jean.pi...@newoldbits.com wrote:
>>
>>> From: Jean Pihet 
>>>
>>> Introduce functional (or logical) states for power domains and the
>>> API functions to read the power domains settings and to convert
>>> between the functional (i.e. logical) and the internal (or registers)
>>> values.
>>>
>>> OMAP2, OMAP3 and OMAP4 platforms are defining a conversion routine.
>>>
>>> In the new API the function omap_set_pwrdm_state takes the functional
>>> states as parameter; while at it the function is moved to the power
>>> domains code.
>>>
>>> The memory and logic states are not using the functional states, this
>>> comes as a subsequent patch.
>>>
>>> Signed-off-by: Jean Pihet 
>>
>> This patch results in several checkpatch warnings; please resolve them.
> Oops. Will check and update.
> 
>>
>>> ---
>>>  arch/arm/mach-omap2/pm.c   |   66 ---
>>>  arch/arm/mach-omap2/powerdomain-common.c   |   61 ++
>>>  arch/arm/mach-omap2/powerdomain.c  |  175 
>>> 
>>>  arch/arm/mach-omap2/powerdomain.h  |   21 
>>>  arch/arm/mach-omap2/powerdomain2xxx_3xxx.c |5 +
>>>  arch/arm/mach-omap2/powerdomain44xx.c  |2 +
>>>  6 files changed, 264 insertions(+), 66 deletions(-)
>>>
> ...
> 
>>> +/*
>>> + * Functional (i.e. logical) to internal (i.e. registers)
>>> + * values for the power domains states
>>> + */
>>
>> Please use kerneldoc-style function comments.
> Ok
> 
>>
>>> +int omap2_pwrdm_func_to_pwrst(struct powerdomain *pwrdm, u8 func_pwrst)
>>> +{
>>> + int ret;
>>> +
>>> + switch (func_pwrst) {
>>> + case PWRDM_FUNC_PWRST_ON:
>>> + ret = PWRDM_POWER_ON;
>>> + break;
>>> + case PWRDM_FUNC_PWRST_INACTIVE:
>>> + ret = PWRDM_POWER_INACTIVE;
>>> + break;
>>> + case PWRDM_FUNC_PWRST_CSWR:
>>> + case PWRDM_FUNC_PWRST_OSWR:
>>> + ret = PWRDM_POWER_RET;
>>> + break;
>>> + case PWRDM_FUNC_PWRST_OFF:
>>> + ret = PWRDM_POWER_OFF;
>>> + break;
>>> + default:
>>> + ret = -1;
>>> + }
>>> +
>>> + return ret;
>>> +}
>>
>> At a quick glance, I don't think that this function is appropriate for all
>> OMAP2+ chips.  For example, off-mode is not supported in our OMAP2xxx
>> kernels.  And OMAP2xxx/3xxx do not support the INACTIVE powerstate.  So
>> probably this function should differ by chip, and be located in the
>> powerdomain[2-4]*xx*.c files.
> I hope to make this function as generic as possible, hence the
> location (powerdomain-common.c). Some states are not programmed by the
> pwrdm_* functions since there forbidden by the contents of the
> pwrdm->pwrst field.
> Now if the need arises some platform specific function can be defined
> for conversion functions since the pwrdm->ops function pointers are
> used. I do not think it is needed now but it can easily be changed.
> 
>> Also, what about the logic and memory bank power states?  Shouldn't this
>> function pass those back as well?
> Cf. in the description "The memory and logic states are not using the
> functional states, this comes as a subsequent patch."
> 
I don't see much difference between the functional power states to
actual power states with some cases here and there.

+ case PWRDM_FUNC_PWRST_CSWR:
+ case PWRDM_FUNC_PWRST_OSWR:
+ ret = PWRDM_POWER_RET;

This is not true and even if you add logic/memmort etc support,
I still think, we are just duplicating stuff between functional
vs actual power state.

If the idea is to have one single interface to program the power
domain states, so that Generic frameworks, or PM code movement to
driver/* directories is easier, we may want think about alternative
which is scalable.

Just a wild thought...

May be we can abstract all the necessary/used power domain programming
entities inside a structure and export that. That should contain, power
state, logic state, mem state, special quirk flags like SAR etc.
being structure is always expandable and an API taking structure as
a parameter need not change.

Regards
Santosh

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

Re: [PATCHv2 04/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode

[Shilimkar, Santosh]

On Thu, May 17, 2012 at 12:34 PM, Shilimkar, Santosh
 wrote:
> On Thu, May 17, 2012 at 4:12 AM, Kevin Hilman  wrote:
>> Tero Kristo  writes:
>>
>>> From: Rajendra Nayak 
>>>
>>> SAR/ROM code restores only CORE DPLL to its original state
>>> post wakeup from OFF mode.
>>> The rest of the DPLL's in OMAP4 platform (MPU/IVA/ABE/USB/PER)
>>> are saved and restored here during an OFF transition.
>>>
>>> [n...@ti.com: minor cleanups]
>>> Signed-off-by: Nishanth Menon 
>>> Signed-off-by: Rajendra Nayak 
>>> Signed-off-by: Santosh Shilimkar 
>>> Signed-off-by: Tero Kristo 
>>
>> Some general comments:
>>
>> - the register dump/print doesn't belong here.  If needed, should be a
>>  debug feature if needed.
>>
>> - Rather than hooking into omap4_enter_lowpower(), should use
>>  the cluster PM enter/exit notifier chain.
>>
> This is again specific to device OFF only and not related to CPU
> cluster state as such. So I don't think notifiers should be used here.
>
> O.w even when we attempt just MPU OSWR C-state, all these functions will
> get called in notifier chain.
>
Just a thought, we can have a separate notifier chain for device OFF. It can
allow use to get rid of 'enable_off_mode" kind of flags and can be
used by many drivers too.

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

[PATCH 1/2] staging: drm/omap: dmabuf/prime mmap support

[Rob Clark]

From: Rob Clark 

Add support for mmap'ing buffers via dmabuf.  For handling mmap of
cached buffers correctly, fault handling and PTE shootdown are used
to track dirty pages and automagically handle cache flushes before
dma access to the buffer.

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_drv.h|5 ++
 drivers/staging/omapdrm/omap_fb.c |5 +-
 drivers/staging/omapdrm/omap_gem.c|  104 ++---
 drivers/staging/omapdrm/omap_gem_dmabuf.c |   48 +
 4 files changed, 151 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_drv.h 
b/drivers/staging/omapdrm/omap_drv.h
index 3586173..73a606e 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -138,6 +138,8 @@ int omap_gem_dumb_destroy(struct drm_file *file, struct 
drm_device *dev,
 int omap_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args);
 int omap_gem_mmap(struct file *filp, struct vm_area_struct *vma);
+int omap_gem_mmap_obj(struct drm_gem_object *obj,
+   struct vm_area_struct *vma);
 int omap_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);
 int omap_gem_op_start(struct drm_gem_object *obj, enum omap_gem_op op);
 int omap_gem_op_finish(struct drm_gem_object *obj, enum omap_gem_op op);
@@ -145,6 +147,9 @@ int omap_gem_op_sync(struct drm_gem_object *obj, enum 
omap_gem_op op);
 int omap_gem_op_async(struct drm_gem_object *obj, enum omap_gem_op op,
void (*fxn)(void *arg), void *arg);
 int omap_gem_roll(struct drm_gem_object *obj, uint32_t roll);
+void omap_gem_cpu_sync(struct drm_gem_object *obj, int pgoff);
+void omap_gem_dma_sync(struct drm_gem_object *obj,
+   enum dma_data_direction dir);
 int omap_gem_get_paddr(struct drm_gem_object *obj,
dma_addr_t *paddr, bool remap);
 int omap_gem_put_paddr(struct drm_gem_object *obj);
diff --git a/drivers/staging/omapdrm/omap_fb.c 
b/drivers/staging/omapdrm/omap_fb.c
index 04b235b..3478757 100644
--- a/drivers/staging/omapdrm/omap_fb.c
+++ b/drivers/staging/omapdrm/omap_fb.c
@@ -197,8 +197,11 @@ int omap_framebuffer_replace(struct drm_framebuffer *a,
pa->paddr = 0;
}
 
-   if (pb && !ret)
+   if (pb && !ret) {
ret = omap_gem_get_paddr(pb->bo, &pb->paddr, true);
+   if (!ret)
+   omap_gem_dma_sync(pb->bo, DMA_TO_DEVICE);
+   }
}
 
if (ret) {
diff --git a/drivers/staging/omapdrm/omap_gem.c 
b/drivers/staging/omapdrm/omap_gem.c
index c5ba334..3a0d035 100644
--- a/drivers/staging/omapdrm/omap_gem.c
+++ b/drivers/staging/omapdrm/omap_gem.c
@@ -207,13 +207,27 @@ static inline bool is_shmem(struct drm_gem_object *obj)
return obj->filp != NULL;
 }
 
+/**
+ * shmem buffers that are mapped cached can simulate coherency via using
+ * page faulting to keep track of dirty pages
+ */
+static inline bool is_cached_coherent(struct drm_gem_object *obj)
+{
+   struct omap_gem_object *omap_obj = to_omap_bo(obj);
+   return is_shmem(obj) &&
+   ((omap_obj->flags & OMAP_BO_CACHE_MASK) == OMAP_BO_CACHED);
+}
+
 static DEFINE_SPINLOCK(sync_lock);
 
 /** ensure backing pages are allocated */
 static int omap_gem_attach_pages(struct drm_gem_object *obj)
 {
+   struct drm_device *dev = obj->dev;
struct omap_gem_object *omap_obj = to_omap_bo(obj);
struct page **pages;
+   int i, npages = obj->size >> PAGE_SHIFT;
+   dma_addr_t *addrs;
 
WARN_ON(omap_obj->pages);
 
@@ -231,16 +245,18 @@ static int omap_gem_attach_pages(struct drm_gem_object 
*obj)
 * DSS, GPU, etc. are not cache coherent:
 */
if (omap_obj->flags & (OMAP_BO_WC|OMAP_BO_UNCACHED)) {
-   int i, npages = obj->size >> PAGE_SHIFT;
-   dma_addr_t *addrs = kmalloc(npages * sizeof(addrs), GFP_KERNEL);
+   addrs = kmalloc(npages * sizeof(addrs), GFP_KERNEL);
for (i = 0; i < npages; i++) {
-   addrs[i] = dma_map_page(obj->dev->dev, pages[i],
+   addrs[i] = dma_map_page(dev->dev, pages[i],
0, PAGE_SIZE, DMA_BIDIRECTIONAL);
}
-   omap_obj->addrs = addrs;
+   } else {
+   addrs = kzalloc(npages * sizeof(addrs), GFP_KERNEL);
}
 
+   omap_obj->addrs = addrs;
omap_obj->pages = pages;
+
return 0;
 }
 
@@ -258,10 +274,11 @@ static void omap_gem_detach_pages(struct drm_gem_object 
*obj)
dma_unmap_page(obj->dev->dev, omap_obj->addrs[i],
PAGE_SIZE, DMA_BIDIRECTIONAL);
}
-   kfree(omap_obj->addrs);
-   omap_obj->addrs = NULL;
}
 
+   kfree(omap_obj->addrs);
+   omap_obj->

[PATCH 2/2] staging: drm/omap: initial dmabuf/prime import support

[Rob Clark]

From: Rob Clark 

This adds support to re-import omapdrm's own buffers.  Importing buffers
allocated by other drivers can be added later, but for now is not needed
(we don't yet have any other exportering drivers to test with).

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_drv.c|2 ++
 drivers/staging/omapdrm/omap_drv.h|2 ++
 drivers/staging/omapdrm/omap_gem_dmabuf.c |   22 ++
 3 files changed, 26 insertions(+)

diff --git a/drivers/staging/omapdrm/omap_drv.c 
b/drivers/staging/omapdrm/omap_drv.c
index 1f559f4..0d2acca 100644
--- a/drivers/staging/omapdrm/omap_drv.c
+++ b/drivers/staging/omapdrm/omap_drv.c
@@ -767,7 +767,9 @@ static struct drm_driver omap_drm_driver = {
.debugfs_cleanup = omap_debugfs_cleanup,
 #endif
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_export = omap_gem_prime_export,
+   .gem_prime_import = omap_gem_prime_import,
.gem_init_object = omap_gem_init_object,
.gem_free_object = omap_gem_free_object,
.gem_vm_ops = &omap_gem_vm_ops,
diff --git a/drivers/staging/omapdrm/omap_drv.h 
b/drivers/staging/omapdrm/omap_drv.h
index 73a606e..f238d57 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -162,6 +162,8 @@ size_t omap_gem_mmap_size(struct drm_gem_object *obj);
 
 struct dma_buf * omap_gem_prime_export(struct drm_device *dev,
struct drm_gem_object *obj, int flags);
+struct drm_gem_object * omap_gem_prime_import(struct drm_device *dev,
+   struct dma_buf *buffer);
 
 static inline int align_pitch(int pitch, int width, int bpp)
 {
diff --git a/drivers/staging/omapdrm/omap_gem_dmabuf.c 
b/drivers/staging/omapdrm/omap_gem_dmabuf.c
index aba4b34..42728e0 100644
--- a/drivers/staging/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/staging/omapdrm/omap_gem_dmabuf.c
@@ -196,3 +196,25 @@ struct dma_buf * omap_gem_prime_export(struct drm_device 
*dev,
 {
return dma_buf_export(obj, &omap_dmabuf_ops, obj->size, 0600);
 }
+
+struct drm_gem_object * omap_gem_prime_import(struct drm_device *dev,
+   struct dma_buf *buffer)
+{
+   struct drm_gem_object *obj;
+
+   /* is this one of own objects? */
+   if (buffer->ops == &omap_dmabuf_ops) {
+   obj = buffer->priv;
+   /* is it from our device? */
+   if (obj->dev == dev) {
+   drm_gem_object_reference(obj);
+   return obj;
+   }
+   }
+
+   /*
+* TODO add support for importing buffers from other devices..
+* for now we don't need this but would be nice to add eventually
+*/
+   return ERR_PTR(-EINVAL);
+}
-- 
1.7.9.5

--
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/2] staging: drm/omap: more dmabuf/prime support

[Rob Clark]

From: Rob Clark 

Now that dmabuf mmap support is in dmabuf-next, here is support for it
in omapdrm.  Also some basic support to import dmabuf's.  For now it
can only re-import dmabuf's that it exported itself, mainly because I
don't yet need anything else and also because at the moment I don't
have a way to test it (need another exporter).

Rob Clark (2):
  staging: drm/omap: dmabuf/prime mmap support
  staging: drm/omap: initial dmabuf/prime import support

 drivers/staging/omapdrm/omap_drv.c|2 +
 drivers/staging/omapdrm/omap_drv.h|7 ++
 drivers/staging/omapdrm/omap_fb.c |5 +-
 drivers/staging/omapdrm/omap_gem.c|  104 ++---
 drivers/staging/omapdrm/omap_gem_dmabuf.c |   70 +++
 5 files changed, 177 insertions(+), 11 deletions(-)

-- 
1.7.9.5

--
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: [PATCHv2 15/19] ARM: OMAP4430: PM: workaround for DDR corruption on second CS

[Shilimkar, Santosh]

On Thu, May 17, 2012 at 5:45 AM, Kevin Hilman  wrote:
> Tero Kristo  writes:
>
>> From: Santosh Shilimkar 
>>
>> Work around for Errata ID: i632 "LPDDR2 Corruption After OFF Mode
>> Transition When CS1 Is Used On EMIF" which impacts OMAP443x silicon
>> The issue occurs when EMIF_SDRAM_CONFIG is restored first before
>> EMIF_SDRAM_CONFIG_2 is not yet restored, the register configuration
>> is not set properly, we apply the required workaround allowing
>> the restore sequence to work properly.
>
> Please summarize the workaround here as well.
>
ok
>> Signed-off-by: Santosh Shilimkar 
>> [t-kri...@ti.com: moved workaround from omap-sar.c to pm44xx.c]
>> Signed-off-by: Tero Kristo 
>> ---
>>  .../include/mach/ctrl_module_wkup_44xx.h           |    2 +
>>  arch/arm/mach-omap2/pm44xx.c                       |   37 
>> 
>>  2 files changed, 39 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h 
>> b/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
>> index a0af9ba..b763a79 100644
>> --- a/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
>> +++ b/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
>> @@ -28,6 +28,8 @@
>>  #define OMAP4_CTRL_MODULE_WKUP_IP_REVISION           0x
>>  #define OMAP4_CTRL_MODULE_WKUP_IP_HWINFO             0x0004
>>  #define OMAP4_CTRL_MODULE_WKUP_IP_SYSCONFIG          0x0010
>> +#define OMAP4_CTRL_SECURE_EMIF1_SDRAM_CONFIG2_REG    0x0114
>> +#define OMAP4_CTRL_SECURE_EMIF2_SDRAM_CONFIG2_REG    0x011c
>>  #define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_0  0x0460
>>  #define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_1  0x0464
>>  #define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_2  0x0468
>> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
>> index 215b80e..dfaa254 100644
>> --- a/arch/arm/mach-omap2/pm44xx.c
>> +++ b/arch/arm/mach-omap2/pm44xx.c
>> @@ -17,12 +17,18 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +
>> +#include 
>> +#include 
>>
>>  #include "common.h"
>>  #include "clockdomain.h"
>>  #include "powerdomain.h"
>>  #include "pm.h"
>>
>> +#define EMIF_SDRAM_CONFIG2_OFFSET    0xc
>> +
>>  struct power_state {
>>       struct powerdomain *pwrdm;
>>       u32 next_state;
>> @@ -215,6 +221,37 @@ static int __init omap4_pm_init(void)
>>
>>       pr_err("Power Management for TI OMAP4.\n");
>>
>> +     /*
>> +      * Work around for OMAP443x Errata i632: "LPDDR2 Corruption After OFF
>> +      * Mode Transition When CS1 Is Used On EMIF":
>> +      * Overwrite EMIF1/EMIF2
>> +      * SECURE_EMIF1_SDRAM_CONFIG2_REG
>> +      * SECURE_EMIF2_SDRAM_CONFIG2_REG
>> +      */
>> +     if (cpu_is_omap443x()) {
>
> This should probably be done later in this function, after PM_ERRATUM
> flags are setup, and then it should use a PM_ERRATUM flag instead of cpu_is*
>
ok

>> +             void __iomem *secure_ctrl_mod;
>> +             void __iomem *emif1;
>> +             void __iomem *emif2;
>> +             u32 val;
>> +
>> +             secure_ctrl_mod = ioremap(OMAP4_CTRL_MODULE_WKUP, SZ_4K);
>> +             emif1 = ioremap(OMAP44XX_EMIF1_BASE, SZ_1M);
>> +             emif2 = ioremap(OMAP44XX_EMIF2_BASE, SZ_1M);
>> +
>> +             BUG_ON(!secure_ctrl_mod || !emif1 || !emif2);
>
> Please avoid BUG_ON() and use proper error recovery.  This is not a
> condition where the entire kernel should panic.
>
Agree. WARN_ON() should suffice.

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

Re: [PATCHv2 03/19] ARM: OMAP4: PM: Add device-off support

[Shilimkar, Santosh]

On Thu, May 17, 2012 at 4:06 AM, Kevin Hilman  wrote:
> +Jean for functional power states
>
> Tero Kristo  writes:
>
>> This patch adds device off support to OMAP4 device type.
>
> Description is rather thin for a patch that is doing so much.
>
>> OFF mode is disabled by default,
>
> why?
>
>> however, there are two ways to enable OFF mode:
>> a) In the board file, call omap4_pm_off_mode_enable(1)
>> b) Enable OFF mode using the debugfs entry
>> echo "1">/sys/kernel/debug/pm_debug/enable_off_mode
>> (conversely echo '0' will disable it as well).
>
> This part needs to be a separate patch.
>
> But, as stated in the core retention series, I'd like to move away from
> these global flags all together.
>
> The way we manage the disabling of certain states (like off) is already
> clumsy for OMAP3, and it's getting worse with OMAP4.  Basically, I think
> this feature needs to be supported by using constraints on functional
> power states.   Having checks all over the place is getting unwieldy and
> not attractive to maintain.
>
> The combination of constraints and functional power states should make
> this much more manageable.   Until we have that, I'd prefer to keep
> the debugfs enable/disable stuff as separate patches at the end of the
> series used only for testing.
>
>> Signed-off-by: Santosh Shilimkar 
>> [t-kri...@ti.com: largely re-structured the code]
>
> then the sign-off above from Santosh probably doesn't apply anymore.
> You should change that to a Cc and just mention tht this is based upon
> some original work from Santosh.
>
> First,  some general comments:
>
> There is a lot going on in this patch, so it is hard to follow what all
> is related, and why.  Just a quick glance suggests it needs to be broken
> up into at least a few parts:
>
> - low-level PRM support: new APIs for various off-mode features)
>  (should probably be done on top of functional power states)
> - powerdomain core support or "achievable" states
>  (should probably be done on top of functional power states)
> - IRQ/GIC context save/restore
> - secure RAM save/restore (this has been tightly coupled to the GIC
>  but it's not obvious why)
> - PM debug support to enable/disable off-mode
>  (for testing only, not for merge)
>
Further split sounds good to me.

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

Re: [PATCHv2 05/19] ARM: OMAP4: PM: save/restore all CM1/2 settings in OFF mode

[Shilimkar, Santosh]

On Thu, May 17, 2012 at 4:18 AM, Kevin Hilman  wrote:
> Tero Kristo  writes:
>
>> From: Rajendra Nayak 
>>
>> Restore all CM1/2 module registers as they are lost in OFF mode.
>
> Save and restore?
>
> Also, as in the previous patch.  Can this be done using cluster PM
> notifier as well?    (I realize that this series was probably done
> before the PM notifiers were upstream, but now that we have them, we
> should use them.)
>
Device OFF specific and not related to CPU cluster state as such.

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

Re: [PATCHv2 04/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode

[Shilimkar, Santosh]

On Thu, May 17, 2012 at 4:12 AM, Kevin Hilman  wrote:
> Tero Kristo  writes:
>
>> From: Rajendra Nayak 
>>
>> SAR/ROM code restores only CORE DPLL to its original state
>> post wakeup from OFF mode.
>> The rest of the DPLL's in OMAP4 platform (MPU/IVA/ABE/USB/PER)
>> are saved and restored here during an OFF transition.
>>
>> [n...@ti.com: minor cleanups]
>> Signed-off-by: Nishanth Menon 
>> Signed-off-by: Rajendra Nayak 
>> Signed-off-by: Santosh Shilimkar 
>> Signed-off-by: Tero Kristo 
>
> Some general comments:
>
> - the register dump/print doesn't belong here.  If needed, should be a
>  debug feature if needed.
>
> - Rather than hooking into omap4_enter_lowpower(), should use
>  the cluster PM enter/exit notifier chain.
>
This is again specific to device OFF only and not related to CPU
cluster state as such. So I don't think notifiers should be used here.

O.w even when we attempt just MPU OSWR C-state, all these functions will
get called in notifier chain.

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

Re: [PATCHv2 06/19] ARM: OMAP4: PM: Add SAR backup support towards device OFF

[Shilimkar, Santosh]

On Thu, May 17, 2012 at 4:28 AM, Kevin Hilman  wrote:
> Tero Kristo  writes:
>
>> From: Santosh Shilimkar 
>>
>> The SAR RAM is maintained during Device OFF mode.
>
> so why is this patch bothering to save and restore it?
>
SAR RAM is maintained(not powered down) but somebody needs to
feel the contents which will be preserved :-)

> -ECONFUSED
>
>> The register layout
>> is fixed in SAR ROM. SAR is split into 4 banks with different
>> privilege accesses based on device type
>>
>>  ---
>>  Access mode          Bank    Address Range
>>  ---
>>  HS/GP : Public               1       0x4A32_6000 - 0x4A32_6FFF (4kB)
>>  HS/GP : Public               2       0x4A32_7000 - 0x4A32_73FF (1kB)
>>
>>  HS/EMU : Secured
>>  GP : Public          3       0x4A32_8000 - 0x4A32_87FF (2kB)
>>
>>  HS/GP :Secure
>>  write once.          4       0x4A32_9000 - 0x4A32_93FF (1kB)
>>  ---
>>
>> The save process is done entirely by software and restore is done by
>> hardware using the auto-restore feature. The restore feature is enabled
>> by default and cannot be disabled. The software must save the data
>> to be restored in a dedicated location in SAR RAM.
>
> Some general comments:
>
> - can the cluster PM notifier be used for the save path?
>
Nope. This is for device OFF only case. CPU Cluster state as such
has no dependency.

> - This patch adds lots of data that is immediately removed by the next
>  patch.  Probably the two just need to be combined.
>
iormap() hunk from this patch can be completely dropped since
it is getting fixed in next patch. Other infrastructure is maintained.

> - BUG_ON() should not be used unless there is absolutely no recovery
>  path, since it casues a full kernel panic.   Instead, some error
>  recovery should be added.
>
WARN_ON should suffice.
--
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