Hello.

I have Davinci DM365 board, but I can't find more suitable
mail-listing to ask my qustion.

I have written Linux kernel module.
Main purpose: change ARM core rate.
Davinci DM365 has two PLL: PLL1 and PLL2.

ARM core can be feed by:
* PLLC1SYSCLK1 - fixed all time, equal to 243000 kHz.
* PLLC2SYSCLK2 - that one I can change.

Lower borde ARM core freq == 121500 kHz (must be > pll1_sysclk4 CFG/DMA bus).
Higher borde ARM core freq == 300000 kHz.

To change ARM core freq I do next steps:
1. switch ARM core to PLLC2SYSCLK2
2. reset & configure PLL2.
3. switch back to PLLC2SYSCLK2.
4. call adjust_jiffies() ( snatch from cpufreq.c)

Now I come to standstill.

I got several working configurations, and several not working.
I can't undestand why some of them works, and some not.

Stable work. Switch between next rates work all times:
272000 (kHz), mul=17, div=2
204000 (kHz), mul=17, div=3
252000 (kHz), mul=21, div=3
201600 (kHz), mul=21, div=4
200000 (kHz), mul=25, div=5
249600 (kHz), mul=26, div=4
259200 (kHz), mul=27, div=4
268800 (kHz), mul=28, div=4
278400 (kHz), mul=29, div=4
232000 (kHz), mul=29, div=5
205714 (kHz), mul=30, div=6
297600 (kHz), mul=31, div=4
248000 (kHz), mul=31, div=5
212571 (kHz), mul=31, div=6
186000 (kHz), mul=31, div=7

Don't work - (completely instantaneously hang system):

144000 (kHz), mul=3, div=0
180000 (kHz), mul=15, div=3
136000 (kHz), mul=17, div=5
126000 (kHz), mul=21, div=7
157714 (kHz), mul=23, div=6
171428 (kHz), mul=25, div=6
133333 (kHz), mul=25, div=8
178285 (kHz), mul=26, div=6
162000 (kHz), mul=27, div=7
174000 (kHz), mul=29, div=7
165333 (kHz), mul=31, div=8
158400 (kHz), mul=33, div=9
296000 (kHz), mul=37, div=5
203076 (kHz), mul=55, div=12
299076 (kHz), mul=81, div=12

Can anybody comment this behaviour?


If frequency == 222 000 kHz than system behave quite unstable.
And give next messages:


Backtrace:
Г„<c0074c9c>Гњ (add_to_page_cache_lru+0x0/0xac) from Г„<c0074dbc>Гњ
(grab_cache_page_write_begin+0x74/0x9c)
 r5:c46d4268 r4:c03dc480
Г„<c0074d48>Гњ (grab_cache_page_write_begin+0x0/0x9c) from
Г„<c00f35b8>Гњ (ext3_write_begin+0x80/0x240)
Г„<c00f3538>Гњ (ext3_write_begin+0x0/0x240) from Г„<c0073d10>Гњ
(generic_file_buffered_write+0xf0/0x258)
Г„<c0073c20>Гњ (generic_file_buffered_write+0x0/0x258) from
Г„<c0075e64>Гњ (__generic_file_aio_write+0x4a8/0x4f8)
Г„<c00759bc>Гњ (__generic_file_aio_write+0x0/0x4f8) from
Г„<c0075f28>Гњ (generic_file_aio_write+0x74/0xdc)
Г„<c0075eb4>Гњ (generic_file_aio_write+0x0/0xdc) from Г„<c009dc1c>Гњ
(do_sync_readv_writev+0x98/0xe4)
Г„<c009db84>Гњ (do_sync_readv_writev+0x0/0xe4) from Г„<c009e2e4>Гњ
(do_readv_writev+0xb4/0x190)
Г„<c009e230>Гњ (do_readv_writev+0x0/0x190) from Г„<c009e42c>Гњ
(vfs_writev+0x6c/0x7c)
Г„<c009e3c0>Гњ (vfs_writev+0x0/0x7c) from Г„<c009e510>Гњ (sys_writev+0x44/0x70)
 r5:00000000 r4:0030063f
Г„<c009e4cc>Гњ (sys_writev+0x0/0x70) from Г„<c0028f60>Гњ
(ret_fast_syscall+0x0/0x2c)


Backtrace:
Г„<c002c2a4>Гњ (dump_backtrace+0x0/0x10c) from Г„<c029d478>Гњ
(dump_stack+0x18/0x1c)
 r7:00000000 r6:c3446738 r5:00017000 r4:00000000
Г„<c029d460>Гњ (dump_stack+0x0/0x1c) from Г„<c0036c74>Гњ
(__schedule_bug+0x54/0x60)
Г„<c0036c20>Гњ (__schedule_bug+0x0/0x60) from Г„<c029d6ec>Гњ
(schedule+0x68/0x3c4)
 r4:c34bed4c
Г„<c029d684>Гњ (schedule+0x0/0x3c4) from Г„<c00370b8>Гњ
(__cond_resched+0x18/0x24)
Г„<c00370a0>Гњ (__cond_resched+0x0/0x24) from Г„<c029db58>Гњ
(_cond_resched+0x30/0x40)
Г„<c029db28>Гњ (_cond_resched+0x0/0x40) from Г„<c008b0ec>Гњ
(unmap_vmas+0x5d8/0x6a0)
Г„<c008ab14>Гњ (unmap_vmas+0x0/0x6a0) from Г„<c008dd68>Гњ (exit_mmap+0xd4/0x208)
Г„<c008dc94>Гњ (exit_mmap+0x0/0x208) from Г„<c003be60>Гњ (mmput+0x40/0xf0)
 r8:00000000 r7:c34bec34 r6:c3442320 r5:00000000 r4:c34bec00
Г„<c003be20>Гњ (mmput+0x0/0xf0) from Г„<c0040144>Гњ (exit_mm+0x124/0x130)
 r5:c34bec00 r4:00000000
Г„<c0040020>Гњ (exit_mm+0x0/0x130) from Г„<c0041bec>Гњ (do_exit+0x190/0x65c)
 r7:c49c3bd8 r6:c3442320 r5:c3442320 r4:0000000b
Г„<c0041a5c>Гњ (do_exit+0x0/0x65c) from Г„<c002c7e0>Гњ (die+0x1c4/0x1f4)
Г„<c002c61c>Гњ (die+0x0/0x1f4) from Г„<c002c858>Гњ (bad_mode+0x48/0x70)
Г„<c002c810>Гњ (bad_mode+0x0/0x70) from Г„<c00744f8>Гњ (find_get_page+0x30/0xb0)
 r4:c03dc480
BUG: scheduling while atomic: syslogd/1411/0x40000002


Main question is:
Why some frequencies are stable, and other does not?
--
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

Reply via email to