Re: [PATCHv5 3/8] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control register change
On Thu, May 17, 2012 at 10:45 PM, Kevin Hilman khil...@ti.com wrote: Shilimkar, Santosh santosh.shilim...@ti.com writes: On Wed, May 16, 2012 at 10:21 PM, Kevin Hilman khil...@ti.com wrote: Santosh Shilimkar santosh.shilim...@ti.com 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 t-kri...@ti.com writes: From: Santosh Shilimkar santosh.shilim...@ti.com 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 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: [PATCH 8/8] gpio/omap: fix missing check in *_runtime_suspend()
On Fri, May 18, 2012 at 5:26 AM, Kevin Hilman khil...@ti.com wrote: Tony Lindgren t...@atomide.com writes: * Kevin Hilman khil...@ti.com [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 khil...@ti.com 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 t...@atomide.com Cc: Tarun Kanti DebBarma tarun.ka...@ti.com Signed-off-by: Kevin Hilman khil...@ti.com --- Thanks for the Fix Kevin. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/11] ASoC: OMAP: HDMI: Change error values in HDMI CPU DAI
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 ricardo.n...@ti.com
---
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
[PATCH 01/11] ASoC: OMAP: HDMI: Introduce codec
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 ricardo.n...@ti.com
---
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 ricardo.n...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+#include linux/module.h
+#include sound/soc.h
+
+#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 ricardo.n...@ti.com);
+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
@@
[PATCH 04/11] ASoC: OMAP: HDMI: Create a structure for private data of the CPU DAI
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 ricardo.n...@ti.com
---
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 02/11] ASoC: OMAP: HDMI: Update the platform device names
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 ricardo.n...@ti.com
---
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 asm/mach-types.h
#include video/omapdss.h
-#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 06/11] ASoC: OMAP: HDMI: Expand configuration of hw_params
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 ricardo.n...@ti.com
---
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 sound/pcm_params.h
#include sound/initval.h
#include sound/soc.h
+#include sound/asound.h
+#include sound/asoundef.h
#include video/omapdss.h
#include plat/dma.h
@@ -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)
+
[PATCH 10/11] ASoC: OMAP: HDMI: Make sound card naming more generic
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 ricardo.n...@ti.com
---
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 ricardo.n...@ti.com
*
@@ -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 ricardo.n...@ti.com);
-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 07/11] ASoC: OMAP: HDMI: Improve how the display state is verified
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 ricardo.n...@ti.com
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 08/11] ASoC: OMAP: HDMI: Expand capabilities of the HDMI DAI
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 ricardo.n...@ti.com
---
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 05/11] ASoC: OMAP: HDMI: Use the DSS audio interface
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 ricardo.n...@ti.com
---
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 sound/pcm_params.h
#include sound/initval.h
#include sound/soc.h
+#include video/omapdss.h
#include plat/dma.h
#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
[PATCH 11/11] ASoC: OMAP: HDMI: Rename sound card source file
Rename sound card driver source file to encompass not only OMAP4 but future
OMAP versions that feature HDMI.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
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 ricardo.n...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/module.h
+#include sound/pcm.h
+#include sound/soc.h
+#include asm/mach-types.h
+#include video/omapdss.h
+
+#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 ricardo.n...@ti.com);
+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 ricardo.n...@ti.com
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
[PATCH 09/11] ASoC: OMAP: HDMI: Make build config options more generic
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 ricardo.n...@ti.com --- 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 00/11] ASoC: OMAP: HDMI: Use DSS audio interface and prepare for OMAP5
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
Re: [PATCH] ARM: OMAP2+: fix gpmc request_irq
+ Afzal who has been doing quite a bit of GMPC work recently. On Fri, May 18, 2012 at 10:13 AM, Ming Lei ming@canonical.com wrote: 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. GPMC IRQ line can shared between the multiple devices you connect on it. This patch just removes the flag of IRQF_SHARED to make the irq registration successful. Cc: Kevin Hilman khil...@ti.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Ming Lei ming@canonical.com --- arch/arm/mach-omap2/gpmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Are you sure it fails ? I just tried booting OMAP4 with 3.4-rc4 and don't see the irq failure error message. What I am missing ? 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: [PATCH] ARM: OMAP2+: fix gpmc request_irq
Hi Santosh, On Fri, May 18, 2012 at 12:33:16, Shilimkar, Santosh wrote: + Afzal who has been doing quite a bit of GMPC work recently. On Fri, May 18, 2012 at 10:13 AM, Ming Lei ming@canonical.com wrote: 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. GPMC IRQ line can shared between the multiple devices you connect on it. : Are you sure it fails ? I just tried booting OMAP4 with 3.4-rc4 and don't see the irq failure error message. What I am missing ? Issue happens on l-o master, this was mentioned in [1], now I feel right solution is to keep dev-id. Regards Afzal [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg68749.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] ARM: OMAP2+: fix gpmc request_irq
On Fri, May 18, 2012 at 12:46 PM, Mohammed, Afzal af...@ti.com wrote: Hi Santosh, On Fri, May 18, 2012 at 12:33:16, Shilimkar, Santosh wrote: + Afzal who has been doing quite a bit of GMPC work recently. On Fri, May 18, 2012 at 10:13 AM, Ming Lei ming@canonical.com wrote: 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. GPMC IRQ line can shared between the multiple devices you connect on it. : Are you sure it fails ? I just tried booting OMAP4 with 3.4-rc4 and don't see the irq failure error message. What I am missing ? Issue happens on l-o master, this was mentioned in [1], now I feel right solution is to keep dev-id. Thanks for the reference. removing SHARED flag is not solution and yes, you might have to keep the dev-id if that was the issue. 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: [PATCH] ARM: OMAP2+: fix gpmc request_irq
Hi, On Fri, May 18, 2012 at 3:19 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: : Are you sure it fails ? [1.778930] GPMC revision 6.0 [1.782226] gpmc: irq-52 could not claim: err -22 Thanks for the reference. removing SHARED flag is not solution and yes, you might have to keep the dev-id if that was the issue. Is the gpmc a shared interrupt line? SHARED is not needed at all for non shared interrupt line in hardware. Thanks, -- Ming Lei -- 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] ARM: OMAP2+: fix gpmc request_irq
On Fri, May 18, 2012 at 1:10 PM, Ming Lei ming@canonical.com wrote: Hi, On Fri, May 18, 2012 at 3:19 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: : Are you sure it fails ? [ 1.778930] GPMC revision 6.0 [ 1.782226] gpmc: irq-52 could not claim: err -22 Afzal pointed me to the failing tree. Thanks for the reference. removing SHARED flag is not solution and yes, you might have to keep the dev-id if that was the issue. Is the gpmc a shared interrupt line? SHARED is not needed at all for non shared interrupt line in hardware. The line is shared. 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
tps65910
Hey guys! Who knows how to initialize and use tps65910 driver in linux with am3517? I designed a board using the Craneboard schematic as a reference. Mistral provides the kernel 2.6.32 and it works fine. Now I'm porting the BSP to kernel 3.0.17 and don't know how to implement voltage regulator features with the tps65910 driver (it appeared in kernel 3.0 ) under kernel 3.0 environment. I'm watching board-omap3beagle.c as a reference and tps65910.c driver and can't find any correlation. Any suggestions? Any help is appreciated! Max -- 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()
On Fri, May 18, 2012 at 3:51 AM, Kevin Hilman khil...@ti.com wrote:
Tarun, Santosh,
Tarun Kanti DebBarma tarun.ka...@ti.com 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 khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
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?
Able to reproduce the problem. Tested on Zoom3 by enabling NFS.
Verified the time difference for the filesystem to boot. Without your
fixes it takes
around 60 seconds while with the fix it takes less than 7 seconds.
Tested-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
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 khil...@ti.com
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
Re: [PATCH] ARM: OMAP2+: fix gpmc request_irq
On Fri, May 18, 2012 at 3:43 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: Is the gpmc a shared interrupt line? SHARED is not needed at all for non shared interrupt line in hardware. The line is shared. If so, dev_id should be added. But sorry, could you let me know what other interrupt sources are shared with the line? From 17.3.2 Interrupt Requests to Cortex-A9 MPU INTC of OMAP4 TRM, GPMC_IRQ is the only source of MA_IRQ_20 for Cortex-A9 MPU INTC. Even though GPMC_IRQ is connected with D_IRQ_59(DSP INTC) and MA_IRQ_20(MPU INTC), this still means it is not a shared line for MPU INTC. Also looks the above is similar for OMAP3. Correct me if the above is wrong. Thanks, -- Ming Lei -- 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: tps65910
Hi Maxim, On Fri, May 18, 2012 at 13:23:53, Maxim Podbereznyy wrote: Hey guys! Who knows how to initialize and use tps65910 driver in linux with am3517? I designed a board using the Craneboard schematic as a reference. Mistral provides the kernel 2.6.32 and it works fine. Now I'm porting the BSP to kernel 3.0.17 and don't know how to implement voltage regulator features with the tps65910 driver (it appeared in kernel 3.0 ) under kernel 3.0 environment. I'm watching board-omap3beagle.c as a reference and tps65910.c driver and can't find any correlation. Any suggestions? Any help is appreciated! AM335X EVM (support not yet in mainline) works with tps65910, in case AM335X release helps you, git://arago-project.org/git/projects/linux-am33x.git v3.2_AM335xPSP_04.06.00.07 Regards Afzal -- 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 1/4] MFD: palmas PMIC device support
Hi Mark, On Tue, May 15, 2012 at 07:14:51PM +0100, Mark Brown wrote: On Tue, May 15, 2012 at 03:48:56PM +0900, Graeme Gregory wrote: Palmas is a PMIC from Texas Instruments and this is the MFD part of the driver for this chip. The PMIC has SMPS and LDO regulators, a general purpose ADC, GPIO, USB OTG mode detection, watchdog and RTC features. Reviwed-by: Mark Brown broo...@opensource.wolfsonmicro.com however this depends on some new regmap-irq changes that Graeme posted a couple of days ago and are only on regmap at the minute - Samuel, if you're OK with this I guess the easiest thing is if I apply there? I'm fine with it. For the MFD parts: Acked-by: Samuel Ortiz sa...@linux.intel.com Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: fix gpmc request_irq
On Fri, May 18, 2012 at 2:34 PM, Ming Lei ming@canonical.com wrote: On Fri, May 18, 2012 at 3:43 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: Is the gpmc a shared interrupt line? SHARED is not needed at all for non shared interrupt line in hardware. The line is shared. If so, dev_id should be added. But sorry, could you let me know what other interrupt sources are shared with the line? From 17.3.2 Interrupt Requests to Cortex-A9 MPU INTC of OMAP4 TRM, GPMC_IRQ is the only source of MA_IRQ_20 for Cortex-A9 MPU INTC. Even though GPMC_IRQ is connected with D_IRQ_59(DSP INTC) and MA_IRQ_20(MPU INTC), this still means it is not a shared line for MPU INTC. Generally IRQF_SHARED means, the interrupt line is only one but multiple devices can generate the interrupts. If you connect different devices on GMPC using chip selects like Ethernet controller, Nand, NOR contoller, all of they can generate events which can be reported by the GPMC. That's the reason I shared the line is shared. On the side note, looks like GMPC too needs to be converted to sparse IRQ since it seems to be creating a dummy irqchip and dispatching secondary handlers based on chip selects. 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: [PATCH] ARM: OMAP2+: fix gpmc request_irq
Hi Santosh, On Fri, May 18, 2012 at 15:43:31, Shilimkar, Santosh wrote: On the side note, looks like GMPC too needs to be converted to sparse IRQ since it seems to be creating a dummy irqchip and dispatching secondary handlers based on chip selects. GPMC dummy chip is being modified to so that irq descriptors are created dynamically [1], with a final goal of reaching something similar to [2], please let me know if any comments on those. Hi Ming, Requesting irq is called by driver of IP, while whether it is shared or not depends on SoC where IP lives, so ideally it seems platform should inform the driver whether it is shared driver should do what platform tells. Or else to be safe, it should be made shared always ? This may not make much sense now w.r.t gpmc, but would be applicable once gpmc becomes a driver (undergoing conversion), but may not be that important as there are no SoCs presently sharing gpmc interrupt (afaik) Regards Afzal [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg68745.html [2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67496.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] ARM: OMAP2+: fix gpmc request_irq
On Fri, May 18, 2012 at 4:21 PM, Mohammed, Afzal af...@ti.com wrote: Hi Santosh, On Fri, May 18, 2012 at 15:43:31, Shilimkar, Santosh wrote: On the side note, looks like GMPC too needs to be converted to sparse IRQ since it seems to be creating a dummy irqchip and dispatching secondary handlers based on chip selects. GPMC dummy chip is being modified to so that irq descriptors are created dynamically [1], with a final goal of reaching something similar to [2], please let me know if any comments on those. Cool. So it's already getting cleaned-up. Thanks for the reference. 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: [PATCH] ARM: OMAP2+: fix gpmc request_irq
Hi, On Fri, May 18, 2012 at 6:13 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: Generally IRQF_SHARED means, the interrupt line is only one but multiple devices can generate the interrupts. If you connect different devices on GMPC using chip selects like Ethernet controller, Nand, NOR contoller, all of they can generate events which can be reported by the GPMC. That's the reason I shared the line is shared. IMO, it depends on if the event handlers of other chips(ethernet, nand, nor..) share the same irq number(GPMC_IRQ). If so, it should be IRQF_SHARED. If they are handled in its own irq number(it may convert to irq dispatching), that shouldn't be IRQF_SHARED. On Fri, May 18, 2012 at 6:51 PM, Mohammed, Afzal af...@ti.com wrote: Hi Ming, Requesting irq is called by driver of IP, while whether it is shared or not depends on SoC where IP lives, so ideally it seems platform should inform the driver whether it is shared driver should do what platform tells. Or else to be safe, it should be made shared always ? Shared or not(IRQF_SHARED) may be determined by hardware and software handling. If the same interrupt line is shared by several peripherals and all interrupt handlers are requested to same interrupt number for handling IRQs from these peripherals, it should be IRQF_SHARED. This may not make much sense now w.r.t gpmc, but would be applicable once gpmc becomes a driver (undergoing conversion), but may not be that important as there are no SoCs presently sharing gpmc interrupt (afaik) Looks the fix isn't needed if so. Anyway, thanks your guys for exposing much info about GPMC irq handling. Thanks, -- Ming Lei -- 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] OMAPDSS: DSI: Support command mode interleaving during video mode blanking periods
Hi, On Tue, 2012-05-15 at 11:32 +0530, Archit Taneja wrote: DSI supports interleaving of command mode packets during the HSA, HFP, HBP and BLLP blanking intervals in a video mode stream. This is useful as a user may want to read or change the configuration of a panel without stopping the video stream. On OMAP DSI, we can queue HS or LP command mode packets in the TX FIFO, and the DSI HW takes care of interleaving this data during the one of the blanking intervals. The DSI HW needs to be programmed with the maximum amount of data that can be interleaved in a particular blanking period. A blanking period cannot be used to send command mode data for it's complete duration, there is some amount of time required for the DSI data and clock lanes to transition to the desired LP or HS state. Based on the state of the lanes at the beginning and end of the blanking period, we have different scenarios, with each scenario having a different value of time required to transition to HS or LP. Refer to the section 'Interleaving Mode' in OMAP TRM for more info on the scenarios and the equations to calculate the time required for HS or LP transitions. We use the scenarios which takes the maximum time for HS or LP transition, this gives us the minimum amount of time that can be used to interleave command mode data. The amount of data that can be sent during this minimum time is calculated for command mode packets both in LP and HS. These are written to the registers DSI_VM_TIMING4 to DSI_VM_TIMING6. The calculations don't take into account the time required of transmitting BTA when doing a DSI read, or verifying if a DSI write went through correctly. Until these latencies aren't considered, the behaviour of DSI is unpredictable when a BTA is interleaved during a blanking period. Enhancement of these calculations is a TODO item. The code in dsi_config_cmd_mode_interleaving() looks a bit long and confusing, but I don't think it's trivial to simplify it. There's just so many variables to consider. In the future I think we should store the DSI configurations into memory, so that we don't need to parse the hardware registers to find out things like DSI timings. I'll apply this, as it's very nice to have at least minimal interleaving support. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 8/8] gpio/omap: fix missing check in *_runtime_suspend()
Grant Likely grant.lik...@secretlab.ca writes: 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? We just found one more fix needed. I'm collecting the acks/tested-bys and will have a branch for you shortly. 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: [PATCHv5 3/8] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control register change
Shilimkar, Santosh santosh.shilim...@ti.com writes: On Thu, May 17, 2012 at 10:45 PM, Kevin Hilman khil...@ti.com wrote: [...] 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. Aha, that's the missing piece of the puzzle: The ROM code is clearing bits that are unused on r1pX (but used on r2pX). That is the root of this bug and needs more description. Thanks for clarifying. [...] Santosh, I do understand what is happening here. But I play dumb so that it will be described in great detail in the changelog so that when I forget (and you forget) we can go back to this and get a quick understanding of both the bug and the workaround. Since you are very deeply familiar with this bug, it's understandably hard to write this changelog since most things probably seem obvious to you. A suggestion would be to have a few colleagues that are not familiar with this bug read the changelog and try and describe it back to you. I agree with you. This is side effect of knowing some BUGs too much. I will work with Tero so that change log captures more details. Thanks. Maybe Jon Hunter can help review the changelog too. IMO, he is the reigning champion of thorough, descriptive and detailed changelogs. :) 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 1/4] MFD: palmas PMIC device support
On Fri, May 18, 2012 at 11:55:12AM +0200, Samuel Ortiz wrote: I'm fine with it. For the MFD parts: Acked-by: Samuel Ortiz sa...@linux.intel.com Applied all, thanks. I moved the header updates from the regulator into the MFD so the regulator driver can be applied via the regulator tree and the MFD via the regmap tree in order to preserve bisection. signature.asc Description: Digital signature
Re: [PATCH 01/11] ASoC: OMAP: HDMI: Introduce codec
On Fri, May 18, 2012 at 01:42:33AM -0500, Ricardo Neri wrote: 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. Applied this one, though I had to manually fix up the Kconfig and Makefile - you should always submit against the current development tree. signature.asc Description: Digital signature
Re: tps65910
Hi Mohammed! Thanks a lot! This code certainly can be used as a reference. I just wonder why it was not possible to rewrite tps65910 driver to comply with current twl interface? For example tps65910 API for the Craneboard is 100% the same as for OMAP3 and therefore porting features from Beagleboard to any board with tps65910 would be like 1-2-3. am33xx BSP is supported by TI, omap3evm is supported by TI, though both BSPs have absolutely different PMIC API in spite of they implement the same features.. Max 2012/5/18 Mohammed, Afzal af...@ti.com: Hi Maxim, On Fri, May 18, 2012 at 13:23:53, Maxim Podbereznyy wrote: Hey guys! Who knows how to initialize and use tps65910 driver in linux with am3517? I designed a board using the Craneboard schematic as a reference. Mistral provides the kernel 2.6.32 and it works fine. Now I'm porting the BSP to kernel 3.0.17 and don't know how to implement voltage regulator features with the tps65910 driver (it appeared in kernel 3.0 ) under kernel 3.0 environment. I'm watching board-omap3beagle.c as a reference and tps65910.c driver and can't find any correlation. Any suggestions? Any help is appreciated! AM335X EVM (support not yet in mainline) works with tps65910, in case AM335X release helps you, git://arago-project.org/git/projects/linux-am33x.git v3.2_AM335xPSP_04.06.00.07 Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] ASoC: OMAP: HDMI: Use DSS audio interface and prepare for OMAP5
On Fri, May 18, 2012 at 01:42:32AM -0500, Ricardo Neri wrote: 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 Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com signature.asc Description: Digital signature
Re: [PATCH 01/11] ASoC: OMAP: HDMI: Introduce codec
On 05/18/2012 11:32 AM, Mark Brown wrote: On Fri, May 18, 2012 at 01:42:33AM -0500, Ricardo Neri wrote: 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. Applied this one, though I had to manually fix up the Kconfig and Makefile - you should always submit against the current development tree. Thanks Mark! Sorry for the inconvenience, I will use the development tree in the future. -- 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 07/10] arm: omap4430sdp: Add support for omap4iss camera
Hi Sakari,
On Sun, May 13, 2012 at 7:24 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
Hi Sergio,
On Thu, May 03, 2012 at 10:20:47PM -0500, Aguirre, Sergio wrote:
Hi Sakari,
On Thu, May 3, 2012 at 7:03 AM, Aguirre, Sergio saagui...@ti.com wrote:
Hi Sakari,
Thanks for reviewing.
On Wed, May 2, 2012 at 2:47 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
Hi Sergio,
Thanks for the patches!!
On Wed, May 02, 2012 at 10:15:46AM -0500, Sergio Aguirre wrote:
...
+static int sdp4430_ov_cam1_power(struct v4l2_subdev *subdev, int on)
+{
+ struct device *dev = subdev-v4l2_dev-dev;
+ int ret;
+
+ if (on) {
+ if (!regulator_is_enabled(sdp4430_cam2pwr_reg)) {
+ ret = regulator_enable(sdp4430_cam2pwr_reg);
+ if (ret) {
+ dev_err(dev,
+ Error in enabling sensor power
regulator 'cam2pwr'\n);
+ return ret;
+ }
+
+ msleep(50);
+ }
+
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 1);
+ msleep(10);
+ ret = clk_enable(sdp4430_cam1_aux_clk); /* Enable XCLK */
+ if (ret) {
+ dev_err(dev,
+ Error in clk_enable() in %s(%d)\n,
+ __func__, on);
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
+ return ret;
+ }
+ msleep(10);
+ } else {
+ clk_disable(sdp4430_cam1_aux_clk);
+ msleep(1);
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
+ if (regulator_is_enabled(sdp4430_cam2pwr_reg)) {
+ ret = regulator_disable(sdp4430_cam2pwr_reg);
+ if (ret) {
+ dev_err(dev,
+ Error in disabling sensor power
regulator 'cam2pwr'\n);
+ return ret;
+ }
+ }
+ }
+
+ return 0;
+}
Isn't this something that should be part of the sensor driver? There's
nothing in the above code that would be board specific, except the names
of
the clocks, regulators and GPIOs. The sensor driver could hold the names
instead; this would be also compatible with the device tree.
Agreed. I see what you mean...
I'll take care of that.
Can you please check out these patches?
1.
http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/cb6c10d58053180364461e6bc8d30d1ec87e6e22
Ideally we should really get rid of the board code callbacks. What do you
need to do there?
Well, in a OMAP44xx Blaze:
http://svtronics.com/products/27-blaze-mdp
The CSI2-A interface has 2 possible sensor inputs:
- Sony IMX060 12 MP
- OmniVision OV5650 5MP
Which are muxed with a High speed differential selector.
(Analog devices part: ADG936, found here:
http://www.analog.com/static/imported-files/data_sheets/ADG936_936R.pdf)
And to make it more fun, you switch that with a GPIO in an Audio IC (TWL6040) !
Quite a mess, but leaves me with few options, so that's why I need
that to be board
specific, and that by providing these function that can be used to
take care of such
creative designs :P
Have better ideas?
2.
http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/6732e0db25c6647b34ef8f01c244a49a1fd6b45d
Isn't reset voltage level (high or low) a property of the sensor rather than
the board?
Well, I know sometimes the people who typically design the hardware can be
quite inventive. ;)
Unfortunately, that's exactly the case!
Again, in this creative design in Blaze platform I mentioned above,
they also have a
level inverter just before the RESET pin in the sensor. So that makes
it active high, from
the GPIO driver point of view :/
Not sure if there's a better way of handling this...
Thanks for the comments!
Regards,
Sergio
3.
http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/d61c4e3142dc9cae972f9128fe73d986838c0ca1
4.
http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/e83f36001c7f7cbe184ad094d9b0c95c39e5028f
Cheers,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media 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
On 18 May 2012 01:02, Stephen Warren swar...@wwwdotorg.org wrote: 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. As already noted by Russell, the dma setup is different than irq or gpio which deliberately lend to off-SoC attachments. Without fpga'ing, I find it hard to imagine request-signals going off-SoC. I only see the issue of different boards sporting a different sub-sets of clients i.e, a map entry may or may exist for a board but it would be same for two boards that have it. Maybe we could somehow separate out the chan-map and private-data into board.dts ? Even if it has to stay in soc.dts, we still have the benefit of having dmac agnostic client nodes. cheers! -- 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+: OPP: Fix to ensure check of right oppdef after bad one
Commit 9fa2df6b90786301b175e264f5fa9846aba81a65
(ARM: OMAP2+: OPP: allow OPP enumeration to continue if device is not present)
makes the logic:
for (i = 0; i opp_def_size; i++) {
snip
if (!oh || !oh-od) {
snip
continue;
}
snip
opp_def++;
}
In short, the moment we hit a Bad OPP, we end up looping the list
comparing against the bad opp definition pointer for the rest of the
iteration count. Instead, increment opp_def in the for loop itself
and allow continue to be used in code without much thought so that
we check the next set of OPP definition pointers :)
Cc: Kevin Hilman khil...@ti.com
Cc: Steve Sakoman st...@sakoman.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/opp.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
index de6d464..d8f6dbf 100644
--- a/arch/arm/mach-omap2/opp.c
+++ b/arch/arm/mach-omap2/opp.c
@@ -53,7 +53,7 @@ int __init omap_init_opp_table(struct omap_opp_def *opp_def,
omap_table_init = 1;
/* Lets now register with OPP library */
- for (i = 0; i opp_def_size; i++) {
+ for (i = 0; i opp_def_size; i++, opp_def++) {
struct omap_hwmod *oh;
struct device *dev;
@@ -86,7 +86,6 @@ int __init omap_init_opp_table(struct omap_opp_def *opp_def,
__func__, opp_def-freq,
opp_def-hwmod_name, i, r);
}
- opp_def++;
}
return 0;
--
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] ARM: OMAP: PM: Lock clocks list while generating summary
From: Todd Poynor toddpoy...@google.com commit a53025724052b2b1edbc982a4a248784638f563d (OMAP: Add debugfs node to show the summary of all clocks) Introduced clock summary, however, we are interested in seeing snapshot of the clock state, not in dynamically changing clock configurations as the data provided by clock summary will then be useless for debugging configuration issues. So, hold the common lock when dumping the clock summary. Cc: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org [n...@ti.com: added commit message] Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Todd Poynor toddpoy...@google.com --- arch/arm/plat-omap/clock.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c index 62ec5c4..706b7e2 100644 --- a/arch/arm/plat-omap/clock.c +++ b/arch/arm/plat-omap/clock.c @@ -461,6 +461,7 @@ static int clk_dbg_show_summary(struct seq_file *s, void *unused) struct clk *c; struct clk *pa; + mutex_lock(clocks_mutex); seq_printf(s, %-30s %-30s %-10s %s\n, clock-name, parent-name, rate, use-count); @@ -469,6 +470,7 @@ static int clk_dbg_show_summary(struct seq_file *s, void *unused) seq_printf(s, %-30s %-30s %-10lu %d\n, c-name, pa ? pa-name : none, c-rate, c-usecount); } + mutex_unlock(clocks_mutex); return 0; } -- 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] ARM: OMAP3+: PM: VP: ensure VP is idle before disable
From: Wenbiao Wang ww...@ti.com Voltage Processor state machine transition to disable need to occur from IDLE state. When we transition OPP in a functioning system, the call sequence for an OPP transition is as follows: omap_sr_disable - sr class 3 disable - vp disable - sr disable forceupdate to voltage/frequency scale depending on which OPP we are transitioning to. If we hit a critical timing window where SR had commanded VP for a voltage transition and VP is in the middle of operating on that command, it needs to go through a few states before going to update state(where it actually sends the command to VC). Initial view of h/w owners is that the state disable of VP is expected to be sampled for the next transition. Instead, to be on a safer side, we ensure that the valid states of the VP state machine is diligently followed by software. This can be done by waiting for VP to be in idle prior to disabling VP. As part of this change, increase timeout for VP idle check to improbable 500uSec to be certain that system is indeed unable to continue before crashing out with error(worst case expectancy remains the same 3-100uSec depending on when we caught VP). Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: linux-omap@vger.kernel.org (open list:OMAP SUPPORT) Cc: linux-arm-ker...@lists.infradead.org (moderated list:ARM PORT) [n...@ti.com: port from android] Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Wenbiao Wang ww...@ti.com --- arch/arm/mach-omap2/vp.c | 15 +-- arch/arm/mach-omap2/vp.h |2 +- 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c index f95c1ba..925d869 100644 --- a/arch/arm/mach-omap2/vp.c +++ b/arch/arm/mach-omap2/vp.c @@ -262,6 +262,17 @@ void omap_vp_disable(struct voltagedomain *voltdm) return; } + /* +* Wait for VP idle Typical latency is 2us. Maximum latency is ~100us +* Depending on if we catch VP in the middle of an SR operation. +*/ + omap_test_timeout((voltdm-read(vp-vstatus)), + VP_IDLE_TIMEOUT, timeout); + + if (timeout = VP_IDLE_TIMEOUT) + pr_warning(%s: vdd_%s idle timedout before disable\n, + __func__, voltdm-name); + /* Disable VP */ vpconfig = voltdm-read(vp-vpconfig); vpconfig = ~vp-common-vpconfig_vpenable; @@ -274,8 +285,8 @@ void omap_vp_disable(struct voltagedomain *voltdm) VP_IDLE_TIMEOUT, timeout); if (timeout = VP_IDLE_TIMEOUT) - pr_warning(%s: vdd_%s idle timedout\n, - __func__, voltdm-name); + pr_warning(%s: vdd_%s idle timedout after disable\n, + __func__, voltdm-name); vp-enabled = false; diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h index 7c155d2..0abf895 100644 --- a/arch/arm/mach-omap2/vp.h +++ b/arch/arm/mach-omap2/vp.h @@ -31,7 +31,7 @@ struct voltagedomain; #define OMAP4_VP_VDD_MPU_ID 2 /* XXX document */ -#define VP_IDLE_TIMEOUT200 +#define VP_IDLE_TIMEOUT500 #define VP_TRANXDONE_TIMEOUT 300 /** -- 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: [PATCH 3/6] arm: omap4: support pmu
Hi Ming,
On 05/16/2012 05:12 AM, Ming Lei wrote:
On Thu, May 10, 2012 at 5:35 AM, Jon Hunter jon-hun...@ti.com wrote:
+
+ /*configure CTI0 for pmu irq routing*/
+ cti_init(omap4_cti[0], base0, OMAP44XX_IRQ_CTI0, 6);
+ cti_unlock(omap4_cti[0]);
+ cti_map_trigger(omap4_cti[0], 1, 6, 2);
+
+ /*configure CTI1 for pmu irq routing*/
+ cti_init(omap4_cti[1], base1, OMAP44XX_IRQ_CTI1, 6);
+ cti_unlock(omap4_cti[1]);
+ cti_map_trigger(omap4_cti[1], 1, 6, 2);
As pointed in another thread, the above line should be changed to below:
cti_map_trigger(omap4_cti[1], 1, 6, 3);
which can avoid irq flood issue at high frequency sample mode.
For detailed description about the issue and fix, see below link:
http://permalink.gmane.org/gmane.linux.linaro.devel/10532
I was performing the test you mentioned in the above thread to reproduce the
problem. However, I was not able to reproduce the issue. Did you receive any
confirmation from Dmitry this fixed his issue for oprofile?
By the way, I did not find too many details about the actual fix in the above
thread. It appears to be mapping the interrupt to another channel. Can you
clarify what this change is doing?
I did see the following kernel dump when running the perf record test. Applying
your change did not help. Have you seen this? I am using the linux-omap master
branch.
[ 199.186859] INFO: rcu_sched self-detected stall on CPU { 1} (t=7680 jiffies)
[ 199.194427] [c001c5fc] (unwind_backtrace+0x0/0xf4) from [c00a8788]
(__rcu_pending+0x158/0x45c)
[ 199.203826] [c00a8788] (__rcu_pending+0x158/0x45c) from [c00a8afc]
(rcu_check_callbacks+0x70/0x1ac)
[ 199.213653] [c00a8afc] (rcu_check_callbacks+0x70/0x1ac) from [c0051a70]
(update_process_times+0x38/0x68)
[ 199.223968] [c0051a70] (update_process_times+0x38/0x68) from [c008970c]
(tick_sched_timer+0x88/0xd8)
[ 199.233917] [c008970c] (tick_sched_timer+0x88/0xd8) from [c0067550]
(__run_hrtimer+0x7c/0x1e0)
[ 199.243316] [c0067550] (__run_hrtimer+0x7c/0x1e0) from [c0067920]
(hrtimer_interrupt+0x108/0x294)
[ 199.252990] [c0067920] (hrtimer_interrupt+0x108/0x294) from [c001ad60]
(twd_handler+0x34/0x40)
[ 199.262359] [c001ad60] (twd_handler+0x34/0x40) from [c00a325c]
(handle_percpu_devid_irq+0x8c/0x138)
[ 199.272216] [c00a325c] (handle_percpu_devid_irq+0x8c/0x138) from
[c00a02e8] (generic_handle_irq+0x34/0x44)
[ 199.282714] [c00a02e8] (generic_handle_irq+0x34/0x44) from [c00153c0]
(handle_IRQ+0x4c/0xac)
[ 199.291900] [c00153c0] (handle_IRQ+0x4c/0xac) from [c0008480]
(gic_handle_irq+0x2c/0x60)
[ 199.300781] [c0008480] (gic_handle_irq+0x2c/0x60) from [c0482964]
(__irq_svc+0x44/0x60)
[ 199.309509] Exception stack(0xef217c40 to 0xef217c88)
[ 199.314819] 7c40: 00a2 ef0ef540 0202
ef216000 c19c0080
[ 199.323394] 7c60: c1a66d00 ef0ef7ac ef217d54 ef217c88
00a3 c004a380
[ 199.331939] 7c80: 6113
[ 199.335601] [c0482964] (__irq_svc+0x44/0x60) from [c004a380]
(__do_softirq+0x64/0x214)
[ 199.344268] [c004a380] (__do_softirq+0x64/0x214) from [c004a70c]
(irq_exit+0x90/0x98)
[ 199.352874] [c004a70c] (irq_exit+0x90/0x98) from [c00153c4]
(handle_IRQ+0x50/0xac)
[ 199.361145] [c00153c4] (handle_IRQ+0x50/0xac) from [c0008480]
(gic_handle_irq+0x2c/0x60)
[ 199.369995] [c0008480] (gic_handle_irq+0x2c/0x60) from [c0482964]
(__irq_svc+0x44/0x60)
[ 199.378753] Exception stack(0xef217cf8 to 0xef217d40)
[ 199.384033] 7ce0:
009f 0001
[ 199.392639] 7d00: ef0ef540 ef1254c0 ef073480
c19de118 c19bd6c0
[ 199.401184] 7d20: ef0ef7ac ef217d54 0001 ef217d40 00a0 c0071df8
2113
[ 199.409759] [c0482964] (__irq_svc+0x44/0x60) from [c0071df8]
(finish_task_switch+0x4c/0xf0)
[ 199.418884] [c0071df8] (finish_task_switch+0x4c/0xf0) from [c0481234]
(__schedule+0x410/0x808)
[ 199.428283] [c0481234] (__schedule+0x410/0x808) from [c0112274]
(pipe_wait+0x58/0x78)
[ 199.436859] [c0112274] (pipe_wait+0x58/0x78) from [c0112c3c]
(pipe_read+0x454/0x584)
[ 199.445343] [c0112c3c] (pipe_read+0x454/0x584) from [c0109220]
(do_sync_read+0xac/0xf4)
[ 199.454101] [c0109220] (do_sync_read+0xac/0xf4) from [c0109de4]
(vfs_read+0xac/0x130)
[ 199.462646] [c0109de4] (vfs_read+0xac/0x130) from [c0109f38]
(sys_read+0x40/0x70)
[ 199.470855] [c0109f38] (sys_read+0x40/0x70) from [c0014300]
(ret_fast_syscall+0x0/0x3c)
At the end of the test I also saw ...
Processed 18048959 events and lost 26 chunks!
Check IO/CPU overload!
Let me know if you have any thoughts.
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
[PATCH V2] ARM: OMAP3+: PM: VP: ensure VP is idle before disable
From: Wenbiao Wang ww...@ti.com Voltage Processor state machine transition to disable need to occur from IDLE state. When we transition OPP in a functioning system, the call sequence for an OPP transition is as follows: omap_sr_disable - sr class 3 disable - vp disable - sr disable forceupdate to voltage/frequency scale depending on which OPP we are transitioning to. If we hit a critical timing window where SR had commanded VP for a voltage transition and VP is in the middle of operating on that command, it needs to go through a few states before going to update state(where it actually sends the command to VC). Initial view of h/w owners is that the state disable of VP is expected to be sampled for the next transition. Instead, to be on a safer side, we ensure that the valid states of the VP state machine is diligently followed by software. This can be done by waiting for VP to be in idle prior to disabling VP. Existing prints have been updated to ensure context is available on error messages. As part of this change, increase timeout for VP idle check to improbable 500uSec to be certain that system is indeed unable to continue before crashing out with error(worst case expectancy remains the same 3-100uSec depending on when we caught VP). Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org [n...@ti.com: port from android] Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Wenbiao Wang ww...@ti.com --- V2: fix commit message - picked up redundant info from get_maintainer.pl Apologies on the spam V1: http://marc.info/?l=linux-omapm=133736493721977w=2 arch/arm/mach-omap2/vp.c | 15 +-- arch/arm/mach-omap2/vp.h |2 +- 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c index f95c1ba..925d869 100644 --- a/arch/arm/mach-omap2/vp.c +++ b/arch/arm/mach-omap2/vp.c @@ -262,6 +262,17 @@ void omap_vp_disable(struct voltagedomain *voltdm) return; } + /* +* Wait for VP idle Typical latency is 2us. Maximum latency is ~100us +* Depending on if we catch VP in the middle of an SR operation. +*/ + omap_test_timeout((voltdm-read(vp-vstatus)), + VP_IDLE_TIMEOUT, timeout); + + if (timeout = VP_IDLE_TIMEOUT) + pr_warning(%s: vdd_%s idle timedout before disable\n, + __func__, voltdm-name); + /* Disable VP */ vpconfig = voltdm-read(vp-vpconfig); vpconfig = ~vp-common-vpconfig_vpenable; @@ -274,8 +285,8 @@ void omap_vp_disable(struct voltagedomain *voltdm) VP_IDLE_TIMEOUT, timeout); if (timeout = VP_IDLE_TIMEOUT) - pr_warning(%s: vdd_%s idle timedout\n, - __func__, voltdm-name); + pr_warning(%s: vdd_%s idle timedout after disable\n, + __func__, voltdm-name); vp-enabled = false; diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h index 7c155d2..0abf895 100644 --- a/arch/arm/mach-omap2/vp.h +++ b/arch/arm/mach-omap2/vp.h @@ -31,7 +31,7 @@ struct voltagedomain; #define OMAP4_VP_VDD_MPU_ID 2 /* XXX document */ -#define VP_IDLE_TIMEOUT200 +#define VP_IDLE_TIMEOUT500 #define VP_TRANXDONE_TIMEOUT 300 /** -- 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/3] ARM: OMAP3+: VP: collate fixes
Reviewing the android code base brought out a few fixes that upstream does not have, so collating them and posting them out in this chain. Nishanth Menon (2): ARM: OMAP3+: PM: VP: check to ensure VP is idle before forceupdate ARM: OMAP3+: PM: VP: check only the VPINIDLE status bit Wenbiao Wang (1): ARM: OMAP3+: PM: VP: ensure VP is idle before disable arch/arm/mach-omap2/vp.c | 34 ++ arch/arm/mach-omap2/vp.h |3 ++- arch/arm/mach-omap2/vp3xxx_data.c |1 + arch/arm/mach-omap2/vp44xx_data.c |1 + 4 files changed, 34 insertions(+), 5 deletions(-) Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Regards, Nishanth Menon -- 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 1/3] ARM: OMAP3+: PM: VP: ensure VP is idle before disable
From: Wenbiao Wang ww...@ti.com Voltage Processor state machine transition to disable need to occur from IDLE state. When we transition OPP in a functioning system, the call sequence for an OPP transition is as follows: omap_sr_disable - sr class 3 disable - vp disable - sr disable forceupdate to voltage/frequency scale depending on which OPP we are transitioning to. If we hit a critical timing window where SR had commanded VP for a voltage transition and VP is in the middle of operating on that command, it needs to go through a few states before going to update state(where it actually sends the command to VC). Initial view of h/w owners is that the state disable of VP is expected to be sampled for the next transition. Instead, to be on a safer side, we ensure that the valid states of the VP state machine is diligently followed by software. This can be done by waiting for VP to be in idle prior to disabling VP. Existing prints have been updated to ensure context is available on error messages. As part of this change, increase timeout for VP idle check to improbable 500uSec to be certain that system is indeed unable to continue before crashing out with error(worst case expectancy remains the same 3-100uSec depending on when we caught VP). Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org [n...@ti.com: port from android] Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Wenbiao Wang ww...@ti.com --- arch/arm/mach-omap2/vp.c | 15 +-- arch/arm/mach-omap2/vp.h |2 +- 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c index f95c1ba..925d869 100644 --- a/arch/arm/mach-omap2/vp.c +++ b/arch/arm/mach-omap2/vp.c @@ -262,6 +262,17 @@ void omap_vp_disable(struct voltagedomain *voltdm) return; } + /* +* Wait for VP idle Typical latency is 2us. Maximum latency is ~100us +* Depending on if we catch VP in the middle of an SR operation. +*/ + omap_test_timeout((voltdm-read(vp-vstatus)), + VP_IDLE_TIMEOUT, timeout); + + if (timeout = VP_IDLE_TIMEOUT) + pr_warning(%s: vdd_%s idle timedout before disable\n, + __func__, voltdm-name); + /* Disable VP */ vpconfig = voltdm-read(vp-vpconfig); vpconfig = ~vp-common-vpconfig_vpenable; @@ -274,8 +285,8 @@ void omap_vp_disable(struct voltagedomain *voltdm) VP_IDLE_TIMEOUT, timeout); if (timeout = VP_IDLE_TIMEOUT) - pr_warning(%s: vdd_%s idle timedout\n, - __func__, voltdm-name); + pr_warning(%s: vdd_%s idle timedout after disable\n, + __func__, voltdm-name); vp-enabled = false; diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h index 7c155d2..0abf895 100644 --- a/arch/arm/mach-omap2/vp.h +++ b/arch/arm/mach-omap2/vp.h @@ -31,7 +31,7 @@ struct voltagedomain; #define OMAP4_VP_VDD_MPU_ID 2 /* XXX document */ -#define VP_IDLE_TIMEOUT200 +#define VP_IDLE_TIMEOUT500 #define VP_TRANXDONE_TIMEOUT 300 /** -- 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 2/3] ARM: OMAP3+: PM: VP: check to ensure VP is idle before forceupdate
Ideally in the flow of DVFS programming, VP should be in idle state (since we disabled it) before entering forceupdate. Ensure that this is the case. Not doing this could cause VP statemachine to enter invalid states. Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Signed-off-by: Vinay Amancha vinayku...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap2/vp.c | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c index 925d869..985091b 100644 --- a/arch/arm/mach-omap2/vp.c +++ b/arch/arm/mach-omap2/vp.c @@ -123,6 +123,18 @@ int omap_vp_forceupdate_scale(struct voltagedomain *voltdm, u8 target_vsel, current_vsel; int ret, timeout = 0; +/* +* Wait for VP idle Typical latency is 2us. Maximum latency is ~100us +* This is an additional allowance to ensure we are in proper state +* to enter into forceupdate state transition. +*/ + omap_test_timeout((voltdm-read(vp-vstatus)), + VP_IDLE_TIMEOUT, timeout); + + if (timeout = VP_IDLE_TIMEOUT) + pr_warning(%s: vdd_%s idle timedout forceupdate(v=%ld)\n, + __func__, voltdm-name, target_volt); + ret = omap_vc_pre_scale(voltdm, target_volt, target_vsel, current_vsel); if (ret) return 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
[PATCH] ARM: OMAP3+: dpll: optimize noncore dpll locking logic
From: Vikram Pandita vikram.pand...@ti.com
If the dpll is already locked, code can be optimized
to return much earlier than doing redundent set of lock mode
and wait on idlest.
Cc: Tony Lindgren t...@atomide.com
Cc: Jon Hunter jon-hun...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Mike Turquette mturque...@ti.com
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
arch/arm/mach-omap2/dpll3xxx.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index fc56745..3cfd7c4 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -135,11 +135,20 @@ static u16 _omap3_dpll_compute_freqsel(struct clk *clk,
u8 n)
*/
static int _omap3_noncore_dpll_lock(struct clk *clk)
{
+ const struct dpll_data *dd;
u8 ai;
- int r;
+ u8 state = 1;
+ int r = 0;
pr_debug(clock: locking DPLL %s\n, clk-name);
+ dd = clk-dpll_data;
+ state = __ffs(dd-idlest_mask);
+
+ /* Check if already locked */
+ if ((__raw_readl(dd-idlest_reg) dd-idlest_mask) == state)
+ goto done;
+
ai = omap3_dpll_autoidle_read(clk);
omap3_dpll_deny_idle(clk);
@@ -151,6 +160,7 @@ static int _omap3_noncore_dpll_lock(struct clk *clk)
if (ai)
omap3_dpll_allow_idle(clk);
+done:
return r;
}
--
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 3/3] ARM: OMAP3+: PM: VP: check only the VPINIDLE status bit
Currently we check against the entire 32 bits of the status register
Where, bits 1-31 are marked as reserved and mentioned in TRM as read
returns undefined values. Hence, check against purely the vpinidle
status bit.
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Reported-by: Vinay Amancha vinayku...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/vp.c | 15 +--
arch/arm/mach-omap2/vp.h |1 +
arch/arm/mach-omap2/vp3xxx_data.c |1 +
arch/arm/mach-omap2/vp44xx_data.c |1 +
4 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 985091b..cdcac16 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -128,8 +128,9 @@ int omap_vp_forceupdate_scale(struct voltagedomain *voltdm,
* This is an additional allowance to ensure we are in proper state
* to enter into forceupdate state transition.
*/
- omap_test_timeout((voltdm-read(vp-vstatus)),
- VP_IDLE_TIMEOUT, timeout);
+ omap_test_timeout((voltdm-read(vp-vstatus)
+ vp-common-vstatus_vpidle), VP_IDLE_TIMEOUT,
+ timeout);
if (timeout = VP_IDLE_TIMEOUT)
pr_warning(%s: vdd_%s idle timedout forceupdate(v=%ld)\n,
@@ -278,8 +279,9 @@ void omap_vp_disable(struct voltagedomain *voltdm)
* Wait for VP idle Typical latency is 2us. Maximum latency is ~100us
* Depending on if we catch VP in the middle of an SR operation.
*/
- omap_test_timeout((voltdm-read(vp-vstatus)),
- VP_IDLE_TIMEOUT, timeout);
+ omap_test_timeout((voltdm-read(vp-vstatus)
+ vp-common-vstatus_vpidle), VP_IDLE_TIMEOUT,
+ timeout);
if (timeout = VP_IDLE_TIMEOUT)
pr_warning(%s: vdd_%s idle timedout before disable\n,
@@ -293,8 +295,9 @@ void omap_vp_disable(struct voltagedomain *voltdm)
/*
* Wait for VP idle Typical latency is 2us. Maximum latency is ~100us
*/
- omap_test_timeout((voltdm-read(vp-vstatus)),
- VP_IDLE_TIMEOUT, timeout);
+ omap_test_timeout((voltdm-read(vp-vstatus)
+ vp-common-vstatus_vpidle), VP_IDLE_TIMEOUT,
+ timeout);
if (timeout = VP_IDLE_TIMEOUT)
pr_warning(%s: vdd_%s idle timedout after disable\n,
diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h
index 0abf895..876b5ab 100644
--- a/arch/arm/mach-omap2/vp.h
+++ b/arch/arm/mach-omap2/vp.h
@@ -73,6 +73,7 @@ struct omap_vp_common {
u8 vpconfig_initvdd;
u8 vpconfig_forceupdate;
u8 vpconfig_vpenable;
+ u8 vstatus_vpidle;
u8 vstepmin_stepmin_shift;
u8 vstepmin_smpswaittimemin_shift;
u8 vstepmax_stepmax_shift;
diff --git a/arch/arm/mach-omap2/vp3xxx_data.c
b/arch/arm/mach-omap2/vp3xxx_data.c
index bd89f80..a65909b 100644
--- a/arch/arm/mach-omap2/vp3xxx_data.c
+++ b/arch/arm/mach-omap2/vp3xxx_data.c
@@ -44,6 +44,7 @@ static const struct omap_vp_common omap3_vp_common = {
.vpconfig_initvdd = OMAP3430_INITVDD_MASK,
.vpconfig_forceupdate = OMAP3430_FORCEUPDATE_MASK,
.vpconfig_vpenable = OMAP3430_VPENABLE_MASK,
+ .vstatus_vpidle = OMAP3430_VPINIDLE_MASK,
.vstepmin_smpswaittimemin_shift = OMAP3430_SMPSWAITTIMEMIN_SHIFT,
.vstepmax_smpswaittimemax_shift = OMAP3430_SMPSWAITTIMEMAX_SHIFT,
.vstepmin_stepmin_shift = OMAP3430_VSTEPMIN_SHIFT,
diff --git a/arch/arm/mach-omap2/vp44xx_data.c
b/arch/arm/mach-omap2/vp44xx_data.c
index 8c031d1..9d14881 100644
--- a/arch/arm/mach-omap2/vp44xx_data.c
+++ b/arch/arm/mach-omap2/vp44xx_data.c
@@ -44,6 +44,7 @@ static const struct omap_vp_common omap4_vp_common = {
.vpconfig_initvdd = OMAP4430_INITVDD_MASK,
.vpconfig_forceupdate = OMAP4430_FORCEUPDATE_MASK,
.vpconfig_vpenable = OMAP4430_VPENABLE_MASK,
+ .vstatus_vpidle = OMAP4430_VPINIDLE_MASK,
.vstepmin_smpswaittimemin_shift = OMAP4430_SMPSWAITTIMEMIN_SHIFT,
.vstepmax_smpswaittimemax_shift = OMAP4430_SMPSWAITTIMEMAX_SHIFT,
.vstepmin_stepmin_shift = OMAP4430_VSTEPMIN_SHIFT,
--
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] usb: musb: handle nuked ep dma interrupt
From: Vikram Pandita vikram.pand...@ti.com
User can trigger disabling of gadget at run time while the
transfers are going on.
Eg: 1: rmmod of musb driver while transfers are going on
Eg: 2: On android doing:
echo 0/sys/class/android_usb/android0/enable
While a big file transfer is going on via PTP/MTP.
In such a case, musb_gadget_disable() calls nuke()
but the dma interrupt may still happen for an endpoint since hw
would raise the interrupt in anycase.
This can result in a NULL pointer access crash:
[ 314.030426] PC is at txstate+0x74/0x20c
[ 314.034759] LR is at musb_g_tx+0x140/0x204
[ 314.039489] pc : [c03506f4]lr : [c0350bcc]psr: 2193
[ 314.039520] sp : c783bc68 ip : 0002 fp : c783bc9c
[ 314.052429] r10: 0018 r9 : r8 : 0200
[ 314.058258] r7 : r6 : fc0ab130 r5 : c781a410 r4 : c6caf640
[ 314.065643] r3 : r2 : r1 : r0 : c781a000
[ 315.083251] Backtrace:
[ 315.086242] [c0350680] (txstate+0x0/0x20c) from [c0350bcc]
(musb_g_tx+0x140/0x204)
[ 315.095123] [c0350a8c] (musb_g_tx+0x0/0x204) from [c034eb00]
(musb_dma_completion+0x40/0x54)
[ 315.104980] [c034eac0] (musb_dma_completion+0x0/0x54) from [c0351e6c]
(dma_controller_irq+0x118/0x184)
[ 315.115661] [c0351d54] (dma_controller_irq+0x0/0x184) from [c00d86b8]
(handle_irq_event_percpu+0x54/0x188)
So put protection in code to handle possiblity of getting an interrupt for an
endpoint that might have been already nuked.
Reported-by: Todd Poynor toddpoy...@google.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
drivers/usb/musb/musb_gadget.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index f42c29b..695c892 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -328,6 +328,13 @@ static void txstate(struct musb *musb, struct musb_request
*req)
musb_ep = req-ep;
+ /* Check if EP is disabled */
+ if (!musb_ep-desc) {
+ dev_dbg(musb-controller, ep:%s disabled - ignore request\n,
+ musb_ep-end_point.name);
+ return;
+ }
+
/* we shouldn't get here while DMA is active ... but we do ... */
if (dma_channel_status(musb_ep-dma) == MUSB_DMA_STATUS_BUSY) {
dev_dbg(musb-controller, dma pending...\n);
@@ -650,6 +657,13 @@ static void rxstate(struct musb *musb, struct musb_request
*req)
len = musb_ep-packet_sz;
+ /* Check if EP is disabled */
+ if (!musb_ep-desc) {
+ dev_dbg(musb-controller, ep:%s disabled - ignore request\n,
+ musb_ep-end_point.name);
+ return;
+ }
+
/* We shouldn't get here while DMA is active, but we do... */
if (dma_channel_status(musb_ep-dma) == MUSB_DMA_STATUS_BUSY) {
dev_dbg(musb-controller, DMA pending...\n);
--
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: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On Wednesday 16 May 2012, Stephen Warren wrote: Simple case: /* e.g. FIFO TX DMA req - 2 DMACs possible */ dma-req-0 = dmac1 DMAC1_DMA_REQ_6; /* e.g. FIFO RX DMA req 1 DMAC possible */ dma-req-1 = dmac1 DMAC1_DMA_REQ_8; Multiple DMAC case: /* e.g. FIFO TX DMA req - 2 DMACs possible */ dma-req-0 = dmac1 DMAC1_DMA_REQ_6 dmac2 DMA_2_DMA_REQ_8; /* e.g. FIFO RX DMA req 1 DMAC possible */ dma-req-1 = dmac1 DMAC1_DMA_REQ_8; Then, when the DMA client calls the standard API to get DMA channel for my outbound DMA request n, the core code will kasprintf(dma-req-%d, n); to generate the property name. That's how pinctrl works. Does that seem better? Yes, that is one way that I suggested at an earlier point. After some discussion, I would use a different syntax for these though, to the exact same effect, writing it as dmas = dmac1 DMAC1_DMA_REQ_6, dmac2 DMA_2_DMA_REQ_8, dmac1 DMAC1_DMA_REQ_8; dma-names = tx, tx, rx; The driver can still request the dma line by name tx and the subsystem would pick one out of those with the same name. For the majority of cases, we would only need a single dma request line and could leave out the dma-names property, so when you don't ask for a specific name, you just get any dma line out of the dmas array. Arnd -- 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
On Wednesday 16 May 2012, Jassi Brar wrote: On 17 May 2012 01:12, Arnd Bergmann a...@arndb.de wrote: 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. The idea was that a client shouldn't need to know/tell which dma controller serves it or which peripheral interface of a dma controller. I think in future third-party device IPs, like ARM's Primecell, are only gonna get more common so it makes even more sense. I don't understand why this is an advantage. I definitely agree that the client driver should not know or care about the type of DMA controller that is being used, IMHO it makes a lot of sense if the device node specifies the dma line in the way that is specific to the controller. It already does the same thing for IRQ, GPIO and other stuff, so it's consistent and not an additional burden on the author of the device tree source file. I believe that it can work and that it solves the problem you are faced with at minimal complexity, but you put the burden of this complexity on everybody who does not have this issue, and make the general binding confusing and harder to read. I am sorry if I gave you the wrong impression, but I didn't intend to just scratch my personal itch. I truly believed I and Stephen reached a generic solution i.e, as much as it could be. Yes, I realize I should have stepped in earlier. The proposal you have made is indeed generic and can cover important cases that the original proposal did not. My objection is that it's too complex at doing that for the common case though and that I think we can get a simpler solution that still solves the same problem. I already replied to Stephen expanding on his proposed solution, which I find reasonable, especially in the refined version of my reply. Like your proposal, it treats multiple dma engines for the same client as the normal case, by slightly extending the binding that Jon posted. Another solution that I find equally ok is the one that I proposed earlier in this thread, where we assume that for each dma request line there is exactly one dma engine master, and then add either a map (similar to the interrupt-map property) to cover the complex case in a special way, or to extend the binding for a specific dma engine so that you can have a single device node represent all dma engines of the same soc, separating this from the multiple struct dma_device instances that represent the multiple hardware blocks in Linux. Arnd -- 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
On 05/18/2012 02:49 PM, Arnd Bergmann wrote: On Wednesday 16 May 2012, Stephen Warren wrote: Simple case: /* e.g. FIFO TX DMA req - 2 DMACs possible */ dma-req-0 = dmac1 DMAC1_DMA_REQ_6; /* e.g. FIFO RX DMA req 1 DMAC possible */ dma-req-1 = dmac1 DMAC1_DMA_REQ_8; Multiple DMAC case: /* e.g. FIFO TX DMA req - 2 DMACs possible */ dma-req-0 = dmac1 DMAC1_DMA_REQ_6 dmac2 DMA_2_DMA_REQ_8; /* e.g. FIFO RX DMA req 1 DMAC possible */ dma-req-1 = dmac1 DMAC1_DMA_REQ_8; Then, when the DMA client calls the standard API to get DMA channel for my outbound DMA request n, the core code will kasprintf(dma-req-%d, n); to generate the property name. That's how pinctrl works. Does that seem better? Yes, that is one way that I suggested at an earlier point. After some discussion, I would use a different syntax for these though, to the exact same effect, writing it as dmas = dmac1 DMAC1_DMA_REQ_6, dmac2 DMA_2_DMA_REQ_8, dmac1 DMAC1_DMA_REQ_8; dma-names = tx, tx, rx; That looks pretty reasonable. One comment below. The driver can still request the dma line by name tx and the subsystem would pick one out of those with the same name. For the majority of cases, we would only need a single dma request line Hmm. Many devices have multiple different FIFOs, and hence multiple DMA request signals (e.g. Tegra I2S has separate RX and TX FIFO, Tegra S/PDIF has 2 FIFOs in each direction). That would require the driver to always use get_by_name() to differentiate between 2/4 options for the same DMA req or 2/4 different DMA requests. Most other bindings allow use of get_by_id() or get_by_name() interchangeably. and could leave out the dma-names property, so when you don't ask for a specific name, you just get any dma line out of the dmas array. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] arm: omap4: create pmu device via hwmod
Hi Benoit,
On 05/10/2012 04:56 AM, Cousson, Benoit wrote:
Hi Jon Ming,
On 5/9/2012 11:35 PM, Jon Hunter wrote:
From: Ming Leiming@canonical.com
The following modules is required to be enabled before configuring
cross trigger interface for enabling pmu irq:
l3_instr, l3_main_3, debugss
so build the arm-pmu device via the three hwmods.
Cc: Ming Leiming@canonical.com
Cc: Will Deaconwill.dea...@arm.com
Cc: Benoit Coussonb-cous...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
Cc: Kevin Hilmankhil...@ti.com
Signed-off-by: Ming Leiming@canonical.com
Signed-off-by: Will Deaconwill.dea...@arm.com
Signed-off-by: Jon Hunterjon-hun...@ti.com
---
arch/arm/mach-omap2/devices.c | 61
++---
1 files changed, 57 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c
b/arch/arm/mach-omap2/devices.c
index 58682d1..d75b7d3 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -423,14 +423,67 @@ static struct platform_device omap_pmu_device = {
.num_resources= 1,
};
-static void omap_init_pmu(void)
+static struct arm_pmu_platdata omap4_pmu_data;
+static struct omap_device_pm_latency omap_pmu_latency[] = {
+[0] = {
+.deactivate_func = omap_device_idle_hwmods,
+.activate_func = omap_device_enable_hwmods,
+.flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+},
+};
You can get rid of that, and use a NULL value during
omap_device_build_ss. It will use the default value automatically.
I have removed this now for V2.
+static struct platform_device* __init omap4_init_pmu(void)
{
-if (cpu_is_omap24xx())
+int id = -1;
+const char *hw;
+struct platform_device *pd;
+struct omap_hwmod* oh[3];
+char *dev_name = arm-pmu;
+
+hw = l3_main_3;
+oh[0] = omap_hwmod_lookup(hw);
+if (!oh[0]) {
+pr_err(Could not look up %s hwmod\n, hw);
+return NULL;
+}
+hw = l3_instr;
+oh[1] = omap_hwmod_lookup(hw);
+if (!oh[1]) {
+pr_err(Could not look up %s hwmod\n, hw);
+return NULL;
+}
+hw = debugss;
+oh[2] = omap_hwmod_lookup(hw);
+if (!oh[2]) {
+pr_err(Could not look up %s hwmod\n, hw);
+return NULL;
+}
+
+pd = omap_device_build_ss(dev_name, id, oh, 3,omap4_pmu_data,
+sizeof(omap4_pmu_data),
+omap_pmu_latency,
+ARRAY_SIZE(omap_pmu_latency), 0);
+WARN(IS_ERR(pd), Can't build omap_device for %s.\n,
+dev_name);
+return pd;
+}
+static void __init omap_init_pmu(void)
+{
+if (cpu_is_omap24xx()) {
omap_pmu_device.resource =omap2_pmu_resource;
Ideally, OMAP2 and 3 should use the hwmod device creation as well.
Do you know for OMAP2/3 what hwmods are needed for PMU support? Is it
just the MPU?
I see two options here for OMAP2/3 ...
1. Add the appropriate PMU interrupts to the MPU HWMOD and use the MPU
HWMOD to build the pmu device.
2. Create a new PMU HWMOD for OMAP2/3.
Please note that for 4460, I can get PMU to work without needing the EMU
PD if I use the PMU interrupts and not CTI. So this really simplifies
matters for 4460 (and 4470). For 4460 I have created the PMU device by
just using the MPU HWMOD and adding the PMU interrupts to the MPU HWMOD.
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 V3 1/2] of: Add generic device tree DMA helpers
On Friday 18 May 2012, Stephen Warren wrote: The driver can still request the dma line by name tx and the subsystem would pick one out of those with the same name. For the majority of cases, we would only need a single dma request line Hmm. Many devices have multiple different FIFOs, and hence multiple DMA request signals (e.g. Tegra I2S has separate RX and TX FIFO, Tegra S/PDIF has 2 FIFOs in each direction). That would require the driver to always use get_by_name() to differentiate between 2/4 options for the same DMA req or 2/4 different DMA requests. Most other bindings allow use of get_by_id() or get_by_name() interchangeably. Ok, good point. So we could make the common case that they are numbered but not named and require all drivers to use named properties when there is the possibility that the device might be connected to multiple controllers, but that seems tricky because a driver can start being used on a platform that has only one controller and have no dma-name property in the device tree but then get used on a different soc that actually has multiple controllers. So if we do that, we might want to make the dma-names property mandatory for every device, and document what the names are. Another option would be to encode the direction in the property in a generic way and provide an API that lets you ask specifically for a read, write or readwrite channel out of the ones that are available, rather than assuming there is only one kind. Consequently, any device that uses more than one read channel or more than one write channel would still have to use names to identify them. Arnd -- 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
[GIT PULL] gpio/omap: fix fallout from last cleanup series
Hi Grant, Here's the promised branch that fixes the fallout from the last cleanup series which introduced a few new bugs in the cleanup. :( I collected the acks/tested-bys from the list. Thanks, Kevin The following changes since commit 1b1287032df3a69d3ef9a486b444f4ffcca50d01: gpio/omap: fix missing check in *_runtime_suspend() (2012-05-11 17:08:40 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.5/fixes/gpio-2 for you to fetch changes up to b3c64bc30af67ed328a8d919e41160942b870451: gpio/omap: (re)fix wakeups on level-triggered GPIOs (2012-05-18 07:05:06 -0700) Kevin Hilman (2): gpio/omap: fix broken context restore for non-OFF mode transitions gpio/omap: (re)fix wakeups on level-triggered GPIOs drivers/gpio/gpio-omap.c |9 - 1 file changed, 4 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] gpio/omap: fix fallout from last cleanup series
On Fri, May 18, 2012 at 4:16 PM, Kevin Hilman khil...@ti.com wrote: Hi Grant, Here's the promised branch that fixes the fallout from the last cleanup series which introduced a few new bugs in the cleanup. :( I collected the acks/tested-bys from the list. Merged, thanks. g. Thanks, Kevin The following changes since commit 1b1287032df3a69d3ef9a486b444f4ffcca50d01: gpio/omap: fix missing check in *_runtime_suspend() (2012-05-11 17:08:40 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.5/fixes/gpio-2 for you to fetch changes up to b3c64bc30af67ed328a8d919e41160942b870451: gpio/omap: (re)fix wakeups on level-triggered GPIOs (2012-05-18 07:05:06 -0700) Kevin Hilman (2): gpio/omap: fix broken context restore for non-OFF mode transitions gpio/omap: (re)fix wakeups on level-triggered GPIOs drivers/gpio/gpio-omap.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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
On 05/18/2012 03:43 PM, Arnd Bergmann wrote: On Friday 18 May 2012, Stephen Warren wrote: The driver can still request the dma line by name tx and the subsystem would pick one out of those with the same name. For the majority of cases, we would only need a single dma request line Hmm. Many devices have multiple different FIFOs, and hence multiple DMA request signals (e.g. Tegra I2S has separate RX and TX FIFO, Tegra S/PDIF has 2 FIFOs in each direction). That would require the driver to always use get_by_name() to differentiate between 2/4 options for the same DMA req or 2/4 different DMA requests. Most other bindings allow use of get_by_id() or get_by_name() interchangeably. Ok, good point. So we could make the common case that they are numbered but not named and require all drivers to use named properties when there is the possibility that the device might be connected to multiple controllers, but that seems tricky because a driver can start being used on a platform that has only one controller and have no dma-name property in the device tree but then get used on a different soc that actually has multiple controllers. Indeed. So if we do that, we might want to make the dma-names property mandatory for every device, and document what the names are. We could do that, but one more proposal: Add the client's ID/index into the dmas property, so: simple 1 req: dmas = 0 dmac1 xxx; simple 2 req: dmas = 0 dmac1 xxx 1 dmac1 yyy; multiple dmacs: dmas = 0 dmac1 xxx 0 dmac2 zzz 1 dmac1 yyy; (i.e. dmas = [client_dma_req_id phandle dma-specifier]*) (where 0==TX_FIFO, 1=RX_FIFO for example, but could also have 2=TX_FIFO_B, 3=RX_FIFO_B, ...) Then dma-names would map name to ID, but you'd still need to search all through the dmas property to find the ID match. Another option would be to encode the direction in the property in a generic way and provide an API that lets you ask specifically for a read, write or readwrite channel out of the ones that are available, rather than assuming there is only one kind. Consequently, any device that uses more than one read channel or more than one write channel would still have to use names to identify them. I'm not sure that /just/ direction cuts it; Tegra's SPDIF has 2 TX DMAs (PCM data and control data) and same for RX. The format above is roughly the same as what you proposed, but with an explicit ID rather than direction in the dmas property. -- 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] OMAP: control: bootaddr and bootmod APIs
Hello Omar, On Wed, 2 May 2012, Omar Ramirez Luna wrote: Recently a patch went in for tidspbridge code, to ioremap SCM registers and solve a build break[1]. However it has been pointed out before that this is a layer violation given that control module should handle its own registers, this series is an attempt to create APIs for the users of these registers. With some adaptations this patch might also make use of it: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg66491.html Patch: staging: tidspbridge: use scm functions to set boot address and mode, will be sent separately to staging tree. Tested on OMAP3 Beagleboard. [1] http://www.mail-archive.com/devel@linuxdriverproject.org/msg18762.html Omar Ramirez Luna (3): OMAP2+: control: new APIs to configure boot address and mode OMAP: dsp: interface to control module functions staging: tidspbridge: use scm functions to set boot address and mode Thanks, queued for 3.6. - 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
