RE: [PATCH v4-alt 3/6] ARM: OMAP3: hwmod data: add gpmc
Hi Paul, On Tue, May 08, 2012 at 21:02:33, Paul Walmsley wrote: Major reason was that there are some boards that rely on bootloader settings, eg. kernel does not do any setting for smsc911x. I did not want to break those, at least it causes problem with omap3evm, see below But this is the whole point. The Linux GPMC driver and integration code should be setting up the GPMC registers based on board file and/or DT data, before the kernel touches any GPMC devices. We don't want to rely on the bootloader settings unless we absolutely have no other choice. Otherwise, the stability of the kernel could easily be impacted by the bootloader's GPMC timings and other register settings, and we want to minimize those potential sources of variation. So if we absolutely have no choice than to keep HWMOD_INIT_NO_RESET here, which doesn't sound like the case so far, we need to understand exactly why this is so. There are 14 out of 20 boards partially or fully relying on bootloader settings. I will try to do configuration for smsc911x in Kernel itself, this is the only one that can be tested from my side (on omap3evm), but there are other peripherals like NOR, quaduart, onenand-flash (different from omap-onenand), then smc91x (timings are not set from kernel for sdp boards), these would affect 7 boards of both omap2 omap3. To get configuration done from Kernel properly without having these boards is too tough for me. So I request you to keep HWMOD_INIT_NO_RESET (I will add configuration for smsc911x), please let me know your comments. Removing it causes multiple problems, one is that CS0 is valid after reset of module, with base address starting from zero, which causes requesting resource failure for CS0, with the way it is currently coded (GPMC resource starts from 1MB). Can't this be handled by using a custom hwmod reset function for the GPMC? No too familiar with hwmod, let me try that Another issue on OMAP3EVM is the detection of evm revision based on phy id, by reading hardcoded address, 0x2c00. It had to be skipped to reach till above mentioned. Looking at omap3_evm_get_revision() it seems that the OMAP3EVM detection happens by reading the Ethernet chip's revision register. So can't this be fixed by programming the GPMC appropriately to access the Ethernet chip first? I did not get you, may be let me explain the problem once again, 0x2c00 is physical address configured by bootloader. And omap3evm board file depends on this value to read eth chip revision register. Ideally this register should be accessed by smsc911x driver only. Once gpmc is reset, physical address for smsc911x can vary. With gpmc driver conversion, address of smsc911x register would be available only to smsc911x driver, and this address would not be setup until gpmc driver is probed, and so would not available for omap3_evm_get_revision, which has to be called before gpmc device registration. And here we are depending on eth revision register to find board revision. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] ARM: OMAP4: Add PMU Support
Jon, On Thu, May 10, 2012 at 3:03 AM, Jon Hunter jon-hun...@ti.com wrote: From: Jon Hunter jon-hun...@ti.com This series adds PMU support for OMAP4 devices. This is based upon Will Deacons series [1]. This series attempts to fix the management of the EMU power domain so that PMU can be enabled at runtime and low-power states are not prevented when PMU is not in-use. The fix is based upon inputs from Benoit, Paul and Kevin [2]. This series is based upon the latest linux-omap master branch from Tony and has been tested on a OMAP4460 panda. OMAP4460/70 devices too have dependency on the EMU domain so even though there is a possibility to route PMU IRQ events bypassing the CTI, we will still have the same issue. So the fix is needed for all OMAP4 devices. In OMAP5+ devices, PMU dependency with EMU domain is completely removed. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] Re-map the CTIs IRQs from MPU to DEBUGSS
On Thu, May 10, 2012 at 3:05 AM, Jon Hunter jon-hun...@ti.com wrote: From: Jon Hunter jon-hun...@ti.com In order to use the CTI interrupts inconjunction with the DEBUGSS we need to re-map the CTI IRQs to the DEBUGSS HWMOD. This is based upon Benoit Cousson's patch [1]. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/073319.html Cc: Ming Lei ming@canonical.com Cc: Will Deacon will.dea...@arm.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com Signed-off-by: Jon Hunter jon-hun...@ti.com --- Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] arm: omap4: create pmu device via hwmod
On Thu, May 10, 2012 at 3:05 AM, Jon Hunter jon-hun...@ti.com wrote: From: Ming Lei ming@canonical.com The following modules is required to be enabled before configuring cross trigger interface for enabling pmu irq: l3_instr, l3_main_3, debugss so build the arm-pmu device via the three hwmods. Cc: Ming Lei ming@canonical.com Cc: Will Deacon will.dea...@arm.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com Signed-off-by: Ming Lei ming@canonical.com Signed-off-by: Will Deacon will.dea...@arm.com Signed-off-by: Jon Hunter jon-hun...@ti.com --- $subject: s/arm: omap4: / ARM: OMAP4 To be consistent with rest of the series. Same comment for patch 1/6 as well Rest of the patch is fine. Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 05/10] ARM: OMAP2+: SmartReflex: introduce a busy loop condition test macro
On Tue, May 8, 2012 at 3:47 PM, AnilKumar, Chimata anilku...@ti.com wrote:
On Mon, May 07, 2012 at 10:51:53, J, KEERTHY wrote:
On Fri, May 4, 2012 at 2:42 PM, AnilKumar, Chimata anilku...@ti.com wrote:
On Thu, Apr 26, 2012 at 23:10:36, J, KEERTHY wrote:
From: Jean Pihet j-pi...@ti.com
Now that omap_test_timeout is only accessible from mach-omap2/,
introduce a similar function for SR.
This change makes the SmartReflex implementation ready for the move
to drivers/.
Signed-off-by: Jean Pihet j-pi...@ti.com
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 12 ++--
include/linux/power/smartreflex.h | 23 ++-
2 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index d859277..acef08d 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -289,9 +289,9 @@ static void sr_v1_disable(struct omap_sr *sr)
* Wait for SR to be disabled.
* wait until ERRCONFIG.MCUDISACKINTST = 1. Typical latency is 1us.
*/
- omap_test_timeout((sr_read_reg(sr, ERRCONFIG_V1)
- ERRCONFIG_MCUDISACKINTST), SR_DISABLE_TIMEOUT,
- timeout);
+ sr_test_cond_timeout((sr_read_reg(sr, ERRCONFIG_V1)
+ ERRCONFIG_MCUDISACKINTST), SR_DISABLE_TIMEOUT,
+ timeout);
if (timeout = SR_DISABLE_TIMEOUT)
dev_warn(sr-pdev-dev, %s: Smartreflex disable
timedout\n,
@@ -334,9 +334,9 @@ static void sr_v2_disable(struct omap_sr *sr)
* Wait for SR to be disabled.
* wait until IRQSTATUS.MCUDISACKINTST = 1. Typical latency is 1us.
*/
- omap_test_timeout((sr_read_reg(sr, IRQSTATUS)
- IRQSTATUS_MCUDISABLEACKINT), SR_DISABLE_TIMEOUT,
- timeout);
+ sr_test_cond_timeout((sr_read_reg(sr, IRQSTATUS)
+ IRQSTATUS_MCUDISABLEACKINT),
SR_DISABLE_TIMEOUT,
+ timeout);
if (timeout = SR_DISABLE_TIMEOUT)
dev_warn(sr-pdev-dev, %s: Smartreflex disable
timedout\n,
diff --git a/include/linux/power/smartreflex.h
b/include/linux/power/smartreflex.h
index 884eaee..78b795e 100644
--- a/include/linux/power/smartreflex.h
+++ b/include/linux/power/smartreflex.h
@@ -22,7 +22,7 @@
#include linux/types.h
#include linux/platform_device.h
-
+#include linux/delay.h
#include plat/voltage.h
/*
@@ -168,6 +168,27 @@ struct omap_sr {
};
/**
+ * test_cond_timeout - busy-loop, testing a condition
+ * @cond: condition to test until it evaluates to true
+ * @timeout: maximum number of microseconds in the timeout
+ * @index: loop index (integer)
+ *
+ * Loop waiting for @cond to become true or until at least @timeout
+ * microseconds have passed. To use, define some integer @index in the
+ * calling code. After running, if @index == @timeout, then the loop has
+ * timed out.
+ *
+ * Copied from omap_test_timeout */
+#define sr_test_cond_timeout(cond, timeout, index) \
+({ \
+ for (index = 0; index timeout; index++) { \
+ if (cond) \
+ break; \
+ udelay(1); \
+ } \
+})
I think we can use time_after()/time_before() APIs for timeout and
cpu_relax() for
tight loops instead of udelay().
cpu_relax() changes the priority everytime to low and will yield to
another thread.
Considering that we are checking the condition every microsecond does it make
some saving using cpu_relax().
cpu_relax() does not involve any priority changes or scheduling AFAICS.
Have a look at this thread:
http://www.spinics.net/lists/netdev/msg151699.html
Thanks. My bad. I meant yielding to another thread with in a space
of 1uS.
Regards
AnilKumar
--
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 4/6] ARM: OMAP4: PMU: Add runtime PM support
On Thu, May 10, 2012 at 3:05 AM, Jon Hunter jon-hun...@ti.com wrote: From: Jon Hunter jon-hun...@ti.com This patch is based upon Ming Lei's patch to add runtime PM support for OMAP4 [1]. In Ming's original patch the CTI interrupts were being enabled during runtime when the PMU was used but they were only configured once during init. Therefore move the configuration of the CTI interrupts to the runtime PM functions. You might want to give the reason why you need to move the re-confiuration from init to to run-time PM functions so that the actual issue of reset gets addressed. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074153.html Cc: Ming Lei ming@canonical.com Cc: Will Deacon will.dea...@arm.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com Signed-off-by: Jon Hunter jon-hun...@ti.com --- Patch as such looks fine to me. Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4-alt 0/6] GPMC driver migrate one
Hi Tony, On Wed, May 09, 2012 at 03:06:26, Tony Lindgren wrote: To resolve this and as per your earlier question on whether old along with new interface can be made to work parallely, here is suggestion from my end to deal with it. I think this is the only way to keep this all building and booting for each patch in the series, no? If so, then we should select this option. The first patch should be broken up into more readable patches, it seems that you can do that without breaking things. Bisectability has been maintained in the patches. Ok, I will proceed by keeping old new interface together, will try to achieve it in smaller patches and without hacks. Please let me know whether you are fine in taking patch series as in v4 (that converts all boards at once, with further revisions based on review comments). It seems that there are still some pending comments and we need to have the hwmod entries merged first by Paul. Ok, first I will try to get hwmod in. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] gpio/omap: remaining cleanups and fix
Hi Tarun,
On Fri, Apr 27, 2012 at 7:43 PM, Tarun Kanti DebBarma
tarun.ka...@ti.com wrote:
Here are the remaining cleanup patches. There are broadly
two categories of cleanups.
Cat-1: Those missed while introducing new feature like SPARSE_IRQ
handling and DT support; use edge/level handlers from
generic IRQ framework.
Cat-2: Removal of redundant fields from struct gpio_bank{} as a
result of they being already covered by members within
context field of struct gpio_bank{}.
Reference:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Commit: 66f75a5d028beaf67c931435fdc3e7823125730c (Linux 3.4-rc4)
Series is available for reference here:
git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev.git
for_3.5/gpio_more_cleanup_fixes
I tested this series from your tree on Beagle-XM retention, offmode,
suspend to mem and resume with and and without enabling offmode
from sysfs was checked and found retention count and off mode
count was getting incremented.
Also ran few test cases available from here[1] to request and release gpio,
test cases passed.
Feel Free to add:
Tested-by: Govindraj.R govindraj.r...@ti.com
--
Thanks
Govindraj.R
[1]:
http://gitorious.org/omap-ddt/omap-ddt/trees/master/gpio/test_code/utils/gpio_mods
--
To unsubscribe from this list: send the line unsubscribe 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] twl4030: Various fixes for charing-from-USB
Would you be able to help me understand exactly what it means for the USB bus to go to suspend? Is this something that the host initiates or something that the gadget initiates? Host initiates it, when host wants to suspend the whole bus or certain port, it will stop sending SOF, after 3ms of that, the device will pullup dp. After that, the bus is at suspend state (dp=3, dm=0). Please see: http://www.amebasystems.com/downloads/hardware/datasheets/USB/ usb_20_052709/Suspend%20Current%20ECN.pdf How does this relate to a simple charger? It that considered to have a non-suspended bus, or is it considered as a separate case? You may need a USB Charger driver which can differentiate dedicated charger (DCP), host charger (CDP), or pc host port(SDP). Only at SDP case, you need to consider suspend current limiation. Maybe we need to not suspend the USB OTG interface when the device as a whole enters suspend-to-RAM. Maybe we need to register a dummy gadget to the bus active while in suspend? Does the gadget have to be responsive while-ever the bus is not suspended? Maybe we can arrange for any USB activity to trigger a resume? Entering suspend while still charging really should be possible - at least with a dump charger and hopefully from a host port as well. I'll like to find the best way to achieve that, and any help you can provide would be greatly appreciated. The host may not limit charge current when the vbus is on, but the device should not draw much current when the host is suspended. Consider below case: There is a Media Player connecting at laptop (without connecting wall power), the laptop may suspend sometime later(vbus is still on), the Media Player may go on working and continue drawing hundreds of mA from the host. Some hours later, the capacity of laptop will be exhausted which is not expected. -- To unsubscribe from this list: send the line unsubscribe 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] OMAPDSS: TFP410: use gpio_set_value_cansleep
On Wed, 2012-05-09 at 16:37 -0700, Tony Lindgren wrote: * Russ Dill russ.d...@ti.com [120509 15:53]: On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren t...@atomide.com wrote: * Russ Dill russ.d...@ti.com [120509 15:12]: The Beagleboard xM gpio used for TFP410 powerdown is connected through an I2C attached chip which means setting the GPIO can sleep. Code that calls tfp410_power_on/off holds a mutex, so sleeping should be fine. What's the error without this patch? Or just no display? Just wondering if it's safe to merge Tomi's clean up series to arm-soc tree.. The only platform that has a problem is Beagleboard xM, and that is only after 'ARM: OMAP: Cleanup Beagleboard DVI reset gpio' is applied. Since the context actually can sleep, the only consequence is a WARN_ON statement. So yes, it should be safe. Well since I have not actually merged it with other branches yet, I'll wait for Tomi to apply that and repull his for-l-o-3.5 branch. You can pull for-l-o-3.5 as it is now, there's no need to change it. This _cansleep change is a separate dss specific change. So to summarize: Currently the powerdown GPIO for tfp410 is handled in the board files (and called reset gpio), with gpio_set_value(). My cleanup series moves this to the tfp410 driver. BB-xM needs to use gpio_set_value_cansleep() in tfp410 to function properly, so the tfp410 driver needs to be changed, as this patch does. I will take this patch to the dss tree. So it's safe to pull my cleanup series, but if I understood correctly, applying Russ's [PATCH v4] ARM: OMAP: Cleanup Beagleboard DVI reset gpio will cause WARN_ONs on BB-xM until this patch to tfp410 is also applied. But it doesn't sound too serious, so I think it's safe to apply the cleanup beagleboard dvi patch also. The warning will go away when both l-o and dss trees are pulled in the merge window. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 5/6] ARM: OMAP4: CLKDM: Update supported transition modes
On Thursday 10 May 2012 03:06 AM, Jon Hunter wrote:
From: Jon Hunter jon-hun...@ti.com
For OMAP3+ devices, the clock domains (CLKDMs) support one or more of the
following transition modes ...
NO_SLEEP (0x0) - A clock domain sleep transition is never initiated,
irrespective of the hardware conditions.
SW_SLEEP (0x1) - A software-forced sleep transition. The transition is
initiated
when the associated hardware conditions are satisfied
SW_WKUP (0x2) - A software-forced clock domain wake-up transition is
initiated,
irrespective of the hardware conditions.
HW_AUTO (0x3) - Hardware-controlled automatic sleep and wake-up transition is
initiated by the PRCM module when the associated hardware
conditions are satisfied.
For OMAP4 devices, SW_SLEEP is equivalent to HW_AUTO and NO_SLEEP is
equivalent
to SW_WKUP. For OMAP4 devices, all CLKDMs support HW_AUTO and therefore we can
place the CLKDMs in the HW_AUTO state instead of the SW_SLEEP mode. Hence, we
do not need to use the SW_SLEEP mode. With regard to NO_SLEEP and SW_WKUP it
is
preferred to use SW_WKUP mode if the CLKDM supports it and so use this mode
instead of NO_SLEEP where possible.
For a software perspective the above 4 modes are represented by the following
flags to indicate what modes are supported by each of the CLKDMs.
CLKDM_CAN_DISABLE_AUTO-- NO_SLEEP
CLKDM_CAN_ENABLE_AUTO -- HW_AUTO
CLKDM_CAN_FORCE_SLEEP -- SW_SLEEP
CLKDM_CAN_FORCE_WAKEUP-- SW_WKUP
By eliminating the SW_SLEEP mode the the mapping of the flags for OMAP4
devices
can becomes ...
CLKDM_CAN_DISABLE_AUTO-- NO_SLEEP
CLKDM_CAN_ENABLE_AUTO -- HW_AUTO
CLKDM_CAN_FORCE_SLEEP -- HW_AUTO
Not sure if this can be entirely correct for OMAP4.
Because HW_AUTO = Sleep and wakeup transition are
based upon hardware conditions
Where as SW_SLEEP = Start a software forced sleep
transition on the domain.
I will reply on the the thread where this is being discussed.
CLKDM_CAN_FORCE_WAKEUP-- SW_WKUP
Cc: Ming Lei ming@canonical.com
Cc: Will Deacon will.dea...@arm.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/clockdomain44xx.c |7 +--
arch/arm/mach-omap2/cminst44xx.c | 14 --
2 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain44xx.c
b/arch/arm/mach-omap2/clockdomain44xx.c
index 4f04dd1..99ce556 100644
--- a/arch/arm/mach-omap2/clockdomain44xx.c
+++ b/arch/arm/mach-omap2/clockdomain44xx.c
@@ -70,7 +70,7 @@ static int omap4_clkdm_clear_all_wkup_sleep_deps(struct
clockdomain *clkdm)
static int omap4_clkdm_sleep(struct clockdomain *clkdm)
{
- omap4_cminst_clkdm_force_sleep(clkdm-prcm_partition,
+ omap4_cminst_clkdm_enable_hwsup(clkdm-prcm_partition,
clkdm-cm_inst, clkdm-clkdm_offs);
In case SW_SLEEP != HW_AUTO, something like below can be done
if (clkdm-flags CLKDM_CAN_FORCE_SLEEP )
omap4_cminst_clkdm_force_sleep(clkdm-prcm_partition,
clkdm-cm_inst, clkdm-clkdm_offs);
else
omap4_cminst_clkdm_enable_hwsup(clkdm-prcm_partition,
clkdm-cm_inst, clkdm-clkdm_offs);
return 0;
}
@@ -90,7 +90,10 @@ static void omap4_clkdm_allow_idle(struct clockdomain
*clkdm)
static void omap4_clkdm_deny_idle(struct clockdomain *clkdm)
{
- omap4_cminst_clkdm_disable_hwsup(clkdm-prcm_partition,
+ if (clkdm-flags CLKDM_CAN_FORCE_WAKEUP)
+ omap4_clkdm_wakeup(clkdm);
+ else
+ omap4_cminst_clkdm_disable_hwsup(clkdm-prcm_partition,
clkdm-cm_inst, clkdm-clkdm_offs);
}
diff --git a/arch/arm/mach-omap2/cminst44xx.c
b/arch/arm/mach-omap2/cminst44xx.c
index bd8810c..a44456c 100644
--- a/arch/arm/mach-omap2/cminst44xx.c
+++ b/arch/arm/mach-omap2/cminst44xx.c
@@ -227,20 +227,6 @@ void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst,
u16 cdoffs)
}
/**
- * omap4_cminst_clkdm_force_sleep - try to put a clockdomain into idle
- * @part: PRCM partition ID that the clockdomain registers exist in
- * @inst: CM instance register offset (*_INST macro)
- * @cdoffs: Clockdomain register offset (*_CDOFFS macro)
- *
- * Put a clockdomain referred to by (@part, @inst, @cdoffs) into idle
- * No return value.
- */
-void omap4_cminst_clkdm_force_sleep(u8 part, s16 inst, u16 cdoffs)
-{
- _clktrctrl_write(OMAP34XX_CLKSTCTRL_FORCE_SLEEP, part, inst, cdoffs);
-}
-
-/**
* omap4_cminst_clkdm_force_sleep - try to take a clockdomain out of idle
* @part: PRCM partition ID that the clockdomain registers exist in
* @inst: CM instance register offset (*_INST macro)
--
To unsubscribe from this list: send the line
Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep
On Wed, 2012-05-09 at 15:08 -0700, Russ Dill wrote: The Beagleboard xM gpio used for TFP410 powerdown is connected through an I2C attached chip which means setting the GPIO can sleep. Code that calls tfp410_power_on/off holds a mutex, so sleeping should be fine. Signed-off-by: Russ Dill russ.d...@ti.com --- drivers/video/omap2/displays/panel-tfp410.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) I'll apply this to dss tree, thanks. Tomi signature.asc Description: This is a digitally signed message part
Re: oprofile and ARM A9 hardware counter
Benoit,
On Wednesday 09 May 2012 04:28 PM, Cousson, Benoit wrote:
Hi Kevin and Jon,
On 5/8/2012 11:22 PM, Kevin Hilman wrote:
Jon Hunterjon-hun...@ti.com writes:
Hi Benoit,
On 05/08/2012 06:01 AM, Cousson, Benoit wrote:
[...]
P.S. Please note there is also already a different fix in mainline for
the EMU clkdm data from Paul which adds the force wakeup flag and
removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
because the hardware is capable.)
Hmmm ... yes saw this, and you will have to excuse me as I don't fully
follow the logic here. In fact, I am thinking we want the opposite ;-)
From looking, into this it seems to me that when PMU is running we want
the EMU clock domain in software-wakeup state and when PMU is not
running we want in the hardware auto state.
So far, I'm with you.
By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
domain it is put right back into the HW_AUTO state
This is only because it was in the HWSUP state when _enable was called.
If clkdm_deny_idle() is used, that behavior will change.
and hence PMU is
not working (see _enable() function in
arch/arm/mach-omap2/omap_hwmod.c)
So really what I think we want is to remove the ENABLE_AUTO flag to keep
the clock domain in software wake-up and use the DISABLE_AUTO flag to
put the clock domain back in HW_AUTO (note this requires a patch to
perform this 2nd part).
Well, Paul will have to comment here for the final word, but IIUC, the
hwmod flags are supposed to indicate only what the HW is capable of. If
we want to change the runtime behavior, we nee to use (or add) APIs to
change the beahvior. In this case, clkdm_allow_idle(),
clkdm_deny_idle() are probably what is needed here.
Yes, indeed, we should not hack the flags to fix that kind of issue. The
flags describe what the HW is capable of, and the EMU CD can support
HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the
only valid next power state is OFF, meaning that no retention mode is
supported. So any transition to idle will go to OFF and lead to a reset
upon wakeup.
No hacking intended here, just getting the flags correct ;-)
So let me start from the beginning ...
1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
SW_WKUP.
2. When the EMU CD is active (due to something like PMU), we want to
keep the CD in the SW_WKUP state, otherwise we can automatically
transition to idle and reset the IP (at least for omap4430).
3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
state because SW_SLEEP is NOT supported.
In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
set then the omap_pm_clkdms_setup() function will place the CD into
HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
hwmod _enable() is called it is in the HW_AUTO state and so it is
allowed to idle. This is not what we want. Do you agree?
If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
then I do not have the above problem.
To be honest, with you the more I look and test the code, the more
confused I am by the definition of the CLKDM_CAN_HWSUP ...
#define CLKDM_CAN_HWSUP (CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
When I look at where these flags are used, I see that
CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...
CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
Are the above the correct definitions?
Not quite.
These flags describe the capabilities as defined in CLKTRCTRL field of
the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)
CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)
Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
it's described as The automatic hardware-supervised mode is disabled
Yeah, in fact this is the source of the current confusion for my point of
view.
We chat about that with Paul some time back.
EMU CD does support HW_AUTO and SW_WKUP, so it means that if you want to
disable the AUTO mode you can use the SW_WKUP.
Assuming that CLKDM_CAN_DISABLE_AUTO is equivalent to NO_SLEEP is thus not
correct. In fact any state != HW_AUTO should be considered a non-automatic
mode.
So EMU does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and
CLKDM_CAN_FORCE_WAKEUP.
But the way it is implemented does not really allow that, because disable
hwsup imply setting state to OMAP34XX_CLKSTCTRL_DISABLE_AUTO.
void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs)
{
_clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, part, inst, cdoffs);
}
So if we want to
RE: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
Hi Ivan, On Wed, May 09, 2012 at 21:01:42, Tony Lindgren wrote: Note that I could prepare a new MTD patch with BCH ecc code included, allowing to drop the GPMC BCH ecc api. OK, let's do that then. I'll drop this patch and you can coordinate your patch with Afzal. Now that some review comments has been received on the series, let me try to come up with a suitable way forward and contact you within a day or two. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/25] OMAPDSS: DT preparation patches v2
On Wed, 2012-05-09 at 08:45 -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [120509 01:12]: Below is the pull request for board file related changes. Tested on panda 4430sdp. Thanks, I've merged that into clenaup-dss branch and will send it along with other still pending cleanup branches. How should I manage my tree related to this... Should I rebase my original DT preparation series on top of this new branch, or can I just ignore the new branch for now, as long as I merge it at some point before sending a pull request to mainline? Yes you need to rebase on this now. And not touch these commits. Otherwise we'll end up with duplicate commits in the mainline tree, which is a big no-no. If something shows up that needs fixing in this series, it must now be separate patches on top of this series. When doing pull requests we both just have to make note that there's a dependency to this branch, and it will find it's way to mainline via arm-soc pull request. Or if no conflicts need sorting out, then it will just get merged with your pull request. Hmm, I'm still not totally sure how to proceed. What do you mean with make a note? I understand that I can't change the commits, but is it ok for me to now merge the for-l-o-3.5 branch into my master branch (which is my stable branch, for which I'll send a pull request)? If the same commits are both in my tree and in l-o (or arm-soc), doesn't it mean that the commits seem to come into Linus's tree from whoever happens to send their pull request first? Then again, does it matter.. And if there are conflicts in the board files between for-l-o-3.5 and some other commits, and you or Arnd resolve those for l-o or arm-soc, what happens when the same, but unresolved, commits come from my pull request? Sorry if this should be obvious, but I haven't done such merging before and I'd rather not mess it up =). Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
On Wednesday 09 May 2012 09:18 PM, Russell King - ARM Linux wrote: On Wed, May 09, 2012 at 06:00:10PM +0530, Shilimkar, Santosh wrote: On Wed, May 9, 2012 at 5:53 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, May 09, 2012 at 02:20:28PM +0530, Shilimkar, Santosh wrote: The only change done common code is clearing 'XN' bit for DRAM region in page table entries. The other change of setting the DACR register is done in ARMv7 specific code. Yes, XN is an ARMv6+ thing. Before ARMv5, it was implementation defined. Some implementations used the bit to mean allow writes to update the cache. Other implementations labelled this bit as should be zero while others labelled it as should be one. Good to know. The upshot of this is, we know that having this bit as '1' means that all the CPUs we support today work. I would be _very_ concerned to change this bit to zero as we _really_ don't know how the pre-ARMv6 CPUs would react. I agree. The solution to this is pretty simple - if ARMv6+ needs a different base section mapping value, then we need to extract that from the code and pass in the base section mapping value. I'll sort out a patch later today for this. Great. This works for my 4430SDP board. I haven't booted it on anything else yet. Please can you check that this solves the issue for you? Thanks. Yes it does. Are you planning to merge below patch as is or split the patch like 1) Refactoring 2) ARMv7 fix Either is fine with me. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 14/14] OMAPDSS: HDMI: Implement DSS driver interface for audio
On Wed, 2012-05-09 at 23:12 -0500, Ricardo Neri wrote: Under the new strategy, in addition to not allowing the audio functions to be called from multiple threads, audio functions will fail if the sequence _CONFIGURED - _ENABLED - PLAYING - DISABLED is not followed. This is aligned with the behavior that ALSA follows for the audio codecs. Also, it checks the state of the panel to allow the audio transitions. But the video and audio paths are probably always separate, and for those we need protection. As you said, using the mutex for the may-sleep audio functions solves the issue for those, leaving start/stop as the only problem case. Audio only needs to know if the display is active. Under the improved Audio also needs to know if the video mode is suitable for audio, right? So not only disabling the video has to stop audio, but also if the video mode changes to a non-supported one. strategy, audio_start indirectly checks the state of the panel because the audio needs to be in AUDIO_ENABLED state to start and this state is reached only if the panel is active. The mutex is held to check the state of the panel and the audio lock is held to change the audio state. Also, the audio transitions to AUDIO_DISABLED if the panel is disabled. Hmm, I can't see the code that does that. As far as I see, no video enable/disable/reconfig affects audio in any way. Am I missing a patch? Could you setup a public git branch so it's easier for me to get the whole series, instead of sending individual patches. Tomi signature.asc Description: This is a digitally signed message part
Re: omapfb-main.c: check result of simple_strtoul
On Wed, 2012-05-09 at 22:47 +0800, Hein Tibosch wrote:
Tomi,
In drivers/video/omap2/omapfb/omapfb-main.c:
static int omapfb_parse_vram_param(const char *param, int max_entries,
unsigned long *sizes, unsigned long *paddrs)
{
int fbnum;
unsigned long size;
unsigned long paddr = 0;
char *p, *start;
start = (char *)param;
while (1) {
p = start;
fbnum = simple_strtoul(p, p, 10);
- if (p == param)
+ if (p == start)
correct?
Yes, looks like a correct fix. I'll cook up a patch.
How did you encounter the bug? What was the outcome?
Tomi
signature.asc
Description: This is a digitally signed message part
RE: [GIT PULL] ARM: OMAP2+: Misc cleanup
On Wed, May 09, 2012 at 00:04:14, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [120508 00:18]:
Tony,
Please pull the following preparatory cleanup series to add OMAP5 minimal
support. Boot tested on OMAP2430 SDP, OMAP3430 SDP and OMAP4430 SDP
platforms.
I have dropped {[PATCH 7/7] ARM: OMAP4+: Add prm and cm base init function}
from this set since Paul is taking that one in his queue.
OK thanks, pulling this into cleanup-soc and merging into cleanup branch
with what we have in devel-hwmod.
Tony,
Just observed that, while merging cleanup-soc into cleanup branch you have
missed couple of lines from Satosh's original patch. Which leads to build
break on OMAP2 alone build.
Can you please merge below change,
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 833f153..c82783a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -122,6 +122,8 @@ obj-$(CONFIG_SOC_AM33XX)+= $(powerdomain-common)
clockdomain-common += clockdomain.o
clockdomain-common += clockdomains_common_data.o
obj-$(CONFIG_ARCH_OMAP2) += $(clockdomain-common)
+obj-$(CONFIG_ARCH_OMAP2) += clockdomain2xxx_3xxx.o
+obj-$(CONFIG_ARCH_OMAP2) += clockdomains2xxx_3xxx_data.o
obj-$(CONFIG_SOC_OMAP2420) += clockdomains2420_data.o
obj-$(CONFIG_SOC_OMAP2430) += clockdomains2430_data.o
obj-$(CONFIG_ARCH_OMAP3) += $(clockdomain-common)
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Wed, May 09, 2012 at 10:45:08PM +0100, Jon Hunter wrote: Hi All, Hi Jon, I have posted my latest series here [1] based upon that from Will [2] which attempts to fix the EMU CD based upon the inputs from this thread. It is working on my omap4460 panda. Hopefully Ming and/or Will can also test. I know that Ming is out this week but said he can test next week. Many thanks to you (+Kevin, Benoit, Paul and co) for persevering with this. If I can get my hands on a Panda, I'll see if I can test something this week. Any particular tests you want me to run to exercise the interaction with PM? Cheers, Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESUBMIT PATCH] ARM: OMAP2+: am33xx: Add low level debugging support
From: Afzal Mohammed af...@ti.com
Add support for low level debugging on AM335X EVM (AM33XX family).
Currently only support for UART1 console, which is used on AM335X EVM
is added.
Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
---
This patch had been Reviewed and accepted earlier, but got
missed during last merge window. Resubmitting again, without
code-change.
arch/arm/mach-omap2/include/mach/debug-macro.S | 17 -
arch/arm/plat-omap/include/plat/serial.h |4
arch/arm/plat-omap/include/plat/uncompress.h |6 ++
3 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S
b/arch/arm/mach-omap2/include/mach/debug-macro.S
index cdfc2a1..d7f844a 100644
--- a/arch/arm/mach-omap2/include/mach/debug-macro.S
+++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
@@ -72,6 +72,8 @@ omap_uart_lsr:.word 0
beq 82f @ configure UART2
cmp \rp, #TI81XXUART3 @ ti81Xx UART offsets different
beq 83f @ configure UART3
+ cmp \rp, #AM33XXUART1 @ AM33XX UART offsets different
+ beq 84f @ configure UART1
cmp \rp, #ZOOM_UART @ only on zoom2/3
beq 95f @ configure ZOOM_UART
@@ -100,7 +102,9 @@ omap_uart_lsr: .word 0
b 98f
83:mov \rp, #UART_OFFSET(TI81XX_UART3_BASE)
b 98f
-
+84:ldr \rp, =AM33XX_UART1_BASE
+ and \rp, \rp, #0x00ff
+ b 97f
95:ldr \rp, =ZOOM_UART_BASE
str \rp, [\tmp, #0] @ omap_uart_phys
ldr \rp, =ZOOM_UART_VIRT
@@ -109,6 +113,17 @@ omap_uart_lsr: .word 0
str \rp, [\tmp, #8] @ omap_uart_lsr
b 10b
+ /* AM33XX: Store both phys and virt address for the uart */
+97:add \rp, \rp, #0x4400 @ phys base
+ str \rp, [\tmp, #0] @ omap_uart_phys
+ sub \rp, \rp, #0x4400 @ phys base
+ add \rp, \rp, #0xf900 @ virt base
+ str \rp, [\tmp, #4] @ omap_uart_virt
+ mov \rp, #(UART_LSR OMAP_PORT_SHIFT)
+ str \rp, [\tmp, #8] @ omap_uart_lsr
+
+ b 10b
+
/* Store both phys and virt address for the uart */
98:add \rp, \rp, #0x4800 @ phys base
str \rp, [\tmp, #0] @ omap_uart_phys
diff --git a/arch/arm/plat-omap/include/plat/serial.h
b/arch/arm/plat-omap/include/plat/serial.h
index b073e5f..28e2d25 100644
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -60,6 +60,9 @@
/* AM3505/3517 UART4 */
#define AM35XX_UART4_BASE 0x4809E000 /* Only on AM3505/3517 */
+/* AM33XX serial port */
+#define AM33XX_UART1_BASE 0x44E09000
+
/* External port on Zoom2/3 */
#define ZOOM_UART_BASE 0x1000
#define ZOOM_UART_VIRT 0xfa40
@@ -93,6 +96,7 @@
#define TI81XXUART181
#define TI81XXUART282
#define TI81XXUART383
+#define AM33XXUART184
#define ZOOM_UART 95 /* Only on zoom2/3 */
/* This is only used by 8250.c for omap1510 */
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h
b/arch/arm/plat-omap/include/plat/uncompress.h
index cc3f11b..ac43233 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -103,6 +103,10 @@ static inline void flush(void)
_DEBUG_LL_ENTRY(mach, TI81XX_UART##p##_BASE, OMAP_PORT_SHIFT, \
TI81XXUART##p)
+#define DEBUG_LL_AM33XX(p, mach) \
+ _DEBUG_LL_ENTRY(mach, AM33XX_UART##p##_BASE, OMAP_PORT_SHIFT, \
+ AM33XXUART##p)
+
static inline void __arch_decomp_setup(unsigned long arch_id)
{
int port = 0;
@@ -183,6 +187,8 @@ static inline void __arch_decomp_setup(unsigned long
arch_id)
/* TI8148 base boards using UART1 */
DEBUG_LL_TI81XX(1, ti8148evm);
+ /* AM33XX base boards using UART1 */
+ DEBUG_LL_AM33XX(1, am335xevm);
} while (0);
}
--
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] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
On Thu, May 10, 2012 at 12:41:35PM +0530, Santosh Shilimkar wrote: Are you planning to merge below patch as is or split the patch like 1) Refactoring 2) ARMv7 fix I don't see any point in splitting this up, especially as the ARMv7 fix would involve merely changing two lines (the domain register value and the value passed into __setup_mmu via r6.) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Thu, May 10, 2012 at 10:44 AM, Will Deacon will.dea...@arm.com wrote: On Wed, May 09, 2012 at 10:45:08PM +0100, Jon Hunter wrote: Hi All, Hi Jon, I have posted my latest series here [1] based upon that from Will [2] which attempts to fix the EMU CD based upon the inputs from this thread. It is working on my omap4460 panda. Hopefully Ming and/or Will can also test. I know that Ming is out this week but said he can test next week. Many thanks to you (+Kevin, Benoit, Paul and co) for persevering with this. If I can get my hands on a Panda, I'll see if I can test something this week. Any particular tests you want me to run to exercise the interaction with PM? Cheers, I would like to get the final patch (on top of Ming's) so I can test this on my Panda board too. Thanks. Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
On Thursday 10 May 2012 02:23 PM, Russell King - ARM Linux wrote: On Thu, May 10, 2012 at 12:41:35PM +0530, Santosh Shilimkar wrote: Are you planning to merge below patch as is or split the patch like 1) Refactoring 2) ARMv7 fix I don't see any point in splitting this up, especially as the ARMv7 fix would involve merely changing two lines (the domain register value and the value passed into __setup_mmu via r6.) Fine with me. Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
Tony, [snip] So after the cleanup patch introducing CONFIG_SOC_OMAP4PLUS it can be changed as #ifdef (CONFIG_SOC_OMAP4PLUS) !(defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)) So this will avoid patching this for the future socs. ? Well it seems that we've come to a conclusion that if we introduce new config options, they should be based on features instead. So CONFIG_SOC_HAS_OMAPXYZ_BLAH rather than CONFIG_SOC_OMAP4PLUS. Sure thanks for clarifying. Then i will introduce a relevant config in my cleanup patch first and then add OMAP5. Thanks, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] ARM: OMAP4 device off support
On Thu, 2012-05-10 at 00:14 +0100, Russell King - ARM Linux wrote: On Wed, May 09, 2012 at 03:46:02PM -0700, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: Hi, First version for this work. Applies on top of mainline + iochain set + OMAP4 core retention set. Working tree available here: tree: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.4-omap4-dev-off FYI... seems your get repo is corrupted. I tried fetching both with git and https protocols: $ git remote add tero git://gitorious.org/~kristo/omap-pm/omap-pm-work.git $ git fetch tero fatal: The remote end hung up unexpectedly fatal: protocol error: bad pack heade $ git remote rm tero $ git remote add tero https://git.gitorious.org/~kristo/omap-pm/omap-pm-work.git $ git fetch tero error: Unable to find 653621e4dd02d4a2117e1b813d9c5f1ccb11c9ed under https://git.gitorious.org/~kristo/omap-pm/omap-pm-work.git Cannot obtain needed object 653621e4dd02d4a2117e1b813d9c5f1ccb11c9ed error: Fetch failed. You will have a partially transferred pack file in your repository... Strange, well I pushed 1 new branch and it looks like it is cloning properly now. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] arm: omap4: create pmu device via hwmod
Hi Jon Ming,
On 5/9/2012 11:35 PM, Jon Hunter wrote:
From: Ming Leiming@canonical.com
The following modules is required to be enabled before configuring
cross trigger interface for enabling pmu irq:
l3_instr, l3_main_3, debugss
so build the arm-pmu device via the three hwmods.
Cc: Ming Leiming@canonical.com
Cc: Will Deaconwill.dea...@arm.com
Cc: Benoit Coussonb-cous...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
Cc: Kevin Hilmankhil...@ti.com
Signed-off-by: Ming Leiming@canonical.com
Signed-off-by: Will Deaconwill.dea...@arm.com
Signed-off-by: Jon Hunterjon-hun...@ti.com
---
arch/arm/mach-omap2/devices.c | 61 ++---
1 files changed, 57 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 58682d1..d75b7d3 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -423,14 +423,67 @@ static struct platform_device omap_pmu_device = {
.num_resources = 1,
};
-static void omap_init_pmu(void)
+static struct arm_pmu_platdata omap4_pmu_data;
+static struct omap_device_pm_latency omap_pmu_latency[] = {
+ [0] = {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
You can get rid of that, and use a NULL value during
omap_device_build_ss. It will use the default value automatically.
+static struct platform_device* __init omap4_init_pmu(void)
{
- if (cpu_is_omap24xx())
+ int id = -1;
+ const char *hw;
+ struct platform_device *pd;
+ struct omap_hwmod* oh[3];
+ char *dev_name = arm-pmu;
+
+ hw = l3_main_3;
+ oh[0] = omap_hwmod_lookup(hw);
+ if (!oh[0]) {
+ pr_err(Could not look up %s hwmod\n, hw);
+ return NULL;
+ }
+ hw = l3_instr;
+ oh[1] = omap_hwmod_lookup(hw);
+ if (!oh[1]) {
+ pr_err(Could not look up %s hwmod\n, hw);
+ return NULL;
+ }
+ hw = debugss;
+ oh[2] = omap_hwmod_lookup(hw);
+ if (!oh[2]) {
+ pr_err(Could not look up %s hwmod\n, hw);
+ return NULL;
+ }
+
+ pd = omap_device_build_ss(dev_name, id, oh, 3,omap4_pmu_data,
+ sizeof(omap4_pmu_data),
+ omap_pmu_latency,
+ ARRAY_SIZE(omap_pmu_latency), 0);
+ WARN(IS_ERR(pd), Can't build omap_device for %s.\n,
+ dev_name);
+ return pd;
+}
+static void __init omap_init_pmu(void)
+{
+ if (cpu_is_omap24xx()) {
omap_pmu_device.resource =omap2_pmu_resource;
Ideally, OMAP2 and 3 should use the hwmod device creation as well.
Regards,
Benoit
- else if (cpu_is_omap34xx())
+ } else if (cpu_is_omap34xx()) {
omap_pmu_device.resource =omap3_pmu_resource;
- else
+ } else if (cpu_is_omap44xx()) {
+ struct platform_device *pd;
+
+ pd = omap4_init_pmu();
+ if (!pd)
+ return;
+ omap_device_enable(pd);
+ return;
+ } else {
return;
+ }
platform_device_register(omap_pmu_device);
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP3/4: consolidate cpuidle Makefile
The current Makefile compiles the cpuidle34xx.c and cpuidle44xx.c files
even if the cpuidle option is not set in the kernel.
This patch fixes this by creating a section in the Makefile where these
files are compiled only if the CONFIG_CPU_IDLE option is set.
This modification breaks an implicit dependency between CPU_IDLE and PM as
they belong to the same block in the Makefile. This is fixed in the Kconfig
by selecting explicitely PM is CPU_IDLE is set.
The linux coding style recommend to use no-op functions in the headers
when the subsystem is disabled instead of adding big section in C files.
This patch fix this also.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
Reviewed-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/Kconfig |2 ++
arch/arm/mach-omap2/Makefile | 11 +++
arch/arm/mach-omap2/cpuidle34xx.c |8
arch/arm/mach-omap2/cpuidle44xx.c |8
arch/arm/mach-omap2/pm.h | 17 +++--
5 files changed, 24 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 8141b76..42f6b89 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -34,6 +34,7 @@ config ARCH_OMAP3
select CPU_V7
select USB_ARCH_HAS_EHCI if USB_SUPPORT
select ARCH_HAS_OPP
+ select PM if CPU_IDLE
select PM_OPP if PM
select ARM_CPU_SUSPEND if PM
select MULTI_IRQ_HANDLER
@@ -51,6 +52,7 @@ config ARCH_OMAP4
select PL310_ERRATA_727915
select ARM_ERRATA_720789
select ARCH_HAS_OPP
+ select PM if CPU_IDLE
select PM_OPP if PM
select USB_ARCH_HAS_EHCI if USB_SUPPORT
select ARM_CPU_SUSPEND if PM
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 49f92bc..f46c735 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -64,10 +64,8 @@ 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 \
- cpuidle34xx.o
-obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o \
- cpuidle44xx.o
+obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
+obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o
obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3) += smartreflex-class3.o
@@ -81,6 +79,11 @@ endif
endif
+ifeq ($(CONFIG_CPU_IDLE),y)
+obj-$(CONFIG_ARCH_OMAP3)+= cpuidle34xx.o
+obj-$(CONFIG_ARCH_OMAP4)+= cpuidle44xx.o
+endif
+
# PRCM
obj-y += prm_common.o
obj-$(CONFIG_ARCH_OMAP2) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 207bc1c..3134452 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -36,8 +36,6 @@
#include control.h
#include common.h
-#ifdef CONFIG_CPU_IDLE
-
/* Mach specific information to be recorded in the C-state driver_data */
struct omap3_idle_statedata {
u32 mpu_state;
@@ -379,9 +377,3 @@ int __init omap3_idle_init(void)
return 0;
}
-#else
-int __init omap3_idle_init(void)
-{
- return 0;
-}
-#endif /* CONFIG_CPU_IDLE */
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index be1617c..02d15bb 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -22,8 +22,6 @@
#include pm.h
#include prm.h
-#ifdef CONFIG_CPU_IDLE
-
/* Machine specific information */
struct omap4_idle_statedata {
u32 cpu_state;
@@ -199,9 +197,3 @@ int __init omap4_idle_init(void)
return 0;
}
-#else
-int __init omap4_idle_init(void)
-{
- return 0;
-}
-#endif /* CONFIG_CPU_IDLE */
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 7856489..ab04d3b 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -15,12 +15,25 @@
#include powerdomain.h
+#ifdef CONFIG_CPU_IDLE
+extern int __init omap3_idle_init(void);
+extern int __init omap4_idle_init(void);
+#else
+static inline int omap3_idle_init(void)
+{
+ return 0;
+}
+
+static inline int omap4_idle_init(void)
+{
+ return 0;
+}
+#endif
+
extern void *omap3_secure_ram_storage;
extern void omap3_pm_off_mode_enable(int);
extern void omap_sram_idle(void);
extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
-extern int omap3_idle_init(void);
-extern int omap4_idle_init(void);
extern int omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused);
extern int (*omap_pm_suspend)(void);
--
1.7.5.4
--
To unsubscribe from this list: send
[PATCH 0/3] ARM: OMAP2/3: DSS HWMOD fixes
Hi, These patches fix DSS hwmod data related to sysc flags. I haven't seen any problem produced by these missing bits, but by looking at the TRM it's clear that they should be defined. However, applying these will cause additional warnings to show during boot: omap_hwmod: dss_dispc: softreset failed (waited 1 usec) omap_hwmod: dss_rfbi: softreset failed (waited 1 usec) Most likely the softreset fails even now, but as there's no check to verify it, no warnings are visible. I think the reason for the failing softreset is the same problem as we have on OMAP4: dss_core hwmod should be enabled before other dss hwmods can be enabled (and reset). Tomi Tomi Valkeinen (3): ARM: OMAP2/3: HWMOD: Add missing flags for dispc class ARM: OMAP2/3: HWMOD: Add missing flag for rfbi class ARM: OMAP3: HWMOD: Add omap_hwmod_class_sysconfig for dsi .../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |3 ++- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 15 ++- 3 files changed, 17 insertions(+), 3 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: OMAP2/3: HWMOD: Add missing flag for rfbi class
hwmod class for rfbi is missing SYSS_HAS_RESET_STATUS, which this patch
adds.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
.../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c
index f08e442..bae4afd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c
@@ -65,7 +65,7 @@ static struct omap_hwmod_class_sysconfig omap2_rfbi_sysc = {
.sysc_offs = 0x0010,
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
- SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: OMAP2/3: HWMOD: Add missing flags for dispc class
hwmod class for dispc is missing sysc flags, which this patch adds.
OMAP2 is missing SYSS_HAS_RESET_STATUS
OMAP3 is missing SYSS_HAS_RESET_STATUS and SYSC_HAS_CLOCKACTIVITY
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |3 ++-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index 2a67297..7d1f71a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -39,7 +39,8 @@ static struct omap_hwmod_class_sysconfig omap2_dispc_sysc = {
.sysc_offs = 0x0010,
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
- SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE |
+ SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index db86ce9..489c374 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1502,7 +1502,8 @@ static struct omap_hwmod_class_sysconfig omap3_dispc_sysc
= {
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE |
- SYSC_HAS_ENAWAKEUP),
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_CLOCKACTIVITY |
+ SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: OMAP3: HWMOD: Add omap_hwmod_class_sysconfig for dsi
hwmod data for OMAP3 does not define sysconfig for DSI. This patch adds
it.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 489c374..1c55295 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1558,8 +1558,20 @@ static struct omap_hwmod omap3xxx_dss_dispc_hwmod = {
* display serial interface controller
*/
+static struct omap_hwmod_class_sysconfig omap3xxx_dsi_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
static struct omap_hwmod_class omap3xxx_dsi_hwmod_class = {
.name = dsi,
+ .sysc = omap3xxx_dsi_sysc,
};
static struct omap_hwmod_irq_info omap3xxx_dsi1_irqs[] = {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omapfb-main.c: check result of simple_strtoul
On Thu, 2012-05-10 at 18:51 +0800, Hein Tibosch wrote:
On 5/10/2012 4:23 PM, Tomi Valkeinen wrote:
On Wed, 2012-05-09 at 22:47 +0800, Hein Tibosch wrote:
fbnum = simple_strtoul(p, p, 10);
- if (p == param)
+ if (p == start)
correct?
Yes, looks like a correct fix. I'll cook up a patch.
How did you encounter the bug? What was the outcome?
I was reading the source, adding some printk's to get more debugging.
It would fail to detect a syntax error like:
omapfb.vram=0:2M,:5M
Ok, thanks.
If I may ask: why aren't mode and modes filled in:
/sys/devices/platform/omapfb/graphics/fb0 ?
Only modes will get an entry when a new mode becomes active.
No particular reason, nobody just has implemented it.
I thought of adding something like this in hdmi.c:
+static void omap_to_fbmode (struct fb_videomode *fb_mode, const struct
hdmi_config *cfg)
+{
You can't add framebuffer code to omapdss. omapdss is the lowlevel
driver that cannot depend on the fb driver. omapdss is also used by
other display drivers like omapdrm.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 01/13] ARM: OMAP5: id: Add cpu id for ES versions
Hi,
\
On 05/03/2012 10:26 AM, R Sricharan wrote:
Adding the OMAP5 ES1.0, 2.0 and OMAP5432 cpu revision
detection support.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/control.h |4 +++
arch/arm/mach-omap2/id.c | 47
+
arch/arm/plat-omap/include/plat/cpu.h | 23 ++-
3 files changed, 72 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index a406fd0..9daac6f 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -246,6 +246,10 @@
/* TI81XX CONTROL_DEVCONF register offsets */
#define TI81XX_CONTROL_DEVICE_ID (TI81XX_CONTROL_DEVCONF + 0x000)
+/* OMAP54XX CONTROL STATUS register */
+#define OMAP5XXX_CONTROL_STATUS0x134
+#define OMAP5_DEVICETYPE_MASK (0x7 6)
+
/*
* REVISIT: This list of registers is not comprehensive - there are more
* that should be added.
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 0e79b7b..d2ec323 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -50,6 +50,11 @@ int omap_type(void)
val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
} else if (cpu_is_omap44xx()) {
val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
+ } else if (cpu_is_omap54xx()) {
+ val = omap_ctrl_readl(OMAP5XXX_CONTROL_STATUS);
+ val = OMAP5_DEVICETYPE_MASK;
+ val = 6;
+ goto out;
} else {
pr_err(Cannot detect omap type!\n);
goto out;
@@ -500,6 +505,48 @@ void __init omap4xxx_check_revision(void)
((omap_rev() 12) 0xf), ((omap_rev() 8) 0xf));
}
+void __init omap5xxx_check_revision(void)
+{
+ u32 idcode;
+ u16 hawkeye;
+ u8 rev;
+
+ idcode = read_tap_reg(OMAP_TAP_IDCODE);
+ hawkeye = (idcode 12) 0x;
+ rev = (idcode 28) 0xff;
+ switch (hawkeye) {
+ case 0xb942:
+ switch (rev) {
+ case 0:
+ omap_revision = OMAP5430_REV_ES1_0;
+ break;
+ case 1:
+ omap_revision = OMAP5430_REV_ES2_0;
+ break;
+ default:
+ omap_revision = OMAP5430_REV_ES1_0;
Default should always be the latest version supported. i.e. in this case
it should be OMAP5430_REV_ES2_0
+ }
+ break;
+
+ case 0xb998:
+ switch (rev) {
+ case 0:
+ omap_revision = OMAP5432_REV_ES1_0;
+ break;
+ default:
+ omap_revision = OMAP5432_REV_ES1_0;
+ }
+ break;
+
+ default:
+ /* Unknown default to latest silicon rev as default*/
+ omap_revision = OMAP5430_REV_ES2_0;
+ }
+
+ pr_info(OMAP%04x ES%d.0\n,
+ omap_rev() 16, ((omap_rev() 12) 0xf));
+}
+
regards,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] OMAPDSS: OMAPFB: always allow to configure overlay
Currently when multiple overlays are active, OMAPFB_SETUP_PLANE fails.
Instead of failing, allow it to configure the first overlay as if there
was only one overlay, the remaining ones will have to be configured in
other ways (sysfs).
This allows overlay-controlling programs (like video players) to function
properly when framebuffer is cloned to another display (like TV).
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
drivers/video/omap2/omapfb/omapfb-ioctl.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c
b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 6a09ef8..8af7e17 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -70,7 +70,7 @@ static int omapfb_setup_plane(struct fb_info *fbi, struct
omapfb_plane_info *pi)
DBG(omapfb_setup_plane\n);
- if (ofbi-num_overlays != 1) {
+ if (ofbi-num_overlays == 0) {
r = -EINVAL;
goto out;
}
@@ -185,7 +185,7 @@ static int omapfb_query_plane(struct fb_info *fbi, struct
omapfb_plane_info *pi)
{
struct omapfb_info *ofbi = FB2OFB(fbi);
- if (ofbi-num_overlays != 1) {
+ if (ofbi-num_overlays == 0) {
memset(pi, 0, sizeof(*pi));
} else {
struct omap_overlay *ovl;
--
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 01/13] ARM: OMAP5: id: Add cpu id for ES versions
Hi Roger,
+void __init omap5xxx_check_revision(void)
+{
+ u32 idcode;
+ u16 hawkeye;
+ u8 rev;
+
+ idcode = read_tap_reg(OMAP_TAP_IDCODE);
+ hawkeye = (idcode 12) 0x;
+ rev = (idcode 28) 0xff;
+ switch (hawkeye) {
+ case 0xb942:
+ switch (rev) {
+ case 0:
+ omap_revision = OMAP5430_REV_ES1_0;
+ break;
+ case 1:
+ omap_revision = OMAP5430_REV_ES2_0;
+ break;
+ default:
+ omap_revision = OMAP5430_REV_ES1_0;
Default should always be the latest version supported. i.e. in this case
it should be OMAP5430_REV_ES2_0
ok thanks, will correct it.
Thanks,
Sricharan
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omapfb-main.c: check result of simple_strtoul
On 5/10/2012 4:23 PM, Tomi Valkeinen wrote:
On Wed, 2012-05-09 at 22:47 +0800, Hein Tibosch wrote:
fbnum = simple_strtoul(p, p, 10);
-if (p == param)
+if (p == start)
correct?
Yes, looks like a correct fix. I'll cook up a patch.
How did you encounter the bug? What was the outcome?
I was reading the source, adding some printk's to get more debugging.
It would fail to detect a syntax error like:
omapfb.vram=0:2M,:5M
If I may ask: why aren't mode and modes filled in:
/sys/devices/platform/omapfb/graphics/fb0 ?
Only modes will get an entry when a new mode becomes active.
I thought of adding something like this in hdmi.c:
+static void omap_to_fbmode (struct fb_videomode *fb_mode, const struct
hdmi_config *cfg)
+{
+ char name[64];
+ unsigned hsync;
+ unsigned vsync;
+ unsigned refresh;
+ snprintf (name, sizeof name, %d_%s_%d.%d,
+ cfg-cm.code,
+ cfg-cm.mode == HDMI_HDMI ? hdmi : dvi,
+ cfg-timings.x_res,
+ cfg-timings.y_res);
+
+ hsync = cfg-timings.hfp + cfg-timings.hsw + cfg-timings.hbp +
cfg-timings.x_res;
+ vsync = cfg-timings.vfp + cfg-timings.vsw + cfg-timings.vbp +
cfg-timings.y_res;
+ refresh = (unsigned) ((1000U * cfg-timings.pixel_clock + (hsync *
vsync-1) ) / (hsync * vsync));
+
+ fb_mode-name = kstrdup(name, GFP_KERNEL); /* optional */
+ fb_mode-refresh = refresh; /* optional */
+ fb_mode-xres = cfg-timings.x_res;
+ fb_mode-yres = cfg-timings.y_res;
+ fb_mode-pixclock = DIV_ROUND_UP (10UL,
cfg-timings.pixel_clock);
+ fb_mode-left_margin = cfg-timings.hfp;
+ fb_mode-right_margin = cfg-timings.hbp;
+ fb_mode-upper_margin = cfg-timings.vfp;
+ fb_mode-lower_margin = cfg-timings.vbp;
+ fb_mode-hsync_len = cfg-timings.hsw;
+ fb_mode-vsync_len = cfg-timings.vsw;
+ fb_mode-sync =
+ (cfg-timings.vsync_pol ? FB_SYNC_VERT_HIGH_ACT : 0) |
+ (cfg-timings.hsync_pol ? FB_SYNC_HOR_HIGH_ACT : 0);
+ fb_mode-vmode = 0;
+ fb_mode-flag = 0;
+}
+
+int omap2_add_video_modes (struct fb_info *fbi)
+{
+ struct fb_videomode fb_mode;
+ int i;
+ int count = 0;
+
+ INIT_LIST_HEAD(fbi-modelist);
+
+ for (i = 0; i ARRAY_SIZE(cea_timings); i++) {
+ omap_to_fbmode (fb_mode, cea_timings[i]);
+ fb_add_videomode(fb_mode, fbi-modelist);
+ count++;
+ }
+ for (i = 0; i ARRAY_SIZE(vesa_timings); i++) {
+ omap_to_fbmode (fb_mode, vesa_timings[i]);
+ fb_add_videomode(fb_mode, fbi-modelist);
+ count++;
+ }
+ return count;
+}
and call it from omapfb-main.c:
static int omapfb_create_framebuffers(struct omapfb2_device *fbdev)
{
...
clear_fb_info(fbi);
fbdev-fbs[i] = fbi;
+ omap2_add_video_modes (fbi);
With this patch I get 34 working entries from cat modes:
U:1024x768p-59
U:1280x800p-67
U:1680x1050p-59
U:1400x1050p-59
U:1280x768p-59
U:1920x1080p-60
U:1366x768p-59
...
which makes testing a bit easier.
But maybe I'm reinventing some wheel?
Hein
--
To unsubscribe from this list: send the line unsubscribe 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/13] ARM: OMAP5: Add the WakeupGen IP updates.
Hi,
On 05/03/2012 10:26 AM, R Sricharan wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
OMAP4 and OMAP5 share same WakeupGen IP with below few udpates on OMAP5.
- Additional 32 interrupt support is added w.r.t OMAP4 design.
- The AUX CORE boot registers are now made accessible from non-secure SW.
- SAR offset are changed and PTMSYNC* registers are removed from SAR.
Patch updates the WakeupGen code accordingly.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/include/mach/omap-wakeupgen.h |6 +
arch/arm/mach-omap2/omap-hotplug.c| 24 -
arch/arm/mach-omap2/omap-smp.c| 19 +++-
arch/arm/mach-omap2/omap-wakeupgen.c | 110 +++-
arch/arm/mach-omap2/omap4-sar-layout.h| 12 ++-
5 files changed, 135 insertions(+), 36 deletions(-)
diff --git a/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h
b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h
index 548de90..4d700bc 100644
--- a/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h
+++ b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h
@@ -11,15 +11,20 @@
#ifndef OMAP_ARCH_WAKEUPGEN_H
#define OMAP_ARCH_WAKEUPGEN_H
+/* OMAP4 and OMAP5 has same base address */
+#define OMAP_WKUPGEN_BASE0x48281000
unnecessary change, why don't you just use OMAP44XX_WKUPGEN_BASE or
define this in the same header as OMAP44XX_WKUPGEN_BASE?
+
#define OMAP_WKG_CONTROL_0 0x00
#define OMAP_WKG_ENB_A_0 0x10
#define OMAP_WKG_ENB_B_0 0x14
#define OMAP_WKG_ENB_C_0 0x18
#define OMAP_WKG_ENB_D_0 0x1c
+#define OMAP_WKG_ENB_E_0 0x20
#define OMAP_WKG_ENB_A_1 0x410
#define OMAP_WKG_ENB_B_1 0x414
#define OMAP_WKG_ENB_C_1 0x418
#define OMAP_WKG_ENB_D_1 0x41c
+#define OMAP_WKG_ENB_E_1 0x420
#define OMAP_AUX_CORE_BOOT_0 0x800
#define OMAP_AUX_CORE_BOOT_1 0x804
#define OMAP_PTMSYNCREQ_MASK 0xc00
@@ -28,4 +33,5 @@
#define OMAP_TIMESTAMPCYCLEHI0xc0c
extern int __init omap_wakeupgen_init(void);
+extern void __iomem *omap_get_wakeupgen_base(void);
#endif
diff --git a/arch/arm/mach-omap2/omap-hotplug.c
b/arch/arm/mach-omap2/omap-hotplug.c
index 56c345b..052303c 100644
--- a/arch/arm/mach-omap2/omap-hotplug.c
+++ b/arch/arm/mach-omap2/omap-hotplug.c
@@ -17,8 +17,10 @@
#include linux/kernel.h
#include linux/errno.h
#include linux/smp.h
+#include linux/io.h
#include asm/cacheflush.h
+#include mach/omap-wakeupgen.h
#include common.h
@@ -35,7 +37,8 @@ int platform_cpu_kill(unsigned int cpu)
*/
void __ref platform_cpu_die(unsigned int cpu)
{
- unsigned int this_cpu;
+ unsigned int boot_cpu = 0;
+ void __iomem *base = omap_get_wakeupgen_base();
this is unnecessary copy for omap4, move it to the place where you want
it below.
+ void __iomem *base;
flush_cache_all();
dsb();
@@ -43,16 +46,27 @@ void __ref platform_cpu_die(unsigned int cpu)
/*
* we're ready for shutdown now, so do it
*/
- if (omap_modify_auxcoreboot0(0x0, 0x200) != 0x0)
- pr_err(Secure clear status failed\n);
+ if (cpu_is_omap44xx()) {
+ if (omap_modify_auxcoreboot0(0x0, 0x200) != 0x0)
+ pr_err(Secure clear status failed\n);
+ } else {
i.e. here
+ *base = omap_get_wakeupgen_base();
+ __raw_writel(0, base + OMAP_AUX_CORE_BOOT_0);
+ }
+
for (;;) {
/*
* Enter into low power state
*/
omap4_hotplug_cpu(cpu, PWRDM_POWER_OFF);
- this_cpu = smp_processor_id();
- if (omap_read_auxcoreboot0() == this_cpu) {
+
+ if (cpu_is_omap44xx())
+ boot_cpu = omap_read_auxcoreboot0();
+ else
+ boot_cpu =
+ __raw_readl(base + OMAP_AUX_CORE_BOOT_0) 5;
+
+ if (boot_cpu == smp_processor_id()) {
/*
* OK, proper wakeup, we're done
*/
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index deffbf1..151fd5b 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -26,6 +26,8 @@
#include mach/hardware.h
#include mach/omap-secure.h
+#include mach/omap-wakeupgen.h
+#include asm/cputype.h
#include iomap.h
#include common.h
@@ -73,6 +75,8 @@ int __cpuinit boot_secondary(unsigned int cpu, struct
task_struct *idle)
{
static struct clockdomain *cpu1_clkdm;
static bool
Re: [PATCH 08/13] ARM: OMAP5: Add the WakeupGen IP updates.
On Thu, May 10, 2012 at 5:06 PM, Roger Quadros rog...@ti.com wrote: Hi, On 05/03/2012 10:26 AM, R Sricharan wrote: From: Santosh Shilimkar santosh.shilim...@ti.com OMAP4 and OMAP5 share same WakeupGen IP with below few udpates on OMAP5. - Additional 32 interrupt support is added w.r.t OMAP4 design. - The AUX CORE boot registers are now made accessible from non-secure SW. - SAR offset are changed and PTMSYNC* registers are removed from SAR. Patch updates the WakeupGen code accordingly. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: R Sricharan r.sricha...@ti.com --- arch/arm/mach-omap2/include/mach/omap-wakeupgen.h | 6 + arch/arm/mach-omap2/omap-hotplug.c | 24 - arch/arm/mach-omap2/omap-smp.c | 19 +++- arch/arm/mach-omap2/omap-wakeupgen.c | 110 +++- arch/arm/mach-omap2/omap4-sar-layout.h | 12 ++- 5 files changed, 135 insertions(+), 36 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h index 548de90..4d700bc 100644 --- a/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h +++ b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h @@ -11,15 +11,20 @@ #ifndef OMAP_ARCH_WAKEUPGEN_H #define OMAP_ARCH_WAKEUPGEN_H +/* OMAP4 and OMAP5 has same base address */ +#define OMAP_WKUPGEN_BASE 0x48281000 unnecessary change, why don't you just use OMAP44XX_WKUPGEN_BASE or define this in the same header as OMAP44XX_WKUPGEN_BASE? Just to avoid confusion about OMAP44XX and OMAP54XX. It's cleaner to remove the OMAP44XX reference if the base is generic and not depend on OMAP4/5. It's not un-necessary change as such. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/13] ARM: OMAP5: Add the WakeupGen IP updates.
On 05/10/2012 02:42 PM, Shilimkar, Santosh wrote: On Thu, May 10, 2012 at 5:06 PM, Roger Quadros rog...@ti.com wrote: Hi, On 05/03/2012 10:26 AM, R Sricharan wrote: From: Santosh Shilimkar santosh.shilim...@ti.com OMAP4 and OMAP5 share same WakeupGen IP with below few udpates on OMAP5. - Additional 32 interrupt support is added w.r.t OMAP4 design. - The AUX CORE boot registers are now made accessible from non-secure SW. - SAR offset are changed and PTMSYNC* registers are removed from SAR. Patch updates the WakeupGen code accordingly. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: R Sricharan r.sricha...@ti.com --- arch/arm/mach-omap2/include/mach/omap-wakeupgen.h |6 + arch/arm/mach-omap2/omap-hotplug.c| 24 - arch/arm/mach-omap2/omap-smp.c| 19 +++- arch/arm/mach-omap2/omap-wakeupgen.c | 110 +++- arch/arm/mach-omap2/omap4-sar-layout.h| 12 ++- 5 files changed, 135 insertions(+), 36 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h index 548de90..4d700bc 100644 --- a/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h +++ b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h @@ -11,15 +11,20 @@ #ifndef OMAP_ARCH_WAKEUPGEN_H #define OMAP_ARCH_WAKEUPGEN_H +/* OMAP4 and OMAP5 has same base address */ +#define OMAP_WKUPGEN_BASE0x48281000 unnecessary change, why don't you just use OMAP44XX_WKUPGEN_BASE or define this in the same header as OMAP44XX_WKUPGEN_BASE? Just to avoid confusion about OMAP44XX and OMAP54XX. It's cleaner to remove the OMAP44XX reference if the base is generic and not depend on OMAP4/5. It's not un-necessary change as such. OK, is OMAP_WKUPGEN_BASE applicable for OMAPs prior to OMAP4? If not the naming scheme does not look appropriate. regards, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/13] ARM: OMAP5: Add the WakeupGen IP updates.
On Thursday 10 May 2012 05:18 PM, Roger Quadros wrote: On 05/10/2012 02:42 PM, Shilimkar, Santosh wrote: On Thu, May 10, 2012 at 5:06 PM, Roger Quadros rog...@ti.com wrote: Hi, On 05/03/2012 10:26 AM, R Sricharan wrote: From: Santosh Shilimkar santosh.shilim...@ti.com OMAP4 and OMAP5 share same WakeupGen IP with below few udpates on OMAP5. - Additional 32 interrupt support is added w.r.t OMAP4 design. - The AUX CORE boot registers are now made accessible from non-secure SW. - SAR offset are changed and PTMSYNC* registers are removed from SAR. Patch updates the WakeupGen code accordingly. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: R Sricharan r.sricha...@ti.com --- arch/arm/mach-omap2/include/mach/omap-wakeupgen.h |6 + arch/arm/mach-omap2/omap-hotplug.c| 24 - arch/arm/mach-omap2/omap-smp.c| 19 +++- arch/arm/mach-omap2/omap-wakeupgen.c | 110 +++- arch/arm/mach-omap2/omap4-sar-layout.h| 12 ++- 5 files changed, 135 insertions(+), 36 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h index 548de90..4d700bc 100644 --- a/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h +++ b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h @@ -11,15 +11,20 @@ #ifndef OMAP_ARCH_WAKEUPGEN_H #define OMAP_ARCH_WAKEUPGEN_H +/* OMAP4 and OMAP5 has same base address */ +#define OMAP_WKUPGEN_BASE0x48281000 unnecessary change, why don't you just use OMAP44XX_WKUPGEN_BASE or define this in the same header as OMAP44XX_WKUPGEN_BASE? Just to avoid confusion about OMAP44XX and OMAP54XX. It's cleaner to remove the OMAP44XX reference if the base is generic and not depend on OMAP4/5. It's not un-necessary change as such. OK, is OMAP_WKUPGEN_BASE applicable for OMAPs prior to OMAP4? If not the naming scheme does not look appropriate. It's IP exist on OMAP4/5 and future OMAPs, no name is fine. Btw, if you go on that route you will too many examples of non appropriate names. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
Hi, On 05/03/2012 10:26 AM, R Sricharan wrote: OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP architecture. It's a dual core SOC with GIC used for interrupt handling and with an integrated L2 cache controller. OMAP5432 is another variant of OMAP5430, with a memory controller supporting DDR3 and SATA. Patch includes: - The machine specific headers and sources updates. - Platform header updates. - Minimum initialisation support for serial. - IO table init Signed-off-by: R Sricharan r.sricha...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/Makefile | 26 ++ arch/arm/mach-omap2/clock.c|3 +- arch/arm/mach-omap2/cminst44xx.h |2 +- arch/arm/mach-omap2/common.c | 24 + arch/arm/mach-omap2/common.h | 11 ++ arch/arm/mach-omap2/include/mach/debug-macro.S |8 ++-- arch/arm/mach-omap2/io.c | 44 arch/arm/mach-omap2/iomap.h| 27 ++ arch/arm/mach-omap2/prcm.c |2 +- arch/arm/mach-omap2/prm2xxx_3xxx.h |5 ++- arch/arm/plat-omap/Makefile|4 +-- arch/arm/plat-omap/include/plat/clkdev_omap.h |1 + arch/arm/plat-omap/include/plat/clock.h|4 ++- arch/arm/plat-omap/include/plat/hardware.h |1 + arch/arm/plat-omap/include/plat/multi.h|9 + arch/arm/plat-omap/include/plat/omap54xx.h | 32 + arch/arm/plat-omap/include/plat/serial.h | 10 + arch/arm/plat-omap/include/plat/uncompress.h |6 +++ arch/arm/plat-omap/sram.c | 11 +- 19 files changed, 208 insertions(+), 22 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/omap54xx.h diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 669e2b1..fbb6b3d 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -16,6 +16,7 @@ secure-common = omap-smc.o omap-secure.o obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(hwmod-common) obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(hwmod-common) $(secure-common) obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common) $(secure-common) +obj-$(CONFIG_ARCH_OMAP5) += prm44xx.o $(hwmod-common) $(secure-common) ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),) obj-y += mcbsp.o @@ -27,8 +28,10 @@ obj-$(CONFIG_TWL4030_CORE) += omap_twl.o obj-$(CONFIG_SMP)+= omap-smp.o omap-headsmp.o obj-$(CONFIG_HOTPLUG_CPU)+= omap-hotplug.o -obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o -obj-$(CONFIG_ARCH_OMAP4) += sleep44xx.o +omap-4-5-common = omap4-common.o omap-wakeupgen.o \ +sleep44xx.o +obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-common) +obj-$(CONFIG_ARCH_OMAP5)+= $(omap-4-5-common) plus_sec := $(call as-instr,.arch_extension sec,+sec) AFLAGS_omap-headsmp.o:=-Wa,-march=armv7-a$(plus_sec) @@ -68,6 +71,7 @@ obj-$(CONFIG_ARCH_OMAP2)+= sleep24xx.o obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o obj-$(CONFIG_ARCH_OMAP3) += cpuidle34xx.o obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o +obj-$(CONFIG_ARCH_OMAP5) += omap-mpuss-lowpower.o obj-$(CONFIG_ARCH_OMAP4) += cpuidle44xx.o obj-$(CONFIG_PM_DEBUG) += pm-debug.o obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o @@ -87,9 +91,11 @@ obj-y += prm_common.o obj-$(CONFIG_ARCH_OMAP2) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o obj-$(CONFIG_ARCH_OMAP3) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o obj-$(CONFIG_ARCH_OMAP3) += vc3xxx_data.o vp3xxx_data.o -obj-$(CONFIG_ARCH_OMAP4) += prcm.o cminst44xx.o cm44xx.o -obj-$(CONFIG_ARCH_OMAP4) += prcm_mpu44xx.o prminst44xx.o -obj-$(CONFIG_ARCH_OMAP4) += vc44xx_data.o vp44xx_data.o prm44xx.o +omap-prcm-4-5-common = prcm.o cminst44xx.o cm44xx.o \ +prcm_mpu44xx.o prminst44xx.o \ +vc44xx_data.o vp44xx_data.o +obj-$(CONFIG_ARCH_OMAP4) += $(omap-prcm-4-5-common) prm44xx.o +obj-$(CONFIG_ARCH_OMAP5)+= $(omap-prcm-4-5-common) # OMAP voltage domains voltagedomain-common := voltage.o vc.o vp.o @@ -99,6 +105,7 @@ obj-$(CONFIG_ARCH_OMAP3) += $(voltagedomain-common) obj-$(CONFIG_ARCH_OMAP3) += voltagedomains3xxx_data.o obj-$(CONFIG_ARCH_OMAP4) +=
Re: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
On Wed, 2012-05-09 at 08:31 -0700, Tony Lindgren wrote: Note that I could prepare a new MTD patch with BCH ecc code included, allowing to drop the GPMC BCH ecc api. OK, let's do that then. I'll drop this patch and you can coordinate your patch with Afzal. Ivan, so are you going to send new patches early enough to make them hit 3.5? Can you please then re-send all the dependent patches again and again describe what depends on what, because I am getting lost :-) -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
[PATCH v2] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
From: Govindraj.R govindraj.r...@ti.com
The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of
default uart pads) removed default uart pads that where getting populated
and which was making rx pin wakeup capable. If uart pads was used in
different mode by any other module then it would fail since the default
pads took over all the uart pins forcefully. With removal of default pads
the rx_pad wakeup for console uart while waking up from off mode is broken.
Utilise the mux api available to probe the availability of mux pins
in uart mode and probe for availability of uart pin in mux mode0
if uart is available as uart pin itself then configure rx pin
as wakeup capable.
This patch itself doesn't cater to all boards. Boards using uart rx wakeup
mechanism should ensure the usage of omap_serial_init_port by configuring
required uart ports and pass necessary mux data, till then this probing of
uart pins can cater to enabling of rx pad wakeup to most of the boards.
This patch can also throw some boot warning from _omap_mux_get_by_name
if pin is requested for availability is not present while dynamically probing
the uart pins availability such boot warnings can be addressed only when board
files are patched with omap_serial_init_port calls passing the right pads
needed for a given port.
Discussion Threads for reference:
http://www.spinics.net/lists/linux-omap/msg69859.html
http://www.spinics.net/lists/linux-omap/msg68659.html
Cc: Felipe Balbi ba...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Russ Dill russ.d...@gmail.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Ameya Palande ameya.pala...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
Patching of all board files would be difficult as even I am not aware of all
omap-board schematics and uart port usage. So individual board file can be
enabled accordingly for uart usage by calling omap_serial_init_port call
with right mux data.
for testing: Patch based on v3.4-rc6
(tested on beagle-xm for off mode rx wakeup)
Patch targeted for v3.5
arch/arm/mach-omap2/mux.c|3 +-
arch/arm/mach-omap2/mux.h| 10 ++
arch/arm/mach-omap2/serial.c | 65 +++--
3 files changed, 72 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 65c3391..d937ddd 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -217,8 +217,7 @@ static int __init _omap_mux_get_by_name(struct
omap_mux_partition *partition,
return -ENODEV;
}
-static int __init
-omap_mux_get_by_name(const char *muxname,
+int __init omap_mux_get_by_name(const char *muxname,
struct omap_mux_partition **found_partition,
struct omap_mux **found_mux)
{
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 69fe060..68927f1 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -225,8 +225,18 @@ omap_hwmod_mux_init(struct omap_device_pad *bpads, int
nr_pads);
*/
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state);
+int omap_mux_get_by_name(const char *muxname,
+ struct omap_mux_partition **found_partition,
+ struct omap_mux **found_mux);
#else
+static inline int omap_mux_get_by_name(const char *muxname,
+ struct omap_mux_partition **found_partition,
+ struct omap_mux **found_mux)
+{
+ return 0;
+}
+
static inline int omap_mux_init_gpio(int gpio, int val)
{
return 0;
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 9fc2f44..c097317 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -57,6 +57,7 @@ struct omap_uart_state {
struct list_head node;
struct omap_hwmod *oh;
+ struct omap_device_pad default_omap_uart_pads[2];
};
static LIST_HEAD(uart_list);
@@ -126,11 +127,68 @@ static void omap_uart_set_smartidle(struct
platform_device *pdev) {}
#endif /* CONFIG_PM */
#ifdef CONFIG_OMAP_MUX
-static void omap_serial_fill_default_pads(struct omap_board_data *bdata)
+
+#define OMAP_UART_DEFAULT_PAD_NAME_LEN 28
+static char rx_pad_name[OMAP_UART_DEFAULT_PAD_NAME_LEN],
+ tx_pad_name[OMAP_UART_DEFAULT_PAD_NAME_LEN] __initdata;
+
+static void __init
+omap_serial_fill_uart_tx_rx_pads(struct omap_board_data *bdata,
+ struct omap_uart_state *uart)
+{
+ uart-default_omap_uart_pads[0].name = rx_pad_name;
+ uart-default_omap_uart_pads[0].flags = OMAP_DEVICE_PAD_REMUX |
+ OMAP_DEVICE_PAD_WAKEUP;
+ uart-default_omap_uart_pads[0].enable = OMAP_PIN_INPUT |
+ OMAP_MUX_MODE0;
+ uart-default_omap_uart_pads[0].idle = OMAP_PIN_INPUT | OMAP_MUX_MODE0;
+ uart-default_omap_uart_pads[1].name = tx_pad_name;
+
Re: [PATCH 01/13] ARM: OMAP5: id: Add cpu id for ES versions
On 12:56 Thu 03 May , R Sricharan wrote:
Adding the OMAP5 ES1.0, 2.0 and OMAP5432 cpu revision
detection support.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/control.h |4 +++
arch/arm/mach-omap2/id.c | 47
+
arch/arm/plat-omap/include/plat/cpu.h | 23 ++-
3 files changed, 72 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index a406fd0..9daac6f 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -246,6 +246,10 @@
/* TI81XX CONTROL_DEVCONF register offsets */
#define TI81XX_CONTROL_DEVICE_ID (TI81XX_CONTROL_DEVCONF + 0x000)
+/* OMAP54XX CONTROL STATUS register */
+#define OMAP5XXX_CONTROL_STATUS0x134
+#define OMAP5_DEVICETYPE_MASK (0x7 6)
+
/*
* REVISIT: This list of registers is not comprehensive - there are more
* that should be added.
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 0e79b7b..d2ec323 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -50,6 +50,11 @@ int omap_type(void)
val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
} else if (cpu_is_omap44xx()) {
val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
+ } else if (cpu_is_omap54xx()) {
+ val = omap_ctrl_readl(OMAP5XXX_CONTROL_STATUS);
+ val = OMAP5_DEVICETYPE_MASK;
+ val = 6;
+ goto out;
} else {
pr_err(Cannot detect omap type!\n);
goto out;
@@ -500,6 +505,48 @@ void __init omap4xxx_check_revision(void)
((omap_rev() 12) 0xf), ((omap_rev() 8) 0xf));
}
+void __init omap5xxx_check_revision(void)
+{
+ u32 idcode;
+ u16 hawkeye;
+ u8 rev;
+
+ idcode = read_tap_reg(OMAP_TAP_IDCODE);
+ hawkeye = (idcode 12) 0x;
+ rev = (idcode 28) 0xff;
+ switch (hawkeye) {
+ case 0xb942:
+ switch (rev) {
+ case 0:
+ omap_revision = OMAP5430_REV_ES1_0;
why do you duplicate this
+ break;
+ case 1:
+ omap_revision = OMAP5430_REV_ES2_0;
+ break;
do this
case 0:
+ default:
+ omap_revision = OMAP5430_REV_ES1_0;
+ }
+ break;
+
+ case 0xb998:
+ switch (rev) {
+ case 0:
+ omap_revision = OMAP5432_REV_ES1_0;
+ break;
+ default:
ditto here
+ omap_revision = OMAP5432_REV_ES1_0;
+ }
Best Regards,
J.
--
To unsubscribe from this list: send the line unsubscribe 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/13] ARM: OMAP5: id: Add cpu id for ES versions
Hi J,
why do you duplicate this
+ break;
+ case 1:
+ omap_revision = OMAP5430_REV_ES2_0;
+ break;
do this
case 0:
+ default:
+ omap_revision = OMAP5430_REV_ES1_0;
+ }
+ break;
+
+ case 0xb998:
+ switch (rev) {
+ case 0:
+ omap_revision = OMAP5432_REV_ES1_0;
+ break;
+ default:
ditto here
Agree. Will correct the redundancy.
Thanks,
Sricharan
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Jon Hunter jon-hun...@ti.com writes: [...] I have posted my latest series here [1] based upon that from Will [2] which attempts to fix the EMU CD based upon the inputs from this thread. It is working on my omap4460 panda. There are some differences between 4430 and 4460 here. Can you test on 4430 as well? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] gpio/omap: fix incorrect initialization of omap_gpio_mod_init
Grant, DebBarma, Tarun Kanti tarun.ka...@ti.com writes: Hi, On Thu, May 10, 2012 at 3:06 AM, Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: On Mon, 7 May 2012 10:52:28 DebBarma, Tarun Kanti wrote: On Sun, May 6, 2012 at 3:25 AM, Grazvydas Ignotas nota...@gmail.com wrote: On Mon, Apr 30, 2012 at 10:20 AM, Tarun Kanti DebBarma tarun.ka...@ti.com wrote: Initialization of irqenable, irqstatus registers is the common operation done in this function for all OMAP platforms, viz. OMAP1, OMAP2+. The latter _gpio_rmw()'s which supposedly got introduced wrongly to take care of OMAP2+ platforms were overwriting initially programmed OMAP1 value breaking functionality on OMAP1. Hi, I can confirm that my other issues with GPIO on Amstrad Delta were not related, and this patch is still required for GPIO interrupts hardware being correctly initialized on OMAP1 in 3.4-rc6. You can add my Tested-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl if you wish. Thank you for confirming!! We'd like to get this one in for v3.4-rc. Can you queue it? I added the tested-by from Janusz and my signoff, and pull request is below. Thanks, Kevin The following changes since commit d48b97b403d23f6df0b990cee652bdf9a52337a3: Linux 3.4-rc6 (2012-05-06 15:07:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.5/fixes/gpio for you to fetch changes up to 6edd94db250038c8fdf176f23ca4017d2f312509: gpio/omap: fix incorrect initialization of omap_gpio_mod_init (2012-05-10 07:16:15 -0700) Tarun Kanti DebBarma (1): gpio/omap: fix incorrect initialization of omap_gpio_mod_init drivers/gpio/gpio-omap.c |9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] twl4030: Various fixes for charing-from-USB
On Thu, 10 May 2012, NeilBrown wrote: Maybe we need to not suspend the USB OTG interface when the device as a whole enters suspend-to-RAM. Maybe we need to register a dummy gadget to the bus active while in suspend? Does the gadget have to be responsive while-ever the bus is not suspended? Yes. Maybe we can arrange for any USB activity to trigger a resume? Probably not, at least, not fast enough. The gadget is required to respond to USB packets within a few microseconds. At a minimum, the USB device controller would have to remain fully powered. Entering suspend while still charging really should be possible - at least with a dump charger and hopefully from a host port as well. I'll like to find the best way to achieve that, and any help you can provide would be greatly appreciated. If the gadget is attached to a dumb charger rather than a host then there's no problem. But otherwise it's not so simple. Have you read the USB charger class specification? (I haven't...) Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] mmc: omap: driver registration cleanups
On Tue, May 8, 2012 at 5:05 PM, Venkatraman S svenk...@ti.com wrote: Cleanups for the legacy omap mmc driver to remove clutter and make it well behaved as module. Venkatraman S (3): mmc: omap: convert to per instance workqueue mmc: omap: make it behave well as module mmc: omap: convert to module_platform_driver Looks good to me, So Acked-by: Balaji T K balaj...@ti.com drivers/mmc/host/omap.c | 48 +++--- 1 files changed, 16 insertions(+), 32 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
On Thu, 2012-05-10 at 17:17 +0200, Ivan Djelic wrote: But in order to do so, I need the changes that Afzal has submitted (in particular [3]). Those changes (and as a consequence, my new patch) won't hit 3.5. So, when Afzal's patches are pushed, I'll submit a new, single MTD patch. But this is not going to happen this merge window as I understood, may be not even the next one. We need to make UBIFS happy sooner than that, I think. So may be we go forward with your original patch? -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH 00/25] OMAPDSS: DT preparation patches v2
* Tomi Valkeinen tomi.valkei...@ti.com [120510 00:15]: On Wed, 2012-05-09 at 08:45 -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [120509 01:12]: Below is the pull request for board file related changes. Tested on panda 4430sdp. Thanks, I've merged that into clenaup-dss branch and will send it along with other still pending cleanup branches. How should I manage my tree related to this... Should I rebase my original DT preparation series on top of this new branch, or can I just ignore the new branch for now, as long as I merge it at some point before sending a pull request to mainline? Yes you need to rebase on this now. And not touch these commits. Otherwise we'll end up with duplicate commits in the mainline tree, which is a big no-no. If something shows up that needs fixing in this series, it must now be separate patches on top of this series. When doing pull requests we both just have to make note that there's a dependency to this branch, and it will find it's way to mainline via arm-soc pull request. Or if no conflicts need sorting out, then it will just get merged with your pull request. Hmm, I'm still not totally sure how to proceed. What do you mean with make a note? Well let's say I had some conflicting platform data clean up patches, I would pull in your branch, then when sending a pull request I would mention that it depends on your branch being pulled in. I understand that I can't change the commits, but is it ok for me to now merge the for-l-o-3.5 branch into my master branch (which is my stable branch, for which I'll send a pull request)? Yes. But I suggest you first add add that panda xm gpio fix into your for-l-o-3.5 and that way it's safer for me to merge too. If the same commits are both in my tree and in l-o (or arm-soc), doesn't it mean that the commits seem to come into Linus's tree from whoever happens to send their pull request first? Then again, does it matter.. Yes, that's OK. And if there are conflicts in the board files between for-l-o-3.5 and some other commits, and you or Arnd resolve those for l-o or arm-soc, what happens when the same, but unresolved, commits come from my pull request? Well in that case it makes sense to get the arm-soc changes merged first, who wants to resolve conflicts multiple times? Of course more branches can be pulled into both trees as needed too. Sorry if this should be obvious, but I haven't done such merging before and I'd rather not mess it up =). Yeah np :) 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] OMAPDSS: TFP410: use gpio_set_value_cansleep
* Tomi Valkeinen tomi.valkei...@ti.com [120509 23:56]: On Wed, 2012-05-09 at 16:37 -0700, Tony Lindgren wrote: * Russ Dill russ.d...@ti.com [120509 15:53]: On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren t...@atomide.com wrote: * Russ Dill russ.d...@ti.com [120509 15:12]: The Beagleboard xM gpio used for TFP410 powerdown is connected through an I2C attached chip which means setting the GPIO can sleep. Code that calls tfp410_power_on/off holds a mutex, so sleeping should be fine. What's the error without this patch? Or just no display? Just wondering if it's safe to merge Tomi's clean up series to arm-soc tree.. The only platform that has a problem is Beagleboard xM, and that is only after 'ARM: OMAP: Cleanup Beagleboard DVI reset gpio' is applied. Since the context actually can sleep, the only consequence is a WARN_ON statement. So yes, it should be safe. Well since I have not actually merged it with other branches yet, I'll wait for Tomi to apply that and repull his for-l-o-3.5 branch. You can pull for-l-o-3.5 as it is now, there's no need to change it. This _cansleep change is a separate dss specific change. So to summarize: Currently the powerdown GPIO for tfp410 is handled in the board files (and called reset gpio), with gpio_set_value(). My cleanup series moves this to the tfp410 driver. BB-xM needs to use gpio_set_value_cansleep() in tfp410 to function properly, so the tfp410 driver needs to be changed, as this patch does. I will take this patch to the dss tree. So it's safe to pull my cleanup series, but if I understood correctly, applying Russ's [PATCH v4] ARM: OMAP: Cleanup Beagleboard DVI reset gpio will cause WARN_ONs on BB-xM until this patch to tfp410 is also applied. But it doesn't sound too serious, so I think it's safe to apply the cleanup beagleboard dvi patch also. The warning will go away when both l-o and dss trees are pulled in the merge window. OK thanks will use for-l-o-3.5 as it is now then. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP2+: Misc cleanup
* Hiremath, Vaibhav hvaib...@ti.com [120510 01:37]:
On Wed, May 09, 2012 at 00:04:14, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [120508 00:18]:
Tony,
Please pull the following preparatory cleanup series to add OMAP5 minimal
support. Boot tested on OMAP2430 SDP, OMAP3430 SDP and OMAP4430 SDP
platforms.
I have dropped {[PATCH 7/7] ARM: OMAP4+: Add prm and cm base init
function}
from this set since Paul is taking that one in his queue.
OK thanks, pulling this into cleanup-soc and merging into cleanup branch
with what we have in devel-hwmod.
Tony,
Just observed that, while merging cleanup-soc into cleanup branch you have
missed couple of lines from Satosh's original patch. Which leads to build
break on OMAP2 alone build.
OK thanks for letting me know, will take a look.
Tony
Can you please merge below change,
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 833f153..c82783a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -122,6 +122,8 @@ obj-$(CONFIG_SOC_AM33XX)+=
$(powerdomain-common)
clockdomain-common += clockdomain.o
clockdomain-common += clockdomains_common_data.o
obj-$(CONFIG_ARCH_OMAP2) += $(clockdomain-common)
+obj-$(CONFIG_ARCH_OMAP2) += clockdomain2xxx_3xxx.o
+obj-$(CONFIG_ARCH_OMAP2) += clockdomains2xxx_3xxx_data.o
obj-$(CONFIG_SOC_OMAP2420) += clockdomains2420_data.o
obj-$(CONFIG_SOC_OMAP2430) += clockdomains2430_data.o
obj-$(CONFIG_ARCH_OMAP3) += $(clockdomain-common)
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On 05/09/2012 03:38 PM, Jassi Brar wrote:
On 10 May 2012 00:40, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/08/2012 01:09 PM, Jassi Brar wrote:
There is important difference between providing data via clients
during runtime vs providing info about every client to the dmac driver
at one go during its probe.
I certainly see that there is a difference.
I don't understand why it's an important difference; I think everything
needs to be handled at run-time no matter what:
Just because there is information in the DT that this client DT node
uses this channel/request-ID/... of this DMA controller doesn't mean
that the driver for the client is going to be loaded, or that SW running
on the system is going to cause that driver to actually be opened and do
any DMA. As such, any resource allocation rules etc. must be evaluated
only if/when a driver actually requests/uses a DMA channel, so having
all the information up front doesn't seem like a theoretically
possible thing anyway.
One point is about 'qos' here something like bandwidth allocation.
If the dmac driver knew up-front the max possible clients that could be
active simultaneously, it could divide the bandwidth accordingly.
Again, the example of PL330 employing 2physical channels for better
service - LLI (you got it right), where even 1 physical channel would
also have served only not as reliably. I believe there would be
more such scenarios.
QoS seems like policy to me, whereas DT is more about describing the HW.
Is DT the correct place to describe QoS policy?
I guess you are talking more about deriving policy from the description
of HW, i.e. how many client described in DT. However, for some reason
that seems dangerous to me; what if clients can be instantiated some
other way?
Another minor benefit could be that the dmac driver populate only
as many struct dma_chan as there are actually clients on the
machine (and this population has to be done during probe).
It could mean ~8 instead of ~40 channels populated on a machine.
Note, a PL330 dmac can have 32 channels, OMAP's has 128
Most importantly, I just think it's a cleaner approach.
Very similar to this, in order to support your point that a given client
could potentially use a channel from either of 2 different DMA
controller instances, you don't know until run-time which controller
will be used, so can't have up-front information in this scenario
either, even if the DMA does actually take place.
Sorry, perhaps I wasn't clear enough.
A client sees _no_ difference between the two channels that could serve it.
And it can't start using two, if two are available.
Client just needs one suitable channel on whichever dmac that might be.
If the channel for a client is to be switched runtime, that decision
should lie with the dmac driver, not the client. And I am not really
after implementing that runtime decision support.
Yes, I understood that point. The issue is:
For a 1:1 mapping (or 1:n mapping in HW with static selection specified
in the DT) between DMA client and DMA controller, perhaps the controller
can indeed make QoS decisions based on which (how many) clients are
connected to it.
However, if a DMA client can be serviced by more than 1 DMA engine, and
the decision as to which DMA engine to use occurs at run-time by the DMA
driver core, rather than being statically configured in the DT, then the
DMA controller drivers cannot know ahead of time which will be used, and
hence cannot have the full information they need to make accurate QoS
decisions ahead of time; they can only make these decisions at run-time
when the DMA channels are actually opened.
So, I believe coupling any QoS decisions to DT content alone is not correct.
Solving (b) seems to require something very roughly like:
dma-controller@0 {
compatible = foo,dmac-xxx;
dma-requests =
client0 0 // DMAC req 0 is client0's 0th req output
client0 1
client1 0
client1 1
client2 0
...;
};
dma-controller@1 {
compatible = bar,dmac-yyy;
dma-requests =
// Supports some client modules, but not the same ones
client0 0
client1 0
client3 0
...;
};
client0: i2s {
/* has 2 DMA request output signals: 0, 1 */
};
client1: spdif {
/* has 2 DMA request signals: 0, 1 */
};
client2: foo {
/* has 1 DMA request signal: 0 */
};
client3: bar {
/* has 1 DMA request signal: 0 */
};
and then having the core DMA code have an API like:
channel = dma_request(clients_dma_req_output_id)
which looks in each DMA controller's dma-requests list for the client's
phandle and matching dma_req_output_id.
Almost what I proposed in my third post in this thread !!
Yes, looking back it's quite similar, but...
The minor difference being, you use the {request-signal, phandle} pair
to
Re: [PATCH] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
On 05/09/2012 02:49 PM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [120509 13:22]:
On 05/04/2012 04:08 PM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [120504 11:59]:
On 05/04/2012 10:34 AM, Tony Lindgren wrote:
* Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com [120504 08:58]:
On 08:03 Fri 04 May , Tony Lindgren wrote:
so I was thinking to do like on gpio
uart {
pin = pioA 12 {pararms}
}
Hmm I assume the 12 above the gpio number?
no pin number in the bank because it could not be gpio
Yes OK, but pin number 12 in the gpio bank, not in the mux register.
Got it.
I'd prefer to avoid any references to GPIOs here; not all muxable pins
are GPIOs and not all GPIOs are muxable pins. Lets keep the two concepts
independent.
And it seems that pioA 12 is not always enough information for the pinctrl
driver to request a GPIO. So it's best to specify it separately.
Why would a pinctrl driver request a GPIO?
Hmm what would pinctrl_request_gpio do if the GPIO driver is separate driver?
Well, that's a GPIO driver requesting a GPIO from the pinctrl system,
rather than the pinctrl driver requesting a GPIO (sorry to be picky).
It wasn't at all obvious to me from your binding proposal that you
intended the pinctrl-simple driver to support the GPIO operations at
all. If you do want this, I think you'd need some properties (perhaps
some kind of explicit table) in order to set up the GPIO ID - pinctrl
pin ID mapping. I don't recall seeing those; did I just miss them? I
think we'd want this to be explicit because:
a) It may well be the case that not all users of pinctrl-simple actually
mux/control GPIOs at all. It's certainly possible to only mux special
functions, and have dedicated pins for a GPIO controller.
b) Even when GPIOs do come into the picture, it may be that only some of
the pins are available as GPIOs.
Also, were you intending pinctrl-simple to actually be the GPIO
controller itself? That'd be another case that one might consider fairly
simple, but then extends to being gpio-simple as well as pinctrl-simple...
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: OMAP2+: Move stubbed secure_sram_reserve function to a common.c and call it __weak
omap_secure_ram_reserve_memblock is stubbed for OMAP1,2 only builds using a
ifdef check. But this results in adding CONFIG_ARCH_OMAPxx checks for
future socs that use the real function. So move this to common.c file and
call it __weak.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/plat-omap/common.c |9 +
arch/arm/plat-omap/include/plat/omap-secure.h |5 -
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 0a9b9a9..89a3723 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -77,3 +77,12 @@ void __init omap_init_consistent_dma_size(void)
init_consistent_dma_size(CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE 20);
#endif
}
+
+/*
+ * Stub function for OMAP2 so that common files
+ * continue to build when custom builds are used
+ */
+int __weak omap_secure_ram_reserve_memblock(void)
+{
+ return 0;
+}
diff --git a/arch/arm/plat-omap/include/plat/omap-secure.h
b/arch/arm/plat-omap/include/plat/omap-secure.h
index 8c7994c..0e4acd2 100644
--- a/arch/arm/plat-omap/include/plat/omap-secure.h
+++ b/arch/arm/plat-omap/include/plat/omap-secure.h
@@ -3,12 +3,7 @@
#include linux/types.h
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
extern int omap_secure_ram_reserve_memblock(void);
-#else
-static inline void omap_secure_ram_reserve_memblock(void)
-{ }
-#endif
#ifdef CONFIG_OMAP4_ERRATA_I688
extern int omap_barrier_reserve_memblock(void);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] ARM: OMAP2+: Misc cleanup part2
This is a continuation of the previous cleanup series from santosh.shilim...@ti.com [1]. Patches are outcome of the OMAP5 review suggestions from Tony/Benoit/Santosh/Rajendra. [1] http://www.spinics.net/lists/linux-omap/msg69730.html R Sricharan (4): ARM: OMAP2+: Introduce CONFIG_SOC_HAS_OMAP_DPLL macro ARM: OMAP2+: Move the stubbed prm and cm functions to prcm.c file and make them __weak. ARM: OMAP2+: Move stubbed secure_sram_reserve function to a common.c and call it __weak ARM: OMAP: counter-32k: Select the CR register offset using the IP scheme. arch/arm/mach-omap2/Kconfig |5 ++ arch/arm/mach-omap2/clock.c |2 +- arch/arm/mach-omap2/cminst44xx.h | 25 arch/arm/mach-omap2/prcm.c| 77 + arch/arm/mach-omap2/prm2xxx_3xxx.h| 65 - arch/arm/plat-omap/common.c |9 +++ arch/arm/plat-omap/counter_32k.c | 16 - arch/arm/plat-omap/include/plat/clock.h |4 +- arch/arm/plat-omap/include/plat/omap-secure.h |5 -- 9 files changed, 107 insertions(+), 101 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: OMAP2+: Move the stubbed prm and cm functions to prcm.c file and make them __weak.
Some prm and cm registers read/write and status functions
are built only for some custom OMAP2+ builds and are stubbed
in header files for other builds under ifdef statements.
But this results in adding new CONFIG_ARCH_OMAPXXX
checks when SOCs are added in the future. So move them
to a common place for OMAP2+ and make them 'weak' implementations.
This way no new ifdefs would be required in the future and also
cleans up the existing code.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/cminst44xx.h | 25
arch/arm/mach-omap2/prcm.c | 77
arch/arm/mach-omap2/prm2xxx_3xxx.h | 65 --
3 files changed, 77 insertions(+), 90 deletions(-)
diff --git a/arch/arm/mach-omap2/cminst44xx.h b/arch/arm/mach-omap2/cminst44xx.h
index a018a73..d69fdef 100644
--- a/arch/arm/mach-omap2/cminst44xx.h
+++ b/arch/arm/mach-omap2/cminst44xx.h
@@ -16,38 +16,13 @@ extern void omap4_cminst_clkdm_enable_hwsup(u8 part, s16
inst, u16 cdoffs);
extern void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs);
extern void omap4_cminst_clkdm_force_sleep(u8 part, s16 inst, u16 cdoffs);
extern void omap4_cminst_clkdm_force_wakeup(u8 part, s16 inst, u16 cdoffs);
-
extern int omap4_cminst_wait_module_ready(u8 part, u16 inst, s16 cdoffs, u16
clkctrl_offs);
-
-# ifdef CONFIG_ARCH_OMAP4
extern int omap4_cminst_wait_module_idle(u8 part, u16 inst, s16 cdoffs,
u16 clkctrl_offs);
-
extern void omap4_cminst_module_enable(u8 mode, u8 part, u16 inst, s16 cdoffs,
u16 clkctrl_offs);
extern void omap4_cminst_module_disable(u8 part, u16 inst, s16 cdoffs,
u16 clkctrl_offs);
-
-# else
-
-static inline int omap4_cminst_wait_module_idle(u8 part, u16 inst, s16 cdoffs,
- u16 clkctrl_offs)
-{
- return 0;
-}
-
-static inline void omap4_cminst_module_enable(u8 mode, u8 part, u16 inst,
- s16 cdoffs, u16 clkctrl_offs)
-{
-}
-
-static inline void omap4_cminst_module_disable(u8 part, u16 inst, s16 cdoffs,
-u16 clkctrl_offs)
-{
-}
-
-# endif
-
/*
* In an ideal world, we would not export these low-level functions,
* but this will probably take some time to fix properly
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 480f40a..9bc3f5d 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -164,3 +164,80 @@ void __init omap2_set_globals_prcm(struct omap_globals
*omap2_globals)
omap_cm_base_init();
}
}
+
+/*
+ * Stubbed functions so that common files
+ * continue to build when custom builds are used
+ */
+u32 __weak omap2_prm_read_mod_reg(s16 module, u16 idx)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
+
+void __weak omap2_prm_write_mod_reg(u32 val, s16 module, u16 idx)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+}
+u32 __weak omap2_prm_rmw_mod_reg_bits(u32 mask, u32 bits,
+ s16 module, s16 idx)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
+u32 __weak omap2_prm_set_mod_reg_bits(u32 bits, s16 module, s16 idx)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
+u32 __weak omap2_prm_clear_mod_reg_bits(u32 bits, s16 module, s16 idx)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
+u32 __weak omap2_prm_read_mod_bits_shift(s16 domain, s16 idx, u32 mask)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
+int __weak omap2_prm_is_hardreset_asserted(s16 prm_mod, u8 shift)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
+int __weak omap2_prm_assert_hardreset(s16 prm_mod, u8 shift)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
+int __weak omap2_prm_deassert_hardreset(s16 prm_mod, u8 rst_shift,
+ u8 st_shift)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
+
+int __weak omap4_cminst_wait_module_idle(u8 part, u16 inst, s16 cdoffs,
+ u16 clkctrl_offs)
+{
+ return 0;
+}
+
+void __weak omap4_cminst_module_enable(u8 mode, u8 part, u16 inst,
+ s16
[PATCH 1/4] ARM: OMAP2+: Introduce CONFIG_SOC_HAS_OMAP_DPLL macro
The DPLL ip was introduced and used in the OMAP3PLUS socs, while
OMAP2 had the APLL IP. There are some features which are common
to both ips, and some which are only applicable to DPLL ip's.
Currently CONFIG_ARCH_OMAP_XXX checks is used to conditionally
compile the additional features for every applicable SOC. This
makes it nessecary to add new a check for every new SOC added
in the future.
So by introducing a new SOC_HAS_OMAP_DPLL config such new #ifdefs
can be avoided for the future socs and also to cleanup the existing
ifdefferies.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/Kconfig |5 +
arch/arm/mach-omap2/clock.c |2 +-
arch/arm/plat-omap/include/plat/clock.h |4 ++--
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 0685dc8..9a8d691 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -27,9 +27,13 @@ config ARCH_OMAP2
select CPU_V6
select MULTI_IRQ_HANDLER
+config SOC_HAS_OMAP_DPLL
+ bool
+
config ARCH_OMAP3
bool TI OMAP3
depends on ARCH_OMAP2PLUS
+ select SOC_HAS_OMAP_DPLL
default y
select CPU_V7
select USB_ARCH_HAS_EHCI if USB_SUPPORT
@@ -42,6 +46,7 @@ config ARCH_OMAP4
bool TI OMAP4
default y
depends on ARCH_OMAP2PLUS
+ select SOC_HAS_OMAP_DPLL
select CACHE_L2X0
select CPU_V7
select ARM_GIC
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index d9f4931..629cd2d 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -400,7 +400,7 @@ int omap2_clk_set_parent(struct clk *clk, struct clk
*new_parent)
/* OMAP3/4 non-CORE DPLL clkops */
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
+#ifdef CONFIG_SOC_HAS_OMAP_DPLL
const struct clkops clkops_omap3_noncore_dpll_ops = {
.enable = omap3_noncore_dpll_enable,
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index d0ef57c..095bee8 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -156,7 +156,7 @@ struct dpll_data {
u8 min_divider;
u16 max_divider;
u8 modes;
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
+#ifdef CONFIG_SOC_HAS_OMAP_DPLL
void __iomem*autoidle_reg;
void __iomem*idlest_reg;
u32 autoidle_mask;
@@ -167,7 +167,7 @@ struct dpll_data {
u8 auto_recal_bit;
u8 recal_en_bit;
u8 recal_st_bit;
-# endif
+#endif
u8 flags;
};
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: OMAP: counter-32k: Select the CR register offset using the IP scheme.
OMAP socs has a legacy and a highlander version of the 32k sync counter IP. The register offsets vary between the highlander and the legacy scheme. So use the 'SCHEME' bits(30-31) of the revision register to distinguish between the two versions and choose the CR register offset accordingly. Signed-off-by: R Sricharan r.sricha...@ti.com --- arch/arm/plat-omap/counter_32k.c | 16 +--- 1 files changed, 13 insertions(+), 3 deletions(-) diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c index b2f634b..cbd939d 100644 --- a/arch/arm/plat-omap/counter_32k.c +++ b/arch/arm/plat-omap/counter_32k.c @@ -28,7 +28,10 @@ #include plat/clock.h /* OMAP2_32KSYNCNT_CR_OFF: offset of 32ksync counter register */ -#define OMAP2_32KSYNCNT_CR_OFF 0x10 +#define OMAP2_32KSYNCNT_REV_OFF0x0 +#define OMAP2_32KSYNCNT_REV_SCHEME (0x3 30) +#define OMAP2_32KSYNCNT_CR_OFF_LOW 0x10 +#define OMAP2_32KSYNCNT_CR_OFF_HIGH0x30 /* * 32KHz clocksource ... always available, on pretty most chips except @@ -83,9 +86,16 @@ int __init omap_init_clocksource_32k(void __iomem *vbase) int ret; /* -* 32k sync Counter register offset is at 0x10 +* 32k sync Counter IP register offsets vary between the +* highlander version and the legacy ones. +* The 'SCHEME' bits(30-31) of the revision register is used +* to identify the version. */ - sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF; + if (__raw_readl(vbase + OMAP2_32KSYNCNT_REV_OFF) + OMAP2_32KSYNCNT_REV_SCHEME) + sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF_HIGH; + else + sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF_LOW; /* * 12 rough estimate from the calculations in -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/4] ARM: OMAP2+: Misc cleanup part2
-Original Message- From: R Sricharan [mailto:r.sricha...@ti.com] Sent: Thursday, May 10, 2012 10:37 PM To: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org; santosh.shilim...@ti.com; t...@atomide.com; b-cous...@ti.com; r.sricha...@ti.com; p...@pswan.com Subject: [PATCH 0/4] ARM: OMAP2+: Misc cleanup part2 This is a continuation of the previous cleanup series from santosh.shilim...@ti.com [1]. Patches are outcome of the OMAP5 review suggestions from Tony/Benoit/Santosh/Rajendra. [1] http://www.spinics.net/lists/linux-omap/msg69730.html R Sricharan (4): ARM: OMAP2+: Introduce CONFIG_SOC_HAS_OMAP_DPLL macro ARM: OMAP2+: Move the stubbed prm and cm functions to prcm.c file and make them __weak. ARM: OMAP2+: Move stubbed secure_sram_reserve function to a common.c and call it __weak ARM: OMAP: counter-32k: Select the CR register offset using the IP scheme. Forgot to add the below reviewed-by tag. Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Thanks, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP3+: PRM/hwmod: fix and improve I/O chain wakeup support
Hi Tero, On Wed, 9 May 2012, Tero Kristo wrote: On Fri, 2012-04-20 at 09:55 -0700, Tony Lindgren wrote: * Tero Kristo t-kri...@ti.com [120420 01:24]: Hi, What happened with this pull request? It doesn't seem to be in 3.4 at least. There was a boot issue on omap3 evm and that branch got dropped. Will merge it again after Paul has figured out the issue. Paul / Tony, do you want me to re-send the set for this with the OMAP3 EVM related fix? This was figured out in a separate email chain. Will try to integrate it here. But maybe if I run into problems here, I might ask for your help. By the way, I regret how long it's taken me to review and handle some of your pending patchsets. They haven't been forgotten here... - 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 1/3] ARM: OMAP AM35xx: clock and hwmod data: fix AM35xx HSOTGUSB hwmod
Partially fix the hwmod data for the AM35xx USB OTG hwmod. This
should resolve the following boot warning on AM35xx platforms:
omap_hwmod: am35x_otg_hs: cannot be enabled for reset (3)
While here, also fix the clkdev records, to avoid warnings about
duplicate clock aliases.
The hwmod is also connected to the wrong interconnect. It should be
connected to the IPSS, not the L4 CORE. But that is left for a future
fix, since it probably has a dependency on some hwmod core changes.
Cc: Felipe Balbi ba...@ti.com
Cc: Hema HK hem...@ti.com
Cc: Mark A. Greer mgr...@animalcreek.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock3xxx_data.c |4 ++--
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 14 +-
2 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 4e1a3b0..13102b9 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3478,8 +3478,8 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(davinci_mdio.0, NULL, emac_fck, CK_AM35XX),
CLK(vpfe-capture, master, vpfe_ick, CK_AM35XX),
CLK(vpfe-capture, slave,vpfe_fck, CK_AM35XX),
- CLK(musb-am35x, ick, hsotgusb_ick_am35xx,
CK_AM35XX),
- CLK(musb-am35x, fck, hsotgusb_fck_am35xx,
CK_AM35XX),
+ CLK(NULL, hsotgusb_ick, hsotgusb_ick_am35xx,
CK_AM35XX),
+ CLK(NULL, hsotgusb_fck, hsotgusb_fck_am35xx,
CK_AM35XX),
CLK(NULL, hecc_ck, hecc_ck, CK_AM35XX),
CLK(NULL, uart4_ick,uart4_ick_am35xx, CK_AM35XX),
CLK(omap_timer.1, 32k_ck, omap_32k_fck, CK_3XXX),
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 0c65079..678a3aa 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1637,25 +1637,20 @@ static struct omap_hwmod omap3xxx_usbhsotg_hwmod = {
/* usb_otg_hs */
static struct omap_hwmod_irq_info am35xx_usbhsotg_mpu_irqs[] = {
-
{ .name = mc, .irq = 71 },
{ .irq = -1 }
};
static struct omap_hwmod_class am35xx_usbotg_class = {
.name = am35xx_usbotg,
- .sysc = NULL,
};
static struct omap_hwmod am35xx_usbhsotg_hwmod = {
.name = am35x_otg_hs,
.mpu_irqs = am35xx_usbhsotg_mpu_irqs,
- .main_clk = NULL,
- .prcm = {
- .omap2 = {
- },
- },
+ .main_clk = hsotgusb_fck,
.class = am35xx_usbotg_class,
+ .flags = HWMOD_NO_IDLEST,
};
/* MMC/SD/SDIO common */
@@ -2046,9 +2041,10 @@ static struct omap_hwmod_ocp_if omap3xxx_usbhsotg__l3 = {
static struct omap_hwmod_ocp_if am35xx_usbhsotg__l3 = {
.master = am35xx_usbhsotg_hwmod,
.slave = omap3xxx_l3_main_hwmod,
- .clk= core_l3_ick,
+ .clk= hsotgusb_ick,
.user = OCP_USER_MPU,
};
+
/* L4_CORE - L4_WKUP interface */
static struct omap_hwmod_ocp_if omap3xxx_l4_core__l4_wkup = {
.master = omap3xxx_l4_core_hwmod,
@@ -2342,7 +2338,7 @@ static struct omap_hwmod_addr_space
am35xx_usbhsotg_addrs[] = {
static struct omap_hwmod_ocp_if am35xx_l4_core__usbhsotg = {
.master = omap3xxx_l4_core_hwmod,
.slave = am35xx_usbhsotg_hwmod,
- .clk= l4_ick,
+ .clk= hsotgusb_ick,
.addr = am35xx_usbhsotg_addrs,
.user = OCP_USER_MPU,
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: OMAP: AM35xx: fix UART4 softreset
During kernel init, the AM3505/AM3517 UART4 cannot complete its softreset:
omap_hwmod: uart4: softreset failed (waited 1 usec)
This also results in another warning later in the boot process:
omap_hwmod: uart4: enabled state can only be entered from initialized, idle, or
disabled state
From empirical observation, the AM35xx UART4 IP block requires either
uart1_fck or uart2_fck to be enabled while UART4 resets. Otherwise
the reset will never complete. So this patch adds uart1_fck as an
optional clock for UART4 and adds the appropriate hwmod flag to cause
uart1_fck to be enabled during the reset process. (The choice of
uart1_fck over uart2_fck was arbitrary.)
Unfortunately this observation raises many questions. Is it necessary
for uart1_fck or uart2_fck to be controlled with uart4_fck for the
UART4 to work correctly? What exactly do the AM35xx UART4 clock
tree and the related PRCM idle management FSMs look like? If anyone
has the ability to answer these questions through empirical functional
testing, or hardware information from the AM35xx designers, it would
be greatly appreciated.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Kyle Manna kyle.ma...@fuel7.com
Cc: Mark A. Greer mgr...@animalcreek.com
Cc: Ranjith Lohithakshan ranji...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock3xxx_data.c |8 ++--
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 17 +
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 11644bf..12c64db 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3201,8 +3201,12 @@ static struct clk vpfe_fck = {
};
/*
- * The UART1/2 functional clock acts as the functional
- * clock for UART4. No separate fclk control available.
+ * The UART1/2 functional clock acts as the functional clock for
+ * UART4. No separate fclk control available. XXX Well now we have a
+ * uart4_fck that is apparently used as the UART4 functional clock,
+ * but it also seems that uart1_fck or uart2_fck are still needed, at
+ * least for UART4 softresets to complete. This really needs
+ * clarification.
*/
static struct clk uart4_ick_am35xx = {
.name = uart4_ick,
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index c939131..c6653a80 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -535,6 +535,20 @@ static struct omap_hwmod_dma_info am35xx_uart4_sdma_reqs[]
= {
{ .dma_req = -1 }
};
+/*
+ * XXX AM35xx UART4 cannot complete its softreset without uart1_fck or
+ * uart2_fck being enabled. So we add uart1_fck as an optional clock,
+ * below, and set the HWMOD_CONTROL_OPT_CLKS_IN_RESET. This really
+ * should not be needed. The functional clock structure of the AM35xx
+ * UART4 is extremely unclear and opaque; it is unclear what the role
+ * of uart1/2_fck is for the UART4. Any clarification from either
+ * empirical testing or the AM3505/3517 hardware designers would be
+ * most welcome.
+ */
+static struct omap_hwmod_opt_clk am35xx_uart4_opt_clks[] = {
+ { .role = softreset_uart1_fck, .clk = uart1_fck },
+};
+
static struct omap_hwmod am35xx_uart4_hwmod = {
.name = uart4,
.mpu_irqs = am35xx_uart4_mpu_irqs,
@@ -549,6 +563,9 @@ static struct omap_hwmod am35xx_uart4_hwmod = {
.idlest_idle_bit = AM35XX_ST_UART4_SHIFT,
},
},
+ .opt_clks = am35xx_uart4_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(am35xx_uart4_opt_clks),
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.class = omap2_uart_class,
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: OMAP2+: Move the stubbed prm and cm functions to prcm.c file and make them __weak.
Hi On Thu, 10 May 2012, R Sricharan wrote: Some prm and cm registers read/write and status functions are built only for some custom OMAP2+ builds and are stubbed in header files for other builds under ifdef statements. But this results in adding new CONFIG_ARCH_OMAPXXX checks when SOCs are added in the future. So move them to a common place for OMAP2+ and make them 'weak' implementations. Thanks for the patch. These stubs aren't needed any longer, so we can just get rid of them; no need to mark them __weak. I've got a patch to just drop them here to be posted soon as part of a larger PRCM cleanup. - 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 00/13] ARM: OMAP5: Add minimal OMAP5 SOC support
Hi Tony, -Original Message- From: R Sricharan [mailto:r.sricha...@ti.com] Sent: Thursday, May 03, 2012 12:56 PM To: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org; santosh.shilim...@ti.com; t...@atomide.com; b-cous...@ti.com; r.sricha...@ti.com Subject: [PATCH 00/13] ARM: OMAP5: Add minimal OMAP5 SOC support The series adds minimal OMAP5 support. OMAP5430 has a dual core Cortex-A15 based MPU subsystem with 2MB L2 cache. The SOC has many compatible blocks with OMAP4 SOCS and hence large part of the peripherals are re-used. OMAP5432 is another variant of OMAP5430, with a memory controller supporting DDR3 and SATA. OMAP5 V2 series is ready with all comments addressed, but I have below dependencies to be merged to apply my series against your cleanup-soc branch 1) git://git.pwsan.com/linux-2.6 hwmod_soc_conditional_cleanup_3.5 2) git://git.pwsan.com/linux-2.6 hwmod_data_cleanup_3.5 3) https://github.com/hvaibhav/am335x-linux 32ksync-timer-cleanup 4) http://www.spinics.net/lists/arm-kernel/msg174461.html Can you please let me know how you want me to prepare the series with these dependencies. Thanks, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/4] ARM: OMAP2+: Move the stubbed prm and cm functions to prcm.c file and make them __weak.
Hi Paul, On Thu, 10 May 2012, R Sricharan wrote: Some prm and cm registers read/write and status functions are built only for some custom OMAP2+ builds and are stubbed in header files for other builds under ifdef statements. But this results in adding new CONFIG_ARCH_OMAPXXX checks when SOCs are added in the future. So move them to a common place for OMAP2+ and make them 'weak' implementations. Thanks for the patch. These stubs aren't needed any longer, so we can just get rid of them; no need to mark them __weak. I've got a patch to just drop them here to be posted soon as part of a larger PRCM cleanup. Thanks. I will pick up your series. Thanks, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
On Thu, May 10, 2012 at 04:52:18PM +0100, Artem Bityutskiy wrote: On Thu, 2012-05-10 at 17:17 +0200, Ivan Djelic wrote: But in order to do so, I need the changes that Afzal has submitted (in particular [3]). Those changes (and as a consequence, my new patch) won't hit 3.5. So, when Afzal's patches are pushed, I'll submit a new, single MTD patch. But this is not going to happen this merge window as I understood, may be not even the next one. We need to make UBIFS happy sooner than that, I think. So may be we go forward with your original patch? I'm OK with this too, as the patches are ready and tested. The MTD patch is [2], it depends on [1] which has been pushed, then dropped by Tony. Do you need me to repost [2] ? Tony, sorry to backpedal on this: would you re-push patch [1], if indeed Afzal's patches are not going to be merged soon ? In the meantime, I can prepare a patch on top of Afzal's to have a smooth transition w.r.t BCH support. What do you think ? Best Regards, -- Ivan [1] http://lists.infradead.org/pipermail/linux-mtd/2012-April/040965.html [2] http://lists.infradead.org/pipermail/linux-mtd/2012-April/041020.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V2] ARM: OMAP2+: am33xx: Make am33xx as a separate class
* Tony Lindgren t...@atomide.com [120509 11:58]: * Vaibhav Hiremath hvaib...@ti.com [120509 04:28]: Initially, we decided to make am33xx family of device to fall under omap3 class (cpu_is_omap34xx() = true), since it carries Cortex-A8 core. But while adding complete baseport support (like, clock, power and hwmod) support, it is observed that, we are creating more and more problems by treating am33xx device as omap3 family, as nothing matches between them (except cortex-A8 mpu). Thanks applying into devel-soc after updating for soc_is change and fixing typo in the description that stil said OMAPAM. Updated patch below. Turns out we still need to add defined(CONFIG_SOC_AM33XX) around __omap2_set_globals() to keep compile working when omap4 + am33xx are selected without omap2 or 3. Also removed the default y for am33xx as that's where we're heading to anyways. Updated patch below. Tony From 54891e60bc79c43c2dbc8351f62ac5c3e8eb3592 Mon Sep 17 00:00:00 2001 From: Vaibhav Hiremath hvaib...@ti.com Date: Wed, 9 May 2012 16:54:27 +0530 Subject: [PATCH] ARM: OMAP2+: am33xx: Make am33xx as a separate class Initially, we decided to make am33xx family of device to fall under omap3 class (cpu_is_omap34xx() = true), since it carries Cortex-A8 core. But while adding complete baseport support (like, clock, power and hwmod) support, it is observed that, we are creating more and more problems by treating am33xx device as omap3 family, as nothing matches between them (except cortex-A8 mpu). So, after long discussion we have came to the conclusion that, we should not consider am33xx device as omap3 family, instead create separate class (SOC_AM33XX) under OMAP2PLUS. This means, for am33xx device, cpu_is_omap34xx() will return false, and only cpu_is_am33xx() will be true. Please refer to the link below, for mailing-list discussion on this - http://www.spinics.net/lists/linux-omap/msg69439.html Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: Paul Walmsley p...@pwsan.com [t...@atomide.com: fixed typo, updated for soc_is] Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 61bf3c3..5bc2604 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -84,8 +84,9 @@ config SOC_TI81XX config SOC_AM33XX bool AM33XX support - depends on ARCH_OMAP3 - default y + select CPU_V7 + select ARM_CPU_SUSPEND if PM + select MULTI_IRQ_HANDLER config OMAP_PACKAGE_ZAF bool diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 7cdb940..288e1a3 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -16,6 +16,7 @@ secure-common = omap-smc.o omap-secure.o obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(hwmod-common) obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(hwmod-common) $(secure-common) obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common) $(secure-common) +obj-$(CONFIG_SOC_AM33XX) += irq.o $(hwmod-common) ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),) obj-y += mcbsp.o @@ -90,6 +91,7 @@ obj-$(CONFIG_ARCH_OMAP3) += vc3xxx_data.o vp3xxx_data.o obj-$(CONFIG_ARCH_OMAP4) += prcm.o cminst44xx.o cm44xx.o obj-$(CONFIG_ARCH_OMAP4) += prcm_mpu44xx.o prminst44xx.o obj-$(CONFIG_ARCH_OMAP4) += vc44xx_data.o vp44xx_data.o prm44xx.o +obj-$(CONFIG_SOC_AM33XX) += prcm.o # OMAP voltage domains voltagedomain-common := voltage.o vc.o vp.o @@ -99,6 +101,7 @@ obj-$(CONFIG_ARCH_OMAP3) += $(voltagedomain-common) obj-$(CONFIG_ARCH_OMAP3) += voltagedomains3xxx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common) obj-$(CONFIG_ARCH_OMAP4) += voltagedomains44xx_data.o +obj-$(CONFIG_SOC_AM33XX) += $(voltagedomain-common) # OMAP powerdomain framework powerdomain-common += powerdomain.o powerdomain-common.o @@ -113,6 +116,7 @@ obj-$(CONFIG_ARCH_OMAP3)+= powerdomains2xxx_3xxx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(powerdomain-common) obj-$(CONFIG_ARCH_OMAP4) += powerdomain44xx.o obj-$(CONFIG_ARCH_OMAP4) += powerdomains44xx_data.o +obj-$(CONFIG_SOC_AM33XX) += $(powerdomain-common) # PRCM clockdomain control clockdomain-common += clockdomain.o @@ -129,6 +133,7 @@ obj-$(CONFIG_ARCH_OMAP3)+= clockdomains3xxx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(clockdomain-common) obj-$(CONFIG_ARCH_OMAP4) += clockdomain44xx.o obj-$(CONFIG_ARCH_OMAP4) += clockdomains44xx_data.o +obj-$(CONFIG_SOC_AM33XX) += $(clockdomain-common) # Clock framework obj-$(CONFIG_ARCH_OMAP2) += $(clock-common) clock2xxx.o @@ -146,6 +151,7 @@ obj-$(CONFIG_ARCH_OMAP3)
Re: [PATCH-V2] ARM: OMAP2+: am33xx: Make am33xx as a separate class
* Tony Lindgren t...@atomide.com [120510 11:06]: * Tony Lindgren t...@atomide.com [120509 11:58]: * Vaibhav Hiremath hvaib...@ti.com [120509 04:28]: Initially, we decided to make am33xx family of device to fall under omap3 class (cpu_is_omap34xx() = true), since it carries Cortex-A8 core. But while adding complete baseport support (like, clock, power and hwmod) support, it is observed that, we are creating more and more problems by treating am33xx device as omap3 family, as nothing matches between them (except cortex-A8 mpu). Thanks applying into devel-soc after updating for soc_is change and fixing typo in the description that stil said OMAPAM. Updated patch below. Turns out we still need to add defined(CONFIG_SOC_AM33XX) around __omap2_set_globals() to keep compile working when omap4 + am33xx are selected without omap2 or 3. Also removed the default y for am33xx as that's where we're heading to anyways. Updated patch below. Argh, now it breaks with: arch/arm/mach-omap2/built-in.o: In function `omap2_set_globals_am33xx': twl-common.c:(.init.text+0x1dd8): undefined reference to `omap2_set_globals_sdrc' There are clearly some dependencies to the clean up patches being discussed.. So I'll drop this for now until the clean up is sorted out. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V2] ARM: OMAP2+: am33xx: Make am33xx as a separate class
On Thu, May 10, 2012 at 23:35:36, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [120510 11:06]: * Tony Lindgren t...@atomide.com [120509 11:58]: * Vaibhav Hiremath hvaib...@ti.com [120509 04:28]: Initially, we decided to make am33xx family of device to fall under omap3 class (cpu_is_omap34xx() = true), since it carries Cortex-A8 core. But while adding complete baseport support (like, clock, power and hwmod) support, it is observed that, we are creating more and more problems by treating am33xx device as omap3 family, as nothing matches between them (except cortex-A8 mpu). Thanks applying into devel-soc after updating for soc_is change and fixing typo in the description that stil said OMAPAM. Updated patch below. Turns out we still need to add defined(CONFIG_SOC_AM33XX) around __omap2_set_globals() to keep compile working when omap4 + am33xx are selected without omap2 or 3. Also removed the default y for am33xx as that's where we're heading to anyways. Updated patch below. Argh, now it breaks with: arch/arm/mach-omap2/built-in.o: In function `omap2_set_globals_am33xx': twl-common.c:(.init.text+0x1dd8): undefined reference to `omap2_set_globals_sdrc' There are clearly some dependencies to the clean up patches being discussed.. So I'll drop this for now until the clean up is sorted out. All cleanup patches which I have posted should resolve these issues. Do you see any issues with them? ARM: OMAP2+: CLEANUP: All OMAP2PLUS uses omap-device.o target so add one entry ARM: OMAP2+: CLEANUP: Move omap3 dpll ops to dpll3xxx.c ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals You can only drop last patch, on which Kevin had commented, rest all should be merged. ARM: OMAP2+: CLEANUP: Add new config option for different DPLL Features Please let me know if I am missing something. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/4] ARM: OMAP2+: Introduce CONFIG_SOC_HAS_OMAP_DPLL macro
On Thu, May 10, 2012 at 22:36:52, R, Sricharan wrote:
The DPLL ip was introduced and used in the OMAP3PLUS socs, while
OMAP2 had the APLL IP. There are some features which are common
to both ips, and some which are only applicable to DPLL ip's.
Currently CONFIG_ARCH_OMAP_XXX checks is used to conditionally
compile the additional features for every applicable SOC. This
makes it nessecary to add new a check for every new SOC added
in the future.
So by introducing a new SOC_HAS_OMAP_DPLL config such new #ifdefs
can be avoided for the future socs and also to cleanup the existing
ifdefferies.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/Kconfig |5 +
arch/arm/mach-omap2/clock.c |2 +-
arch/arm/plat-omap/include/plat/clock.h |4 ++--
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 0685dc8..9a8d691 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -27,9 +27,13 @@ config ARCH_OMAP2
select CPU_V6
select MULTI_IRQ_HANDLER
+config SOC_HAS_OMAP_DPLL
+ bool
+
config ARCH_OMAP3
bool TI OMAP3
depends on ARCH_OMAP2PLUS
+ select SOC_HAS_OMAP_DPLL
default y
select CPU_V7
select USB_ARCH_HAS_EHCI if USB_SUPPORT
@@ -42,6 +46,7 @@ config ARCH_OMAP4
bool TI OMAP4
default y
depends on ARCH_OMAP2PLUS
+ select SOC_HAS_OMAP_DPLL
select CACHE_L2X0
select CPU_V7
select ARM_GIC
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index d9f4931..629cd2d 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -400,7 +400,7 @@ int omap2_clk_set_parent(struct clk *clk, struct clk
*new_parent)
/* OMAP3/4 non-CORE DPLL clkops */
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
+#ifdef CONFIG_SOC_HAS_OMAP_DPLL
const struct clkops clkops_omap3_noncore_dpll_ops = {
.enable = omap3_noncore_dpll_enable,
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index d0ef57c..095bee8 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -156,7 +156,7 @@ struct dpll_data {
u8 min_divider;
u16 max_divider;
u8 modes;
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
+#ifdef CONFIG_SOC_HAS_OMAP_DPLL
void __iomem*autoidle_reg;
void __iomem*idlest_reg;
u32 autoidle_mask;
@@ -167,7 +167,7 @@ struct dpll_data {
u8 auto_recal_bit;
u8 recal_en_bit;
u8 recal_st_bit;
-# endif
+#endif
I had submitted similar patch recently, and Kevin had suggested that
Instead of adding config option, we shoule simply get rid of this ifdef
completely.
Refer to
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg68293.html
Waiting for Paul to conform here.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V2] ARM: OMAP2+: am33xx: Make am33xx as a separate class
* Hiremath, Vaibhav hvaib...@ti.com [120510 11:22]: On Thu, May 10, 2012 at 23:35:36, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [120510 11:06]: * Tony Lindgren t...@atomide.com [120509 11:58]: * Vaibhav Hiremath hvaib...@ti.com [120509 04:28]: Initially, we decided to make am33xx family of device to fall under omap3 class (cpu_is_omap34xx() = true), since it carries Cortex-A8 core. But while adding complete baseport support (like, clock, power and hwmod) support, it is observed that, we are creating more and more problems by treating am33xx device as omap3 family, as nothing matches between them (except cortex-A8 mpu). Thanks applying into devel-soc after updating for soc_is change and fixing typo in the description that stil said OMAPAM. Updated patch below. Turns out we still need to add defined(CONFIG_SOC_AM33XX) around __omap2_set_globals() to keep compile working when omap4 + am33xx are selected without omap2 or 3. Also removed the default y for am33xx as that's where we're heading to anyways. Updated patch below. Argh, now it breaks with: arch/arm/mach-omap2/built-in.o: In function `omap2_set_globals_am33xx': twl-common.c:(.init.text+0x1dd8): undefined reference to `omap2_set_globals_sdrc' There are clearly some dependencies to the clean up patches being discussed.. So I'll drop this for now until the clean up is sorted out. All cleanup patches which I have posted should resolve these issues. Do you see any issues with them? ARM: OMAP2+: CLEANUP: All OMAP2PLUS uses omap-device.o target so add one entry That looks OK to me. ARM: OMAP2+: CLEANUP: Move omap3 dpll ops to dpll3xxx.c This one should be at least acked by Paul. ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals This one should be acked by both Paul and Kevin. You can only drop last patch, on which Kevin had commented, rest all should be merged. ARM: OMAP2+: CLEANUP: Add new config option for different DPLL Features Please let me know if I am missing something. Looks OK otherwise, just can't quite apply them yet without the acks. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V2] ARM: OMAP2+: am33xx: Make am33xx as a separate class
On Fri, May 11, 2012 at 00:00:25, Tony Lindgren wrote: * Hiremath, Vaibhav hvaib...@ti.com [120510 11:22]: On Thu, May 10, 2012 at 23:35:36, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [120510 11:06]: * Tony Lindgren t...@atomide.com [120509 11:58]: * Vaibhav Hiremath hvaib...@ti.com [120509 04:28]: Initially, we decided to make am33xx family of device to fall under omap3 class (cpu_is_omap34xx() = true), since it carries Cortex-A8 core. But while adding complete baseport support (like, clock, power and hwmod) support, it is observed that, we are creating more and more problems by treating am33xx device as omap3 family, as nothing matches between them (except cortex-A8 mpu). Thanks applying into devel-soc after updating for soc_is change and fixing typo in the description that stil said OMAPAM. Updated patch below. Turns out we still need to add defined(CONFIG_SOC_AM33XX) around __omap2_set_globals() to keep compile working when omap4 + am33xx are selected without omap2 or 3. Also removed the default y for am33xx as that's where we're heading to anyways. Updated patch below. Argh, now it breaks with: arch/arm/mach-omap2/built-in.o: In function `omap2_set_globals_am33xx': twl-common.c:(.init.text+0x1dd8): undefined reference to `omap2_set_globals_sdrc' There are clearly some dependencies to the clean up patches being discussed.. So I'll drop this for now until the clean up is sorted out. All cleanup patches which I have posted should resolve these issues. Do you see any issues with them? ARM: OMAP2+: CLEANUP: All OMAP2PLUS uses omap-device.o target so add one entry That looks OK to me. ARM: OMAP2+: CLEANUP: Move omap3 dpll ops to dpll3xxx.c This one should be at least acked by Paul. ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals This one should be acked by both Paul and Kevin. You can only drop last patch, on which Kevin had commented, rest all should be merged. ARM: OMAP2+: CLEANUP: Add new config option for different DPLL Features Please let me know if I am missing something. Looks OK otherwise, just can't quite apply them yet without the acks. Understood. Let's wait for Kevin and Paul's ack on this. I will ping them tomorrow again... Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] ARM: OMAP: AM35xx: fix some boot warnings with AM3505/3517
Hi Mark On Thu, 10 May 2012, Mark A. Greer wrote: On Thu, May 10, 2012 at 11:29:13AM -0600, Paul Walmsley wrote: Hello, this series fixes some of the warnings observed at boot with the AM35xx boards. Intended for either the 3.5 or 3.5-rc merge windows. Particularly appreciated would be some feedback on the ARM: OMAP: AM35xx: fix UART4 softreset patch from people who know the AM35xx SoC hardware. What repo/branch are these patches based on? They are based on the 'omap-devel-b-for-3.5' tag in my omap-pending tree on kernel.org: http://git.kernel.org/?p=linux/kernel/git/pjw/omap-pending.git;a=tag;h=8b14f48f6a985a71e250feb3e8595d9400829a18 The series is also available via git from git://git.pwsan.com/linux-2.6 in the branch am35xx_hwmod_data_fixes_a_3.5. - 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: [GIT PULL 9/10] omap devicetree updates for v3.5 merge window
* Tony Lindgren t...@atomide.com [120510 11:49]:
The following changes since commit b3431f5ba402a98a89b78a9408b4972d8870df4d:
arm/dts: OMAP3: Add mmc controller nodes and board data (2012-03-14
21:54:57 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-dt-for-v3.5
for you to fetch changes up to 40364b9f5a4d167d97bb6a76cd239ca8cfff056a:
arm/dts: omap4-panda: Add LEDs support (2012-05-09 17:18:03 -0700)
Minor DT updates based on the dt-missed-3.4 branch
For this one there's a minor merge conflict, here's a suggested
resolve.
Regards,
Tony
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@@ -743,12 -721,14 +743,15 @@@ static int __init omap2_init_devices(vo
* in alphabetical order so they're easier to sort through.
*/
omap_init_audio();
- omap_init_mcpdm();
- omap_init_dmic();
omap_init_camera();
+ omap_init_hdmi_audio();
omap_init_mbox();
- omap_init_mcspi();
+ /* If dtb is there, the devices will be created dynamically */
+ if (!of_have_populated_dt()) {
+ omap_init_dmic();
+ omap_init_mcpdm();
+ omap_init_mcspi();
+ }
omap_init_pmu();
omap_hdq_init();
omap_init_sti();
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 8/10] omap timer cleanup for v3.5 merge window
* Tony Lindgren t...@atomide.com [120510 11:49]:
The following changes since commit bfd17879866b36e95c58721da070d9f2ac7f8901:
Merge tag 'omap-devel-c-for-3.5' of
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into
devel-hwmod-data (2012-05-09 09:58:42 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-cleanup-timer-for-v3.5
for you to fetch changes up to 1fe97c8f6a1de67a5f56e029a818903d5bed8017:
ARM: OMAP: Make OMAP clocksource source selection using kernel param
(2012-05-09 10:07:05 -0700)
Timer changes to make it easier to support various SoCs
And this has a conflict for common headers:
--- a/arch/arm/mach-omap1/common.h
+++ b/arch/arm/mach-omap1/common.h
@@@ -57,16 -56,15 +57,22 @@@ void omap1_init_early(void)
void omap1_init_irq(void);
void omap1_restart(char, const char *);
+extern void __init omap_check_revision(void);
+
+extern void omap1_nand_cmd_ctl(struct mtd_info *mtd, int cmd,
+ unsigned int ctrl);
+
- extern struct sys_timer omap1_timer;
- extern bool omap_32k_timer_init(void);
-
+extern u32 omap_irq_flags;
-
+extern int ocpi_enable(void);
++
+ extern struct sys_timer omap1_timer;
+ #ifdef CONFIG_OMAP_32K_TIMER
+ extern int omap_32k_timer_init(void);
+ #else
+ static inline int __init omap_32k_timer_init(void)
+ {
+ return -ENODEV;
+ }
+ #endif
-extern void __init omap_init_consistent_dma_size(void);
#endif /* __ARCH_ARM_MACH_OMAP1_COMMON_H */
diff --cc arch/arm/plat-omap/include/plat/common.h
index a557b84,55c514b..d1cb6f5
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@@ -30,10 -30,8 +30,10 @@@
#include plat/i2c.h
#include plat/omap_hwmod.h
- extern int __init omap_init_clocksource_32k(void);
+ extern int __init omap_init_clocksource_32k(void __iomem *vbase);
+extern void __init omap_check_revision(void);
+
extern void omap_reserve(void);
extern int omap_dss_reset(struct omap_hwmod *);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 10/10] omap dss clean up for v3.5 merge window
* Tony Lindgren t...@atomide.com [120510 11:49]:
The following changes since commit d48b97b403d23f6df0b990cee652bdf9a52337a3:
Linux 3.4-rc6 (2012-05-06 15:07:32 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-cleanup-dss-for-v3.5
for you to fetch changes up to 21f787b356279798a002c68d53628755c84168de:
Merge branch 'for-l-o-3.5' of git://gitorious.org/linux-omap-dss2/linux
into cleanup-dss (2012-05-09 08:39:20 -0700)
Clean up for omap DSS board init in preparation for adding DT support.
Merging in this branch should avoid issues in linux-next for the
DSS changes. There's a small merge conflict here too:
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@@ -389,28 -420,16 +373,16 @@@ static struct omap_board_mux board_mux[
/* Display DVI */
#define PANDA_DVI_TFP410_POWER_DOWN_GPIO 0
- static int omap4_panda_enable_dvi(struct omap_dss_device *dssdev)
- {
- gpio_set_value(dssdev-reset_gpio, 1);
- return 0;
- }
-
- static void omap4_panda_disable_dvi(struct omap_dss_device *dssdev)
- {
- gpio_set_value(dssdev-reset_gpio, 0);
- }
-
/* Using generic display panel */
- static struct panel_dvi_platform_data omap4_dvi_panel = {
- .platform_enable= omap4_panda_enable_dvi,
- .platform_disable = omap4_panda_disable_dvi,
- .i2c_bus_num = 3,
+ static struct tfp410_platform_data omap4_dvi_panel = {
+ .i2c_bus_num= 3,
+ .power_down_gpio= PANDA_DVI_TFP410_POWER_DOWN_GPIO,
};
-struct omap_dss_device omap4_panda_dvi_device = {
+static struct omap_dss_device omap4_panda_dvi_device = {
.type = OMAP_DISPLAY_TYPE_DPI,
.name = dvi,
- .driver_name= dvi,
+ .driver_name= tfp410,
.data = omap4_dvi_panel,
.phy.dpi.data_lines = 24,
.reset_gpio = PANDA_DVI_TFP410_POWER_DOWN_GPIO,
@@@ -478,13 -485,8 +438,8 @@@ static struct omap_dss_board_info omap4
.default_device = omap4_panda_dvi_device,
};
-void __init omap4_panda_display_init(void)
+static void __init omap4_panda_display_init(void)
{
- int r;
-
- r = omap4_panda_dvi_init();
- if (r)
- pr_err(error initializing panda DVI\n);
omap_display_init(omap4_panda_dss_data);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Will,
On 05/10/2012 03:44 AM, Will Deacon wrote:
On Wed, May 09, 2012 at 10:45:08PM +0100, Jon Hunter wrote:
Hi All,
Hi Jon,
I have posted my latest series here [1] based upon that from Will [2]
which attempts to fix the EMU CD based upon the inputs from this thread.
It is working on my omap4460 panda. Hopefully Ming and/or Will can also
test. I know that Ming is out this week but said he can test next week.
Many thanks to you (+Kevin, Benoit, Paul and co) for persevering with this.
If I can get my hands on a Panda, I'll see if I can test something this
week. Any particular tests you want me to run to exercise the interaction
with PM?
May be Kevin and Paul have some suggestions, but I am not sure what PM modes
are currently supported for OMAP4 in the linux-omap master branch.
For my testing I have just been reading the PM_EMU_PWRSTST register which shows
the power state of the EMU power domain. It should read 3 when the power domain
is ON and 0 when it is off. I did something like the following (dumping all EMU
clock and power domain registers).
Cheers
Jon
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index b02aa81..41cb2fa 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -437,8 +437,25 @@ static struct omap_device_pm_latency omap_pmu_latency[] = {
static struct cti omap4_cti[2];
static struct platform_device *pmu_dev;
+static inline void dump_emu(char *s, int d)
+{
+ pr_info(%s-%d: CM_EMU_CLKSTCTRL = 0x%x\n, s, d,
+ __raw_readl(OMAP2_L4_IO_ADDRESS(0x4A307A00)));
+ pr_info(%s-%d: CM_EMU_DYNAMICDEP = 0x%x\n, s, d,
+ __raw_readl(OMAP2_L4_IO_ADDRESS(0x4A307A08)));
+ pr_info(%s-%d: CM_EMU_DEBUGSS_CLKCTRL = 0x%x\n, s, d,
+ __raw_readl(OMAP2_L4_IO_ADDRESS(0x4A307A20)));
+ pr_info(%s-%d: PM_EMU_PWRSTCTRL = 0x%x\n, s, d,
+ __raw_readl(OMAP2_L4_IO_ADDRESS(0x4A307900)));
+ pr_info(%s-%d: PM_EMU_PWRSTST = 0x%x\n, s, d,
+ __raw_readl(OMAP2_L4_IO_ADDRESS(0x4A307904)));
+ pr_info(%s-%d: RM_EMU_DEBUGSS_CONTEXT = 0x%x\n, s, d,
+ __raw_readl(OMAP2_L4_IO_ADDRESS(0x4A307924)));
+
+}
static void omap4_enable_cti(int irq)
{
+ dump_emu((char *)__func__, __LINE__);
pm_runtime_get_sync(pmu_dev-dev);
if (irq == OMAP44XX_IRQ_CTI0) {
/* configure CTI0 for pmu irq routing */
@@ -451,15 +468,18 @@ static void omap4_enable_cti(int irq)
cti_map_trigger(omap4_cti[1], 1, 6, 2);
cti_enable(omap4_cti[1]);
}
+ dump_emu((char *)__func__, __LINE__);
}
static void omap4_disable_cti(int irq)
{
+ dump_emu((char *)__func__, __LINE__);
if (irq == OMAP44XX_IRQ_CTI0)
cti_disable(omap4_cti[0]);
else if (irq == OMAP44XX_IRQ_CTI1)
cti_disable(omap4_cti[1]);
pm_runtime_put(pmu_dev-dev);
+ dump_emu((char *)__func__, __LINE__);
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 2/10] omap soc clean-up for v3.5 merge window
* Tony Lindgren t...@atomide.com [120510 11:47]: The following changes since commit 7a8bcf067d2b11964cb83ce3d753ac2d3ab9843c: Merge branch 'devel-hwmod' into cleanup (2012-05-08 10:17:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-cleanup-for-v3.5 for you to fetch changes up to 2c65e7440d56b3b285d1c95563b4dcce8e40dea3: GPMC: add ECC control definitions (2012-05-10 09:39:47 -0700) Clean up to make it easier to add support for new SoCs. Note that these have a merge dependency to omap-devel-hwmod-for-v3.5 branch for the Makefile changes. FYI, sets 2/10 and 3/10 have recent commit times as I had to fix a mismerge in the cleanup branch and drop one patch that was causing build errors for some cases. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
* Ivan Djelic ivan.dje...@parrot.com [120510 10:49]: On Thu, May 10, 2012 at 04:52:18PM +0100, Artem Bityutskiy wrote: On Thu, 2012-05-10 at 17:17 +0200, Ivan Djelic wrote: But in order to do so, I need the changes that Afzal has submitted (in particular [3]). Those changes (and as a consequence, my new patch) won't hit 3.5. So, when Afzal's patches are pushed, I'll submit a new, single MTD patch. But this is not going to happen this merge window as I understood, may be not even the next one. We need to make UBIFS happy sooner than that, I think. So may be we go forward with your original patch? I'm OK with this too, as the patches are ready and tested. The MTD patch is [2], it depends on [1] which has been pushed, then dropped by Tony. Do you need me to repost [2] ? Tony, sorry to backpedal on this: would you re-push patch [1], if indeed Afzal's patches are not going to be merged soon ? In the meantime, I can prepare a patch on top of Afzal's to have a smooth transition w.r.t BCH support. What do you think ? Yes this is OK with me as this removes the blocker for UBIFS work. For arch/arm/mach-omap2/gpmc.c, I have the following two patches queued: 27aeb3da5f97c55f61d92e3dbfb738762f76dc32 Merge tag 'omap-cleanup-for-v3.5' into tmp-merge 2c65e7440d56b3b285d1c95563b4dcce8e40dea3 GPMC: add ECC control definitions 355f8eee48134ba10ca81664ee90eeb240f5f928 ARM: OMAP2+: GPMC: resolve type-conversion warning from sparse Looks your patch applies to v3.4-rc6 and what I have queued without conflicts, so I suggest you merge both via MTD patches: Acked-by: Tony Lindgren t...@atomide.com [1] http://lists.infradead.org/pipermail/linux-mtd/2012-April/040965.html [2] http://lists.infradead.org/pipermail/linux-mtd/2012-April/041020.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Kevin, On 05/10/2012 09:12 AM, Kevin Hilman wrote: Jon Hunter jon-hun...@ti.com writes: [...] I have posted my latest series here [1] based upon that from Will [2] which attempts to fix the EMU CD based upon the inputs from this thread. It is working on my omap4460 panda. There are some differences between 4430 and 4460 here. Can you test on 4430 as well? No problem. I tested on an OMAP4430 ES2.2 EMU blaze this morning and it is also working. By the way, from an EMU power domain perspective the omap4430 and omap4460 behave the same, that is the PD is always set to OFF state and so will transition to OFF when ever the EMU CD idles. So same problem exists when using PMU and CTI. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP AM35xx: clock and hwmod data: fix AM35xx HSOTGUSB hwmod
On Thu, May 10, 2012 at 11:29:17AM -0600, Paul Walmsley wrote: Partially fix the hwmod data for the AM35xx USB OTG hwmod. This should resolve the following boot warning on AM35xx platforms: omap_hwmod: am35x_otg_hs: cannot be enabled for reset (3) While here, also fix the clkdev records, to avoid warnings about duplicate clock aliases. The hwmod is also connected to the wrong interconnect. It should be connected to the IPSS, not the L4 CORE. But that is left for a future fix, since it probably has a dependency on some hwmod core changes. Cc: Felipe Balbi ba...@ti.com Cc: Hema HK hem...@ti.com Cc: Mark A. Greer mgr...@animalcreek.com Signed-off-by: Paul Walmsley p...@pwsan.com Acked-by: Mark A. Greer mgr...@animalcreek.com (on an am3517evm) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: am33xx: Add AM335XEVM machine support
From: Afzal Mohammed af...@ti.com
This patch adds minimal support for AM335X machine init.
During last merge window, two separate patches supporting am33xx
machine init had been submitted,
1. Link to earlier Baseport patch submission (Legacy):
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg59325.html
2. Link to earlier DT based machine init support patch submission:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg61398.html
And both had got accepted at that time, but got missed during
merge window.
But now, since we have taken decision to make am33xx as a separate
class and not to follow omap3 family, these patches needs to changes
accordingly (only changes),
- Combine both the patches, since early init and timer init
used in board-generic.c file requires them.
- Remove dependency on AM3517EVM, and only use DT approach
for machine init.
- Change the config option (as changed recently)
CONFIG_SOC_OMAPAM33XX -- CONFIG_SOC_AM33XX
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/board-generic.c | 18 ++
arch/arm/mach-omap2/common.h|2 ++
arch/arm/mach-omap2/io.c| 10 ++
arch/arm/mach-omap2/irq.c |2 +-
arch/arm/mach-omap2/timer.c |5 +
5 files changed, 36 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 098d183..7dcd342 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -129,6 +129,24 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened
Device Tree))
MACHINE_END
#endif
+#ifdef CONFIG_SOC_AM33XX
+static const char *am33xx_boards_compat[] __initdata = {
+ ti,am33xx,
+ NULL,
+};
+
+DT_MACHINE_START(AM33XX_DT, Generic AM33XX (Flattened Device Tree))
+ .reserve= omap_reserve,
+ .map_io = am33xx_map_io,
+ .init_early = am33xx_init_early,
+ .init_irq = omap_init_irq,
+ .handle_irq = omap3_intc_handle_irq,
+ .init_machine = omap_generic_init,
+ .timer = omap3_am33xx_timer,
+ .dt_compat = am33xx_boards_compat,
+MACHINE_END
+#endif
+
#ifdef CONFIG_ARCH_OMAP4
static struct twl4030_platform_data sdp4430_twldata = {
.irq_base = TWL6030_IRQ_BASE,
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 267540b..aaab1d5 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -83,6 +83,7 @@ extern void omap2_init_common_infrastructure(void);
extern struct sys_timer omap2_timer;
extern struct sys_timer omap3_timer;
extern struct sys_timer omap3_secure_timer;
+extern struct sys_timer omap3_am33xx_timer;
extern struct sys_timer omap4_timer;
void omap2420_init_early(void);
@@ -93,6 +94,7 @@ void omap3630_init_early(void);
void omap3_init_early(void); /* Do not use this one */
void am35xx_init_early(void);
void ti81xx_init_early(void);
+void am33xx_init_early(void);
void omap4430_init_early(void);
void omap_prcm_restart(char, const char *);
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index bafa592..df4d119 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -438,6 +438,16 @@ void __init ti81xx_init_early(void)
}
#endif
+#ifdef CONFIG_SOC_AM33XX
+void __init am33xx_init_early(void)
+{
+ omap2_set_globals_am33xx();
+ omap3xxx_check_revision();
+ ti81xx_check_features();
+ omap_common_init_early();
+}
+#endif
+
#ifdef CONFIG_ARCH_OMAP4
void __init omap4430_init_early(void)
{
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 34496fe..3ce9312 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -278,7 +278,7 @@ int __init omap_intc_of_init(struct device_node *node,
return 0;
}
-#ifdef CONFIG_ARCH_OMAP3
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
static struct omap3_intc_regs intc_context[ARRAY_SIZE(irq_banks)];
void omap_intc_save_context(void)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index ecec873..61dbe41 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -332,6 +332,11 @@ OMAP_SYS_TIMER_INIT(3_secure, OMAP3_SECURE_TIMER,
OMAP3_CLKEV_SOURCE,
OMAP_SYS_TIMER(3_secure)
#endif
+#ifdef CONFIG_SOC_AM33XX
+OMAP_SYS_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE, 2, OMAP4_MPU_SOURCE)
+OMAP_SYS_TIMER(3_am33xx)
+#endif
+
#ifdef CONFIG_ARCH_OMAP4
#ifdef CONFIG_LOCAL_TIMERS
static DEFINE_TWD_LOCAL_TIMER(twd_local_timer,
--
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 V3 07/10] ARM: OMAP2+: SmartReflex: Use per-OPP data structure
Hi Jean,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of J, KEERTHY
Sent: Thursday, April 26, 2012 12:41 PM
To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
Hilman, Kevin; r...@sisk.pl; linux-ker...@vger.kernel.org; linux-
p...@lists.linux-foundation.org
Cc: Pihet-XID, Jean; J, KEERTHY; Paul Walmsley; Gopinath, Thara; Menon,
Nishanth
Subject: [PATCH V3 07/10] ARM: OMAP2+: SmartReflex: Use per-OPP data
structure
From: Jean Pihet j-pi...@ti.com
The SmartReflex driver incorrectly treats some per-OPP data as data
common to all OPPs (e.g., ERRMINLIMIT). Move this data into a per-OPP
data structure.
Furthermore, in order to make the SmartReflex implementation ready for
the move to drivers/, remove the dependency from the SR driver code
to the voltage layer by querying the data tables only from the SR device
init code.
Based on Paul's original code for the SmartReflex driver conversion.
Signed-off-by: Jean Pihet j-pi...@ti.com
Signed-off-by: J Keerthy j-keer...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Thara Gopinath th...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 38 +---
arch/arm/mach-omap2/sr_device.c | 36 +---
--
include/linux/power/smartreflex.h |8 +-
3 files changed, 54 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-
omap2/smartreflex.c
index acef08d..20075de 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -347,22 +347,23 @@ static void sr_v2_disable(struct omap_sr *sr)
sr_write_reg(sr, IRQSTATUS, IRQSTATUS_MCUDISABLEACKINT);
}
-static u32 sr_retrieve_nvalue(struct omap_sr *sr, u32 efuse_offs)
+static struct omap_sr_nvalue_table *sr_retrieve_nvalue_row(
+ struct omap_sr *sr, u32 efuse_offs)
{
int i;
if (!sr-nvalue_table) {
dev_warn(sr-pdev-dev, %s: Missing ntarget value table\n,
__func__);
- return 0;
+ return NULL;
}
for (i = 0; i sr-nvalue_count; i++) {
if (sr-nvalue_table[i].efuse_offs == efuse_offs)
- return sr-nvalue_table[i].nvalue;
+ return sr-nvalue_table[i];
}
- return 0;
+ return NULL;
}
/* Public Functions */
@@ -586,7 +587,7 @@ int sr_enable(struct voltagedomain *voltdm, unsigned
long volt)
{
struct omap_volt_data *volt_data;
struct omap_sr *sr = _sr_lookup(voltdm);
- u32 nvalue_reciprocal;
+ struct omap_sr_nvalue_table *nvalue_row;
int ret;
if (IS_ERR(sr)) {
@@ -602,16 +603,16 @@ int sr_enable(struct voltagedomain *voltdm, unsigned
long volt)
return PTR_ERR(volt_data);
}
- nvalue_reciprocal = sr_retrieve_nvalue(sr, volt_data-
sr_efuse_offs);
+ nvalue_row = sr_retrieve_nvalue_row(sr, volt_data-sr_efuse_offs);
- if (!nvalue_reciprocal) {
- dev_warn(sr-pdev-dev, %s: NVALUE = 0 at voltage %ld\n,
- __func__, volt);
+ if (!nvalue_row) {
+ dev_warn(sr-pdev-dev, %s: failure getting SR data for this
voltage %ld\n,
+ __func__, volt);
return -ENODATA;
}
/* errminlimit is opp dependent and hence linked to voltage */
- sr-err_minlimit = volt_data-sr_errminlimit;
+ sr-err_minlimit = nvalue_row-errminlimit;
pm_runtime_get_sync(sr-pdev-dev);
@@ -624,7 +625,7 @@ int sr_enable(struct voltagedomain *voltdm, unsigned
long volt)
if (ret)
return ret;
- sr_write_reg(sr, NVALUERECIPROCAL, nvalue_reciprocal);
+ sr_write_reg(sr, NVALUERECIPROCAL, nvalue_row-nvalue);
/* SRCONFIG - enable SR */
sr_modify_reg(sr, SRCONFIG, SRCONFIG_SRENABLE, SRCONFIG_SRENABLE);
@@ -872,7 +873,6 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
struct omap_sr_data *pdata = pdev-dev.platform_data;
struct resource *mem, *irq;
struct dentry *nvalue_dir;
- struct omap_volt_data *volt_data;
int i, ret = 0;
sr_info = kzalloc(sizeof(struct omap_sr), GFP_KERNEL);
@@ -990,12 +990,10 @@ static int __init omap_sr_probe(struct
platform_device *pdev)
goto err_debugfs;
}
- omap_voltage_get_volttable(sr_info-voltdm, volt_data);
- if (!volt_data) {
- dev_warn(pdev-dev, %s: %s: No Voltage table for the
- corresponding vdd. Cannot create debugfs
- entries for n-values\n,
- __func__, sr_info-name);
+ if (sr_info-nvalue_count == 0 || !sr_info-nvalue_table) {
+ dev_warn(pdev-dev, %s: %s: No Voltage table for the
Re: [PATCH v2] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
* Govindraj.R govindraj.r...@ti.com [120510 06:09]:
From: Govindraj.R govindraj.r...@ti.com
The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of
default uart pads) removed default uart pads that where getting populated
and which was making rx pin wakeup capable. If uart pads was used in
Nitpick.. this should say were used here ^^^
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -295,8 +353,7 @@ void __init omap_serial_board_init(struct
omap_uart_port_info *info)
bdata.pads = NULL;
bdata.pads_cnt = 0;
- if (cpu_is_omap44xx() || cpu_is_omap34xx())
- omap_serial_fill_default_pads(bdata);
+ omap_serial_check_wakeup(bdata, uart);
Should this section become:
if (!info) {
omap_serial_check_wakeup(bdata, uart);
omap_serial_init_port(bdata, NULL);
} else {
omap_serial_init_port(bdata, info[uart-num]);
}
As if you have bdata, then there should not be anything to mux,
right?
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 2/3] ARM: OMAP AM35xx: clock and hwmod data: fix UART4 data
On Thu, May 10, 2012 at 11:29:18AM -0600, Paul Walmsley wrote: Add missing terminators to the arrays of IRQ, DMA, and address space structure records in the AM35xx UART4 hwmod data. Without these terminators, the following warnings appear on boot: omap_uart.3: failed to claim resource 58 omap_device: omap_uart: build failed (-16) WARNING: at /home/paul/linux/arch/arm/mach-omap2/serial.c:375 omap_serial_init_port+0x198/0x284() Could not build omap_device for omap_uart: uart4. Also, AM35xx uart4_fck has an incorrect parent clock pointer. Fix it and clean up a whitespace issue. Fix some incorrectly-named macros related to AM35xx UART4. Cc: Kyle Manna kyle.ma...@fuel7.com Cc: Mark A. Greer mgr...@animalcreek.com Cc: Ranjith Lohithakshan ranji...@ti.com Signed-off-by: Paul Walmsley p...@pwsan.com Acked-by: Mark A. Greer mgr...@animalcreek.com (on an am3517evm) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: OMAP: AM35xx: fix UART4 softreset
On Thu, May 10, 2012 at 11:29:19AM -0600, Paul Walmsley wrote: During kernel init, the AM3505/AM3517 UART4 cannot complete its softreset: omap_hwmod: uart4: softreset failed (waited 1 usec) This also results in another warning later in the boot process: omap_hwmod: uart4: enabled state can only be entered from initialized, idle, or disabled state From empirical observation, the AM35xx UART4 IP block requires either uart1_fck or uart2_fck to be enabled while UART4 resets. Otherwise the reset will never complete. So this patch adds uart1_fck as an optional clock for UART4 and adds the appropriate hwmod flag to cause uart1_fck to be enabled during the reset process. (The choice of uart1_fck over uart2_fck was arbitrary.) Unfortunately this observation raises many questions. Is it necessary for uart1_fck or uart2_fck to be controlled with uart4_fck for the UART4 to work correctly? What exactly do the AM35xx UART4 clock tree and the related PRCM idle management FSMs look like? If anyone has the ability to answer these questions through empirical functional testing, or hardware information from the AM35xx designers, it would be greatly appreciated. Cc: Benoît Cousson b-cous...@ti.com Cc: Kyle Manna kyle.ma...@fuel7.com Cc: Mark A. Greer mgr...@animalcreek.com Cc: Ranjith Lohithakshan ranji...@ti.com Signed-off-by: Paul Walmsley p...@pwsan.com Acked-by: Mark A. Greer mgr...@animalcreek.com (on an am3517evm) Mark -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On 10 May 2012 22:30, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/09/2012 03:38 PM, Jassi Brar wrote:
One point is about 'qos' here something like bandwidth allocation.
If the dmac driver knew up-front the max possible clients that could be
active simultaneously, it could divide the bandwidth accordingly.
Again, the example of PL330 employing 2physical channels for better
service - LLI (you got it right), where even 1 physical channel would
also have served only not as reliably. I believe there would be
more such scenarios.
QoS seems like policy to me, whereas DT is more about describing the HW.
Is DT the correct place to describe QoS policy?
I guess you are talking more about deriving policy from the description
of HW, i.e. how many client described in DT.
Yeah, that's what I meant.
However, for some reason that seems dangerous to me; what if clients
can be instantiated some other way?
The other way could be hotplug ?
Anyway in those machines every channel would be populated
and dmac driver would always account for the all-ports-plugged case.
For a 1:1 mapping (or 1:n mapping in HW with static selection specified
in the DT) between DMA client and DMA controller, perhaps the controller
can indeed make QoS decisions based on which (how many) clients are
connected to it.
However, if a DMA client can be serviced by more than 1 DMA engine, and
the decision as to which DMA engine to use occurs at run-time by the DMA
driver core, rather than being statically configured in the DT, then the
DMA controller drivers cannot know ahead of time which will be used
I think the dmac driver would make use of the routing flexibility to sustain its
'qos', and not the other way around (decide qos based on which one of the
two dmacs would provide a channel to a client in future).
Anyways, so far only Samsung SoCs seem to have that flexibility/redundancy
and I have never had anyone asking for that runtime decision making.
The minor difference being, you use the {request-signal, phandle} pair
to find the right channel, I used only 'token'.
That's a pretty big difference, I think.
In your proposal, every token was globally unique (well, within the 1 DT
file). I'd rather not see any more global numbering schemes.
Probably my shallow experience, but globally unique, within a file sounds
like an oxymoron :)
I think arbitrary numerical tokens are a reasonable price to pay for the
robustness and simplicity they bring.
Now, DMA requests are signals /from/ a DMA client to a DMA controller
(send more data please, or pull more data please). Hence, I assert
that the phandle should refer to the DMA client, not the DMA controller.
OK, though we may just want to convey information about the h/w setup
from the s/w POV, rather than info to simulate the h/w ;)
For ex, the dma api and controller drivers don't really care about
the fact that the client's driver must set some bit to trigger operation,
whereas some simulator would need to care about that.
Anyways, I am OK with whatever works well and make things simpler.
Also note that, a client's dma specifier becomes perfectly general
and future-proof
client1: spdif {
dma_tx = 278
dma_rx = 723
};
otherwise the following representation
client1: spdif {
dma = sdma 2 1 sdma 3 2;
};
could break with some weird dma setups (IIANW Russell already finds
it wouldn't work for him).
To solve Russell's HW, we need some way of representing the mux directly
in DT irrespective of how the DMA controller or DMA client specify what
they're connected to. Anything else isn't representing the HW in DT.
Also, who knows how to control the mux? We need that to be fully
general, and so the mux itself really needs some kind of driver which
the DMA core or DMA controller can call into when the channel is
allocated in order to set up the mux. Right now, Russell's driver calls
in the a platform-/board-provided callback, but we should really
architect a generic driver framework for this.
Well, I doubt if there would ever be enough such platforms to warrant a
new generic framework. For now, I would leave that to be a matter between
the dmac driver and its DT node.
Similarly let every dmac, being unique, require DT data in it's own custom
format - I don't believe we can find a generic DT format for every kind of
dmac that does exist or would exist. (For ex, you found a way for RMK's
mux'ed req_lines, but what about assigning priorities to clients which is
possible with PL08X dmacs but not most others?)
So, I would strive only to make clients' dma specifier generic.
client0: i2s {
/* has 2 DMA request output signals: 0, 1 */
};
client1: spdif {
/* has 2 DMA request signals: 0, 1 */
};
Do we also need to somehow tag these signals for the client to
differentiate between TX and RX channel ?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a
[PATCH v4 0/2] Fixes in preparation for enabling Dsp in omap4
This set of patches provides the foundation for enabling OMAP4 Dsp as remote processor. The first patch is a generic fix for mailbox in mach-omap2. Without this patch, the irq for a mailbox instance other than the first one is not properly enabled. The second patch fixes the clock and irq names for the Tesla iommu in omap4 and enable it by default. History: === Changes from v3: - Changes in patch 1: Unrolling blocking_notifier_chain_register if omap_mbox_startup fails - Changes in patch 2: Adding Acked-by: Ohad Ben-Cohen o...@wizery.com Changes from v2: - Patch 3 is removed from this series. If http://marc.info/?l=linux-omapm=133601127627420w=2 is merged, it might be revisited. - Changes in patch 1: - Use omap_mbox_enable/disable_irq APIs instead of the internal ops. - Move notifier_block before enabling the mbox's irq to avoid possible race. - Changes in patch 2: - Commit message revisited to clarify the need of the change. Changes from v1: - Whitespaces and tabs were added when sending the patches by the mailer, due to wrong configuration. - No code changes. Juan Gutierrez (2): omap: mailbox: enable mailbox irq per instance omap4: iommu: fix irq and clock name for dsp-iommu arch/arm/mach-omap2/mailbox.c|2 -- arch/arm/mach-omap2/omap-iommu.c |6 ++ arch/arm/plat-omap/mailbox.c | 13 + 3 files changed, 11 insertions(+), 10 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] omap: mailbox: enable mailbox irq per instance
The machine-specific omap2_mbox_startup is called only once
to initialize the whole mbox module. Enabling mbox irq at
startup is only enabling the irq of the very first mailbox
instance created.
The enable_irq function should be called every time a
new mbox instance is created/opened, in the generic
platform mailbox layer.
Also, the notifier_block registration is called before
enabling the mbox's irq to avoid possible race of receiving
an interrupt without invoking the user's notifier callback.
Signed-off-by: Juan Gutierrez jgutier...@ti.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/mailbox.c |2 --
arch/arm/plat-omap/mailbox.c | 13 +
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 415a6f1..f727034 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -83,8 +83,6 @@ static int omap2_mbox_startup(struct omap_mbox *mbox)
l = mbox_read_reg(MAILBOX_REVISION);
pr_debug(omap mailbox rev %d.%d\n, (l 0xf0) 4, (l 0x0f));
- omap2_mbox_enable_irq(mbox, IRQ_RX);
-
return 0;
}
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index ad32621..5e13c38 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -282,6 +282,8 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
}
mbox-rxq = mq;
mq-mbox = mbox;
+
+ omap_mbox_enable_irq(mbox, IRQ_RX);
}
mutex_unlock(mbox_configured_lock);
return 0;
@@ -305,6 +307,7 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
mutex_lock(mbox_configured_lock);
if (!--mbox-use_count) {
+ omap_mbox_disable_irq(mbox, IRQ_RX);
free_irq(mbox-irq, mbox);
tasklet_kill(mbox-txq-tasklet);
flush_work_sync(mbox-rxq-work);
@@ -338,13 +341,15 @@ struct omap_mbox *omap_mbox_get(const char *name, struct
notifier_block *nb)
if (!mbox)
return ERR_PTR(-ENOENT);
- ret = omap_mbox_startup(mbox);
- if (ret)
- return ERR_PTR(-ENODEV);
-
if (nb)
blocking_notifier_chain_register(mbox-notifier, nb);
+ ret = omap_mbox_startup(mbox);
+ if (ret) {
+ blocking_notifier_chain_unregister(mbox-notifier, nb);
+ return ERR_PTR(-ENODEV);
+ }
+
return mbox;
}
EXPORT_SYMBOL(omap_mbox_get);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/2] omap4: iommu: fix irq and clock name for dsp-iommu
Irq and clock names were wrong for dsp iommu configuration
for omap4.
- Renamed tesla_ick to dsp_fck:
This is required because the new naming convention introduced
by: commit 0e43327 OMAP4 clock: Fix clock names and align
with hwmod names
- Renamed INT_44XX_DSP_MMU to OMAP44XX_IRQ_TESLA_MMU.
Naming convention adopted since: commit e927f8d omap4: Add
auto-generated irq and dma headers
- dsp-iommu is enabled by default.
Signed-off-by: Juan Gutierrez jgutier...@ti.com
Acked-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/omap-iommu.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index ac49384..1be8bcb 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -73,19 +73,17 @@ static struct iommu_device omap4_devices[] = {
.da_end = 0xF000,
},
},
-#if defined(CONFIG_MPU_TESLA_IOMMU)
{
.base = OMAP4_MMU2_BASE,
- .irq = INT_44XX_DSP_MMU,
+ .irq = OMAP44XX_IRQ_TESLA_MMU,
.pdata = {
.name = tesla,
.nr_tlb_entries = 32,
- .clk_name = tesla_ick,
+ .clk_name = dsp_fck,
.da_start = 0x0,
.da_end = 0xF000,
},
},
-#endif
};
#define NR_OMAP4_IOMMU_DEVICES ARRAY_SIZE(omap4_devices)
static struct platform_device *omap4_iommu_pdev[NR_OMAP4_IOMMU_DEVICES];
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 8/10] omap timer cleanup for v3.5 merge window
* Tony Lindgren t...@atomide.com [120510 11:55]:
* Tony Lindgren t...@atomide.com [120510 11:49]:
The following changes since commit bfd17879866b36e95c58721da070d9f2ac7f8901:
Merge tag 'omap-devel-c-for-3.5' of
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into
devel-hwmod-data (2012-05-09 09:58:42 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-cleanup-timer-for-v3.5
for you to fetch changes up to 1fe97c8f6a1de67a5f56e029a818903d5bed8017:
ARM: OMAP: Make OMAP clocksource source selection using kernel param
(2012-05-09 10:07:05 -0700)
Timer changes to make it easier to support various SoCs
And this has a conflict for common headers:
...
Also looks like this produces a merge conflict with linux-next
commit bd0493ea (ARM: 7413/1: move read_{boot,persistent}_clock to
the architecture level). To resolve, the line to add
register_persistent_clock(NULL, omap_read_persistent_clock);
needs to be resolved as below.
Regards,
Tony
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@@ -69,40 -69,55 +70,41 @@@ static void omap_read_persistent_clock(
*ts = *tsp;
}
-int __init omap_init_clocksource_32k(void)
+/**
+ * omap_init_clocksource_32k - setup and register counter 32k as a
+ * kernel clocksource
+ * @pbase: base addr of counter_32k module
+ * @size: size of counter_32k to map
+ *
+ * Returns 0 upon success or negative error code upon failure.
+ *
+ */
+int __init omap_init_clocksource_32k(void __iomem *vbase)
{
- static char err[] __initdata = KERN_ERR
- %s: can't register clocksource!\n;
-
- if (cpu_is_omap16xx() || cpu_class_is_omap2()) {
- u32 pbase;
- unsigned long size = SZ_4K;
- void __iomem *base;
- struct clk *sync_32k_ick;
-
- if (cpu_is_omap16xx()) {
- pbase = OMAP16XX_TIMER_32K_SYNCHRONIZED;
- size = SZ_1K;
- } else if (cpu_is_omap2420())
- pbase = OMAP2420_32KSYNCT_BASE + 0x10;
- else if (cpu_is_omap2430())
- pbase = OMAP2430_32KSYNCT_BASE + 0x10;
- else if (cpu_is_omap34xx())
- pbase = OMAP3430_32KSYNCT_BASE + 0x10;
- else if (cpu_is_omap44xx())
- pbase = OMAP4430_32KSYNCT_BASE + 0x10;
- else
- return -ENODEV;
-
- /* For this to work we must have a static mapping in io.c for
this area */
- base = ioremap(pbase, size);
- if (!base)
- return -ENODEV;
-
- sync_32k_ick = clk_get(NULL, omap_32ksync_ick);
- if (!IS_ERR(sync_32k_ick))
- clk_enable(sync_32k_ick);
-
- timer_32k_base = base;
-
- /*
- * 12 rough estimate from the calculations in
- * __clocksource_updatefreq_scale.
- */
- clocks_calc_mult_shift(persistent_mult, persistent_shift,
- 32768, NSEC_PER_SEC, 12);
-
- if (clocksource_mmio_init(base, 32k_counter, 32768, 250, 32,
-clocksource_mmio_readl_up))
- printk(err, 32k_counter);
-
- setup_sched_clock(omap_32k_read_sched_clock, 32, 32768);
- register_persistent_clock(NULL, omap_read_persistent_clock);
+ int ret;
+
+ /*
+ * 32k sync Counter register offset is at 0x10
+ */
+ sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF;
+
+ /*
+ * 12 rough estimate from the calculations in
+ * __clocksource_updatefreq_scale.
+ */
+ clocks_calc_mult_shift(persistent_mult, persistent_shift,
+ 32768, NSEC_PER_SEC, 12);
+
+ ret = clocksource_mmio_init(sync32k_cnt_reg, 32k_counter, 32768,
+ 250, 32, clocksource_mmio_readl_up);
+ if (ret) {
+ pr_err(32k_counter: can't register clocksource\n);
+ return ret;
}
+
+ setup_sched_clock(omap_32k_read_sched_clock, 32, 32768);
+ pr_info(OMAP clocksource: 32k_counter at 32768 Hz\n);
++ register_persistent_clock(NULL, omap_read_persistent_clock);
+
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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 1/2] omap: mailbox: enable mailbox irq per instance
On Thu, May 10, 2012 at 11:09 PM, Juan Gutierrez jgutier...@ti.com wrote: The machine-specific omap2_mbox_startup is called only once to initialize the whole mbox module. Enabling mbox irq at startup is only enabling the irq of the very first mailbox instance created. The enable_irq function should be called every time a new mbox instance is created/opened, in the generic platform mailbox layer. Also, the notifier_block registration is called before enabling the mbox's irq to avoid possible race of receiving an interrupt without invoking the user's notifier callback. Signed-off-by: Juan Gutierrez jgutier...@ti.com Acked-by: Ohad Ben-Cohen o...@wizery.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V7 0/3] ARM: OMAP: Make OMAP clocksource source selection runtime
Dnia czwartek, 3 maja 2012 13:28:58 Vaibhav Hiremath pisze: Current OMAP code supports couple of clocksource options based on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz) This patch series cleans up the existing 32k-sync timer implementation, movind SoC init code to respective files (mach-omap1/timer32k.c and mach-omap2/timer.c) and uses kernel parameter to override the default clocksource of counter_32k, also in order to support some OMAP based derivative SoCs like AM33XX which doesn't have 32K sync-timer hardware IP, adds hwmod lookup for omap2+ devices, and if lookup fails then fall back to gp-timer. if(use_gptimer_clksrc == true) gptimer clocksource init; else if (counter_32 init == false) /* Fallback to gptimer */ gptimer clocksource init(; With this, we should be able to support multi-omap boot including devices with/without 32k-sync timer. This patch-series has been boot tested on AM37xEVM platform, it would be helpful if somebody help me to validate it on OMAP1/2 platforms. The patches are also available at (based on linux-omap/master) - https://github.com/hvaibhav/am335x-linux 32ksync-timer-cleanup Tried to test this branch, merged into 3.4-rc6, and with my Amstrad Delta fixes applied, using my custom Amstrad Delta config, but initially failed because an unrelated issue rised to the surface: | LD .tmp_vmlinux1 | arch/arm/mach-omap1/built-in.o: In function `omap1_usb_init': | lcd_dma.c:(.init.text+0x1420): undefined reference to `ocpi_enable' | make: *** [.tmp_vmlinux1] Error 1 Apparently introduced with commit d3645d39ad0ed9f09535065676ea0ba114f93cdf, ARM: OMAP1: OHCI: use platform_data fn ptr to enable OCPI bus, looks like one or more symbols exported by the not linked in arch/arm/mach-omap1/ocpi.o may be missing for non-OMAP16xx configs. Otherwise, if configured with OMAP16xx selected, builds and seems to work correctly for me, to the extent possible to verify without physical access to the hardware. However, please note that the Amstrad Delta doesn't make use of the 32k timer, only mpu_timer. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
Hiremath, Vaibhav hvaib...@ti.com writes:
On Wed, May 09, 2012 at 04:08:09, Hilman, Kevin wrote:
Vaibhav Hiremath hvaib...@ti.com writes:
The function __omap2_set_globals() can be common across all
platforms/architectures, even in case of omap4, internally it
calls same set of functions as in __omap2_set_globals() function
(except for sdrc).
OK so far.
This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc,
so that we can reuse same function across omap2/3/4...
But what happens when a single kernel is built that has support for an
SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)?
As such Nothing...I looking into this direction while implementing.
In that case, sdrc.c file will be compiled in and execution will jump to
omap2_set_globals_sdrc(). But inside this function, we are already checking
whether the omap2_globals-sdrc and omap2_globals-sms for NULL and then use
it.
And function omap2_sdrc_init() is also depends on machine, so in case of
Am33xx, it won't get into sdrc execution at all. And in case of omap4, it
will.
Then why bother with the #ifdef at all?
If it already safe to call on all SoCs, just get rid of the #ifdef all
together.
In that case this new SOC_HAS_OMAP2_SDRC will be set, and
set_globals_sdrc() will be called even for the SoCs without SDRC.
So, rather than add a new Kconfig option for this, I would rather see
you using the existing runtime feature check for the SDRC: omap_has_sdrc()
There is NO difference between runtime feature check Vs this patch, refer to
the function implementation,
void __init omap2_set_globals_sdrc(struct omap_globals *omap2_globals)
{
if (omap2_globals-sdrc)
omap2_sdrc_base = omap2_globals-sdrc;
if (omap2_globals-sms)
omap2_sms_base = omap2_globals-sms;
}
The initialization happens after checking for NULL, so even if you execute it
or not, the variable are set to NULL in case of am33xx.
So I don't find any difference between runtime and this patch.
Except readability.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: irq: Increase no of supported interrupts to 128
Hiremath, Vaibhav hvaib...@ti.com writes: On Wed, May 09, 2012 at 00:09:34, Hilman, Kevin wrote: Vaibhav Hiremath hvaib...@ti.com writes: With addition to TI81XX, AM33XX family of devices, the number of interrupts supported has increased to 128, compared to 96. The current implementation for irq handling is hardcoded to use 96 interrupts (with 3 register-sets to handle), this patch cleanups the code, to increase maximum number of interrupts support to 128, with dynamic detection of no of registers required for handling all interrupts. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Afzal Mohammed af...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Paul Walmsley p...@pwsan.com --- Ideally, we should use dynamic allocation to allocate memory for registers/arrays, Yes. Thanks Kevin, I will put this activity in my TODO list. may be too much cleanup for this patch, There is no such thing as too much cleanup. ;) And the INTC is in need of it, IMO. Indeed it is in need of cleanup... so as of now restricting to minimal changes to fit devices like, am33xx/ti81xx. Then someone else will have to do the cleanup later. It would be greatly appreciated if you could do the necessary cleanup in order to cleanly add support for more SoCs. Yes, we probably should've insisted when support for TI81xx was added, but that one slipped in under the radar. Yeah, I understand. As I said I will put this activity in my TODO list. For starters, the notion of a banks this code is a rather messed up and needs a cleanup. A bank is supposed to be a group of 32 interrupts, and the INTC is made up of 3 (or 4) banks. However, the current code creates a single bank of 96 (or 128) interrupts. It also confuses what registers are part of the bank and what are global to the INTC. This confusion is both in init and in context save/restore. IMO, to clean this up, first the notion of banks needs to be fixed in that code there is a distinction between what acts on banks and what works on the whole INTC. Then, the init/alloc should be done dynamically based on the number of interrupts passed to omap_init_irq() Kevin, Let me finish up with am33xx baseport upstream activity which is currently going on at full swing, then next thing I will pick up is this code cleanup. I still feel, this is still a valid cleanup patch, and can be merged, as it is required/used when we do major cleanup. Well, Tony can make that decision. Personally, I think this patch continues to add confusion on top of an existing mess, and to me provides the proverbial straw that broke the camel's back. That being said, the INTC core is an obviously important and sensitive piece of code so needs to be handled with care. In case Tony decides to merge this patch and allow a future** cleanup, I'll provide some comments. Kevin ** since they rarely happen, we tend to not have too much faith in promises of mythical future cleanups. This is not because we don't trust you personally, but simply based on based experience. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V7 0/3] ARM: OMAP: Make OMAP clocksource source selection runtime
Hi Janusz, On Thu, 10 May 2012, Janusz Krzysztofik wrote: Tried to test this branch, merged into 3.4-rc6, and with my Amstrad Delta fixes applied, using my custom Amstrad Delta config, but initially failed because an unrelated issue rised to the surface: | LD .tmp_vmlinux1 | arch/arm/mach-omap1/built-in.o: In function `omap1_usb_init': | lcd_dma.c:(.init.text+0x1420): undefined reference to `ocpi_enable' | make: *** [.tmp_vmlinux1] Error 1 Apparently introduced with commit d3645d39ad0ed9f09535065676ea0ba114f93cdf, ARM: OMAP1: OHCI: use platform_data fn ptr to enable OCPI bus, looks like one or more symbols exported by the not linked in arch/arm/mach-omap1/ocpi.o may be missing for non-OMAP16xx configs. Thanks for the report, I'll send a fix. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: irq: Increase no of supported interrupts to 128
* Kevin Hilman khil...@ti.com [120510 14:53]: Hiremath, Vaibhav hvaib...@ti.com writes: Let me finish up with am33xx baseport upstream activity which is currently going on at full swing, then next thing I will pick up is this code cleanup. I still feel, this is still a valid cleanup patch, and can be merged, as it is required/used when we do major cleanup. Well, Tony can make that decision. Personally, I think this patch continues to add confusion on top of an existing mess, and to me provides the proverbial straw that broke the camel's back. That being said, the INTC core is an obviously important and sensitive piece of code so needs to be handled with care. In case Tony decides to merge this patch and allow a future** cleanup, I'll provide some comments. Heh I agree with Kevin here :) Tony ** since they rarely happen, we tend to not have too much faith in promises of mythical future cleanups. This is not because we don't trust you personally, but simply based on based experience. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
