On Wed, Apr 16, 2008 at 04:58:21PM -0500, Scott Wood wrote:
On Thu, Apr 17, 2008 at 01:00:42AM +0400, Anton Vorontsov wrote:
On Wed, Apr 16, 2008 at 01:44:42PM -0500, Scott Wood wrote:
A maximal timeout of ~65 ms is a little low... For use as a wakeup from
sleep mode, I'd like to be able
On Thu, Apr 17, 2008 at 04:52:35PM +0400, Anton Vorontsov wrote:
Heh. Scott, think about it. You have single 16bit timer with variable
frequency. To use it, you'd better know what exactly precision you need.
Why? I know the timeout I need.
Then you limited to u16 for the interval for this
On Wednesday 16 April 2008 20:39, Anton Vorontsov wrote:
On Tue, Mar 18, 2008 at 03:48:12PM -0500, Scott Wood wrote:
[...]
How about:
struct gtm_timer *gtm_get_specific_timer(struct gtm *gtm, int timer,
int width);
...with np-data used by the
On Thu, Apr 17, 2008 at 09:19:03AM -0500, Scott Wood wrote:
On Thu, Apr 17, 2008 at 04:52:35PM +0400, Anton Vorontsov wrote:
Heh. Scott, think about it. You have single 16bit timer with variable
frequency. To use it, you'd better know what exactly precision you need.
Why? I know the
On Thu, Apr 17, 2008 at 04:23:56PM +0200, Laurent Pinchart wrote:
[...]
+ /*
+* We have two 8 bit prescalers -- primary and secondary (psr, sps),
+* plus slow go mode (clk / 16). So, total prescale value is
+* 16 * (psr + 1) * (sps + 1).
+*/
+ if (prescaler 256 *
On Thu, Apr 17, 2008 at 04:23:56PM +0200, Laurent Pinchart wrote:
+ /*
+* We have two 8 bit prescalers -- primary and secondary (psr, sps),
+* plus slow go mode (clk / 16). So, total prescale value is
+* 16 * (psr + 1) * (sps + 1).
+*/
+ if (prescaler 256 * 256 *
On Thu, Apr 17, 2008 at 04:39:04AM +1000, Anton Vorontsov wrote:
+#define GTMDR_FFR(1 3)
This should be GTMDR_FRR according to the chip docs.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
On Thu, Apr 17, 2008 at 11:14:00AM -0500, Scott Wood wrote:
Anton Vorontsov wrote:
This isn't a timer with usec precision! This is a timer that silently
crops precision as it wants to. Ahh, I see you dropped u prefix.
It is a timer with usec precision, unless you ask for a timeout of more
On Tue, Mar 18, 2008 at 03:48:12PM -0500, Scott Wood wrote:
[...]
How about:
struct gtm_timer *gtm_get_specific_timer(struct gtm *gtm, int timer,
int width);
...with np-data used by the caller to figure out which gtm pointer to
pass in.
Thanks for
On Wed, Apr 16, 2008 at 10:39:04PM +0400, Anton Vorontsov wrote:
+/**
+ * gtm_reset_utimer16 - reset 16 bits timer
+ * @tmr: pointer to the gtm_timer structure obtained from gtm_get_timer
+ * @usec:timer interval in microseconds
+ * @free_run:free run flag
+ *
+ * This
On Wed, Apr 16, 2008 at 01:44:42PM -0500, Scott Wood wrote:
On Wed, Apr 16, 2008 at 10:39:04PM +0400, Anton Vorontsov wrote:
+/**
+ * gtm_reset_utimer16 - reset 16 bits timer
+ * @tmr: pointer to the gtm_timer structure obtained from gtm_get_timer
+ * @usec: timer interval in
On Thu, Apr 17, 2008 at 01:00:42AM +0400, Anton Vorontsov wrote:
On Wed, Apr 16, 2008 at 01:44:42PM -0500, Scott Wood wrote:
A maximal timeout of ~65 ms is a little low... For use as a wakeup from
sleep mode, I'd like to be able to request timeouts as large as the
hardware allows.
That
On Tuesday 11 March 2008 18:24, Anton Vorontsov wrote:
GTM stands for General-purpose Timers Module and able to generate
timer{1,2,3,4} interrupts.
There are several limitations in this support:
1. Cascaded (32 bit) timers unimplemented (1-2, 3-4).
This is straightforward to implement
On Tue, Apr 08, 2008 at 11:01:53AM +0200, Laurent Pinchart wrote:
On Tuesday 11 March 2008 18:24, Anton Vorontsov wrote:
GTM stands for General-purpose Timers Module and able to generate
timer{1,2,3,4} interrupts.
There are several limitations in this support:
1. Cascaded (32 bit)
On Tue, Mar 11, 2008 at 08:24:29PM +0300, Anton Vorontsov wrote:
+Required properties:
+ - compatible : should be fsl,gtm (fsl,qe-gtm in addition for QE
+ GTMs).
+ - reg : should contain gtm registers location and length (0x40).
+ - interrupts : should
On Tue, Mar 18, 2008 at 12:43:29PM -0500, Scott Wood wrote:
On Tue, Mar 11, 2008 at 08:24:29PM +0300, Anton Vorontsov wrote:
+Required properties:
+ - compatible : should be fsl,gtm (fsl,qe-gtm in addition for QE
+ GTMs).
+ - reg : should contain gtm
Anton Vorontsov wrote:
+arch_initcall(qe_init_gtm);
If this happens before the gtm_init_gtm(),
If isn't possible, order is guaranteed.
You use arch_initcall for both, so you're relying on link order. I
think this at least merits a comment.
then np-data will not be set.
It's a bug in
On Tue, Mar 18, 2008 at 02:55:14PM -0500, Scott Wood wrote:
Anton Vorontsov wrote:
+arch_initcall(qe_init_gtm);
If this happens before the gtm_init_gtm(),
If isn't possible, order is guaranteed.
You use arch_initcall for both, so you're relying on link order. I
think this at least
Anton Vorontsov wrote:
On Tue, Mar 18, 2008 at 02:55:14PM -0500, Scott Wood wrote:
Anton Vorontsov wrote:
+arch_initcall(qe_init_gtm);
If this happens before the gtm_init_gtm(),
If isn't possible, order is guaranteed.
You use arch_initcall for both, so you're relying on link order. I
think
19 matches
Mail list logo