Re: MMC/SD cards hotplug scenario
On Wed, May 21, 2008 at 11:42:04AM +0530, Madhusudhan Chikkature Rajashekar wrote: After the end of the I/O errors I can umount the partition that was mounted and I reinsert the card. That's rather expected - outstanding IO has to be errored when the medium is removed. It seem not to work very well consistently. Vague handwaving comment with no useful information. What precisely is the problem that you're seeing? -- 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
-Original Message- From: Russell King - ARM Linux [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 21, 2008 1:00 PM To: Madhusudhan Chikkature Rajashekar Cc: 'Pierre Ossman'; linux-omap@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: MMC/SD cards hotplug scenario On Wed, May 21, 2008 at 11:42:04AM +0530, Madhusudhan Chikkature Rajashekar wrote: After the end of the I/O errors I can umount the partition that was mounted and I reinsert the card. That's rather expected - outstanding IO has to be errored when the medium is removed. Yes. I got your point. But can this be made to through few I/O errors and stop instead of resulting in I/O errors for the rest of the data? In the case where data copied is huge, for eg 500MB, the I/O errors are quite lot. It seem not to work very well consistently. Vague handwaving comment with no useful information. What precisely is the problem that you're seeing? What I meant here is that reinsertion of the card does not seem to result in reinitialization of the card consistently. Details of few things I noticed is listed below stepwise and to start with card is detected and mounted on mount point /mnt/mmc dir. 1. Start copy of data. 2. Removed the card in the middle of transfer. At the controller driver level this generated card removed interrupt. The mmc_detect_change fn called. 3. I/O Errors generated. 4. Reinsert the card. This generated card inserted interrupt. The mmc_detect_fn called. But the card does not seem to be reinitialized correctly. cat /proc/partitions does not list mmc partitions. The attached log shows that out of 3 trails, it seem to work fine correctly 2 times and failed the third time. So my question is for the above scenario does the MMC/SD core need to take care of anything explicitely or should this be fixed at the controller driver level? Regards, Madhu p -a cp -a /etc/ /mnt/mmc/ + MMC CARD REMOVED + mmc0: card 981b removed mmcblk0: error -110 sending read/write command end_request: I/O error, dev mmcblk0, sector 3928 mmcblk0: error -110 sending read/write command end_request: I/O error, dev mmcblk0, sector 48 Buffer I/O error on device mmcblk0p1, logical block 4 lost page write due to I/O error on mmcblk0p1 mmcblk0: error -110 sending read/write command end_request: I/O error, dev mmcblk0, sector 16 Buffer I/O error on device mmcblk0p1, logical block 0 lost page write due to I/O error on mmcblk0p1 end_request: I/O error, dev mmcblk0, sector 24 Buffer I/O error on device mmcblk0p1, logical block 1 lost page write due to I/O error on mmcblk0p1 mmcblk0: error -110 sending read/write command WARNING: at fs/buffer.c:1169 mark_buffer_dirty() [c0033400] (dump_stack+0x0/0x14) from [c00d21ac] (mark_buffer_dirty+0x44/0xb8) [c00d2168] (mark_buffer_dirty+0x0/0xb8) from [c0108ae4] (group_adjust_blocks+0x38/0x3c) r5:0008 r4: [c0108aac] (group_adjust_blocks+0x0/0x3c) from [c0109778] (ext2_new_blocks+0x3fc/0x5cc) [c010937c] (ext2_new_blocks+0x0/0x5cc) from [c010d100] (ext2_get_block+0x2bc/0x69c) [c010ce44] (ext2_get_block+0x0/0x69c) from [c00d2f70] (__block_prepare_write+0x18c/0x414) [c00d2de4] (__block_prepare_write+0x0/0x414) from [c00d32e4] (block_write_begin+0x90/0x108) [c00d3254] (block_write_begin+0x0/0x108) from [c010cdf4] (__ext2_write_begin+0x3c/0x48) [c010cdb8] (__ext2_write_begin+0x0/0x48) from [c010ce3c] (ext2_write_begin+0x3c/0x44) [c010ce00] (ext2_write_begin+0x0/0x44) from [c009185c] (generic_file_buffered_write+0x10c/0x5f0) [c0091750] (generic_file_buffered_write+0x0/0x5f0) from [c0092168] (__generic_file_aio_write_nolock+0x428/0x478) [c0091d40] (__generic_file_aio_write_nolock+0x0/0x478) from [c009222c] (generic_file_aio_write+0x74/0xe8) [c00921b8] (generic_file_aio_write+0x0/0xe8) from [c00b08d0] (do_sync_write+0xbc/0x10c) [c00b0814] (do_sync_write+0x0/0x10c) from [c00b11b8] (vfs_write+0xb8/0x148) [c00b1100] (vfs_write+0x0/0x148) from [c00b1784] (sys_write+0x44/0x70) r7:1000 r6:c7c1ff20 r5: r4: [c00b1740] (sys_write+0x0/0x70) from [c002ee60] (ret_fast_syscall+0x0/0x2c) r8:c002f66c r7:0004 r6:0004 r5:be8aa148 r4:1000 end_request: I/O error, dev mmcblk0, sector 1048592 Buffer I/O error on device mmcblk0p1, logical block 131072 lost page write due to I/O error on mmcblk0p1 end_request: I/O error, dev mmcblk0, sector 1048600 Buffer I/O error on device mmcblk0p1, logical block 131073 lost page write due to I/O error on mmcblk0p1 end_request: I/O error, dev mmcblk0, sector 1048608 Buffer I/O error on device mmcblk0p1, logical block 131074 lost page write due to I/O error on mmcblk0p1 end_request: I/O error, dev mmcblk0, sector 1048616 Buffer I/O error on device mmcblk0p1, logical block 131075 lost page write due to I/O error on mmcblk0p1 end_request: I/O error, dev mmcblk0, sector 1048624 Buffer I/O error on device mmcblk0p1, logical block 131076 lost page write due to
enabling uart2 on omap5912 osk
Hello, How do i enable UART2 on omap5912_osk in the kernel? and is there a way by which i can test if the uart2 has been recongnised? i dont see uart module being initialized during the kernel boot-up. thank you. regards, Shareef -- 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: sdio cmd53 doesn't work on omap 2430sdp
Hi, Please use the vger list. It seems like you are getting DTO on CMD53. One thing you might want to check is did the card configuration path went fine before you issue CMD53. Before your card driver issues CMD53, I guess the SDIO core issues a series of CMD52 to read the card capabilities and Setup the bus width etc... Does these go through fine for the card you are using? Does the core detect the new SDIO card? Regards, Madhu -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitriy Chumak Sent: Wednesday, May 21, 2008 5:51 PM To: [EMAIL PROTECTED] Subject: sdio cmd53 doesn't work on omap 2430sdp Hi *, I write an SDIO driver on OMAP 2430SDP platform. I have two question related to MMC subsystem: 1. When I issue sdio_readw (or other function that ends up using CMD53 sdio command) - it hangs. This happens because func mmc_wait_for_req waits for request completion that should be signaled by calling mmc_wait_done. mmc_wait_done is indirectly called from mmc_omap_cmd_done if condition host-data == NULL || cmd-error (file: drivers/mmc/host/omap_hsmmc.c, line: 273) is true. In my case the above condition is not true because host-data is not NULL and cmd-error is NULL. Why this could be happen. Which code is responsible for setting host-data to NULL in case of successful sdio command completion? 2. Also when I issue sdio_readw - I get an error status 108001 in mmc_omap_irq. If I've decoded it correctly it means CC, ERR and DATA_TIMEOUT. What does it means and when this could be happened? Best regards, Dmitriy ___ Linux-omap-open-source mailing list [EMAIL PROTECTED] http://linux.omap.com/mailman/listinfo/linux-omap-open-source -- 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: sdio cmd53 doesn't work on omap 2430sdp
On Wednesday 21 May 2008 15:48:27 you wrote: the SDIO core issues a series of CMD52 to read the card capabilities and Setup the bus width etc... Does these go through fine for the card you are using? Does the core detect the new SDIO card? Yes, all these go fine and the core detects a new SDIO card, only CMD53 doesn't work. Could it be because of using DMA? Are there any way to not use DMA with CMD53? Regards, Dmitriy -- 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: enabling uart2 on omap5912 osk
* mohammed shareef [EMAIL PROTECTED] [080520 23:43]: Hello, How do i enable UART2 on omap5912_osk in the kernel? and is there a way by which i can test if the uart2 has been recongnised? i dont see uart module being initialized during the kernel boot-up. You need to enable it in board-osk.c, see enabled_uarts. Then to use it you also need the right hardware attached to it. 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: [PATCH 0/2] MUSB: 2 patches to fix some bug found on Blackfin
* Bryan Wu [EMAIL PROTECTED] [080519 01:06]: On Mon, May 19, 2008 at 3:49 PM, Felipe Balbi [EMAIL PROTECTED] wrote: On Mon, 19 May 2008 14:39:10 +0800, Bryan Wu [EMAIL PROTECTED] wrote: On Sat, May 17, 2008 at 10:37 PM, David Brownell [EMAIL PROTECTED] wrote: On Saturday 17 May 2008, Bryan Wu wrote: We discussed these 4 bugs before. Now we fixed them. Please review following 2 patches. They looked plausible to me ... though the urb-status one is a bit of a band-aid, and when that field finally vanishes a better fix will be needed. I'll push these to linux-omap tree then. OK, so is there any plan for merge the MUSB to mainline and finally to remove the urb-status? I was planing to do this by the end of this year or as soon as I make all usb if tests pass again. I'm out of tools for that right now :-s Great, after I enable the DMA mode 1 on Blackfin and cleanup the code, I will send out the code before you sent them to upstream Maybe we should get the musb code to USB tree before that? It's been out of the scope for linux-omap tree for quite a while now. 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: [RESENDING PATCH 4/4] ARM: OMAP: Add ethernet support for OMAPLDP
* Kamat, Nishant [EMAIL PROTECTED] [080519 02:50]: Tony, From: Tony Lindgren [mailto:[EMAIL PROTECTED] * Nishant Kamat [EMAIL PROTECTED] [080515 07:45]: +#define DEBUG_BASE 0x0800 + +#define OMAP34XX_ETHR_START DEBUG_BASE +#define LDP_SMC911X_CS 1 +#define LDP_SMC911X_GPIO 152 + These redefines will conflict when compiling in support for multiple boards. They should be passed in the platform_data. If I understand correctly, the problem is about using the same #define names as 3430 SDP, right? How about this patch: Yeah that's the problem. Can you please send the defconfig changes in a separate patch? Tony From: Nishant Kamat [EMAIL PROTECTED] This patch adds ethernet support (smc911x) for OMAP LDP platform. Signed-off-by: Nishant Kamat [EMAIL PROTECTED] --- arch/arm/configs/omap_ldp_defconfig | 164 - arch/arm/mach-omap2/board-ldp.c | 51 ++ include/asm-arm/arch-omap/board-ldp.h |4 + 3 files changed, 216 insertions(+), 3 deletions(-) diff --git a/arch/arm/configs/omap_ldp_defconfig b/arch/arm/configs/omap_ldp_defconfig index 9a90975..fb2880b 100644 --- a/arch/arm/configs/omap_ldp_defconfig +++ b/arch/arm/configs/omap_ldp_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.26-rc2-omap1 -# Thu May 15 19:08:39 2008 +# Thu May 15 19:09:22 2008 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y @@ -37,8 +37,11 @@ CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y +# CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set +# CONFIG_TASKSTATS is not set +# CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 # CONFIG_CGROUPS is not set @@ -319,7 +322,86 @@ CONFIG_ARCH_SUSPEND_POSSIBLE=y # # Networking # -# CONFIG_NET is not set +CONFIG_NET=y + +# +# Networking options +# +CONFIG_PACKET=y +# CONFIG_PACKET_MMAP is not set +CONFIG_UNIX=y +CONFIG_XFRM=y +# CONFIG_XFRM_USER is not set +# CONFIG_XFRM_SUB_POLICY is not set +# CONFIG_XFRM_MIGRATE is not set +# CONFIG_XFRM_STATISTICS is not set +CONFIG_NET_KEY=y +# CONFIG_NET_KEY_MIGRATE is not set +CONFIG_INET=y +# CONFIG_IP_MULTICAST is not set +# CONFIG_IP_ADVANCED_ROUTER is not set +CONFIG_IP_FIB_HASH=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_IP_PNP_BOOTP=y +CONFIG_IP_PNP_RARP=y +# CONFIG_NET_IPIP is not set +# CONFIG_NET_IPGRE is not set +# CONFIG_ARPD is not set +# CONFIG_SYN_COOKIES is not set +# CONFIG_INET_AH is not set +# CONFIG_INET_ESP is not set +# CONFIG_INET_IPCOMP is not set +# CONFIG_INET_XFRM_TUNNEL is not set +# CONFIG_INET_TUNNEL is not set +CONFIG_INET_XFRM_MODE_TRANSPORT=y +CONFIG_INET_XFRM_MODE_TUNNEL=y +CONFIG_INET_XFRM_MODE_BEET=y +# CONFIG_INET_LRO is not set +CONFIG_INET_DIAG=y +CONFIG_INET_TCP_DIAG=y +# CONFIG_TCP_CONG_ADVANCED is not set +CONFIG_TCP_CONG_CUBIC=y +CONFIG_DEFAULT_TCP_CONG=cubic +# CONFIG_TCP_MD5SIG is not set +# CONFIG_IPV6 is not set +# CONFIG_NETWORK_SECMARK is not set +# CONFIG_NETFILTER is not set +# CONFIG_IP_DCCP is not set +# CONFIG_IP_SCTP is not set +# CONFIG_TIPC is not set +# CONFIG_ATM is not set +# CONFIG_BRIDGE is not set +# CONFIG_VLAN_8021Q is not set +# CONFIG_DECNET is not set +# CONFIG_LLC2 is not set +# CONFIG_IPX is not set +# CONFIG_ATALK is not set +# CONFIG_X25 is not set +# CONFIG_LAPB is not set +# CONFIG_ECONET is not set +# CONFIG_WAN_ROUTER is not set +# CONFIG_NET_SCHED is not set + +# +# Network testing +# +# CONFIG_NET_PKTGEN is not set +# CONFIG_HAMRADIO is not set +# CONFIG_CAN is not set +# CONFIG_IRDA is not set +# CONFIG_BT is not set +# CONFIG_AF_RXRPC is not set + +# +# Wireless +# +# CONFIG_CFG80211 is not set +# CONFIG_WIRELESS_EXT is not set +# CONFIG_MAC80211 is not set +# CONFIG_IEEE80211 is not set +# CONFIG_RFKILL is not set +# CONFIG_NET_9P is not set # # Device Drivers @@ -335,18 +417,21 @@ CONFIG_PREVENT_FIRMWARE_BUILD=y # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set +# CONFIG_CONNECTOR is not set # CONFIG_MTD is not set # CONFIG_PARPORT is not set CONFIG_BLK_DEV=y # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_CRYPTOLOOP is not set +# CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=16384 # CONFIG_BLK_DEV_XIP is not set # CONFIG_CDROM_PKTCDVD is not set +# CONFIG_ATA_OVER_ETH is not set CONFIG_MISC_DEVICES=y # CONFIG_EEPROM_93CX6 is not set # CONFIG_OMAP_STI is not set @@ -388,12 +473,61 @@ CONFIG_SCSI_WAIT_SCAN=m # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set +#
Re: [PATCH 0/2] MUSB: 2 patches to fix some bug found on Blackfin
On Wednesday 21 May 2008, Tony Lindgren wrote: Great, after I enable the DMA mode 1 on Blackfin and cleanup the code, I will send out the code before you sent them to upstream Maybe we should get the musb code to USB tree before that? It's been out of the scope for linux-omap tree for quite a while now. I'm all for getting the musb_hdrc driver into the 2.6.27 queue... I presume there are still some infrastructure changes in usbcore that block that merge? It'd be nice if we could merge musb_hdrc without those changes (OTG related) and then update that stuff separately. - 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
RE: enabling uart2 on omap5912 osk
Each bit enables one uart.
For uarts 1, 2, 3 it will look like:
static struct omap_uart_config osk_uart_config __initdata = {
.enabled_uarts = (1 0) | (1 1) | (1 2),
};
Just a hint. You can look board-xxx.c config files and see examples
there.
Roman Tereshonkov
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of ext mohammed
shareef
Sent: 21 May, 2008 20:12
To: Tony Lindgren
Cc: omap; [EMAIL PROTECTED]
Subject: Re: enabling uart2 on omap5912 osk
i see the following lines in the omap-osk.c file regarding the uarts:
static struct omap_uart_config osk_uart_config __initdata = {
.enabled_uarts = (1 0),
};
what does it mean? i want all my uarts (1,2,3) enabled. how do i have
to modify the above line?
thanx for the help.
regards,
Shareef
On Wed, May 21, 2008 at 9:10 PM, Tony Lindgren [EMAIL PROTECTED] wrote:
* mohammed shareef [EMAIL PROTECTED] [080520 23:43]:
Hello,
How do i enable UART2 on omap5912_osk in the kernel?
and is there a way by which i can test if the uart2 has been
recongnised?
i dont see uart module being initialized during the kernel boot-up.
You need to enable it in board-osk.c, see enabled_uarts. Then to use
it
you also need the right hardware attached to it.
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
--
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: enabling uart2 on omap5912 osk
* mohammed shareef [EMAIL PROTECTED] [080521 10:12]:
i see the following lines in the omap-osk.c file regarding the uarts:
static struct omap_uart_config osk_uart_config __initdata = {
.enabled_uarts = (1 0),
};
what does it mean? i want all my uarts (1,2,3) enabled. how do i have
to modify the above line?
How about try .enabled_uarts = 3
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: 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. Details of few things I noticed is listed below stepwise and to start with card is detected and mounted on mount point /mnt/mmc dir. 1. Start copy of data. 2. Removed the card in the middle of transfer. At the controller driver level this generated card removed interrupt. The mmc_detect_change fn called. 3. I/O Errors generated. 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. 4. Reinsert the card. This generated card inserted interrupt. The mmc_detect_fn called. But the card does not seem to be reinitialized correctly. cat /proc/partitions does not list mmc partitions. Anything in dmesg? So my question is for the above scenario does the MMC/SD core need to take care of anything explicitely or should this be fixed at the controller driver level? Host drivers shouldn't have to bother with any of this for the simple reason that there should be no state inside the driver except for the current request. Keeping track of cards and block devices are handled in the core and mmc_block respectively. Rgds Pierre signature.asc Description: PGP signature
Re: [PATCH] IRQ: simplify OMAP2 mask_irq/unmask_irq code
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.
- 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_SET0 0x008c
#define INTC_PENDING_IRQ0 0x0098
+/* 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: enabling uart2 on omap5912 osk
On Wed, 21 May 2008 10:44:28 -0700, Tony Lindgren [EMAIL PROTECTED] wrote:
* mohammed shareef [EMAIL PROTECTED] [080521 10:12]:
i see the following lines in the omap-osk.c file regarding the uarts:
static struct omap_uart_config osk_uart_config __initdata = {
.enabled_uarts = (1 0),
};
what does it mean? i want all my uarts (1,2,3) enabled. how do i have
to modify the above line?
How about try .enabled_uarts = 3
this would enable only uarts 1 and 2, right?
maybe it's enough :-p
--
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: [PATCH 0/2] MUSB: 2 patches to fix some bug found on Blackfin
On Wednesday 21 May 2008, Felipe Balbi wrote: I'm all for getting the musb_hdrc driver into the 2.6.27 queue... I presume there are still some infrastructure changes in usbcore that block that merge? It'd be nice if we could merge musb_hdrc without those changes (OTG related) and then update that stuff separately. Ok then, I'll prepare the patches during the next week and post here on l-o so people can comment. When it's a USB patch, please post to linux-usb. Most of the relevant reviewers won't be on Linux-OMAP. ;) That said, I'm looking forward to seeing the www.beagleboard.org hardware [1] become more generally available. That will make some musb_hdrc hardware available in a more developer-friendly rig than, say, an N810 tablet. And it might well get more folk in a position where they can use that driver! (I think some Blackfin devboards are available already, but they're more pricey.) - Dave [1] http://www.elinux.org/BeagleBoard -- 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/2] MUSB: 2 patches to fix some bug found on Blackfin
On Wed, May 21, 2008 at 4:04 PM, David Brownell wrote: That said, I'm looking forward to seeing the www.beagleboard.org hardware [1] become more generally available. That will make some musb_hdrc hardware available in a more developer-friendly rig than, say, an N810 tablet. And it might well get more folk in a position where they can use that driver! (I think some Blackfin devboards are available already, but they're more pricey.) unfortunately, that is the case. the BF527 EZKit is ~$900 while the BF548 EZKit is ~$1000. i'm hoping us software guys keep complaining enough for the hardware guys to put out a bare bone kit at a reasonable price (sub $300). -mike -- 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: enabling uart2 on omap5912 osk
* Felipe Balbi [EMAIL PROTECTED] [080521 12:37]:
On Wed, 21 May 2008 10:44:28 -0700, Tony Lindgren [EMAIL PROTECTED] wrote:
* mohammed shareef [EMAIL PROTECTED] [080521 10:12]:
i see the following lines in the omap-osk.c file regarding the uarts:
static struct omap_uart_config osk_uart_config __initdata = {
.enabled_uarts = (1 0),
};
what does it mean? i want all my uarts (1,2,3) enabled. how do i have
to modify the above line?
How about try .enabled_uarts = 3
this would enable only uarts 1 and 2, right?
maybe it's enough :-p
Oh yeh, that's true :)
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: enabling uart2 on omap5912 osk
On Thu, 22 May 2008 03:46:37 +0530, mohammed shareef [EMAIL PROTECTED] wrote: when i type: ls -l /dev/ttyS0 crw-rw-rw-1 root root 4, 64 Aug 8 2004 \0x1b[1;35m/dev/ttyS0\0x1b[0m # ls -l /dev/ttyS1 -rw-r-- ... that's a bit weird. What does cat /proc/tty/drivers show ? -- 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: enabling uart2 on omap5912 osk
# cat /proc/tty/drivers /dev/tty /dev/tty5 0 system:/dev/tty /dev/console /dev/console5 1 system:console /dev/ptmx/dev/ptmx 5 2 system /dev/vc/0/dev/vc/0 4 0 system:vtmaster serial /dev/ttyS 4 64-67 serial pty_slave/dev/pts 136 0-1048575 pty:slave pty_master /dev/ptm 128 0-1048575 pty:master pty_slave/dev/ttyp 3 0-255 pty:slave pty_master /dev/pty2 0-255 pty:master unknown /dev/tty4 1-63 console this is the output.. regards and thanx, shareef On Thu, May 22, 2008 at 3:51 AM, Felipe Balbi [EMAIL PROTECTED] wrote: On Thu, 22 May 2008 03:46:37 +0530, mohammed shareef [EMAIL PROTECTED] wrote: when i type: ls -l /dev/ttyS0 crw-rw-rw-1 root root 4, 64 Aug 8 2004 \0x1b[1;35m/dev/ttyS0\0x1b[0m # ls -l /dev/ttyS1 -rw-r-- ... that's a bit weird. What does cat /proc/tty/drivers show ? -- 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: enabling uart2 on omap5912 osk
On Thu, 22 May 2008 04:01:17 +0530, mohammed shareef [EMAIL PROTECTED] wrote: # cat /proc/tty/drivers /dev/tty /dev/tty5 0 system:/dev/tty /dev/console /dev/console5 1 system:console /dev/ptmx/dev/ptmx 5 2 system /dev/vc/0/dev/vc/0 4 0 system:vtmaster serial /dev/ttyS 4 64-67 serial Here's what you're looking for. pty_slave/dev/pts 136 0-1048575 pty:slave pty_master /dev/ptm 128 0-1048575 pty:master pty_slave/dev/ttyp 3 0-255 pty:slave pty_master /dev/pty2 0-255 pty:master unknown /dev/tty4 1-63 console this is the output.. It seems ok, no idea why the 4 doesn't appear in ls -l. Sorry :-s -- 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
omap osk and mistral touchscreen-ads7846
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 -- 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
Recent DMA changes broke omap1, CDAC broken on 3430
Hi all, Turns out my recent DMA changes broke omap1 dma to some extent. I've pushed a fix for that, and also a fix for old alsa code, and a compile fix for H4. I also fixed omap_get_dma_src/dst_pos() to return the current address. So if there are still some old drivers (wrongly) assuming this function returns the transfer count, they're even more broken now. Please everybody check your drivers for that. It also seems that omap3430sdp ES2.0 returns 0 for CDAC address. This means omap_get_dma_dst_pos() will always return 0, which may break some drivers.. I have no idea why CDAC is 0 on 3430, there's something in TRM in 9.5.4 Synchronized Transfer Monitoring Using CDAC about setting CDAC, but so far no luck. Maybe this only works for hardware triggered transfers? If anybody has ideas why CDAC is not behaving let me know! Cheers, 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
