[patch 2.6.26-omap-git] beagle LED fixes
Signed-off-by: David Brownell [EMAIL PROTECTED]
Update and fix Beagle LED declarations: gpios for USR0 and USR1
were swapped, and their names don't match docs or silksreen.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-omap3beagle.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/arch/arm/mach-omap2/board-omap3beagle.c 2008-08-04 22:08:16.0
-0700
+++ b/arch/arm/mach-omap2/board-omap3beagle.c 2008-08-04 22:08:36.0
-0700
@@ -75,14 +76,14 @@ static struct omap_lcd_config omap3_beag
struct gpio_led gpio_leds[] = {
{
- .name = beagleboard::led0,
+ .name = beagleboard::usr0,
.default_trigger= none,
- .gpio = 149,
+ .gpio = 150,
},
{
- .name = beagleboard::led1,
+ .name = beagleboard::usr1,
.default_trigger= none,
- .gpio = 150,
+ .gpio = 149,
},
};
--
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] OMAP3:devices.c: Enabling 4-bit for SD card
On Monday 14 July 2008, Kumar, Purushotam wrote:
if (cpu_is_omap2430() || cpu_is_omap34xx()) {
- if (mmc-enabled)
+ if (mmc-enabled) {
+ mmc1_data.conf = *mmc;
(void)
platform_device_register(mmc_omap_device1);
+ }
I don't get it. OMAP3 uses the hsmmc code, which uses
a struct omap_mmc_platform_data to configure itself.
But this patch updates a struct omap_mmc_conf as used
by the non-hsmmc code.
So ... it's a NOP, at least for OMAP3. Right?
--
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
can't read/write flash device after booting from nfs
Hi: I can't find how to subscribe this email list. so I could just send email to it. :) I have booted the omap ldp board with nfs. I want to bootup from flash. so I want to test if linux kernel could read/write flash device. I used make omap_ldp_defconfig make uImage to build kernel. After kernel booting, I can't read/write flash device. Anyone has bootup the ldp board with Flash device? 6console [ttyS2] enabled Linux version 2.6.26-rc8-omap1 ([EMAIL PROTECTED]) (gcc version 4.2.3 (Sourcery G++ Lite 2008q1-126)) #2 Thu Jul 31 16:50:54 CST 2008 CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=00c5387f Machine: OMAP LDP board Memory policy: ECC disabled, Data cache writeback OMAP3430 ES2.2 SRAM: Mapped pa 0x4020 to va 0xd700 size: 0x10 CPU0: D VIPT write-through cache CPU0: cache: 768 bytes, associativity 1, 8 byte lines, 64 sets Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: mem=128M console=ttyS2,115200n8 noinitrd root=/dev/nfs rw nfsroot=128.247.77.91:/home/ztao/tftproot/arm-linux,nolock,tcp,rsize=4096,wsize=4096 ip=128.247.77.90 Clocking rate (Crystal/DPLL/ARM core): 26.0/266/500 MHz GPMC revision 5.0 IRQ: Found an INTC at 0xd820 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller OMAP34xx GPIO hardware version 2.5 PID hash table entries: 512 (order: 9, 2048 bytes) Console: colour dummy device 80x30 omap2-nand driver initializing 6NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND 256MiB 1,8V 16-bit) NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND 256MiB 1,8V 16-bit) 5Creating 6 MTD partitions on omap2-nand.0: Creating 6 MTD partitions on omap2-nand.0: 50x-0x0008 : X-Loader-NAND 0x-0x0008 : X-Loader-NAND 50x0008-0x0010 : U-Boot-NAND 0x0008-0x0010 : U-Boot-NAND 50x0010-0x0014 : Boot Env-NAND 0x0010-0x0014 : Boot Env-NAND 50x0014-0x0054 : Kernel-NAND 0x0014-0x0054 : Kernel-NAND 50x0054-0x0094 : root file system- NAND 0x0054-0x0094 : root file system- NAND 50x0094-0x1000 : File System - NAND 0x0094-0x1000 : File System - NAND 5usbmon: debugfs is not available / # dd if=/dev/mtblock4 of=test2 count=1 3end_request: I/O error, dev mtdblock4, sector 0 end_request: I/O error, dev mtdblock4, sector 0 3Buffer I/O error on device mtdblock4, logical block 0 Buffer I/O error on device mtdblock4, logical block 0 3end_request: I/O error, dev mtdblock4, sector 16 end_request: I/O error, dev mtdblock4, sector 16 3Buffer I/O error on device mtdblock4, logical block 2 Buffer I/O error on device mtdblock4, logical block 2 3end_request: I/O error, dev mtdblock4, sector 24 end_request: I/O error, dev mtdblock4, sector 24 3Buffer I/O error on device mtdblock4, logical block 3 Buffer I/O error on device mtdblock4, logical block 3 3end_request: I/O error, dev mtdblock4, sector 0 end_request: I/O error, dev mtdblock4, sector 0 3Buffer I/O error on device mtdblock4, logical block 0 Buffer I/O error on device mtdblock4, logical block 0 dd: /dev/mtdblock4: Input/output error / # / # dd if=ext2.img of=/dev/mtdblock5 count=4 4mtdblock: erase of region [0x0, 0x2] on File System - NAND failed mtdblock: erase of region [0x0, 0x2] on File System - NAND failed 4+0 records in 4+0 records out / # I checked the schematic, the Flash type is PC28F640P30T85, it should be Intel flash. I'm not sure if the config file using wrong flash driver. Any suggestion, please let me know. Best Regards Tao -- 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.6.26-omap-git] beagle LED fixes
* Koen Kooi [EMAIL PROTECTED] [080805 11:14]:
Op 5 aug 2008, om 08:56 heeft David Brownell het volgende geschreven:
Signed-off-by: David Brownell [EMAIL PROTECTED]
Update and fix Beagle LED declarations: gpios for USR0 and USR1
were swapped, and their names don't match docs or silksreen.
I just heard that from TI and wanted to fix that today :) I didn't
notice it because revA board have the leds shorted together so they both
light up at the same time.
Pushing today.
Tony
Signed-off-by: David Brownell [EMAIL PROTECTED]
Acked-by: Koen Kooi [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-omap3beagle.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/arch/arm/mach-omap2/board-omap3beagle.c2008-08-04
22:08:16.0 -0700
+++ b/arch/arm/mach-omap2/board-omap3beagle.c2008-08-04
22:08:36.0 -0700
@@ -75,14 +76,14 @@ static struct omap_lcd_config omap3_beag
struct gpio_led gpio_leds[] = {
{
-.name = beagleboard::led0,
+.name = beagleboard::usr0,
.default_trigger= none,
-.gpio = 149,
+.gpio = 150,
},
{
-.name = beagleboard::led1,
+.name = beagleboard::usr1,
.default_trigger= none,
-.gpio = 150,
+.gpio = 149,
},
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap
in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] OMAP: MENELAUS: Improvements on menelaus
* Gadiyar, Anand [EMAIL PROTECTED] [080729 22:38]: 2008/7/29 Felipe Balbi [EMAIL PROTECTED]: On Tue, Jul 29, 2008 at 02:07:51PM -0500, Woodruff, Richard wrote: 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? A number does seem more understandable. Though some of these chips live under a few different numbers. it does seem more understandable, but now that it has been used for so long I guess it would be nasty to change right now. Almost every one here knows that menelaus is the companion chip for omap2 hw. Personally, I never recall the correct number designation for menelaus. Well, menelaus is a friendly name now that I know what it is but it was difficult to find its datasheet without knowing the public name used by the manufacturer, it seemed like a nokia's own chip. Also iirc if you open the device you will only see the TWLxxx name on the chip. I see TWLxxx is now mentioned in the Kconfig so I won't insist. Cheers I think it'll be hard for a newbie to figure out what this menelaus is. Google won't help either, (unless one really thinks there is a connection between Linux and Greek Mythology ;) ). I second renaming the file to TWL92230. Mentioning this in Kconfig is simply not enough. Yeah, let's rename it as it's not in mainline yet. I'll apply this series, then the next set of patches can take care of the renaming. 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] MUSB: Fix bug - don't mess up count number and CSR0 register value
Hi, * Bryan Wu [EMAIL PROTECTED] [080805 06:27]: Signed-off-by: Bryan Wu [EMAIL PROTECTED] --- drivers/usb/musb/musb_gadget_ep0.c | 24 1 files changed, 12 insertions(+), 12 deletions(-) I think all musb patches should be now posted to linux-usb list as the patches are queued for integration. So I'll be using plain code coming from mainline tree and won't apply any patches to musb code except temporary fixes if compile breaks. Cheers, Tony Do you mind if I post the patches here as well? It could be useful to someone using USB on OMAP? At least they could get a review here. I've got one set of patches coming up over the next couple of days, and all of it is based on the current linux-omap tree. - Anand -- 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
* Felipe Balbi [EMAIL PROTECTED] [080805 12:35]: On Tue, Aug 05, 2008 at 11:57:53AM +0300, Tony Lindgren wrote: Yeah, let's rename it as it's not in mainline yet. I'll apply this series, then the next set of patches can take care of the renaming. It it in mainline actually, check your drivers/i2c/chips and it was added by you :-p commit 0c4a59fed41bdd4c30ce0999a87f30a812f29ee2 Author: Tony Lindgren [EMAIL PROTECTED] Date: Tue Jul 17 04:06:09 2007 -0700 OMAP: add TI TWL92330/Menelaus Power Management chip driver Add Texas Instruments TWL92330/Menelaus Power Management chip driver. This includes voltage regulators, Dual slot memory card tranceivers and real-time clock(RTC). The support for RTC is integrated with this driver only; it is not separate module. Passes 'rtctest' on OMAP H4 EVM, other than lack of periodic (1/N second) IRQs. System wakeup alarms (from suspend-to-RAM) work too. The battery keeps the RTC active over power off, so once you set clock (rdate/ntpdate/etc, then hwclock -w) then RTC_HCTOSYS at boot time will behave as expected. Cc: Jean Delvare [EMAIL PROTECTED] Cc: Tony Lindgren [EMAIL PROTECTED] Cc: David Brownell [EMAIL PROTECTED] Signed-off-by: Trilok Soni [EMAIL PROTECTED] Acked-by: Alessandro Zummo [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] Maybe someone sent that patch for you ? Oops :) I guess I'm over a year behind current developments after my vacation! Anyways, sounds like people want to rename it. Carlos, can you send your patches to the i2c list for integration? 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] Added support for OMAP35x processor series
Op 5 aug 2008, om 11:50 heeft Igor Stoppa het volgende geschreven: On Tue, 2008-08-05 at 15:09 +0530, ext Premi, Sanjeev wrote: This patch is needed to ensure that we can make decisions based on the processor capabilities. E.g. OMAP3503 does not contain a DSP. We shouldn't be trying to disable/ manage the clocks for DSP on this processor. Same for SGX. Why can't the detection happen at runtime? AIUI the ID bits are the same (linux misdetect the 3530 on my beagle for a 3430). I heard that the only definitive way to do it at runtime is to CRC check the ROM code. Jason, is that correct? regards, Koen Enabling NEON is support iby default is just based on the number of requests I have been getting from various users. Huh? -- Cheers, Igor --- Igor Stoppa Maemo Software - 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 PGP.sig Description: This is a digitally signed message part
Re: [PATCH] MUSB: Fix bug - don't mess up count number and CSR0 register value
Hi,
* Bryan Wu [EMAIL PROTECTED] [080805 06:27]:
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
---
drivers/usb/musb/musb_gadget_ep0.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
I think all musb patches should be now posted to linux-usb list as the
patches are queued for integration.
So I'll be using plain code coming from mainline tree and
won't apply any patches to musb code except temporary fixes if compile
breaks.
Cheers,
Tony
diff --git a/drivers/usb/musb/musb_gadget_ep0.c
b/drivers/usb/musb/musb_gadget_ep0.c
index 2d2574c..e7b56df 100644
--- a/drivers/usb/musb/musb_gadget_ep0.c
+++ b/drivers/usb/musb/musb_gadget_ep0.c
@@ -452,7 +452,7 @@ static void ep0_rxstate(struct musb *musb)
{
void __iomem*regs = musb-control_ep-regs;
struct usb_request *req;
- u16 tmp;
+ u16 count, csr;
req = next_ep0_request(musb);
@@ -464,34 +464,34 @@ static void ep0_rxstate(struct musb *musb)
unsignedlen = req-length - req-actual;
/* read the buffer */
- tmp = musb_readb(regs, MUSB_COUNT0);
- if (tmp len) {
+ count = musb_readb(regs, MUSB_COUNT0);
+ if (count len) {
req-status = -EOVERFLOW;
- tmp = len;
+ count = len;
}
- musb_read_fifo(musb-endpoints[0], tmp, buf);
- req-actual += tmp;
- tmp = MUSB_CSR0_P_SVDRXPKTRDY;
- if (tmp 64 || req-actual == req-length) {
+ musb_read_fifo(musb-endpoints[0], count, buf);
+ req-actual += count;
+ csr = MUSB_CSR0_P_SVDRXPKTRDY;
+ if (count 64 || req-actual == req-length) {
musb-ep0_state = MUSB_EP0_STAGE_STATUSIN;
- tmp |= MUSB_CSR0_P_DATAEND;
+ csr |= MUSB_CSR0_P_DATAEND;
} else
req = NULL;
} else
- tmp = MUSB_CSR0_P_SVDRXPKTRDY | MUSB_CSR0_P_SENDSTALL;
+ csr = MUSB_CSR0_P_SVDRXPKTRDY | MUSB_CSR0_P_SENDSTALL;
/* Completion handler may choose to stall, e.g. because the
* message just received holds invalid data.
*/
if (req) {
- musb-ackpend = tmp;
+ musb-ackpend = csr;
musb_g_ep0_giveback(musb, req);
if (!musb-ackpend)
return;
musb-ackpend = 0;
}
- musb_writew(regs, MUSB_CSR0, tmp);
+ musb_writew(regs, MUSB_CSR0, csr);
}
/*
--
1.5.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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/2] Move voltage controller configuration to pm34xx.c
* Peter 'p2' De Schrijver [EMAIL PROTECTED] [080731 16:39]:
Signed-off-by: Peter 'p2' De Schrijver [EMAIL PROTECTED]
---
arch/arm/mach-omap2/smartreflex.c | 60
-
1 files changed, 0 insertions(+), 60 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index b41fe96..7e4f9a4 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -362,64 +362,6 @@ static void sr_configure_vp(int srid)
}
}
-static void sr_configure_vc(void)
-{
- prm_write_mod_reg((R_SRI2C_SLAVE_ADDR OMAP3430_SMPS_SA1_SHIFT) |
- (R_SRI2C_SLAVE_ADDR OMAP3430_SMPS_SA0_SHIFT),
- OMAP3430_GR_MOD, OMAP3_PRM_VC_SMPS_SA_OFFSET);
-
- prm_write_mod_reg((R_VDD2_SR_CONTROL OMAP3430_VOLRA1_SHIFT) |
- (R_VDD1_SR_CONTROL OMAP3430_VOLRA0_SHIFT),
- OMAP3430_GR_MOD, OMAP3_PRM_VC_SMPS_VOL_RA_OFFSET);
-
- prm_write_mod_reg((OMAP3430_VC_CMD_VAL0_ON
- OMAP3430_VC_CMD_ON_SHIFT) |
- (OMAP3430_VC_CMD_VAL0_ONLP OMAP3430_VC_CMD_ONLP_SHIFT) |
- (OMAP3430_VC_CMD_VAL0_RET OMAP3430_VC_CMD_RET_SHIFT) |
- (OMAP3430_VC_CMD_VAL0_OFF OMAP3430_VC_CMD_OFF_SHIFT),
- OMAP3430_GR_MOD, OMAP3_PRM_VC_CMD_VAL_0_OFFSET);
-
- prm_write_mod_reg((OMAP3430_VC_CMD_VAL1_ON
- OMAP3430_VC_CMD_ON_SHIFT) |
- (OMAP3430_VC_CMD_VAL1_ONLP OMAP3430_VC_CMD_ONLP_SHIFT) |
- (OMAP3430_VC_CMD_VAL1_RET OMAP3430_VC_CMD_RET_SHIFT) |
- (OMAP3430_VC_CMD_VAL1_OFF OMAP3430_VC_CMD_OFF_SHIFT),
- OMAP3430_GR_MOD, OMAP3_PRM_VC_CMD_VAL_1_OFFSET);
-
- prm_write_mod_reg(OMAP3430_CMD1 | OMAP3430_RAV1,
- OMAP3430_GR_MOD,
- OMAP3_PRM_VC_CH_CONF_OFFSET);
-
- prm_write_mod_reg(OMAP3430_MCODE_SHIFT | OMAP3430_HSEN | OMAP3430_SREN,
- OMAP3430_GR_MOD,
- OMAP3_PRM_VC_I2C_CFG_OFFSET);
-
- /* Setup voltctrl and other setup times */
- /* XXX CONFIG_SYSOFFMODE has not been implemented yet */
-#ifdef CONFIG_OMAP_SYSOFFMODE
- prm_write_mod_reg(OMAP3430_AUTO_OFF | OMAP3430_AUTO_RET |
- OMAP3430_SEL_OFF, OMAP3430_GR_MOD,
- OMAP3_PRM_VOLTCTRL_OFFSET);
-
- prm_write_mod_reg(OMAP3430_CLKSETUP_DURATION, OMAP3430_GR_MOD,
- OMAP3_PRM_CLKSETUP_OFFSET);
- prm_write_mod_reg((OMAP3430_VOLTSETUP_TIME2
- OMAP3430_SETUP_TIME2_SHIFT) |
- (OMAP3430_VOLTSETUP_TIME1
- OMAP3430_SETUP_TIME1_SHIFT),
- OMAP3430_GR_MOD, OMAP3_PRM_VOLTSETUP1_OFFSET);
-
- prm_write_mod_reg(OMAP3430_VOLTOFFSET_DURATION, OMAP3430_GR_MOD,
- OMAP3_PRM_VOLTOFFSET_OFFSET);
- prm_write_mod_reg(OMAP3430_VOLTSETUP2_DURATION, OMAP3430_GR_MOD,
- OMAP3_PRM_VOLTSETUP2_OFFSET);
-#else
- prm_set_mod_reg_bits(OMAP3430_AUTO_RET, OMAP3430_GR_MOD,
- OMAP3_PRM_VOLTCTRL_OFFSET);
-#endif
-
-}
-
static void sr_configure(struct omap_sr *sr)
{
u32 sr_config;
@@ -845,8 +787,6 @@ static int __init omap3_sr_init(void)
sr_set_nvalues(sr2);
sr_configure_vp(SR2);
- sr_configure_vc();
-
/* Enable SR on T2 */
ret = twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, RdReg,
R_DCDC_GLOBAL_CFG);
This patch does not seem to move code, it just removes it. Can you do
the patches where the first patch just moves the existing code, then
the second patch adds the new changes? That way it's easier to read.
Thanks,
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] PM related changes:McSPI
* Girish. S. G. [EMAIL PROTECTED] [080730 14:55]:
PM related changes for McSPI
This should be sent to [EMAIL PROTECTED], please
also Cc linux-omap list.
Thanks,
Tony
Signed-off-by: Girish S G [EMAIL PROTECTED]
---
arch/arm/mach-omap2/devices.c | 26 -
drivers/spi/omap2_mcspi.c | 195
++
2 files changed, 204 insertions(+), 17 deletions(-)
Index: linux-omap-2.6/arch/arm/mach-omap2/devices.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/devices.c 2008-07-30
16:49:21.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/devices.c 2008-07-30
16:57:53.0
+0530
@@ -168,6 +168,11 @@
.end= OMAP2_MCSPI1_BASE + 0xff,
.flags = IORESOURCE_MEM,
},
+
+ {
+ .start = INT_24XX_SPI1_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
};
static struct platform_device omap2_mcspi1 = {
@@ -190,6 +195,11 @@
.end= OMAP2_MCSPI2_BASE + 0xff,
.flags = IORESOURCE_MEM,
},
+
+ {
+ .start = INT_24XX_SPI2_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
};
static struct platform_device omap2_mcspi2 = {
@@ -209,9 +219,14 @@
static struct resource omap2_mcspi3_resources[] = {
{
- .start = OMAP2_MCSPI3_BASE,
- .end= OMAP2_MCSPI3_BASE + 0xff,
- .flags = IORESOURCE_MEM,
+ .start = OMAP2_MCSPI3_BASE,
+ .end= OMAP2_MCSPI3_BASE + 0xff,
+ .flags = IORESOURCE_MEM,
+ },
+
+ {
+ .start = INT_24XX_SPI3_IRQ,
+ .flags = IORESOURCE_IRQ,
},
};
@@ -237,6 +252,11 @@
.end= OMAP2_MCSPI4_BASE + 0xff,
.flags = IORESOURCE_MEM,
},
+
+ {
+ .start = INT_34XX_SPI4_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
};
static struct platform_device omap2_mcspi4 = {
Index: linux-omap-2.6/drivers/spi/omap2_mcspi.c
===
--- linux-omap-2.6.orig/drivers/spi/omap2_mcspi.c 2008-07-30
16:49:59.0
+0530
+++ linux-omap-2.6/drivers/spi/omap2_mcspi.c 2008-07-30 17:11:23.0
+0530
@@ -35,6 +35,8 @@
#include linux/spi/spi.h
+#include asm/system.h
+#include asm/irq.h
#include asm/arch/dma.h
#include asm/arch/clock.h
@@ -61,8 +63,11 @@
#define OMAP2_MCSPI_SYSCONFIG_AUTOIDLE (1 0)
#define OMAP2_MCSPI_SYSCONFIG_SOFTRESET (1 1)
+#define OMAP2_AFTR_RST_SET_MASTER(0 2)
#define OMAP2_MCSPI_SYSSTATUS_RESETDONE (1 0)
+#define OMAP2_MCSPI_SYS_CON_LVL_1 1
+#define OMAP2_MCSPI_SYS_CON_LVL_2 2
#define OMAP2_MCSPI_MODULCTRL_SINGLE (1 0)
#define OMAP2_MCSPI_MODULCTRL_MS (1 2)
@@ -84,6 +89,11 @@
#define OMAP2_MCSPI_CHCONF_TURBO (1 19)
#define OMAP2_MCSPI_CHCONF_FORCE (1 20)
+#define OMAP2_MCSPI_SYSCFG_WKUP (1 2)
+#define OMAP2_MCSPI_SYSCFG_IDL (2 3)
+#define OMAP2_MCSPI_SYSCFG_CLK (2 8)
+#define OMAP2_MCSPI_WAKEUP_EN(1 1)
+#define OMAP2_MCSPI_IRQ_WKS (1 16)
#define OMAP2_MCSPI_CHSTAT_RXS (1 0)
#define OMAP2_MCSPI_CHSTAT_TXS (1 1)
#define OMAP2_MCSPI_CHSTAT_EOT (1 2)
@@ -128,6 +138,15 @@
int word_len;
};
+#if defined(CONFIG_OMAP34XX_OFFMODE) defined(CONFIG_OMAP3_PM)
+struct omap_mcspi_regs {
+ u32 sysconfig;
+ u32 modulctrl;
+ u32 chconf0;
+ u32 chconf1;
+};
+static struct omap_mcspi_regs mcspi_ctx[4];
+#endif /* #ifdef CONFIG_OMAP34XX_OFFMODE */
static struct workqueue_struct *omap2_mcspi_wq;
#define MOD_REG_BIT(val, mask, set) do { \
@@ -152,6 +171,14 @@
return __raw_readl(mcspi-base + idx);
}
+static inline void mcspi_write_wkup_reg(struct spi_master *master,
+ int idx, u32 val)
+{
+ struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
+
+ __raw_writel(val, mcspi-base + idx);
+}
+
static inline void mcspi_write_cs_reg(const struct spi_device *spi,
int idx, u32 val)
{
@@ -214,6 +241,99 @@
mcspi_write_reg(master, OMAP2_MCSPI_MODULCTRL, l);
}
+static void omap_mcspi_wakeup_enable(struct spi_master *spi_cntrl, int level)
+{
+ if (level == OMAP2_MCSPI_SYS_CON_LVL_1)
+ mcspi_write_wkup_reg(spi_cntrl, OMAP2_MCSPI_SYSCONFIG,
+ (mcspi_read_reg(spi_cntrl, OMAP2_MCSPI_SYSCONFIG) |
+ OMAP2_MCSPI_SYSCFG_WKUP | OMAP2_MCSPI_SYSCFG_IDL |
+ OMAP2_MCSPI_SYSCFG_CLK |
+
Re: [PATCH v2] ARM: OMAP3: Make I2C bus 2 configurable for BeagleBoard
* Dirk Behme [EMAIL PROTECTED] [080704 10:39]:
I2C2 at BeagleBoard is connected to expansion connector, i.e. unused if
nothing is connected to this connector. As internal OMAP3 pull up
resistors are not strong enough, enabled but unused I2C2 bus results in
error messages (e.g. I2C timeouts). I2C2 should be enabled only if
something is connected to I2C2 at board's expansion connector and this
extension has additional pull up resistors for I2C2 bus.
- Add configuration option for this
- Use configuration option in board-omap3beagle
- While being there, add OMAP3 to OMAP I2C help text
Pushing today.
Tony
Signed-off-by: Dirk Behme [EMAIL PROTECTED]
Subject: ARM: OMAP3: Make I2C bus 2 configurable for BeagleBoard
From: Dirk Behme [EMAIL PROTECTED]
I2C2 at BeagleBoard is connected to expansion connector, i.e. unused if
nothing is connected to this connector. As internal OMAP3 pull up resistors
are not strong enough, enabled but unused I2C2 bus results in error messages
(e.g. I2C timeouts). I2C2 should be enabled only if something is connected to
I2C2 at board's expansion connector and this extension has additional pull up
resistors for I2C2 bus.
- Add configuration option for this
- Use configuration option in board-omap3beagle
- While being there, add OMAP3 to OMAP I2C help text
Signed-off-by: Dirk Behme [EMAIL PROTECTED]
---
Changes in v2: Incorporate Jarkko's comments. Pin mux is already done
depending on enabled busses in omap_i2c_mux_pins(int bus).
We don't have to do it manually here. Thanks!
Index: linux-beagle/arch/arm/mach-omap2/board-omap3beagle.c
===
--- linux-beagle.orig/arch/arm/mach-omap2/board-omap3beagle.c
+++ linux-beagle/arch/arm/mach-omap2/board-omap3beagle.c
@@ -40,7 +40,9 @@ static struct omap_uart_config omap3_bea
static int __init omap3_beagle_i2c_init(void)
{
omap_register_i2c_bus(1, 2600, NULL, 0);
+#ifdef CONFIG_I2C2_OMAP_BEAGLE
omap_register_i2c_bus(2, 400, NULL, 0);
+#endif
omap_register_i2c_bus(3, 400, NULL, 0);
return 0;
}
Index: linux-beagle/drivers/i2c/busses/Kconfig
===
--- linux-beagle.orig/drivers/i2c/busses/Kconfig
+++ linux-beagle/drivers/i2c/busses/Kconfig
@@ -332,10 +332,27 @@ config I2C_OMAP
default y if MACH_OMAP_H3 || MACH_OMAP_OSK
help
If you say yes to this option, support will be included for the
- I2C interface on the Texas Instruments OMAP1/2 family of processors.
- Like OMAP1510/1610/1710/5912 and OMAP242x.
+ I2C interface on the Texas Instruments OMAP1/2/3 family of
+ processors.
+ Like OMAP1510/1610/1710/5912, OMAP242x, OMAP34x and OMAP35x.
For details see http://www.ti.com/omap.
+config I2C2_OMAP_BEAGLE
+ bool Enable I2C2 for OMAP3 BeagleBoard
+ depends on ARCH_OMAP MACH_OMAP3_BEAGLE
+ select OMAP_MUX
+ default n
+ help
+ Say Y here if you want to enable I2C bus 2 at OMAP3 based
+ BeagleBoard.
+ I2C2 at BeagleBoard is connected to expansion connector, i.e. unused
+ if nothing is connected to this connector. As internal OMAP3 pull up
+ resistors are not strong enough, enabled but unused I2C2 bus results
+ in error messages (e.g. I2C timeouts). Enable this only if you have
+ something connected to I2C2 at board's expansion connector and this
+ extension has additional pull up resistors for I2C2 bus.
+
+
config I2C_PARPORT
tristate Parallel port adapter
depends on PARPORT
--
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] Added support for OMAP35x processor series
Why can't the detection happen at runtime? No mechanism as of now. ~sanjeev -Original Message- From: Igor Stoppa [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2008 3:21 PM To: Premi, Sanjeev Cc: Tony Lindgren; linux-omap@vger.kernel.org Subject: RE: [PATCH] Added support for OMAP35x processor series On Tue, 2008-08-05 at 15:09 +0530, ext Premi, Sanjeev wrote: This patch is needed to ensure that we can make decisions based on the processor capabilities. E.g. OMAP3503 does not contain a DSP. We shouldn't be trying to disable/ manage the clocks for DSP on this processor. Same for SGX. Why can't the detection happen at runtime? Enabling NEON is support iby default is just based on the number of requests I have been getting from various users. Huh? [sp] Linux releases on OMAP35x based on 2.6.22 are available for download since MAR '08. -- Cheers, Igor --- Igor Stoppa Maemo Software - 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
Re: [PATCH] Enable SYSOFFMODE use
* Peter 'p2' De Schrijver [EMAIL PROTECTED] [080721 19:03]: Signed-off-by: Peter 'p2' De Schrijver [EMAIL PROTECTED] --- arch/arm/mach-omap2/smartreflex.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c index 0f3a659..b41fe96 100644 --- a/arch/arm/mach-omap2/smartreflex.c +++ b/arch/arm/mach-omap2/smartreflex.c @@ -396,17 +396,17 @@ static void sr_configure_vc(void) /* Setup voltctrl and other setup times */ /* XXX CONFIG_SYSOFFMODE has not been implemented yet */ -#ifdef CONFIG_SYSOFFMODE - prm_write_mod_reg(OMAP3430_AUTO_OFF | OMAP3430_AUTO_RET, - OMAP3430_GR_MOD, +#ifdef CONFIG_OMAP_SYSOFFMODE + prm_write_mod_reg(OMAP3430_AUTO_OFF | OMAP3430_AUTO_RET | + OMAP3430_SEL_OFF, OMAP3430_GR_MOD, OMAP3_PRM_VOLTCTRL_OFFSET); prm_write_mod_reg(OMAP3430_CLKSETUP_DURATION, OMAP3430_GR_MOD, OMAP3_PRM_CLKSETUP_OFFSET); prm_write_mod_reg((OMAP3430_VOLTSETUP_TIME2 - OMAP3430_VOLTSETUP_TIME2_OFFSET) | + OMAP3430_SETUP_TIME2_SHIFT) | (OMAP3430_VOLTSETUP_TIME1 - OMAP3430_VOLTSETUP_TIME1_OFFSET), + OMAP3430_SETUP_TIME1_SHIFT), OMAP3430_GR_MOD, OMAP3_PRM_VOLTSETUP1_OFFSET); prm_write_mod_reg(OMAP3430_VOLTOFFSET_DURATION, OMAP3430_GR_MOD, Do we need the CONFIG_SYSOFFMODE option? How about just add /sys/power/off_while_idle and if that's set to 1 then allow off mode? 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: [PATCHv2 1/2] TWL4030: mark init-only functions as __init
* Paul Walmsley [EMAIL PROTECTED] [080805 00:17]:
Mark many functions in twl4030-core.c as __init.
This does not apply cleanly, maybe there's still some other twl patch
missing? Can you check and refresh as needed. The second patch applies,
so I'll push that today.
Tony
Signed-off-by: Paul Walmsley [EMAIL PROTECTED]
---
drivers/i2c/chips/twl4030-core.c | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/chips/twl4030-core.c
b/drivers/i2c/chips/twl4030-core.c
index 47d547d..54e392b 100644
--- a/drivers/i2c/chips/twl4030-core.c
+++ b/drivers/i2c/chips/twl4030-core.c
@@ -681,7 +681,8 @@ static void do_twl4030_irq(unsigned int irq, irq_desc_t
*desc)
}
/* attach a client to the adapter */
-static int twl4030_detect_client(struct i2c_adapter *adapter, unsigned char
sid)
+static int __init twl4030_detect_client(struct i2c_adapter *adapter,
+ unsigned char sid)
{
int err = 0;
struct twl4030_client *twl;
@@ -730,7 +731,7 @@ static int twl4030_detect_client(struct i2c_adapter
*adapter, unsigned char sid)
}
/* adapter callback */
-static int twl4030_attach_adapter(struct i2c_adapter *adapter)
+static int __init twl4030_attach_adapter(struct i2c_adapter *adapter)
{
int i;
int ret = 0;
@@ -783,7 +784,7 @@ static int twl4030_detach_client(struct i2c_client
*client)
return 0;
}
-static struct task_struct *start_twl4030_irq_thread(int irq)
+static struct task_struct * __init start_twl4030_irq_thread(int irq)
{
struct task_struct *thread;
@@ -801,7 +802,7 @@ static struct task_struct *start_twl4030_irq_thread(int
irq)
* These three functions should be part of Voltage frame work
* added here to complete the functionality for now.
*/
-static int protect_pm_master(void)
+static int __init protect_pm_master(void)
{
int e = 0;
@@ -810,7 +811,7 @@ static int protect_pm_master(void)
return e;
}
-static int unprotect_pm_master(void)
+static int __init unprotect_pm_master(void)
{
int e = 0;
@@ -821,7 +822,7 @@ static int unprotect_pm_master(void)
return e;
}
-static int power_companion_init(void)
+static int __init power_companion_init(void)
{
struct clk *osc;
u32 rate;
@@ -866,7 +867,7 @@ static int power_companion_init(void)
* don't know whether the COR bit is set in module_SIH_CTRL. Returns
* the status from the I2C read operation.
*/
-static int twl4030_i2c_clear_isr(u8 mod_no, u8 reg)
+static int __init twl4030_i2c_clear_isr(u8 mod_no, u8 reg)
{
int res;
u8 tmp;
@@ -878,7 +879,7 @@ static int twl4030_i2c_clear_isr(u8 mod_no, u8 reg)
return twl4030_i2c_write_u8(mod_no, 0xff, reg);
}
-static void twl_init_irq(void)
+static void __init twl_init_irq(void)
{
int i, j;
int res = 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
--
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] Remove double MODULE_ALIAS declaration.
* Roman Tereshonkov [EMAIL PROTECTED] [080626 17:23]:
Only once MODULE_ALIAS declaration is enough.
Columns are counted from 0 to n_cols - 1.
Pushing today.
Tony
Signed-off-by: Roman Tereshonkov [EMAIL PROTECTED]
---
drivers/input/keyboard/omap-twl4030keypad.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/input/keyboard/omap-twl4030keypad.c
b/drivers/input/keyboard/omap-twl4030keypad.c
index 20aeb3c..68c5b8e 100644
--- a/drivers/input/keyboard/omap-twl4030keypad.c
+++ b/drivers/input/keyboard/omap-twl4030keypad.c
@@ -158,7 +158,7 @@ static void twl4030_kp_scan(int release_all)
if (!changed)
continue;
- for (col = 0; col n_cols + 1; col++) {
+ for (col = 0; col n_cols; col++) {
int key;
if (!(changed (1 col)))
@@ -373,4 +373,3 @@ MODULE_ALIAS(platform:omap_twl4030keypad);
MODULE_AUTHOR(Texas Instruments);
MODULE_DESCRIPTION(OMAP TWL4030 Keypad Driver);
MODULE_LICENSE(GPL);
-MODULE_ALIAS(platform:omap_twl4030keypad);
--
1.5.5.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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] Added support for OMAP35x processor series
* Sanjeev Premi [EMAIL PROTECTED] [080801 14:50]: This patch adds basic support for the OMAP35x Applications Processors. (See: http://focus.ti.com/general/docs/gencontent.tsp?contentId=46725) As you will notice, NEON SIMD coprocessor is enabled by default for these processors. Do we really need this? To me it seems like our CPU detection should figure out the processor is 34xx and specifically 35xx something. Are there Cortex A8 processors with no Neon hardware? Tony Signed-off-by: Sanjeev Premi [EMAIL PROTECTED] --- arch/arm/mach-omap2/Kconfig | 50 ++- 1 files changed, 49 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index bb6d695..63d7cdd 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -25,6 +25,54 @@ config ARCH_OMAP3430 depends on ARCH_OMAP3 ARCH_OMAP34XX select ARCH_OMAP_OTG +config ARCH_OMAP35XX + bool OMAP35x Family + select ARCH_OMAP3 + select ARCH_OMAP34XX + select ARCH_OMAP3430 + select OMAP3430_ES2 + select NEON + help + OMAP35x family of processors based on ARM Cortex-A8 + in combination with IVA2.2 core and OpenGL ES2.0 + compatible graphics engine. + + ARM Cortex-A8 contains NEON SIMD coprocessor. + +choice + prompt Current choice + default ARCH_OMAP3503 + +config ARCH_OMAP3503 + bool OMAP3503 + depends on ARCH_OMAP35XX + help + Contains ARM Cortex-A8 processor. + +config ARCH_OMAP3515 + bool OMAP3515 + depends on ARCH_OMAP35XX + help +Contains ARM Cortex-A8 processor and SGX530 subsystem +for 2D and 3D graphics acceleration. + +config ARCH_OMAP3525 + bool OMAP3525 + depends on ARCH_OMAP35XX + help + Contains ARM Cortex-A8 processor and IVA2.2 subsystem + with a C64x+ DSP core. + +config ARCH_OMAP3530 + bool OMAP3530 + depends on ARCH_OMAP35XX + help +Contains ARM Cortex-A8 processor, IVA2.2 subsystem +with a C64x+ DSP Core and SGX530 subsystem for 2D +and 3D graphics acceleration. + +endchoice + comment OMAP Board Type depends on ARCH_OMAP2 || ARCH_OMAP3 @@ -117,7 +165,7 @@ config MACH_OMAP_3430SDP config MACH_OMAP3EVM bool OMAP 3530 EVM board - depends on ARCH_OMAP3 ARCH_OMAP34XX + depends on ARCH_OMAP35XX config MACH_OMAP3_BEAGLE bool OMAP3 BEAGLE board -- 1.5.6 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] OMAP3 Beagle: add nand support
* Koen Kooi [EMAIL PROTECTED] [080804 18:01]:
Can this patch go in as well today?
Pushing the refreshed series posted by Dirk today.
Tony
regards,
Koen
Op 11 jun 2008, om 20:19 heeft Steve Sakoman het volgende geschreven:
Add nand support to omap3beagle
Signed-off-by: Steve Sakoman [EMAIL PROTECTED]
---
arch/arm/mach-omap2/Makefile |3
arch/arm/mach-omap2/board-omap3beagle-flash.c | 119
++
arch/arm/mach-omap2/board-omap3beagle.c |1
include/asm-arm/arch-omap/board-omap3beagle.h |2
4 files changed, 124 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/
Makefile
index 13d0043..d582b8f 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -44,7 +44,8 @@ obj-$(CONFIG_MACH_OMAP3EVM)+=
board-omap3evm.o \
board-omap3evm-flash.o
obj-$(CONFIG_MACH_OMAP3_BEAGLE) += board-omap3beagle.o \
usb-musb.o usb-ehci.o \
- hsmmc.o
+ hsmmc.o \
+ board-omap3beagle-flash.o
obj-$(CONFIG_MACH_OMAP_LDP) += board-ldp.o \
hsmmc.o \
usb-musb.o
diff --git a/arch/arm/mach-omap2/board-omap3beagle-flash.c b/arch/
arm/mach-omap2/board-omap3beagle-flash.c
new file mode 100644
index 000..5346df0
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3beagle-flash.c
@@ -0,0 +1,119 @@
+/*
+ * board-omap3beagle-flash.c
+ *
+ * Copyright (c) 2008 Texas Instruments
+ *
+ * Modified from board-omap3evm-flash.c
+ *
+ * This program is free software; you can redistribute it and/or
modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
+#include linux/types.h
+#include linux/io.h
+
+#include asm/mach/flash.h
+#include asm/arch/board.h
+#include asm/arch/gpmc.h
+#include asm/arch/nand.h
+
+#define GPMC_CS0_BASE 0x60
+#define GPMC_CS_SIZE 0x30
+
+static struct mtd_partition omap3beagle_nand_partitions[] = {
+/* All the partition sizes are listed in terms of NAND block size */
+{
+.name = X-Loader,
+.offset = 0,
+.size = 4*(64 * 2048),
+.mask_flags = MTD_WRITEABLE,/* force read-only */
+},
+{
+.name = U-Boot,
+.offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+.size = 15*(64 * 2048),
+.mask_flags = MTD_WRITEABLE,/* force read-only */
+},
+{
+.name = U-Boot Env,
+.offset = MTDPART_OFS_APPEND, /* Offset = 0x26 */
+.size = 1*(64 * 2048),
+},
+{
+.name = Kernel,
+.offset = MTDPART_OFS_APPEND, /* Offset = 0x28 */
+.size = 32*(64 * 2048),
+},
+{
+.name = File System,
+.offset = MTDPART_OFS_APPEND, /* Offset = 0x68 */
+.size = MTDPART_SIZ_FULL,
+},
+};
+
+static struct omap_nand_platform_data omap3beagle_nand_data = {
+.parts = omap3beagle_nand_partitions,
+.nr_parts = ARRAY_SIZE(omap3beagle_nand_partitions),
+.dma_channel= -1, /* disable DMA in OMAP NAND driver */
+.nand_setup = NULL,
+.dev_ready = NULL,
+};
+
+static struct resource omap3beagle_nand_resource = {
+.flags = IORESOURCE_MEM,
+};
+
+static struct platform_device omap3beagle_nand_device = {
+.name = omap2-nand,
+.id = -1,
+.dev= {
+.platform_data = omap3beagle_nand_data,
+},
+.num_resources = 1,
+.resource = omap3beagle_nand_resource,
+};
+
+
+void __init omap3beagle_flash_init(void)
+{
+u8 cs = 0;
+u8 nandcs = GPMC_CS_NUM + 1;
+
+u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
+
+/* find out the chip-select on which NAND exists */
+while (cs GPMC_CS_NUM) {
+u32 ret = 0;
+ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+
+if ((ret 0xC00) == 0x800) {
+printk(KERN_INFO Found NAND on CS%d\n, cs);
+if (nandcs GPMC_CS_NUM)
+nandcs = cs;
+}
+cs++;
+}
+
+if (nandcs GPMC_CS_NUM) {
+printk(KERN_INFO NAND: Unable to find configuration
+ in
Re: [PATCH] ARM MMU: add strongly-ordered memory type
On Mon, Aug 04, 2008 at 05:40:57PM -0600, Paul Walmsley wrote:
Add the MT_MEMORY_STRONGLY_ORDERED memory type for ARM strongly ordered
memory.
This is used on OMAP3 for on-board SRAM. On OMAP, SRAM is used for code
that changes the SDRAM controller's clock, temporarily blocking access to
SDRAM. During this period, as code executes from SRAM, the ARM cache
controller can attempt to write dirty cache lines back to SDRAM to make
room for SRAM cache lines, causing the MPU subsystem to hang. To avoid
this, we mark SRAM as strongly- ordered memory.
Is the controller allowed to write dirty cache lines out at any time it
likes? Surely a better fix is to drain the cache of the changes before
changing the clock for the SDRAM?
Problem noted by Richard Woodruff [EMAIL PROTECTED]. Fix derived
from the TI CDP codebase.
Signed-off-by: Paul Walmsley [EMAIL PROTECTED]
---
arch/arm/mm/mmu.c |5 +
include/asm-arm/mach/map.h | 13 +++--
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 2d6d682..5b56539 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -239,6 +239,11 @@ static struct mem_type mem_types[] = {
.prot_sect = PMD_TYPE_SECT,
.domain= DOMAIN_KERNEL,
},
+ [MT_MEMORY_STRONGLY_ORDERED] = {
+ .prot_sect = PMD_TYPE_SECT | PMD_SECT_AP_WRITE |
+ PMD_SECT_UNCACHED,
+ .domain= DOMAIN_KERNEL,
+ },
};
const struct mem_type *get_mem_type(unsigned int type)
diff --git a/include/asm-arm/mach/map.h b/include/asm-arm/mach/map.h
index 7ef3c83..8cb46b7 100644
--- a/include/asm-arm/mach/map.h
+++ b/include/asm-arm/mach/map.h
@@ -19,12 +19,13 @@ struct map_desc {
};
/* types 0-3 are defined in asm/io.h */
-#define MT_CACHECLEAN4
-#define MT_MINICLEAN 5
-#define MT_LOW_VECTORS 6
-#define MT_HIGH_VECTORS 7
-#define MT_MEMORY8
-#define MT_ROM 9
+#define MT_CACHECLEAN4
+#define MT_MINICLEAN 5
+#define MT_LOW_VECTORS 6
+#define MT_HIGH_VECTORS 7
+#define MT_MEMORY8
+#define MT_ROM 9
+#define MT_MEMORY_STRONGLY_ORDERED 10
#define MT_NONSHARED_DEVICE MT_DEVICE_NONSHARED
#define MT_IXP2000_DEVICEMT_DEVICE_IXP2000
---
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php
--
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
--
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] mach-omap2: resolve remaining sparse issues
* Paul Walmsley [EMAIL PROTECTED] [080718 06:13]: This series fixes the current set of sparse warnings in arch/arm/mach-omap2 for the omap2_evm_defconfig, n800_defconfig, and omap_3430sdp_defconfig configs. A few checkpatch issues are also addressed. Boot-tested on N800 and 3430SDP ES2. Pushing these patches today. Tony - Paul size: textdata bss dec hex filename 2922973 134480 100984 3158437 3031a5 vmlinux.omap2evm.orig 2922941 134480 100984 3158405 303185 vmlinux.omap2evm --- Paul Walmsley (4): SmartReflex: fix sparse issues mach-omap2: fix sparse warnings, some style issues for OMAP2 builds mach-omap2: mark casts between integers and pointers with __force Add prototypes for public functions or declare private functions static: arch/arm/mach-omap2/board-2430sdp-flash.c | 28 ++-- arch/arm/mach-omap2/board-n800-audio.c| 14 -- arch/arm/mach-omap2/board-n800-camera.c |2 ++ arch/arm/mach-omap2/board-n800.h |2 ++ arch/arm/mach-omap2/clock24xx.c |2 +- arch/arm/mach-omap2/clock24xx.h |6 -- arch/arm/mach-omap2/clock34xx.h |9 ++--- arch/arm/mach-omap2/gpmc.c| 11 +++ arch/arm/mach-omap2/irq.c |4 ++-- arch/arm/mach-omap2/mailbox.c |4 ++-- arch/arm/mach-omap2/mcbsp.c |2 +- arch/arm/mach-omap2/mmu.h |4 ++-- arch/arm/mach-omap2/mux.c |2 +- arch/arm/mach-omap2/pm.c |3 ++- arch/arm/mach-omap2/pm.h | 16 ++-- arch/arm/mach-omap2/pm34xx.c |2 +- arch/arm/mach-omap2/smartreflex.c | 10 ++ arch/arm/mach-omap2/smartreflex.h |3 +++ include/asm-arm/arch-omap/mailbox.h |2 ++ include/asm-arm/arch-omap/prcm.h |4 20 files changed, 80 insertions(+), 50 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment
Op 5 aug 2008, om 14:14 heeft Tony Lindgren het volgende geschreven:
* Koen Kooi [EMAIL PROTECTED] [080805 15:11]:
Op 19 jun 2008, om 14:54 heeft Woodruff, Richard het volgende
geschreven:
Hi,
I'll resend this to the omap list. I had originally sent it with
some
pictures but I guess they were too big for the lists. Individual
should have got them.
If anyone has the time this is a good to test with. If you have
dynamic tick enabled it can double performance of high rate
interrupt
things like MUSB.
This patch has been working for me quite well these last few week,
any
chance it can to into git?
This needs to go in via LKML, I think Thomas Gleixner is looking
into it.
Great! It seems that the bulk of the patches OE applies to the
beagleboard kernel are on their way into upstream :)
regards,
Koen
Tony
regards,
Koen
If anyone wants I'll re-send larger trace pictures individually.
From: Woodruff, Richard, Monday, June 16, 2008 7:06 PM
It simply does a check to see if the about to be reprogrammed 1
shot
already is the last event programmed in the hardware. If it is it
skips
calling the hardware.
In my device I get many interrupts from a high speed USB device
in a
very short period of time. The system spends a lot of time
reprogramming the hardware timer which is in a slower timing domain
as
compared to the CPU. This results in the CPU spending a huge
amount
of
time waiting for the timer posting to be done. All of this
reprogramming is useless as the wake up time has not changed.
As measured using ETM trace this drops my reprogramming penalty
from
almost 60% CPU load down to 15% during high interrupt rate. If you
like
I can send traces to show this.
Attached are some results on OMAP-ARM from USB-OTG:
As host:
[EMAIL PROTECTED] /]# mount -t vfat /dev/sda1 /mnt/
[EMAIL PROTECTED] /]# time -p cp /mnt/OE.mtn.bz2 /dev/null
real 32.51
user 0.02
sys 1.05
[EMAIL PROTECTED] /]# umount /mnt/
[EMAIL PROTECTED] /]# mount -t vfat /dev/sda1 /mnt/
[EMAIL PROTECTED] /]# time -p cp /mnt/OE.mtn.bz2 /dev/null
real 17.92
user 0.05
sys 1.57
As Client:
Attached are some visuals as of client doing gadget zero tests.
Pictures clearly show before a domination by timer reprogram and
after
not.
Regards,
Richard W.
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index b854a89..ff6b967 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -254,6 +254,17 @@ void tick_nohz_stop_sched_tick(void)
/* Schedule the tick, if we are at least one jiffie off */
if ((long)delta_jiffies = 1) {
+ /*
+ * calculate the expiry time for the next timer wheel
+ * timer
+ */
+ expires = ktime_add_ns(last_update,
tick_period.tv64 *
+ delta_jiffies);
+
+ /* Skip reprogram of event if its not changed */
+ if(ts-tick_stopped ktime_equal(expires, dev-
next_event))
+ goto out2;
+
if (delta_jiffies 1)
cpu_set(cpu, nohz_cpu_mask);
/*
@@ -304,12 +315,7 @@ void tick_nohz_stop_sched_tick(void)
goto out;
}
- /*
-* calculate the expiry time for the next timer
wheel
-* timer
-*/
- expires = ktime_add_ns(last_update,
tick_period.tv64 *
- delta_jiffies);
+ /* Mark expiries */
ts-idle_expires = expires;
if (ts-nohz_mode == NOHZ_MODE_HIGHRES) {
@@ -328,6 +334,7 @@ void tick_nohz_stop_sched_tick(void)
tick_do_update_jiffies64(ktime_get());
cpu_clear(cpu, nohz_cpu_mask);
}
+out2:
raise_softirq_irqoff(TIMER_SOFTIRQ);
out:
ts-next_jiffies = next_jiffies;
--
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
PGP.sig
Description: This is a digitally signed message part
RE: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment
This needs to go in via LKML, I think Thomas Gleixner is looking into it. * Today it is in Andrew Morton's tree. * Thomas has been in copy and Andrew has ack'ed it. So far Thomas hasn't had much interest. I haven't bugged him since Andrew picked it up as I guess it will flow in from his tree. I have locally one more change to this code which also makes a good performance difference dealing with the soft-irq task. I wanted more testing before pushing that. Regards, Richard W. -- 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] OMAP2/3 clockdomains: combine pwrdm, pwrdm_name into union in struct clockdomain
* Paul Walmsley [EMAIL PROTECTED] [080718 11:22]:
struct clockdomain contains a struct powerdomain *pwrdm and const char
*pwrdm_name. The pwrdm_name is only used at initialization to look up
the appropriate pwrdm pointer. Combining these into a union saves
about 100 bytes on 3430SDP. This patch should not cause any change in
kernel function.
Boot-tested on 3430SDP ES2.
Pushing today.
Tony
Signed-off-by: Paul Walmsley [EMAIL PROTECTED]
size:
textdata bss dec hex filename
3391587 157104 107136 3655827 37c893 vmlinux.3430sdp.orig
3391555 157032 107136 3655723 37c82b vmlinux.3430sdp
---
arch/arm/mach-omap2/clockdomain.c | 58
++-
arch/arm/mach-omap2/clockdomains.h | 54 +++--
include/asm-arm/arch-omap/clockdomain.h | 22 +++-
3 files changed, 67 insertions(+), 67 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 6e5f892..caa7992 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -71,14 +71,14 @@ static void _autodep_lookup(struct clkdm_pwrdm_autodep
*autodep)
if (!omap_chip_is(autodep-omap_chip))
return;
- pwrdm = pwrdm_lookup(autodep-pwrdm_name);
+ pwrdm = pwrdm_lookup(autodep-pwrdm.name);
if (!pwrdm) {
pr_debug(clockdomain: _autodep_lookup: powerdomain %s
- does not exist\n, autodep-pwrdm_name);
+ does not exist\n, autodep-pwrdm.name);
WARN_ON(1);
return;
}
- autodep-pwrdm = pwrdm;
+ autodep-pwrdm.ptr = pwrdm;
return;
}
@@ -95,16 +95,13 @@ static void _clkdm_add_autodeps(struct clockdomain *clkdm)
{
struct clkdm_pwrdm_autodep *autodep;
- for (autodep = autodeps; autodep-pwrdm_name; autodep++) {
- if (!autodep-pwrdm)
- continue;
-
+ for (autodep = autodeps; autodep-pwrdm.ptr; autodep++) {
pr_debug(clockdomain: adding %s sleepdep/wkdep for
- pwrdm %s\n, autodep-pwrdm_name,
- clkdm-pwrdm-name);
+ pwrdm %s\n, autodep-pwrdm.ptr-name,
+ clkdm-pwrdm.ptr-name);
- pwrdm_add_sleepdep(clkdm-pwrdm, autodep-pwrdm);
- pwrdm_add_wkdep(clkdm-pwrdm, autodep-pwrdm);
+ pwrdm_add_sleepdep(clkdm-pwrdm.ptr, autodep-pwrdm.ptr);
+ pwrdm_add_wkdep(clkdm-pwrdm.ptr, autodep-pwrdm.ptr);
}
}
@@ -120,16 +117,13 @@ static void _clkdm_del_autodeps(struct clockdomain
*clkdm)
{
struct clkdm_pwrdm_autodep *autodep;
- for (autodep = autodeps; autodep-pwrdm_name; autodep++) {
- if (!autodep-pwrdm)
- continue;
-
+ for (autodep = autodeps; autodep-pwrdm.ptr; autodep++) {
pr_debug(clockdomain: removing %s sleepdep/wkdep for
- pwrdm %s\n, autodep-pwrdm_name,
- clkdm-pwrdm-name);
+ pwrdm %s\n, autodep-pwrdm.ptr-name,
+ clkdm-pwrdm.ptr-name);
- pwrdm_del_sleepdep(clkdm-pwrdm, autodep-pwrdm);
- pwrdm_del_wkdep(clkdm-pwrdm, autodep-pwrdm);
+ pwrdm_del_sleepdep(clkdm-pwrdm.ptr, autodep-pwrdm.ptr);
+ pwrdm_del_wkdep(clkdm-pwrdm.ptr, autodep-pwrdm.ptr);
}
}
@@ -179,7 +173,7 @@ void clkdm_init(struct clockdomain **clkdms,
autodeps = init_autodeps;
if (autodeps)
- for (autodep = autodeps; autodep-pwrdm_name; autodep++)
+ for (autodep = autodeps; autodep-pwrdm.ptr; autodep++)
_autodep_lookup(autodep);
}
@@ -202,13 +196,13 @@ int clkdm_register(struct clockdomain *clkdm)
if (!omap_chip_is(clkdm-omap_chip))
return -EINVAL;
- pwrdm = pwrdm_lookup(clkdm-pwrdm_name);
+ pwrdm = pwrdm_lookup(clkdm-pwrdm.name);
if (!pwrdm) {
pr_debug(clockdomain: clkdm_register %s: powerdomain %s
- does not exist\n, clkdm-name, clkdm-pwrdm_name);
+ does not exist\n, clkdm-name, clkdm-pwrdm.name);
return -EINVAL;
}
- clkdm-pwrdm = pwrdm;
+ clkdm-pwrdm.ptr = pwrdm;
mutex_lock(clkdm_mutex);
/* Verify that the clockdomain is not already registered */
@@ -242,7 +236,7 @@ int clkdm_unregister(struct clockdomain *clkdm)
if (!clkdm)
return -EINVAL;
- pwrdm_del_clkdm(clkdm-pwrdm, clkdm);
+ pwrdm_del_clkdm(clkdm-pwrdm.ptr, clkdm);
mutex_lock(clkdm_mutex);
list_del(clkdm-node);
@@ -327,7 +321,7 @@ struct powerdomain *clkdm_get_pwrdm(struct clockdomain
*clkdm)
if (!clkdm)
return NULL;
- return clkdm-pwrdm;
+ return clkdm-pwrdm.ptr;
}
Re: [PATCH] Free HDQ clocks in error path
* Madhusudhan Chikkature [EMAIL PROTECTED] [080722 15:04]:
Hi,
This patch provides the fix to free the HDQ clocks in the error path.
Regards,
Madhu
-
From: Madhusudhan Chikkature[EMAIL PROTECTED]
ARM: OMAP3: Free HDQ clocks when a read is tried with no battery connected
Pushing today.
Tony
Signed-off-by: Madhusudhan Chikkature[EMAIL PROTECTED]
---
drivers/w1/masters/omap_hdq.c |5 -
1 files changed, 4 insertions(+), 1 deletion(-)
Index: linux-omap-ti.git-07102008/drivers/w1/masters/omap_hdq.c
===
--- linux-omap-ti.git-07102008.orig/drivers/w1/masters/omap_hdq.c
2008-07-02
20:10:38.0 +0530
+++ linux-omap-ti.git-07102008/drivers/w1/masters/omap_hdq.c 2008-07-16
12:17:42.0 +0530
@@ -515,8 +515,11 @@ static u8 omap_w1_read_byte(void *data)
int ret;
ret = hdq_read_byte(val);
- if (ret)
+ if (ret) {
+ init_trans = 0;
+ omap_hdq_put();
return -1;
+ }
/* Write followed by a read, release the module */
if (init_trans) {
--
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 1/3] Triton BCI driver board/device setup for OMAP3430
* Felipe Balbi [EMAIL PROTECTED] [080723 10:32]: On Wed, 23 Jul 2008 10:16:27 +0530, Madhusudhan Chikkature [EMAIL PROTECTED] wrote: Hi Felipe, Tony, weird that we still have these prototypes in these headers. Could be some merging conflict ? Yes. I see that these prototypes are still present in the board3430 and board2430 header files in the omap tree. Anyways, please apply the attached patch. We're using usb_musb_init() and usb_ehci_init() now. You mean I should apply the attached patch you sent for local use, right? And I guess I dont need to resend this perticular BCI patch, am I correct? No :-) that was to Tony. Just replied to your mail so it's easy to see why we need that patch :-) Pushing these today. Do you have a patch for moving the extern prototypes into the twl header? 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/4] OMAP: MENELAUS: Improvements on menelaus
* Carlos Aguiar [EMAIL PROTECTED] [080805 16:40]: ext Tony Lindgren wrote: * Felipe Balbi [EMAIL PROTECTED] [080805 12:35]: On Tue, Aug 05, 2008 at 11:57:53AM +0300, Tony Lindgren wrote: Yeah, let's rename it as it's not in mainline yet. I'll apply this series, then the next set of patches can take care of the renaming. It it in mainline actually, check your drivers/i2c/chips and it was added by you :-p commit 0c4a59fed41bdd4c30ce0999a87f30a812f29ee2 Author: Tony Lindgren [EMAIL PROTECTED] Date: Tue Jul 17 04:06:09 2007 -0700 OMAP: add TI TWL92330/Menelaus Power Management chip driver Add Texas Instruments TWL92330/Menelaus Power Management chip driver. This includes voltage regulators, Dual slot memory card tranceivers and real-time clock(RTC). The support for RTC is integrated with this driver only; it is not separate module. Passes 'rtctest' on OMAP H4 EVM, other than lack of periodic (1/N second) IRQs. System wakeup alarms (from suspend-to-RAM) work too. The battery keeps the RTC active over power off, so once you set clock (rdate/ntpdate/etc, then hwclock -w) then RTC_HCTOSYS at boot time will behave as expected. Cc: Jean Delvare [EMAIL PROTECTED] Cc: Tony Lindgren [EMAIL PROTECTED] Cc: David Brownell [EMAIL PROTECTED] Signed-off-by: Trilok Soni [EMAIL PROTECTED] Acked-by: Alessandro Zummo [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] Maybe someone sent that patch for you ? Oops :) I guess I'm over a year behind current developments after my vacation! Anyways, sounds like people want to rename it. Carlos, can you send your patches to the i2c list for integration? Tony Hi Tony and folks, So, I'm going to preparing and send a new series by today to i2c list for integration so that such series: - Align the code from l-o tree to mainline tree. - Apply the series of four patches I just sent to l-o. - And than a last one to rename files to twl92230, as folks agreeded. Sounds good to me! 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 2/2] Dynamic allocation for mcbsp devices. and related changes
* chandra shekhar [EMAIL PROTECTED] [080625 18:02]:
From: chandra shekhar [EMAIL PROTECTED]
This patch provides dynamic allocation for mcbsp device.
no. of mcbsp for each cpu is determined at runtime and accordingly memory is
allocated. id check macro definition has been changed.
Pushing today.
Tony
Signed-off-by: chandra shekhar [EMAIL PROTECTED]
---
arch/arm/mach-omap1/mcbsp.c | 37 +--
arch/arm/mach-omap2/mcbsp.c | 21 +-
arch/arm/plat-omap/devices.c |7
arch/arm/plat-omap/mcbsp.c| 359
+-
include/asm-arm/arch-omap/mcbsp.h |9
5 files changed, 224 insertions(+), 209 deletions(-)
Index: linux-omap-2.6/arch/arm/mach-omap1/mcbsp.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap1/mcbsp.c 2008-06-25
15:54:04.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap1/mcbsp.c2008-06-25
19:57:26.0 +0530
@@ -103,30 +103,6 @@
{ }
#endif
-static int omap1_mcbsp_check(unsigned int id)
-{
- /* REVISIT: Check correctly for number of registered McBSPs */
- if (cpu_is_omap730()) {
- if (id OMAP_MAX_MCBSP_COUNT - 2) {
-printk(KERN_ERR OMAP-McBSP: McBSP%d doesn't exist\n,
- id + 1);
-return -ENODEV;
- }
- return 0;
- }
-
- if (cpu_is_omap15xx() || cpu_is_omap16xx()) {
- if (id OMAP_MAX_MCBSP_COUNT - 1) {
- printk(KERN_ERR OMAP-McBSP: McBSP%d doesn't exist\n,
- id + 1);
- return -ENODEV;
- }
- return 0;
- }
-
- return -ENODEV;
-}
-
static void omap1_mcbsp_request(unsigned int id)
{
/*
@@ -151,7 +127,6 @@
}
static struct omap_mcbsp_ops omap1_mcbsp_ops = {
- .check = omap1_mcbsp_check,
.request= omap1_mcbsp_request,
.free = omap1_mcbsp_free,
};
@@ -263,6 +238,18 @@
}
if (cpu_is_omap730())
+ omap_mcbsp_count = OMAP730_MCBSP_PDATA_SZ;
+ if (cpu_is_omap15xx())
+ omap_mcbsp_count = OMAP15XX_MCBSP_PDATA_SZ;
+ if (cpu_is_omap16xx())
+ omap_mcbsp_count = OMAP16XX_MCBSP_PDATA_SZ;
+
+ mcbsp_ptr = kzalloc(omap_mcbsp_count * sizeof(struct omap_mcbsp *),
+ GFP_KERNEL);
+ if (!mcbsp_ptr)
+ return -ENOMEM;
+
+ if (cpu_is_omap730())
omap_mcbsp_register_board_cfg(omap730_mcbsp_pdata,
OMAP730_MCBSP_PDATA_SZ);
Index: linux-omap-2.6/arch/arm/mach-omap2/mcbsp.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/mcbsp.c 2008-06-25
15:54:04.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/mcbsp.c2008-06-25
19:56:14.0 +0530
@@ -117,18 +117,8 @@
omap2_mcbsp2_mux_setup();
}
-static int omap2_mcbsp_check(unsigned int id)
-{
- if (id OMAP_MAX_MCBSP_COUNT - 1) {
- printk(KERN_ERR OMAP-McBSP: McBSP%d doesn't exist\n, id + 1);
- return -ENODEV;
- }
- return 0;
-}
-
static struct omap_mcbsp_ops omap2_mcbsp_ops = {
.request= omap2_mcbsp_request,
- .check = omap2_mcbsp_check,
};
#ifdef CONFIG_ARCH_OMAP24XX
@@ -196,9 +186,18 @@
}
if (cpu_is_omap24xx())
+ omap_mcbsp_count = OMAP24XX_MCBSP_PDATA_SZ;
+ if (cpu_is_omap34xx())
+ omap_mcbsp_count = OMAP34XX_MCBSP_PDATA_SZ;
+
+ mcbsp_ptr = kzalloc(omap_mcbsp_count * sizeof(struct omap_mcbsp *),
+ GFP_KERNEL);
+ if (!mcbsp_ptr)
+ return -ENOMEM;
+
+ if (cpu_is_omap24xx())
omap_mcbsp_register_board_cfg(omap24xx_mcbsp_pdata,
OMAP24XX_MCBSP_PDATA_SZ);
-
if (cpu_is_omap34xx())
omap_mcbsp_register_board_cfg(omap34xx_mcbsp_pdata,
OMAP34XX_MCBSP_PDATA_SZ);
Index: linux-omap-2.6/arch/arm/plat-omap/devices.c
===
--- linux-omap-2.6.orig/arch/arm/plat-omap/devices.c 2008-06-25
15:55:06.0 +0530
+++ linux-omap-2.6/arch/arm/plat-omap/devices.c 2008-06-25
15:55:52.0
+0530
@@ -160,13 +160,6 @@
{
int i;
- if (size OMAP_MAX_MCBSP_COUNT) {
- printk(KERN_WARNING Registered too many McBSPs platform_data.
- Using maximum (%d) available.\n,
- OMAP_MAX_MCBSP_COUNT);
- size = OMAP_MAX_MCBSP_COUNT;
- }
-
omap_mcbsp_devices = kzalloc(size * sizeof(struct platform_device
Re: [PATCH 3/3] Fixes required for HSMMC driver to work as module
* Madhusudhan Chikkature [EMAIL PROTECTED] [080725 13:34]:
From: Madhusudhan Chikkature[EMAIL PROTECTED]
ARM: OMAP3: Fixes required to make HSMMC driver as module.
This patch provides the necessary fixes to make the HSMMC driver work as
loadble module.
This one does not apply, can you take a look?
Thanks,
Tony
Signed-off-by: Madhusudhan Chikkature[EMAIL PROTECTED]
Signed-off-by: Romit Dasgupta [EMAIL PROTECTED]
---
drivers/mmc/host/omap_hsmmc.c | 43
+++---
1 files changed, 32 insertions(+), 11 deletions(-)
Index: linux-omap-ti.git-07142008/drivers/mmc/host/omap_hsmmc.c
===
--- linux-omap-ti.git-07142008.orig/drivers/mmc/host/omap_hsmmc.c
2008-07-23
16:31:56.0 +0530
+++ linux-omap-ti.git-07142008/drivers/mmc/host/omap_hsmmc.c 2008-07-24
12:07:40.0 +0530
@@ -764,23 +764,27 @@ static int __init omap_mmc_probe(struct
if (IS_ERR(host-iclk)) {
ret = PTR_ERR(host-iclk);
host-iclk = NULL;
- goto err;
+ goto err1;
}
host-fclk = clk_get(pdev-dev, mmchs_fck);
if (IS_ERR(host-fclk)) {
ret = PTR_ERR(host-fclk);
host-fclk = NULL;
clk_put(host-iclk);
- goto err;
+ goto err1;
}
- if (clk_enable(host-fclk) != 0)
- goto err;
+ if (clk_enable(host-fclk) != 0) {
+ clk_put(host-iclk);
+ clk_put(host-fclk);
+ goto err1;
+ }
if (clk_enable(host-iclk) != 0) {
clk_disable(host-fclk);
+ clk_put(host-iclk);
clk_put(host-fclk);
- goto err;
+ goto err1;
}
host-dbclk = clk_get(pdev-dev, mmchsdb_fck);
@@ -873,12 +877,6 @@ static int __init omap_mmc_probe(struct
return 0;
-err:
- dev_dbg(mmc_dev(host-mmc), Probe Failed\n);
- if (host)
- mmc_free_host(mmc);
- return ret;
-
irq_err:
dev_dbg(mmc_dev(host-mmc), Unable to configure MMC IRQs\n);
clk_disable(host-fclk);
@@ -890,6 +888,11 @@ irq_err:
clk_put(host-dbclk);
}
+err1:
+ iounmap(host-base);
+err:
+ dev_dbg(mmc_dev(host-mmc), Probe Failed\n);
+ release_mem_region(res-start, res-end - res-start + 1);
if (host)
mmc_free_host(mmc);
return ret;
@@ -898,9 +901,26 @@ irq_err:
static int omap_mmc_remove(struct platform_device *pdev)
{
struct mmc_omap_host *host = platform_get_drvdata(pdev);
+ struct resource *res;
+ u16 vdd = 0;
+
+ if (!(OMAP_HSMMC_READ(host-base, HCTL) SDVSDET)) {
+ /*
+ * Set the vdd back to 3V,
+ * applicable for dual volt support.
+ */
+ vdd = fls(host-mmc-ocr_avail) - 1;
+ if (omap_mmc_switch_opcond(host, vdd) != 0)
+ host-mmc-ios.vdd = vdd;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (res)
+ release_mem_region(res-start, res-end - res-start + 1);
platform_set_drvdata(pdev, NULL);
if (host) {
+ mmc_remove_host(host-mmc);
host-pdata-cleanup(pdev-dev);
free_irq(host-irq, host);
if (mmc_slot(host).card_detect_irq)
@@ -917,6 +937,7 @@ static int omap_mmc_remove(struct platfo
}
mmc_free_host(host-mmc);
+ iounmap(host-base);
}
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: [PATCH 2/3]HSMMC fix for hotplug scenario with I/O in progress
* Madhusudhan Chikkature [EMAIL PROTECTED] [080725 13:33]:
From: Madhusudhan Chikkature[EMAIL PROTECTED]
ARM: OMAP3: HSMMC fix for hotplug scenario.
This patch fixes the inconsistancy noted if the card is removed from the slot
duing an active I/O.
Pushing today.
Tony
Signed-off-by: Madhusudhan Chikkature[EMAIL PROTECTED]
Signed-off-by: Romit Dasgupta [EMAIL PROTECTED]
---
drivers/mmc/host/omap_hsmmc.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
Index: linux-omap-ti.git-07142008/drivers/mmc/host/omap_hsmmc.c
===
--- linux-omap-ti.git-07142008.orig/drivers/mmc/host/omap_hsmmc.c
2008-07-17
16:07:05.0 +0530
+++ linux-omap-ti.git-07142008/drivers/mmc/host/omap_hsmmc.c 2008-07-17
16:08:48.0 +0530
@@ -85,6 +85,7 @@
#define INIT_STREAM_CMD 0x
#define DUAL_VOLT_OCR_BIT7
#define SRC (1 25)
+#define SRD (1 26)
#define OMAP_MMC1_DEVID 1
#define OMAP_MMC2_DEVID 2
@@ -301,6 +302,7 @@ static void mmc_dma_cleanup(struct mmc_o
static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
{
struct mmc_omap_host *host = dev_id;
+ struct mmc_data *data;
int end_cmd = 0, end_trans = 0, status;
if (host-cmd == NULL host-data == NULL) {
@@ -309,6 +311,7 @@ static irqreturn_t mmc_omap_irq(int irq,
return IRQ_HANDLED;
}
+ data = host-data;
status = OMAP_HSMMC_READ(host-base, STAT);
dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
@@ -356,7 +359,7 @@ static irqreturn_t mmc_omap_irq(int irq,
if (end_cmd || (status CC))
mmc_omap_cmd_done(host, host-cmd);
if (end_trans || (status TC))
- mmc_omap_xfer_done(host, host-data);
+ mmc_omap_xfer_done(host, data);
return IRQ_HANDLED;
}
@@ -436,8 +439,12 @@ static void mmc_omap_detect(struct work_
host-mmc-ios.vdd = vdd;
}
mmc_detect_change(host-mmc, (HZ * 200) / 1000);
- } else
+ } else {
+ OMAP_HSMMC_WRITE(host-base, SYSCTL,
+ OMAP_HSMMC_READ(host-base, SYSCTL) | SRD);
+ while (OMAP_HSMMC_READ(host-base, SYSCTL) SRD) ;
mmc_detect_change(host-mmc, (HZ * 50) / 1000);
+ }
}
/*
--
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/3] HSMMC driver fix for core ret
* Madhusudhan Chikkature [EMAIL PROTECTED] [080725 13:32]:
From: Madhusudhan Chikkature[EMAIL PROTECTED]
ARM: OMAP3: HSMMC fix for core ret.
The core ret seem to be prevented by HSMMC CTO errors. This patch provides a
fix for the same.
Pushing today.
Tony
Signed-off-by: Madhusudhan Chikkature[EMAIL PROTECTED]
---
drivers/mmc/host/omap_hsmmc.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
Index: linux-omap-ti.git-07142008/drivers/mmc/host/omap_hsmmc.c
===
--- linux-omap-ti.git-07142008.orig/drivers/mmc/host/omap_hsmmc.c
2008-07-10
14:59:37.0 +0530
+++ linux-omap-ti.git-07142008/drivers/mmc/host/omap_hsmmc.c 2008-07-17
15:08:29.0 +0530
@@ -84,6 +84,7 @@
#define STAT_CLEAR 0x
#define INIT_STREAM_CMD 0x
#define DUAL_VOLT_OCR_BIT7
+#define SRC (1 25)
#define OMAP_MMC1_DEVID 1
#define OMAP_MMC2_DEVID 2
@@ -315,10 +316,16 @@ static irqreturn_t mmc_omap_irq(int irq,
if ((status CMD_TIMEOUT) ||
(status CMD_CRC)) {
if (host-cmd) {
- if (status CMD_TIMEOUT)
+ if (status CMD_TIMEOUT) {
+ OMAP_HSMMC_WRITE(host-base, SYSCTL,
+ OMAP_HSMMC_READ(host-base,
+ SYSCTL) | SRC);
+ while (OMAP_HSMMC_READ(host-base,
+ SYSCTL) SRC) ;
host-cmd-error = -ETIMEDOUT;
- else
+ } else {
host-cmd-error = -EILSEQ;
+ }
end_cmd = 1;
}
if (host-data)
--
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 1/3] Triton BCI driver board/device setup for OMAP3430
On Tue, Aug 05, 2008 at 04:35:51PM +0300, Tony Lindgren wrote: * Felipe Balbi [EMAIL PROTECTED] [080723 10:32]: On Wed, 23 Jul 2008 10:16:27 +0530, Madhusudhan Chikkature [EMAIL PROTECTED] wrote: Hi Felipe, Tony, weird that we still have these prototypes in these headers. Could be some merging conflict ? Yes. I see that these prototypes are still present in the board3430 and board2430 header files in the omap tree. Anyways, please apply the attached patch. We're using usb_musb_init() and usb_ehci_init() now. You mean I should apply the attached patch you sent for local use, right? And I guess I dont need to resend this perticular BCI patch, am I correct? No :-) that was to Tony. Just replied to your mail so it's easy to see why we need that patch :-) Pushing these today. Do you have a patch for moving the extern prototypes into the twl header? I was talking about these: From: Felipe Balbi [EMAIL PROTECTED] arch: omap: get rid of usb_init() protytpes we now use usb_musb_init() and usb_ehci_init() functions Signed-off-by: Felipe Balbi [EMAIL PROTECTED] --- diff --git a/include/asm-arm/arch-omap/board-2430sdp.h b/include/asm-arm/arch-omap/board-2430sdp.h index fde6915..83d0eec 100644 --- a/include/asm-arm/arch-omap/board-2430sdp.h +++ b/include/asm-arm/arch-omap/board-2430sdp.h @@ -36,6 +36,5 @@ /* Function prototypes */ extern void sdp2430_flash_init(void); -extern void sdp2430_usb_init(void); #endif /* __ASM_ARCH_OMAP_2430SDP_H */ diff --git a/include/asm-arm/arch-omap/board-3430sdp.h b/include/asm-arm/arch-omap/board-3430sdp.h index d583008..85f769e 100644 --- a/include/asm-arm/arch-omap/board-3430sdp.h +++ b/include/asm-arm/arch-omap/board-3430sdp.h @@ -29,7 +29,6 @@ #ifndef __ASM_ARCH_OMAP_3430SDP_H #define __ASM_ARCH_OMAP_3430SDP_H -extern void sdp3430_usb_init(void); extern void sdp3430_flash_init(void); #define DEBUG_BASE 0x0800 /* debug board */ -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Resending - PATCH 1/3] Triton BCI driver board/device setup for OMAP3430
* Felipe Balbi [EMAIL PROTECTED] [080805 17:06]: On Tue, Aug 05, 2008 at 04:35:51PM +0300, Tony Lindgren wrote: * Felipe Balbi [EMAIL PROTECTED] [080723 10:32]: On Wed, 23 Jul 2008 10:16:27 +0530, Madhusudhan Chikkature [EMAIL PROTECTED] wrote: Hi Felipe, Tony, weird that we still have these prototypes in these headers. Could be some merging conflict ? Yes. I see that these prototypes are still present in the board3430 and board2430 header files in the omap tree. Anyways, please apply the attached patch. We're using usb_musb_init() and usb_ehci_init() now. You mean I should apply the attached patch you sent for local use, right? And I guess I dont need to resend this perticular BCI patch, am I correct? No :-) that was to Tony. Just replied to your mail so it's easy to see why we need that patch :-) Pushing these today. Do you have a patch for moving the extern prototypes into the twl header? I was talking about these: From: Felipe Balbi [EMAIL PROTECTED] arch: omap: get rid of usb_init() protytpes we now use usb_musb_init() and usb_ehci_init() functions OK, thanks. Will push today. Tony Signed-off-by: Felipe Balbi [EMAIL PROTECTED] --- diff --git a/include/asm-arm/arch-omap/board-2430sdp.h b/include/asm-arm/arch-omap/board-2430sdp.h index fde6915..83d0eec 100644 --- a/include/asm-arm/arch-omap/board-2430sdp.h +++ b/include/asm-arm/arch-omap/board-2430sdp.h @@ -36,6 +36,5 @@ /* Function prototypes */ extern void sdp2430_flash_init(void); -extern void sdp2430_usb_init(void); #endif /* __ASM_ARCH_OMAP_2430SDP_H */ diff --git a/include/asm-arm/arch-omap/board-3430sdp.h b/include/asm-arm/arch-omap/board-3430sdp.h index d583008..85f769e 100644 --- a/include/asm-arm/arch-omap/board-3430sdp.h +++ b/include/asm-arm/arch-omap/board-3430sdp.h @@ -29,7 +29,6 @@ #ifndef __ASM_ARCH_OMAP_3430SDP_H #define __ASM_ARCH_OMAP_3430SDP_H -extern void sdp3430_usb_init(void); extern void sdp3430_flash_init(void); #define DEBUG_BASE 0x0800 /* debug board */ -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP PM interface, version 3
* Paul Walmsley [EMAIL PROTECTED] [080717 05:00]: Hello everyone, this is the third version of the OMAP PM interface patch. Major changes since the second revision: 1. set_max_mpu_wakeup_lat() has been added. This is intended to limit the amount of time needed for the MPU to wake up and enter a device driver's interrupt handler. 2. set_max_dma_lat() has been renamed to set_max_sdma_lat() 3. omap_pm_dsp_get_opp_table() and struct omap_opp have been added for future DSPBridge/CPUFreq use. omap_pm_if_init() now takes pointers to struct omap_opp arrays that are intended to be passed in from the board-*.c files. 4. Interface documentation has been moved to the include/asm-arm/arch-omap/omap-pm.h file. 5. Documentation updated and moved into Documentation/arm/OMAP/omap_pm Further comments welcome, I think we need to run this by LKML, linux-arm-kernel, and linux-pm before we integrate these. Can you repost these for comments one more time so we get comments from other mailing lists? Thanks, Tony - Paul - This message proposes the third version of a power management interface (the OMAP PM interface) for the linux-omap kernel tree. It includes a general device driver PM interface, along with some specialized interfaces for CPUFreq, DSPBridge, and the powerdomain/clockdomain code. This message focuses on the general device driver portion, since it is most relevant to the larger community of OMAP device driver developers. The interface is intended to allow drivers to take advantage of OMAP power management features: - without locking drivers into a particular underlying implementation; - without adding constraints that are specific to particular OMAP variants; and - without affecting other architectures. The device driver portion of the interface covers four types of PM constraints: 1. Set the maximum MPU wakeup latency 2. Set the maximum device wakeup latency 3. Set the maximum system DMA transfer start latency (CORE pwrdm) 4. Set the minimum bus throughput needed by a device These are described in more detail in the patch. This interface is intended to be temporary, to survive only until the Linux PM QoS layer supports these features. This interface is a collaborative product of many people from Nokia and TI: Karthik Dasu, Jouni Högander, Tony Lindgren, Rajendra Nayak, Sakari Poussa, Veeramanikandan Raju, Anand Sawant, Igor Stoppa, Paul Walmsley, and Richard Woodruff. Included in the patch is a 'no-op' implementation that documents the interface and emits debug messages. Rajendra Nayak at TI has developed an initial implementation of the OMAP PM interface that relies mostly on TI's Shared Resource Framework. Also under development is an implementation of the OMAP PM code that uses the existing Linux PM QoS code. Comments welcomed, - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Implement powerdomain off on state counters
Hi Tony, On Tue, 2008-08-05 at 17:20 +0300, ext Tony Lindgren wrote: * Peter 'p2' De Schrijver [EMAIL PROTECTED] [080724 16:00]: This patchset implement counters to count the number of off to on state transitions in a powerdomain. These counters will be made available to drivers in a later patchset to allow them to make a better informed decision wether to restore the hardware registers or not. Peter 'p2' De Schrijver (3): Power off on state counter debugging Power off on state counter infrastructure Add hooks for counting off on power transitions We should merge these into Paul's powerdomain patches against mainline tree and post them again for more comments to LKML, linux-arm-kernel and linux-pm. Dave Brownell commented already that this stuff, albeit apparently generic enough to be interesting to other archs, would probably be better off being merged in the omap tree, since in the end other SOCs tend to be far simpler than OMAP. Considering that we are not 100% sure about the usefulness of certain sw features - example: the granularity for the bandwidth requirements might be too fine - I'd rather avoid bringing in whishlists from other architectures, unless they are proven to be really needed. And AFAIK so far nobody has come forward with such claim. Can't we first get it working in a reliable way on OMAP? Whatever survives this process has probably better chances to result interesting to other people. -- Cheers, Igor --- Igor Stoppa Maemo Software - 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
omap ldp board(3430) failed to read/write NAND flash device after booting from nfs
Hi: I have booted the omap ldp board with nfs. I want to bootup from flash. so I want to test if linux kernel could read/write flash device. I used make omap_ldp_defconfig make uImage to build kernel. After kernel booting, I can't read/write flash device. Anyone has bootup the ldp board with Flash device? 6console [ttyS2] enabled Linux version 2.6.26-rc8-omap1 ([EMAIL PROTECTED]) (gcc version 4.2.3 (Sourcery G++ Lite 2008q1-126)) #2 Thu Jul 31 16:50:54 CST 2008 CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=00c5387f Machine: OMAP LDP board Memory policy: ECC disabled, Data cache writeback OMAP3430 ES2.2 SRAM: Mapped pa 0x4020 to va 0xd700 size: 0x10 CPU0: D VIPT write-through cache CPU0: cache: 768 bytes, associativity 1, 8 byte lines, 64 sets Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: mem=128M console=ttyS2,115200n8 noinitrd root=/dev/nfs rw nfsroot=128.247.77.91:/home/ztao/tftproot/arm-linux,nolock,tcp,rsize=4096,wsize=4096 ip=128.247.77.90 Clocking rate (Crystal/DPLL/ARM core): 26.0/266/500 MHz GPMC revision 5.0 IRQ: Found an INTC at 0xd820 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller OMAP34xx GPIO hardware version 2.5 PID hash table entries: 512 (order: 9, 2048 bytes) Console: colour dummy device 80x30 omap2-nand driver initializing 6NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND 256MiB 1,8V 16-bit) NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND 256MiB 1,8V 16-bit) 5Creating 6 MTD partitions on omap2-nand.0: Creating 6 MTD partitions on omap2-nand.0: 50x-0x0008 : X-Loader-NAND 0x-0x0008 : X-Loader-NAND 50x0008-0x0010 : U-Boot-NAND 0x0008-0x0010 : U-Boot-NAND 50x0010-0x0014 : Boot Env-NAND 0x0010-0x0014 : Boot Env-NAND 50x0014-0x0054 : Kernel-NAND 0x0014-0x0054 : Kernel-NAND 50x0054-0x0094 : root file system- NAND 0x0054-0x0094 : root file system- NAND 50x0094-0x1000 : File System - NAND 0x0094-0x1000 : File System - NAND 5usbmon: debugfs is not available / # dd if=/dev/mtblock4 of=test2 count=1 3end_request: I/O error, dev mtdblock4, sector 0 end_request: I/O error, dev mtdblock4, sector 0 3Buffer I/O error on device mtdblock4, logical block 0 Buffer I/O error on device mtdblock4, logical block 0 3end_request: I/O error, dev mtdblock4, sector 16 end_request: I/O error, dev mtdblock4, sector 16 3Buffer I/O error on device mtdblock4, logical block 2 Buffer I/O error on device mtdblock4, logical block 2 3end_request: I/O error, dev mtdblock4, sector 24 end_request: I/O error, dev mtdblock4, sector 24 3Buffer I/O error on device mtdblock4, logical block 3 Buffer I/O error on device mtdblock4, logical block 3 3end_request: I/O error, dev mtdblock4, sector 0 end_request: I/O error, dev mtdblock4, sector 0 3Buffer I/O error on device mtdblock4, logical block 0 Buffer I/O error on device mtdblock4, logical block 0 dd: /dev/mtdblock4: Input/output error / # / # dd if=ext2.img of=/dev/mtdblock5 count=4 4mtdblock: erase of region [0x0, 0x2] on File System - NAND failed mtdblock: erase of region [0x0, 0x2] on File System - NAND failed 4+0 records in 4+0 records out / # I checked the schematic, the Flash type is PC28F640P30T85, it should be Intel flash. I'm not sure if the config file using wrong flash driver. Any suggestion will be appreciated. Best Regards Tao -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Implement powerdomain off on state counters
* Igor Stoppa [EMAIL PROTECTED] [080805 17:38]: Hi Tony, On Tue, 2008-08-05 at 17:20 +0300, ext Tony Lindgren wrote: * Peter 'p2' De Schrijver [EMAIL PROTECTED] [080724 16:00]: This patchset implement counters to count the number of off to on state transitions in a powerdomain. These counters will be made available to drivers in a later patchset to allow them to make a better informed decision wether to restore the hardware registers or not. Peter 'p2' De Schrijver (3): Power off on state counter debugging Power off on state counter infrastructure Add hooks for counting off on power transitions We should merge these into Paul's powerdomain patches against mainline tree and post them again for more comments to LKML, linux-arm-kernel and linux-pm. Dave Brownell commented already that this stuff, albeit apparently generic enough to be interesting to other archs, would probably be better off being merged in the omap tree, since in the end other SOCs tend to be far simpler than OMAP. Yeah. Considering that we are not 100% sure about the usefulness of certain sw features - example: the granularity for the bandwidth requirements might be too fine - I'd rather avoid bringing in whishlists from other architectures, unless they are proven to be really needed. And AFAIK so far nobody has come forward with such claim. Can't we first get it working in a reliable way on OMAP? We should first get ack (even if it means no comments) from other mailing lists before we go ahead implementing this as it affects the drivers too. Whatever survives this process has probably better chances to result interesting to other people. Yeh, but we need to keep them informed throughout the process. Many of the people that could be commenting the code are not reading linux-omap list. Also, we want to get these patches integrated to mainline tree, and Russell wants to have more review before integrating. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap ldp board(3430) failed to read/write NAND flash device after booting from nfs
Tao, I have booted the omap ldp board with nfs. I want to bootup from flash. so I want to test if linux kernel could read/write flash device. before booting, execute a 'nand unlock' in u-boot / # dd if=/dev/mtblock4 of=test2 count=1 # dd if=/dev/mtdblock4 of=test2 count=1 1+0 records in 1+0 records out / # / # dd if=ext2.img of=/dev/mtdblock5 count=4 # dd if=rd-ext2.bin of=/dev/mtdblock5 count=4 4+0 records in 4+0 records out # cat /proc/mtd dev:size erasesize name mtd0: 0008 0002 X-Loader-NAND mtd1: 0008 0002 U-Boot-NAND mtd2: 0004 0002 Boot Env-NAND mtd3: 0040 0002 Kernel-NAND mtd4: 0fac 0002 File System - NAND # dd if=rd-ext2.bin of=/dev/mtdblock4 count=4 4+0 records in 4+0 records out Best Regards Abraham -- 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: About to tag v2.6.26-omap1, patch queue deleted, please check and repost
Hi all, I've pushed all the patches I have in my omap inbox, except for the omap serial driver that I want to look more. I've tried to comment on the ones that did not get pushed, then erased everything from my omap inbox. Some drivers should get integrated via other mailing lists, and some debug patches can probably stay as debug patches, and some patches I probably have accidentally deleted :) And the PM patches I lost track of, so those should be reposted. So please check your patches, and repost your patches if something is left out. Also please check that things work for your board, let's try to tag v2.6.26-omap1 within next few days so we can move on again. Cheers, Tony Boot tested on 3430SDP with the defconfig. Things work okay so far. - Anand -- 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: About to tag v2.6.26-omap1, patch queue deleted, please check and repost
Gadiyar, Anand wrote: Hi all, I've pushed all the patches I have in my omap inbox, except for the omap serial driver that I want to look more. I've tried to comment on the ones that did not get pushed, then erased everything from my omap inbox. Some drivers should get integrated via other mailing lists, and some debug patches can probably stay as debug patches, and some patches I probably have accidentally deleted :) And the PM patches I lost track of, so those should be reposted. So please check your patches, and repost your patches if something is left out. Also please check that things work for your board, let's try to tag v2.6.26-omap1 within next few days so we can move on again. Cheers, Tony Boot tested on 3430SDP with the defconfig. Things work okay so far. Same with BeagleBoard. Dirk -- 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 3/3] Fixes required for HSMMC driver to work as module
Hi Tony,
Sure. I will take a look.
Regards,
Madhu
- Original Message -
From: Tony Lindgren [EMAIL PROTECTED]
To: Madhusudhan Chikkature [EMAIL PROTECTED]
Cc: linux-omap@vger.kernel.org
Sent: Tuesday, August 05, 2008 7:34 PM
Subject: Re: [PATCH 3/3] Fixes required for HSMMC driver to work as module
* Madhusudhan Chikkature [EMAIL PROTECTED] [080725 13:34]:
From: Madhusudhan Chikkature[EMAIL PROTECTED]
ARM: OMAP3: Fixes required to make HSMMC driver as module.
This patch provides the necessary fixes to make the HSMMC driver work as
loadble module.
This one does not apply, can you take a look?
Thanks,
Tony
Signed-off-by: Madhusudhan Chikkature[EMAIL PROTECTED]
Signed-off-by: Romit Dasgupta [EMAIL PROTECTED]
---
drivers/mmc/host/omap_hsmmc.c | 43
+++---
1 files changed, 32 insertions(+), 11 deletions(-)
Index: linux-omap-ti.git-07142008/drivers/mmc/host/omap_hsmmc.c
===
--- linux-omap-ti.git-07142008.orig/drivers/mmc/host/omap_hsmmc.c 2008-07-23
16:31:56.0 +0530
+++ linux-omap-ti.git-07142008/drivers/mmc/host/omap_hsmmc.c 2008-07-24
12:07:40.0 +0530
@@ -764,23 +764,27 @@ static int __init omap_mmc_probe(struct
if (IS_ERR(host-iclk)) {
ret = PTR_ERR(host-iclk);
host-iclk = NULL;
- goto err;
+ goto err1;
}
host-fclk = clk_get(pdev-dev, mmchs_fck);
if (IS_ERR(host-fclk)) {
ret = PTR_ERR(host-fclk);
host-fclk = NULL;
clk_put(host-iclk);
- goto err;
+ goto err1;
}
- if (clk_enable(host-fclk) != 0)
- goto err;
+ if (clk_enable(host-fclk) != 0) {
+ clk_put(host-iclk);
+ clk_put(host-fclk);
+ goto err1;
+ }
if (clk_enable(host-iclk) != 0) {
clk_disable(host-fclk);
+ clk_put(host-iclk);
clk_put(host-fclk);
- goto err;
+ goto err1;
}
host-dbclk = clk_get(pdev-dev, mmchsdb_fck);
@@ -873,12 +877,6 @@ static int __init omap_mmc_probe(struct
return 0;
-err:
- dev_dbg(mmc_dev(host-mmc), Probe Failed\n);
- if (host)
- mmc_free_host(mmc);
- return ret;
-
irq_err:
dev_dbg(mmc_dev(host-mmc), Unable to configure MMC IRQs\n);
clk_disable(host-fclk);
@@ -890,6 +888,11 @@ irq_err:
clk_put(host-dbclk);
}
+err1:
+ iounmap(host-base);
+err:
+ dev_dbg(mmc_dev(host-mmc), Probe Failed\n);
+ release_mem_region(res-start, res-end - res-start + 1);
if (host)
mmc_free_host(mmc);
return ret;
@@ -898,9 +901,26 @@ irq_err:
static int omap_mmc_remove(struct platform_device *pdev)
{
struct mmc_omap_host *host = platform_get_drvdata(pdev);
+ struct resource *res;
+ u16 vdd = 0;
+
+ if (!(OMAP_HSMMC_READ(host-base, HCTL) SDVSDET)) {
+ /*
+ * Set the vdd back to 3V,
+ * applicable for dual volt support.
+ */
+ vdd = fls(host-mmc-ocr_avail) - 1;
+ if (omap_mmc_switch_opcond(host, vdd) != 0)
+ host-mmc-ios.vdd = vdd;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (res)
+ release_mem_region(res-start, res-end - res-start + 1);
platform_set_drvdata(pdev, NULL);
if (host) {
+ mmc_remove_host(host-mmc);
host-pdata-cleanup(pdev-dev);
free_irq(host-irq, host);
if (mmc_slot(host).card_detect_irq)
@@ -917,6 +937,7 @@ static int omap_mmc_remove(struct platfo
}
mmc_free_host(host-mmc);
+ iounmap(host-base);
}
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: [PATCH RFC] MUSB: Fix index register corruption seen with g_ether and Windows host
On Tue, Aug 5, 2008 at 11:48 PM, Gadiyar, Anand [EMAIL PROTECTED] wrote: From: Anand Gadiyar [EMAIL PROTECTED] If Indexed Mode register accesses are enabled, the ep0_rxstate() function calls musb_g_ep0_giveback() before writing to the CSR register. When control returns to this ep0_rxstate, the index register contents are over-written. This causes the CSR register write to fail. Fixed by writing the correct value into the index register before writing to the CSR. This was observed only in ep0_rxstate() with g_ether loaded and the device connected to a MS Windows host PC. Anticipatively fixed ep0_txstate() as well. Actually, I'm still struggling in a bug similar with this one on Blackfin. We ran following testcase 100 times, 10-20 times tastcases failed. --- $ ./testusb -D /proc/bus/usb/005/012 -t14 -c 15000 -s 256 -v 1 unknown speed /proc/bus/usb/005/012 /proc/bus/usb/005/012 test 14 -- 75 (Value too large for defined data type) --- I reported this bug to our hardware designer and the omap list. Felipe said he did met this issue. From the capture data of USB analyzer, the peripheral musb sent out garbage data in the IN-STATUS stage. In that stage, the DATA length should be zero. But the peripheral sent out 1 byte or 2 bytes sometimes. Thanks -Bryan Signed-off-by: Anand Gadiyar [EMAIL PROTECTED] Cc: David Brownell [EMAIL PROTECTED] --- This patch will probably turn up with tabs replaced by spaces - my mailer is broken. Will fix that or find another one. Till then, this is RFC. The patch was based on the linux-omap git tree but that tab-to-space issue should cause the patch to not apply. Dave, you wrote the original commit (5dd8c56c) on linux-omap that moved the register write after the call to the giveback function [1]. Could you take a look at this patch please? [1] http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=commit;h=5dd8c56c0bb1aaadbf6540de8350161c7a9f7034 drivers/usb/musb/musb_gadget_ep0.c |2 ++ 1 files changed, 2 insertions(+) Index: 04aug_ccase/drivers/usb/musb/musb_gadget_ep0.c === --- 04aug_ccase.orig/drivers/usb/musb/musb_gadget_ep0.c +++ 04aug_ccase/drivers/usb/musb/musb_gadget_ep0.c @@ -476,6 +476,7 @@ static void ep0_rxstate(struct musb *mus return; musb-ackpend = 0; } + musb_ep_select(musb-mregs, 0); musb_writew(regs, MUSB_CSR0, tmp); } @@ -528,6 +529,7 @@ static void ep0_txstate(struct musb *mus } /* send it out, triggering a txpktrdy cleared irq */ + musb_ep_select(musb-mregs, 0); musb_writew(regs, MUSB_CSR0, csr); } -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH RFC] MUSB: Fix index register corruption seen with g_ether and Windows host
On Tue, Aug 5, 2008 at 11:48 PM, Gadiyar, Anand [EMAIL PROTECTED] wrote: From: Anand Gadiyar [EMAIL PROTECTED] If Indexed Mode register accesses are enabled, the ep0_rxstate() function calls musb_g_ep0_giveback() before writing to the CSR register. When control returns to this ep0_rxstate, the index register contents are over-written. This causes the CSR register write to fail. Fixed by writing the correct value into the index register before writing to the CSR. This was observed only in ep0_rxstate() with g_ether loaded and the device connected to a MS Windows host PC. Anticipatively fixed ep0_txstate() as well. Actually, I'm still struggling in a bug similar with this one on Blackfin. We ran following testcase 100 times, 10-20 times tastcases failed. --- $ ./testusb -D /proc/bus/usb/005/012 -t14 -c 15000 -s 256 -v 1 unknown speed /proc/bus/usb/005/012 /proc/bus/usb/005/012 test 14 -- 75 (Value too large for defined data type) --- I reported this bug to our hardware designer and the omap list. Felipe said he did met this issue. From the capture data of USB analyzer, the peripheral musb sent out garbage data in the IN-STATUS stage. In that stage, the DATA length should be zero. But the peripheral sent out 1 byte or 2 bytes sometimes. Thanks -Bryan Hi Bryan, Could you tell me if you're using Indexed Mode or Flat mode? I'll try this out on my boards and see what I get. - Anand -- 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
[Resending - PATCH] OMAP2EVM: add LCD panel support
omap2evm LCD supports VGA and QVGA resolution, by default its in VGA mode.
Signed-off-by: Arun C [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-omap2evm.c | 15 +++-
drivers/video/omap/Makefile |2 +
drivers/video/omap/lcd_omap2evm.c| 195 ++
3 files changed, 210 insertions(+), 2 deletions(-)
create mode 100644 drivers/video/omap/lcd_omap2evm.c
diff --git a/arch/arm/mach-omap2/board-omap2evm.c
b/arch/arm/mach-omap2/board-omap2evm.c
index 0baf704..13c53cc 100644
--- a/arch/arm/mach-omap2/board-omap2evm.c
+++ b/arch/arm/mach-omap2/board-omap2evm.c
@@ -62,6 +62,15 @@ static inline void __init omap2evm_init_smc911x(void)
}
+static struct platform_device omap2_evm_lcd_device = {
+ .name = omap2evm_lcd,
+ .id = -1,
+};
+
+static struct omap_lcd_config omap2_evm_lcd_config __initdata = {
+ .ctrl_name = internal,
+};
+
static void __init omap2_evm_init_irq(void)
{
omap2_init_common_hw(NULL);
@@ -75,7 +84,8 @@ static struct omap_uart_config omap2_evm_uart_config
__initdata = {
};
static struct omap_board_config_kernel omap2_evm_config[] __initdata = {
- {OMAP_TAG_UART, omap2_evm_uart_config},
+ { OMAP_TAG_UART,omap2_evm_uart_config },
+ { OMAP_TAG_LCD, omap2_evm_lcd_config },
};
static int __init omap2_evm_i2c_init(void)
@@ -90,7 +100,8 @@ static int __init omap2_evm_i2c_init(void)
}
static struct platform_device *omap2_evm_devices[] __initdata = {
-omap2evm_smc911x_device,
+ omap2_evm_lcd_device,
+ omap2evm_smc911x_device,
};
static void __init omap2_evm_init(void)
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index fe7ee5d..662dff9 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -31,6 +31,8 @@ objs-y$(CONFIG_MACH_SX1) += lcd_sx1.o
objs-y$(CONFIG_MACH_OMAP_APOLLON) += lcd_apollon.o
objs-y$(CONFIG_MACH_OMAP_2430SDP) += lcd_2430sdp.o
objs-y$(CONFIG_MACH_OMAP_3430SDP) += lcd_2430sdp.o
+objs-y$(CONFIG_MACH_OMAP2EVM) += lcd_omap2evm.o
+objs-y$(CONFIG_MACH_OMAP_3430SDP) += lcd_3430sdp.o
objs-y$(CONFIG_MACH_OMAP3EVM) += lcd_omap3evm.o
objs-y$(CONFIG_MACH_OMAP3_BEAGLE) += lcd_omap3beagle.o
objs-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o
diff --git a/drivers/video/omap/lcd_omap2evm.c
b/drivers/video/omap/lcd_omap2evm.c
new file mode 100644
index 000..8311cac
--- /dev/null
+++ b/drivers/video/omap/lcd_omap2evm.c
@@ -0,0 +1,195 @@
+/*
+ * LCD panel support for the MISTRAL OMAP2EVM board
+ *
+ * Author: Arun C [EMAIL PROTECTED]
+ *
+ * Derived from drivers/video/omap/lcd_omap3evm.c
+ * Derived from drivers/video/omap/lcd-apollon.c
+ *
+ * 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/module.h
+#include linux/platform_device.h
+#include linux/i2c/twl4030.h
+
+#include asm/arch/gpio.h
+#include asm/arch/mux.h
+#include asm/arch/omapfb.h
+#include asm/mach-types.h
+
+#define LCD_PANEL_ENABLE_GPIO 154
+#define LCD_PANEL_LR 128
+#define LCD_PANEL_UD 129
+#define LCD_PANEL_INI 152
+#define LCD_PANEL_QVGA 148
+#define LCD_PANEL_RESB 153
+
+#define LCD_XRES 480
+#define LCD_YRES 640
+#define LCD_PIXCLOCK_MAX 2 /* in kHz */
+
+#define TWL_LED_LEDEN 0x00
+#define TWL_PWMA_PWMAON0x00
+#define TWL_PWMA_PWMAOFF 0x01
+
+static unsigned int bklight_level;
+
+static int omap2evm_panel_init(struct lcd_panel *panel,
+ struct omapfb_device *fbdev)
+{
+ omap_request_gpio(LCD_PANEL_ENABLE_GPIO);
+ omap_request_gpio(LCD_PANEL_LR);
+ omap_request_gpio(LCD_PANEL_UD);
+ omap_request_gpio(LCD_PANEL_INI);
+ omap_request_gpio(LCD_PANEL_QVGA);
+ omap_request_gpio(LCD_PANEL_RESB);
+
+ omap_set_gpio_direction(LCD_PANEL_ENABLE_GPIO, 0);
+ omap_set_gpio_direction(LCD_PANEL_LR, 0);
+ omap_set_gpio_direction(LCD_PANEL_UD, 0);
+ omap_set_gpio_direction(LCD_PANEL_INI, 0);
+ omap_set_gpio_direction(LCD_PANEL_QVGA, 0);
+ omap_set_gpio_direction(LCD_PANEL_RESB, 0);
+
+ omap_set_gpio_dataout(LCD_PANEL_RESB, 1);
+ omap_set_gpio_dataout(LCD_PANEL_INI, 1);
+ omap_set_gpio_dataout(LCD_PANEL_QVGA, 0);
+
