Re: [PATCH v2 5/5] OMAPDSS: HDMI: Add support to dump clocks through
On Fri, 2011-09-23 at 11:22 +0530, K, Mythri P wrote: - What is dcofreq? Looking at the code, it tells if the pixel clock is 1000MHz. Why is such a field needed, can't the HDMI driver manage that itself? And if it's needed, why is it called dcofreq, the name doesn't make much sense to me. It is DCO frequency, It suggest the frequency selector range , The field is not DCO frequency, it's a boolean, 0 or 1. That's why the name doesn't really make sense to me. HDMI_PLL_CONFIGURATION2 (3:1) has to be set accordingly by the driver depending on whether the CLKOUTLDO is greater than or less than 1000Mhz, but anyways the decision is taken by the driver. But can't it be done in the ti_hdmi driver, at the same time when programming the registers? Why do we need to set the boolean beforehand. Also the name is as suggested by TRM . I couldn't find boolean dcofreq in the TRM. - We are doing HDMI PLL calculations in the omapdss drivers hdmi.c file. The PLL calculations are PLL specific, and thus should be in the specific HDMI implementation file, right? + seq_printf(s, DISPC clock source %s (%s)\t(%s)\n, + dss_get_generic_clk_source_name(dispc_clk_src), + dss_feat_get_clk_source_name(dispc_clk_src), + dispc_clk_src == OMAP_DSS_CLK_SRC_FCK ? + off : on); Why do you print DISPC clock source? How is that part of HDMI clock configuration? Reason is to check whether the DISPC clock source is PRCM / DSI PLL, Because DSI PLL might not be sufficient. But it's already printed by the DISPC section, and it's not part of HDMI, so I don't quite see the need. What do you mean DSI PLL might not be sufficient? We can get higher DISPC clocks with DSI PLL than with PRCM. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] OMAP4: Hwmod: system control module hwmod
+ Benoît Hi, On Thu, 22 Sep 2011, Keerthy wrote: From: Benoit Cousson b-cous...@ti.com Adding the system control module hwmod. Have the autogeneration scripts been updated ? Signed-off-by: Benoit Cousson b-cous...@ti.com Signed-off-by: Keerthy j-keer...@ti.com - Paul
Re: [PATCH] OMAP2+: clock: cleanup CPUfreq leftovers
On Thu, 22 Sep 2011, Paul Walmsley wrote: On Thu, 22 Sep 2011, Kevin Hilman wrote: Now that we have OPP layer, and OMAP CPUfreq driver is using it, we no longer need/use the clock framework code for filling up CPUfreq tables. Remove it. Signed-off-by: Kevin Hilman khil...@ti.com --- Paul, this patch has a dependency on the OMAP CPUFreq driver move/cleanup series just posted. Assuming that is merged for v3.2, this can go also. Great, could you cc lakml also ? By the way, I guess the subject line should start with ARM: OMAP2+: clock: .. etc., per Arnd's recent request. - 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 0/6] system control module device and support for temperature sensor
Hi On Thu, 22 Sep 2011, Keerthy wrote: The patch series adds support of system control module device and adds support temperature sensor. The patch series adds hwmod for system control module and enables the clocks for temperature sensor. The OMAP4460 specific register set data for the on die mpu temperature sensor is also part of this series. Benoit Cousson (1): OMAP4: Hwmod: system control module hwmod Keerthy (4): OMAP4: Adding the temperature sensor register set bit fields OMAP4: Clock: Associate clocks for OMAP temperature sensor OMAP4460: Temperature sensor data OMAP4: System control module device support Vishwanath BS (1): OMAP4460: Clock: Adding support for 4460 specific clocks Also, before you re-post, could you please prefix the subject lines of all of these patches with ARM: per Arnd Bergmann's recent request? thanks - 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 5/5] OMAPDSS: HDMI: Add support to dump clocks through
Hi, On Fri, Sep 23, 2011 at 11:31 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Fri, 2011-09-23 at 11:22 +0530, K, Mythri P wrote: - What is dcofreq? Looking at the code, it tells if the pixel clock is 1000MHz. Why is such a field needed, can't the HDMI driver manage that itself? And if it's needed, why is it called dcofreq, the name doesn't make much sense to me. It is DCO frequency, It suggest the frequency selector range , The field is not DCO frequency, it's a boolean, 0 or 1. That's why the name doesn't really make sense to me. HDMI_PLL_CONFIGURATION2 (3:1) has to be set accordingly by the driver depending on whether the CLKOUTLDO is greater than or less than 1000Mhz, but anyways the decision is taken by the driver. But can't it be done in the ti_hdmi driver, at the same time when programming the registers? Why do we need to set the boolean beforehand. It can be done, It is not a boolean , boolean logic is used to determine the value 0x2 / 0x4. Page # 101. (DCO frequency). Also the name is as suggested by TRM . I couldn't find boolean dcofreq in the TRM. - We are doing HDMI PLL calculations in the omapdss drivers hdmi.c file. The PLL calculations are PLL specific, and thus should be in the specific HDMI implementation file, right? + seq_printf(s, DISPC clock source %s (%s)\t(%s)\n, + dss_get_generic_clk_source_name(dispc_clk_src), + dss_feat_get_clk_source_name(dispc_clk_src), + dispc_clk_src == OMAP_DSS_CLK_SRC_FCK ? + off : on); Why do you print DISPC clock source? How is that part of HDMI clock configuration? Reason is to check whether the DISPC clock source is PRCM / DSI PLL, Because DSI PLL might not be sufficient. But it's already printed by the DISPC section, and it's not part of HDMI, so I don't quite see the need. What do you mean DSI PLL might not be sufficient? We can get higher DISPC clocks with DSI PLL than with PRCM. Well , from the older calculation / values passed to DSI , it was seen that DSI PLL was in the order of 156Mhz, and PRCM with 186Mhz. This had resulted in underflow issues with HDMI. Thanks and regards, Mythri. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: OMAP4460+: System control module driver
Hi some comments: On Thu, 22 Sep 2011, Keerthy wrote: The system control module has several components. On die temperature is a part of system control module. The system control module driver registers the temperature sensor as a client. A hwmon driver for temperature sensor to route the temperature and the thresholds to the user space. The system control module driver patch depends on the following series found here: http://comments.gmane.org/gmane.linux.ports.arm.omap/64436 Signed-off-by: Keerthy j-keer...@ti.com Cc:sa...@linux.intel.com This should also be sent to the linux-arm-ker...@lists.infradead.org and linux-ker...@vger.kernel.org lists as well as the linux-omap list. --- drivers/mfd/Kconfig|9 + drivers/mfd/Makefile |2 +- drivers/mfd/omap4460plus_scm.c | 581 3 files changed, 591 insertions(+), 1 deletions(-) create mode 100644 drivers/mfd/omap4460plus_scm.c Index: linux-omap-2.6/drivers/mfd/Kconfig === --- linux-omap-2.6.orig/drivers/mfd/Kconfig 2011-09-22 18:35:25.636575640 +0530 +++ linux-omap-2.6/drivers/mfd/Kconfig2011-09-22 18:35:43.412576517 +0530 @@ -212,6 +212,15 @@ and other features that are often used in portable devices like cell phones and PDAs. +config OMAP4460PLUS_SCM + bool Texas Instruments OMAP4460 System control module + depends on ARCH_OMAP OMAP_SCM_DEV + help + If you say yes here you get support for the Texas Instruments + OMAP4460 system control module. This includes support for + on die temperature sensor which is a part of System control + module. + It seems to me that this driver should work for the OMAP4430 as well. Is there a reason why this is marked as OMAP4460 all over? config TWL4030_CORE bool Texas Instruments TWL4030/TWL5030/TWL6030/TPS659x0 Support depends on I2C=y GENERIC_HARDIRQS Index: linux-omap-2.6/drivers/mfd/Makefile === --- linux-omap-2.6.orig/drivers/mfd/Makefile 2011-09-22 18:35:25.604576115 +0530 +++ linux-omap-2.6/drivers/mfd/Makefile 2011-09-22 18:35:43.416576975 +0530 @@ -42,7 +42,7 @@ obj-$(CONFIG_MFD_TPS65912_I2C) += tps65912-i2c.o obj-$(CONFIG_MFD_TPS65912_SPI) += tps65912-spi.o obj-$(CONFIG_MENELAUS) += menelaus.o - +obj-$(CONFIG_OMAP4460PLUS_SCM) += omap4460plus_scm.o obj-$(CONFIG_TWL4030_CORE) += twl-core.o twl4030-irq.o twl6030-irq.o obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o Index: linux-omap-2.6/drivers/mfd/omap4460plus_scm.c === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-omap-2.6/drivers/mfd/omap4460plus_scm.c 2011-09-22 18:53:05.132583900 +0530 Please split this file into at least two files, as is the standard practice for MFD drivers. There should be one omap4-scm-core.c file, and one omap4-scm-tempsensor.c file. Everything temperature sensor-specific should go into the omap4-scm-tempsensor.c file. @@ -0,0 +1,581 @@ +/* + * OMAP4 system control module driver file + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/ + * Author: J Keerthy j-keer...@ti.com + * Author: Moiz Sonasath m-sonas...@ti.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ + +#include linux/interrupt.h +#include linux/clk.h +#include linux/io.h +#include linux/slab.h +#include linux/platform_device.h +#include plat/omap_device.h +#include linux/kernel.h +#include linux/jiffies.h +#include linux/err.h +#include linux/types.h +#include linux/mutex.h +#include linux/delay.h +#include plat/scm.h + +#define TSHUT_HOT920 /* 122 deg C */ +#define TSHUT_COLD 866 /* 100 deg C */ +#define T_HOT800 /* 73 deg C */ +#define T_COLD 795 /* 71 deg C */ +#define MAX_FREQ 200 +#define MIN_FREQ 100 +#define MIN_TEMP -4 +#define MAX_TEMP 123000 +#define HYST_VAL 5000 Are any of these definitions
Re: [PATCH v2 5/5] OMAPDSS: HDMI: Add support to dump clocks through
On Fri, 2011-09-23 at 12:10 +0530, K, Mythri P wrote: Hi, On Fri, Sep 23, 2011 at 11:31 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Fri, 2011-09-23 at 11:22 +0530, K, Mythri P wrote: - What is dcofreq? Looking at the code, it tells if the pixel clock is 1000MHz. Why is such a field needed, can't the HDMI driver manage that itself? And if it's needed, why is it called dcofreq, the name doesn't make much sense to me. It is DCO frequency, It suggest the frequency selector range , The field is not DCO frequency, it's a boolean, 0 or 1. That's why the name doesn't really make sense to me. HDMI_PLL_CONFIGURATION2 (3:1) has to be set accordingly by the driver depending on whether the CLKOUTLDO is greater than or less than 1000Mhz, but anyways the decision is taken by the driver. But can't it be done in the ti_hdmi driver, at the same time when programming the registers? Why do we need to set the boolean beforehand. It can be done, It is not a boolean , boolean logic is used to determine the value 0x2 / 0x4. Page # 101. (DCO frequency). The code says: pi-dcofreq = phy 1000 * 100; so it is a boolean. What do you mean DSI PLL might not be sufficient? We can get higher DISPC clocks with DSI PLL than with PRCM. Well , from the older calculation / values passed to DSI , it was seen that DSI PLL was in the order of 156Mhz, and PRCM with 186Mhz. This had resulted in underflow issues with HDMI. But that's just up to the particular configuration used. DSI PLL can be configured to reach the maximum DSS FCLK, but with PRCM this is not usually possible. I see your point that it is relevant for HDMI to work properly, but there are many other things that are also needed for HDMI to work properly and we don't print them. And as the DISPC clk source is already printed above in the DISPC section, I don't see the need for that here. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] iommu/omap: Fix build error with !IOMMU_SUPPORT
On Thu, Sep 22, 2011 at 09:48:27AM -0400, Felipe Contreras wrote: On Tue, Sep 20, 2011 at 1:54 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: On Tuesday 20 September 2011 12:01:46 Roedel, Joerg wrote: On Sat, Sep 17, 2011 at 08:02:22PM -0400, Laurent Pinchart wrote: On Wednesday 14 September 2011 16:07:39 Joerg Roedel wrote: Without this patch it is possible to select the VIDEO_OMAP3 driver which then selects OMAP_IOVMM. But the omap iommu driver is not compiled without IOMMU_SUPPORT enabled. Fix that by forcing OMAP_IOMMU and OMAP_IOVMM are enabled before VIDEO_OMAP3 can be selected. What about making VIDEO_OMAP3 select IOMMU_SUPPORT instead then ? Your patch would make the OMAP3 ISP driver disappear from the menu until IOMMU_SUPPORT gets turned on, which can confuse users. Using 'depends on' rather then 'selects' is common standard in Kconfig. You can't select PCI drivers without selecting PCI first, for example. You wouldn't expect a PCI driver to work without PCI support. My concern is that most OMAP3 ISP users won't know that IOMMU supports is required. Feel free to ignore it though :-) I agree with Laurent. As a user, why should I care about IOMMU? I just want this thing. Because enabling IOMMU can have other side-effects on the system and as a user you want to be aware that it is enabled. A user not wanting the iommu driver can just disable it then without the need to de-select all drivers depending on it first. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/10] cpufreq: OMAP: cleanup for multi-SoC support,move into drivers/cpufreq
Kevin,
-Original Message-
From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-
arm-kernel-boun...@lists.infradead.org] On Behalf Of Kevin Hilman
Sent: Friday, September 23, 2011 2:37 AM
To: cpuf...@vger.kernel.org; Dave Jones
Cc: Nishanth Menon; linux-omap@vger.kernel.org; Santosh Shilimkar;
linux-arm-ker...@lists.infradead.org; Rajendra Nayak
Subject: [PATCH 01/10] cpufreq: OMAP: cleanup for multi-SoC
support,move into drivers/cpufreq
From: Santosh Shilimkar santosh.shilim...@ti.com
Move OMAP cpufreq driver from arch/arm/mach-omap2 into
drivers/cpufreq, along with a few cleanups:
- generalize support for better handling of different SoCs in the
OMAP
- use OPP layer instead of OMAP clock internals for frequency table
init
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[khil...@ti.com: move to drivers]
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/Makefile|1 -
arch/arm/plat-omap/cpu-omap.c | 171 -
---
drivers/cpufreq/Makefile |1 +
drivers/cpufreq/omap-cpufreq.c | 188
4 files changed, 189 insertions(+), 172 deletions(-)
delete mode 100644 arch/arm/plat-omap/cpu-omap.c
create mode 100644 drivers/cpufreq/omap-cpufreq.c
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-
omap/Makefile
index f0233e6..4ef7493 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -21,7 +21,6 @@ obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
obj-$(CONFIG_OMAP_IOMMU) += iommu.o iovmm.o
obj-$(CONFIG_OMAP_IOMMU_DEBUG) += iommu-debug.o
-obj-$(CONFIG_CPU_FREQ) += cpu-omap.o
obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o
obj-$(CONFIG_OMAP_DEBUG_DEVICES) += debug-devices.o
obj-$(CONFIG_OMAP_DEBUG_LEDS) += debug-leds.o
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-
omap.c
deleted file mode 100644
index da4f68d..000
--- a/arch/arm/plat-omap/cpu-omap.c
+++ /dev/null
@@ -1,171 +0,0 @@
-/*
- * linux/arch/arm/plat-omap/cpu-omap.c
- *
- * CPU frequency scaling for OMAP
- *
- * Copyright (C) 2005 Nokia Corporation
- * Written by Tony Lindgren t...@atomide.com
- *
- * Based on cpu-sa1110.c, Copyright (C) 2001 Russell King
- *
- * This program is free software; you can redistribute it and/or
modify
- * it under the terms of the GNU General Public License version 2
as
- * published by the Free Software Foundation.
- */
-#include linux/types.h
-#include linux/kernel.h
-#include linux/sched.h
-#include linux/cpufreq.h
-#include linux/delay.h
-#include linux/init.h
-#include linux/err.h
-#include linux/clk.h
-#include linux/io.h
-
-#include mach/hardware.h
-#include plat/clock.h
-#include asm/system.h
-
-#define VERY_HI_RATE 9
-
-static struct cpufreq_frequency_table *freq_table;
-
-#ifdef CONFIG_ARCH_OMAP1
-#define MPU_CLK mpu
-#else
-#define MPU_CLK virt_prcm_set
-#endif
-
-static struct clk *mpu_clk;
-
-/* TODO: Add support for SDRAM timing changes */
-
-static int omap_verify_speed(struct cpufreq_policy *policy)
-{
- if (freq_table)
- return cpufreq_frequency_table_verify(policy,
freq_table);
-
- if (policy-cpu)
- return -EINVAL;
-
- cpufreq_verify_within_limits(policy, policy-cpuinfo.min_freq,
- policy-cpuinfo.max_freq);
-
- policy-min = clk_round_rate(mpu_clk, policy-min * 1000) /
1000;
- policy-max = clk_round_rate(mpu_clk, policy-max * 1000) /
1000;
- cpufreq_verify_within_limits(policy, policy-cpuinfo.min_freq,
- policy-cpuinfo.max_freq);
- return 0;
-}
-
-static unsigned int omap_getspeed(unsigned int cpu)
-{
- unsigned long rate;
-
- if (cpu)
- return 0;
-
- rate = clk_get_rate(mpu_clk) / 1000;
- return rate;
-}
-
-static int omap_target(struct cpufreq_policy *policy,
-unsigned int target_freq,
-unsigned int relation)
-{
- struct cpufreq_freqs freqs;
- int ret = 0;
-
- /* Ensure desired rate is within allowed range. Some govenors
- * (ondemand) will just pass target_freq=0 to get the minimum.
*/
- if (target_freq policy-min)
- target_freq = policy-min;
- if (target_freq policy-max)
- target_freq = policy-max;
-
- freqs.old = omap_getspeed(0);
- freqs.new = clk_round_rate(mpu_clk, target_freq * 1000) /
1000;
- freqs.cpu = 0;
-
- if (freqs.old == freqs.new)
- return ret;
-
- cpufreq_notify_transition(freqs, CPUFREQ_PRECHANGE);
-#ifdef CONFIG_CPU_FREQ_DEBUG
- printk(KERN_DEBUG cpufreq-omap: transition: %u -- %u\n,
-freqs.old, freqs.new);
-#endif
- ret = clk_set_rate(mpu_clk, freqs.new * 1000);
- cpufreq_notify_transition(freqs, CPUFREQ_POSTCHANGE);
-
- return
Re: [PATCH v16 00/12] OMAP: dmtimer: adaptation to platform_driver
Hi Tony,
[...]
I've applied these into dmtimer branch with some changes to simplify
things further. I've also merged it into linux-omap master branch
for further testing.
I'll reply to your patches with the changes I've done. Care give the
dmtimer branch a try and see if I've missed something?
Sure, I will go through the changes and do testing on it.
Please find the missing/correction in the patch below.
You can include them as part of patch 9.
Thanks.
--
Tarun
From 98cb7949054214684d7361eed2e382fa716ab0da Mon Sep 17 00:00:00 2001
From: Tarun Kanti DebBarma tarun.ka...@ti.com
Date: Fri, 23 Sep 2011 14:48:56 +0530
Subject: [correction] [PATCH 09/12] OMAP: dmtimer: low-power mode support
These are some missing content as well as correction to this patch.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 21 ++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index de7896f..81a2305 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -79,9 +79,9 @@ static void omap_dm_timer_write_reg(struct
omap_dm_timer *timer, u32 reg,
static void omap_timer_restore_context(struct omap_dm_timer *timer)
{
- omap_dm_timer_write_reg(timer, OMAP_TIMER_OCP_CFG_OFFSET,
- timer-context.tiocp_cfg);
- if (timer-revision 1)
+ __raw_writel(timer-context.tiocp_cfg,
+ timer-io_base + OMAP_TIMER_OCP_CFG_OFFSET);
+ if (timer-revision == 1)
__raw_writel(timer-context.tistat, timer-sys_stat);
__raw_writel(timer-context.tisr, timer-irq_stat);
@@ -356,6 +356,21 @@ int omap_dm_timer_stop(struct omap_dm_timer *timer)
__omap_dm_timer_stop(timer, timer-posted, rate);
+ if (timer-loses_context) {
+ if (timer-get_context_loss_count)
+ timer-ctx_loss_count =
+ timer-get_context_loss_count(timer-pdev-dev);
+ }
+
+ /*
+* Since the register values are computed and written within
+* __omap_dm_timer_stop, we need to use read to retrieve the
+* context.
+*/
+ timer-context.tclr =
+ omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG);
+ timer-context.tisr = __raw_readl(timer-irq_stat);
+ omap_dm_timer_disable(timer);
return 0;
}
EXPORT_SYMBOL_GPL(omap_dm_timer_stop);
--
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
[PATCHv3 5/5] OMAPDSS: HDMI: Add support to dump clocks through
From: Mythri P K mythr...@ti.com
Add support to dump the HDMI PLL dividers such as regm, regn etc
and other clock dumps such as pixel clock rate, TMDS clock rate.
changes since V2:
Add pixel clock and TMDS clock dump and remove dcofreq and DISPC clock source
print.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/dss.c |3 +++
drivers/video/omap2/dss/dss.h |1 +
drivers/video/omap2/dss/hdmi.c | 33 +
3 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 3e09726..76e2bcd 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -732,6 +732,9 @@ void dss_debug_dump_clocks(struct seq_file *s)
#ifdef CONFIG_OMAP2_DSS_DSI
dsi_dump_clocks(s);
#endif
+#ifdef CONFIG_OMAP4_DSS_HDMI
+ hdmi_dump_clocks(s);
+#endif
}
#endif
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 8652007..ef8770a 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -473,6 +473,7 @@ void hdmi_uninit_platform_driver(void);
int hdmi_init_display(struct omap_dss_device *dssdev);
unsigned long hdmi_get_pixel_clock(void);
void hdmi_dump_regs(struct seq_file *s);
+void hdmi_dump_clocks(struct seq_file *s);
#else
static inline int hdmi_init_display(struct omap_dss_device *dssdev)
{
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 3262f0f..0510655 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -33,6 +33,8 @@
#include linux/pm_runtime.h
#include linux/clk.h
#include video/omapdss.h
+#include linux/seq_file.h
+
#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
#include sound/soc.h
@@ -454,6 +456,37 @@ void hdmi_dump_regs(struct seq_file *s)
mutex_unlock(hdmi.lock);
}
+void hdmi_dump_clocks(struct seq_file *s)
+{
+ enum omap_dss_clk_source dispc_clk_src;
+
+ dispc_clk_src = dss_get_dispc_clk_source();
+
+ if (hdmi_runtime_get())
+ return;
+
+ seq_printf(s, - HDMI PLL -\n);
+
+ seq_printf(s, hdmi %s source rate = %lu\n,
+ hdmi.ip_data.pll_data.refsel == HDMI_REFSEL_SYSCLK ?
+ sysclk : pclk/ref1/ref2,
+ clk_get_rate(hdmi.sys_clk));
+
+ seq_printf(s, Pixel clock frequency = %u\n,
+ hdmi.ip_data.cfg.timings.timings.pixel_clock);
+
+ seq_printf(s, TMDS clock frequency = %u\n,
+ 10 * hdmi.ip_data.cfg.timings.timings.pixel_clock);
+
+ seq_printf(s, regm\t%u\n, hdmi.ip_data.pll_data.regm);
+
+ seq_printf(s, regmf\t%u\n, hdmi.ip_data.pll_data.regmf);
+
+ seq_printf(s, regsd\t%u\n, hdmi.ip_data.pll_data.regsd);
+
+ hdmi_runtime_put();
+}
+
int omapdss_hdmi_read_edid(u8 *buf, int len)
{
int r;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com wrote:
Hi
a few comments
On Thu, 22 Sep 2011, Keshava Munegowda wrote:
following 4 hwmod structures are added
1. usb_host_hs hwmod of usbhs with uhh base address and functional clock,
2. usb_ehci_hs hwmod with irq and base address,
3. usb_ohci_hs hwmod with irq and base address,
- the ehci and ohci hwmods does not require functional clock
because usb_host_hs has functional clock which is sufficient
to access ehci and ohci address space.
Every hwmod should have a functional clock defined. If they use the same
functional clock as usb_host_hs, then the same main_clk should be listed
for ehci/ohci also.
yes it is right in general convention.
But USB host is different case. :-)
Yes, Ehci and Ohci are embedded within usbhs ; hence they do not need
separate functional clocks.
But the question arises here , why do we need these ehci and ohci as two
different hwmods containing only irq and base address?
It is required for future - to implement remote wakeup feature for ehci
and ohci ports depending on irq-chain handler patches by Tero.
Separate hwmods for ehci and ohci are needed to enable prcm chain-handler
to uniquely identify the wakeup source as ehci or ohci and call only the
corresponding interrupt handler.
We will be using omap_hwmod_mux_init for ehci and ohci hwmods to enable
I/O wakeup capability for respective IO-pads. Depending on the particular
wakeup source(ehci/ohci), the corresponding ehci or ohci irq handler will
be called.
If ehci and ohci are combined with usbhs hwmod as a single hwmod , then
for every wakeup (either ehci or ohci port wakeup) only the first
interrupt handler will be called (please look at the function
omap_hwmod_mux_handle_irq of
/arch/arm/mach-omap2/mux.c file ; in tero's latest patch:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53139.html)
, so in this
case, if ehci interrupt is the first interrupt , then even for ohci wakeup
, only ehci interrupt will get called; which will break the functionality.
4. usb_tll_hs hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 271
1 files changed, 271 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..d79f728 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -84,6 +84,10 @@ static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap34xx_usbhs_ohci_hwmod;
+static struct omap_hwmod omap34xx_usbhs_ehci_hwmod;
+static struct omap_hwmod omap34xx_usb_tll_hs_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -3196,6 +3200,266 @@ static struct omap_hwmod omap3xxx_mmc3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__l3_main_2 = {
+ .master = omap34xx_usb_host_hs_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk = core_l3_ick,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_class_sysconfig omap34xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
This is missing a bunch of SYSC bits, according to Table 24-152
UHH_SYSCONFIG of the 34xx public TRM, version ZR.
some time back i had extended this , but it was causing system resets;
I will check this and add the remaining flags.
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields = omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_usb_host_hs_hwmod_class = {
+ .name = usb_host_hs,
+ .sysc = omap34xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_masters[] = {
+ omap34xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap34xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x48064000,
+ .pa_end = 0x480643ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {}
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_cfg__usb_host_hs = {
+ .master = omap3xxx_l4_core_hwmod,
Re: [PATCHv3 5/5] OMAPDSS: HDMI: Add support to dump clocks through
On Fri, 2011-09-23 at 15:02 +0530, mythr...@ti.com wrote: From: Mythri P K mythr...@ti.com Add support to dump the HDMI PLL dividers such as regm, regn etc and other clock dumps such as pixel clock rate, TMDS clock rate. changes since V2: Add pixel clock and TMDS clock dump and remove dcofreq and DISPC clock source print. Let's drop this fifth patch for now, I think the hdmi pll code needs a bit cleaning up before we can have a good dump clocks support. I'll take the patches 1-4 and apply to dss2 master. Btw, this patch, and the 4th patch, still have broken subject. I guess this is fourth time I mention it. I'll fix it myself in the patches I apply. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH V6 0/4] cpuidle: Global registration of idle states with per-cpu statistics
On Friday 23 September 2011 01:15 AM, Kevin Hilman wrote: Deepthi Dharwar deep...@linux.vnet.ibm.com writes: The following patch series implements global registration of cpuidle states, and also has the necessary data structure changes to accommodate the per-cpu writable members of the cpuidle_states structure. I reviewed earlier versions of the series, and this version still looks good to me. Any reason it is still RFC? Reviewed-by: Kevin Hilman khil...@ti.com and for the OMAP-specific parts, Acked-by: Kevin Hilman khil...@ti.com Kevin Hi Kevin, Thanks for reviewing the patch. This was posted as an RFC, as there were a couple of ToDos listed in this patch series which I thought needed additional review before I could ask for inclusion. To Do : == 1. Russell King pointed out that in (V5 1/4) of this patch in arch/arm/mach-at91/cpuidle.c, AT91 pieces may be broken. In at91_enter_idle() routine, folks need to fix the two consecutive asm() statements by combining it to one as per the GCC reference manual. Reference: https://lkml.org/lkml/2011/6/6/273 2. In (V6 4/4), handle the case when idle states may change at run time and acpi_processor_cst_has_changed() routine is called in a better way than the current solution in this patch. In this current solution where global registration is implemented, the boot cpu on x86 would disable all the devices, repopulate the states and later enable all the devices, irrespective of the cpu that would receive the notification first. Reference: https://lkml.org/lkml/2011/4/25/83 Thanks Regards, -Deepthi -- To unsubscribe from this list: send the line unsubscribe 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: [PATCHv3 5/5] OMAPDSS: HDMI: Add support to dump clocks through
Hi, On Fri, Sep 23, 2011 at 4:15 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Fri, 2011-09-23 at 15:02 +0530, mythr...@ti.com wrote: From: Mythri P K mythr...@ti.com Add support to dump the HDMI PLL dividers such as regm, regn etc and other clock dumps such as pixel clock rate, TMDS clock rate. changes since V2: Add pixel clock and TMDS clock dump and remove dcofreq and DISPC clock source print. Let's drop this fifth patch for now, I think the hdmi pll code needs a bit cleaning up before we can have a good dump clocks support. I'll take the patches 1-4 and apply to dss2 master. Btw, this patch, and the 4th patch, still have broken subject. I guess this is fourth time I mention it. I'll fix it myself in the patches I apply. I shall mail the fourth patch , As only change suggested was subject change, I wanted to send it if this patch was ok. Anyways mailing it to you. Thanks and regards, Mythri. after 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
[PATCHv3 4/4] OMAPDSS: HDMI: Add support to dump registers
From: Mythri P K mythr...@ti.com
Add support to dump the HDMI wrapper, core, PLL and PHY registers
through debugfs.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/core.c|4 +
drivers/video/omap2/dss/dss.h |1 +
drivers/video/omap2/dss/dss_features.c|5 +
drivers/video/omap2/dss/hdmi.c| 16 +++
drivers/video/omap2/dss/ti_hdmi.h | 14 +++
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 173 +
6 files changed, 213 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 76821fe..86ec12e 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -145,6 +145,10 @@ static int dss_initialize_debugfs(void)
debugfs_create_file(venc, S_IRUGO, dss_debugfs_dir,
venc_dump_regs, dss_debug_fops);
#endif
+#ifdef CONFIG_OMAP4_DSS_HDMI
+ debugfs_create_file(hdmi, S_IRUGO, dss_debugfs_dir,
+ hdmi_dump_regs, dss_debug_fops);
+#endif
return 0;
}
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 47eebd8..8652007 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -472,6 +472,7 @@ int hdmi_init_platform_driver(void);
void hdmi_uninit_platform_driver(void);
int hdmi_init_display(struct omap_dss_device *dssdev);
unsigned long hdmi_get_pixel_clock(void);
+void hdmi_dump_regs(struct seq_file *s);
#else
static inline int hdmi_init_display(struct omap_dss_device *dssdev)
{
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index 47e66d8..a2fc8e0 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -447,6 +447,11 @@ static const struct ti_hdmi_ip_ops omap4_hdmi_functions = {
.pll_enable = ti_hdmi_4xxx_pll_enable,
.pll_disable= ti_hdmi_4xxx_pll_disable,
.video_enable = ti_hdmi_4xxx_wp_video_start,
+ .dump_wrapper = ti_hdmi_4xxx_wp_dump,
+ .dump_core = ti_hdmi_4xxx_core_dump,
+ .dump_pll = ti_hdmi_4xxx_pll_dump,
+ .dump_phy = ti_hdmi_4xxx_phy_dump,
+
};
void dss_init_hdmi_ip_ops(struct hdmi_ip_data *ip_data)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 2f554ae..3262f0f 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -438,6 +438,22 @@ void omapdss_hdmi_display_set_timing(struct
omap_dss_device *dssdev)
}
}
+void hdmi_dump_regs(struct seq_file *s)
+{
+ mutex_lock(hdmi.lock);
+
+ if (hdmi_runtime_get())
+ return;
+
+ hdmi.ip_data.ops-dump_wrapper(hdmi.ip_data, s);
+ hdmi.ip_data.ops-dump_pll(hdmi.ip_data, s);
+ hdmi.ip_data.ops-dump_phy(hdmi.ip_data, s);
+ hdmi.ip_data.ops-dump_core(hdmi.ip_data, s);
+
+ hdmi_runtime_put();
+ mutex_unlock(hdmi.lock);
+}
+
int omapdss_hdmi_read_edid(u8 *buf, int len)
{
int r;
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index d48603c..2c3443d 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -101,6 +101,15 @@ struct ti_hdmi_ip_ops {
void (*pll_disable)(struct hdmi_ip_data *ip_data);
void (*video_enable)(struct hdmi_ip_data *ip_data, bool start);
+
+ void (*dump_wrapper)(struct hdmi_ip_data *ip_data, struct seq_file *s);
+
+ void (*dump_core)(struct hdmi_ip_data *ip_data, struct seq_file *s);
+
+ void (*dump_pll)(struct hdmi_ip_data *ip_data, struct seq_file *s);
+
+ void (*dump_phy)(struct hdmi_ip_data *ip_data, struct seq_file *s);
+
};
struct hdmi_ip_data {
@@ -121,4 +130,9 @@ void ti_hdmi_4xxx_wp_video_start(struct hdmi_ip_data
*ip_data, bool start);
int ti_hdmi_4xxx_pll_enable(struct hdmi_ip_data *ip_data);
void ti_hdmi_4xxx_pll_disable(struct hdmi_ip_data *ip_data);
void ti_hdmi_4xxx_basic_configure(struct hdmi_ip_data *ip_data);
+void ti_hdmi_4xxx_wp_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
+void ti_hdmi_4xxx_pll_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
+void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
+void ti_hdmi_4xxx_phy_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
+
#endif
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 5f22d2e..e1a6ce5 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -27,6 +27,7 @@
#include linux/mutex.h
#include linux/delay.h
#include linux/string.h
+#include linux/seq_file.h
#include ti_hdmi_4xxx_ip.h
#include dss.h
@@ -805,6 +806,178 @@ void ti_hdmi_4xxx_basic_configure(struct hdmi_ip_data
*ip_data)
Re: [PATCH 1/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap4
So I'd suggest one of two approaches: 1. If the pin muxing can follow the PM runtime status of the UHH IP block, then the pin mux data should be associated with the UHH hwmod. No, the mux is applicable only to ehci and ohci , where as sysconfig is applicable to uhh ( usb_host_hs class). 2. If the pin muxing must follow the EHCI/OHCI IP block PM runtime status, then drivers/mfd/omap-usb-host.c is what should be handling the remuxing. omap-usb-host.c can set the dev_pm_ops of the EHCI/OHCI platform_devices to point to functions either in arch/arm/mach-omap2/usb-host.c, or local functions that call into mach-omap2/usb-host.c functions to handle pin remuxing. (Those function pointers should be provided to the MFD driver in some clean way, like via platform_data.) The dev_pm_ops of ehci should exist in /drivers/usb/host/ehci-omap.c and dev_pm_ops of phci should exist in /drivers/usb/host/ohci-omap3.c. In the existing design, the omap-usb-host.c host can not access the platform driver of ehci and ohci. But, through function pointers it is possible to send the platform data to ehci and ohci drivers to handle pin remuxing; but we will not able to use tero's patches; and it will prevent our future design activity for remote wakeup of ehci and ohci. please let me know if you have thoughts on this. Regards Keshava -- To unsubscribe from this list: send the line unsubscribe 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 4/5] ispccdc: Configure CCDC_SYN_MODE register for UYVY8_2X8 and YUYV8_2X8 formats
From: Laurent Pinchart [laurent.pinch...@ideasonboard.com]
Sent: Wednesday, September 21, 2011 2:36 PM
To: Ravi, Deepthy
Cc: mche...@infradead.org; t...@atomide.com; Hiremath, Vaibhav;
linux-me...@vger.kernel.org; li...@arm.linux.org.uk;
linux-arm-ker...@lists.infradead.org; kyungmin.p...@samsung.com;
hverk...@xs4all.nl; m.szyprow...@samsung.com; g.liakhovet...@gmx.de;
Shilimkar, Santosh; khil...@deeprootsystems.com; david.woodho...@intel.com;
a...@linux-foundation.org; linux-ker...@vger.kernel.org;
linux-omap@vger.kernel.org; Sakari Ailus
Subject: Re: [PATCH 4/5] ispccdc: Configure CCDC_SYN_MODE register for
UYVY8_2X8 and YUYV8_2X8 formats
Hi Deepthy,
On Wednesday 21 September 2011 07:32:44 Ravi, Deepthy wrote:
On Wednesday, September 21, 2011 4:56 AM Laurent Pinchart wrote:
On Tuesday 20 September 2011 16:56:51 Deepthy Ravi wrote:
Configure INPMOD and PACK8 fileds of CCDC_SYN_MODE
register for UYVY8_2X8 and YUYV8_2X8 formats.
Signed-off-by: Deepthy Ravi deepthy.r...@ti.com
---
drivers/media/video/omap3isp/ispccdc.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispccdc.c
b/drivers/media/video/omap3isp/ispccdc.c index 418ba65..1dcf180 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -985,8 +985,12 @@ static void ccdc_config_sync_if(struct
isp_ccdc_device
*ccdc,
syn_mode = ~ISPCCDC_SYN_MODE_INPMOD_MASK;
if (format-code == V4L2_MBUS_FMT_YUYV8_2X8 ||
- format-code == V4L2_MBUS_FMT_UYVY8_2X8)
- syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR8;
+ format-code == V4L2_MBUS_FMT_UYVY8_2X8){
+ if (pdata pdata-bt656)
+ syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR8;
+ else
+ syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR16;
+ }
else if (format-code == V4L2_MBUS_FMT_YUYV8_1X16 ||
format-code == V4L2_MBUS_FMT_UYVY8_1X16)
syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR16;
@@ -1172,7 +1176,8 @@ static void ccdc_configure(struct isp_ccdc_device
*ccdc) syn_mode = ~ISPCCDC_SYN_MODE_SDR2RSZ;
/* Use PACK8 mode for 1byte per pixel formats. */
- if (omap3isp_video_format_info(format-code)-width = 8)
+ if ((omap3isp_video_format_info(format-code)-width = 8)
+ (omap3isp_video_format_info(format-code)-bpp =
8))
I'm not sure to follow you. This will clear the PACK8 bit for the
YUYV8_2X8 formats. Those formats are 8 bits wide, shouldn't PACK8 be set
to store samples on 8 bits instead of 16 bits ?
Is this patch intended to support YUYV8_2X8 sensors in non BT.656 mode
with the bridge enabled ? In that case, what would you think about setting
the CCDC input format to YUYV8_1X16 instead ? This would better reflect
the reality, as the bridge converts YUYV8_2X8 to YUYV8_1X16, and the CCDC
is then fed with YUYV8_1X16.
Yes this is intended for YUYV8_2X8 sensors in non BT.656 with 8 to 16 bit
bridge enabled. So the data has to be stored as 16 bits per sample. Thats
why PACK8 is cleared . I am not sure about using YUYV8_1X16.
My original idea when I wrote the YV support patches was to implement this use
case with YUYV8_2X8 at the sensor output and YUYV8_1X16 at the CCDC input. The
ISP driver could then enable the bridge automatically. I'm not sure if that's
the best solution though, it might be confusing for the users. What I would
like to keep, however, is the idea of enabling the bridge automatically.
[Deepthy Ravi] But for streaming to start, the formats on both ends of the link
should match. I believe setting different formats at sensor output and ccdc
input will give a broken pipe error. Is my understanding correct ? If so, how
do you propose to handle the situation ?
Sakari, any opinion on this ?
syn_mode |= ISPCCDC_SYN_MODE_PACK8;
else
syn_mode = ~ISPCCDC_SYN_MODE_PACK8;
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 1/3] AM35x: voltage: Basic initialization
hi Kevin
On Fri, Sep 23, 2011 at 4:00 AM, Hilman, Kevin wrote:
Hi Abhilash,
Abhilash K V abhilash...@ti.com writes:
This patch adds the basic initialization of voltage layer
for AM35x. Since AM35x doesn't support voltage scaling,
I must admit to still being confused by this series.
This patch says AM35x doesn't support voltage scaling, and the next
patch adds PMIC support, and registers it with the voltage layer.
However, with each voltdm-scalable flag set to false, none of the PMIC
values will ever be used (by the current voltage layer.) Do you have
more patches on top of this that extend the voltage layer to directly
use the PMIC instead of using VC or VP?
I'm assuming we have some more assumptions in our current voltage layer
about the presence of VC/VP that are wrong and need to be fixed. Now
that the big voltage layer cleanup is done, I am *very* interested in
getting rid of any more assumptions we have in that code about how
devices are hooked up with PMICs.
Can you summarize how these devices are using (or want to use) the
voltage layer?
[Abhilash K V] Your concerns are grave and am trying to address most,
however these are the only points I can make outright:
- AM35x has just one voltage domain, so I tried having only one entry in
voltagedomains_omap3[ ] ( and calling it mpu_core, maybe or mpu or core
?).
Either ways, some power-domain, say mpu_pwrdm would try looking for the
mpu_iva
volt-domain and return error, this happens for most powerdomains as their
constituent
volt-domains are hard-coded (and so unavailable on am35xx). Changing the code
(which
will be massive) there going against our initial premise that am35xx is still a
type of
omap3 SoC.
- TPS65023 PMIC code was originally included as a starting point to support a
omap34xx
(with SR disabled maybe) with power supplied by a TPS65023. Yes,I agree that
since
this looks more of like hypothetical scenario right now and so we can do
without the addition of file pmic_tps65023.c for now as it doesn't provide any
support for
scaling.
-Abhilash
Thanks,
Kevin
Many functions have been defined to plug into existing
voltage layer.
Signed-off-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Abhilash K V abhilash...@ti.com
---
arch/arm/mach-omap2/omap_opp_data.h |1 +
arch/arm/mach-omap2/opp3xxx_data.c|9 +
arch/arm/mach-omap2/voltagedomains3xxx_data.c | 10 --
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_opp_data.h
b/arch/arm/mach-omap2/omap_opp_data.h
index c784c12..c7cedf3 100644
--- a/arch/arm/mach-omap2/omap_opp_data.h
+++ b/arch/arm/mach-omap2/omap_opp_data.h
@@ -88,6 +88,7 @@ extern struct omap_volt_data omap34xx_vddmpu_volt_data[];
extern struct omap_volt_data omap34xx_vddcore_volt_data[];
extern struct omap_volt_data omap36xx_vddmpu_volt_data[];
extern struct omap_volt_data omap36xx_vddcore_volt_data[];
+extern struct omap_volt_data am35xx_vdd_volt_data[];
extern struct omap_volt_data omap44xx_vdd_mpu_volt_data[];
extern struct omap_volt_data omap44xx_vdd_iva_volt_data[];
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
b/arch/arm/mach-omap2/opp3xxx_data.c
index d95f3f9..e4a5ee6 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -85,6 +85,15 @@ struct omap_volt_data omap36xx_vddcore_volt_data[] = {
VOLT_DATA_DEFINE(0, 0, 0, 0),
};
+/* AM35x
+ *
+ * Fields related to SmartReflex and Voltage Processor are set to 0.
+ */
fix multi-line comment style (search for 'multi-line' in
Documentation/CodingStyle)
+struct omap_volt_data am35xx_vdd_volt_data[] = {
+ VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP3_UV, 0x0, 0x0, 0x0),
+ VOLT_DATA_DEFINE(0, 0, 0, 0),
+};
+
/* OPP data */
static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
diff --git a/arch/arm/mach-omap2/voltagedomains3xxx_data.c
b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
index 071101d..530082f 100644
--- a/arch/arm/mach-omap2/voltagedomains3xxx_data.c
+++ b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
@@ -85,7 +85,10 @@ void __init omap3xxx_voltagedomains_init(void)
* XXX Will depend on the process, validation, and binning
* for the currently-running IC
*/
- if (cpu_is_omap3630()) {
+ if (cpu_is_omap3505() || cpu_is_omap3517()) {
+ omap3_voltdm_mpu.volt_data = am35xx_vdd_volt_data;
+ omap3_voltdm_core.volt_data = am35xx_vdd_volt_data;
+ } else if (cpu_is_omap3630()) {
omap3_voltdm_mpu.volt_data = omap36xx_vddmpu_volt_data;
omap3_voltdm_core.volt_data = omap36xx_vddcore_volt_data;
} else {
@@ -93,8 +96,11 @@ void __init omap3xxx_voltagedomains_init(void)
omap3_voltdm_core.volt_data = omap34xx_vddcore_volt_data;
}
- for (i = 0; voltdm = voltagedomains_omap3[i], voltdm; i++)
+ for (i = 0; voltdm
[PATCHv9 00/18] omap PRCM chain handler
Hello, Following set contains the version 9 of this work. This patch set contains a number of patches tagged as 'TEMP', they are only meant for testing purposes and to provide proof of concept. Most of the 'TEMP' patches are related to UART runtime handling and they will be replaced by work done by Govindraj Raja. As this is a new set sent to linux-arm and linux-kernel lists, the basic concept being tackled with this set is to provide a mechanism for multiple drivers to register for PRCM interrupts. PRCM interrupt contains a SoC depenpend number of events, which of most interesting ones are wakeup and IO chain. These are the only supported events in the driver currently, but it is possible to add more by tweaking omap3xxx-prm.c and omap4xxx-prm.c files. This driver should also be expanded later to contain much of the code currently included within the OMAP voltage framework, which resides under arch/arm/mach-omap2/voltage*,vc*,vp*. Changes compared to previous version of this set: - PRM driver is now moved under /drivers/mfd - PRM driver split into three parts now, common, omap3 and omap4 - version of the driver to init is detected based on PRM version (patch 11) - cleaned up the initialization logic a bit (platform device is built separately, provide two different drivers) - renamed PRM hwmods as prm3xxx and prm4xxx These patches have been tested on omap3 beagle and omap4 blaze platforms. Tested features include suspend and dynamic idle. Tested trees are available at: g...@gitorious.org:~kristo/omap-pm/omap-pm-work.git branches: omap3_prcm_chain and omap4_prcm_chain -Tero Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv9 01/18] OMAP2+: hwmod: Add API to enable IO ring wakeup.
From: R, Govindraj govindraj.r...@ti.com
Add API to enable IO pad wakeup capability based on mux dynamic pad and
wake_up enable flag available from hwmod_mux initialization.
Use the wakeup_enable flag and enable wakeup capability
for the given pads. Wakeup capability will be enabled/disabled
during hwmod idle transition based on whether wakeup_flag is
set or cleared.
Map the enable/disable pad wakeup API's to hwmod_wakeup_enable/disable.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 59 ++
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 84cc0bd..e751dd9 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2062,6 +2062,34 @@ static int __init omap_hwmod_setup_all(void)
core_initcall(omap_hwmod_setup_all);
/**
+ * omap_hwmod_set_ioring_wakeup - enable io pad wakeup flag.
+ * @oh: struct omap_hwmod *
+ * @set: bool value indicating to set or clear wakeup status.
+ *
+ * Set or Clear wakeup flag for the io_pad.
+ */
+static int omap_hwmod_set_ioring_wakeup(struct omap_hwmod *oh, bool set_wake)
+{
+ struct omap_device_pad *pad;
+ int ret = -EINVAL, j;
+
+ if (oh-mux oh-mux-enabled) {
+ for (j = 0; j oh-mux-nr_pads_dynamic; j++) {
+ pad = oh-mux-pads_dynamic[j];
+ if (pad-flags OMAP_DEVICE_PAD_WAKEUP) {
+ if (set_wake)
+ pad-idle |= OMAP_WAKEUP_EN;
+ else
+ pad-idle = ~OMAP_WAKEUP_EN;
+ ret = 0;
+ }
+ }
+ }
+
+ return ret;
+}
+
+/**
* omap_hwmod_enable - enable an omap_hwmod
* @oh: struct omap_hwmod *
*
@@ -2393,6 +2421,35 @@ int omap_hwmod_del_initiator_dep(struct omap_hwmod *oh,
{
return _del_initiator_dep(oh, init_oh);
}
+/**
+ * omap_hwmod_enable_ioring_wakeup - Set wakeup flag for iopad.
+ * @oh: struct omap_hwmod *
+ *
+ * Traverse through dynamic pads, if pad is enabled then
+ * set wakeup enable bit flag for the mux pin. Wakeup pad bit
+ * will be set during hwmod idle transistion.
+ * Return error if pads are not enabled or not available.
+ */
+int omap_hwmod_enable_ioring_wakeup(struct omap_hwmod *oh)
+{
+ /* Enable pad wake-up capability */
+ return omap_hwmod_set_ioring_wakeup(oh, true);
+}
+
+/**
+ * omap_hwmod_disable_ioring_wakeup - Clear wakeup flag for iopad.
+ * @oh: struct omap_hwmod *
+ *
+ * Traverse through dynamic pads, if pad is enabled then
+ * clear wakeup enable bit flag for the mux pin. Wakeup pad bit
+ * will be set during hwmod idle transistion.
+ * Return error if pads are not enabled or not available.
+ */
+int omap_hwmod_disable_ioring_wakeup(struct omap_hwmod *oh)
+{
+ /* Disable pad wakeup capability */
+ return omap_hwmod_set_ioring_wakeup(oh, false);
+}
/**
* omap_hwmod_enable_wakeup - allow device to wake up the system
@@ -2419,6 +2476,7 @@ int omap_hwmod_enable_wakeup(struct omap_hwmod *oh)
v = oh-_sysc_cache;
_enable_wakeup(oh, v);
_write_sysconfig(v, oh);
+ omap_hwmod_enable_ioring_wakeup(oh);
spin_unlock_irqrestore(oh-_lock, flags);
return 0;
@@ -2449,6 +2507,7 @@ int omap_hwmod_disable_wakeup(struct omap_hwmod *oh)
v = oh-_sysc_cache;
_disable_wakeup(oh, v);
_write_sysconfig(v, oh);
+ omap_hwmod_disable_ioring_wakeup(oh);
spin_unlock_irqrestore(oh-_lock, flags);
return 0;
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv9 02/18] OMAP2+: hwmod: Add API to check IO PAD wakeup status
From: R, Govindraj govindraj.r...@ti.com
Add API to determine IO-PAD wakeup event status for a given
hwmod dynamic_mux pad.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/mux.c| 30 ++
arch/arm/mach-omap2/mux.h| 13 +++
arch/arm/mach-omap2/omap_hwmod.c |7 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
4 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index c7fb22a..50ee806 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -351,6 +351,36 @@ err1:
return NULL;
}
+/**
+ * omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup
+ * @hmux: Pads for a hwmod
+ *
+ * Gets the wakeup status of given pad from omap-hwmod.
+ * Returns true if wakeup event is set for pad else false
+ * if wakeup is not occured or pads are not avialable.
+ */
+bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
+{
+ int i;
+ unsigned int val;
+ u8 ret = false;
+
+ for (i = 0; i hmux-nr_pads; i++) {
+ struct omap_device_pad *pad = hmux-pads[i];
+
+ if (pad-flags OMAP_DEVICE_PAD_WAKEUP) {
+ val = omap_mux_read(pad-partition,
+ pad-mux-reg_offset);
+ if (val OMAP_WAKEUP_EVENT) {
+ ret = true;
+ break;
+ }
+ }
+ }
+
+ return ret;
+}
+
/* Assumes the calling function takes care of locking */
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state)
{
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 2132308..8b2150a 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -225,8 +225,21 @@ omap_hwmod_mux_init(struct omap_device_pad *bpads, int
nr_pads);
*/
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state);
+/**
+ * omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup
+ * @hmux: Pads for a hwmod
+ *
+ * Called only from omap_hwmod.c, do not use.
+ */
+bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux);
#else
+static inline bool
+omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
+{
+ return 0;
+}
+
static inline int omap_mux_init_gpio(int gpio, int val)
{
return 0;
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e751dd9..a8b24d7 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2724,3 +2724,10 @@ int omap_hwmod_no_setup_reset(struct omap_hwmod *oh)
return 0;
}
+
+int omap_hwmod_pad_get_wakeup_status(struct omap_hwmod *oh)
+{
+ if (oh oh-mux)
+ return omap_hwmod_mux_get_wake_status(oh-mux);
+ return -EINVAL;
+}
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 38ac4af..9c70cc8 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -606,6 +606,7 @@ u32 omap_hwmod_get_context_loss_count(struct omap_hwmod
*oh);
int omap_hwmod_no_setup_reset(struct omap_hwmod *oh);
+int omap_hwmod_pad_get_wakeup_status(struct omap_hwmod *oh);
/*
* Chip variant-specific hwmod init routines - XXX should be converted
* to use initcalls once the initial boot ordering is straightened out
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv9 06/18] mfd: omap-prm: added chain interrupt handler
Introduce a chained interrupt handler mechanism for the PRCM
interrupt, so that individual PRCM event can cleanly be handled by
handlers in separate drivers. We do this by introducing PRCM event
names, which are then matched to the particular PRCM interrupt bit
depending on the specific OMAP SoC being used.
PRCM interrupts have two priority levels, high or normal. High priority
is needed for IO event handling, so that we can be sure that IO events
are processed before other events. This reduces latency for IO event
customers and also prevents incorrect ack sequence on OMAP3.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Cc: Avinash.H.M avinas...@ti.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Govindraj.R govindraj.r...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
drivers/mfd/omap-prm-common.c | 239 +
drivers/mfd/omap-prm.h| 40 +++
drivers/mfd/omap3xxx-prm.c| 29 +-
drivers/mfd/omap4xxx-prm.c| 28 +-
4 files changed, 334 insertions(+), 2 deletions(-)
create mode 100644 drivers/mfd/omap-prm.h
diff --git a/drivers/mfd/omap-prm-common.c b/drivers/mfd/omap-prm-common.c
index 39b199c8..2886eb2 100644
--- a/drivers/mfd/omap-prm-common.c
+++ b/drivers/mfd/omap-prm-common.c
@@ -15,10 +15,249 @@
#include linux/ctype.h
#include linux/module.h
#include linux/io.h
+#include linux/irq.h
+#include linux/interrupt.h
#include linux/slab.h
#include linux/init.h
#include linux/err.h
+#include omap-prm.h
+
+#define OMAP_PRCM_MAX_NR_PENDING_REG 2
+
+struct omap_prm_device {
+ const struct omap_prcm_irq_setup *irq_setup;
+ const struct omap_prcm_irq *irqs;
+ struct irq_chip_generic **irq_chips;
+ int nr_irqs;
+ u32 *saved_mask;
+ u32 *priority_mask;
+ int base_irq;
+ int irq;
+ void __iomem *base;
+};
+
+static struct omap_prm_device prm_dev;
+
+static inline u32 prm_read_reg(int offset)
+{
+ return __raw_readl(prm_dev.base + offset);
+}
+
+static inline void prm_write_reg(u32 value, int offset)
+{
+ __raw_writel(value, prm_dev.base + offset);
+}
+
+static void prm_pending_events(unsigned long *events)
+{
+ u32 mask, st;
+ int i;
+
+ memset(events, 0, prm_dev.irq_setup-nr_regs * sizeof(unsigned long));
+
+ for (i = 0; i prm_dev.irq_setup-nr_regs; i++) {
+ mask = prm_read_reg(prm_dev.irq_setup-mask + i * 4);
+ st = prm_read_reg(prm_dev.irq_setup-ack + i * 4);
+ events[i] = mask st;
+ }
+}
+
+/*
+ * Move priority events from events to priority_events array
+ */
+static void prm_events_filter_priority(unsigned long *events,
+ unsigned long *priority_events)
+{
+ int i;
+
+ for (i = 0; i prm_dev.irq_setup-nr_regs; i++) {
+ priority_events[i] = events[i] prm_dev.priority_mask[i];
+ events[i] ^= priority_events[i];
+ }
+}
+
+/*
+ * PRCM Interrupt Handler
+ *
+ * This is a common handler for the OMAP PRCM interrupts. Pending
+ * interrupts are detected by a call to prm_pending_events and
+ * dispatched accordingly. Clearing of the wakeup events should be
+ * done by the SoC specific individual handlers.
+ */
+static void prcm_irq_handler(unsigned int irq, struct irq_desc *desc)
+{
+ unsigned long pending[OMAP_PRCM_MAX_NR_PENDING_REG];
+ unsigned long priority_pending[OMAP_PRCM_MAX_NR_PENDING_REG];
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ unsigned int virtirq;
+ int nr_irqs = prm_dev.irq_setup-nr_regs * 32;
+
+ /*
+* Loop until all pending irqs are handled, since
+* generic_handle_irq() can cause new irqs to come
+*/
+ while (1) {
+ prm_pending_events(pending);
+
+ /* No bit set, then all IRQs are handled */
+ if (find_first_bit(pending, nr_irqs) = nr_irqs)
+ break;
+
+ prm_events_filter_priority(pending, priority_pending);
+
+ /*
+* Loop on all currently pending irqs so that new irqs
+* cannot starve previously pending irqs
+*/
+
+ /* Serve priority events first */
+ for_each_set_bit(virtirq, priority_pending, nr_irqs)
+ generic_handle_irq(prm_dev.base_irq + virtirq);
+
+ /* Serve normal events next */
+ for_each_set_bit(virtirq, pending, nr_irqs)
+ generic_handle_irq(prm_dev.base_irq + virtirq);
+ }
+ if (chip-irq_ack)
+ chip-irq_ack(desc-irq_data);
+ if (chip-irq_eoi)
+ chip-irq_eoi(desc-irq_data);
+ chip-irq_unmask(desc-irq_data);
+}
+
+/*
+ * Given a PRCM event name, returns the corresponding IRQ on which the
+ * handler should be registered.
+ */
+int omap_prcm_event_to_irq(const char
[PATCHv9 09/18] omap3: pm: use prcm chain handler
PM interrupt handling is now done through the PRCM chain handler. The
interrupt handling logic is also split in two parts, to server IO and
WKUP events separately. This allows us to handle IO chain events in a
clean way.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 104 +++---
1 files changed, 37 insertions(+), 67 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7255d9b..712fd15 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -29,6 +29,7 @@
#include linux/delay.h
#include linux/slab.h
#include linux/console.h
+#include linux/mfd/omap-prm.h
#include trace/events/power.h
#include asm/suspend.h
@@ -198,7 +199,7 @@ static void omap3_save_secure_ram_context(void)
* that any peripheral wake-up events occurring while attempting to
* clear the PM_WKST_x are detected and cleared.
*/
-static int prcm_clear_mod_irqs(s16 module, u8 regs)
+static int prcm_clear_mod_irqs(s16 module, u8 regs, u32 ignore_bits)
{
u32 wkst, fclk, iclk, clken;
u16 wkst_off = (regs == 3) ? OMAP3430ES2_PM_WKST3 : PM_WKST1;
@@ -210,6 +211,7 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs)
wkst = omap2_prm_read_mod_reg(module, wkst_off);
wkst = omap2_prm_read_mod_reg(module, grpsel_off);
+ wkst = ~ignore_bits;
if (wkst) {
iclk = omap2_cm_read_mod_reg(module, iclk_off);
fclk = omap2_cm_read_mod_reg(module, fclk_off);
@@ -225,6 +227,7 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs)
omap2_cm_set_mod_reg_bits(clken, module, fclk_off);
omap2_prm_write_mod_reg(wkst, module, wkst_off);
wkst = omap2_prm_read_mod_reg(module, wkst_off);
+ wkst = ~ignore_bits;
c++;
}
omap2_cm_write_mod_reg(iclk, module, iclk_off);
@@ -234,76 +237,35 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs)
return c;
}
-static int _prcm_int_handle_wakeup(void)
+static irqreturn_t _prcm_int_handle_io(int irq, void *unused)
{
int c;
- c = prcm_clear_mod_irqs(WKUP_MOD, 1);
- c += prcm_clear_mod_irqs(CORE_MOD, 1);
- c += prcm_clear_mod_irqs(OMAP3430_PER_MOD, 1);
- if (omap_rev() OMAP3430_REV_ES1_0) {
- c += prcm_clear_mod_irqs(CORE_MOD, 3);
- c += prcm_clear_mod_irqs(OMAP3430ES2_USBHOST_MOD, 1);
- }
+ c = prcm_clear_mod_irqs(WKUP_MOD, 1,
+ ~(OMAP3430_ST_IO_MASK | OMAP3430_ST_IO_CHAIN_MASK));
- return c;
+ return c ? IRQ_HANDLED : IRQ_NONE;
}
-/*
- * PRCM Interrupt Handler
- *
- * The PRM_IRQSTATUS_MPU register indicates if there are any pending
- * interrupts from the PRCM for the MPU. These bits must be cleared in
- * order to clear the PRCM interrupt. The PRCM interrupt handler is
- * implemented to simply clear the PRM_IRQSTATUS_MPU in order to clear
- * the PRCM interrupt. Please note that bit 0 of the PRM_IRQSTATUS_MPU
- * register indicates that a wake-up event is pending for the MPU and
- * this bit can only be cleared if the all the wake-up events latched
- * in the various PM_WKST_x registers have been cleared. The interrupt
- * handler is implemented using a do-while loop so that if a wake-up
- * event occurred during the processing of the prcm interrupt handler
- * (setting a bit in the corresponding PM_WKST_x register and thus
- * preventing us from clearing bit 0 of the PRM_IRQSTATUS_MPU register)
- * this would be handled.
- */
-static irqreturn_t prcm_interrupt_handler (int irq, void *dev_id)
+static irqreturn_t _prcm_int_handle_wakeup(int irq, void *unused)
{
- u32 irqenable_mpu, irqstatus_mpu;
- int c = 0;
-
- irqenable_mpu = omap2_prm_read_mod_reg(OCP_MOD,
-OMAP3_PRM_IRQENABLE_MPU_OFFSET);
- irqstatus_mpu = omap2_prm_read_mod_reg(OCP_MOD,
-OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
- irqstatus_mpu = irqenable_mpu;
-
- do {
- if (irqstatus_mpu (OMAP3430_WKUP_ST_MASK |
-OMAP3430_IO_ST_MASK)) {
- c = _prcm_int_handle_wakeup();
-
- /*
-* Is the MPU PRCM interrupt handler racing with the
-* IVA2 PRCM interrupt handler ?
-*/
- WARN(c == 0, prcm: WARNING: PRCM indicated MPU wakeup
-but no wakeup sources are marked\n);
- } else {
- /* XXX we need to expand our PRCM interrupt handler */
- WARN(1, prcm: WARNING: PRCM interrupt received, but
-no code to handle it (%08x)\n, irqstatus_mpu);
- }
-
-
[PATCHv9 13/18] TEMP: 4430sdp: use common serial init with mux support
Temporary testing related patch, not meant for integration.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index c7cef44..f1151e8 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -737,17 +737,7 @@ static struct omap_board_data serial4_data __initdata = {
static inline void board_serial_init(void)
{
- struct omap_board_data bdata;
- bdata.flags = 0;
- bdata.pads = NULL;
- bdata.pads_cnt = 0;
- bdata.id= 0;
- /* pass dummy data for UART1 */
- omap_serial_init_port(bdata);
-
- omap_serial_init_port(serial2_data);
- omap_serial_init_port(serial3_data);
- omap_serial_init_port(serial4_data);
+ omap_serial_init();
}
#else
#define board_mux NULL
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv9 10/18] OMAP3: pm: do not enable PRCM MPU interrupts manually
This is handled automatically by the PRCM chain interrupt mechanism now. Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/pm34xx.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 712fd15..4bbf1cd 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -661,10 +661,6 @@ static void __init prcm_setup_regs(void) OMAP3430_GRPSEL_GPT1_MASK | OMAP3430_GRPSEL_GPT12_MASK, WKUP_MOD, OMAP3430_PM_MPUGRPSEL); - /* For some reason IO doesn't generate wakeup event even if -* it is selected to mpu wakeup goup */ - omap2_prm_write_mod_reg(OMAP3430_IO_EN_MASK | OMAP3430_WKUP_EN_MASK, - OCP_MOD, OMAP3_PRM_IRQENABLE_MPU_OFFSET); /* Enable PM_WKEN to support DSS LPR */ omap2_prm_write_mod_reg(OMAP3430_PM_WKEN_DSS_EN_DSS_MASK, -- 1.7.4.1 Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv9 18/18] TEMP: OMAP device: change pr_warnings to pr_debugs
Prevents a hang when omap_device would want to print something for serial console device while enabling / disabling its clocks. Should be handled properly by serial runtime PM support. Signed-off-by: Tero Kristo t-kri...@ti.com Cc: Govindraj.R govindraj.r...@ti.com --- arch/arm/plat-omap/omap_device.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index d8f2299..ecec0cc 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -154,7 +154,7 @@ static int _omap_device_activate(struct omap_device *od, u8 ignore_lat) %d: %llu\n, od-pm_lat_level, act_lat); } else - dev_warn(od-pdev-dev, + dev_dbg(od-pdev-dev, activate latency %d higher than exptected. (%llu %d)\n, od-pm_lat_level, act_lat, @@ -221,7 +221,7 @@ static int _omap_device_deactivate(struct omap_device *od, u8 ignore_lat) %d: %llu\n, od-pm_lat_level, deact_lat); } else - dev_warn(od-pdev-dev, + dev_dbg(od-pdev-dev, deactivate latency %d higher than exptected. (%llu %d)\n, od-pm_lat_level, deact_lat, -- 1.7.4.1 Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv9 17/18] TEMP: OMAP: serial: remove padconf hacks
These are no longer needed as omap_hwmod takes care of multiplexing of pads.
Should be handled properly with serial runtime PM support patches.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 25 +
1 files changed, 1 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0cc5434..cdcdd83 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -73,7 +73,6 @@ struct omap_uart_state {
void __iomem *wk_st;
void __iomem *wk_en;
u32 wk_mask;
- u32 padconf;
u32 dma_enabled;
struct clk *ick;
@@ -309,13 +308,6 @@ static void omap_uart_enable_wakeup(struct omap_uart_state
*uart)
v |= uart-wk_mask;
__raw_writel(v, uart-wk_en);
}
-
- /* Ensure IOPAD wake-enables are set */
- if (cpu_is_omap34xx() uart-padconf) {
- u16 v = omap_ctrl_readw(uart-padconf);
- v |= OMAP3_PADCONF_WAKEUPENABLE0;
- omap_ctrl_writew(v, uart-padconf);
- }
}
static void omap_uart_disable_wakeup(struct omap_uart_state *uart)
@@ -326,13 +318,6 @@ static void omap_uart_disable_wakeup(struct
omap_uart_state *uart)
v = ~uart-wk_mask;
__raw_writel(v, uart-wk_en);
}
-
- /* Ensure IOPAD wake-enables are cleared */
- if (cpu_is_omap34xx() uart-padconf) {
- u16 v = omap_ctrl_readw(uart-padconf);
- v = ~OMAP3_PADCONF_WAKEUPENABLE0;
- omap_ctrl_writew(v, uart-padconf);
- }
}
static void omap_uart_smart_idle_enable(struct omap_uart_state *uart,
@@ -478,7 +463,6 @@ static void omap_uart_idle_init(struct omap_uart_state
*uart)
if (cpu_is_omap34xx() !cpu_is_ti816x()) {
u32 mod = (uart-num 1) ? OMAP3430_PER_MOD : CORE_MOD;
u32 wk_mask = 0;
- u32 padconf = 0;
/* XXX These PRM accesses do not belong here */
uart-wk_en = OMAP34XX_PRM_REGADDR(mod, PM_WKEN1);
@@ -486,23 +470,18 @@ static void omap_uart_idle_init(struct omap_uart_state
*uart)
switch (uart-num) {
case 0:
wk_mask = OMAP3430_ST_UART1_MASK;
- padconf = 0x182;
break;
case 1:
wk_mask = OMAP3430_ST_UART2_MASK;
- padconf = 0x17a;
break;
case 2:
wk_mask = OMAP3430_ST_UART3_MASK;
- padconf = 0x19e;
break;
case 3:
wk_mask = OMAP3630_ST_UART4_MASK;
- padconf = 0x0d2;
break;
}
uart-wk_mask = wk_mask;
- uart-padconf = padconf;
} else if (cpu_is_omap24xx()) {
u32 wk_mask = 0;
u32 wk_en = PM_WKEN1, wk_st = PM_WKST1;
@@ -532,7 +511,6 @@ static void omap_uart_idle_init(struct omap_uart_state
*uart)
uart-wk_en = NULL;
uart-wk_st = NULL;
uart-wk_mask = 0;
- uart-padconf = 0;
}
uart-irqflags |= IRQF_SHARED;
@@ -833,8 +811,7 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata)
console_unlock();
- if ((cpu_is_omap34xx() uart-padconf) ||
- (uart-wk_en uart-wk_mask)) {
+ if (uart-oh-mux || (uart-wk_en uart-wk_mask)) {
device_init_wakeup(pdev-dev, true);
DEV_CREATE_FILE(pdev-dev, dev_attr_sleep_timeout);
}
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv9 16/18] TEMP: OMAP3: serial: made serial to work properly with PRCM chain handler
This patch is just a temporary hack to allow serial to work properly with
the PRCM chain handler. Should be replaced with a proper implementation
by serial runtime PM support.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 29 +
drivers/tty/serial/omap-serial.c |8
2 files changed, 17 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index e08feb1..0cc5434 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -39,6 +39,7 @@
#include plat/dma.h
#include plat/omap_hwmod.h
#include plat/omap_device.h
+#include plat/prcm.h
#include prm2xxx_3xxx.h
#include pm.h
@@ -380,6 +381,7 @@ static void omap_uart_allow_sleep(struct omap_uart_state
*uart)
omap_uart_smart_idle_enable(uart, 1);
uart-can_sleep = 1;
del_timer(uart-timer);
+ omap_uart_disable_clocks(uart);
}
static void omap_uart_idle_timer(unsigned long data)
@@ -391,36 +393,23 @@ static void omap_uart_idle_timer(unsigned long data)
void omap_uart_prepare_idle(int num)
{
- struct omap_uart_state *uart;
-
- list_for_each_entry(uart, uart_list, node) {
- if (num == uart-num uart-can_sleep) {
- omap_uart_disable_clocks(uart);
- return;
- }
- }
}
void omap_uart_resume_idle(int num)
{
struct omap_uart_state *uart;
+ u32 wkst;
list_for_each_entry(uart, uart_list, node) {
if (num == uart-num uart-can_sleep) {
- omap_uart_enable_clocks(uart);
+ omap_uart_block_sleep(uart);
- /* Check for IO pad wakeup */
- if (cpu_is_omap34xx() uart-padconf) {
- u16 p = omap_ctrl_readw(uart-padconf);
-
- if (p OMAP3_PADCONF_WAKEUPEVENT0)
- omap_uart_block_sleep(uart);
+ /* Check for normal UART wakeup (and clear it) */
+ if (uart-wk_st uart-wk_mask) {
+ wkst = __raw_readl(uart-wk_st) uart-wk_mask;
+ if (wkst)
+ __raw_writel(wkst, uart-wk_st);
}
-
- /* Check for normal UART wakeup */
- if (__raw_readl(uart-wk_st) uart-wk_mask)
- omap_uart_block_sleep(uart);
- return;
}
}
}
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index c37df8d..cfff8ac 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -261,6 +261,8 @@ static void serial_omap_start_tx(struct uart_port *port)
unsigned int start;
int ret = 0;
+ omap_uart_resume_idle(up-pdev-id);
+
if (!up-use_dma) {
serial_omap_enable_ier_thri(up);
return;
@@ -354,6 +356,8 @@ static inline irqreturn_t serial_omap_irq(int irq, void
*dev_id)
unsigned int iir, lsr;
unsigned long flags;
+ omap_uart_resume_idle(up-pdev-id);
+
iir = serial_in(up, UART_IIR);
if (iir UART_IIR_NO_INT)
return IRQ_NONE;
@@ -641,6 +645,8 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
unsigned long flags = 0;
unsigned int baud, quot;
+ omap_uart_resume_idle(up-pdev-id);
+
switch (termios-c_cflag CSIZE) {
case CS5:
cval = UART_LCR_WLEN5;
@@ -947,6 +953,8 @@ serial_omap_console_write(struct console *co, const char *s,
unsigned int ier;
int locked = 1;
+ omap_uart_resume_idle(up-pdev-id);
+
local_irq_save(flags);
if (up-port.sysrq)
locked = 0;
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv9 15/18] TEMP: OMAP3: pm: remove serial resume / idle calls from idle path
This is no longer needed as it will be handled within serial driver itself.
This part should be properly handled with serial runtime support.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 19 ---
1 files changed, 0 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 4bbf1cd..46c209d 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -341,18 +341,9 @@ void omap_sram_idle(void)
omap3_enable_io_chain();
}
- /* Block console output in case it is on one of the OMAP UARTs */
- if (!is_suspending())
- if (per_next_state PWRDM_POWER_ON ||
- core_next_state PWRDM_POWER_ON)
- if (!console_trylock())
- goto console_still_active;
-
/* PER */
if (per_next_state PWRDM_POWER_ON) {
per_going_off = (per_next_state == PWRDM_POWER_OFF) ? 1 : 0;
- omap_uart_prepare_idle(2);
- omap_uart_prepare_idle(3);
omap2_gpio_prepare_for_idle(per_going_off);
if (per_next_state == PWRDM_POWER_OFF)
omap3_per_save_context();
@@ -360,8 +351,6 @@ void omap_sram_idle(void)
/* CORE */
if (core_next_state PWRDM_POWER_ON) {
- omap_uart_prepare_idle(0);
- omap_uart_prepare_idle(1);
if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
omap3_cm_save_context();
@@ -408,8 +397,6 @@ void omap_sram_idle(void)
omap3_sram_restore_context();
omap2_sms_restore_context();
}
- omap_uart_resume_idle(0);
- omap_uart_resume_idle(1);
if (core_next_state == PWRDM_POWER_OFF)
omap2_prm_clear_mod_reg_bits(OMAP3430_AUTO_OFF_MASK,
OMAP3430_GR_MOD,
@@ -423,14 +410,8 @@ void omap_sram_idle(void)
omap2_gpio_resume_after_idle();
if (per_prev_state == PWRDM_POWER_OFF)
omap3_per_restore_context();
- omap_uart_resume_idle(2);
- omap_uart_resume_idle(3);
}
- if (!is_suspending())
- console_unlock();
-
-console_still_active:
/* Disable IO-PAD and IO-CHAIN wakeup */
if (omap3_has_io_wakeup()
(per_next_state PWRDM_POWER_ON ||
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv9 12/18] TEMP: serial: added mux support
Just for PRCM chain handler testing purposes. This should be replaced with
a proper implementation.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/serial.c | 71 -
1 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 3d1c1d3..e08feb1 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -862,17 +862,84 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata)
* can call this function when they want to have default behaviour
* for serial ports (e.g initialize them all as serial ports).
*/
+
+struct serial_mux_conf {
+ char *name;
+ int omap3_mux;
+ int omap4_mux;
+};
+
+#define OMAP3_SERIAL_MUX_IN_PU (OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0)
+#define OMAP3_SERIAL_MUX_IN_PD (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE0)
+#define OMAP3_SERIAL_MUX_IN (OMAP_PIN_INPUT | OMAP_MUX_MODE0)
+#define OMAP3_SERIAL_MUX_OUT (OMAP_PIN_OUTPUT | OMAP_MUX_MODE0)
+#define OMAP4_SERIAL_MUX_IN_PU (OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0)
+#define OMAP4_SERIAL_MUX_OUT (OMAP_PIN_OUTPUT | OMAP_MUX_MODE0)
+#define OMAP4_SERIAL_MUX_IN (OMAP_PIN_INPUT | OMAP_MUX_MODE0)
+#define SERIAL_DISABLED OMAP_MUX_MODE7
+
+#define OMAP_SERIAL_NUM_PADS_PER_PORT 4
+
+static const struct serial_mux_conf serial_mux_data[] = {
+ { uart1_cts.uart1_cts, OMAP3_SERIAL_MUX_IN, SERIAL_DISABLED, },
+ { uart1_rts.uart1_rts, OMAP3_SERIAL_MUX_OUT, SERIAL_DISABLED, },
+ { uart1_rx.uart1_rx, OMAP3_SERIAL_MUX_IN, SERIAL_DISABLED, },
+ { uart1_tx.uart1_tx, OMAP3_SERIAL_MUX_OUT, SERIAL_DISABLED, },
+ { uart2_cts.uart2_cts, OMAP3_SERIAL_MUX_IN,
+ OMAP4_SERIAL_MUX_IN_PU, },
+ { uart2_rts.uart2_rts, OMAP3_SERIAL_MUX_OUT, OMAP4_SERIAL_MUX_OUT, },
+ { uart2_rx.uart2_rx, OMAP3_SERIAL_MUX_IN, OMAP4_SERIAL_MUX_IN_PU, },
+ { uart2_tx.uart2_tx, OMAP3_SERIAL_MUX_OUT, OMAP4_SERIAL_MUX_OUT },
+ { uart3_cts_rctx.uart3_cts_rctx, OMAP3_SERIAL_MUX_IN_PD,
+ OMAP4_SERIAL_MUX_IN_PU, },
+ { uart3_rts_sd.uart3_rts_sd, OMAP3_SERIAL_MUX_OUT,
+ OMAP4_SERIAL_MUX_OUT, },
+ { uart3_rx_irrx.uart3_rx_irrx, OMAP3_SERIAL_MUX_IN,
+ OMAP4_SERIAL_MUX_IN, },
+ { uart3_tx_irtx.uart3_tx_irtx, OMAP3_SERIAL_MUX_OUT,
+ OMAP4_SERIAL_MUX_OUT, },
+ { uart4_rx.uart4_rx, SERIAL_DISABLED, OMAP4_SERIAL_MUX_IN, },
+ { uart4_tx.uart4_tx, SERIAL_DISABLED, OMAP4_SERIAL_MUX_OUT, },
+ { NULL, SERIAL_DISABLED, SERIAL_DISABLED, },
+ { NULL, SERIAL_DISABLED, SERIAL_DISABLED, },
+};
+
void __init omap_serial_init(void)
{
struct omap_uart_state *uart;
struct omap_board_data bdata;
+ struct omap_device_pad *pads;
+ int idx;
+ int i;
+ pads = kmalloc(sizeof(struct omap_device_pad) * 4, GFP_KERNEL);
list_for_each_entry(uart, uart_list, node) {
bdata.id = uart-num;
bdata.flags = 0;
- bdata.pads = NULL;
bdata.pads_cnt = 0;
+ bdata.pads = pads;
+
+ for (i = 0; i OMAP_SERIAL_NUM_PADS_PER_PORT; i++) {
+ idx = bdata.id * OMAP_SERIAL_NUM_PADS_PER_PORT + i;
+ pads[i].name = serial_mux_data[idx].name;
+ pads[i].enable = 0;
+ pads[i].idle = 0;
+ pads[i].flags = 0;
+ if (cpu_is_omap34xx())
+ pads[i].enable = serial_mux_data[idx].omap3_mux;
+ if (cpu_is_omap44xx())
+ pads[i].enable = serial_mux_data[idx].omap4_mux;
+ if (pads[i].enable != SERIAL_DISABLED)
+ bdata.pads_cnt++;
+ if (pads[i].enable OMAP_PIN_INPUT) {
+ pads[i].flags = OMAP_DEVICE_PAD_REMUX |
+ OMAP_DEVICE_PAD_WAKEUP;
+ }
+ pads[i].idle = pads[i].enable;
+ }
+ if (bdata.pads_cnt == 0)
+ bdata.pads = NULL;
omap_serial_init_port(bdata);
-
}
+ kfree(pads);
}
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv9 11/18] omap3+: add omap prm driver initialization
OMAP PRM driver is initialized based on availability of PRM hwmods.
This patch will sequentially check for a list of known PRM hwmods and
will add an omap device if any is found.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/devices.c | 46 +
1 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 10adf66..d6750a4 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -419,6 +419,51 @@ static void omap_init_pmu(void)
platform_device_register(omap_pmu_device);
}
+#ifdef CONFIG_OMAP_PRM
+
+#include linux/mfd/omap-prm.h
+
+static const char * const omap_prm_devnames[] = {
+ prm3xxx,
+ prm4xxx,
+ NULL,
+};
+
+static void omap_init_prm(void)
+{
+ struct platform_device *pdev;
+ struct omap_hwmod *oh = NULL;
+ struct omap_prm_platform_config *pdata;
+ int i = 0;
+
+ while (!oh omap_prm_devnames[i]) {
+ oh = omap_hwmod_lookup(omap_prm_devnames[i]);
+ i++;
+ }
+
+ if (!oh) {
+ pr_info(prm hwmod not available\n);
+ return;
+ }
+
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+
+ if (!pdata) {
+ pr_err(%s: kzalloc failed\n, __func__);
+ return;
+ }
+
+ pdata-irq = oh-mpu_irqs[0].irq;
+ pdata-base = omap_hwmod_get_mpu_rt_va(oh);
+
+ pdev = omap_device_build(oh-name, -1, oh, pdata,
+ sizeof(*pdata), NULL, 0, 0);
+
+ WARN(IS_ERR(pdev), Unable to build omap device for PRM\n);
+}
+#else
+static inline void omap_init_prm(void) { }
+#endif
#if defined(CONFIG_CRYPTO_DEV_OMAP_SHAM) ||
defined(CONFIG_CRYPTO_DEV_OMAP_SHAM_MODULE)
@@ -687,6 +732,7 @@ static int __init omap2_init_devices(void)
omap_init_mbox();
omap_init_mcspi();
omap_init_pmu();
+ omap_init_prm();
omap_hdq_init();
omap_init_sti();
omap_init_sham();
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv9 14/18] TEMP: mux: added trace for io wkup event
Temporary patch for testing purposes, not meant for integration.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/mux.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index b27c061..642fe3f 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -376,6 +376,8 @@ bool omap_hwmod_mux_get_wake_status(struct
omap_hwmod_mux_info *hmux)
pad-mux-reg_offset);
if (val OMAP_WAKEUP_EVENT) {
ret = true;
+ pr_info(wkup detected: %04x\n,
+ pad-mux-reg_offset);
break;
}
}
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv9 07/18] mfd: omap-prm: added suspend prepare and complete callbacks
These are needed because runtime PM is disabled during suspend, and
it is bad if we get interrupts from the PRCM chain handler during it.
Now, PRCM interrupt forwarding is disabled until the suspend-complete,
which makes sure that all the needed drivers are up.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
drivers/mfd/omap-prm-common.c | 34 +-
drivers/mfd/omap-prm.h|2 ++
drivers/mfd/omap3xxx-prm.c|1 +
drivers/mfd/omap4xxx-prm.c|1 +
4 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/omap-prm-common.c b/drivers/mfd/omap-prm-common.c
index 2886eb2..e8522fc 100644
--- a/drivers/mfd/omap-prm-common.c
+++ b/drivers/mfd/omap-prm-common.c
@@ -20,6 +20,7 @@
#include linux/slab.h
#include linux/init.h
#include linux/err.h
+#include linux/platform_device.h
#include omap-prm.h
@@ -35,6 +36,7 @@ struct omap_prm_device {
int base_irq;
int irq;
void __iomem *base;
+ int suspended;
};
static struct omap_prm_device prm_dev;
@@ -92,12 +94,20 @@ static void prcm_irq_handler(unsigned int irq, struct
irq_desc *desc)
struct irq_chip *chip = irq_desc_get_chip(desc);
unsigned int virtirq;
int nr_irqs = prm_dev.irq_setup-nr_regs * 32;
+ int i;
+
+ if (prm_dev.suspended)
+ for (i = 0; i prm_dev.irq_setup-nr_regs; i++) {
+ prm_dev.saved_mask[i] =
+ prm_read_reg(prm_dev.irq_setup-mask + i * 4);
+ prm_write_reg(0, prm_dev.irq_setup-mask + i * 4);
+ }
/*
* Loop until all pending irqs are handled, since
* generic_handle_irq() can cause new irqs to come
*/
- while (1) {
+ while (!prm_dev.suspended) {
prm_pending_events(pending);
/* No bit set, then all IRQs are handled */
@@ -258,6 +268,28 @@ err:
return -ENOMEM;
}
+static int omap_prm_prepare(struct device *kdev)
+{
+ prm_dev.suspended = 1;
+ return 0;
+}
+
+static void omap_prm_complete(struct device *kdev)
+{
+ int i;
+
+ prm_dev.suspended = 0;
+
+ for (i = 0; i prm_dev.irq_setup-nr_regs; i++)
+ prm_write_reg(prm_dev.saved_mask[i],
+ prm_dev.irq_setup-mask + i * 4);
+}
+
+const struct dev_pm_ops omap_prm_pm_ops = {
+ .prepare = omap_prm_prepare,
+ .complete = omap_prm_complete,
+};
+
MODULE_AUTHOR(Tero Kristo t-kri...@ti.com);
MODULE_DESCRIPTION(OMAP PRM core driver);
MODULE_LICENSE(GPL);
diff --git a/drivers/mfd/omap-prm.h b/drivers/mfd/omap-prm.h
index 7ffefe1..c901810 100644
--- a/drivers/mfd/omap-prm.h
+++ b/drivers/mfd/omap-prm.h
@@ -32,6 +32,8 @@ struct omap_prcm_irq {
.priority = _priority \
}
+extern const struct dev_pm_ops omap_prm_pm_ops;
+
void omap_prcm_irq_cleanup(void);
int omap_prcm_register_chain_handler(int irq, void __iomem *base,
const struct omap_prcm_irq_setup *irq_setup,
diff --git a/drivers/mfd/omap3xxx-prm.c b/drivers/mfd/omap3xxx-prm.c
index 9be21ee..38b88aa 100644
--- a/drivers/mfd/omap3xxx-prm.c
+++ b/drivers/mfd/omap3xxx-prm.c
@@ -66,6 +66,7 @@ static struct platform_driver omap3xxx_prm_driver = {
.driver = {
.owner = THIS_MODULE,
.name = DRIVER_NAME,
+ .pm = omap_prm_pm_ops,
},
};
diff --git a/drivers/mfd/omap4xxx-prm.c b/drivers/mfd/omap4xxx-prm.c
index 6e134a7..92cc67d 100644
--- a/drivers/mfd/omap4xxx-prm.c
+++ b/drivers/mfd/omap4xxx-prm.c
@@ -65,6 +65,7 @@ static struct platform_driver omap4xxx_prm_driver = {
.driver = {
.owner = THIS_MODULE,
.name = DRIVER_NAME,
+ .pm = omap_prm_pm_ops,
},
};
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv9 05/18] mfd: omap-prm: add driver skeleton
This driver will eventually support OMAP soc PRM module features, e.g. PRCM
chain interrupts and voltage processor / controller. This patch only adds
basic skeleton for the driver that can be probed for omap3 and omap4.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
drivers/mfd/Kconfig |7 +
drivers/mfd/Makefile |2 +
drivers/mfd/omap-prm-common.c | 24
drivers/mfd/omap3xxx-prm.c| 60 +
drivers/mfd/omap4xxx-prm.c| 60 +
include/linux/mfd/omap-prm.h | 24
6 files changed, 177 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/omap-prm-common.c
create mode 100644 drivers/mfd/omap3xxx-prm.c
create mode 100644 drivers/mfd/omap4xxx-prm.c
create mode 100644 include/linux/mfd/omap-prm.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 21574bd..1ae2571 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -770,6 +770,13 @@ config MFD_AAT2870_CORE
additional drivers must be enabled in order to use the
functionality of the device.
+config OMAP_PRM
+ bool OMAP Power and Reset Management driver
+ depends on (ARCH_OMAP) PM
+ help
+ Say Y to enable support for the OMAP Power and Reset Management
+ driver.
+
endif # MFD_SUPPORT
menu Multimedia Capabilities Port drivers
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index c580203..503d85d 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -102,3 +102,5 @@ obj-$(CONFIG_MFD_PM8921_CORE) += pm8921-core.o
obj-$(CONFIG_MFD_PM8XXX_IRQ) += pm8xxx-irq.o
obj-$(CONFIG_TPS65911_COMPARATOR) += tps65911-comparator.o
obj-$(CONFIG_MFD_AAT2870_CORE) += aat2870-core.o
+obj-$(CONFIG_OMAP_PRM) += omap-prm-common.o omap3xxx-prm.o \
+ omap4xxx-prm.o
diff --git a/drivers/mfd/omap-prm-common.c b/drivers/mfd/omap-prm-common.c
new file mode 100644
index 000..39b199c8
--- /dev/null
+++ b/drivers/mfd/omap-prm-common.c
@@ -0,0 +1,24 @@
+/*
+ * OMAP Power and Reset Management (PRM) driver common functionality
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ *
+ * Author: Tero Kristo t-kri...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/kernel.h
+#include linux/ctype.h
+#include linux/module.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/init.h
+#include linux/err.h
+
+MODULE_AUTHOR(Tero Kristo t-kri...@ti.com);
+MODULE_DESCRIPTION(OMAP PRM core driver);
+MODULE_LICENSE(GPL);
diff --git a/drivers/mfd/omap3xxx-prm.c b/drivers/mfd/omap3xxx-prm.c
new file mode 100644
index 000..177aced
--- /dev/null
+++ b/drivers/mfd/omap3xxx-prm.c
@@ -0,0 +1,60 @@
+/*
+ * OMAP Power and Reset Management (PRM) driver for OMAP3xxx
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ *
+ * Author: Tero Kristo t-kri...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/kernel.h
+#include linux/ctype.h
+#include linux/module.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/init.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/mfd/omap-prm.h
+
+#define DRIVER_NAME prm3xxx
+
+static int __devinit omap3xxx_prm_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int __devexit omap3xxx_prm_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static struct platform_driver omap3xxx_prm_driver = {
+ .probe = omap3xxx_prm_probe,
+ .remove = __devexit_p(omap3xxx_prm_remove),
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = DRIVER_NAME,
+ },
+};
+
+static int __init omap3xxx_prm_init(void)
+{
+ return platform_driver_register(omap3xxx_prm_driver);
+}
+module_init(omap3xxx_prm_init);
+
+static void __exit omap3xxx_prm_exit(void)
+{
+ platform_driver_unregister(omap3xxx_prm_driver);
+}
+module_exit(omap3xxx_prm_exit);
+
+MODULE_ALIAS(platform:DRIVER_NAME);
+MODULE_AUTHOR(Tero Kristo t-kri...@ti.com);
+MODULE_DESCRIPTION(OMAP3xxx PRM driver);
+MODULE_LICENSE(GPL);
diff --git a/drivers/mfd/omap4xxx-prm.c b/drivers/mfd/omap4xxx-prm.c
new file mode 100644
index 000..9de8f3e
--- /dev/null
+++ b/drivers/mfd/omap4xxx-prm.c
@@ -0,0 +1,60 @@
+/*
+ * OMAP Power and Reset Management (PRM) driver for OMAP4xxx
+ *
+ * Copyright (C) 2011 Texas
[PATCHv9 08/18] OMAP2+: mux: add support for PAD wakeup interrupts
OMAP mux now provides a service routine to parse pending wakeup events
and to call registered ISR whenever active wakeups are detected. This
routine is called directly from PRCM interrupt handler.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/mux.c | 38 ++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 50ee806..b27c061 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -32,6 +32,9 @@
#include linux/debugfs.h
#include linux/seq_file.h
#include linux/uaccess.h
+#include linux/irq.h
+#include linux/interrupt.h
+#include linux/mfd/omap-prm.h
#include asm/system.h
@@ -381,6 +384,33 @@ bool omap_hwmod_mux_get_wake_status(struct
omap_hwmod_mux_info *hmux)
return ret;
}
+/**
+ * omap_hwmod_mux_handle_irq - Process wakeup events for a single hwmod
+ *
+ * Checks a single hwmod for every wakeup capable pad to see if there is an
+ * active wakeup event. If this is the case, call the corresponding ISR.
+ */
+static int _omap_hwmod_mux_handle_irq(struct omap_hwmod *oh, void *data)
+{
+ if (!oh-mux || !oh-mux-enabled)
+ return 0;
+ if (omap_hwmod_mux_get_wake_status(oh-mux))
+ generic_handle_irq(oh-mpu_irqs[0].irq);
+ return 0;
+}
+
+/**
+ * omap_hwmod_mux_handle_irq - Process pad wakeup irqs.
+ *
+ * Calls a function for each registered omap_hwmod to check
+ * pad wakeup statuses.
+ */
+static irqreturn_t omap_hwmod_mux_handle_irq(int irq, void *unused)
+{
+ omap_hwmod_for_each(_omap_hwmod_mux_handle_irq, NULL);
+ return IRQ_HANDLED;
+}
+
/* Assumes the calling function takes care of locking */
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state)
{
@@ -745,6 +775,7 @@ static void __init omap_mux_free_names(struct omap_mux *m)
static int __init omap_mux_late_init(void)
{
struct omap_mux_partition *partition;
+ int ret;
list_for_each_entry(partition, mux_partitions, node) {
struct omap_mux_entry *e, *tmp;
@@ -765,6 +796,13 @@ static int __init omap_mux_late_init(void)
}
}
+ ret = request_irq(omap_prcm_event_to_irq(io),
+ omap_hwmod_mux_handle_irq, IRQF_SHARED | IRQF_NO_SUSPEND,
+ hwmod_io, omap_mux_late_init);
+
+ if (ret)
+ printk(KERN_WARNING Failed to setup hwmod io irq %d\n, ret);
+
omap_mux_dbg_init();
return 0;
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod
This patch is temporary until Paul can provide a final version.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 56
1 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..26ced4f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -161,6 +161,7 @@ static struct omap_hwmod omap3xxx_l3_main_hwmod = {
};
static struct omap_hwmod omap3xxx_l4_wkup_hwmod;
+static struct omap_hwmod omap3xxx_prm_hwmod;
static struct omap_hwmod omap3xxx_uart1_hwmod;
static struct omap_hwmod omap3xxx_uart2_hwmod;
static struct omap_hwmod omap3xxx_uart3_hwmod;
@@ -478,6 +479,24 @@ static struct omap_hwmod omap3xxx_l4_per_hwmod = {
.flags = HWMOD_NO_IDLEST,
};
+static struct omap_hwmod_addr_space omap3xxx_prm_addrs[] = {
+ {
+ .pa_start = 0x48306000,
+ .pa_end = 0x48306000 + SZ_8K + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+ {}
+};
+
+/* L4_WKUP - PRM interface */
+static struct omap_hwmod_ocp_if omap3xxx_l4_wkup__prm = {
+ .master = omap3xxx_l4_wkup_hwmod,
+ .slave = omap3xxx_prm_hwmod,
+ .clk= wkup_l4_ick,
+ .addr = omap3xxx_prm_addrs,
+ .user = OCP_USER_MPU,
+};
+
/* Slave interfaces on the L4_WKUP interconnect */
static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_slaves[] = {
omap3xxx_l4_core__l4_wkup,
@@ -493,6 +512,40 @@ static struct omap_hwmod omap3xxx_l4_wkup_hwmod = {
.flags = HWMOD_NO_IDLEST,
};
+/* Slave interfaces on the L4_WKUP interconnect */
+static struct omap_hwmod_ocp_if *omap3xxx_prm_slaves[] = {
+ omap3xxx_l4_wkup__prm,
+};
+
+static struct omap_hwmod_class_sysconfig omap3xxx_prm_sysc = {
+ .rev_offs = 0x0804,
+ .sysc_offs = 0x0814,
+ .sysc_flags = SYSC_HAS_AUTOIDLE,
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_prm_hwmod_class = {
+ .name = prm,
+ .sysc = omap3xxx_prm_sysc,
+};
+
+static struct omap_hwmod_irq_info omap3xxx_prm_irqs[] = {
+ { .irq = 11 },
+ { .irq = -1 }
+};
+
+/* PRM */
+static struct omap_hwmod omap3xxx_prm_hwmod = {
+ .name = prm3xxx,
+ .mpu_irqs = omap3xxx_prm_irqs,
+ .class = omap3xxx_prm_hwmod_class,
+ .main_clk = wkup_32k_fck,
+ .slaves = omap3xxx_prm_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_prm_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = HWMOD_NO_IDLEST,
+};
+
/* Master interfaces on the MPU device */
static struct omap_hwmod_ocp_if *omap3xxx_mpu_masters[] = {
omap3xxx_mpu__l3_main,
@@ -3201,6 +3254,9 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_l4_core_hwmod,
omap3xxx_l4_per_hwmod,
omap3xxx_l4_wkup_hwmod,
+
+ omap3xxx_prm_hwmod,
+
omap3xxx_mmc1_hwmod,
omap3xxx_mmc2_hwmod,
omap3xxx_mmc3_hwmod,
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
To unsubscribe from this list: send the line unsubscribe 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 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices
hi Kevin,
On Fri, Sep 23, 2011 at 3:05 PM, Hilman, Kevin wrote:
Abhilash K V abhilash...@ti.com writes:
In case of AM3517 AM3505, SmartReflex is not applicable so
we must not enable it.
This part is fine, but...
So omap3_twl_init() is now not called when the processor does not
support SR.
...I don't think this is right. DVFS using the PMIC is still doable
without SR.
Are you assuming that no DVFS is done on these devices?
[Abhilash K V] yes, I just verified (in sprugr0b), that DVFS is not supported
on am35xx
DPS however is supported, though I'm unsure of how or whether it needs
software control.
-Abhilash
Kevin
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Abhilash K V abhilash...@ti.com
---
arch/arm/mach-omap2/id.c |2 +-
arch/arm/mach-omap2/pm.c |3 ++-
arch/arm/plat-omap/include/plat/cpu.h |2 ++
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index d27daf9..b7e3082 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -188,7 +188,7 @@ static void __init omap3_check_features(void)
if (cpu_is_omap3630())
omap_features |= OMAP3_HAS_192MHZ_CLK;
if (!cpu_is_omap3505() !cpu_is_omap3517())
- omap_features |= OMAP3_HAS_IO_WAKEUP;
+ omap_features |= (OMAP3_HAS_IO_WAKEUP | OMAP3_HAS_SR);
omap_features |= OMAP3_HAS_SDRC;
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index d34fc52..da71abc 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -252,7 +252,8 @@ postcore_initcall(omap2_common_pm_init);
static int __init omap2_common_pm_late_init(void)
{
/* Init the OMAP TWL parameters */
- omap3_twl_init();
+ if (omap3_has_sr())
+ omap3_twl_init();
omap4_twl_init();
/* Init the voltage layer */
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 2f90269..cc6fcd3 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -413,6 +413,7 @@ extern u32 omap_features;
#define OMAP4_HAS_MPU_1GHZ BIT(8)
#define OMAP4_HAS_MPU_1_2GHZ BIT(9)
#define OMAP4_HAS_MPU_1_5GHZ BIT(10)
+#define OMAP3_HAS_SR BIT(11)
#define OMAP3_HAS_FEATURE(feat,flag) \
@@ -429,6 +430,7 @@ OMAP3_HAS_FEATURE(isp, ISP)
OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK)
OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP)
OMAP3_HAS_FEATURE(sdrc, SDRC)
+OMAP3_HAS_FEATURE(sr, SR)
/*
* Runtime detection of OMAP4 features
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv9 04/18] TEMP: OMAP4xxx: hwmod data: add PRM hwmod
This patch is temporary until Benoit can provide final version.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 65
1 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6201422..c09bf4d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -3990,6 +3990,68 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+ /*
+ * 'prm' class
+ * power and reset manager (part of the prcm infrastructure)
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_prm_sysc = {
+ .rev_offs = 0x,
+ .sysc_flags = 0,
+};
+
+static struct omap_hwmod_class omap44xx_prm_hwmod_class = {
+ .name = prm,
+ .sysc = omap44xx_prm_sysc,
+};
+
+/* prm */
+static struct omap_hwmod omap44xx_prm_hwmod;
+static struct omap_hwmod_irq_info omap44xx_prm_irqs[] = {
+ { .irq = 11 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_rst_info omap44xx_prm_resets[] = {
+ { .name = rst_global_warm_sw, .rst_shift = 0 },
+ { .name = rst_global_cold_sw, .rst_shift = 1 },
+};
+
+static struct omap_hwmod_addr_space omap44xx_prm_addrs[] = {
+ {
+ .pa_start = 0x4a306000,
+ .pa_end = 0x4a307fff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* l4_wkup - prm */
+static struct omap_hwmod_ocp_if omap44xx_l4_wkup__prm = {
+ .master = omap44xx_l4_wkup_hwmod,
+ .slave = omap44xx_prm_hwmod,
+ .clk= l4_wkup_clk_mux_ck,
+ .addr = omap44xx_prm_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* prm slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_prm_slaves[] = {
+ omap44xx_l4_wkup__prm,
+};
+
+static struct omap_hwmod omap44xx_prm_hwmod = {
+ .name = prm4xxx,
+ .class = omap44xx_prm_hwmod_class,
+ .mpu_irqs = omap44xx_prm_irqs,
+ .clkdm_name = l4_wkup_clkdm,
+ .rst_lines = omap44xx_prm_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap44xx_prm_resets),
+ .slaves = omap44xx_prm_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_prm_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
/*
* 'smartreflex' class
* smartreflex module (monitor silicon performance and outputs a measure of
@@ -5448,6 +5510,9 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* mpu class */
omap44xx_mpu_hwmod,
+ /* prm class */
+ omap44xx_prm_hwmod,
+
/* smartreflex class */
omap44xx_smartreflex_core_hwmod,
omap44xx_smartreflex_iva_hwmod,
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] OMAP4: Clock: Associate clocks for OMAP temperature sensor
On Fri, Sep 23, 2011 at 11:28 AM, Paul Walmsley p...@pwsan.com wrote:
On Fri, 23 Sep 2011, J, KEERTHY wrote:
On Fri, Sep 23, 2011 at 10:48 AM, Paul Walmsley p...@pwsan.com wrote:
On Thu, 22 Sep 2011, Keerthy wrote:
---
arch/arm/mach-omap2/clock44xx_data.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 946bf04..c51e513 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3185,9 +3185,9 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, aes2_fck, aes2_fck,
CK_443X),
CLK(NULL, aess_fck, aess_fck,
CK_443X),
CLK(NULL, bandgap_fclk, bandgap_fclk,
CK_443X),
- CLK(NULL, bandgap_ts_fclk, bandgap_ts_fclk,
CK_446X),
+ CLK(omap4460plus_scm.0, fck, bandgap_ts_fclk,
CK_446X),
CLK(NULL, des3des_fck, des3des_fck,
CK_443X),
- CLK(NULL, div_ts_ck, div_ts_ck,
CK_446X),
+ CLK(omap4460plus_scm.0, div_ck,
div_ts_ck, CK_446X),
Clearly this device is incorrectly named. You're setting up a clkdev
entry that's marked as being valid for OMAP4430, but your device is called
omap4460plus_scm. They can't both be right...
This is addressed in Patch 06.
How does patch 6 address it?
I am not sure i interpreted the comment right. These clock nodes are specific to
OMAP4460 and are tagged CK_446X hence the device name omap4460plus_scm.0
- Paul
--
Regards and Thanks,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] AM3517 : support for suspend/resume
hi Kevin Thanks for reviewing the patch. On Fri, Sep 23, 2011 at 3:25 AM, Hilman, Kevin wrote: Abhilash K V abhilash...@ti.com writes: This patch-set adds support for suspension to RAM and resumption on the AM3517. This includes: 1. Patch to disable dynamic sleep (as it is not supported on AM35xx). This should still be a separate patch, with justification. More on this below. [Abhilash K V] OK 2. Imported the unique suspend/resume sequence for AM3517, contained in the new file arch/arm/mach-omap2/sleep3517.S. Caveat: If no_console_suspend is enabled (via boot-args),the device doesnot resume but simply hangs. Kevin's fix below should fix this: http://marc.info/?l=linux-omapm=131593828001388w=2#1 should fix? I assumed you tested it along with this. [Abhilash K V] I've tested that it does; pardon my choice of words. Signed-off-by: Ranjith Lohithakshan ranji...@ti.com Reviewed-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Abhilash K V abhilash...@ti.com --- This patch is dependent on the following patch-sets: * [PATCH v3 0/2] AM3517: Booting up at http://marc.info/?l=linux-omapm=131548349725176w=2 * [PATCH v2 0/3] AM35x: Adding PM init at http://marc.info/?l=linux-kernelm=131548606728209w=2 The patches are tested on master of tmlind/linux-omap-2.6.git. Kernel version is 3.1-rc3 and last commit on top of which these patches were added is: b148d763841161894ed6629794064065a834aa2b: Linux-omap rebuilt: Updated to use omap_sdrc_init with the folowing commit reverted: f3637a5f2e2eb391ff5757bc83fb5de8f9726464: irq: Always set IRQF_ONESHOT if no primary handler is specified Changes in v2: * Synchronised with the cleaned-up suspend-resume code for OMAP3 * Removed unused *_get_restore_pointer code * Added SECURE_SRAM feature to disallow saving and restoring secure ram context for AM35x Adding a new feature flag should be a separate patch. * Compacted the number of patches by squashing three closely coupled ones and eliminating one that was no longer needed. arch/arm/mach-omap2/Makefile |3 +- arch/arm/mach-omap2/id.c |4 +- arch/arm/mach-omap2/pm.h |3 + arch/arm/mach-omap2/pm34xx.c | 21 - arch/arm/mach-omap2/sleep3517.S | 156 + arch/arm/plat-omap/include/plat/cpu.h |2 + 6 files changed, 183 insertions(+), 6 deletions(-) create mode 100644 arch/arm/mach-omap2/sleep3517.S diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 590e797..37f62ae 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -61,7 +61,7 @@ endif ifeq ($(CONFIG_PM),y) obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o -obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o \ +obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o sleep3517.o \ cpuidle34xx.o obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o obj-$(CONFIG_PM_DEBUG) += pm-debug.o @@ -70,6 +70,7 @@ obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3) += smartreflex-class3.o AFLAGS_sleep24xx.o :=-Wa,-march=armv6 AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec) +AFLAGS_sleep3517.o :=-Wa,-march=armv7-a$(plus_sec) ifeq ($(CONFIG_PM_VERBOSE),y) CFLAGS_pm_bus.o += -DDEBUG diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index da71098..3e40c02 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -202,7 +202,9 @@ static void __init omap3_check_features(void) if (cpu_is_omap3630()) omap_features |= OMAP3_HAS_192MHZ_CLK; if (!cpu_is_omap3505() !cpu_is_omap3517()) - omap_features |= (OMAP3_HAS_IO_WAKEUP | OMAP3_HAS_SR); + omap_features |= (OMAP3_HAS_IO_WAKEUP + | OMAP3_HAS_SR + | OMAP3_HAS_SECURE_SRAM); This is not related to suspend either, and should probably be part of the bootup series. The HAS_SECURE_SRAM part should be added to the separate patch that adds this new feature flag. omap_features |= OMAP3_HAS_SDRC; diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h index ce028f6..952eb2b 100644 --- a/arch/arm/mach-omap2/pm.h +++ b/arch/arm/mach-omap2/pm.h @@ -82,10 +82,13 @@ extern unsigned int omap24xx_cpu_suspend_sz; /* 3xxx */ extern void omap34xx_cpu_suspend(int save_state); +extern void omap3517_cpu_suspend(int save_state); /* omap3_do_wfi function pointer and size, for copy to SRAM */ extern void omap3_do_wfi(void); +extern void omap3517_do_wfi(void); extern unsigned int omap3_do_wfi_sz; +extern unsigned int omap3517_do_wfi_sz; /* ... and its pointer from SRAM after copy
Re: [PATCH 3/6] OMAP4460: Temperature sensor data
On Fri, Sep 23, 2011 at 11:33 AM, Paul Walmsley p...@pwsan.com wrote:
Hi
some comments
On Thu, 22 Sep 2011, Keerthy wrote:
The register set and the
bit fields might vary across OMAP versions. Hence
creating a structure comprising of all the registers
and bit fields to make the driver uniform for all the
versions with different register sets. The data file
contains the structure populated with register offsets
and bit fields corresponding to OMAP4460 on die sensor.
Signed-off-by: Keerthy j-keer...@ti.com
Cc: t...@atomide.com
---
arch/arm/mach-omap2/Makefile | 2 +-
arch/arm/mach-omap2/temp_sensor4460_data.c | 115 ++
arch/arm/plat-omap/include/plat/scm.h | 175
3 files changed, 291 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/temp_sensor4460_data.c
create mode 100644 arch/arm/plat-omap/include/plat/scm.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 46a3497..e6f8d36 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -86,7 +86,7 @@ obj-$(CONFIG_ARCH_OMAP3) += prcm.o
cm2xxx_3xxx.o prm2xxx_3xxx.o \
obj-$(CONFIG_ARCH_OMAP4) += prcm.o cm2xxx_3xxx.o cminst44xx.o \
cm44xx.o prcm_mpu44xx.o \
prminst44xx.o vc44xx_data.o \
- vp44xx_data.o
+ vp44xx_data.o temp_sensor4460_data.o
This is not part of the PRCM, so it should not be added here.
It also should be conditional on CONFIG_SOC_OMAP4460. If that Kconfig
entry doesn't exist, it should be added.
Ok. I will add it.
# OMAP voltage domains
ifeq ($(CONFIG_PM),y)
diff --git a/arch/arm/mach-omap2/temp_sensor4460_data.c
b/arch/arm/mach-omap2/temp_sensor4460_data.c
new file mode 100644
index 000..2804615
--- /dev/null
+++ b/arch/arm/mach-omap2/temp_sensor4460_data.c
Is there some reason why this shouldn't go into drivers/ in some form?
This is used by mach-omap2.
@@ -0,0 +1,115 @@
+/*
+ * OMAP4460 on die Temperature sensor data file
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: J Keerthy j-keer...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/slab.h
+#include control.h
+#include plat/scm.h
+
+/*
+ * OMAP4460 has one instance of thermal sensor for MPU
+ * need to describe the individual bit fields
+ */
+struct omap_temp_sensor_registers omap_mpu_temp_sensor_registers = {
This is going to break if we want to compile a kernel with support
for, say, the 4430 and 4460 temperature sensors.
Ok. I will rename this as omap4460_temp_sensor_registers
+ .temp_sensor_ctrl = OMAP4460_TEMP_SENSOR_CTRL_OFFSET,
+ .bgap_tempsoff_mask = OMAP4460_BGAP_TEMPSOFF_MASK,
+ .bgap_soc_mask = OMAP4460_BGAP_TEMP_SENSOR_SOC_MASK,
+ .bgap_eocz_mask = OMAP4460_BGAP_TEMP_SENSOR_EOCZ_MASK,
+ .bgap_dtemp_mask = OMAP4460_BGAP_TEMP_SENSOR_DTEMP_MASK,
+
+ .bgap_mask_ctrl = OMAP4460_BGAP_CTRL_OFFSET,
+ .mask_hot_mask = OMAP4460_MASK_HOT_MASK,
+ .mask_cold_mask = OMAP4460_MASK_COLD_MASK,
+
+ .bgap_mode_ctrl = OMAP4460_BGAP_CTRL_OFFSET,
+ .mode_ctrl_mask = OMAP4460_SINGLE_MODE_MASK,
+
+ .bgap_counter = OMAP4460_BGAP_COUNTER_OFFSET,
+ .counter_mask = OMAP4460_COUNTER_MASK,
+
+ .bgap_threshold = OMAP4460_BGAP_THRESHOLD_OFFSET,
+ .threshold_thot_mask = OMAP4460_T_HOT_MASK,
+ .threshold_tcold_mask = OMAP4460_T_COLD_MASK,
+
+ .thsut_threshold = OMAP4460_BGAP_TSHUT_OFFSET,
tshut is misspelled.
I will correct this.
+ .tshut_hot_mask = OMAP4460_TSHUT_HOT_MASK,
+ .tshut_cold_mask = OMAP4460_TSHUT_COLD_MASK,
+
+ .bgap_status = OMAP4460_BGAP_STATUS_OFFSET,
+ .status_clean_stop_mask = OMAP4460_CLEAN_STOP_MASK,
+ .status_bgap_alert_mask = OMAP4460_BGAP_ALERT_MASK,
+
Re: [PATCH 4/6] OMAP4: Hwmod: system control module hwmod
On Fri, Sep 23, 2011 at 11:45 AM, Paul Walmsley p...@pwsan.com wrote: + Benoît Hi, On Thu, 22 Sep 2011, Keerthy wrote: From: Benoit Cousson b-cous...@ti.com Adding the system control module hwmod. Have the autogeneration scripts been updated ? The hwmod is autogenerated. I have taken this from Benoit. I have added the dev_attr to pass on the information about temperature sensors. Signed-off-by: Benoit Cousson b-cous...@ti.com Signed-off-by: Keerthy j-keer...@ti.com - Paul -- Regards and Thanks, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP2+: clock: cleanup CPUfreq leftovers
Paul Walmsley p...@pwsan.com writes: On Thu, 22 Sep 2011, Paul Walmsley wrote: On Thu, 22 Sep 2011, Kevin Hilman wrote: Now that we have OPP layer, and OMAP CPUfreq driver is using it, we no longer need/use the clock framework code for filling up CPUfreq tables. Remove it. Signed-off-by: Kevin Hilman khil...@ti.com --- Paul, this patch has a dependency on the OMAP CPUFreq driver move/cleanup series just posted. Assuming that is merged for v3.2, this can go also. Great, could you cc lakml also ? doh. By the way, I guess the subject line should start with ARM: OMAP2+: clock: .. etc., per Arnd's recent request. yeah, will refresh. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] cpufreq: OMAP: cleanup for multi-SoC support,move into drivers/cpufreq
Vishwanath Sripathy vishwanath...@ti.com writes: [...] +#ifdef CONFIG_CPU_FREQ_DEBUG +pr_info(cpufreq-omap: transition: %u -- %u\n, freqs.old, freqs.new); +#endif + +ret = clk_set_rate(mpu_clk, freqs.new * 1000); Do you plan to post follow up patches to scale voltage along with Clock? Yes. This series is just a move of existing code + minor cleanups. The next step is to finalize/merge Tero's regulator driver and use that to scale voltage along with frequency here. Now that the voltage domain cleanups are merged, I hope to have regulator series + voltage scaling changes in this driver ready next week. 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
[PATCH v2] ARM: OMAP2+: clock: cleanup CPUfreq leftovers
Now that we have OPP layer, and OMAP CPUfreq driver is using it, we no
longer need/use the clock framework code for filling up CPUfreq
tables. Remove it.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 80 --
arch/arm/mach-omap2/clock.c |5 --
arch/arm/mach-omap2/clock.h |8 ---
3 files changed, 0 insertions(+), 93 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
index 39f9d5a..9a13e07 100644
--- a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
+++ b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
@@ -164,83 +164,3 @@ int omap2_select_table_rate(struct clk *clk, unsigned long
rate)
return 0;
}
-
-#ifdef CONFIG_CPU_FREQ
-/*
- * Walk PRCM rate table and fillout cpufreq freq_table
- * XXX This should be replaced by an OPP layer in the near future
- */
-static struct cpufreq_frequency_table *freq_table;
-
-void omap2_clk_init_cpufreq_table(struct cpufreq_frequency_table **table)
-{
- const struct prcm_config *prcm;
- int i = 0;
- int tbl_sz = 0;
-
- if (!cpu_is_omap24xx())
- return;
-
- for (prcm = rate_table; prcm-mpu_speed; prcm++) {
- if (!(prcm-flags cpu_mask))
- continue;
- if (prcm-xtal_speed != sclk-rate)
- continue;
-
- /* don't put bypass rates in table */
- if (prcm-dpll_speed == prcm-xtal_speed)
- continue;
-
- tbl_sz++;
- }
-
- /*
-* XXX Ensure that we're doing what CPUFreq expects for this error
-* case and the following one
-*/
- if (tbl_sz == 0) {
- pr_warning(%s: no matching entries in rate_table\n,
- __func__);
- return;
- }
-
- /* Include the CPUFREQ_TABLE_END terminator entry */
- tbl_sz++;
-
- freq_table = kzalloc(sizeof(struct cpufreq_frequency_table) * tbl_sz,
-GFP_ATOMIC);
- if (!freq_table) {
- pr_err(%s: could not kzalloc frequency table\n, __func__);
- return;
- }
-
- for (prcm = rate_table; prcm-mpu_speed; prcm++) {
- if (!(prcm-flags cpu_mask))
- continue;
- if (prcm-xtal_speed != sclk-rate)
- continue;
-
- /* don't put bypass rates in table */
- if (prcm-dpll_speed == prcm-xtal_speed)
- continue;
-
- freq_table[i].index = i;
- freq_table[i].frequency = prcm-mpu_speed / 1000;
- i++;
- }
-
- freq_table[i].index = i;
- freq_table[i].frequency = CPUFREQ_TABLE_END;
-
- *table = freq_table[0];
-}
-
-void omap2_clk_exit_cpufreq_table(struct cpufreq_frequency_table **table)
-{
- if (!cpu_is_omap24xx())
- return;
-
- kfree(freq_table);
-}
-
-#endif
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 1f3481f..160e61c 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -536,10 +536,5 @@ struct clk_functions omap2_clk_functions = {
.clk_set_rate = omap2_clk_set_rate,
.clk_set_parent = omap2_clk_set_parent,
.clk_disable_unused = omap2_clk_disable_unused,
-#ifdef CONFIG_CPU_FREQ
- /* These will be removed when the OPP code is integrated */
- .clk_init_cpufreq_table = omap2_clk_init_cpufreq_table,
- .clk_exit_cpufreq_table = omap2_clk_exit_cpufreq_table,
-#endif
};
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 48ac568..7fa20b3 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -144,14 +144,6 @@ extern const struct clksel_rate gpt_sys_rates[];
extern const struct clksel_rate gfx_l3_rates[];
extern const struct clksel_rate dsp_ick_rates[];
-#if defined(CONFIG_ARCH_OMAP2) defined(CONFIG_CPU_FREQ)
-extern void omap2_clk_init_cpufreq_table(struct cpufreq_frequency_table
**table);
-extern void omap2_clk_exit_cpufreq_table(struct cpufreq_frequency_table
**table);
-#else
-#define omap2_clk_init_cpufreq_table 0
-#define omap2_clk_exit_cpufreq_table 0
-#endif
-
extern const struct clkops clkops_omap2_iclk_dflt_wait;
extern const struct clkops clkops_omap2_iclk_dflt;
extern const struct clkops clkops_omap2_iclk_idle_only;
--
1.7.6
--
To unsubscribe from this list: send the line unsubscribe 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] AM3517 : support for suspend/resume
Koyamangalath, Abhilash abhilash...@ti.com writes:
[...]
@@ -485,6 +489,8 @@ console_still_active:
int omap3_can_sleep(void)
{
+ if (cpu_is_omap3505() || cpu_is_omap3517())
+ return 0;
This needs to be a separate patch with a descriptive changelog and
justification as to why you can't do WFI in idle.
[Abhilash K V]OK
Adding something like this means the device will *never* attempt a WFI
during idle.
[Abhilash K V] This patch was put in as dynamic sleep feature is not
supported by the device, there are no C states etc. The only PM
supported is forced suspend /resume. There is just one power-domain
and it can be in ON or RET states.
If the device can WFI and hit retention in suspend, there should be no
not to target the same power state in idle.
You don't have to have CPUidle with multiple C-states to use idle.
I suspect that avoiding WFI in idle is masking a bug that you don't see
in the suspend path.
[Abhilash K V] I need to recap a bit to find out if there is a better
way to indicate the lack of idle feature.
Yes please. From my POV, deciding not to go idle is a SW decision, not
a hardware decision. As the same SW mechanisms are involved, whatever
power state that can be acheived from suspend should be targetted in
idle.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] AM35x: voltage: Basic initialization
Hi Abhilash, Koyamangalath, Abhilash abhilash...@ti.com writes: On Fri, Sep 23, 2011 at 4:00 AM, Hilman, Kevin wrote: Hi Abhilash, Abhilash K V abhilash...@ti.com writes: This patch adds the basic initialization of voltage layer for AM35x. Since AM35x doesn't support voltage scaling, I must admit to still being confused by this series. This patch says AM35x doesn't support voltage scaling, and the next patch adds PMIC support, and registers it with the voltage layer. However, with each voltdm-scalable flag set to false, none of the PMIC values will ever be used (by the current voltage layer.) Do you have more patches on top of this that extend the voltage layer to directly use the PMIC instead of using VC or VP? I'm assuming we have some more assumptions in our current voltage layer about the presence of VC/VP that are wrong and need to be fixed. Now that the big voltage layer cleanup is done, I am *very* interested in getting rid of any more assumptions we have in that code about how devices are hooked up with PMICs. Can you summarize how these devices are using (or want to use) the voltage layer? [Abhilash K V] Your concerns are grave and am trying to address most, however these are the only points I can make outright: - AM35x has just one voltage domain, so I tried having only one entry in voltagedomains_omap3[ ] ( and calling it mpu_core, maybe or mpu or core ?). Based the TRM, it's called core. Either ways, some power-domain, say mpu_pwrdm would try looking for the mpu_iva volt-domain and return error, this happens for most powerdomains as their constituent volt-domains are hard-coded (and so unavailable on am35xx). Changing the code (which will be massive) there going against our initial premise that am35xx is still a type of omap3 SoC. While the AM35x is similar to the OMAP3 in many ways, in terms of power, there are some significant differences that we need to model properly. The problem with the current approach is it's trying to trick the core code into thinking an AM35x is like an OMAP34xx by creating voltage domains that don't exist in hardware. The point of these voltage/power/clock domain data files is to represent *exactly* what is in hardware. Looking closer at SPRUGR0B, I don't think you should be directly using the 34xx powerdomains as a starting point. There are a few reasons: - not all 34xx powerdomains exist on AM35x (at least cam, iva2, USB host are missing) - AM35x powerdomains are in different voltage domains - AM35x powerdomains do not support retention or off (only on and inactive according to SPRUGR0B) - TPS65023 PMIC code was originally included as a starting point to support a omap34xx (with SR disabled maybe) with power supplied by a TPS65023. Yes,I agree that since this looks more of like hypothetical scenario right now and so we can do without the addition of file pmic_tps65023.c for now as it doesn't provide any support for scaling. I see now. Adding support for that PMIC to the kernel is fine, I just don't think it makes sense in context of this series for this device, since it does not support voltage scaling, and AFAICT, this PMIC is for DVS uses. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5 v11] mfd: omap: usb: Runtime PM support for EHCI and OHCI drivers
Munegowda, Keshava keshava_mgo...@ti.com writes: On Thu, Sep 22, 2011 at 7:02 PM, Ming Lei tom.leim...@gmail.com wrote: Hi, On Thu, Sep 22, 2011 at 7:37 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@ti.com The Hwmod structures and Runtime PM features are implemented For EHCI and OHCI drivers of OMAP3 and OMAP4. The global suspend/resume of EHCI and OHCI is validated on OMAP3430 sdp board with these patches. These patches are re-based to Kevin's pm branch : git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git Is kernel.org up now? :-) thanks, -- Ming Lei no! its kevin tree, which i took it 3 weeks back. :-( There shouldn't be any reason to base these patches on my tree. You should be using a current mainline. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 37/55] mmc: irq: Remove IRQF_DISABLED
Hi, On Thu, Sep 22 2011, Yong Zhang wrote: Since commit [e58aa3d2: genirq: Run irq handlers with interrupts disabled], We run all interrupt handlers with interrupts disabled and we even check and yell when an interrupt handler returns with interrupts enabled (see commit [b738a50a: genirq: Warn when handler enables interrupts]). So now this flag is a NOOP and can be removed. Signed-off-by: Yong Zhang yong.zha...@gmail.com Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Thanks, pushed to mmc-next for 3.2 with Kishore's ACK added. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] OMAP4460: Clock: Adding support for 4460 specific clocks
Hi
On Thu, 22 Sep 2011, Paul Walmsley wrote:
On Thu, 22 Sep 2011, Keerthy wrote:
From: Vishwanath BS vishwanath...@ti.com
OMAP4460 specific clocks are not getting added as the
cpu_is_omap44xx is choosing only OMAP4430 specific clock nodes.
Changing it to add to OMAP4460 specific clocks also.
This is clocks are required of temperature sensor.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Keerthy j-keer...@ti.com
Cc: p...@pwsan.com
---
arch/arm/mach-omap2/clock44xx_data.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index c51e513..f72513b 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -1398,9 +1398,9 @@ static struct clk dss_dss_clk = {
};
static const struct clksel_rate div3_8to32_rates[] = {
- { .div = 8, .val = 0, .flags = RATE_IN_44XX },
- { .div = 16, .val = 1, .flags = RATE_IN_44XX },
- { .div = 32, .val = 2, .flags = RATE_IN_44XX },
+ { .div = 8, .val = 0, .flags = RATE_IN_4460 },
+ { .div = 16, .val = 1, .flags = RATE_IN_4460 },
+ { .div = 32, .val = 2, .flags = RATE_IN_4460 },
Are these rates really 4460-specific? If so, then it looks like something
is broken in the clock data generator. Clearly, I should not have acked
these patches and they should never have been merged.
{ .div = 0 },
};
@@ -3403,12 +3403,12 @@ int __init omap4xxx_clk_init(void)
struct omap_clk *c;
u32 cpu_clkflg;
- if (cpu_is_omap44xx()) {
+ if (cpu_is_omap443x()) {
cpu_mask = RATE_IN_4430;
cpu_clkflg = CK_443X;
} else if (cpu_is_omap446x()) {
- cpu_mask = RATE_IN_4460;
- cpu_clkflg = CK_446X;
+ cpu_mask = RATE_IN_4460 | RATE_IN_4430;
+ cpu_clkflg = CK_446X | CK_443X;
This isn't right. Until the clock data files are converted to use per-SoC
lists, what needs to be done here is to define a RATE_IN_44XX and CK_44XX
that will match all existing 4430/4460/4470 clocks. Then for rates and
clocks that are only specific to one of those SoCs, the appropriate
SoC-specific flag should be set.
Ugh. I see what's going on here, now. Both of these are good fixes,
since the existing 4460 clock support is broken.
- 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 00/11] OMAP: Add initial support for DT on OMAP3 OMAP4
Hi Tony, Grant, Here is the first set of patches to add device-tree support for OMAP3+ platforms. That series mainly adds a minimal OMAP2+ generic board file for basic DT support on OMAP2420, OMAP2430, OMAP3, OMAP4 and beyond. The goal is to remove even the minimal static devices init in order to have a fully generic OMAP board file. For the moment both UART and I2C need to be initialized statically. That series is a respin of several RFCs I sent previously and take into account the comments mainly done by Arnd and Grant. Patches are based on for_3.2/2_omap_device_dt and are available here: git://gitorious.org/omap-pm/linux.git for_3.2/3_omap_devicetree Please note that the Device Tree source files will be stored as well in the following repository: git://gitorious.org/omap/devicetree.git master Comments are welcome. Regards, Benoit Benoit Cousson (11): OMAP2+: Add SoC specific map_io functions arm/dts: Add initial device tree support for OMAP4 SoC arm/dts: Add support for OMAP4 PandaBoard arm/dts: Add support for OMAP4 SDP board arm/dts: Add initial device tree support for OMAP3 SoC arm/dts: Add support for OMAP3 Beagle board OMAP2+: board-generic: Add DT support to generic board OMAP2+: board-generic: Add i2c static init OMAP2+: l3-noc: Add support for device-tree arm/dts: OMAP4: Add a main ocp entry bound to l3-noc driver arm/dts: OMAP3+: Add mpu, dsp and iva nodes Documentation/devicetree/bindings/arm/omap/dsp.txt | 14 ++ Documentation/devicetree/bindings/arm/omap/iva.txt | 19 +++ .../devicetree/bindings/arm/omap/l3-noc.txt| 19 +++ Documentation/devicetree/bindings/arm/omap/mpu.txt | 27 arch/arm/boot/dts/omap3-beagle.dts | 29 arch/arm/boot/dts/omap3.dtsi | 63 arch/arm/boot/dts/omap4-panda.dts | 29 arch/arm/boot/dts/omap4-sdp.dts| 29 arch/arm/boot/dts/omap4.dtsi | 103 + arch/arm/mach-omap2/Kconfig|8 +- arch/arm/mach-omap2/board-generic.c| 158 ++- arch/arm/mach-omap2/common.c | 18 +++ arch/arm/mach-omap2/devices.c |5 + arch/arm/mach-omap2/omap_l3_noc.c | 23 +++- arch/arm/mach-omap2/pm.c |3 +- arch/arm/plat-omap/include/plat/common.h |4 + 16 files changed, 501 insertions(+), 50 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/dsp.txt create mode 100644 Documentation/devicetree/bindings/arm/omap/iva.txt create mode 100644 Documentation/devicetree/bindings/arm/omap/l3-noc.txt create mode 100644 Documentation/devicetree/bindings/arm/omap/mpu.txt create mode 100644 arch/arm/boot/dts/omap3-beagle.dts create mode 100644 arch/arm/boot/dts/omap3.dtsi create mode 100644 arch/arm/boot/dts/omap4-panda.dts create mode 100644 arch/arm/boot/dts/omap4-sdp.dts create mode 100644 arch/arm/boot/dts/omap4.dtsi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/11] arm/dts: Add initial device tree support for OMAP4 SoC
Add initial device-tree support for OMAP4 SoC.
This is based on the original panda board patch done by Manju:
http://permalink.gmane.org/gmane.linux.ports.arm.omap/60393
Add the generic GIC interrupt-controller from ARM.
Add an empty soc node to contain non memory mapped IPs
(DSP, MPU, IPU...).
Note: Since reg, irq and dma are provided by hwmod for the
moment, these attributes will not be present at all in DTS
to highlight the gap. They will be added as soon as dma bindings
will be there and drivers will be adapted.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 79 ++
1 files changed, 79 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap4.dtsi
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
new file mode 100644
index 000..d4131e3
--- /dev/null
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -0,0 +1,79 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Carveout for multimedia usecases
+ * It should be the last 48MB of the first 512MB memory part
+ * In theory, it should not even exist. That zone should be reserved
+ * dynamically during the .reserve callback.
+ */
+/memreserve/ 0x9d00 0x0300;
+
+/include/ skeleton.dtsi
+
+/ {
+ compatible = ti,omap4430, ti,omap4;
+ interrupt-parent = gic;
+
+ aliases {
+ };
+
+ /*
+* The soc node represents the soc top level view. It is uses for IPs
+* that are not memory mapped in the MPU view or for the MPU itself.
+*/
+ soc {
+ compatible = ti,omap-infra;
+ };
+
+ /*
+* XXX: Use a flat representation of the OMAP4 interconnect.
+* The real OMAP interconnect network is quite complex.
+*
+* MPU -+-- MPU_PRIVATE - GIC, L2
+* |
+* ++--+
+* || |
+* ++- EMIF - DDR |
+* || |
+* |+ ++
+* || |
+* |+- L4_ABE - AESS, MCBSP, TIMERs...
+* ||
+* +- L3_MAIN --+- L4_CORE - IPs...
+* |
+* +- L4_PER - IPs...
+* |
+* +- L4_CFG -+- L4_WKUP - IPs...
+* | |
+* | +- IPs...
+* +- IPU +
+* | |
+* +- DSP +
+* | |
+* +- DSS +
+*
+* Since that will not bring real advantage to represent that in DT for
+* the moment, just use a fake OCP bus entry to represent the whole bus
+* hierarchy.
+*/
+ ocp {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ gic: interrupt-controller@48241000 {
+ compatible = arm,cortex-a9-gic;
+ interrupt-controller;
+ #interrupt-cells = 1;
+ reg = 0x48241000 0x1000,
+ 0x48240100 0x0100;
+ };
+ };
+};
--
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 01/11] OMAP2+: Add SoC specific map_io functions
Add SoC specific map_io function to be used by the generic DT
board file. This is an intermediate step before having some
generic DT aware map_io function.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/common.c | 18 ++
arch/arm/plat-omap/include/plat/common.h |4
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 3f20cbb..de61f15 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -56,6 +56,12 @@ void __init omap2_set_globals_242x(void)
{
__omap2_set_globals(omap242x_globals);
}
+
+void __init omap242x_map_io(void)
+{
+ omap2_set_globals_242x();
+ omap242x_map_common_io();
+}
#endif
#if defined(CONFIG_SOC_OMAP2430)
@@ -74,6 +80,12 @@ void __init omap2_set_globals_243x(void)
{
__omap2_set_globals(omap243x_globals);
}
+
+void __init omap243x_map_io(void)
+{
+ omap2_set_globals_243x();
+ omap243x_map_common_io();
+}
#endif
#if defined(CONFIG_ARCH_OMAP3)
@@ -138,5 +150,11 @@ void __init omap2_set_globals_443x(void)
omap2_set_globals_control(omap4_globals);
omap2_set_globals_prcm(omap4_globals);
}
+
+void __init omap4_map_io(void)
+{
+ omap2_set_globals_443x();
+ omap44xx_map_common_io();
+}
#endif
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index 5cac97e..abda2c7 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -83,7 +83,11 @@ void omap2_set_globals_sdrc(struct omap_globals *);
void omap2_set_globals_control(struct omap_globals *);
void omap2_set_globals_prcm(struct omap_globals *);
+void omap242x_map_io(void);
+void omap243x_map_io(void);
void omap3_map_io(void);
+void omap4_map_io(void);
+
/**
* omap_test_timeout - busy-loop, testing a condition
--
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 03/11] arm/dts: Add support for OMAP4 PandaBoard
Based on the original omap4-panda.dts file from Manju.
http://www.spinics.net/lists/linux-omap/msg55836.html
Add memory information and a default bootargs to allow
a boot from RAMDISK.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap4-panda.dts
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
new file mode 100644
index 000..c702657
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -0,0 +1,29 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ omap4.dtsi
+
+/ {
+ model = TI OMAP4 PandaBoard;
+ compatible = ti,omap4-panda, ti,omap4430, ti,omap4;
+
+ /*
+* Since the initial device tree board file does not create any
+* devices (MMC, network...), the only way to boot is to provide a
+* ramdisk.
+*/
+ chosen {
+ bootargs = root=/dev/ram0 rw console=ttyO2,115200n8
initrd=0x8160,20M ramdisk_size=20480 no_console_suspend debug;
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x4000; /* 1 GB */
+ };
+};
--
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 05/11] arm/dts: Add initial device tree support for OMAP3 SoC
Add initial OMAP3 soc file with empty ocp bus.
Based on initial patch from Manju:
http://www.spinics.net/lists/linux-omap/msg55830.html
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 44 ++
1 files changed, 44 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3.dtsi
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
new file mode 100644
index 000..d558785
--- /dev/null
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -0,0 +1,44 @@
+/*
+ * Device Tree Source for OMAP3 SoC
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ skeleton.dtsi
+
+/ {
+ compatible = ti,omap3430, ti,omap3;
+
+ /*
+* The soc node represents the soc top level view. It is uses for IPs
+* that are not memory mapped in the MPU view or for the MPU itself.
+*/
+ soc {
+ compatible = ti,omap-infra;
+ };
+
+ /*
+* XXX: Use a flat representation of the OMAP3 interconnect.
+* The real OMAP interconnect network is quite complex.
+* Since that will not bring real advantage to represent that in DT for
+* the moment, just use a fake OCP bus entry to represent the whole bus
+* hierarchy.
+*/
+ ocp {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ ti,hwmods = l3_main;
+
+ intc: interrupt-controller@1 {
+ compatible = ti,omap3-intc;
+ interrupt-controller;
+ #interrupt-cells = 1;
+ };
+ };
+};
--
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 06/11] arm/dts: Add support for OMAP3 Beagle board
Add OMAP3 beagleboard DTS file to use the omap3.dtsi
SoC file.
Add a default bootargs line to allow a boot from RAMDISK
Add memory node information.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-beagle.dts
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
new file mode 100644
index 000..9486be6
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -0,0 +1,29 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ omap3.dtsi
+
+/ {
+ model = TI OMAP3 BeagleBoard;
+ compatible = ti,omap3-beagle, ti,omap3;
+
+ /*
+* Since the initial device tree board file does not create any
+* devices (MMC, network...), the only way to boot is to provide a
+* ramdisk.
+*/
+ chosen {
+ bootargs = root=/dev/ram0 rw console=ttyO2,115200n8
initrd=0x8160,20M ramdisk_size=20480 no_console_suspend debug earlyprintk;
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x2000; /* 512 MB */
+ };
+};
--
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 04/11] arm/dts: Add support for OMAP4 SDP board
Add the SDP/Blaze (Software Development Board) support with
device tree.
That file is based on the omap4-panda.dts.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap4-sdp.dts
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
new file mode 100644
index 000..066e28c
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -0,0 +1,29 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ omap4.dtsi
+
+/ {
+ model = TI OMAP4 SDP board;
+ compatible = ti,omap4-sdp, ti,omap4430, ti,omap4;
+
+ /*
+* Since the initial device tree board file does not create any
+* devices (MMC, network...), the only way to boot is to provide a
+* ramdisk.
+*/
+ chosen {
+ bootargs = root=/dev/ram0 rw console=ttyO2,115200n8
initrd=0x8160,20M ramdisk_size=20480 no_console_suspend debug;
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x4000; /* 1 GB */
+ };
+};
--
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 08/11] OMAP2+: board-generic: Add i2c static init
Still needed to boot until the i2c twl driver is adapted to
device-tree. Otherwise the voltage control code will try to
access the twl and crash.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-generic.c | 41 +-
1 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index dcbd64c..1186a76 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -11,6 +11,7 @@
#include linux/io.h
#include linux/of_platform.h
#include linux/irqdomain.h
+#include linux/i2c/twl.h
#include mach/hardware.h
#include asm/mach/arch.h
@@ -18,7 +19,31 @@
#include plat/board.h
#include plat/common.h
#include mach/omap4-common.h
+#include common-board-devices.h
+/*
+ * XXX: Still needed to boot until the i2c twl driver is adapted to
+ * device-tree
+ */
+static struct twl4030_platform_data sdp4430_twldata = {
+ .irq_base = TWL6030_IRQ_BASE,
+ .irq_end= TWL6030_IRQ_END,
+};
+
+static void __init omap4_i2c_init(void)
+{
+ omap4_pmic_init(twl6030, sdp4430_twldata);
+}
+
+static struct twl4030_platform_data beagle_twldata = {
+ .irq_base = TWL4030_IRQ_BASE,
+ .irq_end= TWL4030_IRQ_END,
+};
+
+static void __init omap3_i2c_init(void)
+{
+ omap3_pmic_init(twl4030, beagle_twldata);
+}
static struct of_device_id omap_dt_match_table[] __initdata = {
{ .compatible = simple-bus, },
@@ -44,6 +69,18 @@ static void __init omap_generic_init(void)
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
}
+static void __init omap4_init(void)
+{
+ omap4_i2c_init();
+ omap_generic_init();
+}
+
+static void __init omap3_init(void)
+{
+ omap3_i2c_init();
+ omap_generic_init();
+}
+
#if defined(CONFIG_SOC_OMAP2420)
static const char *omap242x_boards_compat[] __initdata = {
ti,omap2420,
@@ -89,7 +126,7 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened Device
Tree))
.map_io = omap3_map_io,
.init_early = omap3430_init_early,
.init_irq = omap3_init_irq,
- .init_machine = omap_generic_init,
+ .init_machine = omap3_init,
.timer = omap3_timer,
.dt_compat = omap3_boards_compat,
MACHINE_END
@@ -106,7 +143,7 @@ DT_MACHINE_START(OMAP4_DT, Generic OMAP4 (Flattened Device
Tree))
.map_io = omap4_map_io,
.init_early = omap4430_init_early,
.init_irq = gic_init_irq,
- .init_machine = omap_generic_init,
+ .init_machine = omap4_init,
.timer = omap4_timer,
.dt_compat = omap4_boards_compat,
MACHINE_END
--
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 07/11] OMAP2+: board-generic: Add DT support to generic board
Re-cycle the original board-generic file to support Device Tree
for every OMAP2+ variants.
Note: Since it is a completely new content in the existing file
I removed the original copyright.
The current approach is an intermediate step before having only
one machine descriptor that will use some generic DT aware
functions.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Kconfig |8 ++-
arch/arm/mach-omap2/board-generic.c | 129 ++
2 files changed, 89 insertions(+), 48 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 7edf802..5934a27 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -106,9 +106,13 @@ comment OMAP Board Type
depends on ARCH_OMAP2PLUS
config MACH_OMAP_GENERIC
- bool Generic OMAP board
- depends on ARCH_OMAP2
+ bool Generic OMAP2+ board
+ depends on ARCH_OMAP2PLUS
+ select USE_OF
default y
+ help
+ Support for generic TI OMAP2+ boards using Flattened Device Tree.
+ More information at Documentation/devicetree
config MACH_OMAP2_TUSB6010
bool
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index e8d45d3..dcbd64c 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -1,76 +1,113 @@
/*
- * linux/arch/arm/mach-omap2/board-generic.c
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
*
- * Copyright (C) 2005 Nokia Corporation
- * Author: Paul Mundt paul.mu...@nokia.com
- *
- * Modified from mach-omap/omap1/board-generic.c
- *
- * Code for generic OMAP2 board. Should work on many OMAP2 systems where
- * the bootloader passes the board-specific data to the kernel.
- * Do not put any board specific code to this file; create a new machine
- * type if you need custom low-level initializations.
+ * Support for generic OMAP2+ device tree boards.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
-#include linux/kernel.h
-#include linux/init.h
-#include linux/device.h
+#include linux/io.h
+#include linux/of_platform.h
+#include linux/irqdomain.h
#include mach/hardware.h
-#include asm/mach-types.h
#include asm/mach/arch.h
-#include asm/mach/map.h
-#include mach/gpio.h
-#include plat/usb.h
#include plat/board.h
#include plat/common.h
+#include mach/omap4-common.h
-static struct omap_board_config_kernel generic_config[] = {
+
+static struct of_device_id omap_dt_match_table[] __initdata = {
+ { .compatible = simple-bus, },
+ { .compatible = ti,omap-infra, },
+ { }
};
-static void __init omap_generic_init_early(void)
-{
- omap2_init_common_infrastructure();
-}
+static struct of_device_id intc_match[] __initdata = {
+ { .compatible = ti,omap3-intc, },
+ { .compatible = arm,cortex-a9-gic, },
+ { }
+};
static void __init omap_generic_init(void)
{
+ struct device_node *node = of_find_matching_node(NULL, intc_match);
+ if (node)
+ irq_domain_add_simple(node, 0);
+
omap_serial_init();
omap_sdrc_init(NULL, NULL);
- omap_board_config = generic_config;
- omap_board_config_size = ARRAY_SIZE(generic_config);
-}
-static void __init omap_generic_map_io(void)
-{
- if (cpu_is_omap242x()) {
- omap2_set_globals_242x();
- omap242x_map_common_io();
- } else if (cpu_is_omap243x()) {
- omap2_set_globals_243x();
- omap243x_map_common_io();
- } else if (cpu_is_omap34xx()) {
- omap2_set_globals_3xxx();
- omap34xx_map_common_io();
- } else if (cpu_is_omap44xx()) {
- omap2_set_globals_443x();
- omap44xx_map_common_io();
- }
+ of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
}
-/* XXX This machine entry name should be updated */
-MACHINE_START(OMAP_GENERIC, Generic OMAP24xx)
- /* Maintainer: Paul Mundt paul.mu...@nokia.com */
- .atag_offset= 0x100,
+#if defined(CONFIG_SOC_OMAP2420)
+static const char *omap242x_boards_compat[] __initdata = {
+ ti,omap2420,
+ NULL,
+};
+
+DT_MACHINE_START(OMAP242X_DT, Generic OMAP2420 (Flattened Device Tree))
.reserve= omap_reserve,
- .map_io = omap_generic_map_io,
- .init_early = omap_generic_init_early,
+ .map_io = omap242x_map_io,
+ .init_early = omap2420_init_early,
.init_irq = omap2_init_irq,
.init_machine = omap_generic_init,
.timer = omap2_timer,
+ .dt_compat = omap242x_boards_compat,
+MACHINE_END
+#endif
+
+#if defined(CONFIG_SOC_OMAP2430)
+static const char
[PATCH 09/11] OMAP2+: l3-noc: Add support for device-tree
Add device-tree support for the l3-noc driver.
Use platform_driver_register to defer the probing at device init
time.
Add documentation for the l3-noc bindings.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
.../devicetree/bindings/arm/omap/l3-noc.txt| 19
arch/arm/mach-omap2/omap_l3_noc.c | 23 +++
2 files changed, 37 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/l3-noc.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt
b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt
new file mode 100644
index 000..6888a5e
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt
@@ -0,0 +1,19 @@
+* TI - L3 Network On Chip (NoC)
+
+This version is an implementation of the generic NoC IP
+provided by Arteris.
+
+Required properties:
+- compatible : Should be ti,omap3-l3-smx for OMAP3 family
+ Should be ti,omap4-l3-noc for OMAP4 family
+- ti,hwmods: l3_main_1, ... One hwmod for each noc domain.
+
+Examples:
+
+ocp {
+ compatible = ti,omap4-l3-noc, simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ ti,hwmods = l3_main_1, l3_main_2, l3_main_3;
+};
diff --git a/arch/arm/mach-omap2/omap_l3_noc.c
b/arch/arm/mach-omap2/omap_l3_noc.c
index 7b9f190..d618c9d 100644
--- a/arch/arm/mach-omap2/omap_l3_noc.c
+++ b/arch/arm/mach-omap2/omap_l3_noc.c
@@ -120,7 +120,7 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
return IRQ_HANDLED;
}
-static int __init omap4_l3_probe(struct platform_device *pdev)
+static int __devinit omap4_l3_probe(struct platform_device *pdev)
{
static struct omap4_l3 *l3;
struct resource *res;
@@ -214,7 +214,7 @@ err0:
return ret;
}
-static int __exit omap4_l3_remove(struct platform_device *pdev)
+static int __devexit omap4_l3_remove(struct platform_device *pdev)
{
struct omap4_l3 *l3 = platform_get_drvdata(pdev);
@@ -228,16 +228,29 @@ static int __exit omap4_l3_remove(struct platform_device
*pdev)
return 0;
}
+#if defined(CONFIG_OF)
+static const struct of_device_id l3_noc_match[] = {
+ {.compatible = ti,omap4-l3-noc, },
+ {},
+}
+MODULE_DEVICE_TABLE(of, l3_noc_match);
+#else
+#define l3_noc_match NULL
+#endif
+
static struct platform_driver omap4_l3_driver = {
- .remove = __exit_p(omap4_l3_remove),
+ .probe = omap4_l3_probe,
+ .remove = __devexit_p(omap4_l3_remove),
.driver = {
- .name = omap_l3_noc,
+ .name = omap_l3_noc,
+ .owner = THIS_MODULE,
+ .of_match_table = l3_noc_match,
},
};
static int __init omap4_l3_init(void)
{
- return platform_driver_probe(omap4_l3_driver, omap4_l3_probe);
+ return platform_driver_register(omap4_l3_driver);
}
postcore_initcall_sync(omap4_l3_init);
--
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 10/11] arm/dts: OMAP4: Add a main ocp entry bound to l3-noc driver
Used the main OCP node to add bindings with the l3_noc driver.
Remove l3_noc static device creation if DT is populated.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |3 ++-
arch/arm/mach-omap2/devices.c |5 +
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d4131e3..b85a39d 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -63,10 +63,11 @@
* hierarchy.
*/
ocp {
- compatible = simple-bus;
+ compatible = ti,omap4-l3-noc, simple-bus;
#address-cells = 1;
#size-cells = 1;
ranges;
+ ti,hwmods = l3_main_1, l3_main_2, l3_main_3;
gic: interrupt-controller@48241000 {
compatible = arm,cortex-a9-gic;
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2d4a199..0f8e0eb 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -16,6 +16,7 @@
#include linux/clk.h
#include linux/err.h
#include linux/slab.h
+#include linux/of.h
#include mach/hardware.h
#include mach/irqs.h
@@ -77,6 +78,10 @@ static int __init omap4_l3_init(void)
struct platform_device *pdev;
char oh_name[L3_MODULES_MAX_LEN];
+ /* If dtb is there, the devices will be created dynamically */
+ if (of_have_populated_dt())
+ return -ENODEV;
+
/*
* To avoid code running on other OMAPs in
* multi-omap builds
--
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 11/11] arm/dts: OMAP3+: Add mpu, dsp and iva nodes
Add nodes for devices used by PM code (mpu, dsp, iva).
Add an empty cpus node as well as recommended in the DT spec.
Remove mpu, dsp, iva devices init if dt is populated.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Kevin Hilman khil...@ti.com
---
Documentation/devicetree/bindings/arm/omap/dsp.txt | 14 ++
Documentation/devicetree/bindings/arm/omap/iva.txt | 19 ++
Documentation/devicetree/bindings/arm/omap/mpu.txt | 27
arch/arm/boot/dts/omap3.dtsi | 19 ++
arch/arm/boot/dts/omap4.dtsi | 23 +
arch/arm/mach-omap2/pm.c |3 +-
6 files changed, 104 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/dsp.txt
create mode 100644 Documentation/devicetree/bindings/arm/omap/iva.txt
create mode 100644 Documentation/devicetree/bindings/arm/omap/mpu.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/dsp.txt
b/Documentation/devicetree/bindings/arm/omap/dsp.txt
new file mode 100644
index 000..325feef
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/dsp.txt
@@ -0,0 +1,14 @@
+* TI - DSP (Digital Signal Processor)
+
+TI DSP included in OMAP SoC
+
+Required properties:
+- compatible : Should be ti,omap3-c64 for OMAP3 4
+- ti,hwmods: dsp
+
+Examples:
+
+dsp {
+compatible = ti,omap3-c64;
+ti,hwmods = dsp;
+};
diff --git a/Documentation/devicetree/bindings/arm/omap/iva.txt
b/Documentation/devicetree/bindings/arm/omap/iva.txt
new file mode 100644
index 000..b889475
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/iva.txt
@@ -0,0 +1,19 @@
+* TI - IVA (Imaging and Video Accelerator) subsystem
+
+The IVA contain various audio, video or imaging HW accelerator
+depending of the version.
+
+Required properties:
+- compatible : Should be:
+ - ti,ivahd for OMAP4
+ - ti,iva2.2 for OMAP3
+ - ti,iva2.1 for OMAP2430
+ - ti,iva1 for OMAP2420
+- ti,hwmods: iva
+
+Examples:
+
+iva {
+compatible = ti,ivahd, ti,iva;
+ti,hwmods = iva;
+};
diff --git a/Documentation/devicetree/bindings/arm/omap/mpu.txt
b/Documentation/devicetree/bindings/arm/omap/mpu.txt
new file mode 100644
index 000..5ffbacd
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/mpu.txt
@@ -0,0 +1,27 @@
+* TI - MPU (Main Processor Unit) subsystem
+
+The MPU subsystem contain one or several ARM cores
+depending of the version.
+The MPU contain CPUs, GIC, L2 cache and a local PRCM.
+
+Required properties:
+- compatible : Should be ti,omap3-mpu for OMAP3
+ Should be ti,omap4-mpu for OMAP4
+- ti,hwmods: mpu
+
+Examples:
+
+- For an OMAP4 SMP system:
+
+mpu {
+compatible = ti,omap4-mpu;
+ti,hwmods = mpu;
+};
+
+
+- For an OMAP3 monocore system:
+
+mpu {
+compatible = ti,omap3-mpu;
+ti,hwmods = mpu;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index d558785..d202bb5 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -13,12 +13,31 @@
/ {
compatible = ti,omap3430, ti,omap3;
+ cpus {
+ cpu@0 {
+ compatible = arm,cortex-a8;
+ };
+ };
+
/*
* The soc node represents the soc top level view. It is uses for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
*/
soc {
compatible = ti,omap-infra;
+ mpu {
+ compatible = ti,omap3-mpu;
+ ti,hwmods = mpu;
+ };
+
+ iva {
+ compatible = ti,iva2.2;
+ ti,hwmods = iva;
+
+ dsp {
+ compatible = ti,omap3-c64;
+ };
+ };
};
/*
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index b85a39d..4c61c82 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -23,12 +23,35 @@
aliases {
};
+ cpus {
+ cpu@0 {
+ compatible = arm,cortex-a9;
+ };
+ cpu@1 {
+ compatible = arm,cortex-a9;
+ };
+ };
+
/*
* The soc node represents the soc top level view. It is uses for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
*/
soc {
compatible = ti,omap-infra;
+ mpu {
+ compatible = ti,omap4-mpu;
+ ti,hwmods = mpu;
+ };
+
+ dsp {
+ compatible = ti,omap3-c64;
+ ti,hwmods = dsp;
+ };
+
+ iva {
+ compatible = ti,ivahd;
+ ti,hwmods =
[GIT PULL] omap cleanup part2 for v3.2 merge window
Hi Arnd, Please pull omap cleanup branch again from: git://github.com/tmlind/linux.git cleanup This contains a fix for earlier cleanup patches and has omap_device cleanup and PM cleanup merged in. As some of the later cleanup was based on a -rc6 while the earlier branch was based on -rc4, the git request pull against the earlier cleanup produces noise. So instead, below is a diff to the previous pull request against -rc7 that show the incremental changes. Regards, Tony --- /tmp/old2011-09-23 14:32:54.435085320 -0700 +++ /tmp/new2011-09-23 14:33:09.163108235 -0700 @@ -4,7 +4,30 @@ are available in the git repository at: - git://github.com/tmlind/linux.git cleanup-part1 + git://github.com/tmlind/linux.git cleanup + +Grazvydas Ignotas (1): + OMAP: omap_device: make latency autoadjust messages debug + +Jarkko Nikula (1): + omap: mcbsp: Remove omap device API + +Johan Hovold (2): + OMAP2+: PM: fix typos in misc. comment and error messages + OMAP2+: PM: clean up error messages: replace printk with pr_err. + +Kevin Hilman (8): + OMAP: omap_device: replace debug/warning/error prints with dev_* macros + OMAP: omap_device: remove internal functions from omap_device.h + OMAP: omap_device: when building return platform_device instead of omap_device + OMAP: omap_device: device register functions now take platform_device pointer + OMAP: omap_device: _disable_idle_on_suspend() takes platform_device pointer + OMAP: omap_device: decouple platform_device from omap_device + OMAP3: PM: fix UART handling when using no_console_suspend + ARM: 7082/1: platform_device: pdev_archdata: add omap_device pointer + +Michael Jones (1): + OMAP2: PM debug: remove leftover debug code Paul Walmsley (12): OMAP3: id: remove identification codes that only correspond to marketing names @@ -20,12 +43,16 @@ OMAP2+: hwmod: remove OMAP_CHIP* OMAP: id: remove OMAP_CHIP declarations, code -Tony Lindgren (4): +Tony Lindgren (7): omap2+: Use Kconfig symbol in Makefile instead of obj-y ARM: OMAP: Move omap2_init_common_devices out of init_early ARM: OMAP: Introduce SoC specific early_init Merge branch 'omap_chip_remove_cleanup_3.2' of git://git.pwsan.com/linux-2.6 into cleanup + ARM: OMAP2+: Fix missing inline functions for Makefile cleanup + Merge branch 'for_3.2/omap_device' of git://gitorious.org/khilman/linux-omap-pm into cleanup + Merge branch 'for_3.2/pm-cleanup' of git://gitorious.org/khilman/linux-omap-pm into cleanup + arch/arm/include/asm/device.h|5 + arch/arm/mach-omap2/Makefile | 81 +-- arch/arm/mach-omap2/board-2430sdp.c |9 +- arch/arm/mach-omap2/board-3430sdp.c |9 +- @@ -37,6 +64,8 @@ arch/arm/mach-omap2/board-cm-t35.c | 13 +- arch/arm/mach-omap2/board-cm-t3517.c |9 +- arch/arm/mach-omap2/board-devkit8000.c | 12 +- + arch/arm/mach-omap2/board-flash.c|5 - + arch/arm/mach-omap2/board-flash.h| 19 + arch/arm/mach-omap2/board-generic.c |2 +- arch/arm/mach-omap2/board-h4.c |9 +- arch/arm/mach-omap2/board-igep0020.c | 13 +- @@ -64,13 +93,24 @@ arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c | 803 +- arch/arm/mach-omap2/clockdomains3xxx_data.c | 398 +++ arch/arm/mach-omap2/clockdomains44xx_data.c | 409 +++- + arch/arm/mach-omap2/devices.c| 44 +- + arch/arm/mach-omap2/display.c|6 +- + arch/arm/mach-omap2/dma.c| 16 +- + arch/arm/mach-omap2/gpio.c | 10 +- + arch/arm/mach-omap2/hsmmc.c |8 +- + arch/arm/mach-omap2/hwspinlock.c |8 +- arch/arm/mach-omap2/id.c | 191 ++ arch/arm/mach-omap2/io.c | 52 ++- + arch/arm/mach-omap2/mcbsp.c |8 +- arch/arm/mach-omap2/omap_hwmod.c |3 - arch/arm/mach-omap2/omap_hwmod_2420_data.c | 37 - arch/arm/mach-omap2/omap_hwmod_2430_data.c | 45 -- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 169 +++--- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 82 --- + arch/arm/mach-omap2/opp.c|2 +- + arch/arm/mach-omap2/pm.c | 30 +- + arch/arm/mach-omap2/pm24xx.c | 27 - + arch/arm/mach-omap2/pm34xx.c |2 +- arch/arm/mach-omap2/powerdomain-common.c |7 +- arch/arm/mach-omap2/powerdomain.c| 87 ++- arch/arm/mach-omap2/powerdomain.h|9 +- @@ -78,12 +118,18 @@ arch/arm/mach-omap2/powerdomains2xxx_data.c | 44 +- arch/arm/mach-omap2/powerdomains3xxx_data.c
Re: [PATCHv9 00/18] omap PRCM chain handler
On Fri, 23 Sep 2011 15:46:08 +0300, Tero Kristo said: Following set contains the version 9 of this work. This patch set contains a number of patches tagged as 'TEMP', they are only meant for testing purposes and to provide proof of concept. Most of the 'TEMP' patches are related to UART runtime handling and they will be replaced by work done by Govindraj Raja. What do we do with these TEMP patches if the UART patches don't make the same merge window, or have other issues? I'm always leery of will be replaced code, because I've seen too many times when it *didn't* get replaced. (I really don't care what the 'Plan B' is, as long as we have one...) pgpprmOWHQJUp.pgp Description: PGP signature
Re: [PATCH 10/11] arm/dts: OMAP4: Add a main ocp entry bound to l3-noc driver
* Benoit Cousson b-cous...@ti.com [110923 12:50]: Used the main OCP node to add bindings with the l3_noc driver. Remove l3_noc static device creation if DT is populated. --- a/arch/arm/mach-omap2/devices.c +++ b/arch/arm/mach-omap2/devices.c @@ -16,6 +16,7 @@ #include linux/clk.h #include linux/err.h #include linux/slab.h +#include linux/of.h #include mach/hardware.h #include mach/irqs.h @@ -77,6 +78,10 @@ static int __init omap4_l3_init(void) struct platform_device *pdev; char oh_name[L3_MODULES_MAX_LEN]; + /* If dtb is there, the devices will be created dynamically */ + if (of_have_populated_dt()) + return -ENODEV; + /* * To avoid code running on other OMAPs in * multi-omap builds How about just remove omap3_l3_init and omap4_l3_init completely instead? There should not be any need for the platform glue code if the driver, it's OK for us to require that either DT is passed from the bootloader or as appended DT as soon as the appended DT patches are merged. 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 01/11] OMAP2+: Add SoC specific map_io functions
* Benoit Cousson b-cous...@ti.com [110923 12:50]:
Add SoC specific map_io function to be used by the generic DT
board file. This is an intermediate step before having some
generic DT aware map_io function.
Thanks, I'll apply this into cleanup branch and with the related
conversion of board files.
Regards,
Tony
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/common.c | 18 ++
arch/arm/plat-omap/include/plat/common.h |4
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 3f20cbb..de61f15 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -56,6 +56,12 @@ void __init omap2_set_globals_242x(void)
{
__omap2_set_globals(omap242x_globals);
}
+
+void __init omap242x_map_io(void)
+{
+ omap2_set_globals_242x();
+ omap242x_map_common_io();
+}
#endif
#if defined(CONFIG_SOC_OMAP2430)
@@ -74,6 +80,12 @@ void __init omap2_set_globals_243x(void)
{
__omap2_set_globals(omap243x_globals);
}
+
+void __init omap243x_map_io(void)
+{
+ omap2_set_globals_243x();
+ omap243x_map_common_io();
+}
#endif
#if defined(CONFIG_ARCH_OMAP3)
@@ -138,5 +150,11 @@ void __init omap2_set_globals_443x(void)
omap2_set_globals_control(omap4_globals);
omap2_set_globals_prcm(omap4_globals);
}
+
+void __init omap4_map_io(void)
+{
+ omap2_set_globals_443x();
+ omap44xx_map_common_io();
+}
#endif
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index 5cac97e..abda2c7 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -83,7 +83,11 @@ void omap2_set_globals_sdrc(struct omap_globals *);
void omap2_set_globals_control(struct omap_globals *);
void omap2_set_globals_prcm(struct omap_globals *);
+void omap242x_map_io(void);
+void omap243x_map_io(void);
void omap3_map_io(void);
+void omap4_map_io(void);
+
/**
* omap_test_timeout - busy-loop, testing a condition
--
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 07/11] OMAP2+: board-generic: Add DT support to generic board
* Benoit Cousson b-cous...@ti.com [110923 12:50]: Re-cycle the original board-generic file to support Device Tree for every OMAP2+ variants. Note: Since it is a completely new content in the existing file I removed the original copyright. I'd suggest just keeping it, maybe just update the comments accordingly? That's because Copyrights in general just don't disappear. And the meaning of the board-generic is still the same as originally, that is do the booting based on board-specific data passed from the bootloader like the comments say: - * Code for generic OMAP2 board. Should work on many OMAP2 systems where - * the bootloader passes the board-specific data to the kernel. - * Do not put any board specific code to this file; create a new machine - * type if you need custom low-level initializations. + * Support for generic OMAP2+ device tree boards. 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 08/11] OMAP2+: board-generic: Add i2c static init
* Benoit Cousson b-cous...@ti.com [110923 12:50]: Still needed to boot until the i2c twl driver is adapted to device-tree. Otherwise the voltage control code will try to access the twl and crash. That sounds OK to me for now. For merging these patches, how about the following: - Kevin queues up the omap_device related changes - Grant queues up the .dts changes - I'll queue the map_io and board changes based on Kevin's omap_device changes 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 03/11] arm/dts: Add support for OMAP4 PandaBoard
On Fri, Sep 23, 2011 at 10:23:11PM +0200, Benoit Cousson wrote:
Based on the original omap4-panda.dts file from Manju.
http://www.spinics.net/lists/linux-omap/msg55836.html
Add memory information and a default bootargs to allow
a boot from RAMDISK.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap4-panda.dts
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
new file mode 100644
index 000..c702657
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -0,0 +1,29 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ omap4.dtsi
+
+/ {
+ model = TI OMAP4 PandaBoard;
+ compatible = ti,omap4-panda, ti,omap4430, ti,omap4;
+
+ /*
+ * Since the initial device tree board file does not create any
+ * devices (MMC, network...), the only way to boot is to provide a
+ * ramdisk.
+ */
+ chosen {
+ bootargs = root=/dev/ram0 rw console=ttyO2,115200n8
initrd=0x8160,20M ramdisk_size=20480 no_console_suspend debug;
Generally, we don't want bootargs in the .dts files; we want them
added to the .dtb by the boot firmware. However, we are bootstrapping
here, so I'm okay with it in the short term until firmware matures a
bit more.
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x4000; /* 1 GB */
+ };
+};
--
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 11/11] arm/dts: OMAP3+: Add mpu, dsp and iva nodes
On Fri, Sep 23, 2011 at 10:23:19PM +0200, Benoit Cousson wrote:
Add nodes for devices used by PM code (mpu, dsp, iva).
Add an empty cpus node as well as recommended in the DT spec.
Remove mpu, dsp, iva devices init if dt is populated.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Kevin Hilman khil...@ti.com
Series looks good to me on brief review.
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
Documentation/devicetree/bindings/arm/omap/dsp.txt | 14 ++
Documentation/devicetree/bindings/arm/omap/iva.txt | 19 ++
Documentation/devicetree/bindings/arm/omap/mpu.txt | 27
arch/arm/boot/dts/omap3.dtsi | 19 ++
arch/arm/boot/dts/omap4.dtsi | 23 +
arch/arm/mach-omap2/pm.c |3 +-
6 files changed, 104 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/dsp.txt
create mode 100644 Documentation/devicetree/bindings/arm/omap/iva.txt
create mode 100644 Documentation/devicetree/bindings/arm/omap/mpu.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/dsp.txt
b/Documentation/devicetree/bindings/arm/omap/dsp.txt
new file mode 100644
index 000..325feef
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/dsp.txt
@@ -0,0 +1,14 @@
+* TI - DSP (Digital Signal Processor)
+
+TI DSP included in OMAP SoC
+
+Required properties:
+- compatible : Should be ti,omap3-c64 for OMAP3 4
+- ti,hwmods: dsp
+
+Examples:
+
+dsp {
+compatible = ti,omap3-c64;
+ti,hwmods = dsp;
+};
diff --git a/Documentation/devicetree/bindings/arm/omap/iva.txt
b/Documentation/devicetree/bindings/arm/omap/iva.txt
new file mode 100644
index 000..b889475
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/iva.txt
@@ -0,0 +1,19 @@
+* TI - IVA (Imaging and Video Accelerator) subsystem
+
+The IVA contain various audio, video or imaging HW accelerator
+depending of the version.
+
+Required properties:
+- compatible : Should be:
+ - ti,ivahd for OMAP4
+ - ti,iva2.2 for OMAP3
+ - ti,iva2.1 for OMAP2430
+ - ti,iva1 for OMAP2420
+- ti,hwmods: iva
+
+Examples:
+
+iva {
+compatible = ti,ivahd, ti,iva;
+ti,hwmods = iva;
+};
diff --git a/Documentation/devicetree/bindings/arm/omap/mpu.txt
b/Documentation/devicetree/bindings/arm/omap/mpu.txt
new file mode 100644
index 000..5ffbacd
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/mpu.txt
@@ -0,0 +1,27 @@
+* TI - MPU (Main Processor Unit) subsystem
+
+The MPU subsystem contain one or several ARM cores
+depending of the version.
+The MPU contain CPUs, GIC, L2 cache and a local PRCM.
+
+Required properties:
+- compatible : Should be ti,omap3-mpu for OMAP3
+ Should be ti,omap4-mpu for OMAP4
+- ti,hwmods: mpu
+
+Examples:
+
+- For an OMAP4 SMP system:
+
+mpu {
+compatible = ti,omap4-mpu;
+ti,hwmods = mpu;
+};
+
+
+- For an OMAP3 monocore system:
+
+mpu {
+compatible = ti,omap3-mpu;
+ti,hwmods = mpu;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index d558785..d202bb5 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -13,12 +13,31 @@
/ {
compatible = ti,omap3430, ti,omap3;
+ cpus {
+ cpu@0 {
+ compatible = arm,cortex-a8;
+ };
+ };
+
/*
* The soc node represents the soc top level view. It is uses for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
*/
soc {
compatible = ti,omap-infra;
+ mpu {
+ compatible = ti,omap3-mpu;
+ ti,hwmods = mpu;
+ };
+
+ iva {
+ compatible = ti,iva2.2;
+ ti,hwmods = iva;
+
+ dsp {
+ compatible = ti,omap3-c64;
+ };
+ };
};
/*
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index b85a39d..4c61c82 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -23,12 +23,35 @@
aliases {
};
+ cpus {
+ cpu@0 {
+ compatible = arm,cortex-a9;
+ };
+ cpu@1 {
+ compatible = arm,cortex-a9;
+ };
+ };
+
/*
* The soc node represents the soc top level view. It is uses for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
*/
soc {
compatible = ti,omap-infra;
+ mpu {
+ compatible = ti,omap4-mpu;
+ ti,hwmods = mpu;
+ };
+
+
Re: [PATCH 08/11] OMAP2+: board-generic: Add i2c static init
On Fri, Sep 23, 2011 at 04:12:08PM -0700, Tony Lindgren wrote: * Benoit Cousson b-cous...@ti.com [110923 12:50]: Still needed to boot until the i2c twl driver is adapted to device-tree. Otherwise the voltage control code will try to access the twl and crash. That sounds OK to me for now. For merging these patches, how about the following: - Kevin queues up the omap_device related changes - Grant queues up the .dts changes - I'll queue the map_io and board changes based on Kevin's omap_device changes Go ahead and queue up the .dts changes in your tree. No need to split them up. 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 v7 00/26] gpio/omap: driver cleanup and fixes
[...] After debugging this myself a bit, here's what I think may be going on. This may not be the only problem but here's at least one of them. First, debounce clocks are disabled in the runtime_suspend callback. When a GPIO is freed and it's the last one in the bank, bank-mod_usage goes to zero. After that, pm_runtime_put_sync() is called, which will trigger the driver's -runtime_suspend callback. The -runtime_suspend() callback checks bank-mod_usage as well, and if zero, doesn't do anything (notably, it doesn't disable debounce clocks.) I need some clarification in reproducing/testing the fix on OMAP3430SDP. The first thing I am trying to verify is the code flow of suspend. 1) With no debounce clock enabled, when I enable UART timeouts, I automatically see system going to retention. That is I don't have to type echo mem /sys/power/state echo 5 /sys/devices/platform/omap/omap_uart.0/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.1/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.2/sleep_timeout 2) I am do not see the print in omap_gpio_suspend/resume(), but I see the print in *_prepare_for_idle()/*_resume_after_idle(). Folks testing on Tablet2 platform said there is dedicated button to suspend/resume. Is there something equivalent? -- Tarun -- To unsubscribe from this list: send the line unsubscribe 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: [PATCHv9 00/18] omap PRCM chain handler
Hi Valdis.Kletnieks, On Sat, Sep 24, 2011 at 3:53 AM, valdis.kletni...@vt.edu wrote: On Fri, 23 Sep 2011 15:46:08 +0300, Tero Kristo said: Following set contains the version 9 of this work. This patch set contains a number of patches tagged as 'TEMP', they are only meant for testing purposes and to provide proof of concept. Most of the 'TEMP' patches are related to UART runtime handling and they will be replaced by work done by Govindraj Raja. What do we do with these TEMP patches if the UART patches don't make the same merge window, or have other issues? I'm always leery of will be replaced code, because I've seen too many times when it *didn't* get replaced. (I really don't care what the 'Plan B' is, as long as we have one...) UART Runtime patches are already posted for review and it's also targeted for next merge window. Our intention is to push both the features together for next merge window. Regards Vishwa ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv9 00/18] omap PRCM chain handler
On Sat, 24 Sep 2011 10:54:29 +0530, Sripathy, Vishwanath said: UART Runtime patches are already posted for review and it's also targeted for next merge window. Our intention is to push both the features together for next merge window. Oh, OK. That should work then. Thanks for the clarification... pgpy6RReAWKiK.pgp Description: PGP signature
