[PATCH 0/7] usb: otg: TWL6030: OMAP4430: musb transceiver driver support for OMAP4
This patch series has the support for TWL6030-usb transceiver driver and changes in the musb driver to make it functional with OMAP4430. OMAP4 musb support UTMI and ULPI transceiver interfaces. In UTMI mode, the transceiver functionality is split between the TWL6030 PMIC chip and OMAP4 embedded PHY. The TWL6030 transceiver driver code is under otg folder and internal UTMI PHY specific code changes are defined under mach-omap2 directory and functions are passed through platform_data structure. This patch series is based on V2.6.37-rc4 + [1]+[2]+[3]+[4]. [1] http://www.listware.net/201011/linux-usb/ 65625-patch-resend-v3-usb-musb-do-not-use-dma-for-control-transfers.html [2] http://www.spinics.net/lists/linux-usb/msg37105.html [3] http://permalink.gmane.org/gmane.linux.usb.general/37123 [4] Felipe's musb-reorg patch series. http://gitorious.org/usb/usb/commits/musb-hw Tested musb device and host mode functionality with OMAP4430SDP and OMAP3630 ZOOM3. Cc: Felipe Balbi ba...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: David Brownell dbrown...@users.sourceforge.net Cc: Samuel Ortiz sa...@linux.intel.com --- Hema HK (7): mfd: TWL6030: USBOTG VBUS event generation on charger VBUS events. usb: otg: Adding twl6030-usb transceiver driver for OMAP4430 musb usb: otg: Kconfig: Add Kconfig option for TWL6030 transceiver. mfd: TWL6030: OMAP4: Registering the TWL6030-usb device usb: musb: TWL6030: Selecting TWL6030_USB transceiver for OMAP4 usb: musb: Adding musb support for OMAP4430 arm: OMAP4430: musb: Enable musb device initialization for OMAP4430 arch/arm/mach-omap2/Makefile|1 + arch/arm/mach-omap2/board-4430sdp.c | 15 +- arch/arm/mach-omap2/board-omap4panda.c |9 +- arch/arm/mach-omap2/omap_phy_internal.c | 123 +++ arch/arm/plat-omap/include/plat/usb.h |4 + drivers/mfd/twl-core.c | 44 +++- drivers/mfd/twl6030-irq.c |9 +- drivers/usb/musb/Kconfig|1 + drivers/usb/musb/musb_core.c|5 + drivers/usb/musb/musb_core.h|1 + drivers/usb/musb/musb_gadget.c |1 + drivers/usb/musb/omap2430.c | 85 +- drivers/usb/otg/Kconfig | 11 + drivers/usb/otg/Makefile|1 + drivers/usb/otg/twl6030-usb.c | 527 +++ include/linux/i2c/twl.h |6 + 16 files changed, 824 insertions(+), 19 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] mfd: TWL6030: USBOTG VBUS event generation on
With TWL6030-usb, VBUS SESS_VLD and SESS_END events are not generated
as expected. When these interrupts are enabled, charger VBUS detection
interrupt does not get generated. So USBOTG has to be dependent on charger
VBUS interrupts.
So added one bit for USBOTG and changed the handler to call the
USBOTG handler whenever there is a charger VBUS interrupt.
VBUS SESS_VLD and SESS_END event generation issue is under debug with
HW team. This fix might not be required once after fixing the issue.
Signed-off-by: Balaji TK balaj...@ti.com
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
drivers/mfd/twl6030-irq.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
Index: linux-2.6/drivers/mfd/twl6030-irq.c
===
--- linux-2.6.orig/drivers/mfd/twl6030-irq.c
+++ linux-2.6/drivers/mfd/twl6030-irq.c
@@ -74,7 +74,7 @@ static int twl6030_interrupt_mapping[24]
USBOTG_INTR_OFFSET, /* Bit 16 ID_WKUP */
USBOTG_INTR_OFFSET, /* Bit 17 VBUS_WKUP */
USBOTG_INTR_OFFSET, /* Bit 18 ID */
- USBOTG_INTR_OFFSET, /* Bit 19 VBUS*/
+ USB_PRES_INTR_OFFSET, /* Bit 19 VBUS*/
CHARGER_INTR_OFFSET,/* Bit 20 CHRG_CTRL */
CHARGER_INTR_OFFSET,/* Bit 21 EXT_CHRG*/
CHARGER_INTR_OFFSET,/* Bit 22 INT_CHRG*/
@@ -128,6 +128,13 @@ static int twl6030_irq_thread(void *data
sts.bytes[3] = 0; /* Only 24 bits are valid*/
+ /*
+* Since VBUS status bit is not reliable for VBUS disconnect
+* use CHARGER VBUS detection status bit instead.
+*/
+ if (sts.bytes[2] 0x10)
+ sts.bytes[2] |= 0x08;
+
for (i = 0; sts.int_sts; sts.int_sts = 1, i++) {
local_irq_disable();
if (sts.int_sts 0x1) {
--
To unsubscribe from this list: send the line unsubscribe 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/7] usb: otg: Adding twl6030-usb transceiver driver for
Adding the twl6030-usb transceiver support for OMAP4 musb driver.
OMAP4 supports 2 types of transceiver interface.
1. UTMI: The PHY is embedded within OMAP4. The transceiver functionality
is split between the twl6030 PMIC chip and OMAP4430. The VBUS, ID pin
sensing and OTG SRP generation part is integrated in TWL6030 and UTMI PHY
functionality is embedded within the OMAP4430.
There is no direct interactions between the MUSB controller and TWL6030
chip to communicate the session-valid, session-end and ID-GND events.
It has to be done through a software by setting/resetting bits in
one of the control module register of OMAP4430 which in turn toggles
the appropriate signals to MUSB controller.
The internal transceiver has functional clocks and
powerdown bits to powerdown the PHY for power saving.
Since there is no option available for having 2 transceiver drivers
for one USB controller, internal PHY specific APIs are passed through
plaform_data function pointers to use in the twl6030-usb transceiver
driver.
2. ULPI interface is provided for off-chip transceivers.
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: David Brownell dbrown...@users.sourceforge.net
---
arch/arm/mach-omap2/omap_phy_internal.c | 133
arch/arm/plat-omap/include/plat/usb.h |4
drivers/usb/otg/Makefile|1
drivers/usb/otg/twl6030-usb.c | 514
4 files changed, 652 insertions(+)
Index: linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
===
--- /dev/null
+++ linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
@@ -0,0 +1,150 @@
+/*
+ * This file configures the internal USB PHY in OMAP4430. Used
+ * with TWL6030 transceiver and MUSB on OMAP4430.
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ *Author: Hema HK hem...@ti.com
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ */
+
+#include linux/types.h
+#include linux/delay.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/err.h
+#include linux/usb.h
+
+#include plat/usb.h
+
+/* OMAP control module register for UTMI PHY */
+#define CONTROL_DEV_CONF 0x300
+#define PHY_PD 0x1
+
+#define USBOTGHS_CONTROL 0x33c
+#defineAVALID BIT(0)
+#defineBVALID BIT(1)
+#defineVBUSVALID BIT(2)
+#defineSESSEND BIT(3)
+#defineIDDIG BIT(4)
+
+static struct clk *phyclk, *clk48m, *clk32k;
+static void __iomem *ctrl_base;
+
+int omap4430_phy_init(struct device *dev)
+{
+ ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
+ if (!ctrl_base) {
+ dev_err(dev, control module ioremap failed\n);
+ return -ENOMEM;
+ }
+ /* Power down the phy */
+ __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
+ phyclk = clk_get(dev, ocp2scp_usb_phy_ick);
+
+ if (IS_ERR(phyclk)) {
+ dev_err(dev, cannot clk_get ocp2scp_usb_phy_ick\n);
+ iounmap(ctrl_base);
+ return PTR_ERR(phyclk);
+ }
+
+ clk48m = clk_get(dev, ocp2scp_usb_phy_phy_48m);
+ if (IS_ERR(clk48m)) {
+ dev_err(dev, cannot clk_get ocp2scp_usb_phy_phy_48m\n);
+ clk_put(phyclk);
+ iounmap(ctrl_base);
+ return PTR_ERR(clk48m);
+ }
+
+ clk32k = clk_get(dev, usb_phy_cm_clk32k);
+ if (IS_ERR(clk32k)) {
+ dev_err(dev, cannot clk_get usb_phy_cm_clk32k\n);
+ clk_put(phyclk);
+ clk_put(clk48m);
+ iounmap(ctrl_base);
+ return PTR_ERR(clk32k);
+ }
+ return 0;
+}
+
+int omap4430_phy_set_clk(struct device *dev, int on)
+{
+ static int state;
+
+ if (on !state) {
+ /* Enable the phy clocks */
+ clk_enable(phyclk);
+ clk_enable(clk48m);
+ clk_enable(clk32k);
+ state = 1;
+ } else if (state) {
+ /* Disable the phy clocks */
+ clk_disable(phyclk);
+
[PATCH 3/7] usb: otg: Kconfig: Add Kconfig option for TWL6030 transceiver.
Added the TWL6030-usb transceiver option in the Kconfig Signed-off-by: Hema HK hem...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: David Brownell dbrown...@users.sourceforge.net --- drivers/usb/otg/Kconfig | 12 1 file changed, 12 insertions(+) Index: linux-2.6/drivers/usb/otg/Kconfig === --- linux-2.6.orig/drivers/usb/otg/Kconfig +++ linux-2.6/drivers/usb/otg/Kconfig @@ -59,6 +59,18 @@ config TWL4030_USB This transceiver supports high and full speed devices plus, in host mode, low speed. +config TWL6030_USB + tristate TWL6030 USB Transceiver Driver + depends on TWL4030_CORE + select USB_OTG_UTILS + help + Enable this to support the USB OTG transceiver on TWL6030 + family chips. This TWL6030 transceiver has the VBUS and ID GND + and OTG SRP events capabilities. For all other transceiver functionality + UTMI PHY is embedded in OMAP4430.The internal PHY configurations APIs + are hooked to this driver through platform_data structure. + The definition of internal PHY APIs are in the mach-omap2 layer. + config NOP_USB_XCEIV tristate NOP USB Transceiver Driver select USB_OTG_UTILS -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] mfd: TWL6030: OMAP4: Registering the TWL6030-usb device
Registering the twl6030-usb transceiver device as a child to twl6030 core.
Removed the NOP transceiver init call from board file.
Populated twl4030_usb_data platform data structure with the function
pointers for OMAP4430 internal PHY operation to be used twl630-usb driver.
Signed-off-by: Hema HK hem...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Felipe Balbi ba...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c|9 +-
arch/arm/mach-omap2/board-omap4panda.c |7 +
drivers/mfd/twl-core.c | 44 +
include/linux/i2c/twl.h|6
4 files changed, 59 insertions(+), 7 deletions(-)
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
@@ -231,6 +231,13 @@ static struct omap_musb_board_data musb_
.power = 100,
};
+static struct twl4030_usb_data omap4_usbphy_data = {
+ .phy_init = omap4430_phy_init,
+ .phy_exit = omap4430_phy_exit,
+ .phy_power = omap4430_phy_power,
+ .phy_set_clock = omap4430_phy_set_clk,
+};
+
static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
@@ -450,6 +457,7 @@ static struct twl4030_platform_data sdp4
.vaux1 = sdp4430_vaux1,
.vaux2 = sdp4430_vaux2,
.vaux3 = sdp4430_vaux3,
+ .usb= omap4_usbphy_data
};
static struct i2c_board_info __initdata sdp4430_i2c_boardinfo[] = {
@@ -514,8 +522,6 @@ static void __init omap_4430sdp_init(voi
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
omap_serial_init();
omap4_twl6030_hsmmc_init(mmc);
- /* OMAP4 SDP uses internal transceiver so register nop transceiver */
- usb_nop_xceiv_register();
/* FIXME: allow multi-omap to boot until musb is updated for omap4 */
if (!cpu_is_omap44xx())
usb_musb_init(musb_board_data);
Index: linux-2.6/drivers/mfd/twl-core.c
===
--- linux-2.6.orig/drivers/mfd/twl-core.c
+++ linux-2.6/drivers/mfd/twl-core.c
@@ -95,7 +95,8 @@
#define twl_has_rtc() false
#endif
-#if defined(CONFIG_TWL4030_USB) || defined(CONFIG_TWL4030_USB_MODULE)
+#if defined(CONFIG_TWL4030_USB) || defined(CONFIG_TWL4030_USB_MODULE) ||\
+ defined(CONFIG_TWL6030_USB) || defined(CONFIG_TWL6030_USB_MODULE)
#define twl_has_usb() true
#else
#define twl_has_usb() false
@@ -682,6 +683,43 @@ add_children(struct twl4030_platform_dat
usb3v1.dev = child;
}
}
+ if (twl_has_usb() pdata-usb twl_class_is_6030()) {
+
+ static struct regulator_consumer_supply usb3v3 = {
+ .supply = vusb,
+ };
+
+ if (twl_has_regulator()) {
+ /* this is a template that gets copied */
+ struct regulator_init_data usb_fixed = {
+ .constraints.valid_modes_mask =
+ REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .constraints.valid_ops_mask =
+ REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ };
+
+ child = add_regulator_linked(TWL6030_REG_VUSB,
+ usb_fixed, usb3v3, 1);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+ }
+
+ child = add_child(0, twl6030_usb,
+ pdata-usb, sizeof(*pdata-usb),
+ true,
+ /* irq1 = VBUS_PRES, irq0 = USB ID*/
+ pdata-irq_base + USBOTG_INTR_OFFSET,
+ pdata-irq_base + USB_PRES_INTR_OFFSET);
+
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+ /* we need to connect regulators to this transceiver */
+ if (twl_has_regulator() child)
+ usb3v3.dev = child;
+
+ }
if (twl_has_watchdog()) {
child = add_child(0, twl4030_wdt, NULL, 0, false, 0, 0);
@@ -815,10 +853,6 @@ add_children(struct twl4030_platform_dat
if (IS_ERR(child))
return PTR_ERR(child);
- child = add_regulator(TWL6030_REG_VUSB, pdata-vusb);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
child = add_regulator(TWL6030_REG_VAUX1_6030, pdata-vaux1);
if (IS_ERR(child))
[PATCH 6/7] usb: musb: Adding musb support for OMAP4430
OMAP4430 supports UTMI and ULPI types of transceiver interface.
In UTMI mode: The PHY is embedded within OMAP4430. The transceiver functionality
is split between the twl6030 PMIC chip and OMAP4430. The VBUS, ID pin
sensing and OTG SRP generation part is integrated in TWL6030 and UTMI PHY
functionality is embedded within the OMAP4430.
There is no direct interactions between the MUSB controller and TWL6030
chip to communicate the session-valid, session-end and ID-GND events.
It has to be done through a software by setting/resetting bits in
one of the control module register of OMAP4430 which in turn toggles
the appropriate signals to MUSB controller.
musb driver is register for atomic notifications from the transceiver
driver to get the event notifications for connect/disconnect and ID-GND.
Based on these events call the transceiver init/shutdown function to
configure the transceiver to toggle the VBUS valid, session end and ID_GND
signals to musb.
For ID_GND event notifications, toggle the ID_GND signal and then wait for
musb to be configured as A device, and then call the transceiver function
to set the VBUS.
using otg_get_last_event function to get the missed transceiver events
if the cable or device is connected before registration(musb driver load).
In OTG mode and musb as a host, When the Micro A connector used, VBUS is turned
on
and session bit set. When the device is connected, enumeration goes through.
When the device disconnected from the other end of the connector(ID is still
grounded),
link will detect the disconnect and end the session. When the device is
connected back,
there are no events generated in the TWL6030-usb, and link is already down.So
the device is
not detected.Removed the session bit disable code which will recognize the
connect of the device..
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi ba...@ti.com
---
drivers/usb/musb/musb_core.c |5 ++
drivers/usb/musb/musb_core.h |1
drivers/usb/musb/musb_gadget.c |1
drivers/usb/musb/omap2430.c| 92 -
4 files changed, 88 insertions(+), 11 deletions(-)
Index: linux-2.6/drivers/usb/musb/musb_core.c
===
--- linux-2.6.orig/drivers/usb/musb/musb_core.c
+++ linux-2.6/drivers/usb/musb/musb_core.c
@@ -2116,6 +2116,11 @@ bad_config:
MUSB_DEVCTL_BDEVICE
? 'B' : 'A'));
+ /*
+* Host only mode, check whether the device is already
+* connected
+*/
+ otg_get_last_event(musb-xceiv);
} else /* peripheral is enabled */ {
MUSB_DEV_MODE(musb);
musb-xceiv-default_a = 0;
Index: linux-2.6/drivers/usb/musb/musb_core.h
===
--- linux-2.6.orig/drivers/usb/musb/musb_core.h
+++ linux-2.6/drivers/usb/musb/musb_core.h
@@ -411,6 +411,7 @@ struct musb {
struct timer_list otg_timer;
#endif
+ struct notifier_block nb;
/* called with IRQs blocked; ON/nonzero implies starting a session,
* and waiting at least a_wait_vrise_tmout.
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
@@ -1809,6 +1809,7 @@ int usb_gadget_probe_driver(struct usb_g
hcd-self.uses_pio_for_control = 1;
}
}
+ otg_get_last_event(musb-xceiv);
}
return retval;
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
@@ -57,12 +57,8 @@ static void musb_do_idle(unsigned long _
spin_lock_irqsave(musb-lock, flags);
- devctl = musb_readb(musb-mregs, MUSB_DEVCTL);
-
switch (musb-xceiv-state) {
case OTG_STATE_A_WAIT_BCON:
- devctl = ~MUSB_DEVCTL_SESSION;
- musb_writeb(musb-mregs, MUSB_DEVCTL, devctl);
devctl = musb_readb(musb-mregs, MUSB_DEVCTL);
if (devctl MUSB_DEVCTL_BDEVICE) {
@@ -142,6 +138,7 @@ static void omap2430_try_idle(struct mus
static void omap2430_set_vbus(struct musb *musb, int is_on)
{
u8 devctl;
+ long int timeout = 0x;
/* HDRC controls CPEN, but beware current surges during device
* connect. They can trigger transient overcurrent conditions
* that must be ignored.
@@ -150,12 +147,26 @@ static void omap2430_set_vbus(struct mus
devctl = musb_readb(musb-mregs, MUSB_DEVCTL);
if (is_on) {
- musb-is_active = 1;
- musb-xceiv-default_a = 1;
-
[PATCH v2] OMAP2+: disable idle early in the suspend sequence
From: Jean Pihet j-pi...@ti.com
Some bad interaction between the idle and the suspend paths has been
noticed: the idle code is called during the suspend enter and exit
sequences. This could cause corruption or lock-up of resources.
The solution is to move the calls to disable_hlt at the very beginning
of the suspend sequence (ex. in omap3_pm_begin instead of
omap3_pm_prepare), and the call to enable_hlt at the very end of
the suspend sequence (ex. in omap3_pm_end instead of omap3_pm_finish).
Tested with RET and OFF on Beagle and OMAP3EVM.
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
v1: support for OMAP3 only.
Tested on board.
v2: Added support for OMAP2 and OMAP4.
Compile tested only for OMAP2 and OMAP4.
Tested on board for OMAP3.
arch/arm/mach-omap2/pm24xx.c | 16 ++--
arch/arm/mach-omap2/pm34xx.c |4 ++--
arch/arm/mach-omap2/pm44xx.c |4 ++--
3 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index c85923e..3820179 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -286,8 +286,6 @@ out:
static int omap2_pm_prepare(void)
{
- /* We cannot sleep in idle until we have resumed */
- disable_hlt();
return 0;
}
@@ -330,10 +328,24 @@ static int omap2_pm_enter(suspend_state_t state)
static void omap2_pm_finish(void)
{
+}
+
+static int omap2_pm_begin(suspend_state_t state)
+{
+ /* We cannot sleep in idle until we have resumed */
+ disable_hlt();
+ return 0;
+}
+
+static void omap2_pm_end(void)
+{
enable_hlt();
+ return;
}
static struct platform_suspend_ops omap_pm_ops = {
+ .begin = omap2_pm_begin,
+ .end= omap2_pm_end,
.prepare= omap2_pm_prepare,
.enter = omap2_pm_enter,
.finish = omap2_pm_finish,
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 0ec8a04..ec80d38 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -518,7 +518,6 @@ static suspend_state_t suspend_state;
static int omap3_pm_prepare(void)
{
- disable_hlt();
return 0;
}
@@ -586,12 +585,12 @@ static int omap3_pm_enter(suspend_state_t unused)
static void omap3_pm_finish(void)
{
- enable_hlt();
}
/* Hooks to enable / disable UART interrupts during suspend */
static int omap3_pm_begin(suspend_state_t state)
{
+ disable_hlt();
suspend_state = state;
omap_uart_enable_irqs(0);
return 0;
@@ -601,6 +600,7 @@ static void omap3_pm_end(void)
{
suspend_state = PM_SUSPEND_ON;
omap_uart_enable_irqs(1);
+ enable_hlt();
return;
}
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 54544b4..f4c4fab 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -33,7 +33,6 @@ static LIST_HEAD(pwrst_list);
#ifdef CONFIG_SUSPEND
static int omap4_pm_prepare(void)
{
- disable_hlt();
return 0;
}
@@ -61,17 +60,18 @@ static int omap4_pm_enter(suspend_state_t suspend_state)
static void omap4_pm_finish(void)
{
- enable_hlt();
return;
}
static int omap4_pm_begin(suspend_state_t state)
{
+ disable_hlt();
return 0;
}
static void omap4_pm_end(void)
{
+ enable_hlt();
return;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: disable idle early in the suspend sequence
On Wed, Dec 8, 2010 at 2:11 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Hi Jean, Jean Pihet jean.pi...@newoldbits.com writes: Some bad interaction between the idle and the suspend paths has been noticed: the idle code is called during the suspend enter and exit sequences. This could cause corruption or lock-up of resources. The solution is to move the call to disable_hlt at the very beginning of the suspend sequence (in omap3_pm_begin instead of omap3_pm_prepare), and the call to enable_hlt at the very end of the suspend sequence (in omap3_pm_end instead of omap3_pm_finish). Tested with RET and OFF on Beagle and OMAP3EVM. Signed-off-by: Jean Pihet j-pi...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/pm34xx.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Can you update this to do similar for OMAP2 and OMAP4? Done! It needs some testing on OMAP2 and OMAP4 boards since it has been compile tested only. Thanks, Kevin Thanks, Jean -- To unsubscribe from this list: send the line unsubscribe 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/7 v2] OMAP: McSPI: Hwmod adaptation + runtime conversion
On Wed, Dec 1, 2010 at 7:31 PM, Govindraj.R govindraj.r...@ti.com wrote: Changes invloves: 1) Addition of hwmod data for omap2/3/4. 1) McSPI driver hwmod adaptation with cleanup of base address macros and using omap-device API's. 2) Runtime Conversion of McSPI driver Any comments or feedback on this patch series? If no comments I hope patch series can be merged through LO tree with a ack from Grant on patch 6/6 and patch 7/7. Benoit, I may need you comments or ack on patch 1/[1-4] Patch 1/5 will be posted out separately as per Paul's comments: http://ns3.spinics.net/lists/linux-omap/msg41219.html -- Thanks, Govindraj.R Changes from v1: --- 1) Fixing patch 5/5 comments for hwmod+runtime Split the patch 5/5 to hwmod adaptation and then runtime conversion http://www.mail-archive.com/linux-omap@vger.kernel.org/msg33387.html Testing Updates: Was tested using data transfer test module available at: http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=blob;f=mcspi/test_code/ utils/mcspi_modules/omap_mcspi_datatest.c; h=e42ec10c5c844abdde6a7175a268b379fbbdb655; hb=5d9a755d50e58de861c5e8991f2f607bc49b5dc3 System wide suspend and ret/off counts observation, ensured that no behavioral difference with and without this patch series. Benoit Cousson (1): OMAP4: hwmod data: Add McSPI Charulatha V (5): OMAP2420: hwmod data: Add McSPI OMAP2430: hwmod data: Add McSPI OMAP3: hwmod data: Add McSPI OMAP3: clocks: Update clock domain name for mcspi fck OMAP: devices: Modify McSPI device to adapt to hwmod framework Govindraj.R (1): OMAP: runtime: McSPI driver runtime conversion arch/arm/mach-omap2/clock3xxx_data.c | 4 + arch/arm/mach-omap2/devices.c | 189 --- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 156 arch/arm/mach-omap2/omap_hwmod_2430_data.c | 219 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 280 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 267 ++ arch/arm/plat-omap/include/plat/mcspi.h | 11 + drivers/spi/omap2_mcspi.c | 225 +++--- 8 files changed, 1051 insertions(+), 300 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 -- To unsubscribe from this list: send the line unsubscribe 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 01/11] OMAP4: PRCM: add OMAP4-specific accessor/mutatorfunctions
Paul, -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Wednesday, December 08, 2010 11:49 AM To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Cc: Rajendra Nayak; Santosh Shilimkar; Benoīt Cousson Subject: [PATCH 01/11] OMAP4: PRCM: add OMAP4-specific accessor/mutatorfunctions In some ways, the OMAP4 PRCM register layout is quite different than the OMAP2/3 PRCM register layout. For example, on OMAP2/3, from a register layout point of view, all CM instances were located in the CM subsystem, and all PRM instances were located in the PRM subsystem. OMAP4 changes this. Now, for example, some CM instances, such as WKUP_CM and EMU_CM, are located in the system PRM subsystem. And a local PRCM exists for the MPU - this PRCM combines registers that would normally appear in both CM and PRM instances, but uses its own register layout which matches neither the OMAP2/3 PRCM layout nor the OMAP4 PRCM layout. To try to deal with this, introduce some new functions, omap4_cminst* and omap4_prminst*. The former is to be used when writing to a CM instance register (no matter what subsystem or hardware module it exists in), and the latter, similarly, with PRM instance registers. To determine which PRCM partition to write to, the functions take a PRCM instance ID argument. Subsequent patches add these partition IDs to the OMAP4 powerdomain and clockdomain definitions. Thanks a lot for this cleanup. As far as I can see, there's really no good way to handle these types of register access inconsistencies. This patch seemed like the least bad approach. Moving forward, the long-term goal is to remove all direct PRCM register access from the PM code. PRCM register access should go through layers such as the powerdomain and clockdomain code that can hide the details of how to interact with the specific hardware variant. One more possible road block of removing the direct register access from PM code is DEVICE PRM module. Even with this clean-up for DEVCIE PRM related registers. I guess we still need to use the lowest level APIs. While here, rename cm4xxx.c to cm44xx.c to match the naming convention of the other OMAP4 PRCM files. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Benoīt Cousson b-cous...@ti.com Cc: Rajendra Nayak rna...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/Makefile |4 + arch/arm/mach-omap2/cm1_44xx.h |5 + arch/arm/mach-omap2/cm2_44xx.h |6 ++ arch/arm/mach-omap2/cm44xx.c | 52 ++ arch/arm/mach-omap2/cm4xxx.c | 62 - arch/arm/mach-omap2/cminst44xx.c | 118 arch/arm/mach-omap2/prcm.c | 26 --- arch/arm/mach-omap2/prcm44xx.h | 42 +++ arch/arm/mach-omap2/prcm_mpu44xx.c | 45 arch/arm/mach-omap2/prcm_mpu44xx.h |8 ++ arch/arm/mach-omap2/prm44xx.c | 65 ++ arch/arm/mach-omap2/prm44xx.h |6 ++ arch/arm/mach-omap2/prminst44xx.c | 74 arch/arm/mach-omap2/prminst44xx.h | 25 +++ arch/arm/plat-omap/include/plat/prcm.h |7 +- 15 files changed, 454 insertions(+), 91 deletions(-) create mode 100644 arch/arm/mach-omap2/cm44xx.c delete mode 100644 arch/arm/mach-omap2/cm4xxx.c create mode 100644 arch/arm/mach-omap2/cminst44xx.c create mode 100644 arch/arm/mach-omap2/prcm44xx.h create mode 100644 arch/arm/mach-omap2/prcm_mpu44xx.c create mode 100644 arch/arm/mach-omap2/prminst44xx.c create mode 100644 arch/arm/mach-omap2/prminst44xx.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] usb: otg: Adding twl6030-usb transceiver driver for
On Wed, Dec 08, 2010 at 09:31:15PM +0530, Hema HK wrote:
Adding the twl6030-usb transceiver support for OMAP4 musb driver.
OMAP4 supports 2 types of transceiver interface.
1. UTMI: The PHY is embedded within OMAP4. The transceiver functionality
is split between the twl6030 PMIC chip and OMAP4430. The VBUS, ID pin
sensing and OTG SRP generation part is integrated in TWL6030 and UTMI PHY
functionality is embedded within the OMAP4430.
There is no direct interactions between the MUSB controller and TWL6030
chip to communicate the session-valid, session-end and ID-GND events.
It has to be done through a software by setting/resetting bits in
one of the control module register of OMAP4430 which in turn toggles
the appropriate signals to MUSB controller.
The internal transceiver has functional clocks and
powerdown bits to powerdown the PHY for power saving.
Since there is no option available for having 2 transceiver drivers
for one USB controller, internal PHY specific APIs are passed through
plaform_data function pointers to use in the twl6030-usb transceiver
driver.
2. ULPI interface is provided for off-chip transceivers.
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: David Brownell dbrown...@users.sourceforge.net
---
arch/arm/mach-omap2/omap_phy_internal.c | 133
arch/arm/plat-omap/include/plat/usb.h |4
drivers/usb/otg/Makefile|1
drivers/usb/otg/twl6030-usb.c | 514
4 files changed, 652 insertions(+)
Index: linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
===
--- /dev/null
+++ linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
@@ -0,0 +1,148 @@
+/*
+ * This file configures the internal USB PHY in OMAP4430. Used
+ * with TWL6030 transceiver and MUSB on OMAP4430.
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ *Author: Hema HK hem...@ti.com
^^ you need a space after *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ */
+
+#include linux/types.h
+#include linux/errno.h
+#include linux/delay.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/err.h
+#include linux/usb.h
+
+#include plat/usb.h
+
+/* OMAP control module register for UTMI PHY */
+#define CONTROL_DEV_CONF 0x300
+#define PHY_PD 0x1
+
+#define USBOTGHS_CONTROL 0x33c
+#defineAVALID BIT(0)
+#defineBVALID BIT(1)
+#defineVBUSVALID BIT(2)
+#defineSESSEND BIT(3)
+#defineIDDIG BIT(4)
+
+static struct clk *phyclk, *clk48m, *clk32k;
+static void __iomem *ctrl_base;
+
+int omap4430_phy_init(struct device *dev)
+{
+ ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
+ if (!ctrl_base) {
+ dev_err(dev, control module ioremap failed\n);
+ return -ENOMEM;
+ }
+ /* Power down the phy */
+ __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
+ phyclk = clk_get(dev, ocp2scp_usb_phy_ick);
+
+ if (IS_ERR(phyclk)) {
+ dev_err(dev, cannot clk_get ocp2scp_usb_phy_ick\n);
+ iounmap(ctrl_base);
+ return PTR_ERR(phyclk);
+ }
+
+ clk48m = clk_get(dev, ocp2scp_usb_phy_phy_48m);
+ if (IS_ERR(clk48m)) {
+ dev_err(dev, cannot clk_get ocp2scp_usb_phy_phy_48m\n);
+ clk_put(phyclk);
+ iounmap(ctrl_base);
+ return PTR_ERR(clk48m);
+ }
+
+ clk32k = clk_get(dev, usb_phy_cm_clk32k);
+ if (IS_ERR(clk32k)) {
+ dev_err(dev, cannot clk_get usb_phy_cm_clk32k\n);
+ clk_put(phyclk);
+ clk_put(clk48m);
+ iounmap(ctrl_base);
+ return PTR_ERR(clk32k);
+ }
+ return 0;
+}
+
+int omap4430_phy_set_clk(struct device *dev, int on)
+{
+ static int state;
+
+ if (on !state) {
+ /* Enable the phy clocks */
+ clk_enable(phyclk);
+ clk_enable(clk48m);
+ clk_enable(clk32k);
+ state = 1;
+ } else if (state) {
+
Re: [PATCH 2/7] usb: otg: Adding twl6030-usb transceiver driver for
On Wed, Dec 8, 2010 at 3:20 PM, Felipe Balbi ba...@ti.com wrote:
On Wed, Dec 08, 2010 at 09:31:15PM +0530, Hema HK wrote:
Adding the twl6030-usb transceiver support for OMAP4 musb driver.
OMAP4 supports 2 types of transceiver interface.
1. UTMI: The PHY is embedded within OMAP4. The transceiver functionality
is split between the twl6030 PMIC chip and OMAP4430. The VBUS, ID pin
sensing and OTG SRP generation part is integrated in TWL6030 and UTMI PHY
functionality is embedded within the OMAP4430.
There is no direct interactions between the MUSB controller and TWL6030
chip to communicate the session-valid, session-end and ID-GND events.
It has to be done through a software by setting/resetting bits in
one of the control module register of OMAP4430 which in turn toggles
the appropriate signals to MUSB controller.
The internal transceiver has functional clocks and
powerdown bits to powerdown the PHY for power saving.
Since there is no option available for having 2 transceiver drivers
for one USB controller, internal PHY specific APIs are passed through
plaform_data function pointers to use in the twl6030-usb transceiver
driver.
2. ULPI interface is provided for off-chip transceivers.
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: David Brownell dbrown...@users.sourceforge.net
---
arch/arm/mach-omap2/omap_phy_internal.c | 133
arch/arm/plat-omap/include/plat/usb.h | 4
drivers/usb/otg/Makefile | 1
drivers/usb/otg/twl6030-usb.c | 514
4 files changed, 652 insertions(+)
Index: linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
===
--- /dev/null
+++ linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
@@ -0,0 +1,148 @@
+/*
+ * This file configures the internal USB PHY in OMAP4430. Used
+ * with TWL6030 transceiver and MUSB on OMAP4430.
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ *Author: Hema HK hem...@ti.com
^^ you need a space after *
OK.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ */
+
+#include linux/types.h
+#include linux/errno.h
+#include linux/delay.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/err.h
+#include linux/usb.h
+
+#include plat/usb.h
+
+/* OMAP control module register for UTMI PHY */
+#define CONTROL_DEV_CONF 0x300
+#define PHY_PD 0x1
+
+#define USBOTGHS_CONTROL 0x33c
+#define AVALID BIT(0)
+#define BVALID BIT(1)
+#define VBUSVALID BIT(2)
+#define SESSEND BIT(3)
+#define IDDIG BIT(4)
+
+static struct clk *phyclk, *clk48m, *clk32k;
+static void __iomem *ctrl_base;
+
+int omap4430_phy_init(struct device *dev)
+{
+ ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
+ if (!ctrl_base) {
+ dev_err(dev, control module ioremap failed\n);
+ return -ENOMEM;
+ }
+ /* Power down the phy */
+ __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
+ phyclk = clk_get(dev, ocp2scp_usb_phy_ick);
+
+ if (IS_ERR(phyclk)) {
+ dev_err(dev, cannot clk_get ocp2scp_usb_phy_ick\n);
+ iounmap(ctrl_base);
+ return PTR_ERR(phyclk);
+ }
+
+ clk48m = clk_get(dev, ocp2scp_usb_phy_phy_48m);
+ if (IS_ERR(clk48m)) {
+ dev_err(dev, cannot clk_get ocp2scp_usb_phy_phy_48m\n);
+ clk_put(phyclk);
+ iounmap(ctrl_base);
+ return PTR_ERR(clk48m);
+ }
+
+ clk32k = clk_get(dev, usb_phy_cm_clk32k);
+ if (IS_ERR(clk32k)) {
+ dev_err(dev, cannot clk_get usb_phy_cm_clk32k\n);
+ clk_put(phyclk);
+ clk_put(clk48m);
+ iounmap(ctrl_base);
+ return PTR_ERR(clk32k);
+ }
+ return 0;
+}
+
+int omap4430_phy_set_clk(struct device *dev, int on)
+{
+ static int state;
+
+ if (on !state) {
+ /*
Re: [PATCH v2 1/3] ARM: omap: Enable low-level omap3 PM code to work withCONFIG_THUMB2_KERNEL
Hi, On Tue, Dec 7, 2010 at 7:15 PM, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Tue, 7 Dec 2010, Dave Martin wrote: On Tue, Dec 7, 2010 at 2:53 PM, Dave Martin dave.mar...@linaro.org wrote: [...] Note that converting to C doesn't mean that code which attempts to copy function bodies will work: you still need to handle the fact that if f() is a C function symbol, then the value of the symbol f is actually the function's base address + 1. See my changes in sram.c, To clarify, this applies *if* f is a Thumb symbol. To make it generic, a new macro could be used: #define SYM_ADDR(x) ((void *)((long)(x) ~1L)) Could do ... I wasn't sure if it was useful for just this one case, but I guess we may encounter others. And it would make the code a lot less messy... if so, a macro for exracting just the Thumb bit, and a macro for rebasing a symbol while preserving the Thumb bit could also be useful. #define SYM_STATE(x) ((long)(x) 1) #define SYM_REBASE(new_addr, sym) ((void *)((long)SYM_ADDR(new_addr) | SYM_STATE(sym))) The relationship could be a bit clearer if we use the name SYM_BASE instead of SYM_ADDR. With these, the affected code becomes something like: memcpy(buffer, SYM_BASE(f), size_of_f); new_f = SYM_REBASE(f, buffer); What do you think? Is there a recommended type for a pointer-sized integer? I notice linux/types.h defines uintptr_t (as unsigned long). 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: [PATCH 2/7] usb: otg: Adding twl6030-usb transceiver driver for
On Wed, Dec 8, 2010 at 3:53 PM, Kalliguddi, Hema hem...@ti.com wrote:
On Wed, Dec 8, 2010 at 3:20 PM, Felipe Balbi ba...@ti.com wrote:
On Wed, Dec 08, 2010 at 09:31:15PM +0530, Hema HK wrote:
Adding the twl6030-usb transceiver support for OMAP4 musb driver.
OMAP4 supports 2 types of transceiver interface.
1. UTMI: The PHY is embedded within OMAP4. The transceiver functionality
is split between the twl6030 PMIC chip and OMAP4430. The VBUS, ID pin
sensing and OTG SRP generation part is integrated in TWL6030 and UTMI PHY
functionality is embedded within the OMAP4430.
There is no direct interactions between the MUSB controller and TWL6030
chip to communicate the session-valid, session-end and ID-GND events.
It has to be done through a software by setting/resetting bits in
one of the control module register of OMAP4430 which in turn toggles
the appropriate signals to MUSB controller.
The internal transceiver has functional clocks and
powerdown bits to powerdown the PHY for power saving.
Since there is no option available for having 2 transceiver drivers
for one USB controller, internal PHY specific APIs are passed through
plaform_data function pointers to use in the twl6030-usb transceiver
driver.
2. ULPI interface is provided for off-chip transceivers.
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: David Brownell dbrown...@users.sourceforge.net
---
arch/arm/mach-omap2/omap_phy_internal.c | 133
arch/arm/plat-omap/include/plat/usb.h | 4
drivers/usb/otg/Makefile | 1
drivers/usb/otg/twl6030-usb.c | 514
4 files changed, 652 insertions(+)
Index: linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
===
--- /dev/null
+++ linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
@@ -0,0 +1,148 @@
+/*
+ * This file configures the internal USB PHY in OMAP4430. Used
+ * with TWL6030 transceiver and MUSB on OMAP4430.
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ *Author: Hema HK hem...@ti.com
^^ you need a space after *
OK.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ */
+
+#include linux/types.h
+#include linux/errno.h
+#include linux/delay.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/err.h
+#include linux/usb.h
+
+#include plat/usb.h
+
+/* OMAP control module register for UTMI PHY */
+#define CONTROL_DEV_CONF 0x300
+#define PHY_PD 0x1
+
+#define USBOTGHS_CONTROL 0x33c
+#define AVALID BIT(0)
+#define BVALID BIT(1)
+#define VBUSVALID BIT(2)
+#define SESSEND BIT(3)
+#define IDDIG BIT(4)
+
+static struct clk *phyclk, *clk48m, *clk32k;
+static void __iomem *ctrl_base;
+
+int omap4430_phy_init(struct device *dev)
+{
+ ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
+ if (!ctrl_base) {
+ dev_err(dev, control module ioremap failed\n);
+ return -ENOMEM;
+ }
+ /* Power down the phy */
+ __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
+ phyclk = clk_get(dev, ocp2scp_usb_phy_ick);
+
+ if (IS_ERR(phyclk)) {
+ dev_err(dev, cannot clk_get ocp2scp_usb_phy_ick\n);
+ iounmap(ctrl_base);
+ return PTR_ERR(phyclk);
+ }
+
+ clk48m = clk_get(dev, ocp2scp_usb_phy_phy_48m);
+ if (IS_ERR(clk48m)) {
+ dev_err(dev, cannot clk_get ocp2scp_usb_phy_phy_48m\n);
+ clk_put(phyclk);
+ iounmap(ctrl_base);
+ return PTR_ERR(clk48m);
+ }
+
+ clk32k = clk_get(dev, usb_phy_cm_clk32k);
+ if (IS_ERR(clk32k)) {
+ dev_err(dev, cannot clk_get usb_phy_cm_clk32k\n);
+ clk_put(phyclk);
+ clk_put(clk48m);
+ iounmap(ctrl_base);
+ return PTR_ERR(clk32k);
+ }
+ return 0;
+}
+
+int omap4430_phy_set_clk(struct device *dev, int on)
+{
+
Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL
On Wed, Dec 8, 2010 at 5:59 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Dave, -Original Message- From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] Sent: Wednesday, December 08, 2010 11:27 AM To: Dave Martin Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- o...@vger.kernel.org; linaro-...@lists.linaro.org Subject: RE: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL -Original Message- From: Dave Martin [mailto:dave.mar...@linaro.org] Sent: Tuesday, December 07, 2010 10:21 PM To: Santosh Shilimkar Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- o...@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL Hi, On Tue, Dec 7, 2010 at 6:28 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Dave, [.] So anything inside #ifdef CONFIG_THUMB2_KERNEL can assume v7/Thumb-2 capable (and hence reasonably new) tools. I'll follow up shortly with a patch to the generic ARM Kconfig to make this explicit, so that ARCH_OMAP2 and THUMB2_KERNEL can't accidentally be configured together. sure When you are doing the changes can you please check if you could build the THUMB2 kernel with omap2plus_defconfig. I suspect the build will fail. With my Kconfig patch, kconfig won't let you turn on Thumb-2 in that configuration: http://lists.arm.linux.org.uk/lurker/message/20101207.165737.0897658f.en.html If you want to turn on Thumb-2, you must disable ARCH_OMAP2 first. If my understanding is correct, this is the right behaviour. The kernel builds, fine but in ARM. I hope that clarifies things... 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: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL
-Original Message- From: Dave Martin [mailto:dave.mar...@linaro.org] Sent: Wednesday, December 08, 2010 4:11 PM To: Santosh Shilimkar Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- o...@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL On Wed, Dec 8, 2010 at 5:59 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Dave, -Original Message- From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] Sent: Wednesday, December 08, 2010 11:27 AM To: Dave Martin Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- o...@vger.kernel.org; linaro-...@lists.linaro.org Subject: RE: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL -Original Message- From: Dave Martin [mailto:dave.mar...@linaro.org] Sent: Tuesday, December 07, 2010 10:21 PM To: Santosh Shilimkar Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- o...@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL Hi, On Tue, Dec 7, 2010 at 6:28 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Dave, [.] So anything inside #ifdef CONFIG_THUMB2_KERNEL can assume v7/Thumb-2 capable (and hence reasonably new) tools. I'll follow up shortly with a patch to the generic ARM Kconfig to make this explicit, so that ARCH_OMAP2 and THUMB2_KERNEL can't accidentally be configured together. sure When you are doing the changes can you please check if you could build the THUMB2 kernel with omap2plus_defconfig. I suspect the build will fail. With my Kconfig patch, kconfig won't let you turn on Thumb-2 in that configuration: http://lists.arm.linux.org.uk/lurker/message/20101207.165737.0897658f.en.h tml If you want to turn on Thumb-2, you must disable ARCH_OMAP2 first. If my understanding is correct, this is the right behaviour. Ofcourse it will build with ARCH_OMAP2 disabled :) (ARMv6 dependency) In other words, I wanted to say that omap2plus_defconfig can't be used as is to build THUMB kernel binary. Thanks for conforming. -- To unsubscribe from this list: send the line unsubscribe 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: Thumb-2: Make CONFIG_THUMB2_KERNEL depend on !CPU_V6
On Wed, Dec 8, 2010 at 7:43 AM, David Brownell davi...@pacbell.net wrote: --- On Tue, 12/7/10, Dave Martin dave.mar...@linaro.org wrote: From: Dave Martin dave.mar...@linaro.org Subject: [PATCH] ARM: Thumb-2: Make CONFIG_THUMB2_KERNEL depend on !CPU_V6... This makes sense, because Thumb-2 code can't execute on anything prior to ARMv7. WRONG ... but you may be overlooking the fact that there are at least three flavors of Thumb-2 ... - Original, as on some ARMv6 chips ARM1156 was the introductory Thumb2 core). It's Thumb1 plus a very few 32-bit instructions. (And maybe the SIMD instructions too; I forget. Not suitable for OS work like IRQ handling, ISTR; or at least, not as suitable as the ARMv7 flavors. -Microcontroller ... ARMv7M chips, and likely not available on Linux-capable hardware ... Suitable for RTOS work like IRQ handling. You're correct on some points ... *but* v7-M is not supported in the kernel yet, and in any case full linux is not applicable - this will be ucLinux territory. v7-M shares much of the instruction set with v7-A/R, bit it's a substantially different architecture when it comes to things like exception handling etc. The v6T2 architecture supported by arm1156 does have comprehensive Thumb-2 support (not just a few 32-bit instructions), and arm1156 supports taking of exceptions in Thumb-2 etc., so in principle the complete OS could be built in Thumb-2 as is the case for v7. But this particular processor is rare and I believe it's not supported in the kernel right now ... and not likely to be. No other processors implement v6T2, and no new processors will implement it either. The rules might need to be refined later, but !CPU_V6 seems sensible for now. 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: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL
On Wed, Dec 8, 2010 at 10:45 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: -Original Message- From: Dave Martin [mailto:dave.mar...@linaro.org] Sent: Wednesday, December 08, 2010 4:11 PM To: Santosh Shilimkar Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- o...@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL On Wed, Dec 8, 2010 at 5:59 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Dave, -Original Message- From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] Sent: Wednesday, December 08, 2010 11:27 AM To: Dave Martin Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- o...@vger.kernel.org; linaro-...@lists.linaro.org Subject: RE: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL -Original Message- From: Dave Martin [mailto:dave.mar...@linaro.org] Sent: Tuesday, December 07, 2010 10:21 PM To: Santosh Shilimkar Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- o...@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL Hi, On Tue, Dec 7, 2010 at 6:28 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Dave, [.] So anything inside #ifdef CONFIG_THUMB2_KERNEL can assume v7/Thumb-2 capable (and hence reasonably new) tools. I'll follow up shortly with a patch to the generic ARM Kconfig to make this explicit, so that ARCH_OMAP2 and THUMB2_KERNEL can't accidentally be configured together. sure When you are doing the changes can you please check if you could build the THUMB2 kernel with omap2plus_defconfig. I suspect the build will fail. With my Kconfig patch, kconfig won't let you turn on Thumb-2 in that configuration: http://lists.arm.linux.org.uk/lurker/message/20101207.165737.0897658f.en.h tml If you want to turn on Thumb-2, you must disable ARCH_OMAP2 first. If my understanding is correct, this is the right behaviour. Ofcourse it will build with ARCH_OMAP2 disabled :) (ARMv6 dependency) In other words, I wanted to say that omap2plus_defconfig can't be used as is to build THUMB kernel binary. Well, yes, that's another way of looking at it. Anyway, I think this is the intended result -- is it OK for you? 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: [PATCH v2] OMAP4: Pandaboard: Add omap_reserve functionality
On Wednesday 08 December 2010 08:10:47 Raghuveer Murthy wrote: This patch adds omap_reserve functionality to board-omap4panda.c. Helps in the reserving boot time memory in SDRAM, used here for framebuffer allocation. This patch is in similar lines to commit id 71ee7dad9b6991, from Russell king Russell King ... it's a surname, not a title :-D btw. CCing linux-arm-kernel, as that's a proper mailing list. Cheers Cc: Russell King rmk+ker...@arm.linux.org.uk Cc: linux-...@lists.arm.linux.org.uk Signed-off-by: Raghuveer Murthy raghuveer.mur...@ti.com --- arch/arm/mach-omap2/board-omap4panda.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c index da24745..0ccc24f 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -393,6 +393,7 @@ MACHINE_START(OMAP4_PANDA, OMAP4 Panda board) /* Maintainer: David Anders - Texas Instruments Inc */ .boot_params= 0x8100, .map_io = omap4_panda_map_io, + .reserve= omap_reserve, .init_irq = omap4_panda_init_irq, .init_machine = omap4_panda_init, .timer = omap_timer, -- To unsubscribe from this list: send the line unsubscribe 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 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL
-Original Message- From: Dave Martin [mailto:dave.mar...@linaro.org] Sent: Wednesday, December 08, 2010 4:35 PM To: Santosh Shilimkar Cc: Tony Lindgren; linux-omap@vger.kernel.org; linaro- d...@lists.linaro.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL On Wed, Dec 8, 2010 at 10:45 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: -Original Message- From: Dave Martin [mailto:dave.mar...@linaro.org] Sent: Wednesday, December 08, 2010 4:11 PM To: Santosh Shilimkar Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- o...@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL On Wed, Dec 8, 2010 at 5:59 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Dave, -Original Message- From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] Sent: Wednesday, December 08, 2010 11:27 AM To: Dave Martin Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- o...@vger.kernel.org; linaro-...@lists.linaro.org Subject: RE: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL -Original Message- From: Dave Martin [mailto:dave.mar...@linaro.org] Sent: Tuesday, December 07, 2010 10:21 PM To: Santosh Shilimkar Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- o...@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL Hi, On Tue, Dec 7, 2010 at 6:28 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Dave, [.] So anything inside #ifdef CONFIG_THUMB2_KERNEL can assume v7/Thumb-2 capable (and hence reasonably new) tools. I'll follow up shortly with a patch to the generic ARM Kconfig to make this explicit, so that ARCH_OMAP2 and THUMB2_KERNEL can't accidentally be configured together. sure When you are doing the changes can you please check if you could build the THUMB2 kernel with omap2plus_defconfig. I suspect the build will fail. With my Kconfig patch, kconfig won't let you turn on Thumb-2 in that configuration: http://lists.arm.linux.org.uk/lurker/message/20101207.165737.0897658f.en.h tml If you want to turn on Thumb-2, you must disable ARCH_OMAP2 first. If my understanding is correct, this is the right behaviour. Ofcourse it will build with ARCH_OMAP2 disabled :) (ARMv6 dependency) In other words, I wanted to say that omap2plus_defconfig can't be used as is to build THUMB kernel binary. Well, yes, that's another way of looking at it. Anyway, I think this is the intended result -- is it OK for you? Should be ok considering you can't do much with it. But I let Tony comment on it. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL
On Wed, Dec 8, 2010 at 11:10 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: -Original Message- From: Dave Martin [mailto:dave.mar...@linaro.org] Sent: Wednesday, December 08, 2010 4:35 PM To: Santosh Shilimkar Cc: Tony Lindgren; linux-omap@vger.kernel.org; linaro- d...@lists.linaro.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL On Wed, Dec 8, 2010 at 10:45 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: -Original Message- From: Dave Martin [mailto:dave.mar...@linaro.org] Sent: Wednesday, December 08, 2010 4:11 PM To: Santosh Shilimkar Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- o...@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL On Wed, Dec 8, 2010 at 5:59 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Dave, -Original Message- From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] Sent: Wednesday, December 08, 2010 11:27 AM To: Dave Martin Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- o...@vger.kernel.org; linaro-...@lists.linaro.org Subject: RE: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL -Original Message- From: Dave Martin [mailto:dave.mar...@linaro.org] Sent: Tuesday, December 07, 2010 10:21 PM To: Santosh Shilimkar Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- o...@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL Hi, On Tue, Dec 7, 2010 at 6:28 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Dave, [.] So anything inside #ifdef CONFIG_THUMB2_KERNEL can assume v7/Thumb-2 capable (and hence reasonably new) tools. I'll follow up shortly with a patch to the generic ARM Kconfig to make this explicit, so that ARCH_OMAP2 and THUMB2_KERNEL can't accidentally be configured together. sure When you are doing the changes can you please check if you could build the THUMB2 kernel with omap2plus_defconfig. I suspect the build will fail. With my Kconfig patch, kconfig won't let you turn on Thumb-2 in that configuration: http://lists.arm.linux.org.uk/lurker/message/20101207.165737.0897658f.en.h tml If you want to turn on Thumb-2, you must disable ARCH_OMAP2 first. If my understanding is correct, this is the right behaviour. Ofcourse it will build with ARCH_OMAP2 disabled :) (ARMv6 dependency) In other words, I wanted to say that omap2plus_defconfig can't be used as is to build THUMB kernel binary. Well, yes, that's another way of looking at it. Anyway, I think this is the intended result -- is it OK for you? Should be ok considering you can't do much with it. But I let Tony comment on it. Well, it depends on what you're trying to do. We can't combine Thumb-2 with a combined omap kernel intended to support omap2. But in linaro for example we are targeting v7+ only for the kernel and userspace, so we already build the kernel for v7 and don't include the OMAP2 support; instead we target OMAP3/4. I believe the situation for Ubuntu is similar. In our case, including the omap2 support wouldn't be useful, since the userspace won't run on that platform anyway... So really, my concerns are that a) the generic rules for CONFIG_THUMB2_KERNEL are correct, and b) the omap tree works well with this configuration to the maximum extent possible. Obviously, mixing ARCH_OMAP2 with THUMB2_KERNEL _isn't_ possible even in theory, so I don't consider it a failure if that combination isn't supported. 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: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL
On Tue, Dec 7, 2010 at 7:29 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Dec 07, 2010 at 04:50:50PM +, Dave Martin wrote: I'll follow up shortly with a patch to the generic ARM Kconfig to make this explicit, so that ARCH_OMAP2 and THUMB2_KERNEL can't accidentally be configured together. That's a rubbish dependency. You may have an ARCH_OMAP2 platform which is Cortex A9, and you only have Cortex A9 support selected. In that case there's no reason to prevent THUMB2_KERNEL being selected. The right thing to do is to make THUMB2_KERNEL depend on those CPUs which are not to be selected - not by making it depend on some platform configuration option(s) which aren't actually relevent. You're correct on this point-- this was my conclusion also. If you haven't already, take a look at my other post http://www.spinics.net/lists/arm-kernel/msg106576.html Does this address your concern? 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: [PATCH RESEND] ARM: io: fix namespace conflicts
Russell,
On Fri, Dec 3, 2010 at 12:04, Sourav Poddar sourav.pod...@ti.com wrote:
Having __v as the variable name for the definition of different macros leads
to the namespace pollution. For example,
readl(p)
unrolls to:
({ u32 __v = ({ u32 __v = (( __u32)(__le32)(( __le32) ((void)0,
*(volatile unsigned int *)((p); __v; }); __asm__ __volatile__ (mcr
p15,
, %0, c7, c10, 5 : : r (0) : memory); __v; });
({ u32 __v = ({ u32 __v
causes sparse warning: warning: symbol '__v' shadows an earlier one
Using variable names which use the function name prefix across the
various macros avoids the namespace pollution.
With this change, ~200 sparse warnings in omap2plus_defconfig build are
fixed.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
Reviewed by: Nishanth Menon n...@ti.com
---
Links related to previous discussions are as follows:
https://patchwork.kernel.org/patch/250171/
http://www.spinics.net/lists/linux-omap/msg38569.html
http://marc.info/?t=128506336700011r=1w=2
arch/arm/include/asm/io.h | 32 +---
1 files changed, 21 insertions(+), 11 deletions(-)
If no comments, pls ack this patch.
Thanks,
V Charulatha
--
To unsubscribe from this list: send the line unsubscribe 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 01/11] OMAP4: PRCM: add OMAP4-specific accessor/mutatorfunctions
snip...
diff --git a/arch/arm/mach-omap2/cminst44xx.c
b/arch/arm/mach-omap2/cminst44xx.c
new file mode 100644
index 000..2c0cad3
--- /dev/null
+++ b/arch/arm/mach-omap2/cminst44xx.c
@@ -0,0 +1,118 @@
+/*
+ * OMAP4 CM instance functions
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Paul Walmsley
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This is needed since CM instances can be in the PRM, PRCM_MPU, CM1,
+ * or CM2 hardware modules. For example, the EMU_CM CM instance is in
+ * the PRM hardware module. What a mess...
+ */
+
+#include linux/kernel.h
+#include linux/types.h
+#include linux/errno.h
+#include linux/err.h
+#include linux/io.h
+
+#include plat/common.h
+
+#include cm.h
+#include cm1_44xx.h
+#include cm2_44xx.h
+#include cm44xx.h
+#include cminst44xx.h
+#include cm-regbits-44xx.h
+#include prcm44xx.h
+#include prm44xx.h
+#include prcm_mpu44xx.h
+
+static u32 (*_cm_read_fns[OMAP4_MAX_PRCM_PARTITIONS])(s16, u16) = {
+ [OMAP4430_INVALID_PRCM_PARTITION] = NULL,
+ [OMAP4430_PRM_PARTITION]=
omap4_prm_read_inst_reg,
+ [OMAP4430_CM1_PARTITION]=
omap4_cm1_read_inst_reg,
+ [OMAP4430_CM2_PARTITION]=
omap4_cm2_read_inst_reg,
+ [OMAP4430_SCRM_PARTITION] = NULL,
+ [OMAP4430_PRCM_MPU_PARTITION] =
omap4_prcm_mpu_read_inst_reg
+};
+
+static void (*_cm_write_fns[OMAP4_MAX_PRCM_PARTITIONS])(u32, s16, u16)
= {
+ [OMAP4430_INVALID_PRCM_PARTITION] = NULL,
+ [OMAP4430_PRM_PARTITION]=
omap4_prm_write_inst_reg,
+ [OMAP4430_CM1_PARTITION]=
omap4_cm1_write_inst_reg,
+ [OMAP4430_CM2_PARTITION]=
omap4_cm2_write_inst_reg,
+ [OMAP4430_SCRM_PARTITION] = NULL,
+ [OMAP4430_PRCM_MPU_PARTITION] =
omap4_prcm_mpu_write_inst_reg
+};
+
+/* Read a register in a CM instance */
+u32 omap4_cminst_read_inst_reg(u8 part, s16 module, u16 idx)
+{
+ BUG_ON(part = OMAP4_MAX_PRCM_PARTITIONS ||
+part == OMAP4430_INVALID_PRCM_PARTITION ||
+!_cm_read_fns[part]);
+ return _cm_read_fns[part](module, idx);
Hi Paul,
Would it help if we can avoid one more level of function
indirection (given that these are low level apis) and store
the Partition offsets in the tables above (instead of func
pointers) and do some thing like this.
return __raw_readl(OMAP2_L4_IO_ADDRESS(cm_read_offset[part],
module, idx));
with the table entries of cm_read_offset looking something like
+ [OMAP4430_PRM_PARTITION]= OMAP4430_PRM_BASE,
+ [OMAP4430_CM1_PARTITION]= OMAP4430_CM1_BASE,
+ [OMAP4430_CM2_PARTITION]= OMAP4430_CM2_BASE,
regards,
Rajendra
+}
+
+/* Write into a register in a CM instance */
+void omap4_cminst_write_inst_reg(u32 val, u8 part, s16 module, u16 idx)
+{
+ BUG_ON(part = OMAP4_MAX_PRCM_PARTITIONS ||
+part == OMAP4430_INVALID_PRCM_PARTITION ||
+!_cm_write_fns[part]);
+ _cm_write_fns[part](val, module, idx);
+}
+
+/* Read-modify-write a register in CM1. Caller must lock */
+u32 omap4_cminst_rmw_inst_reg_bits(u32 mask, u32 bits, u8 part,
+ s16 module, s16 idx)
+{
+ u32 v;
+
+ v = omap4_cminst_read_inst_reg(part, module, idx);
+ v = ~mask;
+ v |= bits;
+ omap4_cminst_write_inst_reg(v, part, module, idx);
+
+ return v;
+}
+
+
+/**
+ * omap4_cm_wait_module_ready - wait for a module to be in 'func' state
+ * @clkctrl_reg: CLKCTRL module address
+ *
+ * Wait for the module IDLEST to be functional. If the idle state is in
any
+ * the non functional state (trans, idle or disabled), module and thus
the
+ * sysconfig cannot be accessed and will probably lead to an imprecise
+ * external abort
+ *
+ * Module idle state:
+ * 0x0 func: Module is fully functional, including OCP
+ * 0x1 trans:Module is performing transition: wakeup, or sleep,
or sleep
+ * abortion
+ * 0x2 idle: Module is in Idle mode (only OCP part). It is
functional if
+ * using separate functional clock
+ * 0x3 disabled: Module is disabled and cannot be accessed
+ *
+ */
+int omap4_cm_wait_module_ready(void __iomem *clkctrl_reg)
+{
+ int i = 0;
+
+ if (!clkctrl_reg)
+ return 0;
+
+ omap_test_timeout((
+ ((__raw_readl(clkctrl_reg) OMAP4430_IDLEST_MASK) == 0)
||
+ (((__raw_readl(clkctrl_reg) OMAP4430_IDLEST_MASK)
+ OMAP4430_IDLEST_SHIFT) == 0x2)),
+ MAX_MODULE_READY_TIME, i);
+
+ return (i MAX_MODULE_READY_TIME) ? 0 : -EBUSY;
+}
+
diff --git a/arch/arm/mach-omap2/prcm.c
RE: [PATCH 01/11] OMAP4: PRCM: add OMAP4-specific accessor/mutatorfunctions
snip...
+++ b/arch/arm/mach-omap2/cminst44xx.c
@@ -0,0 +1,118 @@
+/*
+ * OMAP4 CM instance functions
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Paul Walmsley
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This is needed since CM instances can be in the PRM, PRCM_MPU, CM1,
+ * or CM2 hardware modules. For example, the EMU_CM CM instance is in
+ * the PRM hardware module. What a mess...
+ */
+
+#include linux/kernel.h
+#include linux/types.h
+#include linux/errno.h
+#include linux/err.h
+#include linux/io.h
+
+#include plat/common.h
+
+#include cm.h
+#include cm1_44xx.h
+#include cm2_44xx.h
+#include cm44xx.h
+#include cminst44xx.h
This header seems to be missed in the series.
+#include cm-regbits-44xx.h
+#include prcm44xx.h
+#include prm44xx.h
+#include prcm_mpu44xx.h
+
+static u32 (*_cm_read_fns[OMAP4_MAX_PRCM_PARTITIONS])(s16, u16) = {
+ [OMAP4430_INVALID_PRCM_PARTITION] = NULL,
+ [OMAP4430_PRM_PARTITION]=
omap4_prm_read_inst_reg,
+ [OMAP4430_CM1_PARTITION]=
omap4_cm1_read_inst_reg,
+ [OMAP4430_CM2_PARTITION]=
omap4_cm2_read_inst_reg,
+ [OMAP4430_SCRM_PARTITION] = NULL,
+ [OMAP4430_PRCM_MPU_PARTITION] =
omap4_prcm_mpu_read_inst_reg
+};
+
+static void (*_cm_write_fns[OMAP4_MAX_PRCM_PARTITIONS])(u32, s16, u16)
= {
+ [OMAP4430_INVALID_PRCM_PARTITION] = NULL,
+ [OMAP4430_PRM_PARTITION]=
omap4_prm_write_inst_reg,
+ [OMAP4430_CM1_PARTITION]=
omap4_cm1_write_inst_reg,
+ [OMAP4430_CM2_PARTITION]=
omap4_cm2_write_inst_reg,
+ [OMAP4430_SCRM_PARTITION] = NULL,
+ [OMAP4430_PRCM_MPU_PARTITION] =
omap4_prcm_mpu_write_inst_reg
+};
+
+/* Read a register in a CM instance */
+u32 omap4_cminst_read_inst_reg(u8 part, s16 module, u16 idx)
+{
+ BUG_ON(part = OMAP4_MAX_PRCM_PARTITIONS ||
+part == OMAP4430_INVALID_PRCM_PARTITION ||
+!_cm_read_fns[part]);
+ return _cm_read_fns[part](module, idx);
+}
+
+/* Write into a register in a CM instance */
+void omap4_cminst_write_inst_reg(u32 val, u8 part, s16 module, u16 idx)
+{
+ BUG_ON(part = OMAP4_MAX_PRCM_PARTITIONS ||
+part == OMAP4430_INVALID_PRCM_PARTITION ||
+!_cm_write_fns[part]);
+ _cm_write_fns[part](val, module, idx);
+}
+
+/* Read-modify-write a register in CM1. Caller must lock */
+u32 omap4_cminst_rmw_inst_reg_bits(u32 mask, u32 bits, u8 part,
+ s16 module, s16 idx)
+{
+ u32 v;
+
+ v = omap4_cminst_read_inst_reg(part, module, idx);
+ v = ~mask;
+ v |= bits;
+ omap4_cminst_write_inst_reg(v, part, module, idx);
+
+ return v;
+}
+
+
+/**
+ * omap4_cm_wait_module_ready - wait for a module to be in 'func' state
+ * @clkctrl_reg: CLKCTRL module address
+ *
+ * Wait for the module IDLEST to be functional. If the idle state is in
any
+ * the non functional state (trans, idle or disabled), module and thus
the
+ * sysconfig cannot be accessed and will probably lead to an imprecise
+ * external abort
+ *
+ * Module idle state:
+ * 0x0 func: Module is fully functional, including OCP
+ * 0x1 trans:Module is performing transition: wakeup, or sleep,
or sleep
+ * abortion
+ * 0x2 idle: Module is in Idle mode (only OCP part). It is
functional if
+ * using separate functional clock
+ * 0x3 disabled: Module is disabled and cannot be accessed
+ *
+ */
+int omap4_cm_wait_module_ready(void __iomem *clkctrl_reg)
+{
+ int i = 0;
+
+ if (!clkctrl_reg)
+ return 0;
+
+ omap_test_timeout((
+ ((__raw_readl(clkctrl_reg) OMAP4430_IDLEST_MASK) == 0)
||
+ (((__raw_readl(clkctrl_reg) OMAP4430_IDLEST_MASK)
+ OMAP4430_IDLEST_SHIFT) == 0x2)),
+ MAX_MODULE_READY_TIME, i);
+
+ return (i MAX_MODULE_READY_TIME) ? 0 : -EBUSY;
+}
+
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index dd95cbb..fe0865b 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -33,6 +33,7 @@
#include cm44xx.h
#include prm2xxx_3xxx.h
#include prm44xx.h
+#include prcm44xx.h
#include prm-regbits-24xx.h
#include prm-regbits-44xx.h
#include control.h
@@ -80,31 +81,6 @@ void omap_prcm_arch_reset(char mode, const char *cmd)
prcm_offs, OMAP4_RM_RSTCTRL);
}
-/* Read a PRM register, AND it, and shift the result down to bit 0 */
-u32 omap4_prm_read_bits_shift(void __iomem *reg, u32 mask)
-{
- u32 v;
-
- v = __raw_readl(reg);
- v = mask;
- v = __ffs(mask);
-
- return v;
-}
-
-/*
Which git repo for AM35x-OMAP35x-PSP-SDK-03.00.01.06
Hi, Would someone happen to know which git repo was used to create the AM35x-OMAP35x-PSP-SDK-03.00.01.06.tgz download package? I want to create an OpenEmbedded recipe for this package, and work with it using OE. Elvis Dowson -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] usb: musb: TWL6030: Selecting TWL6030_USB transceiver
Hello. Hema HK wrote: Selecting the twl6030-usb for OMAP4430SDP and OMAP4 PANDA board and adding OMAP4 internal phy code for compilation Signed-off-by: Hema HK hem...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: Tony Lindgren t...@atomide.com [...] Index: linux-2.6/drivers/usb/musb/Kconfig === --- linux-2.6.orig/drivers/usb/musb/Kconfig +++ linux-2.6/drivers/usb/musb/Kconfig @@ -12,6 +12,7 @@ config USB_MUSB_HDRC depends on (ARM || (BF54x !BF544) || (BF52x !BF522 !BF523)) select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) select TWL4030_USB if MACH_OMAP_3430SDP + select TWL6030_USB if (MACH_OMAP_3430SDP || MACH_OMAP4_PANDA) Parens are not necessary. Though the previous code uses them... 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 3/7] usb: otg: Kconfig: Add Kconfig option for TWL6030 transceiver.
Hello. Hema HK wrote: Added the TWL6030-usb transceiver option in the Kconfig Signed-off-by: Hema HK hem...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: David Brownell dbrown...@users.sourceforge.net [...] Index: linux-2.6/drivers/usb/otg/Kconfig === --- linux-2.6.orig/drivers/usb/otg/Kconfig +++ linux-2.6/drivers/usb/otg/Kconfig @@ -59,6 +59,18 @@ config TWL4030_USB This transceiver supports high and full speed devices plus, in host mode, low speed. +config TWL6030_USB + tristate TWL6030 USB Transceiver Driver + depends on TWL4030_CORE + select USB_OTG_UTILS + help + Enable this to support the USB OTG transceiver on TWL6030 + family chips. This TWL6030 transceiver has the VBUS and ID GND + and OTG SRP events capabilities. For all other transceiver functionality + UTMI PHY is embedded in OMAP4430.The internal PHY configurations APIs ^^ Space missing after period. 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 v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, November 16, 2010 3:43 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers Gopinath, Thara th...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, November 11, 2010 12:43 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers Thara Gopinath th...@ti.com writes: This patch adds debug support to the voltage and smartreflex drivers. This means a whole bunch of voltage processor and smartreflex parameters are now visible through the pm debugfs. The voltage parameters can be viewed at /debug/voltage/vdd_x/parameter and the smartreflex parameters can be viewed at /debug/vdd_x/smartreflex/parameter To enable overriding of these parameters from user side, write 1 into /debug/voltage/vdd_x/override_volt_params Please just git rid of any sort of override parameter from sysfs. Instead, you can detect in the sysfs code itself if any parameters were changed and then set the vdd-user_override flag. But in the sys-fs code I do not have access to vdd. How do I then set this flag? But when will I unset this flag?? You can't. And, AFAICT, it wasn't clear from the current code or docs whether this could work or was expected to work either, e.g., if you set override_volt_params back to zero, to the original values all get reused? If you want to provide this feature, then it should be documented and made clear that this is an intended goal. Thinking about this more, the main thing I don't like about this approach is that the active code paths (enable disable) have to check each time if any of these values have been overidden. Rather than have several places in the active code paths where this override value is checked, there the sysfs methods should simply update the values that are used by the core code. This way, the core would not need to know about where the values came from (defalts, volt_data, user override, etc.) If you want to provide a way to revert this, then maybe writing -1 will should switch that value back to the HW default, or volt_data default. Kevin, Benoit, Nishant et al, Without this override flag today there is no direct way of allowing user to write into these parameters. My question is, is there a need for the parameters to be over-written from the user-space? If yes, I need ideas on how to implement it with using override_volt_params ! Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MMC: omap_hsmmc: enable interface clock before calling mmc_host_enable()
On Tue, Dec 7, 2010 at 5:27 PM, Paul Walmsley p...@pwsan.com wrote:
In the OMAP HSMMC driver, the code path entered via mmc_host_enable() can
include register accesses to the HSMMC IP block. For this to work, both
the device interface clock and functional clock need to be enabled before
mmc_host_enable() is called. However, omap_hsmmc_probe() calls
mmc_host_enable() before enabling the device interface clock. This can
crash the kernel with:
Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09c014
Fix by calling mmc_host_enable() after the device interface clock is
enabled.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Adrian Hunter adrian.hun...@nokia.com
Cc: Kishore Kadiyala kishore.kadiy...@ti.com
Cc: Tero Kristo tero.kri...@nokia.com
---
Acked-by: Madhusudhan Chikkature madhu...@ti.com
drivers/mmc/host/omap_hsmmc.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 5d46021..58a2c5e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2101,14 +2101,14 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
/* we start off in DISABLED state */
host-dpm_state = DISABLED;
- if (mmc_host_enable(host-mmc) != 0) {
+ if (clk_enable(host-iclk) != 0) {
clk_put(host-iclk);
clk_put(host-fclk);
goto err1;
}
- if (clk_enable(host-iclk) != 0) {
- mmc_host_disable(host-mmc);
+ if (mmc_host_enable(host-mmc) != 0) {
+ clk_disable(host-iclk);
clk_put(host-iclk);
clk_put(host-fclk);
goto err1;
--
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 v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
Gopinath, Thara had written, on 12/08/2010 10:18 AM, the following: [..] And, AFAICT, it wasn't clear from the current code or docs whether this could work or was expected to work either, e.g., if you set override_volt_params back to zero, to the original values all get reused? If you want to provide this feature, then it should be documented and made clear that this is an intended goal. Thinking about this more, the main thing I don't like about this approach is that the active code paths (enable disable) have to check each time if any of these values have been overidden. Rather than have several places in the active code paths where this override value is checked, there the sysfs methods should simply update the values that are used by the core code. This way, the core would not need to know about where the values came from (defalts, volt_data, user override, etc.) If you want to provide a way to revert this, then maybe writing -1 will should switch that value back to the HW default, or volt_data default. Kevin, Benoit, Nishant et al, Without this override flag today there is no direct way of allowing user to write into these parameters. My question is, Glancing at the debug entries being overidden, as developer (debug users) working for tweaking parameters for their platform - yes - we will need some mechanism to runtime tweak and see the behavior without needing to rebuild the kernel everytime. On production system (OS users): they should'nt be using this. is there a need for the parameters to be over-written from the user-space? If yes, I need ideas on how to implement it with using override_volt_params ! Lets get the basics in kernel.org in some form! IMHO, all this double knobs are un-necessary overheads in codeflow for development only code- just provide the debugfs entries that reflect the data in their original structures, use the original structures everytime we go to a new transition (aka if you change the params in debugfs, they dont take effect till you do another transition).. but that is just my 2cents. --- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Thumb-2: Make CONFIG_THUMB2_KERNEL depend on !CPU_V6
So to recapitulate ... you're agreeing with me on my key point -- that ARM1156, a V6T2 core with Thumb2 support (used in fact to introduce Thumb2), should work for some in-kernel Thumb2 usage, degree TBD, but obviously the v7 cores are more capable (with SIMD support in T2, etc). And no, *I* never said anything about a V7M Linux, that was your words. I'm used to the advantages of using MMUs with fork() and mprotect(), etc. But the updated reason you gave for not allowing V6T2 is that it's an uncommon architecture (one core, not widely manufactured today) ... not impossibility. In short, the basic premise of $PATCH is wrong, as I pointed out, but there may be other reasons to merge it, related to V6T2 chip availability not the actual architecture specs from ARM. A similar argument would be that making the ASM code cope with core variants would get ugly/messy. At least the GNU assembler is, as I recall, aware of which instructions which cores support, so it would provide clean errors if given instructions that are Thumb2 (some flavor) but not accepted by the target. But Linux code shouldn't trigger such errors in the first place, even if they're a good backstop (and that implies ugly core-driven conditional code. -- To unsubscribe from this list: send the line unsubscribe 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] OMAP4: Pandaboard: Fixing MMC card detect gpio line
On 12/07/2010 06:13 AM, Murthy, Raghuveer wrote:
The .gpio_cd member of omap2_hsmmc_info is not initialized. This
will default to zero. On Pandaboard this interferes with gpio line
assigned for powering TFP410 DVI chip.
This fix was missed out in the previous commit bf56f0a6668cd, from
Nishanth Menon
Signed-off-by: Kishore Kadiyalakishore.kadiy...@ti.com
Signed-off-by: Raghuveer Murthyraghuveer.mur...@ti.com
Acked-by: Nishanth Menonn...@ti.com
Tested-by: David Anders x0132...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index ad6b5cc..0ccc24f 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -142,6 +142,7 @@ static struct omap2_hsmmc_info mmc[] = {
.mmc= 1,
.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_wp= -EINVAL,
+ .gpio_cd= -EINVAL,
},
{} /* Terminator */
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] ARM: omap: Enable low-level omap3 PM code to work withCONFIG_THUMB2_KERNEL
On Wed, 8 Dec 2010, Dave Martin wrote: Hi, On Tue, Dec 7, 2010 at 7:15 PM, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Tue, 7 Dec 2010, Dave Martin wrote: On Tue, Dec 7, 2010 at 2:53 PM, Dave Martin dave.mar...@linaro.org wrote: [...] Note that converting to C doesn't mean that code which attempts to copy function bodies will work: you still need to handle the fact that if f() is a C function symbol, then the value of the symbol f is actually the function's base address + 1. See my changes in sram.c, To clarify, this applies *if* f is a Thumb symbol. To make it generic, a new macro could be used: #define SYM_ADDR(x) ((void *)((long)(x) ~1L)) Could do ... I wasn't sure if it was useful for just this one case, but I guess we may encounter others. And it would make the code a lot less messy... That also makes the code self documenting. if so, a macro for exracting just the Thumb bit, and a macro for rebasing a symbol while preserving the Thumb bit could also be useful. #define SYM_STATE(x) ((long)(x) 1) #define SYM_REBASE(new_addr, sym) ((void *)((long)SYM_ADDR(new_addr) | SYM_STATE(sym))) The relationship could be a bit clearer if we use the name SYM_BASE instead of SYM_ADDR. With these, the affected code becomes something like: memcpy(buffer, SYM_BASE(f), size_of_f); new_f = SYM_REBASE(f, buffer); What do you think? Looks fine to me. Is there a recommended type for a pointer-sized integer? I notice linux/types.h defines uintptr_t (as unsigned long). If uintptr_t is already defined then it is probably a good idea to just use it. Nicolas
Re: [PATCH] ARM: Thumb-2: Make CONFIG_THUMB2_KERNEL depend on !CPU_V6
David Brownell davi...@pacbell.net writes: So to recapitulate ... you're agreeing with me on my key point -- that ARM1156, a V6T2 core with Thumb2 support (used in fact to introduce Thumb2), should work for some in-kernel Thumb2 usage, degree TBD, but obviously the v7 cores are more capable (with SIMD support in T2, etc). The ARM1156 implements the full Thumb2 instruction set, exactly the same as in v7 except for ThumbEE and features new to v7 in general. But the updated reason you gave for not allowing V6T2 is that it's an uncommon architecture (one core, not widely manufactured today) ... not impossibility. The architecture being uncommon is not in my opinion cause to make life harder than necessary for whomever might some day want to add support for it. Does the patch solve any real problem today? -- Måns Rullgård m...@mansr.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] ARM: Thumb-2: Make CONFIG_THUMB2_KERNEL depend on !CPU_V6
Hi, On Wed, Dec 8, 2010 at 4:38 PM, David Brownell davi...@pacbell.net wrote: So to recapitulate ... you're agreeing with me on my key point -- that ARM1156, a V6T2 core with Thumb2 support (used in fact to introduce Thumb2), should work for some in-kernel Thumb2 usage, degree TBD, but obviously the v7 cores are more capable (with SIMD support in T2, etc). To be strictly accurate, 1156 is not an ARMv6 core -- it's an ARMv6T2 core, so it's debatable whether CPU_V6 should be set in this case. A separate config item, such as CPU_V6T2 might be needed to express this distinction if support for 1156 were to be added. I believe if multiple CPU_* are defined, this usually means a kernel configured to support multiple platforms in the same binary; this is supported by some mach tress. A kernel binary intended to execute on a set of platforms including a plain v6 platform (indicated by CPU_V6 being set) most not be built in Thumb-2, since it then wouldn't work on those v6 platforms. And no, *I* never said anything about a V7M Linux, that was your words. I'm used to the advantages of using MMUs with fork() and mprotect(), etc. But the updated reason you gave for not allowing V6T2 is that it's an uncommon architecture (one core, not widely manufactured today) ... not impossibility. Agreed. Out of interest, do you know of anyone working with 1156 of patches to support it? This would be a different story, since then it would be clearer how CONFIG_THUMB2_KERNEL should integrate in this case. In short, the basic premise of $PATCH is wrong, as I pointed out, but there may be other reasons to merge it, related to V6T2 chip availability not the actual architecture specs from ARM. Well, the statement Thumb-2 code can't execute on anything prior to ARMv7 was a generalisation; the commit message can certainly be made clearer. Really, what I meant was something like Thumb-2 code can't execute on any common architecture prior to ARMv7, but I'm happy to make it clearer to explain the v6T2 case. A similar argument would be that making the ASM code cope with core variants would get ugly/messy. At least the GNU assembler is, as I recall, aware of which instructions which cores support, so it would provide clean errors if given instructions that are Thumb2 (some flavor) but not accepted by the target. But Linux code shouldn't trigger such errors in the first place, even if they're a good backstop (and that implies ugly core-driven conditional code. That's why I prefer not to allow CONFIG_THUMB2_KERNEL to be turned on in situations where it won't work. If you have a cleaner solution, feel free to suggest it. 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: [PATCH 01/11] OMAP4: PRCM: add OMAP4-specific accessor/mutatorfunctions
On Wed, 8 Dec 2010, Rajendra Nayak wrote: +#include cminst44xx.h This header seems to be missed in the series. Oops, sorry about that. Fixed in the git branch on git.pwsan.com. Attached below is the final mach-omap2/cminst44xx.h file. It's created by the first patch in this series (OMAP4: PRCM: add OMAP4-specific accessor/mutator functions) and modified by the seventh patch in the series (OMAP4: clockdomains: add OMAP4 PRCM data and OMAP4 support) I will repost those. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Which git repo for AM35x-OMAP35x-PSP-SDK-03.00.01.06
Op 8 dec 2010, om 15:05 heeft Elvis Dowson het volgende geschreven: Hi, Would someone happen to know which git repo was used to create the AM35x-OMAP35x-PSP-SDK-03.00.01.06.tgz download package? I want to create an OpenEmbedded recipe for this package, and work with it using OE. The existing recipe for that isn't good enough?-- To unsubscribe from this list: send the line unsubscribe 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 01/11] OMAP4: PRCM: add OMAP4-specific accessor/mutatorfunctions
On Wed, 8 Dec 2010, Paul Walmsley wrote: On Wed, 8 Dec 2010, Rajendra Nayak wrote: +#include cminst44xx.h This header seems to be missed in the series. Oops, sorry about that. Fixed in the git branch on git.pwsan.com. Attached below is the final mach-omap2/cminst44xx.h file. Well, anyway, here it is. - Paul /* * OMAP4 Power/Reset Management (CM) function prototypes * * Copyright (C) 2010 Nokia Corporation * Paul Walmsley * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. */ #ifndef __ARCH_ASM_MACH_OMAP2_CMINST44XX_H #define __ARCH_ASM_MACH_OMAP2_CMINST44XX_H extern bool omap4_cminst_is_clkdm_in_hwsup(u8 part, s16 inst, u16 cdoffs); extern void omap4_cminst_clkdm_enable_hwsup(u8 part, s16 inst, u16 cdoffs); extern void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs); extern void omap4_cminst_clkdm_force_sleep(u8 part, s16 inst, u16 cdoffs); extern void omap4_cminst_clkdm_force_wakeup(u8 part, s16 inst, u16 cdoffs); /* * In an ideal world, we would not export these low-level functions, * but this will probably take some time to fix properly */ extern u32 omap4_cminst_read_inst_reg(u8 part, s16 inst, u16 idx); extern void omap4_cminst_write_inst_reg(u32 val, u8 part, s16 inst, u16 idx); extern u32 omap4_cminst_rmw_inst_reg_bits(u32 mask, u32 bits, u8 part, s16 inst, s16 idx); extern int omap4_cm_wait_module_ready(void __iomem *clkctrl_reg); #endif -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to change freq of mmc2_clk to 48Mhz for OMAP35xx
On Wed, 8 Dec 2010, Elvis Dowson wrote: What should I do to change the output frequency of mmc2_clk signal to 48Mhz for the OMAP35xx processor? Right now it is giving an output of 96MHz and the signal output looks more like a sine wave than a square wave clock output signal. Assuming you're using the mainline kernel, it doesn't look like the MMC driver changes its functional clock at all. So perhaps your bootloader is programming it incorrectly? I guess at some point we will need to reprogram all the clocks on boot also, to deal with buggy bootloaders... Anyway, if you want to try changing it from the kernel side, you'll need code like this in the MMC driver or OMAP integration code (off the top of my head, untested): struct clk *c; c = clk_get(dev, fck); clk_set_rate(c, 4800); clk_put(c); Please let me know if this doesn't work. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to change freq of mmc2_clk to 48Mhz for OMAP35xx
On Wed, Dec 8, 2010 at 10:36 PM, Paul Walmsley p...@pwsan.com wrote: Anyway, if you want to try changing it from the kernel side, you'll need code like this in the MMC driver or OMAP integration code (off the top of my head, untested): Please let me know if this doesn't work. IIRC, there is mmc_set_clock() method, but it isn't exported. Anyway, I have another issue with some specific code which also requires the same function to be exported. -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line unsubscribe 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 11/14] OMAP4: PRCM: reorganize existing OMAP4 PRCM header files
Paul Walmsley p...@pwsan.com writes: On Tue, 7 Dec 2010, Cousson, Benoit wrote: On 12/7/2010 2:25 AM, Paul Walmsley wrote: [...] + * + * XXX This file needs to be updated to align on one of OMAP4, OMAP44XX, + * or OMAP4430. Yep, I was thinking to change that as well. My first thought was OMAP4 to get a shorter name, but when we will introduce OMAP4440, we might have some new entries, that will looks ugly close to OMAP4. So at the end I will prefer OMAP44XX for the moment and we might renamed to OMAP4430 or OMAP4440 for the entries that will diverge. Do you want to change that for 2.6.38? It will require some sync with the various users of these defines, but that should be doable. I don't mind waiting until after 2.6.38, I think we'll have a pretty huge pile of patches on our hands to merge already for .38... maybe Tony or Kevin have some opinions though. I think this should wait 'til after 2.6.38, but be early in the next cycle so all dependencies can be handled early. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 8/8] Input: omap4 - pm runtime
Datta, Shubhrajyoti shubhrajy...@ti.com writes: [...] Subject: Re: [PATCH v6 8/8] Input: omap4 - pm runtime Abraham Arce x0066...@ti.com writes: Enable pm runtime in driver So power is enabled on probe and cut on _remove(). Did you consider doing any more fine grained PM for this device? For example, cutting power after some inactivity timer and re-enabling on a keypress/interrupt? My idea is that the clock needs to be on to get interrupts (OMAP4 the control is at module level and ick/fclk level control is difficult). So disabling will prevent interrupts. The keypad is in wakeup domain which is always on. So the power impact may be minimal. What do you think. I think the changelog needs to be updated to describe the reasons behind the decisions made. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] staging: tidspbridge: use the right type for list_is_last
Removes the following warning: CC [M] drivers/staging/tidspbridge/rmgr/rmm.o drivers/staging/tidspbridge/rmgr/rmm.c: In function 'rmm_alloc': drivers/staging/tidspbridge/rmgr/rmm.c:147: warning: passing argument 1 of 'list_is_last' from incompatible pointer type include/linux/list.h:170: note: expected 'const struct list_head *' but argument is of type 'struct rmm_ovly_sect *' Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com --- drivers/staging/tidspbridge/rmgr/rmm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/staging/tidspbridge/rmgr/rmm.c b/drivers/staging/tidspbridge/rmgr/rmm.c index aae8657..5a3f09c 100644 --- a/drivers/staging/tidspbridge/rmgr/rmm.c +++ b/drivers/staging/tidspbridge/rmgr/rmm.c @@ -144,7 +144,7 @@ int rmm_alloc(struct rmm_target_obj *target, u32 segid, u32 size, new_sect-addr = addr; new_sect-size = size; new_sect-page = segid; - if (list_is_last(sect, target-ovly_list)) + if (list_is_last(sect-list_elem, target-ovly_list)) /* Put new section at the end of the list */ list_add_tail(new_sect-list_elem, target-ovly_list); -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: tidspbridge: remove file handling functions for loader
On Tue, Dec 07, 2010 at 12:09:06AM -0600, Omar Ramirez Luna wrote: Instead use request_firmware and friends to get a valid firmware image. Right now the image is supplied dynamically through udev and the following rule: KERNEL==omap-dsp, SUBSYSTEM==firmware, ACTION==add, \ RUN+=/bin/sh -c 'echo 1 /sys/$DEVPATH/loading; \ cat $FIRMWARE /sys/$DEVPATH/data; \ echo 0 /sys/$DEVPATH/loading' Why do you need a custom firmware rule? Why doesn't the default firmware loading rule that comes with udev work properly for you? What are you needing different here that works properly for all other drivers? confused, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] OMAP2+: PM/serial: fix console semaphore acquire during suspend
commit 0d8e2d0dad98a693bad88aea6876ac8b94ad95c6 (OMAP2+: PM/serial:
hold console semaphore while OMAP UARTs are disabled) added use of the
console semaphore to protect UARTs from being accessed after disabled
during idle, but this causes problems in suspend.
During suspend, the console semaphore is acquired by the console
suspend method (console_suspend()) so the try_acquire_console_sem()
will always fail and suspend will be aborted.
To fix, introduce a check so the console semaphore is only attempted
during idle, and not during suspend. Also use the same check so that
the console semaphore is not prematurely released during resume.
Thanks to Paul Walmsley for suggesting adding the same check during
resume.
Cc: Paul Walmsley p...@pwsan.com
Tested-by: Jean Pihet j-pi...@ti.com
Tested-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
Applies to Tony's omap-fixes branch, and recommended for -rc series.
arch/arm/mach-omap2/pm24xx.c | 35 ---
arch/arm/mach-omap2/pm34xx.c | 27 ---
2 files changed, 52 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index c85923e..1e031d0 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -53,6 +53,19 @@
#include plat/powerdomain.h
#include plat/clockdomain.h
+#ifdef CONFIG_SUSPEND
+static suspend_state_t suspend_state = PM_SUSPEND_ON;
+static inline bool is_suspending(void)
+{
+ return (suspend_state != PM_SUSPEND_ON);
+}
+#else
+static inline bool is_suspending(void)
+{
+ return false;
+}
+#endif
+
static void (*omap2_sram_idle)(void);
static void (*omap2_sram_suspend)(u32 dllctrl, void __iomem *sdrc_dlla_ctrl,
void __iomem *sdrc_power);
@@ -120,8 +133,9 @@ static void omap2_enter_full_retention(void)
goto no_sleep;
/* Block console output in case it is on one of the OMAP UARTs */
- if (try_acquire_console_sem())
- goto no_sleep;
+ if (!is_suspending())
+ if (try_acquire_console_sem())
+ goto no_sleep;
omap_uart_prepare_idle(0);
omap_uart_prepare_idle(1);
@@ -136,7 +150,8 @@ static void omap2_enter_full_retention(void)
omap_uart_resume_idle(1);
omap_uart_resume_idle(0);
- release_console_sem();
+ if (!is_suspending())
+ release_console_sem();
no_sleep:
if (omap2_pm_debug) {
@@ -284,6 +299,12 @@ out:
local_irq_enable();
}
+static int omap2_pm_begin(suspend_state_t state)
+{
+ suspend_state = state;
+ return 0;
+}
+
static int omap2_pm_prepare(void)
{
/* We cannot sleep in idle until we have resumed */
@@ -333,10 +354,18 @@ static void omap2_pm_finish(void)
enable_hlt();
}
+static void omap2_pm_end(void)
+{
+ suspend_state = PM_SUSPEND_ON;
+ return;
+}
+
static struct platform_suspend_ops omap_pm_ops = {
+ .begin = omap2_pm_begin,
.prepare= omap2_pm_prepare,
.enter = omap2_pm_enter,
.finish = omap2_pm_finish,
+ .end= omap2_pm_end,
.valid = suspend_valid_only_mem,
};
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 0ec8a04..648b8c5 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -50,6 +50,19 @@
#include sdrc.h
#include control.h
+#ifdef CONFIG_SUSPEND
+static suspend_state_t suspend_state = PM_SUSPEND_ON;
+static inline bool is_suspending(void)
+{
+ return (suspend_state != PM_SUSPEND_ON);
+}
+#else
+static inline bool is_suspending(void)
+{
+ return false;
+}
+#endif
+
/* Scratchpad offsets */
#define OMAP343X_TABLE_ADDRESS_OFFSET 0xc4
#define OMAP343X_TABLE_VALUE_OFFSET 0xc0
@@ -387,10 +400,11 @@ void omap_sram_idle(void)
}
/* Block console output in case it is on one of the OMAP UARTs */
- if (per_next_state PWRDM_POWER_ON ||
- core_next_state PWRDM_POWER_ON)
- if (try_acquire_console_sem())
- goto console_still_active;
+ if (!is_suspending())
+ if (per_next_state PWRDM_POWER_ON ||
+ core_next_state PWRDM_POWER_ON)
+ if (try_acquire_console_sem())
+ goto console_still_active;
/* PER */
if (per_next_state PWRDM_POWER_ON) {
@@ -470,7 +484,8 @@ void omap_sram_idle(void)
omap_uart_resume_idle(3);
}
- release_console_sem();
+ if (!is_suspending())
+ release_console_sem();
console_still_active:
/* Disable IO-PAD and IO-CHAIN wakeup */
@@ -514,8 +529,6 @@ out:
}
#ifdef CONFIG_SUSPEND
-static suspend_state_t suspend_state;
-
static int omap3_pm_prepare(void)
{
disable_hlt();
--
Re: [PATCH v2] OMAP2+: disable idle early in the suspend sequence
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
Some bad interaction between the idle and the suspend paths has been
noticed: the idle code is called during the suspend enter and exit
sequences. This could cause corruption or lock-up of resources.
The solution is to move the calls to disable_hlt at the very beginning
of the suspend sequence (ex. in omap3_pm_begin instead of
omap3_pm_prepare), and the call to enable_hlt at the very end of
the suspend sequence (ex. in omap3_pm_end instead of omap3_pm_finish).
In an earlier version, I thought we agreed to just remove the empty
prepare/finish calls. Can you do that?
Also, can you base this on top of my recently posted patch:
[PATCH v3] OMAP2+: PM/serial: fix console semaphore acquire during suspend
since it touches some of the same code for pm24xx.c
Thanks,
Kevin
Tested with RET and OFF on Beagle and OMAP3EVM.
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
v1: support for OMAP3 only.
Tested on board.
v2: Added support for OMAP2 and OMAP4.
Compile tested only for OMAP2 and OMAP4.
Tested on board for OMAP3.
arch/arm/mach-omap2/pm24xx.c | 16 ++--
arch/arm/mach-omap2/pm34xx.c |4 ++--
arch/arm/mach-omap2/pm44xx.c |4 ++--
3 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index c85923e..3820179 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -286,8 +286,6 @@ out:
static int omap2_pm_prepare(void)
{
- /* We cannot sleep in idle until we have resumed */
- disable_hlt();
return 0;
}
@@ -330,10 +328,24 @@ static int omap2_pm_enter(suspend_state_t state)
static void omap2_pm_finish(void)
{
+}
+
+static int omap2_pm_begin(suspend_state_t state)
+{
+ /* We cannot sleep in idle until we have resumed */
+ disable_hlt();
+ return 0;
+}
+
+static void omap2_pm_end(void)
+{
enable_hlt();
+ return;
}
static struct platform_suspend_ops omap_pm_ops = {
+ .begin = omap2_pm_begin,
+ .end= omap2_pm_end,
.prepare= omap2_pm_prepare,
.enter = omap2_pm_enter,
.finish = omap2_pm_finish,
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 0ec8a04..ec80d38 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -518,7 +518,6 @@ static suspend_state_t suspend_state;
static int omap3_pm_prepare(void)
{
- disable_hlt();
return 0;
}
@@ -586,12 +585,12 @@ static int omap3_pm_enter(suspend_state_t unused)
static void omap3_pm_finish(void)
{
- enable_hlt();
}
/* Hooks to enable / disable UART interrupts during suspend */
static int omap3_pm_begin(suspend_state_t state)
{
+ disable_hlt();
suspend_state = state;
omap_uart_enable_irqs(0);
return 0;
@@ -601,6 +600,7 @@ static void omap3_pm_end(void)
{
suspend_state = PM_SUSPEND_ON;
omap_uart_enable_irqs(1);
+ enable_hlt();
return;
}
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 54544b4..f4c4fab 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -33,7 +33,6 @@ static LIST_HEAD(pwrst_list);
#ifdef CONFIG_SUSPEND
static int omap4_pm_prepare(void)
{
- disable_hlt();
return 0;
}
@@ -61,17 +60,18 @@ static int omap4_pm_enter(suspend_state_t suspend_state)
static void omap4_pm_finish(void)
{
- enable_hlt();
return;
}
static int omap4_pm_begin(suspend_state_t state)
{
+ disable_hlt();
return 0;
}
static void omap4_pm_end(void)
{
+ enable_hlt();
return;
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: tidspbridge: remove file handling functions for loader
Hi, On Wed, Dec 8, 2010 at 4:26 PM, Greg KH g...@kroah.com wrote: On Tue, Dec 07, 2010 at 12:09:06AM -0600, Omar Ramirez Luna wrote: Instead use request_firmware and friends to get a valid firmware image. Right now the image is supplied dynamically through udev and the following rule: KERNEL==omap-dsp, SUBSYSTEM==firmware, ACTION==add, \ RUN+=/bin/sh -c 'echo 1 /sys/$DEVPATH/loading; \ cat $FIRMWARE /sys/$DEVPATH/data; \ echo 0 /sys/$DEVPATH/loading' Why do you need a custom firmware rule? It was meant as an example, when I compiled my minimal file system it didn't supply the firmware.sh script nor created /lib/firmware... I thought that not everybody would have the firmware.sh, so I just provided a sample rule. Why doesn't the default firmware loading rule that comes with udev work properly for you? What are you needing different here that works properly for all other drivers? firmware.sh under /lib/udev/ and dsp binaries installed under /lib/firmware/, my rule is the brute version of firmware.sh so nothing different in the script. Probably the only change would be to supply the firmware name only, as of now the insmod parameter requires the entire path, e.g.: insmod bridgedriver.ko base_img=/lib/dsp/baseimage.dof if using firmware.sh and placing firmware files under /lib/firmware/, then insmod bridgedriver.ko base_img=baseimage.dof Should be enough. Regards, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5 v3] OMAP: idle path errata fixes
Nishanth Menon had written, on 12/03/2010 11:03 AM, the following: Hi, as discussed in [1], here is step 2 - idle path errata fixes. this is the next rev incorporating comments from V2 post of this series. V2: http://marc.info/?l=linux-omapm=129106200408109w=2 Major change in V3: Erratas are now handled per silicon - it is much cleaner :) no more redundant cpu_is_omap34xx check anymore errata configure is __init as it should be Eduardo Valentin (1): OMAP3630: PM: Erratum i583: disable coreoff if ES1.2 Nishanth Menon (1): OMAP3630: PM: Erratum i608: disable RTA Peter 'p2' De Schrijver (2): OMAP3: PM: Erratum i581 support: dll kick strategy OMAP3630: PM: Disable L2 cache while invalidating L2 cache Richard Woodruff (1): OMAP3: PM: Update clean_l2 to use v7_flush_dcache_all arch/arm/mach-omap2/control.c |5 +- arch/arm/mach-omap2/control.h |5 + arch/arm/mach-omap2/pm.h|6 ++ arch/arm/mach-omap2/pm34xx.c| 38 arch/arm/mach-omap2/sleep34xx.S | 187 --- 5 files changed, 169 insertions(+), 72 deletions(-) bloat-o-meter report Vs 2.6.37-rc4 add/remove: 1/0 grow/shrink: 6/2 up/down: 220/-12 (208) function old new delta omap3_pm_init 17761868 +92 omap_sram_idle 10401104 +64 omap3_save_scratchpad_contents 732 760 +28 vermagic 45 60 +15 linux_banner 131 146 +15 omap2_init_mmc 10321036 +4 pm34xx_errata - 2 +2 omap_serial_init_port 11201116 -4 prcm_interrupt_handler 276 268 -8 [1] http://marc.info/?l=linux-omapm=129045338806957w=2 Cc: Charulatha Varadarajan ch...@ti.com Cc: Jean Pihet jean.pi...@newoldbits.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Tao Hu tgh...@motorola.com Cc: Tony Lindgren t...@atomide.com Cc: Vishwanath Sripathy vishwanath...@ti.com Gentle ping on this series.. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/3] OMAP: Add opp data
Hi, On Wed, Nov 24, 2010 at 10:54, Nishanth Menon n...@ti.com wrote: Major changes in V5: rebased to k.org 2.6.37-rc3 introduced omap_opp_data.h couple of whitespace and offline license suggestion cleanups V4: http://marc.info/?l=linux-omapm=128993367112637w=2 V3: http://marc.info/?l=linux-omapm=128984926812800w=2 V2: http://marc.info/?t=12875366533r=1w=2 Kevin Hilman (1): OMAP3: remove OPP interfaces from OMAP PM layer Nishanth Menon (2): omap: opp: add OMAP3 OPP table data and common init omap4: opp: add OPP table data Documentation/arm/OMAP/omap_pm | 25 +++ arch/arm/mach-omap2/Kconfig | 4 + arch/arm/mach-omap2/Makefile | 6 ++ arch/arm/mach-omap2/io.c | 3 +- arch/arm/mach-omap2/omap_opp_data.h | 72 +++ arch/arm/mach-omap2/opp.c | 93 + arch/arm/mach-omap2/opp3xxx_data.c | 107 + arch/arm/mach-omap2/opp4xxx_data.c | 57 +++ arch/arm/mach-omap2/pm.h | 14 arch/arm/plat-omap/include/plat/omap-pm.h | 31 +++-- arch/arm/plat-omap/omap-pm-noop.c | 11 +--- 11 files changed, 390 insertions(+), 33 deletions(-) create mode 100644 arch/arm/mach-omap2/omap_opp_data.h create mode 100644 arch/arm/mach-omap2/opp.c create mode 100644 arch/arm/mach-omap2/opp3xxx_data.c create mode 100644 arch/arm/mach-omap2/opp4xxx_data.c Bloat-o-meter report for omap2plus_defconfig Vs 2.6.37-rc3: add/remove: 22/3 grow/shrink: 4/3 up/down: 3149/-64 (3085) function old new delta opp_add - 568 +568 opp_set_availability - 520 +520 omap_init_opp_table - 328 +328 omap34xx_opp_def_list - 208 +208 static.__func__ 13783 13954 +171 opp_find_freq_floor - 164 +164 omap36xx_opp_def_list - 160 +160 opp_find_freq_ceil - 144 +144 opp_find_freq_exact - 128 +128 find_device_opp - 124 +124 opp_get_opp_count - 120 +120 omap44xx_opp_def_list - 96 +96 opp_get_voltage - 76 +76 opp_get_freq - 76 +76 omap3_opp_init - 76 +76 dev_opp_list_lock - 72 +72 omap4_opp_init - 48 +48 vermagic 45 60 +15 linux_banner 133 148 +15 opp_enable - 8 +8 opp_disable - 8 +8 dev_opp_list - 8 +8 kernel_config_data 13899 13906 +7 __initcall_omap4_opp_init6 - 4 +4 __initcall_omap3_opp_init6 - 4 +4 omap_table_init - 1 +1 omap_pm_cpu_set_freq 28 24 -4 mpu_opps 4 - -4 l3_opps 4 - -4 dsp_opps 4 - -4 omap_pm_if_early_init 20 8 -12 omap2_init_common_hw 464 428 -36 Regards, Nishanth Menon Gentle ping on this series.. Regards, Nishanth Menon
Re: [PATCH] staging: tidspbridge: remove file handling functions for loader
On Wed, Dec 08, 2010 at 05:02:20PM -0600, Ramirez Luna, Omar wrote: Hi, On Wed, Dec 8, 2010 at 4:26 PM, Greg KH g...@kroah.com wrote: On Tue, Dec 07, 2010 at 12:09:06AM -0600, Omar Ramirez Luna wrote: Instead use request_firmware and friends to get a valid firmware image. Right now the image is supplied dynamically through udev and the following rule: KERNEL==omap-dsp, SUBSYSTEM==firmware, ACTION==add, \ RUN+=/bin/sh -c 'echo 1 /sys/$DEVPATH/loading; \ cat $FIRMWARE /sys/$DEVPATH/data; \ echo 0 /sys/$DEVPATH/loading' Why do you need a custom firmware rule? It was meant as an example, when I compiled my minimal file system it didn't supply the firmware.sh script nor created /lib/firmware... I thought that not everybody would have the firmware.sh, so I just provided a sample rule. So, can I remove this from the changelog comment, as it's not really needed at all? Why doesn't the default firmware loading rule that comes with udev work properly for you? What are you needing different here that works properly for all other drivers? firmware.sh under /lib/udev/ and dsp binaries installed under /lib/firmware/, my rule is the brute version of firmware.sh so nothing different in the script. Probably the only change would be to supply the firmware name only, as of now the insmod parameter requires the entire path, e.g.: insmod bridgedriver.ko base_img=/lib/dsp/baseimage.dof if using firmware.sh and placing firmware files under /lib/firmware/, then insmod bridgedriver.ko base_img=baseimage.dof Ick, why use a module parameter name at all? Why is this special and different from all other firmware users? They don't have to manually specify a file name, the driver does that. Please fix up the patch to not require a module parameter, distros hate them, and users hate them even more. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/11] OMAP2+: clockdomains: split the clkdm hwsup enable/disable function
Paul Walmsley p...@pwsan.com writes:
Split _omap2_clkdm_set_hwsup() into _disable_hwsup() and _enable_hwsup().
While here, also document that the autodeps are deprecated and that they
should be removed at the earliest opportunity.
Signed-off-by: Paul Walmsley p...@pwsan.com
[...]
@@ -222,28 +231,50 @@ static void _clkdm_del_autodeps(struct clockdomain
*clkdm)
}
}
-/*
- * _omap2_clkdm_set_hwsup - set the hwsup idle transition bit
+/**
+ * _enable_hwsup - set the hwsup idle transition bit
+ * @clkdm: struct clockdomain *
+ *
+ * XXX fix doco
hmm, 'doco' must be a new lingo I haven't learned yet.
+ * Internal helper for actually switching the bit that controls hwsup
+ * idle transitions for clkdm.
+ */
+static void _enable_hwsup(struct clockdomain *clkdm)
+{
+ u32 bits, v;
+
+ if (cpu_is_omap24xx())
+ bits = OMAP24XX_CLKSTCTRL_ENABLE_AUTO;
+ else if (cpu_is_omap34xx() || cpu_is_omap44xx())
+ bits = OMAP34XX_CLKSTCTRL_ENABLE_AUTO;
+ else
+ BUG();
+
+ bits = bits __ffs(clkdm-clktrctrl_mask);
+
+ v = __raw_readl(clkdm-clkstctrl_reg);
+ v = ~(clkdm-clktrctrl_mask);
+ v |= bits;
+ __raw_writel(v, clkdm-clkstctrl_reg);
+
+}
+
+/**
+ * _disable_hwsup - set the hwsup idle transition bit
* @clkdm: struct clockdomain *
- * @enable: int 0 to disable, 1 to enable
*
+ * XXX fix doco
here too
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: tidspbridge: remove file handling functions for loader
On Wed, Dec 8, 2010 at 5:08 PM, Greg KH g...@kroah.com wrote: On Wed, Dec 08, 2010 at 05:02:20PM -0600, Ramirez Luna, Omar wrote: Hi, On Wed, Dec 8, 2010 at 4:26 PM, Greg KH g...@kroah.com wrote: On Tue, Dec 07, 2010 at 12:09:06AM -0600, Omar Ramirez Luna wrote: Instead use request_firmware and friends to get a valid firmware image. Right now the image is supplied dynamically through udev and the following rule: KERNEL==omap-dsp, SUBSYSTEM==firmware, ACTION==add, \ RUN+=/bin/sh -c 'echo 1 /sys/$DEVPATH/loading; \ cat $FIRMWARE /sys/$DEVPATH/data; \ echo 0 /sys/$DEVPATH/loading' Why do you need a custom firmware rule? It was meant as an example, when I compiled my minimal file system it didn't supply the firmware.sh script nor created /lib/firmware... I thought that not everybody would have the firmware.sh, so I just provided a sample rule. So, can I remove this from the changelog comment, as it's not really needed at all? Yes it can be removed. BTW, I don't expect this pushed through staging yet, I need to include it to my branch first and then I'll send a pull request with the pile of patches. Sorry for the misunderstanding and thanks for the review. insmod bridgedriver.ko base_img=baseimage.dof Ick, why use a module parameter name at all? Why is this special and different from all other firmware users? They don't have to manually specify a file name, the driver does that. The thing is that there are N number of firmwares, e.g.: There is the official and usable firmware to play with multimedia baseimage.dof But there are also minimal firmwares to just ping or swap buffers with the dsp, when you just want to play around with basic features. Please fix up the patch to not require a module parameter, distros hate them, and users hate them even more. The driver is the one requiring the parameter (it was already this way), this patch doesn't introduce any parameter. I'll check what can be done and if nobody rejects I'll use the baseimage.dof as firmware by default. Regards, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/3] OMAP: Add opp data
Hi Nishanth, Nishanth Menon n...@ti.com writes: Major changes in V5: rebased to k.org 2.6.37-rc3 introduced omap_opp_data.h couple of whitespace and offline license suggestion cleanups OK, v5 looks good to me. One more minor minor detail. Can you post one more time with linux-arm-kernel in Cc so it doesn't have to be reposted before Tony merges it. Please also add in Paul's ack on patch 3. Thanks. Unless there are other objections, I'll pull the next rev into my pm-next and queue for 2.6.38. Note that as we go further with DVFS, we will likely need to expand this OPP data/table to include some more options, but that can be done when the time comes, so I'm OK with the current form for now. Thanks Nishanth, Kevin V4: http://marc.info/?l=linux-omapm=128993367112637w=2 V3: http://marc.info/?l=linux-omapm=128984926812800w=2 V2: http://marc.info/?t=12875366533r=1w=2 Kevin Hilman (1): OMAP3: remove OPP interfaces from OMAP PM layer Nishanth Menon (2): omap: opp: add OMAP3 OPP table data and common init omap4: opp: add OPP table data Documentation/arm/OMAP/omap_pm| 25 +++ arch/arm/mach-omap2/Kconfig |4 + arch/arm/mach-omap2/Makefile |6 ++ arch/arm/mach-omap2/io.c |3 +- arch/arm/mach-omap2/omap_opp_data.h | 72 +++ arch/arm/mach-omap2/opp.c | 93 + arch/arm/mach-omap2/opp3xxx_data.c| 107 + arch/arm/mach-omap2/opp4xxx_data.c| 57 +++ arch/arm/mach-omap2/pm.h | 14 arch/arm/plat-omap/include/plat/omap-pm.h | 31 +++-- arch/arm/plat-omap/omap-pm-noop.c | 11 +--- 11 files changed, 390 insertions(+), 33 deletions(-) create mode 100644 arch/arm/mach-omap2/omap_opp_data.h create mode 100644 arch/arm/mach-omap2/opp.c create mode 100644 arch/arm/mach-omap2/opp3xxx_data.c create mode 100644 arch/arm/mach-omap2/opp4xxx_data.c Bloat-o-meter report for omap2plus_defconfig Vs 2.6.37-rc3: add/remove: 22/3 grow/shrink: 4/3 up/down: 3149/-64 (3085) function old new delta opp_add- 568+568 opp_set_availability - 520+520 omap_init_opp_table- 328+328 omap34xx_opp_def_list - 208+208 static.__func__13783 13954+171 opp_find_freq_floor- 164+164 omap36xx_opp_def_list - 160+160 opp_find_freq_ceil - 144+144 opp_find_freq_exact- 128+128 find_device_opp- 124+124 opp_get_opp_count - 120+120 omap44xx_opp_def_list - 96 +96 opp_get_voltage- 76 +76 opp_get_freq - 76 +76 omap3_opp_init - 76 +76 dev_opp_list_lock - 72 +72 omap4_opp_init - 48 +48 vermagic 45 60 +15 linux_banner 133 148 +15 opp_enable - 8 +8 opp_disable- 8 +8 dev_opp_list - 8 +8 kernel_config_data 13899 13906 +7 __initcall_omap4_opp_init6 - 4 +4 __initcall_omap3_opp_init6 - 4 +4 omap_table_init- 1 +1 omap_pm_cpu_set_freq 28 24 -4 mpu_opps 4 - -4 l3_opps4 - -4 dsp_opps 4 - -4 omap_pm_if_early_init 20 8 -12 omap2_init_common_hw 464 428 -36 Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: tidspbridge: remove file handling functions for loader
On Wed, Dec 08, 2010 at 05:32:50PM -0600, Ramirez Luna, Omar wrote: On Wed, Dec 8, 2010 at 5:08 PM, Greg KH g...@kroah.com wrote: On Wed, Dec 08, 2010 at 05:02:20PM -0600, Ramirez Luna, Omar wrote: Hi, On Wed, Dec 8, 2010 at 4:26 PM, Greg KH g...@kroah.com wrote: On Tue, Dec 07, 2010 at 12:09:06AM -0600, Omar Ramirez Luna wrote: Instead use request_firmware and friends to get a valid firmware image. Right now the image is supplied dynamically through udev and the following rule: KERNEL==omap-dsp, SUBSYSTEM==firmware, ACTION==add, \ RUN+=/bin/sh -c 'echo 1 /sys/$DEVPATH/loading; \ cat $FIRMWARE /sys/$DEVPATH/data; \ echo 0 /sys/$DEVPATH/loading' Why do you need a custom firmware rule? It was meant as an example, when I compiled my minimal file system it didn't supply the firmware.sh script nor created /lib/firmware... I thought that not everybody would have the firmware.sh, so I just provided a sample rule. So, can I remove this from the changelog comment, as it's not really needed at all? Yes it can be removed. BTW, I don't expect this pushed through staging yet, I need to include it to my branch first and then I'll send a pull request with the pile of patches. Sorry for the misunderstanding and thanks for the review. Well, don't send me patches you don't want me to apply without a big DO NOT APPLY in them, otherwise I might try to :) insmod bridgedriver.ko base_img=baseimage.dof Ick, why use a module parameter name at all? Why is this special and different from all other firmware users? They don't have to manually specify a file name, the driver does that. The thing is that there are N number of firmwares, e.g.: There is the official and usable firmware to play with multimedia baseimage.dof But there are also minimal firmwares to just ping or swap buffers with the dsp, when you just want to play around with basic features. Then mess with the firmware symlink in userspace, don't have the driver have to worry about it. Please fix up the patch to not require a module parameter, distros hate them, and users hate them even more. The driver is the one requiring the parameter (it was already this way), this patch doesn't introduce any parameter. I'll check what can be done and if nobody rejects I'll use the baseimage.dof as firmware by default. That would be good. Again, you can put whatever firmware image you want in that location if you wish to use different ones. That is for userspace to do, not have the kernel worry about. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] OMAP2+: PM/serial: fix console semaphore acquire during suspend
On Wed, Dec 8, 2010 at 11:40 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
@@ -120,8 +133,9 @@ static void omap2_enter_full_retention(void)
goto no_sleep;
/* Block console output in case it is on one of the OMAP UARTs */
- if (try_acquire_console_sem())
- goto no_sleep;
+ if (!is_suspending())
+ if (try_acquire_console_sem())
+ goto no_sleep;
Combine into one if?
Hi Kevin,
snip
omap_uart_prepare_idle(0);
omap_uart_prepare_idle(1);
@@ -136,7 +150,8 @@ static void omap2_enter_full_retention(void)
omap_uart_resume_idle(1);
omap_uart_resume_idle(0);
- release_console_sem();
+ if (!is_suspending())
+ release_console_sem();
no_sleep:
if (omap2_pm_debug) {
@@ -284,6 +299,12 @@ out:
local_irq_enable();
}
+static int omap2_pm_begin(suspend_state_t state)
+{
+ suspend_state = state;
+ return 0;
+}
Do you really need a return code here?
static int omap2_pm_prepare(void)
{
/* We cannot sleep in idle until we have resumed */
@@ -333,10 +354,18 @@ static void omap2_pm_finish(void)
enable_hlt();
}
+static void omap2_pm_end(void)
+{
+ suspend_state = PM_SUSPEND_ON;
+ return;
+}
Redundant return.
+
static struct platform_suspend_ops omap_pm_ops = {
+ .begin = omap2_pm_begin,
.prepare = omap2_pm_prepare,
.enter = omap2_pm_enter,
.finish = omap2_pm_finish,
+ .end = omap2_pm_end,
.valid = suspend_valid_only_mem,
};
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 0ec8a04..648b8c5 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -50,6 +50,19 @@
#include sdrc.h
#include control.h
+#ifdef CONFIG_SUSPEND
+static suspend_state_t suspend_state = PM_SUSPEND_ON;
+static inline bool is_suspending(void)
+{
+ return (suspend_state != PM_SUSPEND_ON);
+}
+#else
+static inline bool is_suspending(void)
+{
+ return false;
+}
+#endif
+
/* Scratchpad offsets */
#define OMAP343X_TABLE_ADDRESS_OFFSET 0xc4
#define OMAP343X_TABLE_VALUE_OFFSET 0xc0
@@ -387,10 +400,11 @@ void omap_sram_idle(void)
}
/* Block console output in case it is on one of the OMAP UARTs */
- if (per_next_state PWRDM_POWER_ON ||
- core_next_state PWRDM_POWER_ON)
- if (try_acquire_console_sem())
- goto console_still_active;
+ if (!is_suspending())
+ if (per_next_state PWRDM_POWER_ON ||
+ core_next_state PWRDM_POWER_ON)
+ if (try_acquire_console_sem())
+ goto console_still_active;
Oh well, 3 nested ifs...
Thanks,
Vitaly
--
To unsubscribe from this list: send the line unsubscribe 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 05/11] OMAP2+: clockdomains: split the clkdm hwsup enable/disable function
On Wed, 8 Dec 2010, Kevin Hilman wrote: Paul Walmsley p...@pwsan.com writes: - * _omap2_clkdm_set_hwsup - set the hwsup idle transition bit +/** + * _enable_hwsup - set the hwsup idle transition bit + * @clkdm: struct clockdomain * + * + * XXX fix doco hmm, 'doco' must be a new lingo I haven't learned yet. Thanks, will fix these. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] OMAP: device: make rt_va easily avaialable to drivers
Patch OMAP: hwmod/device: add omap_{device, hwmod}_get_mpu_rt_va[1],
introduces omap_device_get_rt_va which is meant to be called
by drivers to retrieve the _mpu_rt_va, however this function
receives a pointer to an omap_device; since there is no
practical way for a driver to get this parameter without
fiddling with pdev and container_of macro, and omap_device code
already does this, it is better for it to handle this case.
Also moved header declaration to appear in the set of
functions to be used by drivers, as per the comment there.
[1] http://marc.info/?l=linux-omapm=127808467703366w=2
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h |3 +--
arch/arm/plat-omap/omap_device.c |8 ++--
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 28e2d1a..1877c1a 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -80,6 +80,7 @@ struct omap_device {
int omap_device_enable(struct platform_device *pdev);
int omap_device_idle(struct platform_device *pdev);
int omap_device_shutdown(struct platform_device *pdev);
+void __iomem *omap_device_get_rt_va(struct platform_device *pdev);
/* Core code interface */
@@ -101,8 +102,6 @@ struct omap_device *omap_device_build_ss(const char
*pdev_name, int pdev_id,
int omap_device_register(struct omap_device *od);
int omap_early_device_register(struct omap_device *od);
-void __iomem *omap_device_get_rt_va(struct omap_device *od);
-
/* OMAP PM interface */
int omap_device_align_pm_lat(struct platform_device *pdev,
u32 new_wakeup_lat_limit);
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index abe933c..9d11195 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -681,7 +681,7 @@ struct powerdomain *omap_device_get_pwrdm(struct
omap_device *od)
/**
* omap_device_get_mpu_rt_va - return the MPU's virtual addr for the hwmod base
- * @od: struct omap_device *
+ * @pdev: struct platform_device *
*
* Return the MPU's virtual address for the base of the hwmod, from
* the ioremap() that the hwmod code does. Only valid if there is one
@@ -690,8 +690,12 @@ struct powerdomain *omap_device_get_pwrdm(struct
omap_device *od)
* otherwise, passes along the return value from
* omap_hwmod_get_mpu_rt_va().
*/
-void __iomem *omap_device_get_rt_va(struct omap_device *od)
+void __iomem *omap_device_get_rt_va(struct platform_device *pdev)
{
+ struct omap_device *od;
+
+ od = _find_by_pdev(pdev);
+
if (od-hwmods_cnt != 1)
return NULL;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] OMAP: device: make rt_va easily avaialable to drivers
On Wed, Dec 8, 2010 at 5:54 PM, Omar Ramirez Luna omar.rami...@ti.com wrote:
Patch OMAP: hwmod/device: add omap_{device, hwmod}_get_mpu_rt_va[1],
introduces omap_device_get_rt_va which is meant to be called
by drivers to retrieve the _mpu_rt_va, however this function
receives a pointer to an omap_device; since there is no
practical way for a driver to get this parameter without
fiddling with pdev and container_of macro, and omap_device code
already does this, it is better for it to handle this case.
Also moved header declaration to appear in the set of
functions to be used by drivers, as per the comment there.
[1] http://marc.info/?l=linux-omapm=127808467703366w=2
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h | 3 +--
arch/arm/plat-omap/omap_device.c | 8 ++--
2 files changed, 7 insertions(+), 4 deletions(-)
This is a single patch set, please ignore the [1/6] subject :/
I'll resubmit to avoid confusions.
Regards,
Omar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: device: make rt_va easily avaialable to drivers
Patch OMAP: hwmod/device: add omap_{device, hwmod}_get_mpu_rt_va[1],
introduces omap_device_get_rt_va which is meant to be called
by drivers to retrieve the _mpu_rt_va, however this function
receives a pointer to an omap_device; since there is no
practical way for a driver to get this parameter without
fiddling with pdev and container_of macro, and omap_device code
already does this, it is better for it to handle this case.
Also moved header declaration to appear in the set of
functions to be used by drivers, as per the comment there.
[1] http://marc.info/?l=linux-omapm=127808467703366w=2
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h |3 +--
arch/arm/plat-omap/omap_device.c |8 ++--
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 28e2d1a..1877c1a 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -80,6 +80,7 @@ struct omap_device {
int omap_device_enable(struct platform_device *pdev);
int omap_device_idle(struct platform_device *pdev);
int omap_device_shutdown(struct platform_device *pdev);
+void __iomem *omap_device_get_rt_va(struct platform_device *pdev);
/* Core code interface */
@@ -101,8 +102,6 @@ struct omap_device *omap_device_build_ss(const char
*pdev_name, int pdev_id,
int omap_device_register(struct omap_device *od);
int omap_early_device_register(struct omap_device *od);
-void __iomem *omap_device_get_rt_va(struct omap_device *od);
-
/* OMAP PM interface */
int omap_device_align_pm_lat(struct platform_device *pdev,
u32 new_wakeup_lat_limit);
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index abe933c..9d11195 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -681,7 +681,7 @@ struct powerdomain *omap_device_get_pwrdm(struct
omap_device *od)
/**
* omap_device_get_mpu_rt_va - return the MPU's virtual addr for the hwmod base
- * @od: struct omap_device *
+ * @pdev: struct platform_device *
*
* Return the MPU's virtual address for the base of the hwmod, from
* the ioremap() that the hwmod code does. Only valid if there is one
@@ -690,8 +690,12 @@ struct powerdomain *omap_device_get_pwrdm(struct
omap_device *od)
* otherwise, passes along the return value from
* omap_hwmod_get_mpu_rt_va().
*/
-void __iomem *omap_device_get_rt_va(struct omap_device *od)
+void __iomem *omap_device_get_rt_va(struct platform_device *pdev)
{
+ struct omap_device *od;
+
+ od = _find_by_pdev(pdev);
+
if (od-hwmods_cnt != 1)
return NULL;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git.pwsan.com *_2.6.38 branches rebased to Tony's for-next branch
Hi, just a quick note to any users of the 2.6.38 branches on git.pwsan.com. hwmod_a_2.6.38 and pwrdm_prcm_a_2.6.38 have been updated to base on Tony's for-next branch. pwrdm_prcm_b_2.6.38 has been updated to base on pwrdm_prcm_a_2.6.38 due to dependencies. And wdt_2.6.38 has been updated to base on hwmod_a_2.6.38 due to dependencies. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] usb: otg: Kconfig: Add Kconfig option for TWL6030 transceiver.
Hi, On Wed, Dec 8, 2010 at 9:35 PM, Sergei Shtylyov sshtyl...@mvista.com wrote: Hello. Hema HK wrote: Added the TWL6030-usb transceiver option in the Kconfig Signed-off-by: Hema HK hem...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: David Brownell dbrown...@users.sourceforge.net [...] Index: linux-2.6/drivers/usb/otg/Kconfig === --- linux-2.6.orig/drivers/usb/otg/Kconfig +++ linux-2.6/drivers/usb/otg/Kconfig @@ -59,6 +59,18 @@ config TWL4030_USB This transceiver supports high and full speed devices plus, in host mode, low speed. +config TWL6030_USB + tristate TWL6030 USB Transceiver Driver + depends on TWL4030_CORE + select USB_OTG_UTILS + help + Enable this to support the USB OTG transceiver on TWL6030 + family chips. This TWL6030 transceiver has the VBUS and ID GND + and OTG SRP events capabilities. For all other transceiver functionality + UTMI PHY is embedded in OMAP4430.The internal PHY configurations APIs ^^ Space missing after period. I will fix it. Regards, Hema 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 5/7] usb: musb: TWL6030: Selecting TWL6030_USB transceiver
On Wed, Dec 8, 2010 at 9:33 PM, Sergei Shtylyov sshtyl...@mvista.com wrote: Hello. Hema HK wrote: Selecting the twl6030-usb for OMAP4430SDP and OMAP4 PANDA board and adding OMAP4 internal phy code for compilation Signed-off-by: Hema HK hem...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: Tony Lindgren t...@atomide.com [...] Index: linux-2.6/drivers/usb/musb/Kconfig === --- linux-2.6.orig/drivers/usb/musb/Kconfig +++ linux-2.6/drivers/usb/musb/Kconfig @@ -12,6 +12,7 @@ config USB_MUSB_HDRC depends on (ARM || (BF54x !BF544) || (BF52x !BF522 !BF523)) select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) select TWL4030_USB if MACH_OMAP_3430SDP + select TWL6030_USB if (MACH_OMAP_3430SDP || MACH_OMAP4_PANDA) Parens are not necessary. Though the previous code uses them... OK. Regards, Hema 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
