On Fri, May 08, 2015 at 01:02:17PM -0700, Jonathan Richardson wrote: > For the clock functions I think we can use the existing framework > unchanged with one exception: ptp_clock_adjtime() doesn't allow negative > time adjustments and we would like to allow this. ??? /** * struct ptp_clock_info - decribes a PTP hardware clock ... * @adjtime: Shifts the time of the hardware clock. * parameter delta: Desired change in nanoseconds. ... int (*adjtime)(struct ptp_clock_info *ptp, s64 delta); That s64 is 's' as in "signed". > IRQ interval: I mentioned before that we may be able to calculate the > isochronous interrupt rate automatically but this isn't possible because > the DTE doesn't know the frequency of the clients. One solution is to > use the 'PTP_PEROUT_REQUEST' ioctl to set a periodic timer frequency. > Not really a timer but good enough for our purposes. As I said in my other reply, I don't understand what the problem is. > Set divider: There is no ability to set a frequency or do anything to a > channel. We could re-use the PTP_EXTTS_REQUEST ioctl but extend 'struct > ptp_extts_request' by using the reserved field rsv to allow setting an > integer value representing either a frequency or divider value in our > case - some value to configure a channel. A new flag would have to be > added to the existing PTP_ENABLE_FEATURE, RISING and FALLING EDGE. I don't get this, either. > Get timestamp: This is a bit more complicated. Currently the PTP driver > does list management for timestamps from external timestamp channels. > Timestamps from all channels go into the same list. In our driver we > have a s/w FIFO for each client and it closely matches the h/w FIFO and > handles any overflow. We would like to keep it this way because it also > allows multiple user space processes to only fetch timestamps for the > client it's handling. But having many readers is less efficient and more complex. Also, we can adjust the buffer if needed to prevent HW FIFO overflows. > We could add a new ioctl to get a timestamp from > the driver instead of doing it through ptp_read() but it would be nice > if we could let ptp_read() allow the driver to do timestamp management > instead of PTP. Maybe provide an option to obtain the timestamps from a > container in the driver instead of the one managed by PTP. I like being > able to use read/poll to obtain data instead of polling the kernel with > ioctls as we are currently doing. The PTP interface supports poll/read just fine already. > Also, avoiding the kmalloc in ptp_read > would be nice because this of the frequency it would be called at. Do > you have any preference on how to handle this? Originally I had the buffer on the stack, but DaveM didn't like it, saying performance is no excuse for not doing it "the right way". Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
