Re: OMAP support in mainline?
On Wed, Sep 17, 2008 at 2:25 AM, Tony Lindgren [EMAIL PROTECTED] wrote: Hopefully we'll get all core 24xx and 34xx files integrated soon. But then there are tons of board-*.c files missing from mainline that probably need to be cleaned up a bit. What about sending the board to standby via /sys/power/state and waking it up via pressing one of the keypad buttons ? Is it already supported in mainline ? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] alsa: add Beagleboard SoC configuration.
On Tue, 16 Sep 2008 23:51:35 +0300 ext Felipe Contreras [EMAIL PROTECTED] wrote: This is exactly the same as the overo configuration. It might make sense to have them in a single one. Signed-off-by: Felipe Contreras [EMAIL PROTECTED] --- This was suggested by Koen Kooi. sound/soc/omap/Kconfig |8 ++ sound/soc/omap/Makefile |2 + sound/soc/omap/omap3beagle.c | 149 + + 3 files changed, 159 insertions(+), 0 deletions(-) create mode 100644 sound/soc/omap/omap3beagle.c Actually I've been using patched Overo driver in my Beagle for couple days now :-) However I propose to keep Beagle and Overo separated as this patch does. I think Overo can have more versatile audio connections than Beagle and thus likely to be extended over time where as Beagle audio HW is fixed as it's now. Steve, any comments? Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP support in mainline?
Op 17 sep 2008, om 07:55 heeft David Brownell het volgende geschreven: On Tuesday 16 September 2008, Jarkko Nikula wrote: I think one good measure for this whole work when one can can run Beagle or Overo with mainline kernel. Yes ... ideally for 2.6.28 for both. The Overo boards handed out at the kernel summit are a bit visible right now as not yet booting with mainline code. :) And they aren't working too well with current l-o git either with MUSB being broken. There's a patch to fix client mode, but host mode still isn't working. regards, Koen That would require some spring-cleaning effort and getting core, TWL4030, etc. patches out but then it is much more easier to send remaining board files and other drivers to their relevant lists. My quick audit: - core updates - board files - twl4030 ... converted to new-style, gpiolib, drivers/mfd - hsmmc - omap2 nand - various pending musb updates FB support would be nice too, but IMO not if that means rushing the updates discussed lately. Not all the TWL components would need to go upstream at once. - Dave -- To unsubscribe from this list: send the line unsubscribe linux- omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html PGP.sig Description: This is a digitally signed message part
Re: [PREVIEW] New display subsystem for OMAP2/3
On Mon, 2008-09-15 at 20:27 +0100, ext Måns Rullgård wrote: Tomi Valkeinen [EMAIL PROTECTED] writes: On Sat, 2008-09-13 at 22:47 +0100, ext Måns Rullgård wrote: Koen Kooi [EMAIL PROTECTED] writes: What I don't like about the patch posted is its size. I'm sure the transition could be done in a sequence of smaller patches. At the very least, it should be possible to move existing functionality to the new architecture, then add the new parts afterwards. I also see little value in keeping the old model around, as is done in the patch. I don't like the size either. However, I have no idea how the old driver could be transformed to include this functionality with a reasonable effort. The implementations are quite different. Any suggestions how I could approach this task? Only thing that comes to my mind is that there are very similar low level functions in both DSS1 and DSS2 (for dispc and rfbi), that I could remove from the old place and move to arch/arm/plat-omap/dss/, but that doesn't take us very far. Are the patches you posted your latest version of the code? Do you have this code in a public git repo? I'd like to take a closer look at what you've done. They are not the very latest, but they are recent enough. Unfortunately I don't have them on a public git. Nokia is still a bit lacking in that area =). They should apply to linux-omap kernel from last Thursday (I think the commit id is mentioned in the series file). Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: Clean-up MMC device init (Was: [PATCH]Enable 4-bit in HSMMC1 and HSMMC2 platform data)
On Tue, Sep 16, 2008 at 04:13:57PM -0700, Tony Lindgren wrote: OK Here's the patch updated. If necessary, the patch could be broken into several parts. I've already got a patch doing what I've outlined (and some other stuff) I just haven't had time to finish it off to email out yet. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] OMAP2/3 clock: encode prcm_mod for each struct clk
On Tue, 16 Sep 2008, Tony Lindgren wrote: Looks like patch 3/3 is missing? vger ate it. Will split it up, - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PREVIEW] New display subsystem for OMAP2/3
Tomi Valkeinen [EMAIL PROTECTED] writes: On Mon, 2008-09-15 at 20:27 +0100, ext Måns Rullgård wrote: Tomi Valkeinen [EMAIL PROTECTED] writes: On Sat, 2008-09-13 at 22:47 +0100, ext Måns Rullgård wrote: Koen Kooi [EMAIL PROTECTED] writes: What I don't like about the patch posted is its size. I'm sure the transition could be done in a sequence of smaller patches. At the very least, it should be possible to move existing functionality to the new architecture, then add the new parts afterwards. I also see little value in keeping the old model around, as is done in the patch. I don't like the size either. However, I have no idea how the old driver could be transformed to include this functionality with a reasonable effort. The implementations are quite different. Any suggestions how I could approach this task? Only thing that comes to my mind is that there are very similar low level functions in both DSS1 and DSS2 (for dispc and rfbi), that I could remove from the old place and move to arch/arm/plat-omap/dss/, but that doesn't take us very far. Are the patches you posted your latest version of the code? Do you have this code in a public git repo? I'd like to take a closer look at what you've done. They are not the very latest, but they are recent enough. Unfortunately I don't have them on a public git. Nokia is still a bit lacking in that area =). They should apply to linux-omap kernel from last Thursday (I think the commit id is mentioned in the series file). I don't like working on old code. It inevitably leads to wasting time re-doing things that have already been done in the latest version. -- Måns Rullgård [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH PM-0] OMAP3: I2C: Implement i2c save/restore
Save and restore needed registers instead of re-init.
Signed-off-by: Jouni Hogander [EMAIL PROTECTED]
---
drivers/i2c/busses/i2c-omap.c | 47 +++--
1 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a661ed3..211d7b5 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -147,6 +147,10 @@ struct omap_i2c_dev {
unsignedb_hw:1; /* bad h/w fixes */
unsignedidle:1;
u16 iestate;/* Saved interrupt register */
+ u16 pscstate;
+ u16 scllstate;
+ u16 sclhstate;
+ u16 bufstate;
};
static inline void omap_i2c_write_reg(struct omap_i2c_dev *i2c_dev,
@@ -209,16 +213,22 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
if (dev-iclk != NULL)
clk_enable(dev-iclk);
clk_enable(dev-fclk);
+
+ if (cpu_is_omap34xx()) {
+ omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
+ 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);
+ }
+
dev-idle = 0;
- if (dev-iestate)
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
+ omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
}
static void omap_i2c_idle(struct omap_i2c_dev *dev)
{
u16 iv;
- dev-iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
if (dev-rev1)
iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG);
@@ -238,7 +248,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
- u16 psc = 0, scll = 0, sclh = 0;
+ u16 psc = 0, scll = 0, sclh = 0, buf = 0;
u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
unsigned long fclk_rate = 1200;
unsigned long timeout;
@@ -327,23 +337,30 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
- if (dev-fifo_size)
- /* Note: setup required fifo size - 1 */
- omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG,
- (dev-fifo_size - 1) 8 | /* RTRSH */
- OMAP_I2C_BUF_RXFIF_CLR |
- (dev-fifo_size - 1) | /* XTRSH */
- OMAP_I2C_BUF_TXFIF_CLR);
+ if (dev-fifo_size) {
+ /* Note: setup required fifo size - 1. RTRSH and XTRSH */
+ buf = (dev-fifo_size - 1) 8 | OMAP_I2C_BUF_RXFIF_CLR |
+ (dev-fifo_size - 1) | OMAP_I2C_BUF_TXFIF_CLR;
+ omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, buf);
+ }
/* Take the I2C module out of reset: */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
/* Enable interrupts */
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG,
- (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
+ dev-iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
OMAP_I2C_IE_AL) | ((dev-fifo_size) ?
- (OMAP_I2C_IE_RDR | OMAP_I2C_IE_XDR) : 0));
+ (OMAP_I2C_IE_RDR | OMAP_I2C_IE_XDR) : 0);
+ omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
+
+ if (cpu_is_omap34xx()) {
+ dev-pscstate = psc;
+ dev-scllstate = scll;
+ dev-sclhstate = sclh;
+ dev-bufstate = buf;
+ }
+
return 0;
}
@@ -503,8 +520,6 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
omap_i2c_unidle(dev);
- omap_i2c_init(dev);
-
if ((r = omap_i2c_wait_for_bb(dev)) 0)
goto out;
--
1.5.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH PM-0] OMAP3: I2C: Implement i2c save/restore
Jouni Hogander [EMAIL PROTECTED] writes:
Save and restore needed registers instead of re-init.
Signed-off-by: Jouni Hogander [EMAIL PROTECTED]
Ack. Pushing to pm-0 today.
Kevin
---
drivers/i2c/busses/i2c-omap.c | 47
+++--
1 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a661ed3..211d7b5 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -147,6 +147,10 @@ struct omap_i2c_dev {
unsignedb_hw:1; /* bad h/w fixes */
unsignedidle:1;
u16 iestate;/* Saved interrupt register */
+ u16 pscstate;
+ u16 scllstate;
+ u16 sclhstate;
+ u16 bufstate;
};
static inline void omap_i2c_write_reg(struct omap_i2c_dev *i2c_dev,
@@ -209,16 +213,22 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
if (dev-iclk != NULL)
clk_enable(dev-iclk);
clk_enable(dev-fclk);
+
+ if (cpu_is_omap34xx()) {
+ omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
+ 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);
+ }
+
dev-idle = 0;
- if (dev-iestate)
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
+ omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
}
static void omap_i2c_idle(struct omap_i2c_dev *dev)
{
u16 iv;
- dev-iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
if (dev-rev1)
iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG);
@@ -238,7 +248,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
- u16 psc = 0, scll = 0, sclh = 0;
+ u16 psc = 0, scll = 0, sclh = 0, buf = 0;
u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
unsigned long fclk_rate = 1200;
unsigned long timeout;
@@ -327,23 +337,30 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
- if (dev-fifo_size)
- /* Note: setup required fifo size - 1 */
- omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG,
- (dev-fifo_size - 1) 8 | /* RTRSH */
- OMAP_I2C_BUF_RXFIF_CLR |
- (dev-fifo_size - 1) | /* XTRSH */
- OMAP_I2C_BUF_TXFIF_CLR);
+ if (dev-fifo_size) {
+ /* Note: setup required fifo size - 1. RTRSH and XTRSH */
+ buf = (dev-fifo_size - 1) 8 | OMAP_I2C_BUF_RXFIF_CLR |
+ (dev-fifo_size - 1) | OMAP_I2C_BUF_TXFIF_CLR;
+ omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, buf);
+ }
/* Take the I2C module out of reset: */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
/* Enable interrupts */
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG,
- (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
+ dev-iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
OMAP_I2C_IE_AL) | ((dev-fifo_size) ?
- (OMAP_I2C_IE_RDR | OMAP_I2C_IE_XDR) : 0));
+ (OMAP_I2C_IE_RDR | OMAP_I2C_IE_XDR) : 0);
+ omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
+
+ if (cpu_is_omap34xx()) {
+ dev-pscstate = psc;
+ dev-scllstate = scll;
+ dev-sclhstate = sclh;
+ dev-bufstate = buf;
+ }
+
return 0;
}
@@ -503,8 +520,6 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
omap_i2c_unidle(dev);
- omap_i2c_init(dev);
-
if ((r = omap_i2c_wait_for_bb(dev)) 0)
goto out;
--
1.5.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH PM-0] OMAP3: I2C: Implement i2c save/restore
On Wed, Sep 17, 2008 at 02:18:57PM +0300, ext Kevin Hilman wrote: Jouni Hogander [EMAIL PROTECTED] writes: Save and restore needed registers instead of re-init. Signed-off-by: Jouni Hogander [EMAIL PROTECTED] Ack. Pushing to pm-0 today. About that, pm-0 only appears in source.mvista.com. Anyway of pushing it to kernel.org as well ?? -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP support in mainline?
Op 17 sep 2008, om 14:24 heeft Steve Sakoman het volgende geschreven: On Wed, Sep 17, 2008 at 12:16 AM, Koen Kooi [EMAIL PROTECTED] wrote: And they aren't working too well with current l-o git either with MUSB being broken. There's a patch to fix client mode, but host mode still isn't working. Host mode musb is working just fine on Overo with the set transceiver patch. Not sure why you are having trouble with Beagle (and can't check since I don't have my Beagle board with me at the moment) I should clarify: OTG mode with a host cable doesn't work in .27rc, it does work in 2.6.26. I haven't tried specifying pure hostmode, only OTG. I would try it on the evm as well, but that is having serious irq issues with .27rc, pressing a key on the keypad triggers an irq overrun, ethernet gives an oops on boot when trying to register and irq etc,etc. 2.6.27 is looking really, really bad on omap3 at the moment. regards, Koen Steve -- To unsubscribe from this list: send the line unsubscribe linux- omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html PGP.sig Description: This is a digitally signed message part
[PATCH] Debobs and ETK padconf implementation
Signed-off-by: Peter 'p2' De Schrijver [EMAIL PROTECTED]
---
arch/arm/mach-omap2/debobs.c | 214 ++
1 files changed, 214 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/debobs.c
diff --git a/arch/arm/mach-omap2/debobs.c b/arch/arm/mach-omap2/debobs.c
new file mode 100644
index 000..1bde1f4
--- /dev/null
+++ b/arch/arm/mach-omap2/debobs.c
@@ -0,0 +1,214 @@
+/*
+ * arch/arm/mach-omap2/debobs.c
+ *
+ * Handle debobs pads
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ *
+ * Written by Peter De Schrijver [EMAIL PROTECTED]
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/debugfs.h
+#include linux/uaccess.h
+#include linux/module.h
+#include mach/control.h
+#include mach/mux.h
+#include mach/gpio.h
+#include mach/board.h
+
+#define ETK_GPIO_BEGIN 12
+#define ETK_GPIO(i)(ETK_GPIO_BEGIN + i)
+#define NUM_OF_DEBOBS_PADS 18
+
+enum debobs_pad_mode {
+ GPIO = 0,
+ OBS = 1,
+ ETK = 2,
+ NO_MODE = 3,
+};
+
+static char *debobs_pad_mode_names[] = {
+ [GPIO] = GPIO,
+ [OBS] = OBS,
+ [ETK] = ETK,
+};
+
+struct obs {
+ u16 offset;
+ u8 value;
+ u8 mask;
+};
+
+struct debobs_pad {
+ enum debobs_pad_mode mode;
+ struct obs core_obs;
+ struct obs wakeup_obs;
+};
+
+static struct debobs_pad debobs_pads[NUM_OF_DEBOBS_PADS];
+
+static int debobs_mode_open(struct inode *inode, struct file *file)
+{
+ file-private_data = inode-i_private;
+
+ return 0;
+}
+
+static ssize_t debobs_mode_read(struct file *file, char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ char buffer[10];
+ int size;
+ int pad_number = (int)file-private_data;
+ struct debobs_pad *e = debobs_pads[pad_number];
+
+ size = snprintf(buffer, sizeof(buffer), %s\n,
+ debobs_pad_mode_names[e-mode]);
+ return simple_read_from_buffer(user_buf, count, ppos, buffer, size);
+}
+
+static ssize_t debobs_mode_write(struct file *file, const char __user
*user_buf,
+ size_t count, loff_t *ppos)
+{
+ char buffer[10];
+ int buf_size, i, pad_number;
+ u16 muxmode = OMAP34XX_MUX_MODE7;
+
+ memset(buffer, 0, sizeof(buffer));
+ buf_size = min(count, (sizeof(buffer)-1));
+
+ if (copy_from_user(buffer, user_buf, buf_size))
+ return -EFAULT;
+
+ pad_number = (int)file-private_data;
+
+ for (i = 0; i NO_MODE; i++) {
+ if (!strnicmp(debobs_pad_mode_names[i],
+ buffer,
+ strlen(debobs_pad_mode_names[i]))) {
+ switch (i) {
+ case ETK:
+ muxmode = OMAP34XX_MUX_MODE0;
+ break;
+ case GPIO:
+ muxmode = OMAP34XX_MUX_MODE4;
+ break;
+ case OBS:
+ muxmode = OMAP34XX_MUX_MODE7;
+ break;
+ }
+ omap_ctrl_writew(muxmode,
+ OMAP343X_PADCONF_ETK(pad_number));
+ debobs_pads[pad_number].mode = i;
+
+ return count;
+ }
+ }
+
+ return -EINVAL;
+}
+
+static const struct file_operations debobs_mode_fops = {
+ .open = debobs_mode_open,
+ .read = debobs_mode_read,
+ .write = debobs_mode_write,
+};
+
+static int debobs_get(void *data, u64 *val)
+{
+ struct obs *o = data;
+
+ *val = o-value;
+
+ return 0;
+}
+
+static int debobs_set(void *data, u64 val)
+{
+ struct obs *o = data;
+
+ val = BIT(o-mask) - 1;
+
+ omap_ctrl_writeb(val, o-offset);
+ o-value = val;
+
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(debobs_fops, debobs_get, debobs_set, %llu\n);
+
+static inline int __init _new_debobs_pad(struct debobs_pad *pad, char *name,
+ int number, struct dentry *root)
+{
+ struct dentry *d;
+ struct obs *o;
+
+ d = debugfs_create_dir(name, root);
+ if (IS_ERR(d))
+ return
[PATCH] Add definitions for ETK pads and debobs registers
Signed-off-by: Peter 'p2' De Schrijver [EMAIL PROTECTED] --- arch/arm/plat-omap/include/mach/control.h | 34 + 1 files changed, 34 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/control.h b/arch/arm/plat-omap/include/mach/control.h index ef8cf12..19addae 100644 --- a/arch/arm/plat-omap/include/mach/control.h +++ b/arch/arm/plat-omap/include/mach/control.h @@ -149,6 +149,8 @@ #define OMAP343X_CONTROL_FUSE_SR (OMAP2_CONTROL_GENERAL + 0x0130) #define OMAP343X_CONTROL_IVA2_BOOTADDR (OMAP2_CONTROL_GENERAL + 0x0190) #define OMAP343X_CONTROL_IVA2_BOOTMOD (OMAP2_CONTROL_GENERAL + 0x0194) +#define OMAP343X_CONTROL_DEBOBS(i) (OMAP2_CONTROL_GENERAL + 0x01B0 \ + + ((i) 1) * 4 + (!(i) 1) * 2) #define OMAP343X_CONTROL_DEBOBS_0 (OMAP2_CONTROL_GENERAL + 0x01B0) #define OMAP343X_CONTROL_DEBOBS_1 (OMAP2_CONTROL_GENERAL + 0x01B4) #define OMAP343X_CONTROL_DEBOBS_2 (OMAP2_CONTROL_GENERAL + 0x01B8) @@ -170,6 +172,38 @@ #define OMAP343X_CONTROL_SRAMLDO5 (OMAP2_CONTROL_GENERAL + 0x02C0) #define OMAP343X_CONTROL_CSI (OMAP2_CONTROL_GENERAL + 0x02b4) +/* 34xx PADCONF register offsets */ + +#define OMAP343X_PADCONF_ETK(i)(OMAP2_CONTROL_PADCONFS + 0x5a8 + \ + (i)*2) +#define OMAP343X_PADCONF_ETK_CLK OMAP343X_PADCONF_ETK(0) +#define OMAP343X_PADCONF_ETK_CTL OMAP343X_PADCONF_ETK(1) +#define OMAP343X_PADCONF_ETK_D0OMAP343X_PADCONF_ETK(2) +#define OMAP343X_PADCONF_ETK_D1OMAP343X_PADCONF_ETK(3) +#define OMAP343X_PADCONF_ETK_D2OMAP343X_PADCONF_ETK(4) +#define OMAP343X_PADCONF_ETK_D3OMAP343X_PADCONF_ETK(5) +#define OMAP343X_PADCONF_ETK_D4OMAP343X_PADCONF_ETK(6) +#define OMAP343X_PADCONF_ETK_D5OMAP343X_PADCONF_ETK(7) +#define OMAP343X_PADCONF_ETK_D6OMAP343X_PADCONF_ETK(8) +#define OMAP343X_PADCONF_ETK_D7OMAP343X_PADCONF_ETK(9) +#define OMAP343X_PADCONF_ETK_D8OMAP343X_PADCONF_ETK(10) +#define OMAP343X_PADCONF_ETK_D9OMAP343X_PADCONF_ETK(11) +#define OMAP343X_PADCONF_ETK_D10 OMAP343X_PADCONF_ETK(12) +#define OMAP343X_PADCONF_ETK_D11 OMAP343X_PADCONF_ETK(13) +#define OMAP343X_PADCONF_ETK_D12 OMAP343X_PADCONF_ETK(14) +#define OMAP343X_PADCONF_ETK_D13 OMAP343X_PADCONF_ETK(15) +#define OMAP343X_PADCONF_ETK_D14 OMAP343X_PADCONF_ETK(16) +#define OMAP343X_PADCONF_ETK_D15 OMAP343X_PADCONF_ETK(17) + +/* 34xx GENERAL_WKUP regist offsets */ + +#define OMAP343X_CONTROL_WKUP_DEBOBSMUX(i) (OMAP343X_CONTROL_GENERAL_WKUP + \ + 0x008 + (i)) +#define OMAP343X_CONTROL_WKUP_DEBOBS0 (OMAP343X_CONTROL_GENERAL_WKUP + 0x008) +#define OMAP343X_CONTROL_WKUP_DEBOBS1 (OMAP343X_CONTROL_GENERAL_WKUP + 0x00C) +#define OMAP343X_CONTROL_WKUP_DEBOBS2 (OMAP343X_CONTROL_GENERAL_WKUP + 0x010) +#define OMAP343X_CONTROL_WKUP_DEBOBS3 (OMAP343X_CONTROL_GENERAL_WKUP + 0x014) +#define OMAP343X_CONTROL_WKUP_DEBOBS4 (OMAP343X_CONTROL_GENERAL_WKUP + 0x018) /* * REVISIT: This list of registers is not comprehensive - there are more -- 1.5.6.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add debobs Kconfig item
Signed-off-by: Peter 'p2' De Schrijver [EMAIL PROTECTED] --- arch/arm/mach-omap2/Kconfig | 10 +- arch/arm/mach-omap2/Makefile |3 +++ 2 files changed, 12 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index d0bbbf8..639af08 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -151,4 +151,12 @@ config OMAP3_OFF_MODE depends on ARCH_OMAP3 default n help - Use off mode for powerdomains. \ No newline at end of file + Use off mode for powerdomains. + +config OMAP3_DEBOBS + bool OMAP 3430 Debug observability support + depends on ARCH_OMAP3 DEBUG_FS + default n + help + Use ETK pads for debug observability + diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 23fc127..88d3af0 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -40,6 +40,9 @@ obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox_mach.o mailbox_mach-objs := mailbox.o mmu_mach-objs := mmu.o +# Debobs +obj-$(CONFIG_OMAP3_DEBOBS) += debobs.o + # Specific board support obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o board-h4-mmc.o -- 1.5.6.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] debobs support for OMAP3430.
This patch adds support for debug observability on OMAP3430 using the ETK lines. Fixes some potential issues with the OMAP343X_CONTROL_DEBOBS, OMAP343X_PADCONF_ETK and OMAP343X_CONTROL_WKUP_DEBOBSMUX macros. Peter 'p2' De Schrijver (3): Add definitions for ETK pads and debobs registers Debobs and ETK padconf implementation Add debobs Kconfig item arch/arm/mach-omap2/Kconfig | 10 ++- arch/arm/mach-omap2/Makefile |3 + arch/arm/mach-omap2/debobs.c | 214 + arch/arm/plat-omap/include/mach/control.h | 34 + 4 files changed, 260 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/debobs.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP 2/3 V4L2 display driver on video planes
Hi, Hardik! ext Hardik Shah wrote: diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 2703c66..e899dd2 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -762,8 +762,6 @@ source drivers/media/video/au0828/Kconfig source drivers/media/video/ivtv/Kconfig -source drivers/media/video/omap/Kconfig - source drivers/media/video/cx18/Kconfig config VIDEO_M32R_AR @@ -802,6 +800,14 @@ config VIDEO_OMAP2 ---help--- Driver for an OMAP 2 camera controller. +config VIDEO_OMAP3 This is the same configuration option as we are using for the OMAP 3 camera driver at the moment. Could you, for example, call this VIDEO_OMAP3_VIDEOOUT? CONFIG_VIDEO_OMAP2 enables the OMAP 2 camera driver. diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 3e580e8..10f879c 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -107,6 +107,8 @@ obj-$(CONFIG_VIDEO_CAFE_CCIC) += cafe_ccic.o obj-$(CONFIG_VIDEO_OV7670) += ov7670.o obj-$(CONFIG_VIDEO_OMAP2) += omap24xxcam.o omap24xxcam-dma.o +obj-$(CONFIG_VIDEO_OMAP3) += omap/ It's just two C source code files --- how about putting them into the parent directory? The omap directory has just one driver in it, the OMAP 1 camera driver. I think at some point it was intended to be moved to the parent directory although this hasn't happened. Best regards, -- Sakari Ailus [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP 2/3 V4L2 display driver on video planes
Hi Ailus, Thanks, Vaibhav Hiremath Senior Software Engg. Platform Support Products Texas Instruments Inc Ph: +91-80-25099927 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sakari Ailus Sent: Wednesday, September 17, 2008 9:00 PM To: Shah, Hardik Cc: [EMAIL PROTECTED]; linux-omap@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: [PATCH] OMAP 2/3 V4L2 display driver on video planes Hi, Hardik! ext Hardik Shah wrote: diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 2703c66..e899dd2 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -762,8 +762,6 @@ source drivers/media/video/au0828/Kconfig source drivers/media/video/ivtv/Kconfig -source drivers/media/video/omap/Kconfig - source drivers/media/video/cx18/Kconfig config VIDEO_M32R_AR @@ -802,6 +800,14 @@ config VIDEO_OMAP2 ---help--- Driver for an OMAP 2 camera controller. +config VIDEO_OMAP3 This is the same configuration option as we are using for the OMAP 3 camera driver at the moment. Could you, for example, call this VIDEO_OMAP3_VIDEOOUT? CONFIG_VIDEO_OMAP2 enables the OMAP 2 camera driver. I am aware of camera config options, but since now V4l started supporting output devices (like display) widely, we should have some meaningful config options here. I propose something following - config VIDEO_OMAP3 bool OMAP2/OMAP3 V4L2 drivers depends on VIDEO_DEV (ARCH_OMAP24XX || ARCH_OMAP34XX) default y help V4L2 DSS driver support for OMAP2/3 based boards. source drivers/media/video/omap/Kconfig config VIDEO_OMAP3_CAMERA tristate OMAP 3 Camera support select VIDEOBUF_GEN select VIDEOBUF_DMA_SG select VIDEO_OMAP3_ISP depends on VIDEO_V4L2 ARCH_OMAP34XX VIDEO_OMAP3 default VIDEO_OMAP3 ---help--- Driver for an OMAP 3 camera controller. source drivers/media/video/isp/Kconfig diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 3e580e8..10f879c 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -107,6 +107,8 @@ obj-$(CONFIG_VIDEO_CAFE_CCIC) += cafe_ccic.o obj-$(CONFIG_VIDEO_OV7670) += ov7670.o obj-$(CONFIG_VIDEO_OMAP2) += omap24xxcam.o omap24xxcam-dma.o +obj-$(CONFIG_VIDEO_OMAP3) += omap/ It's just two C source code files --- how about putting them into the parent directory? The omap directory has just one driver in it, the OMAP 1 camera driver. I think at some point it was intended to be moved to the parent directory although this hasn't happened. But with addition of V4L2 display patch the number of files got increased, now we have 4 files for display driver. I would prefer other way, move OMAP specific files to omap directory. Best regards, -- Sakari Ailus [EMAIL PROTECTED] -- video4linux-list mailing list Unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/video4linux-list -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Re: omap-sdp3430_Rotation patch
From: Rajesh K [EMAIL PROTECTED]
OMAP FBDEV: VRFB framebuffer rotation support
This patch provides rotation support for OMAP2/3. You will have to append
video=omapfb:rotation=0 parameters to your u-boot arguments to get this
working. This supports 0,90,180 and 270 degree rotations.
Signed-off-by: Rajesh K [EMAIL PROTECTED]
Signed-off-by: Iqbal Shareef [EMAIL PROTECTED]
---
arch/arm/plat-omap/include/mach/omapfb.h |4 +-
drivers/video/omap/dispc.c | 189 +-
drivers/video/omap/dispc.h | 33 +-
drivers/video/omap/omapfb_main.c | 32 +++---
4 files changed, 236 insertions(+), 22 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/omapfb.h
b/arch/arm/plat-omap/include/mach/omapfb.h
index a4a84f3..338a11d 100644
--- a/arch/arm/plat-omap/include/mach/omapfb.h
+++ b/arch/arm/plat-omap/include/mach/omapfb.h
@@ -277,7 +277,7 @@ typedef int (*omapfb_notifier_callback_t)(struct
notifier_block *,
struct omapfb_mem_region {
dma_addr_t paddr;
- void*vaddr;
+ void __iomem*vaddr;
unsigned long size;
u8 type; /* OMAPFB_PLANE_MEM_* */
unsignedalloc:1;/* allocated by the driver */
@@ -306,7 +306,7 @@ struct lcd_ctrl {
int screen_width,
int pos_x, int pos_y, int width,
int height, int color_mode);
- int (*set_rotate) (int angle);
+ int (*set_rotate) (int plane, int angle);
int (*setup_mem) (int plane, size_t size,
int mem_type, unsigned long *paddr);
int (*mmap) (struct fb_info *info,
diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index ce4c4de..1f5a7a5 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -149,12 +149,25 @@
#define RESMAP_MASK(_page_nr) \
(1 ((_page_nr) (sizeof(unsigned long) * 8 - 1)))
+unsigned long save_paddr;
+unsigned long save_vaddr;
+
struct resmap {
unsigned long start;
unsignedpage_cnt;
unsigned long *map;
};
+struct {
+ unsigned long paddr[4];
+ void __iomem *vaddr[4];
+ u32 xoffset;
+ u32 yoffset;
+ unsigned long size_val;
+ unsigned long control_val;
+} vrfb;
+
+static void omap2_disp_set_vrfb(u32 width, u32 height, u32 bytes_per_pixel);
static struct {
void __iomem*base;
@@ -459,6 +472,170 @@ static int omap_dispc_setup_plane(int plane, int
channel_out,
return r;
}
+/*
+* pages_per_side : Will provide pages per side
+* @ img_side : img_side
+* @ page_exp : page_exponential
+* Return Value: Returns pages per side value.
+*/
+
+static inline u32 pages_per_side(u32 img_side, u32 page_exp)
+{
+ return (img_side + (1page_exp) - 1) page_exp;
+}
+
+/*
+* omap2_disp_set_vrfb : Will configure VRFB Support.Its a rotation engine
+* which will supports rotations of 0,90,180,270 degrees.
+* @width: Width of the image
+* @height : height of the image
+* @bytes_per_pixel : color depth of the image
+* return value : None
+*/
+
+static void omap2_disp_set_vrfb(u32 width, u32 height, u32 bytes_per_pixel)
+{
+ int page_width_exp, page_height_exp, pixel_size_exp;
+ int context = 0;
+ vrfb.size_val = 0;
+ vrfb.control_val = 0;
+ pixel_size_exp = bytes_per_pixel 1;
+ page_width_exp = PAGE_WIDTH_EXP;
+ page_height_exp = PAGE_HEIGHT_EXP;
+
+ width = ((1page_width_exp) *
+ (pages_per_side(width * bytes_per_pixel,
+ page_width_exp))) pixel_size_exp;
+ height = (1page_height_exp) *
+ (pages_per_side(height, page_height_exp));
+
+ __raw_writel(save_paddr, SMS_ROT0_PHYSICAL_BA(context));
+ __raw_writel(0, SMS_ROT0_SIZE(context));
+
+ vrfb.size_val |= (width SMS_IMAGEWIDTH_OFFSET)|
+ (height SMS_IMAGEHEIGHT_OFFSET);
+ __raw_writel(vrfb.size_val, SMS_ROT0_SIZE(context));
+ __raw_writel(0, SMS_ROT_CONTROL(context));
+ vrfb.control_val |= pixel_size_exp SMS_PS_OFFSET
+ | (page_width_exp - pixel_size_exp) SMS_PW_OFFSET
+ | page_height_exp SMS_PH_OFFSET;
+ __raw_writel(vrfb.control_val, SMS_ROT_CONTROL(context));
+}
+
+/*
+* omap_dispc_set_rotate : configuring rotation registers based on angle.
+* @ plane: graphics or video pipe line
+* @ angle: Rotation angle.
+* Return Value: Returns 0 on success
+ Returns -1 if it fails.
+*/
+
+int omap_dispc_set_rotate(int plane, int angle)
+{
+ int width, height;
+ u32 addr_base;
+ u32
Re: OMAP support in mainline?
* Tony Lindgren [EMAIL PROTECTED] [080917 09:55]: * Kalle Valo [EMAIL PROTECTED] [080916 23:32]: Jarkko Nikula [EMAIL PROTECTED] writes: On Tue, 16 Sep 2008 16:25:06 -0700 ext Tony Lindgren [EMAIL PROTECTED] wrote: Hopefully we'll get all core 24xx and 34xx files integrated soon. But then there are tons of board-*.c files missing from mainline that probably need to be cleaned up a bit. I think one good measure for this whole work when one can can run Beagle or Overo with mainline kernel. I really would like to run N800/N810 with mainline kernel (ie. with Linus' tree), at least get it booting. For example, sound and bluetooth are not that important for me right now. What kind of cleanup is needed for that? Well here are few things that come to mind for N8X0: - drivers/cbus needs to be cleaned and submitted via LKML - arch/arm/mach-omap2/board-n800*.c maybe should be called board-n8x0*.c instead? - blizzard_enable_clocks() needs to create a virtual clock so that drivers/video/omap/ can just call clk_enable/disable(). Other board files may need this done too, at least nokia770*.c has the same problem Oh, one more thing: All the ATAG_OMAP data needs to be set in the board-*.c files as platform_data, omap specific ATAGs won't be going to mainline as discussed earlier on linux-arm-kernel. If any ATAGs are needed, such as for the serial console, it needs to be a generic ATAG for whole arch/arm. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP support in mainline?
* Kalle Valo [EMAIL PROTECTED] [080916 23:32]: Jarkko Nikula [EMAIL PROTECTED] writes: On Tue, 16 Sep 2008 16:25:06 -0700 ext Tony Lindgren [EMAIL PROTECTED] wrote: Hopefully we'll get all core 24xx and 34xx files integrated soon. But then there are tons of board-*.c files missing from mainline that probably need to be cleaned up a bit. I think one good measure for this whole work when one can can run Beagle or Overo with mainline kernel. I really would like to run N800/N810 with mainline kernel (ie. with Linus' tree), at least get it booting. For example, sound and bluetooth are not that important for me right now. What kind of cleanup is needed for that? Well here are few things that come to mind for N8X0: - drivers/cbus needs to be cleaned and submitted via LKML - arch/arm/mach-omap2/board-n800*.c maybe should be called board-n8x0*.c instead? - blizzard_enable_clocks() needs to create a virtual clock so that drivers/video/omap/ can just call clk_enable/disable(). Other board files may need this done too, at least nokia770*.c has the same problem Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH omapzoom tree] Fix keypad for LDP
Hi Vikram,
This patch fixes the keypad for LDP on the OMAPZOOM tree.
- Adds dependency on MACH_LDP for TWL4030 KEYPAD menuconfig option.
- Adds correct keypad IRQ to LDP board file.
- Adds the struct omap_keypad to GPIO part of the T2 keypad driver.
Regards,
dom
Signed-off-by: Dominic Curran [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-ldp.c|1 +
drivers/input/keyboard/Kconfig |2 +-
drivers/input/keyboard/omap-twl4030keypad.c| 25
3 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 175668e..58f56a2 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -286,6 +286,7 @@ static struct omap_kp_platform_data ldp_kp_data = {
.keymap = ldp_twl4030_keymap,
.keymapsize = ARRAY_SIZE(ldp_twl4030_keymap),
.rep= 1,
+ .irq= TWL4030_MODIRQ_KEYPAD,
/* Use row_gpios as a way to pass the OMAP GPIO keymap pointer */
.row_gpios = ldp_omap_gpio_keymap,
};
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index e4d0436..c8abf13 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -261,7 +261,7 @@ config KEYBOARD_OMAP
config KEYBOARD_TWL4030
tristate TI TWL4030 keypad support
- depends on TWL4030_CORE (MACH_OMAP_2430SDP || MACH_OMAP2EVM ||
MACH_OMAP_3430SDP || MACH_OMAP3EVM)
+ depends on TWL4030_CORE (MACH_OMAP_2430SDP || MACH_OMAP2EVM ||
MACH_OMAP_3430SDP || MACH_OMAP3EVM || MACH_OMAP_LDP)
help
Say Y here if you want to use the OMAP TWL4030 keypad.
diff --git a/drivers/input/keyboard/omap-twl4030keypad.c
b/drivers/input/keyboard/omap-twl4030keypad.c
index 1ca2987..87ee1dd 100644
--- a/drivers/input/keyboard/omap-twl4030keypad.c
+++ b/drivers/input/keyboard/omap-twl4030keypad.c
@@ -38,6 +38,7 @@
#include linux/i2c.h
#include linux/i2c/twl4030.h
#include linux/irq.h
+#include mach/gpio.h
#include mach/keypad.h
#include twl4030-keypad.h
@@ -241,7 +242,7 @@ static irqreturn_t do_kp_irq(int irq, void *_kp)
}
#ifdef CONFIG_MACH_OMAP_LDP
-static void omap_gpio_kp_scan(void)
+static void omap_gpio_kp_scan(struct omap_keypad *kp)
{
unsigned int new_gpio;
int idx = 0, chg = 0, key, state;
@@ -254,7 +255,7 @@ static void omap_gpio_kp_scan(void)
if (chg) {
key = GET_KEY(omap_gpios[idx]);
state = (new_gpio == 0);
- input_report_key(omap_twl4030kp, key, state);
+ input_report_key(kp-omap_twl4030kp, key, state);
}
if (!new_gpio)
@@ -281,10 +282,12 @@ static void omap_gpio_kp_scan(void)
/*
* Keypad interrupt handler for OMAP GPIO's.
*/
-static irqreturn_t do_kp_gpio_irq(int irq, void *dev_id)
+static irqreturn_t do_kp_gpio_irq(int irq, void *_kp)
{
+ struct omap_keypad *kp = _kp;
+
/* Scan keypad for any changes in GPIO keys. */
- omap_gpio_kp_scan();
+ omap_gpio_kp_scan(kp);
return IRQ_HANDLED;
}
@@ -292,10 +295,12 @@ static irqreturn_t do_kp_gpio_irq(int irq, void *dev_id)
static void omap_gpio_kp_timer(unsigned long arg)
{
- omap_gpio_kp_scan();
+ struct omap_keypad *kp = (struct omap_keypad*)arg;
+ omap_gpio_kp_scan(kp);
}
-static int omap_gpio_kp_probe(unsigned int *gpio_keymap)
+static int
+omap_gpio_kp_probe(struct omap_keypad *kp, unsigned int *gpio_keymap)
{
int i, idx = 0, irq_idx = 0;
@@ -321,18 +326,18 @@ static int omap_gpio_kp_probe(unsigned int *gpio_keymap)
while (omap_gpios[irq_idx] != 0) {
if (request_irq(OMAP_GPIO_IRQ(GET_GPIO(omap_gpios[irq_idx])),
do_kp_gpio_irq, IRQF_TRIGGER_FALLING,
- omap-keypad, NULL) 0)
+ omap-keypad, kp) 0)
goto err2;
irq_idx++;
}
/* Initialize GPIO timer */
gpio_timer.function = omap_gpio_kp_timer;
- gpio_timer.data = (unsigned long)NULL;
+ gpio_timer.data = (unsigned long)kp;
init_timer(gpio_timer);
/* scan current key state */
- omap_gpio_kp_scan();
+ omap_gpio_kp_scan(kp);
return 0;
@@ -503,7 +508,7 @@ static int __init omap_kp_probe(struct platform_device
*pdev)
goto err4;
#ifdef CONFIG_MACH_OMAP_LDP
- omap_gpio_kp_probe(pdata-row_gpios);
+ omap_gpio_kp_probe(kp, pdata-row_gpios);
#endif
return ret;
--
1.5.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
getting 2.6.25 from git to run on omap35x evm
The OMAP35x EVM (from TI/Mistral) runs their SDK 1.0.0 which is based on linux-2.6.22.18. I'm trying to get linux-2.6.25 (tag = v2.6.25-omap1 from linux-omap-2.6.git) running on the 35x EVM but having difficulties. The linux-2.6.22.18 including support for OMAP 35x EVM appears quite different from linux-omap-2.6.25 from git in the OMAP specific areas. Should linux-omap-2.6.25-v2.6.25-omap1 build and run without modifications on OMAP 35x EVM? If so, I should be able to port SDK 1.0.0 functionality (that perhaps hasn't made it into the linux-omap git yet) over to newer 2.6.25 kernel as necessary - correct? If not, is there another or newer kernel in linux-omap get that could/should run on 35x EVM, or is another approach suggested? Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: getting 2.6.25 from git to run on omap35x evm
Op 17 sep 2008, om 20:36 heeft twebb het volgende geschreven: The OMAP35x EVM (from TI/Mistral) runs their SDK 1.0.0 which is based on linux-2.6.22.18. I'm trying to get linux-2.6.25 (tag = v2.6.25-omap1 from linux-omap-2.6.git) running on the 35x EVM but having difficulties. The linux-2.6.22.18 including support for OMAP 35x EVM appears quite different from linux-omap-2.6.25 from git in the OMAP specific areas. Should linux-omap-2.6.25-v2.6.25-omap1 build and run without modifications on OMAP 35x EVM? If so, I should be able to port SDK 1.0.0 functionality (that perhaps hasn't made it into the linux-omap git yet) over to newer 2.6.25 kernel as necessary - correct? If not, is there another or newer kernel in linux-omap get that could/should run on 35x EVM, or is another approach suggested? Why 2.6.25? Git has 2.6.26 already and currenly is at 2.6.27rc6, so why go from one obsolete version to another obsolete one? .27rc is pretty broken on the EVM atm, ut .26 should work fine. regards, Koen PGP.sig Description: This is a digitally signed message part
Re: getting 2.6.25 from git to run on omap35x evm
On Wed, Sep 17, 2008 at 2:59 PM, Koen Kooi [EMAIL PROTECTED] wrote: Why 2.6.25? Git has 2.6.26 already and currenly is at 2.6.27rc6, so why go from one obsolete version to another obsolete one? .27rc is pretty broken on the EVM atm, ut .26 should work fine. Was going with 2.6.25 because once I get basic functionality on the EVM with linux-omap-2.6.25, next step is applying a separate 2.6.25-based patch. So 2.6.26 should work OK on 35xEVM? If so, I'll see if patch applies without problems and give it a try. Does anyone (TI?) know how far apart their linux-2.6.22.18 (SDK 1.0.0) is from the linux-omap-2.6.git and when they might converge? Along these lines, which defconfig to use for OMAP35x EVM: SDK = omap3evm_defconfig or linux-omap-2.6.25 = omap3_evm_defconfig (different names and different contents)? Thanks. twebb -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: getting 2.6.25 from git to run on omap35x evm
On Wed, Sep 17, 2008 at 3:23 PM, twebb [EMAIL PROTECTED] wrote: On Wed, Sep 17, 2008 at 2:59 PM, Koen Kooi [EMAIL PROTECTED] wrote: Why 2.6.25? Git has 2.6.26 already and currenly is at 2.6.27rc6, so why go from one obsolete version to another obsolete one? .27rc is pretty broken on the EVM atm, ut .26 should work fine. Was going with 2.6.25 because once I get basic functionality on the EVM with linux-omap-2.6.25, next step is applying a separate 2.6.25-based patch. So 2.6.26 should work OK on 35xEVM? If so, I'll see if patch applies without problems and give it a try. Does anyone (TI?) know how far apart their linux-2.6.22.18 (SDK 1.0.0) is from the linux-omap-2.6.git and when they might converge? Along these lines, which defconfig to use for OMAP35x EVM: SDK = omap3evm_defconfig or linux-omap-2.6.25 = omap3_evm_defconfig (different names and different contents)? Thanks. twebb -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html If you take a look at the http://git.omapzoom.org tree as opposed to the official Linux OMAP tree, that things will be more linear to your 2.6.22.18 tree. I'm currently moving our 2.6.22.18 codebase to 2.6.27-rc3 based on the OMAPZOOM tree and it's faring a lot better then when I tried the official tree. So use OMAPZOOM to quickly jump ahead and once up-to-date you can figure out what the next step is to get more towards the official L-O tree.. Regards ~ Ashwin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: getting 2.6.25 from git to run on omap35x evm
On Wed, Sep 17, 2008 at 3:36 PM, Ashwin Bihari [EMAIL PROTECTED] wrote: Does anyone (TI?) know how far apart their linux-2.6.22.18 (SDK 1.0.0) is from the linux-omap-2.6.git and when they might converge? Along these lines, which defconfig to use for OMAP35x EVM: SDK = omap3evm_defconfig or linux-omap-2.6.25 = omap3_evm_defconfig (different names and different contents)? If you take a look at the http://git.omapzoom.org tree as opposed to the official Linux OMAP tree, that things will be more linear to your 2.6.22.18 tree. I'm currently moving our 2.6.22.18 codebase to 2.6.27-rc3 based on the OMAPZOOM tree and it's faring a lot better then when I tried the official tree. So use OMAPZOOM to quickly jump ahead and once up-to-date you can figure out what the next step is to get more towards the official L-O tree.. Regards ~ Ashwin Great, that's helpful. Do you know omapzoom linux-2.6.25 to be somewhat functional with OMAP 35x EVM, or would you suggest going with something newer like v2.6.26-ti-07252008? Or must I go to 2.6.27-rc3? I assume newer (to a point) would result in better stability on the 35x EVM? Thanks, twebb -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP support in mainline?
On Wed, Sep 17, 2008 at 09:57:25AM -0700, Tony Lindgren wrote: If any ATAGs are needed, such as for the serial console, it needs to be a generic ATAG for whole arch/arm. Why is it needed for serial console anyway? We already have a cross- architecture way of defining the console - it's the 'console=' argument given to the kernel at boot time via the argument string. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: getting 2.6.25 from git to run on omap35x evm
On Wed, Sep 17, 2008 at 4:11 PM, twebb [EMAIL PROTECTED] wrote: On Wed, Sep 17, 2008 at 3:36 PM, Ashwin Bihari [EMAIL PROTECTED] wrote: Does anyone (TI?) know how far apart their linux-2.6.22.18 (SDK 1.0.0) is from the linux-omap-2.6.git and when they might converge? Along these lines, which defconfig to use for OMAP35x EVM: SDK = omap3evm_defconfig or linux-omap-2.6.25 = omap3_evm_defconfig (different names and different contents)? If you take a look at the http://git.omapzoom.org tree as opposed to the official Linux OMAP tree, that things will be more linear to your 2.6.22.18 tree. I'm currently moving our 2.6.22.18 codebase to 2.6.27-rc3 based on the OMAPZOOM tree and it's faring a lot better then when I tried the official tree. So use OMAPZOOM to quickly jump ahead and once up-to-date you can figure out what the next step is to get more towards the official L-O tree.. Regards ~ Ashwin Great, that's helpful. Do you know omapzoom linux-2.6.25 to be somewhat functional with OMAP 35x EVM, or would you suggest going with something newer like v2.6.26-ti-07252008? Or must I go to 2.6.27-rc3? I assume newer (to a point) would result in better stability on the 35x EVM? Thanks, twebb The EVM is a board option in this tree, so you're going to have the best possible luck with the latest and greatest code base. I have a custom board based on the OMAP3530. So I'm actually adding a new board-type and the necessary pieces appropriate for my platform. Regards ~ Ashwin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Re: omap-sdp3430_Rotation patch
Hi,
On Wed, Sep 17, 2008 at 11:43 AM, [EMAIL PROTECTED] wrote:
From: Rajesh K [EMAIL PROTECTED]
OMAP FBDEV: VRFB framebuffer rotation support
This patch provides rotation support for OMAP2/3. You will have to append
video=omapfb:rotation=0 parameters to your u-boot arguments to get this
working. This supports 0,90,180 and 270 degree rotations.
Signed-off-by: Rajesh K [EMAIL PROTECTED]
Signed-off-by: Iqbal Shareef [EMAIL PROTECTED]
---
arch/arm/plat-omap/include/mach/omapfb.h |4 +-
drivers/video/omap/dispc.c | 189
+-
drivers/video/omap/dispc.h | 33 +-
drivers/video/omap/omapfb_main.c | 32 +++---
4 files changed, 236 insertions(+), 22 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/omapfb.h
b/arch/arm/plat-omap/include/mach/omapfb.h
index a4a84f3..338a11d 100644
--- a/arch/arm/plat-omap/include/mach/omapfb.h
+++ b/arch/arm/plat-omap/include/mach/omapfb.h
@@ -277,7 +277,7 @@ typedef int (*omapfb_notifier_callback_t)(struct
notifier_block *,
struct omapfb_mem_region {
dma_addr_t paddr;
- void*vaddr;
+ void __iomem*vaddr;
unsigned long size;
u8 type; /* OMAPFB_PLANE_MEM_* */
unsignedalloc:1;/* allocated by the driver */
@@ -306,7 +306,7 @@ struct lcd_ctrl {
int screen_width,
int pos_x, int pos_y, int width,
int height, int color_mode);
- int (*set_rotate) (int angle);
+ int (*set_rotate) (int plane, int angle);
int (*setup_mem) (int plane, size_t size,
int mem_type, unsigned long *paddr);
int (*mmap) (struct fb_info *info,
diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index ce4c4de..1f5a7a5 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -149,12 +149,25 @@
#define RESMAP_MASK(_page_nr) \
(1 ((_page_nr) (sizeof(unsigned long) * 8 - 1)))
+unsigned long save_paddr;
sav_vaddr is defined but nowhere used.
+unsigned long save_vaddr;
+
struct resmap {
unsigned long start;
unsignedpage_cnt;
unsigned long *map;
};
+struct {
+ unsigned long paddr[4];
+ void __iomem *vaddr[4];
+ u32 xoffset;
+ u32 yoffset;
+ unsigned long size_val;
+ unsigned long control_val;
+} vrfb;
+
+static void omap2_disp_set_vrfb(u32 width, u32 height, u32 bytes_per_pixel);
static struct {
void __iomem*base;
@@ -459,6 +472,170 @@ static int omap_dispc_setup_plane(int plane, int
channel_out,
return r;
}
+/*
+* pages_per_side : Will provide pages per side
+* @ img_side : img_side
+* @ page_exp : page_exponential
+* Return Value: Returns pages per side value.
+*/
+
+static inline u32 pages_per_side(u32 img_side, u32 page_exp)
+{
+ return (img_side + (1page_exp) - 1) page_exp;
+}
+
+/*
+* omap2_disp_set_vrfb : Will configure VRFB Support.Its a rotation
engine
+* which will supports rotations of 0,90,180,270 degrees.
+* @width: Width of the image
+* @height : height of the image
+* @bytes_per_pixel : color depth of the image
+* return value : None
+*/
+
+static void omap2_disp_set_vrfb(u32 width, u32 height, u32 bytes_per_pixel)
+{
+ int page_width_exp, page_height_exp, pixel_size_exp;
+ int context = 0;
+ vrfb.size_val = 0;
+ vrfb.control_val = 0;
+ pixel_size_exp = bytes_per_pixel 1;
+ page_width_exp = PAGE_WIDTH_EXP;
+ page_height_exp = PAGE_HEIGHT_EXP;
+
+ width = ((1page_width_exp) *
+ (pages_per_side(width * bytes_per_pixel,
+ page_width_exp))) pixel_size_exp;
+ height = (1page_height_exp) *
+ (pages_per_side(height, page_height_exp));
+
+ __raw_writel(save_paddr, SMS_ROT0_PHYSICAL_BA(context));
+ __raw_writel(0, SMS_ROT0_SIZE(context));
+
+ vrfb.size_val |= (width SMS_IMAGEWIDTH_OFFSET)|
+ (height SMS_IMAGEHEIGHT_OFFSET);
+ __raw_writel(vrfb.size_val, SMS_ROT0_SIZE(context));
+ __raw_writel(0, SMS_ROT_CONTROL(context));
+ vrfb.control_val |= pixel_size_exp SMS_PS_OFFSET
+ | (page_width_exp - pixel_size_exp) SMS_PW_OFFSET
+ | page_height_exp SMS_PH_OFFSET;
+ __raw_writel(vrfb.control_val, SMS_ROT_CONTROL(context));
+}
+
+/*
+* omap_dispc_set_rotate : configuring rotation registers based on angle.
+* @ plane: graphics or video pipe line
+* @ angle: Rotation angle.
