Re: [PATCH v3 00/11] usb: dwc3/xhci/phy: Enable runtime power management
On Thu, Apr 04, 2013 at 10:34:57AM +0530, Vivek Gautam wrote: Hi Sarah, On Wed, Apr 3, 2013 at 10:57 PM, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: Question: Do you still need this patch for 3.10? Felipe's 'next' is closed for 3.10, so this series won't be making it to 3.10 now, as a whole. :-( right, besides we're still discussing what to do with the whole PHY part, right ? -- balbi signature.asc Description: Digital signature
Re: [PATCH v5 1/6] drivers: phy: add generic PHY framework
Hi,
On Wed, Apr 03, 2013 at 05:54:11PM -0600, Stephen Warren wrote:
struct phy {
struct device *dev;
struct module *owner;
int (*init)(struct phy *phy);
int (*exit)(struct phy *phy);
int (*suspend)(struct phy *phy);
int (*resume)(struct phy *phy);
I wonder whether it makes sense to provide -suspend/-resume callbacks
here. We already have dev_pm_ops providing those methods and we can just
wrap pm_runtime_* calls to be called by consumers.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[...]
Can the LCD_BL_GPIO be handled by the omap panel driver? Otherwise the
backlight will supposedly be always on. Is it just a simple switch for
the BL power, which does not affect the SPI in any way?
Yes, it can for now.
Also, I think we should also take into account the backlight framework,
including PMW.
I've updated this patch to set the LCD EN gpio once at boot time, and pass the
LCD BL gpio to the panel driver. Updated patch below.
---
commit a58a72363aa4359cdb75878de1517bd50faf9eb4
Author: Tomi Valkeinen tomi.valkei...@ti.com
Date: Mon Dec 3 16:05:06 2012 +0530
arm: omap: board-cm-t35: use generic dpi panel's gpio handling
The cm-t35 board file currently requests gpios required to configure the
tdo35s
panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the generic dpi panel driver itself and
shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file.
Add the gpio information to generic dpi panel's platform data so that it's
passed to the panel driver.
Note: Only BL enable gpio is handled in the panel driver. The LCD enable
GPIO is handled in the board file at init time, as there's a 50 ms delay
required when using the GPIO, and the panel driver doesn't know about
that.
Cc: Tony Lindgren t...@atomide.com
Cc: Igor Grinberg grinb...@compulab.co.il
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Looks good, thanks!
Acked-by: Igor Grinberg grinb...@compulab.co.il
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index bccd3e5..cccbfea 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -190,32 +190,6 @@ static inline void cm_t35_init_nand(void) {}
#define CM_T35_LCD_BL_GPIO 58
#define CM_T35_DVI_EN_GPIO 54
-static int lcd_enabled;
-static int dvi_enabled;
-
-static int cm_t35_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- if (dvi_enabled) {
- printk(KERN_ERR cannot enable LCD, DVI is enabled\n);
- return -EINVAL;
- }
-
- gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
- gpio_set_value(CM_T35_LCD_BL_GPIO, 1);
-
- lcd_enabled = 1;
-
- return 0;
-}
-
-static void cm_t35_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- lcd_enabled = 0;
-
- gpio_set_value(CM_T35_LCD_BL_GPIO, 0);
- gpio_set_value(CM_T35_LCD_EN_GPIO, 0);
-}
-
static int cm_t35_panel_enable_tv(struct omap_dss_device *dssdev)
{
return 0;
@@ -227,8 +201,10 @@ static void cm_t35_panel_disable_tv(struct
omap_dss_device *dssdev)
static struct panel_generic_dpi_data lcd_panel = {
.name = toppoly_tdo35s,
- .platform_enable= cm_t35_panel_enable_lcd,
- .platform_disable = cm_t35_panel_disable_lcd,
+ .num_gpios = 1,
+ .gpios = {
+ CM_T35_LCD_BL_GPIO,
+ },
};
static struct omap_dss_device cm_t35_lcd_device = {
@@ -292,11 +268,6 @@ static struct spi_board_info cm_t35_lcd_spi_board_info[]
__initdata = {
},
};
-static struct gpio cm_t35_dss_gpios[] __initdata = {
- { CM_T35_LCD_EN_GPIO, GPIOF_OUT_INIT_LOW, lcd enable},
- { CM_T35_LCD_BL_GPIO, GPIOF_OUT_INIT_LOW, lcd bl enable },
-};
-
static void __init cm_t35_init_display(void)
{
int err;
@@ -304,23 +275,21 @@ static void __init cm_t35_init_display(void)
spi_register_board_info(cm_t35_lcd_spi_board_info,
ARRAY_SIZE(cm_t35_lcd_spi_board_info));
- err = gpio_request_array(cm_t35_dss_gpios,
- ARRAY_SIZE(cm_t35_dss_gpios));
+
+ err = gpio_request_one(CM_T35_LCD_EN_GPIO, GPIOF_OUT_INIT_LOW,
+ lcd bl enable);
if (err) {
- pr_err(CM-T35: failed to request DSS control GPIOs\n);
+ pr_err(CM-T35: failed to request LCD EN GPIO\n);
return;
}
- gpio_export(CM_T35_LCD_EN_GPIO, 0);
- gpio_export(CM_T35_LCD_BL_GPIO, 0);
-
msleep(50);
gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
err = omap_display_init(cm_t35_dss_data);
if (err) {
pr_err(CM-T35: failed to register DSS device\n);
- gpio_free_array(cm_t35_dss_gpios, ARRAY_SIZE(cm_t35_dss_gpios));
+ gpio_free(CM_T35_LCD_EN_GPIO);
}
}
- --
Regards,
Igor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRXSjtAAoJEBDE8YO64EfakqEP/RxTWET2KP1KRIs5VW6o6JXG
w4Mil7k62AmpClojEWMJTF6UfOc08Zmg4m5ZPly1mT2NAgwtwStP1hkTRuPuL34w
NMfbwro5uUf4Wp49ZxZyuLLEnlzVh8VPWPmHKc+pRl9XQOqS9fau+EBxmIXKSAgC
Re: [PATCH v3 01/11] usb: phy: Add APIs for runtime power management
Hi, On Wed, Apr 03, 2013 at 02:14:02PM -0400, Alan Stern wrote: Lets suppose DWC3 enables runtime_pm on USB 2 type phy, it will try to go into suspend state and thereby call runtime_suspend(), if any. And PHY will come to active state only when its consumer wakes it up, and this consumer is operational only when its related PHY is in fully functional state. So do we have a situation in which this PHY goes into low power state in its runtime_suspend(), resulting in non-detection of devices on further attach (since PHY is in low power state) ? Will the controller (like EHCI/OHCI) be functional now ? ehci/ohci need to cope with that by calling usb_phy_autopm_get_sync(), right ? (so does DWC3 :-) Maybe you guys have already got this all figured out -- if so, feel free to ignore this email. Some subsystems handle this issue by calling pm_runtime_get_sync() before probing a driver and pm_runtime_put_sync() after unbinding the driver. If the driver is runtime-PM-enabled, it then does its own put_sync near the end of its probe routine and get_sync in its release routine. sounds a bit 'fishy' to me... So a separate entity would call pm_runtime_get_sync(), even when we don't have registered dev_pm_ops, then drivers need to check if runtime_pm is enabled and call pm_runtime_put*() conditionally before returning from probe(). One remove, we might have another issue: device is already runtime_suspended (due to e.g. autosuspend) when module is removed, a call to pm_runtime_put_sync() will be unbalanced. No ? -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 00/11] usb: dwc3/xhci/phy: Enable runtime power management
On Thu, Apr 4, 2013 at 12:40 PM, Felipe Balbi ba...@ti.com wrote: On Thu, Apr 04, 2013 at 10:34:57AM +0530, Vivek Gautam wrote: Hi Sarah, On Wed, Apr 3, 2013 at 10:57 PM, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: Question: Do you still need this patch for 3.10? Felipe's 'next' is closed for 3.10, so this series won't be making it to 3.10 now, as a whole. :-( right, besides we're still discussing what to do with the whole PHY part, right ? Right ofcourse. :-) -- Thanks Regards Vivek -- To unsubscribe from this list: send the line unsubscribe 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 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
Hi,
On 04/04/2013 02:42 AM, Tony Lindgren wrote:
Hi,
* Roger Quadros rog...@ti.com [130319 07:31]:
Register a device tree clock provider for AUX clocks
on the OMAP4 SoC. Also provide the binding information.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/clock/omap4-clock.txt | 32 ++
arch/arm/boot/dts/omap4.dtsi |5 +++
arch/arm/mach-omap2/board-generic.c|2 +-
arch/arm/mach-omap2/cclock44xx_data.c | 35
arch/arm/mach-omap2/clock44xx.h|1 +
arch/arm/mach-omap2/common.h |9 +
arch/arm/mach-omap2/io.c |6 +++
7 files changed, 89 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/omap4-clock.txt
...
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/omap4-clock.txt
Is this really specific to omap4 and auxclk only?
Shouldn't it be just omap-clock.txt?
Yes, I've fixed this up in v2 of this patch.
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -27,6 +27,7 @@
#include linux/clk-private.h
#include linux/clkdev.h
#include linux/io.h
+#include linux/of.h
#include soc.h
#include iomap.h
@@ -1663,6 +1664,40 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, cpufreq_ck, dpll_mpu_ck, CK_443X),
};
+static struct clk *scrm_clks[] = {
+auxclk0_ck,
+auxclk1_ck,
+auxclk2_ck,
+auxclk3_ck,
+auxclk4_ck,
+auxclk5_ck,
+};
Hmm I don't like the idea of specifying the auxclk both in the
cclock44xx_data.c and in DT..
Right, but till we have all clocks moved to DT we only need this
approach for general purpose clocks that are not mapped to devices
by hwmod.
e.g. auxclk are required to be specified in DT nodes for USB PHY.
Without this we can't get USB host working on Panda.
As Rajendra points out, it seems moving entire clock data to DT is not
going to happen soon. So this is the simplistic way things can work.
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM3517 DaVinci EMAC Ethernet performance issues
On 4/4/2013 7:50 AM, CF Adad wrote: We've done network captures on our link, and the problem is very strange. The iperf client transmits data quickly and steadily for a while, but then all the sudden just stops. In the captures you can see an ACK come back from the server for the frame that was just sent, but then instead of immediately sending the next one it just sits there for sometimes several seconds. Then, it suddenly picks back up and starts running again. It's as though it just paused due to lack of data. The same kind of issue was observed in different SoC with Davinci EMAC and resolved by the patch below. Can you make sure the patch is applied in your kernel and take the performance again. https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=7e51cde276ca820d526c6c21cf8147df595a36bf Regards Mugunthan V N -- To unsubscribe from this list: send the line unsubscribe 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 v2 16/18] ARM: OMAP2+: AM33XX: Basic suspend resume support
Hi Daniel, On Wed, Apr 03, 2013 at 17:22:41, Daniel Mack wrote: Hi Vaibhav, On Mon, Dec 31, 2012 at 2:07 PM, Vaibhav Bedia vaibhav.be...@ti.com wrote: AM335x supports various low power modes as documented in section 8.1.4.3 of the AM335x TRM which is available @ http://www.ti.com/litv/pdf/spruh73f May I ask about the plans for this series? Will you be re-spinning them for a current tree, and what's the planned merge window for it? I am tied up in some other stuff right now. I plan to address Kevin's comments and repost the patches soon. Since rc5 is already out i think v3.10 is not a realistic target any more but I do hope to have this accepted for v3.11. Regards, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 01/11] usb: phy: Add APIs for runtime power management
Hi, On Thu, Apr 4, 2013 at 12:48 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Wed, Apr 03, 2013 at 02:14:02PM -0400, Alan Stern wrote: Lets suppose DWC3 enables runtime_pm on USB 2 type phy, it will try to go into suspend state and thereby call runtime_suspend(), if any. And PHY will come to active state only when its consumer wakes it up, and this consumer is operational only when its related PHY is in fully functional state. So do we have a situation in which this PHY goes into low power state in its runtime_suspend(), resulting in non-detection of devices on further attach (since PHY is in low power state) ? Will the controller (like EHCI/OHCI) be functional now ? ehci/ohci need to cope with that by calling usb_phy_autopm_get_sync(), right ? (so does DWC3 :-) Maybe you guys have already got this all figured out -- if so, feel free to ignore this email. Some subsystems handle this issue by calling pm_runtime_get_sync() before probing a driver and pm_runtime_put_sync() after unbinding the driver. If the driver is runtime-PM-enabled, it then does its own put_sync near the end of its probe routine and get_sync in its release routine. sounds a bit 'fishy' to me... So a separate entity would call pm_runtime_get_sync(), even when we don't have registered dev_pm_ops, then drivers need to check if runtime_pm is enabled and call pm_runtime_put*() conditionally before returning from probe(). One remove, we might have another issue: device is already runtime_suspended (due to e.g. autosuspend) when module is removed, a call to pm_runtime_put_sync() will be unbalanced. No ? May be i am misinterpreting !! If PHYs are runtime-PM enabled (PHY probe calls *runtime_enable*), then the consumers need to call pm_runtime_get_sync whever they want to access PHY. Besides PHYs also need to *put_sync* just before their probe is finishing, so that it's availbale for autosuspend. I, however didn't understand the need of PHY to *get_sync* itself in release routine. -- Thanks Regards Vivek -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/6] drivers: phy: add generic PHY framework
Hi, On Wednesday 03 April 2013 09:17 PM, Felipe Balbi wrote: Hi, On Wed, Apr 03, 2013 at 08:02:52PM +0530, Kishon Vijay Abraham I wrote: + ret = -EINVAL; + goto err0; + } + + if (!phy_class) + phy_core_init(); why don't you setup the class on module_init ? Then this would be a terrible error condition here :-) This is for the case where the PHY driver gets loaded before the PHY framework. I could have returned EPROBE_DEFER here instead I thought will have it this way. looks a bit weird IMO. Is it really possible for PHY to load before ? yeah. it actually happened when I tried with beagle and had all the modules as built-in. Because twl4030 has subsys_initcall(), it loads before PHY framework. that's a bug in twl4030. right. Will fix it. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/6] drivers: phy: add generic PHY framework
Hi, On Thursday 04 April 2013 03:16 AM, Sylwester Nawrocki wrote: On 04/03/2013 02:53 PM, Kishon Vijay Abraham I wrote: . . snip . . diff --git a/Documentation/phy.txt b/Documentation/phy.txt new file mode 100644 index 000..7785ec0 --- /dev/null +++ b/Documentation/phy.txt @@ -0,0 +1,113 @@ +PHY SUBSYSTEM + Kishon Vijay Abraham Ikis...@ti.com + +This document explains the Generic PHY Framework along with the APIs provided, +and how-to-use. + +1. Introduction + +*PHY* is the abbreviation for physical layer. It is used to connect a device +to the physical medium e.g., the USB controller has a PHY to provide functions Shouldn't it be ...medium, e.g. the USB... ? +such as serialization, de-serialization, encoding, decoding and is responsible +for obtaining the required data transmission rate. Note that some USB +controller has PHY functionality embedded into it and others use an external controllers have PHY functionality embedded into them ? +PHY. Other peripherals that uses a PHY include Wireless LAN, Ethernet, s/uses/use ? +SATA etc. + +The intention of creating this framework is to bring the phy drivers spread +all over the Linux kernel to drivers/phy to increase code re-use and to +increase code maintainability. + +This framework will be of use only to devices that uses external PHY (PHY s/uses/use ? +functionality is not embedded within the controller). + +2. Creating the PHY + +The PHY driver should create the PHY in order for other peripheral controllers +to make use of it. The PHY framework provides 2 APIs to create the PHY. + +struct phy *phy_create(struct device *dev, const char *label, +struct device_node *of_node, int type, struct phy_ops *ops, +void *priv); +struct phy *devm_phy_create(struct device *dev, const char *label, +struct device_node *of_node, int type, struct phy_ops *ops, +void *priv); + +The PHY drivers can use one of the above 2 APIs to create the PHY by passing +the device pointer, label, device node, type, phy ops and a driver data. +phy_ops is a set of function pointers for performing PHY operations such as +init, exit, suspend, resume, power_on and power_off. + +3. Binding the PHY to the controller + +The framework provides an API for binding the controller to the PHY in the +case of non dt boot. + +struct phy_bind *phy_bind(const char *dev_name, int index, +const char *phy_dev_name); + +The API fills the phy_bind structure with the dev_name (device name of the +controller), index and phy_dev_name (device name of the PHY). This will +be used when the controller requests this phy. This API should be used by +platform specific initialization code (board file). + +In the case of dt boot, the binding information should be added in the dt +data of the controller. s/in the dt data of/in the device tree node of ? +4. Getting a reference to the PHY + +Before the controller can make use of the PHY, it has to get a reference to +it. This framework provides 6 APIs to get a reference to the PHY. + +struct phy *phy_get(struct device *dev, int index); +struct phy *devm_phy_get(struct device *dev, int index); +struct phy *of_phy_get(struct device *dev, const char *phandle, int index); +struct phy *devm_of_phy_get(struct device *dev, const char *phandle, int index); Why do we need separate functions for dt and non-dt ? Couldn't it be handled internally by the framework ? So the PHY users can use same calls for dt and non-dt, like in case of e.g. the regulators API ? yeah. Indeed it makes sense to do it that way. Also signatures of some functions are different now: extern struct phy *phy_get(struct device *dev, int index); extern struct phy *devm_phy_get(struct device *dev, int index); extern struct phy *of_phy_get(struct device *dev, int index); extern struct phy *devm_of_phy_get(struct device *dev, int index); My bad :-( BTW, I think extern could be dropped, does it have any significance in function declarations in header files ? it shouldn't have any effect I guess. It's harmless nevertheless. +struct phy *of_phy_get_byname(struct device *dev, const char *string); +struct phy *devm_of_phy_get_byname(struct device *dev, const char *string); + +phy_get and devm_phy_get can be used to get the PHY in non-dt boot. This API +uses the binding information added using the phy_bind API to find and return +the appropriate PHY. The only difference between the two APIs is that +devm_phy_get associates the device with the PHY using devres on successful PHY +get. On driver detach, release function is invoked on the the devres data and s/the the/the +devres data is freed. + +of_phy_get and devm_of_phy_get can be used to get the PHY in dt boot. These +APIs take the phandle and index to get a reference to the PHY. The only +difference between the two APIs is that devm_of_phy_get associates the device +with the PHY using devres on successful phy get. On driver detach, release +function is invoked on the
Re: [PATCH v3 01/11] usb: phy: Add APIs for runtime power management
Hi, On Thu, Apr 04, 2013 at 02:26:51PM +0530, Vivek Gautam wrote: Lets suppose DWC3 enables runtime_pm on USB 2 type phy, it will try to go into suspend state and thereby call runtime_suspend(), if any. And PHY will come to active state only when its consumer wakes it up, and this consumer is operational only when its related PHY is in fully functional state. So do we have a situation in which this PHY goes into low power state in its runtime_suspend(), resulting in non-detection of devices on further attach (since PHY is in low power state) ? Will the controller (like EHCI/OHCI) be functional now ? ehci/ohci need to cope with that by calling usb_phy_autopm_get_sync(), right ? (so does DWC3 :-) Maybe you guys have already got this all figured out -- if so, feel free to ignore this email. Some subsystems handle this issue by calling pm_runtime_get_sync() before probing a driver and pm_runtime_put_sync() after unbinding the driver. If the driver is runtime-PM-enabled, it then does its own put_sync near the end of its probe routine and get_sync in its release routine. sounds a bit 'fishy' to me... So a separate entity would call pm_runtime_get_sync(), even when we don't have registered dev_pm_ops, then drivers need to check if runtime_pm is enabled and call pm_runtime_put*() conditionally before returning from probe(). One remove, we might have another issue: device is already runtime_suspended (due to e.g. autosuspend) when module is removed, a call to pm_runtime_put_sync() will be unbalanced. No ? May be i am misinterpreting !! If PHYs are runtime-PM enabled (PHY probe calls *runtime_enable*), then the consumers need to call pm_runtime_get_sync whever they want to access PHY. Alright, so here's my understanding: I suggested letting e.g. DWC3 enable the PHY's runtime_pm; Alan said that it could be done before that so that DWC3 sees an enabled PHY during probe. -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/2] mfd: twl4030-madc: Add support for raw value in twl4030_madc_conversion
On Sunday 24 March 2013 15:03:29 Pali Rohár wrote: On Saturday 02 March 2013 23:23:05 Pali Rohár wrote: On Friday 15 February 2013 23:56:49 Pali Rohár wrote: Driver twl4030-madc has hardcoded channel types (10 - battery current, 1 - battery temperature) and also conversation data in variable twl4030_divider_ratios. These hardcoded channels are incorrect for Nokia RX-51 board (where is channel 0 - battery temperature). For Nokia RX-51 there is rx51_battery power_supply driver which reporting battery information via twl4030_madc_conversion. But this driver needs raw values (not converted via some hardcoded functions). So this patch adding new parameter raw to struct twl4030_madc_request which tell twl4030-madc driver to not convert values, but rather return raw. Signed-off-by: Pali Rohár pali.ro...@gmail.com --- drivers/mfd/twl4030-madc.c | 14 ++ include/linux/i2c/twl4030-madc.h |2 ++ 2 files changed, 12 insertions(+), 4 deletions(-) Hello, can somebody review this twl4030-madc patch? Bump. Can some of mfd maintainers look at this patch and include it to mfd tree? It is needed for rx51_battery power supply driver. CCing Tony, can you look at this patch? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
[PATCH v2 00/12] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
Pual, Here is the series which updates the minor updates you suggested. As aligned on list with Tony, I have dropped clock data from the series. That means for the boot, one clock data patch needs to be applied. It is available on my git tree in 'out_of_tree/omap5_clk_data' branch. Alsot, you will notice hwmod data loc has come down from ~6000 lines to ~2000 lines because of removal of iospace, irq, dma data as well as unused hwmods. Few hwmods for which dt conversion is pending are not added as well but those would add max ~400 loc in future. Series has been tested boot on OMAP4 and OMAP5 devices and compile tested for all the OMAP2/3/4/5 specific configs. For OMAP5 testing, I have to pull in Tony's arm-soc pull requests, benoit's dt branch and hence ended up creating a 'testing/3.10/omap5_int_rebuild' branch. The following changes since commit a937536b868b8369b98967929045f1df54234323: Linux 3.9-rc3 (2013-03-17 15:59:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap5_data_files_v2 for you to fetch changes up to f97c560324a0e3c0607d57089930493db6ad7435: ARM: OMAP5: Enable build and frameowrk initialisations (2013-04-04 14:00:52 +0530) Benoit Cousson (7): ARM: OMAP5: PRM: Add OMAP54XX register and bitfield files ARM: OMAP5: CM: Add OMAP54XX register and bitfield files ARM: OMAP5: PRCM: Add OMAP54XX local MPU PRCM registers ARM: OMAP5: SCRM: Add OMAP54XX header file. ARM: OMAP5: clockdomain data: Add OMAP54XX data and update the header ARM: OMAP5: powerdomain data: Add OMAP54XX data and update the header ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data Santosh Shilimkar (5): ARM: OMAP4+: PRM: Move function prototypes to common header for re-use ARM: OMAP4+: CM: Move function prototypes to common header for re-use ARM: OMAP4+: PRCM MPU: Move function prototypes to common header for re-use ARM: OMAP5: voltagedomain data: Add OMAP5 voltage domain data ARM: OMAP5: Enable build and frameowrk initialisations arch/arm/mach-omap2/Makefile |4 + arch/arm/mach-omap2/clockdomain.h |1 + arch/arm/mach-omap2/clockdomains54xx_data.c | 464 + arch/arm/mach-omap2/cm-regbits-54xx.h | 1737 arch/arm/mach-omap2/cm1_44xx.h|7 +- arch/arm/mach-omap2/cm1_54xx.h| 218 ++ arch/arm/mach-omap2/cm2_44xx.h|7 +- arch/arm/mach-omap2/cm2_54xx.h| 394 arch/arm/mach-omap2/cm_44xx_54xx.h| 36 + arch/arm/mach-omap2/io.c |7 + arch/arm/mach-omap2/omap_hwmod.h |1 + arch/arm/mach-omap2/omap_hwmod_54xx_data.c| 2151 arch/arm/mach-omap2/powerdomain.h |1 + arch/arm/mach-omap2/powerdomains54xx_data.c | 331 +++ arch/arm/mach-omap2/prcm44xx.h|6 + arch/arm/mach-omap2/prcm_mpu44xx.h| 14 +- arch/arm/mach-omap2/prcm_mpu54xx.h| 87 + arch/arm/mach-omap2/prcm_mpu_44xx_54xx.h | 36 + arch/arm/mach-omap2/prm-regbits-54xx.h| 2701 + arch/arm/mach-omap2/prm44xx.h | 33 +- arch/arm/mach-omap2/prm44xx_54xx.h| 58 + arch/arm/mach-omap2/prm54xx.h | 421 arch/arm/mach-omap2/scrm54xx.h| 231 +++ arch/arm/mach-omap2/voltage.h |1 + arch/arm/mach-omap2/voltagedomains54xx_data.c | 102 + 25 files changed, 8994 insertions(+), 55 deletions(-) create mode 100644 arch/arm/mach-omap2/clockdomains54xx_data.c create mode 100644 arch/arm/mach-omap2/cm-regbits-54xx.h create mode 100644 arch/arm/mach-omap2/cm1_54xx.h create mode 100644 arch/arm/mach-omap2/cm2_54xx.h create mode 100644 arch/arm/mach-omap2/cm_44xx_54xx.h create mode 100644 arch/arm/mach-omap2/omap_hwmod_54xx_data.c create mode 100644 arch/arm/mach-omap2/powerdomains54xx_data.c create mode 100644 arch/arm/mach-omap2/prcm_mpu54xx.h create mode 100644 arch/arm/mach-omap2/prcm_mpu_44xx_54xx.h create mode 100644 arch/arm/mach-omap2/prm-regbits-54xx.h create mode 100644 arch/arm/mach-omap2/prm44xx_54xx.h create mode 100644 arch/arm/mach-omap2/prm54xx.h create mode 100644 arch/arm/mach-omap2/scrm54xx.h create mode 100644 arch/arm/mach-omap2/voltagedomains54xx_data.c -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 01/12] ARM: OMAP4+: PRM: Move function prototypes to common header for re-use
OMAP5 reuses OMAP4 PRM IP block which lets us re-use PRM functions. So move the function prototypes from prm44xx.h to prm44xx_54xx.h header. The suggestion came from Paul Walmsley as part of the OMAP5 data file review. This is preparatory patch to add OMAP5 PRM data file. Cc: Paul Walmsley p...@pwsan.com Acked-by: Rajendra Nayak rna...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/prm44xx.h | 33 +--- arch/arm/mach-omap2/prm44xx_54xx.h | 58 2 files changed, 59 insertions(+), 32 deletions(-) create mode 100644 arch/arm/mach-omap2/prm44xx_54xx.h diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h index 8ee1fbd..7db2422 100644 --- a/arch/arm/mach-omap2/prm44xx.h +++ b/arch/arm/mach-omap2/prm44xx.h @@ -25,6 +25,7 @@ #ifndef __ARCH_ARM_MACH_OMAP2_PRM44XX_H #define __ARCH_ARM_MACH_OMAP2_PRM44XX_H +#include prm44xx_54xx.h #include prcm-common.h #include prm.h @@ -744,36 +745,4 @@ #define OMAP4_PRM_VC_ERRST_OFFSET 0x00f8 #define OMAP4430_PRM_VC_ERRST OMAP44XX_PRM_REGADDR(OMAP4430_PRM_DEVICE_INST, 0x00f8) -/* Function prototypes */ -# ifndef __ASSEMBLER__ - -extern u32 omap4_prm_read_inst_reg(s16 inst, u16 idx); -extern void omap4_prm_write_inst_reg(u32 val, s16 inst, u16 idx); -extern u32 omap4_prm_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx); - -/* OMAP4-specific VP functions */ -u32 omap4_prm_vp_check_txdone(u8 vp_id); -void omap4_prm_vp_clear_txdone(u8 vp_id); - -/* - * OMAP4 access functions for voltage controller (VC) and - * voltage proccessor (VP) in the PRM. - */ -extern u32 omap4_prm_vcvp_read(u8 offset); -extern void omap4_prm_vcvp_write(u32 val, u8 offset); -extern u32 omap4_prm_vcvp_rmw(u32 mask, u32 bits, u8 offset); - -extern void omap44xx_prm_reconfigure_io_chain(void); - -/* PRM interrupt-related functions */ -extern void omap44xx_prm_read_pending_irqs(unsigned long *events); -extern void omap44xx_prm_ocp_barrier(void); -extern void omap44xx_prm_save_and_clear_irqen(u32 *saved_mask); -extern void omap44xx_prm_restore_irqen(u32 *saved_mask); - -extern int __init omap44xx_prm_init(void); -extern u32 omap44xx_prm_get_reset_sources(void); - -# endif - #endif diff --git a/arch/arm/mach-omap2/prm44xx_54xx.h b/arch/arm/mach-omap2/prm44xx_54xx.h new file mode 100644 index 000..7cd22ab --- /dev/null +++ b/arch/arm/mach-omap2/prm44xx_54xx.h @@ -0,0 +1,58 @@ +/* + * OMAP44xx and 54xx PRM common functions + * + * Copyright (C) 2009-2013 Texas Instruments, Inc. + * Copyright (C) 2009-2010 Nokia Corporation + * + * Paul Walmsley (p...@pwsan.com) + * Rajendra Nayak (rna...@ti.com) + * 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_PRM44XX_54XX_H +#define __ARCH_ARM_MACH_OMAP2_PRM44XX_54XX_H + +/* Function prototypes */ +#ifndef __ASSEMBLER__ + +extern u32 omap4_prm_read_inst_reg(s16 inst, u16 idx); +extern void omap4_prm_write_inst_reg(u32 val, s16 inst, u16 idx); +extern u32 omap4_prm_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx); + +/* OMAP4/OMAP5-specific VP functions */ +u32 omap4_prm_vp_check_txdone(u8 vp_id); +void omap4_prm_vp_clear_txdone(u8 vp_id); + +/* + * OMAP4/OMAP5 access functions for voltage controller (VC) and + * voltage proccessor (VP) in the PRM. + */ +extern u32 omap4_prm_vcvp_read(u8 offset); +extern void omap4_prm_vcvp_write(u32 val, u8 offset); +extern u32 omap4_prm_vcvp_rmw(u32 mask, u32 bits, u8 offset); + +extern void omap44xx_prm_reconfigure_io_chain(void); + +/* PRM interrupt-related functions */ +extern void omap44xx_prm_read_pending_irqs(unsigned long *events); +extern void omap44xx_prm_ocp_barrier(void); +extern void omap44xx_prm_save_and_clear_irqen(u32 *saved_mask); +extern void omap44xx_prm_restore_irqen(u32 *saved_mask); + +extern int __init omap44xx_prm_init(void); +extern u32 omap44xx_prm_get_reset_sources(void); + +#endif + +#endif -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 03/12] ARM: OMAP4+: CM: Move function prototypes to common header for re-use
OMAP5 reuses OMAP4 CM IP block which lets us re-use CM1/CM2 functions. So move the function prototypes from cm1_44xx.h, cm2_44xx.h to cm_prm44xx_54xx.h header. The suggestion came from Paul Walmsley as part of the OMAP5 data file review. This is preparatory patch to add OMAP5 CM data file. Cc: Paul Walmsley p...@pwsan.com Acked-by: Rajendra Nayak rna...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/cm1_44xx.h |7 ++- arch/arm/mach-omap2/cm2_44xx.h |7 ++- arch/arm/mach-omap2/cm_44xx_54xx.h | 36 3 files changed, 40 insertions(+), 10 deletions(-) create mode 100644 arch/arm/mach-omap2/cm_44xx_54xx.h diff --git a/arch/arm/mach-omap2/cm1_44xx.h b/arch/arm/mach-omap2/cm1_44xx.h index 1bc00dc..5ae8fe3 100644 --- a/arch/arm/mach-omap2/cm1_44xx.h +++ b/arch/arm/mach-omap2/cm1_44xx.h @@ -25,6 +25,8 @@ #ifndef __ARCH_ARM_MACH_OMAP2_CM1_44XX_H #define __ARCH_ARM_MACH_OMAP2_CM1_44XX_H +#include cm_44xx_54xx.h + /* CM1 base address */ #define OMAP4430_CM1_BASE 0x4a004000 @@ -217,9 +219,4 @@ #define OMAP4_CM1_ABE_WDT3_CLKCTRL_OFFSET 0x0088 #define OMAP4430_CM1_ABE_WDT3_CLKCTRL OMAP44XX_CM1_REGADDR(OMAP4430_CM1_ABE_INST, 0x0088) -/* Function prototypes */ -extern u32 omap4_cm1_read_inst_reg(s16 inst, u16 idx); -extern void omap4_cm1_write_inst_reg(u32 val, s16 inst, u16 idx); -extern u32 omap4_cm1_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx); - #endif diff --git a/arch/arm/mach-omap2/cm2_44xx.h b/arch/arm/mach-omap2/cm2_44xx.h index b9de72d..ee5136d 100644 --- a/arch/arm/mach-omap2/cm2_44xx.h +++ b/arch/arm/mach-omap2/cm2_44xx.h @@ -25,6 +25,8 @@ #ifndef __ARCH_ARM_MACH_OMAP2_CM2_44XX_H #define __ARCH_ARM_MACH_OMAP2_CM2_44XX_H +#include cm_44xx_54xx.h + /* CM2 base address */ #define OMAP4430_CM2_BASE 0x4a008000 @@ -449,9 +451,4 @@ #define OMAP4_CM_CEFUSE_CEFUSE_CLKCTRL_OFFSET 0x0020 #define OMAP4430_CM_CEFUSE_CEFUSE_CLKCTRL OMAP44XX_CM2_REGADDR(OMAP4430_CM2_CEFUSE_INST, 0x0020) -/* Function prototypes */ -extern u32 omap4_cm2_read_inst_reg(s16 inst, u16 idx); -extern void omap4_cm2_write_inst_reg(u32 val, s16 inst, u16 idx); -extern u32 omap4_cm2_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx); - #endif diff --git a/arch/arm/mach-omap2/cm_44xx_54xx.h b/arch/arm/mach-omap2/cm_44xx_54xx.h new file mode 100644 index 000..4154f86 --- /dev/null +++ b/arch/arm/mach-omap2/cm_44xx_54xx.h @@ -0,0 +1,36 @@ +/* + * OMAP44xx and OMAP54xx CM1/CM2 function prototypes + * + * Copyright (C) 2009-201333 Texas Instruments, Inc. + * Copyright (C) 2009-2010 Nokia Corporation + * + * Paul Walmsley (p...@pwsan.com) + * Rajendra Nayak (rna...@ti.com) + * 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_CM_44XX_54XX_H +#define __ARCH_ARM_MACH_OMAP2_CM_44XX_55XX_H + +/* CM1 Function prototypes */ +extern u32 omap4_cm1_read_inst_reg(s16 inst, u16 idx); +extern void omap4_cm1_write_inst_reg(u32 val, s16 inst, u16 idx); +extern u32 omap4_cm1_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx); + +/* CM2 Function prototypes */ +extern u32 omap4_cm2_read_inst_reg(s16 inst, u16 idx); +extern void omap4_cm2_write_inst_reg(u32 val, s16 inst, u16 idx); +extern u32 omap4_cm2_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx); + +#endif -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 05/12] ARM: OMAP4+: PRCM MPU: Move function prototypes to common header for re-use
OMAP5 reuses OMAP4 MPU PRCM IP block which lets us re-use functions. So move the function prototypes from prcm_mpu44xx.h to prcm_mpu_44xx_54xx.h header. The suggestion came from Paul Walmsley as part of the OMAP5 data file review. This is preparatory patch to add OMAP5 MPU PRCM data file. Cc: Paul Walmsley p...@pwsan.com Acked-by: Rajendra Nayak rna...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/prcm_mpu44xx.h | 14 +--- arch/arm/mach-omap2/prcm_mpu_44xx_54xx.h | 36 ++ 2 files changed, 37 insertions(+), 13 deletions(-) create mode 100644 arch/arm/mach-omap2/prcm_mpu_44xx_54xx.h diff --git a/arch/arm/mach-omap2/prcm_mpu44xx.h b/arch/arm/mach-omap2/prcm_mpu44xx.h index 884af7b..059bd4f 100644 --- a/arch/arm/mach-omap2/prcm_mpu44xx.h +++ b/arch/arm/mach-omap2/prcm_mpu44xx.h @@ -25,12 +25,9 @@ #ifndef __ARCH_ARM_MACH_OMAP2_PRCM_MPU44XX_H #define __ARCH_ARM_MACH_OMAP2_PRCM_MPU44XX_H +#include prcm_mpu_44xx_54xx.h #include common.h -# ifndef __ASSEMBLER__ -extern void __iomem *prcm_mpu_base; -# endif - #define OMAP4430_PRCM_MPU_BASE 0x48243000 #define OMAP44XX_PRCM_MPU_REGADDR(inst, reg) \ @@ -98,13 +95,4 @@ extern void __iomem *prcm_mpu_base; #define OMAP4_CM_CPU1_CLKSTCTRL_OFFSET 0x0018 #define OMAP4430_CM_CPU1_CLKSTCTRL OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU1_INST, 0x0018) -/* Function prototypes */ -# ifndef __ASSEMBLER__ -extern u32 omap4_prcm_mpu_read_inst_reg(s16 inst, u16 idx); -extern void omap4_prcm_mpu_write_inst_reg(u32 val, s16 inst, u16 idx); -extern u32 omap4_prcm_mpu_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst, - s16 idx); -extern void __init omap2_set_globals_prcm_mpu(void __iomem *prcm_mpu); -# endif - #endif diff --git a/arch/arm/mach-omap2/prcm_mpu_44xx_54xx.h b/arch/arm/mach-omap2/prcm_mpu_44xx_54xx.h new file mode 100644 index 000..ca149e7 --- /dev/null +++ b/arch/arm/mach-omap2/prcm_mpu_44xx_54xx.h @@ -0,0 +1,36 @@ +/* + * OMAP44xx and OMAP54xx PRCM MPU function prototypes + * + * Copyright (C) 2010, 2013 Texas Instruments, Inc. + * Copyright (C) 2010 Nokia Corporation + * + * Paul Walmsley (p...@pwsan.com) + * Rajendra Nayak (rna...@ti.com) + * 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_PRCM_MPU_44XX_54XX_H +#define __ARCH_ARM_MACH_OMAP2_PRCM_MPU_44XX_54XX_H + +#ifndef __ASSEMBLER__ +extern void __iomem *prcm_mpu_base; + +extern u32 omap4_prcm_mpu_read_inst_reg(s16 inst, u16 idx); +extern void omap4_prcm_mpu_write_inst_reg(u32 val, s16 inst, u16 idx); +extern u32 omap4_prcm_mpu_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst, + s16 idx); +extern void __init omap2_set_globals_prcm_mpu(void __iomem *prcm_mpu); +#endif + +#endif -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 06/12] ARM: OMAP5: PRCM: Add OMAP54XX local MPU PRCM registers
From: Benoit Cousson b-cous...@ti.com Add the PRCM MPU registers for OMAP54XX platforms. Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Benoit Cousson b-cous...@ti.com [santosh.shilim...@ti.com: Generated es2.0 data] Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/prcm44xx.h |6 +++ arch/arm/mach-omap2/prcm_mpu54xx.h | 87 2 files changed, 93 insertions(+) create mode 100644 arch/arm/mach-omap2/prcm_mpu54xx.h diff --git a/arch/arm/mach-omap2/prcm44xx.h b/arch/arm/mach-omap2/prcm44xx.h index 7334ffb..f429cdd 100644 --- a/arch/arm/mach-omap2/prcm44xx.h +++ b/arch/arm/mach-omap2/prcm44xx.h @@ -32,6 +32,12 @@ #define OMAP4430_SCRM_PARTITION4 #define OMAP4430_PRCM_MPU_PARTITION5 +#define OMAP54XX_PRM_PARTITION 1 +#define OMAP54XX_CM_CORE_AON_PARTITION 2 +#define OMAP54XX_CM_CORE_PARTITION 3 +#define OMAP54XX_SCRM_PARTITION4 +#define OMAP54XX_PRCM_MPU_PARTITION5 + /* * OMAP4_MAX_PRCM_PARTITIONS: set to the highest value of the PRCM partition * IDs, plus one diff --git a/arch/arm/mach-omap2/prcm_mpu54xx.h b/arch/arm/mach-omap2/prcm_mpu54xx.h new file mode 100644 index 000..bc2ce32 --- /dev/null +++ b/arch/arm/mach-omap2/prcm_mpu54xx.h @@ -0,0 +1,87 @@ +/* + * OMAP54xx PRCM MPU instance offset macros + * + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com + * + * Paul Walmsley (p...@pwsan.com) + * Rajendra Nayak (rna...@ti.com) + * 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_PRCM_MPU54XX_H +#define __ARCH_ARM_MACH_OMAP2_PRCM_MPU54XX_H + +#include prcm_mpu_44xx_54xx.h +#include common.h + +#define OMAP54XX_PRCM_MPU_BASE 0x48243000 + +#define OMAP54XX_PRCM_MPU_REGADDR(inst, reg) \ + OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE + (inst) + (reg)) + +/* PRCM_MPU instances */ +#define OMAP54XX_PRCM_MPU_OCP_SOCKET_INST 0x +#define OMAP54XX_PRCM_MPU_DEVICE_INST 0x0200 +#define OMAP54XX_PRCM_MPU_PRM_C0_INST 0x0400 +#define OMAP54XX_PRCM_MPU_CM_C0_INST 0x0600 +#define OMAP54XX_PRCM_MPU_PRM_C1_INST 0x0800 +#define OMAP54XX_PRCM_MPU_CM_C1_INST 0x0a00 + +/* PRCM_MPU clockdomain register offsets (from instance start) */ +#define OMAP54XX_PRCM_MPU_CM_C0_CPU0_CDOFFS0x +#define OMAP54XX_PRCM_MPU_CM_C1_CPU1_CDOFFS0x + + +/* + * PRCM_MPU + * + * The PRCM_MPU is a local PRCM inside the MPU subsystem. For the PRCM (global) + * point of view the PRCM_MPU is a single entity. It shares the same + * programming model as the global PRCM and thus can be assimilate as two new + * MOD inside the PRCM + */ + +/* PRCM_MPU.PRCM_MPU_OCP_SOCKET register offsets */ +#define OMAP54XX_REVISION_PRCM_MPU_OFFSET 0x + +/* PRCM_MPU.PRCM_MPU_DEVICE register offsets */ +#define OMAP54XX_PRCM_MPU_PRM_RSTST_OFFSET 0x +#define OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET 0x0004 +#define OMAP54XX_PRM_FRAC_INCREMENTER_NUMERATOR_OFFSET 0x0010 +#define OMAP54XX_PRM_FRAC_INCREMENTER_DENUMERATOR_RELOAD_OFFSET0x0014 + +/* PRCM_MPU.PRCM_MPU_PRM_C0 register offsets */ +#define OMAP54XX_PM_CPU0_PWRSTCTRL_OFFSET 0x +#define OMAP54XX_PM_CPU0_PWRSTST_OFFSET0x0004 +#define OMAP54XX_RM_CPU0_CPU0_RSTCTRL_OFFSET 0x0010 +#define OMAP54XX_RM_CPU0_CPU0_RSTST_OFFSET 0x0014 +#define OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET 0x0024 + +/* PRCM_MPU.PRCM_MPU_CM_C0 register offsets */ +#define OMAP54XX_CM_CPU0_CLKSTCTRL_OFFSET 0x +#define OMAP54XX_CM_CPU0_CPU0_CLKCTRL_OFFSET 0x0020 +#define OMAP54XX_CM_CPU0_CPU0_CLKCTRL OMAP54XX_PRCM_MPU_REGADDR(OMAP54XX_PRCM_MPU_CM_C0_INST, 0x0020) + +/* PRCM_MPU.PRCM_MPU_PRM_C1 register offsets */ +#define OMAP54XX_PM_CPU1_PWRSTCTRL_OFFSET 0x +#define OMAP54XX_PM_CPU1_PWRSTST_OFFSET0x0004 +#define OMAP54XX_RM_CPU1_CPU1_RSTCTRL_OFFSET 0x0010 +#define OMAP54XX_RM_CPU1_CPU1_RSTST_OFFSET 0x0014 +#define OMAP54XX_RM_CPU1_CPU1_CONTEXT_OFFSET 0x0024 + +/* PRCM_MPU.PRCM_MPU_CM_C1 register offsets */ +#define
[PATCH v2 07/12] ARM: OMAP5: SCRM: Add OMAP54XX header file.
From: Benoit Cousson b-cous...@ti.com Adding the OMAP5 specific header for SCRM module. Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Benoit Cousson b-cous...@ti.com [santosh.shilim...@ti.com: Generated es2.0 data] Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/scrm54xx.h | 231 1 file changed, 231 insertions(+) create mode 100644 arch/arm/mach-omap2/scrm54xx.h diff --git a/arch/arm/mach-omap2/scrm54xx.h b/arch/arm/mach-omap2/scrm54xx.h new file mode 100644 index 000..57e86c8 --- /dev/null +++ b/arch/arm/mach-omap2/scrm54xx.h @@ -0,0 +1,231 @@ +/* + * OMAP54XX SCRM registers and bitfields + * + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com + * + * 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_54XX_H +#define __ARCH_ARM_MACH_OMAP2_SCRM_54XX_H + +#define OMAP5_SCRM_BASE0x4ae0a000 + +#define OMAP54XX_SCRM_REGADDR(reg) \ + OMAP2_L4_IO_ADDRESS(OMAP5_SCRM_BASE + (reg)) + +/* SCRM */ + +/* SCRM.SCRM register offsets */ +#define OMAP5_SCRM_REVISION_SCRM_OFFSET0x +#define OMAP5_SCRM_REVISION_SCRM OMAP54XX_SCRM_REGADDR(0x) +#define OMAP5_SCRM_CLKSETUPTIME_OFFSET 0x0100 +#define OMAP5_SCRM_CLKSETUPTIME OMAP54XX_SCRM_REGADDR(0x0100) +#define OMAP5_SCRM_PMICSETUPTIME_OFFSET0x0104 +#define OMAP5_SCRM_PMICSETUPTIME OMAP54XX_SCRM_REGADDR(0x0104) +#define OMAP5_SCRM_ALTCLKSRC_OFFSET0x0110 +#define OMAP5_SCRM_ALTCLKSRC OMAP54XX_SCRM_REGADDR(0x0110) +#define OMAP5_SCRM_MODEMCLKM_OFFSET0x0118 +#define OMAP5_SCRM_MODEMCLKM OMAP54XX_SCRM_REGADDR(0x0118) +#define OMAP5_SCRM_D2DCLKM_OFFSET 0x011c +#define OMAP5_SCRM_D2DCLKM OMAP54XX_SCRM_REGADDR(0x011c) +#define OMAP5_SCRM_EXTCLKREQ_OFFSET0x0200 +#define OMAP5_SCRM_EXTCLKREQ OMAP54XX_SCRM_REGADDR(0x0200) +#define OMAP5_SCRM_ACCCLKREQ_OFFSET0x0204 +#define OMAP5_SCRM_ACCCLKREQ OMAP54XX_SCRM_REGADDR(0x0204) +#define OMAP5_SCRM_PWRREQ_OFFSET 0x0208 +#define OMAP5_SCRM_PWRREQ OMAP54XX_SCRM_REGADDR(0x0208) +#define OMAP5_SCRM_AUXCLKREQ0_OFFSET 0x0210 +#define OMAP5_SCRM_AUXCLKREQ0 OMAP54XX_SCRM_REGADDR(0x0210) +#define OMAP5_SCRM_AUXCLKREQ1_OFFSET 0x0214 +#define OMAP5_SCRM_AUXCLKREQ1 OMAP54XX_SCRM_REGADDR(0x0214) +#define OMAP5_SCRM_AUXCLKREQ2_OFFSET 0x0218 +#define OMAP5_SCRM_AUXCLKREQ2 OMAP54XX_SCRM_REGADDR(0x0218) +#define OMAP5_SCRM_AUXCLKREQ3_OFFSET 0x021c +#define OMAP5_SCRM_AUXCLKREQ3 OMAP54XX_SCRM_REGADDR(0x021c) +#define OMAP5_SCRM_AUXCLKREQ4_OFFSET 0x0220 +#define OMAP5_SCRM_AUXCLKREQ4 OMAP54XX_SCRM_REGADDR(0x0220) +#define OMAP5_SCRM_AUXCLKREQ5_OFFSET 0x0224 +#define OMAP5_SCRM_AUXCLKREQ5 OMAP54XX_SCRM_REGADDR(0x0224) +#define OMAP5_SCRM_D2DCLKREQ_OFFSET0x0234 +#define OMAP5_SCRM_D2DCLKREQ OMAP54XX_SCRM_REGADDR(0x0234) +#define OMAP5_SCRM_AUXCLK0_OFFSET 0x0310 +#define OMAP5_SCRM_AUXCLK0 OMAP54XX_SCRM_REGADDR(0x0310) +#define OMAP5_SCRM_AUXCLK1_OFFSET 0x0314 +#define OMAP5_SCRM_AUXCLK1 OMAP54XX_SCRM_REGADDR(0x0314) +#define OMAP5_SCRM_AUXCLK2_OFFSET 0x0318 +#define OMAP5_SCRM_AUXCLK2 OMAP54XX_SCRM_REGADDR(0x0318) +#define OMAP5_SCRM_AUXCLK3_OFFSET 0x031c +#define OMAP5_SCRM_AUXCLK3 OMAP54XX_SCRM_REGADDR(0x031c) +#define OMAP5_SCRM_AUXCLK4_OFFSET 0x0320 +#define OMAP5_SCRM_AUXCLK4 OMAP54XX_SCRM_REGADDR(0x0320) +#define OMAP5_SCRM_AUXCLK5_OFFSET 0x0324 +#define OMAP5_SCRM_AUXCLK5 OMAP54XX_SCRM_REGADDR(0x0324) +#define OMAP5_SCRM_RSTTIME_OFFSET 0x0400 +#define OMAP5_SCRM_RSTTIME OMAP54XX_SCRM_REGADDR(0x0400) +#define OMAP5_SCRM_MODEMRSTCTRL_OFFSET 0x0418 +#define OMAP5_SCRM_MODEMRSTCTRL OMAP54XX_SCRM_REGADDR(0x0418) +#define OMAP5_SCRM_D2DRSTCTRL_OFFSET 0x041c +#define OMAP5_SCRM_D2DRSTCTRL
[PATCH v2 12/12] ARM: OMAP5: Enable build and frameowrk initialisations
Include the OMAP5 data files in build. Initialise the voltage, power, clock domains. Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/Makefile |4 arch/arm/mach-omap2/io.c |7 +++ 2 files changed, 11 insertions(+) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index b068b7f..5d5ff91 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -127,6 +127,7 @@ obj-$(CONFIG_ARCH_OMAP4)+= voltagedomains44xx_data.o obj-$(CONFIG_SOC_AM33XX) += $(voltagedomain-common) obj-$(CONFIG_SOC_AM33XX)+= voltagedomains33xx_data.o obj-$(CONFIG_SOC_OMAP5)+= $(voltagedomain-common) +obj-$(CONFIG_SOC_OMAP5)+= voltagedomains54xx_data.o # OMAP powerdomain framework powerdomain-common += powerdomain.o powerdomain-common.o @@ -141,6 +142,7 @@ obj-$(CONFIG_ARCH_OMAP4)+= powerdomains44xx_data.o obj-$(CONFIG_SOC_AM33XX) += $(powerdomain-common) obj-$(CONFIG_SOC_AM33XX) += powerdomains33xx_data.o obj-$(CONFIG_SOC_OMAP5)+= $(powerdomain-common) +obj-$(CONFIG_SOC_OMAP5)+= powerdomains54xx_data.o # PRCM clockdomain control clockdomain-common += clockdomain.o @@ -156,6 +158,7 @@ obj-$(CONFIG_ARCH_OMAP4)+= clockdomains44xx_data.o obj-$(CONFIG_SOC_AM33XX) += $(clockdomain-common) obj-$(CONFIG_SOC_AM33XX) += clockdomains33xx_data.o obj-$(CONFIG_SOC_OMAP5)+= $(clockdomain-common) +obj-$(CONFIG_SOC_OMAP5)+= clockdomains54xx_data.o # Clock framework obj-$(CONFIG_ARCH_OMAP2) += $(clock-common) clock2xxx.o @@ -198,6 +201,7 @@ obj-$(CONFIG_ARCH_OMAP3)+= omap_hwmod_2xxx_3xxx_interconnect_data.o obj-$(CONFIG_ARCH_OMAP3) += omap_hwmod_3xxx_data.o obj-$(CONFIG_SOC_AM33XX) += omap_hwmod_33xx_data.o obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_data.o +obj-$(CONFIG_SOC_OMAP5)+= omap_hwmod_54xx_data.o # EMU peripherals obj-$(CONFIG_OMAP3_EMU)+= emu.o diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index 2c3fdd6..e0cea6f 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -618,7 +618,14 @@ void __init omap5_init_early(void) omap2_set_globals_prcm_mpu(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE)); omap_prm_base_init(); omap_cm_base_init(); + omap44xx_prm_init(); omap5xxx_check_revision(); + omap54xx_voltagedomains_init(); + omap54xx_powerdomains_init(); + omap54xx_clockdomains_init(); + omap54xx_hwmod_init(); + omap_hwmod_init_postsetup(); + } #endif -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 11/12] ARM: OMAP5: voltagedomain data: Add OMAP5 voltage domain data
Add voltagedomain related data for OMAP54XX SOCs. OMAP4 OPP data is
used for now. OMAP5 OPP data will be added as part of OMAP5 DVFS
support.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/voltage.h |1 +
arch/arm/mach-omap2/voltagedomains54xx_data.c | 102 +
2 files changed, 103 insertions(+)
create mode 100644 arch/arm/mach-omap2/voltagedomains54xx_data.c
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index a0ce4f1..5998eed 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -171,6 +171,7 @@ extern void omap2xxx_voltagedomains_init(void);
extern void omap3xxx_voltagedomains_init(void);
extern void am33xx_voltagedomains_init(void);
extern void omap44xx_voltagedomains_init(void);
+extern void omap54xx_voltagedomains_init(void);
struct voltagedomain *voltdm_lookup(const char *name);
void voltdm_init(struct voltagedomain **voltdm_list);
diff --git a/arch/arm/mach-omap2/voltagedomains54xx_data.c
b/arch/arm/mach-omap2/voltagedomains54xx_data.c
new file mode 100644
index 000..72b8971
--- /dev/null
+++ b/arch/arm/mach-omap2/voltagedomains54xx_data.c
@@ -0,0 +1,102 @@
+/*
+ * OMAP5 Voltage Management Routines
+ *
+ * Based on voltagedomains44xx_data.c
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include linux/kernel.h
+#include linux/err.h
+#include linux/init.h
+
+#include common.h
+
+#include prm54xx.h
+#include voltage.h
+#include omap_opp_data.h
+#include vc.h
+#include vp.h
+
+static const struct omap_vfsm_instance omap5_vdd_mpu_vfsm = {
+ .voltsetup_reg = OMAP54XX_PRM_VOLTSETUP_MPU_RET_SLEEP_OFFSET,
+};
+
+static const struct omap_vfsm_instance omap5_vdd_mm_vfsm = {
+ .voltsetup_reg = OMAP54XX_PRM_VOLTSETUP_MM_RET_SLEEP_OFFSET,
+};
+
+static const struct omap_vfsm_instance omap5_vdd_core_vfsm = {
+ .voltsetup_reg = OMAP54XX_PRM_VOLTSETUP_CORE_RET_SLEEP_OFFSET,
+};
+
+static struct voltagedomain omap5_voltdm_mpu = {
+ .name = mpu,
+ .scalable = true,
+ .read = omap4_prm_vcvp_read,
+ .write = omap4_prm_vcvp_write,
+ .rmw = omap4_prm_vcvp_rmw,
+ .vc = omap4_vc_mpu,
+ .vfsm = omap5_vdd_mpu_vfsm,
+ .vp = omap4_vp_mpu,
+};
+
+static struct voltagedomain omap5_voltdm_mm = {
+ .name = mm,
+ .scalable = true,
+ .read = omap4_prm_vcvp_read,
+ .write = omap4_prm_vcvp_write,
+ .rmw = omap4_prm_vcvp_rmw,
+ .vc = omap4_vc_iva,
+ .vfsm = omap5_vdd_mm_vfsm,
+ .vp = omap4_vp_iva,
+};
+
+static struct voltagedomain omap5_voltdm_core = {
+ .name = core,
+ .scalable = true,
+ .read = omap4_prm_vcvp_read,
+ .write = omap4_prm_vcvp_write,
+ .rmw = omap4_prm_vcvp_rmw,
+ .vc = omap4_vc_core,
+ .vfsm = omap5_vdd_core_vfsm,
+ .vp = omap4_vp_core,
+};
+
+static struct voltagedomain omap5_voltdm_wkup = {
+ .name = wkup,
+};
+
+static struct voltagedomain *voltagedomains_omap5[] __initdata = {
+ omap5_voltdm_mpu,
+ omap5_voltdm_mm,
+ omap5_voltdm_core,
+ omap5_voltdm_wkup,
+ NULL,
+};
+
+static const char *sys_clk_name __initdata = sys_clkin;
+
+void __init omap54xx_voltagedomains_init(void)
+{
+ struct voltagedomain *voltdm;
+ int i;
+
+ /*
+* XXX Will depend on the process, validation, and binning
+* for the currently-running IC. Use OMAP4 data for time being.
+*/
+#ifdef CONFIG_PM_OPP
+ omap5_voltdm_mpu.volt_data = omap446x_vdd_mpu_volt_data;
+ omap5_voltdm_mm.volt_data = omap446x_vdd_iva_volt_data;
+ omap5_voltdm_core.volt_data = omap446x_vdd_core_volt_data;
+#endif
+
+ for (i = 0; voltdm = voltagedomains_omap5[i], voltdm; i++)
+ voltdm-sys_clk.name = sys_clk_name;
+
+ voltdm_init(voltagedomains_omap5);
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 08/12] ARM: OMAP5: clockdomain data: Add OMAP54XX data and update the header
From: Benoit Cousson b-cous...@ti.com
Add the data file to describe all clock domains inside the OMAP54XX soc.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
[santosh.shilim...@ti.com: Generated es2.0 data]
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/clockdomain.h |1 +
arch/arm/mach-omap2/clockdomains54xx_data.c | 464 +++
2 files changed, 465 insertions(+)
create mode 100644 arch/arm/mach-omap2/clockdomains54xx_data.c
diff --git a/arch/arm/mach-omap2/clockdomain.h
b/arch/arm/mach-omap2/clockdomain.h
index 2da3765..daeecf1 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -216,6 +216,7 @@ extern void __init omap243x_clockdomains_init(void);
extern void __init omap3xxx_clockdomains_init(void);
extern void __init am33xx_clockdomains_init(void);
extern void __init omap44xx_clockdomains_init(void);
+extern void __init omap54xx_clockdomains_init(void);
extern void clkdm_add_autodeps(struct clockdomain *clkdm);
extern void clkdm_del_autodeps(struct clockdomain *clkdm);
diff --git a/arch/arm/mach-omap2/clockdomains54xx_data.c
b/arch/arm/mach-omap2/clockdomains54xx_data.c
new file mode 100644
index 000..1a3c69d
--- /dev/null
+++ b/arch/arm/mach-omap2/clockdomains54xx_data.c
@@ -0,0 +1,464 @@
+/*
+ * OMAP54XX Clock domains framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Abhijit Pagare (abhijitpag...@ti.com)
+ * Benoit Cousson (b-cous...@ti.com)
+ * Paul Walmsley (p...@pwsan.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.
+ */
+
+#include linux/kernel.h
+#include linux/io.h
+
+#include clockdomain.h
+#include cm1_54xx.h
+#include cm2_54xx.h
+
+#include cm-regbits-54xx.h
+#include prm54xx.h
+#include prcm44xx.h
+#include prcm_mpu54xx.h
+
+/* Static Dependencies for OMAP4 Clock Domains */
+
+static struct clkdm_dep c2c_wkup_sleep_deps[] = {
+ { .clkdm_name = abe_clkdm },
+ { .clkdm_name = emif_clkdm },
+ { .clkdm_name = iva_clkdm },
+ { .clkdm_name = l3init_clkdm },
+ { .clkdm_name = l3main1_clkdm },
+ { .clkdm_name = l3main2_clkdm },
+ { .clkdm_name = l4cfg_clkdm },
+ { .clkdm_name = l4per_clkdm },
+ { NULL },
+};
+
+static struct clkdm_dep cam_wkup_sleep_deps[] = {
+ { .clkdm_name = emif_clkdm },
+ { .clkdm_name = iva_clkdm },
+ { .clkdm_name = l3main1_clkdm },
+ { NULL },
+};
+
+static struct clkdm_dep dma_wkup_sleep_deps[] = {
+ { .clkdm_name = abe_clkdm },
+ { .clkdm_name = dss_clkdm },
+ { .clkdm_name = emif_clkdm },
+ { .clkdm_name = ipu_clkdm },
+ { .clkdm_name = iva_clkdm },
+ { .clkdm_name = l3init_clkdm },
+ { .clkdm_name = l3main1_clkdm },
+ { .clkdm_name = l4cfg_clkdm },
+ { .clkdm_name = l4per_clkdm },
+ { .clkdm_name = l4sec_clkdm },
+ { .clkdm_name = wkupaon_clkdm },
+ { NULL },
+};
+
+static struct clkdm_dep dsp_wkup_sleep_deps[] = {
+ { .clkdm_name = abe_clkdm },
+ { .clkdm_name = emif_clkdm },
+ { .clkdm_name = iva_clkdm },
+ { .clkdm_name = l3init_clkdm },
+ { .clkdm_name = l3main1_clkdm },
+ { .clkdm_name = l3main2_clkdm },
+ { .clkdm_name = l4cfg_clkdm },
+ { .clkdm_name = l4per_clkdm },
+ { .clkdm_name = wkupaon_clkdm },
+ { NULL },
+};
+
+static struct clkdm_dep dss_wkup_sleep_deps[] = {
+ { .clkdm_name = emif_clkdm },
+ { .clkdm_name = iva_clkdm },
+ { .clkdm_name = l3main2_clkdm },
+ { NULL },
+};
+
+static struct clkdm_dep gpu_wkup_sleep_deps[] = {
+ { .clkdm_name = emif_clkdm },
+ { .clkdm_name = iva_clkdm },
+ { .clkdm_name = l3main1_clkdm },
+ { NULL },
+};
+
+static struct clkdm_dep ipu_wkup_sleep_deps[] = {
+ { .clkdm_name = abe_clkdm },
+ { .clkdm_name = dsp_clkdm },
+ { .clkdm_name = dss_clkdm },
+ { .clkdm_name = emif_clkdm },
+ { .clkdm_name = gpu_clkdm },
+ { .clkdm_name = iva_clkdm },
+ { .clkdm_name = l3init_clkdm },
+ { .clkdm_name = l3main1_clkdm },
+ { .clkdm_name = l3main2_clkdm },
+ { .clkdm_name = l4cfg_clkdm },
+ { .clkdm_name = l4per_clkdm },
+ { .clkdm_name = l4sec_clkdm },
+ { .clkdm_name = wkupaon_clkdm },
+ { NULL },
+};
+
+static struct clkdm_dep iva_wkup_sleep_deps[] = {
+ { .clkdm_name = emif_clkdm },
+ { .clkdm_name = l3main1_clkdm },
+ { NULL },
+};
[PATCH v2 09/12] ARM: OMAP5: powerdomain data: Add OMAP54XX data and update the header
From: Benoit Cousson b-cous...@ti.com
Add the data file to describe all power domains inside the OMAP54XX soc.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
[santosh.shilim...@ti.com: Generated es2.0 data]
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/powerdomain.h |1 +
arch/arm/mach-omap2/powerdomains54xx_data.c | 331 +++
2 files changed, 332 insertions(+)
create mode 100644 arch/arm/mach-omap2/powerdomains54xx_data.c
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index 140c360..3d82f50 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -253,6 +253,7 @@ extern void omap243x_powerdomains_init(void);
extern void omap3xxx_powerdomains_init(void);
extern void am33xx_powerdomains_init(void);
extern void omap44xx_powerdomains_init(void);
+extern void omap54xx_powerdomains_init(void);
extern struct pwrdm_ops omap2_pwrdm_operations;
extern struct pwrdm_ops omap3_pwrdm_operations;
diff --git a/arch/arm/mach-omap2/powerdomains54xx_data.c
b/arch/arm/mach-omap2/powerdomains54xx_data.c
new file mode 100644
index 000..81f8a7c
--- /dev/null
+++ b/arch/arm/mach-omap2/powerdomains54xx_data.c
@@ -0,0 +1,331 @@
+/*
+ * OMAP54XX Power domains framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Abhijit Pagare (abhijitpag...@ti.com)
+ * Benoit Cousson (b-cous...@ti.com)
+ * Paul Walmsley (p...@pwsan.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.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+
+#include powerdomain.h
+
+#include prcm-common.h
+#include prcm44xx.h
+#include prm-regbits-54xx.h
+#include prm54xx.h
+#include prcm_mpu54xx.h
+
+/* core_54xx_pwrdm: CORE power domain */
+static struct powerdomain core_54xx_pwrdm = {
+ .name = core_pwrdm,
+ .voltdm = { .name = core },
+ .prcm_offs= OMAP54XX_PRM_CORE_INST,
+ .prcm_partition = OMAP54XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_RET_ON,
+ .pwrsts_logic_ret = PWRSTS_OFF_RET,
+ .banks= 5,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_OFF_RET, /* core_nret_bank */
+ [1] = PWRSTS_OFF_RET, /* core_ocmram */
+ [2] = PWRSTS_OFF_RET, /* core_other_bank */
+ [3] = PWRSTS_OFF_RET, /* ipu_l2ram */
+ [4] = PWRSTS_OFF_RET, /* ipu_unicache */
+ },
+ .pwrsts_mem_on = {
+ [0] = PWRSTS_OFF_RET, /* core_nret_bank */
+ [1] = PWRSTS_OFF_RET, /* core_ocmram */
+ [2] = PWRSTS_OFF_RET, /* core_other_bank */
+ [3] = PWRSTS_OFF_RET, /* ipu_l2ram */
+ [4] = PWRSTS_OFF_RET, /* ipu_unicache */
+ },
+ .flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* abe_54xx_pwrdm: Audio back end power domain */
+static struct powerdomain abe_54xx_pwrdm = {
+ .name = abe_pwrdm,
+ .voltdm = { .name = core },
+ .prcm_offs= OMAP54XX_PRM_ABE_INST,
+ .prcm_partition = OMAP54XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts_logic_ret = PWRSTS_OFF,
+ .banks= 2,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_OFF_RET, /* aessmem */
+ [1] = PWRSTS_OFF_RET, /* periphmem */
+ },
+ .pwrsts_mem_on = {
+ [0] = PWRSTS_OFF_RET, /* aessmem */
+ [1] = PWRSTS_OFF_RET, /* periphmem */
+ },
+ .flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* coreaon_54xx_pwrdm: Always ON logic that sits in VDD_CORE voltage domain */
+static struct powerdomain coreaon_54xx_pwrdm = {
+ .name = coreaon_pwrdm,
+ .voltdm = { .name = core },
+ .prcm_offs= OMAP54XX_PRM_COREAON_INST,
+ .prcm_partition = OMAP54XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_ON,
+};
+
+/* dss_54xx_pwrdm: Display subsystem power domain */
+static struct powerdomain dss_54xx_pwrdm = {
+ .name = dss_pwrdm,
+ .voltdm = { .name = core },
+ .prcm_offs= OMAP54XX_PRM_DSS_INST,
+ .prcm_partition = OMAP54XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts_logic_ret = PWRSTS_OFF,
+ .banks= 1,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_OFF_RET,
Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
Paul, On Thursday 04 April 2013 01:39 AM, Paul Walmsley wrote: cc Kevin Hi On Wed, 20 Mar 2013, Santosh Shilimkar wrote: Benoit Cousson (7): ARM: OMAP5: PRM: Add OMAP54XX register and bitfield files So it looks like this patch never made it to the mailing list. Was it too big? If so, please try splitting it into two or more pieces. Looking at the git branch that you posted for pulling, the patch adds two files, so maybe you can just create one patch for each file? Size was not an issue mostly. Looks like that entire series got affected because of the TI mailer issue which was reported by ARM list maintainer. I lost many emails during that. Also, looking at the bottom of the arch/arm/mach-omap2/prm54xx.h from this commit 600e78bb51c0ee081f0da14f879c3e4a1dee9896, there are a bunch of function prototypes that reference OMAP44xx. Shouldn't these reference OMAP54xx, or be removed from this file? If you're reusing the OMAP4 PRM functions for OMAP5, then shouldn't they be moved out from the OMAP4 header files into a separate header file? Yes. I some how ignored this considering the files were auto-generated. Have fixed this one now in v2 [1] which is posted on list ARM: OMAP5: CM: Add OMAP54XX register and bitfield files There are similar problems with this patch. It doesn't look like it ever made it to the linux-omap list, in my inbox, anyway. And again the function prototypes make several references to OMAP4, when they should refer to OMAP5 or be removed from this file. Fixed in v2 ARM: OMAP5: PRCM: Add OMAP54XX local MPU PRCM registers More duplicated OMAP4 function prototypes here. Fixed in v2 ARM: OMAP5: SCRM: Add OMAP54XX header file. Looks fine to me. ARM: OMAP2+: clockdomain data: Add OMAP54XX data and update the header ARM: OMAP5: powerdomain data: Add OMAP54XX data and update the header These two look okay to me based on a superficial inspection. Is there a public TRM posted for OMAP5? It's not in the obvious place, so there's no way to review these against the TRM: http://www.ti.com/lsds/ti/omap-applications-processors/technical-documents.page?familyId=601docCategoryId=6 Public TRM got delayed becasue of recent changes at TI. As per the latest I heard, April end the TRM should be public. But as you know auto-generated data is often more accurate than TRM :) ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data Looks like this one hasn't been reposted after the changes that were made to it after Tony's comments? If I've just missed the list post, please send a link. Otherwise, the updated patch should be reposted. As mentioned earlier, the series was lost mostly because of mailer issue. Posted v2 has this patch now. Santosh Shilimkar (4): ARM: OMAP5: hwmod_data: Fix UART sysc settings ARM: OMAP5: hwmod-data: Add timer clock activity flags These two should be rolled into the ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data patch. Folded in v2. ARM: OMAP5: voltagedomain data: Add OMAP5 voltage domain data This one needs to be acked by Kevin. Kevin has been cc'ed on this one. ARM: OMAP5: Enable build and frameowrk initialisations Looks fine to me. Thanks a lot for quick response. Please let me know if I missed any of your comments in v2. Regards, Santosh [1] http://www.spinics.net/lists/arm-kernel/msg235575.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] ARM: OMAP5: hwmod, clock and prm data files
On Thursday 04 April 2013 01:43 AM, Paul Walmsley wrote: Hi, On Fri, 18 Jan 2013, Santosh Shilimkar wrote: Series contains the hwmod, clock and prm data files for OMAP54xx SOCs. This data was kept out of tree to be validated on es2.0 silicon version and also to avoid the es1.0/es2.0 differences which are many. Benoit Cousson, Rajendra Nayak, Paul Walmesly and Mike have all contributed to get the autogen scripts in shape for OMAP5. From various discussion on the list, the clock data files are suppose to be moved to drivers/clk/. Once the direction is clear, patch 8 can be updated accordingly. Patches are tested on OMAP5 sEVM and uEVM. For testing few additional patches are needed. Same tree can be fetched from here [1] The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619: Linux 3.8-rc4 (2013-01-17 19:25:45 -0800) are available in the git repository at: git://github.com/SantoshShilimkar/linux.git for_3.9/omap5_data_files for you to fetch changes up to 7f534e1ebeb2bc64250b56fe00eb7d4dfa585e8e: ARM: OMAP5: Enable build and frameowrk initialisations (2013-01-18 19:45:48 +0530) I've posted several comments on the patch contents themselves, all of which are relatively minor, and should be easy to fix: Indeed the fixes were easy. Have posted v2 [1] with the updates. Regards, Santosh [1] http://www.spinics.net/lists/arm-kernel/msg235575.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 v5 1/6] drivers: phy: add generic PHY framework
Hi,
On 04/04/2013 11:21 AM, Kishon Vijay Abraham I wrote:
On Thursday 04 April 2013 03:16 AM, Sylwester Nawrocki wrote:
On 04/03/2013 02:53 PM, Kishon Vijay Abraham I wrote:
+4. Getting a reference to the PHY
+
+Before the controller can make use of the PHY, it has to get a
reference to
+it. This framework provides 6 APIs to get a reference to the PHY.
+
+struct phy *phy_get(struct device *dev, int index);
+struct phy *devm_phy_get(struct device *dev, int index);
+struct phy *of_phy_get(struct device *dev, const char *phandle, int
index);
+struct phy *devm_of_phy_get(struct device *dev, const char *phandle,
int index);
Why do we need separate functions for dt and non-dt ? Couldn't it be
handled
internally by the framework ? So the PHY users can use same calls for dt
and non-dt, like in case of e.g. the regulators API ?
yeah. Indeed it makes sense to do it that way.
Also signatures of some functions are different now:
extern struct phy *phy_get(struct device *dev, int index);
extern struct phy *devm_phy_get(struct device *dev, int index);
extern struct phy *of_phy_get(struct device *dev, int index);
extern struct phy *devm_of_phy_get(struct device *dev, int index);
My bad :-(
BTW, I think extern could be dropped, does it have any significance in
function declarations in header files ?
it shouldn't have any effect I guess. It's harmless nevertheless.
Yup.
+struct phy *of_phy_get_byname(struct device *dev, const char *string);
+struct phy *devm_of_phy_get_byname(struct device *dev, const char
*string);
--- /dev/null
+++ b/drivers/phy/phy-core.c
@@ -0,0 +1,616 @@
+static struct phy *of_phy_lookup(struct device_node *node)
+{
+struct phy *phy;
+struct device *dev;
+struct class_dev_iter iter;
+
+class_dev_iter_init(iter, phy_class, NULL, NULL);
There is currently nothing preventing a call to this function before
phy_class is initialized. It happened during my tests, and the nice
stack dump showed that it was the PHY user attempting to get the PHY
before the framework got initialized. So either phy_core_init should
be a subsys_initcall or we need a better protection against phy_class
being NULL or ERR_PTR in more places.
Whats the initcall used in your PHY user? Looks like more people prefer having
It happened in a regular platform driver probe() callback.
module_init and any issue because of it should be fixed in PHY providers and
PHY users.
OK. In fact this uncovered some issues in the MIPI DSI interface driver
(some unexpected interrupts). But this should just be fixed in those drivers
anyway. Now the DSI interface driver needs to wait for the PHY to be
registered and ready, so the initialization will likely be changed regardless
the framework initializes in module_init or earlier.
+while ((dev = class_dev_iter_next(iter))) {
+phy = container_of(dev, struct phy, dev);
+if (node != phy-of_node)
+continue;
+
+class_dev_iter_exit(iter);
+return phy;
+}
+
+class_dev_iter_exit(iter);
+return ERR_PTR(-EPROBE_DEFER);
+}
+/**
+ * of_phy_get() - lookup and obtain a reference to a phy by phandle
+ * @dev: device that requests this phy
+ * @index: the index of the phy
+ *
+ * Returns the phy associated with the given phandle value,
+ * after getting a refcount to it or -ENODEV if there is no such phy or
+ * -EPROBE_DEFER if there is a phandle to the phy, but the device is
+ * not yet loaded.
+ */
+struct phy *of_phy_get(struct device *dev, int index)
+{
+int ret;
+struct phy *phy = NULL;
+struct phy_bind *phy_map = NULL;
+struct of_phandle_args args;
+struct device_node *node;
+
+if (!dev-of_node) {
+dev_dbg(dev, device does not have a device node entry\n);
+return ERR_PTR(-EINVAL);
+}
+
+ret = of_parse_phandle_with_args(dev-of_node, phys, #phy-cells,
+index,args);
+if (ret) {
+dev_dbg(dev, failed to get phy in %s node\n,
+dev-of_node-full_name);
+return ERR_PTR(-ENODEV);
+}
+
+phy = of_phy_lookup(args.np);
+if (IS_ERR(phy) || !try_module_get(phy-ops-owner)) {
+phy = ERR_PTR(-EPROBE_DEFER);
+goto err0;
+}
+
+phy = phy-ops-of_xlate(phy,args);
+if (IS_ERR(phy))
+goto err1;
+
+phy_map = phy_bind(dev_name(dev), index, dev_name(phy-dev));
+if (!IS_ERR(phy_map)) {
+phy_map-phy = phy;
+phy_map-auto_bind = true;
Shouldn't it be done with the phy_bind_mutex held ? I guess an unlocked
version of the phy_bind functions is needed, so it can be used internally.
The locking is done inside phy_bind function. I'm not sure but I vaguely
remember getting a dump stack (incorrect mutex ordering or something) when
trying to have phy_bind_mutex here. I can check it again.
Yes, IIUC the locking needs to be reworked a bit so phy_map is not modified
without the mutex held.
Re: [PATCH] Revert OMAP/serial: Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO IRQ generation
On Thu, Apr 4, 2013 at 12:06 AM, Alexey Pelykh alexey.pel...@gmail.com wrote: Is it possible to check behavior on 3.0-3.2 kernels? We use 3.2 on pandora as production kernel and it doesn't have this issue that 3.9 had. 3.2 serial PM code is vastly different from what's in later ones though. On Wed, Apr 3, 2013 at 11:57 PM, Paul Walmsley p...@pwsan.com wrote: Hi Alexey, On Wed, 3 Apr 2013, Alexey Pelykh wrote: But, since we've found the issue, I suggest that we should look at it closer, especially since at this moment only you can reproduce it. Well probably no one else is testing it :-) As far as I understand, but I may be wrong, this comment is wrong, since if to specify OMAP_UART_SCR_RX_TRIG_GRANU1_MASK, it effectively sets Rx threshold to 1 character, instead of 16. /* Set receive FIFO threshold to 16 characters and * transmit FIFO threshold to 16 spaces */ Again it certainly would not surprise me... that UART IP block seems to be poorly understood :-( Bizarre, I know. - Paul -- Gražvydas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
+ Tero and few more TI folks,
On Thursday 04 April 2013 01:12 AM, Paul Walmsley wrote:
Hi Santosh
On Wed, 3 Apr 2013, Santosh Shilimkar wrote:
Thes patchset has already missed last couple of merge windows and its the
biggest bottleneck in getting OMAP5 booting from mainline. So I request
you to please have a look it quickly so that Tony can line that up for
3.10.
Looks like there are a few minor issues with the patches based on a quick
look. I'll post those to the list shortly; they should be easy to fix.
But those issues aren't my real concern with this series.
What's harder to fix are the underlying process issues. My main concern
is that these patches add almost 9,000 lines of code and data. We've
received clear guidance from the upstream ARM SoC maintainers that any
significant new additions need to be balanced with moving a similar number
of lines of code and data out of arch/arm/{plat-,mach-}* into drivers/.
(Or the new patches should be accompanied with patches that show obvious
progress towards the goal of moving code and data out of
arch/arm/{plat-,mach-}*.) We need to see more help from TI on the
prerequisites for this cleanup process.
I agree that we are not making faster progress but as part of the
$subject series itself, for DT only build, we removed around ~4000
lines of data from hwmod. After the merge window, we can trim
the AM33XX and then later OMAP4 when it is made DT only support.
That should give us another 6000 lines of negative diff.
At the same time removal of MUX data for OMAP4 should be
around 2000 lines of negative diff.
You might also notice, we dropped OMAP5 clock data considering
its move under drivers/clk/. Rajendra and Tero already posted
patches [1] for the same on the list. Ofcourse your feedback is
needed to make progress there.
For example, as discussed last year with the TI upstream PM team, an
important first step in this process in my view is to get rid of the
direct PRM/CM register accesses in the OMAP PM code. See commit
c4ceedcb18cf7a06059482a3a1828b9aad9f78cf (ARM: OMAP2+: CM/clock: convert
_omap2_module_wait_ready() to use SoC-independent CM functions) as an
example of this process. This should make it easier to get the PRM/CM
functionality into drivers/. That in turn make it possible to move the
clockdomain, clock, powerdomain, and hwmod code to drivers/.ARM: OMAP2+:
CM/clock: convert _omap2_module_wait_ready() to use SoC-independent CM
functions. So far as I can tell, there hasn't been any forward progress
on this.
On this part as well after my discussion with Tony, Tero picked it up
and he and Eduardo posted questions to you [2] considering you
already had some WIP patches as we learned from Tony. I suggest
you send any information on this to Tero since he is leading the
PM effort and has plans to work on these items.
It's also necessary to see more TI contributions in finding and fixing
regressions. Detecting and fixing regressions from the previous kernel
release should be done first, before working on cleanup series or new
feature/SoC additions. Looking at the list of v3.9-rc regressions that
I've found, we've gotten very little organized help from TI on dealing
with them.
This in turn robs the maintainers of time that could be spent doing patch
review or further cleanup work, which benefits no one in the end.
Ideally each regression would be assigned to a member of the TI upstream
team, and the whole process could be completed within one or two weeks.
I agree with you overall.
On couple of specific issues though,
- BOOT-Loader version: IMHO boot-loader should be upgraded here.
We always upgrade kernel for new/fixed features and bootloader should
be no exception.
- Co-processor Power issue: This one is also has boot-loader dependency
but here too, going on path where firmware needs to be loaded to idle
them isn't great idea. We never did that for OMAP2/3 where DSP, Tesla
was present. IMO, we should not bring these devices out of reset and
let the remote_proc() frame works take care of them when it is
available in kernel. Suman from TI is working on it to enable that.
...
So from my point of view, I'd like to see the following changes before we
accept any new patchsets that add a significant number of lines:
1. Organized help from TI in finding and fixing regressions in the -rc
cycle, with the regressions dealt with before any new feature
pull-requests are sent
Agreed. Tero can help here to streamline the process for PM regressions.
Rest of the core regressions and MPU PM, feel free to pass it on to
Rajendra/me. We will try to address them on priority.
2. Help from TI on some of the cleanup work that we've mentioned in the
past, starting with the PRM/CM register access cleanup inside mach-omap2/
Absolutely. As I mentioned earlier, Eduardo and Tero are waiting for your
inputs on this topic.
3. Pairing any large feature or SoC
Re: [PATCH v5 1/6] drivers: phy: add generic PHY framework
Hi,
On Thursday 04 April 2013 04:11 PM, Sylwester Nawrocki wrote:
Hi,
On 04/04/2013 11:21 AM, Kishon Vijay Abraham I wrote:
On Thursday 04 April 2013 03:16 AM, Sylwester Nawrocki wrote:
On 04/03/2013 02:53 PM, Kishon Vijay Abraham I wrote:
+4. Getting a reference to the PHY
+
+Before the controller can make use of the PHY, it has to get a
reference to
+it. This framework provides 6 APIs to get a reference to the PHY.
+
+struct phy *phy_get(struct device *dev, int index);
+struct phy *devm_phy_get(struct device *dev, int index);
+struct phy *of_phy_get(struct device *dev, const char *phandle, int
index);
+struct phy *devm_of_phy_get(struct device *dev, const char *phandle,
int index);
Why do we need separate functions for dt and non-dt ? Couldn't it be
handled
internally by the framework ? So the PHY users can use same calls for dt
and non-dt, like in case of e.g. the regulators API ?
yeah. Indeed it makes sense to do it that way.
Also signatures of some functions are different now:
extern struct phy *phy_get(struct device *dev, int index);
extern struct phy *devm_phy_get(struct device *dev, int index);
extern struct phy *of_phy_get(struct device *dev, int index);
extern struct phy *devm_of_phy_get(struct device *dev, int index);
My bad :-(
BTW, I think extern could be dropped, does it have any significance in
function declarations in header files ?
it shouldn't have any effect I guess. It's harmless nevertheless.
Yup.
+struct phy *of_phy_get_byname(struct device *dev, const char *string);
+struct phy *devm_of_phy_get_byname(struct device *dev, const char
*string);
--- /dev/null
+++ b/drivers/phy/phy-core.c
@@ -0,0 +1,616 @@
+static struct phy *of_phy_lookup(struct device_node *node)
+{
+struct phy *phy;
+struct device *dev;
+struct class_dev_iter iter;
+
+class_dev_iter_init(iter, phy_class, NULL, NULL);
There is currently nothing preventing a call to this function before
phy_class is initialized. It happened during my tests, and the nice
stack dump showed that it was the PHY user attempting to get the PHY
before the framework got initialized. So either phy_core_init should
be a subsys_initcall or we need a better protection against phy_class
being NULL or ERR_PTR in more places.
Whats the initcall used in your PHY user? Looks like more people prefer having
It happened in a regular platform driver probe() callback.
module_init and any issue because of it should be fixed in PHY providers and
PHY users.
OK. In fact this uncovered some issues in the MIPI DSI interface driver
(some unexpected interrupts). But this should just be fixed in those drivers
anyway. Now the DSI interface driver needs to wait for the PHY to be
registered and ready, so the initialization will likely be changed regardless
the framework initializes in module_init or earlier.
+while ((dev = class_dev_iter_next(iter))) {
+phy = container_of(dev, struct phy, dev);
+if (node != phy-of_node)
+continue;
+
+class_dev_iter_exit(iter);
+return phy;
+}
+
+class_dev_iter_exit(iter);
+return ERR_PTR(-EPROBE_DEFER);
+}
+/**
+ * of_phy_get() - lookup and obtain a reference to a phy by phandle
+ * @dev: device that requests this phy
+ * @index: the index of the phy
+ *
+ * Returns the phy associated with the given phandle value,
+ * after getting a refcount to it or -ENODEV if there is no such phy or
+ * -EPROBE_DEFER if there is a phandle to the phy, but the device is
+ * not yet loaded.
+ */
+struct phy *of_phy_get(struct device *dev, int index)
+{
+int ret;
+struct phy *phy = NULL;
+struct phy_bind *phy_map = NULL;
+struct of_phandle_args args;
+struct device_node *node;
+
+if (!dev-of_node) {
+dev_dbg(dev, device does not have a device node entry\n);
+return ERR_PTR(-EINVAL);
+}
+
+ret = of_parse_phandle_with_args(dev-of_node, phys, #phy-cells,
+index,args);
+if (ret) {
+dev_dbg(dev, failed to get phy in %s node\n,
+dev-of_node-full_name);
+return ERR_PTR(-ENODEV);
+}
+
+phy = of_phy_lookup(args.np);
+if (IS_ERR(phy) || !try_module_get(phy-ops-owner)) {
+phy = ERR_PTR(-EPROBE_DEFER);
+goto err0;
+}
+
+phy = phy-ops-of_xlate(phy,args);
+if (IS_ERR(phy))
+goto err1;
+
+phy_map = phy_bind(dev_name(dev), index, dev_name(phy-dev));
+if (!IS_ERR(phy_map)) {
+phy_map-phy = phy;
+phy_map-auto_bind = true;
Shouldn't it be done with the phy_bind_mutex held ? I guess an unlocked
version of the phy_bind functions is needed, so it can be used internally.
The locking is done inside phy_bind function. I'm not sure but I vaguely
remember getting a dump stack (incorrect mutex ordering or something) when
trying to have phy_bind_mutex here. I can check it again.
Yes, IIUC the locking needs to be reworked a bit so phy_map is not modified
without the mutex held.
+}
+
+
Re: [PATCH v2 01/18] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
On Thursday 04 April 2013 01:14 AM, Kevin Hilman wrote:
Hi Santosh,
Santosh Shilimkar santosh.shilim...@ti.com writes:
OMAP5 and future OMAP based SOCs has backward compatible MPUSS
IP block with OMAP4. It's programming model is mostly similar.
Hence consolidate the OMAP MPUSS code so that it can be re-used
on OMAP5 and future SOCs.
No functional change.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 65
-
1 file changed, 54 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index d650f91..d9e4843 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -71,10 +71,46 @@ struct omap4_cpu_pm_info {
void (*secondary_startup)(void);
};
+/**
+ * struct cpu_pm_ops - CPU pm operations
+ * @finish_suspend: CPU suspend finisher function pointer
+ * @resume: CPU resume function pointer
+ * @scu_prepare:CPU Snoop Control program function pointer
+ *
+ * Structure holds functions pointer for CPU low power operations like
+ * suspend, resume and scu programming.
+ */
+struct cpu_pm_ops {
+int (*finish_suspend)(unsigned long cpu_state);
+void (*resume)(void);
+void (*scu_prepare)(unsigned int cpu_id, unsigned int cpu_state);
+};
+
+extern int omap4_finish_suspend(unsigned long cpu_state);
+extern void omap4_cpu_resume(void);
checkpatch should've yelled at you for adding externs to .c files.
It does. I didn't see they were already in header file and considering
they were shared between asm and mpuss file, I just kept it that way.
i have seen many places in kernel for asm exports, this is being used
and hence kept it.
Also, aren't these already defined in common.h anyways?
Yep. I will just drop above hunk.
Otherwise, patch looks fine.
I will take that as an ack then ?
Regards,
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MUSB regression in linux next at least for pandboard
Hi, On 02/07/2013 04:10 PM, Grazvydas Ignotas wrote: On Thu, Feb 7, 2013 at 11:16 AM, Roger Quadros rog...@ti.com wrote: snip It seems the beagleboard problem is related to OMAP silicon errata [1]. Apparently, remote wakeup as well as host issued wakeup break omap-ehci and have nothing to do with the hub or it's driver. I'll work on this issue after I'm done with device tree migration. Looking forward to this, mainline has been suffering from this since almost forever.. Unfortunately, there is another errata [2] that makes it impossible to support suspend/resume on the beagleboard. cheers, -roger [2] Advisory 3.1.1.195 HSUSB Interoperability Issue With SMSC USB3320 PHY http://www.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=sprz278ffileType=pdf -- To unsubscribe from this list: send the line unsubscribe 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] drivers: video: use module_platform_driver_probe()
On Tue, Apr 2, 2013 at 12:21 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 2013-03-15 15:02, Fabio Porcedda wrote: This patch converts the drivers to use the module_platform_driver_probe() macro which makes the code smaller and a bit simpler. Signed-off-by: Fabio Porcedda fabio.porce...@gmail.com Cc: Florian Tobias Schandinat florianschandi...@gmx.de Acked-by: Nicolas Ferre nicolas.fe...@atmel.com # atmel_lcdfb.c Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: David Howells dhowe...@redhat.com Cc: Geert Uytterhoeven ge...@linux-m68k.org Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com # amifb.c Cc: Kuninori Morimoto kuninori.morimoto...@renesas.com --- Notes: v4: - add acked-by Nicolas Laurent - fix amifb.c v3: - add missing drivers: amifb, atmel_lcdfb, vrfb - split patch set to each maintainer to easy up respin v2: - rebased over linux-next and remove already converted drivers drivers/video/amifb.c | 14 +- drivers/video/atmel_lcdfb.c| 13 + drivers/video/omap2/vrfb.c | 13 + drivers/video/sh_mipi_dsi.c| 12 +--- drivers/video/sh_mobile_hdmi.c | 12 +--- 5 files changed, 5 insertions(+), 59 deletions(-) Thanks, applied to fbdev branch. Thanks for taking it. I don't see this patch neither in linux-next nor in git://gitorious.org/linux-omap-dss2/linux.git, in which repository/branch is it? Regards -- Fabio Porcedda Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] drivers: video: use module_platform_driver_probe()
On 2013-04-04 14:38, Fabio Porcedda wrote: On Tue, Apr 2, 2013 at 12:21 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 2013-03-15 15:02, Fabio Porcedda wrote: This patch converts the drivers to use the module_platform_driver_probe() macro which makes the code smaller and a bit simpler. Signed-off-by: Fabio Porcedda fabio.porce...@gmail.com Cc: Florian Tobias Schandinat florianschandi...@gmx.de Acked-by: Nicolas Ferre nicolas.fe...@atmel.com # atmel_lcdfb.c Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: David Howells dhowe...@redhat.com Cc: Geert Uytterhoeven ge...@linux-m68k.org Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com # amifb.c Cc: Kuninori Morimoto kuninori.morimoto...@renesas.com --- Notes: v4: - add acked-by Nicolas Laurent - fix amifb.c v3: - add missing drivers: amifb, atmel_lcdfb, vrfb - split patch set to each maintainer to easy up respin v2: - rebased over linux-next and remove already converted drivers drivers/video/amifb.c | 14 +- drivers/video/atmel_lcdfb.c| 13 + drivers/video/omap2/vrfb.c | 13 + drivers/video/sh_mipi_dsi.c| 12 +--- drivers/video/sh_mobile_hdmi.c | 12 +--- 5 files changed, 5 insertions(+), 59 deletions(-) Thanks, applied to fbdev branch. Thanks for taking it. I don't see this patch neither in linux-next nor in git://gitorious.org/linux-omap-dss2/linux.git, in which repository/branch is it? I just pushed for-next branch an hour ago or so, to the above mentioned gitorious tree. So should be in linux-next tomorrow, I guess. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v4] drivers: video: use module_platform_driver_probe()
On Thu, Apr 4, 2013 at 1:41 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 2013-04-04 14:38, Fabio Porcedda wrote: On Tue, Apr 2, 2013 at 12:21 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 2013-03-15 15:02, Fabio Porcedda wrote: This patch converts the drivers to use the module_platform_driver_probe() macro which makes the code smaller and a bit simpler. Signed-off-by: Fabio Porcedda fabio.porce...@gmail.com Cc: Florian Tobias Schandinat florianschandi...@gmx.de Acked-by: Nicolas Ferre nicolas.fe...@atmel.com # atmel_lcdfb.c Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: David Howells dhowe...@redhat.com Cc: Geert Uytterhoeven ge...@linux-m68k.org Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com # amifb.c Cc: Kuninori Morimoto kuninori.morimoto...@renesas.com --- Notes: v4: - add acked-by Nicolas Laurent - fix amifb.c v3: - add missing drivers: amifb, atmel_lcdfb, vrfb - split patch set to each maintainer to easy up respin v2: - rebased over linux-next and remove already converted drivers drivers/video/amifb.c | 14 +- drivers/video/atmel_lcdfb.c| 13 + drivers/video/omap2/vrfb.c | 13 + drivers/video/sh_mipi_dsi.c| 12 +--- drivers/video/sh_mobile_hdmi.c | 12 +--- 5 files changed, 5 insertions(+), 59 deletions(-) Thanks, applied to fbdev branch. Thanks for taking it. I don't see this patch neither in linux-next nor in git://gitorious.org/linux-omap-dss2/linux.git, in which repository/branch is it? I just pushed for-next branch an hour ago or so, to the above mentioned gitorious tree. So should be in linux-next tomorrow, I guess. Thanks. -- Fabio Porcedda Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 03/18] ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
On Thursday 04 April 2013 01:50 AM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
OMAP5 has backward compatible PRCM block and it's programming
model is mostly similar to OMAP4. Same is going to be maintained
for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
management code so that it can be re-used on OMAP5 and later devices.
With consolidated code, let basic power management code build
for OMAP5 devices. While at it, update the kernel-doc for omap4_pm_init().
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/Makefile |9 ++--
arch/arm/mach-omap2/{pm44xx.c = pm_omap4plus.c} | 54
.../mach-omap2/{sleep44xx.S = sleep_omap4plus.S} |0
3 files changed, 49 insertions(+), 14 deletions(-)
rename arch/arm/mach-omap2/{pm44xx.c = pm_omap4plus.c} (86%)
rename arch/arm/mach-omap2/{sleep44xx.S = sleep_omap4plus.S} (100%)
[..]
diff --git a/arch/arm/mach-omap2/pm44xx.c
b/arch/arm/mach-omap2/pm_omap4plus.c
similarity index 86%
rename from arch/arm/mach-omap2/pm44xx.c
rename to arch/arm/mach-omap2/pm_omap4plus.c
index 5ba6d88..e920c34 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm_omap4plus.c
@@ -1,7 +1,7 @@
/*
- * OMAP4 Power Management Routines
+ * OMAP4PLUS Power Management Routines
nit: OMAP4+ (you only need to spell out plus in the filename.
OK. I will replace '+' instead of 'PLUS' in rest of the places.
*
- * Copyright (C) 2010-2011 Texas Instruments, Inc.
+ * Copyright (C) 2010-2013 Texas Instruments, Inc.
* Rajendra Nayak rna...@ti.com
* Santosh Shilimkar santosh.shilim...@ti.com
*
@@ -135,16 +135,16 @@ static void omap_default_idle(void)
}
/**
- * omap4_pm_init - Init routine for OMAP4 PM
+ * omap4_init_static_deps - Add OMAP4 static dependencies
*
- * Initializes all powerdomain and clockdomain target states
- * and all PRCM settings.
+ * Add needed static clockdomain dependencies on OMAP4 devices.
+ * Return: 0 on success or 'err' on failures
*/
-int __init omap4_pm_init(void)
+static inline int omap4_init_static_deps(void)
You dropped the __init here, but it's still only called from another
__init function, so I suspect it should stay.
Yep. Will keep that in next version.
Regards,
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
USB ehci suspend/resume on beagleboard
correcting misleading subject line. was (Re: MUSB regression in linux next at least for pandboard) On 04/04/2013 02:36 PM, Roger Quadros wrote: Hi, On 02/07/2013 04:10 PM, Grazvydas Ignotas wrote: On Thu, Feb 7, 2013 at 11:16 AM, Roger Quadros rog...@ti.com wrote: snip It seems the beagleboard problem is related to OMAP silicon errata [1]. Apparently, remote wakeup as well as host issued wakeup break omap-ehci and have nothing to do with the hub or it's driver. I'll work on this issue after I'm done with device tree migration. Looking forward to this, mainline has been suffering from this since almost forever.. Unfortunately, there is another errata [2] that makes it impossible to support suspend/resume on the beagleboard. cheers, -roger [2] Advisory 3.1.1.195 HSUSB Interoperability Issue With SMSC USB3320 PHY http://www.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=sprz278ffileType=pdf -- To unsubscribe from this list: send the line unsubscribe 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 03/18] ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
On Thursday 04 April 2013 05:21 PM, Santosh Shilimkar wrote:
On Thursday 04 April 2013 01:50 AM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
OMAP5 has backward compatible PRCM block and it's programming
model is mostly similar to OMAP4. Same is going to be maintained
for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
management code so that it can be re-used on OMAP5 and later devices.
With consolidated code, let basic power management code build
for OMAP5 devices. While at it, update the kernel-doc for omap4_pm_init().
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/Makefile |9 ++--
arch/arm/mach-omap2/{pm44xx.c = pm_omap4plus.c} | 54
.../mach-omap2/{sleep44xx.S = sleep_omap4plus.S} |0
3 files changed, 49 insertions(+), 14 deletions(-)
rename arch/arm/mach-omap2/{pm44xx.c = pm_omap4plus.c} (86%)
rename arch/arm/mach-omap2/{sleep44xx.S = sleep_omap4plus.S} (100%)
[..]
/**
- * omap4_pm_init - Init routine for OMAP4 PM
+ * omap4_init_static_deps - Add OMAP4 static dependencies
*
- * Initializes all powerdomain and clockdomain target states
- * and all PRCM settings.
+ * Add needed static clockdomain dependencies on OMAP4 devices.
+ * Return: 0 on success or 'err' on failures
*/
-int __init omap4_pm_init(void)
+static inline int omap4_init_static_deps(void)
You dropped the __init here, but it's still only called from another
__init function, so I suspect it should stay.
Yep. Will keep that in next version.
I was too quick to respond. The function is static inline so
there is no need to add __init here.
Regards,
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 05/18] ARM: OMAP5: PM: Enables ES2 PM mode by default
On Thursday 04 April 2013 01:55 AM, Kevin Hilman wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: Enables MPUSS ES2 power management mode using ES2_PM_MODE in AMBA_IF_MODE register. 0x0: ES1 behavior, CPU cores would enter and exit OFF mode together. Broken What is broken? Should have added clarification here. Sorry. Changelog is updated as below 0x0: ES1 behavior, CPU cores would enter and exit OFF mode together. 0x1: ES2 behavior, CPU cores are allowed to enter/exit OFF mode independently. ES1.0 CPUx OFF mode behavior never worked and after analysis by design team, it was declared as a broken hardware feature. That lead to addition of ES2.0 behavior which works. 0x1: ES2 behavior, CPU cores are allowed to enter/exit OFF mode independently. The AMBA_IF_MODE register value is stored on SAR RAM and restored by ROM code. Acked-by: Nishanth Menon n...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- [..] diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c index f8bb3b9..8bcaa8c 100644 --- a/arch/arm/mach-omap2/omap-wakeupgen.c +++ b/arch/arm/mach-omap2/omap-wakeupgen.c @@ -42,6 +42,7 @@ #define CPU1_ID 0x1 #define OMAP4_NR_BANKS 4 #define OMAP4_NR_IRQS 128 +#define OMAP5_AMBA_IF_PM_MODE (1 5) nit: use BIT() Ok. Regards, santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 06/18] ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains
On Thursday 04 April 2013 02:01 AM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
In addition to the standard power-management technique, the OMAP5
MPU subsystem also employs an SR3-APG (mercury) power management
technology to reduce leakage.
It allows for full logic and memories retention on MPU_C0 and MPU_C1 and
is controlled by the PRCM_MPU.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index b1441b1..d390d18 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -62,6 +62,10 @@
#include prm44xx.h
#include prm-regbits-44xx.h
+/* Add defines needed for mercury mode. Refer MPU's PRM_PSCON_COUNT */
+#define PRM_PSCON_HG_EN (1 24)
+#define PRM_PSCON_HG_RAMPUP (1 25)
nit: use BIT()
ok
#ifdef CONFIG_SMP
struct omap4_cpu_pm_info {
@@ -337,6 +341,28 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu,
unsigned int power_state)
return 0;
}
+/**
+ * enable_mercury_retention_mode: Enable OMAP5 mercury retention feature
+ *
+ * OMAP5 devices supports SR3-APG (mercury) power management technology to
+ * reduce leakage. It allows for full logic and memories retention on
+ * MPU_C0 and MPU_C1 and is controlled by the PRCM_MPU. The function enable
+ * the mercury retention feature.
+ */
+static void enable_mercury_retention_mode(void)
__init ?
yep.
This is very OMAP5 specific (unless you generalize the offsets used) so
should this have omap5_ prefix?
Agree.
+{
+u32 reg;
+
+/*
+ * To enable mercury mode, both HG_EN and HG_RAMPUP needs to be
+ * enabled from PRM_PSCON_COUNT register.
+ */
+reg = omap4_prcm_mpu_read_inst_reg(OMAP54XX_PRCM_MPU_DEVICE_INST,
+OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
+reg |= PRM_PSCON_HG_EN | PRM_PSCON_HG_RAMPUP;
+omap4_prcm_mpu_write_inst_reg(reg, OMAP54XX_PRCM_MPU_DEVICE_INST,
+OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
nit: when I see 'reg', I expect it to be a register/offset. But this is
a register value. Maybe use 'val' instead as you've done elsewhere in
this series.
I generally use 'offset' if it is offset and 'reg' for actual register read.
Anyways, I have changed it to 'val' now.
Regards,
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/18] ARM: OMAP5: Add init_late() hook to enable pm initialization
On Thursday 04 April 2013 02:03 AM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
With consolidated code, now we can add the .init_late hook for
OMAP5 to enable power management and mux initialization.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
[..]
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index e948a39..cdd1264 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -636,6 +636,14 @@ void __init omap5_init_early(void)
omap_hwmod_init_postsetup();
}
+
+void __init omap5_init_late(void)
+{
+omap_mux_late_init();
+omap2_common_pm_late_init();
+omap4_pm_init();
+omap2_clk_enable_autoidle_all();
+}
Since you're consolidating, why not rename omap4430_init_late to
omap4plus_init_late and use it for both OMAP4 and OMAP5?
Now re-looking again, I need to drop omap_mux_late_init()
since OMAP5 is DT only. And hence OMAP5 needs to be a
separate hook at least for now.
Regards,
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ADP1653 board code for Nokia RX-51
Hi Sakari, On Thursday 04 April 2013 01:22:28 Sakari Ailus wrote: On Tue, Mar 26, 2013 at 12:07:01AM +0100, Laurent Pinchart wrote: On Sunday 24 March 2013 23:46:01 Sakari Ailus wrote: Pali Rohár wrote: On Thursday 07 March 2013 23:18:27 Sakari Ailus wrote: On Wed, Mar 06, 2013 at 10:44:41PM +0100, Sebastian Reichel wrote: On Wed, Mar 06, 2013 at 09:20:16PM +0100, Pali Rohár wrote: On Wednesday 06 March 2013 21:12:06 Pali Rohár wrote: On Sunday 17 February 2013 20:03:03 Aaro Koskinen wrote: On Sun, Feb 17, 2013 at 04:16:49PM +0100, Pali Rohár wrote: +/* + * arch/arm/mach-omap2/board-rx51-camera.c + * + * Copyright (C) 2008 Nokia Corporation + * + * Contact: Sakari Ailus sakari.ai...@nokia.com + * Tuukka Toivonen tuukka.o.toivo...@nokia.com You should put these people to CC... Just to see if the addresses are still valid (which I doubt). Ok, trying :-) I got Delivery Status Notification (Failure) for both addresses. This is expected. Sakari Ailus hosts some code on github [0], which has the following email address: sakari.ailus+gitori...@retiisi.org.uk I added it to this mail's CC. [0] https://gitorious.org/~sailus Nice to hear people are interested in this. ;-) The primary reason I haven't tried submitting this to mainline is that ARM board code has a bad reputation these days. The N900 does not have yet support for device tree (AFAIK), which also would require a few bits and pieces on the flash driver to work. Also the sensor and lens drivers would need at least some work before being ready for submission to mainline for camera to be usable. Unfortunately I haven't had recently time to work on this. N9(50) support has higher priority for myself. That, too, is pending the DT support for the device. There's indeed more up-to-date code in my repository. Even if it's not too close to mainline anymore it should be a better starting point than the old kernel from MeeGo. URL:https://gitorious.org/omap3camera/pages/Home Hi, this board code is same in your git repository and on meego obs. Patch only adding support for adp1653 driver which is already in upstream kernel. Are there any other problems with this patch to go for upstream? A few more things comes to mind. We depend a little bit on actual board code; it's not only static data. That's the configuration of the external clock from the ISP to the sensor. That should move to the common clock framework so that the ISP registers the clock and the sensor driver can then use it. AFAIR Laurent has done some work on that. Yes. I hope to get the patches in v3.10. Cool! :) The patches have been posted to the linux-media mailing list. If the dependencies make it to v3.10 the OMAP3 ISP patches should get there too. The peculiar detail of the rx51 is that there's a switch on the camera CCP2 bus that selects either sensor (primary or secondary). Both sensors are connected to the same receiver. That isn't properly modelled currently at all, so that's why we have rx51_camera_set_xshutdown(). I guess it'd still work if you only power (i.e. open) either of the devices at a time, though. Have you thought about how we could model that ? Well, the two dependent gpios could be modelled as two independent ones ( for sensor drivers), but setting the state of those gpios could fail, gpio_set_value() still returns void. This isn't pretty perhaps but as a result the initialisation of the secondary sensor to be powered up at the same time will fail since it's in reset: the xshutdown of both sensors is controlled by the same gpio as is the mux (AFAIR). So one N900 camera specific gpio driver would be needed. It'd be a very simple driver. What do you think? I think I'll need to see how the GPIOs are wired up on the board. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 08/18] ARM: OMAP5: PM: Add CPU power off in hotplug path
On Thursday 04 April 2013 02:19 AM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
Add power management code to handle the CPU off mode to enable CPUP hotplug
mode for OMAP5 devices. Separate suspend finisher is used for
OMAP5(Cortex-A15)
because it doesn't use SCU power status register and external PL310 L2 cache
which makes code flow bit different.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[...]
@@ -436,14 +445,21 @@ int __init omap4_mpuss_init(void)
if (cpu_is_omap44xx()) {
omap_pm_ops.finish_suspend = omap4_finish_suspend;
+omap_pm_ops.hotplug_restart = omap_secondary_startup;
omap_pm_ops.resume = omap4_cpu_resume;
omap_pm_ops.scu_prepare = scu_pwrst_prepare;
cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
} else if (soc_is_omap54xx()) {
+omap_pm_ops.finish_suspend = omap5_finish_suspend;
+omap_pm_ops.hotplug_restart = omap5_secondary_startup;
cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
enable_mercury_retention_mode();
}
+/* Over-write the OMAP4 hook to take care of ROM BUG */
+if (cpu_is_omap446x())
+omap_pm_ops.hotplug_restart = omap_secondary_startup_4460;
A couple nits...
I think this would go better at the end of the 'if omap44xx' block
above.
Nishant commented on this as well. The indentation was looking ugly
and I thought its better to have this BUG hunk separate. I prefer
it this way though if you really insist, i have to change it.
Also, while you're hear, maybe it's time to rename the current secondary
startup functions to match the new one. IOW omap4_..., omap4460_... and
omap5_...
Good idea. Will do it in a separate patch since these have been there in few
files.
Regards,
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 09/18] ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force wakeup method
On Thursday 04 April 2013 02:24 AM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
While waking up CPU from off state using clock domain force wakeup, restore
the CPU power state to ON state before putting CPU clock domain under
hardware control. Otherwise CPU wakeup might fail. The change is recommended
for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
devices first.
Sounds reasonable, but can you describe the weakness a little more?
IOW, what exactly happens if this is not done? It sounds like the CPU
might immediately go back to retention, but how does that happen unless
it does a WFI?
Its more of lock-up inside the hardware state machine and results
are UN-predictable. We have seen hard-locks most of the time where system
is just frozen. The hardware gets into wrong state machine if the power
domain state isn't restored. I will add this information to changelog.
Also, this sounds like a fix to me, and should probably be broken out
accordingly.
Yeah. You mean a separate patch from the series, right ? This patch
actually can be independently added.
In case you decide to apply it for the fixes branch, updated patch
at end of the email.
Regards,
Santosh
From a0cef44760d859b63a34603010f8c0621da4b8ab Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Fri, 8 Feb 2013 22:50:58 +0530
Subject: [PATCH] ARM: OMAP4+: PM: Restore CPU power state to ON with
clockdomain force wakeup method
While waking up CPU from off state using clock domain force wakeup, restore
the CPU power state to ON state before putting CPU clock domain under
hardware control. Otherwise CPU wakeup might fail. The change is recommended
for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
devices first.
As a result of weakness, lock-up is observed inside the hardware state
machine of local CPU PRCM and results are UN-predictable as per designers.
In software testing, we have seen hard-locks most of the time where system
gets frozen. With power domain state restored, system behaves correctly.
So update the code accordingly.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c |1 +
arch/arm/mach-omap2/omap-smp.c| 12 ++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 944e64a..9de47a7 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -131,6 +131,7 @@ static int omap4_enter_idle_coupled(struct cpuidle_device
*dev,
/* Wakeup CPU1 only if it is not offlined */
if (dev-cpu == 0 cpumask_test_cpu(1, cpu_online_mask)) {
clkdm_wakeup(cpu_clkdm[1]);
+ omap_set_pwrdm_state(cpu_pd[1], PWRDM_POWER_ON);
clkdm_allow_idle(cpu_clkdm[1]);
}
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 5b20165..8106e8d 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -83,6 +83,7 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu,
struct task_struct *
{
static struct clockdomain *cpu1_clkdm;
static bool booted;
+ static struct powerdomain *cpu1_pwrdm;
void __iomem *base = omap_get_wakeupgen_base();
/*
@@ -102,8 +103,10 @@ static int __cpuinit omap4_boot_secondary(unsigned int
cpu, struct task_struct *
else
__raw_writel(0x20, base + OMAP_AUX_CORE_BOOT_0);
- if (!cpu1_clkdm)
+ if (!cpu1_clkdm !cpu1_pwrdm) {
cpu1_clkdm = clkdm_lookup(mpu1_clkdm);
+ cpu1_pwrdm = pwrdm_lookup(cpu1_pwrdm);
+ }
/*
* The SGI(Software Generated Interrupts) are not wakeup capable
@@ -116,7 +119,7 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu,
struct task_struct *
* Section :
* 4.3.4.2 Power States of CPU0 and CPU1
*/
- if (booted) {
+ if (booted cpu1_pwrdm cpu1_clkdm) {
/*
* GIC distributor control register has changed between
* CortexA9 r1pX and r2pX. The Control Register secure
@@ -137,7 +140,12 @@ static int __cpuinit omap4_boot_secondary(unsigned int
cpu, struct task_struct *
gic_dist_disable();
}
+ /*
+* Ensure that CPU power state is set to ON to avoid CPU
+* powerdomain transition on wfi
+*/
clkdm_wakeup(cpu1_clkdm);
+ omap_set_pwrdm_state(cpu1_pwrdm, PWRDM_POWER_ON);
clkdm_allow_idle(cpu1_clkdm);
if (IS_PM44XX_ERRATUM(PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD)) {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Re: [PATCH v2 11/18] ARM: OMAP5: PM: Add L2 memory power down support
On Thursday 04 April 2013 02:28 AM, Kevin Hilman wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: When the entire MPUSS cluster is powered down in device off state, L2 cache memory looses it's content and hence while targetting such a state, l2 cache needs to be flushed to main memory. Add the necessary low power code support for the same. Acked-by: Nishanth Menon n...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/omap-secure.h |1 + arch/arm/mach-omap2/sleep_omap4plus.S | 21 + 2 files changed, 22 insertions(+) diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h index 1739468..a171a5a 100644 --- a/arch/arm/mach-omap2/omap-secure.h +++ b/arch/arm/mach-omap2/omap-secure.h @@ -47,6 +47,7 @@ #define OMAP4_MON_L2X0_PREFETCH_INDEX 0x113 #define OMAP5_MON_CACHES_CLEAN_INDEX0x103 #define OMAP5_MON_AUX_CTRL_INDEX0x107 +#define OMAP5_MON_L2AUX_CTRL_INDEX 0x104 this #define is not used in this patch. Yep. Will drop above hunk. I forgot to drop this one after dropping the L2X0 setting from last version. Its no longer needed on OMAP5 ES2.0. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 12/18] ARM: OMAP4: CPUidle: Avoid double idle driver registration
On Thursday 04 April 2013 02:33 AM, Kevin Hilman wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: OMAP4 CPUidle driver registration call is under a loop which leads to calling cpuidle_register_driver twice which is not intended. Fix it by moving the driver registration outside the loop. Reported-by: Nishanth Menon n...@ti.com Acked-by: Nishanth Menon n...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Looks good. I've already got a for_3.10/fixes/cpuidle branch going, so I'll apply this one there. ok. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 13/18] ARM: OMAP: CPUidle: Unregister drivere on device registration failure
On Thursday 04 April 2013 02:33 AM, Kevin Hilman wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: If the CPUidle device registration fails for some reason, we should unregister the driver on error path. Fix the code accordingly. Also when at it, check of the driver registration failure too. Acked-by: Nishanth Menon n...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Adding to my for_3.10/fixes/cpuidle branch. Thanks. regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 14/18] ARM: OMAP4: CPUidle: Make C-state description field more precise
On Thursday 04 April 2013 02:35 AM, Kevin Hilman wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: It is useful to know the CPU power state along with MPUSS power state in a supported C-state. Since the data is available via sysfs, one can avoid scrolling the source code for precise construction of C-state. Reported-by: Nishanth Menon n...@ti.com Acked-by: Nishanth Menon n...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Nice. Adding to for_3.10/fixes/cpuidle branch. Thanks. regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 16/18] ARM: OMAP4+: CPUidle: Deprecate use of omap4_mpuss_read_prev_context_state()
On Thursday 04 April 2013 03:07 AM, Kevin Hilman wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: Current OMAP4 CPUIdle driver is using omap4_mpuss_read_prev_context_state() function to check whether the MPU cluster lost context or not. Thanks to couple CPUIdle, cluster low power entry is almost guaranteed and hence the programmed cluster check is enough in idle exit path. The API was more of an optimization for corner cases, where if the cluster low power entry fails for some reason, the cluster context restore gets skipped. Moving forward, OMAP CPUidle drivers needs to be moved to drivers/idle/* once the PRM/CM code gets moved to drivers. This patch also reduces one dependency with platform code for idle driver movement. Acked-by: Nishanth Menon n...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Looks good, but I find the changelog a bit confusing. Below is a slightly modified patch (I only modified the changelog). If those changes are OK with you, I'll add it to my cpuidle branch as well. Looks good to me Kevin. Thanks for the change-log update. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 15/18] ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
On Thursday 04 April 2013 02:40 AM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
The OMAP5 idle driver can re-use most of OMAP4 CPUidle driver
implementation. Also the next derivative SOCs are going to re-use
the MPUSS so, same driver with minor updates can be re-used.
Prepare the code so that its easier to add CPUidle support for
OMAP5 devices.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index b8a22f0..ac6d526 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -1,7 +1,7 @@
/*
- * OMAP4 CPU idle Routines
+ * OMAP4PLUS CPU idle Routines
nit: s/PLUS/+/
in a few other places in this patch also.
yes. Will update that.
@@ -24,13 +24,13 @@
#include clockdomain.h
/* Machine specific information */
-struct omap4_idle_statedata {
+struct idle_statedata {
u32 cpu_state;
u32 mpu_logic_state;
u32 mpu_state;
};
-static struct omap4_idle_statedata omap4_idle_data[] = {
+static struct idle_statedata omap4_idle_data[] = {
{
.cpu_state = PWRDM_POWER_ON,
.mpu_state = PWRDM_POWER_ON,
@@ -53,11 +53,12 @@ static struct clockdomain *cpu_clkdm[NR_CPUS];
static atomic_t abort_barrier;
static bool cpu_done[NR_CPUS];
+static struct idle_statedata *state_ptr = omap4_idle_data[0];
The assignment at init time (from the next patch) should be done here
for 44xx, and the next patch can just add OMAP5 support.
You don't need that to be differentiated at init at this
patch since only OMAP4 is supported and static assignment takes care
of it. Next patch ofcouse we need to differentiate and hence added
the checks there.
Regards,
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 17/18] ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
On Thursday 04 April 2013 02:55 AM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
The OMAP5 idle driver can re-use OMAP4 CPUidle driver implementation thanks
to compatible MPUSS design.
Though unlike OMAP4, on OMAP5 devices, MPUSS CSWR (Close Switch
Retention) power states can be achieved with respective power states
on CPU0 and CPU1 power domain. This mode was broken on OMAP4 devices
because of hardware limitation.
I'm a bit confused by the description here.
I gather from the code that this means that CPU0 and CPU1 can hit CSWR
independently, correct?
They can be programmed independently without any ordering(like
CPU0 last etc), but the actual transition to the low power CSWR
happens together. Till that the first CPU hit WFI remains in WFI
state waiting for other CPU to hit WFI and then both transition
together.
Completely managed inside hardware.
Also there is no CPU low power entry order requirement like
master CPU etc for CSWR C-state, which is icing on the cake.
Even on secure devices?
Yes. On secure devices too. Actually since we don't loose context,
secure entry/exit doesn't come into picture.
Code makes use of voting scheme for cluster low power state to support
MPUSS CSWR C-state.
The voting scheme and associated locking should be better described
here, or commented in the code itself.
You are right. It deserves some description.
Supported OMAP5 CPUidle C-states:
C1 - CPU0 ON(WFI) + CPU1 ON(WFI) + MPUSS ON
C2 - CPU0 CSWR + CPU1 CSWR + MPUSS CSWR
C3 - CPU0 OFF + CPU1 OFF + MPUSS OSWR
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[...]
+static int omap_enter_idle_smp(struct cpuidle_device *dev,
+struct cpuidle_driver *drv,
+int index)
+{
+struct idle_statedata *cx = state_ptr + index;
+int cpu_id = smp_processor_id();
+unsigned long flag;
+
+clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
I think the CPUidle core handles the broadcast notification now.
Not in mainline yet. And those patches came after my patches and
I don't wanted un-necessary merge dependency, I avoided it. Its trivial
though to drop if from here once the idle next is merged.
+raw_spin_lock_irqsave(mpu_lock, flag);
+cx-mpu_state_vote++;
How about using an atomic_t and atomic_inc()/atomic_dec() instead, which
will avoid the need for a spinlock.
Spin lock is not just for the vote variable. I had atomics opps in first
version I gave it to product team. But they found a race condition in
where MPU power state was getting overwritten by other CPU.
Even with that, it still seems potentially racy. Do you need a memory
barrier here to be sure that any changes from another CPU are visible
here, and vice versa?
With locks, you don't need barriers since the updated copy is guaranteed.
Can you please elaborate on potential race ? I have given pretty hard
thought and didn't see any race which can be exposed with locks in place.
Regards,
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM3517 DaVinci EMAC Ethernet performance issues
Mugunthan V N, Thank you SO much for your repsonse. That did help enormously. # ./iperf-arm -i 1 -t 3000 -c 10.22.255.5 Client connecting to 10.22.255.5, TCP port 5001 TCP window size: 19.6 KByte (default) [ 3] local 10.22.0.17 port 40201 connected with 10.22.255.5 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 1.0 sec 8.88 MBytes 74.4 Mbits/sec [ 3] 1.0- 2.0 sec 10.7 MBytes 90.0 Mbits/sec [ 3] 2.0- 3.0 sec 8.24 MBytes 69.1 Mbits/sec [ 3] 3.0- 4.0 sec 8.54 MBytes 71.6 Mbits/sec [ 3] 4.0- 5.0 sec 7.23 MBytes 60.6 Mbits/sec [ 3] 5.0- 6.0 sec 11.2 MBytes 93.6 Mbits/sec [ 3] 6.0- 7.0 sec 10.6 MBytes 89.2 Mbits/sec [ 3] 7.0- 8.0 sec 10.1 MBytes 84.9 Mbits/sec [ 3] 8.0- 9.0 sec 7.76 MBytes 65.1 Mbits/sec [ 3] 9.0-10.0 sec 4.66 MBytes 39.1 Mbits/sec [ 3] 10.0-11.0 sec 6.79 MBytes 57.0 Mbits/sec [ 3] 11.0-12.0 sec 7.30 MBytes 61.3 Mbits/sec [ 3] 12.0-13.0 sec 7.01 MBytes 58.8 Mbits/sec We're still not at 100%, but the exhorbitant timeouts are gone, and we're back to bandwidth we can live with for the time being. Thanks! The oddity is the patch you shared is one that I actually suggested to myself in my code comments from nearly a year ago. I guess I needed someone to remind me of my own notes! :-P See the comment in that line from http://article.gmane.org/gmane.linux.ports.arm.omap/79787 ??? Since that fix appears to help, please review the other contents of that draft patch I posted back then. Perhaps there are a few other good things that can be applied from there to the driver today? The biggest change I proposed was removing the redundant emac_rx_alloc() function and replacing it with the standard netdev_alloc_skb_ip_align() instead. I also took a look at improving the detection and handling of some potential errors. To be honest, I never saw any of my dev_err() calls hit, but that's not to say that they could never do so. Thanks again! - Original Message - From: Mugunthan V N mugunthan...@ti.com To: CF Adad cfa...@rocketmail.com Cc: linux-omap@vger.kernel.org linux-omap@vger.kernel.org; da...@davemloft.net da...@davemloft.net Sent: Thursday, April 4, 2013 4:32 AM Subject: Re: AM3517 DaVinci EMAC Ethernet performance issues On 4/4/2013 7:50 AM, CF Adad wrote: We've done network captures on our link, and the problem is very strange. The iperf client transmits data quickly and steadily for a while, but then all the sudden just stops. In the captures you can see an ACK come back from the server for the frame that was just sent, but then instead of immediately sending the next one it just sits there for sometimes several seconds. Then, it suddenly picks back up and starts running again. It's as though it just paused due to lack of data. The same kind of issue was observed in different SoC with Davinci EMAC and resolved by the patch below. Can you make sure the patch is applied in your kernel and take the performance again. https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=7e51cde276ca820d526c6c21cf8147df595a36bf Regards Mugunthan V N -- To unsubscribe from this list: send the line unsubscribe 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 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
On Thursday 04 April 2013 04:22 AM, Kevin Hilman wrote: Hi Santosh, Santosh Shilimkar santosh.shilim...@ti.com writes: Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted earlier (March 1st 2013). Patch-set incorporates comments from Nishant Menon (Thanks for review NM) and his acked-by tags. I would like to get this queued for 3.10 merge window if you are ok with the series. I did a review of this series with several comments on the individual patches. Thanks a lot Kevin. I have addressed all the comments and have updated patches ready. I've already queued most of the CPUidle fixes/cleanups in my for_3.10/cleanup/cpuidle branch and will get that to Tony soon. For the rest, I suggest probably breaking it up into cleanup/consolidation stuff and then OMAP5 support. The latter will depend on all the OMAP5 data/headers but the cleanup/consolidation stuff could be merged sooner (but probably a bit late for v3.10 now.) I have already split the patch-set into 'consolidation' and 'OMAP5 support' since it was straight forward. Need to just build the branches on top of your branches. So waiting for you to update your 'for_3.10/*' branches. For the merge, its your call:) As you said OMAP5 support(couple of patches) has a dependency on OMAP5 data files. I will at least make the branches ready on top of yours. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] smiapp-pll: Take existing divisor into account in minimum divisor check
Hi Sakari, (CC'ing linux-omap and Rajendra Nayak) On Sunday 31 March 2013 23:07:42 Sakari Ailus wrote: Hi Pali and Laurent, Laurent: Pali has been working to get N900 working again with (almost) mainline kernel. On Sun, Mar 31, 2013 at 12:03:39PM +0200, Pali Rohár wrote: On Sunday 31 March 2013 10:44:08 Sakari Ailus wrote: Required added multiplier (and divisor) calculation did not take into account the existing divisor when checking the values against the minimum divisor. Do just that. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- Hi Pali, This looks like a bug in the PLL calculator. Could you try if this patch fixes it? It's written on an N950 and also is fully untested. :) If it works for you I'll submit it to mainline as well. Happy Easter! :) drivers/media/i2c/smiapp-pll.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) Hi, now I tried smiapp again with 3.9 kernel on n900 and it failing with this error messae (smiapp driver is not loaded): [ 22.164001] omap3isp omap3isp: Revision 2.0 found [ 22.166900] omap3isp omap3isp: clk_set_rate for cam_mclk failed I bisected git commit 6d1aa02f10497b138e01ebe6eafabd6071729334 omap3isp: Set cam_mclk rate directly and after reverting it 3.9 kernel started loading smiapp driver. When I applied your patch This shouldn't happen. Laurent: did you test the patch on 3430 back then? I only tested 3630. AFAIR you did, but I don't remember for sure. I can't remember for sure, but it seems I haven't, or at least not properly :-( I don't have time to debug this in the coming days unfortunately. If this turns out to be a non-trivial issue then it's probably good to continue on linux-omap. It might not be too complex to fix, but linux-omap is a good idea nonetheless. Could you try debugging the problem ? The starting point is clk_set_rate() in drivers/clk/clk.c. My guess is that clk_calc_new_rates() returns NULL, and that it does so because it walks to clock tree up to dpll4_m5x2_ck which has neither a round_rate operation nor the CLK_SET_RATE_PARENT flag set. Could you please confirm that ? I wonder if the dpll4_m5x2_ck clock (in arch/arm/mach-omap2/cclock3xxx_data.c) should just have the CLK_SET_RATE_PARENT flag set as the dpll4_m5x2_ck_3630 clock. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 01/11] usb: phy: Add APIs for runtime power management
On Thu, 4 Apr 2013, Felipe Balbi wrote: Some subsystems handle this issue by calling pm_runtime_get_sync() before probing a driver and pm_runtime_put_sync() after unbinding the driver. If the driver is runtime-PM-enabled, it then does its own put_sync near the end of its probe routine and get_sync in its release routine. sounds a bit 'fishy' to me... So a separate entity would call pm_runtime_get_sync(), even when we don't have registered dev_pm_ops, I don't know what you mean by separate entity. The PHY's subsystem would handle this. After all, the subsystem has to handle registering the PHY in the first place. If the PHY doesn't have a dev_pm_ops, why are you talking about doing runtime PM on it? That doesn't make any sense. then drivers need to check if runtime_pm is enabled and call pm_runtime_put*() conditionally before returning from probe(). One They don't have to check. If CONFIG_PM_RUNTIME isn't set or the target is runtime-PM-disabled then pm_runtime_put* is essentially a no-op (in the disabled case it decrements the usage counter but doesn't do anything else). One possible complication I did not mention: The scheme described above assumes the device that uses the PHY will always be registered on the same type of bus. If the device can be used on multiple bus types (and hence in multiple subsystems) then things aren't so simple, because some of the subsystems might support runtime PM and others might not. (You may very well run into this problem with USB controllers that are sometimes on a PCI bus and sometimes on a platform bus.) In this case, the driver needs to adapt to the subsystem's capabilities. Presumably the bus-glue part of the driver takes care of this. remove, we might have another issue: device is already runtime_suspended (due to e.g. autosuspend) when module is removed, a call to pm_runtime_put_sync() will be unbalanced. No ? No. I left out some of the details. For one thing, the subsystem is careful to do a runtime resume before calling the driver's remove method. (Also, if you look over my original description carefully, you'll see that there are no unbalanced calls -- even if the device is already runtime suspended when the driver is unbound.) For another, the subsystem needs to check before calling the driver's runtime-PM methods. There are two brief windows during which the driver isn't in charge of the device even though dev-driver is set. Those windows occur in the subsystem's probe routine (before it calls the driver's probe method) and in the subsystem's remove routine (after it calls the driver's remove method). At such times, the subsystem's runtime-PM handlers must be careful _not_ to call the driver's runtime-PM routines. May be i am misinterpreting !! If PHYs are runtime-PM enabled (PHY probe calls *runtime_enable*), then the consumers need to call pm_runtime_get_sync whever they want to access PHY. No, because in addition to being runtime-PM enabled, the PHY should automatically be runtime resumed when the consumer registers itself as a user of the PHY. Therefore the consumer doesn't need to do anything at all -- which is good for consumers that aren't runtime-PM aware. Alright, so here's my understanding: I suggested letting e.g. DWC3 enable the PHY's runtime_pm; Alan said that it could be done before that so that DWC3 sees an enabled PHY during probe. Basically right. Help me to understand the overall situation a little better: What code registers the PHY initially? What routine does the DWC3 driver call to register itself as a consumer of the PHY? Likewise, what routine does it call to unregister itself? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
* Rajendra Nayak rna...@ti.com [130403 22:25]: On Thursday 04 April 2013 05:12 AM, Tony Lindgren wrote: How about just add a minimal drivers/clk/omap/clk-xyz.c that takes the configuration from DT and is based on the binding we already have in Documentation/devicetree/bindings/clock/clock-bindings.txt? Then as we add new bindings there we can drop them from current cclock44xx_data.c, no? That is after omap4 is DT only.. The patch just provides an alternative for clkdev mapping in case of DT. Are you suggesting we move all *clock data* related to auxclks (and eventually all clocks) into DT? Well I think we should have a driver that can take any defined clock binding from DT at least for boottime clocks. We need at least the timer clocks early during the boot, and probably the root device like MMC or possibly Ethernet depending on the board. The rest of the huge amount of clocks we can just load from /lib/firmware after mounting intramfs or root on MMC. As long as we can define any boottime clock in DT also, loading the rest of the clock data from /lib/firmware should not cause issues with booting. And as we get the clocks moved, we can drop them from cclock44xx_data.c. AFAIK the new driver can just clk_get the parent clocks so those can stay in cclock44xx_data.c for now? So basically we can do the same as we are already doing with pinctrl-single.c, but with addition of loading large amounts of data from /lib/firmware. And eventually we can do the same with hwmod too. Regarding the readability issue, we now have preprocessing support for .dts files merged AFAIK, so they can be as readable as data structures :) We have discussed this multiple times in the past, and moving 250 clock nodes with each needing multiple register offsets, masks, shifts etc into DT makes it completely un-readable. For me, having a way for devices to reference a clock that they use for a device using DT makes sense, but not moving all clock data into dts files. Yes that's why we should also support loading clocks from /lib/firmware. Naturally the parent clocks can be allocated by the clock driver(s) at least initially. But the main reason I think we should do this is so we get out of the flame path with these huge data files for every new SoC. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/11] usb: dwc3/xhci/phy: Enable runtime power management
On Thu, Apr 04, 2013 at 01:02:45PM +0530, Vivek Gautam wrote: On Thu, Apr 4, 2013 at 12:40 PM, Felipe Balbi ba...@ti.com wrote: On Thu, Apr 04, 2013 at 10:34:57AM +0530, Vivek Gautam wrote: Hi Sarah, On Wed, Apr 3, 2013 at 10:57 PM, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: Question: Do you still need this patch for 3.10? Felipe's 'next' is closed for 3.10, so this series won't be making it to 3.10 now, as a whole. :-( right, besides we're still discussing what to do with the whole PHY part, right ? Right ofcourse. :-) Ok, so it sounds like I shouldn't merge that patch for 3.10. Please include that patch in your next round of revisions instead. And now I'm glad I'm slow. :) Sarah Sharp -- To unsubscribe from this list: send the line unsubscribe 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 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
* Roger Quadros rog...@ti.com [130404 00:39]:
On 04/04/2013 02:42 AM, Tony Lindgren wrote:
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -27,6 +27,7 @@
#include linux/clk-private.h
#include linux/clkdev.h
#include linux/io.h
+#include linux/of.h
#include soc.h
#include iomap.h
@@ -1663,6 +1664,40 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, cpufreq_ck, dpll_mpu_ck, CK_443X),
};
+static struct clk *scrm_clks[] = {
+ auxclk0_ck,
+ auxclk1_ck,
+ auxclk2_ck,
+ auxclk3_ck,
+ auxclk4_ck,
+ auxclk5_ck,
+};
Hmm I don't like the idea of specifying the auxclk both in the
cclock44xx_data.c and in DT..
Right, but till we have all clocks moved to DT we only need this
approach for general purpose clocks that are not mapped to devices
by hwmod.
For v3.10, let's just make sure that USB works with DT as then
after v3.10 we can make omap4 DT only and get rid of estimated
7K lines of code and data. I guess this is the last piece missing
for that, or are we also missing something else?
Can't you set up a clock alias for your device so it can find the
auxclk when requesting it with the dev entry?
For the DT clock driver if needed for v3.10, how about just do a
minimal drivers/clock/omap/ that uses the standard binding?
Then that driver can just do clk_get() from cclock44xx_data.c
for now? And then later on we'll just move all the clocks to a
combination of DT + /lib/firmware.
e.g. auxclk are required to be specified in DT nodes for USB PHY.
Without this we can't get USB host working on Panda.
OK. So if the USB PHY has a dev entry, can't you just set up a
clock alias in struct omap_clk omap44xx_clks[] for it?
As Rajendra points out, it seems moving entire clock data to DT is not
going to happen soon. So this is the simplistic way things can work.
Right but seems like we can get started there without moving
them all at once.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
On Thursday 04 April 2013 08:04 PM, Santosh Shilimkar wrote: On Thursday 04 April 2013 04:22 AM, Kevin Hilman wrote: Hi Santosh, Santosh Shilimkar santosh.shilim...@ti.com writes: Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted earlier (March 1st 2013). Patch-set incorporates comments from Nishant Menon (Thanks for review NM) and his acked-by tags. I would like to get this queued for 3.10 merge window if you are ok with the series. I did a review of this series with several comments on the individual patches. Thanks a lot Kevin. I have addressed all the comments and have updated patches ready. I've already queued most of the CPUidle fixes/cleanups in my for_3.10/cleanup/cpuidle branch and will get that to Tony soon. For the rest, I suggest probably breaking it up into cleanup/consolidation stuff and then OMAP5 support. The latter will depend on all the OMAP5 data/headers but the cleanup/consolidation stuff could be merged sooner (but probably a bit late for v3.10 now.) I have already split the patch-set into 'consolidation' and 'OMAP5 support' since it was straight forward. Need to just build the branches on top of your branches. So waiting for you to update your 'for_3.10/*' branches. For the merge, its your call:) As you said OMAP5 support(couple of patches) has a dependency on OMAP5 data files. I will at least make the branches ready on top of yours. After looking at your tree, looks like the branches are already there. Idle branch name is not for_3.10/fixes/cpuidle though :) So I created 'for_3.10/omap_pm-cleanup' and 'for_3.10/omap5_pm_v2' and pushed on my git tree [1] in case you would like to have a look. I briefly tested them on OMAP4 device with CPUidle enabled and they seems to work fine. Will do OMAP5 testing tomorrow and then post the updated patches on list. Regards, Santosh [1] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
* Santosh Shilimkar santosh.shilim...@ti.com [130404 04:15]:
+ Tero and few more TI folks,
On Thursday 04 April 2013 01:12 AM, Paul Walmsley wrote:
Hi Santosh
On Wed, 3 Apr 2013, Santosh Shilimkar wrote:
Thes patchset has already missed last couple of merge windows and its the
biggest bottleneck in getting OMAP5 booting from mainline. So I request
you to please have a look it quickly so that Tony can line that up for
3.10.
Looks like there are a few minor issues with the patches based on a quick
look. I'll post those to the list shortly; they should be easy to fix.
But those issues aren't my real concern with this series.
What's harder to fix are the underlying process issues. My main concern
is that these patches add almost 9,000 lines of code and data. We've
received clear guidance from the upstream ARM SoC maintainers that any
significant new additions need to be balanced with moving a similar number
of lines of code and data out of arch/arm/{plat-,mach-}* into drivers/.
(Or the new patches should be accompanied with patches that show obvious
progress towards the goal of moving code and data out of
arch/arm/{plat-,mach-}*.) We need to see more help from TI on the
prerequisites for this cleanup process.
I agree that we are not making faster progress but as part of the
$subject series itself, for DT only build, we removed around ~4000
lines of data from hwmod. After the merge window, we can trim
the AM33XX and then later OMAP4 when it is made DT only support.
That should give us another 6000 lines of negative diff.
At the same time removal of MUX data for OMAP4 should be
around 2000 lines of negative diff.
Can't we already trim the am33xx hwmod data after your patches for
v3.10 as am33xx is already DT only? Unfortunately we cannot create
negative diffstat in other ways for v3.10 merge window as we cannot
make omap4 DT only just quite yet.
FYI, I have some trivial patches here to drop board and mux support for
omap4 once we can make omap4 DT only, so that will be about 3000 lines
of reduction with estimated 1000 - 2000 lines once I go through the
unneeded platform init code for omap4 for things like MMC and USB.
The rest of the clean-up issues I believe we all agree, we just need
to get it done so we can avoid getting flamed for every new SoC for
the huge data files. To fix the data issue for good, it seems that we can
get started moving both the clock and hwmod data to simple drivers
that can get clocks and hwmod data both from DT and /lib/firmware.
It also seems that we don't need to move all the data at once, which
makes the task easier.
Cheers,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
On Thursday 04 April 2013 10:22 PM, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [130404 04:15]:
+ Tero and few more TI folks,
On Thursday 04 April 2013 01:12 AM, Paul Walmsley wrote:
Hi Santosh
On Wed, 3 Apr 2013, Santosh Shilimkar wrote:
Thes patchset has already missed last couple of merge windows and its the
biggest bottleneck in getting OMAP5 booting from mainline. So I request
you to please have a look it quickly so that Tony can line that up for
3.10.
Looks like there are a few minor issues with the patches based on a quick
look. I'll post those to the list shortly; they should be easy to fix.
But those issues aren't my real concern with this series.
What's harder to fix are the underlying process issues. My main concern
is that these patches add almost 9,000 lines of code and data. We've
received clear guidance from the upstream ARM SoC maintainers that any
significant new additions need to be balanced with moving a similar number
of lines of code and data out of arch/arm/{plat-,mach-}* into drivers/.
(Or the new patches should be accompanied with patches that show obvious
progress towards the goal of moving code and data out of
arch/arm/{plat-,mach-}*.) We need to see more help from TI on the
prerequisites for this cleanup process.
I agree that we are not making faster progress but as part of the
$subject series itself, for DT only build, we removed around ~4000
lines of data from hwmod. After the merge window, we can trim
the AM33XX and then later OMAP4 when it is made DT only support.
That should give us another 6000 lines of negative diff.
At the same time removal of MUX data for OMAP4 should be
around 2000 lines of negative diff.
Can't we already trim the am33xx hwmod data after your patches for
v3.10 as am33xx is already DT only? Unfortunately we cannot create
negative diffstat in other ways for v3.10 merge window as we cannot
make omap4 DT only just quite yet.
Yes we can and I can take a stab it tomorrow. The only thing is I
might need some support for testing but thats manageable. Will
take a stab at it tomorrow and if everything goes well, post a
patch for smae.
FYI, I have some trivial patches here to drop board and mux support for
omap4 once we can make omap4 DT only, so that will be about 3000 lines
of reduction with estimated 1000 - 2000 lines once I go through the
unneeded platform init code for omap4 for things like MMC and USB.
Cool.
The rest of the clean-up issues I believe we all agree, we just need
to get it done so we can avoid getting flamed for every new SoC for
the huge data files. To fix the data issue for good, it seems that we can
get started moving both the clock and hwmod data to simple drivers
that can get clocks and hwmod data both from DT and /lib/firmware.
It also seems that we don't need to move all the data at once, which
makes the task easier.
Agree.
regards,
santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 08/18] ARM: OMAP5: PM: Add CPU power off in hotplug path
Santosh Shilimkar santosh.shilim...@ti.com writes:
On Thursday 04 April 2013 02:19 AM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
Add power management code to handle the CPU off mode to enable CPUP hotplug
mode for OMAP5 devices. Separate suspend finisher is used for
OMAP5(Cortex-A15)
because it doesn't use SCU power status register and external PL310 L2 cache
which makes code flow bit different.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[...]
@@ -436,14 +445,21 @@ int __init omap4_mpuss_init(void)
if (cpu_is_omap44xx()) {
omap_pm_ops.finish_suspend = omap4_finish_suspend;
+ omap_pm_ops.hotplug_restart = omap_secondary_startup;
omap_pm_ops.resume = omap4_cpu_resume;
omap_pm_ops.scu_prepare = scu_pwrst_prepare;
cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
} else if (soc_is_omap54xx()) {
+ omap_pm_ops.finish_suspend = omap5_finish_suspend;
+ omap_pm_ops.hotplug_restart = omap5_secondary_startup;
cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
enable_mercury_retention_mode();
}
+ /* Over-write the OMAP4 hook to take care of ROM BUG */
+ if (cpu_is_omap446x())
+ omap_pm_ops.hotplug_restart = omap_secondary_startup_4460;
A couple nits...
I think this would go better at the end of the 'if omap44xx' block
above.
Nishant commented on this as well. The indentation was looking ugly
and I thought its better to have this BUG hunk separate. I prefer
it this way though if you really insist, i have to change it.
I insist.
Also, while you're hear, maybe it's time to rename the current secondary
startup functions to match the new one. IOW omap4_..., omap4460_... and
omap5_...
Good idea. Will do it in a separate patch since these have been there in few
files.
OK.
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 17/18] ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
Santosh Shilimkar santosh.shilim...@ti.com writes:
On Thursday 04 April 2013 02:55 AM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
The OMAP5 idle driver can re-use OMAP4 CPUidle driver implementation thanks
to compatible MPUSS design.
Though unlike OMAP4, on OMAP5 devices, MPUSS CSWR (Close Switch
Retention) power states can be achieved with respective power states
on CPU0 and CPU1 power domain. This mode was broken on OMAP4 devices
because of hardware limitation.
I'm a bit confused by the description here.
I gather from the code that this means that CPU0 and CPU1 can hit CSWR
independently, correct?
They can be programmed independently without any ordering(like
CPU0 last etc), but the actual transition to the low power CSWR
happens together. Till that the first CPU hit WFI remains in WFI
state waiting for other CPU to hit WFI and then both transition
together.
Completely managed inside hardware.
OK, elaborating this in the changelog would be helpful. Use the will I
understand this changelog in a year rule to see if the changelog is
detailed enough. Or better, will Kevin understand this changelog in a
year. (hint: the answer is usually no.) ;)
Also there is no CPU low power entry order requirement like
master CPU etc for CSWR C-state, which is icing on the cake.
Even on secure devices?
Yes. On secure devices too. Actually since we don't loose context,
secure entry/exit doesn't come into picture.
Code makes use of voting scheme for cluster low power state to support
MPUSS CSWR C-state.
The voting scheme and associated locking should be better described
here, or commented in the code itself.
You are right. It deserves some description.
Supported OMAP5 CPUidle C-states:
C1 - CPU0 ON(WFI) + CPU1 ON(WFI) + MPUSS ON
C2 - CPU0 CSWR + CPU1 CSWR + MPUSS CSWR
C3 - CPU0 OFF + CPU1 OFF + MPUSS OSWR
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[...]
+static int omap_enter_idle_smp(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ struct idle_statedata *cx = state_ptr + index;
+ int cpu_id = smp_processor_id();
+ unsigned long flag;
+
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
I think the CPUidle core handles the broadcast notification now.
Not in mainline yet. And those patches came after my patches and
I don't wanted un-necessary merge dependency, I avoided it. Its trivial
though to drop if from here once the idle next is merged.
OK.
I believe that stuff is already queued, no? Maybe ahave this as an
add-on separate patch that can be used for your loal testing, but does
not go upstream.
I would only include this if you're sure the other series is not going
upstream.
+ raw_spin_lock_irqsave(mpu_lock, flag);
+ cx-mpu_state_vote++;
How about using an atomic_t and atomic_inc()/atomic_dec() instead, which
will avoid the need for a spinlock.
Spin lock is not just for the vote variable. I had atomics opps in first
version I gave it to product team. But they found a race condition in
where MPU power state was getting overwritten by other CPU.
Even with that, it still seems potentially racy. Do you need a memory
barrier here to be sure that any changes from another CPU are visible
here, and vice versa?
With locks, you don't need barriers since the updated copy is guaranteed.
It's guaranteed because the spinlock implementation uses barriers.
Can you please elaborate on potential race ? I have given pretty hard
thought and didn't see any race which can be exposed with locks in place.
I was referring to using atomic ops. With atomic ops, you'd need an
explicit barrier (which you're getting inside the spinlock
implementation)
That being said, I have not thought through all the corner cases as you
have, so I'll defer to your choice (as long as it's well documented.)
If you decide to stick with spinlocks, be sure to describe all of what
the spinlock is protecting, and why.
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 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
Santosh Shilimkar santosh.shilim...@ti.com writes: On Thursday 04 April 2013 08:04 PM, Santosh Shilimkar wrote: On Thursday 04 April 2013 04:22 AM, Kevin Hilman wrote: Hi Santosh, Santosh Shilimkar santosh.shilim...@ti.com writes: Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted earlier (March 1st 2013). Patch-set incorporates comments from Nishant Menon (Thanks for review NM) and his acked-by tags. I would like to get this queued for 3.10 merge window if you are ok with the series. I did a review of this series with several comments on the individual patches. Thanks a lot Kevin. I have addressed all the comments and have updated patches ready. I've already queued most of the CPUidle fixes/cleanups in my for_3.10/cleanup/cpuidle branch and will get that to Tony soon. For the rest, I suggest probably breaking it up into cleanup/consolidation stuff and then OMAP5 support. The latter will depend on all the OMAP5 data/headers but the cleanup/consolidation stuff could be merged sooner (but probably a bit late for v3.10 now.) I have already split the patch-set into 'consolidation' and 'OMAP5 support' since it was straight forward. Need to just build the branches on top of your branches. So waiting for you to update your 'for_3.10/*' branches. For the merge, its your call:) As you said OMAP5 support(couple of patches) has a dependency on OMAP5 data files. I will at least make the branches ready on top of yours. After looking at your tree, looks like the branches are already there. Idle branch name is not for_3.10/fixes/cpuidle though :) oh, sorry. I changed it to 'cleanup'. So I created 'for_3.10/omap_pm-cleanup' and 'for_3.10/omap5_pm_v2' and pushed on my git tree [1] in case you would like to have a look. I briefly tested them on OMAP4 device with CPUidle enabled and they seems to work fine. Will do OMAP5 testing tomorrow and then post the updated patches on list. Perfect, 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
[PATCH] ARM: dts: OMAP4+: Correct L3 interrupts
The L3 interrupt numbers are incorrect for OMAP4+ and are conflicting
with some of the timer interrupts causing the allocation of timer
interrupts to fail.
The problem is caused by adding 32 to the interrupt number for the L3
interrupts to account for per processor interrupts (PPI) and software
generated interrupts (SGI) which typically are mapped to the first 32
interrupts in the ARM GIC. This is not necessary because the first
parameter of the ARM GIC interrupt property specifies the GIC interrupt
type (ie. SGI, PPI, etc). Hence, fix the interrupt number fo the L3
interrupts by substracting 32.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
Please note that this problem is observed in Benoit's for_3.10/dts branch [1].
[1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git
arch/arm/boot/dts/omap4.dtsi |4 ++--
arch/arm/boot/dts/omap5.dtsi |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 3329140..3ae6a3f 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -97,8 +97,8 @@
reg = 0x4400 0x1000,
0x4480 0x2000,
0x4500 0x1000;
- interrupts = 0 41 0x4,
-0 42 0x4;
+ interrupts = 0 9 0x4,
+0 10 0x4;
counter32k: counter@4a304000 {
compatible = ti,omap-counter32k;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index f4c71d9..86f784e 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -90,8 +90,8 @@
reg = 0x4400 0x2000,
0x4480 0x3000,
0x4500 0x4000;
- interrupts = 0 41 0x4,
-0 42 0x4;
+ interrupts = 0 9 0x4,
+0 10 0x4;
counter32k: counter@4ae04000 {
compatible = ti,omap-counter32k;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP2+: GPMC updates
* Jon Hunter jon-hun...@ti.com [130403 19:25]: On 04/03/2013 04:40 PM, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [130402 10:00]: The following changes since commit dca3a783400a18e2bf4503b1d4a85c4d0ca1a7e4: Merge commit '31d9adca82ce65e5c99d045b5fd917c702b6fce3' into tmp (2013-04-01 14:33:50 -0500) are available in the git repository at: git://github.com/jonhunter/linux.git omap-gpmc-for-v3.10 for you to fetch changes up to c67bd6e7cad2160c3bbfa2ac2bd954f918301c23: ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes (2013-04-01 14:53:50 -0500) Adds GPMC DT support for NOR flash and Ethernet and includes various GPMC cleans-up and fixes. This series is dependent on commit 7185684 (ARM: OMAP: use consistent error checking) from RMK's clean-up branch and commit 31d9adc (ARM: OMAP2+: Fix broken gpmc support). Looks good except it adds a new warning: arch/arm/mach-omap2/gpmc.c: In function ‘gpmc_read_timings_dt’: arch/arm/mach-omap2/gpmc.c:1324: warning: ‘p’ may be used uninitialized in this function Can you please take a look? No problem. I did not see get this warning, but I believe that there is a bug that needed to be fixed. Can you try the below? Thanks yes that works. Pulling into omap-for-v3.10/gpmc. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] ARM: OMAP: DMTIMER updates for v3.10
* Jon Hunter jon-hun...@ti.com [130319 10:42]: Includes: - A couple fixes for DMTIMER context loss handling. - Populating DMTIMER errata when booting with device-tree. - A new function for requesting a DMTIMER by device-tree node. Based upon v3.9-rc3. Tested on OMAP5912 OSK, OMAP2420 H4, OMAP3430 SDP, OMAP4430 Blaze and AM335x EVM. Testing includes ... 1. Booting kernel on above boards 2. Testing of various DMTIMER request APIs 3. Testing the timer overflow and match interrupts. 4. Using different clock sources to operate the timer with. Jon Hunter (4): ARM: OMAP: Force dmtimer restore if context loss is not detectable ARM: OMAP: Add function to request timer by node ARM: dts: OMAP2+: Update DMTIMER compatibility property ARM: OMAP2+: Populate DMTIMER errata when using device-tree NeilBrown (1): ARM: OMAP: Simplify dmtimer context-loss handling .../devicetree/bindings/arm/omap/timer.txt | 17 +- arch/arm/boot/dts/am33xx.dtsi | 14 +- arch/arm/boot/dts/omap2.dtsi | 22 +- arch/arm/boot/dts/omap2420.dtsi|2 +- arch/arm/boot/dts/omap2430.dtsi|2 +- arch/arm/boot/dts/omap3.dtsi | 24 +- arch/arm/boot/dts/omap4.dtsi | 22 +- arch/arm/boot/dts/omap5.dtsi | 22 +- arch/arm/mach-omap2/timer.c|7 +- arch/arm/plat-omap/dmtimer.c | 241 arch/arm/plat-omap/include/plat/dmtimer.h |1 + 11 files changed, 220 insertions(+), 154 deletions(-) For all these it sounds like it's best that Benoit queues them with the .dts changes: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot
On 10:43-20130404, Rajendra Nayak wrote:
On Thursday 04 April 2013 08:22 AM, Nishanth Menon wrote:
On 11:47-20130403, Kevin Hilman wrote:
Nishanth Menon n...@ti.com writes:
[...]
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index afa509a..5b147ef 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -49,6 +49,11 @@ static void __init omap_generic_init(void)
omap4_panda_display_init_of();
else if (of_machine_is_compatible(ti,omap4-sdp))
omap_4430sdp_display_init_of();
+
+ if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
+ struct platform_device_info devinfo = { .name = cpufreq-cpu0,
};
+ platform_device_register_full(devinfo);
+ }
Rather than adding new clkdev nodes below, how about using clk add_alias
here?
Thanks for pointing this out, I spend some time implementing such a
scheme and following is my opinion:
Summary:
There is one major problem which forces us to introduce this clock
hack - clock nodes are not in device tree yet. Yes, clock add alias
There's already a patch floating around for this..
https://lkml.org/lkml/2013/4/2/84
Not really. Try on OMAP4 PandaBoard:
Based on
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.10/dts d114294 ARM: dts: AM33XX: Corrects typo in interrupt field in SPI
node
+ the patch https://patchwork.kernel.org/patch/2335671/ applied
Pandaboard 4 Log: http://pastebin.com/qsdsbv7p
The Patch does not even work, unless there is un-documented patch
dependencies!
Secondly, even if it did work, it would still continue to need yet another
hack[1] - I am agree with Tony in his discussion in
http://marc.info/?t=13637032569r=1w=2
*if* we are moving clock to DT, we should move the data to DT as well -
similar to what other platforms do - highbank as far as i can quickly
see. (drivers/clk/clk-highbank.c and arch/arm/boot/dts/ecx-common.dtsi
as examples). Clk alias might have been a solution, but in this case,
clk add alias (as I indicated in this thread is not really worth the
effort for the mess of code it creates for cpu clock).
[1]
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index dd8f58f..9282b4c 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -635,4 +635,9 @@
ti,has-mailbox;
};
};
+
+ dpll_mpu: scrmclks {
+ compatible = ti,omap4-clock;
+ #clock-cells = 1;
+ };
};
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index cccf39a..1587a5f 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -21,6 +21,8 @@
80 1313000
1008000 1375000
;
+ clocks = dpll_mpu;
+ clock-names = cpu;
clock-latency = 30; /* From legacy driver */
};
};
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index afa509a..5b147ef 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -49,6 +49,11 @@ static void __init omap_generic_init(void)
omap4_panda_display_init_of();
else if (of_machine_is_compatible(ti,omap4-sdp))
omap_4430sdp_display_init_of();
+
+ if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
+ struct platform_device_info devinfo = { .name = cpufreq-cpu0,
};
+ platform_device_register_full(devinfo);
+ }
}
#ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index a93617b..ba4562a 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -1675,6 +1675,7 @@ static struct clk *dt_clks[] = {
auxclk3_ck,
auxclk4_ck,
auxclk5_ck,
+ dpll_mpu_ck,
};
static struct clk_onecell_data clock_data;
--
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
[GIT PULL 1/3] omap usb platform init changes for v3.10 merge window
The following changes since commit 1f0972f5b05a674d73e4eb314fa1b6c78e37aef1: usb: phy: nop: Add some parameters to platform data (2013-03-18 11:13:54 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/usb-signed for you to fetch changes up to 2e5f78aeceb6f203b514ca03a48e3fd056025524: ARM: dts: omap3-beagle: Add USB Host support (2013-04-02 10:00:04 -0700) EHCI platform data related changes for v3.10 merge window. These are needed for the USB PHY support, and are based on commit 1f0972f5 from Felipe Balbi's tree as agreed on the mailing lists. Roger Quadros (20): ARM: OMAP2+: omap-usb-host: Add usbhs_init_phys() ARM: OMAP2+: omap4panda: Adapt to ehci-omap changes ARM: OMAP3: Beagle: Adapt to ehci-omap changes ARM: OMAP3: 3430SDP: Adapt to ehci-omap changes ARM: OMAP3: 3630SDP: Adapt to ehci-omap changes ARM: OMAP: AM3517crane: Adapt to ehci-omap changes ARM: OMAP: AM3517evm: Adapt to ehci-omap changes ARM: OMAP3: cm-t35: Adapt to ehci-omap changes ARM: OMAP3: cm-t3517: Adapt to ehci-omap changes ARM: OMAP: devkit8000: Adapt to ehci-omap changes ARM: OMAP3: igep0020: Adapt to ehci-omap changes ARM: OMAP3: omap3evm: Adapt to ehci-omap changes ARM: OMAP3: omap3pandora: Adapt to ehci-omap changes ARM: OMAP3: omap3stalker: Adapt to ehci-omap changes ARM: OMAP3: omap3touchbook: Adapt to ehci-omap changes ARM: OMAP3: overo: Adapt to ehci-omap changes ARM: OMAP: zoom: Adapt to ehci-omap changes ARM: dts: OMAP4: Add HS USB Host IP nodes ARM: dts: OMAP3: Add HS USB Host IP nodes ARM: dts: omap3-beagle: Add USB Host support arch/arm/boot/dts/omap3-beagle.dts | 71 + arch/arm/boot/dts/omap3.dtsi | 31 ++ arch/arm/boot/dts/omap4.dtsi | 30 ++ arch/arm/mach-omap2/board-3430sdp.c| 21 ++-- arch/arm/mach-omap2/board-3630sdp.c| 21 ++-- arch/arm/mach-omap2/board-am3517crane.c| 24 ++--- arch/arm/mach-omap2/board-am3517evm.c | 17 +-- arch/arm/mach-omap2/board-cm-t35.c | 20 ++-- arch/arm/mach-omap2/board-cm-t3517.c | 20 ++-- arch/arm/mach-omap2/board-devkit8000.c | 8 -- arch/arm/mach-omap2/board-igep0020.c | 32 +++--- arch/arm/mach-omap2/board-omap3beagle.c| 32 -- arch/arm/mach-omap2/board-omap3evm.c | 25 ++--- arch/arm/mach-omap2/board-omap3pandora.c | 21 ++-- arch/arm/mach-omap2/board-omap3stalker.c | 17 +-- arch/arm/mach-omap2/board-omap3touchbook.c | 17 +-- arch/arm/mach-omap2/board-omap4panda.c | 55 -- arch/arm/mach-omap2/board-overo.c | 16 +-- arch/arm/mach-omap2/board-zoom.c | 16 +-- arch/arm/mach-omap2/usb-host.c | 160 - arch/arm/mach-omap2/usb.h | 9 ++ 21 files changed, 503 insertions(+), 160 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: AM3517 DaVinci EMAC Ethernet performance issues
Mugunthan and all, One more quick follow-up: With that patch applied and us removing the SMSC LAN8710 PHY driver from the kernel and just using the default unknown driver, things are *much* better. (I have no idea why that PHY driver would be hurting us since that is the exact PHY the TAM-3517 uses, but I'll take better performance any day.) On average we're seeing 40 - 60Mbps in the transmit direction and continuing to see the full ~95Mbps in the receive direction. We do still see some timeouts when transmitting, but they are certainly fewer and farther between. There is one additional step that I can take which appears to completely fix our performance. Oddly, it's turning on our custom application! With our custom app running, suddenly we can do 95Mbps is *both* directions without any drops! Since our app in its idle state is really not doing anything but periodically reading and writing on all 4 AM3517 UARTs + periodically blipping out a one-way UDP status packet or two + doing a little bit of stuff on the GPMC (we have a GPMC-based UART as well), there is _nothing_ there that seems like it should double-up our EMAC's transmit performance. If anything, I would have expected the unnecessary load to hurt us. My theory at the moment is that this code is somehow keeping the EMAC from entering some form of a sleep or lower power state; and this something must be different than whatever iperf is doing. (iperf chews up about 25% of the CPU by the way, so I don't think it's a general CPU stress thing.) I know there are several power domains and such on this chip, and I've seen lots of effort going into getting all of them to work properly over the past year. For our older 3.5-rc4 kernel, I've turned all power control stuff OFF. Our application does not require low power features, so I've long considered that something to do when I have idle time on my hands. Do you agree that this app holding something up seems like a good theory? If so, what could possibly be shutting off or causing a pause that this custom app I've mentioned may be inadvertently keeping awake? We are already running our kernel with the nohlt option and the kernel configuration shown below. Is there anything else anyone would recommend we try? Thanks! # # Automatically generated file; DO NOT EDIT. # Linux/arm 3.5.0-rc4 Kernel Configuration # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y CONFIG_HAVE_PROC_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_VECTORS_BASE=0x CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_GENERIC_BUG=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_HAVE_IRQ_WORK=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set CONFIG_DEFAULT_HOSTNAME=(none) # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_FHANDLE is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_KTIME_SCALAR=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set # CONFIG_CGROUP_FREEZER is not set # CONFIG_CGROUP_DEVICE is not set # CONFIG_CPUSETS is not set # CONFIG_CGROUP_CPUACCT is not set # CONFIG_RESOURCE_COUNTERS is not set # CONFIG_CGROUP_SCHED is not set # CONFIG_BLK_CGROUP is not set # CONFIG_CHECKPOINT_RESTORE is not set # CONFIG_NAMESPACES is not set # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE=initramfs.cpio.gz CONFIG_INITRAMFS_ROOT_UID=0 CONFIG_INITRAMFS_ROOT_GID=0 CONFIG_RD_GZIP=y # CONFIG_RD_BZIP2 is not set CONFIG_RD_LZMA=y # CONFIG_RD_XZ is not set # CONFIG_RD_LZO is not set CONFIG_INITRAMFS_COMPRESSION_NONE=y # CONFIG_INITRAMFS_COMPRESSION_GZIP is not set # CONFIG_INITRAMFS_COMPRESSION_LZMA is not set #
[PATCH 0/5] gpio/omap: 2nd batch of updates for v3.10
Main change is ensuring that the state of a gpio bank is restored when booting with device-tree. The rest of the patches are clean-ups and one optimisation. The patch modifying the *.dtsi files should go via Benoit Cousson's for_3.10/dts branch [1] as it is dependent on changes in his branch but I have included here for completeness. Testing includes: - Boot testing on OMAP5912 OSK, OMAP2420 H4, OMAP3430 SDP, OMAP4430 SDP and AM335x EVM. - Verified that GPIO interrupts are working on OMAP5912 OSK, OMAP2420 H4, OMAP3430 SDP and OMAP4430 SDP by making sure networking was working correctly as these boards use a GPIO with the ethernet chips. Also checked /proc/interrupts to ensure GPIO interrupt counts are incrementing as expected. [1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git Jon Hunter (4): gpio/omap: free irq domain in probe() failure paths gpio/omap: optimise interrupt service routine gpio/omap: force restore if context loss is not detectable ARM: dts: OMAP2+: Identify GPIO banks that are always powered Tarun Kanti DebBarma (1): gpio/omap: remove extra context restores in *_runtime_resume() .../devicetree/bindings/gpio/gpio-omap.txt |7 ++- arch/arm/boot/dts/omap2420.dtsi|4 ++ arch/arm/boot/dts/omap2430.dtsi|4 ++ arch/arm/boot/dts/omap3.dtsi |1 + arch/arm/boot/dts/omap4.dtsi |1 + arch/arm/boot/dts/omap5.dtsi |1 + drivers/gpio/gpio-omap.c | 49 +++- 7 files changed, 44 insertions(+), 23 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] gpio/omap: free irq domain in probe() failure paths
Currently the IRQ domain is not freed once allocated, in the case where
omap_gpio_probe() fails. Therefore, ensure we free the domain if the
probe does fail. Furthermore, the local variable ret is not needed
and so remove this.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
drivers/gpio/gpio-omap.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0d30c7a..1e666c8 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1094,7 +1094,6 @@ static int omap_gpio_probe(struct platform_device *pdev)
const struct omap_gpio_platform_data *pdata;
struct resource *res;
struct gpio_bank *bank;
- int ret = 0;
match = of_match_device(of_match_ptr(omap_gpio_match), dev);
@@ -1143,18 +1142,21 @@ static int omap_gpio_probe(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (unlikely(!res)) {
dev_err(dev, Invalid mem resource\n);
+ irq_domain_remove(bank-domain);
return -ENODEV;
}
if (!devm_request_mem_region(dev, res-start, resource_size(res),
pdev-name)) {
dev_err(dev, Region already claimed\n);
+ irq_domain_remove(bank-domain);
return -EBUSY;
}
bank-base = devm_ioremap(dev, res-start, resource_size(res));
if (!bank-base) {
dev_err(dev, Could not ioremap\n);
+ irq_domain_remove(bank-domain);
return -ENOMEM;
}
@@ -1178,7 +1180,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
list_add_tail(bank-node, omap_gpio_list);
- return ret;
+ return 0;
}
#ifdef CONFIG_ARCH_OMAP2PLUS
--
1.7.10.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] gpio/omap: remove extra context restores in *_runtime_resume()
From: Tarun Kanti DebBarma tarun.ka...@ti.com 68942edb09f69b6e09522d1d346665eb3aadde49 (gpio/omap: fix wakeups on level-triggered GPIOs) already restores the fallingdetect and risingdetect contexts in *_runtime_resume(). These registers were modified in *_runtime_suspend() to include even those configured as level-triggered since only edge-triggered gpios can generate wakeup events. Therefore, the old context restores of the same registers present later in the code is not needed any more. Remove them. Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Signed-off-by: Jon Hunter jon-hun...@ti.com --- drivers/gpio/gpio-omap.c |4 1 file changed, 4 deletions(-) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index 1e666c8..5af7acd 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -1292,10 +1292,6 @@ static int omap_gpio_runtime_resume(struct device *dev) return 0; } - __raw_writel(bank-context.fallingdetect, - bank-base + bank-regs-fallingdetect); - __raw_writel(bank-context.risingdetect, - bank-base + bank-regs-risingdetect); l = __raw_readl(bank-base + bank-regs-datain); /* -- 1.7.10.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] gpio/omap: force restore if context loss is not detectable
When booting with device-tree the function pointer for detecting context
loss is not populated. Ideally, the pm_runtime framework should be
enhanced to allow a means for reporting context/state loss and we could
avoid populating such function pointers altogether. In the interim until
a generic non-device specific solution is in place, force a restore of
the gpio bank when enabling the gpio controller.
Adds a new device-tree property for the OMAP GPIO controller to indicate
if the GPIO controller is located in a power-domain that never loses
power and hence will always maintain its logic state.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
.../devicetree/bindings/gpio/gpio-omap.txt |7 --
drivers/gpio/gpio-omap.c | 25 +---
2 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
index a56e3a5..8d95052 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -20,8 +20,11 @@ Required properties:
8 = active low level-sensitive.
OMAP specific properties:
-- ti,hwmods: Name of the hwmod associated to the GPIO:
- gpioX, X being the 1-based instance number from the HW spec
+- ti,hwmods: Name of the hwmod associated to the GPIO:
+ gpioX, X being the 1-based instance number
+ from the HW spec.
+- ti,gpio-always-on: Indicates if a GPIO bank is always powered and
+ so will never lose its logic state.
Example:
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 685e850..0557529 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1120,11 +1120,17 @@ static int omap_gpio_probe(struct platform_device *pdev)
bank-width = pdata-bank_width;
bank-is_mpuio = pdata-is_mpuio;
bank-non_wakeup_gpios = pdata-non_wakeup_gpios;
- bank-loses_context = pdata-loses_context;
bank-regs = pdata-regs;
#ifdef CONFIG_OF_GPIO
bank-chip.of_node = of_node_get(node);
#endif
+ if (node) {
+ if (!of_property_read_bool(node, ti,gpio-always-on))
+ bank-loses_context = true;
+ } else {
+ bank-loses_context = pdata-loses_context;
+ }
+
bank-domain = irq_domain_add_linear(node, bank-width,
irq_domain_simple_ops, NULL);
@@ -1258,9 +1264,9 @@ static int omap_gpio_runtime_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct gpio_bank *bank = platform_get_drvdata(pdev);
- int context_lost_cnt_after;
u32 l = 0, gen, gen0, gen1;
unsigned long flags;
+ int c;
spin_lock_irqsave(bank-lock, flags);
_gpio_dbck_enable(bank);
@@ -1276,14 +1282,17 @@ static int omap_gpio_runtime_resume(struct device *dev)
__raw_writel(bank-context.risingdetect,
bank-base + bank-regs-risingdetect);
- if (bank-get_context_loss_count) {
- context_lost_cnt_after =
- bank-get_context_loss_count(bank-dev);
- if (context_lost_cnt_after != bank-context_loss_count) {
+ if (bank-loses_context) {
+ if (!bank-get_context_loss_count) {
omap_gpio_restore_context(bank);
} else {
- spin_unlock_irqrestore(bank-lock, flags);
- return 0;
+ c = bank-get_context_loss_count(bank-dev);
+ if (c != bank-context_loss_count) {
+ omap_gpio_restore_context(bank);
+ } else {
+ spin_unlock_irqrestore(bank-lock, flags);
+ return 0;
+ }
}
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] gpio/omap: optimise interrupt service routine
The OMAP GPIO interrupt service routine is checking each bit in the
GPIO interrupt status register to see which bits are set. It is not
efficient to check every bit especially if only a few bits are set.
Therefore, instead of checking every bit use the __ffs() function,
which returns the location of the first set bit, to find all the set
bits.
This optimisation was suggested-by and developed in collaboration
with Felipe Balbi.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
drivers/gpio/gpio-omap.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 5af7acd..685e850 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -689,7 +689,7 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
{
void __iomem *isr_reg = NULL;
u32 isr;
- unsigned int i;
+ unsigned int bit;
struct gpio_bank *bank;
int unmasked = 0;
struct irq_chip *chip = irq_desc_get_chip(desc);
@@ -730,9 +730,9 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
if (!isr)
break;
- for (i = 0; isr != 0; isr = 1, i++) {
- if (!(isr 1))
- continue;
+ while (isr) {
+ bit = __ffs(isr);
+ isr = ~(1 bit);
/*
* Some chips can't respond to both rising and falling
@@ -741,10 +741,10 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
* to respond to the IRQ for the opposite direction.
* This will be indicated in the bank toggle_mask.
*/
- if (bank-toggle_mask (1 i))
- _toggle_gpio_edge_triggering(bank, i);
+ if (bank-toggle_mask (1 bit))
+ _toggle_gpio_edge_triggering(bank, bit);
- generic_handle_irq(irq_find_mapping(bank-domain, i));
+ generic_handle_irq(irq_find_mapping(bank-domain, bit));
}
}
/* if bank has any level sensitive GPIO pin interrupt
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] ARM: dts: OMAP2+: Identify GPIO banks that are always powered
Add the ti,gpio-always-on property to the appropriate GPIO banks to indicate which banks are always powered and will never lose logic state. Cc: Benoit Cousson b-cous...@ti.com Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/boot/dts/omap2420.dtsi |4 arch/arm/boot/dts/omap2430.dtsi |4 arch/arm/boot/dts/omap3.dtsi|1 + arch/arm/boot/dts/omap4.dtsi|1 + arch/arm/boot/dts/omap5.dtsi|1 + 5 files changed, 11 insertions(+) diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi index 455b239..76446ff 100644 --- a/arch/arm/boot/dts/omap2420.dtsi +++ b/arch/arm/boot/dts/omap2420.dtsi @@ -34,6 +34,7 @@ reg = 0x48018000 0x200; interrupts = 29; ti,hwmods = gpio1; + ti,gpio-always-on; #gpio-cells = 2; gpio-controller; #interrupt-cells = 2; @@ -45,6 +46,7 @@ reg = 0x4801a000 0x200; interrupts = 30; ti,hwmods = gpio2; + ti,gpio-always-on; #gpio-cells = 2; gpio-controller; #interrupt-cells = 2; @@ -56,6 +58,7 @@ reg = 0x4801c000 0x200; interrupts = 31; ti,hwmods = gpio3; + ti,gpio-always-on; #gpio-cells = 2; gpio-controller; #interrupt-cells = 2; @@ -67,6 +70,7 @@ reg = 0x4801e000 0x200; interrupts = 32; ti,hwmods = gpio4; + ti,gpio-always-on; #gpio-cells = 2; gpio-controller; #interrupt-cells = 2; diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi index 477b120..ca2c4a3 100644 --- a/arch/arm/boot/dts/omap2430.dtsi +++ b/arch/arm/boot/dts/omap2430.dtsi @@ -34,6 +34,7 @@ reg = 0x4900c000 0x200; interrupts = 29; ti,hwmods = gpio1; + ti,gpio-always-on; #gpio-cells = 2; gpio-controller; #interrupt-cells = 2; @@ -45,6 +46,7 @@ reg = 0x4900e000 0x200; interrupts = 30; ti,hwmods = gpio2; + ti,gpio-always-on; #gpio-cells = 2; gpio-controller; #interrupt-cells = 2; @@ -56,6 +58,7 @@ reg = 0x4901 0x200; interrupts = 31; ti,hwmods = gpio3; + ti,gpio-always-on; #gpio-cells = 2; gpio-controller; #interrupt-cells = 2; @@ -67,6 +70,7 @@ reg = 0x49012000 0x200; interrupts = 32; ti,hwmods = gpio4; + ti,gpio-always-on; #gpio-cells = 2; gpio-controller; #interrupt-cells = 2; diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi index 3344f05..626406f 100644 --- a/arch/arm/boot/dts/omap3.dtsi +++ b/arch/arm/boot/dts/omap3.dtsi @@ -116,6 +116,7 @@ reg = 0x4831 0x200; interrupts = 29; ti,hwmods = gpio1; + ti,gpio-always-on; gpio-controller; #gpio-cells = 2; interrupt-controller; diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi index 3329140..627f6ca 100644 --- a/arch/arm/boot/dts/omap4.dtsi +++ b/arch/arm/boot/dts/omap4.dtsi @@ -140,6 +140,7 @@ reg = 0x4a31 0x200; interrupts = 0 29 0x4; ti,hwmods = gpio1; + ti,gpio-always-on; gpio-controller; #gpio-cells = 2; interrupt-controller; diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index f4c71d9..82a4b03 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -133,6 +133,7 @@ reg = 0x4ae1 0x200; interrupts = 0 29 0x4; ti,hwmods = gpio1; + ti,gpio-always-on; gpio-controller; #gpio-cells = 2; interrupt-controller; -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe
Re: [PATCH 5/5] ARM: dts: OMAP2+: Identify GPIO banks that are always powered
* Jon Hunter jon-hun...@ti.com [130404 13:21]: Add the ti,gpio-always-on property to the appropriate GPIO banks to indicate which banks are always powered and will never lose logic state. This patch should be queued by Benoit as this will likely cause pointless merge conflicts with the other .dts files. Regards, Tony Cc: Benoit Cousson b-cous...@ti.com Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/boot/dts/omap2420.dtsi |4 arch/arm/boot/dts/omap2430.dtsi |4 arch/arm/boot/dts/omap3.dtsi|1 + arch/arm/boot/dts/omap4.dtsi|1 + arch/arm/boot/dts/omap5.dtsi|1 + 5 files changed, 11 insertions(+) diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi index 455b239..76446ff 100644 --- a/arch/arm/boot/dts/omap2420.dtsi +++ b/arch/arm/boot/dts/omap2420.dtsi @@ -34,6 +34,7 @@ reg = 0x48018000 0x200; interrupts = 29; ti,hwmods = gpio1; + ti,gpio-always-on; #gpio-cells = 2; gpio-controller; #interrupt-cells = 2; @@ -45,6 +46,7 @@ reg = 0x4801a000 0x200; interrupts = 30; ti,hwmods = gpio2; + ti,gpio-always-on; #gpio-cells = 2; gpio-controller; #interrupt-cells = 2; @@ -56,6 +58,7 @@ reg = 0x4801c000 0x200; interrupts = 31; ti,hwmods = gpio3; + ti,gpio-always-on; #gpio-cells = 2; gpio-controller; #interrupt-cells = 2; @@ -67,6 +70,7 @@ reg = 0x4801e000 0x200; interrupts = 32; ti,hwmods = gpio4; + ti,gpio-always-on; #gpio-cells = 2; gpio-controller; #interrupt-cells = 2; diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi index 477b120..ca2c4a3 100644 --- a/arch/arm/boot/dts/omap2430.dtsi +++ b/arch/arm/boot/dts/omap2430.dtsi @@ -34,6 +34,7 @@ reg = 0x4900c000 0x200; interrupts = 29; ti,hwmods = gpio1; + ti,gpio-always-on; #gpio-cells = 2; gpio-controller; #interrupt-cells = 2; @@ -45,6 +46,7 @@ reg = 0x4900e000 0x200; interrupts = 30; ti,hwmods = gpio2; + ti,gpio-always-on; #gpio-cells = 2; gpio-controller; #interrupt-cells = 2; @@ -56,6 +58,7 @@ reg = 0x4901 0x200; interrupts = 31; ti,hwmods = gpio3; + ti,gpio-always-on; #gpio-cells = 2; gpio-controller; #interrupt-cells = 2; @@ -67,6 +70,7 @@ reg = 0x49012000 0x200; interrupts = 32; ti,hwmods = gpio4; + ti,gpio-always-on; #gpio-cells = 2; gpio-controller; #interrupt-cells = 2; diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi index 3344f05..626406f 100644 --- a/arch/arm/boot/dts/omap3.dtsi +++ b/arch/arm/boot/dts/omap3.dtsi @@ -116,6 +116,7 @@ reg = 0x4831 0x200; interrupts = 29; ti,hwmods = gpio1; + ti,gpio-always-on; gpio-controller; #gpio-cells = 2; interrupt-controller; diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi index 3329140..627f6ca 100644 --- a/arch/arm/boot/dts/omap4.dtsi +++ b/arch/arm/boot/dts/omap4.dtsi @@ -140,6 +140,7 @@ reg = 0x4a31 0x200; interrupts = 0 29 0x4; ti,hwmods = gpio1; + ti,gpio-always-on; gpio-controller; #gpio-cells = 2; interrupt-controller; diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index f4c71d9..82a4b03 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -133,6 +133,7 @@ reg = 0x4ae1 0x200; interrupts = 0 29 0x4; ti,hwmods = gpio1; + ti,gpio-always-on; gpio-controller;
Re: [PATCH 5/5] ARM: dts: OMAP2+: Identify GPIO banks that are always powered
On 04/04/2013 03:35 PM, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [130404 13:21]: Add the ti,gpio-always-on property to the appropriate GPIO banks to indicate which banks are always powered and will never lose logic state. This patch should be queued by Benoit as this will likely cause pointless merge conflicts with the other .dts files. Yes agreed. I mentioned that in the cover-letter. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] ARM: dts: OMAP2+: Identify GPIO banks that are always powered
* Jon Hunter jon-hun...@ti.com [130404 14:05]: On 04/04/2013 03:35 PM, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [130404 13:21]: Add the ti,gpio-always-on property to the appropriate GPIO banks to indicate which banks are always powered and will never lose logic state. This patch should be queued by Benoit as this will likely cause pointless merge conflicts with the other .dts files. Yes agreed. I mentioned that in the cover-letter. OK thanks. 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
[GIT PULL] mailbox driver framework for v3.10 merge window
The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: Linux 3.9-rc2 (2013-03-10 16:54:19 -0700) are available in the git repository at: git://github.com/sumananna/mailbox.git dbx500-prcmu-mailbox for you to fetch changes up to c497eba5247728c67ba0e0de0907723dd114134a: mailbox: fix invalid use of sizeof in mailbox_msg_send() (2013-03-23 15:04:14 +0800) -- OMAP and ST-Ericsson platforms are both using mailbox to communicate with some coprocessors. This series creates a consolidated framework, living under drivers/mailbox. The changes mainly contain: - create a mailbox framework independent from OMAP h/w - creates dbx500 mailbox driver for ST-Ericsson platforms - move the omap mailbox out of plat-omap/mach-omapX adapting to the new framework. - minor bug fixes in mailbox code This series is needed for the work currently being done on the PRCMU driver. -- Loic Pallardy (7): mailbox: rename omap_mbox in mailbox mailbox: create opened message type mailbox: change protection mechanisms mailbox: add shared memory mailbox type mailbox: add IRQF_NO_SUSPEND flag mailbox: add no_irq send message mailbox: create dbx500 mailbox driver Omar Ramirez Luna (2): mailbox: OMAP: introduce mailbox framework mailbox: split internal header from API header Suman Anna (5): mailbox: rename pl320-ipc specific mailbox.h ARM: OMAP2+: mbox: remove dependencies with soc.h mailbox/omap: check iomem resource before dereferencing it mailbox: check for NULL nb in mailbox_put mailbox: call request_irq after mbox queues are allocated Wei Yongjun (1): mailbox: fix invalid use of sizeof in mailbox_msg_send() .../devicetree/bindings/mailbox/dbx500-mailbox.txt | 27 + arch/arm/configs/omap1_defconfig | 3 +- arch/arm/mach-omap1/Makefile | 4 - arch/arm/mach-omap1/mailbox.c | 199 --- arch/arm/mach-omap2/Makefile | 3 - arch/arm/mach-omap2/devices.c | 13 +- arch/arm/mach-omap2/mailbox.c | 430 -- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 12 + arch/arm/mach-omap2/omap_hwmod_2430_data.c | 11 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 11 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 13 + arch/arm/plat-omap/Kconfig | 16 - arch/arm/plat-omap/Makefile| 3 - arch/arm/plat-omap/include/plat/mailbox.h | 105 arch/arm/plat-omap/mailbox.c | 435 -- drivers/cpufreq/highbank-cpufreq.c | 2 +- drivers/mailbox/Kconfig| 41 ++ drivers/mailbox/Makefile | 5 + drivers/mailbox/mailbox-dbx500.c | 648 + drivers/mailbox/mailbox-omap1.c| 229 drivers/mailbox/mailbox-omap2.c| 370 drivers/mailbox/mailbox.c | 552 ++ drivers/mailbox/mailbox_internal.h | 70 +++ drivers/mailbox/pl320-ipc.c| 2 +- drivers/remoteproc/Kconfig | 3 +- drivers/remoteproc/omap_remoteproc.c | 36 +- drivers/staging/tidspbridge/Kconfig| 3 +- drivers/staging/tidspbridge/core/_tiomap.h | 2 +- drivers/staging/tidspbridge/core/chnl_sm.c | 8 +- drivers/staging/tidspbridge/core/io_sm.c | 5 +- drivers/staging/tidspbridge/core/tiomap3430.c | 6 +- drivers/staging/tidspbridge/core/tiomap3430_pwr.c | 6 +- drivers/staging/tidspbridge/core/tiomap_io.c | 9 +- .../tidspbridge/include/dspbridge/host_os.h| 2 +- include/linux/mailbox.h| 52 +- include/linux/pl320-ipc.h | 17 + include/linux/platform_data/mailbox-dbx500.h | 12 + include/linux/platform_data/mailbox-omap.h | 53 ++ 38 files changed, 2170 insertions(+), 1248 deletions(-) create mode 100644 Documentation/devicetree/bindings/mailbox/dbx500-mailbox.txt delete mode 100644 arch/arm/mach-omap1/mailbox.c delete mode 100644 arch/arm/mach-omap2/mailbox.c delete mode 100644 arch/arm/plat-omap/include/plat/mailbox.h delete mode 100644 arch/arm/plat-omap/mailbox.c create mode 100644 drivers/mailbox/mailbox-dbx500.c create mode 100644 drivers/mailbox/mailbox-omap1.c create mode 100644 drivers/mailbox/mailbox-omap2.c create mode 100644 drivers/mailbox/mailbox.c create mode 100644 drivers/mailbox/mailbox_internal.h create mode 100644 include/linux/pl320-ipc.h create mode 100644 include/linux/platform_data/mailbox-dbx500.h create mode 100644
regulator: query on regulator re-entrance
Hi Liam, Mark,
TI platforms typically use Adaptive Voltage Scaling technique to determine
an optimal voltage on top of the traditional DVFS strategy to optimize power.
Depending on the SoC, we use AVS class 0, 1, 1.5, 2, 3. In general,
the AVS strategy is pretty much like a regulator which then gives command
to the PMIC for the optimal voltage to choose.
For example, on AM335x(beaglebone) platform, we use AVS class 2 strategy.
Ref[1]
If we ignore the details of the class 1.5 implementation, we will notice
a) regulator set_voltage equivalent set_voltage() is required.
b) this set_voltage does some 'magic stuff' depending on the SoC and AVS class
and calls the 'real regulator' which talks to the PMIC over i2c/spi etc..
in short the call sequence is more or less:
driver (cpufreq) - AVS - PMIC regulator.
By modeling AVS class drivers as an regulator, we then do not need to introduce
SoC specific hacks and APIs.
driver (cpufreq) - AVS regulator - PMIC regulator.
However, we then need ability to have regulator calls while in the context of
another regulator. Taking this to the next level we might want to chain
multiple regulators as well (example of additional strategy of ABB discussed
here[2]).
In short, an regulator which is also an consumer.
As a proof of concept, I wrote up a dummy AVS class 2 driver (without AVS
functionality)[3] - result is an lockdep warning[4].
I believe there'd be other similar user's who might find it useful to have
regulator chaining. However, considering that regulator framework has
been around for a while, the generic question is: are we ok to allow for
changes to let regulators be re-enterant? If this is interesting, then, I
am curious to know if there are any attempts to do this already in progress.
If interesting and no attempts, then we'd be interested in collaborating for it.
Ref:
[1]
https://github.com/Angstrom-distribution/meta-ti/blob/master/recipes-kernel/linux/linux-am335x-3.2.0-psp04.06.00.08/0001-am33xx-Add-SmartReflex-support.patch
[2] http://marc.info/?t=13648399343r=1w=2
[3] http://pastebin.com/yttSEQ0j
[4] lockdep warning
/sys/devices/system/cpu/cpu0/cpufreq # cat scaling_available_frequencies
30 60 80
/sys/devices/system/cpu/cpu0/cpufreq # echo -n 30scaling_setspeed
[ 28.409606]
[ 28.411193] =
[ 28.416900] [ INFO: possible recursive locking detected ]
[ 28.422607] 3.9.0-rc3-00064-g5e75410-dirty #39 Not tainted
[ 28.428375] -
[ 28.434082] sh/782 is trying to acquire lock:
[ 28.438690] (rdev-mutex){+.+.+.}, at: [c033e5d8]
regulator_get_voltage+0x18/0x38
[ 28.447021]
[ 28.447021] but task is already holding lock:
[ 28.453186] (rdev-mutex){+.+.+.}, at: [c033e5d8]
regulator_get_voltage+0x18/0x38
[ 28.461486]
[ 28.461486] other info that might help us debug this:
[ 28.468414] Possible unsafe locking scenario:
[ 28.468414]
[ 28.474670]CPU0
[ 28.477264]
[ 28.479858] lock(rdev-mutex);
[ 28.483367] lock(rdev-mutex);
[ 28.486877]
[ 28.486877] *** DEADLOCK ***
[ 28.486877]
[ 28.493164] May be due to missing lock nesting notation
[ 28.493164]
[ 28.500335] 5 locks held by sh/782:
[ 28.504028] #0: (buffer-mutex){+.+.+.}, at: [c01951a8]
sysfs_write_file+0x28/0xb4
[ 28.512573] #1: (s_active#4){.+.+.+}, at: [c01951dc]
sysfs_write_file+0x5c/0xb4
[ 28.520721] #2: (per_cpu(cpu_policy_rwsem, cpu)){..}, at:
[c0453260] lock_policy_rwsem_write+0x30/0x44
[ 28.531463] #3: (userspace_mutex){+.+...}, at: [c045597c]
cpufreq_set+0x28/0xc8
[ 28.539611] #4: (rdev-mutex){+.+.+.}, at: [c033e5d8]
regulator_get_voltage+0x18/0x38
[ 28.548400]
[ 28.548400] stack backtrace:
[ 28.553070] [c001bc84] (unwind_backtrace+0x0/0x130) from [c009f4f0]
(print_deadlock_bug+0xcc/0xfc)
[ 28.562927] [c009f4f0] (print_deadlock_bug+0xcc/0xfc) from [c00a0d08]
(validate_chain.isra.27+0x3cc/0x67c)
[ 28.573516] [c00a0d08] (validate_chain.isra.27+0x3cc/0x67c) from
[c00a3ce4] (__lock_acquire+0x420/0xa24)
[ 28.583923] [c00a3ce4] (__lock_acquire+0x420/0xa24) from [c00a49dc]
(lock_acquire+0x9c/0x1f4)
[ 28.593322] [c00a49dc] (lock_acquire+0x9c/0x1f4) from [c058863c]
(mutex_lock_nested+0x78/0x3a0)
[ 28.602874] [c058863c] (mutex_lock_nested+0x78/0x3a0) from [c033e5d8]
(regulator_get_voltage+0x18/0x38)
[ 28.613189] [c033e5d8] (regulator_get_voltage+0x18/0x38) from [c033e0f0]
(_regulator_get_voltage+0x68/0x84)
[ 28.623840] [c033e0f0] (_regulator_get_voltage+0x68/0x84) from
[c033e5e0] (regulator_get_voltage+0x20/0x38)
[ 28.634490] [c033e5e0] (regulator_get_voltage+0x20/0x38) from [c0457d28]
(cpu0_set_target+0x184/0x490)
[ 28.644714] [c0457d28] (cpu0_set_target+0x184/0x490) from [c045284c]
(__cpufreq_driver_target+0x88/0xb8)
[ 28.655090] [c045284c] (__cpufreq_driver_target+0x88/0xb8) from
[c04559dc] (cpufreq_set+0x88/0xc8)
[ 28.664916] [c04559dc]
