* 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).