[PATCH] Provide the set_power at TWL4030 MMC
Custom board powered by VAUX2 and VAUX4 for MMC instead of VMMC
Also it uses VMMC for MMC core power not voltage.
MMC1: uses VMMC1(voltage) and VMMC2(Vdd)
MMC2: uses VAUX2(voltage) and VAUX4(Vdd)
To address this issue, platform uses its custom power function.
Signed-off-by: Kyungmin Park <[EMAIL PROTECTED]>
---
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
b/arch/arm/mach-omap2/mmc-twl4030.c
index 626d668..571b7b0 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -27,28 +27,6 @@
#if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
-#define LDO_CLR0x00
-#define VSEL_S2_CLR0x40
-
-#define VMMC1_DEV_GRP 0x27
-#define VMMC1_CLR 0x00
-#define VMMC1_315V 0x03
-#define VMMC1_300V 0x02
-#define VMMC1_285V 0x01
-#define VMMC1_185V 0x00
-#define VMMC1_DEDICATED0x2A
-
-#define VMMC2_DEV_GRP 0x2B
-#define VMMC2_CLR 0x40
-#define VMMC2_315V 0x0c
-#define VMMC2_300V 0x0b
-#define VMMC2_285V 0x0a
-#define VMMC2_260V 0x08
-#define VMMC2_185V 0x06
-#define VMMC2_DEDICATED0x2E
-
-#define VMMC_DEV_GRP_P10x20
-
static u16 control_pbias_offset;
static u16 control_devconf1_offset;
@@ -385,14 +363,21 @@ void __init hsmmc_init(struct twl4030_hsmmc_info
*controllers)
/* NOTE: we assume OMAP's MMC1 and MMC2 use
* the TWL4030's VMMC1 and VMMC2, respectively;
* and that OMAP's MMC3 isn't used.
+* or provided by a platform.
*/
switch (c->mmc) {
case 1:
- mmc->slots[0].set_power = twl_mmc1_set_power;
+ if (c->set_power)
+ mmc->slots[0].set_power = c->set_power;
+ else
+ mmc->slots[0].set_power = twl_mmc1_set_power;
break;
case 2:
- mmc->slots[0].set_power = twl_mmc2_set_power;
+ if (c->set_power)
+ mmc->slots[0].set_power = c->set_power;
+ else
+ mmc->slots[0].set_power = twl_mmc2_set_power;
break;
default:
pr_err("MMC%d configuration not supported!\n", c->mmc);
diff --git a/arch/arm/mach-omap2/mmc-twl4030.h
b/arch/arm/mach-omap2/mmc-twl4030.h
index e2d58a2..25a08ed 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.h
+++ b/arch/arm/mach-omap2/mmc-twl4030.h
@@ -6,12 +6,55 @@
* published by the Free Software Foundation.
*/
+#define VAUX2_DEV_GRP 0x1B
+#define VAUX2_315V 0x0C
+#define VAUX2_300V 0x0B
+#define VAUX2_285V 0x0A
+#define VAUX2_260V 0x08
+#define VAUX2_185V 0x06
+#define VAUX2_180V 0x05
+#define VAUX2_DEDICATED0x1E
+
+#define VAUX4_DEV_GRP 0x23
+#define VAUX4_315V 0x0C
+#define VAUX4_300V 0x0B
+#define VAUX4_285V 0x0A
+#define VAUX4_260V 0x08
+#define VAUX4_185V 0x06
+#define VAUX4_DEDICATED0x26
+
+#define VAUX_DEV_GRP_P10x20
+
+#define LDO_CLR0x00
+#define VSEL_S2_CLR0x40
+
+#define VMMC1_DEV_GRP 0x27
+#define VMMC1_CLR 0x00
+#define VMMC1_315V 0x03
+#define VMMC1_300V 0x02
+#define VMMC1_285V 0x01
+#define VMMC1_185V 0x00
+#define VMMC1_DEDICATED0x2A
+
+#define VMMC2_DEV_GRP 0x2B
+#define VMMC2_CLR 0x00
+#define VMMC2_315V 0x0c
+#define VMMC2_300V 0x0b
+#define VMMC2_285V 0x0a
+#define VMMC2_260V 0x08
+#define VMMC2_185V 0x06
+#define VMMC2_DEDICATED0x2E
+
+#define VMMC_DEV_GRP_P10x20
+
struct twl4030_hsmmc_info {
u8 mmc;/* controller 1/2/3 */
u8 wires; /* 1/4/8 wires */
int gpio_cd;/* or -EINVAL */
int gpio_wp;/* or -EINVAL */
int ext_clock:1;/* use external pin for input clock */
+ int (*set_power)(struct device *dev, int slot,
+ int power_on, int vdd);
};
#ifdefined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE) || \
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: ARM : OMAP: Pass logical DMA channel number always to callback handlers
> -Original Message- > From: Jarkko Nikula [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 26, 2008 6:05 PM > To: Shilimkar, Santosh > Cc: Tony Lindgren; linux-omap@vger.kernel.org > Subject: Re: ARM : OMAP: Pass logical DMA channel number > always to callback handlers > > On Wed, 26 Nov 2008 16:26:42 +0530 > "ext Shilimkar, Santosh" <[EMAIL PROTECTED]> wrote: > > > > As commit log says, user can pass the chain_id via > callback data if > > > needed. > > Yes there are few ways you can achieve this if you don't > want to pass the chain_id as part of the callback. But in > that case the 'omap_request_dma_chain' callback signature > should have been also cleaned ( 'ch' instead of 'chain_id'). > > > Ah, yeah, then it was missing from my patch and have to send a patch > changing it. > > > >I think chained dma callback may also find more use > > > for logical channel number than chain_id e.g. when > modifying the transfer > > > parameters etc. > > When user wants to use chaining,they expects that the chain > internals ( free channel allocation etc) should be managed by > DMA library. So even user wants to modify the parameters, it > can directly use 'omap_modify_dma_chain_params' api and just > provide 'chain_id'. For which channel the parameters should > be changed will be decided by the DMA library internally > depending on free channels from chain. > > > This approach doesn't work e.g. with audio. Let's assume you > would like > to use DMA chaining with ALSA (been there, done that, until found a > better solution. See sound/soc/omap-pcm.c). Don't know how alsa frameworks works but looking at code, it seems this was done when omap DMA version were not supporting chaining. But even after chaining is available it's not been updated.That's a different topic anyways. > ALSA application may ask to use e.g. 100 periods, which is more than > n.o. logical DMA channels in OMAP so chain length is have to > be shorter > than n.o. periods. Which then means that channel parameters > are have to > modify while the chain is running. Not sure about the above scenario's practicality. How much is 'one' period in terms bytes. Is there requirement that for one period , you need a dedicated DMA channel for a transfer. I don't understand how you arrived at above conlcusion. > omap_modify_dma_chain_params is setting parameters for all channels in > a chain, and more over, function header of it says "Dont do this while > dma is running!!". Firstly I don't understand why you want to use 'omap_modify_dma_chain_params' when chain is active. Above example you have given is not telling me how I end in a situation of modifying chanining parametsr. In normal case,you can very much program the transfer related parameters using 'omap_dma_chain_a_transfer' which will find out free channel and queue it. > > > And uniform, smaller API set is always better than bloated one. > > This change any way don't reduce a single API so not sure > what you mean by 'smaller API set is always better than > bloated one'. It may reduce a callback for a user in > > > IMO, API is a one step bigger if DMA callback has different arguments > depending is it in non-chained vs. chained configuration. > > So I still don't see a real benefit of this patch. Because > of above mentioned reasons I think we should revert this patch. > > > Probably you would like to show/share opposite example? Not exactly. But I want to see that the chaining feature should be used as it is intended and supported by design. Because if user wants to manage the programming of free channels then it is as good as , user implements it's own chaining. This can be done with normal DMA APIs as well. :-) > > Jarkko > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add OMAP2 camera driver
Hi Hans, > > 1) The makefile isn't right: it compiles omap24xxcam.c and > omap24xxcam-dma.c as two modules, but I suspect you want only one since > the symbols that omap24xxcam.c needs from omap24xxcam-dma.c are not > exported. See e.g. the msp3400 driver in the Makefile for how to do it. I will make this change. > > 2) The Kconfig is probably missing a ARCH_OMAP dependency (sounds > reasonable, at least), so now it also compiles for the i686 but that > architecture doesn't have a clk_get function. I will add this dependency. > > 3) I was wondering whether Sakari also wants to add a Signed-off-by > line? Looking at the comments it seems that he was involved as well. I CCed from the first e-mail, so that he can review and give Signed-off-by to this patch. > > 4) I get a bunch of compile warnings (admittedly when compiling for > i686) that you might want to look at. Compiled against the 2.6.27 > kernel with gcc-4.3.1. It might be bogus since I didn't compile for the > omap architecture. I will update my toolchain to gcc-4.3.x for ARM and see if it generates the warnings like below. But I think we are fine once we add ARCH_OMAP dependency to this driver. Thanks for the review comments. I will resubmit the patch. -- ---Trilok Soni http://triloksoni.wordpress.com http://www.linkedin.com/in/triloksoni -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] extra module resets to ensure full-chip idle
Dirk Behme <[EMAIL PROTECTED]> writes: > Kevin Hilman wrote: >> Various bootloaders have been known to leave modules in a state >> which prevents full-chip retention. > > Does it make sense to check if > > [PATCH 1/5] OMAP3: PM: HSMMC: force MMC module reset on boot > [PATCH 2/5] OMAP3: PM: Force IVA2 into idle during bootup > > can be done in U-Boot, too? If yes, I would have a look to it. Yes, ideally u-boot or whatever bootloader isused should be leaving these modules in a known reset/idle state. However, there are many bootloaders for many platforms out there so until there is some sort of standard on bootloaders, I think the kernel will have to ensure this is done. Kevin > >> This series forces >> MMC, IVA2 and D2D/modem into known reset/idle states so that >> the OMAP3 can hit full-chip idle. >> >> Tested on OMAP3 Beagle, and custom OMAP3 hardware. >> >> NOTE: this is similar to the set I posted for the PM branch >> but this series is rebased onto linux-omap and includes >> the MMC reset. >> >> Kevin Hilman (5): >> OMAP3: PM: HSMMC: force MMC module reset on boot >> OMAP3: PM: Force IVA2 into idle during bootup >> OMAP3: PM: Add D2D clocks and auto-idle setup to PRCM init >> OMAP3: PM: D2D clockdomain supports SW supervised transitions >> OMAP3: PM: Ensure modem is reset during PRCM init >> >> arch/arm/mach-omap2/clock34xx.h | 37 +- >> arch/arm/mach-omap2/clockdomains.h|2 +- >> arch/arm/mach-omap2/cm-regbits-34xx.h | 14 + >> arch/arm/mach-omap2/devices.c | 76 >> + >> arch/arm/mach-omap2/pm34xx.c | 65 - >> arch/arm/plat-omap/include/mach/control.h |5 ++ >> 6 files changed, 195 insertions(+), 4 deletions(-) >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-omap" in >> the body of a message to [EMAIL PROTECTED] >> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] extra module resets to ensure full-chip idle
Kevin Hilman wrote: Various bootloaders have been known to leave modules in a state which prevents full-chip retention. Does it make sense to check if [PATCH 1/5] OMAP3: PM: HSMMC: force MMC module reset on boot [PATCH 2/5] OMAP3: PM: Force IVA2 into idle during bootup can be done in U-Boot, too? If yes, I would have a look to it. Regards Dirk This series forces MMC, IVA2 and D2D/modem into known reset/idle states so that the OMAP3 can hit full-chip idle. Tested on OMAP3 Beagle, and custom OMAP3 hardware. NOTE: this is similar to the set I posted for the PM branch but this series is rebased onto linux-omap and includes the MMC reset. Kevin Hilman (5): OMAP3: PM: HSMMC: force MMC module reset on boot OMAP3: PM: Force IVA2 into idle during bootup OMAP3: PM: Add D2D clocks and auto-idle setup to PRCM init OMAP3: PM: D2D clockdomain supports SW supervised transitions OMAP3: PM: Ensure modem is reset during PRCM init arch/arm/mach-omap2/clock34xx.h | 37 +- arch/arm/mach-omap2/clockdomains.h|2 +- arch/arm/mach-omap2/cm-regbits-34xx.h | 14 + arch/arm/mach-omap2/devices.c | 76 + arch/arm/mach-omap2/pm34xx.c | 65 - arch/arm/plat-omap/include/mach/control.h |5 ++ 6 files changed, 195 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2.6.28-rc6-omap-git 2/2] twl4030-usb: get rid of OMAP1 OTG hooks
From: David Brownell <[EMAIL PROTECTED]>
Remove incomplete/broken support for OMAP1 OTG controller.
Update the otg.state field in some more code paths.
Let IRQ logic handle PHY suspend/resume.
Fix an unlikely memory leak.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/i2c/chips/twl4030-usb.c | 75 --
1 file changed, 17 insertions(+), 58 deletions(-)
--- a/drivers/i2c/chips/twl4030-usb.c
+++ b/drivers/i2c/chips/twl4030-usb.c
@@ -34,7 +34,7 @@
#include
#include
#include
-#include
+
/* Register defines */
@@ -234,19 +234,6 @@
#define GPIO_USB_4PIN_ULPI_2430C (3 << 0)
-/* bits in OTG_CTRL */
-#defineOTG_XCEIV_OUTPUTS \
- (OTG_ASESSVLD|OTG_BSESSEND|OTG_BSESSVLD|OTG_VBUSVLD|OTG_ID)
-#defineOTG_XCEIV_INPUTS \
- (OTG_PULLDOWN|OTG_PULLUP|OTG_DRV_VBUS|OTG_PD_VBUS|OTG_PU_VBUS|OTG_PU_ID)
-#defineOTG_CTRL_BITS \
- (OTG_A_BUSREQ|OTG_A_SETB_HNPEN|OTG_B_BUSREQ|OTG_B_HNPEN|OTG_BUSDROP)
- /* and OTG_PULLUP is sometimes written */
-
-#defineOTG_CTRL_MASK (OTG_DRIVER_SEL| \
- OTG_XCEIV_OUTPUTS|OTG_XCEIV_INPUTS| \
- OTG_CTRL_BITS)
-
enum linkstat {
USB_LINK_UNKNOWN = 0,
@@ -371,6 +358,10 @@ static enum linkstat twl4030_usb_linksta
dev_dbg(twl->dev, "HW_CONDITIONS 0x%02x/%d; link %d\n",
status, status, linkstat);
+ /* REVISIT this assumes host and peripheral controllers
+* are registered, and that both are active...
+*/
+
spin_lock_irq(&twl->lock);
twl->linkstat = linkstat;
if (linkstat == USB_LINK_ID) {
@@ -397,13 +388,12 @@ static void twl4030_usb_set_mode(struct
FUNC_CTRL_XCVRSELECT_MASK |
FUNC_CTRL_OPMODE_MASK);
break;
-/*
- case T2_USB_MODE_CEA2011_3PIN:
- twl4030_cea2011_3_pin_FS_setup(twl);
+ case -1:
+ /* FIXME: power on defaults */
break;
-*/
default:
- /* FIXME: power on defaults */
+ dev_err(twl->dev, "unsupported T2 transceiver mode %d\n",
+ mode);
break;
};
}
@@ -577,30 +567,14 @@ static int twl4030_set_peripheral(struct
struct usb_gadget *gadget)
{
struct twl4030_usb *twl;
- u32 l;
if (!x)
return -ENODEV;
twl = xceiv_to_twl(x);
-
- if (!gadget) {
- omap_writew(0, OTG_IRQ_EN);
- twl4030_phy_suspend(twl, 1);
- twl->otg.gadget = NULL;
-
- return -ENODEV;
- }
-
twl->otg.gadget = gadget;
- twl4030_phy_resume(twl);
-
- l = omap_readl(OTG_CTRL) & OTG_CTRL_MASK;
- l &= ~(OTG_XCEIV_OUTPUTS|OTG_CTRL_BITS);
- l |= OTG_ID;
- omap_writel(l, OTG_CTRL);
-
- twl->otg.state = OTG_STATE_B_IDLE;
+ if (!gadget)
+ twl->otg.state = OTG_STATE_UNDEFINED;
return 0;
}
@@ -613,24 +587,9 @@ static int twl4030_set_host(struct otg_t
return -ENODEV;
twl = xceiv_to_twl(x);
-
- if (!host) {
- omap_writew(0, OTG_IRQ_EN);
- twl4030_phy_suspend(twl, 1);
- twl->otg.host = NULL;
-
- return -ENODEV;
- }
-
twl->otg.host = host;
- twl4030_phy_resume(twl);
-
- twl4030_usb_set_bits(twl, TWL4030_OTG_CTRL,
- TWL4030_OTG_CTRL_DMPULLDOWN
- | TWL4030_OTG_CTRL_DPPULLDOWN);
-
- twl4030_usb_set_bits(twl, FUNC_CTRL, FUNC_CTRL_SUSPENDM);
- twl4030_usb_set_bits(twl, TWL4030_OTG_CTRL, TWL4030_OTG_CTRL_DRVVBUS);
+ if (!host)
+ twl->otg.state = OTG_STATE_UNDEFINED;
return 0;
}
@@ -641,15 +600,15 @@ static int __init twl4030_usb_probe(stru
struct twl4030_usb *twl;
int status;
- twl = kzalloc(sizeof *twl, GFP_KERNEL);
- if (!twl)
- return -ENOMEM;
-
if (!pdata) {
dev_dbg(&pdev->dev, "platform_data not available\n");
return -EINVAL;
}
+ twl = kzalloc(sizeof *twl, GFP_KERNEL);
+ if (!twl)
+ return -ENOMEM;
+
twl->dev= &pdev->dev;
twl->irq= platform_get_irq(pdev, 0);
twl->otg.dev= twl->dev;
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2.6.28-rc6-omap-git 1/2] twl4030-usb: cleanup debug code
From: David Brownell <[EMAIL PROTECTED]>
Remove some debug code from twl4030-usb which 'checkpatch.pl' warned
about. Turn some other messages into debug code; and add some debug
messages in the "write verify" paths (so we can see if they matter).
This gives about 25% codespace shrinkage.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/i2c/chips/twl4030-usb.c | 29 ++---
1 file changed, 10 insertions(+), 19 deletions(-)
--- a/drivers/i2c/chips/twl4030-usb.c
+++ b/drivers/i2c/chips/twl4030-usb.c
@@ -285,13 +285,18 @@ static int twl4030_i2c_write_u8_verify(s
(twl4030_i2c_read_u8(module, &check, address) >= 0) &&
(check == data))
return 0;
+ dev_dbg(twl->dev, "Write%d[%d,0x%x] wrote %02x but read %02x\n",
+ 1, module, address, check, data);
+
/* Failed once: Try again */
if ((twl4030_i2c_write_u8(module, data, address) >= 0) &&
(twl4030_i2c_read_u8(module, &check, address) >= 0) &&
(check == data))
return 0;
- /* Failed again: Return error */
+ dev_dbg(twl->dev, "Write%d[%d,0x%x] wrote %02x but read %02x\n",
+ 2, module, address, check, data);
+ /* Failed again: Return error */
return -EBUSY;
}
@@ -304,23 +309,9 @@ static inline int twl4030_usb_write(stru
int ret = 0;
ret = twl4030_i2c_write_u8(TWL4030_MODULE_USB, data, address);
- if (ret >= 0) {
-#if 0 /* debug */
- u8 data1;
- if (twl4030_i2c_read_u8(TWL4030_MODULE_USB, &data1,
- address) < 0)
- dev_err(twl->dev, "re-read failed\n");
- else
- dev_dbg(twl->dev,
- "Write %s wrote %x read %x from reg %x\n",
- (data1 == data) ? "succeed" : "mismatch",
- data, data1, address);
-#endif
- } else {
- dev_warn(twl->dev,
+ if (ret < 0)
+ dev_dbg(twl->dev,
"TWL4030:USB:Write[0x%x] Error %d\n", address, ret);
- }
-
return ret;
}
@@ -333,7 +324,7 @@ static inline int twl4030_readb(struct t
if (ret >= 0)
ret = data;
else
- dev_warn(twl->dev,
+ dev_dbg(twl->dev,
"TWL4030:readb[0x%x,0x%x] Error %d\n",
module, address, ret);
@@ -655,7 +646,7 @@ static int __init twl4030_usb_probe(stru
return -ENOMEM;
if (!pdata) {
- dev_info(&pdev->dev, "platform_data not available\n");
+ dev_dbg(&pdev->dev, "platform_data not available\n");
return -EINVAL;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] OMAP3: PM: UART save/restore support for OFF-mode
If OFF-mode is enabled, each enabled UART will save its
context whenever clocks are disabled and restore it when
clocks are re-enabled.
Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/serial.c | 77 ++
include/linux/serial_reg.h |1 +
2 files changed, 78 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index f93dc52..dd32047 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -50,6 +50,18 @@ struct omap_uart_state {
struct plat_serial8250_port *p;
struct list_head node;
+
+#ifdef CONFIG_ARCH_OMAP3
+ int context_valid;
+
+ /* Registers to be saved/restored for OFF-mode */
+ u16 dll;
+ u16 dlh;
+ u16 ier;
+ u16 sysc;
+ u16 scr;
+ u16 wer;
+#endif
};
static struct omap_uart_state omap_uart[OMAP_MAX_NR_PORTS];
@@ -114,6 +126,69 @@ static inline void __init omap_uart_reset(struct
omap_uart_state *uart)
serial_write_reg(p, UART_OMAP_SYSC, (0x02 << 3) | (1 << 2) | (1 << 0));
}
+#ifdef CONFIG_ARCH_OMAP3
+/* to be replaced by global with forthcoming OFF-mode patches */
+static int enable_off_mode;
+
+static void omap_uart_save_context(struct omap_uart_state *uart)
+{
+ u16 lcr = 0;
+ struct plat_serial8250_port *p = uart->p;
+
+ if (!enable_off_mode)
+ return;
+
+ lcr = serial_read_reg(p, UART_LCR);
+ serial_write_reg(p, UART_LCR, 0xBF);
+ uart->dll = serial_read_reg(p, UART_DLL);
+ uart->dlh = serial_read_reg(p, UART_DLM);
+ serial_write_reg(p, UART_LCR, lcr);
+ uart->ier = serial_read_reg(p, UART_IER);
+ uart->sysc = serial_read_reg(p, UART_OMAP_SYSC);
+ uart->scr = serial_read_reg(p, UART_OMAP_SCR);
+ uart->wer = serial_read_reg(p, UART_OMAP_WER);
+
+ uart->context_valid = 1;
+}
+
+static void omap_uart_restore_context(struct omap_uart_state *uart)
+{
+ u16 efr = 0;
+ struct plat_serial8250_port *p = uart->p;
+
+ if (!enable_off_mode)
+ return;
+
+ if (!uart->context_valid)
+ return;
+
+ uart->context_valid = 0;
+
+ serial_write_reg(p, UART_OMAP_MDR1, 0x7);
+ serial_write_reg(p, UART_LCR, 0xBF); /* Config B mode */
+ efr = serial_read_reg(p, UART_EFR);
+ serial_write_reg(p, UART_EFR, UART_EFR_ECB);
+ serial_write_reg(p, UART_LCR, 0x0); /* Operational mode */
+ serial_write_reg(p, UART_IER, 0x0);
+ serial_write_reg(p, UART_LCR, 0xBF); /* Config B mode */
+ serial_write_reg(p, UART_DLL, uart->dll);
+ serial_write_reg(p, UART_DLM, uart->dlh);
+ serial_write_reg(p, UART_LCR, 0x0); /* Operational mode */
+ serial_write_reg(p, UART_IER, uart->ier);
+ serial_write_reg(p, UART_FCR, 0xA1);
+ serial_write_reg(p, UART_LCR, 0xBF); /* Config B mode */
+ serial_write_reg(p, UART_EFR, efr);
+ serial_write_reg(p, UART_LCR, UART_LCR_WLEN8);
+ serial_write_reg(p, UART_OMAP_SCR, uart->scr);
+ serial_write_reg(p, UART_OMAP_WER, uart->wer);
+ serial_write_reg(p, UART_OMAP_SYSC, uart->sysc);
+ serial_write_reg(p, UART_OMAP_MDR1, 0x00); /* UART 16x mode */
+}
+#else
+static inline void omap_uart_save_context(struct omap_uart_state *uart) {}
+static inline void omap_uart_restore_context(struct omap_uart_state *uart) {}
+#endif /* CONFIG_ARCH_OMAP3 */
+
static void omap_uart_smart_idle_enable(struct omap_uart_state *uart,
int enable)
{
@@ -137,6 +212,7 @@ static inline void omap_uart_enable_clocks(struct
omap_uart_state *uart)
clk_enable(uart->ick);
clk_enable(uart->fck);
uart->clocked = 1;
+ omap_uart_restore_context(uart);
}
static inline void omap_uart_disable_clocks(struct omap_uart_state *uart)
@@ -144,6 +220,7 @@ static inline void omap_uart_disable_clocks(struct
omap_uart_state *uart)
if (!uart->clocked)
return;
+ omap_uart_save_context(uart);
uart->clocked = 0;
clk_disable(uart->ick);
clk_disable(uart->fck);
diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h
index 96c0d93..850db2e 100644
--- a/include/linux/serial_reg.h
+++ b/include/linux/serial_reg.h
@@ -323,6 +323,7 @@
#define UART_OMAP_MVER 0x14/* Module version register */
#define UART_OMAP_SYSC 0x15/* System configuration register */
#define UART_OMAP_SYSS 0x16/* System status register */
+#define UART_OMAP_WER 0x17/* Wake-up enable register */
#endif /* _LINUX_SERIAL_REG_H */
--
1.6.0.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] OMAP3: PM: UART: disable clocks when idle
This patch allows the chip to hit retention when the OMAP UARTs are
inactive. After the timeout of an activity timer, each UART is
allowed to disable its clocks so the system can enter retention. The
activity timer is (re)activated on any UART interrupt, UART wake event
or any IO pad wakeup.
While the activity timer is active, the smart-idle mode of the UART is
also disabled. This is due to a "feature" of the UART module that
after a UART wakeup, the smart-idle mode may be entered before the
UART has communicated the interrupt, or upon TX, an idle mode
may be entered before the TX FIFOs are emptied.
Upon suspend, the PM hook ensures the UART block is ready for sleep
and explicitly disables the clocks. Upon resume, the UART is
re-clocked and the activity timer restarted.
To enable the clock-disabling feature of this patch, do
# echo 1 > /sys/power/clocks_off_while_idle
Special thanks to Tero Kristo for the initial ideas and first versions
of UART idle support, and to Jouni Hogander for extra testing and
bugfixes.
Tested on OMAP3 (Beagle, custom HW) and OMAP2 (n810)
Cc: Tero Kristo <[EMAIL PROTECTED]>
Cc: Jouni Hogander <[EMAIL PROTECTED]>
Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/pm-debug.c | 135 -
arch/arm/mach-omap2/pm.h |8 -
arch/arm/mach-omap2/pm24xx.c | 40 ++--
arch/arm/mach-omap2/pm34xx.c | 14 ++
arch/arm/mach-omap2/serial.c | 303 +++---
arch/arm/plat-omap/include/mach/common.h |2 -
arch/arm/plat-omap/include/mach/serial.h |8 +
7 files changed, 322 insertions(+), 188 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 0b5c044..b00f5f4 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -37,141 +37,6 @@
#ifdef CONFIG_PM_DEBUG
int omap2_pm_debug = 0;
-static int serial_console_clock_disabled;
-static int serial_console_uart;
-static unsigned int serial_console_next_disable;
-
-static struct clk *console_iclk, *console_fclk;
-
-static void serial_console_kick(void)
-{
- serial_console_next_disable = omap2_read_32k_sync_counter();
- /* Keep the clocks on for 4 secs */
- serial_console_next_disable += 4 * 32768;
-}
-
-static void serial_wait_tx(void)
-{
- static const unsigned long uart_bases[3] = {
- 0x4806a000, 0x4806c000, 0x4806e000
- };
- unsigned long lsr_reg;
- int looped = 0;
-
- /* Wait for TX FIFO and THR to get empty */
- lsr_reg = IO_ADDRESS(uart_bases[serial_console_uart - 1] + (5 << 2));
- while ((__raw_readb(lsr_reg) & 0x60) != 0x60)
- looped = 1;
- if (looped)
- serial_console_kick();
-}
-
-u32 omap2_read_32k_sync_counter(void)
-{
-return omap_readl(OMAP2_32KSYNCT_BASE + 0x0010);
-}
-
-void serial_console_fclk_mask(u32 *f1, u32 *f2)
-{
- switch (serial_console_uart) {
- case 1:
- *f1 &= ~(1 << 21);
- break;
- case 2:
- *f1 &= ~(1 << 22);
- break;
- case 3:
- *f2 &= ~(1 << 2);
- break;
- }
-}
-
-void serial_console_sleep(int enable)
-{
- if (console_iclk == NULL || console_fclk == NULL)
- return;
-
- if (enable) {
- BUG_ON(serial_console_clock_disabled);
- if (clk_get_usecount(console_fclk) == 0)
- return;
- if ((int) serial_console_next_disable - (int)
omap2_read_32k_sync_counter() >= 0)
- return;
- serial_wait_tx();
- clk_disable(console_iclk);
- clk_disable(console_fclk);
- serial_console_clock_disabled = 1;
- } else {
- int serial_wakeup = 0;
- u32 l;
-
- switch (serial_console_uart) {
- case 1:
- l = prm_read_mod_reg(CORE_MOD, PM_WKST1);
- if (l & OMAP24XX_ST_UART1_MASK)
- serial_wakeup = 1;
- break;
- case 2:
- l = prm_read_mod_reg(CORE_MOD, PM_WKST1);
- if (l & OMAP24XX_ST_UART2_MASK)
- serial_wakeup = 1;
- break;
- case 3:
- l = prm_read_mod_reg(CORE_MOD, OMAP24XX_PM_WKST2);
- if (l & OMAP24XX_ST_UART3_MASK)
- serial_wakeup = 1;
- break;
- }
- if (serial_wakeup)
- serial_console_kick();
- if (!serial_console_clock_disabled)
- return;
- clk_enable(console_iclk);
- clk_enable(console_fclk);
- serial_console_clock_disabled = 0;
- }
-}
-
-void pm_ini
[PATCH 1/3] OMAP3: PM: Add wake-up bit defintiions for CONTROL_PADCONF_X
Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]> --- arch/arm/plat-omap/include/mach/control.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/control.h b/arch/arm/plat-omap/include/mach/control.h index b51f7fd..745bc4c 100644 --- a/arch/arm/plat-omap/include/mach/control.h +++ b/arch/arm/plat-omap/include/mach/control.h @@ -213,6 +213,10 @@ #define OMAP3_IVA2_BOOTMOD_MASK(0xf << 0) #define OMAP3_IVA2_BOOTMOD_IDLE(0x1 << 0) +/* CONTROL_PADCONF_X bits */ +#define OMAP3_PADCONF_WAKEUPEVENT0 (1 << 15) +#define OMAP3_PADCONF_WAKEUPENABLE0(1 << 14) + #ifndef __ASSEMBLY__ #if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) extern void __iomem *omap_ctrl_base_get(void); -- 1.6.0.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] OMAP: PM: enable UART clock disabling when idle
This series enables UART clock disabling after an inactivity period. It is based on top of the 2 8250 patches recently sent to linux-serial and CC'd to linux-omap. To enable: # echo 1 > /sys/power/clocks_off_while_idle # echo 1 > /sys/power/sleep_while_idle NOTE: it is expected that the first character typed is lost when coming out of idle. The first char serves as the wakeup event but is lost. Kevin Hilman (3): OMAP3: PM: Add wake-up bit defintiions for CONTROL_PADCONF_X OMAP3: PM: UART: disable clocks when idle OMAP3: PM: UART save/restore support for OFF-mode arch/arm/mach-omap2/pm-debug.c| 135 -- arch/arm/mach-omap2/pm.h |8 - arch/arm/mach-omap2/pm24xx.c | 40 ++-- arch/arm/mach-omap2/pm34xx.c | 14 + arch/arm/mach-omap2/serial.c | 380 +++-- arch/arm/plat-omap/include/mach/common.h |2 - arch/arm/plat-omap/include/mach/control.h |4 + arch/arm/plat-omap/include/mach/serial.h |8 + include/linux/serial_reg.h|1 + 9 files changed, 404 insertions(+), 188 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] OMAP3: PM: HSMMC: force MMC module reset on boot
* Kevin Hilman <[EMAIL PROTECTED]> [081126 16:07]:
> The bootloader may leave the MMC in a state which prevents hitting
> retention. Even when MMC is not compiled in, each MMC module needs to
> be forced into reset.
>
> Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/devices.c | 76
> +
> 1 files changed, 76 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index 241e418..196de4e 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -358,6 +359,80 @@ static inline void omap_init_sha1_md5(void) { }
>
> /*-*/
>
> +#ifdef CONFIG_ARCH_OMAP3
> +
> +#define MMCHS1 (L4_34XX_BASE + 0x9C000)
> +#define MMCHS2 (L4_34XX_BASE + 0xB4000)
> +#define MMCHS3 (L4_34XX_BASE + 0xAD000)
These are already in plat-omap/include/mach/mmc.h, how about just
include it? Then you can have a switch statement like we already have
for omap2_init_mmc?
> +#define MAX_MMC 3
This too
> +#define MMCHS_SYSCONFIG 0x0010
> +#define MMCHS_SYSCONFIG_SWRESET (1 << 1)
> +#define MMCHS_SYSSTATUS 0x0014
> +#define MMCHS_SYSSTATUS_RESETDONE(1 << 0)
> +
> +static struct platform_device dummy_pdev = {
> + .dev = {
> + .bus = &platform_bus_type,
> + },
> +};
> +
> +/**
> + * omap_hsmmc_reset() - Full reset of each HS-MMC controller
> + *
> + * Ensure that each MMC controller is fully reset. Controllers
> + * left in an unknown state (by bootloaer) may prevent retention
> + * or OFF-mode. This is especially important in cases where the
> + * MMC driver is not enabled, _or_ built as a module.
Should say bootloader above :)
Regards,
Tony
> + * In order for reset to work, interface, functional and debounce
> + * clocks must be enabled. The debounce clock comes from func_32k_clk
> + * and is not under SW control, so we only enable i- and f-clocks.
> + **/
> +static void __init omap_hsmmc_reset(void)
> +{
> + u32 i, base[MAX_MMC] = {MMCHS1, MMCHS2, MMCHS3};
> +
> + for (i = 0; i < MAX_MMC; i++) {
> + u32 v;
> + struct clk *iclk, *fclk;
> + struct device *dev = &dummy_pdev.dev;
> +
> + dummy_pdev.id = i;
> + iclk = clk_get(dev, "mmchs_ick");
> + if (iclk && clk_enable(iclk))
> + iclk = NULL;
> +
> + fclk = clk_get(dev, "mmchs_fck");
> + if (fclk && clk_enable(fclk))
> + fclk = NULL;
> +
> + if (!iclk || !fclk) {
> + printk(KERN_WARNING
> +"%s: Unable to enable clocks for MMC%d, "
> +"cannot reset.\n", __func__, i);
> + break;
> + }
> +
> + omap_writel(MMCHS_SYSCONFIG_SWRESET, base[i] + MMCHS_SYSCONFIG);
> + v = omap_readl(base[i] + MMCHS_SYSSTATUS);
> + while (!(omap_readl(base[i] + MMCHS_SYSSTATUS) &
> + MMCHS_SYSSTATUS_RESETDONE))
> + cpu_relax();
> +
> + if (fclk) {
> + clk_disable(fclk);
> + clk_put(fclk);
> + }
> + if (iclk) {
> + clk_disable(iclk);
> + clk_put(iclk);
> + }
> + }
> +}
> +#else
> +static inline void omap_hsmmc_reset(void) {}
> +#endif
> +
> #if defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE) || \
> defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
>
> @@ -477,6 +552,7 @@ static int __init omap2_init_devices(void)
> /* please keep these calls, and their implementations above,
>* in alphabetical order so they're easier to sort through.
>*/
> + omap_hsmmc_reset();
> omap_init_camera();
> omap_init_mbox();
> omap_init_mcspi();
> --
> 1.6.0.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] 8250: when waking, PM hook should be called before accessing port
The UART suspend hook may have disabled the UART clocks such that
accesses to the port may fail. So before accessing the port
call the PM hook so it has a chance to enable clocks.
Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
---
drivers/serial/8250.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index 993a242..a181667 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -2334,10 +2334,18 @@ serial8250_pm(struct uart_port *port, unsigned int
state,
unsigned int oldstate)
{
struct uart_8250_port *p = (struct uart_8250_port *)port;
+ int sleep = state != 0;
- serial8250_set_sleep(p, state != 0);
+ /* If we're waking up, call the PM hook before waking up
+* so port can be properly activated/enabled if necessary */
+ if (p->pm && !sleep)
+ p->pm(port, state, oldstate);
+
+ serial8250_set_sleep(p, sleep);
- if (p->pm)
+ /* If we're going to sleep, PM hook should be called after
+* to deactivate/disable port */
+ if (p->pm && sleep)
p->pm(port, state, oldstate);
}
--
1.6.0.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] 8250: Allow platform to register PM hook
Allow platform code to register a PM hook with the 8250 driver. This
enables platform specific code to be run for suspend/resume events.
Since the per-port PM hook is local to the 8250 driver ('struct
uart_port' doesn't have a PM hook) I pass the pm hook from the
platform probe via serial8250_register_port().
Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
---
drivers/serial/8250.c |7 +--
include/linux/serial_8250.h |7 ++-
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index 5f383d8..993a242 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -2842,7 +2842,7 @@ static int __devinit serial8250_probe(struct
platform_device *dev)
port.dev= &dev->dev;
if (share_irqs)
port.flags |= UPF_SHARE_IRQ;
- ret = serial8250_register_port(&port);
+ ret = serial8250_register_port(&port, p->pm);
if (ret < 0) {
dev_err(&dev->dev, "unable to register port at index %d
"
"(IO%lx MEM%llx IRQ%d): %d\n", i,
@@ -2966,7 +2966,9 @@ static struct uart_8250_port
*serial8250_find_match_or_unused(struct uart_port *
*
* On success the port is ready to use and the line number is returned.
*/
-int serial8250_register_port(struct uart_port *port)
+int serial8250_register_port(struct uart_port *port,
+void (*pm)(struct uart_port *, unsigned int state,
+ unsigned int oldstate))
{
struct uart_8250_port *uart;
int ret = -ENOSPC;
@@ -2990,6 +2992,7 @@ int serial8250_register_port(struct uart_port *port)
uart->port.flags= port->flags | UPF_BOOT_AUTOCONF;
uart->port.mapbase = port->mapbase;
uart->port.private_data = port->private_data;
+ uart->pm = pm;
if (port->dev)
uart->port.dev = port->dev;
diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index 3d37c94..97723c5 100644
--- a/include/linux/serial_8250.h
+++ b/include/linux/serial_8250.h
@@ -28,6 +28,9 @@ struct plat_serial8250_port {
unsigned char iotype; /* UPIO_* */
unsigned char hub6;
upf_t flags; /* UPF_* flags */
+
+ void(*pm)(struct uart_port *, unsigned int state,
+ unsigned int oldstate);
};
/*
@@ -57,7 +60,9 @@ enum {
*/
struct uart_port;
-int serial8250_register_port(struct uart_port *);
+int serial8250_register_port(struct uart_port *,
+void (*pm)(struct uart_port *, unsigned int state,
+ unsigned int oldstate));
void serial8250_unregister_port(int line);
void serial8250_suspend_port(int line);
void serial8250_resume_port(int line);
--
1.6.0.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] OMAP3: PM: Ensure modem is reset during PRCM init
Rogue bootloaders may enable the modem and thus keep the
D2D power- and clock-domains from going into retention.
Reset modem on boot to be sure it is in known state.
Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/pm34xx.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7c5577a..e22a11f 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -418,6 +418,12 @@ static void __init omap3_iva_idle(void)
static void __init prcm_setup_regs(void)
{
+ /* reset modem */
+ prm_write_mod_reg(OMAP3430_RM_RSTCTRL_CORE_MODEM_SW_RSTPWRON |
+ OMAP3430_RM_RSTCTRL_CORE_MODEM_SW_RST,
+ CORE_MOD, RM_RSTCTRL);
+ prm_write_mod_reg(0, CORE_MOD, RM_RSTCTRL);
+
/* XXX Reset all wkdeps. This should be done when initializing
* powerdomains */
prm_write_mod_reg(0, OMAP3430_IVA2_MOD, PM_WKDEP);
--
1.6.0.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] OMAP3: PM: D2D clockdomain supports SW supervised transitions
Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/clockdomains.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains.h
b/arch/arm/mach-omap2/clockdomains.h
index bafa650..49a5774 100644
--- a/arch/arm/mach-omap2/clockdomains.h
+++ b/arch/arm/mach-omap2/clockdomains.h
@@ -198,7 +198,7 @@ static struct clockdomain sgx_clkdm = {
static struct clockdomain d2d_clkdm = {
.name = "d2d_clkdm",
.pwrdm = { .name = "core_pwrdm" },
- .flags = CLKDM_CAN_HWSUP,
+ .flags = CLKDM_CAN_HWSUP_SWSUP,
.clktrctrl_mask = OMAP3430ES1_CLKTRCTRL_D2D_MASK,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
--
1.6.0.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] OMAP3: PM: Add D2D clocks and auto-idle setup to PRCM init
Add D2D clocks (modem_fck, sad2d_ick, mad2d_ick) to clock framework,
and also ensure that auto-idle bits are set for these clocks during
PRCM init.
Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/clock34xx.h | 37 +++-
arch/arm/mach-omap2/cm-regbits-34xx.h | 14
arch/arm/mach-omap2/pm34xx.c |4 ++-
3 files changed, 52 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 0b95fcb..78504ce 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -1330,6 +1330,38 @@ static struct clk d2d_26m_fck = {
.recalc = &followparent_recalc,
};
+static struct clk modem_fck = {
+ .name = "modem_fck",
+ .parent = &sys_ck,
+ .prcm_mod = CORE_MOD,
+ .enable_reg = CM_FCLKEN1,
+ .enable_bit = OMAP3430_EN_MODEM_SHIFT,
+ .flags = CLOCK_IN_OMAP343X,
+ .clkdm = { .name = "d2d_clkdm" },
+ .recalc = &followparent_recalc,
+};
+
+static struct clk sad2d_ick = {
+ .name = "sad2d_ick",
+ .parent = &sys_ck,
+ .prcm_mod = CORE_MOD,
+ .enable_reg = CM_ICLKEN1,
+ .enable_bit = OMAP3430_EN_SAD2D_SHIFT,
+ .flags = CLOCK_IN_OMAP343X,
+ .clkdm = { .name = "d2d_clkdm" },
+ .recalc = &followparent_recalc,
+};
+
+static struct clk mad2d_ick = {
+ .name = "mad2d_ick",
+ .parent = &sys_ck,
+ .prcm_mod = CORE_MOD,
+ .enable_reg = CM_ICLKEN3,
+ .enable_bit = OMAP3430_EN_MAD2D_SHIFT,
+ .flags = CLOCK_IN_OMAP343X,
+ .clkdm = { .name = "d2d_clkdm" },
+ .recalc = &followparent_recalc,
+};
static const struct clksel omap343x_gpt_clksel[] = {
{ .parent = &omap_32k_fck, .rates = gpt_32k_rates },
{ .parent = &sys_ck, .rates = gpt_sys_rates },
@@ -2241,8 +2273,6 @@ static struct clk usb_l4_ick = {
.recalc = &omap2_clksel_recalc,
};
-/* XXX MDM_INTC_ICK, SAD2D_ICK ?? */
-
/* SECURITY_L4_ICK2 based clocks */
static struct clk security_l4_ick2 = {
@@ -3460,6 +3490,9 @@ static struct clk *onchip_34xx_clks[] __initdata = {
&sgx_fck,
&sgx_ick,
&d2d_26m_fck,
+ &modem_fck,
+ &sad2d_ick,
+ &mad2d_ick,
&gpt10_fck,
&gpt11_fck,
&cpefuse_fck,
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index 6f3f5a3..6923deb 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -145,6 +145,8 @@
#define OMAP3430_CLKACTIVITY_MPU_MASK (1 << 0)
/* CM_FCLKEN1_CORE specific bits */
+#define OMAP3430_EN_MODEM (1 << 31)
+#define OMAP3430_EN_MODEM_SHIFT31
/* CM_ICLKEN1_CORE specific bits */
#define OMAP3430_EN_ICR(1 << 29)
@@ -161,6 +163,8 @@
#define OMAP3430_EN_MAILBOXES_SHIFT7
#define OMAP3430_EN_OMAPCTRL (1 << 6)
#define OMAP3430_EN_OMAPCTRL_SHIFT 6
+#define OMAP3430_EN_SAD2D (1 << 3)
+#define OMAP3430_EN_SAD2D_SHIFT3
#define OMAP3430_EN_SDRC (1 << 1)
#define OMAP3430_EN_SDRC_SHIFT 1
@@ -176,6 +180,10 @@
#define OMAP3430_EN_DES1 (1 << 0)
#define OMAP3430_EN_DES1_SHIFT 0
+/* CM_ICLKEN3_CORE */
+#define OMAP3430_EN_MAD2D_SHIFT3
+#define OMAP3430_EN_MAD2D (1 << 3)
+
/* CM_FCLKEN3_CORE specific bits */
#define OMAP3430ES2_EN_TS_SHIFT1
#define OMAP3430ES2_EN_TS_MASK (1 << 1)
@@ -231,6 +239,8 @@
#define OMAP3430ES2_ST_CPEFUSE_MASK(1 << 0)
/* CM_AUTOIDLE1_CORE */
+#define OMAP3430_AUTO_MODEM(1 << 31)
+#define OMAP3430_AUTO_MODEM_SHIFT 31
#define OMAP3430ES2_AUTO_MMC3 (1 << 30)
#define OMAP3430ES2_AUTO_MMC3_SHIFT30
#define OMAP3430ES2_AUTO_ICR (1 << 29)
@@ -287,6 +297,8 @@
#define OMAP3430_AUTO_HSOTGUSB_SHIFT 4
#define OMAP3430ES1_AUTO_D2D (1 << 3)
#define OMAP3430ES1_AUTO_D2D_SHIFT 3
+#define OMAP3430_AUTO_SAD2D(1 << 3)
+#define OMAP3430_AUTO_SAD2D_SHIFT 3
#define OMAP3430_AUTO_SSI (1 << 0)
#define OMAP3430_AUTO_SSI_SHIFT0
@@ -308,6 +320,8 @@
#defineOMAP3430ES2_AUTO_USBTLL
[PATCH 2/5] OMAP3: PM: Force IVA2 into idle during bootup
Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/pm34xx.c | 55 +
arch/arm/plat-omap/include/mach/control.h |5 +++
2 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 9f5a544..5166fbd 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include "cm.h"
#include "cm-regbits-34xx.h"
@@ -363,6 +364,58 @@ static struct platform_suspend_ops omap_pm_ops = {
.valid = suspend_valid_only_mem,
};
+
+/**
+ * omap3_iva_idle(): ensure IVA is in idle so it can be put into
+ * retention
+ *
+ * In cases where IVA2 is activated by bootcode, it may prevent
+ * full-chip retention or off-mode because it is not idle. This
+ * function forces the IVA2 into idle state so it can go
+ * into retention/off and thus allow full-chip retention/off.
+ *
+ **/
+static void __init omap3_iva_idle(void)
+{
+ struct clk *iva2_ck;
+
+ iva2_ck = clk_get(NULL, "iva2_fclk");
+ if (!iva2_ck) {
+ pr_err("Unable to get IVA2 fclk: cannot force idle.\n");
+ return;
+ }
+
+ /* Disable IVA2 clock */
+ clk_disable(iva2_ck);
+
+ /* Reset IVA2 */
+ prm_write_mod_reg(OMAP3430_RST1_IVA2 |
+ OMAP3430_RST2_IVA2 |
+ OMAP3430_RST3_IVA2,
+ OMAP3430_IVA2_MOD, RM_RSTCTRL);
+
+ /* Enable IVA2 clock */
+ clk_enable(iva2_ck);
+
+ /* Set IVA2 boot mode to 'idle' */
+ omap_ctrl_writel(OMAP3_IVA2_BOOTMOD_IDLE,
+OMAP343X_CONTROL_IVA2_BOOTMOD);
+
+ /* Un-reset IVA2 */
+ prm_write_mod_reg(0, OMAP3430_IVA2_MOD, RM_RSTCTRL);
+
+ /* Disable IVA2 clocks */
+ clk_disable(iva2_ck);
+
+ /* Reset IVA2 */
+ prm_write_mod_reg(OMAP3430_RST1_IVA2 |
+ OMAP3430_RST2_IVA2 |
+ OMAP3430_RST3_IVA2,
+ OMAP3430_IVA2_MOD, RM_RSTCTRL);
+
+ clk_put(iva2_ck);
+}
+
static void __init prcm_setup_regs(void)
{
/* XXX Reset all wkdeps. This should be done when initializing
@@ -515,6 +568,8 @@ static void __init prcm_setup_regs(void)
* it is selected to mpu wakeup goup */
prm_write_mod_reg(OMAP3430_IO_EN | OMAP3430_WKUP_EN,
OCP_MOD, OMAP2_PRM_IRQENABLE_MPU_OFFSET);
+
+ omap3_iva_idle();
}
static int __init pwrdms_setup(struct powerdomain *pwrdm)
diff --git a/arch/arm/plat-omap/include/mach/control.h
b/arch/arm/plat-omap/include/mach/control.h
index ee3c39e..b51f7fd 100644
--- a/arch/arm/plat-omap/include/mach/control.h
+++ b/arch/arm/plat-omap/include/mach/control.h
@@ -208,6 +208,11 @@
#define OMAP2_PBIASLITEPWRDNZ0 (1 << 1)
#define OMAP2_PBIASLITEVMODE0 (1 << 0)
+/* CONTROL_IVA2_BOOTMOD bits */
+#define OMAP3_IVA2_BOOTMOD_SHIFT 0
+#define OMAP3_IVA2_BOOTMOD_MASK(0xf << 0)
+#define OMAP3_IVA2_BOOTMOD_IDLE(0x1 << 0)
+
#ifndef __ASSEMBLY__
#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
extern void __iomem *omap_ctrl_base_get(void);
--
1.6.0.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] OMAP3: PM: HSMMC: force MMC module reset on boot
The bootloader may leave the MMC in a state which prevents hitting
retention. Even when MMC is not compiled in, each MMC module needs to
be forced into reset.
Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/devices.c | 76 +
1 files changed, 76 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 241e418..196de4e 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -358,6 +359,80 @@ static inline void omap_init_sha1_md5(void) { }
/*-*/
+#ifdef CONFIG_ARCH_OMAP3
+
+#define MMCHS1 (L4_34XX_BASE + 0x9C000)
+#define MMCHS2 (L4_34XX_BASE + 0xB4000)
+#define MMCHS3 (L4_34XX_BASE + 0xAD000)
+#define MAX_MMC3
+#define MMCHS_SYSCONFIG0x0010
+#define MMCHS_SYSCONFIG_SWRESET(1 << 1)
+#define MMCHS_SYSSTATUS0x0014
+#define MMCHS_SYSSTATUS_RESETDONE (1 << 0)
+
+static struct platform_device dummy_pdev = {
+ .dev = {
+ .bus = &platform_bus_type,
+ },
+};
+
+/**
+ * omap_hsmmc_reset() - Full reset of each HS-MMC controller
+ *
+ * Ensure that each MMC controller is fully reset. Controllers
+ * left in an unknown state (by bootloaer) may prevent retention
+ * or OFF-mode. This is especially important in cases where the
+ * MMC driver is not enabled, _or_ built as a module.
+ *
+ * In order for reset to work, interface, functional and debounce
+ * clocks must be enabled. The debounce clock comes from func_32k_clk
+ * and is not under SW control, so we only enable i- and f-clocks.
+ **/
+static void __init omap_hsmmc_reset(void)
+{
+ u32 i, base[MAX_MMC] = {MMCHS1, MMCHS2, MMCHS3};
+
+ for (i = 0; i < MAX_MMC; i++) {
+ u32 v;
+ struct clk *iclk, *fclk;
+ struct device *dev = &dummy_pdev.dev;
+
+ dummy_pdev.id = i;
+ iclk = clk_get(dev, "mmchs_ick");
+ if (iclk && clk_enable(iclk))
+ iclk = NULL;
+
+ fclk = clk_get(dev, "mmchs_fck");
+ if (fclk && clk_enable(fclk))
+ fclk = NULL;
+
+ if (!iclk || !fclk) {
+ printk(KERN_WARNING
+ "%s: Unable to enable clocks for MMC%d, "
+ "cannot reset.\n", __func__, i);
+ break;
+ }
+
+ omap_writel(MMCHS_SYSCONFIG_SWRESET, base[i] + MMCHS_SYSCONFIG);
+ v = omap_readl(base[i] + MMCHS_SYSSTATUS);
+ while (!(omap_readl(base[i] + MMCHS_SYSSTATUS) &
+MMCHS_SYSSTATUS_RESETDONE))
+ cpu_relax();
+
+ if (fclk) {
+ clk_disable(fclk);
+ clk_put(fclk);
+ }
+ if (iclk) {
+ clk_disable(iclk);
+ clk_put(iclk);
+ }
+ }
+}
+#else
+static inline void omap_hsmmc_reset(void) {}
+#endif
+
#if defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE) || \
defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
@@ -477,6 +552,7 @@ static int __init omap2_init_devices(void)
/* please keep these calls, and their implementations above,
* in alphabetical order so they're easier to sort through.
*/
+ omap_hsmmc_reset();
omap_init_camera();
omap_init_mbox();
omap_init_mcspi();
--
1.6.0.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] extra module resets to ensure full-chip idle
Various bootloaders have been known to leave modules in a state which prevents full-chip retention. This series forces MMC, IVA2 and D2D/modem into known reset/idle states so that the OMAP3 can hit full-chip idle. Tested on OMAP3 Beagle, and custom OMAP3 hardware. NOTE: this is similar to the set I posted for the PM branch but this series is rebased onto linux-omap and includes the MMC reset. Kevin Hilman (5): OMAP3: PM: HSMMC: force MMC module reset on boot OMAP3: PM: Force IVA2 into idle during bootup OMAP3: PM: Add D2D clocks and auto-idle setup to PRCM init OMAP3: PM: D2D clockdomain supports SW supervised transitions OMAP3: PM: Ensure modem is reset during PRCM init arch/arm/mach-omap2/clock34xx.h | 37 +- arch/arm/mach-omap2/clockdomains.h|2 +- arch/arm/mach-omap2/cm-regbits-34xx.h | 14 + arch/arm/mach-omap2/devices.c | 76 + arch/arm/mach-omap2/pm34xx.c | 65 - arch/arm/plat-omap/include/mach/control.h |5 ++ 6 files changed, 195 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP: Fixes for suspend / resume GPIO wake-up handling
>From 723fdb781abfe78d8ba7d911abbb581722348aa7 Mon Sep 17 00:00:00 2001
From: Tero Kristo <[EMAIL PROTECTED]>
Date: Wed, 26 Nov 2008 14:35:16 -0800
Subject: [PATCH] ARM: OMAP: Fixes for suspend / resume GPIO wake-up handling
Use the correct wake-up enable register, and make it
work with 34xx also.
Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
arch/arm/plat-omap/gpio.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 8679fbc..424049d 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -101,6 +101,7 @@
#define OMAP24XX_GPIO_IRQSTATUS2 0x0028
#define OMAP24XX_GPIO_IRQENABLE2 0x002c
#define OMAP24XX_GPIO_IRQENABLE1 0x001c
+#define OMAP24XX_GPIO_WAKE_EN 0x0020
#define OMAP24XX_GPIO_CTRL 0x0030
#define OMAP24XX_GPIO_OE 0x0034
#define OMAP24XX_GPIO_DATAIN 0x0038
@@ -1551,7 +1552,7 @@ static int omap_gpio_suspend(struct sys_device *dev,
pm_message_t mesg)
#endif
#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
case METHOD_GPIO_24XX:
- wake_status = bank->base + OMAP24XX_GPIO_SETWKUENA;
+ wake_status = bank->base + OMAP24XX_GPIO_WAKE_EN;
wake_clear = bank->base + OMAP24XX_GPIO_CLEARWKUENA;
wake_set = bank->base + OMAP24XX_GPIO_SETWKUENA;
break;
@@ -1574,7 +1575,7 @@ static int omap_gpio_resume(struct sys_device *dev)
{
int i;
- if (!cpu_is_omap24xx() && !cpu_is_omap16xx())
+ if (!cpu_class_is_omap2() && !cpu_is_omap16xx())
return 0;
for (i = 0; i < gpio_bank_count; i++) {
--
1.5.6.rc3.21.g8c6b5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP: Typo fix for clock_allow_idle
>From 147dcf5489fb86c4bfe400520186f9f11b304783 Mon Sep 17 00:00:00 2001 From: Amit Kucheria <[EMAIL PROTECTED]> Date: Tue, 25 Nov 2008 15:11:12 -0800 Subject: [PATCH] ARM: OMAP: Typo fix for clock_allow_idle The second clk_deny_idle instance should be clk_allow_idle instead. Signed-off-by: Amit Kucheria <[EMAIL PROTECTED]> Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]> --- arch/arm/plat-omap/include/mach/pm.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/pm.h b/arch/arm/plat-omap/include/mach/pm.h index 768eb6e..2a9c27a 100644 --- a/arch/arm/plat-omap/include/mach/pm.h +++ b/arch/arm/plat-omap/include/mach/pm.h @@ -128,7 +128,7 @@ void clk_deny_idle(struct clk *clk); * clk_allow_idle - Counters previous clk_deny_idle * @clk: clock signal handle */ -void clk_deny_idle(struct clk *clk); +void clk_allow_idle(struct clk *clk); extern void omap_pm_idle(void); extern void omap_pm_suspend(void); -- 1.5.6.rc3.21.g8c6b5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP: Remove broken LCD driver for SX1
>From 7953031da4200323ab5d85bd514054ca4ba9d225 Mon Sep 17 00:00:00 2001
From: Tony Lindgren <[EMAIL PROTECTED]>
Date: Mon, 24 Nov 2008 18:11:16 -0800
Subject: [PATCH] ARM: OMAP: Remove broken LCD driver for SX1
Recently the omap McBSP code was cleaned up to get rid of
direct McBSP register tinkering by the drivers. Looks like
lcd_sx1.c never got converted, and now it breaks builds.
It seems the lcd_sx1.c driver is attempting SPI mode, but
doing it in a different way compared to omap_mcbsp_set_spi_mode().
Remove the broken driver, patches welcome to add it back when
done properly by patching both mcbsp.c and lcd_sx1.c.
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/video/omap/Makefile |1 -
drivers/video/omap/lcd_sx1.c | 327 --
2 files changed, 0 insertions(+), 328 deletions(-)
delete mode 100644 drivers/video/omap/lcd_sx1.c
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index 99da8b6..ed13889 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -23,7 +23,6 @@ objs-y$(CONFIG_MACH_OMAP_PALMZ71) += lcd_palmz71.o
objs-$(CONFIG_ARCH_OMAP16XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1610.o
objs-$(CONFIG_ARCH_OMAP15XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1510.o
objs-y$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o
-objs-y$(CONFIG_MACH_SX1) += lcd_sx1.o
omapfb-objs := $(objs-yy)
diff --git a/drivers/video/omap/lcd_sx1.c b/drivers/video/omap/lcd_sx1.c
deleted file mode 100644
index e55de20..000
--- a/drivers/video/omap/lcd_sx1.c
+++ /dev/null
@@ -1,327 +0,0 @@
-/*
- * LCD panel support for the Siemens SX1 mobile phone
- *
- * Current version : [EMAIL PROTECTED], great help from FCA0
- *
- * 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.
- *
- * 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.,
- * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-#include
-
-/*
- * OMAP310 GPIO registers
- */
-#define GPIO_DATA_INPUT0xfffce000
-#define GPIO_DATA_OUTPUT 0xfffce004
-#define GPIO_DIR_CONTROL 0xfffce008
-#define GPIO_INT_CONTROL 0xfffce00c
-#define GPIO_INT_MASK 0xfffce010
-#define GPIO_INT_STATUS0xfffce014
-#define GPIO_PIN_CONTROL 0xfffce018
-
-
-#define A_LCD_SSC_RD 3
-#define A_LCD_SSC_SD 7
-#define _A_LCD_RESET 9
-#define _A_LCD_SSC_CS 12
-#define _A_LCD_SSC_A0 13
-
-#define DSP_REG0xE1017024
-
-const unsigned char INIT_1[12] = {
- 0x1C, 0x02, 0x88, 0x00, 0x1E, 0xE0, 0x00, 0xDC, 0x00, 0x02, 0x00
-};
-
-const unsigned char INIT_2[127] = {
- 0x15, 0x00, 0x29, 0x00, 0x3E, 0x00, 0x51, 0x00,
- 0x65, 0x00, 0x7A, 0x00, 0x8D, 0x00, 0xA1, 0x00,
- 0xB6, 0x00, 0xC7, 0x00, 0xD8, 0x00, 0xEB, 0x00,
- 0xFB, 0x00, 0x0B, 0x01, 0x1B, 0x01, 0x27, 0x01,
- 0x34, 0x01, 0x41, 0x01, 0x4C, 0x01, 0x55, 0x01,
- 0x5F, 0x01, 0x68, 0x01, 0x70, 0x01, 0x78, 0x01,
- 0x7E, 0x01, 0x86, 0x01, 0x8C, 0x01, 0x94, 0x01,
- 0x9B, 0x01, 0xA1, 0x01, 0xA4, 0x01, 0xA9, 0x01,
- 0xAD, 0x01, 0xB2, 0x01, 0xB7, 0x01, 0xBC, 0x01,
- 0xC0, 0x01, 0xC4, 0x01, 0xC8, 0x01, 0xCB, 0x01,
- 0xCF, 0x01, 0xD2, 0x01, 0xD5, 0x01, 0xD8, 0x01,
- 0xDB, 0x01, 0xE0, 0x01, 0xE3, 0x01, 0xE6, 0x01,
- 0xE8, 0x01, 0xEB, 0x01, 0xEE, 0x01, 0xF1, 0x01,
- 0xF3, 0x01, 0xF8, 0x01, 0xF9, 0x01, 0xFC, 0x01,
- 0x00, 0x02, 0x03, 0x02, 0x07, 0x02, 0x09, 0x02,
- 0x0E, 0x02, 0x13, 0x02, 0x1C, 0x02, 0x00
-};
-
-const unsigned char INIT_3[15] = {
- 0x14, 0x26, 0x33, 0x3D, 0x45, 0x4D, 0x53, 0x59,
- 0x5E, 0x63, 0x67, 0x6D, 0x71, 0x78, 0xFF
-};
-
-static void epson_sendbyte(int flag, unsigned char byte)
-{
- int i, shifter = 0x80;
-
- if (!flag)
- gpio_set_value(_A_LCD_SSC_A0, 0);
- mdelay(2);
- gpio_set_value(A_LCD_SSC_RD, 1);
-
- gpio_set_value(A_LCD_SSC_SD, flag);
-
- OMAP_MCBSP_WRITE(OMAP1510_MCBSP3_BASE, PCR0, 0x2200);
- OMAP_MCBSP_WRITE(OMAP1510_MCBSP3_BASE, PCR0, 0x2202);
- for (i = 0; i < 8; i++) {
- OMAP_MCBSP_WRITE(OMAP1510_MCBSP3_BASE, PCR0, 0x2200);
- gpio_set_value(A_LCD_SSC_SD, shifter & byte);
- OMAP_MCBSP_WRITE(OMAP1510_MCBSP3_BASE, PCR0, 0x2202);
- shifter >>= 1;
-
git-pull request for omap-fixes for 2.6.28
Hi Russell, I have three trivial fixes for 2.6.28 that I'll post as a reply to this thread. Following is also the pull request for you assuming you don't have issues with these patches. Regards, Tony The following changes since commit 13d428afc007fcfcd6deeb215618f54cf9c0cae6: Linus Torvalds (1): Linux 2.6.28-rc6 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes Amit Kucheria (1): ARM: OMAP: Typo fix for clock_allow_idle Tero Kristo (1): ARM: OMAP: Fixes for suspend / resume GPIO wake-up handling Tony Lindgren (1): ARM: OMAP: Remove broken LCD driver for SX1 arch/arm/plat-omap/gpio.c|5 +- arch/arm/plat-omap/include/mach/pm.h |2 +- drivers/video/omap/Makefile |1 - drivers/video/omap/lcd_sx1.c | 327 -- 4 files changed, 4 insertions(+), 331 deletions(-) delete mode 100644 drivers/video/omap/lcd_sx1.c -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 0/3] OMAP_LDP support in linux-git tree
* Stanley.Miao <[EMAIL PROTECTED]> [081120 23:45]: > Changes from v1: > > 1, change omap_request_gpio() to gpio_request() in gpio.patch. One request: Since the LDP is in the mainline kernel, can you please provide whatever applies as patches against the mainline board-ldp.c? Then if some driver is not yet in mainline, provide that in an extra patch. That way I don't have to rewrite your patches for mainline ;) Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP Framebuffer memory allocation and mapping
* Hiremath, Vaibhav <[EMAIL PROTECTED]> [081120 03:25]: > > > Thanks, > Vaibhav Hiremath > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:linux-omap- > > [EMAIL PROTECTED] On Behalf Of Tomi Valkeinen > > Sent: Thursday, November 20, 2008 4:22 PM > > To: linux-omap@vger.kernel.org > > Subject: OMAP Framebuffer memory allocation and mapping > > > > Hi, > > > > I have a couple of questions regarding the memory management for the > > new > > display subsystem. > > > > The new DSS allocates memory with dma_alloc_writecombine() and mmaps > > it > > to user space with dma_mmap_writecombine(). Allocation is done when > > omapfb starts up. Normally memory gets very quickly too fragmented > > for > > dma_alloc_writecombine() to work, but setting > > CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE helps this. > > > > However, even when CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE is set to 14, > > I > > am, for some reason, not able to allocate 1280x1024x4 (~5.2M) > > framebuffer. Could the consistent DMA area be already too > > fragmented, or > > is there some size limit there? > > > [Hiremath, Vaibhav] Similar issue I had also faced while implementing VRFB > rotation on new DSS of yours. I increased the value of MAX_ORDER to 12 > (currently set to 11), defined in include/linux/mmzone.h file. And it worked > for me; I am allocating 2048*720*4 bytes of buffer. > > I am not sure community acceptance on this, probably somebody could suggest > better way to this. You might want to dump out the start and end address of you memory area and make sure it does not overlap with anything else. Earlier you had to reserve large areas during memory init.. I doubt that it's still the case though. See also Documentation/arm/memory.txt. Tony > > There's also support to allocate fb memory in very early phase with > > reserve_bootmem(), which needs a predefined physical address and > > size > > that can come from the bootloader. I've been looking at the old DSS > > to > > see how this memory should be mapped, but I haven't been able to get > > it > > to work. It looks like the DSS DMA and the user space have a bit > > different view of the memory, so my assumption is that there's some > > caching or similar being done. > > > > So how to setup the memory gotten from reserve_bootmem() (or > > alloc_bootmem()) so that it would work the same way as > > dma_alloc_writecombine()'s memory? > > > > And generally: any other ideas how to improve the memory management > > of > > the DSS? > > > > Tomi > > > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux- > > omap" in > > the body of a message to [EMAIL PROTECTED] > > 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 [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.28-rc6-omap] twl4030-power: minor cleanup
* David Brownell <[EMAIL PROTECTED]> [081126 13:09]:
> From: David Brownell <[EMAIL PROTECTED]>
>
> Minor cleanups to the twl4030 power script support: move its
> init code out of the "add children" call (it adds no children!),
> and move the power bus messages earlier in the header file to
> unclutter the platform data section and since they're not used
> only for those scripts.
Pushing to l-o tree.
Tony
> Signed-off-by: David Brownell <[EMAIL PROTECTED]>
> ---
> drivers/mfd/twl4030-core.c |7 +--
> include/linux/i2c/twl4030.h | 94 +-
> 2 files changed, 53 insertions(+), 48 deletions(-)
>
> --- a/drivers/mfd/twl4030-core.c
> +++ b/drivers/mfd/twl4030-core.c
> @@ -503,9 +503,6 @@ add_children(struct twl4030_platform_dat
> return PTR_ERR(child);
> }
>
> - if (twl_has_power() && pdata->power)
> - twl4030_power_init(pdata->power);
> -
> if (twl_has_rtc()) {
> /*
>* REVISIT platform_data here currently might expose the
> @@ -788,6 +785,10 @@ twl4030_probe(struct i2c_client *client,
> /* setup clock framework */
> clocks_init();
>
> + /* load power event scripts */
> + if (twl_has_power() && pdata->power)
> + twl4030_power_init(pdata->power);
> +
> /* Maybe init the T2 Interrupt subsystem */
> if (client->irq
> && pdata->irq_base
> --- a/include/linux/i2c/twl4030.h
> +++ b/include/linux/i2c/twl4030.h
> @@ -168,7 +168,7 @@ int twl4030_i2c_read(u8 mod_no, u8 *valu
> /*--*/
>
> /*
> - * Multichannel ADC register offsets (use TWL4030_MODULE_MADC)
> + * Monitoring ADC register offsets (use TWL4030_MODULE_MADC)
> * ... SIH/interrupt only
> */
>
> @@ -218,6 +218,53 @@ int twl4030_i2c_read(u8 mod_no, u8 *valu
>
> /*--*/
>
> +/* Power bus message definitions */
> +
> +#define DEV_GRP_NULL 0x0
> +#define DEV_GRP_P1 0x1
> +#define DEV_GRP_P2 0x2
> +#define DEV_GRP_P3 0x4
> +
> +#define RES_GRP_RES 0x0
> +#define RES_GRP_PP 0x1
> +#define RES_GRP_RC 0x2
> +#define RES_GRP_PP_RC0x3
> +#define RES_GRP_PR 0x4
> +#define RES_GRP_PP_PR0x5
> +#define RES_GRP_RC_PR0x6
> +#define RES_GRP_ALL 0x7
> +
> +#define RES_TYPE2_R0 0x0
> +
> +#define RES_TYPE_ALL 0x7
> +
> +#define RES_STATE_WRST 0xF
> +#define RES_STATE_ACTIVE 0xE
> +#define RES_STATE_SLEEP 0x8
> +#define RES_STATE_OFF0x0
> +
> +/*
> + * Power Bus Message Format ... these can be sent individually by Linux,
> + * but are usually part of downloaded scripts that are run when various
> + * power events are triggered.
> + *
> + * Broadcast Message (16 Bits):
> + *DEV_GRP[15:13] MT[12] RES_GRP[11:9] RES_TYPE2[8:7] RES_TYPE[6:4]
> + *RES_STATE[3:0]
> + *
> + * Singular Message (16 Bits):
> + *DEV_GRP[15:13] MT[12] RES_ID[11:4] RES_STATE[3:0]
> + */
> +
> +#define MSG_BROADCAST(devgrp, grp, type, type2, state) \
> + ( (devgrp) << 13 | 1 << 12 | (grp) << 9 | (type2) << 7 \
> + | (type) << 4 | (state))
> +
> +#define MSG_SINGULAR(devgrp, id, state) \
> + ((devgrp) << 13 | 0 << 12 | (id) << 4 | (state))
> +
> +/*--*/
> +
> struct twl4030_bci_platform_data {
> int *battery_tmp_tbl;
> unsigned int tblsize;
> @@ -281,60 +328,17 @@ struct twl4030_script {
> struct twl4030_ins *script;
> unsigned size;
> u8 flags;
> -};
> #define TRITON_WRST_SCRIPT (1<<0)
> #define TRITON_WAKEUP12_SCRIPT (1<<1)
> #define TRITON_WAKEUP3_SCRIPT(1<<2)
> #define TRITON_SLEEP_SCRIPT (1<<3)
> +};
>
> struct twl4030_power_data {
> struct twl4030_script **scripts;
> unsigned size;
> };
>
> -/* Power bus message definitions */
> -
> -#define DEV_GRP_NULL 0x0
> -#define DEV_GRP_P1 0x1
> -#define DEV_GRP_P2 0x2
> -#define DEV_GRP_P3 0x4
> -
> -#define RES_GRP_RES 0x0
> -#define RES_GRP_PP 0x1
> -#define RES_GRP_RC 0x2
> -#define RES_GRP_PP_RC0x3
> -#define RES_GRP_PR 0x4
> -#define RES_GRP_PP_PR0x5
> -#define RES_GRP_RC_PR0x6
> -#define RES_GRP_ALL 0x7
> -
> -#define RES_TYPE2_R0 0x0
> -
> -#define RES_TYPE_ALL 0x7
> -
> -#define RES_STATE_WRST 0xF
> -#define RES_STATE_ACTIVE 0xE
> -#define RES_STATE_SLEEP 0x8
> -#define RES_STATE_OFF0x0
> -
> -/*
> -*Power Bus Message Format
> -*
> -*Broadcast Message (16 Bits)
> -*DEV_GRP[15:13] MT[12] RES_GRP[11:9] RES_TYPE2[8:7] RES_TYPE[6:4]
> -*RES_STATE[3:0
Re: [patch 2.6.28-rc6-omap] twl4030: linkage fix for generic power scripts
* David Brownell <[EMAIL PROTECTED]> [081126 13:09]:
> From: David Brownell <[EMAIL PROTECTED]>
>
> Section fixes for generic twl4030 power scripts.
>
> NOTE: doesn't fix the bug whereby Beagle won't reset when
> these scripts are loaded. Or fix SDP section warnings.
Pushing to l-o tree.
Tony
> Signed-off-by: David Brownell <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/board-omap3beagle.c |2 +-
> arch/arm/mach-omap2/board-omap3evm.c |2 +-
> arch/arm/mach-omap2/board-overo.c |2 +-
> arch/arm/mach-omap2/twl4030-generic-scripts.c |3 +++
> arch/arm/mach-omap2/twl4030-generic-scripts.h |5 +
> 5 files changed, 11 insertions(+), 3 deletions(-)
>
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -206,7 +206,7 @@ static struct twl4030_platform_data beag
> /* platform_data for children goes here */
> .usb= &beagle_usb_data,
> .gpio = &beagle_gpio_data,
> - .power = &generic3430_t2scripts_data,
> + .power = GENERIC3430_T2SCRIPTS_DATA,
> .vmmc1 = &beagle_vmmc1,
> .vsim = &beagle_vsim,
> .vdac = &beagle_vdac,
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -139,7 +139,7 @@ static struct twl4030_platform_data omap
> .keypad = &omap3evm_kp_data,
> .madc = &omap3evm_madc_data,
> .usb= &omap3evm_usb_data,
> - .power = &generic3430_t2scripts_data,
> + .power = GENERIC3430_T2SCRIPTS_DATA,
> .gpio = &omap3evm_gpio_data,
> };
>
> --- a/arch/arm/mach-omap2/board-overo.c
> +++ b/arch/arm/mach-omap2/board-overo.c
> @@ -162,7 +162,7 @@ static struct twl4030_platform_data over
> .irq_end= TWL4030_IRQ_END,
> .gpio = &overo_gpio_data,
> .usb= &overo_usb_data,
> - .power = &generic3430_t2scripts_data,
> + .power = GENERIC3430_T2SCRIPTS_DATA,
> };
>
> static struct i2c_board_info __initdata overo_i2c_boardinfo[] = {
> --- a/arch/arm/mach-omap2/twl4030-generic-scripts.c
> +++ b/arch/arm/mach-omap2/twl4030-generic-scripts.c
> @@ -23,6 +23,8 @@
> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> */
>
> +#ifdef CONFIG_TWL4030_POWER
> +
> #include
> #include
> #include
> @@ -76,3 +78,4 @@ struct twl4030_power_data generic3430_t2
> };
>
>
> +#endif /* CONFIG_TWL4030_POWER */
> --- a/arch/arm/mach-omap2/twl4030-generic-scripts.h
> +++ b/arch/arm/mach-omap2/twl4030-generic-scripts.h
> @@ -3,6 +3,11 @@
>
> #include
>
> +#ifdef CONFIG_TWL4030_POWER
> extern struct twl4030_power_data generic3430_t2scripts_data;
> +#define GENERIC3430_T2SCRIPTS_DATA &generic3430_t2scripts_data
> +#else
> +#define GENERIC3430_T2SCRIPTS_DATA NULL
> +#endif /* CONFIG_TWL4030_POWER */
>
> #endif
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: MCSPI: Enable mcspi wake-up v2.
* David Brownell <[EMAIL PROTECTED]> [081126 10:41]: > On Wednesday 26 November 2008, Tony Lindgren wrote: > > * Jouni Hogander <[EMAIL PROTECTED]> [081118 23:48]: > > > Currently mcspi wake-ups are not enabled. This might cause case where > > > OMAP is not waking up on mcspi events. > > > > Dave, I assume you're picking these for your SPI queue? Will only > > apply to l-o if you ack and tell me so. > > OK... I'm not totally caught up there. Is this needed for > a 2.6.28-final merge? I'm guessing not; so it'd be OK to > queue for 2.6.29-final and have it in l-o until 29-rc1 gets > pulled down. Yes 2.6.29 timeline sounds fine to me at least. I'll apply these to l-o then. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: Fixes for suspend / resume GPIO wake-up handling
* Kevin Hilman <[EMAIL PROTECTED]> [081126 10:56]:
> Tero Kristo <[EMAIL PROTECTED]> writes:
>
> > Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
> > ---
> > arch/arm/plat-omap/gpio.c |4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
>
> Thanks, I'll pull this into the next PM branch, and this
> can go straight into linux-omap.
>
> Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
Pushing to l-o and adding to omap-fixes queue.
Tony
> > diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
> > index f4ec3af..62349fd 100644
> > --- a/arch/arm/plat-omap/gpio.c
> > +++ b/arch/arm/plat-omap/gpio.c
> > @@ -1585,7 +1585,7 @@ static int omap_gpio_suspend(struct sys_device *dev,
> > pm_message_t mesg)
> > #endif
> > #if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
> > case METHOD_GPIO_24XX:
> > - wake_status = bank->base + OMAP24XX_GPIO_SETWKUENA;
> > + wake_status = bank->base + OMAP24XX_GPIO_WAKE_EN;
> > wake_clear = bank->base + OMAP24XX_GPIO_CLEARWKUENA;
> > wake_set = bank->base + OMAP24XX_GPIO_SETWKUENA;
> > break;
> > @@ -1608,7 +1608,7 @@ static int omap_gpio_resume(struct sys_device *dev)
> > {
> > int i;
> >
> > - if (!cpu_is_omap24xx() && !cpu_is_omap16xx())
> > + if (!cpu_class_is_omap2() && !cpu_is_omap16xx())
> > return 0;
> >
> > for (i = 0; i < gpio_bank_count; i++) {
> > --
> > 1.5.4.3
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> > the body of a message to [EMAIL PROTECTED]
> > 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 [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP general SOC driver.
On Wednesday 26 November 2008, Mark Brown wrote: > > I wonder if > > it shouldn't suffice just to provide a mask of capabilities > > that are wired up on a given board. > > It's possible - if the differences can be handled by marking some pins > as connected or disconnected and possible specifying a different system > clock rate to the chip then that approach was what I was expecting. > If there is more substantial differences such as having the clocking > arranged differently then separate drivers start to make more sense. OK, from my non-expert perspective it sounds eminently do-able. By someone else. :) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP general SOC driver.
On Wed, Nov 26, 2008 at 12:44:33PM -0800, David Brownell wrote: > Let me insert a minor plug from the PM perspective that it would be > good to find a way that the codecs can sit in the proper places in > the driver model tree. Example with twl4030: it's an I2C device > and thus should be a child of something like This is exactly what I'm saying about allowing the machine, codec and platform drivers to probe separately. It's the major benefit of v2. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP general SOC driver.
On Wed, Nov 26, 2008 at 12:33:12PM -0800, David Brownell wrote: > And maybe more; that's just me summarizing unconnected pins, > not the datasheet. There are also cost-reduced parts with > less audio capability. ... > I make no claim about audio expertise -- the nearest I come > to it is observing a few years back that there was a huge > framework hole, which ASoC seems to fill -- but I wonder if > it shouldn't suffice just to provide a mask of capabilities > that are wired up on a given board. It's possible - if the differences can be handled by marking some pins as connected or disconnected and possible specifying a different system clock rate to the chip then that approach was what I was expecting. If there is more substantial differences such as having the clocking arranged differently then separate drivers start to make more sense. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2.6.28-rc6-omap] twl4030-power: minor cleanup
From: David Brownell <[EMAIL PROTECTED]>
Minor cleanups to the twl4030 power script support: move its
init code out of the "add children" call (it adds no children!),
and move the power bus messages earlier in the header file to
unclutter the platform data section and since they're not used
only for those scripts.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/mfd/twl4030-core.c |7 +--
include/linux/i2c/twl4030.h | 94 +-
2 files changed, 53 insertions(+), 48 deletions(-)
--- a/drivers/mfd/twl4030-core.c
+++ b/drivers/mfd/twl4030-core.c
@@ -503,9 +503,6 @@ add_children(struct twl4030_platform_dat
return PTR_ERR(child);
}
- if (twl_has_power() && pdata->power)
- twl4030_power_init(pdata->power);
-
if (twl_has_rtc()) {
/*
* REVISIT platform_data here currently might expose the
@@ -788,6 +785,10 @@ twl4030_probe(struct i2c_client *client,
/* setup clock framework */
clocks_init();
+ /* load power event scripts */
+ if (twl_has_power() && pdata->power)
+ twl4030_power_init(pdata->power);
+
/* Maybe init the T2 Interrupt subsystem */
if (client->irq
&& pdata->irq_base
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -168,7 +168,7 @@ int twl4030_i2c_read(u8 mod_no, u8 *valu
/*--*/
/*
- * Multichannel ADC register offsets (use TWL4030_MODULE_MADC)
+ * Monitoring ADC register offsets (use TWL4030_MODULE_MADC)
* ... SIH/interrupt only
*/
@@ -218,6 +218,53 @@ int twl4030_i2c_read(u8 mod_no, u8 *valu
/*--*/
+/* Power bus message definitions */
+
+#define DEV_GRP_NULL 0x0
+#define DEV_GRP_P1 0x1
+#define DEV_GRP_P2 0x2
+#define DEV_GRP_P3 0x4
+
+#define RES_GRP_RES0x0
+#define RES_GRP_PP 0x1
+#define RES_GRP_RC 0x2
+#define RES_GRP_PP_RC 0x3
+#define RES_GRP_PR 0x4
+#define RES_GRP_PP_PR 0x5
+#define RES_GRP_RC_PR 0x6
+#define RES_GRP_ALL0x7
+
+#define RES_TYPE2_R0 0x0
+
+#define RES_TYPE_ALL 0x7
+
+#define RES_STATE_WRST 0xF
+#define RES_STATE_ACTIVE 0xE
+#define RES_STATE_SLEEP0x8
+#define RES_STATE_OFF 0x0
+
+/*
+ * Power Bus Message Format ... these can be sent individually by Linux,
+ * but are usually part of downloaded scripts that are run when various
+ * power events are triggered.
+ *
+ * Broadcast Message (16 Bits):
+ *DEV_GRP[15:13] MT[12] RES_GRP[11:9] RES_TYPE2[8:7] RES_TYPE[6:4]
+ *RES_STATE[3:0]
+ *
+ * Singular Message (16 Bits):
+ *DEV_GRP[15:13] MT[12] RES_ID[11:4] RES_STATE[3:0]
+ */
+
+#define MSG_BROADCAST(devgrp, grp, type, type2, state) \
+ ( (devgrp) << 13 | 1 << 12 | (grp) << 9 | (type2) << 7 \
+ | (type) << 4 | (state))
+
+#define MSG_SINGULAR(devgrp, id, state) \
+ ((devgrp) << 13 | 0 << 12 | (id) << 4 | (state))
+
+/*--*/
+
struct twl4030_bci_platform_data {
int *battery_tmp_tbl;
unsigned int tblsize;
@@ -281,60 +328,17 @@ struct twl4030_script {
struct twl4030_ins *script;
unsigned size;
u8 flags;
-};
#define TRITON_WRST_SCRIPT (1<<0)
#define TRITON_WAKEUP12_SCRIPT (1<<1)
#define TRITON_WAKEUP3_SCRIPT (1<<2)
#define TRITON_SLEEP_SCRIPT(1<<3)
+};
struct twl4030_power_data {
struct twl4030_script **scripts;
unsigned size;
};
-/* Power bus message definitions */
-
-#define DEV_GRP_NULL 0x0
-#define DEV_GRP_P1 0x1
-#define DEV_GRP_P2 0x2
-#define DEV_GRP_P3 0x4
-
-#define RES_GRP_RES0x0
-#define RES_GRP_PP 0x1
-#define RES_GRP_RC 0x2
-#define RES_GRP_PP_RC 0x3
-#define RES_GRP_PR 0x4
-#define RES_GRP_PP_PR 0x5
-#define RES_GRP_RC_PR 0x6
-#define RES_GRP_ALL0x7
-
-#define RES_TYPE2_R0 0x0
-
-#define RES_TYPE_ALL 0x7
-
-#define RES_STATE_WRST 0xF
-#define RES_STATE_ACTIVE 0xE
-#define RES_STATE_SLEEP0x8
-#define RES_STATE_OFF 0x0
-
-/*
-* Power Bus Message Format
-*
-* Broadcast Message (16 Bits)
-* DEV_GRP[15:13] MT[12] RES_GRP[11:9] RES_TYPE2[8:7] RES_TYPE[6:4]
-* RES_STATE[3:0]
-*
-* Singular Message (16 Bits)
-* DEV_GRP[15:13] MT[12] RES_ID[11:4] RES_STATE[3:0]
-*
-*/
-
-#define MSG_BROADCAST(devgrp, grp, type, type2, state) \
- (devgrp << 13 | 1 << 12 | grp << 9 | type2 << 7 | type << 4 | state)
-
-#define MSG_SINGULAR(devgrp, id, state) \
- (devgrp << 13 | 0 << 12 | id << 4 | st
[patch 2.6.28-rc6-omap] twl4030: linkage fix for generic power scripts
From: David Brownell <[EMAIL PROTECTED]>
Section fixes for generic twl4030 power scripts.
NOTE: doesn't fix the bug whereby Beagle won't reset when
these scripts are loaded. Or fix SDP section warnings.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/board-omap3beagle.c |2 +-
arch/arm/mach-omap2/board-omap3evm.c |2 +-
arch/arm/mach-omap2/board-overo.c |2 +-
arch/arm/mach-omap2/twl4030-generic-scripts.c |3 +++
arch/arm/mach-omap2/twl4030-generic-scripts.h |5 +
5 files changed, 11 insertions(+), 3 deletions(-)
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -206,7 +206,7 @@ static struct twl4030_platform_data beag
/* platform_data for children goes here */
.usb= &beagle_usb_data,
.gpio = &beagle_gpio_data,
- .power = &generic3430_t2scripts_data,
+ .power = GENERIC3430_T2SCRIPTS_DATA,
.vmmc1 = &beagle_vmmc1,
.vsim = &beagle_vsim,
.vdac = &beagle_vdac,
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -139,7 +139,7 @@ static struct twl4030_platform_data omap
.keypad = &omap3evm_kp_data,
.madc = &omap3evm_madc_data,
.usb= &omap3evm_usb_data,
- .power = &generic3430_t2scripts_data,
+ .power = GENERIC3430_T2SCRIPTS_DATA,
.gpio = &omap3evm_gpio_data,
};
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -162,7 +162,7 @@ static struct twl4030_platform_data over
.irq_end= TWL4030_IRQ_END,
.gpio = &overo_gpio_data,
.usb= &overo_usb_data,
- .power = &generic3430_t2scripts_data,
+ .power = GENERIC3430_T2SCRIPTS_DATA,
};
static struct i2c_board_info __initdata overo_i2c_boardinfo[] = {
--- a/arch/arm/mach-omap2/twl4030-generic-scripts.c
+++ b/arch/arm/mach-omap2/twl4030-generic-scripts.c
@@ -23,6 +23,8 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
+#ifdef CONFIG_TWL4030_POWER
+
#include
#include
#include
@@ -76,3 +78,4 @@ struct twl4030_power_data generic3430_t2
};
+#endif /* CONFIG_TWL4030_POWER */
--- a/arch/arm/mach-omap2/twl4030-generic-scripts.h
+++ b/arch/arm/mach-omap2/twl4030-generic-scripts.h
@@ -3,6 +3,11 @@
#include
+#ifdef CONFIG_TWL4030_POWER
extern struct twl4030_power_data generic3430_t2scripts_data;
+#define GENERIC3430_T2SCRIPTS_DATA &generic3430_t2scripts_data
+#else
+#define GENERIC3430_T2SCRIPTS_DATA NULL
+#endif /* CONFIG_TWL4030_POWER */
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP general SOC driver.
On Wednesday 26 November 2008, Mark Brown wrote: > > I'm told that the ASoC stuff "should" go in a separate ASoC > > area for some reason. Â That still makes no good sense to me, > > so if there's a brief explanation as to why it's done that > > way, please fling me a URL. Â :) > > The move is in the direction you want but we're not there yet. Â The fact > that things are now decomposed enough for us to be able to think about > it is a good sign here. > > The biggest part of it is that the degree of coupling between the > various ASoC components is high - this is particularly obvious with v1 > where the entire card is probed at once. Â This includes coupling between > the drivers and the core where the degree of churn is very high right > now due to v2 merging. Â It doesn't feel right to give architectures an > API that they can't rely on from one merge window to the next yet, OK, that seems to be the key point. And it makes a lot of sense; I wouldn't call the driver structure here "simple", so it deserves some iteration on multiple disparate hardware platforms just to make sure the interfaces is adequate to the problem. Let me insert a minor plug from the PM perspective that it would be good to find a way that the codecs can sit in the proper places in the driver model tree. Example with twl4030: it's an I2C device and thus should be a child of something like /sys/devices/platform/i2c_omap.1/i2c-adapter/i2c-1/1-0049 to guarantee that for example nothing touches that codec after its parent I2C controller gets suspended. - Dave > partly from the point of view of isolating the code for review purposes > and also due to the merge issues which would doubtless crop up. > > Another part of it is that some machine drivers can get involved enough > to sit on or cross the boundary from platform data to being drivers for > substantial distinct hardware but that's very much not the case for > everything. > > I've been spending time this week working on getting the ability to load > platform and codec drivers independantly merged. Â That will at least > allow the instantiation of the ASoC drivers for those to be pushed out > into the architecture code, which is a start and should substantially > reduce the size of most machine drivers. Â At the point where that's been > done it's probably worth looking again at the simpler machine drivers. > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP general SOC driver.
On Wednesday 26 November 2008, Mark Brown wrote: > Can someone post an overview of what the hardware configurations of > these boards are, please? Â It's starting to sound like they're not very > similar at all. I only have schematics for Beagle ... which makes VERY minimal use of the twl4030 audio capabilities: - stereo "headset" output, without its mic - stereo aux-in Other twl4030 family boards *could* have: - microphone input for that headset - stereo "hands-off" speakers - mono earpiece output - two other microphone input channels And maybe more; that's just me summarizing unconnected pins, not the datasheet. There are also cost-reduced parts with less audio capability. I make no claim about audio expertise -- the nearest I come to it is observing a few years back that there was a huge framework hole, which ASoC seems to fill -- but I wonder if it shouldn't suffice just to provide a mask of capabilities that are wired up on a given board. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP general SOC driver.
Op 26 nov 2008, om 21:07 heeft Mark Brown het volgende geschreven: On Wed, Nov 26, 2008 at 10:34:41AM -0800, David Brownell wrote: Re TWL4030 codec configuration ... I count three microphone input channels not used on Beagle, plus a speaker output and some other stuff. So it's obvious that something which works on Beagle won't handle more interesting configurations of that audio support. Can someone post an overview of what the hardware configurations of these boards are, please? It's starting to sound like they're not very similar at all. On the codec level all these board use a variant of the TWL4030. The variants differ slightly in what kind of extra goodies they provide. On the board level not every feature of the TWL familiy is used, the beagle only analog in and analog out, the overo exposes more interfaces, etc. Other people can fill in the details, but these are the differences I can think of. regards, Koen PGP.sig Description: This is a digitally signed message part
Re: [PATCH] Add OMAP2 camera driver
On Wednesday 26 November 2008 19:44:51 Trilok Soni wrote: > This patch was living at linux-omap GIT tree from long time and seem > to survive the testing. It is also used in N800/N810 Internet Tablet. > Sakari Ailus can give more information about this. I am not able to > submit this patch as inline one due to my git-send-email > configuration with Gmail. Hi Trilok, I found a few problems with this patch: 1) The makefile isn't right: it compiles omap24xxcam.c and omap24xxcam-dma.c as two modules, but I suspect you want only one since the symbols that omap24xxcam.c needs from omap24xxcam-dma.c are not exported. See e.g. the msp3400 driver in the Makefile for how to do it. 2) The Kconfig is probably missing a ARCH_OMAP dependency (sounds reasonable, at least), so now it also compiles for the i686 but that architecture doesn't have a clk_get function. 3) I was wondering whether Sakari also wants to add a Signed-off-by line? Looking at the comments it seems that he was involved as well. 4) I get a bunch of compile warnings (admittedly when compiling for i686) that you might want to look at. Compiled against the 2.6.27 kernel with gcc-4.3.1. It might be bogus since I didn't compile for the omap architecture. CC [M] /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.o In file included from /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.c:42: /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h: In function 'omap24xxcam_reg_in': /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h:549: warning: passing argument 1 of 'readl' makes pointer from integer without a cast /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h: In function 'omap24xxcam_reg_out': /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h:555: warning: passing argument 2 of 'writel' makes pointer from integer without a cast /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h: In function 'omap24xxcam_reg_merge': /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h:563: warning: passing argument 1 of 'readl' makes pointer from integer without a cast /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h:565: warning: passing argument 2 of 'writel' makes pointer from integer without a cast CC [M] /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam-dma.o In file included from /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam-dma.c:32: /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h: In function 'omap24xxcam_reg_in': /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h:549: warning: passing argument 1 of 'readl' makes pointer from integer without a cast /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h: In function 'omap24xxcam_reg_out': /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h:555: warning: passing argument 2 of 'writel' makes pointer from integer without a cast /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h: In function 'omap24xxcam_reg_merge': /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h:563: warning: passing argument 1 of 'readl' makes pointer from integer without a cast /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h:565: warning: passing argument 2 of 'writel' makes pointer from integer without a cast /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam-dma.c: In function 'omap24xxcam_dma_hwinit': /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam-dma.c:357: warning: passing argument 1 of '_spin_lock_irqsave' discards qualifiers from pointer target type /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam-dma.c:361: warning: passing argument 1 of '_spin_unlock_irqrestore' discards qualifiers from pointer target type Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP general SOC driver.
On Wed, Nov 26, 2008 at 10:34:41AM -0800, David Brownell wrote: > Re TWL4030 codec configuration ... I count three microphone > input channels not used on Beagle, plus a speaker output > and some other stuff. So it's obvious that something which > works on Beagle won't handle more interesting configurations > of that audio support. Can someone post an overview of what the hardware configurations of these boards are, please? It's starting to sound like they're not very similar at all. > I'm told that the ASoC stuff "should" go in a separate ASoC > area for some reason. That still makes no good sense to me, > so if there's a brief explanation as to why it's done that > way, please fling me a URL. :) The move is in the direction you want but we're not there yet. The fact that things are now decomposed enough for us to be able to think about it is a good sign here. The biggest part of it is that the degree of coupling between the various ASoC components is high - this is particularly obvious with v1 where the entire card is probed at once. This includes coupling between the drivers and the core where the degree of churn is very high right now due to v2 merging. It doesn't feel right to give architectures an API that they can't rely on from one merge window to the next yet, partly from the point of view of isolating the code for review purposes and also due to the merge issues which would doubtless crop up. Another part of it is that some machine drivers can get involved enough to sit on or cross the boundary from platform data to being drivers for substantial distinct hardware but that's very much not the case for everything. I've been spending time this week working on getting the ability to load platform and codec drivers independantly merged. That will at least allow the instantiation of the ASoC drivers for those to be pushed out into the architecture code, which is a start and should substantially reduce the size of most machine drivers. At the point where that's been done it's probably worth looking again at the simpler machine drivers. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix crash on non-3430SDP platforms with DVFS/CPUFreq
"Rajendra Nayak" <[EMAIL PROTECTED]> writes:
> The SRF/DVFS + CPUFreq patches had issues booting on
> non-3430SDP platforms as reported by Kevin Hilman.
> This patch puts non-NULL checks in place for mpu_opps/dsp_opps
> /l3_opps before accessing them and fixes the issue.
>
> This fix/patch can be applied on top of
> pm-20081119 branch
> + [PATCH 00/08] OMAP3 SRF: OPP and Frequency resources
> + [PATCH 00/03] OMAP3 PM: CPUFreq driver for OMAP3
Thanks, I'll pull this fix along with the above two series into
the next PM branch (which should be out later today.)
Kevin
> Signed-off-by: Rajendra Nayak <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/clock34xx.c| 33
> -
> arch/arm/mach-omap2/pm.h | 18 ---
> arch/arm/mach-omap2/resource34xx.c | 21 ++
> arch/arm/plat-omap/cpu-omap.c |6 +
> arch/arm/plat-omap/include/mach/omap34xx.h | 18 +++
> 5 files changed, 64 insertions(+), 32 deletions(-)
>
> Index: linux-omap-2.6/arch/arm/mach-omap2/clock34xx.c
> ===
> --- linux-omap-2.6.orig/arch/arm/mach-omap2/clock34xx.c 2008-11-26
> 17:43:12.011090533 +0530
> +++ linux-omap-2.6/arch/arm/mach-omap2/clock34xx.c2008-11-26
> 17:47:40.551795371 +0530
> @@ -666,6 +666,9 @@ void omap2_clk_init_cpufreq_table(struct
> struct omap_opp *prcm;
> int i = 0;
>
> + if (!mpu_opps)
> + return;
> +
> /* Avoid registering the 120% Overdrive with CPUFreq */
> prcm = mpu_opps + MAX_VDD1_OPP - 1;
> for (; prcm->rate; prcm--) {
> @@ -798,20 +801,24 @@ int __init omap2_clk_init(void)
> dpll3_clk = clk_get(NULL, "dpll3_m2_ck");
>
> mpu_speed = dpll1_clk->rate;
> - prcm_vdd = mpu_opps + MAX_VDD1_OPP;
> - for (; prcm_vdd->rate; prcm_vdd--) {
> - if (prcm_vdd->rate <= mpu_speed) {
> - curr_vdd1_prcm_set = prcm_vdd;
> - break;
> + if (mpu_opps) {
> + prcm_vdd = mpu_opps + MAX_VDD1_OPP;
> + for (; prcm_vdd->rate; prcm_vdd--) {
> + if (prcm_vdd->rate <= mpu_speed) {
> + curr_vdd1_prcm_set = prcm_vdd;
> + break;
> + }
> }
> }
>
> core_speed = dpll3_clk->rate;
> - prcm_vdd = l3_opps + MAX_VDD2_OPP;
> - for (; prcm_vdd->rate; prcm_vdd--) {
> - if (prcm_vdd->rate <= core_speed) {
> - curr_vdd2_prcm_set = prcm_vdd;
> - break;
> + if (l3_opps) {
> + prcm_vdd = l3_opps + MAX_VDD2_OPP;
> + for (; prcm_vdd->rate; prcm_vdd--) {
> + if (prcm_vdd->rate <= core_speed) {
> + curr_vdd2_prcm_set = prcm_vdd;
> + break;
> + }
> }
> }
>
> @@ -878,6 +885,9 @@ static long omap3_round_to_table_rate(st
> if ((clk != &virt_vdd1_prcm_set) && (clk != &virt_vdd2_prcm_set))
> return -EINVAL;
>
> + if (!mpu_opps || !dsp_opps || !l3_opps)
> + return -EINVAL;
> +
> highest_rate = -EINVAL;
>
> if (clk == &virt_vdd1_prcm_set)
> @@ -904,6 +914,9 @@ static int omap3_select_table_rate(struc
> if ((clk != &virt_vdd1_prcm_set) && (clk != &virt_vdd2_prcm_set))
> return -EINVAL;
>
> + if (!mpu_opps || !dsp_opps || !l3_opps)
> + return -EINVAL;
> +
> if (clk == &virt_vdd1_prcm_set) {
> prcm_vdd = mpu_opps + MAX_VDD1_OPP;
> index = MAX_VDD1_OPP;
> Index: linux-omap-2.6/arch/arm/mach-omap2/pm.h
> ===
> --- linux-omap-2.6.orig/arch/arm/mach-omap2/pm.h 2008-11-26
> 17:43:12.011090533 +0530
> +++ linux-omap-2.6/arch/arm/mach-omap2/pm.h 2008-11-26 17:47:40.552795340
> +0530
> @@ -39,24 +39,6 @@ extern void omap3_pm_off_mode_enable(int
> #endif
> extern int set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
>
> -
> -/* VDD1 OPPS */
> -#define VDD1_OPP10x1
> -#define VDD1_OPP20x2
> -#define VDD1_OPP30x3
> -#define VDD1_OPP40x4
> -#define VDD1_OPP50x5
> -
> -/* VDD2 OPPS */
> -#define VDD2_OPP10x1
> -#define VDD2_OPP20x2
> -#define VDD2_OPP30x3
> -
> -#define MIN_VDD1_OPP VDD1_OPP1
> -#define MAX_VDD1_OPP VDD1_OPP5
> -#define MIN_VDD2_OPP VDD2_OPP1
> -#define MAX_VDD2_OPP VDD2_OPP3
> -
> #ifdef CONFIG_PM_DEBUG
> extern u32 omap2_read_32k_sync_counter(void);
> extern void omap2_pm_dump(int mode, int resume, unsigned int us);
> Index: linux-omap-2.6/arch/arm/mach-omap2/resource34xx.c
> ===
> --- linux-omap-2.6.orig/arch/arm/mach-omap2/resource34xx.c2008-11-26
> 17:43:12.011090533 +0530
> +++ linux-omap-2.6/arch
Re: [PATCH] OMAP3: PM: readability fix for IVA2 DPLL autoidle
* Paul Walmsley <[EMAIL PROTECTED]> [081125 09:07]: > On Tue, 25 Nov 2008, Kevin Hilman wrote: > > > No functional change, just a readability fix. > > > > The symbolic name of the shift value used in writing > > CM_AUTOIDLE_PLL_IVA2 referred values in the CM_CLKSTCTRL_IVA2 > > register. Fix this to use the AUTOIDLE fields. > > > > Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]> > > Acked-by: Paul Walmsley <[EMAIL PROTECTED]> Pushing today. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] OMAP: HSMMC: Make driver support dynamic idle
* Adrian Hunter <[EMAIL PROTECTED]> [081121 01:15]:
> Add a timer that is kept active by MMC requests. FCLK is disabled on timeout
Let's keep these patches on hold until we have the hsmmc.c driver in
mainline, then get them integrated via LKML.
Meanwhile, maybe you want to set up a git branch for hsmmc to queue these?
And then I could mirror your hsmmc branch.
Regards,
Tony
> Signed-off-by: Amit Kucheria <[EMAIL PROTECTED]>
> ---
> drivers/mmc/host/omap_hsmmc.c | 73 +---
> 1 files changed, 60 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 0df6841..ee21a64 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -121,6 +121,9 @@
> #define OMAP_HSMMC_WRITE(base, reg, val) \
> __raw_writel((val), (base) + OMAP_HSMMC_##reg)
>
> +enum {OFF = 0, ON};
> +#define IDLE_TIMEOUT (5*HZ)
> +
> struct mmc_omap_host {
> struct device *dev;
> struct mmc_host*mmc;
> @@ -148,9 +151,50 @@ struct mmc_omap_host {
> int initstr;
> int slot_id;
> int dbclk_enabled;
> +
> + struct timer_list idle_timer;
> + spinlock_t clk_lock; /* for changing enabled state */
> + int fclk_enabled:1;
> +
> struct omap_mmc_platform_data *pdata;
> };
>
> +int mmc_omap_fclk_state(struct mmc_omap_host *host, unsigned int state)
> +{
> + unsigned long flags;
> + int ret;
> +
> + spin_lock_irqsave(&host->clk_lock, flags);
> + if (host->fclk_enabled != state) {
> + if (state == ON) {
> + if (host->fclk_enabled == OFF) {
> + ret = clk_enable(host->fclk);
> + if (ret != 0)
> + return ret;
> + dev_dbg(mmc_dev(host->mmc),
> + "mmc_fclk: enabled\n");
> + }
> + /* Revisit: Change the timer bump based on real
> +MMC usage characteristics */
> + mod_timer(&host->idle_timer, jiffies + IDLE_TIMEOUT);
> + } else {
> + clk_disable(host->fclk);
> + dev_dbg(mmc_dev(host->mmc), "mmc_fclk: disabled\n");
> + del_timer(&host->idle_timer);
> + }
> + host->fclk_enabled = state;
> + }
> + spin_unlock_irqrestore(&host->clk_lock, flags);
> + return 0;
> +}
> +
> +static void mmc_omap_idle_timer(unsigned long data)
> +{
> + struct mmc_omap_host *host = (struct mmc_omap_host *) data;
> +
> + mmc_omap_fclk_state(host, OFF);
> +}
> +
> /*
> * Stop clock to the card
> */
> @@ -457,7 +501,7 @@ static int omap_mmc_switch_opcond(struct mmc_omap_host
> *host, int vdd)
> int ret;
>
> /* Disable the clocks */
> - clk_disable(host->fclk);
> + mmc_omap_fclk_state(host, OFF);
> clk_disable(host->iclk);
> clk_disable(host->dbclk);
>
> @@ -471,7 +515,7 @@ static int omap_mmc_switch_opcond(struct mmc_omap_host
> *host, int vdd)
> if (ret != 0)
> goto err;
>
> - clk_enable(host->fclk);
> + mmc_omap_fclk_state(host, ON);
> clk_enable(host->iclk);
> clk_enable(host->dbclk);
>
> @@ -742,10 +786,10 @@ static void omap_mmc_request(struct mmc_host *mmc,
> struct mmc_request *req)
> WARN_ON(host->mrq != NULL);
> host->mrq = req;
> mmc_omap_prepare_data(host, req);
> + mmc_omap_fclk_state(host, ON);
> mmc_omap_start_command(host, req->cmd, req->data);
> }
>
> -
> /* Routine to configure clock values. Exposed API to core */
> static void omap_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
> {
> @@ -824,6 +868,7 @@ static void omap_mmc_set_ios(struct mmc_host *mmc, struct
> mmc_ios *ios)
> if (ios->bus_mode == MMC_BUSMODE_OPENDRAIN)
> OMAP_HSMMC_WRITE(host->base, CON,
> OMAP_HSMMC_READ(host->base, CON) | OD);
> +
> }
>
> static int omap_hsmmc_get_cd(struct mmc_host *mmc)
> @@ -860,7 +905,7 @@ static int __init omap_mmc_probe(struct platform_device
> *pdev)
> struct mmc_host *mmc;
> struct mmc_omap_host *host = NULL;
> struct resource *res;
> - int ret = 0, irq;
> + int ret = 0, irq, reg;
> u32 hctl, capa;
>
> if (pdata == NULL) {
> @@ -925,14 +970,17 @@ static int __init omap_mmc_probe(struct platform_device
> *pdev)
> goto err1;
> }
>
> - if (clk_enable(host->fclk) != 0) {
> + spin_lock_init(&host->clk_lock);
> + setup_timer(&host->idle_timer, mmc_omap_idle_timer,
> + (unsigned long) host);
> +
> + if (mmc_omap_fclk_state(host, ON) != 0) {
> clk_put(host->iclk);
> clk_put(host->fclk);
> goto err1
Re: [PATCH 3/9] OMAP: HSMMC: Make fclk disable request driven.
* Adrian Hunter <[EMAIL PROTECTED]> [081121 01:16]:
> Start idle timer only at the end of request or request like operation
> such card detect, set_ios, probe, or resume. This will ensure the fclk is
> disable quickly after the operation is done, but never too early.
>From merging into mainline point of view, maybe this should be merged into
the earlier patch for adding the idle timer?
Tony
> Signed-off-by: Jarkko Lavinen <[EMAIL PROTECTED]>
> ---
> drivers/mmc/host/omap_hsmmc.c | 15 ++-
> 1 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 2eed691..a134f76 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -122,7 +122,7 @@
> __raw_writel((val), (base) + OMAP_HSMMC_##reg)
>
> enum {OFF = 0, ON};
> -#define IDLE_TIMEOUT (5*HZ)
> +#define IDLE_TIMEOUT (jiffies_to_msecs(10))
>
> struct mmc_omap_host {
> struct device *dev;
> @@ -165,6 +165,7 @@ static int mmc_omap_fclk_state(struct mmc_omap_host
> *host, unsigned int state)
> int ret = 0;
>
> spin_lock_irqsave(&host->clk_lock, flags);
> + del_timer(&host->idle_timer);
> if (host->fclk_enabled != state) {
> if (state == ON) {
> ret = clk_enable(host->fclk);
> @@ -172,13 +173,9 @@ static int mmc_omap_fclk_state(struct mmc_omap_host
> *host, unsigned int state)
> goto err_out;
>
> dev_dbg(mmc_dev(host->mmc), "mmc_fclk: enabled\n");
> - /* Revisit: Change the timer bump based on real
> -MMC usage characteristics */
> - mod_timer(&host->idle_timer, jiffies + IDLE_TIMEOUT);
> } else {
> clk_disable(host->fclk);
> dev_dbg(mmc_dev(host->mmc), "mmc_fclk: disabled\n");
> - del_timer(&host->idle_timer);
> }
> host->fclk_enabled = state;
> }
> @@ -335,6 +332,7 @@ mmc_omap_xfer_done(struct mmc_omap_host *host, struct
> mmc_data *data)
>
> if (!data->stop) {
> host->mrq = NULL;
> + mod_timer(&host->idle_timer, jiffies + IDLE_TIMEOUT);
> mmc_request_done(host->mmc, data->mrq);
> return;
> }
> @@ -363,6 +361,7 @@ mmc_omap_cmd_done(struct mmc_omap_host *host, struct
> mmc_command *cmd)
> }
> if (host->data == NULL || cmd->error) {
> host->mrq = NULL;
> + mod_timer(&host->idle_timer, jiffies + IDLE_TIMEOUT);
> mmc_request_done(host->mmc, cmd->mrq);
> }
> }
> @@ -575,6 +574,7 @@ static void mmc_omap_detect(struct work_struct *work)
> while (OMAP_HSMMC_READ(host->base, SYSCTL) & SRD) ;
> mmc_detect_change(host->mmc, (HZ * 50) / 1000);
> }
> + mod_timer(&host->idle_timer, jiffies + IDLE_TIMEOUT);
> }
>
> /*
> @@ -874,6 +874,8 @@ static void omap_mmc_set_ios(struct mmc_host *mmc, struct
> mmc_ios *ios)
>
> if (ios->power_mode == MMC_POWER_OFF)
> mmc_omap_fclk_state(host, OFF);
> + else
> + mod_timer(&host->idle_timer, jiffies + IDLE_TIMEOUT);
> }
>
> static int omap_hsmmc_get_cd(struct mmc_host *mmc)
> @@ -1088,6 +1090,7 @@ static int __init omap_mmc_probe(struct platform_device
> *pdev)
> if (ret < 0)
> goto err_cover_switch;
> }
> + mod_timer(&host->idle_timer, jiffies + IDLE_TIMEOUT);
>
> return 0;
>
> @@ -1250,6 +1253,8 @@ static int omap_mmc_resume(struct platform_device *pdev)
> ret = mmc_resume_host(host->mmc);
> if (ret == 0)
> host->suspended = 0;
> +
> + mod_timer(&host->idle_timer, jiffies + IDLE_TIMEOUT);
> }
>
> return ret;
> --
> 1.5.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: Fixes for suspend / resume GPIO wake-up handling
Tero Kristo <[EMAIL PROTECTED]> writes:
> Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
> ---
> arch/arm/plat-omap/gpio.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
Thanks, I'll pull this into the next PM branch, and this
can go straight into linux-omap.
Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
> index f4ec3af..62349fd 100644
> --- a/arch/arm/plat-omap/gpio.c
> +++ b/arch/arm/plat-omap/gpio.c
> @@ -1585,7 +1585,7 @@ static int omap_gpio_suspend(struct sys_device *dev,
> pm_message_t mesg)
> #endif
> #if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
> case METHOD_GPIO_24XX:
> - wake_status = bank->base + OMAP24XX_GPIO_SETWKUENA;
> + wake_status = bank->base + OMAP24XX_GPIO_WAKE_EN;
> wake_clear = bank->base + OMAP24XX_GPIO_CLEARWKUENA;
> wake_set = bank->base + OMAP24XX_GPIO_SETWKUENA;
> break;
> @@ -1608,7 +1608,7 @@ static int omap_gpio_resume(struct sys_device *dev)
> {
> int i;
>
> - if (!cpu_is_omap24xx() && !cpu_is_omap16xx())
> + if (!cpu_class_is_omap2() && !cpu_is_omap16xx())
> return 0;
>
> for (i = 0; i < gpio_bank_count; i++) {
> --
> 1.5.4.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PM: Added suspend target state control to debugfs for OMAP3
Tero Kristo <[EMAIL PROTECTED]> writes:
> Target state can be read / programmed via files under:
> [debugfs]/pm_debug/[pwrdm]/suspend
>
> Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
Thanks, pulling into next PM branch.
Kevin
> ---
> arch/arm/mach-omap2/pm-debug.c | 30 --
> arch/arm/mach-omap2/pm.h |4
> arch/arm/mach-omap2/pm34xx.c | 24
> 3 files changed, 56 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
> index 82219f4..ac61d15 100644
> --- a/arch/arm/mach-omap2/pm-debug.c
> +++ b/arch/arm/mach-omap2/pm-debug.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -511,11 +512,28 @@ int pm_dbg_regset_init(int reg_set)
> return 0;
> }
>
> -static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
> +static int pwrdm_suspend_get(void *data, u64 *val)
> +{
> + *val = omap3_pm_get_suspend_state((struct powerdomain *)data);
> +
> + if (*val >= 0)
> + return 0;
> + return *val;
> +}
> +
> +static int pwrdm_suspend_set(void *data, u64 val)
> +{
> + return omap3_pm_set_suspend_state((struct powerdomain *)data, (int)val);
> +}
> +
> +DEFINE_SIMPLE_ATTRIBUTE(pwrdm_suspend_fops, pwrdm_suspend_get,
> pwrdm_suspend_set, "%llu\n");
> +
> +static int __init pwrdms_setup(struct powerdomain *pwrdm, void *dir)
> {
> int i;
> s64 t;
> struct timespec now;
> + struct dentry *d;
>
> getnstimeofday(&now);
> t = timespec_to_ns(&now);
> @@ -525,6 +543,14 @@ static int __init pwrdms_setup(struct powerdomain
> *pwrdm, void *unused)
>
> pwrdm->timer = t;
>
> + if (strncmp(pwrdm->name, "dpll", 4) == 0)
> + return 0;
> +
> + d = debugfs_create_dir(pwrdm->name, (struct dentry *)dir);
> +
> + (void) debugfs_create_file("suspend", S_IRUGO|S_IWUSR, d,
> + (void *)pwrdm, &pwrdm_suspend_fops);
> +
> return 0;
> }
>
> @@ -545,7 +571,7 @@ static int __init pm_dbg_init(void)
> (void) debugfs_create_file("time", S_IRUGO,
> d, (void *)DEBUG_FILE_TIMERS, &debug_fops);
>
> - pwrdm_for_each(pwrdms_setup, NULL);
> + pwrdm_for_each(pwrdms_setup, (void *)d);
>
> pm_dbg_dir = debugfs_create_dir("registers", d);
> if (IS_ERR(pm_dbg_dir))
> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
> index 4b1ba7c..78fde57 100644
> --- a/arch/arm/mach-omap2/pm.h
> +++ b/arch/arm/mach-omap2/pm.h
> @@ -34,8 +34,12 @@ extern void omap2_block_sleep(void);
> extern void omap2_allow_sleep(void);
> #ifdef CONFIG_ARCH_OMAP3
> extern void omap3_pm_off_mode_enable(int);
> +extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
> +extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
> #else
> #define omap3_pm_off_mode_enable(int) do {} while (0);
> +#define omap3_pm_get_suspend_state(pwrdm) do {} while (0);
> +#define omap3_pm_set_suspend_state(pwrdm,state) do {} while (0);
> #endif
> extern int set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 191299c..73ac22c 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -780,6 +780,30 @@ void omap3_pm_off_mode_enable(int enable)
> }
> }
>
> +int omap3_pm_get_suspend_state(struct powerdomain *pwrdm)
> +{
> + struct power_state *pwrst;
> +
> + list_for_each_entry(pwrst, &pwrst_list, node) {
> + if (pwrst->pwrdm == pwrdm)
> + return pwrst->next_state;
> + }
> + return -EINVAL;
> +}
> +
> +int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state)
> +{
> + struct power_state *pwrst;
> +
> + list_for_each_entry(pwrst, &pwrst_list, node) {
> + if (pwrst->pwrdm == pwrdm) {
> + pwrst->next_state = state;
> + return 0;
> + }
> + }
> + return -EINVAL;
> +}
> +
> static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
> {
> struct power_state *pwrst;
> --
> 1.5.4.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] Save sram context after changing MPU, DSP or core clocks
"Peter 'p2' De Schrijver" <[EMAIL PROTECTED]> writes: > This patch saves the sram context again after a MPU,DSP or core clock > frequency change. This is necessary so the rom code can restore the correct > DPLL settings when resuming from off mode. Thanks to Rajendra Nayak for > suggesting the problem and coming up with the same fix at about the same time. > Thanks, pulling into next PM branch. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP2/3 GPTIMER: skip unnecessary TLDR write during non-autoreload
* Kevin Hilman <[EMAIL PROTECTED]> [081126 10:39]: > "Woodruff, Richard" <[EMAIL PROTECTED]> writes: > > >> * Woodruff, Richard <[EMAIL PROTECTED]> [081014 12:47]: > >> > > omap_dm_timer_write_reg(timer, OMAP_TIMER_COUNTER_REG, load); > >> > > - omap_dm_timer_write_reg(timer, OMAP_TIMER_LOAD_REG, load); > >> > > omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l); > >> > > } > >> > > >> > I seem to recall there was a missed interrupt condition which this worked > >> around. > >> > > >> > IIRC, the original code didn't bother with the load I added back as a > >> > work > >> around as a way to get posted mode working. > >> > >> Well these seem to be working based on some quick timer tests. > >> Pushing so we can verify it ;) > > > > This kind of change might be better tested on the PM branch. It's > > the kind of thing more likely to work with PM disabled. Testing in > > both is good, PM for many things is less forgiving... > > I validated these patches on the PM branch. > > I used cyclictest to test lots of timer reprogramming, and also tested > in both RET-while-idle and OFF-while-idle for low frequency timer > reprogramming. > > Acked-by: Kevin Hilman <[EMAIL PROTECTED]> Thanks for testing, pushing them to l-o today and adding to omap2-upstream queue. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: MCSPI: Enable mcspi wake-up v2.
On Wednesday 26 November 2008, Tony Lindgren wrote: > * Jouni Hogander <[EMAIL PROTECTED]> [081118 23:48]: > > Currently mcspi wake-ups are not enabled. This might cause case where > > OMAP is not waking up on mcspi events. > > Dave, I assume you're picking these for your SPI queue? Will only > apply to l-o if you ack and tell me so. OK... I'm not totally caught up there. Is this needed for a 2.6.28-final merge? I'm guessing not; so it'd be OK to queue for 2.6.29-final and have it in l-o until 29-rc1 gets pulled down. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][OMAPZOOM][2/2] Disable OV3640 sensor support in omap_zoom2_defconfig file
OV3640 smart sensor is not supported on zoom2 platform. Signed-off-by: Leed Aguilar <[EMAIL PROTECTED]> Ack-by: Dominic Curran <[EMAIL PROTECTED]> --- arch/arm/configs/omap_zoom2_defconfig |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/arm/configs/omap_zoom2_defconfig b/arch/arm/configs/omap_zoom2_defconfig index cf73335..fd8377c 100644 --- a/arch/arm/configs/omap_zoom2_defconfig +++ b/arch/arm/configs/omap_zoom2_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.27-omap1 -# Fri Nov 7 13:16:24 2008 +# Wed Nov 26 12:18:23 2008 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y @@ -957,8 +957,7 @@ CONFIG_VIDEO_CAPTURE_DRIVERS=y # CONFIG_VIDEO_OV9640 is not set # CONFIG_VIDEO_MT9P012 is not set # CONFIG_VIDEO_DW9710 is not set -CONFIG_VIDEO_OV3640=y -CONFIG_VIDEO_OV3640_CSI2=y +# CONFIG_VIDEO_OV3640 is not set # CONFIG_VIDEO_SAA711X is not set # CONFIG_VIDEO_SAA717X is not set # CONFIG_VIDEO_TVP5150 is not set -- 1.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][OMAPZOOM][1/2] Cleanup for zoom2 board file: OV3640 sensor is not supported
OmniVision ov3640 smart sensor driver (3MP) is not supported
on ZOOM2 board.
Signed-off-by: Leed Aguilar <[EMAIL PROTECTED]>
Ack-by: Dominic Curran <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/board-zoom2.c | 213 +
1 files changed, 1 insertions(+), 212 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom2.c
b/arch/arm/mach-omap2/board-zoom2.c
index 6bbf6cc..c823750 100755
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -47,28 +47,6 @@
#include
#endif
-#ifdef CONFIG_VIDEO_OMAP3
-#include
-#include <../drivers/media/video/omap34xxcam.h>
-#include <../drivers/media/video/isp/ispreg.h>
-#if defined(CONFIG_VIDEO_OV3640) || defined(CONFIG_VIDEO_OV3640_MODULE)
-#include <../drivers/media/video/ov3640.h>
-#include <../drivers/media/video/isp/ispcsi2.h>
-static struct omap34xxcam_hw_config *hwc;
-#define OV3640_CSI2_CLOCK_POLARITY 0 /* +/- pin order */
-#define OV3640_CSI2_DATA0_POLARITY 0 /* +/- pin order */
-#define OV3640_CSI2_DATA1_POLARITY 0 /* +/- pin order */
-#define OV3640_CSI2_CLOCK_LANE 1/* Clock lane position: 1 */
-#define OV3640_CSI2_DATA0_LANE 2/* Data0 lane position: 2 */
-#define OV3640_CSI2_DATA1_LANE 3/* Data1 lane position: 3 */
-#define OV3640_CSI2_PHY_THS_TERM 4
-#define OV3640_CSI2_PHY_THS_SETTLE 14
-#define OV3640_CSI2_PHY_TCLK_TERM 0
-#define OV3640_CSI2_PHY_TCLK_MISS 1
-#define OV3640_CSI2_PHY_TCLK_SETTLE14
-#endif
-#endif
-
#define SDP3430_SMC91X_CS3
#define ENABLE_VAUX1_DEDICATED 0x03
#define ENABLE_VAUX1_DEV_GRP 0x20
@@ -311,7 +289,6 @@ static struct twl4030_keypad_data ldp_kp_twl4030_data = {
.rep= 1,
.irq= TWL4030_MODIRQ_KEYPAD,
};
-static int ts_gpio;
static int __init msecure_init(void)
{
@@ -484,182 +461,6 @@ static struct twl4030_platform_data ldp_twldata = {
.keypad = &ldp_kp_twl4030_data,
};
-#if defined(CONFIG_VIDEO_OV3640) || defined(CONFIG_VIDEO_OV3640_MODULE)
-
-static struct omap34xxcam_sensor_config ov3640_hwc = {
- .sensor_isp = 0,
-#if defined(CONFIG_VIDEO_OV3640_CSI2)
- .xclk = OMAP34XXCAM_XCLK_B,
-#else
- .xclk = OMAP34XXCAM_XCLK_A,
-#endif
- .capture_mem = 2592 * 1944 * 2 * 2,
-};
-
-static struct isp_interface_config ov3640_if_config = {
- .ccdc_par_ser = ISP_CSIA,
- .dataline_shift = 0x0,
- .hsvs_syncdetect = ISPCTRL_SYNC_DETECT_VSRISE,
- .vdint0_timing = 0x0,
- .vdint1_timing = 0x0,
- .strobe = 0x0,
- .prestrobe = 0x0,
- .shutter = 0x0,
- .prev_sph = 2,
- .prev_slv = 1,
- .wenlog = ISPCCDC_CFG_WENLOG_AND,
- .u.csi.crc = 0x0,
- .u.csi.mode = 0x0,
- .u.csi.edge = 0x0,
- .u.csi.signalling = 0x0,
- .u.csi.strobe_clock_inv = 0x0,
- .u.csi.vs_edge = 0x0,
- .u.csi.channel = 0x1,
- .u.csi.vpclk = 0x1,
- .u.csi.data_start = 0x0,
- .u.csi.data_size = 0x0,
- .u.csi.format = V4L2_PIX_FMT_SGRBG10,
-};
-
-static int ov3640_sensor_set_prv_data(void *priv)
-{
-
- hwc = priv;
- hwc->u.sensor.xclk = ov3640_hwc.xclk;
- hwc->u.sensor.sensor_isp = ov3640_hwc.sensor_isp;
- hwc->dev_index = 1;
- hwc->dev_minor = 4;
- hwc->dev_type = OMAP34XXCAM_SLAVE_SENSOR;
- hwc->interface_type = ISP_CSIA;
-
-#if defined(CONFIG_VIDEO_OV3640_CSI2)
- hwc->csi2.hw_csi2.lanes.clock.polarity = OV3640_CSI2_CLOCK_POLARITY;
- hwc->csi2.hw_csi2.lanes.clock.position = OV3640_CSI2_CLOCK_LANE;
- hwc->csi2.hw_csi2.lanes.data[0].polarity = OV3640_CSI2_DATA0_POLARITY;
- hwc->csi2.hw_csi2.lanes.data[0].position = OV3640_CSI2_DATA0_LANE;
- hwc->csi2.hw_csi2.lanes.data[1].polarity = OV3640_CSI2_DATA1_POLARITY;
- hwc->csi2.hw_csi2.lanes.data[1].position = OV3640_CSI2_DATA1_LANE;
- hwc->csi2.hw_csi2.phy.ths_term = OV3640_CSI2_PHY_THS_TERM;
- hwc->csi2.hw_csi2.phy.ths_settle = OV3640_CSI2_PHY_THS_SETTLE;
- hwc->csi2.hw_csi2.phy.tclk_term = OV3640_CSI2_PHY_TCLK_TERM;
- hwc->csi2.hw_csi2.phy.tclk_miss = OV3640_CSI2_PHY_TCLK_MISS;
- hwc->csi2.hw_csi2.phy.tclk_settle = OV3640_CSI2_PHY_TCLK_SETTLE;
-#endif
-
- return 0;
-}
-
-static int ov3640_sensor_power_set(enum v4l2_power power)
-{
- struct isp_csi2_lanes_cfg lanecfg;
- struct isp_csi2_phy_cfg phyconfig;
- static enum v4l2_power previous_power = V4L2_POWER_OFF;
- switch (power) {
- case V4L2_POWER_ON:
- printk(KERN_DEBUG "ov3640_sensor_power_set(ON)\n");
- if (previous_power == V4L2_POWER_OFF)
- isp_csi2_reset();
- lanecfg.clk.pol = OV3640_CSI2_CLOCK_POLARITY;
- lanecfg.clk.pos = OV3640_CSI2_CLOCK_LANE;
- lanecfg.data[0].pol = OV3640_CSI2_DATA0_POLARITY;
- lanecfg.data[0].pos = OV3640_CSI2_DATA
Re: [PATCH 2/2] OMAP2/3 GPTIMER: skip unnecessary TLDR write during non-autoreload
"Woodruff, Richard" <[EMAIL PROTECTED]> writes: >> * Woodruff, Richard <[EMAIL PROTECTED]> [081014 12:47]: >> > > omap_dm_timer_write_reg(timer, OMAP_TIMER_COUNTER_REG, load); >> > > - omap_dm_timer_write_reg(timer, OMAP_TIMER_LOAD_REG, load); >> > > omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l); >> > > } >> > >> > I seem to recall there was a missed interrupt condition which this worked >> around. >> > >> > IIRC, the original code didn't bother with the load I added back as a work >> around as a way to get posted mode working. >> >> Well these seem to be working based on some quick timer tests. >> Pushing so we can verify it ;) > > This kind of change might be better tested on the PM branch. It's > the kind of thing more likely to work with PM disabled. Testing in > both is good, PM for many things is less forgiving... I validated these patches on the PM branch. I used cyclictest to test lots of timer reprogramming, and also tested in both RET-while-idle and OFF-while-idle for low frequency timer reprogramming. Acked-by: Kevin Hilman <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/10] omap mailbox: add initial omap3 support
* Hiroshi DOYU <[EMAIL PROTECTED]> [081125 16:10]:
> Hi Tony,
>
> From: "ext Tony Lindgren" <[EMAIL PROTECTED]>
> Subject: Re: [PATCH 02/10] omap mailbox: add initial omap3 support
> Date: Tue, 25 Nov 2008 13:54:14 -0800
>
> > * Hiroshi DOYU <[EMAIL PROTECTED]> [081125 01:40]:
> > > Signed-off-by: Hiroshi DOYU <[EMAIL PROTECTED]>
> > > ---
> > > arch/arm/mach-omap2/devices.c | 24 +++---
> > > arch/arm/mach-omap2/mailbox.c | 46
> > > ++--
> > > arch/arm/plat-omap/Kconfig |2 +-
> > > arch/arm/plat-omap/include/mach/irqs.h |1 +
> > > arch/arm/plat-omap/include/mach/omap34xx.h |2 +-
> > > 5 files changed, 52 insertions(+), 23 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> > > index 241e418..d385f0f 100644
> > > --- a/arch/arm/mach-omap2/devices.c
> > > +++ b/arch/arm/mach-omap2/devices.c
> > > @@ -84,13 +84,15 @@ static inline void omap_init_camera(void)
> > > }
> > > #endif
> > >
> > > -#if defined(CONFIG_OMAP_DSP) || defined(CONFIG_OMAP_DSP_MODULE)
> > > -#define OMAP2_MBOX_BASE IO_ADDRESS(OMAP24XX_MAILBOX_BASE)
> > > +#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
> > > +
> > > +#define MBOX_REG_SIZE0x120
> > >
> > > static struct resource mbox_resources[] = {
> > > +#if defined(CONFIG_ARCH_OMAP2420)
> > > {
> > > - .start = OMAP2_MBOX_BASE,
> > > - .end= OMAP2_MBOX_BASE + 0x11f,
> > > + .start = OMAP24XX_MAILBOX_BASE,
> > > + .end= OMAP24XX_MAILBOX_BASE + MBOX_REG_SIZE - 1,
> > > .flags = IORESOURCE_MEM,
> > > },
> > > {> @@ -101,6 +103,18 @@ static struct resource mbox_resources[] = {
> > > .start = INT_24XX_MAIL_U3_MPU,
> > > .flags = IORESOURCE_IRQ,
> > > },
> > > +/* FIXME: if multiple architecture support is necessary */
> > > +#elif defined(CONFIG_ARCH_OMAP3)
> > > + {
> > > + .start = OMAP34XX_MAILBOX_BASE,
> > > + .end= OMAP34XX_MAILBOX_BASE + MBOX_REG_SIZE - 1,
> > > + .flags = IORESOURCE_MEM,
> > > + },
> > > + {
> > > + .start = INT_34XX_MAIL_U0_MPU,
> > > + .flags = IORESOURCE_IRQ,
> > > + },
> > > +#endif
> > > };
> > >
> > > static struct platform_device mbox_device = {
> >
> > How about setting up omap2_mbox_resources[] and omap3_mbox_resources[]
> > above instead? Then just select the right one to use during init.
> >
> > We should not need to use ifdefs in any of the code for detecting the
> > omap cpu type, please use cpu_is_omap24xx() and cpu_is_omap34xx()
> > instead.
>
> Agreed and updated as below.
Thanks, since this is a large series, can you please send your series for
RMK to integrate to LAKML? Make sure it also applies against mainline
first :) Please feel free to add my Ack to your patches.
> Also, the latest patchset is available in the git repository at:
>
> http://git.gitorious.org/lk/mainline.git mailbox
Thanks, I've added mirroring for this branch to my kernel.org tree.
Let's wait for ack from RMK before integrating it to l-o.
BTW, we should move dspgateway also into a separate branch like
tidspbridge as it's not in the mainline tree. Do you want to keep the
original for that on your git server too?
Regards,
Tony
> From 7b62c1b04ae50adf2827fb3ca1ec8a3e72349d14 Mon Sep 17 00:00:00 2001
> From: Hiroshi DOYU <[EMAIL PROTECTED]>
> Date: Sat, 22 Nov 2008 02:28:36 +0200
> Subject: [PATCH 02/10] omap mailbox: add initial omap3 support
>
> Signed-off-by: Hiroshi DOYU <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/devices.c | 36 +-
> arch/arm/mach-omap2/mailbox.c | 46
> ++--
> arch/arm/plat-omap/Kconfig |2 +-
> arch/arm/plat-omap/include/mach/irqs.h |1 +
> arch/arm/plat-omap/include/mach/omap34xx.h |2 +-
> 5 files changed, 61 insertions(+), 26 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index 241e418..ea37f37 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -84,13 +84,14 @@ static inline void omap_init_camera(void)
> }
> #endif
>
> -#if defined(CONFIG_OMAP_DSP) || defined(CONFIG_OMAP_DSP_MODULE)
> -#define OMAP2_MBOX_BASE IO_ADDRESS(OMAP24XX_MAILBOX_BASE)
> +#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
>
> -static struct resource mbox_resources[] = {
> +#define MBOX_REG_SIZE0x120
> +
> +static struct resource omap2_mbox_resources[] = {
> {
> - .start = OMAP2_MBOX_BASE,
> - .end= OMAP2_MBOX_BASE + 0x11f,
> + .start = OMAP24XX_MAILBOX_BASE,
> + .end= OMAP24XX_MAILBOX_BASE + MBOX_REG_SIZE - 1,
Re: [PATCH] Fix omap-gpio warnings when compiling for ARCH_OMAP15XX
On Wednesday 26 November 2008, Tony Lindgren wrote: > Let's rather start > splitting the gpio code into common code and processor specific code > to fix issues like this for good. Working on that. :) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP general SOC driver.
On Wednesday 26 November 2008, Jarkko Nikula wrote: > And as a first step, I recommend to start merging only those EVM & SDP > boards with Beagle since they seems to be most close to each other. > > Even the Overo seems to be close also, it was discussed earlier to keep > it separated now since Steve was going to send some new features into > it. This seems to focus on just the McBSP channel out of the OMAP ... except that it hides (in that nasty #ifdeffery) the codec data. The fact that it doesn't allow EAC or a McBSP successor says to me it's not really "general". Heck ... it even hard-wires McBSP2, preventing another channel from being used. So IMO a different name would be appropriate... Re TWL4030 codec configuration ... I count three microphone input channels not used on Beagle, plus a speaker output and some other stuff. So it's obvious that something which works on Beagle won't handle more interesting configurations of that audio support. Plus, if there's going to be a board-specific platform device created, and stuffed with data like codec descriptions and configuration data ... that's what arch/arm/mach-*/board-*.c files are for. I'm told that the ASoC stuff "should" go in a separate ASoC area for some reason. That still makes no good sense to me, so if there's a brief explanation as to why it's done that way, please fling me a URL. :) - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: MCSPI: Enable mcspi wake-up v2.
* Jouni Hogander <[EMAIL PROTECTED]> [081118 23:48]:
> Currently mcspi wake-ups are not enabled. This might cause case where
> OMAP is not waking up on mcspi events.
Dave, I assume you're picking these for your SPI queue? Will only
apply to l-o if you ack and tell me so.
Tony
> Signed-off-by: Jouni Hogander <[EMAIL PROTECTED]>
> ---
> drivers/spi/omap2_mcspi.c | 11 +--
> 1 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
> index 454a271..d7e519c 100644
> --- a/drivers/spi/omap2_mcspi.c
> +++ b/drivers/spi/omap2_mcspi.c
> @@ -59,6 +59,8 @@
>
> /* per-register bitmasks: */
>
> +#define OMAP2_MCSPI_SYSCONFIG_SMARTIDLE (2 << 3)
> +#define OMAP2_MCSPI_SYSCONFIG_ENAWAKEUP (1 << 2)
> #define OMAP2_MCSPI_SYSCONFIG_AUTOIDLE (1 << 0)
> #define OMAP2_MCSPI_SYSCONFIG_SOFTRESET (1 << 1)
>
> @@ -90,6 +92,7 @@
>
> #define OMAP2_MCSPI_CHCTRL_EN(1 << 0)
>
> +#define OMAP2_MCSPI_WAKEUPENABLE_WKEN(1 << 0)
>
> /* We have 2 DMA channels per CS, one for RX and one for TX */
> struct omap2_mcspi_dma {
> @@ -884,8 +887,12 @@ static int __init omap2_mcspi_reset(struct omap2_mcspi
> *mcspi)
> } while (!(tmp & OMAP2_MCSPI_SYSSTATUS_RESETDONE));
>
> mcspi_write_reg(master, OMAP2_MCSPI_SYSCONFIG,
> - /* (3 << 8) | (2 << 3) | */
> - OMAP2_MCSPI_SYSCONFIG_AUTOIDLE);
> + OMAP2_MCSPI_SYSCONFIG_AUTOIDLE |
> + OMAP2_MCSPI_SYSCONFIG_ENAWAKEUP |
> + OMAP2_MCSPI_SYSCONFIG_SMARTIDLE);
> +
> + mcspi_write_reg(master, OMAP2_MCSPI_WAKEUPENABLE,
> + OMAP2_MCSPI_WAKEUPENABLE_WKEN);
>
> omap2_mcspi_set_master_mode(master);
>
> --
> 1.6.0.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix omap-gpio warnings when compiling for ARCH_OMAP15XX
* Jonathan McDowell <[EMAIL PROTECTED]> [08 15:44]:
> When compiling for ARCH_OMAP15XX I get the following compiler warning in
> gpio.c:
>
> arch/arm/plat-omap/gpio.c: In function ‘_set_gpio_wakeup’:
> arch/arm/plat-omap/gpio.c:848: warning: unused variable ‘flags’
>
> Simple patch below fixes this.
Sorry for the delay on responding to this.. Let's rather start
splitting the gpio code into common code and processor specific code
to fix issues like this for good. In this case, we would only register
set_wakeup functions for 16xx, 24xx, and 34xx.
Regards,
Tony
>
> Signed-off-by: Jonathan McDowell <[EMAIL PROTECTED]>
>
> -
> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
> index 8bb4542..bfbe366 100644
> --- a/arch/arm/plat-omap/gpio.c
> +++ b/arch/arm/plat-omap/gpio.c
> @@ -845,7 +845,10 @@ static inline void _set_gpio_irqenable(struct gpio_bank
> *bank, int gpio, int ena
> */
> static int _set_gpio_wakeup(struct gpio_bank *bank, int gpio, int enable)
> {
> +#if defined(CONFIG_ARCH_OMAP16XX) || defined(CONFIG_ARCH_OMAP24XX) || \
> + defined(CONFIG_ARCH_OMAP34XX)
> unsigned long flags;
> +#endif
>
> switch (bank->method) {
> #ifdef CONFIG_ARCH_OMAP16XX
> -
>
> J.
>
> --
> Web [ Asking whether machines can think is like asking whether ]
> site: http:// [ submarines can swim. ] Made by
> www.earth.li/~noodles/ [ ] HuggieTag 0.0.23
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PWM drivers for TWL4030
On Wednesday 26 November 2008, Grazvydas Ignotas wrote: > > > > Might have been better to use LEDA and LEDB for backlights, > > you probably could have saved some external hardware ... those > > pins are high drive. Â :) > > LEDB probably wasn't used for LCD backlight because it doesn't provide > enough power (60mA only). Don't know for sure, it wasn't me who > designed the hardware. LEDA, at 160 mA, is the one to use to use for that then. LEDB, at 60 mA, is indeed less hefty. Though I suppose if both backlights are high current, you'd end up hurting anyway. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omapfb: Fix argument of blank operation.
* Felipe Contreras <[EMAIL PROTECTED]> [081125 11:24]:
> The blank operation should receive FB_BLANK_POWERDOWN, not
> VESA_POWERDOWN.
Here's my canned fbdev reply for this tread too:
Guys, please take this discussion to fbdev mailing list and cc
linux-omap list. I'm not going to push any more omap fbdev patches,
so please send the patches against mainline kernel to fbdev list.
Regards,
Tony
> Signed-off-by: Felipe Contreras <[EMAIL PROTECTED]>
> ---
> drivers/video/omap/omapfb_main.c |8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/omap/omapfb_main.c
> b/drivers/video/omap/omapfb_main.c
> index 3bb4247..c8db8b2 100644
> --- a/drivers/video/omap/omapfb_main.c
> +++ b/drivers/video/omap/omapfb_main.c
> @@ -348,7 +348,7 @@ static int omapfb_blank(int blank, struct fb_info *fbi)
>
> omapfb_rqueue_lock(fbdev);
> switch (blank) {
> - case VESA_NO_BLANKING:
> + case FB_BLANK_UNBLANK:
> if (fbdev->state == OMAPFB_SUSPENDED) {
> if (fbdev->ctrl->resume)
> fbdev->ctrl->resume();
> @@ -359,7 +359,7 @@ static int omapfb_blank(int blank, struct fb_info *fbi)
> do_update = 1;
> }
> break;
> - case VESA_POWERDOWN:
> + case FB_BLANK_POWERDOWN:
> if (fbdev->state == OMAPFB_ACTIVE) {
> fbdev->panel->disable(fbdev->panel);
> if (fbdev->ctrl->suspend)
> @@ -1842,7 +1842,7 @@ static int omapfb_suspend(struct platform_device *pdev,
> pm_message_t mesg)
> struct omapfb_device *fbdev = platform_get_drvdata(pdev);
>
> if (fbdev != NULL)
> - omapfb_blank(VESA_POWERDOWN, fbdev->fb_info[0]);
> + omapfb_blank(FB_BLANK_POWERDOWN, fbdev->fb_info[0]);
> return 0;
> }
>
> @@ -1852,7 +1852,7 @@ static int omapfb_resume(struct platform_device *pdev)
> struct omapfb_device *fbdev = platform_get_drvdata(pdev);
>
> if (fbdev != NULL)
> - omapfb_blank(VESA_NO_BLANKING, fbdev->fb_info[0]);
> + omapfb_blank(FB_BLANK_UNBLANK, fbdev->fb_info[0]);
> return 0;
> }
>
> --
> 1.6.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix for dispc's error "omapfb omapfb: irq error status 4020"
* Tomi Valkeinen <[EMAIL PROTECTED]> [081113 06:06]: > Hi, > > On Fri, 2008-11-07 at 12:55 -0800, ext Rick Bronson wrote: > > Folks, > > > > Please take a look at this change to drivers/video/omap/dispc.c. It > > addresses a problem seen on some boots of OMAP's. On about 1 in 30 > > boots one gets an endless stream of interrupts from the > > DISPC_IRQ_SYNC_LOST bit in the DISPC_IRQSTATUS register. The > > following messages are printed. > > > > omapfb omapfb: irq error status 4020 > > Can you try the patch below if it fixes this problem for you? On my new > display subsystem adding a sleep between enabling clocks and doing the > soft reset removed the problem. > > I tried a bit with different sleep times. With 1ms sleep I still got > sync losts. With 10ms I didn't, but I went safe and put 40ms. Here's my canned fbdev reply for this tread too: Guys, please take this discussion to fbdev mailing list and cc linux-omap list. I'm not going to push any more omap fbdev patches, so please send the patches against mainline kernel to fbdev list. Regards, Tony > > Tomi > > > > diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c > index c140c21..bdfda0c 100644 > --- a/drivers/video/omap/dispc.c > +++ b/drivers/video/omap/dispc.c > @@ -24,6 +24,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -1402,6 +1403,10 @@ static int omap_dispc_init(struct omapfb_device > *fbdev, int ext_mode, > /* Reset monitoring works only w/ the 54M clk */ > enable_digit_clocks(1); > > + /* We need to wait here a bit, otherwise we sometimes start > to get > +* synclost errors. */ > + msleep(40); > + > /* Soft reset */ > MOD_REG_FLD(DISPC_SYSCONFIG, 1 << 1, 1 << 1); > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3evm LCD red-tint workaround
* Koen Kooi <[EMAIL PROTECTED]> [081102 14:00]:
>
> Op 2 nov 2008, om 20:56 heeft Grazvydas Ignotas het volgende geschreven:
>
>>> PS: TS is still unusable with the 16x16 pixel resolution
>> This is also the case for Pandora. The patch below fixes the problem,
>> but as I have no other boards to test this on, I haven't sent it.
>> See if it helps you.
>
> This fixes the problem on the EVM as well, thanks!
Guys, please take this discussion to fbdev mailing list and cc
linux-omap list. I'm not going to push any more omap fbdev patches,
so please send the patches against mainline kernel to fbdev list.
Regards,
Tony
>
> regards,
>
> Koen
>
>
>>
>>
>>
>> From 91f3af26bbf751b846e6265d86387e81be7c1364 Mon Sep 17 00:00:00 2001
>> From: Grazvydas Ignotas <[EMAIL PROTECTED]>
>> Date: Tue, 28 Oct 2008 22:01:42 +0200
>> Subject: [PATCH] OMAP3: fix McSPI transfers
>>
>> Currently on OMAP3 if both write and read is set up for a transfer,
>> the first byte returned on read is corrupted. Work around this by
>> disabling channel between reads and writes, instead of transfers.
>> ---
>> drivers/spi/omap2_mcspi.c |7 ---
>> 1 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
>> index 454a271..4890b6c 100644
>> --- a/drivers/spi/omap2_mcspi.c
>> +++ b/drivers/spi/omap2_mcspi.c
>> @@ -710,7 +710,6 @@ static void omap2_mcspi_work(struct work_struct
>> *work)
>> spi = m->spi;
>> cs = spi->controller_state;
>>
>> -omap2_mcspi_set_enable(spi, 1);
>> list_for_each_entry(t, &m->transfers, transfer_list) {
>> if (t->tx_buf == NULL && t->rx_buf == NULL && t->len) {
>> status = -EINVAL;
>> @@ -741,6 +740,8 @@ static void omap2_mcspi_work(struct work_struct
>> *work)
>> if (t->len) {
>> unsignedcount;
>>
>> +omap2_mcspi_set_enable(spi, 1);
>> +
>> /* RX_ONLY mode needs dummy data in TX reg */
>> if (t->tx_buf == NULL)
>> __raw_writel(0, cs->base
>> @@ -752,6 +753,8 @@ static void omap2_mcspi_work(struct work_struct
>> *work)
>> count = omap2_mcspi_txrx_pio(spi, t);
>> m->actual_length += count;
>>
>> +omap2_mcspi_set_enable(spi, 0);
>> +
>> if (count != t->len) {
>> status = -EIO;
>> break;
>> @@ -777,8 +780,6 @@ static void omap2_mcspi_work(struct work_struct
>> *work)
>> if (cs_active)
>> omap2_mcspi_force_cs(spi, 0);
>>
>> -omap2_mcspi_set_enable(spi, 0);
>> -
>> m->status = status;
>> m->complete(m->context);
>>
>> --
>> 1.5.4.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap"
>> in
>> the body of a message to [EMAIL PROTECTED]
>> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH] OMAP general SOC driver.
On Wed, Nov 26, 2008 at 09:24:03AM -0800, Steve Sakoman wrote: > I'm all for factoring out common code, but I think that this approach > will become a maintenance nightmare over time. I had formed the impression that an awful lot of the boards had very similar audio subsystems and that even with DAPM support it'd be fairly straightforward to do standard drivers for certain classes of system. If that's not the case then doing this sort of shared machine driver probably isn't worth it at all. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Patch to enable omapfb scaling
* Tuomas Kulve <[EMAIL PROTECTED]> [081103 07:04]:
> Tuomas Kulve wrote:
> > Hi
> >
> > The attached patch enables omapfb scaling. Tested on omap3 based
> > beagleboard with 2.6.27-omap1 kernel from linux-omap kernel tree.
>
> The 0002 patch implements downscaling in omapfb. It seems to work on
> ES3.0 beagleboard and ES2.1 EVM but not on my rev B5 beagleboard.
>
> The patch still needs cleanup but it should work with e.g. X.Org's XV
> extension:
>
> http://gitweb.pingu.fi/?p=xf86-video-omapfb.git;a=summary
All, I'm not going to push any more omap video patches, those need to
be discussed on fbdev mailing list. So please send the patches against
the mainline kernel there and cc linux-omap mailing list.
Regards,
Tony
>
>
> --
> Tuomas Kulve, Movial Creative Technologies Inc.
> Porkkalankatu 13J, FI-00180 Helsinki
> Fax +358 9 8567 6401, Tel +358 9 8567 6400
> www.movial.com
> From 069ce763b1a7e936b7b2bdc288d94dd98e477d7e Mon Sep 17 00:00:00 2001
> From: Tuomas Kulve <[EMAIL PROTECTED]>
> Date: Mon, 3 Nov 2008 11:22:56 +0200
> Subject: [PATCH] Implemented video downsampling in omapfb.
>
> ---
> drivers/video/omap/dispc.c | 58
>
> 1 files changed, 53 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
> index 68bc887..83f37bf 100644
> --- a/drivers/video/omap/dispc.c
> +++ b/drivers/video/omap/dispc.c
> @@ -545,6 +545,17 @@ static void write_firhv_reg(int plane, int reg, u32
> value)
> dispc_write_reg(base + reg * 8, value);
> }
>
> +static void write_firv_reg(int plane, int reg, u32 value)
> +{
> + u32 base;
> +
> + if (plane == 1)
> + base = 0x1E0;
> + else
> + base = 0x1E0 + 0x20;
> + dispc_write_reg(base + reg * 4, value);
> +}
> +
> static void set_upsampling_coef_table(int plane)
> {
> const u32 coef[][2] = {
> @@ -565,6 +576,27 @@ static void set_upsampling_coef_table(int plane)
> }
> }
>
> +static void set_downsampling_coef_table(int plane)
> +{
> + const u32 coef[][3] = {
> + { 0x24382400, 0x24382400, 0x },
> + { 0x28371FFE, 0x28391F04, 0x04FE },
> + { 0x2C361BFB, 0x2D381B08, 0x08FB },
> + { 0x303516F9, 0x3237170C, 0x0CF9 },
> + { 0x11343311, 0x123737F7, 0xF711 },
> + { 0x1635300C, 0x173732F9, 0xF90C },
> + { 0x1B362C08, 0x1B382DFB, 0xFB08 },
> + { 0x1F372804, 0x1F3928FE, 0xFE04 },
> + };
> + int i;
> +
> + for (i = 0; i < 8; i++) {
> + write_firh_reg(plane, i, coef[i][0]);
> + write_firhv_reg(plane, i, coef[i][1]);
> + write_firv_reg(plane, i, coef[i][2]);
> + }
> +}
> +
> static int omap_dispc_set_scale(int plane,
> int orig_width, int orig_height,
> int out_width, int out_height)
> @@ -592,16 +624,32 @@ static int omap_dispc_set_scale(int plane,
> if (orig_height > out_height ||
> orig_width * 8 < out_width ||
> orig_height * 8 < out_height) {
> + dev_dbg(dispc.fbdev->dev,
> + "Max upsampling is 8x, "
> + "tried: %dx%d -> %dx%d\n",
> + orig_width, orig_height,
> + out_width, out_height);
> enable_lcd_clocks(0);
> return -EINVAL;
> }
> set_upsampling_coef_table(plane);
> } else if (orig_width > out_width) {
> - /* Downsampling not yet supported
> - */
> -
> - enable_lcd_clocks(0);
> - return -EINVAL;
> + /*
> + * Downsampling.
> + * Currently you can only scale both dimensions in one way.
> + */
> + if (orig_height < out_height ||
> + orig_width > out_width * 4 ||
> + orig_height > out_height * 4) {
> + dev_dbg(dispc.fbdev->dev,
> + "Max downsampling is 4x, "
> + "tried: %dx%d -> %dx%d\n",
> + orig_width, orig_height,
> + out_width, out_height);
> + enable_lcd_clocks(0);
> + return -EINVAL;
> + }
> + set_downsampling_coef_table(plane);
> }
> if (!orig_width || orig_width == out_width)
> fir_hinc = 0;
> --
> 1.5.6.5
>
> From fd41a240a99de4c1408097bb39fa89cec4b7868d Mon Sep 17 00:00:00 2001
> From: Tuomas Kulve <[EMAIL PROTECTED]>
> Date: Fri, 31 Oct 2008 20:05:26 +0200
> Subject: [PATCH] Calculate fir_*inc using resolution minus one in omapfb
> scaling.
>
> ---
> drivers/video/omap/dispc.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
>
Re: [PATCH] SDTI: Add netlink support for debug message output.
* Felipe Balbi <[EMAIL PROTECTED]> [081118 05:27]:
> On Wed, Oct 29, 2008 at 01:39:28PM +0200, Tereshonkov Roman wrote:
> > Add support for user to use netlink for message output to XTI.
> > Add autoidle feature if SDTI is not used.
> >
> > Signed-off-by: Roman Tereshonkov <[EMAIL PROTECTED]>
>
> Acked-by: Felipe Balbi <[EMAIL PROTECTED]>
Pushing to l-o today. Roman, do you have any plans to submit this for
integration on LKML? The OMAP_TAG_STI_CONSOLE would need to be removed
for mainline and be replaced with cmdline parsing for console=...
Tony
>
> > ---
> > drivers/misc/sti/Makefile |2 +-
> > drivers/misc/sti/sdti.c| 14 ++
> > drivers/misc/sti/sti-netlink.c |8 +++-
> > 3 files changed, 18 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/misc/sti/Makefile b/drivers/misc/sti/Makefile
> > index aee30bd..43574d1 100644
> > --- a/drivers/misc/sti/Makefile
> > +++ b/drivers/misc/sti/Makefile
> > @@ -2,7 +2,7 @@ ifeq ($(CONFIG_ARCH_OMAP3),y)
> > obj-$(CONFIG_OMAP_STI) += sdti.o
> > else
> > obj-$(CONFIG_OMAP_STI) += sti.o sti-fifo.o
> > -obj-$(CONFIG_NET) += sti-netlink.o
> > endif
> >
> > +obj-$(CONFIG_NET) += sti-netlink.o
> > obj-$(CONFIG_OMAP_STI_CONSOLE) += sti-console.o
> > diff --git a/drivers/misc/sti/sdti.c b/drivers/misc/sti/sdti.c
> > index 4514783..92ce57b 100644
> > --- a/drivers/misc/sti/sdti.c
> > +++ b/drivers/misc/sti/sdti.c
> > @@ -31,11 +31,14 @@
> > #define CPU1_TRACE_EN 0x01
> > #define CPU2_TRACE_EN 0x02
> >
> > +#define SDTI_SYSCONFIG_SOFTRESET (1 << 1)
> > +#define SDTI_SYSCONFIG_AUTOIDLE(1 << 0)
> > +
> > static struct clk *sdti_ck;
> > void __iomem *sti_base, *sti_channel_base;
> > static DEFINE_SPINLOCK(sdti_lock);
> >
> > -void omap_sti_channel_write_trace(int len, int id, void *data,
> > +void sti_channel_write_trace(int len, int id, void *data,
> > unsigned int channel)
> > {
> > const u8 *tpntr = data;
> > @@ -49,13 +52,13 @@ void omap_sti_channel_write_trace(int len, int id, void
> > *data,
> >
> > spin_unlock_irq(&sdti_lock);
> > }
> > -EXPORT_SYMBOL(omap_sti_channel_write_trace);
> > +EXPORT_SYMBOL(sti_channel_write_trace);
> >
> > static void omap_sdti_reset(void)
> > {
> > int i;
> >
> > - sti_writel(0x02, SDTI_SYSCONFIG);
> > + sti_writel(SDTI_SYSCONFIG_SOFTRESET, SDTI_SYSCONFIG);
> >
> > for (i = 0; i < 1; i++)
> > if (sti_readl(SDTI_SYSSTATUS) & 1)
> > @@ -79,6 +82,9 @@ static int __init omap_sdti_init(void)
> > omap_sdti_reset();
> > sti_writel(0xC5ACCE55, SDTI_LOCK_ACCESS);
> >
> > + /* Autoidle */
> > + sti_writel(SDTI_SYSCONFIG_AUTOIDLE, SDTI_SYSCONFIG);
> > +
> > /* Claim SDTI */
> > sti_writel(1 << 30, SDTI_WINCTRL);
> > i = sti_readl(SDTI_WINCTRL);
> > @@ -99,7 +105,7 @@ static int __init omap_sdti_init(void)
> > snprintf(buf, sizeof(buf), "OMAP SDTI support loaded (HW v%u.%u)\n",
> > (i >> 4) & 0x0f, i & 0x0f);
> > printk(KERN_INFO "%s", buf);
> > - omap_sti_channel_write_trace(strlen(buf), 0xc3, buf, 239);
> > + sti_channel_write_trace(strlen(buf), 0xc3, buf, 239);
> >
> > return 0;
> > }
> > diff --git a/drivers/misc/sti/sti-netlink.c b/drivers/misc/sti/sti-netlink.c
> > index f1f8a48..b198e4c 100644
> > --- a/drivers/misc/sti/sti-netlink.c
> > +++ b/drivers/misc/sti/sti-netlink.c
> > @@ -25,6 +25,7 @@ enum {
> > STI_WRITE,
> > };
> >
> > +#if defined(CONFIG_ARCH_OMAP1) || defined(CONFIG_ARCH_OMAP2)
> > static int sti_netlink_read(int pid, int seq, void *payload, int size)
> > {
> > struct sk_buff *skb;
> > @@ -55,6 +56,7 @@ nlmsg_failure:
> >
> > return -EINVAL;
> > }
> > +#endif
> >
> > /*
> > * We abuse nlmsg_type and nlmsg_flags for our purposes.
> > @@ -66,7 +68,7 @@ static int sti_netlink_receive_msg(struct sk_buff *skb,
> > struct nlmsghdr *nlh)
> > {
> > void *data;
> > u8 chan, id;
> > - int size, ret = 0, len = 0;
> > + int size, ret = 0;
> >
> > data= NLMSG_DATA(nlh);
> > chan= (nlh->nlmsg_flags >> 8) & 0xff;
> > @@ -77,7 +79,10 @@ static int sti_netlink_receive_msg(struct sk_buff *skb,
> > struct nlmsghdr *nlh)
> > case STI_WRITE:
> > sti_channel_write_trace(size, id, data, chan);
> > break;
> > +#if defined(CONFIG_ARCH_OMAP1) || defined(CONFIG_ARCH_OMAP2)
> > case STI_READ:
> > + int len = 0;
> > +
> > data = kmalloc(size, GFP_KERNEL);
> > if (!data)
> > return -ENOMEM;
> > @@ -88,6 +93,7 @@ static int sti_netlink_receive_msg(struct sk_buff *skb,
> > struct nlmsghdr *nlh)
> >data, len);
> > kfree(data);
> > break;
> > +#endif
> > default:
> > return -ENOTTY;
> > }
> > --
> > 1.5.5.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-omap" i
Re: [PATCH 1/2] Add Input/Output related ioctl support
On Wednesday 26 November 2008 18:04:39 [EMAIL PROTECTED] wrote:
> From: Vaibhav Hiremath <[EMAIL PROTECTED]>
>
> Note - Resending again with TVP driver for completeness.
>
> Added ioctl support for query std, set std, enum input,
> get input, set input, enum output, get output and set output.
>
> For sensor kind of slave drivers v4l2-int-device.h provides
> necessary ioctl support, but the ioctls required to interface
> with decoders and encoders are missing. Most of the decoders
> and encoders supports multiple inputs and outputs, like
> S-Video or Composite.
>
> With these ioctl''s user can select the specific input/output.
>
> Signed-off-by: Brijesh Jadav <[EMAIL PROTECTED]>
> Signed-off-by: Hardik Shah <[EMAIL PROTECTED]>
> Signed-off-by: Manjunath Hadli <[EMAIL PROTECTED]>
> Signed-off-by: R Sivaraj <[EMAIL PROTECTED]>
> Signed-off-by: Vaibhav Hiremath <[EMAIL PROTECTED]>
> Signed-off-by: Karicheri Muralidharan <[EMAIL PROTECTED]>
> ---
> include/media/v4l2-int-device.h | 17 +
> 1 files changed, 17 insertions(+), 0 deletions(-)
>
> diff --git a/include/media/v4l2-int-device.h
> b/include/media/v4l2-int-device.h index 9c2df41..2325b2a 100644
> --- a/include/media/v4l2-int-device.h
> +++ b/include/media/v4l2-int-device.h
> @@ -102,6 +102,7 @@ enum v4l2_power {
> V4L2_POWER_OFF = 0,
> V4L2_POWER_ON,
> V4L2_POWER_STANDBY,
> + V4L2_POWER_RESUME,
> };
Why is POWER_RESUME added? In an earlier discussion with Sakari Ailus it
was decided not to add this (see the video4linux thread with
subject "[PATCH 4/6] V4L: Int if: Define new power state changes").
It also wasn't in your original patch.
Regards,
Hans
>
> /* Slave interface type. */
> @@ -183,6 +184,14 @@ enum v4l2_int_ioctl_num {
> vidioc_int_s_crop_num,
> vidioc_int_g_parm_num,
> vidioc_int_s_parm_num,
> + vidioc_int_querystd_num,
> + vidioc_int_s_std_num,
> + vidioc_int_enum_input_num,
> + vidioc_int_g_input_num,
> + vidioc_int_s_input_num,
> + vidioc_int_enumoutput_num,
> + vidioc_int_g_output_num,
> + vidioc_int_s_output_num,
>
> /*
>*
> @@ -284,6 +293,14 @@ V4L2_INT_WRAPPER_1(g_crop, struct v4l2_crop, *);
> V4L2_INT_WRAPPER_1(s_crop, struct v4l2_crop, *);
> V4L2_INT_WRAPPER_1(g_parm, struct v4l2_streamparm, *);
> V4L2_INT_WRAPPER_1(s_parm, struct v4l2_streamparm, *);
> +V4L2_INT_WRAPPER_1(querystd, v4l2_std_id, *);
> +V4L2_INT_WRAPPER_1(s_std, v4l2_std_id, *);
> +V4L2_INT_WRAPPER_1(enum_input, struct v4l2_input, *);
> +V4L2_INT_WRAPPER_1(g_input, int, *);
> +V4L2_INT_WRAPPER_1(s_input, int, );
> +V4L2_INT_WRAPPER_1(enumoutput, struct v4l2_output, *);
> +V4L2_INT_WRAPPER_1(g_output, int, *);
> +V4L2_INT_WRAPPER_1(s_output, int, );
>
> V4L2_INT_WRAPPER_0(dev_init);
> V4L2_INT_WRAPPER_0(dev_exit);
> --
> 1.5.6
>
> --
> video4linux-list mailing list
> Unsubscribe
> mailto:[EMAIL PROTECTED]
> https://www.redhat.com/mailman/listinfo/video4linux-list
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Add Input/Output related ioctl support
From: Vaibhav Hiremath <[EMAIL PROTECTED]>
Note - Resending again with TVP driver for completeness.
Added ioctl support for query std, set std, enum input,
get input, set input, enum output, get output and set output.
For sensor kind of slave drivers v4l2-int-device.h provides
necessary ioctl support, but the ioctls required to interface
with decoders and encoders are missing. Most of the decoders
and encoders supports multiple inputs and outputs, like
S-Video or Composite.
With these ioctl''s user can select the specific input/output.
Signed-off-by: Brijesh Jadav <[EMAIL PROTECTED]>
Signed-off-by: Hardik Shah <[EMAIL PROTECTED]>
Signed-off-by: Manjunath Hadli <[EMAIL PROTECTED]>
Signed-off-by: R Sivaraj <[EMAIL PROTECTED]>
Signed-off-by: Vaibhav Hiremath <[EMAIL PROTECTED]>
Signed-off-by: Karicheri Muralidharan <[EMAIL PROTECTED]>
---
include/media/v4l2-int-device.h | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-int-device.h b/include/media/v4l2-int-device.h
index 9c2df41..2325b2a 100644
--- a/include/media/v4l2-int-device.h
+++ b/include/media/v4l2-int-device.h
@@ -102,6 +102,7 @@ enum v4l2_power {
V4L2_POWER_OFF = 0,
V4L2_POWER_ON,
V4L2_POWER_STANDBY,
+ V4L2_POWER_RESUME,
};
/* Slave interface type. */
@@ -183,6 +184,14 @@ enum v4l2_int_ioctl_num {
vidioc_int_s_crop_num,
vidioc_int_g_parm_num,
vidioc_int_s_parm_num,
+ vidioc_int_querystd_num,
+ vidioc_int_s_std_num,
+ vidioc_int_enum_input_num,
+ vidioc_int_g_input_num,
+ vidioc_int_s_input_num,
+ vidioc_int_enumoutput_num,
+ vidioc_int_g_output_num,
+ vidioc_int_s_output_num,
/*
*
@@ -284,6 +293,14 @@ V4L2_INT_WRAPPER_1(g_crop, struct v4l2_crop, *);
V4L2_INT_WRAPPER_1(s_crop, struct v4l2_crop, *);
V4L2_INT_WRAPPER_1(g_parm, struct v4l2_streamparm, *);
V4L2_INT_WRAPPER_1(s_parm, struct v4l2_streamparm, *);
+V4L2_INT_WRAPPER_1(querystd, v4l2_std_id, *);
+V4L2_INT_WRAPPER_1(s_std, v4l2_std_id, *);
+V4L2_INT_WRAPPER_1(enum_input, struct v4l2_input, *);
+V4L2_INT_WRAPPER_1(g_input, int, *);
+V4L2_INT_WRAPPER_1(s_input, int, );
+V4L2_INT_WRAPPER_1(enumoutput, struct v4l2_output, *);
+V4L2_INT_WRAPPER_1(g_output, int, *);
+V4L2_INT_WRAPPER_1(s_output, int, );
V4L2_INT_WRAPPER_0(dev_init);
V4L2_INT_WRAPPER_0(dev_exit);
--
1.5.6
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP general SOC driver.
* Stanley.Miao <[EMAIL PROTECTED]> [081126 02:42]: > Add a shared omap SoC driver to avoid reduplicate code among omap soc drivers. > > Signed-off-by: Stanley.Miao <[EMAIL PROTECTED]> > --- > sound/soc/omap/Kconfig| 49 + > sound/soc/omap/Makefile | 13 > sound/soc/omap/omap-general.c | 155 > + > sound/soc/omap/omap-general.h | 70 ++ > 4 files changed, 287 insertions(+), 0 deletions(-) > create mode 100644 sound/soc/omap/omap-general.c > create mode 100644 sound/soc/omap/omap-general.h > > --- /dev/null > +++ b/sound/soc/omap/omap-general.h > @@ -0,0 +1,70 @@ > +/* > + * omap-general.h > + * > + * Copyright (C) 2008 Wind River Systems, Inc. > + * > + * Author: Stanley Miao <[EMAIL PROTECTED]> > + * > + * 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 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., 51 Franklin St, Fifth Floor, Boston, MA > + * 02110-1301 USA > + * > + */ > + > +#ifdef CONFIG_SND_OMAP_SOC_N810 > +#include "../codecs/tlv320aic3x.h" > +#define CODEC_SYS_CLOCK 1200 > +#define CODEC_NAME "TLV320AIC33" > +#define STREAM_NAME "AIC33" > +#define CODEC_DEV(&soc_codec_dev_aic3x) > +#define CODEC_DAI(&aic3x_dai) > +#define CODEC_SETUP_DATA (&&n810_aic33_setup) > +#define DAI_LINK_INIT(n810_aic33_init) > +#define SOC_OPS_STARTUP (n810_startup) > +#define SOC_OPS_SHUTDOWN (n810_shutdown) > +#else > +#include "../codecs/twl4030.h" > +#define CODEC_SYS_CLOCK 2600 > +#define CODEC_NAME "TWL4030" > +#define STREAM_NAME "TWL4030" > +#define CODEC_DEV(&soc_codec_dev_twl4030) > +#define CODEC_DAI(&twl4030_dai) > +#define CODEC_SETUP_DATA NULL > +#define DAI_LINK_INITNULL > +#define SOC_OPS_STARTUP NULL > +#define SOC_OPS_SHUTDOWN NULL > +#endif /* CONFIG_SND_OMAP_SOC_N810 */ > + > +#ifdef CONFIG_SND_OMAP_SOC_N810 > +#define MACHINE_IS_OMAP_GENERAL (machine_is_nokia_n810() || > machine_is_nokia_n810_wimax()) > +#elif defined(CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE) > +#define MACHINE_IS_OMAP_GENERAL machine_is_omap3_beagle() > +#elif defined(CONFIG_SND_OMAP_SOC_OVERO) > +#define MACHINE_IS_OMAP_GENERAL machine_is_overo() > +#elif defined(CONFIG_SND_OMAP_SOC_3430SDP) > +#define MACHINE_IS_OMAP_GENERAL machine_is_omap_3430sdp() > +#elif defined(CONFIG_SND_OMAP_SOC_LDP) > +#define MACHINE_IS_OMAP_GENERAL machine_is_omap_ldp() > +#elif defined(CONFIG_SND_OMAP_SOC_OMAP2EVM) > +#define MACHINE_IS_OMAP_GENERAL machine_is_omap2evm() > +#elif defined(CONFIG_SND_OMAP_SOC_OMAP3EVM) > +#define MACHINE_IS_OMAP_GENERAL machine_is_omapevm() > +#endif Please also remove these ifdef elsif stuff above to compile in support for multiple boards. The best way to to do it is to pass the necessary info in platform_data, so you should not need to use machine_is_omap() or cpu_is_omap() in the actual driver code. Regards, Tony > +#ifndef omap_board_soc_init > +#define omap_board_soc_init(x) 0 > +#endif > +#ifndef omap_board_soc_exit > +#define omap_board_soc_exit > +#endif > + > -- > 1.5.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] i2c: i2c-omap: Fix standard and fast mode prescalers
From: Eero Nurkkala <[EMAIL PROTECTED]>
The prescalers for 100 kHz and 400 kHz mode
are wrong for omap 3430 and omap 2430. The
internal clock is the fclock divided by the
prescaler. The PSC is an 8 bit field in
omap3430 and omap2430. Moreover, the scll and
sclh values should be adjusted properly.
Having the correct prescaler is important in
the process of getting a finite i2c clock. In
addition, the prescaler is used in the process
of activating the correct noise filter and thus,
lets more error resilient i2c communications.
Signed-off-by: Eero Nurkkala <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 630702c..c21af3f 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -337,7 +337,13 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
if (cpu_is_omap2430() || cpu_is_omap34xx()) {
/* HSI2C controller internal clk rate should be 19.2 Mhz */
- internal_clk = 19200;
+ if (dev->speed > 400)
+ internal_clk = 19200;
+ else if (dev->speed > 100)
+ internal_clk = 9600;
+ else
+ internal_clk = 4000;
+
fclk_rate = clk_get_rate(dev->fclk) / 1000;
/* Compute prescaler divisor */
@@ -355,8 +361,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
hssclh = fclk_rate / (dev->speed * 2) - 6;
} else {
/* To handle F/S modes */
- fsscll = internal_clk / (dev->speed * 2) - 6;
- fssclh = internal_clk / (dev->speed * 2) - 6;
+ fsscll = internal_clk / (dev->speed * 2) - 3;
+ fssclh = internal_clk / (dev->speed * 2) - 9;
}
scll = (hsscll << OMAP_I2C_SCLL_HSSCLL) | fsscll;
sclh = (hssclh << OMAP_I2C_SCLH_HSSCLH) | fssclh;
--
1.6.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fix crash on non-3430SDP platforms with DVFS/CPUFreq
The SRF/DVFS + CPUFreq patches had issues booting on
non-3430SDP platforms as reported by Kevin Hilman.
This patch puts non-NULL checks in place for mpu_opps/dsp_opps
/l3_opps before accessing them and fixes the issue.
This fix/patch can be applied on top of
pm-20081119 branch
+ [PATCH 00/08] OMAP3 SRF: OPP and Frequency resources
+ [PATCH 00/03] OMAP3 PM: CPUFreq driver for OMAP3
Signed-off-by: Rajendra Nayak <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/clock34xx.c| 33 -
arch/arm/mach-omap2/pm.h | 18 ---
arch/arm/mach-omap2/resource34xx.c | 21 ++
arch/arm/plat-omap/cpu-omap.c |6 +
arch/arm/plat-omap/include/mach/omap34xx.h | 18 +++
5 files changed, 64 insertions(+), 32 deletions(-)
Index: linux-omap-2.6/arch/arm/mach-omap2/clock34xx.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/clock34xx.c 2008-11-26
17:43:12.011090533 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/clock34xx.c 2008-11-26
17:47:40.551795371 +0530
@@ -666,6 +666,9 @@ void omap2_clk_init_cpufreq_table(struct
struct omap_opp *prcm;
int i = 0;
+ if (!mpu_opps)
+ return;
+
/* Avoid registering the 120% Overdrive with CPUFreq */
prcm = mpu_opps + MAX_VDD1_OPP - 1;
for (; prcm->rate; prcm--) {
@@ -798,20 +801,24 @@ int __init omap2_clk_init(void)
dpll3_clk = clk_get(NULL, "dpll3_m2_ck");
mpu_speed = dpll1_clk->rate;
- prcm_vdd = mpu_opps + MAX_VDD1_OPP;
- for (; prcm_vdd->rate; prcm_vdd--) {
- if (prcm_vdd->rate <= mpu_speed) {
- curr_vdd1_prcm_set = prcm_vdd;
- break;
+ if (mpu_opps) {
+ prcm_vdd = mpu_opps + MAX_VDD1_OPP;
+ for (; prcm_vdd->rate; prcm_vdd--) {
+ if (prcm_vdd->rate <= mpu_speed) {
+ curr_vdd1_prcm_set = prcm_vdd;
+ break;
+ }
}
}
core_speed = dpll3_clk->rate;
- prcm_vdd = l3_opps + MAX_VDD2_OPP;
- for (; prcm_vdd->rate; prcm_vdd--) {
- if (prcm_vdd->rate <= core_speed) {
- curr_vdd2_prcm_set = prcm_vdd;
- break;
+ if (l3_opps) {
+ prcm_vdd = l3_opps + MAX_VDD2_OPP;
+ for (; prcm_vdd->rate; prcm_vdd--) {
+ if (prcm_vdd->rate <= core_speed) {
+ curr_vdd2_prcm_set = prcm_vdd;
+ break;
+ }
}
}
@@ -878,6 +885,9 @@ static long omap3_round_to_table_rate(st
if ((clk != &virt_vdd1_prcm_set) && (clk != &virt_vdd2_prcm_set))
return -EINVAL;
+ if (!mpu_opps || !dsp_opps || !l3_opps)
+ return -EINVAL;
+
highest_rate = -EINVAL;
if (clk == &virt_vdd1_prcm_set)
@@ -904,6 +914,9 @@ static int omap3_select_table_rate(struc
if ((clk != &virt_vdd1_prcm_set) && (clk != &virt_vdd2_prcm_set))
return -EINVAL;
+ if (!mpu_opps || !dsp_opps || !l3_opps)
+ return -EINVAL;
+
if (clk == &virt_vdd1_prcm_set) {
prcm_vdd = mpu_opps + MAX_VDD1_OPP;
index = MAX_VDD1_OPP;
Index: linux-omap-2.6/arch/arm/mach-omap2/pm.h
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/pm.h2008-11-26
17:43:12.011090533 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/pm.h 2008-11-26 17:47:40.552795340
+0530
@@ -39,24 +39,6 @@ extern void omap3_pm_off_mode_enable(int
#endif
extern int set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
-
-/* VDD1 OPPS */
-#define VDD1_OPP1 0x1
-#define VDD1_OPP2 0x2
-#define VDD1_OPP3 0x3
-#define VDD1_OPP4 0x4
-#define VDD1_OPP5 0x5
-
-/* VDD2 OPPS */
-#define VDD2_OPP1 0x1
-#define VDD2_OPP2 0x2
-#define VDD2_OPP3 0x3
-
-#define MIN_VDD1_OPP VDD1_OPP1
-#define MAX_VDD1_OPP VDD1_OPP5
-#define MIN_VDD2_OPP VDD2_OPP1
-#define MAX_VDD2_OPP VDD2_OPP3
-
#ifdef CONFIG_PM_DEBUG
extern u32 omap2_read_32k_sync_counter(void);
extern void omap2_pm_dump(int mode, int resume, unsigned int us);
Index: linux-omap-2.6/arch/arm/mach-omap2/resource34xx.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/resource34xx.c 2008-11-26
17:43:12.011090533 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/resource34xx.c 2008-11-26
18:16:28.376582736 +0530
@@ -144,6 +144,10 @@ static struct device dummy_dsp_dev;
void init_opp(struct shared_resource *resp)
{
resp->no_of_users = 0;
+
+ if (!mpu_opps || !dsp_opps || !l3_opps)
+ return 0;
+
Re: ARM : OMAP: Pass logical DMA channel number always to callback handlers
On Wed, 26 Nov 2008 16:26:42 +0530 "ext Shilimkar, Santosh" <[EMAIL PROTECTED]> wrote: > > As commit log says, user can pass the chain_id via callback data if > > needed. > Yes there are few ways you can achieve this if you don't want to pass the > chain_id as part of the callback. But in that case the > 'omap_request_dma_chain' callback signature should have been also cleaned ( > 'ch' instead of 'chain_id'). > Ah, yeah, then it was missing from my patch and have to send a patch changing it. > >I think chained dma callback may also find more use > > for logical channel number than chain_id e.g. when modifying the transfer > > parameters etc. > When user wants to use chaining,they expects that the chain internals ( free > channel allocation etc) should be managed by DMA library. So even user wants > to modify the parameters, it can directly use 'omap_modify_dma_chain_params' > api and just provide 'chain_id'. For which channel the parameters should be > changed will be decided by the DMA library internally depending on free > channels from chain. > This approach doesn't work e.g. with audio. Let's assume you would like to use DMA chaining with ALSA (been there, done that, until found a better solution. See sound/soc/omap-pcm.c). ALSA application may ask to use e.g. 100 periods, which is more than n.o. logical DMA channels in OMAP so chain length is have to be shorter than n.o. periods. Which then means that channel parameters are have to modify while the chain is running. omap_modify_dma_chain_params is setting parameters for all channels in a chain, and more over, function header of it says "Dont do this while dma is running!!". > > And uniform, smaller API set is always better than bloated one. > This change any way don't reduce a single API so not sure what you mean by > 'smaller API set is always better than bloated one'. It may reduce a callback > for a user in > IMO, API is a one step bigger if DMA callback has different arguments depending is it in non-chained vs. chained configuration. > So I still don't see a real benefit of this patch. Because of above mentioned > reasons I think we should revert this patch. > Probably you would like to show/share opposite example? Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP3: Fixes for suspend / resume GPIO wake-up handling
Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
---
arch/arm/plat-omap/gpio.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index f4ec3af..62349fd 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1585,7 +1585,7 @@ static int omap_gpio_suspend(struct sys_device *dev,
pm_message_t mesg)
#endif
#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
case METHOD_GPIO_24XX:
- wake_status = bank->base + OMAP24XX_GPIO_SETWKUENA;
+ wake_status = bank->base + OMAP24XX_GPIO_WAKE_EN;
wake_clear = bank->base + OMAP24XX_GPIO_CLEARWKUENA;
wake_set = bank->base + OMAP24XX_GPIO_SETWKUENA;
break;
@@ -1608,7 +1608,7 @@ static int omap_gpio_resume(struct sys_device *dev)
{
int i;
- if (!cpu_is_omap24xx() && !cpu_is_omap16xx())
+ if (!cpu_class_is_omap2() && !cpu_is_omap16xx())
return 0;
for (i = 0; i < gpio_bank_count; i++) {
--
1.5.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP general SOC driver.
On Wed, 26 Nov 2008 11:08:55 + "ext Mark Brown" <[EMAIL PROTECTED]> wrote: > > +#ifdef CONFIG_SND_OMAP_SOC_N810 > > +#include "../codecs/tlv320aic3x.h" > > +#define CODEC_SYS_CLOCK1200 > > +#define CODEC_NAME "TLV320AIC33" > > +#define STREAM_NAME"AIC33" > > +#define CODEC_DEV (&soc_codec_dev_aic3x) > > +#define CODEC_DAI (&aic3x_dai) > > +#define CODEC_SETUP_DATA (&&n810_aic33_setup) > > +#define DAI_LINK_INIT (n810_aic33_init) > > +#define SOC_OPS_STARTUP(n810_startup) > > +#define SOC_OPS_SHUTDOWN (n810_shutdown) > > Please change this to use a platform data based approach rather than > these ifdefs: it's not a good approach for readability and it prevents > building multiple board drivers in one kernel which isn't good for > distributions. The s3c24xx_uda134x.c provides an example of how this > can be done. It may be more sensible to have a separate driver per > codec. > -- And as a first step, I recommend to start merging only those EVM & SDP boards with Beagle since they seems to be most close to each other. Even the Overo seems to be close also, it was discussed earlier to keep it separated now since Steve was going to send some new features into it. Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP general SOC driver.
On Wed, Nov 26, 2008 at 06:47:58PM +0800, Stanley.Miao wrote: > Add a shared omap SoC driver to avoid reduplicate code among omap soc drivers. It's really good to see work on this but I've got some concerns with the approach being taken here. > + > +config SND_OMAP_SOC_OVERO > + tristate "SoC Audio support for Gumstix Overo" > + depends on SND_OMAP_SOC && MACH_OVERO This won't apply - this and several of the other machines are already present. > +#ifdef CONFIG_SND_OMAP_SOC_N810 > +#include "../codecs/tlv320aic3x.h" > +#define CODEC_SYS_CLOCK 1200 > +#define CODEC_NAME "TLV320AIC33" > +#define STREAM_NAME "AIC33" > +#define CODEC_DEV(&soc_codec_dev_aic3x) > +#define CODEC_DAI(&aic3x_dai) > +#define CODEC_SETUP_DATA (&&n810_aic33_setup) > +#define DAI_LINK_INIT(n810_aic33_init) > +#define SOC_OPS_STARTUP (n810_startup) > +#define SOC_OPS_SHUTDOWN (n810_shutdown) Please change this to use a platform data based approach rather than these ifdefs: it's not a good approach for readability and it prevents building multiple board drivers in one kernel which isn't good for distributions. The s3c24xx_uda134x.c provides an example of how this can be done. It may be more sensible to have a separate driver per codec. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: ARM : OMAP: Pass logical DMA channel number always to callback handlers
> -Original Message- > From: Jarkko Nikula [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 26, 2008 3:42 PM > To: Shilimkar, Santosh > Cc: Tony Lindgren; linux-omap@vger.kernel.org > Subject: Re: ARM : OMAP: Pass logical DMA channel number > always to callback handlers > > On Wed, 26 Nov 2008 14:43:02 +0530 > "ext Shilimkar, Santosh" <[EMAIL PROTECTED]> wrote: > > > Hi Jarkko\Tony , > > > > Recently during some debugging, I observed this patch. > > > http://source.mvista.com/git/?p=linux-omap-2.6.git;a=commitdif > f;h=538528de0cb256f65716ab2e9613d9e920f97fe2;hp=29e8c3c304b62f > 31b799565c9ee85d42bd163f80 > > > > As per your description,it improves the debugging. Can you > elaborate more on this ? > > > Honestly don't remember what I meant for easier debugging, probably > just watching how the logical channels are rotating during > the transfer or something like that. Yes but It will be of just academic interest to see it. :-) > > For users this change is little confusing, if they go as > per the signatures of the 'omap_request_dma_chain' and > 'omap_request_dma' APIs. Also separating the callbacks for > chained and non-chained transfers seems to be the practical > usage in most of the cases. Also users would be only > interested in 'chain_id' and not 'channel number' in case of > chaining. > > > As commit log says, user can pass the chain_id via callback data if > needed. Yes there are few ways you can achieve this if you don't want to pass the chain_id as part of the callback. But in that case the 'omap_request_dma_chain' callback signature should have been also cleaned ( 'ch' instead of 'chain_id'). >I think chained dma callback may also find more use > for logical channel number than chain_id e.g. when modifying the transfer > parameters etc. When user wants to use chaining,they expects that the chain internals ( free channel allocation etc) should be managed by DMA library. So even user wants to modify the parameters, it can directly use 'omap_modify_dma_chain_params' api and just provide 'chain_id'. For which channel the parameters should be changed will be decided by the DMA library internally depending on free channels from chain. In fact if users modifies parameters using 'omap_set_dma_params' + 'ch' number directly in a chained transfer, then it can tamper the chaining state machine. > And uniform, smaller API set is always better than bloated one. This change any way don't reduce a single API so not sure what you mean by 'smaller API set is always better than bloated one'. It may reduce a callback for a user in case he wants to use normal and chaining feature together for a module. But he has to any way add the logic to differentiate between callers. I have not seen any driver using DMA that way. So I still don't see a real benefit of this patch. Because of above mentioned reasons I think we should revert this patch. Regards Santosh Shilimkar-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP general SOC driver.
Add a shared omap SoC driver to avoid reduplicate code among omap soc drivers. Signed-off-by: Stanley.Miao <[EMAIL PROTECTED]> --- sound/soc/omap/Kconfig| 49 + sound/soc/omap/Makefile | 13 sound/soc/omap/omap-general.c | 155 + sound/soc/omap/omap-general.h | 70 ++ 4 files changed, 287 insertions(+), 0 deletions(-) create mode 100644 sound/soc/omap/omap-general.c create mode 100644 sound/soc/omap/omap-general.h diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index 8b7766b..92a557f 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -14,6 +14,14 @@ config SND_OMAP_SOC_N810 help Say Y if you want to add support for SoC audio on Nokia N810. +config SND_OMAP_SOC_OMAP3_BEAGLE + tristate "SoC Audio support for OMAP3 Beagle" + depends on SND_OMAP_SOC && MACH_OMAP3_BEAGLE + select SND_OMAP_SOC_MCBSP + select SND_SOC_TWL4030 + help + Say Y if you want to add support for SoC audio on the Beagleboard. + config SND_OMAP_SOC_OSK5912 tristate "SoC Audio support for omap osk5912" depends on SND_OMAP_SOC && MACH_OMAP_OSK @@ -21,3 +29,44 @@ config SND_OMAP_SOC_OSK5912 select SND_SOC_TLV320AIC23 help Say Y if you want to add support for SoC audio on osk5912. + +config SND_OMAP_SOC_OVERO + tristate "SoC Audio support for Gumstix Overo" + depends on SND_OMAP_SOC && MACH_OVERO + select SND_OMAP_SOC_MCBSP + select SND_SOC_TWL4030 + help + Say Y if you want to add support for SoC audio on the Gumstix Overo. + +config SND_OMAP_SOC_3430SDP + tristate "SoC Audio support for OMAP 3430SDP" + depends on SND_OMAP_SOC && MACH_OMAP_3430SDP + select SND_OMAP_SOC_MCBSP + select SND_SOC_TWL4030 + help + Say Y if you want to add support for SoC audio on the OMAP 3430SDP. + +config SND_OMAP_SOC_LDP + tristate "SoC Audio support for OMAP ZOOM SDK" + depends on SND_OMAP_SOC && MACH_OMAP_LDP + select SND_OMAP_SOC_MCBSP + select SND_SOC_TWL4030 + help + Say Y if you want to add support for SoC audio on the OMAP ZOOM MDK. + +config SND_OMAP_SOC_OMAP2EVM + tristate "SoC Audio support for OMAP2EVM" + depends on SND_OMAP_SOC && MACH_OMAP2EVM + select SND_OMAP_SOC_MCBSP + select SND_SOC_TWL4030 + help + Say Y if you want to add support for SoC audio on the OMAP2EVM. + +config SND_OMAP_SOC_OMAP3EVM + tristate "SoC Audio support for OMAP3EVM" + depends on SND_OMAP_SOC && MACH_OMAP3EVM + select SND_OMAP_SOC_MCBSP + select SND_SOC_TWL4030 + help + Say Y if you want to add support for SoC audio on the OMAP3EVM. + diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile index e09d1f2..de9163b 100644 --- a/sound/soc/omap/Makefile +++ b/sound/soc/omap/Makefile @@ -7,7 +7,20 @@ obj-$(CONFIG_SND_OMAP_SOC_MCBSP) += snd-soc-omap-mcbsp.o # OMAP Machine Support snd-soc-n810-objs := n810.o +snd-soc-omap3beagle-objs := omap-general.o snd-soc-osk5912-objs := osk5912.o +snd-soc-overo-objs := omap-general.o +snd-soc-3430sdp-objs := omap-general.o +snd-soc-ldp-objs := omap-general.o +snd-soc-omap2evm-objs := omap-general.o +snd-soc-omap3evm-objs := omap-general.o obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-n810.o +obj-$(CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE) += snd-soc-omap3beagle.o obj-$(CONFIG_SND_OMAP_SOC_OSK5912) += snd-soc-osk5912.o +obj-$(CONFIG_SND_OMAP_SOC_OVERO) += snd-soc-overo.o +obj-$(CONFIG_SND_OMAP_SOC_3430SDP) += snd-soc-3430sdp.o +obj-$(CONFIG_SND_OMAP_SOC_LDP) += snd-soc-ldp.o +obj-$(CONFIG_SND_OMAP_SOC_OMAP2EVM) += snd-soc-omap2evm.o +obj-$(CONFIG_SND_OMAP_SOC_OMAP3EVM) += snd-soc-omap3evm.o + diff --git a/sound/soc/omap/omap-general.c b/sound/soc/omap/omap-general.c new file mode 100644 index 000..a3fa647 --- /dev/null +++ b/sound/soc/omap/omap-general.c @@ -0,0 +1,155 @@ +/* + * omap-general.c -- OMAP SoC general machine file. + * + * Author: Stanley Miao <[EMAIL PROTECTED]> + * + * 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 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., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ + +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include "omap-mcbsp.h" +#include "omap-pcm.h" +#include "omap-general.
[PATCH] PM: Added suspend target state control to debugfs for OMAP3
Target state can be read / programmed via files under:
[debugfs]/pm_debug/[pwrdm]/suspend
Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/pm-debug.c | 30 --
arch/arm/mach-omap2/pm.h |4
arch/arm/mach-omap2/pm34xx.c | 24
3 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 82219f4..ac61d15 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -511,11 +512,28 @@ int pm_dbg_regset_init(int reg_set)
return 0;
}
-static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
+static int pwrdm_suspend_get(void *data, u64 *val)
+{
+ *val = omap3_pm_get_suspend_state((struct powerdomain *)data);
+
+ if (*val >= 0)
+ return 0;
+ return *val;
+}
+
+static int pwrdm_suspend_set(void *data, u64 val)
+{
+ return omap3_pm_set_suspend_state((struct powerdomain *)data, (int)val);
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(pwrdm_suspend_fops, pwrdm_suspend_get,
pwrdm_suspend_set, "%llu\n");
+
+static int __init pwrdms_setup(struct powerdomain *pwrdm, void *dir)
{
int i;
s64 t;
struct timespec now;
+ struct dentry *d;
getnstimeofday(&now);
t = timespec_to_ns(&now);
@@ -525,6 +543,14 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm,
void *unused)
pwrdm->timer = t;
+ if (strncmp(pwrdm->name, "dpll", 4) == 0)
+ return 0;
+
+ d = debugfs_create_dir(pwrdm->name, (struct dentry *)dir);
+
+ (void) debugfs_create_file("suspend", S_IRUGO|S_IWUSR, d,
+ (void *)pwrdm, &pwrdm_suspend_fops);
+
return 0;
}
@@ -545,7 +571,7 @@ static int __init pm_dbg_init(void)
(void) debugfs_create_file("time", S_IRUGO,
d, (void *)DEBUG_FILE_TIMERS, &debug_fops);
- pwrdm_for_each(pwrdms_setup, NULL);
+ pwrdm_for_each(pwrdms_setup, (void *)d);
pm_dbg_dir = debugfs_create_dir("registers", d);
if (IS_ERR(pm_dbg_dir))
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 4b1ba7c..78fde57 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -34,8 +34,12 @@ extern void omap2_block_sleep(void);
extern void omap2_allow_sleep(void);
#ifdef CONFIG_ARCH_OMAP3
extern void omap3_pm_off_mode_enable(int);
+extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
+extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
#else
#define omap3_pm_off_mode_enable(int) do {} while (0);
+#define omap3_pm_get_suspend_state(pwrdm) do {} while (0);
+#define omap3_pm_set_suspend_state(pwrdm,state) do {} while (0);
#endif
extern int set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 191299c..73ac22c 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -780,6 +780,30 @@ void omap3_pm_off_mode_enable(int enable)
}
}
+int omap3_pm_get_suspend_state(struct powerdomain *pwrdm)
+{
+ struct power_state *pwrst;
+
+ list_for_each_entry(pwrst, &pwrst_list, node) {
+ if (pwrst->pwrdm == pwrdm)
+ return pwrst->next_state;
+ }
+ return -EINVAL;
+}
+
+int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state)
+{
+ struct power_state *pwrst;
+
+ list_for_each_entry(pwrst, &pwrst_list, node) {
+ if (pwrst->pwrdm == pwrdm) {
+ pwrst->next_state = state;
+ return 0;
+ }
+ }
+ return -EINVAL;
+}
+
static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
{
struct power_state *pwrst;
--
1.5.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM : OMAP: Pass logical DMA channel number always to callback handlers
On Wed, 26 Nov 2008 14:43:02 +0530 "ext Shilimkar, Santosh" <[EMAIL PROTECTED]> wrote: > Hi Jarkko\Tony , > > Recently during some debugging, I observed this patch. > http://source.mvista.com/git/?p=linux-omap-2.6.git;a=commitdiff;h=538528de0cb256f65716ab2e9613d9e920f97fe2;hp=29e8c3c304b62f31b799565c9ee85d42bd163f80 > > As per your description,it improves the debugging. Can you elaborate more on > this ? > Honestly don't remember what I meant for easier debugging, probably just watching how the logical channels are rotating during the transfer or something like that. > For users this change is little confusing, if they go as per the signatures > of the 'omap_request_dma_chain' and 'omap_request_dma' APIs. Also separating > the callbacks for chained and non-chained transfers seems to be the practical > usage in most of the cases. Also users would be only interested in 'chain_id' > and not 'channel number' in case of chaining. > As commit log says, user can pass the chain_id via callback data if needed. I think chained dma callback may also find more use for logical channel number than chain_id e.g. when modifying the transfer parameters etc. And uniform, smaller API set is always better than bloated one. Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please fix or remove OMAP2 onenand driver
On Mon, Nov 24, 2008 at 02:44:36PM +0200, Adrian Hunter wrote: > From: Adrian Hunter <[EMAIL PROTECTED]> > Date: Mon, 24 Nov 2008 13:34:53 +0200 > Subject: [PATCH] MTD: OMAP: OneNAND: header file relocation > > Signed-off-by: Adrian Hunter <[EMAIL PROTECTED]> Great. Acked-by: Russell King <[EMAIL PROTECTED]> David, can you merge this patch for 2.6.28 please? > --- > drivers/mtd/onenand/omap2.c | 17 - > 1 files changed, 8 insertions(+), 9 deletions(-) > > diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c > index e39b21d..a7e4d98 100644 > --- a/drivers/mtd/onenand/omap2.c > +++ b/drivers/mtd/onenand/omap2.c > @@ -32,19 +32,18 @@ > #include > #include > #include > +#include > +#include > > -#include > #include > -#include > -#include > -#include > -#include > +#include > +#include > +#include > +#include > > -#include > -#include > -#include > +#include > > -#include > +#include > > #define DRIVER_NAME "omap2-onenand" > > -- > 1.5.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PWM drivers for TWL4030
On Wed, Nov 26, 2008 at 3:42 AM, David Brownell <[EMAIL PROTECTED]> wrote: > On Tuesday 25 November 2008, Grazvydas Ignotas wrote: >> > If they're using the LEDA or LEDB PWMs, providing and exporting >> > a brightness control would be easy. If they're using the other >> > two PWMs, it'd be more work. >> >> The configuration is as follows: >> LEDA - keypad backlight >> LEDB - power LED >> PWM0 - LCD backlight >> PWM1 - charger LED > > Might have been better to use LEDA and LEDB for backlights, > you probably could have saved some external hardware ... those > pins are high drive. :) LEDB probably wasn't used for LCD backlight because it doesn't provide enough power (60mA only). Don't know for sure, it wasn't me who designed the hardware. > Right, start as gpio leds. Since I've already looked at it, > I may take a whack at exposing LEDA/LEDB PWMs ... expecting to > use thhe same interface for PWM0/PWM1. That would be great, thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
ARM : OMAP: Pass logical DMA channel number always to callback handlers
Hi Jarkko\Tony , Recently during some debugging, I observed this patch. http://source.mvista.com/git/?p=linux-omap-2.6.git;a=commitdiff;h=538528de0cb256f65716ab2e9613d9e920f97fe2;hp=29e8c3c304b62f31b799565c9ee85d42bd163f80 As per your description,it improves the debugging. Can you elaborate more on this ? For users this change is little confusing, if they go as per the signatures of the 'omap_request_dma_chain' and 'omap_request_dma' APIs. Also separating the callbacks for chained and non-chained transfers seems to be the practical usage in most of the cases. Also users would be only interested in 'chain_id' and not 'channel number' in case of chaining. So if it improves only debugging and some what complicates the usage, I suggest we should revert this patch. Regards, Santosh Shilimkar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
