Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
On Sun, May 11, 2014 at 4:42 PM, Tony Lindgren t...@atomide.com wrote: * Andreas Müller schnitzelt...@googlemail.com [140509 14:07]: On Fri, May 9, 2014 at 9:38 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 30/04/14 02:52, Tony Lindgren wrote: Otherwise we can get often errors like the following and the display won't come on: omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay omapdss APPLY error: SYNC_LOST on channel lcd, restarting the output with video overlays disabled There are some earlier references to this issue: http://www.spinics.net/lists/linux-omap/msg59511.html http://www.spinics.net/lists/linux-omap/msg59724.html resend - my client had HTML enabled... FWIW: I have had issues long time ago [1]. With mainline 3.14.3 I had still the reboot problem on old 600MHz OMAP 3530. Applying this patch solved the issues. For other versions I had no chance to reproduce the original wakup issue mentioned in old thread Sorry I'm a bit confused now. Is the reboot issue a separate issue related to the twl4030 generic scripts for 3530? And then this patch fixes dm3730 wake-up (from suspend?) issues? Or do we have some other bug where we wrongly hit omap3630_dss_feats on 3530 somehow? (What I think) I have done: Have 3.14.3 still booting with legacy board init (please don't kill me for that). Without applying your patch old OMAP3530 crashed at every reboot with SYNCH_LOST. After applying your patch reboot works fine. Looking into id-code makes me wonder what changes on 36xx-features do to 35xx devices (treated as 34xx - right?). The only way that this happens is for unknown hawkeye fallthough. I suggest you simply forget my note and I will find out what really 'fixed' dss reboot problem. Andreas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
On Fri, May 9, 2014 at 9:38 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 30/04/14 02:52, Tony Lindgren wrote:
Otherwise we can get often errors like the following and the
display won't come on:
omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
omapdss APPLY error: SYNC_LOST on channel lcd, restarting
the output with video overlays disabled
There are some earlier references to this issue:
http://www.spinics.net/lists/linux-omap/msg59511.html
http://www.spinics.net/lists/linux-omap/msg59724.html
resend - my client had HTML enabled...
FWIW: I have had issues long time ago [1]. With mainline 3.14.3 I had
still the reboot problem on old 600MHz OMAP 3530. Applying this patch
solved the issues. For other versions I had no chance to reproduce the
original wakup issue mentioned in old thread
[1] http://marc.info/?l=linux-omapm=136250904607413w=2
Andreas
Those don't sound like the same issue, but it's hard to say. What kind
of clock rates do you get? Cat you paste debugfs/omapdss/clk, with and
without this patch?
What resolution do you have? If it's a very high resolution (say, DVI
output to a monitor), it could just be an issue of
not-enough-memory-bandwidth.
It seems that it's safe to set the lower values even for 3630.
If we can confirm that 3630 works with the higher values
reliably we can add further detection.
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/video/fbdev/omap2/dss/dss.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dss.c
b/drivers/video/fbdev/omap2/dss/dss.c
index d55266c..ad6561f 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats
__initconst = {
.dpi_select_source = dss_dpi_select_source_omap2_omap3,
};
+/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */
static const struct dss_features omap3630_dss_feats __initconst = {
- .fck_div_max= 32,
- .dss_fck_multiplier = 1,
+ .fck_div_max= 16,
+ .dss_fck_multiplier = 2,
These values tell about the clock hardware, they are not settings that
can be changed to change the clock. OMAP3630 has a fixed x2 multiplier
and a divider with maximum value of 16.
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 1/5] mmc: omap_hsmmc: Enable SDIO interrupt
On Mon, Apr 28, 2014 at 9:40 AM, Andreas Fenkart afenk...@gmail.com wrote:
@@ -2201,11 +2346,16 @@ static int omap_hsmmc_suspend(struct device *dev)
pm_runtime_get_sync(host-dev);
if (!(host-mmc-pm_flags MMC_PM_KEEP_POWER)) {
- omap_hsmmc_disable_irq(host);
+ OMAP_HSMMC_WRITE(host-base, ISE, 0);
+ OMAP_HSMMC_WRITE(host-base, IE, 0);
+ OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, HCTL,
OMAP_HSMMC_READ(host-base, HCTL) ~SDBP);
}
+ if (host-wake_irq !(host-mmc-pm_flags MMC_PM_WAKE_SDIO_IRQ))
+ disable_irq(host-wake_irq);
+
if (host-dbclk)
clk_disable_unprepare(host-dbclk);
@@ -2231,6 +2381,9 @@ static int omap_hsmmc_resume(struct device *dev)
omap_hsmmc_protect_card(host);
+ if (host-wake_irq !(host-mmc-pm_flags MMC_PM_WAKE_SDIO_IRQ))
+ enable_irq(host-wake_irq);
+
pm_runtime_mark_last_busy(host-dev);
pm_runtime_put_autosuspend(host-dev);
return 0;
Maybe I misunderstand something here but shouldn't
disable_irq/enable_irq be swapped here?
regards
Andreas
--
To unsubscribe from this list: send the line unsubscribe 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 v10 1/5] mmc: omap_hsmmc: Enable SDIO interrupt
On Mon, Apr 28, 2014 at 9:40 AM, Andreas Fenkart afenk...@gmail.com wrote:
There have been various patches floating around for enabling
the SDIO IRQ for hsmmc, but none of them ever got merged.
Probably the reason for not merging the SDIO interrupt patches
has been the lack of wake-up path for SDIO on some omaps that
has also needed remuxing the SDIO DAT1 line to a GPIO making
the patches complex.
This patch adds the minimal SDIO IRQ support to hsmmc for
omaps that do have the wake-up path. For those omaps, the
DAT1 line need to have the wake-up enable bit set, and the
wake-up interrupt is the same as for the MMC controller.
This patch has been tested on am3730 es1.2 with mwifiex
connected to MMC3 with mwifiex waking to Ethernet traffic
from off-idle mode. Note that for omaps that do not have
the SDIO wake-up path, this patch will not work for idle
modes and further patches for remuxing DAT1 to GPIO are
needed.
Based on earlier patches [1][2] by David Vrabel
david.vra...@csr.com, Steve Sakoman st...@sakoman.com
For now, only support SDIO interrupt if we are booted with
a separate wake-irq configued via device tree. This is
because omaps need the wake-irq for idle states, and some
omaps need special quirks. And we don't want to add new
legacy mux platform init code callbacks any longer as we
are moving to DT based booting anyways.
To use it, you need to specify the wake-irq using the
interrupts-extended property.
[1]
http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux.git;a=commitdiff_plain;h=010810d22f6f49ac03da4ba384969432e0320453
[2] http://comments.gmane.org/gmane.linux.kernel.mmc/20446
Cc: Balaji T K balaj...@ti.com
Signed-off-by: Andreas Fenkart afenk...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 272e0ee..700fb91 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -29,6 +29,7 @@
#include linux/timer.h
#include linux/clk.h
#include linux/of.h
+#include linux/of_irq.h
#include linux/of_gpio.h
#include linux/of_device.h
#include linux/omap-dma.h
@@ -36,6 +37,7 @@
#include linux/mmc/core.h
#include linux/mmc/mmc.h
#include linux/io.h
+#include linux/irq.h
#include linux/gpio.h
#include linux/regulator/consumer.h
#include linux/pinctrl/consumer.h
@@ -106,6 +108,7 @@
#define TC_EN (1 1)
#define BWR_EN (1 4)
#define BRR_EN (1 5)
+#define CIRQ_EN(1 8)
#define ERR_EN (1 15)
#define CTO_EN (1 16)
#define CCRC_EN(1 17)
@@ -140,7 +143,6 @@
#define VDD_3V0300 /* 30 uV */
#define VDD_165_195(ffs(MMC_VDD_165_195) - 1)
-#define AUTO_CMD23 (1 1)/* Auto CMD23 support */
/*
* One controller can have multiple slots, like on some omap boards using
* omap.c controller driver. Luckily this is not currently done on any known
@@ -194,6 +196,7 @@ struct omap_hsmmc_host {
u32 sysctl;
u32 capa;
int irq;
+ int wake_irq;
int use_dma, dma_ch;
struct dma_chan *tx_chan;
struct dma_chan *rx_chan;
@@ -206,6 +209,9 @@ struct omap_hsmmc_host {
int req_in_progress;
unsigned long clk_rate;
unsigned intflags;
+#define AUTO_CMD23 (1 0)/* Auto CMD23 support */
+#define HSMMC_SDIO_IRQ_ENABLED (1 1)/* SDIO irq enabled */
+#define HSMMC_WAKE_IRQ_ENABLED (1 2)
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
};
@@ -510,27 +516,40 @@ static void omap_hsmmc_stop_clock(struct
omap_hsmmc_host *host)
static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
struct mmc_command *cmd)
{
- unsigned int irq_mask;
+ u32 irq_mask = INT_EN_MASK;
+ unsigned long flags;
if (host-use_dma)
- irq_mask = INT_EN_MASK ~(BRR_EN | BWR_EN);
- else
- irq_mask = INT_EN_MASK;
+ irq_mask = ~(BRR_EN | BWR_EN);
/* Disable timeout for erases */
if (cmd-opcode == MMC_ERASE)
irq_mask = ~DTO_EN;
+ spin_lock_irqsave(host-irq_lock, flags);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+
+ /* latch pending CIRQ, but don't signal MMC core */
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
+ spin_unlock_irqrestore(host-irq_lock, flags);
}
static void omap_hsmmc_disable_irq(struct
Re: omapdss wakeup issues
On Tue, Mar 5, 2013 at 7:44 PM, Andreas Müller schnitzelt...@googlemail.com wrote: On Fri, Mar 1, 2013 at 10:07 PM, Andreas Müller schnitzelt...@googlemail.com wrote: On Thu, Feb 28, 2013 at 5:27 PM, Andreas Müller schnitzelt...@googlemail.com wrote: Hi, I am preparing 3.8 mainline for gumstix overo and have the following issue: waking Monitor connected by HDMI from power save makes Monitor complain for unsupported frequency and console says: | omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay Is this a known issue? Sorry for the noise but this is the only issue I have with 3.8.1 stable (currently). Some further notes: * with old OMAP 3530 (only 600MHz capable) the HDMI does not work for warm restart and not for pressing reset. The only way out is power-off / power on. This I saw with 3.6 the first time but I did not follow it at that time. * My kernel command line is console=ttyO2,115200n8 mpurate=800 vram=12M omapfb.mode=dvi:1280x1024MR-24@60 omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait I added omapdss.debug=y and omapdss.debug=1 but that did give me further information. Are there other settings available helping to debug this? * I attached kernel config and bootlog for proper start - maybe this gives some hint. * Monitor power down is caused by XFCE power management Is there any other information I can give to solve this? FWIW DM3730 (Overo fire storm) the wakeup causes some additional warning omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay [ cut here ] WARNING: at drivers/video/omap2/dss/dispc.c:543 dispc_mgr_go+0x20/0x54() Modules linked in: libertas_sdio libertas lib80211 cfg80211 rfkill ads7846 gpio_keys [c001254c] (unwind_backtrace+0x0/0xe0) from [c002e7fc] (warn_slowpath_common+0x4c/0x64) [c002e7fc] (warn_slowpath_common+0x4c/0x64) from [c002e82c] (warn_slowpath_null+0x18/0x1c) [c002e82c] (warn_slowpath_null+0x18/0x1c) from [c0370cc0] (dispc_mgr_go+0x20/0x54) [c0370cc0] (dispc_mgr_go+0x20/0x54) from [c037a900] (dispc_error_worker+0x6c/0x18c) [c037a900] (dispc_error_worker+0x6c/0x18c) from [c004667c] (process_one_work+0x1fc/0x3dc) [c004667c] (process_one_work+0x1fc/0x3dc) from [c0046c08] (worker_thread+0x238/0x34c) [c0046c08] (worker_thread+0x238/0x34c) from [c004ad08] (kthread+0xa0/0xb0) [c004ad08] (kthread+0xa0/0xb0) from [c000d938] (ret_from_fork+0x14/0x3c) ---[ end trace 40fcd9df3dd2aaf5 ]--- Andreas FWIW taken on DM3730 @ 800MHz 1. All OK root@overo:~# cat /sys/kernel/debug/omapdss/dispc_irq period 34640 ms irqs 0 FRAMEDONE 0 VSYNC 0 EVSYNC_EVEN 0 EVSYNC_ODD0 ACBIAS_COUNT_STAT 0 PROG_LINE_NUM 0 GFX_FIFO_UNDERFLOW0 GFX_END_WIN 0 PAL_GAMMA_MASK0 OCP_ERR 0 VID1_FIFO_UNDERFLOW 0 VID1_END_WIN 0 VID2_FIFO_UNDERFLOW 0 VID2_END_WIN 0 SYNC_LOST 0 SYNC_LOST_DIGIT 0 WAKEUP0 2. Monitor off cat /sys/kernel/debug/omapdss/dispc_irq period 652843 ms irqs 1 FRAMEDONE 1 VSYNC 1 EVSYNC_EVEN 0 EVSYNC_ODD0 ACBIAS_COUNT_STAT 0 PROG_LINE_NUM 1 GFX_FIFO_UNDERFLOW0 GFX_END_WIN 1 PAL_GAMMA_MASK0 OCP_ERR 0 VID1_FIFO_UNDERFLOW 0 VID1_END_WIN 0 VID2_FIFO_UNDERFLOW 0 VID2_END_WIN 0 SYNC_LOST 0 SYNC_LOST_DIGIT 0 WAKEUP1 3. Wakeup root@overo:~# omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay cat /sys/kernel/debug/omapdss/dispc_irq period 42140 ms irqs 1 FRAMEDONE 0 VSYNC 0 EVSYNC_EVEN 0 EVSYNC_ODD0 ACBIAS_COUNT_STAT 0 PROG_LINE_NUM 1 GFX_FIFO_UNDERFLOW1 GFX_END_WIN 0 PAL_GAMMA_MASK0 OCP_ERR 0 VID1_FIFO_UNDERFLOW 0 VID1_END_WIN 0 VID2_FIFO_UNDERFLOW 0 VID2_END_WIN 0 SYNC_LOST 0 SYNC_LOST_DIGIT 0 WAKEUP0 Is there some other information which might be helpful to solve this? Andreas -- To unsubscribe from this list: send the line unsubscribe 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] board-overo.c: enable TWL4030 power off
On Mon, Mar 4, 2013 at 8:00 PM, Tony Lindgren t...@atomide.com wrote:
* Andreas Müller schnitzelt...@googlemail.com [130228 04:50]:
Can you please add a description here? Preferrably something
like With commit XYZ overo poweroff stopped working. Fix this
by blah blah blah so this can be queued as a fix.
Regards,
Tony
Signed-off-by: Andreas Müller schnitzelt...@googlemail.com
---
arch/arm/mach-omap2/board-overo.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 86bab51..b975c72 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -418,9 +418,14 @@ static struct regulator_init_data overo_vmmc1 = {
.consumer_supplies = overo_vmmc1_supply,
};
+static struct twl4030_power_data overo_power_data = {
+ .use_poweroff = true,
+};
+
static struct twl4030_platform_data overo_twldata = {
.gpio = overo_gpio_data,
.vmmc1 = overo_vmmc1,
+ .power = overo_power_data,
};
static int __init overo_i2c_init(void)
--
AFAIK this has never been implemented mainline. Up to now I used a
patch from Steve Sakoman implementing the commands for TWL to shut
down - but this was never sent here and is no more required with TWL
framework.
I will send V2 with more descriptive commit message till end of week.
Andreas
--
To unsubscribe from this list: send the line unsubscribe 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] board-overo.c: enable TWL4030 power off
On Mon, Mar 4, 2013 at 8:00 PM, Tony Lindgren t...@atomide.com wrote:
* Andreas Müller schnitzelt...@googlemail.com [130228 04:50]:
Can you please add a description here? Preferrably something
like With commit XYZ overo poweroff stopped working. Fix this
by blah blah blah so this can be queued as a fix.
Regards,
Tony
Signed-off-by: Andreas Müller schnitzelt...@googlemail.com
---
arch/arm/mach-omap2/board-overo.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 86bab51..b975c72 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -418,9 +418,14 @@ static struct regulator_init_data overo_vmmc1 = {
.consumer_supplies = overo_vmmc1_supply,
};
+static struct twl4030_power_data overo_power_data = {
+ .use_poweroff = true,
+};
+
static struct twl4030_platform_data overo_twldata = {
.gpio = overo_gpio_data,
.vmmc1 = overo_vmmc1,
+ .power = overo_power_data,
};
static int __init overo_i2c_init(void)
--
Sorry for the noise but I am newbie here and have one question:
Against which branch should patches send here be based on. Up to now I
used Linus' mainline branch - is that OK?
Andreas
--
To unsubscribe from this list: send the line unsubscribe 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: omapdss wakeup issues
On Fri, Mar 1, 2013 at 10:07 PM, Andreas Müller schnitzelt...@googlemail.com wrote: On Thu, Feb 28, 2013 at 5:27 PM, Andreas Müller schnitzelt...@googlemail.com wrote: Hi, I am preparing 3.8 mainline for gumstix overo and have the following issue: waking Monitor connected by HDMI from power save makes Monitor complain for unsupported frequency and console says: | omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay Is this a known issue? Sorry for the noise but this is the only issue I have with 3.8.1 stable (currently). Some further notes: * with old OMAP 3530 (only 600MHz capable) the HDMI does not work for warm restart and not for pressing reset. The only way out is power-off / power on. This I saw with 3.6 the first time but I did not follow it at that time. * My kernel command line is console=ttyO2,115200n8 mpurate=800 vram=12M omapfb.mode=dvi:1280x1024MR-24@60 omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait I added omapdss.debug=y and omapdss.debug=1 but that did give me further information. Are there other settings available helping to debug this? * I attached kernel config and bootlog for proper start - maybe this gives some hint. * Monitor power down is caused by XFCE power management Is there any other information I can give to solve this? FWIW DM3730 (Overo fire storm) the wakeup causes some additional warning omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay [ cut here ] WARNING: at drivers/video/omap2/dss/dispc.c:543 dispc_mgr_go+0x20/0x54() Modules linked in: libertas_sdio libertas lib80211 cfg80211 rfkill ads7846 gpio_keys [c001254c] (unwind_backtrace+0x0/0xe0) from [c002e7fc] (warn_slowpath_common+0x4c/0x64) [c002e7fc] (warn_slowpath_common+0x4c/0x64) from [c002e82c] (warn_slowpath_null+0x18/0x1c) [c002e82c] (warn_slowpath_null+0x18/0x1c) from [c0370cc0] (dispc_mgr_go+0x20/0x54) [c0370cc0] (dispc_mgr_go+0x20/0x54) from [c037a900] (dispc_error_worker+0x6c/0x18c) [c037a900] (dispc_error_worker+0x6c/0x18c) from [c004667c] (process_one_work+0x1fc/0x3dc) [c004667c] (process_one_work+0x1fc/0x3dc) from [c0046c08] (worker_thread+0x238/0x34c) [c0046c08] (worker_thread+0x238/0x34c) from [c004ad08] (kthread+0xa0/0xb0) [c004ad08] (kthread+0xa0/0xb0) from [c000d938] (ret_from_fork+0x14/0x3c) ---[ end trace 40fcd9df3dd2aaf5 ]--- Andreas -- To unsubscribe from this list: send the line unsubscribe 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: omapdss wakeup issues
On Fri, Mar 1, 2013 at 2:25 PM, Matthias Brugger matthias@gmail.com wrote: Hi Andreas, 2013/2/28 Andreas Müller schnitzelt...@googlemail.com: Hi, I am preparing 3.8 mainline for gumstix overo and have the following issue: waking Monitor connected by HDMI from power save makes Monitor complain for unsupported frequency and console says: | omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay Is this a known issue? I'm not sure if it's the same issue, but you might give it a shot. The problem is, that when changing the CPU frequency in OMAP3530, the frequency of L3 is changed. This frequency is used in DSS. The result is a fifo underflow on gfx. First check, if you use some dynamic cpufreq governor, which might be changing the frequency. A workaround (although not very nice) is to set fixed l3_main values in mach-omap2/opp3xxx_data.c Best regards, Matthias I have gouvernor 'performance' selected which AFAIK keeps frequency at maximum. Some more details in another mail which I already prepared. Andreas -- To unsubscribe from this list: send the line unsubscribe 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] board-overo.c: enable TWL4030 power off
Signed-off-by: Andreas Müller schnitzelt...@googlemail.com
---
arch/arm/mach-omap2/board-overo.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 86bab51..b975c72 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -418,9 +418,14 @@ static struct regulator_init_data overo_vmmc1 = {
.consumer_supplies = overo_vmmc1_supply,
};
+static struct twl4030_power_data overo_power_data = {
+ .use_poweroff = true,
+};
+
static struct twl4030_platform_data overo_twldata = {
.gpio = overo_gpio_data,
.vmmc1 = overo_vmmc1,
+ .power = overo_power_data,
};
static int __init overo_i2c_init(void)
--
1.7.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.6-rc4
On Wed, Sep 5, 2012 at 5:44 PM, Paul Walmsley p...@pwsan.com wrote: Here are some basic boot and power management test results for v3.6-rc4: http://www.pwsan.com/omap/testlogs/test_v3.6-rc4/20120904122415/ Some observations: * N800: panics during kernel init - This is caused by an MMC driver bug; fixed by [PATCH] MMC: OMAP MSDI: fix broken PIO mode, available from here: http://www.spinics.net/lists/arm-kernel/msg190879.html * CM-T3517: L3 in-band error with USB OTG during boot - Cause unknown; longstanding issue; does not occur on the 3517EVM * 37xx EVM: CORE not entering dynamic off-idle - Cause unknown; dynamic retention-idle seems to work; system suspend to off works * 4430ES2 Panda: CORE, L4PER, L3INIT, TESLA, IVAHD not going idle - Cause unknown; may be partially due to McPDM reset problem (The objective in posting these is to determine what is and isn't working in the mainline releases, as well as to make it easier to determine what is fixed or is broken by subsequent series that use this as a base.) I did not find that - maybe I missed something: Could you also store the resulting configs of theses tests? Andreas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
