[PATCH] ASoC: Replace snd_soc_machine by snd_soc_card structure in SDP3430 machine driver
This patch replaces snd_soc_machine structure by snd_soc_card in
SP3430 driver. This change is needed in SDP3430 driver to reflect
changes introduced by ASoC: Rename snd_soc_card to snd_soc_machine patch
(875065491fba8eb13219f16c36e79a6fb4e15c68).
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
---
sound/soc/omap/sdp3430.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/omap/sdp3430.c b/sound/soc/omap/sdp3430.c
index ad97836..e226fa7 100644
--- a/sound/soc/omap/sdp3430.c
+++ b/sound/soc/omap/sdp3430.c
@@ -91,7 +91,7 @@ static struct snd_soc_dai_link sdp3430_dai = {
};
/* Audio machine driver */
-static struct snd_soc_machine snd_soc_machine_sdp3430 = {
+static struct snd_soc_card snd_soc_sdp3430 = {
.name = SDP3430,
.platform = omap_soc_platform,
.dai_link = sdp3430_dai,
@@ -100,7 +100,7 @@ static struct snd_soc_machine snd_soc_machine_sdp3430 = {
/* Audio subsystem */
static struct snd_soc_device sdp3430_snd_devdata = {
- .machine = snd_soc_machine_sdp3430,
+ .card = snd_soc_sdp3430,
.codec_dev = soc_codec_dev_twl4030,
};
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: musb OTG broken in 2.6.29-rc3?
On Tue, Feb 10, 2009 at 08:35:31AM +0100, Balbi Felipe (Nokia-D/Helsinki) wrote:
On Tue, Feb 10, 2009 at 05:47:16AM +0100, Ajay Kumar Gupta wrote:
-Original Message-
From: Steve Sakoman [mailto:sako...@gmail.com]
Sent: Tuesday, February 10, 2009 10:13 AM
To: Gupta, Ajay Kumar
Cc: linux-omap
Subject: Re: musb OTG broken in 2.6.29-rc3?
On Mon, Feb 9, 2009 at 8:05 PM, Gupta, Ajay Kumar ajay.gu...@ti.com
wrote:
Before I spend too much time debugging, has anyone else been
successful with musb OTG in 2.6.29-rc3? A quick search of this list
didn't turn up any discussion of issues.
It works fine on OMAP35x EVM too. I had to add a proc entry for session
start
(Switching on the vBus).
Could you give me a little more detail on what you had to do for
session start? Perhaps I have a similar issue on Overo.
It is same $ echo F /proc/driver/musb_hdrc, which was earlier
In musb_procfs.c and now been removed.
+ case 'F':
+ reg = musb_readb(mbase, MUSB_DEVCTL);
+ reg |= MUSB_DEVCTL_SESSION;
+ musb_writeb(mbase, MUSB_DEVCTL, reg);
a temp sysfs for that will help:
Steve, could you try the following
cut here
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 2cc34fa..0ffd611 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1713,6 +1713,32 @@ musb_vbus_show(struct device *dev, struct
device_attribute *attr, char *buf)
}
static DEVICE_ATTR(vbus, 0644, musb_vbus_show, musb_vbus_store);
+static ssize_t
+musb_session_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t n)
+{
+ struct musb *musb = dev_to_musb(dev);
+ unsigned short session;
+ u8 devctl;
+
+ if (sscanf(buf, %hu, session) != 1
+ || (session != 1) || (session != 0)) {
ugg, this should be
here's the updated:
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 2cc34fa..1ea7cfa 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1713,6 +1713,32 @@ musb_vbus_show(struct device *dev, struct
device_attribute *attr, char *buf)
}
static DEVICE_ATTR(vbus, 0644, musb_vbus_show, musb_vbus_store);
+static ssize_t
+musb_session_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t n)
+{
+ struct musb *musb = dev_to_musb(dev);
+ unsigned short session;
+ u8 devctl;
+
+ if (sscanf(buf, %hu, session) != 1
+ || ((session != 1) (session != 0))) {
+ dev_err(dev, value must be 1 on 0\n);
+ return -EINVAL;
+ }
+
+ devctl = musb_readb(musb-mregs, MUSB_DEVCTL);
+ if (session)
+ devctl |= MUSB_DEVCTL_SESSION;
+ else
+ devctl = ~MUSB_DEVCTL_SESSION;
+
+ musb_writeb(musb-mregs, MUSB_DEVCTL, devctl);
+
+ return n;
+}
+static DEVICE_ATTR(session, 0644, NULL, musb_session_store);
+
#ifdef CONFIG_USB_GADGET_MUSB_HDRC
/* Gadget drivers can't know that a host is connected so they might want
@@ -1813,6 +1839,7 @@ static void musb_free(struct musb *musb)
*/
#ifdef CONFIG_SYSFS
+ device_remove_file(musb-controller, dev_attr_session);
device_remove_file(musb-controller, dev_attr_mode);
device_remove_file(musb-controller, dev_attr_vbus);
#ifdef CONFIG_USB_MUSB_OTG
@@ -2047,6 +2074,7 @@ bad_config:
}
#ifdef CONFIG_SYSFS
+ status = device_create_file(dev, dev_attr_session);
status = device_create_file(dev, dev_attr_mode);
status = device_create_file(dev, dev_attr_vbus);
#ifdef CONFIG_USB_GADGET_MUSB_HDRC
@@ -2061,6 +2089,7 @@ bad_config:
fail2:
#ifdef CONFIG_SYSFS
+ device_remove_file(musb-controller, dev_attr_session);
device_remove_file(musb-controller, dev_attr_mode);
device_remove_file(musb-controller, dev_attr_vbus);
#ifdef CONFIG_USB_MUSB_OTG
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: musb OTG broken in 2.6.29-rc3?
On Tue, 10 Feb 2009 08:35:31 +0100 Balbi Felipe (Nokia-D/Helsinki) felipe.ba...@nokia.com wrote: Could you give me a little more detail on what you had to do for session start? Perhaps I have a similar issue on Overo. It is same $ echo F /proc/driver/musb_hdrc, which was earlier In musb_procfs.c and now been removed. + case 'F': + reg = musb_readb(mbase, MUSB_DEVCTL); + reg |= MUSB_DEVCTL_SESSION; + musb_writeb(mbase, MUSB_DEVCTL, reg); a temp sysfs for that will help: Steve, could you try the following I let Felipe to send new version of the patch where it applies (I had there spaces instead of tabs?) and condition for session value is not true for all values ;-) But for me Beagle work. Ethernet gadget just fine and HS HUB by kicking the session on. Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ASoC: Replace snd_soc_machine by snd_soc_card structure in SDP3430 machine driver
On Tue, 10 Feb 2009 09:05:07 +0100 ext Lopez Cruz, Misael x0052...@ti.com wrote: This patch replaces snd_soc_machine structure by snd_soc_card in SP3430 driver. This change is needed in SDP3430 driver to reflect changes introduced by ASoC: Rename snd_soc_card to snd_soc_machine patch (875065491fba8eb13219f16c36e79a6fb4e15c68). Signed-off-by: Misael Lopez Cruz x0052...@ti.com --- sound/soc/omap/sdp3430.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) IMO, this is for 2.6.29-rc since it fixes a compilation error. Acked-by: Jarkko Nikula jarkko.nik...@nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP I2C: Include OMAP_I2C_SYSC_REG in save and restore.
Kevin,
Did you get a chance to review this patch?
--
Jagadeesh
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Pakaravoor, Jagadeesh
Sent: Thursday, January 22, 2009 12:49 PM
To: linux-omap@vger.kernel.org
Cc: jouni.hogan...@nokia.com; khil...@deeprootsystems.com
Subject: [PATCH] OMAP I2C: Include OMAP_I2C_SYSC_REG in save and restore.
From: Jagadeesh Bhaskar Pakaravoor j-pakarav...@ti.com
Save and restore should include OMAP_I2C_SYSC_REG.
This patch applies on origin/pm.
Signed-off-by: Jagadeesh Bhaskar Pakaravoor j-pakarav...@ti.com
---
Index: linux-omap-2.6/drivers/i2c/busses/i2c-omap.c
===
--- linux-omap-2.6.orig/drivers/i2c/busses/i2c-omap.c 2009-01-22
12:11:12.0 +0530
+++ linux-omap-2.6/drivers/i2c/busses/i2c-omap.c 2009-01-22
12:44:12.202367296 +0530
@@ -182,6 +182,7 @@ struct omap_i2c_dev {
u16 scllstate;
u16 sclhstate;
u16 bufstate;
+ u16 syscstate;
};
static inline void omap_i2c_write_reg(struct omap_i2c_dev *i2c_dev,
@@ -240,6 +241,7 @@ static void omap_i2c_unidle(struct omap_
omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev-bufstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, dev-syscstate);
}
dev-idle = 0;
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
@@ -300,14 +302,15 @@ static int omap_i2c_init(struct omap_i2c
} else if (dev-rev = OMAP_I2C_REV_ON_3430) {
u32 v;
- v = SYSC_AUTOIDLE_MASK;
- v |= SYSC_ENAWAKEUP_MASK;
- v |= (SYSC_IDLEMODE_SMART
+ dev-syscstate = SYSC_AUTOIDLE_MASK;
+ dev-syscstate |= SYSC_ENAWAKEUP_MASK;
+ dev-syscstate |= (SYSC_IDLEMODE_SMART
__ffs(SYSC_SIDLEMODE_MASK));
- v |= (SYSC_CLOCKACTIVITY_FCLK
+ dev-syscstate |= (SYSC_CLOCKACTIVITY_FCLK
__ffs(SYSC_CLOCKACTIVITY_MASK));
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, v);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
+ dev-syscstate);
/*
* Enabling all wakup sources to stop I2C freezing on
* WFI instruction.
--
With Regards,
Jagadeesh Bhaskar P
Some men see things as they are and say why - I dream things that never were
and say why not.
- George Bernard Shaw
---
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Remaining bits for basic support of LDP
On Mon, Feb 02, 2009 at 10:29:09PM +, Russell King - ARM Linux wrote: On Mon, Feb 02, 2009 at 01:45:30PM -0800, David Miller wrote: From: Russell King - ARM Linux li...@arm.linux.org.uk Date: Mon, 2 Feb 2009 21:39:53 + The patch to fix these issues would seem to be relatively small (12 lines in the smc911x and one line change in board-ldp.c) - is it something we want done for -rc4 or do we scrap the ethernet support on the LDP until the SMSC driver has been merged ? Obviously, having working ethernet would be helpful, and since it was half heartedly merged when the initial OMAP3 stuff went upstream we should do something with it one way or another. Well, the SMSC driver is there already in the tree. The only thing not currently being scheduled to hit 2.6.29-rcX are the recent changes to support platform specified interrupt flags and all of that stuff. If you want, we can look into pushing that work into 2.6.29-rcX Hmm. Since we should assume that the other smc911x using platforms work as-is, merging Steve's first four and the LDP patch seems to be a sane idea. We can queue the remainder for when bugs are reported or the next merge window, whichever comes earlier. So, what's happening on this? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Remaining bits for basic support of LDP
On Tue, Feb 10, 2009 at 11:48:55AM +, Russell King - ARM Linux wrote:
On Mon, Feb 02, 2009 at 10:29:09PM +, Russell King - ARM Linux wrote:
On Mon, Feb 02, 2009 at 01:45:30PM -0800, David Miller wrote:
From: Russell King - ARM Linux li...@arm.linux.org.uk
Date: Mon, 2 Feb 2009 21:39:53 +
The patch to fix these issues would seem to be relatively small (12
lines in the smc911x and one line change in board-ldp.c) - is it
something we want done for -rc4 or do we scrap the ethernet support
on the LDP until the SMSC driver has been merged ?
Obviously, having working ethernet would be helpful, and since it was
half heartedly merged when the initial OMAP3 stuff went upstream we
should do something with it one way or another.
Well, the SMSC driver is there already in the tree.
The only thing not currently being scheduled to hit
2.6.29-rcX are the recent changes to support platform
specified interrupt flags and all of that stuff.
If you want, we can look into pushing that work into
2.6.29-rcX
Hmm. Since we should assume that the other smc911x using platforms work
as-is, merging Steve's first four and the LDP patch seems to be a sane
idea. We can queue the remainder for when bugs are reported or the
next merge window, whichever comes earlier.
So, what's happening on this?
For the record, this is what the patch for fixing smc911x to work on
the LDP looks like. It's been tested on the LDP and works. It has
a minimal impact, so this is probably a better patch to merge for
2.6.29 rather than the smsc911x conversion patches which are more
invasive.
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 61f7c36..d544965 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -81,7 +87,7 @@ static inline void __init ldp_init_smc911x(void)
}
ldp_smc911x_resources[0].start = cs_mem_base + 0x0;
- ldp_smc911x_resources[0].end = cs_mem_base + 0xf;
+ ldp_smc911x_resources[0].end = cs_mem_base + 0xff;
udelay(100);
eth_gpio = LDP_SMC911X_GPIO;
diff --git a/drivers/net/smc911x.h b/drivers/net/smc911x.h
index 870b4c3..a45952e 100644
--- a/drivers/net/smc911x.h
+++ b/drivers/net/smc911x.h
@@ -42,6 +42,16 @@
#define SMC_USE_16BIT0
#define SMC_USE_32BIT1
#define SMC_IRQ_SENSEIRQF_TRIGGER_LOW
+#elif defined(CONFIG_ARCH_OMAP34XX)
+ #define SMC_USE_16BIT0
+ #define SMC_USE_32BIT1
+ #define SMC_IRQ_SENSEIRQF_TRIGGER_LOW
+ #define SMC_MEM_RESERVED 1
+#elif defined(CONFIG_ARCH_OMAP24XX)
+ #define SMC_USE_16BIT0
+ #define SMC_USE_32BIT1
+ #define SMC_IRQ_SENSEIRQF_TRIGGER_LOW
+ #define SMC_MEM_RESERVED 1
#else
/*
* Default configuration
@@ -675,6 +685,7 @@ smc_pxa_dma_outsl(struct smc911x_local *lp, u_long physaddr,
#define CHIP_9116 0x0116
#define CHIP_9117 0x0117
#define CHIP_9118 0x0118
+#define CHIP_9211 0x9211
#define CHIP_9215 0x115A
#define CHIP_9217 0x117A
#define CHIP_9218 0x118A
@@ -689,6 +700,7 @@ static const struct chip_id chip_ids[] = {
{ CHIP_9116, LAN9116 },
{ CHIP_9117, LAN9117 },
{ CHIP_9118, LAN9118 },
+ { CHIP_9211, LAN9211 },
{ CHIP_9215, LAN9215 },
{ CHIP_9217, LAN9217 },
{ CHIP_9218, LAN9218 },
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] Pad configuration for OMAP3EVM Multi-Media Daughter Card Support
Thanks,
Vaibhav Hiremath
-Original Message-
From: Hiremath, Vaibhav
Sent: Friday, January 30, 2009 12:52 AM
To: linux-omap@vger.kernel.org
Cc: linux-me...@vger.kernel.org; Hiremath, Vaibhav; Jadav, Brijesh
R; Shah, Hardik
Subject: [PATCH 1/2] Pad configuration for OMAP3EVM Multi-Media
Daughter Card Support
From: Vaibhav Hiremath hvaib...@ti.com
On OMAP3EVM Mass Market Daugher Card following GPIO pins are being
used -
GPIO134 -- Enable/Disable TVP5146 interface
GPIO54 -- Enable/Disable Expansion Camera interface
GPIO136 -- Enable/Disable Camera (Sensor) interface
Added entry for the above GPIO's in mux.c and mux.h file
Signed-off-by: Brijesh Jadav brijes...@ti.com
Signed-off-by: Hardik Shah hardik.s...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/mux.c |6 ++
arch/arm/plat-omap/include/mach/mux.h |5 -
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 1556688..d226d81 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -471,6 +471,12 @@ MUX_CFG_34XX(AF5_34XX_GPIO142, 0x170,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
MUX_CFG_34XX(AE5_34XX_GPIO143, 0x172,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+MUX_CFG_34XX(AG4_34XX_GPIO134, 0x160,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+MUX_CFG_34XX(U8_34XX_GPIO54, 0x0b4,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+MUX_CFG_34XX(AE4_34XX_GPIO136, 0x164,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
};
diff --git a/arch/arm/plat-omap/include/mach/mux.h b/arch/arm/plat-
omap/include/mach/mux.h
index 67fddec..ace037f 100644
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -795,7 +795,10 @@ enum omap34xx_index {
AF6_34XX_GPIO140_UP,
AE6_34XX_GPIO141,
AF5_34XX_GPIO142,
- AE5_34XX_GPIO143
+ AE5_34XX_GPIO143,
+ AG4_34XX_GPIO134,
+ U8_34XX_GPIO54,
+ AE4_34XX_GPIO136,
};
[Hiremath, Vaibhav] If there are no review comments on this then probably this
patch should go through, since this is independent and being used with
Multi-Media Daughter card support.
struct omap_mux_cfg {
--
1.5.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [REVIEW PATCH 2/2] OMAP3EVM Multi-Media Daughter Card Support
Thanks, Vaibhav Hiremath -Original Message- From: Alexey Klimov [mailto:klimov.li...@gmail.com] Sent: Saturday, January 31, 2009 9:59 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; linux-me...@vger.kernel.org; Jadav, Brijesh R; Shah, Hardik Subject: Re: [REVIEW PATCH 2/2] OMAP3EVM Multi-Media Daughter Card Support Hello, Vaibhav May i tell few suggestions ? On Fri, 2009-01-30 at 00:52 +0530, hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@ti.com This is second version of OMAP3EVM Mulit-Media/Mass Market Daughter Card support. Fixes: - Cleaned unused header files, struct formating, and unused comments. - Pad/mux configuration handled in mux.ch - mux.ch related changes moved to seperate patch - Renamed file board-omap3evm-dc.c to board-omap3evm-dc-v4l.c to make more explicit. - Added some more meaningful name for Kconfig option TODO: - Camera sensor support (for future development). - Driver header file inclusion (dependency on ISP-Camera patches) I am working with Sergio to seperate/move header file to standard location. - Still need to fix naming convention for DC Tested: - TVP5146 (BT656) decoder interface on top of Sergio's ISP-Camera patches. - Loopback application, capturing image through TVP5146 and saving it to file per frame. - Basic functionality of HSUSB Transceiver USB-83320 Signed-off-by: Brijesh Jadav brijes...@ti.com Signed-off-by: Hardik Shah hardik.s...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- arch/arm/mach-omap2/Kconfig |8 +- arch/arm/mach-omap2/Makefile|1 + arch/arm/mach-omap2/board-omap3evm-dc-v4l.c | 348 +++ arch/arm/mach-omap2/board-omap3evm-dc.h | 42 4 files changed, 398 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/board-omap3evm-dc-v4l.c create mode 100644 arch/arm/mach-omap2/board-omap3evm-dc.h [Hiremath, Vaibhav] This patch is strongly dependent on ISP-Camera patches, and need rebase/refreshment/synchronization with latest code-base from Sergio and Sakari. I believe they are under process of fixing review comments. Since there are only minor review comments received for MMDC patch, I will wait till the time Sergio posts the patches supporting ISP-Camera module. And then I will submit it to the community after refreshing on top of it (with review comment fix). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/8] i2c: lp5521: cosmetic fixes
General cleanup to the code. Preparing to send it to
mainline.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
drivers/i2c/chips/lp5521.c | 159
1 files changed, 73 insertions(+), 86 deletions(-)
diff --git a/drivers/i2c/chips/lp5521.c b/drivers/i2c/chips/lp5521.c
index 7fb8091..e040c4d 100644
--- a/drivers/i2c/chips/lp5521.c
+++ b/drivers/i2c/chips/lp5521.c
@@ -1,5 +1,5 @@
/*
- * drivers/i2c/chips/lp5521.c
+ * lp5521.c - LP5521 LED Driver
*
* Copyright (C) 2007 Nokia Corporation
*
@@ -24,7 +24,6 @@
#include linux/init.h
#include linux/i2c.h
#include linux/mutex.h
-#include mach/gpio.h
#define LP5521_DRIVER_NAME lp5521
@@ -71,6 +70,7 @@
#define LP5521_PROGRAM_LENGTH 32 /* in bytes */
struct lp5521_chip {
+ /* device lock */
struct mutexlock;
struct i2c_client *client;
char*mode;
@@ -81,20 +81,14 @@ struct lp5521_chip {
static int lp5521_set_mode(struct lp5521_chip *chip, char *mode);
-static int lp5521_write(struct i2c_client *client, u8 reg, u8 value)
+static inline int lp5521_write(struct i2c_client *client, u8 reg, u8 value)
{
return i2c_smbus_write_byte_data(client, reg, value);
}
-static int lp5521_read(struct i2c_client *client, u8 reg, u8 *buf)
+static inline int lp5521_read(struct i2c_client *client, u8 reg)
{
- s32 ret = i2c_smbus_read_byte_data(client, reg);
-
- if (ret 0)
- return -EIO;
-
- *buf = ret;
- return 0;
+ return i2c_smbus_read_byte_data(client, reg);
}
static int lp5521_configure(struct i2c_client *client)
@@ -136,19 +130,19 @@ static int lp5521_load_program(struct lp5521_chip *chip,
u8 *pattern)
if (chip-red)
ret |= i2c_smbus_write_i2c_block_data(client,
- LP5521_REG_R_PROG_MEM,
- LP5521_PROGRAM_LENGTH,
- pattern);
+ LP5521_REG_R_PROG_MEM,
+ LP5521_PROGRAM_LENGTH,
+ pattern);
if (chip-green)
ret |= i2c_smbus_write_i2c_block_data(client,
- LP5521_REG_G_PROG_MEM,
- LP5521_PROGRAM_LENGTH,
- pattern);
+ LP5521_REG_G_PROG_MEM,
+ LP5521_PROGRAM_LENGTH,
+ pattern);
if (chip-blue)
ret |= i2c_smbus_write_i2c_block_data(client,
- LP5521_REG_B_PROG_MEM,
- LP5521_PROGRAM_LENGTH,
- pattern);
+ LP5521_REG_B_PROG_MEM,
+ LP5521_PROGRAM_LENGTH,
+ pattern);
return ret;
}
@@ -156,31 +150,33 @@ static int lp5521_load_program(struct lp5521_chip *chip,
u8 *pattern)
static int lp5521_run_program(struct lp5521_chip *chip)
{
struct i2c_client *client = chip-client;
- int ret;
+ int reg;
u8 mask = 0xc0;
u8 exec_state = 0;
- u8 enable_reg;
- ret = lp5521_read(client, LP5521_REG_ENABLE, enable_reg);
- if (ret)
- goto fail;
+ reg = lp5521_read(client, LP5521_REG_ENABLE);
+ if (reg 0)
+ return reg;
- enable_reg = mask;
+ reg = mask;
/* set all active channels exec state to countinous run*/
- exec_state |= (chip-red5);
+ exec_state |= (chip-red 5);
exec_state |= (chip-green 3);
- exec_state |= (chip-blue 1);
+ exec_state |= (chip-blue 1);
- enable_reg |= exec_state;
+ reg |= exec_state;
- ret |= lp5521_write(client, LP5521_REG_ENABLE, enable_reg);
+ if (lp5521_write(client, LP5521_REG_ENABLE, reg))
+ dev_dbg(client-dev, failed writing to register %02x\n,
+ LP5521_REG_ENABLE);
/* set op-mode to run for active channels, disabled for others */
- ret |= lp5521_write(client, LP5521_REG_OP_MODE, exec_state);
+ if (lp5521_write(client, LP5521_REG_OP_MODE, exec_state))
+ dev_dbg(client-dev, failed writing to register %02x\n,
+ LP5521_REG_OP_MODE);
-fail:
- return ret;
+ return 0;
}
/*--*/
@@ -188,8 +184,8 @@ fail:
/*--*/
static ssize_t show_active_channels(struct device *dev,
- struct device_attribute *attr,
-
[PATCH 0/8] updates to two nokia drivers
Hi Tony, all,
I'd like to get these integrated so afterwards I can
send the drivers to mainline.
At least lp5521 is in pretty good shape for mainline,
I'd say, but maybe lm8323 will get some comments.
Anyways, these were tested on n810.
Felipe Balbi (8):
i2c: lp5521: remove dead code
i2c: lp5521: cosmetic fixes
i2c: lp5521: simplify mode setting
i2c: lp5521: move to LED framework
leds: lp5521: move to drivers/leds
input: lm8323: get rid of global pdata pointer
input: lm8323: get rid of useless debug macro
input: lm8323: general clean up
arch/arm/mach-omap2/board-n800.c | 14 +-
drivers/i2c/chips/Kconfig |7 -
drivers/i2c/chips/Makefile |1 -
drivers/input/keyboard/lm8323.c| 113 +++
drivers/leds/Kconfig | 10 +
drivers/leds/Makefile |1 +
drivers/{i2c/chips/lp5521.c = leds/leds-lp5521.c} | 379 +---
7 files changed, 321 insertions(+), 204 deletions(-)
rename drivers/{i2c/chips/lp5521.c = leds/leds-lp5521.c} (62%)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] i2c: lp5521: simplify mode setting
Avoid using string magic and use integer for comparisson
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
drivers/i2c/chips/lp5521.c | 52 ---
1 files changed, 38 insertions(+), 14 deletions(-)
diff --git a/drivers/i2c/chips/lp5521.c b/drivers/i2c/chips/lp5521.c
index e040c4d..9e94ff8 100644
--- a/drivers/i2c/chips/lp5521.c
+++ b/drivers/i2c/chips/lp5521.c
@@ -46,10 +46,6 @@
#define LP5521_REG_G_PROG_MEM 0x30
#define LP5521_REG_B_PROG_MEM 0x50
-#define LP5521_MODE_LOAD load
-#define LP5521_MODE_RUNrun
-#define LP5521_MODE_DIRECT_CONTROL direct
-
#define LP5521_CURRENT_1m5 0x0f
#define LP5521_CURRENT_3m1 0x1f
#define LP5521_CURRENT_4m7 0x2f
@@ -69,17 +65,23 @@
#define LP5521_PROGRAM_LENGTH 32 /* in bytes */
+enum lp5521_mode {
+ LP5521_MODE_LOAD,
+ LP5521_MODE_RUN,
+ LP5521_MODE_DIRECT_CONTROL,
+};
+
struct lp5521_chip {
/* device lock */
struct mutexlock;
struct i2c_client *client;
- char*mode;
+ enum lp5521_modemode;
int red;
int green;
int blue;
};
-static int lp5521_set_mode(struct lp5521_chip *chip, char *mode);
+static int lp5521_set_mode(struct lp5521_chip *chip, enum lp5521_mode mode);
static inline int lp5521_write(struct i2c_client *client, u8 reg, u8 value)
{
@@ -313,8 +315,25 @@ static ssize_t show_mode(struct device *dev,
char *buf)
{
struct lp5521_chip *chip = dev_get_drvdata(dev);
+ char *mode;
+
+ mutex_lock(chip-lock);
+ switch (chip-mode) {
+ case LP5521_MODE_RUN:
+ mode = run;
+ break;
+ case LP5521_MODE_LOAD:
+ mode = load;
+ break;
+ case LP5521_MODE_DIRECT_CONTROL:
+ mode = direct;
+ break;
+ default:
+ mode = undefined;
+ }
+ mutex_unlock(chip-lock);
- return sprintf(buf, %s\n, chip-mode);
+ return sprintf(buf, %s\n, mode);
}
static ssize_t store_mode(struct device *dev,
@@ -442,23 +461,28 @@ static void lp5521_unregister_sysfs(struct i2c_client
*client)
/* Set chip operating mode */
/*--*/
-static int lp5521_set_mode(struct lp5521_chip *chip, char *mode)
+static int lp5521_set_mode(struct lp5521_chip *chip, enum lp5521_mode mode)
{
struct i2c_client *client = chip-client ;
int ret = 0;
/* if in that mode already do nothing, except for run */
- if (!strcmp(mode, chip-mode) strcmp(mode, LP5521_MODE_RUN))
+ if (chip-mode == mode mode != LP5521_MODE_RUN)
return 0;
- if (!strcmp(mode, LP5521_MODE_RUN))
+ switch (mode) {
+ case LP5521_MODE_RUN:
ret = lp5521_run_program(chip);
-
- if (!strcmp(mode, LP5521_MODE_LOAD))
+ break;
+ case LP5521_MODE_LOAD:
ret |= lp5521_write(client, LP5521_REG_OP_MODE, 0x15);
-
- if (!strcmp(mode, LP5521_MODE_DIRECT_CONTROL))
+ break;
+ case LP5521_MODE_DIRECT_CONTROL:
ret |= lp5521_write(client, LP5521_REG_OP_MODE, 0x3F);
+ break;
+ default:
+ dev_dbg(client-dev, unsupported mode %d\n, mode);
+ }
chip-mode = mode;
--
1.6.1.265.g9a013
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] input: lm8323: get rid of useless debug macro
we can use dev_vdbg() which is only true when VERBOSE is
enabled.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
drivers/input/keyboard/lm8323.c | 28 +++-
1 files changed, 11 insertions(+), 17 deletions(-)
diff --git a/drivers/input/keyboard/lm8323.c b/drivers/input/keyboard/lm8323.c
index 60abe61..0812bef 100644
--- a/drivers/input/keyboard/lm8323.c
+++ b/drivers/input/keyboard/lm8323.c
@@ -33,12 +33,6 @@
#include asm/mach-types.h
#include asm/mach/irq.h
-#ifdef VERBOSE
-#define debug dev_dbg
-#else
-#define debug(...)
-#endif
-
/* Commands to send to the chip. */
#define LM8323_CMD_READ_ID 0x80 /* Read chip ID. */
#define LM8323_CMD_WRITE_CFG 0x81 /* Set configuration item. */
@@ -303,7 +297,7 @@ static void process_keys(struct lm8323_chip *lm)
s16 keycode = lm-keymap[key];
if (likely(keycode 0)) {
- debug(lm-client-dev, key 0x%02x %s\n, key,
+ dev_vdbg(lm-client-dev, key 0x%02x %s\n, key,
isdown ? down : up);
if (likely(lm-kp_enabled)) {
input_report_key(lm-idev, keycode, isdown);
@@ -337,13 +331,13 @@ static void lm8323_process_error(struct lm8323_chip *lm)
if (lm8323_read(lm, LM8323_CMD_READ_ERR, error, 1) == 1) {
if (error ERR_FIFOOVER)
- debug(lm-client-dev, fifo overflow!\n);
+ dev_vdbg(lm-client-dev, fifo overflow!\n);
if (error ERR_KEYOVR)
- debug(lm-client-dev, more than two keys pressed\n);
+ dev_vdbg(lm-client-dev, more than two keys
pressed\n);
if (error ERR_CMDUNK)
- debug(lm-client-dev, unknown command submitted\n);
+ dev_vdbg(lm-client-dev, unknown command
submitted\n);
if (error ERR_BADPAR)
- debug(lm-client-dev, bad command parameter\n);
+ dev_vdbg(lm-client-dev, bad command parameter\n);
}
}
@@ -408,10 +402,10 @@ static void lm8323_work(struct work_struct *work)
process_keys(lm);
if (ints INT_ROTATOR) {
/* We don't currently support the rotator. */
- debug(lm-client-dev, rotator fired\n);
+ dev_vdbg(lm-client-dev, rotator fired\n);
}
if (ints INT_ERROR) {
- debug(lm-client-dev, error!\n);
+ dev_vdbg(lm-client-dev, error!\n);
lm8323_process_error(lm);
}
if (ints INT_NOINIT) {
@@ -420,15 +414,15 @@ static void lm8323_work(struct work_struct *work)
lm8323_configure(lm);
}
if (ints INT_PWM1) {
- debug(lm-client-dev, pwm1 engine completed\n);
+ dev_vdbg(lm-client-dev, pwm1 engine completed\n);
pwm_done(lm-pwm1);
}
if (ints INT_PWM2) {
- debug(lm-client-dev, pwm2 engine completed\n);
+ dev_vdbg(lm-client-dev, pwm2 engine completed\n);
pwm_done(lm-pwm2);
}
if (ints INT_PWM3) {
- debug(lm-client-dev, pwm3 engine completed\n);
+ dev_vdbg(lm-client-dev, pwm3 engine completed\n);
pwm_done(lm-pwm3);
}
}
@@ -714,7 +708,7 @@ static int lm8323_probe(struct i2c_client *client,
lm-size_x = 12;
}
- debug(c-dev, Keypad size: %d x %d\n, lm-size_x, lm-size_y);
+ dev_vdbg(client-dev, Keypad size: %d x %d\n, lm-size_x,
lm-size_y);
lm-debounce_time = pdata-debounce_time;
if (lm-debounce_time == 0) /* Default. */
--
1.6.1.265.g9a013
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] input: lm8323: get rid of global pdata pointer
pdata is only used during probe to initialize a few fields
from lm8323 device structure. Moving pdata pointer to probe
won't harm anybody.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
drivers/input/keyboard/lm8323.c | 34 --
1 files changed, 16 insertions(+), 18 deletions(-)
diff --git a/drivers/input/keyboard/lm8323.c b/drivers/input/keyboard/lm8323.c
index 342ef6a..60abe61 100644
--- a/drivers/input/keyboard/lm8323.c
+++ b/drivers/input/keyboard/lm8323.c
@@ -186,9 +186,6 @@ static struct lm8323_chip *pwm_to_lm8323(struct lm8323_pwm
*pwm)
}
}
-static struct lm8323_platform_data *lm8323_pdata;
-
-
#define LM8323_MAX_DATA 8
/*
@@ -682,6 +679,7 @@ static DEVICE_ATTR(disable_kp, 0644, lm8323_show_disable,
lm8323_set_disable);
static int lm8323_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
+ struct lm8323_platform_data *pdata;
struct input_dev *idev;
struct lm8323_chip *lm;
int i, err = 0;
@@ -694,11 +692,11 @@ static int lm8323_probe(struct i2c_client *client,
i2c_set_clientdata(client, lm);
lm-client = client;
- lm8323_pdata = client-dev.platform_data;
- if (!lm8323_pdata)
+ pdata = client-dev.platform_data;
+ if (!pdata)
return -EINVAL; /* ? */
- lm-size_x = lm8323_pdata-size_x;
+ lm-size_x = pdata-size_x;
if (lm-size_x == 0) {
lm-size_x = 8;
} else if (lm-size_x 8) {
@@ -707,7 +705,7 @@ static int lm8323_probe(struct i2c_client *client,
lm-size_x = 8;
}
- lm-size_y = lm8323_pdata-size_y;
+ lm-size_y = pdata-size_y;
if (lm-size_y == 0) {
lm-size_y = 12;
} else if (lm-size_y 12) {
@@ -718,13 +716,13 @@ static int lm8323_probe(struct i2c_client *client,
debug(c-dev, Keypad size: %d x %d\n, lm-size_x, lm-size_y);
- lm-debounce_time = lm8323_pdata-debounce_time;
+ lm-debounce_time = pdata-debounce_time;
if (lm-debounce_time == 0) /* Default. */
lm-debounce_time = 12;
else if (lm-debounce_time == -1) /* Disable debounce. */
lm-debounce_time = 0;
- lm-active_time = lm8323_pdata-active_time;
+ lm-active_time = pdata-active_time;
if (lm-active_time == 0) /* Default. */
lm-active_time = 500;
else if (lm-active_time == -1) /* Disable sleep. */
@@ -756,11 +754,11 @@ static int lm8323_probe(struct i2c_client *client,
goto fail2;
}
- if (init_pwm(lm, 1, client-dev, lm8323_pdata-pwm1_name) 0)
+ if (init_pwm(lm, 1, client-dev, pdata-pwm1_name) 0)
goto fail3;
- if (init_pwm(lm, 2, client-dev, lm8323_pdata-pwm2_name) 0)
+ if (init_pwm(lm, 2, client-dev, pdata-pwm2_name) 0)
goto fail4;
- if (init_pwm(lm, 3, client-dev, lm8323_pdata-pwm3_name) 0)
+ if (init_pwm(lm, 3, client-dev, pdata-pwm3_name) 0)
goto fail5;
mutex_init(lm-lock);
@@ -787,8 +785,8 @@ static int lm8323_probe(struct i2c_client *client,
goto fail8;
}
- if (lm8323_pdata-name)
- idev-name = lm8323_pdata-name;
+ if (pdata-name)
+ idev-name = pdata-name;
else
idev-name = LM8323 keypad;
snprintf(lm-phys, sizeof(lm-phys), %s/input-kp, client-dev.bus_id);
@@ -797,13 +795,13 @@ static int lm8323_probe(struct i2c_client *client,
lm-keys_down = 0;
idev-evbit[0] = BIT(EV_KEY);
for (i = 0; i LM8323_KEYMAP_SIZE; i++) {
- if (lm8323_pdata-keymap[i] 0)
- set_bit(lm8323_pdata-keymap[i], idev-keybit);
+ if (pdata-keymap[i] 0)
+ set_bit(pdata-keymap[i], idev-keybit);
- lm-keymap[i] = lm8323_pdata-keymap[i];
+ lm-keymap[i] = pdata-keymap[i];
}
- if (lm8323_pdata-repeat)
+ if (pdata-repeat)
set_bit(EV_REP, idev-evbit);
lm-idev = idev;
--
1.6.1.265.g9a013
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8] i2c: lp5521: move to LED framework
Register three separate leds for lp5521 and allow
them to be controlled separately while keeping
backwards compatibility with userspace programs
based on old implementation.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
drivers/i2c/chips/lp5521.c | 146 +++-
1 files changed, 144 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/chips/lp5521.c b/drivers/i2c/chips/lp5521.c
index 9e94ff8..a5c3425 100644
--- a/drivers/i2c/chips/lp5521.c
+++ b/drivers/i2c/chips/lp5521.c
@@ -4,6 +4,7 @@
* Copyright (C) 2007 Nokia Corporation
*
* Written by Mathias Nyman mathias.ny...@nokia.com
+ * Updated by Felipe Balbi felipe.ba...@nokia.com
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -23,7 +24,9 @@
#include linux/module.h
#include linux/init.h
#include linux/i2c.h
+#include linux/leds.h
#include linux/mutex.h
+#include linux/workqueue.h
#define LP5521_DRIVER_NAME lp5521
@@ -75,7 +78,17 @@ struct lp5521_chip {
/* device lock */
struct mutexlock;
struct i2c_client *client;
+
+ struct work_struct red_work;
+ struct work_struct green_work;
+ struct work_struct blue_work;
+
+ struct led_classdev ledr;
+ struct led_classdev ledg;
+ struct led_classdev ledb;
+
enum lp5521_modemode;
+
int red;
int green;
int blue;
@@ -489,6 +502,87 @@ static int lp5521_set_mode(struct lp5521_chip *chip, enum
lp5521_mode mode)
return ret;
}
+static void lp5521_red_work(struct work_struct *work)
+{
+ struct lp5521_chip *chip = container_of(work, struct lp5521_chip,
red_work);
+ int ret;
+
+ ret = lp5521_configure(chip-client);
+ if (ret) {
+ dev_dbg(chip-client-dev, could not configure lp5521, %d\n,
+ ret);
+ return;
+ }
+
+ ret = lp5521_write(chip-client, LP5521_REG_R_PWM, chip-red);
+ if (ret)
+ dev_dbg(chip-client-dev, could not set brightness, %d\n,
+ ret);
+}
+
+static void lp5521_red_set(struct led_classdev *led,
+ enum led_brightness value)
+{
+ struct lp5521_chip *chip = container_of(led, struct lp5521_chip, ledr);
+
+ chip-red = value;
+ schedule_work(chip-red_work);
+}
+
+static void lp5521_green_work(struct work_struct *work)
+{
+ struct lp5521_chip *chip = container_of(work, struct lp5521_chip,
green_work);
+ int ret;
+
+ ret = lp5521_configure(chip-client);
+ if (ret) {
+ dev_dbg(chip-client-dev, could not configure lp5521, %d\n,
+ ret);
+ return;
+ }
+
+ ret = lp5521_write(chip-client, LP5521_REG_G_PWM, chip-green);
+ if (ret)
+ dev_dbg(chip-client-dev, could not set brightness, %d\n,
+ ret);
+}
+
+static void lp5521_green_set(struct led_classdev *led,
+ enum led_brightness value)
+{
+ struct lp5521_chip *chip = container_of(led, struct lp5521_chip, ledg);
+
+ chip-green = value;
+ schedule_work(chip-green_work);
+}
+
+static void lp5521_blue_work(struct work_struct *work)
+{
+ struct lp5521_chip *chip = container_of(work, struct lp5521_chip,
blue_work);
+ int ret;
+
+ ret = lp5521_configure(chip-client);
+ if (ret) {
+ dev_dbg(chip-client-dev, could not configure lp5521, %d\n,
+ ret);
+ return;
+ }
+
+ ret = lp5521_write(chip-client, LP5521_REG_B_PWM, chip-blue);
+ if (ret)
+ dev_dbg(chip-client-dev, could not set brightness, %d\n,
+ ret);
+}
+
+static void lp5521_blue_set(struct led_classdev *led,
+ enum led_brightness value)
+{
+ struct lp5521_chip *chip = container_of(led, struct lp5521_chip, ledb);
+
+ chip-blue = value;
+ schedule_work(chip-blue_work);
+}
+
/*--*/
/* Probe, Attach, Remove */
/*--*/
@@ -509,6 +603,10 @@ static int __init lp5521_probe(struct i2c_client *client,
mutex_init(chip-lock);
+ INIT_WORK(chip-red_work, lp5521_red_work);
+ INIT_WORK(chip-green_work, lp5521_green_work);
+ INIT_WORK(chip-blue_work, lp5521_blue_work);
+
ret = lp5521_configure(client);
if (ret 0) {
dev_err(client-dev, lp5521 error configuring chip \n);
@@ -521,14 +619,52 @@ static int __init lp5521_probe(struct i2c_client *client,
chip-green = 1;
chip-blue = 1;
+
[PATCH 5/8] leds: lp5521: move to drivers/leds
This driver should be sitting together with the other
led drivers.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
drivers/i2c/chips/Kconfig |7 ---
drivers/i2c/chips/Makefile |1 -
drivers/leds/Kconfig | 10 ++
drivers/leds/Makefile |1 +
drivers/{i2c/chips/lp5521.c = leds/leds-lp5521.c} |0
5 files changed, 11 insertions(+), 8 deletions(-)
rename drivers/{i2c/chips/lp5521.c = leds/leds-lp5521.c} (100%)
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index bb95b3e..e4831e1 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -141,13 +141,6 @@ config SENSORS_TSL2563
This driver can also be built as a module. If so, the module
will be called tsl2563.
-config LP5521
- tristate LP5521 LED driver chip
- depends on I2C
- help
- If you say yes here you get support for the National Semiconductor
- LP5521 LED driver.
-
config MENELAUS
bool TWL92330/Menelaus PM chip
depends on I2C=y ARCH_OMAP24XX
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index 32a395f..1c94712 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -21,7 +21,6 @@ obj-$(CONFIG_TWL4030_POWEROFF)+= twl4030-poweroff.o
obj-$(CONFIG_TWL4030_PWRBUTTON)+= twl4030-pwrbutton.o
obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
obj-$(CONFIG_RTC_X1205_I2C)+= x1205.o
-obj-$(CONFIG_LP5521) += lp5521.o
ifeq ($(CONFIG_I2C_DEBUG_CHIP),y)
EXTRA_CFLAGS += -DDEBUG
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 4d4ff64..8d0f37e 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -134,6 +134,16 @@ config LEDS_GPIO
outputs. To be useful the particular board must have LEDs
and they must be connected to the GPIO lines.
+config LEDS_LP5521
+ tristate LED Support for the LP5521 LEDs
+ depends on LEDS_CLASS I2C
+ help
+ If you say 'Y' here you get support for the National Semiconductor
+ LP5521 LED driver used in n8x0 boards.
+
+ This driver can be built as a module by choosing 'M'. The module
+ will be called leds-lp5521.
+
config LEDS_CLEVO_MAIL
tristate Mail LED on Clevo notebook (EXPERIMENTAL)
depends on LEDS_CLASS X86 SERIO_I8042 DMI EXPERIMENTAL
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 7ac6ad3..4ab09e8 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_LEDS_COBALT_RAQ) += leds-cobalt-raq.o
obj-$(CONFIG_LEDS_SUNFIRE) += leds-sunfire.o
obj-$(CONFIG_LEDS_PCA9532) += leds-pca9532.o
obj-$(CONFIG_LEDS_GPIO)+= leds-gpio.o
+obj-$(CONFIG_LEDS_LP5521) += leds-lp5521.o
obj-$(CONFIG_LEDS_CLEVO_MAIL) += leds-clevo-mail.o
obj-$(CONFIG_LEDS_HP6XX) += leds-hp6xx.o
obj-$(CONFIG_LEDS_FSG) += leds-fsg.o
diff --git a/drivers/i2c/chips/lp5521.c b/drivers/leds/leds-lp5521.c
similarity index 100%
rename from drivers/i2c/chips/lp5521.c
rename to drivers/leds/leds-lp5521.c
--
1.6.1.265.g9a013
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] i2c: lp5521: remove dead code
That LED_CONNECTED_WRONG was never defined so removing. If someone needs those hooks, add back via proper platform_data instead of nasty ifdefery. Signed-off-by: Felipe Balbi felipe.ba...@nokia.com --- drivers/i2c/chips/lp5521.c | 22 -- 1 files changed, 0 insertions(+), 22 deletions(-) diff --git a/drivers/i2c/chips/lp5521.c b/drivers/i2c/chips/lp5521.c index c0862d9..7fb8091 100644 --- a/drivers/i2c/chips/lp5521.c +++ b/drivers/i2c/chips/lp5521.c @@ -28,13 +28,8 @@ #define LP5521_DRIVER_NAME lp5521 -#ifdef LED_CONNECTED_WRONG -#define LP5521_REG_R_PWM 0x04 -#define LP5521_REG_B_PWM 0x02 -#else #define LP5521_REG_R_PWM 0x02 #define LP5521_REG_B_PWM 0x04 -#endif #define LP5521_REG_ENABLE 0x00 #define LP5521_REG_OP_MODE 0x01 #define LP5521_REG_G_PWM 0x03 @@ -200,22 +195,12 @@ static ssize_t show_active_channels(struct device *dev, char channels[4]; int pos = 0; -#ifdef LED_CONNECTED_WRONG - if (chip-blue) - pos += sprintf(channels + pos, r); - if (chip-green) - pos += sprintf(channels + pos, g); - if (chip-red) - pos += sprintf(channels + pos, b); - -#else if (chip-red) pos += sprintf(channels + pos, r); if (chip-green) pos += sprintf(channels + pos, g); if (chip-blue) pos += sprintf(channels + pos, b); -#endif channels[pos] = '\0'; @@ -232,17 +217,10 @@ static ssize_t store_active_channels(struct device *dev, chip-green = 0; chip-blue = 0; -#ifdef LED_CONNECTED_WRONG - if (strchr(buf, 'r') != NULL) - chip-blue = 1; - if (strchr(buf, 'b') != NULL) - chip-red = 1; -#else if (strchr(buf, 'r') != NULL) chip-red = 1; if (strchr(buf, 'b') != NULL) chip-blue = 1; -#endif if (strchr(buf, 'g') != NULL) chip-green = 1; -- 1.6.1.265.g9a013 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.29-rc3-git 2/2] USB: disable twl4030 USB regulators when cable unplugged
On Sun, 2009-02-08 at 10:52 -0800, David Brownell wrote:
From: Kalle Jokiniemi kalle.jokini...@digia.com
This patch disables LDO regulators VUSB1V5, VUSB1V8, and VUSB3V1
when the USB cable is unplugged, to eliminate that source of power
waste. (Enabled LDOs consume power at all times.)
Please put this one on hold.
A bug has been discovered here. If the twl-regulator is not compiled in,
the twl4030-usb fails while trying to access the reg-fw interfaces (and
not checking error values). Also it's bit confusing how we get different
error values if reg_fw is not compiled (no error) vs. reg_fw is
compiled, but twl_regulator is not... (error)
Also problems with boot order were discovered.
I'll post a set that fixes this soon.
- Kalle
Signed-off-by: Kalle Jokiniemi kalle.jokini...@digia.com
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
Depends on the twl4030 regulator driver, so I'm suggesting this
be merged (with that driver) through the regulator patch queue
to simplify things.
drivers/usb/otg/twl4030-usb.c | 30 --
1 file changed, 24 insertions(+), 6 deletions(-)
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -34,6 +34,7 @@
#include linux/delay.h
#include linux/usb/otg.h
#include linux/i2c/twl4030.h
+#include linux/regulator/consumer.h
/* Register defines */
@@ -246,6 +247,11 @@ struct twl4030_usb {
struct otg_transceiver otg;
struct device *dev;
+ /* TWL4030 internal USB regulator supplies */
+ struct regulator*usb1v5;
+ struct regulator*usb1v8;
+ struct regulator*usb3v1;
+
/* for vbus reporting with irqs disabled */
spinlock_t lock;
@@ -434,6 +440,9 @@ static void twl4030_phy_power(struct twl
pwr = twl4030_usb_read(twl, PHY_PWR_CTRL);
if (on) {
+ regulator_enable(twl-usb1v5);
+ regulator_enable(twl-usb1v8);
+ regulator_enable(twl-usb3v1);
pwr = ~PHY_PWR_PHYPWD;
WARN_ON(twl4030_usb_write_verify(twl, PHY_PWR_CTRL, pwr) 0);
twl4030_usb_write(twl, PHY_CLK_CTRL,
@@ -443,6 +452,9 @@ static void twl4030_phy_power(struct twl
} else {
pwr |= PHY_PWR_PHYPWD;
WARN_ON(twl4030_usb_write_verify(twl, PHY_PWR_CTRL, pwr) 0);
+ regulator_disable(twl-usb1v5);
+ regulator_disable(twl-usb1v8);
+ regulator_disable(twl-usb3v1);
}
}
@@ -480,16 +492,19 @@ static void twl4030_usb_ldo_init(struct
/* input to VUSB3V1 LDO is from VBAT, not VBUS */
twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x14, VUSB_DEDICATED1);
- /* turn on 3.1V regulator */
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x20, VUSB3V1_DEV_GRP);
+ /* Initialize 3.1V regulator */
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB3V1_DEV_GRP);
+ twl-usb3v1 = regulator_get(twl-dev, usb3v1);
twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB3V1_TYPE);
- /* turn on 1.5V regulator */
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x20, VUSB1V5_DEV_GRP);
+ /* Initialize 1.5V regulator */
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB1V5_DEV_GRP);
+ twl-usb1v5 = regulator_get(twl-dev, usb1v5);
twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB1V5_TYPE);
- /* turn on 1.8V regulator */
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x20, VUSB1V8_DEV_GRP);
+ /* Initialize 1.8V regulator */
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB1V8_DEV_GRP);
+ twl-usb1v8 = regulator_get(twl-dev, usb1v8);
twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB1V8_TYPE);
/* disable access to power configuration registers */
@@ -688,6 +703,9 @@ static int __exit twl4030_usb_remove(str
twl4030_usb_clear_bits(twl, POWER_CTRL, POWER_CTRL_OTG_ENAB);
twl4030_phy_power(twl, 0);
+ regulator_put(twl-usb1v5);
+ regulator_put(twl-usb1v8);
+ regulator_put(twl-usb3v1);
kfree(twl);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/1] Group and resource assignments for TWL4030
This patch introduces support for board specific group assignments of TWL4030 resources. The resource type and type2 fields can also be specified. Peter 'p2' De Schrijver (1): Group and resource assignments for TWL4030 drivers/mfd/twl4030-power.c | 95 ++- include/linux/i2c/twl4030.h | 41 ++- 2 files changed, 134 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] Group and resource assignments for TWL4030
Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
---
drivers/mfd/twl4030-power.c | 95 ++-
include/linux/i2c/twl4030.h | 41 ++-
2 files changed, 134 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index d9d1655..c558127 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -38,6 +38,8 @@ static u8 triton_next_free_address = 0x2b;
#define PHY_TO_OFF_PM_MASTER(p)(p - 0x36)
#define PHY_TO_OFF_PM_RECEIVER(p) (p - 0x5b)
+#define NUM_OF_RESOURCES 28
+
/* resource - hfclk */
#define R_HFCLKOUT_DEV_GRP PHY_TO_OFF_PM_RECEIVER(0xe6)
@@ -66,6 +68,42 @@ static u8 triton_next_free_address = 0x2b;
#define KEY_1 0xC0
#define KEY_2 0x0C
+/* resource configuration registers */
+
+#define DEVGROUP_OFFSET0
+#define TYPE_OFFSET1
+
+static int __initdata res_config_addrs[] = {
+ [1] = 0x17,
+ [2] = 0x1b,
+ [3] = 0x1f,
+ [4] = 0x23,
+ [5] = 0x27,
+ [6] = 0x2b,
+ [7] = 0x2f,
+ [8] = 0x33,
+ [9] = 0x37,
+ [10] = 0x3b,
+ [11] = 0x3f,
+ [12] = 0x43,
+ [13] = 0x47,
+ [14] = 0x4b,
+ [15] = 0x55,
+ [16] = 0x63,
+ [17] = 0x71,
+ [18] = 0x74,
+ [19] = 0x77,
+ [20] = 0x7a,
+ [21] = 0x7f,
+ [22] = 0x82,
+ [23] = 0x85,
+ [24] = 0x88,
+ [25] = 0x8b,
+ [26] = 0x8e,
+ [27] = 0x91,
+ [28] = 0x94,
+};
+
static int __init twl4030_write_script_byte(u8 address, u8 byte)
{
int err;
@@ -245,10 +283,57 @@ static int __init load_triton_script(struct
twl4030_script *tscript)
return err;
}
+static void __init twl4030_configure_resource(struct twl4030_resconfig
*rconfig)
+{
+ int rconfig_addr;
+ u8 type;
+
+ if (rconfig-resource NUM_OF_RESOURCES) {
+ printk(KERN_ERR
+ TWL4030 Resource %d does not exist\n,
+ rconfig-resource);
+ return;
+ }
+
+ rconfig_addr = res_config_addrs[rconfig-resource];
+
+ /* Set resource group */
+
+ if (rconfig-devgroup = 0)
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ rconfig-devgroup 5,
+ rconfig_addr + DEVGROUP_OFFSET);
+
+ /* Set resource types */
+
+ if (twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER,
+ type,
+ rconfig_addr + TYPE_OFFSET) 0) {
+ printk(KERN_ERR
+ TWL4030 Resource %d type could not read\n,
+ rconfig-resource);
+ return;
+ }
+
+ if (rconfig-type = 0) {
+ type = ~7;
+ type |= rconfig-type;
+ }
+
+ if (rconfig-type2 = 0) {
+ type = ~(3 3);
+ type |= rconfig-type2 3;
+ }
+
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ type, rconfig_addr + TYPE_OFFSET);
+}
+
void __init twl4030_power_init(struct twl4030_power_data *triton2_scripts)
{
int err = 0;
int i;
+ struct twl4030_resconfig *resconfig;
err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_MASTER, KEY_1,
R_PROTECT_KEY);
@@ -258,12 +343,20 @@ void __init twl4030_power_init(struct twl4030_power_data
*triton2_scripts)
printk(KERN_ERR
TWL4030 Unable to unlock registers\n);
- for (i = 0; i triton2_scripts-size; i++) {
+ for (i = 0; i triton2_scripts-scripts_size; i++) {
err = load_triton_script(triton2_scripts-scripts[i]);
if (err)
break;
}
+ resconfig = triton2_scripts-resource_config;
+ if (resconfig) {
+ while (resconfig-resource) {
+ twl4030_configure_resource(resconfig);
+ resconfig++;
+ }
+ }
+
if (twl4030_i2c_write_u8(TWL4030_MODULE_PM_MASTER, 0, R_PROTECT_KEY))
printk(KERN_ERR
TWL4030 Unable to relock registers\n);
diff --git a/include/linux/i2c/twl4030.h b/include/linux/i2c/twl4030.h
index 93d483d..e6ce1cd 100644
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -243,6 +243,37 @@ int twl4030_i2c_read(u8 mod_no, u8 *value, u8 reg,
unsigned num_bytes);
#define RES_STATE_SLEEP0x8
#define RES_STATE_OFF 0x0
+/* Power resources */
+
+#define RES_VAUX1 1
+#define RES_VAUX2 2
+#define RES_VAUX3 3
+#define RES_VAUX4 4
+#define RES_VMMC1 5
+#define RES_VMMC2 6
+#define RES_VPLL1
Re: [PATCH 1/1] Group and resource assignments for TWL4030
On Tue, Feb 10, 2009 at 02:11:35PM +0100, Peter 'p2' De Schrijver wrote:
Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
---
drivers/mfd/twl4030-power.c | 95
++-
include/linux/i2c/twl4030.h | 41 ++-
2 files changed, 134 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index d9d1655..c558127 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -38,6 +38,8 @@ static u8 triton_next_free_address = 0x2b;
#define PHY_TO_OFF_PM_MASTER(p)(p - 0x36)
#define PHY_TO_OFF_PM_RECEIVER(p) (p - 0x5b)
+#define NUM_OF_RESOURCES 28
+
/* resource - hfclk */
#define R_HFCLKOUT_DEV_GRP PHY_TO_OFF_PM_RECEIVER(0xe6)
@@ -66,6 +68,42 @@ static u8 triton_next_free_address = 0x2b;
#define KEY_1 0xC0
#define KEY_2 0x0C
+/* resource configuration registers */
+
+#define DEVGROUP_OFFSET0
+#define TYPE_OFFSET1
+
+static int __initdata res_config_addrs[] = {
+ [1] = 0x17,
+ [2] = 0x1b,
+ [3] = 0x1f,
+ [4] = 0x23,
+ [5] = 0x27,
+ [6] = 0x2b,
+ [7] = 0x2f,
+ [8] = 0x33,
+ [9] = 0x37,
+ [10] = 0x3b,
+ [11] = 0x3f,
+ [12] = 0x43,
+ [13] = 0x47,
+ [14] = 0x4b,
+ [15] = 0x55,
+ [16] = 0x63,
+ [17] = 0x71,
+ [18] = 0x74,
+ [19] = 0x77,
+ [20] = 0x7a,
+ [21] = 0x7f,
+ [22] = 0x82,
+ [23] = 0x85,
+ [24] = 0x88,
+ [25] = 0x8b,
+ [26] = 0x8e,
+ [27] = 0x91,
+ [28] = 0x94,
+};
+
static int __init twl4030_write_script_byte(u8 address, u8 byte)
{
int err;
@@ -245,10 +283,57 @@ static int __init load_triton_script(struct
twl4030_script *tscript)
return err;
}
+static void __init twl4030_configure_resource(struct twl4030_resconfig
*rconfig)
+{
+ int rconfig_addr;
+ u8 type;
+
+ if (rconfig-resource NUM_OF_RESOURCES) {
+ printk(KERN_ERR
+ TWL4030 Resource %d does not exist\n,
+ rconfig-resource);
+ return;
+ }
+
+ rconfig_addr = res_config_addrs[rconfig-resource];
+
+ /* Set resource group */
+
+ if (rconfig-devgroup = 0)
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ rconfig-devgroup 5,
+ rconfig_addr + DEVGROUP_OFFSET);
+
+ /* Set resource types */
+
+ if (twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER,
+ type,
+ rconfig_addr + TYPE_OFFSET) 0) {
+ printk(KERN_ERR
+ TWL4030 Resource %d type could not read\n,
+ rconfig-resource);
+ return;
+ }
+
+ if (rconfig-type = 0) {
+ type = ~7;
+ type |= rconfig-type;
+ }
+
+ if (rconfig-type2 = 0) {
+ type = ~(3 3);
+ type |= rconfig-type2 3;
+ }
+
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ type, rconfig_addr + TYPE_OFFSET);
+}
+
void __init twl4030_power_init(struct twl4030_power_data *triton2_scripts)
{
int err = 0;
int i;
+ struct twl4030_resconfig *resconfig;
err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_MASTER, KEY_1,
R_PROTECT_KEY);
@@ -258,12 +343,20 @@ void __init twl4030_power_init(struct
twl4030_power_data *triton2_scripts)
printk(KERN_ERR
TWL4030 Unable to unlock registers\n);
- for (i = 0; i triton2_scripts-size; i++) {
+ for (i = 0; i triton2_scripts-scripts_size; i++) {
err = load_triton_script(triton2_scripts-scripts[i]);
if (err)
break;
}
+ resconfig = triton2_scripts-resource_config;
+ if (resconfig) {
+ while (resconfig-resource) {
+ twl4030_configure_resource(resconfig);
+ resconfig++;
+ }
+ }
+
if (twl4030_i2c_write_u8(TWL4030_MODULE_PM_MASTER, 0, R_PROTECT_KEY))
printk(KERN_ERR
TWL4030 Unable to relock registers\n);
diff --git a/include/linux/i2c/twl4030.h b/include/linux/i2c/twl4030.h
index 93d483d..e6ce1cd 100644
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -243,6 +243,37 @@ int twl4030_i2c_read(u8 mod_no, u8 *value, u8 reg,
unsigned num_bytes);
#define RES_STATE_SLEEP0x8
#define RES_STATE_OFF 0x0
+/* Power resources */
+
Re: [patch 2.6.29-rc3-git 2/2] USB: disable twl4030 USB regulators when cable unplugged
On Sun, 2009-02-08 at 10:52 -0800, David Brownell wrote:
From: Kalle Jokiniemi kalle.jokini...@digia.com
This patch disables LDO regulators VUSB1V5, VUSB1V8, and VUSB3V1
when the USB cable is unplugged, to eliminate that source of power
waste. (Enabled LDOs consume power at all times.)
Please put this on hold for a while. This won't work if we don't have
TWL regulator support enabled. Also it's missing error value checking.
I'll post new patch(es) soon.
- Kalle
Signed-off-by: Kalle Jokiniemi kalle.jokini...@digia.com
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
Depends on the twl4030 regulator driver, so I'm suggesting this
be merged (with that driver) through the regulator patch queue
to simplify things.
drivers/usb/otg/twl4030-usb.c | 30 --
1 file changed, 24 insertions(+), 6 deletions(-)
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -34,6 +34,7 @@
#include linux/delay.h
#include linux/usb/otg.h
#include linux/i2c/twl4030.h
+#include linux/regulator/consumer.h
/* Register defines */
@@ -246,6 +247,11 @@ struct twl4030_usb {
struct otg_transceiver otg;
struct device *dev;
+ /* TWL4030 internal USB regulator supplies */
+ struct regulator*usb1v5;
+ struct regulator*usb1v8;
+ struct regulator*usb3v1;
+
/* for vbus reporting with irqs disabled */
spinlock_t lock;
@@ -434,6 +440,9 @@ static void twl4030_phy_power(struct twl
pwr = twl4030_usb_read(twl, PHY_PWR_CTRL);
if (on) {
+ regulator_enable(twl-usb1v5);
+ regulator_enable(twl-usb1v8);
+ regulator_enable(twl-usb3v1);
pwr = ~PHY_PWR_PHYPWD;
WARN_ON(twl4030_usb_write_verify(twl, PHY_PWR_CTRL, pwr) 0);
twl4030_usb_write(twl, PHY_CLK_CTRL,
@@ -443,6 +452,9 @@ static void twl4030_phy_power(struct twl
} else {
pwr |= PHY_PWR_PHYPWD;
WARN_ON(twl4030_usb_write_verify(twl, PHY_PWR_CTRL, pwr) 0);
+ regulator_disable(twl-usb1v5);
+ regulator_disable(twl-usb1v8);
+ regulator_disable(twl-usb3v1);
}
}
@@ -480,16 +492,19 @@ static void twl4030_usb_ldo_init(struct
/* input to VUSB3V1 LDO is from VBAT, not VBUS */
twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x14, VUSB_DEDICATED1);
- /* turn on 3.1V regulator */
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x20, VUSB3V1_DEV_GRP);
+ /* Initialize 3.1V regulator */
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB3V1_DEV_GRP);
+ twl-usb3v1 = regulator_get(twl-dev, usb3v1);
twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB3V1_TYPE);
- /* turn on 1.5V regulator */
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x20, VUSB1V5_DEV_GRP);
+ /* Initialize 1.5V regulator */
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB1V5_DEV_GRP);
+ twl-usb1v5 = regulator_get(twl-dev, usb1v5);
twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB1V5_TYPE);
- /* turn on 1.8V regulator */
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x20, VUSB1V8_DEV_GRP);
+ /* Initialize 1.8V regulator */
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB1V8_DEV_GRP);
+ twl-usb1v8 = regulator_get(twl-dev, usb1v8);
twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB1V8_TYPE);
/* disable access to power configuration registers */
@@ -688,6 +703,9 @@ static int __exit twl4030_usb_remove(str
twl4030_usb_clear_bits(twl, POWER_CTRL, POWER_CTRL_OTG_ENAB);
twl4030_phy_power(twl, 0);
+ regulator_put(twl-usb1v5);
+ regulator_put(twl-usb1v8);
+ regulator_put(twl-usb3v1);
kfree(twl);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: musb OTG broken in 2.6.29-rc3?
On Tue, Feb 10, 2009 at 12:46 AM, Jarkko Nikula jarkko.nik...@nokia.com wrote: On Tue, 10 Feb 2009 08:35:31 +0100 Balbi Felipe (Nokia-D/Helsinki) felipe.ba...@nokia.com wrote: Could you give me a little more detail on what you had to do for session start? Perhaps I have a similar issue on Overo. It is same $ echo F /proc/driver/musb_hdrc, which was earlier In musb_procfs.c and now been removed. + case 'F': + reg = musb_readb(mbase, MUSB_DEVCTL); + reg |= MUSB_DEVCTL_SESSION; + musb_writeb(mbase, MUSB_DEVCTL, reg); a temp sysfs for that will help: Steve, could you try the following I let Felipe to send new version of the patch where it applies (I had there spaces instead of tabs?) and condition for session value is not true for all values ;-) I had the same issue with spaces/tabs. Heading to the airport now, so won't be able to do further testing (beyond compile testing) till Friday. But for me Beagle work. Ethernet gadget just fine and HS HUB by kicking the session on. What method did you use to kick the session on? Was this always required? I might be misremembering, but I seem to recall that plugging in a miniA cable resulted in musb automatically switching modes to host. Sorry for the perhaps stupid questions, I am *far* from being a USB expert :-) Regards, Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: musb OTG broken in 2.6.29-rc3?
On Tue, 10 Feb 2009 15:27:18 +0100 ext Steve Sakoman sako...@gmail.com wrote: But for me Beagle work. Ethernet gadget just fine and HS HUB by kicking the session on. What method did you use to kick the session on? Was this always required? I might be misremembering, but I seem to recall that plugging in a miniA cable resulted in musb automatically switching modes to host. I used Felipe's patch and echo 1 /sys/...musb_something/session. That was required each time I reconnected the cable. Sorry for the perhaps stupid questions, I am *far* from being a USB expert :-) Me too :-) Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.29-rc3-git 2/2] USB: disable twl4030 USB regulators when cable unplugged
On Tue, Feb 10, 2009 at 03:08:14PM +0200, Kalle Jokiniemi wrote: A bug has been discovered here. If the twl-regulator is not compiled in, the twl4030-usb fails while trying to access the reg-fw interfaces (and reg-fw is the regulator framework? not checking error values). Also it's bit confusing how we get different error values if reg_fw is not compiled (no error) vs. reg_fw is compiled, but twl_regulator is not... (error) The general model is that if you've got regulator API support enabled then you'll have the relevant regulator drivers enabled. The support for compiling out the core is intended to allow configurations that don't use regulators at all. This is a bit restrictive but works well for most users. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/1] Board specific prm timings
This is an updated version which removes a useless printk. This patch allows for boardspecific prm timings such as voltage and clock setup delays. By default it will use the very conservative timings which were used previously. Peter 'p2' De Schrijver (1): per board prm timings arch/arm/mach-omap2/pm.h |9 + arch/arm/mach-omap2/pm34xx.c | 31 +-- 2 files changed, 34 insertions(+), 6 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP [TV] video
I'm trying to get TV [S-Video] working on my 3530 board. The settings in the current kernel don't seem to work very well on my TV (U.S. NTSC, standard). Comparing the video encoder setup with the suggested values in the manual, I find many differences, mostly with respect to the framing (signal shaping). Questions: * Are the settings in the kernel tree known to work [as is]? * Why the divergence from the recommended values? Any ideas or helpful pointers would be graciously accepted Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] per board prm timings
API definition to set prm setup times.
Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
---
arch/arm/mach-omap2/pm.h |9 +
arch/arm/mach-omap2/pm34xx.c | 31 +--
2 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 451f247..d79ea07 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -33,9 +33,18 @@ extern void *omap3_secure_ram_storage;
extern void omap2_block_sleep(void);
extern void omap2_allow_sleep(void);
#ifdef CONFIG_ARCH_OMAP3
+struct prm_setup_times {
+ u16 clksetup;
+ u16 voltsetup_time1;
+ u16 voltsetup_time2;
+ u16 voltoffset;
+ u16 voltsetup2;
+};
+
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);
+extern void omap3_set_prm_setup_times(struct prm_setup_times *setup_times);
#else
#define omap3_pm_off_mode_enable(int) do {} while (0);
#define omap3_pm_get_suspend_state(pwrdm) do {} while (0);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 44189a0..06aa382 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -85,6 +85,14 @@ static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
static struct powerdomain *core_pwrdm, *per_pwrdm;
static struct powerdomain *cam_pwrdm;
+static struct prm_setup_times prm_setup = {
+ .clksetup = 0xff,
+ .voltsetup_time1 = 0xfff,
+ .voltsetup_time2 = 0xfff,
+ .voltoffset = 0xff,
+ .voltsetup2 = 0xff,
+};
+
static inline void omap3_per_save_context(void)
{
omap3_gpio_save_context();
@@ -880,6 +888,15 @@ int omap3_pm_set_suspend_state(struct powerdomain *pwrdm,
int state)
return -EINVAL;
}
+void omap3_set_prm_setup_times(struct prm_setup_times *setup_times)
+{
+ prm_setup.clksetup = setup_times-clksetup;
+ prm_setup.voltsetup_time1 = setup_times-voltsetup_time1;
+ prm_setup.voltsetup_time2 = setup_times-voltsetup_time2;
+ prm_setup.voltoffset = setup_times-voltoffset;
+ prm_setup.voltsetup2 = setup_times-voltsetup2;
+}
+
static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
{
struct power_state *pwrst;
@@ -1015,6 +1032,7 @@ err2:
static void __init configure_vc(void)
{
+
prm_write_mod_reg((R_SRI2C_SLAVE_ADDR OMAP3430_SMPS_SA1_SHIFT) |
(R_SRI2C_SLAVE_ADDR OMAP3430_SMPS_SA0_SHIFT),
OMAP3430_GR_MOD, OMAP3_PRM_VC_SMPS_SA_OFFSET);
@@ -1044,21 +1062,22 @@ static void __init configure_vc(void)
OMAP3430_GR_MOD,
OMAP3_PRM_VC_I2C_CFG_OFFSET);
- /* Setup voltctrl and other setup times */
+ /* Setup value for voltctrl */
prm_write_mod_reg(OMAP3430_AUTO_RET,
OMAP3430_GR_MOD, OMAP3_PRM_VOLTCTRL_OFFSET);
- prm_write_mod_reg(OMAP3430_CLKSETUP_DURATION, OMAP3430_GR_MOD,
+ /* Write setup times */
+ prm_write_mod_reg(prm_setup.clksetup, OMAP3430_GR_MOD,
OMAP3_PRM_CLKSETUP_OFFSET);
- prm_write_mod_reg((OMAP3430_VOLTSETUP_TIME2
+ prm_write_mod_reg((prm_setup.voltsetup_time2
OMAP3430_SETUP_TIME2_SHIFT) |
- (OMAP3430_VOLTSETUP_TIME1
+ (prm_setup.voltsetup_time1
OMAP3430_SETUP_TIME1_SHIFT),
OMAP3430_GR_MOD, OMAP3_PRM_VOLTSETUP1_OFFSET);
- prm_write_mod_reg(OMAP3430_VOLTOFFSET_DURATION, OMAP3430_GR_MOD,
+ prm_write_mod_reg(prm_setup.voltoffset, OMAP3430_GR_MOD,
OMAP3_PRM_VOLTOFFSET_OFFSET);
- prm_write_mod_reg(OMAP3430_VOLTSETUP2_DURATION, OMAP3430_GR_MOD,
+ prm_write_mod_reg(prm_setup.voltsetup2, OMAP3430_GR_MOD,
OMAP3_PRM_VOLTSETUP2_OFFSET);
}
--
1.5.6.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Backlight driver for omap3evm
Thanks, Vaibhav Hiremath -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev Sent: Wednesday, January 07, 2009 8:52 PM To: Richard Purdie Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH] Backlight driver for omap3evm -Original Message- From: Richard Purdie [mailto:rpur...@rpsys.net] Sent: Wednesday, January 07, 2009 8:37 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] Backlight driver for omap3evm On Wed, 2009-01-07 at 20:25 +0530, Sanjeev Premi wrote: should be done in the platform code for the board, not in the general driver. If you do that, you should be able to reuse most of the generic-bl device code. I tried so, but wasn't able to get the Kconfig dependencies right to get 'generic-bl' into my build. Hence, removed the code that I believed to be generic (since yesterday's mail) and created the patch. Will give another try. [Hiremath, Vaibhav] Now I will be following up for OMAP3EVM backlight driver patch initiated/posted by Sanjeev. I was just referring to the backlight drives currently available under Linux tree, and observed that almost all drivers have been implemented in different way. I could not able to get one driver to which I can refer to for adding support for OMAP3EVM backlight driver. Can anybody tell me the expected way of implementation for backlight driver is? I have some questions here, - If I understand correctly (and as mentioned and pointed out by Richard in the mail-chain), platform_device should get added in platform file where it registers the pointer to the structure struct generic_bl_info. This I believe should be standard way everybody should follow, which is not the case. Am I missing something here? - The below question may sound foolish, but to is important for me to understand the framework. If I have simple and straight control of backlight, do I really required to have separate backlight driver for my platform? Can I make use of generic-bl driver? The only difference (atleast to my platform) would be the SYSFS entry, the entry will get created something like /sys/class/backlight/generic-bl/ Is it required to make driver, Power aware and differentiate from generic driver? Do we have any document on backlight driver framework? Regards, Richard -- To unsubscribe from this list: send the line unsubscribe linux- omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.29-rc3-git 2/2] USB: disable twl4030 USB regulators when cable unplugged
On Tuesday 10 February 2009, Kalle Jokiniemi wrote: This patch disables LDO regulators VUSB1V5, VUSB1V8, and VUSB3V1 when the USB cable is unplugged, to eliminate that source of power waste. (Enabled LDOs consume power at all times.) Please put this on hold for a while. This won't work if we don't have TWL regulator support enabled. So Kconfig should have TWL4030_USB depend on REGULATOR_TWL4030? Also it's missing error value checking. You mean like in the ldo_init() stuff? Fair enough. - Dave I'll post new patch(es) soon. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM branch updates: 3430sdp and omap3evm results
Kevin, I pulled git kernel today but still I am not seeing this patch in pm branch, looks like this patch is missing in the pm branch. Can you please recheck the same? thanks Ramesh Gupta G On 2/5/09, Ramesh Gupta Guntha grgupt...@gmail.com wrote: Kevin, I applied the patch maually at my end and tested, this works fine for me. anyway I will try with pm branch . thanks Ramesh Gupta G On 2/5/09, Kevin Hilman khil...@deeprootsystems.com wrote: Ramesh Gupta Guntha grgupt...@gmail.com writes: Hi Kevin, On 2/4/09, Kevin Hilman khil...@deeprootsystems.com wrote: Ramesh Gupta Guntha grgupt...@gmail.com writes: Kevin, On 2/4/09, Kevin Hilman khil...@deeprootsystems.com wrote: Ramesh Gupta Guntha grgupt...@gmail.com writes: Hi, I am able to resolve all other issues with this pm branch except one issue, I am not able to enable the iva2 clock once system is suspended and resumed, I am getting below messages. 3clock: dpll2_ck failed transition to 'locked' clock: dpll2_ck failed transition to 'locked' 3clock: dpll2_ck failed transition to 'locked' clock: dpll2_ck failed transition to 'locked' Once after booting ( without adding bridgedriver/ installing bridgedriver) CM_CLKEN_PLL_IVA2 value shows as 0x37 indicates IVA2 DPLL in locked mode. once after system suspend the value is not restored I am seeing that as 0x11 indicates IVA2 DPLL is low power stop mode. Can any one please provide your inputs on the above error? I tried reconfiguring the CM_CLKEN_PLL_IVA2 to lock mode but still I am seeing the same messages as above while enabling iva2 clock. Are you suspending into retention or off-mode? I am suspending into Off mode. Do you see this problem when only going into retention? If not, sounds like we're missing some registers being saved/restored across off-mode. I am seeing this issue only with OFF mode , retention works fine for me, yeah, looks like some registers are not restored properly across off mode. please let me know your inputs on this. I have just updated the PM branch with a fix from Jouni to save/restore CM_CLKSEL1_PLL_IVA2. Can you try the latest PM branch? Thanks, Kevin -- Thanks Ramesh Gupta G -- Thanks Ramesh Gupta G -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Remaining bits for basic support of LDP
* Russell King - ARM Linux li...@arm.linux.org.uk [090210 03:56]:
On Tue, Feb 10, 2009 at 11:48:55AM +, Russell King - ARM Linux wrote:
On Mon, Feb 02, 2009 at 10:29:09PM +, Russell King - ARM Linux wrote:
On Mon, Feb 02, 2009 at 01:45:30PM -0800, David Miller wrote:
From: Russell King - ARM Linux li...@arm.linux.org.uk
Date: Mon, 2 Feb 2009 21:39:53 +
The patch to fix these issues would seem to be relatively small (12
lines in the smc911x and one line change in board-ldp.c) - is it
something we want done for -rc4 or do we scrap the ethernet support
on the LDP until the SMSC driver has been merged ?
Obviously, having working ethernet would be helpful, and since it was
half heartedly merged when the initial OMAP3 stuff went upstream we
should do something with it one way or another.
Well, the SMSC driver is there already in the tree.
The only thing not currently being scheduled to hit
2.6.29-rcX are the recent changes to support platform
specified interrupt flags and all of that stuff.
If you want, we can look into pushing that work into
2.6.29-rcX
Hmm. Since we should assume that the other smc911x using platforms work
as-is, merging Steve's first four and the LDP patch seems to be a sane
idea. We can queue the remainder for when bugs are reported or the
next merge window, whichever comes earlier.
So, what's happening on this?
For the record, this is what the patch for fixing smc911x to work on
the LDP looks like. It's been tested on the LDP and works. It has
a minimal impact, so this is probably a better patch to merge for
2.6.29 rather than the smsc911x conversion patches which are more
invasive.
Yeah, the smsc updates for omap might take a while longer to get going.
So here's my ack for this smc911x patch:
Acked-by: Tony Lindgren t...@atomide.com
For the smsc changes, I don't have an LDP to test with. But I'll try
to get another board to work with smsc now that I have some MMC voltage
weirdness out of the way and have a proper root on MMC :) That is after
I have musb working on it so I can scp the module over g_ether..
Regards,
Tony
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 61f7c36..d544965 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -81,7 +87,7 @@ static inline void __init ldp_init_smc911x(void)
}
ldp_smc911x_resources[0].start = cs_mem_base + 0x0;
- ldp_smc911x_resources[0].end = cs_mem_base + 0xf;
+ ldp_smc911x_resources[0].end = cs_mem_base + 0xff;
udelay(100);
eth_gpio = LDP_SMC911X_GPIO;
diff --git a/drivers/net/smc911x.h b/drivers/net/smc911x.h
index 870b4c3..a45952e 100644
--- a/drivers/net/smc911x.h
+++ b/drivers/net/smc911x.h
@@ -42,6 +42,16 @@
#define SMC_USE_16BIT 0
#define SMC_USE_32BIT 1
#define SMC_IRQ_SENSE IRQF_TRIGGER_LOW
+#elif defined(CONFIG_ARCH_OMAP34XX)
+ #define SMC_USE_16BIT 0
+ #define SMC_USE_32BIT 1
+ #define SMC_IRQ_SENSE IRQF_TRIGGER_LOW
+ #define SMC_MEM_RESERVED 1
+#elif defined(CONFIG_ARCH_OMAP24XX)
+ #define SMC_USE_16BIT 0
+ #define SMC_USE_32BIT 1
+ #define SMC_IRQ_SENSE IRQF_TRIGGER_LOW
+ #define SMC_MEM_RESERVED 1
#else
/*
* Default configuration
@@ -675,6 +685,7 @@ smc_pxa_dma_outsl(struct smc911x_local *lp, u_long
physaddr,
#define CHIP_91160x0116
#define CHIP_91170x0117
#define CHIP_91180x0118
+#define CHIP_92110x9211
#define CHIP_92150x115A
#define CHIP_92170x117A
#define CHIP_92180x118A
@@ -689,6 +700,7 @@ static const struct chip_id chip_ids[] = {
{ CHIP_9116, LAN9116 },
{ CHIP_9117, LAN9117 },
{ CHIP_9118, LAN9118 },
+ { CHIP_9211, LAN9211 },
{ CHIP_9215, LAN9215 },
{ CHIP_9217, LAN9217 },
{ CHIP_9218, LAN9218 },
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Remaining bits for basic support of LDP
* Russell King - ARM Linux li...@arm.linux.org.uk [090210 13:37]: On Tue, Feb 10, 2009 at 01:02:02PM -0800, Tony Lindgren wrote: Yeah, the smsc updates for omap might take a while longer to get going. So here's my ack for this smc911x patch: Acked-by: Tony Lindgren t...@atomide.com Thanks. For the smsc changes, I don't have an LDP to test with. But I'll try to get another board to work with smsc now that I have some MMC voltage weirdness out of the way and have a proper root on MMC :) That is after I have musb working on it so I can scp the module over g_ether.. I've tested them both on the LDP, both work fine. That talk of MMC voltage weirdness sounds like bug fixes - do they need to get into mainline? Yes, I'll check few things first and then post a patch in a separate thread. Basically the issue is with a 3.0V internal MMC card connected to MMC2 where omap_hsmmc.c SVDS still needs to be set to use 1.8V. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP I2C: Include OMAP_I2C_SYSC_REG in save and restore.
Pakaravoor, Jagadeesh j-pakarav...@ti.com writes: Kevin, Did you get a chance to review this patch? Yes, and I applied it to the PM branch early last week. See the commit log[1]. I guess I forgot to respond to the list. Sorry... Kevin [1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=shortlog;h=pm -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM branch updates: 3430sdp and omap3evm results
Ramesh Gupta Guntha grgupt...@gmail.com writes: Kevin, I pulled git kernel today but still I am not seeing this patch in pm branch, looks like this patch is missing in the pm branch. Can you please recheck the same? Hi Ramesh, It looks like Tony's tree is not sync'ing with my PM branch anymore. I will check with Tony. In the mean-time, you could try to pull directly from my git repo[1] Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git On 2/5/09, Ramesh Gupta Guntha grgupt...@gmail.com wrote: Kevin, I applied the patch maually at my end and tested, this works fine for me. anyway I will try with pm branch . thanks Ramesh Gupta G On 2/5/09, Kevin Hilman khil...@deeprootsystems.com wrote: Ramesh Gupta Guntha grgupt...@gmail.com writes: Hi Kevin, On 2/4/09, Kevin Hilman khil...@deeprootsystems.com wrote: Ramesh Gupta Guntha grgupt...@gmail.com writes: Kevin, On 2/4/09, Kevin Hilman khil...@deeprootsystems.com wrote: Ramesh Gupta Guntha grgupt...@gmail.com writes: Hi, I am able to resolve all other issues with this pm branch except one issue, I am not able to enable the iva2 clock once system is suspended and resumed, I am getting below messages. 3clock: dpll2_ck failed transition to 'locked' clock: dpll2_ck failed transition to 'locked' 3clock: dpll2_ck failed transition to 'locked' clock: dpll2_ck failed transition to 'locked' Once after booting ( without adding bridgedriver/ installing bridgedriver) CM_CLKEN_PLL_IVA2 value shows as 0x37 indicates IVA2 DPLL in locked mode. once after system suspend the value is not restored I am seeing that as 0x11 indicates IVA2 DPLL is low power stop mode. Can any one please provide your inputs on the above error? I tried reconfiguring the CM_CLKEN_PLL_IVA2 to lock mode but still I am seeing the same messages as above while enabling iva2 clock. Are you suspending into retention or off-mode? I am suspending into Off mode. Do you see this problem when only going into retention? If not, sounds like we're missing some registers being saved/restored across off-mode. I am seeing this issue only with OFF mode , retention works fine for me, yeah, looks like some registers are not restored properly across off mode. please let me know your inputs on this. I have just updated the PM branch with a fix from Jouni to save/restore CM_CLKSEL1_PLL_IVA2. Can you try the latest PM branch? Thanks, Kevin -- Thanks Ramesh Gupta G -- Thanks Ramesh Gupta G -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.29-rc3-git 1/2] regulator: twl4030 regulators
On Mon, Feb 09, 2009 at 04:24:01PM -0800, David Brownell wrote: On Monday 09 February 2009, Mark Brown wrote: Maybe, but there is no such mechanism right yet. When it's created, then this could switch over. Since you appear to be writing the code already... :) Not for the regulator core, though. Switching from a simplistic constraint engine to one that starts to There's nothing specific to the driver in this code - it's just doing basic comparisons of two sets of constraints and acting on them and would work just as well if it were pushed into the core. You're going to need this in multiple drivers to use it in a system anyway (it'll need to be in at least the drivers which might be used on that system). handle a more realistic union of constraints model would be doable, but is a bit more off-topic work than I'd want to sign up for just now. Solving all possible problems is, obviously, a bigger task but I don't think we need to solve everything in order to avoid having this be driver specific. What I would suggest that you do for this is submit a patch allowing the regulators to supply a set of constraints when they register (but not doing anything with them), another with a TWL4030 driver using that API and a third patch making the core do something with that data. This would result in something which maintains consistent behaviour over all regulator drivers, which is my main concern here, and avoids tying up the TWL4030 driver merge with any debate about how to use information about the capabilities of the regulator. I have some regulator API patches I need to test (should be sometime this week) so I may be inspired to do at least the first patch myself. I don't think there's any doubt that the core can do something useful with the information. The model you're working with doesn't do a good job of component-izing things ... board may be board stack, where notions like the hardware are fluid. Most of the development work for the regulator API has been done on reference platforms with many pluggable boards (often including the PMIC board) so thought has been given as to how to handle these systems. For daughtercards other than the primary PMIC (which are vastly more common in production systems) one approach has been to represent the daughtercards as a device that gets whatever supplies the daughtercard has. The distribution of power within the daughtercard is then be done by adding child regulators. Your current patch does also set constraints for the voltages if they weren't there previously I was thinking that boards which don't need constraints shouldn't need to create any ... they could just pass on the capabilities of the underlying regulator. For safety the regulator API won't do anything without being explicitly told that it's OK to do so - if we were to do this we'd need to have an explicit flag in the constraints which says that this is what to do. Constraints are also permission grants. Only when that system is componentized that way. Not all are. Modular systems can have plug-in regulator boards; constraints on a mainboard would necessarily overlap with supported regulator boards ... but the regulators themselves would naturally have different constraints. Indeed. Like I say, a very large proportion of the development of the regulator API has been done on reference designs which are built in this fashion, including both pluggable PMIC boards and other daughtercards. Normally the primary PMIC cards are handled with conditional code in the machine file (either compile time or run time) or by registering drivers for all the PMICs and allowing failed device probes to sort everything out. So far handling things this way hasn't been a big deal - there are usually relatively few PMIC boards out there for a given platform and the PMIC itself is rarely a major restriction. This conditional code would normally do the setup that is specific to each PMIC board, including matching the regulators on the PMIC board with the rest of the system and any devices on the PMIC board itself that require supplies. A lot of the time there is a one to many mapping between regulators on the PMIC board and power domains in the base system and there are often additional devices on the PMIC board in addition to the base board. It's not unknown for the contraints applied to not be straight combinations of supply constraints (normally due to a lack of desire for runtime flexibility on supplies). At the end of the day board code is still always going to have to at some point know what regulators are fitted and how they are connected up. There are some things we could do to make handling runtime decisions on this easier, like allowing multiple sets of constraints and supplies to be supplied so the machine drivers can set up the various combinations of supplies more easily when that's possible (which is I think what you were getting at above), but they don't remove the
Re: [PATCH omap-fixes] OMAP2/3: GPIO: remove recursion in IRQ wakeup path
David Brownell davi...@pacbell.net writes: On Wednesday 28 January 2009, Kevin Hilman wrote: Now that the generic IRQ and GPIO frameworks are used for enabling and disabling GPIO IRQ wakeup sources, there is no longer a need to call [enable|disable]_irq_wake() in the low-level code. Doing so results in recursive calls to [enable|disable]_irq_wake(). Could you clarify what actually made that requirement go away? The recursion was introduced -- using the generic IRQ framework! -- as a simple way to ensure the parent IRQ was properly wake-enabled. Is the issue that something changed, so that something else wake-enables the parent? My description was not very descriptive... sorry... From what I can understand here, I don't see the point in wake-enabling the parent IRQ since there is no wakeup glue for the bank IRQs, thus these calls are actually failing and causing 'unbalanced IRQ disable' noise in the generic IRQ layer. Here is what is happening. Consider the gpio-keys driver. Upon suspend, it enables the IRQ wake for its GPIO. The OMAP GPIO code then calls enable_wake_irq() for the parent irq (the GPIO bank IRQ). This call is actually failing because the bank IRQ has no 'set_wake' method. Because of this failure, the generic IRQ code doesn't actually do anything, and sets the 'disable_depth' to zero for the bank IRQ. Then, upon resume, the resume path disables IRQ wakeups for the GPIO. The OMAP GPIO code then tries to call disable_irq_wake() for the bank IRQ and you get noisy 'unbalanced IRQ disable' warnings from the generic IRQ layere because of the attempt to disable the IRQ wake of an IRQ that was never enabled. So the options that I see are: 1) fix the OMAP GPIO code to check the return code of the parent enable, or 2) drop the parent enable/disable I prefer (1) since those calls will always fail AFAICT. Does that make any sense? If you're OK with (1), I will re-issue the patch with a better discription. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Remaining bits for basic support of LDP
From: Russell King - ARM Linux li...@arm.linux.org.uk Date: Tue, 10 Feb 2009 21:37:12 + On Tue, Feb 10, 2009 at 01:02:02PM -0800, Tony Lindgren wrote: Yeah, the smsc updates for omap might take a while longer to get going. So here's my ack for this smc911x patch: Acked-by: Tony Lindgren t...@atomide.com Thanks. Russell if you formally resubmit this with proper changelog, signoffs, and acks I can merge it in quickly via the net-2.6 if you like. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
Hello.
+static int omap34xxcam_open(struct inode *inode, struct file *file)
+{
snip
+ if (atomic_inc_return(vdev-users) == 1) {
+ isp_get();
+ if (omap34xxcam_slave_power_set(vdev, V4L2_POWER_ON,
+ OMAP34XXCAM_SLAVE_POWER_ALL))
+ goto out_slave_power_set_standby;
+ omap34xxcam_slave_power_set(
+ vdev, V4L2_POWER_STANDBY,
+ OMAP34XXCAM_SLAVE_POWER_SENSOR);
+ omap34xxcam_slave_power_suggest(
+ vdev, V4L2_POWER_STANDBY,
+ OMAP34XXCAM_SLAVE_POWER_LENS);
+ }
I'm wondering whether this V4L2_POWER_STANDBY operation for sensor
device is really necessary.
Because if that makes sensor device in standby mode, we do S_FMT and
bunch of V4L2 APIs while the camera module is in standby mode.
In most cases of sensor + ISP SOC camera modules, I2C command is not
working while the camera module is in standby mode.
Following the camera interface source code, sensor goes down to
standby mode until VIDIOC_STREAMON is called.
If this power up timing depends on sensor device, then I think we need
a conditional power on sequence.
As you defined slave devices as SENSOR, LENS, FLASH, then how about
making a new slave category like ISP for sensor+ISP SOC modules?
Then we could make slave devices with conditional cases.
Cheers.
Regards,
Nate
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP [TV] video
Thanks, Vaibhav Hiremath -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Gary Thomas Sent: Tuesday, February 10, 2009 9:35 PM To: Linux OMAP Subject: OMAP [TV] video I'm trying to get TV [S-Video] working on my 3530 board. The settings in the current kernel don't seem to work very well on my TV (U.S. NTSC, standard). Comparing the video encoder setup with the suggested values in the manual, I find many differences, mostly with respect to the framing (signal shaping). Questions: * Are the settings in the kernel tree known to work [as is]? * Why the divergence from the recommended values? Any ideas or helpful pointers would be graciously accepted [Hiremath, Vaibhav] Can you provide some more details like, Which kernel version are you using? Are you using DSS2 for TV out? Which board you are using, (must be EVM)? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux- omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.29-rc3-git 2/2] USB: disable twl4030 USB regulators when cable unplugged
On Tue, 2009-02-10 at 11:52 -0800, David Brownell wrote: On Tuesday 10 February 2009, Kalle Jokiniemi wrote: This patch disables LDO regulators VUSB1V5, VUSB1V8, and VUSB3V1 when the USB cable is unplugged, to eliminate that source of power waste. (Enabled LDOs consume power at all times.) Please put this on hold for a while. This won't work if we don't have TWL regulator support enabled. So Kconfig should have TWL4030_USB depend on REGULATOR_TWL4030? Yes. Also it's missing error value checking. You mean like in the ldo_init() stuff? Fair enough. I mean, if regulator_get fails. - Kalle - Dave I'll post new patch(es) soon. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] TWL: USB: disable VUSB regulators when cable unplugged
From: Jouni Hogander jouni.hogan...@nokia.com
This patch disables USB regulators VUSB1V5, VUSB1V8, and VUSB3V1
when the USB cable is unplugged to reduce power consumption.
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
Signed-off-by: Kalle Jokiniemi kalle.jokini...@digia.com
---
drivers/usb/otg/twl4030-usb.c | 45 +++-
1 files changed, 39 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 416e441..29df421 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -34,6 +34,8 @@
#include linux/delay.h
#include linux/usb/otg.h
#include linux/i2c/twl4030.h
+#include linux/regulator/consumer.h
+#include linux/err.h
/* Register defines */
@@ -246,6 +248,11 @@ struct twl4030_usb {
struct otg_transceiver otg;
struct device *dev;
+ /* TWL4030 internal USB regulator supplies */
+ struct regulator*usb1v5;
+ struct regulator*usb1v8;
+ struct regulator*usb3v1;
+
/* for vbus reporting with irqs disabled */
spinlock_t lock;
@@ -434,6 +441,12 @@ static void twl4030_phy_power(struct twl4030_usb *twl, int
on)
pwr = twl4030_usb_read(twl, PHY_PWR_CTRL);
if (on) {
+ if (twl-usb1v5)
+ regulator_enable(twl-usb1v5);
+ if (twl-usb1v8)
+ regulator_enable(twl-usb1v8);
+ if (twl-usb3v1)
+ regulator_enable(twl-usb3v1);
pwr = ~PHY_PWR_PHYPWD;
WARN_ON(twl4030_usb_write_verify(twl, PHY_PWR_CTRL, pwr) 0);
twl4030_usb_write(twl, PHY_CLK_CTRL,
@@ -443,6 +456,12 @@ static void twl4030_phy_power(struct twl4030_usb *twl, int
on)
} else {
pwr |= PHY_PWR_PHYPWD;
WARN_ON(twl4030_usb_write_verify(twl, PHY_PWR_CTRL, pwr) 0);
+ if (twl-usb1v5)
+ regulator_disable(twl-usb1v5);
+ if (twl-usb1v8)
+ regulator_disable(twl-usb1v8);
+ if (twl-usb3v1)
+ regulator_disable(twl-usb3v1);
}
}
@@ -470,6 +489,8 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
static void twl4030_usb_ldo_init(struct twl4030_usb *twl)
{
+ struct regulator*reg;
+
/* Enable writing to power configuration registers */
twl4030_i2c_write_u8(TWL4030_MODULE_PM_MASTER, 0xC0, PROTECT_KEY);
twl4030_i2c_write_u8(TWL4030_MODULE_PM_MASTER, 0x0C, PROTECT_KEY);
@@ -480,16 +501,25 @@ static void twl4030_usb_ldo_init(struct twl4030_usb *twl)
/* input to VUSB3V1 LDO is from VBAT, not VBUS */
twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x14, VUSB_DEDICATED1);
- /* turn on 3.1V regulator */
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x20, VUSB3V1_DEV_GRP);
+ /* Initialize 3.1V regulator */
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB3V1_DEV_GRP);
+ reg = regulator_get(twl-dev, usb3v1);
+ if (!IS_ERR(reg))
+ twl-usb3v1 = reg;
twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB3V1_TYPE);
- /* turn on 1.5V regulator */
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x20, VUSB1V5_DEV_GRP);
+ /* Initialize 1.5V regulator */
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB1V5_DEV_GRP);
+ reg = regulator_get(twl-dev, usb1v5);
+ if (!IS_ERR(reg))
+ twl-usb1v5 = reg;
twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB1V5_TYPE);
- /* turn on 1.8V regulator */
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x20, VUSB1V8_DEV_GRP);
+ /* Initialize 1.8V regulator */
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB1V8_DEV_GRP);
+ reg = regulator_get(twl-dev, usb1v8);
+ if (!IS_ERR(reg))
+ twl-usb1v8 = reg;
twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0, VUSB1V8_TYPE);
/* disable access to power configuration registers */
@@ -688,6 +718,9 @@ static int __exit twl4030_usb_remove(struct platform_device
*pdev)
twl4030_usb_clear_bits(twl, POWER_CTRL, POWER_CTRL_OTG_ENAB);
twl4030_phy_power(twl, 0);
+ regulator_put(twl-usb1v5);
+ regulator_put(twl-usb1v8);
+ regulator_put(twl-usb3v1);
kfree(twl);
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] USB: OTG: Twl4030 depends on REGULATOR_TWL4030
From: Jouni Hogander jouni.hogan...@nokia.com Twl4030 doesn't work without twl4030-regulator so it should depend on that. Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com Signed-off-by: Kalle Jokiniemi kalle.jokini...@digia.com --- drivers/usb/otg/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig index ee55b44..5790a5b 100644 --- a/drivers/usb/otg/Kconfig +++ b/drivers/usb/otg/Kconfig @@ -43,7 +43,7 @@ config ISP1301_OMAP config TWL4030_USB tristate TWL4030 USB Transceiver Driver - depends on TWL4030_CORE + depends on TWL4030_CORE REGULATOR_TWL4030 select USB_OTG_UTILS help Enable this to support the USB OTG transceiver on TWL4030 -- 1.5.4.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] TWL: USB: Start using twl4030/5030 regulator driver
These couple of patches enable dynamic swithcing of the regulators used by twl4030 usb tranceiver. This set replaces the single patch USB: disable twl4030 USB regulators when cable unplugged sent previously. The change to previous version is that possible errors in regulator_get are now handled and the twl4030 usb driver requires TWL_REGULATOR support to be compiled. Thanks to Aaro Koskinen for reporing these problems. Original patch by Kalle Jokiniemi, fixes by Jouni Hogander. Jouni Hogander (2): TWL: USB: disable VUSB regulators when cable unplugged USB: OTG: Twl4030 depends on REGULATOR_TWL4030 drivers/usb/otg/Kconfig |2 +- drivers/usb/otg/twl4030-usb.c | 45 +++- 2 files changed, 40 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] TWL: USB: Start using twl4030/5030 regulator driver
On Tuesday 10 February 2009, Kalle Jokiniemi wrote: These couple of patches enable dynamic swithcing of the regulators used by twl4030 usb tranceiver. This set replaces the single patch USB: disable twl4030 USB regulators when cable unplugged sent previously. The change to previous version is that possible errors in regulator_get are now handled and the twl4030 usb driver requires TWL_REGULATOR support to be compiled. It'd make more sense to me as a single patch ... :) And also, instead of *continuing* after the regulators can't be acquired, it's better to abort. It's not going to be able to do anything ... so don't finish probing, and don't register this dead transceiver. - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH E 10/14] OMAP clock: support dry run rate and parent changes
Hello Russell, On Sun, 8 Feb 2009, Russell King - ARM Linux wrote: On Wed, Jan 28, 2009 at 12:27:56PM -0700, Paul Walmsley wrote: For upcoming notifier support, modify the rate recalculation code to take parent rate and rate storage parameters. The goal here is to allow the clock code to determine what the clock's rate would be after a parent change or a rate change, without actually changing the hardware registers. This is used by the upcoming notifier patches to pass a clock's current and planned rates to the notifier callbacks. NAK. I'm not sure whether you've realised, but this is exactly what the 'round_rate' method is supposed to be doing. It provides a method by which you can find out what the clock rate would be if you asked for 'set_rate' to set the hardware to the requested rate. There's been some miscommunication about the purpose of this patch - most likely my fault for not grouping this patch with the clock notifier patch set, which has not yet been submitted for upstream merging. Most of this patch is not needed until notifiers are implemented, so I'd propose that we defer consideration of most of this patch until the clock notifiers are submitted. What would be useful, though, is to split out the RECALC_ON_ENABLE portion of this patch and merge that. That is a bug fix, and I should have sent that as a separate patch. For the sake of the current discussion though, here's what this patch was intended to accomplish. We have some patches under development that implement clock rate change notifiers, allowing drivers to register for pre- and post-notification on clock rate changes. The notifier callbacks are passed the old clock rate and the new clock rate. Since a rate change on a clock in the middle of the clock tree (e.g., dpll3_m2_ck) can affect all clocks downstream, the clock code must compute the new rate for not only dpll3_m2_ck, but also all downstream clocks, before clk-rate is updated and the hardware registers are actually changed. This presents a problem with the current code. Consider the pre-notification case, in which the clock code needs to compute the target clock rate without actually updating clk-rate. But the round_rate() functions assume that the parent clock's current rate is what should be used. If the parent clock's rate would also change as part of the clk_set_rate(), the target rate computation will return an incorrect rate. So this patch allows temporary rates to be computed for all of the clocks that would be affected by the rate or parent change, so the correct target rates can be passed to each clock's notifier (assuming one exists for the clock). N.B., this temporary rate computation is also the motivation behind the recursive propagate_rate() calls that we discussed earlier. It also may turn out that it's unnecessary to pass the new rate to the notifiers, in which case most of this code won't need to reappear. A far better way to approach this would be to split the set_rate/recalc functionality into two parts: 1. a method which returns the both the new clock rate and the hardware programming information 2. a method to commit the hardware programming information to the registers (1) can be used for implementing clk_round_rate() (which is totally lacking in OMAP2+, yet is implemented in OMAP1), clk_set_rate(), clk_set_parent() etc. The OMAP2/3 clock code does implement clk_round_rate() - most commonly via mach-omap2/clock.c:omap2_clksel_round_rate(). There are a few special cases which use other round_rate() functions. (2) can be used when it's required to actually reprogram the hardware. So, rather than the current situation where we have recalc, round_rate and set_rate methods, we have calc_rate() and commit() methods instead and have the core clock code sort out calling these. I haven't yet spent much time thinking about this new arrangement -- it seems to be orthogonal to the problem that this patch is intended to solve -- but it might make sense for a different purpose. Many of our set_rate() functions wind up calling round_rate() first to determine whether the passed-in rate is valid and to return the hardware programming data from the clksel structures. This extra call to round_rate() just wastes cycles. So this new layout might be more efficient, although it appears that calc_rate() is called twice in the new arrangement as well. I appreciate the ongoing technical review, - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
