Re: UbiFS + HWECC(?) + BeagleBoard = fail
Charles Manning wrote: Luca, I have been having similar problems on a hacked Overo kernel. I have no problems with 2.6.35. I tried just commenting out the define and disabling PREFETCH and did not get a good boot due to ubi not finding the volume info. Are you loading up a UBI image with uboot? Are you using the ubi volume as rootfs? To make it work again, I did from u-boot: - nand scrub (*completely* wipe the NAND) - ubi part nand0,3 (recreate partitions) - ubi create rootfs 40 - ...create other partitions... - ubi write ... (to rewrite rootfs) - finally, boot with the kernel having the define commented and PREFETCH off. Not all of these may be needed, but this way I got the board up and running again. Luca -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
-Original Message- From: Nishanth Menon [mailto:n...@ti.com] Sent: Wednesday, December 08, 2010 10:05 PM To: Gopinath, Thara Cc: Kevin Hilman; linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers Gopinath, Thara had written, on 12/08/2010 10:18 AM, the following: [..] And, AFAICT, it wasn't clear from the current code or docs whether this could work or was expected to work either, e.g., if you set override_volt_params back to zero, to the original values all get reused? If you want to provide this feature, then it should be documented and made clear that this is an intended goal. Thinking about this more, the main thing I don't like about this approach is that the active code paths (enable disable) have to check each time if any of these values have been overidden. Rather than have several places in the active code paths where this override value is checked, there the sysfs methods should simply update the values that are used by the core code. This way, the core would not need to know about where the values came from (defalts, volt_data, user override, etc.) If you want to provide a way to revert this, then maybe writing -1 will should switch that value back to the HW default, or volt_data default. Kevin, Benoit, Nishant et al, Without this override flag today there is no direct way of allowing user to write into these parameters. My question is, Glancing at the debug entries being overidden, as developer (debug users) working for tweaking parameters for their platform - yes - we will need some mechanism to runtime tweak and see the behavior without needing to rebuild the kernel everytime. On production system (OS users): they should'nt be using this. is there a need for the parameters to be over-written from the user-space? If yes, I need ideas on how to implement it with using override_volt_params ! Lets get the basics in kernel.org in some form! IMHO, all this double knobs are un-necessary overheads in codeflow for development only code- just provide the debugfs entries that reflect the data in their original structures, use the original structures everytime we go to a new transition (aka if you change the params in debugfs, they dont take effect till you do another transition).. but that is just my 2cents. Nishant, The issue here is most of these parameters are one time setting (during init) and need not be changed at all if the user does not wish to over-ride them for debug purpose. Hence the need for the checks (not double-hooks). But I agree with your point that let us get the basic in the kernel.org in some form. So for this first version that we plan to push to kernel.org, I plan to expose out these parameters to user space but not allow a write access to them. The write access part can be added later whenever required. Regards Thara --- 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 v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
Gopinath, Thara wrote, on 12/09/2010 03:43 AM: -Original Message- From: Nishanth Menon [mailto:n...@ti.com] Sent: Wednesday, December 08, 2010 10:05 PM To: Gopinath, Thara Cc: Kevin Hilman; linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers Gopinath, Thara had written, on 12/08/2010 10:18 AM, the following: [..] And, AFAICT, it wasn't clear from the current code or docs whether this could work or was expected to work either, e.g., if you set override_volt_params back to zero, to the original values all get reused? If you want to provide this feature, then it should be documented and made clear that this is an intended goal. Thinking about this more, the main thing I don't like about this approach is that the active code paths (enable disable) have to check each time if any of these values have been overidden. Rather than have several places in the active code paths where this override value is checked, there the sysfs methods should simply update the values that are used by the core code. This way, the core would not need to know about where the values came from (defalts, volt_data, user override, etc.) If you want to provide a way to revert this, then maybe writing -1 will should switch that value back to the HW default, or volt_data default. Kevin, Benoit, Nishant et al, Without this override flag today there is no direct way of allowing user to write into these parameters. My question is, Glancing at the debug entries being overidden, as developer (debug users) working for tweaking parameters for their platform - yes - we will need some mechanism to runtime tweak and see the behavior without needing to rebuild the kernel everytime. On production system (OS users): they should'nt be using this. is there a need for the parameters to be over-written from the user-space? If yes, I need ideas on how to implement it with using override_volt_params ! Lets get the basics in kernel.org in some form! IMHO, all this double knobs are un-necessary overheads in codeflow for development only code- just provide the debugfs entries that reflect the data in their original structures, use the original structures everytime we go to a new transition (aka if you change the params in debugfs, they dont take effect till you do another transition).. but that is just my 2cents. Nishant, The issue here is most of these parameters are one time setting (during init) and need not be changed at all if the user does not wish to over-ride them for debug purpose. Hence the need for the checks (not double-hooks). But I agree If they are init time thingy, then why not set it up so that when some one echo's to the debugfs, it writes to the register as well? That way you dont need to add runtime check and the debug developer does'nt need to worry about echo 1 magic_control_sys_fs_file (just kidding). with your point that let us get the basic in the kernel.org in some form. So for this first version that we plan to push to kernel.org, I plan to expose out these parameters to user space but not allow a write access to them. The write access part can be added later whenever required. Sure.. at this point, anything that actually works is welcome :) -- 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
[PATCH 0/2] ARM: Thumb-2: Fix Kconfig rules to avoid nonworking configs
Some configurations don't make sense with Thumb-2, or don't currently work and are unlikely to be relevant. The patches avoid Kconfig from allowing these problematic combinations, for now. Dave Martin (2): ARM: Thumb-2: Make CONFIG_THUMB2_KERNEL depend on !CPU_V6 ARM: Make CONFIG_FPE_NWFPE depend on !CONFIG_THUMB2_KERNEL arch/arm/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: Thumb-2: Make CONFIG_THUMB2_KERNEL depend on !CPU_V6
This makes sense, because Thumb-2 code can't execute on plain ARMv6 processors. This will avoid accidentally configuring a broken kernel where the config otherwise would allow multiple architecture versions to coexist in the same kernel. Not adding !CPU_V5 etc., because the chance of anyone trying to put v5 and v7 in the same kernel is low, and I'm not aware of any mach which can do this. These could be added later if it matters. Note that the rules may need to be refined if support for the ARM1156J(F)-S processor is later added to the kernel, since this processor supports the rare ARMv6T2 extensions, which add support for Thumb-2 and a few other ARMv7 features. Signed-off-by: Dave Martin dave.mar...@linaro.org Acked-by: Catalin Marinas catalin.mari...@arm.com --- arch/arm/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index db524e7..f9ca7f3 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1311,7 +1311,7 @@ config HZ config THUMB2_KERNEL bool Compile the kernel in Thumb-2 mode - depends on CPU_V7 EXPERIMENTAL + depends on CPU_V7 !CPU_V6 EXPERIMENTAL select AEABI select ARM_ASM_UNIFIED help -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: Make CONFIG_FPE_NWFPE depend on !CONFIG_THUMB2_KERNEL
Because the nwfpe support is unlikely to be used on new platforms and requires CONFIG_OABI_COMPAT, which is not generally used with ARMv7+, we shouldn't expect to build nwfpe support into a Thumb-2 kernel. At present, nwfpe contains assembly code which isn't Thumb-2 compatible, and for now it doesn't appear useful to port this code. All ARMv7-A/R platforms necessarily have VFPv3 hardware floating- point natively, making emulation unnecessary. Signed-off-by: Dave Martin dave.mar...@linaro.org Acked-by: Catalin Marinas catalin.mari...@arm.com --- arch/arm/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index f9ca7f3..7e825c3 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1759,7 +1759,7 @@ comment At least one emulation must be selected config FPE_NWFPE bool NWFPE math emulation - depends on !AEABI || OABI_COMPAT + depends on (!AEABI || OABI_COMPAT) !THUMB2_KERNEL ---help--- Say Y to include the NWFPE floating point emulator in the kernel. This is necessary to run most binaries. Linux does not currently -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/7] mfd: TWL6030: OMAP4: Registering the TWL6030-usb device
Hello. On 08-12-2010 19:01, Hema HK wrote: Registering the twl6030-usb transceiver device as a child to twl6030 core. Removed the NOP transceiver init call from board file. Populated twl4030_usb_data platform data structure with the function pointers for OMAP4430 internal PHY operation to be used twl630-usb driver. ^ by? Signed-off-by: Hema HKhem...@ti.com Cc: Samuel Ortizsa...@linux.intel.com Cc: Felipe Balbiba...@ti.com Cc: Tony Lindgrent...@atomide.com [...] Index: linux-2.6/drivers/mfd/twl-core.c === --- linux-2.6.orig/drivers/mfd/twl-core.c +++ linux-2.6/drivers/mfd/twl-core.c [...] @@ -682,6 +683,43 @@ add_children(struct twl4030_platform_dat [...] + child = add_child(0, twl6030_usb, + pdata-usb, sizeof(*pdata-usb), + true, + /* irq1 = VBUS_PRES, irq0 = USB ID*/ You forgot space before */. Index: linux-2.6/arch/arm/mach-omap2/board-omap4panda.c === --- linux-2.6.orig/arch/arm/mach-omap2/board-omap4panda.c +++ linux-2.6/arch/arm/mach-omap2/board-omap4panda.c Your patch is not sorted. WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v6 03/12] media: Entities, pads and links
Hi, On Tuesday 07 December 2010 20:03:28 Mark Brown wrote: On Tue, Dec 07, 2010 at 07:11:39PM +0100, Hans Verkuil wrote: Ah, now I understand what you mean. Would 'activated' be better than 'active'? Better, yes, though it still sounds a bit like something should be actively (IYSWIM) happening. In the absence of better ideas I could go with this. Or perhaps just say: the link 'is on' or the link 'is switched on'? So: ...LINK_SWITCHED_ON (sorry, forgot what the prefix is). Actually, I think 'switched on' is a pretty good description of what is going on in the hardware. I prefer activated, this makes me think of power. Bear in mind that for most audio the power is a big portion of the control - either the audio is analogue or it looks like it. Do I understand it correctly that the outcome of this discussion is that I just need to rename active to activated when talking about links ? -- 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
[RESEND #2] [PATCH v2] LEDS: Add output invertion option to backlight trigger
This patch extends the LED backlight tirgger driver with an option that allows
for inverting the trigger output polarity.
With the invertion option provided, I (ab)use the backlight trigger for
driving a LED that indicates LCD display blank condtition on my Amstrad Delta
videophone. Since the machine has no dedicated power LED, it was not possible
to distinguish if the display was blanked, or the machine was turned off,
without touching it.
The invert sysfs control is patterned after a similiar function of the GPIO
trigger driver.
Created and tested against linux-2.6.36-rc5 on Amstrad Delta.
Retested on linux-2.6.37-rc4.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Cc: Richard Purdie rpur...@rpsys.net
---
Resent because I still can't see any response received, while yet another
merge window is going to pass away soon.
Applies cleanly on top of 2.6.37-rc4, so no need for yet another refresh. Only
tried to clean up the commit message slightly - maybe my English is not good
enough to bother with, if not the code?
v1 - v2 changes:
- improve some conditional expressions to be more readable; thanks to Ralph
Corderoy (from e3-hacking) and Lars-Peter Clausen for their suggestions,
- refresh against linux-2.6.36-rc5.
drivers/leds/ledtrig-backlight.c | 60
---
1 file changed, 56 insertions(+), 4 deletions(-)
diff -upr linux-2.6.36-rc5.orig/drivers/leds/ledtrig-backlight.c
linux-2.6.36-rc5/drivers/leds/ledtrig-backlight.c
--- linux-2.6.36-rc5.orig/drivers/leds/ledtrig-backlight.c 2010-09-24
15:35:13.0 +0200
+++ linux-2.6.36-rc5/drivers/leds/ledtrig-backlight.c 2010-10-03
15:59:49.0 +0200
@@ -26,6 +26,7 @@ struct bl_trig_notifier {
int brightness;
int old_status;
struct notifier_block notifier;
+ unsigned invert;
};
static int fb_notifier_callback(struct notifier_block *p,
@@ -36,23 +37,63 @@ static int fb_notifier_callback(struct n
struct led_classdev *led = n-led;
struct fb_event *fb_event = data;
int *blank = fb_event-data;
+ int new_status = *blank ? BLANK : UNBLANK;
switch (event) {
case FB_EVENT_BLANK :
- if (*blank n-old_status == UNBLANK) {
+ if (new_status == n-old_status)
+ break;
+
+ if ((n-old_status == UNBLANK) ^ n-invert) {
n-brightness = led-brightness;
led_set_brightness(led, LED_OFF);
- n-old_status = BLANK;
- } else if (!*blank n-old_status == BLANK) {
+ } else {
led_set_brightness(led, n-brightness);
- n-old_status = UNBLANK;
}
+
+ n-old_status = new_status;
+
break;
}
return 0;
}
+static ssize_t bl_trig_invert_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct led_classdev *led = dev_get_drvdata(dev);
+ struct bl_trig_notifier *n = led-trigger_data;
+
+ return sprintf(buf, %s\n, n-invert ? yes : no);
+}
+
+static ssize_t bl_trig_invert_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t num)
+{
+ struct led_classdev *led = dev_get_drvdata(dev);
+ struct bl_trig_notifier *n = led-trigger_data;
+ unsigned invert;
+ int ret;
+
+ ret = sscanf(buf, %u, invert);
+ if (ret 1) {
+ dev_err(dev, invalid value\n);
+ return -EINVAL;
+ }
+
+ n-invert = !!invert;
+
+ /* After inverting, we need to update the LED. */
+ if ((n-old_status == BLANK) ^ n-invert)
+ led_set_brightness(led, LED_OFF);
+ else
+ led_set_brightness(led, n-brightness);
+
+ return num;
+}
+static DEVICE_ATTR(invert, 0644, bl_trig_invert_show, bl_trig_invert_store);
+
static void bl_trig_activate(struct led_classdev *led)
{
int ret;
@@ -66,6 +107,10 @@ static void bl_trig_activate(struct led_
return;
}
+ ret = device_create_file(led-dev, dev_attr_invert);
+ if (ret)
+ goto err_invert;
+
n-led = led;
n-brightness = led-brightness;
n-old_status = UNBLANK;
@@ -74,6 +119,12 @@ static void bl_trig_activate(struct led_
ret = fb_register_client(n-notifier);
if (ret)
dev_err(led-dev, unable to register backlight trigger\n);
+
+ return;
+
+err_invert:
+ led-trigger_data = NULL;
+ kfree(n);
}
static void bl_trig_deactivate(struct led_classdev *led)
@@ -82,6 +133,7 @@ static void bl_trig_deactivate(struct le
(struct bl_trig_notifier *) led-trigger_data;
if (n) {
+ device_remove_file(led-dev, dev_attr_invert);
fb_unregister_client(n-notifier);
kfree(n);
}
--
RE: [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
-Original Message- From: Menon, Nishanth Sent: Thursday, December 09, 2010 4:54 PM To: Gopinath, Thara Cc: Kevin Hilman; linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers Gopinath, Thara wrote, on 12/09/2010 03:43 AM: -Original Message- From: Nishanth Menon [mailto:n...@ti.com] Sent: Wednesday, December 08, 2010 10:05 PM To: Gopinath, Thara Cc: Kevin Hilman; linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers Gopinath, Thara had written, on 12/08/2010 10:18 AM, the following: [..] And, AFAICT, it wasn't clear from the current code or docs whether this could work or was expected to work either, e.g., if you set override_volt_params back to zero, to the original values all get reused? If you want to provide this feature, then it should be documented and made clear that this is an intended goal. Thinking about this more, the main thing I don't like about this approach is that the active code paths (enable disable) have to check each time if any of these values have been overidden. Rather than have several places in the active code paths where this override value is checked, there the sysfs methods should simply update the values that are used by the core code. This way, the core would not need to know about where the values came from (defalts, volt_data, user override, etc.) If you want to provide a way to revert this, then maybe writing -1 will should switch that value back to the HW default, or volt_data default. Kevin, Benoit, Nishant et al, Without this override flag today there is no direct way of allowing user to write into these parameters. My question is, Glancing at the debug entries being overidden, as developer (debug users) working for tweaking parameters for their platform - yes - we will need some mechanism to runtime tweak and see the behavior without needing to rebuild the kernel everytime. On production system (OS users): they should'nt be using this. is there a need for the parameters to be over-written from the user-space? If yes, I need ideas on how to implement it with using override_volt_params ! Lets get the basics in kernel.org in some form! IMHO, all this double knobs are un-necessary overheads in codeflow for development only code- just provide the debugfs entries that reflect the data in their original structures, use the original structures everytime we go to a new transition (aka if you change the params in debugfs, they dont take effect till you do another transition).. but that is just my 2cents. Nishant, The issue here is most of these parameters are one time setting (during init) and need not be changed at all if the user does not wish to over-ride them for debug purpose. Hence the need for the checks (not double-hooks). But I agree If they are init time thingy, then why not set it up so that when some one echo's to the debugfs, it writes to the register as well? That way you dont need to add runtime check and the debug developer does'nt need to worry about echo 1 magic_control_sys_fs_file (just kidding). Yes but then for it the debugfs set get APIs should have access to the data structures which stores the register offset etc. Today I am using a single API to set any parameter any vdd. This will have to change. Maybe one API per parameter. I cannot currently think of any better solution :-)! with your point that let us get the basic in the kernel.org in some form. So for this first version that we plan to push to kernel.org, I plan to expose out these parameters to user space but not allow a write access to them. The write access part can be added later whenever required. Sure.. at this point, anything that actually works is welcome :) Ok :-) ! Regards Thara -- To unsubscribe from this list: send the line unsubscribe 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/11] OMAP: PRCM/powerdomain/clockdomain patches for 2.6.38, part two
On Tue, 07 Dec 2010 23:18:28 -0700 Paul Walmsley p...@pwsan.com wrote: This series is available via git from git://git.pwsan.com/linux-2.6 in the branch 'pwrdm_prcm_b_2.6.38'. It applies on top of the OMAP: PRCM/powerdomain/clockdomain patches for 2.6.38, part one series, sent earlier. Kevin and OMAP ASoC-hackers, I'd appreciate review and acks, if appropriate, on the patches that touch code that you maintain. TI OMAP4 PM people, I would appreciate any testing assistance that you may be able to provide. Benoît, I've tried to keep the kernel data files and the output of the scripts relatively similar, but we might need to do some tweaking of the scripts or data files to align them in the way that makes the most sense. Is there some patch missing? Part one compiles but this set does not. CC arch/arm/mach-omap2/clockdomain.o arch/arm/mach-omap2/clockdomain.c:33: fatal error: cminst44xx.h: No such file or directory compilation terminated. make[1]: *** [arch/arm/mach-omap2/clockdomain.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] OMAP: I2C and UART device name cleanup
Hi All, In order to enforce a little bit of consistency in the omap devices name, the convention for omap devices name will be now omap_xxx. All the drivers adapted to hwmod will be named like that during the on-going adaptations. The I2C and UART drivers are already adapted to hwmod but with the originals name. Rename i2c and uart using this convention: i2c_omap - omap_i2c omap-hsuart - omap_uart Tested on OMAP4 ES2 on Panda / sdp4430. Some more validation will be needed on OMAP2 3. This series is based on Kevin's pm-hwmod-i2c branch and is available here: git://gitorious.org/omap-pm/linux.git for_2.6.38/device_name Regards, Benoit v1 http://www.spinics.net/lists/linux-omap/msg41474.html Merge previous patch #1 and #2 as suggested by Kevin to change the driver name at the same time with the device name in the clockdev. Benoit Cousson (2): I2C: i2c-omap: Change device name: i2c_omap - omap_i2c OMAP: serial: Change device name: omap-hsuart - omap_uart arch/arm/mach-omap1/clock_data.c |6 +++--- arch/arm/mach-omap2/clock2420_data.c |8 arch/arm/mach-omap2/clock2430_data.c |8 arch/arm/mach-omap2/clock3xxx_data.c | 12 ++-- arch/arm/mach-omap2/clock44xx_data.c | 16 arch/arm/plat-omap/i2c.c |2 +- arch/arm/plat-omap/include/plat/omap-serial.h |2 +- drivers/i2c/busses/i2c-omap.c |4 ++-- 8 files changed, 29 insertions(+), 29 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 v2 2/2] OMAP: serial: Change device name: omap-hsuart - omap_uart
The naming convention for omap_device is omap_XXX. Rename the device and driver name in order to stick to this naming convention. Remove the hs prefix that is implicit for every OMAP uarts. Signed-off-by: Benoit Cousson b-cous...@ti.com Acked-by: Govindraj Raja govindraj.r...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/plat-omap/include/plat/omap-serial.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h index c8dae02..cc71426 100644 --- a/arch/arm/plat-omap/include/plat/omap-serial.h +++ b/arch/arm/plat-omap/include/plat/omap-serial.h @@ -22,7 +22,7 @@ #include plat/mux.h -#define DRIVER_NAMEomap-hsuart +#define DRIVER_NAMEomap_uart /* * Use tty device name as ttyO, [O - OMAP] -- 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 v2 1/2] I2C: i2c-omap: Change device name: i2c_omap - omap_i2c
The convention for omap device naming is omap_XXX.
Rename the device and driver name in order to stick
to this naming convention.
Change device name in clock nodes as well.
Signed-off-by: Benoit Cousson b-cous...@ti.com
c: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Ben Dooks ben-...@fluff.org
---
arch/arm/mach-omap1/clock_data.c |6 +++---
arch/arm/mach-omap2/clock2420_data.c |8
arch/arm/mach-omap2/clock2430_data.c |8
arch/arm/mach-omap2/clock3xxx_data.c | 12 ++--
arch/arm/mach-omap2/clock44xx_data.c | 16
arch/arm/plat-omap/i2c.c |2 +-
drivers/i2c/busses/i2c-omap.c|4 ++--
7 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index af54114..aa6dd67 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -736,9 +736,9 @@ static struct omap_clk omap_clks[] = {
CLK(mmci-omap.1, ick, armper_ck.clk, CK_16XX),
/* Virtual clocks */
CLK(NULL, mpu, virtual_ck_mpu, CK_16XX | CK_1510 |
CK_310),
- CLK(i2c_omap.1, fck,i2c_fck, CK_16XX | CK_1510 |
CK_310 | CK_7XX),
- CLK(i2c_omap.1, ick,i2c_ick, CK_16XX),
- CLK(i2c_omap.1, ick,dummy_ck, CK_1510 | CK_310 |
CK_7XX),
+ CLK(omap_i2c.1, fck,i2c_fck, CK_16XX | CK_1510 |
CK_310 | CK_7XX),
+ CLK(omap_i2c.1, ick,i2c_ick, CK_16XX),
+ CLK(omap_i2c.1, ick,dummy_ck, CK_1510 | CK_310 |
CK_7XX),
CLK(omap1_spi100k.1, fck, dummy_ck, CK_7XX),
CLK(omap1_spi100k.1, ick, dummy_ck, CK_7XX),
CLK(omap1_spi100k.2, fck, dummy_ck, CK_7XX),
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index 21f8562..ed61ac2 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1862,10 +1862,10 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, eac_fck, eac_fck, CK_242X),
CLK(omap_hdq.0, ick,hdq_ick, CK_242X),
CLK(omap_hdq.1, fck,hdq_fck, CK_242X),
- CLK(i2c_omap.1, ick,i2c1_ick, CK_242X),
- CLK(i2c_omap.1, fck,i2c1_fck, CK_242X),
- CLK(i2c_omap.2, ick,i2c2_ick, CK_242X),
- CLK(i2c_omap.2, fck,i2c2_fck, CK_242X),
+ CLK(omap_i2c.1, ick,i2c1_ick, CK_242X),
+ CLK(omap_i2c.1, fck,i2c1_fck, CK_242X),
+ CLK(omap_i2c.2, ick,i2c2_ick, CK_242X),
+ CLK(omap_i2c.2, fck,i2c2_fck, CK_242X),
CLK(NULL, gpmc_fck, gpmc_fck, CK_242X),
CLK(NULL, sdma_fck, sdma_fck, CK_242X),
CLK(NULL, sdma_ick, sdma_ick, CK_242X),
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index e32afcb..1bded4e 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1969,10 +1969,10 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, fac_fck, fac_fck, CK_243X),
CLK(omap_hdq.0, ick,hdq_ick, CK_243X),
CLK(omap_hdq.1, fck,hdq_fck, CK_243X),
- CLK(i2c_omap.1, ick,i2c1_ick, CK_243X),
- CLK(i2c_omap.1, fck,i2chs1_fck,CK_243X),
- CLK(i2c_omap.2, ick,i2c2_ick, CK_243X),
- CLK(i2c_omap.2, fck,i2chs2_fck,CK_243X),
+ CLK(omap_i2c.1, ick,i2c1_ick, CK_243X),
+ CLK(omap_i2c.1, fck,i2chs1_fck,CK_243X),
+ CLK(omap_i2c.2, ick,i2c2_ick, CK_243X),
+ CLK(omap_i2c.2, fck,i2chs2_fck,CK_243X),
CLK(NULL, gpmc_fck, gpmc_fck, CK_243X),
CLK(NULL, sdma_fck, sdma_fck, CK_243X),
CLK(NULL, sdma_ick, sdma_ick, CK_243X),
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index d85ecd5..ee8aa39 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3285,9 +3285,9 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(mmci-omap-hs.1, fck, mmchs2_fck,CK_3XXX),
CLK(NULL, mspro_fck,mspro_fck, CK_343X),
CLK(mmci-omap-hs.0, fck, mmchs1_fck,CK_3XXX),
- CLK(i2c_omap.3, fck,i2c3_fck, CK_3XXX),
- CLK(i2c_omap.2, fck,i2c2_fck, CK_3XXX),
- CLK(i2c_omap.1, fck,i2c1_fck, CK_3XXX),
+ CLK(omap_i2c.3, fck,i2c3_fck, CK_3XXX),
+ CLK(omap_i2c.2, fck,i2c2_fck, CK_3XXX),
+ CLK(omap_i2c.1, fck,i2c1_fck, CK_3XXX),
CLK(omap-mcbsp.5, fck,
Re: [PATCH] MFD: TWL/TPS: fix twl_probe section mismatch warning in mfd/twl-core.c
Hi Bryan, On Wed, Dec 08, 2010 at 10:42:04AM +0800, Bryan Wu wrote: Fix the following section mismatch warning when building omap2plus_defconfig: WARNING: vmlinux.o(.data+0x47d7c): Section mismatch in reference from the variable twl_driver to the function .init.text:twl_probe() Patch applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/3] omap4: opp: add OPP table data
This patch adds OPP tables for OMAP4. New file has been added to keep
the OMAP4 opp tables and the registration of these tables with the
generic opp framework by OMAP SoC OPP interface.
Based on:
http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=blob;f=arch/arm/mach-omap2/opp44xx_data.c;h=252e3d0cb6050a64f390b9311c1c4977d74f762a;hb=refs/heads/omap4_next
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
v5:
added ARCH_HAS_OPP after rebase to rc3
V4: http://marc.info/?t=12899337926r=1w=2
switched data to .c file
v3: http://marc.info/?l=linux-omapm=128984926712794w=2
* switched to using device_initcall to autoinitialize the
opp tables
v2: https://patchwork.kernel.org/patch/266921/
arch/arm/mach-omap2/Kconfig|2 +
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/opp4xxx_data.c | 57
arch/arm/mach-omap2/pm.h |5 +++
4 files changed, 65 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/opp4xxx_data.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 102a7df..f85188d 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -46,6 +46,8 @@ config ARCH_OMAP4
select ARM_GIC
select PL310_ERRATA_588369
select ARM_ERRATA_720789
+ select ARCH_HAS_OPP
+ select PM_OPP if PM
comment OMAP Core Type
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fbbb6b3..ea217f5 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_ARCH_OMAP2) += sdrc2xxx.o
ifeq ($(CONFIG_PM_OPP),y)
obj-y += opp.o
obj-$(CONFIG_ARCH_OMAP3) += opp3xxx_data.o
+obj-$(CONFIG_ARCH_OMAP4) += opp4xxx_data.o
endif
# Power Management
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c
b/arch/arm/mach-omap2/opp4xxx_data.c
new file mode 100644
index 000..a11fa56
--- /dev/null
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -0,0 +1,57 @@
+/*
+ * OMAP4 OPP table definitions.
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Nishanth Menon
+ * Kevin Hilman
+ * Thara Gopinath
+ * Copyright (C) 2010 Nokia Corporation.
+ * Eduardo Valentin
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include linux/module.h
+
+#include plat/cpu.h
+
+#include omap_opp_data.h
+
+static struct omap_opp_def __initdata omap44xx_opp_def_list[] = {
+ /* MPU OPP1 - OPP50 */
+ OPP_INITIALIZER(mpu, true, 3, 110),
+ /* MPU OPP2 - OPP100 */
+ OPP_INITIALIZER(mpu, true, 6, 120),
+ /* MPU OPP3 - OPP-Turbo */
+ OPP_INITIALIZER(mpu, false, 8, 126),
+ /* MPU OPP4 - OPP-SB */
+ OPP_INITIALIZER(mpu, false, 100800, 135),
+ /* L3 OPP1 - OPP50 */
+ OPP_INITIALIZER(l3_main_1, true, 1, 93),
+ /* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
+ OPP_INITIALIZER(l3_main_1, true, 2, 110),
+ /* TODO: add IVA, DSP, aess, fdif, gpu */
+};
+
+/**
+ * omap4_opp_init() - initialize omap4 opp table
+ */
+static int __init omap4_opp_init(void)
+{
+ int r = -ENODEV;
+
+ if (!cpu_is_omap44xx())
+ return r;
+
+ r = omap_init_opp_table(omap44xx_opp_def_list,
+ ARRAY_SIZE(omap44xx_opp_def_list));
+
+ return r;
+}
+device_initcall(omap4_opp_init);
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 2031f15..a43e069 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -22,11 +22,16 @@ extern int omap3_idle_init(void);
#if defined(CONFIG_PM_OPP)
extern int omap3_opp_init(void);
+extern int omap4_opp_init(void);
#else
static inline int omap3_opp_init(void)
{
return -EINVAL;
}
+static inline int omap4_opp_init(void)
+{
+ return -EINVAL;
+}
#endif
struct cpuidle_params {
--
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
[PATCH v4 3/3] OMAP3: remove OPP interfaces from OMAP PM layer
From: Kevin Hilman khil...@deeprootsystems.com
With new OPP layer, OPP users will access OPP API directly instead of
using OMAP PM layer, so remove all notions of OPPs from the OMAP PM
layer.
Acked-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
v4: identical to v3 with Acked-by added
posted for completeness sake - no change involved
v3: no longer explicitly calling the init_table, instead
depending on the device_initcall to initialize as needed
v2: https://patchwork.kernel.org/patch/266931/
arch/arm/mach-omap2/io.c |3 +-
arch/arm/plat-omap/include/plat/omap-pm.h | 31 +---
arch/arm/plat-omap/omap-pm-noop.c | 11 +-
3 files changed, 12 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 40562dd..2fe4e02 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -327,8 +327,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
else if (cpu_is_omap44xx())
omap44xx_hwmod_init();
- /* The OPP tables have to be registered before a clk init */
- omap_pm_if_early_init(mpu_opps, dsp_opps, l3_opps);
+ omap_pm_if_early_init();
if (cpu_is_omap2420())
omap2420_clk_init();
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h
b/arch/arm/plat-omap/include/plat/omap-pm.h
index 728fbb9..62c3fe9 100644
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -17,27 +17,10 @@
#include linux/device.h
#include linux/cpufreq.h
#include linux/clk.h
+#include linux/opp.h
#include powerdomain.h
-/**
- * struct omap_opp - clock frequency-to-OPP ID table for DSP, MPU
- * @rate: target clock rate
- * @opp_id: OPP ID
- * @min_vdd: minimum VDD1 voltage (in millivolts) for this OPP
- *
- * Operating performance point data. Can vary by OMAP chip and board.
- */
-struct omap_opp {
- unsigned long rate;
- u8 opp_id;
- u16 min_vdd;
-};
-
-extern struct omap_opp *mpu_opps;
-extern struct omap_opp *dsp_opps;
-extern struct omap_opp *l3_opps;
-
/*
* agent_id values for use with omap_pm_set_min_bus_tput():
*
@@ -59,9 +42,11 @@ extern struct omap_opp *l3_opps;
* framework starts. The _if_ is to avoid name collisions with the
* PM idle-loop code.
*/
-int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table,
-struct omap_opp *dsp_opp_table,
-struct omap_opp *l3_opp_table);
+#ifdef CONFIG_OMAP_PM_NONE
+#define omap_pm_if_early_init() 0
+#else
+int __init omap_pm_if_early_init(void);
+#endif
/**
* omap_pm_if_init - OMAP PM init code called after clock fw init
@@ -69,7 +54,11 @@ int __init omap_pm_if_early_init(struct omap_opp
*mpu_opp_table,
* The main initialization code. OPP tables are passed in here. The
* _if_ is to avoid name collisions with the PM idle-loop code.
*/
+#ifdef CONFIG_OMAP_PM_NONE
+#define omap_pm_if_init() 0
+#else
int __init omap_pm_if_init(void);
+#endif
/**
* omap_pm_if_exit - OMAP PM exit code
diff --git a/arch/arm/plat-omap/omap-pm-noop.c
b/arch/arm/plat-omap/omap-pm-noop.c
index e129ce8..ca75abb 100644
--- a/arch/arm/plat-omap/omap-pm-noop.c
+++ b/arch/arm/plat-omap/omap-pm-noop.c
@@ -26,10 +26,6 @@
#include plat/powerdomain.h
-struct omap_opp *dsp_opps;
-struct omap_opp *mpu_opps;
-struct omap_opp *l3_opps;
-
/*
* Device-driver-originated constraints (via board-*.c files)
*/
@@ -308,13 +304,8 @@ int omap_pm_get_dev_context_loss_count(struct device *dev)
/* Should be called before clk framework init */
-int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table,
-struct omap_opp *dsp_opp_table,
-struct omap_opp *l3_opp_table)
+int __init omap_pm_if_early_init(void)
{
- mpu_opps = mpu_opp_table;
- dsp_opps = dsp_opp_table;
- l3_opps = l3_opp_table;
return 0;
}
--
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
[PATCH v6 0/3 Resend] OMAP: Add opp data
Hi, This series introduces OPP data for OMAP3 and 4 with relevant cleanups in OMAP's pm layer. Additional patches for cpufreq interface to OPP library + enablement of SmartReflex, voltage layers depend on the data made available here. Major changes in V6: Looping in L-a + added Paul's Ack in patch 3/3 http://marc.info/?l=linux-omapm=129185174709566w=2 rebased to 2.6.37-rc5 Major changes in V5: rebased to k.org 2.6.37-rc3 introduced omap_opp_data.h couple of whitespace and offline license suggestion cleanups V4: http://marc.info/?l=linux-omapm=128993367112637w=2 V3: http://marc.info/?l=linux-omapm=128984926812800w=2 V2: http://marc.info/?t=12875366533r=1w=2 Kevin Hilman (1): OMAP3: remove OPP interfaces from OMAP PM layer Nishanth Menon (2): omap: opp: add OMAP3 OPP table data and common init omap4: opp: add OPP table data Documentation/arm/OMAP/omap_pm| 25 +++ arch/arm/mach-omap2/Kconfig |4 + arch/arm/mach-omap2/Makefile |6 ++ arch/arm/mach-omap2/io.c |3 +- arch/arm/mach-omap2/omap_opp_data.h | 72 +++ arch/arm/mach-omap2/opp.c | 93 + arch/arm/mach-omap2/opp3xxx_data.c| 107 + arch/arm/mach-omap2/opp4xxx_data.c| 57 +++ arch/arm/mach-omap2/pm.h | 14 arch/arm/plat-omap/include/plat/omap-pm.h | 31 +++-- arch/arm/plat-omap/omap-pm-noop.c | 11 +--- 11 files changed, 390 insertions(+), 33 deletions(-) create mode 100644 arch/arm/mach-omap2/omap_opp_data.h create mode 100644 arch/arm/mach-omap2/opp.c create mode 100644 arch/arm/mach-omap2/opp3xxx_data.c create mode 100644 arch/arm/mach-omap2/opp4xxx_data.c Bloat-o-meter report for omap2plus_defconfig Vs 2.6.37-rc5: add/remove: 22/3 grow/shrink: 4/3 up/down: 3143/-64 (3079) function old new delta opp_add- 576+576 opp_set_availability - 524+524 omap_init_opp_table- 332+332 omap34xx_opp_def_list - 208+208 static.__func__13783 13954+171 opp_find_freq_floor- 160+160 omap36xx_opp_def_list - 160+160 opp_find_freq_ceil - 152+152 opp_find_freq_exact- 128+128 find_device_opp- 116+116 opp_get_opp_count - 108+108 omap44xx_opp_def_list - 96 +96 omap3_opp_init - 76 +76 opp_get_voltage- 72 +72 opp_get_freq - 72 +72 dev_opp_list_lock - 72 +72 omap4_opp_init - 48 +48 vermagic 45 60 +15 linux_banner 131 146 +15 kernel_config_data 13718 13727 +9 opp_enable - 8 +8 opp_disable- 8 +8 dev_opp_list - 8 +8 __initcall_omap4_opp_init6 - 4 +4 __initcall_omap3_opp_init6 - 4 +4 omap_table_init- 1 +1 omap_pm_cpu_set_freq 28 24 -4 mpu_opps 4 - -4 l3_opps4 - -4 dsp_opps 4 - -4 omap_pm_if_early_init 20 8 -12 omap2_init_common_hw 464 428 -36 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
[PATCH v5 1/3] omap: opp: add OMAP3 OPP table data and common init
Add OPP data for OMAP34xx and OMAP36xx and initialization functions
to populate OPP tables based on current SoC.
introduce an OMAP generic opp initialization routine which OMAP3
and OMAP4+ SoCs can use to register their OPP definitions.
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Nishanth Menon n...@ti.com
---
v5: introduced new header for data structures to be used by data files
bit of licensing + whitespace cleanups
introduced ARCH_HAS_OPP after rebasing to rc3
v4: http://marc.info/?t=12899337928r=1w=2
Comments from Thomas addressed:
* Data switched to .c file and included in opp.c
* init_table will fail with -EEXIST if already called
* minor comment improvements
Not addressed:
* request for board files to explicitly call init table
as discussed http://marc.info/?l=linux-omapm=128992417530385w=2
v3: http://marc.info/?t=12898493916r=1w=2
* added documentation for custom opp modification
by board files
* switched to using device_initcall to autoinitialize the
opp tables
v2: https://patchwork.kernel.org/patch/266911/
Documentation/arm/OMAP/omap_pm | 25
arch/arm/mach-omap2/Kconfig |2 +
arch/arm/mach-omap2/Makefile|6 ++
arch/arm/mach-omap2/omap_opp_data.h | 72 +++
arch/arm/mach-omap2/opp.c | 93 ++
arch/arm/mach-omap2/opp3xxx_data.c | 107 +++
arch/arm/mach-omap2/pm.h|9 +++
7 files changed, 314 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap_opp_data.h
create mode 100644 arch/arm/mach-omap2/opp.c
create mode 100644 arch/arm/mach-omap2/opp3xxx_data.c
diff --git a/Documentation/arm/OMAP/omap_pm b/Documentation/arm/OMAP/omap_pm
index 5389440..9012bb0 100644
--- a/Documentation/arm/OMAP/omap_pm
+++ b/Documentation/arm/OMAP/omap_pm
@@ -127,3 +127,28 @@ implementation needs:
10. (*pdata-cpu_set_freq)(unsigned long f)
11. (*pdata-cpu_get_freq)(void)
+
+Customizing OPP for platform
+
+Defining CONFIG_PM should enable OPP layer for the silicon
+and the registration of OPP table should take place automatically.
+However, in special cases, the default OPP table may need to be
+tweaked, for e.g.:
+ * enable default OPPs which are disabled by default, but which
+ could be enabled on a platform
+ * Disable an unsupported OPP on the platform
+ * Define and add a custom opp table entry
+in these cases, the board file needs to do additional steps as follows:
+arch/arm/mach-omapx/board-xyz.c
+ #include pm.h
+
+ static void __init omap_xyz_init_irq(void)
+ {
+
+ /* Initialize the default table */
+ omapx_opp_init();
+ /* Do customization to the defaults */
+
+ }
+NOTE: omapx_opp_init will be omap3_opp_init or as required
+based on the omap family.
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index ab784bf..102a7df 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -35,6 +35,8 @@ config ARCH_OMAP3
select CPU_V7
select USB_ARCH_HAS_EHCI
select ARM_L1_CACHE_SHIFT_6 if !ARCH_OMAP4
+ select ARCH_HAS_OPP
+ select PM_OPP if PM
config ARCH_OMAP4
bool TI OMAP4
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 60e51bc..fbbb6b3 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -47,6 +47,12 @@ obj-$(CONFIG_ARCH_OMAP3) += mux34xx.o
obj-$(CONFIG_ARCH_OMAP2) += sdrc2xxx.o
# obj-$(CONFIG_ARCH_OMAP3) += sdrc3xxx.o
+# OPP table initialization
+ifeq ($(CONFIG_PM_OPP),y)
+obj-y += opp.o
+obj-$(CONFIG_ARCH_OMAP3) += opp3xxx_data.o
+endif
+
# Power Management
ifeq ($(CONFIG_PM),y)
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
diff --git a/arch/arm/mach-omap2/omap_opp_data.h
b/arch/arm/mach-omap2/omap_opp_data.h
new file mode 100644
index 000..46ac27d
--- /dev/null
+++ b/arch/arm/mach-omap2/omap_opp_data.h
@@ -0,0 +1,72 @@
+/*
+ * OMAP SoC specific OPP Data helpers
+ *
+ * Copyright (C) 2009-2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Nishanth Menon
+ * Kevin Hilman
+ * Copyright (C) 2010 Nokia Corporation.
+ * Eduardo Valentin
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ *
Re: [PATCH v3] OMAP2+: PM/serial: fix console semaphore acquire during suspend
Vitaly Wool vitalyw...@gmail.com writes:
On Wed, Dec 8, 2010 at 11:40 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
@@ -120,8 +133,9 @@ static void omap2_enter_full_retention(void)
goto no_sleep;
/* Block console output in case it is on one of the OMAP UARTs */
- if (try_acquire_console_sem())
- goto no_sleep;
+ if (!is_suspending())
+ if (try_acquire_console_sem())
+ goto no_sleep;
Combine into one if?
personal preference I guess. I prefer it nested.
snip
omap_uart_prepare_idle(0);
omap_uart_prepare_idle(1);
@@ -136,7 +150,8 @@ static void omap2_enter_full_retention(void)
omap_uart_resume_idle(1);
omap_uart_resume_idle(0);
- release_console_sem();
+ if (!is_suspending())
+ release_console_sem();
no_sleep:
if (omap2_pm_debug) {
@@ -284,6 +299,12 @@ out:
local_irq_enable();
}
+static int omap2_pm_begin(suspend_state_t state)
+{
+ suspend_state = state;
+ return 0;
+}
Do you really need a return code here?
yes, this function prototype is defined by the driver model, not by me.
static int omap2_pm_prepare(void)
{
/* We cannot sleep in idle until we have resumed */
@@ -333,10 +354,18 @@ static void omap2_pm_finish(void)
enable_hlt();
}
+static void omap2_pm_end(void)
+{
+ suspend_state = PM_SUSPEND_ON;
+ return;
+}
Redundant return.
but harmless
+
static struct platform_suspend_ops omap_pm_ops = {
+ .begin = omap2_pm_begin,
.prepare = omap2_pm_prepare,
.enter = omap2_pm_enter,
.finish = omap2_pm_finish,
+ .end = omap2_pm_end,
.valid = suspend_valid_only_mem,
};
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 0ec8a04..648b8c5 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -50,6 +50,19 @@
#include sdrc.h
#include control.h
+#ifdef CONFIG_SUSPEND
+static suspend_state_t suspend_state = PM_SUSPEND_ON;
+static inline bool is_suspending(void)
+{
+ return (suspend_state != PM_SUSPEND_ON);
+}
+#else
+static inline bool is_suspending(void)
+{
+ return false;
+}
+#endif
+
/* Scratchpad offsets */
#define OMAP343X_TABLE_ADDRESS_OFFSET 0xc4
#define OMAP343X_TABLE_VALUE_OFFSET 0xc0
@@ -387,10 +400,11 @@ void omap_sram_idle(void)
}
/* Block console output in case it is on one of the OMAP UARTs */
- if (per_next_state PWRDM_POWER_ON ||
- core_next_state PWRDM_POWER_ON)
- if (try_acquire_console_sem())
- goto console_still_active;
+ if (!is_suspending())
+ if (per_next_state PWRDM_POWER_ON ||
+ core_next_state PWRDM_POWER_ON)
+ if (try_acquire_console_sem())
+ goto console_still_active;
Oh well, 3 nested ifs...
again, personal preference.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8] arm: omap: add support for RM-680
These patches add initial support for Nokia RM-680 board.
Patches 1-7 are just preparation and make board-rx51-sdram.c reusable
by renaming it to sdram-nokia.c etc.
Patch 8 adds a new board and requires updated mach-types from
http://www.arm.linux.org.uk/developer/machines/download.php in order
to compile.
These are based on top of linux-omap/master
(92f446c47b18827e61483787668b0bb5f7a033b6).
...
Aaro Koskinen (8):
arm: omap: rename board-rx51-sdram.c to sdram-nokia.c
arm: omap: add sdram-nokia.h
arm: omap: sdram-nokia: prepare for new memory timings
arm: omap: sdram-nokia: use array to list timings
arm: omap: sdram-nokia: improve error handling
arm: omap: sdram-nokia: delete redundant timing data
arm: omap: sdram-nokia: add 97.6/195.2 MHz timing data
arm: omap: add minimal support for RM-680
arch/arm/mach-omap2/Kconfig|6 +
arch/arm/mach-omap2/Makefile |5 +-
arch/arm/mach-omap2/board-rm680.c | 187
arch/arm/mach-omap2/board-rx51.c |4 +-
.../{board-rx51-sdram.c = sdram-nokia.c} | 102 +---
arch/arm/mach-omap2/sdram-nokia.h | 12 ++
arch/arm/plat-omap/include/plat/uncompress.h |1 +
7 files changed, 292 insertions(+), 25 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-rm680.c
rename arch/arm/mach-omap2/{board-rx51-sdram.c = sdram-nokia.c} (66%)
create mode 100644 arch/arm/mach-omap2/sdram-nokia.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 2/8] arm: omap: add sdram-nokia.h
Add a header file for Nokia SDRAM functions. Based on patches by Juha
Keski-Saari.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
arch/arm/mach-omap2/board-rx51.c |2 +-
arch/arm/mach-omap2/sdram-nokia.c |1 +
arch/arm/mach-omap2/sdram-nokia.h | 12
3 files changed, 14 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/sdram-nokia.h
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index b7df8e3..7362c91 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -32,10 +32,10 @@
#include mux.h
#include pm.h
+#include sdram-nokia.h
#define RX51_GPIO_SLEEP_IND 162
-struct omap_sdrc_params *nokia_get_sdram_timings(void);
extern void rx51_video_mem_init(void);
static struct gpio_led gpio_leds[] = {
diff --git a/arch/arm/mach-omap2/sdram-nokia.c
b/arch/arm/mach-omap2/sdram-nokia.c
index 690202b..261efc8 100644
--- a/arch/arm/mach-omap2/sdram-nokia.c
+++ b/arch/arm/mach-omap2/sdram-nokia.c
@@ -22,6 +22,7 @@
#include plat/clock.h
#include plat/sdrc.h
+#include sdram-nokia.h
/* In picoseconds, except for tREF (ns), tXP, tCKE, tWTR (clks) */
struct sdram_timings {
diff --git a/arch/arm/mach-omap2/sdram-nokia.h
b/arch/arm/mach-omap2/sdram-nokia.h
new file mode 100644
index 000..ee63da5
--- /dev/null
+++ b/arch/arm/mach-omap2/sdram-nokia.h
@@ -0,0 +1,12 @@
+/*
+ * SDRC register values for Nokia boards
+ *
+ * Copyright (C) 2010 Nokia
+ *
+ * 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.
+ */
+
+struct omap_sdrc_params *nokia_get_sdram_timings(void);
+
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] arm: omap: rename board-rx51-sdram.c to sdram-nokia.c
Rename the file and functions so that it can be reused by future Nokia
boards. Based on patches by Juha Keski-Saari.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/board-rx51.c |4 +-
.../{board-rx51-sdram.c = sdram-nokia.c} | 34 ++--
3 files changed, 20 insertions(+), 20 deletions(-)
rename arch/arm/mach-omap2/{board-rx51-sdram.c = sdram-nokia.c} (85%)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fbc8739..3a71d19 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -141,7 +141,7 @@ obj-$(CONFIG_MACH_OMAP_3430SDP) +=
board-3430sdp.o \
board-flash.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
- board-rx51-sdram.o \
+ sdram-nokia.o \
board-rx51-peripherals.o \
board-rx51-video.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 6635142..b7df8e3 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -35,7 +35,7 @@
#define RX51_GPIO_SLEEP_IND 162
-struct omap_sdrc_params *rx51_get_sdram_timings(void);
+struct omap_sdrc_params *nokia_get_sdram_timings(void);
extern void rx51_video_mem_init(void);
static struct gpio_led gpio_leds[] = {
@@ -105,7 +105,7 @@ static void __init rx51_init_irq(void)
omap_board_config = rx51_config;
omap_board_config_size = ARRAY_SIZE(rx51_config);
omap3_pm_init_cpuidle(rx51_cpuidle_params);
- sdrc_params = rx51_get_sdram_timings();
+ sdrc_params = nokia_get_sdram_timings();
omap2_init_common_hw(sdrc_params, sdrc_params);
omap_init_irq();
}
diff --git a/arch/arm/mach-omap2/board-rx51-sdram.c
b/arch/arm/mach-omap2/sdram-nokia.c
similarity index 85%
rename from arch/arm/mach-omap2/board-rx51-sdram.c
rename to arch/arm/mach-omap2/sdram-nokia.c
index a43b2c5..690202b 100644
--- a/arch/arm/mach-omap2/board-rx51-sdram.c
+++ b/arch/arm/mach-omap2/sdram-nokia.c
@@ -1,7 +1,7 @@
/*
- * SDRC register values for RX51
+ * SDRC register values for Nokia boards
*
- * Copyright (C) 2008 Nokia Corporation
+ * Copyright (C) 2008, 2010 Nokia Corporation
*
* Lauri Leukkunen lauri.leukku...@nokia.com
*
@@ -43,9 +43,9 @@ struct sdram_timings {
u32 tWTR;
};
-static struct omap_sdrc_params rx51_sdrc_params[4];
+static struct omap_sdrc_params nokia_sdrc_params[4];
-static const struct sdram_timings rx51_timings[] = {
+static const struct sdram_timings memory_timings[] = {
{
.casl = 3,
.tDAL = 33000,
@@ -110,12 +110,12 @@ static int set_sdrc_timing_regval(u32 *regval, int
st_bit, int end_bit,
#ifdef DEBUG
#define SDRC_SET_ONE(reg, st, end, field, rate) \
if (set_sdrc_timing_regval((reg), (st), (end), \
- rx51_timings-field, (rate), #field) 0) \
+ memory_timings-field, (rate), #field) 0) \
err = -1;
#else
#define SDRC_SET_ONE(reg, st, end, field, rate) \
if (set_sdrc_timing_regval((reg), (st), (end), \
- rx51_timings-field) 0) \
+ memory_timings-field) 0) \
err = -1;
#endif
@@ -148,14 +148,14 @@ static int set_sdrc_timing_regval_ps(u32 *regval, int
st_bit, int end_bit,
#ifdef DEBUG
#define SDRC_SET_ONE_PS(reg, st, end, field, rate) \
if (set_sdrc_timing_regval_ps((reg), (st), (end), \
- rx51_timings-field, \
+ memory_timings-field, \
(rate), #field) 0) \
err = -1;
#else
#define SDRC_SET_ONE_PS(reg, st, end, field, rate) \
if (set_sdrc_timing_regval_ps((reg), (st), (end), \
- rx51_timings-field, (rate)) 0) \
+ memory_timings-field, (rate)) 0) \
err = -1;
#endif
@@ -184,7 +184,7 @@ static int sdrc_timings(int id, long rate)
SDRC_SET_ONE(actim_ctrlb, 16, 17, tWTR, l3_rate);
ticks_per_ms = l3_rate;
- rfr = rx51_timings[0].tREF * ticks_per_ms / 100;
+ rfr = memory_timings[0].tREF * ticks_per_ms / 100;
if (rfr 65535 + 50)
rfr = 65535;
else
@@ -197,18 +197,18 @@ static int sdrc_timings(int id, long rate)
l = rfr 8;
rfr_ctrl = l | 0x1; /* autorefresh, reload counter with 1xARCV */
- rx51_sdrc_params[id].rate = rate;
- rx51_sdrc_params[id].actim_ctrla = actim_ctrla;
- rx51_sdrc_params[id].actim_ctrlb = actim_ctrlb;
- rx51_sdrc_params[id].rfr_ctrl = rfr_ctrl;
[PATCH 3/8] arm: omap: sdram-nokia: prepare for new memory timings
Rename the current timings to indicate they're for 166 MHz. Based on
patches by Eduardo Valentin and Juha Keski-Saari.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
Cc: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/mach-omap2/sdram-nokia.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/sdram-nokia.c
b/arch/arm/mach-omap2/sdram-nokia.c
index 261efc8..97d1673 100644
--- a/arch/arm/mach-omap2/sdram-nokia.c
+++ b/arch/arm/mach-omap2/sdram-nokia.c
@@ -46,7 +46,7 @@ struct sdram_timings {
static struct omap_sdrc_params nokia_sdrc_params[4];
-static const struct sdram_timings memory_timings[] = {
+static const struct sdram_timings nokia_166mhz_timings[] = {
{
.casl = 3,
.tDAL = 33000,
@@ -160,7 +160,8 @@ static int set_sdrc_timing_regval_ps(u32 *regval, int
st_bit, int end_bit,
err = -1;
#endif
-static int sdrc_timings(int id, long rate)
+static int sdrc_timings(int id, long rate,
+ const struct sdram_timings *memory_timings)
{
u32 ticks_per_ms;
u32 rfr, l;
@@ -213,9 +214,9 @@ struct omap_sdrc_params *nokia_get_sdram_timings(void)
{
int err;
- err = sdrc_timings(0, 4150);
- err |= sdrc_timings(1, 8300);
- err |= sdrc_timings(2, 16600);
+ err = sdrc_timings(0, 4150, nokia_166mhz_timings);
+ err |= sdrc_timings(1, 8300, nokia_166mhz_timings);
+ err |= sdrc_timings(2, 16600, nokia_166mhz_timings);
return nokia_sdrc_params[0];
}
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8] arm: omap: sdram-nokia: use array to list timings
Use an array to make it easier to add new values.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
arch/arm/mach-omap2/sdram-nokia.c | 21 +++--
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/sdram-nokia.c
b/arch/arm/mach-omap2/sdram-nokia.c
index 97d1673..1171451 100644
--- a/arch/arm/mach-omap2/sdram-nokia.c
+++ b/arch/arm/mach-omap2/sdram-nokia.c
@@ -44,8 +44,6 @@ struct sdram_timings {
u32 tWTR;
};
-static struct omap_sdrc_params nokia_sdrc_params[4];
-
static const struct sdram_timings nokia_166mhz_timings[] = {
{
.casl = 3,
@@ -67,6 +65,16 @@ static const struct sdram_timings nokia_166mhz_timings[] = {
},
};
+static const struct {
+ long rate;
+ struct sdram_timings const *data;
+} nokia_timings[] = {
+ { 4150, nokia_166mhz_timings },
+ { 8300, nokia_166mhz_timings },
+ { 16600, nokia_166mhz_timings },
+};
+static struct omap_sdrc_params nokia_sdrc_params[ARRAY_SIZE(nokia_timings) +
1];
+
static unsigned long sdrc_get_fclk_period(long rate)
{
/* In picoseconds */
@@ -212,11 +220,12 @@ static int sdrc_timings(int id, long rate,
struct omap_sdrc_params *nokia_get_sdram_timings(void)
{
- int err;
+ int err = 0;
+ int i;
- err = sdrc_timings(0, 4150, nokia_166mhz_timings);
- err |= sdrc_timings(1, 8300, nokia_166mhz_timings);
- err |= sdrc_timings(2, 16600, nokia_166mhz_timings);
+ for (i = 0; i ARRAY_SIZE(nokia_timings); i++)
+ err |= sdrc_timings(i, nokia_timings[i].rate,
+ nokia_timings[i].data);
return nokia_sdrc_params[0];
}
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] arm: omap: sdram-nokia: improve error handling
Actually check for errors: print an error log and return NULL.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
arch/arm/mach-omap2/sdram-nokia.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/sdram-nokia.c
b/arch/arm/mach-omap2/sdram-nokia.c
index 1171451..863586b 100644
--- a/arch/arm/mach-omap2/sdram-nokia.c
+++ b/arch/arm/mach-omap2/sdram-nokia.c
@@ -223,10 +223,14 @@ struct omap_sdrc_params *nokia_get_sdram_timings(void)
int err = 0;
int i;
- for (i = 0; i ARRAY_SIZE(nokia_timings); i++)
+ for (i = 0; i ARRAY_SIZE(nokia_timings); i++) {
err |= sdrc_timings(i, nokia_timings[i].rate,
nokia_timings[i].data);
+ if (err)
+ pr_err(%s: error with rate %ld: %d\n, __func__,
+ nokia_timings[i].rate, err);
+ }
- return nokia_sdrc_params[0];
+ return err ? NULL : nokia_sdrc_params;
}
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] arm: omap: sdram-nokia: delete redundant timing data
41.5 MHz SDRAM clock is not usable.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
arch/arm/mach-omap2/sdram-nokia.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/sdram-nokia.c
b/arch/arm/mach-omap2/sdram-nokia.c
index 863586b..baf83ec 100644
--- a/arch/arm/mach-omap2/sdram-nokia.c
+++ b/arch/arm/mach-omap2/sdram-nokia.c
@@ -69,7 +69,6 @@ static const struct {
long rate;
struct sdram_timings const *data;
} nokia_timings[] = {
- { 4150, nokia_166mhz_timings },
{ 8300, nokia_166mhz_timings },
{ 16600, nokia_166mhz_timings },
};
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] arm: omap: sdram-nokia: add 97.6/195.2 MHz timing data
Introduce 97.6/195.2 MHz memory timing data. Based on patches by Eduardo
Valentin, Igor Dmitriev and Juha Keski-Saari.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
Cc: Eduardo Valentin eduardo.valen...@nokia.com
Cc: Igor Dmitriev ext-dmitriev.i...@nokia.com
---
arch/arm/mach-omap2/sdram-nokia.c | 44 +
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/sdram-nokia.c
b/arch/arm/mach-omap2/sdram-nokia.c
index baf83ec..14caa22 100644
--- a/arch/arm/mach-omap2/sdram-nokia.c
+++ b/arch/arm/mach-omap2/sdram-nokia.c
@@ -44,6 +44,27 @@ struct sdram_timings {
u32 tWTR;
};
+static const struct sdram_timings nokia_97dot6mhz_timings[] = {
+ {
+ .casl = 3,
+ .tDAL = 30725,
+ .tDPL = 15362,
+ .tRRD = 10241,
+ .tRCD = 20483,
+ .tRP = 15362,
+ .tRAS = 40967,
+ .tRC = 56330,
+ .tRFC = 138266,
+ .tXSR = 204839,
+
+ .tREF = 7798,
+
+ .tXP = 2,
+ .tCKE = 4,
+ .tWTR = 2,
+ },
+};
+
static const struct sdram_timings nokia_166mhz_timings[] = {
{
.casl = 3,
@@ -65,12 +86,35 @@ static const struct sdram_timings nokia_166mhz_timings[] = {
},
};
+static const struct sdram_timings nokia_195dot2mhz_timings[] = {
+ {
+ .casl = 3,
+ .tDAL = 30725,
+ .tDPL = 15362,
+ .tRRD = 10241,
+ .tRCD = 20483,
+ .tRP = 15362,
+ .tRAS = 40967,
+ .tRC = 56330,
+ .tRFC = 138266,
+ .tXSR = 204839,
+
+ .tREF = 7752,
+
+ .tXP = 2,
+ .tCKE = 4,
+ .tWTR = 2,
+ },
+};
+
static const struct {
long rate;
struct sdram_timings const *data;
} nokia_timings[] = {
{ 8300, nokia_166mhz_timings },
+ { 9760, nokia_97dot6mhz_timings },
{ 16600, nokia_166mhz_timings },
+ { 19520, nokia_195dot2mhz_timings },
};
static struct omap_sdrc_params nokia_sdrc_params[ARRAY_SIZE(nokia_timings) +
1];
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8] arm: omap: add minimal support for RM-680
Add minimal support for Nokia RM-680 board.
Tested with omap2plus_defconfig.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
arch/arm/mach-omap2/Kconfig |6 +
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/board-rm680.c| 187 ++
arch/arm/plat-omap/include/plat/uncompress.h |1 +
4 files changed, 197 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-rm680.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b67b1a9..9c317d6 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -221,6 +221,12 @@ config MACH_NOKIA_N8X0
select MACH_NOKIA_N810
select MACH_NOKIA_N810_WIMAX
+config MACH_NOKIA_RM680
+ bool Nokia RM-680 board
+ depends on ARCH_OMAP3
+ default y
+ select OMAP_PACKAGE_CBB
+
config MACH_NOKIA_RX51
bool Nokia RX-51 board
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 3a71d19..25bc945 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -140,6 +140,9 @@ obj-$(CONFIG_MACH_OMAP_3430SDP) +=
board-3430sdp.o \
hsmmc.o \
board-flash.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
+obj-$(CONFIG_MACH_NOKIA_RM680) += board-rm680.o \
+ sdram-nokia.o \
+ hsmmc.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
sdram-nokia.o \
board-rx51-peripherals.o \
diff --git a/arch/arm/mach-omap2/board-rm680.c
b/arch/arm/mach-omap2/board-rm680.c
new file mode 100644
index 000..2966314
--- /dev/null
+++ b/arch/arm/mach-omap2/board-rm680.c
@@ -0,0 +1,187 @@
+/*
+ * Board support file for Nokia RM-680.
+ *
+ * Copyright (C) 2010 Nokia
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/io.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/init.h
+#include linux/i2c/twl.h
+#include linux/platform_device.h
+#include linux/regulator/fixed.h
+#include linux/regulator/machine.h
+#include linux/regulator/consumer.h
+
+#include asm/mach/arch.h
+#include asm/mach-types.h
+
+#include plat/i2c.h
+#include plat/mmc.h
+#include plat/usb.h
+#include plat/gpmc.h
+#include plat/common.h
+#include plat/onenand.h
+
+#include mux.h
+#include hsmmc.h
+#include sdram-nokia.h
+
+static struct regulator_consumer_supply rm680_vemmc_consumers[] = {
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1),
+};
+
+/* Fixed regulator for internal eMMC */
+static struct regulator_init_data rm680_vemmc = {
+ .constraints = {
+ .name = rm680_vemmc,
+ .min_uV = 290,
+ .max_uV = 290,
+ .apply_uV = 1,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS
+ | REGULATOR_CHANGE_MODE,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(rm680_vemmc_consumers),
+ .consumer_supplies = rm680_vemmc_consumers,
+};
+
+static struct fixed_voltage_config rm680_vemmc_config = {
+ .supply_name= VEMMC,
+ .microvolts = 290,
+ .gpio = 157,
+ .startup_delay = 150,
+ .enable_high= 1,
+ .init_data = rm680_vemmc,
+};
+
+static struct platform_device rm680_vemmc_device = {
+ .name = reg-fixed-voltage,
+ .dev= {
+ .platform_data = rm680_vemmc_config,
+ },
+};
+
+static struct platform_device *rm680_peripherals_devices[] __initdata = {
+ rm680_vemmc_device,
+};
+
+/* TWL */
+static struct twl4030_gpio_platform_data rm680_gpio_data = {
+ .gpio_base = OMAP_MAX_GPIO_LINES,
+ .irq_base = TWL4030_GPIO_IRQ_BASE,
+ .irq_end= TWL4030_GPIO_IRQ_END,
+ .pullups= BIT(0),
+ .pulldowns = BIT(1) | BIT(2) | BIT(8) | BIT(15),
+};
+
+static struct twl4030_usb_data rm680_usb_data = {
+ .usb_mode = T2_USB_MODE_ULPI,
+};
+
+static struct twl4030_platform_data rm680_twl_data = {
+ .irq_base = TWL4030_IRQ_BASE,
+ .irq_end= TWL4030_IRQ_END,
+ .gpio = rm680_gpio_data,
+ .usb= rm680_usb_data,
+
Re: [PATCH 2/8] arm: omap: add sdram-nokia.h
Aaro Koskinen had written, on 12/09/2010 10:39 AM, the following: [...] diff --git a/arch/arm/mach-omap2/sdram-nokia.h b/arch/arm/mach-omap2/sdram-nokia.h new file mode 100644 index 000..ee63da5 --- /dev/null +++ b/arch/arm/mach-omap2/sdram-nokia.h @@ -0,0 +1,12 @@ +/* + * SDRC register values for Nokia boards + * + * Copyright (C) 2010 Nokia + * + * 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. + */ + +struct omap_sdrc_params *nokia_get_sdram_timings(void); + Minor comment: Header guard missing. maybe nice to add #ifndef, #def, #endif. 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 v2 1/2] I2C: i2c-omap: Change device name: i2c_omap - omap_i2c
Ben,
Benoit Cousson b-cous...@ti.com writes:
The convention for omap device naming is omap_XXX.
Rename the device and driver name in order to stick
to this naming convention.
Change device name in clock nodes as well.
Signed-off-by: Benoit Cousson b-cous...@ti.com
c: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Ben Dooks ben-...@fluff.org
---
arch/arm/mach-omap1/clock_data.c |6 +++---
arch/arm/mach-omap2/clock2420_data.c |8
arch/arm/mach-omap2/clock2430_data.c |8
arch/arm/mach-omap2/clock3xxx_data.c | 12 ++--
arch/arm/mach-omap2/clock44xx_data.c | 16
arch/arm/plat-omap/i2c.c |2 +-
drivers/i2c/busses/i2c-omap.c|4 ++--
7 files changed, 28 insertions(+), 28 deletions(-)
[...]
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 760b8be..9d09083 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1139,7 +1139,7 @@ static struct platform_driver omap_i2c_driver = {
.probe = omap_i2c_probe,
.remove = omap_i2c_remove,
.driver = {
- .name = i2c_omap,
+ .name = omap_i2c,
.owner = THIS_MODULE,
},
};
@@ -1161,4 +1161,4 @@ module_exit(omap_i2c_exit_driver);
MODULE_AUTHOR(MontaVista Software, Inc. (and others));
MODULE_DESCRIPTION(TI OMAP I2C bus adapter);
MODULE_LICENSE(GPL);
-MODULE_ALIAS(platform:i2c_omap);
+MODULE_ALIAS(platform:omap_i2c);
With your ack for the name change in the driver, we can merge this
through the OMAP tree with the other core changes.
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 v2 0/2] OMAP: I2C and UART device name cleanup
Benoit Cousson b-cous...@ti.com writes: Hi All, In order to enforce a little bit of consistency in the omap devices name, the convention for omap devices name will be now omap_xxx. All the drivers adapted to hwmod will be named like that during the on-going adaptations. The I2C and UART drivers are already adapted to hwmod but with the originals name. Rename i2c and uart using this convention: i2c_omap - omap_i2c omap-hsuart - omap_uart Tested on OMAP4 ES2 on Panda / sdp4430. Some more validation will be needed on OMAP2 3. This series is based on Kevin's pm-hwmod-i2c branch and is available here: git://gitorious.org/omap-pm/linux.git for_2.6.38/device_name Acked-by: Kevin Hilman khil...@deeprootsystems.com Regards, Benoit v1 http://www.spinics.net/lists/linux-omap/msg41474.html Merge previous patch #1 and #2 as suggested by Kevin to change the driver name at the same time with the device name in the clockdev. Benoit Cousson (2): I2C: i2c-omap: Change device name: i2c_omap - omap_i2c OMAP: serial: Change device name: omap-hsuart - omap_uart arch/arm/mach-omap1/clock_data.c |6 +++--- arch/arm/mach-omap2/clock2420_data.c |8 arch/arm/mach-omap2/clock2430_data.c |8 arch/arm/mach-omap2/clock3xxx_data.c | 12 ++-- arch/arm/mach-omap2/clock44xx_data.c | 16 arch/arm/plat-omap/i2c.c |2 +- arch/arm/plat-omap/include/plat/omap-serial.h |2 +- drivers/i2c/busses/i2c-omap.c |4 ++-- 8 files changed, 29 insertions(+), 29 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] arm: omap4: panda: fix initialize musb
From: Ming Lei tom.leim...@gmail.com Obviously we should only initialize musb once. Signed-off-by: Ming Lei tom.leim...@gmail.com --- arch/arm/mach-omap2/board-omap4panda.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c index 22599fc..85371be 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -393,9 +393,6 @@ static void __init omap4_panda_init(void) usb_nop_xceiv_register(); omap4_ehci_init(); usb_musb_init(musb_board_data); - /* FIXME: allow multi-omap to boot until musb is updated for omap4 */ - if (!cpu_is_omap44xx()) - usb_musb_init(musb_board_data); } static void __init omap4_panda_map_io(void) -- 1.7.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
Re: [PATCH 8/8] arm: omap: add minimal support for RM-680
Hi Aaro,
A couple of small comments below, otherwise looks nice to me.
Jamie
On Thu, Dec 09, 2010 at 06:39:24PM +0200, Aaro Koskinen wrote:
Add minimal support for Nokia RM-680 board.
Tested with omap2plus_defconfig.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
[...]
+#if defined(CONFIG_MTD_ONENAND_OMAP2) || \
+ defined(CONFIG_MTD_ONENAND_OMAP2_MODULE)
+static struct omap_onenand_platform_data board_onenand_data[] = {
+ {
+ .gpio_irq = 65,
+ .flags = ONENAND_SYNC_READWRITE,
+ }
+};
+#endif
+
+/* eMMC */
+static struct omap2_hsmmc_info mmc[] __initdata = {
+ {
+ .name = internal,
+ .mmc= 2,
+ .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_MMC_HIGHSPEED,
+ .gpio_cd= -EINVAL,
+ .gpio_wp= -EINVAL,
+ },
+ { /* Terminator */ }
+};
+
+static void __init rm680_peripherals_init(void)
+{
+ platform_add_devices(rm680_peripherals_devices,
+ ARRAY_SIZE(rm680_peripherals_devices));
+ rm680_i2c_init();
+ gpmc_onenand_init(board_onenand_data);
What happens if CONFIG_MTD_ONENAND_OMAP2=n and
CONFIG_MTD_ONENAND_OMAP2_MODULE=n? Do you need to define board_onenand_data to
NULL if these aren't enabled?
+ omap2_hsmmc_init(mmc);
+}
+
+static void __init rm680_init_irq(void)
+{
+ struct omap_sdrc_params *sdrc_params;
+
+ sdrc_params = nokia_get_sdram_timings();
+ omap2_init_common_hw(sdrc_params, sdrc_params);
+ omap_init_irq();
+ omap_gpio_init();
+}
+
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#endif
+
+static struct omap_musb_board_data rm680_musb_data = {
+ .interface_type = MUSB_INTERFACE_ULPI,
+ .mode = MUSB_PERIPHERAL,
+ .power = 100,
+};
+
+static void __init rm680_init(void)
+{
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
The same here as with the onenand data.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] I2C: i2c-omap: Change device name: i2c_omap - omap_i2c
On Thu, 9 Dec 2010, Benoit Cousson wrote: The convention for omap device naming is omap_XXX. Rename the device and driver name in order to stick to this naming convention. Change device name in clock nodes as well. Acked-by: Paul Walmsley p...@pwsan.com - 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] OMAP: device: make rt_va easily avaialable to drivers
Omar Ramirez Luna omar.rami...@ti.com writes:
Patch OMAP: hwmod/device: add omap_{device, hwmod}_get_mpu_rt_va[1],
introduces omap_device_get_rt_va which is meant to be called
by drivers to retrieve the _mpu_rt_va, however this function
receives a pointer to an omap_device; since there is no
practical way for a driver to get this parameter without
fiddling with pdev and container_of macro, and omap_device code
already does this, it is better for it to handle this case.
Also moved header declaration to appear in the set of
functions to be used by drivers, as per the comment there.
[1] http://marc.info/?l=linux-omapm=127808467703366w=2
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
Looks right, since all the other driver-accessible functions take a
platform_device pointer, not an omap_device pointer.
Acked-by: Kevin Hilman khil...@deeprootsystems.com
However, I thing the subject/shortlog should be clearer. IMO, this
patch makes the API more consistent rather than making it easier.
Also, subject prefix should be preferrably 'OMAP: omap_device:'.
Kevin
---
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: [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
Gopinath, Thara th...@ti.com writes: [...] So for this first version that we plan to push to kernel.org, I plan to expose out these parameters to user space but not allow a write access to them. The write access part can be added later whenever required. OK with me. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap4: panda: fix initialize musb
tom.leim...@gmail.com had written, on 12/09/2010 11:02 AM, the following: From: Ming Lei tom.leim...@gmail.com Obviously we should only initialize musb once. Signed-off-by: Ming Lei tom.leim...@gmail.com --- arch/arm/mach-omap2/board-omap4panda.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c index 22599fc..85371be 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -393,9 +393,6 @@ static void __init omap4_panda_init(void) usb_nop_xceiv_register(); omap4_ehci_init(); usb_musb_init(musb_board_data); - /* FIXME: allow multi-omap to boot until musb is updated for omap4 */ - if (!cpu_is_omap44xx()) - usb_musb_init(musb_board_data); } static void __init omap4_panda_map_io(void) Looks good to me. since this is for l-o master branch, I think this should probably be squashed to: commit ec787afd05aad0cdb0b0d2948b356569805e5b30 Author: Felipe Balbi ba...@ti.com Date: Wed Dec 1 13:48:54 2010 +0200 arm: omap4: panda: initialize musb initialize the musb port on pandaboard. Signed-off-by: Felipe Balbi ba...@ti.com 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 v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
Kevin Hilman had written, on 12/09/2010 11:19 AM, the following: Gopinath, Thara th...@ti.com writes: [...] So for this first version that we plan to push to kernel.org, I plan to expose out these parameters to user space but not allow a write access to them. The write access part can be added later whenever required. OK with me. +1 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 8/8] arm: omap: add minimal support for RM-680
On Thu, Dec 09, 2010 at 07:11:28PM +0200, Aaro Koskinen wrote:
Hi,
On Thu, 9 Dec 2010, Jamie Iles wrote:
+static void __init rm680_peripherals_init(void)
+{
+ platform_add_devices(rm680_peripherals_devices,
+ ARRAY_SIZE(rm680_peripherals_devices));
+ rm680_i2c_init();
+ gpmc_onenand_init(board_onenand_data);
What happens if CONFIG_MTD_ONENAND_OMAP2=n and
CONFIG_MTD_ONENAND_OMAP2_MODULE=n? Do you need to define board_onenand_data
to
NULL if these aren't enabled?
[...]
+static void __init rm680_init(void)
+{
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
The same here as with the onenand data.
Check the following commits in linux-omap tree:
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=5403187f83c12c6f4c03547e0cc05bac0310be7b
and
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=7203f8a48bb63015ebe58a6f2a38aec1cb208b9d
Thanks for the pointer! It looks a bit confusing to my eyes but I guess it's
better than lots of ifdeffery.
Jamie
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] OMAP2+: disable idle early in the suspend sequence
From: Jean Pihet j-pi...@ti.com
Some bad interaction between the idle and the suspend paths has been
identified: the idle code is called during the suspend enter and exit
sequences. This could cause corruption or lock-up of resources.
The solution is to move the calls to disable_hlt at the very beginning
of the suspend sequence (ex. in omap3_pm_begin instead of
omap3_pm_prepare), and the call to enable_hlt at the very end of
the suspend sequence (ex. in omap3_pm_end instead of omap3_pm_finish).
Tested with RET and OFF on Beagle and OMAP3EVM.
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
v1:
Support for OMAP3 only.
Tested on board.
v2:
Added support for OMAP2 and OMAP4.
Compile tested only for OMAP2 and OMAP4.
Tested on board for OMAP3.
v3:
Rebased on Kevin's latest 'OMAP2+: PM/serial: fix console semaphore acquire
during suspend', cf. http://marc.info/?l=linux-omapm=129184804805075w=2
Removed the empty _pm_prepare and _pm_finish functions.
arch/arm/mach-omap2/pm24xx.c | 16 ++--
arch/arm/mach-omap2/pm34xx.c | 15 ++-
arch/arm/mach-omap2/pm44xx.c | 16 ++--
3 files changed, 6 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index 1e031d0..6cde8ed 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -301,14 +301,8 @@ out:
static int omap2_pm_begin(suspend_state_t state)
{
- suspend_state = state;
- return 0;
-}
-
-static int omap2_pm_prepare(void)
-{
- /* We cannot sleep in idle until we have resumed */
disable_hlt();
+ suspend_state = state;
return 0;
}
@@ -349,22 +343,16 @@ static int omap2_pm_enter(suspend_state_t state)
return ret;
}
-static void omap2_pm_finish(void)
-{
- enable_hlt();
-}
-
static void omap2_pm_end(void)
{
suspend_state = PM_SUSPEND_ON;
+ enable_hlt();
return;
}
static struct platform_suspend_ops omap_pm_ops = {
.begin = omap2_pm_begin,
- .prepare= omap2_pm_prepare,
.enter = omap2_pm_enter,
- .finish = omap2_pm_finish,
.end= omap2_pm_end,
.valid = suspend_valid_only_mem,
};
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 648b8c5..5bf344a 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -529,12 +529,6 @@ out:
}
#ifdef CONFIG_SUSPEND
-static int omap3_pm_prepare(void)
-{
- disable_hlt();
- return 0;
-}
-
static int omap3_pm_suspend(void)
{
struct power_state *pwrst;
@@ -597,14 +591,10 @@ static int omap3_pm_enter(suspend_state_t unused)
return ret;
}
-static void omap3_pm_finish(void)
-{
- enable_hlt();
-}
-
/* Hooks to enable / disable UART interrupts during suspend */
static int omap3_pm_begin(suspend_state_t state)
{
+ disable_hlt();
suspend_state = state;
omap_uart_enable_irqs(0);
return 0;
@@ -614,15 +604,14 @@ static void omap3_pm_end(void)
{
suspend_state = PM_SUSPEND_ON;
omap_uart_enable_irqs(1);
+ enable_hlt();
return;
}
static struct platform_suspend_ops omap_pm_ops = {
.begin = omap3_pm_begin,
.end= omap3_pm_end,
- .prepare= omap3_pm_prepare,
.enter = omap3_pm_enter,
- .finish = omap3_pm_finish,
.valid = suspend_valid_only_mem,
};
#endif /* CONFIG_SUSPEND */
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 54544b4..6aff996 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -31,12 +31,6 @@ struct power_state {
static LIST_HEAD(pwrst_list);
#ifdef CONFIG_SUSPEND
-static int omap4_pm_prepare(void)
-{
- disable_hlt();
- return 0;
-}
-
static int omap4_pm_suspend(void)
{
do_wfi();
@@ -59,28 +53,22 @@ static int omap4_pm_enter(suspend_state_t suspend_state)
return ret;
}
-static void omap4_pm_finish(void)
-{
- enable_hlt();
- return;
-}
-
static int omap4_pm_begin(suspend_state_t state)
{
+ disable_hlt();
return 0;
}
static void omap4_pm_end(void)
{
+ enable_hlt();
return;
}
static struct platform_suspend_ops omap_pm_ops = {
.begin = omap4_pm_begin,
.end= omap4_pm_end,
- .prepare= omap4_pm_prepare,
.enter = omap4_pm_enter,
- .finish = omap4_pm_finish,
.valid = suspend_valid_only_mem,
};
#endif /* CONFIG_SUSPEND */
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] OMAP: PRCM/powerdomain/clockdomain patches for 2.6.38, part two
Hello Jarkko On Thu, 9 Dec 2010, Jarkko Nikula wrote: On Tue, 07 Dec 2010 23:18:28 -0700 Paul Walmsley p...@pwsan.com wrote: This series is available via git from git://git.pwsan.com/linux-2.6 in the branch 'pwrdm_prcm_b_2.6.38'. It applies on top of the OMAP: PRCM/powerdomain/clockdomain patches for 2.6.38, part one series, sent earlier. Kevin and OMAP ASoC-hackers, I'd appreciate review and acks, if appropriate, on the patches that touch code that you maintain. TI OMAP4 PM people, I would appreciate any testing assistance that you may be able to provide. Benoît, I've tried to keep the kernel data files and the output of the scripts relatively similar, but we might need to do some tweaking of the scripts or data files to align them in the way that makes the most sense. Is there some patch missing? Part one compiles but this set does not. Yes, mach-omap2/cminst44xx.h is missing from the posted series. It's been added to the branch on the git server and posted here: http://www.spinics.net/lists/arm-kernel/msg106850.html Will repost the updated series after handling some of the other comments. - Paul
Re: [PATCH v2] OMAP2+: disable idle early in the suspend sequence
Kevin, On Thu, Dec 9, 2010 at 12:01 AM, Kevin Hilman khil...@deeprootsystems.com wrote: jean.pi...@newoldbits.com writes: From: Jean Pihet j-pi...@ti.com Some bad interaction between the idle and the suspend paths has been noticed: the idle code is called during the suspend enter and exit sequences. This could cause corruption or lock-up of resources. The solution is to move the calls to disable_hlt at the very beginning of the suspend sequence (ex. in omap3_pm_begin instead of omap3_pm_prepare), and the call to enable_hlt at the very end of the suspend sequence (ex. in omap3_pm_end instead of omap3_pm_finish). In an earlier version, I thought we agreed to just remove the empty prepare/finish calls. Can you do that? Also, can you base this on top of my recently posted patch: [PATCH v3] OMAP2+: PM/serial: fix console semaphore acquire during suspend since it touches some of the same code for pm24xx.c Ok sent as '[PATCH v3] OMAP2+: disable idle early in the suspend sequence' Thanks, Jean 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: OMAP HSMMC problems with off-mode
Paul Walmsley p...@pwsan.com writes: Hi, On Tue, 7 Dec 2010, Chikkature Rajashekar, Madhusudhan wrote: On Tue, Dec 7, 2010 at 1:51 PM, Adrian Hunter adrian.hun...@nokia.com wrote: It is at least because omap_pm_get_dev_context_loss_count() is not implemented. Tero Kristo was looking at that recently. Yes. I agree that is the problem. In the .32 kernel I had hooked it to get_last_off_on_transaction_id which helped. But that functionality does not exist anymore. So something equivalent to tell the driver when the OFF was hit will make it work. OK, let's see if we can get that fixed in at least some trivial way for 2.6.38. While working on this, I applied this trivial patch: diff --git a/arch/arm/plat-omap/omap-pm-noop.c b/arch/arm/plat-omap/omap-pm-noop.c index e129ce8..781aa5f 100644 --- a/arch/arm/plat-omap/omap-pm-noop.c +++ b/arch/arm/plat-omap/omap-pm-noop.c @@ -30,6 +30,8 @@ struct omap_opp *dsp_opps; struct omap_opp *mpu_opps; struct omap_opp *l3_opps; +static int dummy_context_loss_counter; + /* * Device-driver-originated constraints (via board-*.c files) */ @@ -303,7 +305,7 @@ int omap_pm_get_dev_context_loss_count(struct device *dev) * off counter. */ - return 0; + return dummy_context_loss_counter++; } ... which causes drivers to believe that device context has been lost after each call to omap_pm_get_dev_context_loss_count(). Brutal, but effective for chasing out context save/restore bugs. Tested-by: Kevin Hilman khil...@deeprootsystems.com I verified that this, in combination with your other patch[1] results in working off-suspend with MMC on 34xx/n900, 35xx/beagle and 36xx/zoom3. Paul, do you want to submit a formal patch for this for 2.6.38? if not, I can add a changelog and queue this with other PM core changes for 2.6.38. Kevin [1] MMC: omap_hsmmc: enable interface clock before calling mmc_host_enable() -- To unsubscribe from this list: send the line unsubscribe 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] OMAP2+: disable idle early in the suspend sequence
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
Some bad interaction between the idle and the suspend paths has been
identified: the idle code is called during the suspend enter and exit
sequences. This could cause corruption or lock-up of resources.
The solution is to move the calls to disable_hlt at the very beginning
of the suspend sequence (ex. in omap3_pm_begin instead of
omap3_pm_prepare), and the call to enable_hlt at the very end of
the suspend sequence (ex. in omap3_pm_end instead of omap3_pm_finish).
Tested with RET and OFF on Beagle and OMAP3EVM.
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
OK, one more time... can you Cc linux-arm-kernel as well.
This avoids having to repost to linux-arm-kernel before final merge.
After that, will queue in pm-next for 2.6.38.
Thanks,
Kevin
---
v1:
Support for OMAP3 only.
Tested on board.
v2:
Added support for OMAP2 and OMAP4.
Compile tested only for OMAP2 and OMAP4.
Tested on board for OMAP3.
v3:
Rebased on Kevin's latest 'OMAP2+: PM/serial: fix console semaphore acquire
during suspend', cf. http://marc.info/?l=linux-omapm=129184804805075w=2
Removed the empty _pm_prepare and _pm_finish functions.
arch/arm/mach-omap2/pm24xx.c | 16 ++--
arch/arm/mach-omap2/pm34xx.c | 15 ++-
arch/arm/mach-omap2/pm44xx.c | 16 ++--
3 files changed, 6 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index 1e031d0..6cde8ed 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -301,14 +301,8 @@ out:
static int omap2_pm_begin(suspend_state_t state)
{
- suspend_state = state;
- return 0;
-}
-
-static int omap2_pm_prepare(void)
-{
- /* We cannot sleep in idle until we have resumed */
disable_hlt();
+ suspend_state = state;
return 0;
}
@@ -349,22 +343,16 @@ static int omap2_pm_enter(suspend_state_t state)
return ret;
}
-static void omap2_pm_finish(void)
-{
- enable_hlt();
-}
-
static void omap2_pm_end(void)
{
suspend_state = PM_SUSPEND_ON;
+ enable_hlt();
return;
}
static struct platform_suspend_ops omap_pm_ops = {
.begin = omap2_pm_begin,
- .prepare= omap2_pm_prepare,
.enter = omap2_pm_enter,
- .finish = omap2_pm_finish,
.end= omap2_pm_end,
.valid = suspend_valid_only_mem,
};
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 648b8c5..5bf344a 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -529,12 +529,6 @@ out:
}
#ifdef CONFIG_SUSPEND
-static int omap3_pm_prepare(void)
-{
- disable_hlt();
- return 0;
-}
-
static int omap3_pm_suspend(void)
{
struct power_state *pwrst;
@@ -597,14 +591,10 @@ static int omap3_pm_enter(suspend_state_t unused)
return ret;
}
-static void omap3_pm_finish(void)
-{
- enable_hlt();
-}
-
/* Hooks to enable / disable UART interrupts during suspend */
static int omap3_pm_begin(suspend_state_t state)
{
+ disable_hlt();
suspend_state = state;
omap_uart_enable_irqs(0);
return 0;
@@ -614,15 +604,14 @@ static void omap3_pm_end(void)
{
suspend_state = PM_SUSPEND_ON;
omap_uart_enable_irqs(1);
+ enable_hlt();
return;
}
static struct platform_suspend_ops omap_pm_ops = {
.begin = omap3_pm_begin,
.end= omap3_pm_end,
- .prepare= omap3_pm_prepare,
.enter = omap3_pm_enter,
- .finish = omap3_pm_finish,
.valid = suspend_valid_only_mem,
};
#endif /* CONFIG_SUSPEND */
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 54544b4..6aff996 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -31,12 +31,6 @@ struct power_state {
static LIST_HEAD(pwrst_list);
#ifdef CONFIG_SUSPEND
-static int omap4_pm_prepare(void)
-{
- disable_hlt();
- return 0;
-}
-
static int omap4_pm_suspend(void)
{
do_wfi();
@@ -59,28 +53,22 @@ static int omap4_pm_enter(suspend_state_t suspend_state)
return ret;
}
-static void omap4_pm_finish(void)
-{
- enable_hlt();
- return;
-}
-
static int omap4_pm_begin(suspend_state_t state)
{
+ disable_hlt();
return 0;
}
static void omap4_pm_end(void)
{
+ enable_hlt();
return;
}
static struct platform_suspend_ops omap_pm_ops = {
.begin = omap4_pm_begin,
.end= omap4_pm_end,
- .prepare= omap4_pm_prepare,
.enter = omap4_pm_enter,
- .finish = omap4_pm_finish,
.valid = suspend_valid_only_mem,
};
#endif /* CONFIG_SUSPEND */
Re: Unbalanced IRQ wake disable during resume from static suspend
Govindraj govindraj...@gmail.com writes:
On Fri, Dec 3, 2010 at 4:38 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Friday, December 03, 2010 3:53 PM
To: Santosh Shilimkar
Cc: linux-omap@vger.kernel.org; Govindraj; khil...@deeprootsystems.com
Subject: RE: Unbalanced IRQ wake disable during resume from static
suspend
Hello Santosh
On Thu, 2 Dec 2010, Santosh Shilimkar wrote:
Just a wild guess here but is this because the 'set_wake' is
not setup and then fw might be returning some error whenever
driver invoke this API as part of enable_irq_wake() callback
If that being the case, below patch might might help. Can
somebody try this out ?
This patch might remove the warnings, but I doubt that it solves the
root
cause. In any case, it doesn't seem correct to unconditionally return 0
(success) from an omap_irq_wake() function, given that the OMAP INTC has
no functionality in this regard.
The real problem appears to be in drivers/serial/serial_core.c.
uart_suspend_port() doesn't check the return value of enable_irq_wake().
Seems to me that it needs to save that return value somewhere and not
bother calling disable_irq_wake() in uart_resume_port() if
enable_irq_wake() returned an error.
That's the patch that I'd suggest that you guys put together and send to
the Linux serial people.
You are right Paul. This will actually fix the broken driver rather than
masking it. Will spin a patch for the same
Hi Santosh/Paul,
How about this patch?
[Tested on 3630SDP
also tested on 36xx/zoom3 and 34xx/n900
From cb4e79a645b530f83f55d801ab054cc438ada0dd Mon Sep 17 00:00:00 2001
From: Govindraj.R govindraj.r...@ti.com
Date: Fri, 3 Dec 2010 16:42:14 +0530
Subject: [PATCH] Serial: Unbalanced IRQ wake disable during resume
from static suspend
Check for return status for enable_irq_wake if irq_wake
interface is not available then during resume unconditional
disabling of irq_wake can throw below warning.
This doesn't read well. How about:
Subject: serial: omap-serial: avoid unbalanced IRQ disable
Changelog:
To avoid unbalanced IRQ wake disable, ensure that wakeups are disabled
only when wakeups have been successfully enabled.
With this, you don't need to include the backtrace as the unbalanced IRQ
disable is understood from the subject changelog.
[ cut here ]
WARNING: at kernel/irq/manage.c:382 set_irq_wake+0x80/0xe4()
Unbalanced IRQ 72 wake disable
Modules linked in:
[c0062a28] (unwind_backtrace+0x0/0xec) from [c0092260]
(warn_slowpath_common+0x4c/0x64)
[c0092260] (warn_slowpath_common+0x4c/0x64) from [c00922f8]
(warn_slowpath_fmt+0x2c/0x3c
[c00922f8] (warn_slowpath_fmt+0x2c/0x3c) from [c00d3238]
(set_irq_wake+0x80/0xe4)
[c00d3238] (set_irq_wake+0x80/0xe4) from [c029dd60]
(uart_resume_port+0x84/0x248)
[c029dd60] (uart_resume_port+0x84/0x248) from [c02a2338]
(serial_omap_resume+0x20/0x2c)
[c02a2338] (serial_omap_resume+0x20/0x2c) from [c02a92d4]
(platform_pm_resume+0x48/0x54)
[c02a92d4] (platform_pm_resume+0x48/0x54) from [c02abd1c]
(pm_op+0x6c/0xac)
[c02abd1c] (pm_op+0x6c/0xac) from [c02ac0fc]
(device_resume+0x58/0x10c)
[c02ac0fc] (device_resume+0x58/0x10c) from [c02ac2ec]
(dpm_resume_end+0xf4/0x360)
[c02ac2ec] (dpm_resume_end+0xf4/0x360) from [c00cf58c]
(suspend_devices_and_enter+0x1ac/0x200)
[c00cf58c] (suspend_devices_and_enter+0x1ac/0x200) from [c00cf6c0]
(enter_state+0xe0/0x138)
[c00cf6c0] (enter_state+0xe0/0x138) from [c00ced18]
(state_store+0x90/0xb8)
[c00ced18] (state_store+0x90/0xb8) from [c0243b98]
(kobj_attr_store+0x18/0x1c)
[c0243b98] (kobj_attr_store+0x18/0x1c) from [c0176128]
(sysfs_write_file+0x10c/0x144)
[c0176128] (sysfs_write_file+0x10c/0x144) from [c0125528]
(vfs_write+0xac/0x134)
[c0125528] (vfs_write+0xac/0x134) from [c012565c]
(sys_write+0x3c/0x68)
[c012565c] (sys_write+0x3c/0x68) from [c005bb00]
(ret_fast_syscall+0x0/0x3c)
---[ end trace 19fe50b7b47ba94f ]---
Thus add a flag to check the return status for irq_wake
based on flag disable the irq_wake
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
drivers/serial/serial_core.c |6 --
include/linux/serial_core.h |1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/serial_core.c b/drivers/serial/serial_core.c
index cd85112..0466815 100644
--- a/drivers/serial/serial_core.c
+++ b/drivers/serial/serial_core.c
@@ -1990,7 +1990,8 @@ int uart_suspend_port(struct uart_driver *drv,
struct uart_port *uport)
tty_dev = device_find_child(uport-dev, match, serial_match_port);
if (device_may_wakeup(tty_dev)) {
- enable_irq_wake(uport-irq);
+ if (!enable_irq_wake(uport-irq))
+ uport-irq_wake = 1;
put_device(tty_dev);
mutex_unlock(port-mutex);
return 0;
@@ -2056,7 +2057,8 @@ int
Re: OMAP HSMMC problems with off-mode
Hi Kevin On Thu, 9 Dec 2010, Kevin Hilman wrote: Paul, do you want to submit a formal patch for this for 2.6.38? if not, I can add a changelog and queue this with other PM core changes for 2.6.38. we should probably come up with a patch for .38 that only increments this when off-mode is entered... otherwise there will probably be a performance hit when off-mode-supporting devices are reinitialized after every clk_enable() :-) The HSMMC driver also resets the IP block when that happens. - 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: OMAP HSMMC problems with off-mode
On Thu, 9 Dec 2010, Paul Walmsley wrote: On Thu, 9 Dec 2010, Kevin Hilman wrote: Paul, do you want to submit a formal patch for this for 2.6.38? if not, I can add a changelog and queue this with other PM core changes for 2.6.38. we should probably come up with a patch for .38 that only increments this when off-mode is entered... otherwise there will probably be a performance hit when off-mode-supporting devices are reinitialized after every clk_enable() :-) The HSMMC driver also resets the IP block when that happens. Although, just thinking about it, it might be worth adding a debugfs option or Kconfig option for the OMAP PM no-op layer that enables 'brutal mode' for testing? - 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 2/2] ARM: Make CONFIG_FPE_NWFPE depend on !CONFIG_THUMB2_KERNEL
On Thu, 9 Dec 2010, Dave Martin wrote: Because the nwfpe support is unlikely to be used on new platforms and requires CONFIG_OABI_COMPAT, which is not generally used with ARMv7+, we shouldn't expect to build nwfpe support into a Thumb-2 kernel. At present, nwfpe contains assembly code which isn't Thumb-2 compatible, and for now it doesn't appear useful to port this code. All ARMv7-A/R platforms necessarily have VFPv3 hardware floating- point natively, making emulation unnecessary. Signed-off-by: Dave Martin dave.mar...@linaro.org Acked-by: Catalin Marinas catalin.mari...@arm.com Acked-by: Nicolas Pitre nicolas.pi...@linaro.org --- arch/arm/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index f9ca7f3..7e825c3 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1759,7 +1759,7 @@ comment At least one emulation must be selected config FPE_NWFPE bool NWFPE math emulation - depends on !AEABI || OABI_COMPAT + depends on (!AEABI || OABI_COMPAT) !THUMB2_KERNEL ---help--- Say Y to include the NWFPE floating point emulator in the kernel. This is necessary to run most binaries. Linux does not currently -- 1.7.1 ___ 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 1/2] ARM: Thumb-2: Make CONFIG_THUMB2_KERNEL depend on !CPU_V6
On Thu, 9 Dec 2010, Dave Martin wrote: This makes sense, because Thumb-2 code can't execute on plain ARMv6 processors. This will avoid accidentally configuring a broken kernel where the config otherwise would allow multiple architecture versions to coexist in the same kernel. Not adding !CPU_V5 etc., because the chance of anyone trying to put v5 and v7 in the same kernel is low, and I'm not aware of any mach which can do this. These could be added later if it matters. Note that the rules may need to be refined if support for the ARM1156J(F)-S processor is later added to the kernel, since this processor supports the rare ARMv6T2 extensions, which add support for Thumb-2 and a few other ARMv7 features. Signed-off-by: Dave Martin dave.mar...@linaro.org Acked-by: Catalin Marinas catalin.mari...@arm.com Acked-by: Nicolas Pitre nicolas.pi...@linaro.org --- arch/arm/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index db524e7..f9ca7f3 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1311,7 +1311,7 @@ config HZ config THUMB2_KERNEL bool Compile the kernel in Thumb-2 mode - depends on CPU_V7 EXPERIMENTAL + depends on CPU_V7 !CPU_V6 EXPERIMENTAL select AEABI select ARM_ASM_UNIFIED help -- 1.7.1 ___ 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 1/2] I2C: i2c-omap: Change device name: i2c_omap - omap_i2c
On Thu, Dec 09, 2010 at 08:55:28AM -0800, Kevin Hilman wrote:
Ben,
The convention for omap device naming is omap_XXX.
Rename the device and driver name in order to stick
to this naming convention.
Renaming stuff like this is going to have an impact on the userspace
as anyone looking through /sys's driver heirarchy is going to miss the
old name...
It all depends if you really want to go ahead with this...
Change device name in clock nodes as well.
Signed-off-by: Benoit Cousson b-cous...@ti.com
c: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Ben Dooks ben-...@fluff.org
---
arch/arm/mach-omap1/clock_data.c |6 +++---
arch/arm/mach-omap2/clock2420_data.c |8
arch/arm/mach-omap2/clock2430_data.c |8
arch/arm/mach-omap2/clock3xxx_data.c | 12 ++--
arch/arm/mach-omap2/clock44xx_data.c | 16
arch/arm/plat-omap/i2c.c |2 +-
drivers/i2c/busses/i2c-omap.c|4 ++--
7 files changed, 28 insertions(+), 28 deletions(-)
[...]
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 760b8be..9d09083 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1139,7 +1139,7 @@ static struct platform_driver omap_i2c_driver = {
.probe = omap_i2c_probe,
.remove = omap_i2c_remove,
.driver = {
- .name = i2c_omap,
+ .name = omap_i2c,
.owner = THIS_MODULE,
},
};
@@ -1161,4 +1161,4 @@ module_exit(omap_i2c_exit_driver);
MODULE_AUTHOR(MontaVista Software, Inc. (and others));
MODULE_DESCRIPTION(TI OMAP I2C bus adapter);
MODULE_LICENSE(GPL);
-MODULE_ALIAS(platform:i2c_omap);
+MODULE_ALIAS(platform:omap_i2c);
With your ack for the name change in the driver, we can merge this
through the OMAP tree with the other core changes.
Thanks,
Kevin
--
--
Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/
Large Hadron Colada: A large Pina Colada that makes the universe disappear.
--
To unsubscribe from this list: send the line unsubscribe 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 v8 01/11] OMAP: GPIO: prepare for platform driver
Hi Charu,
Varadarajan, Charulatha ch...@ti.com writes:
Prepare for implementing GPIO as a platform driver.
Modifies omap_gpio_init() to make use of omap_gpio_chip_init()
and omap_gpio_mod_init(). omap_gpio_mod_init() does the module init
by clearing the status register and initializing the GPIO control register.
omap_gpio_chip_init() initializes the chip request, free, get, set and
other function pointers and sets the gpio irq handler.
This is only to reorganize the code so that the omap gpio platform driver
implementation patch looks cleaner and better to review.
Signed-off-by: Charulatha V ch...@ti.com
I just noticed while testing on 36xx/Zoom3 that GPIO wakeups are no
longer working after this series.
The problem seems to be that for OMAP2+, this series removed manual
SYSCONFIG register setting in favor of using omap_hwmod (which is good),
however some of the SYSCONFIG values, specifically, in the current code,
the ENAWAKEUP bit was set in each bank, but this is no longer the
default with omap_hwmod.
-#ifdef CONFIG_ARCH_OMAP2PLUS
- if ((bank-method == METHOD_GPIO_24XX) ||
- (bank-method == METHOD_GPIO_44XX)) {
- static const u32 non_wakeup_gpios[] = {
- 0xe203ffc0, 0x08700040
- };
-
- if (cpu_is_omap44xx()) {
- __raw_writel(0x, bank-base +
- OMAP4_GPIO_IRQSTATUSCLR0);
- __raw_writew(0x0015, bank-base +
- OMAP4_GPIO_SYSCONFIG);
- __raw_writel(0x, bank-base +
- OMAP4_GPIO_DEBOUNCENABLE);
- /*
- * Initialize interface clock ungated,
- * module enabled
- */
- __raw_writel(0, bank-base + OMAP4_GPIO_CTRL);
- } else {
- __raw_writel(0x, bank-base +
- OMAP24XX_GPIO_IRQENABLE1);
- __raw_writel(0x, bank-base +
- OMAP24XX_GPIO_IRQSTATUS1);
- __raw_writew(0x0015, bank-base +
- OMAP24XX_GPIO_SYSCONFIG);
Here bit 2 (ENAWAKEUP) is set, and is not reconfigured anywhere in this
series. Same for OMAP4 above.
Here's a quick fix to preserve current functionality (will post
w/changelog shortly), but it shows that GPIO wakeups were not fully
tested with this series. In the future, along with reporting what
platforms it was testing on, it would be very helpful to include a
summary of how the series was tested.
Thanks,
Kevin
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
index 413de18..05a123f 100644
--- a/arch/arm/mach-omap2/gpio.c
+++ b/arch/arm/mach-omap2/gpio.c
@@ -75,6 +75,7 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void
*unused)
return -EINVAL;
}
+ omap_hwmod_enable_wakeup(oh);
od = omap_device_build(name, id - 1, oh, pdata,
sizeof(*pdata), omap_gpio_latency,
ARRAY_SIZE(omap_gpio_latency),
--
To unsubscribe from this list: send the line unsubscribe 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 13/11] OMAP2+: GPIO: ensure bank wakeups are enabled by default
As part of the GPIO conversion to platform_device/platform_driver, commit 2fae7fbed072705d91e09ed393b2e580b2d895fc (OMAP: GPIO: prepare for platform driver) removed hard-coded per-bank SYSCONFIG register values in favor of using omap_hwmod to manage the SYSCONFIG register. In the previous code, bank-level wakeups were enabled by default using the SYSCONFIG.ENAWAKEUP bit, but omap_hwmod does not enable wakeups by default. Thus the above commit effectively disabled GPIO bank wakeups. This patch enables GPIO bank level wakeups by default to preserve previous functionality. Longer term, per-bank wakeup functionality should be controlled by the driver and enabled only when there are wakeup-enabled GPIOs in the bank. Tested on 36xx/Zoom3 where serial console (QUART) uses GPIO IRQ. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- Applies to Tony's devel-gpio branch. arch/arm/mach-omap2/gpio.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c index 413de18..05a123f 100644 --- a/arch/arm/mach-omap2/gpio.c +++ b/arch/arm/mach-omap2/gpio.c @@ -75,6 +75,7 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void *unused) return -EINVAL; } + omap_hwmod_enable_wakeup(oh); od = omap_device_build(name, id - 1, oh, pdata, sizeof(*pdata), omap_gpio_latency, ARRAY_SIZE(omap_gpio_latency), -- 1.7.2.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] usb: musb: Adding names for IRQs in resource structure
Hello.
Kevin Hilman wrote:
The resource data is getting automatically populated from a set of data
generated from TI's hardware database for the OMAP platform,
While we could hack in some exceptions to that tool to generate resources
in a specific order, it seems less fragile to use the resource name
instead.That way, no matter what order the resources are generated, the
driver still work.
Modified the OMAP,Blackfin and Davinci architecture files to add the name of
the IRQs
in the resource structures and musb driver to use the get_irq_byname() api to
get the device and dma irq numbers instead of using the index.
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Mike Frysinger vap...@gentoo.org
---
For the davinci changes:
Acked-by: Kevin Hilman khil...@deeprootsystems.com
Kevin
[...]
Index: linux-omap-pm/arch/arm/mach-davinci/usb.c
===
--- linux-omap-pm.orig/arch/arm/mach-davinci/usb.c
+++ linux-omap-pm/arch/arm/mach-davinci/usb.c
@@ -64,10 +64,12 @@ static struct resource usb_resources[] =
{
.start = IRQ_USBINT,
.flags = IORESOURCE_IRQ,
+ .name = mc
},
{
/* placeholder for the dedicated CPPI IRQ */
.flags = IORESOURCE_IRQ,
+ .name = dma
},
};
Argh! This failed to also modify da8xx_usb20_resources[]... :-(
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] OMAP2+: disable idle early in the suspend sequence
From: Jean Pihet j-pi...@ti.com
Some bad interaction between the idle and the suspend paths has been
identified: the idle code is called during the suspend enter and exit
sequences. This could cause corruption or lock-up of resources.
The solution is to move the calls to disable_hlt at the very beginning
of the suspend sequence (ex. in omap3_pm_begin instead of
omap3_pm_prepare), and the call to enable_hlt at the very end of
the suspend sequence (ex. in omap3_pm_end instead of omap3_pm_finish).
Tested with RET and OFF on Beagle and OMAP3EVM.
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
v1:
Support for OMAP3 only.
Tested on board.
v2:
Added support for OMAP2 and OMAP4.
Compile tested only for OMAP2 and OMAP4.
Tested on board for OMAP3.
v3:
Rebased on Kevin's latest 'OMAP2+: PM/serial: fix console semaphore acquire
during suspend', cf. http://marc.info/?l=linux-omapm=129184804805075w=2
Removed the empty _pm_prepare and _pm_finish functions.
arch/arm/mach-omap2/pm24xx.c | 16 ++--
arch/arm/mach-omap2/pm34xx.c | 15 ++-
arch/arm/mach-omap2/pm44xx.c | 16 ++--
3 files changed, 6 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index 1e031d0..6cde8ed 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -301,14 +301,8 @@ out:
static int omap2_pm_begin(suspend_state_t state)
{
- suspend_state = state;
- return 0;
-}
-
-static int omap2_pm_prepare(void)
-{
- /* We cannot sleep in idle until we have resumed */
disable_hlt();
+ suspend_state = state;
return 0;
}
@@ -349,22 +343,16 @@ static int omap2_pm_enter(suspend_state_t state)
return ret;
}
-static void omap2_pm_finish(void)
-{
- enable_hlt();
-}
-
static void omap2_pm_end(void)
{
suspend_state = PM_SUSPEND_ON;
+ enable_hlt();
return;
}
static struct platform_suspend_ops omap_pm_ops = {
.begin = omap2_pm_begin,
- .prepare= omap2_pm_prepare,
.enter = omap2_pm_enter,
- .finish = omap2_pm_finish,
.end= omap2_pm_end,
.valid = suspend_valid_only_mem,
};
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 648b8c5..5bf344a 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -529,12 +529,6 @@ out:
}
#ifdef CONFIG_SUSPEND
-static int omap3_pm_prepare(void)
-{
- disable_hlt();
- return 0;
-}
-
static int omap3_pm_suspend(void)
{
struct power_state *pwrst;
@@ -597,14 +591,10 @@ static int omap3_pm_enter(suspend_state_t unused)
return ret;
}
-static void omap3_pm_finish(void)
-{
- enable_hlt();
-}
-
/* Hooks to enable / disable UART interrupts during suspend */
static int omap3_pm_begin(suspend_state_t state)
{
+ disable_hlt();
suspend_state = state;
omap_uart_enable_irqs(0);
return 0;
@@ -614,15 +604,14 @@ static void omap3_pm_end(void)
{
suspend_state = PM_SUSPEND_ON;
omap_uart_enable_irqs(1);
+ enable_hlt();
return;
}
static struct platform_suspend_ops omap_pm_ops = {
.begin = omap3_pm_begin,
.end= omap3_pm_end,
- .prepare= omap3_pm_prepare,
.enter = omap3_pm_enter,
- .finish = omap3_pm_finish,
.valid = suspend_valid_only_mem,
};
#endif /* CONFIG_SUSPEND */
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 54544b4..6aff996 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -31,12 +31,6 @@ struct power_state {
static LIST_HEAD(pwrst_list);
#ifdef CONFIG_SUSPEND
-static int omap4_pm_prepare(void)
-{
- disable_hlt();
- return 0;
-}
-
static int omap4_pm_suspend(void)
{
do_wfi();
@@ -59,28 +53,22 @@ static int omap4_pm_enter(suspend_state_t suspend_state)
return ret;
}
-static void omap4_pm_finish(void)
-{
- enable_hlt();
- return;
-}
-
static int omap4_pm_begin(suspend_state_t state)
{
+ disable_hlt();
return 0;
}
static void omap4_pm_end(void)
{
+ enable_hlt();
return;
}
static struct platform_suspend_ops omap_pm_ops = {
.begin = omap4_pm_begin,
.end= omap4_pm_end,
- .prepare= omap4_pm_prepare,
.enter = omap4_pm_enter,
- .finish = omap4_pm_finish,
.valid = suspend_valid_only_mem,
};
#endif /* CONFIG_SUSPEND */
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] OMAP2+: disable idle early in the suspend sequence
On Thu, Dec 9, 2010 at 7:00 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
Some bad interaction between the idle and the suspend paths has been
identified: the idle code is called during the suspend enter and exit
sequences. This could cause corruption or lock-up of resources.
The solution is to move the calls to disable_hlt at the very beginning
of the suspend sequence (ex. in omap3_pm_begin instead of
omap3_pm_prepare), and the call to enable_hlt at the very end of
the suspend sequence (ex. in omap3_pm_end instead of omap3_pm_finish).
Tested with RET and OFF on Beagle and OMAP3EVM.
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
OK, one more time... can you Cc linux-arm-kernel as well.
Done!
This avoids having to repost to linux-arm-kernel before final merge.
After that, will queue in pm-next for 2.6.38.
Thanks,
Kevin
Jean
---
v1:
Support for OMAP3 only.
Tested on board.
v2:
Added support for OMAP2 and OMAP4.
Compile tested only for OMAP2 and OMAP4.
Tested on board for OMAP3.
v3:
Rebased on Kevin's latest 'OMAP2+: PM/serial: fix console semaphore acquire
during suspend', cf. http://marc.info/?l=linux-omapm=129184804805075w=2
Removed the empty _pm_prepare and _pm_finish functions.
arch/arm/mach-omap2/pm24xx.c | 16 ++--
arch/arm/mach-omap2/pm34xx.c | 15 ++-
arch/arm/mach-omap2/pm44xx.c | 16 ++--
3 files changed, 6 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index 1e031d0..6cde8ed 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -301,14 +301,8 @@ out:
static int omap2_pm_begin(suspend_state_t state)
{
- suspend_state = state;
- return 0;
-}
-
-static int omap2_pm_prepare(void)
-{
- /* We cannot sleep in idle until we have resumed */
disable_hlt();
+ suspend_state = state;
return 0;
}
@@ -349,22 +343,16 @@ static int omap2_pm_enter(suspend_state_t state)
return ret;
}
-static void omap2_pm_finish(void)
-{
- enable_hlt();
-}
-
static void omap2_pm_end(void)
{
suspend_state = PM_SUSPEND_ON;
+ enable_hlt();
return;
}
static struct platform_suspend_ops omap_pm_ops = {
.begin = omap2_pm_begin,
- .prepare = omap2_pm_prepare,
.enter = omap2_pm_enter,
- .finish = omap2_pm_finish,
.end = omap2_pm_end,
.valid = suspend_valid_only_mem,
};
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 648b8c5..5bf344a 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -529,12 +529,6 @@ out:
}
#ifdef CONFIG_SUSPEND
-static int omap3_pm_prepare(void)
-{
- disable_hlt();
- return 0;
-}
-
static int omap3_pm_suspend(void)
{
struct power_state *pwrst;
@@ -597,14 +591,10 @@ static int omap3_pm_enter(suspend_state_t unused)
return ret;
}
-static void omap3_pm_finish(void)
-{
- enable_hlt();
-}
-
/* Hooks to enable / disable UART interrupts during suspend */
static int omap3_pm_begin(suspend_state_t state)
{
+ disable_hlt();
suspend_state = state;
omap_uart_enable_irqs(0);
return 0;
@@ -614,15 +604,14 @@ static void omap3_pm_end(void)
{
suspend_state = PM_SUSPEND_ON;
omap_uart_enable_irqs(1);
+ enable_hlt();
return;
}
static struct platform_suspend_ops omap_pm_ops = {
.begin = omap3_pm_begin,
.end = omap3_pm_end,
- .prepare = omap3_pm_prepare,
.enter = omap3_pm_enter,
- .finish = omap3_pm_finish,
.valid = suspend_valid_only_mem,
};
#endif /* CONFIG_SUSPEND */
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 54544b4..6aff996 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -31,12 +31,6 @@ struct power_state {
static LIST_HEAD(pwrst_list);
#ifdef CONFIG_SUSPEND
-static int omap4_pm_prepare(void)
-{
- disable_hlt();
- return 0;
-}
-
static int omap4_pm_suspend(void)
{
do_wfi();
@@ -59,28 +53,22 @@ static int omap4_pm_enter(suspend_state_t suspend_state)
return ret;
}
-static void omap4_pm_finish(void)
-{
- enable_hlt();
- return;
-}
-
static int omap4_pm_begin(suspend_state_t state)
{
+ disable_hlt();
return 0;
}
static void omap4_pm_end(void)
{
+ enable_hlt();
return;
}
static struct platform_suspend_ops omap_pm_ops = {
.begin = omap4_pm_begin,
.end = omap4_pm_end,
- .prepare = omap4_pm_prepare,
.enter = omap4_pm_enter,
- .finish = omap4_pm_finish,
Re: [PATCH v2 1/2] I2C: i2c-omap: Change device name: i2c_omap - omap_i2c
Ben Dooks ben-...@fluff.org writes:
On Thu, Dec 09, 2010 at 08:55:28AM -0800, Kevin Hilman wrote:
Ben,
The convention for omap device naming is omap_XXX.
Rename the device and driver name in order to stick
to this naming convention.
Renaming stuff like this is going to have an impact on the userspace
as anyone looking through /sys's driver heirarchy is going to miss the
old name...
It all depends if you really want to go ahead with this...
Yes, we are aware of the userspace impact, but this name change makes
all devices on OMAP have consistent names and actually improves the
ability to have userspace tools have consistent naming as well.
Kevin
Change device name in clock nodes as well.
Signed-off-by: Benoit Cousson b-cous...@ti.com
c: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Ben Dooks ben-...@fluff.org
---
arch/arm/mach-omap1/clock_data.c |6 +++---
arch/arm/mach-omap2/clock2420_data.c |8
arch/arm/mach-omap2/clock2430_data.c |8
arch/arm/mach-omap2/clock3xxx_data.c | 12 ++--
arch/arm/mach-omap2/clock44xx_data.c | 16
arch/arm/plat-omap/i2c.c |2 +-
drivers/i2c/busses/i2c-omap.c|4 ++--
7 files changed, 28 insertions(+), 28 deletions(-)
[...]
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 760b8be..9d09083 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1139,7 +1139,7 @@ static struct platform_driver omap_i2c_driver = {
.probe = omap_i2c_probe,
.remove = omap_i2c_remove,
.driver = {
- .name = i2c_omap,
+ .name = omap_i2c,
.owner = THIS_MODULE,
},
};
@@ -1161,4 +1161,4 @@ module_exit(omap_i2c_exit_driver);
MODULE_AUTHOR(MontaVista Software, Inc. (and others));
MODULE_DESCRIPTION(TI OMAP I2C bus adapter);
MODULE_LICENSE(GPL);
-MODULE_ALIAS(platform:i2c_omap);
+MODULE_ALIAS(platform:omap_i2c);
With your ack for the name change in the driver, we can merge this
through the OMAP tree with the other core changes.
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 v2 1/2] I2C: i2c-omap: Change device name: i2c_omap - omap_i2c
On Thu, Dec 09, 2010 at 08:55:28AM -0800, Kevin Hilman wrote:
Ben,
Benoit Cousson b-cous...@ti.com writes:
The convention for omap device naming is omap_XXX.
Rename the device and driver name in order to stick
to this naming convention.
Change device name in clock nodes as well.
Signed-off-by: Benoit Cousson b-cous...@ti.com
c: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Ben Dooks ben-...@fluff.org
Acked-by: Ben Dooks ben-li...@fluff.org
---
arch/arm/mach-omap1/clock_data.c |6 +++---
arch/arm/mach-omap2/clock2420_data.c |8
arch/arm/mach-omap2/clock2430_data.c |8
arch/arm/mach-omap2/clock3xxx_data.c | 12 ++--
arch/arm/mach-omap2/clock44xx_data.c | 16
arch/arm/plat-omap/i2c.c |2 +-
drivers/i2c/busses/i2c-omap.c|4 ++--
7 files changed, 28 insertions(+), 28 deletions(-)
[...]
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 760b8be..9d09083 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1139,7 +1139,7 @@ static struct platform_driver omap_i2c_driver = {
.probe = omap_i2c_probe,
.remove = omap_i2c_remove,
.driver = {
- .name = i2c_omap,
+ .name = omap_i2c,
.owner = THIS_MODULE,
},
};
@@ -1161,4 +1161,4 @@ module_exit(omap_i2c_exit_driver);
MODULE_AUTHOR(MontaVista Software, Inc. (and others));
MODULE_DESCRIPTION(TI OMAP I2C bus adapter);
MODULE_LICENSE(GPL);
-MODULE_ALIAS(platform:i2c_omap);
+MODULE_ALIAS(platform:omap_i2c);
With your ack for the name change in the driver, we can merge this
through the OMAP tree with the other core changes.
Thanks,
Kevin
--
--
Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/
Large Hadron Colada: A large Pina Colada that makes the universe disappear.
--
To unsubscribe from this list: send the line unsubscribe 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: How to change freq of mmc2_clk to 48Mhz for OMAP35xx
Hi Paul, On Dec 9, 2010, at 12:36 AM, Paul Walmsley wrote: On Wed, 8 Dec 2010, Elvis Dowson wrote: What should I do to change the output frequency of mmc2_clk signal to 48Mhz for the OMAP35xx processor? Right now it is giving an output of 96MHz and the signal output looks more like a sine wave than a square wave clock output signal. Assuming you're using the mainline kernel, it doesn't look like the MMC driver changes its functional clock at all. So perhaps your bootloader is programming it incorrectly? Section 22.5.2.7.2 of the OMAP35x TRM revision D (page 3128) shows the steps required for changing the MMC/SD/SDIO controller clock frequency. Essentially the steps involve : - disabling clock to the device, - set the new clock divider value, - check it clock is stable, and then - re-enable the clock to the device. All this is being operated on the MMCi.MMCHS_SYSCTL register. I'm using the following bootloader synchronized with the OMAP35x PSP 03.00.01.06 $ git clone git://arago-project.org/git/projects/u-boot-omap3.git u-boot-2009.11-patchwork $ cd u-boot-2009.11-patchwork $ git checkout --track -b OMAPPSP_03.00.01.06 origin/OMAPPSP_03.00.01.06 Doing a grep for MMCHS_SYSCTL didn't return anything. Where in the bootloader do you think it can be set? Elvis Dowson -- To unsubscribe from this list: send the line unsubscribe 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 v8 01/11] OMAP: GPIO: prepare for platform driver
Salut Kevin,
On 12/9/2010 8:18 PM, Kevin Hilman wrote:
Hi Charu,
Varadarajan, Charulathach...@ti.com writes:
Prepare for implementing GPIO as a platform driver.
Modifies omap_gpio_init() to make use of omap_gpio_chip_init()
and omap_gpio_mod_init(). omap_gpio_mod_init() does the module init
by clearing the status register and initializing the GPIO control register.
omap_gpio_chip_init() initializes the chip request, free, get, set and
other function pointers and sets the gpio irq handler.
This is only to reorganize the code so that the omap gpio platform driver
implementation patch looks cleaner and better to review.
Signed-off-by: Charulatha Vch...@ti.com
I just noticed while testing on 36xx/Zoom3 that GPIO wakeups are no
longer working after this series.
The problem seems to be that for OMAP2+, this series removed manual
SYSCONFIG register setting in favor of using omap_hwmod (which is good),
however some of the SYSCONFIG values, specifically, in the current code,
the ENAWAKEUP bit was set in each bank, but this is no longer the
default with omap_hwmod.
That part is strange, because Rajendra did a patch to enable the wakeup
bit during _omap_hwmod_enable as soon as the idlemode is set to smartidle.
/* If slave port is in SMARTIDLE, also enable wakeup */
if ((sf SYSC_HAS_SIDLEMODE) (s_idlemode == HWMOD_IDLEMODE_SMART))
_enable_wakeup(oh);
The _disable_wakeup is never called, so in theory once it is set, it
should remain enabled.
Does that mean that this the GPIO is not in smartidle anymore in your case?
Regards,
Benoit
-#ifdef CONFIG_ARCH_OMAP2PLUS
- if ((bank-method == METHOD_GPIO_24XX) ||
- (bank-method == METHOD_GPIO_44XX)) {
- static const u32 non_wakeup_gpios[] = {
- 0xe203ffc0, 0x08700040
- };
-
- if (cpu_is_omap44xx()) {
- __raw_writel(0x, bank-base +
- OMAP4_GPIO_IRQSTATUSCLR0);
- __raw_writew(0x0015, bank-base +
- OMAP4_GPIO_SYSCONFIG);
- __raw_writel(0x, bank-base +
-OMAP4_GPIO_DEBOUNCENABLE);
- /*
-* Initialize interface clock ungated,
-* module enabled
-*/
- __raw_writel(0, bank-base + OMAP4_GPIO_CTRL);
- } else {
- __raw_writel(0x, bank-base +
- OMAP24XX_GPIO_IRQENABLE1);
- __raw_writel(0x, bank-base +
- OMAP24XX_GPIO_IRQSTATUS1);
- __raw_writew(0x0015, bank-base +
- OMAP24XX_GPIO_SYSCONFIG);
Here bit 2 (ENAWAKEUP) is set, and is not reconfigured anywhere in this
series. Same for OMAP4 above.
Here's a quick fix to preserve current functionality (will post
w/changelog shortly), but it shows that GPIO wakeups were not fully
tested with this series. In the future, along with reporting what
platforms it was testing on, it would be very helpful to include a
summary of how the series was tested.
Thanks,
Kevin
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
index 413de18..05a123f 100644
--- a/arch/arm/mach-omap2/gpio.c
+++ b/arch/arm/mach-omap2/gpio.c
@@ -75,6 +75,7 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void
*unused)
return -EINVAL;
}
+ omap_hwmod_enable_wakeup(oh);
od = omap_device_build(name, id - 1, oh, pdata,
sizeof(*pdata), omap_gpio_latency,
ARRAY_SIZE(omap_gpio_latency),
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] staging: tidspbridge: various cleanups
This series is a reduced set of the previous one, containing only two patches that were changed based on Omar's review: http://marc.info/?l=linux-omapm=129162731925095 Also rebased to the latest dspbridge branch from the omapzoom.org git tree. Ionut Nicu (2): staging: tidspbridge: rmgr/node.c code cleanup staging: tidspbridge: rmgr code cleanup drivers/staging/tidspbridge/rmgr/drv.c | 171 - drivers/staging/tidspbridge/rmgr/node.c | 682 +++ drivers/staging/tidspbridge/rmgr/rmm.c | 266 ++--- 3 files changed, 509 insertions(+), 610 deletions(-) -- 1.7.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] staging: tidspbridge: rmgr/node.c code cleanup
Reorganized some code in rmgr/node.c to increase its
readability. Most of the changes reduce the code
indentation level and simplifiy the code. No functional
changes were done.
Signed-off-by: Ionut Nicu ionut.n...@mindbit.ro
---
drivers/staging/tidspbridge/rmgr/node.c | 607 ++
1 files changed, 283 insertions(+), 324 deletions(-)
diff --git a/drivers/staging/tidspbridge/rmgr/node.c
b/drivers/staging/tidspbridge/rmgr/node.c
index 62d5c31..b196a7a 100644
--- a/drivers/staging/tidspbridge/rmgr/node.c
+++ b/drivers/staging/tidspbridge/rmgr/node.c
@@ -236,9 +236,9 @@ struct node_object {
/* Default buffer attributes */
static struct dsp_bufferattr node_dfltbufattrs = {
- 0, /* cb_struct */
- 1, /* segment_id */
- 0, /* buf_alignment */
+ .cb_struct = 0,
+ .segment_id = 1,
+ .buf_alignment = 0,
};
static void delete_node(struct node_object *hnode,
@@ -284,8 +284,7 @@ enum node_state node_get_state(void *hnode)
struct node_object *pnode = (struct node_object *)hnode;
if (!pnode)
return -1;
- else
- return pnode-node_state;
+ return pnode-node_state;
}
/*
@@ -844,6 +843,7 @@ int node_connect(struct node_object *node1, u32 stream1,
char *pstr_dev_name = NULL;
enum node_type node1_type = NODE_TASK;
enum node_type node2_type = NODE_TASK;
+ enum dsp_strmmode strm_mode;
struct node_strmdef *pstrm_def;
struct node_strmdef *input = NULL;
struct node_strmdef *output = NULL;
@@ -857,60 +857,49 @@ int node_connect(struct node_object *node1, u32 stream1,
int status = 0;
DBC_REQUIRE(refs 0);
- if ((node1 != (struct node_object *)DSP_HGPPNODE !node1) ||
- (node2 != (struct node_object *)DSP_HGPPNODE !node2))
- status = -EFAULT;
+ if (!node1 || !node2)
+ return -EFAULT;
- if (!status) {
- /* The two nodes must be on the same processor */
- if (node1 != (struct node_object *)DSP_HGPPNODE
- node2 != (struct node_object *)DSP_HGPPNODE
- node1-hnode_mgr != node2-hnode_mgr)
- status = -EPERM;
- /* Cannot connect a node to itself */
- if (node1 == node2)
- status = -EPERM;
+ /* The two nodes must be on the same processor */
+ if (node1 != (struct node_object *)DSP_HGPPNODE
+ node2 != (struct node_object *)DSP_HGPPNODE
+ node1-hnode_mgr != node2-hnode_mgr)
+ return -EPERM;
- }
- if (!status) {
- /* node_get_type() will return NODE_GPP if hnode =
-* DSP_HGPPNODE. */
- node1_type = node_get_type(node1);
- node2_type = node_get_type(node2);
- /* Check stream indices ranges */
- if ((node1_type != NODE_GPP node1_type != NODE_DEVICE
-stream1 = MAX_OUTPUTS(node1)) || (node2_type != NODE_GPP
- node2_type !=
- NODE_DEVICE
- stream2 =
- MAX_INPUTS(node2)))
- status = -EINVAL;
- }
- if (!status) {
- /*
-* Only the following types of connections are allowed:
-* task/dais socket == task/dais socket
-* task/dais socket == device
-* task/dais socket == GPP
-*
-* ie, no message nodes, and at least one task or dais
-* socket node.
-*/
- if (node1_type == NODE_MESSAGE || node2_type == NODE_MESSAGE ||
- (node1_type != NODE_TASK node1_type != NODE_DAISSOCKET
-node2_type != NODE_TASK node2_type != NODE_DAISSOCKET))
- status = -EPERM;
- }
+ /* Cannot connect a node to itself */
+ if (node1 == node2)
+ return -EPERM;
+
+ /* node_get_type() will return NODE_GPP if hnode = DSP_HGPPNODE. */
+ node1_type = node_get_type(node1);
+ node2_type = node_get_type(node2);
+ /* Check stream indices ranges */
+ if ((node1_type != NODE_GPP node1_type != NODE_DEVICE
+ stream1 = MAX_OUTPUTS(node1)) ||
+ (node2_type != NODE_GPP node2_type != NODE_DEVICE
+stream2 = MAX_INPUTS(node2)))
+ return -EINVAL;
+
+ /*
+* Only the following types of connections are allowed:
+* task/dais socket == task/dais socket
+* task/dais socket ==
[PATCH 2/2] staging: tidspbridge: rmgr code cleanup
Reorganized some code in the rmgr module to increase
its readability. No functional changes were done.
Signed-off-by: Ionut Nicu ionut.n...@mindbit.ro
---
drivers/staging/tidspbridge/rmgr/drv.c | 171 +---
drivers/staging/tidspbridge/rmgr/node.c | 81 +-
drivers/staging/tidspbridge/rmgr/rmm.c | 266 +-
3 files changed, 229 insertions(+), 289 deletions(-)
diff --git a/drivers/staging/tidspbridge/rmgr/drv.c
b/drivers/staging/tidspbridge/rmgr/drv.c
index e0fc895..71a9489 100644
--- a/drivers/staging/tidspbridge/rmgr/drv.c
+++ b/drivers/staging/tidspbridge/rmgr/drv.c
@@ -304,40 +304,28 @@ int drv_proc_update_strm_res(u32 num_bufs, void
*strm_resources)
*/
int drv_create(struct drv_object **drv_obj)
{
- int status = 0;
struct drv_object *pdrv_object = NULL;
struct drv_data *drv_datap = dev_get_drvdata(bridge);
DBC_REQUIRE(drv_obj != NULL);
DBC_REQUIRE(refs 0);
+ if (!drv_datap)
+ return -EFAULT;
+
pdrv_object = kzalloc(sizeof(struct drv_object), GFP_KERNEL);
- if (pdrv_object) {
- /* Create and Initialize List of device objects */
- INIT_LIST_HEAD(pdrv_object-dev_list);
- INIT_LIST_HEAD(pdrv_object-dev_node_string);
- } else {
- status = -ENOMEM;
- }
- /* Store the DRV Object in the driver data */
- if (!status) {
- if (drv_datap) {
- drv_datap-drv_object = (void *)pdrv_object;
- } else {
- status = -EPERM;
- pr_err(%s: Failed to store DRV object\n, __func__);
- }
- }
+ if (!pdrv_object)
+ return -ENOMEM;
- if (!status) {
- *drv_obj = pdrv_object;
- } else {
- /* Free the DRV Object */
- kfree(pdrv_object);
- }
+ /* Create and Initialize List of device objects */
+ INIT_LIST_HEAD(pdrv_object-dev_list);
+ INIT_LIST_HEAD(pdrv_object-dev_node_string);
- DBC_ENSURE(status || pdrv_object);
- return status;
+ /* Store the DRV Object in the driver data */
+ drv_datap-drv_object = (void *)pdrv_object;
+ *drv_obj = pdrv_object;
+
+ return 0;
}
/*
@@ -424,19 +412,19 @@ int drv_get_dev_object(u32 index, struct drv_object
*hdrv_obj,
*/
u32 drv_get_first_dev_object(void)
{
- u32 dw_dev_object = 0;
struct drv_object *pdrv_obj;
struct drv_data *drv_datap = dev_get_drvdata(bridge);
- if (drv_datap drv_datap-drv_object) {
- pdrv_obj = drv_datap-drv_object;
- if (!list_empty(pdrv_obj-dev_list))
- dw_dev_object = (u32) pdrv_obj-dev_list.next;
- } else {
+ if (!drv_datap || !drv_datap-drv_object) {
pr_err(%s: Failed to retrieve the object handle\n, __func__);
+ return 0;
}
- return dw_dev_object;
+ pdrv_obj = drv_datap-drv_object;
+ if (list_empty(pdrv_obj-dev_list))
+ return 0;
+
+ return (u32) pdrv_obj-dev_list.next;
}
/*
@@ -447,21 +435,19 @@ u32 drv_get_first_dev_object(void)
*/
u32 drv_get_first_dev_extension(void)
{
- u32 dw_dev_extension = 0;
struct drv_object *pdrv_obj;
struct drv_data *drv_datap = dev_get_drvdata(bridge);
- if (drv_datap drv_datap-drv_object) {
- pdrv_obj = drv_datap-drv_object;
- if (!list_empty(pdrv_obj-dev_node_string)) {
- dw_dev_extension =
- (u32) pdrv_obj-dev_node_string.next;
- }
- } else {
+ if (!drv_datap || !drv_datap-drv_object) {
pr_err(%s: Failed to retrieve the object handle\n, __func__);
+ return 0;
}
- return dw_dev_extension;
+ pdrv_obj = drv_datap-drv_object;
+ if (list_empty(pdrv_obj-dev_node_string))
+ return 0;
+
+ return (u32) pdrv_obj-dev_node_string.next;
}
/*
@@ -473,24 +459,25 @@ u32 drv_get_first_dev_extension(void)
*/
u32 drv_get_next_dev_object(u32 hdev_obj)
{
- u32 dw_next_dev_object = 0;
struct drv_object *pdrv_obj;
struct drv_data *drv_datap = dev_get_drvdata(bridge);
struct list_head *curr;
- if (drv_datap drv_datap-drv_object) {
- pdrv_obj = drv_datap-drv_object;
- if (!list_empty(pdrv_obj-dev_list)) {
- curr = (struct list_head *)hdev_obj;
- if (list_is_last(curr, pdrv_obj-dev_list))
- return 0;
- dw_next_dev_object = (u32) curr-next;
- }
- } else {
+ if (!drv_datap || !drv_datap-drv_object) {
pr_err(%s: Failed to retrieve the object handle\n, __func__);
+ return 0;
}
-
[PATCH v2 0/8] OMAP34: clock data: Fixes and add new clocks nodes
Hi Paul, Here is a collections of fixes and clock nodes addition done on OMAP3 and OMAP4 clock data files. I have included the one that Thara already submitted after fixing the various comments done on the original version. That revision include as well a new fix from Jon. Thanks to both fixes, the clocks rate are now accurate and the func_48m_fclk does report 48MHz now! Cool isn't it? Tested on sdp4430 + ES2.0. The series is based on 2.6.37-rc5 and is available here: git://gitorious.org/omap-pm/linux.git for_2.6.38/clock Regards, Benoit 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 Jon Hunter (1): OMAP4: clock data: Add missing fixed divisors Jonathan Bergsagel (1): OMAP4: clock data: Add missing fields in iva_hsd_byp_clk_mux_ck 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-omap2/clock3xxx_data.c |2 + arch/arm/mach-omap2/clock44xx_data.c | 653 -- arch/arm/mach-omap2/scrm44xx.h | 176 + 3 files changed, 640 insertions(+), 191 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 v2 1/8] OMAP4: clock data: Add control for pad_clks_ck and slimbus_clk
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
Cc: 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 1599836..4395e2e 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 = {
--
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 v2 2/8] OMAP3: clock data: Add wkup_clkdm in sr1_fck and sr2_fck
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
Cc: 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 d85ecd5..741f6a0 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,
};
--
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 v2 4/8] 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
Cc: 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 123aa6d..6558d91 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 */
--
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 v2 3/8] 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
Cc: 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 4395e2e..123aa6d 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, .val = 19, .flags = RATE_IN_4430 },
- { .div = 20, .val = 20, .flags
[PATCH v2 5/8] OMAP4: PRCM: Add SCRM header file
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 Cc: 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 0x0420 +#define OMAP4_SCRM_EXTPWRONRSTCTRL
[PATCH v2 6/8] 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
Cc: 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 6558d91..fd7efe8 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 v2 8/8] OMAP4: clock data: Add missing fixed divisors
From: Jon Hunter jon-hun...@ti.com
The following OMAP4 clocks have the following fixed divisors that
determine the frequency at which these clocks operate. These
dividers are defined by the PRCM specification and without these
dividers the rates of the below clocks are calculated incorrectly.
This may cause internal peripherals using these clocks to operate
at the wrong frequency.
- abe_24m_fclk (freq = divided-by-8)
- ddrphy_ck (freq = parent divided-by-2)
- dll_clk_div_ck (freq = parent divided-by-2)
- per_hs_clk_div_ck (freq = parent divided-by-2)
- usb_hs_clk_div_ck (freq = parent divided-by-3)
- func_12m_fclk (freq = parent divided-by-16)
- func_24m_clk (freq = parent divided-by-4)
- func_24mc_fclk (freq = parent divided-by-8)
- func_48mc_fclk (freq = divided-by-4)
- lp_clk_div_ck (freq = divided-by-16)
- per_abe_24m_fclk (freq = divided-by-4)
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 33 ++---
1 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 51f28a0..953d97e 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -333,7 +333,8 @@ static struct clk abe_24m_fclk = {
.name = abe_24m_fclk,
.parent = dpll_abe_m2x2_ck,
.ops= clkops_null,
- .recalc = followparent_recalc,
+ .fixed_div = 8,
+ .recalc = omap_fixed_divisor_recalc,
};
static const struct clksel_rate div3_1to4_rates[] = {
@@ -499,7 +500,8 @@ static struct clk ddrphy_ck = {
.name = ddrphy_ck,
.parent = dpll_core_m2_ck,
.ops= clkops_null,
- .recalc = followparent_recalc,
+ .fixed_div = 2,
+ .recalc = omap_fixed_divisor_recalc,
};
static struct clk dpll_core_m5x2_ck = {
@@ -584,7 +586,8 @@ static struct clk dll_clk_div_ck = {
.name = dll_clk_div_ck,
.parent = dpll_core_m4x2_ck,
.ops= clkops_null,
- .recalc = followparent_recalc,
+ .fixed_div = 2,
+ .recalc = omap_fixed_divisor_recalc,
};
static const struct clksel dpll_abe_m2_div[] = {
@@ -773,7 +776,8 @@ static struct clk per_hs_clk_div_ck = {
.name = per_hs_clk_div_ck,
.parent = dpll_abe_m3x2_ck,
.ops= clkops_null,
- .recalc = followparent_recalc,
+ .fixed_div = 2,
+ .recalc = omap_fixed_divisor_recalc,
};
static const struct clksel per_hsd_byp_clk_mux_sel[] = {
@@ -986,7 +990,8 @@ static struct clk usb_hs_clk_div_ck = {
.name = usb_hs_clk_div_ck,
.parent = dpll_abe_m3x2_ck,
.ops= clkops_null,
- .recalc = followparent_recalc,
+ .fixed_div = 3,
+ .recalc = omap_fixed_divisor_recalc,
};
/* DPLL_USB */
@@ -1066,21 +1071,24 @@ static struct clk func_12m_fclk = {
.name = func_12m_fclk,
.parent = dpll_per_m2x2_ck,
.ops= clkops_null,
- .recalc = followparent_recalc,
+ .fixed_div = 16,
+ .recalc = omap_fixed_divisor_recalc,
};
static struct clk func_24m_clk = {
.name = func_24m_clk,
.parent = dpll_per_m2_ck,
.ops= clkops_null,
- .recalc = followparent_recalc,
+ .fixed_div = 4,
+ .recalc = omap_fixed_divisor_recalc,
};
static struct clk func_24mc_fclk = {
.name = func_24mc_fclk,
.parent = dpll_per_m2x2_ck,
.ops= clkops_null,
- .recalc = followparent_recalc,
+ .fixed_div = 8,
+ .recalc = omap_fixed_divisor_recalc,
};
static const struct clksel_rate div2_4to8_rates[] = {
@@ -1110,7 +1118,8 @@ static struct clk func_48mc_fclk = {
.name = func_48mc_fclk,
.parent = dpll_per_m2x2_ck,
.ops= clkops_null,
- .recalc = followparent_recalc,
+ .fixed_div = 4,
+ .recalc = omap_fixed_divisor_recalc,
};
static const struct clksel_rate div2_2to4_rates[] = {
@@ -1227,7 +1236,8 @@ static struct clk lp_clk_div_ck = {
.name = lp_clk_div_ck,
.parent = dpll_abe_m2x2_ck,
.ops= clkops_null,
- .recalc = followparent_recalc,
+ .fixed_div = 16,
+ .recalc = omap_fixed_divisor_recalc,
};
static const struct clksel l4_wkup_clk_mux_sel[] = {
@@ -1295,7 +1305,8 @@ static struct clk per_abe_24m_fclk = {
.name
[PATCH v2 7/8] 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
Cc: 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 fd7efe8..51f28a0 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,
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: device: make rt_va easily avaialable to drivers
On Wed, Dec 8, 2010 at 5:59 PM, Omar Ramirez Luna omar.rami...@ti.com wrote:
Patch OMAP: hwmod/device: add omap_{device, hwmod}_get_mpu_rt_va[1],
introduces omap_device_get_rt_va which is meant to be called
by drivers to retrieve the _mpu_rt_va, however this function
receives a pointer to an omap_device; since there is no
practical way for a driver to get this parameter without
fiddling with pdev and container_of macro, and omap_device code
already does this, it is better for it to handle this case.
Also moved header declaration to appear in the set of
functions to be used by drivers, as per the comment there.
[1] http://marc.info/?l=linux-omapm=127808467703366w=2
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
Acked-by: Hari Kanigeri h-kanige...@ti.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;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/2] I2C: i2c-omap: Change device name: i2c_omap - omap_i2c
Hi, Kevin Hilman [khil...@deeprootsystems.com]: Ben Dooks ben-...@fluff.org writes: Renaming stuff like this is going to have an impact on the userspace as anyone looking through /sys's driver heirarchy is going to miss the old name... It all depends if you really want to go ahead with this... Yes, we are aware of the userspace impact, but this name change makes all devices on OMAP have consistent names and actually improves the ability to have userspace tools have consistent naming as well. So there are no imporant users, or if there is, they are prepared for this change? drivers/i2c/busses/i2c-omap.c|4 ++-- What about the .c / .ko file name? A. -- To unsubscribe from this list: send the line unsubscribe 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 v8 01/11] OMAP: GPIO: prepare for platform driver
Cousson, Benoit b-cous...@ti.com writes:
Salut Kevin,
On 12/9/2010 8:18 PM, Kevin Hilman wrote:
Hi Charu,
Varadarajan, Charulathach...@ti.com writes:
Prepare for implementing GPIO as a platform driver.
Modifies omap_gpio_init() to make use of omap_gpio_chip_init()
and omap_gpio_mod_init(). omap_gpio_mod_init() does the module init
by clearing the status register and initializing the GPIO control register.
omap_gpio_chip_init() initializes the chip request, free, get, set and
other function pointers and sets the gpio irq handler.
This is only to reorganize the code so that the omap gpio platform driver
implementation patch looks cleaner and better to review.
Signed-off-by: Charulatha Vch...@ti.com
I just noticed while testing on 36xx/Zoom3 that GPIO wakeups are no
longer working after this series.
The problem seems to be that for OMAP2+, this series removed manual
SYSCONFIG register setting in favor of using omap_hwmod (which is good),
however some of the SYSCONFIG values, specifically, in the current code,
the ENAWAKEUP bit was set in each bank, but this is no longer the
default with omap_hwmod.
That part is strange, because Rajendra did a patch to enable the
wakeup bit during _omap_hwmod_enable as soon as the idlemode is set to
smartidle.
/* If slave port is in SMARTIDLE, also enable wakeup */
if ((sf SYSC_HAS_SIDLEMODE) (s_idlemode == HWMOD_IDLEMODE_SMART))
_enable_wakeup(oh);
The _disable_wakeup is never called, so in theory once it is set, it
should remain enabled.
Does that mean that this the GPIO is not in smartidle anymore in your case?
Looks like a bug in the patch that added automatic wakeup enables.
Basically, wakeups are enabled, but are promptly disabled if
SYSC_HAS_AUTOIDLE. Here's the code:
/*
* XXX The clock framework should handle this, by
* calling into this code. But this must wait until the
* clock structures are tagged with omap_hwmod entries
*/
if ((oh-flags HWMOD_SET_DEFAULT_CLOCKACT)
(sf SYSC_HAS_CLOCKACTIVITY))
_set_clockactivity(oh, oh-class-sysc-clockact, v);
_write_sysconfig(v, oh);
OK, so here, 'v' has wakeups disabled.
/* If slave is in SMARTIDLE, also enable wakeup */
if ((sf SYSC_HAS_SIDLEMODE) !(oh-flags HWMOD_SWSUP_SIDLE))
_enable_wakeup(oh);
Here we enabled them directly in SYSC (but 'v' is not updated)
/*
* Set the autoidle bit only after setting the smartidle bit
* Setting this will not have any impact on the other modules.
*/
if (sf SYSC_HAS_AUTOIDLE) {
idlemode = (oh-flags HWMOD_NO_OCP_AUTOIDLE) ?
0 : 1;
_set_module_autoidle(oh, idlemode, v);
_write_sysconfig(v, oh);
}
And here, SYSCONFIG is updated again using 'v', which does not have
wakeups enabled.
A quick patch (below) shows that if I update 'v' after enabling wakeups,
the problem is fixed.
I'll cook up a cleaner patch for this, but I think the solution is
probably to change _enable_wakeup() to take the 'v' argument and modify
it instead of directly writing SYSCONFIG. That will make it more like
all the other helper functions.
Kevin
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 12856eb..adcb1fc 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -791,8 +791,10 @@ static void _enable_sysc(struct omap_hwmod *oh)
_write_sysconfig(v, oh);
/* If slave is in SMARTIDLE, also enable wakeup */
- if ((sf SYSC_HAS_SIDLEMODE) !(oh-flags HWMOD_SWSUP_SIDLE))
+ if ((sf SYSC_HAS_SIDLEMODE) !(oh-flags HWMOD_SWSUP_SIDLE)) {
_enable_wakeup(oh);
+ v = oh-_sysc_cache;
+ }
/*
* Set the autoidle bit only after setting the smartidle bit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] I2C: i2c-omap: Change device name: i2c_omap - omap_i2c
On Thu, Dec 09, 2010 at 10:18:48PM +, aaro.koski...@nokia.com wrote: Hi, Kevin Hilman [khil...@deeprootsystems.com]: Ben Dooks ben-...@fluff.org writes: Renaming stuff like this is going to have an impact on the userspace as anyone looking through /sys's driver heirarchy is going to miss the old name... It all depends if you really want to go ahead with this... Yes, we are aware of the userspace impact, but this name change makes all devices on OMAP have consistent names and actually improves the ability to have userspace tools have consistent naming as well. So there are no imporant users, or if there is, they are prepared for this change? drivers/i2c/busses/i2c-omap.c|4 ++-- What about the .c / .ko file name? Pretty much everyone is in the form of i2c-xxx.c, so I would prefer it to stay that way. -- Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/ Large Hadron Colada: A large Pina Colada that makes the universe disappear. -- To unsubscribe from this list: send the line unsubscribe 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 Omar,
On Thu, 2010-12-09 at 23:47 +0200, Ionut Nicu wrote:
Reorganized some code in rmgr/node.c to increase its
readability. Most of the changes reduce the code
indentation level and simplifiy the code. No functional
changes were done.
snip
/*
* Check stream mode. Default is STRMMODE_PROCCOPY.
*/
- if (!status pattrs) {
- if (pattrs-strm_mode != STRMMODE_PROCCOPY)
- status = -EPERM;/* illegal stream mode */
-
- }
- if (status)
- goto func_end;
+ if (pattrs pattrs-strm_mode != STRMMODE_PROCCOPY)
+ return -EPERM; /* illegal stream mode */
While cleaning up and reviewing the code I saw this check, which unless
it's intentional I think it looks like a bug. See comment below.
snip
+ strm_mode = pattrs ? pattrs-strm_mode : STRMMODE_PROCCOPY;
+ switch (strm_mode) {
+ case STRMMODE_RDMA:
...
+
+ case STRMMODE_ZEROCOPY:
...
+ case STRMMODE_PROCCOPY:
It looks like all modes are handled here although the only one that
could escape the validation from above is STRMMODE_PROCCOPY.
I tried removing the first check and tested with the
userspace-dspbridge strmcopy application, but I noticed the DSP hangs if
I try to use it with anything else than the copy mode.
Are the other modes (rdma, zerocopy) not supported at all?
Thanks,
Ionut.
--
To unsubscribe from this list: send the line unsubscribe 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 v8 01/11] OMAP: GPIO: prepare for platform driver
On 12/9/2010 11:19 PM, Kevin Hilman wrote:
Cousson, Benoitb-cous...@ti.com writes:
Salut Kevin,
On 12/9/2010 8:18 PM, Kevin Hilman wrote:
Hi Charu,
Varadarajan, Charulathach...@ti.com writes:
Prepare for implementing GPIO as a platform driver.
Modifies omap_gpio_init() to make use of omap_gpio_chip_init()
and omap_gpio_mod_init(). omap_gpio_mod_init() does the module init
by clearing the status register and initializing the GPIO control register.
omap_gpio_chip_init() initializes the chip request, free, get, set and
other function pointers and sets the gpio irq handler.
This is only to reorganize the code so that the omap gpio platform driver
implementation patch looks cleaner and better to review.
Signed-off-by: Charulatha Vch...@ti.com
I just noticed while testing on 36xx/Zoom3 that GPIO wakeups are no
longer working after this series.
The problem seems to be that for OMAP2+, this series removed manual
SYSCONFIG register setting in favor of using omap_hwmod (which is good),
however some of the SYSCONFIG values, specifically, in the current code,
the ENAWAKEUP bit was set in each bank, but this is no longer the
default with omap_hwmod.
That part is strange, because Rajendra did a patch to enable the
wakeup bit during _omap_hwmod_enable as soon as the idlemode is set to
smartidle.
/* If slave port is in SMARTIDLE, also enable wakeup */
if ((sf SYSC_HAS_SIDLEMODE) (s_idlemode == HWMOD_IDLEMODE_SMART))
_enable_wakeup(oh);
The _disable_wakeup is never called, so in theory once it is set, it
should remain enabled.
Does that mean that this the GPIO is not in smartidle anymore in your case?
Looks like a bug in the patch that added automatic wakeup enables.
Basically, wakeups are enabled, but are promptly disabled if
SYSC_HAS_AUTOIDLE. Here's the code:
/*
* XXX The clock framework should handle this, by
* calling into this code. But this must wait until the
* clock structures are tagged with omap_hwmod entries
*/
if ((oh-flags HWMOD_SET_DEFAULT_CLOCKACT)
(sf SYSC_HAS_CLOCKACTIVITY))
_set_clockactivity(oh, oh-class-sysc-clockact,v);
_write_sysconfig(v, oh);
OK, so here, 'v' has wakeups disabled.
/* If slave is in SMARTIDLE, also enable wakeup */
if ((sf SYSC_HAS_SIDLEMODE) !(oh-flags HWMOD_SWSUP_SIDLE))
_enable_wakeup(oh);
Here we enabled them directly in SYSC (but 'v' is not updated)
/*
* Set the autoidle bit only after setting the smartidle bit
* Setting this will not have any impact on the other modules.
*/
if (sf SYSC_HAS_AUTOIDLE) {
idlemode = (oh-flags HWMOD_NO_OCP_AUTOIDLE) ?
0 : 1;
_set_module_autoidle(oh, idlemode,v);
_write_sysconfig(v, oh);
}
And here, SYSCONFIG is updated again using 'v', which does not have
wakeups enabled.
A quick patch (below) shows that if I update 'v' after enabling wakeups,
the problem is fixed.
I'll cook up a cleaner patch for this, but I think the solution is
probably to change _enable_wakeup() to take the 'v' argument and modify
it instead of directly writing SYSCONFIG. That will make it more like
all the other helper functions.
Funny, I did a patch that does that yesterday just because the wakeup
enable on some OMAP4 IPs does require changing the idlemode as well.
So I added a new _set_enawakeup API to use the same programming model.
+static int _set_enawakeup(struct omap_hwmod *oh, u8 enawakeup, u32 *v)
{
- u32 v, wakeup_mask;
+ u32 wakeup_mask;
+ u8 wakeup_shift;
if (!oh-class-sysc ||
!(oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP))
@@ -401,10 +402,44 @@ static int _enable_wakeup(struct omap_hwmod *oh)
return -EINVAL;
}
- wakeup_mask = (0x1 oh-class-sysc-sysc_fields-enwkup_shift);
+ wakeup_shift = oh-class-sysc-sysc_fields-enwkup_shift;
+ wakeup_mask = 0x1 wakeup_shift;
+
+ *v = ~wakeup_mask;
+ *v |= enawakeup wakeup_shift;
+
+ return 0;
+}
+
That does not solve the issue I was trying to fix with the McPDM driver,
that's why I didn't send it yet, but that might be enough for the GPIO.
Regards,
Benoit
Kevin
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 12856eb..adcb1fc 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -791,8 +791,10 @@ static void _enable_sysc(struct omap_hwmod *oh)
_write_sysconfig(v, oh);
/* If slave is in SMARTIDLE, also enable wakeup */
- if ((sf SYSC_HAS_SIDLEMODE) !(oh-flags HWMOD_SWSUP_SIDLE))
+ if ((sf SYSC_HAS_SIDLEMODE) !(oh-flags HWMOD_SWSUP_SIDLE)) {
_enable_wakeup(oh);
+ v = oh-_sysc_cache;
+ }
/*
* Set the autoidle bit only after setting the smartidle bit
--
To
Re: [PATCH 11/14] OMAP4: PRCM: reorganize existing OMAP4 PRCM header files
Salut Paul, On 12/8/2010 7:47 AM, Paul Walmsley wrote: Salut Benoît, On Tue, 7 Dec 2010, Cousson, Benoit wrote: Salut Paul, On 12/7/2010 2:25 AM, Paul Walmsley wrote: Split the existing cm44xx.h file into cm1_44xx.h and cm2_44xx.h files so they match their underlying OMAP hardware modules. Add clockdomain offset information. Add header files for the MPU local PRCM, prcm_mpu44xx.h, and for the SCRM, scrm44xx.h. SCRM register offsets still need to be added; TI should do this. And we did it :-) Even better :-) I sent it last week along with clock data series: https://patchwork.kernel.org/patch/373751/ OK, I've just realized that it was a little bit hidden in the clock data patch, and maybe we should have been sent two patches. Sorry for that. Do you want to take it in that series, or should I re-sent the clock data one? I guess it's better done in the clock series; that should avoid a branch dependency between the PRCM patchsets and the clock patch sets. One thing that would be nice on the scrm44xx.h file is to keep the _OFFSET macros. It would be nice in the long run to get rid of the absolute addressing macros in case someone decides to shuffle around the IP block addresses again... can you update your clock series with that change? OK, this is done. I've just posted it. 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] staging: tidspbridge: rmgr/node.c code cleanup
On Fri, Dec 10, 2010 at 12:22 AM, Ionut Nicu ionut.n...@mindbit.ro wrote: I tried removing the first check and tested with the userspace-dspbridge strmcopy application, but I noticed the DSP hangs if I try to use it with anything else than the copy mode. Are the other modes (rdma, zerocopy) not supported at all? AFAIK that's the case. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe 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 Ionut,
On Thu, Dec 9, 2010 at 4:22 PM, Ionut Nicu ionut.n...@mindbit.ro wrote:
Hi Omar,
On Thu, 2010-12-09 at 23:47 +0200, Ionut Nicu wrote:
Reorganized some code in rmgr/node.c to increase its
readability. Most of the changes reduce the code
indentation level and simplifiy the code. No functional
changes were done.
snip
/*
* Check stream mode. Default is STRMMODE_PROCCOPY.
*/
- if (!status pattrs) {
- if (pattrs-strm_mode != STRMMODE_PROCCOPY)
- status = -EPERM; /* illegal stream mode */
-
- }
- if (status)
- goto func_end;
+ if (pattrs pattrs-strm_mode != STRMMODE_PROCCOPY)
+ return -EPERM; /* illegal stream mode */
While cleaning up and reviewing the code I saw this check, which unless
it's intentional I think it looks like a bug. See comment below.
snip
+ strm_mode = pattrs ? pattrs-strm_mode : STRMMODE_PROCCOPY;
+ switch (strm_mode) {
+ case STRMMODE_RDMA:
...
+
+ case STRMMODE_ZEROCOPY:
...
+ case STRMMODE_PROCCOPY:
It looks like all modes are handled here although the only one that
could escape the validation from above is STRMMODE_PROCCOPY.
I tried removing the first check and tested with the
userspace-dspbridge strmcopy application, but I noticed the DSP hangs if
I try to use it with anything else than the copy mode.
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.
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
[PATCH] OMAP2+: omap_hwmod: fix wakeup enable/disable for consistency
In the omap_hwmod core, most of the SYSCONFIG register helper
functions do not directly write the register, but instead just modify
a value passed in.
This patch converts the _enable_wakeup() and _disable_wakeup() helper
functions to take a value argument and only modify it instead of
actually writing the register. This makes the wakeup helpers
consistent with the other helper functions and avoids unintentional
problems like the following.
This problem was found after discovering that GPIO wakeups were no
longer functional. The root cause was that the ENAWAKEUP bit of the
SYSCONFIG register was being unintentionaly overwritten, leaving
wakeups disabled after the following two commits were combined:
commit: 9980ce53c97392a3dbdc9d1ac3e455d79b4167ed
OMAP: hwmod: Enable module wakeup if in smartidle
commit: 78f26e872f77b6312273216de1a8f836c6f2e143
OMAP: hwmod: Set autoidle after smartidle during _sysc_enable
There resulting in code in _enable_sysc() was this:
/*
* XXX The clock framework should handle this, by
* calling into this code. But this must wait until the
* clock structures are tagged with omap_hwmod entries
*/
if ((oh-flags HWMOD_SET_DEFAULT_CLOCKACT)
(sf SYSC_HAS_CLOCKACTIVITY))
_set_clockactivity(oh, oh-class-sysc-clockact, v);
_write_sysconfig(v, oh);
so here, 'v' has wakeups disabled.
/* If slave is in SMARTIDLE, also enable wakeup */
if ((sf SYSC_HAS_SIDLEMODE) !(oh-flags HWMOD_SWSUP_SIDLE))
_enable_wakeup(oh);
Here wakeup is enabled in the SYSCONFIG register (but 'v' is not updated)
/*
* Set the autoidle bit only after setting the smartidle bit
* Setting this will not have any impact on the other modules.
*/
if (sf SYSC_HAS_AUTOIDLE) {
idlemode = (oh-flags HWMOD_NO_OCP_AUTOIDLE) ?
0 : 1;
_set_module_autoidle(oh, idlemode, v);
_write_sysconfig(v, oh);
}
And here, SYSCONFIG is updated again using 'v', which does not have
wakeups enabled, resulting in ENAWAKEUP being cleared.
Special thanks to Benoit Cousson for pointing out that wakeups were
supposed to be automatically enabled when a hwmod is enabled, and thus
helping target the root cause of this problem.
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
Applies on top of Paul's hwmod_a_2.6.38 branch.
arch/arm/mach-omap2/omap_hwmod.c | 32 +---
1 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index a039b37..84a03eb 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -388,9 +388,9 @@ static int _set_module_autoidle(struct omap_hwmod *oh, u8
autoidle,
* Allow the hardware module @oh to send wakeups. Returns -EINVAL
* upon error or 0 upon success.
*/
-static int _enable_wakeup(struct omap_hwmod *oh)
+static int _enable_wakeup(struct omap_hwmod *oh, u32 *v)
{
- u32 v, wakeup_mask;
+ u32 wakeup_mask;
if (!oh-class-sysc ||
!(oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP))
@@ -403,9 +403,7 @@ static int _enable_wakeup(struct omap_hwmod *oh)
wakeup_mask = (0x1 oh-class-sysc-sysc_fields-enwkup_shift);
- v = oh-_sysc_cache;
- v |= wakeup_mask;
- _write_sysconfig(v, oh);
+ *v |= wakeup_mask;
/* XXX test pwrdm_get_wken for this hwmod's subsystem */
@@ -421,9 +419,9 @@ static int _enable_wakeup(struct omap_hwmod *oh)
* Prevent the hardware module @oh to send wakeups. Returns -EINVAL
* upon error or 0 upon success.
*/
-static int _disable_wakeup(struct omap_hwmod *oh)
+static int _disable_wakeup(struct omap_hwmod *oh, u32 *v)
{
- u32 v, wakeup_mask;
+ u32 wakeup_mask;
if (!oh-class-sysc ||
!(oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP))
@@ -436,9 +434,7 @@ static int _disable_wakeup(struct omap_hwmod *oh)
wakeup_mask = (0x1 oh-class-sysc-sysc_fields-enwkup_shift);
- v = oh-_sysc_cache;
- v = ~wakeup_mask;
- _write_sysconfig(v, oh);
+ *v = ~wakeup_mask;
/* XXX test pwrdm_get_wken for this hwmod's subsystem */
@@ -786,11 +782,11 @@ static void _enable_sysc(struct omap_hwmod *oh)
(sf SYSC_HAS_CLOCKACTIVITY))
_set_clockactivity(oh, oh-class-sysc-clockact, v);
- _write_sysconfig(v, oh);
-
/* If slave is in SMARTIDLE, also enable wakeup */
if ((sf SYSC_HAS_SIDLEMODE) !(oh-flags HWMOD_SWSUP_SIDLE))
- _enable_wakeup(oh);
+ _enable_wakeup(oh, v);
+
+ _write_sysconfig(v, oh);
/*
* Set the autoidle bit only after setting the smartidle bit
@@ -2009,13 +2005,16 @@ int
Re: [PATCH v8 01/11] OMAP: GPIO: prepare for platform driver
Hi Charu, I owe you an apology. Kevin Hilman khil...@deeprootsystems.com writes: [...] I just noticed while testing on 36xx/Zoom3 that GPIO wakeups are no longer working after this series. The problem seems to be that for OMAP2+, this series removed manual SYSCONFIG register setting in favor of using omap_hwmod (which is good), however some of the SYSCONFIG values, specifically, in the current code, the ENAWAKEUP bit was set in each bank, but this is no longer the default with omap_hwmod. I was wrong here. The enable wakeup mode was supposed to be enabled by default in the hwmod, but due to a bug[1], it was not. This problem was not directly related to your series. [...] ... but it shows that GPIO wakeups were not fully tested with this series. In the future, along with reporting what platforms it was testing on, it would be very helpful to include a summary of how the series was tested. I apologize for accusing you of not testing GPIO wakeups. I now know that this functionality was broken by patches independent of your series, so I deeply regret the accusation. Kevin [1] http://marc.info/?l=linux-omapm=129193625420446w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] OMAP4: hwmod data fixes and update
Hi Paul, Here is a small set of OMAP4 hwmod data updates. Re-order properly the data that were a little bit shuffled during the previous merge window. Add the new reset flags introduced in 2.6.37 and that were not used in the hwmod data. The OMAP2 and OMAP3 fixes should come soon. Fix some missing field in the GPIO OMAP4 hwmod data that I missed during the review. IVA and DSP are added just to allow the processors device creation at boot time and avoid the warnings. Thanks to Charu for testing the GPIO / WD_TIMER changes. Thanks to Govindraj for testing the UART changes. The series is based on lo/for-next (v2.6.37-rc5-66-ga2814df) and is available here: git://gitorious.org/omap-pm/linux.git for_2.6.38/hwmod_data Please note that there is a slight dependency with the following patch due to the name change of the iva fclk: OMAP4: clock data: Add missing DPLL x2 clock node https://patchwork.kernel.org/patch/396612/ Tested on sdp4430 + ES2.0/ES2.1. Regards, Benoit Benoit Cousson (5): OMAP4: hwmod data: Fix hwmod entries order OMAP4: hwmod data: Add SYSS_HAS_RESET_STATUS flag OMAP4: hwmod data: Fix missing address in DMM and EMIF_FW OMAP4: hwmod data: Add IVA and DSP OMAP4: hwmod clock data: Fix GPIO opt_clks and ocp_if iclk arch/arm/mach-omap2/clock44xx_data.c | 12 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 1256 ++-- 2 files changed, 822 insertions(+), 446 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: hwmod data: Fix hwmod entries order
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
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 1002 +++-
1 files changed, 553 insertions(+), 449 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index d258936..d8ef977 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -168,6 +168,7 @@ static struct omap_hwmod omap44xx_l3_instr_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/* l3_main_1 interface data */
/* l3_main_2 - l3_main_1 */
static struct omap_hwmod_ocp_if omap44xx_l3_main_2__l3_main_1 = {
.master = omap44xx_l3_main_2_hwmod,
@@ -384,6 +385,464 @@ static struct omap_hwmod omap44xx_l4_wkup_hwmod = {
};
/*
+ * 'mpu_bus' class
+ * instance(s): mpu_private
+ */
+static struct omap_hwmod_class omap44xx_mpu_bus_hwmod_class = {
+ .name = mpu_bus,
+};
+
+/* mpu_private interface data */
+/* mpu - mpu_private */
+static struct omap_hwmod_ocp_if omap44xx_mpu__mpu_private = {
+ .master = omap44xx_mpu_hwmod,
+ .slave = omap44xx_mpu_private_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mpu_private slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_mpu_private_slaves[] = {
+ omap44xx_mpu__mpu_private,
+};
+
+static struct omap_hwmod omap44xx_mpu_private_hwmod = {
+ .name = mpu_private,
+ .class = omap44xx_mpu_bus_hwmod_class,
+ .slaves = omap44xx_mpu_private_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_mpu_private_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/*
+ * Modules omap_hwmod structures
+ *
+ * The following IPs are excluded for the moment because:
+ * - They do not need an explicit SW control using omap_hwmod API.
+ * - They still need to be validated with the driver
+ * properly adapted to omap_hwmod / omap_device
+ *
+ * aess
+ * bandgap
+ * c2c
+ * c2c_target_fw
+ * cm_core
+ * cm_core_aon
+ * counter_32k
+ * ctrl_module_core
+ * ctrl_module_pad_core
+ * ctrl_module_pad_wkup
+ * ctrl_module_wkup
+ * debugss
+ * dma_system
+ * dmic
+ * dsp
+ * dss
+ * dss_dispc
+ * dss_dsi1
+ * dss_dsi2
+ * dss_hdmi
+ * dss_rfbi
+ * dss_venc
+ * efuse_ctrl_cust
+ * efuse_ctrl_std
+ * elm
+ * emif1
+ * emif2
+ * fdif
+ * gpmc
+ * gpu
+ * hdq1w
+ * hsi
+ * ipu
+ * iss
+ * iva
+ * kbd
+ * mailbox
+ * mcasp
+ * mcbsp1
+ * mcbsp2
+ * mcbsp3
+ * mcbsp4
+ * mcpdm
+ * mcspi1
+ * mcspi2
+ * mcspi3
+ * mcspi4
+ * mmc1
+ * mmc2
+ * mmc3
+ * mmc4
+ * mmc5
+ * mpu_c0
+ * mpu_c1
+ * ocmc_ram
+ * ocp2scp_usb_phy
+ * ocp_wp_noc
+ * prcm
+ * prcm_mpu
+ * prm
+ * scrm
+ * sl2if
+ * slimbus1
+ * slimbus2
+ * smartreflex_core
+ * smartreflex_iva
+ * smartreflex_mpu
+ * spinlock
+ * timer1
+ * timer10
+ * timer11
+ * timer2
+ * timer3
+ * timer4
+ * timer5
+ * timer6
+ * timer7
+ * timer8
+ * timer9
+ * usb_host_fs
+ * usb_host_hs
+ * usb_otg_hs
+ * usb_phy_cm
+ * usb_tll_hs
+ * usim
+ */
+
+/*
+ * 'gpio' class
+ * general purpose io module
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_gpio_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0114,
+ .sysc_flags = (SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_gpio_hwmod_class = {
+ .name = gpio,
+ .sysc = omap44xx_gpio_sysc,
+ .rev = 2,
+};
+
+/* gpio dev_attr */
+static struct omap_gpio_dev_attr gpio_dev_attr = {
+ .bank_width = 32,
+ .dbck_flag = true,
+};
+
+/* gpio1 */
+static struct omap_hwmod omap44xx_gpio1_hwmod;
+static struct omap_hwmod_irq_info omap44xx_gpio1_irqs[] = {
+ { .irq = 29 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_gpio1_addrs[] = {
+ {
+
[PATCH 3/5] OMAP4: hwmod data: Fix missing address in DMM and EMIF_FW
The DMM is a piece of interconnect that need to be configured properly
for the tiler functionnality. It thus exposes some configuration registers
that were missing previously.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 26 +++---
1 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 1e3a94e..7dccba3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -68,7 +68,15 @@ static struct omap_hwmod_ocp_if omap44xx_l3_main_1__dmm = {
.master = omap44xx_l3_main_1_hwmod,
.slave = omap44xx_dmm_hwmod,
.clk= l3_div_ck,
- .user = OCP_USER_MPU | OCP_USER_SDMA,
+ .user = OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_addr_space omap44xx_dmm_addrs[] = {
+ {
+ .pa_start = 0x4e00,
+ .pa_end = 0x4e0007ff,
+ .flags = ADDR_TYPE_RT
+ },
};
/* mpu - dmm */
@@ -76,7 +84,9 @@ static struct omap_hwmod_ocp_if omap44xx_mpu__dmm = {
.master = omap44xx_mpu_hwmod,
.slave = omap44xx_dmm_hwmod,
.clk= l3_div_ck,
- .user = OCP_USER_MPU | OCP_USER_SDMA,
+ .addr = omap44xx_dmm_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_dmm_addrs),
+ .user = OCP_USER_MPU,
};
/* dmm slave ports */
@@ -116,12 +126,22 @@ static struct omap_hwmod_ocp_if omap44xx_dmm__emif_fw = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_addr_space omap44xx_emif_fw_addrs[] = {
+ {
+ .pa_start = 0x4a20c000,
+ .pa_end = 0x4a20c0ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
/* l4_cfg - emif_fw */
static struct omap_hwmod_ocp_if omap44xx_l4_cfg__emif_fw = {
.master = omap44xx_l4_cfg_hwmod,
.slave = omap44xx_emif_fw_hwmod,
.clk= l4_div_ck,
- .user = OCP_USER_MPU | OCP_USER_SDMA,
+ .addr = omap44xx_emif_fw_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_emif_fw_addrs),
+ .user = OCP_USER_MPU,
};
/* emif_fw slave ports */
--
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: hwmod data: Add SYSS_HAS_RESET_STATUS flag
Update the data for GPIO, UART, WD_TIMER and I2C in order to
support the new reset status flag introduce in the following
commit:
commit 2cb068149c365f1c2b10f2ece6786139527dcc16
OMAP: hwmod: Fix softreset status check for some new OMAP4 IPs
Without this flag properly set, the reset is done, but the hwmod
core code will not wait for the reset completion to continue its
excecution.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Tested-by: Charulatha V ch...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index d8ef977..1e3a94e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -518,8 +518,9 @@ static struct omap_hwmod_class_sysconfig omap44xx_gpio_sysc
= {
.rev_offs = 0x,
.sysc_offs = 0x0010,
.syss_offs = 0x0114,
- .sysc_flags = (SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
- SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_ENAWAKEUP |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
};
@@ -852,7 +853,7 @@ static struct omap_hwmod_class_sysconfig omap44xx_i2c_sysc
= {
.syss_offs = 0x0090,
.sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
- SYSC_HAS_SOFTRESET),
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
};
@@ -1124,7 +1125,8 @@ static struct omap_hwmod_class_sysconfig
omap44xx_uart_sysc = {
.sysc_offs = 0x0054,
.syss_offs = 0x0058,
.sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_ENAWAKEUP |
- SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
};
@@ -1354,7 +1356,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_wd_timer_sysc = {
.sysc_offs = 0x0010,
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_EMUFREE | SYSC_HAS_SIDLEMODE |
- SYSC_HAS_SOFTRESET),
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
};
--
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: hwmod data: Add IVA and DSP
Add IVA and DSP hwmods in order to allow the pm code to
initialize properly the processors devices during
omap2_init_processor_devices.
It will avoid the following warnings.
_init_omap_device: could not find omap_hwmod for iva
_init_omap_device: could not find omap_hwmod for dsp
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 243 +++-
1 files changed, 241 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7dccba3..102c76f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -37,7 +37,9 @@
/* Backward references (IPs with Bus Master capability) */
static struct omap_hwmod omap44xx_dmm_hwmod;
+static struct omap_hwmod omap44xx_dsp_hwmod;
static struct omap_hwmod omap44xx_emif_fw_hwmod;
+static struct omap_hwmod omap44xx_iva_hwmod;
static struct omap_hwmod omap44xx_l3_instr_hwmod;
static struct omap_hwmod omap44xx_l3_main_1_hwmod;
static struct omap_hwmod omap44xx_l3_main_2_hwmod;
@@ -167,6 +169,14 @@ static struct omap_hwmod_class omap44xx_l3_hwmod_class = {
};
/* l3_instr interface data */
+/* iva - l3_instr */
+static struct omap_hwmod_ocp_if omap44xx_iva__l3_instr = {
+ .master = omap44xx_iva_hwmod,
+ .slave = omap44xx_l3_instr_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l3_main_3 - l3_instr */
static struct omap_hwmod_ocp_if omap44xx_l3_main_3__l3_instr = {
.master = omap44xx_l3_main_3_hwmod,
@@ -177,6 +187,7 @@ static struct omap_hwmod_ocp_if
omap44xx_l3_main_3__l3_instr = {
/* l3_instr slave ports */
static struct omap_hwmod_ocp_if *omap44xx_l3_instr_slaves[] = {
+ omap44xx_iva__l3_instr,
omap44xx_l3_main_3__l3_instr,
};
@@ -189,6 +200,14 @@ static struct omap_hwmod omap44xx_l3_instr_hwmod = {
};
/* l3_main_1 interface data */
+/* dsp - l3_main_1 */
+static struct omap_hwmod_ocp_if omap44xx_dsp__l3_main_1 = {
+ .master = omap44xx_dsp_hwmod,
+ .slave = omap44xx_l3_main_1_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l3_main_2 - l3_main_1 */
static struct omap_hwmod_ocp_if omap44xx_l3_main_2__l3_main_1 = {
.master = omap44xx_l3_main_2_hwmod,
@@ -215,6 +234,7 @@ static struct omap_hwmod_ocp_if omap44xx_mpu__l3_main_1 = {
/* l3_main_1 slave ports */
static struct omap_hwmod_ocp_if *omap44xx_l3_main_1_slaves[] = {
+ omap44xx_dsp__l3_main_1,
omap44xx_l3_main_2__l3_main_1,
omap44xx_l4_cfg__l3_main_1,
omap44xx_mpu__l3_main_1,
@@ -229,6 +249,14 @@ static struct omap_hwmod omap44xx_l3_main_1_hwmod = {
};
/* l3_main_2 interface data */
+/* iva - l3_main_2 */
+static struct omap_hwmod_ocp_if omap44xx_iva__l3_main_2 = {
+ .master = omap44xx_iva_hwmod,
+ .slave = omap44xx_l3_main_2_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l3_main_1 - l3_main_2 */
static struct omap_hwmod_ocp_if omap44xx_l3_main_1__l3_main_2 = {
.master = omap44xx_l3_main_1_hwmod,
@@ -247,6 +275,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_cfg__l3_main_2
= {
/* l3_main_2 slave ports */
static struct omap_hwmod_ocp_if *omap44xx_l3_main_2_slaves[] = {
+ omap44xx_iva__l3_main_2,
omap44xx_l3_main_1__l3_main_2,
omap44xx_l4_cfg__l3_main_2,
};
@@ -308,6 +337,14 @@ static struct omap_hwmod_class omap44xx_l4_hwmod_class = {
};
/* l4_abe interface data */
+/* dsp - l4_abe */
+static struct omap_hwmod_ocp_if omap44xx_dsp__l4_abe = {
+ .master = omap44xx_dsp_hwmod,
+ .slave = omap44xx_l4_abe_hwmod,
+ .clk= ocp_abe_iclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l3_main_1 - l4_abe */
static struct omap_hwmod_ocp_if omap44xx_l3_main_1__l4_abe = {
.master = omap44xx_l3_main_1_hwmod,
@@ -326,6 +363,7 @@ static struct omap_hwmod_ocp_if omap44xx_mpu__l4_abe = {
/* l4_abe slave ports */
static struct omap_hwmod_ocp_if *omap44xx_l4_abe_slaves[] = {
+ omap44xx_dsp__l4_abe,
omap44xx_l3_main_1__l4_abe,
omap44xx_mpu__l4_abe,
};
@@ -456,7 +494,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
* debugss
* dma_system
* dmic
- * dsp
* dss
* dss_dispc
* dss_dsi1
@@ -476,7 +513,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
* hsi
* ipu
* iss
- * iva
* kbd
* mailbox
* mcasp
@@ -530,6 +566,91 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
*/
/*
+ * 'dsp' class
+ * dsp sub-system
+ */
+
+static struct omap_hwmod_class omap44xx_dsp_hwmod_class = {
+
[PATCH 5/5] OMAP4: hwmod clock data: Fix GPIO opt_clks and ocp_if iclk
Fix opt clocks name in clock framework and hwmod.
Add the missing iclk in the ocp_if structure.
Add the HWMOD_CONTROL_OPT_CLKS_IN_RESET flag to ensure
the the GPIO optional clock is enable during reset.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Tested-by: Charulatha V ch...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 12 ++--
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 23 +--
2 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 1599836..c59a5a9 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -2856,17 +2856,17 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, emif2_fck,emif2_fck,
CK_443X),
CLK(NULL, fdif_fck, fdif_fck,
CK_443X),
CLK(NULL, fpka_fck, fpka_fck,
CK_443X),
- CLK(NULL, gpio1_dbck, gpio1_dbclk,
CK_443X),
+ CLK(NULL, gpio1_dbclk, gpio1_dbclk,
CK_443X),
CLK(NULL, gpio1_ick,gpio1_ick,
CK_443X),
- CLK(NULL, gpio2_dbck, gpio2_dbclk,
CK_443X),
+ CLK(NULL, gpio2_dbclk, gpio2_dbclk,
CK_443X),
CLK(NULL, gpio2_ick,gpio2_ick,
CK_443X),
- CLK(NULL, gpio3_dbck, gpio3_dbclk,
CK_443X),
+ CLK(NULL, gpio3_dbclk, gpio3_dbclk,
CK_443X),
CLK(NULL, gpio3_ick,gpio3_ick,
CK_443X),
- CLK(NULL, gpio4_dbck, gpio4_dbclk,
CK_443X),
+ CLK(NULL, gpio4_dbclk, gpio4_dbclk,
CK_443X),
CLK(NULL, gpio4_ick,gpio4_ick,
CK_443X),
- CLK(NULL, gpio5_dbck, gpio5_dbclk,
CK_443X),
+ CLK(NULL, gpio5_dbclk, gpio5_dbclk,
CK_443X),
CLK(NULL, gpio5_ick,gpio5_ick,
CK_443X),
- CLK(NULL, gpio6_dbck, gpio6_dbclk,
CK_443X),
+ CLK(NULL, gpio6_dbclk, gpio6_dbclk,
CK_443X),
CLK(NULL, gpio6_ick,gpio6_ick,
CK_443X),
CLK(NULL, gpmc_ick, gpmc_ick,
CK_443X),
CLK(NULL, gpu_fck, gpu_fck,
CK_443X),
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 102c76f..0ed9cdd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -696,6 +696,7 @@ static struct omap_hwmod_addr_space omap44xx_gpio1_addrs[]
= {
static struct omap_hwmod_ocp_if omap44xx_l4_wkup__gpio1 = {
.master = omap44xx_l4_wkup_hwmod,
.slave = omap44xx_gpio1_hwmod,
+ .clk= l4_wkup_clk_mux_ck,
.addr = omap44xx_gpio1_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_gpio1_addrs),
.user = OCP_USER_MPU | OCP_USER_SDMA,
@@ -707,7 +708,7 @@ static struct omap_hwmod_ocp_if *omap44xx_gpio1_slaves[] = {
};
static struct omap_hwmod_opt_clk gpio1_opt_clks[] = {
- { .role = dbclk, .clk = sys_32k_ck },
+ { .role = dbclk, .clk = gpio1_dbclk },
};
static struct omap_hwmod omap44xx_gpio1_hwmod = {
@@ -747,6 +748,7 @@ static struct omap_hwmod_addr_space omap44xx_gpio2_addrs[]
= {
static struct omap_hwmod_ocp_if omap44xx_l4_per__gpio2 = {
.master = omap44xx_l4_per_hwmod,
.slave = omap44xx_gpio2_hwmod,
+ .clk= l4_div_ck,
.addr = omap44xx_gpio2_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_gpio2_addrs),
.user = OCP_USER_MPU | OCP_USER_SDMA,
@@ -758,12 +760,13 @@ static struct omap_hwmod_ocp_if *omap44xx_gpio2_slaves[]
= {
};
static struct omap_hwmod_opt_clk gpio2_opt_clks[] = {
- { .role = dbclk, .clk = sys_32k_ck },
+ { .role = dbclk, .clk = gpio2_dbclk },
};
static struct omap_hwmod omap44xx_gpio2_hwmod = {
.name = gpio2,
.class = omap44xx_gpio_hwmod_class,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap44xx_gpio2_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_gpio2_irqs),
.main_clk = gpio2_ick,
@@ -798,6 +801,7 @@ static struct omap_hwmod_addr_space omap44xx_gpio3_addrs[]
= {
static struct omap_hwmod_ocp_if omap44xx_l4_per__gpio3 = {
.master = omap44xx_l4_per_hwmod,
.slave = omap44xx_gpio3_hwmod,
+ .clk= l4_div_ck,
.addr = omap44xx_gpio3_addrs,
Re: [PATCH v2 1/2] I2C: i2c-omap: Change device name: i2c_omap - omap_i2c
On Thu, Dec 09, 2010 at 10:18:48PM +, aaro.koski...@nokia.com wrote: Hi, Kevin Hilman [khil...@deeprootsystems.com]: Ben Dooks ben-...@fluff.org writes: Renaming stuff like this is going to have an impact on the userspace as anyone looking through /sys's driver heirarchy is going to miss the old name... It all depends if you really want to go ahead with this... Yes, we are aware of the userspace impact, but this name change makes all devices on OMAP have consistent names and actually improves the ability to have userspace tools have consistent naming as well. So there are no imporant users, or if there is, they are prepared for this change? drivers/i2c/busses/i2c-omap.c|4 ++-- What about the .c / .ko file name? Pretty much everything in the drivers/i2c/busses directory is named i2c-something.c, and I would like to keep it that way. -- Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/ Large Hadron Colada: A large Pina Colada that makes the universe disappear. -- To unsubscribe from this list: send the line unsubscribe 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: OMAP HSMMC problems with off-mode
Paul Walmsley p...@pwsan.com writes: Hi Kevin On Thu, 9 Dec 2010, Kevin Hilman wrote: Paul, do you want to submit a formal patch for this for 2.6.38? if not, I can add a changelog and queue this with other PM core changes for 2.6.38. we should probably come up with a patch for .38 that only increments this when off-mode is entered... otherwise there will probably be a performance hit when off-mode-supporting devices are reinitialized after every clk_enable() :-) The HSMMC driver also resets the IP block when that happens. I have a series for this (will post shortly), but it only works for omap_devices, since otherwise it's rather hacky to find the powerdomain for a given device. Unfortunately, MMC is still not converted to omap_device/omap_hwmod, so my series doesn't help for MMC. :( 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 13/11] OMAP2+: GPIO: ensure bank wakeups are enabled by default
* Kevin Hilman khil...@deeprootsystems.com [101209 11:33]: As part of the GPIO conversion to platform_device/platform_driver, commit 2fae7fbed072705d91e09ed393b2e580b2d895fc (OMAP: GPIO: prepare for platform driver) removed hard-coded per-bank SYSCONFIG register values in favor of using omap_hwmod to manage the SYSCONFIG register. In the previous code, bank-level wakeups were enabled by default using the SYSCONFIG.ENAWAKEUP bit, but omap_hwmod does not enable wakeups by default. Thus the above commit effectively disabled GPIO bank wakeups. This patch enables GPIO bank level wakeups by default to preserve previous functionality. So this patch is no longer needed, right? 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
[PATCH/RFC 1/2] OMAP2+: powerdomain: add API to get context loss count
Add new powerdomain API
int pwrdm_get_context_loss_count(struct powerdomain *pwrdm)
for checking how many times the powerdomain has lost context. The
loss count is the sum sum of the powerdomain off-mode counter, the
logic off counter and the per-bank memory off counter.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/powerdomain.c | 23 +++
arch/arm/mach-omap2/powerdomain.h |1 +
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 06ef60e..78e7d22 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -909,3 +909,26 @@ int pwrdm_post_transition(void)
pwrdm_for_each(_pwrdm_post_transition_cb, NULL);
return 0;
}
+
+/**
+ * pwrdm_get_context_loss_count - get powerdomain's context loss count
+ * @pwrdm: struct powerdomain * to wait for
+ *
+ * Context loss count is a sum of powerdomain off-mode counter,
+ * the logic off counter and the per-bank memory off counter.
+ */
+int pwrdm_get_context_loss_count(struct powerdomain *pwrdm)
+{
+ int i, count;
+
+ count = pwrdm-state_counter[PWRDM_POWER_OFF];
+ count += pwrdm-ret_logic_off_counter;
+
+ for (i = 0; i pwrdm-banks; i++)
+ count += pwrdm-ret_mem_off_counter[i];
+
+ pr_debug(powerdomain: %s: context loss count = %u\n,
+pwrdm-name, count);
+
+ return count;
+}
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index 35b5b48..d269eff 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -211,6 +211,7 @@ int pwrdm_clkdm_state_switch(struct clockdomain *clkdm);
int pwrdm_pre_transition(void);
int pwrdm_post_transition(void);
int pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm);
+int pwrdm_get_context_loss_count(struct powerdomain *pwrdm);
extern void omap2xxx_powerdomains_init(void);
extern void omap3xxx_powerdomains_init(void);
--
1.7.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 2/2] OMAP: PM: implement context loss count APIs
Implement OMAP PM layer omap_pm_get_dev_context_loss_count() API by
creating similar APIs at the omap_device and omap_hwmod levels. The
omap_hwmod level call is the layer with access to the powerdomain
core, so it is the place where the powerdomain is queried to get the
context loss count.
NOTE: only works for devices which have been converted to use
omap_device/omap_hwmod.
Longer term, we could possibly remove this API from the OMAP PM layer,
and instead directly use the omap_device level API.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod.c | 18 ++
arch/arm/plat-omap/include/plat/omap_device.h |1 +
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
arch/arm/plat-omap/omap-pm-noop.c | 17 +
arch/arm/plat-omap/omap_device.c | 20
5 files changed, 49 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 81c1097..0ec9c70 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2220,3 +2220,21 @@ ohsps_unlock:
return ret;
}
+
+/**
+ * omap_hwmod_get_context_loss_count - get lost context count
+ * @oh: struct omap_hwmod *
+ *
+ * Query the powerdomain of of @oh to get the context loss
+ * count for this device.
+ */
+int omap_hwmod_get_context_loss_count(struct omap_hwmod *oh)
+{
+ struct powerdomain *pwrdm;
+
+ pwrdm = omap_hwmod_get_pwrdm(oh);
+ if (!pwrdm)
+ return -ENODEV;
+
+ return pwrdm_get_context_loss_count(pwrdm);
+}
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 28e2d1a..70d31d0 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -107,6 +107,7 @@ void __iomem *omap_device_get_rt_va(struct omap_device *od);
int omap_device_align_pm_lat(struct platform_device *pdev,
u32 new_wakeup_lat_limit);
struct powerdomain *omap_device_get_pwrdm(struct omap_device *od);
+int omap_device_get_context_loss_count(struct platform_device *pdev);
/* Other */
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 62bdb23..5a96ac5 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -568,6 +568,7 @@ int omap_hwmod_for_each_by_class(const char *classname,
void *user);
int omap_hwmod_set_postsetup_state(struct omap_hwmod *oh, u8 state);
+int omap_hwmod_get_context_loss_count(struct omap_hwmod *oh);
/*
* Chip variant-specific hwmod init routines - XXX should be converted
diff --git a/arch/arm/plat-omap/omap-pm-noop.c
b/arch/arm/plat-omap/omap-pm-noop.c
index 7578366..5a58f97 100644
--- a/arch/arm/plat-omap/omap-pm-noop.c
+++ b/arch/arm/plat-omap/omap-pm-noop.c
@@ -20,9 +20,11 @@
#include linux/init.h
#include linux/cpufreq.h
#include linux/device.h
+#include linux/platform_device.h
/* Interface documentation is in mach/omap-pm.h */
#include plat/omap-pm.h
+#include plat/omap_device.h
struct omap_opp *dsp_opps;
struct omap_opp *mpu_opps;
@@ -288,20 +290,19 @@ unsigned long omap_pm_cpu_get_freq(void)
int omap_pm_get_dev_context_loss_count(struct device *dev)
{
+ struct platform_device *pdev = to_platform_device(dev);
+ int count;
+
if (!dev) {
WARN_ON(1);
return -EINVAL;
};
- pr_debug(OMAP PM: returning context loss count for dev %s\n,
-dev_name(dev));
+ count = omap_device_get_context_loss_count(pdev);
+ pr_debug(OMAP PM: context loss count for dev %s = %d\n,
+dev_name(dev), count);
- /*
-* Map the device to the powerdomain. Return the powerdomain
-* off counter.
-*/
-
- return 0;
+ return count;
}
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index abe933c..e29c2d6 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -280,6 +280,26 @@ static void _add_optional_clock_alias(struct omap_device
*od,
/* Public functions for use by core code */
/**
+ * omap_device_get_context_loss_count - get lost context count
+ * @od: struct omap_device *
+ *
+ * Using the primary hwmod for this device, query the context loss
+ * count for this device.
+ */
+int omap_device_get_context_loss_count(struct platform_device *pdev)
+{
+ struct omap_device *od;
+ int ret = -ENODEV;
+
+ od = _find_by_pdev(pdev);
+
+ if (od-hwmods_cnt)
+ omap_hwmod_get_context_loss_count(od-hwmods[0]);
+
+ return ret;
+}
+
+/**
* omap_device_count_resources - count number of struct resource entries needed
* @od: struct
Re: [PATCH 13/11] OMAP2+: GPIO: ensure bank wakeups are enabled by default
Tony Lindgren t...@atomide.com writes: * Kevin Hilman khil...@deeprootsystems.com [101209 11:33]: As part of the GPIO conversion to platform_device/platform_driver, commit 2fae7fbed072705d91e09ed393b2e580b2d895fc (OMAP: GPIO: prepare for platform driver) removed hard-coded per-bank SYSCONFIG register values in favor of using omap_hwmod to manage the SYSCONFIG register. In the previous code, bank-level wakeups were enabled by default using the SYSCONFIG.ENAWAKEUP bit, but omap_hwmod does not enable wakeups by default. Thus the above commit effectively disabled GPIO bank wakeups. This patch enables GPIO bank level wakeups by default to preserve previous functionality. So this patch is no longer needed, right? Yup, you beat me to it. This is actually a problem in the omap_hwmod core, and I posted a separate patch[1] to fix that problem. Kevin [1] http://marc.info/?l=linux-omapm=129193625420446w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP1: SRAM: fix size for OMAP1611 SoCs
* Kevin Hilman khil...@deeprootsystems.com [101207 17:06]: Kernel was failing to boot on omap1611 based OSK boards due to mis-configured SRAM size. Existing code was using a hard-coded value for 250k, which was then rounded down by PAGE_SIZE. Increasing this to 256k allows kernel to boot on omap1611 SoCs. Problem reported by and initial fix suggested by Tim Bird. Thanks to Tony Lindgren for helping diagnose the problem to being specific to OMAP1611 and not affecting OMAP1610/OMAP1623. Thanks, will queue this fix. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/8] OMAP34: clock data: Fixes and add new clocks nodes
Hi Benoit, Benoit Cousson b-cous...@ti.com writes: Hi Paul, Here is a collections of fixes and clock nodes addition done on OMAP3 and OMAP4 clock data files. I have included the one that Thara already submitted after fixing the various comments done on the original version. That revision include as well a new fix from Jon. Thanks to both fixes, the clocks rate are now accurate and the func_48m_fclk does report 48MHz now! Cool isn't it? Tested on sdp4430 + ES2.0. The series is based on 2.6.37-rc5 and is available here: git://gitorious.org/omap-pm/linux.git for_2.6.38/clock I tried to pull this into my pm-core for testing with all the other PM stuff we have baking for 2.6.38. Unfortunately, this series has conflicts with Paul's pwrdm_prcm_[ab]_2.6.38 branches. Could you rebase this on Paul's pwrdm_prcm_b_2.6.38 branch? Kevin 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 Jon Hunter (1): OMAP4: clock data: Add missing fixed divisors Jonathan Bergsagel (1): OMAP4: clock data: Add missing fields in iva_hsd_byp_clk_mux_ck 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-omap2/clock3xxx_data.c |2 + arch/arm/mach-omap2/clock44xx_data.c | 653 -- arch/arm/mach-omap2/scrm44xx.h | 176 + 3 files changed, 640 insertions(+), 191 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
Re: [PATCH 0/5] OMAP4: hwmod data fixes and update
Benoit Cousson b-cous...@ti.com writes: Hi Paul, Here is a small set of OMAP4 hwmod data updates. Re-order properly the data that were a little bit shuffled during the previous merge window. Add the new reset flags introduced in 2.6.37 and that were not used in the hwmod data. The OMAP2 and OMAP3 fixes should come soon. Fix some missing field in the GPIO OMAP4 hwmod data that I missed during the review. IVA and DSP are added just to allow the processors device creation at boot time and avoid the warnings. Thanks to Charu for testing the GPIO / WD_TIMER changes. Thanks to Govindraj for testing the UART changes. The series is based on lo/for-next (v2.6.37-rc5-66-ga2814df) and is available here: git://gitorious.org/omap-pm/linux.git for_2.6.38/hwmod_data Please note that there is a slight dependency with the following patch due to the name change of the iva fclk: OMAP4: clock data: Add missing DPLL x2 clock node https://patchwork.kernel.org/patch/396612/ Tested on sdp4430 + ES2.0/ES2.1. As with the other series, I tried to pull this into my pm-core for testing with all the other PM stuff we have baking for 2.6.38. Unfortunately, this series has conflicts with Paul's pwrdm_prcm_[ab]_2.6.38 branches. Could you rebase this on Paul's pwrdm_prcm_b_2.6.38 branch? Kevin Regards, Benoit Benoit Cousson (5): OMAP4: hwmod data: Fix hwmod entries order OMAP4: hwmod data: Add SYSS_HAS_RESET_STATUS flag OMAP4: hwmod data: Fix missing address in DMM and EMIF_FW OMAP4: hwmod data: Add IVA and DSP OMAP4: hwmod clock data: Fix GPIO opt_clks and ocp_if iclk arch/arm/mach-omap2/clock44xx_data.c | 12 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 1256 ++-- 2 files changed, 822 insertions(+), 446 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 v3] OMAP2+: PM/serial: fix console semaphore acquire during suspend
* Kevin Hilman khil...@deeprootsystems.com [101209 07:40]:
Vitaly Wool vitalyw...@gmail.com writes:
+static void omap2_pm_end(void)
+{
+ suspend_state = PM_SUSPEND_ON;
+ return;
+}
Redundant return.
but harmless
I'll queue this fix, will leave out the harmless return.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v3 6/7] omap3: Export omap3isp platform device structure
Hi Tony, On Monday 06 December 2010 20:32:13 Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [101125 03:13]: Hi, On Thu, Nov 25, 2010 at 12:17:59PM +0100, Laurent Pinchart wrote: pass platform_data as an argument to this call ? Then remove the static inline and export this one ? Yes indeed, why ? :-) I guess things like that are difficult to spot when you've had your nose on the code for too long. Thanks for the review, I'll fix this. no problem :-) Can you please also grep to make sure there are no other EXPORT_SYMBOL being added to arch/arm/*omap*/ code in these patches? That's the only 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
