[PATCH V4] OMAP3: PM: Set/clear T2 bit for Smartreflex on TWL
From: Thara Gopinath th...@ti.com
Voltage control on TWL can be done using VMODE/I2C1/I2C_SR.
Since almost all platforms use I2C_SR on omap3, omap3_twl_init by
default expects that OMAP's I2C_SR is plugged in to TWL's I2C
and calls omap3_twl_set_sr_bit. On platforms where I2C_SR is not connected,
the board files are expected to call omap3_twl_set_sr_bit(false) to
ensure that I2C_SR path is not set for voltage control and prevent
the default behavior of omap3_twl_init.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
Cc: linux-arm-ker...@lists.infradead.org
---
This patch is based on LO PM Branch and Smartreflex has been
tested on OMAP3430 SDP, OMAP3630 SDP and boot tested on
OMAP2430 SDP.
arch/arm/mach-omap2/omap_twl.c | 60
arch/arm/mach-omap2/pm.h |1 +
2 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 00e1d2b..b341c36 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -59,8 +59,15 @@
static bool is_offset_valid;
static u8 smps_offset;
+/*
+ * Flag to ensure Smartreflex bit in TWL
+ * being cleared in board file is not overwritten.
+ */
+static bool __initdata twl_sr_enable_autoinit;
+#define TWL4030_DCDC_GLOBAL_CFG0x06
#define REG_SMPS_OFFSET 0xE0
+#define SMARTREFLEX_ENABLE BIT(3)
static unsigned long twl4030_vsel_to_uv(const u8 vsel)
{
@@ -269,6 +276,18 @@ int __init omap3_twl_init(void)
omap3_core_volt_info.vp_vddmax = OMAP3630_VP2_VLIMITTO_VDDMAX;
}
+ /*
+* The smartreflex bit on twl4030 specifies if the setting of voltage
+* is done over the I2C_SR path. Since this setting is independent of
+* the actual usage of smartreflex AVS module, we enable TWL SR bit
+* by default irrespective of whether smartreflex AVS module is enabled
+* on the OMAP side or not. This is because without this bit enabled,
+* the voltage scaling through vp forceupdate/bypass mechanism of
+* voltage scaling will not function on TWL over I2C_SR.
+*/
+ if (!twl_sr_enable_autoinit)
+ omap3_twl_set_sr_bit(true);
+
voltdm = omap_voltage_domain_lookup(mpu);
omap_voltage_register_pmic(voltdm, omap3_mpu_volt_info);
@@ -277,3 +296,44 @@ int __init omap3_twl_init(void)
return 0;
}
+
+/**
+ * omap3_twl_set_sr_bit() - Set/Clear SR bit on TWL
+ * @enable: enable SR mode in twl or not
+ *
+ * If 'enable' is true, enables Smartreflex bit on TWL 4030 to make sure
+ * voltage scaling through OMAP SR works. Else, the smartreflex bit
+ * on twl4030 is cleared as there are platforms which use OMAP3 and T2 but
+ * use Synchronized Scaling Hardware Strategy (ENABLE_VMODE=1) and Direct
+ * Strategy Software Scaling Mode (ENABLE_VMODE=0), for setting the voltages,
+ * in those scenarios this bit is to be cleared (enable = false).
+ *
+ * Returns 0 on sucess, error is returned if I2C read/write fails.
+ */
+int __init omap3_twl_set_sr_bit(bool enable)
+{
+ u8 temp;
+ int ret;
+ if (twl_sr_enable_autoinit)
+ pr_warning(%s: unexpected multiple calls\n, __func__);
+
+ ret = twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, temp,
+ TWL4030_DCDC_GLOBAL_CFG);
+ if (ret)
+ goto err;
+
+ if (enable)
+ temp |= SMARTREFLEX_ENABLE;
+ else
+ temp = ~SMARTREFLEX_ENABLE;
+
+ ret = twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, temp,
+ TWL4030_DCDC_GLOBAL_CFG);
+ if (!ret) {
+ twl_sr_enable_autoinit = true;
+ return 0;
+ }
+err:
+ pr_err(%s: Error access to TWL4030 (%d)\n, __func__, ret);
+ return ret;
+}
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 39580e6..797bfd1 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -127,6 +127,7 @@ static inline void omap_enable_smartreflex_on_init(void) {}
#ifdef CONFIG_TWL4030_CORE
extern int omap3_twl_init(void);
extern int omap4_twl_init(void);
+extern int omap3_twl_set_sr_bit(bool enable);
#else
static inline int omap3_twl_init(void)
{
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP: DSS2: Common IRQ handler for all OMAPs
Hi, On Tuesday 15 February 2011 01:15 PM, Valkeinen, Tomi wrote: snip I'm not familiar with genirq/irq_chip. But yes, as Archit said, we can mask/unmask DSS interrupts. I mean, there's only one interrupt line, but DSS has irqstatus and irqenable registers that can be used. If I understood correctly, irq_chip could be used to manage DSS and DSI interrupts, but I don't know right away what that would mean in practice, and would it make things easier or not. But this could be something that needs more study, as there's a custom isr handling system in DSS, and it would be nice if that could be replaced with genirq. But I guess the main problem still remains with genirqs also: we have one interrupt line on omap3, used by two separate modules. And one irq on omap2, used by one module, and two irqs on omap4, used by two modules. Tomi We actually have 4 interrupt lines on OMAP4, 1 for dispc, 2 for dsi1 and dsi2 and 1 for hdmi. Regards, Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP: DSS2: Common IRQ handler for all OMAPs
Hi,
On Tue, Feb 15, 2011 at 09:58:24AM +0530, archit taneja wrote:
does it make sense to install an irq_chip for that ? I mean, can you
mask/unmask dss and or dsi IRQs ? If you can, then it might make sense
to take a look into GENIRQ and install an irq_chip for that. Then both
dsi and dss would be able to use standard request_irq() API.
We could disable dsi IRQs by masking all the possible interrupt
events in DSI_IRQSTATUS. The same goes for dispc. Is this what you
meant by masking/unmasking irqs?
yes it is. Then it makes sense to have an irq_chip for those two irqs, I
think.
/proc/interrupt will reflect how the hardware works (DSI and DISPC IRQs
being handled by DSS), both dsi and dispc can use normal request_irq()
without setting IRQF_SHARED, etc etc. All you need to do is:
static struct irq_chip dss_irq_chip = {
.name = DSS,
.irq_bus_lock = dss_bus_lock,
.irq_bus_sync_unlock= dss_bus_sync_unlock,
.irq_mask = dss_irq_mask,
.irq_unmask = dss_irq_unmask,
.irq_ack= dss_irq_ack,
};
then, somewhere during probe() you have to:
for (irq = irq_base; irq irq_end; irq++) {
#ifdef CONFIG_ARM
set_irq_flags(irq, IRQF_VALID)
#else
set_irq_noprobe(irq);
#endif
set_irq_data(irq, dss_device_structure_pointer);
set_irq_chip_and_handler(irq, dss_irq_chip,
handle_simple_irq);
}
and on exit() you just need to cleanup:
for (irq = irq_base; irq irq_end; irq++) {
#ifdef CONFIG_ARM
set_irq_flags(irq, 0)
#endif
set_irq_chip_and_handler(irq, NULL, NULL);
set_irq_data(irq, NULL);
}
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] RETU fetch IRQ via struct resource
Hi, On Mon, Feb 14, 2011 at 03:22:42PM -0800, Tony Lindgren wrote: Hmm well maybe send the new ones? Then I can pull assuming you rebase on the cbus branch. That's usable now too and up to v2.6.38-rc4. Will do that later on today. -- balbi -- To unsubscribe from this list: send the line unsubscribe 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] OMAP: Fix Memory Leaks in Smartreflex driver
This Patch frees all the dynamically allocated memory
which couldn't have been released in some error hitting cases.
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm/mach-omap2/smartreflex.c | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index a1f532e..5af8829 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -284,6 +284,7 @@ error:
dev_err(sr_info-pdev-dev, %s: ERROR in registering
interrupt handler. Smartreflex will
not function as desired\n, __func__);
+ kfree(name);
kfree(sr_info);
return ret;
}
@@ -881,7 +882,7 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
ret = sr_late_init(sr_info);
if (ret) {
pr_warning(%s: Error in SR late init\n, __func__);
- return ret;
+ goto err_release_region;
}
}
@@ -892,14 +893,17 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
* not try to create rest of the debugfs entries.
*/
vdd_dbg_dir = omap_voltage_get_dbgdir(sr_info-voltdm);
- if (!vdd_dbg_dir)
- return -EINVAL;
+ if (!vdd_dbg_dir) {
+ ret = -EINVAL;
+ goto err_release_region;
+ }
dbg_dir = debugfs_create_dir(smartreflex, vdd_dbg_dir);
if (IS_ERR(dbg_dir)) {
dev_err(pdev-dev, %s: Unable to create debugfs directory\n,
__func__);
- return PTR_ERR(dbg_dir);
+ ret = PTR_ERR(dbg_dir);
+ goto err_release_region;
}
(void) debugfs_create_file(autocomp, S_IRUGO | S_IWUSR, dbg_dir,
@@ -915,7 +919,8 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
if (IS_ERR(nvalue_dir)) {
dev_err(pdev-dev, %s: Unable to create debugfs directory
for n-values\n, __func__);
- return PTR_ERR(nvalue_dir);
+ ret = PTR_ERR(nvalue_dir);
+ goto err_release_region;
}
omap_voltage_get_volttable(sr_info-voltdm, volt_data);
@@ -924,7 +929,8 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
corresponding vdd vdd_%s. Cannot create debugfs
entries for n-values\n,
__func__, sr_info-voltdm-name);
- return -ENODATA;
+ ret = -ENODATA;
+ goto err_release_region;
}
for (i = 0; i sr_info-nvalue_count; i++) {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/5] omap: select REGULATOR_FIXED_VOLTAGE by default for panda and sdp4430
Power to the wl12xx wlan device is controlled by a fixed regulator. Boards that have the wl12xx should select REGULATOR_FIXED_VOLTAGE. Signed-off-by: Panduranga Mallireddy panduranga_mallire...@ti.com --- arch/arm/mach-omap2/Kconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 1a2cf62..eeaeb3b 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -300,6 +300,7 @@ config MACH_OMAP_4430SDP depends on ARCH_OMAP4 select OMAP_PACKAGE_CBL select OMAP_PACKAGE_CBS + select REGULATOR_FIXED_VOLTAGE config MACH_OMAP4_PANDA bool OMAP4 Panda Board @@ -307,6 +308,7 @@ config MACH_OMAP4_PANDA depends on ARCH_OMAP4 select OMAP_PACKAGE_CBL select OMAP_PACKAGE_CBS + select REGULATOR_FIXED_VOLTAGE config OMAP3_EMU bool OMAP3 debugging peripherals -- 1.5.6.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/5] omap: panda: wlan board muxing
Add board muxing to support the wlan wl1271 chip that is
hardwired to mmc5 (fifth mmc controller) on the PANDA.
Based on the wlan board muxing for zoom3 by Ohad Ben-Cohen
oh...@ti.com
Signed-off-by: Panduranga Mallireddy panduranga_mallire...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 9218862..cc9df6c 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -401,6 +401,19 @@ static int __init omap4_panda_i2c_init(void)
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ /* WLAN IRQ - GPIO 53 */
+ OMAP4_MUX(GPMC_NCS3, OMAP_MUX_MODE3 | OMAP_PIN_INPUT),
+ /* WLAN POWER ENABLE - GPIO 43 */
+ OMAP4_MUX(GPMC_A19, OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT),
+ /* WLAN SDIO: MMC5 CMD */
+ OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC5 CLK */
+ OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC5 DAT[0-3] */
+ OMAP4_MUX(SDMMC5_DAT0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP4_MUX(SDMMC5_DAT1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP4_MUX(SDMMC5_DAT2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP4_MUX(SDMMC5_DAT3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
--
1.5.6.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/5] omap: panda: add fixed regulator device for wlan
Add a fixed regulator vmmc device to enable power control
of the wl1271 wlan device.
Based on the patch for zoom by Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Panduranga Mallireddy panduranga_mallire...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c | 34
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index cc9df6c..cd25255 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -26,6 +26,7 @@
#include linux/usb/otg.h
#include linux/i2c/twl.h
#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
#include mach/hardware.h
#include mach/omap4-common.h
@@ -45,6 +46,7 @@
#define GPIO_HUB_POWER 1
#define GPIO_HUB_NRESET62
+#define GPIO_WIFI_PMENA43
static struct gpio_led gpio_leds[] = {
{
@@ -172,6 +174,37 @@ static struct regulator_consumer_supply
omap4_panda_vmmc_supply[] = {
},
};
+static struct regulator_consumer_supply omap4_panda_vmmc5_supply = {
+ .supply = vmmc,
+ .dev_name = mmci-omap-hs.4,
+};
+
+static struct regulator_init_data panda_vmmc5 = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = omap4_panda_vmmc5_supply,
+};
+
+static struct fixed_voltage_config panda_vwlan = {
+ .supply_name = vwl1271,
+ .microvolts = 180, /* 1.8V */
+ .gpio = GPIO_WIFI_PMENA,
+ .startup_delay = 7, /* 70msec */
+ .enable_high = 1,
+ .enabled_at_boot = 0,
+ .init_data = panda_vmmc5,
+};
+
+static struct platform_device omap_vwlan_device = {
+ .name = reg-fixed-voltage,
+ .id = 1,
+ .dev = {
+ .platform_data = panda_vwlan,
+ },
+};
+
static int omap4_twl6030_hsmmc_late_init(struct device *dev)
{
int ret = 0;
@@ -430,6 +463,7 @@ static void __init omap4_panda_init(void)
omap4_panda_i2c_init();
platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
+ platform_device_register(omap_vwlan_device);
omap_serial_init();
omap4_twl6030_hsmmc_init(mmc);
/* OMAP4 Panda uses internal transceiver so register nop transceiver */
--
1.5.6.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/5] Panda: Support for WLAN on WL127x
Fixes from V1: 1. Removing the pull up of WLAN IRQ line, since it is always held up by wl127x device. Adding support for WLAN on Panda board using wl12xx and mac80211 drivers Patches were tested on Panda board. These patches add software control for emulating card detect events, add board configurations to support the wl127x device. These patches are dependent on the patches that enable clock for WLAN on panda. Please refer the following links for these patches: https://patchwork.kernel.org/patch/546381/ https://patchwork.kernel.org/patch/546401/ [PATCH 5/5] OMAP: hsmmc: Enable MMC4 and MMC5 on OMAP4 platforms is dependent on hwmod adpotation for HSMMC patches series. For original patches of adpotation for HSMMC refer: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg43464.html Patches are based on mainline 2.6.38-rc3 Kishore Kadiyala (1): OMAP: hsmmc: Enable MMC4 and MMC5 on OMAP4 platforms Panduranga Mallireddy (4): omap: panda: wlan board muxing omap: select REGULATOR_FIXED_VOLTAGE by default for panda and sdp4430 omap: panda: add fixed regulator device for wlan omap: panda: add mmc5/wl1271 device support arch/arm/mach-omap2/Kconfig|2 + arch/arm/mach-omap2/board-omap4panda.c | 67 arch/arm/mach-omap2/hsmmc.c|5 ++ drivers/mmc/host/omap_hsmmc.c | 24 +-- 4 files changed, 94 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/5] omap: panda: add mmc5/wl1271 device support
Add MMC5 support on PANDA, which has the wl1271 device hardwired to.
The wl1271 is a 4-wire, 1.8V, embedded SDIO WLAN device with an
external IRQ line, and power-controlled by a GPIO-based fixed regulator.
Based on the patch for mmc3/wl1271 device support for zoom by Ohad
Ben-Cohen o...@wizery.com
Signed-off-by: Panduranga Mallireddy panduranga_mallire...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index cd25255..ef43010 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -27,6 +27,7 @@
#include linux/i2c/twl.h
#include linux/regulator/machine.h
#include linux/regulator/fixed.h
+#include linux/wl12xx.h
#include mach/hardware.h
#include mach/omap4-common.h
@@ -47,6 +48,7 @@
#define GPIO_HUB_POWER 1
#define GPIO_HUB_NRESET62
#define GPIO_WIFI_PMENA43
+#define GPIO_WIFI_IRQ 53
static struct gpio_led gpio_leds[] = {
{
@@ -164,6 +166,15 @@ static struct omap2_hsmmc_info mmc[] = {
.gpio_wp= -EINVAL,
.gpio_cd= -EINVAL,
},
+ {
+ .name = wl1271,
+ .mmc= 5,
+ .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_POWER_OFF_CARD,
+ .gpio_wp= -EINVAL,
+ .gpio_cd= -EINVAL,
+ .ocr_mask = MMC_VDD_165_195,
+ .nonremovable = true,
+ },
{} /* Terminator */
};
@@ -205,6 +216,12 @@ static struct platform_device omap_vwlan_device = {
},
};
+struct wl12xx_platform_data omap_panda_wlan_data __initdata = {
+ .irq = OMAP_GPIO_IRQ(GPIO_WIFI_IRQ),
+ /* PANDA ref clock is 38.4 MHz */
+ .board_ref_clock = 2,
+};
+
static int omap4_twl6030_hsmmc_late_init(struct device *dev)
{
int ret = 0;
@@ -461,6 +478,9 @@ static void __init omap4_panda_init(void)
package = OMAP_PACKAGE_CBL;
omap4_mux_init(board_mux, package);
+ if (wl12xx_set_platform_data(omap_panda_wlan_data))
+ pr_err(error setting wl12xx data\n);
+
omap4_panda_i2c_init();
platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
platform_device_register(omap_vwlan_device);
--
1.5.6.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/5] OMAP: hsmmc: Enable MMC4 and MMC5 on OMAP4 platforms
From: Kishore Kadiyala kishore.kadiy...@ti.com
OMAP4 supports up to 5 MMC controllers, but only 3 of these were
initialized. MMC5 is used by wl12xx chip. So initialize MMC4 and MMC5.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Signed-off-by: Panduranga Mallireddy panduranga_mallire...@ti.com
---
arch/arm/mach-omap2/hsmmc.c |5 +
drivers/mmc/host/omap_hsmmc.c | 24
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 8f1a484..3c0809f 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -348,6 +348,11 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
mmc-slots[0].after_set_reg = NULL;
}
break;
+ case 4:
+ case 5:
+ mmc-slots[0].before_set_reg = NULL;
+ mmc-slots[0].after_set_reg = NULL;
+ break;
default:
pr_err(MMC%d configuration not supported!\n, c-mmc);
kfree(mmc);
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index f59f8da..2525071 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -260,7 +260,7 @@ static int omap_hsmmc_1_set_power(struct device *dev, int
slot, int power_on,
return ret;
}
-static int omap_hsmmc_23_set_power(struct device *dev, int slot, int power_on,
+static int omap_hsmmc_235_set_power(struct device *dev, int slot, int power_on,
int vdd)
{
struct omap_hsmmc_host *host =
@@ -316,6 +316,12 @@ static int omap_hsmmc_23_set_power(struct device *dev, int
slot, int power_on,
return ret;
}
+static int omap_hsmmc_4_set_power(struct device *dev, int slot, int power_on,
+ int vdd)
+{
+ return 0;
+}
+
static int omap_hsmmc_1_set_sleep(struct device *dev, int slot, int sleep,
int vdd, int cardsleep)
{
@@ -326,7 +332,7 @@ static int omap_hsmmc_1_set_sleep(struct device *dev, int
slot, int sleep,
return regulator_set_mode(host-vcc, mode);
}
-static int omap_hsmmc_23_set_sleep(struct device *dev, int slot, int sleep,
+static int omap_hsmmc_235_set_sleep(struct device *dev, int slot, int sleep,
int vdd, int cardsleep)
{
struct omap_hsmmc_host *host =
@@ -365,6 +371,12 @@ static int omap_hsmmc_23_set_sleep(struct device *dev, int
slot, int sleep,
return regulator_enable(host-vcc_aux);
}
+static int omap_hsmmc_4_set_sleep(struct device *dev, int slot, int sleep,
+ int vdd, int cardsleep)
+{
+ return 0;
+}
+
static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
{
struct regulator *reg;
@@ -379,10 +391,14 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
*host)
break;
case OMAP_MMC2_DEVID:
case OMAP_MMC3_DEVID:
+ case OMAP_MMC5_DEVID:
/* Off-chip level shifting, or none */
- mmc_slot(host).set_power = omap_hsmmc_23_set_power;
- mmc_slot(host).set_sleep = omap_hsmmc_23_set_sleep;
+ mmc_slot(host).set_power = omap_hsmmc_235_set_power;
+ mmc_slot(host).set_sleep = omap_hsmmc_235_set_sleep;
break;
+ case OMAP_MMC4_DEVID:
+ mmc_slot(host).set_power = omap_hsmmc_4_set_power;
+ mmc_slot(host).set_sleep = omap_hsmmc_4_set_sleep;
default:
pr_err(MMC%d configuration not supported!\n, host-id);
return -EINVAL;
--
1.5.6.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap: dmtimer: Enable autoidle
-Original Message- From: ext Kevin Hilman [mailto:khil...@ti.com] Sent: 15 February, 2011 01:29 To: Kristo Tero (Nokia-MS/Tampere) Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] omap: dmtimer: Enable autoidle Tero Kristo tero.kri...@nokia.com writes: This will save some power. Signed-off-by: Tero Kristo tero.kri...@nokia.com Please report which platforms this was tested with. Tested only on OMAP3. Should this be changed to apply only on that one? I don't know about OMAP4, but I think this should work on OMAP2 at least based on spec. Also, please Cc linux-arm-kernel. Thanks, Kevin --- arch/arm/plat-omap/dmtimer.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat- omap/dmtimer.c index 1d706cf..949becc 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -341,6 +341,7 @@ static void omap_dm_timer_reset(struct omap_dm_timer *timer) l = omap_dm_timer_read_reg(timer, OMAP_TIMER_OCP_CFG_REG); l |= 0x02 3; /* Set to smart-idle mode */ l |= 0x2 8; /* Set clock activity to perserve f-clock on idle */ +l |= 0x1 0; /* Set autoidle */ /* * Enable wake-up on OMAP2 CPUs. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP: DSS2: Common IRQ handler for all OMAPs
Hi,
On Tuesday 15 February 2011 01:35 PM, Balbi, Felipe wrote:
Hi,
On Tue, Feb 15, 2011 at 09:58:24AM +0530, archit taneja wrote:
does it make sense to install an irq_chip for that ? I mean, can you
mask/unmask dss and or dsi IRQs ? If you can, then it might make sense
to take a look into GENIRQ and install an irq_chip for that. Then both
dsi and dss would be able to use standard request_irq() API.
We could disable dsi IRQs by masking all the possible interrupt
events in DSI_IRQSTATUS. The same goes for dispc. Is this what you
meant by masking/unmasking irqs?
yes it is. Then it makes sense to have an irq_chip for those two irqs, I
think.
/proc/interrupt will reflect how the hardware works (DSI and DISPC IRQs
being handled by DSS), both dsi and dispc can use normal request_irq()
without setting IRQF_SHARED, etc etc. All you need to do is:
static struct irq_chip dss_irq_chip = {
.name = DSS,
.irq_bus_lock = dss_bus_lock,
.irq_bus_sync_unlock= dss_bus_sync_unlock,
.irq_mask = dss_irq_mask,
.irq_unmask = dss_irq_unmask,
.irq_ack= dss_irq_ack,
};
then, somewhere during probe() you have to:
for (irq = irq_base; irq irq_end; irq++) {
#ifdef CONFIG_ARM
set_irq_flags(irq, IRQF_VALID)
#else
set_irq_noprobe(irq);
#endif
set_irq_data(irq, dss_device_structure_pointer);
set_irq_chip_and_handler(irq,dss_irq_chip,
handle_simple_irq);
}
and on exit() you just need to cleanup:
for (irq = irq_base; irq irq_end; irq++) {
#ifdef CONFIG_ARM
set_irq_flags(irq, 0)
#endif
set_irq_chip_and_handler(irq, NULL, NULL);
set_irq_data(irq, NULL);
}
Thanks for the info, but this seems to be suitable for the case
when there are multiple irq events coming from the same interrupt line.
On OMAP4 we have 4 different IRQ lines going to ARM, i.e 4 lines defined
in irqs-44xx.h.
We are looking for a common irq handler located somewhere centrally, and
each module can hook their irq line to this handler.
Does irq_chip do this? what does irq_base and irq_end signify?
Regards,
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 7/7] usb: musb: OMAP4430: Fix usb device detection if connected during boot
-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: Monday, February 14, 2011 3:36 PM
To: Hema HK
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Felipe Balbi
Subject: Re: [PATCH 7/7] usb: musb: OMAP4430: Fix usb device
detection if connected during boot
Hi,
On Thu, Feb 03, 2011 at 03:19:47PM +0530, Hema HK wrote:
+static void omap2430_musb_enable(struct musb *musb)
+{
+u8 devctl;
+unsigned long timeout = jiffies + msecs_to_jiffies(1000);
+struct device *dev = musb-controller;
+struct musb_hdrc_platform_data *pdata = dev-platform_data;
+struct omap_musb_board_data *data = pdata-board_data;
+
+switch (musb-xceiv-last_event) {
+
+case USB_EVENT_ID:
+otg_init(musb-xceiv);
+if (data-interface_type == MUSB_INTERFACE_UTMI) {
+devctl = musb_readb(musb-mregs, MUSB_DEVCTL);
+/* start the session */
+devctl |= MUSB_DEVCTL_SESSION;
+musb_writeb(musb-mregs, MUSB_DEVCTL, devctl);
+while (musb_readb(musb-mregs,
MUSB_DEVCTL) 0x80) {
isn't this BDEVICE bit ? We have a define for that, please use it.
OK.
Regards,
Hema
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP: DSS2: Common IRQ handler for all OMAPs
Hi,
On Tue, Feb 15, 2011 at 01:50:49PM +0530, archit taneja wrote:
yes it is. Then it makes sense to have an irq_chip for those two irqs, I
think.
/proc/interrupt will reflect how the hardware works (DSI and DISPC IRQs
being handled by DSS), both dsi and dispc can use normal request_irq()
without setting IRQF_SHARED, etc etc. All you need to do is:
static struct irq_chip dss_irq_chip = {
.name = DSS,
.irq_bus_lock = dss_bus_lock,
.irq_bus_sync_unlock= dss_bus_sync_unlock,
.irq_mask = dss_irq_mask,
.irq_unmask = dss_irq_unmask,
.irq_ack= dss_irq_ack,
};
then, somewhere during probe() you have to:
for (irq = irq_base; irq irq_end; irq++) {
#ifdef CONFIG_ARM
set_irq_flags(irq, IRQF_VALID)
#else
set_irq_noprobe(irq);
#endif
set_irq_data(irq, dss_device_structure_pointer);
set_irq_chip_and_handler(irq,dss_irq_chip,
handle_simple_irq);
}
and on exit() you just need to cleanup:
for (irq = irq_base; irq irq_end; irq++) {
#ifdef CONFIG_ARM
set_irq_flags(irq, 0)
#endif
set_irq_chip_and_handler(irq, NULL, NULL);
set_irq_data(irq, NULL);
}
Thanks for the info, but this seems to be suitable for the case
when there are multiple irq events coming from the same interrupt
line. On OMAP4 we have 4 different IRQ lines going to ARM, i.e 4
lines defined in irqs-44xx.h.
do you have 4 lines for 4 different modules ? If so, what's the problem
here ? The irq_chip you're using is INTC
We are looking for a common irq handler located somewhere centrally,
and each module can hook their irq line to this handler.
Does irq_chip do this? what does irq_base and irq_end signify?
I guess it can't do that, no. irq_base is the starting number for this
irq_chip's IRQ and irq_end is irq_base + number_of_irqs.
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP: DSS2: Common IRQ handler for all OMAPs
Hi,
On Tuesday 15 February 2011 12:57 PM, Valkeinen, Tomi wrote:
snip
I meant something like this:
dispc.c:
dispc_init()
{
/* did we have a pdev for dispc? if not, this needs to be dss.pdev */
request_irq(platform_get_irq(dispc.pdev, 0), irq_handler, IRQF_SHARED,
dispc irq, foo);
}
irq_handler()
{
if (irq_can_be_shared) {
check if the irq is for us. exit if not;
}
handle;
}
dsi.c:
dsi_init()
{
request_irq(platform_get_irq(dsi.pdev, 0), irq_handler, IRQF_SHARED, dsi
irq, foo);
}
irq_handler()
{
if (irq_can_be_shared) {
check if the irq is for us. exit if not;
}
handle;
}
This approach looks clean, but isn't IRQF_SHARED used the other way
around. One irq line and multiple handlers?
Regards,
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5 v6] OMAP2+: musb: HWMOD adaptation for musb. registration
On Mon, Feb 14, 2011 at 04:15:10PM -0800, Kevin Hilman wrote: Hema HK hem...@ti.com writes: Using omap_device_build API instead of platform_device_register for OMAP2430,OMAP34xx and OMAP4430 musb device registration. The device specific resources defined in centralized database will be used. Except for AM35x. NACK, for same reasons as previous version of this patch. Does it really make sense to hold on omap2plus HWMOD conversion because of AM35x ? I mean, I understand it would be better to get all fixed up, but loose another merge window for that ? Can we get omap2plus in and AM35x on the next merge window ? At least omap2plus would have been converted to hwmod and would be using pm_runtime as we want. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP: DSS2: Common IRQ handler for all OMAPs
On Tue, 2011-02-15 at 02:30 -0600, Taneja, Archit wrote:
Hi,
On Tuesday 15 February 2011 12:57 PM, Valkeinen, Tomi wrote:
snip
I meant something like this:
dispc.c:
dispc_init()
{
/* did we have a pdev for dispc? if not, this needs to be dss.pdev */
request_irq(platform_get_irq(dispc.pdev, 0), irq_handler, IRQF_SHARED,
dispc irq, foo);
}
irq_handler()
{
if (irq_can_be_shared) {
check if the irq is for us. exit if not;
}
handle;
}
dsi.c:
dsi_init()
{
request_irq(platform_get_irq(dsi.pdev, 0), irq_handler, IRQF_SHARED,
dsi irq, foo);
}
irq_handler()
{
if (irq_can_be_shared) {
check if the irq is for us. exit if not;
}
handle;
}
This approach looks clean, but isn't IRQF_SHARED used the other way
around. One irq line and multiple handlers?
That is the case here, isn't it (on omap3)? One interrupt line (the DSS
irq, the same returned both from dsi.pdev and dispc.pdev), and two
handlers, one in dispc and one in dsi? Or what do you mean?
On omap2 there's no dsi code ran, so dispc is the only one requesting
the irq, and thus IRQF_SHARED is extra. In omap4 there are separate irq
lines (dsi.pdev and dispc.pdev return different irqs), and so
IRQF_SHARED is again extra. But I don't see any harm in IRQF_SHARED even
in omap2/4.
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
[PATCH 00/15] More cleanups
We're almost there. retu.c looks very nice now. The bulk effort is now on its children: . retu-headset.c . should use jack framework . should use dev_pm_ops . some cleanups wouldn't hurt . retu-rtc.c . needs suspend/resume (?) . retu-wdt.c . needs suspend/resume (?) patches also available at [1] for convenience [1] git://gitorious.org/usb/usb.git cbus Felipe Balbi (15): cbus: retu: drop retu_get_status cbus: retu: replace BUG_ON with WARN cbus: retu: drop the unnecessary spinlock_t cbus: retu: drop unused PFX macro arm: omap: cbus: add IDs for Retu and Tahvo arm: omap: pass Retu ID via platform_data cbus: retu: use the devid from platform_data cbus: retu: introduce internal read/write functions cbus: retu: search and replace cbus: retu: pwrbutton: save device pointer on our structure cbus: retu: pass the child device pointer to all retu functions cbus: retu: headset: don't save pdev pointer cbus: retu: replace EXPORT_SYMBOL with EXPORT_SYMBOL_GPL cbus: retu: tabify retu initialization cbus: retu: set pm_power_off to NULL when removing retu arch/arm/mach-omap1/board-nokia770.c |1 + arch/arm/mach-omap2/board-n8x0.c |1 + arch/arm/plat-omap/include/plat/cbus.h |4 + drivers/cbus/retu-headset.c| 35 --- drivers/cbus/retu-pwrbutton.c |4 +- drivers/cbus/retu-rtc.c| 34 +++ drivers/cbus/retu-wdt.c| 15 +--- drivers/cbus/retu.c| 160 +++- drivers/cbus/retu.h| 10 +- 9 files changed, 146 insertions(+), 118 deletions(-) -- 1.7.4.rc2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/15] cbus: retu: drop retu_get_status
children are allocated after retu core probes,
so by the time children start to probe, parent
is initialized for sure.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/cbus/retu-rtc.c |6 --
drivers/cbus/retu-wdt.c |8
drivers/cbus/retu.c |6 --
drivers/cbus/retu.h |1 -
4 files changed, 0 insertions(+), 21 deletions(-)
diff --git a/drivers/cbus/retu-rtc.c b/drivers/cbus/retu-rtc.c
index 5f52edf..303a4a6 100644
--- a/drivers/cbus/retu-rtc.c
+++ b/drivers/cbus/retu-rtc.c
@@ -215,12 +215,6 @@ static int __init retu_rtc_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, rtc);
mutex_init(rtc-mutex);
- r = retu_get_status();
- if (!r) {
- dev_err(pdev-dev, retu not initialized\n);
- goto err1;
- }
-
rtc-alarm_expired = retu_read_reg(RETU_REG_IDR)
(0x1 RETU_INT_RTCA);
diff --git a/drivers/cbus/retu-wdt.c b/drivers/cbus/retu-wdt.c
index 8b87ae9..423216c 100644
--- a/drivers/cbus/retu-wdt.c
+++ b/drivers/cbus/retu-wdt.c
@@ -230,10 +230,6 @@ static int __devinit retu_wdt_ping(void)
{
int r;
- r = retu_get_status();
- if (!r)
- return -ENODEV;
-
#ifdef CONFIG_WATCHDOG_NOWAYOUT
retu_modify_counter(RETU_WDT_MAX_TIMER);
#else
@@ -258,10 +254,6 @@ static int __init retu_wdt_probe(struct platform_device
*pdev)
struct retu_wdt_dev *wdev;
int ret;
- ret = retu_get_status();
- if (!ret)
- return -ENODEV;
-
wdev = kzalloc(sizeof(struct retu_wdt_dev), GFP_KERNEL);
if (!wdev)
return -ENOMEM;
diff --git a/drivers/cbus/retu.c b/drivers/cbus/retu.c
index 6134781..5886b00 100644
--- a/drivers/cbus/retu.c
+++ b/drivers/cbus/retu.c
@@ -74,12 +74,6 @@ struct retu {
static struct retu *the_retu;
-int retu_get_status(void)
-{
- return the_retu ? 1 : 0;
-}
-EXPORT_SYMBOL(retu_get_status);
-
/**
* retu_read_reg - Read a value from a register in Retu
* @reg: the register to read from
diff --git a/drivers/cbus/retu.h b/drivers/cbus/retu.h
index 1b05f3e..f2357a9 100644
--- a/drivers/cbus/retu.h
+++ b/drivers/cbus/retu.h
@@ -57,7 +57,6 @@
#defineMAX_RETU_IRQ_HANDLERS 16
-int retu_get_status(void);
int retu_read_reg(unsigned reg);
void retu_write_reg(unsigned reg, u16 val);
void retu_set_clear_reg_bits(unsigned reg, u16 set, u16 clear);
--
1.7.4.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/15] cbus: retu: replace BUG_ON with WARN
Instead of breaking the entire thing, just
WARN() about it.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/cbus/retu.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/cbus/retu.c b/drivers/cbus/retu.c
index 5886b00..032864a 100644
--- a/drivers/cbus/retu.c
+++ b/drivers/cbus/retu.c
@@ -82,7 +82,7 @@ static struct retu *the_retu;
*/
int retu_read_reg(unsigned reg)
{
- BUG_ON(!the_retu);
+ WARN(!the_retu, Retu not initialized\n);
return cbus_read_reg(RETU_ID, reg);
}
EXPORT_SYMBOL(retu_read_reg);
@@ -96,7 +96,7 @@ EXPORT_SYMBOL(retu_read_reg);
*/
void retu_write_reg(unsigned reg, u16 val)
{
- BUG_ON(!the_retu);
+ WARN(!the_retu, Retu not initialized\n);
cbus_write_reg(RETU_ID, reg, val);
}
EXPORT_SYMBOL(retu_write_reg);
--
1.7.4.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/15] cbus: retu: drop the unnecessary spinlock_t
gpiolib functions can sleep, and we already
have a mutex on the driver, so drop the
spinlock_t and use the mutex.
While at that, also rename irq_lock to
mutex since that's not used only for the
IRQ path anymore.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/cbus/retu.c | 21 -
1 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/cbus/retu.c b/drivers/cbus/retu.c
index 032864a..82d22b8 100644
--- a/drivers/cbus/retu.c
+++ b/drivers/cbus/retu.c
@@ -54,8 +54,7 @@
struct retu {
/* Device lock */
- spinlock_t lock;
- struct mutexirq_lock;
+ struct mutexmutex;
struct device *dev;
int irq_base;
@@ -104,15 +103,14 @@ EXPORT_SYMBOL(retu_write_reg);
void retu_set_clear_reg_bits(unsigned reg, u16 set, u16 clear)
{
struct retu *retu = the_retu;
- unsigned long flags;
u16 w;
- spin_lock_irqsave(retu-lock, flags);
+ mutex_lock(retu-mutex);
w = retu_read_reg(reg);
w = ~clear;
w |= set;
retu_write_reg(reg, w);
- spin_unlock_irqrestore(retu-lock, flags);
+ mutex_unlock(retu-mutex);
}
EXPORT_SYMBOL_GPL(retu_set_clear_reg_bits);
@@ -121,7 +119,6 @@ EXPORT_SYMBOL_GPL(retu_set_clear_reg_bits);
int retu_read_adc(int channel)
{
struct retu *retu = the_retu;
- unsigned long flags;
int res;
if (!retu)
@@ -130,7 +127,7 @@ int retu_read_adc(int channel)
if (channel 0 || channel ADC_MAX_CHAN_NUMBER)
return -EINVAL;
- spin_lock_irqsave(retu-lock, flags);
+ mutex_lock(retu-mutex);
if ((channel == 8) retu-is_vilma) {
int scr = retu_read_reg(RETU_REG_ADCSCR);
@@ -147,7 +144,7 @@ int retu_read_adc(int channel)
retu_write_reg(RETU_REG_ADCR, (1 13));
/* Unlock retu */
- spin_unlock_irqrestore(retu-lock, flags);
+ mutex_unlock(retu-mutex);
return res;
}
@@ -215,7 +212,7 @@ static void retu_bus_lock(struct irq_data *data)
{
struct retu *retu = irq_data_get_irq_chip_data(data);
- mutex_lock(retu-irq_lock);
+ mutex_lock(retu-mutex);
}
static void retu_bus_sync_unlock(struct irq_data *data)
@@ -232,7 +229,7 @@ static void retu_bus_sync_unlock(struct irq_data *data)
retu-ack_pending = false;
}
- mutex_unlock(retu-irq_lock);
+ mutex_unlock(retu-mutex);
}
static struct irq_chip retu_irq_chip = {
@@ -410,9 +407,7 @@ static int __init retu_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, retu);
the_retu = retu;
- /* Prepare tasklet */
- spin_lock_init(retu-lock);
- mutex_init(retu-irq_lock);
+ mutex_init(retu-mutex);
irq = platform_get_irq(pdev, 0);
--
1.7.4.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/15] cbus: retu: drop unused PFX macro
That's not used anywhere in the code,
so simply drop it.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/cbus/retu.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/cbus/retu.c b/drivers/cbus/retu.c
index 82d22b8..b1c8e57 100644
--- a/drivers/cbus/retu.c
+++ b/drivers/cbus/retu.c
@@ -50,7 +50,6 @@
#include retu.h
#define RETU_ID0x01
-#define PFXretu:
struct retu {
/* Device lock */
--
1.7.4.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/15] arm: omap: pass Retu ID via platform_data
Instead of hardcoding on the driver, pass
that via platform_data instead.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap1/board-nokia770.c |1 +
arch/arm/mach-omap2/board-n8x0.c |1 +
arch/arm/plat-omap/include/plat/cbus.h |1 +
3 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index d939370..f2a92b5 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -126,6 +126,7 @@ static struct resource retu_resource[] = {
static struct cbus_retu_platform_data nokia770_retu_data = {
.irq_base = CBUS_RETU_IRQ_BASE,
.irq_end= CBUS_RETU_IRQ_END,
+ .devid = CBUS_RETU_DEVICE_ID,
};
static struct platform_device retu_device = {
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 1e4bfb2..e00c0fa 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -223,6 +223,7 @@ static struct resource retu_resource[] = {
static struct cbus_retu_platform_data n8x0_retu_data = {
.irq_base = CBUS_RETU_IRQ_BASE,
.irq_end= CBUS_RETU_IRQ_END,
+ .devid = CBUS_RETU_DEVICE_ID,
};
static struct platform_device retu_device = {
diff --git a/arch/arm/plat-omap/include/plat/cbus.h
b/arch/arm/plat-omap/include/plat/cbus.h
index e7ace57..563b1c2 100644
--- a/arch/arm/plat-omap/include/plat/cbus.h
+++ b/arch/arm/plat-omap/include/plat/cbus.h
@@ -34,6 +34,7 @@ struct cbus_host_platform_data {
struct cbus_retu_platform_data {
int irq_base;
int irq_end;
+ int devid;
};
#endif /* __PLAT_CBUS_H */
--
1.7.4.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/15] cbus: retu: use the devid from platform_data
We are already passing the device ID via
platform_data, all we have to do know is
use it.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/cbus/retu.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/cbus/retu.c b/drivers/cbus/retu.c
index b1c8e57..d2326aa 100644
--- a/drivers/cbus/retu.c
+++ b/drivers/cbus/retu.c
@@ -49,13 +49,13 @@
#include cbus.h
#include retu.h
-#define RETU_ID0x01
-
struct retu {
/* Device lock */
struct mutexmutex;
struct device *dev;
+ int devid;
+
int irq_base;
int irq_end;
@@ -81,7 +81,7 @@ static struct retu *the_retu;
int retu_read_reg(unsigned reg)
{
WARN(!the_retu, Retu not initialized\n);
- return cbus_read_reg(RETU_ID, reg);
+ return cbus_read_reg(the_retu-devid, reg);
}
EXPORT_SYMBOL(retu_read_reg);
@@ -95,7 +95,7 @@ EXPORT_SYMBOL(retu_read_reg);
void retu_write_reg(unsigned reg, u16 val)
{
WARN(!the_retu, Retu not initialized\n);
- cbus_write_reg(RETU_ID, reg, val);
+ cbus_write_reg(the_retu-devid, reg, val);
}
EXPORT_SYMBOL(retu_write_reg);
@@ -413,6 +413,7 @@ static int __init retu_probe(struct platform_device *pdev)
retu-irq = irq;
retu-irq_base = pdata-irq_base;
retu-irq_end = pdata-irq_end;
+ retu-devid = pdata-devid;
retu_irq_init(retu);
--
1.7.4.rc2
--
To unsubscribe from this list: send the line unsubscribe 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 08/15] cbus: retu: introduce internal read/write functions
We already have the retu structure in others
parts of the retu driver, so instead of accessing
the_retu all over the place, we can start combining
those accesses.
While at that fix a kerneldoc comment on
retu_write_reg()
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/cbus/retu.c | 27 ---
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/cbus/retu.c b/drivers/cbus/retu.c
index d2326aa..7e4b7e5 100644
--- a/drivers/cbus/retu.c
+++ b/drivers/cbus/retu.c
@@ -73,6 +73,27 @@ struct retu {
static struct retu *the_retu;
/**
+ * __retu_read_reg - Read a value from a register in Retu
+ * @retu: pointer to retu structure
+ * @reg: the register address to read from
+ */
+static int __retu_read_reg(struct retu *retu, unsigned reg)
+{
+ return cbus_read_reg(retu-devid, reg);
+}
+
+/**
+ * __retu_write_reg - Writes a value to a register in Retu
+ * @retu: pointer to retu structure
+ * @reg: the register address to write to
+ * @val: the value to write to the register
+ */
+static void __retu_write_reg(struct retu *retu, unsigned reg, u16 val)
+{
+ cbus_write_reg(retu-devid, reg, val);
+}
+
+/**
* retu_read_reg - Read a value from a register in Retu
* @reg: the register to read from
*
@@ -81,21 +102,21 @@ static struct retu *the_retu;
int retu_read_reg(unsigned reg)
{
WARN(!the_retu, Retu not initialized\n);
- return cbus_read_reg(the_retu-devid, reg);
+ return __retu_read_reg(the_retu, reg);
}
EXPORT_SYMBOL(retu_read_reg);
/**
* retu_write_reg - Write a value to a register in Retu
* @reg: the register to write to
- * @reg: the value to write to the register
+ * @val: the value to write to the register
*
* This function writes a value to the specified register
*/
void retu_write_reg(unsigned reg, u16 val)
{
WARN(!the_retu, Retu not initialized\n);
- cbus_write_reg(the_retu-devid, reg, val);
+ __retu_write_reg(the_retu, reg, val);
}
EXPORT_SYMBOL(retu_write_reg);
--
1.7.4.rc2
--
To unsubscribe from this list: send the line unsubscribe 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 09/15] cbus: retu: search and replace
replace all occurrences of retu_read_reg
and retu_write_reg with the internal functions
__retu_read_reg and __retu_write_reg on retu.c
Achieved with the following vim command:
:%s/\retu_\(read\|write\)_reg(/__retu_\1_reg(retu, /gc
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/cbus/retu.c | 41 +++--
1 files changed, 23 insertions(+), 18 deletions(-)
diff --git a/drivers/cbus/retu.c b/drivers/cbus/retu.c
index 7e4b7e5..c798b58 100644
--- a/drivers/cbus/retu.c
+++ b/drivers/cbus/retu.c
@@ -126,10 +126,10 @@ void retu_set_clear_reg_bits(unsigned reg, u16 set, u16
clear)
u16 w;
mutex_lock(retu-mutex);
- w = retu_read_reg(reg);
+ w = __retu_read_reg(retu, reg);
w = ~clear;
w |= set;
- retu_write_reg(reg, w);
+ __retu_write_reg(retu, reg, w);
mutex_unlock(retu-mutex);
}
EXPORT_SYMBOL_GPL(retu_set_clear_reg_bits);
@@ -150,18 +150,18 @@ int retu_read_adc(int channel)
mutex_lock(retu-mutex);
if ((channel == 8) retu-is_vilma) {
- int scr = retu_read_reg(RETU_REG_ADCSCR);
- int ch = (retu_read_reg(RETU_REG_ADCR) 10) 0xf;
+ int scr = __retu_read_reg(retu, RETU_REG_ADCSCR);
+ int ch = (__retu_read_reg(retu, RETU_REG_ADCR) 10) 0xf;
if (((scr 0xff) != 0) (ch != 8))
- retu_write_reg (RETU_REG_ADCSCR, (scr ~0xff));
+ __retu_write_reg(retu, RETU_REG_ADCSCR, (scr ~0xff));
}
/* Select the channel and read result */
- retu_write_reg(RETU_REG_ADCR, channel 10);
- res = retu_read_reg(RETU_REG_ADCR) 0x3ff;
+ __retu_write_reg(retu, RETU_REG_ADCR, channel 10);
+ res = __retu_read_reg(retu, RETU_REG_ADCR) 0x3ff;
if (retu-is_vilma)
- retu_write_reg(RETU_REG_ADCR, (1 13));
+ __retu_write_reg(retu, RETU_REG_ADCR, (1 13));
/* Unlock retu */
mutex_unlock(retu-mutex);
@@ -179,8 +179,8 @@ static irqreturn_t retu_irq_handler(int irq, void *_retu)
u16 idr;
u16 imr;
- idr = retu_read_reg(RETU_REG_IDR);
- imr = retu_read_reg(RETU_REG_IMR);
+ idr = __retu_read_reg(retu, RETU_REG_IDR);
+ imr = __retu_read_reg(retu, RETU_REG_IMR);
idr = ~imr;
if (!idr) {
@@ -240,12 +240,12 @@ static void retu_bus_sync_unlock(struct irq_data *data)
struct retu *retu = irq_data_get_irq_chip_data(data);
if (retu-mask_pending) {
- retu_write_reg(RETU_REG_IMR, retu-mask);
+ __retu_write_reg(retu, RETU_REG_IMR, retu-mask);
retu-mask_pending = false;
}
if (retu-ack_pending) {
- retu_write_reg(RETU_REG_IDR, retu-ack);
+ __retu_write_reg(retu, RETU_REG_IDR, retu-ack);
retu-ack_pending = false;
}
@@ -309,10 +309,15 @@ static void retu_irq_exit(struct retu *retu)
*/
static void retu_power_off(void)
{
+ struct retu *retu = the_retu;
+ unsignedreg;
+
+ reg = __retu_read_reg(retu, RETU_REG_CC1);
+
/* Ignore power button state */
- retu_write_reg(RETU_REG_CC1, retu_read_reg(RETU_REG_CC1) | 2);
+ __retu_write_reg(retu, RETU_REG_CC1, reg | 2);
/* Expire watchdog immediately */
- retu_write_reg(RETU_REG_WATCHDOG, 0);
+ __retu_write_reg(retu, RETU_REG_WATCHDOG, 0);
/* Wait for poweroff*/
for (;;);
}
@@ -438,7 +443,7 @@ static int __init retu_probe(struct platform_device *pdev)
retu_irq_init(retu);
- rev = retu_read_reg(RETU_REG_ASICR) 0xff;
+ rev = __retu_read_reg(retu, RETU_REG_ASICR) 0xff;
if (rev (1 7))
retu-is_vilma = true;
@@ -447,7 +452,7 @@ static int __init retu_probe(struct platform_device *pdev)
(rev 4) 0x07, rev 0x0f);
/* Mask all RETU interrupts */
- retu_write_reg(RETU_REG_IMR, 0x);
+ __retu_write_reg(retu, RETU_REG_IMR, 0x);
ret = request_threaded_irq(irq, NULL, retu_irq_handler, 0,
retu, retu);
@@ -470,7 +475,7 @@ static int __init retu_probe(struct platform_device *pdev)
return 0;
err2:
- retu_write_reg(RETU_REG_IMR, 0x);
+ __retu_write_reg(retu, RETU_REG_IMR, 0x);
free_irq(irq, retu);
err1:
@@ -489,7 +494,7 @@ static int __exit retu_remove(struct platform_device *pdev)
irq = platform_get_irq(pdev, 0);
/* Mask all RETU interrupts */
- retu_write_reg(RETU_REG_IMR, 0x);
+ __retu_write_reg(retu, RETU_REG_IMR, 0x);
free_irq(irq, retu);
retu_irq_exit(retu);
kfree(retu);
--
1.7.4.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Re: OMAP: DSS2: Common IRQ handler for all OMAPs
Hi,
On Tuesday 15 February 2011 02:07 PM, Valkeinen, Tomi wrote:
On Tue, 2011-02-15 at 02:30 -0600, Taneja, Archit wrote:
Hi,
On Tuesday 15 February 2011 12:57 PM, Valkeinen, Tomi wrote:
snip
I meant something like this:
dispc.c:
dispc_init()
{
/* did we have a pdev for dispc? if not, this needs to be dss.pdev */
request_irq(platform_get_irq(dispc.pdev, 0), irq_handler, IRQF_SHARED,
dispc irq, foo);
}
irq_handler()
{
if (irq_can_be_shared) {
check if the irq is for us. exit if not;
}
handle;
}
dsi.c:
dsi_init()
{
request_irq(platform_get_irq(dsi.pdev, 0), irq_handler, IRQF_SHARED, dsi
irq, foo);
}
irq_handler()
{
if (irq_can_be_shared) {
check if the irq is for us. exit if not;
}
handle;
}
This approach looks clean, but isn't IRQF_SHARED used the other way
around. One irq line and multiple handlers?
That is the case here, isn't it (on omap3)? One interrupt line (the DSS
irq, the same returned both from dsi.pdev and dispc.pdev), and two
handlers, one in dispc and one in dsi? Or what do you mean?
Okay, so for OMAP3 we should populate dsi.pdev and dispc.pdev in such a
way that they return the single irq line number for DSS. And for OMAP4,
the separate line numbers will go for the modules anyway.
How do differentiate with the common handler now? It will be dirty if we
have checks on the irq_line. Could we pass the pdev as the arg to
differentiate the source?
On omap2 there's no dsi code ran, so dispc is the only one requesting
the irq, and thus IRQF_SHARED is extra. In omap4 there are separate irq
lines (dsi.pdev and dispc.pdev return different irqs), and so
IRQF_SHARED is again extra. But I don't see any harm in IRQF_SHARED even
in omap2/4.
Tomi
Regards,
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: omap3beagle: init musb default role by Kconfig
Currently musb is initialized to OTG mode by default in musb_board_data, it's
better to init it depending on Kconfig.
Signed-off-by: Bob Liu lliu...@gmail.com
---
arch/arm/mach-omap2/board-omap3beagle.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 14f4224..fb82773 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -554,7 +554,13 @@ static struct omap_board_mux board_mux[] __initdata = {
static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_ULPI,
- .mode = MUSB_OTG,
+#if defined(CONFIG_USB_MUSB_OTG)
+ .mode = MUSB_OTG,
+#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
+ .mode = MUSB_HOST,
+#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
+ .mode = MUSB_PERIPHERAL,
+#endif
.power = 100,
};
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/15] cbus: retu: pwrbutton: save device pointer on our structure
We will start passing our device pointer to
read/write functions exported from retu so
we need to save the device pointer on our
context structure.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/cbus/retu-pwrbutton.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/cbus/retu-pwrbutton.c b/drivers/cbus/retu-pwrbutton.c
index 593a73a..77c655d 100644
--- a/drivers/cbus/retu-pwrbutton.c
+++ b/drivers/cbus/retu-pwrbutton.c
@@ -47,6 +47,7 @@
struct retu_pwrbutton {
struct input_dev*idev;
+ struct device *dev;
int state;
int irq;
@@ -83,6 +84,7 @@ static int __init retubutton_probe(struct platform_device
*pdev)
goto err0;
}
+ pwr-dev = pdev-dev;
pwr-irq = platform_get_irq(pdev, 0);
platform_set_drvdata(pdev, pwr);
--
1.7.4.rc2
--
To unsubscribe from this list: send the line unsubscribe 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 v9 09/11 RESEND] OMAP: dmtimer: switch-over to platform device driver
NOTE: Missed code to configure timers to POSTED mode.
switch-over to platform device driver through following changes:
(a) call to dmtimer initialization routine from timer-gp.c is
removed (b) initiate dmtimer early initialization from omap2_init_common_hw
in io.c (c) modify plat-omap/dmtimer routines to use new register map and
platform data.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Acked-by: Cousson, Benoit b-cous...@ti.com
---
arch/arm/mach-omap2/clock2420_data.c |2 +-
arch/arm/mach-omap2/clock2430_data.c |2 +-
arch/arm/mach-omap2/clock3xxx_data.c |2 +-
arch/arm/mach-omap2/clock44xx_data.c |2 +-
arch/arm/mach-omap2/dmtimer.c | 61 +
arch/arm/mach-omap2/dmtimer.h | 30 +++
arch/arm/mach-omap2/io.c |3 +
arch/arm/mach-omap2/timer-gp.c|1 -
arch/arm/plat-omap/dmtimer.c | 350 -
arch/arm/plat-omap/include/plat/dmtimer.h |5 +-
10 files changed, 190 insertions(+), 268 deletions(-)
create mode 100644 arch/arm/mach-omap2/dmtimer.h
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index ee93d3c..390d6aa 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1801,7 +1801,7 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, virt_prcm_set, virt_prcm_set, CK_242X),
/* general l4 interface ck, multi-parent functional clk */
CLK(NULL, gpt1_ick, gpt1_ick, CK_242X),
- CLK(NULL, gpt1_fck, gpt1_fck, CK_242X),
+ CLK(omap_timer.1, fck, gpt1_fck, CK_242X),
CLK(NULL, gpt2_ick, gpt2_ick, CK_242X),
CLK(omap_timer.2, fck, gpt2_fck, CK_242X),
CLK(NULL, gpt3_ick, gpt3_ick, CK_242X),
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index 24553ce..7a3e5a4 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1905,7 +1905,7 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, virt_prcm_set, virt_prcm_set, CK_243X),
/* general l4 interface ck, multi-parent functional clk */
CLK(NULL, gpt1_ick, gpt1_ick, CK_243X),
- CLK(NULL, gpt1_fck, gpt1_fck, CK_243X),
+ CLK(omap_timer.1, fck, gpt1_fck, CK_243X),
CLK(NULL, gpt2_ick, gpt2_ick, CK_243X),
CLK(omap_timer.2, fck, gpt2_fck, CK_243X),
CLK(NULL, gpt3_ick, gpt3_ick, CK_243X),
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 524d995..f318115 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3374,7 +3374,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, usbhost_ick, usbhost_ick, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(ehci-omap.0, usbhost_ick, usbhost_ick, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(NULL, usim_fck, usim_fck, CK_3430ES2PLUS |
CK_36XX),
- CLK(NULL, gpt1_fck, gpt1_fck, CK_3XXX),
+ CLK(omap_timer.1, fck, gpt1_fck, CK_3XXX),
CLK(NULL, wkup_32k_fck, wkup_32k_fck, CK_3XXX),
CLK(NULL, gpio1_dbck, gpio1_dbck,CK_3XXX),
CLK(omap_wdt, fck, wdt2_fck, CK_3XXX),
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 11997a3..8f8b010 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3181,7 +3181,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, smartreflex_core_fck, smartreflex_core_fck,
CK_443X),
CLK(NULL, smartreflex_iva_fck, smartreflex_iva_fck,
CK_443X),
CLK(NULL, smartreflex_mpu_fck, smartreflex_mpu_fck,
CK_443X),
- CLK(NULL, gpt1_fck, timer1_fck,
CK_443X),
+ CLK(omap_timer.1, fck, timer1_fck,
CK_443X),
CLK(omap_timer.10,fck, timer10_fck,
CK_443X),
CLK(omap_timer.11,fck, timer11_fck,
CK_443X),
CLK(omap_timer.2, fck, timer2_fck,
CK_443X),
diff --git a/arch/arm/mach-omap2/dmtimer.c b/arch/arm/mach-omap2/dmtimer.c
index 00cebe9..63d5ae7 100644
--- a/arch/arm/mach-omap2/dmtimer.c
+++ b/arch/arm/mach-omap2/dmtimer.c
@@ -197,3 +197,64 @@ static int __init omap_timer_init(struct omap_hwmod *oh,
void *unused)
return ret;
}
+
+/**
+ * omap2_dm_timer_early_init - top level early timer initialization
+ * called in the last part of omap2_init_common_hw
+ *
+ * Uses dedicated hwmod api to parse through hwmod database for
+ * given class name and then build and register the
Re: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation can cause data corruption
On Tue, Feb 15, 2011 at 1:14 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
-Original Message-
From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com]
Sent: Monday, February 14, 2011 10:39 AM
To: Andrei Warkentin
Cc: linux-omap@vger.kernel.org; Kevin Hilman; t...@atomide.com;
linux-arm-ker...@lists.infradead.org; Catalin Marinas
Subject: RE: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way
operation can cause data corruption
[]
...
I understood that from first comment. But I am not in favor
of polluting common ARM files with SOC specific #ifdeffery.
We have gone over this when first errata support
was added for PL310
I have a better way to handle this scenario.
Expect an updated patch for this.
Below is the updated version which should remove any
OMAP dependency on these errata's. Attached same.
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Fri, 14 Jan 2011 14:16:04 +0530
Subject: [v2 PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation
can cause data corruption
PL310 implements the Clean Invalidate by Way L2 cache maintenance
operation (offset 0x7FC). This operation runs in background so that
PL310 can handle normal accesses while it is in progress. Under very
rare circumstances, due to this erratum, write data can be lost when
PL310 treats a cacheable write transaction during a Clean Invalidate
by Way operation.
Workaround:
Disable Write-Back and Cache Linefill (Debug Control Register)
Clean Invalidate by Way (0x7FC)
Re-enable Write-Back and Cache Linefill (Debug Control Register)
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Catalin Marinas catalin.mari...@arm.com
---
arch/arm/Kconfig | 13 -
arch/arm/include/asm/outercache.h | 1 +
arch/arm/mach-omap2/Kconfig | 3 +++
arch/arm/mach-omap2/omap4-common.c | 7 +++
arch/arm/mm/cache-l2x0.c | 28 +++-
5 files changed, 38 insertions(+), 14 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5cff165..ebadd95 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1140,7 +1140,7 @@ config ARM_ERRATA_742231
config PL310_ERRATA_588369
bool Clean Invalidate maintenance operations do not invalidate
clean lines
- depends on CACHE_L2X0 ARCH_OMAP4
+ depends on CACHE_L2X0 CACHE_PL310
help
The PL310 L2 cache controller implements three types of Clean
Invalidate maintenance operations: by Physical Address
@@ -1177,6 +1177,17 @@ config ARM_ERRATA_743622
visible impact on the overall performance or power consumption
of the
processor.
+config PL310_ERRATA_727915
+ bool Background Clean Invalidate by Way operation can cause
data corruption
+ depends on CACHE_L2X0 CACHE_PL310
+ help
+ PL310 implements the Clean Invalidate by Way L2 cache
maintenance
+ operation (offset 0x7FC). This operation runs in background so
that
+ PL310 can handle normal accesses while it is in progress. Under
very
+ rare circumstances, due to this erratum, write data can be lost
when
+ PL310 treats a cacheable write transaction during a Clean
+ Invalidate by Way operation Note that this errata uses Texas
+ Instrument's secure monitor api to implement the work around.
endmenu
source arch/arm/common/Kconfig
diff --git a/arch/arm/include/asm/outercache.h
b/arch/arm/include/asm/outercache.h
index fc19009..348d513 100644
--- a/arch/arm/include/asm/outercache.h
+++ b/arch/arm/include/asm/outercache.h
@@ -31,6 +31,7 @@ struct outer_cache_fns {
#ifdef CONFIG_OUTER_CACHE_SYNC
void (*sync)(void);
#endif
+ void (*set_debug)(unsigned long);
};
#ifdef CONFIG_OUTER_CACHE
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index f285dd7..fd11ab4 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -45,7 +45,10 @@ config ARCH_OMAP4
select CPU_V7
select ARM_GIC
select LOCAL_TIMERS
+ select CACHE_L2X0
+ select CACHE_PL310
select PL310_ERRATA_588369
+ select PL310_ERRATA_727915
select ARM_ERRATA_720789
select ARCH_HAS_OPP
select PM_OPP if PM
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index 1926864..9ef8c29 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -52,6 +52,12 @@ static void omap4_l2x0_disable(void)
omap_smc1(0x102, 0x0);
}
+static void omap4_l2x0_set_debug(unsigned long val)
+{
+ /* Program PL310 L2 Cache controller debug register */
+ omap_smc1(0x100, val);
+}
+
static int __init omap_l2_cache_init(void)
{
u32 aux_ctrl = 0;
@@ -99,6 +105,7 @@ static int __init omap_l2_cache_init(void)
* specific one
*/
RE: [PATCH] omap: dmtimer: Enable autoidle
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of tero.kri...@nokia.com Sent: Tuesday, February 15, 2011 1:47 PM To: Hilman, Kevin Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH] omap: dmtimer: Enable autoidle -Original Message- From: ext Kevin Hilman [mailto:khil...@ti.com] Sent: 15 February, 2011 01:29 To: Kristo Tero (Nokia-MS/Tampere) Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] omap: dmtimer: Enable autoidle Tero Kristo tero.kri...@nokia.com writes: This will save some power. Signed-off-by: Tero Kristo tero.kri...@nokia.com Please report which platforms this was tested with. Tested only on OMAP3. Should this be changed to apply only on that one? I don't know about OMAP4, but I think this should work on OMAP2 at least based on spec. It works on OMAP2 and OMAP4. -- Tarun Also, please Cc linux-arm-kernel. Thanks, Kevin --- arch/arm/plat-omap/dmtimer.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat- omap/dmtimer.c index 1d706cf..949becc 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -341,6 +341,7 @@ static void omap_dm_timer_reset(struct omap_dm_timer *timer) l = omap_dm_timer_read_reg(timer, OMAP_TIMER_OCP_CFG_REG); l |= 0x02 3; /* Set to smart-idle mode */ l |= 0x2 8; /* Set clock activity to perserve f-clock on idle */ + l |= 0x1 0; /* Set autoidle */ /* * Enable wake-up on OMAP2 CPUs. -- To unsubscribe from this list: send the line unsubscribe 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: OMAP: DSS2: Common IRQ handler for all OMAPs
Copying Benoit,
On Tuesday 15 February 2011 02:07 PM, Valkeinen, Tomi wrote:
On Tue, 2011-02-15 at 02:30 -0600, Taneja, Archit wrote:
Hi,
On Tuesday 15 February 2011 12:57 PM, Valkeinen, Tomi wrote:
snip
I meant something like this:
dispc.c:
dispc_init()
{
/* did we have a pdev for dispc? if not, this needs to be dss.pdev */
request_irq(platform_get_irq(dispc.pdev, 0), irq_handler, IRQF_SHARED,
dispc irq, foo);
}
irq_handler()
{
if (irq_can_be_shared) {
check if the irq is for us. exit if not;
}
handle;
}
dsi.c:
dsi_init()
{
request_irq(platform_get_irq(dsi.pdev, 0), irq_handler, IRQF_SHARED, dsi
irq, foo);
}
irq_handler()
{
if (irq_can_be_shared) {
check if the irq is for us. exit if not;
}
handle;
}
This approach looks clean, but isn't IRQF_SHARED used the other way
around. One irq line and multiple handlers?
That is the case here, isn't it (on omap3)? One interrupt line (the DSS
irq, the same returned both from dsi.pdev and dispc.pdev), and two
handlers, one in dispc and one in dsi? Or what do you mean?
On omap2 there's no dsi code ran, so dispc is the only one requesting
the irq, and thus IRQF_SHARED is extra. In omap4 there are separate irq
lines (dsi.pdev and dispc.pdev return different irqs), and so
IRQF_SHARED is again extra. But I don't see any harm in IRQF_SHARED even
in omap2/4.
Tomi
Benoit,
Is it okay to have the same irq entry for 2 different hwmods?
This requirement comes from OMAP3 where dispc and dsi have a common irq
line, where as on OMAP4 dispc and dsi have separate irq lines.
We basically want to get rid of a central dss irq handler (hence, remove
irq entries for dss_core hwmod) and instead have separate irq handlers
for each module which may or may not share an irq line.
Regards,
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation can cause data corruption
-Original Message-
From: Andrei Warkentin [mailto:andr...@motorola.com]
Sent: Tuesday, February 15, 2011 2:40 PM
To: Santosh Shilimkar
Cc: linux-arm-ker...@lists.infradead.org; linux-
o...@vger.kernel.org; Kevin Hilman; t...@atomide.com; Catalin
Marinas
Subject: Re: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way
operation can cause data corruption
On Tue, Feb 15, 2011 at 1:14 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
-Original Message-
From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com]
Sent: Monday, February 14, 2011 10:39 AM
To: Andrei Warkentin
Cc: linux-omap@vger.kernel.org; Kevin Hilman; t...@atomide.com;
linux-arm-ker...@lists.infradead.org; Catalin Marinas
Subject: RE: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way
operation can cause data corruption
[]
Why set by default to NULL, why not have a normal l2x0_set_debug
which
just does a write to L2X0_DEBUG_CTRL, and then just invoke the
function pointer when you wish to manipulate the DCR? That way you
don't need the runtime check, and it's just clearer, I think.
I though about it. There more changes in the file and hence I
avoided it. This can be done though.
Also, why not do something like -
do_stuff();
#ifdef CONFIG_NEED_ERRATA_1234
do_errata_stuff();
#endif
do_more_stuff();
...
Which makes code completely ugly.
instead of -
...
#ifdef CONFIG_NEED_ERRATA_1234
do_some_stuf() {
bar();
}
#else
{
do_some_stuff() {
}
// nothing
}
We have already discussed this. The code becomes ugly. If you
are interested in the reasoning, please check archives.
Russell and Catalin has suggested above.
If you understand the errata in first place, you could
understand the comment.
I let Catalin, Russell comment on it more, but unnecessary
CONFIG options and polluting every function with #If, else
checks don't make sense. Rest of your comments are related
to this.
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] omap: dmtimer: Enable autoidle
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of DebBarma, Tarun Kanti Sent: Tuesday, February 15, 2011 2:50 PM To: tero.kri...@nokia.com; Hilman, Kevin Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH] omap: dmtimer: Enable autoidle -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of tero.kri...@nokia.com Sent: Tuesday, February 15, 2011 1:47 PM To: Hilman, Kevin Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH] omap: dmtimer: Enable autoidle -Original Message- From: ext Kevin Hilman [mailto:khil...@ti.com] Sent: 15 February, 2011 01:29 To: Kristo Tero (Nokia-MS/Tampere) Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] omap: dmtimer: Enable autoidle Tero Kristo tero.kri...@nokia.com writes: This will save some power. Signed-off-by: Tero Kristo tero.kri...@nokia.com Please report which platforms this was tested with. Tested only on OMAP3. Should this be changed to apply only on that one? I don't know about OMAP4, but I think this should work on OMAP2 at least based on spec. It works on OMAP2 and OMAP4. Ok, on OMAP4 I should have clarified further. AUTOIDLE is present only for millisecond timers: 1,2,10. The reset of the timers do not have this bit. -- Tarun Also, please Cc linux-arm-kernel. Thanks, Kevin --- arch/arm/plat-omap/dmtimer.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat- omap/dmtimer.c index 1d706cf..949becc 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -341,6 +341,7 @@ static void omap_dm_timer_reset(struct omap_dm_timer *timer) l = omap_dm_timer_read_reg(timer, OMAP_TIMER_OCP_CFG_REG); l |= 0x02 3; /* Set to smart-idle mode */ l |= 0x2 8; /* Set clock activity to perserve f-clock on idle */ +l |= 0x1 0; /* Set autoidle */ /* * Enable wake-up on OMAP2 CPUs. -- To unsubscribe from this list: send the line unsubscribe 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 -- To unsubscribe from this list: send the line unsubscribe linux-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] OMAP: PM: implement devices wakeup latency constraints APIs
-Original Message-
From: jean.pi...@newoldbits.com [mailto:jean.pi...@newoldbits.com]
Sent: Friday, February 11, 2011 12:53 AM
To: khil...@ti.com; p...@pwsan.com; Vibhore Vardhan; Santosh
Shilimkar; Vishwanath BS; rna...@ti.com
Cc: linux-omap@vger.kernel.org; Jean Pihet; Vibhore Vardhan
Subject: [PATCH 2/2] OMAP: PM: implement devices wakeup latency
constraints APIs
From: Jean Pihet j-pi...@ti.com
Implement OMAP PM layer omap_pm_set_max_dev_wakeup_lat API by
creating similar APIs at the omap_device and omap_hwmod levels. The
omap_hwmod level call is the layer with access to the powerdomain
core, so it is the place where the powerdomain is queried to set and
release the constraints.
NOTE: only works for devices which have been converted to use
omap_device/omap_hwmod.
Longer term, we could possibly remove this API from the OMAP PM layer,
and instead directly use the omap_device level API.
Based on Vibhore's original patch , adapted to omap_device and
omap_hwmod frameworks.
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Vibhore Vardhan vvard...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 62 +-
arch/arm/mach-omap2/powerdomain.c | 176
-
arch/arm/mach-omap2/powerdomain.h | 31 +
arch/arm/mach-omap2/powerdomains3xxx_data.c | 60
+
arch/arm/plat-omap/include/plat/omap_device.h |2 +
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 +
arch/arm/plat-omap/omap-pm-constraints.c | 101 ++-
arch/arm/plat-omap/omap_device.c | 28
8 files changed, 399 insertions(+), 63 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-
omap2/omap_hwmod.c
index e282e35..0dc096f 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -142,6 +142,7 @@
#include powerdomain.h
#include plat/clock.h
#include plat/omap_hwmod.h
+#include plat/omap_device.h
#include plat/prcm.h
#include cm2xxx_3xxx.h
@@ -2198,10 +2199,69 @@ ohsps_unlock:
}
/**
+ * omap_hwmod_set_max_dev_wakeup_lat - set a device wake-up
constraint
+ * @oh: struct omap_hwmod *
+ * @req_oh: struct omap_hwmod *
Need to explain what this parameters mean.
+ * @t: wakeup latency constraint (us). -1 removes the existing
constraint
+ *
+ * Query the powerdomain of @oh to set/release the wake-up
constraint
+ *
+ * Returns -EINVAL if @oh or @req_oh have no power domain, or the
return
+ * code from the pwrdm function
(pwrdm_wakeuplat_set/release_constraint)
+ * of the powerdomain assocated with @oh.
+ */
+int omap_hwmod_set_max_dev_wakeup_lat(struct omap_hwmod
*req_oh,
+ struct omap_hwmod *oh, long t)
+{
+ struct device *req_dev;
+ struct platform_device *pdev;
+ struct powerdomain *pwrdm;
+ int ret = 0;
+
+ pwrdm = omap_hwmod_get_pwrdm(oh);
+
+ /* Catch devices with undefined powerdomains */
+ if (!pwrdm) {
+ pr_err(omap_hwmod: Error: could not find parent
+ powerdomain for %s\n, oh-name);
+ return -EINVAL;
+ }
+
+ pdev = (req_oh-od-pdev);
+ if (pdev == NULL) {
+ pr_err(omap_hwmod: Error: pdev not found for oh %s\n,
+oh-name);
+ return -EINVAL;
+ }
+
+ req_dev = (pdev-dev);
+ if (req_dev == NULL) {
+ pr_err(omap_hwmod: Error: device not found for oh
%s\n,
+oh-name);
+ return -EINVAL;
+ }
If I understand correctly, req_dev is used for keeping track of different
requests. If so, why can't you directly pass req_dev as an input param
instead of deriving it from pdev.
+
+ /* Call set/release_constraint for the given pwrdm */
+ if (t == -1) {
+ pr_debug(omap_hwmod: remove max device latency
constraint:
+ oh %s, pwrdm %s, req by oh %s\n,
+ oh-name, pwrdm-name, req_oh-name);
+ ret = pwrdm_wakeuplat_release_constraint(pwrdm,
req_dev);
+ } else {
+ pr_debug(omap_hwmod: add max device latency
constraint:
+ oh %s, t = %ld usec, pwrdm %s, req by oh
%s\n,
+ oh-name, t, pwrdm-name, req_oh-name);
+ ret = pwrdm_wakeuplat_set_constraint(pwrdm, req_dev,
t);
+ }
+
+ return 0;
+}
+
+/**
* omap_hwmod_get_context_loss_count - get lost context count
* @oh: struct omap_hwmod *
*
- * Query the powerdomain of of @oh to get the context loss
+ * Query the powerdomain of @oh to get the context loss
* count for this device.
*
* Returns the context loss count of the powerdomain assocated with
@oh
diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-
omap2/powerdomain.c
index eaed0df..3ed3bea 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
RE: [PATCH 0/3]OMAP4: Keypad support
Hi, Any comments on this series. Thanking you, With Regards, Shubhro -Original Message- From: shubhrajy...@ti.com [mailto:shubhrajy...@ti.com] Sent: Monday, December 27, 2010 11:22 AM To: linux-omap@vger.kernel.org; linux-in...@vger.kernel.org Cc: Shubhrajyoti D Subject: [PATCH 0/3]OMAP4: Keypad support From: Shubhrajyoti D a0393...@india.ti.com Adding the keypad 4430sdp board support and PM runtime change. Tested on 4430sdp. Abraham Arce (1): OMAP4:keypad: PM runtime Benoit Cousson (1): OMAP4: hwmod data: Add keypad in the hwmod database Syed Rafiuddin (1): OMAP4: keypad: Add the board support. arch/arm/mach-omap2/board-4430sdp.c| 89 arch/arm/mach-omap2/devices.c | 41 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 70 ++ drivers/input/keyboard/omap4-keypad.c |8 +++ 4 files changed, 208 insertions(+), 0 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
[1/7 v2] usb: otg: enable regulator only on cable/device connect
From: Kalliguddi, Hema hem...@ti.com
Remove the regulator enable while driver loading and enable it only when
the cable/device is connected and disable it when disconnected.
Remove the configuration of config_state and config_trans register
configuration as these registers are programmed when regulator
enable/disable is called.
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi ba...@ti.com
---
drivers/usb/otg/twl6030-usb.c | 27 ---
1 file changed, 12 insertions(+), 15 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
Index: linux-2.6/drivers/usb/otg/twl6030-usb.c
===
--- linux-2.6.orig/drivers/usb/otg/twl6030-usb.c
+++ linux-2.6/drivers/usb/otg/twl6030-usb.c
@@ -158,8 +158,6 @@ static int twl6030_phy_init(struct otg_t
dev = twl-dev;
pdata = dev-platform_data;
- regulator_enable(twl-usb3v3);
-
hw_state = twl6030_readb(twl, TWL6030_MODULE_ID0, STS_HW_CONDITIONS);
if (hw_state STS_USB_ID)
@@ -180,7 +178,6 @@ static void twl6030_phy_shutdown(struct
dev = twl-dev;
pdata = dev-platform_data;
pdata-phy_power(twl-dev, 0, 0);
- regulator_disable(twl-usb3v3);
}
static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
@@ -199,16 +196,6 @@ static int twl6030_usb_ldo_init(struct t
if (IS_ERR(twl-usb3v3))
return -ENODEV;
- regulator_enable(twl-usb3v3);
-
- /* Program the VUSB_CFG_TRANS for ACTIVE state. */
- twl6030_writeb(twl, TWL_MODULE_PM_RECEIVER, 0x3F,
- VUSB_CFG_TRANS);
-
- /* Program the VUSB_CFG_STATE register to ON on all groups. */
- twl6030_writeb(twl, TWL_MODULE_PM_RECEIVER, 0xE1,
- VUSB_CFG_STATE);
-
/* Program the USB_VBUS_CTRL_SET and set VBUS_ACT_COMP bit */
twl6030_writeb(twl, TWL_MODULE_USB, 0x4, USB_VBUS_CTRL_SET);
@@ -261,16 +248,23 @@ static irqreturn_t twl6030_usb_irq(int i
CONTROLLER_STAT1);
if (!(hw_state STS_USB_ID)) {
if (vbus_state VBUS_DET) {
+ regulator_enable(twl-usb3v3);
+ twl-asleep = 1;
status = USB_EVENT_VBUS;
twl-otg.default_a = false;
twl-otg.state = OTG_STATE_B_IDLE;
+ twl-linkstat = status;
+ blocking_notifier_call_chain(twl-otg.notifier,
+ status, twl-otg.gadget);
} else {
status = USB_EVENT_NONE;
- }
- if (status = 0) {
twl-linkstat = status;
blocking_notifier_call_chain(twl-otg.notifier,
status, twl-otg.gadget);
+ if (twl-asleep) {
+ regulator_disable(twl-usb3v3);
+ twl-asleep = 0;
+ }
}
}
sysfs_notify(twl-dev-kobj, NULL, vbus);
@@ -288,6 +282,8 @@ static irqreturn_t twl6030_usbotg_irq(in
if (hw_state STS_USB_ID) {
+ regulator_enable(twl-usb3v3);
+ twl-asleep = 1;
twl6030_writeb(twl, TWL_MODULE_USB, USB_ID_INT_EN_HI_CLR, 0x1);
twl6030_writeb(twl, TWL_MODULE_USB, USB_ID_INT_EN_HI_SET,
0x10);
@@ -437,6 +433,7 @@ static int __devinit twl6030_usb_probe(s
return status;
}
+ twl-asleep = 0;
pdata-phy_init(dev);
twl6030_enable_irq(twl-otg);
dev_info(pdev-dev, Initialized TWL6030 USB module\n);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[2/7 v2] usb: otg: Remove one unnecessary I2C read request.
From: Kalliguddi, Hema hem...@ti.com
To get the ID status there was an I2C read transfer. Removed this I2C
read transfer as this info can be used from existing variable(linkstat).
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi ba...@ti.com
---
drivers/usb/otg/twl6030-usb.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Index: linux-2.6/drivers/usb/otg/twl6030-usb.c
===
--- linux-2.6.orig/drivers/usb/otg/twl6030-usb.c
+++ linux-2.6/drivers/usb/otg/twl6030-usb.c
@@ -149,7 +149,6 @@ static int twl6030_set_phy_clk(struct ot
static int twl6030_phy_init(struct otg_transceiver *x)
{
- u8 hw_state;
struct twl6030_usb *twl;
struct device *dev;
struct twl4030_usb_data *pdata;
@@ -158,9 +157,7 @@ static int twl6030_phy_init(struct otg_t
dev = twl-dev;
pdata = dev-platform_data;
- hw_state = twl6030_readb(twl, TWL6030_MODULE_ID0, STS_HW_CONDITIONS);
-
- if (hw_state STS_USB_ID)
+ if (twl-linkstat == USB_EVENT_ID)
pdata-phy_power(twl-dev, 1, 1);
else
pdata-phy_power(twl-dev, 0, 1);
@@ -290,6 +287,7 @@ static irqreturn_t twl6030_usbotg_irq(in
status = USB_EVENT_ID;
twl-otg.default_a = true;
twl-otg.state = OTG_STATE_A_IDLE;
+ twl-linkstat = status;
blocking_notifier_call_chain(twl-otg.notifier, status,
twl-otg.gadget);
} else {
@@ -299,7 +297,6 @@ static irqreturn_t twl6030_usbotg_irq(in
0x1);
}
twl6030_writeb(twl, TWL_MODULE_USB, USB_ID_INT_LATCH_CLR, status);
- twl-linkstat = status;
return IRQ_HANDLED;
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[3/7 v2] usb: otg: OMAP4430: Introducing suspend function for power management
From: Kalliguddi, Hema hem...@ti.com
Introduced the suspend/resume function for the OMAP4430 internal PHY.
This will be used by the twl6030-usb transceiver driver.
Moved the clock enable/disable function calls and power on/off of the PHY
code from power on/off functions to suspend/resume function.
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/omap_phy_internal.c | 22 +++---
1 file changed, 15 insertions(+), 7 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
Index: linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/omap_phy_internal.c
+++ linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
@@ -103,13 +103,6 @@ int omap4430_phy_set_clk(struct device *
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);
- mdelay(200);
- }
if (ID)
/* enable VBUS valid, IDDIG groung */
__raw_writel(AVALID | VBUSVALID, ctrl_base +
@@ -125,10 +118,25 @@ int omap4430_phy_power(struct device *de
/* Enable session END and IDIG to high impedence. */
__raw_writel(SESSEND | IDDIG, ctrl_base +
USBOTGHS_CONTROL);
+ }
+ return 0;
+}
+
+int omap4430_phy_suspend(struct device *dev, int suspend)
+{
+ if (suspend) {
/* Disable the clocks */
omap4430_phy_set_clk(dev, 0);
/* Power down the phy */
__raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
+ } else {
+ /* Enable the internel phy clcoks */
+ 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);
+ mdelay(200);
+ }
}
return 0;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[4/7 v2] usb: otg: OMAP4430: Add phy_suspend function pointer to
From: Kalliguddi, Hema hem...@ti.com
Introduce the .phy_suspend function pointer to twl4030_usb_data structure.
assign the function to it for both sdp board and panda boards.
This will be used by the twl6030-usb transceiver driver.
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c|1 +
arch/arm/mach-omap2/board-omap4panda.c |1 +
arch/arm/plat-omap/include/plat/usb.h |1 +
include/linux/i2c/twl.h|2 ++
4 files changed, 5 insertions(+)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Index: linux-2.6/arch/arm/mach-omap2/board-4430sdp.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/board-4430sdp.c
+++ linux-2.6/arch/arm/mach-omap2/board-4430sdp.c
@@ -272,6 +272,7 @@ static struct twl4030_usb_data omap4_usb
.phy_exit = omap4430_phy_exit,
.phy_power = omap4430_phy_power,
.phy_set_clock = omap4430_phy_set_clk,
+ .phy_suspend= omap4430_phy_suspend,
};
static struct omap2_hsmmc_info mmc[] = {
Index: linux-2.6/arch/arm/mach-omap2/board-omap4panda.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/board-omap4panda.c
+++ linux-2.6/arch/arm/mach-omap2/board-omap4panda.c
@@ -153,6 +153,7 @@ static struct twl4030_usb_data omap4_usb
.phy_exit = omap4430_phy_exit,
.phy_power = omap4430_phy_power,
.phy_set_clock = omap4430_phy_set_clk,
+ .phy_suspend= omap4430_phy_suspend,
};
static struct omap2_hsmmc_info mmc[] = {
Index: linux-2.6/arch/arm/plat-omap/include/plat/usb.h
===
--- linux-2.6.orig/arch/arm/plat-omap/include/plat/usb.h
+++ linux-2.6/arch/arm/plat-omap/include/plat/usb.h
@@ -88,6 +88,7 @@ extern int omap4430_phy_power(struct dev
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 omap4430_phy_suspend(struct device *dev, int suspend);
#endif
Index: linux-2.6/include/linux/i2c/twl.h
===
--- linux-2.6.orig/include/linux/i2c/twl.h
+++ linux-2.6/include/linux/i2c/twl.h
@@ -600,6 +600,8 @@ struct twl4030_usb_data {
int (*phy_power)(struct device *dev, int iD, int on);
/* enable/disable phy clocks */
int (*phy_set_clock)(struct device *dev, int on);
+ /* suspend/resume of phy */
+ int (*phy_suspend)(struct device *dev, int suspend);
};
struct twl4030_ins {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[5/7 v2] usb: otg: TWL6030: Introduce the twl6030_phy_suspend function.
From: Kalliguddi, Hema hem...@ti.com
Introduce the twl6030_phy_suspend function and assign to otg.set_suspend
function pointer.
This function is used by the musb-omap2430 platform driver
during suspend/resume.
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi ba...@ti.com
---
drivers/usb/otg/twl6030-usb.c | 16
1 file changed, 16 insertions(+)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Index: linux-2.6/drivers/usb/otg/twl6030-usb.c
===
--- linux-2.6.orig/drivers/usb/otg/twl6030-usb.c
+++ linux-2.6/drivers/usb/otg/twl6030-usb.c
@@ -177,6 +177,20 @@ static void twl6030_phy_shutdown(struct
pdata-phy_power(twl-dev, 0, 0);
}
+static int twl6030_phy_suspend(struct otg_transceiver *x, int suspend)
+{
+ struct twl6030_usb *twl;
+ struct device *dev;
+ struct twl4030_usb_data *pdata;
+
+ twl = xceiv_to_twl(x);
+ dev = twl-dev;
+ pdata = dev-platform_data;
+ pdata-phy_suspend(twl-dev, suspend);
+
+ return 0;
+}
+
static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
{
@@ -388,6 +402,7 @@ static int __devinit twl6030_usb_probe(s
twl-otg.set_vbus = twl6030_set_vbus;
twl-otg.init = twl6030_phy_init;
twl-otg.shutdown = twl6030_phy_shutdown;
+ twl-otg.set_suspend= twl6030_phy_suspend;
/* init spinlock for workqueue */
spin_lock_init(twl-lock);
@@ -432,6 +447,7 @@ static int __devinit twl6030_usb_probe(s
twl-asleep = 0;
pdata-phy_init(dev);
+ twl6030_phy_suspend(twl-otg, 0);
twl6030_enable_irq(twl-otg);
dev_info(pdev-dev, Initialized TWL6030 USB module\n);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[7/7 v2] usb: musb: OMAP4430: Fix usb device detection if connected during boot
From: Kalliguddi, Hema hem...@ti.com
OMAP4430 is embedded with UTMI PHY. This PHY does not support the
OTG features like ID pin detection and VBUS detection. This function
is exported to an external companion chip TWL6030. Software must retrieve
the OTG HNP and SRP status from the TWL6030 and configure the bits inside
the control module that drive the related USBOTGHS UTMI interface signals.
It must also read back the UTMI signals needed to configure the TWL6030
OTG module.
Can find more details in the TRM[1].
[1]:http://focus.ti.com/pdfs/wtbu/OMAP4430_ES2.0_Public_TRM_vJ.pdf
In OMAP4430 musb driver VBUS and ID notifications are received from the
transceiver driver. If the cable/device is connected during boot,
notifications from transceiver driver will be missed till musb driver
is loaded.
Patch to configure the transceiver in the platform_enable/disable
functions and enable the vbus in the gadget driver based on the
last_event of the otg_transceiver.
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi ba...@ti.com
---
[Fixed the comments from Felipe]
drivers/usb/musb/musb_gadget.c |4 +++
drivers/usb/musb/omap2430.c| 49 -
2 files changed, 48 insertions(+), 5 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Index: linux-2.6/drivers/usb/musb/musb_gadget.c
===
--- linux-2.6.orig/drivers/usb/musb/musb_gadget.c
+++ linux-2.6/drivers/usb/musb/musb_gadget.c
@@ -1855,6 +1855,10 @@ int usb_gadget_probe_driver(struct usb_g
} else {
hcd-self.uses_pio_for_control = 1;
}
+
+ if ((musb-xceiv-last_event == USB_EVENT_ID)
+musb-xceiv-set_vbus)
+ otg_set_vbus(musb-xceiv, 1);
}
}
Index: linux-2.6/drivers/usb/musb/omap2430.c
===
--- linux-2.6.orig/drivers/usb/musb/omap2430.c
+++ linux-2.6/drivers/usb/musb/omap2430.c
@@ -350,16 +350,56 @@ static int omap2430_musb_init(struct mus
if (status)
DBG(1, notification register failed\n);
- /* check whether cable is already connected */
- if (musb-xceiv-state ==OTG_STATE_B_IDLE)
- musb_otg_notifications(musb-nb, 1,
- musb-xceiv-gadget);
-
setup_timer(musb_idle_timer, musb_do_idle, (unsigned long) musb);
return 0;
}
+static void omap2430_musb_enable(struct musb *musb)
+{
+ u8 devctl;
+ unsigned long timeout = jiffies + msecs_to_jiffies(1000);
+ struct device *dev = musb-controller;
+ struct musb_hdrc_platform_data *pdata = dev-platform_data;
+ struct omap_musb_board_data *data = pdata-board_data;
+
+ switch (musb-xceiv-last_event) {
+
+ case USB_EVENT_ID:
+ otg_init(musb-xceiv);
+ if (data-interface_type == MUSB_INTERFACE_UTMI) {
+ devctl = musb_readb(musb-mregs, MUSB_DEVCTL);
+ /* start the session */
+ devctl |= MUSB_DEVCTL_SESSION;
+ musb_writeb(musb-mregs, MUSB_DEVCTL, devctl);
+ while (musb_readb(musb-mregs, MUSB_DEVCTL)
+ MUSB_DEVCTL_BDEVICE) {
+ cpu_relax();
+
+ if (time_after(jiffies, timeout)) {
+ dev_err(musb-controller,
+ configured as A device timeout);
+ break;
+ }
+ }
+ }
+ break;
+
+ case USB_EVENT_VBUS:
+ otg_init(musb-xceiv);
+ break;
+
+ default:
+ break;
+ }
+}
+
+static void omap2430_musb_disable(struct musb *musb)
+{
+ if (musb-xceiv-last_event)
+ otg_shutdown(musb-xceiv);
+}
+
static int omap2430_musb_exit(struct musb *musb)
{
@@ -377,6 +417,9 @@ static const struct musb_platform_ops om
.try_idle = omap2430_musb_try_idle,
.set_vbus = omap2430_musb_set_vbus,
+
+ .enable = omap2430_musb_enable,
+ .disable= omap2430_musb_disable,
};
static u64 omap2430_dmamask = DMA_BIT_MASK(32);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[6/7 v2] usb: otg: TWL6030 Save the last event in otg_transceiver
From: Kalliguddi, Hema hem...@ti.com
Save the last event in the otg_transceiver so that it can used in the
musb driver and gadget driver to configure the musb and enable the
vbus for host mode and OTG mode, if the device is connected during boot.
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi ba...@ti.com
---
[Reusing some part of the patch[1] posted by Arnaud Mandy]
[1] http://permalink.gmane.org/gmane.linux.usb.general/37123
---
drivers/usb/otg/twl6030-usb.c |3 +++
include/linux/usb/otg.h |1 +
2 files changed, 4 insertions(+)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Index: linux-2.6/drivers/usb/otg/twl6030-usb.c
===
--- linux-2.6.orig/drivers/usb/otg/twl6030-usb.c
+++ linux-2.6/drivers/usb/otg/twl6030-usb.c
@@ -265,11 +265,13 @@ static irqreturn_t twl6030_usb_irq(int i
twl-otg.default_a = false;
twl-otg.state = OTG_STATE_B_IDLE;
twl-linkstat = status;
+ twl-otg.last_event = status;
blocking_notifier_call_chain(twl-otg.notifier,
status, twl-otg.gadget);
} else {
status = USB_EVENT_NONE;
twl-linkstat = status;
+ twl-otg.last_event = status;
blocking_notifier_call_chain(twl-otg.notifier,
status, twl-otg.gadget);
if (twl-asleep) {
@@ -302,6 +304,7 @@ static irqreturn_t twl6030_usbotg_irq(in
twl-otg.default_a = true;
twl-otg.state = OTG_STATE_A_IDLE;
twl-linkstat = status;
+ twl-otg.last_event = status;
blocking_notifier_call_chain(twl-otg.notifier, status,
twl-otg.gadget);
} else {
Index: linux-2.6/include/linux/usb/otg.h
===
--- linux-2.6.orig/include/linux/usb/otg.h
+++ linux-2.6/include/linux/usb/otg.h
@@ -66,6 +66,7 @@ struct otg_transceiver {
u8 default_a;
enum usb_otg_state state;
+ enum usb_xceiv_events last_event;
struct usb_bus *host;
struct usb_gadget *gadget;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap: dmtimer: Enable autoidle
-Original Message- From: ext DebBarma, Tarun Kanti [mailto:tarun.ka...@ti.com] Sent: 15 February, 2011 11:31 To: Kristo Tero (Nokia-MS/Tampere); Hilman, Kevin Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH] omap: dmtimer: Enable autoidle -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of DebBarma, Tarun Kanti Sent: Tuesday, February 15, 2011 2:50 PM To: tero.kri...@nokia.com; Hilman, Kevin Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH] omap: dmtimer: Enable autoidle -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of tero.kri...@nokia.com Sent: Tuesday, February 15, 2011 1:47 PM To: Hilman, Kevin Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH] omap: dmtimer: Enable autoidle -Original Message- From: ext Kevin Hilman [mailto:khil...@ti.com] Sent: 15 February, 2011 01:29 To: Kristo Tero (Nokia-MS/Tampere) Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] omap: dmtimer: Enable autoidle Tero Kristo tero.kri...@nokia.com writes: This will save some power. Signed-off-by: Tero Kristo tero.kri...@nokia.com Please report which platforms this was tested with. Tested only on OMAP3. Should this be changed to apply only on that one? I don't know about OMAP4, but I think this should work on OMAP2 at least based on spec. It works on OMAP2 and OMAP4. Ok, on OMAP4 I should have clarified further. AUTOIDLE is present only for millisecond timers: 1,2,10. The reset of the timers do not have this bit. Does it matter if the bit is set on the timers that don't have it or does the HW just ignore it? Or should we enumerate the timers that support it on omap4? -- Tarun Also, please Cc linux-arm-kernel. Thanks, Kevin --- arch/arm/plat-omap/dmtimer.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat- omap/dmtimer.c index 1d706cf..949becc 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -341,6 +341,7 @@ static void omap_dm_timer_reset(struct omap_dm_timer *timer) l = omap_dm_timer_read_reg(timer, OMAP_TIMER_OCP_CFG_REG); l |= 0x02 3; /* Set to smart-idle mode */ l |= 0x2 8; /* Set clock activity to perserve f-clock on idle */ + l |= 0x1 0; /* Set autoidle */ /* * Enable wake-up on OMAP2 CPUs. -- To unsubscribe from this list: send the line unsubscribe 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap: dmtimer: Enable autoidle
[...] Should this be changed to apply only on that one? I don't know about OMAP4, but I think this should work on OMAP2 at least based on spec. It works on OMAP2 and OMAP4. Ok, on OMAP4 I should have clarified further. AUTOIDLE is present only for millisecond timers: 1,2,10. The reset of the timers do not have this bit. Does it matter if the bit is set on the timers that don't have it or does the HW just ignore it? Or should we enumerate the timers that support it on omap4? For other timers it happens to be SOFTRESET bit. So HW would not ignore. -- Tarun Also, please Cc linux-arm-kernel. Thanks, Kevin --- arch/arm/plat-omap/dmtimer.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat- omap/dmtimer.c index 1d706cf..949becc 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -341,6 +341,7 @@ static void omap_dm_timer_reset(struct omap_dm_timer *timer) l = omap_dm_timer_read_reg(timer, OMAP_TIMER_OCP_CFG_REG); l |= 0x02 3; /* Set to smart-idle mode */ l |= 0x2 8; /* Set clock activity to perserve f-clock on idle */ + l |= 0x1 0; /* Set autoidle */ /* * Enable wake-up on OMAP2 CPUs. -- To unsubscribe from this list: send the line unsubscribe 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP: DSS2: Common IRQ handler for all OMAPs
Hi Archit,
On 2/15/2011 10:25 AM, Taneja, Archit wrote:
Copying Benoit,
On Tuesday 15 February 2011 02:07 PM, Valkeinen, Tomi wrote:
On Tue, 2011-02-15 at 02:30 -0600, Taneja, Archit wrote:
Hi,
On Tuesday 15 February 2011 12:57 PM, Valkeinen, Tomi wrote:
snip
I meant something like this:
dispc.c:
dispc_init()
{
/* did we have a pdev for dispc? if not, this needs to be dss.pdev */
request_irq(platform_get_irq(dispc.pdev, 0), irq_handler, IRQF_SHARED,
dispc irq, foo);
}
irq_handler()
{
if (irq_can_be_shared) {
check if the irq is for us. exit if not;
}
handle;
}
dsi.c:
dsi_init()
{
request_irq(platform_get_irq(dsi.pdev, 0), irq_handler, IRQF_SHARED, dsi
irq, foo);
}
irq_handler()
{
if (irq_can_be_shared) {
check if the irq is for us. exit if not;
}
handle;
}
This approach looks clean, but isn't IRQF_SHARED used the other way
around. One irq line and multiple handlers?
That is the case here, isn't it (on omap3)? One interrupt line (the DSS
irq, the same returned both from dsi.pdev and dispc.pdev), and two
handlers, one in dispc and one in dsi? Or what do you mean?
On omap2 there's no dsi code ran, so dispc is the only one requesting
the irq, and thus IRQF_SHARED is extra. In omap4 there are separate irq
lines (dsi.pdev and dispc.pdev return different irqs), and so
IRQF_SHARED is again extra. But I don't see any harm in IRQF_SHARED even
in omap2/4.
Tomi
Benoit,
Is it okay to have the same irq entry for 2 different hwmods?
This requirement comes from OMAP3 where dispc and dsi have a common irq
line, where as on OMAP4 dispc and dsi have separate irq lines.
Well, no. I explained that in one of my comment about hwmod
modification. The hwmod data are reflecting the exact HW capabilities.
So, if there is a change in the HW, the hwmod will be different.
It is up to the driver to adapt to this change.
The driver has to evolve to handle properly the new HW capabilities
while keeping the old stuff working.
We basically want to get rid of a central dss irq handler (hence, remove
irq entries for dss_core hwmod) and instead have separate irq handlers
for each module which may or may not share an irq line.
Then you need to hack your driver but not the hwmod data:-(
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: OMAP: DSS2: Common IRQ handler for all OMAPs
Hi Benoit,
On Tue, Feb 15, 2011 at 3:53 PM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Archit,
On 2/15/2011 10:25 AM, Taneja, Archit wrote:
Copying Benoit,
On Tuesday 15 February 2011 02:07 PM, Valkeinen, Tomi wrote:
On Tue, 2011-02-15 at 02:30 -0600, Taneja, Archit wrote:
Hi,
On Tuesday 15 February 2011 12:57 PM, Valkeinen, Tomi wrote:
snip
I meant something like this:
dispc.c:
dispc_init()
{
/* did we have a pdev for dispc? if not, this needs to be
dss.pdev */
request_irq(platform_get_irq(dispc.pdev, 0), irq_handler,
IRQF_SHARED, dispc irq, foo);
}
irq_handler()
{
if (irq_can_be_shared) {
check if the irq is for us. exit if not;
}
handle;
}
dsi.c:
dsi_init()
{
request_irq(platform_get_irq(dsi.pdev, 0), irq_handler,
IRQF_SHARED, dsi irq, foo);
}
irq_handler()
{
if (irq_can_be_shared) {
check if the irq is for us. exit if not;
}
handle;
}
This approach looks clean, but isn't IRQF_SHARED used the other way
around. One irq line and multiple handlers?
That is the case here, isn't it (on omap3)? One interrupt line (the DSS
irq, the same returned both from dsi.pdev and dispc.pdev), and two
handlers, one in dispc and one in dsi? Or what do you mean?
On omap2 there's no dsi code ran, so dispc is the only one requesting
the irq, and thus IRQF_SHARED is extra. In omap4 there are separate irq
lines (dsi.pdev and dispc.pdev return different irqs), and so
IRQF_SHARED is again extra. But I don't see any harm in IRQF_SHARED even
in omap2/4.
Tomi
Benoit,
Is it okay to have the same irq entry for 2 different hwmods?
This requirement comes from OMAP3 where dispc and dsi have a common irq
line, where as on OMAP4 dispc and dsi have separate irq lines.
Well, no. I explained that in one of my comment about hwmod modification.
The hwmod data are reflecting the exact HW capabilities.
So, if there is a change in the HW, the hwmod will be different.
It is up to the driver to adapt to this change.
I guess what Archit wanted to say is, for hw IPs DISPC and DSI, on
OMAP3, have a common IRQ line, so could both their hwmod databases
have the same IRQ added for them? This would us call, for a common IRQ
line shared w/ DISPC and DSI, like
mentioned in Tomi's sample code above.
How is hwmod data for these cases handled today? [shared IRQ,
different platform devices?]
Best regards,
~Sumit.
The driver has to evolve to handle properly the new HW capabilities while
keeping the old stuff working.
We basically want to get rid of a central dss irq handler (hence, remove
irq entries for dss_core hwmod) and instead have separate irq handlers
for each module which may or may not share an irq line.
Then you need to hack your driver but not the hwmod data:-(
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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
On Mon, Feb 14, 2011 at 11:15 PM, Kevin Hilman khil...@ti.com wrote: Hi Dave, Dave Martin dave.mar...@linaro.org writes: On Mon, Feb 14, 2011 at 10:00:23AM -0500, Nicolas Pitre wrote: On Mon, 14 Feb 2011, Dave Martin wrote: @@ -289,8 +297,20 @@ clean_l2: * - should be faster and will change with kernel * - 'might' have to copy address, load and jump to it */ +#ifdef CONFIG_THUMB2_KERNEL + /* kernel is non-interworking : must do this from Thumb */ + adr r1, . + 1 + bx r1 + .thumb +#endif ldr r1, kernel_flush Didn't you mean this instead: /* kernel is non-interworking : must do this from Thumb */ adr r1, 1f + 1 bx r1 .thumb 1: ldr r1, kernel_flush ... Note that this is intended as an experimental hack, not a real patch (apologies if I didn't make that clear...) Well, actually I meant add r1, pc, #1 ... which means I was too busy trying to be clever... oops! That is of course exactly equivalent to your code... ? blx r1 +#ifdef CONFIG_THUMB2_KERNEL + .align + bx pc + nop + .arm Also here, the .align has the potential to introduce a zero halfword in the instruction stream before the bx. What about: adr r3, 1f bx r3 .align .arm 1: ... .align inserts a 16-bit nop when misaligned in Thumb in a text section, and a word-aligned bx pc is a specific architecturally allowed way to do an inline switch to ARM. The linker uses this trick for PLT veneers etc. A nicer fix for doing this sort of call from low-level code which might be ARM is to convert arch/arm/mm/*-v7.S to use bx lr to return. Generally, we can do this for all arches = v5, without any incompatibility. However, since the need for it will be rare and it will generate patch noise for not much real benefit, I haven't proposed this. Updated patch below. I tested the updated patch on top of your dirty branch I tested with last week, and now see off-mode working just fine. Thanks for testing-- that's great news. I will have a think about whether the patch can be tidied up to revert most of the code back to Thumb, though that isn't essential. If I've understood what's going on correctly, I think only the restore entry points, SMC call sites and the entry to omap3_sram_configure_core_dpll could need to be ARM; the rest shouldn't really make any difference... Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP: DSS2: Common IRQ handler for all OMAPs
Hi Sumit,
On 2/15/2011 11:28 AM, Semwal, Sumit wrote:
Hi Benoit,
On Tue, Feb 15, 2011 at 3:53 PM, Cousson, Benoitb-cous...@ti.com wrote:
Hi Archit,
On 2/15/2011 10:25 AM, Taneja, Archit wrote:
Copying Benoit,
On Tuesday 15 February 2011 02:07 PM, Valkeinen, Tomi wrote:
On Tue, 2011-02-15 at 02:30 -0600, Taneja, Archit wrote:
Hi,
On Tuesday 15 February 2011 12:57 PM, Valkeinen, Tomi wrote:
snip
I meant something like this:
dispc.c:
dispc_init()
{
/* did we have a pdev for dispc? if not, this needs to be
dss.pdev */
request_irq(platform_get_irq(dispc.pdev, 0), irq_handler,
IRQF_SHARED, dispc irq, foo);
}
irq_handler()
{
if (irq_can_be_shared) {
check if the irq is for us. exit if not;
}
handle;
}
dsi.c:
dsi_init()
{
request_irq(platform_get_irq(dsi.pdev, 0), irq_handler,
IRQF_SHARED, dsi irq, foo);
}
irq_handler()
{
if (irq_can_be_shared) {
check if the irq is for us. exit if not;
}
handle;
}
This approach looks clean, but isn't IRQF_SHARED used the other way
around. One irq line and multiple handlers?
That is the case here, isn't it (on omap3)? One interrupt line (the DSS
irq, the same returned both from dsi.pdev and dispc.pdev), and two
handlers, one in dispc and one in dsi? Or what do you mean?
On omap2 there's no dsi code ran, so dispc is the only one requesting
the irq, and thus IRQF_SHARED is extra. In omap4 there are separate irq
lines (dsi.pdev and dispc.pdev return different irqs), and so
IRQF_SHARED is again extra. But I don't see any harm in IRQF_SHARED even
in omap2/4.
Tomi
Benoit,
Is it okay to have the same irq entry for 2 different hwmods?
This requirement comes from OMAP3 where dispc and dsi have a common irq
line, where as on OMAP4 dispc and dsi have separate irq lines.
Well, no. I explained that in one of my comment about hwmod modification.
The hwmod data are reflecting the exact HW capabilities.
So, if there is a change in the HW, the hwmod will be different.
It is up to the driver to adapt to this change.
I guess what Archit wanted to say is, for hw IPs DISPC and DSI, on
OMAP3, have a common IRQ line, so could both their hwmod databases
have the same IRQ added for them? This would us call, for a common IRQ
line shared w/ DISPC and DSI, like
mentioned in Tomi's sample code above.
OK, thanks for the clarification, actually I missed a little bit the
point :-(
So in fact the 2 modules share that same IRQ today, and you just want to
populate both hwmod with the same input.
If this is a real OR between the two IRQ lines, meaning the dispc cannot
mask the dsi IRQ or the opposite, then having the same IRQ number in the
two different hwmods is a correct representation of the HW.
Then both devices with get the same IRQ number during the
platform_get_irq, so if the driver is aware of that it is fine.
How is hwmod data for these cases handled today? [shared IRQ,
different platform devices?]
I don't think we have such case today at least on OMAP4. Or maybe it is
just not properly documented, so only one hwmod is mapped to the IRQ line.
Regards,
Benoit
Best regards,
~Sumit.
The driver has to evolve to handle properly the new HW capabilities while
keeping the old stuff working.
We basically want to get rid of a central dss irq handler (hence, remove
irq entries for dss_core hwmod) and instead have separate irq handlers
for each module which may or may not share an irq line.
Then you need to hack your driver but not the hwmod data:-(
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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] ARM: pm: add generic CPU suspend/resume support
On Mon, Feb 14, 2011 at 08:11:23PM -0800, Colin Cross wrote: Even with a cache flush, cpu_resume_turn_on_mmu fails because the page table modification, done with the cache off, ends up in memory, but the L2 contains the old value. When the MMU and cache are enabled, the 1:1 mapping disappears. The page table would need to be invalidated during suspend. I can avoid the problem entirely by leaving the MMU on and skipping cpu_resume when the CPU does not go through reset. If you're not losing CPU state, what's the point in calling the suspend function? It's purpose is to save CPU state ready for the CPU going to sleep and losing power, and restoring that state when the CPU wakes up sometime later. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] omap3: minor clean-up in flash related code
Changes include: - fixing typos - using pr_err() instead of printk Sanjeev Premi (2): omap3: fix minor typos omap3: flash: use pr_err instead of printk arch/arm/mach-omap2/board-flash.c | 19 --- 1 files changed, 8 insertions(+), 11 deletions(-) -- 1.7.2.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] omap3: fix minor typos
This patch fixes typos that were remaining after the file and functions were renamed. Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/mach-omap2/board-flash.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/board-flash.c b/arch/arm/mach-omap2/board-flash.c index fd38c05..ce61200 100644 --- a/arch/arm/mach-omap2/board-flash.c +++ b/arch/arm/mach-omap2/board-flash.c @@ -1,5 +1,5 @@ /* - * board-sdp-flash.c + * board-flash.c * Modified from mach-omap2/board-3430sdp-flash.c * * Copyright (C) 2009 Nokia Corporation @@ -189,7 +189,7 @@ unmap: } /** - * sdp3430_flash_init - Identify devices connected to GPMC and register. + * board_flash_init - Identify devices connected to GPMC and register. * * @return - void. */ -- 1.7.2.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] omap3: flash: use pr_err instead of printk
Change all occurences of printf() to pr_err().
Includes minor formatting changes as result of
this change.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
arch/arm/mach-omap2/board-flash.c | 15 ++-
1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index ce61200..86d1020 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -73,11 +73,11 @@ __init board_nor_init(struct mtd_partition *nor_parts, u8
nr_parts, u8 cs)
+ FLASH_SIZE_SDPV1 - 1;
}
if (err 0) {
- printk(KERN_ERR NOR: Can't request GPMC CS\n);
+ pr_err(NOR: Can't request GPMC CS\n);
return;
}
if (platform_device_register(board_nor_device) 0)
- printk(KERN_ERR Unable to register NOR device\n);
+ pr_err(Unable to register NOR device\n);
}
#if defined(CONFIG_MTD_ONENAND_OMAP2) || \
@@ -208,7 +208,7 @@ void board_flash_init(struct flash_partitions
partition_info[],
*/
idx = get_gpmc0_type();
if (idx = MAX_SUPPORTED_GPMC_CONFIG) {
- printk(KERN_ERR %s: Invalid chip select: %d\n, __func__, cs);
+ pr_err(%s: Invalid chip select: %d\n, __func__, cs);
return;
}
config_sel = (unsigned char *)(chip_sel_board[idx]);
@@ -232,22 +232,19 @@ void board_flash_init(struct flash_partitions
partition_info[],
}
if (norcs GPMC_CS_NUM)
- printk(KERN_INFO NOR: Unable to find configuration
- in GPMC\n);
+ pr_err(NOR: Unable to find configuration in GPMC\n);
else
board_nor_init(partition_info[0].parts,
partition_info[0].nr_parts, norcs);
if (onenandcs GPMC_CS_NUM)
- printk(KERN_INFO OneNAND: Unable to find configuration
- in GPMC\n);
+ pr_err(OneNAND: Unable to find configuration in GPMC\n);
else
board_onenand_init(partition_info[1].parts,
partition_info[1].nr_parts, onenandcs);
if (nandcs GPMC_CS_NUM)
- printk(KERN_INFO NAND: Unable to find configuration
- in GPMC\n);
+ pr_err(NAND: Unable to find configuration in GPMC\n);
else
board_nand_init(partition_info[2].parts,
partition_info[2].nr_parts, nandcs);
--
1.7.2.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP: DSS2: Common IRQ handler for all OMAPs
Hi, On Tue, Feb 15, 2011 at 10:37:37AM +0200, Tomi Valkeinen wrote: This approach looks clean, but isn't IRQF_SHARED used the other way around. One irq line and multiple handlers? That is the case here, isn't it (on omap3)? One interrupt line (the DSS irq, the same returned both from dsi.pdev and dispc.pdev), and two handlers, one in dispc and one in dsi? Or what do you mean? IMO, for omap3 it would be better to have irq_chip there. Then you can keep e.g. DISPC IRQ disabled until dispc.c calls request_irq(). What happens today if you have IRQ enabled but dispc isn't ready to act on those ? On omap2 there's no dsi code ran, so dispc is the only one requesting the irq, and thus IRQF_SHARED is extra. In omap4 there are separate irq lines (dsi.pdev and dispc.pdev return different irqs), and so IRQF_SHARED is again extra. But I don't see any harm in IRQF_SHARED even in omap2/4. What if another HW requests the wrong IRQ number and it ends up being your dispc IRQ line ? -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] ARM: pm: add generic CPU suspend/resume support
On Fri, Feb 11, 2011 at 06:50:57PM -0800, Colin Cross wrote: +ENDPROC(cpu_resume_turn_mmu_on) +cpu_resume_after_mmu: + str r5, [r2, r4, lsl #2] @ restore old mapping +#ifdef MULTI_CACHE + ldr r10, =cpu_cache + ldr pc, [r10, #CACHE_FLUSH_KERN_ALL] +#else + b __cpuc_flush_kern_all +#endif I think we can eliminate this cache flush by delaying the cache enable as below. Could you see whether Tegra 2 survives this please? Thanks. diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S index bed1876..193be5f 100644 --- a/arch/arm/kernel/sleep.S +++ b/arch/arm/kernel/sleep.S @@ -4,6 +4,7 @@ #include asm/assembler.h #include asm/glue-cache.h #include asm/glue-proc.h +#include asm/system.h .text /* @@ -81,25 +82,22 @@ ENTRY(cpu_resume_mmu) str r3, [r2, r4, lsl #2]@ setup 1:1 mapping for mmu code sub r2, r2, r1 ldr r3, =cpu_resume_after_mmu + bic r1, r0, #CR_C @ ensure D-cache is disabled b cpu_resume_turn_mmu_on ENDPROC(cpu_resume_mmu) .ltorg .align 5 cpu_resume_turn_mmu_on: - mcr p15, 0, r0, c1, c0, 0 @ turn on MMU, caches, etc - mrc p15, 0, r0, c0, c0, 0 @ read id reg - mov r0, r0 - mov r0, r0 + mcr p15, 0, r1, c1, c0, 0 @ turn on MMU, I-cache, etc + mrc p15, 0, r1, c0, c0, 0 @ read id reg + mov r1, r1 + mov r1, r1 mov pc, r3 @ jump to virtual address ENDPROC(cpu_resume_turn_mmu_on) cpu_resume_after_mmu: str r5, [r2, r4, lsl #2]@ restore old mapping -#ifdef MULTI_CACHE - ldr r10, =cpu_cache - ldr pc, [r10, #CACHE_FLUSH_KERN_ALL] -#else - b __cpuc_flush_kern_all -#endif + mcr p15, 0, r0, c1, c0, 0 @ turn on D-cache + mov pc, lr /* * Note: Yes, part of the following code is located into the .data section. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap3beagle: init musb default role by Kconfig
Hi, On Tue, Feb 15, 2011 at 04:55:00PM +0800, Bob Liu wrote: Currently musb is initialized to OTG mode by default in musb_board_data, it's better to init it depending on Kconfig. what's the problem in always keeping OTG ? that board is wired for OTG anyway. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP: DSS2: Common IRQ handler for all OMAPs
On Tue, 2011-02-15 at 04:57 -0600, Balbi, Felipe wrote: Hi, On Tue, Feb 15, 2011 at 10:37:37AM +0200, Tomi Valkeinen wrote: This approach looks clean, but isn't IRQF_SHARED used the other way around. One irq line and multiple handlers? That is the case here, isn't it (on omap3)? One interrupt line (the DSS irq, the same returned both from dsi.pdev and dispc.pdev), and two handlers, one in dispc and one in dsi? Or what do you mean? IMO, for omap3 it would be better to have irq_chip there. Then you can keep e.g. DISPC IRQ disabled until dispc.c calls request_irq(). What happens today if you have IRQ enabled but dispc isn't ready to act on those ? Currently we have a single interrupt handler, which then calls either dispc and/or dsi handler. Dispc and dsi are always ready to handle those. I don't think it would be a good solution if irq_chip would be used only for omap3. Then we'd have totally different solutions for different omap versions. But if irq_chip can be easily used for all omap versions, then perhaps. But then again, using IRQF_SHARED should (I think) solve the problem quite easily without big changes to the code. irq_chip sounds like a bigger change. On omap2 there's no dsi code ran, so dispc is the only one requesting the irq, and thus IRQF_SHARED is extra. In omap4 there are separate irq lines (dsi.pdev and dispc.pdev return different irqs), and so IRQF_SHARED is again extra. But I don't see any harm in IRQF_SHARED even in omap2/4. What if another HW requests the wrong IRQ number and it ends up being your dispc IRQ line ? Are you asking what happens if we have a bug in kernel code? Anything can happen =). But I don't see that as a reason not to use IRQF_SHARED. 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
[PATCH v2] OMAP: IOMMU: add missing function declaration
Declaration of exported function 'iopgtable_lookup_entry' is missing from header file. Currently we have a sparse warning as it's not being used externally. Adding its declaration to avoid such warning and allow its usage in future. Signed-off-by: David Cohen daco...@gmail.com --- arch/arm/plat-omap/include/plat/iommu.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/iommu.h b/arch/arm/plat-omap/include/plat/iommu.h index 69230d6..19cbb5e 100644 --- a/arch/arm/plat-omap/include/plat/iommu.h +++ b/arch/arm/plat-omap/include/plat/iommu.h @@ -154,6 +154,8 @@ extern void flush_iotlb_range(struct iommu *obj, u32 start, u32 end); extern void flush_iotlb_all(struct iommu *obj); extern int iopgtable_store_entry(struct iommu *obj, struct iotlb_entry *e); +extern void iopgtable_lookup_entry(struct iommu *obj, u32 da, u32 **ppgd, + u32 **ppte); extern size_t iopgtable_clear_entry(struct iommu *obj, u32 iova); extern int iommu_set_da_range(struct iommu *obj, u32 start, u32 end); -- 1.7.2.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH resend] video: omap24xxcam: Fix compilation
Thomas Weber wrote: Add linux/sched.h because of missing declaration of TASK_NORMAL. This patch fixes the following error: drivers/media/video/omap24xxcam.c: In function 'omap24xxcam_vbq_complete': drivers/media/video/omap24xxcam.c:415: error: 'TASK_NORMAL' undeclared (first use in this function) drivers/media/video/omap24xxcam.c:415: error: (Each undeclared identifier is reported only once drivers/media/video/omap24xxcam.c:415: error: for each function it appears in.) Signed-off-by: Thomas Weber we...@corscience.de Thanks, Thomas! Acked-by: Sakari Ailus sakari.ai...@iki.fi --- drivers/media/video/omap24xxcam.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/omap24xxcam.c b/drivers/media/video/omap24xxcam.c index 0175527..f6626e8 100644 --- a/drivers/media/video/omap24xxcam.c +++ b/drivers/media/video/omap24xxcam.c @@ -36,6 +36,7 @@ #include linux/clk.h #include linux/io.h #include linux/slab.h +#include linux/sched.h #include media/v4l2-common.h #include media/v4l2-ioctl.h -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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 resend] video: omap24xxcam: Fix compilation
On Tue, Feb 15, 2011 at 01:28:19PM +0200, Sakari Ailus wrote:
Thomas Weber wrote:
Add linux/sched.h because of missing declaration of TASK_NORMAL.
This patch fixes the following error:
drivers/media/video/omap24xxcam.c: In function
'omap24xxcam_vbq_complete':
drivers/media/video/omap24xxcam.c:415: error: 'TASK_NORMAL' undeclared
(first use in this function)
drivers/media/video/omap24xxcam.c:415: error: (Each undeclared
identifier is reported only once
drivers/media/video/omap24xxcam.c:415: error: for each function it
appears in.)
Signed-off-by: Thomas Weber we...@corscience.de
Thanks, Thomas!
Are we using the same tree ? I don't see anything related to TASK_* on
that function on today's mainline, here's a copy of the function:
387 static void omap24xxcam_vbq_complete(struct omap24xxcam_sgdma *sgdma,
388 u32 csr, void *arg)
389 {
390 struct omap24xxcam_device *cam =
391 container_of(sgdma, struct omap24xxcam_device, sgdma);
392 struct omap24xxcam_fh *fh = cam-streaming-private_data;
393 struct videobuf_buffer *vb = (struct videobuf_buffer *)arg;
394 const u32 csr_error = CAMDMA_CSR_MISALIGNED_ERR
395 | CAMDMA_CSR_SUPERVISOR_ERR | CAMDMA_CSR_SECURE_ERR
396 | CAMDMA_CSR_TRANS_ERR | CAMDMA_CSR_DROP;
397 unsigned long flags;
398
399 spin_lock_irqsave(cam-core_enable_disable_lock, flags);
400 if (--cam-sgdma_in_queue == 0)
401 omap24xxcam_core_disable(cam);
402 spin_unlock_irqrestore(cam-core_enable_disable_lock, flags);
403
404 do_gettimeofday(vb-ts);
405 vb-field_count = atomic_add_return(2, fh-field_count);
406 if (csr csr_error) {
407 vb-state = VIDEOBUF_ERROR;
408 if (!atomic_read(fh-cam-in_reset)) {
409 dev_dbg(cam-dev, resetting camera, csr 0x%x\n,
csr);
410 omap24xxcam_reset(cam);
411 }
412 } else
413 vb-state = VIDEOBUF_DONE;
414 wake_up(vb-done);
415 }
see that line 415 is where the function ends. My head is
795abaf1e4e188c4171e3cd3dbb11a9fcacaf505
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP: DSS2: Common IRQ handler for all OMAPs
Hi, On Tue, Feb 15, 2011 at 01:25:34PM +0200, Tomi Valkeinen wrote: On Tue, Feb 15, 2011 at 10:37:37AM +0200, Tomi Valkeinen wrote: This approach looks clean, but isn't IRQF_SHARED used the other way around. One irq line and multiple handlers? That is the case here, isn't it (on omap3)? One interrupt line (the DSS irq, the same returned both from dsi.pdev and dispc.pdev), and two handlers, one in dispc and one in dsi? Or what do you mean? IMO, for omap3 it would be better to have irq_chip there. Then you can keep e.g. DISPC IRQ disabled until dispc.c calls request_irq(). What happens today if you have IRQ enabled but dispc isn't ready to act on those ? Currently we have a single interrupt handler, which then calls either dispc and/or dsi handler. Dispc and dsi are always ready to handle those. Exactly the kind of thing irq_chip would help you :-) I don't think it would be a good solution if irq_chip would be used only for omap3. Then we'd have totally different solutions for different omap versions. But if irq_chip can be easily used for all omap versions, then perhaps. But the HW is different anyway. On OMAP3 you're connect to a DSS irq demuxer, on OMAP4 you have dedicated lines straight from OMAP's INTC. On omap2 there's no dsi code ran, so dispc is the only one requesting the irq, and thus IRQF_SHARED is extra. In omap4 there are separate irq lines (dsi.pdev and dispc.pdev return different irqs), and so IRQF_SHARED is again extra. But I don't see any harm in IRQF_SHARED even in omap2/4. What if another HW requests the wrong IRQ number and it ends up being your dispc IRQ line ? Are you asking what happens if we have a bug in kernel code? Anything can happen =). But I don't see that as a reason not to use IRQF_SHARED. ok, I have to agree. :-) But you will be allowing for that to happen. If you don't IRQF_SHARED, request_irq() will fail on the second call with -EBUSY I believe. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-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 resend] video: omap24xxcam: Fix compilation
Hi Felipe,
On 02/15/2011 12:37 PM, Felipe Balbi wrote:
On Tue, Feb 15, 2011 at 01:28:19PM +0200, Sakari Ailus wrote:
Thomas Weber wrote:
Add linux/sched.h because of missing declaration of TASK_NORMAL.
This patch fixes the following error:
drivers/media/video/omap24xxcam.c: In function
'omap24xxcam_vbq_complete':
drivers/media/video/omap24xxcam.c:415: error: 'TASK_NORMAL' undeclared
(first use in this function)
drivers/media/video/omap24xxcam.c:415: error: (Each undeclared
identifier is reported only once
drivers/media/video/omap24xxcam.c:415: error: for each function it
appears in.)
Signed-off-by: Thomas Weber we...@corscience.de
Thanks, Thomas!
Are we using the same tree ? I don't see anything related to TASK_* on
Please have a look at definition of macro wake_up. This where those
TASK_* flags are used.
that function on today's mainline, here's a copy of the function:
387 static void omap24xxcam_vbq_complete(struct omap24xxcam_sgdma *sgdma,
388 u32 csr, void *arg)
389 {
390 struct omap24xxcam_device *cam =
391 container_of(sgdma, struct omap24xxcam_device, sgdma);
392 struct omap24xxcam_fh *fh = cam-streaming-private_data;
393 struct videobuf_buffer *vb = (struct videobuf_buffer *)arg;
394 const u32 csr_error = CAMDMA_CSR_MISALIGNED_ERR
395 | CAMDMA_CSR_SUPERVISOR_ERR | CAMDMA_CSR_SECURE_ERR
396 | CAMDMA_CSR_TRANS_ERR | CAMDMA_CSR_DROP;
397 unsigned long flags;
398
399 spin_lock_irqsave(cam-core_enable_disable_lock, flags);
400 if (--cam-sgdma_in_queue == 0)
401 omap24xxcam_core_disable(cam);
402 spin_unlock_irqrestore(cam-core_enable_disable_lock, flags);
403
404 do_gettimeofday(vb-ts);
405 vb-field_count = atomic_add_return(2, fh-field_count);
406 if (csr csr_error) {
407 vb-state = VIDEOBUF_ERROR;
408 if (!atomic_read(fh-cam-in_reset)) {
409 dev_dbg(cam-dev, resetting camera, csr
0x%x\n, csr);
410 omap24xxcam_reset(cam);
411 }
412 } else
413 vb-state = VIDEOBUF_DONE;
414 wake_up(vb-done);
415 }
see that line 415 is where the function ends. My head is
795abaf1e4e188c4171e3cd3dbb11a9fcacaf505
Cheers,
Sylwester Nawrocki
--
To unsubscribe from this list: send the line unsubscribe linux-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 resend] video: omap24xxcam: Fix compilation
hi, On Tue, Feb 15, 2011 at 12:44:42PM +0100, Sylwester Nawrocki wrote: Are we using the same tree ? I don't see anything related to TASK_* on Please have a look at definition of macro wake_up. This where those TASK_* flags are used. $ git grep -e TASK_ drivers/media/video/omap*.[ch] $ ??? -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-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 resend] video: omap24xxcam: Fix compilation
Am 15.02.2011 12:44, schrieb Sylwester Nawrocki:
Hi Felipe,
On 02/15/2011 12:37 PM, Felipe Balbi wrote:
On Tue, Feb 15, 2011 at 01:28:19PM +0200, Sakari Ailus wrote:
Thomas Weber wrote:
Add linux/sched.h because of missing declaration of TASK_NORMAL.
This patch fixes the following error:
drivers/media/video/omap24xxcam.c: In function
'omap24xxcam_vbq_complete':
drivers/media/video/omap24xxcam.c:415: error: 'TASK_NORMAL' undeclared
(first use in this function)
drivers/media/video/omap24xxcam.c:415: error: (Each undeclared
identifier is reported only once
drivers/media/video/omap24xxcam.c:415: error: for each function it
appears in.)
Signed-off-by: Thomas Weber we...@corscience.de
Thanks, Thomas!
Are we using the same tree ? I don't see anything related to TASK_* on
Please have a look at definition of macro wake_up. This where those
TASK_* flags are used.
that function on today's mainline, here's a copy of the function:
387 static void omap24xxcam_vbq_complete(struct omap24xxcam_sgdma *sgdma,
388 u32 csr, void *arg)
389 {
390 struct omap24xxcam_device *cam =
391 container_of(sgdma, struct omap24xxcam_device, sgdma);
392 struct omap24xxcam_fh *fh = cam-streaming-private_data;
393 struct videobuf_buffer *vb = (struct videobuf_buffer *)arg;
394 const u32 csr_error = CAMDMA_CSR_MISALIGNED_ERR
395 | CAMDMA_CSR_SUPERVISOR_ERR | CAMDMA_CSR_SECURE_ERR
396 | CAMDMA_CSR_TRANS_ERR | CAMDMA_CSR_DROP;
397 unsigned long flags;
398
399 spin_lock_irqsave(cam-core_enable_disable_lock, flags);
400 if (--cam-sgdma_in_queue == 0)
401 omap24xxcam_core_disable(cam);
402 spin_unlock_irqrestore(cam-core_enable_disable_lock, flags);
403
404 do_gettimeofday(vb-ts);
405 vb-field_count = atomic_add_return(2, fh-field_count);
406 if (csr csr_error) {
407 vb-state = VIDEOBUF_ERROR;
408 if (!atomic_read(fh-cam-in_reset)) {
409 dev_dbg(cam-dev, resetting camera, csr
0x%x\n, csr);
410 omap24xxcam_reset(cam);
411 }
412 } else
413 vb-state = VIDEOBUF_DONE;
414 wake_up(vb-done);
415 }
see that line 415 is where the function ends. My head is
795abaf1e4e188c4171e3cd3dbb11a9fcacaf505
Cheers,
Sylwester Nawrocki
--
Hello Felipe,
in include/linux/wait.h
#define wake_up(x)__wake_up(x, TASK_NORMAL, 1, NULL)
Regards,
Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-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 resend] video: omap24xxcam: Fix compilation
Felipe Balbi wrote: hi, On Tue, Feb 15, 2011 at 12:44:42PM +0100, Sylwester Nawrocki wrote: Are we using the same tree ? I don't see anything related to TASK_* on Please have a look at definition of macro wake_up. This where those TASK_* flags are used. $ git grep -e TASK_ drivers/media/video/omap*.[ch] $ ??? It's wake_up() on line 414. -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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
hwmod: multi-omap: disabling smartreflex on AM3517
AM3517 doesn't support SmartReflex. However, these HWMODS are defined in omap3_hwmods[]: omap34xx_sr1_hwmod, omap34xx_sr2_hwmod, omap36xx_sr1_hwmod, omap36xx_sr2_hwmod, (similar definition in l4_slaves as well) This leads to crash when booting the kernel on AM3517EVM during _setup(). I see the field .omap_chip being initialized; but not used. If I were to use this - along with cpu_is_omap3517(), I would need to define a new flag e.g. CHIP_IS_AM3517 and add it to almost all devices defined in omap_hwmod_3xxx_data.c. Before going all out on making changes, wanted to check if there is a better way. Has this/similar possibility been considered earlier? Best regards, Sanjeev -- To unsubscribe from this list: send the line unsubscribe linux-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 resend] video: omap24xxcam: Fix compilation
Hi, On Tue, Feb 15, 2011 at 12:50:12PM +0100, Thomas Weber wrote: Hello Felipe, in include/linux/wait.h #define wake_up(x)__wake_up(x, TASK_NORMAL, 1, NULL) aha, now I get it, so shouldn't the real fix be including linux/sched.h on linux/wait.h, I mean, it's linuux/wait.h who uses a symbol defined in linux/sched.h, right ? -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-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 resend] video: omap24xxcam: Fix compilation
Felipe Balbi wrote: Hi, On Tue, Feb 15, 2011 at 12:50:12PM +0100, Thomas Weber wrote: Hello Felipe, in include/linux/wait.h #define wake_up(x)__wake_up(x, TASK_NORMAL, 1, NULL) aha, now I get it, so shouldn't the real fix be including linux/sched.h on linux/wait.h, I mean, it's linuux/wait.h who uses a symbol defined in linux/sched.h, right ? Surprisingly many other files still don't seem to be affected. But this is actually a better solution (to include sched.h in wait.h). -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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: [4/7 v2] usb: otg: OMAP4430: Add phy_suspend function pointer to
Hello.
On 15-02-2011 12:42, Hema HK wrote:
The subject seems incomplete.
From: Kalliguddi, Hemahem...@ti.com
Introduce the .phy_suspend function pointer to twl4030_usb_data structure.
assign the function to it for both sdp board and panda boards.
This will be used by the twl6030-usb transceiver driver.
Signed-off-by: Hema HKhem...@ti.com
Cc: Felipe Balbiba...@ti.com
Cc: Tony Lindgrent...@atomide.com
[...]
Index: linux-2.6/arch/arm/mach-omap2/board-4430sdp.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/board-4430sdp.c
+++ linux-2.6/arch/arm/mach-omap2/board-4430sdp.c
@@ -272,6 +272,7 @@ static struct twl4030_usb_data omap4_usb
.phy_exit = omap4430_phy_exit,
.phy_power = omap4430_phy_power,
.phy_set_clock = omap4430_phy_set_clk,
+ .phy_suspend= omap4430_phy_suspend,
};
static struct omap2_hsmmc_info mmc[] = {
Index: linux-2.6/arch/arm/mach-omap2/board-omap4panda.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/board-omap4panda.c
+++ linux-2.6/arch/arm/mach-omap2/board-omap4panda.c
@@ -153,6 +153,7 @@ static struct twl4030_usb_data omap4_usb
.phy_exit = omap4430_phy_exit,
.phy_power = omap4430_phy_power,
.phy_set_clock = omap4430_phy_set_clk,
+ .phy_suspend= omap4430_phy_suspend,
};
static struct omap2_hsmmc_info mmc[] = {
Index: linux-2.6/arch/arm/plat-omap/include/plat/usb.h
===
--- linux-2.6.orig/arch/arm/plat-omap/include/plat/usb.h
+++ linux-2.6/arch/arm/plat-omap/include/plat/usb.h
@@ -88,6 +88,7 @@ extern int omap4430_phy_power(struct dev
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 omap4430_phy_suspend(struct device *dev, int suspend);
I think this *extern* declaration should be a part of the previous patch.
#endif
Index: linux-2.6/include/linux/i2c/twl.h
===
--- linux-2.6.orig/include/linux/i2c/twl.h
+++ linux-2.6/include/linux/i2c/twl.h
@@ -600,6 +600,8 @@ struct twl4030_usb_data {
int (*phy_power)(struct device *dev, int iD, int on);
/* enable/disable phy clocks */
int (*phy_set_clock)(struct device *dev, int on);
+ /* suspend/resume of phy */
+ int (*phy_suspend)(struct device *dev, int suspend);
};
I'd make the above the only change in this patch, and add all the other
changes into the previous patch (which then I'd change places with that one).
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [5/7 v2] usb: otg: TWL6030: Introduce the twl6030_phy_suspend function.
Hello.
On 15-02-2011 12:42, Hema HK wrote:
From: Kalliguddi, Hemahem...@ti.com
Introduce the twl6030_phy_suspend function and assign to otg.set_suspend
function pointer.
This function is used by the musb-omap2430 platform driver
during suspend/resume.
Signed-off-by: Hema HKhem...@ti.com
Cc: Felipe Balbiba...@ti.com
[...]
Index: linux-2.6/drivers/usb/otg/twl6030-usb.c
===
--- linux-2.6.orig/drivers/usb/otg/twl6030-usb.c
+++ linux-2.6/drivers/usb/otg/twl6030-usb.c
@@ -177,6 +177,20 @@ static void twl6030_phy_shutdown(struct
pdata-phy_power(twl-dev, 0, 0);
}
+static int twl6030_phy_suspend(struct otg_transceiver *x, int suspend)
+{
+ struct twl6030_usb *twl;
+ struct device *dev;
+ struct twl4030_usb_data *pdata;
+
+ twl = xceiv_to_twl(x);
+ dev = twl-dev;
+ pdata = dev-platform_data;
Why not do all the above in the intializers?
+ pdata-phy_suspend(twl-dev, suspend);
+
+ return 0;
+}
+
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap: dmtimer: Enable autoidle
-Original Message- From: ext DebBarma, Tarun Kanti [mailto:tarun.ka...@ti.com] Sent: 15 February, 2011 11:52 To: Kristo Tero (Nokia-MS/Tampere); Hilman, Kevin Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH] omap: dmtimer: Enable autoidle [...] Should this be changed to apply only on that one? I don't know about OMAP4, but I think this should work on OMAP2 at least based on spec. It works on OMAP2 and OMAP4. Ok, on OMAP4 I should have clarified further. AUTOIDLE is present only for millisecond timers: 1,2,10. The reset of the timers do not have this bit. Does it matter if the bit is set on the timers that don't have it or does the HW just ignore it? Or should we enumerate the timers that support it on omap4? For other timers it happens to be SOFTRESET bit. So HW would not ignore. Ok, so this one should only be implemented for omap2/3 or added logic is needed for omap4. -- Tarun Also, please Cc linux-arm-kernel. Thanks, Kevin --- arch/arm/plat-omap/dmtimer.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat- omap/dmtimer.c index 1d706cf..949becc 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -341,6 +341,7 @@ static void omap_dm_timer_reset(struct omap_dm_timer *timer) l = omap_dm_timer_read_reg(timer, OMAP_TIMER_OCP_CFG_REG); l |= 0x02 3; /* Set to smart-idle mode */ l |= 0x2 8; /* Set clock activity to perserve f-clock on idle */ +l |= 0x1 0; /* Set autoidle */ /* * Enable wake-up on OMAP2 CPUs. -- To unsubscribe from this list: send the line unsubscribe 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap: dmtimer: Enable autoidle
[...] Should this be changed to apply only on that one? I don't know about OMAP4, but I think this should work on OMAP2 at least based on spec. It works on OMAP2 and OMAP4. Ok, on OMAP4 I should have clarified further. AUTOIDLE is present only for millisecond timers: 1,2,10. The reset of the timers do not have this bit. Does it matter if the bit is set on the timers that don't have it or does the HW just ignore it? Or should we enumerate the timers that support it on omap4? For other timers it happens to be SOFTRESET bit. So HW would not ignore. Ok, so this one should only be implemented for omap2/3 or added logic is needed for omap4. YES. Also, please Cc linux-arm-kernel. Thanks, Kevin --- arch/arm/plat-omap/dmtimer.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat- omap/dmtimer.c index 1d706cf..949becc 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -341,6 +341,7 @@ static void omap_dm_timer_reset(struct omap_dm_timer *timer) l = omap_dm_timer_read_reg(timer, OMAP_TIMER_OCP_CFG_REG); l |= 0x02 3; /* Set to smart-idle mode */ l |= 0x2 8; /* Set clock activity to perserve f-clock on idle */ + l |= 0x1 0; /* Set autoidle */ /* * Enable wake-up on OMAP2 CPUs. -- To unsubscribe from this list: send the line unsubscribe 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP: DSS2: Common IRQ handler for all OMAPs
Hi, snip Is it okay to have the same irq entry for 2 different hwmods? This requirement comes from OMAP3 where dispc and dsi have a common irq line, where as on OMAP4 dispc and dsi have separate irq lines. Well, no. I explained that in one of my comment about hwmod modification. The hwmod data are reflecting the exact HW capabilities. So, if there is a change in the HW, the hwmod will be different. It is up to the driver to adapt to this change. I guess what Archit wanted to say is, for hw IPs DISPC and DSI, on OMAP3, have a common IRQ line, so could both their hwmod databases have the same IRQ added for them? This would us call, for a common IRQ line shared w/ DISPC and DSI, like mentioned in Tomi's sample code above. OK, thanks for the clarification, actually I missed a little bit the point :-( So in fact the 2 modules share that same IRQ today, and you just want to populate both hwmod with the same input. If this is a real OR between the two IRQ lines, meaning the dispc cannot mask the dsi IRQ or the opposite, then having the same IRQ number in the two different hwmods is a correct representation of the HW. There is a real OR between the 2 irq lines in OMAP3, as there is no DSS_IRQENABLE, but there is a DSS_IRQSTATUS. You can mask one of DISPC or DSI by zeroing all the bits in DISPC_IRQENABLE or DSI_IRQENABLE respectively. But there is no higher level register to mask them. snip Regards, Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hwmod: multi-omap: disabling smartreflex on AM3517
Hi Sanjeev, On 2/15/2011 12:51 PM, Premi, Sanjeev wrote: AM3517 doesn't support SmartReflex. However, these HWMODS are defined in omap3_hwmods[]: omap34xx_sr1_hwmod, omap34xx_sr2_hwmod, omap36xx_sr1_hwmod, omap36xx_sr2_hwmod, (similar definition in l4_slaves as well) This leads to crash when booting the kernel on AM3517EVM during _setup(). I see the field .omap_chip being initialized; but not used. Yes, it is. During the hwmod initialization (omap_hwmod_init), only the hwmods that match the correct chip version are kept. I guess that your problem is that AM3517 is probably seen as a regular 3430 for the moment. If I were to use this - along with cpu_is_omap3517(), I would need to define a new flag e.g. CHIP_IS_AM3517 and add it to almost all devices defined in omap_hwmod_3xxx_data.c. Before going all out on making changes, wanted to check if there is a better way. Has this/similar possibility been considered earlier? Well, this is the best way to do that for my point of view. This .omap_chip field was done for that purpose. During device init, the sr code will do query for the smartreflex hwmod and will failed, thus avoiding to do further initialization. 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
[PATCH 1/6] arm: omap: i2c: fix compile warning
Fix the following compile warning:
arch/arm/plat-omap/i2c.c:120:13: warning:
'omap_pm_set_max_mpu_wakeup_lat_compat' defined but not used
arch/arm/plat-omap/i2c.c:125:38: warning: 'omap_i2c_latency'
defined but not used
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/plat-omap/i2c.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index a4f8003..3341ca4 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -112,6 +112,7 @@ static inline int omap1_i2c_add_bus(int bus_id)
}
+#ifdef CONFIG_ARCH_OMAP2PLUS
/*
* XXX This function is a temporary compatibility wrapper - only
* needed until the I2C driver can be converted to call
@@ -130,7 +131,6 @@ static struct omap_device_pm_latency omap_i2c_latency[] = {
},
};
-#ifdef CONFIG_ARCH_OMAP2PLUS
static inline int omap2_i2c_add_bus(int bus_id)
{
int l;
--
1.7.4.rc2
--
To unsubscribe from this list: send the line unsubscribe 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/6] trivial compile warning fixes
Hi Tony, following are a few compile warning fixes for your consideration. For convenience, patches are also available at [1] [1] git://gitorious.org/usb/usb.git trivial Felipe Balbi (6): arm: omap: i2c: fix compile warning arm: omap1: fix compile warning arm: omap1: fix compile warnings arm: omap1: fix a bunch of section mismatches arm: omap2: irq: fix compile warning: arm: omap2: clksel: fix compile warning arch/arm/mach-omap1/board-ams-delta.c | 14 +++--- arch/arm/mach-omap1/board-fsample.c|2 +- arch/arm/mach-omap1/board-palmte.c | 13 - arch/arm/mach-omap2/clkt_clksel.c |2 +- arch/arm/mach-omap2/irq.c |4 +- arch/arm/plat-omap/i2c.c |2 +- arch/arm/plat-omap/include/plat/fpga.h | 92 7 files changed, 58 insertions(+), 71 deletions(-) -- 1.7.4.rc2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] arm: omap1: fix compile warnings
Fix the following compile warnings:
arch/arm/mach-omap1/board-innovator.c:165:3: warning: initialization
makes integer from pointer without a cast
arch/arm/mach-omap1/board-perseus2.c:305:3: warning: initialization
makes integer from pointer without a cast
arch/arm/mach-omap1/board-fsample.c:338:3: warning: initialization makes
integer from pointer without a cast
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/plat-omap/include/plat/fpga.h | 92
1 files changed, 46 insertions(+), 46 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/fpga.h
b/arch/arm/plat-omap/include/plat/fpga.h
index ae39bcb..bd3c632 100644
--- a/arch/arm/plat-omap/include/plat/fpga.h
+++ b/arch/arm/plat-omap/include/plat/fpga.h
@@ -30,18 +30,18 @@ extern void omap1510_fpga_init_irq(void);
* ---
*/
/* maps in the FPGA registers and the ETHR registers */
-#define H2P2_DBG_FPGA_BASE IOMEM(0xE800) /* VA */
+#define H2P2_DBG_FPGA_BASE 0xE800 /* VA */
#define H2P2_DBG_FPGA_SIZE SZ_4K /* SIZE */
#define H2P2_DBG_FPGA_START0x0400 /* PA */
#define H2P2_DBG_FPGA_ETHR_START (H2P2_DBG_FPGA_START + 0x300)
-#define H2P2_DBG_FPGA_FPGA_REV (H2P2_DBG_FPGA_BASE + 0x10) /* FPGA
Revision */
-#define H2P2_DBG_FPGA_BOARD_REV(H2P2_DBG_FPGA_BASE + 0x12)
/* Board Revision */
-#define H2P2_DBG_FPGA_GPIO (H2P2_DBG_FPGA_BASE + 0x14) /* GPIO
outputs */
-#define H2P2_DBG_FPGA_LEDS (H2P2_DBG_FPGA_BASE + 0x16) /* LEDs
outputs */
-#define H2P2_DBG_FPGA_MISC_INPUTS (H2P2_DBG_FPGA_BASE + 0x18) /* Misc
inputs */
-#define H2P2_DBG_FPGA_LAN_STATUS (H2P2_DBG_FPGA_BASE + 0x1A) /* LAN
Status line */
-#define H2P2_DBG_FPGA_LAN_RESET(H2P2_DBG_FPGA_BASE + 0x1C)
/* LAN Reset line */
+#define H2P2_DBG_FPGA_FPGA_REV IOMEM(H2P2_DBG_FPGA_BASE + 0x10)
/* FPGA Revision */
+#define H2P2_DBG_FPGA_BOARD_REVIOMEM(H2P2_DBG_FPGA_BASE +
0x12)/* Board Revision */
+#define H2P2_DBG_FPGA_GPIO IOMEM(H2P2_DBG_FPGA_BASE + 0x14)
/* GPIO outputs */
+#define H2P2_DBG_FPGA_LEDS IOMEM(H2P2_DBG_FPGA_BASE + 0x16)
/* LEDs outputs */
+#define H2P2_DBG_FPGA_MISC_INPUTS IOMEM(H2P2_DBG_FPGA_BASE + 0x18)
/* Misc inputs */
+#define H2P2_DBG_FPGA_LAN_STATUS IOMEM(H2P2_DBG_FPGA_BASE + 0x1A)
/* LAN Status line */
+#define H2P2_DBG_FPGA_LAN_RESETIOMEM(H2P2_DBG_FPGA_BASE +
0x1C)/* LAN Reset line */
/* NOTE: most boards don't have a static mapping for the FPGA ... */
struct h2p2_dbg_fpga {
@@ -81,55 +81,55 @@ struct h2p2_dbg_fpga {
* OMAP-1510 FPGA
* ---
*/
-#define OMAP1510_FPGA_BASE IOMEM(0xE800) /* VA */
+#define OMAP1510_FPGA_BASE 0xE800 /* VA */
#define OMAP1510_FPGA_SIZE SZ_4K
#define OMAP1510_FPGA_START0x0800 /* PA */
/* Revision */
-#define OMAP1510_FPGA_REV_LOW (OMAP1510_FPGA_BASE + 0x0)
-#define OMAP1510_FPGA_REV_HIGH (OMAP1510_FPGA_BASE + 0x1)
+#define OMAP1510_FPGA_REV_LOW IOMEM(OMAP1510_FPGA_BASE + 0x0)
+#define OMAP1510_FPGA_REV_HIGH IOMEM(OMAP1510_FPGA_BASE + 0x1)
-#define OMAP1510_FPGA_LCD_PANEL_CONTROL(OMAP1510_FPGA_BASE +
0x2)
-#define OMAP1510_FPGA_LED_DIGIT(OMAP1510_FPGA_BASE +
0x3)
-#define INNOVATOR_FPGA_HID_SPI (OMAP1510_FPGA_BASE + 0x4)
-#define OMAP1510_FPGA_POWER(OMAP1510_FPGA_BASE + 0x5)
+#define OMAP1510_FPGA_LCD_PANEL_CONTROL
IOMEM(OMAP1510_FPGA_BASE + 0x2)
+#define OMAP1510_FPGA_LED_DIGIT
IOMEM(OMAP1510_FPGA_BASE + 0x3)
+#define INNOVATOR_FPGA_HID_SPI IOMEM(OMAP1510_FPGA_BASE + 0x4)
+#define OMAP1510_FPGA_POWERIOMEM(OMAP1510_FPGA_BASE + 0x5)
/* Interrupt status */
-#define OMAP1510_FPGA_ISR_LO (OMAP1510_FPGA_BASE + 0x6)
-#define OMAP1510_FPGA_ISR_HI (OMAP1510_FPGA_BASE + 0x7)
+#define OMAP1510_FPGA_ISR_LO IOMEM(OMAP1510_FPGA_BASE + 0x6)
+#define OMAP1510_FPGA_ISR_HI IOMEM(OMAP1510_FPGA_BASE + 0x7)
/* Interrupt mask */
-#define OMAP1510_FPGA_IMR_LO (OMAP1510_FPGA_BASE + 0x8)
-#define OMAP1510_FPGA_IMR_HI (OMAP1510_FPGA_BASE + 0x9)
+#define OMAP1510_FPGA_IMR_LO IOMEM(OMAP1510_FPGA_BASE + 0x8)
+#define OMAP1510_FPGA_IMR_HI IOMEM(OMAP1510_FPGA_BASE + 0x9)
/* Reset registers */
-#define OMAP1510_FPGA_HOST_RESET (OMAP1510_FPGA_BASE + 0xa)
-#define
[PATCH 4/6] arm: omap1: fix a bunch of section mismatches
Fix the following section mismatches:
WARNING: arch/arm/mach-omap1/built-in.o(.data+0x491c): Section mismatch
in reference from the variable fsample_config to the (unknown reference)
.init.data:(unknown)
The variable fsample_config references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the
variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
WARNING: arch/arm/mach-omap1/built-in.o(.data+0x8f0c): Section mismatch
in reference from the variable ams_delta_config to the (unknown
reference) .init.data:(unknown)
The variable ams_delta_config references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the
variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
WARNING: arch/arm/mach-omap1/built-in.o(.data+0x93ac): Section mismatch
in reference from the variable ams_delta_camera_device to the (unknown
reference) .init.data:(unknown)
The variable ams_delta_camera_device references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the
variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
WARNING: vmlinux.o(.data+0x5e94): Section mismatch in reference from the
variable fsample_config to the (unknown reference) .init.data:(unknown)
The variable fsample_config references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the
variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
WARNING: vmlinux.o(.data+0xa484): Section mismatch in reference from the
variable ams_delta_config to the (unknown reference)
.init.data:(unknown)
The variable ams_delta_config references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the
variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
WARNING: vmlinux.o(.data+0xa924): Section mismatch in reference from the
variable ams_delta_camera_device to the (unknown reference)
.init.data:(unknown)
The variable ams_delta_camera_device references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the
variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap1/board-ams-delta.c | 14 +++---
arch/arm/mach-omap1/board-fsample.c |2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 22cc8c8..2f446a2 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -165,7 +165,7 @@ static struct map_desc ams_delta_io_desc[] __initdata = {
}
};
-static struct omap_lcd_config ams_delta_lcd_config __initdata = {
+static struct omap_lcd_config ams_delta_lcd_config = {
.ctrl_name = internal,
};
@@ -208,14 +208,14 @@ static const struct matrix_keymap_data
ams_delta_keymap_data = {
.keymap_size= ARRAY_SIZE(ams_delta_keymap),
};
-static struct omap_kp_platform_data ams_delta_kp_data = {
+static struct omap_kp_platform_data ams_delta_kp_data __initdata = {
.rows = 8,
.cols = 8,
.keymap_data= ams_delta_keymap_data,
.delay = 9,
};
-static struct platform_device ams_delta_kp_device = {
+static struct platform_device ams_delta_kp_device __initdata = {
.name = omap-keypad,
.id = -1,
.dev= {
@@ -225,12 +225,12 @@ static struct platform_device ams_delta_kp_device = {
.resource = ams_delta_kp_resources,
};
-static struct platform_device ams_delta_lcd_device = {
+static struct platform_device ams_delta_lcd_device __initdata = {
.name = lcd_ams_delta,
.id = -1,
};
-static struct platform_device ams_delta_led_device = {
+static struct platform_device ams_delta_led_device __initdata = {
.name = ams-delta-led,
.id = -1
};
@@ -259,7 +259,7 @@ static int ams_delta_camera_power(struct device *dev, int
power)
#define ams_delta_camera_power NULL
#endif
-static struct soc_camera_link __initdata ams_delta_iclink = {
+static struct soc_camera_link ams_delta_iclink __initdata = {
.bus_id = 0,/* OMAP1 SoC camera bus */
.i2c_adapter_id = 1,
.board_info = ams_delta_camera_board_info[0],
@@ -267,7 +267,7 @@ static struct soc_camera_link __initdata ams_delta_iclink =
{
.power =
[PATCH 6/6] arm: omap2: clksel: fix compile warning
Fix the following compile warning:
arch/arm/mach-omap2/clkt_clksel.c: In function '_get_div_and_fieldval':
arch/arm/mach-omap2/clkt_clksel.c:100:35: warning: 'max_clkr' may be
used uninitialized in this function
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/clkt_clksel.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt_clksel.c
b/arch/arm/mach-omap2/clkt_clksel.c
index a781cd6..e25364d 100644
--- a/arch/arm/mach-omap2/clkt_clksel.c
+++ b/arch/arm/mach-omap2/clkt_clksel.c
@@ -97,7 +97,7 @@ static u8 _get_div_and_fieldval(struct clk *src_clk, struct
clk *clk,
u32 *field_val)
{
const struct clksel *clks;
- const struct clksel_rate *clkr, *max_clkr;
+ const struct clksel_rate *clkr, *max_clkr = NULL;
u8 max_div = 0;
clks = _get_clksel_by_parent(clk, src_clk);
--
1.7.4.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP: DSS2: Common IRQ handler for all OMAPs
On 2/15/2011 1:43 PM, Taneja, Archit wrote: Hi, snip Is it okay to have the same irq entry for 2 different hwmods? This requirement comes from OMAP3 where dispc and dsi have a common irq line, where as on OMAP4 dispc and dsi have separate irq lines. Well, no. I explained that in one of my comment about hwmod modification. The hwmod data are reflecting the exact HW capabilities. So, if there is a change in the HW, the hwmod will be different. It is up to the driver to adapt to this change. I guess what Archit wanted to say is, for hw IPs DISPC and DSI, on OMAP3, have a common IRQ line, so could both their hwmod databases have the same IRQ added for them? This would us call, for a common IRQ line shared w/ DISPC and DSI, like mentioned in Tomi's sample code above. OK, thanks for the clarification, actually I missed a little bit the point :-( So in fact the 2 modules share that same IRQ today, and you just want to populate both hwmod with the same input. If this is a real OR between the two IRQ lines, meaning the dispc cannot mask the dsi IRQ or the opposite, then having the same IRQ number in the two different hwmods is a correct representation of the HW. There is a real OR between the 2 irq lines in OMAP3, as there is no DSS_IRQENABLE, but there is a DSS_IRQSTATUS. You can mask one of DISPC or DSI by zeroing all the bits in DISPC_IRQENABLE or DSI_IRQENABLE respectively. But there is no higher level register to mask them. That's perfect then, and it deserves the duplication of this irq number for both hwmods. 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: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
2010/5/11 Eduardo Valentin eduardo.valen...@nokia.com: Here is the version 5 of the change to export OMAP data to userspace (name, revision, id code, production id and die id). Basically, this version is still attempting to create a new file under /proc. It is the /proc/socinfo, which should be used to export bits which are SoC specific (not CPU related, nor machine related). So, differences between previous version are: - merged patch 02/04 with 03/04 to avoid compilation breakages. - simplified the seq_file usage by using the single_open and single_release functions - exported a function to register a seq_operation .show callback - adapted the changes accordingly As usual, comments are welcome. Eduardo, what has happened to this patchset? Now we need something similar for arch/arm/mach-ux500 and I was sort of hoping that this infrastructure would be in place already... wrong I was. Do you want help in picking it up and try to polish it up? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] OMAP: IOMMU: add missing function declaration
From: David Cohen daco...@gmail.com Subject: [PATCH v2] OMAP: IOMMU: add missing function declaration Date: Tue, 15 Feb 2011 13:31:13 +0200 Declaration of exported function 'iopgtable_lookup_entry' is missing from header file. Currently we have a sparse warning as it's not being used externally. Adding its declaration to avoid such warning and allow its usage in future. Signed-off-by: David Cohen daco...@gmail.com --- arch/arm/plat-omap/include/plat/iommu.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) Thanks. Tony, Please put this into your queue. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
IOMMU upper layer is already printing error message. OMAP2+ specific
layer may print error message only for debug purpose.
Signed-off-by: David Cohen daco...@gmail.com
---
arch/arm/mach-omap2/iommu2.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 14ee686..4244a07 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -163,13 +163,13 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj, u32
*ra)
da = iommu_read_reg(obj, MMU_FAULT_AD);
*ra = da;
- dev_err(obj-dev, %s:\tda:%08x , __func__, da);
+ dev_dbg(obj-dev, %s:\tda:%08x , __func__, da);
for (i = 0; i ARRAY_SIZE(err_msg); i++) {
if (stat (1 i))
- printk(%s , err_msg[i]);
+ printk(KERN_DEBUG %s , err_msg[i]);
}
- printk(\n);
+ printk(KERN_DEBUG \n);
iommu_write_reg(obj, stat, MMU_IRQSTATUS);
--
1.7.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] IOMMU fault callback support
Hi, This patch set adds fault callback support to allow IOMMU users to debug or react when a fault happens. IOMMU faults might be very difficult to reproduce and then to figure out the source of the problem. Currently IOMMU driver prints not so useful debug message and does not notice user about such issue. With a fault callback, IOMMU user may debug much more useful information and/or react to go back to a valid state. Br, David --- David Cohen (2): OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg() OMAP: IOMMU: add support to callback during fault handling arch/arm/mach-omap2/iommu2.c| 27 arch/arm/plat-omap/include/plat/iommu.h | 15 ++- arch/arm/plat-omap/iommu.c | 41 --- 3 files changed, 72 insertions(+), 11 deletions(-) -- 1.7.2.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] OMAP: IOMMU: add support to callback during fault handling
Add support to register a callback for IOMMU fault situations. Drivers using
IOMMU module might want to be informed when such errors happen in order to
debug it or react.
Signed-off-by: David Cohen daco...@gmail.com
---
arch/arm/mach-omap2/iommu2.c| 21 +--
arch/arm/plat-omap/include/plat/iommu.h | 15 ++-
arch/arm/plat-omap/iommu.c | 41 ---
3 files changed, 69 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 4244a07..559a066 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -143,10 +143,10 @@ static void omap2_iommu_set_twl(struct iommu *obj, bool
on)
__iommu_set_twl(obj, false);
}
-static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra)
+static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra, u32 *iommu_errs)
{
int i;
- u32 stat, da;
+ u32 stat, da, errs;
const char *err_msg[] = {
tlb miss,
translation fault,
@@ -157,8 +157,10 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj, u32
*ra)
stat = iommu_read_reg(obj, MMU_IRQSTATUS);
stat = MMU_IRQ_MASK;
- if (!stat)
+ if (!stat) {
+ *iommu_errs = 0;
return 0;
+ }
da = iommu_read_reg(obj, MMU_FAULT_AD);
*ra = da;
@@ -171,6 +173,19 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj, u32
*ra)
}
printk(KERN_DEBUG \n);
+ errs = 0;
+ if (stat MMU_IRQ_TLBMISS)
+ errs |= OMAP_IOMMU_ERR_TLB_MISS;
+ if (stat MMU_IRQ_TRANSLATIONFAULT)
+ errs |= OMAP_IOMMU_ERR_TRANS_FAULT;
+ if (stat MMU_IRQ_EMUMISS)
+ errs |= OMAP_IOMMU_ERR_EMU_MISS;
+ if (stat MMU_IRQ_TABLEWALKFAULT)
+ errs |= OMAP_IOMMU_ERR_TBLWALK_FAULT;
+ if (stat MMU_IRQ_MULTIHITFAULT)
+ errs |= OMAP_IOMMU_ERR_MULTIHIT_FAULT;
+ *iommu_errs = errs;
+
iommu_write_reg(obj, stat, MMU_IRQSTATUS);
return stat;
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 19cbb5e..5a2475f 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -31,6 +31,7 @@ struct iommu {
struct clk *clk;
void __iomem*regbase;
struct device *dev;
+ void*fault_cb_priv;
unsigned intrefcount;
struct mutexiommu_lock; /* global for this whole object */
@@ -48,6 +49,7 @@ struct iommu {
struct mutexmmap_lock; /* protect mmap */
int (*isr)(struct iommu *obj);
+ void (*fault_cb)(struct iommu *obj, u32 da, u32 iommu_errs, void *priv);
void *ctx; /* iommu context: registres saved area */
u32 da_start;
@@ -83,7 +85,7 @@ struct iommu_functions {
int (*enable)(struct iommu *obj);
void (*disable)(struct iommu *obj);
void (*set_twl)(struct iommu *obj, bool on);
- u32 (*fault_isr)(struct iommu *obj, u32 *ra);
+ u32 (*fault_isr)(struct iommu *obj, u32 *ra, u32 *iommu_errs);
void (*tlb_read_cr)(struct iommu *obj, struct cr_regs *cr);
void (*tlb_load_cr)(struct iommu *obj, struct cr_regs *cr);
@@ -109,6 +111,13 @@ struct iommu_platform_data {
u32 da_end;
};
+/* IOMMU errors */
+#define OMAP_IOMMU_ERR_TLB_MISS(1 0)
+#define OMAP_IOMMU_ERR_TRANS_FAULT (1 1)
+#define OMAP_IOMMU_ERR_EMU_MISS(1 2)
+#define OMAP_IOMMU_ERR_TBLWALK_FAULT (1 3)
+#define OMAP_IOMMU_ERR_MULTIHIT_FAULT (1 4)
+
#if defined(CONFIG_ARCH_OMAP1)
#error iommu for this processor not implemented yet
#else
@@ -161,6 +170,10 @@ extern size_t iopgtable_clear_entry(struct iommu *obj, u32
iova);
extern int iommu_set_da_range(struct iommu *obj, u32 start, u32 end);
extern struct iommu *iommu_get(const char *name);
extern void iommu_put(struct iommu *obj);
+extern int iommu_set_fault_callback(const char *name,
+ void (*fault_cb)(struct iommu *obj, u32 da,
+u32 errs, void *priv),
+ void *fault_cb_priv);
extern void iommu_save_ctx(struct iommu *obj);
extern void iommu_restore_ctx(struct iommu *obj);
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index b1107c0..7f780ee 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -163,9 +163,9 @@ static u32 get_iopte_attr(struct iotlb_entry *e)
return arch_iommu-get_pte_attr(e);
}
-static u32 iommu_report_fault(struct iommu *obj, u32 *da)
+static u32 iommu_report_fault(struct iommu *obj, u32 *da, u32 *iommu_errs)
{
- return arch_iommu-fault_isr(obj, da);
+ return arch_iommu-fault_isr(obj, da, iommu_errs);
}
static void iotlb_lock_get(struct
Re: [PATCH 0/2] IOMMU fault callback support
A missing prefix in the cover letter's subject. It's: OMAP: IOMMU: Br, David On Tue, Feb 15, 2011 at 3:20 PM, David Cohen daco...@gmail.com wrote: Hi, This patch set adds fault callback support to allow IOMMU users to debug or react when a fault happens. IOMMU faults might be very difficult to reproduce and then to figure out the source of the problem. Currently IOMMU driver prints not so useful debug message and does not notice user about such issue. With a fault callback, IOMMU user may debug much more useful information and/or react to go back to a valid state. Br, David --- David Cohen (2): OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg() OMAP: IOMMU: add support to callback during fault handling arch/arm/mach-omap2/iommu2.c | 27 arch/arm/plat-omap/include/plat/iommu.h | 15 ++- arch/arm/plat-omap/iommu.c | 41 --- 3 files changed, 72 insertions(+), 11 deletions(-) -- 1.7.2.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
Hello.
On 15-02-2011 16:20, David Cohen wrote:
IOMMU upper layer is already printing error message. OMAP2+ specific
layer may print error message only for debug purpose.
Signed-off-by: David Cohendaco...@gmail.com
---
arch/arm/mach-omap2/iommu2.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 14ee686..4244a07 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -163,13 +163,13 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj, u32
*ra)
da = iommu_read_reg(obj, MMU_FAULT_AD);
*ra = da;
- dev_err(obj-dev, %s:\tda:%08x , __func__, da);
+ dev_dbg(obj-dev, %s:\tda:%08x , __func__, da);
Note that dev_dbg() will only print something if either DEBUG or
CONFIG_DYNAMIC_DEBUG are defined...
for (i = 0; i ARRAY_SIZE(err_msg); i++) {
if (stat (1 i))
- printk(%s , err_msg[i]);
+ printk(KERN_DEBUG %s , err_msg[i]);
... unlike printk(KERN_DEBUG...). You probably want to use pr_debug()
instead.
}
- printk(\n);
+ printk(KERN_DEBUG \n);
Here too... Although wait, it should be KERN_CONT instead! Debug levels
are only attributed to the whole lines.
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
On Tue, Feb 15, 2011 at 3:38 PM, Sergei Shtylyov sshtyl...@mvista.com wrote:
Hello.
Hi,
On 15-02-2011 16:20, David Cohen wrote:
IOMMU upper layer is already printing error message. OMAP2+ specific
layer may print error message only for debug purpose.
Signed-off-by: David Cohendaco...@gmail.com
---
arch/arm/mach-omap2/iommu2.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 14ee686..4244a07 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -163,13 +163,13 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj,
u32 *ra)
da = iommu_read_reg(obj, MMU_FAULT_AD);
*ra = da;
- dev_err(obj-dev, %s:\tda:%08x , __func__, da);
+ dev_dbg(obj-dev, %s:\tda:%08x , __func__, da);
Note that dev_dbg() will only print something if either DEBUG or
CONFIG_DYNAMIC_DEBUG are defined...
That's my plan.
for (i = 0; i ARRAY_SIZE(err_msg); i++) {
if (stat (1 i))
- printk(%s , err_msg[i]);
+ printk(KERN_DEBUG %s , err_msg[i]);
... unlike printk(KERN_DEBUG...). You probably want to use pr_debug()
instead.
}
- printk(\n);
+ printk(KERN_DEBUG \n);
Here too... Although wait, it should be KERN_CONT instead! Debug levels
are only attributed to the whole lines.
But your observation is correct. I'll resend it with KERN_CONT instead.
Regards,
David
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP: PM: implement devices wakeup latency constraints APIs
Hi Vishwa,
On Tue, Feb 15, 2011 at 10:35 AM, Vishwanath Sripathy
vishwanath...@ti.com wrote:
-Original Message-
From: jean.pi...@newoldbits.com [mailto:jean.pi...@newoldbits.com]
Sent: Friday, February 11, 2011 12:53 AM
To: khil...@ti.com; p...@pwsan.com; Vibhore Vardhan; Santosh
Shilimkar; Vishwanath BS; rna...@ti.com
Cc: linux-omap@vger.kernel.org; Jean Pihet; Vibhore Vardhan
Subject: [PATCH 2/2] OMAP: PM: implement devices wakeup latency
constraints APIs
From: Jean Pihet j-pi...@ti.com
Implement OMAP PM layer omap_pm_set_max_dev_wakeup_lat API by
creating similar APIs at the omap_device and omap_hwmod levels. The
omap_hwmod level call is the layer with access to the powerdomain
core, so it is the place where the powerdomain is queried to set and
release the constraints.
NOTE: only works for devices which have been converted to use
omap_device/omap_hwmod.
Longer term, we could possibly remove this API from the OMAP PM layer,
and instead directly use the omap_device level API.
Based on Vibhore's original patch , adapted to omap_device and
omap_hwmod frameworks.
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Vibhore Vardhan vvard...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 62 +-
arch/arm/mach-omap2/powerdomain.c | 176
-
arch/arm/mach-omap2/powerdomain.h | 31 +
arch/arm/mach-omap2/powerdomains3xxx_data.c | 60
+
arch/arm/plat-omap/include/plat/omap_device.h | 2 +
arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 +
arch/arm/plat-omap/omap-pm-constraints.c | 101 ++-
arch/arm/plat-omap/omap_device.c | 28
8 files changed, 399 insertions(+), 63 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-
omap2/omap_hwmod.c
index e282e35..0dc096f 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -142,6 +142,7 @@
#include powerdomain.h
#include plat/clock.h
#include plat/omap_hwmod.h
+#include plat/omap_device.h
#include plat/prcm.h
#include cm2xxx_3xxx.h
@@ -2198,10 +2199,69 @@ ohsps_unlock:
}
/**
+ * omap_hwmod_set_max_dev_wakeup_lat - set a device wake-up
constraint
+ * @oh: struct omap_hwmod *
+ * @req_oh: struct omap_hwmod *
Need to explain what this parameters mean.
Ok, will add a description here. Basically oh corresponds to the
device (and so the power domain) to set a constraint on and req_oh is
the constraint requester. oh is used to determine which power domain
to set a constraint on, req_oh is used to record the requester for
later update or removal of a constraint.
+ * @t: wakeup latency constraint (us). -1 removes the existing
constraint
+ *
+ * Query the powerdomain of @oh to set/release the wake-up
constraint
+ *
+ * Returns -EINVAL if @oh or @req_oh have no power domain, or the
return
+ * code from the pwrdm function
(pwrdm_wakeuplat_set/release_constraint)
+ * of the powerdomain assocated with @oh.
+ */
+int omap_hwmod_set_max_dev_wakeup_lat(struct omap_hwmod
*req_oh,
+ struct omap_hwmod *oh, long t)
+{
+ struct device *req_dev;
+ struct platform_device *pdev;
+ struct powerdomain *pwrdm;
+ int ret = 0;
+
+ pwrdm = omap_hwmod_get_pwrdm(oh);
+
+ /* Catch devices with undefined powerdomains */
+ if (!pwrdm) {
+ pr_err(omap_hwmod: Error: could not find parent
+ powerdomain for %s\n, oh-name);
+ return -EINVAL;
+ }
+
+ pdev = (req_oh-od-pdev);
+ if (pdev == NULL) {
+ pr_err(omap_hwmod: Error: pdev not found for oh %s\n,
+ oh-name);
+ return -EINVAL;
+ }
+
+ req_dev = (pdev-dev);
+ if (req_dev == NULL) {
+ pr_err(omap_hwmod: Error: device not found for oh
%s\n,
+ oh-name);
+ return -EINVAL;
+ }
If I understand correctly, req_dev is used for keeping track of different
requests. If so, why can't you directly pass req_dev as an input param
instead of deriving it from pdev.
The layering in the API is as follows: caller - omap-pm -
omap_device - omap_hwmod - powerdomain. The parameters types are
passed accordingly.
Note: I will rename pdev to req_pdev to make it clear that the
parameter relates to the requester.
+
+ /* Call set/release_constraint for the given pwrdm */
+ if (t == -1) {
+ pr_debug(omap_hwmod: remove max device latency
constraint:
+ oh %s, pwrdm %s, req by oh %s\n,
+ oh-name, pwrdm-name, req_oh-name);
+ ret = pwrdm_wakeuplat_release_constraint(pwrdm,
req_dev);
+ } else {
+ pr_debug(omap_hwmod: add max device latency
constraint:
+ oh %s, t = %ld usec, pwrdm %s, req by oh
%s\n,
+ oh-name, t,
Re: [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
On 15-02-2011 16:44, David Cohen wrote:
IOMMU upper layer is already printing error message. OMAP2+ specific
layer may print error message only for debug purpose.
Signed-off-by: David Cohendaco...@gmail.com
---
arch/arm/mach-omap2/iommu2.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 14ee686..4244a07 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -163,13 +163,13 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj,
u32 *ra)
da = iommu_read_reg(obj, MMU_FAULT_AD);
*ra = da;
- dev_err(obj-dev, %s:\tda:%08x , __func__, da);
+ dev_dbg(obj-dev, %s:\tda:%08x , __func__, da);
Note that dev_dbg() will only print something if either DEBUG or
CONFIG_DYNAMIC_DEBUG are defined...
That's my plan.
for (i = 0; i ARRAY_SIZE(err_msg); i++) {
if (stat (1i))
- printk(%s , err_msg[i]);
+ printk(KERN_DEBUG %s , err_msg[i]);
... unlike printk(KERN_DEBUG...). You probably want to use pr_debug()
instead.
}
- printk(\n);
+ printk(KERN_DEBUG \n);
Here too... Although wait, it should be KERN_CONT instead! Debug levels
are only attributed to the whole lines.
But your observation is correct. I'll resend it with KERN_CONT instead.
This won't play out correctly anyway. If DEBUG is not #define'd, the
beginning of line won't be printed but the continuations will. You just can't
do it correctly with dev_dbg(), unless you break the single line into several
ones.
Regards,
David
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] ARM: etm: Allow range selection
On Mon, Feb 14, 2011 at 10:11:12PM -0800, Arve Hjønnevåg wrote:
Trace kernel text segment by default as before, allow tracing of other
ranges by writing a range to /sys/devices/etm/trace_range, or to trace
everything by writing 0 0.
Since you're adding this, I think it might make sense to add a 3rd optional
ctx id field, so that userspace tracing is also possible, especially when
on-chip ETB sizes increase to something more sensible than what they are
these days.
Thanks!
Signed-off-by: Arve Hjønnevåg a...@android.com
---
arch/arm/kernel/etm.c | 49
++---
1 files changed, 46 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kernel/etm.c b/arch/arm/kernel/etm.c
index bc7d8f2..8a1c422 100644
--- a/arch/arm/kernel/etm.c
+++ b/arch/arm/kernel/etm.c
@@ -40,12 +40,17 @@ struct tracectx {
unsigned long flags;
int ncmppairs;
int etm_portsz;
+ unsigned long range_start;
+ unsigned long range_end;
struct device *dev;
struct clk *emu_clk;
struct mutexmutex;
};
-static struct tracectx tracer;
+static struct tracectx tracer = {
+ .range_start = (unsigned long)_stext,
+ .range_end = (unsigned long)_etext,
+};
static inline bool trace_isrunning(struct tracectx *t)
{
@@ -115,8 +120,12 @@ static int trace_start(struct tracectx *t)
return -EFAULT;
}
- etm_setup_address_range(t, 1, (unsigned long)_stext,
- (unsigned long)_etext, 0, 0);
+ if (t-range_start || t-range_end)
+ etm_setup_address_range(t, 1,
+ t-range_start, t-range_end, 0, 0);
+ else
+ etm_writel(t, ETMTE_INCLEXCL, ETMR_TRACEENCTRL);
+
etm_writel(t, 0, ETMR_TRACEENCTRL2);
etm_writel(t, 0, ETMR_TRACESSCTRL);
etm_writel(t, 0x6f, ETMR_TRACEENEVT);
@@ -525,6 +534,35 @@ static ssize_t trace_mode_store(struct kobject *kobj,
static struct kobj_attribute trace_mode_attr =
__ATTR(trace_mode, 0644, trace_mode_show, trace_mode_store);
+static ssize_t trace_range_show(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, %08lx %08lx\n,
+ tracer.range_start, tracer.range_end);
+}
+
+static ssize_t trace_range_store(struct kobject *kobj,
+struct kobj_attribute *attr,
+const char *buf, size_t n)
+{
+ unsigned long range_start, range_end;
+
+ if (sscanf(buf, %lx %lx, range_start, range_end) != 2)
+ return -EINVAL;
+
+ mutex_lock(tracer.mutex);
+ tracer.range_start = range_start;
+ tracer.range_end = range_end;
+ mutex_unlock(tracer.mutex);
+
+ return n;
+}
+
+
+static struct kobj_attribute trace_range_attr =
+ __ATTR(trace_range, 0644, trace_range_show, trace_range_store);
+
static int __init etm_probe(struct amba_device *dev, struct amba_id *id)
{
struct tracectx *t = tracer;
@@ -576,6 +614,10 @@ static int __init etm_probe(struct amba_device *dev,
struct amba_id *id)
if (ret)
dev_dbg(dev-dev, Failed to create trace_mode in sysfs\n);
+ ret = sysfs_create_file(dev-dev.kobj, trace_range_attr.attr);
+ if (ret)
+ dev_dbg(dev-dev, Failed to create trace_range in sysfs\n);
+
dev_dbg(t-dev, ETM AMBA driver initialized.\n);
out:
@@ -605,6 +647,7 @@ static int etm_remove(struct amba_device *dev)
sysfs_remove_file(dev-dev.kobj, trace_running_attr.attr);
sysfs_remove_file(dev-dev.kobj, trace_info_attr.attr);
sysfs_remove_file(dev-dev.kobj, trace_mode_attr.attr);
+ sysfs_remove_file(dev-dev.kobj, trace_range_attr.attr);
return 0;
}
--
1.7.3.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/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
On Tue, 15 Feb 2011 15:44:27 +0200 David Cohen daco...@gmail.com wrote: @@ -163,13 +163,13 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra) da = iommu_read_reg(obj, MMU_FAULT_AD); *ra = da; - dev_err(obj-dev, %s:\tda:%08x , __func__, da); + dev_dbg(obj-dev, %s:\tda:%08x , __func__, da); Note that dev_dbg() will only print something if either DEBUG or CONFIG_DYNAMIC_DEBUG are defined... That's my plan. So it's sure that a developer won't need these error dumps when receiving an error report? I.e. IOMMU upper level errors give enough information to start doing own debugging? Just my 2 cents. -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
On Tue, Feb 15, 2011 at 3:56 PM, Sergei Shtylyov sshtyl...@mvista.com wrote:
On 15-02-2011 16:44, David Cohen wrote:
IOMMU upper layer is already printing error message. OMAP2+ specific
layer may print error message only for debug purpose.
Signed-off-by: David Cohendaco...@gmail.com
---
arch/arm/mach-omap2/iommu2.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 14ee686..4244a07 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -163,13 +163,13 @@ static u32 omap2_iommu_fault_isr(struct iommu
*obj,
u32 *ra)
da = iommu_read_reg(obj, MMU_FAULT_AD);
*ra = da;
- dev_err(obj-dev, %s:\tda:%08x , __func__, da);
+ dev_dbg(obj-dev, %s:\tda:%08x , __func__, da);
Note that dev_dbg() will only print something if either DEBUG or
CONFIG_DYNAMIC_DEBUG are defined...
That's my plan.
for (i = 0; i ARRAY_SIZE(err_msg); i++) {
if (stat (1 i))
- printk(%s , err_msg[i]);
+ printk(KERN_DEBUG %s , err_msg[i]);
... unlike printk(KERN_DEBUG...). You probably want to use pr_debug()
instead.
}
- printk(\n);
+ printk(KERN_DEBUG \n);
Here too... Although wait, it should be KERN_CONT instead! Debug levels
are only attributed to the whole lines.
But your observation is correct. I'll resend it with KERN_CONT instead.
This won't play out correctly anyway. If DEBUG is not #define'd, the
beginning of line won't be printed but the continuations will. You just
can't do it correctly with dev_dbg(), unless you break the single line into
several ones.
Yes, I got this situation. I'm coming with a proper solution on next version.
Br,
David
Regards,
David
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
On Tue, Feb 15, 2011 at 3:59 PM, Jarkko Nikula jhnik...@gmail.com wrote: On Tue, 15 Feb 2011 15:44:27 +0200 David Cohen daco...@gmail.com wrote: @@ -163,13 +163,13 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra) da = iommu_read_reg(obj, MMU_FAULT_AD); *ra = da; - dev_err(obj-dev, %s:\tda:%08x , __func__, da); + dev_dbg(obj-dev, %s:\tda:%08x , __func__, da); Note that dev_dbg() will only print something if either DEBUG or CONFIG_DYNAMIC_DEBUG are defined... That's my plan. So it's sure that a developer won't need these error dumps when receiving an error report? I.e. IOMMU upper level errors give enough information to start doing own debugging? Yes, developers do need this information. But it's a bit useless tell only we've got an iommu fault, due to many places might be causing it. My purpose is to let the debug responsibility to IOMMU users. They have access to the iovmm layer as well and can provide a much more useful information. e.g. OMAP3 ISP has many submodules using IOMMU. With a fault callback, it can dump all the iovm areas and the faulty 'da' too. It might indicate which submodule was responsible for the issue. Of course we can just let this debug messages the way they are and print this redundant information. But IMO it's not necessary. Regards, David Just my 2 cents. -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
On Tue, Feb 15, 2011 at 04:38:32PM +0300, Sergei Shtylyov wrote:
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 14ee686..4244a07 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -163,13 +163,13 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj,
u32 *ra)
da = iommu_read_reg(obj, MMU_FAULT_AD);
*ra = da;
-dev_err(obj-dev, %s:\tda:%08x , __func__, da);
+dev_dbg(obj-dev, %s:\tda:%08x , __func__, da);
Note that dev_dbg() will only print something if either DEBUG or
CONFIG_DYNAMIC_DEBUG are defined...
for (i = 0; i ARRAY_SIZE(err_msg); i++) {
if (stat (1 i))
-printk(%s , err_msg[i]);
+printk(KERN_DEBUG %s , err_msg[i]);
... unlike printk(KERN_DEBUG...). You probably want to use pr_debug()
instead.
No - this isn't starting a new line. pr_cont() here.
}
-printk(\n);
+printk(KERN_DEBUG \n);
Here too... Although wait, it should be KERN_CONT instead! Debug
levels are only attributed to the whole lines.
And pr_cont() here too. If you care about using KERN_CONT which is
just a static marker to allow automated printk level checking easier.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/1] OMAP: IOMMU fault callback support
Hi, v2: Previous patch 1/2 on v1 was dropped. --- v1: This patch set adds fault callback support to allow IOMMU users to debug or react when a fault happens. IOMMU faults might be very difficult to reproduce and then to figure out the source of the problem. Currently IOMMU driver prints not so useful debug message and does not notice user about such issue. With a fault callback, IOMMU user may debug much more useful information and/or react to go back to a valid state. Br, David --- David Cohen (1): OMAP: IOMMU: add support to callback during fault handling arch/arm/mach-omap2/iommu2.c| 21 +-- arch/arm/plat-omap/include/plat/iommu.h | 15 ++- arch/arm/plat-omap/iommu.c | 41 --- 3 files changed, 69 insertions(+), 8 deletions(-) -- 1.7.2.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/1] OMAP: IOMMU: add support to callback during fault handling
Add support to register a callback for IOMMU fault situations. Drivers using
IOMMU module might want to be informed when such errors happen in order to
debug it or react.
Signed-off-by: David Cohen daco...@gmail.com
---
arch/arm/mach-omap2/iommu2.c| 21 +--
arch/arm/plat-omap/include/plat/iommu.h | 15 ++-
arch/arm/plat-omap/iommu.c | 41 ---
3 files changed, 69 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 14ee686..504310d 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -143,10 +143,10 @@ static void omap2_iommu_set_twl(struct iommu *obj, bool
on)
__iommu_set_twl(obj, false);
}
-static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra)
+static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra, u32 *iommu_errs)
{
int i;
- u32 stat, da;
+ u32 stat, da, errs;
const char *err_msg[] = {
tlb miss,
translation fault,
@@ -157,8 +157,10 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj, u32
*ra)
stat = iommu_read_reg(obj, MMU_IRQSTATUS);
stat = MMU_IRQ_MASK;
- if (!stat)
+ if (!stat) {
+ *iommu_errs = 0;
return 0;
+ }
da = iommu_read_reg(obj, MMU_FAULT_AD);
*ra = da;
@@ -171,6 +173,19 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj, u32
*ra)
}
printk(\n);
+ errs = 0;
+ if (stat MMU_IRQ_TLBMISS)
+ errs |= OMAP_IOMMU_ERR_TLB_MISS;
+ if (stat MMU_IRQ_TRANSLATIONFAULT)
+ errs |= OMAP_IOMMU_ERR_TRANS_FAULT;
+ if (stat MMU_IRQ_EMUMISS)
+ errs |= OMAP_IOMMU_ERR_EMU_MISS;
+ if (stat MMU_IRQ_TABLEWALKFAULT)
+ errs |= OMAP_IOMMU_ERR_TBLWALK_FAULT;
+ if (stat MMU_IRQ_MULTIHITFAULT)
+ errs |= OMAP_IOMMU_ERR_MULTIHIT_FAULT;
+ *iommu_errs = errs;
+
iommu_write_reg(obj, stat, MMU_IRQSTATUS);
return stat;
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 19cbb5e..5a2475f 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -31,6 +31,7 @@ struct iommu {
struct clk *clk;
void __iomem*regbase;
struct device *dev;
+ void*fault_cb_priv;
unsigned intrefcount;
struct mutexiommu_lock; /* global for this whole object */
@@ -48,6 +49,7 @@ struct iommu {
struct mutexmmap_lock; /* protect mmap */
int (*isr)(struct iommu *obj);
+ void (*fault_cb)(struct iommu *obj, u32 da, u32 iommu_errs, void *priv);
void *ctx; /* iommu context: registres saved area */
u32 da_start;
@@ -83,7 +85,7 @@ struct iommu_functions {
int (*enable)(struct iommu *obj);
void (*disable)(struct iommu *obj);
void (*set_twl)(struct iommu *obj, bool on);
- u32 (*fault_isr)(struct iommu *obj, u32 *ra);
+ u32 (*fault_isr)(struct iommu *obj, u32 *ra, u32 *iommu_errs);
void (*tlb_read_cr)(struct iommu *obj, struct cr_regs *cr);
void (*tlb_load_cr)(struct iommu *obj, struct cr_regs *cr);
@@ -109,6 +111,13 @@ struct iommu_platform_data {
u32 da_end;
};
+/* IOMMU errors */
+#define OMAP_IOMMU_ERR_TLB_MISS(1 0)
+#define OMAP_IOMMU_ERR_TRANS_FAULT (1 1)
+#define OMAP_IOMMU_ERR_EMU_MISS(1 2)
+#define OMAP_IOMMU_ERR_TBLWALK_FAULT (1 3)
+#define OMAP_IOMMU_ERR_MULTIHIT_FAULT (1 4)
+
#if defined(CONFIG_ARCH_OMAP1)
#error iommu for this processor not implemented yet
#else
@@ -161,6 +170,10 @@ extern size_t iopgtable_clear_entry(struct iommu *obj, u32
iova);
extern int iommu_set_da_range(struct iommu *obj, u32 start, u32 end);
extern struct iommu *iommu_get(const char *name);
extern void iommu_put(struct iommu *obj);
+extern int iommu_set_fault_callback(const char *name,
+ void (*fault_cb)(struct iommu *obj, u32 da,
+u32 errs, void *priv),
+ void *fault_cb_priv);
extern void iommu_save_ctx(struct iommu *obj);
extern void iommu_restore_ctx(struct iommu *obj);
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index b1107c0..7f780ee 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -163,9 +163,9 @@ static u32 get_iopte_attr(struct iotlb_entry *e)
return arch_iommu-get_pte_attr(e);
}
-static u32 iommu_report_fault(struct iommu *obj, u32 *da)
+static u32 iommu_report_fault(struct iommu *obj, u32 *da, u32 *iommu_errs)
{
- return arch_iommu-fault_isr(obj, da);
+ return arch_iommu-fault_isr(obj, da, iommu_errs);
}
static void iotlb_lock_get(struct iommu *obj,
Re: [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
On Tue, 15 Feb 2011 16:08:32 +0200 David Cohen daco...@gmail.com wrote: So it's sure that a developer won't need these error dumps when receiving an error report? I.e. IOMMU upper level errors give enough information to start doing own debugging? Yes, developers do need this information. But it's a bit useless tell only we've got an iommu fault, due to many places might be causing it. My purpose is to let the debug responsibility to IOMMU users. They have access to the iovmm layer as well and can provide a much more useful information. e.g. OMAP3 ISP has many submodules using IOMMU. With a fault callback, it can dump all the iovm areas and the faulty 'da' too. It might indicate which submodule was responsible for the issue. Of course we can just let this debug messages the way they are and print this redundant information. But IMO it's not necessary. Sounds fair enough and if I understood correctly this is not something what end user will hit but more like another developer. In that case the debug messages are the right thing. -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
