RE: [PATCH] omap_vout: Set DSS overlay_info only if paddr is non zero
On Fri, Mar 09, 2012 at 05:17:41, Laurent Pinchart wrote: Hi Archit, On Wednesday 07 March 2012 14:31:16 Archit Taneja wrote: The omap_vout driver tries to set the DSS overlay_info using set_overlay_info() when the physical address for the overlay is still not configured. This happens in omap_vout_probe() and vidioc_s_fmt_vid_out(). The calls to omapvid_init(which internally calls set_overlay_info()) are removed from these functions. They don't need to be called as the omap_vout_device struct anyway maintains the overlay related changes made. Also, remove the explicit call to set_overlay_info() in vidioc_streamon(), this was used to set the paddr, this isn't needed as omapvid_init() does the same thing later. These changes are required as the DSS2 driver since 3.3 kernel doesn't let you set the overlay info with paddr as 0. Signed-off-by: Archit Taneja arc...@ti.com Thanks for the patch. This seems to fix memory corruption that would result in sysfs-related crashes such as [ 31.279541] [ cut here ] [ 31.284423] WARNING: at fs/sysfs/file.c:343 sysfs_open_file+0x70/0x1f8() [ 31.291503] missing sysfs attribute operations for kobject: (null) [ 31.298004] Modules linked in: mt9p031 aptina_pll omap3_isp [ 31.303924] [c0018260] (unwind_backtrace+0x0/0xec) from [c0034488] (warn_slowpath_common+0x4c/0x64) [ 31.313812] [c0034488] (warn_slowpath_common+0x4c/0x64) from [c0034520] (warn_slowpath_fmt+0x2c/0x3c) [ 31.323913] [c0034520] (warn_slowpath_fmt+0x2c/0x3c) from [c01219bc] (sysfs_open_file+0x70/0x1f8) [ 31.333618] [c01219bc] (sysfs_open_file+0x70/0x1f8) from [c00ccc94] (__dentry_open+0x1f8/0x30c) [ 31.343139] [c00ccc94] (__dentry_open+0x1f8/0x30c) from [c00cce58] (nameidata_to_filp+0x50/0x5c) [ 31.352752] [c00cce58] (nameidata_to_filp+0x50/0x5c) from [c00db4c0] (do_last+0x55c/0x6a0) [ 31.361999] [c00db4c0] (do_last+0x55c/0x6a0) from [c00db6bc] (path_openat+0xb8/0x37c) [ 31.370605] [c00db6bc] (path_openat+0xb8/0x37c) from [c00dba60] (do_filp_open+0x30/0x7c) [ 31.379486] [c00dba60] (do_filp_open+0x30/0x7c) from [c00cc904] (do_sys_open+0xd8/0x170) [ 31.388366] [c00cc904] (do_sys_open+0xd8/0x170) from [c0012760] (ret_fast_syscall+0x0/0x3c) [ 31.397552] ---[ end trace 13639ab74f345d7e ]--- Tested-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Thanks Laurent for testing this patch. Please push it to v3.3 :-) Will send a pull request today itself. Thanks, Vaibhav -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: Fix compile error when FB_OMAP2 is not set
On Thu, 2012-03-08 at 12:46 -0800, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [120308 12:11]:
Otherwise we will get:
arch/arm/plat-omap/fb.c:101: error: expected ‘)’ before ‘*’ token
Signed-off-by: Tony Lindgren t...@atomide.com
---
Tomi, you need something like this for what you have in for-next.
--- a/arch/arm/plat-omap/fb.c
+++ b/arch/arm/plat-omap/fb.c
@@ -98,6 +98,8 @@ arch_initcall(omap_init_fb);
#else
-void __init omapfb_set_lcd_config(omap_lcd_config *config) { }
+void __init omapfb_set_lcd_config(const struct omap_lcd_config *config)
+{
+}
#endif
Also now seeing the following with what you have in for-next:
drivers/video/omap2/displays/panel-taal.c: In function ‘taal_num_errors_show’:
drivers/video/omap2/displays/panel-taal.c:605: warning: ‘errors’ may be used
uninitialized in this function
Hmm, my compiler doesn't complain (codesourcery 2010.09-50), so I didn't
notice that. Which compiler version reports the warning?
I'm not 100% sure, but I think it's a false warning, the code path that
uses errors should only be ran when errors has been set.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 5/9] ARM: OMAP36xx: hwmod data: fix SmartReflex interface data
Hi Paul, On Fri, Mar 9, 2012 at 4:51 AM, Paul Walmsley p...@pwsan.com wrote: Dropping this patch from this series due to conflicts with the SmartReflex branch. It will be moved to a subsequent series. I can take this change as part of the series I am preparing for the SR conversion to drivers/. What do you thin? - Paul Jean -- 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 -- 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 05/13] gpio/omap: get rid of retrigger variable in gpio_irq_handler
On Wed, Mar 7, 2012 at 4:45 PM, Tarun Kanti DebBarma tarun.ka...@ti.com wrote: This local variable is just assigned zero and then OR'ed with isr. It does not appear to serve any purpose and so removing it. Missed following comments from Kevin given in v2. Sorry about that. I have updated the change in: git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev for_3.4/gpio_further_cleanup_fixes commit 672e302e3c (ARM: OMAP: use edge/level handlers from generic IRQ framework) removed retrigger support in favor of using generic IRQ framework. This patch cleans up some unused remnants of that removal. -- Tarun Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Felipe Balbi ba...@ti.com --- drivers/gpio/gpio-omap.c | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index 3765654..de5fe8f 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -626,7 +626,6 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc) u32 isr; unsigned int gpio_irq, gpio_index; struct gpio_bank *bank; - u32 retrigger = 0; int unmasked = 0; struct irq_chip *chip = irq_desc_get_chip(desc); @@ -663,8 +662,6 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc) chained_irq_exit(chip, desc); } - isr |= retrigger; - retrigger = 0; if (!isr) break; -- 1.7.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 0/2] ARM/ASoC: OMAP: McBSP config cleanup
Hi, Since the McBSP driver has been moved out from arch/arm/plat-omap/ and it is combined as a single driver with the sound/soc/omap/omap-mcbsp.c there is no longer need to have CONFIG_OMAP_MCBSP. This series cleans up the Kconfigs, and Makefiles. Also it is fixes the issue that the OMAP audio drivers were not buildable as modules (the ones using McBSP) reported by Grazvydas Ignotas nota...@gmail.com I have generated this series on top of Liam's for-3.4 branch. The arch/arm/mach-omap* patch applies cleanly on top of todays linux-next, so if this series goes via ASoC we are not going to have conflicts with stuff coming via l-o. Tested on BeagleBoard, and SDP4430, compile tested for OMAP1. This series should go via ASoC along with the rest of the McBSP changes. Regards, Peter --- Peter Ujfalusi (2): ARM: OMAP: Remove CONFIG_OMAP_MCBSP references ASoC: OMAP: Build config cleanup for McBSP arch/arm/mach-omap1/Kconfig |3 --- arch/arm/mach-omap1/Makefile |4 +++- arch/arm/mach-omap2/Makefile |4 +++- sound/soc/omap/Kconfig |6 -- sound/soc/omap/Makefile |3 +-- 5 files changed, 7 insertions(+), 13 deletions(-) -- 1.7.8.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP: Remove CONFIG_OMAP_MCBSP references
The McBSP driver stack has been moved to ASoC. The CONFIG_OMAP_MCBSP will be removed since the CONFIG_SND_OMAP_SOC_MCBSP will trigger to build the McBSP (audio) drivers. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- arch/arm/mach-omap1/Kconfig |3 --- arch/arm/mach-omap1/Makefile |4 +++- arch/arm/mach-omap2/Makefile |4 +++- 3 files changed, 6 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig index 4f8d66f..922ab0d 100644 --- a/arch/arm/mach-omap1/Kconfig +++ b/arch/arm/mach-omap1/Kconfig @@ -37,7 +37,6 @@ comment OMAP Board Type config MACH_OMAP_INNOVATOR bool TI Innovator depends on ARCH_OMAP1 (ARCH_OMAP15XX || ARCH_OMAP16XX) - select OMAP_MCBSP help TI OMAP 1510 or 1610 Innovator board support. Say Y here if you have such a board. @@ -45,7 +44,6 @@ config MACH_OMAP_INNOVATOR config MACH_OMAP_H2 bool TI H2 Support depends on ARCH_OMAP1 ARCH_OMAP16XX - select OMAP_MCBSP help TI OMAP 1610/1611B H2 board support. Say Y here if you have such a board. @@ -72,7 +70,6 @@ config MACH_HERALD config MACH_OMAP_OSK bool TI OSK Support depends on ARCH_OMAP1 ARCH_OMAP16XX - select OMAP_MCBSP help TI OMAP 5912 OSK (OMAP Starter Kit) board support. Say Y here if you have such a board. diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile index 11c85cd..9923f92 100644 --- a/arch/arm/mach-omap1/Makefile +++ b/arch/arm/mach-omap1/Makefile @@ -6,7 +6,9 @@ obj-y := io.o id.o sram.o time.o irq.o mux.o flash.o serial.o devices.o dma.o obj-y += clock.o clock_data.o opp_data.o reset.o pm_bus.o timer.o -obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o +ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),) +obj-y += mcbsp.o +endif obj-$(CONFIG_OMAP_32K_TIMER) += timer32k.o diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index bd76394..06326a6 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -17,7 +17,9 @@ obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(hwmod-common) obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(hwmod-common) $(secure-common) obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common) $(secure-common) -obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o +ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),) +obj-y += mcbsp.o +endif obj-$(CONFIG_TWL4030_CORE) += omap_twl.o -- 1.7.8.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ASoC: OMAP: Build config cleanup for McBSP
The McBSP driver stack has been moved, and rewritten resulting a single driver - selected by CONFIG_SND_OMAP_SOC_MCBSP. There is no longer need to have CONFIG_OMAP_MCBSP anymore. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- sound/soc/omap/Kconfig |6 -- sound/soc/omap/Makefile |3 +-- 2 files changed, 1 insertions(+), 8 deletions(-) diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index 4bb7802..deafbfa 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -5,13 +5,8 @@ config SND_OMAP_SOC config SND_OMAP_SOC_DMIC tristate -config OMAP_MCBSP - tristate - depends on ARCH_OMAP - config SND_OMAP_SOC_MCBSP tristate - select OMAP_MCBSP config SND_OMAP_SOC_MCPDM tristate @@ -31,7 +26,6 @@ config SND_OMAP_SOC_N810 config SND_OMAP_SOC_RX51 tristate SoC Audio support for Nokia RX-51 depends on SND_OMAP_SOC MACH_NOKIA_RX51 - select OMAP_MCBSP select SND_OMAP_SOC_MCBSP select SND_SOC_TLV320AIC3X select SND_SOC_TPA6130A2 diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile index 9f8fbd5..1d656bc 100644 --- a/sound/soc/omap/Makefile +++ b/sound/soc/omap/Makefile @@ -1,13 +1,12 @@ # OMAP Platform Support snd-soc-omap-objs := omap-pcm.o snd-soc-omap-dmic-objs := omap-dmic.o -snd-soc-omap-mcbsp-objs := omap-mcbsp.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 obj-$(CONFIG_SND_OMAP_SOC) += snd-soc-omap.o obj-$(CONFIG_SND_OMAP_SOC_DMIC) += snd-soc-omap-dmic.o -obj-$(CONFIG_OMAP_MCBSP) += mcbsp.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 -- 1.7.8.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] hsmmc cleanups in platform callback routines
This series mainly splits the platform callbacks implemented in hsmmc.c (for clk source selection and pbiascell programming) rather than doing everything in a single callback which is what is done today. This cleanup is ground work before all these callbacks are moved into hsmmc/system-control module driver out of machine folder. Patches tested on omap3 beagle-Xm and omap4 panda boards. regards, Rajendra Rajendra Nayak (4): ARM: OMAP2+: hsmmc: Add a flag to identify modules supporting clock src selection ARM: OMAP2+: hsmmc: Split the clock src selection and pbias programming ARM: OMAP2+: hsmmc: Let board files specify if an external transceiver exists ARM: OMAP2430SDP: No support to switch to external clock on omap2430 arch/arm/mach-omap2/board-2430sdp.c|1 - arch/arm/mach-omap2/hsmmc.c| 101 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 14 +++- arch/arm/plat-omap/include/plat/mmc.h |2 + drivers/mmc/host/omap_hsmmc.c |3 + 5 files changed, 58 insertions(+), 63 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: OMAP2+: hsmmc: Split the clock src selection and pbias programming
While the pbias programming is something needed every time a regulator
output voltage is changed, the clock source selection to select between
an internal loopback and external clock seems like a one time setting.
These are today clubbed into a single platform callback, called from
the driver for every regulator voltage switch. Split these into seperate
callbacks and make the driver do this once at setup.
Also some platforms like AM35x seem to be doing this using a .set_power
callback, which seems completely orthogonal to what the callback is
expected to do.
Lastly, though the System control module has the registers to control
clock source selection, even on OMAP2430, the latest 2430 TRM version Z
clearly mentions in Table 7-135 and Table 7-154, that these bits are not
useful/used on OMAP2430. So get rid of control_devconf1_offset and just
use the OMAP3 based offsets for the register.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Balaji TK balaj...@ti.com
Cc: Venkatraman S svenk...@ti.com
Cc: Chris Ball c...@laptop.org
---
arch/arm/mach-omap2/hsmmc.c | 86 ++---
arch/arm/plat-omap/include/plat/mmc.h |1 +
drivers/mmc/host/omap_hsmmc.c |3 +
3 files changed, 40 insertions(+), 50 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 11e26fc..0133b29 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -27,7 +27,6 @@
#if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
static u16 control_pbias_offset;
-static u16 control_devconf1_offset;
static u16 control_mmc1;
#define HSMMC_NAME_LEN 9
@@ -43,6 +42,32 @@ static int hsmmc_get_context_loss(struct device *dev)
#define hsmmc_get_context_loss NULL
#endif
+static void hsmmc1_select_input_clk_src(struct device *dev)
+{
+ u32 reg;
+ struct omap_mmc_platform_data *mmc = dev-platform_data;
+
+ reg = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0);
+ if (mmc-slots[0].internal_clock)
+ reg |= OMAP2_MMCSDIO1ADPCLKISEL;
+ else
+ reg = ~OMAP2_MMCSDIO1ADPCLKISEL;
+ omap_ctrl_writel(reg, OMAP2_CONTROL_DEVCONF0);
+}
+
+static void hsmmc2_select_input_clk_src(struct device *dev)
+{
+ u32 reg;
+ struct omap_mmc_platform_data *mmc = dev-platform_data;
+
+ reg = omap_ctrl_readl(OMAP343X_CONTROL_DEVCONF1);
+ if (mmc-slots[0].internal_clock)
+ reg |= OMAP2_MMCSDIO2ADPCLKISEL;
+ else
+ reg = ~OMAP2_MMCSDIO2ADPCLKISEL;
+ omap_ctrl_writel(reg, OMAP343X_CONTROL_DEVCONF1);
+}
+
static void omap_hsmmc1_before_set_reg(struct device *dev, int slot,
int power_on, int vdd)
{
@@ -72,12 +97,6 @@ static void omap_hsmmc1_before_set_reg(struct device *dev,
int slot,
omap_ctrl_writel(reg, OMAP243X_CONTROL_DEVCONF1);
}
- if (mmc-slots[0].internal_clock) {
- reg = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0);
- reg |= OMAP2_MMCSDIO1ADPCLKISEL;
- omap_ctrl_writel(reg, OMAP2_CONTROL_DEVCONF0);
- }
-
reg = omap_ctrl_readl(control_pbias_offset);
if (cpu_is_omap3630()) {
/* Set MMC I/O to 52Mhz */
@@ -171,17 +190,6 @@ static void omap4_hsmmc1_after_set_reg(struct device *dev,
int slot,
}
}
-static void hsmmc2_select_input_clk_src(struct omap_mmc_platform_data *mmc)
-{
- u32 reg;
-
- reg = omap_ctrl_readl(control_devconf1_offset);
- if (mmc-slots[0].internal_clock)
- reg |= OMAP2_MMCSDIO2ADPCLKISEL;
- else
- reg = ~OMAP2_MMCSDIO2ADPCLKISEL;
- omap_ctrl_writel(reg, control_devconf1_offset);
-}
static void hsmmc2_before_set_reg(struct device *dev, int slot,
int power_on, int vdd)
@@ -190,26 +198,6 @@ static void hsmmc2_before_set_reg(struct device *dev, int
slot,
if (mmc-slots[0].remux)
mmc-slots[0].remux(dev, slot, power_on);
-
- if (power_on)
- hsmmc2_select_input_clk_src(mmc);
-}
-
-static int am35x_hsmmc2_set_power(struct device *dev, int slot,
- int power_on, int vdd)
-{
- struct omap_mmc_platform_data *mmc = dev-platform_data;
-
- if (power_on)
- hsmmc2_select_input_clk_src(mmc);
-
- return 0;
-}
-
-static int nop_mmc_set_power(struct device *dev, int slot, int power_on,
- int vdd)
-{
- return 0;
}
static inline void omap_hsmmc_mux(struct omap_mmc_platform_data
*mmc_controller,
@@ -387,9 +375,6 @@ static int omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c,
}
}
- if (cpu_is_omap3517() || cpu_is_omap3505())
- mmc-slots[0].set_power = nop_mmc_set_power;
-
[PATCH 1/4] ARM: OMAP2+: hsmmc: Add a flag to identify modules supporting clock src selection
hsmmc2_before_set_reg() seems to do a clock source selection (supported
only on some mmc IP blocks) but decides to do so based on a 'HSMMC_HAS_PBIAS'
feature flag which seems completely wrong. Fix this by adding a new controller
flag 'OMAP_HSMMC_SUPPORTS_CLKSRC_SELECT' which can be then used to identify
which
controller instance supports this feature.
Looking at the TRM for OMAP2/3/4, it turns out only the 2 controller instances
on
OMAP3 support this, so update this flag in the .dev_attr structure for the
corresponding hwmods.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Balaji TK balaj...@ti.com
Cc: Venkatraman S svenk...@ti.com
Cc: Chris Ball c...@laptop.org
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/hsmmc.c| 15 +++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 14 +++---
arch/arm/plat-omap/include/plat/mmc.h |1 +
3 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 19dd165..11e26fc 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -408,8 +408,7 @@ static int omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c,
c-caps = ~MMC_CAP_8_BIT_DATA;
c-caps |= MMC_CAP_4_BIT_DATA;
}
- if (mmc-slots[0].features HSMMC_HAS_PBIAS) {
- /* off-chip level shifting, or none */
+ if (mmc-controller_flags OMAP_HSMMC_SUPPORTS_CLKSRC_SELECT) {
mmc-slots[0].before_set_reg = hsmmc2_before_set_reg;
mmc-slots[0].after_set_reg = NULL;
}
@@ -447,12 +446,6 @@ void omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo,
int ctrl_nr)
goto done;
}
- if (omap_hsmmc_pdata_init(hsmmcinfo, mmc_data) 0) {
- pr_err(%s fails!\n, __func__);
- goto done;
- }
- omap_hsmmc_mux(mmc_data, (ctrl_nr - 1));
-
name = omap_hsmmc;
l = snprintf(oh_name, MAX_OMAP_MMC_HWMOD_NAME_LEN,
@@ -471,6 +464,12 @@ void omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo,
int ctrl_nr)
mmc_data-controller_flags = mmc_dev_attr-flags;
}
+ if (omap_hsmmc_pdata_init(hsmmcinfo, mmc_data) 0) {
+ pr_err(%s fails!\n, __func__);
+ goto done;
+ }
+ omap_hsmmc_mux(mmc_data, (ctrl_nr - 1));
+
pdev = omap_device_build(name, ctrl_nr - 1, oh, mmc_data,
sizeof(struct omap_mmc_platform_data), NULL, 0, false);
if (IS_ERR(pdev)) {
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 3c8dd92..236785f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3145,13 +3145,15 @@ static struct omap_hwmod_ocp_if *omap3xxx_mmc1_slaves[]
= {
};
static struct omap_mmc_dev_attr mmc1_dev_attr = {
- .flags = OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
+ .flags = (OMAP_HSMMC_SUPPORTS_DUAL_VOLT |
+ OMAP_HSMMC_SUPPORTS_CLKSRC_SELECT),
};
/* See 35xx errata 2.1.1.128 in SPRZ278F */
static struct omap_mmc_dev_attr mmc1_pre_es3_dev_attr = {
.flags = (OMAP_HSMMC_SUPPORTS_DUAL_VOLT |
- OMAP_HSMMC_BROKEN_MULTIBLOCK_READ),
+ OMAP_HSMMC_BROKEN_MULTIBLOCK_READ |
+ OMAP_HSMMC_SUPPORTS_CLKSRC_SELECT),
};
static struct omap_hwmod omap3xxx_pre_es3_mmc1_hwmod = {
@@ -3219,9 +3221,14 @@ static struct omap_hwmod_ocp_if *omap3xxx_mmc2_slaves[]
= {
omap3xxx_l4_core__mmc2,
};
+static struct omap_mmc_dev_attr mmc2_dev_attr = {
+ .flags = OMAP_HSMMC_SUPPORTS_CLKSRC_SELECT,
+};
+
/* See 35xx errata 2.1.1.128 in SPRZ278F */
static struct omap_mmc_dev_attr mmc2_pre_es3_dev_attr = {
- .flags = OMAP_HSMMC_BROKEN_MULTIBLOCK_READ,
+ .flags = (OMAP_HSMMC_BROKEN_MULTIBLOCK_READ |
+ OMAP_HSMMC_SUPPORTS_CLKSRC_SELECT),
};
static struct omap_hwmod omap3xxx_pre_es3_mmc2_hwmod = {
@@ -3262,6 +3269,7 @@ static struct omap_hwmod omap3xxx_es3plus_mmc2_hwmod = {
.idlest_idle_bit = OMAP3430_ST_MMC2_SHIFT,
},
},
+ .dev_attr = mmc2_dev_attr,
.slaves = omap3xxx_mmc2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_mmc2_slaves),
.class = omap34xx_mmc_class,
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index f75946c..5d9c98b 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -49,6 +49,7 @@
*/
#define OMAP_HSMMC_SUPPORTS_DUAL_VOLT BIT(0)
#define OMAP_HSMMC_BROKEN_MULTIBLOCK_READ BIT(1)
+#define OMAP_HSMMC_SUPPORTS_CLKSRC_SELECT BIT(2)
struct omap_mmc_dev_attr {
u8 flags;
--
1.7.1
--
To unsubscribe from this list:
[PATCH 4/4] ARM: OMAP2430SDP: No support to switch to external clock on omap2430
As stated in the latest 2430 TRM version Z, Table 7-135 and Table 7-154,
omap2430 does not support switching between internal loopback and external
clock for MMC modules. This is supported only on some instances of MMC
modules on omap3430 only.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Balaji TK balaj...@ti.com
Cc: Venkatraman S svenk...@ti.com
---
arch/arm/mach-omap2/board-2430sdp.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 7370983..eb70b00 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -249,7 +249,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
.caps = MMC_CAP_4_BIT_DATA,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
- .ext_clock = 1,
},
{} /* Terminator */
};
--
1.7.1
--
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: OMAP2+: hsmmc: Let board files specify if an external transceiver exists
The omap2_hsmmc_info structure provides a way for board files to specify
if an external transciever exists for the mmc module. So get rid of the
assumption based on external clock.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Balaji TK balaj...@ti.com
Cc: Venkatraman S svenk...@ti.com
---
arch/arm/mach-omap2/hsmmc.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 0133b29..0aa4587 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -387,8 +387,6 @@ static int omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c,
mmc-select_input_clk_src = hsmmc1_select_input_clk_src;
break;
case 2:
- if (c-ext_clock)
- c-transceiver = 1;
if (c-transceiver (c-caps MMC_CAP_8_BIT_DATA)) {
c-caps = ~MMC_CAP_8_BIT_DATA;
c-caps |= MMC_CAP_4_BIT_DATA;
--
1.7.1
--
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/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree
Hi Grant,
On Friday 09 March 2012 11:12 AM, Grant Likely wrote:
On Thu, 23 Feb 2012 17:31:27 +0530, Rajendra Nayakrna...@ti.com wrote:
Define dt bindings for the ti-omap-hsmmc, and adapt
the driver to extract data (which was earlier passed as
platform_data) from device tree.
Signed-off-by: Rajendra Nayakrna...@ti.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 31 +
drivers/mmc/host/omap_hsmmc.c | 68
2 files changed, 99 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
new file mode 100644
index 000..e4fa8f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -0,0 +1,31 @@
+* TI Highspeed MMC host controller for OMAP
+
+The Highspeed MMC Host Controller on TI OMAP family
+provides an interface for MMC, SD, and SDIO types of memory cards.
+
+Required properties:
+- compatible:
+ Should be ti,omap2-hsmmc, for OMAP2/3 controllers
+ Should be ti,omap4-hsmmc, for OMAP4 controllers
+- ti,hwmods: Must be mmcn, n is controller instance starting 1
+- reg : should contain hsmmc registers location and length
+
+Optional properties:
+ti,dual-volt: boolean, supports dual voltage cards
+supply-name-supply: phandle to the regulator device tree node
+supply-name examples are vmmc, vmmc_aux etc
+ti,bus-width: Number of data lines, default assumed is 1 if the property is
missing.
+cd-gpios: GPIOs for card detection
+wp-gpios: GPIOs for write protection
+ti,non-removable: non-removable slot (like eMMC)
Binding looks okay. A couple comments below...
[...]
+static const struct of_device_id omap_mmc_of_match[];
If you move the omap_mmc_of_match[] table up to here then there is no
need for the forward declaration.
+
static int __init omap_hsmmc_probe(struct platform_device *pdev)
{
struct omap_mmc_platform_data *pdata = pdev-dev.platform_data;
@@ -1725,6 +1768,14 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
struct omap_hsmmc_host *host = NULL;
struct resource *res;
int ret, irq;
+ const struct of_device_id *match;
+
+ match = of_match_device(omap_mmc_of_match,pdev-dev);
+ if (match) {
+ pdata = of_get_hsmmc_pdata(pdev-dev);
+ if (match-data)
+ pdata-reg_offset = *(u16 *)match-data;
Blech on the ugly cast. It is slightly safer to do thusly:
u16 *offsetp = match-data;
pdata-reg_offset = *offsetp
thanks for the review. I'll repost with these changes.
regards,
Rajendra
+ }
if (pdata == NULL) {
dev_err(pdev-dev, Platform Data is missing\n);
@@ -2120,12 +2171,29 @@ static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
.runtime_resume = omap_hsmmc_runtime_resume,
};
+#if defined(CONFIG_OF)
+static u16 omap4_reg_offset = 0x100;
+
+static const struct of_device_id omap_mmc_of_match[] = {
+ {
+ .compatible = ti,omap2-hsmmc,
+ },
+ {
+ .compatible = ti,omap4-hsmmc,
+ .data =omap4_reg_offset,
+ },
+ {},
+}
+MODULE_DEVICE_TABLE(of, omap_mmc_of_match);
+#endif
+
static struct platform_driver omap_hsmmc_driver = {
.remove = omap_hsmmc_remove,
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
.pm =omap_hsmmc_dev_pm_ops,
+ .of_match_table = of_match_ptr(omap_mmc_of_match),
},
};
--
1.7.1
___
linaro-dev mailing list
linaro-...@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
--
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 12/13] gpio/omap: fix incorrect context restore logic in omap_gpio_runtime_resume
On Thu, Mar 8, 2012 at 12:49 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Thu, Mar 8, 2012 at 4:58 AM, DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
On Wed, Mar 7, 2012 at 5:37 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On Wednesday 07 March 2012 12:16 PM, Tarun Kanti DebBarma wrote:
In omap_gpio_runtime_resume() the context restore should be independent
of bank-enabled_non_wakeup_gpios. This was preventing context restore
of GPIO lines which are not wakeup enabled.
Reported-by: Govindraj Raja govindraj.r...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
drivers/gpio/gpio-omap.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 2e8e476..ccfbae0 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1227,7 +1227,7 @@ static int omap_gpio_runtime_resume(struct device
*dev)
__raw_writel(bank-context.risingdetect,
bank-base + bank-regs-risingdetect);
- if (!bank-enabled_non_wakeup_gpios || !bank-workaround_enabled) {
+ if (!bank-workaround_enabled) {
This doesn't seem to be right.
Don't you want to avoid GPIO restore for banks which are in
always on domain. Infact the purpose of enabled_non_wakeup_gpios
is exactly that ? Isn't it.
What am I missing ?
The bank-enabled_non_wakeup_gpios is set whenever a gpio line is programmed
as edge trigger as shown below.
(This is not meant to distinguish between gpios in WKUP domain vs
those in PER domain).
The context restore should happen irrespective of whether the trigger
type is edge or level.
In fact context restore was not happening for a gpio line because of
this condition while
testing suspend/resume.
[...]
if (trigger IRQ_TYPE_EDGE_BOTH)
bank-enabled_non_wakeup_gpios |= gpio_bit;
else
bank-enabled_non_wakeup_gpios = ~gpio_bit;
[...]
Make sense now. Thanks for clarification Tarun.
You can add mine..
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Thanks.
I have missed removing the same change from omap_gpio_runtime_suspend().
@@ -1178,9 +1178,6 @@ static int omap_gpio_runtime_suspend(struct device *dev)
* non-wakeup GPIOs. Otherwise spurious IRQs will be
* generated. See OMAP2420 Errata item 1.101.
*/
- if (!(bank-enabled_non_wakeup_gpios))
- goto update_gpio_context_count;
-
FYI, I tested the change on OMAP5 code-base which did not have the above change.
Anyways, I have updated the change in:
git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev
for_3.4/gpio_further_cleanup_fixes
--
Tarun
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data
On Friday 09 March 2012 11:16 AM, Grant Likely wrote:
On Fri, 24 Feb 2012 10:49:00 -0800, Tony Lindgrent...@atomide.com wrote:
* Rajendra Nayakrna...@ti.com [120223 19:29]:
On Friday 24 February 2012 12:27 AM, Tony Lindgren wrote:
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -113,5 +113,31 @@
#size-cells =0;
ti,hwmods = i2c3;
};
+
+ mmc1: mmc@1 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ };
+
+ mmc2: mmc@2 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc2;
+ };
+
+ mmc3: mmc@3 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc3;
+ };
+
+ mmc4: mmc@4 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc4;
+ };
+
+ mmc5: mmc@5 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc5;
+ };
};
};
These all should all be ti,omap3-hsmmc I guess?
Well, I defined the binding such that both omap2 and omap3
can use the same compatible ti,omap2-hsmmc since there is
no difference in the way they are defined or handled. If thats
confusing, I can have separate compatibles.
Btw, I guess we do the same with a few other re-used IPs as well,
I just checked and mcpsi does the same.
Yeah let's use separate compatibles to avoid confusion.
For omap2 we also have the ti,omap2-mmc in addition to
ti,omap2-hsmmc..
Yes, absolutely use separate compatible values. It is always important
to be specific as to the silicon implementing the IP. The omap3 instance
can also carry the omap2 string in its compatible list:
compatible = ti,omap3-hsmmc, ti,omap2-hsmmc;
Sure, will repost with seperate compatible strings. Also missed adding
the 'status = disable;' for unused mmc blocks in the board .dts file
causing unused mmc modules to get probed too. Will fix that as well.
thanks,
Rajendra
g.
--
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 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data
Hi Paul, On Friday 09 March 2012 12:21 PM, Paul Walmsley wrote: On Thu, 8 Mar 2012, Grant Likely wrote: Yes, absolutely use separate compatible values. It is always important to be specific as to the silicon implementing the IP. In that case, it is probably best to use the full chip name in the compatible string, e.g., omap2420 or omap2430 rather than just omap2. Since omap2420 and omap2430 have different MMC controllers (and these bindings only cover the hsmmc controller used in 2430 and beyond, I haven't done the bindings for the legacy one yet), the idea was to differentiate between omap2420 and omap2430 by using compatible of ti,omap2-hsmmc for the High-Speed controller used in OMAP2 (2430) and ti,omap2-mmc for the legacy one used in OMAP2 (2420). Does that sound good to you? Particularly in the case of OMAP3, which is a largely meaningless group these days with AM33xx, OMAP34xx, OMAP36xx, and AM3517, many of which are quite different from each other... But these bindings are specific and limited to HSMMC module which is not quite different in the different SoC variants. There is a single driver to handle hsmmc module on all the SoCs which does not need to differentiate which SoC it is on. regards, Rajendra - 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
mmc_delayed_work error
Hi, When i suspend the system, i get 0 : OFF, 1 : RETENTION, 2 : ON-INACTIVE, 3 : ON-ACTIVE Powerdomain (core_pwrdm) entered state 1 Powerdomain (gfx_pwrdm) is in state 0 Powerdomain (abe_pwrdm) entered state 0 Powerdomain (dss_pwrdm) is in state 0 Powerdomain (tesla_pwrdm) entered state 0 Powerdomain (wkup_pwrdm) is in state 0 Powerdomain (cpu0_pwrdm) entered state 0 Powerdomain (cpu1_pwrdm) entered state 0 Powerdomain (emu_pwrdm) is in state 0 Powerdomain (mpu_pwrdm) entered state 0 Powerdomain (ivahd_pwrdm) entered state 0 Powerdomain (cam_pwrdm) is in state 0 Powerdomain (l3init_pwrdm) entered state 1 Powerdomain (l4per_pwrdm) entered state 1 Powerdomain (always_on_core_pwrdm) is in state 0 Powerdomain (cefuse_pwrdm) is in state 0 PM: early resume of devices complete after 0.854 msecs wakeup wake lock: mmc_delayed_work PM: resume of devices complete after 150.054 msecs Restarting tasks ... mmc_delayed_work keeps looping. Any idea on whats going wrong. Am using 2.6.35. -- Cheers!! Allen -- 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 3/3] OMAPDSS: HDMI: Sysfs support to configure quantization
Hi Tomi, On Tue, Feb 14, 2012 at 5:52 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi, The color range is something that desktops have to handle also, so there's probably ways to handle it in DRM. DisplayPort also has the same range setting, so it's not specific to HDMI. So I propose to add a kernel API for this in the omap_dss_driver, so that the users of omapdss may handle setting the range as they see best. I see , it is fine i shall make it generic dss API. Btw, the displayport spec speaks of VESA and CEA ranges. Does HDMI spec only speak about limited/full range? Yes so is the case with HDMI it is full range for VGA and limited range for rest. I also only now realized that we have full/limited range setting in video overlay's ATTRIBUTEs also. And it seems that we currently set it always to 0, i.e. limited range. I wonder if this causes color degradation in case the HDMI/DP output also sets limited range, and thus the color range gets scaled down twice... yes there is a limited/full range bit in dispc for color conversion, did a quick check using analyzer it doesn't impact the HDMI color range, so can confirm there is no degradation. Thanks and regards, Mythri. Tomi -- 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: DSS pwrdm usecount, disabling autodeps for DSS
On Fri, Mar 9, 2012 at 2:42 AM, Kevin Hilman khil...@ti.com wrote: Hi Tomi, A while ago you were asking about why DSS pwrdm counts were so high on OMAP3, and why DSS was transitioning even though it was completely unused. Paul and I just spent some a little time debugging this, and narrowed it down to autodeps. (sorry it took so long, it finally bothered me enough to actually look into it.) I've seen the same happening to usbhost_pwrdm in linux-next, maybe it needs similar patch? Talking about linux-next, musb is crashing there on first register access, just after pm_runtime_get_sync(), maybe something's up with clock related code? CONFIG_PM_RUNTIME was enabled there. -- Gražvydas -- 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: DSS pwrdm usecount, disabling autodeps for DSS
On Thu, 2012-03-08 at 16:42 -0800, Kevin Hilman wrote: Hi Tomi, A while ago you were asking about why DSS pwrdm counts were so high on OMAP3, and why DSS was transitioning even though it was completely unused. Paul and I just spent some a little time debugging this, and narrowed it down to autodeps. (sorry it took so long, it finally bothered me enough to actually look into it.) The patch below fixes the problem at least when DSS is not loaded (DSS just stays in retention), but I didn't try this with any active DSS usage, or loading/unloding the DSS drivers. Could you give the patch below a try on OMAP3 along with some active DSS usage as well as unloading the modules after using. Could you also verify that suspend/resume continues to work for DSS? I didn't get very far with the patch =(. Tested on omap3 overo, with -rc6 based dss tree. loading nfs/work/linux/drivers/video/omap2/dss/omapdss.ko def_disp=lcd43 [ 20.772460] cm: Module associated with clock dss1_alwon_fck didn't enable in 10 tries [ 20.784210] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa050040 [ 20.792297] Internal error: : 1028 [#1] SMP [ 20.796722] Modules linked in: omapdss(+) [ 20.800994] CPU: 0Not tainted (3.3.0-rc6-00050-g53306db-dirty #113) [ 20.808288] PC is at omap_dsshw_probe+0xb0/0x22c [omapdss] [ 20.814086] LR is at trace_hardirqs_on_caller+0xec/0x198 [ 20.819702] pc : [bf001464]lr : [c0089c7c]psr: 6013 [ 20.819702] sp : ce89bd60 ip : 6093 fp : 5b8e [ 20.831787] r10: bf03d000 r9 : c0bdc558 r8 : bf029884 [ 20.837310] r7 : r6 : r5 : cf094008 r4 : bf02a0e8 [ 20.844177] r3 : fa05 r2 : r1 : 0001 r0 : [ 20.851074] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 20.858581] Control: 10c5387d Table: 8e8b4019 DAC: 0015 [ 20.864624] Process insmod (pid: 673, stack limit = 0xce89a2f8) [ 20.870880] Stack: (0xce89bd60 to 0xce89c000) [ 20.875488] bd60: cf094008 c0c13d98 cf09403c c027f08c c027f074 c027de74 cf094008 bf029884 [ 20.884094] bd80: cf09403c bf0297c4 c027e010 bf029884 c027df7c c027c928 [ 20.892730] bda0: cf0196a8 cf082510 bf029884 c06b1260 cea54f40 c027d860 bf01fc50 c022da38 [ 20.901336] bdc0: cf019600 bf029884 bf02a0c4 c0688154 bf0297c4 bf03d000 c027e4d4 [ 20.909973] bde0: c065ca18 bf02a0c4 c0688154 bf0297c4 bf0002a0 cf0c3900 [ 20.918609] be00: c0c13d98 c065ca20 c0c13d98 c065ca54 bf0297c4 c0bdc558 bf03d000 [ 20.927215] be20: 5b8e c027f08c c027f074 c027de74 c065ca20 bf0297c4 c065ca54 [ 20.935852] be40: 0001 c027e010 bf0297c4 c027df7c c027c928 cf0196a8 cf082210 [ 20.944458] be60: bf0297c4 c06b1260 cf3f91c0 c027d860 bf01f5a4 c022da38 cf019600 bf0297c4 [ 20.953094] be80: ce89a000 c06c9800 0001 bf03d000 c027e4d4 ce89a000 [ 20.961700] bea0: c06c9800 0001 bf03d074 bf029f5c c0008648 c069e1d4 bf029f5c [ 20.970336] bec0: 0001 bf03d000 0001 c069e1d0 c006325c cf004400 [ 20.978973] bee0: ce8c5640 bf029f5c bf029fa4 0001 ce825940 0001 c0bdc558 bf029f5c [ 20.987579] bf00: 5b8e c0092af0 bf029f68 cf37d8e0 c078db40 c00907b8 bf0263ec [ 20.996215] bf20: bf03b311 bf029f68 d08ca000 0019725a d09e9aec d09e987e d0a5b6cc 0002b968 [ 21.004821] bf40: 00035448 003c 003d 0024 0028 0016 [ 21.013458] bf60: bf01d7b8 0041 c05b198c [ 21.022064] bf80: be83ee84 0019725a 0003 be83ee84 0080 c0013068 ce89a000 [ 21.030700] bfa0: c0012ea0 0019725a 0003 b6cf4008 0019725a 000a7008 be83ee84 [ 21.039306] bfc0: 0019725a 0003 be83ee84 0080 000a47f8 b6fd [ 21.047943] bfe0: be83ebc8 be83ebb8 00019dfc b6f60020 6010 b6cf4008 8f4fe821 8f4fec21 [ 21.056701] [bf001464] (omap_dsshw_probe+0xb0/0x22c [omapdss]) from [c027f08c] (platform_drv_ probe+0x18/0x1c) [ 21.067535] [c027f08c] (platform_drv_probe+0x18/0x1c) from [c027de74] (driver_probe_device+0x 90/0x198) [ 21.077728] [c027de74] (driver_probe_device+0x90/0x198) from [c027e010] (__driver_attach+0x94 /0x98) [ 21.087646] [c027e010] (__driver_attach+0x94/0x98) from [c027c928] (bus_for_each_dev+0x50/0x7 c) [ 21.097167] [c027c928] (bus_for_each_dev+0x50/0x7c) from [c027d860] (bus_add_driver+0x184/0x2 48) [ 21.106811] [c027d860] (bus_add_driver+0x184/0x248) from [c027e4d4] (driver_register+0x78/0x1 30) [ 21.116516] [c027e4d4] (driver_register+0x78/0x130) from [bf0002a0] (omap_dss_probe+0x34/0x32 c [omapdss]) [ 21.127075] [bf0002a0] (omap_dss_probe+0x34/0x32c [omapdss]) from [c027f08c] (platform_drv_pr obe+0x18/0x1c) [ 21.137725] [c027f08c] (platform_drv_probe+0x18/0x1c) from [c027de74] (driver_probe_device+0x 90/0x198) [ 21.147888] [c027de74]
Re: [GIT PULL] ARM: OMAP2+: PM: core support for SMPS regulators for v3.4
On Thu, Mar 08, 2012 at 04:32:18PM -0800, Tony Lindgren wrote: * Kevin Hilman khil...@ti.com [120308 09:37]: Tony Lindgren t...@atomide.com writes: Oh, that's because it depends on the regulator core changes that are in Mark's regulator tree. You need the for-next branch of : git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git For this to compile correctly. Sorry, I should've been more clear above about the build dependency. Hmm just checking.. Recently Mark replied to Peter: ... So can you guys please confirm that if is indeed an immutable commit to use as a base to merge in something? Absolutely not, the for-next branch is rebuilt frequently especially since it includes stuff sent to Linus and he complained about bugfixes merged up into development code. What is the actual dependency here? The topic branches are more or less static, though some more than others. In general you should warn people if you've got a dependency on their tree, it makes life easier. signature.asc Description: Digital signature
[PATCH] omap_vout: Fix DMA transaction error issue when rotation is enabled
When rotation is enabled and driver is configured in USERPTR buffer exchange mechanism, in specific use-case driver reports an error, DMA transaction error with device 0. In driver _buffer_prepare funtion, we were using vout-buf_phy_addr[vb-i] for buffer physical address to configure SDMA channel, but this variable does get updated only during init. And the issue will occur when driver allocates less number of buffers during init and application requests more buffers through REQBUF ioctl; this variable will lead to invalid configuration of SDMA channel leading to DMA transaction error. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- Archit/Laurent, Can you help me to validate this patch on your platform/usecase? drivers/media/video/omap/omap_vout_vrfb.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/omap/omap_vout_vrfb.c b/drivers/media/video/omap/omap_vout_vrfb.c index 4be26ab..240d36d 100644 --- a/drivers/media/video/omap/omap_vout_vrfb.c +++ b/drivers/media/video/omap/omap_vout_vrfb.c @@ -225,7 +225,7 @@ int omap_vout_prepare_vrfb(struct omap_vout_device *vout, if (!is_rotation_enabled(vout)) return 0; - dmabuf = vout-buf_phy_addr[vb-i]; + dmabuf = (dma_addr_t) vout-queued_buf_addr[vb-i]; /* If rotation is enabled, copy input buffer into VRFB * memory space using DMA. We are copying input buffer * into VRFB memory space of desired angle and DSS will -- 1.7.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] omap_vout: Fix the build warning and section miss-match warning
Patch fixes below build warning and section miss-match warning
from omap_vout driver -
Build warnings:
=
drivers/media/video/omap/omap_vout.c: In function 'omapvid_setup_overlay':
drivers/media/video/omap/omap_vout.c:381:17: warning: 'mode' may be used
uninitialized in this function
Section Mis-Match warnings:
==
WARNING: drivers/media/video/omap/omap-vout.o(.data+0x0): Section mismatch in
reference from the variable
omap_vout_driver to the function .init.text:omap_vout_probe()
The variable omap_vout_driver references
the function __init omap_vout_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/omap/omap_vout.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index dffcf66..0fb0437 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -328,7 +328,7 @@ static int video_mode_to_dss_mode(struct omap_vout_device
*vout)
struct omap_overlay *ovl;
struct omapvideo_info *ovid;
struct v4l2_pix_format *pix = vout-pix;
- enum omap_color_mode mode;
+ enum omap_color_mode mode = -EINVAL;
ovid = vout-vid_info;
ovl = ovid-overlays[0];
@@ -2108,7 +2108,7 @@ static void omap_vout_cleanup_device(struct
omap_vout_device *vout)
kfree(vout);
}
-static int omap_vout_remove(struct platform_device *pdev)
+static int __devexit omap_vout_remove(struct platform_device *pdev)
{
int k;
struct v4l2_device *v4l2_dev = platform_get_drvdata(pdev);
@@ -2129,7 +2129,7 @@ static int omap_vout_remove(struct platform_device *pdev)
return 0;
}
-static int __init omap_vout_probe(struct platform_device *pdev)
+static int __devinit omap_vout_probe(struct platform_device *pdev)
{
int ret = 0, i;
struct omap_overlay *ovl;
@@ -2241,9 +2241,10 @@ probe_err0:
static struct platform_driver omap_vout_driver = {
.driver = {
.name = VOUT_NAME,
+ .owner = THIS_MODULE,
},
.probe = omap_vout_probe,
- .remove = omap_vout_remove,
+ .remove = __devexit_p(omap_vout_remove),
};
static int __init omap_vout_init(void)
--
1.7.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
Re: [PATCH v4 3/3] OMAPDSS: HDMI: Sysfs support to configure quantization
On Fri, 2012-03-09 at 16:17 +0530, K, Mythri P wrote: I also only now realized that we have full/limited range setting in video overlay's ATTRIBUTEs also. And it seems that we currently set it always to 0, i.e. limited range. I wonder if this causes color degradation in case the HDMI/DP output also sets limited range, and thus the color range gets scaled down twice... yes there is a limited/full range bit in dispc for color conversion, did a quick check using analyzer it doesn't impact the HDMI color range, so can confirm there is no degradation. Did you try what happens if you set the range to full in DISPC? Because it should affect HDMI also, so I don't quite understand how there could be no degradation if both DISPC and HDMI do the range limiting. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 2/2] ASoC: OMAP: Build config cleanup for McBSP
On Fri, Mar 09, 2012 at 10:51:18AM +0200, Peter Ujfalusi wrote: The McBSP driver stack has been moved, and rewritten resulting a single driver - selected by CONFIG_SND_OMAP_SOC_MCBSP. There is no longer need to have CONFIG_OMAP_MCBSP anymore. Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com signature.asc Description: Digital signature
Re: [PATCH 4/4] misc: emif: add device tree support to emif driver
Hi Grant,
On Friday 09 March 2012 11:07 AM, Grant Likely wrote:
On Thu, 8 Mar 2012 22:03:57 +0530, Aneesh Vane...@ti.com wrote:
Cc: Rajendra Nayakrna...@ti.com
Cc: Benoit Coussonb-cous...@ti.com
Signed-off-by: Aneesh Vane...@ti.com
---
Changes since RFC v4:
- Rebased to the latest version of EMIF series
- Replace kzalloc()/kfree() with devm_* variants
---
drivers/misc/emif.c | 289 ++-
1 files changed, 288 insertions(+), 1 deletions(-)
diff --git a/drivers/misc/emif.c b/drivers/misc/emif.c
index 79fb161..0aaa61e 100644
--- a/drivers/misc/emif.c
+++ b/drivers/misc/emif.c
@@ -18,6 +18,7 @@
#includelinux/platform_device.h
#includelinux/interrupt.h
#includelinux/slab.h
+#includelinux/of.h
#includelinux/debugfs.h
#includelinux/seq_file.h
#includelinux/module.h
@@ -49,6 +50,7 @@
*frequency in effect at the moment)
* @plat_data:Pointer to saved platform data.
* @debugfs_root: dentry to the root folder for EMIF in debugfs
+ * @np_ddr:Pointer to ddr device tree node
*/
struct emif_data {
u8 duplicate;
@@ -63,6 +65,9 @@ struct emif_data {
struct emif_regs*curr_regs;
struct emif_platform_data *plat_data;
struct dentry *debugfs_root;
+#if defined(CONFIG_OF)
+ struct device_node *np_ddr;
+#endif
Don't bother with the #if/#endif wrapper here.
Ok.
};
static struct emif_data *emif1;
@@ -1147,6 +1152,270 @@ static int is_custom_config_valid(struct
emif_custom_configs *cust_cfgs,
return valid;
}
+#if defined(CONFIG_OF)
+static void __init of_get_custom_configs(struct device_node *np_emif,
__devinit. Same through the rest of the file.
I am not sure if we need __devinit. I see that __devinit will not have
any effect if CONFIG_HOTPLUG is enabled and CONFIG_HOTPLUG is always
enabled in our configuration. EMIF devices are not hot-pluggable
devices and are always added at boot-time from the board file. They are
on-chip IP modules and dynamic discovery and addition doesn't make
sense for them. So, can't we save some memory by making them __init.
AFAIU, __init doesn't have any effect in a module. However, I can make
that more explicit by using '__init_or_module'. Is that ok?
[...]
+ return NULL;
+out:
+ return emif;
+}
+#endif
+
static struct emif_data * __init get_device_details(
This function also must be __devinit
struct platform_device *pdev)
{
@@ -1266,7 +1535,13 @@ static int __init emif_probe(struct platform_device
*pdev)
struct resource *res;
int irq;
- emif = get_device_details(pdev);
+#if defined(CONFIG_OF)
+ if (pdev-dev.of_node)
+ emif = of_get_device_details(pdev-dev.of_node,pdev-dev);
+ else
+#endif
+ emif = get_device_details(pdev);
+
if (!emif) {
pr_err(%s: error getting device data\n, __func__);
goto error;
@@ -1643,11 +1918,23 @@ static void __attribute__((unused))
freq_post_notify_handling(void)
spin_unlock_irqrestore(emif_lock, irq_state);
}
+#if defined(CONFIG_OF)
+static const struct of_device_id emif_of_match[] = {
+ { .compatible = ti,emif-4d },
+ { .compatible = ti,emif-4d5 },
+ {},
+};
+MODULE_DEVICE_TABLE(of, emif_of_match);
+#endif
+
static struct platform_driver emif_driver = {
.remove = __exit_p(emif_remove),
Not part of this patch I realize, but this is a bug. .remove must
be in the __devexit section and the __devexit_p() wrapper must
be used. Similarly, emif_probe must be in the __devinit section.
Again, in our case remove() is not needed unless the driver is built as
a module because the devices will never be un-registered. When it is
built as a module the effect is same for both:
#if defined(MODULE) || defined(CONFIG_HOTPLUG)
#define __devexit_p(x) x
#else
#define __devexit_p(x) NULL
#endif
#ifdef MODULE
#define __exit_p(x) x
#else
#define __exit_p(x) NULL
#endif
.shutdown = emif_shutdown,
.driver = {
.name = emif,
+#if defined(CONFIG_OF)
+ .of_match_table = of_match_ptr(emif_of_match),
+#endif
The of_match_ptr() macro makes the #if/#endif wrapper redundant.
Ok. I will remove it.
Otherwise, on brief review this patch looks right.
Thanks for the review. Are you ok with the bindings too?
br,
Aneesh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] OMAPDSS: HDMI: Add support for OMAP5 HDMI core IP driver
From: Mythri P K mythr...@ti.com Add basic functionality support for HDMI OMAP5 core driver. Across OMAP4 and OMAP5 HDMI core IP block differs where as the PHY, PLL and the wrapper blocks are reused, using the existing framework and extention to support OMAP5 core driver is added. Mythri P K (2): OMAPDSS: HDMI: Make Wrapper function non-static OMAPDSS: HDMI: Add support for OMAP5 HDMI core library in DSS drivers/video/omap2/dss/ti_hdmi.h |2 + drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 10 +- drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |9 + drivers/video/omap2/dss/ti_hdmi_5xxx_ip.c | 341 + drivers/video/omap2/dss/ti_hdmi_5xxx_ip.h | 254 + 5 files changed, 611 insertions(+), 5 deletions(-) create mode 100644 drivers/video/omap2/dss/ti_hdmi_5xxx_ip.c create mode 100644 drivers/video/omap2/dss/ti_hdmi_5xxx_ip.h -- 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 1/2] OMAPDSS: HDMI: Make Wrapper function non-static
From: Mythri P K mythr...@ti.com
HDMI wrapper is same across OMAP4 and OMAP5, so the wrapper
functions can be re-used. Thus making wrapper functions as non-static.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 10 +-
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |9 +
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index bc55528..7ccac68 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -721,7 +721,7 @@ static void hdmi_core_av_packet_config(struct hdmi_ip_data
*ip_data,
(repeat_cfg.generic_pkt_repeat));
}
-static void hdmi_wp_init(struct omap_video_timings *timings,
+void hdmi_wp_init(struct omap_video_timings *timings,
struct hdmi_video_format *video_fmt)
{
pr_debug(Enter hdmi_wp_init\n);
@@ -744,7 +744,7 @@ void ti_hdmi_4xxx_wp_video_start(struct hdmi_ip_data
*ip_data, bool start)
REG_FLD_MOD(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG, start, 31, 31);
}
-static void hdmi_wp_video_init_format(struct hdmi_video_format *video_fmt,
+void hdmi_wp_video_init_format(struct hdmi_video_format *video_fmt,
struct omap_video_timings *timings, struct hdmi_config *param)
{
pr_debug(Enter hdmi_wp_video_init_format\n);
@@ -760,7 +760,7 @@ static void hdmi_wp_video_init_format(struct
hdmi_video_format *video_fmt,
timings-vsw = param-timings.vsw;
}
-static void hdmi_wp_video_config_format(struct hdmi_ip_data *ip_data,
+void hdmi_wp_video_config_format(struct hdmi_ip_data *ip_data,
struct hdmi_video_format *video_fmt)
{
u32 l = 0;
@@ -773,7 +773,7 @@ static void hdmi_wp_video_config_format(struct hdmi_ip_data
*ip_data,
hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_SIZE, l);
}
-static void hdmi_wp_video_config_interface(struct hdmi_ip_data *ip_data)
+void hdmi_wp_video_config_interface(struct hdmi_ip_data *ip_data)
{
u32 r;
pr_debug(Enter hdmi_wp_video_config_interface\n);
@@ -786,7 +786,7 @@ static void hdmi_wp_video_config_interface(struct
hdmi_ip_data *ip_data)
hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG, r);
}
-static void hdmi_wp_video_config_timing(struct hdmi_ip_data *ip_data,
+void hdmi_wp_video_config_timing(struct hdmi_ip_data *ip_data,
struct omap_video_timings *timings)
{
u32 timing_h = 0;
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index efa6f29..c18f415 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -542,4 +542,13 @@ void hdmi_wp_audio_config_dma(struct hdmi_ip_data *ip_data,
void hdmi_wp_audio_config_format(struct hdmi_ip_data *ip_data,
struct hdmi_audio_format *aud_fmt);
#endif
+void hdmi_wp_video_config_timing(struct hdmi_ip_data *ip_data,
+ struct omap_video_timings *timings);
+void hdmi_wp_video_config_interface(struct hdmi_ip_data *ip_data);
+void hdmi_wp_video_config_format(struct hdmi_ip_data *ip_data,
+ struct hdmi_video_format *video_fmt);
+void hdmi_wp_video_init_format(struct hdmi_video_format *video_fmt,
+ struct omap_video_timings *timings, struct hdmi_config *param);
+void hdmi_wp_init(struct omap_video_timings *timings,
+ struct hdmi_video_format *video_fmt);
#endif
--
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/2] OMAPDSS: HDMI: Add support for OMAP5 HDMI core library
From: Mythri P K mythr...@ti.com
Add support for configuration of the basic HDMI OMAP5 core IP
driver.HDMI shares the wrapper, PHY and PLL code with OMAP4.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi.h |2 +
drivers/video/omap2/dss/ti_hdmi_5xxx_ip.c | 341 +
drivers/video/omap2/dss/ti_hdmi_5xxx_ip.h | 254 +
3 files changed, 597 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/dss/ti_hdmi_5xxx_ip.c
create mode 100644 drivers/video/omap2/dss/ti_hdmi_5xxx_ip.h
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index 1f58b84..aafecc2 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -185,4 +185,6 @@ void ti_hdmi_4xxx_phy_dump(struct hdmi_ip_data *ip_data,
struct seq_file *s);
defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
void ti_hdmi_4xxx_wp_audio_enable(struct hdmi_ip_data *ip_data, bool enable);
#endif
+void ti_hdmi_5xxx_basic_configure(struct hdmi_ip_data *ip_data);
+void ti_hdmi_5xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
#endif
diff --git a/drivers/video/omap2/dss/ti_hdmi_5xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_5xxx_ip.c
new file mode 100644
index 000..a8a5ad3
--- /dev/null
+++ b/drivers/video/omap2/dss/ti_hdmi_5xxx_ip.c
@@ -0,0 +1,341 @@
+
+/*
+ * ti_hdmi_5xxx_ip.c
+ *
+ * HDMI TI OMAP5 IP driver Library
+ * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: Mythri pk mythr...@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, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/err.h
+#include linux/io.h
+#include linux/interrupt.h
+#include linux/mutex.h
+#include linux/delay.h
+#include linux/string.h
+#include linux/seq_file.h
+
+#include ti_hdmi_5xxx_ip.h
+#include dss.h
+
+static inline void hdmi_write_reg(void __iomem *base_addr,
+ const unsigned long idx, u32 val)
+{
+ __raw_writel(val, base_addr + idx);
+}
+
+static inline u32 hdmi_read_reg(void __iomem *base_addr,
+ const unsigned long idx)
+{
+ return __raw_readl(base_addr + idx);
+}
+
+static inline void __iomem *hdmi_core_sys_base(struct hdmi_ip_data *ip_data)
+{
+ return ip_data-base_wp + ip_data-core_sys_offset;
+}
+
+static inline int hdmi_wait_for_bit_change(void __iomem *base_addr,
+ const unsigned long idx,
+ int b2, int b1, u32 val)
+{
+ u32 t = 0;
+ while (val != REG_GET(base_addr, idx, b2, b1)) {
+ udelay(1);
+ if (t++ 1)
+ return !val;
+ }
+ return val;
+}
+
+void ti_hdmi_5xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s)
+{
+
+#define DUMPCORE(r) seq_printf(s, %-35s %08x\n, #r,\
+ hdmi_read_reg(hdmi_core_sys_base(ip_data), r))
+
+ DUMPCORE(HDMI_CORE_FC_INVIDCONF);
+ DUMPCORE(HDMI_CORE_FC_INHACTIV0);
+ DUMPCORE(HDMI_CORE_FC_INHACTIV1);
+ DUMPCORE(HDMI_CORE_FC_INHBLANK0);
+ DUMPCORE(HDMI_CORE_FC_INHBLANK1);
+ DUMPCORE(HDMI_CORE_FC_INVACTIV0);
+ DUMPCORE(HDMI_CORE_FC_INVACTIV1);
+ DUMPCORE(HDMI_CORE_FC_INVBLANK);
+ DUMPCORE(HDMI_CORE_FC_HSYNCINDELAY0);
+ DUMPCORE(HDMI_CORE_FC_HSYNCINDELAY1);
+ DUMPCORE(HDMI_CORE_FC_HSYNCINWIDTH0);
+ DUMPCORE(HDMI_CORE_FC_HSYNCINWIDTH1);
+ DUMPCORE(HDMI_CORE_FC_VSYNCINDELAY);
+ DUMPCORE(HDMI_CORE_FC_VSYNCINWIDTH);
+ DUMPCORE(HDMI_CORE_FC_CTRLDUR);
+ DUMPCORE(HDMI_CORE_FC_EXCTRLDUR);
+ DUMPCORE(HDMI_CORE_FC_EXCTRLSPAC);
+ DUMPCORE(HDMI_CORE_FC_CH0PREAM);
+ DUMPCORE(HDMI_CORE_FC_CH1PREAM);
+ DUMPCORE(HDMI_CORE_FC_CH2PREAM);
+ DUMPCORE(HDMI_CORE_FC_AVICONF0);
+ DUMPCORE(HDMI_CORE_FC_AVICONF1);
+ DUMPCORE(HDMI_CORE_FC_AVICONF2);
+ DUMPCORE(HDMI_CORE_FC_AVIVID);
+ DUMPCORE(HDMI_CORE_FC_PRCONF);
+
+ DUMPCORE(HDMI_CORE_MC_CLKDIS);
+ DUMPCORE(HDMI_CORE_MC_SWRSTZREQ);
+ DUMPCORE(HDMI_CORE_MC_FLOWCTRL);
+ DUMPCORE(HDMI_CORE_MC_PHYRSTZ);
+ DUMPCORE(HDMI_CORE_MC_LOCKONCLOCK);
+
+ DUMPCORE(HDMI_CORE_I2CM_SLAVE);
+ DUMPCORE(HDMI_CORE_I2CM_ADDRESS);
+ DUMPCORE(HDMI_CORE_I2CM_DATAO);
+ DUMPCORE(HDMI_CORE_I2CM_DATAI);
+ DUMPCORE(HDMI_CORE_I2CM_OPERATION);
+
RE: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
-Original Message- From: Chris Ball [mailto:c...@laptop.org] Sent: Thursday, March 08, 2012 10:39 PM To: Maupin, Chase Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org Subject: Re: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices Hi Chase, On Thu, Mar 01 2012, Chase Maupin wrote: * With certain SD cards timeouts like the following have been seen due to an improper calculation of the dto value: mmcblk0: error -110 transferring data, sector 4126233, nr 8, card status 0xc00 * By removing the dto calculation and setting the timeout value to the maximum specified by the SD card specification part A2 section 2.2.15 these timeouts can be avoided. * This change has been used by beagleboard users as well as the Texas Instruments SDK without a negative impact. * There are multiple discussion threads about this but the most relevant ones are: * http://talk.maemo.org/showthread.php?p=1000707#post1000707 * http://www.mail-archive.com/linux- o...@vger.kernel.org/msg42213.html * Original proposal for this fix was done by Sukumar Ghoral of Texas Instruments * Tested using a Texas Instruments AM335x EVM Signed-off-by: Chase Maupin chase.mau...@ti.com Thanks, I've pushed this to mmc-next for 3.4. (With a trivial indentation fix, below.) Thank you Chris. diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 82b400793..9d4ce1c 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1360,7 +1360,7 @@ static void set_data_timeout(struct omap_hsmmc_host *host) if (clkd == 0) clkd = 1; -/* Use the maximum timeout value allowed in the standard of 14 or 0xE */ + /* Use the maximum timeout value allowed in the standard of 14 or 0xE */ dto = 14; reg = ~DTO_MASK; - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: implementing suspend to ram on cortex A8 based on linux 3.0.8
On Wed, Mar 7, 2012 at 12:05 PM, yang gqyang hustgqy...@gmail.com wrote: dear all: I am working on arm cortex a8 now, trying to implement suspend to ram based on linux 3.0.8. Which CPU exactly are you using? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: OMAP2+: PM: code consolidation for 3.4
Luciano Coelho coe...@ti.com writes: Hi Kevin, On Thu, 2012-03-08 at 13:21 -0800, Kevin Hilman wrote: Luciano Coelho coe...@ti.com writes: [...] Thanks, Paul! I was just chatting with Kevin about this on IRC. With your patch and no_console_suspend, it works. :) Just FYI... I've queued this patch from Paul and it's now queued by Tony for v3.4 in his cleanup-pm branch. Great, thanks for the info! BTW, you and Paul said that it was not recommended to use no_console_suspend, but Ido (on CC) said that it can be useful for us, because we need to see if our own (wireless) stuff goes into suspend correctly. no_console_suspend should not be needed there. It is really only intended as a *temporary* debug feature when suspend fails. Since the console is disabled during suspend, if suspend fails, you might not see the reason for failure. So in this case, you enable no_console_suspend just to see the suspend output, and why it's failing. If suspend/resume succeed, you will see all the console output after resume because even though the console is disabled, the printks are buffered, so you will see them eventually. So with a working suspend/resume, you will eventually see all the console output. So basically, any usage of no_console_suspend should be temporary, until you figure out why suspend if failing. Are there any real problems with no_console_suspend besides power consumption? Is it safe for us to simply apply Paul's patch when we need it? There are important side effects of leaving the console enabled. Namely, the console UART will stay clocked, and thus prevent it's surrounding powerdomain from reaching a low power state. UARTs can be in either the PER or CORE powerdomains, so preventing them from reaching the low powerstate will affect other drivers in those powerdomains. For example, if your device is in the same powerdomain as the UART, it will not be clock gated (or power gated) so the context save/restore paths of those devices will not be exercised. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP2+: PM: core support for SMPS regulators for v3.4
Mark Brown broo...@opensource.wolfsonmicro.com writes: On Thu, Mar 08, 2012 at 04:32:18PM -0800, Tony Lindgren wrote: * Kevin Hilman khil...@ti.com [120308 09:37]: Tony Lindgren t...@atomide.com writes: Oh, that's because it depends on the regulator core changes that are in Mark's regulator tree. You need the for-next branch of : git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git For this to compile correctly. Sorry, I should've been more clear above about the build dependency. Hmm just checking.. Recently Mark replied to Peter: ... So can you guys please confirm that if is indeed an immutable commit to use as a base to merge in something? Absolutely not, the for-next branch is rebuilt frequently especially since it includes stuff sent to Linus and he complained about bugfixes merged up into development code. What is the actual dependency here? The stuff is in your topic/drivers branch. Specifically: ed5da2a mfd: twl-core: regulator configuration for twl6030 V1V8, V2V1 SMPS 77a3915 regulator: twl-regulator: Add fixed LDO for V1V8, V2V1 supply d64214b regulator: twl: adapt twl-regulator driver to dt 3e1ff1f regulator: twl6030: add support for vdd1, vdd2 and vdd3 regulators 1a4a805 regulator: twl4030: add support for external voltage get/set The topic branches are more or less static, though some more than others. Is topic/drivers something stable? If not, these are a ways back in that branch, maybe you make a topic/drivers-stable for us? In general you should warn people if you've got a dependency on their tree, it makes life easier. Yeah, I should've raised this when the original series were posted. The arch stuff and drivers/regulator stuff were posted all together, but you picked out the regulator stuff and I picked up the rest. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: clock: Add aliases for McBSP fclk clocks
Hi Paul, Tony, On 03/06/2012 10:55 AM, Peter Ujfalusi wrote: CLKS signal for McBSP ports can be selected from internal (PRCM) or external (ABE_CLKS pin) source. To be able to use existing code we need to create clock aliases consistent among OMAP2/3/4. Would you be able to take a look at this patch? Thanks, 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
Re: [PATCH v2 3/4] arm/dts: OMAP4: Add mmc controller nodes and board data
On Fri, 24 Feb 2012 15:56:52 +0530, Rajendra Nayak rna...@ti.com wrote:
On Friday 24 February 2012 03:46 PM, T Krishnamoorthy, Balaji wrote:
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 29f4589..9204f60 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -25,6 +25,11 @@
serial1 =uart2;
serial2 =uart3;
serial3 =uart4;
+ mmc1 =mmc1;
+ mmc2 =mmc2;
+ mmc3 =mmc3;
+ mmc4 =mmc4;
+ mmc5 =mmc5;
};
cpus {
@@ -155,5 +160,31 @@
#size-cells =0;
ti,hwmods = i2c4;
};
+
+ mmc1: mmc@1 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ };
+
+ mmc2: mmc@2 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc2;
+ };
Hi Rajendra,
Is there a way to control the device registration order,
eMMC connected to mmc2 needs to be registered as /dev/mmcblk0p ...
irrespective of whether SD card is mount or not on mmc1 card slot.
So that bootargs would not have to be modified when filesystem is on eMMC.
I don't know if we can, but even if we could, we take care of the same
bootargs working on two boards (say sdp and panda) *if* on sdp I have my
filesystem on eMMC and on panda I have it on external card.
What happens if I want to use my filesystem on both boards on external
card?
of_alias_get_id() may be able to help you here. It will extract the id
numbering from the /aliases node. That is the safe way to do global
enumeration of devices in the device tree (instead of 'cell-index' which
is strongly discouraged)
g.
+
+ mmc3: mmc@3 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc3;
+ };
+
+ mmc4: mmc@4 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc4;
+ };
+
+ mmc5: mmc@5 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc5;
+ };
};
};
--
1.7.1
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies,Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ARM: OMAP: GPIO cleanup and device tree adaptation
Hi Grant, Please pull the patches for OMAP GPIO DT support. It is based on your current gpio/next branch. Thanks, Benoit The following changes since commit e4e449e82871c53ef3b22bd3a50fceabc0638926: Mark Brown (1): gpiolib: Add comments explaining the _cansleep() WARN_ON()s are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_grant/for_3.4/dt_gpio Benoit Cousson (4): gpio/omap: Remove bank-id information and misc cleanup gpio/omap: Use devm_ API and add request_mem_region gpio/omap: Add DT support to GPIO driver gpio/omap: Fix IRQ handling for SPARSE_IRQ .../devicetree/bindings/gpio/gpio-omap.txt | 36 arch/arm/plat-omap/include/plat/gpio.h | 22 +-- drivers/gpio/gpio-omap.c | 208 ++-- 3 files changed, 190 insertions(+), 76 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-omap.txt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP: GPIO cleanup and device tree adaptation
On Fri, Mar 9, 2012 at 9:33 AM, Cousson, Benoit b-cous...@ti.com wrote: Hi Grant, Please pull the patches for OMAP GPIO DT support. It is based on your current gpio/next branch. Thanks, Benoit Merged, thanks. g. The following changes since commit e4e449e82871c53ef3b22bd3a50fceabc0638926: Mark Brown (1): gpiolib: Add comments explaining the _cansleep() WARN_ON()s are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_grant/for_3.4/dt_gpio Benoit Cousson (4): gpio/omap: Remove bank-id information and misc cleanup gpio/omap: Use devm_ API and add request_mem_region gpio/omap: Add DT support to GPIO driver gpio/omap: Fix IRQ handling for SPARSE_IRQ .../devicetree/bindings/gpio/gpio-omap.txt | 36 arch/arm/plat-omap/include/plat/gpio.h | 22 +-- drivers/gpio/gpio-omap.c | 208 ++-- 3 files changed, 190 insertions(+), 76 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-omap.txt -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/12] gpio/twl: Allocate irq_desc dynamically for SPARSE_IRQ support
Hi Grant,
Gentle ping for these patches.
Thanks,
Benoit
On 3/7/2012 1:57 PM, Cousson, Benoit wrote:
Hi Grant,
That fix is tightly coupled with the previous twl4030-irq change, so it
will be good to pulled it with the twl series through MFD if you are OK
with that?
Care to ack this one and the next one?
Thanks,
Benoit
On 3/2/2012 5:50 PM, Benoit Cousson wrote:
Do not use the board pdata for irq_base, but allocate them dynamically
to allow a proper support of SPARSE_IRQ.
Fix an unneeded line wrap.
Signed-off-by: Benoit Coussonb-cous...@ti.com
Acked-by: Felipe Balbiba...@ti.com
---
drivers/gpio/gpio-twl4030.c | 33 +
1 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index 697396c..49e5c6e 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -395,23 +395,26 @@ static int gpio_twl4030_remove(struct
platform_device *pdev);
static int __devinit gpio_twl4030_probe(struct platform_device *pdev)
{
struct twl4030_gpio_platform_data *pdata = pdev-dev.platform_data;
- int ret;
+ int ret, irq_base;
/* maybe setup IRQs */
- if (pdata-irq_base) {
- if (is_module()) {
- dev_err(pdev-dev,
- can't dispatch IRQs from modules\n);
- goto no_irqs;
- }
- ret = twl4030_sih_setup(pdev-dev, TWL4030_MODULE_GPIO,
- pdata-irq_base);
- if (ret 0)
- return ret;
- WARN_ON(ret != pdata-irq_base);
- twl4030_gpio_irq_base = ret;
+ if (is_module()) {
+ dev_err(pdev-dev, can't dispatch IRQs from modules\n);
+ goto no_irqs;
+ }
+
+ irq_base = irq_alloc_descs(-1, 0, TWL4030_GPIO_MAX, 0);
+ if (irq_base 0) {
+ dev_err(pdev-dev, Failed to alloc irq_descs\n);
+ return irq_base;
}
+ ret = twl4030_sih_setup(pdev-dev, TWL4030_MODULE_GPIO, irq_base);
+ if (ret 0)
+ return ret;
+
+ twl4030_gpio_irq_base = irq_base;
+
no_irqs:
/*
* NOTE: boards may waste power if they don't set pullups
@@ -443,9 +446,7 @@ no_irqs:
ret = gpiochip_add(twl_gpiochip);
if (ret 0) {
- dev_err(pdev-dev,
- could not register gpiochip, %d\n,
- ret);
+ dev_err(pdev-dev, could not register gpiochip, %d\n, ret);
twl_gpiochip.ngpio = 0;
gpio_twl4030_remove(pdev);
} else if (pdata-setup) {
--
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
--
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 5/9] ARM: OMAP36xx: hwmod data: fix SmartReflex interface data
Hi On Fri, 9 Mar 2012, Jean Pihet wrote: On Fri, Mar 9, 2012 at 4:51 AM, Paul Walmsley p...@pwsan.com wrote: Dropping this patch from this series due to conflicts with the SmartReflex branch. It will be moved to a subsequent series. I can take this change as part of the series I am preparing for the SR conversion to drivers/. What do you thin? I've already included it as part of another pull request... - Paul
Re: [GIT PULL] ARM: OMAP: GPIO cleanup and device tree adaptation
Hi Grant, Grant Likely grant.lik...@secretlab.ca writes: On Fri, Mar 9, 2012 at 9:33 AM, Cousson, Benoit b-cous...@ti.com wrote: Hi Grant, Please pull the patches for OMAP GPIO DT support. It is based on your current gpio/next branch. Thanks, Benoit Merged, thanks. Since you're queuing OMAP GPIO stuff, ping on this one: http://marc.info/?l=linux-omapm=133098903909156w=2 Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS pwrdm usecount, disabling autodeps for DSS
On Fri, 9 Mar 2012, Tomi Valkeinen wrote: I didn't get very far with the patch =(. Tested on omap3 overo, with -rc6 based dss tree. Thanks for testing and the .config. Probably the best thing to do in the medium term is to fix the hwmod iclk handling; I think that will also fix the DSS autodeps problem. BTW, regarding your other recent E-mails and your patches, I regret that I haven't had the chance to get back to you on them, but I do plan to. Too much going on at the moment... - 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 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Tue, Mar 06, 2012 at 04:25:30, Tony Lindgren wrote:
Hi,
* Vaibhav Hiremath hvaib...@ti.com [120119 06:01]:
OMAP device has 32k-sync timer which is currently used as a
clocksource in the kernel (omap2plus_defconfig).
The current implementation uses compile time selection between
gp-timer and 32k-sync timer, which breaks multi-omap build for
the devices like AM33xx, where 32k-sync timer is not available.
So use hwmod database lookup mechanism, through which at run-time
we can identify availability of 32k-sync timer on the device,
else fall back to gp-timer.
...
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -69,52 +69,55 @@ void read_persistent_clock(struct timespec *ts)
int __init omap_init_clocksource_32k(void)
{
- static char err[] __initdata = KERN_ERR
- %s: can't register clocksource!\n;
-
- if (cpu_is_omap16xx() || cpu_class_is_omap2()) {
- u32 pbase;
- unsigned long size = SZ_4K;
- void __iomem *base;
- struct clk *sync_32k_ick;
-
- if (cpu_is_omap16xx()) {
- pbase = OMAP16XX_TIMER_32K_SYNCHRONIZED;
- size = SZ_1K;
- } else if (cpu_is_omap2420())
- pbase = OMAP2420_32KSYNCT_BASE + 0x10;
- else if (cpu_is_omap2430())
- pbase = OMAP2430_32KSYNCT_BASE + 0x10;
- else if (cpu_is_omap34xx())
- pbase = OMAP3430_32KSYNCT_BASE + 0x10;
- else if (cpu_is_omap44xx())
- pbase = OMAP4430_32KSYNCT_BASE + 0x10;
- else
+ u32 pbase;
+ unsigned long size = SZ_4K;
+ void __iomem *base;
+ struct clk *sync_32k_ick;
+
+ if (cpu_is_omap16xx()) {
+ pbase = OMAP16XX_TIMER_32K_SYNCHRONIZED;
+ size = SZ_1K;
+ } else if (cpu_class_is_omap2()) {
+ struct omap_hwmod *oh;
+ const char *oh_name = counter_32k;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh || oh-slaves_cnt == 0) {
+ pr_err(Could not lookup %s hwmod\n, oh_name);
return -ENODEV;
+ }
+ pbase = oh-slaves[0]-addr-pa_start + 0x10;
+ } else {
+ return -ENODEV;
+ }
How about have separate omap1 and omap2+ init functions that
call a common function and passes the pbase as a parameter?
That way we can get rid of the cpu_is_omap tests here.
Tony,
In the morning, I replied very soon, without much thinking...
Just now I started working on the patch, I was just reviewing the code,
and I felt that, it is unnecessary to split the code between omap1 and
omap2+.
The reason is,
Currently Only OMAP16xx base-address is hardcoded with cpu_is_omap16xx()
macro, For all other omap family of devices the complete information is fetched
from HWDMO api's/data.
Thanks,
Vaibhav
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] ARM: OMAP4: clock: Add aliases for McBSP fclk clocks
* Peter Ujfalusi peter.ujfal...@ti.com [120309 07:47]: Hi Paul, Tony, On 03/06/2012 10:55 AM, Peter Ujfalusi wrote: CLKS signal for McBSP ports can be selected from internal (PRCM) or external (ABE_CLKS pin) source. To be able to use existing code we need to create clock aliases consistent among OMAP2/3/4. Would you be able to take a look at this patch? To me this looks safe to merge via ASoC tree, assuming Paul acks it too, and it does not cause merge conflicts with Paul's changes: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: clock: Add aliases for McBSP fclk clocks
On Fri, 9 Mar 2012, Tony Lindgren wrote: * Peter Ujfalusi peter.ujfal...@ti.com [120309 07:47]: Hi Paul, Tony, On 03/06/2012 10:55 AM, Peter Ujfalusi wrote: CLKS signal for McBSP ports can be selected from internal (PRCM) or external (ABE_CLKS pin) source. To be able to use existing code we need to create clock aliases consistent among OMAP2/3/4. Would you be able to take a look at this patch? To me this looks safe to merge via ASoC tree, assuming Paul acks it too, and it does not cause merge conflicts with Paul's changes: Acked-by: Tony Lindgren t...@atomide.com Please let's not merge this one yet. It should not be necessary to change the clkdev aliases, this change should occur in the hwmod code. - 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] ARM: OMAP4: clock: Add aliases for McBSP fclk clocks
On Fri, 9 Mar 2012, Paul Walmsley wrote: Please let's not merge this one yet. It should not be necessary to change the clkdev aliases, this change should occur in the hwmod code. Sorry, sent this too quickly. Not the hwmod code, but the opt_clks aliases in the hwmod data. - 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: DSS pwrdm usecount, disabling autodeps for DSS
Tomi Valkeinen tomi.valkei...@ti.com writes: On Thu, 2012-03-08 at 16:42 -0800, Kevin Hilman wrote: Hi Tomi, A while ago you were asking about why DSS pwrdm counts were so high on OMAP3, and why DSS was transitioning even though it was completely unused. Paul and I just spent some a little time debugging this, and narrowed it down to autodeps. (sorry it took so long, it finally bothered me enough to actually look into it.) The patch below fixes the problem at least when DSS is not loaded (DSS just stays in retention), but I didn't try this with any active DSS usage, or loading/unloding the DSS drivers. Could you give the patch below a try on OMAP3 along with some active DSS usage as well as unloading the modules after using. Could you also verify that suspend/resume continues to work for DSS? I didn't get very far with the patch =(. Tested on omap3 overo, with -rc6 based dss tree. Bummer, thanks for trying. It seems we still have work to do in fixing the omap2/3 enable sequence. At least we know the root cause of the DSS pwrdm usecount now. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: Fix compile error when FB_OMAP2 is not set
* Tomi Valkeinen tomi.valkei...@ti.com [120309 00:14]:
On Thu, 2012-03-08 at 12:46 -0800, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [120308 12:11]:
Otherwise we will get:
arch/arm/plat-omap/fb.c:101: error: expected ‘)’ before ‘*’ token
Signed-off-by: Tony Lindgren t...@atomide.com
---
Tomi, you need something like this for what you have in for-next.
--- a/arch/arm/plat-omap/fb.c
+++ b/arch/arm/plat-omap/fb.c
@@ -98,6 +98,8 @@ arch_initcall(omap_init_fb);
#else
-void __init omapfb_set_lcd_config(omap_lcd_config *config) { }
+void __init omapfb_set_lcd_config(const struct omap_lcd_config *config)
+{
+}
#endif
Also now seeing the following with what you have in for-next:
drivers/video/omap2/displays/panel-taal.c: In function
‘taal_num_errors_show’:
drivers/video/omap2/displays/panel-taal.c:605: warning: ‘errors’ may be
used uninitialized in this function
Hmm, my compiler doesn't complain (codesourcery 2010.09-50), so I didn't
notice that. Which compiler version reports the warning?
I'm not 100% sure, but I think it's a false warning, the code path that
uses errors should only be ran when errors has been set.
This seems to depend on the .config options somehow. Not getting
it with omap2plus_defconfig, but getting it at least with Russell's
omap4430-sdp seed config from:
http://www.arm.linux.org.uk/developer/build/
Using now emdebian 4.3.5-4 as there seems to be some issues
showing all the section warnings with CodeSourcery and Linaro
toolchains.
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 v2] ARM: OMAP: WiLink platform data for the PandaBoard
Hi Luca,
* Mircea Gherzan mgher...@gmail.com [120306 14:23]:
The uim deamon requires sysfs entries that are filled in using
this platform data.
Signed-off-by: Mircea Gherzan mgher...@gmail.com
---
arch/arm/mach-omap2/board-omap4panda.c | 14 --
include/linux/ti_wilink_st.h |2 ++
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index b1d74d6..339e781 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -27,6 +27,7 @@
#include linux/i2c/twl.h
#include linux/regulator/machine.h
#include linux/regulator/fixed.h
+#include linux/ti_wilink_st.h
#include linux/wl12xx.h
#include mach/hardware.h
@@ -56,12 +57,21 @@
#define HDMI_GPIO_HPD 63 /* Hotplug detect */
/* wl127x BT, FM, GPS connectivity chip */
-static int wl1271_gpios[] = {46, -1, -1};
+static struct ti_st_plat_data wilink_platform_data = {
+ .nshutdown_gpio = 46,
+ .dev_name = /dev/ttyO1,
+ .flow_cntrl = 1,
+ .baud_rate = 300,
+ .chip_enable= NULL,
+ .suspend= NULL,
+ .resume = NULL,
+};
+
static struct platform_device wl1271_device = {
.name = kim,
.id = -1,
.dev= {
- .platform_data = wl1271_gpios,
+ .platform_data = wilink_platform_data,
},
};
diff --git a/include/linux/ti_wilink_st.h b/include/linux/ti_wilink_st.h
index 2ef4385..3ca0269 100644
--- a/include/linux/ti_wilink_st.h
+++ b/include/linux/ti_wilink_st.h
@@ -25,6 +25,8 @@
#ifndef TI_WILINK_ST_H
#define TI_WILINK_ST_H
+#include linux/skbuff.h
+
/**
* enum proto-type - The protocol on WiLink chips which share a
* common physical interface like UART.
--
Just checking.. Can you please take a look at this patch
and confirm that this is how things are supposed to be done?
To me passing some third driver's dev_name in pdata seems
pretty weird.. But then again maybe I just don't know how
this is supposed to work.
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 1/2] ARM: OMAP: Remove CONFIG_OMAP_MCBSP references
* Peter Ujfalusi peter.ujfal...@ti.com [120309 00:54]: The McBSP driver stack has been moved to ASoC. The CONFIG_OMAP_MCBSP will be removed since the CONFIG_SND_OMAP_SOC_MCBSP will trigger to build the McBSP (audio) drivers. Great, glad to see this! Thanks for working on this: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] slimbus message encoding/decoding
On 03/08/2012 05:21 PM, Marc Butler wrote: All, This patch provides generic functions for encoding/decoding SLIMbus messages (Section 8 of the specification). Thanks for providing this patch. My understanding is that this patch provides helper functions for h/w controllers which rely on s/w to provide the exact message to be sent out on the bus. No CRC generator is included for the PI and MI fields. The OMAP4430 chip this is being tested on generates and populates these fields in h/w. However, I have include a general (and untested) callback mechanism. Just like CRC, some other fields may be populated by HW. e.g. Qualcomm chip also populates Arbitration priority, Arbitration Extension fields. So it expects SW to only program a few fields, a.k.a logical/elemental address, MT,MC, DT etc.(that too, SW programs this based on software interface manual). The hardware will convert this information to actual slimbus-compliant message and send it on the bus. Being said that, I am not aware of how majority of h/w controllers work and will be open to have this patch if other hardwares rely on s/w to provide the exact message as well. -Sagar -m -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] slimbus message encoding/decoding
On Fri, Mar 09, 2012 at 12:50:24PM -0700, Sagar Dharia wrote: On 03/08/2012 05:21 PM, Marc Butler wrote: Thanks for providing this patch. My understanding is that this patch provides helper functions for h/w controllers which rely on s/w to provide the exact message to be sent out on the bus. Yes. The ti omap4430 expects the messages, to be complete except for the PI, MR, and MI fields which are encoded by the h/w. Just like CRC, some other fields may be populated by HW. e.g. Qualcomm chip also populates Arbitration priority, Arbitration Extension fields. So it expects SW to only program a few fields, a.k.a logical/elemental address, MT,MC, DT etc.(that too, SW programs this based on software interface manual). The hardware will convert this information to actual slimbus-compliant message and send it on the bus. Understood. The functions are not incompatible with construction partial messages, but as it will not likely work when inserting the header field, as it goes about trying to compute the remaining length, based on the current (icomplete) message including the arbitration header. Being said that, I am not aware of how majority of h/w controllers work and will be open to have this patch if other hardwares rely on s/w to provide the exact message as well. The ti omap4430 requires this support. Regards, -m -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 2/6] ARM: OMAP3 PM: Move IO Daisychain function to omap3 prm file
cc Rajendra
Hi Tero,
a few comments:
On Tue, 6 Mar 2012, Tero Kristo wrote:
...
+/* OMAP3 Daisychain enable sequence */
+void omap3_trigger_io_chain(void)
+{
+ int i = 0;
+
+ omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+PM_WKEN);
+ /* Do a readback to assure write has been done */
+ omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
Looks like this barrier shouldn't be needed? The write is immediately
followed by another read from the same IP block.
+
+ omap_test_timeout(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
+ OMAP3430_ST_IO_CHAIN_MASK,
+ MAX_IOPAD_LATCH_TIME, i);
+
+ omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+ PM_WKEN);
+
+ omap2_prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN_MASK, WKUP_MOD,
+ PM_WKST);
+
+ omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST);
+}
I see that you removed the second timeout test from this code, but not
from the OMAP4 version. Any reason why? Seems like if the second timeout
can be removed from one, then it can also be removed from the other?
- 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: [PATCHv5 1/6] ARM: OMAP3 PM: correct enable/disable of daisy io chain
Hi
On Tue, 6 Mar 2012, Tero Kristo wrote:
From: Mohan V moh...@ti.com
Currently the enabling and disabling of IO Daisy chain is not
according to the TRM. The below steps are followed to enable/
disable the IO chain according to the Sec 3.5.7.2.2
I/O Wake-Up Mechanism in OMAP3630 Public TRM[1].
Steps to enable IO chain:
[a] Set PM_WKEN_WKUP.EN_IO bit
[b] Set the PM_WKEN_WKUP.EN_IO_CHAIN bit
[c] Poll for PM_WKST_WKUP.ST_IO_CHAIN.
[d] When ST_IO_CHAIN bit set to 1, clear PM_WKEN_WKUP.EN_IO_CHAIN
[e] Clear ST_IO_CHAIN bit.
Steps to disable IO chain:
[a] Clear PM_WKEN_WKUP.EN_IO_CHAIN bit
[b] Clear PM_WKEN_WKUP.EN_IO bit
[c] Clear PM_WKST_WKUP.ST_IO bit by writing 1 to it.
Step [e] [c] in each case can be skipped, as these are handled
by the PRCM interrupt handler later.
[1] http://focus.ti.com/pdfs/wtbu/OMAP36xx_ES1.x_PUBLIC_TRM_vV.zip
Signed-off-by: Mohan V moh...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Reviewed-by: Rajendra Nayak rna...@ti.com
I modified the commit message to better reflect the reality of what's in
the TRM. Updated version is below.
- Paul
From: Mohan V moh...@ti.com
Date: Fri, 2 Mar 2012 17:17:50 +0200
Subject: [PATCH 1/6] ARM: OMAP3: PM: correct enable/disable of daisy io chain
Currently the enabling and disabling of IO Daisy chain is not
according to the TRM. The below steps are followed to enable/
disable the IO chain, based loosely on the Sec 3.5.7.2.2
I/O Wake-Up Mechanism section in OMAP3630 Public TRM[1].
Steps to enable IO chain:
[a] Set PM_WKEN_WKUP.EN_IO bit
[b] Set the PM_WKEN_WKUP.EN_IO_CHAIN bit
[c] Poll for PM_WKST_WKUP.ST_IO_CHAIN.
[d] When ST_IO_CHAIN bit set to 1, clear PM_WKEN_WKUP.EN_IO_CHAIN
[e] Clear ST_IO_CHAIN bit.
Steps to disable IO chain:
[a] Clear PM_WKEN_WKUP.EN_IO_CHAIN bit
[b] Clear PM_WKEN_WKUP.EN_IO bit
[c] Clear PM_WKST_WKUP.ST_IO bit by writing 1 to it.
Step [e] [c] in each case can be skipped, as these are handled
by the PRCM interrupt handler later.
[1] http://focus.ti.com/pdfs/wtbu/OMAP36xx_ES1.x_PUBLIC_TRM_vV.zip
Signed-off-by: Mohan V moh...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
[p...@pwsan.com: modified commit message to clarify that these steps are
based loosely on the TRM section, rather than documented exactly]
Reviewed-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/pm34xx.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index fc69875..b0821a8 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -94,16 +94,17 @@ static void omap3_enable_io_chain(void)
/* Do a readback to assure write has been done */
omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
- while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN)
+ while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
OMAP3430_ST_IO_CHAIN_MASK)) {
timeout++;
if (timeout 1000) {
pr_err(Wake up daisy chain activation failed.\n);
return;
}
- omap2_prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN_MASK,
- WKUP_MOD, PM_WKEN);
}
+ omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+ PM_WKEN);
+
}
static void omap3_disable_io_chain(void)
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 2/6] ARM: OMAP3 PM: Move IO Daisychain function to omap3 prm file
Hi
On Tue, 6 Mar 2012, Tero Kristo wrote:
From: Vishwanath BS vishwanath...@ti.com
Since IO Daisychain modifies only PRM registers, it makes sense to move
it to PRM File. Also changed the timeout value for IO chain enable to
100us and added a wait for status disable at the end.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
This patch has been updated in a few different ways, described below.
Please let me know if you're okay with it.
- Paul
From: Vishwanath BS vishwanath...@ti.com
Date: Fri, 2 Mar 2012 17:17:51 +0200
Subject: [PATCH 2/6] ARM: OMAP3: PM: Move IO Daisychain function to omap3 prm
file
Since IO Daisychain modifies only PRM registers, it makes sense to move
it to PRM File. Also changed the timeout value for IO chain enable to
100us and added a wait for status disable at the end.
Thanks to Nishanth Menon n...@ti.com for contributing a fix to the
timeout code waiting for WUCLKOUT to go high.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Nishanth Menon n...@ti.com
[p...@pwsan.com: renamed omap3_trigger_io_chain() to better describe the
end result and to match other PRM functions; removed
omap3_disable_io_chain(); moved MAX_IOPAD_LATCH_TIME to prcm-common as it
will also be used by the OMAP4 code; removed unnecessary barrier;
added kerneldoc; added credit for fix from Nishanth]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/pm34xx.c | 35 ++-
arch/arm/mach-omap2/prcm-common.h |8
arch/arm/mach-omap2/prm2xxx_3xxx.c | 31 +++
arch/arm/mach-omap2/prm2xxx_3xxx.h |2 ++
4 files changed, 43 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index b0821a8..378a0de 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -85,34 +85,6 @@ static inline void omap3_per_restore_context(void)
omap_gpio_restore_context();
}
-static void omap3_enable_io_chain(void)
-{
- int timeout = 0;
-
- omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
- PM_WKEN);
- /* Do a readback to assure write has been done */
- omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
-
- while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
-OMAP3430_ST_IO_CHAIN_MASK)) {
- timeout++;
- if (timeout 1000) {
- pr_err(Wake up daisy chain activation failed.\n);
- return;
- }
- }
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
- PM_WKEN);
-
-}
-
-static void omap3_disable_io_chain(void)
-{
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
-PM_WKEN);
-}
-
static void omap3_core_save_context(void)
{
omap3_ctrl_save_padconf();
@@ -324,7 +296,7 @@ void omap_sram_idle(void)
core_next_state PWRDM_POWER_ON)) {
omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
PM_WKEN);
if (omap3_has_io_chain_ctrl())
- omap3_enable_io_chain();
+ omap3_reconfigure_io_chain();
}
pwrdm_pre_transition();
@@ -407,12 +379,9 @@ void omap_sram_idle(void)
/* Disable IO-PAD and IO-CHAIN wakeup */
if (omap3_has_io_wakeup()
(per_next_state PWRDM_POWER_ON ||
-core_next_state PWRDM_POWER_ON)) {
+core_next_state PWRDM_POWER_ON))
omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
PM_WKEN);
- if (omap3_has_io_chain_ctrl())
- omap3_disable_io_chain();
- }
clkdm_allow_idle(mpu_pwrdm-pwrdm_clkdms[0]);
}
diff --git a/arch/arm/mach-omap2/prcm-common.h
b/arch/arm/mach-omap2/prcm-common.h
index 5aa5435..f057c15 100644
--- a/arch/arm/mach-omap2/prcm-common.h
+++ b/arch/arm/mach-omap2/prcm-common.h
@@ -406,6 +406,14 @@
*/
#define MAX_MODULE_HARDRESET_WAIT 1
+/*
+ * Maximum time(us) it takes to output the signal WUCLKOUT of the last
+ * pad of the I/O ring after asserting WUCLKIN high. Tero measured
+ * the actual time at 7 to 8 microseconds on OMAP3 and 2 to 4
+ * microseconds on OMAP4, so this timeout may be too high.
+ */
+#define MAX_IOPAD_LATCH_TIME 100
+
# ifndef __ASSEMBLER__
extern void __iomem *prm_base;
extern void __iomem *cm_base;
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 9ce7654..7d62bd6 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -301,6 +301,37 @@ void omap3xxx_prm_restore_irqen(u32 *saved_mask)
Re: [PATCHv5 3/6] ARM: OMAP4 PM: Add IO Daisychain support
Hi
On Tue, 6 Mar 2012, Tero Kristo wrote:
From: Rajendra Nayak rna...@ti.com
IO daisychain is a mechanism that allows individual IO pads to generate
wakeup events on their own based on a switch of an input signal level.
This allows the hardware module behind the pad to be powered down, but
still have device level capability to detect IO events, and once this
happens the module can be powered back up to resume IO. See section
3.9.4 in OMAP4430 Public TRM for details.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
Here's an updated version of this patch. Please let me know if you think
we should remove the poll on the WUCLKOUT line to conform with the change
that Tero made to the OMAP3 version.
- Paul
From: Rajendra Nayak rna...@ti.com
Date: Fri, 2 Mar 2012 17:17:52 +0200
Subject: [PATCH 3/6] ARM: OMAP4: PRM: Add IO Daisychain support
IO daisychain is a mechanism that allows individual IO pads to generate
wakeup events on their own based on a switch of an input signal level.
This allows the hardware module behind the pad to be powered down, but
still have device level capability to detect IO events, and once this
happens the module can be powered back up to resume IO. See section
3.9.4 in OMAP4430 Public TRM for details.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
[p...@pwsan.com: removed MAX_IOPAD_LATCH_TIME declaration; renamed
omap4_trigger_io_chain() to conform to other PRM function names;
added kerneldoc]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/prm44xx.c | 48 +
arch/arm/mach-omap2/prm44xx.h |2 +
2 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index a1d6154..5868a12 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -231,6 +231,54 @@ void omap44xx_prm_restore_irqen(u32 *saved_mask)
OMAP4_PRM_IRQENABLE_MPU_2_OFFSET);
}
+/**
+ * omap44xx_prm_reconfigure_io_chain - clear latches and reconfigure I/O chain
+ *
+ * Clear any previously-latched I/O wakeup events and ensure that the
+ * I/O wakeup gates are aligned with the current mux settings. Works
+ * by asserting WUCLKIN, waiting for WUCLKOUT to be asserted, and then
+ * deasserting WUCLKIN and waiting for WUCLKOUT to be deasserted.
+ * No return value. XXX Are the final two steps necessary?
+ */
+void omap44xx_prm_reconfigure_io_chain(void)
+{
+ int i = 0;
+
+ /* Enable GLOBAL_WUEN */
+ if (!(omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET) OMAP4430_GLOBAL_WUEN_MASK))
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_GLOBAL_WUEN_MASK,
+ OMAP4430_GLOBAL_WUEN_MASK, OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET);
+
+ /* Trigger WUCLKIN enable */
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK,
+ OMAP4430_WUCLK_CTRL_MASK, OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET);
+ omap_test_timeout(
+ (((omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET)
+ OMAP4430_WUCLK_STATUS_MASK)
+ OMAP4430_WUCLK_STATUS_SHIFT) == 1),
+ MAX_IOPAD_LATCH_TIME, i);
+ if (i == MAX_IOPAD_LATCH_TIME)
+ pr_warn(PRM: I/O chain clock line assertion timed out\n);
+
+ /* Trigger WUCLKIN disable */
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, 0x0,
+ OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET);
+ omap_test_timeout(
+ (((omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET)
+ OMAP4430_WUCLK_STATUS_MASK)
+ OMAP4430_WUCLK_STATUS_SHIFT) == 0),
+ MAX_IOPAD_LATCH_TIME, i);
+ if (i == MAX_IOPAD_LATCH_TIME)
+ pr_warn(PRM: I/O chain clock line deassertion timed out\n);
+
+ return;
+}
+
static int __init omap4xxx_prcm_init(void)
{
if (cpu_is_omap44xx())
diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h
index 7978092..ee72ae6 100644
--- a/arch/arm/mach-omap2/prm44xx.h
+++ b/arch/arm/mach-omap2/prm44xx.h
@@ -763,6 +763,8 @@ extern u32 omap4_prm_vcvp_read(u8 offset);
extern void omap4_prm_vcvp_write(u32 val, u8 offset);
extern u32 omap4_prm_vcvp_rmw(u32 mask, u32 bits, u8 offset);
+extern void omap44xx_prm_reconfigure_io_chain(void);
+
/* PRM interrupt-related functions */
extern void omap44xx_prm_read_pending_irqs(unsigned long *events);
extern void omap44xx_prm_ocp_barrier(void);
--
1.7.9.1
--
To
Re: [PATCHv5 4/6] ARM: OMAP3+: PRM: Enable IO wake up
On Tue, 6 Mar 2012, Tero Kristo wrote:
Enable IO Wake up for OMAP3/4 as part of PRM Init. Currently this has been
managed in cpuidle path which is not the right place. Subsequent patch
will remove IO Daisy chain handling in cpuidle path once daisy chain is
handled as part of hwmod mux. This patch also moves the OMAP4 IO wakeup
enable code from the trigger function to init time setup.
Signed-off-by: Tero Kristo t-kri...@ti.com
Reviewed-by: Rajendra Nayak rna...@ti.com
Here's an updated version of this patch. Please let me know if you have
any comments.
- Paul
From: Tero Kristo t-kri...@ti.com
Date: Fri, 2 Mar 2012 17:17:53 +0200
Subject: [PATCH 4/6] ARM: OMAP3+: PRM: Enable IO wake up
Enable IO Wake up for OMAP3/4 as part of PRM Init. Currently this has been
managed in cpuidle path which is not the right place. Subsequent patch
will remove IO Daisy chain handling in cpuidle path once daisy chain is
handled as part of hwmod mux. This patch also moves the OMAP4 IO wakeup
enable code from the trigger function to init time setup.
Signed-off-by: Tero Kristo t-kri...@ti.com
[p...@pwsan.com: harmonize function names with other PRM functions; add
kerneldoc]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/prm2xxx_3xxx.c | 20 +++-
arch/arm/mach-omap2/prm44xx.c | 26 ++
2 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 7d62bd6..1471a33 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -332,10 +332,28 @@ void omap3xxx_prm_reconfigure_io_chain(void)
omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST);
}
+/**
+ * omap3xxx_prm_enable_io_wakeup - enable wakeup events from I/O wakeup latches
+ *
+ * Activates the I/O wakeup event latches and allows events logged by
+ * those latches to signal a wakeup event to the PRCM. For I/O
+ * wakeups to occur, WAKEUPENABLE bits must be set in the pad mux
+ * registers, and omap3xxx_prm_reconfigure_io_chain() must be called.
+ * No return value.
+ */
+static void __init omap3xxx_prm_enable_io_wakeup(void)
+{
+ if (omap3_has_io_wakeup())
+ omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
+ PM_WKEN);
+}
+
static int __init omap3xxx_prcm_init(void)
{
- if (cpu_is_omap34xx())
+ if (cpu_is_omap34xx()) {
+ omap3xxx_prm_enable_io_wakeup();
return omap_prcm_register_chain_handler(omap3_prcm_irq_setup);
+ }
return 0;
}
subsys_initcall(omap3xxx_prcm_init);
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 5868a12..af251c7 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -244,13 +244,6 @@ void omap44xx_prm_reconfigure_io_chain(void)
{
int i = 0;
- /* Enable GLOBAL_WUEN */
- if (!(omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
- OMAP4_PRM_IO_PMCTRL_OFFSET) OMAP4430_GLOBAL_WUEN_MASK))
- omap4_prm_rmw_inst_reg_bits(OMAP4430_GLOBAL_WUEN_MASK,
- OMAP4430_GLOBAL_WUEN_MASK, OMAP4430_PRM_DEVICE_INST,
- OMAP4_PRM_IO_PMCTRL_OFFSET);
-
/* Trigger WUCLKIN enable */
omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK,
OMAP4430_WUCLK_CTRL_MASK, OMAP4430_PRM_DEVICE_INST,
@@ -279,10 +272,27 @@ void omap44xx_prm_reconfigure_io_chain(void)
return;
}
+/**
+ * omap44xx_prm_enable_io_wakeup - enable wakeup events from I/O wakeup latches
+ *
+ * Activates the I/O wakeup event latches and allows events logged by
+ * those latches to signal a wakeup event to the PRCM. For I/O wakeups
+ * to occur, WAKEUPENABLE bits must be set in the pad mux registers, and
+ * omap44xx_prm_reconfigure_io_chain() must be called. No return value.
+ */
+static void __init omap44xx_prm_enable_io_wakeup(void)
+{
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_GLOBAL_WUEN_MASK,
+ OMAP4430_GLOBAL_WUEN_MASK, OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET);
+}
+
static int __init omap4xxx_prcm_init(void)
{
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx()) {
+ omap44xx_prm_enable_io_wakeup();
return omap_prcm_register_chain_handler(omap4_prcm_irq_setup);
+ }
return 0;
}
subsys_initcall(omap4xxx_prcm_init);
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 5/6] ARM: OMAP3PLUS PM: Add IO Daisychain support via hwmod mux
Hi
On Tue, 6 Mar 2012, Tero Kristo wrote:
From: Vishwanath BS vishwanath...@ti.com
IO Daisychain feature has to be triggered whenever there is a change in
device's mux configuration (See section 3.9.4 in OMAP4 Public TRM vP).
Now devices can idle independent of the powerdomain, there can be a
window where device is idled and corresponding powerdomain can be
ON/INACTIVE state. In such situations, since both module wake up is
enabled at padlevel as well as io daisychain sequence is triggered,
there will be 2 PRCM interrupts (Module async wake up via swakeup and
IO Pad interrupt). But as PRCM Interrupt handler clears the Module
Padlevel WKST bit in the first interrupt, module specific interrupt
handler will not triggered for the second time
Also look at detailed explanation given by Rajendra at
http://www.spinics.net/lists/linux-serial/msg04480.html
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
Here's an updated version of this patch that removes the dependency on
mach-omap2/pm.*.
- Paul
From: Vishwanath BS vishwanath...@ti.com
Date: Fri, 2 Mar 2012 17:17:54 +0200
Subject: [PATCH 5/6] ARM: OMAP3PLUS: hwmod: reconfigure IO Daisychain during
hwmod mux
IO Daisychain feature has to be triggered whenever there is a change in
device's mux configuration (See section 3.9.4 in OMAP4 Public TRM vP).
Now devices can idle independent of the powerdomain, there can be a
window where device is idled and corresponding powerdomain can be
ON/INACTIVE state. In such situations, since both module wake up is
enabled at padlevel as well as io daisychain sequence is triggered,
there will be 2 PRCM interrupts (Module async wake up via swakeup and
IO Pad interrupt). But as PRCM Interrupt handler clears the Module
Padlevel WKST bit in the first interrupt, module specific interrupt
handler will not triggered for the second time
Also look at detailed explanation given by Rajendra at
http://www.spinics.net/lists/linux-serial/msg04480.html
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
[p...@pwsan.com: remove dependency on pm.c pm.h; add kerneldoc]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod.c | 37 +++--
1 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index eba6cd3..58a5920 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -152,6 +152,7 @@
#include prm44xx.h
#include prminst44xx.h
#include mux.h
+#include pm.h
/* Maximum microseconds to wait for OMAP module to softreset */
#define MAX_MODULE_SOFTRESET_WAIT 1
@@ -165,6 +166,8 @@ static LIST_HEAD(omap_hwmod_list);
/* mpu_oh: used to add/remove MPU initiator from sleepdep list */
static struct omap_hwmod *mpu_oh;
+/* io_chain_lock: used to serialize reconfigurations of the I/O chain */
+static DEFINE_SPINLOCK(io_chain_lock);
/* Private functions */
@@ -1481,6 +1484,32 @@ static int _reset(struct omap_hwmod *oh)
}
/**
+ * _reconfigure_io_chain - clear any I/O chain wakeups and reconfigure chain
+ *
+ * Call the appropriate PRM function to clear any logged I/O chain
+ * wakeups and to reconfigure the chain. This apparently needs to be
+ * done upon every mux change. Since hwmods can be concurrently
+ * enabled and idled, hold a spinlock around the I/O chain
+ * reconfiguration sequence. No return value.
+ *
+ * XXX When the PRM code is moved to drivers, this function can be removed,
+ * as the PRM infrastructure should abstract this.
+ */
+static void _reconfigure_io_chain(void)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(io_chain_lock, flags);
+
+ if (cpu_is_omap34xx() omap3_has_io_chain_ctrl())
+ omap3xxx_prm_reconfigure_io_chain();
+ else if (cpu_is_omap44xx())
+ omap44xx_prm_reconfigure_io_chain();
+
+ spin_unlock_irqrestore(io_chain_lock, flags);
+}
+
+/**
* _enable - enable an omap_hwmod
* @oh: struct omap_hwmod *
*
@@ -1535,8 +1564,10 @@ static int _enable(struct omap_hwmod *oh)
/* Mux pins for device runtime if populated */
if (oh-mux (!oh-mux-enabled ||
((oh-_state == _HWMOD_STATE_IDLE)
-oh-mux-pads_dynamic)))
+oh-mux-pads_dynamic))) {
omap_hwmod_mux(oh-mux, _HWMOD_STATE_ENABLED);
+ _reconfigure_io_chain();
+ }
_add_initiator_dep(oh, mpu_oh);
@@ -1622,8 +1653,10 @@ static int _idle(struct omap_hwmod *oh)
clkdm_hwmod_disable(oh-clkdm, oh);
/* Mux pins for device idle if populated */
- if (oh-mux oh-mux-pads_dynamic)
+ if (oh-mux oh-mux-pads_dynamic) {
omap_hwmod_mux(oh-mux, _HWMOD_STATE_IDLE);
+ _reconfigure_io_chain();
+ }
oh-_state =
Re: [PATCHv5 6/6] ARM: OMAP3 PM: Remove IO Daisychain control from cpuidle
On Tue, 6 Mar 2012, Tero Kristo wrote:
From: Vishwanath BS vishwanath...@ti.com
As IO Daisy chain sequence is triggered via hwmod mux, there is no need to
control it from cpuidle path for OMAP3.
Also as omap3_disable_io_chain is no longer being used, just remove the
function.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
Reviewed-by: Rajendra Nayak rna...@ti.com
And here's a modified version of this one that takes into account the
earlier changes.
- Paul
From ad04159c4ec89eef4026fa2e2aeefc3795d98b89 Mon Sep 17 00:00:00 2001
From: Vishwanath BS vishwanath...@ti.com
Date: Fri, 2 Mar 2012 17:17:55 +0200
Subject: [PATCH 6/6] ARM: OMAP3: PM: Remove IO Daisychain control from
cpuidle
As IO Daisy chain sequence is triggered via hwmod mux, there is no need to
control it from cpuidle path for OMAP3.
Also as omap3_disable_io_chain is no longer being used, just remove the
function.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
Reviewed-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/pm34xx.c | 14 --
1 files changed, 0 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 378a0de..ed12bb4 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -291,13 +291,6 @@ void omap_sram_idle(void)
/* Enable IO-PAD and IO-CHAIN wakeups */
per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
- if (omap3_has_io_wakeup()
- (per_next_state PWRDM_POWER_ON ||
-core_next_state PWRDM_POWER_ON)) {
- omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
PM_WKEN);
- if (omap3_has_io_chain_ctrl())
- omap3_reconfigure_io_chain();
- }
pwrdm_pre_transition();
@@ -376,13 +369,6 @@ void omap_sram_idle(void)
omap3_per_restore_context();
}
- /* Disable IO-PAD and IO-CHAIN wakeup */
- if (omap3_has_io_wakeup()
- (per_next_state PWRDM_POWER_ON ||
-core_next_state PWRDM_POWER_ON))
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
-PM_WKEN);
-
clkdm_allow_idle(mpu_pwrdm-pwrdm_clkdms[0]);
}
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 0/6] ARM: OMAP3+: IO daisy chain support fixes
Hi On Tue, 6 Mar 2012, Tero Kristo wrote: Changes compared to previous version: - patch2: * fixed the timeout for waiting for ST_IO_CHAIN == 1 * added clear for ST_IO_CHAIN bit (as per spec + implementation in patch 1) * replaced the timeout at the end of function with a simple register readback (timing out on a register value that we are clearing does not make that much sense, the bit is cleared the very first time CPU manages to read it) - patch5: * added spinlock for protecting io_chain_trigger operation Tested on omap3 beagle + omap4 blaze. Also did measurements for the cost of IO chain trigger operation with ARM performance counters: - omap3 approx 7...8us - omap4 approx 2...4us Thanks for the changes. So as you probably already saw, a few changes have been made. The updated series is in the branch 'io_chain_devel_3.4' on git://git.pwsan.com/linux-2.6. The main outstanding question is whether the OMAP4 WUCLKOUT poll should be removed to match the v5 changes to the OMAP3 function. Please let me know. Any other testing or comments are of course welcome. - 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 v2] ARM: OMAP: WiLink platform data for the PandaBoard
On Fri, 2012-03-09 at 10:31 -0800, Tony Lindgren wrote:
Hi Luca,
Hi Tony,
* Mircea Gherzan mgher...@gmail.com [120306 14:23]:
The uim deamon requires sysfs entries that are filled in using
this platform data.
Signed-off-by: Mircea Gherzan mgher...@gmail.com
---
arch/arm/mach-omap2/board-omap4panda.c | 14 --
include/linux/ti_wilink_st.h |2 ++
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index b1d74d6..339e781 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -27,6 +27,7 @@
#include linux/i2c/twl.h
#include linux/regulator/machine.h
#include linux/regulator/fixed.h
+#include linux/ti_wilink_st.h
#include linux/wl12xx.h
#include mach/hardware.h
@@ -56,12 +57,21 @@
#define HDMI_GPIO_HPD 63 /* Hotplug detect */
/* wl127x BT, FM, GPS connectivity chip */
-static int wl1271_gpios[] = {46, -1, -1};
+static struct ti_st_plat_data wilink_platform_data = {
+ .nshutdown_gpio = 46,
+ .dev_name = /dev/ttyO1,
+ .flow_cntrl = 1,
+ .baud_rate = 300,
+ .chip_enable= NULL,
+ .suspend= NULL,
+ .resume = NULL,
+};
+
static struct platform_device wl1271_device = {
.name = kim,
.id = -1,
.dev= {
- .platform_data = wl1271_gpios,
+ .platform_data = wilink_platform_data,
},
};
diff --git a/include/linux/ti_wilink_st.h b/include/linux/ti_wilink_st.h
index 2ef4385..3ca0269 100644
--- a/include/linux/ti_wilink_st.h
+++ b/include/linux/ti_wilink_st.h
@@ -25,6 +25,8 @@
#ifndef TI_WILINK_ST_H
#define TI_WILINK_ST_H
+#include linux/skbuff.h
+
/**
* enum proto-type - The protocol on WiLink chips which share a
* common physical interface like UART.
--
Just checking.. Can you please take a look at this patch
and confirm that this is how things are supposed to be done?
To me passing some third driver's dev_name in pdata seems
pretty weird.. But then again maybe I just don't know how
this is supposed to work.
This looks pretty weird to me too. The /dev/ttyO1 thing doesn't look
right. But I don't really know how this works either, because this is
the BT/FM/GPS part of the wl12xx chip. And, to be honest, I don't know
anything about it. I only know about the wifi part of it. :\
--
Cheers,
Luca.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: clock: Add aliases for McBSP fclk clocks
Hello Péter
could you please try this patch instead of the clkdev change?
It is based on my 'hwmod_enable_remaining_hwmods_devel_3.4' branch, but
the basic idea should work on v3.3-rc6 as well.
If it works for you, please let us know and we can queue this up along
with the hwmod data changes. Probably we should replace the changelog
also with the one from your patch, it might be a little more useful?
Suggestions welcome.
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Fri, 9 Mar 2012 23:28:28 -0700
Subject: [PATCH] ARM: OMAP4: hwmod data: add McBSP parent clock aliases
Add optional parent clocks for the OMAP4 McBSP modules so the driver
can switch between parent clocks.
Based on a patch from Péter Ujfalusi peter.ujfal...@ti.com.
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index e029992..b4a061d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1921,6 +1921,11 @@ static struct omap_hwmod_dma_info
omap44xx_mcbsp1_sdma_reqs[] = {
{ .dma_req = -1 }
};
+static struct omap_hwmod_opt_clk mcbsp1_opt_clks[] = {
+ { .role = pad_fck, .clk = pad_clks_ck },
+ { .role = prcm_clk, .clk = mcbsp1_sync_mux_ck },
+};
+
static struct omap_hwmod omap44xx_mcbsp1_hwmod = {
.name = mcbsp1,
.class = omap44xx_mcbsp_hwmod_class,
@@ -1935,6 +1940,8 @@ static struct omap_hwmod omap44xx_mcbsp1_hwmod = {
.modulemode = MODULEMODE_SWCTRL,
},
},
+ .opt_clks = mcbsp1_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(mcbsp1_opt_clks),
};
/* mcbsp2 */
@@ -1949,6 +1956,11 @@ static struct omap_hwmod_dma_info
omap44xx_mcbsp2_sdma_reqs[] = {
{ .dma_req = -1 }
};
+static struct omap_hwmod_opt_clk mcbsp2_opt_clks[] = {
+ { .role = pad_fck, .clk = pad_clks_ck },
+ { .role = prcm_clk, .clk = mcbsp2_sync_mux_ck },
+};
+
static struct omap_hwmod omap44xx_mcbsp2_hwmod = {
.name = mcbsp2,
.class = omap44xx_mcbsp_hwmod_class,
@@ -1963,6 +1975,8 @@ static struct omap_hwmod omap44xx_mcbsp2_hwmod = {
.modulemode = MODULEMODE_SWCTRL,
},
},
+ .opt_clks = mcbsp2_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(mcbsp2_opt_clks),
};
/* mcbsp3 */
@@ -1977,6 +1991,11 @@ static struct omap_hwmod_dma_info
omap44xx_mcbsp3_sdma_reqs[] = {
{ .dma_req = -1 }
};
+static struct omap_hwmod_opt_clk mcbsp3_opt_clks[] = {
+ { .role = pad_fck, .clk = pad_clks_ck },
+ { .role = prcm_clk, .clk = mcbsp3_sync_mux_ck },
+};
+
static struct omap_hwmod omap44xx_mcbsp3_hwmod = {
.name = mcbsp3,
.class = omap44xx_mcbsp_hwmod_class,
@@ -1991,6 +2010,8 @@ static struct omap_hwmod omap44xx_mcbsp3_hwmod = {
.modulemode = MODULEMODE_SWCTRL,
},
},
+ .opt_clks = mcbsp3_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(mcbsp3_opt_clks),
};
/* mcbsp4 */
@@ -2005,6 +2026,11 @@ static struct omap_hwmod_dma_info
omap44xx_mcbsp4_sdma_reqs[] = {
{ .dma_req = -1 }
};
+static struct omap_hwmod_opt_clk mcbsp4_opt_clks[] = {
+ { .role = pad_fck, .clk = pad_clks_ck },
+ { .role = prcm_clk, .clk = mcbsp4_sync_mux_ck },
+};
+
static struct omap_hwmod omap44xx_mcbsp4_hwmod = {
.name = mcbsp4,
.class = omap44xx_mcbsp_hwmod_class,
@@ -2019,6 +2045,8 @@ static struct omap_hwmod omap44xx_mcbsp4_hwmod = {
.modulemode = MODULEMODE_SWCTRL,
},
},
+ .opt_clks = mcbsp4_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(mcbsp4_opt_clks),
};
/*
--
1.7.9.1
Re: [PATCH 7/7] OMAPDSS: HDMI: hot plug detect fix
On Thu, 2012-03-08 at 07:29 -0800, Greg KH wrote: On Thu, Mar 08, 2012 at 09:35:13AM +0200, Tomi Valkeinen wrote: On Wed, 2012-03-07 at 12:01 -0800, Greg KH wrote: On Thu, Mar 01, 2012 at 02:26:35PM +0200, Tomi Valkeinen wrote: From: Rob Clark r...@ti.com The OMAPDSS: HDMI: PHY burnout fix commit switched the HDMI driver over to using a GPIO for plug detect. Unfortunately the -detect() method was not also updated, causing HDMI to no longer work for the omapdrm driver (because it would actually check if a connection was detected before attempting to enable display). Signed-off-by: Rob Clark r...@ti.com Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com You forgot to tell me what the git commit id is for this patch (it's ca888a7958b3d808e4efd08ceff88913f4212c69, right?) Yes, that's the one. It wasn't in Linus's tree yet, only in fbdev tree, so I wasn't sure what the commit id is. Then you should not have sent it to me, as if I were to take it then, I could not have :( Oh, ok. I thought the patch-must-be-in-mainline-rule was not a totally strict one, so I decided to include it in this case as the patch was a rather trivial one and already in the fbdev tree (I mentioned it in the intro mail). I guess I got lucky and the patch got into mainline before you took the patches. And why isn't this needed for the 3.0 kernel as well? The detect() function is not present in 3.0, so there was nothing to break. Ok, so everything I've queued up is all that is needed, right? Yes, looks correct. Thanks! Tomi -- 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
