Re: [PATCH] OMAP: omap_device: use pdev as parameter to get rt_va
Hi Omar,
On 12/11/2010 12:45 AM, Ramirez Luna, Omar wrote:
Make the parameter received by omap_device_get_mpu_rt_va
consistent with the functions meant to be called by drivers.
Also move its header declaration to appear in the set of
functions to be used by drivers, as per the comment there.
Please note that even if Paul submitted this API upon request from
Santosh, we do not want driver to us it most of the time.
All drivers should us the generic Linux way to get physical mem resource
and then ioremap it.
I assume that if you want to update this API, you are probably already
using it.
Why cannot you use the generic way?
Regards,
Benoit
Signed-off-by: Omar Ramirez Lunaomar.rami...@ti.com
Acked-by: Kevin Hilmankhil...@deeprootsystems.com
---
arch/arm/plat-omap/include/plat/omap_device.h |3 +--
arch/arm/plat-omap/omap_device.c |8 ++--
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 28e2d1a..1877c1a 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -80,6 +80,7 @@ struct omap_device {
int omap_device_enable(struct platform_device *pdev);
int omap_device_idle(struct platform_device *pdev);
int omap_device_shutdown(struct platform_device *pdev);
+void __iomem *omap_device_get_rt_va(struct platform_device *pdev);
/* Core code interface */
@@ -101,8 +102,6 @@ struct omap_device *omap_device_build_ss(const char
*pdev_name, int pdev_id,
int omap_device_register(struct omap_device *od);
int omap_early_device_register(struct omap_device *od);
-void __iomem *omap_device_get_rt_va(struct omap_device *od);
-
/* OMAP PM interface */
int omap_device_align_pm_lat(struct platform_device *pdev,
u32 new_wakeup_lat_limit);
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index abe933c..9d11195 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -681,7 +681,7 @@ struct powerdomain *omap_device_get_pwrdm(struct
omap_device *od)
/**
* omap_device_get_mpu_rt_va - return the MPU's virtual addr for the hwmod
base
- * @od: struct omap_device *
+ * @pdev: struct platform_device *
*
* Return the MPU's virtual address for the base of the hwmod, from
* the ioremap() that the hwmod code does. Only valid if there is one
@@ -690,8 +690,12 @@ struct powerdomain *omap_device_get_pwrdm(struct
omap_device *od)
* otherwise, passes along the return value from
* omap_hwmod_get_mpu_rt_va().
*/
-void __iomem *omap_device_get_rt_va(struct omap_device *od)
+void __iomem *omap_device_get_rt_va(struct platform_device *pdev)
{
+ struct omap_device *od;
+
+ od = _find_by_pdev(pdev);
+
if (od-hwmods_cnt != 1)
return NULL;
--
To unsubscribe from this list: send the line unsubscribe 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: Problem trying to measure OMAP35x core temperature
On Sat, Dec 11, 2010 at 10:14 PM, Peter Barada pet...@logicpd.com wrote:
I'm trying to add code to a 2.6.32 kernel to extract the OMAP core
temperature for thermal testing, and section 7.4.6 of the OMAP3 TRM
(spug98g.pdf) explains the CONTROL_TEMP_SENSOR register.
I have not look at it further but there is some code at
http://thread.gmane.org/gmane.linux.ports.arm.omap/8424/focus=8514.
Hope this helps!
Jean
I've added the following code:
static void omap3logic_fetch_temp(char *temp_buf)
{
int temp_val;
unsigned int temp;
static short temp_table[] = {
-400, -400, -400, -400, -400,
-400, -389, -375, -361, -333, /* 0-9 */
-318, -304, -290, -275, -261,
-247, -233, -219, -205, -191, /* 10-19 */
-177, -163, -149, -134, -120,
-106, -92, -78, -64, -50, /* 20-29 */
-35, -21, -7, +8, +23,
+37, +51, +66, +80, +94, /* 30-39 */
+108, +123, +137, +151, +165,
+179, +194, +208, +222, +236, /* 40-49 */
+251, +265, +279, +293, +307,
+321, +335, +349, +364, +378, /* 50-59 */
+392, +406, +420, +424, +449,
+463, +447, +491, +505, +519, /* 60-69 */
+533, +546, +560, +574, +588,
+602, +616, +630, +644, +657, /* 70-79 */
+671, +685, +699, +713, +727,
+741, +755, +769, +783, +797, /* 80-89 */
+811, +823, +838, +852, +865,
+879, +893, +906, +920, +934, /* 90-99 */
+947, +961, +975, +989, +1002,
+1016, +1030, +1043, +1057, +1071, /* 100-109 */
+1085, +1098, +1112, +1126, +1140,
+1153, +1167, +1181, +1194, +1208, /* 110-119 */
+1222, +1235, +1249, +1250, +1250,
+1250, +1250, +1250, +1250, /* 120-128 */
};
temp = omap_ctrl_readl(OMAP343X_CONTROL_TEMP_SENSOR);
temp_val = (temp_table[temp0x7f] + temp_table[(temp0x7f)+1]) / 2;
sprintf(temp_buf, %d.%1d (%02x), temp_val/10, ((unsigned
int)temp_val)%10, temp);
}
static ssize_t
omap3logic_show_temp(struct class *class, char *buf)
{
ssize_t retval;
char temp[128];
omap3logic_fetch_temp(temp);
retval = sprintf(buf, %s\n, temp);
return retval;
}
static struct class_attribute temp_attr =
__ATTR(temp, S_IRUGO, omap3logic_show_temp, NULL);
static struct class *omap3logic_temp_class;
void omap3logic_temp_init(void)
{
int rc;
omap3logic_temp_class = class_create(THIS_MODULE, temp);
if (IS_ERR(omap3logic_temp_class)) {
printk(KERN_ERR %s: couldn't create temp class\n, __FUNCTION__);
return;
}
rc = class_create_file(omap3logic_temp_class, temp_attr);
if (unlikely(rc)) {
printk(KERN_ERR %s: couldn't create temp class file\n,
__FUNCTION__);
return;
}
/* Set CONTCONV and SOC to start continuous temperature measurements */
omap_ctrl_writel(0x300, OMAP343X_CONTROL_TEMP_SENSOR);
}
But when I read the register back, I see only a fixed temperature value,
even if I fire up some video demos to crank up the load. If I reboot I'll
see the temperature jump up, but then it stays constant whether I
increase/decrease the CPU load.
Any ideas why this isn't working?
Thanks in advance!
--
Peter Barada
pet...@logicpd.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
--
To unsubscribe from this list: send the line unsubscribe 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 5/5] OMAP: mailbox: add omap_device latency information
On 12/11/2010 4:25 PM, Ramirez Luna, Omar wrote: On Fri, Dec 10, 2010 at 7:51 PM, Omar Ramirez Lunaomar.rami...@ti.com wrote: From: Felipe Contrerasfelipe.contre...@gmail.com So that we can enable the main clock. This should be: Subject: OMAP: mailbox: use runtime pm for clk and sysc handling Use runtime pm APIs to enable/disable mailbox clocks and to configure SYSCONFIG registers. And if someone agrees, device_latency can be merged with the previous patch for device_build. I'll wait for comments and resubmit. Yes, you're right, the device latency has nothing to do in that patch. It should be in the previous patch: [PATCH v3 4/5] OMAP: mailbox: build device using omap_device/omap_hwmod. regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] omap3: igepv2: Don't call gpio_set_value right after gpio_direction_output
2010/12/12 Laurent Pinchart laurent.pinch...@ideasonboard.com:
gpio_direction_output() has a value argument, there's no need to call
gpio_set_value() explicitly right after.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
arch/arm/mach-omap2/board-igep0020.c | 20
1 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 5e035a5..20b88c1 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -342,24 +342,21 @@ static void __init igep2_leds_init(void)
static inline void igep2_leds_init(void)
{
if ((gpio_request(IGEP2_GPIO_LED0_RED, gpio-led:red:d0) == 0)
- (gpio_direction_output(IGEP2_GPIO_LED0_RED, 1) == 0)) {
+ (gpio_direction_output(IGEP2_GPIO_LED0_RED, 0) == 0))
gpio_export(IGEP2_GPIO_LED0_RED, 0);
- gpio_set_value(IGEP2_GPIO_LED0_RED, 0);
- } else
+ else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED0_RED\n);
if ((gpio_request(IGEP2_GPIO_LED0_GREEN, gpio-led:green:d0) == 0)
- (gpio_direction_output(IGEP2_GPIO_LED0_GREEN, 1) == 0)) {
+ (gpio_direction_output(IGEP2_GPIO_LED0_GREEN, 0) == 0))
gpio_export(IGEP2_GPIO_LED0_GREEN, 0);
- gpio_set_value(IGEP2_GPIO_LED0_GREEN, 0);
- } else
+ else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED0_GREEN\n);
if ((gpio_request(IGEP2_GPIO_LED1_RED, gpio-led:red:d1) == 0)
- (gpio_direction_output(IGEP2_GPIO_LED1_RED, 1) == 0)) {
+ (gpio_direction_output(IGEP2_GPIO_LED1_RED, 0) == 0))
gpio_export(IGEP2_GPIO_LED1_RED, 0);
- gpio_set_value(IGEP2_GPIO_LED1_RED, 0);
- } else
+ else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED1_RED\n);
}
@@ -397,10 +394,9 @@ static int igep2_twl_gpio_setup(struct device *dev,
/* TWL4030_GPIO_MAX + 1 == ledB (out, active low LED) */
#if !defined(CONFIG_LEDS_GPIO) !defined(CONFIG_LEDS_GPIO_MODULE)
if ((gpio_request(gpio+TWL4030_GPIO_MAX+1, gpio-led:green:d1) == 0)
- (gpio_direction_output(gpio + TWL4030_GPIO_MAX + 1, 1) == 0)) {
+ (gpio_direction_output(gpio + TWL4030_GPIO_MAX + 1, 0) == 0))
gpio_export(gpio + TWL4030_GPIO_MAX + 1, 0);
- gpio_set_value(gpio + TWL4030_GPIO_MAX + 1, 0);
- } else
+ else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED1_GREEN\n);
#else
igep2_gpio_leds[3].gpio = gpio + TWL4030_GPIO_MAX + 1;
--
1.7.2.2
Acked-by: Enric Balletbo i Serra eballe...@gmail.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] OMAP1: clock_data: use runtime cpu / machine checks
Hello Janusz, Cory, On Sat, 11 Dec 2010, Janusz Krzysztofik wrote: Otherwise multi-omap1 configurations may set wrong clock speed. Created and tested against l-o master on Amstrad Delta. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl Thanks, this is a significant step forward in building a good omap1_defconfig. Cory, do you mind testing this out? If it works for you also, let's plan to take this for 2.6.38. However: Tested with omap1_defconfig after dropping CONFIG_OMAP_CLOCKS_SET_BY_BOOTLOADER=y and those of 12MHz xtal based clock speeds which are too high for my board. This is also key. Until the board files can somehow indicate which rate sets are usable for their boards at runtime -- which is what the CONFIG_OMAP_ARM* KConfig options used to do at KConfig-time -- I don't think omap1_defconfig is possible yet. Volunteers to tackle that project are gladly welcome :-) - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the trivial tree with the omap tree
On Mon, 13 Dec 2010, Stephen Rothwell wrote:
Hi Jiri,
Today's linux-next merge of the trivial tree got a conflict in
arch/arm/mach-omap2/pm24xx.c between commit
e83df17f178360a8e7874441bca04a710c869e42 (OMAP2+: PM/serial: fix console
semaphore acquire during suspend) from the omap tree and commit
2f55ac072f5344519348c0c94b3d2f4cca46847b (suspend: constify
platform_suspend_ops) from the trivial tree.
I fixed it up (see below) and can carry the fix as necessary.
Thank you Stephen. If you could carry this fixup patch, then it seems best
option for me. This conflict is trivial enough to be resolved later during
merge.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-omap2/pm24xx.c
index aaeea49,aa9764e..000
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@@ -354,13 -326,7 +354,13 @@@ static void omap2_pm_finish(void
enable_hlt();
}
+static void omap2_pm_end(void)
+{
+suspend_state = PM_SUSPEND_ON;
+}
+
- static struct platform_suspend_ops omap_pm_ops = {
+ static const struct platform_suspend_ops omap_pm_ops = {
+.begin = omap2_pm_begin,
.prepare= omap2_pm_prepare,
.enter = omap2_pm_enter,
.finish = omap2_pm_finish,
--
Jiri Kosina
SUSE Labs, Novell Inc.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
musb (omap3) as host fails with reconnecting devices
Hello, I've tried to use a BT-dongle attached via a Mini-A-Std A cable to the OTG-port of a BeagleBoard Rev C4 (OMAP3530). That devices needs a firmware and disconnects/reconnects with a new pid after it has received the firmware (ath3k). I'm currently trying it with a kernel v2.6.37-rc5. Using the device on an ehci-port it looks like that (which is as it should be): Dec 11 09:16:04 beagle kernel: [ 101.033325] usb 1-2.1: new full speed USB device using ehci-omap and address 4 Dec 11 09:16:04 beagle kernel: [ 101.150970] usb 1-2.1: New USB device found, idVendor=0cf3, idProduct=3000 Dec 11 09:16:04 beagle kernel: [ 101.151000] usb 1-2.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Dec 11 09:16:04 beagle kernel: [ 101.287048] Bluetooth: Atheros AR30xx firmware driver ver 1.0 Dec 11 09:16:04 beagle kernel: [ 101.615844] usbcore: registered new interface driver ath3k Dec 11 09:16:04 beagle kernel: [ 101.814056] usb 1-2.1: USB disconnect, address 4 Dec 11 09:16:06 beagle kernel: [ 103.080200] usb 1-2.1: new full speed USB device using ehci-omap and address 5 Dec 11 09:16:06 beagle kernel: [ 103.198242] usb 1-2.1: New USB device found, idVendor=0cf3, idProduct=3005 Dec 11 09:16:06 beagle kernel: [ 103.198242] usb 1-2.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Dec 11 09:16:06 beagle kernel: [ 103.324493] Bluetooth: Core ver 2.15 Because I haven't found another way to get musb_hdrc into host mode, I'm doing the following: modprobe g_zero echo host /sys/devices/platform/musb_hdrc/mode I've read somewhere thats because there is no id-change-irq available on omap4 but I still wonder why the mini-a-cable is not recognized as such e.g. on startup (it was connected all the time). Now the following happens when the driver (ath3k) will upload the new firmware to the device: Dec 11 10:16:29 beagle kernel: [ 147.498809] musb_giveback 325: complete cd04d500 usb_api_blocking_completion+0x0/0x14 (0), dev2 ep2out, 4096/4096 Dec 11 10:16:29 beagle kernel: [ 147.498962] musb_schedule 1885: qh cbcb6540 periodic slot 10 Dec 11 10:16:29 beagle kernel: [ 147.498992] musb_start_urb 252: qh cbcb6540 urb cd04d500 dev2 ep2out-bulk, hw_ep 10, cbd55000/1024 Dec 11 10:16:29 beagle kernel: [ 147.498992] musb_ep_program 706: -- hw10 urb cd04d500 spd2 dev2 ep2out h_addr00 h_port00 bytes 1024 Dec 11 10:16:29 beagle kernel: [ 147.499023] dma_channel_program 167: ep10-Tx pkt_sz 64, dma_addr 0x8bd55000 length 1024, mode 1 Dec 11 10:16:29 beagle kernel: [ 147.499053] configure_channel 130: ceb60e18, pkt_sz 64, addr 0x8bd55000, len 1024, mode 1 Dec 11 10:16:29 beagle kernel: [ 147.499053] musb_start_urb 290: Start TX10 dma Dec 11 10:16:29 beagle kernel: [ 147.500030] dma_controller_irq 316: ch ceb60e18, 0x8bd55000 - 0x8bd55400 (1024 / 1024) = complete Dec 11 10:16:29 beagle kernel: [ 147.500030] musb_g_tx 476: == ep10in, txcsr b400 This is wrong and should be musb_t_tx (I assume it got changed to musb_g_tx because the device disconnects after it has received the new firmware). Dec 11 10:16:29 beagle kernel: [ 147.500061] dma_controller_irq 357: !! IRQ DONE !! Dec 11 10:16:29 beagle kernel: [ 147.500091] musb_interrupt 1596: ** IRQ peripheral usb0028 tx rx Dec 11 10:16:29 beagle kernel: [ 147.500091] musb_stage0_irq 462: == Power=e0, DevCtl=19, int_usb=0x28 Dec 11 10:16:29 beagle kernel: [ 147.500122] musb_stage0_irq 784: DISCONNECT (a_host) as Host, devctl 19 Dec 11 10:16:29 beagle kernel: [ 147.500152] musb_platform_try_idle 130: a_wait_bcon inactive, for idle timer for 1101 ms Dec 11 10:16:29 beagle kernel: [ 147.500244] musb_hub_control 356: port status 00010100 Dec 11 10:16:29 beagle kernel: [ 147.500274] musb_hub_control 290: clear feature 16 Dec 11 10:16:29 beagle kernel: [ 147.500305] usb 2-1: USB disconnect, address 2 Dec 11 10:16:32 beagle kernel: [ 150.493621] musb_urb_dequeue 2156: urb=cd04d500, dev2 ep2out Dec 11 10:16:32 beagle kernel: [ 150.493652] musb_cleanup_urb 2109: abort TX10 DMA for urb cd04d500 -- 0 Dec 11 10:16:32 beagle kernel: [ 150.493682] musb_giveback 325: complete cd04d500 usb_api_blocking_completion+0x0/0x14 (0), dev2 ep2out, 1024/1024 Dec 11 10:16:32 beagle kernel: [ 150.493713] ath3k_load_firmware: Error in firmware loading err = -110,len = 1024, size = 1024 Dec 11 10:16:32 beagle kernel: [ 150.493835] ath3k: probe of 2-1:1.0 failed with error -5 Dec 11 10:16:32 beagle kernel: [ 150.493988] usbcore: registered new interface driver ath3k Dec 11 10:16:32 beagle kernel: [ 150.494964] musb_hub_control 356: port status 0100 Dec 11 10:16:32 beagle kernel: [ 150.532531] musb_hub_control 356: port status 0100 Dec 11 10:16:32 beagle kernel: [ 150.571563] musb_hub_control 356: port status 0100 Dec 11 10:16:32 beagle kernel: [ 150.610626] musb_hub_control 356:
Re: How to change freq of mmc2_clk to 48Mhz for OMAP35xx
Hello Elvis On Fri, 10 Dec 2010, Elvis Dowson wrote: On Dec 9, 2010, at 12:43 AM, Andy Shevchenko wrote: On Wed, Dec 8, 2010 at 10:36 PM, Paul Walmsley p...@pwsan.com wrote: Anyway, if you want to try changing it from the kernel side, you'll need code like this in the MMC driver or OMAP integration code (off the top of my head, untested): Please let me know if this doesn't work. First let me say, my earlier code that I sent you is not going to work. This is because hsmmc2_fclk is not directly rate-controllable. So using the kernel clock framework to tweak that won't work. However... In my u-boot-2010.03 board file (or with u-boot-2009.11 patched to incorporate the mmc_set_dev() method) I added the following lines of code. - mmc_set_dev(2) select the MMC2 controller. - mmc_clock_config attempts to use a clock divider value of 2, and this method implements the logic outlined in Section 22.5.2.7.2 of the OMAP35x TRM Rev D ... This is having no effect, and the output clock from the bootloader stage is still at 96MHz. How can I change the MMC CLK output to 48MHz using either the boot loader or the kernel? Let's focus on the kernel. What kernel are you running? If you're not running a mainline kernel, I probably can't help you. For example, if you're using a TI kernel or Google kernel, you should talk to/E-mail them for support, unless someone else on this list happens to be able to help you. Also, please tell us which board are you using. For the moment I will assume you are using a recent mainline kernel. drivers/mmc/host/omap_hsmmc.c is the applicable driver file. Please take a look at omap_hsmmc_set_ios() and omap_hsmmc_context_restore() in that file. There is some code there that attempts to program the internal MMC divisor appropriately. If you add some debugging printk()s in there, you might get some insight into what it's writing to that register. Could you do this and tell us what the code is writing to the SYSCTL register? - 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/RFC 2/2] OMAP: PM: implement context loss count APIs
Hello Vishwa, On Fri, 10 Dec 2010, Vishwanath Sripathy wrote: + count = omap_device_get_context_loss_count(pdev); + pr_debug(OMAP PM: context loss count for dev %s = %d\n, +dev_name(dev), count); Shouldn't this implementation be part of omap-pm.c where all the OMAP PM functions are to be implemented? I thought omap-pm-noop.c should have dummy implementation. In general, yes. But we also want the code in omap-pm-noop.c not to cause additional breakage. Unlike most of the other functions in this file, if the context loss count function doesn't do something minimally useful, then the system is going to break badly. You've probably seen this thread: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg40079.html (By the way, the reason why I think we shouldn't use the approach described in http://www.mail-archive.com/linux-omap@vger.kernel.org/msg40101.html is because I suspect it is going to seriously damage retention idle performance. For example, the HSMMC driver resets its entire IP block in its context restore function...) But to confirm your general point, yes, in general, further functional development of the OMAP PM code should take place outside the no-op file. Hopefully, at some point, we'll be able to drop the no-op file. Once there is a useful replacement, we should be able to switch to it as a default. - 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] arm: omap: update mach-types for rm680
Temporary hack to update mach-types for rm680; without this the master branch of linux-omap will be broken for omap2plus_defconfig builds. Nyet-Signed-off-by: Anand Gadiyar gadi...@ti.com --- Tony, Not sure how this is handled normally. Do you sync up mach-types with Russell's tree, or locally apply a patch like the one below? - Anand arch/arm/tools/mach-types |1 + 1 file changed, 1 insertion(+) Index: ehci/arch/arm/tools/mach-types === --- ehci.orig/arch/arm/tools/mach-types +++ ehci/arch/arm/tools/mach-types @@ -3044,3 +3044,4 @@ harvest_desotoMACH_HARVEST_DESOTO HARV msm8x60_qrdc MACH_MSM8X60_QRDC MSM8X60_QRDC3060 spear900 MACH_SPEAR900 SPEAR9003061 pcontrol_g20 MACH_PCONTROL_G20 PCONTROL_G203062 +nokia_rm680MACH_NOKIA_RM680NOKIA_RM680 3220 -- To unsubscribe from this list: send the line unsubscribe 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: linux-next: manual merge of the trivial tree with the omap tree
Hi Jiri, On Mon, 13 Dec 2010 11:01:59 +0100 (CET) Jiri Kosina jkos...@suse.cz wrote: Thank you Stephen. If you could carry this fixup patch, then it seems best option for me. This conflict is trivial enough to be resolved later during merge. Yep, no worries. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpBYDBs8Np3d.pgp Description: PGP signature
RE: [PATCH v2 01/17] OMAP2420: hwmod data: add DSS DISPC RFBI VENC
Kevin, Tony, Gentle reminder. Is there anything else pending on me to get these first 4 patches pulled in l-o? Regards, Senthil -Original Message- From: Guruswamy, Senthilvadivu Sent: Monday, December 06, 2010 1:14 PM To: 't...@atomide.com'; Cousson, Benoit Cc: Guruswamy, Senthilvadivu; khil...@deeprootsystems.com; tomi.valkei...@nokia.com; p...@pwsan.com; Hiremath, Vaibhav; linux- o...@vger.kernel.org Subject: RE: [PATCH v2 01/17] OMAP2420: hwmod data: add DSS DISPC RFBI VENC Tony, -Original Message- From: Guruswamy, Senthilvadivu Sent: Monday, November 29, 2010 5:21 PM To: khil...@deeprootsystems.com; tomi.valkei...@nokia.com; p...@pwsan.com; Hiremath, Vaibhav; linux-omap@vger.kernel.org Cc: Guruswamy, Senthilvadivu Subject: [PATCH v2 01/17] OMAP2420: hwmod data: add DSS DISPC RFBI VENC From: Senthilvadivu Guruswamy svad...@ti.com Database generated for OMAP2420 Display Sub System. Since dss is also considered as an IP as dispc,rfbi, name it as dss_dss. Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com Acked-by: Benoit Cousson b-cous...@ti.com --- The first 4 patches are reviewed by Acked by Benoit. These patches are also tested on 2420-N800, 2430SDP, 3430SDP as mentioned in cover letter. Could you please let me know what is needed further to push this changes to l-o. Regards, Senthil arch/arm/mach-omap2/omap_hwmod_2420_data.c | 283 -- To unsubscribe from this list: send the line unsubscribe 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] omap2+: Initialize omap_irq_base for entry-macro.Sfrom platform code
Hi Tony,
-Original Message-
From: linux-arm-kernel-boun...@lists.infradead.org
[mailto:linux-arm-kernel-boun...@lists.infradead.org] On Behalf
Of Tony Lindgren
Sent: Wednesday, December 08, 2010 7:19 AM
To: Nicolas Pitre
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: [PATCH 3/3] omap2+: Initialize omap_irq_base for
entry-macro.Sfrom platform code
This way we can use the generic omap SoC detection code instead.
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/include/mach/entry-macro.S
b/arch/arm/mach-omap2/include/mach/entry-macro.S
index 06e64e1..6032941 100644
--- a/arch/arm/mach-omap2/include/mach/entry-macro.S
+++ b/arch/arm/mach-omap2/include/mach/entry-macro.S
@@ -38,41 +38,27 @@
*/
#ifdef MULTI_OMAP2
+
+/*
+ * We use __glue to avoid errors with multiple definitions of
+ * .globl omap_irq_base as it's included from entry-armv.S but not
+ * from entry-common.S.
+ */
+#ifdef __glue
.pushsection .data
-omap_irq_base: .word 0
+ .globl omap_irq_base
+omap_irq_base:
+ .word 0
.popsection
+#endif
- /* Configure the interrupt base on the first interrupt */
+ /*
+ * Configure the interrupt base on the first interrupt.
+ * See also omap_irq_base_init for setting omap_irq_base.
+ */
.macro get_irqnr_preamble, base, tmp
-9:
ldr \base, =omap_irq_base @ irq base address
ldr \base, [\base, #0] @ irq base value
- cmp \base, #0 @ already configured?
- bne 9997f @ nothing to do
-
- mrc p15, 0, \tmp, c0, c0, 0 @ get processor revision
- and \tmp, \tmp, #0x000f @ only check architecture
- cmp \tmp, #0x0007 @ is v6?
- beq 2400f @ found v6 so it's
omap24xx
- mrc p15, 0, \tmp, c0, c0, 0 @ get processor revision
- and \tmp, \tmp, #0x00f0 @ check cortex 8 or 9
- cmp \tmp, #0x0080 @ cortex A-8?
- beq 3400f @ found A-8 so it's
omap34xx
- cmp \tmp, #0x0090 @ cortex A-9?
- beq 4400f @ found A-9 so it's
omap44xx
-2400:ldr \base, =OMAP2_IRQ_BASE
- ldr \tmp, =omap_irq_base
- str \base, [\tmp, #0]
- b 9b
-3400:ldr \base, =OMAP3_IRQ_BASE
- ldr \tmp, =omap_irq_base
- str \base, [\tmp, #0]
- b 9b
-4400:ldr \base, =OMAP4_IRQ_BASE
- ldr \tmp, =omap_irq_base
- str \base, [\tmp, #0]
- b 9b
-9997:
.endm
/* Check the pending interrupts. Note that base already
set */
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 40562dd..3d18349 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -46,6 +46,7 @@
#include clockdomains.h
#include plat/omap_hwmod.h
+#include plat/multi.h
/*
* The machine specific code may provide the extra mapping besides the
@@ -311,6 +312,25 @@ static int __init _omap2_init_reprogram_sdrc(void)
return v;
}
+/*
+ * Initialize asm_irq_base for entry-macro.S
+ */
+static inline void omap_irq_base_init(void)
+{
+ extern void __iomem *omap_irq_base;
+
+#ifdef MULTI_OMAP2
+ if (cpu_is_omap242x())
Looks like this should be a cpu_is_omap24xx(). The
current master is broken on a 2430sdp and a git-bisect
pointed me to this patch.
Regards,
Rajendra
+ omap_irq_base = OMAP2_L4_IO_ADDRESS(OMAP24XX_IC_BASE);
+ else if (cpu_is_omap34xx())
+ omap_irq_base = OMAP2_L4_IO_ADDRESS(OMAP34XX_IC_BASE);
+ else if (cpu_is_omap44xx())
+ omap_irq_base =
OMAP2_L4_IO_ADDRESS(OMAP44XX_GIC_CPU_BASE);
+ else
+ pr_err(Could not initialize omap_irq_base\n);
+#endif
+}
+
void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1)
{
@@ -352,4 +372,6 @@ void __init omap2_init_common_hw(struct
omap_sdrc_params *sdrc_cs0,
_omap2_init_reprogram_sdrc();
}
gpmc_init();
+
+ omap_irq_base_init();
}
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/8] OMAP4: clock data: Add missing fields in iva_hsd_byp_clk_mux_ck
Hi Paul, On 12/11/2010 1:34 AM, Paul Walmsley wrote: On Thu, 9 Dec 2010, Benoit Cousson wrote: From: Jonathan Bergsageljbergsa...@ti.com Add register address, mask and link to the clksel structure that were missing in the IVA DPLL mux clock node. Signed-off-by: Jonathan Bergsageljbergsa...@ti.com Signed-off-by: Benoit Coussonb-cous...@ti.com This patch results in a checkpatch warning: --- WARNING: please, no space before tabs #23: FILE: arch/arm/mach-omap2/clock44xx_data.c:639: +^I.clksel ^I= iva_hsd_byp_clk_mux_sel,$ total: 0 errors, 1 warnings, 0 checks, 13 lines checked Your patch has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. --- I've fixed it in the copy in my local branch, but next time, please run checkpatch.pl and fix any problems before submitting. Oops, that's my mistake. the original patch was good, and I messed it up during the merge conflict resolution. And then on top of that I completely missed this warning due to the important number of line over 80 characters warnings in this series. I have now a filter for dummies to remove that and avoid missing real warnings in the future. Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if ES1.2
Nishant,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Nishanth Menon
Sent: Friday, December 03, 2010 10:34 PM
To: linux-omap
Cc: Eduardo Valentin; Kevin Hilman; Tony Lindgren; Nishanth Menon
Subject: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if
ES1.2
From: Eduardo Valentin eduardo.valen...@nokia.com
Limitation i583: Self_Refresh Exit issue after OFF mode
Issue:
When device is waking up from OFF mode, then SDRC state machine
sends
inappropriate sequence violating JEDEC standards.
Impact:
OMAP3630 ES1.2 is impacted as follows depending on the platform:
CS0: for 38.4MHz as internal sysclk, DDR content seen to be stable,
while
for all other sysclk frequencies, varied levels of instability
seen based on varied parameters.
CS1: impacted
This patch takes option #3 as recommended by the Silicon erratum:
Avoid core power domain transitioning to OFF mode. Power consumption
impact is expected in this case.
To do this, we route OFF requests to RET request on the impacted
revisions
of silicon.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
[...@ti.com: rebased the code to 2.6.37-rc2- short circuit code changed
a bit]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
v3: no functional change in erratum wa implementation, just registration
of
erratum is collated to a single cpu detection and version check
v2: https://patchwork.kernel.org/patch/365262/
rebased to this patch series instead of depending on hs changes
fix typo for macro definition
v1: http://marc.info/?l=linux-omapm=129013173425266w=2
arch/arm/mach-omap2/pm34xx.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-
omap2/pm34xx.c
index b49e02b..ba3c0d6 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -56,6 +56,7 @@
#define OMAP343X_CONTROL_REG_VALUE_OFFSET 0xc8
#define RTA_ERRATUM_i608 (1 0)
+#define SDRC_WAKEUP_ERRATUM_i583 (1 1)
static u16 pm34xx_errata;
#define IS_PM34XX_ERRATUM(id)(pm34xx_errata (id))
@@ -406,6 +407,17 @@ void omap_sram_idle(void)
}
/* CORE */
+ /*
+ * Erratum i583: implementation for ES rev Es1.2 on 3630
+ * We cannot enable OFF mode in a stable form for previous
+ * revisions, transition instead to RET
+ */
+ if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
+ (core_next_state == PWRDM_POWER_OFF)) {
+ pwrdm_set_next_pwrst(core_pwrdm,
PWRDM_POWER_RET);
+ core_next_state = PWRDM_POWER_RET;
+ }
Since next_state in pwrst_list (for core) is not updated, this is throwing
up an error Powerdomain (core_pwrdm) didn't enter target state 0 when
you off mode is enabled for ES1.1 or lesser (in suspend path). It's not
really true that Core has not entered target state. It has entered
Retention state which is the actual target state set in omap_sram_idle.
However it did not enter the state that was passed by omap3_pm_suspend. Is
this expected behavior?
Vishwa
+
if (core_next_state PWRDM_POWER_ON) {
omap_uart_prepare_idle(0);
omap_uart_prepare_idle(1);
@@ -999,6 +1011,8 @@ static void __init pm_errata_configure(void)
pm34xx_errata |= RTA_ERRATUM_i608;
/* Enable the l2 cache toggling in sleep logic */
enable_omap3630_toggle_l2_on_restore();
+ if (omap_rev() OMAP3630_REV_ES1_2)
+ pm34xx_errata |= SDRC_WAKEUP_ERRATUM_i583;
}
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if ES1.2
Vishwanath Sripathy had written, on 12/13/2010 07:35 AM, the following:
Nishant,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Nishanth Menon
Sent: Friday, December 03, 2010 10:34 PM
To: linux-omap
Cc: Eduardo Valentin; Kevin Hilman; Tony Lindgren; Nishanth Menon
Subject: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if
ES1.2
From: Eduardo Valentin eduardo.valen...@nokia.com
Limitation i583: Self_Refresh Exit issue after OFF mode
Issue:
When device is waking up from OFF mode, then SDRC state machine
sends
inappropriate sequence violating JEDEC standards.
Impact:
OMAP3630 ES1.2 is impacted as follows depending on the platform:
CS0: for 38.4MHz as internal sysclk, DDR content seen to be stable,
while
for all other sysclk frequencies, varied levels of instability
seen based on varied parameters.
CS1: impacted
This patch takes option #3 as recommended by the Silicon erratum:
Avoid core power domain transitioning to OFF mode. Power consumption
impact is expected in this case.
To do this, we route OFF requests to RET request on the impacted
revisions
of silicon.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
[...@ti.com: rebased the code to 2.6.37-rc2- short circuit code changed
a bit]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
v3: no functional change in erratum wa implementation, just registration
of
erratum is collated to a single cpu detection and version check
v2: https://patchwork.kernel.org/patch/365262/
rebased to this patch series instead of depending on hs changes
fix typo for macro definition
v1: http://marc.info/?l=linux-omapm=129013173425266w=2
arch/arm/mach-omap2/pm34xx.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-
omap2/pm34xx.c
index b49e02b..ba3c0d6 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -56,6 +56,7 @@
#define OMAP343X_CONTROL_REG_VALUE_OFFSET 0xc8
#define RTA_ERRATUM_i608 (1 0)
+#define SDRC_WAKEUP_ERRATUM_i583 (1 1)
static u16 pm34xx_errata;
#define IS_PM34XX_ERRATUM(id) (pm34xx_errata (id))
@@ -406,6 +407,17 @@ void omap_sram_idle(void)
}
/* CORE */
+ /*
+* Erratum i583: implementation for ES rev Es1.2 on 3630
+* We cannot enable OFF mode in a stable form for previous
+* revisions, transition instead to RET
+*/
+ if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
+ (core_next_state == PWRDM_POWER_OFF)) {
+ pwrdm_set_next_pwrst(core_pwrdm,
PWRDM_POWER_RET);
+ core_next_state = PWRDM_POWER_RET;
+ }
Since next_state in pwrst_list (for core) is not updated, this is throwing
up an error Powerdomain (core_pwrdm) didn't enter target state 0 when
you off mode is enabled for ES1.1 or lesser (in suspend path). It's not
really true that Core has not entered target state. It has entered
Retention state which is the actual target state set in omap_sram_idle.
However it did not enter the state that was passed by omap3_pm_suspend. Is
this expected behavior?
we could go both ways on this - this patch will(as you noticed) indicate
that the transition failed on ES1.2, or we could make it entirely
transparent(by modifying the the pwrst_list - claim we achieved off,
while not really hitting off - I personally dont think that is correct.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH/RFC 2/2] OMAP: PM: implement context loss count APIs
Paul, -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Monday, December 13, 2010 4:13 PM To: Vishwanath Sripathy Cc: Kevin Hilman; linux-omap@vger.kernel.org Subject: RE: [PATCH/RFC 2/2] OMAP: PM: implement context loss count APIs Hello Vishwa, On Fri, 10 Dec 2010, Vishwanath Sripathy wrote: + count = omap_device_get_context_loss_count(pdev); + pr_debug(OMAP PM: context loss count for dev %s = %d\n, + dev_name(dev), count); Shouldn't this implementation be part of omap-pm.c where all the OMAP PM functions are to be implemented? I thought omap-pm-noop.c should have dummy implementation. In general, yes. But we also want the code in omap-pm-noop.c not to cause additional breakage. Unlike most of the other functions in this file, if the context loss count function doesn't do something minimally useful, then the system is going to break badly. You've probably seen this thread: http://www.mail-archive.com/linux- o...@vger.kernel.org/msg40079.html (By the way, the reason why I think we shouldn't use the approach described in http://www.mail-archive.com/linux- o...@vger.kernel.org/msg40101.html is because I suspect it is going to seriously damage retention idle performance. For example, the HSMMC driver resets its entire IP block in its context restore function...) But to confirm your general point, yes, in general, further functional development of the OMAP PM code should take place outside the no-op file. Hopefully, at some point, we'll be able to drop the no-op file. Once there is a useful replacement, we should be able to switch to it as a default. I have no issues with the implementation and I agree. All I am saying is that why can't this implementation be added in omap-pm.c and compile this file instead of omap-pm-noop.c when OMAP_PM is enabled. I believe this function is useful when off mode is enabled which means OMAP_PM is enabled. Vishwa - 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 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if ES1.2
Nishant,
-Original Message-
From: Nishanth Menon [mailto:n...@ti.com]
Sent: Monday, December 13, 2010 7:13 PM
To: Vishwanath Sripathy
Cc: linux-omap; Eduardo Valentin; Kevin Hilman; Tony Lindgren
Subject: Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable
coreoff if ES1.2
Vishwanath Sripathy had written, on 12/13/2010 07:35 AM, the
following:
Nishant,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Nishanth Menon
Sent: Friday, December 03, 2010 10:34 PM
To: linux-omap
Cc: Eduardo Valentin; Kevin Hilman; Tony Lindgren; Nishanth Menon
Subject: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable
coreoff if
ES1.2
From: Eduardo Valentin eduardo.valen...@nokia.com
Limitation i583: Self_Refresh Exit issue after OFF mode
Issue:
When device is waking up from OFF mode, then SDRC state machine
sends
inappropriate sequence violating JEDEC standards.
Impact:
OMAP3630 ES1.2 is impacted as follows depending on the
platform:
CS0: for 38.4MHz as internal sysclk, DDR content seen to be stable,
while
for all other sysclk frequencies, varied levels of instability
seen based on varied parameters.
CS1: impacted
This patch takes option #3 as recommended by the Silicon erratum:
Avoid core power domain transitioning to OFF mode. Power
consumption
impact is expected in this case.
To do this, we route OFF requests to RET request on the impacted
revisions
of silicon.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
[...@ti.com: rebased the code to 2.6.37-rc2- short circuit code
changed
a bit]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
v3: no functional change in erratum wa implementation, just
registration
of
erratum is collated to a single cpu detection and version check
v2: https://patchwork.kernel.org/patch/365262/
rebased to this patch series instead of depending on hs changes
fix typo for macro definition
v1: http://marc.info/?l=linux-omapm=129013173425266w=2
arch/arm/mach-omap2/pm34xx.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-
omap2/pm34xx.c
index b49e02b..ba3c0d6 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -56,6 +56,7 @@
#define OMAP343X_CONTROL_REG_VALUE_OFFSET 0xc8
#define RTA_ERRATUM_i608 (1 0)
+#define SDRC_WAKEUP_ERRATUM_i583 (1 1)
static u16 pm34xx_errata;
#define IS_PM34XX_ERRATUM(id) (pm34xx_errata (id))
@@ -406,6 +407,17 @@ void omap_sram_idle(void)
}
/* CORE */
+ /*
+ * Erratum i583: implementation for ES rev Es1.2 on 3630
+ * We cannot enable OFF mode in a stable form for previous
+ * revisions, transition instead to RET
+ */
+ if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
+ (core_next_state == PWRDM_POWER_OFF)) {
+ pwrdm_set_next_pwrst(core_pwrdm,
PWRDM_POWER_RET);
+ core_next_state = PWRDM_POWER_RET;
+ }
Since next_state in pwrst_list (for core) is not updated, this is
throwing
up an error Powerdomain (core_pwrdm) didn't enter target state 0
when
you off mode is enabled for ES1.1 or lesser (in suspend path). It's
not
really true that Core has not entered target state. It has entered
Retention state which is the actual target state set in
omap_sram_idle.
However it did not enter the state that was passed by
omap3_pm_suspend. Is
this expected behavior?
we could go both ways on this - this patch will(as you noticed) indicate
that the transition failed on ES1.2, or we could make it entirely
transparent(by modifying the the pwrst_list - claim we achieved off,
while not really hitting off - I personally dont think that is correct.
The point I am making is that you cannot distinguish between genuine off
/retention failure since this message is thrown for both pass and fail.
May be an additional trace message indicating that system entered
retention instead of off (for ES1.2) will be useful.
Vishwa
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if ES1.2
Vishwanath Sripathy had written, on 12/13/2010 07:54 AM, the following:
Nishant,
-Original Message-
From: Nishanth Menon [mailto:n...@ti.com]
Sent: Monday, December 13, 2010 7:13 PM
To: Vishwanath Sripathy
Cc: linux-omap; Eduardo Valentin; Kevin Hilman; Tony Lindgren
Subject: Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable
coreoff if ES1.2
Vishwanath Sripathy had written, on 12/13/2010 07:35 AM, the
following:
Nishant,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Nishanth Menon
Sent: Friday, December 03, 2010 10:34 PM
To: linux-omap
Cc: Eduardo Valentin; Kevin Hilman; Tony Lindgren; Nishanth Menon
Subject: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable
coreoff if
ES1.2
From: Eduardo Valentin eduardo.valen...@nokia.com
Limitation i583: Self_Refresh Exit issue after OFF mode
Issue:
When device is waking up from OFF mode, then SDRC state machine
sends
inappropriate sequence violating JEDEC standards.
Impact:
OMAP3630 ES1.2 is impacted as follows depending on the
platform:
CS0: for 38.4MHz as internal sysclk, DDR content seen to be stable,
while
for all other sysclk frequencies, varied levels of instability
seen based on varied parameters.
CS1: impacted
This patch takes option #3 as recommended by the Silicon erratum:
Avoid core power domain transitioning to OFF mode. Power
consumption
impact is expected in this case.
To do this, we route OFF requests to RET request on the impacted
revisions
of silicon.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
[...@ti.com: rebased the code to 2.6.37-rc2- short circuit code
changed
a bit]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
v3: no functional change in erratum wa implementation, just
registration
of
erratum is collated to a single cpu detection and version check
v2: https://patchwork.kernel.org/patch/365262/
rebased to this patch series instead of depending on hs changes
fix typo for macro definition
v1: http://marc.info/?l=linux-omapm=129013173425266w=2
arch/arm/mach-omap2/pm34xx.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-
omap2/pm34xx.c
index b49e02b..ba3c0d6 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -56,6 +56,7 @@
#define OMAP343X_CONTROL_REG_VALUE_OFFSET 0xc8
#define RTA_ERRATUM_i608 (1 0)
+#define SDRC_WAKEUP_ERRATUM_i583 (1 1)
static u16 pm34xx_errata;
#define IS_PM34XX_ERRATUM(id) (pm34xx_errata (id))
@@ -406,6 +407,17 @@ void omap_sram_idle(void)
}
/* CORE */
+ /*
+* Erratum i583: implementation for ES rev Es1.2 on 3630
+* We cannot enable OFF mode in a stable form for previous
+* revisions, transition instead to RET
+*/
+ if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
+ (core_next_state == PWRDM_POWER_OFF)) {
+ pwrdm_set_next_pwrst(core_pwrdm,
PWRDM_POWER_RET);
+ core_next_state = PWRDM_POWER_RET;
+ }
Since next_state in pwrst_list (for core) is not updated, this is
throwing
up an error Powerdomain (core_pwrdm) didn't enter target state 0
when
you off mode is enabled for ES1.1 or lesser (in suspend path). It's
not
really true that Core has not entered target state. It has entered
Retention state which is the actual target state set in
omap_sram_idle.
However it did not enter the state that was passed by
omap3_pm_suspend. Is
this expected behavior?
we could go both ways on this - this patch will(as you noticed) indicate
that the transition failed on ES1.2, or we could make it entirely
transparent(by modifying the the pwrst_list - claim we achieved off,
while not really hitting off - I personally dont think that is correct.
The point I am making is that you cannot distinguish between genuine off
/retention failure since this message is thrown for both pass and fail.
May be an additional trace message indicating that system entered
retention instead of off (for ES1.2) will be useful.
hmm... good point there.
two issues here:
a) omap3_pm_suspend should probably state which state was achieved as
well in the error message (trivial fix).
b) how do we notify users that it was due to SDRC_WAKEUP_ERRATUM_i583
that core-off was denied. - do this in omap3_pm_suspend(when user
attempts actual OFF) OR omap3_pm_off_mode_enable(when user attempts to
enable OFF mode)?
Any suggestions to allow the same uImage boot on all silicon + allow
cpu_idle + suspend paths not to spew pr_info messages(aka cant add
prints in sram_idle)?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
RE: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if ES1.2
Nishant,
-Original Message-
From: Nishanth Menon [mailto:n...@ti.com]
Sent: Monday, December 13, 2010 7:35 PM
To: Vishwanath Sripathy
Cc: linux-omap; Eduardo Valentin; Kevin Hilman; Tony Lindgren
Subject: Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable
coreoff if ES1.2
Vishwanath Sripathy had written, on 12/13/2010 07:54 AM, the
following:
Nishant,
-Original Message-
From: Nishanth Menon [mailto:n...@ti.com]
Sent: Monday, December 13, 2010 7:13 PM
To: Vishwanath Sripathy
Cc: linux-omap; Eduardo Valentin; Kevin Hilman; Tony Lindgren
Subject: Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable
coreoff if ES1.2
Vishwanath Sripathy had written, on 12/13/2010 07:35 AM, the
following:
Nishant,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Nishanth Menon
Sent: Friday, December 03, 2010 10:34 PM
To: linux-omap
Cc: Eduardo Valentin; Kevin Hilman; Tony Lindgren; Nishanth
Menon
Subject: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable
coreoff if
ES1.2
From: Eduardo Valentin eduardo.valen...@nokia.com
Limitation i583: Self_Refresh Exit issue after OFF mode
Issue:
When device is waking up from OFF mode, then SDRC state
machine
sends
inappropriate sequence violating JEDEC standards.
Impact:
OMAP3630 ES1.2 is impacted as follows depending on the
platform:
CS0: for 38.4MHz as internal sysclk, DDR content seen to be
stable,
while
for all other sysclk frequencies, varied levels of instability
seen based on varied parameters.
CS1: impacted
This patch takes option #3 as recommended by the Silicon
erratum:
Avoid core power domain transitioning to OFF mode. Power
consumption
impact is expected in this case.
To do this, we route OFF requests to RET request on the impacted
revisions
of silicon.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
[...@ti.com: rebased the code to 2.6.37-rc2- short circuit code
changed
a bit]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
v3: no functional change in erratum wa implementation, just
registration
of
erratum is collated to a single cpu detection and version
check
v2: https://patchwork.kernel.org/patch/365262/
rebased to this patch series instead of depending on hs
changes
fix typo for macro definition
v1: http://marc.info/?l=linux-omapm=129013173425266w=2
arch/arm/mach-omap2/pm34xx.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-
omap2/pm34xx.c
index b49e02b..ba3c0d6 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -56,6 +56,7 @@
#define OMAP343X_CONTROL_REG_VALUE_OFFSET 0xc8
#define RTA_ERRATUM_i608(1 0)
+#define SDRC_WAKEUP_ERRATUM_i583(1 1)
static u16 pm34xx_errata;
#define IS_PM34XX_ERRATUM(id) (pm34xx_errata (id))
@@ -406,6 +407,17 @@ void omap_sram_idle(void)
}
/* CORE */
+/*
+ * Erratum i583: implementation for ES rev Es1.2 on
3630
+ * We cannot enable OFF mode in a stable form for
previous
+ * revisions, transition instead to RET
+ */
+if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
+(core_next_state == PWRDM_POWER_OFF))
{
+pwrdm_set_next_pwrst(core_pwrdm,
PWRDM_POWER_RET);
+core_next_state = PWRDM_POWER_RET;
+}
Since next_state in pwrst_list (for core) is not updated, this is
throwing
up an error Powerdomain (core_pwrdm) didn't enter target state
0
when
you off mode is enabled for ES1.1 or lesser (in suspend path). It's
not
really true that Core has not entered target state. It has entered
Retention state which is the actual target state set in
omap_sram_idle.
However it did not enter the state that was passed by
omap3_pm_suspend. Is
this expected behavior?
we could go both ways on this - this patch will(as you noticed)
indicate
that the transition failed on ES1.2, or we could make it entirely
transparent(by modifying the the pwrst_list - claim we achieved off,
while not really hitting off - I personally dont think that is
correct.
The point I am making is that you cannot distinguish between genuine
off
/retention failure since this message is thrown for both pass and
fail.
May be an additional trace message indicating that system entered
retention instead of off (for ES1.2) will be useful.
hmm... good point there.
two issues here:
a) omap3_pm_suspend should probably state which state was achieved
as
well in the error message (trivial fix).
b) how do we notify users that it was due to
SDRC_WAKEUP_ERRATUM_i583
that
Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if ES1.2
Vishwanath Sripathy had written, on 12/13/2010 08:25 AM, the following:
[...]
+ if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
+ (core_next_state == PWRDM_POWER_OFF))
{
+ pwrdm_set_next_pwrst(core_pwrdm,
PWRDM_POWER_RET);
+ core_next_state = PWRDM_POWER_RET;
+ }
Since next_state in pwrst_list (for core) is not updated, this is
throwing
up an error Powerdomain (core_pwrdm) didn't enter target state
0
when
you off mode is enabled for ES1.1 or lesser (in suspend path). It's
not
really true that Core has not entered target state. It has entered
Retention state which is the actual target state set in
omap_sram_idle.
However it did not enter the state that was passed by
omap3_pm_suspend. Is
this expected behavior?
we could go both ways on this - this patch will(as you noticed)
indicate
that the transition failed on ES1.2, or we could make it entirely
transparent(by modifying the the pwrst_list - claim we achieved off,
while not really hitting off - I personally dont think that is
correct.
The point I am making is that you cannot distinguish between genuine
off
/retention failure since this message is thrown for both pass and
fail.
May be an additional trace message indicating that system entered
retention instead of off (for ES1.2) will be useful.
hmm... good point there.
two issues here:
a) omap3_pm_suspend should probably state which state was achieved
as
well in the error message (trivial fix).
b) how do we notify users that it was due to
SDRC_WAKEUP_ERRATUM_i583
that core-off was denied. - do this in omap3_pm_suspend(when user
attempts actual OFF) OR omap3_pm_off_mode_enable(when user
attempts to
enable OFF mode)?
Any suggestions to allow the same uImage boot on all silicon + allow
cpu_idle + suspend paths not to spew pr_info messages(aka cant add
prints in sram_idle)?
I vote for denying off mode for Core (for ES1.2) in
omap3_pm_off_mode_enable and throw up a message saying that Core off is
not enabled. Then we will not get this failure message in suspend path
since pwrst_list will have the right state.
Keep in mind - if we disable it in omap3_pm_off_mode_enable - we will
deny OFF wholesale if I understand the logic right- not just core-off -
I kind of think that is extreme.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if ES1.2
-Original Message-
Vishwanath Sripathy had written, on 12/13/2010 08:25 AM, the following:
[...]
+ if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
+ (core_next_state == PWRDM_POWER_OFF))
{
+ pwrdm_set_next_pwrst(core_pwrdm,
PWRDM_POWER_RET);
+ core_next_state = PWRDM_POWER_RET;
+ }
Since next_state in pwrst_list (for core) is not updated, this is
throwing
up an error Powerdomain (core_pwrdm) didn't enter target state
0
when
you off mode is enabled for ES1.1 or lesser (in suspend path).
It's
not
really true that Core has not entered target state. It has entered
Retention state which is the actual target state set in
omap_sram_idle.
However it did not enter the state that was passed by
omap3_pm_suspend. Is
this expected behavior?
we could go both ways on this - this patch will(as you noticed)
indicate
that the transition failed on ES1.2, or we could make it entirely
transparent(by modifying the the pwrst_list - claim we achieved
off,
while not really hitting off - I personally dont think that is
correct.
The point I am making is that you cannot distinguish between genuine
off
/retention failure since this message is thrown for both pass and
fail.
May be an additional trace message indicating that system entered
retention instead of off (for ES1.2) will be useful.
hmm... good point there.
two issues here:
a) omap3_pm_suspend should probably state which state was achieved
as
well in the error message (trivial fix).
b) how do we notify users that it was due to
SDRC_WAKEUP_ERRATUM_i583
that core-off was denied. - do this in omap3_pm_suspend(when user
attempts actual OFF) OR omap3_pm_off_mode_enable(when user
attempts to
enable OFF mode)?
Any suggestions to allow the same uImage boot on all silicon + allow
cpu_idle + suspend paths not to spew pr_info messages(aka cant add
prints in sram_idle)?
I vote for denying off mode for Core (for ES1.2) in
omap3_pm_off_mode_enable and throw up a message saying that Core off
is
not enabled. Then we will not get this failure message in suspend path
since pwrst_list will have the right state.
Keep in mind - if we disable it in omap3_pm_off_mode_enable - we will
deny OFF wholesale if I understand the logic right- not just core-off -
I kind of think that is extreme.
I take that back, we could do something like the following instead:
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index ba3c0d6..74842f1 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -933,7 +933,14 @@ void omap3_pm_off_mode_enable(int enable)
list_for_each_entry(pwrst, pwrst_list, node) {
pwrst-next_state = state;
- omap_set_pwrdm_state(pwrst-pwrdm, state);
+ if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
+ pwrst-pwrdm == core_pwrdm) {
+ omap_set_pwrdm_state(pwrst-pwrdm,
PWRDM_POWER_RET);
+ pr_err(%s: cannot enable Core OFF due to i583\n,
+ __func__);
+ } else {
+ omap_set_pwrdm_state(pwrst-pwrdm, state);
+ }
}
}
Will wait to see if there are additional opinions on this approach -if
none,
Will post a v4 for this patch alone.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if ES1.2
Vishwanath Sripathy had written, on 12/13/2010 08:45 AM, the following:
Keep in mind - if we disable it in omap3_pm_off_mode_enable - we will
deny OFF wholesale if I understand the logic right- not just core-off -
I kind of think that is extreme.
No, I am not saying that deny idle for all power domains. Deny it only for
Core domain, something like this.
void omap3_pm_off_mode_enable(int enable)
{
struct power_state *pwrst;
u32 state;
if (enable)
state = PWRDM_POWER_OFF;
else
state = PWRDM_POWER_RET;
#ifdef CONFIG_CPU_IDLE
omap3_cpuidle_update_states();
#endif
list_for_each_entry(pwrst, pwrst_list, node) {
pwrst-next_state = state;
if (strcmp(core_pwrdm, pwrst-pwrdm-name)==0) {
if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
state ==PWRDM_POWER_OFF)
pwrst-next_state = PWRDM_POWER_RET;
}
omap_set_pwrdm_state(pwrst-pwrdm, pwrst-next_state);
yep, I think our emails crossed wires - I realized the same as well.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if ES1.2
-Original Message-
From: Nishanth Menon [mailto:n...@ti.com]
Sent: Monday, December 13, 2010 8:14 PM
To: Vishwanath Sripathy
Cc: linux-omap; Eduardo Valentin; Kevin Hilman; Tony Lindgren
Subject: RE: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable
coreoff if ES1.2
-Original Message-
Vishwanath Sripathy had written, on 12/13/2010 08:25 AM, the
following:
[...]
+if
(IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
+(core_next_state ==
PWRDM_POWER_OFF))
{
+pwrdm_set_next_pwrst(core_pwrdm,
PWRDM_POWER_RET);
+core_next_state = PWRDM_POWER_RET;
+}
Since next_state in pwrst_list (for core) is not updated, this
is
throwing
up an error Powerdomain (core_pwrdm) didn't enter target
state
0
when
you off mode is enabled for ES1.1 or lesser (in suspend path).
It's
not
really true that Core has not entered target state. It has
entered
Retention state which is the actual target state set in
omap_sram_idle.
However it did not enter the state that was passed by
omap3_pm_suspend. Is
this expected behavior?
we could go both ways on this - this patch will(as you noticed)
indicate
that the transition failed on ES1.2, or we could make it
entirely
transparent(by modifying the the pwrst_list - claim we achieved
off,
while not really hitting off - I personally dont think that is
correct.
The point I am making is that you cannot distinguish between
genuine
off
/retention failure since this message is thrown for both pass and
fail.
May be an additional trace message indicating that system
entered
retention instead of off (for ES1.2) will be useful.
hmm... good point there.
two issues here:
a) omap3_pm_suspend should probably state which state was
achieved
as
well in the error message (trivial fix).
b) how do we notify users that it was due to
SDRC_WAKEUP_ERRATUM_i583
that core-off was denied. - do this in omap3_pm_suspend(when
user
attempts actual OFF) OR omap3_pm_off_mode_enable(when user
attempts to
enable OFF mode)?
Any suggestions to allow the same uImage boot on all silicon +
allow
cpu_idle + suspend paths not to spew pr_info messages(aka cant
add
prints in sram_idle)?
I vote for denying off mode for Core (for ES1.2) in
omap3_pm_off_mode_enable and throw up a message saying that
Core off
is
not enabled. Then we will not get this failure message in suspend
path
since pwrst_list will have the right state.
Keep in mind - if we disable it in omap3_pm_off_mode_enable - we
will
deny OFF wholesale if I understand the logic right- not just core-off
-
I kind of think that is extreme.
I take that back, we could do something like the following instead:
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-
omap2/pm34xx.c
index ba3c0d6..74842f1 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -933,7 +933,14 @@ void omap3_pm_off_mode_enable(int enable)
list_for_each_entry(pwrst, pwrst_list, node) {
pwrst-next_state = state;
- omap_set_pwrdm_state(pwrst-pwrdm, state);
+ if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
+ pwrst-pwrdm == core_pwrdm) {
+ omap_set_pwrdm_state(pwrst-pwrdm,
PWRDM_POWER_RET);
You need to update pwrst-next_state as well.
Otherwise suspend will still throw the same error. I just sent the code in
other email.
Vishwa
+ pr_err(%s: cannot enable Core OFF due to
i583\n,
+ __func__);
+ } else {
+ omap_set_pwrdm_state(pwrst-pwrdm, state);
+ }
}
}
Will wait to see if there are additional opinions on this approach -if
none,
Will post a v4 for this patch alone.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: clean up ASM idle code
-Original Message- From: jean.pi...@newoldbits.com [mailto:jean.pi...@newoldbits.com] Sent: Tuesday, December 07, 2010 4:42 PM To: linux-omap@vger.kernel.org Cc: Jean Pihet; Vishwanath BS Subject: [PATCH] OMAP3: clean up ASM idle code From: Jean Pihet j-pi...@ti.com Clean up of the ASM code: - reorganized the code in logical sections: defines, API functions, internal functions and variables, - reworked and simplified the execution paths, for better readability and to avoid duplication of code, - added comments on the entry and exit points, - reworked the existing comments for better readability, - reworked the code formating, alignment and white spaces, - added comments for the i443 erratum workarounds, - changed the hardcoded values in favor of existing macros from include files, - clean up of non used symbols. Tested on OMAP3EVM and Beagleboard with full RET and OFF modes. Heavily reworked from Vishwa's original patch. Signed-off-by: Jean Pihet j-pi...@ti.com Cc: Vishwanath BS vishwanath...@ti.com Tested on ZOOM3 for Retention and OFF in suspend and Idle path. Acked-by: Vishwanath BS vishwanath...@ti.com --- Applies on top of Nishant's latest idle path errata fixes step 2, cf. http://marc.info/?l=linux-omapm=129139584919242w=2 arch/arm/mach-omap2/control.h |2 + arch/arm/mach-omap2/pm.h|1 - arch/arm/mach-omap2/pm34xx.c|4 +- arch/arm/mach-omap2/sleep34xx.S | 522 +-- 4 files changed, 288 insertions(+), 241 deletions(-) diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach- omap2/control.h index d7911c5..72efefb 100644 --- a/arch/arm/mach-omap2/control.h +++ b/arch/arm/mach-omap2/control.h @@ -274,6 +274,8 @@ #define OMAP343X_SCRATCHPAD_ROM (OMAP343X_CTRL_BASE + 0x860) #define OMAP343X_SCRATCHPAD (OMAP343X_CTRL_BASE + 0x910) #define OMAP343X_SCRATCHPAD_ROM_OFFSET 0x19C +#define OMAP343X_SCRATCHPAD_REGADDR(reg) OMAP2_L4_IO_ADDRESS(\ + OMAP343X_SCRATCHPAD + reg) /* AM35XX_CONTROL_IPSS_CLK_CTRL bits */ #define AM35XX_USBOTG_VBUSP_CLK_SHIFT 0 diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h index aff39d0..e458b2a 100644 --- a/arch/arm/mach-omap2/pm.h +++ b/arch/arm/mach-omap2/pm.h @@ -80,7 +80,6 @@ extern void save_secure_ram_context(u32 *addr); extern void omap3_save_scratchpad_contents(void); extern unsigned int omap24xx_idle_loop_suspend_sz; -extern unsigned int omap34xx_suspend_sz; extern unsigned int save_secure_ram_context_sz; extern unsigned int omap24xx_cpu_suspend_sz; extern unsigned int omap34xx_cpu_suspend_sz; diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach- omap2/pm34xx.c index a37d53d..c93b872 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -135,7 +135,7 @@ static void omap3_core_save_context(void) /* * Force write last pad into memory, as this can fail in some - * cases according to erratas 1.157, 1.185 + * cases according to errata 1.157 1.185 */ omap_ctrl_writel(omap_ctrl_readl(OMAP343X_PADCONF_ETK_D1 4), OMAP343X_CONTROL_MEM_WKUP + 0x2a0); @@ -432,7 +432,7 @@ void omap_sram_idle(void) /* * On EMU/HS devices ROM code restores a SRDC value * from scratchpad which has automatic self refresh on timeout - * of AUTO_CNT = 1 enabled. This takes care of errata 1.142. + * of AUTO_CNT = 1 enabled. This takes care of erratum ID i443. * Hence store/restore the SDRC_POWER register here. */ if (omap_rev() = OMAP3430_REV_ES3_0 diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach- omap2/sleep34xx.S index d2eda01..96a4864 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -33,24 +33,27 @@ #include sdrc.h #include control.h -#define SDRC_SCRATCHPAD_SEM_V0xfa00291c - -#define PM_PREPWSTST_CORE_V OMAP34XX_PRM_REGADDR(CORE_MOD, \ - OMAP3430_PM_PREPWSTST) -#define PM_PREPWSTST_CORE_P 0x48306AE8 -#define PM_PREPWSTST_MPU_V OMAP34XX_PRM_REGADDR(MPU_MOD, \ - OMAP3430_PM_PREPWSTST) +/* + * Registers access definitions + */ +#define SDRC_SCRATCHPAD_SEM_OFFS 0xc +#define SDRC_SCRATCHPAD_SEM_V OMAP343X_SCRATCHPAD_REGADDR\ + (SDRC_SCRATCHPAD_SEM_OFFS) +#define PM_PREPWSTST_CORE_P OMAP3430_PRM_BASE + CORE_MOD +\ + OMAP3430_PM_PREPWSTST #define PM_PWSTCTRL_MPU_POMAP3430_PRM_BASE + MPU_MOD + OMAP2_PM_PWSTCTRL #define CM_IDLEST1_CORE_V OMAP34XX_CM_REGADDR(CORE_MOD, CM_IDLEST1) #define CM_IDLEST_CKGEN_VOMAP34XX_CM_REGADDR(PLL_MOD, CM_IDLEST) #define SRAM_BASE_P 0x4020 -#define CONTROL_STAT 0x480022F0 -#define CONTROL_MEM_RTA_CTRL
RE: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if ES1.2
Nishant,
-Original Message-
From: Nishanth Menon [mailto:n...@ti.com]
Sent: Monday, December 13, 2010 8:07 PM
To: Vishwanath Sripathy
Cc: linux-omap; Eduardo Valentin; Kevin Hilman; Tony Lindgren
Subject: Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable
coreoff if ES1.2
Vishwanath Sripathy had written, on 12/13/2010 08:25 AM, the
following:
[...]
+ if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
+ (core_next_state == PWRDM_POWER_OFF))
{
+ pwrdm_set_next_pwrst(core_pwrdm,
PWRDM_POWER_RET);
+ core_next_state = PWRDM_POWER_RET;
+ }
Since next_state in pwrst_list (for core) is not updated, this is
throwing
up an error Powerdomain (core_pwrdm) didn't enter target
state
0
when
you off mode is enabled for ES1.1 or lesser (in suspend path).
It's
not
really true that Core has not entered target state. It has entered
Retention state which is the actual target state set in
omap_sram_idle.
However it did not enter the state that was passed by
omap3_pm_suspend. Is
this expected behavior?
we could go both ways on this - this patch will(as you noticed)
indicate
that the transition failed on ES1.2, or we could make it entirely
transparent(by modifying the the pwrst_list - claim we achieved
off,
while not really hitting off - I personally dont think that is
correct.
The point I am making is that you cannot distinguish between
genuine
off
/retention failure since this message is thrown for both pass and
fail.
May be an additional trace message indicating that system entered
retention instead of off (for ES1.2) will be useful.
hmm... good point there.
two issues here:
a) omap3_pm_suspend should probably state which state was
achieved
as
well in the error message (trivial fix).
b) how do we notify users that it was due to
SDRC_WAKEUP_ERRATUM_i583
that core-off was denied. - do this in omap3_pm_suspend(when
user
attempts actual OFF) OR omap3_pm_off_mode_enable(when user
attempts to
enable OFF mode)?
Any suggestions to allow the same uImage boot on all silicon + allow
cpu_idle + suspend paths not to spew pr_info messages(aka cant
add
prints in sram_idle)?
I vote for denying off mode for Core (for ES1.2) in
omap3_pm_off_mode_enable and throw up a message saying that
Core off is
not enabled. Then we will not get this failure message in suspend path
since pwrst_list will have the right state.
Keep in mind - if we disable it in omap3_pm_off_mode_enable - we will
deny OFF wholesale if I understand the logic right- not just core-off -
I kind of think that is extreme.
No, I am not saying that deny idle for all power domains. Deny it only for
Core domain, something like this.
void omap3_pm_off_mode_enable(int enable)
{
struct power_state *pwrst;
u32 state;
if (enable)
state = PWRDM_POWER_OFF;
else
state = PWRDM_POWER_RET;
#ifdef CONFIG_CPU_IDLE
omap3_cpuidle_update_states();
#endif
list_for_each_entry(pwrst, pwrst_list, node) {
pwrst-next_state = state;
if (strcmp(core_pwrdm, pwrst-pwrdm-name)==0) {
if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
state ==PWRDM_POWER_OFF)
pwrst-next_state = PWRDM_POWER_RET;
}
omap_set_pwrdm_state(pwrst-pwrdm, pwrst-next_state);
}
}
Vishwa
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if ES1.2
Vishwanath Sripathy had written, on 12/13/2010 08:48 AM, the following:
-Original Message-
From: Nishanth Menon [mailto:n...@ti.com]
Sent: Monday, December 13, 2010 8:14 PM
To: Vishwanath Sripathy
Cc: linux-omap; Eduardo Valentin; Kevin Hilman; Tony Lindgren
Subject: RE: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable
coreoff if ES1.2
-Original Message-
Vishwanath Sripathy had written, on 12/13/2010 08:25 AM, the
following:
[...]
+ if
(IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
+ (core_next_state ==
PWRDM_POWER_OFF))
{
+ pwrdm_set_next_pwrst(core_pwrdm,
PWRDM_POWER_RET);
+ core_next_state = PWRDM_POWER_RET;
+ }
Since next_state in pwrst_list (for core) is not updated, this
is
throwing
up an error Powerdomain (core_pwrdm) didn't enter target
state
0
when
you off mode is enabled for ES1.1 or lesser (in suspend path).
It's
not
really true that Core has not entered target state. It has
entered
Retention state which is the actual target state set in
omap_sram_idle.
However it did not enter the state that was passed by
omap3_pm_suspend. Is
this expected behavior?
we could go both ways on this - this patch will(as you noticed)
indicate
that the transition failed on ES1.2, or we could make it
entirely
transparent(by modifying the the pwrst_list - claim we achieved
off,
while not really hitting off - I personally dont think that is
correct.
The point I am making is that you cannot distinguish between
genuine
off
/retention failure since this message is thrown for both pass and
fail.
May be an additional trace message indicating that system
entered
retention instead of off (for ES1.2) will be useful.
hmm... good point there.
two issues here:
a) omap3_pm_suspend should probably state which state was
achieved
as
well in the error message (trivial fix).
b) how do we notify users that it was due to
SDRC_WAKEUP_ERRATUM_i583
that core-off was denied. - do this in omap3_pm_suspend(when
user
attempts actual OFF) OR omap3_pm_off_mode_enable(when user
attempts to
enable OFF mode)?
Any suggestions to allow the same uImage boot on all silicon +
allow
cpu_idle + suspend paths not to spew pr_info messages(aka cant
add
prints in sram_idle)?
I vote for denying off mode for Core (for ES1.2) in
omap3_pm_off_mode_enable and throw up a message saying that
Core off
is
not enabled. Then we will not get this failure message in suspend
path
since pwrst_list will have the right state.
Keep in mind - if we disable it in omap3_pm_off_mode_enable - we
will
deny OFF wholesale if I understand the logic right- not just core-off
-
I kind of think that is extreme.
I take that back, we could do something like the following instead:
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-
omap2/pm34xx.c
index ba3c0d6..74842f1 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -933,7 +933,14 @@ void omap3_pm_off_mode_enable(int enable)
list_for_each_entry(pwrst, pwrst_list, node) {
pwrst-next_state = state;
- omap_set_pwrdm_state(pwrst-pwrdm, state);
+ if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
+ pwrst-pwrdm == core_pwrdm) {
+ omap_set_pwrdm_state(pwrst-pwrdm,
PWRDM_POWER_RET);
You need to update pwrst-next_state as well.
Otherwise suspend will still throw the same error. I just sent the code in
other email.
yep. except, I think we dont need to do string compare. the following
looks any better?
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index ba3c0d6..da12a56 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -932,8 +932,15 @@ void omap3_pm_off_mode_enable(int enable)
#endif
list_for_each_entry(pwrst, pwrst_list, node) {
- pwrst-next_state = state;
- omap_set_pwrdm_state(pwrst-pwrdm, state);
+ if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
+ pwrst-pwrdm == core_pwrdm) {
+ pwrst-next_state = PWRDM_POWER_RET;
+ pr_err(%s: cannot enable Core OFF due to i583\n,
+ __func__);
+ } else {
+ pwrst-next_state = state;
+ }
+ omap_set_pwrdm_state(pwrst-pwrdm, pwrst-next_state);
}
}
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if ES1.2
-Original Message-
From: Nishanth Menon [mailto:n...@ti.com]
Sent: Monday, December 13, 2010 8:23 PM
To: Vishwanath Sripathy
Cc: linux-omap; Eduardo Valentin; Kevin Hilman; Tony Lindgren
Subject: Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable
coreoff if ES1.2
Vishwanath Sripathy had written, on 12/13/2010 08:48 AM, the
following:
-Original Message-
From: Nishanth Menon [mailto:n...@ti.com]
Sent: Monday, December 13, 2010 8:14 PM
To: Vishwanath Sripathy
Cc: linux-omap; Eduardo Valentin; Kevin Hilman; Tony Lindgren
Subject: RE: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable
coreoff if ES1.2
-Original Message-
Vishwanath Sripathy had written, on 12/13/2010 08:25 AM, the
following:
[...]
+ if
(IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
+ (core_next_state ==
PWRDM_POWER_OFF))
{
+ pwrdm_set_next_pwrst(core_pwrdm,
PWRDM_POWER_RET);
+ core_next_state = PWRDM_POWER_RET;
+ }
Since next_state in pwrst_list (for core) is not updated, this
is
throwing
up an error Powerdomain (core_pwrdm) didn't enter target
state
0
when
you off mode is enabled for ES1.1 or lesser (in suspend
path).
It's
not
really true that Core has not entered target state. It has
entered
Retention state which is the actual target state set in
omap_sram_idle.
However it did not enter the state that was passed by
omap3_pm_suspend. Is
this expected behavior?
we could go both ways on this - this patch will(as you
noticed)
indicate
that the transition failed on ES1.2, or we could make it
entirely
transparent(by modifying the the pwrst_list - claim we
achieved
off,
while not really hitting off - I personally dont think that is
correct.
The point I am making is that you cannot distinguish between
genuine
off
/retention failure since this message is thrown for both pass
and
fail.
May be an additional trace message indicating that system
entered
retention instead of off (for ES1.2) will be useful.
hmm... good point there.
two issues here:
a) omap3_pm_suspend should probably state which state was
achieved
as
well in the error message (trivial fix).
b) how do we notify users that it was due to
SDRC_WAKEUP_ERRATUM_i583
that core-off was denied. - do this in
omap3_pm_suspend(when
user
attempts actual OFF) OR omap3_pm_off_mode_enable(when
user
attempts to
enable OFF mode)?
Any suggestions to allow the same uImage boot on all silicon +
allow
cpu_idle + suspend paths not to spew pr_info messages(aka
cant
add
prints in sram_idle)?
I vote for denying off mode for Core (for ES1.2) in
omap3_pm_off_mode_enable and throw up a message saying
that
Core off
is
not enabled. Then we will not get this failure message in suspend
path
since pwrst_list will have the right state.
Keep in mind - if we disable it in omap3_pm_off_mode_enable - we
will
deny OFF wholesale if I understand the logic right- not just
core-off
-
I kind of think that is extreme.
I take that back, we could do something like the following instead:
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-
omap2/pm34xx.c
index ba3c0d6..74842f1 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -933,7 +933,14 @@ void omap3_pm_off_mode_enable(int
enable)
list_for_each_entry(pwrst, pwrst_list, node) {
pwrst-next_state = state;
- omap_set_pwrdm_state(pwrst-pwrdm, state);
+ if
(IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
+ pwrst-pwrdm == core_pwrdm) {
+ omap_set_pwrdm_state(pwrst-pwrdm,
PWRDM_POWER_RET);
You need to update pwrst-next_state as well.
Otherwise suspend will still throw the same error. I just sent the
code
in
other email.
yep. except, I think we dont need to do string compare. the following
looks any better?
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-
omap2/pm34xx.c
index ba3c0d6..da12a56 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -932,8 +932,15 @@ void omap3_pm_off_mode_enable(int enable)
#endif
list_for_each_entry(pwrst, pwrst_list, node) {
- pwrst-next_state = state;
- omap_set_pwrdm_state(pwrst-pwrdm, state);
+ if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
+ pwrst-pwrdm == core_pwrdm) {
+ pwrst-next_state = PWRDM_POWER_RET;
+ pr_err(%s: cannot enable Core OFF due to
i583\n,
+ __func__);
You probably need to throw up this warning only if state
== PWRDM_POWER_OFF. Otherwise this code looks fine to me.
Vishwa
+ } else {
+ pwrst-next_state = state;
+
Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if ES1.2
Vishwanath Sripathy had written, on 12/13/2010 08:58 AM, the following:
[...]
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-
omap2/pm34xx.c
index ba3c0d6..da12a56 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -932,8 +932,15 @@ void omap3_pm_off_mode_enable(int enable)
#endif
list_for_each_entry(pwrst, pwrst_list, node) {
- pwrst-next_state = state;
- omap_set_pwrdm_state(pwrst-pwrdm, state);
+ if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
+ pwrst-pwrdm == core_pwrdm) {
+ pwrst-next_state = PWRDM_POWER_RET;
+ pr_err(%s: cannot enable Core OFF due to
i583\n,
+ __func__);
You probably need to throw up this warning only if state
== PWRDM_POWER_OFF. Otherwise this code looks fine to me.
Thanks for the review. added it. will post a v4 later today if no one
cribs with this approach. I will retain the logic in sram_idle as well
as a backup measure.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 10/12] OMAP: dmtimer: switch-over to platform device driver
Hi Tarun,
I'm just re-sending to a wider audience my comments.
On 12/7/2010 12:44 AM, DebBarma, Tarun Kanti wrote:
switch-over to platform device driver through following changes:
(a) call to dmtimer initialization routine from timer-gp.c is
removed (b) initiate dmtimer early initialization from omap2_init_common_hw
in io.c (c) modify plat-omap/dmtimer routines to use new register map and
platform data.
[...]
diff --git a/arch/arm/mach-omap2/dmtimer.c b/arch/arm/mach-omap2/dmtimer.c
index b639082..50509c7 100644
--- a/arch/arm/mach-omap2/dmtimer.c
+++ b/arch/arm/mach-omap2/dmtimer.c
@@ -172,3 +172,43 @@ static int __init omap_timer_init(struct omap_hwmod *oh,
void *user)
return ret;
}
+
+/**
+ * omap2_dm_timer_early_init - top level early timer initialization
+ * called in the last part of omap2_init_common_hw
+ *
+ * Uses dedicated hwmod api to parse through hwmod database for
+ * given class name and then build and register the timer device.
+ * At the end driver is registered and early probe initiated.
+ */
+void __init omap2_dm_timer_early_init(void)
+{
+ int early_init = 1; /* identify early init in omap2_timer_init() */
+ int ret = omap_hwmod_for_each_by_class(timer,
+ omap_timer_init,early_init);
+
+ if (unlikely(ret)) {
+ pr_debug(%s: device registration FAILED!\n, __func__);
+ return;
+ }
+
+ early_platform_driver_register_all(earlytimer);
+ early_platform_driver_probe(earlytimer, early_timer_count, 0);
+}
+
+/**
+ * omap2_dm_timer_init - top level timer normal device initialization
+ *
+ * Uses dedicated hwmod API to parse through hwmod database for
+ * given class names and then build and register the timer device.
+ */
+static int __init omap2_dm_timer_init(void)
+{
+ int ret = omap_hwmod_for_each_by_class(timer, omap_timer_init, NULL);
Because of this second iteration, you are creating each device twice,
and the early one is never deleted.
What should be done to avoid that and to avoid the double hwmod
iteration is:
The first hwmod iteration will create the early device and populate the
timer list, here you call the omap_device_build.
Then during the regular device init, you should not iterate again on the
hwmod list, you just have to iterate through the timer list and
call omap_device_register. That will avoid to re-allocate the internal
omap_device structures, and will simplify the code as well.
Removing the dmtimer list is probably something that will require some
hacks in the early driver code itself of potentially in the omap_device
one. This is clearly out of the scope for the series for my point of view.
Regards,
Benoit
+
+ if (unlikely(ret))
+ pr_debug(%s: device registration FAILED!\n, __func__);
+
+ return ret;
+}
+arch_initcall(omap2_dm_timer_init);
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 40562dd..e6128b5 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -46,6 +46,7 @@
#include clockdomains.h
#includeplat/omap_hwmod.h
+#include dmtimer.h
/*
* The machine specific code may provide the extra mapping besides the
@@ -352,4 +353,5 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
_omap2_init_reprogram_sdrc();
}
gpmc_init();
+ omap2_dm_timer_early_init();
}
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
index e13c29e..54fafac 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -235,7 +235,6 @@ static void __init omap2_gp_timer_init(void)
BUG_ON(!twd_base);
}
#endif
- omap_dm_timer_init();
omap2_gp_clockevent_init();
omap2_gp_clocksource_init();
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index ddc875b..ac6a498 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -159,11 +159,8 @@
(_OMAP_TIMER_TICK_INT_MASK_COUNT_OFFSET | (WP_TOWR WPSHIFT))
struct omap_dm_timer {
- unsigned long phys_base;
int irq;
-#ifdef CONFIG_ARCH_OMAP2PLUS
- struct clk *iclk, *fclk;
-#endif
+ struct clk *fclk;
void __iomem *io_base;
unsigned reserved:1;
unsigned enabled:1;
@@ -172,117 +169,25 @@ struct omap_dm_timer {
struct list_head node;
};
-static int dm_timer_count;
-
-#ifdef CONFIG_ARCH_OMAP2
-static struct omap_dm_timer omap2_dm_timers[] = {
- { .phys_base = 0x48028000, .irq = INT_24XX_GPTIMER1 },
- { .phys_base = 0x4802a000, .irq = INT_24XX_GPTIMER2 },
- { .phys_base = 0x48078000, .irq = INT_24XX_GPTIMER3 },
- { .phys_base = 0x4807a000, .irq = INT_24XX_GPTIMER4 },
- { .phys_base = 0x4807c000, .irq = INT_24XX_GPTIMER5 },
- { .phys_base = 0x4807e000, .irq = INT_24XX_GPTIMER6 },
- { .phys_base = 0x4808, .irq = INT_24XX_GPTIMER7 },
- {
Re: [PATCH 2/2] omap3: igepv2: LED gpio-led:green:d1 is active low
2010/12/12 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Make sure the LED is turned off at boot time, and configure the GPIO LED
device as active low.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
arch/arm/mach-omap2/board-igep0020.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 20b88c1..41a4b25 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -317,6 +317,7 @@ static struct gpio_led igep2_gpio_leds[] = {
.name = gpio-led:green:d1,
.default_trigger = heartbeat,
.gpio = -EINVAL, /* gets replaced */
+ .active_low = 1,
},
};
@@ -394,7 +395,7 @@ static int igep2_twl_gpio_setup(struct device *dev,
/* TWL4030_GPIO_MAX + 1 == ledB (out, active low LED) */
#if !defined(CONFIG_LEDS_GPIO) !defined(CONFIG_LEDS_GPIO_MODULE)
if ((gpio_request(gpio+TWL4030_GPIO_MAX+1, gpio-led:green:d1) == 0)
- (gpio_direction_output(gpio + TWL4030_GPIO_MAX + 1, 0) == 0))
+ (gpio_direction_output(gpio + TWL4030_GPIO_MAX + 1, 1) == 0))
gpio_export(gpio + TWL4030_GPIO_MAX + 1, 0);
else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED1_GREEN\n);
--
1.7.2.2
Acked-by: Enric Balletbo i Serra eballe...@gmail.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: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera
On 10 December 2010 17:03, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Dec 10, 2010 at 12:03:07PM +0100, Janusz Krzysztofik wrote:
void __init omap1_camera_init(void *info)
{
struct platform_device *dev = omap1_camera_device;
+ dma_addr_t paddr = omap1_camera_phys_mempool_base;
+ dma_addr_t size = omap1_camera_phys_mempool_size;
int ret;
dev-dev.platform_data = info;
+ if (paddr) {
+ if (dma_declare_coherent_memory(dev-dev, paddr, paddr, size,
+ DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE))
Although this works, you're ending up with SDRAM being mapped via
ioremap, which uses MT_DEVICE - so what is SDRAM ends up being
mapped as if it were a device.
BTW, does the generic dma_declare_coherent_memory() does the correct
thing in using ioremap()? Maybe some other function that takes a
pgprot_t would be better (ioremap_page_range) and could pass something
like pgprot_noncached (though ideally a pgprot_dmacoherent). Or just
an architecturally-defined function.
--
Catalin
--
To unsubscribe from this list: send the line unsubscribe 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: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
I wrote:
I'll see if I can draw up the ALSA-specific media stuff over the weekend.
Sorry, wrong weekend.
Anyway, below are some remarks and a patch.
* Entity types
TYPE_NODE was renamed to TYPE_DEVICE because node sounds like a node
in a graph, which does not distinguish it from other entity types
because all entities are part of the topology graph. I chose device
as this type describes entities that are visible as some device node to
other software.
TYPE_EXT describes entities that represent some interface to the
external world, TYPE_INT those that are internal to the entire device.
(I'm not sure if that distinction is very useful, but TYPE_SUBDEV seems
to be an even more meaningless name.)
ALSA mixer controls are not directly represented; a better fit for the
architecture of actual devices is that one or more mixer controls can be
associated with an entity. (This can be done with a field of the mixer
control.)
* Entity properties
There needs to be a mechanism to associate meta-information (properties)
with entities. This information should be optional and extensible, but,
when being handled inside the kernel, doesn't need to be more than
a read-only blob. I think that something like ALSA's TLV format (used
for mixer controls) can be used here. (I'm not mentioning the X-word
here, except to note that the M stands for markup.)
* Entity subtypes
EXT_JACK_ANALOG represents any analog audio and/or video connector.
Properties for audio jacks would be jack type (TRS/RCA), color code,
line level, position, etc.
EXT_JACK_DIGITAL represents a digital connector like S/PDIF (coax/
TOSLINK), ADAT, TDIF, or MADI.
EXT_JACK_BUS represents a bus like FireWire and comes from the USB audio
spec. (I doubt that any devices with this entitiy will ever exist.)
EXT_INSTRUMENT represents something like an e-guitar, keyboard, or MIDI
controller. (Instrument entities are typically audio sources and MIDI
sources and sinks, but can also be audio sinks.)
EXT_SPEAKER also includes headphones; there might be made a case for
having those as a separate subtype.
EXT_PLAYER represents a device like a CD/DVD/tape player. Recorders can
also write to that device, so player might not be an ideal name.
EXT_BROADCAST represents devices like TV tuners, satellite receivers,
cable tuners, or radios.
INT_SYNTHESIZER converts MIDI to audio.
INT_NOISE_SOURCE comes from the USB audio spec; this is not an attempt
to describe the characteristics of consumer-grade devices :-) , but
represents an internal noise source for level calibration or measurements.
INT_CONTROLS may have multiple independent controls (this is USB's
Feature Unit); INT_EFFECT may have multiple controls that affect one
single algorithm.
INT_CHANNEL_SPLIT/MERGE are needed for HDAudio devices, whose topology
information has only stereo links.
* Entity specifications
While TYPE_DEVICE entities can be identified by their device node, other
entities typcially have just a numeric ID. For that, it would be useful
to make do without separate identification and let the driver choose the
entity ID.
Signed-off-by: Clemens Ladisch clem...@ladisch.de
--- linux/include/linux/media.h
+++ linux/include/linux/media.h
@@ -46,16 +46,36 @@ struct media_device_info {
#define MEDIA_ENTITY_TYPE_MASK 0x00ff
#define MEDIA_ENTITY_SUBTYPE_MASK 0x
-#define MEDIA_ENTITY_TYPE_NODE (1 MEDIA_ENTITY_TYPE_SHIFT)
-#define MEDIA_ENTITY_TYPE_NODE_V4L (MEDIA_ENTITY_TYPE_NODE + 1)
-#define MEDIA_ENTITY_TYPE_NODE_FB (MEDIA_ENTITY_TYPE_NODE + 2)
-#define MEDIA_ENTITY_TYPE_NODE_ALSA(MEDIA_ENTITY_TYPE_NODE + 3)
-#define MEDIA_ENTITY_TYPE_NODE_DVB (MEDIA_ENTITY_TYPE_NODE + 4)
+#define MEDIA_ENTITY_TYPE_DEVICE (1 MEDIA_ENTITY_TYPE_SHIFT)
+#define MEDIA_ENTITY_TYPE_DEVICE_V4L (MEDIA_ENTITY_TYPE_DEVICE + 1)
+#define MEDIA_ENTITY_TYPE_DEVICE_FB(MEDIA_ENTITY_TYPE_DEVICE + 2)
+#define MEDIA_ENTITY_TYPE_DEVICE_DVB (MEDIA_ENTITY_TYPE_DEVICE + 3)
+#define MEDIA_ENTITY_TYPE_DEVICE_ALSA_PCM (MEDIA_ENTITY_TYPE_DEVICE + 4)
+#define MEDIA_ENTITY_TYPE_DEVICE_ALSA_MIDI (MEDIA_ENTITY_TYPE_DEVICE + 5)
-#define MEDIA_ENTITY_TYPE_SUBDEV (2 MEDIA_ENTITY_TYPE_SHIFT)
-#define MEDIA_ENTITY_TYPE_SUBDEV_SENSOR
(MEDIA_ENTITY_TYPE_SUBDEV + 1)
-#define MEDIA_ENTITY_TYPE_SUBDEV_FLASH (MEDIA_ENTITY_TYPE_SUBDEV + 2)
-#define MEDIA_ENTITY_TYPE_SUBDEV_LENS (MEDIA_ENTITY_TYPE_SUBDEV + 3)
+#define MEDIA_ENTITY_TYPE_EXT (2 MEDIA_ENTITY_TYPE_SHIFT)
+#define MEDIA_ENTITY_TYPE_EXT_SENSOR (MEDIA_ENTITY_TYPE_EXT + 1)
+#define MEDIA_ENTITY_TYPE_EXT_FLASH(MEDIA_ENTITY_TYPE_EXT + 2)
+#define MEDIA_ENTITY_TYPE_EXT_LENS (MEDIA_ENTITY_TYPE_EXT + 3)
+#define MEDIA_ENTITY_TYPE_EXT_JACK_MIDI(MEDIA_ENTITY_TYPE_EXT
+ 4)
+#define
Re: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera
On Mon, Dec 13, 2010 at 03:52:20PM +, Catalin Marinas wrote:
On 10 December 2010 17:03, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Dec 10, 2010 at 12:03:07PM +0100, Janusz Krzysztofik wrote:
void __init omap1_camera_init(void *info)
{
struct platform_device *dev = omap1_camera_device;
+ dma_addr_t paddr = omap1_camera_phys_mempool_base;
+ dma_addr_t size = omap1_camera_phys_mempool_size;
int ret;
dev-dev.platform_data = info;
+ if (paddr) {
+ if (dma_declare_coherent_memory(dev-dev, paddr, paddr,
size,
+ DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE))
Although this works, you're ending up with SDRAM being mapped via
ioremap, which uses MT_DEVICE - so what is SDRAM ends up being
mapped as if it were a device.
BTW, does the generic dma_declare_coherent_memory() does the correct
thing in using ioremap()?
I argue it doesn't, as I said above. It means we map SDRAM as device
memory, and as I understand the way interconnects work, it's entirely
possible that this may not result in the SDRAM being accessible.
Maybe some other function that takes a
pgprot_t would be better (ioremap_page_range) and could pass something
like pgprot_noncached (though ideally a pgprot_dmacoherent). Or just
an architecturally-defined function.
This API was designed in the ARMv5 days when things were a lot simpler.
What we now have is rather messy though, and really needs sorting out
before we get too many users of it. (Arguably it should never have been
accepted in its current state.)
We have a rule that the returned value of ioremap() is not to be used
as a pointer which can be dereferenced by anything except driver code.
Yet this is exactly what dma_declare_coherent_memory() does:
struct dma_coherent_mem {
void*virt_base;
...
};
int dma_declare_coherent_memory(struct device *dev, dma_addr_t bus_addr,
dma_addr_t device_addr, size_t size, int flags)
{
void __iomem *mem_base = NULL;
mem_base = ioremap(bus_addr, size);
dev-dma_mem-virt_base = mem_base;
}
int dma_alloc_from_coherent(struct device *dev, ssize_t size,
dma_addr_t *dma_handle, void **ret)
{
*ret = mem-virt_base + (pageno PAGE_SHIFT);
}
and drivers expect the returned value from dma_alloc_coherent() to be
dereferenceable.
Note that this also fails sparse checking. It will fail on any
architecture where the return value from ioremap() is not a virtual
address.
So, not only does this fail the kernel's own rules, but as we already know,
it fails the architecture's restrictions with multiple mappings of memory
when used with SDRAM, and it also maps main memory as a device. I wonder
how many more things this broken API needs to do wrong before it's current
implementation is consigned to the circular filing cabinet.
--
To unsubscribe from this list: send the line unsubscribe 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: Inconsistent lock state caused by omap_mbox_msg_send() called from tidspbridge
Hi Ionut and Ohad, On Sunday 12 December 2010 15:22:38 Ohad Ben-Cohen wrote: On Sun, Dec 12, 2010 at 4:15 PM, Ionut Nicu ionut.n...@mindbit.ro wrote: I noticed this too, but this patch should fix it: https://patchwork.kernel.org/patch/365292/ True. And in this patch the move to spin_lock_bh() is justifiable, too, since it adds a sending path which is parallel to the mailbox tasklet. Is this patch set ready for inclusion in the mainline kernel, or does it need to be reworked ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REPOST][PATCH] Fix IGEPv2 second MMC channel power supply
Hi all,
2010/12/4 Marc Zyngier m...@misterjones.org:
Commit 72f381ba056 (omap3: Remove VMMC2 regulator on IGEP v2)
removed an unused regulator entry, but left the second MMC channel
(used by the Libertas WLAN module) without link to power regulator.
This causes the SDIO module to fail being detected.
This patch adds the two regulators that actually feed the WLAN module
(1v8 from the TWL4030 VIO LDO, and a fixed 3v3). With that patch, the
second channel is properly detected. Details of the power supply
implementation were kindly provided by Enric Balletbo i Serra.
Also change vmmc1 to use symbolic names instead of direct device
reference.
Tested on an IGEPv2 Rev-B.
Signed-off-by: Marc Zyngier m...@misterjones.org
Acked-by: Enric Balletbo i Serra eballe...@gmail.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-igep0020.c | 61 -
1 files changed, 51 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 5e035a5..9a85e60 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -19,6 +19,7 @@
#include linux/interrupt.h
#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
#include linux/i2c/twl.h
#include linux/mmc/host.h
@@ -257,9 +258,8 @@ static inline void __init igep2_init_smsc911x(void) { }
static struct omap_board_config_kernel igep2_config[] __initdata = {
};
-static struct regulator_consumer_supply igep2_vmmc1_supply = {
- .supply = vmmc,
-};
+static struct regulator_consumer_supply igep2_vmmc1_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.0);
/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
static struct regulator_init_data igep2_vmmc1 = {
@@ -276,6 +276,52 @@ static struct regulator_init_data igep2_vmmc1 = {
.consumer_supplies = igep2_vmmc1_supply,
};
+static struct regulator_consumer_supply igep2_vio_supply =
+ REGULATOR_SUPPLY(vmmc_aux, mmci-omap-hs.1);
+
+static struct regulator_init_data igep2_vio = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = 1,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = igep2_vio_supply,
+};
+
+static struct regulator_consumer_supply igep2_vmmc2_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1);
+
+static struct regulator_init_data igep2_vmmc2 = {
+ .constraints = {
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .always_on = 1,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = igep2_vmmc2_supply,
+};
+
+static struct fixed_voltage_config igep2_vwlan = {
+ .supply_name = vwlan,
+ .microvolts = 330,
+ .gpio = -EINVAL,
+ .enabled_at_boot = 1,
+ .init_data = igep2_vmmc2,
+};
+
+static struct platform_device igep2_vwlan_device = {
+ .name = reg-fixed-voltage,
+ .id = 0,
+ .dev = {
+ .platform_data = igep2_vwlan,
+ },
+};
+
static struct omap2_hsmmc_info mmc[] = {
{
.mmc = 1,
@@ -373,12 +419,6 @@ static int igep2_twl_gpio_setup(struct device *dev,
omap2_hsmmc_init(mmc);
/*
- * link regulators to MMC adapters ... we know the
- * regulators will be set up only *after* we return.
- */
- igep2_vmmc1_supply.dev = mmc[0].dev;
-
- /*
* REVISIT: need ehci-omap hooks for external VBUS
* power switch and overcurrent detect
*/
@@ -489,6 +529,7 @@ static void __init igep2_display_init(void)
static struct platform_device *igep2_devices[] __initdata = {
igep2_dss_device,
+ igep2_vwlan_device,
};
static void __init igep2_init_irq(void)
@@ -519,7 +560,7 @@ static struct twl4030_platform_data igep2_twldata = {
.gpio = igep2_twl4030_gpio_pdata,
.vmmc1 = igep2_vmmc1,
.vpll2 = igep2_vpll2,
-
+ .vio = igep2_vio,
};
static struct i2c_board_info __initdata igep2_i2c1_boardinfo[] = {
--
1.7.3.2
Tony, please can this patch be included before 2.6.37 ? Without this
patch the wifi module on IGEP v2 board not works.
Thanks,
Enric Balletbo i Serra.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the
OMAP3 DSP baseimage with SYS_printf support
Hi, I've been trying to get SYS_printf working on the DSP, with no luck so far. I'm using the dspbridge driver from 2.6.37-rc5, with the CONFIG_TIDSPBRIDGE_DEBUG option enabled. Dynamic binaries calling SYS_printf can be loaded correctly, but nothing is printed in the Linux kerne log. I've been told I need to get SYS_printf support compiled in baseimage.dof. As far as I can tell, baseimage.dof is distributed publicly under binary form only. Is that correct, or are the sources available somewhere ? I've tried the baseimage.dof binaries from https://gforge.ti.com/gf/download/frsrelease/285/3260/DSPbinaries-3.09-Linux- x86-Install, https://gforge.ti.com/gf/download/frsrelease/352/3680/TI_DSPbinaries_RLS23.i3.8-3.12- Linux-x86-Install and https://gforge.ti.com/gf/download/frsrelease/282/3244/TI_DSP_Binaries_Android_RLS25.14M.3.tar.bz2. If the baseimage.dof sources are not publicly available, does anyone know if TI plans to provide a binary version with SYS_printf support enabled ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/9] TILER-DMM: Main TILER driver implementation
On Mon, Dec 06, 2010 at 03:21:59PM -0800, Tony Lindgren wrote: Hi, * David Sin david...@ti.com [101206 14:09]: From: Lajos Molnar mol...@ti.com This patch contains the TILER driver and implementation of the TILER block manipulation and mapping functions. It also contains the makefile and config file for the TILER driver. ... +config TILER_GRANULARITY +int Allocation granularity +range 1 4096 +default 128 ... +config TILER_ALIGNMENT +int Allocation alignment +range 1 4096 +default 4096 ... +config TILER_CACHE_LIMIT +int Memory limit to cache free pages in MBytes +range 0 128 +default 40 ... Do you really need these Kconfig options? To me it seems you should pass these in platform_data. Regards, Tony Hi Tony, No -- we don't really need these here, but we thought that it would be an easy way for the user to set them -- esp the CACHE_LIMIT. We can actually remove themi, since it's not going to change very often, and add it to plat data later. I'll revise the patch. BTW, Are you going to be the one to merge this code? Regards, -- David Sin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] ARM: GIC: cleanup
Sorry for being late on testing this out. The patch series and works on the msm 8660. Acked-By: Abhijeet Dharmapurikar adhar...@codeaurora.org Russell King - ARM Linux wrote: This patch series cleans up the GIC code, consolidating some of the per-platform practices into the common GIC code. One notable change is to the initialization methods - we used to require platforms to pass in the address of the per-CPU interfaces despite them always being identical between all cores. This was nonsense, as even in the extremely unlikely event that they were different, we aren't storing them in a per-CPU manner. The GIC initialization methods are now simpler: one call to gic_init() from the boot CPU, and a call to gic_secondary_init() as each secondary CPU starts - and no need for platforms to keep track of the address anymore. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] OMAP: mailbox and iommu changes: for-next for v2.6.38
On Sun, Dec 12, 2010 at 5:20 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Dec 06, 2010 at 09:16:23AM -0600, Kanigeri, Hari wrote: Ruseell, On Thu, Dec 2, 2010 at 9:43 AM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Thu, Dec 2, 2010 at 9:20 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Dec 02, 2010 at 08:50:07AM -0600, Guzman Lugo, Fernando wrote: On Thu, Dec 2, 2010 at 6:33 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Dec 02, 2010 at 06:07:23AM -0600, Kanigeri, Hari wrote: Hi Tony, The following changes since commit e8a7e48bb248a1196484d3f8afa53bded2b24e71: Linus Torvalds (1): Linux 2.6.37-rc4 are available in the git repository at: git://gitorious.org/iommu_mailbox/iommu_mailbox.git for_2.6.38 Fernando Guzman Lugo (5): OMAP: mailbox: change full flag per mailbox queue instead of global omap: iovmm - no gap checking for fixed address omap: iovmm - add superpages support to fixed da address omap: iovmm - replace __iounmap with omap_iounmap This change is wrong. Nothing should be directly referencing omap_iounmap nor for that matter omap_ioremap. Both are implementation details of the standard ioremap/iounmap APIs. Use the official APIs rather than the implementation details behind them. if you see where the function is used, you will see that it is not calling the function, it is use as a parameter in unmap_vm_area(), if I used iounmap which is a macro there I will get a compilation error. Hmm, yes, because iounmap() is defined as a macro rather than iounmap. The solution to this is to fix iounmap and __arch_iounmap macros so they aren't macros which take arguments. That will then allow them to be used in the way you desire. yes, that way it can be used in the function parameter. what is the right thing to do? 1) You send your patch and then I send the new version of the patches. 2) I make a new series of the patches with the change to iounmap and I include your patch in the series. Can you please suggest the approach we take here ? So, either you send your suggested change as a patch and Fernando's patch will be based on it, or he can take a TODO action item to patch again if you plan to send this change later. Right, the patches are in my git tree, under the 'io' branch: http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm.git io which you can use to base stuff off of. Make sure your tree has commits up to 2.6.37-rc5 before pulling to avoid grabbing MB's of pack files. Thanks, Russell. Fernando, can you please rebase your patches based on Russell's patch. I will take care of queuing up the patches for git pull request. Thank you, Best regards, Hari Kanigeri -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] ARM: GIC: cleanup
On Mon, Dec 13, 2010 at 09:23:29AM -0800, Abhijeet Dharmapurikar wrote: Sorry for being late on testing this out. The patch series and works on the msm 8660. Acked-By: Abhijeet Dharmapurikar adhar...@codeaurora.org Would you prefer a Tested-by: ? -- To unsubscribe from this list: send the line unsubscribe 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] OMAP: omap_device: use pdev as parameter to get rt_va
Hi Benoit, On Mon, Dec 13, 2010 at 2:12 AM, Cousson, Benoit b-cous...@ti.com wrote: Hi Omar, On 12/11/2010 12:45 AM, Ramirez Luna, Omar wrote: Make the parameter received by omap_device_get_mpu_rt_va consistent with the functions meant to be called by drivers. Also move its header declaration to appear in the set of functions to be used by drivers, as per the comment there. Please note that even if Paul submitted this API upon request from Santosh, we do not want driver to us it most of the time. Oh, ok. Yes, I was under the impression that this ioremap was internal to hwmod, and drivers should do their own one; but then I noticed that API and since it was under the public functions through struct platform data, I thought it was easier to pass pdev than od. All drivers should us the generic Linux way to get physical mem resource and then ioremap it. Then I guess this function belongs to the public for core code and not for drivers along with the omap_device_get_pwrdm. I assume that if you want to update this API, you are probably already using it. Why cannot you use the generic way? I can leave the generic way along with ioremap, the purpose was to use omap_device APIs as much as possible. Thanks, Omar -- To unsubscribe from this list: send the line unsubscribe 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 5/5] OMAP: mailbox: add omap_device latency information
- mbox_ick_handle = clk_get(NULL, mailboxes_ick);
- if (IS_ERR(mbox_ick_handle)) {
- printk(KERN_ERR Could not get mailboxes_ick: %ld\n,
- PTR_ERR(mbox_ick_handle));
- return PTR_ERR(mbox_ick_handle);
- }
- clk_enable(mbox_ick_handle);
+ pm_runtime_get_sync(mbox_pdev-dev);
Might be good to check the return value.
Thank you,
Best regards,
Hari Kanigeri
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap: update mach-types for rm680
* Anand Gadiyar gadi...@ti.com [101213 02:46]: Temporary hack to update mach-types for rm680; without this the master branch of linux-omap will be broken for omap2plus_defconfig builds. Nyet-Signed-off-by: Anand Gadiyar gadi...@ti.com --- Tony, Not sure how this is handled normally. Do you sync up mach-types with Russell's tree, or locally apply a patch like the one below? Oops, thanks for catching that. I'll add this to omap-testing as a temporary patch so it will get merged to the master branch. Tony arch/arm/tools/mach-types |1 + 1 file changed, 1 insertion(+) Index: ehci/arch/arm/tools/mach-types === --- ehci.orig/arch/arm/tools/mach-types +++ ehci/arch/arm/tools/mach-types @@ -3044,3 +3044,4 @@ harvest_desoto MACH_HARVEST_DESOTO HARV msm8x60_qrdc MACH_MSM8X60_QRDC MSM8X60_QRDC3060 spear900 MACH_SPEAR900 SPEAR9003061 pcontrol_g20 MACH_PCONTROL_G20 PCONTROL_G203062 +nokia_rm680 MACH_NOKIA_RM680NOKIA_RM680 3220 -- To unsubscribe from this list: send the line unsubscribe 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/24] Update clocksource registration
John Stultz notes in his commit: clocksource: Add clocksource_register_hz/khz interface How to pick good mult/shift pairs has always been difficult to describe to folks writing clocksource drivers, since it requires careful tradeoffs in adjustment accuracy vs overflow limits. Now, with the clocks_calc_mult_shift function, its much easier. However, not many clocksources have converted to using that function, and there is still the issue of the max interval length assumption being made by each clocksource driver independently. So this patch simplifies the registration process by having clocksources be registered with a hz/khz value and the registration function taking care of setting mult/shift. This should take most of the confusion out of writing a clocksource driver. Additionally it also keeps the shift size tradeoff (more accuracy vs longer possible nohz times) centralized so the timekeeping core can keep track of the assumptions being made. This patch series updates all ARM platforms clocksource registration to use the new clocksource_register_hz()/clocksource_register_khz() functions, simplifying the selection of the multiply/shift constants. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/24] ARM: omap: update clock source registration
In d7e81c2 (clocksource: Add clocksource_register_hz/khz interface) new
interfaces were added which simplify (and optimize) the selection of the
divisor shift/mult constants. Switch over to using this new interface.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-omap1/time.c |6 +-
arch/arm/mach-omap2/timer-gp.c |5 +
arch/arm/plat-omap/counter_32k.c |6 +-
3 files changed, 3 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
index 1be6a21..abb34ff 100644
--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -208,7 +208,6 @@ static struct clocksource clocksource_mpu = {
.rating = 300,
.read = mpu_read,
.mask = CLOCKSOURCE_MASK(32),
- .shift = 24,
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
};
@@ -217,13 +216,10 @@ static void __init omap_init_clocksource(unsigned long
rate)
static char err[] __initdata = KERN_ERR
%s: can't register clocksource!\n;
- clocksource_mpu.mult
- = clocksource_khz2mult(rate/1000, clocksource_mpu.shift);
-
setup_irq(INT_TIMER2, omap_mpu_timer2_irq);
omap_mpu_timer_start(1, ~0, 1);
- if (clocksource_register(clocksource_mpu))
+ if (clocksource_register_hz(clocksource_mpu, rate))
printk(err, clocksource_mpu.name);
}
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
index e13c29e..a7816db 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -195,7 +195,6 @@ static struct clocksource clocksource_gpt = {
.rating = 300,
.read = clocksource_read_cycles,
.mask = CLOCKSOURCE_MASK(32),
- .shift = 24,
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
};
@@ -220,9 +219,7 @@ static void __init omap2_gp_clocksource_init(void)
omap_dm_timer_set_load_start(gpt, 1, 0);
- clocksource_gpt.mult =
- clocksource_khz2mult(tick_rate/1000, clocksource_gpt.shift);
- if (clocksource_register(clocksource_gpt))
+ if (clocksource_register_hz(clocksource_gpt, tick_rate))
printk(err2, clocksource_gpt.name);
}
#endif
diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
index 155fe43..8f149f5 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -102,7 +102,6 @@ static struct clocksource clocksource_32k = {
.rating = 250,
.read = omap_32k_read_dummy,
.mask = CLOCKSOURCE_MASK(32),
- .shift = 10,
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
};
@@ -167,12 +166,9 @@ static int __init omap_init_clocksource_32k(void)
if (sync_32k_ick)
clk_enable(sync_32k_ick);
- clocksource_32k.mult = clocksource_hz2mult(32768,
- clocksource_32k.shift);
-
offset_32k = clocksource_32k.read(clocksource_32k);
- if (clocksource_register(clocksource_32k))
+ if (clocksource_register_hz(clocksource_32k, 32768))
printk(err, clocksource_32k.name);
}
return 0;
--
1.6.2.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
[GIT PULL] omap fixes for v2.6.37-rc5
Hi Linus, Please pull what should be the last set of omap specific fixes for this -rc cycle: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus The main fixes are to make PM code to compile without CONFIG_DEBUG_FS, and a fix for the console for suspend. The first patch just moves some code around. The second patch adds checks for suspend to the recent fix 0d8e2d0dad98a693bad88aea6876ac8b94ad95c6 (OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled). Again, this will eventually be handled by runtime PM but that's not suitable for the -rc series. The rest are trivial fixes for for some board specific issues, and to handle clk_get values with IS_ERR. Regards, Tony The following changes since commit cf7d7e5a1980d1116ee152d25dac382b112b9c17: Linux 2.6.37-rc5 (2010-12-06 20:09:04 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus Aaro Koskinen (1): arm: omap2: io: fix clk_get() error check Kevin Hilman (3): omap: PM debug: fix wake-on-timer debugfs dependency OMAP1: SRAM: fix size for OMAP1611 SoCs OMAP2+: PM/serial: fix console semaphore acquire during suspend Ohad Ben-Cohen (1): omap: zoom: wl1271 slot is MMC_CAP_POWER_OFF_CARD Paul Walmsley (1): OMAP2: PRCM: fix some SHIFT macros that were actually bitmasks Sukumar Ghorai (1): omap: nand: remove hardware ECC as default Vasiliy Kulikov (1): arm: plat-omap: counter_32k: use IS_ERR() instead of NULL check arch/arm/mach-omap2/board-zoom-peripherals.c |2 +- arch/arm/mach-omap2/io.c |2 +- arch/arm/mach-omap2/pm-debug.c | 34 +- arch/arm/mach-omap2/pm24xx.c | 34 +++-- arch/arm/mach-omap2/pm34xx.c | 27 +++- arch/arm/mach-omap2/prcm-common.h| 11 arch/arm/plat-omap/counter_32k.c |3 +- arch/arm/plat-omap/sram.c|2 +- drivers/mtd/nand/omap2.c |1 - 9 files changed, 79 insertions(+), 37 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/RFC 2/2] OMAP: PM: implement context loss count APIs
Vishwa On Mon, 13 Dec 2010, Vishwanath Sripathy wrote: I have no issues with the implementation and I agree. All I am saying is that why can't this implementation be added in omap-pm.c and compile this file instead of omap-pm-noop.c 1. because omap-pm-noop.c needs to not actively break anything when it is used, and this function, unlike most of the other functions in omap-pm-noop.c, has no valid 'no-op' failure mode; and 2. because no one has yet posted a complete, clean, working, SRF-free OMAP PM layer to the lists. It was the hope several years ago when this interface was created that someone else would be capable of doing this. when OMAP_PM is enabled. What is this OMAP_PM that you are referring to? I believe this function is useful when off mode is enabled which means OMAP_PM is enabled. Huh? Mainline Linux on OMAP can enter off-mode with omap2plus_defconfig right now via a runtime debugfs setting. There is no KConfig setting to enable. - 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: [REPOST][PATCH] Fix IGEPv2 second MMC channel power supply
* Enric Balletbò i Serra eballe...@gmail.com [101213 08:47]: Tony, please can this patch be included before 2.6.37 ? Without this patch the wifi module on IGEP v2 board not works. Sorry it's too much for the -rc series. For the -rc series the fixes should be major bugs. This is in the category it never worked before. I will add it to omap-boards branch for the next merge window over the next few days while going through all the pending patches in patchwork. Cheers, 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: Inconsistent lock state caused by omap_mbox_msg_send() called from tidspbridge
On Mon, Dec 13, 2010 at 6:45 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com On Sun, Dec 12, 2010 at 4:15 PM, Ionut Nicu ionut.n...@mindbit.ro wrote: I noticed this too, but this patch should fix it: https://patchwork.kernel.org/patch/365292/ True. And in this patch the move to spin_lock_bh() is justifiable, too, since it adds a sending path which is parallel to the mailbox tasklet. Is this patch set ready for inclusion in the mainline kernel, or does it need to be reworked ? Better let Hari answer this one. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe 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: Inconsistent lock state caused by omap_mbox_msg_send() called from tidspbridge
On Mon, Dec 13, 2010 at 2:49 PM, Ohad Ben-Cohen o...@wizery.com wrote: On Mon, Dec 13, 2010 at 6:45 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com On Sun, Dec 12, 2010 at 4:15 PM, Ionut Nicu ionut.n...@mindbit.ro wrote: I noticed this too, but this patch should fix it: https://patchwork.kernel.org/patch/365292/ True. And in this patch the move to spin_lock_bh() is justifiable, too, since it adds a sending path which is parallel to the mailbox tasklet. Is this patch set ready for inclusion in the mainline kernel, or does it need to be reworked ? Better let Hari answer this one. Yes, it is set to go into mainline kernel. Thank you, Best regards, Hari Kanigeri -- To unsubscribe from this list: send the line unsubscribe 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/5] OMAP34: Fixes in setup/suspend/powerdomain
Hi Paul, This is a series of fixes on OMAP3/4 in setup apis, in the suspend framework and in powerdomain modelling for OMAP4. The series is based on your power domain series and is available here: git://gitorious.org/omap-pm/linux.git for_2.6.38/power Tested on 4430sdp + ES2.0 with omap2plus_defconfig. Tested on 3430sdp - validate OFF in suspend, with omap3_pm_defconfig from Kevin's tree. Tested on 2430sdp after fixing the break on linux-omap master. See http://www.spinics.net/lists/linux-omap/msg42050.html Regards, Rajendra, Santosh Benoit Rajendra Nayak (3): OMAP4: PM: Use the lowpwrstatechange feature on OMAP4 OMAP4: PM: Do not assume clkdm supports hw transitions OMAP4: powerdomain: l4per pwrdm does not support OFF Santosh Shilimkar (2): OMAP4: powerdomain: Remove L3INIT_PD OFF state OMAP4: clock data: Keep L3INSTR clock domain modulemode under HW control arch/arm/mach-omap2/clock44xx_data.c|3 +++ arch/arm/mach-omap2/pm.c| 16 +--- arch/arm/mach-omap2/powerdomains44xx_data.c |4 ++-- 3 files changed, 18 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] OMAP4: PM: Use the lowpwrstatechange feature on OMAP4
From: Rajendra Nayak rna...@ti.com
For pwrdm's which support lowperstatechange, do not try waking
up the domain to put it back to deeper sleep state.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/pm.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index cf1c4c9..dc68044 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -114,6 +114,14 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32
state)
return ret;
if (pwrdm_read_pwrst(pwrdm) PWRDM_POWER_ON) {
+ if ((pwrdm_read_pwrst(pwrdm) state)
+ (pwrdm-flags PWRDM_HAS_LOWPOWERSTATECHANGE)) {
+ ret = pwrdm_set_next_pwrst(pwrdm, state);
+ pwrdm_set_lowpwrstchange(pwrdm);
+ pwrdm_wait_transition(pwrdm);
+ pwrdm_state_switch(pwrdm);
+ return ret;
+ }
omap2_clkdm_wakeup(pwrdm-pwrdm_clkdms[0]);
sleep_switch = 1;
pwrdm_wait_transition(pwrdm);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] OMAP4: powerdomain: Remove L3INIT_PD OFF state
From: Santosh Shilimkar santosh.shilim...@ti.com
On OMAP4, there is an issue when L3INIT transitions to OFF mode without
device OFF. The SAR restore mechanism will not get triggered without
wakeup from device OFF and hence the USB host and USB TLL context
will not be restored.
Hardware team recommended to remove the OFF state support for L3INIT_PD
since there is no power impact. It will be removed on next OMAP revision
(OMAP4440 and beyond).
Hence this patch removed the OFF state from L3INIT_PD. The deepest
state supported on L3INIT_PD is OSWR just like CORE_PD and PER_PD
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[b-cous...@ti.com: update the changelog with next OMAP info]
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/powerdomains44xx_data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c
b/arch/arm/mach-omap2/powerdomains44xx_data.c
index cec9c09..26d7641 100644
--- a/arch/arm/mach-omap2/powerdomains44xx_data.c
+++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
@@ -267,7 +267,7 @@ static struct powerdomain l3init_44xx_pwrdm = {
.prcm_offs= OMAP4430_PRM_L3INIT_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts = PWRSTS_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 1,
.pwrsts_mem_ret = {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] OMAP4: PM: Do not assume clkdm supports hw transitions
From: Rajendra Nayak rna...@ti.com
omap_set_pwrdm_state today assumes a clkdm supports hw_auto
transitions and hence leaves some which do not support this
in sw wkup state preventing low power transitions.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/pm.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index dc68044..a2a70e1 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -91,8 +91,7 @@ static void omap2_init_processor_devices(void)
/*
* This sets pwrdm state (other than mpu core. Currently only ON
- * RET are supported. Function is assuming that clkdm doesn't have
- * hw_sup mode enabled.
+ * RET are supported.
*/
int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state)
{
@@ -135,7 +134,10 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32
state)
}
if (sleep_switch) {
- omap2_clkdm_allow_idle(pwrdm-pwrdm_clkdms[0]);
+ if (pwrdm-pwrdm_clkdms[0]-flags CLKDM_CAN_ENABLE_AUTO)
+ omap2_clkdm_allow_idle(pwrdm-pwrdm_clkdms[0]);
+ else
+ omap2_clkdm_sleep(pwrdm-pwrdm_clkdms[0]);
pwrdm_wait_transition(pwrdm);
pwrdm_state_switch(pwrdm);
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] OMAP4: powerdomain: l4per pwrdm does not support OFF
From: Rajendra Nayak rna...@ti.com
The l4per power domain in ES2.0 does support only RET and ON states.
The previous ES1.0 HW database was wrong and thus fixed on ES2.
Change the pwrsts field to reflect that.
Signed-off-by: Rajendra Nayak rna...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/powerdomains44xx_data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c
b/arch/arm/mach-omap2/powerdomains44xx_data.c
index 5fdf485..cec9c09 100644
--- a/arch/arm/mach-omap2/powerdomains44xx_data.c
+++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
@@ -285,7 +285,7 @@ static struct powerdomain l4per_44xx_pwrdm = {
.prcm_offs= OMAP4430_PRM_L4PER_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts = PWRSTS_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 2,
.pwrsts_mem_ret = {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] OMAP4: clock data: Keep L3INSTR clock domain modulemode under HW control
From: Santosh Shilimkar santosh.shilim...@ti.com
L3INSTR clock domain is read only register and its reset value is
HW_AUTO. The modules withing this clock domain needs to be kept under
hardware control.
MODULEMODE:
- 0x0: Module is disable by software. Any INTRCONN access to module
results in an error, except if resulting from a module wakeup
(asynchronous wakeup).
- 0x1: Module is managed automatically by hardware according to
clock domain transition. A clock domain sleep transition put
module into idle. A wakeup domain transition put it back
into function. If CLKTRCTRL=3, any INTRCONN access to module
is always granted. Module clocks may be gated according to
the clock domain state.
This patch keeps CM_L3INSTR_L3_3_CLKCTRL, CM_L3INSTR_L3_INSTR_CLKCTRL
and CM_L3INSTR_INTRCONN_WP1_CLKCTRL module mode under hardware control
by using ENABLE_ON_INIT flag.
Without this the OMAP4 device OFF mode SAR restore phase aborts during
interconnect register restore phase. This can be also handled by doing
explicit a clock enable and disable in the low power code since there
is no direct module associated with it. But that seems not necessary
since the clock domain is under HW control.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 76e900b..a72f6ab 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -1755,6 +1755,7 @@ static struct clk l3_instr_ick = {
.enable_reg = OMAP4430_CM_L3INSTR_L3_INSTR_CLKCTRL,
.enable_bit = OMAP4430_MODULEMODE_HWCTRL,
.clkdm_name = l3_instr_clkdm,
+ .flags = ENABLE_ON_INIT,
.parent = l3_div_ck,
.recalc = followparent_recalc,
};
@@ -1765,6 +1766,7 @@ static struct clk l3_main_3_ick = {
.enable_reg = OMAP4430_CM_L3INSTR_L3_3_CLKCTRL,
.enable_bit = OMAP4430_MODULEMODE_HWCTRL,
.clkdm_name = l3_instr_clkdm,
+ .flags = ENABLE_ON_INIT,
.parent = l3_div_ck,
.recalc = followparent_recalc,
};
@@ -2069,6 +2071,7 @@ static struct clk ocp_wp_noc_ick = {
.enable_reg = OMAP4430_CM_L3INSTR_OCP_WP1_CLKCTRL,
.enable_bit = OMAP4430_MODULEMODE_HWCTRL,
.clkdm_name = l3_instr_clkdm,
+ .flags = ENABLE_ON_INIT,
.parent = l3_div_ck,
.recalc = followparent_recalc,
};
--
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: [GIT PULL] OMAP: mailbox and iommu changes: for-next for v2.6.38
On Mon, Dec 13, 2010 at 11:31 AM, Kanigeri, Hari h-kanige...@ti.com wrote: On Sun, Dec 12, 2010 at 5:20 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Dec 06, 2010 at 09:16:23AM -0600, Kanigeri, Hari wrote: Ruseell, On Thu, Dec 2, 2010 at 9:43 AM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Thu, Dec 2, 2010 at 9:20 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Dec 02, 2010 at 08:50:07AM -0600, Guzman Lugo, Fernando wrote: On Thu, Dec 2, 2010 at 6:33 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Dec 02, 2010 at 06:07:23AM -0600, Kanigeri, Hari wrote: Hi Tony, The following changes since commit e8a7e48bb248a1196484d3f8afa53bded2b24e71: Linus Torvalds (1): Linux 2.6.37-rc4 are available in the git repository at: git://gitorious.org/iommu_mailbox/iommu_mailbox.git for_2.6.38 Fernando Guzman Lugo (5): OMAP: mailbox: change full flag per mailbox queue instead of global omap: iovmm - no gap checking for fixed address omap: iovmm - add superpages support to fixed da address omap: iovmm - replace __iounmap with omap_iounmap This change is wrong. Nothing should be directly referencing omap_iounmap nor for that matter omap_ioremap. Both are implementation details of the standard ioremap/iounmap APIs. Use the official APIs rather than the implementation details behind them. if you see where the function is used, you will see that it is not calling the function, it is use as a parameter in unmap_vm_area(), if I used iounmap which is a macro there I will get a compilation error. Hmm, yes, because iounmap() is defined as a macro rather than iounmap. The solution to this is to fix iounmap and __arch_iounmap macros so they aren't macros which take arguments. That will then allow them to be used in the way you desire. yes, that way it can be used in the function parameter. what is the right thing to do? 1) You send your patch and then I send the new version of the patches. 2) I make a new series of the patches with the change to iounmap and I include your patch in the series. Can you please suggest the approach we take here ? So, either you send your suggested change as a patch and Fernando's patch will be based on it, or he can take a TODO action item to patch again if you plan to send this change later. Right, the patches are in my git tree, under the 'io' branch: http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm.git io I tried to clone it but after sometime it fails, I tried to used git:// but it did not work and know behind a http proxy it is getting The requested URL returned error: 500 do someone know if I need something special to clone it? Regards, Fernando. which you can use to base stuff off of. Make sure your tree has commits up to 2.6.37-rc5 before pulling to avoid grabbing MB's of pack files. Thanks, Russell. Fernando, can you please rebase your patches based on Russell's patch. I will take care of queuing up the patches for git pull request. Thank you, Best regards, Hari Kanigeri -- To unsubscribe from this list: send the line unsubscribe 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] OMAP: mailbox and iommu changes: for-next for v2.6.38
On Mon, Dec 13, 2010 at 05:02:12PM -0600, Guzman Lugo, Fernando wrote: On Mon, Dec 13, 2010 at 11:31 AM, Kanigeri, Hari h-kanige...@ti.com wrote: On Sun, Dec 12, 2010 at 5:20 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Dec 06, 2010 at 09:16:23AM -0600, Kanigeri, Hari wrote: Ruseell, On Thu, Dec 2, 2010 at 9:43 AM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Thu, Dec 2, 2010 at 9:20 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Dec 02, 2010 at 08:50:07AM -0600, Guzman Lugo, Fernando wrote: On Thu, Dec 2, 2010 at 6:33 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Dec 02, 2010 at 06:07:23AM -0600, Kanigeri, Hari wrote: Hi Tony, The following changes since commit e8a7e48bb248a1196484d3f8afa53bded2b24e71: Linus Torvalds (1): Linux 2.6.37-rc4 are available in the git repository at: git://gitorious.org/iommu_mailbox/iommu_mailbox.git for_2.6.38 Fernando Guzman Lugo (5): OMAP: mailbox: change full flag per mailbox queue instead of global omap: iovmm - no gap checking for fixed address omap: iovmm - add superpages support to fixed da address omap: iovmm - replace __iounmap with omap_iounmap This change is wrong. Nothing should be directly referencing omap_iounmap nor for that matter omap_ioremap. Both are implementation details of the standard ioremap/iounmap APIs. Use the official APIs rather than the implementation details behind them. if you see where the function is used, you will see that it is not calling the function, it is use as a parameter in unmap_vm_area(), if I used iounmap which is a macro there I will get a compilation error. Hmm, yes, because iounmap() is defined as a macro rather than iounmap. The solution to this is to fix iounmap and __arch_iounmap macros so they aren't macros which take arguments. That will then allow them to be used in the way you desire. yes, that way it can be used in the function parameter. what is the right thing to do? 1) You send your patch and then I send the new version of the patches. 2) I make a new series of the patches with the change to iounmap and I include your patch in the series. Can you please suggest the approach we take here ? So, either you send your suggested change as a patch and Fernando's patch will be based on it, or he can take a TODO action item to patch again if you plan to send this change later. Right, the patches are in my git tree, under the 'io' branch: http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm.git io I tried to clone it but after sometime it fails, I tried to used git:// but it did not work and know behind a http proxy it is getting The requested URL returned error: 500 do someone know if I need something special to clone it? Sigh. Someone has helpfully upgraded apache on the machine at about 8pm, but failed to check that it was running afterwards (it's now midnight.) I've just restarted it, so it should work now. -- To unsubscribe from this list: send the line unsubscribe 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] OMAP: pm.c correct the initcall for an early init.
Gopinath, Thara th...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, December 02, 2010 7:03 PM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] OMAP: pm.c correct the initcall for an early init. Thara Gopinath th...@ti.com writes: omap2_common_pm_init is the API where generic system devices like mpu, l3 etc get initialized. This has to happen really early on during the boot and not at a later time. This is especially important with the new opp changes as these devices need to be built before the opp tables init happen. Today both are device initcalls and it works just because of the order of compilation Why postcore? there are several other inicalls earlier than device_initcall. Because the init in omap_device is a core_initcall. With respect to opp layer, making this anything above device_initcall will work. But then tomorrow some other module needs these generic devices in their init, we will again have to bump up the init priority of this fn. It is a good thing to do this early on in the boot cycle rather than later. OK, please describe this in more detail the changelog. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] OMAP: mailbox and iommu changes: for-next for v2.6.38
On Mon, Dec 13, 2010 at 6:02 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Dec 13, 2010 at 05:02:12PM -0600, Guzman Lugo, Fernando wrote: On Mon, Dec 13, 2010 at 11:31 AM, Kanigeri, Hari h-kanige...@ti.com wrote: On Sun, Dec 12, 2010 at 5:20 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Dec 06, 2010 at 09:16:23AM -0600, Kanigeri, Hari wrote: Ruseell, On Thu, Dec 2, 2010 at 9:43 AM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Thu, Dec 2, 2010 at 9:20 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Dec 02, 2010 at 08:50:07AM -0600, Guzman Lugo, Fernando wrote: On Thu, Dec 2, 2010 at 6:33 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Dec 02, 2010 at 06:07:23AM -0600, Kanigeri, Hari wrote: Hi Tony, The following changes since commit e8a7e48bb248a1196484d3f8afa53bded2b24e71: Linus Torvalds (1): Linux 2.6.37-rc4 are available in the git repository at: git://gitorious.org/iommu_mailbox/iommu_mailbox.git for_2.6.38 Fernando Guzman Lugo (5): OMAP: mailbox: change full flag per mailbox queue instead of global omap: iovmm - no gap checking for fixed address omap: iovmm - add superpages support to fixed da address omap: iovmm - replace __iounmap with omap_iounmap This change is wrong. Nothing should be directly referencing omap_iounmap nor for that matter omap_ioremap. Both are implementation details of the standard ioremap/iounmap APIs. Use the official APIs rather than the implementation details behind them. if you see where the function is used, you will see that it is not calling the function, it is use as a parameter in unmap_vm_area(), if I used iounmap which is a macro there I will get a compilation error. Hmm, yes, because iounmap() is defined as a macro rather than iounmap. The solution to this is to fix iounmap and __arch_iounmap macros so they aren't macros which take arguments. That will then allow them to be used in the way you desire. yes, that way it can be used in the function parameter. what is the right thing to do? 1) You send your patch and then I send the new version of the patches. 2) I make a new series of the patches with the change to iounmap and I include your patch in the series. Can you please suggest the approach we take here ? So, either you send your suggested change as a patch and Fernando's patch will be based on it, or he can take a TODO action item to patch again if you plan to send this change later. Right, the patches are in my git tree, under the 'io' branch: http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm.git io I tried to clone it but after sometime it fails, I tried to used git:// but it did not work and know behind a http proxy it is getting The requested URL returned error: 500 do someone know if I need something special to clone it? Sigh. Someone has helpfully upgraded apache on the machine at about 8pm, but failed to check that it was running afterwards (it's now midnight.) I've just restarted it, so it should work now. Thanks it is working now :). Regards, Fernando. -- To unsubscribe from this list: send the line unsubscribe 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] OMAP2+: PM: omap device: API's for handling mstandby mode
Paul/Benoit, On Fri, Dec 03, 2010 at 01:19:06PM +0100, Cousson, Benoit wrote: On 12/3/2010 10:47 AM, G, Manjunath Kondaiah wrote: * Cousson, Benoitb-cous...@ti.com [2010-12-03 09:38:35 +0100]: [...] v7: replaced mutex lock with spin lock. Added use count for controlling access to sysconfig registers in case if overlapping request/release API's are used. I'm not sure it should be done here. I'd rather keep that code in the DMA, since this is the only user of that feature. Are you referring to spin lock or usage count? The spinlock is needed, I was referring to the usage count. That being said, the API proposed by Paul (request/release ) sound like a get/put, so maybe he had that kind of usage in mind. I'm still not convince it should be done at hwmod API level. Paul, Any thoughts on that? How do we proceed further? -Manjunath -- To unsubscribe from this list: send the line unsubscribe 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 v5 0/12] dmtimer adaptation to platform_driver
DebBarma, Tarun Kanti tarun.ka...@ti.com writes: On Tue, Dec 07, 2010 at 05:14:07AM +0530, Tarun Kanti DebBarma wrote: dmtimer adaptation to platform_driver. This patch series is adaptation of dmtimer code to platform driver using omap_device and omap_hwmod abstraction. Tested on following platforms: OMAP4430, OMAP3430, OMAP3630, OMAP2430 OMAP2420 -- Image with omap2plus_defconfig in too large to download on N800. How about omap1? The mainline code happily compiles and boots on osk5912 but this series is going to break omap1 build. I have built and booted on OMAP1 during v3. This time I could not because My OMAP1710 has gone bad. I am looking for one to test. That's precisely the reason I have not mentioned OMAP1. Rather than not mentioning OMAP1, you should state whether (or not) it was tested on OMAP1. As build/boot testing on OMAP1 is a requirement for merge, this information is crucial. 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 1/5] OMAP4: hwmod data: Fix hwmod entries order
Benoit Cousson b-cous...@ti.com writes: The original OMAP4 hwmod data files is fully generated from HW database. But since the file is introduced incrementaly along with driver that uses the data, it has to be splitted by the driver owner and then re-merged by the maintainer. Because of the similarity of the data, git is completely lost during such merge and thus the data does not look like the original one at the end. Re-order properly the structures to stay in sync with original data set. Add a comment that does contain all the IPs that can have a hwmod, but do not have it in the file for the moment. It gives a good indication of the progress. Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Rajendra Nayak rna...@ti.com Cc: Govindraj.R govindraj.r...@ti.com Cc: Charulatha V ch...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Acked-by: Kevin Hilman khil...@deeprootsystems.com My (mostly) blind git merges caused this problem in the first place. Sorry. 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 6/6] omap2+: Initialize serial ports for wake-up events for n8x0
Tony Lindgren t...@atomide.com writes:
Use omap_serial_init_port so we can let the serial code handle the
remuxing of the RX pads.
Signed-off-by: Tony Lindgren t...@atomide.com
Does this work for UART wakeups on n810? I don't see any 'idle' value
for the pads, so I'm guessing it wont work without those, right? Or am
I missing something here.
Kevin
---
arch/arm/mach-omap2/board-n8x0.c | 66
--
1 files changed, 63 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n8x0.c
b/arch/arm/mach-omap2/board-n8x0.c
index d022301..e3429b4 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -29,6 +29,7 @@
#include plat/board.h
#include plat/common.h
+#include plat/omap_device.h
#include plat/menelaus.h
#include mach/irqs.h
#include plat/mcspi.h
@@ -754,8 +755,68 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP2420_MUX(EAC_AC_DOUT, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
+
+static struct omap_device_pad serial0_pads[] __initdata = {
+ { .name = uart1_rx.uart1_rx, .enable = OMAP_MUX_MODE0 },
+ { .name = uart1_tx.uart1_tx, .enable = OMAP_MUX_MODE0 },
+};
+
+static struct omap_device_pad n800_serial1_pads[] __initdata = {
+ { .name = uart2_rx.uart2_rx, .enable = OMAP_MUX_MODE7, },
+ {
+ .name = uart2_tx.uart2_tx,
+ .enable = OMAP_PULL_ENA | OMAP_MUX_MODE7,
+ },
+};
+
+static struct omap_device_pad n810_serial1_pads[] __initdata = {
+ { .name = uart2_rx.uart2_rx, .enable = OMAP_MUX_MODE0, },
+ { .name = uart2_tx.uart2_tx, .enable = OMAP_MUX_MODE0, },
+};
+
+static struct omap_device_pad serial2_pads[] __initdata = {
+ {
+ .name = uart3_rx_irrx.uart3_rx_irrx,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .enable = OMAP_MUX_MODE0,
+ .idle = OMAP_MUX_MODE3/* Mux as GPIO for idle */
+ },
+ { .name = uart3_tx_irtx.uart3_tx_irtx, .enable = OMAP_MUX_MODE0, },
+};
+
+static struct omap_device_board_data serial0_data = {
+ .id = 0,
+ .pads = serial0_pads,
+ .pads_cnt = ARRAY_SIZE(serial0_pads),
+};
+
+static struct omap_device_board_data serial1_data = {
+ .id = 1,
+};
+
+static struct omap_device_board_data serial2_data = {
+ .id = 2,
+ .pads = serial2_pads,
+ .pads_cnt = ARRAY_SIZE(serial2_pads),
+};
+
+static inline void board_serial_init(int is_n800)
+{
+ if (is_n800) {
+ serial1_data.pads = n800_serial1_pads;
+ serial1_data.pads_cnt = ARRAY_SIZE(n800_serial1_pads);
+ } else {
+ serial1_data.pads = n810_serial1_pads;
+ serial1_data.pads_cnt = ARRAY_SIZE(n810_serial1_pads);
+ }
+ omap_serial_init_port(serial0_data);
+ omap_serial_init_port(serial1_data);
+ omap_serial_init_port(serial2_data);
+}
#else
-#define board_muxNULL
+static inline void board_serial_init(void)
+ omap_serial_init();
+}
#endif
static void __init n8x0_init_machine(void)
@@ -772,8 +833,7 @@ static void __init n8x0_init_machine(void)
if (machine_is_nokia_n810())
i2c_register_board_info(2, n810_i2c_board_info_2,
ARRAY_SIZE(n810_i2c_board_info_2));
-
- omap_serial_init();
+ board_serial_init(machine_is_nokia_n800());
n8x0_onenand_init();
n8x0_mmc_init();
n8x0_usb_init();
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5 v3] OMAP3630: PM: Erratum i608: disable RTA
Nishanth Menon n...@ti.com writes: Erratum id: i608 RTA (Retention Till Access) feature is not supported and leads to device stability issues when enabled. This impacts modules with embedded memories on OMAP3630 Workaround is to disable RTA on boot and coming out of core off. For disabling rta coming out of off mode, we do this by overriding the restore pointer for 3630 to allow us restore handler as the first point of entry before caches are touched and is common for GP and HS devices. to disable earlier than this could be possible by modifying the ppa for HS devices, but not for GP devices. Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Tony Lindgren t...@atomide.com [ambr...@ti.com: co-developer] Signed-off-by: Ambresh K ambr...@ti.com Signed-off-by: Nishanth Menon n...@ti.com [...] @@ -1045,6 +1057,15 @@ static int __init omap3_pm_init(void) pm_idle = omap3_pm_idle; omap3_idle_init(); + /* + * RTA is disabled during initialization as per erratum i608 + * it is safer to disable rta by the bootloader, but we would like + * to be doubly sure here and prevent any mishaps. + */ + if (IS_PM34XX_ERRATUM(RTA_ERRATUM_i608)) + omap_ctrl_writel(OMAP36XX_RTA_DISABLE, + OMAP36XX_CONTROL_MEM_RTA_CTRL); + Minor nit: we've been trying to clean up control module access. So, rather than directly writing control module registers, could you create an API for this like was done for omap3_ctrl_write_boot_mode(). Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if ES1.2
Nishanth Menon n...@ti.com writes:
Vishwanath Sripathy had written, on 12/13/2010 08:58 AM, the following:
[...]
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-
omap2/pm34xx.c
index ba3c0d6..da12a56 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -932,8 +932,15 @@ void omap3_pm_off_mode_enable(int enable)
#endif
list_for_each_entry(pwrst, pwrst_list, node) {
- pwrst-next_state = state;
- omap_set_pwrdm_state(pwrst-pwrdm, state);
+ if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
+ pwrst-pwrdm == core_pwrdm) {
+ pwrst-next_state = PWRDM_POWER_RET;
+ pr_err(%s: cannot enable Core OFF due to
i583\n,
+ __func__);
You probably need to throw up this warning only if state
== PWRDM_POWER_OFF. Otherwise this code looks fine to me.
Thanks for the review. added it. will post a v4 later today if no one
cribs with this approach. I will retain the logic in sram_idle as well
as a backup measure.
This logic doesn't belong in SRAM idle. To handle the idle case, you
should also disable the 'valid' bit for any C-state that has CORE off (I
think there's only one.)
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5 v3] OMAP: idle path errata fixes
Hi Nishanth, Nishanth Menon n...@ti.com writes: as discussed in [1], here is step 2 - idle path errata fixes. this is the next rev incorporating comments from V2 post of this series. I had a couple small comments on individual patches. In addition, in the next series, can you report the platforms it was tested on, and how it was tested (retention idle/suspend, off idle/suspend, CPUidle enabled?, etc.) I tested this series (and Jean's cleanup patch) on 34xx/n900 with retention idle suspend and off idle suspend with and without CPUidle enabled.) Also, when posting an updated series, can you update the version of all patches in the series, even if they are unchanged? This makes more more explicit versioning, keeps things clearer in patchwork and avoids problems with dumb mailers who thread by subject only. Also, please Cc linux-arm-kernel when posting the next version. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: tidspbridge: use the right type for list_is_last
On Sun, Dec 12, 2010 at 6:02 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Omar, On Wednesday 08 December 2010 23:20:23 Omar Ramirez Luna wrote: Removes the following warning: CC [M] drivers/staging/tidspbridge/rmgr/rmm.o drivers/staging/tidspbridge/rmgr/rmm.c: In function 'rmm_alloc': drivers/staging/tidspbridge/rmgr/rmm.c:147: warning: passing argument 1 of 'list_is_last' from incompatible pointer type include/linux/list.h:170: note: expected 'const struct list_head *' but argument is of type 'struct rmm_ovly_sect *' I was about to send the same patch. Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Great, thanks Laurent, Ionut for the review. Regards, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP Tutorial Hour - Introduction to USB on OMAP
FYI... Please find details on the upcoming “OMAP Tutorial Hour” that will be hosted on Dec 15th, Wed at 8:30 AM CST (Central Standard Time) (UTC-5). http://omappedia.org/wiki/Tutorial_Hour_Topics Topics: * Introduction to USB on OMAP - Presented by “Anand Gadiyar” * Meego on PandaBoard - Presented by “Nishant Menon” Meeting Details: WebEx: https://ti.webex.com/mw0306lb/mywebex/default.do?siteurl=ti Meeting Number: 751 133 275 Meeting Password: None Teleconference Participant Code: 44464775 Teleconference bridge number in USA: 1-877-561-6828 or (972) 995 Teleconference bridge numbers for other countries please visit: http://www.ticonferencing.com/globalaccess/ We invite you to present in a future session – please suggest your topics at: http://www.omappedia.org/wiki/Tutorial_Hour_Topics Thanks! -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] staging: tidspbridge: rmgr/node.c code cleanup
Hi, On Sun, Dec 12, 2010 at 8:20 AM, Ionut Nicu ionut.n...@mindbit.ro wrote: Are the other modes (rdma, zerocopy) not supported at all? No, those modes are not supported... the only one working for dsp streams is proc-copy. Is there any plan to make them work? If not, maybe the code that handles them should be removed... I don't think there is any plan to support these modes, they have been disabled long time ago, even before the first versions of tidspbridge, I agree we should start thinking about removing them. Regards, Omar -- To unsubscribe from this list: send the line unsubscribe 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] OMAP3: clean up ASM idle code
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
Clean up of the ASM code:
- reorganized the code in logical sections: defines, API
functions, internal functions and variables,
- reworked and simplified the execution paths, for better
readability and to avoid duplication of code,
- added comments on the entry and exit points,
- reworked the existing comments for better readability,
- reworked the code formating, alignment and white spaces,
- added comments for the i443 erratum workarounds,
- changed the hardcoded values in favor of existing macros
from include files,
- clean up of non used symbols.
The 'lock_scratchpad_sem' code is also unused. IIRC, you removed that
in an earlier version of the series. Are you still planning to remove
that? maybe in a subsequent patch?
That being said, pure whitespace changes and unused code removal should
probably be a separate patch. It's a great help to reviewers if
functional changes are separated from whitespace changes. It's a bit
tricky in this series as there's lots of code moving as well, so I'll
leave it up to your judgement on how/if to separate these out.
Tested on OMAP3EVM and Beagleboard with full RET and OFF modes.
In idle? in suspend? both? was CPUidle enabled?
FWIW, I tested on 3430-ES3.1/n900 with retention idle suspend and off
idle suspend with CPUidle enabled.
Heavily reworked from Vishwa's original patch.
Here, it's more customary to say Based on original patch from Vishwa
and ensure the original author is CC'd (which you've done.)
Other than that, this is a great cleanup, and makes this much more
readable. Thanks.
Some other minor comments below.
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Vishwanath BS vishwanath...@ti.com
---
Applies on top of Nishant's latest idle path errata fixes step 2,
cf. http://marc.info/?l=linux-omapm=129139584919242w=2
[...]
@@ -208,36 +172,153 @@ api_params:
ENTRY(save_secure_ram_context_sz)
.word . - save_secure_ram_context
+
+/* ==
+ * == Idle entry point ==
+ * ==
+ */
Let's keep C multi-line coding style even for assembly. Same goes for
several other places below.
/*
* Forces OMAP into idle state
*
- * omap34xx_suspend() - This bit of code just executes the WFI
- * for normal idles.
+ * omap34xx_suspend() - This bit of code saves the CPU context if needed
+ * and executes the WFI instruction
+ *
+ * Note: This code get's copied to internal SRAM at boot.
*
- * Note: This code get's copied to internal SRAM at boot. When the OMAP
- *wakes up it continues execution at the point it went to sleep.
+ * Note: When the OMAP wakes up it continues at different execution points,
+ * depending on the low power mode (non-OFF vs OFF modes),
+ * cf. 'Resume path for xxx mode' comments.
*/
ENTRY(omap34xx_cpu_suspend)
stmfd sp!, {r0-r12, lr} @ save registers on stack
loop:
/*b loop*/ @Enable to debug by stepping through code
While here, let's get rid of these infinite loop hacks for debugging as
anyone debugging this code can add these back as needed. Otherwise,
they clutter the code. There are a few of theses throughout the
original code.
[...]
@@ -250,9 +331,28 @@ loop:
nop
bl wait_sdrc_ok
- ldmfd sp!, {r0-r12, pc} @ restore regs and return
+/* ===
+ * == Exit point from non-OFF modes ==
+ * ===
+ */
+ ldmfd sp!, {r0-r12, pc} @ restore regs and return
+
+
+/* ==
+ * == Resume path for OFF mode ==
+ * ==
+ */
I don't think this is quite correct. I don't believe it starts
immediately here. Doesn't it resume from DDR first, and then jump
here. A brief description of that process would help clarify that process.
+/*
+ * The restore_* functions are executed when back from WFI in OFF mode
+ *
+ * restore_es3: applies to 34xx = ES3.0
+ * restore_3630: applies to 36xx
+ * restore: common code for 3xxx
+ */
restore_es3:
/*b restore_es3*/ @ Enable to debug restore code
+
ldr r5, pm_prepwstst_core_p
ldr r4, [r5]
and r4, r4, #0x3
@@ -282,18 +382,20 @@ restore_3630:
ldr r1, control_mem_rta
mov r2, #OMAP36XX_RTA_DISABLE
str r2, [r1]
- /* Fall thru for the remaining logic */
+
+ /* Fall thru to common code for the remaining logic */
+
restore:
/* b restore*/ @ Enable to debug restore code
-/* Check what was the reason for mpu reset and store the reason in
r9*/
-/* 1 - Only L1 and logic lost */
-/* 2 - Only L2 lost - In this case, we wont be here */
-/* 3 - Both L1 and L2 lost */
+ /* Check what was the reason for mpu reset and store the reason in r9*/
+ /* 1 - Only L1 and logic lost
RE: [PATCH 0/5] omap4: l2x0 fixes and cleanup
ping -Original Message- From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] Sent: Thursday, December 02, 2010 5:28 PM To: t...@atomide.com Cc: Nishanth Menon; m...@mansr.com; khil...@deeprootsystems.com; linux- arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org Subject: RE: [PATCH 0/5] omap4: l2x0 fixes and cleanup Tony, -Original Message- From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] Sent: Friday, November 19, 2010 11:01 PM To: linux-omap@vger.kernel.org Cc: n...@ti.com; m...@mansr.com; t...@atomide.com; khil...@deeprootsystems.com; linux-arm-ker...@lists.infradead.org; Santosh Shilimkar Subject: [PATCH 0/5] omap4: l2x0 fixes and cleanup This series is outcome of the below discussion thread. http://www.spinics.net/lists/arm-kernel/msg104254.html The series in brief has following patches - adds PL310 aux-control register bitfields - Use these bitfields instead of hardcoded values as part of init - Enable PL310 intsruction, Data prefetch hints and BRESP to improve performance - Set share-override bit to avoid non-cached buffer corruption Thanks to Nishant Menon for testing this series on OMAP4 panda using the memspeed utility. Have boot tested this series on OMAP4 SDP with omap2plus_defconfig. How about merging this series in omap-testing if you are ok with it. Patch ARM: l2x0: Add aux control register bitfields is already acked by Catalin. The following changes since commit e53beacd23d9cb47590da6a7a7f6d417b941a994: Linus Torvalds (1): Linux 2.6.37-rc2 Mans Rullgard (1): omap4: l2x0: enable instruction and data prefetching Santosh Shilimkar (4): ARM: l2x0: Add aux control register bitfields omap4: l2x0: Construct the AUXCTRL value using defines omap4: l2x0: Set share override bit omap4: l2x0: Enable early BRESP bit arch/arm/include/asm/hardware/cache-l2x0.h | 12 ++- arch/arm/mach-omap2/omap4-common.c | 30 +-- 2 files changed, 34 insertions(+), 8 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 v2 01/17] OMAP2420: hwmod data: add DSS DISPC RFBI VENC
Tomi, -Original Message- From: Guruswamy, Senthilvadivu Sent: Monday, December 13, 2010 5:02 PM To: Guruswamy, Senthilvadivu; 't...@atomide.com'; Cousson, Benoit; 'khil...@deeprootsystems.com' Cc: 'tomi.valkei...@nokia.com'; 'p...@pwsan.com'; Hiremath, Vaibhav; 'linux-omap@vger.kernel.org' Subject: RE: [PATCH v2 01/17] OMAP2420: hwmod data: add DSS DISPC RFBI VENC Kevin, Tony, Gentle reminder. Is there anything else pending on me to get these first 4 patches pulled in l-o? Regards, Senthil -Original Message- From: Guruswamy, Senthilvadivu Sent: Monday, December 06, 2010 1:14 PM To: 't...@atomide.com'; Cousson, Benoit Cc: Guruswamy, Senthilvadivu; khil...@deeprootsystems.com; tomi.valkei...@nokia.com; p...@pwsan.com; Hiremath, Vaibhav; linux- o...@vger.kernel.org Subject: RE: [PATCH v2 01/17] OMAP2420: hwmod data: add DSS DISPC RFBI VENC Tony, -Original Message- From: Guruswamy, Senthilvadivu Sent: Monday, November 29, 2010 5:21 PM To: khil...@deeprootsystems.com; tomi.valkei...@nokia.com; p...@pwsan.com; Hiremath, Vaibhav; linux-omap@vger.kernel.org Cc: Guruswamy, Senthilvadivu Subject: [PATCH v2 01/17] OMAP2420: hwmod data: add DSS DISPC RFBI VENC From: Senthilvadivu Guruswamy svad...@ti.com Database generated for OMAP2420 Display Sub System. Since dss is also considered as an IP as dispc,rfbi, name it as dss_dss. Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com Acked-by: Benoit Cousson b-cous...@ti.com --- The first 4 patches are reviewed by Acked by Benoit. These patches are also tested on 2420-N800, 2430SDP, 3430SDP as mentioned in cover letter. Could you please let me know what is needed further to push this changes to l-o. [Senthil] I see in patch work that the whole of this series is delegated to you. Could you please act on this and let me know if there is anything pending from my side ? Regards, Senthil arch/arm/mach-omap2/omap_hwmod_2420_data.c | 283 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/12] OMAP: clock/SRAM: patches for 2.6.38, part one
This clock/SRAM patch series, based on v2.6.37-rc5: - fixes some problems and missing data with OMAP4 clocks, - adds SCRM IP block data (part of the OMAP4 PRCM collection of modules), - cleans up the way that OMAP3 clock data CK_* and RATE_IN_* flags are used, - adds some comments to the SRAM code, - prepares part of the OMAP1 clock code for a combined OMAP1 defconfig (although more work is left to be done before a combined OMAP1 defconfig is safe, from a clock framework perspective), - and fixes a few minor bugs in the OMAP2/3 clock code. Boot-tested on OSK 5912, N800, OMAP35xx Beagle, and OMAP37xx Beagle-XM. This series is also available from git://git.pwsan.com/linux-2.6 branch 'clk_a_2.6.38'. - Paul --- clk_a_2.6.38 textdata bss dec hex filename 5733349 471616 5608768 11813733 b44365 vmlinux.orig 5734273 473728 5608768 11816769 b44f41 vmlinux.patched Benoit Cousson (3): OMAP4: clock data: Add control for pad_clks_ck and slimbus_clk OMAP3: clock data: Add wkup_clkdm in sr1_fck and sr2_fck OMAP4: PRCM: Add SCRM header file Janusz Krzysztofik (1): OMAP1: clock_data: use runtime cpu / machine checks Jonathan Bergsagel (1): OMAP4: clock data: Add missing fields in iva_hsd_byp_clk_mux_ck Paul Walmsley (4): OMAP2xxx clock: fix dss2_fck recalc to use clksel OMAP3: clock: clarify usage of struct clksel_rate.flags and struct omap_clk.cpu OMAP3: clock: fix incorrect rate display when switching MPU rate at boot OMAP2/3: SRAM: add comment about crashes during a TLB miss Rajendra Nayak (2): OMAP4: clock data: Add SCRM auxiliary clock nodes OMAP4: clock data: Export control to enable/disable CORE/PER M3 clocks Thara Gopinath (1): OMAP4: clock data: Add missing DPLL x2 clock nodes arch/arm/mach-omap1/clock_data.c | 17 - arch/arm/mach-omap2/clock2420_data.c |2 arch/arm/mach-omap2/clock2430_data.c |2 arch/arm/mach-omap2/clock3xxx.c |2 arch/arm/mach-omap2/clock3xxx_data.c | 218 - arch/arm/mach-omap2/clock44xx_data.c | 620 ++--- arch/arm/mach-omap2/scrm44xx.h| 176 +++ arch/arm/mach-omap2/sram242x.S|6 arch/arm/mach-omap2/sram243x.S|6 arch/arm/mach-omap2/sram34xx.S|6 arch/arm/plat-omap/include/plat/clkdev_omap.h | 20 - arch/arm/plat-omap/include/plat/clock.h | 11 12 files changed, 772 insertions(+), 314 deletions(-) create mode 100644 arch/arm/mach-omap2/scrm44xx.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/12] OMAP4: clock data: Add control for pad_clks_ck and slimbus_clk
From: Benoit Cousson b-cous...@ti.com
The gating of pad_clks and slimbus_ck is controlled by the PRCM, but
since the clock source is external, this is the SW responsability
to gate / un-gate it when the mcpdm or slimbus module need to be used.
There is no autogating possible with such external clock.
Add SW control to enable / disable this SW gating in the pad_clks_ck
and slimbus_clk clock node.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Sebastien Guiriec s-guir...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index bfcd19f..828d7f4 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -47,7 +47,9 @@ static struct clk extalt_clkin_ck = {
static struct clk pad_clks_ck = {
.name = pad_clks_ck,
.rate = 1200,
- .ops= clkops_null,
+ .ops= clkops_omap2_dflt,
+ .enable_reg = OMAP4430_CM_CLKSEL_ABE,
+ .enable_bit = OMAP4430_PAD_CLKS_GATE_SHIFT,
};
static struct clk pad_slimbus_core_clks_ck = {
@@ -65,7 +67,9 @@ static struct clk secure_32k_clk_src_ck = {
static struct clk slimbus_clk = {
.name = slimbus_clk,
.rate = 1200,
- .ops= clkops_null,
+ .ops= clkops_omap2_dflt,
+ .enable_reg = OMAP4430_CM_CLKSEL_ABE,
+ .enable_bit = OMAP4430_SLIMBUS_CLK_GATE_SHIFT,
};
static struct clk sys_32k_ck = {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/12] OMAP4: clock data: Add SCRM auxiliary clock nodes
From: Rajendra Nayak rna...@ti.com
Add support for auxiliary clocks nodes which are part of SCRM.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock44xx_data.c | 175 ++
1 files changed, 175 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 421103c..80a1898 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -35,6 +35,7 @@
#include prm.h
#include prm-regbits-44xx.h
#include control.h
+#include scrm44xx.h
/* Root clocks */
@@ -2822,6 +2823,168 @@ static struct clk trace_clk_div_ck = {
.set_rate = omap2_clksel_set_rate,
};
+/* SCRM aux clk nodes */
+
+static const struct clksel auxclk_sel[] = {
+ { .parent = sys_clkin_ck, .rates = div_1_0_rates },
+ { .parent = dpll_core_m3x2_ck, .rates = div_1_1_rates },
+ { .parent = dpll_per_m3x2_ck, .rates = div_1_2_rates },
+ { .parent = NULL },
+};
+
+static struct clk auxclk0_ck = {
+ .name = auxclk0_ck,
+ .parent = sys_clkin_ck,
+ .init = omap2_init_clksel_parent,
+ .ops= clkops_omap2_dflt,
+ .clksel = auxclk_sel,
+ .clksel_reg = OMAP4_SCRM_AUXCLK0,
+ .clksel_mask= OMAP4_SRCSELECT_MASK,
+ .recalc = omap2_clksel_recalc,
+ .enable_reg = OMAP4_SCRM_AUXCLK0,
+ .enable_bit = OMAP4_ENABLE_SHIFT,
+};
+
+static struct clk auxclk1_ck = {
+ .name = auxclk1_ck,
+ .parent = sys_clkin_ck,
+ .init = omap2_init_clksel_parent,
+ .ops= clkops_omap2_dflt,
+ .clksel = auxclk_sel,
+ .clksel_reg = OMAP4_SCRM_AUXCLK1,
+ .clksel_mask= OMAP4_SRCSELECT_MASK,
+ .recalc = omap2_clksel_recalc,
+ .enable_reg = OMAP4_SCRM_AUXCLK1,
+ .enable_bit = OMAP4_ENABLE_SHIFT,
+};
+
+static struct clk auxclk2_ck = {
+ .name = auxclk2_ck,
+ .parent = sys_clkin_ck,
+ .init = omap2_init_clksel_parent,
+ .ops= clkops_omap2_dflt,
+ .clksel = auxclk_sel,
+ .clksel_reg = OMAP4_SCRM_AUXCLK2,
+ .clksel_mask= OMAP4_SRCSELECT_MASK,
+ .recalc = omap2_clksel_recalc,
+ .enable_reg = OMAP4_SCRM_AUXCLK2,
+ .enable_bit = OMAP4_ENABLE_SHIFT,
+};
+static struct clk auxclk3_ck = {
+ .name = auxclk3_ck,
+ .parent = sys_clkin_ck,
+ .init = omap2_init_clksel_parent,
+ .ops= clkops_omap2_dflt,
+ .clksel = auxclk_sel,
+ .clksel_reg = OMAP4_SCRM_AUXCLK3,
+ .clksel_mask= OMAP4_SRCSELECT_MASK,
+ .recalc = omap2_clksel_recalc,
+ .enable_reg = OMAP4_SCRM_AUXCLK3,
+ .enable_bit = OMAP4_ENABLE_SHIFT,
+};
+
+static struct clk auxclk4_ck = {
+ .name = auxclk4_ck,
+ .parent = sys_clkin_ck,
+ .init = omap2_init_clksel_parent,
+ .ops= clkops_omap2_dflt,
+ .clksel = auxclk_sel,
+ .clksel_reg = OMAP4_SCRM_AUXCLK4,
+ .clksel_mask= OMAP4_SRCSELECT_MASK,
+ .recalc = omap2_clksel_recalc,
+ .enable_reg = OMAP4_SCRM_AUXCLK4,
+ .enable_bit = OMAP4_ENABLE_SHIFT,
+};
+
+static struct clk auxclk5_ck = {
+ .name = auxclk5_ck,
+ .parent = sys_clkin_ck,
+ .init = omap2_init_clksel_parent,
+ .ops= clkops_omap2_dflt,
+ .clksel = auxclk_sel,
+ .clksel_reg = OMAP4_SCRM_AUXCLK5,
+ .clksel_mask= OMAP4_SRCSELECT_MASK,
+ .recalc = omap2_clksel_recalc,
+ .enable_reg = OMAP4_SCRM_AUXCLK5,
+ .enable_bit = OMAP4_ENABLE_SHIFT,
+};
+
+static const struct clksel auxclkreq_sel[] = {
+ { .parent = auxclk0_ck, .rates = div_1_0_rates },
+ { .parent = auxclk1_ck, .rates = div_1_1_rates },
+ { .parent = auxclk2_ck, .rates = div_1_2_rates },
+ { .parent = auxclk3_ck, .rates = div_1_3_rates },
+ { .parent = auxclk4_ck, .rates = div_1_4_rates },
+ { .parent = auxclk5_ck, .rates = div_1_5_rates },
+ { .parent = NULL },
+};
+
+static struct clk auxclkreq0_ck = {
+ .name = auxclkreq0_ck,
+ .parent = auxclk0_ck,
+ .init = omap2_init_clksel_parent,
+ .ops= clkops_null,
+ .clksel = auxclkreq_sel,
+ .clksel_reg = OMAP4_SCRM_AUXCLKREQ0,
+ .clksel_mask= OMAP4_MAPPING_MASK,
+ .recalc = omap2_clksel_recalc,
+};
+
+static struct clk auxclkreq1_ck = {
+ .name = auxclkreq1_ck,
+ .parent = auxclk1_ck,
+ .init
[PATCH 05/12] OMAP4: PRCM: Add SCRM header file
From: Benoit Cousson b-cous...@ti.com Add the header file with scrm registers absolute address, offset and bitfields. Signed-off-by: Benoit Cousson b-cous...@ti.com Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/scrm44xx.h | 176 1 files changed, 176 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/scrm44xx.h diff --git a/arch/arm/mach-omap2/scrm44xx.h b/arch/arm/mach-omap2/scrm44xx.h new file mode 100644 index 000..d29bf27 --- /dev/null +++ b/arch/arm/mach-omap2/scrm44xx.h @@ -0,0 +1,176 @@ +/* + * OMAP44xx SCRM registers and bitfields + * + * Copyright (C) 2010 Texas Instruments, Inc. + * + * Benoit Cousson (b-cous...@ti.com) + * + * This file is automatically generated from the OMAP hardware databases. + * We respectfully ask that any modifications to this file be coordinated + * with the public linux-omap@vger.kernel.org mailing list and the + * authors above to ensure that the autogeneration scripts are kept + * up-to-date with the file contents. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef __ARCH_ARM_MACH_OMAP2_SCRM_44XX_H +#define __ARCH_ARM_MACH_OMAP2_SCRM_44XX_H + +/* Base address */ +#define OMAP4_SCRM 0x4a30a000 + +#define OMAP44XX_SCRM_REGADDR(reg) \ + OMAP2_L4_IO_ADDRESS(OMAP4_SCRM + (reg)) + +/* Registers offset */ +#define OMAP4_SCRM_REVISION_SCRM_OFFSET0x +#define OMAP4_SCRM_REVISION_SCRM OMAP44XX_SCRM_REGADDR(0x) +#define OMAP4_SCRM_CLKSETUPTIME_OFFSET 0x0100 +#define OMAP4_SCRM_CLKSETUPTIME OMAP44XX_SCRM_REGADDR(0x0100) +#define OMAP4_SCRM_PMICSETUPTIME_OFFSET0x0104 +#define OMAP4_SCRM_PMICSETUPTIME OMAP44XX_SCRM_REGADDR(0x0104) +#define OMAP4_SCRM_ALTCLKSRC_OFFSET0x0110 +#define OMAP4_SCRM_ALTCLKSRC OMAP44XX_SCRM_REGADDR(0x0110) +#define OMAP4_SCRM_MODEMCLKM_OFFSET0x0118 +#define OMAP4_SCRM_MODEMCLKM OMAP44XX_SCRM_REGADDR(0x0118) +#define OMAP4_SCRM_D2DCLKM_OFFSET 0x011c +#define OMAP4_SCRM_D2DCLKM OMAP44XX_SCRM_REGADDR(0x011c) +#define OMAP4_SCRM_EXTCLKREQ_OFFSET0x0200 +#define OMAP4_SCRM_EXTCLKREQ OMAP44XX_SCRM_REGADDR(0x0200) +#define OMAP4_SCRM_ACCCLKREQ_OFFSET0x0204 +#define OMAP4_SCRM_ACCCLKREQ OMAP44XX_SCRM_REGADDR(0x0204) +#define OMAP4_SCRM_PWRREQ_OFFSET 0x0208 +#define OMAP4_SCRM_PWRREQ OMAP44XX_SCRM_REGADDR(0x0208) +#define OMAP4_SCRM_AUXCLKREQ0_OFFSET 0x0210 +#define OMAP4_SCRM_AUXCLKREQ0 OMAP44XX_SCRM_REGADDR(0x0210) +#define OMAP4_SCRM_AUXCLKREQ1_OFFSET 0x0214 +#define OMAP4_SCRM_AUXCLKREQ1 OMAP44XX_SCRM_REGADDR(0x0214) +#define OMAP4_SCRM_AUXCLKREQ2_OFFSET 0x0218 +#define OMAP4_SCRM_AUXCLKREQ2 OMAP44XX_SCRM_REGADDR(0x0218) +#define OMAP4_SCRM_AUXCLKREQ3_OFFSET 0x021c +#define OMAP4_SCRM_AUXCLKREQ3 OMAP44XX_SCRM_REGADDR(0x021c) +#define OMAP4_SCRM_AUXCLKREQ4_OFFSET 0x0220 +#define OMAP4_SCRM_AUXCLKREQ4 OMAP44XX_SCRM_REGADDR(0x0220) +#define OMAP4_SCRM_AUXCLKREQ5_OFFSET 0x0224 +#define OMAP4_SCRM_AUXCLKREQ5 OMAP44XX_SCRM_REGADDR(0x0224) +#define OMAP4_SCRM_D2DCLKREQ_OFFSET0x0234 +#define OMAP4_SCRM_D2DCLKREQ OMAP44XX_SCRM_REGADDR(0x0234) +#define OMAP4_SCRM_AUXCLK0_OFFSET 0x0310 +#define OMAP4_SCRM_AUXCLK0 OMAP44XX_SCRM_REGADDR(0x0310) +#define OMAP4_SCRM_AUXCLK1_OFFSET 0x0314 +#define OMAP4_SCRM_AUXCLK1 OMAP44XX_SCRM_REGADDR(0x0314) +#define OMAP4_SCRM_AUXCLK2_OFFSET 0x0318 +#define OMAP4_SCRM_AUXCLK2 OMAP44XX_SCRM_REGADDR(0x0318) +#define OMAP4_SCRM_AUXCLK3_OFFSET 0x031c +#define OMAP4_SCRM_AUXCLK3 OMAP44XX_SCRM_REGADDR(0x031c) +#define OMAP4_SCRM_AUXCLK4_OFFSET 0x0320 +#define OMAP4_SCRM_AUXCLK4 OMAP44XX_SCRM_REGADDR(0x0320) +#define OMAP4_SCRM_AUXCLK5_OFFSET 0x0324 +#define OMAP4_SCRM_AUXCLK5 OMAP44XX_SCRM_REGADDR(0x0324) +#define OMAP4_SCRM_RSTTIME_OFFSET 0x0400 +#define OMAP4_SCRM_RSTTIME OMAP44XX_SCRM_REGADDR(0x0400) +#define OMAP4_SCRM_MODEMRSTCTRL_OFFSET 0x0418 +#define OMAP4_SCRM_MODEMRSTCTRL OMAP44XX_SCRM_REGADDR(0x0418) +#define OMAP4_SCRM_D2DRSTCTRL_OFFSET 0x041c +#define OMAP4_SCRM_D2DRSTCTRL OMAP44XX_SCRM_REGADDR(0x041c) +#define OMAP4_SCRM_EXTPWRONRSTCTRL_OFFSET
[PATCH 09/12] OMAP3: clock: clarify usage of struct clksel_rate.flags and struct omap_clk.cpu
Clarify the usage of the struct omap_clk.cpu flags (e.g., CK_*) to use
bits only for individual SoC variants (e.g., CK_3430ES1, CK_3505,
etc.). Superset flags, such as CK_3XXX or CK_AM35XX, are now defined
as disjunctions of individual SoC variant flags. This simplifies the
definition and use of these flags. struct omap_clk record definitions
can now simply specify the bitmask of actual SoCs that the records are
valid for. The clock init code can simply set a single CPU type mask
bit for the SoC that is currently in use, and test against that,
rather than needing to set some combination of flags.
Similarly, clarify the use of struct clksel_rate.flags. The bit
allocated for RATE_IN_3XXX has been reassigned, and RATE_IN_3XXX has
been defined as a disjunction of the 34xx and 36xx rate flags. The
advantages are the same as the above.
Clarify the usage of struct omap_clk.cpu flags such as CK_34XX to only
apply to the SoCs that they name, e.g., OMAP34xx chips. The previous
practice caused significantly different SoCs, such as OMAP36xx, to be
included in CK_34XX. In my opinion, this is much more intuitive.
Similarly, clarify the use of struct clksel_rate.flags, such that
RATE_IN_3430ES2PLUS now only applies to 34xx chips with ES level = 2
- it does not apply to OMAP36xx.
...
At some point, it probably makes sense to collapse the CK_* and
RATE_IN_* flags together into a single bitfield, and possibly use the
existing CHIP_IS_OMAP* flags for platform detection.
...
This all seems to work fine on OMAP34xx and OMAP36xx Beagle. Not sure
if it works on Sitara or the TI816X, unfortunately I don't have any
here to test with.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock3xxx_data.c | 216 -
arch/arm/plat-omap/include/plat/clkdev_omap.h | 20 +-
arch/arm/plat-omap/include/plat/clock.h | 11 +
3 files changed, 125 insertions(+), 122 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 94cbae3..84e43d3 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -120,7 +120,7 @@ static const struct clksel_rate osc_sys_13m_rates[] = {
};
static const struct clksel_rate osc_sys_16_8m_rates[] = {
- { .div = 1, .val = 5, .flags = RATE_IN_3430ES2PLUS },
+ { .div = 1, .val = 5, .flags = RATE_IN_3430ES2PLUS_36XX },
{ .div = 0 }
};
@@ -452,35 +452,35 @@ static struct clk dpll3_x2_ck = {
static const struct clksel_rate div31_dpll3_rates[] = {
{ .div = 1, .val = 1, .flags = RATE_IN_3XXX },
{ .div = 2, .val = 2, .flags = RATE_IN_3XXX },
- { .div = 3, .val = 3, .flags = RATE_IN_3430ES2PLUS },
- { .div = 4, .val = 4, .flags = RATE_IN_3430ES2PLUS },
- { .div = 5, .val = 5, .flags = RATE_IN_3430ES2PLUS },
- { .div = 6, .val = 6, .flags = RATE_IN_3430ES2PLUS },
- { .div = 7, .val = 7, .flags = RATE_IN_3430ES2PLUS },
- { .div = 8, .val = 8, .flags = RATE_IN_3430ES2PLUS },
- { .div = 9, .val = 9, .flags = RATE_IN_3430ES2PLUS },
- { .div = 10, .val = 10, .flags = RATE_IN_3430ES2PLUS },
- { .div = 11, .val = 11, .flags = RATE_IN_3430ES2PLUS },
- { .div = 12, .val = 12, .flags = RATE_IN_3430ES2PLUS },
- { .div = 13, .val = 13, .flags = RATE_IN_3430ES2PLUS },
- { .div = 14, .val = 14, .flags = RATE_IN_3430ES2PLUS },
- { .div = 15, .val = 15, .flags = RATE_IN_3430ES2PLUS },
- { .div = 16, .val = 16, .flags = RATE_IN_3430ES2PLUS },
- { .div = 17, .val = 17, .flags = RATE_IN_3430ES2PLUS },
- { .div = 18, .val = 18, .flags = RATE_IN_3430ES2PLUS },
- { .div = 19, .val = 19, .flags = RATE_IN_3430ES2PLUS },
- { .div = 20, .val = 20, .flags = RATE_IN_3430ES2PLUS },
- { .div = 21, .val = 21, .flags = RATE_IN_3430ES2PLUS },
- { .div = 22, .val = 22, .flags = RATE_IN_3430ES2PLUS },
- { .div = 23, .val = 23, .flags = RATE_IN_3430ES2PLUS },
- { .div = 24, .val = 24, .flags = RATE_IN_3430ES2PLUS },
- { .div = 25, .val = 25, .flags = RATE_IN_3430ES2PLUS },
- { .div = 26, .val = 26, .flags = RATE_IN_3430ES2PLUS },
- { .div = 27, .val = 27, .flags = RATE_IN_3430ES2PLUS },
- { .div = 28, .val = 28, .flags = RATE_IN_3430ES2PLUS },
- { .div = 29, .val = 29, .flags = RATE_IN_3430ES2PLUS },
- { .div = 30, .val = 30, .flags = RATE_IN_3430ES2PLUS },
- { .div = 31, .val = 31, .flags = RATE_IN_3430ES2PLUS },
+ { .div = 3, .val = 3, .flags = RATE_IN_3430ES2PLUS_36XX },
+ { .div = 4, .val = 4, .flags = RATE_IN_3430ES2PLUS_36XX },
+ { .div = 5, .val = 5, .flags = RATE_IN_3430ES2PLUS_36XX },
+ { .div = 6, .val = 6, .flags = RATE_IN_3430ES2PLUS_36XX },
+ { .div = 7, .val = 7, .flags = RATE_IN_3430ES2PLUS_36XX },
+ { .div = 8, .val = 8, .flags = RATE_IN_3430ES2PLUS_36XX },
+ { .div = 9, .val = 9, .flags = RATE_IN_3430ES2PLUS_36XX },
+ {
[PATCH 12/12] OMAP1: clock_data: use runtime cpu / machine checks
From: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Otherwise multi-omap1 configurations may set wrong clock speed.
Created and tested against l-o master on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap1/clock_data.c | 17 -
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index 423d21d..c7c2a52 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -823,12 +823,10 @@ int __init omap1_clk_init(void)
crystal_type = info-system_clock_type;
}
-#if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
- ck_ref.rate = 1300;
-#elif defined(CONFIG_ARCH_OMAP16XX)
- if (crystal_type == 2)
+ if (cpu_is_omap7xx())
+ ck_ref.rate = 1300;
+ if (cpu_is_omap16xx() crystal_type == 2)
ck_ref.rate = 1920;
-#endif
pr_info(Clocks: ARM_SYSST: 0x%04x DPLL_CTL: 0x%04x ARM_CKCTL:
0x%04x\n, omap_readw(ARM_SYSST), omap_readw(DPLL_CTL),
@@ -883,10 +881,11 @@ int __init omap1_clk_init(void)
ck_dpll1.rate / 100, (ck_dpll1.rate / 10) % 10,
arm_ck.rate / 100, (arm_ck.rate / 10) % 10);
-#if defined(CONFIG_MACH_OMAP_PERSEUS2) || defined(CONFIG_MACH_OMAP_FSAMPLE)
- /* Select slicer output as OMAP input clock */
- omap_writew(omap_readw(OMAP7XX_PCC_UPLD_CTRL) ~0x1,
OMAP7XX_PCC_UPLD_CTRL);
-#endif
+ if (machine_is_omap_perseus2() || machine_is_omap_fsample()) {
+ /* Select slicer output as OMAP input clock */
+ omap_writew(omap_readw(OMAP7XX_PCC_UPLD_CTRL) ~0x1,
+ OMAP7XX_PCC_UPLD_CTRL);
+ }
/* Amstrad Delta wants BCLK high when inactive */
if (machine_is_ams_delta())
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/12] OMAP3: clock: fix incorrect rate display when switching MPU rate at boot
The OMAP3 clock code contains some legacy code to allow the MPU rate to be specified as a kernel command line parameter. If the 'mpurate' parameter is specified, the kernel will attempt to switch the MPU rate to this rate during boot. As part of this process, a short message Switched to new clocking rate is generated -- and in this message, the Core clock rate and MPU clock rate are transposed. This patch ensures that the clock rates are displayed in the correct order. Thanks to Bruno Guerin br_gue...@free.fr for reporting this bug and proposing a fix. Thanks to Richard Woodruff r-woodru...@ti.com for reviewing the problem and passing the report on. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Bruno Guerin br.gue...@free.fr Cc: Richard Woodruff r-woodru...@ti.com --- arch/arm/mach-omap2/clock3xxx.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/clock3xxx.c b/arch/arm/mach-omap2/clock3xxx.c index a447c4d..90b9477 100644 --- a/arch/arm/mach-omap2/clock3xxx.c +++ b/arch/arm/mach-omap2/clock3xxx.c @@ -94,7 +94,7 @@ static int __init omap3xxx_clk_arch_init(void) ret = omap2_clk_switch_mpurate_at_boot(dpll1_ck); if (!ret) - omap2_clk_print_new_rates(osc_sys_ck, arm_fck, core_ck); + omap2_clk_print_new_rates(osc_sys_ck, core_ck, arm_fck); return ret; } -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/12] OMAP2/3: SRAM: add comment about crashes during a TLB miss
Some users were observing crashes during the execution of CORE DVFS
code from OCM RAM -- a locally-modified copy of the linux-omap code.
Richard Woodruff tracked this down to a DTLB miss which had been
inadvertently and intermittently caused by the local modifications.
(The TLB miss caused the ARM MMU to attempt to walk the page tables
stored in SDRAM, which was not possible since SDRAM is off-line for a
portion of the CORE DVFS OCM RAM code.)
Add a note to the OMAP2 OMAP3 CORE DVFS SRAM code to warn others that
changes may result in crashes here if they are not carefully tested.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Richard Woodruff r-woodru...@ti.com
Cc: Jon Hunter jon-hun...@ti.com
Cc: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/sram242x.S |6 ++
arch/arm/mach-omap2/sram243x.S |6 ++
arch/arm/mach-omap2/sram34xx.S |6 ++
3 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/sram242x.S b/arch/arm/mach-omap2/sram242x.S
index 92e6e1a..6d88cee 100644
--- a/arch/arm/mach-omap2/sram242x.S
+++ b/arch/arm/mach-omap2/sram242x.S
@@ -21,6 +21,12 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
* MA 02111-1307 USA
+ *
+ * Richard Woodruff notes that any changes to this code must be carefully
+ * audited and tested to ensure that they don't cause a TLB miss while
+ * the SDRAM is inaccessible. Such a situation will crash the system
+ * since it will cause the ARM MMU to attempt to walk the page tables.
+ * These crashes may be intermittent.
*/
#include linux/linkage.h
#include asm/assembler.h
diff --git a/arch/arm/mach-omap2/sram243x.S b/arch/arm/mach-omap2/sram243x.S
index ab49736..2f104a6 100644
--- a/arch/arm/mach-omap2/sram243x.S
+++ b/arch/arm/mach-omap2/sram243x.S
@@ -21,6 +21,12 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
* MA 02111-1307 USA
+ *
+ * Richard Woodruff notes that any changes to this code must be carefully
+ * audited and tested to ensure that they don't cause a TLB miss while
+ * the SDRAM is inaccessible. Such a situation will crash the system
+ * since it will cause the ARM MMU to attempt to walk the page tables.
+ * These crashes may be intermittent.
*/
#include linux/linkage.h
#include asm/assembler.h
diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S
index 3637274..43f67f5 100644
--- a/arch/arm/mach-omap2/sram34xx.S
+++ b/arch/arm/mach-omap2/sram34xx.S
@@ -104,6 +104,12 @@
* touching the SDRAM. Until that time, users who know that their use case
* can satisfy the above requirement can enable the CONFIG_OMAP3_SDRC_AC_TIMING
* option.
+ *
+ * Richard Woodruff notes that any changes to this code must be carefully
+ * audited and tested to ensure that they don't cause a TLB miss while
+ * the SDRAM is inaccessible. Such a situation will crash the system
+ * since it will cause the ARM MMU to attempt to walk the page tables.
+ * These crashes may be intermittent.
*/
ENTRY(omap3_sram_configure_core_dpll)
stmfd sp!, {r1-r12, lr} @ store regs to stack
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/12] OMAP4: clock data: Export control to enable/disable CORE/PER M3 clocks
From: Rajendra Nayak rna...@ti.com
The CORE and PER M3 post dividers are different from the rest of the
DPLL post dividers as in they go to SCRM, and are used
there to export clocks for instance used by external sensor.
There is no automatic HW dependency in PRCM to manage them. Hence these
two clocks (dpll post dividers) should be managed by SW and explicitly
enabled/disabled.
Add control in clock framework to handle that.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock44xx_data.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 80a1898..4c77613 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -610,7 +610,9 @@ static struct clk dpll_core_m3x2_ck = {
.clksel = dpll_core_m6x2_div,
.clksel_reg = OMAP4430_CM_DIV_M3_DPLL_CORE,
.clksel_mask= OMAP4430_DPLL_CLKOUTHIF_DIV_MASK,
- .ops= clkops_null,
+ .ops= clkops_omap2_dflt,
+ .enable_reg = OMAP4430_CM_DIV_M3_DPLL_CORE,
+ .enable_bit = OMAP4430_DPLL_CLKOUTHIF_GATE_CTRL_SHIFT,
.recalc = omap2_clksel_recalc,
.round_rate = omap2_clksel_round_rate,
.set_rate = omap2_clksel_set_rate,
@@ -869,7 +871,9 @@ static struct clk dpll_per_m3x2_ck = {
.clksel = dpll_per_m2x2_div,
.clksel_reg = OMAP4430_CM_DIV_M3_DPLL_PER,
.clksel_mask= OMAP4430_DPLL_CLKOUTHIF_DIV_MASK,
- .ops= clkops_null,
+ .ops= clkops_omap2_dflt,
+ .enable_reg = OMAP4430_CM_DIV_M3_DPLL_PER,
+ .enable_bit = OMAP4430_DPLL_CLKOUTHIF_GATE_CTRL_SHIFT,
.recalc = omap2_clksel_recalc,
.round_rate = omap2_clksel_round_rate,
.set_rate = omap2_clksel_set_rate,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/12] OMAP4: clock data: Add missing DPLL x2 clock nodes
From: Thara Gopinath th...@ti.com
This patch extends the OMAP4 clock data to include
various x2 clock nodes between DPLL and HS dividers as the
clock framework skips a x2 while calculating the dpll locked
frequency.
The clock database extensions are autogenerated using
the scripts maintained by Benoit Cousson.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Thara Gopinath th...@ti.com
[p...@pwsan.com: fixed merge conflicts against v2.6.37-rc5]
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 423 --
1 files changed, 248 insertions(+), 175 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 828d7f4..aa503cb 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -269,11 +269,63 @@ static struct clk dpll_abe_ck = {
.set_rate = omap3_noncore_dpll_set_rate,
};
+static struct clk dpll_abe_x2_ck = {
+ .name = dpll_abe_x2_ck,
+ .parent = dpll_abe_ck,
+ .ops= clkops_null,
+ .recalc = omap3_clkoutx2_recalc,
+};
+
+static const struct clksel_rate div31_1to31_rates[] = {
+ { .div = 1, .val = 1, .flags = RATE_IN_4430 },
+ { .div = 2, .val = 2, .flags = RATE_IN_4430 },
+ { .div = 3, .val = 3, .flags = RATE_IN_4430 },
+ { .div = 4, .val = 4, .flags = RATE_IN_4430 },
+ { .div = 5, .val = 5, .flags = RATE_IN_4430 },
+ { .div = 6, .val = 6, .flags = RATE_IN_4430 },
+ { .div = 7, .val = 7, .flags = RATE_IN_4430 },
+ { .div = 8, .val = 8, .flags = RATE_IN_4430 },
+ { .div = 9, .val = 9, .flags = RATE_IN_4430 },
+ { .div = 10, .val = 10, .flags = RATE_IN_4430 },
+ { .div = 11, .val = 11, .flags = RATE_IN_4430 },
+ { .div = 12, .val = 12, .flags = RATE_IN_4430 },
+ { .div = 13, .val = 13, .flags = RATE_IN_4430 },
+ { .div = 14, .val = 14, .flags = RATE_IN_4430 },
+ { .div = 15, .val = 15, .flags = RATE_IN_4430 },
+ { .div = 16, .val = 16, .flags = RATE_IN_4430 },
+ { .div = 17, .val = 17, .flags = RATE_IN_4430 },
+ { .div = 18, .val = 18, .flags = RATE_IN_4430 },
+ { .div = 19, .val = 19, .flags = RATE_IN_4430 },
+ { .div = 20, .val = 20, .flags = RATE_IN_4430 },
+ { .div = 21, .val = 21, .flags = RATE_IN_4430 },
+ { .div = 22, .val = 22, .flags = RATE_IN_4430 },
+ { .div = 23, .val = 23, .flags = RATE_IN_4430 },
+ { .div = 24, .val = 24, .flags = RATE_IN_4430 },
+ { .div = 25, .val = 25, .flags = RATE_IN_4430 },
+ { .div = 26, .val = 26, .flags = RATE_IN_4430 },
+ { .div = 27, .val = 27, .flags = RATE_IN_4430 },
+ { .div = 28, .val = 28, .flags = RATE_IN_4430 },
+ { .div = 29, .val = 29, .flags = RATE_IN_4430 },
+ { .div = 30, .val = 30, .flags = RATE_IN_4430 },
+ { .div = 31, .val = 31, .flags = RATE_IN_4430 },
+ { .div = 0 },
+};
+
+static const struct clksel dpll_abe_m2x2_div[] = {
+ { .parent = dpll_abe_x2_ck, .rates = div31_1to31_rates },
+ { .parent = NULL },
+};
+
static struct clk dpll_abe_m2x2_ck = {
.name = dpll_abe_m2x2_ck,
- .parent = dpll_abe_ck,
+ .parent = dpll_abe_x2_ck,
+ .clksel = dpll_abe_m2x2_div,
+ .clksel_reg = OMAP4430_CM_DIV_M2_DPLL_ABE,
+ .clksel_mask= OMAP4430_DPLL_CLKOUT_DIV_MASK,
.ops= clkops_null,
- .recalc = followparent_recalc,
+ .recalc = omap2_clksel_recalc,
+ .round_rate = omap2_clksel_round_rate,
+ .set_rate = omap2_clksel_set_rate,
};
static struct clk abe_24m_fclk = {
@@ -330,50 +382,10 @@ static struct clk aess_fclk = {
.set_rate = omap2_clksel_set_rate,
};
-static const struct clksel_rate div31_1to31_rates[] = {
- { .div = 1, .val = 1, .flags = RATE_IN_4430 },
- { .div = 2, .val = 2, .flags = RATE_IN_4430 },
- { .div = 3, .val = 3, .flags = RATE_IN_4430 },
- { .div = 4, .val = 4, .flags = RATE_IN_4430 },
- { .div = 5, .val = 5, .flags = RATE_IN_4430 },
- { .div = 6, .val = 6, .flags = RATE_IN_4430 },
- { .div = 7, .val = 7, .flags = RATE_IN_4430 },
- { .div = 8, .val = 8, .flags = RATE_IN_4430 },
- { .div = 9, .val = 9, .flags = RATE_IN_4430 },
- { .div = 10, .val = 10, .flags = RATE_IN_4430 },
- { .div = 11, .val = 11, .flags = RATE_IN_4430 },
- { .div = 12, .val = 12, .flags = RATE_IN_4430 },
- { .div = 13, .val = 13, .flags = RATE_IN_4430 },
- { .div = 14, .val = 14, .flags = RATE_IN_4430 },
- { .div = 15, .val = 15, .flags = RATE_IN_4430 },
- { .div = 16, .val = 16, .flags = RATE_IN_4430 },
- { .div = 17, .val = 17, .flags = RATE_IN_4430 },
- { .div = 18, .val = 18, .flags = RATE_IN_4430 },
- { .div = 19,
[PATCH 08/12] OMAP2xxx clock: fix dss2_fck recalc to use clksel
dss2_fck is a clksel clock, and therefore its rate should be recalculated
with the clksel mechanism. This was working in early 2009, but was one of
the casualties of the big OMAP clock merge between 2.6.29 and 2.6.30.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock2420_data.c |2 +-
arch/arm/mach-omap2/clock2430_data.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index 831e25c..7cfa186 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -812,7 +812,7 @@ static struct clk dss2_fck = { /* Alt clk used
in power management */
.clksel_reg = OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL1),
.clksel_mask= OMAP24XX_CLKSEL_DSS2_MASK,
.clksel = dss2_fck_clksel,
- .recalc = followparent_recalc,
+ .recalc = omap2_clksel_recalc,
};
static struct clk dss_54m_fck = { /* Alt clk used in power management */
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index a9c60b7..3bd437a 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -800,7 +800,7 @@ static struct clk dss2_fck = { /* Alt clk used
in power management */
.clksel_reg = OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL1),
.clksel_mask= OMAP24XX_CLKSEL_DSS2_MASK,
.clksel = dss2_fck_clksel,
- .recalc = followparent_recalc,
+ .recalc = omap2_clksel_recalc,
};
static struct clk dss_54m_fck = { /* Alt clk used in power management */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/12] OMAP4: clock data: Add missing fields in iva_hsd_byp_clk_mux_ck
From: Jonathan Bergsagel jbergsa...@ti.com
Add register address, mask and link to the clksel structure that
were missing in the IVA DPLL mux clock node.
Signed-off-by: Jonathan Bergsagel jbergsa...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index aa503cb..421103c 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -636,8 +636,12 @@ static const struct clksel iva_hsd_byp_clk_mux_sel[] = {
static struct clk iva_hsd_byp_clk_mux_ck = {
.name = iva_hsd_byp_clk_mux_ck,
.parent = sys_clkin_ck,
+ .clksel = iva_hsd_byp_clk_mux_sel,
+ .init = omap2_init_clksel_parent,
+ .clksel_reg = OMAP4430_CM_CLKSEL_DPLL_IVA,
+ .clksel_mask= OMAP4430_DPLL_BYP_CLKSEL_MASK,
.ops= clkops_null,
- .recalc = followparent_recalc,
+ .recalc = omap2_clksel_recalc,
};
/* DPLL_IVA */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/12] OMAP3: clock data: Add wkup_clkdm in sr1_fck and sr2_fck
From: Benoit Cousson b-cous...@ti.com
The smartreflex modules belong to an ALWON_FCLK clock domain that
does not have any SW control. The gating of that interface clock
is triggered by a transition of the WKUP clock domain to idle.
Attach both smartreflex instances on OMAP3 to the WKUP clock domain.
The missing clock domain field in srX_fck clock nodes was reported by
Kevin during the discussion about smartreflex on OMAP3:
https://patchwork.kernel.org/patch/199342/
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/clock3xxx_data.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 0579604..94cbae3 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3044,6 +3044,7 @@ static struct clk sr1_fck = {
.parent = sys_ck,
.enable_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_SR1_SHIFT,
+ .clkdm_name = wkup_clkdm,
.recalc = followparent_recalc,
};
@@ -3054,6 +3055,7 @@ static struct clk sr2_fck = {
.parent = sys_ck,
.enable_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_SR2_SHIFT,
+ .clkdm_name = wkup_clkdm,
.recalc = followparent_recalc,
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] OMAP34: Fixes in setup/suspend/powerdomain
Hi Benoît, Kevin, On Mon, 13 Dec 2010, Benoit Cousson wrote: This is a series of fixes on OMAP3/4 in setup apis, in the suspend framework and in powerdomain modelling for OMAP4. ... Rajendra Nayak (3): OMAP4: PM: Use the lowpwrstatechange feature on OMAP4 OMAP4: PM: Do not assume clkdm supports hw transitions The above two patches should be run by Kevin for his ack (cc'ed on this message). Kevin, care to ack these? - Paul
Re: [PATCH v5 0/12] dmtimer adaptation to platform_driver
On Tue, 7 Dec 2010, Tarun Kanti DebBarma wrote: Tested on following platforms: OMAP4430, OMAP3430, OMAP3630, OMAP2430 OMAP2420 -- Image with omap2plus_defconfig in too large to download on N800. Just build a minimal N800 config for testing. It's really quite easy. Use 'make menuconfig' and then you can remove lots of unnecessary stuff. - 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/12] OMAP: clock/SRAM: patches for 2.6.38, part one
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Tuesday, December 14, 2010 12:05 PM To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: [PATCH 00/12] OMAP: clock/SRAM: patches for 2.6.38, part one I guess you wanted to say SCRM instead of SRAM in subject line This clock/SRAM patch series, based on v2.6.37-rc5: - fixes some problems and missing data with OMAP4 clocks, - adds SCRM IP block data (part of the OMAP4 PRCM collection of modules), - cleans up the way that OMAP3 clock data CK_* and RATE_IN_* flags are used, - adds some comments to the SRAM code, - prepares part of the OMAP1 clock code for a combined OMAP1 defconfig (although more work is left to be done before a combined OMAP1 defconfig is safe, from a clock framework perspective), - and fixes a few minor bugs in the OMAP2/3 clock code. Boot-tested on OSK 5912, N800, OMAP35xx Beagle, and OMAP37xx Beagle-XM. This series is also available from git://git.pwsan.com/linux-2.6 branch 'clk_a_2.6.38'. - Paul --- clk_a_2.6.38 text data bss dec hex filename 5733349471616 5608768 11813733 b44365 vmlinux.orig 5734273473728 5608768 11816769 b44f41 vmlinux.patched Benoit Cousson (3): OMAP4: clock data: Add control for pad_clks_ck and slimbus_clk OMAP3: clock data: Add wkup_clkdm in sr1_fck and sr2_fck OMAP4: PRCM: Add SCRM header file Janusz Krzysztofik (1): OMAP1: clock_data: use runtime cpu / machine checks Jonathan Bergsagel (1): OMAP4: clock data: Add missing fields in iva_hsd_byp_clk_mux_ck Paul Walmsley (4): OMAP2xxx clock: fix dss2_fck recalc to use clksel OMAP3: clock: clarify usage of struct clksel_rate.flags and struct omap_clk.cpu OMAP3: clock: fix incorrect rate display when switching MPU rate at boot OMAP2/3: SRAM: add comment about crashes during a TLB miss Rajendra Nayak (2): OMAP4: clock data: Add SCRM auxiliary clock nodes OMAP4: clock data: Export control to enable/disable CORE/PER M3 clocks Thara Gopinath (1): OMAP4: clock data: Add missing DPLL x2 clock nodes arch/arm/mach-omap1/clock_data.c | 17 - arch/arm/mach-omap2/clock2420_data.c |2 arch/arm/mach-omap2/clock2430_data.c |2 arch/arm/mach-omap2/clock3xxx.c |2 arch/arm/mach-omap2/clock3xxx_data.c | 218 - arch/arm/mach-omap2/clock44xx_data.c | 620 ++-- - arch/arm/mach-omap2/scrm44xx.h| 176 +++ arch/arm/mach-omap2/sram242x.S|6 arch/arm/mach-omap2/sram243x.S|6 arch/arm/mach-omap2/sram34xx.S|6 arch/arm/plat-omap/include/plat/clkdev_omap.h | 20 - arch/arm/plat-omap/include/plat/clock.h | 11 12 files changed, 772 insertions(+), 314 deletions(-) create mode 100644 arch/arm/mach-omap2/scrm44xx.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 00/12] OMAP: clock/SRAM: patches for 2.6.38, part one
On Tue, 14 Dec 2010, Santosh Shilimkar wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Tuesday, December 14, 2010 12:05 PM To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: [PATCH 00/12] OMAP: clock/SRAM: patches for 2.6.38, part one I guess you wanted to say SCRM instead of SRAM in subject line SRAM was, in fact, intentional. But maybe, if the series is reposted, I might add SCRM also. - 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/12] OMAP: clock/SRAM: patches for 2.6.38, part one
-Original Message- From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] Sent: Tuesday, December 14, 2010 12:19 PM To: Paul Walmsley; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org Subject: RE: [PATCH 00/12] OMAP: clock/SRAM: patches for 2.6.38, part one -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Tuesday, December 14, 2010 12:05 PM To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: [PATCH 00/12] OMAP: clock/SRAM: patches for 2.6.38, part one I guess you wanted to say SCRM instead of SRAM in subject line Please ignore my comment Paul. The series does have a SRAM fix. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
