Re: [PATCHv2 09/15] OMAP: DSS2: HDMI: implement detect()
Hi, On Thu, Sep 15, 2011 at 11:27 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Thu, 2011-09-15 at 11:11 +0530, K, Mythri P wrote: Hi, On Wed, Sep 14, 2011 at 7:41 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Yes, you are right, detect() does not know if the monitor has changed between polls, so both notification and polling are needed. I implemented only polling as there's no HPD event mechanism yet in omapdss, and also because this was simple and gives DRM basic ability to detect a monitor. If it is needed for DRM then it is fine, but with detect renamed to poll. By next week i should have a patch ready for HPD event mechanism. What is wrong with detect? It detects if there's a display connected. It can be used in polling manner, trying it every n seconds, but it should also be used even if you use HPD event. I think the normal sequence would be something like: 1) register HPD event 2) use detect() to see if a monitor is already connected I guess polling ever few seconds to detect would be waste of CPU cycles when there is already a mechanism in the H/w to detect the connection. Current sequence : Enable display ( Irrespective of whether the cable is connected on not) Sequence with HPD: 1.Register for HPD connect. 2.Enable display 3.Notify DRM/Audio/Kernel component that wants to listen to this event. Thanks and regards, Mythri. -- To unsubscribe from this list: send the line unsubscribe 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] DMAEngine: Define generic transfer request api
2011/9/13 Barry Song 21cn...@gmail.com: 2011/9/13 Jassi Brar jaswinder.si...@linaro.org: On 13 September 2011 13:16, Barry Song 21cn...@gmail.com wrote: if test pass, to the patch, and even for the moment, to the API's idea Acked-by: Barry Song baohua.s...@csr.com one issue i noticed is with a device_prep_dma_genxfer, i don't need device_prep_slave_sg any more, Yeah, the damengine would need to adapt to the fact that these interleaved tranfers could be Mem-Mem as well as Mem-Dev (even though yours could be only one type, but some dmacs could do both). How about: BUG_ON(dma_has_cap(DMA_MEMCPY, device-cap_mask) - !device-device_prep_dma_memcpy); + !device-device_prep_dma_memcpy + !device-device_prep_dma_genxfer); BUG_ON(dma_has_cap(DMA_SLAVE, device-cap_mask) - !device-device_prep_slave_sg); + !device-device_prep_slave_sg + !device-device_prep_dma_genxfer); Seems ok, but please modify in a way you think is best and submit a patch on top of this new api. Then it'll be easier to evaluate everything. i think it should be handled by this patch but not a new one. and i also think xfer_template is a bad name for a structure which is an API. i'd like to add namespace for it and rename it to dma_genxfer. or have any good suggestion? i'd like to send this together with BUG_ON(dma_has_cap(DMA_SLAVE, device-cap_mask) !device-device_prep_dma_genxfer) as v2. -barry -- To unsubscribe from this list: send the line unsubscribe 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: [PATCHv2 09/15] OMAP: DSS2: HDMI: implement detect()
On Thu, 2011-09-15 at 11:54 +0530, K, Mythri P wrote: Hi, On Thu, Sep 15, 2011 at 11:27 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Thu, 2011-09-15 at 11:11 +0530, K, Mythri P wrote: Hi, On Wed, Sep 14, 2011 at 7:41 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Yes, you are right, detect() does not know if the monitor has changed between polls, so both notification and polling are needed. I implemented only polling as there's no HPD event mechanism yet in omapdss, and also because this was simple and gives DRM basic ability to detect a monitor. If it is needed for DRM then it is fine, but with detect renamed to poll. By next week i should have a patch ready for HPD event mechanism. What is wrong with detect? It detects if there's a display connected. It can be used in polling manner, trying it every n seconds, but it should also be used even if you use HPD event. I think the normal sequence would be something like: 1) register HPD event 2) use detect() to see if a monitor is already connected I guess polling ever few seconds to detect would be waste of CPU cycles when there is already a mechanism in the H/w to detect the connection. Obviously. Polling is only used if hot-plug-detect is not available. But detect function can be used even when HPD is available. Current sequence : Enable display ( Irrespective of whether the cable is connected on not) Sequence with HPD: 1.Register for HPD connect. 2.Enable display 3.Notify DRM/Audio/Kernel component that wants to listen to this event. Why would you enable the display even if there's no monitor connected? And when the DRM starts, how does DRM know if the display was already connected? Would you send a HPD event when DRM registers to the event even if there's no actual plug-in event done (i.e. user actually connecting the cable)? And just to clarify, my sequence example was from DRM's point of view. The HDMI driver shouldn't do anything before DRM/omapfb asks it to do something. 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] DMAEngine: Define generic transfer request api
On 15 September 2011 12:01, Barry Song 21cn...@gmail.com wrote: 2011/9/13 Barry Song 21cn...@gmail.com: 2011/9/13 Jassi Brar jaswinder.si...@linaro.org: On 13 September 2011 13:16, Barry Song 21cn...@gmail.com wrote: if test pass, to the patch, and even for the moment, to the API's idea Acked-by: Barry Song baohua.s...@csr.com one issue i noticed is with a device_prep_dma_genxfer, i don't need device_prep_slave_sg any more, Yeah, the damengine would need to adapt to the fact that these interleaved tranfers could be Mem-Mem as well as Mem-Dev (even though yours could be only one type, but some dmacs could do both). How about: BUG_ON(dma_has_cap(DMA_MEMCPY, device-cap_mask) - !device-device_prep_dma_memcpy); + !device-device_prep_dma_memcpy + !device-device_prep_dma_genxfer); BUG_ON(dma_has_cap(DMA_SLAVE, device-cap_mask) - !device-device_prep_slave_sg); + !device-device_prep_slave_sg + !device-device_prep_dma_genxfer); Seems ok, but please modify in a way you think is best and submit a patch on top of this new api. Then it'll be easier to evaluate everything. i think it should be handled by this patch but not a new one. and i also think xfer_template is a bad name for a structure which is an API. i'd like to add namespace for it and rename it to dma_genxfer. or have any good suggestion? I think xfer_template is better - which stresses the usage as having prepared templates of transfers and only change src/dst address before submitting. 'device_prep_dma_genxfer' is the API which is already named so. i'd like to send this together with BUG_ON(dma_has_cap(DMA_SLAVE, device-cap_mask) !device-device_prep_dma_genxfer) as v2. Is there no change other than skipping check for SLAVE when using this api ? -- To unsubscribe from this list: send the line unsubscribe 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] DMAEngine: Define generic transfer request api
2011/9/15 Jassi Brar jaswinder.si...@linaro.org: On 15 September 2011 12:01, Barry Song 21cn...@gmail.com wrote: 2011/9/13 Barry Song 21cn...@gmail.com: 2011/9/13 Jassi Brar jaswinder.si...@linaro.org: On 13 September 2011 13:16, Barry Song 21cn...@gmail.com wrote: if test pass, to the patch, and even for the moment, to the API's idea Acked-by: Barry Song baohua.s...@csr.com one issue i noticed is with a device_prep_dma_genxfer, i don't need device_prep_slave_sg any more, Yeah, the damengine would need to adapt to the fact that these interleaved tranfers could be Mem-Mem as well as Mem-Dev (even though yours could be only one type, but some dmacs could do both). How about: BUG_ON(dma_has_cap(DMA_MEMCPY, device-cap_mask) - !device-device_prep_dma_memcpy); + !device-device_prep_dma_memcpy + !device-device_prep_dma_genxfer); BUG_ON(dma_has_cap(DMA_SLAVE, device-cap_mask) - !device-device_prep_slave_sg); + !device-device_prep_slave_sg + !device-device_prep_dma_genxfer); Seems ok, but please modify in a way you think is best and submit a patch on top of this new api. Then it'll be easier to evaluate everything. i think it should be handled by this patch but not a new one. and i also think xfer_template is a bad name for a structure which is an API. i'd like to add namespace for it and rename it to dma_genxfer. or have any good suggestion? I think xfer_template is better - which stresses the usage as having prepared templates of transfers and only change src/dst address before submitting. 'device_prep_dma_genxfer' is the API which is already named so. sorry i can't agree that. device_prep_dma_genxfer is an API, xfer_template is a data structure which will be seen by users, client drivers. it at least needs a namespace. Otherwise, people someday maybe add another xfer. i'd like to send this together with BUG_ON(dma_has_cap(DMA_SLAVE, device-cap_mask) !device-device_prep_dma_genxfer) as v2. Is there no change other than skipping check for SLAVE when using this api ? -- To unsubscribe from this list: send the line unsubscribe 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-V2 0/4] Introducing TI's New SoC/board AM335XEVM
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Thursday, September 15, 2011 6:02 AM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; Hilman, Kevin; p...@pwsan.com; linux-arm- ker...@lists.infradead.org Subject: Re: [RFC PATCH-V2 0/4] Introducing TI's New SoC/board AM335XEVM * hvaib...@ti.com hvaib...@ti.com [110829 05:52]: From: Vaibhav Hiremath hvaib...@ti.com This patch set adds support for AM335x device having Cortex-A8 MPU. AM335X is treated as another OMAP3 variant, where, along with existing cpu class OMAP34XX, new cpu class AM33XX is created and the respective type is AM335X, which is newly added device in the family. This means, cpu_is_omap34xx(), cpu_is_am33xx() and cpu_is_am335x() checks return success for AM335X. Currently submitting this patch series as a RFC (V2), to initiate the discussion on the approach we have chosen for AM335x device support. Based on the feedback, will submit the final version of patch series immediately. Can you please rebase these on Paul's CHIP_IS removal series? Those patches are available at: git://git.pwsan.com/linux-2.6 omap_chip_remove_cleanup_3.2 [Hiremath, Vaibhav] Thanks Tony for your comments, Yeah, I will rebase and submit it again ASAP. Thanks, Vaibhav 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
[PATCH 0/3] OMAP: DSS: display support for 4430SDP
These patches add support for the LCD and PicoDLP outputs for 4430SDP board. Tomi Tomi Valkeinen (3): OMAP: DSS2: Taal: remove external backlight support OMAP4: 4430SDP: Add panel support to board file OMAP4: 4430SDP: Add picodlp support to board file arch/arm/mach-omap2/board-4430sdp.c | 193 +++-- drivers/video/omap2/displays/panel-taal.c | 76 +--- include/video/omap-panel-nokia-dsi.h |8 +- 3 files changed, 212 insertions(+), 65 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] OMAP: DSS2: Taal: remove external backlight support
Taal panel driver supports two kinds of backlight control: 1) using DSI
commands sent to the panel to control the backlight, 2) calling function
pointers going to the board file to control the backlight.
The second option is a bit hacky, and will no longer be needed when the
PWM driver supports the backlight features. After that we can use the
standard PWM backlight driver.
This patch removes the second backlight control mechanism, and adds a
boolean field, use_dsi_backlight, to nokia_dsi_panel_data which the
board file can use to inform whether the panel driver should use DSI
commands to control the backlight.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays/panel-taal.c | 76 +++-
include/video/omap-panel-nokia-dsi.h |8 +--
2 files changed, 32 insertions(+), 52 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index ddc696d..7f91002 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -208,8 +208,6 @@ struct taal_data {
struct delayed_work te_timeout_work;
- bool use_dsi_bl;
-
bool cabc_broken;
unsigned cabc_mode;
@@ -541,7 +539,6 @@ static int taal_bl_update_status(struct backlight_device
*dev)
{
struct omap_dss_device *dssdev = dev_get_drvdata(dev-dev);
struct taal_data *td = dev_get_drvdata(dssdev-dev);
- struct nokia_dsi_panel_data *panel_data = get_panel_data(dssdev);
int r;
int level;
@@ -555,23 +552,16 @@ static int taal_bl_update_status(struct backlight_device
*dev)
mutex_lock(td-lock);
- if (td-use_dsi_bl) {
- if (td-enabled) {
- dsi_bus_lock(dssdev);
+ if (td-enabled) {
+ dsi_bus_lock(dssdev);
- r = taal_wake_up(dssdev);
- if (!r)
- r = taal_dcs_write_1(td, DCS_BRIGHTNESS, level);
+ r = taal_wake_up(dssdev);
+ if (!r)
+ r = taal_dcs_write_1(td, DCS_BRIGHTNESS, level);
- dsi_bus_unlock(dssdev);
- } else {
- r = 0;
- }
+ dsi_bus_unlock(dssdev);
} else {
- if (!panel_data-set_backlight)
- r = -EINVAL;
- else
- r = panel_data-set_backlight(dssdev, level);
+ r = 0;
}
mutex_unlock(td-lock);
@@ -950,7 +940,7 @@ static int taal_probe(struct omap_dss_device *dssdev)
{
struct backlight_properties props;
struct taal_data *td;
- struct backlight_device *bldev;
+ struct backlight_device *bldev = NULL;
struct nokia_dsi_panel_data *panel_data = get_panel_data(dssdev);
struct panel_config *panel_config = NULL;
int r, i;
@@ -1011,35 +1001,26 @@ static int taal_probe(struct omap_dss_device *dssdev)
taal_hw_reset(dssdev);
- /* if no platform set_backlight() defined, presume DSI backlight
-* control */
- memset(props, 0, sizeof(struct backlight_properties));
- if (!panel_data-set_backlight)
- td-use_dsi_bl = true;
-
- if (td-use_dsi_bl)
+ if (panel_data-use_dsi_backlight) {
+ memset(props, 0, sizeof(struct backlight_properties));
props.max_brightness = 255;
- else
- props.max_brightness = 127;
-
- props.type = BACKLIGHT_RAW;
- bldev = backlight_device_register(dev_name(dssdev-dev), dssdev-dev,
- dssdev, taal_bl_ops, props);
- if (IS_ERR(bldev)) {
- r = PTR_ERR(bldev);
- goto err_bl;
- }
- td-bldev = bldev;
+ props.type = BACKLIGHT_RAW;
+ bldev = backlight_device_register(dev_name(dssdev-dev),
+ dssdev-dev, dssdev, taal_bl_ops, props);
+ if (IS_ERR(bldev)) {
+ r = PTR_ERR(bldev);
+ goto err_bl;
+ }
+
+ td-bldev = bldev;
- bldev-props.fb_blank = FB_BLANK_UNBLANK;
- bldev-props.power = FB_BLANK_UNBLANK;
- if (td-use_dsi_bl)
+ bldev-props.fb_blank = FB_BLANK_UNBLANK;
+ bldev-props.power = FB_BLANK_UNBLANK;
bldev-props.brightness = 255;
- else
- bldev-props.brightness = 127;
- taal_bl_update_status(bldev);
+ taal_bl_update_status(bldev);
+ }
if (panel_data-use_ext_te) {
int gpio = panel_data-ext_te_gpio;
@@ -1097,7 +1078,8 @@ err_irq:
if (panel_data-use_ext_te)
gpio_free(panel_data-ext_te_gpio);
err_gpio:
- backlight_device_unregister(bldev);
+ if (bldev != NULL)
+
[PATCH 2/3] OMAP4: 4430SDP: Add panel support to board file
4430SDP has two Taal DSI panels, connected to DSI 1 and DSI 2 modules.
The panels use a common PWM backlight, which will be implemented later
when the PWM driver has been improved to support the backlight.
Until the PWM driver has been improved, the following hack added to
arch/arm/mach-omap2/board-4430sdp.c can be used to set the backlight to
max:
static int omap_4430sdp_hack_backlight(void)
{
twl_i2c_write_u8(TWL_MODULE_PWM, 0x7f, LED_PWM2OFF);
twl_i2c_write_u8(TWL_MODULE_PWM, 0x7f, LED_PWM2ON);
twl_i2c_write_u8(TWL6030_MODULE_ID1, 0x30, TWL6030_TOGGLE3);
return 0;
}
late_initcall(omap_4430sdp_hack_backlight);
Signed-off-by: Archit Taneja arc...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 141 +++---
1 files changed, 128 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 79c2827..b01ba46 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -38,6 +38,7 @@
#include plat/mmc.h
#include plat/omap4-keypad.h
#include video/omapdss.h
+#include video/omap-panel-nokia-dsi.h
#include linux/wl12xx.h
#include mux.h
@@ -52,6 +53,7 @@
#define OMAP4_SFH7741_ENABLE_GPIO 188
#define HDMI_GPIO_HPD 60 /* Hot plug pin for HDMI */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
+#define DISPLAY_SEL_GPIO 59 /* LCD2/PicoDLP switch */
#define GPIO_WIFI_PMENA54
#define GPIO_WIFI_IRQ 53
@@ -340,11 +342,6 @@ static int __init omap_ethernet_init(void)
return status;
}
-static struct platform_device sdp4430_lcd_device = {
- .name = sdp4430_lcd,
- .id = -1,
-};
-
static struct regulator_consumer_supply sdp4430_vbat_supply[] = {
REGULATOR_SUPPLY(vddvibl, twl6040-vibra),
REGULATOR_SUPPLY(vddvibr, twl6040-vibra),
@@ -374,19 +371,13 @@ static struct platform_device sdp4430_vbat = {
};
static struct platform_device *sdp4430_devices[] __initdata = {
- sdp4430_lcd_device,
sdp4430_gpio_keys_device,
sdp4430_leds_gpio,
sdp4430_leds_pwm,
sdp4430_vbat,
};
-static struct omap_lcd_config sdp4430_lcd_config __initdata = {
- .ctrl_name = internal,
-};
-
static struct omap_board_config_kernel sdp4430_config[] __initdata = {
- { OMAP_TAG_LCD, sdp4430_lcd_config },
};
static void __init omap_4430sdp_init_early(void)
@@ -648,6 +639,119 @@ static void sdp4430_panel_disable_hdmi(struct
omap_dss_device *dssdev)
gpio_free(HDMI_GPIO_HPD);
}
+static struct nokia_dsi_panel_data dsi1_panel = {
+ .name = taal,
+ .reset_gpio = 102,
+ .use_ext_te = false,
+ .ext_te_gpio= 101,
+ .esd_interval = 0,
+};
+
+static struct omap_dss_device sdp4430_lcd_device = {
+ .name = lcd,
+ .driver_name= taal,
+ .type = OMAP_DISPLAY_TYPE_DSI,
+ .data = dsi1_panel,
+ .phy.dsi= {
+ .clk_lane = 1,
+ .clk_pol= 0,
+ .data1_lane = 2,
+ .data1_pol = 0,
+ .data2_lane = 3,
+ .data2_pol = 0,
+
+ .module = 0,
+ },
+
+ .clocks = {
+ .dispc = {
+ .channel = {
+ /* Logic Clock = 172.8 MHz */
+ .lck_div= 1,
+ /* Pixel Clock = 34.56 MHz */
+ .pck_div= 5,
+ .lcd_clk_src=
OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC,
+ },
+ .dispc_fclk_src = OMAP_DSS_CLK_SRC_FCK,
+ },
+
+ .dsi = {
+ .regn = 16, /* Fint = 2.4 MHz */
+ .regm = 180, /* DDR Clock = 216 MHz */
+ .regm_dispc = 5,/* PLL1_CLK1 = 172.8 MHz */
+ .regm_dsi = 5,/* PLL1_CLK2 = 172.8 MHz */
+
+ .lp_clk_div = 10, /* LP Clock = 8.64 MHz */
+ .dsi_fclk_src = OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DSI,
+ },
+ },
+ .channel= OMAP_DSS_CHANNEL_LCD,
+};
+
+static struct nokia_dsi_panel_data dsi2_panel = {
+ .name = taal,
+ .reset_gpio = 104,
+ .use_ext_te = false,
+ .ext_te_gpio= 103,
+ .esd_interval = 0,
+};
+
+static struct omap_dss_device sdp4430_lcd2_device = {
+ .name = lcd2,
+ .driver_name= taal,
+ .type =
[PATCH 3/3] OMAP4: 4430SDP: Add picodlp support to board file
An on-board projector named picodlp is available for OMAP4430 SDP.
Entry for this picodlp as a panel is being added in dss_devices array to
the board file. It needs 4 GPIO pins for interfacing with host
processor and these are defined and two of them are configured in board
file. Two GPIOs power_on and display_select are configured here.
picodlp also needs an i2c client over i2c controller-2 at address 0x1b.
Signed-off-by: Mayuresh Janorkar ma...@ti.com
Signed-off-by: Mythri P K mythr...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 52 +++
1 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index b01ba46..379c21b 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -39,6 +39,7 @@
#include plat/omap4-keypad.h
#include video/omapdss.h
#include video/omap-panel-nokia-dsi.h
+#include video/omap-panel-picodlp.h
#include linux/wl12xx.h
#include mux.h
@@ -54,6 +55,7 @@
#define HDMI_GPIO_HPD 60 /* Hot plug pin for HDMI */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
#define DISPLAY_SEL_GPIO 59 /* LCD2/PicoDLP switch */
+#define DLP_POWER_ON_GPIO 40
#define GPIO_WIFI_PMENA54
#define GPIO_WIFI_IRQ 53
@@ -761,10 +763,59 @@ static struct omap_dss_device sdp4430_hdmi_device = {
.channel = OMAP_DSS_CHANNEL_DIGIT,
};
+static struct picodlp_panel_data sdp4430_picodlp_pdata = {
+ .picodlp_adapter_id = 2,
+ .emu_done_gpio = 44,
+ .pwrgood_gpio = 45,
+};
+
+static void sdp4430_picodlp_init(void)
+{
+ int r;
+ const struct gpio picodlp_gpios[] = {
+ {DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
+ DLP POWER ON},
+ {sdp4430_picodlp_pdata.emu_done_gpio, GPIOF_IN,
+ DLP EMU DONE},
+ {sdp4430_picodlp_pdata.pwrgood_gpio, GPIOF_OUT_INIT_LOW,
+ DLP PWRGOOD},
+ };
+
+ r = gpio_request_array(picodlp_gpios, ARRAY_SIZE(picodlp_gpios));
+ if (r)
+ pr_err(Cannot request PicoDLP GPIOs, error %d\n, r);
+}
+
+static int sdp4430_panel_enable_picodlp(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(DISPLAY_SEL_GPIO, 0);
+ gpio_set_value(DLP_POWER_ON_GPIO, 1);
+
+ return 0;
+}
+
+static void sdp4430_panel_disable_picodlp(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(DLP_POWER_ON_GPIO, 0);
+ gpio_set_value(DISPLAY_SEL_GPIO, 1);
+}
+
+static struct omap_dss_device sdp4430_picodlp_device = {
+ .name = picodlp,
+ .driver_name= picodlp_panel,
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .phy.dpi.data_lines = 24,
+ .channel= OMAP_DSS_CHANNEL_LCD2,
+ .platform_enable= sdp4430_panel_enable_picodlp,
+ .platform_disable = sdp4430_panel_disable_picodlp,
+ .data = sdp4430_picodlp_pdata,
+};
+
static struct omap_dss_device *sdp4430_dss_devices[] = {
sdp4430_lcd_device,
sdp4430_lcd2_device,
sdp4430_hdmi_device,
+ sdp4430_picodlp_device,
};
static struct omap_dss_board_info sdp4430_dss_data = {
@@ -785,6 +836,7 @@ static void omap_4430sdp_display_init(void)
sdp4430_lcd_init();
sdp4430_hdmi_mux_init();
+ sdp4430_picodlp_init();
omap_display_init(sdp4430_dss_data);
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5 v8] arm: omap: usb: ehci and ohci hwmod structures for omap4
On Thu, Sep 15, 2011 at 11:25 AM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Wed, Sep 14, 2011 at 10:20 PM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Keshava,
On 8/25/2011 9:01 AM, Munegowda, Keshava wrote:
From: Benoit Coussonb-cous...@ti.com
Following 4 hwmod structures are added:
UHH hwmod of usbhs with uhh base address and functional clock,
EHCI hwmod with irq and base address,
OHCI hwmod with irq and base address,
TLL hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Benoit Coussonb-cous...@ti.com
That version is really different compared to my original patch, so you
should highlight the diff you introduced.
Since there are too many changes are done compare to your original
patch; i prefer keep a single patch,rather
keeping your original patch and my changes are another patch.
Signed-off-by: Keshava Munegowdakeshava_mgo...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 247
1 files changed, 247 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6201422..0bc01dd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -68,6 +68,10 @@ static struct omap_hwmod omap44xx_mmc2_hwmod;
static struct omap_hwmod omap44xx_mpu_hwmod;
static struct omap_hwmod omap44xx_mpu_private_hwmod;
static struct omap_hwmod omap44xx_usb_otg_hs_hwmod;
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap44xx_usbhs_ohci_hwmod;
+static struct omap_hwmod omap44xx_usbhs_ehci_hwmod;
+static struct omap_hwmod omap44xx_usb_tll_hs_hwmod;
None of the 3 last entries are master, and thus should not need any backward
declaration.
yes, I will make this change.
/*
* Interconnects omap_hwmod structures
@@ -5336,6 +5340,245 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod =
{
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap44xx_usb_host_hs__l3_main_2 = {
+ .master =omap44xx_usb_host_hs_hwmod,
+ .slave =omap44xx_l3_main_2_hwmod,
+ .clk = l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP | MSTANDBY_FORCE |
+ MSTANDBY_NO | MSTANDBY_SMART |
+ MSTANDBY_SMART_WKUP),
Minor, but it should be:
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+ MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+ .sysc_fields =omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_usb_host_hs_hwmod_class = {
+ .name = usbhs_uhh,
+ .sysc =omap44xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_masters[] = {
+ omap44xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap44xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
In general, there is no name for unique entry. And if you need a name, you
should find something relevant considering this is local to the hwmod.
+ .pa_start = 0x4a064000,
+ .pa_end = 0x4a0647ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {} /* Terminating Entry */
That comment is useless. Paul added one space inside the terminator as well.
+};
+
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_host_hs = {
+ .master =omap44xx_l4_cfg_hwmod,
+ .slave =omap44xx_usb_host_hs_hwmod,
+ .clk = l4_div_ck,
+ .addr = omap44xx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_slaves[] = {
+ omap44xx_l4_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod = {
+ .name = usbhs_uhh,
+ .class =omap44xx_usb_host_hs_hwmod_class,
+ .clkdm_name = l3_init_clkdm,
+ .main_clk = usb_host_hs_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
OMAP4_CM_L3INIT_USB_HOST_CLKCTRL_OFFSET,
+ .context_offs =
OMAP4_RM_L3INIT_USB_HOST_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+ .slaves = omap44xx_usb_host_hs_slaves,
+
patch [PATCH] OMAP4: clock: re-enable previous clockdomain enable/disable failed to apply to 3.0-stable tree
The patch below does not apply to the 3.0-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to sta...@kernel.org. thanks, greg k-h -- original commit in Linus's tree -- From 9c5f560173a466582d91bb06f4e3d2bafb0fee5c Mon Sep 17 00:00:00 2001 From: Paul Walmsley p...@pwsan.com Date: Fri, 19 Aug 2011 16:59:56 -0600 Subject: [PATCH] OMAP4: clock: re-enable previous clockdomain enable/disable sequence MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit After commit 665d001338b494d6d62810aa99b4c0fa1a0884b9 (OMAP2+: hwmod: Follow the recommended PRCM module enable sequence), device drivers for OMAP IP blocks that do not use runtime PM can cause oopses or kernel instability[1][2]. This is because those non-runtime PM drivers do not use the hwmod code, which implements the correct IP block enable and disable sequence. Several options for dealing with this problem have been proposed: 1. Add a new field to the OMAP struct clk to mark clocks that are currently used by non-runtime PM drivers. Modify the clock code to use the old clockdomain sequence for these marked clocks. As drivers are converted to use runtime PM, remove the annotation from the clocks. 2. Similar to #1, but associate the flag with the struct omap_clk instead. 3. Add IDLEST wait support to the OMAP4 clock code, similar to the way it is implemented for OMAP2/3, and enable it in each struct clk currently used by non-runtime PM drivers. As drivers are converted to use runtime PM, remove the annotation from the clocks. 4. Do nothing; leave the problem to those responsible for the unconverted drivers. 5. Re-enable clock-based clockdomain control in the OMAP4 clock code. This would revert back to the behavior of Linux 3.0, simply with a slightly longer module enable/disable latency. Unfortunately, no approach seemed particularly good. Options 1 through 3 seemed unwise due to the following reasons: A. The OMAP struct clks are intended primarily to describe hardware clock nodes, and the intention is that no driver-specific data should be stored there (applies to #1) B. The resulting patch would have been quite large for the -rc series (applies to #1, #2, #3) C. The patch would have been a new, yet temporary hack; and similar fixes have drawn negative comments in the recent past (see for example [3]) Option 4 is undesirable because commit 665d001338b494d6d62810aa99b4c0fa1a0884b9 (OMAP2+: hwmod: Follow the recommended PRCM module enable sequence) has resulted in a less stable kernel; and kernel stability is more important than OMAP4 power management. Option 5 is the approach taken in this patch. This seemed to be the least intrusive approach for 3.1-rc. The approach in this patch was originally proposed by Ohad Ben-Cohen o...@wizery.com. I'm simply writing the commit message and passing it along. ... Thanks to Luciano Coelho coe...@ti.com for reporting the problem. Thanks to Ohad Ben-Cohen o...@wizery.com for tracking the problem down, generating a temporary workaround, and proposing a patch to deal with the problem. Thanks to Rajendra Nayak rna...@ti.com for proposing another patch to deal with the problem. Thanks to Felipe Balbi ba...@ti.com for comments. 1. Coelho, Luciano coe...@ti.com. _Re: Oops on ehci_hcd when booting 3.0.0-rc2 on panda_. Tue, 09 Aug 2011 14:26:08 +0300. Posted to the linux-omap@vger.kernel.org mailing list. Available from (among others) http://www.spinics.net/linux/lists/linux-omap/msg55213.html 2. Munegowda, Keshava keshava_mgo...@ti.com. _Re: Oops on ehci_hcd when booting 3.0.0-rc2 on panda_. Thu, 11 Aug 2011 13:51:05 +0530. Posted to the linux-omap@vger.kernel.org mailing list. Available from (among others) http://www.spinics.net/linux/lists/linux-omap/msg55371.html 3. King, Russell li...@arm.linux.org.uk. _Re: [PATCH 5/8] OMAP4: PM: TEMP: Prevent l3init from idling/force sleep_. Thu, 23 Jun 2011 16:22:49 +0100. Posted to the linux-omap@vger.kernel.org mailing list. Available from (among others) http://www.mail-archive.com/linux-omap@vger.kernel.org/msg51392.html Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Luciano Coelho coe...@ti.com Cc: Ohad Ben-Cohen o...@wizery.com Cc: Rajendra Nayak rna...@ti.com Cc: Benoît Cousson b-cous...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c index 2af0e3f..a3a1827 100644 --- a/arch/arm/mach-omap2/clock44xx_data.c +++ b/arch/arm/mach-omap2/clock44xx_data.c @@ -3379,7 +3379,13 @@ int __init omap4xxx_clk_init(void) } clk_init(omap2_clk_functions); - omap2_clk_disable_clkdm_control(); + + /* +* Must stay commented until all OMAP SoC drivers are +*
Re: [PATCH] DMAEngine: Define generic transfer request api
2011/9/15 Jassi Brar jaswinder.si...@linaro.org:
On 15 September 2011 12:01, Barry Song 21cn...@gmail.com wrote:
2011/9/13 Barry Song 21cn...@gmail.com:
2011/9/13 Jassi Brar jaswinder.si...@linaro.org:
On 13 September 2011 13:16, Barry Song 21cn...@gmail.com wrote:
if test pass, to the patch, and even for the moment, to the API's idea
Acked-by: Barry Song baohua.s...@csr.com
one issue i noticed is with a device_prep_dma_genxfer, i don't need
device_prep_slave_sg any more,
Yeah, the damengine would need to adapt to the fact that these
interleaved tranfers could be Mem-Mem as well as Mem-Dev
(even though yours could be only one type, but some dmacs could
do both).
How about:
BUG_ON(dma_has_cap(DMA_MEMCPY, device-cap_mask)
- !device-device_prep_dma_memcpy);
+ !device-device_prep_dma_memcpy
+ !device-device_prep_dma_genxfer);
BUG_ON(dma_has_cap(DMA_SLAVE, device-cap_mask)
- !device-device_prep_slave_sg);
+ !device-device_prep_slave_sg
+ !device-device_prep_dma_genxfer);
Seems ok, but please modify in a way you think is best and submit a patch
on top of this new api. Then it'll be easier to evaluate everything.
i think it should be handled by this patch but not a new one.
and i also think xfer_template is a bad name for a structure which is
an API. i'd like to add namespace for it and rename it to dma_genxfer.
or have any good suggestion?
I think xfer_template is better - which stresses the usage as having prepared
templates of transfers and only change src/dst address before submitting.
'device_prep_dma_genxfer' is the API which is already named so.
i'd like to send this together with BUG_ON(dma_has_cap(DMA_SLAVE,
device-cap_mask) !device-device_prep_dma_genxfer) as v2.
Is there no change other than skipping check for SLAVE when using this api ?
another change i want to do is a simple xfer alloc helper so that
every driver doesn't need a long line to alloc this struct with a zero
length array:
struct xfer_template *alloc_xfer_template(size_t frame_size)
{
kzalloc(sizeof(struct xfer_template) +
sizeof(struct data_chunk) * frame_size);
}
Then client can fill
xt.sgl[0].size
xt.sgl[0].icg
xt.sgl[1].size
xt.sgl[1].icg
...
xt.sgl[x].size
xt.sgl[x].icg
but xfer_template and data_chunk will have namespace.
-barry
--
To unsubscribe from this list: send the line unsubscribe 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 v15 06/12] OMAP: dmtimer: switch-over to platform device driver
Hi Tony, On Thu, Sep 15, 2011 at 11:12:53, DebBarma, Tarun Kanti wrote: On Thu, Sep 15, 2011 at 3:15 AM, Tony Lindgren t...@atomide.com wrote: * Tarun Kanti DebBarma tarun.ka...@ti.com [110908 13:36]: removed from timer code. New set of timers present on OMAP4 are now supported. Also, as we don't need the support for different register offsets for the first two omap4 timers, please rather implement support for the new timers and the timeouts directly in plat-omap/dmtimer.c. That way we can still keep the minimal timer support simple for clocksource and clockevent. Of course this means that we'll be only supporting the first two timers as system timers on omap4, but that's fine. Ok, I can make the change! But, do we have to keep OMAP5 in mind right now where even timers[1,2] require addition of offsets? We need clocksource clockevent to be able to work with timers requiring addition of offsets. Without this AM335X, TI816X and TI814X SoC's will not boot. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] PM QoS: implement the OMAP low level constraints management code
Paul, Rafael, Kevin, Ping on this patch set. IIUC the intention is to have this series merged in 3.2, is that correct? Regards, Jean On Fri, Sep 2, 2011 at 3:13 PM, Jean Pihet jean.pi...@newoldbits.com wrote: . create a PM layer plugin for per-device constraints, compiled under CONFIG_OMAP_PM_CONSTRAINTS=y . implement the devices wake-up latency constraints using the global device PM QoS notification handler which applies the constraints to the underlying layer . implement the low level code which controls the power domains next power states, through the hwmod and pwrdm layers . add cpuidle and power domains wake-up latency figures for OMAP3, cf. [1] for the details on where the numbers are coming from . cpuidle is a CPU centric framework so it decides the MPU next power state based on the MPU exit_latency and target_residency figures. The rest of the power domains get their next power state programmed from the devices PM QoS framework, via the devices wake-up latency constraints. . convert the OMAP I2C driver to the PM QoS API for MPU latency constraints ToDo: 1. validate the constraints framework on OMAP4 HW (done on OMAP3) 2. re-visit the OMAP power domains states initialization procedure. Currently the power states that have been changed from the constraints API which were applied before the initialization of the power domains are lost Based on the pm-qos branch of the linux-pm git tree (3.1.0-rc3), cf. [2]. Tested on OMAP3 Beagleboard (ES2.x) with constraints on MPU, CORE, PER in RETention and OFF modes. [1] http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement [2] git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git Jean Pihet (8): OMAP: convert I2C driver to PM QoS for latency constraints OMAP: PM: create a PM layer plugin for per-device constraints OMAP2+: powerdomain: control power domains next state OMAP3: powerdomain data: add wake-up latency figures OMAP2+: omap_hwmod: manage the wake-up latency constraints OMAP: PM CONSTRAINTS: implement the devices wake-up latency constraints OMAP2+: cpuidle only influences the MPU state OMAP3: update cpuidle latency and threshold figures arch/arm/mach-omap2/cpuidle34xx.c | 56 ++--- arch/arm/mach-omap2/omap_hwmod.c | 26 ++- arch/arm/mach-omap2/pm.h | 17 ++- arch/arm/mach-omap2/powerdomain.c | 190 ++ arch/arm/mach-omap2/powerdomain.h | 33 +++- arch/arm/mach-omap2/powerdomains3xxx_data.c | 78 ++ arch/arm/plat-omap/Kconfig | 7 + arch/arm/plat-omap/Makefile | 1 + arch/arm/plat-omap/i2c.c | 20 -- arch/arm/plat-omap/include/plat/omap-pm.h | 128 -- arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 + arch/arm/plat-omap/omap-pm-constraints.c | 350 ++ arch/arm/plat-omap/omap-pm-noop.c | 89 --- drivers/i2c/busses/i2c-omap.c | 31 ++- 14 files changed, 737 insertions(+), 291 deletions(-) create mode 100644 arch/arm/plat-omap/omap-pm-constraints.c -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
Hi Santosh, On 9/14/2011 7:22 PM, Shilimkar, Santosh wrote: On Wednesday 14 September 2011 10:48 PM, Tony Lindgren wrote: * Santoshsantosh.shilim...@ti.com [110914 09:40]: On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote: * Santoshsantosh.shilim...@ti.com[110914 09:16]: Thanks for the clarification. It seems to me the spec is most likely wrong as we've had the GIC working for over two years now without doing anything with the wakeup gen registers :) It's working because CPU clockdomain are never put under HW supervised mode and they are kept in force wakeup. Clock-domain never idles on mainline code. PM series will put the clock-domains under HW supervison as needed to achieve any low power states and then all sorts of corner cases will come out. But again the wakeup gen triggers only do something when hitting idle. There should be no use for them during runtime, right? You missed my point in the description. Clockdomain inactive doesn't depend on idle or WFI execution. Under HW supervison CPU clock domain can get into inactive when CPU is stalled and waiting for a read response from slow interconnect. I'm a little bit confused by that statement... I'm wondering how the PRCM can gate the CPU/MPU clock and re-enable it if the MPU is gated? What kind of event can wakeup the CPU in case of CPU stalled? The spec seems to indicate that wakeupgen is needed only if CPU are in WFI. It is even written: CPUx will change power state only when StandbyWFI is asserted.. Even a WFE is not supposed to trigger a standby. How can the CPU be inactive at clock domain level without a WFI? Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] iommu/omap: Fix build error with !IOMMU_SUPPORT
On Wed, Sep 14, 2011 at 02:57:13PM -0400, Ohad Ben-Cohen wrote: On Wed, Sep 14, 2011 at 5:07 PM, Joerg Roedel joerg.roe...@amd.com wrote: Without this patch it is possible to select the VIDEO_OMAP3 driver which then selects OMAP_IOVMM. But the omap iommu driver is not compiled without IOMMU_SUPPORT enabled. Fix that by forcing OMAP_IOMMU and OMAP_IOVMM are enabled before VIDEO_OMAP3 can be selected. I'm ok with this but wouldn't it be simpler if we drop IOMMU_SUPPORT altogether (and just use a plain menu instead) ? Users will then be presented with only a single iommu-related question: whether they want their iommu driver built or not. This doesn't work on platforms that may have more than one possible iommu driver, like x86 for example. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 05/11] TWL: regulator: Make twl-regulator driver extract data from DT
Modify the twl regulator driver to extract the regulator_init_data from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)
Signed-off-by: Rajendra Nayak rna...@ti.com
---
drivers/regulator/twl-regulator.c | 28 +---
1 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index ee8747f..df1b95a 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -17,6 +17,8 @@
#include linux/regulator/driver.h
#include linux/regulator/machine.h
#include linux/i2c/twl.h
+#include linux/of.h
+#include linux/of_regulator.h
/*
@@ -1011,6 +1013,9 @@ static int __devinit twlreg_probe(struct platform_device
*pdev)
struct regulation_constraints *c;
struct regulator_dev*rdev;
+ if (pdev-dev.of_node)
+ of_property_read_u32(pdev-dev.of_node, ti,reg-id, pdev-id);
+
for (i = 0, info = NULL; i ARRAY_SIZE(twl_regs); i++) {
if (twl_regs[i].desc.id != pdev-id)
continue;
@@ -1020,7 +1025,11 @@ static int __devinit twlreg_probe(struct platform_device
*pdev)
if (!info)
return -ENODEV;
- initdata = pdev-dev.platform_data;
+ if (pdev-dev.of_node)
+ initdata = of_get_regulator_init_data(pdev-dev.of_node);
+ else
+ initdata = pdev-dev.platform_data;
+
if (!initdata)
return -EINVAL;
@@ -1101,14 +1110,27 @@ static int __devexit twlreg_remove(struct
platform_device *pdev)
MODULE_ALIAS(platform:twl_reg);
+#if defined(CONFIG_OF)
+static const struct of_device_id twl_of_match[] __devinitconst = {
+ { .compatible = ti,twl-reg, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, twl_of_match);
+#else
+#define twl_of_match NULL
+#endif
+
static struct platform_driver twlreg_driver = {
.probe = twlreg_probe,
.remove = __devexit_p(twlreg_remove),
/* NOTE: short name, to work around driver model truncation of
* twl_regulator.12 (and friends) to twl_regulator.1.
*/
- .driver.name= twl_reg,
- .driver.owner = THIS_MODULE,
+ .driver = {
+ .name = twl_reg,
+ .owner = THIS_MODULE,
+ .of_match_table = twl_of_match,
+ },
};
static int __init twlreg_init(void)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 02/11] regulator: Fix error check in set_consumer_device_supply
The parameters to set_consumer_device_supply() can be considered invalid (and hence it could return -EINVAL) if nether consumer_dev nor consumer_dev_name are passed, not when *both* are passed. Signed-off-by: Rajendra Nayak rna...@ti.com --- drivers/regulator/core.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index d8e6a42..9365359 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -981,7 +981,7 @@ static int set_consumer_device_supply(struct regulator_dev *rdev, struct regulator_map *node; int has_dev; - if (consumer_dev consumer_dev_name) + if (!consumer_dev !consumer_dev_name) return -EINVAL; if (!consumer_dev_name consumer_dev) -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 07/11] regulator: Make fixed regulator driver extract data from DT
Modify the fixed regulator driver to extract fixed_voltage_config from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)
Signed-off-by: Rajendra Nayak rna...@ti.com
---
drivers/regulator/fixed.c | 20 +++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
index 2fe9d99..a214b30 100644
--- a/drivers/regulator/fixed.c
+++ b/drivers/regulator/fixed.c
@@ -26,6 +26,8 @@
#include linux/gpio.h
#include linux/delay.h
#include linux/slab.h
+#include linux/of.h
+#include linux/of_regulator.h
struct fixed_voltage_data {
struct regulator_desc desc;
@@ -104,10 +106,15 @@ static struct regulator_ops fixed_voltage_ops = {
static int __devinit reg_fixed_voltage_probe(struct platform_device *pdev)
{
- struct fixed_voltage_config *config = pdev-dev.platform_data;
+ struct fixed_voltage_config *config;
struct fixed_voltage_data *drvdata;
int ret;
+ if (pdev-dev.of_node)
+ config = of_get_fixed_voltage_config(pdev-dev.of_node);
+ else
+ config = pdev-dev.platform_data;
+
drvdata = kzalloc(sizeof(struct fixed_voltage_data), GFP_KERNEL);
if (drvdata == NULL) {
dev_err(pdev-dev, Failed to allocate device data\n);
@@ -216,12 +223,23 @@ static int __devexit reg_fixed_voltage_remove(struct
platform_device *pdev)
return 0;
}
+#if defined(CONFIG_OF)
+static const struct of_device_id fixed_of_match[] __devinitconst = {
+ { .compatible = regulator-fixed, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, fixed_of_match);
+#else
+#define fixed_of_match NULL
+#endif
+
static struct platform_driver regulator_fixed_voltage_driver = {
.probe = reg_fixed_voltage_probe,
.remove = __devexit_p(reg_fixed_voltage_remove),
.driver = {
.name = reg-fixed-voltage,
.owner = THIS_MODULE,
+ .of_match_table = fixed_of_match,
},
};
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 08/11] omap4: panda: Pass fixed regulator data from DT
Pass the fixed voltage regulator information for
omap4panda board from device tree.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 0a83e3f..9c34c7f 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -52,6 +52,16 @@
interrupts = 11;
reg = 0;
};
+
+ vwl1271-fixedregulator {
+ compatible = regulator-fixed,ti,twl-reg;
+ supply-name = vwl1271;
+ microvolts = 180;
+ gpio = 43;
+ startup-delay = 7;
+ enable-high;
+ enabled-at-boot;
+ };
};
};
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 03/11] DT: regulator: Helper routine to extract regulator_init_data
The helper routine is meant to be used by regulator drivers
to extract the regulator_init_data structure passed from device tree.
'consumer_supplies' which is part of regulator_init_data is not extracted
as the regulator consumer mappings are passed through DT differently,
implemented in subsequent patches.
Also add documentation for regulator bindings to be used to pass
regulator_init_data struct information from device tree.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
.../devicetree/bindings/regulator/regulator.txt| 37 +
drivers/of/Kconfig |6 ++
drivers/of/Makefile|1 +
drivers/of/of_regulator.c | 85
include/linux/of_regulator.h | 23 +
5 files changed, 152 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt
create mode 100644 drivers/of/of_regulator.c
create mode 100644 include/linux/of_regulator.h
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt
b/Documentation/devicetree/bindings/regulator/regulator.txt
new file mode 100644
index 000..001e5ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -0,0 +1,37 @@
+Voltage/Current Regulators
+
+Required properties:
+- compatible: Must be regulator;
+
+Optional properties:
+- supply-regulator: Name of the parent regulator
+- min-uV: smallest voltage consumers may set
+- max-uV: largest voltage consumers may set
+- uV-offset: Offset applied to voltages from consumer to compensate for
voltage drops
+- min-uA: smallest current consumers may set
+- max-uA: largest current consumers may set
+- mode-fast: boolean, Can handle fast changes in its load
+- mode-normal: boolean, Normal regulator power supply mode
+- mode-idle: boolean, Can be more efficient during light loads
+- mode-standby: boolean, Can be most efficient during light loads
+- change-voltage: boolean, Output voltage can be changed by software
+- change-current: boolean, Output current can be chnaged by software
+- change-mode: boolean, Operating mode can be changed by software
+- change-status: boolean, Enable/Disable control for regulator exists
+- change-drms: boolean, Dynamic regulator mode switching is enabled
+- input-uV: Input voltage for regulator when supplied by another regulator
+- initial-mode: Mode to set at startup
+- always-on: boolean, regulator should never be disabled
+- boot-on: bootloader/firmware enabled regulator
+- apply-uV: apply uV constraint if min == max
+
+Example:
+
+ xyz-regulator: regulator@0 {
+ compatible = regulator;
+ min-uV = 100;
+ max-uV = 250;
+ mode-fast;
+ change-voltage;
+ always-on;
+ };
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index b3bfea5..296b96d 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -87,4 +87,10 @@ config OF_PCI_IRQ
help
OpenFirmware PCI IRQ routing helpers
+config OF_REGULATOR
+ def_bool y
+ depends on REGULATOR
+ help
+ OpenFirmware regulator framework helpers
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index 74b959c..bea2852 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_OF_SPI) += of_spi.o
obj-$(CONFIG_OF_MDIO) += of_mdio.o
obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
+obj-$(CONFIG_OF_REGULATOR) += of_regulator.o
diff --git a/drivers/of/of_regulator.c b/drivers/of/of_regulator.c
new file mode 100644
index 000..f01d275
--- /dev/null
+++ b/drivers/of/of_regulator.c
@@ -0,0 +1,85 @@
+/*
+ * OF helpers for regulator framework
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Rajendra Nayak rna...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/slab.h
+#include linux/of.h
+#include linux/regulator/machine.h
+
+static void of_get_regulation_constraints(struct device_node *np,
+ struct regulator_init_data **init_data)
+{
+ unsigned int valid_modes_mask = 0, valid_ops_mask = 0;
+
+ of_property_read_u32(np, min-uV, (*init_data)-constraints.min_uV);
+ of_property_read_u32(np, max-uV, (*init_data)-constraints.max_uV);
+ of_property_read_u32(np, uV-offset,
(*init_data)-constraints.uV_offset);
+ of_property_read_u32(np, min-uA, (*init_data)-constraints.min_uA);
+ of_property_read_u32(np, max-uA, (*init_data)-constraints.max_uA);
+
+ /* valid modes mask */
+ if (of_find_property(np, mode-fast, NULL))
+ valid_modes_mask |= REGULATOR_MODE_FAST;
+
[RFC PATCH 06/11] DT: regulator: Helper routine to extract fixed_voltage_config
The helper routine defined here (of_get_fixed_voltage_config) can
be used to extract information about fixed regulators (which are not
software controlable) from device tree.
Add documenation about additional bindings for fixed
regulators that can be passed through DT.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
.../devicetree/bindings/regulator/regulator.txt| 19
drivers/of/of_regulator.c | 31
include/linux/of_regulator.h |7
3 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt
b/Documentation/devicetree/bindings/regulator/regulator.txt
index 001e5ce..f8c51d8 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -2,6 +2,8 @@ Voltage/Current Regulators
Required properties:
- compatible: Must be regulator;
+or
+- compatible: Must be regulator-fixed; /* For Fixed volatge regulator */
Optional properties:
- supply-regulator: Name of the parent regulator
@@ -24,6 +26,13 @@ Optional properties:
- always-on: boolean, regulator should never be disabled
- boot-on: bootloader/firmware enabled regulator
- apply-uV: apply uV constraint if min == max
+# For fixed voltage regulators
+- supply-name: Name of the regulator supply
+- microvolts: Output voltage of regulator
+- gpio: gpio to use for enable control
+- startup-delay: startup time in microseconds
+- enable-high: Polarity of enable GPIO, 1 = Active High, 0 = Active low
+- enabled-at-boot: 1 = yes, 0 = no
Example:
@@ -35,3 +44,13 @@ Example:
change-voltage;
always-on;
};
+
+ abc-fixedregulator {
+ compatible = regulator-fixed;
+ supply-name = fixed-supply;
+ microvolts = 180;
+ gpio = 43;
+ startup-delay = 7;
+ enable-high;
+ enabled-at-boot;
+ };
diff --git a/drivers/of/of_regulator.c b/drivers/of/of_regulator.c
index f01d275..4d7a49d 100644
--- a/drivers/of/of_regulator.c
+++ b/drivers/of/of_regulator.c
@@ -13,6 +13,7 @@
#include linux/slab.h
#include linux/of.h
#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
static void of_get_regulation_constraints(struct device_node *np,
struct regulator_init_data **init_data)
@@ -83,3 +84,33 @@ struct regulator_init_data
*of_get_regulator_init_data(struct device_node *np)
return init_data;
}
EXPORT_SYMBOL(of_get_regulator_init_data);
+
+/**
+ * of_get_fixed_voltage_config - extract fixed_voltage_config structure info
+ * @np: Pointer to fixed-regulator device tree node
+ *
+ * Populates fixed_voltage_config structure by extracting data from device
+ * tree node, returns a pointer to the populated structure of NULL if memory
+ * alloc fails.
+ */
+struct fixed_voltage_config *of_get_fixed_voltage_config(struct device_node
*np)
+{
+ struct fixed_voltage_config *config;
+
+ config = kzalloc(sizeof(struct fixed_voltage_config), GFP_KERNEL);
+ if (!config)
+ return NULL;
+
+ config-supply_name = (char *)of_get_property(np, supply-name, NULL);
+ of_property_read_u32(np, microvolts, config-microvolts);
+ of_property_read_u32(np, gpio, config-gpio);
+ of_property_read_u32(np, startup-delay, config-startup_delay);
+ if (of_find_property(np, enable-high, NULL))
+ config-enable_high = true;
+ if (of_find_property(np, enabled-at-boot, NULL))
+ config-enabled_at_boot = true;
+ config-init_data = of_get_regulator_init_data(np);
+
+ return config;
+}
+EXPORT_SYMBOL(of_get_fixed_voltage_config);
diff --git a/include/linux/of_regulator.h b/include/linux/of_regulator.h
index 5eb048c..39860c5 100644
--- a/include/linux/of_regulator.h
+++ b/include/linux/of_regulator.h
@@ -11,12 +11,19 @@
#if defined(CONFIG_OF_REGULATOR)
extern struct regulator_init_data
*of_get_regulator_init_data(struct device_node *np);
+extern struct fixed_voltage_config
+ *of_get_fixed_voltage_config(struct device_node *np);
#else
static inline struct regulator_init_data
*of_get_regulator_init_data(struct device_node *np)
{
return NULL;
}
+static inline struct fixed_voltage_config
+ *of_get_fixed_voltage_config(struct device_node *np)
+{
+ return NULL;
+}
#endif /* CONFIG_OF_REGULATOR */
#endif /* __LINUX_OF_REG_H */
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 01/11] OMAP: TWL: Clean up mode and ops mask passed from board files
The TWL driver seems to set the default .valid_modes_mask to
(REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY) and .valid_ops_mask
to (REGULATOR_CHANGE_VOLTAGE | REGULATOR_CHANGE_MODE | REGULATOR_CHANGE_STATUS)
for all the registered regulators.
There is no need for all the board files to pass this information
additionally, when the driver already sets them by default.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/board-2430sdp.c |5 --
arch/arm/mach-omap2/board-3430sdp.c | 30 --
arch/arm/mach-omap2/board-4430sdp.c | 10 -
arch/arm/mach-omap2/board-cm-t35.c | 10 -
arch/arm/mach-omap2/board-devkit8000.c | 13 --
arch/arm/mach-omap2/board-igep0020.c | 11 -
arch/arm/mach-omap2/board-ldp.c |9
arch/arm/mach-omap2/board-omap3beagle.c | 10 -
arch/arm/mach-omap2/board-omap3evm.c | 14 ---
arch/arm/mach-omap2/board-omap3logic.c |5 --
arch/arm/mach-omap2/board-omap3pandora.c | 26
arch/arm/mach-omap2/board-omap3stalker.c |8
arch/arm/mach-omap2/board-omap3touchbook.c | 10 -
arch/arm/mach-omap2/board-overo.c|5 --
arch/arm/mach-omap2/board-rm680.c|4 --
arch/arm/mach-omap2/board-rx51-peripherals.c | 55 --
arch/arm/mach-omap2/board-zoom-peripherals.c | 14 ---
arch/arm/mach-omap2/twl-common.c | 44
18 files changed, 0 insertions(+), 283 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 2028464..32154f4 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -156,11 +156,6 @@ static struct regulator_init_data sdp2430_vmmc1 = {
.constraints = {
.min_uV = 185,
.max_uV = 315,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(sdp2430_vmmc1_supplies),
.consumer_supplies = sdp2430_vmmc1_supplies[0],
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index bd600cf..01ce6df 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -306,10 +306,6 @@ static struct regulator_init_data sdp3430_vaux1 = {
.min_uV = 280,
.max_uV = 280,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
};
@@ -319,10 +315,6 @@ static struct regulator_init_data sdp3430_vaux2 = {
.min_uV = 280,
.max_uV = 280,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
};
@@ -332,10 +324,6 @@ static struct regulator_init_data sdp3430_vaux3 = {
.min_uV = 280,
.max_uV = 280,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(sdp3430_vaux3_supplies),
.consumer_supplies = sdp3430_vaux3_supplies,
@@ -347,10 +335,6 @@ static struct regulator_init_data sdp3430_vaux4 = {
.min_uV = 180,
.max_uV = 180,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
};
@@ -359,11 +343,6 @@ static struct regulator_init_data sdp3430_vmmc1 = {
.constraints = {
.min_uV = 185,
.max_uV = 315,
-
[RFC PATCH 00/11] Device tree support for regulators
Hi Grant, Mark, This RFC is an attempt to move the regulator mappings from board files into device tree for OMAP. In the process I have defined some helper routines for regulators and defined the bindings for these. The patches are based on top of Benoit's series which adds DT support for i2c and twl for OMAP from here git://gitorious.org/omap-pm/linux.git for_3.2/5_omap_dt_i2c_twl I know Benoit is planning a respin of the series soon, in which he intends to register all twl child nodes as platform devices, which would mean I just drop the last patch in this series. The first couple of patches in the series are just fixes and cleanups leading to the regulator DT migration. The series is tested on OMAP4SDP and OMAP4PANDA boards. regards, Rajendra Rajendra Nayak (11): OMAP: TWL: Clean up mode and ops mask passed from board files regulator: Fix error check in set_consumer_device_supply DT: regulator: Helper routine to extract regulator_init_data omap4: SDP: Pass regulator_init_data from DT TWL: regulator: Make twl-regulator driver extract data from DT DT: regulator: Helper routine to extract fixed_voltage_config regulator: Make fixed regulator driver extract data from DT omap4: panda: Pass fixed regulator data from DT DT: regulator: Helper to extract regulator node based on supply name regulator: Implement consumer regulator mapping from device tree DT: regulator: register regulators as platform devices .../devicetree/bindings/regulator/regulator.txt| 56 ++ .../bindings/regulator/twl-regulator.txt | 18 ++ arch/arm/boot/dts/omap4-panda.dts | 10 + arch/arm/boot/dts/omap4-sdp.dts| 16 ++ arch/arm/mach-omap2/board-2430sdp.c|5 - arch/arm/mach-omap2/board-3430sdp.c| 30 arch/arm/mach-omap2/board-4430sdp.c| 10 - arch/arm/mach-omap2/board-cm-t35.c | 10 - arch/arm/mach-omap2/board-devkit8000.c | 13 -- arch/arm/mach-omap2/board-igep0020.c | 11 -- arch/arm/mach-omap2/board-ldp.c|9 - arch/arm/mach-omap2/board-omap3beagle.c| 10 - arch/arm/mach-omap2/board-omap3evm.c | 14 -- arch/arm/mach-omap2/board-omap3logic.c |5 - arch/arm/mach-omap2/board-omap3pandora.c | 26 --- arch/arm/mach-omap2/board-omap3stalker.c |8 - arch/arm/mach-omap2/board-omap3touchbook.c | 10 - arch/arm/mach-omap2/board-overo.c |5 - arch/arm/mach-omap2/board-rm680.c |4 - arch/arm/mach-omap2/board-rx51-peripherals.c | 55 -- arch/arm/mach-omap2/board-zoom-peripherals.c | 14 -- arch/arm/mach-omap2/twl-common.c | 44 - drivers/mfd/twl-core.c |3 + drivers/of/Kconfig |6 + drivers/of/Makefile|1 + drivers/of/of_regulator.c | 183 drivers/regulator/core.c | 25 +++- drivers/regulator/fixed.c | 20 ++- drivers/regulator/twl-regulator.c | 28 +++- include/linux/of_regulator.h | 42 + include/linux/regulator/driver.h |3 + 31 files changed, 406 insertions(+), 288 deletions(-) create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt create mode 100644 Documentation/devicetree/bindings/regulator/twl-regulator.txt create mode 100644 drivers/of/of_regulator.c create mode 100644 include/linux/of_regulator.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 11/11] DT: regulator: register regulators as platform devices
of_regulator_register_devices() registers all regulators
as platform devices. Use this to register all twl regulators
from the twl driver probe.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
drivers/mfd/twl-core.c |3 +++
drivers/of/of_regulator.c| 30 ++
include/linux/of_regulator.h |5 +
3 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index a12af12..f210e28 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -36,6 +36,7 @@
#include linux/slab.h
#include linux/of_irq.h
#include linux/irqdomain.h
+#include linux/of_regulator.h
#include linux/regulator/machine.h
@@ -1357,6 +1358,8 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
else
status = add_children(pdata, id-driver_data);
+ of_regulator_register_devices(node);
+
fail:
if (status 0)
twl_remove(client);
diff --git a/drivers/of/of_regulator.c b/drivers/of/of_regulator.c
index 6f8fd4e..0312a6a 100644
--- a/drivers/of/of_regulator.c
+++ b/drivers/of/of_regulator.c
@@ -12,6 +12,7 @@
#include linux/slab.h
#include linux/of.h
+#include linux/of_platform.h
#include linux/regulator/machine.h
#include linux/regulator/fixed.h
@@ -151,3 +152,32 @@ struct device_node *of_get_regulator(struct device *dev,
const char *supply)
return regnode;
}
EXPORT_SYMBOL(of_get_regulator);
+
+/**
+ * of_regulator_register_devices - Register regulator devices to platform bus
+ * @np:Parent device node with regulator child nodes
+ *
+ * Registers all the regulator and regulator-fixed nodes as platform devices
+ *
+ */
+void of_regulator_register_devices(struct device_node *np)
+{
+ struct device_node *child;
+ struct platform_device *dev;
+
+ for_each_child_of_node(np, child) {
+ if (of_device_is_compatible(child, regulator)
+ || of_device_is_compatible(child, regulator-fixed)) {
+ dev = of_device_alloc(child, NULL, NULL);
+ if (!dev)
+ return;
+ dev-dev.bus = platform_bus_type;
+ if (of_device_add(dev) != 0) {
+ platform_device_put(dev);
+ return;
+ }
+ }
+ }
+ return;
+}
+
diff --git a/include/linux/of_regulator.h b/include/linux/of_regulator.h
index 5fc7329..38cf7e3 100644
--- a/include/linux/of_regulator.h
+++ b/include/linux/of_regulator.h
@@ -15,6 +15,7 @@ extern struct fixed_voltage_config
*of_get_fixed_voltage_config(struct device_node *np);
extern struct device_node *of_get_regulator(struct device *dev,
const char *id);
+extern void of_regulator_register_devices(struct device_node *np);
#else
static inline struct regulator_init_data
*of_get_regulator_init_data(struct device_node *np)
@@ -31,6 +32,10 @@ static inline struct device_node *of_get_regulator(struct
device *dev,
{
return NULL;
}
+static inline void of_regulator_register_devices(struct device_node *np)
+{
+ return NULL;
+}
#endif /* CONFIG_OF_REGULATOR */
#endif /* __LINUX_OF_REG_H */
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 04/11] omap4: SDP: Pass regulator_init_data from DT
Pass regulator_init_data information for omap4sdp from device tree so the
regulator driver can then use the regulator helper
routine to extract and use them during the driver probe().
Add documentation for TWL regulator specific bindings.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
.../bindings/regulator/twl-regulator.txt | 18 ++
arch/arm/boot/dts/omap4-sdp.dts| 16
2 files changed, 34 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/regulator/twl-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/twl-regulator.txt
b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
new file mode 100644
index 000..59df44b
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
@@ -0,0 +1,18 @@
+TWL family of regulators
+
+Required properties:
+- compatible: Must be regulator,ti,twl-reg;
+
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+- ti,reg-id: Identifier for a TWL regulator, defined in linux/i2c/twl.h file.
+
+Example:
+
+ xyz-regulator: regulator@0 {
+ compatible = regulator,ti,twl-reg;
+ ti,reg-id = 37; /* TWL6030_REG_VAUX1_6030 */
+ min-uV = 100;
+ max-uV = 300;
+ apply-uV;
+ };
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 14faf92..2a613e2 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -52,6 +52,22 @@
interrupts = 11;
reg = 0;
};
+
+ vaux1-regulator: regulator@0 {
+ compatible = regulator,ti,twl-reg;
+ ti,reg-id = 37; /* TWL6030_REG_VAUX1_6030 */
+ min-uV = 100;
+ max-uV = 300;
+ apply-uV;
+ };
+
+ vusim-regulator: regulator@1 {
+ compatible = regulator,ti,twl-reg;
+ ti,reg-id = 42; /* TWL6030_REG_VUSIM */
+ min-uV = 120;
+ max-uV = 290;
+ apply_uV;
+ };
};
};
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 10/11] regulator: Implement consumer regulator mapping from device tree
With device tree, the consumer regulator mapping is deferred till
a regulator_get is called from the corresponding device driver,
instead of being done during regulator_register.
This avoids a complete scan of all DT nodes to identify consumers
for all regulators.
Devices can assocaite with one or more regulators by providing a
list of phandles and supply names.
For Example:
devicenode: node@0x0 {
...
...
regulator = regulator1,regulator2;
regulator-names = supply1,supply2;
};
When a device driver calls a regulator_get, specifying the
supply name, the phandle and eventually the regulator node
is extracted from the device and a mapping created by calling
set_consumer_device_supply().
Signed-off-by: Rajendra Nayak rna...@ti.com
---
drivers/regulator/core.c | 23 +++
include/linux/regulator/driver.h |3 +++
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 9365359..61da2e7 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -25,6 +25,8 @@
#include linux/mutex.h
#include linux/suspend.h
#include linux/delay.h
+#include linux/of.h
+#include linux/of_regulator.h
#include linux/regulator/consumer.h
#include linux/regulator/driver.h
#include linux/regulator/machine.h
@@ -1167,6 +1169,15 @@ static struct regulator *_regulator_get(struct device
*dev, const char *id,
mutex_lock(regulator_list_mutex);
+#ifdef CONFIG_OF
+ struct device_node *node;
+ node = of_get_regulator(dev, id);
+ if (!node)
+ goto out;
+ list_for_each_entry(rdev, regulator_list, list)
+ if (node == rdev-node)
+ goto found;
+#else
list_for_each_entry(map, regulator_map_list, list) {
/* If the mapping has a device set up it must match */
if (map-dev_name
@@ -1178,6 +1189,7 @@ static struct regulator *_regulator_get(struct device
*dev, const char *id,
goto found;
}
}
+#endif
if (board_wants_dummy_regulator) {
rdev = dummy_regulator_rdev;
@@ -1216,6 +1228,15 @@ found:
if (!try_module_get(rdev-owner))
goto out;
+#ifdef CONFIG_OF
+ ret = set_consumer_device_supply(rdev, dev, devname, id);
+ if (ret 0) {
+ dev_err(dev, Failed to set supply %d\n, ret);
+ unset_regulator_supplies(rdev);
+ goto out;
+ }
+#endif
+
regulator = create_regulator(rdev, dev, id);
if (regulator == NULL) {
regulator = ERR_PTR(-ENOMEM);
@@ -2619,6 +2640,8 @@ struct regulator_dev *regulator_register(struct
regulator_desc *regulator_desc,
rdev-reg_data = driver_data;
rdev-owner = regulator_desc-owner;
rdev-desc = regulator_desc;
+ if (dev dev-of_node)
+ rdev-node = dev-of_node;
INIT_LIST_HEAD(rdev-consumer_list);
INIT_LIST_HEAD(rdev-list);
BLOCKING_INIT_NOTIFIER_HEAD(rdev-notifier);
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index 1a80bc7..4aebbf5 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -196,6 +196,9 @@ struct regulator_dev {
struct mutex mutex; /* consumer lock */
struct module *owner;
struct device dev;
+#ifdef CONFIG_OF
+ struct device_node *node;
+#endif
struct regulation_constraints *constraints;
struct regulator *supply; /* for tree */
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 09/11] DT: regulator: Helper to extract regulator node based on supply name
Device nodes in DT can associate themselves with one or more
regulators by providing a list of phandles (to regulator nodes)
and corresponding supply names.
For Example:
devicenode: node@0x0 {
...
...
regulator = regulator1,regulator2;
regulator-names = supply1,supply2;
};
of_get_regulator() extracts the regulator node for a given
device, based on the supply name.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
drivers/of/of_regulator.c| 37 +
include/linux/of_regulator.h |7 +++
2 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/drivers/of/of_regulator.c b/drivers/of/of_regulator.c
index 4d7a49d..6f8fd4e 100644
--- a/drivers/of/of_regulator.c
+++ b/drivers/of/of_regulator.c
@@ -114,3 +114,40 @@ struct fixed_voltage_config
*of_get_fixed_voltage_config(struct device_node *np)
return config;
}
EXPORT_SYMBOL(of_get_fixed_voltage_config);
+
+/**
+ * of_get_regulator - get a regulator device node based on supply name
+ * @dev: Device pointer for the consumer (of regulator) device
+ * @supply: regulator supply name
+ *
+ * Extract the regulator device node corresponding to the supply name.
+ * retruns the device node corresponding to the regulator if found, else
+ * returns NULL.
+ */
+struct device_node *of_get_regulator(struct device *dev, const char *supply)
+{
+ struct device_node *regnode = NULL;
+ u32 reghandle;
+ int regsz, namesz;
+ const void *regprop;
+ const char *namesprop;
+
+ regprop = of_get_property(dev-of_node, regulator, regsz);
+ namesprop = of_get_property(dev-of_node, regulator-names, namesz);
+ if (!regprop || !namesprop)
+ return NULL;
+
+ while (regsz namesz) {
+ if (!strcmp(namesprop, supply)) {
+ reghandle = be32_to_cpup(regprop);
+ regnode = of_find_node_by_phandle(reghandle);
+ break;
+ }
+ regsz -= 4;
+ regprop += 4;
+ namesz -= strlen(namesprop) + 1;
+ namesprop += strlen(namesprop) + 1;
+ }
+ return regnode;
+}
+EXPORT_SYMBOL(of_get_regulator);
diff --git a/include/linux/of_regulator.h b/include/linux/of_regulator.h
index 39860c5..5fc7329 100644
--- a/include/linux/of_regulator.h
+++ b/include/linux/of_regulator.h
@@ -13,6 +13,8 @@ extern struct regulator_init_data
*of_get_regulator_init_data(struct device_node *np);
extern struct fixed_voltage_config
*of_get_fixed_voltage_config(struct device_node *np);
+extern struct device_node *of_get_regulator(struct device *dev,
+ const char *id);
#else
static inline struct regulator_init_data
*of_get_regulator_init_data(struct device_node *np)
@@ -24,6 +26,11 @@ static inline struct fixed_voltage_config
{
return NULL;
}
+static inline struct device_node *of_get_regulator(struct device *dev,
+ const char *id)
+{
+ return NULL;
+}
#endif /* CONFIG_OF_REGULATOR */
#endif /* __LINUX_OF_REG_H */
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
On Thu, Sep 15, 2011 at 3:06 PM, Cousson, Benoit b-cous...@ti.com wrote: Hi Santosh, On 9/14/2011 7:22 PM, Shilimkar, Santosh wrote: On Wednesday 14 September 2011 10:48 PM, Tony Lindgren wrote: * Santoshsantosh.shilim...@ti.com [110914 09:40]: On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote: * Santoshsantosh.shilim...@ti.com [110914 09:16]: Thanks for the clarification. It seems to me the spec is most likely wrong as we've had the GIC working for over two years now without doing anything with the wakeup gen registers :) It's working because CPU clockdomain are never put under HW supervised mode and they are kept in force wakeup. Clock-domain never idles on mainline code. PM series will put the clock-domains under HW supervison as needed to achieve any low power states and then all sorts of corner cases will come out. But again the wakeup gen triggers only do something when hitting idle. There should be no use for them during runtime, right? You missed my point in the description. Clockdomain inactive doesn't depend on idle or WFI execution. Under HW supervison CPU clock domain can get into inactive when CPU is stalled and waiting for a read response from slow interconnect. I'm a little bit confused by that statement... I'm wondering how the PRCM can gate the CPU/MPU clock and re-enable it if the MPU is gated? What kind of event can wakeup the CPU in case of CPU stalled? The spec seems to indicate that wakeupgen is needed only if CPU are in WFI. It is even written: CPUx will change power state only when StandbyWFI is asserted.. Even a WFE is not supposed to trigger a standby. How can the CPU be inactive at clock domain level without a WFI? I mean only CPU clock domain and not the power domain inactive and local CPU clock can be gated without WFI when clock domain is kept under hardware supervision. But I agree with you that, for the stalled case, wakeupgen can't generate any event and it will LPRM state-machine which take care of un-gating the clock for that local CPU. I have been discussing today morning with design IP team on the restriction in the functional specs and they said they will check and comeback. For now, I would like to go with what specs says. By next merge window, am sure we will be clear inputs from IP team on this and if it happens that the requirement needs to be changed and we need not do mask/unmask in non-low power scenario, we can start looking at other aspects as Tony suggested. 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
Kernel Halt with framebuffer enabled: omap_mbox_get()
Hi, We're doing some development with the TI8168 EVM and have followed the instructions on the TI wiki for enabling the /dev framebuffer. When we do this we end up with a kernel halt during boot (see below for example). Doing some investigation it looks like the for loop in mach-omap2/mailbox.c: omap_mbox_get() might be wrong: for(mbox = *mboxes; mbox; mbox++) It looks like this increments the omap_mbox structure rather than the array? Should the loop actually be something like for(mbox = *mboxes; (mbox != NULL); mbox = *mboxes++) I'm hesitant to query this as it looks like this change has been in the kernel for about a year, so perhaps I'm missing something? Stuart Kernel Halt IR RC5 (streamzap) protocol handler initialized IR LIRC bridge handler initialized Linux video capture interface: v2.00 OMAP Watchdog Timer Rev 0x00: initial timeout 60 sec Unable to handle kernel NULL pointer dereference at virtual address 0002 pgd = c0004000 [0002] *pgd= Internal error: Oops: 5 [#1] last sysfs file: Modules linked in: CPU: 0 Not tainted (2.6.37 #2) PC is at strcmp+0xc/0x3c LR is at omap_mbox_get+0x50/0x1f8 pc : [c0145d70] lr : [c004d704] psr: 8013 sp : c2c25f10 ip : c2c25f20 fp : c2c25f1c r10: r9 : r8 : r7 : c0322314 r6 : c03a7938 r5 : c03ac6c4 r4 : c0385b8c/mbo/ r3 : 0064 r2 : 0076 r1 : c0322314 r0 : 0002 Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 80004019 DAC: 0017 Process swapper (pid: 1, stack limit = 0xc2c242e8) Stack: (0xc2c25f10 to 0xc2c26000) Stack: (0xc2c25f10 to 0xc2c26000) 5f00: c2c25f44 c2c25f20 c004d704 c0145d70 5f20: c021d3cc c0145d70 c03a78dc c03a7810 c03a78d8 c001e1ac c2c25f6c c2c25f48 5f40: c022133c c004d6c0 c03ac0c0 c2c24000 c03ac0c0 c0056c28 5f60: c2c25f94 c2c25f70 c001e1e8 c0221148 c2c24000 c03ac0c0 c0056c28 5f80: c001e1ac c2c25fdc c2c25f98 c002b44c c001e1b8 c2c25fbc 30342980 5fa0: 0036 c2c25fc4 0197 c0391998 c0021e34 c0021e84 c0056c28 5fc0: 0013 c2c25ff4 c2c25fe0 c0008998 c002b324 5fe0: c00088f8 c2c25ff8 c0056c28 c0008904 33c53c6c 33d53cec Backtrace: [c0145d64] (strcmp+0x0/0x3c) from [c004d704] (omap_mbox_get+0x50/0x1f8) [c004d6b4] (omap_mbox_get+0x0/0x1f8) from [c022133c] (notify_shm_drv_setup+0x200/0x28c) r7:c001e1ac r6:c03a78d8 r5:c03a7810 r4:c03a78dc [c022113c] (notify_shm_drv_setup+0x0/0x28c) from [c001e1e8] (notify_init+0x3c/0x2c8) r6:c0056c28 r5:c03ac0c0 r4:c2c24000 [c001e1ac] (notify_init+0x0/0x2c8) from [c002b44c] (do_one_initcall+0x134/0x19c) r8: r7:c001e1ac r6:c0056c28 r5:c03ac0c0 r4:c2c24000 r3: [c002b318] (do_one_initcall+0x0/0x19c) from [c0008998] (kernel_init+0xa0/0x14c) [c00088f8] (kernel_init+0x0/0x14c) from [c0056c28] (do_exit+0x0/0x644) r5:c00088f8 r4: Code: e89da800 e1a0c00d e92dd800 e24cb004 (e4d03001) end Plexus Corp. Registered address: Pinnacle Hill, Kelso, Roxburghshire, TD5 8XX. Registered in Scotland: number SC146948. This email transmission is confidential and intended solely for the person or organisation to whom it is addressed. If you are not the intended recipient, you must not copy, distribute or disseminate the information, or take any action in reliance of it. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Plexus Corp. If you have received this message in error, do not open any attachment but please notify the sender (above) deleting this message from your system. Please rely on your own virus check no responsibility is taken by the sender for any damage rising out of any bug or virus infection. -- To unsubscribe from this list: send the line unsubscribe 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: Kernel Halt with framebuffer enabled: omap_mbox_get()
Hi Stuart,
On Thu, Sep 15, 2011 at 3:22 PM, Stuart Brown stuart.br...@plexus.com wrote:
Doing some investigation it looks like the for loop in mach-omap2/mailbox.c:
omap_mbox_get() might be wrong:
for(mbox = *mboxes; mbox; mbox++)
...
I'm hesitant to query this as it looks like this change has been in the
kernel for about a year, so perhaps I'm missing something?
You're probably missing the following patch from Kevin:
commit c03773206bf2249a890c4d420ed32ef500630095
Author: Kevin Hilman khil...@ti.com
Date: Fri Feb 11 19:56:43 2011 +
OMAP2+: mailbox: fix lookups for multiple mailboxes
The pointer math in omap_mbox_get() is not quite right, and leads to
passing NULL to strcmp() when searching for an mbox that is not first
in the list.
Convert to using array indexing as is done in all the other functions
which walk the mbox list.
Tested on OMAP2420/n810, OMAP3630/zoom3, OMAP4430/Blaze
Signed-off-by: Kevin Hilman khil...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 459b319..49d3208 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -322,15 +322,18 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
struct omap_mbox *omap_mbox_get(const char *name, struct notifier_block *nb)
{
- struct omap_mbox *mbox;
- int ret;
+ struct omap_mbox *_mbox, *mbox = NULL;
+ int i, ret;
if (!mboxes)
return ERR_PTR(-EINVAL);
- for (mbox = *mboxes; mbox; mbox++)
- if (!strcmp(mbox-name, name))
+ for (i = 0; (_mbox = mboxes[i]); i++) {
+ if (!strcmp(_mbox-name, name)) {
+ mbox = _mbox;
break;
+ }
+ }
if (!mbox)
return ERR_PTR(-ENOENT);
--
To unsubscribe from this list: send the line unsubscribe 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 v9] arm: omap: usb: device name change for the clk names of usbhs
From: Keshava Munegowda keshava_mgo...@ti.com
device name usbhs clocks are changed from
usbhs-omap.0 to usbhs_omap; this is because
in the hwmod registration the device name is set
as usbhs_omap; The redudant clock nodes are removed.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c | 26 --
arch/arm/mach-omap2/clock44xx_data.c | 10 +-
drivers/mfd/omap-usb-host.c |2 +-
3 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index ffd55b1..63a822f 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3285,7 +3285,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, cpefuse_fck, cpefuse_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, ts_fck, ts_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbtll_fck, usbtll_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, usbtll_fck, usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_omap, usbtll_fck, usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(omap-mcbsp.1, prcm_fck, core_96m_fck, CK_3XXX),
CLK(omap-mcbsp.5, prcm_fck, core_96m_fck, CK_3XXX),
CLK(NULL, core_96m_fck, core_96m_fck, CK_3XXX),
@@ -3321,7 +3321,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, pka_ick, pka_ick, CK_34XX | CK_36XX),
CLK(NULL, core_l4_ick, core_l4_ick, CK_3XXX),
CLK(NULL, usbtll_ick, usbtll_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, usbtll_ick, usbtll_ick,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_omap, usbtll_ick, usbtll_ick,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(omap_hsmmc.2, ick, mmchs3_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, icr_ick, icr_ick, CK_34XX | CK_36XX),
CLK(omap-aes, ick, aes2_ick, CK_34XX | CK_36XX),
@@ -3367,20 +3367,18 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, cam_ick, cam_ick, CK_34XX | CK_36XX),
CLK(NULL, csi2_96m_fck, csi2_96m_fck, CK_34XX | CK_36XX),
CLK(NULL, usbhost_120m_fck, usbhost_120m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, hs_fck, usbhost_120m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbhost_48m_fck, usbhost_48m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, fs_fck, usbhost_48m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbhost_ick, usbhost_ick, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, usbhost_ick, usbhost_ick, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, utmi_p1_gfclk,dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, utmi_p2_gfclk,dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, xclk60mhsp1_ck, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, xclk60mhsp2_ck, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, usb_host_hs_utmi_p1_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, usb_host_hs_utmi_p2_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, usb_tll_hs_usb_ch0_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, usb_tll_hs_usb_ch1_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, init_60m_fclk,dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usbhost_ick, usbhost_ick, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_omap, utmi_p1_gfclk,dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, utmi_p2_gfclk,dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, xclk60mhsp1_ck, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, xclk60mhsp2_ck, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usb_host_hs_utmi_p1_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usb_host_hs_utmi_p2_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usb_tll_hs_usb_ch0_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usb_tll_hs_usb_ch1_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, init_60m_fclk,dummy_ck,
CK_3XXX),
CLK(NULL, usim_fck, usim_fck, CK_3430ES2PLUS |
CK_36XX),
CLK(NULL, gpt1_fck, gpt1_fck, CK_3XXX),
CLK(NULL, wkup_32k_fck, wkup_32k_fck, CK_3XXX),
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 2af0e3f..088977a 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3281,7 +3281,7 @@ static
[PATCH 2/5 v9] arm: omap: usb: ehci and ohci hwmod structures for omap3
Following 4 hwmod structure are added:
UHH hwmod of usbhs with uhh base address and functional clock,
EHCI hwmod with irq and base address,
OHCI hwmod with irq and base address,
TLL hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 283
1 files changed, 283 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..ca9a1b7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -84,6 +84,10 @@ static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap34xx_usbhs_ohci_hwmod;
+static struct omap_hwmod omap34xx_usbhs_ehci_hwmod;
+static struct omap_hwmod omap34xx_usb_tll_hs_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -3196,6 +3200,278 @@ static struct omap_hwmod omap3xxx_mmc3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__l3_main_2 = {
+ .master = omap34xx_usb_host_hs_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk= core_l3_ick,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_class_sysconfig omap34xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_usb_host_hs_hwmod_class = {
+ .name = usbhs_uhh,
+ .sysc = omap34xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_masters[] = {
+ omap34xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap34xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x48064000,
+ .pa_end = 0x480643ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {}
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_cfg__usb_host_hs = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_usb_host_hs_hwmod,
+ .clk= l4_ick,
+ .addr = omap34xx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f128m_cfg__usb_host_hs = {
+ .clk= usbhost_120m_fck,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f48m_cfg__usb_host_hs = {
+ .clk= usbhost_48m_fck,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_slaves[] = {
+ omap34xx_l4_cfg__usb_host_hs,
+ omap34xx_f128m_cfg__usb_host_hs,
+ omap34xx_f48m_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod = {
+ .name = usbhs_uhh,
+ .class = omap34xx_usb_host_hs_hwmod_class,
+ .main_clk = usbhost_ick,
+ .prcm = {
+ .omap2 = {
+ .module_offs = OMAP3430ES2_USBHOST_MOD,
+ .prcm_reg_id = 1,
+ .module_bit = 0,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = 1,
+ .idlest_stdby_bit = 0,
+ },
+ },
+ .slaves = omap34xx_usb_host_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_slaves),
+ .masters= omap34xx_usb_host_hs_masters,
+ .masters_cnt= ARRAY_SIZE(omap34xx_usb_host_hs_masters),
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
+/* 'usbhs_ohci' class */
+static struct omap_hwmod_ocp_if omap34xx_usbhs_ohci__l3_main_2 = {
+ .master = omap34xx_usbhs_ohci_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk= core_l3_ick,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_class omap34xx_usbhs_ohci_hwmod_class = {
+ .name = usbhs_ohci,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usbhs_ohci_masters[] = {
+ omap34xx_usbhs_ohci__l3_main_2,
[PATCH 0/5 v9] mfd: omap: usb: Runtime PM support for EHCI and OHCI drivers
From: Keshava Munegowda keshava_mgo...@ti.com The Hwmod structures and Runtime PM features are implemented For EHCI and OHCI drivers of OMAP3 and OMAP4. The global suspend/resume of EHCI and OHCI is validated on OMAP3430 sdp board with these patches. these patches are rebased to kevin's pm branch and usbhs latest mainline kernel patches TODO: - Adding pad configurations to Hwmods - Aggressive clock cutting in usb bus suspends - Remote Wakeup implementation using irq-chaining Benoit Cousson (1): arm: omap: usb: ehci and ohci hwmod structures for omap4 Keshava Munegowda (4): arm: omap: usb: ehci and ohci hwmod structures for omap3 arm: omap: usb: register hwmods of usbhs arm: omap: usb: device name change for the clk names of usbhs mfd: omap: usb: Runtime PM support arch/arm/mach-omap2/clock3xxx_data.c | 26 +- arch/arm/mach-omap2/clock44xx_data.c | 10 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 281 +++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 247 ++ arch/arm/mach-omap2/usb-host.c | 114 ++--- arch/arm/plat-omap/include/plat/usb.h |3 - drivers/mfd/omap-usb-host.c| 733 +++- drivers/usb/host/ehci-omap.c | 17 +- drivers/usb/host/ohci-omap3.c | 18 +- 9 files changed, 891 insertions(+), 558 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5 v9] mfd: omap: usb: Runtime PM support
From: Keshava Munegowda keshava_mgo...@ti.com
The usbhs core driver does not enable/disable the interface and
functional clocks; These clocks are handled by hwmod and runtime pm,
hence instead of the clock enable/disable, the runtime pm APIS are
used. however,the port clocks are handled by the usbhs core.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/include/plat/usb.h |3 -
drivers/mfd/omap-usb-host.c | 731 +
drivers/usb/host/ehci-omap.c | 17 +-
drivers/usb/host/ohci-omap3.c | 18 +-
4 files changed, 295 insertions(+), 474 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 17d3c93..2b66dc2 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -100,9 +100,6 @@ extern void usb_musb_init(struct omap_musb_board_data
*board_data);
extern void usbhs_init(const struct usbhs_omap_board_data *pdata);
-extern int omap_usbhs_enable(struct device *dev);
-extern void omap_usbhs_disable(struct device *dev);
-
extern int omap4430_phy_power(struct device *dev, int ID, int on);
extern int omap4430_phy_set_clk(struct device *dev, int on);
extern int omap4430_phy_init(struct device *dev);
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 9c2da29..e6f3b01 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -26,6 +26,7 @@
#include linux/spinlock.h
#include linux/gpio.h
#include plat/usb.h
+#include linux/pm_runtime.h
#define USBHS_DRIVER_NAME usbhs_omap
#define OMAP_EHCI_DEVICE ehci-omap
@@ -146,9 +147,6 @@
struct usbhs_hcd_omap {
- struct clk *usbhost_ick;
- struct clk *usbhost_hs_fck;
- struct clk *usbhost_fs_fck;
struct clk *xclk60mhsp1_ck;
struct clk *xclk60mhsp2_ck;
struct clk *utmi_p1_fck;
@@ -158,8 +156,6 @@ struct usbhs_hcd_omap {
struct clk *usbhost_p2_fck;
struct clk *usbtll_p2_fck;
struct clk *init_60m_fclk;
- struct clk *usbtll_fck;
- struct clk *usbtll_ick;
void __iomem*uhh_base;
void __iomem*tll_base;
@@ -168,7 +164,6 @@ struct usbhs_hcd_omap {
u32 usbhs_rev;
spinlock_t lock;
- int count;
};
/*-*/
@@ -318,269 +313,6 @@ err_end:
return ret;
}
-/**
- * usbhs_omap_probe - initialize TI-based HCDs
- *
- * Allocates basic resources for this USB host controller.
- */
-static int __devinit usbhs_omap_probe(struct platform_device *pdev)
-{
- struct device *dev = pdev-dev;
- struct usbhs_omap_platform_data *pdata = dev-platform_data;
- struct usbhs_hcd_omap *omap;
- struct resource *res;
- int ret = 0;
- int i;
-
- if (!pdata) {
- dev_err(dev, Missing platform data\n);
- ret = -ENOMEM;
- goto end_probe;
- }
-
- omap = kzalloc(sizeof(*omap), GFP_KERNEL);
- if (!omap) {
- dev_err(dev, Memory allocation failed\n);
- ret = -ENOMEM;
- goto end_probe;
- }
-
- spin_lock_init(omap-lock);
-
- for (i = 0; i OMAP3_HS_USB_PORTS; i++)
- omap-platdata.port_mode[i] = pdata-port_mode[i];
-
- omap-platdata.ehci_data = pdata-ehci_data;
- omap-platdata.ohci_data = pdata-ohci_data;
-
- omap-usbhost_ick = clk_get(dev, usbhost_ick);
- if (IS_ERR(omap-usbhost_ick)) {
- ret = PTR_ERR(omap-usbhost_ick);
- dev_err(dev, usbhost_ick failed error:%d\n, ret);
- goto err_end;
- }
-
- omap-usbhost_hs_fck = clk_get(dev, hs_fck);
- if (IS_ERR(omap-usbhost_hs_fck)) {
- ret = PTR_ERR(omap-usbhost_hs_fck);
- dev_err(dev, usbhost_hs_fck failed error:%d\n, ret);
- goto err_usbhost_ick;
- }
-
- omap-usbhost_fs_fck = clk_get(dev, fs_fck);
- if (IS_ERR(omap-usbhost_fs_fck)) {
- ret = PTR_ERR(omap-usbhost_fs_fck);
- dev_err(dev, usbhost_fs_fck failed error:%d\n, ret);
- goto err_usbhost_hs_fck;
- }
-
- omap-usbtll_fck = clk_get(dev, usbtll_fck);
- if (IS_ERR(omap-usbtll_fck)) {
- ret = PTR_ERR(omap-usbtll_fck);
- dev_err(dev, usbtll_fck failed error:%d\n, ret);
- goto
[PATCH 3/5 v9] arm: omap: usb: register hwmods of usbhs
The hwmod structure of uhh, ohci, ehci and tll are
retrieved and registered with omap device
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/usb-host.c | 114 +--
1 files changed, 50 insertions(+), 64 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 89ae298..9c37db9 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -28,51 +28,30 @@
#include mach/hardware.h
#include mach/irqs.h
#include plat/usb.h
+#include plat/omap_device.h
#include mux.h
#ifdef CONFIG_MFD_OMAP_USB_HOST
-#define OMAP_USBHS_DEVICE usbhs-omap
-
-static struct resource usbhs_resources[] = {
- {
- .name = uhh,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = tll,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = ehci,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = ehci-irq,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = ohci,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = ohci-irq,
- .flags = IORESOURCE_IRQ,
- }
-};
-
-static struct platform_device usbhs_device = {
- .name = OMAP_USBHS_DEVICE,
- .id = 0,
- .num_resources = ARRAY_SIZE(usbhs_resources),
- .resource = usbhs_resources,
-};
+#define OMAP_USBHS_DEVICE usbhs_omap
+#defineUSBHS_UHH_HWMODNAME usbhs_uhh
+#defineUSBHS_OHCI_HWMODNAMEusbhs_ohci
+#define USBHS_EHCI_HWMODNAME usbhs_ehci
+#define USBHS_TLL_HWMODNAMEusbhs_tll
static struct usbhs_omap_platform_data usbhs_data;
static struct ehci_hcd_omap_platform_data ehci_data;
static struct ohci_hcd_omap_platform_data ohci_data;
+static struct omap_device_pm_latency omap_uhhtll_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
/* MUX settings for EHCI pins */
/*
* setup_ehci_io_mux - initialize IO pad mux for USBHOST
@@ -508,7 +487,10 @@ static void setup_4430ohci_io_mux(const enum
usbhs_omap_port_mode *port_mode)
void __init usbhs_init(const struct usbhs_omap_board_data *pdata)
{
- int i;
+ struct omap_hwmod *oh[4];
+ struct omap_device *od;
+ int bus_id = -1;
+ int i;
for (i = 0; i OMAP3_HS_USB_PORTS; i++) {
usbhs_data.port_mode[i] = pdata-port_mode[i];
@@ -523,44 +505,48 @@ void __init usbhs_init(const struct usbhs_omap_board_data
*pdata)
usbhs_data.ohci_data = ohci_data;
if (cpu_is_omap34xx()) {
- usbhs_resources[0].start = OMAP34XX_UHH_CONFIG_BASE;
- usbhs_resources[0].end = OMAP34XX_UHH_CONFIG_BASE + SZ_1K - 1;
- usbhs_resources[1].start = OMAP34XX_USBTLL_BASE;
- usbhs_resources[1].end = OMAP34XX_USBTLL_BASE + SZ_4K - 1;
- usbhs_resources[2].start= OMAP34XX_EHCI_BASE;
- usbhs_resources[2].end = OMAP34XX_EHCI_BASE + SZ_1K - 1;
- usbhs_resources[3].start = INT_34XX_EHCI_IRQ;
- usbhs_resources[4].start= OMAP34XX_OHCI_BASE;
- usbhs_resources[4].end = OMAP34XX_OHCI_BASE + SZ_1K - 1;
- usbhs_resources[5].start = INT_34XX_OHCI_IRQ;
setup_ehci_io_mux(pdata-port_mode);
setup_ohci_io_mux(pdata-port_mode);
} else if (cpu_is_omap44xx()) {
- usbhs_resources[0].start = OMAP44XX_UHH_CONFIG_BASE;
- usbhs_resources[0].end = OMAP44XX_UHH_CONFIG_BASE + SZ_1K - 1;
- usbhs_resources[1].start = OMAP44XX_USBTLL_BASE;
- usbhs_resources[1].end = OMAP44XX_USBTLL_BASE + SZ_4K - 1;
- usbhs_resources[2].start = OMAP44XX_HSUSB_EHCI_BASE;
- usbhs_resources[2].end = OMAP44XX_HSUSB_EHCI_BASE + SZ_1K - 1;
- usbhs_resources[3].start = OMAP44XX_IRQ_EHCI;
- usbhs_resources[4].start = OMAP44XX_HSUSB_OHCI_BASE;
- usbhs_resources[4].end = OMAP44XX_HSUSB_OHCI_BASE + SZ_1K - 1;
- usbhs_resources[5].start = OMAP44XX_IRQ_OHCI;
setup_4430ehci_io_mux(pdata-port_mode);
setup_4430ohci_io_mux(pdata-port_mode);
}
- if (platform_device_add_data(usbhs_device,
- usbhs_data, sizeof(usbhs_data)) 0) {
- printk(KERN_ERR USBHS platform_device_add_data failed\n);
- goto init_end;
+ oh[0] = omap_hwmod_lookup(USBHS_UHH_HWMODNAME);
+ if (!oh[0]) {
+ pr_err(Could not look up %s\n, USBHS_UHH_HWMODNAME);
+
[PATCH 1/5 v9] arm: omap: usb: ehci and ohci hwmod structures for omap4
From: Benoit Cousson b-cous...@ti.com
Following 4 hwmod structures are added:
UHH hwmod of usbhs with uhh base address and functional clock,
EHCI hwmod with irq and base address,
OHCI hwmod with irq and base address,
TLL hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 249 +++-
1 files changed, 248 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6201422..f06efa6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -68,6 +68,10 @@ static struct omap_hwmod omap44xx_mmc2_hwmod;
static struct omap_hwmod omap44xx_mpu_hwmod;
static struct omap_hwmod omap44xx_mpu_private_hwmod;
static struct omap_hwmod omap44xx_usb_otg_hs_hwmod;
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap44xx_usbhs_ohci_hwmod;
+static struct omap_hwmod omap44xx_usbhs_ehci_hwmod;
+static struct omap_hwmod omap44xx_usb_tll_hs_hwmod;
/*
* Interconnects omap_hwmod structures
@@ -5336,6 +5340,244 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap44xx_usb_host_hs__l3_main_2 = {
+ .master = omap44xx_usb_host_hs_hwmod,
+ .slave = omap44xx_l3_main_2_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+ MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_usb_host_hs_hwmod_class = {
+ .name = usbhs_uhh,
+ .sysc = omap44xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_masters[] = {
+ omap44xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap44xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x4a064000,
+ .pa_end = 0x4a0647ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {}
+};
+
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_host_hs = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_usb_host_hs_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_slaves[] = {
+ omap44xx_l4_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod = {
+ .name = usbhs_uhh,
+ .class = omap44xx_usb_host_hs_hwmod_class,
+ .clkdm_name = l3_init_clkdm,
+ .main_clk = usb_host_hs_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_L3INIT_USB_HOST_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_L3INIT_USB_HOST_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+ .slaves = omap44xx_usb_host_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_usb_host_hs_slaves),
+ .masters= omap44xx_usb_host_hs_masters,
+ .masters_cnt= ARRAY_SIZE(omap44xx_usb_host_hs_masters),
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/* 'usbhs_ohci' class */
+static struct omap_hwmod_class omap44xx_usbhs_ohci_hwmod_class = {
+ .name = usbhs_ohci,
+};
+
+static struct omap_hwmod_irq_info omap44xx_usbhs_ohci_irqs[] = {
+ { .name = ohci-irq, .irq = 76 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_addr_space omap44xx_usbhs_ohci_addrs[] = {
+ {
+ .name = ohci,
+ .pa_start = 0x4A064800,
+ .pa_end = 0x4A064BFF,
+ .flags = ADDR_MAP_ON_INIT
+ },
+ {}
+};
+
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usbhs_ohci = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_usbhs_ohci_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_usbhs_ohci_addrs,
+ .user = OCP_USER_MPU |
RE: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
From: Shilimkar, Santosh Sent: Thursday, September 15, 2011 7:02 AM You missed my point in the description. Clockdomain inactive doesn't depend on idle or WFI execution. Under HW supervison CPU clock domain can get into inactive when CPU is stalled and waiting for a read response from slow interconnect. My understanding is MPSS global clock domain can not gate unless each cpu is in wfi and other conditions are met. Other conditions are a wugen ack that there are no irqs and ocp-bridge logic giving its ok. What kind of local clock gating is there per cpu or sub-clock domains is not as clear. The mpu's pivot on individual wfi while other blocks in mpuss have other considerations. The spec is very clear about coherent programmation of wugen and gic. Like being discussed. Its examples are about how wugen used I've heard about are around transition in and out of standbys at wfi. Wugen will process all irqs before giving ack to sleep, it also has ability to fail sleep if new irqs come in before final idle. * It may be possible depending on clarifications to handle near wfi, but you might have to do it for -every- cpu's wfi unless you can coordinate who the last one is. Doing it as you go with gic would avoid redoing work over and over at the many wfi calls. This extra work costs in latency and power. Doing housekeeping along with gic seems better from a run time perspective. Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe 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 01/11] OMAP: TWL: Clean up mode and ops mask passed from board files
On Thu, Sep 15, 2011 at 04:51:57PM +0530, Rajendra Nayak wrote: The TWL driver seems to set the default .valid_modes_mask to (REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY) and .valid_ops_mask to (REGULATOR_CHANGE_VOLTAGE | REGULATOR_CHANGE_MODE | REGULATOR_CHANGE_STATUS) for all the registered regulators. There is no need for all the board files to pass this information additionally, when the driver already sets them by default. the driver? This sounds very buggy... -- To unsubscribe from this list: send the line unsubscribe 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 02/11] regulator: Fix error check in set_consumer_device_supply
On Thu, Sep 15, 2011 at 04:51:58PM +0530, Rajendra Nayak wrote: The parameters to set_consumer_device_supply() can be considered invalid (and hence it could return -EINVAL) if nether consumer_dev nor consumer_dev_name are passed, not when *both* are passed. Signed-off-by: Rajendra Nayak rna...@ti.com No, passing both is a clear bug on the part of the caller - the two ways of specifying the device are not supposed to be used together. -- To unsubscribe from this list: send the line unsubscribe 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: Kernel Halt with framebuffer enabled: omap_mbox_get()
Thanks Ohad,
It looks like this patch is missing from the arago-project linux-omap3 code
base.
We've been using the most recent release - T1816XPSP_04.00.00.12.
What would the procedure be to get this patch applied to the arago-project?
Stuart
-Original Message-
From: Ohad Ben-Cohen [mailto:o...@wizery.com]
Sent: 15 September 2011 14:12
To: Stuart Brown
Cc: linux-omap@vger.kernel.org; Brian Murray
Subject: Re: Kernel Halt with framebuffer enabled: omap_mbox_get()
Hi Stuart,
On Thu, Sep 15, 2011 at 3:22 PM, Stuart Brown stuart.br...@plexus.com wrote:
Doing some investigation it looks like the for loop in mach-omap2/mailbox.c:
omap_mbox_get() might be wrong:
for(mbox = *mboxes; mbox; mbox++)
...
I'm hesitant to query this as it looks like this change has been in the
kernel for about a year, so perhaps I'm missing something?
You're probably missing the following patch from Kevin:
commit c03773206bf2249a890c4d420ed32ef500630095
Author: Kevin Hilman khil...@ti.com
Date: Fri Feb 11 19:56:43 2011 +
OMAP2+: mailbox: fix lookups for multiple mailboxes
The pointer math in omap_mbox_get() is not quite right, and leads to
passing NULL to strcmp() when searching for an mbox that is not first
in the list.
Convert to using array indexing as is done in all the other functions
which walk the mbox list.
Tested on OMAP2420/n810, OMAP3630/zoom3, OMAP4430/Blaze
Signed-off-by: Kevin Hilman khil...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 459b319..49d3208 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -322,15 +322,18 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
struct omap_mbox *omap_mbox_get(const char *name, struct notifier_block *nb)
{
- struct omap_mbox *mbox;
- int ret;
+ struct omap_mbox *_mbox, *mbox = NULL;
+ int i, ret;
if (!mboxes)
return ERR_PTR(-EINVAL);
- for (mbox = *mboxes; mbox; mbox++)
- if (!strcmp(mbox-name, name))
+ for (i = 0; (_mbox = mboxes[i]); i++) {
+ if (!strcmp(_mbox-name, name)) {
+ mbox = _mbox;
break;
+ }
+ }
if (!mbox)
return ERR_PTR(-ENOENT);
Plexus Corp.
Registered address: Pinnacle Hill, Kelso, Roxburghshire, TD5 8XX.
Registered in Scotland: number SC146948.
This email transmission is confidential and intended solely for the person or
organisation to whom it is addressed. If you are not the intended recipient,
you must not copy, distribute or disseminate the information, or take any
action in reliance of it. Any views expressed in this message are those of the
individual sender, except where the sender specifically states them to be the
views of Plexus Corp. If you have received this message in error, do not open
any attachment but please notify the sender (above) deleting this message from
your system. Please rely on your own virus check no responsibility is taken by
the sender for any damage rising out of any bug or virus infection.
--
To unsubscribe from this list: send the line unsubscribe 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 03/11] DT: regulator: Helper routine to extract regulator_init_data
On Thu, Sep 15, 2011 at 04:51:59PM +0530, Rajendra Nayak wrote: .../devicetree/bindings/regulator/regulator.txt| 37 + drivers/of/Kconfig |6 ++ drivers/of/Makefile|1 + drivers/of/of_regulator.c | 85 include/linux/of_regulator.h | 23 + Don't go hiding the bindings for things away from the code they're binding. Bindings for the regualtor API are a regulator API thing and should be part of the regulator API code. +Required properties: +- compatible: Must be regulator; Is this idiomatic or should we just have a helper that parses a big list of properties from the device node? +- mode-fast: boolean, Can handle fast changes in its load +- mode-normal: boolean, Normal regulator power supply mode +- mode-idle: boolean, Can be more efficient during light loads +- mode-standby: boolean, Can be most efficient during light loads I guess these are actually permissions to set the given modes? The documentation should be clearer. +- apply-uV: apply uV constraint if min == max This seems a bit Linux/runtime policy specific (especially the last bit). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 04/11] omap4: SDP: Pass regulator_init_data from DT
On Thu, Sep 15, 2011 at 04:52:00PM +0530, Rajendra Nayak wrote:
+Required properties:
+- compatible: Must be regulator,ti,twl-reg;
I'd expect listings for the specific chips too.
+ xyz-regulator: regulator@0 {
+ compatible = regulator,ti,twl-reg;
+ ti,reg-id = 37; /* TWL6030_REG_VAUX1_6030 */
These magic numbers are *very* Linux specific, we should have a better
way of specifying regulators - I'd off the top of my head expect that
the compatible property would identify the regulator.
--
To unsubscribe from this list: send the line unsubscribe 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: Kernel Halt with framebuffer enabled: omap_mbox_get()
On Thu, Sep 15, 2011 at 4:40 PM, Stuart Brown stuart.br...@plexus.com wrote: What would the procedure be to get this patch applied to the arago-project? I have a feeling that asking Sanjeev will help ;) -- To unsubscribe from this list: send the line unsubscribe 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 06/11] DT: regulator: Helper routine to extract fixed_voltage_config
On Thu, Sep 15, 2011 at 04:52:02PM +0530, Rajendra Nayak wrote: .../devicetree/bindings/regulator/regulator.txt| 19 drivers/of/of_regulator.c | 31 include/linux/of_regulator.h |7 3 files changed, 57 insertions(+), 0 deletions(-) Again, this should be part of the regulator API code not hidden away where it will only get reviewed by device tree people. Required properties: - compatible: Must be regulator; +or +- compatible: Must be regulator-fixed; /* For Fixed volatge regulator */ This seems at best confusing - the fixed voltage regulator is a particular regulator driver, and the general concept of a fixed voltage regulator is still a subset of regulators. +# For fixed voltage regulators +- supply-name: Name of the regulator supply +- microvolts: Output voltage of regulator +- gpio: gpio to use for enable control +- startup-delay: startup time in microseconds +- enable-high: Polarity of enable GPIO, 1 = Active High, 0 = Active low +- enabled-at-boot: 1 = yes, 0 = no Much of this is specific to the Linux fixed voltage regulator driver rather than a generic regulator with a fixed voltage. -- To unsubscribe from this list: send the line unsubscribe 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 07/11] regulator: Make fixed regulator driver extract data from DT
On Thu, Sep 15, 2011 at 04:52:03PM +0530, Rajendra Nayak wrote: Modify the fixed regulator driver to extract fixed_voltage_config from device tree when passed, instead of getting it through platform_data structures (on non-DT builds) The code you added in the previous patch should be part of this driver. -- To unsubscribe from this list: send the line unsubscribe 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 09/11] DT: regulator: Helper to extract regulator node based on supply name
On Thu, Sep 15, 2011 at 04:52:05PM +0530, Rajendra Nayak wrote: regulator = regulator1,regulator2; regulator-names = supply1,supply2; }; This syntax is really painful - we're relying on keeping two arrays in sync which isn't good for legibility or robustness. I'd expect something like having a property with the supply name referencing the regulator node concerned like: dbvdd = regulator1; dcvdd = regulator2; or something. Keeping the two arrays separate doesn't seem great. -- To unsubscribe from this list: send the line unsubscribe 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 10/11] regulator: Implement consumer regulator mapping from device tree
On Thu, Sep 15, 2011 at 04:52:06PM +0530, Rajendra Nayak wrote:
+#ifdef CONFIG_OF
+ struct device_node *node;
+ node = of_get_regulator(dev, id);
+ if (!node)
+ goto out;
+ list_for_each_entry(rdev, regulator_list, list)
+ if (node == rdev-node)
+ goto found;
+#else
list_for_each_entry(map, regulator_map_list, list) {
/* If the mapping has a device set up it must match */
if (map-dev_name
@@ -1178,6 +1189,7 @@ static struct regulator *_regulator_get(struct device
*dev, const char *id,
goto found;
}
}
+#endif
This forces all machines to use device tree when CONFIG_OF is enabled.
I'd expect to see both mechanisms supported simultaneously, for example
by falling back to the current code if the device tree lookup fails.
@@ -1216,6 +1228,15 @@ found:
if (!try_module_get(rdev-owner))
goto out;
+#ifdef CONFIG_OF
+ ret = set_consumer_device_supply(rdev, dev, devname, id);
+ if (ret 0) {
+ dev_err(dev, Failed to set supply %d\n, ret);
+ unset_regulator_supplies(rdev);
+ goto out;
+ }
+#endif
+
This seems wrong, why are we adding things to the regulator_map which is
really only there for lookups when we already did the lookup using the
device tree?
@@ -2619,6 +2640,8 @@ struct regulator_dev *regulator_register(struct
regulator_desc *regulator_desc,
rdev-reg_data = driver_data;
rdev-owner = regulator_desc-owner;
rdev-desc = regulator_desc;
+ if (dev dev-of_node)
+ rdev-node = dev-of_node;
dev is mandatory.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 0/6] usb: musb: charger detection
This provides a series of patches contributed by several people to do correct charger detection and solve issues that came along with the charger detection implementation. USB_EVENT_NONE notification is sent only when a PC cable/CDP cable or a device connected to MUSB is detached. USB_EVENT_VBUS notification is sent only when a PC cable/CDP cable or a device is connected to MUSB. Developed on: git://github.com/torvalds/linux.git commit id: cc39c6a9bbdebfcf1a7dee64d83bf302bc38d941 This patch series is developed and tested on top of Heikki Krogerus patch series (version4) [1] Basic Testing: Tested with gadget zero enabled for charger detection (PC/DCP). Data transfer testing is done on both omap4 and omap3 with ./testusb. Tested for device enumeration when a device is connected to MUSB. [1] http://www.spinics.net/lists/linux-usb/msg51038.html Balaji T K (2): OMAP4: TWL6030: add USB charger detection twl6030: set charger current to be used by battery charging module Kishon Vijay Abraham I (2): usb: musb: omap: Configure OTG_INTERFSEL for proper charger detection usb: musb: omap4430_phy_power to enable/disable clocks and power up/down phy Sergii Postulga (1): OMAP4: PHY internal: Add msleep_interruptible to charger detection function Viswanath Puttagunta (1): MUSB Charger Type Detection: Fix DCP detect during boot. arch/arm/mach-omap2/omap_phy_internal.c | 67 +++ arch/arm/plat-omap/include/plat/usb.h |1 + drivers/usb/musb/omap2430.c | 50 +++ drivers/usb/otg/twl6030-usb.c | 64 +++-- 4 files changed, 159 insertions(+), 23 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
[RFC PATCH 1/6] usb: musb: omap: Configure OTG_INTERFSEL for proper charger detection
Setting OTG_INTERFSEL to UTMI interferes with charger detection resulting
in incorrect detection of charger type. Hence OTG_INTERFSEL is configured to
ULPI initially and changed to UTMI only after receiving USB_EVENT_ID or
USB_EVENT_VBUS notification.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Balaji T K balaj...@ti.com
[sandesh.go...@ti.com: The interface selection has to be done before the PHY
is activated and is not allowed to change when the PHY clock is already
running]
---
drivers/usb/musb/omap2430.c | 50 +++---
1 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index fc9377c..724450b 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -228,6 +228,7 @@ static inline void omap2430_low_level_init(struct musb
*musb)
static int musb_otg_notifications(struct notifier_block *nb,
unsigned long event, void *unused)
{
+ u32 val;
struct musb *musb = container_of(nb, struct musb, nb);
struct device *dev = musb-controller;
struct musb_hdrc_platform_data *pdata = dev-platform_data;
@@ -240,11 +241,32 @@ static int musb_otg_notifications(struct notifier_block
*nb,
if (is_otg_enabled(musb)) {
if (musb-gadget_driver) {
pm_runtime_get_sync(musb-controller);
+
+ val = musb_readl(musb-mregs, OTG_INTERFSEL);
+ if (data-interface_type ==
+ MUSB_INTERFACE_UTMI) {
+ val = ~ULPI_12PIN;
+ val |= UTMI_8BIT;
+ } else {
+ val |= ULPI_12PIN;
+ }
+ musb_writel(musb-mregs, OTG_INTERFSEL, val);
+
usb_phy_init(musb-xceiv);
omap2430_musb_set_vbus(musb, 1);
}
} else {
pm_runtime_get_sync(musb-controller);
+
+ val = musb_readl(musb-mregs, OTG_INTERFSEL);
+ if (data-interface_type == MUSB_INTERFACE_UTMI) {
+ val = ~ULPI_12PIN;
+ val |= UTMI_8BIT;
+ } else {
+ val |= ULPI_12PIN;
+ }
+ musb_writel(musb-mregs, OTG_INTERFSEL, val);
+
usb_phy_init(musb-xceiv);
omap2430_musb_set_vbus(musb, 1);
}
@@ -255,6 +277,16 @@ static int musb_otg_notifications(struct notifier_block
*nb,
if (musb-gadget_driver)
pm_runtime_get_sync(musb-controller);
+
+ val = musb_readl(musb-mregs, OTG_INTERFSEL);
+ if (data-interface_type == MUSB_INTERFACE_UTMI) {
+ val = ~ULPI_12PIN;
+ val |= UTMI_8BIT;
+ } else {
+ val |= ULPI_12PIN;
+ }
+ musb_writel(musb-mregs, OTG_INTERFSEL, val);
+
usb_phy_init(musb-xceiv);
break;
@@ -272,6 +304,11 @@ static int musb_otg_notifications(struct notifier_block
*nb,
otg_set_vbus(musb-xceiv-otg, 0);
}
usb_phy_shutdown(musb-xceiv);
+
+ val = musb_readl(musb-mregs, OTG_INTERFSEL);
+ val |= ULPI_12PIN;
+ musb_writel(musb-mregs, OTG_INTERFSEL, val);
+
break;
default:
dev_dbg(musb-controller, ID float\n);
@@ -304,16 +341,11 @@ static int omap2430_musb_init(struct musb *musb)
goto err1;
}
+ /* Set OTG_INTERFSEL to ULPI for correct charger detection.
+* This should be later set to UTMI.
+*/
l = musb_readl(musb-mregs, OTG_INTERFSEL);
-
- if (data-interface_type == MUSB_INTERFACE_UTMI) {
- /* OMAP4 uses Internal PHY GS70 which uses UTMI interface */
- l = ~ULPI_12PIN; /* Disable ULPI */
- l |= UTMI_8BIT; /* Enable UTMI */
- } else {
- l |= ULPI_12PIN;
- }
-
+ l |= ULPI_12PIN;
musb_writel(musb-mregs, OTG_INTERFSEL, l);
pr_debug(HS USB OTG: revision 0x%x, sysconfig 0x%02x,
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 2/6] usb: musb: omap4430_phy_power to enable/disable clocks and power up/down phy
omap4430_phy_power is modified to be self contained in that it enables clock
and power up the phy in addition to modifying the USBOTGHS_CONTROL register
during power on. Similarly while powering down, it disables clock and
power down the phy.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Partha Basak p-bas...@ti.com
---
arch/arm/mach-omap2/omap_phy_internal.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index 58775e3..a828833 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -110,6 +110,13 @@ int omap4430_phy_set_clk(struct device *dev, int on)
int omap4430_phy_power(struct device *dev, int ID, int on)
{
if (on) {
+ /* enabled the clocks */
+ omap4430_phy_set_clk(dev, 1);
+ /* power on the phy */
+ if (__raw_readl(ctrl_base + CONTROL_DEV_CONF) PHY_PD) {
+ __raw_writel(~PHY_PD, ctrl_base + CONTROL_DEV_CONF);
+ msleep_interruptible(200);
+ }
if (ID)
/* enable VBUS valid, IDDIG groung */
__raw_writel(AVALID | VBUSVALID, ctrl_base +
@@ -125,6 +132,10 @@ int omap4430_phy_power(struct device *dev, int ID, int on)
/* Enable session END and IDIG to high impedance. */
__raw_writel(SESSEND | IDDIG, ctrl_base +
USBOTGHS_CONTROL);
+ /* Power down the phy */
+ __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
+ /* Disable the clocks */
+ omap4430_phy_set_clk(dev, 0);
}
return 0;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 6/6] twl6030: set charger current to be used by battery charging module
From: Balaji T K balaj...@ti.com
Set the current supplied by dedicated charging port to 1800mV(according to
battery charging specification). Also added a callback function for set_power
to dynamically set the current to be supplied based on the state of the system.
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/otg/twl6030-usb.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/otg/twl6030-usb.c b/drivers/usb/otg/twl6030-usb.c
index 6cb28ea..1f22c10 100644
--- a/drivers/usb/otg/twl6030-usb.c
+++ b/drivers/usb/otg/twl6030-usb.c
@@ -102,6 +102,7 @@ struct twl6030_usb {
int irq1;
int irq2;
+ unsigned intusb_cinlimit_mA;
u8 linkstat;
u8 asleep;
u8 prev_vbus;
@@ -305,6 +306,7 @@ static irqreturn_t twl6030_usb_irq(int irq, void *_twl)
regulator_disable(twl-usb3v3);
status = USB_EVENT_CHARGER;
twl-xceiv.last_event = status;
+ twl-usb_cinlimit_mA = 1800;
} else {
regulator_disable(twl-usb3v3);
goto vbus_notify;
@@ -435,6 +437,16 @@ static int twl6030_set_host(struct usb_otg *otg, struct
usb_bus *host)
return 0;
}
+static int twl6030_set_power(struct usb_phy *x, unsigned int mA)
+{
+ struct twl6030_usb *twl = xceiv_to_twl(x);
+
+ twl-usb_cinlimit_mA = mA;
+ atomic_notifier_call_chain(twl-xceiv.notifier, USB_EVENT_ENUMERATED,
+ twl-usb_cinlimit_mA);
+ return 0;
+}
+
static int __devinit twl6030_usb_probe(struct platform_device *pdev)
{
struct twl6030_usb *twl;
@@ -463,6 +475,7 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
twl-xceiv.label= twl6030;
twl-xceiv.otg = otg;
twl-xceiv.init = twl6030_phy_init;
+ twl-xceiv.set_power= twl6030_set_power;
twl-xceiv.shutdown = twl6030_phy_shutdown;
twl-xceiv.set_suspend = twl6030_phy_suspend;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 5/6] OMAP4: PHY internal: Add msleep_interruptible to charger detection function
From: Sergii Postulga x0153...@ti.com
Charger detection is given 500ms to complete until which it loops continuously
taking all the processor time. If we plug USB-micro cable to board during
playing video or audio we have a glitches. This patch frees time for doing
other things during waiting the charger detecting flag.
Signed-off-by: Sergii Postulga x0153...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/omap_phy_internal.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index 55918ea..2334de8 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -135,6 +135,7 @@ int omap4_charger_detect(void)
chargertype = ((usb2phycore 21) 0x7);
if (usb2phycore USB2PHY_CHGDETECTED)
break;
+ msleep_interruptible(10);
} while (!time_after(jiffies, timeout));
switch (chargertype) {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 4/6] MUSB Charger Type Detection: Fix DCP detect during boot.
From: Viswanath Puttagunta vi...@ti.com
The charger detection module is getting
disabled during boot up if a DCP (Dedicated charging port)
is connected before device is powered on (Bit 30 of CONTROL_USB2PHYCORE
is set). This patch enables charger type detection each time the charger type
wants to be detected.
Signed-off-by: Viswanath Puttagunta vi...@ti.com
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/omap_phy_internal.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index e5a6701..55918ea 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -49,6 +49,7 @@
#define CHARGER_TYPE_HOST 0x5
#define CHARGER_TYPE_PC0x6
#define USB2PHY_CHGDETECTEDBIT(13)
+#define USB2PHY_DISCHGDET BIT(30)
static struct clk *phyclk, *clk48m, *clk32k;
static void __iomem *ctrl_base;
@@ -124,6 +125,10 @@ int omap4_charger_detect(void)
omap4430_phy_power(NULL, 0, 1);
+ usb2phycore = omap4_ctrl_pad_readl(CONTROL_USB2PHYCORE);
+ usb2phycore = ~USB2PHY_DISCHGDET;
+ omap4_ctrl_pad_writel(usb2phycore, CONTROL_USB2PHYCORE);
+
timeout = jiffies + msecs_to_jiffies(500);
do {
usb2phycore = omap4_ctrl_pad_readl(CONTROL_USB2PHYCORE);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 3/6] OMAP4: TWL6030: add USB charger detection
From: Balaji T K balaj...@ti.com
Charger detection is done in threaded irq and is performed only when OMAP
acts as B-device. Phy is powered on before charger detection and is powered
down once charger detection is completed. The type of charger is sent through
all the registered notifiers.
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Hema HK hem...@ti.com
Signed-off-by: Partha Basak p-bas...@ti.com
---
arch/arm/mach-omap2/omap_phy_internal.c | 50 ++
arch/arm/plat-omap/include/plat/usb.h |1 +
drivers/usb/otg/twl6030-usb.c | 51 ++
3 files changed, 88 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index a828833..e5a6701 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -27,6 +27,7 @@
#include linux/io.h
#include linux/err.h
#include linux/usb.h
+#include linux/power_supply.h
#include plat/usb.h
#include control.h
@@ -42,6 +43,13 @@
#defineSESSEND BIT(3)
#defineIDDIG BIT(4)
+#define CONTROL_USB2PHYCORE0x620
+#define CHARGER_TYPE_PS2 0x2
+#define CHARGER_TYPE_DEDICATED 0x4
+#define CHARGER_TYPE_HOST 0x5
+#define CHARGER_TYPE_PC0x6
+#define USB2PHY_CHGDETECTEDBIT(13)
+
static struct clk *phyclk, *clk48m, *clk32k;
static void __iomem *ctrl_base;
static int usbotghs_control;
@@ -107,6 +115,48 @@ int omap4430_phy_set_clk(struct device *dev, int on)
return 0;
}
+int omap4_charger_detect(void)
+{
+ unsigned long timeout;
+ int charger = 0;
+ u32 usb2phycore = 0;
+ u32 chargertype = 0;
+
+ omap4430_phy_power(NULL, 0, 1);
+
+ timeout = jiffies + msecs_to_jiffies(500);
+ do {
+ usb2phycore = omap4_ctrl_pad_readl(CONTROL_USB2PHYCORE);
+ chargertype = ((usb2phycore 21) 0x7);
+ if (usb2phycore USB2PHY_CHGDETECTED)
+ break;
+ } while (!time_after(jiffies, timeout));
+
+ switch (chargertype) {
+ case CHARGER_TYPE_DEDICATED:
+ charger = POWER_SUPPLY_TYPE_USB_DCP;
+ pr_info(DCP detected\n);
+ break;
+ case CHARGER_TYPE_HOST:
+ charger = POWER_SUPPLY_TYPE_USB_CDP;
+ pr_info(CDP detected\n);
+ break;
+ case CHARGER_TYPE_PC:
+ charger = POWER_SUPPLY_TYPE_USB;
+ pr_info(PC detected\n);
+ break;
+ case CHARGER_TYPE_PS2:
+ pr_info(PS/2 detected!\n);
+ break;
+ default:
+ pr_err(KERN_ERRUnknown charger detected! %d\n, chargertype);
+ }
+
+ omap4430_phy_power(NULL, 0, 0);
+
+ return charger;
+}
+
int omap4430_phy_power(struct device *dev, int ID, int on)
{
if (on) {
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 17d3c93..582851b 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -107,6 +107,7 @@ extern int omap4430_phy_power(struct device *dev, int ID,
int on);
extern int omap4430_phy_set_clk(struct device *dev, int on);
extern int omap4430_phy_init(struct device *dev);
extern int omap4430_phy_exit(struct device *dev);
+extern int omap4_charger_detect(void);
extern int omap4430_phy_suspend(struct device *dev, int suspend);
#endif
diff --git a/drivers/usb/otg/twl6030-usb.c b/drivers/usb/otg/twl6030-usb.c
index 843c47d..6cb28ea 100644
--- a/drivers/usb/otg/twl6030-usb.c
+++ b/drivers/usb/otg/twl6030-usb.c
@@ -32,6 +32,8 @@
#include linux/notifier.h
#include linux/slab.h
#include linux/delay.h
+#include plat/usb.h
+#include linux/power_supply.h
/* usb register definitions */
#define USB_VENDOR_ID_LSB 0x00
@@ -102,6 +104,7 @@ struct twl6030_usb {
int irq2;
u8 linkstat;
u8 asleep;
+ u8 prev_vbus;
boolirq_enabled;
boolvbus_enable;
unsigned long features;
@@ -273,6 +276,7 @@ static irqreturn_t twl6030_usb_irq(int irq, void *_twl)
{
struct twl6030_usb *twl = _twl;
struct usb_otg *otg = twl-xceiv.otg;
+ unsigned charger_type;
int status;
u8 vbus_state, hw_state;
@@ -280,29 +284,48 @@ static irqreturn_t twl6030_usb_irq(int irq, void *_twl)
vbus_state = twl6030_readb(twl, TWL_MODULE_MAIN_CHARGE,
CONTROLLER_STAT1);
- if (!(hw_state STS_USB_ID)) {
- if (vbus_state VBUS_DET) {
- regulator_enable(twl-usb3v3);
-
Re: [RFC PATCH 11/11] DT: regulator: register regulators as platform devices
On Thu, Sep 15, 2011 at 04:52:07PM +0530, Rajendra Nayak wrote:
of_regulator_register_devices() registers all regulators
as platform devices. Use this to register all twl regulators
from the twl driver probe.
Regulators can be devices of any type, not just platform devices.
drivers/mfd/twl-core.c |3 +++
drivers/of/of_regulator.c| 30 ++
include/linux/of_regulator.h |5 +
Again, in the regulator code not hidden away please.
+/**
+ * of_regulator_register_devices - Register regulator devices to platform bus
+ * @np: Parent device node with regulator child nodes
+ *
+ * Registers all the regulator and regulator-fixed nodes as platform devices
+ *
+ */
+void of_regulator_register_devices(struct device_node *np)
+{
+ struct device_node *child;
+ struct platform_device *dev;
+
+ for_each_child_of_node(np, child) {
+ if (of_device_is_compatible(child, regulator)
+ || of_device_is_compatible(child, regulator-fixed)) {
+ dev = of_device_alloc(child, NULL, NULL);
+ if (!dev)
+ return;
+ dev-dev.bus = platform_bus_type;
+ if (of_device_add(dev) != 0) {
+ platform_device_put(dev);
+ return;
+ }
I'm not entirely sure what this is for? Surely we should be
instantiating the subdevices of the MFD in the same way we always have
done?
+ }
+ }
+ return;
+}
+
diff --git a/include/linux/of_regulator.h b/include/linux/of_regulator.h
index 5fc7329..38cf7e3 100644
--- a/include/linux/of_regulator.h
+++ b/include/linux/of_regulator.h
@@ -15,6 +15,7 @@ extern struct fixed_voltage_config
*of_get_fixed_voltage_config(struct device_node *np);
extern struct device_node *of_get_regulator(struct device *dev,
const char *id);
+extern void of_regulator_register_devices(struct device_node *np);
#else
static inline struct regulator_init_data
*of_get_regulator_init_data(struct device_node *np)
@@ -31,6 +32,10 @@ static inline struct device_node *of_get_regulator(struct
device *dev,
{
return NULL;
}
+static inline void of_regulator_register_devices(struct device_node *np)
+{
+ return NULL;
+}
#endif /* CONFIG_OF_REGULATOR */
#endif /* __LINUX_OF_REG_H */
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus
On Thu, Sep 15, 2011 at 3:12 AM, Rusty Russell ru...@rustcorp.com.au wrote: 7... numbers are cheap :) 7 it is :) Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mfd: remove CONFIG_MFD_SUPPORT
Hi Arnd, On Fri, Sep 02, 2011 at 04:43:36PM +0200, Arnd Bergmann wrote: We currently have two symbols to control compilation the MFD subsystem, MFD_SUPPORT and MFD_CORE. The MFD_SUPPORT is actually not required at all, it only hides the submenu when not set, with the effect that Kconfig warns about missing dependencies when another driver selects an MFD driver while MFD_SUPPORT is disabled. Turning the MFD submenu back from menuconfig into a plain menu simplifies the Kconfig syntax for those kinds of users and avoids the surprise when the menu suddenly appears because another driver was enabled that selects this symbol. So I applied this one, thanks a lot. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: Add PWM1 and PWM2 support to twl6030-pwm
Hi Hemanth,
On Tue, Aug 30, 2011 at 12:27:17PM +0530, Hemanth V wrote:
From: Hemanth V heman...@ti.com
Date: Fri, 26 Aug 2011 10:49:29 +0530
Subject: [PATCH] Add PWM1 and PWM2 support to twl6030-pwm driver
This patch adds support for PWM1/PWM2. TWL6030 PWM driver also
supports Indicator LED PWM. Function pointers are defined for
for init, enable, disable and configuration for both Indicator LED
PWM (led_pwm) and PWM1/PWM2 (std_pwm)
Some comments on this code:
+/* PWMs supported by driver */
+#define PWM_ID_LED 1
+#define PWM_ID_PWM1 2
+#define PWM_ID_PWM2 3
I wish we could use enums here, but that's not what the PWM API is expecting.
+int led_pwm_enable(struct pwm_device *pwm)
All your pwm_ops should be static now.
{
u8 val;
int ret;
@@ -95,9 +140,8 @@ int pwm_enable(struct pwm_device *pwm)
twl_i2c_read_u8(TWL6030_MODULE_ID1, val, LED_PWM_CTRL2);
return 0;
}
-EXPORT_SYMBOL(pwm_enable);
-void pwm_disable(struct pwm_device *pwm)
+void led_pwm_disable(struct pwm_device *pwm)
{
u8 val;
int ret;
@@ -120,37 +164,284 @@ void pwm_disable(struct pwm_device *pwm)
}
return;
}
-EXPORT_SYMBOL(pwm_disable);
-struct pwm_device *pwm_request(int pwm_id, const char *label)
+int led_pwm_init(struct pwm_device *pwm)
{
u8 val;
int ret;
+
+ val = PWM_CTRL2_DIS_PD | PWM_CTRL2_CURR_02 | PWM_CTRL2_SRC_VBUS |
+ PWM_CTRL2_MODE_HW;
+
+ ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, val, LED_PWM_CTRL2);
+
+ return ret;
+}
+
+static struct pwm_ops pwm_led = {
+ .config = led_pwm_config,
+ .enable = led_pwm_enable,
+ .disable = led_pwm_disable,
+ .init = led_pwm_init,
+};
+
+int std_pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
+{
+ int ret = 0, level, pwm_id, reg;
+
+ level = (duty_ns * PWM_CTRL1_MAX) / period_ns;
+ pwm_id = pwm-pwm_id;
+
+ if (pwm_id == PWM_ID_PWM1)
+ reg = LED_PWM1ON;
+ else
+ reg = LED_PWM2ON;
This is not consistent with your:
if (PWM1)
else if (PWM2)
else
error
logic below.
Moreover, I'd rather use switch() here but that's more of a personal taste
than anything else.
+struct pwm_device *pwm_request(int pwm_id, const char *label)
+{
+ int ret, found = 0;
struct pwm_device *pwm;
+ mutex_lock(pwm_lock);
+
+ list_for_each_entry(pwm, pwm_list, node) {
+ if (pwm-pwm_id == pwm_id) {
+ found = 1;
+ break;
+ }
+ }
+
+ if (found) {
+ if (pwm-use_count == 0) {
+ pwm-use_count++;
+ pwm-label = label;
+ } else {
+ pwm = ERR_PTR(-EBUSY);
+ }
I failed to understand the logic here. How can you have found == TRUE, and
use_count being 0 ? Also, don't you want to track the pwm users and disable it
when user_count is reaching 0 ? You're not doing that from pwm_free().
+ goto out;
You're leaving with the pwm_lock locked.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ASoC/MFD: twl4030: Fix dependencies for audio codec
Hi THomas, On Mon, Sep 05, 2011 at 11:26:33AM +0200, Thomas Weber wrote: The codec for Devkit8000 (TWL4030) was not detected except when build with CONFIG_SND_SOC_ALL_CODECS. twl-core.c still uses the CONFIG_TWL4030_CODEC for twl_has_codec(). In commit 57fe7251f5bfc4332f24479376de48a1e8ca6211 the CONFIG_TWL4030_CODEC was renamed into CONFIG_MFD_TWL4030_AUDIO, thatswhy the codec was not detected. This patch renames the CONFIG_ TWL4030_CODEC into CONFIG_MFD_TWL4030_AUDIO in twl-core.c. Signed-off-by: Thomas Weber we...@corscience.de Applied, thanks a lot. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v15 06/12] OMAP: dmtimer: switch-over to platform device driver
* Mohammed, Afzal af...@ti.com [110915 01:13]: Hi Tony, On Thu, Sep 15, 2011 at 11:12:53, DebBarma, Tarun Kanti wrote: On Thu, Sep 15, 2011 at 3:15 AM, Tony Lindgren t...@atomide.com wrote: * Tarun Kanti DebBarma tarun.ka...@ti.com [110908 13:36]: removed from timer code. New set of timers present on OMAP4 are now supported. Also, as we don't need the support for different register offsets for the first two omap4 timers, please rather implement support for the new timers and the timeouts directly in plat-omap/dmtimer.c. That way we can still keep the minimal timer support simple for clocksource and clockevent. Of course this means that we'll be only supporting the first two timers as system timers on omap4, but that's fine. Ok, I can make the change! But, do we have to keep OMAP5 in mind right now where even timers[1,2] require addition of offsets? We need clocksource clockevent to be able to work with timers requiring addition of offsets. Without this AM335X, TI816X and TI814X SoC's will not boot. OK. Then how about let's do the following things: 1. Modify the inline access functions to take the PEND and others if needed registers as a parameter 2. Modify mach-omap2/timer.c to initialize the PEND and others in the SoC specific timer_init function 3. Move all the non-minimal stuff into dmtimer.c as that will eventually be a device driver at some point This way we can still share some of the inline access functions and keep the system timer code minimal. Then the device driver like features will be limited to dmtimer.c as that usage is more complex with than with system timer. 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] mfd: twl6030: Setup irq_wake infrastructure.
Hi Santosh, On Tue, Sep 06, 2011 at 09:29:30PM +0530, Santosh Shilimkar wrote: TWL6030 devices have an interrupt line which is connected to application processor like OMAP. These devices support multiple features such as MMC card detect, USB cable detect, RTC interrupt, etc. that must wake up the application processor. With this change, TWL6030 client drivers can make use of irq_wake() if the wakeup is desirable on it's irq events. Patch applied to my for-next branch, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v15 06/12] OMAP: dmtimer: switch-over to platform device driver
* Tony Lindgren t...@atomide.com [110915 09:24]: * Mohammed, Afzal af...@ti.com [110915 01:13]: We need clocksource clockevent to be able to work with timers requiring addition of offsets. Without this AM335X, TI816X and TI814X SoC's will not boot. OK. Then how about let's do the following things: 1. Modify the inline access functions to take the PEND and others if needed registers as a parameter 2. Modify mach-omap2/timer.c to initialize the PEND and others in the SoC specific timer_init function Also, let's do these changes first then rebase the dmtimer series on those changes as it simplifies the dmtimer series a bit. 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 1/4] AM3517 : support for suspend/resume
Koyamangalath, Abhilash abhilash...@ti.com writes:
hi Kevin
On Tue, Sep 13, 2011 at 11:54 PM, Hilman, Kevin wrote:
Hi Abhilash,
Koyamangalath, Abhilash abhilash...@ti.com writes:
Hi
On Wed, Aug 31, 2011 at 4:28 AM, Hilman, Kevin wrote:
Abhilash K V abhilash...@ti.com writes:
snip
In addition to Russell's comments about using the latest code from
mainline, I have some comments below.
[Abhilash K V] I have reworked the patch against the tip (as suggested by
Russell).
And I've incorporated all of Kevin's comments too.
Great, thanks!
There is one known issue left which needs to be closed before I can
submit v2 of this patch.
With no_console_suspend, suspend to RAM hangs right now on AM3517, after
the message:
Disabling non-boot CPUs ...
There is no error message or dump.
I found that this crash is happening in a call to pr_warning(), from
_omap_device_deactivate().
The same code does not produce this issue on omap34xx due to this snippet
from omap_sram_idle() :
/* PER */
if (per_next_state PWRDM_POWER_ON) {
per_going_off = (per_next_state == PWRDM_POWER_OFF) ? 1 : 0;
omap_uart_prepare_idle(2);
omap_uart_prepare_idle(3);
omap2_gpio_prepare_for_idle(per_going_off);
if (per_next_state == PWRDM_POWER_OFF)
omap3_per_save_context();
}
/* CORE */
if (core_next_state PWRDM_POWER_ON) {
omap_uart_prepare_idle(0);
omap_uart_prepare_idle(1);
if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
omap3_cm_save_context();
}
}
This happens in preparation to the suspend operation (I,e. the WFI).
As seen here, on 34xx the sequence in which the uarts are disabled is 2, 3,
0 and 1.The console-uart, which is uart-1 here (starting from uart-0) is
disabled last.
For AM3517 EVM, the console-uart is uart-2 and this ought to be
disabled at the last to prevent this crash from occurring.
There are several other OMAP3 platforms (n900, Beagle, etc.) where the
UART console is also UART2, so console ordering is not the problem.
[Abhilash K V] OK. Yet changing the order so that uart-2 is disabled
at the last seems to rid me of the crash on AM35x. I understand that
holding the console_sem before suspend (your fix below) is the way to
go, but I'm just curious over what's happening here.
You're unlucky. :)
Each time an omap_device is disabled, we print a message if it's a new
worst case value.
What's happening to you is that one of the UARTs disabled after the
console is getting a new worst case value. Because of the missing
console locking, it's trying to write to the console, and boom.
Simply put what is the rationale behind choosing this order of
UART-disables ?
The order is not important at all.
Changing the order might fix this problem for your current situation,
but the same problem could pop up elsewhere.
In fact, even if you disable the console UART last, we can still try to
print the new worst case messages after the console is disabled.
That's why the console locking is important.
The fact that that pr_warning is making it to the console suggests that
the console is not locked. In the idle path, we take the console lock
(using console_trylock(), just above the code you showed above.)
But during suspend, there was an assumption (by me[2]) that the console
would always be locked in the suspend path. During no_console_suspend,
it appears that is not the case.
Can you try the patch below[1] to see if that fixes your problem? I
think it should.
[Abhilash K V] Yes it does, thanks.
Great, thanks for testing. I'll add a Tested-by for you, and post it
to the list.
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] mfd: Combine MFD_SUPPORT and MFD_CORE
On Mon, Aug 29, 2011 at 09:41:47PM +0300, Luciano Coelho wrote: --- @@ -417,7 +417,6 @@ config GPIO_TIMBERDALE config GPIO_RDC321X tristate RDC R-321x GPIO support depends on PCI - select MFD_SUPPORT select MFD_CORE select MFD_RDC321X help diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 21574bd..1836cdf 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -2,10 +2,9 @@ # Multifunction miscellaneous devices # -menuconfig MFD_SUPPORT - bool Multifunction device drivers +menuconfig MFD_CORE + tristate Multifunction device drivers depends on HAS_IOMEM - default y Looks like there is a bug here. Kconfig symbols with dependencies (HAS_IOMEM) must not ever be selected by other symbols because Kconfig doesn't implement a way to resolve them. This patch means that every select MFD_CORE just assumes that HAS_IOMEM is also selected. g. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.
Santosh santosh.shilim...@ti.com writes: On Wednesday 14 September 2011 01:57 AM, Tony Lindgren wrote: * Santosh Shilimkarsantosh.shilim...@ti.com [110904 06:22]: On OMAP4 SOC intecronnects has many write buffers in the async bridges and they can be drained only with stongly ordered accesses. This is not correct, strongly ordered access does not guarantee anything here. If it fixes issues, it's because it makes the writes to reach the device faster. Strongly ordered does not affect anything outside ARM, so the bus access won't change. What I said is the aync bridges WB and what is said is correct from MPU accesses point of view. It's not about faster or slower. With device memory the, writes can get stuck into write buffers where as with SO, the write buffers will be bypassed. The behaviours is limited to the MPU side async bridge boundary which is the problem. The statement is not for l3 and l4 interconnect which probably you mean. There is always a hardware signal to communicate CPU at async bridges to ensure that data is not stuck in these bridges before CPU clock/voltage is cut. Unfortunately we have a BUG on OMAP44XX devices and the dual channel makes it even worst since both pipes have the same BUG. So what we are doing is issuing SO write/read accesses on these pipes so that there is nothing stuck there before MPU hits low power states and also avoids any race conditions when both channels are used together by some initiators. The behaviour is validated at RTL level and there is no ambiguity about it. May be you have mistaken the L3 and L4 as the interconnect levels in this case. Sounds to me like the changelog needs to be a bit more verbose. Remember, we're all probably going to forget the gory details of this in a few months and want to be able to go back to the code w/changelog to refresh our memories. 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 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.
On Thu, Sep 15, 2011 at 10:47 PM, Kevin Hilman khil...@ti.com wrote: Santosh santosh.shilim...@ti.com writes: On Wednesday 14 September 2011 01:57 AM, Tony Lindgren wrote: * Santosh Shilimkarsantosh.shilim...@ti.com [110904 06:22]: On OMAP4 SOC intecronnects has many write buffers in the async bridges and they can be drained only with stongly ordered accesses. This is not correct, strongly ordered access does not guarantee anything here. If it fixes issues, it's because it makes the writes to reach the device faster. Strongly ordered does not affect anything outside ARM, so the bus access won't change. What I said is the aync bridges WB and what is said is correct from MPU accesses point of view. It's not about faster or slower. With device memory the, writes can get stuck into write buffers where as with SO, the write buffers will be bypassed. The behaviours is limited to the MPU side async bridge boundary which is the problem. The statement is not for l3 and l4 interconnect which probably you mean. There is always a hardware signal to communicate CPU at async bridges to ensure that data is not stuck in these bridges before CPU clock/voltage is cut. Unfortunately we have a BUG on OMAP44XX devices and the dual channel makes it even worst since both pipes have the same BUG. So what we are doing is issuing SO write/read accesses on these pipes so that there is nothing stuck there before MPU hits low power states and also avoids any race conditions when both channels are used together by some initiators. The behaviour is validated at RTL level and there is no ambiguity about it. May be you have mistaken the L3 and L4 as the interconnect levels in this case. Sounds to me like the changelog needs to be a bit more verbose. Remember, we're all probably going to forget the gory details of this in a few months and want to be able to go back to the code w/changelog to refresh our memories. Change log was accurate but I agree it needs more description to make it clear. I plan to update it. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ti.com addresses randomly unsubscribed from vger.kernel.org lists
Hello, There have been ongoing problems for awhile now where ti.com addresses have been randomly unsubscribed from vger.kernel.org lists (linux-omap, linux-kernel, etc.) Luca and myself have been working with TI IT to figure out this problem, and they claim to have fixed the problem (details on problem below.) Please send me an email if you find yourself suddenly unsubscribed from one of these mailing lists, and also open a ticket with IT. Kevin More details: The problem is that the mailing list admin was receiving bounces from the ti.com mail servers, but the bounces were not descriptive enough to discover which addresses were failing. The result was big hammer approach in that ti.com addresses were unsubscribed until the bounces stopped. After talking with the list admins, this has been going on for years. We were able to get copies of the bounced emails from the kernel.org list admin and share them with IT, and they have found the problem and have claimed to fix it. If you find yourself suddenly unsubscribed again, please open a ticket and also let me know. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: twl6030: Setup irq_wake infrastructure.
On Thu, Sep 15, 2011 at 10:32 PM, Samuel Ortiz sa...@linux.intel.com wrote: Hi Santosh, On Tue, Sep 06, 2011 at 09:29:30PM +0530, Santosh Shilimkar wrote: TWL6030 devices have an interrupt line which is connected to application processor like OMAP. These devices support multiple features such as MMC card detect, USB cable detect, RTC interrupt, etc. that must wake up the application processor. With this change, TWL6030 client drivers can make use of irq_wake() if the wakeup is desirable on it's irq events. Patch applied to my for-next branch, thanks. Thanks Samuel. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.
* Shilimkar, Santosh santosh.shilim...@ti.com [110915 09:51]: On Thu, Sep 15, 2011 at 10:47 PM, Kevin Hilman khil...@ti.com wrote: Santosh santosh.shilim...@ti.com writes: On Wednesday 14 September 2011 01:57 AM, Tony Lindgren wrote: * Santosh Shilimkarsantosh.shilim...@ti.com [110904 06:22]: On OMAP4 SOC intecronnects has many write buffers in the async bridges and they can be drained only with stongly ordered accesses. This is not correct, strongly ordered access does not guarantee anything here. If it fixes issues, it's because it makes the writes to reach the device faster. Strongly ordered does not affect anything outside ARM, so the bus access won't change. What I said is the aync bridges WB and what is said is correct from MPU accesses point of view. It's not about faster or slower. With device memory the, writes can get stuck into write buffers where as with SO, the write buffers will be bypassed. The behaviours is limited to the MPU side async bridge boundary which is the problem. The statement is not for l3 and l4 interconnect which probably you mean. There is always a hardware signal to communicate CPU at async bridges to ensure that data is not stuck in these bridges before CPU clock/voltage is cut. Unfortunately we have a BUG on OMAP44XX devices and the dual channel makes it even worst since both pipes have the same BUG. So what we are doing is issuing SO write/read accesses on these pipes so that there is nothing stuck there before MPU hits low power states and also avoids any race conditions when both channels are used together by some initiators. The behaviour is validated at RTL level and there is no ambiguity about it. May be you have mistaken the L3 and L4 as the interconnect levels in this case. Sounds to me like the changelog needs to be a bit more verbose. Remember, we're all probably going to forget the gory details of this in a few months and want to be able to go back to the code w/changelog to refresh our memories. Change log was accurate but I agree it needs more description to make it clear. I plan to update it. Please also include the errata in the description and set it up with a Kconfig entry with something like ARM_ERRATA_XX or TI_ERRATA_XX. Also it would be best to apply this fix at the end of the PM series so it is easier to verify the bug and potentially remove the hack if a better fix is ever available. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 03/11] DT: regulator: Helper routine to extract regulator_init_data
On 09/15/2011 08:44 AM, Mark Brown wrote: On Thu, Sep 15, 2011 at 04:51:59PM +0530, Rajendra Nayak wrote: .../devicetree/bindings/regulator/regulator.txt| 37 + drivers/of/Kconfig |6 ++ drivers/of/Makefile|1 + drivers/of/of_regulator.c | 85 include/linux/of_regulator.h | 23 + Don't go hiding the bindings for things away from the code they're binding. Bindings for the regualtor API are a regulator API thing and should be part of the regulator API code. Agreed, but FYI not all subsystem maintainers agree. Moving of_i2c.c into i2c was rejected. Rob +Required properties: +- compatible: Must be regulator; Is this idiomatic or should we just have a helper that parses a big list of properties from the device node? +- mode-fast: boolean, Can handle fast changes in its load +- mode-normal: boolean, Normal regulator power supply mode +- mode-idle: boolean, Can be more efficient during light loads +- mode-standby: boolean, Can be most efficient during light loads I guess these are actually permissions to set the given modes? The documentation should be clearer. +- apply-uV: apply uV constraint if min == max This seems a bit Linux/runtime policy specific (especially the last bit). ___ devicetree-discuss mailing list devicetree-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.
On Thu, Sep 15, 2011 at 11:23 PM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [110915 09:51]: On Thu, Sep 15, 2011 at 10:47 PM, Kevin Hilman khil...@ti.com wrote: Santosh santosh.shilim...@ti.com writes: On Wednesday 14 September 2011 01:57 AM, Tony Lindgren wrote: * Santosh Shilimkarsantosh.shilim...@ti.com [110904 06:22]: On OMAP4 SOC intecronnects has many write buffers in the async bridges and they can be drained only with stongly ordered accesses. This is not correct, strongly ordered access does not guarantee anything here. If it fixes issues, it's because it makes the writes to reach the device faster. Strongly ordered does not affect anything outside ARM, so the bus access won't change. What I said is the aync bridges WB and what is said is correct from MPU accesses point of view. It's not about faster or slower. With device memory the, writes can get stuck into write buffers where as with SO, the write buffers will be bypassed. The behaviours is limited to the MPU side async bridge boundary which is the problem. The statement is not for l3 and l4 interconnect which probably you mean. There is always a hardware signal to communicate CPU at async bridges to ensure that data is not stuck in these bridges before CPU clock/voltage is cut. Unfortunately we have a BUG on OMAP44XX devices and the dual channel makes it even worst since both pipes have the same BUG. So what we are doing is issuing SO write/read accesses on these pipes so that there is nothing stuck there before MPU hits low power states and also avoids any race conditions when both channels are used together by some initiators. The behaviour is validated at RTL level and there is no ambiguity about it. May be you have mistaken the L3 and L4 as the interconnect levels in this case. Sounds to me like the changelog needs to be a bit more verbose. Remember, we're all probably going to forget the gory details of this in a few months and want to be able to go back to the code w/changelog to refresh our memories. Change log was accurate but I agree it needs more description to make it clear. I plan to update it. Please also include the errata in the description and set it up with a Kconfig entry with something like ARM_ERRATA_XX or TI_ERRATA_XX. Sure. It's a TI ERRATA. Also it would be best to apply this fix at the end of the PM series so it is easier to verify the bug and potentially remove the hack if a better fix is ever available. As such order doesn't matter much because it can be removed either way even if it is in the beginning of the series with KCONFIG entry. But I can change the order if you prefer that way. 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: [RFC PATCH 03/11] DT: regulator: Helper routine to extract regulator_init_data
On 09/15/2011 06:21 AM, Rajendra Nayak wrote:
The helper routine is meant to be used by regulator drivers
to extract the regulator_init_data structure passed from device tree.
'consumer_supplies' which is part of regulator_init_data is not extracted
as the regulator consumer mappings are passed through DT differently,
implemented in subsequent patches.
Also add documentation for regulator bindings to be used to pass
regulator_init_data struct information from device tree.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
.../devicetree/bindings/regulator/regulator.txt| 37 +
drivers/of/Kconfig |6 ++
drivers/of/Makefile|1 +
drivers/of/of_regulator.c | 85
include/linux/of_regulator.h | 23 +
5 files changed, 152 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt
create mode 100644 drivers/of/of_regulator.c
create mode 100644 include/linux/of_regulator.h
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt
b/Documentation/devicetree/bindings/regulator/regulator.txt
new file mode 100644
index 000..001e5ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -0,0 +1,37 @@
+Voltage/Current Regulators
+
+Required properties:
+- compatible: Must be regulator;
This is way too generic. compatible is not for matching a class of
devices. It is for matching a specific piece of h/w. So I would expect
names like wolfson,wm8350-dcdc.
+
+Optional properties:
+- supply-regulator: Name of the parent regulator
+- min-uV: smallest voltage consumers may set
+- max-uV: largest voltage consumers may set
+- uV-offset: Offset applied to voltages from consumer to compensate for
voltage drops
+- min-uA: smallest current consumers may set
+- max-uA: largest current consumers may set
+- mode-fast: boolean, Can handle fast changes in its load
+- mode-normal: boolean, Normal regulator power supply mode
+- mode-idle: boolean, Can be more efficient during light loads
+- mode-standby: boolean, Can be most efficient during light loads
+- change-voltage: boolean, Output voltage can be changed by software
+- change-current: boolean, Output current can be chnaged by software
+- change-mode: boolean, Operating mode can be changed by software
+- change-status: boolean, Enable/Disable control for regulator exists
+- change-drms: boolean, Dynamic regulator mode switching is enabled
+- input-uV: Input voltage for regulator when supplied by another regulator
+- initial-mode: Mode to set at startup
+- always-on: boolean, regulator should never be disabled
+- boot-on: bootloader/firmware enabled regulator
+- apply-uV: apply uV constraint if min == max
+
+Example:
+
+ xyz-regulator: regulator@0 {
+ compatible = regulator;
+ min-uV = 100;
+ max-uV = 250;
+ mode-fast;
+ change-voltage;
+ always-on;
+ };
You need to show how a node references the regulator.
Rob
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index b3bfea5..296b96d 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -87,4 +87,10 @@ config OF_PCI_IRQ
help
OpenFirmware PCI IRQ routing helpers
+config OF_REGULATOR
+ def_bool y
+ depends on REGULATOR
+ help
+ OpenFirmware regulator framework helpers
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index 74b959c..bea2852 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_OF_SPI)+= of_spi.o
obj-$(CONFIG_OF_MDIO)+= of_mdio.o
obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
+obj-$(CONFIG_OF_REGULATOR) += of_regulator.o
diff --git a/drivers/of/of_regulator.c b/drivers/of/of_regulator.c
new file mode 100644
index 000..f01d275
--- /dev/null
+++ b/drivers/of/of_regulator.c
@@ -0,0 +1,85 @@
+/*
+ * OF helpers for regulator framework
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Rajendra Nayak rna...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/slab.h
+#include linux/of.h
+#include linux/regulator/machine.h
+
+static void of_get_regulation_constraints(struct device_node *np,
+ struct regulator_init_data **init_data)
+{
+ unsigned int valid_modes_mask = 0, valid_ops_mask = 0;
+
+ of_property_read_u32(np, min-uV, (*init_data)-constraints.min_uV);
+ of_property_read_u32(np, max-uV, (*init_data)-constraints.max_uV);
+
[GIT PULL] OMAP voltage layer cleanup for v3.2
Tony, Please pull the OMAP voltage layer cleanup for v3.2. This is a combination of the series A..E that have been posted, with a handful of updates throughout the comments and kerneldoc. It is based on the powerdomain/clockdomain OMAP_CHIP cleanup from Paul (his pwrdm_clkdm_remove_omap_chip_cleanup_3.2 branch.) Thanks, Kevin The following changes since commit 8179488a36985d4929cf89be5d9171145a769511: OMAP: powerdomain: remove omap_chip bitmasks (2011-09-14 17:20:44 -0600) are available in the git repository at: git://gitorious.org/khilman/linux-omap-pm.git for_3.2/voltage-cleanup Benoit Cousson (1): OMAP4: powerdomain data: add voltage domains Kevin Hilman (48): OMAP2+: hwmod: remove unused voltagedomain pointer OMAP2+: voltage: move PRCM mod offets into VC/VP structures OMAP2+: voltage: move prm_irqst_reg from VP into voltage domain OMAP2+: voltage: start towards a new voltagedomain layer OMAP3: voltage: rename mpu voltagedomain to mpu_iva OMAP3: voltagedomain data: add wakeup domain OMAP3+: voltage: add scalable flag to voltagedomain OMAP2+: powerdomain: add voltagedomain to struct powerdomain OMAP2: add voltage domains and connect to powerdomains OMAP3: powerdomain data: add voltage domains OMAP2+: powerdomain: add voltage domain lookup during register OMAP2+: voltage: keep track of powerdomains in each voltagedomain OMAP2+: voltage: split voltage controller (VC) code into dedicated layer OMAP2+: voltage: move VC into struct voltagedomain, misc. renames OMAP2+: voltage: enable VC bypass scale method when VC is initialized OMAP2+: voltage: split out voltage processor (VP) code into new layer OMAP2+: VC: support PMICs with separate voltage and command registers OMAP2+: add PRM VP functions for checking/clearing VP TX done status OMAP3+ VP: replace transaction done check/clear with VP ops OMAP2+: PRM: add register access functions for VC/VP OMAP3+: voltage: convert to PRM register access functions OMAP3+: VC: cleanup i2c slave address configuration OMAP3+: VC: cleanup PMIC register address configuration OMAP3+: VC bypass: use fields from VC struct instead of PMIC info OMAP3+: VC: cleanup voltage setup time configuration OMAP3+: VC: move on/onlp/ret/off command configuration into common init OMAP3+: VC: abstract out channel configuration OMAP3+: voltage domain: move PMIC struct from vdd_info into struct voltagedomain OMAP3+: VC: make I2C config programmable with PMIC-specific settings OMAP3+: PM: VC: handle mutant channel config for OMAP4 MPU channel OMAP3+: VC: use last nominal voltage setting to get current_vsel OMAP3+: VP: cleanup: move VP instance into voltdm, misc. renames OMAP3+: voltage: remove unneeded debugfs interface OMAP3+: VP: struct omap_vp_common: replace shift with __ffs(mask) OMAP3+: VP: move SoC-specific sys clock rate retreival late init OMAP3+: VP: move timing calculation/config into VP init OMAP3+: VP: create VP helper function for updating error gain OMAP3+: VP: remove omap_vp_runtime_data OMAP3+: VP: move voltage scale function pointer into struct voltagedomain OMAP3+: VP: update_errorgain(): return error if VP OMAP3+: VP: remove unused omap_vp_get_curr_volt() OMAP3+: VP: combine setting init voltage into common function OMAP3+: voltage: rename scale and reset functions using voltdm_ prefix OMAP3+: voltage: move/rename curr_volt from vdd_info into struct voltagedomain OMAP3+: voltdm: final removal of omap_vdd_info OMAP3+: voltage: rename omap_voltage_get_nom_volt - voltdm_get_voltage OMAP3+: voltage: update nominal voltage in voltdm_scale() not VC post-scale OMAP2+: VC: more registers are per-channel starting with OMAP5 Nishanth Menon (3): OMAP4: PM: TWL6030: fix uv to voltage for 0x39 OMAP4: PM: TWL6030: address 0V conversions OMAP4: PM: TWL6030: add cmd register Patrick Titiano (2): OMAP4: PM: TWL6030: fix voltage conversion formula OMAP4: PM: TWL6030: fix ON/RET/OFF voltages Tero Kristo (1): omap: voltage: add a stub header file for external/regulator use Todd Poynor (1): OMAP: VP: Explicitly mask VPVOLTAGE field arch/arm/mach-omap2/Makefile |5 +- arch/arm/mach-omap2/io.c |5 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |4 +- arch/arm/mach-omap2/omap_twl.c | 107 ++- arch/arm/mach-omap2/pm.c |6 +- arch/arm/mach-omap2/powerdomain.c| 23 + arch/arm/mach-omap2/powerdomain.h| 10 + arch/arm/mach-omap2/powerdomain2xxx_3xxx.c |2 +- arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c |2 + arch/arm/mach-omap2/powerdomains2xxx_data.c |4 +
Re: [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.
* Shilimkar, Santosh santosh.shilim...@ti.com [110915 10:49]: On Thu, Sep 15, 2011 at 11:23 PM, Tony Lindgren t...@atomide.com wrote: Please also include the errata in the description and set it up with a Kconfig entry with something like ARM_ERRATA_XX or TI_ERRATA_XX. Sure. It's a TI ERRATA. OK Also it would be best to apply this fix at the end of the PM series so it is easier to verify the bug and potentially remove the hack if a better fix is ever available. As such order doesn't matter much because it can be removed either way even if it is in the beginning of the series with KCONFIG entry. But I can change the order if you prefer that way. Well it seems that it's the omap4_finish_suspend in this series that can be used to trigger the bug, although the bug has been around for few years. So then instead of mentioning random hangups you can have a better description with something like Patch xyz added PM idle support for omap4, however bug 123 causes so and so. Fix the issue with blah blah. Also, if you have some easy way to reproduce the bug maybe mention that too? That would make it easy to verify if issue has been fixed. 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: ti.com addresses randomly unsubscribed from vger.kernel.org lists
On Thu, 2011-09-15 at 10:26 -0700, Kevin Hilman wrote: Hello, There have been ongoing problems for awhile now where ti.com addresses have been randomly unsubscribed from vger.kernel.org lists (linux-omap, linux-kernel, etc.) Luca and myself have been working with TI IT to figure out this problem, and they claim to have fixed the problem (details on problem below.) Please send me an email if you find yourself suddenly unsubscribed from one of these mailing lists, and also open a ticket with IT. Kevin More details: The problem is that the mailing list admin was receiving bounces from the ti.com mail servers, but the bounces were not descriptive enough to discover which addresses were failing. The result was big hammer approach in that ti.com addresses were unsubscribed until the bounces stopped. After talking with the list admins, this has been going on for years. We were able to get copies of the bounced emails from the kernel.org list admin and share them with IT, and they have found the problem and have claimed to fix it. If you find yourself suddenly unsubscribed again, please open a ticket and also let me know. Yeah, I've been in contact with Dave and he helped us by sending some bounce emails to be investigated by TI's IT. It seems that they have worked around this problem, by whitelisting vger.kernel.org. According to IT, the problem was the way vger sends emails, by opening a single SMTP connection to send loads of emails at once, instead of opening a separate connection for each recipient. The SPAM filters TI uses consider that kind of behavior as SPAM by default. Hopefully the bounces won't happen anymore with the whitelisting. Dave said he hasn't got any bounces for a while (he used to get 50-60 a day) and that he will inform me in case he sees more bounces from ti.com. I use my gmail account for these subscriptions, and have done it for a few years, after having similar problems with my ex nokia.com email. ;) As Kevin said, if you use ti.com emails and you get mysteriously unsubscribed from some mailing lists, let us know. -- Cheers, Luca. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.
On Fri, Sep 16, 2011 at 1:13 AM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [110915 10:49]: On Thu, Sep 15, 2011 at 11:23 PM, Tony Lindgren t...@atomide.com wrote: Please also include the errata in the description and set it up with a Kconfig entry with something like ARM_ERRATA_XX or TI_ERRATA_XX. Sure. It's a TI ERRATA. OK Also it would be best to apply this fix at the end of the PM series so it is easier to verify the bug and potentially remove the hack if a better fix is ever available. As such order doesn't matter much because it can be removed either way even if it is in the beginning of the series with KCONFIG entry. But I can change the order if you prefer that way. Well it seems that it's the omap4_finish_suspend in this series that can be used to trigger the bug, although the bug has been around for few years. So then instead of mentioning random hangups you can have a better description with something like Patch xyz added PM idle support for omap4, however bug 123 causes so and so. Fix the issue with blah blah. Sounds good . Also, if you have some easy way to reproduce the bug maybe mention that too? That would make it easy to verify if issue has been fixed. There are some multimedia usecases where the bug was discovered but on mainline obviously we don't have that support. I will check with IP folks if any other simple test-case is possible to reproduce the issue and If I find one, will mention that. Thanks for the review. 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] mfd: twl6030: Setup irq_wake infrastructure.
On Tue, Sep 06, 2011 at 09:29:30PM +0530, Santosh Shilimkar wrote:
TWL6030 devices have an interrupt line which is connected to
application processor like OMAP. These devices support multiple features
such as MMC card detect, USB cable detect, RTC interrupt, etc. that must
wake up the application processor.
With this change, TWL6030 client drivers can make use of
irq_wake() if the wakeup is desirable on it's irq events.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
cc: Samuel Ortiz sa...@linux.intel.com
---
drivers/mfd/twl6030-irq.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index eb3b5f8..4477134 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -187,6 +187,13 @@ static inline void activate_irq(int irq)
#endif
}
+int twl6030_irq_set_wake(struct irq_data *d, unsigned int on)
+{
+ int twl_irq = (int)irq_get_chip_data(d-irq);
+
+ return irq_set_irq_wake(twl_irq, on);
Note that when running with this previously, LOCKDEP warnings
were seen. LOCKDEP explicitly sets all irq_desc locks as a single
lock-class, causing possible recursive locking detected when the TWL
RTC (or other) driver calls through enable_irq_wake to
twl6030_irq_set_wake, which recursively calls irq_set_irq_wake.
Although the irq_desc and lock are different, LOCKDEP treats these as
equivalent, presumably due to problems that can be incurred when
locking more than one irq_desc.
Currently we're running with twl6030_irq_set_wake keeping a count of
sub-module wakeirqs, and setting the wakeup status for the twl_irq
enabled or disabled as needed at suspend time. Can send a patch if
wanted.
+}
+
/*--*/
static unsigned twl6030_irq_next;
@@ -318,10 +325,12 @@ int twl6030_init_irq(int irq_num, unsigned irq_base,
unsigned irq_end)
twl6030_irq_chip = dummy_irq_chip;
twl6030_irq_chip.name = twl6030;
twl6030_irq_chip.irq_set_type = NULL;
+ twl6030_irq_chip.irq_set_wake = twl6030_irq_set_wake;
for (i = irq_base; i irq_end; i++) {
irq_set_chip_and_handler(i, twl6030_irq_chip,
handle_simple_irq);
+ irq_set_chip_data(i, (void *)irq_num);
activate_irq(i);
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 03/11] DT: regulator: Helper routine to extract regulator_init_data
On Thu, Sep 15, 2011 at 04:51:59PM +0530, Rajendra Nayak wrote:
The helper routine is meant to be used by regulator drivers
to extract the regulator_init_data structure passed from device tree.
'consumer_supplies' which is part of regulator_init_data is not extracted
as the regulator consumer mappings are passed through DT differently,
implemented in subsequent patches.
Also add documentation for regulator bindings to be used to pass
regulator_init_data struct information from device tree.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
.../devicetree/bindings/regulator/regulator.txt| 37 +
drivers/of/Kconfig |6 ++
drivers/of/Makefile|1 +
drivers/of/of_regulator.c | 85
I originally put the DT stuff under drivers/of for i2c and spi because
there was resistance from driver subsystem maintainers to having code
for something that was powerpc only. Now that it is no longer the
case, I recommend putting this code under drivers/regulator.
include/linux/of_regulator.h | 23 +
5 files changed, 152 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt
create mode 100644 drivers/of/of_regulator.c
create mode 100644 include/linux/of_regulator.h
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt
b/Documentation/devicetree/bindings/regulator/regulator.txt
new file mode 100644
index 000..001e5ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -0,0 +1,37 @@
+Voltage/Current Regulators
+
+Required properties:
+- compatible: Must be regulator;
A regulator compatible doesn't actually help much. Compatible is
for specifying the specific device, not for trying to describe what
kind of device it is. Instead, specific regulator bindings can adopt
extend this binding.
+
+Optional properties:
+- supply-regulator: Name of the parent regulator
If this is a reference to another regulator node then don't use names.
Use phandles instead. In which case it should probably be named
something like regulator-parent (similar to interrupt parent).
However, I can imagine it possible for a regulator to have multiple
parents. It may just be better to go with something like the gpio
scheme of phandle gpio-specifier list of entries. Or maybe just a
list of phandles would be sufficient.
+- min-uV: smallest voltage consumers may set
+- max-uV: largest voltage consumers may set
+- uV-offset: Offset applied to voltages from consumer to compensate for
voltage drops
+- min-uA: smallest current consumers may set
+- max-uA: largest current consumers may set
+- mode-fast: boolean, Can handle fast changes in its load
+- mode-normal: boolean, Normal regulator power supply mode
+- mode-idle: boolean, Can be more efficient during light loads
+- mode-standby: boolean, Can be most efficient during light loads
+- change-voltage: boolean, Output voltage can be changed by software
+- change-current: boolean, Output current can be chnaged by software
+- change-mode: boolean, Operating mode can be changed by software
+- change-status: boolean, Enable/Disable control for regulator exists
+- change-drms: boolean, Dynamic regulator mode switching is enabled
+- input-uV: Input voltage for regulator when supplied by another regulator
+- initial-mode: Mode to set at startup
+- always-on: boolean, regulator should never be disabled
+- boot-on: bootloader/firmware enabled regulator
+- apply-uV: apply uV constraint if min == max
To avoid collisions, I'd prefix all of these with a common prefix.
Something like regulator-*.
These map 1:1 to how Linux currently implements regulators; which
isn't exactly bad, but it means that even if Linux changes, we're
still have to support this binding. Does this represent the best
layout for high level description of regulators?
+
+Example:
+
+ xyz-regulator: regulator@0 {
+ compatible = regulator;
+ min-uV = 100;
+ max-uV = 250;
+ mode-fast;
+ change-voltage;
+ always-on;
+ };
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index b3bfea5..296b96d 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -87,4 +87,10 @@ config OF_PCI_IRQ
help
OpenFirmware PCI IRQ routing helpers
+config OF_REGULATOR
+ def_bool y
+ depends on REGULATOR
+ help
+ OpenFirmware regulator framework helpers
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index 74b959c..bea2852 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_OF_SPI)+= of_spi.o
obj-$(CONFIG_OF_MDIO)+= of_mdio.o
obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
Re: [RFC PATCH 04/11] omap4: SDP: Pass regulator_init_data from DT
On Thu, Sep 15, 2011 at 04:52:00PM +0530, Rajendra Nayak wrote:
Pass regulator_init_data information for omap4sdp from device tree so the
regulator driver can then use the regulator helper
routine to extract and use them during the driver probe().
Add documentation for TWL regulator specific bindings.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
.../bindings/regulator/twl-regulator.txt | 18 ++
arch/arm/boot/dts/omap4-sdp.dts| 16
2 files changed, 34 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/regulator/twl-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/twl-regulator.txt
b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
new file mode 100644
index 000..59df44b
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
@@ -0,0 +1,18 @@
+TWL family of regulators
+
+Required properties:
+- compatible: Must be regulator,ti,twl-reg;
Most specific values always come first. Of course, this point is moot
since regulator shouldn't be used at all.
+
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+- ti,reg-id: Identifier for a TWL regulator, defined in linux/i2c/twl.h file.
This needs more explanation. I don't understand what it means.
+
+Example:
+
+ xyz-regulator: regulator@0 {
+ compatible = regulator,ti,twl-reg;
+ ti,reg-id = 37; /* TWL6030_REG_VAUX1_6030 */
+ min-uV = 100;
+ max-uV = 300;
+ apply-uV;
+ };
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 14faf92..2a613e2 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -52,6 +52,22 @@
interrupts = 11;
reg = 0;
};
+
+ vaux1-regulator: regulator@0 {
+ compatible = regulator,ti,twl-reg;
+ ti,reg-id = 37; /* TWL6030_REG_VAUX1_6030 */
+ min-uV = 100;
+ max-uV = 300;
+ apply-uV;
+ };
+
+ vusim-regulator: regulator@1 {
+ compatible = regulator,ti,twl-reg;
+ ti,reg-id = 42; /* TWL6030_REG_VUSIM */
+ min-uV = 120;
+ max-uV = 290;
+ apply_uV;
+ };
};
};
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 04/11] omap4: SDP: Pass regulator_init_data from DT
On Thu, Sep 15, 2011 at 02:46:18PM +0100, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:52:00PM +0530, Rajendra Nayak wrote:
+Required properties:
+- compatible: Must be regulator,ti,twl-reg;
I'd expect listings for the specific chips too.
+ xyz-regulator: regulator@0 {
+ compatible = regulator,ti,twl-reg;
+ ti,reg-id = 37; /* TWL6030_REG_VAUX1_6030 */
These magic numbers are *very* Linux specific, we should have a better
way of specifying regulators - I'd off the top of my head expect that
the compatible property would identify the regulator.
Yes, that is exactly what it should do.
g.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 05/11] TWL: regulator: Make twl-regulator driver extract data from DT
On Thu, Sep 15, 2011 at 04:52:01PM +0530, Rajendra Nayak wrote:
Modify the twl regulator driver to extract the regulator_init_data from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)
Signed-off-by: Rajendra Nayak rna...@ti.com
---
drivers/regulator/twl-regulator.c | 28 +---
1 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index ee8747f..df1b95a 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -17,6 +17,8 @@
#include linux/regulator/driver.h
#include linux/regulator/machine.h
#include linux/i2c/twl.h
+#include linux/of.h
+#include linux/of_regulator.h
/*
@@ -1011,6 +1013,9 @@ static int __devinit twlreg_probe(struct
platform_device *pdev)
struct regulation_constraints *c;
struct regulator_dev*rdev;
+ if (pdev-dev.of_node)
+ of_property_read_u32(pdev-dev.of_node, ti,reg-id, pdev-id);
+
Don't do this. As much as possible, don't reply on plaform_device-id
when using DT. Plus it is illegal to modify pdev-id after the device
is registered.
for (i = 0, info = NULL; i ARRAY_SIZE(twl_regs); i++) {
if (twl_regs[i].desc.id != pdev-id)
continue;
@@ -1020,7 +1025,11 @@ static int __devinit twlreg_probe(struct
platform_device *pdev)
if (!info)
return -ENODEV;
- initdata = pdev-dev.platform_data;
+ if (pdev-dev.of_node)
+ initdata = of_get_regulator_init_data(pdev-dev.of_node);
+ else
+ initdata = pdev-dev.platform_data;
+
if (!initdata)
return -EINVAL;
@@ -1101,14 +1110,27 @@ static int __devexit twlreg_remove(struct
platform_device *pdev)
MODULE_ALIAS(platform:twl_reg);
+#if defined(CONFIG_OF)
+static const struct of_device_id twl_of_match[] __devinitconst = {
+ { .compatible = ti,twl-reg, },
This looks rather generic. Is this a specific chip? It should be.
g.
+ {},
+};
+MODULE_DEVICE_TABLE(of, twl_of_match);
+#else
+#define twl_of_match NULL
+#endif
+
static struct platform_driver twlreg_driver = {
.probe = twlreg_probe,
.remove = __devexit_p(twlreg_remove),
/* NOTE: short name, to work around driver model truncation of
* twl_regulator.12 (and friends) to twl_regulator.1.
*/
- .driver.name= twl_reg,
- .driver.owner = THIS_MODULE,
+ .driver = {
+ .name = twl_reg,
+ .owner = THIS_MODULE,
+ .of_match_table = twl_of_match,
+ },
};
static int __init twlreg_init(void)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 06/11] DT: regulator: Helper routine to extract fixed_voltage_config
On Thu, Sep 15, 2011 at 04:52:02PM +0530, Rajendra Nayak wrote:
The helper routine defined here (of_get_fixed_voltage_config) can
be used to extract information about fixed regulators (which are not
software controlable) from device tree.
Add documenation about additional bindings for fixed
regulators that can be passed through DT.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
.../devicetree/bindings/regulator/regulator.txt| 19
drivers/of/of_regulator.c | 31
include/linux/of_regulator.h |7
3 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt
b/Documentation/devicetree/bindings/regulator/regulator.txt
index 001e5ce..f8c51d8 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -2,6 +2,8 @@ Voltage/Current Regulators
Required properties:
- compatible: Must be regulator;
+or
+- compatible: Must be regulator-fixed; /* For Fixed volatge regulator */
regulator-fixed should actually just be another driver binding that
uses the regulator binding.
Optional properties:
- supply-regulator: Name of the parent regulator
@@ -24,6 +26,13 @@ Optional properties:
- always-on: boolean, regulator should never be disabled
- boot-on: bootloader/firmware enabled regulator
- apply-uV: apply uV constraint if min == max
+# For fixed voltage regulators
+- supply-name: Name of the regulator supply
+- microvolts: Output voltage of regulator
+- gpio: gpio to use for enable control
+- startup-delay: startup time in microseconds
+- enable-high: Polarity of enable GPIO, 1 = Active High, 0 = Active low
+- enabled-at-boot: 1 = yes, 0 = no
Example:
@@ -35,3 +44,13 @@ Example:
change-voltage;
always-on;
};
+
+ abc-fixedregulator {
+ compatible = regulator-fixed;
+ supply-name = fixed-supply;
+ microvolts = 180;
+ gpio = 43;
+ startup-delay = 7;
+ enable-high;
+ enabled-at-boot;
+ };
diff --git a/drivers/of/of_regulator.c b/drivers/of/of_regulator.c
index f01d275..4d7a49d 100644
--- a/drivers/of/of_regulator.c
+++ b/drivers/of/of_regulator.c
@@ -13,6 +13,7 @@
#include linux/slab.h
#include linux/of.h
#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
static void of_get_regulation_constraints(struct device_node *np,
struct regulator_init_data **init_data)
@@ -83,3 +84,33 @@ struct regulator_init_data
*of_get_regulator_init_data(struct device_node *np)
return init_data;
}
EXPORT_SYMBOL(of_get_regulator_init_data);
+
+/**
+ * of_get_fixed_voltage_config - extract fixed_voltage_config structure info
+ * @np: Pointer to fixed-regulator device tree node
+ *
+ * Populates fixed_voltage_config structure by extracting data from device
+ * tree node, returns a pointer to the populated structure of NULL if memory
+ * alloc fails.
+ */
+struct fixed_voltage_config *of_get_fixed_voltage_config(struct device_node
*np)
+{
+ struct fixed_voltage_config *config;
+
+ config = kzalloc(sizeof(struct fixed_voltage_config), GFP_KERNEL);
+ if (!config)
+ return NULL;
+
+ config-supply_name = (char *)of_get_property(np, supply-name, NULL);
+ of_property_read_u32(np, microvolts, config-microvolts);
+ of_property_read_u32(np, gpio, config-gpio);
+ of_property_read_u32(np, startup-delay, config-startup_delay);
+ if (of_find_property(np, enable-high, NULL))
+ config-enable_high = true;
+ if (of_find_property(np, enabled-at-boot, NULL))
+ config-enabled_at_boot = true;
+ config-init_data = of_get_regulator_init_data(np);
+
+ return config;
+}
+EXPORT_SYMBOL(of_get_fixed_voltage_config);
diff --git a/include/linux/of_regulator.h b/include/linux/of_regulator.h
index 5eb048c..39860c5 100644
--- a/include/linux/of_regulator.h
+++ b/include/linux/of_regulator.h
@@ -11,12 +11,19 @@
#if defined(CONFIG_OF_REGULATOR)
extern struct regulator_init_data
*of_get_regulator_init_data(struct device_node *np);
+extern struct fixed_voltage_config
+ *of_get_fixed_voltage_config(struct device_node *np);
#else
static inline struct regulator_init_data
*of_get_regulator_init_data(struct device_node *np)
{
return NULL;
}
+static inline struct fixed_voltage_config
+ *of_get_fixed_voltage_config(struct device_node *np)
+{
+ return NULL;
+}
#endif /* CONFIG_OF_REGULATOR */
#endif /* __LINUX_OF_REG_H */
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PATCH 1/8] OMAP: convert I2C driver to PM QoS for latency constraints
Hi Jean, Jean Pihet jean.pi...@newoldbits.com writes: Convert the driver from the outdated omap_pm_set_max_mpu_wakeup_lat API to the new PM QoS API. Since the constraint is on the MPU subsystem, use the PM_QOS_CPU_DMA_LATENCY class of PM QoS. The resulting MPU constraints are used by cpuidle to decide the next power state of the MPU subsystem. Currently only OMAP3 is placing constraints on the MPU. Signed-off-by: Jean Pihet j-pi...@ti.com [...] @@ -648,8 +648,16 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num) if (r 0) goto out; - if (dev-set_mpu_wkup_lat != NULL) - dev-set_mpu_wkup_lat(dev-dev, dev-latency); + /* + * When waiting for completion of a i2c transfer, we need to + * set a wake up latency constraint for the MPU. This is to + * ensure quick enough wakeup from idle, when transfer + * completes. + * Used on OMAP3 Only + */ + if (cpu_is_omap34xx()) We don't want any cpu_is_* checking in drivers. If this is only done on certain SoCs, then a flag should be passed from device init code via pdata. That being said, I don't see why this shouldn't be set for all SoCs since it's using the FIFO size to determine the latency. 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: [RFC PATCH 09/11] DT: regulator: Helper to extract regulator node based on supply name
On Thu, Sep 15, 2011 at 02:54:16PM +0100, Mark Brown wrote: On Thu, Sep 15, 2011 at 04:52:05PM +0530, Rajendra Nayak wrote: regulator = regulator1,regulator2; regulator-names = supply1,supply2; }; This syntax is really painful - we're relying on keeping two arrays in sync which isn't good for legibility or robustness. I'd expect something like having a property with the supply name referencing the regulator node concerned like: dbvdd = regulator1; dcvdd = regulator2; or something. Keeping the two arrays separate doesn't seem great. We've got two competing approaches here. For reg and interrupts, the proposal on the table that we talked about at LPC is to do reg-names and interrupts-names so as to preserve the existing semantics of the reg and interrupts properties. For gpios we're using the binding name-gpios for named gpio references. There isn't the same pressure to preserve existing bindings in that case. I'm okay with either approach, providing that -regulator is encoded into the name. g. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 09/11] DT: regulator: Helper to extract regulator node based on supply name
On Thu, Sep 15, 2011 at 04:50:35PM -0600, Grant Likely wrote: We've got two competing approaches here. For reg and interrupts, the proposal on the table that we talked about at LPC is to do reg-names and interrupts-names so as to preserve the existing semantics of the reg and interrupts properties. For gpios we're using the binding name-gpios for named gpio references. There isn't the same pressure to preserve existing bindings in that case. I'm okay with either approach, providing that -regulator is encoded into the name. I think I prefer the latter but I'm probably not too fussed. I'd rather use something like -supply for these just on the basis that you don't always connect things to regulators (for example, speaker supplies are generally attached direct to the battery). -- To unsubscribe from this list: send the line unsubscribe 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: Tasks schedule/migration issue with CPU hotplug?
Hi, Yong
You're right. We figured out something is wrong (is negative) with
vruntime of certain processes.
Below link describes the same issue we observed.
http://lkml.indiana.edu/hypermail/linux/kernel/1101.2/00333.html
And the commite indicated by you is exactly the fix.
Appreciate it!.
On Thu, Sep 8, 2011 at 3:39 PM, Yong Zhang yong.zha...@gmail.com wrote:
On Thu, Sep 08, 2011 at 03:28:01PM +0800, Yong Zhang wrote:
On Thu, Sep 08, 2011 at 02:47:08PM +0800, TAO HU wrote:
Resend with linux-kernel mail list included.
Hmm, could you give a try with commit da7a735e?
Thanks,
Yong
---
commit da7a735e51f9622eb3e1672594d4a41da01d7e4f
Author: Peter Zijlstra a.p.zijls...@chello.nl
Date: Mon Jan 17 17:03:27 2011 +0100
sched: Fix switch_from_fair()
When a task is taken out of the fair class we must ensure the vruntime
is properly normalized because when we put it back in it will assume
to be normalized.
The case that goes wrong is when changing away from the fair class
while sleeping. Sleeping tasks have non-normalized vruntime in order
to make sleeper-fairness work. So treat the switch away from fair as a
wakeup and preserve the relative vruntime.
Also update sysrq-n to call the -switch_{to,from} methods.
Reported-by: Onkalo Samu samu.p.onk...@nokia.com
Signed-off-by: Peter Zijlstra a.p.zijls...@chello.nl
LKML-Reference: new-submission
Signed-off-by: Ingo Molnar mi...@elte.hu
On Wed, Sep 7, 2011 at 10:22 PM, TAO HU tgh...@motorola.com wrote:
4[ 6950.136230] cfs_rq[0]:/
4[ 6950.136230] ? .exec_clock ? ? ? ? ? ? ? ? ? ?: 6520265.283900
4[ 6950.136260] ? .MIN_vruntime ? ? ? ? ? ? ? ? ?: 2223057.428522
4[ 6950.136260] ? .min_vruntime ? ? ? ? ? ? ? ? ?: 2223057.428522
4[ 6950.136291] ? .max_vruntime ? ? ? ? ? ? ? ? ?: 2223114.709956
4[ 6950.136291] ? .spread ? ? ? ? ? ? ? ? ? ? ? ?: 57.281434
4[ 6950.136291] ? .spread0 ? ? ? ? ? ? ? ? ? ? ? : 0.00
4[ 6950.136322] ? .nr_running ? ? ? ? ? ? ? ? ? ?: 212
4[ 6950.136322] ? .load ? ? ? ? ? ? ? ? ? ? ? ? ?: 217650
4[ 6950.136352] ? .nr_spread_over ? ? ? ? ? ? ? ?: 125034
4[ 6950.136352] ? .shares ? ? ? ? ? ? ? ? ? ? ? ?: 0
4[ 6950.136352]
4[ 6950.136566] runnable tasks:
4[ 6950.136566] ? ? ? ? ? ? task ? PID ? ? ? ? tree-key ?switches
prio ? ? exec-runtime ? ? ? ? sum-exec ? ? ? ?sum-sleep
4[ 6950.136596]
--
4[ 6950.136627] ? ? ?omap2_mcspi ? ?21 ? 2223062.886210 ?29451523
The tree-key(2223062.886210) almost equals to cfs_rq.min_vruntime,
so maybe you hit the bug which is cured by the mentioned commit.
Thanks,
Yong
--
Best Regards
Hu Tao
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] OMAP voltage layer cleanup for v3.2
* Kevin Hilman khil...@ti.com [110915 11:59]: Tony, Please pull the OMAP voltage layer cleanup for v3.2. This is a combination of the series A..E that have been posted, with a handful of updates throughout the comments and kerneldoc. It is based on the powerdomain/clockdomain OMAP_CHIP cleanup from Paul (his pwrdm_clkdm_remove_omap_chip_cleanup_3.2 branch.) Thanks, I've pulled Paul's omap_chip_remove_cleanup_3.2 into cleanup branch and your voltage changes into voltage branch and rebuilt linux-omap master branch. Then assuming no issues, I'll ask Arnd to pull these on Friday. 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
[GIT PULL] OMAP: omap_device cleanup for v3.2
Tony, Please pull this omap_device cleanup series for v3.2. This sets the groundwork for Benoit's DT infrastructure work. Kevin The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb: Linux 3.1-rc6 (2011-09-12 14:02:02 -0700) are available in the git repository at: git://gitorious.org/khilman/linux-omap-pm.git for_3.2/omap_device Grazvydas Ignotas (1): OMAP: omap_device: make latency autoadjust messages debug Jarkko Nikula (1): omap: mcbsp: Remove omap device API Kevin Hilman (6): OMAP: omap_device: replace debug/warning/error prints with dev_* macros OMAP: omap_device: remove internal functions from omap_device.h OMAP: omap_device: when building return platform_device instead of omap_device OMAP: omap_device: device register functions now take platform_device pointer OMAP: omap_device: _disable_idle_on_suspend() takes platform_device pointer OMAP: omap_device: decouple platform_device from omap_device arch/arm/mach-omap2/devices.c | 44 +++--- arch/arm/mach-omap2/display.c |6 +- arch/arm/mach-omap2/dma.c | 16 +- arch/arm/mach-omap2/gpio.c| 10 +- arch/arm/mach-omap2/hsmmc.c |8 +- arch/arm/mach-omap2/hwspinlock.c |8 +- arch/arm/mach-omap2/mcbsp.c |8 +- arch/arm/mach-omap2/opp.c |2 +- arch/arm/mach-omap2/pm.c |8 +- arch/arm/mach-omap2/serial.c | 14 +- arch/arm/mach-omap2/sr_device.c |6 +- arch/arm/plat-omap/i2c.c |8 +- arch/arm/plat-omap/include/plat/omap_device.h | 30 ++-- arch/arm/plat-omap/mcbsp.c| 27 arch/arm/plat-omap/omap_device.c | 185 + 15 files changed, 180 insertions(+), 200 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] OMAP: PM CONSTRAINTS: implement the devices wake-up latency constraints
Jean Pihet jean.pi...@newoldbits.com writes:
Implement the devices wake-up latency constraints using the global
device PM QoS notification handler which applies the constraints to the
underlying layer by calling the corresponding function at hwmod level.
Note: the bus throughput function is implemented but currently is
a no-op. A new PM QoS class for the bus throughput needs to be
added.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up
latency constraints on MPU, CORE and PER.
Signed-off-by: Jean Pihet j-pi...@ti.com
This patch does 2 things.
1) removes the MPU lat stuff from the OMAP PM layer (since it's now
available in a generic form
2) implements device wake-up latency constraints
This should be broken up into two parts.
Also, this patch seems to remove a bunch of stuff that was just added in
patch 2/8. Probably best to create the new OMAP PM layer after remving
the unused stuff.
It think the code using the new per-device PM QoS API should also live
outside the OMAP PM layer, since it's not related, and we want to get
rid of the OMAP PM layer eventually.
Speaking of which..., the more I think about it, the more I think we
should take this opportunity to clean and/or remove the OMAP PM layer
completely.
With your work, other than the no-op bus throughput API, it's basically
unused. I think that rather than creating a new OMAP PM layer just to
have a a no-op bus throughput function here, I think it's time
to remove OMAP PM completely. This might also give some incentive
for a PM QoS bus throughput constraint as well.
Of course, Paul can make the final decision there whether to remove it
now, but I think it's time.
Just to prove it's usefulness (or lack thereof), Here's a hack that
combined with your patch 1/8 shows that it is pretty easy to remove.
Kevin
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index a5b7a23..e819d59 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -74,6 +74,13 @@ static const struct omap_dss_hwmod_data
omap4_dss_hwmod_data[] __initdata = {
{ dss_hdmi, omapdss_hdmi, -1 },
};
+static int omap_display_get_context_loss_count(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+
+ return omap_device_get_context_loss_count(pdev);
+}
+
int __init omap_display_init(struct omap_dss_board_info *board_data)
{
int r = 0;
@@ -98,7 +105,7 @@ int __init omap_display_init(struct omap_dss_board_info
*board_data)
pdata.board_data = board_data;
pdata.board_data-get_context_loss_count =
- omap_pm_get_dev_context_loss_count;
+ omap_display_get_context_loss_count;
for (i = 0; i oh_count; i++) {
oh = omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index a9b45c7..fc001f7 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -36,7 +36,9 @@ static u16 control_mmc1;
static int hsmmc_get_context_loss(struct device *dev)
{
- return omap_pm_get_dev_context_loss_count(dev);
+ struct platform_device *pdev = to_platform_device(dev);
+
+ return omap_device_get_context_loss_count(pdev);
}
#else
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 132724c..6e8794a 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -386,7 +386,7 @@ void __init omap2_init_common_infrastructure(void)
_set_hwmod_postsetup_state,
postsetup_state);
- omap_pm_if_early_init();
+ /* omap_pm_if_early_init(); */
if (cpu_is_omap2420())
omap2420_clk_init();
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 4411163..ca978c0 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -243,10 +243,10 @@ static int option_set(void *data, u64 val)
*option = val;
if (option == enable_off_mode) {
- if (val)
- omap_pm_enable_off_mode();
- else
- omap_pm_disable_off_mode();
+ /* if (val) */
+ /* omap_pm_enable_off_mode(); */
+ /* else */
+ /* omap_pm_disable_off_mode(); */
if (cpu_is_omap34xx())
omap3_pm_off_mode_enable(val);
}
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 472bf22..59e7533 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -243,7 +243,7 @@ static void __init omap4_init_voltages(void)
static int __init omap2_common_pm_init(void)
{
omap2_init_processor_devices();
- omap_pm_if_init();
+ /* omap_pm_if_init(); */
return 0;
}
diff --git a/arch/arm/plat-omap/Makefile
Re: [GIT PULL] OMAP: omap_device cleanup for v3.2
Kevin Hilman khil...@ti.com writes: Please pull this omap_device cleanup series for v3.2. This sets the groundwork for Benoit's DT infrastructure work. Turns out this series has a dependency on a patch[1] in Russell's for-next branch. Russell, any chance of picking this patch into your devel-stable so we have a fixed point to merge with? Thanks, Kevin [1] commit 456f69c544d4298e921dc0c606492cdbaa60b34b Author: Kevin Hilman khil...@deeprootsystems.com Date: Tue Sep 6 21:04:10 2011 +0100 ARM: 7082/1: platform_device: pdev_archdata: add omap_device pointer Add omap_device pointer to the ARM-specific arch data in the platform_device. This will be used to attach OMAP-specific device-data to the platform device with device lifetime. Suggested-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Grant Likely grant.lik...@secretlab.ca Signed-off-by: Kevin Hilman khil...@ti.com Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk -- To unsubscribe from this list: send the line unsubscribe 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 v9] mfd: omap: usb: Runtime PM support
On 09/15/11 06:22, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@ti.com The usbhs core driver does not enable/disable the interface and functional clocks; These clocks are handled by hwmod and runtime pm, hence instead of the clock enable/disable, the runtime pm APIS are used. however,the port clocks are handled by the usbhs core. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Kevin Hilman khil...@ti.com --- arch/arm/plat-omap/include/plat/usb.h |3 - drivers/mfd/omap-usb-host.c | 731 + drivers/usb/host/ehci-omap.c | 17 +- drivers/usb/host/ohci-omap3.c | 18 +- 4 files changed, 295 insertions(+), 474 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/usb.h b/arch/arm/plat-omap/include/plat/usb.h index 17d3c93..2b66dc2 100644 Patch 5/5 is white space mangled. The tabs have been changed into spaces. -Frank -- To unsubscribe from this list: send the line unsubscribe 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 v15 06/12] OMAP: dmtimer: switch-over to platform device driver
On Thu, Sep 15, 2011 at 10:35 PM, Tony Lindgren t...@atomide.com wrote: * Tony Lindgren t...@atomide.com [110915 09:24]: * Mohammed, Afzal af...@ti.com [110915 01:13]: We need clocksource clockevent to be able to work with timers requiring addition of offsets. Without this AM335X, TI816X and TI814X SoC's will not boot. OK. Then how about let's do the following things: 1. Modify the inline access functions to take the PEND and others if needed registers as a parameter 2. Modify mach-omap2/timer.c to initialize the PEND and others in the SoC specific timer_init function Also, let's do these changes first then rebase the dmtimer series on those changes as it simplifies the dmtimer series a bit. Alright I will start with this. -- Tarun 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] mfd: twl6030: Setup irq_wake infrastructure.
On Fri, Sep 16, 2011 at 2:07 AM, Todd Poynor toddpoy...@google.com wrote:
On Tue, Sep 06, 2011 at 09:29:30PM +0530, Santosh Shilimkar wrote:
TWL6030 devices have an interrupt line which is connected to
application processor like OMAP. These devices support multiple features
such as MMC card detect, USB cable detect, RTC interrupt, etc. that must
wake up the application processor.
With this change, TWL6030 client drivers can make use of
irq_wake() if the wakeup is desirable on it's irq events.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
cc: Samuel Ortiz sa...@linux.intel.com
---
drivers/mfd/twl6030-irq.c | 9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index eb3b5f8..4477134 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -187,6 +187,13 @@ static inline void activate_irq(int irq)
#endif
}
+int twl6030_irq_set_wake(struct irq_data *d, unsigned int on)
+{
+ int twl_irq = (int)irq_get_chip_data(d-irq);
+
+ return irq_set_irq_wake(twl_irq, on);
Note that when running with this previously, LOCKDEP warnings
were seen. LOCKDEP explicitly sets all irq_desc locks as a single
lock-class, causing possible recursive locking detected when the TWL
RTC (or other) driver calls through enable_irq_wake to
twl6030_irq_set_wake, which recursively calls irq_set_irq_wake.
Although the irq_desc and lock are different, LOCKDEP treats these as
equivalent, presumably due to problems that can be incurred when
locking more than one irq_desc.
Currently we're running with twl6030_irq_set_wake keeping a count of
sub-module wakeirqs, and setting the wakeup status for the twl_irq
enabled or disabled as needed at suspend time. Can send a patch if
wanted.
Please do that.
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 5/5 v9] mfd: omap: usb: Runtime PM support
On Fri, Sep 16, 2011 at 6:10 AM, Frank Rowand frank.row...@am.sony.com wrote: On 09/15/11 06:22, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@ti.com The usbhs core driver does not enable/disable the interface and functional clocks; These clocks are handled by hwmod and runtime pm, hence instead of the clock enable/disable, the runtime pm APIS are used. however,the port clocks are handled by the usbhs core. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Kevin Hilman khil...@ti.com --- arch/arm/plat-omap/include/plat/usb.h | 3 - drivers/mfd/omap-usb-host.c | 731 + drivers/usb/host/ehci-omap.c | 17 +- drivers/usb/host/ohci-omap3.c | 18 +- 4 files changed, 295 insertions(+), 474 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/usb.h b/arch/arm/plat-omap/include/plat/usb.h index 17d3c93..2b66dc2 100644 Patch 5/5 is white space mangled. The tabs have been changed into spaces. -Frank where exactly? I had checked before sending it , but i dint find any? please let me know where exactly. regards keshava -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
