Re: mmci-omap regressions
2009/1/12 Ladislav Michl la...@linux-mips.org:
Last time I used MMC card with linux-2.6.15-omap2 and it worked pretty well on
my custom 5910 based board. Current git nor linux-2.6.22-omap1 (currently used
for production) doesn't work at all. Inspecting diff between 2.6.15-omap2 and
2.6.22-omap1 showed that
--- a/drivers/mmc/host/omap.c 2009-01-12 09:32:23.0 +0100
+++ b/drivers/mmc/host/omap.c 2009-01-12 09:46:26.0 +0100
@@ -974,7 +974,7 @@
* Writing to the CON register twice seems to do the trick. */
for (i = 0; i 2; i++)
OMAP_MMC_WRITE(host, CON, dsor);
- if (ios-power_mode == MMC_POWER_ON) {
+ if (ios-power_mode == MMC_POWER_UP) {
/* Send clock cycles, poll completion */
OMAP_MMC_WRITE(host, IE, 0);
OMAP_MMC_WRITE(host, STAT, 0x);
did the trick.
Just confirming that I had the same issue on Palm T|E (omap15xx) and
used a similar modification to make it work. This was with 2.6.22 so
very long ago.
Cheers
--
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 12/33] Add tsc2005 touchscreen driver
2008/8/30 Felipe Balbi [EMAIL PROTECTED]: From: Felipe Balbi [EMAIL PROTECTED] Signed-off-by: Felipe Balbi [EMAIL PROTECTED] --- drivers/input/touchscreen/Kconfig |5 + drivers/input/touchscreen/Makefile |1 + drivers/input/touchscreen/tsc2005.c | 736 +++ include/linux/spi/tsc2005.h | 29 ++ 4 files changed, 771 insertions(+), 0 deletions(-) create mode 100644 drivers/input/touchscreen/tsc2005.c create mode 100644 include/linux/spi/tsc2005.h diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig index 25287e8..a115f38 100644 --- a/drivers/input/touchscreen/Kconfig +++ b/drivers/input/touchscreen/Kconfig @@ -217,6 +217,11 @@ config TOUCHSCREEN_ATMEL_TSADCC To compile this driver as a module, choose M here: the module will be called atmel_tsadcc. +config TOUCHSCREEN_TSC2005 + tristate TSC2005 touchscreen support + help + Say Y here for if you are using the touchscreen features of TSC2301. + config TOUCHSCREEN_UCB1400 tristate Philips UCB1400 touchscreen select AC97_BUS diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile index 15cf290..0342389 100644 --- a/drivers/input/touchscreen/Makefile +++ b/drivers/input/touchscreen/Makefile @@ -26,6 +26,7 @@ obj-$(CONFIG_TOUCHSCREEN_TOUCHIT213) += touchit213.o obj-$(CONFIG_TOUCHSCREEN_TOUCHRIGHT) += touchright.o obj-$(CONFIG_TOUCHSCREEN_TOUCHWIN) += touchwin.o obj-$(CONFIG_TOUCHSCREEN_UCB1400) += ucb1400_ts.o +obj-$(CONFIG_TOUCHSCREEN_TSC2005) += tsc2005.o obj-$(CONFIG_TOUCHSCREEN_WM97XX) += wm97xx-ts.o wm97xx-ts-$(CONFIG_TOUCHSCREEN_WM9705) += wm9705.o wm97xx-ts-$(CONFIG_TOUCHSCREEN_WM9712) += wm9712.o diff --git a/drivers/input/touchscreen/tsc2005.c b/drivers/input/touchscreen/tsc2005.c new file mode 100644 index 000..7fb107e --- /dev/null +++ b/drivers/input/touchscreen/tsc2005.c @@ -0,0 +1,736 @@ +/* + * TSC2005 touchscreen driver + * + * Copyright (C) 2006-2008 Nokia Corporation + * + * Author: Lauri Leukkunen [EMAIL PROTECTED] + * based on TSC2301 driver by Klaus K. Pedersen [EMAIL PROTECTED] + * + * 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 linux/kernel.h +#include linux/module.h +#include linux/input.h +#include linux/interrupt.h +#include linux/delay.h +#include linux/spi/spi.h + +#ifdef CONFIG_ARCH_OMAP +#include mach/gpio.h +#endif + +#include linux/spi/tsc2005.h + +/** + * The touchscreen interface operates as follows: + * + * Initialize: + *Request access to GPIO103 (DAV) + *tsc2005_dav_irq_handler will trigger when DAV line goes down + * + * 1) Pen is pressed against touchscreeen + * 2) TSC2005 performs AD conversion + * 3) After the conversion is done TSC2005 drives DAV line down + * 4) GPIO IRQ is received and tsc2005_dav_irq_handler is called + * 5) tsc2005_ts_irq_handler queues up an spi transfer to fetch + * the x, y, z1, z2 values + * 6) tsc2005_ts_rx() reports coordinates to input layer and + * sets up tsc2005_ts_timer() to be called after TSC2005_TS_SCAN_TIME + * 7) When the penup_timer expires, there have not been DAV interrupts + * during the last 20ms which means the pen has been lifted. + */ + +#define TSC2005_VDD_LOWER_27 + +#ifdef TSC2005_VDD_LOWER_27 +#define TSC2005_HZ (1000) +#else +#define TSC2005_HZ (2500) +#endif + +#define TSC2005_CMD(0x80) +#define TSC2005_REG(0x00) + +#define TSC2005_CMD_STOP (1) +#define TSC2005_CMD_10BIT (0 2) +#define TSC2005_CMD_12BIT (1 2) + +#define TSC2005_CMD_SCAN_XYZZ (0 3) +#define TSC2005_CMD_SCAN_XY(1 3) +#define TSC2005_CMD_SCAN_X (2 3) +#define TSC2005_CMD_SCAN_Y (3 3) +#define TSC2005_CMD_SCAN_ZZ(4 3) +#define TSC2005_CMD_AUX_SINGLE (5 3) +#define TSC2005_CMD_TEMP1 (6 3) +#define TSC2005_CMD_TEMP2 (7 3) +#define TSC2005_CMD_AUX_CONT (8 3) +#define TSC2005_CMD_TEST_X_CONN(9 3) +#define TSC2005_CMD_TEST_Y_CONN(10 3) +/* command 11 reserved */ +#define TSC2005_CMD_TEST_SHORT (12 3) +#define TSC2005_CMD_DRIVE_XX (13 3) +#define TSC2005_CMD_DRIVE_YY (14
Re: [PATCH 00/34] omap drivers going upstream
2008/9/1 Felipe Balbi [EMAIL PROTECTED]:
On Sat, Aug 30, 2008 at 08:16:00PM +0300, Felipe Balbi wrote:
From: Felipe Balbi [EMAIL PROTECTED]
The following drivers are going upstream for integration.
They have been sitting on linux-omap for quite a while just
increasing the diff against mainline and probability of
merge conflicts.
Just one comment to this. I had to left bluetooth driver out of the
series because it's using omap2_block/allow_sleep in the driver code.
That should be fixed and the set_clock function should come via
platform_data to the driver.
53 static void hci_h4p_set_clk(struct hci_h4p_info *info, int *clock, int
enable)
54 {
55 unsigned long flags;
56
57 spin_lock_irqsave(info-clocks_lock, flags);
58 if (enable !*clock) {
59 NBT_DBG_POWER(Enabling %p\n, clock);
60 clk_enable(info-uart_fclk);
61 #ifdef CONFIG_ARCH_OMAP2
62 if (cpu_is_omap24xx()) {
63 clk_enable(info-uart_iclk);
64 omap2_block_sleep();
65 }
66 #endif
67 }
68 if (!enable *clock) {
69 NBT_DBG_POWER(Disabling %p\n, clock);
70 clk_disable(info-uart_fclk);
71 #ifdef CONFIG_ARCH_OMAP2
72 if (cpu_is_omap24xx()) {
73 clk_disable(info-uart_iclk);
74 omap2_allow_sleep();
75 }
76 #endif
77 }
78
79 *clock = enable;
80 spin_unlock_irqrestore(info-clocks_lock, flags);
81 }
That driver is full of arch specific code and should be cleaned up ASAP.
A few things I could get by briefly looking at the driver (actualy only
drivers/bluetooth/hci_h4p/core.c):
There's also a curious issue in hci_h4p_interrupt I hit recently but
after looking at the rest of the driver thought it was beating a dead
horse..., but just in case it isn't:
the driver assumes the OMAP UART, but then it uses UART_IIR_ID which
is only valid for standard UARTs, causing OMAP-specific Rx errors to
be ignored silently. Turns out that on my N810 there are actually Rx
errors reported during firmware upload, but I didn't find a better way
to handle them than to ignore them:
--- a/drivers/bluetooth/hci_h4p/core.c
+++ b/drivers/bluetooth/hci_h4p/core.c
@@ -482,7 +491,14 @@ static irqreturn_t hci_h4p_interrupt(int irq, void *data)
NBT_DBG(In interrupt handler iir 0x%.2x\n, iir);
- iir = UART_IIR_ID;
+ iir = 0x1e; /* OMAP UART has wider INT than UART_IIR_ID */
+
+ /*
+* Often Rx errors are reported but reading the receive buffer
+* gives the correct data, so treat it as an Rx interrupt.
+*/
+ if (iir == 0xc)
+ iir = 0x4;
if (iir == UART_IIR_MSI) {
msr = hci_h4p_inb(info, UART_MSR);
The tsc210x drivers should be upstreamable with the exception of ALSA
code which needs to be converted to ASoC. Maruk Vasut found a leak in
one error path, but I can't charge the device that has the tsc2102
that I used for testing.
I have some improvements to drivers/net/irda/omap-ir.c (clean-up and
removing OMAP16xx specific bits to support OMAP1) but again, have no
charger for the device.
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: [PATCH 00/34] omap drivers going upstream
2008/8/30 Felipe Balbi [EMAIL PROTECTED]: snim Add omap touchscreen driver This is just a tsc2101 touchscreen + pin multiplexing, I'm not really sure it should be upstream (but don't drop it without someone who knows commenting). I think someone even experimented with using a tsc2101 driver on the Hx board, but I may be wrong. Regards -- 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/4] OMAP: MENELAUS: Improvements on menelaus
Hi, 2008/7/29 Felipe Balbi [EMAIL PROTECTED]: On Tue, Jul 29, 2008 at 12:44:19PM -0400, Carlos Aguiar wrote: Hi Tony and folks, This patch series proposes some improvements on menelaus code. Basically it makes menelaus to use macros instead of some magic constant numbers, making menelaus code more legible. The menelaus header was moved to include/linux/i2c and register map (including the macros created) were moved to include/linux/i2c/menelaus.h Tested with MMC on N800 and looks fine. They look quite ok. How about syncing l-o menelaus with mainline via lm-sensors mailing list and discuss all these there as well ?? How about renaming it to twl92230c before submitting upstream? As far as I can tell the name menelaus appears only in linux and makes it hard to associate with the real hardware. Does someone know why was it renamed that way? Regards -- 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: [RESEND][PATCH]Separate out 3430 LCD panel support from 2430 file
2008/7/2 [EMAIL PROTECTED]:
From: Iqbal Shareef [EMAIL PROTECTED]
Separate out 3430 LCD panel support from 2430 SDP.
Currently the support for the LCD on 3430SDP is added in the lcd_2430sdp.c
file. This patch separates it out to a new file.
Isn't this a bit step backwards? Code reuse is generally a good thing
if it doesn't clutter the code too much, and if you do diff -pNaur
lcd_2430sdp.c lcd_3430sdp.c in the current tree you will see that they
are very similar.
Additionally this patch leaves some of the 3430SDP code in
lcd_2430sdp.c, you will still find this:
#define SDP3430_LCD_PANEL_BACKLIGHT_GPIO24
#define SDP3430_LCD_PANEL_ENABLE_GPIO 28
...
if (machine_is_omap_3430sdp()) {
enable_gpio= SDP3430_LCD_PANEL_ENABLE_GPIO;
backlight_gpio = SDP3430_LCD_PANEL_BACKLIGHT_GPIO;
} else {
enable_gpio= SDP2430_LCD_PANEL_ENABLE_GPIO;
backlight_gpio = SDP2430_LCD_PANEL_BACKLIGHT_GPIO;
}
...
if (machine_is_omap_3430sdp()) {
ded_reg = TWL4030_VAUX3_DEDICATED;
ded_val = ENABLE_VAUX3_DEDICATED;
grp_reg = TWL4030_VAUX3_DEV_GRP;
grp_val = ENABLE_VAUX3_DEV_GRP;
} else {
ded_reg = TWL4030_VAUX2_DEDICATED;
ded_val = ENABLE_VAUX2_DEDICATED;
grp_reg = TWL4030_VAUX2_DEV_GRP;
grp_val = ENABLE_VAUX2_DEV_GRP;
}
Another thing that isn't explained is why the GPIO numbers for
backlight and enable changed from 24 and 28 to 8 and 5.
Regards,
Andrew
--
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: [RFC][PATCH] usb: musb: pass configuration specifics via pdata
2008/6/30 David Brownell [EMAIL PROTECTED]: On Monday 30 June 2008, Felipe Balbi wrote: The patch won't probe. But if you just copy what's added in board-omap3430sdp.c should work. Better: that controller data should be provided by SOC glue in those cases (omap2430, omap 3*, DaVinci, etc). If it's not board-specific, it doesn't belong in board-specific glue.. Yep, I believe same applies to devices with the TUSB6010 - musb-hdrc parameters are TUSB6010 specific and not board specific. Regards -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] MACH-OMAP1: MCBSP: Add support for mcbsp on mach-omap1
Hiya,
On 29/05/2008, Eduardo Valentin [EMAIL PROTECTED] wrote:
+static struct omap_mcbsp_platform_data omap1_mcbsp_pdata[] = {
+#ifdef CONFIG_ARCH_OMAP730
+ {
+ .virt_base = io_p2v(OMAP730_MCBSP1_BASE),
+ .dma_rx_sync= OMAP_DMA_MCBSP1_RX,
+ .dma_tx_sync= OMAP_DMA_MCBSP1_TX,
+ .rx_irq = INT_730_McBSP1RX,
+ .tx_irq = INT_730_McBSP1TX,
+ .ops= omap1_mcbsp_ops,
+ },
+ {
+ .virt_base = io_p2v(OMAP730_MCBSP2_BASE),
+ .dma_rx_sync= OMAP_DMA_MCBSP3_RX,
+ .dma_tx_sync= OMAP_DMA_MCBSP3_TX,
+ .rx_irq = INT_730_McBSP2RX,
+ .tx_irq = INT_730_McBSP2TX
+ .ops= omap1_mcbsp_ops,
+ },
+#endif
+#ifdef CONFIG_ARCH_OMAP15XX
+ {
+ .virt_base = OMAP1510_MCBSP1_BASE,
+ .dma_rx_sync= OMAP_DMA_MCBSP1_RX,
+ .dma_tx_sync= OMAP_DMA_MCBSP1_TX,
+ .rx_irq = INT_McBSP1RX,
+ .tx_irq = INT_McBSP1TX,
+ .ops= omap1_mcbsp_ops,
+ .clk_name = mcbsp_clk,
+ },
+ {
+ .virt_base = io_p2v(OMAP1510_MCBSP2_BASE),
+ .dma_rx_sync= OMAP_DMA_MCBSP2_RX,
+ .dma_tx_sync= OMAP_DMA_MCBSP2_TX,
+ .rx_irq = INT_1510_SPI_RX,
+ .tx_irq = INT_1510_SPI_TX,
+ .ops= omap1_mcbsp_ops,
+ },
+ {
+ .virt_base = OMAP1510_MCBSP3_BASE,
+ .dma_rx_sync= OMAP_DMA_MCBSP3_RX,
+ .dma_tx_sync= OMAP_DMA_MCBSP3_TX,
+ .rx_irq = INT_McBSP3RX,
+ .tx_irq = INT_McBSP3TX,
+ .ops= omap1_mcbsp_ops,
+ .clk_name = mcbsp_clk,
+ },
+#endif
+#ifdef CONFIG_ARCH_OMAP16XX
+ {
+ .virt_base = OMAP1610_MCBSP1_BASE,
+ .dma_rx_sync= OMAP_DMA_MCBSP1_RX,
+ .dma_tx_sync= OMAP_DMA_MCBSP1_TX,
+ .rx_irq = INT_McBSP1RX,
+ .tx_irq = INT_McBSP1TX,
+ .ops= omap1_mcbsp_ops,
+ .clk_name = mcbsp_clk,
+ },
+ {
+ .virt_base = io_p2v(OMAP1610_MCBSP2_BASE),
+ .dma_rx_sync= OMAP_DMA_MCBSP2_RX,
+ .dma_tx_sync= OMAP_DMA_MCBSP2_TX,
+ .rx_irq = INT_1610_McBSP2_RX,
+ .tx_irq = INT_1610_McBSP2_TX,
+ .ops= omap1_mcbsp_ops,
+ },
+ {
+ .virt_base = OMAP1610_MCBSP3_BASE,
+ .dma_rx_sync= OMAP_DMA_MCBSP3_RX,
+ .dma_tx_sync= OMAP_DMA_MCBSP3_TX,
+ .rx_irq = INT_McBSP3RX,
+ .tx_irq = INT_McBSP3TX,
+ .ops= omap1_mcbsp_ops,
+ .clk_name = mcbsp_clk,
+ },
+#endif
+};
I think you need a runtime omap model check here. Otherwise if you
have all three models enabled in the config (I don't remember if that
is supported but that's not the point) you'll get eight
platform_devices. That will not Oops because there's a sanity check
in omap_mcbsp_register_board_cfg() but only the first three will get
registered.
There is a runtime check in the original version.
Same applies to PATCH 5/5 for omap2.
Cheers,
Andrew
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] N810: Don't export camera orientation
On 15/05/2008, Felipe Balbi [EMAIL PROTECTED] wrote:
On Wed, May 14, 2008 at 03:04:37PM +0300, Sakari Ailus wrote:
ext Felipe Balbi wrote:
Hello Felipe, and thanks for reviewing the patch! :)
On Tue, 13 May 2008 19:04:22 +0300, Sakari Ailus [EMAIL PROTECTED]
wrote:
@@ -298,12 +340,21 @@ static int tcm825x_ifparm(struct v4l2_ifparm *p)
return 0;
}
+static int tcm825x_is_upside_down(void)
+{
+ if (machine_is_nokia_n810())
+ return 1;
+
+ return 0;
+}
+
const struct tcm825x_platform_data n800_tcm825x_platform_data = {
- .is_okay = tcm825x_is_okay,
- .power_set= tcm825x_power_set,
- .default_regs = tcm825x_default_regs,
- .needs_reset = tcm825x_needs_reset,
- .ifparm = tcm825x_ifparm,
+ .is_okay= tcm825x_is_okay,
+ .power_set = tcm825x_power_set,
+ .default_regs = tcm825x_default_regs,
+ .needs_reset= tcm825x_needs_reset,
+ .ifparm = tcm825x_ifparm,
+ .is_upside_down = tcm825x_is_upside_down,
ok, now i got your point but this could be:
.is_upside_down = machine_is_nokia_n810() ? 1 : 0,
This doesn't work because machine_is_nokia_n810() is not constant.
Anyway, tcm825x_is_upside_down can be made more simple as it could just
return machine_is_nokia_n810().
I'll send new patches.
Didn't quite get, machine_is_nokia_n810() will always be true when
running in n810. Could you clarify a bit :-p
It'll *return* true, but C initialisers must be constants. It simply
wouldn't compile.
Cheers
--
Please do not print this email unless absolutely necessary. Spread
environmental awareness.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] N810: Don't export camera orientation
On 15/05/2008, Felipe Balbi [EMAIL PROTECTED] wrote:
On Thu, May 15, 2008 at 08:54:34AM +0200, andrzej zaborowski wrote:
On 15/05/2008, Felipe Balbi [EMAIL PROTECTED] wrote:
On Wed, May 14, 2008 at 03:04:37PM +0300, Sakari Ailus wrote:
ext Felipe Balbi wrote:
Hello Felipe, and thanks for reviewing the patch! :)
On Tue, 13 May 2008 19:04:22 +0300, Sakari Ailus [EMAIL PROTECTED]
wrote:
@@ -298,12 +340,21 @@ static int tcm825x_ifparm(struct v4l2_ifparm
*p)
return 0;
}
+static int tcm825x_is_upside_down(void)
+{
+ if (machine_is_nokia_n810())
+ return 1;
+
+ return 0;
+}
+
const struct tcm825x_platform_data n800_tcm825x_platform_data = {
- .is_okay = tcm825x_is_okay,
- .power_set= tcm825x_power_set,
- .default_regs = tcm825x_default_regs,
- .needs_reset = tcm825x_needs_reset,
- .ifparm = tcm825x_ifparm,
+ .is_okay= tcm825x_is_okay,
+ .power_set = tcm825x_power_set,
+ .default_regs = tcm825x_default_regs,
+ .needs_reset= tcm825x_needs_reset,
+ .ifparm = tcm825x_ifparm,
+ .is_upside_down = tcm825x_is_upside_down,
ok, now i got your point but this could be:
.is_upside_down = machine_is_nokia_n810() ? 1 : 0,
This doesn't work because machine_is_nokia_n810() is not constant.
Anyway, tcm825x_is_upside_down can be made more simple as it could
just
return machine_is_nokia_n810().
I'll send new patches.
Didn't quite get, machine_is_nokia_n810() will always be true when
running in n810. Could you clarify a bit :-p
It'll *return* true, but C initialisers must be constants. It simply
wouldn't compile.
and that's why i was using ?:
machine_is_nokia_n810 ? 1 : 0
This doesn't change anything - since machine_is_... is not constant,
the whole expression is not constant and is a syntax error. The
compiler needs to know at compile time whether to store a 0 or a 1 in
the initialiser.
--
Please do not print this email unless absolutely necessary. Spread
environmental awareness.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Input: Make lm8323 sticky key to work with console
On 15/05/2008, Felipe Balbi [EMAIL PROTECTED] wrote: On Wed, May 14, 2008 at 09:01:19PM -0700, Tony Lindgren wrote: This allows using N810 keyboard from console by adding optional Fn and shift sticky key handling by passing them from platform_data. Currently some not so obvious mappings are: - Pipe is Fn + Enter - Delete is Fn + Backspace - Escape is Fn + Ctrl no tab? :-( Fn + space maybe?? :-p Fn + Right is assigned in the patch (I check too :) ). But I'm not sure whther that should be done in the lm8323 driver or elsewhere. The existence of keys like Fn and Shift is N810-specific and lm8323 is just a gpio matrix keypad chip. Regards -- Please do not print this email unless absolutely necessary. Spread environmental awareness. -- 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] MUSB: misc clean-up.
Correct the interrupt mask in TUSB6010 and other nit-picking from my tree.
Signed-off-by: Andrzej Zaborowski [EMAIL PROTECTED]
---
drivers/usb/musb/musb_host.c |2 +-
drivers/usb/musb/musb_procfs.c |2 +-
drivers/usb/musb/tusb6010.c |6 +++---
drivers/usb/musb/tusb6010_omap.c |2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 64673b7..e9c766f 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -1203,7 +1203,7 @@ void musb_host_tx(struct musb *musb, u8 epnum)
* we have a candidate... NAKing is *NOT* an error
*/
musb_ep_select(mbase, epnum);
- musb_writew(epio, MUSB_CSR0,
+ musb_writew(epio, MUSB_TXCSR,
MUSB_TXCSR_H_WZC_BITS
| MUSB_TXCSR_TXPKTRDY);
goto finish;
diff --git a/drivers/usb/musb/musb_procfs.c b/drivers/usb/musb/musb_procfs.c
index e6e050c..da683eb 100644
--- a/drivers/usb/musb/musb_procfs.c
+++ b/drivers/usb/musb/musb_procfs.c
@@ -453,7 +453,7 @@ dump_end_info(struct musb *musb, u8 epnum, char *aBuffer,
unsigned max)
/* Dump the current status and compile options.
* @param musb the device driver instance
- * @param buffer where to dump the status; it must be big enough hold the
+ * @param buffer where to dump the status; it must be big enough to hold the
* result otherwise BAD THINGS HAPPENS(TM).
*/
static int dump_header_stats(struct musb *musb, char *buffer)
diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
index bed2e18..1f3643b 100644
--- a/drivers/usb/musb/tusb6010.c
+++ b/drivers/usb/musb/tusb6010.c
@@ -740,7 +740,7 @@ tusb_otg_ints(struct musb *musb, u32 int_src, void __iomem
*tbase)
break;
case OTG_STATE_A_WAIT_VFALL:
/* REVISIT this irq triggers during short
-* spikes causet by enumeration ...
+* spikes caused by enumeration ...
*/
if (musb-vbuserr_retry) {
musb-vbuserr_retry--;
@@ -888,7 +888,7 @@ static irqreturn_t tusb_interrupt(int irq, void *__hci)
musb_writel(tbase, TUSB_DMA_INT_CLEAR, dma_src);
}
- /* EP interrupts. In OCP mode tusb6010 mirrors the MUSB * interrupts */
+ /* EP interrupts. In OCP mode tusb6010 mirrors the MUSB interrupts */
if (int_src (TUSB_INT_SRC_USB_IP_TX | TUSB_INT_SRC_USB_IP_RX)) {
u32 musb_src = musb_readl(tbase, TUSB_USBIP_INT_SRC);
@@ -972,7 +972,7 @@ void musb_platform_disable(struct musb *musb)
/* disable all IRQs */
musb_writel(tbase, TUSB_INT_MASK, ~TUSB_INT_MASK_RESERVED_BITS);
- musb_writel(tbase, TUSB_USBIP_INT_MASK, 0);
+ musb_writel(tbase, TUSB_USBIP_INT_MASK, 0x7fff);
musb_writel(tbase, TUSB_DMA_INT_MASK, 0x7fff);
musb_writel(tbase, TUSB_GPIO_INT_MASK, 0x1ff);
diff --git a/drivers/usb/musb/tusb6010_omap.c b/drivers/usb/musb/tusb6010_omap.c
index 66e146e..f7a3ffe 100644
--- a/drivers/usb/musb/tusb6010_omap.c
+++ b/drivers/usb/musb/tusb6010_omap.c
@@ -188,7 +188,7 @@ static void tusb_omap_dma_cb(int lch, u16 ch_status, void
*data)
channel-status = MUSB_DMA_STATUS_FREE;
- /* Handle only RX callbacks here. TX callbacks musb be handled based
+ /* Handle only RX callbacks here. TX callbacks must be handled based
* on the TUSB DMA status interrupt.
* REVISIT: Use both TUSB DMA status interrupt and OMAP DMA callback
* interrupt for RX and TX.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] I2C: LM8323: Introduce lm8323 keypad driver
Hi,
On 09/04/2008, Felipe Balbi [EMAIL PROTECTED] wrote:
On Wed, Apr 09, 2008 at 03:04:00PM +0300, Felipe Balbi wrote:
+static unsigned short normal_i2c[] =
+{
+ LM8323_I2C_ADDR00, LM8323_I2C_ADDR01,
+ LM8323_I2C_ADDR10, LM8323_I2C_ADDR11,
+ I2C_CLIENT_END
+};
+
+I2C_CLIENT_INSMOD;
This was garbage, already remove in this version below.
From 3bab182ebe0f922773e62bf6915a8bef1222cec0 Mon Sep 17 00:00:00 2001
From: Daniel Stone [EMAIL PROTECTED]
Date: Mon, 7 Apr 2008 17:07:37 +0300
Subject: [PATCH 1/5] I2C: LM8323: Introduce lm8323 keypad driver
Introduce lm8323 keypad driver.
Signed-off-by: Daniel Stone [EMAIL PROTECTED]
Updated to build with recent linux-omap and new-style
i2c driver.
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-n800.c | 77
arch/arm/mach-omap2/board-n810.c |2 +
drivers/input/keyboard/Kconfig |7 +
drivers/input/keyboard/Makefile |1 +
drivers/input/keyboard/lm8323.c | 911
++
include/linux/i2c/lm8323.h | 39 ++
6 files changed, 1037 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/keyboard/lm8323.c
create mode 100644 include/linux/i2c/lm8323.h
diff --git a/arch/arm/mach-omap2/board-n800.c
b/arch/arm/mach-omap2/board-n800.c
index 758e2c1..367e518 100644
--- a/arch/arm/mach-omap2/board-n800.c
+++ b/arch/arm/mach-omap2/board-n800.c
@@ -23,6 +23,7 @@
#include linux/interrupt.h
#include linux/irq.h
#include linux/i2c.h
+#include linux/i2c/lm8323.h
#include asm/hardware.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -48,6 +49,76 @@
#define N800_DAV_IRQ_GPIO 103
#define N800_TSC2301_RESET_GPIO118
+#ifdef CONFIG_MACH_NOKIA_N810
+static s16 rx44_keymap[LM8323_KEYMAP_SIZE] = {
+ [0x01] = KEY_Q,
+ [0x02] = KEY_K,
+ [0x03] = KEY_O,
+ [0x04] = KEY_P,
+ [0x05] = KEY_BACKSPACE,
+ [0x06] = KEY_A,
+ [0x07] = KEY_S,
+ [0x08] = KEY_D,
+ [0x09] = KEY_F,
+ [0x0a] = KEY_G,
+ [0x0b] = KEY_H,
+ [0x0c] = KEY_J,
+
+ [0x11] = KEY_W,
+ [0x12] = KEY_F4,
+ [0x13] = KEY_L,
+ [0x14] = KEY_APOSTROPHE,
+ [0x16] = KEY_Z,
+ [0x17] = KEY_X,
+ [0x18] = KEY_C,
+ [0x19] = KEY_V,
+ [0x1a] = KEY_B,
+ [0x1b] = KEY_N,
+ [0x1c] = KEY_LEFTSHIFT, /* Actually, this is both shift keys */
+ [0x1f] = KEY_F7,
+
+ [0x21] = KEY_E,
+ [0x22] = KEY_SEMICOLON,
+ [0x23] = KEY_MINUS,
+ [0x24] = KEY_EQUAL,
+ [0x2b] = KEY_FN,
+ [0x2c] = KEY_M,
+ [0x2f] = KEY_F8,
+
+ [0x31] = KEY_R,
+ [0x32] = KEY_RIGHTCTRL,
+ [0x34] = KEY_SPACE,
+ [0x35] = KEY_COMMA,
+ [0x37] = KEY_UP,
+ [0x3c] = KEY_COMPOSE,
+ [0x3f] = KEY_F6,
+
+ [0x41] = KEY_T,
+ [0x44] = KEY_DOT,
+ [0x46] = KEY_RIGHT,
+ [0x4f] = KEY_F5,
+ [0x51] = KEY_Y,
+ [0x53] = KEY_DOWN,
+ [0x55] = KEY_ENTER,
+ [0x5f] = KEY_ESC,
+
+ [0x61] = KEY_U,
+ [0x64] = KEY_LEFT,
+
+ [0x71] = KEY_I,
+ [0x75] = KEY_KPENTER,
+};
+
+static struct lm8323_platform_data lm8323_pdata = {
+ .repeat = 0, /* Repeat is handled in userspace for now. */
+ .keymap = rx44_keymap,
+
+ .name = Internal keyboard,
+ .pwm1_name = keyboard,
+ .pwm2_name = cover,
+};
+#endif
+
void __init nokia_n800_init_irq(void)
{
omap2_init_common_hw();
@@ -502,6 +573,12 @@ static struct i2c_board_info __initdata
n800_i2c_board_info_2[] = {
I2C_BOARD_INFO(tea5761, 0x10),
},
#endif
+ {
+ I2C_BOARD_INFO(lm8323, 0x45),
+ .type = lm8323,
+ .irq= OMAP_GPIO_IRQ(109),
+ .platform_data = lm8323_pdata,
+ },
};
void __init nokia_n800_common_init(void)
diff --git a/arch/arm/mach-omap2/board-n810.c
b/arch/arm/mach-omap2/board-n810.c
index c4f4dd5..fb0e61f 100644
--- a/arch/arm/mach-omap2/board-n810.c
+++ b/arch/arm/mach-omap2/board-n810.c
@@ -10,6 +10,8 @@
*/
#include linux/init.h
+#include linux/i2c.h
+#include linux/i2c/lm8323.h
#include asm/hardware.h
#include asm/mach-types.h
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 1c22930..137f7e4 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -285,6 +285,13 @@ config KEYBOARD_TSC2301
help
Say Y here for if you are using the keypad features of TSC2301.
+config KEYBOARD_LM8323
+ tristate LM8323 keypad chip
+ depends on I2C
+ help
+ If you say yes here you get
Re: [PATCH 1/5] I2C: LM8323: Introduce lm8323 keypad driver
Hi, On 09/04/2008, Lauri Leukkunen [EMAIL PROTECTED] wrote: On 09/04/08 21:05 +0300, ext Felipe Balbi wrote: On Wed, Apr 09, 2008 at 07:26:31PM +0200, andrzej zaborowski wrote: Question not really related to this patchset, but in the TSC2005 driver some averaging and limit checks are done to the ADC values. Shouldn't that be done in userspace instead? (The ADS784x and TSC2301 drivers do the same evidently.) Now that's not really up to me, but if we move it now it probably won't provide the feature n810 needs. I mean, n810 is designed on top of the features provided by driver, the application probably expects the driver to do the averaging and limit checks so at least for tsc2005 I think it's not a good idea to change due to application requirements. User-space is too late for this filtering, we would end up feeding ~1k samples per second there, and that would simply clog the system pretty badly, can't do much buffering either as that degrades interactive responsiveness of the UI. That's true, that'd send to userspace the amount of data multiplied by the number of samples over which the averaging is done. I don't know how significant amount that would be. In my opinion kernel should provide correct data to user-space, not some pseudo-random interference from the LCD. I think this is discutible. There's a number of userspace libraries written to talk tightly to the kernel and make that data more correct, one of them is tslib. Distros that come with tslib often have a set of device-specific config files for tslib which load tslib plugins for things like averaging, smoothing, checking bounds on the values. One of the arguments for doing that in userspace is that of avoiding every touchscreen driver redoing the same averaging and/or limit checking code. I agree thought that it may be better to sacrifice that for performance. Cheers -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] I2C: LM8323: Introduce lm8323 keypad driver
On 10/04/2008, Daniel Stone [EMAIL PROTECTED] wrote: On Thu, Apr 10, 2008 at 01:58:51AM +0200, ext andrzej zaborowski wrote: On 09/04/2008, Lauri Leukkunen [EMAIL PROTECTED] wrote: In my opinion kernel should provide correct data to user-space, not some pseudo-random interference from the LCD. I think this is discutible. There's a number of userspace libraries written to talk tightly to the kernel and make that data more correct, one of them is tslib. Distros that come with tslib often have a set of device-specific config files for tslib which load tslib plugins for things like averaging, smoothing, checking bounds on the values. One of the arguments for doing that in userspace is that of avoiding every touchscreen driver redoing the same averaging and/or limit checking code. I agree thought that it may be better to sacrifice that for performance. If everyone's doing the same thing, move it to drivers/input/, not to userspace. Why should we be forced to have _two_ drivers and essentially maintain a stable kernel/userspace ABI between them? Surely it's better to only have _one_ hardware-specific driver, rather than half in the kernel, and half hidden behind an abstraction layer that is meant to let you just deal with input events without knowing stupid details about the hardware? For the ease of reconfiguration for one thing, tslib is quite configurable with the plugins loaded by a config file. The ABI you talk about is the same evdev ABI which is already stable. Averaging doesn't just cancel the noise from LCD, just lessens it but there may be better things to do with it and the userspace already knows how to deal with that. So it expects the kernel driver to be more like a ADC driver. Of course doing it in drivers/input/ as configured by board files, would also work if things were designed that way. Cheers -- 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] Stop AIC23 driver from Oopsing.
From: Andrzej Zaborowski [EMAIL PROTECTED]
Prevent AIC23 driver Oopsing when no AIC23 is present by moving some of the
initialisation to after the chip is found. There seems to be more that
should be fixed in this driver but with this change it can at least be
compiled into a kernel safely.
Signed-off-by: Andrzej Zaborowski [EMAIL PROTECTED]
---
drivers/i2c/chips/tlv320aic23.c | 94 --
1 files changed, 49 insertions(+), 45 deletions(-)
diff --git a/drivers/i2c/chips/tlv320aic23.c b/drivers/i2c/chips/tlv320aic23.c
index a2ec4bc..544cc28 100644
--- a/drivers/i2c/chips/tlv320aic23.c
+++ b/drivers/i2c/chips/tlv320aic23.c
@@ -54,6 +54,7 @@ I2C_CLIENT_INSMOD;
static struct i2c_driver aic23_driver;
static struct i2c_client *new_client;
static int selftest;
+static struct platform_device audio_i2c_device;
static struct aic23_info {
u16 volume_reg_left;
@@ -95,6 +96,38 @@ int aic23_write_value(u8 reg, u16 value)
return 0;
}
+/*
+ * Configures the McBSP3 which is used to send clock to the AIC23 codec.
+ * The input clock rate from DSP is 12MHz.
+ * The DSP clock must be on before this is called.
+ */
+static int omap_mcbsp3_aic23_clock_init(void)
+{
+ u16 w;
+
+ /* enable 12MHz clock to mcbsp 1 3 */
+ __raw_writew(__raw_readw(DSP_IDLECT2) | (11), DSP_IDLECT2);
+ __raw_writew(__raw_readw(DSP_RSTCT2) | 1 | 11, DSP_RSTCT2);
+
+ /* disable sample rate generator */
+ OMAP_MCBSP_WRITE(OMAP1610_MCBSP3_BASE, SPCR1, 0x);
+ OMAP_MCBSP_WRITE(OMAP1610_MCBSP3_BASE, SPCR2, 0x);
+
+ /* pin control register */
+ OMAP_MCBSP_WRITE(OMAP1610_MCBSP3_BASE, PCR0,(CLKXM | CLKXP | CLKRP));
+
+ /* configure srg to send 12MHz pulse from dsp peripheral clock */
+ OMAP_MCBSP_WRITE(OMAP1610_MCBSP3_BASE, SRGR1, 0x);
+ OMAP_MCBSP_WRITE(OMAP1610_MCBSP3_BASE, SRGR2, CLKSM);
+
+ /* enable sample rate generator */
+ w = OMAP_MCBSP_READ(OMAP1610_MCBSP3_BASE, SPCR2);
+ OMAP_MCBSP_WRITE(OMAP1610_MCBSP3_BASE, SPCR2, (w | FREE | GRST));
+ printk(Clock enabled to MCBSP1 3 \n);
+
+ return 0;
+}
+
static int aic23_detect_client(struct i2c_adapter *adapter, int address,
int kind)
{
@@ -103,7 +136,7 @@ static int aic23_detect_client(struct i2c_adapter *adapter,
int address,
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_WORD_DATA |
I2C_FUNC_SMBUS_WRITE_BYTE)) {
- printk(KERN_WARNING %s functinality check failed\n,
+ printk(KERN_WARNING %s functionality check failed\n,
client_name);
return err;
}
@@ -128,6 +161,19 @@ static int aic23_detect_client(struct i2c_adapter
*adapter, int address,
kfree(new_client);
return err;
}
+
+ if (platform_device_register(audio_i2c_device)) {
+ printk(KERN_WARNING Failed to register audio i2c device\n);
+ selftest = -ENODEV;
+ return selftest;
+ }
+ /* FIXME: Do in board-specific file */
+ omap_mcbsp3_aic23_clock_init();
+
+ if (!aic23_info_l.power_down)
+ aic23_power_up();
+ aic23_info_l.initialized = 1;
+
return 0;
}
@@ -135,6 +181,8 @@ static int aic23_detach_client(struct i2c_client *client)
{
int err;
+ platform_device_unregister(audio_i2c_device);
+
if ((err = i2c_detach_client(client))) {
printk(aic23.o: Client deregistration failed, \
client not detached.\n);
@@ -162,38 +210,6 @@ static struct i2c_driver aic23_driver = {
.detach_client = aic23_detach_client,
};
-/*
- * Configures the McBSP3 which is used to send clock to the AIC23 codec.
- * The input clock rate from DSP is 12MHz.
- * The DSP clock must be on before this is called.
- */
-static int omap_mcbsp3_aic23_clock_init(void)
-{
- u16 w;
-
- /* enable 12MHz clock to mcbsp 1 3 */
- __raw_writew(__raw_readw(DSP_IDLECT2) | (11), DSP_IDLECT2);
- __raw_writew(__raw_readw(DSP_RSTCT2) | 1 | 11, DSP_RSTCT2);
-
- /* disable sample rate generator */
- OMAP_MCBSP_WRITE(OMAP1610_MCBSP3_BASE, SPCR1, 0x);
- OMAP_MCBSP_WRITE(OMAP1610_MCBSP3_BASE, SPCR2, 0x);
-
- /* pin control register */
- OMAP_MCBSP_WRITE(OMAP1610_MCBSP3_BASE, PCR0,(CLKXM | CLKXP | CLKRP));
-
- /* configure srg to send 12MHz pulse from dsp peripheral clock */
- OMAP_MCBSP_WRITE(OMAP1610_MCBSP3_BASE, SRGR1, 0x);
- OMAP_MCBSP_WRITE(OMAP1610_MCBSP3_BASE, SRGR2, CLKSM);
-
- /* enable sample rate generator */
- w = OMAP_MCBSP_READ(OMAP1610_MCBSP3_BASE, SPCR2);
- OMAP_MCBSP_WRITE(OMAP1610_MCBSP3_BASE, SPCR2, (w | FREE | GRST));
- printk(Clock enabled to MCBSP1 3 \n);
-
- return 0;
-}
-
static void update_volume_left(int volume
Re: [PATCH] Stop AIC23 driver from Oopsing.
On 02/04/2008, Tony Lindgren [EMAIL PROTECTED] wrote: * Andrzej Zaborowski [EMAIL PROTECTED] [080329 18:30]: From: Andrzej Zaborowski [EMAIL PROTECTED] Prevent AIC23 driver Oopsing when no AIC23 is present by moving some of the initialisation to after the chip is found. There seems to be more that should be fixed in this driver but with this change it can at least be compiled into a kernel safely. This does not seem to apply, can you please check? Oops, I had forgotten to update. Now rebased and resent, with an additional typo corrected in one of the error messages. -- Please do not print this email unless absolutely necessary. Spread environmental awareness. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix TUSB6010 ID register offsets.
On 31/03/2008, Felipe Balbi [EMAIL PROTECTED] wrote: On Mon, Mar 31, 2008 at 10:58:11AM +0300, Tony Lindgren wrote: * Andrzej Zaborowski [EMAIL PROTECTED] [080329 18:48]: From: Andrzej Zaborowski [EMAIL PROTECTED] [Sorry, the previous patch was a copy/paste mistake, this one should be better] I have no access to the docs for this chip but I'm pretty sure the current address of the two DIDR1 registers is wrong because it's outside the TUSB-specific register space. The modified address in turn has a good chance to be correct. Signed-off-by: Andrzej Zaborowski [EMAIL PROTECTED] --- drivers/usb/musb/tusb6010.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/musb/tusb6010.h b/drivers/usb/musb/tusb6010.h index bb25c3b..f2036ef 100644 --- a/drivers/usb/musb/tusb6010.h +++ b/drivers/usb/musb/tusb6010.h @@ -225,8 +225,8 @@ extern void tusb_allow_idle(struct musb *musb, u32 wakeup_enables); #define TUSB_PROD_TEST_RESET_VAL 0xa596 #define TUSB_EP_FIFO(ep) (TUSB_FIFO_BASE + (ep) * 0x20) -#define TUSB_DIDR1_LO 0x1f8 -#define TUSB_DIDR1_HI 0x1fc +#define TUSB_DIDR1_LO (TUSB_SYS_REG_BASE + 0x1f8) +#define TUSB_DIDR1_HI (TUSB_SYS_REG_BASE + 0x1fc) #defineTUSB_DIDR1_HI_CHIP_REV(v) (((v) 17) 0xf) #defineTUSB_DIDR1_HI_REV_200 #defineTUSB_DIDR1_HI_REV_301 This looks like a valid fix. Hmm, I guess we've had some unnecessary software workarounds for tusb3.1 chips happening :) Ugh, I'm out for today and tomorrow but I'll test on wednesday and make sure it works. Thanks. I only checked with usb-net, the only difference was that I got dieid2 instead of dieid5 in the dmesg (2 seems correct for rev3.1). The machine is some n810 proto (says N00). Cheers -- Please do not print this email unless absolutely necessary. Spread environmental awareness. -- 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
