Re: [PATCH v3] ARM: OMAP: board-ldp: add regulator info to get the microSD slot working again
Tony, can this to into git?
regards,
Koen
Op 2 apr 2009, om 20:58 heeft David Brownell het volgende geschreven:
Ack on that v3 patch, FWIW ... but also:
On Tuesday 31 March 2009, Koen Kooi wrote:
+static const struct twl4030_resconfig ldp_resconfig[] = {
+ /* disable regulators that u-boot left enabled; the
+* devices' drivers should be managing these.
+*/
+ { .resource = RES_VMMC1, },
+ { 0, },
+};
+
Purely for information -- as in, maybe *more* regulators should
be disabled -- here's a patch I tend to run with. Obviously it's
better to set the resconfig stuff than to do what this originally
tried to do, but this predates resconfig.
All this does (now) is print some messages that highlight when
regulators end up in wierd states after initialization.
- Dave
===
--- a/drivers/regulator/twl4030-regulator.c
+++ b/drivers/regulator/twl4030-regulator.c
@@ -39,6 +39,9 @@ struct twlreg_info {
/* FIXED_LDO voltage */
u8 deciV;
+ /* true iff regulator is set up for Linux*/
+ boolin_use;
+
/* voltage in mV = table[VSEL]; table_len must be a power-of-two */
u8 table_len;
const u16 *table;
@@ -419,6 +422,8 @@ static struct twlreg_info twl4030_regs[]
/* VUSBCP is managed *only* by the USB subchip */
};
+static bool is_4030;
+
static int twl4030reg_probe(struct platform_device *pdev)
{
int i;
@@ -430,6 +435,8 @@ static int twl4030reg_probe(struct platf
for (i = 0, info = NULL; i < ARRAY_SIZE(twl4030_regs); i++) {
if (twl4030_regs[i].desc.id != pdev->id)
continue;
+ if (pdev->id == TWL4030_REG_VAUX2_4030)
+ is_4030 = true;
info = twl4030_regs + i;
break;
}
@@ -458,6 +465,8 @@ static int twl4030reg_probe(struct platf
}
platform_set_drvdata(pdev, rdev);
+ info->in_use = true;
+
/* NOTE: many regulators support short-circuit IRQs (presentable
* as REGULATOR_OVER_CURRENT notifications?) configured via:
* - SC_CONFIG
@@ -469,6 +478,64 @@ static int twl4030reg_probe(struct platf
return 0;
}
+/*
+ * Make sure all LDOs are in the P1 (Linux) group or none; and that
+ * if Linux can't have enabled them, they're in no group (disabled).
+ * Unused-but-enabled LDOs are a constant power drain.
+ *
+ * NOTE: something else must disable LDOs which Linux manages, but
+ * which may have been wrongly enabled during system startup.
+ */
+static __init int twl4030_ldo_tweak(void)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(twl4030_regs); i++) {
+ struct twlreg_info *info = &twl4030_regs[i];
+ int dev_grp, new_grp;
+ int status;
+
+ /* ignore the "other" VAUX2 descriptor */
+ if (info->base == 0x1b) {
+ if (info->desc.id == TWL4030_REG_VAUX2_4030) {
+ if (!is_4030)
+ continue;
+ } else {
+ if (is_4030)
+ continue;
+ }
+ }
+
+ dev_grp = twl4030reg_read(info, VREG_GRP);
+ if (dev_grp < 0)
+ continue;
+ dev_grp &= 0xf0;
+
+ if (info->in_use)
+ new_grp = dev_grp & (P1_GRP | WARM_CFG);
+ else
+ new_grp = 0;
+ if (dev_grp == new_grp)
+ continue;
+
+ /* reset and report this; the bootloader might be fixable */
+#if 0
+ status = twl4030reg_write(info, VREG_GRP, new_grp);
+#else
+ status = 0;
+#endif
+ if (status < 0)
+ pr_err("TWL: can't update LDO %s, err %d\n",
+ info->desc.name, status);
+ else
+ pr_info("TWL: LDO %s, dev_grp %02x --> %02x\n",
+ info->desc.name, dev_grp, new_grp);
+
+ }
+ return 0;
+}
+late_initcall(twl4030_ldo_tweak);
+
static int __devexit twl4030reg_remove(struct platform_device *pdev)
{
regulator_unregister(platform_get_drvdata(pdev));
--
To unsubscribe from this list: send the line "unsubscribe linux-
omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
PGP.sig
Description: Dit deel van het bericht is digitaal ondertekend
Re: [PATCH] OMAP3: PM: Add the wakeup source driver, v3
Hi Kevin,
Have you had chance to review this new version of wakeup driver? :)
Regards,
Kyuwon
On Fri, Apr 3, 2009 at 7:43 PM, Kim Kyuwon wrote:
> Sometimes, it is necessary to find out "what does wake up my board
> from suspend?". Notifying wake-up source feature may be used to blame
> unexpected wake-up events which increase power consumption. And user
> mode applications can act smartly according to the wake-up event from
> Suspend-to-RAM state to minimize power consumption. Note that this
> driver can't inform wake-up events from idle state. This driver uses
> sysfs interface to give information to user mode applications like:
>
> cat /sys/power/omap_resume_irq
> cat /sys/power/omap_resume_event
>
> This driver also privides the unified GPIO wake-up source
> configuration. specific GPIO settings in the board files are:
>
> /* Wakeup source configuration */
> static struct gpio_wake boardname_gpio_wake[] = {
>{ 23, IRQF_TRIGGER_RISING,"BT_WAKEUP",1},
>{ 24, IRQF_TRIGGER_RISING,"USB_DETECT", 1},
> };
>
> static struct omap_wake_platform_data boardname_wake_data = {
>.gpio_wakes = boardname_gpio_wake,
>.gpio_wake_num = ARRAY_SIZE(boardname_gpio_wake),
> };
>
> static struct platform_device boardname_wakeup = {
>.name = "omap-wake",
>.id = -1,
>.dev= {
>.platform_data = &boardname_wake_data,
>},
> };
>
> The patch adds Kconfig options "OMAP34xx wakeup source support" under
> "System type"->"TI OMAP implementations" menu.
>
> Signed-off-by: Kim Kyuwon
> ---
> arch/arm/mach-omap2/Makefile |1 +
> arch/arm/mach-omap2/irq.c | 21 +-
> arch/arm/mach-omap2/prcm-common.h |4 +
> arch/arm/mach-omap2/prm-regbits-34xx.h |5 +
> arch/arm/mach-omap2/wake34xx.c | 681
>
> arch/arm/plat-omap/Kconfig |9 +
> arch/arm/plat-omap/include/mach/irqs.h |4 +
> arch/arm/plat-omap/include/mach/wake.h | 30 ++
> 8 files changed, 752 insertions(+), 3 deletions(-)
> create mode 100644 arch/arm/mach-omap2/wake34xx.c
> create mode 100644 arch/arm/plat-omap/include/mach/wake.h
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index e693efd..4d7dbca 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -25,6 +25,7 @@ obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
> obj-$(CONFIG_ARCH_OMAP24XX)+= sleep24xx.o
> obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
> obj-$(CONFIG_PM_DEBUG) += pm-debug.o
> +obj-$(CONFIG_OMAP_WAKE)+= wake34xx.o
> endif
>
> # SmartReflex driver
> diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
> index 700fc3d..18ac725 100644
> --- a/arch/arm/mach-omap2/irq.c
> +++ b/arch/arm/mach-omap2/irq.c
> @@ -33,9 +33,6 @@
> #define INTC_MIR_SET0 0x008c
> #define INTC_PENDING_IRQ0 0x0098
>
> -/* Number of IRQ state bits in each MIR register */
> -#define IRQ_BITS_PER_REG 32
> -
> /*
> * OMAP2 has a number of different interrupt controllers, each interrupt
> * controller is identified as its own "bank". Register definitions are
> @@ -193,6 +190,24 @@ int omap_irq_pending(void)
>return 0;
> }
>
> +void omap_get_pending_irqs(u32 *pending_irqs, unsigned len)
> +{
> + int i, j = 0;
> +
> + for (i = 0; i < ARRAY_SIZE(irq_banks); i++) {
> + struct omap_irq_bank *bank = irq_banks + i;
> + int irq;
> +
> + for (irq = 0; irq < bank->nr_irqs && j < len;
> + irq += IRQ_BITS_PER_REG) {
> + int offset = irq & (~(IRQ_BITS_PER_REG - 1));
> +
> + pending_irqs[j++] = intc_bank_read_reg(bank,
> + (INTC_PENDING_IRQ0 + offset));
> + }
> + }
> +}
> +
> void __init omap_init_irq(void)
> {
>unsigned long nr_of_irqs = 0;
> diff --git a/arch/arm/mach-omap2/prcm-common.h
> b/arch/arm/mach-omap2/prcm-common.h
> index cb1ae84..1f340aa 100644
> --- a/arch/arm/mach-omap2/prcm-common.h
> +++ b/arch/arm/mach-omap2/prcm-common.h
> @@ -273,6 +273,10 @@
> #define OMAP3430_ST_D2D_SHIFT 3
> #define OMAP3430_ST_D2D_MASK (1 << 3)
>
> +/* PM_WKST3_CORE, CM_IDLEST3_CORE shared bits */
> +#define OMAP3430_ST_USBTLL_SHIFT 2
> +#define OMAP3430_ST_USBTLL_MASK(1 << 2)
> +
> /* CM_FCLKEN_WKUP, CM_ICLKEN_WKUP, PM_WKEN_WKUP shared bits */
> #define OMAP3430_EN_GPIO1 (1 << 3)
> #define OMAP3430_EN_GPIO1_SHIFT3
> diff --git a/arch/arm/mach-omap2/prm-regbits-34xx.h
> b/arch/arm/mach-omap2/prm-regbits-34xx.h
> index 0
Re: YUV rotation support for DSS2 - 2.6.29 [WAS Re: Hello Tomi Valkeinen, I have some questions about dss2 driver.]
Hi Hardik,
Thanks for fixing up the patch. I can confirm that YUV rotation is
fine and patches are ready to be merged -- although the attached fix
is needed as well for the userspace layer to know the correct row
strides when writing YUV to the framebuffer.
I'm still having VID1_FIFO_UNDERFLOW errors when I try to play rotated
video on plane 1 and plane 0 is rotated as well. Do you have any ideas
how to debug this further?
Thanks,
Tim
> Hi Tomi,
> If YUV rotation with frame buffer passes can you please review the patch and
> merge it to your latest.
>
> Regards,
> Hardik
From 4ba3f8b1d2feef00ac6c8de827262d255cebb185 Mon Sep 17 00:00:00 2001
From: Tim Yamin
Date: Mon, 13 Apr 2009 13:57:42 -0700
Subject: [PATCH] DSS2: OMAPFB: Set line_length correctly for YUV with VRFB.
Signed-off-by: Tim Yamin
---
drivers/video/omap2/omapfb/omapfb-main.c | 30 +-
1 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 9043265..675a7c9 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -377,10 +377,19 @@ void set_fb_fix(struct fb_info *fbi)
fbi->screen_base = (char __iomem *)omapfb_get_region_vaddr(ofbi);
/* used by mmap in fbmem.c */
- if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB)
- fix->line_length =
- (OMAP_VRFB_LINE_LEN * var->bits_per_pixel) >> 3;
- else
+ if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
+ switch (var->nonstd) {
+ case OMAPFB_COLOR_YUV422:
+ case OMAPFB_COLOR_YUY422:
+ fix->line_length =
+(OMAP_VRFB_LINE_LEN * var->bits_per_pixel) >> 2;
+ break;
+ default:
+ fix->line_length =
+(OMAP_VRFB_LINE_LEN * var->bits_per_pixel) >> 3;
+ break;
+ }
+ } else
fix->line_length =
(var->xres_virtual * var->bits_per_pixel) >> 3;
fix->smem_start = omapfb_get_region_paddr(ofbi);
@@ -689,7 +698,18 @@ static int omapfb_setup_overlay(struct fb_info *fbi, struct omap_overlay *ovl,
goto err;
}
- screen_width = fix->line_length / (var->bits_per_pixel >> 3);
+ switch (var->nonstd) {
+ case OMAPFB_COLOR_YUV422:
+ case OMAPFB_COLOR_YUY422:
+ if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
+ screen_width = fix->line_length
+/ (var->bits_per_pixel >> 2);
+ break;
+ }
+ default:
+ screen_width = fix->line_length / (var->bits_per_pixel >> 3);
+ break;
+ }
ovl->get_overlay_info(ovl, &info);
--
1.5.6.3
RE: YUV rotation support for DSS2 - 2.6.29 [WAS Re: Hello Tomi Valkeinen, I have some questions about dss2 driver.]
Hi, > -Original Message- > From: plasma...@gmail.com [mailto:plasma...@gmail.com] On Behalf Of Tim Yamin > Sent: Wednesday, April 08, 2009 12:31 AM > To: Shah, Hardik > Cc: grego...@gentil.com; tomi.valkei...@nokia.com; linux-omap@vger.kernel.org; > beaglebo...@googlegroups.com > Subject: Re: YUV rotation support for DSS2 - 2.6.29 [WAS Re: Hello Tomi > Valkeinen, I have some questions about dss2 driver.] > > Hi Hardik / Tomi, > > > [Shah, Hardik] I have also patched the DSS to support the DSS YUV rotation. > Here the rotation type is passed to know the type of rotation required by > driver. I have also modified the FBDEV driver to use this patch. Please find > the both patches. I have tested it on the old master of tomi. Commit id is > 4261fafc4fdc0730b3d4dd83c036d8be09ec8575. I am planning to rebase it on the > latest master soon. I have tested the FBDEV driver with different rotation and > resolution settings. Hi Tim, I have done few changes to your patch. - else if (bytespp == 2) + width >>= 1; Will not work for 32 bit formats like ARGB or RGB24u. Secondly I have fixed lot many check patch warnings/errors in your patch. So please do that before providing patches. Third I have implemented VRFB mirroring also. I have tested YUV, UYVY, RGB24u, RGB16, and ARGB on V4L2 driver with rotation and mirroring with different resolutions on LCD and its working fine. Tim, Will you please test the YUV rotation with frame buffer driver with the attached patch and let us know the result. I have tested RGB rotation and its working fine. Hi Tomi, If YUV rotation with frame buffer passes can you please review the patch and merge it to your latest. Regards, Hardik > > I've merged my changes with your patches and rebased against master, > please find the new patch attached. [Shah, Hardik] Hi Tim, I have modified your DSS2 rotation patch to make it more generic to support YUV as well as ARGB32 and RGB24u formats. > > > [Shah, Hardik] In past I saw setting the FIFO size eliminates this problem. > I have some FIFO setting can you please try this out and let me know the > result. > > FIFO_HIGH_THRES = 0x3FC and GFX_FIFO_LOW_THRES = 0x3BC. This I tried in on > OMAP3. > > Tried this (see attached patch) but does not help -- still getting > these errors as soon as I try to play a video: > > omapdss DISPC error: VID1_FIFO_UNDERFLOW, disabling VID1 > omapdss DISPC error: SYNC_LOST, disabling LCD > > The FIFOs are configured as follows: > > omapdss DISPC: fifo(0) size 1024, low/high old 3008/3071, new 956/1020 > omapdss DISPC: fifo(1) size 1024, low/high old 956/1020, new 956/1020 > > Cheers, > > Tim 0002-DSS2-OMAPFB-Added-support-for-the-YUV-VRFB-rotatio.patch Description: 0002-DSS2-OMAPFB-Added-support-for-the-YUV-VRFB-rotatio.patch 0001-DSS2-VRFB-rotation-and-mirroring-implemented.patch Description: 0001-DSS2-VRFB-rotation-and-mirroring-implemented.patch
