Re: [PATCH v3] Renesas Ethernet AVB driver

On Tue, Apr 14, 2015 at 01:07:38AM +0300, Sergei Shtylyov wrote: +static int ravb_wait(struct net_device *ndev, u16 reg, u32 mask, u32 value) +{ + int i; + + for (i = 0; i 1; i++) { + if ((ravb_read(ndev, reg) mask) == value) + return 0; +

Re: [PATCH 11/11] k_clock:Remove the 32bit methods with timespec type

On Mon, Apr 20, 2015 at 01:57:39PM +0800, Baolin Wang wrote: @@ -911,18 +907,14 @@ retry: return -EINVAL; kc = clockid_to_kclock(timr-it_clock); - if (WARN_ON_ONCE(!kc || (!kc-timer_set !kc-timer_set64))) { + if (WARN_ON_ONCE(!kc || !kc-timer_set64)) {

Re: [Y2038] [PATCH 04/11] posix timers:Introduce the 64bit methods with timespec64 type for k_clock structure

On Wed, Apr 22, 2015 at 03:50:45PM +0200, Arnd Bergmann wrote: time, stime, gettimeofday, settimeofday, adjtimex, nanosleep, getitimer, setitimer: all deprecated = wontfix If adjtimex is deprecated, what will replace it? It is really important for ntp. Thanks, Richard -- To unsubscribe

Re: [Y2038] [PATCH 04/11] posix timers:Introduce the 64bit methods with timespec64 type for k_clock structure

On Wed, Apr 22, 2015 at 10:45:23AM +0200, Thomas Gleixner wrote: So we could save one translation step if we implement new syscalls which have a scalar nsec interface instead of the timespec/timeval cruft and let user space do the translation to whatever it wants. +1 I personally would

Re: [PATCH] Added additional callback to ptp_clock_info:

On Thu, Jun 25, 2015 at 04:42:57PM -0700, Christopher Hall wrote: @@ -196,19 +196,31 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg) break; } pct = sysoff-ts[0]; - for (i = 0; i sysoff-n_samples;

Re: [PATCH] Add PTP cross-timestamp to the PTP driver interface

Chris, Basically this patch looks okay to me. Could you please add LKML, John Stultz and tglx (the time guys) onto CC? I would like to get their Acks or at least let them have a chance to review it. On Thu, Jun 25, 2015 at 04:42:56PM -0700, Christopher Hall wrote: This patch allows system and

[PATCH net] net: igb: fix the start time for periodic output signals

, and the signal does appear starting with the second edge. This patch fixes the issue by programming the registers correctly. Signed-off-by: Richard Cochran richardcoch...@gmail.com --- drivers/net/ethernet/intel/igb/igb_ptp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [PATCH net] net: igb: fix the start time for periodic output signals

On Thu, Jun 11, 2015 at 02:51:30PM +0200, Richard Cochran wrote: This patch fixes the issue by programming the registers correctly. Please also consider this for stable. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord

Re: [PATCH v2 1/1] Added additional callback to ptp_clock_info:

I have three nits to pick... On Thu, Jul 02, 2015 at 06:14:48PM -0700, Christopher Hall wrote: diff --git a/include/linux/ptp_clock_kernel.h b/include/linux/ptp_clock_kernel.h index b8b7306..344f129 100644 --- a/include/linux/ptp_clock_kernel.h +++ b/include/linux/ptp_clock_kernel.h @@

Re: [PATCH v2 0/1] Add PTP cross-timestamp to the PTP driver interface

On Thu, Jul 02, 2015 at 06:14:47PM -0700, Christopher Hall wrote: This patch adds an additional callback getsynctime64(). Which will be called when the driver is able to perform a more accurate, implementation specific cross-timestamping. For example, future network devices that implement

[PATCH net-next 2/4] net: cpsw: remove two unused global functions

The funtions, cpsw_ale_flush and cpsw_ale_set_ageout, have never been used since they were first introduced. This patch removes the dead code. Signed-off-by: Richard Cochran richardcoch...@gmail.com --- drivers/net/ethernet/ti/cpsw_ale.c | 45 -- drivers/net

[PATCH net-next 0/4] cpsw cleanups

While working on an out-of-tree customization, I noticed a few minor problems in the cpsw code. This series cleans up the issues I found. Thanks, Richard Richard Cochran (4): net: cpsw: fix misplaced break statements. net: cpsw: remove two unused global functions net: cpsw: remove

[PATCH net-next 4/4] net: cpsw: remove redundant calls disabling dma interrupts.

The function, cpsw_intr_disable, already calls cpdma_ctlr_int_ctrl. There is no need to disable the dma interrupts twice. This patch removes the extra calls. Signed-off-by: Richard Cochran richardcoch...@gmail.com --- drivers/net/ethernet/ti/cpsw.c | 3 --- 1 file changed, 3 deletions(-) diff

[PATCH net-next 3/4] net: cpsw: remove redundant calls enabling dma interrupts.

The function, cpsw_intr_enable, already calls cpdma_ctlr_int_ctrl. There is no need to enable the dma interrupts twice. This patch removes the extra call. Signed-off-by: Richard Cochran richardcoch...@gmail.com --- drivers/net/ethernet/ti/cpsw.c | 2 -- 1 file changed, 2 deletions(-) diff

[PATCH net-next 1/4] net: cpsw: fix misplaced break statements.

Having the breaks too far to the left makes parsing the dense switch/case block unnecessarily harder. Signed-off-by: Richard Cochran richardcoch...@gmail.com --- drivers/net/ethernet/ti/cpsw.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/ti/cpsw.c

[PATCH net 3/3] net: dp83640: fix improper double spin locking.

without irqsave. Signed-off-by: Richard Cochran richardcoch...@gmail.com --- drivers/net/phy/dp83640.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c index e570036..00cb41e 100644 --- a/drivers/net/phy/dp83640.c +++ b

[PATCH net 2/3] net: dp83640: reinforce locking rules.

. Signed-off-by: Richard Cochran richardcoch...@gmail.com --- drivers/net/phy/dp83640.c | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c index 7a068d9..e570036 100644 --- a/drivers/net/phy/dp83640.c +++ b/drivers

[PATCH net 0/3] phyter bug fixes

While working on a project using the phyter, I noticed some bugs that have crept in over time. This series fixes those bugs. These patches are also meant for stable. Thanks, Richard Richard Cochran (3): net: dp83640: fix broken calibration routine. net: dp83640: reinforce locking rules

[PATCH net 1/3] net: dp83640: fix broken calibration routine.

that trigger indexes 0 and 1 are special in allowing the TRIG_IF_LATE flag to actually work. This patch fixes the issue by using one of the special triggers during the recalibration method. Signed-off-by: Richard Cochran richardcoch...@gmail.com --- drivers/net/phy/dp83640.c | 2 +- 1 file changed

Re: [PATCH v3 3/4] Add support for driver cross-timestamp to PTP_SYS_OFFSET ioctl

On Sat, Aug 22, 2015 at 10:33:48PM +0200, Thomas Gleixner wrote: @@ -196,19 +197,31 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg) break; } pct = sysoff-ts[0]; - for (i = 0; i sysoff-n_samples; i++)

Re: [PATCH v3 3/4] Add support for driver cross-timestamp to PTP_SYS_OFFSET ioctl

On Sun, Aug 23, 2015 at 10:15:00AM +0200, Thomas Gleixner wrote: So why can't you take N samples from the synced hardware? It does not make any sense to me to switch to the imprecise mode if nsamples 1. Ok, then I prefer to leave this imprecise method in place and ... You can also provide a

Re: [PATCH 1/5] Add functions producing system time given a backing counter value

On Wed, Jul 29, 2015 at 12:49:44PM +0200, Peter Zijlstra wrote: This is still fuzzy, right? The hardware ART timestamp could be from _before_ the NTP adjust; or the NTP adjust could happen while we do this conversion and we'll take the retry loop. In the original series, yes. In both cases,

Re: [PATCH 1/5] Add functions producing system time given a backing counter value

On Wed, Jul 29, 2015 at 12:23:27PM +0200, Thomas Gleixner wrote: Something like the below untested patch should be all we need for PTP to be as precise as possible. Yes, that is as good as it can be. The code protects against concurrent NTP adjustments, and the PTP driver will have to block

Re: [PATCH v2 4/4] Added getsynctime64() callback

On Thu, Aug 13, 2015 at 09:10:36PM +, Hall, Christopher S wrote: + if (!cpu_has_art) + return -EOPNOTSUPP; Perform this check before registration, setting .getsynctime64 accordingly. The problem here is that ART initialization doesn't happen until we install TSC as a

Re: [PATCH v2 4/4] Added getsynctime64() callback

On Fri, Aug 07, 2015 at 04:01:35PM -0700, Christopher Hall wrote: --- a/drivers/net/ethernet/intel/e1000e/defines.h +++ b/drivers/net/ethernet/intel/e1000e/defines.h @@ -527,6 +527,13 @@ #define E1000_RXCW_C 0x2000/* Receive config */ #define E1000_RXCW_SYNCH

Re: [PATCH v2 3/4] Add support for driver cross-timestamp to PTP_SYS_OFFSET ioctl

() callback provided by the driver. The cross-timestamp is best effort where the latency between the capture of system time (getnstimeofday()) and the device time (driver callback) may be significant. Acked-by: Richard Cochran richardcoch...@gmail.com -- To unsubscribe from this list: send

Re: [net-next 01/14] clarify implementation of ethtool's get_ts_info op

. In addition, update the header for ethtool_ts_info to specify that drivers ought to only report the filters they support without upscaling in this manner. Acked-by: Richard Cochran richardcoch...@gmail.com (for this patch and the other get_ts_info patches) -- To unsubscribe from this list: send the line

Re: [PATCH net-next] sock: don't enable netstamp for af_unix sockets

On Mon, Oct 26, 2015 at 02:32:59PM +0100, Hannes Frederic Sowa wrote: > On Mon, Oct 26, 2015, at 14:19, Richard Cochran wrote: > > On Mon, Oct 26, 2015 at 01:51:37PM +0100, Hannes Frederic Sowa wrote: > > > netstamp_needed is toggled for all socket families if they request

Re: [PATCH net-next] sock: don't enable netstamp for af_unix sockets

On Mon, Oct 26, 2015 at 01:51:37PM +0100, Hannes Frederic Sowa wrote: > netstamp_needed is toggled for all socket families if they request > timestamping. But some protocols don't need the lower-layer timestamping > code at all. This patch starts disabling it for af-unix. What problem is this

Re: [PATCH net-next 0/5] dp83640 driver fixes

On Mon, Nov 02, 2015 at 03:13:16PM -0500, David Miller wrote: > Looks like Richard wants changes to patch #1. Yes, please update the description and use a macro for the offset. Other than that, the series looks ok to me. Thanks, Richard -- To unsubscribe from this list: send the line

Re: [PATCH v2 net-next 0/5] dp83640 driver fixes

On Tue, Nov 03, 2015 at 09:34:03AM +0100, Stefan Sørensen wrote: > This series fixes a number of minor bugs in the dp83640 driver. For the series, Acked-by: Richard Cochran <richardcoch...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe netdev" in th

Re: [PATCH net-next 3/5] dp83640: Prune rx timestamp list before reading from it

> packets with the same sequence number after a rollover. > > Signed-off-by: Stefan Sørensen <stefan.soren...@spectralink.com> Acked-by: Richard Cochran <richardcoch...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a m

Re: [PATCH net-next 1/5] dp83640: Include hash in timestamp/packet matching

On Fri, Oct 30, 2015 at 01:14:00PM +0100, Stefan Sørensen wrote: > Only using the message type and sequence id for matching timestamps with > packets is error prone, particularly if packets can be reordered. Fix by > extending the check to include the hash of bytes 20-29 (source id in PTPv2) >

Re: [PATCH net-next 2/5] dp83640: Delay scheduled work.

On Fri, Oct 30, 2015 at 01:14:01PM +0100, Stefan Sørensen wrote: > Currently rx_timestamp_work reschedules itself as a regular workqueue item, > effectively causing it run constantly as long as there are packets left in > the queue. Fix by using delayed workqueue items, limiting it to run only >

Re: [1/1] stmmac: Correctly report PTP capabilities.

<pr...@electromag.com.au> Thanks for catching this bug. Acked-by: Richard Cochran <richardcoch...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: AF_PACKET mmap() v4...

On Thu, Nov 05, 2015 at 12:04:14AM -0500, David Miller wrote: > So I want everyone to think about whether there are any other changes > we might want to make given that we have to make a v4 anyways. One thing I would like to see is a field for a desired transmit time. Time based scheduling is a

Re: [PATCH net-next 4/5] ptp: Change ptp_class to a proper bitmask

Stefan Sørensen <stefan.soren...@spectralink.com> Acked-by: Richard Cochran <richardcoch...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next 5/5] dp83640: Only wait for timestamps for packets with timestamping enabled.

t; > Signed-off-by: Stefan Sørensen <stefan.soren...@spectralink.com> Acked-by: Richard Cochran <richardcoch...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next 2/5] dp83640: Delay scheduled work.

he timestamp never arrives, by these packets are properly not > very useful to the application anyway. Ok, thanks for the explanation. I mixed this up with another out of tree driver that I was hacking recently. Acked-by: Richard Cochran <richardcoch...@gmail.com> -- To unsubscribe from thi

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Wed, Oct 14, 2015 at 04:22:03PM +0200, Thomas Gleixner wrote: > It's not only the DSP. There is a bunch of usre space software > involved as well. Care to think about the full picture and not just > about some randomly chosen single problem out of the full problem > space. I would surely like

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Wed, Oct 14, 2015 at 09:21:42AM +0200, Thomas Gleixner wrote: > The firmware gives you an ART/audio timestamp pair. The firmware does > neither know about system time nor about PTP time. > > So we have to do correlation in software. Ok, so give me the ART/audio and two recent ART/ptp times*

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Mon, Oct 19, 2015 at 05:36:56PM -0700, John Stultz wrote: > If we're only tracking 4ms of history, how does this solution > measurably improve the error over using the timestamps to generate > MONOTONIC_RAW clock deltas (which doesn't require keeping any history) > and using

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Tue, Oct 20, 2015 at 12:48:03PM +0200, Thomas Gleixner wrote: > On Tue, 20 Oct 2015, Richard Cochran wrote: > > > On Mon, Oct 19, 2015 at 05:36:56PM -0700, John Stultz wrote: > > > If we're only tracking 4ms of history, how does this solution > > > measurabl

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Tue, Oct 20, 2015 at 09:11:21PM +0200, Thomas Gleixner wrote: > Darn, we don't want to have that kind of sampling in every driver > which has this kind of problem even if it looks like the simpler > choice for this particular use case. This is going to be something > which next generation chips

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Tue, Oct 20, 2015 at 01:51:13PM +0200, Richard Cochran wrote: > You can, in fact, achieve "proper" correlation by sampling. As John > said, the question is whether the method in the patch set "measurably > improves the error" over using another, simpler method. H

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Wed, Oct 14, 2015 at 07:34:03PM -0700, Christopher Hall wrote: > I hope this is helpful. Thanks. So the DSP does not produce or consume system time stamps. Fine. Still I fail to understand why you need the system time. Thomas seems to say that there are *other* applications that will want to

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Wed, Oct 14, 2015 at 06:57:33PM -0700, Christopher Hall wrote: > >>+#define SHADOW_HISTORY_DEPTH 7 > > > >And that number is 7 because? > > Due to power of 2 it will be 8 instead. As above the useful history is 8-2*1 > ms (1 ms is the minimum jiffy length). Array size 4 would not be enough >

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Tue, Oct 13, 2015 at 09:51:02AM +0200, Thomas Gleixner wrote: > > You are restricting the problem space to this particular use > case. There are other use cases where PTP is not available or not the > relevant reference, but you still want to correlate time domains to > ART. They may well be

Re: [PATCH v4 3/4] Add PTP_SYS_OFFSET_PRECISE for driver crosstimestamping

On Mon, Oct 12, 2015 at 11:45:21AM -0700, Christopher S. Hall wrote: > > +struct ptp_sys_offset_precise { > + unsigned int rsv[4];/* Reserved for future use. */ > + struct ptp_clock_time dev; > + struct ptp_clock_time sys; > +}; > + Please put the reserved field at the bottom.

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

Now that I am starting to understand what this code is trying to achieve... On Mon, Oct 12, 2015 at 11:45:19AM -0700, Christopher S. Hall wrote: > The modification to the original patch accomodates these > slow devices by adding the option of providing an ART value outside > of the retry loop and

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Tue, Oct 13, 2015 at 09:15:51PM +0200, Thomas Gleixner wrote: > That's not working. The firmware is not going to change, no matter > what. Can we at least have a explanation of how the firmware operates? How are (ART,sys) pairs are generated, and how they are supposed to get into the DSP?

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Mon, Oct 12, 2015 at 11:45:19AM -0700, Christopher S. Hall wrote: > Another representative use case of time sync and the correlated > clocksource (in addition to PTP noted above) is PTP synchronized > audio. The added explanations of the audio use case do help. However, you did not address my

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Mon, Oct 12, 2015 at 11:45:19AM -0700, Christopher S. Hall wrote: > +int get_correlated_timestamp(struct correlated_ts *crt, > + struct correlated_cs *crs) > +{ > + struct timekeeper *tk = _core.timekeeper; > + unsigned long seq; > + cycles_t cycles,

Re: [PATCH v2 1/1] Added additional callback to ptp_clock_info:

On Mon, Jul 06, 2015 at 03:44:58PM -0500, Josh Cartwright wrote: It's difficult to make too many judgements without seeing how a driver might implement this; is there another patchset that shows how a driver implements this? The interface is certainly clear enough to me. The details of

Re: [PATCH v3] Add support for driver cross-timestamp to PTP_SYS_OFFSET ioctl

() callback provided by the driver. The cross-timestamp is best effort where the latency between the capture of system time (getnstimeofday()) and the device time (driver callback) may be significant. The interface looks okay to me. Now all we need is a user of it... Acked-by: Richard Cochran

Re: [PATCH v2 1/1] Added additional callback to ptp_clock_info:

On Wed, Jul 08, 2015 at 07:17:37AM -0500, Josh Cartwright wrote: It's unusual to see interfaces added like this without also seeing users at the same time to see how the pieces fit together. Should I have assumed this was a PATCH RFC for just the API? Chris, any idea when we might see a

[PATCH net-next] net: igb: implement high frequency periodic output signals

to the target time for longer periods. Signed-off-by: Richard Cochran richardcoch...@gmail.com --- drivers/net/ethernet/intel/igb/e1000_regs.h | 2 + drivers/net/ethernet/intel/igb/igb_ptp.c| 72 + 2 files changed, 54 insertions(+), 20 deletions(-) diff --git a/drivers/net

Re: [PATCH v3 3/4] Add support for driver cross-timestamp to PTP_SYS_OFFSET ioctl

On Mon, Aug 24, 2015 at 08:16:51PM +, Hall, Christopher S wrote: This means: remove code changes from the PTP_SYS_OFFSET ioctl and call getsynctime64() from a new ioctl PTP_SYS_OFFSET_PRECISE. Right? Yes. And use the same type (struct ptp_sys_offset) for the new ioctl? Or should a

Re: [PATCH v3 1/4] Add correlated clocksource deriving system time from an auxiliary clocksource

On Fri, Sep 04, 2015 at 05:10:21PM +0200, Peter Zijlstra wrote: > I think what they're getting at is asking if there's a rate limit to > time adjustments, without that, saving the last n transition points will > still not cover any given length of history. As if the ntp code isn't complex enough

Re: [PATCH v3 1/4] Add correlated clocksource deriving system time from an auxiliary clocksource

On Fri, Sep 04, 2015 at 03:02:19PM +0200, Thomas Gleixner wrote: > No. This function is explicitely for the precise timestamp usecase, > which is required by PTP and other sane use cases. Right. The audio department only needs to know the (ART, ptp) offset. The kernel and user space never need

Re: [PATCH v3 1/4] Add correlated clocksource deriving system time from an auxiliary clocksource

On Thu, Sep 03, 2015 at 11:20:37PM +, Hall, Christopher S wrote: > In addition to the network interface, ART will be used in the audio interface > as well. > We need to support the case where an audio co-processor will control the > audio device. > In this case, the get_ts() function

Re: [PATCH 02/12] net: stmmac: avoid using timespec

64() instead. > > Because of hardware limitations, there is still an overflow > in year 2106, which we cannot really avoid, but this documents > the overflow. > > Signed-off-by: Arnd Bergmann <a...@arndb.de> Acked-by: Richard Cochran <richardcoch...@gmail.com> -- To

Re: [PATCH 01/12] net: fec: avoid timespec use

ns_to_timespec64 can still be better as the > implementation can be hand-optimized in the future. > > Signed-off-by: Arnd Bergmann <a...@arndb.de> Acked-by: Richard Cochran <richardcoch...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe net

Re: [PATCH 03/12] net: igb: avoid using timespec

Arnd As author of these snippets, I went ahead and reviewed. I have one comment, below. Reviewed-by: Richard Cochran <richardcoch...@gmail.com> On Wed, Sep 30, 2015 at 01:26:33PM +0200, Arnd Bergmann wrote: > diff --git a/drivers/net/ethernet/intel/igb/igb_ptp.c > b/drivers/net/et

Re: [PATCH 03/12] net: igb: avoid using timespec

On Thu, Oct 01, 2015 at 10:01:57PM +0200, Arnd Bergmann wrote: > I tried to use this pattern whenever I convert the 64-bit 'long long' > tv_sec member of 'struct timespec64' into a 32-bit number, to annotate > the loss of range. Sounds reasonable to me. > I have thought about defining separate

Re: [PATCH] testptp: Silence compiler warnings on ppc64

o > "long long" on ppc64, too. > > Signed-off-by: Thomas Huth <th...@redhat.com> Acked-by: Richard Cochran <richardcoch...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] y2038 conversion for ntp/pps and sfc driver

ubsystems, so I'm also looking for the right person > to merge them. > > Please review. (Series was "lightly reviewed" ;) Acked-by: Richard Cochran <richardcoch...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a

Re: [PATCH 4/6] net: freescale: Fix module autoload for OF platform driver

ubject line should have been: net: gianfar_ptp: ... Acked-by: Richard Cochran <richardcoch...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 2/3] net: macb: Add support for 1588 for Zynq Ultrascale+ MPSoC

On Mon, Sep 21, 2015 at 11:19:32PM +0530, Harini Katakam wrote: > Ping 1) trim your replies 2) put the PTP maintainer on PTP patches for review Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More

Re: [PATCH v3] net/macb: add support for resetting PHY using GPIO

On Wed, Dec 16, 2015 at 07:31:30PM +0100, Gregory CLEMENT wrote: > +Optional properties for PHY child node: > +- reset-gpios : Should specify the gpio for phy reset reset-gpios plural or reset-gpio singular? > + > Examples: > > macb0: ethernet@fffc4000 { > @@ -29,4 +32,8 @@ Examples: >

Re: [PATCH net-next 2/2] net/mlx5_en: Add HW timestamping (TS) support

On Wed, Dec 16, 2015 at 06:46:34PM +0200, Saeed Mahameed wrote: > From: Eran Ben Elisha > > Add support for enable/disable HW timestamping for incoming and/or > outgoing packets. It adds and initializes all structs and callbacks > needed by kernel TS API. To enable/disable

Re: [PATCH net-next V1 3/4] net/mlx5e: Add HW timestamping (TS) support

On Thu, Dec 17, 2015 at 02:35:34PM +0200, Saeed Mahameed wrote: > @@ -63,6 +65,7 @@ > #define MLX5E_TX_CQ_POLL_BUDGET128 > #define MLX5E_UPDATE_STATS_INTERVAL200 /* msecs */ > #define MLX5E_SQ_BF_BUDGET 16 > +#define MLX5E_SERVICE_TASK_DELAY (HZ / 4) Hm... >

Re: [PATCH net-next V1 3/4] net/mlx5e: Add HW timestamping (TS) support

On Thu, Dec 17, 2015 at 02:35:34PM +0200, Saeed Mahameed wrote: > +static int mlx5e_get_ts_info(struct net_device *dev, > + struct ethtool_ts_info *info) > +{ > + struct mlx5e_priv *priv = netdev_priv(dev); > + int ret; > + > + ret = ethtool_op_get_ts_info(dev,

Re: [PATCH net-next V1 4/4] net/mlx5e: Add PTP Hardware Clock (PHC) support

On Thu, Dec 17, 2015 at 02:35:35PM +0200, Saeed Mahameed wrote: > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c > b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c > index 8e86f2c..b2e5014 100644 > --- a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c > +++

Re: [RFC v5 5/6] Add PTP_SYS_OFFSET_PRECISE for driver crosstimestamping

On Mon, Jan 04, 2016 at 04:45:22AM -0800, Christopher S. Hall wrote: > @@ -138,6 +142,7 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, > unsigned long arg) > caps.n_per_out = ptp->info->n_per_out; > caps.pps = ptp->info->pps; > caps.n_pins =

Re: [PATCH net-next V3 3/4] net/mlx5e: Add HW timestamping (TS) support

n, add a service task to catch internal clock overflow, to make > sure timestamping is accurate. > > Signed-off-by: Eran Ben Elisha <era...@mellanox.com> > Signed-off-by: Saeed Mahameed <sae...@mellanox.com> Acked-by: Richard Cochran <richardcoch...@gmail.com> -- To unsub

Re: [PATCH net-next V3 0/4] Introduce mlx5 ethernet timestamping

On Mon, Jan 04, 2016 at 04:47:03PM -0500, David Miller wrote: > Richard, please review this series. It looks fine to me now, and I acked the timestamping/phc bits. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to

Re: [PATCH net-next V3 4/4] net/mlx5e: Add PTP Hardware Clock (PHC) support

et/) on a Mellanox > ConnectX-4 card. > > Signed-off-by: Eran Ben Elisha <era...@mellanox.com> > Cc: Richard Cochran <richardcoch...@gmail.com> > Signed-off-by: Saeed Mahameed <sae...@mellanox.com> Acked-by: Richard Cochran <richardcoch...@gmail.com> -- To unsubscribe

Re: [PATCH net-next V2 3/4] net/mlx5e: Add HW timestamping (TS) support

On Mon, Dec 21, 2015 at 04:35:23PM +0200, Saeed Mahameed wrote: > think of a case where: > CPU1: is just about to call > "schedule_delayed_work(>overflow_work, > tstamp->overflow_period);" > CPU2: cancel_delayed_work > > In this case cancel_dalyed_work_sync (CPU2) will wait for CPU1 to > complete

Re: [PATCH net-next V2 4/4] net/mlx5e: Add PTP Hardware Clock (PHC) support

et/) on a Mellanox > ConnectX-4 card. > > Signed-off-by: Eran Ben Elisha <era...@mellanox.com> > Cc: Richard Cochran <richardcoch...@gmail.com> > Signed-off-by: Saeed Mahameed <sae...@mellanox.com> Acked-by: Richard Cochran <richardcoch...@gmail.com> -- To unsubscribe

Re: [PATCH net-next V2 3/4] net/mlx5e: Add HW timestamping (TS) support

On Sun, Dec 20, 2015 at 11:46:30PM +0200, Saeed Mahameed wrote: > +/* Should run once every mlx5e_tstamp->overflow_period */ > +static void mlx5e_timestamp_overflow(struct work_struct *work) > +{ > + struct delayed_work *dwork = to_delayed_work(work); > + struct mlx5e_tstamp *tstamp =

Re: [PATCH net-next V1 3/4] net/mlx5e: Add HW timestamping (TS) support

On Sun, Dec 20, 2015 at 03:08:18PM +0200, Saeed Mahameed wrote: > Agree, but what will happen if the calculated period is too rapid ? > shouldn't we have some kind of minimum ? If the period is shorter than you can handle, then the clock will overflow and is therefore unusable. Thanks, Richard

Re: [PATCH net-next V2 3/4] net/mlx5e: Add HW timestamping (TS) support

On Tue, Dec 22, 2015 at 12:00:52PM +0200, Saeed Mahameed wrote: > Ok, but what will happen if somehow tstamp->overflow_period is zero ? > the work will run too rapidly. > don't we need to have protection against such case. Why not return an error in that case? Thanks, Richard -- To unsubscribe

Re: [PATCH 18/28] ptp: pch: allow build on MIPS platforms

On Mon, Nov 30, 2015 at 04:21:43PM +, Paul Burton wrote: > Allow the ptp_pch driver to be built on MIPS platforms in preparation > for use on the MIPS Boston board. > > Signed-off-by: Paul Burton <paul.bur...@imgtec.com> Acked-by: Richard Cochran <richardcoch...@gmail.c

Re: [RFC PATCH 14/16] net: dsa: Add new binding implementation

On Fri, May 27, 2016 at 02:29:04PM -0700, Florian Fainelli wrote: > We need to set priorities here, and the highest priority is to get these > patches accepted to enable more people to utilize DSA, so once we have > more devices we can get to a longer term plan to get a better > abstraction model

Re: [very-RFC 0/8] TSN driver for the kernel

On Tue, Jun 14, 2016 at 11:30:00AM +0200, Henrik Austad wrote: > So loop data from kernel -> userspace -> kernelspace and finally back to > userspace and the media application? Huh? I wonder where you got that idea. Let me show an example of what I mean. void listener() {

Re: [very-RFC 0/8] TSN driver for the kernel

On Tue, Jun 14, 2016 at 12:18:44PM +0100, One Thousand Gnomes wrote: > On Mon, 13 Jun 2016 21:51:36 +0200 > Richard Cochran <richardcoch...@gmail.com> wrote: > > > > Actually, we already have support for tunable clock-like HW elements, > > namely the dynamic p

Re: [very-RFC 0/8] TSN driver for the kernel

On Tue, Jun 14, 2016 at 10:38:10PM +0200, Henrik Austad wrote: > Where is your media-application in this? Um, that *is* a media application. It plays music on the sound card. > You only loop the audio from > network to the dsp, is the media-application attached to the dsp-device? Sorry, I

Re: [very-RFC 0/8] TSN driver for the kernel

On Wed, Jun 15, 2016 at 12:15:24PM +0900, Takashi Sakamoto wrote: > > On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote: > >> I have seen audio PLL/multiplier chips that will take, for example, a > >> 10 kHz input and produce your 48 kHz media clock. With

Re: [very-RFC 0/8] TSN driver for the kernel

On Tue, Jun 14, 2016 at 10:38:10PM +0200, Henrik Austad wrote: > Whereas I want to do > > aplay some_song.wav Can you please explain how your patches accomplish this? Thanks, Richard

Re: [very-RFC 7/8] AVB ALSA - Add ALSA shim for TSN

On Wed, Jun 15, 2016 at 02:13:03PM +0200, Henrik Austad wrote: > On Wed, Jun 15, 2016 at 01:49:08PM +0200, Richard Cochran wrote: > And how would v4l2 benefit from this being in alsalib? Should we require > both V4L and ALSA to implement the same, or should we place it in a common

Re: [very-RFC 7/8] AVB ALSA - Add ALSA shim for TSN

Now that I understand better... On Sun, Jun 12, 2016 at 01:01:35AM +0200, Henrik Austad wrote: > Userspace is supposed to reserve bandwidth, find StreamID etc. > > To use as a Talker: > > mkdir /config/tsn/test/eth0/talker > cd /config/tsn/test/eth0/talker > echo 65535 > buffer_size > echo

Re: [very-RFC 0/8] TSN driver for the kernel

On Wed, Jun 15, 2016 at 09:04:41AM +0200, Richard Cochran wrote: > On Tue, Jun 14, 2016 at 10:38:10PM +0200, Henrik Austad wrote: > > Whereas I want to do > > > > aplay some_song.wav > > Can you please explain how your patches accomplish this? Never mind. Looking b

Re: [very-RFC 0/8] TSN driver for the kernel

On Mon, Jun 13, 2016 at 03:00:59PM +0200, Henrik Austad wrote: > On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote: > > People have been asking me about TSN and Linux, and we've made some > > thoughts about it. The interest is there, and so I am glad to see

Re: [very-RFC 0/8] TSN driver for the kernel

On Mon, Jun 13, 2016 at 03:00:59PM +0200, Henrik Austad wrote: > On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote: > > Which driver is that? > > drivers/net/ethernet/renesas/ That driver is merely a PTP capable MAC driver, nothing more. Although AVB is in

Re: [very-RFC 0/8] TSN driver for the kernel

On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote: > 3. ALSA support for tunable AD/DA clocks. The rate of the Listener's >DA clock must match that of the Talker and the other Listeners. >Either you adjust it in HW using a VCO or similar, or you do >adaptive

Re: [very-RFC 0/8] TSN driver for the kernel

Henrik, On Sun, Jun 12, 2016 at 01:01:28AM +0200, Henrik Austad wrote: > There are at least one AVB-driver (the AV-part of TSN) in the kernel > already, Which driver is that? > however this driver aims to solve a wider scope as TSN can do > much more than just audio. A very basic ALSA-driver is

Re: [patch] ptp: oops in ptp_ioctl()

On Thu, May 26, 2016 at 09:46:22AM +0300, Dan Carpenter wrote: > If we pass ERR_PTR(-EFAULT) to kfree() then it's going to oops. Thanks for catching this. Acked-by: Richard Cochran <richardcoch...@gmail.com>

Re: [PATCH] net: tilegx: use correct timespec64 type

bit machines. > > However, using 'struct timespec64' directly is obviously the right > thing to do, and will help us remove 'struct timespec' in the future. > > Signed-off-by: Arnd Bergmann <a...@arndb.de> > Fixes: b9acf24f779c ("ptp: tilegx: convert to the 64 bit get/

Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

On Mon, Jun 20, 2016 at 01:08:27PM +0200, Pierre-Louis Bossart wrote: > The ALSA API provides support for 'audio' timestamps (playback/capture rate > defined by audio subsystem) and 'system' timestamps (typically linked to > TSC/ART) with one option to take synchronized timestamps should the

  1   2   3   4   5   >