Re: omap osk and mistral touchscreen-ads7846
On Thu, May 22, 2008 at 4:10 AM, mohammed shareef [EMAIL PROTECTED] wrote: Hello, i have enabled the SPI and ADS7846 drivers during kernel (2.6.18) compilation. i could see in the kernel boot log that they are also initialized. ads7846 spi2.0: touchscreen + hwmon, irq 164 input: ADS784x Touchscreen as /class/input/input1 / but could someone tell me what should i do next to calibrate my touchscreen? i even tried compiling tslib and added the executables to the file system. But when i run the executable /usr/X11/bin/ts_calibrate i see no response on the LCD. the system just hangs.' thanx and regards, Shareef ___ Linux-omap-open-source mailing list [EMAIL PROTECTED] http://linux.omap.com/mailman/listinfo/linux-omap-open-source Hi Shareef, Touch the screen several times and do a cat /proc/interrupts to check whether the interrupts are coming. Or you can enable event device debugging in menuconfig and see the debug messages. Regards, Arun 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: omap osk and mistral touchscreen-ads7846
On Thu, 22 May 2008 12:53:11 +0530, mohammed shareef [EMAIL PROTECTED] wrote: hi arun/all, when i do cat for interrupts i get: # cat /proc/interrupts CPU0 19: 0 MPU DMA 20: 0 MPU DMA 21: 0 MPU DMA 22: 0 MPU DMA 23: 0 MPU DMA 24: 0 MPU DMA 25: 9834 MPU LCD DMA 31: 3 MPU lcdc 33: 1 MPU omap-keypad 36:313 MPU i2c_omap 46:148 MPU serial 54: 19893 MPU 32KHz timer 78: 0 MPU peripheral wakeup 85: 0 MPU DMA 86: 0 MPU DMA 87: 0 MPU DMA 88: 0 MPU DMA 89: 0 MPU DMA 90: 0 MPU DMA 91: 0 MPU DMA 92: 0 MPU DMA 93: 0 MPU DMA 94: 0 MPU DMA 160: 1409GPIO eth0 164: 24GPIO spi2.0 Here's your interrupt line (if I'm not wrong). This touchscreen is connected via spi. If you go to arch/arm/mach-omap1/board-osk.c you'll see a spi_board_info. Just to be sure issue: watch 'cat /proc/interrupts' and keep touching the touchscreen. spi2.0 value should increase. -- Best Regards, Felipe Balbi http://felipebalbi.com [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: omap osk and mistral touchscreen-ads7846
On Thu, May 22, 2008 at 12:53 PM, mohammed shareef [EMAIL PROTECTED] wrote: hi arun/all, when i do cat for interrupts i get: # cat /proc/interrupts CPU0 19: 0 MPU DMA 20: 0 MPU DMA 21: 0 MPU DMA 22: 0 MPU DMA 23: 0 MPU DMA 24: 0 MPU DMA 25: 9834 MPU LCD DMA 31: 3 MPU lcdc 33: 1 MPU omap-keypad 36:313 MPU i2c_omap 46:148 MPU serial 54: 19893 MPU 32KHz timer 78: 0 MPU peripheral wakeup 85: 0 MPU DMA 86: 0 MPU DMA 87: 0 MPU DMA 88: 0 MPU DMA 89: 0 MPU DMA 90: 0 MPU DMA 91: 0 MPU DMA 92: 0 MPU DMA 93: 0 MPU DMA 94: 0 MPU DMA 160: 1409GPIO eth0 164: 24GPIO spi2.0 178: 0GPIO serial wakeup 197: 0GPIO serial wakeup 209: 19773GPIO serial wakeup 222: 0GPIO omap_cf 353: 0 MPUIO tps65010 354: 0 MPUIO mistral_wakeup Err: 0 looks like am not getting the touchscreen interrupts. i havent even calibrated my touchscreen. but i have enabled the SPI interface and the ADS7846 touchscreen in the kernel. could you tell me how to calibrate it or make it work? i guess i am missing out on some files like i have nothing like ts_calibrate in my filesystem. See this link, i think it can help you. http://linux.omap.com/pipermail/linux-omap-open-source/2005-March/003174.html Regards, Arun 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
[PATCH 0/2] Add D2D clockdomain on OMAP3 ES2+
Hello, This patch series adds D2D (die-to-die) clockdomain handling into OMAP3 ES2+ builds. It seems the D2D clockdomain logic is still present on the chip and must be manually programmed to allow the CORE_D2D clockdomain to go inactive. For this to work, the pm34xx.c code also had to be modified to use the pwrdm_for_each_clkdm() iterator, lest the existing for-loop fall off the end of pwrdm-pwrdm_clkdms[]. This also should fix an oops with CONFIG_PM on any 3430ES1 boards out there. Tested on 3430SDP ES2.0. - Paul diffstat: arch/arm/mach-omap2/clockdomains.h |9 - arch/arm/mach-omap2/pm34xx.c | 23 ++- 2 files changed, 26 insertions(+), 6 deletions(-) size: textdata bss dec hex filename 3280225 155416 98792 3534433 35ee61 vmlinux.3430sdp.orig 3280305 155416 98792 3534513 35eeb1 vmlinux.3430sdp.patched -- 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] IRQ: simplify OMAP2 mask_irq/unmask_irq code
* Paul Walmsley [EMAIL PROTECTED] [080521 12:15]:
Hi Tony,
On Wed, 21 May 2008, Tony Lindgren wrote:
* Paul Walmsley [EMAIL PROTECTED] [080520 18:20]:
Modify mach-omap2/irq.c to simplify the IRQ number-to-IRQ register and
IRQ
number-to-register bit calculations.
How about patching Jouni's new omap_irq_pending() for this too?
done - updated patch below.
Thanks, pushing today.
Tony
- Paul
[PATCH] IRQ: simplify OMAP2 mask_irq/unmask_irq code
Modify mach-omap2/irq.c to simplify the IRQ number-to-IRQ register and
IRQ number-to-register bit calculations.
Signed-off-by: Paul Walmsley [EMAIL PROTECTED]
Signed-off-by: Kyungmin Park [EMAIL PROTECTED]
Acked-by: Paul Mundt [EMAIL PROTECTED]
size:
textdata bss dec hex filename
3272871 155128 98792 3526791 35d087 vmlinux.3430sdp
3272839 155128 98792 3526759 35d067 vmlinux.3430sdp.patched
---
arch/arm/mach-omap2/irq.c | 27 ++-
1 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index f1e1e2e..94d2f93 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -28,6 +28,9 @@
#define INTC_MIR_SET00x008c
#define INTC_PENDING_IRQ00x0098
+/* Number of IRQ state bits in each MIR register */
+#define IRQ_BITS_PER_REG 32
+
/*
* OMAP2 has a number of different interrupt controllers, each interrupt
* controller is identified as its own bank. Register definitions are
@@ -68,24 +71,18 @@ static void omap_ack_irq(unsigned int irq)
static void omap_mask_irq(unsigned int irq)
{
- int offset = (irq 5) 5;
+ int offset = irq (~(IRQ_BITS_PER_REG - 1));
- if (irq = 64)
- irq %= 64;
- else if (irq = 32)
- irq %= 32;
+ irq = (IRQ_BITS_PER_REG - 1);
intc_bank_write_reg(1 irq, irq_banks[0], INTC_MIR_SET0 + offset);
}
static void omap_unmask_irq(unsigned int irq)
{
- int offset = (irq 5) 5;
+ int offset = irq (~(IRQ_BITS_PER_REG - 1));
- if (irq = 64)
- irq %= 64;
- else if (irq = 32)
- irq %= 32;
+ irq = (IRQ_BITS_PER_REG - 1);
intc_bank_write_reg(1 irq, irq_banks[0], INTC_MIR_CLEAR0 + offset);
}
@@ -131,11 +128,15 @@ int omap_irq_pending(void)
struct omap_irq_bank *bank = irq_banks + i;
int irq;
- for (irq = 0; irq bank-nr_irqs; irq += 32)
- if (intc_bank_read_reg(bank, INTC_PENDING_IRQ0 +
-((irq 5) 5)))
+ for (irq = 0; irq bank-nr_irqs; irq += IRQ_BITS_PER_REG) {
+ int offset = irq (~(IRQ_BITS_PER_REG - 1));
+
+ if (intc_bank_read_reg(bank, (INTC_PENDING_IRQ0 +
+ offset)))
return 1;
+ }
}
+
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: MMC/SD cards hotplug scenario
Hi Pierre, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pierre Ossman Sent: Thursday, May 22, 2008 12:02 AM To: Chikkature Rajashekar, Madhusudhan Cc: 'Russell King - ARM Linux'; linux-omap@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: MMC/SD cards hotplug scenario On Wed, 21 May 2008 15:01:00 +0530 Madhusudhan Chikkature Rajashekar [EMAIL PROTECTED] wrote: What I meant here is that reinsertion of the card does not seem to result in reinitialization of the card consistently. Previously, that has always been because of bad interactions with the block layer. 2.6.24 should be more resilient though. snip The obscene amount of noise here seems to be caused by ext2 being extremely persistent. This is generally a good thing for your data though. :) What is missing is a decent way for a block device to tell the upper layers that is gone with no hope of ever coming back. Right now we just tell it that there was a write error, which just makes the upper layers retry and retry. In this scenario, do you think it would be right to kill the ongoing copy from application space, say for example an UI is running for MMC copy and when the card is removed the app gets notified may be through hotplug event or signaling and then app just kills the process that is issuing this copy request. This will prevent long running errors. Just a thought, Regards, Khasim -- 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: Fix compiler error at pm-debug
* Kyungmin Park [EMAIL PROTECTED] [080520 22:57]: Fix compiler error at pm-debug Thanks, pushing today. Tony CC arch/arm/mach-omap2/pm-debug.o In file included from arch/arm/mach-omap2/pm-debug.c:30: arch/arm/mach-omap2/prm.h: In function `prm_rmw_reg_bits': arch/arm/mach-omap2/prm.h:107: error: implicit declaration of function `__raw_readl' arch/arm/mach-omap2/prm.h:110: error: implicit declaration of function `__raw_writel' arch/arm/mach-omap2/pm-debug.c: In function `serial_wait_tx': arch/arm/mach-omap2/pm-debug.c:59: error: implicit declaration of function `__raw_readb' make[1]: *** [arch/arm/mach-omap2/pm-debug.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 Signed-off-by: Kyungmin Park [EMAIL PROTECTED] --- diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c index 361e52b..8a9f3c4 100644 --- a/arch/arm/mach-omap2/pm-debug.c +++ b/arch/arm/mach-omap2/pm-debug.c @@ -23,6 +23,7 @@ #include linux/clk.h #include linux/err.h +#include linux/io.h #include asm/arch/clock.h #include asm/arch/board.h -- 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: MMC/SD cards hotplug scenario
On Fri, May 23, 2008 at 01:16:39AM +0530, Syed Mohammed, Khasim wrote: The obscene amount of noise here seems to be caused by ext2 being extremely persistent. This is generally a good thing for your data though. :) What is missing is a decent way for a block device to tell the upper layers that is gone with no hope of ever coming back. Right now we just tell it that there was a write error, which just makes the upper layers retry and retry. In this scenario, do you think it would be right to kill the ongoing copy from application space, say for example an UI is running for MMC copy and when the card is removed the app gets notified may be through hotplug event or signaling and then app just kills the process that is issuing this copy request. This will prevent long running errors. Just a thought, If you pick out the errors from 'cp', you'll see that the system is telling 'cp' that it's getting IO errors. Nevertheless, 'cp' carries on trying to copy each file (and rightfully so.) However, there is another issue here - if you're going to be ejecting a medium containing an ext2fs filesystem at some random point, you absolutely must run e2fsck before remounting it - the filesystem _will_ be in an inconsistent state at the point you eject the card. Moreover, I wouldn't be surprised if you keep doing this with a card, that the card's firmware will eventually get confused and die. Basically, what I'm trying to say is that ejecting any medium randomly from the system is _always_ going to result in problems of some nature. Some of which you can reduce the impact from, others are fairly terminal. The only safe solution is the unmount, wait for data to be written, and then eject the card. -- 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: MMC/SD cards hotplug scenario
Hi, On Thu, 2008-05-22 at 21:01 +0100, ext Russell King - ARM Linux wrote: Basically, what I'm trying to say is that ejecting any medium randomly from the system is _always_ going to result in problems of some nature. Some of which you can reduce the impact from, others are fairly terminal. The only safe solution is the unmount, wait for data to be written, and then eject the card. from this point of view it is a watered down version of what happens when the power is removed abruptly, which unfortunately cannot really be avoided on battery powered devices with removable battery. If the system is supposed to survive such cases, then ext2 is probably not the best choice and a journaling fs (ext3 ?) should be considered. With MMC even the way the power fails (vcore fading away before/after vio) affects the possibility of the embedded uC b0rking. So it needs to be addressed also at board HW level. This of course cannot be really controlled when the MMC is removed from the slot, unless there is a sensor on the MMC lid. Sensor that could be used for an emergency, controlled powerdown, with no sync. But on the Tablets we instead show a warning and tell the user to be nice and close back the lid: UI designers prefer such approach. Just my 2 cents. -- Cheers, Igor --- Igor Stoppa Nokia Devices RD - Helsinki -- 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
