[PATCH] ARM: OMAP2+: CLEANUP: Remove ARCH_OMAPx ifdef from struct dpll_data
From: Kevin Hilman khil...@ti.com
There are certain fields inside 'struct dpll_data' which are
included under ARCH_OMAP3 and ARCH_OMAP4 option, which makes it
difficult to use it for new devices like, am33xx, ti81xx, etc...
So remove the ifdef completely, this will add few fields to the struct
unused, but it improves readability and maintainability of the code.
Signed-off-by: Kevin Hilman khil...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: R Sricharan r.sricha...@ti.com
---
Since Kevin had provided this idea and code change,
making this patch under his authorship.
arch/arm/plat-omap/include/plat/clock.h |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index d0ef57c..656b986 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -156,7 +156,6 @@ struct dpll_data {
u8 min_divider;
u16 max_divider;
u8 modes;
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
void __iomem*autoidle_reg;
void __iomem*idlest_reg;
u32 autoidle_mask;
@@ -167,7 +166,6 @@ struct dpll_data {
u8 auto_recal_bit;
u8 recal_en_bit;
u8 recal_st_bit;
-# endif
u8 flags;
};
--
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-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
On Fri, May 11, 2012 at 03:09:39, Hilman, Kevin wrote: Hiremath, Vaibhav hvaib...@ti.com writes: On Wed, May 09, 2012 at 04:08:09, Hilman, Kevin wrote: Vaibhav Hiremath hvaib...@ti.com writes: The function __omap2_set_globals() can be common across all platforms/architectures, even in case of omap4, internally it calls same set of functions as in __omap2_set_globals() function (except for sdrc). OK so far. This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc, so that we can reuse same function across omap2/3/4... But what happens when a single kernel is built that has support for an SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)? As such Nothing...I looking into this direction while implementing. In that case, sdrc.c file will be compiled in and execution will jump to omap2_set_globals_sdrc(). But inside this function, we are already checking whether the omap2_globals-sdrc and omap2_globals-sms for NULL and then use it. And function omap2_sdrc_init() is also depends on machine, so in case of Am33xx, it won't get into sdrc execution at all. And in case of omap4, it will. Then why bother with the #ifdef at all? If it already safe to call on all SoCs, just get rid of the #ifdef all together. Kevin, sdrc.o target gets built only as omap-2-3-common, this will not get built for omap4, am33xx, ti81xx, etc... So in order to avoid build break, you have to have some mechanism, and that's where we need to create config option dependent on platform. Another better way of handling this is adding __weak function. What's your opinion on this? Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: OMAP2+: Introduce CONFIG_SOC_HAS_OMAP_DPLL macro
Vaibhav,
[snip]
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index d0ef57c..095bee8 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -156,7 +156,7 @@ struct dpll_data {
u8 min_divider;
u16 max_divider;
u8 modes;
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
+#ifdef CONFIG_SOC_HAS_OMAP_DPLL
void __iomem *autoidle_reg;
void __iomem *idlest_reg;
u32 autoidle_mask;
@@ -167,7 +167,7 @@ struct dpll_data {
u8 auto_recal_bit;
u8 recal_en_bit;
u8 recal_st_bit;
-# endif
+#endif
I had submitted similar patch recently, and Kevin had suggested that
Instead of adding config option, we shoule simply get rid of this ifdef
completely.
Refer to
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg68293.html
Waiting for Paul to conform here.
Thanks for pointing that out. Will check on this and Paul's PRCM series
cleanup series then.
Thanks,
Sricharan
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: OMAP2+: Introduce CONFIG_SOC_HAS_OMAP_DPLL macro
Hi Vaibhav, Sricharan, Yesterday, Paul confirmed that, removing ifdef is the way to go. So just few mins back I had submitted patch for the same. http://permalink.gmane.org/gmane.linux.ports.arm.omap/76972 oh ya, was just looking at that. Thanks, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/4] ARM: OMAP2+: Introduce CONFIG_SOC_HAS_OMAP_DPLL macro
On Fri, May 11, 2012 at 11:46:32, R, Sricharan wrote: Vaibhav, [snip] Waiting for Paul to conform here. Thanks for pointing that out. Will check on this and Paul's PRCM series cleanup series then. Sricharan, Yesterday, Paul confirmed that, removing ifdef is the way to go. So just few mins back I had submitted patch for the same. http://permalink.gmane.org/gmane.linux.ports.arm.omap/76972 Thanks, Vaibhav -- 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+: CLEANUP: Remove ARCH_OMAPx ifdef from struct dpll_data
On Fri, May 11, 2012 at 11:32 AM, Vaibhav Hiremath hvaib...@ti.com wrote: From: Kevin Hilman khil...@ti.com There are certain fields inside 'struct dpll_data' which are included under ARCH_OMAP3 and ARCH_OMAP4 option, which makes it difficult to use it for new devices like, am33xx, ti81xx, etc... So remove the ifdef completely, this will add few fields to the struct unused, but it improves readability and maintainability of the code. Signed-off-by: Kevin Hilman khil...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: R Sricharan r.sricha...@ti.com --- Acked-by : Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
Vaibhav, This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc, so that we can reuse same function across omap2/3/4... But what happens when a single kernel is built that has support for an SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)? As such Nothing...I looking into this direction while implementing. In that case, sdrc.c file will be compiled in and execution will jump to omap2_set_globals_sdrc(). But inside this function, we are already checking whether the omap2_globals-sdrc and omap2_globals-sms for NULL and then use it. And function omap2_sdrc_init() is also depends on machine, so in case of Am33xx, it won't get into sdrc execution at all. And in case of omap4, it will. Then why bother with the #ifdef at all? If it already safe to call on all SoCs, just get rid of the #ifdef all together. Kevin, sdrc.o target gets built only as omap-2-3-common, this will not get built for omap4, am33xx, ti81xx, etc... So in order to avoid build break, you have to have some mechanism, and that's where we need to create config option dependent on platform. Another better way of handling this is adding __weak function. What's your opinion on this? Then how about just allowing to compile for all omap2/3/4 ? Thanks, Sricharan -- 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: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
On Fri, May 11, 2012 at 12:07:59, R, Sricharan wrote: Vaibhav, This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc, so that we can reuse same function across omap2/3/4... But what happens when a single kernel is built that has support for an SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)? As such Nothing...I looking into this direction while implementing. In that case, sdrc.c file will be compiled in and execution will jump to omap2_set_globals_sdrc(). But inside this function, we are already checking whether the omap2_globals-sdrc and omap2_globals-sms for NULL and then use it. And function omap2_sdrc_init() is also depends on machine, so in case of Am33xx, it won't get into sdrc execution at all. And in case of omap4, it will. Then why bother with the #ifdef at all? If it already safe to call on all SoCs, just get rid of the #ifdef all together. Kevin, sdrc.o target gets built only as omap-2-3-common, this will not get built for omap4, am33xx, ti81xx, etc... So in order to avoid build break, you have to have some mechanism, and that's where we need to create config option dependent on platform. Another better way of handling this is adding __weak function. What's your opinion on this? Then how about just allowing to compile for all omap2/3/4 ? I wouldn't recommend that. Also, now we have almost all the devices coming in with EMIF (no sdrc). Thanks, Vaibhav -- 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+: irq: Increase no of supported interrupts to 128
On Fri, May 11, 2012 at 03:19:21, Hilman, Kevin wrote: Hiremath, Vaibhav hvaib...@ti.com writes: On Wed, May 09, 2012 at 00:09:34, Hilman, Kevin wrote: Vaibhav Hiremath hvaib...@ti.com writes: With addition to TI81XX, AM33XX family of devices, the number of interrupts supported has increased to 128, compared to 96. The current implementation for irq handling is hardcoded to use 96 interrupts (with 3 register-sets to handle), this patch cleanups the code, to increase maximum number of interrupts support to 128, with dynamic detection of no of registers required for handling all interrupts. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Afzal Mohammed af...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Paul Walmsley p...@pwsan.com --- Ideally, we should use dynamic allocation to allocate memory for registers/arrays, Yes. Thanks Kevin, I will put this activity in my TODO list. may be too much cleanup for this patch, There is no such thing as too much cleanup. ;) And the INTC is in need of it, IMO. Indeed it is in need of cleanup... so as of now restricting to minimal changes to fit devices like, am33xx/ti81xx. Then someone else will have to do the cleanup later. It would be greatly appreciated if you could do the necessary cleanup in order to cleanly add support for more SoCs. Yes, we probably should've insisted when support for TI81xx was added, but that one slipped in under the radar. Yeah, I understand. As I said I will put this activity in my TODO list. For starters, the notion of a banks this code is a rather messed up and needs a cleanup. A bank is supposed to be a group of 32 interrupts, and the INTC is made up of 3 (or 4) banks. However, the current code creates a single bank of 96 (or 128) interrupts. It also confuses what registers are part of the bank and what are global to the INTC. This confusion is both in init and in context save/restore. IMO, to clean this up, first the notion of banks needs to be fixed in that code there is a distinction between what acts on banks and what works on the whole INTC. Then, the init/alloc should be done dynamically based on the number of interrupts passed to omap_init_irq() Kevin, Let me finish up with am33xx baseport upstream activity which is currently going on at full swing, then next thing I will pick up is this code cleanup. I still feel, this is still a valid cleanup patch, and can be merged, as it is required/used when we do major cleanup. Well, Tony can make that decision. Personally, I think this patch continues to add confusion on top of an existing mess, and to me provides the proverbial straw that broke the camel's back. That being said, the INTC core is an obviously important and sensitive piece of code so needs to be handled with care. In case Tony decides to merge this patch and allow a future** cleanup, I'll provide some comments. I am OK, lets drop this patch as of now, and I will take this when I start cleanup activity. Kevin ** since they rarely happen, we tend to not have too much faith in promises of mythical future cleanups. This is not because we don't trust you personally, but simply based on based experience. Very nicely said :) :) :) I agree with you, sometimes priorities changes and things doesn't happen the way we wanted to be. As I said earlier, I am now full time working on upstream (no ifs and buts); else I wouldn't have committed for this activity. Thanks, Vaibhav -- 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-V7 0/3] ARM: OMAP: Make OMAP clocksource source selection runtime
On Fri, May 11, 2012 at 03:06:48, Janusz Krzysztofik wrote: Dnia czwartek, 3 maja 2012 13:28:58 Vaibhav Hiremath pisze: Current OMAP code supports couple of clocksource options based on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz) This patch series cleans up the existing 32k-sync timer implementation, movind SoC init code to respective files (mach-omap1/timer32k.c and mach-omap2/timer.c) and uses kernel parameter to override the default clocksource of counter_32k, also in order to support some OMAP based derivative SoCs like AM33XX which doesn't have 32K sync-timer hardware IP, adds hwmod lookup for omap2+ devices, and if lookup fails then fall back to gp-timer. if(use_gptimer_clksrc == true) gptimer clocksource init; else if (counter_32 init == false) /* Fallback to gptimer */ gptimer clocksource init(; With this, we should be able to support multi-omap boot including devices with/without 32k-sync timer. This patch-series has been boot tested on AM37xEVM platform, it would be helpful if somebody help me to validate it on OMAP1/2 platforms. The patches are also available at (based on linux-omap/master) - https://github.com/hvaibhav/am335x-linux 32ksync-timer-cleanup Tried to test this branch, merged into 3.4-rc6, and with my Amstrad Delta fixes applied, using my custom Amstrad Delta config, but initially failed because an unrelated issue rised to the surface: | LD .tmp_vmlinux1 | arch/arm/mach-omap1/built-in.o: In function `omap1_usb_init': | lcd_dma.c:(.init.text+0x1420): undefined reference to `ocpi_enable' | make: *** [.tmp_vmlinux1] Error 1 Apparently introduced with commit d3645d39ad0ed9f09535065676ea0ba114f93cdf, ARM: OMAP1: OHCI: use platform_data fn ptr to enable OCPI bus, looks like one or more symbols exported by the not linked in arch/arm/mach-omap1/ocpi.o may be missing for non-OMAP16xx configs. Otherwise, if configured with OMAP16xx selected, builds and seems to work correctly for me, to the extent possible to verify without physical access to the hardware. However, please note that the Amstrad Delta doesn't make use of the 32k timer, only mpu_timer. Thanks Janusz for validating this, really appreciate your help here. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V2 2/4] ARM: OMAP2+: CLEANUP: Move omap3 dpll ops to dpll3xxx.c
On Fri, May 11, 2012 at 04:32:11, Paul Walmsley wrote: On Wed, 9 May 2012, Vaibhav Hiremath wrote: In order to remove unnecessary idefs, move noncore and core dpll ops to dpll3xxx.c file (where it should have been already). The clkops (clkops_omap3_core_dpll_ops clkops_omap3_noncore_dpll_ops) is used in clock data files, and dependency is already handled by Makefile rule. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Paul Walmsley p...@pwsan.com This is probably okay. Acked-by: Paul Walmsley p...@pwsan.com Thanks Paul, Thanks, Vaibhav -- 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 8/10] omap timer cleanup for v3.5 merge window
[+sfr]
On Thu, May 10, 2012 at 1:24 PM, Tony Lindgren t...@atomide.com wrote:
* Tony Lindgren t...@atomide.com [120510 11:55]:
* Tony Lindgren t...@atomide.com [120510 11:49]:
The following changes since commit
bfd17879866b36e95c58721da070d9f2ac7f8901:
Merge tag 'omap-devel-c-for-3.5' of
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into
devel-hwmod-data (2012-05-09 09:58:42 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-cleanup-timer-for-v3.5
for you to fetch changes up to 1fe97c8f6a1de67a5f56e029a818903d5bed8017:
ARM: OMAP: Make OMAP clocksource source selection using kernel param
(2012-05-09 10:07:05 -0700)
Timer changes to make it easier to support various SoCs
And this has a conflict for common headers:
...
Also looks like this produces a merge conflict with linux-next
commit bd0493ea (ARM: 7413/1: move read_{boot,persistent}_clock to
the architecture level). To resolve, the line to add
register_persistent_clock(NULL, omap_read_persistent_clock);
needs to be resolved as below.
Thanks for the heads up. Stephen, see below for tomorrow's -next rebuild.
-Olof
Regards,
Tony
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@@ -69,40 -69,55 +70,41 @@@ static void omap_read_persistent_clock(
*ts = *tsp;
}
-int __init omap_init_clocksource_32k(void)
+/**
+ * omap_init_clocksource_32k - setup and register counter 32k as a
+ * kernel clocksource
+ * @pbase: base addr of counter_32k module
+ * @size: size of counter_32k to map
+ *
+ * Returns 0 upon success or negative error code upon failure.
+ *
+ */
+int __init omap_init_clocksource_32k(void __iomem *vbase)
{
- 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
- return -ENODEV;
-
- /* For this to work we must have a static mapping in io.c for
this area */
- base = ioremap(pbase, size);
- if (!base)
- return -ENODEV;
-
- sync_32k_ick = clk_get(NULL, omap_32ksync_ick);
- if (!IS_ERR(sync_32k_ick))
- clk_enable(sync_32k_ick);
-
- timer_32k_base = base;
-
- /*
- * 12 rough estimate from the calculations in
- * __clocksource_updatefreq_scale.
- */
- clocks_calc_mult_shift(persistent_mult, persistent_shift,
- 32768, NSEC_PER_SEC, 12);
-
- if (clocksource_mmio_init(base, 32k_counter, 32768, 250, 32,
- clocksource_mmio_readl_up))
- printk(err, 32k_counter);
-
- setup_sched_clock(omap_32k_read_sched_clock, 32, 32768);
- register_persistent_clock(NULL, omap_read_persistent_clock);
+ int ret;
+
+ /*
+ * 32k sync Counter register offset is at 0x10
+ */
+ sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF;
+
+ /*
+ * 12 rough estimate from the calculations in
+ * __clocksource_updatefreq_scale.
+ */
+ clocks_calc_mult_shift(persistent_mult, persistent_shift,
+ 32768, NSEC_PER_SEC, 12);
+
+ ret = clocksource_mmio_init(sync32k_cnt_reg, 32k_counter, 32768,
+ 250, 32, clocksource_mmio_readl_up);
+ if (ret) {
+ pr_err(32k_counter: can't register clocksource\n);
+ return ret;
}
+
+ setup_sched_clock(omap_32k_read_sched_clock, 32, 32768);
+ pr_info(OMAP clocksource: 32k_counter at 32768 Hz\n);
++ register_persistent_clock(NULL, omap_read_persistent_clock);
+
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap
Re: [GIT PULL 1/10] omap non-critical fixes for v3.5 merge window
Tony, I've pulled all 10 requests. Many of them ended up going into the same next/ branch, but that's quite OK. Please double check my merge conflict resolutions. One nit is that at least one of the branches had a few varying patch subjects, so just a friendly reminder to sanitize them to ARM: OMAP.*: or so when you apply patches. I did notice that omap2plus_defconfig has grown a new warning caused by ARM: OMAP2+: clean up some cppcheck warnings (oh, the irony!): arch/arm/plat-omap/usb.c: In function 'omap_otg_init': arch/arm/plat-omap/usb.c:40:6: warning: unused variable 'status' [-Wunused-variable] -Olof -- 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
New OMAP build warning
arch/arm/plat-omap/usb.c: In function 'omap_otg_init': arch/arm/plat-omap/usb.c:40: warning: unused variable 'status' caused by: commit eeb3711b89d68e147e05e7b43a49ecc5009dc157 Author: Paul Walmsley p...@pwsan.com Date: Fri Apr 13 06:34:32 2012 -0600 ARM: OMAP2+: clean up some cppcheck warnings -- 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] usb/dwc3: Fix the dwc3 dependency
On Fri, May 11, 2012 at 11:25:24AM +0530, joseph daniel wrote: The warning shown up when ran with randconfig, warning: (USB_DWC3) selects USB_XHCI_PLATFORM which has unmet direct dependencies (USB_SUPPORT USB_XHCI_HCD) Signed-off-by: joseph daniel josephdanielwal...@gmail.com --- drivers/usb/dwc3/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig index d8f741f..68271fa 100644 --- a/drivers/usb/dwc3/Kconfig +++ b/drivers/usb/dwc3/Kconfig @@ -1,6 +1,6 @@ config USB_DWC3 tristate DesignWare USB3 DRD Core Support - depends on (USB USB_GADGET) + depends on (USB USB_SUPPORT USB_XCHI_HCD USB_GADGET) typo I would prefer the select to change: select XHCI_PLATFORM if (USB_SUPPORT USB_XHCI_HCD) or something similar. select USB_OTG_UTILS select USB_GADGET_DUALSPEED select USB_GADGET_SUPERSPEED -- balbi signature.asc Description: Digital signature
Re: [GIT PULL 1/10] omap non-critical fixes for v3.5 merge window
Hello Olof, On Fri, 11 May 2012, Olof Johansson wrote: I did notice that omap2plus_defconfig has grown a new warning caused by ARM: OMAP2+: clean up some cppcheck warnings (oh, the irony!): arch/arm/plat-omap/usb.c: In function 'omap_otg_init': arch/arm/plat-omap/usb.c:40:6: warning: unused variable 'status' [-Wunused-variable] Thanks, this has been fixed by: http://marc.info/?l=linux-omapm=133660322929805w=2 - 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: New OMAP build warning
On Fri, 11 May 2012, Russell King - ARM Linux wrote: arch/arm/plat-omap/usb.c: In function 'omap_otg_init': arch/arm/plat-omap/usb.c:40: warning: unused variable 'status' caused by: commit eeb3711b89d68e147e05e7b43a49ecc5009dc157 Author: Paul Walmsley p...@pwsan.com Date: Fri Apr 13 06:34:32 2012 -0600 ARM: OMAP2+: clean up some cppcheck warnings Thanks, this has been fixed by: http://marc.info/?l=linux-omapm=133660322929805w=2 - 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] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
On Thu, May 10, 2012 at 6:05 AM, Govindraj.R govindraj.r...@ti.com wrote:
From: Govindraj.R govindraj.r...@ti.com
The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of
default uart pads) removed default uart pads that where getting populated
and which was making rx pin wakeup capable. If uart pads was used in
different mode by any other module then it would fail since the default
pads took over all the uart pins forcefully. With removal of default pads
the rx_pad wakeup for console uart while waking up from off mode is broken.
Utilise the mux api available to probe the availability of mux pins
in uart mode and probe for availability of uart pin in mux mode0
if uart is available as uart pin itself then configure rx pin
as wakeup capable.
This patch itself doesn't cater to all boards. Boards using uart rx wakeup
mechanism should ensure the usage of omap_serial_init_port by configuring
required uart ports and pass necessary mux data, till then this probing of
uart pins can cater to enabling of rx pad wakeup to most of the boards.
This patch can also throw some boot warning from _omap_mux_get_by_name
if pin is requested for availability is not present while dynamically probing
the uart pins availability such boot warnings can be addressed only when board
files are patched with omap_serial_init_port calls passing the right pads
needed for a given port.
Discussion Threads for reference:
http://www.spinics.net/lists/linux-omap/msg69859.html
http://www.spinics.net/lists/linux-omap/msg68659.html
Cc: Felipe Balbi ba...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Russ Dill russ.d...@gmail.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Ameya Palande ameya.pala...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
Patching of all board files would be difficult as even I am not aware of all
omap-board schematics and uart port usage. So individual board file can be
enabled accordingly for uart usage by calling omap_serial_init_port call
with right mux data.
for testing: Patch based on v3.4-rc6
(tested on beagle-xm for off mode rx wakeup)
Patch targeted for v3.5
arch/arm/mach-omap2/mux.c | 3 +-
arch/arm/mach-omap2/mux.h | 10 ++
arch/arm/mach-omap2/serial.c | 65 +++--
3 files changed, 72 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 65c3391..d937ddd 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -217,8 +217,7 @@ static int __init _omap_mux_get_by_name(struct
omap_mux_partition *partition,
return -ENODEV;
}
-static int __init
-omap_mux_get_by_name(const char *muxname,
+int __init omap_mux_get_by_name(const char *muxname,
struct omap_mux_partition **found_partition,
struct omap_mux **found_mux)
{
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 69fe060..68927f1 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -225,8 +225,18 @@ omap_hwmod_mux_init(struct omap_device_pad *bpads, int
nr_pads);
*/
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state);
+int omap_mux_get_by_name(const char *muxname,
+ struct omap_mux_partition **found_partition,
+ struct omap_mux **found_mux);
#else
+static inline int omap_mux_get_by_name(const char *muxname,
+ struct omap_mux_partition **found_partition,
+ struct omap_mux **found_mux)
+{
+ return 0;
+}
+
static inline int omap_mux_init_gpio(int gpio, int val)
{
return 0;
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 9fc2f44..c097317 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -57,6 +57,7 @@ struct omap_uart_state {
struct list_head node;
struct omap_hwmod *oh;
+ struct omap_device_pad default_omap_uart_pads[2];
};
static LIST_HEAD(uart_list);
@@ -126,11 +127,68 @@ static void omap_uart_set_smartidle(struct
platform_device *pdev) {}
#endif /* CONFIG_PM */
#ifdef CONFIG_OMAP_MUX
-static void omap_serial_fill_default_pads(struct omap_board_data *bdata)
+
+#define OMAP_UART_DEFAULT_PAD_NAME_LEN 28
+static char rx_pad_name[OMAP_UART_DEFAULT_PAD_NAME_LEN],
+ tx_pad_name[OMAP_UART_DEFAULT_PAD_NAME_LEN] __initdata;
+
+static void __init
+omap_serial_fill_uart_tx_rx_pads(struct omap_board_data *bdata,
+ struct omap_uart_state *uart)
+{
+ uart-default_omap_uart_pads[0].name = rx_pad_name;
+ uart-default_omap_uart_pads[0].flags = OMAP_DEVICE_PAD_REMUX |
+
OMAP_DEVICE_PAD_WAKEUP;
+ uart-default_omap_uart_pads[0].enable = OMAP_PIN_INPUT |
+
Re: [GIT PULL 1/10] omap non-critical fixes for v3.5 merge window
On Fri, May 11, 2012 at 1:33 AM, Paul Walmsley p...@pwsan.com wrote: Hello Olof, On Fri, 11 May 2012, Olof Johansson wrote: I did notice that omap2plus_defconfig has grown a new warning caused by ARM: OMAP2+: clean up some cppcheck warnings (oh, the irony!): arch/arm/plat-omap/usb.c: In function 'omap_otg_init': arch/arm/plat-omap/usb.c:40:6: warning: unused variable 'status' [-Wunused-variable] Thanks, this has been fixed by: http://marc.info/?l=linux-omapm=133660322929805w=2 Sounds good, I'll wait for it to trickle in on a future pull request. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: OMAP: AM35xx: fix UART4 softreset
Hi Paul,
On 5/10/2012 7:29 PM, Paul Walmsley wrote:
During kernel init, the AM3505/AM3517 UART4 cannot complete its softreset:
omap_hwmod: uart4: softreset failed (waited 1 usec)
This also results in another warning later in the boot process:
omap_hwmod: uart4: enabled state can only be entered from initialized, idle, or
disabled state
From empirical observation, the AM35xx UART4 IP block requires either
uart1_fck or uart2_fck to be enabled while UART4 resets. Otherwise
the reset will never complete. So this patch adds uart1_fck as an
optional clock for UART4 and adds the appropriate hwmod flag to cause
uart1_fck to be enabled during the reset process. (The choice of
uart1_fck over uart2_fck was arbitrary.)
Unfortunately this observation raises many questions. Is it necessary
for uart1_fck or uart2_fck to be controlled with uart4_fck for the
UART4 to work correctly? What exactly do the AM35xx UART4 clock
tree and the related PRCM idle management FSMs look like? If anyone
has the ability to answer these questions through empirical functional
testing, or hardware information from the AM35xx designers, it would
be greatly appreciated.
I do not have any clue about that chip, but is this clock really what it
is supposed to be? I mean, isn't the uart1_fck the parent of all the
UART fck or something like that. Don't we just have an issue becasue the
clock names are not accurate?
Regards,
Benoit
Cc: Benoît Coussonb-cous...@ti.com
Cc: Kyle Mannakyle.ma...@fuel7.com
Cc: Mark A. Greermgr...@animalcreek.com
Cc: Ranjith Lohithakshanranji...@ti.com
Signed-off-by: Paul Walmsleyp...@pwsan.com
---
arch/arm/mach-omap2/clock3xxx_data.c |8 ++--
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 17 +
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 11644bf..12c64db 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3201,8 +3201,12 @@ static struct clk vpfe_fck = {
};
/*
- * The UART1/2 functional clock acts as the functional
- * clock for UART4. No separate fclk control available.
+ * The UART1/2 functional clock acts as the functional clock for
+ * UART4. No separate fclk control available. XXX Well now we have a
+ * uart4_fck that is apparently used as the UART4 functional clock,
+ * but it also seems that uart1_fck or uart2_fck are still needed, at
+ * least for UART4 softresets to complete. This really needs
+ * clarification.
*/
static struct clk uart4_ick_am35xx = {
.name = uart4_ick,
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index c939131..c6653a80 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -535,6 +535,20 @@ static struct omap_hwmod_dma_info am35xx_uart4_sdma_reqs[]
= {
{ .dma_req = -1 }
};
+/*
+ * XXX AM35xx UART4 cannot complete its softreset without uart1_fck or
+ * uart2_fck being enabled. So we add uart1_fck as an optional clock,
+ * below, and set the HWMOD_CONTROL_OPT_CLKS_IN_RESET. This really
+ * should not be needed. The functional clock structure of the AM35xx
+ * UART4 is extremely unclear and opaque; it is unclear what the role
+ * of uart1/2_fck is for the UART4. Any clarification from either
+ * empirical testing or the AM3505/3517 hardware designers would be
+ * most welcome.
+ */
+static struct omap_hwmod_opt_clk am35xx_uart4_opt_clks[] = {
+ { .role = softreset_uart1_fck, .clk = uart1_fck },
+};
+
static struct omap_hwmod am35xx_uart4_hwmod = {
.name = uart4,
.mpu_irqs = am35xx_uart4_mpu_irqs,
@@ -549,6 +563,9 @@ static struct omap_hwmod am35xx_uart4_hwmod = {
.idlest_idle_bit = AM35XX_ST_UART4_SHIFT,
},
},
+ .opt_clks = am35xx_uart4_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(am35xx_uart4_opt_clks),
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.class =omap2_uart_class,
};
--
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] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
On Fri, May 11, 2012 at 12:41 AM, Tony Lindgren t...@atomide.com wrote:
* Govindraj.R govindraj.r...@ti.com [120510 06:09]:
From: Govindraj.R govindraj.r...@ti.com
The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of
default uart pads) removed default uart pads that where getting populated
and which was making rx pin wakeup capable. If uart pads was used in
Nitpick.. this should say were used here ^^^
will change this.
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -295,8 +353,7 @@ void __init omap_serial_board_init(struct
omap_uart_port_info *info)
bdata.pads = NULL;
bdata.pads_cnt = 0;
- if (cpu_is_omap44xx() || cpu_is_omap34xx())
- omap_serial_fill_default_pads(bdata);
+ omap_serial_check_wakeup(bdata, uart);
Should this section become:
if (!info) {
omap_serial_check_wakeup(bdata, uart);
omap_serial_init_port(bdata, NULL);
} else {
omap_serial_init_port(bdata, info[uart-num]);
}
As if you have bdata, then there should not be anything to mux,
right?
populating bdata should not depend on port_info,
omap_serial_board_init takes only port info parameter and tries to populate
wakeup parameter since it has not received the same from board file.
And board file may or may not pass port info.
So populating bdata - for uart wakeup pin should not be coupled with
availability of port info.
--
Thanks,
Govindraj.R
--
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] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
On Fri, May 11, 2012 at 2:04 PM, Russ Dill russ.d...@gmail.com wrote: On Thu, May 10, 2012 at 6:05 AM, Govindraj.R govindraj.r...@ti.com wrote: From: Govindraj.R govindraj.r...@ti.com The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of default uart pads) removed default uart pads that where getting populated and which was making rx pin wakeup capable. If uart pads was used in different mode by any other module then it would fail since the default pads took over all the uart pins forcefully. With removal of default pads the rx_pad wakeup for console uart while waking up from off mode is broken. [...] + * Check if uart is used in default tx/rx mode i.e. in mux mode0 + * if yes then configure rx pin for wake up capability + */ + if (!(rx_mode 0x07) !(tx_mode 0x07)) + omap_serial_fill_uart_tx_rx_pads(bdata, uart); I realize the comment makes it clear, but it'd probably be better to just make the code clear. I noticed mux.h has a OMAP_MODE_GPIO(x) macro for testing if a mux is in mode4. Perhaps its time to start expanding on that, at least with a macro like: #define OMAP_MUX_MODE(x) ((x) OMAP_MUX_MODE7) So you can do a OMAP_MUX_MODE(rx_mode) == OMAP_MUX_MODE0 Yes sure, will add the macro and use the same. (will post v3 addressing the comments received so far) -- Thanks, Govindraj.R -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: OMAP: AM35xx: fix UART4 softreset
Hi Benoît On Fri, 11 May 2012, Cousson, Benoit wrote: I do not have any clue about that chip, but is this clock really what it is supposed to be? I mean, isn't the uart1_fck the parent of all the UART fck or something like that. Don't we just have an issue becasue the clock names are not accurate? I guess that's what I'm trying to find out. According to the AM3517 TRM rev. B (SPRUGR0B) Figure 14-20 UART Functional Integration and Table 14-11 UART Clocks, all of the UARTs appear to have independent functional clocks. The table even mentions a CM_FCLKEN1_CORE.EN_UART4 bit. But the PRCM chapter of this TRM doesn't mention that at all. So the documentation is not too useful here. On the rest of the OMAPs, as far as I know, the UART clocks are all separate. - Paul
Re: [PATCH 2/2] mfd: twl: remove pdata-irq_base/_end, no more users
Hi Kevin, On Tue, May 08, 2012 at 10:19:02AM -0700, Kevin Hilman wrote: After converstion to SPARSE_IRQ, the driver doesn't use the pdata-irq_base/irq_end fields anymore. The last users have been cleanup up, and now these fields can be removed. Cc: Benoit Cousson b-cous...@ti.com Cc: Samuel Ortiz sa...@linux.intel.com Signed-off-by: Kevin Hilman khil...@ti.com Acked-by: Samuel Ortiz sa...@linux.intel.com Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: OMAP: AM35xx: fix UART4 softreset
On 5/11/2012 11:22 AM, Paul Walmsley wrote: Hi Benoît On Fri, 11 May 2012, Cousson, Benoit wrote: I do not have any clue about that chip, but is this clock really what it is supposed to be? I mean, isn't the uart1_fck the parent of all the UART fck or something like that. Don't we just have an issue becasue the clock names are not accurate? I guess that's what I'm trying to find out. According to the AM3517 TRM rev. B (SPRUGR0B) Figure 14-20 UART Functional Integration and Table 14-11 UART Clocks, all of the UARTs appear to have independent functional clocks. The table even mentions a CM_FCLKEN1_CORE.EN_UART4 bit. But the PRCM chapter of this TRM doesn't mention that at all. So the documentation is not too useful here. On the rest of the OMAPs, as far as I know, the UART clocks are all separate. In fact, not really. The same PER_48M_GFCLK clock is used for every UART instances in OMAP4. We do have a separate modulemode for each UART but as far as clocks are concerned, the source clock is the same. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: OMAP: AM35xx: fix UART4 softreset
On Fri, 11 May 2012, Cousson, Benoit wrote: On 5/11/2012 11:22 AM, Paul Walmsley wrote: On the rest of the OMAPs, as far as I know, the UART clocks are all separate. In fact, not really. The same PER_48M_GFCLK clock is used for every UART instances in OMAP4. We do have a separate modulemode for each UART but as far as clocks are concerned, the source clock is the same. By separate I mean that they are all independently gated. This does not appear to be the case with AM3517. Or perhaps it is the case and something isn't right with the idle management FSMs. - 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
[PATCH v3] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
From: Govindraj.R govindraj.r...@ti.com
The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of
default uart pads) removed default uart pads that where getting populated
and which was making rx pin wakeup capable. If uart pads were used in
different mode by any other module then it would fail since the default
pads took over all the uart pins forcefully. With removal of default pads
the rx_pad wakeup for console uart while waking up from off mode is broken.
Utilise the mux api available to probe the availability of mux pins
in uart mode and probe for availability of uart pin in mux mode0
if uart is available as uart pin itself then configure rx pin
as wakeup capable.
This patch itself doesn't cater to all boards. Boards using uart rx wakeup
mechanism should ensure the usage of omap_serial_init_port by configuring
required uart ports and pass necessary mux data, till then this probing of
uart pins can cater to enabling of rx pad wakeup to most of the boards.
This patch can also throw some boot warning from _omap_mux_get_by_name
if pin is requested for availability is not present while dynamically probing
the uart pins availability such boot warnings can be addressed only when board
files are patched with omap_serial_init_port calls passing the right pads
needed for a given port.
Discussion Threads for reference:
http://www.spinics.net/lists/linux-omap/msg69859.html
http://www.spinics.net/lists/linux-omap/msg68659.html
Cc: Felipe Balbi ba...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Russ Dill russ.d...@gmail.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Ameya Palande ameya.pala...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
Patching of all board files would be difficult as even I am not aware of all
omap-board schematics and uart port usage. So individual board file can be
enabled accordingly for uart usage by calling omap_serial_init_port call
with right mux data.
for testing: Patch based on v3.4-rc6
(tested on beagle-xm for off mode rx wakeup)
Patch targeted for v3.5
arch/arm/mach-omap2/mux.c|3 +-
arch/arm/mach-omap2/mux.h| 11 +++
arch/arm/mach-omap2/serial.c | 65 +++--
3 files changed, 73 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 65c3391..d937ddd 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -217,8 +217,7 @@ static int __init _omap_mux_get_by_name(struct
omap_mux_partition *partition,
return -ENODEV;
}
-static int __init
-omap_mux_get_by_name(const char *muxname,
+int __init omap_mux_get_by_name(const char *muxname,
struct omap_mux_partition **found_partition,
struct omap_mux **found_mux)
{
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 69fe060..471e62a 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -59,6 +59,7 @@
#define OMAP_PIN_OFF_WAKEUPENABLE OMAP_WAKEUP_EN
#define OMAP_MODE_GPIO(x) (((x) OMAP_MUX_MODE7) == OMAP_MUX_MODE4)
+#define OMAP_MODE_UART(x) (((x) OMAP_MUX_MODE7) == OMAP_MUX_MODE0)
/* Flags for omapX_mux_init */
#define OMAP_PACKAGE_MASK 0x
@@ -225,8 +226,18 @@ omap_hwmod_mux_init(struct omap_device_pad *bpads, int
nr_pads);
*/
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state);
+int omap_mux_get_by_name(const char *muxname,
+ struct omap_mux_partition **found_partition,
+ struct omap_mux **found_mux);
#else
+static inline int omap_mux_get_by_name(const char *muxname,
+ struct omap_mux_partition **found_partition,
+ struct omap_mux **found_mux)
+{
+ return 0;
+}
+
static inline int omap_mux_init_gpio(int gpio, int val)
{
return 0;
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 9fc2f44..2dc50e7 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -57,6 +57,7 @@ struct omap_uart_state {
struct list_head node;
struct omap_hwmod *oh;
+ struct omap_device_pad default_omap_uart_pads[2];
};
static LIST_HEAD(uart_list);
@@ -126,11 +127,68 @@ static void omap_uart_set_smartidle(struct
platform_device *pdev) {}
#endif /* CONFIG_PM */
#ifdef CONFIG_OMAP_MUX
-static void omap_serial_fill_default_pads(struct omap_board_data *bdata)
+
+#define OMAP_UART_DEFAULT_PAD_NAME_LEN 28
+static char rx_pad_name[OMAP_UART_DEFAULT_PAD_NAME_LEN],
+ tx_pad_name[OMAP_UART_DEFAULT_PAD_NAME_LEN] __initdata;
+
+static void __init
+omap_serial_fill_uart_tx_rx_pads(struct omap_board_data *bdata,
+ struct omap_uart_state *uart)
+{
+ uart-default_omap_uart_pads[0].name = rx_pad_name;
+ uart-default_omap_uart_pads[0].flags = OMAP_DEVICE_PAD_REMUX |
+
Re: [PATCH 3/3] ARM: OMAP: AM35xx: fix UART4 softreset
On 5/11/2012 11:35 AM, Paul Walmsley wrote: On Fri, 11 May 2012, Cousson, Benoit wrote: On 5/11/2012 11:22 AM, Paul Walmsley wrote: On the rest of the OMAPs, as far as I know, the UART clocks are all separate. In fact, not really. The same PER_48M_GFCLK clock is used for every UART instances in OMAP4. We do have a separate modulemode for each UART but as far as clocks are concerned, the source clock is the same. By separate I mean that they are all independently gated. This does not appear to be the case with AM3517. Or perhaps it is the case and something isn't right with the idle management FSMs. But they are not separately gated for OMAP4 either. This is the modulemode trick that make us think that, but it just means that the PRCM should ensure that this clock is needed when at least one UART modulemode is enabled. In fact the SPI modules are using the same clock. The modulemode is used to do some reference counting, but the gating is done globally. It was the same with the FCK_EN and ICK_EN in OMAP23. The PRCM spec show only one global gating between FUNC_48M_FCLK and PER_48M_GFCLK. All the modules are sharing the exact same clock. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb/dwc3: Fix the dwc3 dependency
Hi Felipe, On Fri, May 11, 2012 at 1:27 PM, Felipe Balbi ba...@ti.com wrote: On Fri, May 11, 2012 at 11:25:24AM +0530, joseph daniel wrote: The warning shown up when ran with randconfig, warning: (USB_DWC3) selects USB_XHCI_PLATFORM which has unmet direct dependencies (USB_SUPPORT USB_XHCI_HCD) Signed-off-by: joseph daniel josephdanielwal...@gmail.com --- drivers/usb/dwc3/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig index d8f741f..68271fa 100644 --- a/drivers/usb/dwc3/Kconfig +++ b/drivers/usb/dwc3/Kconfig @@ -1,6 +1,6 @@ config USB_DWC3 tristate DesignWare USB3 DRD Core Support - depends on (USB USB_GADGET) + depends on (USB USB_SUPPORT USB_XCHI_HCD USB_GADGET) typo I would prefer the select to change: select XHCI_PLATFORM if (USB_SUPPORT USB_XHCI_HCD) will do this and send out a patch shotly. or something similar. select USB_OTG_UTILS select USB_GADGET_DUALSPEED select USB_GADGET_SUPERSPEED -- balbi Thanks -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] usb/dwc3: Fix the dwc3 dependency
The warning shown up when ran with randconfig, warning: (USB_DWC3) selects USB_XHCI_PLATFORM which has unmet direct dependencies (USB_SUPPORT USB_XHCI_HCD) Signed-off-by: joseph daniel josephdanielwal...@gmail.com --- drivers/usb/dwc3/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig index d8f741f..d13c60f 100644 --- a/drivers/usb/dwc3/Kconfig +++ b/drivers/usb/dwc3/Kconfig @@ -4,7 +4,7 @@ config USB_DWC3 select USB_OTG_UTILS select USB_GADGET_DUALSPEED select USB_GADGET_SUPERSPEED - select USB_XHCI_PLATFORM + select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD help Say Y or M here if your system has a Dual Role SuperSpeed USB controller based on the DesignWare USB3 IP Core. -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: OMAP: AM35xx: fix UART4 softreset
On Fri, 11 May 2012, Cousson, Benoit wrote: But they are not separately gated for OMAP4 either. This is the modulemode trick that make us think that, but it just means that the PRCM should ensure that this clock is needed when at least one UART modulemode is enabled. In fact the SPI modules are using the same clock. The modulemode is used to do some reference counting, but the gating is done globally. It was the same with the FCK_EN and ICK_EN in OMAP23. The PRCM spec show only one global gating between FUNC_48M_FCLK and PER_48M_GFCLK. All the modules are sharing the exact same clock. Well, on OMAP3 and AM3517, they do not all share the same clock. If you look at the 34xx TRM vZU Table 17-11 UART Clocks, you can see that the UART1 and 2 functional clocks are sourced from clocks managed by the CORE clockdomain, while UART3 is sourced from clocks managed by the PER clockdomain. This is also expressed in our OMAP3 clock tree. I realize this is slightly tangential to your point. As to where the clock gating nodes are actually located on a given piece of silicon, unfortunately I have no way of confirming that, aside from power measurement. You might be correct about what's going on with the AM3517 but it would be nice to get some confirmation from the AM35xx PRCM engineer(s). At this point one of two possibilities seem likely: either CM_FCLKEN1_CORE.EN_UART4 does nothing, or CM_FCLKEN1_CORE.EN_UART4 is necessary but not sufficient to get the UART4 to work. If CM_FCLKEN1_CORE.EN_UART4 does not actually do anything then we need to remove it from the kernel and ideally file a documentation bug to get it removed from the TRM. On the other hand, if we do have to enable CM_FCLKEN1_CORE.EN_UART4 to deassert the IdleAck to UART4, but the PRCM usecounting is broken, then I guess we'll need to add a workaround to the hwmod code to essentially support multiple main clocks. - 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] usb/dwc3: Fix the dwc3 dependency
Hello. On 11-05-2012 9:55, joseph daniel wrote: The warning shown up when ran with randconfig, warning: (USB_DWC3) selects USB_XHCI_PLATFORM which has unmet direct dependencies (USB_SUPPORT USB_XHCI_HCD) Signed-off-by: joseph danieljosephdanielwal...@gmail.com --- drivers/usb/dwc3/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig index d8f741f..68271fa 100644 --- a/drivers/usb/dwc3/Kconfig +++ b/drivers/usb/dwc3/Kconfig @@ -1,6 +1,6 @@ config USB_DWC3 tristate DesignWare USB3 DRD Core Support - depends on (USB USB_GADGET) + depends on (USB USB_SUPPORT USB_XCHI_HCD USB_GADGET) Parens not needed -- could as well get rid of them. WBR, Sergei -- 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: oprofile and ARM A9 hardware counter
On Thu, May 10, 2012 at 07:55:01PM +0100, Jon Hunter wrote: Hi Will, Hi Jon, For my testing I have just been reading the PM_EMU_PWRSTST register which shows the power state of the EMU power domain. It should read 3 when the power domain is ON and 0 when it is off. I did something like the following (dumping all EMU clock and power domain registers). I figured I may as well take perf for a spin and see how I got on. The good news is that the hwmod bits all seem to work as before and the correct IRQs are requested: root@florentine-pogen:~# cat /proc/interrupts CPU0 CPU1 29: 44527 17916 GIC twd 33: 0 0 GIC arm-pmu 34: 0 0 GIC arm-pmu But, unfortunately, as you can see from the above, I just can't persuade them to fire. The PMU counters do tick, but they happily increment through zero without us realising. I retested with my perf/omap4 branch to make sure my board is ok, and the irqs do fire there. Any ideas? Cheers, Will -- 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: OMAP2+: Add AM335x and AM3517/05 EVM DT support
Hi Tony, Here are some remaining DT patches I was not able to push at 3.4 due to some missing dependency. It applies now fine on top of lo/dt branch. Regards, Benoit The following changes since commit 40364b9f5a4d167d97bb6a76cd239ca8cfff056a: Benoit Cousson (1): arm/dts: omap4-panda: Add LEDs support are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.5/dts/am33xx Vaibhav Hiremath (3): arm/dts: Add support for TI AM335x EVM board arm/dts: omap3-evm: Add i2c and twl4030 support arm/dts: Add support for TI AM3517/05 EVM board arch/arm/boot/dts/am335x-evm.dts | 39 ++ arch/arm/boot/dts/am3517-evm.dts | 32 +++ arch/arm/boot/dts/omap3-evm.dts | 28 +++ 3 files changed, 99 insertions(+), 0 deletions(-) create mode 100644 arch/arm/boot/dts/am335x-evm.dts create mode 100644 arch/arm/boot/dts/am3517-evm.dts -- 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 14/14] OMAPDSS: HDMI: Implement DSS driver interface for audio
On Thu, 2012-05-10 at 20:56 -0500, Ricardo Neri wrote: Sorry, some hunks where missing in the patch that I submitted yesterday. I just pushed a branch containing the whole most up-to-date series here: git://gitorious.org/omap-audio/linux-audio.git ricardon/topic/dss_audio-for-tomi This includes the implementation of the DSS audio interface for HDMI covering the improved locking strategy [1][2], plus the missing hunks in my yesterday's patch, plus handling of mode changes you pointed out. Please let me know if you want me to resubmit the whole patch series so that you can comment if you need to. Thanks, I think this is fine. I had to rebase your branch as you had some extra patches there also. There were also a few conflicts with latest dss stuff, but nothing serious. I pushed the branch with latest dss and your branch to: git://gitorious.org/linux-omap-dss2/linux.git test With a quick test video works ok, but I didn't test audio. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH] OMAP4: panda: add statics to remove warnings
On Fri, 2012-05-04 at 12:29 -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [120425 05:32]: On Tue, 2012-04-24 at 10:16 -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [120423 00:43]: Add statics to board-omap4-panda.c's internal functions and data structures to remove warnings. Care to update with the warnings produced? Ah, sure. Updated patch below: From e96ddeb7d783d48a15a32f8ef5a7bae3089f66b9 Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen tomi.valkei...@ti.com Date: Wed, 28 Mar 2012 11:38:58 +0300 Subject: [PATCH] OMAP4: panda: add statics to remove warnings Add statics to board-omap4-panda.c's internal functions and data structures to remove sparse warnings: arch/arm/mach-omap2/board-omap4panda.c:234:29: warning: symbol 'omap_panda_wlan_data' was not declared. Should it be static? arch/arm/mach-omap2/board-omap4panda.c:441:24: warning: symbol 'omap4_panda_dvi_device' was not declared. Should it be static? arch/arm/mach-omap2/board-omap4panda.c:451:12: warning: symbol 'omap4_panda_dvi_init' was not declared. Should it be static? arch/arm/mach-omap2/board-omap4panda.c:512:13: warning: symbol 'omap4_panda_display_init' was not declared. Should it be static? Thanks adding to fixes-non-critical. It seems this patch is obsolete, as there's already one in linux-next: commit 8c3d4534a8da0dc6a2d52b61585e61f7e8143096 Author: Paul Walmsley p...@pwsan.com Date: Fri Apr 13 06:34:26 2012 -0600 ARM: OMAP2+: declare file-local functions as static Tomi signature.asc Description: This is a digitally signed message part
Re: oprofile and ARM A9 hardware counter
Hi Will On 05/11/2012 07:25 AM, Will Deacon wrote: On Thu, May 10, 2012 at 07:55:01PM +0100, Jon Hunter wrote: Hi Will, Hi Jon, For my testing I have just been reading the PM_EMU_PWRSTST register which shows the power state of the EMU power domain. It should read 3 when the power domain is ON and 0 when it is off. I did something like the following (dumping all EMU clock and power domain registers). I figured I may as well take perf for a spin and see how I got on. The good news is that the hwmod bits all seem to work as before and the correct IRQs are requested: root@florentine-pogen:~# cat /proc/interrupts CPU0 CPU1 29: 44527 17916 GIC twd 33: 0 0 GIC arm-pmu 34: 0 0 GIC arm-pmu But, unfortunately, as you can see from the above, I just can't persuade them to fire. The PMU counters do tick, but they happily increment through zero without us realising. I retested with my perf/omap4 branch to make sure my board is ok, and the irqs do fire there. Any ideas? Do you disable OMAP2/3 support in the kernel config, so that CPU_HAS_PMU is enabled? Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Fri, May 11, 2012 at 02:47:17PM +0100, Jon Hunter wrote: On 05/11/2012 07:25 AM, Will Deacon wrote: I figured I may as well take perf for a spin and see how I got on. The good news is that the hwmod bits all seem to work as before and the correct IRQs are requested: root@florentine-pogen:~# cat /proc/interrupts CPU0 CPU1 29: 44527 17916 GIC twd 33: 0 0 GIC arm-pmu 34: 0 0 GIC arm-pmu But, unfortunately, as you can see from the above, I just can't persuade them to fire. The PMU counters do tick, but they happily increment through zero without us realising. I retested with my perf/omap4 branch to make sure my board is ok, and the irqs do fire there. Any ideas? Do you disable OMAP2/3 support in the kernel config, so that CPU_HAS_PMU is enabled? I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that way. Will -- 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: omap: dmtimer: fix incorrect TCRR value in posted mode
Timers in PER domain periodically report old time from TCRR in posted mode unless ICLK = 4 * FCLK. The problem is addressed in the following manner: Patch 1: Adds ick alias in the clkdev table so that dmtimer code can extract the iclk rate using clk_get_rate(). Patch 2: The final logic added in omap_dm_timer_prepare() where timer is set to non-posted mode if iclk 4*fclk. Rajendra Nayak (1): ARM: omap: hwmod: Add an 'ick' clkdev alias Tarun Kanti DebBarma (1): ARM: omap: dmtimer: set non-posted mode if iclk less than 4*fck arch/arm/plat-omap/dmtimer.c | 12 arch/arm/plat-omap/omap_device.c |3 +++ 2 files changed, 15 insertions(+), 0 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 1/2] ARM: omap: hwmod: Add an 'ick' clkdev alias
From: Rajendra Nayak rna...@ti.com For all hwmods' with just one slave interface, use the slave-clk to add an 'ick' clkdev alias in the table. This is useful for drivers of such devices to get the interface clock using 'clk_get(dev, ick)' Signed-off-by: Rajendra Nayak rna...@ti.com --- arch/arm/plat-omap/omap_device.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index d50cbc6..c8bc005 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -311,6 +311,9 @@ static void _add_hwmod_clocks_clkdev(struct omap_device *od, for (i = 0; i oh-opt_clks_cnt; i++) _add_clkdev(od, oh-opt_clks[i].role, oh-opt_clks[i].clk); + + if (oh-slaves_cnt == 1) + _add_clkdev(od, ick, oh-slaves[0]-clk); } -- 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 2/2] ARM: omap: dmtimer: set non-posted mode if iclk less than 4*fck
Timers in PER domain periodically report old time from TCRR in
posted mode if ick 4*fck. Therefore, set timer to non-posted
whenever ick 4*fck for all timers.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 15e7882..a81b85e 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -378,6 +378,7 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer,
int source)
{
int ret;
struct dmtimer_platform_data *pdata;
+ struct clk *iclk;
if (unlikely(!timer))
return -EINVAL;
@@ -388,6 +389,17 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer,
int source)
return -EINVAL;
ret = pdata-set_timer_src(timer-pdev, source);
+ /*
+* Timers in PER domain periodically report old time
+* from TCRR in posted mode if ick 4*fck. Hence,
+* when this condition is satisfied setting the timer
+* to non-posted mode, instead.
+*/
+ if (!IS_ERR(ret)) {
+ iclk = clk_get(timer-pdev-dev, ick);
+ if (clk_get_rate(iclk) (4 * clk_get_rate(timer-fclk)))
+ timer-posted = 0;
+ }
return ret;
}
--
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 02/19] ARM: OMAP4: PM: save/restore all CM1/2 settings in OFF mode
On Wed, 2012-05-09 at 16:27 -0700, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
From: Rajendra Nayak rna...@ti.com
Restore all CM1/2 module registers as they are lost in OFF mode.
Except they are still lost since nobody calls these new functions (in
this patch.) :)
For ease of review, it's preferred to add the *users* of new code in the
same patch as the new code.
I'll fix this for the next version. I think this same comment applies to
patch #3 also.
[n...@ti.com: minor clean ups]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Axel Haslam axelhas...@gmail.com
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/cm44xx.c | 322
++
arch/arm/mach-omap2/cm44xx.h |2 +
2 files changed, 324 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/cm44xx.c b/arch/arm/mach-omap2/cm44xx.c
index 535d66e..fb5465b 100644
--- a/arch/arm/mach-omap2/cm44xx.c
+++ b/arch/arm/mach-omap2/cm44xx.c
@@ -21,8 +21,11 @@
#include iomap.h
#include common.h
#include cm.h
+#include cm44xx.h
#include cm1_44xx.h
#include cm2_44xx.h
+#include cminst44xx.h
+#include prcm44xx.h
#include cm-regbits-44xx.h
/* CM1 hardware module low-level functions */
@@ -50,3 +53,322 @@ void omap4_cm2_write_inst_reg(u32 val, s16 inst, u16
reg)
{
__raw_writel(val, OMAP44XX_CM2_REGADDR(inst, reg));
}
+
+#define MAX_CM_REGISTERS 51
+
+struct omap4_cm_reg {
+ u16 offset;
+ u32 val;
+};
+
+struct omap4_cm_regs {
+ u32 mod_off;
+ u32 no_reg;
minor: do these need to be u32?
u16 should be good enough to save space I guess, I'll try changing this
and see what happens.
+ struct omap4_cm_reg reg[MAX_CM_REGISTERS];
+};
+
+static struct omap4_cm_regs cm1_regs[] = {
+ /* OMAP4430_CM1_OCP_SOCKET_MOD */
+ { .mod_off = OMAP4430_CM1_OCP_SOCKET_INST, .no_reg = 1,
+ {{.offset = OMAP4_CM_CM1_PROFILING_CLKCTRL_OFFSET} },
For readability sake, I'd prefer to see this line indented. And why
the extra space before the final '}'}
These tables are horrible, would be better to get rid of them completely
but I guess that is not possible... I'll look at the indentation.
+ },
[...]
+static void omap4_cm1_prepare_off(void)
+{
+ u32 i, j;
+ struct omap4_cm_regs *cm_reg = cm1_regs;
+
+ for (i = 0; i ARRAY_SIZE(cm1_regs); i++, cm_reg++) {
+ for (j = 0; j cm_reg-no_reg; j++) {
+ cm_reg-reg[j].val =
+ omap4_cminst_read_inst_reg(OMAP4430_CM1_PARTITION,
+ cm_reg-mod_off,
+ cm_reg-reg[j].offset);
+ }
+ }
+}
+
+static void omap4_cm2_prepare_off(void)
+{
+ u32 i, j;
+ struct omap4_cm_regs *cm_reg = cm2_regs;
+
+ for (i = 0; i ARRAY_SIZE(cm2_regs); i++, cm_reg++) {
+ for (j = 0; j cm_reg-no_reg; j++) {
+ cm_reg-reg[j].val =
+ omap4_cminst_read_inst_reg(OMAP4430_CM2_PARTITION,
+ cm_reg-mod_off,
+ cm_reg-reg[j].offset);
+ }
+ }
+}
+static void omap4_cm1_resume_off(void)
+{
+ u32 i, j;
+ struct omap4_cm_regs *cm_reg = cm1_regs;
+
+ for (i = 0; i ARRAY_SIZE(cm1_regs); i++, cm_reg++) {
+ for (j = 0; j cm_reg-no_reg; j++) {
+ omap4_cminst_write_inst_reg(cm_reg-reg[j].val,
+ OMAP4430_CM1_PARTITION,
+ cm_reg-mod_off,
+ cm_reg-reg[j].offset);
+ }
+ }
+}
+
+static void omap4_cm2_resume_off(void)
+{
+ u32 i, j;
+ struct omap4_cm_regs *cm_reg = cm2_regs;
+
+ for (i = 0; i ARRAY_SIZE(cm2_regs); i++, cm_reg++) {
+ for (j = 0; j cm_reg-no_reg; j++) {
+ omap4_cminst_write_inst_reg(cm_reg-reg[j].val,
+ OMAP4430_CM2_PARTITION,
+ cm_reg-mod_off,
+ cm_reg-reg[j].offset);
+ }
+ }
+}
Notice the two prpare functions (and resume functions) are basically
identical, except for the partition.
How about adding a .partition field to the struct so there can be a
single function}
Yea, should be possible. I'll fix this for next rev.
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Will, On 05/11/2012 08:49 AM, Will Deacon wrote: On Fri, May 11, 2012 at 02:47:17PM +0100, Jon Hunter wrote: On 05/11/2012 07:25 AM, Will Deacon wrote: I figured I may as well take perf for a spin and see how I got on. The good news is that the hwmod bits all seem to work as before and the correct IRQs are requested: root@florentine-pogen:~# cat /proc/interrupts CPU0 CPU1 29: 44527 17916 GIC twd 33: 0 0 GIC arm-pmu 34: 0 0 GIC arm-pmu But, unfortunately, as you can see from the above, I just can't persuade them to fire. The PMU counters do tick, but they happily increment through zero without us realising. I retested with my perf/omap4 branch to make sure my board is ok, and the irqs do fire there. Any ideas? Do you disable OMAP2/3 support in the kernel config, so that CPU_HAS_PMU is enabled? I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that way. I tried the same (make omap2plus_defconfig and enabled the above option), and I do see the interrupts firing on both 4430 and 4460... / # cat /proc/interrupts CPU0 CPU1 29: 1023404 GIC twd 33:401 0 GIC arm-pmu 34: 0441 GIC arm-pmu What is your kernel commit ID that you applied the patches on top of? What board are you using? Blaze, panda, etc, and is it 4430 or 4460? Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Fri, May 11, 2012 at 03:52:59PM +0100, Jon Hunter wrote: Hi Will, Hello, On 05/11/2012 08:49 AM, Will Deacon wrote: I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that way. I tried the same (make omap2plus_defconfig and enabled the above option), and I do see the interrupts firing on both 4430 and 4460... / # cat /proc/interrupts CPU0 CPU1 29: 1023404 GIC twd 33:401 0 GIC arm-pmu 34: 0441 GIC arm-pmu Well, at least it's working for somebody! What is your kernel commit ID that you applied the patches on top of? 7cf543bc (Linux-omap rebuilt: Updated to -rc6, merged in pending branches, please test). Is there something else I need too? What board are you using? Blaze, panda, etc, and is it 4430 or 4460? Ye olde Panda 4430. It does work with my perf/omap4 branch though using the same .config (I can mail it to you separately if you want). Cheers, Will -- 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 1/10] omap non-critical fixes for v3.5 merge window
* Olof Johansson o...@lixom.net [120511 00:25]: Tony, I've pulled all 10 requests. Many of them ended up going into the same next/ branch, but that's quite OK. Please double check my merge conflict resolutions. One nit is that at least one of the branches had a few varying patch subjects, so just a friendly reminder to sanitize them to ARM: OMAP.*: or so when you apply patches. Oops, sorry looks like I missed some of them. Usually I do fix those up though, and had my scripts do that automatically when applying from k.o patchwork earlier. I'll add some checks to my scripts applying from mbox format too. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 1/10] omap non-critical fixes for v3.5 merge window
* Olof Johansson o...@lixom.net [120511 01:41]: On Fri, May 11, 2012 at 1:33 AM, Paul Walmsley p...@pwsan.com wrote: Hello Olof, On Fri, 11 May 2012, Olof Johansson wrote: I did notice that omap2plus_defconfig has grown a new warning caused by ARM: OMAP2+: clean up some cppcheck warnings (oh, the irony!): arch/arm/plat-omap/usb.c: In function 'omap_otg_init': arch/arm/plat-omap/usb.c:40:6: warning: unused variable 'status' [-Wunused-variable] Thanks, this has been fixed by: http://marc.info/?l=linux-omapm=133660322929805w=2 Sounds good, I'll wait for it to trickle in on a future pull request. Thanks I'll see if there's some other fixes still needed and send a pull request today. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
On Thu, 2012-05-10 at 19:45 +0200, Ivan Djelic wrote: On Thu, May 10, 2012 at 04:52:18PM +0100, Artem Bityutskiy wrote: On Thu, 2012-05-10 at 17:17 +0200, Ivan Djelic wrote: But in order to do so, I need the changes that Afzal has submitted (in particular [3]). Those changes (and as a consequence, my new patch) won't hit 3.5. So, when Afzal's patches are pushed, I'll submit a new, single MTD patch. But this is not going to happen this merge window as I understood, may be not even the next one. We need to make UBIFS happy sooner than that, I think. So may be we go forward with your original patch? I'm OK with this too, as the patches are ready and tested. The MTD patch is [2], it depends on [1] which has been pushed, then dropped by Tony. Do you need me to repost [2] ? Tony, sorry to backpedal on this: would you re-push patch [1], if indeed Afzal's patches are not going to be merged soon ? In the meantime, I can prepare a patch on top of Afzal's to have a smooth transition w.r.t BCH support. What do you think ? OK, since we now have Tony's ack - I have applied both patches to l2-mtd.git. Thanks. I have a question though - will send separately. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
[PATCH 0/3] Handle GPMC-NAND registers by NAND driver
Hi, This series provides the ability for OMAP NAND driver to configure GPMC_NAND registers by NAND driver itself instead of using GPMC exported symbols. Regards Afzal Afzal Mohammed (3): ARM: OMAP2+: gpmc: update nand register helper ARM: OMAP2+: gpmc-nand: update gpmc-nand regs mtd: nand: omap2: handle nand on gpmc arch/arm/mach-omap2/gpmc-nand.c|2 + arch/arm/mach-omap2/gpmc.c | 21 arch/arm/plat-omap/include/plat/gpmc.h | 18 +++ arch/arm/plat-omap/include/plat/nand.h |1 + drivers/mtd/nand/omap2.c | 207 +--- 5 files changed, 205 insertions(+), 44 deletions(-) -- 1.7.10 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: OMAP2+: gpmc: update nand register helper
Provide helper function for updating NAND register details for
the necessary chip select. NAND drivers platform data can be
updated with this information so that NAND driver can handle
GPMC NAND operations by itself.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 21 +
arch/arm/plat-omap/include/plat/gpmc.h | 18 ++
2 files changed, 39 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 46b09da..a409a3e 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -49,6 +49,7 @@
#define GPMC_ECC_CONTROL 0x1f8
#define GPMC_ECC_SIZE_CONFIG 0x1fc
#define GPMC_ECC1_RESULT0x200
+#define GPMC_ECC_BCH_RESULT_0 0x240
/* GPMC ECC control settings */
#define GPMC_ECC_CTRL_ECCCLEAR 0x100
@@ -681,6 +682,26 @@ int gpmc_prefetch_reset(int cs)
}
EXPORT_SYMBOL(gpmc_prefetch_reset);
+void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs)
+{
+ reg-gpmc_status = gpmc_base + GPMC_STATUS;
+ reg-gpmc_nand_command = gpmc_base + GPMC_CS0_OFFSET +
+ GPMC_CS_NAND_COMMAND + GPMC_CS_SIZE * cs;
+ reg-gpmc_nand_address = gpmc_base + GPMC_CS0_OFFSET +
+ GPMC_CS_NAND_ADDRESS + GPMC_CS_SIZE * cs;
+ reg-gpmc_nand_data = gpmc_base + GPMC_CS0_OFFSET +
+ GPMC_CS_NAND_DATA + GPMC_CS_SIZE * cs;
+ reg-gpmc_prefetch_config1 = gpmc_base + GPMC_PREFETCH_CONFIG1;
+ reg-gpmc_prefetch_config2 = gpmc_base + GPMC_PREFETCH_CONFIG2;
+ reg-gpmc_prefetch_control = gpmc_base + GPMC_PREFETCH_CONTROL;
+ reg-gpmc_prefetch_status = gpmc_base + GPMC_PREFETCH_STATUS;
+ reg-gpmc_ecc_config = gpmc_base + GPMC_ECC_CONFIG;
+ reg-gpmc_ecc_control = gpmc_base + GPMC_ECC_CONTROL;
+ reg-gpmc_ecc_size_config = gpmc_base + GPMC_ECC_SIZE_CONFIG;
+ reg-gpmc_ecc1_result = gpmc_base + GPMC_ECC1_RESULT;
+ reg-gpmc_bch_result0 = gpmc_base + GPMC_ECC_BCH_RESULT_0;
+}
+
static void __init gpmc_mem_init(void)
{
int cs;
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 1527929..6a8078e 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -131,6 +131,24 @@ struct gpmc_timings {
u16 wr_data_mux_bus;/* WRDATAONADMUXBUS */
};
+struct gpmc_nand_regs {
+ void __iomem*gpmc_status;
+ void __iomem*gpmc_nand_command;
+ void __iomem*gpmc_nand_address;
+ void __iomem*gpmc_nand_data;
+ void __iomem*gpmc_prefetch_config1;
+ void __iomem*gpmc_prefetch_config2;
+ void __iomem*gpmc_prefetch_control;
+ void __iomem*gpmc_prefetch_status;
+ void __iomem*gpmc_ecc_config;
+ void __iomem*gpmc_ecc_control;
+ void __iomem*gpmc_ecc_size_config;
+ void __iomem*gpmc_ecc1_result;
+ void __iomem*gpmc_bch_result0;
+};
+
+extern void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs);
+
extern unsigned int gpmc_ns_to_ticks(unsigned int time_ns);
extern unsigned int gpmc_ps_to_ticks(unsigned int time_ps);
extern unsigned int gpmc_ticks_to_ns(unsigned int ticks);
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: OMAP2+: gpmc-nand: update gpmc-nand regs
GPMC has NAND registers, update nand platform data with those details
so that NAND driver can configure those by itself instead of using
exported symbols.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c|2 ++
arch/arm/plat-omap/include/plat/nand.h |1 +
2 files changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 386dec8..d4e803c 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -108,6 +108,8 @@ int __init gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data)
gpmc_cs_configure(gpmc_nand_data-cs, GPMC_CONFIG_RDY_BSY, 1);
}
+ gpmc_update_nand_reg(gpmc_nand_data-reg, gpmc_nand_data-cs);
+
err = platform_device_register(gpmc_nand_device);
if (err 0) {
dev_err(dev, Unable to register NAND device\n);
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 67fc506..86e4d9c 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -29,6 +29,7 @@ struct omap_nand_platform_data {
unsigned long phys_base;
int devsize;
enum omap_ecc ecc_opt;
+ struct gpmc_nand_regs reg;
};
/* minimum size for IO mapping */
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] mtd: nand: omap2: handle nand on gpmc
GPMC driver has been modified to fill NAND platform data with GPMC
NAND register details. As these registers are accessible in NAND
driver itself, configure NAND in GPMC by itself.
Modified prefetch and ecc functions are logically same as the
corresponding exported symbols from GPMC code.
Note: Verfying that other CS have not yet enabled for prefetch ecc
has to be incorporated. Currently this causes no issues as there are
no boards that use NAND on multiple CS. With ongoing GPMC driver
migration, perhaps it would be better to consider NAND connected on
multiple CS as a single peripheral using multiple CS. This would
make handling multiple CS issues easier.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/mtd/nand/omap2.c | 207 --
1 file changed, 163 insertions(+), 44 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index c2b0bba..25f930c 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -95,6 +95,16 @@
#define P4e_s(a) (TF(a NAND_Ecc_P4e)0)
#define P4o_s(a) (TF(a NAND_Ecc_P4o)1)
+#definePREFETCH_CONFIG1_CS_SHIFT 24
+#defineECC_CONFIG_CS_SHIFT 1
+#defineCS_MASK 0x7
+#defineENABLE_PREFETCH (0x1 7)
+#defineDMA_MPU_MODE_SHIFT 2
+#defineECCSIZE1_SHIFT 22
+#defineECC1RESULTSIZE 0x1
+#defineECCCLEAR0x100
+#defineECC10x1
+
/* oob info generated runtime depending on ecc algorithm and layout selected */
static struct nand_ecclayout omap_oobinfo;
/* Define some generic bad / good block scan pattern which are used
@@ -127,9 +137,70 @@ struct omap_nand_info {
} iomode;
u_char *buf;
int buf_len;
+ struct gpmc_nand_regs reg;
};
/**
+ * omap_prefetch_enable - configures and starts prefetch transfer
+ * @cs: cs (chip select) number
+ * @fifo_th: fifo threshold to be used for read/ write
+ * @dma_mode: dma mode enable (1) or disable (0)
+ * @u32_count: number of bytes to be transferred
+ * @is_write: prefetch read(0) or write post(1) mode
+ */
+static int omap_prefetch_enable(int cs, int fifo_th, int dma_mode,
+ unsigned int u32_count, int is_write, struct omap_nand_info *info)
+{
+ u32 val;
+
+ if (fifo_th PREFETCH_FIFOTHRESHOLD_MAX) {
+ pr_err(gpmc: fifo threshold is not supported\n);
+ return -1;
+ } else if (!(readl(info-reg.gpmc_prefetch_control))) {
+ /* Set the amount of bytes to be prefetched */
+ writel(u32_count, info-reg.gpmc_prefetch_config2);
+
+ /* Set dma/mpu mode, the prefetch read / post write and
+* enable the engine. Set which cs is has requested for.
+*/
+ val = ((cs PREFETCH_CONFIG1_CS_SHIFT) |
+ PREFETCH_FIFOTHRESHOLD(fifo_th) |
+ ENABLE_PREFETCH |
+ (dma_mode DMA_MPU_MODE_SHIFT) |
+ (0x1 is_write));
+ writel(val, info-reg.gpmc_prefetch_config1);
+
+ /* Start the prefetch engine */
+ writel(0x1, info-reg.gpmc_prefetch_control);
+ } else {
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
+/**
+ * omap_prefetch_reset - disables and stops the prefetch engine
+ */
+static int omap_prefetch_reset(int cs, struct omap_nand_info *info)
+{
+ u32 config1;
+
+ /* check if the same module/cs is trying to reset */
+ config1 = readl(info-reg.gpmc_prefetch_config1);
+ if (((config1 PREFETCH_CONFIG1_CS_SHIFT) CS_MASK) != cs)
+ return -EINVAL;
+
+ /* Stop the PFPW engine */
+ writel(0x0, info-reg.gpmc_prefetch_control);
+
+ /* Reset/disable the PFPW engine */
+ writel(0x0, info-reg.gpmc_prefetch_config1);
+
+ return 0;
+}
+
+/**
* omap_hwcontrol - hardware specific access to control-lines
* @mtd: MTD device structure
* @cmd: command to device
@@ -147,13 +218,13 @@ static void omap_hwcontrol(struct mtd_info *mtd, int cmd,
unsigned int ctrl)
if (cmd != NAND_CMD_NONE) {
if (ctrl NAND_CLE)
- gpmc_nand_write(info-gpmc_cs, GPMC_NAND_COMMAND, cmd);
+ writeb(cmd, info-reg.gpmc_nand_command);
else if (ctrl NAND_ALE)
- gpmc_nand_write(info-gpmc_cs, GPMC_NAND_ADDRESS, cmd);
+ writeb(cmd, info-reg.gpmc_nand_address);
else /* NAND_NCE */
- gpmc_nand_write(info-gpmc_cs, GPMC_NAND_DATA, cmd);
+ writeb(cmd,
RE: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
Hi Ivan, On Thu, May 10, 2012 at 23:15:27, Ivan Djelic wrote: So, when Afzal's patches are pushed, I'll submit a new, single MTD patch. But this is not going to happen this merge window as I understood, may be not even the next one. We need to make UBIFS happy sooner than that, I think. So may be we go forward with your original patch? I'm OK with this too, as the patches are ready and tested. The MTD patch is [2], it depends on [1] which has been pushed, then dropped by Tony. Do you need me to repost [2] ? Tony, sorry to backpedal on this: would you re-push patch [1], if indeed Afzal's patches are not going to be merged soon ? In the meantime, I can prepare a patch on top of Afzal's to have a smooth transition w.r.t BCH support. What do you think ? A new series [A-D] has been sent for handling GPMC NAND registers by NAND driver itself. This is being targeted for 3.5. Hopefully if every one is in agreement, we can avoid patching for BCH support again when GPMC driver migration happens. And the effect of GPMC driver migration on NAND driver can be reduced when it happens. Can you try a patch on top of this series checks if it works for you, if more is required from my side let me know. Regards Afzal [A] http://marc.info/?l=linux-omapm=133675113218509w=2 [B] http://marc.info/?l=linux-omapm=133675123118577w=2 [C] http://marc.info/?l=linux-omapm=133675123718579w=2 [D] http://marc.info/?l=linux-omapm=133675124818580w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Will, On 05/11/2012 10:02 AM, Will Deacon wrote: On Fri, May 11, 2012 at 03:52:59PM +0100, Jon Hunter wrote: Hi Will, Hello, On 05/11/2012 08:49 AM, Will Deacon wrote: I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that way. I tried the same (make omap2plus_defconfig and enabled the above option), and I do see the interrupts firing on both 4430 and 4460... / # cat /proc/interrupts CPU0 CPU1 29: 1023404 GIC twd 33:401 0 GIC arm-pmu 34: 0441 GIC arm-pmu Well, at least it's working for somebody! What is your kernel commit ID that you applied the patches on top of? 7cf543bc (Linux-omap rebuilt: Updated to -rc6, merged in pending branches, please test). Is there something else I need too? Ok, thanks. I was based upon Tony's -rc5. However, I rebased to the same as you and it is still working for me Can you send me your .config? At the same time, maybe just try make omap2plus_defconfig and enable the OMAP3 debug devices config. That's all I am doing. What board are you using? Blaze, panda, etc, and is it 4430 or 4460? Ye olde Panda 4430. It does work with my perf/omap4 branch though using the same .config (I can mail it to you separately if you want). Ok, should be fine. The kernel should print the ES version on start-up ... [0.00] OMAP4430 ES2.2 What does yours show? Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Fri, May 11, 2012 at 05:31:47PM +0100, Jon Hunter wrote: Can you send me your .config? Sent off-list. At the same time, maybe just try make omap2plus_defconfig and enable the OMAP3 debug devices config. That's all I am doing. Excellent, that works for me. Once we've worked out the problem with my .config you can have my tested-by. Cheers, Will -- 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: OMAP1: USB: fix ocpi_enable compile problem on non-1610 builds
* Paul Walmsley p...@pwsan.com [120510 15:31]: Janusz Krzysztofik reported the following build break on OMAP1 builds that don't include CONFIG_ARCH_OMAP16XX: LD .tmp_vmlinux1 arch/arm/mach-omap1/built-in.o: In function `omap1_usb_init': lcd_dma.c:(.init.text+0x1420): undefined reference to `ocpi_enable' make: *** [.tmp_vmlinux1] Error 1 This was caused by commit d3645d39ad0ed9f09535065676ea0ba114f93cdf (ARM: OMAP1: OHCI: use platform_data fn ptr to enable OCPI bus). Fix by declaring an empty ocpi_enable() on non-16XX builds, which should work until the OCPI code is moved out to drivers/. Thanks applying into fixes-for-cleanup branch. 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: OMAP: OTG integration: fix compiler warning
* Paul Walmsley p...@pwsan.com [120509 15:41]: Tony reported the following compile warning after commit eeb3711b89d68e147e05e7b43a49ecc5009dc157 (ARM: OMAP2+: clean up some cppcheck warnings): arch/arm/plat-omap/usb.c: In function 'omap_otg_init': arch/arm/plat-omap/usb.c:40: warning: unused variable 'status' This happens if CONFIG_ARCH_OMAP_OTG is set but CONFIG_USB_GADGET_OMAP, CONFIG_USB_OHCI_HCD, CONFIG_USB_OHCI_HCD_MODULE, and CONFIG_USB_OTG are all unset. Fix by localizing the status variable to the blocks that use it. Compile-tested only, with omap2plus_defconfig and omap2plus_defconfig with CONFIG_USB_OHCI_HCD and CONFIG_USB_OTG enabled. Thanks applying into fixes-for-cleanup branch. 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] gpio/omap: fix incorrect initialization of omap_gpio_mod_init
On Thu, 10 May 2012 07:23:56 -0700, Kevin Hilman khil...@ti.com wrote: Grant, DebBarma, Tarun Kanti tarun.ka...@ti.com writes: Hi, On Thu, May 10, 2012 at 3:06 AM, Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: On Mon, 7 May 2012 10:52:28 DebBarma, Tarun Kanti wrote: On Sun, May 6, 2012 at 3:25 AM, Grazvydas Ignotas nota...@gmail.com wrote: On Mon, Apr 30, 2012 at 10:20 AM, Tarun Kanti DebBarma tarun.ka...@ti.com wrote: Initialization of irqenable, irqstatus registers is the common operation done in this function for all OMAP platforms, viz. OMAP1, OMAP2+. The latter _gpio_rmw()'s which supposedly got introduced wrongly to take care of OMAP2+ platforms were overwriting initially programmed OMAP1 value breaking functionality on OMAP1. Hi, I can confirm that my other issues with GPIO on Amstrad Delta were not related, and this patch is still required for GPIO interrupts hardware being correctly initialized on OMAP1 in 3.4-rc6. You can add my Tested-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl if you wish. Thank you for confirming!! We'd like to get this one in for v3.4-rc. Can you queue it? I added the tested-by from Janusz and my signoff, and pull request is below. Pulled, thanks. I'll send a pull req out to Linus today. 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] gpio/omap: fix incorrect initialization of omap_gpio_mod_init
On Mon, 7 May 2012 10:52:28 +0530, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote: Hi, On Sun, May 6, 2012 at 3:25 AM, Grazvydas Ignotas nota...@gmail.com wrote: I've noticed that current mainline enables _all_ possible GPIO interrupts, this patch fixes that problem. OK, thanks. Also Grant doesn't seem to be on CC so might not be able to pick this up. I have added Cc: in the patch and was expecting that would take care. Looks like that has not happened. Anyways, I have explicitly added in the email. I'm particularly bursty when it comes to patch review and applying. Sometimes it takes me a while to find time for maintainership work. 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] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
On 05/10/2012 11:27 AM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [120510 10:09]:
On 05/09/2012 02:49 PM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [120509 13:22]:
On 05/04/2012 04:08 PM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [120504 11:59]:
On 05/04/2012 10:34 AM, Tony Lindgren wrote:
* Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com [120504
08:58]:
On 08:03 Fri 04 May , Tony Lindgren wrote:
so I was thinking to do like on gpio
uart {
pin = pioA 12 {pararms}
}
Hmm I assume the 12 above the gpio number?
no pin number in the bank because it could not be gpio
Yes OK, but pin number 12 in the gpio bank, not in the mux register.
Got it.
I'd prefer to avoid any references to GPIOs here; not all muxable pins
are GPIOs and not all GPIOs are muxable pins. Lets keep the two concepts
independent.
And it seems that pioA 12 is not always enough information for the
pinctrl
driver to request a GPIO. So it's best to specify it separately.
Why would a pinctrl driver request a GPIO?
Hmm what would pinctrl_request_gpio do if the GPIO driver is separate
driver?
Well, that's a GPIO driver requesting a GPIO from the pinctrl system,
rather than the pinctrl driver requesting a GPIO (sorry to be picky).
Oh sorry maybe I misunderstood what pinctrl_request_gpio is doing.
Seems like that should work the same way from binding point of view.
It wasn't at all obvious to me from your binding proposal that you
intended the pinctrl-simple driver to support the GPIO operations at
all. If you do want this, I think you'd need some properties (perhaps
some kind of explicit table) in order to set up the GPIO ID - pinctrl
pin ID mapping. I don't recall seeing those; did I just miss them? I
think we'd want this to be explicit because:
a) It may well be the case that not all users of pinctrl-simple actually
mux/control GPIOs at all. It's certainly possible to only mux special
functions, and have dedicated pins for a GPIO controller.
b) Even when GPIOs do come into the picture, it may be that only some of
the pins are available as GPIOs.
Right, we need some pinctrl to gpio mapping eventually. That comes
automatically from DT for the pins and gpios we care about.
And that's why the binding needs to be flexible enough so we can add
optional pin specific options as needed in addition to parsing a larger
set of pins with no options.
The mapping of GPIO to pinctrl pins would presumably be driven solely by
the HW design of the pin controller and GPIO, and not by the mux
selection in the pin controller (otherwise, I'd argue this isn't a
simple case that should be handled by pinctrl-simple).
As such, I'd expect some properties/table at the top-level of the pin
controller object to describe the GPIO mapping. In turn, that implies
that the individual per-pin mux-selection/configuration nodes don't need
to describe any GPIO-related information.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 00/16] [FS, MM, block, MMC]: eMMC High Priority Interrupt Feature
On Wed, May 9, 2012 at 6:15 AM, Minchan Kim minc...@kernel.org wrote: On 05/09/2012 01:31 AM, S, Venkatraman wrote: On Tue, May 8, 2012 at 1:16 PM, Minchan Kim minc...@kernel.org wrote: On 05/03/2012 11:22 PM, Venkatraman S wrote: Standard eMMC (Embedded MultiMedia Card) specification expects to execute one request at a time. If some requests are more important than others, they can't be aborted while the flash procedure is in progress. New versions of the eMMC standard (4.41 and above) specfies a feature called High Priority Interrupt (HPI). This enables an ongoing transaction to be aborted using a special command (HPI command) so that the card is ready to receive new commands immediately. Then the new request can be submitted to the card, and optionally the interrupted command can be resumed again. Some restrictions exist on when and how the command can be used. For example, only write and write-like commands (ERASE) can be preempted, and the urgent request must be a read. In order to support this in software, a) At the top level, some policy decisions have to be made on what is worth preempting for. This implementation uses the demand paging requests and swap read requests as potential reads worth preempting an ongoing long write. This is expected to provide improved responsiveness for smarphones with multitasking capabilities - example would be launch a email application while a video capture session (which causes long writes) is ongoing. Do you have a number to prove it's really big effective? What type of benchmarks would be appropriate to post ? As you know, the response time of a card would vary depending on whether the flash device has enough empty blocks to write into and doesn't have to resort to GC during write requests. Macro benchmarks like iozone etc would be inappropriate here, as they won't show the latency effects of individual write requests hung up doing page reclaim, which happens once in a while. We don't have such special benchmark so you need time to think how to prove it. IMHO, you can use run-many-x-apps.sh which checks elapsed time to activate programs by posting by Wu long time ago. http://www.spinics.net/lists/linux-mm/msg09653.html Of course, your eMMC is used above 80~90% for triggering GC stress and your memory should be used up by dirty pages to happen reclaim. What I have a concern is when we got low memory situation. Then, writing speed for page reclaim is important for response. If we allow read preempt write and write is delay, it means read path takes longer time to get a empty buffer pages in reclaim. In such case, it couldn't be good. I agree. But when writes are delayed anyway as it exceeds hpi_time_threshold (the window available for invoking HPI), it means that the device is in GC mode and either read or write could be equally delayed. Note that even in case of interrupting a write, a single block write (which usually is too short to be interrupted, as designed) is sufficient for doing a page reclaim, and further write requests (including multiblock) would not be subject to HPI, as they will complete within the average time. My point is that it would be better for read to not preempt write-for-page_reclaim. And we can identify it by PG_reclaim. You can get the idea. Anyway, HPI is only feature of a device of many storages and you are requiring modification of generic layers although it's not big. So for getting justification and attracting many core guys(MM,FS,BLOCK), you should provide data at least. Hi Kim, Apologies for a delayed response. I am studying your suggestions and will get back with some changes and also some profiling data. Regards, Venkat. -- 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] few omap fixups for v3.5 merge window
Hi Arnd Olof, Here are the fixes needed for the regressions caused by omap-cleanup-sparse-for-v3.5. I suggest pulling this into arm-soc/omap/cleanup-sparse where the issues got introduced. Regards, Tony The following changes since commit 09f45b83109cb8e23a06d5efb1096a08a9545974: Merge tag 'omap-cleanup-a2-for-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into cleanup-sparse (2012-04-18 10:09:26 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes-for-cleanup for you to fetch changes up to 19b08b33fa4c60d66d4e341d4d1d9a6e86ffc9e6: ARM: OMAP: OTG integration: fix compiler warning (2012-05-11 09:56:43 -0700) Turns out the earlier omap-cleanup-sparse-for-v3.5 up introduced one compile issue and a new warning. Paul Walmsley (2): ARM: OMAP1: USB: fix ocpi_enable compile problem on non-1610 builds ARM: OMAP: OTG integration: fix compiler warning arch/arm/mach-omap1/common.h |4 arch/arm/plat-omap/usb.c |4 +++- 2 files changed, 7 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On 05/10/2012 01:59 PM, Jassi Brar wrote:
On 10 May 2012 22:30, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/09/2012 03:38 PM, Jassi Brar wrote:
One point is about 'qos' here something like bandwidth allocation.
If the dmac driver knew up-front the max possible clients that could be
active simultaneously, it could divide the bandwidth accordingly.
Again, the example of PL330 employing 2physical channels for better
service - LLI (you got it right), where even 1 physical channel would
also have served only not as reliably. I believe there would be
more such scenarios.
QoS seems like policy to me, whereas DT is more about describing the HW.
Is DT the correct place to describe QoS policy?
I guess you are talking more about deriving policy from the description
of HW, i.e. how many client described in DT.
Yeah, that's what I meant.
However, for some reason that seems dangerous to me; what if clients
can be instantiated some other way?
The other way could be hotplug ?
Yes. Also, there's probably some mix of DT-driven and non-DT-driven
instantiation during the transition to DT, although that's probably
temporary.
Anyway in those machines every channel would be populated
and dmac driver would always account for the all-ports-plugged case.
For a 1:1 mapping (or 1:n mapping in HW with static selection specified
in the DT) between DMA client and DMA controller, perhaps the controller
can indeed make QoS decisions based on which (how many) clients are
connected to it.
However, if a DMA client can be serviced by more than 1 DMA engine, and
the decision as to which DMA engine to use occurs at run-time by the DMA
driver core, rather than being statically configured in the DT, then the
DMA controller drivers cannot know ahead of time which will be used
I think the dmac driver would make use of the routing flexibility to sustain
its
'qos', and not the other way around (decide qos based on which one of the
two dmacs would provide a channel to a client in future).
Anyways, so far only Samsung SoCs seem to have that flexibility/redundancy
and I have never had anyone asking for that runtime decision making.
The minor difference being, you use the {request-signal, phandle} pair
to find the right channel, I used only 'token'.
That's a pretty big difference, I think.
In your proposal, every token was globally unique (well, within the 1 DT
file). I'd rather not see any more global numbering schemes.
Probably my shallow experience, but globally unique, within a file sounds
like an oxymoron :)
To the kernel, that one file describes everything it knows about the HW
(except for probed information), so it's global:-) Aside from that, I've
often seen the term global used relative to some specific scope.
I think arbitrary numerical tokens are a reasonable price to pay for the
robustness and simplicity they bring.
I have to disagree here.
Using phandle+ID is almost as simple, and much more flexible. Global IDs
have a number of disadvantages:
a) You have to somehow keep them unique. Even with just a single .dts
file, that's going to be a little painful since there's no central table
of these IDs.
What if the DT is composed of a bunch of chunks that represent pluggable
boards, which may be mixed/matched together depending on what the user
actually plugged in? Then, you have to be very careful to keep the n
different files' numbering ranges segregated, or conflicts will occur.
b) Everything else in DT already uses phandle+ID, so doing the same
thing would be much more familiar and consistent for DT users.
Now, DMA requests are signals /from/ a DMA client to a DMA controller
(send more data please, or pull more data please). Hence, I assert
that the phandle should refer to the DMA client, not the DMA controller.
OK, though we may just want to convey information about the h/w setup
from the s/w POV, rather than info to simulate the h/w ;)
DT is specifically about describing the HW from a HW perspective.
For ex, the dma api and controller drivers don't really care about
the fact that the client's driver must set some bit to trigger operation,
whereas some simulator would need to care about that.
Anyways, I am OK with whatever works well and make things simpler.
Also note that, a client's dma specifier becomes perfectly general
and future-proof
client1: spdif {
dma_tx = 278
dma_rx = 723
};
otherwise the following representation
client1: spdif {
dma = sdma 2 1 sdma 3 2;
};
could break with some weird dma setups (IIANW Russell already finds
it wouldn't work for him).
To solve Russell's HW, we need some way of representing the mux directly
in DT irrespective of how the DMA controller or DMA client specify what
they're connected to. Anything else isn't representing the HW in DT.
Also, who knows how to control the mux? We need that to be fully
general, and so the mux itself really
Re: [PATCH] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
* Stephen Warren swar...@wwwdotorg.org [120511 12:21]: The mapping of GPIO to pinctrl pins would presumably be driven solely by the HW design of the pin controller and GPIO, and not by the mux selection in the pin controller (otherwise, I'd argue this isn't a simple case that should be handled by pinctrl-simple). As such, I'd expect some properties/table at the top-level of the pin controller object to describe the GPIO mapping. In turn, that implies that the individual per-pin mux-selection/configuration nodes don't need to describe any GPIO-related information. Yes good point. I agree it's a HW design issue, and could be in the properties for the pin controller object. Just to summarize, the things to consider with the GPIO to mux mapping are: 1. Having this table as static data in the driver is is not a nice solution as it seems that we'd currently need six mapping tables for omap2+ alone. 2. This table is not needed for most of the (hundreds of) pins, it's only needed for a few selected pins, let's say ten or so on an average device. So there's no need to stuff the kernel with information about the unused GPIO pins. It seems that the conclusion here is that we don't need to worry about GPIOs in the pinctrl-simple binding for now, and it can be added later without having to change the basic binding. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP2+: Add AM335x and AM3517/05 EVM DT support
Hi, * Cousson, Benoit b-cous...@ti.com [120511 05:51]: Hi Tony, Here are some remaining DT patches I was not able to push at 3.4 due to some missing dependency. It applies now fine on top of lo/dt branch. It seems that there are still patches being discussed for those SoCs and we're pretty much done for this merge window. So unless things drag on to -rc8, I'd say we just need to postpone merging new things and merge them early around -rc2. Regards, Tony Regards, Benoit The following changes since commit 40364b9f5a4d167d97bb6a76cd239ca8cfff056a: Benoit Cousson (1): arm/dts: omap4-panda: Add LEDs support are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.5/dts/am33xx Vaibhav Hiremath (3): arm/dts: Add support for TI AM335x EVM board arm/dts: omap3-evm: Add i2c and twl4030 support arm/dts: Add support for TI AM3517/05 EVM board arch/arm/boot/dts/am335x-evm.dts | 39 ++ arch/arm/boot/dts/am3517-evm.dts | 32 +++ arch/arm/boot/dts/omap3-evm.dts | 28 +++ 3 files changed, 99 insertions(+), 0 deletions(-) create mode 100644 arch/arm/boot/dts/am335x-evm.dts create mode 100644 arch/arm/boot/dts/am3517-evm.dts -- 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-alt 0/6] GPMC driver migrate one
* Mohammed, Afzal af...@ti.com [120509 23:39]: Hi Tony, On Wed, May 09, 2012 at 03:06:26, Tony Lindgren wrote: To resolve this and as per your earlier question on whether old along with new interface can be made to work parallely, here is suggestion from my end to deal with it. I think this is the only way to keep this all building and booting for each patch in the series, no? If so, then we should select this option. The first patch should be broken up into more readable patches, it seems that you can do that without breaking things. Bisectability has been maintained in the patches. Ok, I will proceed by keeping old new interface together, will try to achieve it in smaller patches and without hacks. Please let me know whether you are fine in taking patch series as in v4 (that converts all boards at once, with further revisions based on review comments). It seems that there are still some pending comments and we need to have the hwmod entries merged first by Paul. Ok, first I will try to get hwmod in. Let's try to get merged these into l-o master around -rc2 so we can have them tested properly for a few weeks before v3.6 merge window. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP2+: gpmc: update nand register helper
* Afzal Mohammed af...@ti.com [120511 08:48]:
Provide helper function for updating NAND register details for
the necessary chip select. NAND drivers platform data can be
updated with this information so that NAND driver can handle
GPMC NAND operations by itself.
Hmm this seems that it might be a more future proof path.
Tony
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 21 +
arch/arm/plat-omap/include/plat/gpmc.h | 18 ++
2 files changed, 39 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 46b09da..a409a3e 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -49,6 +49,7 @@
#define GPMC_ECC_CONTROL 0x1f8
#define GPMC_ECC_SIZE_CONFIG 0x1fc
#define GPMC_ECC1_RESULT0x200
+#define GPMC_ECC_BCH_RESULT_00x240
/* GPMC ECC control settings */
#define GPMC_ECC_CTRL_ECCCLEAR 0x100
@@ -681,6 +682,26 @@ int gpmc_prefetch_reset(int cs)
}
EXPORT_SYMBOL(gpmc_prefetch_reset);
+void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs)
+{
+ reg-gpmc_status = gpmc_base + GPMC_STATUS;
+ reg-gpmc_nand_command = gpmc_base + GPMC_CS0_OFFSET +
+ GPMC_CS_NAND_COMMAND + GPMC_CS_SIZE * cs;
+ reg-gpmc_nand_address = gpmc_base + GPMC_CS0_OFFSET +
+ GPMC_CS_NAND_ADDRESS + GPMC_CS_SIZE * cs;
+ reg-gpmc_nand_data = gpmc_base + GPMC_CS0_OFFSET +
+ GPMC_CS_NAND_DATA + GPMC_CS_SIZE * cs;
+ reg-gpmc_prefetch_config1 = gpmc_base + GPMC_PREFETCH_CONFIG1;
+ reg-gpmc_prefetch_config2 = gpmc_base + GPMC_PREFETCH_CONFIG2;
+ reg-gpmc_prefetch_control = gpmc_base + GPMC_PREFETCH_CONTROL;
+ reg-gpmc_prefetch_status = gpmc_base + GPMC_PREFETCH_STATUS;
+ reg-gpmc_ecc_config = gpmc_base + GPMC_ECC_CONFIG;
+ reg-gpmc_ecc_control = gpmc_base + GPMC_ECC_CONTROL;
+ reg-gpmc_ecc_size_config = gpmc_base + GPMC_ECC_SIZE_CONFIG;
+ reg-gpmc_ecc1_result = gpmc_base + GPMC_ECC1_RESULT;
+ reg-gpmc_bch_result0 = gpmc_base + GPMC_ECC_BCH_RESULT_0;
+}
+
static void __init gpmc_mem_init(void)
{
int cs;
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 1527929..6a8078e 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -131,6 +131,24 @@ struct gpmc_timings {
u16 wr_data_mux_bus;/* WRDATAONADMUXBUS */
};
+struct gpmc_nand_regs {
+ void __iomem*gpmc_status;
+ void __iomem*gpmc_nand_command;
+ void __iomem*gpmc_nand_address;
+ void __iomem*gpmc_nand_data;
+ void __iomem*gpmc_prefetch_config1;
+ void __iomem*gpmc_prefetch_config2;
+ void __iomem*gpmc_prefetch_control;
+ void __iomem*gpmc_prefetch_status;
+ void __iomem*gpmc_ecc_config;
+ void __iomem*gpmc_ecc_control;
+ void __iomem*gpmc_ecc_size_config;
+ void __iomem*gpmc_ecc1_result;
+ void __iomem*gpmc_bch_result0;
+};
+
+extern void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs);
+
extern unsigned int gpmc_ns_to_ticks(unsigned int time_ns);
extern unsigned int gpmc_ps_to_ticks(unsigned int time_ps);
extern unsigned int gpmc_ticks_to_ns(unsigned int ticks);
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/13] ARM: OMAP5: Add minimal OMAP5 SOC support
Hi, * Sricharan R r.sricha...@ti.com [120510 10:47]: Hi Tony, -Original Message- From: R Sricharan [mailto:r.sricha...@ti.com] Sent: Thursday, May 03, 2012 12:56 PM To: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org; santosh.shilim...@ti.com; t...@atomide.com; b-cous...@ti.com; r.sricha...@ti.com Subject: [PATCH 00/13] ARM: OMAP5: Add minimal OMAP5 SOC support The series adds minimal OMAP5 support. OMAP5430 has a dual core Cortex-A15 based MPU subsystem with 2MB L2 cache. The SOC has many compatible blocks with OMAP4 SOCS and hence large part of the peripherals are re-used. OMAP5432 is another variant of OMAP5430, with a memory controller supporting DDR3 and SATA. OMAP5 V2 series is ready with all comments addressed, but I have below dependencies to be merged to apply my series against your cleanup-soc branch OK 1) git://git.pwsan.com/linux-2.6 hwmod_soc_conditional_cleanup_3.5 This one is not merged in yet and it seems that we're out of time for v3.5 unless it drags on and we have -rc8 after -rc7. 2) git://git.pwsan.com/linux-2.6 hwmod_data_cleanup_3.5 3) https://github.com/hvaibhav/am335x-linux 32ksync-timer-cleanup These two are merged in arm-soc now. 4) http://www.spinics.net/lists/arm-kernel/msg174461.html I think this series still has some pending comments? Can you please let me know how you want me to prepare the series with these dependencies. Until these dependencies get cleared out, it seems that the best branch to base your patches is omap-cleanup-timer-for-v3.5 tag and just carry the pending patches for a little bit longer. 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] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
On 05/11/2012 01:51 PM, Tony Lindgren wrote: * Stephen Warren swar...@wwwdotorg.org [120511 12:21]: The mapping of GPIO to pinctrl pins would presumably be driven solely by the HW design of the pin controller and GPIO, and not by the mux selection in the pin controller (otherwise, I'd argue this isn't a simple case that should be handled by pinctrl-simple). As such, I'd expect some properties/table at the top-level of the pin controller object to describe the GPIO mapping. In turn, that implies that the individual per-pin mux-selection/configuration nodes don't need to describe any GPIO-related information. Yes good point. I agree it's a HW design issue, and could be in the properties for the pin controller object. Just to summarize, the things to consider with the GPIO to mux mapping are: 1. Having this table as static data in the driver is is not a nice solution as it seems that we'd currently need six mapping tables for omap2+ alone. 2. This table is not needed for most of the (hundreds of) pins, it's only needed for a few selected pins, let's say ten or so on an average device. So there's no need to stuff the kernel with information about the unused GPIO pins. It seems that the conclusion here is that we don't need to worry about GPIOs in the pinctrl-simple binding for now, and it can be added later without having to change the basic binding. The one thing I wanted to resolve here wasn't so much the binding for GPIO interaction here, but the following comment: You wrote: I wrote: From a binding perspective, I don't see why you'd want to allow two cases: 1) One node with multiple entries in pinctrl-simple,cells 2) Multiple nodes each with a single entry in pinctrl-simple,cells Why not only allow (1)? Because we need to specify GPIO for some pins. There may be additional flags too, we do have external DMA request lines for few pins available.. I'm not saying pinctrl fwk should know about that, but it's a similar mapping of pins to GPIO lines. I'm asserting that since any GPIO mapping information would be at the top-level of the pinctrl-simple binding, we can in fact only allow option (1) above for the individual pin configuration nodes. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On 12 May 2012 00:58, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/10/2012 01:59 PM, Jassi Brar wrote:
I think arbitrary numerical tokens are a reasonable price to pay for the
robustness and simplicity they bring.
I have to disagree here.
Using phandle+ID is almost as simple, and much more flexible. Global IDs
have a number of disadvantages:
a) You have to somehow keep them unique. Even with just a single .dts
file, that's going to be a little painful since there's no central table
of these IDs.
What if the DT is composed of a bunch of chunks that represent pluggable
boards, which may be mixed/matched together depending on what the user
actually plugged in? Then, you have to be very careful to keep the n
different files' numbering ranges segregated, or conflicts will occur.
You might want to revisit this point after working out the finer details of what
you propose for a client's specifier :)
Well, I doubt if there would ever be enough such platforms to warrant a
new generic framework. For now, I would leave that to be a matter between
the dmac driver and its DT node.
Similarly let every dmac, being unique, require DT data in it's own custom
format - I don't believe we can find a generic DT format for every kind of
dmac that does exist or would exist. (For ex, you found a way for RMK's
mux'ed req_lines, but what about assigning priorities to clients which is
possible with PL08X dmacs but not most others?)
Good question. Again thought that sounds a little like policy, so
perhaps should be negotiated at runtime rather than described in DT?
As much as we love everything to be runtime configurable, I am afraid it
can't be. We can't add new calls to the dmaengine api for simply
supporting specific features of various dmacs (priority in this case)
Because that would mean ideally every client going through the mostly
useless ritual of querying/setting those features and most dmacs
just 'pretending' to support some, except for the rare ones that actually do.
So as much as these sound like policy, they would usually be directly
hardcoded via dt for the machine or deducted by the dmac driver.
client0: i2s {
/* has 2 DMA request output signals: 0, 1 */
};
client1: spdif {
/* has 2 DMA request signals: 0, 1 */
};
Do we also need to somehow tag these signals for the client to
differentiate between TX and RX channel ?
Yes, the client's DT binding would certainly need to describe how many
DMA request signals its HW generates, and give a unique ID to each. The
driver would need to request a DMA channel for a specific one of its DMA
requests.
Did I read give a unique ID to each correctly ?
Could you please take some time out to jot down an example of how a
typical client's dma specifier should look.
FWIW, I think I can live with what you propose. Let us go for the kill.
Thanks.
--
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: omap3: am35x: Convert emac to hwmod disable hlt when open
From: Mark A. Greer mgr...@animalcreek.com Paul, Kevin, These patches convert the davinci emac support for the am35x SoC to use hwmod and add enable_hlt()/disable_hlt() calls to the pm_runtime hooks for that driver. I have converted the davinci_emac driver to use pm_runtime but I can't formally submit it yet since it requires some changes on the mach-davinci side that haven't happened yet. I will send it as an RFC in a reply to this thread. The patches are based on: git://git.pwsan.com/linux-2.6 am35xx_hwmod_data_fixes_a_3.5 Mark -- Mark A. Greer (2): arm: omap3: am35x: Add Davinci EMAC/MDIO hwmod support arm: omap3: am35x: Disable hlt when using Davinci EMAC arch/arm/mach-omap2/am35xx-emac.c | 120 ++-- arch/arm/mach-omap2/am35xx-emac.h | 16 +++- arch/arm/mach-omap2/board-am3517evm.c |3 +- arch/arm/mach-omap2/board-cm-t3517.c |3 +- arch/arm/mach-omap2/clock3xxx_data.c |2 +- arch/arm/mach-omap2/include/mach/am35xx.h |2 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 85 7 files changed, 183 insertions(+), 48 deletions(-) -- 1.7.9.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] arm: omap3: am35x: Add Davinci EMAC/MDIO hwmod support
From: Mark A. Greer mgr...@animalcreek.com
Add hwmod support for the EMAC (and MDIO)
ethernet controller that's on the am35x
family of SoC's.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/am35xx-emac.c | 92 ++--
arch/arm/mach-omap2/clock3xxx_data.c |2 +-
arch/arm/mach-omap2/include/mach/am35xx.h |2 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 85 +
4 files changed, 135 insertions(+), 46 deletions(-)
diff --git a/arch/arm/mach-omap2/am35xx-emac.c
b/arch/arm/mach-omap2/am35xx-emac.c
index 1f97e74..3bb5cb3 100644
--- a/arch/arm/mach-omap2/am35xx-emac.c
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -15,27 +15,13 @@
* General Public License for more details.
*/
-#include linux/clk.h
+#include linux/err.h
#include linux/davinci_emac.h
-#include linux/platform_device.h
-#include plat/irqs.h
+#include asm/system.h
+#include plat/omap_device.h
#include mach/am35xx.h
-
#include control.h
-
-static struct mdio_platform_data am35xx_emac_mdio_pdata;
-
-static struct resource am35xx_emac_mdio_resources[] = {
- DEFINE_RES_MEM(AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET, SZ_4K),
-};
-
-static struct platform_device am35xx_emac_mdio_device = {
- .name = davinci_mdio,
- .id = 0,
- .num_resources = ARRAY_SIZE(am35xx_emac_mdio_resources),
- .resource = am35xx_emac_mdio_resources,
- .dev.platform_data = am35xx_emac_mdio_pdata,
-};
+#include am35xx-emac.h
static void am35xx_enable_emac_int(void)
{
@@ -72,41 +58,57 @@ static struct emac_platform_data am35xx_emac_pdata = {
.interrupt_disable = am35xx_disable_emac_int,
};
-static struct resource am35xx_emac_resources[] = {
- DEFINE_RES_MEM(AM35XX_IPSS_EMAC_BASE, 0x3),
- DEFINE_RES_IRQ(INT_35XX_EMAC_C0_RXTHRESH_IRQ),
- DEFINE_RES_IRQ(INT_35XX_EMAC_C0_RX_PULSE_IRQ),
- DEFINE_RES_IRQ(INT_35XX_EMAC_C0_TX_PULSE_IRQ),
- DEFINE_RES_IRQ(INT_35XX_EMAC_C0_MISC_PULSE_IRQ),
-};
+static struct mdio_platform_data am35xx_mdio_pdata;
-static struct platform_device am35xx_emac_device = {
- .name = davinci_emac,
- .id = -1,
- .num_resources = ARRAY_SIZE(am35xx_emac_resources),
- .resource = am35xx_emac_resources,
- .dev= {
- .platform_data = am35xx_emac_pdata,
- },
-};
+static int __init omap_davinci_emac_dev_init(struct omap_hwmod *oh,
+ void *pdata, int pdata_len)
+{
+ struct platform_device *pdev;
+
+ pdev = omap_device_build(oh-class-name, 0, oh, pdata, pdata_len,
+ NULL, 0, false);
+ if (IS_ERR(pdev)) {
+ WARN(1, Can't build omap_device for %s:%s.\n,
+ oh-class-name, oh-name);
+ return PTR_ERR(pdev);
+ }
+
+ return 0;
+}
void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en)
{
- unsigned int regval;
- int err;
+ struct omap_hwmod *oh;
+ u32 regval;
+ int ret;
- am35xx_emac_pdata.rmii_en = rmii_en;
- am35xx_emac_mdio_pdata.bus_freq = mdio_bus_freq;
- err = platform_device_register(am35xx_emac_device);
- if (err) {
- pr_err(AM35x: failed registering EMAC device: %d\n, err);
+ oh = omap_hwmod_lookup(davinci_mdio);
+ if (!oh) {
+ pr_err(Could not find davinci_mdio hwmod\n);
+ return;
+ }
+
+ am35xx_mdio_pdata.bus_freq = mdio_bus_freq;
+
+ ret = omap_davinci_emac_dev_init(oh, am35xx_mdio_pdata,
+sizeof(am35xx_mdio_pdata));
+ if (ret) {
+ pr_err(Could not build davinci_mdio hwmod device\n);
return;
}
- err = platform_device_register(am35xx_emac_mdio_device);
- if (err) {
- pr_err(AM35x: failed registering EMAC MDIO device: %d\n, err);
- platform_device_unregister(am35xx_emac_device);
+ oh = omap_hwmod_lookup(davinci_emac);
+ if (!oh) {
+ pr_err(Could not find davinci_emac hwmod\n);
+ return;
+ }
+
+ am35xx_emac_pdata.rmii_en = rmii_en;
+
+ ret = omap_davinci_emac_dev_init(oh, am35xx_emac_pdata,
+sizeof(am35xx_emac_pdata));
+ if (ret) {
+ pr_err(Could not build davinci_emac hwmod device\n);
return;
}
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 12c64db..f2f422e 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3478,7 +3478,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, ipss_ick, ipss_ick, CK_AM35XX),
CLK(NULL, rmii_ck, rmii_ck, CK_AM35XX),
CLK(NULL, pclk_ck,
[PATCH 2/2] arm: omap3: am35x: Disable hlt when using Davinci EMAC
From: Mark A. Greer mgr...@animalcreek.com
The am35x family of SoCs has a Davinci EMAC ethernet
controller on-chip. Unfortunately, the EMAC is unable
to wake the PRCM when there is network activity which
leads to a hung or extremely slow system when the MPU
has executed a 'wfi' instruction (because of pm_idle
or CPUidle). To prevent this, add hooks to the EMAC
pm_runtime suspend/resume calls so that hlt is disabled
whenever the EMAC is in use.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/am35xx-emac.c | 44 +
arch/arm/mach-omap2/am35xx-emac.h | 16 +---
arch/arm/mach-omap2/board-am3517evm.c |3 ++-
arch/arm/mach-omap2/board-cm-t3517.c |3 ++-
4 files changed, 56 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/am35xx-emac.c
b/arch/arm/mach-omap2/am35xx-emac.c
index 3bb5cb3..22ff968 100644
--- a/arch/arm/mach-omap2/am35xx-emac.c
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -23,6 +23,37 @@
#include control.h
#include am35xx-emac.h
+/*
+ * Default pm_lats for the am35x.
+ * The net effect of using am35xx_emac_pm_lats[] is that
+ * pm_idle or CPUidle won't be called while the emac
+ * interface is open. This is required because the
+ * EMAC can't wake up PRCM so if the MPU is executing
+ * a 'wfi' instruction (e.g., from pm_idle or CPUidle),
+ * it won't break out of it due to emac activity.
+ */
+static int am35xx_emac_deactivate_func(struct omap_device *od)
+{
+ enable_hlt();
+ return omap_device_idle_hwmods(od);
+}
+
+static int am35xx_emac_activate_func(struct omap_device *od)
+{
+ disable_hlt();
+ return omap_device_enable_hwmods(od);
+}
+
+struct omap_device_pm_latency am35xx_emac_pm_lats[] = {
+ {
+ .deactivate_func= am35xx_emac_deactivate_func,
+ .activate_func = am35xx_emac_activate_func,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+int am35xx_emac_pm_lats_size = ARRAY_SIZE(am35xx_emac_pm_lats);
+
static void am35xx_enable_emac_int(void)
{
u32 regval;
@@ -61,12 +92,13 @@ static struct emac_platform_data am35xx_emac_pdata = {
static struct mdio_platform_data am35xx_mdio_pdata;
static int __init omap_davinci_emac_dev_init(struct omap_hwmod *oh,
- void *pdata, int pdata_len)
+ void *pdata, int pdata_len,
+ struct omap_device_pm_latency *pm_lats, int pm_lats_size)
{
struct platform_device *pdev;
pdev = omap_device_build(oh-class-name, 0, oh, pdata, pdata_len,
- NULL, 0, false);
+ pm_lats, pm_lats_size, false);
if (IS_ERR(pdev)) {
WARN(1, Can't build omap_device for %s:%s.\n,
oh-class-name, oh-name);
@@ -76,7 +108,8 @@ static int __init omap_davinci_emac_dev_init(struct
omap_hwmod *oh,
return 0;
}
-void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en)
+void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en,
+ struct omap_device_pm_latency *pm_lats, int pm_lats_size)
{
struct omap_hwmod *oh;
u32 regval;
@@ -91,7 +124,7 @@ void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8
rmii_en)
am35xx_mdio_pdata.bus_freq = mdio_bus_freq;
ret = omap_davinci_emac_dev_init(oh, am35xx_mdio_pdata,
-sizeof(am35xx_mdio_pdata));
+sizeof(am35xx_mdio_pdata), NULL, 0);
if (ret) {
pr_err(Could not build davinci_mdio hwmod device\n);
return;
@@ -106,7 +139,8 @@ void __init am35xx_emac_init(unsigned long mdio_bus_freq,
u8 rmii_en)
am35xx_emac_pdata.rmii_en = rmii_en;
ret = omap_davinci_emac_dev_init(oh, am35xx_emac_pdata,
-sizeof(am35xx_emac_pdata));
+sizeof(am35xx_emac_pdata),
+pm_lats, pm_lats_size);
if (ret) {
pr_err(Could not build davinci_emac hwmod device\n);
return;
diff --git a/arch/arm/mach-omap2/am35xx-emac.h
b/arch/arm/mach-omap2/am35xx-emac.h
index 15c6f9c..7c23808 100644
--- a/arch/arm/mach-omap2/am35xx-emac.h
+++ b/arch/arm/mach-omap2/am35xx-emac.h
@@ -6,10 +6,20 @@
* published by the Free Software Foundation.
*/
+#include plat/omap_device.h
+
#define AM35XX_DEFAULT_MDIO_FREQUENCY 100
-#if defined(CONFIG_TI_DAVINCI_EMAC) || defined(CONFIG_TI_DAVINCI_EMAC_MODULE)
-void am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en);
+#if IS_ENABLED(CONFIG_TI_DAVINCI_EMAC)
+extern struct omap_device_pm_latency am35xx_emac_pm_lats[];
+extern int am35xx_emac_pm_lats_size;
+
+void am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en,
+ struct omap_device_pm_latency *pm_lats, int
Re: [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
Hiremath, Vaibhav hvaib...@ti.com writes: On Fri, May 11, 2012 at 03:09:39, Hilman, Kevin wrote: Hiremath, Vaibhav hvaib...@ti.com writes: On Wed, May 09, 2012 at 04:08:09, Hilman, Kevin wrote: Vaibhav Hiremath hvaib...@ti.com writes: The function __omap2_set_globals() can be common across all platforms/architectures, even in case of omap4, internally it calls same set of functions as in __omap2_set_globals() function (except for sdrc). OK so far. This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc, so that we can reuse same function across omap2/3/4... But what happens when a single kernel is built that has support for an SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)? As such Nothing...I looking into this direction while implementing. In that case, sdrc.c file will be compiled in and execution will jump to omap2_set_globals_sdrc(). But inside this function, we are already checking whether the omap2_globals-sdrc and omap2_globals-sms for NULL and then use it. And function omap2_sdrc_init() is also depends on machine, so in case of Am33xx, it won't get into sdrc execution at all. And in case of omap4, it will. Then why bother with the #ifdef at all? If it already safe to call on all SoCs, just get rid of the #ifdef all together. Kevin, sdrc.o target gets built only as omap-2-3-common, this will not get built for omap4, am33xx, ti81xx, etc... OK, I see what you mean now. I was confusing because this patch doesn't touch sdrc.c, or the Makefile for sdrc.c. So in order to avoid build break, you have to have some mechanism, and that's where we need to create config option dependent on platform. That being the case, for readability sake, I suggest you change the Makefile to use the new config option for sdrc.c as well. 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: OMAP3EVM not booting on l-o master
Hi Kevin, On Wed, 2 May 2012, Kevin Hilman wrote: From 22726db6fc514cc5110db43fdf05d5afda8e4a59 Mon Sep 17 00:00:00 2001 From: Kevin Hilman khil...@ti.com Date: Tue, 1 May 2012 07:06:42 -0700 Subject: [PATCH] ARM: OMAP3: PM: leave PRCM interrupts disabled until explicitly enabled. By default, request_irq() will auto-enable the requested IRQ. For PRCM interrupts, we may want to avoid that until the PM core code is fully ready to handle the interrupts. This is particularily true for IO pad interrupts on OMAP3, which are shared between the hwmod core and the PRM core. In order to avoid PRCM IO-chain interrupts until the PM core is ready to handle them, ready, set the IRQ_NOAUTOEN flag for the PRCM IO-chain interrupt, which means it will remain disabled after request_irq(). Then, explicitly enable the PRCM interrupts after the request_irq() in the PM core (but not in the hwmod core.) Special thanks to Tero Kristo for suggesting to isolate the fix to only the IO-chain interrupt on OMAP3 instead of all PRCM interrupts. Tested-by: Afzal Mohammed af...@ti.com Acked-by: Tero Kristo t-kri...@ti.com Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Kevin Hilman khil...@ti.com Acked-by: Paul Walmsley p...@pwsan.com If for some reason it doesn't get in for 3.5, let me know and I'll queue with the other IO chain patches for 3.6 as we discussed. - 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 V3 1/2] of: Add generic device tree DMA helpers
On 05/11/2012 03:06 PM, Jassi Brar wrote:
On 12 May 2012 00:58, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/10/2012 01:59 PM, Jassi Brar wrote:
...
client0: i2s {
/* has 2 DMA request output signals: 0, 1 */
};
client1: spdif {
/* has 2 DMA request signals: 0, 1 */
};
Do we also need to somehow tag these signals for the client to
differentiate between TX and RX channel ?
Yes, the client's DT binding would certainly need to describe how many
DMA request signals its HW generates, and give a unique ID to each. The
driver would need to request a DMA channel for a specific one of its DMA
requests.
Did I read give a unique ID to each correctly ?
It'd be unique relative to that individual device or DT node, not at any
larger scope.
Could you please take some time out to jot down an example of how a
typical client's dma specifier should look.
With this proposal, I'm not sure that the client DT node would need any
DMA information at all, at least nothing that identifies which DMA
controllers, channels, or requests are required to service this
node/device's DMA requests - that routing information is all represented
in the DMA controller itself.
(I think Arnd made the following point earlier in this thread):
If you did need to put any other information in DT, then that probably
would go in the DMA client node, since it'd presumably be the same
irrespective of which DMA controller got used. However, that information
presumably wouldn't be needed in DT at all, since the driver would know
it, since it'd be a facet of the HW.
Note: I'm thinking things like DMA physical address (presumably an
offset from the reg property), DMA access size (presumably a fixed
property of the HW), DMA burst size (presumably a property of the HW,
although at least some HW can be programmed to raise the DMA request
signal with a varying number of FIFO entries free, so not fixed), etc.
FWIW, I think I can live with what you propose. Let us go for the kill.
--
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: oprofile and ARM A9 hardware counter
Hi Will, On 05/11/2012 11:38 AM, Will Deacon wrote: On Fri, May 11, 2012 at 05:31:47PM +0100, Jon Hunter wrote: Can you send me your .config? Sent off-list. At the same time, maybe just try make omap2plus_defconfig and enable the OMAP3 debug devices config. That's all I am doing. Excellent, that works for me. Once we've worked out the problem with my .config you can have my tested-by. Great! I have been looking at your .config, but I have not been able to figure out the problem so far. Do you recall what your config is based upon? I seems quite different to mine and the omap2plus_defconfig has not changed much in the last few kernel releases. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 14/14] OMAPDSS: HDMI: Implement DSS driver interface for audio
On 05/11/2012 07:51 AM, Tomi Valkeinen wrote: On Thu, 2012-05-10 at 20:56 -0500, Ricardo Neri wrote: Sorry, some hunks where missing in the patch that I submitted yesterday. I just pushed a branch containing the whole most up-to-date series here: git://gitorious.org/omap-audio/linux-audio.git ricardon/topic/dss_audio-for-tomi This includes the implementation of the DSS audio interface for HDMI covering the improved locking strategy [1][2], plus the missing hunks in my yesterday's patch, plus handling of mode changes you pointed out. Please let me know if you want me to resubmit the whole patch series so that you can comment if you need to. Thanks, I think this is fine. I had to rebase your branch as you had some extra patches there also. There were also a few conflicts with latest dss stuff, but nothing serious. I pushed the branch with latest dss and your branch to: git://gitorious.org/linux-omap-dss2/linux.git test With a quick test video works ok, but I didn't test audio. Thanks for taking the patches! In your branch, the audio part would not build with audio enabled as your branch does not have the ALSA CEA-861 definitions patch [1]. The platform devices for the ASoC HDMI drivers[2] are also missing. I put these patches on top of your test branch and audio works well. [1] and [2] will come from Takashi's and Tony's branches. BR, Ricardo [1]http://www.mail-archive.com/linux-omap@vger.kernel.org/msg66600.html [2]http://www.spinics.net/lists/linux-omap/msg68834.html 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
[GIT PULL] gpio/omap: cleanups for v3.5
Hi Grant, Here's the final round of GPIO cleanups for v3.5. This branch is based on my for_3.5/fixes/gpio branch you just pulled. Kevin The following changes since commit 6edd94db250038c8fdf176f23ca4017d2f312509: gpio/omap: fix incorrect initialization of omap_gpio_mod_init (2012-05-10 07:16:15 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.5/gpio/cleanup for you to fetch changes up to 1b1287032df3a69d3ef9a486b444f4ffcca50d01: gpio/omap: fix missing check in *_runtime_suspend() (2012-05-11 17:08:40 -0700) Tarun Kanti DebBarma (8): gpio/omap: remove virtual_irq_start variable gpio/omap: remove saved_fallingdetect, saved_risingdetect gpio/omap: remove suspend_wakeup field from struct gpio_bank gpio/omap: remove saved_wakeup field from struct gpio_bank gpio/omap: remove retrigger variable in gpio_irq_handler gpio/omap: remove suspend/resume callbacks gpio/omap: remove cpu_is_omap() checks from *_runtime_resume() gpio/omap: fix missing check in *_runtime_suspend() arch/arm/mach-omap1/gpio15xx.c |2 - arch/arm/mach-omap1/gpio16xx.c |5 -- arch/arm/mach-omap1/gpio7xx.c |7 --- arch/arm/mach-omap2/gpio.c |3 +- arch/arm/plat-omap/include/plat/gpio.h |3 +- drivers/gpio/gpio-omap.c | 103 +++- 6 files changed, 27 insertions(+), 96 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] gpio/omap: cleanups for v3.5
On Fri, 11 May 2012 17:30:48 -0700, Kevin Hilman khil...@ti.com wrote: Hi Grant, Here's the final round of GPIO cleanups for v3.5. This branch is based on my for_3.5/fixes/gpio branch you just pulled. Kevin The following changes since commit 6edd94db250038c8fdf176f23ca4017d2f312509: gpio/omap: fix incorrect initialization of omap_gpio_mod_init (2012-05-10 07:16:15 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.5/gpio/cleanup Applied, thanks. g. for you to fetch changes up to 1b1287032df3a69d3ef9a486b444f4ffcca50d01: gpio/omap: fix missing check in *_runtime_suspend() (2012-05-11 17:08:40 -0700) Tarun Kanti DebBarma (8): gpio/omap: remove virtual_irq_start variable gpio/omap: remove saved_fallingdetect, saved_risingdetect gpio/omap: remove suspend_wakeup field from struct gpio_bank gpio/omap: remove saved_wakeup field from struct gpio_bank gpio/omap: remove retrigger variable in gpio_irq_handler gpio/omap: remove suspend/resume callbacks gpio/omap: remove cpu_is_omap() checks from *_runtime_resume() gpio/omap: fix missing check in *_runtime_suspend() arch/arm/mach-omap1/gpio15xx.c |2 - arch/arm/mach-omap1/gpio16xx.c |5 -- arch/arm/mach-omap1/gpio7xx.c |7 --- arch/arm/mach-omap2/gpio.c |3 +- arch/arm/plat-omap/include/plat/gpio.h |3 +- drivers/gpio/gpio-omap.c | 103 +++- 6 files changed, 27 insertions(+), 96 deletions(-) -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4-alt 3/6] ARM: OMAP3: hwmod data: add gpmc
Hi Paul, On Thu, May 10, 2012 at 11:33:44, Mohammed, Afzal wrote: Hi Paul, On Tue, May 08, 2012 at 21:02:33, Paul Walmsley wrote: Major reason was that there are some boards that rely on bootloader settings, eg. kernel does not do any setting for smsc911x. I did not want to break those, at least it causes problem with omap3evm, see below But this is the whole point. The Linux GPMC driver and integration code should be setting up the GPMC registers based on board file and/or DT data, before the kernel touches any GPMC devices. We don't want to rely on the bootloader settings unless we absolutely have no other choice. Otherwise, the stability of the kernel could easily be impacted by the bootloader's GPMC timings and other register settings, and we want to minimize those potential sources of variation. So if we absolutely have no choice than to keep HWMOD_INIT_NO_RESET here, which doesn't sound like the case so far, we need to understand exactly why this is so. There are 14 out of 20 boards partially or fully relying on bootloader settings. I will try to do configuration for smsc911x in Kernel itself, this is the only one that can be tested from my side (on omap3evm), but there are other peripherals like NOR, quaduart, onenand-flash (different from omap-onenand), then smc91x (timings are not set from kernel for sdp boards), these would affect 7 boards of both omap2 omap3. To get configuration done from Kernel properly without having these boards is too tough for me. So I request you to keep HWMOD_INIT_NO_RESET (I will add configuration for smsc911x), please let me know your comments. ping Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] few omap fixups for v3.5 merge window
On Fri, May 11, 2012 at 12:22 PM, Tony Lindgren t...@atomide.com wrote: Hi Arnd Olof, Here are the fixes needed for the regressions caused by omap-cleanup-sparse-for-v3.5. I suggest pulling this into arm-soc/omap/cleanup-sparse where the issues got introduced. Regards, Tony The following changes since commit 09f45b83109cb8e23a06d5efb1096a08a9545974: Merge tag 'omap-cleanup-a2-for-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into cleanup-sparse (2012-04-18 10:09:26 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes-for-cleanup Thanks, pulled. -Olof -- 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
