RE: ehci-omap: Build break on Linus' tree
> (Really looping Tony. Darn broken mailer and poor memory) > > Gadiyar, Anand wrote: > > > > > Tony, > > > > We lost this patch on the way to mainline: > > (it needs a small update - filename changed before > > we can send it out) > > > > http://patchwork.kernel.org/patch/58093/ > > > > Would you like me to rework it, or can you take care of this? > > > > > > Without this, the omap3 defconfigs that build EHCI will > > break (tested omap_3430sdp_defconfig for now). > > All that was needed was this one: http://patchwork.kernel.org/patch/65678/ which is already in your omap-fixes queue. Now to take care of the build warnings and suspend-resume. - Anand -- 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: ehci-omap: Build break on Linus' tree
(Really looping Tony. Darn broken mailer and poor memory) Gadiyar, Anand wrote: > > Tony, > > We lost this patch on the way to mainline: > (it needs a small update - filename changed before > we can send it out) > > http://patchwork.kernel.org/patch/58093/ > > Would you like me to rework it, or can you take care of this? > > > Without this, the omap3 defconfigs that build EHCI will > break (tested omap_3430sdp_defconfig for now). > > - Anand -- 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
ehci-omap: Build break on Linus' tree
Tony, We lost this patch on the way to mainline: (it needs a small update - filename changed before we can send it out) http://patchwork.kernel.org/patch/58093/ Would you like me to rework it, or can you take care of this? Without this, the omap3 defconfigs that build EHCI will break (tested omap_3430sdp_defconfig for now). - Anand -- 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: [RFC][PATCH 4/5] input: serio: add support for Amstrad Delta serial keyboard port
Friday 11 December 2009 09:01:28 Dmitry Torokhov napisał(a): > On Fri, Dec 11, 2009 at 04:09:58AM +0100, Janusz Krzysztofik wrote: > > Friday 11 December 2009 03:36:58 Dmitry Torokhov napisał(a): > > > On Thu, Dec 10, 2009 at 09:07:50PM +0100, Janusz Krzysztofik wrote: > > > > + > > > > +/* > > > > + * This table converts the amstrad mailboard scancodes to normal PC- > > > > AT scancodes > > > > + * The diagram below shows the amstrad keyboard, with the raw > > > > scancodes > > > > + * > > > > + * (70) (7A) (46) (7C) (77) Amstrad (72) (69) (1A) (2A) > > > > (1C) (15) > > > > + * [ 71][1:74][2:73][3:6B][4:22][5:1B][6:1D][7:1E][8:79][9:7D] > > > > [0:75][ 6C] > > > > + * [Q:21][W:23][E:24][R:26][T:52][Y:5D][U:0D][I:0E][O:32][P:34] | > > > > return| > > > > + * [A:31][S:33][D:35][F:36][G:29][H:5B][J:03][K:76][L:3A][@:3B] > > > > > > > > | 2C| > > > > > > > > + * [ 3C][Z:3D][X:4E][C:54][V:0B][B:05][N:41][M:42][.:43][ 3E] > > > > [ 55] > > > > + * [ 83][ 06][ 49][ 4B ][,:44][ 16][ 2E] > > > > [ 09] > > > > + * > > > > + * These scancodes are then translated to AT scancodes using the > > > > following table > > > > + * The amstrad keyboard does not produce any extended scancodes, > > > > but we need to > > > > + * translate some amstrad scancodes to a AT extended scancode, > > > > hence the 16bit > > > > + * value for the translated scancode > > > > + * > > > > > > No, please write a proper keyboard driver instead of creating this > > > Frankenstain monster. It is not a generic serio-style data source so it > > > should not use serio, should reside in drivers/input/keyboard and > > > create input device by itself. > > > > I'll see if I'm able to create a proper driver myself when I find some > > spare time. > > Yes, that would be great, thank you. In fact it should end up about the > same as this driver, except instead of creating and registering serio > port you will need to register input_dev structure and instead of > translating into atkbd scancodes you need to translate directly into > Linux keycodes (KEY_A, KEY_1 and so on). Dmitry, Thanks for your directions. However, before I get to work, please let me still better understand what I am really supposed to create here, and why you think it should be done one way and not the other. I'd rather avoid submitting an input related code that you might find not adequate in the future. First, I have never submitted a single line of code that would be accepted for inclusion into drivers/input before. Could you please recommend a documentation for me to read, from where I could learn what a proper keyboard driver should look like, and what kind of devices can be considered as generic serio-style data sources and what can't, and more? Or should I better give up being that short of required knowledge? Moreover, please have a look at these two messages posted by Cliff Lawson, who worked for Amstrad while the E3 (codename Delta) was being developed, being involved in that development: http://www.earth.li/pipermail/e3-hacking/2006-April/000445.html http://www.earth.li/pipermail/e3-hacking/2006-April/000449.html As one can read, the Amstrad Delta keyboard was described by Cliff as a PS/2 device, even if not connected to a regular PS/2 port but some MPU GPIO lines directly instead. Furthermore, it has been proven by Matt Callow, who created the serio driver you didn't like, that the atkbd keyboard driver already works fine for this keyboard if fed with scancodes matching what it is told to expect. Please also note that the E3 keyboard port is supposed to be used not only for getting input from the keyboard, but from a bundled gamepad as well. Not yet supported, but who knows if forever. That said, do you still think there is a need to create a new, separate keyboard driver for the device in question? Isn't reusing an existing, proven to be working correctly, keyboard driver module, isn't it a good solution here? If not, could you please elaborate on why it's not? I always thought that being PS/2 compatible is enough for a device to be considered as supported by atkbd, but maybe I just don't understand what the atkbd driver is designed for and what a supported device should look like. Moreover, isn't a port, that is supposed to interact with at least two distinct input devices, isn't it worth of creating a separate driver for it, be it serio module or anything else that would better match the input subsystem design? In your initial answer, you quoted a part of the patch, namely that containing a description of the driver's scancode translation functionality. I guess you tried to say that traslating scancodes inside a port driver is wrong. I would agree with that, without any reservations. But for your other conclusions, could you please reconsider if still valid, and elaborate on them if you think they are? Thanks, Janusz PS. To be honest, I have to inform every E3 hacker still interreste
Re: [PATCH] OMAP3: Fix omap3_defconfig build
* Olof Johansson [091209 22:06]:
> Hi,
>
> {removing invalid lkml-like addressee}
>
> On Thu, Dec 10, 2009 at 11:19:52AM +0530, Anand Gadiyar wrote:
> > Select sound codecs to allow this defconfig to build again
>
> You need to fix the config option dependencies/selects, updating the
> defconfig just papers over the real problem.
>
> > Also, sync up this defconfig with the generated .configs.
>
> Good idea, but I suggest holding off until the merge window has closed
> since there are still new options going in. Doing a respin after -rc2
> or so makes more sense. So please redo in a few weeks?
>
> Traditionally Linus hasn't minded pulling in defconfig updates a little
> later in the release cycles.
This sounds like a good plan. Let's plan on doing a round of defconfig
updates later on during the merge cycle.
Regards,
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: [RFC][PATCH 4/5] input: serio: add support for Amstrad Delta serial keyboard port
Hi Janusz, On Sat, Dec 12, 2009 at 09:34:07PM +0100, Janusz Krzysztofik wrote: > Friday 11 December 2009 09:01:28 Dmitry Torokhov napisał(a): > > On Fri, Dec 11, 2009 at 04:09:58AM +0100, Janusz Krzysztofik wrote: > > > Friday 11 December 2009 03:36:58 Dmitry Torokhov napisał(a): > > > > On Thu, Dec 10, 2009 at 09:07:50PM +0100, Janusz Krzysztofik wrote: > > > > > + > > > > > +/* > > > > > + * This table converts the amstrad mailboard scancodes to normal PC- > > > > > AT scancodes > > > > > + * The diagram below shows the amstrad keyboard, with the raw > > > > > scancodes > > > > > + * > > > > > + * (70) (7A) (46) (7C) (77) Amstrad (72) (69) (1A) (2A) > > > > > (1C) (15) > > > > > + * [ 71][1:74][2:73][3:6B][4:22][5:1B][6:1D][7:1E][8:79][9:7D] > > > > > [0:75][ 6C] > > > > > + * [Q:21][W:23][E:24][R:26][T:52][Y:5D][U:0D][I:0E][O:32][P:34] | > > > > > return| > > > > > + * [A:31][S:33][D:35][F:36][G:29][H:5B][J:03][K:76][L:3A][@:3B] > > > > > > > > > > | 2C| > > > > > > > > > > + * [ 3C][Z:3D][X:4E][C:54][V:0B][B:05][N:41][M:42][.:43][ 3E] > > > > > [ 55] > > > > > + * [ 83][ 06][ 49][ 4B ][,:44][ 16][ 2E] > > > > > [ 09] > > > > > + * > > > > > + * These scancodes are then translated to AT scancodes using the > > > > > following table > > > > > + * The amstrad keyboard does not produce any extended scancodes, > > > > > but we need to > > > > > + * translate some amstrad scancodes to a AT extended scancode, > > > > > hence the 16bit > > > > > + * value for the translated scancode > > > > > + * > > > > > > > > No, please write a proper keyboard driver instead of creating this > > > > Frankenstain monster. It is not a generic serio-style data source so it > > > > should not use serio, should reside in drivers/input/keyboard and > > > > create input device by itself. > > > > > > I'll see if I'm able to create a proper driver myself when I find some > > > spare time. > > > > Yes, that would be great, thank you. In fact it should end up about the > > same as this driver, except instead of creating and registering serio > > port you will need to register input_dev structure and instead of > > translating into atkbd scancodes you need to translate directly into > > Linux keycodes (KEY_A, KEY_1 and so on). > > Dmitry, > > Thanks for your directions. However, before I get to work, please let me > still > better understand what I am really supposed to create here, and why you think > it should be done one way and not the other. I'd rather avoid submitting an > input related code that you might find not adequate in the future. > > First, I have never submitted a single line of code that would be accepted for > inclusion into drivers/input before. Could you please recommend a > documentation for me to read, from where I could learn what a proper keyboard > driver should look like, I guess I meant "proper keyboard driver" in the sense of a driver that creates and registeres its own input_dev and perform direct translation of data coming form hardware into linux input events. > and what kind of devices can be considered as generic > serio-style data sources and what can't, and more? If a same device can be used on different platforms and several devices may use the same port then I can see the need of creating a serio abstraction. But if tere is 1:1 relationship then a driver that attaches directly to the hardware might make sense. > Or should I better give up > being that short of required knowledge? > > Moreover, please have a look at these two messages posted by Cliff Lawson, > who > worked for Amstrad while the E3 (codename Delta) was being developed, being > involved in that development: > > http://www.earth.li/pipermail/e3-hacking/2006-April/000445.html > http://www.earth.li/pipermail/e3-hacking/2006-April/000449.html > > As one can read, the Amstrad Delta keyboard was described by Cliff as a PS/2 > device, even if not connected to a regular PS/2 port but some MPU GPIO lines > directly instead. > > Furthermore, it has been proven by Matt Callow, who created the serio driver > you didn't like, that the atkbd keyboard driver already works fine for this > keyboard if fed with scancodes matching what it is told to expect. Of course atkbd would work fine if it is fed the data it expects. The same can be said for any driver in the tree, isn't it? It is possible to write HID-to-atkbd or "gpio matrix to atkbd" "serios" but that does not mean it is the right thing to do. > > Please also note that the E3 keyboard port is supposed to be used not only > for > getting input from the keyboard, but from a bundled gamepad as well. Not yet > supported, but who knows if forever. Can they be used simultaneously? Would not the translation that you perform right now cause issues with the gamepad? Are you thinking about reusing one of the existing gamepad modules in the same fashion as you do for atkbd but translating the data into its native format? > > T
[PATCH v2] [I2C-OMAP] Add support for 16-bit registers
The current i2c-omap driver is set up for 32-bit registers, which
corresponds to most OMAP devices. However, OMAP730/850 based
devices use a 16-bit register size.
This change modifies the driver to perform a runtime CPU type check
to determine the register sizes, and uses a bit shift of either 1
or 2 bits to compute the proper register sizes for all registers.
Signed-off-by: Cory Maccarrone
---
drivers/i2c/busses/i2c-omap.c | 44 +++-
1 files changed, 25 insertions(+), 19 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 827da08..4f8e2f5 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -49,24 +49,24 @@
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
#define OMAP_I2C_REV_REG 0x00
-#define OMAP_I2C_IE_REG0x04
-#define OMAP_I2C_STAT_REG 0x08
-#define OMAP_I2C_IV_REG0x0c
+#define OMAP_I2C_IE_REG0x01
+#define OMAP_I2C_STAT_REG 0x02
+#define OMAP_I2C_IV_REG0x03
/* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
-#define OMAP_I2C_WE_REG0x0c
-#define OMAP_I2C_SYSS_REG 0x10
-#define OMAP_I2C_BUF_REG 0x14
-#define OMAP_I2C_CNT_REG 0x18
-#define OMAP_I2C_DATA_REG 0x1c
-#define OMAP_I2C_SYSC_REG 0x20
-#define OMAP_I2C_CON_REG 0x24
-#define OMAP_I2C_OA_REG0x28
-#define OMAP_I2C_SA_REG0x2c
-#define OMAP_I2C_PSC_REG 0x30
-#define OMAP_I2C_SCLL_REG 0x34
-#define OMAP_I2C_SCLH_REG 0x38
-#define OMAP_I2C_SYSTEST_REG 0x3c
-#define OMAP_I2C_BUFSTAT_REG 0x40
+#define OMAP_I2C_WE_REG0x03
+#define OMAP_I2C_SYSS_REG 0x04
+#define OMAP_I2C_BUF_REG 0x05
+#define OMAP_I2C_CNT_REG 0x06
+#define OMAP_I2C_DATA_REG 0x07
+#define OMAP_I2C_SYSC_REG 0x08
+#define OMAP_I2C_CON_REG 0x09
+#define OMAP_I2C_OA_REG0x0a
+#define OMAP_I2C_SA_REG0x0b
+#define OMAP_I2C_PSC_REG 0x0c
+#define OMAP_I2C_SCLL_REG 0x0d
+#define OMAP_I2C_SCLH_REG 0x0e
+#define OMAP_I2C_SYSTEST_REG 0x0f
+#define OMAP_I2C_BUFSTAT_REG 0x10
/* I2C Interrupt Enable Register (OMAP_I2C_IE): */
#define OMAP_I2C_IE_XDR(1 << 14) /* TX Buffer drain int
enable */
@@ -161,6 +161,7 @@ struct omap_i2c_dev {
struct device *dev;
void __iomem*base; /* virtual */
int irq;
+ int reg_shift; /* bit shift for I2C register
addresses */
struct clk *iclk; /* Interface clock */
struct clk *fclk; /* Functional clock */
struct completion cmd_complete;
@@ -183,12 +184,12 @@ struct omap_i2c_dev {
static inline void omap_i2c_write_reg(struct omap_i2c_dev *i2c_dev,
int reg, u16 val)
{
- __raw_writew(val, i2c_dev->base + reg);
+ __raw_writew(val, i2c_dev->base + (reg << i2c_dev->reg_shift));
}
static inline u16 omap_i2c_read_reg(struct omap_i2c_dev *i2c_dev, int reg)
{
- return __raw_readw(i2c_dev->base + reg);
+ return __raw_readw(i2c_dev->base + (reg << i2c_dev->reg_shift));
}
static int __init omap_i2c_get_clocks(struct omap_i2c_dev *dev)
@@ -895,6 +896,11 @@ omap_i2c_probe(struct platform_device *pdev)
dev->b_hw = 1; /* Enable hardware fixes */
}
+ if (cpu_is_omap7xx())
+ dev->reg_shift = 1;
+ else
+ dev->reg_shift = 2;
+
/* reset ASAP, clearing any IRQs */
omap_i2c_init(dev);
--
1.6.3.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: [RFC/PATCH 2/5] usb: otg: twl4030: add support for notifier
On Fri, Dec 11, 2009 at 10:40:14PM +0200, Felipe Balbi wrote: > that's a threaded irq. Maybe we should patch all twl children to use > request_threaded_irq() already. I'll test that tomorrow. You should also now be able to do all the interrupt handling with genirq without the lockdep dodges that used to be be required. -- 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 v2 3/3] [OMAP] Add OMAP 7xx pin muxes for SPI
This change adds pin mux configuration for SPI100k on
omap7xx platforms.
Signed-off-by: Cory Maccarrone
---
arch/arm/mach-omap1/mux.c |8
arch/arm/plat-omap/include/plat/mux.h |8
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap1/mux.c b/arch/arm/mach-omap1/mux.c
index 07212cc..8434137 100644
--- a/arch/arm/mach-omap1/mux.c
+++ b/arch/arm/mach-omap1/mux.c
@@ -62,6 +62,14 @@ MUX_CFG_7XX("MMC_7XX_DAT0",2, 17,0, 16, 1,
0)
/* I2C interface */
MUX_CFG_7XX("I2C_7XX_SCL", 5,1,0,0, 1, 0)
MUX_CFG_7XX("I2C_7XX_SDA", 5,5,0,0, 1, 0)
+
+/* SPI pins */
+MUX_CFG_7XX("SPI_7XX_1", 6,5,4,4, 1, 0)
+MUX_CFG_7XX("SPI_7XX_2", 6,9,4,8, 1, 0)
+MUX_CFG_7XX("SPI_7XX_3", 6, 13,4, 12, 1, 0)
+MUX_CFG_7XX("SPI_7XX_4", 6, 17,4, 16, 1, 0)
+MUX_CFG_7XX("SPI_7XX_5", 8, 25,0, 24, 0, 0)
+MUX_CFG_7XX("SPI_7XX_6", 9,5,0,4, 0, 0)
};
#define OMAP7XX_PINS_SZARRAY_SIZE(omap7xx_pins)
#else
diff --git a/arch/arm/plat-omap/include/plat/mux.h
b/arch/arm/plat-omap/include/plat/mux.h
index 8f069cc..692c90e 100644
--- a/arch/arm/plat-omap/include/plat/mux.h
+++ b/arch/arm/plat-omap/include/plat/mux.h
@@ -183,6 +183,14 @@ enum omap7xx_index {
/* I2C */
I2C_7XX_SCL,
I2C_7XX_SDA,
+
+ /* SPI */
+ SPI_7XX_1,
+ SPI_7XX_2,
+ SPI_7XX_3,
+ SPI_7XX_4,
+ SPI_7XX_5,
+ SPI_7XX_6,
};
enum omap1xxx_index {
--
1.6.3.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 v3 1/3] [SPI] [OMAP] Add OMAP spi100k driver
This change adds the OMAP SPI 100k driver created by
Fabrice Crohas . This SPI bus is found on
OMAP7xx-series smartphones, and for many, the touchscreen is
attached to this bus.
The lion's share of the work was done by Fabrice on this driver --
I am merely porting it from the Linwizard project on his behalf.
Signed-off-by: Cory Maccarrone
---
drivers/spi/Kconfig |6 +
drivers/spi/Makefile|1 +
drivers/spi/omap_spi_100k.c | 635 +++
3 files changed, 642 insertions(+), 0 deletions(-)
create mode 100644 drivers/spi/omap_spi_100k.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 4b6f7cb..7ef9b12 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -164,6 +164,12 @@ config SPI_OMAP24XX
SPI master controller for OMAP24xx/OMAP34xx Multichannel SPI
(McSPI) modules.
+config SPI_OMAP_100K
+ tristate "OMAP SPI 100K"
+ depends on SPI_MASTER && (ARCH_OMAP850 || ARCH_OMAP730)
+ help
+ OMAP SPI 100K master controller for omap7xx boards.
+
config SPI_ORION
tristate "Orion SPI master (EXPERIMENTAL)"
depends on PLAT_ORION && EXPERIMENTAL
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 21a1182..55f670d 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_SPI_LM70_LLP)+= spi_lm70llp.o
obj-$(CONFIG_SPI_PXA2XX) += pxa2xx_spi.o
obj-$(CONFIG_SPI_OMAP_UWIRE) += omap_uwire.o
obj-$(CONFIG_SPI_OMAP24XX) += omap2_mcspi.o
+obj-$(CONFIG_SPI_OMAP_100K)+= omap_spi_100k.o
obj-$(CONFIG_SPI_ORION)+= orion_spi.o
obj-$(CONFIG_SPI_PL022)+= amba-pl022.o
obj-$(CONFIG_SPI_MPC52xx_PSC) += mpc52xx_psc_spi.o
diff --git a/drivers/spi/omap_spi_100k.c b/drivers/spi/omap_spi_100k.c
new file mode 100644
index 000..5355d90
--- /dev/null
+++ b/drivers/spi/omap_spi_100k.c
@@ -0,0 +1,635 @@
+/*
+ * OMAP7xx SPI 100k controller driver
+ * Author: Fabrice Crohas
+ * from original omap1_mcspi driver
+ *
+ * Copyright (C) 2005, 2006 Nokia Corporation
+ * Author: Samuel Ortiz and
+ * Juha Yrj�l�
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+
+#define OMAP1_SPI100K_MAX_FREQ 4800
+
+#define ICR_SPITAS (OMAP7XX_ICR_BASE + 0x12)
+
+#define SPI_SETUP1 0x00
+#define SPI_SETUP2 0x02
+#define SPI_CTRL0x04
+#define SPI_STATUS 0x06
+#define SPI_TX_LSB 0x08
+#define SPI_TX_MSB 0x0a
+#define SPI_RX_LSB 0x0c
+#define SPI_RX_MSB 0x0e
+
+#define SPI_SETUP1_INT_READ_ENABLE (1UL << 5)
+#define SPI_SETUP1_INT_WRITE_ENABLE (1UL << 4)
+#define SPI_SETUP1_CLOCK_DIVISOR(x) ((x) << 1)
+#define SPI_SETUP1_CLOCK_ENABLE (1UL << 0)
+
+#define SPI_SETUP2_ACTIVE_EDGE_FALLING (0UL << 0)
+#define SPI_SETUP2_ACTIVE_EDGE_RISING (1UL << 0)
+#define SPI_SETUP2_NEGATIVE_LEVEL (0UL << 5)
+#define SPI_SETUP2_POSITIVE_LEVEL (1UL << 5)
+#define SPI_SETUP2_LEVEL_TRIGGER(0UL << 10)
+#define SPI_SETUP2_EDGE_TRIGGER (1UL << 10)
+
+#define SPI_CTRL_SEN(x) ((x) << 7)
+#define SPI_CTRL_WORD_SIZE(x) (((x) - 1) << 2)
+#define SPI_CTRL_WR (1UL << 1)
+#define SPI_CTRL_RD (1UL << 0)
+
+#define SPI_STATUS_WE (1UL << 1)
+#define SPI_STATUS_RD (1UL << 0)
+
+#define WRITE 0
+#define READ 1
+
+
+/* use PIO for small transfers, avoiding DMA setup/teardown overhead and
+ * cache operations; better heuristics consider wordsize and bitrate.
+ */
+#define DMA_MIN_BYTES 8
+
+#define SPI_RUNNING0
+#define SPI_SHUTDOWN 1
+
+struct omap1_spi100k {
+ struct work_struct work;
+
+ /* lock protects queue and registers */
+ spinlock_t lock;
+ struct list_headmsg_queue;
+ struct spi_master *master;
+ struct clk *ick;
+ struct clk *fck;
+
+ /* Virtual base address of the controller */
+ void __iomem*
[PATCH v2 2/3] [OMAP] Add spi100k configuration to OMAP1
This change implements the clocks, platform driver, and register
information necessary to use the spi100k bus with OMAP 7xx systems.
The clocks added are dummy clocks because, although we're pretty
sure there are clocks used for SPI, all current booting methods result
in proper operation without the enabling of any other clocks.
Signed-off-by: Cory Maccarrone
---
arch/arm/mach-omap1/clock.c |4 +++
arch/arm/mach-omap1/devices.c | 34 +
arch/arm/plat-omap/include/plat/omap7xx.h |3 ++
3 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c
index dc8ca91..e584c0f 100644
--- a/arch/arm/mach-omap1/clock.c
+++ b/arch/arm/mach-omap1/clock.c
@@ -135,6 +135,10 @@ static struct omap_clk omap_clks[] = {
CLK("i2c_omap.1", "fck",&i2c_fck, CK_16XX | CK_1510 |
CK_310 | CK_7XX),
CLK("i2c_omap.1", "ick",&i2c_ick, CK_16XX),
CLK("i2c_omap.1", "ick",&dummy_ck, CK_1510 | CK_310 |
CK_7XX),
+ CLK("omap1_spi100k.1", "fck", &dummy_ck, CK_7XX),
+ CLK("omap1_spi100k.1", "ick", &dummy_ck, CK_7XX),
+ CLK("omap1_spi100k.2", "fck", &dummy_ck, CK_7XX),
+ CLK("omap1_spi100k.2", "ick", &dummy_ck, CK_7XX),
CLK("omap_uwire", "fck",&armxor_ck.clk, CK_16XX | CK_1510 |
CK_310),
CLK("omap-mcbsp.1", "ick", &dspper_ck, CK_16XX),
CLK("omap-mcbsp.1", "ick", &dummy_ck, CK_1510 | CK_310),
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 23ded2d..20bc62c 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -23,6 +24,7 @@
#include
#include
#include
+#include
/*-*/
@@ -196,6 +198,37 @@ void __init omap1_init_mmc(struct omap_mmc_platform_data
**mmc_data,
/*-*/
+/* OMAP7xx SPI support */
+#if defined(CONFIG_SPI_OMAP_100K) || defined(CONFIG_SPI_OMAP_100K_MODULE)
+
+struct platform_device omap_spi1 = {
+ .name = "omap1_spi100k",
+ .id = 1,
+};
+
+struct platform_device omap_spi2 = {
+ .name = "omap1_spi100k",
+ .id = 2,
+};
+
+static void omap_init_spi100k(void)
+{
+ omap_spi1.dev.platform_data = ioremap(OMAP7XX_SPI1_BASE, 0x7ff);
+ BUG_ON(!omap_spi1.dev.platform_data);
+
+ omap_spi2.dev.platform_data = ioremap(OMAP7XX_SPI2_BASE, 0x7ff);
+ BUG_ON(!omap_spi2.dev.platform_data);
+
+ platform_device_register(&omap_spi1);
+ platform_device_register(&omap_spi2);
+}
+
+#else
+static inline void omap_init_spi100k(void) {}
+#endif
+
+/*-*/
+
#if defined(CONFIG_OMAP_STI)
#define OMAP1_STI_BASE 0xfffea000
@@ -263,6 +296,7 @@ static int __init omap1_init_devices(void)
omap_init_mbox();
omap_init_rtc();
+ omap_init_spi100k();
omap_init_sti();
return 0;
diff --git a/arch/arm/plat-omap/include/plat/omap7xx.h
b/arch/arm/plat-omap/include/plat/omap7xx.h
index 53f5241..48e4757 100644
--- a/arch/arm/plat-omap/include/plat/omap7xx.h
+++ b/arch/arm/plat-omap/include/plat/omap7xx.h
@@ -46,6 +46,9 @@
#define OMAP7XX_DSPREG_SIZESZ_128K
#define OMAP7XX_DSPREG_START 0xE100
+#define OMAP7XX_SPI1_BASE 0xfffc0800
+#define OMAP7XX_SPI2_BASE 0xfffc1000
+
/*
*
* OMAP7XX specific configuration registers
--
1.6.3.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 v2 0/3] Add spi100k driver and arch support
This patch set implements the spi100k driver we use in the linwizard and wing-linux projects. This SPI driver is used for many omap7xx devices, particularly omap850 HTC smartphones. The first patch is directed at the SPI subsystem mailing list primarily for review. The other two are directed primarily at linux-omap for review. All three are sent to both to preserve complete context for all to see. This is a resubmit of the entire patch series to account for comments recieved on the first one. Cory Maccarrone (3): [SPI] [OMAP] Add OMAP spi100k driver [OMAP] Add spi100k configuration to OMAP1 [OMAP] Add OMAP 7xx pin muxes for SPI arch/arm/mach-omap1/clock.c |4 + arch/arm/mach-omap1/devices.c | 34 ++ arch/arm/mach-omap1/mux.c |8 + arch/arm/plat-omap/include/plat/mux.h |8 + arch/arm/plat-omap/include/plat/omap7xx.h |3 + drivers/spi/Kconfig |6 + drivers/spi/Makefile |1 + drivers/spi/omap_spi_100k.c | 635 + 8 files changed, 699 insertions(+), 0 deletions(-) create mode 100644 drivers/spi/omap_spi_100k.c -- 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
[GIT PULL] More omap code and fixes for 2.6.33 merge window
Linus,
Please pull more omap updates for this merge window from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
omap-for-linus
Most of the diffstat is caused by moving the clock framework
code around, adding new omap4 register defines, and new pin
multiplexing code.
Other changes are for booting omap4430 es1.0, minimal support
for Touch Book board, and a bunch of various fixes.
Regards,
Tony
The following changes since commit aa2cf420593b67cc93de7a3f675b2a88eba0505f:
Linus Torvalds (1):
Merge branch 'for-linus' of git://gitorious.org/linux-omap-dss2/linux
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
omap-for-linus
Anand Gadiyar (1):
omap3: zoom2/3: make MMC slot work again
Cory Maccarrone (3):
omap1: Add omap7xx USB support
omap1: I2C mux and clocks for omap7xx
omap1: htcherald: Update defconfig to include mux support
Grazvydas Ignotas (1):
omap3: pandora: board file updates for .33
Gregoire Gentil (2):
omap3: Board file of Always Innovating OMAP3-based Touch Book
omap3: Defconfig file of Always Innovating OMAP3-based Touch Book
Janusz Krzysztofik (2):
omap1: DMA: move LCD related code from plat-omap to mach-omap1
omap1: LCD_DMA: Use some define rather than a hexadecimal
Kalle Valo (1):
omap3: rx51: Use wl1251 in SPI mode 3
Kevin Hilman (6):
OMAP: omap_device: add to_omap_device() macro
OMAP: omap_device: use UINT_MAX for default wakeup latency limit
OMAP: omap_device: use read_persistent_clock() instead of getnstimeofday()
OMAP: hwmod: warn on missing clockdomain
OMAP: omap_device: fix nsec/usec conversion in latency calculations
OMAP: omap_device: track latency in nanoseconds
Ladislav Michl (4):
omap: use smc91x_platdata to setup smc91x
smc91x: remove OMAP specific bits
omap1: Use gen_nand
omap: arch/arm/plat-omap/devices.c - sort alphabetically
Madhusudhan Chikkature (1):
omap3: Zoom2/3: Update hsmmc board config params
Mika Westerberg (1):
OMAP3: serial - allow platforms specify which UARTs to initialize
Mike Rapoport (2):
omap2: mux: intoduce omap_mux_{read,write}
omap3: cm-t35: add mux initialization
Paul Walmsley (19):
OMAP1/2/3 clock: remove paranoid checks in preparation for
clock{,2xxx,3xxx}_data.c
OMAP2 clock: APLL code shouldn't rely on static clocks in its local
namespace
OMAP2/3: move SDRC macros to mach-omap2/sdrc.h
OMAP2xxx clock: remove implicit dependency between rate CPU flag and
clkdev_omap CPU flag
OMAP3 clock: convert clock34xx.h to clock34xx_data.c
OMAP2 clock: convert clock24xx.h to clock2xxx_data.c, opp2xxx*
OMAP1 clock: convert test in disable_unused() to use ENABLE_ON_INIT
OMAP1 clock: convert mach-omap1/clock.h to mach-omap1/clock_data.c
OMAP2/3 PRCM: don't export prm_*(), cm_*() functions
OMAP clockdomain/powerdomain: remove CONFIG_OMAP_DEBUG_{CLOCK,POWER}DOMAIN
OMAP clockdomain/powerdomain: optimize out sleepdep code on OMAP24xx
OMAP powerdomain/PM: use symbolic constants for the max number of power
states
OMAP powerdomain: rearrange struct powerdomain to save some memory
OMAP3: SDRC: Place SDRC AC timing and MR changes in CORE DVFS SRAM code
behind Kconfig
OMAP clock/hwmod: fix off-by-one errors
OMAP3 hwmod: reprogram OCP_SYSCONFIG register after setting SOFTRESET
OMAP3 hwmod: Add automatic OCP_SYSCONFIG AUTOIDLE handling
OMAP hwmod: add names to module MPU IRQ lines
OMAP3 hwmod: drop most of the OCP_SYSCONFIG.CLOCKACTIVITY code
Rajendra Nayak (11):
ARM: OMAP4: PM: Fix the PRM and CM base addresses
ARM: OMAP4: PM: PRM/CM module offsets for OMAP4
ARM: OMAP4: PM: Adds CM1/2 register defs for OMAP4
ARM: OMAP4: PM: Adds PRM register defs for OMAP4
ARM: OMAP4: PM: Adds PRM register shift and mask bits
ARM: OMAP4: PM: Adds CM1/2 register field masks
ARM: OMAP4: PM: OMAP4 clock tree and clkdev registration
ARM: OMAP4: PM: Add dummy hooks for OMAP4 dpll api's
ARM: OMAP4: PM: Move DPLL control apis to dpll.c
ARM: OMAP4: PM: Add support for OMAP4 dpll api's
ARM: OMAP4: PM: Add init api for DPLL nodes
Roel Kluin (1):
OMAP2/3 powerdomain: return errors rather than returning the output of
IS_ERR()
Sanjeev Premi (1):
omap3: Fix OMAP35XX_REV macros
Santosh Shilimkar (5):
OMAP4: Fix cpu detection
OMAP4: Fix SRAM base and size
OMAP4: AuxCoreBoot registers only accessible in secure mode
OMAP4: Remove the secondary wait loop
OMAP4: Sync up omap4430 defconfig
Sergey Lapin (1):
omap3: id code detection 3525 vs 3515
Thara Gopinath (1):
OMAP3: PM: Fix for MPU power domain MEM BANK position
Tony Lindgren (10):
Merge branch 'for_2_6_33' of git://git.pwsan.com/linux-2.6 into
omap-for-
