Re: [PATCH v3 1/3] nand: omap2: Add support for flash-based bad block table
On 09/11/2014 06:02 PM, Ezequiel Garcia wrote: This commit adds a new platform-data boolean property that enables use of a flash-based bad block table. This can also be enabled by setting the 'nand-on-flash-bbt' devicetree property. If the flash BBT is not enabled, the driver falls back to use OOB bad block markers only, as before. If the flash BBT is enabled the kernel will keep track of bad blocks using a BBT, in addition to the OOB markers. As explained by Brian Norris the reasons for using a BBT are: The primary reason would be that NAND datasheets specify it these days. A better argument is that nobody guarantees that you can write a bad block marker to a worn out block; you may just get program failures. This has been acknowledged by several developers over the last several years. Additionally, you get a boot-time performance improvement if you only have to read a few pages, instead of a page or two from every block on the flash. Signed-off-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar Acked-by: Roger Quadros rog...@ti.com cheers, -roger -- 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] nand: omap2: Remove horrible ifdefs to fix module probe
On 09/11/2014 06:02 PM, Ezequiel Garcia wrote: The current code abuses ifdefs to determine if the selected ECC scheme is supported by the running kernel. As a result the code is hard to read, and it also fails to load as a module. This commit removes all the ifdefs and instead introduces a function omap2_nand_ecc_check() to check if the ECC is supported by using IS_ENABLED(CONFIG_xxx). Since IS_ENABLED() is true when a config is =y or =m, this change fixes the module so it can be loaded with no issues. Signed-off-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar Acked-by: Roger Quadros rog...@ti.com cheers, -roger -- 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/3] nand: omap2: Replace pr_err with dev_err
On 09/11/2014 06:02 PM, Ezequiel Garcia wrote: Usage of pr_err is frowned upon, so replace it with dev_err. Aditionally, the message on nand_bch_init() error is redundant, since proper error is showed if the function fails. You could have omitted the details about nand_bch_init() in the commit message. Signed-off-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar Acked-by: Roger Quadros rog...@ti.com cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] tty: omap-serial: use threaded interrupt handler
On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote: On 09/15/2014 11:39 AM, Peter Hurley wrote: On 09/15/2014 10:00 AM, Frans Klaver wrote: At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart rx buffer overflows within 30 seconds. Threading the interrupt handling reduces this to about 170 overflows in 10 minutes. Why is the threadirqs kernel boot option not sufficient? Or conversely, shouldn't this be selectable? I wasn't aware of the threadirqs boot option. I also wouldn't know if this should be selectable. What would be a reason to favor the non-threaded irq over the threaded irq? Also, do you see the same performance differential when you implement this in the 8250 driver (that is, on top of Sebastian's omap-8250 conversion)? I haven't gotten Sebastian's driver to work properly yet on the console. There was no reason for me yet to throw my omap changes on top of Sebastian's queue. PS - To overflow the 64 byte RX FIFO at those data rates means interrupt latency in excess of 250us? At 3686400 baud it should take about 174 us to fill a 64 byte buffer. I haven't done any measurements on the interrupt latency though. If you consider that we're sending about 1kB of data, 240 times a second, we're spending a lot of time reading data from the uart. I can imagine the system has other work to do as well. This doesn't mean that we're not interested in Sebastian's driver anymore though. We really want that dma support. Thanks, Frans -- 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 09/16] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx
On Mon, Sep 15, 2014 at 06:42:04PM +0200, Sebastian Andrzej Siewior wrote: On 09/12/2014 12:28 PM, Frans Klaver wrote: port config is 115200 8N1. I don't recall doing anything special. I boot, login, less file and get a lock. So I booted my mini Debian 7.6 (basic system + openssh) on my beagle bone black which is: [0.00] AM335X ES2.0 (neon ) configured a console, login, invoked less file. The file was shown, I hit on the space key so less shows me more of the file. No lock-up. I tried booting via NFS and MMC. I tried various files with less. My dot config is here https://breakpoint.cc/config-am335x-bb.txt.xz If there is nothing specific to the file you do less on I have no idea what else it could if it is not the config. I'll test your config and go through the differences. Thanks, Frans -- 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 v5 01/15] 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 jsa...@ti.com
---
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 262771b..1f01068 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -160,7 +160,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 v5 08/15] OMAPDSS: Kconfig: Remove HDMI audio booleans from Kconfig
The booleans are not used anymore. Just select SND_OMAP_SOC_HDMI_AUDIO to enable OMAP HDMI audio support. Signed-off-by: Jyri Sarha jsa...@ti.com --- drivers/video/fbdev/omap2/dss/Kconfig |7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/video/fbdev/omap2/dss/Kconfig b/drivers/video/fbdev/omap2/dss/Kconfig index 3d5eb6c..d1fa730 100644 --- a/drivers/video/fbdev/omap2/dss/Kconfig +++ b/drivers/video/fbdev/omap2/dss/Kconfig @@ -74,9 +74,6 @@ config OMAP4_DSS_HDMI help HDMI support for OMAP4 based SoCs. -config OMAP4_DSS_HDMI_AUDIO - bool - config OMAP5_DSS_HDMI bool HDMI support for OMAP5 default n @@ -86,10 +83,6 @@ config OMAP5_DSS_HDMI Definition Multimedia Interface. See http://www.hdmi.org/ for HDMI specification. -config OMAP5_DSS_HDMI_AUDIO - depends on OMAP5_DSS_HDMI - bool - config OMAP2_DSS_SDI bool SDI support default n -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 00/15] Rework OMAP4+ HDMI audio support
The patches are based on: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git for-next The base, the patches, and couple of additional not-to-be-merged omap2plus_defconfig patches can be found here: git://git.ti.com/~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree.git omap-hdmi-audio Changes since v4: - Turn ASoC parts into a platform device driver - Some cleaning up - reorder the patches to keep bisect working Changes since v3: - Move ASoC parts into library module under sound/soc/omap - Come up with API for the library - Some cleaning up The patch set fixes OMAP4+ HDMI audio. The structure of the implementation looks a bit different than before. Instead of creating a driver specific API for a separate ASoC component driver to connect to, these patches implement a platform device driver under sound/soc/omap for ASoC side implementation. This driver should only be registered from OMAPDSS HDMI code. The ASoC side driver implements cpu-dai component using the callbacks provided by OMAPDSS. Omap-pcm is registered for platform component, dummy hdmi-audio-codec is registered for codec component, and asoc-simple-card is registered for machine driver. Big part of the HDMI audio code is still unchanged and there is a need for a cleanup there. Also there is still probably something wrong with speaker mapping of multi-channel streams. I will get back to cleaning up these issues later. Best regards, Jyri Jyri Sarha (15): OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value OMAPDSS: hdmi: Remove most of OMAP[45]_DSS_HDMI_AUDIO ifdefs OMAPDSS: hdmi4_core: Remove unused hdmi4_audio_get_dma_port() OMAPDSS: hdmi_wp: Add function for getting audio dma address OMAPDSS: hdmi: Make hdmi structure public OMAPDSS: hdmi: Add pdev pointer for audio_pdev in HDMI DRV data ASoC: omap-hdmi-audio: Add platfrom device for OMAP HDMI audio support OMAPDSS: Kconfig: Remove HDMI audio booleans from Kconfig OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly OMAPDSS: hdmi4: Register ASoC platfrom device for omap hdmi audio OMAPDSS: hdmi5: Register ASoC platfrom device for omap hdmi audio ASoC: omap: Remove obsolete HDMI audio code and Kconfig options OMAPDSS: hdmi4: Remove callbacks for the old ASoC DAI driver OMAPDSS: hdmi5: Remove callbacks for the old ASoC DAI driver OMAPDSS: Remove all references to obsolete HDMI audio callbacks .../fbdev/omap2/displays-new/connector-hdmi.c | 99 - .../fbdev/omap2/displays-new/encoder-tpd12s015.c | 56 --- drivers/video/fbdev/omap2/dss/Kconfig |7 - drivers/video/fbdev/omap2/dss/hdmi.h | 35 +- drivers/video/fbdev/omap2/dss/hdmi4.c | 247 ++--- drivers/video/fbdev/omap2/dss/hdmi4_core.c | 14 - drivers/video/fbdev/omap2/dss/hdmi4_core.h |4 - drivers/video/fbdev/omap2/dss/hdmi5.c | 230 +--- drivers/video/fbdev/omap2/dss/hdmi5_core.c |6 - drivers/video/fbdev/omap2/dss/hdmi5_core.h |2 - drivers/video/fbdev/omap2/dss/hdmi_common.c|2 - drivers/video/fbdev/omap2/dss/hdmi_wp.c|8 +- include/sound/omap-hdmi-audio.h| 38 ++ include/video/omapdss.h| 31 -- sound/soc/omap/Kconfig | 22 +- sound/soc/omap/Makefile|6 +- sound/soc/omap/omap-hdmi-audio.c | 379 sound/soc/omap/omap-hdmi-card.c| 87 - sound/soc/omap/omap-hdmi.c | 364 --- sound/soc/omap/omap-hdmi.h | 38 -- 20 files changed, 675 insertions(+), 1000 deletions(-) create mode 100644 include/sound/omap-hdmi-audio.h create mode 100644 sound/soc/omap/omap-hdmi-audio.c delete mode 100644 sound/soc/omap/omap-hdmi-card.c delete mode 100644 sound/soc/omap/omap-hdmi.c delete mode 100644 sound/soc/omap/omap-hdmi.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 v5 15/15] OMAPDSS: Remove all references to obsolete HDMI audio callbacks
In new model these callbacks are obsolete since the ASoC component
drivers are integrated into the HDMI drivers and no callbacks are
needed anymore.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
.../fbdev/omap2/displays-new/connector-hdmi.c | 99
.../fbdev/omap2/displays-new/encoder-tpd12s015.c | 56 ---
include/video/omapdss.h| 31 --
3 files changed, 186 deletions(-)
diff --git a/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c
b/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c
index 131c6e2..dd36d71 100644
--- a/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c
+++ b/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c
@@ -170,98 +170,6 @@ static bool hdmic_detect(struct omap_dss_device *dssdev)
return in-ops.hdmi-detect(in);
}
-static int hdmic_audio_enable(struct omap_dss_device *dssdev)
-{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
- struct omap_dss_device *in = ddata-in;
- int r;
-
- /* enable audio only if the display is active */
- if (!omapdss_device_is_enabled(dssdev))
- return -EPERM;
-
- r = in-ops.hdmi-audio_enable(in);
- if (r)
- return r;
-
- dssdev-audio_state = OMAP_DSS_AUDIO_ENABLED;
-
- return 0;
-}
-
-static void hdmic_audio_disable(struct omap_dss_device *dssdev)
-{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
- struct omap_dss_device *in = ddata-in;
-
- in-ops.hdmi-audio_disable(in);
-
- dssdev-audio_state = OMAP_DSS_AUDIO_DISABLED;
-}
-
-static int hdmic_audio_start(struct omap_dss_device *dssdev)
-{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
- struct omap_dss_device *in = ddata-in;
- int r;
-
- /*
-* No need to check the panel state. It was checked when trasitioning
-* to AUDIO_ENABLED.
-*/
- if (dssdev-audio_state != OMAP_DSS_AUDIO_ENABLED)
- return -EPERM;
-
- r = in-ops.hdmi-audio_start(in);
- if (r)
- return r;
-
- dssdev-audio_state = OMAP_DSS_AUDIO_PLAYING;
-
- return 0;
-}
-
-static void hdmic_audio_stop(struct omap_dss_device *dssdev)
-{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
- struct omap_dss_device *in = ddata-in;
-
- in-ops.hdmi-audio_stop(in);
-
- dssdev-audio_state = OMAP_DSS_AUDIO_ENABLED;
-}
-
-static bool hdmic_audio_supported(struct omap_dss_device *dssdev)
-{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
- struct omap_dss_device *in = ddata-in;
-
- if (!omapdss_device_is_enabled(dssdev))
- return false;
-
- return in-ops.hdmi-audio_supported(in);
-}
-
-static int hdmic_audio_config(struct omap_dss_device *dssdev,
- struct omap_dss_audio *audio)
-{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
- struct omap_dss_device *in = ddata-in;
- int r;
-
- /* config audio only if the display is active */
- if (!omapdss_device_is_enabled(dssdev))
- return -EPERM;
-
- r = in-ops.hdmi-audio_config(in, audio);
- if (r)
- return r;
-
- dssdev-audio_state = OMAP_DSS_AUDIO_CONFIGURED;
-
- return 0;
-}
-
static int hdmic_set_hdmi_mode(struct omap_dss_device *dssdev, bool hdmi_mode)
{
struct panel_drv_data *ddata = to_panel_data(dssdev);
@@ -296,13 +204,6 @@ static struct omap_dss_driver hdmic_driver = {
.detect = hdmic_detect,
.set_hdmi_mode = hdmic_set_hdmi_mode,
.set_hdmi_infoframe = hdmic_set_infoframe,
-
- .audio_enable = hdmic_audio_enable,
- .audio_disable = hdmic_audio_disable,
- .audio_start= hdmic_audio_start,
- .audio_stop = hdmic_audio_stop,
- .audio_supported= hdmic_audio_supported,
- .audio_config = hdmic_audio_config,
};
static int hdmic_probe_pdata(struct platform_device *pdev)
diff --git a/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c
b/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c
index c891d8f..235e3d5 100644
--- a/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c
+++ b/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c
@@ -193,55 +193,6 @@ static bool tpd_detect(struct omap_dss_device *dssdev)
return gpio_get_value_cansleep(ddata-hpd_gpio);
}
-static int tpd_audio_enable(struct omap_dss_device *dssdev)
-{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
- struct omap_dss_device *in = ddata-in;
-
- return in-ops.hdmi-audio_enable(in);
-}
-
-static void tpd_audio_disable(struct omap_dss_device *dssdev)
-{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
- struct omap_dss_device *in = ddata-in;
-
- in-ops.hdmi-audio_disable(in);
-}
-
-static int
[PATCH v5 14/15] OMAPDSS: hdmi5: Remove callbacks for the old ASoC DAI driver
Removes the OMAP5 HDMI audio callbacks for the old external DAI driver.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
drivers/video/fbdev/omap2/dss/hdmi5.c | 113 -
1 file changed, 113 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi5.c
b/drivers/video/fbdev/omap2/dss/hdmi5.c
index 360b31f..0a67c84 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi5.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi5.c
@@ -493,112 +493,6 @@ static int hdmi_read_edid(struct omap_dss_device *dssdev,
return r;
}
-#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
-static int hdmi_audio_enable(struct omap_dss_device *dssdev)
-{
- int r;
-
- mutex_lock(hdmi.lock);
-
- if (!hdmi_mode_has_audio(hdmi.cfg.hdmi_dvi_mode)) {
- r = -EPERM;
- goto err;
- }
-
- r = hdmi_wp_audio_enable(hdmi.wp, true);
- if (r)
- goto err;
-
- mutex_unlock(hdmi.lock);
- return 0;
-
-err:
- mutex_unlock(hdmi.lock);
- return r;
-}
-
-static void hdmi_audio_disable(struct omap_dss_device *dssdev)
-{
- hdmi_wp_audio_enable(hdmi.wp, false);
-}
-
-static int hdmi_audio_start(struct omap_dss_device *dssdev)
-{
- return hdmi_wp_audio_core_req_enable(hdmi.wp, true);
-}
-
-static void hdmi_audio_stop(struct omap_dss_device *dssdev)
-{
- hdmi_wp_audio_core_req_enable(hdmi.wp, false);
-}
-
-static bool hdmi_audio_supported(struct omap_dss_device *dssdev)
-{
- bool r;
-
- mutex_lock(hdmi.lock);
-
- r = hdmi_mode_has_audio(hdmi.cfg.hdmi_dvi_mode);
-
- mutex_unlock(hdmi.lock);
- return r;
-}
-
-static int hdmi_audio_config(struct omap_dss_device *dssdev,
- struct omap_dss_audio *audio)
-{
- int r;
- u32 pclk = hdmi.cfg.timings.pixelclock;
-
- mutex_lock(hdmi.lock);
-
- if (!hdmi_mode_has_audio(hdmi.cfg.hdmi_dvi_mode)) {
- r = -EPERM;
- goto err;
- }
-
- r = hdmi5_audio_config(hdmi.core, hdmi.wp, audio, pclk);
- if (r)
- goto err;
-
- mutex_unlock(hdmi.lock);
- return 0;
-
-err:
- mutex_unlock(hdmi.lock);
- return r;
-}
-#else
-static int hdmi_audio_enable(struct omap_dss_device *dssdev)
-{
- return -EPERM;
-}
-
-static void hdmi_audio_disable(struct omap_dss_device *dssdev)
-{
-}
-
-static int hdmi_audio_start(struct omap_dss_device *dssdev)
-{
- return -EPERM;
-}
-
-static void hdmi_audio_stop(struct omap_dss_device *dssdev)
-{
-}
-
-static bool hdmi_audio_supported(struct omap_dss_device *dssdev)
-{
- return false;
-}
-
-static int hdmi_audio_config(struct omap_dss_device *dssdev,
- struct omap_dss_audio *audio)
-{
- return -EPERM;
-}
-#endif
-
static int hdmi_set_infoframe(struct omap_dss_device *dssdev,
const struct hdmi_avi_infoframe *avi)
{
@@ -627,13 +521,6 @@ static const struct omapdss_hdmi_ops hdmi_ops = {
.read_edid = hdmi_read_edid,
.set_infoframe = hdmi_set_infoframe,
.set_hdmi_mode = hdmi_set_hdmi_mode,
-
- .audio_enable = hdmi_audio_enable,
- .audio_disable = hdmi_audio_disable,
- .audio_start= hdmi_audio_start,
- .audio_stop = hdmi_audio_stop,
- .audio_supported= hdmi_audio_supported,
- .audio_config = hdmi_audio_config,
};
static void hdmi_init_output(struct platform_device *pdev)
--
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 v5 06/15] OMAPDSS: hdmi: Add pdev pointer for audio_pdev in HDMI DRV data
This is used to store omap-hdmi-audio pdev for unregistering it.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
drivers/video/fbdev/omap2/dss/hdmi.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h
b/drivers/video/fbdev/omap2/dss/hdmi.h
index 6bf077b..a6e08ff 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -368,6 +368,8 @@ struct omap_hdmi {
bool core_enabled;
struct omap_dss_device output;
+
+ struct platform_device *audio_pdev;
};
#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 v5 05/15] OMAPDSS: hdmi: Make hdmi structure public
Unify the private anonymous struct in hdmi4.c and hdmi5.c, name it as
struct omap_hdmi, and make it public in hdmi.h.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
drivers/video/fbdev/omap2/dss/hdmi.h | 21 +
drivers/video/fbdev/omap2/dss/hdmi4.c | 31 ---
drivers/video/fbdev/omap2/dss/hdmi5.c | 20 ++--
3 files changed, 31 insertions(+), 41 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h
b/drivers/video/fbdev/omap2/dss/hdmi.h
index 9ba7c1a..6bf077b 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -349,4 +349,25 @@ static inline bool hdmi_mode_has_audio(int mode)
{
return mode == HDMI_HDMI ? true : false;
}
+
+/* HDMI DRV data */
+struct omap_hdmi {
+ struct mutex lock;
+ struct platform_device *pdev;
+
+ struct hdmi_wp_data wp;
+ struct hdmi_pll_datapll;
+ struct hdmi_phy_dataphy;
+ struct hdmi_core_data core;
+
+ struct hdmi_config cfg;
+
+ struct clk *sys_clk;
+ struct regulator *vdda_reg;
+
+ bool core_enabled;
+
+ struct omap_dss_device output;
+};
+
#endif
diff --git a/drivers/video/fbdev/omap2/dss/hdmi4.c
b/drivers/video/fbdev/omap2/dss/hdmi4.c
index 6a8550c..b98186e 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi4.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi4.c
@@ -37,25 +37,9 @@
#include hdmi4_core.h
#include dss.h
#include dss_features.h
+#include hdmi.h
-static struct {
- struct mutex lock;
- struct platform_device *pdev;
-
- struct hdmi_wp_data wp;
- struct hdmi_pll_datapll;
- struct hdmi_phy_dataphy;
- struct hdmi_core_data core;
-
- struct hdmi_config cfg;
-
- struct clk *sys_clk;
- struct regulator *vdda_hdmi_dac_reg;
-
- bool core_enabled;
-
- struct omap_dss_device output;
-} hdmi;
+static struct omap_hdmi hdmi;
static int hdmi_runtime_get(void)
{
@@ -117,7 +101,7 @@ static int hdmi_init_regulator(void)
int r;
struct regulator *reg;
- if (hdmi.vdda_hdmi_dac_reg != NULL)
+ if (hdmi.vdda_reg != NULL)
return 0;
reg = devm_regulator_get(hdmi.pdev-dev, vdda);
@@ -137,7 +121,7 @@ static int hdmi_init_regulator(void)
}
}
- hdmi.vdda_hdmi_dac_reg = reg;
+ hdmi.vdda_reg = reg;
return 0;
}
@@ -146,7 +130,7 @@ static int hdmi_power_on_core(struct omap_dss_device
*dssdev)
{
int r;
- r = regulator_enable(hdmi.vdda_hdmi_dac_reg);
+ r = regulator_enable(hdmi.vdda_reg);
if (r)
return r;
@@ -162,7 +146,7 @@ static int hdmi_power_on_core(struct omap_dss_device
*dssdev)
return 0;
err_runtime_get:
- regulator_disable(hdmi.vdda_hdmi_dac_reg);
+ regulator_disable(hdmi.vdda_reg);
return r;
}
@@ -172,7 +156,7 @@ static void hdmi_power_off_core(struct omap_dss_device
*dssdev)
hdmi.core_enabled = false;
hdmi_runtime_put();
- regulator_disable(hdmi.vdda_hdmi_dac_reg);
+ regulator_disable(hdmi.vdda_reg);
}
static int hdmi_power_on_full(struct omap_dss_device *dssdev)
@@ -678,6 +662,7 @@ static int omapdss_hdmihw_probe(struct platform_device
*pdev)
int irq;
hdmi.pdev = pdev;
+ dev_set_drvdata(pdev-dev, hdmi);
mutex_init(hdmi.lock);
diff --git a/drivers/video/fbdev/omap2/dss/hdmi5.c
b/drivers/video/fbdev/omap2/dss/hdmi5.c
index 32d02ec..90410f5 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi5.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi5.c
@@ -43,24 +43,7 @@
#include dss.h
#include dss_features.h
-static struct {
- struct mutex lock;
- struct platform_device *pdev;
-
- struct hdmi_wp_data wp;
- struct hdmi_pll_datapll;
- struct hdmi_phy_dataphy;
- struct hdmi_core_data core;
-
- struct hdmi_config cfg;
-
- struct clk *sys_clk;
- struct regulator *vdda_reg;
-
- bool core_enabled;
-
- struct omap_dss_device output;
-} hdmi;
+static struct omap_hdmi hdmi;
static int hdmi_runtime_get(void)
{
@@ -703,6 +686,7 @@ static int omapdss_hdmihw_probe(struct platform_device
*pdev)
int irq;
hdmi.pdev = pdev;
+ dev_set_drvdata(pdev-dev, hdmi);
mutex_init(hdmi.lock);
--
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 v5 02/15] OMAPDSS: hdmi: Remove most of OMAP[45]_DSS_HDMI_AUDIO ifdefs
It does not waste too many bytes to compile all audio related core
functions always in with HDMI support. It should help readability and
in keeping the audio code in working shape. Leave the options just for
disabling and enabling the functionality in hdmi[45].c.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
drivers/video/fbdev/omap2/dss/hdmi.h|3 +--
drivers/video/fbdev/omap2/dss/hdmi4_core.c |5 -
drivers/video/fbdev/omap2/dss/hdmi4_core.h |2 --
drivers/video/fbdev/omap2/dss/hdmi5_core.c |6 --
drivers/video/fbdev/omap2/dss/hdmi5_core.h |2 --
drivers/video/fbdev/omap2/dss/hdmi_common.c |2 --
drivers/video/fbdev/omap2/dss/hdmi_wp.c |2 --
7 files changed, 1 insertion(+), 21 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h
b/drivers/video/fbdev/omap2/dss/hdmi.h
index 1f01068..03726b5 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -335,7 +335,7 @@ int hdmi_phy_parse_lanes(struct hdmi_phy_data *phy, const
u32 *lanes);
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)
+/* Audio funcs */
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);
@@ -348,4 +348,3 @@ static inline bool hdmi_mode_has_audio(int mode)
return mode == HDMI_HDMI ? true : false;
}
#endif
-#endif
diff --git a/drivers/video/fbdev/omap2/dss/hdmi4_core.c
b/drivers/video/fbdev/omap2/dss/hdmi4_core.c
index 4ad39cf..3b448d9 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi4_core.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi4_core.c
@@ -31,10 +31,8 @@
#include linux/platform_device.h
#include linux/string.h
#include linux/seq_file.h
-#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
#include sound/asound.h
#include sound/asoundef.h
-#endif
#include hdmi4_core.h
#include dss_features.h
@@ -530,7 +528,6 @@ void hdmi4_core_dump(struct hdmi_core_data *core, struct
seq_file *s)
DUMPCOREAV(HDMI_CORE_AV_CEC_ADDR_ID);
}
-#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
static void hdmi_core_audio_config(struct hdmi_core_data *core,
struct hdmi_core_audio_config *cfg)
{
@@ -886,8 +883,6 @@ int hdmi4_audio_get_dma_port(u32 *offset, u32 *size)
return 0;
}
-#endif
-
int hdmi4_core_init(struct platform_device *pdev, struct hdmi_core_data *core)
{
struct resource *res;
diff --git a/drivers/video/fbdev/omap2/dss/hdmi4_core.h
b/drivers/video/fbdev/omap2/dss/hdmi4_core.h
index 827909e..c1959f7 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi4_core.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi4_core.h
@@ -266,12 +266,10 @@ void hdmi4_configure(struct hdmi_core_data *core, struct
hdmi_wp_data *wp,
void hdmi4_core_dump(struct hdmi_core_data *core, struct seq_file *s);
int hdmi4_core_init(struct platform_device *pdev, struct hdmi_core_data *core);
-#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
int hdmi4_audio_start(struct hdmi_core_data *core, struct hdmi_wp_data *wp);
void hdmi4_audio_stop(struct hdmi_core_data *core, struct hdmi_wp_data *wp);
int hdmi4_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp,
struct omap_dss_audio *audio, u32 pclk);
int hdmi4_audio_get_dma_port(u32 *offset, u32 *size);
-#endif
#endif
diff --git a/drivers/video/fbdev/omap2/dss/hdmi5_core.c
b/drivers/video/fbdev/omap2/dss/hdmi5_core.c
index 83acbf7..8eab25b 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi5_core.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi5_core.c
@@ -30,10 +30,8 @@
#include linux/string.h
#include linux/seq_file.h
#include drm/drm_edid.h
-#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
#include sound/asound.h
#include sound/asoundef.h
-#endif
#include hdmi5_core.h
@@ -644,9 +642,6 @@ void hdmi5_configure(struct hdmi_core_data *core, struct
hdmi_wp_data *wp,
hdmi_core_enable_interrupts(core);
}
-
-#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
-
static void hdmi5_core_audio_config(struct hdmi_core_data *core,
struct hdmi_core_audio_config *cfg)
{
@@ -894,7 +889,6 @@ int hdmi5_audio_config(struct hdmi_core_data *core, struct
hdmi_wp_data *wp,
return 0;
}
-#endif
int hdmi5_core_init(struct platform_device *pdev, struct hdmi_core_data *core)
{
diff --git a/drivers/video/fbdev/omap2/dss/hdmi5_core.h
b/drivers/video/fbdev/omap2/dss/hdmi5_core.h
index ce7e9f3..f2f1022 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi5_core.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi5_core.h
@@ -299,8 +299,6 @@ void hdmi5_configure(struct hdmi_core_data *core, struct
hdmi_wp_data *wp,
struct hdmi_config *cfg);
int hdmi5_core_init(struct platform_device *pdev, struct hdmi_core_data *core);
-#if
[PATCH v5 11/15] OMAPDSS: hdmi5: Register ASoC platfrom device for omap hdmi audio
Implements callbacks for OMAP HDMI audio platform driver and registers
it in probe function. Unregistering is done in remove function.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
drivers/video/fbdev/omap2/dss/hdmi5.c | 97 +
1 file changed, 97 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi5.c
b/drivers/video/fbdev/omap2/dss/hdmi5.c
index 90410f5..360b31f 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi5.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi5.c
@@ -38,6 +38,7 @@
#include linux/gpio.h
#include linux/regulator/consumer.h
#include video/omapdss.h
+#include sound/omap-hdmi-audio.h
#include hdmi5_core.h
#include dss.h
@@ -679,6 +680,91 @@ err:
return r;
}
+/* Audio callbacks */
+static int mode_has_audio(struct device *dev)
+{
+ struct omap_hdmi *hd = dev_get_drvdata(dev);
+ int ret;
+
+ mutex_lock(hd-lock);
+ ret = hdmi_mode_has_audio(hd-cfg);
+ mutex_unlock(hd-lock);
+
+ return ret;
+}
+
+static int audio_enable(struct device *dev, bool enable)
+{
+ struct omap_hdmi *hd = dev_get_drvdata(dev);
+ int ret;
+
+ mutex_lock(hd-lock);
+ if (!hdmi_mode_has_audio(hd-cfg))
+ ret = -EPERM;
+ else
+ ret = hdmi_wp_audio_enable(hd-wp, enable);
+ mutex_unlock(hd-lock);
+
+ return ret;
+}
+
+static int audio_start(struct device *dev, bool enable)
+{
+ struct omap_hdmi *hd = dev_get_drvdata(dev);
+
+ return hdmi_wp_audio_core_req_enable(hd-wp, enable);
+}
+
+static int audio_config(struct device *dev, struct omap_dss_audio *dss_audio)
+{
+ struct omap_hdmi *hd = dev_get_drvdata(dev);
+ int ret;
+
+ mutex_lock(hd-lock);
+ if (!hdmi_mode_has_audio(hd-cfg))
+ ret = -EPERM;
+ else
+ ret = hdmi5_audio_config(hd-core, hd-wp, dss_audio,
+hd-cfg.timings.pixelclock);
+ mutex_unlock(hd-lock);
+
+ return ret;
+}
+
+static int hdmi_audio_register(struct device *dev)
+{
+ struct omap_hdmi_audio_pdata pdata = {
+ .dev = dev,
+ .hw_version = OMAP5_HDMI,
+ .audio_dma_addr = hdmi_wp_get_audio_dma_addr(hdmi.wp),
+ .mode_has_audio = mode_has_audio,
+ .audio_enable = audio_enable,
+ .audio_start = audio_start,
+ .audio_config = audio_config,
+ };
+ struct of_phandle_args dma_spec;
+ int ret;
+
+ ret = of_property_match_string(dev-of_node, dma-names, audio_tx);
+ if (ret 0)
+ return ret;
+
+ ret = of_parse_phandle_with_args(dev-of_node, dmas, #dma-cells,
+ret, dma_spec);
+ if (ret 0)
+ return ret;
+
+ pdata.audio_dma_req = dma_spec.args[0];
+
+ hdmi.audio_pdev =
+ platform_device_register_data(dev, omap-hdmi-audio, 0,
+ pdata, sizeof(pdata));
+ if (IS_ERR(hdmi.audio_pdev))
+ return PTR_ERR(hdmi.audio_pdev);
+
+ return 0;
+}
+
/* HDMI HW IP initialisation */
static int omapdss_hdmihw_probe(struct platform_device *pdev)
{
@@ -736,6 +822,14 @@ static int omapdss_hdmihw_probe(struct platform_device
*pdev)
hdmi_init_output(pdev);
+ r = hdmi_audio_register(pdev-dev);
+ if (r) {
+ DSSERR(Registering HDMI audio failed %d\n, r);
+ hdmi_uninit_output(pdev);
+ pm_runtime_disable(pdev-dev);
+ return r;
+ }
+
dss_debugfs_create_file(hdmi, hdmi_dump_regs);
return 0;
@@ -743,6 +837,9 @@ static int omapdss_hdmihw_probe(struct platform_device
*pdev)
static int __exit omapdss_hdmihw_remove(struct platform_device *pdev)
{
+ if (hdmi.audio_pdev)
+ platform_device_unregister(hdmi.audio_pdev);
+
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 v5 13/15] OMAPDSS: hdmi4: Remove callbacks for the old ASoC DAI driver
Removes the OMAP4 HDMI audio callbacks for the old external DAI driver.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
drivers/video/fbdev/omap2/dss/hdmi4.c | 113 -
1 file changed, 113 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi4.c
b/drivers/video/fbdev/omap2/dss/hdmi4.c
index 2e87229..47c0195 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi4.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi4.c
@@ -469,112 +469,6 @@ static int hdmi_read_edid(struct omap_dss_device *dssdev,
return r;
}
-#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
-static int hdmi_audio_enable(struct omap_dss_device *dssdev)
-{
- int r;
-
- mutex_lock(hdmi.lock);
-
- if (!hdmi_mode_has_audio(hdmi.cfg.hdmi_dvi_mode)) {
- r = -EPERM;
- goto err;
- }
-
- r = hdmi_wp_audio_enable(hdmi.wp, true);
- if (r)
- goto err;
-
- mutex_unlock(hdmi.lock);
- return 0;
-
-err:
- mutex_unlock(hdmi.lock);
- return r;
-}
-
-static void hdmi_audio_disable(struct omap_dss_device *dssdev)
-{
- hdmi_wp_audio_enable(hdmi.wp, false);
-}
-
-static int hdmi_audio_start(struct omap_dss_device *dssdev)
-{
- return hdmi4_audio_start(hdmi.core, hdmi.wp);
-}
-
-static void hdmi_audio_stop(struct omap_dss_device *dssdev)
-{
- hdmi4_audio_stop(hdmi.core, hdmi.wp);
-}
-
-static bool hdmi_audio_supported(struct omap_dss_device *dssdev)
-{
- bool r;
-
- mutex_lock(hdmi.lock);
-
- r = hdmi_mode_has_audio(hdmi.cfg.hdmi_dvi_mode);
-
- mutex_unlock(hdmi.lock);
- return r;
-}
-
-static int hdmi_audio_config(struct omap_dss_device *dssdev,
- struct omap_dss_audio *audio)
-{
- int r;
- u32 pclk = hdmi.cfg.timings.pixelclock;
-
- mutex_lock(hdmi.lock);
-
- if (!hdmi_mode_has_audio(hdmi.cfg.hdmi_dvi_mode)) {
- r = -EPERM;
- goto err;
- }
-
- r = hdmi4_audio_config(hdmi.core, hdmi.wp, audio, pclk);
- if (r)
- goto err;
-
- mutex_unlock(hdmi.lock);
- return 0;
-
-err:
- mutex_unlock(hdmi.lock);
- return r;
-}
-#else
-static int hdmi_audio_enable(struct omap_dss_device *dssdev)
-{
- return -EPERM;
-}
-
-static void hdmi_audio_disable(struct omap_dss_device *dssdev)
-{
-}
-
-static int hdmi_audio_start(struct omap_dss_device *dssdev)
-{
- return -EPERM;
-}
-
-static void hdmi_audio_stop(struct omap_dss_device *dssdev)
-{
-}
-
-static bool hdmi_audio_supported(struct omap_dss_device *dssdev)
-{
- return false;
-}
-
-static int hdmi_audio_config(struct omap_dss_device *dssdev,
- struct omap_dss_audio *audio)
-{
- return -EPERM;
-}
-#endif
-
static int hdmi_set_infoframe(struct omap_dss_device *dssdev,
const struct hdmi_avi_infoframe *avi)
{
@@ -603,13 +497,6 @@ static const struct omapdss_hdmi_ops hdmi_ops = {
.read_edid = hdmi_read_edid,
.set_infoframe = hdmi_set_infoframe,
.set_hdmi_mode = hdmi_set_hdmi_mode,
-
- .audio_enable = hdmi_audio_enable,
- .audio_disable = hdmi_audio_disable,
- .audio_start= hdmi_audio_start,
- .audio_stop = hdmi_audio_stop,
- .audio_supported= hdmi_audio_supported,
- .audio_config = hdmi_audio_config,
};
static void hdmi_init_output(struct platform_device *pdev)
--
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 v5 12/15] ASoC: omap: Remove obsolete HDMI audio code and Kconfig options
Removes omap-hdmi DAI driver, omap-hdmi-card driver, the related
Kconfig options, and Makefile entries. The HDMI DAI drivers has been
integrated directly to OMAP4+ HDMI drivers and simple-card driver is
used instead of omap-hdmi-card driver.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
sound/soc/omap/Kconfig | 13 --
sound/soc/omap/Makefile |4 -
sound/soc/omap/omap-hdmi-card.c | 87 --
sound/soc/omap/omap-hdmi.c | 364 ---
sound/soc/omap/omap-hdmi.h | 38
5 files changed, 506 deletions(-)
delete mode 100644 sound/soc/omap/omap-hdmi-card.c
delete mode 100644 sound/soc/omap/omap-hdmi.c
delete mode 100644 sound/soc/omap/omap-hdmi.h
diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index 66eb428..5fc56a6 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -12,9 +12,6 @@ config SND_OMAP_SOC_MCBSP
config SND_OMAP_SOC_MCPDM
tristate
-config SND_OMAP_SOC_HDMI
- tristate
-
config SND_OMAP_SOC_HDMI_AUDIO
tristate HDMI audio support for OMAP4+ based SoCs
depends on SND_OMAP_SOC
@@ -111,16 +108,6 @@ config SND_OMAP_SOC_OMAP_ABE_TWL6040
- PandaBoard (4430)
- PandaBoardES (4460)
-config SND_OMAP_SOC_OMAP_HDMI
- tristate SoC Audio support for Texas Instruments OMAP HDMI
- depends on SND_OMAP_SOC OMAP4_DSS_HDMI OMAP2_DSS
- select SND_OMAP_SOC_HDMI
- select SND_SOC_HDMI_CODEC
- select OMAP4_DSS_HDMI_AUDIO
- help
- Say Y if you want to add support for SoC HDMI audio on Texas
Instruments
- OMAP4 chips
-
config SND_OMAP_SOC_OMAP3_PANDORA
tristate SoC Audio support for OMAP3 Pandora
depends on TWL4030_CORE SND_OMAP_SOC MACH_OMAP3_PANDORA
diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
index 40688a6..db36fbd 100644
--- a/sound/soc/omap/Makefile
+++ b/sound/soc/omap/Makefile
@@ -3,14 +3,12 @@ snd-soc-omap-objs := omap-pcm.o
snd-soc-omap-dmic-objs := omap-dmic.o
snd-soc-omap-mcbsp-objs := omap-mcbsp.o mcbsp.o
snd-soc-omap-mcpdm-objs := omap-mcpdm.o
-snd-soc-omap-hdmi-objs := omap-hdmi.o
snd-soc-omap-hdmi-audio-objs := omap-hdmi-audio.o
obj-$(CONFIG_SND_OMAP_SOC) += snd-soc-omap.o
obj-$(CONFIG_SND_OMAP_SOC_DMIC) += snd-soc-omap-dmic.o
obj-$(CONFIG_SND_OMAP_SOC_MCBSP) += snd-soc-omap-mcbsp.o
obj-$(CONFIG_SND_OMAP_SOC_MCPDM) += snd-soc-omap-mcpdm.o
-obj-$(CONFIG_SND_OMAP_SOC_HDMI) += snd-soc-omap-hdmi.o
obj-$(CONFIG_SND_OMAP_SOC_HDMI_AUDIO) += snd-soc-omap-hdmi-audio.o
# OMAP Machine Support
@@ -22,7 +20,6 @@ snd-soc-am3517evm-objs := am3517evm.o
snd-soc-omap-abe-twl6040-objs := omap-abe-twl6040.o
snd-soc-omap-twl4030-objs := omap-twl4030.o
snd-soc-omap3pandora-objs := omap3pandora.o
-snd-soc-omap-hdmi-card-objs := omap-hdmi-card.o
obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-n810.o
obj-$(CONFIG_SND_OMAP_SOC_RX51) += snd-soc-rx51.o
@@ -32,4 +29,3 @@ obj-$(CONFIG_SND_OMAP_SOC_AM3517EVM) += snd-soc-am3517evm.o
obj-$(CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040) += snd-soc-omap-abe-twl6040.o
obj-$(CONFIG_SND_OMAP_SOC_OMAP_TWL4030) += snd-soc-omap-twl4030.o
obj-$(CONFIG_SND_OMAP_SOC_OMAP3_PANDORA) += snd-soc-omap3pandora.o
-obj-$(CONFIG_SND_OMAP_SOC_OMAP_HDMI) += snd-soc-omap-hdmi-card.o
diff --git a/sound/soc/omap/omap-hdmi-card.c b/sound/soc/omap/omap-hdmi-card.c
deleted file mode 100644
index f649fe8..000
--- a/sound/soc/omap/omap-hdmi-card.c
+++ /dev/null
@@ -1,87 +0,0 @@
-/*
- * omap-hdmi-card.c
- *
- * OMAP ALSA SoC machine driver for TI OMAP HDMI
- * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
- * Author: Ricardo Neri ricardo.n...@ti.com
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
- */
-
-#include linux/module.h
-#include sound/pcm.h
-#include sound/soc.h
-#include asm/mach-types.h
-#include video/omapdss.h
-
-#define DRV_NAME omap-hdmi-audio
-
-static struct snd_soc_dai_link omap_hdmi_dai = {
- .name = HDMI,
- .stream_name = HDMI,
- .cpu_dai_name = omap-hdmi-audio-dai,
- .platform_name = omap-hdmi-audio-dai,
- .codec_name = hdmi-audio-codec,
- .codec_dai_name = hdmi-hifi,
-};
-
-static struct snd_soc_card snd_soc_omap_hdmi = {
- .name = OMAPHDMI,
- .owner = THIS_MODULE,
- .dai_link = omap_hdmi_dai,
- .num_links = 1,
-};
-
-static int
[PATCH v5 10/15] OMAPDSS: hdmi4: Register ASoC platfrom device for omap hdmi audio
Implements callbacks for OMAP HDMI audio platform driver and registers
it in probe function. Unregistering is done in remove function.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
drivers/video/fbdev/omap2/dss/hdmi4.c | 103 +
1 file changed, 103 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi4.c
b/drivers/video/fbdev/omap2/dss/hdmi4.c
index b98186e..2e87229 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi4.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi4.c
@@ -33,6 +33,7 @@
#include linux/gpio.h
#include linux/regulator/consumer.h
#include video/omapdss.h
+#include sound/omap-hdmi-audio.h
#include hdmi4_core.h
#include dss.h
@@ -655,6 +656,97 @@ err:
return r;
}
+/* Audio callbacks */
+static int mode_has_audio(struct device *dev)
+{
+ struct omap_hdmi *hd = dev_get_drvdata(dev);
+ int ret;
+
+ mutex_lock(hd-lock);
+ ret = hdmi_mode_has_audio(hd-cfg);
+ mutex_unlock(hd-lock);
+
+ return ret;
+}
+
+static int audio_enable(struct device *dev, bool enable)
+{
+ struct omap_hdmi *hd = dev_get_drvdata(dev);
+ int ret;
+
+ mutex_lock(hd-lock);
+ if (!hdmi_mode_has_audio(hd-cfg))
+ ret = -EPERM;
+ else
+ ret = hdmi_wp_audio_enable(hd-wp, enable);
+ mutex_unlock(hd-lock);
+
+ return ret;
+}
+
+static int audio_start(struct device *dev, bool enable)
+{
+ struct omap_hdmi *hd = dev_get_drvdata(dev);
+ int ret = 0;
+
+ if (enable)
+ ret = hdmi4_audio_start(hd-core, hd-wp);
+ else
+ hdmi4_audio_stop(hd-core, hd-wp);
+
+ return ret;
+}
+
+static int audio_config(struct device *dev, struct omap_dss_audio *dss_audio)
+{
+ struct omap_hdmi *hd = dev_get_drvdata(dev);
+ int ret;
+
+ mutex_lock(hd-lock);
+ if (!hdmi_mode_has_audio(hd-cfg))
+ ret = -EPERM;
+ else
+ ret = hdmi4_audio_config(hd-core, hd-wp, dss_audio,
+hd-cfg.timings.pixelclock);
+ mutex_unlock(hd-lock);
+
+ return ret;
+}
+
+static int hdmi_audio_register(struct device *dev)
+{
+ struct omap_hdmi_audio_pdata pdata = {
+ .dev = dev,
+ .hw_version = OMAP4_HDMI,
+ .audio_dma_addr = hdmi_wp_get_audio_dma_addr(hdmi.wp),
+ .mode_has_audio = mode_has_audio,
+ .audio_enable = audio_enable,
+ .audio_start = audio_start,
+ .audio_config = audio_config,
+ };
+ struct of_phandle_args dma_spec;
+ int ret;
+
+ ret = of_property_match_string(dev-of_node, dma-names, audio_tx);
+ if (ret 0)
+ return ret;
+
+ ret = of_parse_phandle_with_args(dev-of_node, dmas, #dma-cells,
+ret, dma_spec);
+ if (ret 0)
+ return ret;
+
+ pdata.audio_dma_req = dma_spec.args[0];
+
+ hdmi.audio_pdev =
+ platform_device_register_data(dev, omap-hdmi-audio, 0,
+ pdata, sizeof(pdata));
+ if (IS_ERR(hdmi.audio_pdev))
+ return PTR_ERR(hdmi.audio_pdev);
+
+ return 0;
+}
+
/* HDMI HW IP initialisation */
static int omapdss_hdmihw_probe(struct platform_device *pdev)
{
@@ -712,6 +804,14 @@ static int omapdss_hdmihw_probe(struct platform_device
*pdev)
hdmi_init_output(pdev);
+ r = hdmi_audio_register(pdev-dev);
+ if (r) {
+ DSSERR(Registering HDMI audio failed\n);
+ hdmi_uninit_output(pdev);
+ pm_runtime_disable(pdev-dev);
+ return r;
+ }
+
dss_debugfs_create_file(hdmi, hdmi_dump_regs);
return 0;
@@ -719,6 +819,9 @@ static int omapdss_hdmihw_probe(struct platform_device
*pdev)
static int __exit omapdss_hdmihw_remove(struct platform_device *pdev)
{
+ if (hdmi.audio_pdev)
+ platform_device_unregister(hdmi.audio_pdev);
+
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 v5 03/15] OMAPDSS: hdmi4_core: Remove unused hdmi4_audio_get_dma_port()
hdmi4_audio_get_dma_port() is unused and and broken.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
drivers/video/fbdev/omap2/dss/hdmi4_core.c |9 -
drivers/video/fbdev/omap2/dss/hdmi4_core.h |2 --
2 files changed, 11 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi4_core.c
b/drivers/video/fbdev/omap2/dss/hdmi4_core.c
index 3b448d9..7eafea5 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi4_core.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi4_core.c
@@ -874,15 +874,6 @@ void hdmi4_audio_stop(struct hdmi_core_data *core, struct
hdmi_wp_data *wp)
hdmi_wp_audio_core_req_enable(wp, false);
}
-int hdmi4_audio_get_dma_port(u32 *offset, u32 *size)
-{
- if (!offset || !size)
- return -EINVAL;
- *offset = HDMI_WP_AUDIO_DATA;
- *size = 4;
- return 0;
-}
-
int hdmi4_core_init(struct platform_device *pdev, struct hdmi_core_data *core)
{
struct resource *res;
diff --git a/drivers/video/fbdev/omap2/dss/hdmi4_core.h
b/drivers/video/fbdev/omap2/dss/hdmi4_core.h
index c1959f7..a069f96 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi4_core.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi4_core.h
@@ -270,6 +270,4 @@ int hdmi4_audio_start(struct hdmi_core_data *core, struct
hdmi_wp_data *wp);
void hdmi4_audio_stop(struct hdmi_core_data *core, struct hdmi_wp_data *wp);
int hdmi4_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp,
struct omap_dss_audio *audio, u32 pclk);
-int hdmi4_audio_get_dma_port(u32 *offset, u32 *size);
-
#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 v5 09/15] OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly
Signed-off-by: Jyri Sarha jsa...@ti.com
---
drivers/video/fbdev/omap2/dss/hdmi.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h
b/drivers/video/fbdev/omap2/dss/hdmi.h
index a6e08ff..6d129f2 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -345,9 +345,9 @@ void hdmi_wp_audio_config_format(struct hdmi_wp_data *wp,
struct hdmi_audio_format *aud_fmt);
void hdmi_wp_audio_config_dma(struct hdmi_wp_data *wp,
struct hdmi_audio_dma *aud_dma);
-static inline bool hdmi_mode_has_audio(int mode)
+static inline bool hdmi_mode_has_audio(struct hdmi_config *cfg)
{
- return mode == HDMI_HDMI ? true : false;
+ return cfg-hdmi_dvi_mode == HDMI_HDMI ? true : false;
}
/* HDMI DRV data */
--
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 v5 04/15] OMAPDSS: hdmi_wp: Add function for getting audio dma address
The audio dma port is found in the hdmi_wp physical address space.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
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 03726b5..9ba7c1a 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -250,6 +250,7 @@ struct hdmi_core_audio_config {
struct hdmi_wp_data {
void __iomem *base;
+ phys_addr_t phys_base;
};
struct hdmi_pll_data {
@@ -317,6 +318,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_audio_dma_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 f1b53de..5154120 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi_wp.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi_wp.c
@@ -245,6 +245,7 @@ int hdmi_wp_init(struct platform_device *pdev, struct
hdmi_wp_data *wp)
DSSERR(can't get WP mem resource\n);
return -EINVAL;
}
+ wp-phys_base = res-start;
wp-base = devm_ioremap_resource(pdev-dev, res);
if (IS_ERR(wp-base)) {
@@ -254,3 +255,8 @@ int hdmi_wp_init(struct platform_device *pdev, struct
hdmi_wp_data *wp)
return 0;
}
+
+phys_addr_t hdmi_wp_get_audio_dma_addr(struct hdmi_wp_data *wp)
+{
+ return wp-phys_base + HDMI_WP_AUDIO_DATA;
+}
--
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 v5 07/15] ASoC: omap-hdmi-audio: Add platfrom device for OMAP HDMI audio support
The platform device should only be registered from OMAPDSS HDMI
driver. The platfrom driver registers and unregisters all ASoC
components needed for OMAP HDMI audio.
The hdmi audio driver implements cpu-dai component using the callbacks
provided by OMAPDSS. Omap-pcm is registered for platform component,
dummy hdmi-audio-codec is registered for codec component, and
asoc-simple-card is registered for machine driver.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
include/sound/omap-hdmi-audio.h | 38
sound/soc/omap/Kconfig | 11 ++
sound/soc/omap/Makefile |2 +
sound/soc/omap/omap-hdmi-audio.c | 379 ++
4 files changed, 430 insertions(+)
create mode 100644 include/sound/omap-hdmi-audio.h
create mode 100644 sound/soc/omap/omap-hdmi-audio.c
diff --git a/include/sound/omap-hdmi-audio.h b/include/sound/omap-hdmi-audio.h
new file mode 100644
index 000..6c1638c
--- /dev/null
+++ b/include/sound/omap-hdmi-audio.h
@@ -0,0 +1,38 @@
+/*
+ * hdmi-audio.c -- OMAP4+ DSS HDMI audio support library
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Author: Jyri Sarha jsa...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#include video/omapdss.h
+
+#ifndef __OMAP_HDMI_AUDIO_H__
+#define __OMAP_HDMI_AUDIO_H__
+
+/* HDMI audio initalization data */
+struct omap_hdmi_audio_pdata {
+ struct device *dev;
+ enum { OMAP4_HDMI, OMAP5_HDMI } hw_version;
+ phys_addr_t audio_dma_addr;
+ unsigned int audio_dma_req;
+
+ int (*mode_has_audio)(struct device *dev);
+ int (*audio_enable)(struct device *dev, bool enable);
+ int (*audio_start)(struct device *dev, bool enable);
+ int (*audio_config)(struct device *dev,
+ struct omap_dss_audio *dss_audio);
+};
+
+#endif /* __OMAP_HDMI_AUDIO_H__ */
diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index d44463a..66eb428 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -15,6 +15,17 @@ config SND_OMAP_SOC_MCPDM
config SND_OMAP_SOC_HDMI
tristate
+config SND_OMAP_SOC_HDMI_AUDIO
+ tristate HDMI audio support for OMAP4+ based SoCs
+ depends on SND_OMAP_SOC
+ select SND_SOC_HDMI_CODEC
+ select SND_SIMPLE_CARD
+ help
+ The driver implements an integrated ASoC Digital Audio
+ Interface component driver and registers a dummy HDMI codec
+ and asoc-simple-card for full HDMI audio support. OMAPDSS
+ HDMI video needs to be enabled too for working HDMI audio.
+
config SND_OMAP_SOC_N810
tristate SoC Audio support for Nokia N810
depends on SND_OMAP_SOC MACH_NOKIA_N810 I2C
diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
index a725905..40688a6 100644
--- a/sound/soc/omap/Makefile
+++ b/sound/soc/omap/Makefile
@@ -4,12 +4,14 @@ snd-soc-omap-dmic-objs := omap-dmic.o
snd-soc-omap-mcbsp-objs := omap-mcbsp.o mcbsp.o
snd-soc-omap-mcpdm-objs := omap-mcpdm.o
snd-soc-omap-hdmi-objs := omap-hdmi.o
+snd-soc-omap-hdmi-audio-objs := omap-hdmi-audio.o
obj-$(CONFIG_SND_OMAP_SOC) += snd-soc-omap.o
obj-$(CONFIG_SND_OMAP_SOC_DMIC) += snd-soc-omap-dmic.o
obj-$(CONFIG_SND_OMAP_SOC_MCBSP) += snd-soc-omap-mcbsp.o
obj-$(CONFIG_SND_OMAP_SOC_MCPDM) += snd-soc-omap-mcpdm.o
obj-$(CONFIG_SND_OMAP_SOC_HDMI) += snd-soc-omap-hdmi.o
+obj-$(CONFIG_SND_OMAP_SOC_HDMI_AUDIO) += snd-soc-omap-hdmi-audio.o
# OMAP Machine Support
snd-soc-n810-objs := n810.o
diff --git a/sound/soc/omap/omap-hdmi-audio.c b/sound/soc/omap/omap-hdmi-audio.c
new file mode 100644
index 000..4614dce
--- /dev/null
+++ b/sound/soc/omap/omap-hdmi-audio.c
@@ -0,0 +1,379 @@
+/*
+ * omap-hdmi-audio.c -- OMAP4+ DSS HDMI audio support library
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Author: Jyri Sarha jsa...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/err.h
+#include linux/string.h
+#include linux/platform_device.h
+#include sound/soc.h
+#include sound/pcm_params.h
+#include sound/dmaengine_pcm.h
+#include
Re: [PATCH 09/16] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx
On Tue, Sep 16, 2014 at 11:05:40AM +0200, Frans Klaver wrote: On Mon, Sep 15, 2014 at 06:42:04PM +0200, Sebastian Andrzej Siewior wrote: On 09/12/2014 12:28 PM, Frans Klaver wrote: port config is 115200 8N1. I don't recall doing anything special. I boot, login, less file and get a lock. So I booted my mini Debian 7.6 (basic system + openssh) on my beagle bone black which is: [0.00] AM335X ES2.0 (neon ) configured a console, login, invoked less file. The file was shown, I hit on the space key so less shows me more of the file. No lock-up. I tried booting via NFS and MMC. I tried various files with less. My dot config is here https://breakpoint.cc/config-am335x-bb.txt.xz If there is nothing specific to the file you do less on I have no idea what else it could if it is not the config. I'll test your config and go through the differences. So far it looks like it isn't in the config. I've tested both your and my config on debian wheezy on a boneblack. No lock ups. Less doesn't fill my entire screen, so it looks a bit funky when scrolling, but I'm not sure if that's related to the driver. I'll have to look further for things we did that may have impact here. Thanks, Frans ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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/16 v9] omap 8250 based uart + DMA
On 09/15/2014 01:50 PM, Sebastian Andrzej Siewior wrote: I changed the restore function the fix the am335x-evm + less freeze. And now we have this. So let me search… IER was 0 by accident. It fixed in TX path. I pushed uart_v10_pre1 which should have it fixed aport from other things… I am going to address the review comments, to split the DMA callbacks as requested and if nobody comes up with something fancy we will have a v10 :) Regards, Tony Sebastian -- 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] dmaengine: omap-dma: Fix cyclic suspend/resume
When the audio stream is paused or suspended we stop the sDMA and when it
is unpsues/resumed we start the channel without reconfiguring it.
The omap_dma_stop() clears the link configuration when we pause the dma, but
it is not setting it back on start. This will result only one audio buffer
to be played back and the DMA will stop, since the linking is disabled.
The link need to be enabled in omap_dma_start() to make sure that cyclic
transfer can continue.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/omap-dma.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 4cf7d9a950d7..13a02ff87f28 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -280,6 +280,7 @@ static void omap_dma_assign(struct omap_dmadev *od, struct
omap_chan *c,
static void omap_dma_start(struct omap_chan *c, struct omap_desc *d)
{
struct omap_dmadev *od = to_omap_dma_dev(c-vc.chan.device);
+ uint32_t val;
if (__dma_omap15xx(od-plat-dma_attr))
omap_dma_chan_write(c, CPC, 0);
@@ -288,6 +289,17 @@ static void omap_dma_start(struct omap_chan *c, struct
omap_desc *d)
omap_dma_clear_csr(c);
+ if (!__dma_omap15xx(od-plat-dma_attr) c-cyclic) {
+ val = omap_dma_chan_read(c, CLNK_CTRL);
+
+ if (dma_omap1())
+ val = ~(1 14); /* clear the STOP_LNK bit */
+ else
+ val |= CLNK_CTRL_ENABLE_LNK;
+
+ omap_dma_chan_write(c, CLNK_CTRL, val);
+ }
+
/* Enable interrupts */
omap_dma_chan_write(c, CICR, d-cicr);
--
2.1.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] dmaengine: omap-dma: Fix cyclic suspend/resume
On Tue, Sep 16, 2014 at 04:06:25PM +0300, Peter Ujfalusi wrote:
When the audio stream is paused or suspended we stop the sDMA and when it
is unpsues/resumed we start the channel without reconfiguring it.
The omap_dma_stop() clears the link configuration when we pause the dma, but
it is not setting it back on start. This will result only one audio buffer
to be played back and the DMA will stop, since the linking is disabled.
The link need to be enabled in omap_dma_start() to make sure that cyclic
transfer can continue.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/omap-dma.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 4cf7d9a950d7..13a02ff87f28 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -280,6 +280,7 @@ static void omap_dma_assign(struct omap_dmadev *od,
struct omap_chan *c,
static void omap_dma_start(struct omap_chan *c, struct omap_desc *d)
{
struct omap_dmadev *od = to_omap_dma_dev(c-vc.chan.device);
+ uint32_t val;
if (__dma_omap15xx(od-plat-dma_attr))
omap_dma_chan_write(c, CPC, 0);
@@ -288,6 +289,17 @@ static void omap_dma_start(struct omap_chan *c, struct
omap_desc *d)
omap_dma_clear_csr(c);
+ if (!__dma_omap15xx(od-plat-dma_attr) c-cyclic) {
+ val = omap_dma_chan_read(c, CLNK_CTRL);
+
+ if (dma_omap1())
+ val = ~(1 14); /* clear the STOP_LNK bit */
+ else
+ val |= CLNK_CTRL_ENABLE_LNK;
+
+ omap_dma_chan_write(c, CLNK_CTRL, val);
+ }
+
Why is this soo complicated? What's wrong with simply writing the
stored value back from the omap_desc:
omap_dma_chan_write(c, CLNK_CTRL, d-clnk_ctrl);
In fact, rather than loading up the above fast path with stuff which
it really doesn't need, why not do this in the resume path? The
other thing which should be placed in the resume path is a mb() call,
since calling omap_dma_start() won't have a barrier in that path.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
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] dmaengine: omap-dma: Fix cyclic suspend/resume
On 09/16/2014 04:22 PM, Russell King - ARM Linux wrote:
On Tue, Sep 16, 2014 at 04:06:25PM +0300, Peter Ujfalusi wrote:
When the audio stream is paused or suspended we stop the sDMA and when it
is unpsues/resumed we start the channel without reconfiguring it.
The omap_dma_stop() clears the link configuration when we pause the dma, but
it is not setting it back on start. This will result only one audio buffer
to be played back and the DMA will stop, since the linking is disabled.
The link need to be enabled in omap_dma_start() to make sure that cyclic
transfer can continue.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/omap-dma.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 4cf7d9a950d7..13a02ff87f28 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -280,6 +280,7 @@ static void omap_dma_assign(struct omap_dmadev *od,
struct omap_chan *c,
static void omap_dma_start(struct omap_chan *c, struct omap_desc *d)
{
struct omap_dmadev *od = to_omap_dma_dev(c-vc.chan.device);
+uint32_t val;
if (__dma_omap15xx(od-plat-dma_attr))
omap_dma_chan_write(c, CPC, 0);
@@ -288,6 +289,17 @@ static void omap_dma_start(struct omap_chan *c, struct
omap_desc *d)
omap_dma_clear_csr(c);
+if (!__dma_omap15xx(od-plat-dma_attr) c-cyclic) {
+val = omap_dma_chan_read(c, CLNK_CTRL);
+
+if (dma_omap1())
+val = ~(1 14); /* clear the STOP_LNK bit */
+else
+val |= CLNK_CTRL_ENABLE_LNK;
+
+omap_dma_chan_write(c, CLNK_CTRL, val);
+}
+
Why is this soo complicated? What's wrong with simply writing the
stored value back from the omap_desc:
omap_dma_chan_write(c, CLNK_CTRL, d-clnk_ctrl);
Oh, I have overlooked this. Thanks.
In fact, rather than loading up the above fast path with stuff which
it really doesn't need, why not do this in the resume path? The
other thing which should be placed in the resume path is a mb() call,
since calling omap_dma_start() won't have a barrier in that path.
Do you want it as a separate patch (adding the mb() and to restore the
CLNK_CTRL register) or is it OK if I send it as one patch?
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] dmaengine: omap-dma: Fix cyclic suspend/resume
Hi, When the audio is paused/resumed (application paused the sream or board suspend) the audio was only playing back one period worth of data and then stops because the omap_dam_stop() clears the link configuration and it is not restored in start. Also add memory barrier call to resume path since this could happen right after coming out from suspend. Regards, Peter --- Peter Ujfalusi (2): dmaengine: omap-dma: Add memory barrier to dma_resume path dmaengine: omap-dma: Restore the CLINK_CTRL in resume path drivers/dma/omap-dma.c | 5 + 1 file changed, 5 insertions(+) -- 2.1.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
[PATCH v2 1/2] dmaengine: omap-dma: Add memory barrier to dma_resume path
Add mb() call to resume path to ensure the necessary barrier.
Resume can happen after waking up from suspend for example.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/omap-dma.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 4cf7d9a950d7..c01ea505ee7c 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -1017,6 +1017,8 @@ static int omap_dma_resume(struct omap_chan *c)
return -EINVAL;
if (c-paused) {
+ mb();
+
omap_dma_start(c, c-desc);
c-paused = false;
}
--
2.1.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
[PATCH v2 2/2] dmaengine: omap-dma: Restore the CLINK_CTRL in resume path
When the audio stream is paused or suspended we stop the sDMA and when it
is unpaused/resumed we start the channel without reconfiguring it.
The omap_dma_stop() clears the link configuration when we pause the dma, but
it is not setting it back on start. This will result only one audio buffer
to be played back and the DMA will stop, since the linking is disabled.
We need to restore the CLINK_CTRL register in case of resume.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/omap-dma.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index c01ea505ee7c..e0990c505889 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -1019,6 +1019,9 @@ static int omap_dma_resume(struct omap_chan *c)
if (c-paused) {
mb();
+ /* Restore chanel link register */
+ omap_dma_chan_write(c, CLNK_CTRL, c-desc-clnk_ctrl);
+
omap_dma_start(c, c-desc);
c-paused = false;
}
--
2.1.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 v2 2/2] dmaengine: omap-dma: Restore the CLINK_CTRL in resume path
On Tue, Sep 16, 2014 at 04:53:49PM +0300, Peter Ujfalusi wrote:
When the audio stream is paused or suspended we stop the sDMA and when it
is unpaused/resumed we start the channel without reconfiguring it.
The omap_dma_stop() clears the link configuration when we pause the dma, but
it is not setting it back on start. This will result only one audio buffer
to be played back and the DMA will stop, since the linking is disabled.
We need to restore the CLINK_CTRL register in case of resume.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Both of these patches now look good, thanks. For both:
Acked-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/omap-dma.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index c01ea505ee7c..e0990c505889 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -1019,6 +1019,9 @@ static int omap_dma_resume(struct omap_chan *c)
if (c-paused) {
mb();
+ /* Restore chanel link register */
+ omap_dma_chan_write(c, CLNK_CTRL, c-desc-clnk_ctrl);
+
omap_dma_start(c, c-desc);
c-paused = false;
}
--
2.1.0
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] dmaengine: omap-dma: Restore the CLINK_CTRL in resume path
On 09/16/14 15:56, Russell King - ARM Linux wrote:
On Tue, Sep 16, 2014 at 04:53:49PM +0300, Peter Ujfalusi wrote:
When the audio stream is paused or suspended we stop the sDMA and when it
is unpaused/resumed we start the channel without reconfiguring it.
The omap_dma_stop() clears the link configuration when we pause the dma, but
it is not setting it back on start. This will result only one audio buffer
to be played back and the DMA will stop, since the linking is disabled.
We need to restore the CLINK_CTRL register in case of resume.
Signed-off-by: Peter Ujfalusipeter.ujfal...@ti.com
Both of these patches now look good, thanks. For both:
Acked-by: Russell Kingrmk+ker...@arm.linux.org.uk
---
drivers/dma/omap-dma.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index c01ea505ee7c..e0990c505889 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -1019,6 +1019,9 @@ static int omap_dma_resume(struct omap_chan *c)
if (c-paused) {
mb();
+ /* Restore chanel link register */
Just too bad that the comment seems to have a typo.
+ omap_dma_chan_write(c, CLNK_CTRL, c-desc-clnk_ctrl);
+
omap_dma_start(c, c-desc);
c-paused = false;
}
--
2.1.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 v2 1/3] can: c_can_platform: Fix c_can_hw_raminit_ti() and add timeout
On 09/09/2014 04:39 PM, Roger Quadros wrote: On 09/09/2014 05:34 PM, Marc Kleine-Budde wrote: On 09/09/2014 04:31 PM, Roger Quadros wrote: Pass the correct 'mask' and 'value' bits to c_can_hw_raminit_wait_ti(). They seem to have been swapped in the usage instances. Can you split this fix into a seperate patch, please. OK. I've added this fix only to the can-tree. Thanks, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH 09/16] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx
On Tue, Sep 16, 2014 at 02:42:00PM +0200, Frans Klaver wrote: On Tue, Sep 16, 2014 at 11:05:40AM +0200, Frans Klaver wrote: On Mon, Sep 15, 2014 at 06:42:04PM +0200, Sebastian Andrzej Siewior wrote: If there is nothing specific to the file you do less on I have no idea what else it could if it is not the config. I'll test your config and go through the differences. So far it looks like it isn't in the config. I've tested both your and my config on debian wheezy on a boneblack. No lock ups. No, skip that. It is in the config. I'll hunt it down. -- 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 v4 10/11] ARM: OMAP2+: AM33XX: Basic suspend resume support
On Wed, Sep 10, 2014 at 12:10 AM, Kevin Hilman khil...@kernel.org wrote: What I think you need to do (and what I've recommended at least once in earlier reviews) put all the (non-rproc) wkup_m3 IPC into into one driver and create a well-described, well-documented API that the platform PM code will use. IMO, the current split is very difficult to read/understand, which means it will even more difficult to maintain. I strongly agree. A remoteproc driver should generally only register its hardware-specific implementation of the rproc_ops via the remoteproc framework. It is not expected to expose public API of its own - that's why we have the generic remoteproc layer for. It makes perfect sense not to use rpmsg for communications if it's not lightweight enough, but exposing a new set of IPC API should take place in a separate well-documented driver. In addition, the suggested remoteproc driver seems to act both as a low-level hardware-specific driver that plugs into remoteproc (by registering rproc_ops via the remoteproc framework), and also as a high-level driver that utilizes the remoteproc public API (by calling rproc_boot). This alone calls for scrutinizing the design as this is not very intuitive. At least for the remoteproc part: if you could provide a simple and straight-forward remoteproc driver that just implements the rproc_ops, this could be merged very quickly. The rest of the code most probably belongs in a different entity, just like Kevin suggested. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/12] ARM: OMAP2+: Add hwmod flag for HWMOD_RECONFIG_IO_CHAIN
On Mon, 15 Sep 2014, Tony Lindgren wrote: Commit cc824534d4fe (ARM: OMAP2+: hwmod: Rearm wake-up interrupts for DT when MUSB is idled) fixed issues with hung UART wake-up events by calling _reconfigure_io_chain() when MUSB is connected or disconnected. As pointed out by Paul Walmsley, we may need to also call _reconfigure_io_chain() in other cases, so it should be a separate flag. Let's add HWMOD_RECONFIG_IO_CHAIN as suggested by Paul. Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Tony Lindgren t...@atomide.com Reviewed-by: Paul Walmsley p...@pwsan.com Thanks for taking care of this. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 10/11] ARM: OMAP2+: AM33XX: Basic suspend resume support
Hi Ohad, On 09/16/2014 10:08 AM, Ohad Ben-Cohen wrote: On Wed, Sep 10, 2014 at 12:10 AM, Kevin Hilman khil...@kernel.org wrote: What I think you need to do (and what I've recommended at least once in earlier reviews) put all the (non-rproc) wkup_m3 IPC into into one driver and create a well-described, well-documented API that the platform PM code will use. IMO, the current split is very difficult to read/understand, which means it will even more difficult to maintain. I strongly agree. A remoteproc driver should generally only register its hardware-specific implementation of the rproc_ops via the remoteproc framework. It is not expected to expose public API of its own - that's why we have the generic remoteproc layer for. It makes perfect sense not to use rpmsg for communications if it's not lightweight enough, but exposing a new set of IPC API should take place in a separate well-documented driver. In addition, the suggested remoteproc driver seems to act both as a low-level hardware-specific driver that plugs into remoteproc (by registering rproc_ops via the remoteproc framework), and also as a high-level driver that utilizes the remoteproc public API (by calling rproc_boot). This alone calls for scrutinizing the design as this is not very intuitive. The current remoteproc infrastructure automatically calls rproc_boot only as part of the rpmsg/virtio stack (in remoteproc_virtio.c), but since the WkupM3 does not use rpmsg, there is no automatic booting of the WkupM3 processor. This is the reason why rproc_boot is called as part of the WkupM3 driver probe sequence. What are your concerns here, and if you think this is not the right place do invoke rproc_boot, where do you expect it to be called? Also do note that, there is no way at present to retrieve the struct rproc for a given remote processor, to be able to invoke the rproc_boot from a different layer. At least for the remoteproc part: if you could provide a simple and straight-forward remoteproc driver that just implements the rproc_ops, this could be merged very quickly. The rest of the code most probably belongs in a different entity, just like Kevin suggested. Splitting this would still require some kind of notifier from remoteproc for the other layers for them to know that the WkupM3 remote processor has been loaded and booted successfully. This is also done as part of the WkupM3 driver at the moment. regards Suman -- 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 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support
Daniel,
On 09/05/2014 04:18 PM, Nishanth Menon wrote:
Daniel,
On 13:22-20140827, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
On Wednesday 27 August 2014 03:35 PM, Nishanth Menon wrote:
On Wed, Aug 27, 2014 at 2:13 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
+ Daniel (cpuidle maintainer)
[...]
+static int omap_enter_idle_smp(struct cpuidle_device *dev,
+struct cpuidle_driver *drv,
+int index)
+{
+ struct idle_statedata *cx = state_ptr + index;
+ unsigned long flag;
+
+ raw_spin_lock_irqsave(mpu_lock, flag);
+ cx-mpu_state_vote++;
+ if (cx-mpu_state_vote == num_online_cpus()) {
+ pwrdm_set_logic_retst(mpu_pd, cx-mpu_logic_state);
+ omap_set_pwrdm_state(mpu_pd, cx-mpu_state);
+ }
+ raw_spin_unlock_irqrestore(mpu_lock, flag);
+
+ omap4_enter_lowpower(dev-cpu, cx-cpu_state);
+
+ raw_spin_lock_irqsave(mpu_lock, flag);
+ if (cx-mpu_state_vote == num_online_cpus())
+ omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
+ cx-mpu_state_vote--;
+ raw_spin_unlock_irqrestore(mpu_lock, flag);
+
+ return index;
+}
Hmm, maybe OMAP5/DRA7 CPUidle driver should be a new one based on MCPM?
Trying to understand benefit of MCPM here - at least without a deeper
understanding of mcpm infrastructure benefits (first look seemed a
little heavy for OMAP5/DRA7 needs).
Neither DRA7/OMAP5 are multi-cluster, the SoCs are not targetted for
OFF of CPU1/0, we have mercury hardware to help with context and
sync issues.
Being able to reuse most of existing OMAP4 infrastructure code is
useful as well to leave the existing omap4 framework as being lighter
in complexity -esp in a cpuidle like hot path?
The spin_lock is only for the programming of MPU power domain in a
consistent manner - I suppose might have been the trigger for
proposing mcpm?
Mostly not
I think this is coming because last time Nicolas Pitre tried to convert
the OMAP CPUIdle into MCPM but because of various ordering requirements,
OMAP wasn't suitable and then the plan was dropped later.
Just to make clear, OMAP OMAP5/DRA7 as well the ordering requirement
remains the same for deeper states. Its just the mercury retention state
which we are able to enter without ordering requirements and hence
the voting scheme.
Ah, OK. This is the part that I'm missing. So for deeper states you'll
need to be using omap_enter_idle_coupled()
Hope this clarifies to you as well as Kevin just in case he missed the
part of the deeper C-states requirements.
Yes, thanks for clarifying.
That being said, I think MCPM can now do essentially what the coupled
states code is doing. Even so, that's probably not a reason to hold up
this patch, but Daniel gets to make that call.
Gentle ping.. You can find the discussion and the patch here:
https://patchwork.kernel.org/patch/4764661/
Ping on this again.. we are pretty close to approaching v3.18 merge
window and this discussion has'nt gotten further.
--
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
[PATCH 1/4] ARM: dts: cm-t54: add HDMI/DVI display data
Add DSS related pinmux and display data nodes required to support HDMI
and DVI video out on CM-T54.
Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
---
arch/arm/boot/dts/omap5-cm-t54.dts | 158
1 files changed, 158 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-cm-t54.dts
b/arch/arm/boot/dts/omap5-cm-t54.dts
index 429471a..9cb40d6 100644
--- a/arch/arm/boot/dts/omap5-cm-t54.dts
+++ b/arch/arm/boot/dts/omap5-cm-t54.dts
@@ -66,6 +66,69 @@
default-state = off;
};
};
+
+ aliases {
+ display0 = hdmi0;
+ display1 = dvi0;
+ };
+
+ hdmi0: connector@0 {
+ compatible = hdmi-connector;
+ label = hdmi;
+
+ type = a;
+
+ pinctrl-names = default;
+ pinctrl-0 = hdmi_conn_pins;
+
+ hpd-gpios = gpio7 1 GPIO_ACTIVE_HIGH; /* GPIO 193, HPD */
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = hdmi_out;
+ };
+ };
+ };
+
+ tfp410: encoder@0 {
+ compatible = ti,tfp410;
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ tfp410_in: endpoint@0 {
+ remote-endpoint = dpi_dvi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ tfp410_out: endpoint@0 {
+ remote-endpoint = dvi_connector_in;
+ };
+ };
+ };
+ };
+
+ dvi0: connector@1 {
+ compatible = dvi-connector;
+ label = dvi;
+
+ digital;
+
+ ddc-i2c-bus = i2c2;
+
+ port {
+ dvi_connector_in: endpoint {
+ remote-endpoint = tfp410_out;
+ };
+ };
+ };
};
omap5_pmx_core {
@@ -88,6 +151,13 @@
;
};
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins =
+ OMAP5_IOPAD(0x01b8, PIN_INPUT | MUX_MODE0) /* i2c2_scl
*/
+ OMAP5_IOPAD(0x01ba, PIN_INPUT | MUX_MODE0) /* i2c2_sda
*/
+ ;
+ };
+
mmc1_pins: pinmux_mmc1_pins {
pinctrl-single,pins =
OMAP5_IOPAD(0x01e2, PIN_INPUT_PULLUP | MUX_MODE0) /*
sdcard_clk */
@@ -144,6 +214,53 @@
OMAP5_IOPAD(0x00b6, PIN_OUTPUT | MUX_MODE6) /*
hsi2_acdata.gpio3_83 */
;
};
+
+ dss_hdmi_pins: pinmux_dss_hdmi_pins {
+ pinctrl-single,pins =
+ OMAP5_IOPAD(0x013c, PIN_INPUT_PULLUP | MUX_MODE0) /*
hdmi_cec.hdmi_cec */
+ OMAP5_IOPAD(0x0140, PIN_INPUT | MUX_MODE0) /*
hdmi_ddc_scl.hdmi_ddc_scl */
+ OMAP5_IOPAD(0x0142, PIN_INPUT | MUX_MODE0) /*
hdmi_ddc_sda.hdmi_ddc_sda */
+ ;
+ };
+
+ hdmi_conn_pins: pinmux_hdmi_conn_pins {
+ pinctrl-single,pins =
+ OMAP5_IOPAD(0x013e, PIN_INPUT | MUX_MODE6) /*
hdmi_hpd.gpio7_193 */
+ ;
+ };
+
+ dss_dpi_pins: pinmux_dss_dpi_pins {
+ pinctrl-single,pins =
+ OMAP5_IOPAD(0x0104, PIN_OUTPUT | MUX_MODE3) /*
dispc_data15 */
+ OMAP5_IOPAD(0x0106, PIN_OUTPUT | MUX_MODE3) /*
dispc_data14 */
+ OMAP5_IOPAD(0x0108, PIN_OUTPUT | MUX_MODE3) /*
dispc_data13 */
+ OMAP5_IOPAD(0x010a, PIN_OUTPUT | MUX_MODE3) /*
dispc_data12 */
+ OMAP5_IOPAD(0x010c, PIN_OUTPUT | MUX_MODE3) /*
dispc_data11 */
+ OMAP5_IOPAD(0x010e, PIN_OUTPUT | MUX_MODE3) /*
dispc_data10 */
+ OMAP5_IOPAD(0x0110, PIN_OUTPUT | MUX_MODE3) /*
dispc_data9 */
+ OMAP5_IOPAD(0x0112, PIN_OUTPUT | MUX_MODE3) /*
dispc_data8 */
+ OMAP5_IOPAD(0x0114, PIN_OUTPUT | MUX_MODE3) /*
dispc_data7 */
+ OMAP5_IOPAD(0x0116, PIN_OUTPUT | MUX_MODE3) /*
dispc_data6 */
+ OMAP5_IOPAD(0x0118, PIN_OUTPUT | MUX_MODE3) /*
dispc_data5 */
+ OMAP5_IOPAD(0x011a, PIN_OUTPUT | MUX_MODE3) /*
dispc_data4 */
+ OMAP5_IOPAD(0x011c, PIN_OUTPUT | MUX_MODE3) /*
dispc_data3 */
+ OMAP5_IOPAD(0x011e, PIN_OUTPUT | MUX_MODE3) /*
dispc_data2 */
+ OMAP5_IOPAD(0x0120, PIN_OUTPUT | MUX_MODE3) /*
dispc_data1 */
+
[PATCH 4/4] ARM: dts: cm-t54: setup omap_dwc3
Add extcon and vbus-supply properties of DWC3 node.
Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
---
arch/arm/boot/dts/omap5-cm-t54.dts |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-cm-t54.dts
b/arch/arm/boot/dts/omap5-cm-t54.dts
index 9cfcad5..855cb88a 100644
--- a/arch/arm/boot/dts/omap5-cm-t54.dts
+++ b/arch/arm/boot/dts/omap5-cm-t54.dts
@@ -631,6 +631,11 @@
phys = 0 hsusb2_phy hsusb3_phy;
};
+usb3 {
+ extcon = extcon_usb3;
+ vbus-supply = smps10_out1_reg;
+};
+
cpu0 {
cpu0-supply = smps123_reg;
};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: dts: cm-t54: add Startek LCD support
Add DT support for Startek KD050C LCD 800x480 panel.
Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
---
arch/arm/boot/dts/omap5-cm-t54.dts | 44
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-cm-t54.dts
b/arch/arm/boot/dts/omap5-cm-t54.dts
index 9cb40d6..588cc2a 100644
--- a/arch/arm/boot/dts/omap5-cm-t54.dts
+++ b/arch/arm/boot/dts/omap5-cm-t54.dts
@@ -70,8 +70,41 @@
aliases {
display0 = hdmi0;
display1 = dvi0;
+ display2 = lcd0;
};
+ lcd0: display {
+compatible = startek,startek-kd050c, panel-dpi;
+label = lcd;
+
+pinctrl-names = default;
+pinctrl-0 = lcd_pins;
+
+enable-gpios = gpio8 3 GPIO_ACTIVE_HIGH;
+
+panel-timing {
+clock-frequency = 3300;
+hactive = 800;
+vactive = 480;
+hfront-porch = 40;
+hback-porch = 40;
+hsync-len = 43;
+vback-porch = 29;
+vfront-porch = 13;
+vsync-len = 3;
+hsync-active = 0;
+vsync-active = 0;
+de-active = 1;
+pixelclk-active = 1;
+};
+
+port {
+lcd_in: endpoint {
+remote-endpoint = dpi_lcd_out;
+};
+};
+};
+
hdmi0: connector@0 {
compatible = hdmi-connector;
label = hdmi;
@@ -223,6 +256,12 @@
;
};
+ lcd_pins: pinmux_lcd_pins {
+ pinctrl-single,pins =
+ OMAP5_IOPAD(0x0172, PIN_OUTPUT_PULLDOWN | MUX_MODE6) /*
timer11_pwm_evt.gpio8_227 */
+ ;
+ };
+
hdmi_conn_pins: pinmux_hdmi_conn_pins {
pinctrl-single,pins =
OMAP5_IOPAD(0x013e, PIN_INPUT | MUX_MODE6) /*
hdmi_hpd.gpio7_193 */
@@ -546,6 +585,11 @@
remote-endpoint = tfp410_in;
data-lines = 24;
};
+
+ dpi_lcd_out: endpoint@1 {
+ remote-endpoint = lcd_in;
+ data-lines = 24;
+ };
};
};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: dts: cm-t54: add ADS7846 touchscreen support
Add ADS7846 touchscreen support.
Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
---
arch/arm/boot/dts/omap5-cm-t54.dts | 61
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-cm-t54.dts
b/arch/arm/boot/dts/omap5-cm-t54.dts
index 588cc2a..9cfcad5 100644
--- a/arch/arm/boot/dts/omap5-cm-t54.dts
+++ b/arch/arm/boot/dts/omap5-cm-t54.dts
@@ -45,6 +45,13 @@
enable-active-high;
};
+ ads7846reg: ads7846-reg {
+ compatible = regulator-fixed;
+ regulator-name = ads7846-reg;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ };
+
/* HS USB Host PHY on PORT 2 */
hsusb2_phy: hsusb2_phy {
compatible = usb-nop-xceiv;
@@ -164,6 +171,15 @@
};
};
+omap5_pmx_wkup {
+
+ ads7846_pins: pinmux_ads7846_pins {
+ pinctrl-single,pins =
+ 0x02 (PIN_INPUT_PULLDOWN | MUX_MODE6) /*
llib_wakereqin.gpio1_wk15 */
+ ;
+ };
+};
+
omap5_pmx_core {
pinctrl-names = default;
pinctrl-0 =
@@ -300,6 +316,51 @@
OMAP5_IOPAD(0x013a, PIN_OUTPUT | MUX_MODE3) /*
dispc_data23 */
;
};
+
+ mcspi2_pins: pinmux_mcspi1_pins {
+ pinctrl-single,pins =
+ OMAP5_IOPAD(0x00fc, PIN_INPUT | MUX_MODE0) /*
mcspi2_clk.mcspi2_clk */
+ OMAP5_IOPAD(0x00fe, PIN_INPUT | MUX_MODE0) /*
mcspi2_simo.mcspi2_simo */
+ OMAP5_IOPAD(0x0100, PIN_INPUT | MUX_MODE0) /*
mcspi2_somi.mcspi2_somi */
+ OMAP5_IOPAD(0x0102, PIN_INPUT | MUX_MODE0) /*
mcspi2_cs0.mcspi2_cs0 */
+ ;
+ };
+};
+
+mcspi2 {
+ pinctrl-names = default;
+ pinctrl-0 = mcspi2_pins;
+
+ /* touch controller */
+ ads7846@0 {
+ pinctrl-names = default;
+ pinctrl-0 = ads7846_pins;
+
+ compatible = ti,ads7846;
+ vcc-supply = ads7846reg;
+
+ reg = 0; /* CS0 */
+ spi-max-frequency = 150;
+
+ interrupt-parent = gpio1;
+ interrupts = 15 0;/* gpio1_wk15 */
+ pendown-gpio = gpio1 15 0;
+
+
+ ti,x-min = /bits/ 16 0x0;
+ ti,x-max = /bits/ 16 0x0fff;
+ ti,y-min = /bits/ 16 0x0;
+ ti,y-max = /bits/ 16 0x0fff;
+
+ ti,x-plate-ohms = /bits/ 16 180;
+ ti,pressure-max = /bits/ 16 255;
+
+ ti,debounce-max = /bits/ 16 30;
+ ti,debounce-tol = /bits/ 16 10;
+ ti,debounce-rep = /bits/ 16 1;
+
+ linux,wakeup;
+ };
};
mmc1 {
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] ARM: dts: cm-t54: enable video out, touchscreen and USB3.0
Add CM-T54 DT nodes: * enable HDMI/DVI/LCD video output support * add ADS7846 touchscreen support * enchance DWC3 setup to enable power supply for USB3.0 OTG port Dmitry Lifshitz (4): ARM: dts: cm-t54: add HDMI/DVI display data ARM: dts: cm-t54: add Startek LCD support ARM: dts: cm-t54: add ADS7846 touchscreen support ARM: dts: cm-t54: setup omap_dwc3 arch/arm/boot/dts/omap5-cm-t54.dts | 268 1 files changed, 268 insertions(+), 0 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: dts: cm-t54: add HDMI/DVI display data
On 09/16/2014 11:35 AM, Dmitry Lifshitz wrote:
Add DSS related pinmux and display data nodes required to support HDMI
and DVI video out on CM-T54.
Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
---
arch/arm/boot/dts/omap5-cm-t54.dts | 158
1 files changed, 158 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-cm-t54.dts
b/arch/arm/boot/dts/omap5-cm-t54.dts
index 429471a..9cb40d6 100644
--- a/arch/arm/boot/dts/omap5-cm-t54.dts
+++ b/arch/arm/boot/dts/omap5-cm-t54.dts
@@ -66,6 +66,69 @@
default-state = off;
};
};
+
+ aliases {
+ display0 = hdmi0;
+ display1 = dvi0;
+ };
Should probably maintain all the aliases in one place at the top of
the dts?
+
+ hdmi0: connector@0 {
+ compatible = hdmi-connector;
+ label = hdmi;
+
+ type = a;
+
+ pinctrl-names = default;
+ pinctrl-0 = hdmi_conn_pins;
+
+ hpd-gpios = gpio7 1 GPIO_ACTIVE_HIGH; /* GPIO 193, HPD */
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = hdmi_out;
+ };
+ };
+ };
+
+ tfp410: encoder@0 {
+ compatible = ti,tfp410;
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ tfp410_in: endpoint@0 {
+ remote-endpoint = dpi_dvi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ tfp410_out: endpoint@0 {
+ remote-endpoint = dvi_connector_in;
+ };
+ };
+ };
+ };
+
+ dvi0: connector@1 {
+ compatible = dvi-connector;
+ label = dvi;
+
+ digital;
+
+ ddc-i2c-bus = i2c2;
+
+ port {
+ dvi_connector_in: endpoint {
+ remote-endpoint = tfp410_out;
+ };
+ };
+ };
};
omap5_pmx_core {
@@ -88,6 +151,13 @@
;
};
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins =
+ OMAP5_IOPAD(0x01b8, PIN_INPUT | MUX_MODE0) /* i2c2_scl
*/
+ OMAP5_IOPAD(0x01ba, PIN_INPUT | MUX_MODE0) /* i2c2_sda
*/
+ ;
+ };
+
mmc1_pins: pinmux_mmc1_pins {
pinctrl-single,pins =
OMAP5_IOPAD(0x01e2, PIN_INPUT_PULLUP | MUX_MODE0) /*
sdcard_clk */
@@ -144,6 +214,53 @@
OMAP5_IOPAD(0x00b6, PIN_OUTPUT | MUX_MODE6) /*
hsi2_acdata.gpio3_83 */
;
};
+
+ dss_hdmi_pins: pinmux_dss_hdmi_pins {
+ pinctrl-single,pins =
+ OMAP5_IOPAD(0x013c, PIN_INPUT_PULLUP | MUX_MODE0) /*
hdmi_cec.hdmi_cec */
+ OMAP5_IOPAD(0x0140, PIN_INPUT | MUX_MODE0) /*
hdmi_ddc_scl.hdmi_ddc_scl */
+ OMAP5_IOPAD(0x0142, PIN_INPUT | MUX_MODE0) /*
hdmi_ddc_sda.hdmi_ddc_sda */
+ ;
+ };
+
+ hdmi_conn_pins: pinmux_hdmi_conn_pins {
+ pinctrl-single,pins =
+ OMAP5_IOPAD(0x013e, PIN_INPUT | MUX_MODE6) /*
hdmi_hpd.gpio7_193 */
+ ;
+ };
+
+ dss_dpi_pins: pinmux_dss_dpi_pins {
+ pinctrl-single,pins =
+ OMAP5_IOPAD(0x0104, PIN_OUTPUT | MUX_MODE3) /*
dispc_data15 */
+ OMAP5_IOPAD(0x0106, PIN_OUTPUT | MUX_MODE3) /*
dispc_data14 */
+ OMAP5_IOPAD(0x0108, PIN_OUTPUT | MUX_MODE3) /*
dispc_data13 */
+ OMAP5_IOPAD(0x010a, PIN_OUTPUT | MUX_MODE3) /*
dispc_data12 */
+ OMAP5_IOPAD(0x010c, PIN_OUTPUT | MUX_MODE3) /*
dispc_data11 */
+ OMAP5_IOPAD(0x010e, PIN_OUTPUT | MUX_MODE3) /*
dispc_data10 */
+ OMAP5_IOPAD(0x0110, PIN_OUTPUT | MUX_MODE3) /*
dispc_data9 */
+ OMAP5_IOPAD(0x0112, PIN_OUTPUT | MUX_MODE3) /*
dispc_data8 */
+ OMAP5_IOPAD(0x0114, PIN_OUTPUT | MUX_MODE3) /*
dispc_data7 */
+ OMAP5_IOPAD(0x0116, PIN_OUTPUT | MUX_MODE3) /*
dispc_data6 */
+ OMAP5_IOPAD(0x0118, PIN_OUTPUT | MUX_MODE3) /*
dispc_data5 */
+ OMAP5_IOPAD(0x011a, PIN_OUTPUT | MUX_MODE3) /*
dispc_data4 */
+ OMAP5_IOPAD(0x011c, PIN_OUTPUT | MUX_MODE3) /*
dispc_data3 */
+ OMAP5_IOPAD(0x011e, PIN_OUTPUT | MUX_MODE3) /*
dispc_data2 */
+
Re: [PATCH 00/16 v9] omap 8250 based uart + DMA
* Sebastian Andrzej Siewior bige...@linutronix.de [140916 05:58]: On 09/15/2014 01:50 PM, Sebastian Andrzej Siewior wrote: I changed the restore function the fix the am335x-evm + less freeze. And now we have this. So let me search… IER was 0 by accident. It fixed in TX path. I pushed uart_v10_pre1 which should have it fixed aport from other things… Just verified that works for my off-idle test case thanks. I am going to address the review comments, to split the DMA callbacks as requested and if nobody comes up with something fancy we will have a v10 :) OK 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 09/16] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx
On 09/15/2014 07:01 PM, Sebastian Andrzej Siewior wrote: On 09/11/2014 04:35 PM, Peter Hurley wrote: I do need to find out if omap hardware sets UART_MSR_DCTS when auto CTS is on. Would you mind running the debug patch below with HW flow control on? I didn't forget about this. However I told minicom to use hardware flow control (and I see the driver set the HW bit) but I haven't seen that uart_handle_cts_change() has been invoked at all. I'm going to check two other boards and report then. No, I don't get into this at all function. So I connected my am335x-evm with beagle board xm because both of them have an old fashion UART connector (instead those uart-to-usb). Both configured with HW-Flow and I haven't seen the function invoked but I saw port-icount.overrun being incremented. This shouldn't happen. So I am a little puzzled here… Regards, Peter Hurley Sebastian -- 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 02/12] ARM: OMAP3: Use force-idle for UARTs because of DMA errata
Hi
A few comments
On Mon, 15 Sep 2014, Tony Lindgren wrote:
In sprz318f.pdf Usage Note 2.7 says that UARTs cannot acknowledge
idle requests in smartidle mode when configured for DMA operations.
I don't have Rev. F here. But reading between the typos in Rev. E, all it
says that the UART should be placed into force-idle mode when there are no
DMA transfers scheduled, otherwise CORE won't go idle. However, this
patch does a lot more than that...
This prevents L4 from going idle. So let's use force-idle mode
instead and also force reconfiguring of the IO chain wake-up events.
Otherwise systems using Sebastian's 8250 patches with DMA will
never enter deeper idle states because of the errata above.
Cc: Paul Walmsley p...@pwsan.com
Cc: Sebastian Andrzej Siewior bige...@linutronix.de
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 61cd49d..55f088c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -490,7 +490,9 @@ static struct omap_hwmod omap3xxx_uart1_hwmod = {
.mpu_irqs = omap2_uart1_mpu_irqs,
.sdma_reqs = omap2_uart1_sdma_reqs,
.main_clk = uart1_fck,
- .flags = DEBUG_TI81XXUART1_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
+ .flags = DEBUG_TI81XXUART1_FLAGS |
+ HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE |
+ HWMOD_FORCE_MSTANDBY | HWMOD_RECONFIG_IO_CHAIN,
... this patch makes four significant changes to the hwmod flags:
1. It changes HWMOD_SWSUP_SIDLE_ACT to HWMOD_SWSUP_SIDLE
2. It adds HWMOD_NO_OCP_AUTOIDLE
3. It adds HWMOD_FORCE_MSTANDBY
4. It adds HWMOD_RECONFIG_IO_CHAIN
As far as I can tell, the only change that actually matches the erratum
usage note is #1. And even that should only be activated when the UART is
in DMA mode.. PIO mode shouldn't need it. (We used to have a DMA-specific
workaround in the driver code for this years ago, which was only enabled
when DMA was used, but it got ripped out in the rush to get rid of the
platform_data function pointers.)
So that leaves the other three flag changes. Of those three, adding
HWMOD_FORCE_MSTANDBY is definitely not correct according to the 34xx
public TRM Rev. ZV, since the UART IP blocks:
a) have no master port,
b) do not contain DMA controllers (they rely on the SDMA), and
c) according to the SYSC_REG register documentation in Table 17-112 of the
above TRM, have no MIDLEMODE bit field.
So adding HWMOD_FORCE_MSTANDBY should have zero effect and it most likely
should be dropped.
Regarding the rest:
I'd be pretty surprised if HWMOD_RECONFIG_IO_CHAIN is needed. If that was
needed, I'd think we would have seen wakeup failures in this path a long
time ago, since the console serial port is the primary debug tool we used
for waking the chip up from deep idle states on demand.
As far as HWMOD_NO_OCP_AUTOIDLE goes: does adding this flag have an effect
when HWMOD_SWSUP_SIDLE is used? If so then this should probably go in as
a separate patch, because it's probably a separate bug than the one
described in the commit message.
...
So I'd suggest restricting this patch to simply change
HWMOD_SWSUP_SIDLE_ACT to HWMOD_SWSUP_SIDLE. Then if the other flags are
needed, would suggest adding them in separate patches, describing what
problems are fixed by adding them.
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/16] tty: serial: Add 8250-core based omap driver
On 09/11/2014 01:57 PM, Peter Hurley wrote:
Hi Sebastian,
Hi Peter,
Nice work. Minor comments within.
Thanks.
After this is merged, it may be worth investigating how to use Yoshihiro's
newly-added 8250-based tunable RX trigger interface for omap.
We need to overwrite the FCR callback. First because we can support
trigger levels 1…64 and it it split across two registers and second
because a change here results also in different DMA attributes.
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -0,0 +1,911 @@
+/*
+ * 8250-core based driver for the OMAP internal UART
+ *
+ * Copyright (C) 2014 Sebastian Andrzej Siewior
+ * based on omap-serial.c, Copyright (C) 2010 Texas Instruments.
or something like that, since this is (partly) based on omap-serial.c
of course.
+ *
+ */
+
…
+/*
+ * Ask the core to calculate the divisor for us.
+ */
+baud = uart_get_baud_rate(port, termios, old,
+port-uartclk / 16 / 0x,
+port-uartclk / 13);
+omap_8250_get_divisor(port, baud, priv);
+
+/*
+ * Ok, we're now changing the port state. Do it with
+ * interrupts disabled.
+ */
+pm_runtime_get_sync(port-dev);
+spin_lock_irqsave(port-lock, flags);
^^^
spin_lock_irq(port-lock);
The serial core calls the -set_termios() method with interrupts enabled.
Okay, this could work.
+
+/*
+ * Update the per-port timeout.
+ */
+uart_update_timeout(port, termios-c_cflag, baud);
+
+up-port.read_status_mask = UART_LSR_OE | UART_LSR_THRE | UART_LSR_DR;
+if (termios-c_iflag INPCK)
+up-port.read_status_mask |= UART_LSR_FE | UART_LSR_PE;
+if (termios-c_iflag (BRKINT | PARMRK))
^
IGNBRK |
Otherwise, the read_status_mask will mask out the BI condition, so
uart_insert_char() will send '\0' byte as TTY_NORMAL.
The 8250 and omap RX path differed so the omap driver didn't need this
change, whereas the 8250 driver does.
Updated.
+up-port.read_status_mask |= UART_LSR_BI;
+
+/*
…
+
+priv-efr = 0;
+if (termios-c_cflag CRTSCTS up-port.flags UPF_HARD_FLOW) {
+/* Enable AUTORTS and AUTOCTS */
+priv-efr |= UART_EFR_CTS | UART_EFR_RTS;
+
+/* Ensure MCR RTS is asserted */
+up-mcr |= UART_MCR_RTS;
+}
+
+if (up-port.flags UPF_SOFT_FLOW) {
I'm aware that this is basically from the omap driver but can someone clear
up if omap hardware can actually do UPF_HARD_FLOW and UPF_SOFT_FLOW
simultaneously? The datasheets that I've looked at say no.
The one that I have here for am335x says:
The UART module can use hardware or software flow control to manage
transmission and reception.
So yes, you are right about this. I changed this to do UPF_HARD_FLOW if
possible + else UPF_SOFT_FLOW.
Regards,
Peter Hurley
Sebastian
--
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
OMAP baseline test results for v3.17-rc5
Here are some basic OMAP test results for Linux v3.17-rc5. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.17-rc5/20140916100200/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Boot to userspace: FAIL ( 2/17): 2430sdp, 5430es2sbct54 skip ( 1/17): 5912osk Pass (14/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3517evm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 8/12): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 3530es3beagle, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 4/12): 37xxevm, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off except CORE via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 1/ 4): 3530es3beagle Pass ( 3/ 4): 37xxevm, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: FAIL ( 1/ 4): 3530es3beagle Pass ( 3/ 4): 37xxevm, 3530es31beagle, 3730es12beaglexm vmlinux object size (delta in bytes from test_v3.17-rc4 (2ce7598c9a453e0acd0e07be7be3f5eb39608ebd)): text data bsstotal kernel +1980 +400+2020 omap1_defconfig +1980 -160+1964 omap1_defconfig_1510innovator_only +1980 +400+2020 omap1_defconfig_5912osk_only +1964 +720+2036 multi_v7_defconfig +1172 +160+1188 omap2plus_defconfig +1212 +160+1228 omap2plus_defconfig_2430sdp_only +1172 -480+1124 omap2plus_defconfig_am33xx_only +1236 -480+1188 omap2plus_defconfig_am43xx_only +1172 -800+1092 omap2plus_defconfig_cpupm +1172 +240+1196 omap2plus_defconfig_dra7xx_only +576 -400 +536 omap2plus_defconfig_n800_multi_omap2xxx +544 -400 +504 omap2plus_defconfig_n800_only_a +1236 -80+1228 omap2plus_defconfig_no_pm +1236 -80+1228 omap2plus_defconfig_omap2_4_only +1172 +160+1188 omap2plus_defconfig_omap3_4_only +1172 -80+1164 omap2plus_defconfig_omap5_only +516 +16 +16 +548 rmk_omap3430_ldp_allnoconfig +960 -640 +896 rmk_omap3430_ldp_oldconfig +548 +12 -16 +544 rmk_omap4430_sdp_allnoconfig +1024 -640 +960 rmk_omap4430_sdp_oldconfig Boot-time memory difference (delta in bytes from test_v3.17-rc4 (2ce7598c9a453e0acd0e07be7be3f5eb39608ebd)) avail rsrvd high freed board kconfig 4k-4k . . 2420n800 omap2plus_defconfig_n800_only_a -8k 8k . . am335xbone omap2plus_defconfig_am33xx_only -224884k -36236k . -404k am335xbonelt omap2plus_defconfig am335xbonelt has been switched to using the
Re: [PATCH 02/12] ARM: OMAP3: Use force-idle for UARTs because of DMA errata
* Paul Walmsley p...@pwsan.com [140916 10:01]:
On Mon, 15 Sep 2014, Tony Lindgren wrote:
In sprz318f.pdf Usage Note 2.7 says that UARTs cannot acknowledge
idle requests in smartidle mode when configured for DMA operations.
I don't have Rev. F here. But reading between the typos in Rev. E, all it
says that the UART should be placed into force-idle mode when there are no
DMA transfers scheduled, otherwise CORE won't go idle. However, this
patch does a lot more than that...
OK. The errata above seems to have a bit more info on that.
@@ -490,7 +490,9 @@ static struct omap_hwmod omap3xxx_uart1_hwmod = {
.mpu_irqs = omap2_uart1_mpu_irqs,
.sdma_reqs = omap2_uart1_sdma_reqs,
.main_clk = uart1_fck,
- .flags = DEBUG_TI81XXUART1_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
+ .flags = DEBUG_TI81XXUART1_FLAGS |
+ HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE |
+ HWMOD_FORCE_MSTANDBY | HWMOD_RECONFIG_IO_CHAIN,
... this patch makes four significant changes to the hwmod flags:
1. It changes HWMOD_SWSUP_SIDLE_ACT to HWMOD_SWSUP_SIDLE
2. It adds HWMOD_NO_OCP_AUTOIDLE
3. It adds HWMOD_FORCE_MSTANDBY
4. It adds HWMOD_RECONFIG_IO_CHAIN
As far as I can tell, the only change that actually matches the erratum
usage note is #1. And even that should only be activated when the UART is
in DMA mode.. PIO mode shouldn't need it. (We used to have a DMA-specific
workaround in the driver code for this years ago, which was only enabled
when DMA was used, but it got ripped out in the rush to get rid of the
platform_data function pointers.)
Indeed that's the case. Only #1 above is needed.
It seems I intially just blindly copied the MUSB related changes for
UART to get Sebastian's series going with DMA, then just rebased those
changes blindly on the HWMOD_RECONFIG_IO_CHAIN patch.
For toggling the DMA vs PIO mode, that should be done with some Linux
generic API from the driver. But since we don't have that, I don't think
there's much overhead for always configuring for DMA mode. Or do you
see some issues with that?
So that leaves the other three flag changes. Of those three, adding
HWMOD_FORCE_MSTANDBY is definitely not correct according to the 34xx
public TRM Rev. ZV, since the UART IP blocks:
a) have no master port,
b) do not contain DMA controllers (they rely on the SDMA), and
c) according to the SYSC_REG register documentation in Table 17-112 of the
above TRM, have no MIDLEMODE bit field.
So adding HWMOD_FORCE_MSTANDBY should have zero effect and it most likely
should be dropped.
OK. That's left over from blind copy-paste from MUSB related changes and
not needed.
Regarding the rest:
I'd be pretty surprised if HWMOD_RECONFIG_IO_CHAIN is needed. If that was
needed, I'd think we would have seen wakeup failures in this path a long
time ago, since the console serial port is the primary debug tool we used
for waking the chip up from deep idle states on demand.
OK. Does not seem to be needed.
As far as HWMOD_NO_OCP_AUTOIDLE goes: does adding this flag have an effect
when HWMOD_SWSUP_SIDLE is used? If so then this should probably go in as
a separate patch, because it's probably a separate bug than the one
described in the commit message.
That does not seem to be needed either.
So I'd suggest restricting this patch to simply change
HWMOD_SWSUP_SIDLE_ACT to HWMOD_SWSUP_SIDLE. Then if the other flags are
needed, would suggest adding them in separate patches, describing what
problems are fixed by adding them.
Yes great. I've verified that's enough to make it work properly with off-idle
and dma when tested against Sebastian's uart_v10_pre1 branch.
Updated patch below, thanks for catching the bogus configuration.
Regards,
Tony
8 --
From: Tony Lindgren t...@atomide.com
Date: Wed, 10 Sep 2014 16:22:31 -0700
Subject: [PATCH] ARM: OMAP3: Use manual idle for UARTs because of DMA errata
In sprz318f.pdf Usage Note 2.7 says that UARTs cannot acknowledge
idle requests in smartidle mode when configured for DMA operations.
This prevents L4 from going idle. So let's use manual idle mode
instead.
Otherwise systems using Sebastian's 8250 patches with DMA will
never enter deeper idle states because of the errata above.
Cc: Paul Walmsley p...@pwsan.com
Cc: Sebastian Andrzej Siewior bige...@linutronix.de
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -490,7 +490,7 @@ static struct omap_hwmod omap3xxx_uart1_hwmod = {
.mpu_irqs = omap2_uart1_mpu_irqs,
.sdma_reqs = omap2_uart1_sdma_reqs,
.main_clk = uart1_fck,
- .flags = DEBUG_TI81XXUART1_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
+ .flags = DEBUG_TI81XXUART1_FLAGS | HWMOD_SWSUP_SIDLE,
.prcm = {
[PATCHv2] rpmsg: compute number of buffers to allocate from vrings
The buffers to be used for communication are allocated during the
rpmsg virtio driver's probe, and the total number of buffers is
currently hard-coded to 512. The vring configuration can vary from
one platform to another or between different remote processors. The
setup of the receive buffers will throw a WARN_ON if the associated
vrings are configured with less than 256 buffers (in each direction).
So, adjust this hard-coded value to rely on the number of buffers the
virtqueue vring is setup with, but also limit to use 256 buffers at
most in each direction to avoid wacky resource tables consuming up
unreasonable memory.
NOTE: The number of buffers is already assumed to be symmetrical
in each direction, and that logic is not unchanged.
Signed-off-by: Suman Anna s-a...@ti.com
---
v2 changes:
- add upper limit on buffers and update comments
- revise patch description
drivers/rpmsg/virtio_rpmsg_bus.c | 46
1 file changed, 32 insertions(+), 14 deletions(-)
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index b6135d4..9ea6c43 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -41,6 +41,7 @@
* @svq: tx virtqueue
* @rbufs: kernel address of rx buffers
* @sbufs: kernel address of tx buffers
+ * @num_bufs: total number of buffers for rx and tx
* @last_sbuf: index of last tx buffer used
* @bufs_dma: dma base addr of the buffers
* @tx_lock: protects svq, sbufs and sleepers, to allow concurrent senders.
@@ -60,6 +61,7 @@ struct virtproc_info {
struct virtio_device *vdev;
struct virtqueue *rvq, *svq;
void *rbufs, *sbufs;
+ unsigned int num_bufs;
int last_sbuf;
dma_addr_t bufs_dma;
struct mutex tx_lock;
@@ -86,13 +88,14 @@ struct rpmsg_channel_info {
#define to_rpmsg_driver(d) container_of(d, struct rpmsg_driver, drv)
/*
- * We're allocating 512 buffers of 512 bytes for communications, and then
- * using the first 256 buffers for RX, and the last 256 buffers for TX.
+ * We're allocating buffers of 512 bytes each for communications. The
+ * number of buffers are computed from the number of buffers supported by
+ * the virtqueue vring (upto a maximum of 256 buffers in each direction).
*
* Each buffer will have 16 bytes for the msg header and 496 bytes for
* the payload.
*
- * This will require a total space of 256KB for the buffers.
+ * This will utilize a maximum total space of 256KB for the buffers.
*
* We might also want to add support for user-provided buffers in time.
* This will allow bigger buffer size flexibility, and can also be used
@@ -102,9 +105,8 @@ struct rpmsg_channel_info {
* can change this without changing anything in the firmware of the remote
* processor.
*/
-#define RPMSG_NUM_BUFS (512)
+#define MAX_RPMSG_NUM_BUFS (256)
#define RPMSG_BUF_SIZE (512)
-#define RPMSG_TOTAL_BUF_SPACE (RPMSG_NUM_BUFS * RPMSG_BUF_SIZE)
/*
* Local addresses are dynamically allocated on-demand.
@@ -579,7 +581,7 @@ static void *get_a_tx_buf(struct virtproc_info *vrp)
* either pick the next unused tx buffer
* (half of our buffers are used for sending messages)
*/
- if (vrp-last_sbuf RPMSG_NUM_BUFS / 2)
+ if (vrp-last_sbuf vrp-num_bufs / 2)
ret = vrp-sbufs + RPMSG_BUF_SIZE * vrp-last_sbuf++;
/* or recycle a used one */
else
@@ -948,6 +950,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
struct virtproc_info *vrp;
void *bufs_va;
int err = 0, i;
+ size_t total_buf_space;
vrp = kzalloc(sizeof(*vrp), GFP_KERNEL);
if (!vrp)
@@ -968,10 +971,24 @@ static int rpmsg_probe(struct virtio_device *vdev)
vrp-rvq = vqs[0];
vrp-svq = vqs[1];
+ vrp-num_bufs = MAX_RPMSG_NUM_BUFS * 2;
+ if (virtqueue_get_vring_size(vrp-rvq) MAX_RPMSG_NUM_BUFS) {
+ /*
+* Override if the virtqueues are configured with less number of
+* buffers. We expect equal number of buffers for each direction
+* as per current code, so throw a warning if the configuration
+* doesn't match.
+*/
+ vrp-num_bufs = virtqueue_get_vring_size(vrp-rvq) * 2;
+ WARN_ON(virtqueue_get_vring_size(vrp-svq) !=
+ (vrp-num_bufs / 2));
+ }
+ total_buf_space = vrp-num_bufs * RPMSG_BUF_SIZE;
+
/* allocate coherent memory for the buffers */
bufs_va = dma_alloc_coherent(vdev-dev.parent-parent,
- RPMSG_TOTAL_BUF_SPACE,
- vrp-bufs_dma, GFP_KERNEL);
+total_buf_space, vrp-bufs_dma,
+GFP_KERNEL);
if (!bufs_va) {
err = -ENOMEM;
goto vqs_del;
@@ -984,10 +1001,10 @@
[PATCH v3 0/2] dmaengine: omap-dma: Fix cyclic suspend/resume
Hi, Changes since v2: - fix typo in patch two - Acked-by added from Russell When the audio is paused/resumed (application paused the sream or board suspend) the audio was only playing back one period worth of data and then stops because the omap_dam_stop() clears the link configuration and it is not restored in start. Also add memory barrier call to resume path since this could happen right after coming out from suspend. Regards, Peter --- Peter Ujfalusi (2): dmaengine: omap-dma: Add memory barrier to dma_resume path dmaengine: omap-dma: Restore the CLINK_CTRL in resume path drivers/dma/omap-dma.c | 5 + 1 file changed, 5 insertions(+) -- 2.1.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
[PATCH v3 1/2] dmaengine: omap-dma: Add memory barrier to dma_resume path
Add mb() call to resume path to ensure the necessary barrier.
Resume can happen after waking up from suspend for example.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/omap-dma.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 4cf7d9a950d7..c01ea505ee7c 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -1017,6 +1017,8 @@ static int omap_dma_resume(struct omap_chan *c)
return -EINVAL;
if (c-paused) {
+ mb();
+
omap_dma_start(c, c-desc);
c-paused = false;
}
--
2.1.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
[PATCH v3 2/2] dmaengine: omap-dma: Restore the CLINK_CTRL in resume path
When the audio stream is paused or suspended we stop the sDMA and when it
is unpaused/resumed we start the channel without reconfiguring it.
The omap_dma_stop() clears the link configuration when we pause the dma, but
it is not setting it back on start. This will result only one audio buffer
to be played back and the DMA will stop, since the linking is disabled.
We need to restore the CLINK_CTRL register in case of resume.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/omap-dma.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index c01ea505ee7c..bbea8243f9e8 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -1019,6 +1019,9 @@ static int omap_dma_resume(struct omap_chan *c)
if (c-paused) {
mb();
+ /* Restore channel link register */
+ omap_dma_chan_write(c, CLNK_CTRL, c-desc-clnk_ctrl);
+
omap_dma_start(c, c-desc);
c-paused = false;
}
--
2.1.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
[PATCHv2 0/2] couple of generic remoteproc enhancements
Hi Ohad, The following is an updated patchset addressing the review comments on v1. The patches are mainly developed to support the WkupM3 remote processor driver on TI AM335x/AM437x SoCs. The patches are rebased onto 3.17-rc3 (rc independent actually). I haven't made any major updates to Patch2 with respect to the ioremap vs defining a CMA region, as the latter is irrelevant for mapping these internal RAMs. Following are the main changes in v2: - Add explicit setting of the .has_iommu field in each of the existing remoteproc platform drivers (Patch 1) - Update patch description to add the usecase details for the change summary (Patch1) - Fixed a minor checkpatch warning (Patch 2). regards Suman v1: http://marc.info/?l=linux-omapm=140483657604924w=2 Suman Anna (2): remoteproc: use a flag to detect the presence of IOMMU remoteproc: add support to handle internal memories drivers/remoteproc/da8xx_remoteproc.c | 1 + drivers/remoteproc/omap_remoteproc.c | 5 ++ drivers/remoteproc/remoteproc_core.c | 98 ++- drivers/remoteproc/ste_modem_rproc.c | 1 + include/linux/remoteproc.h| 45 +++- 5 files changed, 135 insertions(+), 15 deletions(-) -- 2.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 2/2] remoteproc: add support to handle internal memories
A remote processor may need to load certain firmware sections into
internal memories (eg: RAM at L1 or L2 levels) for performance or
other reasons. Introduce a new resource type (RSC_INTMEM) and add
an associated handler function to handle such memories. The handler
creates a kernel mapping for the resource's 'pa' (physical address).
Note that no iommu mapping is performed for this resource, as the
resource is primarily used to represent physical internal memories.
If the internal memory region can only be accessed through an iommu,
a devmem resource entry should be used instead.
Signed-off-by: Robert Tivy rt...@ti.com
Signed-off-by: Suman Anna s-a...@ti.com
---
v2:
- fixed a minor checkpatch warning
drivers/remoteproc/remoteproc_core.c | 83 +++-
include/linux/remoteproc.h | 43 ++-
2 files changed, 124 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 11cdb11..1d668e5 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -664,6 +664,82 @@ free_carv:
return ret;
}
+/**
+ * rproc_handle_intmem() - handle internal memory resource entry
+ * @rproc: rproc handle
+ * @rsc: the intmem resource entry
+ * @offset: offset of the resource data in resource table
+ * @avail: size of available data (for image validation)
+ *
+ * This function will handle firmware requests for mapping a memory region
+ * internal to a remote processor into kernel. It neither allocates any
+ * physical pages, nor performs any iommu mapping, as this resource entry
+ * is primarily used for representing physical internal memories. If the
+ * internal memory region can only be accessed through an iommu, please
+ * use a devmem resource entry.
+ *
+ * These resource entries should be grouped near the carveout entries in
+ * the firmware's resource table, as other firmware entries might request
+ * placing other data objects inside these memory regions (e.g. data/code
+ * segments, trace resource entries, ...).
+ */
+static int rproc_handle_intmem(struct rproc *rproc, struct fw_rsc_intmem *rsc,
+ int offset, int avail)
+{
+ struct rproc_mem_entry *intmem;
+ struct device *dev = rproc-dev;
+ void *va;
+ int ret;
+
+ if (sizeof(*rsc) avail) {
+ dev_err(dev, intmem rsc is truncated\n);
+ return -EINVAL;
+ }
+
+ if (rsc-version != 1) {
+ dev_err(dev, intmem rsc version %d is not supported\n,
+ rsc-version);
+ return -EINVAL;
+ }
+
+ if (rsc-reserved) {
+ dev_err(dev, intmem rsc has non zero reserved bytes\n);
+ return -EINVAL;
+ }
+
+ dev_dbg(dev, intmem rsc: da 0x%x, pa 0x%x, len 0x%x\n,
+ rsc-da, rsc-pa, rsc-len);
+
+ intmem = kzalloc(sizeof(*intmem), GFP_KERNEL);
+ if (!intmem)
+ return -ENOMEM;
+
+ va = (__force void *)ioremap_nocache(rsc-pa, rsc-len);
+ if (!va) {
+ dev_err(dev, ioremap_nocache err: %d\n, rsc-len);
+ ret = -ENOMEM;
+ goto free_intmem;
+ }
+
+ dev_dbg(dev, intmem mapped pa 0x%x of len 0x%x into kernel va %p\n,
+ rsc-pa, rsc-len, va);
+
+ intmem-va = va;
+ intmem-len = rsc-len;
+ intmem-dma = rsc-pa;
+ intmem-da = rsc-da;
+ intmem-priv = (void *)1;/* prevents freeing */
+
+ /* reuse the rproc-carveouts list, so that loading is automatic */
+ list_add_tail(intmem-node, rproc-carveouts);
+
+ return 0;
+
+free_intmem:
+ kfree(intmem);
+ return ret;
+}
+
static int rproc_count_vrings(struct rproc *rproc, struct fw_rsc_vdev *rsc,
int offset, int avail)
{
@@ -681,6 +757,7 @@ static rproc_handle_resource_t
rproc_loading_handlers[RSC_LAST] = {
[RSC_CARVEOUT] = (rproc_handle_resource_t)rproc_handle_carveout,
[RSC_DEVMEM] = (rproc_handle_resource_t)rproc_handle_devmem,
[RSC_TRACE] = (rproc_handle_resource_t)rproc_handle_trace,
+ [RSC_INTMEM] = (rproc_handle_resource_t)rproc_handle_intmem,
[RSC_VDEV] = NULL, /* VDEVs were handled upon registrarion */
};
@@ -768,7 +845,11 @@ static void rproc_resource_cleanup(struct rproc *rproc)
/* clean up carveout allocations */
list_for_each_entry_safe(entry, tmp, rproc-carveouts, node) {
- dma_free_coherent(dev-parent, entry-len, entry-va,
entry-dma);
+ if (!entry-priv)
+ dma_free_coherent(dev-parent, entry-len, entry-va,
+ entry-dma);
+ else
+ iounmap((__force void __iomem *)entry-va);
list_del(entry-node);
kfree(entry);
}
diff --git a/include/linux/remoteproc.h
[PATCHv2 1/2] remoteproc: use a flag to detect the presence of IOMMU
The remoteproc driver core currently relies on iommu_present() on
the bus the device is on, to perform MMU management. However, this
logic doesn't scale for multi-arch, especially for processors that
do not have an IOMMU. Replace this logic instead by using a h/w
capability flag for the presence of IOMMU in the rproc structure.
This issue is seen on OMAP platforms when trying to add a remoteproc
driver for a small Cortex M3 called the WkupM3 used for suspend /
resume management on TI AM335/AM437x SoCs. This processor does not
have an MMU. Same is the case with another processor subsystem
PRU-ICSS on AM335/AM437x. All these are platform devices, and the
current iommu_present check will not scale for the same kernel image
to support OMAP4/OMAP5 and AM335/AM437x.
The existing platform implementation drivers - OMAP remoteproc, STE
Modem remoteproc and DA8xx remoteproc, are updated as well to properly
configure the newly added rproc field.
Cc: Robert Tivy rt...@ti.com
Cc: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Suman Anna s-a...@ti.com
---
v2:
- set the field explicitly in all existing remoteproc platform drivers
- update patch description
drivers/remoteproc/da8xx_remoteproc.c | 1 +
drivers/remoteproc/omap_remoteproc.c | 5 +
drivers/remoteproc/remoteproc_core.c | 15 ++-
drivers/remoteproc/ste_modem_rproc.c | 1 +
include/linux/remoteproc.h| 2 ++
5 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/remoteproc/da8xx_remoteproc.c
b/drivers/remoteproc/da8xx_remoteproc.c
index 3841b98..9fdc0af 100644
--- a/drivers/remoteproc/da8xx_remoteproc.c
+++ b/drivers/remoteproc/da8xx_remoteproc.c
@@ -224,6 +224,7 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
drproc = rproc-priv;
drproc-rproc = rproc;
+ rproc-has_iommu = false;
platform_set_drvdata(pdev, rproc);
diff --git a/drivers/remoteproc/omap_remoteproc.c
b/drivers/remoteproc/omap_remoteproc.c
index 5168972..b21ce95 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -199,6 +199,11 @@ static int omap_rproc_probe(struct platform_device *pdev)
oproc = rproc-priv;
oproc-rproc = rproc;
+ /*
+* All existing OMAP IPU and DSP processors do have an MMU, and
+* are expected to use MMU, so this statement suffices.
+*/
+ rproc-has_iommu = true;
platform_set_drvdata(pdev, rproc);
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 3cd85a6..11cdb11 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -94,19 +94,8 @@ static int rproc_enable_iommu(struct rproc *rproc)
struct device *dev = rproc-dev.parent;
int ret;
- /*
-* We currently use iommu_present() to decide if an IOMMU
-* setup is needed.
-*
-* This works for simple cases, but will easily fail with
-* platforms that do have an IOMMU, but not for this specific
-* rproc.
-*
-* This will be easily solved by introducing hw capabilities
-* that will be set by the remoteproc driver.
-*/
- if (!iommu_present(dev-bus)) {
- dev_dbg(dev, iommu not found\n);
+ if (!rproc-has_iommu) {
+ dev_dbg(dev, iommu not present\n);
return 0;
}
diff --git a/drivers/remoteproc/ste_modem_rproc.c
b/drivers/remoteproc/ste_modem_rproc.c
index c4ac910..c42a32e 100644
--- a/drivers/remoteproc/ste_modem_rproc.c
+++ b/drivers/remoteproc/ste_modem_rproc.c
@@ -289,6 +289,7 @@ static int sproc_probe(struct platform_device *pdev)
sproc = rproc-priv;
sproc-mdev = mdev;
sproc-rproc = rproc;
+ rproc-has_iommu = false;
mdev-drv_data = sproc;
/* Provide callback functions to modem device */
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 9e7e745..78b8a9b 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -404,6 +404,7 @@ enum rproc_crash_type {
* @table_ptr: pointer to the resource table in effect
* @cached_table: copy of the resource table
* @table_csum: checksum of the resource table
+ * @has_iommu: flag to indicate if remote processor is behind an MMU
*/
struct rproc {
struct klist_node node;
@@ -435,6 +436,7 @@ struct rproc {
struct resource_table *table_ptr;
struct resource_table *cached_table;
u32 table_csum;
+ bool has_iommu;
};
/* we currently support only two vrings per rvdev */
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: omap2: n8x0: move i2c devices to DT
By moving i2c devices to DT we can clean up
i2c_board_info and fix a problem with moving
INTC to irq domain where IRQs can be renumbered
on each boot.
Cc: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/omap2420-n810.dts | 7 +++
arch/arm/boot/dts/omap2420-n8x0-common.dtsi | 6 ++
arch/arm/mach-omap2/board-n8x0.c| 26 +++---
arch/arm/mach-omap2/common-board-devices.h | 5 +
arch/arm/mach-omap2/pdata-quirks.c | 2 ++
5 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/arch/arm/boot/dts/omap2420-n810.dts
b/arch/arm/boot/dts/omap2420-n810.dts
index 21baec1..b604d26 100644
--- a/arch/arm/boot/dts/omap2420-n810.dts
+++ b/arch/arm/boot/dts/omap2420-n810.dts
@@ -6,3 +6,10 @@
model = Nokia N810;
compatible = nokia,n810, nokia,n8x0, ti,omap2420, ti,omap2;
};
+
+i2c2 {
+ aic3x@18 {
+ compatible = tlv320aic3x;
+ reg = 0x18;
+ };
+};
diff --git a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
index 89608b2..24c50db 100644
--- a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
+++ b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
@@ -27,6 +27,12 @@
i2c1 {
clock-frequency = 40;
+
+ pmic@72 {
+ compatible = menelaus;
+ reg = 0x72;
+ interrupts = 7 IRQ_TYPE_EDGE_RISING;
+ };
};
i2c2 {
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index aead77a..97767a2 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -33,6 +33,7 @@
#include mmc.h
#include soc.h
#include gpmc-onenand.h
+#include common-board-devices.h
#define TUSB6010_ASYNC_CS 1
#define TUSB6010_SYNC_CS 4
@@ -568,29 +569,14 @@ static int n8x0_menelaus_late_init(struct device *dev)
}
#endif
-static struct menelaus_platform_data n8x0_menelaus_platform_data __initdata = {
+struct menelaus_platform_data n8x0_menelaus_platform_data __initdata = {
.late_init = n8x0_menelaus_late_init,
};
-static struct i2c_board_info __initdata n8x0_i2c_board_info_1[] __initdata = {
- {
- I2C_BOARD_INFO(menelaus, 0x72),
- .irq = 7 + OMAP_INTC_START,
- .platform_data = n8x0_menelaus_platform_data,
- },
-};
-
-static struct aic3x_pdata n810_aic33_data __initdata = {
+struct aic3x_pdata n810_aic33_data __initdata = {
.gpio_reset = 118,
};
-static struct i2c_board_info n810_i2c_board_info_2[] __initdata = {
- {
- I2C_BOARD_INFO(tlv320aic3x, 0x18),
- .platform_data = n810_aic33_data,
- },
-};
-
static int __init n8x0_late_initcall(void)
{
if (!board_caps)
@@ -612,11 +598,5 @@ void * __init n8x0_legacy_init(void)
board_check_revision();
spi_register_board_info(n800_spi_board_info,
ARRAY_SIZE(n800_spi_board_info));
- i2c_register_board_info(0, n8x0_i2c_board_info_1,
- ARRAY_SIZE(n8x0_i2c_board_info_1));
- if (board_is_n810())
- i2c_register_board_info(1, n810_i2c_board_info_2,
- ARRAY_SIZE(n810_i2c_board_info_2));
-
return mmc1_data;
}
diff --git a/arch/arm/mach-omap2/common-board-devices.h
b/arch/arm/mach-omap2/common-board-devices.h
index f338177..07c88ae 100644
--- a/arch/arm/mach-omap2/common-board-devices.h
+++ b/arch/arm/mach-omap2/common-board-devices.h
@@ -1,6 +1,8 @@
#ifndef __OMAP_COMMON_BOARD_DEVICES__
#define __OMAP_COMMON_BOARD_DEVICES__
+#include sound/tlv320aic3x.h
+#include linux/mfd/menelaus.h
#include twl-common.h
#define NAND_BLOCK_SIZESZ_128K
@@ -12,4 +14,7 @@ void omap_ads7846_init(int bus_num, int gpio_pendown, int
gpio_debounce,
struct ads7846_platform_data *board_pdata);
void *n8x0_legacy_init(void);
+extern struct menelaus_platform_data n8x0_menelaus_platform_data;
+extern struct aic3x_pdata n810_aic33_data;
+
#endif /* __OMAP_COMMON_BOARD_DEVICES__ */
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 8695fd4..06a0ccf 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -336,6 +336,8 @@ static struct pdata_init auxdata_quirks[] __initdata = {
struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
#ifdef CONFIG_MACH_NOKIA_N8X0
OF_DEV_AUXDATA(ti,omap2420-mmc, 0x4809c000, mmci-omap.0, NULL),
+ OF_DEV_AUXDATA(menelaus, 0x72, 1-0072,
n8x0_menelaus_platform_data),
+ OF_DEV_AUXDATA(tlv320aic3x, 0x18, 2-0018, n810_aic33_data),
#endif
#ifdef CONFIG_ARCH_OMAP3
OF_DEV_AUXDATA(ti,omap3-padconf, 0x48002030, 48002030.pinmux,
pcs_pdata),
--
2.0.1.563.g66f467c
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Re: [PATCH] arm: omap2: n8x0: move i2c devices to DT
On Tue, Sep 16, 2014 at 03:31:40PM -0500, Felipe Balbi wrote:
By moving i2c devices to DT we can clean up
i2c_board_info and fix a problem with moving
INTC to irq domain where IRQs can be renumbered
on each boot.
Cc: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
note that this only causes problem for N8x0 because it boots in kinda of
a hybrid way, where it uses DT but not all peripherals are created
through DT.
---
arch/arm/boot/dts/omap2420-n810.dts | 7 +++
arch/arm/boot/dts/omap2420-n8x0-common.dtsi | 6 ++
arch/arm/mach-omap2/board-n8x0.c| 26 +++---
arch/arm/mach-omap2/common-board-devices.h | 5 +
arch/arm/mach-omap2/pdata-quirks.c | 2 ++
5 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/arch/arm/boot/dts/omap2420-n810.dts
b/arch/arm/boot/dts/omap2420-n810.dts
index 21baec1..b604d26 100644
--- a/arch/arm/boot/dts/omap2420-n810.dts
+++ b/arch/arm/boot/dts/omap2420-n810.dts
@@ -6,3 +6,10 @@
model = Nokia N810;
compatible = nokia,n810, nokia,n8x0, ti,omap2420, ti,omap2;
};
+
+i2c2 {
+ aic3x@18 {
+ compatible = tlv320aic3x;
+ reg = 0x18;
+ };
+};
diff --git a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
index 89608b2..24c50db 100644
--- a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
+++ b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
@@ -27,6 +27,12 @@
i2c1 {
clock-frequency = 40;
+
+ pmic@72 {
+ compatible = menelaus;
+ reg = 0x72;
+ interrupts = 7 IRQ_TYPE_EDGE_RISING;
+ };
};
i2c2 {
diff --git a/arch/arm/mach-omap2/board-n8x0.c
b/arch/arm/mach-omap2/board-n8x0.c
index aead77a..97767a2 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -33,6 +33,7 @@
#include mmc.h
#include soc.h
#include gpmc-onenand.h
+#include common-board-devices.h
#define TUSB6010_ASYNC_CS1
#define TUSB6010_SYNC_CS 4
@@ -568,29 +569,14 @@ static int n8x0_menelaus_late_init(struct device *dev)
}
#endif
-static struct menelaus_platform_data n8x0_menelaus_platform_data __initdata
= {
+struct menelaus_platform_data n8x0_menelaus_platform_data __initdata = {
.late_init = n8x0_menelaus_late_init,
};
-static struct i2c_board_info __initdata n8x0_i2c_board_info_1[] __initdata =
{
- {
- I2C_BOARD_INFO(menelaus, 0x72),
- .irq = 7 + OMAP_INTC_START,
- .platform_data = n8x0_menelaus_platform_data,
- },
-};
-
-static struct aic3x_pdata n810_aic33_data __initdata = {
+struct aic3x_pdata n810_aic33_data __initdata = {
.gpio_reset = 118,
};
-static struct i2c_board_info n810_i2c_board_info_2[] __initdata = {
- {
- I2C_BOARD_INFO(tlv320aic3x, 0x18),
- .platform_data = n810_aic33_data,
- },
-};
-
static int __init n8x0_late_initcall(void)
{
if (!board_caps)
@@ -612,11 +598,5 @@ void * __init n8x0_legacy_init(void)
board_check_revision();
spi_register_board_info(n800_spi_board_info,
ARRAY_SIZE(n800_spi_board_info));
- i2c_register_board_info(0, n8x0_i2c_board_info_1,
- ARRAY_SIZE(n8x0_i2c_board_info_1));
- if (board_is_n810())
- i2c_register_board_info(1, n810_i2c_board_info_2,
- ARRAY_SIZE(n810_i2c_board_info_2));
-
return mmc1_data;
}
diff --git a/arch/arm/mach-omap2/common-board-devices.h
b/arch/arm/mach-omap2/common-board-devices.h
index f338177..07c88ae 100644
--- a/arch/arm/mach-omap2/common-board-devices.h
+++ b/arch/arm/mach-omap2/common-board-devices.h
@@ -1,6 +1,8 @@
#ifndef __OMAP_COMMON_BOARD_DEVICES__
#define __OMAP_COMMON_BOARD_DEVICES__
+#include sound/tlv320aic3x.h
+#include linux/mfd/menelaus.h
#include twl-common.h
#define NAND_BLOCK_SIZE SZ_128K
@@ -12,4 +14,7 @@ void omap_ads7846_init(int bus_num, int gpio_pendown, int
gpio_debounce,
struct ads7846_platform_data *board_pdata);
void *n8x0_legacy_init(void);
+extern struct menelaus_platform_data n8x0_menelaus_platform_data;
+extern struct aic3x_pdata n810_aic33_data;
+
#endif /* __OMAP_COMMON_BOARD_DEVICES__ */
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 8695fd4..06a0ccf 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -336,6 +336,8 @@ static struct pdata_init auxdata_quirks[] __initdata = {
struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
#ifdef CONFIG_MACH_NOKIA_N8X0
OF_DEV_AUXDATA(ti,omap2420-mmc, 0x4809c000, mmci-omap.0, NULL),
+ OF_DEV_AUXDATA(menelaus, 0x72, 1-0072,
n8x0_menelaus_platform_data),
+ OF_DEV_AUXDATA(tlv320aic3x, 0x18,
[PATCH v3 2/5] drm/tilcdc: Add I2S HDMI audio config for tda998x
The configuration is needed for HDMI audio. The swap and mirr
parameters have to be correctly set in the configuration in order to
have proper colors in the HDMI picture.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
drivers/gpu/drm/tilcdc/tilcdc_slave.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
index 3775fd4..5dd8d78 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
@@ -19,6 +19,7 @@
#include linux/pinctrl/pinmux.h
#include linux/pinctrl/consumer.h
#include drm/drm_encoder_slave.h
+#include drm/i2c/tda998x.h
#include tilcdc_drv.h
@@ -111,8 +112,29 @@ static const struct drm_encoder_helper_funcs
slave_encoder_helper_funcs = {
.restore= drm_i2c_encoder_restore,
};
+static struct tda998x_encoder_params tda998x_pdata = {
+ .swap_b = 0x3,
+ .mirr_b = 0x0,
+ .swap_a = 0x2,
+ .mirr_a = 0x0,
+ .swap_d = 0x1,
+ .mirr_d = 0x0,
+ .swap_c = 0x0,
+ .mirr_c = 0x0,
+ .swap_f = 0x5,
+ .mirr_f = 0x0,
+ .swap_e = 0x4,
+ .mirr_e = 0x0,
+ .audio_cfg = 0x3, /* I2S mode */
+ .audio_clk_cfg = 1, /* select clock pin */
+ .audio_frame[1] = 1,/* channels - 1 */
+ .audio_format = AFMT_I2S,
+ .audio_sample_rate = 48000,
+};
+
static const struct i2c_board_info info = {
- I2C_BOARD_INFO(tda998x, 0x70)
+ I2C_BOARD_INFO(tda998x, 0x70),
+ .platform_data = tda998x_pdata,
};
static struct drm_encoder *slave_encoder_create(struct drm_device *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 v3 3/5] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
Add machine driver support for BeagleBone-Black HDMI audio. BBB has
NXP TDA998X HDMI transmitter connected to McASP port in I2S mode. The
44100 Hz sample-rate and it's multiples can not be accurately produced
on BBB. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE.
The 8 least significant bits are ignored.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
.../bindings/sound/davinci-evm-audio.txt |6 +-
sound/soc/davinci/davinci-evm.c| 82 +++-
2 files changed, 84 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
index 963e100..7560146 100644
--- a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
@@ -1,7 +1,9 @@
-* Texas Instruments SoC audio setups with TLV320AIC3X Codec
+* TI SoC audio using McASP to connect to TLV320AIC3X or HDMI endcoder
Required properties:
-- compatible : ti,da830-evm-audio : forDM365/DA8xx/OMAPL1x/AM33xx
+- compatible: should contain one of:
+* ti,da830-evm-audio for DM365/DA8xx/OMAPL1x/AM33xx with TLV320AIC3X
+* ti,beaglebone-black-audio for Beaglebone-black HDMI audio
- ti,model : The user-visible name of this sound complex.
- ti,audio-codec : The phandle of the TLV320AIC3x audio codec
- ti,mcasp-controller : The phandle of the McASP controller
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index a50010e..3d0acba2a 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -21,6 +21,7 @@
#include sound/core.h
#include sound/pcm.h
#include sound/soc.h
+#include sound/pcm_params.h
#include asm/dma.h
#include asm/mach-types.h
@@ -83,12 +84,46 @@ static int evm_hw_params(struct snd_pcm_substream
*substream,
return 0;
}
+/* If changing sample format the tda998x configuration (REG_CTS_N) needs
+ to be changed. */
+#define TDA998X_SAMPLE_FORMAT SNDRV_PCM_FORMAT_S32_LE
+static int evm_tda998x_startup(struct snd_pcm_substream *substream)
+{
+ struct snd_pcm_runtime *runtime = substream-runtime;
+ struct snd_mask *fmt = constrs_mask(runtime-hw_constraints,
+ SNDRV_PCM_HW_PARAM_FORMAT);
+ snd_mask_none(fmt);
+ snd_mask_set(fmt, TDA998X_SAMPLE_FORMAT);
+
+ return evm_startup(substream);
+}
+
+static int evm_tda998x_hw_params(struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_dai *cpu_dai = rtd-cpu_dai;
+ struct snd_soc_card *soc_card = rtd-card;
+ struct snd_soc_card_drvdata_davinci *drvdata =
+ snd_soc_card_get_drvdata(soc_card);
+
+ return snd_soc_dai_set_sysclk(cpu_dai, 0, drvdata-sysclk,
+ SND_SOC_CLOCK_IN);
+}
+
static struct snd_soc_ops evm_ops = {
.startup = evm_startup,
.shutdown = evm_shutdown,
.hw_params = evm_hw_params,
};
+
+static struct snd_soc_ops evm_tda998x_ops = {
+ .startup = evm_tda998x_startup,
+ .shutdown = evm_shutdown,
+ .hw_params = evm_tda998x_hw_params,
+};
+
/* davinci-evm machine dapm widgets */
static const struct snd_soc_dapm_widget aic3x_dapm_widgets[] = {
SND_SOC_DAPM_HP(Headphone Jack, NULL),
@@ -149,6 +184,35 @@ static int evm_aic3x_init(struct snd_soc_pcm_runtime *rtd)
return 0;
}
+static const struct snd_soc_dapm_widget tda998x_dapm_widgets[] = {
+ SND_SOC_DAPM_OUTPUT(HDMI Out),
+};
+
+static int evm_tda998x_init(struct snd_soc_pcm_runtime *rtd)
+{
+ struct snd_soc_dai *cpu_dai = rtd-cpu_dai;
+ struct snd_soc_dapm_context *dapm = rtd-codec-dapm;
+ struct snd_soc_card *soc_card = rtd-card;
+ int ret;
+
+ ret = snd_soc_dai_set_clkdiv(cpu_dai, 0, 1);
+ if (ret 0)
+ return ret;
+
+ snd_soc_dapm_new_controls(dapm, tda998x_dapm_widgets,
+ ARRAY_SIZE(tda998x_dapm_widgets));
+
+ ret = snd_soc_of_parse_audio_routing(soc_card, ti,audio-routing);
+
+ /* not connected */
+ snd_soc_dapm_disable_pin(dapm, RX);
+
+ /* always connected */
+ snd_soc_dapm_enable_pin(dapm, HDMI Out);
+
+ return 0;
+}
+
/* davinci-evm digital audio interface glue - connects codec -- CPU */
static struct snd_soc_dai_link dm6446_evm_dai = {
.name = TLV320AIC3X,
@@ -334,7 +398,7 @@ static struct snd_soc_card da850_snd_soc_card = {
#if defined(CONFIG_OF)
/*
- * The struct is used as place holder. It will be completely
+ * The structs are used as place holders. They will be completely
* filled with data from dt node.
*/
static struct snd_soc_dai_link evm_dai_tlv320aic3x = {
@@ -347,10 +411,24 @@ static struct snd_soc_dai_link evm_dai_tlv320aic3x = {
[PATCH v3 1/5] clk: ti: add ti,gpio-gate-clock controlled clock
The added ti,gpio-gate-clock is a basic clock that can be enabled and
disabled trough a gpio output. The DT binding document for the clock
is also added. For EPROBE_DEFER handling the registering of the clock
has to be delayed until of_clk_get() call time.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
.../bindings/clock/ti/gpio-gate-clock.txt | 21 ++
drivers/clk/ti/Makefile|2 +-
drivers/clk/ti/gpio.c | 202
3 files changed, 224 insertions(+), 1 deletion(-)
create mode 100644
Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt
create mode 100644 drivers/clk/ti/gpio.c
diff --git a/Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt
b/Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt
new file mode 100644
index 000..6156f82
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt
@@ -0,0 +1,21 @@
+Binding for simple gpio controlled clock.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be ti,gpio-gate-clock.
+- #clock-cells : from common clock binding; shall be set to 0.
+- enable-gpios : GPIO reference for enabling and disabling the clock.
+
+Optional properties:
+- clocks: Maximum of one parent clock is supported.
+
+Example:
+ clock {
+ compatible = ti,gpio-gate-clock;
+ clocks = parentclk;
+ #clock-cells = 0;
+ enable-gpios = gpio 1 GPIO_ACTIVE_HIGH;
+ };
diff --git a/drivers/clk/ti/Makefile b/drivers/clk/ti/Makefile
index ed4d0aa..88074d3 100644
--- a/drivers/clk/ti/Makefile
+++ b/drivers/clk/ti/Makefile
@@ -1,7 +1,7 @@
ifneq ($(CONFIG_OF),)
obj-y += clk.o autoidle.o clockdomain.o
clk-common = dpll.o composite.o divider.o gate.o \
- fixed-factor.o mux.o apll.o
+ fixed-factor.o mux.o apll.o gpio.o
obj-$(CONFIG_SOC_AM33XX) += $(clk-common) clk-33xx.o
obj-$(CONFIG_ARCH_OMAP2) += $(clk-common) interface.o clk-2xxx.o
obj-$(CONFIG_ARCH_OMAP3) += $(clk-common) interface.o clk-3xxx.o
diff --git a/drivers/clk/ti/gpio.c b/drivers/clk/ti/gpio.c
new file mode 100644
index 000..b973801
--- /dev/null
+++ b/drivers/clk/ti/gpio.c
@@ -0,0 +1,202 @@
+/*
+ * Copyright (C) 2012 - 2014 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Jyri Sarha jsa...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Gpio controlled clock implementation
+ */
+
+#include linux/clk-provider.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/gpio.h
+#include linux/of_gpio.h
+#include linux/err.h
+#include linux/device.h
+
+struct clk_gpio {
+ struct clk_hw hw;
+ struct gpio_desc *gpiod;
+};
+
+/**
+ * DOC: basic gpio controlled clock which can be enabled and disabled
+ * with gpio output
+ * Traits of this clock:
+ * prepare - clk_(un)prepare only ensures parent is (un)prepared
+ * enable - clk_enable and clk_disable are functional control gpio
+ * rate - inherits rate from parent. No clk_set_rate support
+ * parent - fixed parent. No clk_set_parent support
+ */
+
+#define to_clk_gpio(_hw) container_of(_hw, struct clk_gpio, hw)
+
+static int clk_gpio_enable(struct clk_hw *hw)
+{
+ struct clk_gpio *clk = to_clk_gpio(hw);
+
+ gpiod_set_value(clk-gpiod, 1);
+
+ return 0;
+}
+
+static void clk_gpio_disable(struct clk_hw *hw)
+{
+ struct clk_gpio *clk = to_clk_gpio(hw);
+
+ gpiod_set_value(clk-gpiod, 0);
+}
+
+static int clk_gpio_is_enabled(struct clk_hw *hw)
+{
+ struct clk_gpio *clk = to_clk_gpio(hw);
+
+ return gpiod_get_value(clk-gpiod);
+}
+
+static const struct clk_ops clk_gpio_ops = {
+ .enable = clk_gpio_enable,
+ .disable = clk_gpio_disable,
+ .is_enabled = clk_gpio_is_enabled,
+};
+
+/**
+ * clk_register_gpio - register a gpip clock with the clock framework
+ * @dev: device that is registering this clock
+ * @name: name of this clock
+ * @parent_name: name of this clock's parent
+ * @gpiod: gpio descriptor to control this clock
+ */
+static struct clk *clk_register_gpio(struct device *dev, const char *name,
+ const char *parent_name, struct gpio_desc *gpiod,
+ unsigned long flags)
+{
+ struct clk_gpio *clk_gpio = NULL;
+ struct clk *clk = ERR_PTR(-EINVAL);
+ struct clk_init_data init = { NULL };
+ unsigned long gpio_flags;
+ int err;
+
+ if (gpiod_is_active_low(gpiod))
+ gpio_flags = GPIOF_OUT_INIT_HIGH;
+ else
+ gpio_flags = GPIOF_OUT_INIT_LOW;
+
[PATCH v3 0/5] Beaglebone-Black HDMI audio
Changes since v2: - Change compatible property from ti,gpio-clock to ti,gpio-gate-clock - Some minor cleanups The code has a functional dependency to: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg109264.html Without the above patch the audio card does not probe. The code has been rebased on top of Linux 3.17-rc5. The patches bellow, the above dependency, and couple of commits to add BBB HDMI audio support to omap2plus_defconfig can be pulled from: https://github.com/jsarha/linux.git linux-master-bbb-hdmi-audio Cheers, Jyri Jyri Sarha (5): clk: ti: add ti,gpio-gate-clock controlled clock drm/tilcdc: Add I2S HDMI audio config for tda998x ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus ASoC: davinci: HDMI audio build for AM33XX and TDA998x ARM: dts: am335x-boneblack: Add HDMI audio support .../bindings/clock/ti/gpio-gate-clock.txt | 21 ++ .../bindings/sound/davinci-evm-audio.txt |6 +- arch/arm/boot/dts/am335x-boneblack.dts | 52 + drivers/clk/ti/Makefile|2 +- drivers/clk/ti/gpio.c | 202 drivers/gpu/drm/tilcdc/tilcdc_slave.c | 24 ++- sound/soc/davinci/Kconfig | 12 ++ sound/soc/davinci/davinci-evm.c| 82 +++- 8 files changed, 395 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt create mode 100644 drivers/clk/ti/gpio.c -- 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 v3 5/5] ARM: dts: am335x-boneblack: Add HDMI audio support
Adds mcasp0_pins, clk_mcasp0_fixed, clk_mcasp0, mcasp0, hdmi_audio,
and sound nodes.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
arch/arm/boot/dts/am335x-boneblack.dts | 52
1 file changed, 52 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 305975d..1487f7c 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -59,12 +59,35 @@
0x1b0 0x03 /* xdma_event_intr0, OMAP_MUX_MODE3 |
AM33XX_PIN_OUTPUT */
;
};
+
+ mcasp0_pins: mcasp0_pins {
+ pinctrl-single,pins =
+ 0x1ac (PIN_INPUT_PULLUP | MUX_MODE0)/*
mcasp0_ahclkx.mcasp0_ahclkx */
+ 0x19c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mcasp0_ahclkr.mcasp0_axr2 */
+ 0x194 (PIN_OUTPUT_PULLUP | MUX_MODE0) /*
mcasp0_fsx.mcasp0_fsx */
+ 0x190 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mcasp0_aclkx.mcasp0_aclkx */
+ 0x06c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a11.GPIO1_27 */
+ ;
+ };
};
lcdc {
status = okay;
};
+mcasp0{
+ pinctrl-names = default;
+ pinctrl-0 = mcasp0_pins;
+ status = okay;
+ op-mode = 0; /* MCASP_IIS_MODE */
+ tdm-slots = 2;
+ serial-dir = /* 0: INACTIVE, 1: TX, 2: RX */
+ 0 0 1 0
+ ;
+ tx-num-evt = 1;
+ rx-num-evt = 1;
+};
+
/ {
hdmi {
compatible = ti,tilcdc,slave;
@@ -74,4 +97,33 @@
pinctrl-1 = nxp_hdmi_bonelt_off_pins;
status = okay;
};
+
+ clk_mcasp0_fixed: clk_mcasp0_fixed {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 24576000;
+ };
+
+ clk_mcasp0: clk_mcasp0 {
+ #clock-cells = 0;
+ compatible = ti,gpio-gate-clock;
+ clocks = clk_mcasp0_fixed;
+ enable-gpios = gpio1 27 0; /* BeagleBone Black Clk enable on
GPIO1_27 */
+ };
+
+ hdmi_audio: hdmi_audio@0 {
+ compatible = linux,hdmi-audio;
+ status = okay;
+ };
+
+ sound {
+ compatible = ti,beaglebone-black-audio;
+ ti,model = TI BeagleBone Black;
+ ti,audio-codec = hdmi_audio;
+ ti,mcasp-controller = mcasp0;
+ ti,audio-routing =
+ HDMI Out, TX;
+ clocks = clk_mcasp0;
+ clock-names = mclk;
+ };
};
--
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 v3 4/5] ASoC: davinci: HDMI audio build for AM33XX and TDA998x
Adds configuration option for HDMI audio support for AM33XX based boards with NXP TDA998x HDMI transmitter. The audio is connected to NXP TDA998x trough McASP running in i2s mode. Signed-off-by: Jyri Sarha jsa...@ti.com --- sound/soc/davinci/Kconfig | 12 1 file changed, 12 insertions(+) diff --git a/sound/soc/davinci/Kconfig b/sound/soc/davinci/Kconfig index d69510c..0c8f143 100644 --- a/sound/soc/davinci/Kconfig +++ b/sound/soc/davinci/Kconfig @@ -43,6 +43,18 @@ config SND_AM33XX_SOC_EVM AM335X-EVMSK, and BeagelBone with AudioCape boards have this setup. +config SND_AM335X_SOC_NXPTDA_EVM + tristate HDMI Audio for the AM33XX chip based boards with TDA998x + depends on SND_EDMA_SOC SOC_AM33XX DRM_I2C_NXP_TDA998X + select SND_SOC_HDMI_CODEC + select SND_DAVINCI_SOC_MCASP + select SND_DAVINCI_SOC_GENERIC_EVM + help + Say Y or M if you want to add support for HDMI SoC audio on + AM33XX boards with NXP TDA998x HDMI transmitter. For example + BeagleBoneBack. The audio is connected to NXP TDA998x trough + McASP running in i2s mode. + config SND_DAVINCI_SOC_EVM tristate SoC Audio support for DaVinci DM6446, DM355 or DM365 EVM depends on SND_DAVINCI_SOC I2C -- 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 2/2] pstore-ram: Allow optional mapping with pgprot_noncached
* Russell King - ARM Linux li...@arm.linux.org.uk [140912 16:16]:
On Fri, Sep 12, 2014 at 11:32:25AM -0700, Tony Lindgren wrote:
On some ARMs at least the memory can be mapped pgprot_noncached()
and still be working for atomic operations. As pointed out by
Colin Cross ccr...@android.com, in some cases you do want to use
pgprot_noncached() if the SoC supports it to see a debug printk
just before a write hanging the system.
On ARMs, the atomic operations on strongly ordered memory are
implementation defined. So let's provide an optional kernel parameter
for configuring noncached memory, and use pgprot_writecombine() by
default.
Can we clean up this terminology please?
Writecombine memory is not cached - write combine memory bypasses the
caches entirely. What it doesn't bypass are store buffers, which may
combine two writes together. So, calling it cached is misleading.
Good point. I've pretty much s/cached/memtype/ and updated the
description too in the patch below.
Secondly, memory returned by ioremap() is not strongly ordered, it is
device memory. There's three main classifications of memory on ARM:
strongly ordered, device and normal memory. Normal memory has attributes
which define whether it is write combining, or cacheable in some way (and
if so, how it's cacheable.)
Exclusives are always permitted to normal memory. The other two are
implementation defined. While an implementation may offer it on
strongly ordered, that doesn't mean that it also supports it on device
memory.
Lastly, aliased mappings are something that ARM has always strongly
discouraged on ARMv6+ (it was plain down-right unpredictable, but it's
now strongly discouraged) and remapping memory with different memory
type should be avoided.
Yes thanks for the summary again. Maybe let's let this second patch float
on the lists for a while until we have somebody actually test it on
unbuffered memory.
Andrew, if no comments on 1/2 in this series, can you please pick it up
for fixes so we get pstore working?
Here's the updated version of the second patch for reference.
Regards,
Tony
8 -
From: Tony Lindgren t...@atomide.com
Date: Thu, 11 Sep 2014 15:02:37 -0700
Subject: [PATCH] pstore-ram: Allow optional mapping with pgprot_noncached
On some ARMs the memory can be mapped pgprot_noncached() and still
be working for atomic operations. As pointed out by Colin Cross
ccr...@android.com, in some cases you do want to use
pgprot_noncached() if the SoC supports it to see a debug printk
just before a write hanging the system.
On ARMs, the atomic operations on strongly ordered memory are
implementation defined. So let's provide an optional kernel parameter
for configuring pgprot_noncached(), and use pgprot_writecombine() by
default.
Cc: Arnd Bergmann a...@arndb.de
Cc: Rob Herring robherri...@gmail.com
Cc: Randy Dunlap rdun...@infradead.org
Cc: Anton Vorontsov an...@enomsg.org
Cc: Colin Cross ccr...@android.com
Cc: Kees Cook keesc...@chromium.org
Cc: Olof Johansson o...@lixom.net
Cc: Tony Luck tony.l...@intel.com
Cc: Russell King li...@arm.linux.org.uk
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/Documentation/ramoops.txt
+++ b/Documentation/ramoops.txt
@@ -14,11 +14,19 @@ survive after a restart.
1. Ramoops concepts
-Ramoops uses a predefined memory area to store the dump. The start and size of
-the memory area are set using two variables:
+Ramoops uses a predefined memory area to store the dump. The start and size
+and type of the memory area are set using three variables:
* mem_address for the start
* mem_size for the size. The memory size will be rounded down to a
power of two.
+ * mem_type to specifiy if the memory type (default is pgprot_writecombine).
+
+Typically the default value of mem_type=0 should be used as that sets the
pstore
+mapping to pgprot_writecombine. Setting mem_type=1 attempts to use
+pgprot_noncached, which only works on some platforms. This is because pstore
+depends on atomic operations. At least on ARM, pgprot_noncached causes the
+memory to be mapped strongly ordered, and atomic operations on strongly ordered
+memory are implementation defined, and won't work on many ARMs such as omaps.
The memory area is divided into record_size chunks (also rounded down to
power of two) and each oops/panic writes a record_size chunk of
@@ -55,6 +63,7 @@ Setting the ramoops parameters can be done in 2 different
manners:
static struct ramoops_platform_data ramoops_data = {
.mem_size = ...,
.mem_address= ...,
+.mem_type = ...,
.record_size= ...,
.dump_oops = ...,
.ecc= ...,
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -61,6 +61,11 @@ module_param(mem_size, ulong, 0400);
MODULE_PARM_DESC(mem_size,
size of reserved RAM used to store oops/panic logs);
+static unsigned int mem_type;
Re: [PATCH 00/16 v9] omap 8250 based uart + DMA
* Tony Lindgren t...@atomide.com [140916 09:49]: * Sebastian Andrzej Siewior bige...@linutronix.de [140916 05:58]: On 09/15/2014 01:50 PM, Sebastian Andrzej Siewior wrote: I changed the restore function the fix the am335x-evm + less freeze. And now we have this. So let me search… IER was 0 by accident. It fixed in TX path. I pushed uart_v10_pre1 which should have it fixed aport from other things… Just verified that works for my off-idle test case thanks. I am going to address the review comments, to split the DMA callbacks as requested and if nobody comes up with something fancy we will have a v10 :) OK Found one more issue when booting on 2420 n8x0, maybe something to do with runtime PM? Regards, Tony [4.770507] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM [4.777343] Modules linked in: [4.780487] CPU: 0 PID: 1 Comm: init Not tainted 3.17.0-rc5-00211-gc2182d0-dirty #1408 [4.788482] task: c5842b80 ti: c585 task.ti: c585 [4.793945] PC is at serial8250_start_tx+0x124/0x154 [4.798980] LR is at uart_start+0x4c/0x5c [4.803039] pc : [c03d7340]lr : [c03d1ee4]psr: a093 [4.803039] sp : c5851e10 ip : c5851e28 fp : c5851e24 [4.814605] r10: 0007 r9 : r8 : c134d554 [4.819885] r7 : c5cb7800 r6 : 2013 r5 : c134d554 r4 : c134d554 [4.826477] r3 : c134d690 r2 : r1 : 0001 r0 : c134d554 [4.833068] Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [4.840332] Control: 00c5387d Table: 85cd8000 DAC: 0015 [4.846130] Process init (pid: 1, stack limit = 0xc5850248) [4.851776] Stack: (0xc5851e10 to 0xc5852000) [4.856201] 1e00: c5cb7800 c134d554 c5851e44 c5851e28 [4.864440] 1e20: c03d1ee4 c03d7228 c5842b80 c5b00408 c5cf3c07 c5851e7c c5851e48 [4.872711] 1e40: c03d2da0 c03d1ea4 c5851e6c a013 c03d1fe0 c5cb7800 0007 224c [4.880981] 1e60: c88cc2a0 2250 c5cf3c00 c88ca000 c5851edc c5851e80 c03b9474 c03d2cd4 [4.889251] 1e80: c5851e9c c5cb7ab4 c5cf3c00 c5cb793c c5a5ae00 c585 c0158e1c [4.897491] 1ea0: c5842b80 c007152c c5cb7ad4 c5cb7ad4 c5cb7800 e0cc 0007 c5cb7800 [4.905761] 1ec0: c585 0400 c5a5ae00 c5851f1c c5851ee0 c03b61c0 c03b92d0 [4.914031] 1ee0: 0007 0007 c5cb18c0 c03b92c4 c0b19f20 0007 e0cc [4.922271] 1f00: c5851f78 c5a5ae00 c585 e0cc c5851f44 c5851f20 c03b63c4 c03b60c0 [4.930541] 1f20: c5851f78 c5a5ae00 0007 e0cc c5851f78 0007 c5851f74 c5851f48 [4.938812] 1f40: c0168f38 c03b632c c0185718 c0185688 c5a5ae00 c5a5ae00 [4.947052] 1f60: 0007 e0cc c5851fa4 c5851f78 c0169380 c0168e90 [4.955322] 1f80: e0cc 0001 0004 c000f164 c5851fa8 [4.963592] 1fa0: c000eee0 c0169340 e0cc e0cc 0007 [4.971862] 1fc0: e0cc 0001 0004 a24c 00017504 1000 [4.980102] 1fe0: bef5aa40 bef5aa30 a474 b6e801ec 6010 [4.988372] [c03d7340] (serial8250_start_tx) from [c03d1ee4] (uart_start+0x4c/0x5c) [4.996490] [c03d1ee4] (uart_start) from [c03d2da0] (uart_write+0xd8/0x100) [5.003875] [c03d2da0] (uart_write) from [c03b9474] (n_tty_write+0x1b0/0x510) [5.011474] [c03b9474] (n_tty_write) from [c03b61c0] (tty_write+0x10c/0x26c) [5.018951] [c03b61c0] (tty_write) from [c03b63c4] (redirected_tty_write+0xa4/0xb8) [5.027038] [c03b63c4] (redirected_tty_write) from [c0168f38] (vfs_write+0xb4/0x1bc) [5.035217] [c0168f38] (vfs_write) from [c0169380] (SyS_write+0x4c/0x98) [5.042358] [c0169380] (SyS_write) from [c000eee0] (ret_fast_syscall+0x0/0x48) [5.050018] Code: e3a02000 ee072fba e3a01001 f5d3f000 (e1d30f9f) -- 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 v10 5/9] arm: omap1: Migrate debug_ll macros to use 8250.S
The omap1's debug-macro.S is similar to the generic 8250 code. Compared to the 8520 code the omap1 macro automatically determines what UART to use based on breadcrumbs left by the bootloader and automatically copes with the eccentric register layout on OMAP7XX. This patch drops both these features and relies instead on the generic 8250 macros: 1. Dropping support for the bootloader breadcrumbs is identical to the way the migration was handled for OMAP2 (see 808b7e07464d...). 2. Support for OMAP7XX still exists but it must be configured by hand (DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime. Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org Cc: Russell King li...@arm.linux.org.uk Cc: linux-arm-ker...@lists.infradead.org Cc: Tony Lindgren t...@atomide.com Cc: Arnd Bergmann arnd.bergm...@linaro.org Cc: linux-omap@vger.kernel.org Tested-by: Aaro Koskinen aaro.koski...@iki.fi --- arch/arm/Kconfig.debug | 57 +- arch/arm/mach-omap1/include/mach/debug-macro.S | 101 - 2 files changed, 56 insertions(+), 102 deletions(-) delete mode 100644 arch/arm/mach-omap1/include/mach/debug-macro.S diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 97c3058..01f4ee2 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -471,6 +471,30 @@ choice Say Y here if you want kernel low-level debugging support on TI-NSPIRE CX models. + config DEBUG_OMAP1UART1 + bool Kernel low-level debugging via OMAP1 UART1 + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART1. + + config DEBUG_OMAP1UART2 + bool Kernel low-level debugging via OMAP1 UART2 + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART2. + + config DEBUG_OMAP1UART3 + bool Kernel low-level debugging via OMAP1 UART3 + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART3. + config DEBUG_OMAP2UART1 bool OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 boards) depends on ARCH_OMAP2PLUS @@ -513,6 +537,30 @@ choice depends on ARCH_OMAP2PLUS select DEBUG_OMAP2PLUS_UART + config DEBUG_OMAP7XXUART1 + bool Kernel low-level debugging via OMAP730 UART1 + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART1. + + config DEBUG_OMAP7XXUART2 + bool Kernel low-level debugging via OMAP730 UART2 + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART2. + + config DEBUG_OMAP7XXUART3 + bool Kernel low-level debugging via OMAP730 UART3 + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART3. + config DEBUG_TI81XXUART1 bool Kernel low-level debugging messages via TI81XX UART1 (ti8148evm) depends on ARCH_OMAP2PLUS @@ -1120,6 +1168,9 @@ config DEBUG_UART_PHYS default 0xff69 if DEBUG_RK32_UART2 default 0xffc02000 if DEBUG_SOCFPGA_UART default 0xffd82340 if ARCH_IOP13XX + default 0xfffb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1 + default 0xfffb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2 + default 0xfffb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3 default 0xfff36000 if DEBUG_HIGHBANK_UART default 0xf700 if ARCH_IOP33X depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \ @@ -1188,6 +1239,9 @@ config DEBUG_UART_VIRT default 0xfef0 if ARCH_IXP4XX !CPU_BIG_ENDIAN default 0xfef3 if ARCH_IXP4XX CPU_BIG_ENDIAN default 0xfef36000 if DEBUG_HIGHBANK_UART + default 0xfefb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1 + default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2 + default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3 default 0xfefff700 if ARCH_IOP33X default
Re: [PATCH v10 5/9] arm: omap1: Migrate debug_ll macros to use 8250.S
Hi, On Tue, Sep 16, 2014 at 11:46:24PM +0100, Daniel Thompson wrote: + config DEBUG_OMAP1UART1 + bool Kernel low-level debugging via OMAP1 UART1 + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART1. ^^ + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART2. ^^ + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART3. ^^ I already commented earlier, that expect here is probably a typo? A. -- 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 v10 5/9] arm: omap1: Migrate debug_ll macros to use 8250.S
On 16/09/14 15:58, Aaro Koskinen wrote: Hi, On Tue, Sep 16, 2014 at 11:46:24PM +0100, Daniel Thompson wrote: +config DEBUG_OMAP1UART1 +bool Kernel low-level debugging via OMAP1 UART1 +depends on ARCH_OMAP1 +select DEBUG_UART_8250 +help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART1. ^^ +select DEBUG_UART_8250 +help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART2. ^^ +select DEBUG_UART_8250 +help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART3. ^^ I already commented earlier, that expect here is probably a typo? I'm extremely sorry to have overlooked your previous comment. There's certainly no question I read your previous e-mail because because I copied your Tested-by: from it. I will fix this (and also grep all other patches in the set to make sure I haven't copied the typo anywhere else). Daniel. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mfd: twl4030-power: use 'ti,system-power-controller' as alternative way to support system power off
On Mon, 08 Sep 2014, Tony Lindgren wrote: * Nishanth Menon n...@ti.com [140903 12:07]: ti,system-power-controller is more or less the standard way of indicating that the PMIC is the system wide power controller and hence may be used to switch off the system. Almost ALL TI PMIC drivers and many Maxim PMIC drivers follow the same style. So support 'ti,system-power-controller' in addition to the usual 'ti,use_poweroff' to indicate that the PMIC instance has control for switching off the system. Signed-off-by: Nishanth Menon n...@ti.com Acked-by: Tony Lindgren t...@atomide.com I assume you're going to resend this with the document modifications? When you do, don't forget to apply Tony's Ack, as it will ensure a faster merge. --- drivers/mfd/twl4030-power.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c index 3bc969a..1c129ba 100644 --- a/drivers/mfd/twl4030-power.c +++ b/drivers/mfd/twl4030-power.c @@ -627,6 +627,9 @@ static bool twl4030_power_use_poweroff(const struct twl4030_power_data *pdata, if (pdata pdata-use_poweroff) return true; + if (of_property_read_bool(node, ti,system-power-controller)) + return true; + if (of_property_read_bool(node, ti,use_poweroff)) return true; -- 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
[PATCH v11 5/9] arm: omap1: Migrate debug_ll macros to use 8250.S
The omap1's debug-macro.S is similar to the generic 8250 code. Compared to the 8520 code the omap1 macro automatically determines what UART to use based on breadcrumbs left by the bootloader and automatically copes with the eccentric register layout on OMAP7XX. This patch drops both these features and relies instead on the generic 8250 macros: 1. Dropping support for the bootloader breadcrumbs is identical to the way the migration was handled for OMAP2 (see 808b7e07464d...). 2. Support for OMAP7XX still exists but it must be configured by hand (DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime. Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org Cc: Russell King li...@arm.linux.org.uk Cc: linux-arm-ker...@lists.infradead.org Cc: Tony Lindgren t...@atomide.com Cc: Arnd Bergmann arnd.bergm...@linaro.org Cc: linux-omap@vger.kernel.org Tested-by: Aaro Koskinen aaro.koski...@iki.fi --- arch/arm/Kconfig.debug | 57 +- arch/arm/mach-omap1/include/mach/debug-macro.S | 101 - 2 files changed, 56 insertions(+), 102 deletions(-) delete mode 100644 arch/arm/mach-omap1/include/mach/debug-macro.S diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 97c3058..6540036 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -471,6 +471,30 @@ choice Say Y here if you want kernel low-level debugging support on TI-NSPIRE CX models. + config DEBUG_OMAP1UART1 + bool Kernel low-level debugging via OMAP1 UART1 + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (except OMAP730) on the UART1. + + config DEBUG_OMAP1UART2 + bool Kernel low-level debugging via OMAP1 UART2 + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (except OMAP730) on the UART2. + + config DEBUG_OMAP1UART3 + bool Kernel low-level debugging via OMAP1 UART3 + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (except OMAP730) on the UART3. + config DEBUG_OMAP2UART1 bool OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 boards) depends on ARCH_OMAP2PLUS @@ -513,6 +537,30 @@ choice depends on ARCH_OMAP2PLUS select DEBUG_OMAP2PLUS_UART + config DEBUG_OMAP7XXUART1 + bool Kernel low-level debugging via OMAP730 UART1 + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART1. + + config DEBUG_OMAP7XXUART2 + bool Kernel low-level debugging via OMAP730 UART2 + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART2. + + config DEBUG_OMAP7XXUART3 + bool Kernel low-level debugging via OMAP730 UART3 + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART3. + config DEBUG_TI81XXUART1 bool Kernel low-level debugging messages via TI81XX UART1 (ti8148evm) depends on ARCH_OMAP2PLUS @@ -1120,6 +1168,9 @@ config DEBUG_UART_PHYS default 0xff69 if DEBUG_RK32_UART2 default 0xffc02000 if DEBUG_SOCFPGA_UART default 0xffd82340 if ARCH_IOP13XX + default 0xfffb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1 + default 0xfffb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2 + default 0xfffb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3 default 0xfff36000 if DEBUG_HIGHBANK_UART default 0xf700 if ARCH_IOP33X depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \ @@ -1188,6 +1239,9 @@ config DEBUG_UART_VIRT default 0xfef0 if ARCH_IXP4XX !CPU_BIG_ENDIAN default 0xfef3 if ARCH_IXP4XX CPU_BIG_ENDIAN default 0xfef36000 if DEBUG_HIGHBANK_UART + default 0xfefb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1 + default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2 + default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3 default 0xfefff700 if ARCH_IOP33X default
[PATCH] ARM: OMAP: Remove unused pieces of legacy DMA API
We're moving to the dmaengine API, so let's remove the unused
pieces of the omap legacy DMA code to make sure we don't get
any new users for these:
omap_set_dma_color_mode
omap_set_dma_src_index
omap_set_dma_dest_index
omap_dma_unlink_lch
omap_clear_dma
omap_dma_running
omap_dma_set_prio_lch
omap_set_dma_dst_endian_type
omap_set_dma_src_endian_type
omap_get_dma_index
omap_dma_disable_irq
omap_request_dma_chain
omap_free_dma_chain
omap_dma_chain_a_transfer
omap_start_dma_chain_transfers
omap_stop_dma_chain_transfers
omap_get_dma_chain_index
omap_get_dma_chain_dst_pos
omap_get_dma_chain_src_pos
omap_modify_dma_chain_params
omap_dma_chain_status
Cc: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -64,7 +64,9 @@ enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED };
static struct omap_system_dma_plat_info *p;
static struct omap_dma_dev_attr *d;
-
+static void omap_clear_dma(int lch);
+static int omap_dma_set_prio_lch(int lch, unsigned char read_prio,
+unsigned char write_prio);
static int enable_1510_mode;
static u32 errata;
@@ -284,66 +286,6 @@ void omap_set_dma_transfer_params(int lch, int data_type,
int elem_count,
}
EXPORT_SYMBOL(omap_set_dma_transfer_params);
-void omap_set_dma_color_mode(int lch, enum omap_dma_color_mode mode, u32 color)
-{
- BUG_ON(omap_dma_in_1510_mode());
-
- if (dma_omap1()) {
- u16 w;
-
- w = p-dma_read(CCR2, lch);
- w = ~0x03;
-
- switch (mode) {
- case OMAP_DMA_CONSTANT_FILL:
- w |= 0x01;
- break;
- case OMAP_DMA_TRANSPARENT_COPY:
- w |= 0x02;
- break;
- case OMAP_DMA_COLOR_DIS:
- break;
- default:
- BUG();
- }
- p-dma_write(w, CCR2, lch);
-
- w = p-dma_read(LCH_CTRL, lch);
- w = ~0x0f;
- /* Default is channel type 2D */
- if (mode) {
- p-dma_write(color, COLOR, lch);
- w |= 1; /* Channel type G */
- }
- p-dma_write(w, LCH_CTRL, lch);
- }
-
- if (dma_omap2plus()) {
- u32 val;
-
- val = p-dma_read(CCR, lch);
- val = ~((1 17) | (1 16));
-
- switch (mode) {
- case OMAP_DMA_CONSTANT_FILL:
- val |= 1 16;
- break;
- case OMAP_DMA_TRANSPARENT_COPY:
- val |= 1 17;
- break;
- case OMAP_DMA_COLOR_DIS:
- break;
- default:
- BUG();
- }
- p-dma_write(val, CCR, lch);
-
- color = 0xff;
- p-dma_write(color, COLOR, lch);
- }
-}
-EXPORT_SYMBOL(omap_set_dma_color_mode);
-
void omap_set_dma_write_mode(int lch, enum omap_dma_write_mode mode)
{
if (dma_omap2plus()) {
@@ -417,16 +359,6 @@ void omap_set_dma_params(int lch, struct
omap_dma_channel_params *params)
}
EXPORT_SYMBOL(omap_set_dma_params);
-void omap_set_dma_src_index(int lch, int eidx, int fidx)
-{
- if (dma_omap2plus())
- return;
-
- p-dma_write(eidx, CSEI, lch);
- p-dma_write(fidx, CSFI, lch);
-}
-EXPORT_SYMBOL(omap_set_dma_src_index);
-
void omap_set_dma_src_data_pack(int lch, int enable)
{
u32 l;
@@ -510,16 +442,6 @@ void omap_set_dma_dest_params(int lch, int dest_port, int
dest_amode,
}
EXPORT_SYMBOL(omap_set_dma_dest_params);
-void omap_set_dma_dest_index(int lch, int eidx, int fidx)
-{
- if (dma_omap2plus())
- return;
-
- p-dma_write(eidx, CDEI, lch);
- p-dma_write(fidx, CDFI, lch);
-}
-EXPORT_SYMBOL(omap_set_dma_dest_index);
-
void omap_set_dma_dest_data_pack(int lch, int enable)
{
u32 l;
@@ -843,7 +765,7 @@ EXPORT_SYMBOL(omap_dma_set_global_params);
* Both of the above can be set with one of the following values :
* DMA_CH_PRIO_HIGH/DMA_CH_PRIO_LOW
*/
-int
+static int
omap_dma_set_prio_lch(int lch, unsigned char read_prio,
unsigned char write_prio)
{
@@ -864,13 +786,13 @@ omap_dma_set_prio_lch(int lch, unsigned char read_prio,
return 0;
}
-EXPORT_SYMBOL(omap_dma_set_prio_lch);
+
/*
* Clears any DMA state so the DMA engine is ready to restart with new buffers
* through omap_start_dma(). Any buffers in flight are discarded.
*/
-void omap_clear_dma(int lch)
+static void omap_clear_dma(int lch)
{
unsigned long flags;
@@ -878,7 +800,6 @@ void omap_clear_dma(int lch)
p-clear_dma(lch);
local_irq_restore(flags);
}
-EXPORT_SYMBOL(omap_clear_dma);
void omap_start_dma(int lch)
{
@@
Re: [alsa-devel] [PATCH v3 0/5] Beaglebone-Black HDMI audio
On 17 September 2014 06:40, Jyri Sarha jsa...@ti.com wrote: Changes since v2: - Change compatible property from ti,gpio-clock to ti,gpio-gate-clock - Some minor cleanups The code has a functional dependency to: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg109264.html Without the above patch the audio card does not probe. The code has been rebased on top of Linux 3.17-rc5. The patches bellow, the above dependency, and couple of commits to add BBB HDMI audio support to omap2plus_defconfig can be pulled from: https://github.com/jsarha/linux.git linux-master-bbb-hdmi-audio How do you intend to get this merge, sending patchsets like this without indication to maintainers on a merge strategy is kinda messy. I'm not sure how maintained tilcdc is. Dave. Cheers, Jyri Jyri Sarha (5): clk: ti: add ti,gpio-gate-clock controlled clock drm/tilcdc: Add I2S HDMI audio config for tda998x ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus ASoC: davinci: HDMI audio build for AM33XX and TDA998x ARM: dts: am335x-boneblack: Add HDMI audio support .../bindings/clock/ti/gpio-gate-clock.txt | 21 ++ .../bindings/sound/davinci-evm-audio.txt |6 +- arch/arm/boot/dts/am335x-boneblack.dts | 52 + drivers/clk/ti/Makefile|2 +- drivers/clk/ti/gpio.c | 202 drivers/gpu/drm/tilcdc/tilcdc_slave.c | 24 ++- sound/soc/davinci/Kconfig | 12 ++ sound/soc/davinci/davinci-evm.c| 82 +++- 8 files changed, 395 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt create mode 100644 drivers/clk/ti/gpio.c -- 1.7.9.5 ___ Alsa-devel mailing list alsa-de...@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel -- 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
