Hi,
On Mon, Sep 01, 2014 at 12:00:54PM -0700, Mike Turquette wrote:
Quoting Maxime Ripard (2014-08-30 13:03:02)
The current phase API doesn't look into the actual hardware to get the phase
value, but will rather get it from a variable only set by the set_phase
function.
This will
On Mon, Sep 01, 2014 at 01:27:28PM +0200, Hans de Goede wrote:
Hi,
On 09/01/2014 12:20 PM, Maxime Ripard wrote:
Hi,
On Sun, Aug 31, 2014 at 12:15:50PM +0200, Hans de Goede wrote:
Hi,
On 08/30/2014 10:03 PM, Maxime Ripard wrote:
The current phase API doesn't look into the actual
Hi
Yep, except that if I see a value -1 as a phase, I would assume that
it's 359, but maybe it's just me :)
-1 looks suspiciously like an error return value from somewhere...
--
David Lanzendörfer
OpenSourceSupport GmbH
System engineer and supporter
http://www.o2s.ch/
signature.asc
Hi,
On Sun, Aug 31, 2014 at 12:15:50PM +0200, Hans de Goede wrote:
Hi,
On 08/30/2014 10:03 PM, Maxime Ripard wrote:
The current phase API doesn't look into the actual hardware to get the phase
value, but will rather get it from a variable only set by the set_phase
function.
This
Quoting Maxime Ripard (2014-08-30 13:03:02)
The current phase API doesn't look into the actual hardware to get the phase
value, but will rather get it from a variable only set by the set_phase
function.
This will cause issue when the client driver will never call the set_phase
function,
The current phase API doesn't look into the actual hardware to get the phase
value, but will rather get it from a variable only set by the set_phase
function.
This will cause issue when the client driver will never call the set_phase
function, where we can end up having a reported phase that will
