OMAP NAND driver issue with subpage reads
Hi,
There seems to be an issue in the omap nand driver
(drivers/mtd/nand/omap2.c) concerning sub-page reads (visible when
using 16bit LP NAND, SOFT_ECC and UBI).
Problem is caused by the omap_read_buf_pref() function using 32bit
reads from the pre-fetch engine. It takes care of the mis-aligned
length but not a mis-aligned buffer pointer. Combined with how the
nand_read_subpage() function aligns the pointer and length to NAND
width (8 or 16 bits) this can lead to situation where the handling of
the mis-aligned length in omap_read_buf_pref() causes the pointer to
not be aligned to 32bits and the data gets corrupted in the read. This
of course leds to ECC issues.
The way I see is there are several ways to fix this:
1. Change nand_read_subpage() to be more strict about alignment
2. Change omap_read_buf_pref() to handle any reads (len % 4) || (buf %
4) with omap_read_bufX() completely
3. Change omap_read_buf_pref() to use ioread16_rep() since buffer and
length are already aligned for us.
I'm leaning towards #2 because, assuming that the nand driver cannot
make assumptions of alignment, we need to be able to handle them all
anyway. The common case of reading big chunks of page data would still
be fast (since reads are always sub-page aligned) but the special case
of reading small OOB chunks would be handled gracefully.
Something like this:
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 5c8978e..8a929cf 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -334,13 +334,12 @@ static void omap_read_buf_pref(struct mtd_info
*mtd, u_char *buf, int len)
u32 *p = (u32 *)buf;
/* take care of subpage reads */
- if (len % 4) {
+ if (len % 4 || (unsigned long) buf % 4) {
if (info-nand.options NAND_BUSWIDTH_16)
omap_read_buf16(mtd, buf, len % 4);
else
omap_read_buf8(mtd, buf, len % 4);
- p = (u32 *) (buf + len % 4);
- len -= len % 4;
+ return;
}
/* configure and start prefetch transfer */
Comments?
- Juha
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 0/1] ARM: OMAP3: Use OMAP3_HAS_IVA_REGS with OMAP3503
Based on Mark A. Greer's findings on the AM3703 and the corresponding patch ARM: OMAP3: Add OMAP3_HAS_IVA_REGS feature. Similarly to am3703, it seems that omap3503 has an IVA control registers even though the subsystem is non-functional. Tested on Gumstix Overo Earth (OMAP3503). Without this patch the IVA domain fails to enter retention on suspend. Juha Kuikka (1): ARM: OMAP3: Use OMAP3_HAS_IVA_REGS with OMAP3503 arch/arm/mach-omap2/id.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 1/1] ARM: OMAP3: Use OMAP3_HAS_IVA_REGS with OMAP3503
Similarly to am3703, it seems that omap3503 has an IVA control registers even though the subsystem is non-functional. This patch sets the OMAP3_HAS_IVA_REGS feature to force initialization of there registers. Based in Mark A. Greer's patch ARM: OMAP3: Add OMAP3_HAS_IVA_REGS feature. Signed-off-by: Juha Kuikka juha.kui...@gmail.com --- arch/arm/mach-omap2/id.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index 4072fbd..45d3eb4 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -244,7 +244,7 @@ void __init omap3xxx_check_features(void) if (cpu_is_omap3630()) omap_features |= OMAP3_HAS_192MHZ_CLK | OMAP3_HAS_IVA_REGS; if (cpu_is_omap3430() || cpu_is_omap3630()) - omap_features |= OMAP3_HAS_IO_WAKEUP; + omap_features |= OMAP3_HAS_IO_WAKEUP | OMAP3_HAS_IVA_REGS; if (cpu_is_omap3630() || omap_rev() == OMAP3430_REV_ES3_1 || omap_rev() == OMAP3430_REV_ES3_1_2) omap_features |= OMAP3_HAS_IO_CHAIN_CTRL; -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Issue with DSS power domain always in ON state
Hello, I am running the l-o (55936cdfaaf11ac352b56bc58e42d6661e65ee13) with following: - ARM: OMAP3: Add OMAP3_HAS_IVA_REGS feature - ARM: OMAP3: Use OMAP3_HAS_IVA_REGS with OMAP3503 - OMAPDSS: PM runtime fixes for 3.5-rc Using omap2plus_defconfig. - Minus EHCI - Minus ADS7846 - Minus SMP - Plus initramfs Running on Gumstix Overo Earth (OMP3503). My problem is that while suspend (with the above patches) seems to function the debug counters for DSS do not indicate retention or off mode. What happens: / # cat /debug/pm_debug/count usbhost_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:0,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 neon_pwrdm (ON),OFF:0,RET:464,INA:0,ON:465,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:0,RET:464,INA:0,ON:465,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 usbhost_clkdm-usbhost_pwrdm (1) sgx_clkdm-sgx_pwrdm (0) per_clkdm-per_pwrdm (18) cam_clkdm-cam_pwrdm (0) dss_clkdm-dss_pwrdm (1) d2d_clkdm-core_pwrdm (0) iva2_clkdm-iva2_pwrdm (0) mpu_clkdm-mpu_pwrdm (0) core_l4_clkdm-core_pwrdm (24) core_l3_clkdm-core_pwrdm (4) neon_clkdm-neon_pwrdm (0) / # echo mem /sys/power/state [ 41.891540] PM: Syncing filesystems ... done. [ 41.910003] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 41.935607] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 41.966796] Suspending console(s) (use no_console_suspend to debug) [ 42.098388] PM: suspend of devices complete after 119.872 msecs [ 42.102722] PM: late suspend of devices complete after 4.272 msecs [ 42.109222] PM: noirq suspend of devices complete after 6.469 msecs [ 44.625213] Successfully put all powerdomains to target state [ 44.628753] PM: noirq resume of devices complete after 3.295 msecs [ 44.632995] PM: early resume of devices complete after 2.685 msecs [ 45.050598] PM: resume of devices complete after 417.449 msecs [ 45.100341] Restarting tasks ... done. / # cat /debug/pm_debug/count usbhost_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:0,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 per_pwrdm (ON),OFF:0,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 neon_pwrdm (ON),OFF:0,RET:616,INA:0,ON:617,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:0,RET:616,INA:0,ON:617,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 usbhost_clkdm-usbhost_pwrdm (1) sgx_clkdm-sgx_pwrdm (0) per_clkdm-per_pwrdm (18) cam_clkdm-cam_pwrdm (0) dss_clkdm-dss_pwrdm (1) d2d_clkdm-core_pwrdm (0) iva2_clkdm-iva2_pwrdm (0) mpu_clkdm-mpu_pwrdm (0) core_l4_clkdm-core_pwrdm (24) core_l3_clkdm-core_pwrdm (4) neon_clkdm-neon_pwrdm (0) In the defconfig DSS is built as a module. After building it (and PANEL_GENERIC) into kernel the situation does not change. Strangely the core domain is able to go to retention (or off if enabled) even though DSS isn't. Suspend _seems_ to work but I only see a meager 10mA reduction (from 80mA to 70mA) in the current to the gumstix so I'm suspicious. Can anyone shed any light on this? - Juha -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?
A thousand apologizes for double posting, some html sneaked into the first email and it got dropped by the list server. I am running on a gumstix with OMAP 3503 on it (name escapes me at the moment) and it has the same issue. Just applying Mark's patch on top of 55936cdfaaf11ac352b56bc58e42d6661e65ee13 (linux-omap) is not enough, I also need to set the OMAP3_HAS_IVA_REGS for the 3430 as well. Inlined patch: diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index 4072fbd..45d3eb4 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -244,7 +244,7 @@ void __init omap3xxx_check_features(void) if (cpu_is_omap3630()) omap_features |= OMAP3_HAS_192MHZ_CLK | OMAP3_HAS_IVA_REGS; if (cpu_is_omap3430() || cpu_is_omap3630()) - omap_features |= OMAP3_HAS_IO_WAKEUP; + omap_features |= OMAP3_HAS_IO_WAKEUP | OMAP3_HAS_IVA_REGS; if (cpu_is_omap3630() || omap_rev() == OMAP3430_REV_ES3_1 || omap_rev() == OMAP3430_REV_ES3_1_2) omap_features |= OMAP3_HAS_IO_CHAIN_CTRL; Here is with I see with this patch: /debug/pm_debug # echo mem /sys/power/state [ 1058.657928] PM: Syncing filesystems ... done. [ 1058.669616] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 1058.703094] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 1058.734252] Suspending console(s) (use no_console_suspend to debug) [ 1058.921936] PM: suspend of devices complete after 161.285 msecs [ 1058.938995] PM: late suspend of devices complete after 16.936 msecs [ 1058.963134] PM: noirq suspend of devices complete after 23.986 msecs [ 1060.013336] Successfully put all powerdomains to target state [ 1060.025726] PM: noirq resume of devices complete after 11.810 msecs [ 1060.042480] PM: early resume of devices complete after 10.437 msecs [ 1060.481353] PM: resume of devices complete after 438.415 msecs [ 1060.547912] Restarting tasks ... done. /debug/pm_debug # cat /debug/pm_debug/count usbhost_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:0,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 per_pwrdm (ON),OFF:0,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 neon_pwrdm (ON),OFF:0,RET:710,INA:0,ON:711,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:0,RET:710,INA:0,ON:711,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 usbhost_clkdm-usbhost_pwrdm (1) sgx_clkdm-sgx_pwrdm (0) per_clkdm-per_pwrdm (18) cam_clkdm-cam_pwrdm (0) dss_clkdm-dss_pwrdm (1) d2d_clkdm-core_pwrdm (0) iva2_clkdm-iva2_pwrdm (0) mpu_clkdm-mpu_pwrdm (0) core_l4_clkdm-core_pwrdm (24) core_l3_clkdm-core_pwrdm (4) neon_clkdm-neon_pwrdm (0) I see that the usbhost domain is still not hitting retention but for some reason it is not being complained about in suspend messages. I am running omap2plus_defconfig with CPUFREQ and CPUIDLE enabled, USB disabled. - Juha On Wed, Jul 18, 2012 at 10:26 AM, Mark A. Greer mgr...@animalcreek.com wrote: On Wed, Jul 18, 2012 at 11:06:34AM +0100, Joe Woodward wrote: From: Mark A. Greer mgr...@animalcreek.com How does this look? Subject: [PATCH] ARM: OMAP3: Add OMAP3_HAS_IVA_REGS feature It appears that the am3703 and possibly the am3715 SoCs have an active IVA subsystem even though the CONTROL_IDCODE register indicates that they don't. From experimentation, it seems that the IVA still requires some registers to be initialized even though we don't want it fully functional. To accomplish this, add a new feature (OMAP3_HAS_IVA_REGS) that indicates that the IVA should be initialized but not really used. Signed-off-by: Mark A. Greer mgr...@animalcreek.com --- Tested on a GUMSTIX Overo AirSTORM (AM3703-based), and that fixes the problem for me, thanks! Great! Thanks for testing, Joe. Paul, Kevin, any comments? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Duck tape is like the force, it has a light side and a dark side and it holds the universe together. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DSS2: Simultaneous DSI and DPI panels
Hello, I was wondering if it would be possible to run DPI and DSI interfaces simultaneously with OMAP3 (DM3730). Limitations: - DSI would have to be in video mode (data to DSI phy through video port with H/VSYNC signaling, OMAP_DSS_PARALLELMODE_BYPASS) - DSI PLL would need to be used for clock source - Both the DPI and DSI panels would have to accept identical clocking (PCLK, blanking intervals etc). - Data lane # must match. - And of course same data would go to both I realize the current SW does not support this, but I'm more wondering if it is possible from the HW point of view because it seems to me that data out from DISPC is pretty much identical in both cases. - Juha -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP_DSS: DSI driver with support for video mode?
Hello, I am wondering if anyone has implemented DSI video mode support in the DSS driver? I tried to trawl the web and the mailing list archives but no patches come up. I am using DM3730. + Juha -- Duck tape is like the force, it has a light side and a dark side and it holds the universe together. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue with DSS DSI: Complex IO not powering on
On Tue, Apr 5, 2011 at 11:16 PM, Archit Taneja arc...@ti.com wrote: Hi, On Wednesday 06 April 2011 07:25 AM, Juha Kuikka wrote: Hi, I am working on a custom board with DM3730 and a DSI panel and I have a problem in powering on the DSI complex IO block. The DSS DSI initialization fails with: omapdss DSI: dsi_complexio_init omapdss DSI error: complexio reset not done!-- my own addition omapdss DSI error: failed to set complexio power state to 1 Can you check if the necessary pad/pin-muxing has been done for the DSI lanes? Thank you for the advice! Turns out they were not. After configuring them the DSI powers on correctly. Unfortunately I ran into another issue, it seems that dispc is not giving us FRAMEDONE interrupt, currently investigating why. Any input is appreciated. Clocking: omapdss DSI: PLL init omapdss DSI: PLL init done omapdss DSI: dsi_pll_set_clock_div() omapdss DSI: DSI Fint 200 omapdss DSI: clkin (dss2_fck) rate 2600, highfreq 0 omapdss DSI: CLKIN4DDR = 2 * 180 / 13 * 2600 / 1 = 72000 omapdss DSI: Data rate on 1 DSI lane 360 Mbps omapdss DSI: Clock lane freq 18000 Hz omapdss DSI: regm3 = 8, dsi1_pll_fclk = 9000 omapdss DSI: regm4 = 8, dsi2_pll_fclk = 9000 omapdss DSI: PLL config done omapdss DSI: PLL OK omapdss DISPC: lck = 9000 (1) omapdss DISPC: pck = 3000 (3) DISPC is using DSI_DPLL1 as fclk. Logs: mapdss MANAGER: omap_dss_mgr_apply(lcd) omapdss OVERLAY: check_overlay 0: (0,0 480x800 - 0x800) disp (480x800) omapdss MANAGER: configure_overlay(0) omapdss DISPC: dispc_setup_plane 0, pa 8143, sw 480, 0,0, 480x800 - 480x800, ilace 0, cmode 40, rot 0, mir 0 flicker_filter 0 omapdss DISPC: calc_rot(0): scrw 480, 480x800 omapdss DISPC: offset0 0, offset1 0, row_inc 1, pix_inc 1 omapdss DISPC: 0,0 480x800 - 480x800 omapdss DISPC: vid[0] attributes = c omapdss DISPC: fifo(0) low/high old 960/1023, new 512/960 omapdss DISPC: dispc_enable_plane 0, 1 omapdss DSI: starting auto update omapdss DSI: dsi_display_enable_te(0) omapdss DSI: dsi_display_set_update_mode(2) dsi_display_update lcd_ix=0 omapdss DSI: dsi_display_update(0,0 480x800) omapdss MANAGER: dispc_setup_partial_planes 0,0 480x800 omapdss MANAGER: configure_overlay(0) omapdss DISPC: dispc_setup_plane 0, pa 8143, sw 480, 0,0, 480x800 - 480x800, ilace 0, cmode 40, rot 0, mir 0 flicker_filter 0 omapdss DISPC: calc_rot(0): scrw 480, 480x800 omapdss DISPC: offset0 0, offset1 0, row_inc 1, pix_inc 1 omapdss DISPC: 0,0 480x800 - 480x800 omapdss DISPC: vid[0] attributes = ad omapdss DISPC: fifo(0) low/high old 512/960, new 512/960 omapdss DISPC: dispc_enable_plane 0, 1 omapdss MANAGER: configure_overlay(1) omapdss DISPC: dispc_enable_plane 1, 0 omapdss MANAGER: configure_overlay(2) omapdss DISPC: dispc_enable_plane 2, 0 omapdss MANAGER: configure_manager(0) omapdss DSI: dsi_vc_config_vp(0) omapdss DSI: dsi_vc_enable channel 0, enable 0 omapdss DSI: dsi_vc_enable channel 0, enable 1 omapdss DSI: dsi_update_screen_dispc(0,0 480x800) omapdss DSI: dsi_display_enable_te(0) omapdss DSI: dsi_display_set_update_mode(2) omapdss DSI error: framedone timeout omapdss DSI error: failed update 0,0 480x800 omapdss DISPC error: timeout waiting for FRAME DONE - Juha Archit The DSI PLL is used and configured according to the example values in the TRM (not proper for our panel but they should enable the complex IO to at least power on, right). Output form DSS DEBUG: omapdss DSI: LP_CLK_DIV 6, LP_CLK 750 omapdss DISPC: lck = 9000 (1) omapdss DISPC: pck = 3000 (3) - DSI PLL - dsi pll source = dss2_alwon_fclk Fint 200 regn 13 CLKIN4DDR 108000 regm 270 dsi1_pll_fck 9000 regm3 12 (on) dsi2_pll_fck 9000 regm4 12 (on) - DSI - dsi fclk source = dsi2_pll_fclk DSI_FCLK 9000 DDR_CLK 27000 TxByteClkHS 6750 LP_CLK 750 VP_CLK 9000 VP_PCLK 3000 As far as I can tell these values fill all the requirements set in the TRM for clock rates and their ratios. After the fail in dsi_complexio_init I dump all registers: DSI_REVISION 0010 DSI_SYSCONFIG 0011 DSI_SYSSTATUS 0001 DSI_IRQSTATUS 00080080 DSI_IRQENABLE DSI_CTRL 0100 DSI_COMPLEXIO_CFG1 48200321 DSI_COMPLEXIO_IRQ_STATUS DSI_COMPLEXIO_IRQ_ENABLE DSI_CLK_CTRL a0304006 DSI_TIMING1 7fff7fff DSI_TIMING2 7fff7fff DSI_VM_TIMING1 DSI_VM_TIMING2 DSI_VM_TIMING3 DSI_CLK_TIMING 0101 DSI_TX_FIFO_VC_SIZE DSI_RX_FIFO_VC_SIZE DSI_COMPLEXIO_CFG2 DSI_RX_FIFO_VC_FULLNESS
Issue with DSS DSI: Complex IO not powering on
Hi, I am working on a custom board with DM3730 and a DSI panel and I have a problem in powering on the DSI complex IO block. The DSS DSI initialization fails with: omapdss DSI: dsi_complexio_init omapdss DSI error: complexio reset not done! -- my own addition omapdss DSI error: failed to set complexio power state to 1 The DSI PLL is used and configured according to the example values in the TRM (not proper for our panel but they should enable the complex IO to at least power on, right). Output form DSS DEBUG: omapdss DSI: LP_CLK_DIV 6, LP_CLK 750 omapdss DISPC: lck = 9000 (1) omapdss DISPC: pck = 3000 (3) - DSI PLL - dsi pll source = dss2_alwon_fclk Fint 200 regn 13 CLKIN4DDR 108000 regm 270 dsi1_pll_fck 9000 regm3 12 (on) dsi2_pll_fck 9000 regm4 12 (on) - DSI - dsi fclk source = dsi2_pll_fclk DSI_FCLK 9000 DDR_CLK 27000 TxByteClkHS 6750 LP_CLK 750 VP_CLK 9000 VP_PCLK 3000 As far as I can tell these values fill all the requirements set in the TRM for clock rates and their ratios. After the fail in dsi_complexio_init I dump all registers: DSI_REVISION 0010 DSI_SYSCONFIG 0011 DSI_SYSSTATUS 0001 DSI_IRQSTATUS 00080080 DSI_IRQENABLE DSI_CTRL 0100 DSI_COMPLEXIO_CFG1 48200321 DSI_COMPLEXIO_IRQ_STATUS DSI_COMPLEXIO_IRQ_ENABLE DSI_CLK_CTRL a0304006 DSI_TIMING1 7fff7fff DSI_TIMING2 7fff7fff DSI_VM_TIMING1 DSI_VM_TIMING2 DSI_VM_TIMING3 DSI_CLK_TIMING 0101 DSI_TX_FIFO_VC_SIZE DSI_RX_FIFO_VC_SIZE DSI_COMPLEXIO_CFG2 DSI_RX_FIFO_VC_FULLNESS DSI_VM_TIMING4 DSI_TX_FIFO_VC_EMPTINESS DSI_VM_TIMING5 DSI_VM_TIMING6 DSI_VM_TIMING7 DSI_STOPCLK_TIMING 0080 DSI_VC_CTRL(0) DSI_VC_TE(0) DSI_VC_LONG_PACKET_HEADER(0) DSI_VC_LONG_PACKET_PAYLOAD(0) DSI_VC_SHORT_PACKET_HEADER(0) DSI_VC_IRQSTATUS(0) DSI_VC_IRQENABLE(0) DSI_VC_CTRL(1) DSI_VC_TE(1) DSI_VC_LONG_PACKET_HEADER(1) DSI_VC_LONG_PACKET_PAYLOAD(1) DSI_VC_SHORT_PACKET_HEADER(1) DSI_VC_IRQSTATUS(1) DSI_VC_IRQENABLE(1) DSI_VC_CTRL(2) DSI_VC_TE(2) DSI_VC_LONG_PACKET_HEADER(2) DSI_VC_LONG_PACKET_PAYLOAD(2) DSI_VC_SHORT_PACKET_HEADER(2) DSI_VC_IRQSTATUS(2) DSI_VC_IRQENABLE(2) DSI_VC_CTRL(3) DSI_VC_TE(3) DSI_VC_LONG_PACKET_HEADER(3) DSI_VC_LONG_PACKET_PAYLOAD(3) DSI_VC_SHORT_PACKET_HEADER(3) DSI_VC_IRQSTATUS(3) DSI_VC_IRQENABLE(3) DSI_DSIPHY_CFG0 1e481d3a DSI_DSIPHY_CFG1 420a1a6a DSI_DSIPHY_CFG2 b81a DSI_DSIPHY_CFG5 6000 DSI_PLL_CONTROL DSI_PLL_STATUS 0383 DSI_PLL_GO DSI_PLL_CONFIGURATION1 05d90e19 DSI_PLL_CONFIGURATION2 0005600e Of special interest is the DSI_COMPLEXIO_CFG1. RESET_DONE is not set, not does the PWR_STATUS match the command given. The LDO_POWER_GOOD_STATE is asserted however. The DSI is powered and all the clocks seem to be on and the DSI PLL locks. Just the complex IO will not power on. I am using a 2.6.32.9 kernel so it is not the latest but I wanted to ask if someone had any idea where to look next before porting the latest onto our board. Thanks, - Juha -- Duck tape is like the force, it has a light side and a dark side and it holds the universe together. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3: Linux Without a Boot Loader?
On Mon, Apr 26, 2010 at 4:19 PM, Nishanth Menon n...@ti.com wrote: The final image looks as follows: +-+ | Configuration | | Header | +-+ | Sty | +-+ | kernel piggy | | bzImage | +-+ Looks very interesting! I was thinking of trying something like this after ELC but unfortunately real work got the better of me. This Configuration Header stuff looks very similar to what TI's Davinci-chips use. They call it AIS but from a short dive into omap-u-boot-utils it is very similar, encoded commands to mask ROM code to initialize HW and load image(s). Now I need to find some time to do this with the Beagle. This may be a stupid question but is the CH format documented somewhere? - Juha -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] updated PM branch, based on 2.6.32-rc1
On Fri, Oct 9, 2009 at 3:04 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Kevin Hilman khil...@deeprootsystems.com writes: Kevin Hilman khil...@deeprootsystems.com writes: Kevin Hilman khil...@deeprootsystems.com writes: Juha Kuikka juha.kui...@gmail.com writes: On Tue, Oct 6, 2009 at 4:16 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Kevin Hilman khil...@deeprootsystems.com writes: Hello, I've rebased/updated the PM branch based on current linux-omap master branch (2.6.32-rc1 based.) I've also updated the OMAP Power Management wiki, and the 'Current version' section highlights the changes, supported platforms as well as the features that have made it into mainline. http://elinux.org/OMAP_Power_Management#Current_version FYI... I just rebased the PM branch onto current omap/master. Some important user-visible changes: The /sys/power/* options are moving into debugfs. For mainline, these primarily debug options need to move to debugfs so I've moved them there. So, if you're missing some flag under /sys/power, it's now under /debug/pm_debug. I've updated the 'Using the PM branch' seciont of PM wiki[1] with the new filenames. Kevin [1] http://elinux.org/OMAP_Power_Management -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hi, Hi Juha, I build and tried this latest on Beagleboard (C2). Booting from MMC using ramdisk image. I changed the LL console to the 3rd UART. The issue I have is that after the system boots up it works for as long as I keep actively using it but if I leave it idle for a short time (~5s) it stops responding. I have tried waking it up using both UART and USER button on the board. This is with the default PM configuration. Thanks for testing, and reporting your problem. I have noticed exactly the same problem and am still investigating it. If I put the board into suspend (retention) it wakes up without any issues. Also, if I enable /debug/pm_debug/sleep_while_idle board wakes up without issues. Well the first couple characers on the console seem to go missing but I guess without CTS/RTS that is expected? Yes, the loss of the first character is expected. Any pointers would be appreciated. I also noticed that it works when 'sleep_while_idle' is enabled, and this has led me to suspect a bug in that serial timout path, but I have yet to debug further. FYI... I haven't figured out exactly why yet, but this patch gets things working again. Basically, I'm just leaving smart-idle disabled all the time. I've discovered that this is only needed when using the older u-boot binary I was downloading from beagleboard.org. I've had lots of PM headaches when using this u-boot and I had forgotten that I had (re)flashed with it. If I build and use a u-boot from the u-boot-ti repo[1], I don't have this problem anymore. Scratch that. Operator error. Actually, I still do have this particular problem, but upgrading u-boot solved some other unrelated problems. Sorry for the noise. Hi, I updated both x-loader and u-boot. And I also pulled the latest omap-pm and did a fresh build. I noticed there is a commit that should fix the serial port issue. Unfortunately I am still plagued by it. X-Loader 1.41 U-Boot 2009.08 (Oct 09 2009 - 15:59:45) Latest omap-om git pull (b7ecc865c5f0885fae4c4401fa78a24084f45c40). / Juha -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] updated PM branch, based on 2.6.32-rc1
On Mon, Oct 12, 2009 at 1:47 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Juha Kuikka wrote: [...] I updated both x-loader and u-boot. And I also pulled the latest omap-pm and did a fresh build. I noticed there is a commit that should fix the serial port issue. Unfortunately I am still plagued by it. X-Loader 1.41 U-Boot 2009.08 (Oct 09 2009 - 15:59:45) Latest omap-om git pull (b7ecc865c5f0885fae4c4401fa78a24084f45c40). That's the latest commit. But I haven't (intentionally) pushed anything to fix that serial issue yet. Which commit are you referring to that should fix the issue? This one: http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=commit;h=6ef4035c4a04bab8d94d8b80fcb90ea7230b8126 Committed 5 days ago. It looked like it might have something to do with this. My bad. Please ignore the noise. Juha -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] updated PM branch, based on 2.6.32-rc1
On Tue, Oct 6, 2009 at 4:16 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Kevin Hilman khil...@deeprootsystems.com writes: Hello, I've rebased/updated the PM branch based on current linux-omap master branch (2.6.32-rc1 based.) I've also updated the OMAP Power Management wiki, and the 'Current version' section highlights the changes, supported platforms as well as the features that have made it into mainline. http://elinux.org/OMAP_Power_Management#Current_version FYI... I just rebased the PM branch onto current omap/master. Some important user-visible changes: The /sys/power/* options are moving into debugfs. For mainline, these primarily debug options need to move to debugfs so I've moved them there. So, if you're missing some flag under /sys/power, it's now under /debug/pm_debug. I've updated the 'Using the PM branch' seciont of PM wiki[1] with the new filenames. Kevin [1] http://elinux.org/OMAP_Power_Management -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hi, I build and tried this latest on Beagleboard (C2). Booting from MMC using ramdisk image. I changed the LL console to the 3rd UART. The issue I have is that after the system boots up it works for as long as I keep actively using it but if I leave it idle for a short time (~5s) it stops responding. I have tried waking it up using both UART and USER button on the board. This is with the default PM configuration. If I put the board into suspend (retention) it wakes up without any issues. Also, if I enable /debug/pm_debug/sleep_while_idle board wakes up without issues. Well the first couple characers on the console seem to go missing but I guess without CTS/RTS that is expected? Any pointers would be appreciated. - Juha -- Madness takes it's toll. Please have exact change. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH - Omapzoom][NAND] Add prefetch and DMA support
Hi,
Do you have any plans to use the prefetch engine's feature to
synchronise to ready/busy pin? (GPMC_PREFETCH_CONFIG1's SYNCHROMODE=1)
That way we could avoid the busy-wait for the flash to be ready.
- Juha
On Thu, Nov 6, 2008 at 5:57 AM, vimal singh [EMAIL PROTECTED] wrote:
This patch adds prefetch support to access nand flash in both mpu and dma
mode.
This patch also adds 8-bit nand support (omap_read/write_buf8).
Prefetch can be used for both 8- and 16-bit devices.
Signed-off-by: Vimal Singh vimalsingh at ti.com
---
API's to access 8- and 16-bit NAND devices (omap_read/wirte_buf8/16)can be
removed after sometime (once sufficient amount of testing is done for both
kind
of devices).
vimal
---
arch/arm/mach-omap2/gpmc.c | 95 +++
arch/arm/plat-omap/include/mach/gpmc.h |4
drivers/mtd/nand/Kconfig | 17 ++
drivers/mtd/nand/omap2.c | 277
-
4 files changed, 386 insertions(+), 7 deletions(-)
Index: omapkernel/arch/arm/mach-omap2/gpmc.c
===
--- omapkernel.orig/arch/arm/mach-omap2/gpmc.c 2008-11-06 12:49:34.0
+0530
+++ omapkernel/arch/arm/mach-omap2/gpmc.c 2008-11-06 12:49:57.0
+0530
@@ -54,6 +54,12 @@
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
#define GPMC_SECTION_SHIFT 28 /* 128 MB */
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+#define CS_NUM_SHIFT 24
+#define ENABLE_PREFETCH7
+#define DMA_MPU_MODE 2
+#endif
+
#ifdef CONFIG_OMAP3_PM
/*
* Structure to save/restore gpmc context
@@ -407,6 +413,92 @@
}
EXPORT_SYMBOL(gpmc_cs_free);
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+/*
+ * gpmc_prefetch_init - configures default configuration for prefetch engine
+ */
+static void gpmc_prefetch_init(void)
+{
+ /* Setting the default threshold to 64 */
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x0);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, 0x40 8);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG2, 0x0);
+}
+
+/*
+ * gpmc_prefetch_start - configures and starts prefetch transfer
+ * @cs - nand cs (chip select) number
+ * @dma_mode: dma mode enable (1) or disable (0)
+ * @u32_count: number of bytes to be transferred
+ * @is_write: prefetch read(0) or write post(1) mode
+ */
+void gpmc_prefetch_start(int cs, int dma_mode,
+ unsigned int u32_count, int is_write)
+{
+ uint32_t prefetch_config1;
+ if (is_write) {
+ /* Set the amount of bytes to be prefetched */
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG2, u32_count);
+
+ /* Set dma/mpu mode, the post write and enable the engine
+* Set which cs is using the post write
+*/
+ prefetch_config1 = gpmc_read_reg(GPMC_PREFETCH_CONFIG1);
+ prefetch_config1 |= ((cs CS_NUM_SHIFT) |
+ (dma_mode DMA_MPU_MODE) |
+ (1 ENABLE_PREFETCH) | 0x1);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, prefetch_config1);
+ } else {
+ /* Set the amount of bytes to be prefetched */
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG2, u32_count);
+
+ /* Set dma/mpu mode, the prefech read and enable the engine
+* Set which cs is using the prefetch
+*/
+ prefetch_config1 = gpmc_read_reg(GPMC_PREFETCH_CONFIG1);
+ prefetch_config1 |= (((cs CS_NUM_SHIFT) |
+ (dma_mode DMA_MPU_MODE) |
+ (1 ENABLE_PREFETCH)) ~0x1);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, prefetch_config1);
+ }
+ /* Start the prefetch engine */
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x1);
+}
+EXPORT_SYMBOL(gpmc_prefetch_start);
+
+/*
+ * gpmc_prefetch_stop - disables and stops the prefetch engine
+ */
+void gpmc_prefetch_stop(void)
+{
+ uint32_t prefetch_config1;
+ /* stop the PFPW engine */
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x0);
+
+ /* Disable the PFPW engine */
+ prefetch_config1 = gpmc_read_reg(GPMC_PREFETCH_CONFIG1);
+ prefetch_config1 = ~((0x07 CS_NUM_SHIFT) |
+ (1 ENABLE_PREFETCH) |
+ (1 DMA_MPU_MODE) | 0x1);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, prefetch_config1);
+}
+EXPORT_SYMBOL(gpmc_prefetch_stop);
+
+/*
+ * gpmc_prefetch_status - reads prefetch status of engine
+ */
+int gpmc_prefetch_status(void)
+{
+ return gpmc_read_reg(GPMC_PREFETCH_STATUS);
+}
+EXPORT_SYMBOL(gpmc_prefetch_status);
+#else
+int gpmc_prefetch_status(void) {return 0; }
+void gpmc_prefetch_stop(void) {}
+void gpmc_prefetch_start(int
OMAP 2430 C64x DSP gateway/bridge
Hi, I was looking around to see if there is a DSP gateway/bridge driver for the C64x DSP in the OMAP2430 chip. So far it looks to me that the DSP bridge in the HEAD (3.3.1) only supports OMAP2420 and hance only the C55x core that is in there. DSP bridge available in http://www.openomap.org/pub/dspbridge/ only mentions OMAP3. Am I out of luck here? - Juha -- Madness takes it's toll. Please have exact change. -- 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 NAND: Fix __raw_readsl() length argument
On Wed, Oct 22, 2008 at 3:23 PM, Juha Kuikka [EMAIL PROTECTED] wrote:
On Wed, Oct 22, 2008 at 3:02 PM, David Brownell [EMAIL PROTECTED] wrote:
On Wednesday 22 October 2008, Juha Kuikka wrote:
- __raw_readsl(nand-IO_ADDR_R, buf, len / 2);
+ __raw_readsl(nand-IO_ADDR_R, buf, len / 4);
}
Shouldn't that have been __raw_readsw() though?
Hmh, good point.
Yeah, but the bug was from a patch from me ... sigh.
From the original code it looks like that was the intention but
readsl() works just as well.
Really? Both upper and lower 16-bit units have the right data?
Yes, all data comes in normally. I'm running JFFS2 on top of this.
I tested this on OMAP2430 and it works ok.
I don't see any mentions in the TRM about the width of the
GPMC_NAND_DATA registers but apparently the NAND engine happily
accepts 32bit accesses on bus.
Maybe this has to do with the FIFO behavior. It would certainly
make sense to allow reads of any size from the FIFO. If it were
raw reads on the data bus, then I'd expect that both 8 and 16 bit
widths would work. (Assuming NAND chips weren't in parallel...)
Right, for the FIFO in prefetch/writeposting block the TRM explicitly
states that it does accept 8/16/32 bit accesses but I don't see this
driver using the prefetch engine.
No parallel chips here, just a regular 16 bit wide LP NAND.
If the FIFO is active, and specified to support arbitrary width
accesses (that don't match the data bus), then by all means use
the __raw_readsl() call to maximize bandwidth use.
Sure. But interestingly enough even without explicitly using the FIFO
it seems to accept longer bus accesses.
Just to be on the safe side, maybe the patch should indeed be revised
to use __raw_readsw(..., len/2) ?
How does this look?
Subject: [PATCH] OMAP2 NAND: Change __raw_readsl() to __raw_readsw()
Signed-off-by: Juha Kuikka [EMAIL PROTECTED]
---
drivers/mtd/nand/omap2.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 2ede116..55ba746 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -196,7 +196,7 @@ static void omap_read_buf16(struct mtd_info *mtd,
u_char *buf, int len)
{
struct nand_chip *nand = mtd-priv;
- __raw_readsl(nand-IO_ADDR_R, buf, len / 2);
+ __raw_readsw(nand-IO_ADDR_R, buf, len / 2);
}
/*
--
1.6.0.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
Re: [PATCH] OMAP2 NAND: Fix __raw_readsl() length argument
On Wed, Oct 22, 2008 at 2:46 PM, David Brownell [EMAIL PROTECTED] wrote: On Wednesday 22 October 2008, Juha Kuikka wrote: - __raw_readsl(nand-IO_ADDR_R, buf, len / 2); + __raw_readsl(nand-IO_ADDR_R, buf, len / 4); } Shouldn't that have been __raw_readsw() though? Hmh, good point. From the original code it looks like that was the intention but readsl() works just as well. I tested this on OMAP2430 and it works ok. I don't see any mentions in the TRM about the width of the GPMC_NAND_DATA registers but apparently the NAND engine happily accepts 32bit accesses on bus. - Juha -- Madness takes it's toll. Please have exact change. -- 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 NAND: Fix __raw_readsl() length argument
On Wed, Oct 22, 2008 at 3:02 PM, David Brownell [EMAIL PROTECTED] wrote: On Wednesday 22 October 2008, Juha Kuikka wrote: - __raw_readsl(nand-IO_ADDR_R, buf, len / 2); + __raw_readsl(nand-IO_ADDR_R, buf, len / 4); } Shouldn't that have been __raw_readsw() though? Hmh, good point. Yeah, but the bug was from a patch from me ... sigh. From the original code it looks like that was the intention but readsl() works just as well. Really? Both upper and lower 16-bit units have the right data? Yes, all data comes in normally. I'm running JFFS2 on top of this. I tested this on OMAP2430 and it works ok. I don't see any mentions in the TRM about the width of the GPMC_NAND_DATA registers but apparently the NAND engine happily accepts 32bit accesses on bus. Maybe this has to do with the FIFO behavior. It would certainly make sense to allow reads of any size from the FIFO. If it were raw reads on the data bus, then I'd expect that both 8 and 16 bit widths would work. (Assuming NAND chips weren't in parallel...) Right, for the FIFO in prefetch/writeposting block the TRM explicitly states that it does accept 8/16/32 bit accesses but I don't see this driver using the prefetch engine. No parallel chips here, just a regular 16 bit wide LP NAND. If the FIFO is active, and specified to support arbitrary width accesses (that don't match the data bus), then by all means use the __raw_readsl() call to maximize bandwidth use. Sure. But interestingly enough even without explicitly using the FIFO it seems to accept longer bus accesses. Just to be on the safe side, maybe the patch should indeed be revised to use __raw_readsw(..., len/2) ? - Juha -- Madness takes it's toll. Please have exact change. -- 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: HEAD unbootable on 2430SDP
On Mon, Oct 6, 2008 at 5:08 PM, Juha Kuikka [EMAIL PROTECTED] wrote: On Mon, Oct 6, 2008 at 4:46 PM, Woodruff, Richard [EMAIL PROTECTED] wrote: I am running into a weird problem with the current HEAD on OMAP2430SDP. It seems the execution goes into infinite loop in intc_bank_read_reg() function. In the: while (!(intc_bank_read_reg(bank, INTC_SYSSTATUS) 0x1)) /* Wait for reset to complete */; Did your board boot loader setup the peripheral port remap register? I'm using the u-boot snapshot from http://linux.omap.com/pub/bootloader/2430sdp/source/u-boot-Sept2507.tar.gz. And it seems to map it. I might also add that the kernel at http://linux.omap.com/pub/kernel/2430sdp/source/linux-2.6.14-omap2-v5.tgz boots without this issue. - Juha -- Madness takes it's toll. Please have exact change. -- 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
HEAD unbootable on 2430SDP
Hi, I am running into a weird problem with the current HEAD on OMAP2430SDP. It seems the execution goes into infinite loop in intc_bank_read_reg() function. In the: while (!(intc_bank_read_reg(bank, INTC_SYSSTATUS) 0x1)) /* Wait for reset to complete */; to be specific. It seems that the address in bank-base_reg does not point to a virtual address that is mapped to the INTC registers. I'm using the omap_2430sdp_defconfig with CONFIG_GPIO_TWL4030 added. Toolchain I used is: gcc version 4.2.3 (Sourcery G++ Lite 2008q1-126) Before digging deeper I was wondering if anyone else sees this? -- Madness takes it's toll. Please have exact change. -- 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
Problems with 2430 NAND prefetch engine
Hi, I am trying to use the NAND prefetch engine to speed up NAND access. In GPMC CS0 is the NAND chip. GPMC_CONFIG7_0 is set to 0x084c by u-boot. Hence the address for this CS should be 0x0C00. Documentation indicates that the FIFO should be accessible in any associated chip-select region after the engine has been enabled. In linux I use ioremap() to map 0x0C00 and use the returned pointer to access the prefetch engine FIFO. Prefetch engine is configured and started. I get FIFOEVENT interrupt from it and try to read the fifo by using this ioremap's pointer but kernel crashes with: Unhandled fault: external abort on non-linefetch (0x008) at 0xc4854000 0xc4854000 corresponds to the pointer ioremap() returned. Apparently I miss something either in HW or kernel but I cannot think of anything. Conventional access to the NAND chip through COMMAND/ADDRESS/DATA registers works ok. Any ideas would be appreciated. - Juha -- Madness takes it's toll. Please have exact change. -- 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
