lkml.org 
[lkml]   [2014]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH RFC net-next v1 0/9] ptp: dynamic pin control
Hi Richard,

--On March 08, 2014 20:42 +0100 Richard Cochran <richardcochran@gmail.com>
wrote:

> This patch series introduces a way of changing the auxiliary PTP
> Hardware Clock functions (periodic output signals and time stamping
> external signals) at run time. In the past on the netdev list, we have
> discussed other ways to handle this, such as module parameters and
> ethtool. This series implements a new PHC ioctl because that is the
> most natural way. Users already activate the auxiliary functions via
> the ioctls. The sysfs interface has also been expanded so that the pin
> configuration can be programmed using shell scripts.

I did a few tests on one of my boards, everything works so far! Thanks for
the patchset, I like it!

> The first patch adds the new ioctls. The PHC subsystem does most of
> the work of maintaining the function-to-pin mapping. Drivers will only
> need to allocate and initialize a pin configuration table and also
> provide a new method that validates a particular assignment.
>
> Patches 5 and 6 just clean up a couple of issues in the phyter driver,
> and the remaining patches actually hook the phyter's pins into the new
> system.
>
> Comments and questions are most welcome.

Do you think it is possible to extend this in the future, e.g. for
selecting the polarity of periodic output signals or for time stamping of
external signals (rising edge/falling edge), or duty cycles of the periodic
signal other than 50%? How could this be done? Using the reserved fields in
struct ptp_pin_desc?

Do you think the concept allows an extension for single pulse output, e.g.
programming a pin to output a single pulse at a given time, as supported by
the DP83640?

If several DP83640 are connected together with the calibration function,
only the GPIOs of the master device can be used, right? I guess this could
also be extended in the future to use the GPIOs of all DP83640, right? Or
do you see a problem with your concept here?

Best regards,
Christian



\
 
 \ /
  Last update: 2014-03-12 10:01    [W:0.116 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site