* Timers on mpc8248 etc... @ 2007-11-28 23:41 Alan Bennett 2007-11-28 23:43 ` Scott Wood 0 siblings, 1 reply; 6+ messages in thread From: Alan Bennett @ 2007-11-28 23:41 UTC (permalink / raw) To: linuxppc-dev I've got a routine that needs to delay for X microseconds, this is a must. The command after schedule_timeout must has to wait for the HW to complete a task that takes X microseconds. I would think that one way to do this is with a simple schedule_timeout. But in the example below, the time that passes from run1() to dontrun() is far less than 3.2 msecs. Infact, sometimes its ~ 800 micros according the a analyzer looking at points triggered in run1() and donrun(). Could this be a configuration problem with the timer/interrupt that generates the jiffies? run1(); delaytime = 3280; set_current_state(TASK_UNINTERRUPTIBLE) ; schedule_timeout(usecs_to_jiffies(delaytime)); //1HZ = 1 second 1/1000 second = 1 milli dontrun(); ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Timers on mpc8248 etc... 2007-11-28 23:41 Timers on mpc8248 etc Alan Bennett @ 2007-11-28 23:43 ` Scott Wood 2007-11-29 4:06 ` Alan Bennett 0 siblings, 1 reply; 6+ messages in thread From: Scott Wood @ 2007-11-28 23:43 UTC (permalink / raw) To: Alan Bennett; +Cc: linuxppc-dev Alan Bennett wrote: > I've got a routine that needs to delay for X microseconds, this is a > must. The command after schedule_timeout must has to wait for the HW > to complete a task that takes X microseconds. > > I would think that one way to do this is with a simple > schedule_timeout. But in the example below, the time that passes from > run1() to dontrun() is far less than 3.2 msecs. Infact, sometimes its > ~ 800 micros according the a analyzer looking at points triggered in > run1() and donrun(). Could this be a configuration problem with the > timer/interrupt that generates the jiffies? Are you sure the timebase frequency is set correctly in the device tree? -Scott ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Timers on mpc8248 etc... 2007-11-28 23:43 ` Scott Wood @ 2007-11-29 4:06 ` Alan Bennett 2007-11-29 11:31 ` Vitaly Bordug 0 siblings, 1 reply; 6+ messages in thread From: Alan Bennett @ 2007-11-29 4:06 UTC (permalink / raw) To: Scott Wood; +Cc: linuxppc-dev It comes from uboot. Can you point me in the right direction to make sure its right? PowerPC,8248@0 { device_type = "cpu"; reg = <0>; d-cache-line-size = <d#32>; i-cache-line-size = <d#32>; d-cache-size = <d#16384>; i-cache-size = <d#16384>; timebase-frequency = <0>; clock-frequency = <0>; }; On 11/28/07, Scott Wood <scottwood@freescale.com> wrote: > Alan Bennett wrote: > > I've got a routine that needs to delay for X microseconds, this is a > > must. The command after schedule_timeout must has to wait for the HW > > to complete a task that takes X microseconds. > > > > I would think that one way to do this is with a simple > > schedule_timeout. But in the example below, the time that passes from > > run1() to dontrun() is far less than 3.2 msecs. Infact, sometimes its > > ~ 800 micros according the a analyzer looking at points triggered in > > run1() and donrun(). Could this be a configuration problem with the > > timer/interrupt that generates the jiffies? > > Are you sure the timebase frequency is set correctly in the device tree? > > -Scott > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Timers on mpc8248 etc... 2007-11-29 4:06 ` Alan Bennett @ 2007-11-29 11:31 ` Vitaly Bordug 2007-11-29 13:50 ` Alan Bennett 0 siblings, 1 reply; 6+ messages in thread From: Vitaly Bordug @ 2007-11-29 11:31 UTC (permalink / raw) To: Alan Bennett; +Cc: linuxppc-dev On Wed, 28 Nov 2007 21:06:36 -0700 Alan Bennett wrote: > It comes from uboot. Can you point me in the right direction to make > sure its right? > PowerPC,8248@0 { > device_type = "cpu"; > reg = <0>; > d-cache-line-size = <d#32>; > i-cache-line-size = <d#32>; > d-cache-size = <d#16384>; > i-cache-size = <d#16384>; > timebase-frequency = <0>; > clock-frequency = <0>; > }; > if your u-boot is up to date, it will have fdt command, and by fdt boardsetup fdt print / inspect what u-boot did. Of course you should have dtb preloaded to memory and fdt addr <offset> should be said to let u-boot know where dtb resides. > > On 11/28/07, Scott Wood <scottwood@freescale.com> wrote: > > Alan Bennett wrote: > > > I've got a routine that needs to delay for X microseconds, this > > > is a must. The command after schedule_timeout must has to wait > > > for the HW to complete a task that takes X microseconds. > > > > > > I would think that one way to do this is with a simple > > > schedule_timeout. But in the example below, the time that passes > > > from run1() to dontrun() is far less than 3.2 msecs. Infact, > > > sometimes its ~ 800 micros according the a analyzer looking at > > > points triggered in run1() and donrun(). Could this be a > > > configuration problem with the timer/interrupt that generates the > > > jiffies? > > > > Are you sure the timebase frequency is set correctly in the device > > tree? > > > > -Scott > > > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev -- Sincerely, Vitaly ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Timers on mpc8248 etc... 2007-11-29 11:31 ` Vitaly Bordug @ 2007-11-29 13:50 ` Alan Bennett 2007-11-29 19:05 ` Alan Bennett 0 siblings, 1 reply; 6+ messages in thread From: Alan Bennett @ 2007-11-29 13:50 UTC (permalink / raw) To: Vitaly Bordug; +Cc: linuxppc-dev My uboot is new-ish, but I don't have the fdt commands? U-Boot 1.3.0 g992742a5-dirty u-boot:clock configuration =========================== MPC8248 Clock Configuration - Bus-to-Core Mult 3.5x, VCO Div 2, 60x Bus Freq 30-85 , Core Freq 100-300 - dfbrg 1, corecnf 0x1e, busdf 3, cpmdf 1, plldf 0, pllmf 5, pcidf 5 - vco_out 396000000, scc_clk 99000000, brg_clk 24750000 - cpu_clk 231000000, cpm_clk 198000000, bus_clk 66000000 Boot Wrapper Reporting =========================== Memory <- <0x0 0x8000000> (128MB) CPU clock-frequency <- 0xdc4c7c0 (231MHz) CPU timebase-frequency <- 0xfbc520 (17MHz) CPU bus-frequency <- 0x3ef1480 (66MHz) Kernel reporting =========================== clocksource: timebase mult[f26c9b2] shift[22] registered device tree in kernel (hex= `od -x`: =========================== /proc/device-tree/cpus/PowerPC,8248@0/name PowerPC,8248 /proc/device-tree/cpus/PowerPC,8248@0/bus-frequency 0000000 03ef 1480 /proc/device-tree/cpus/PowerPC,8248@0/clock-frequency 0000000 0dc4 c7c0 /proc/device-tree/cpus/PowerPC,8248@0/timebase-frequency 0000000 00fb c520 /proc/device-tree/cpus/PowerPC,8248@0/i-cache-size 0000000 0000 4000 On 11/29/07, Vitaly Bordug <vitb@kernel.crashing.org> wrote: > On Wed, 28 Nov 2007 21:06:36 -0700 > Alan Bennett wrote: > > > It comes from uboot. Can you point me in the right direction to make > > sure its right? > > PowerPC,8248@0 { > > device_type = "cpu"; > > reg = <0>; > > d-cache-line-size = <d#32>; > > i-cache-line-size = <d#32>; > > d-cache-size = <d#16384>; > > i-cache-size = <d#16384>; > > timebase-frequency = <0>; > > clock-frequency = <0>; > > }; > > > if your u-boot is up to date, it will have fdt command, and by > fdt boardsetup > fdt print / > > inspect what u-boot did. Of course you should have dtb preloaded to memory and > fdt addr <offset> should be said to let u-boot know where dtb resides. > > > > > > On 11/28/07, Scott Wood <scottwood@freescale.com> wrote: > > > Alan Bennett wrote: > > > > I've got a routine that needs to delay for X microseconds, this > > > > is a must. The command after schedule_timeout must has to wait > > > > for the HW to complete a task that takes X microseconds. > > > > > > > > I would think that one way to do this is with a simple > > > > schedule_timeout. But in the example below, the time that passes > > > > from run1() to dontrun() is far less than 3.2 msecs. Infact, > > > > sometimes its ~ 800 micros according the a analyzer looking at > > > > points triggered in run1() and donrun(). Could this be a > > > > configuration problem with the timer/interrupt that generates the > > > > jiffies? > > > > > > Are you sure the timebase frequency is set correctly in the device > > > tree? > > > > > > -Scott > > > > > _______________________________________________ > > Linuxppc-dev mailing list > > Linuxppc-dev@ozlabs.org > > https://ozlabs.org/mailman/listinfo/linuxppc-dev > > > -- > Sincerely, Vitaly > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Timers on mpc8248 etc... 2007-11-29 13:50 ` Alan Bennett @ 2007-11-29 19:05 ` Alan Bennett 0 siblings, 0 replies; 6+ messages in thread From: Alan Bennett @ 2007-11-29 19:05 UTC (permalink / raw) To: Vitaly Bordug; +Cc: linuxppc-dev Though I'd like to move to a uboot fdt, I can't afford to port it yet, maybe in January. But until then ... It appears that a simple change in U-boot constant, #define CONFIG_8260_CLKIN 66000000 /* in Hz */ to #define CONFIG_8260_CLKIN 100000000 /* in Hz */ has fixed the speed mismatch, and I've verified that schedule_timeout(HZ/10) produces a 100 millisecond delay. However, my serial ports (brgs) are hosed. -Alan On 11/29/07, Alan Bennett <embedded@akb.net> wrote: > My uboot is new-ish, but I don't have the fdt commands? U-Boot 1.3.0 > g992742a5-dirty > > u-boot:clock configuration > =========================== > MPC8248 Clock Configuration > - Bus-to-Core Mult 3.5x, VCO Div 2, 60x Bus Freq 30-85 , Core Freq 100-300 > - dfbrg 1, corecnf 0x1e, busdf 3, cpmdf 1, plldf 0, pllmf 5, pcidf 5 > - vco_out 396000000, scc_clk 99000000, brg_clk 24750000 > - cpu_clk 231000000, cpm_clk 198000000, bus_clk 66000000 > > Boot Wrapper Reporting > =========================== > Memory <- <0x0 0x8000000> (128MB) > CPU clock-frequency <- 0xdc4c7c0 (231MHz) > CPU timebase-frequency <- 0xfbc520 (17MHz) > CPU bus-frequency <- 0x3ef1480 (66MHz) > > Kernel reporting > =========================== > clocksource: timebase mult[f26c9b2] shift[22] registered > > device tree in kernel (hex= `od -x`: > =========================== > /proc/device-tree/cpus/PowerPC,8248@0/name > PowerPC,8248 > /proc/device-tree/cpus/PowerPC,8248@0/bus-frequency > 0000000 03ef 1480 > /proc/device-tree/cpus/PowerPC,8248@0/clock-frequency > 0000000 0dc4 c7c0 > /proc/device-tree/cpus/PowerPC,8248@0/timebase-frequency > 0000000 00fb c520 > /proc/device-tree/cpus/PowerPC,8248@0/i-cache-size > 0000000 0000 4000 > > > > On 11/29/07, Vitaly Bordug <vitb@kernel.crashing.org> wrote: > > On Wed, 28 Nov 2007 21:06:36 -0700 > > Alan Bennett wrote: > > > > > It comes from uboot. Can you point me in the right direction to make > > > sure its right? > > > PowerPC,8248@0 { > > > device_type = "cpu"; > > > reg = <0>; > > > d-cache-line-size = <d#32>; > > > i-cache-line-size = <d#32>; > > > d-cache-size = <d#16384>; > > > i-cache-size = <d#16384>; > > > timebase-frequency = <0>; > > > clock-frequency = <0>; > > > }; > > > > > if your u-boot is up to date, it will have fdt command, and by > > fdt boardsetup > > fdt print / > > > > inspect what u-boot did. Of course you should have dtb preloaded to memory and > > fdt addr <offset> should be said to let u-boot know where dtb resides. > > > > > > > > > > On 11/28/07, Scott Wood <scottwood@freescale.com> wrote: > > > > Alan Bennett wrote: > > > > > I've got a routine that needs to delay for X microseconds, this > > > > > is a must. The command after schedule_timeout must has to wait > > > > > for the HW to complete a task that takes X microseconds. > > > > > > > > > > I would think that one way to do this is with a simple > > > > > schedule_timeout. But in the example below, the time that passes > > > > > from run1() to dontrun() is far less than 3.2 msecs. Infact, > > > > > sometimes its ~ 800 micros according the a analyzer looking at > > > > > points triggered in run1() and donrun(). Could this be a > > > > > configuration problem with the timer/interrupt that generates the > > > > > jiffies? > > > > > > > > Are you sure the timebase frequency is set correctly in the device > > > > tree? > > > > > > > > -Scott > > > > > > > _______________________________________________ > > > Linuxppc-dev mailing list > > > Linuxppc-dev@ozlabs.org > > > https://ozlabs.org/mailman/listinfo/linuxppc-dev > > > > > > -- > > Sincerely, Vitaly > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2007-11-29 19:05 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-11-28 23:41 Timers on mpc8248 etc Alan Bennett 2007-11-28 23:43 ` Scott Wood 2007-11-29 4:06 ` Alan Bennett 2007-11-29 11:31 ` Vitaly Bordug 2007-11-29 13:50 ` Alan Bennett 2007-11-29 19:05 ` Alan Bennett
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).