Re: [PATCH 0/3] ARM: OMAP5+: Support Duty Cycle Correction(DCC)
Quoting Nishanth Menon (2014-05-16 03:45:57) > Hi, > > This patch series has been carried over in vendor kernel for quiet > few years now. > > Unfortunately, it was very recently re-discovered and upstream kernel > is noticed to be broken for OMAP5 1.5GHz - at least we are operating > DPLL at frequency higher than what it was intended to be when CPUFreq > is enabled. Thankfully, with nominal voltage(we dont use AVS yet in > upstream for the mentioned platforms) and margins in trimming, we > have so far not crashed - but I strongly suspect this might be some > boundary case survival. DCC also exists in OMAP4. In some cases customers used it, in other cases we just ran the PLL way out of spec and the mpu_clk would divide by 2. Is this broken for OMAP4 as well? Regards, Mike > > Verified on the following impacted platforms using 3.15-rc4 based > vendor kernel. > > Before: > OMAP5432: http://slexy.org/view/s20cs0qQFg > DRA72x: http://slexy.org/view/s2TXtSa6mH (refused to lock) > DRA75x: http://slexy.org/view/s20AW8MU5c > After: > OMAP5432: http://slexy.org/view/s21iAfWxpu > DRA72x: http://slexy.org/view/s2hwsvGLmC (locks properly) > DRA75x: http://slexy.org/view/s21ehw8WQn > > Hopefully, we can get these into some kernel revision in some form. > > NOTE: Support for 4470(which is the only other platform requiring > DCC) is not present in upstream kernel and there are no plans to > support that SoC, even if it is added at a later point, support can be > extended as needed. > > Series based on v3.15-rc5 tag. > Also available on my tree: > https://github.com/nmenon/linux-2.6-playground/ > branch: push/clock/dcc > > weblink: > https://github.com/nmenon/linux-2.6-playground/commits/push/clock/dcc > > Verification: > 3.15-rc4 based kernel - DRA75x-evm, 72x-evm, OMAP5uevm > 3.15-rc5 - OMAP5uEVM(only one supporting 1.5GHz atm) > > Andrii Tseglytskyi (1): > ARM: OMAP5+: dpll: support Duty Cycle Correction(DCC) > > Nishanth Menon (2): > clk: dpll: support OMAP5 MPU DPLL that need special handling for > higher frequencies > ARM: dts: OMAP5/DRA7: use omap5-mpu-dpll-clock capable of dealing > with higher frequencies > > .../devicetree/bindings/clock/ti/dpll.txt |1 + > arch/arm/boot/dts/dra7xx-clocks.dtsi |2 +- > arch/arm/boot/dts/omap54xx-clocks.dtsi |2 +- > arch/arm/mach-omap2/dpll3xxx.c |9 + > drivers/clk/ti/dpll.c | 21 > > include/linux/clk/ti.h |4 > 6 files changed, 37 insertions(+), 2 deletions(-) > > 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
Get designer watches for less
I now know where to get my trusted branded goods http://smilingsoulcoaching.com/llltdud.php -- 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 13/13] ASoC: omap: Add Kconfig option for OMAP5 HDMI audio
Adds SND_OMAP_SOC_OMAP5_HDMI config option for OMAP5 HDMI audio support. Signed-off-by: Jyri Sarha --- sound/soc/omap/Kconfig | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index d44463a..697e1b8 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -101,7 +101,7 @@ config SND_OMAP_SOC_OMAP_ABE_TWL6040 - PandaBoardES (4460) config SND_OMAP_SOC_OMAP_HDMI - tristate "SoC Audio support for Texas Instruments OMAP HDMI" + tristate "SoC Audio support for Texas Instruments OMAP4 HDMI" depends on SND_OMAP_SOC && OMAP4_DSS_HDMI && OMAP2_DSS select SND_OMAP_SOC_HDMI select SND_SOC_HDMI_CODEC @@ -110,6 +110,17 @@ config SND_OMAP_SOC_OMAP_HDMI Say Y if you want to add support for SoC HDMI audio on Texas Instruments OMAP4 chips + +config SND_OMAP_SOC_OMAP5_HDMI + tristate "SoC Audio support for Texas Instruments OMAP5 HDMI" + depends on SND_OMAP_SOC && OMAP5_DSS_HDMI && OMAP2_DSS + select SND_OMAP_SOC_HDMI + select SND_SOC_HDMI_CODEC + select OMAP5_DSS_HDMI_AUDIO + help + Say Y if you want to add support for SoC HDMI audio on Texas Instruments + OMAP5 chips + config SND_OMAP_SOC_OMAP3_PANDORA tristate "SoC Audio support for OMAP3 Pandora" depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP3_PANDORA -- 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 02/13] ARM: omap5.dtsi: Add audio related parameters to hdmi node
Adds HDMI audio sDMA properties. Signed-off-by: Jyri Sarha --- arch/arm/boot/dts/omap5.dtsi |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 32c02ce..279a9c7 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -937,6 +937,8 @@ ti,hwmods = "dss_hdmi"; clocks = <&dss_48mhz_clk>, <&dss_sys_clk>; clock-names = "fck", "sys_clk"; + dmas = <&sdma 76>; + dma-names = "audio_tx"; }; }; }; -- 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 06/13] ASoC: omap-hdmi-dai: Add platform data struct for omap-hdmi-dai driver
Provide the means to pass OMAPDSS HDMI resources over to omap-hdmi-dai
driver when the OMAPDSS driver registers the DAI driver.
Signed-off-by: Jyri Sarha
---
include/sound/omap-hdmi-dai-pdata.h | 31 +++
1 file changed, 31 insertions(+)
create mode 100644 include/sound/omap-hdmi-dai-pdata.h
diff --git a/include/sound/omap-hdmi-dai-pdata.h
b/include/sound/omap-hdmi-dai-pdata.h
new file mode 100644
index 000..337c859
--- /dev/null
+++ b/include/sound/omap-hdmi-dai-pdata.h
@@ -0,0 +1,31 @@
+/*
+ * omap-hdmi-dai-pdata.h
+ *
+ * Platform data for OMAP ALSA SoC DAI driver for HDMI audio on OMAP4+
+ * processors.
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ * Authors: Jyri Sarha
+ *
+ * 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.
+ *
+ */
+
+#ifndef __OMAP_HDMI_DAI_PDATA_H__
+#define __OMAP_HDMI_DAI_PDATA_H__
+
+struct omap_dss_device;
+
+struct asoc_omap_hdmi_dai_pdata {
+ struct omap_dss_device *dssdev;
+ dma_addr_t dma_addr;
+ unsigned int dma_req;
+};
+
+#endif
--
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 09/13] ASoC: omap-hdmi-card: Changes for registeing the driver from OMAPDSS
The old OMAP HDMI audio registering from arch/arm/mach-omap2/devices.c
was broken. The new approach is to register the drivers from OMAPDSS HDMI
driver. The commit does the necessary changes for this approach.
Signed-off-by: Jyri Sarha
---
sound/soc/omap/omap-hdmi-card.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/sound/soc/omap/omap-hdmi-card.c b/sound/soc/omap/omap-hdmi-card.c
index f649fe8..56c0055 100644
--- a/sound/soc/omap/omap-hdmi-card.c
+++ b/sound/soc/omap/omap-hdmi-card.c
@@ -26,15 +26,13 @@
#include
#include
#include
+#include
#define DRV_NAME "omap-hdmi-audio"
static struct snd_soc_dai_link omap_hdmi_dai = {
.name = "HDMI",
.stream_name = "HDMI",
- .cpu_dai_name = "omap-hdmi-audio-dai",
- .platform_name = "omap-hdmi-audio-dai",
- .codec_name = "hdmi-audio-codec",
.codec_dai_name = "hdmi-hifi",
};
@@ -47,14 +45,28 @@ static struct snd_soc_card snd_soc_omap_hdmi = {
static int omap_hdmi_probe(struct platform_device *pdev)
{
+ struct device *dev = &pdev->dev;
+ struct asoc_omap_hdmi_card_pdata *pdata = dev->platform_data;
struct snd_soc_card *card = &snd_soc_omap_hdmi;
int ret;
+ if (!pdata) {
+ dev_err(dev, "No platform data, bailing out\n");
+ return -ENODEV;
+ }
+
card->dev = &pdev->dev;
+ omap_hdmi_dai.cpu_dai_name =
+ devm_kstrdup(dev, pdata->cpudai_name, GFP_KERNEL);
+ omap_hdmi_dai.platform_name =
+ devm_kstrdup(dev, pdata->cpudai_name, GFP_KERNEL);
+ omap_hdmi_dai.codec_name =
+ devm_kstrdup(dev, pdata->codec_name, GFP_KERNEL);
+
ret = snd_soc_register_card(card);
if (ret) {
- dev_err(&pdev->dev, "snd_soc_register_card failed (%d)\n", ret);
+ dev_err(dev, "snd_soc_register_card failed (%d)\n", ret);
card->dev = NULL;
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 10/13] OMAPDSS: hdmi4: Register HDMI audio ASoC drivers from HDMI driver
The registering is best done here to share the resources owned by OMAPDSS
HDMI driver with ASoC DAI and platform drivers.
Signed-off-by: Jyri Sarha
---
drivers/video/fbdev/omap2/dss/hdmi4.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi4.c
b/drivers/video/fbdev/omap2/dss/hdmi4.c
index 626aad2..62ad1d9 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi4.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi4.c
@@ -52,6 +52,9 @@ static struct {
struct clk *sys_clk;
struct regulator *vdda_hdmi_dac_reg;
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+ struct hdmi_audio_data audio;
+#endif
bool core_enabled;
struct omap_dss_device output;
@@ -736,6 +739,15 @@ static int omapdss_hdmihw_probe(struct platform_device
*pdev)
hdmi_init_output(pdev);
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+ r = hdmi_audio_register(pdev, &hdmi.audio, &hdmi.output, &hdmi.wp);
+ if (r) {
+ DSSERR("Registering HDMI audio failed\n");
+ hdmi_uninit_output(pdev);
+ pm_runtime_disable(&pdev->dev);
+ return r;
+ }
+#endif
dss_debugfs_create_file("hdmi", hdmi_dump_regs);
return 0;
@@ -743,6 +755,9 @@ static int omapdss_hdmihw_probe(struct platform_device
*pdev)
static int __exit omapdss_hdmihw_remove(struct platform_device *pdev)
{
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+ hdmi_audio_unregister(&hdmi.audio);
+#endif
hdmi_uninit_output(pdev);
pm_runtime_disable(&pdev->dev);
--
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 08/13] ASoC: omap-hdmi: Changes for registeing the driver from OMAPDSS
The old OMAP HDMI audio registering from arch/arm/mach-omap2/devices.c
was broken. The new approach is to register it from OMAPDSS HDMI
driver. The commit does the necessary changes for this approach to
omap-hdmi-dai driver.
Signed-off-by: Jyri Sarha
---
sound/soc/omap/omap-hdmi.c | 65
1 file changed, 17 insertions(+), 48 deletions(-)
diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c
index 537a1ec..ed0a37c 100644
--- a/sound/soc/omap/omap-hdmi.c
+++ b/sound/soc/omap/omap-hdmi.c
@@ -35,6 +35,7 @@
#include
#include
+#include
#include "omap-hdmi.h"
#include "omap-pcm.h"
@@ -65,7 +66,7 @@ static int omap_hdmi_dai_startup(struct snd_pcm_substream
*substream,
return err;
}
- if (!priv->dssdev->driver->audio_supported(priv->dssdev)) {
+ if (!priv->dssdev->ops.hdmi->audio_supported(priv->dssdev)) {
dev_err(dai->dev, "audio not supported\n");
return -ENODEV;
}
@@ -80,7 +81,7 @@ static int omap_hdmi_dai_prepare(struct snd_pcm_substream
*substream,
{
struct hdmi_priv *priv = snd_soc_dai_get_drvdata(dai);
- return priv->dssdev->driver->audio_enable(priv->dssdev);
+ return priv->dssdev->ops.hdmi->audio_enable(priv->dssdev);
}
static int omap_hdmi_dai_hw_params(struct snd_pcm_substream *substream,
@@ -206,7 +207,7 @@ static int omap_hdmi_dai_hw_params(struct snd_pcm_substream
*substream,
priv->dss_audio.iec = iec;
priv->dss_audio.cea = cea;
- err = priv->dssdev->driver->audio_config(priv->dssdev,
+ err = priv->dssdev->ops.hdmi->audio_config(priv->dssdev,
&priv->dss_audio);
return err;
@@ -222,12 +223,12 @@ static int omap_hdmi_dai_trigger(struct snd_pcm_substream
*substream, int 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);
+ err = priv->dssdev->ops.hdmi->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);
+ priv->dssdev->ops.hdmi->audio_stop(priv->dssdev);
break;
default:
err = -EINVAL;
@@ -240,7 +241,7 @@ static void omap_hdmi_dai_shutdown(struct snd_pcm_substream
*substream,
{
struct hdmi_priv *priv = snd_soc_dai_get_drvdata(dai);
- priv->dssdev->driver->audio_disable(priv->dssdev);
+ priv->dssdev->ops.hdmi->audio_disable(priv->dssdev);
}
static const struct snd_soc_dai_ops omap_hdmi_dai_ops = {
@@ -267,10 +268,14 @@ static const struct snd_soc_component_driver
omap_hdmi_component = {
static int omap_hdmi_probe(struct platform_device *pdev)
{
- int ret;
- struct resource *hdmi_rsrc;
+ struct asoc_omap_hdmi_dai_pdata *pdata = pdev->dev.platform_data;
struct hdmi_priv *hdmi_data;
- bool hdmi_dev_found = false;
+ int ret;
+
+ if (!pdata) {
+ dev_err(&pdev->dev, "No platform data, bailing out\n");
+ return -ENODEV;
+ }
hdmi_data = devm_kzalloc(&pdev->dev, sizeof(*hdmi_data), GFP_KERNEL);
if (hdmi_data == NULL) {
@@ -278,48 +283,12 @@ static int omap_hdmi_probe(struct platform_device *pdev)
return -ENOMEM;
}
- hdmi_rsrc = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!hdmi_rsrc) {
- dev_err(&pdev->dev, "Cannot obtain IORESOURCE_MEM HDMI\n");
- return -ENODEV;
- }
-
- hdmi_data->dma_data.addr = hdmi_rsrc->start + OMAP_HDMI_AUDIO_DMA_PORT;
-
- hdmi_rsrc = platform_get_resource(pdev, IORESOURCE_DMA, 0);
- if (!hdmi_rsrc) {
- dev_err(&pdev->dev, "Cannot obtain IORESOURCE_DMA HDMI\n");
- return -ENODEV;
- }
-
- hdmi_data->dma_req = hdmi_rsrc->start;
+ hdmi_data->dma_data.addr = pdata->dma_addr;
+ hdmi_data->dma_req = pdata->dma_req;
hdmi_data->dma_data.filter_data = &hdmi_data->dma_req;
hdmi_data->dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
- /*
-* 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) {
-
[PATCH 11/13] OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value
The OMAP5 HDMI audio implementation needs HDMI_AUDIO_LAYOUT_6CH in
hdmi_core_audio_layout enum. I found the correct value from ti-linux
3.8 tree.
Signed-off-by: Jyri Sarha
---
drivers/video/fbdev/omap2/dss/hdmi.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h
b/drivers/video/fbdev/omap2/dss/hdmi.h
index 3ddb5f8..c9efc92 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -159,7 +159,8 @@ enum hdmi_audio_blk_strt_end_sig {
enum hdmi_core_audio_layout {
HDMI_AUDIO_LAYOUT_2CH = 0,
- HDMI_AUDIO_LAYOUT_8CH = 1
+ HDMI_AUDIO_LAYOUT_8CH = 1,
+ HDMI_AUDIO_LAYOUT_6CH = 2
};
enum hdmi_core_cts_mode {
--
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 04/13] OMAPDSS: hdmi_wp: Add function for getting hdmi_wp physical base address
The hdmi_wp physical base address is needed for hdmi audio dma.
Signed-off-by: Jyri Sarha
---
drivers/video/fbdev/omap2/dss/hdmi.h|2 ++
drivers/video/fbdev/omap2/dss/hdmi_wp.c |6 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h
b/drivers/video/fbdev/omap2/dss/hdmi.h
index fbee078..f644bc8 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -341,6 +341,7 @@ struct hdmi_core_infoframe_avi {
struct hdmi_wp_data {
void __iomem *base;
+ phys_addr_t phys_base;
};
struct hdmi_pll_data {
@@ -410,6 +411,7 @@ void hdmi_wp_video_config_timing(struct hdmi_wp_data *wp,
void hdmi_wp_init_vid_fmt_timings(struct hdmi_video_format *video_fmt,
struct omap_video_timings *timings, struct hdmi_config *param);
int hdmi_wp_init(struct platform_device *pdev, struct hdmi_wp_data *wp);
+phys_addr_t hdmi_wp_get_phys_addr(struct hdmi_wp_data *wp);
/* HDMI PLL funcs */
int hdmi_pll_enable(struct hdmi_pll_data *pll, struct hdmi_wp_data *wp);
diff --git a/drivers/video/fbdev/omap2/dss/hdmi_wp.c
b/drivers/video/fbdev/omap2/dss/hdmi_wp.c
index a16a190..bee6df3 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi_wp.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi_wp.c
@@ -264,6 +264,7 @@ int hdmi_wp_init(struct platform_device *pdev, struct
hdmi_wp_data *wp)
temp_res.end = temp_res.start + WP_SIZE - 1;
res = &temp_res;
}
+ wp->phys_base = res->start;
wp->base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
if (!wp->base) {
@@ -273,3 +274,8 @@ int hdmi_wp_init(struct platform_device *pdev, struct
hdmi_wp_data *wp)
return 0;
}
+
+phys_addr_t hdmi_wp_get_phys_addr(struct hdmi_wp_data *wp)
+{
+ return wp->phys_base;
+}
--
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 07/13] ASoC: omap-hdmi-card: Add platform data stuct for omap-hdmi-card driver
The names of the needed ASoC component drivers need to be passed to
the omap-hdmi-card driver for it to find them.
Signed-off-by: Jyri Sarha
---
include/sound/omap-hdmi-card-pdata.h | 28
1 file changed, 28 insertions(+)
create mode 100644 include/sound/omap-hdmi-card-pdata.h
diff --git a/include/sound/omap-hdmi-card-pdata.h
b/include/sound/omap-hdmi-card-pdata.h
new file mode 100644
index 000..f70495b
--- /dev/null
+++ b/include/sound/omap-hdmi-card-pdata.h
@@ -0,0 +1,28 @@
+/*
+ * omap-hdmi-card-pdata.h
+ *
+ * Platform data for OMAP ALSA SoC card driver for HDMI audio on OMAP4+
+ * processors.
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ * Authors: Jyri Sarha
+ *
+ * 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.
+ *
+ */
+
+#ifndef __OMAP_HDMI_CARD_PDATA_H__
+#define __OMAP_HDMI_CARD_PDATA_H__
+
+struct asoc_omap_hdmi_card_pdata {
+ const char *cpudai_name;
+ const char *codec_name;
+};
+
+#endif
--
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 05/13] OMAPDSS: hdmi_audio: Add hdmi_audio.c for registering HDMI audio support
HDMI audio is implemented using ASoC component drivers. The drivers
were earlier registered from under mach-omap2 but that code had
problems with sharing the HDMI resources. This commit adds functions
for registering the ASoC drivers needed for HDMI audio from HDMI
driver itself.
Signed-off-by: Jyri Sarha
---
drivers/video/fbdev/omap2/dss/Makefile |2 +-
drivers/video/fbdev/omap2/dss/hdmi.h | 12
drivers/video/fbdev/omap2/dss/hdmi_audio.c | 92
3 files changed, 105 insertions(+), 1 deletion(-)
create mode 100644 drivers/video/fbdev/omap2/dss/hdmi_audio.c
diff --git a/drivers/video/fbdev/omap2/dss/Makefile
b/drivers/video/fbdev/omap2/dss/Makefile
index 390ab74..7ea2d7c 100644
--- a/drivers/video/fbdev/omap2/dss/Makefile
+++ b/drivers/video/fbdev/omap2/dss/Makefile
@@ -11,7 +11,7 @@ omapdss-$(CONFIG_OMAP2_DSS_VENC) += venc.o
omapdss-$(CONFIG_OMAP2_DSS_SDI) += sdi.o
omapdss-$(CONFIG_OMAP2_DSS_DSI) += dsi.o
omapdss-$(CONFIG_OMAP2_DSS_HDMI_COMMON) += hdmi_common.o hdmi_wp.o hdmi_pll.o \
- hdmi_phy.o
+ hdmi_phy.o hdmi_audio.o
omapdss-$(CONFIG_OMAP4_DSS_HDMI) += hdmi4.o hdmi4_core.o
omapdss-$(CONFIG_OMAP5_DSS_HDMI) += hdmi5.o hdmi5_core.o
ccflags-$(CONFIG_OMAP2_DSS_DEBUG) += -DDEBUG
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h
b/drivers/video/fbdev/omap2/dss/hdmi.h
index f644bc8..3ddb5f8 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -434,6 +434,18 @@ int hdmi_parse_lanes_of(struct platform_device *pdev,
struct device_node *ep,
struct hdmi_phy_data *phy);
#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) ||
defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
+struct hdmi_audio_data {
+ struct platform_device *cpudai_pdev;
+ struct platform_device *codec_pdev;
+ struct platform_device *card_pdev;
+};
+
+int hdmi_audio_register(struct platform_device *pdev,
+ struct hdmi_audio_data *data,
+ struct omap_dss_device *hdmi,
+ struct hdmi_wp_data *wp);
+void hdmi_audio_unregister(struct hdmi_audio_data *data);
+
int hdmi_compute_acr(u32 pclk, u32 sample_freq, u32 *n, u32 *cts);
int hdmi_wp_audio_enable(struct hdmi_wp_data *wp, bool enable);
int hdmi_wp_audio_core_req_enable(struct hdmi_wp_data *wp, bool enable);
diff --git a/drivers/video/fbdev/omap2/dss/hdmi_audio.c
b/drivers/video/fbdev/omap2/dss/hdmi_audio.c
new file mode 100644
index 000..2a485f7
--- /dev/null
+++ b/drivers/video/fbdev/omap2/dss/hdmi_audio.c
@@ -0,0 +1,92 @@
+/*
+ * OMAP4+ HDMI audio
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated
+ *
+ * Authors: Jyri Sarha
+ *
+ * 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.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "hdmi.h"
+
+static struct asoc_omap_hdmi_dai_pdata dai_pdata;
+struct asoc_omap_hdmi_card_pdata card_pdata;
+
+int hdmi_audio_register(struct platform_device *pdev,
+ struct hdmi_audio_data *data,
+ struct omap_dss_device *hdmi,
+ struct hdmi_wp_data *wp)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct device *dev = &pdev->dev;
+ struct dma_chan *dma_ch;
+ struct resource *res;
+
+ dai_pdata.dssdev = hdmi;
+ dai_pdata.dma_addr = hdmi_wp_get_phys_addr(wp) + HDMI_WP_AUDIO_DATA;
+
+ dma_ch = of_dma_request_slave_channel(np, "audio_tx");
+ if (IS_ERR(dma_ch)) {
+ dev_info(dev, "Could not get dma request channel from dts.\n");
+ /* Revert to hard coding. The DMA req channel is the
+ same on all supported hw. */
+ dai_pdata.dma_req = 76;
+ } else {
+ dai_pdata.dma_req = dma_ch->chan_id;
+ /* We only peeked the chan_id for pdata and let dai
+ driver take the DMA channel. */
+ dma_release_channel(dma_ch);
+ }
+
+ data->cpudai_pdev =
+ platform_device_register_data(dev, "omap-hdmi-audio-dai", 0,
+ &dai_pdata, sizeof(dai_pdata));
+ if (IS_ERR(data->cpudai_pdev))
+ return PTR_ERR(data->cpudai_pdev);
+
+ data->codec_pdev =
+ platform_device_register_data(dev, "hdmi-audio-codec",
+ 0, NULL, 0);
+ if (IS_ERR(data->codec_pdev)) {
+ platform_device_unregister(data->cpudai_pdev);
+ return PTR_ERR(data->code
[PATCH 12/13] OMAPDSS: hdmi5: Register HDMI audio ASoC drivers from HDMI driver
The registering is best done here to share the resources owned by OMAPDSS
HDMI driver with ASoC DAI and platform drivers.
Signed-off-by: Jyri Sarha
---
drivers/video/fbdev/omap2/dss/hdmi5.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi5.c
b/drivers/video/fbdev/omap2/dss/hdmi5.c
index c468b9e..1ba387b 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi5.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi5.c
@@ -57,6 +57,9 @@ static struct {
struct clk *sys_clk;
struct regulator *vdda_reg;
+#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
+ struct hdmi_audio_data audio;
+#endif
bool core_enabled;
struct omap_dss_device output;
@@ -761,6 +764,15 @@ static int omapdss_hdmihw_probe(struct platform_device
*pdev)
hdmi_init_output(pdev);
+#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
+ r = hdmi_audio_register(pdev, &hdmi.audio, &hdmi.output, &hdmi.wp);
+ if (r) {
+ DSSERR("Registering HDMI audio failed\n");
+ hdmi_uninit_output(pdev);
+ pm_runtime_disable(&pdev->dev);
+ return r;
+ }
+#endif
dss_debugfs_create_file("hdmi", hdmi_dump_regs);
return 0;
@@ -768,6 +780,9 @@ static int omapdss_hdmihw_probe(struct platform_device
*pdev)
static int __exit omapdss_hdmihw_remove(struct platform_device *pdev)
{
+#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
+ hdmi_audio_unregister(&hdmi.audio);
+#endif
hdmi_uninit_output(pdev);
pm_runtime_disable(&pdev->dev);
--
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 01/13] ARM: omap4.dtsi: Add audio related parametes to hdmi node
Adds HDMI audio sDMA properties. Signed-off-by: Jyri Sarha --- arch/arm/boot/dts/omap4.dtsi |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi index 649b5cd..335ed54 100644 --- a/arch/arm/boot/dts/omap4.dtsi +++ b/arch/arm/boot/dts/omap4.dtsi @@ -919,6 +919,8 @@ ti,hwmods = "dss_hdmi"; clocks = <&dss_48mhz_clk>, <&dss_sys_clk>; clock-names = "fck", "sys_clk"; + dmas = <&sdma 76>; + dma-names = "audio_tx"; }; }; }; -- 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 00/13] Fix OMAP4+ HDMI audio
This patch set fixes the resource sharing problems between omap-hdmi-dai driver and OMAPDSS HDMI driver. It does it by registering the OMAP HDMI audio related ASoC drivers from OMAPDSS HDMI driver. Platform data structs have been added for omap-hdmi-dai and omap-hdmi-card drivers to pass the information and resources from OMAPDSS HDMI driver. The idea of this patch set is to fix HDMI audio for the next release after it got broken by OMAPDSS DT changes. It does not mean that I have abandoned the patch set that integrates the omap-hdmi-dai driver into OMAPDSS HDMI driver. The OMAPDSS side of those patches just had some dependencies to the recent ASoC side patches that would have caused problems in the next merge. I'll mail a revised and rebased version of those patches soon. Best regards, Jyri Jyri Sarha (13): ARM: omap4.dtsi: Add audio related parametes to hdmi node ARM: omap5.dtsi: Add audio related parameters to hdmi node ARM: OMAP2+: Remove non working OMAP HDMI audio initialization OMAPDSS: hdmi_wp: Add function for getting hdmi_wp physical base address OMAPDSS: hdmi_audio: Add hdmi_audio.c for registering HDMI audio support ASoC: omap-hdmi-dai: Add platform data struct for omap-hdmi-dai driver ASoC: omap-hdmi-card: Add platform data stuct for omap-hdmi-card driver ASoC: omap-hdmi: Changes for registeing the driver from OMAPDSS ASoC: omap-hdmi-card: Changes for registeing the driver from OMAPDSS OMAPDSS: hdmi4: Register HDMI audio ASoC drivers from HDMI driver OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value OMAPDSS: hdmi5: Register HDMI audio ASoC drivers from HDMI driver ASoC: omap: Add Kconfig option for OMAP5 HDMI audio arch/arm/boot/dts/omap4.dtsi |2 + arch/arm/boot/dts/omap5.dtsi |2 + arch/arm/mach-omap2/devices.c | 28 - drivers/video/fbdev/omap2/dss/Makefile |2 +- drivers/video/fbdev/omap2/dss/hdmi.h | 17 - drivers/video/fbdev/omap2/dss/hdmi4.c | 15 + drivers/video/fbdev/omap2/dss/hdmi5.c | 15 + drivers/video/fbdev/omap2/dss/hdmi_audio.c | 92 drivers/video/fbdev/omap2/dss/hdmi_wp.c|6 ++ include/sound/omap-hdmi-card-pdata.h | 28 + include/sound/omap-hdmi-dai-pdata.h| 31 ++ sound/soc/omap/Kconfig | 13 +++- sound/soc/omap/omap-hdmi-card.c| 20 -- sound/soc/omap/omap-hdmi.c | 65 +--- 14 files changed, 253 insertions(+), 83 deletions(-) create mode 100644 drivers/video/fbdev/omap2/dss/hdmi_audio.c create mode 100644 include/sound/omap-hdmi-card-pdata.h create mode 100644 include/sound/omap-hdmi-dai-pdata.h -- 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 03/13] ARM: OMAP2+: Remove non working OMAP HDMI audio initialization
This code is not working currently and it can be removed. There is a
conflict in sharing resources with the actual HDMI driver and with
the ASoC HDMI audio DAI driver.
Signed-off-by: Jyri Sarha
---
arch/arm/mach-omap2/devices.c | 28
1 file changed, 28 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index e58609b..4bab682 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -330,33 +330,6 @@ static void omap_init_audio(void)
static inline void omap_init_audio(void) {}
#endif
-#if defined(CONFIG_SND_OMAP_SOC_OMAP_HDMI) || \
- defined(CONFIG_SND_OMAP_SOC_OMAP_HDMI_MODULE)
-
-static struct platform_device omap_hdmi_audio = {
- .name = "omap-hdmi-audio",
- .id = -1,
-};
-
-static void __init omap_init_hdmi_audio(void)
-{
- struct omap_hwmod *oh;
- struct platform_device *pdev;
-
- oh = omap_hwmod_lookup("dss_hdmi");
- if (!oh)
- return;
-
- pdev = omap_device_build("omap-hdmi-audio-dai", -1, oh, NULL, 0);
- WARN(IS_ERR(pdev),
-"Can't build omap_device for omap-hdmi-audio-dai.\n");
-
- platform_device_register(&omap_hdmi_audio);
-}
-#else
-static inline void omap_init_hdmi_audio(void) {}
-#endif
-
#if defined(CONFIG_SPI_OMAP24XX) || defined(CONFIG_SPI_OMAP24XX_MODULE)
#include
@@ -492,7 +465,6 @@ static int __init omap2_init_devices(void)
*/
omap_init_audio();
omap_init_camera();
- omap_init_hdmi_audio();
omap_init_mbox();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt()) {
--
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] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled
* Tony Lindgren [140523 07:45]:
> * Tobias Jakobi [140519 14:19]:
> >
> > But even if I don't connect via WiFi at all, just boot and let me system
> > run with serial console connected, after some time I get a kernel 'WARNING':
> > http://www.math.uni-bielefeld.de/~tjakobi/archive/dmesg.1.log
>
> BTW, care to update the bugzilla page with the second warning
> in this log?
>
> That's the WARNING: CPU: 1 PID: 0 at kernel/timer.c:1147 that's
> at 238 seconds.
Also, with Santosh's fix applied, can you also try disabling one
or more of the idle states for cpuidle and see if that helps?
Something like this patch below. If that helps with the WARNING
above you're getting it narrows down the problem down quite a bit.
Regards,
Tony
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -44,11 +44,13 @@ static struct idle_statedata omap4_idle_data[] = {
.mpu_state = PWRDM_POWER_RET,
.mpu_logic_state = PWRDM_POWER_RET,
},
+#if 0
{
.cpu_state = PWRDM_POWER_OFF,
.mpu_state = PWRDM_POWER_RET,
.mpu_logic_state = PWRDM_POWER_OFF,
},
+#endif
};
static struct powerdomain *mpu_pd, *cpu_pd[MAX_CPUS];
--
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 v13 3/7] mmc: omap_hsmmc: Extend debugfs by SDIO IRQ handling, runtime state
* Balaji T K [140523 05:27]:
> On Friday 23 May 2014 02:00 PM, Andreas Fenkart wrote:
> >Add SDIO IRQ entries to debugfs entry. Note that PSTATE shows current
> >state of data lines, incl. SDIO IRQ pending
> >
> >Acked-by: Balaji T K
> >Signed-off-by: Andreas Fenkart
> >
> >diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> >index 0125eea..cfd2bfb 100644
> >--- a/drivers/mmc/host/omap_hsmmc.c
> >+++ b/drivers/mmc/host/omap_hsmmc.c
> >@@ -56,6 +56,7 @@
> > #define OMAP_HSMMC_RSP54 0x0118
> > #define OMAP_HSMMC_RSP76 0x011C
> > #define OMAP_HSMMC_DATA0x0120
> >+#define OMAP_HSMMC_PSTATE 0x0124
> > #define OMAP_HSMMC_HCTL0x0128
> > #define OMAP_HSMMC_SYSCTL 0x012C
> > #define OMAP_HSMMC_STAT0x0130
> >@@ -1816,10 +1817,23 @@ static int omap_hsmmc_regs_show(struct seq_file *s,
> >void *data)
> > {
> > struct mmc_host *mmc = s->private;
> > struct omap_hsmmc_host *host = mmc_priv(mmc);
> >+#ifdef CONFIG_PM
> >+bool suspended;
> >+#endif
> >
> > seq_printf(s, "mmc%d:\n", mmc->index);
> >+seq_printf(s, "sdio irq mode\t%s\n",
> >+ (mmc->caps & MMC_CAP_SDIO_IRQ) ? "interrupt" : "polling");
> >+
> >+if (mmc->caps & MMC_CAP_SDIO_IRQ) {
> >+seq_printf(s, "sdio irq \t%s\n",
> >+ (host->flags & HSMMC_SDIO_IRQ_ENABLED) ? "enabled"
> >+ : "disabled");
> >+}
> >
> > #ifdef CONFIG_PM
>
> shouldn't this be CONFIG_PM_RUNTIME ?
>
> >+suspended = host->dev->power.runtime_status != RPM_ACTIVE;
> >+seq_printf(s, "runtime state\t%s\n", (suspended ? "idle" : "active"));
>
> The whole check for runtime status (and check for CONFIG_PM..) can be removed,
> since runtime status is available via sysfs
>
> cat /sys/class/mmc_host/mmc/device/power/runtime_status
>
> > seq_printf(s, "ctx_loss:\t%d\n", host->context_loss);
> > #endif
Also CONFIG_SYSFS is a bool FYI.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Accessing GPIOs from userspace using recent kernels
* Linus Walleij [140523 04:36]: > On Fri, May 16, 2014 at 12:15 PM, Peter TB Brett wrote: > > The current call chain seems to be: gpiod_export() --> gpiod_request() --> > > omap_gpio_request(). Looking at other GPIO drivers, it seems like > > omap_gpio_request() should eventually call pinctrl_request_gpio(). Would be > > useful if someone who knows about OMAP4/gpio/pinctrl could take a look at > > this. If we do this, we also need a solution to prevent automatic remuxing of GPIO pins from happending. For wake-up events, some drivers need to remux a rx pin to GPIO input for the duration of idle, and then back to device rx pin. This is needed on some other platforms too AFAIK. For the drivers needing GPIO wake-up events, request_gpio is done in the driver after drivers/base/pinctrl.c has already muxed the device pin to rx. At minimum we would get warnings about reserved pins if we tried to automatically mux them to GPIO. We may be able to use some GPIO specific property to prevent automatic remuxing as we discussed in the #armlinux few days ago. Related to automatic remuxing of GPIO pins, there are also other needs for pinctrl and GPIO interaction. We need to remux GPIO output pins to input + pull + safe_mode to prevent the GPIO pins losing value briefly during off-idle. That's the gpio errata 1.158 at as shown at least at [1]. Because the GPIO to pinctrl mapping is sparse and SoC specific, there's currently now obvious way to do that. And we would need few new GPIO functions to tell pinctrl subsystem about the change. Regards, Tony [1] https://www.gitorious.org/rowboat/kernel/commit/86b15f21298b749a9d8216ff1839d33ad542464e?format=patch -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 00/16] OMAP: GPMC: Restructure OMAP GPMC driver (NAND) : DT binding change proposal
* Roger Quadros [140523 01:17]: > On 05/22/2014 05:46 PM, Ezequiel Garcia wrote: > > On 22 May 01:51 PM, Javier Martinez Canillas wrote: > >> On Thu, May 22, 2014 at 10:12 AM, Roger Quadros wrote: > On 21 May 02:20 PM, Roger Quadros wrote: > While I agree that the GPMC driver is a bit messy, I'm not sure it's > possible > to go through such a complete devicetree binding re-design (breaking > backwards > compatibility) now that the binding is already in production. > >>> > >>> Why not? especially if the existing bindings are poorly dones. Is anyone > >>> using these > >>> bindings burning the DT into ROM and can't change it when they update the > >>> kernel? > >>> > >> > >> While I do agree that your DT bindings are much better than the > >> current ones, there is a policy that DT bindings are an external API > >> and once are released with a kernel are set in stone and can't be > >> changed. > >> > > > > Exactly. The DT binding is considered an ABI. Thus, invariant across kernel > > versions. Users can't be coherced into a DTB update after a kernel update. > > > > That said, I don't really care if you break compatilibity in this case. > > Rather, I'm suggesting that you make sure this change is going to be > > accepted > > upstream, before doing any more work. The DT maintainers are reluctant to do > > so. > > Appreciate your concern. > > Would be really nice if you can review patches 1-12. They have nothing to do > with DT changes. > Thanks. I'm mostly concerned about keeping things working. I think the only way we can keep things working is to keep support for the old binding around in addition to the new one. That way we can update devices one at a time. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] Rework OMAP4+ HDMI audio support
* Tomi Valkeinen [140523 04:03]: > On 12/05/14 18:06, Tony Lindgren wrote: > > * Jyri Sarha [140512 02:13]: > >> Since RFC version of the patch set: > >> - Split callbacks removal patch away from "Integrated ASoC DAI > >> component driver implementation" patches for easier reading > >> > >> This set of patches fixes OMAP4+ HDMI audio. The structure of the > >> implementatin looks a bit different than before. Instead of creating a > >> driver specific API for a separate ASoC component driver to connect > >> to, this implementation integrates an the component driver into the > >> HDMI driver. > >> > >> The idea is to use an existing ASoC component driver API instead of > >> creating a new custom API for each HDMI IP and to avoid splitting the > >> driver to half for separate video and audio parts connected with the > >> API. > >> > >> The new implementation also uses simple-audio-card for a machine > >> driver instead of having its own HW specific machine driver. > > > > Can you guys please post this split into the following separate > > parts for the maintainers to merge: > > > > - ASoC changes > > - DSS changes > > - DTS changes > > > > And once those are all in, please post the defconfig changes. > > Tony, this series will get delayed until 3.17, but I'd like to merge the > HDMI DMA channel changes to omap4/omap5.dtsi already to 3.16. They are > patches 13 and 15. > > Those are very trivial, but I'd rather have acks from you for all the > .dts changes I'll be sending. OK fine with me: Acked-by: Tony Lindgren -- 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 2/3] ARM: dts: oma3-gta04: Add display support
* Tomi Valkeinen [140523 01:21]: > On 08/05/14 23:16, Marek Belisko wrote: > > This patch add support for lcd display on gta04 board. Display control > > is connected to spi (used spi bitbang driver). > > > > Signed-off-by: Marek Belisko > > --- > > arch/arm/boot/dts/omap3-gta04.dts | 87 > > +++ > > 1 file changed, 87 insertions(+) > > I can take this via my tree. > > Tony, can I have your ack on this? Yes for the whole series: Acked-by: Tony Lindgren -- 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: OMAP4: Fix the boot regression with CPU_IDLE enabled
* Tobias Jakobi [140519 14:19]: > > But even if I don't connect via WiFi at all, just boot and let me system > run with serial console connected, after some time I get a kernel 'WARNING': > http://www.math.uni-bielefeld.de/~tjakobi/archive/dmesg.1.log BTW, care to update the bugzilla page with the second warning in this log? That's the WARNING: CPU: 1 PID: 0 at kernel/timer.c:1147 that's at 238 seconds. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/3] ARM: dts: overo: Add panel support
* Tomi Valkeinen [140523 01:19]: > On 23/05/14 10:09, Florian Vaussard wrote: > > Hi Tomi, > > > > On 05/20/2014 03:58 PM, Florian Vaussard wrote: > >> Hi, > >> > >> This series enables the DVI and LCD panels present on some of > >> the Overo expansion boards. > >> > > > > Do you have any more comments on these? If no, do you want to pull them > > through your tree for 3.16, as discussed with Tony? > > Yes, I can take these. > > Tony, do I have your ack on this series? Yes please go ahead and queue these: Acked-by: Tony Lindgren -- 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 v13 7/7] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x
On Friday 23 May 2014 02:00 PM, Andreas Fenkart wrote:
The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected with the GPIO, the GPIO will only wake
the module from suspend, SDIO irq detection will still happen through the
IP block.
Idea of remuxing the pins by Tony Lindgren. Code contributions from
Tony Lindgren and Balaji T K
Acked-by: Balaji T K
Signed-off-by: Andreas Fenkart
Signed-off-by: Tony Lindgren
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 0233ba7..76bf087 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -57,3 +57,56 @@ Examples:
&edma 25>;
dma-names = "tx", "rx";
};
+
+[workaround for missing swakeup on am33xx]
+
+This SOC is missing the swakeup line, it will not detect SDIO irq
+while in suspend.
+
+ --
+ | PRCM |
+ --
+ ^ |
+ swakeup | | fclk
+ | v
+ ----- -
+ | card | -- CIRQ --> | hsmmc | -- IRQ --> | CPU |
+ ----- -
+
+In suspend the fclk is off and the module is disfunctional. Even register reads
+will fail. A small logic in the host will request fclk restore, when an
+external event is detected. Once the clock is restored, the host detects the
+event normally. Since am33xx doesn't have this line it never wakes from
+suspend.
+
+The workaround is to reconfigure the dat1 line as a GPIO upon suspend. To make
+this work, we need to set the named pinctrl states "default" and "idle".
+Prepare idle to remux dat1 as a gpio, and default to remux it back as sdio
+dat1. The MMC driver will then toggle between idle and default state during
+runtime.
+
+In summary:
+1. select matching 'compatible' section, see example below.
+2. specify pinctrl states "default" and "idle", "sleep" is optional.
+3. specify the gpio irq used for detecting sdio irq in suspend
+
+If configuration is incomplete, a warning message is emitted "falling back to
+polling". Also check the "sdio irq mode" in /sys/kernel/debug/mmc0/regs. Mind
+not every application needs SDIO irq, e.g. MMC cards.
+
+ mmc1: mmc@48060100 {
+ compatible = "ti,am33xx-hsmmc";
+ ...
+ pinctrl-names = "default", "idle", "sleep"
+ pinctrl-0 = <&mmc1_pins>;
+ pinctrl-1 = <&mmc1_idle>;
+ pinctrl-2 = <&mmc1_sleep>;
+ ...
+ interrupts-extended = <&intc 64 &gpio2 28 0>;
+ };
+
+ mmc1_idle : pinmux_cirq_pin {
+ pinctrl-single,pins = <
+ 0x0f8 0x3f /* GPIO2_28 */
+ >;
+ };
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 760b0ac..1238506 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1752,15 +1752,25 @@ static int omap_hsmmc_configure_wake_irq(struct
omap_hsmmc_host *host)
* and need to remux SDIO DAT1 to GPIO for wake-up from idle.
*/
if (host->pdata->controller_flags & OMAP_HSMMC_SWAKEUP_MISSING) {
- ret = -ENODEV;
- devm_free_irq(host->dev, host->wake_irq, host);
- goto err;
+ if (IS_ERR(host->dev->pins->default_state)) {
Rater than introducing #ifdef CONFIG_PM on multiple places,
I think things will simple, if pinctrl_lookup_state is used here
to avoid build error on !CONFIG_PM
+ dev_info(host->dev, "missing default pinctrl state\n");
+ ret = -EINVAL;
+ goto err_free_irq;
+ }
+
+ if (IS_ERR(host->dev->pins->idle_state)) {
same here.
+ dev_info(host->dev, "missing idle pinctrl state\n");
+ ret = -EINVAL;
+ goto err_free_irq;
+ }
}
OMAP_HSMMC_WRITE(host->base, HCTL,
OMAP_HSMMC_READ(host->base, HCTL) | IWE);
return 0;
+err_free_irq:
+ devm_free_irq(host->dev, host->wake_irq, host);
err:
dev_warn(host->dev, "no SDIO IRQ support, falling back to polling\n");
host->wake_irq = 0;
--
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 v13 3/7] mmc: omap_hsmmc: Extend debugfs by SDIO IRQ handling, runtime state
On Friday 23 May 2014 02:00 PM, Andreas Fenkart wrote:
Add SDIO IRQ entries to debugfs entry. Note that PSTATE shows current
state of data lines, incl. SDIO IRQ pending
Acked-by: Balaji T K
Signed-off-by: Andreas Fenkart
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 0125eea..cfd2bfb 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -56,6 +56,7 @@
#define OMAP_HSMMC_RSP54 0x0118
#define OMAP_HSMMC_RSP76 0x011C
#define OMAP_HSMMC_DATA 0x0120
+#define OMAP_HSMMC_PSTATE 0x0124
#define OMAP_HSMMC_HCTL 0x0128
#define OMAP_HSMMC_SYSCTL 0x012C
#define OMAP_HSMMC_STAT 0x0130
@@ -1816,10 +1817,23 @@ static int omap_hsmmc_regs_show(struct seq_file *s,
void *data)
{
struct mmc_host *mmc = s->private;
struct omap_hsmmc_host *host = mmc_priv(mmc);
+#ifdef CONFIG_PM
+ bool suspended;
+#endif
seq_printf(s, "mmc%d:\n", mmc->index);
+ seq_printf(s, "sdio irq mode\t%s\n",
+ (mmc->caps & MMC_CAP_SDIO_IRQ) ? "interrupt" : "polling");
+
+ if (mmc->caps & MMC_CAP_SDIO_IRQ) {
+ seq_printf(s, "sdio irq \t%s\n",
+ (host->flags & HSMMC_SDIO_IRQ_ENABLED) ? "enabled"
+ : "disabled");
+ }
#ifdef CONFIG_PM
shouldn't this be CONFIG_PM_RUNTIME ?
+ suspended = host->dev->power.runtime_status != RPM_ACTIVE;
+ seq_printf(s, "runtime state\t%s\n", (suspended ? "idle" : "active"));
The whole check for runtime status (and check for CONFIG_PM..) can be removed,
since runtime status is available via sysfs
cat /sys/class/mmc_host/mmc/device/power/runtime_status
seq_printf(s, "ctx_loss:\t%d\n", host->context_loss);
#endif
@@ -1827,6 +1841,8 @@ static int omap_hsmmc_regs_show(struct seq_file *s, void
*data)
seq_puts(s, "\nregs:\n");
seq_printf(s, "CON:\t\t0x%08x\n",
OMAP_HSMMC_READ(host->base, CON));
+ seq_printf(s, "PSTATE:\t\t0x%08x\n",
+ OMAP_HSMMC_READ(host->base, PSTATE));
seq_printf(s, "HCTL:\t\t0x%08x\n",
OMAP_HSMMC_READ(host->base, HCTL));
seq_printf(s, "SYSCTL:\t\t0x%08x\n",
--
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 v13 1/7] mmc: omap_hsmmc: install dummy pm runtime hooks if !CONFIG_PM_RUNTIME
2014-05-23 12:16 GMT+02:00 Balaji T K :
> On Friday 23 May 2014 02:00 PM, Andreas Fenkart wrote:
>>
>>
>> +#ifdef CONFIG_PM_RUNTIME
>
>
> AFAIK, omap_hsmmc can build without these changes,
> So, I think this patch is not needed.
>
> Let me I know If it is not the case.
if do not guard suspend/resume then I have to add guards in patch 1/7:
> @@ -2200,11 +2346,18 @@ static int omap_hsmmc_suspend(struct device *dev)
> pm_runtime_get_sync(host->dev);
>
> if (!(host->mmc->pm_flags & MMC_PM_KEEP_POWER)) {
> - omap_hsmmc_disable_irq(host);
> + OMAP_HSMMC_WRITE(host->base, ISE, 0);
> + OMAP_HSMMC_WRITE(host->base, IE, 0);
> + OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
> OMAP_HSMMC_WRITE(host->base, HCTL,
> OMAP_HSMMC_READ(host->base, HCTL) & ~SDBP);
> }
>
> + /* do not wake up due to sdio irq */
> + if ((host->mmc->caps & MMC_CAP_SDIO_IRQ) &&
> + !(host->mmc->pm_flags & MMC_PM_WAKE_SDIO_IRQ))
> + disable_irq(host->wake_irq);
here
> +
> if (host->dbclk)
> clk_disable_unprepare(host->dbclk);
>
> @@ -2230,6 +2383,10 @@ static int omap_hsmmc_resume(struct device *dev)
>
> omap_hsmmc_protect_card(host);
>
> + if ((host->mmc->caps & MMC_CAP_SDIO_IRQ) &&
> + !(host->mmc->pm_flags & MMC_PM_WAKE_SDIO_IRQ))
> + enable_irq(host->wake_irq);
> +
> pm_runtime_mark_last_busy(host->dev);
> pm_runtime_put_autosuspend(host->dev);
> return 0;
> @@ -2246,22 +2403,51 @@ static int omap_hsmmc_resume(struct device *dev)
> static int omap_hsmmc_runtime_suspend(struct device *dev)
> {
> struct omap_hsmmc_host *host;
> + unsigned long flags;
>
> host = platform_get_drvdata(to_platform_device(dev));
> omap_hsmmc_context_save(host);
> dev_dbg(dev, "disabled\n");
>
> + spin_lock_irqsave(&host->irq_lock, flags);
> + if ((host->mmc->caps & MMC_CAP_SDIO_IRQ) &&
> + (host->flags & HSMMC_SDIO_IRQ_ENABLED)) {
> + /* disable sdio irq handling to prevent race */
> + OMAP_HSMMC_WRITE(host->base, ISE, 0);
> + OMAP_HSMMC_WRITE(host->base, IE, 0);
> + OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
> +
> + WARN_ON(host->flags & HSMMC_WAKE_IRQ_ENABLED);
> + enable_irq(host->wake_irq);
and here
> + host->flags |= HSMMC_WAKE_IRQ_ENABLED;
> + }
> + spin_unlock_irqrestore(&host->irq_lock, flags);
> return 0;
> }
>
--
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: Accessing GPIOs from userspace using recent kernels
Hi Peter, I think you have already understood from the rest of the conversation that pin control configuration shall be done in the device tree and not from userspace, which is a good start. As shown by Javier many things people sometimes do in userspace should rather be done in kernelspace, such as controlling LEDs and reading pushbuttons etc. On Fri, May 16, 2014 at 12:15 PM, Peter TB Brett wrote: > On 2014-05-15 19:54, Javier Martinez Canillas wrote: >> 0x5e (PIN_INPUT_PULLUP | MUX_MODE0) /* hdmi_sda.hdmi_sda */ >> 0x12e (PIN_OUTPUT | MUX_MODE5) /* dispc2_data15 */ > > Yes, that's my mistake. I took the pin control register addresses from the > OMAP4 documentation and forgot that you have to subtract 0x40 to get the > correct address for use in the device tree. > > The correct snippet has 0x1e and 0xee. I find the pinctrl-single hexdigit syntax infinitely complex and confusing, but it was chosen by its designers. Most drivers use strings to configure muxing and biasing etc. >> Is what you shared your real change or just an example that does not >> apply to the Pandaboard? Could you please share your complete DTS? > > > The attached .dts file sort of works-ish. It's an ugly hack, but I don't > have the time to do any more investigation into this now, unfortunately. > > I guess my main question is: if I use /sys/class/gpio/export to export a > GPIO for userspace control, Which you should avoid, if possible. > it would make sense for the kernel to try and > ensure that the GPIO is actually connected to something! How should we do that? The physics of that request evades me. The pin control subsystem will however refuse to use the pin if it is used for something else. > The current call chain seems to be: gpiod_export() --> gpiod_request() --> > omap_gpio_request(). Looking at other GPIO drivers, it seems like > omap_gpio_request() should eventually call pinctrl_request_gpio(). Would be > useful if someone who knows about OMAP4/gpio/pinctrl could take a look at > this. That is Tony Lindgren and the linux-omap mailing list. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] ARM: OMAP5+: Support Duty Cycle Correction(DCC)
On 05/16/2014 01:45 PM, Nishanth Menon wrote: Hi, This patch series has been carried over in vendor kernel for quiet few years now. Unfortunately, it was very recently re-discovered and upstream kernel is noticed to be broken for OMAP5 1.5GHz - at least we are operating DPLL at frequency higher than what it was intended to be when CPUFreq is enabled. Thankfully, with nominal voltage(we dont use AVS yet in upstream for the mentioned platforms) and margins in trimming, we have so far not crashed - but I strongly suspect this might be some boundary case survival. Verified on the following impacted platforms using 3.15-rc4 based vendor kernel. Before: OMAP5432: http://slexy.org/view/s20cs0qQFg DRA72x: http://slexy.org/view/s2TXtSa6mH (refused to lock) DRA75x: http://slexy.org/view/s20AW8MU5c After: OMAP5432: http://slexy.org/view/s21iAfWxpu DRA72x: http://slexy.org/view/s2hwsvGLmC (locks properly) DRA75x: http://slexy.org/view/s21ehw8WQn Hopefully, we can get these into some kernel revision in some form. Thanks, queued for 3.16/ti-clk-drv. Anybody on the delivery feel free to yell if you got any complaints. -Tero NOTE: Support for 4470(which is the only other platform requiring DCC) is not present in upstream kernel and there are no plans to support that SoC, even if it is added at a later point, support can be extended as needed. Series based on v3.15-rc5 tag. Also available on my tree: https://github.com/nmenon/linux-2.6-playground/ branch: push/clock/dcc weblink: https://github.com/nmenon/linux-2.6-playground/commits/push/clock/dcc Verification: 3.15-rc4 based kernel - DRA75x-evm, 72x-evm, OMAP5uevm 3.15-rc5 - OMAP5uEVM(only one supporting 1.5GHz atm) Andrii Tseglytskyi (1): ARM: OMAP5+: dpll: support Duty Cycle Correction(DCC) Nishanth Menon (2): clk: dpll: support OMAP5 MPU DPLL that need special handling for higher frequencies ARM: dts: OMAP5/DRA7: use omap5-mpu-dpll-clock capable of dealing with higher frequencies .../devicetree/bindings/clock/ti/dpll.txt |1 + arch/arm/boot/dts/dra7xx-clocks.dtsi |2 +- arch/arm/boot/dts/omap54xx-clocks.dtsi |2 +- arch/arm/mach-omap2/dpll3xxx.c |9 + drivers/clk/ti/dpll.c | 21 include/linux/clk/ti.h |4 6 files changed, 37 insertions(+), 2 deletions(-) Regards, Nishanth Menon -- 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 3/4] mfd: tps65917: Add driver for the TPS65917 PMIC
> >>The TPS65917 chip is a power management IC for Portable Navigation > >>Systems > >>and Tablet Computing devices. It contains the following components: > >> > >> - Regulators. > >> - Over Temperature warning and Shut down. > >> > >>This patch adds support for tps65917 mfd device. At this time only > >>the regulator functionality is made available. > >> > >>Signed-off-by: Keerthy > >>--- > >>v3 Changes: > >> > >> * Header file formating > >> * Changed the cache_type to REGCACHE_RBTREE > >> * removed unnecessary code > >> * Corrected documentation style > >> * Added pm_power_off function > >> > >> v2 Changes: > >> > >> * Added volatile register check as some of the registers > >>in the set are volatile. > >>drivers/mfd/Kconfig | 12 + > >> drivers/mfd/Makefile |1 + > >> drivers/mfd/tps65917.c | 594 + > >> include/linux/mfd/tps65917.h | 1485 > >> ++ > >> 4 files changed, 2092 insertions(+) > >> create mode 100644 drivers/mfd/tps65917.c > >> create mode 100644 include/linux/mfd/tps65917.h > >[...] > > > >>+ ret = regmap_read(tps65917->regmap[slave], addr, ®); > >>+ if (ret) > >>+ goto err_irq; > >>+ }i > >What does the read do? You're not doing anything with the value. > This pad1 and pad2 stuff is not needed. I will remove this. > >>>Then why is it in here? > >>> > >>>Did you copy this code from somewhere, if so, where? > >>> > >>>Okay, I just answered my own question. There is so much common code > >>>in between this and palmas, there is no way I'm going to accept this > >>>driver. Please merge it in with the palmas driver! > >>> > >>The chip is more like a subset of palmas with lot of register offset changes > >>and register bit field changes. Adding this would make it clumsy. > >>There could > >>be lot of checks. That is why i chose to write a new driver. > >> > >>Palmas driver already supports palmas variants and tps659038. Merging > >>this would mean more and more checks :-/. > >Then find an elegant way of representing the variants. I'm not > >prepared to carry that much duplicated code in MFD. It's already > >overladened and in need of an overhaul. This will exacerbate the > >matter. > > > > Okay. I am working on that. Thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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: dts: AM4372: clk: efuse based crystal frequency detect
On 05/14/2014 02:36 PM, Sekhar Nori wrote:
From: Afzal Mohammed
Currently oscillator frequency is determined based on sysboot settings,
it may not be the case always. To determine it properly, efuse settings
also has to be read. CONTROL_STATUS register holds this information.
Bit 31: if 0, frequency to be determined based on sysboot
if 1, frequency to be determined based on efuse
Bit 29,30 - for efuse detection of frequency
Bit 22,23 - for sysboot detection of frequency
Add clock nodes (mux) to determine oscillator frequency as above.
Signed-off-by: Afzal Mohammed
Acked-by: Tero Kristo
Signed-off-by: Sekhar Nori
Thanks, queued for 3.16.
-Tero
---
arch/arm/boot/dts/am43xx-clocks.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..71b029c 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -11,6 +11,22 @@
sys_clkin_ck: sys_clkin_ck {
#clock-cells = <0>;
compatible = "ti,mux-clock";
+ clocks = <&sysboot_freq_sel_ck>, <&crystal_freq_sel_ck>;
+ ti,bit-shift = <31>;
+ reg = <0x0040>;
+ };
+
+ crystal_freq_sel_ck: crystal_freq_sel_ck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&virt_1920_ck>, <&virt_2400_ck>, <&virt_2500_ck>,
<&virt_2600_ck>;
+ ti,bit-shift = <29>;
+ reg = <0x0040>;
+ };
+
+ sysboot_freq_sel_ck: sysboot_freq_sel_ck@44e10040 {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
clocks = <&virt_1920_ck>, <&virt_2400_ck>, <&virt_2500_ck>,
<&virt_2600_ck>;
ti,bit-shift = <22>;
reg = <0x0040>;
--
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/19] Rework OMAP4+ HDMI audio support
On 12/05/14 18:06, Tony Lindgren wrote: > * Jyri Sarha [140512 02:13]: >> Since RFC version of the patch set: >> - Split callbacks removal patch away from "Integrated ASoC DAI >> component driver implementation" patches for easier reading >> >> This set of patches fixes OMAP4+ HDMI audio. The structure of the >> implementatin looks a bit different than before. Instead of creating a >> driver specific API for a separate ASoC component driver to connect >> to, this implementation integrates an the component driver into the >> HDMI driver. >> >> The idea is to use an existing ASoC component driver API instead of >> creating a new custom API for each HDMI IP and to avoid splitting the >> driver to half for separate video and audio parts connected with the >> API. >> >> The new implementation also uses simple-audio-card for a machine >> driver instead of having its own HW specific machine driver. > > Can you guys please post this split into the following separate > parts for the maintainers to merge: > > - ASoC changes > - DSS changes > - DTS changes > > And once those are all in, please post the defconfig changes. Tony, this series will get delayed until 3.17, but I'd like to merge the HDMI DMA channel changes to omap4/omap5.dtsi already to 3.16. They are patches 13 and 15. Those are very trivial, but I'd rather have acks from you for all the .dts changes I'll be sending. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 3/4] mfd: tps65917: Add driver for the TPS65917 PMIC
On Friday 23 May 2014 03:36 PM, Lee Jones wrote: The TPS65917 chip is a power management IC for Portable Navigation Systems and Tablet Computing devices. It contains the following components: - Regulators. - Over Temperature warning and Shut down. This patch adds support for tps65917 mfd device. At this time only the regulator functionality is made available. Signed-off-by: Keerthy --- v3 Changes: * Header file formating * Changed the cache_type to REGCACHE_RBTREE * removed unnecessary code * Corrected documentation style * Added pm_power_off function v2 Changes: * Added volatile register check as some of the registers in the set are volatile. drivers/mfd/Kconfig | 12 + drivers/mfd/Makefile |1 + drivers/mfd/tps65917.c | 594 + include/linux/mfd/tps65917.h | 1485 ++ 4 files changed, 2092 insertions(+) create mode 100644 drivers/mfd/tps65917.c create mode 100644 include/linux/mfd/tps65917.h [...] + ret = regmap_read(tps65917->regmap[slave], addr, ®); + if (ret) + goto err_irq; + }i What does the read do? You're not doing anything with the value. This pad1 and pad2 stuff is not needed. I will remove this. Then why is it in here? Did you copy this code from somewhere, if so, where? Okay, I just answered my own question. There is so much common code in between this and palmas, there is no way I'm going to accept this driver. Please merge it in with the palmas driver! The chip is more like a subset of palmas with lot of register offset changes and register bit field changes. Adding this would make it clumsy. There could be lot of checks. That is why i chose to write a new driver. Palmas driver already supports palmas variants and tps659038. Merging this would mean more and more checks :-/. Then find an elegant way of representing the variants. I'm not prepared to carry that much duplicated code in MFD. It's already overladened and in need of an overhaul. This will exacerbate the matter. Okay. I am working on that. Regards, Keerthy -- 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/omap4: add twd clock to DT
On 05/20/2014 05:49 PM, Tony Lindgren wrote: * Tero Kristo [140520 02:01]: On 05/19/2014 07:27 PM, Tony Lindgren wrote: * Joachim Eastwood [140519 09:24]: On 19 May 2014 18:13, Tony Lindgren wrote: * Joachim Eastwood [140518 05:08]: On 22 April 2014 14:39, Tero Kristo wrote: On 04/20/2014 07:22 PM, Gilles Chanteperdrix wrote: Le 19/04/2014 00:39, Tony Lindgren a écrit : * Gilles Chanteperdrix [140407 13:09]: Booting Linux 3.14 on Pandaboard currently gets the following message displayed: smp_twd: clock not found -2 Define "mpu_periphclk" as the twd clock in omap4 dts to avoid this. Tero, care to ack? Sorry if I did not mail the right people, get_maintainer.pl gave me a long list, and I did not feel like spamming all these people for such a small patch. I do not believe Tero was in this list. Regards. Yea I don't think this is my expertise area, however the patch looks good to me, so if you really need it: Acked-by: Tero Kristo Tony, care to add this to your omap 3.16 dt branch? I am still getting: [ 0.000152] smp_twd: clock not found -2 So this fix from Gilles would be nice to have. Best that Tero picks this one up along with the other dt clock changes he's queueing. I kinda assumed you would take it since you asked Tero to ack it. But either way is fine :) Yes that was before Tero started collecting the dt clock patches :) I wouldn't say this to be a clock patch as such, this touches the driver behavior, i.e. registers the correct clock for the driver. That being said, I can still queue this up with the clock patches if that is what you want. Yes please go ahead and take this one. Thanks, Tony Ok, thanks, queued for 3.16. -Tero -- 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 v13 1/7] mmc: omap_hsmmc: install dummy pm runtime hooks if !CONFIG_PM_RUNTIME
On Friday 23 May 2014 02:00 PM, Andreas Fenkart wrote:
Signed-off-by: Andreas Fenkart
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 272e0ee..c62d9dd 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -199,7 +199,9 @@ struct omap_hsmmc_host {
struct dma_chan *rx_chan;
int slot_id;
int response_busy;
+#ifdef CONFIG_PM
int context_loss;
+#endif
int protect_card;
int reqs_blocked;
int use_reg;
@@ -712,14 +714,8 @@ static void omap_hsmmc_context_save(struct omap_hsmmc_host
*host)
#else
-static int omap_hsmmc_context_restore(struct omap_hsmmc_host *host)
-{
- return 0;
-}
-
-static void omap_hsmmc_context_save(struct omap_hsmmc_host *host)
-{
-}
+#define omap_hsmmc_context_restore(host)
+#define omap_hsmmc_context_save(host)
#endif
@@ -1700,11 +1696,14 @@ static int omap_hsmmc_regs_show(struct seq_file *s,
void *data)
struct mmc_host *mmc = s->private;
struct omap_hsmmc_host *host = mmc_priv(mmc);
- seq_printf(s, "mmc%d:\n ctx_loss:\t%d\n\nregs:\n",
- mmc->index, host->context_loss);
+ seq_printf(s, "mmc%d:\n", mmc->index);
- pm_runtime_get_sync(host->dev);
+#ifdef CONFIG_PM
+ seq_printf(s, "ctx_loss:\t%d\n", host->context_loss);
+#endif
+ pm_runtime_get_sync(host->dev);
+ seq_puts(s, "\nregs:\n");
seq_printf(s, "CON:\t\t0x%08x\n",
OMAP_HSMMC_READ(host->base, CON));
seq_printf(s, "HCTL:\t\t0x%08x\n",
@@ -2243,6 +2242,7 @@ static int omap_hsmmc_resume(struct device *dev)
#define omap_hsmmc_resume NULL
#endif
+#ifdef CONFIG_PM_RUNTIME
AFAIK, omap_hsmmc can build without these changes,
So, I think this patch is not needed.
Let me I know If it is not the case.
static int omap_hsmmc_runtime_suspend(struct device *dev)
{
struct omap_hsmmc_host *host;
@@ -2264,6 +2264,10 @@ static int omap_hsmmc_runtime_resume(struct device *dev)
return 0;
}
+#else
+#define omap_hsmmc_runtime_suspend NULL
+#define omap_hsmmc_runtime_resume NULL
+#endif
static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
.suspend= omap_hsmmc_suspend,
--
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 3/4] mfd: tps65917: Add driver for the TPS65917 PMIC
> The TPS65917 chip is a power management IC for Portable Navigation Systems > and Tablet Computing devices. It contains the following components: > > - Regulators. > - Over Temperature warning and Shut down. > > This patch adds support for tps65917 mfd device. At this time only > the regulator functionality is made available. > > Signed-off-by: Keerthy > --- > v3 Changes: > > * Header file formating > * Changed the cache_type to REGCACHE_RBTREE > * removed unnecessary code > * Corrected documentation style > * Added pm_power_off function > > v2 Changes: > > * Added volatile register check as some of the registers > in the set are volatile. > drivers/mfd/Kconfig | 12 + > drivers/mfd/Makefile |1 + > drivers/mfd/tps65917.c | 594 + > include/linux/mfd/tps65917.h | 1485 > ++ > 4 files changed, 2092 insertions(+) > create mode 100644 drivers/mfd/tps65917.c > create mode 100644 include/linux/mfd/tps65917.h [...] > + ret = regmap_read(tps65917->regmap[slave], addr, ®); > + if (ret) > + goto err_irq; > + }i > >>>What does the read do? You're not doing anything with the value. > >>This pad1 and pad2 stuff is not needed. I will remove this. > >Then why is it in here? > > > >Did you copy this code from somewhere, if so, where? > > > >Okay, I just answered my own question. There is so much common code > >in between this and palmas, there is no way I'm going to accept this > >driver. Please merge it in with the palmas driver! > > > The chip is more like a subset of palmas with lot of register offset changes > and register bit field changes. Adding this would make it clumsy. > There could > be lot of checks. That is why i chose to write a new driver. > > Palmas driver already supports palmas variants and tps659038. Merging > this would mean more and more checks :-/. Then find an elegant way of representing the variants. I'm not prepared to carry that much duplicated code in MFD. It's already overladened and in need of an overhaul. This will exacerbate the matter. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 00/16] OMAP: GPMC: Restructure OMAP GPMC driver (NAND) : DT binding change proposal
Hello Roger,
On Fri, May 23, 2014 at 10:16 AM, Roger Quadros wrote:
> Ezequiel & Javier,
>
> On 05/22/2014 05:46 PM, Ezequiel Garcia wrote:
>> On 22 May 01:51 PM, Javier Martinez Canillas wrote:
>>> On Thu, May 22, 2014 at 10:12 AM, Roger Quadros wrote:
> On 21 May 02:20 PM, Roger Quadros wrote:
>>
>> For DT boot:
>> - The GPMC controller node should have a chip select (CS) node for each
>> used
>> chip select. The CS node must have a child device node for each device
>> attached to that chip select. Properties for that child are GPMC
>> agnostic.
>>
>> i.e.
>> gpmc {
>> cs0 {
>> nand0 {
>> }
>> };
>>
>> cs1 {
>> nor0 {
>> }
>> }
>> ...
>> };
>>
>
> While I agree that the GPMC driver is a bit messy, I'm not sure it's
> possible
> to go through such a complete devicetree binding re-design (breaking
> backwards
> compatibility) now that the binding is already in production.
Why not? especially if the existing bindings are poorly dones. Is anyone
using these
bindings burning the DT into ROM and can't change it when they update the
kernel?
>>>
>>> While I do agree that your DT bindings are much better than the
>>> current ones, there is a policy that DT bindings are an external API
>>> and once are released with a kernel are set in stone and can't be
>>> changed.
>>>
>>
>> Exactly. The DT binding is considered an ABI. Thus, invariant across kernel
>> versions. Users can't be coherced into a DTB update after a kernel update.
>>
>> That said, I don't really care if you break compatilibity in this case.
>> Rather, I'm suggesting that you make sure this change is going to be accepted
>> upstream, before doing any more work. The DT maintainers are reluctant to do
>> so.
>
> Appreciate your concern.
>
> Would be really nice if you can review patches 1-12. They have nothing to do
> with DT changes.
> Thanks.
>
Overall your patches looks good to me. But I think it's better to wait
until Tony removes the legacy board files for OMAP2+ since AFAIU at
least the following patches could be dropped or trimmed down when
board files are gone:
[RFC PATCH 04/16] ARM: OMAP2+: gpmc: use platform data to configure CS
space and poplulate
[RFC PATCH 06/16] ARM: OMAP2+: gpmc: add NAND specific setup
[RFC PATCH 07/16] ARM: OMAP2+: nand: Update gpmc_nand_init() to use
generic_gpmc_init()
Patches 1-3 and 5 are independent and can be applied in the meantime
as a preparation for further changes following board files removal.
I really like patches 9-12 since those moves some NAND add-hoc code to
the NAND driver where it really belongs. I think that similar changes
can be made for OneNAND and push the special case handling code from
GPMC driver to drivers/mtd/onenand/omap2.c.
Other devices (nor, ethernet, uart, etc) are already using
gpmc_probe_generic_child() so I hope we can isolate the NAND and
OneNAND specific changes and just use a single probe function for all
child devices and possibly get even need the enum gpmc_omap_type you
are adding on your struct gpmc_omap_cs_data.
So what do you think if as a first step we add the platform data as
you propose with all the commons timings and settings there, move all
the possible code to NAND and OneNAND drivers and try to use a single
configuration function for all child devices?
Then once board files are gone we can do further cleanup in the driver
and then we can discuss about changing the DT bindings. Maybe we can
even change it while keeping backwards compatibility? Although I'm not
sure about the last point I think that at least is worth to discuss
it.
> cheers,
> -roger
>
Thanks a lot and best regards,
Javier
>>
>> On the other side, I guess you will also break bisectability while breaking
>> backward compatibility. Doesn't sound very nice.
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: omap5-clocks.dtsi: add ti,set-rate-parent to dss_dss_clk
On 05/21/2014 03:16 PM, Tomi Valkeinen wrote:
Add ti,set-rate-parent to dss_dss_clk so that the DSS driver can
set the rate.
Signed-off-by: Tomi Valkeinen
Both patches queued for 3.16, thanks.
-Tero
---
arch/arm/boot/dts/omap54xx-clocks.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi
b/arch/arm/boot/dts/omap54xx-clocks.dtsi
index d487fdab3921..d44bdaa8fe68 100644
--- a/arch/arm/boot/dts/omap54xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi
@@ -851,6 +851,7 @@
clocks = <&dpll_per_h12x2_ck>;
ti,bit-shift = <8>;
reg = <0x1420>;
+ ti,set-rate-parent;
};
dss_sys_clk: dss_sys_clk {
--
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 v13 6/7] mmc: omap_hsmmc: switch default/idle pinctrl states in runtime hooks
These are predefined states of the driver model. When not present,
as if not set in the device tree, they become no-ops.
Explicitly selecting the default state is not needed since the
device core layer sets pin mux to "default" state before probe.
This is not the simplest implementation, on AM335x at least, we could
switch to idle at any point in the suspend hook, only the default state
needs to be set before writing to the irq registers or an IRQ might get
lost.
Acked-by: Balaji T K
Signed-off-by: Andreas Fenkart
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index aafef29..760b0ac 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2008,7 +2008,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
const struct of_device_id *match;
dma_cap_mask_t mask;
unsigned tx_req, rx_req;
- struct pinctrl *pinctrl;
const struct omap_mmc_of_data *data;
match = of_match_device(of_match_ptr(omap_mmc_of_match), &pdev->dev);
@@ -2234,11 +2233,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
omap_hsmmc_disable_irq(host);
- pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(pinctrl))
- dev_warn(&pdev->dev,
- "pins are not configured from the driver\n");
-
/*
* For now, only support SDIO interrupt if we have a separate
* wake-up interrupt configured from device tree. This is because
@@ -2463,10 +2457,15 @@ static int omap_hsmmc_runtime_suspend(struct device
*dev)
goto abort;
}
+ pinctrl_pm_select_idle_state(dev);
+
WARN_ON(host->flags & HSMMC_WAKE_IRQ_ENABLED);
enable_irq(host->wake_irq);
host->flags |= HSMMC_WAKE_IRQ_ENABLED;
+ } else {
+ pinctrl_pm_select_idle_state(dev);
}
+
abort:
spin_unlock_irqrestore(&host->irq_lock, flags);
return ret;
@@ -2490,9 +2489,14 @@ static int omap_hsmmc_runtime_resume(struct device *dev)
host->flags &= ~HSMMC_WAKE_IRQ_ENABLED;
}
+ pinctrl_pm_select_default_state(host->dev);
+
+ /* irq lost, if pinmux incorrect */
OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host->base, ISE, CIRQ_EN);
OMAP_HSMMC_WRITE(host->base, IE, CIRQ_EN);
+ } else {
+ pinctrl_pm_select_default_state(host->dev);
}
spin_unlock_irqrestore(&host->irq_lock, flags);
return 0;
--
1.7.10.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 v13 1/7] mmc: omap_hsmmc: install dummy pm runtime hooks if !CONFIG_PM_RUNTIME
Signed-off-by: Andreas Fenkart
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 272e0ee..c62d9dd 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -199,7 +199,9 @@ struct omap_hsmmc_host {
struct dma_chan *rx_chan;
int slot_id;
int response_busy;
+#ifdef CONFIG_PM
int context_loss;
+#endif
int protect_card;
int reqs_blocked;
int use_reg;
@@ -712,14 +714,8 @@ static void omap_hsmmc_context_save(struct omap_hsmmc_host
*host)
#else
-static int omap_hsmmc_context_restore(struct omap_hsmmc_host *host)
-{
- return 0;
-}
-
-static void omap_hsmmc_context_save(struct omap_hsmmc_host *host)
-{
-}
+#define omap_hsmmc_context_restore(host)
+#define omap_hsmmc_context_save(host)
#endif
@@ -1700,11 +1696,14 @@ static int omap_hsmmc_regs_show(struct seq_file *s,
void *data)
struct mmc_host *mmc = s->private;
struct omap_hsmmc_host *host = mmc_priv(mmc);
- seq_printf(s, "mmc%d:\n ctx_loss:\t%d\n\nregs:\n",
- mmc->index, host->context_loss);
+ seq_printf(s, "mmc%d:\n", mmc->index);
- pm_runtime_get_sync(host->dev);
+#ifdef CONFIG_PM
+ seq_printf(s, "ctx_loss:\t%d\n", host->context_loss);
+#endif
+ pm_runtime_get_sync(host->dev);
+ seq_puts(s, "\nregs:\n");
seq_printf(s, "CON:\t\t0x%08x\n",
OMAP_HSMMC_READ(host->base, CON));
seq_printf(s, "HCTL:\t\t0x%08x\n",
@@ -2243,6 +2242,7 @@ static int omap_hsmmc_resume(struct device *dev)
#define omap_hsmmc_resume NULL
#endif
+#ifdef CONFIG_PM_RUNTIME
static int omap_hsmmc_runtime_suspend(struct device *dev)
{
struct omap_hsmmc_host *host;
@@ -2264,6 +2264,10 @@ static int omap_hsmmc_runtime_resume(struct device *dev)
return 0;
}
+#else
+#define omap_hsmmc_runtime_suspend NULL
+#define omap_hsmmc_runtime_resume NULL
+#endif
static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
.suspend= omap_hsmmc_suspend,
--
1.7.10.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 v13 2/7] mmc: omap_hsmmc: Enable SDIO interrupt
There have been various patches floating around for enabling
the SDIO IRQ for hsmmc, but none of them ever got merged.
Probably the reason for not merging the SDIO interrupt patches
has been the lack of wake-up path for SDIO on some omaps that
has also needed remuxing the SDIO DAT1 line to a GPIO making
the patches complex.
This patch adds the minimal SDIO IRQ support to hsmmc for
omaps that do have the wake-up path. For those omaps, the
DAT1 line need to have the wake-up enable bit set, and the
wake-up interrupt is the same as for the MMC controller.
This patch has been tested on am3730 es1.2 with mwifiex
connected to MMC3 with mwifiex waking to Ethernet traffic
from off-idle mode. Note that for omaps that do not have
the SDIO wake-up path, this patch will not work for idle
modes and further patches for remuxing DAT1 to GPIO are
needed.
Based on earlier patches [1][2] by David Vrabel
, Steve Sakoman
For now, only support SDIO interrupt if we are booted with
a separate wake-irq configued via device tree. This is
because omaps need the wake-irq for idle states, and some
omaps need special quirks. And we don't want to add new
legacy mux platform init code callbacks any longer as we
are moving to DT based booting anyways.
To use it, you need to specify the wake-irq using the
interrupts-extended property.
[1]
http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux.git;a=commitdiff_plain;h=010810d22f6f49ac03da4ba384969432e0320453
[2] http://comments.gmane.org/gmane.linux.kernel.mmc/20446
Acked-by: Balaji T K
Signed-off-by: Andreas Fenkart
Signed-off-by: Tony Lindgren
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index ce80561..0233ba7 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -12,6 +12,7 @@ Required properties:
Should be "ti,omap3-hsmmc", for OMAP3 controllers
Should be "ti,omap3-pre-es3-hsmmc" for OMAP3 controllers pre ES3.0
Should be "ti,omap4-hsmmc", for OMAP4 controllers
+ Should be "ti,am33xx-hsmmc", for AM335x controllers
- ti,hwmods: Must be "mmc", n is controller instance starting 1
Optional properties:
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index c62d9dd..0125eea 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -36,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -106,6 +108,7 @@
#define TC_EN (1 << 1)
#define BWR_EN (1 << 4)
#define BRR_EN (1 << 5)
+#define CIRQ_EN(1 << 8)
#define ERR_EN (1 << 15)
#define CTO_EN (1 << 16)
#define CCRC_EN(1 << 17)
@@ -140,7 +143,6 @@
#define VDD_3V0300 /* 30 uV */
#define VDD_165_195(ffs(MMC_VDD_165_195) - 1)
-#define AUTO_CMD23 (1 << 1)/* Auto CMD23 support */
/*
* One controller can have multiple slots, like on some omap boards using
* omap.c controller driver. Luckily this is not currently done on any known
@@ -200,6 +202,7 @@ struct omap_hsmmc_host {
int slot_id;
int response_busy;
#ifdef CONFIG_PM
+ int wake_irq;
int context_loss;
#endif
int protect_card;
@@ -208,6 +211,9 @@ struct omap_hsmmc_host {
int req_in_progress;
unsigned long clk_rate;
unsigned intflags;
+#define AUTO_CMD23 (1 << 0)/* Auto CMD23 support */
+#define HSMMC_SDIO_IRQ_ENABLED (1 << 1)/* SDIO irq enabled */
+#define HSMMC_WAKE_IRQ_ENABLED (1 << 2)
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
};
@@ -512,27 +518,40 @@ static void omap_hsmmc_stop_clock(struct omap_hsmmc_host
*host)
static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
struct mmc_command *cmd)
{
- unsigned int irq_mask;
+ u32 irq_mask = INT_EN_MASK;
+ unsigned long flags;
if (host->use_dma)
- irq_mask = INT_EN_MASK & ~(BRR_EN | BWR_EN);
- else
- irq_mask = INT_EN_MASK;
+ irq_mask &= ~(BRR_EN | BWR_EN);
/* Disable timeout for erases */
if (cmd->opcode == MMC_ERASE)
irq_mask &= ~DTO_EN;
+ spin_lock_irqsave(&host->irq_lock, flags);
OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host->base, ISE, irq_mask);
+
+ /* latch pending CIRQ, but don't signal MMC core */
+ if (host->flags & HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
OMA
[PATCH v13 0/7] mmc: omap_hsmmc: Enable SDIO IRQ
Hi Balaji, Tony, Ulf, all
v13
- fix compile breaks if !CONFIG_PM
- additional patch: install dummy pm runtime hooks if !CONFIG_PM_RUNTIME
v12
- drop !CONFIG_OF compile break only exists when
#undef CONFIG_OF after include headers 1/7(Sebastian Reichel)
- do not emit "falling back to polling" if wake_irq not specified
since MMC does not need it, and it might confuse users
only emit if pinmux default/idle is not present or claiming
the irq failed 2/7(Balaji)
- dropped out-of-tree patches 6/7(Balaji)
- mention "ti,am33xx-hsmmc" compatible section in bindings
documentation 1/5
v11
- split !CONFIG_OF compile break into separate patch
- enable IWE/CLKEXTFREE in CON/HCTL register needed for omap4
- '&' vs '&&' in omap_hsmmc_resume, 1/5 (Andreas Müller)
- #define DLEV_DAT instead of BIT(21) 2/5 (Balaji)
- pinctrl_pm_select_default_state() removed, 4/5 (Balaji)
- drop _irqsave/_irqrestore from omap_hsmmc_wake_irq handler since it
can't be preempted by same priority omap_hsmmc_irq handler 1/5(Joel Fernandes)
- replace devres_open_group by explicit devm_free calls 1/5 (Balaji)
- disable_irq_nosync wake_irq since we handle it thread safe 1/5 (Balaji)
- drop 'gpio_dat1' pinctrl states and rework documentation 5/5 (Balaji)
v10
- bug fix on multi-core, untested
- incorporated changes from Balaji
- use devres / RAII mechanism to configure wake_up /
sdio irq capabilities
- drop pinctrl state 'active'
rely on driver-model states 'default', 'idle'
- add specific 'gpio_dat1' state for am335x SWAKEUP hack
- reorganized patches; +1 patch multi-core bugfix / +1 for pinctrl
- rebased 455c6fdbd21916 / cherry-picks from mmc-next
v9
- extended comment about why wake-irq is needed
- drop double '(' ')' around card_detect_irq
- drop final '.' in in subject line of patch
v8
- rebased on top of Tony Lindgren changes
- improved changelog describing the earlier work
- improved wakeup irq setup
- works for am3730 es platform now
- my changes on top:
- compile tested with #undef CONFIG_OF
- disable wake_irq in handler to prevent infinite loop
- fixed typo and added comment about wake-irq
v7
- rebase on 3.14.0-rc3-49726-g77e15ec
- split omap_hsmmc_pin_init due to regression on omap-3730 platform
v6
- rebase on Linux 3.13-rc3
- reformatting debugfs
v5
- fix compile error introduced by last minute one line fix
v4:
- switch to interrupts-extended format
- drop ti,swakeup-missing flag convert to comaptible section
v3:
- removed gpio_irq from platform_data
v2:
- incorparated changes as suggested by reviewers
- simplified workaround for am335x, gpio will now only wake
the module from runtime suspend, not handle the sdio irq
itself
Andreas Fenkart (7):
mmc: omap_hsmmc: install dummy pm runtime hooks if !CONFIG_PM_RUNTIME
mmc: omap_hsmmc: Enable SDIO interrupt
mmc: omap_hsmmc: Extend debugfs by SDIO IRQ handling, runtime state
mmc: omap_hsmmc: enable wakeup event for sdio OMAP4
mmc: omap_hsmmc: abort runtime suspend if pending sdio irq detected
mmc: omap_hsmmc: switch default/idle pinctrl states in runtime hooks
mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on
AM335x
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 54
drivers/mmc/host/omap_hsmmc.c | 309 ++--
include/linux/platform_data/mmc-omap.h |1 +
3 files changed, 335 insertions(+), 29 deletions(-)
--
1.7.10.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 v13 4/7] mmc: omap_hsmmc: enable wakeup event for sdio OMAP4
To detect sdio irqs properly without spurious events,
OMAP4 needs IWE in CON and CTPL, CLKEXTFREE in HCTL to be set
Tested-by: Andreas Fenkart
Signed-off-by: Balaji T K
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index cfd2bfb..dfc593e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -94,7 +94,10 @@
#define BCE(1 << 1)
#define FOUR_BIT (1 << 1)
#define HSPE (1 << 2)
+#define IWE(1 << 24)
#define DDR(1 << 19)
+#define CLKEXTFREE (1 << 16)
+#define CTPL (1 << 11)
#define DW8(1 << 5)
#define OD 0x1
#define STAT_CLEAR 0x
@@ -689,6 +692,9 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
capa = VS18;
}
+ if (host->mmc->caps & MMC_CAP_SDIO_IRQ)
+ hctl |= IWE;
+
OMAP_HSMMC_WRITE(host->base, HCTL,
OMAP_HSMMC_READ(host->base, HCTL) | hctl);
@@ -1681,19 +1687,23 @@ static void omap_hsmmc_init_card(struct mmc_host *mmc,
struct mmc_card *card)
static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
{
struct omap_hsmmc_host *host = mmc_priv(mmc);
- u32 irq_mask;
+ u32 irq_mask, con;
unsigned long flags;
spin_lock_irqsave(&host->irq_lock, flags);
+ con = OMAP_HSMMC_READ(host->base, CON);
irq_mask = OMAP_HSMMC_READ(host->base, ISE);
if (enable) {
host->flags |= HSMMC_SDIO_IRQ_ENABLED;
irq_mask |= CIRQ_EN;
+ con |= CTPL | CLKEXTFREE;
} else {
host->flags &= ~HSMMC_SDIO_IRQ_ENABLED;
irq_mask &= ~CIRQ_EN;
+ con &= ~(CTPL | CLKEXTFREE);
}
+ OMAP_HSMMC_WRITE(host->base, CON, con);
OMAP_HSMMC_WRITE(host->base, IE, irq_mask);
/*
@@ -1744,6 +1754,8 @@ static int omap_hsmmc_configure_wake_irq(struct
omap_hsmmc_host *host)
goto err;
}
+ OMAP_HSMMC_WRITE(host->base, HCTL,
+OMAP_HSMMC_READ(host->base, HCTL) | IWE);
return 0;
err:
--
1.7.10.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 v13 7/7] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x
The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected with the GPIO, the GPIO will only wake
the module from suspend, SDIO irq detection will still happen through the
IP block.
Idea of remuxing the pins by Tony Lindgren. Code contributions from
Tony Lindgren and Balaji T K
Acked-by: Balaji T K
Signed-off-by: Andreas Fenkart
Signed-off-by: Tony Lindgren
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 0233ba7..76bf087 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -57,3 +57,56 @@ Examples:
&edma 25>;
dma-names = "tx", "rx";
};
+
+[workaround for missing swakeup on am33xx]
+
+This SOC is missing the swakeup line, it will not detect SDIO irq
+while in suspend.
+
+ --
+ | PRCM |
+ --
+ ^ |
+ swakeup | | fclk
+ | v
+ ----- -
+ | card | -- CIRQ --> | hsmmc | -- IRQ --> | CPU |
+ ----- -
+
+In suspend the fclk is off and the module is disfunctional. Even register reads
+will fail. A small logic in the host will request fclk restore, when an
+external event is detected. Once the clock is restored, the host detects the
+event normally. Since am33xx doesn't have this line it never wakes from
+suspend.
+
+The workaround is to reconfigure the dat1 line as a GPIO upon suspend. To make
+this work, we need to set the named pinctrl states "default" and "idle".
+Prepare idle to remux dat1 as a gpio, and default to remux it back as sdio
+dat1. The MMC driver will then toggle between idle and default state during
+runtime.
+
+In summary:
+1. select matching 'compatible' section, see example below.
+2. specify pinctrl states "default" and "idle", "sleep" is optional.
+3. specify the gpio irq used for detecting sdio irq in suspend
+
+If configuration is incomplete, a warning message is emitted "falling back to
+polling". Also check the "sdio irq mode" in /sys/kernel/debug/mmc0/regs. Mind
+not every application needs SDIO irq, e.g. MMC cards.
+
+ mmc1: mmc@48060100 {
+ compatible = "ti,am33xx-hsmmc";
+ ...
+ pinctrl-names = "default", "idle", "sleep"
+ pinctrl-0 = <&mmc1_pins>;
+ pinctrl-1 = <&mmc1_idle>;
+ pinctrl-2 = <&mmc1_sleep>;
+ ...
+ interrupts-extended = <&intc 64 &gpio2 28 0>;
+ };
+
+ mmc1_idle : pinmux_cirq_pin {
+ pinctrl-single,pins = <
+ 0x0f8 0x3f /* GPIO2_28 */
+ >;
+ };
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 760b0ac..1238506 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1752,15 +1752,25 @@ static int omap_hsmmc_configure_wake_irq(struct
omap_hsmmc_host *host)
* and need to remux SDIO DAT1 to GPIO for wake-up from idle.
*/
if (host->pdata->controller_flags & OMAP_HSMMC_SWAKEUP_MISSING) {
- ret = -ENODEV;
- devm_free_irq(host->dev, host->wake_irq, host);
- goto err;
+ if (IS_ERR(host->dev->pins->default_state)) {
+ dev_info(host->dev, "missing default pinctrl state\n");
+ ret = -EINVAL;
+ goto err_free_irq;
+ }
+
+ if (IS_ERR(host->dev->pins->idle_state)) {
+ dev_info(host->dev, "missing idle pinctrl state\n");
+ ret = -EINVAL;
+ goto err_free_irq;
+ }
}
OMAP_HSMMC_WRITE(host->base, HCTL,
OMAP_HSMMC_READ(host->base, HCTL) | IWE);
return 0;
+err_free_irq:
+ devm_free_irq(host->dev, host->wake_irq, host);
err:
dev_warn(host->dev, "no SDIO IRQ support, falling back to polling\n");
host->wake_irq = 0;
--
1.7.10.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 v13 5/7] mmc: omap_hsmmc: abort runtime suspend if pending sdio irq detected
On multicores, an sdio irq handler could be running in parallel to
runtime suspend. In the worst case it could be waiting for the spinlock
held by the runtime suspend. When runtime suspend is complete and the
functional clock (fclk) turned off, the irq handler will continue and
cause a SIGBUS on the first register access.
Acked-by: Balaji T K
Signed-off-by: Andreas Fenkart
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index dfc593e..aafef29 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -107,6 +107,9 @@
#define SRD(1 << 26)
#define SOFTRESET (1 << 1)
+/* PSTATE */
+#define DLEV_DAT(x)(1 << (20 + (x)))
+
/* Interrupt masks for IE and ISE register */
#define CC_EN (1 << 0)
#define TC_EN (1 << 1)
@@ -2432,6 +2435,7 @@ static int omap_hsmmc_runtime_suspend(struct device *dev)
{
struct omap_hsmmc_host *host;
unsigned long flags;
+ int ret = 0;
host = platform_get_drvdata(to_platform_device(dev));
omap_hsmmc_context_save(host);
@@ -2443,14 +2447,29 @@ static int omap_hsmmc_runtime_suspend(struct device
*dev)
/* disable sdio irq handling to prevent race */
OMAP_HSMMC_WRITE(host->base, ISE, 0);
OMAP_HSMMC_WRITE(host->base, IE, 0);
- OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
+
+ if (!(OMAP_HSMMC_READ(host->base, PSTATE) & DLEV_DAT(1))) {
+ /*
+* dat1 line low, pending sdio irq
+* race condition: possible irq handler running on
+* multi-core, abort
+*/
+ dev_dbg(dev, "pending sdio irq, abort suspend\n");
+ OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
+ OMAP_HSMMC_WRITE(host->base, ISE, CIRQ_EN);
+ OMAP_HSMMC_WRITE(host->base, IE, CIRQ_EN);
+ pm_runtime_mark_last_busy(dev);
+ ret = -EBUSY;
+ goto abort;
+ }
WARN_ON(host->flags & HSMMC_WAKE_IRQ_ENABLED);
enable_irq(host->wake_irq);
host->flags |= HSMMC_WAKE_IRQ_ENABLED;
}
+abort:
spin_unlock_irqrestore(&host->irq_lock, flags);
- return 0;
+ return ret;
}
static int omap_hsmmc_runtime_resume(struct device *dev)
--
1.7.10.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 v13 3/7] mmc: omap_hsmmc: Extend debugfs by SDIO IRQ handling, runtime state
Add SDIO IRQ entries to debugfs entry. Note that PSTATE shows current
state of data lines, incl. SDIO IRQ pending
Acked-by: Balaji T K
Signed-off-by: Andreas Fenkart
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 0125eea..cfd2bfb 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -56,6 +56,7 @@
#define OMAP_HSMMC_RSP54 0x0118
#define OMAP_HSMMC_RSP76 0x011C
#define OMAP_HSMMC_DATA0x0120
+#define OMAP_HSMMC_PSTATE 0x0124
#define OMAP_HSMMC_HCTL0x0128
#define OMAP_HSMMC_SYSCTL 0x012C
#define OMAP_HSMMC_STAT0x0130
@@ -1816,10 +1817,23 @@ static int omap_hsmmc_regs_show(struct seq_file *s,
void *data)
{
struct mmc_host *mmc = s->private;
struct omap_hsmmc_host *host = mmc_priv(mmc);
+#ifdef CONFIG_PM
+ bool suspended;
+#endif
seq_printf(s, "mmc%d:\n", mmc->index);
+ seq_printf(s, "sdio irq mode\t%s\n",
+ (mmc->caps & MMC_CAP_SDIO_IRQ) ? "interrupt" : "polling");
+
+ if (mmc->caps & MMC_CAP_SDIO_IRQ) {
+ seq_printf(s, "sdio irq \t%s\n",
+ (host->flags & HSMMC_SDIO_IRQ_ENABLED) ? "enabled"
+ : "disabled");
+ }
#ifdef CONFIG_PM
+ suspended = host->dev->power.runtime_status != RPM_ACTIVE;
+ seq_printf(s, "runtime state\t%s\n", (suspended ? "idle" : "active"));
seq_printf(s, "ctx_loss:\t%d\n", host->context_loss);
#endif
@@ -1827,6 +1841,8 @@ static int omap_hsmmc_regs_show(struct seq_file *s, void
*data)
seq_puts(s, "\nregs:\n");
seq_printf(s, "CON:\t\t0x%08x\n",
OMAP_HSMMC_READ(host->base, CON));
+ seq_printf(s, "PSTATE:\t\t0x%08x\n",
+ OMAP_HSMMC_READ(host->base, PSTATE));
seq_printf(s, "HCTL:\t\t0x%08x\n",
OMAP_HSMMC_READ(host->base, HCTL));
seq_printf(s, "SYSCTL:\t\t0x%08x\n",
--
1.7.10.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 v3 2/3] ARM: dts: oma3-gta04: Add display support
On 08/05/14 23:16, Marek Belisko wrote: > This patch add support for lcd display on gta04 board. Display control > is connected to spi (used spi bitbang driver). > > Signed-off-by: Marek Belisko > --- > arch/arm/boot/dts/omap3-gta04.dts | 87 > +++ > 1 file changed, 87 insertions(+) I can take this via my tree. Tony, can I have your ack on this? Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 0/3] ARM: dts: overo: Add panel support
On 23/05/14 10:09, Florian Vaussard wrote: > Hi Tomi, > > On 05/20/2014 03:58 PM, Florian Vaussard wrote: >> Hi, >> >> This series enables the DVI and LCD panels present on some of >> the Overo expansion boards. >> > > Do you have any more comments on these? If no, do you want to pull them > through your tree for 3.16, as discussed with Tony? Yes, I can take these. Tony, do I have your ack on this series? Tomi signature.asc Description: OpenPGP digital signature
Re: [RFC PATCH 00/16] OMAP: GPMC: Restructure OMAP GPMC driver (NAND) : DT binding change proposal
Ezequiel & Javier,
On 05/22/2014 05:46 PM, Ezequiel Garcia wrote:
> On 22 May 01:51 PM, Javier Martinez Canillas wrote:
>> On Thu, May 22, 2014 at 10:12 AM, Roger Quadros wrote:
On 21 May 02:20 PM, Roger Quadros wrote:
>
> For DT boot:
> - The GPMC controller node should have a chip select (CS) node for each
> used
> chip select. The CS node must have a child device node for each device
> attached to that chip select. Properties for that child are GPMC
> agnostic.
>
> i.e.
> gpmc {
> cs0 {
> nand0 {
> }
> };
>
> cs1 {
> nor0 {
> }
> }
> ...
> };
>
While I agree that the GPMC driver is a bit messy, I'm not sure it's
possible
to go through such a complete devicetree binding re-design (breaking
backwards
compatibility) now that the binding is already in production.
>>>
>>> Why not? especially if the existing bindings are poorly dones. Is anyone
>>> using these
>>> bindings burning the DT into ROM and can't change it when they update the
>>> kernel?
>>>
>>
>> While I do agree that your DT bindings are much better than the
>> current ones, there is a policy that DT bindings are an external API
>> and once are released with a kernel are set in stone and can't be
>> changed.
>>
>
> Exactly. The DT binding is considered an ABI. Thus, invariant across kernel
> versions. Users can't be coherced into a DTB update after a kernel update.
>
> That said, I don't really care if you break compatilibity in this case.
> Rather, I'm suggesting that you make sure this change is going to be accepted
> upstream, before doing any more work. The DT maintainers are reluctant to do
> so.
Appreciate your concern.
Would be really nice if you can review patches 1-12. They have nothing to do
with DT changes.
Thanks.
cheers,
-roger
>
> On the other side, I guess you will also break bisectability while breaking
> backward compatibility. Doesn't sound very nice.
>
--
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 0/3] ARM: dts: overo: Add panel support
Hi Tomi, On 05/20/2014 03:58 PM, Florian Vaussard wrote: > Hi, > > This series enables the DVI and LCD panels present on some of > the Overo expansion boards. > Do you have any more comments on these? If no, do you want to pull them through your tree for 3.16, as discussed with Tony? Regards, Florian > DVI output: > - Tobi > - Summit > > LCD (3.5''): > - Alto35 > > LCD (4.3''): > - Chestnut43 > - Palo43 > - Gallop43 > > I tested on Tobi, Alto35 and Gallop43. > > This series depends on several patches from Tomi [1][2][3] targeting 3.16. > > Regards, > Florian > > Since v2: > - Use gpio-backlight > Since v1: > - Rebased on 3.15-rc4 + recent patches from Tomi > > [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/114572 > [2] http://thread.gmane.org/gmane.linux.ports.arm.omap/114560 > [3] > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/227101.html > > Florian Vaussard (3): > ARM: dts: overo: Add support for DVI output > ARM: dts: overo: Add support for 4.3'' LCD output > ARM: dts: overo: Add support for 3.5'' LCD output > > arch/arm/boot/dts/omap3-overo-alto35-common.dtsi | 1 + > .../boot/dts/omap3-overo-chestnut43-common.dtsi| 1 + > arch/arm/boot/dts/omap3-overo-common-dvi.dtsi | 111 + > arch/arm/boot/dts/omap3-overo-common-lcd35.dtsi| 165 +++ > arch/arm/boot/dts/omap3-overo-common-lcd43.dtsi| 178 > + > arch/arm/boot/dts/omap3-overo-gallop43-common.dtsi | 1 + > arch/arm/boot/dts/omap3-overo-palo43-common.dtsi | 1 + > arch/arm/boot/dts/omap3-overo-summit-common.dtsi | 1 + > arch/arm/boot/dts/omap3-overo-tobi-common.dtsi | 1 + > 9 files changed, 460 insertions(+) > create mode 100644 arch/arm/boot/dts/omap3-overo-common-dvi.dtsi > create mode 100644 arch/arm/boot/dts/omap3-overo-common-lcd35.dtsi > create mode 100644 arch/arm/boot/dts/omap3-overo-common-lcd43.dtsi > -- 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
