[DSS2] RFBI
Hi, have anybody had any progress with making RFBI in DSS2 working? I was out of development for some time, might there be any progress? Probably I could cooperate with somebody working on it or help with testing. Alas, I can't dedicate full time on it, but I'm still interested. All the best, S. -- 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: RFBI: how to make it work?
Hi, all!
I'm trying to rewrite my old driver to DSS2. The driver is for small
176x220 module attached over RFBI interface
on OMAP3525. It basically works with old kernel and drivers/video/omap/*.
I still can't make it work, so is it known which code is necessary to
initialize a panel? I tried
to compare APIs with old and new subsystems and can't see what I am doing wrong.
In original code, I just init rfbi and dispc, and then directly write
to panel (commands and their parameters).
The same code with new API does not seem to produce any results.
Display stays uninitialized,
so commands seem not to get to it.
The code:
...
static struct omap_video_timings panel_timings = {
.x_res = 176,
.y_res = 220,
};
static int panel_probe(struct omap_dss_device *dssdev)
{
int err;
struct rfbi_timings t;
pr_debug(%s\n, __func__);
dssdev-panel.config = OMAP_DSS_LCD_TFT |
OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS;
dssdev-panel.timings = panel_timings;
dssdev-phy.rfbi.channel = 0;
dssdev-ctrl.pixel_size = 24;
dssdev-phy.rfbi.data_lines = 8;
hx8340_dss = dssdev;
t.cs_on_time = 0;
t.we_on_time = t.cs_on_time + 0;
t.re_on_time = t.we_on_time + 0;
t.we_off_time = t.we_on_time + 15000;
t.re_off_time = t.we_off_time + 15000;
t.access_time = 0;
t.cs_off_time = t.we_off_time + 0;
t.we_cycle_time = t.cs_off_time + 1;
t.re_cycle_time = t.we_cycle_time + 15000;
t.cs_pulse_width = 41000;
dssdev-ctrl.rfbi_timings = t;
if (dssdev-platform_enable)
dssdev-platform_enable(dssdev);
.
return 0;
}
static void cmd_data(u8 cmd, u8 data)
{
omap_rfbi_write_command(cmd, 1);
omap_rfbi_write_data(data, 1);
}
static int panel_power_on(struct omap_dss_device *dssdev)
{
int err;
err = omapdss_rfbi_display_enable(dssdev);
if (err 0)
return err;
if (dssdev-platform_enable) {
err = dssdev-platform_enable(dssdev);
if (err)
return err;
}
cmd_data(0x18, 0x44);
cmd_data(0x1B, 0x44);
.
return 0;
}
static int panel_enable(struct omap_dss_device *dssdev)
{
panel_power_on(dssdev);
dssdev-state = OMAP_DSS_DISPLAY_ACTIVE;
return 0;
}
...
static void panel_get_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings)
{
*timings = dssdev-panel.timings;
}
static int panel_check_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings)
{
return 0;
}
struct omap_dss_driver hx8340_panel_driver = {
.probe = panel_probe,
.enable = panel_enable,
...
.get_timings= panel_get_timings,
.check_timings = panel_check_timings,
...
.driver = {
.name = custom-panel,
.owner = THIS_MODULE,
},
};
Any ideas on what is wrong with initialization?
Driver works with old susbystem, but it is very messed-up and requires
patching of subsystem itself.
I skip timer-based auto-update setup here, because I want to make
initialization work first and then move
to that portion later.
Thanks a lot,
S.
--
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] OMAP: McBSP: Add 32-bit mode support
This patchs should allow to use 32-bit samples on e.g. TLV320AIC23 codec,
or others.
---
sound/soc/omap/omap-mcbsp.c | 30 ++
1 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 8ad9dc9..a875d5d 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -295,8 +295,20 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
omap_mcbsp_dai_dma_params[id][substream-stream].dma_req = dma;
omap_mcbsp_dai_dma_params[id][substream-stream].port_addr = port;
omap_mcbsp_dai_dma_params[id][substream-stream].sync_mode = sync_mode;
- omap_mcbsp_dai_dma_params[id][substream-stream].data_type =
- OMAP_DMA_DATA_TYPE_S16;
+ switch(params_format(params)) {
+ case SNDRV_PCM_FORMAT_S16_LE:
+ omap_mcbsp_dai_dma_params[id][substream-stream].data_type =
+OMAP_DMA_DATA_TYPE_S16;
+ break;
+ case SNDRV_PCM_FORMAT_S32_LE:
+ omap_mcbsp_dai_dma_params[id][substream-stream].data_type =
+OMAP_DMA_DATA_TYPE_S32;
+ break;
+ default:
+ omap_mcbsp_dai_dma_params[id][substream-stream].data_type =
+OMAP_DMA_DATA_TYPE_S16;
+ break;
+ }
snd_soc_dai_set_dma_data(cpu_dai, substream,
omap_mcbsp_dai_dma_params[id][substream-stream]);
@@ -330,6 +342,14 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
regs-xcr2 |= XWDLEN2(OMAP_MCBSP_WORD_16);
regs-xcr1 |= XWDLEN1(OMAP_MCBSP_WORD_16);
break;
+ case SNDRV_PCM_FORMAT_S32_LE:
+ /* Set word lengths */
+ wlen = 32;
+ regs-rcr2 |= RWDLEN2(OMAP_MCBSP_WORD_32);
+ regs-rcr1 |= RWDLEN1(OMAP_MCBSP_WORD_32);
+ regs-xcr2 |= XWDLEN2(OMAP_MCBSP_WORD_32);
+ regs-xcr1 |= XWDLEN1(OMAP_MCBSP_WORD_32);
+ break;
default:
/* Unsupported PCM format */
return -EINVAL;
@@ -623,13 +643,15 @@ static struct snd_soc_dai_ops omap_mcbsp_dai_ops = {
.channels_min = 1, \
.channels_max = 16, \
.rates = OMAP_MCBSP_RATES, \
- .formats = SNDRV_PCM_FMTBIT_S16_LE, \
+ .formats = SNDRV_PCM_FMTBIT_S16_LE |\
+ SNDRV_PCM_FMTBIT_S32_LE, \
}, \
.capture = {\
.channels_min = 1, \
.channels_max = 16, \
.rates = OMAP_MCBSP_RATES, \
- .formats = SNDRV_PCM_FMTBIT_S16_LE, \
+ .formats = SNDRV_PCM_FMTBIT_S16_LE |\
+ SNDRV_PCM_FMTBIT_S32_LE, \
}, \
.ops = omap_mcbsp_dai_ops, \
.private_data = mcbsp_data[(link_id)].bus_id, \
--
1.7.0.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] OMAP: McBSP: Add 32-bit mode support
This patchs should allow to use 32-bit samples on e.g. TLV320AIC3x codec,
or others.
Signed-off-by: Sergey Lapin sla...@ossfans.org
---
sound/soc/omap/omap-mcbsp.c | 30 ++
1 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 8ad9dc9..a875d5d 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -295,8 +295,20 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
omap_mcbsp_dai_dma_params[id][substream-stream].dma_req = dma;
omap_mcbsp_dai_dma_params[id][substream-stream].port_addr = port;
omap_mcbsp_dai_dma_params[id][substream-stream].sync_mode = sync_mode;
- omap_mcbsp_dai_dma_params[id][substream-stream].data_type =
- OMAP_DMA_DATA_TYPE_S16;
+ switch(params_format(params)) {
+ case SNDRV_PCM_FORMAT_S16_LE:
+ omap_mcbsp_dai_dma_params[id][substream-stream].data_type =
+OMAP_DMA_DATA_TYPE_S16;
+ break;
+ case SNDRV_PCM_FORMAT_S32_LE:
+ omap_mcbsp_dai_dma_params[id][substream-stream].data_type =
+OMAP_DMA_DATA_TYPE_S32;
+ break;
+ default:
+ omap_mcbsp_dai_dma_params[id][substream-stream].data_type =
+OMAP_DMA_DATA_TYPE_S16;
+ break;
+ }
snd_soc_dai_set_dma_data(cpu_dai, substream,
omap_mcbsp_dai_dma_params[id][substream-stream]);
@@ -330,6 +342,14 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
regs-xcr2 |= XWDLEN2(OMAP_MCBSP_WORD_16);
regs-xcr1 |= XWDLEN1(OMAP_MCBSP_WORD_16);
break;
+ case SNDRV_PCM_FORMAT_S32_LE:
+ /* Set word lengths */
+ wlen = 32;
+ regs-rcr2 |= RWDLEN2(OMAP_MCBSP_WORD_32);
+ regs-rcr1 |= RWDLEN1(OMAP_MCBSP_WORD_32);
+ regs-xcr2 |= XWDLEN2(OMAP_MCBSP_WORD_32);
+ regs-xcr1 |= XWDLEN1(OMAP_MCBSP_WORD_32);
+ break;
default:
/* Unsupported PCM format */
return -EINVAL;
@@ -623,13 +643,15 @@ static struct snd_soc_dai_ops omap_mcbsp_dai_ops = {
.channels_min = 1, \
.channels_max = 16, \
.rates = OMAP_MCBSP_RATES, \
- .formats = SNDRV_PCM_FMTBIT_S16_LE, \
+ .formats = SNDRV_PCM_FMTBIT_S16_LE |\
+ SNDRV_PCM_FMTBIT_S32_LE, \
}, \
.capture = {\
.channels_min = 1, \
.channels_max = 16, \
.rates = OMAP_MCBSP_RATES, \
- .formats = SNDRV_PCM_FMTBIT_S16_LE, \
+ .formats = SNDRV_PCM_FMTBIT_S16_LE |\
+ SNDRV_PCM_FMTBIT_S32_LE, \
}, \
.ops = omap_mcbsp_dai_ops, \
.private_data = mcbsp_data[(link_id)].bus_id, \
--
1.7.0.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] OMAP: McBSP: Add 32-bit mode support
This patchs should allow to use 32-bit samples on e.g. TLV320AIC3x codec,
or others.
Signed-off-by: Sergey Lapin sla...@ossfans.org
---
sound/soc/omap/omap-mcbsp.c | 28
1 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 8ad9dc9..2dead3f 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -295,8 +295,18 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
omap_mcbsp_dai_dma_params[id][substream-stream].dma_req = dma;
omap_mcbsp_dai_dma_params[id][substream-stream].port_addr = port;
omap_mcbsp_dai_dma_params[id][substream-stream].sync_mode = sync_mode;
- omap_mcbsp_dai_dma_params[id][substream-stream].data_type =
- OMAP_DMA_DATA_TYPE_S16;
+ switch (params_format(params)) {
+ case SNDRV_PCM_FORMAT_S16_LE:
+ omap_mcbsp_dai_dma_params[id][substream-stream].data_type =
+OMAP_DMA_DATA_TYPE_S16;
+ break;
+ case SNDRV_PCM_FORMAT_S32_LE:
+ omap_mcbsp_dai_dma_params[id][substream-stream].data_type =
+OMAP_DMA_DATA_TYPE_S32;
+ break;
+ default:
+ return -EINVAL;
+ }
snd_soc_dai_set_dma_data(cpu_dai, substream,
omap_mcbsp_dai_dma_params[id][substream-stream]);
@@ -330,6 +340,14 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
regs-xcr2 |= XWDLEN2(OMAP_MCBSP_WORD_16);
regs-xcr1 |= XWDLEN1(OMAP_MCBSP_WORD_16);
break;
+ case SNDRV_PCM_FORMAT_S32_LE:
+ /* Set word lengths */
+ wlen = 32;
+ regs-rcr2 |= RWDLEN2(OMAP_MCBSP_WORD_32);
+ regs-rcr1 |= RWDLEN1(OMAP_MCBSP_WORD_32);
+ regs-xcr2 |= XWDLEN2(OMAP_MCBSP_WORD_32);
+ regs-xcr1 |= XWDLEN1(OMAP_MCBSP_WORD_32);
+ break;
default:
/* Unsupported PCM format */
return -EINVAL;
@@ -623,13 +641,15 @@ static struct snd_soc_dai_ops omap_mcbsp_dai_ops = {
.channels_min = 1, \
.channels_max = 16, \
.rates = OMAP_MCBSP_RATES, \
- .formats = SNDRV_PCM_FMTBIT_S16_LE, \
+ .formats = SNDRV_PCM_FMTBIT_S16_LE |\
+ SNDRV_PCM_FMTBIT_S32_LE, \
}, \
.capture = {\
.channels_min = 1, \
.channels_max = 16, \
.rates = OMAP_MCBSP_RATES, \
- .formats = SNDRV_PCM_FMTBIT_S16_LE, \
+ .formats = SNDRV_PCM_FMTBIT_S16_LE |\
+ SNDRV_PCM_FMTBIT_S32_LE, \
}, \
.ops = omap_mcbsp_dai_ops, \
.private_data = mcbsp_data[(link_id)].bus_id, \
--
1.7.0.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
DSS2 RFBI
Dear Tomi, If you remember, some time ago you mentioned you have some hacky examples on usage of RFBI driver in DSS2 subsystem. Since I'm going to have major rework for my driver, I'd like to port it to DSS2 and eventually submit for merge. So, could you provide these patches for everyone's sake? Thanks a lot, S. -- 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: DSS2 RFBI
No, I don't remember =). But I was probably talking about the hack to get N800's display working. Unfortunately I don't have those hacks anywhere around, and they wouldn't even compile anymore. I did post the hacks long time ago, you can try googling them. Here's at least one: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg08394.html However, I'm not sure how usable that is with the latest DSS2. Thanks a lot! S. -- 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
MUSB crash on OMAP3 board with second load of gadget
Dear Felipe, Bug I've reported earlier is still reproducible. Steps are within earlier mail (one way is to insert USB cable, use g_file/mass_storage, allow device to mount, rmmod it, load g_ether get crash). gnome5:~# insmod ./g_ether.ko [ 1085.923736] g_ether gadget: using random self ethernet address [ 1085.934234] g_ether gadget: using random host ethernet address [ 1085.949768] usb0: MAC 1a:b9:8c:c5:b3:be [ 1085.960449] usb0: HOST MAC a2:65:53:2b:4f:a4 [ 1085.967315] g_ether gadget: Ethernet Gadget, version: Memorial Day 2008 [ 1085.978851] g_ether gadget: g_ether ready gnome5:~# [ 1097.059326] kernel BUG at arch/arm/mm/dma-mapping.c:426! [ 1097.064697] Unable to handle kernel NULL pointer dereference at virtual address [ 1097.072845] pgd = c0004000 [ 1097.075561] [] *pgd= [ 1097.079162] Internal error: Oops: 817 [#1] PREEMPT [ 1097.083984] last sysfs file: /sys/devices/platform/i2c_omap.1/i2c-1/1-0048/twl4030_usb/vbus [ 1097.092376] Modules linked in: g_ether [last unloaded: g_mass_storage] [ 1097.098968] CPU: 0Not tainted (2.6.33-11957-gdb0da96-dirty #5) [ 1097.105285] PC is at __bug+0x18/0x24 [ 1097.108886] LR is at __bug+0x14/0x24 [ 1097.112487] pc : [c003d88c]lr : [c003d888]psr: 41d3 [ 1097.112518] sp : c03d5e50 ip : 0002822b fp : c7862048 [ 1097.124053] r10: fa0ab000 r9 : fa0ab100 r8 : fa0ab100 [ 1097.129302] r7 : 0001 r6 : c7862064 r5 : r4 : c8998000 [ 1097.135864] r3 : r2 : c03d5e44 r1 : c0367391 r0 : 0042 [ 1097.142456] Flags: nZcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [ 1097.149963] Control: 10c5387d Table: 86c68019 DAC: 0017 [ 1097.155761] Process swapper (pid: 0, stack limit = 0xc03d42e8) [ 1097.161621] Stack: (0xc03d5e50 to 0xc03d6000) [ 1097.166015] 5e40: c8998000 c00413b8 c6d8de00 c02083a8 [ 1097.174255] 5e60: c03d5e9e c020615c c7862048 0008 c03d5e9e 0008 c7862000 [ 1097.182464] 5e80: 0001 c0206d1c c009550c c7800ec0 c7805bc0 c58301f8 6153 0680550c [ 1097.190704] 5ea0: 0100 c03f0040 c03f01e4 00f0 c7862000 0008 0099 [ 1097.198944] 5ec0: c03d4000 001f c0205e94 c7862000 0008 fa0ab000 [ 1097.207183] 5ee0: c7862000 4153 005c 0001 c0205fcc c7932580 [ 1097.215423] 5f00: c0091a04 c7932580 c03e80e8 005c 0002 0001 c0093998 [ 1097.223632] 5f20: 005c c040bb14 c0039070 fa20 c040bb14 c0039ac8 [ 1097.231872] 5f40: 001faa3b 001faa3b c040bb14 0003 c040bb14 c040bb14 [ 1097.240112] 5f60: c042df10 411fc082 001f c03d5f88 c004b038 c004b044 [ 1097.248352] 5f80: 6053 001faa3b 388e67b8 2535913a 388e67b8 2515e6ff [ 1097.256561] 5fa0: c03dae18 c03d4000 c040b09c c03dae18 c03dad48 c0217d60 c03d4000 c040b09c [ 1097.264801] 5fc0: c0028014 c03d7c1c 80026080 c003b4dc c0413d78 c000893c c000848c [ 1097.273040] 5fe0: c0028018 10c53c7d c040b1b0 80008034 [ 1097.281280] [c003d88c] (__bug+0x18/0x24) from [c00413b8] (___dma_single_dev_to_cpu+0x38/0x68) [ 1097.290222] [c00413b8] (___dma_single_dev_to_cpu+0x38/0x68) from [c02083a8] (musb_g_giveback+0x80/0x164) [ 1097.300140] [c02083a8] (musb_g_giveback+0x80/0x164) from [c0206d1c] (musb_g_ep0_irq+0x32c/0x910) [ 1097.309326] [c0206d1c] (musb_g_ep0_irq+0x32c/0x910) from [c0205e94] (musb_interrupt+0x2fc/0x3d4) [ 1097.318542] [c0205e94] (musb_interrupt+0x2fc/0x3d4) from [c0205fcc] (generic_interrupt+0x60/0x94) [ 1097.327819] [c0205fcc] (generic_interrupt+0x60/0x94) from [c0091a04] (handle_IRQ_event+0x34/0xf4) [ 1097.337127] [c0091a04] (handle_IRQ_event+0x34/0xf4) from [c0093998] (handle_level_irq+0xc0/0x150) [ 1097.346405] [c0093998] (handle_level_irq+0xc0/0x150) from [c0039070] (asm_do_IRQ+0x70/0x90) [ 1097.355163] [c0039070] (asm_do_IRQ+0x70/0x90) from [c0039ac8] (__irq_svc+0x48/0xa8) [ 1097.363220] Exception stack(0xc03d5f40 to 0xc03d5f88) [ 1097.368316] 5f40: 001faa3b 001faa3b c040bb14 0003 c040bb14 c040bb14 [ 1097.376556] 5f60: c042df10 411fc082 001f c03d5f88 c004b038 c004b044 [ 1097.384765] 5f80: 6053 [ 1097.388305] [c0039ac8] (__irq_svc+0x48/0xa8) from [c004b044] (omap3_enter_idle+0x104/0x134) [ 1097.397064] [c004b044] (omap3_enter_idle+0x104/0x134) from [c0217d60] (cpuidle_idle_call+0xa4/0x104) [ 1097.406616] [c0217d60] (cpuidle_idle_call+0xa4/0x104) from [c003b4dc] (cpu_idle+0x48/0x98) [ 1097.415283] [c003b4dc] (cpu_idle+0x48/0x98) from [c000893c] (start_kernel+0x26c/0x2cc) [ 1097.423614] [c000893c] (start_kernel+0x26c/0x2cc) from [80008034] (0x80008034) [ 1097.431243] Code: e92d4010 e59f000c eb0a6c93 e3a03000 (e5833000) [ 1097.437469] ---[ end trace a64ad4cab94f5387 ]--- [ 1097.442138] Kernel panic - not syncing: Fatal exception in interrupt [ 1097.448608] [c003f92c] (unwind_backtrace+0x0/0xdc) from [c02d8a00]
Re: MUSB crash on OMAP3 board with second load of gadget
0 at 1:38 PM, Sergey Lapin slapi...@gmail.com wrote: Hi, [ 580.082427] [c0030ac4] (__irq_svc+0x44/0xa8) from [c00420dc] (omap3_enter_idle+0x124/0x158) [ 580.091186] [c00420dc] (omap3_enter_idle+0x124/0x158) from [c022d708] (cpuidle_idle_call+0xa4/0x180) [ 580.100738] [c022d708] (cpuidle_idle_call+0xa4/0x180) from [c00324dc] (cpu_idle+0x48/0x98) [ 580.109436] [c00324dc] (cpu_idle+0x48/0x98) from [c0008934] (start_kernel+0x268/0x2c8) [ 580.117767] [c0008934] (start_kernel+0x268/0x2c8) from [80008034] (0x80008034) [ 580.125366] Code: c03a876b e92d4013 e5903004 e1a04000 (e593c000) [ 580.131652] ---[ end trace 42b8f4f7e396999c ]--- [ 580.136291] Kernel panic - not syncing: Fatal exception in interrupt I've managed to debug that in my case, drivers/usb/musb/musb_gadget_ep0.c: musb_read_setup(): /* clean up any leftover transfers */ r = next_ep0_request(musb); in this place we have somewhat corrupted usb_request. Any ideas why? By the way, crash is not reproduced if cable is removed before module unloading (and all USB activity processed). S. Is this panic looks like list corruption bug which was mentioned earlier? with my new test script I get these panic messages with the same frequency as 6b6b6b6b ones. If I understand right, 6b6b6b6b = slab corruption, and 00200200 = LIST_POISON2, which means list corruption. [ 275.079284] Unable to handle kernel paging request at virtual address 00200200 [ 275.086578] pgd = c0004000 [ 275.089294] [00200200] *pgd= [ 275.092895] Internal error: Oops: 5 [#1] PREEMPT [ 275.097534] last sysfs file: /sys/module/musb_hdrc/parameters/debug [ 275.103851] Modules linked in: g_mass_storage [last unloaded: g_mass_storage] [ 275.111053] CPU: 0Not tainted (2.6.33-rc5-07242-gb226820-dirty #14) [ 275.117828] PC is at list_del+0xc/0x90 [ 275.121582] LR is at musb_g_giveback+0x20/0x118 [ 275.126159] pc : [c01b71cc]lr : [c021daa4]psr: 21d3 [ 275.126159] sp : c03f7db0 ip : 00074df4 fp : c7832048 [ 275.137725] r10: fa0ab000 r9 : fa0ab100 r8 : fa0ab100 [ 275.142974] r7 : 0001 r6 : c7832064 r5 : r4 : c718c618 [ 275.149536] r3 : 00200200 r2 : r1 : c718c600 r0 : c718c618 [ 275.156097] Flags: nzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [ 275.163635] Control: 10c5387d Table: 8725c019 DAC: 0017 [ 275.169403] Process swapper (pid: 0, stack limit = 0xc03f62e8) [ 275.175292] Stack: (0xc03f7db0 to 0xc03f8000) [ 275.179687] 7da0: c718c618 c718c600 c718c600 c021daa4 [ 275.187896] 7dc0: c7832048 c02f10dc c03affcf c03f7ddc c718c618 c718c600 c7832000 [ 275.196136] 7de0: 0001 c021c3c4 0006 0100 0040 c03f6000 06800099 [ 275.204376] 7e00: 0100 0040 00f0 c7832000 0008 0099 [ 275.212615] 7e20: c021b4f0 0008 0001 [ 275.220855] 7e40: c7832000 6153 005c c03f6000 005c c021b628 c78bdc80 c78bdc80 [ 275.229095] 7e60: 005c c0090d58 c78bdc80 c04099cc 005c 0104 0103 c03f6000 [ 275.237304] 7e80: 0002 c0092e1c 005c c03f7f40 c0030070 fa20 [ 275.245544] 7ea0: c0030ac4 0003 c0436700 005c c03f6000 [ 275.253784] 7ec0: 0002 0001 000a 0002 00074c9f c03f7ef0 [ 275.262023] 7ee0: c0063e28 c0063e40 2153 c78bdc80 c78bdc80 005c [ 275.270263] 7f00: c78bdc80 005c 0003 0002 0001 c03f6000 001f [ 275.278472] 7f20: c006401c 005c c0030074 fa20 0003 c0030ac4 [ 275.286743] 7f40: 002e19b8 002e19b8 c04316b4 0003 0003 c04316b4 [ 275.294982] 7f60: 800273e0 411fc082 001f c03f7f88 c00420ec c00420f8 [ 275.303222] 7f80: 6053 002e19b8 386d712e 178b0dd5 386d712e 175cf41d [ 275.311462] 7fa0: c03fbd50 c03fbe20 c0430cdc c03fbd50 c0476b48 c022d93c c03f6000 c0430cdc [ 275.319702] 7fc0: c0029014 c03f9c10 800273e0 c00324dc c045c9c0 c0008934 c000848c [ 275.327911] 7fe0: c0029018 10c53c7d c0430df0 80008034 [ 275.336181] [c01b71cc] (list_del+0xc/0x90) from [c021daa4] (musb_g_giveback+0x20/0x118) [ 275.344573] [c021daa4] (musb_g_giveback+0x20/0x118) from [c021c3c4] (musb_g_ep0_irq+0x358/0x940) [ 275.353790] [c021c3c4] (musb_g_ep0_irq+0x358/0x940) from [c021b4f0] (musb_interrupt+0x2fc/0x3d4) [ 275.362976] [c021b4f0] (musb_interrupt+0x2fc/0x3d4) from [c021b628] (generic_interrupt+0x60/0x94) [ 275.372283] [c021b628] (generic_interrupt+0x60/0x94) from [c0090d58] (handle_IRQ_event+0xa4/0x1e0) [ 275.381652] [c0090d58] (handle_IRQ_event+0xa4/0x1e0) from [c0092e1c] (handle_level_irq+0xc0/0x150) [ 275.391052] [c0092e1c] (handle_level_irq+0xc0/0x150) from [c0030070] (asm_do_IRQ+0x70/0x90) [ 275.399810] [c0030070
MUSB crash on OMAP3 board with second load of gadget
Hi! I have crashes in MUSB code when working with USB gadget drivers. Kernel version: linux-omap master d8ebff302ff819587377b123e900e501e4135d86 To reproduce: (USB device cable should be attached). dd if=/dev/zero of=/tmp/disk bs=1k count=1024 mkdosfs -F 32 /tmp/disk insmod g_mass_storage file=/tmp/disk stall=0 Wait till disk is mounted on host, then rmmod g_mass_storage insmod g_mass_storage file=/tmp/disk stall=0 And here we get Oops in include/linux/list.h line 93, list_del function, which leads us to drivers/usb/musb/musb_gadget.c, function void musb_g_giveback( struct musb_ep *ep, struct usb_request *request, int status), just at the beginning of function. if we add pr_debug(list.prev = %p\n, request-list.prev); pr_debug(list.next = %p\n, request-list.next); and we see list.prev = 6b6b6b6b list.next = 6b6b6b6b And these are NOT values set during list deletion. Any ideas where to debug from here? If I just do return from that function in case of list.prev = 6b6b6b6b, then there's no crash, but there's no working USB either. if I just ignore list_del, I have crash later, where it seems to execute bad code from address 0x6b6b6b6a. Please, help! Thanks a lot, S. -- 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: MUSB crash on OMAP3 board with second load of gadget
On Thu, Jan 21, 2010 at 3:28 PM, Felipe Balbi felipe.ba...@nokia.com wrote: On Thu, Jan 21, 2010 at 12:26:49PM +0100, ext Sergey Lapin wrote: Hi! I have crashes in MUSB code when working with USB gadget drivers. Kernel version: linux-omap master d8ebff302ff819587377b123e900e501e4135d86 To reproduce: (USB device cable should be attached). dd if=/dev/zero of=/tmp/disk bs=1k count=1024 mkdosfs -F 32 /tmp/disk insmod g_mass_storage file=/tmp/disk stall=0 Wait till disk is mounted on host, then rmmod g_mass_storage insmod g_mass_storage file=/tmp/disk stall=0 And here we get Oops in include/linux/list.h line 93, I guess it's the list corruption bug, right ? I've seen that, but couldn't get it to reproduce. Now that you said, I'll try to find a fix for it. It seems so, thanks a lot! S. -- 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: MUSB crash on OMAP3 board with second load of gadget
On Thu, Jan 21, 2010 at 4:23 PM, Sergey Lapin slapi...@gmail.com wrote: On Thu, Jan 21, 2010 at 3:28 PM, Felipe Balbi felipe.ba...@nokia.com wrote: On Thu, Jan 21, 2010 at 12:26:49PM +0100, ext Sergey Lapin wrote: Hi! I have crashes in MUSB code when working with USB gadget drivers. Kernel version: linux-omap master d8ebff302ff819587377b123e900e501e4135d86 To reproduce: (USB device cable should be attached). dd if=/dev/zero of=/tmp/disk bs=1k count=1024 mkdosfs -F 32 /tmp/disk insmod g_mass_storage file=/tmp/disk stall=0 Wait till disk is mounted on host, then rmmod g_mass_storage insmod g_mass_storage file=/tmp/disk stall=0 And here we get Oops in include/linux/list.h line 93, I guess it's the list corruption bug, right ? I've seen that, but couldn't get it to reproduce. Now that you said, I'll try to find a fix for it. If you're interested, this is my Oops dump: [12034.007812] Unable to handle kernel NULL pointer dereference at virtual address 0001 [12034.015960] pgd = c0004000 [12034.018676] [0001] *pgd= [12034.022308] Internal error: Oops: 17 [#1] PREEMPT [12034.027038] last sysfs file: /sys/devices/platform/leds-gpio/leds/gnome5::red14/brightness [12034.035339] Modules linked in: g_mass_storage [last unloaded: g_mass_storage] [12034.042541] CPU: 0Not tainted (2.6.33-rc4-07149-ga29cd26-dirty #9) [12034.049224] PC is at list_del+0xc/0x90 [12034.053009] LR is at musb_g_giveback+0x28/0x130 [12034.057586] pc : [c01b70d0]lr : [c021d928]psr: 41d3 [12034.057586] sp : c03f7e48 ip : 00029fa5 fp : c7832048 [12034.069122] r10: fa0ab000 r9 : fa0ab100 r8 : fa0ab100 [12034.074371] r7 : 0001 r6 : c7832064 r5 : r4 : c6872718 [12034.080963] r3 : 0001 r2 : c03f7e4c r1 : c03b02cb r0 : c6872718 [12034.087524] Flags: nZcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [12034.095031] Control: 10c5387d Table: 87024019 DAC: 0017 [12034.100830] Process swapper (pid: 0, stack limit = 0xc03f62e8) [12034.106689] Stack: (0xc03f7e48 to 0xc03f8000) [12034.111083] 7e40: c6872718 c03b02cb c6872700 c021d928 c03f7e96 c021b650 [12034.119323] 7e60: c7832048 0008 c03f7e96 0008 c7832000 0001 c021c230 [12034.127563] 7e80: c0407a40 c0407538 0f2c8be7 0680c278 0100 0040 [12034.135803] 7ea0: 0fd51da8 00f0 c7832000 0008 0099 [12034.144042] 7ec0: c021b388 c7832000 0008 fa0ab000 c7832000 6153 [12034.152252] 7ee0: 005c c03f6000 005c c021b4c0 c78b9d00 c78b9d00 005c c0090b80 [12034.160491] 7f00: c78b9d00 c04099cc 005c 0002 0001 c03f6000 001f c0092c44 [12034.168731] 7f20: 005c 0003 c0030070 fa20 0003 c0030ac4 [12034.176971] 7f40: 001e449b 001e449b c04316c0 0003 0003 c04316c0 [12034.185211] 7f60: 80027478 411fc082 001f c03f7f88 c00420d0 c00420dc [12034.193450] 7f80: 6053 001e449b 386d8e77 0fb39696 386d8e77 0f9551fb [12034.201660] 7fa0: c03fbd50 c03fbe20 c0430cdc c03fbd50 c0476b48 c022d7ac c03f6000 c0430cdc [12034.209899] 7fc0: c0029014 c03f9c10 80027478 c00324dc c045c9c0 c0008934 c000848c [12034.218139] 7fe0: c0029018 10c53c7d c0430df0 80008034 [12034.226379] [c01b70d0] (list_del+0xc/0x90) from [c021d928] (musb_g_giveback+0x28/0x130) [12034.234802] [c021d928] (musb_g_giveback+0x28/0x130) from [c021c230] (musb_g_ep0_irq+0x32c/0x910) [12034.244018] [c021c230] (musb_g_ep0_irq+0x32c/0x910) from [c021b388] (musb_interrupt+0x2fc/0x3d4) [12034.253204] [c021b388] (musb_interrupt+0x2fc/0x3d4) from [c021b4c0] (generic_interrupt+0x60/0x94) [12034.262512] [c021b4c0] (generic_interrupt+0x60/0x94) from [c0090b80] (handle_IRQ_event+0xa4/0x1e0) [12034.271881] [c0090b80] (handle_IRQ_event+0xa4/0x1e0) from [c0092c44] (handle_level_irq+0xc0/0x150) [12034.281250] [c0092c44] (handle_level_irq+0xc0/0x150) from [c0030070] (asm_do_IRQ+0x70/0x90) [12034.290008] [c0030070] (asm_do_IRQ+0x70/0x90) from [c0030ac4] (__irq_svc+0x44/0xa8) [12034.298065] Exception stack(0xc03f7f40 to 0xc03f7f88) [12034.303161] 7f40: 001e449b 001e449b c04316c0 0003 0003 c04316c0 [12034.311401] 7f60: 80027478 411fc082 001f c03f7f88 c00420d0 c00420dc [12034.319641] 7f80: 6053 [12034.323150] [c0030ac4] (__irq_svc+0x44/0xa8) from [c00420dc] (omap3_enter_idle+0x124/0x158) [12034.331939] [c00420dc] (omap3_enter_idle+0x124/0x158) from [c022d7ac] (cpuidle_idle_call+0xa4/0x180) [12034.341491] [c022d7ac] (cpuidle_idle_call+0xa4/0x180) from [c00324dc] (cpu_idle+0x48/0x98) [12034.350189] [c00324dc] (cpu_idle+0x48/0x98) from [c0008934] (start_kernel+0x268/0x2c8) [12034.358489] [c0008934] (start_kernel+0x268/0x2c8) from [80008034] (0x80008034) [12034.366119] Code: c03a882b e92d4013 e5903004 e1a04000 (e593c000) [12034.372406] ---[ end trace e93a9fc16bcba40b
Re: MUSB crash on OMAP3 board with second load of gadget
Hi, [12034.366119] Code: c03a882b e92d4013 e5903004 e1a04000 (e593c000) [12034.372406] ---[ end trace e93a9fc16bcba40b ]--- [12034.377075] Kernel panic - not syncing: Fatal exception in interrupt this is different from what I've seen. So it's a different problem. Can you get some debugging messages out of that ? enable debugging messages for musb on Kconfig and: echo 5 /sys/modules/musb_hdrc/parameters/debug then: echo 8 /proc/sysrq-trigger then reproduce the problem and get the messages that come before the oops. -- balbi I've executed the following script, and got the result: #!/bin/sh echo 5 /sys/module/musb_hdrc/parameters/debug echo 8 /proc/sysrq-trigger sleep 1 insmod /tmp/g_mass_storage.ko file=/etc/firmware/disk stall=0 sleep 15 rmmod g_mass_storage sleep 3 insmod /tmp/g_mass_storage.ko file=/etc/firmware/disk stall=0 value 15 can be increased if that time is not enough to get mass storage mounted. [ 559.954528] SysRq : Changing Loglevel [ 559.958251] Loglevel set to 8 [ 560.986572] usb_gadget_register_driver 1706: registering driver g_mass_storage [ 560.997863] g_mass_storage gadget: adding config #1 'Linux File-Backed Storage'/bf00698c [ 561.008605] device: 'lun0': device_add [ 561.013427] PM: Adding info for No Bus:lun0 [ 561.086700] lun0: open backing file: /etc/firmware/disk [ 561.093292] g_mass_storage gadget: Mass Storage Function, version: 2009/09/11 [ 561.101135] g_mass_storage gadget: Number of LUNs=1 [ 561.107025] lun0: LUN: removable file: /etc/firmware/disk [ 561.112548] g_mass_storage gadget: I/O thread pid: 1477 [ 561.118988] g_mass_storage gadget: adding 'Mass Storage Function'/c703ca40 to config 'Linux File-Backed Storc [ 561.130950] g_mass_storage gadget: cfg 1/bf00698c speeds: high full [ 561.137817] g_mass_storage gadget: interface 0 = Mass Storage Function/c703ca40 [ 561.146240] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11 [ 561.153808] g_mass_storage gadget: g_mass_storage ready [ 561.159393] musb_start 865: == devctl 98 [ 561.218963] musb_interrupt 1516: ** IRQ peripheral usb0001 tx rx [ 561.375976] musb_interrupt 1516: ** IRQ peripheral usb0004 tx rx [ 561.382720] musb_stage0_irq 385: == Power=f0, DevCtl=99, int_usb=0x4 [ 561.389190] musb_stage0_irq 761: BUS RESET as b_idle [ 561.394195] musb_g_reset 2000: == B-Device addr=0 driver 'g_mass_storage' [ 561.483642] musb_interrupt 1516: ** IRQ peripheral usb0008 tx0001 rx [ 561.490386] musb_g_ep0_irq 643: csr 0001, count 8, myaddr 0, ep0stage setup [ 561.497406] musb_read_fifo 202: RX ep0 fifo fa0ab020 count 8 buf c03f7e96 [ 561.504241] musb_read_setup 577: SETUP req80.06 v0100 i l64 [ 561.510192] musb_g_ep0_irq 825: handled 0, csr 0001, ep0stage in [ 561.516265] musb_g_ep0_queue 931: queue to ep0 (OUT/RX), length=18 [ 561.522491] musb_write_fifo 164: TX ep0 fifo fa0ab020 count 18 buf c72d1600 [ 561.529479] musb_g_giveback 142: ep0 done request c712d600, 18/18 [ 561.535766] musb_interrupt 1516: ** IRQ peripheral usb0008 tx0001 rx [ 561.542510] musb_g_ep0_irq 643: csr , count 0, myaddr 0, ep0stage out/status [ 561.549957] musb_interrupt 1516: ** IRQ peripheral usb000c tx rx [ 561.556701] musb_stage0_irq 385: == Power=f0, DevCtl=99, int_usb=0xc [ 561.563201] musb_stage0_irq 761: BUS RESET as b_peripheral [ 561.568725] musb_g_reset 2000: == B-Device addr=0 driver 'g_mass_storage' [ 561.575622] musb_g_disconnect 1944: devctl 99 [ 561.650573] musb_interrupt 1516: ** IRQ peripheral usb0008 tx0001 rx [ 561.657348] musb_g_ep0_irq 643: csr 0001, count 8, myaddr 0, ep0stage setup [ 561.664337] musb_read_fifo 202: RX ep0 fifo fa0ab020 count 8 buf c03f7e96 [ 561.671173] musb_read_setup 577: SETUP req00.05 v0028 i l0 [ 561.677062] musb_g_ep0_irq 825: handled 1, csr 0001, ep0stage in/status [ 561.683807] musb_interrupt 1516: ** IRQ peripheral usb0008 tx0001 rx [ 561.690551] musb_g_ep0_irq 643: csr , count 0, myaddr 0, ep0stage in/status [ 561.706573] musb_interrupt 1516: ** IRQ peripheral usb0008 tx0001 rx [ 561.713348] musb_g_ep0_irq 643: csr 0001, count 8, myaddr 40, ep0stage idle [ 561.720336] musb_read_fifo 202: RX ep0 fifo fa0ab020 count 8 buf c03f7e96 [ 561.727172] musb_read_setup 577: SETUP req80.06 v0100 i l18 [ 561.733154] musb_g_ep0_irq 825: handled 0, csr 0001, ep0stage in [ 561.739196] musb_g_ep0_queue 931: queue to ep0 (OUT/RX), length=18 [ 561.745422] musb_write_fifo 164: TX ep0 fifo fa0ab020 count 18 buf c72d1600 [ 561.752441] musb_g_giveback 142: ep0 done request c712d600, 18/18 [ 561.758728] musb_interrupt 1516: ** IRQ peripheral usb000d tx rx [ 561.765472] musb_stage0_irq 385: == Power=f0, DevCtl=99, int_usb=0xd [ 561.771942] musb_stage0_irq 761: BUS RESET as b_peripheral [ 561.777465] musb_g_reset 2000: == B-Device addr=0 driver 'g_mass_storage' [ 561.784393] musb_g_disconnect 1944: devctl 99 [ 561.862762] musb_interrupt 1516: ** IRQ
Re: [PATCH] mfd: twl4030: Driver for twl4030 madc module
Hi, all! On Wed, Nov 25, 2009 at 1:47 PM, Amit Kucheria amit.kuche...@verdurent.com wrote: From: Mikko Ylinen mikko.k.yli...@nokia.com This ADC allows monitoring of analog signals such as battery levels, temperatures, etc. Several people have contributed to this driver on the linux-omap list. Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com --- drivers/mfd/Kconfig | 21 ++ drivers/mfd/Makefile | 3 +- drivers/mfd/twl4030-madc.c | 548 ++ include/linux/i2c/twl4030-madc.h | 126 + 4 files changed, 697 insertions(+), 1 deletions(-) create mode 100644 drivers/mfd/twl4030-madc.c create mode 100644 include/linux/i2c/twl4030-madc.h We have just tried to adopt this driver to our custom OMAP3 board, but were unable to get any interrupts. Any ideas on what is missing? We've checked whole TRM and found nothing wrong yet :( Thanks a lot. S. -- 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 05/15] OMAP: DSS2: RFBI: convert to new kfifo API
Hi, all! Heh, maybe update the comments on this one before asking Linus to pull? :) Yes, perhaps that would be wise =). I hope somebody is able to test the patch, as I don't have hardware to test it. Is there some guidelines on porting old rfbi driver to dss2? Then I could test this one. Thanks a lot, S. -- 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: dadd2bb931a08a4b6b17f9e82d9bbe7bedebbc98 breaks omapfb (old non-dss2)
On Wed, Dec 16, 2009 at 2:21 PM, Tomi Valkeinen tomi.valkei...@nokia.com wrote: Hi, On Tue, 2009-12-15 at 17:01 +0100, ext Sergey Lapin wrote: On Tue, Dec 15, 2009 at 6:22 PM, Tomi Valkeinen tomi.valkei...@nokia.com wrote: Hi, On Tue, 2009-12-15 at 10:58 +0100, ext Sergey Lapin wrote: dadd2bb931a08a4b6b17f9e82d9bbe7bedebbc98 OMAP: OMAPFB: add omapdss device The upcoming new display subsystem driver is divided to two devices, omapdss and omapfb, of which omapdss handles the actual hardware. This patch adds a dummy omapdss platform device for the current omapfb driver, which is then used to get the clocks. This will make it possible for the current and the new display drivers to co-exist. Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com Acked-by: Tony Lindgren t...@atomide.com breaks old omapfb. I didn't look at this further, but I quickly tested with OMAP3 SDP board, reverting the patch that makes SDP use DSS2, and it seems to work fine with the old omapfb. rfbi.c was still using omapfb device to get the clocks. Can you try this patch? From 33b78006fb0387e21d5f780338d821621ecad929 Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen tomi.valkei...@nokia.com Date: Wed, 16 Dec 2009 13:18:07 +0200 Subject: [PATCH] OMAP: OMAPFB: fix clk_get for RFBI omapfb platform device was still used to get clocks inside rfbi.c If you add #include linux/platform_device.h to this patch, then problem is fixed. Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com Tested-by: Sergey Lapin sla...@ossfans.org --- drivers/video/omap/dispc.c |2 +- drivers/video/omap/omapfb.h |2 ++ drivers/video/omap/rfbi.c |4 ++-- 3 files changed, 5 insertions(+), 3 deletions(-) -- 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
dadd2bb931a08a4b6b17f9e82d9bbe7bedebbc98 breaks omapfb (old non-dss2)
dadd2bb931a08a4b6b17f9e82d9bbe7bedebbc98 OMAP: OMAPFB: add omapdss device The upcoming new display subsystem driver is divided to two devices, omapdss and omapfb, of which omapdss handles the actual hardware. This patch adds a dummy omapdss platform device for the current omapfb driver, which is then used to get the clocks. This will make it possible for the current and the new display drivers to co-exist. Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com Acked-by: Tony Lindgren t...@atomide.com breaks old omapfb. [ 17.234466] Registering platform device 'omapdss'. Parent at platform [ 17.237548] device: 'omapdss': device_add [ 17.241180] bus: 'platform': add device omapdss [ 17.244964] PM: Adding info for platform:omapdss [ 17.250244] omapfb: DISPC version 3.0 initialized [ 17.253326] omapfb omapfb: can't get ick [ 17.257324] PM: Removing info for platform:omapdss [ 17.261291] bus: 'platform': remove device omapdss [ 17.265411] [ cut here ] [ 17.271545] WARNING: at drivers/base/core.c:131 device_release+0x68/0x7c() [ 17.279510] Device 'omapdss' does not have a release() function, it is broken and must be fixed. [ 17.281433] Modules linked in: [ 17.290008] [c003a9dc] (unwind_backtrace+0x0/0xdc) from [c0062330] (warn_slowpath_common+0x48/0x60) [ 17.298583] [c0062330] (warn_slowpath_common+0x48/0x60) from [c0062380] (warn_slowpath_fmt+0x24/0x30) [ 17.306610] [c0062380] (warn_slowpath_fmt+0x24/0x30) from [c01fcd2c] (device_release+0x68/0x7c) [ 17.314453] [c01fcd2c] (device_release+0x68/0x7c) from [c01b23cc] (kobject_release+0x5c/0x70) [ 17.321746] [c01b23cc] (kobject_release+0x5c/0x70) from [c01b3208] (kref_put+0x5c/0x6c) [ 17.328887] [c01b3208] (kref_put+0x5c/0x6c) from [c01d9a78] (hx8340_init+0x89c/0x8d8) [ 17.336822] [c01d9a78] (hx8340_init+0x89c/0x8d8) from [c01d5018] (omapfb_do_probe+0x38c/0x970) [ 17.345123] [c01d5018] (omapfb_do_probe+0x38c/0x970) from [c01d9af8] (gnome5_panel_probe+0xc/0x18) [ 17.353515] [c01d9af8] (gnome5_panel_probe+0xc/0x18) from [c0201014] (platform_drv_probe+0x18/0x1c) [ 17.362243] [c0201014] (platform_drv_probe+0x18/0x1c) from [c01fff60] (driver_probe_device+0x100/0x1e8) [ 17.370727] [c01fff60] (driver_probe_device+0x100/0x1e8) from [c02000a8] (__driver_attach+0x60/0x84) [ 17.378753] [c02000a8] (__driver_attach+0x60/0x84) from [c01ff658] (bus_for_each_dev+0x44/0x74) [ 17.386871] [c01ff658] (bus_for_each_dev+0x44/0x74) from [c01fef80] (bus_add_driver+0x140/0x2d0) [ 17.394989] [c01fef80] (bus_add_driver+0x140/0x2d0) from [c020039c] (driver_register+0xa8/0x130) [ 17.403106] [c020039c] (driver_register+0xa8/0x130) from [c0034364] (do_one_initcall+0x5c/0x1b4) [ 17.410858] [c0034364] (do_one_initcall+0x5c/0x1b4) from [c0008588] (kernel_init+0xa0/0x124) [ 17.418640] [c0008588] (kernel_init+0xa0/0x124) from [c0035f80] (kernel_thread_exit+0x0/0x8) [ 17.422363] ---[ end trace da227214a82491b7 ]--- [ 17.427520] omapfb omapfb: controller initialization failed (-2) [ 17.433715] driver: 'gnome5_lcd': driver_bound: bound to device 'gnome5_lcd' [ 17.440948] bus: 'platform': really_probe: bound device gnome5_lcd to driver gnome5_lcd Any ideas? Also - is there some guidelines on porting old RFBI-based driver to DSS2? Thanks a lot, S. -- 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: dadd2bb931a08a4b6b17f9e82d9bbe7bedebbc98 breaks omapfb (old non-dss2)
Also - is there some guidelines on porting old RFBI-based driver to DSS2? No, and currently the DSS2 RFBI support may not work. I don't have hardware to test it, and the DSS driver has changed around it. Can anyone confirm that the RFBI support works, and does anyone have public RFBI drivers? Well, in tree, drivers/video/omap/hwa742.c is driver for RFBI-based display driver with hwa742 controller. I think porting Nokia 770 to DSS2 could be nice example... Actually, old RFBI driver is very limited comparing to OMAP3 features, and supports only 16bit color mode (hardcoded). I'd like to see OMAP3 features there, some of them are trivial to add, I have some patches for that, but they are simply bad approach because they are based on old driver, hardcode values, use hackish approaches. So, I'd like to see the right way, so I could move farther with them and toss that messy junk. Thanks a lot, S. -- 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
PM branch
Hi, all! I have some weird behavior with old RFBI (old, non-DSS2) driver on PM branch (actually upgraded from 2.6.28). I use PM branch as my code base. I'd like to try to disable PM stuff to check if that triggers it (RFBI interrupt stop coming accidentally after some time, and whole video hang). But when I change PM from SRF to PM I can't make device to work, console stops recieving characters, and video stops working at all. What configuration should I have to make my device work without PM? Thanks a lot, S. -- 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
PM branch
Hi, all! When new PM branch will be available, is there any plans? I just want to use both DSS2 and PM, but can't make it work by plain merging of master and pm branches :( Thanks a lot, S. -- 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
commit f4633d810405d4df8b3ea98f617856d149af636a breaks non-DSS2 pxafb support
Hi, all! I have custom external framebuffer driver based on drivers/video/omap/hwa742.c It is broken by commit f4633d810405d4df8b3ea98f617856d149af636a. if I revert it, it starts working. What is needed to be done to fix driver to make it work with non-DSS2 omapdss device? S. -- 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] PM: Prevent direct cpufreq scaling during initialization
On Thu, Dec 3, 2009 at 9:29 AM, Dasgupta, Romit ro...@ti.com wrote: Signed-off-by: Romit Dasgupta ro...@ti.com --- diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu- omap.c index 449b6b6..f94df20 100644 --- a/arch/arm/plat-omap/cpu-omap.c +++ b/arch/arm/plat-omap/cpu-omap.c @@ -149,8 +149,6 @@ static int __init omap_cpu_init(struct cpufreq_policy *policy) VERY_HI_RATE) / 1000; } - clk_set_rate(mpu_clk, policy-cpuinfo.max_freq * 1000); - policy-min = policy-cpuinfo.min_freq; policy-max = policy-cpuinfo.max_freq; policy-cur = omap_getspeed(0); This patch leads to hang with current PM branch, SRF and CPU IDLE enabled on OMAP3525 rev C. Verified this to work on Zoom2 + SRF + CPUidle. Can you give some debug info if possible? Well, that looks like false alarm - I tried clean tree without local patches, and it seems to work. However, without this line removed, my system boots faster. Is it possible to limit initial speed for unstable setups, but to boot as fast as possible? Thanks a lot, S. -- 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: SR1: VDD autocomp is not active
Hi, all! It seems discussion went off-list somehow, so I won't delete some quoting. On Wed, Dec 2, 2009 at 2:38 PM, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: Sergey Lapin [mailto:slapi...@gmail.com] Sent: Wednesday, December 02, 2009 1:54 AM To: Premi, Sanjeev Subject: Re: SR1: VDD autocomp is not active I did notice an earlier mail where you mentioned about using an older kernel version. have to back-ported patches specific to silicon identification on this kernel/ I use PM branch of linux-omap git. I just need to make my patches less disgusting by properly porting these. Actually now I think I could do this work even without appropriate tree, since amount of patches is not that big and API is not too different. These patches are not required to make board basically run. It appears that efuse data required for SmartReflex to work may not be available on this silicon... leading to these messages. Right now, I am away from source code, will be able to verify in the morning. Thanks, looking forward for your reply. You should try this with an ES3.1 silicon. If sr_enable() fails, we might see this issue. It seems I only have ES2.1 silicon, so what should I do - disable SR functionality at all - somehow set values the other way? It seems SR is possible on this silicon, only efuse data are absent, so is there a way I could somehow fake these (with some known working values), so the stuff works? Thanks a lot, S. S. -- 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: SR1: VDD autocomp is not active
On Wed, Dec 2, 2009 at 3:19 PM, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: Sergey Lapin [mailto:slapi...@gmail.com] Sent: Wednesday, December 02, 2009 5:35 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: SR1: VDD autocomp is not active Hi, all! It seems discussion went off-list somehow, so I won't delete some quoting. On Wed, Dec 2, 2009 at 2:38 PM, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: Sergey Lapin [mailto:slapi...@gmail.com] Sent: Wednesday, December 02, 2009 1:54 AM To: Premi, Sanjeev Subject: Re: SR1: VDD autocomp is not active I did notice an earlier mail where you mentioned about using an older kernel version. have to back-ported patches specific to silicon identification on this kernel/ I use PM branch of linux-omap git. I just need to make my patches less disgusting by properly porting these. Actually now I think I could do this work even without appropriate tree, since amount of patches is not that big and API is not too different. These patches are not required to make board basically run. It appears that efuse data required for SmartReflex to work may not be available on this silicon... leading to these messages. Right now, I am away from source code, will be able to verify in the morning. Thanks, looking forward for your reply. You should try this with an ES3.1 silicon. If sr_enable() fails, we might see this issue. It seems I only have ES2.1 silicon, so what should I do - disable SR functionality at all [sp] Yes. It will be a good starting point. - somehow set values the other way? [sp] It will be difficult for you to ascertain these values. It seems SR is possible on this silicon, only efuse data are absent, so is there a way I could somehow fake these (with some known working values), so the stuff works? [sp] The code will allow you to do so; but without right values kernel execution can go haywire. Is it possible somehow to identify right silicon revision before ordering? I mean by part number or something? Also, is there some safe numbers somebody knows about, or is there some way of generating them? S. -- 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: SR1: VDD autocomp is not active
[sp] The code will allow you to do so; but without right values kernel execution can go haywire. Is it possible somehow to identify right silicon revision before ordering? I mean by part number or something? Sorry for my ignorance, I've found answer on first question (answer is to read errata properly). Also, is there some safe numbers somebody knows about, or is there some way of generating them? I still persist with this question, though. -- 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: SR1: VDD autocomp is not active
On Wed, Dec 2, 2009 at 4:33 PM, Sergey Lapin slapi...@gmail.com wrote: [sp] The code will allow you to do so; but without right values kernel execution can go haywire. Is it possible somehow to identify right silicon revision before ordering? I mean by part number or something? Sorry for my ignorance, I've found answer on first question (answer is to read errata properly). Also, is there some safe numbers somebody knows about, or is there some way of generating them? I still persist with this question, though. Resume: kernel seems to hang wit SRF disabled and PM enabled. As I have advantage of saving lots of power with PM. disabling SRF seems not to be an option. So it either have to be left as is or numbers should be provided (possibly for even better tasty power saving!) Thanks a lot for your help, S. -- 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] PM: Prevent direct cpufreq scaling during initialization
On Wed, Dec 2, 2009 at 1:12 PM, Romit Dasgupta ro...@ti.com wrote: It is seen that the OMAP specific cpufreq initialization code tries to scale the MPU frequency to the highest possible without taking care of the voltage level. On power on reset the power IC does not provide the necessary voltage for the highest available MPU frequency (that would satisfy all Si families). This potentially is an window of opportunity for things to go wrong. Signed-off-by: Romit Dasgupta ro...@ti.com --- diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c index 449b6b6..f94df20 100644 --- a/arch/arm/plat-omap/cpu-omap.c +++ b/arch/arm/plat-omap/cpu-omap.c @@ -149,8 +149,6 @@ static int __init omap_cpu_init(struct cpufreq_policy *policy) VERY_HI_RATE) / 1000; } - clk_set_rate(mpu_clk, policy-cpuinfo.max_freq * 1000); - policy-min = policy-cpuinfo.min_freq; policy-max = policy-cpuinfo.max_freq; policy-cur = omap_getspeed(0); This patch leads to hang with current PM branch, SRF and CPU IDLE enabled on OMAP3525 rev C. -- 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
linux-2.6.28-rc6-omap1
Hi, all! Is there some git repository with kernel version 2.6.28-rc6-omap1? As I understand it is older OMAP3 kernel Nokia n900 and Beagle were based on. I just need it as merge base to move some work, based on 2.6.28-rc6-omap1 to mainline in maintainable way, so I need it to have proper history. Any links? Thanks a lot, S. -- 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: linux-2.6.28-rc6-omap1
On Tue, Dec 1, 2009 at 2:47 PM, Gadiyar, Anand gadi...@ti.com wrote: v2.6.28-omap1 exists as a tag on Tony's linux-omap tree [1]. Actually I need 2.6.28-rc6-omap1, because in v2.6.28 clock subsystem was slightly changed and lots of little somethings are different, so many that it gets out of control :( S. -- 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
SR1: VDD autocomp is not active
Hi, all! on my OMAP3525-based custom board I get SR1: VDD autocomp is not active and SR2: VDD autocomp is not active quite frequently with PM branch. What that means, and how to fix it? Thanks a lot, S. -- 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: SR1: VDD autocomp is not active
On Tue, Dec 1, 2009 at 7:08 PM, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Sergey Lapin Sent: Tuesday, December 01, 2009 5:24 PM To: linux-omap@vger.kernel.org Subject: SR1: VDD autocomp is not active Hi, all! on my OMAP3525-based custom board I get SR1: VDD autocomp is not active and SR2: VDD autocomp is not active quite frequently with PM branch. What that means, and how to fix it? Do you see them while trying to set the sr_vdd[1|2]_autocomp? OR During normal execution? During normal execution. What is the silicon version reported when Linux kernel boot up? OMAP3525 ES2.1 (l2cache iva neon isp ) S. -- 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: enabling CPU idle leads to panic
Sorry, I forgot to reply to list with this email.
On Wed, Nov 25, 2009 at 8:31 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Sergey Lapin slapi...@gmail.com writes:
On Tue, Nov 24, 2009 at 11:21 PM, Premi, Sanjeev pr...@ti.com wrote:
From: Kevin Hilman [khil...@deeprootsystems.com]
Sent: Tuesday, November 24, 2009 11:57 PM
To: Sergey Lapin; Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: OMAP3: enabling CPU idle leads to panic
Sergey Lapin slapi...@gmail.com writes:
I use PM branch merged with linux-omap branch.
Not sure what this means. PM branch is already based at linux-omap
master branch. You'll need to be more specific, ideally with commit
IDs.
I do git branch tmp origin/master
git checkout -f tmp
git merge origin/pm
The pm branch is already based on l-o master, but perhaps not the very
latest. Instead of the above can you just do
git branch tmp origin/pm
git checkout -f tmp
git merge origin/mybranch
It might if you base your 'mybranch' at the same merge point that the
pm branch is based at. You can find the merge point using:
git merge-base origin/master origin/pm
Well, thanks for advice, I changed my merge script accordingly, but
nothing changed. I still get panic.
[ 21.591064] Unable to handle kernel NULL pointer dereference at
virtual address 0020
[ 21.599212] pgd = c0004000
[ 21.601928] [0020] *pgd=
[ 21.605529] Internal error: Oops: 5 [#1] PREEMPT
[ 21.610168] last sysfs file:
[ 21.613159] Modules linked in:
[ 21.616241] CPU: 0Not tainted (2.6.32-rc8-07040-g4594b2e #117)
[ 21.622558] PC is at pwrdm_for_each_clkdm+0x34/0x88
[ 21.627441] LR is at pwrdm_for_each_clkdm+0x24/0x88
[ 21.632354] pc : [c003b5c0]lr : [c003b5b0]psr: 60d3
[ 21.632385] sp : c03f3f68 ip : fa004800 fp :
[ 21.643920] r10: c003e840 r9 : 411fc082 r8 :
[ 21.649169] r7 : a0d3 r6 : r5 : 0004 r4 : 0001
[ 21.655731] r3 : 0002 r2 : c03f2000 r1 : 0001 r0 :
[ 21.662292] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM
Segment kernel
[ 21.669830] Control: 10c5387d Table: 80004019 DAC: 0017
[ 21.675598] Process swapper (pid: 0, stack limit = 0xc03f22e8)
[ 21.681457] Stack: (0xc03f3f68 to 0xc03f4000)
[ 21.685852] 3f60: c042e4bc 0003 0003
c042e4bc 800263f4 411fc082
[ 21.694091] 3f80: 001f c003e790 c022f3b8 000253d2
0005 0ee4d5e4
[ 21.702301] 3fa0: c03f8640 c03f8650 c042dadc c03f8640 c0474d4c
c022e01c c03f2000 c042dadc
[ 21.710540] 3fc0: c0027e14 c03f5bd0 800263f4 c002f49c c0459fe4
c0008914 c0008478
[ 21.718780] 3fe0: c0027e18 10c53c7d c042dbf0
80008034
[ 21.727020] [c003b5c0] (pwrdm_for_each_clkdm+0x34/0x88) from
[c003e790] (omap3_enter_idle+0xc0/0x15c)
[ 21.736663] [c003e790] (omap3_enter_idle+0xc0/0x15c) from
[c022e01c] (cpuidle_idle_call+0xa4/0x180)
[ 21.746124] [c022e01c] (cpuidle_idle_call+0xa4/0x180) from
[c002f49c] (cpu_idle+0x48/0x98)
[ 21.754791] [c002f49c] (cpu_idle+0x48/0x98) from [c0008914]
(start_kernel+0x250/0x2a8)
[ 21.763122] [c0008914] (start_kernel+0x250/0x2a8) from
[80008034] (0x80008034)
[ 21.770751] Code: e3a06000 e1a05008 e1a04006 ea02 (e595101c)
[ 21.777008] ---[ end trace 2d4ee201e3556cfe ]---
[ 21.781707] Kernel panic - not syncing: Attempted to kill the idle task!
If I add the following patch:
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 1cfa5a6..6a12e53 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -346,6 +346,7 @@ int __init omap3_idle_init(void)
mpu_pd = pwrdm_lookup(mpu_pwrdm);
core_pd = pwrdm_lookup(core_pwrdm);
+ BUG_ON(!core_pd);
omap_init_power_states();
cpuidle_register_driver(omap3_idle_driver);
kernel dies right on BUG_ON.
Also, I patched pwrdm_lookup to print all perdms if returning NULL,
ant there was no core_pwrdm there :(
Is core_pwrdm used only with idle? When I disable cpu idle,
I have no panics.
Update: I continued my investigation.
I added the following patch to kernel:
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index b6990e3..35a5bd0 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -185,7 +185,15 @@ void pwrdm_init(struct powerdomain **pwrdm_list)
if (pwrdm_list) {
for (p = pwrdm_list; *p; p++) {
- pwrdm_register(*p);
+#ifdef CONFIG_DEBUG_LL
+ int i;
+ extern void printascii(char *);
+ printascii((*p)-name);
+ printascii(\n);
+#endif
+ i = pwrdm_register(*p);
+ if (i 0)
+ printascii(Damn\n);
_pwrdm_setup(*p
Re: OMAP3: enabling CPU idle leads to panic
Hi, all! I've found the particular reason for my troubles with CPU idle, since there's no core_pwrdm defined for OMAP3525 CPU. How could I create soch structure or is there anybody having this handy? 3523 is basically 3530 without 3D graphics. -- 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: enabling CPU idle leads to panic
On Fri, Nov 27, 2009 at 2:02 PM, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: Sergey Lapin [mailto:slapi...@gmail.com] Sent: Friday, November 27, 2009 4:19 PM To: Kevin Hilman Cc: Premi, Sanjeev; linux-omap@vger.kernel.org Subject: Re: OMAP3: enabling CPU idle leads to panic Hi, all! I've found the particular reason for my troubles with CPU idle, since there's no core_pwrdm defined for OMAP3525 CPU. How could I create soch structure or is there anybody having this handy? 3523 is basically 3530 without 3D graphics. The core_pwdm is defined in powerdomains34xx.h based on CONFIG_ARCH_OMAP34XX. This should be true for OMAP3525 as well. Alas, that's not because omap_chip_is() function fails on these structures. -- 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: enabling CPU idle leads to panic
Alas, that's not because omap_chip_is() function fails on these structures. I mean during registration of power domains. -- 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: enabling CPU idle leads to panic
On Fri, Nov 27, 2009 at 2:36 PM, Sergey Lapin slapi...@gmail.com wrote:
Alas, that's not because omap_chip_is() function fails
on these structures.
I mean during registration of power domains.
int pwrdm_register(struct powerdomain *pwrdm)
{
unsigned long flags;
int ret = -EINVAL;
if (!pwrdm)
return -EINVAL;
if (!omap_chip_is(pwrdm-omap_chip))
return -EINVAL;
returns -EINVAL for pwrdm_core (both of them), so I get panic later.
Since OMAP2525 vs 3515 were messed-up, I think there could be more
problems there.
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 2e17890..8b15789 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -393,11 +393,11 @@ IS_OMAP_TYPE(3517, 0x3517)
(!omap3_has_iva())\
(!omap3_has_sgx()))
# define cpu_is_omap3515() (cpu_is_omap3430()\
- (omap3_has_iva()) \
- (!omap3_has_sgx()))
+ (!omap3_has_iva())\
+ (omap3_has_sgx()))
# define cpu_is_omap3525() (cpu_is_omap3430()\
- (omap3_has_sgx()) \
- (!omap3_has_iva()))
+ (!omap3_has_sgx())\
+ (omap3_has_iva()))
# define cpu_is_omap3530() (cpu_is_omap3430())
# define cpu_is_omap3505() is_omap3505()
# define cpu_is_omap3517() is_omap3517()
since OMAP3525 has iva but misses sgx, and vice versa 3515 has sgx but
has no iva.
I missed this piece before, but just accidentally found it now. I
don't know if these are
related, but this doesn't fix my problem with core_pwrdm.
S.
--
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: enabling CPU idle leads to panic
-Original Message-
From: Sergey Lapin [mailto:slapi...@gmail.com]
Sent: Friday, November 27, 2009 5:33 PM
To: Premi, Sanjeev
Cc: Kevin Hilman; linux-omap@vger.kernel.org
Subject: Re: OMAP3: enabling CPU idle leads to panic
On Fri, Nov 27, 2009 at 2:36 PM, Sergey Lapin
slapi...@gmail.com wrote:
Alas, that's not because omap_chip_is() function fails
on these structures.
I mean during registration of power domains.
int pwrdm_register(struct powerdomain *pwrdm)
{
unsigned long flags;
int ret = -EINVAL;
if (!pwrdm)
return -EINVAL;
if (!omap_chip_is(pwrdm-omap_chip))
return -EINVAL;
returns -EINVAL for pwrdm_core (both of them), so I get panic later.
Since OMAP2525 vs 3515 were messed-up, I think there could be more
problems there.
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 2e17890..8b15789 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -393,11 +393,11 @@ IS_OMAP_TYPE(3517, 0x3517)
(!omap3_has_iva())\
(!omap3_has_sgx()))
# define cpu_is_omap3515() (cpu_is_omap3430()
\
-
(omap3_has_iva()) \
- (!omap3_has_sgx()))
+
(!omap3_has_iva())\
+ (omap3_has_sgx()))
# define cpu_is_omap3525() (cpu_is_omap3430()
\
-
(omap3_has_sgx()) \
- (!omap3_has_iva()))
+
(!omap3_has_sgx())\
+ (omap3_has_iva()))
# define cpu_is_omap3530() (cpu_is_omap3430())
# define cpu_is_omap3505() is_omap3505()
# define cpu_is_omap3517() is_omap3517()
since OMAP3525 has iva but misses sgx, and vice versa 3515 has sgx but
has no iva.
I missed this piece before, but just accidentally found it now. I
don't know if these are
related, but this doesn't fix my problem with core_pwrdm.
S.
I feel, the problem could be due to this snippet below.
omap_rev() does a compare against omap_revision not just
the revision bits.
Had submitted a patch earlier; will need some time to
find it.
} else if (cpu_is_omap343x()) {
omap_chip.oc = CHIP_IS_OMAP3430;
if (omap_rev() == OMAP3430_REV_ES1_0)
omap_chip.oc |= CHIP_IS_OMAP3430ES1;
else if (omap_rev() = OMAP3430_REV_ES2_0
omap_rev() = OMAP3430_REV_ES2_1)
omap_chip.oc |= CHIP_IS_OMAP3430ES2;
else if (omap_rev() == OMAP3430_REV_ES3_0)
omap_chip.oc |= CHIP_IS_OMAP3430ES3_0;
else if (omap_rev() == OMAP3430_REV_ES3_1)
omap_chip.oc |= CHIP_IS_OMAP3430ES3_1;
} else {
In meantime, can you try setting the following (explicitly)
to the code above:
else if (omap_rev() == OMAP3430_REV_ES3_1)
omap_chip.oc |= CHIP_IS_OMAP3430ES3_1;
+ else
+ omap_chip.oc |= CHIP_IS_OMAP3430ES3_1
~sanjeev
It is fixed, no more panics, thanks a lot!
--
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: enabling CPU idle leads to panic
On Tue, Nov 24, 2009 at 11:21 PM, Premi, Sanjeev pr...@ti.com wrote: From: Kevin Hilman [khil...@deeprootsystems.com] Sent: Tuesday, November 24, 2009 11:57 PM To: Sergey Lapin; Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: OMAP3: enabling CPU idle leads to panic Sergey Lapin slapi...@gmail.com writes: I use PM branch merged with linux-omap branch. Not sure what this means. PM branch is already based at linux-omap master branch. You'll need to be more specific, ideally with commit IDs. I do git branch tmp origin/master git checkout -f tmp git merge origin/pm git merge origin/mybranch git log origin/pm^..origin/pm commit 596f2d2c8153fe24de5c3b6ad78658ce9fff7f28 Author: Kevin Hilman khil...@deeprootsystems.com Date: Wed Jun 17 14:42:22 2009 -0700 OMAP3: PM: default defconfig for PM kernel testing Supports 3430SDP, OMAP3EVM and 3630SDP by default. Also supports, Beagle, Overo, Zoom[23] and RX51 simply by changing System Type--TI OMAP implementations--Low-level debug console UART from UART1 to UART3. Signed-off-by: Kevin Hilman khil...@ti.deeprootsystems.com [sp] I will also need the last commit from pm branch - if not the id; the commit header to start. See above [snip]--[snip] addr2line -e vmlinux c003b5c0 /home/slapin/linux-omap-my-2.6.git/arch/arm/mach-omap2/powerdomain.c:452 It is in function int pwrdm_for_each_clkdm(), where pwrdm is NULL. farther investigations found that core_pwrdm is defined only for 24xx, but I use 3525, and it is being searched. [sp] I am a little confused here. core_pwrdm is defined for 34xx as well. Other than sgx, there isn't any difference between 3530 and 3525. Yes, I see that in source, but that function returns NULL for unknown reason. How could I debug it farther? See the definition at: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blob;f=arch/arm/mach-omap2/powerdomains34xx.h;hb=867d320b6c30d2478358eafeca0e1a6c60cf06c3#l203 Yes, there is. This is where variable allocated. If I add BUG_ON(!core_pd), it crashes here. arch/arm/mach-omap2/cpuidle34xx.c:348:core_pd = pwrdm_lookup(core_pwrdm); Otherwise it crashes the above way. Any ideas on how to fix this? [sp] Have you hand-picked the commits from pm branch and applied against master? See above. I use git merge on fresh branch based on linux-omap master. Thanks a lot, S. -- 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
OMAP3: enabling CPU idle leads to panic
Hi, all! I use PM branch merged with linux-omap branch. A board is custom, so I can't bisect this problem (and I don't know latest working revision). It seems that's because missing clock domain somewhere, [16515.695617] Unable to handle kernel NULL pointer dereference at virtual address 0020 [16515.703735] pgd = c0004000 [16515.706481] [0020] *pgd= [16515.710083] Internal error: Oops: 5 [#1] PREEMPT [16515.714721] last sysfs file: [16515.717712] Modules linked in: [16515.720794] CPU: 0Not tainted (2.6.32-rc8-07113-g318afc6 #110) [16515.727111] PC is at pwrdm_for_each_clkdm+0x34/0x88 [16515.731994] LR is at pwrdm_for_each_clkdm+0x24/0x88 [16515.736907] pc : [c003b5c0]lr : [c003b5b0]psr: 60d3 [16515.736938] sp : c03f3f68 ip : fa004800 fp : [16515.748474] r10: c003e81c r9 : 411fc082 r8 : [16515.753723] r7 : a0d3 r6 : r5 : 0004 r4 : 0001 [16515.760284] r3 : 0002 r2 : c03f2000 r1 : 0001 r0 : [16515.766845] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [16515.774383] Control: 10c5387d Table: 80004019 DAC: 0017 [16515.780151] Process swapper (pid: 0, stack limit = 0xc03f22e8) [16515.786010] Stack: (0xc03f3f68 to 0xc03f4000) [16515.790405] 3f60: c042e4bc 0003 0003 c042e4bc 80026398 411fc082 [16515.798645] 3f80: 001f c003e76c c022f284 00271d5a 0005 0ec00c5c [16515.806854] 3fa0: c03f8640 c03f8710 c042dadc c03f8640 c0474d0c c022dee8 c03f2000 c042dadc [16515.815093] 3fc0: c0027e14 c03f5bd0 80026398 c002f49c c0459fa4 c0008914 c0008478 [16515.82] 3fe0: c0027e18 10c53c7d c042dbf0 80008034 [16515.831573] [c003b5c0] (pwrdm_for_each_clkdm+0x34/0x88) from [c003e76c] (omap3_enter_idle+0xc0/0x15c) [16515.841217] [c003e76c] (omap3_enter_idle+0xc0/0x15c) from [c022dee8] (cpuidle_idle_call+0xa4/0x180) [16515.850677] [c022dee8] (cpuidle_idle_call+0xa4/0x180) from [c002f49c] (cpu_idle+0x48/0x98) [16515.859344] [c002f49c] (cpu_idle+0x48/0x98) from [c0008914] (start_kernel+0x250/0x2a8) [16515.867675] [c0008914] (start_kernel+0x250/0x2a8) from [80008034] (0x80008034) [16515.875274] Code: e3a06000 e1a05008 e1a04006 ea02 (e595101c) [16515.881530] ---[ end trace f0a89c74ea639f01 ]--- [16515.886230] Kernel panic - not syncing: Attempted to kill the idle task! addr2line -e vmlinux c003b5c0 /home/slapin/linux-omap-my-2.6.git/arch/arm/mach-omap2/powerdomain.c:452 It is in function int pwrdm_for_each_clkdm(), where pwrdm is NULL. farther investigations found that core_pwrdm is defined only for 24xx, but I use 3525, and it is being searched. This is where variable allocated. If I add BUG_ON(!core_pd), it crashes here. arch/arm/mach-omap2/cpuidle34xx.c:348: core_pd = pwrdm_lookup(core_pwrdm); Otherwise it crashes the above way. Any ideas on how to fix this? S. -- 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
McBSP troubles
Hi, all! I have problems making any sound with current linux-omap master. Driver below worked ok with 2.6.28-omap1, and debugging output of mcbsp driver is the following: gnome5:~# aplay -c 2 -f S16_LE /dev/urandom [ 4593.480072] !!!omap_mcbsp_dai_startup() [ 4593.484283] !!!omap2_mcbsp_request() [ 4593.488159] disabling LINE_OUT [ 4593.491302] disabling DMIC [ 4593.494018] Disabling ASSYM pin Playing raw data '/dev/urandom' : Signed 16 bit Little Endian, Rate 8000 Hz, Stereo [ 4593.522064] !!!omap_mcbsp_dai_set_dai_fmt() [ 4593.615905] !!!omap_mcbsp_dai_hw_params() [ 4593.620086] omap-mcbsp omap-mcbsp.2: Configuring McBSP2 phys_base: 0x49022000 [ 4593.678375] gnome5_jack_event [ 4593.726623] !!!omap_mcbsp_set_threshold() [ 4593.730651] !!!omap_mcbsp_dai_trigger() [ 4593.735015] omap-mcbsp omap-mcbsp.2: McBSP2 regs [ 4593.740539] omap-mcbsp omap-mcbsp.2: DRR2: 0xd907da5a [ 4593.745697] omap-mcbsp omap-mcbsp.2: DRR1: 0x [ 4593.750518] omap-mcbsp omap-mcbsp.2: DXR2: 0x [ 4593.755340] omap-mcbsp omap-mcbsp.2: DXR1: 0x [ 4593.760162] omap-mcbsp omap-mcbsp.2: SPCR2: 0x02f5 [ 4593.764984] omap-mcbsp omap-mcbsp.2: SPCR1: 0x0030 [ 4593.769805] omap-mcbsp omap-mcbsp.2: RCR2: 0x8041 [ 4593.774627] omap-mcbsp omap-mcbsp.2: RCR1: 0x0040 [ 4593.779449] omap-mcbsp omap-mcbsp.2: XCR2: 0x8041 [ 4593.784271] omap-mcbsp omap-mcbsp.2: XCR1: 0x0040 [ 4593.789093] omap-mcbsp omap-mcbsp.2: SRGR2: 0x001f [ 4593.793884] omap-mcbsp omap-mcbsp.2: SRGR1: 0x0f00 [ 4593.798706] omap-mcbsp omap-mcbsp.2: PCR0: 0x000f [ 4593.803527] omap-mcbsp omap-mcbsp.2: *** [ 4603.811187] ALSA sound/core/pcm_lib.c:1708: playback write error (DMA or IRQ trouble?) [ 4614.818878] ALSA sound/core/pcm_lib.c:1708: playback write error (DMA or IRQ trouble?) aplay: pcm_write:1442: write error: And no sound at all. Codec is supplied properly with clock, and programmed normally, so I think that's McBSP trouble, but I might be wrong. I use tlv320aic32 as codec. I use slightly modified sound/soc/omap/n810.c with clock names changed for OMAP3. Clock is supplied properly. -- 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: OMAP3515 vs 3525 inversion
On Tue, Nov 17, 2009 at 4:39 PM, Premi, Sanjeev pr...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Sergey Lapin
Sent: Monday, November 16, 2009 3:59 PM
To: linux-omap@vger.kernel.org
Subject: OMAP3515 vs 3525 inversion
Hi, all!
I think I found a bug in processor detection code.
as I see,
+ /* OMAP3430 and OMAP3530 are assumed to be same.
+ *
+ * OMAP3525, OMAP3515 and OMAP3503 can be detected only based
+ * on available features. Upon detection, update the CPU id
+ * and CPU class bits.
+ */
+ if (omap3_has_iva() omap3_has_sgx()) {
+ strcpy(cpu_name, 3430/3530);
+ }
+ else if (omap3_has_sgx()) {
+ omap_revision = OMAP3525_REV (rev);
+ strcpy(cpu_name, 3525);
+ }
+ else if (omap3_has_iva()) {
+ omap_revision = OMAP3515_REV (rev);
+ strcpy(cpu_name, 3515);
+ }
+ else {
+ omap_revision = OMAP3503_REV (rev);
+ strcpy(cpu_name, 3503);
+ }
But, actually, 3515 has no DSP, but has PowerVR,
and 3525 has no PowerVR but has DSP. In-tree code inverses
this detection.
This error seems to have crept in while reworking the patch. I
believe the patch can be minimized to:
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 1c15112..e5a0747 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -270,11 +270,11 @@ void __init omap3_cpuinfo(void)
strcpy(cpu_name, 3630);
else if (omap3_has_iva() omap3_has_sgx())
strcpy(cpu_name, 3430/3530);
- else if (omap3_has_sgx()) {
+ else if (omap3_has_iva()) {
omap_revision = OMAP3525_REV(rev);
strcpy(cpu_name, 3525);
}
- else if (omap3_has_iva()) {
+ else if (omap3_has_sgx()) {
omap_revision = OMAP3515_REV(rev);
strcpy(cpu_name, 3515);
}
I can submit this on your behalf.
Fine by me.
S.
--
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
OMAP3515 vs 3525 inversion
Hi, all!
I think I found a bug in processor detection code.
as I see,
+ /* OMAP3430 and OMAP3530 are assumed to be same.
+*
+* OMAP3525, OMAP3515 and OMAP3503 can be detected only based
+* on available features. Upon detection, update the CPU id
+* and CPU class bits.
+*/
+ if (omap3_has_iva() omap3_has_sgx()) {
+ strcpy(cpu_name, 3430/3530);
+ }
+ else if (omap3_has_sgx()) {
+ omap_revision = OMAP3525_REV (rev);
+ strcpy(cpu_name, 3525);
+ }
+ else if (omap3_has_iva()) {
+ omap_revision = OMAP3515_REV (rev);
+ strcpy(cpu_name, 3515);
+ }
+ else {
+ omap_revision = OMAP3503_REV (rev);
+ strcpy(cpu_name, 3503);
+ }
But, actually, 3515 has no DSP, but has PowerVR,
and 3525 has no PowerVR but has DSP. In-tree code inverses this detection.
Please consider applying attached patch. (sorry, no git-send-email
available here).
From 93ac9c6b2dccb0cedb28414612ed2b1b77537dec Mon Sep 17 00:00:00 2001
From: Sergey Lapin sla...@ossfans.org
Date: Mon, 16 Nov 2009 13:23:45 +0300
Subject: [PATCH] OMAP3: id code detection 3525 vs 3515
In current tree CPU detection of 3525 vs 3515 is reversed
Signed-off-by: Sergey Lapin sla...@ossfans.org
---
arch/arm/mach-omap2/id.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index f48a4b2..2f97577 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -278,11 +278,11 @@ void __init omap3_cpuinfo(void)
/* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
strcpy(cpu_name, OMAP3430/3530);
} else if (omap3_has_sgx()) {
- omap_revision = OMAP3525_REV(rev);
- strcpy(cpu_name, OMAP3525);
- } else if (omap3_has_iva()) {
omap_revision = OMAP3515_REV(rev);
strcpy(cpu_name, OMAP3515);
+ } else if (omap3_has_iva()) {
+ omap_revision = OMAP3525_REV(rev);
+ strcpy(cpu_name, OMAP3525);
} else {
omap_revision = OMAP3503_REV(rev);
strcpy(cpu_name, OMAP3503);
--
1.6.5
Re: OMAP3 SDMA + RFBI_PARAM register
On Sat, Oct 31, 2009 at 10:41 AM, Venkatraman S svenk...@ti.com wrote:
On Thu, Oct 29, 2009 at 9:44 PM, Sergey Lapin slapi...@gmail.com wrote:
Hi, all!
I need to transfer block of data using sDMA from memory address
to RFBI_PARAM FIFO, so to put that into display module.
I do this like this:
/* DMA */
#define RFBI_BASE 0x48050800
#define RFBI_PARAM 0x0050
static void configure_dma(int dma_ch, u32 data, int size)
{
int nblk;
omap_set_dma_dest_params(dma_ch, 0, OMAP_DMA_AMODE_CONSTANT,
(RFBI_BASE + RFBI_PARAM), 0, 0);
omap_set_dma_src_params(dma_ch, 0, OMAP_DMA_AMODE_POST_INC,
data, 0, 0);
nblk = (size + PAGE_SIZE - 1) / PAGE_SIZE;
omap_set_dma_transfer_params(dma_ch, OMAP_DMA_DATA_TYPE_S8,
PAGE_SIZE, nblk, OMAP_DMA_SYNC_FRAME, 0, 0);
omap_start_dma(dma_ch);
}
Just making sure, do you want to use DMA to configure just a single
register ? According to your code, you want to transfer data to the
configuration register called RFBI_PARAM, and not the FIFO.
Assuming you want just that, I think you need to use 32 bit element
size. The registers can be read or written in 32 bit mode only. So use
OMAP_DMA_DATA_TYPE_S32, instead of OMAP_DMA_DATA_TYPE_S8.
Again, if you use CONSTANT addressing mode for destination, the
destination address will not be auto-incremented. Hence the only
outcome of this transfer would be that the last 4 bytes of data
would reside in RFBI_PARAM register, if you get to that.
Well, what I want to achieve is:
To write to my display, I need to write 0x22 to RFBI_CMD,
then do writes to RFBI_PARAM register to write pixel data.
It works in simple for(;;) loop. But I want to accelerate it,
so I'd like to use DMA for that.
from drivers/video/omap/rfbi.c:
static void rfbi_write_data(const void *buf, unsigned int len)
{
rfbi_enable_clocks(1);
if (rfbi.bits_per_cycle == 16) {
const u16 *w = buf;
BUG_ON(len 1);
for (; len; len -= 2)
rfbi_write_reg(RFBI_PARAM, *w++);
} else {
const u8 *b = buf;
BUG_ON(rfbi.bits_per_cycle != 8);
for (; len; len--)
rfbi_write_reg(RFBI_PARAM, *b++);
}
rfbi_enable_clocks(0);
}
This part works well, for the display, but it is very slow. I really want to
accelerate this stuff using DMA. Any ideas on how to do that?
My display requires the following sequence: (it is hx8340-b)
COMMAND=0x22, then
DATA=pixel data in chunks of 3 bytes per pixel. as I see, data are
passed to RFBI_PARAM register.
So all I want is what I have to do in the following situation, either
via RFBI or via sDMA writes to
RFBI_PARAM.
Actually, I have two displays, one is 1bpp, another is 18bpp, both use
8-bit 8080-style interface.
As for second one, I think it might be possible to run it using RFBI
with its dedicated DMA,
but I still haven't figured how, or if that's possible at all. For
first one, it seems not possible to run it
using RFBI's dedicated DMA and sDMA is required. Otherwise, both
displays use CPU too much.
Any ideas?
S.
--
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
OMAP3 SDMA + RFBI_PARAM register
Hi, all!
I need to transfer block of data using sDMA from memory address
to RFBI_PARAM FIFO, so to put that into display module.
I do this like this:
/* DMA */
#define RFBI_BASE 0x48050800
#define RFBI_PARAM 0x0050
static void configure_dma(int dma_ch, u32 data, int size)
{
int nblk;
omap_set_dma_dest_params(dma_ch, 0, OMAP_DMA_AMODE_CONSTANT,
(RFBI_BASE + RFBI_PARAM), 0, 0);
omap_set_dma_src_params(dma_ch, 0, OMAP_DMA_AMODE_POST_INC,
data, 0, 0);
nblk = (size + PAGE_SIZE - 1) / PAGE_SIZE;
omap_set_dma_transfer_params(dma_ch, OMAP_DMA_DATA_TYPE_S8,
PAGE_SIZE, nblk, OMAP_DMA_SYNC_FRAME, 0, 0);
omap_start_dma(dma_ch);
}
/*
* DMA call back function
*/
static void hx8340_dma_cb(int lch, u16 ch_status, void *data)
{
if (ch_status OMAP2_DMA_MISALIGNED_ERR_IRQ)
dev_dbg(hx8340.fbdev-dev, Misaligned access\n);
if (hx8340.dma_ch 0)
return;
omap_free_dma(hx8340.dma_ch);
hx8340.dma_ch = -1;
}
/* data is physical address of buffer */
static int transfer_dma(u32 data, int size)
{
int ret = 0;
int i;
if (hx8340.dma_ch != -1) {
set_current_state(TASK_UNINTERRUPTIBLE);
schedule_timeout(100);
omap_free_dma(hx8340.dma_ch);
return ret;
}
ret = omap_request_dma(OMAP34XX_DSS_DMA3, HX8340,
hx8340_dma_cb, NULL, hx8340.dma_ch);
if (ret != 0) {
printk(HX8340: dma request failure\n);
return ret;
}
configure_dma(hx8340.dma_ch, data, size);
return 0;
}
But all I get is
DMA transaction error with device 75
Is what I try to achieve at all possible? At RFBI part of CPU
datasheet it is mentioned it is possible using sDMA
to write these registers. So, is there some examples? I tried to use
drivers/mmc/host/omap_hsmmc.c as example,
but that seems to be not enough. Any ideas?
S.
--
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
OMAP3 RFBI
Hi, all! I have LCD with external controller, which handles 176x220 LCD at 18bpp (666). This device has 8-bit interface and HX8340-B LCD controller. I have managed to make it work using RFBI and send commands using registers, manually. That works, except that it uses too much of CPU to handle. As I unerstand, normal operation mode of RFBI requires 16-bit interface to controller, but is it possible to accelerate device with system DMA? I only need to accelerate data part (params register). Commands are not too frequent here, only data streams are big. Thanks a lot, S. -- 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
