No OMAP PM code on the PM branch???
I'm looking through Kevin's PM branch, and I've done a quick-port of 2.6.30-rc1 to Logic's OMAP3530 LV SOM starting with the rk21 board code, and "echo mem > /sys/power/state" does nothing. Worse, "cat /sys/power/state" doesn't show anything. This is due to no code calling suspend_set_ops() which used to be in arch/arm/mach-omap2/pm34xx.c - this isn't in either Tony or Kevin's current tree. 1) Am I way off base (i.e. am I missing something obvious here)? -- Peter Barada -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Anyone have MUSB working on PM branch?
All,
I'm trying to get OTG to work using the latest PM branch (created by
cloning
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git,
commit ID 12323321f004c9e83061c9a9d06046b050d6d4c77).
I started with the rk51 board, and brought up serial, ethernet for
NFSroot, added the following to setup the OTG MUX
arch/arm/mach-omap2/mux.c:
// MUSB port 0
MUX_CFG_34XX("T28_3430_USB0HS_PHY_CLK", 0x1a2,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLDOWN)
MUX_CFG_34XX("T25_3430_USB0HS_PHY_STP", 0x1a4,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLDOWN)
MUX_CFG_34XX("R28_3430_USB0HS_PHY_DIR", 0x1a6,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLDOWN)
MUX_CFG_34XX("T26_3430_USB0HS_PHY_NXT", 0x1a8,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLDOWN)
MUX_CFG_34XX("T27_3430_USB0HS_PHY_D0", 0x1aa,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLDOWN)
MUX_CFG_34XX("U28_3430_USB0HS_PHY_D1", 0x1ac,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLDOWN)
MUX_CFG_34XX("U27_3430_USB0HS_PHY_D2", 0x1ae,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLDOWN)
MUX_CFG_34XX("U26_3430_USB0HS_PHY_D3", 0x1b0,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLDOWN)
MUX_CFG_34XX("U25_3430_USB0HS_PHY_D4", 0x1b2,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLDOWN)
MUX_CFG_34XX("V28_3430_USB0HS_PHY_D5", 0x1b4,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLDOWN)
MUX_CFG_34XX("V27_3430_USB0HS_PHY_D6", 0x1b6,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLDOWN)
MUX_CFG_34XX("V26_3430_USB0HS_PHY_D7", 0x1b8,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLDOWN)
The following is called before usb_musb_init in the board file:
// Initialize the mux for the MUSB
static void musb_mux_init(void)
{
/* Port 0 */
omap_cfg_reg(T28_3430_USB0HS_PHY_CLK);
omap_cfg_reg(T25_3430_USB0HS_PHY_STP);
omap_cfg_reg(R28_3430_USB0HS_PHY_DIR);
omap_cfg_reg(T26_3430_USB0HS_PHY_NXT);
omap_cfg_reg(T27_3430_USB0HS_PHY_D0);
omap_cfg_reg(U28_3430_USB0HS_PHY_D1);
omap_cfg_reg(U27_3430_USB0HS_PHY_D2);
omap_cfg_reg(U26_3430_USB0HS_PHY_D3);
omap_cfg_reg(U25_3430_USB0HS_PHY_D4);
omap_cfg_reg(V28_3430_USB0HS_PHY_D5);
omap_cfg_reg(V27_3430_USB0HS_PHY_D6);
omap_cfg_reg(V26_3430_USB0HS_PHY_D7);
}
And I verified that it is indeed called(fromn the log):
MUX: setup T28_3430_USB0HS_PHY_CLK (0xd80021a2): 0x0108 -> 0x0108
MUX: setup T25_3430_USB0HS_PHY_STP (0xd80021a4): 0x0118 -> 0x0108
MUX: setup R28_3430_USB0HS_PHY_DIR (0xd80021a6): 0x0108 -> 0x0108
MUX: setup T26_3430_USB0HS_PHY_NXT (0xd80021a8): 0x0108 -> 0x0108
MUX: setup T27_3430_USB0HS_PHY_D0 (0xd80021aa): 0x0108 -> 0x0108
MUX: setup U28_3430_USB0HS_PHY_D1 (0xd80021ac): 0x0108 -> 0x0108
MUX: setup U27_3430_USB0HS_PHY_D2 (0xd80021ae): 0x0108 -> 0x0108
MUX: setup U26_3430_USB0HS_PHY_D3 (0xd80021b0): 0x0108 -> 0x0108
MUX: setup U25_3430_USB0HS_PHY_D4 (0xd80021b2): 0x0108 -> 0x0108
MUX: setup V28_3430_USB0HS_PHY_D5 (0xd80021b4): 0x0114 -> 0x0108
MUX: setup V27_3430_USB0HS_PHY_D6 (0xd80021b6): 0x0108 -> 0x0108
MUX: setup V26_3430_USB0HS_PHY_D7 (0xd80021b8): 0x0108 -> 0x0108
And setup the MUSB in host mode(relevant part of .config):
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_DEVICE_CLASS=y
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set
CONFIG_USB_OTG_WHITELIST=y
CONFIG_USB_OTG_BLACKLIST_HUB=y
CONFIG_USB_MON=y
# CONFIG_USB_WUSB is not set
# CONFIG_USB_WUSB_CBAF is not set
#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
# CONFIG_USB_EHCI_HCD is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_HWA_HCD is not set
CONFIG_USB_MUSB_HDRC=y
CONFIG_USB_MUSB_SOC=y
#
# OMAP 343x high speed USB support
#
CONFIG_USB_MUSB_HOST=y
# CONFIG_USB_MUSB_PERIPHERAL is not set
# CONFIG_USB_MUSB_OTG is not set
# CONFIG_USB_GADGET_MUSB_HDRC is not set
CONFIG_USB_MUSB_HDRC_HCD=y
CONFIG_MUSB_PIO_ONLY=y
CONFIG_USB_MUSB_DEBUG=y
#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set
#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#
#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=y
CONFIG_USB_STORAGE_DEBUG=y
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not
Re: [PATCH] onenand_init: Allow disabling sync read and write based on flags, v2 (Re: [PATCH 1/4] onenand init: Rename board-n800-flash.c to gpmc-onenand.c)
* Tony Lindgren [090430 11:56]:
> * Tony Lindgren [090430 07:06]:
> > * vimal singh [090429 23:33]:
> > > 'gpmc-onenand.c' is still confusing name. This is not going to used in
> > > all boards anyway.
> >
> > Why do you think this cannot be used for all boards?
> >
> > The GPMC timings are totally based on the onenand chip features.
>
> And these two patches make omap3430sdp to work with the gpmc-onenand
> code. Sync mode does not work, but it seems like it was never enabled
> for sdp anyways.
>
> Similar patch should work for other boards too.
Setting the sync_write depends on flags and processor, not just flags.
Here's a fixed version of this patch.
Tony
>From 7c9f55ca7dcf9768fee7128fab5f5cf3cacc1e21 Mon Sep 17 00:00:00 2001
From: Tony Lindgren
Date: Thu, 30 Apr 2009 11:43:19 -0700
Subject: [PATCH] onenand_init: Allow disabling sync read and write based on flags, v2
Allow disabling sync read and write based on flags
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c
index fc79183..4583c79 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -86,15 +86,18 @@ static void omap2_onenand_writew(unsigned short value, void __iomem *addr)
}
static void set_onenand_cfg(void __iomem *onenand_base, int latency,
- int sync_write, int hf)
+int sync_read, int sync_write, int hf)
{
u32 reg;
reg = omap2_onenand_readw(onenand_base + ONENAND_REG_SYS_CFG1);
reg &= ~((0x7 << ONENAND_SYS_CFG1_BRL_SHIFT) | (0x7 << 9));
reg |= (latency << ONENAND_SYS_CFG1_BRL_SHIFT) |
- ONENAND_SYS_CFG1_SYNC_READ |
ONENAND_SYS_CFG1_BL_16;
+ if (sync_read)
+ reg |= ONENAND_SYS_CFG1_SYNC_READ;
+ else
+ reg &= ~ONENAND_SYS_CFG1_SYNC_READ;
if (sync_write)
reg |= ONENAND_SYS_CFG1_SYNC_WRITE;
else
@@ -106,8 +109,9 @@ static void set_onenand_cfg(void __iomem *onenand_base, int latency,
omap2_onenand_writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
}
-static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
- int freq)
+static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
+ void __iomem *onenand_base,
+ int freq)
{
struct gpmc_timings t;
const int t_cer = 15;
@@ -118,9 +122,19 @@ static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
const int t_wph = 30;
int min_gpmc_clk_period, t_ces, t_avds, t_avdh, t_ach, t_aavdh, t_rdyo;
int tick_ns, div, fclk_offset_ns, fclk_offset, gpmc_clk_ns, latency;
- int err, ticks_cez, sync_write = 0, first_time = 0, hf = 0;
+ int err, ticks_cez, sync_read, sync_write, first_time = 0, hf = 0;
+ int cs = cfg->cs;
u32 reg;
+ if (cfg->flags & ONENAND_DIS_SYNC_READ)
+ sync_read = 0;
+ else
+ sync_read = 1;
+ if (cpu_is_omap24xx() || (cfg->flags & ONENAND_DIS_SYNC_WRITE))
+ sync_write = 0;
+ else
+ sync_write = 1;
+
if (!freq) {
/* Very first call freq is not known */
err = omap2_onenand_set_async_mode(cs, onenand_base);
@@ -160,8 +174,6 @@ static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
t_ach = 6;
t_aavdh = 6;
t_rdyo = 9;
- if (cpu_is_omap34xx())
- sync_write = 1;
break;
case 66:
min_gpmc_clk_period = 15; /* 66 MHz */
@@ -171,8 +183,6 @@ static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
t_ach = 6;
t_aavdh = 6;
t_rdyo = 11;
- if (cpu_is_omap34xx())
- sync_write = 1;
break;
default:
min_gpmc_clk_period = 18; /* 54 MHz */
@@ -182,6 +192,7 @@ static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
t_ach = 9;
t_aavdh = 7;
t_rdyo = 15;
+ sync_write = 0;
break;
}
@@ -198,7 +209,8 @@ static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
latency = 4;
if (first_time)
- set_onenand_cfg(onenand_base, latency, sync_write, hf);
+ set_onenand_cfg(onenand_base, latency,
+ sync_read, sync_write, hf);
if (div == 1) {
reg = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG2);
@@ -272,7 +284,7 @@ static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1,
GPMC_CONFIG1_WRAPBURST_SUPP |
GPMC_CONFIG1_READMULTIPLE_SUPP |
- GPMC_CONFIG1_READTYPE_SYNC |
+ (sync_read ? GPMC_CONFIG1_READTYPE_SYNC : 0) |
(sync_write ? GPMC_CONFIG1_WRITEMULTIPLE_SUPP : 0) |
(sync_write ? GPMC_CONFIG1_WRITETYPE_SYNC : 0) |
GPMC_CONFIG1_CLKACTIVATIONTIME(fclk_offset) |
@@ -288,7 +300,7 @@ static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
if (err)
return err;
- set_onenand_cfg(onenand_base, latency, sync_write, hf);
+ set_onenand_cfg(onenand_base, latency, sync_read, sync_write, hf);
return 0;
}
@@ -298,7 +310,7 @@ static int gpmc_onenand_setup(void __iomem *onenand_base, int freq)
struct device *dev = &gpmc_onenand_device.dev;
/* Set sync timings in GPMC */
- if (omap2_onenand_set_sync_mode(gpmc_onenand_data->cs
[PATCH] mmc-twl4030: use correct controller in twl_mmc23_set_power
twl_mmc23_set_power() has MMC2 twl_mmc_controller hardcoded in it, which
breaks MMC3. Find the right controller to use instead.
Signed-off-by: Grazvydas Ignotas
Cc: David Brownell
---
arch/arm/mach-omap2/mmc-twl4030.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
b/arch/arm/mach-omap2/mmc-twl4030.c
index 46d6e9b..9928e72 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -263,8 +263,19 @@ static int twl_mmc1_set_power(struct device *dev, int
slot, int power_on,
static int twl_mmc23_set_power(struct device *dev, int slot, int power_on, int
vdd)
{
int ret = 0;
- struct twl_mmc_controller *c = &hsmmc[1];
+ struct twl_mmc_controller *c = NULL;
struct omap_mmc_platform_data *mmc = dev->platform_data;
+ int i;
+
+ for (i = 1; i < ARRAY_SIZE(hsmmc); i++) {
+ if (mmc == hsmmc[i].mmc) {
+ c = &hsmmc[i];
+ break;
+ }
+ }
+
+ if (c == NULL)
+ return -ENODEV;
/* If we don't see a Vcc regulator, assume it's a fixed
* voltage always-on regulator.
--
1.5.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LDP support
Op 29 apr 2009 om 00:42 heeft Tony Lindgren het volgende geschreven:\ * Russell King - ARM Linux [090428 15:07]: Tony, et.al., Any ideas when more LDP support will be pushed into mainline (such as the framebuffer support)? I'll be looking at the board-*.c patches for the next merge window hopefully this week or next week. Looks like LDP keyboard, touchscreen The ts is pretty much unusable in 2.6.29, haven't tried .30rc yet Regards, Koen & RTC are pretty much ready to go. Then the MMC has some regulator updates, but AFAIK the MMC should work OK already. For the framebuffer, Imre and Tomi know the status the best, so I've added them to Cc. Imre has been meaning to send a bunch of drivers/video/omap changes to the fbdev list for a while now and LDP framebuffer may depend on those. Imre, any news on the status of sending the fb patches upstream? Then there are the upcoming DSS patches from Tomi, but those still need some work before they're ready to go. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux- omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
