On Fri, Dec 14, 2018 at 08:18:26AM +0100, Greg Kroah-Hartman wrote:
> On Mon, Nov 19, 2018 at 12:27:21PM +0100, Henrik Austad wrote:
> > On Fri, Nov 09, 2018 at 11:35:31AM +0100, Henrik Austad wrote:
> > > On Fri, Nov 09, 2018 at 11:07:28AM +0100, Henrik Austad wrote:
> >
On Fri, Nov 09, 2018 at 11:35:31AM +0100, Henrik Austad wrote:
> On Fri, Nov 09, 2018 at 11:07:28AM +0100, Henrik Austad wrote:
> > From: Henrik Austad
> >
> > Short story:
>
> Sorry for the spam, it looks like I was not very specific in /which/
> versi
On Fri, Nov 09, 2018 at 11:35:31AM +0100, Henrik Austad wrote:
> On Fri, Nov 09, 2018 at 11:07:28AM +0100, Henrik Austad wrote:
> > From: Henrik Austad
> >
> > Short story:
>
> Sorry for the spam, it looks like I was not very specific in /which/
> versi
On Fri, Nov 09, 2018 at 11:07:28AM +0100, Henrik Austad wrote:
> From: Henrik Austad
>
> Short story:
Sorry for the spam, it looks like I was not very specific in /which/
version I targeted this to, as well as not providing a full Cc-list for the
cover-letter.
The series is
On Fri, Nov 09, 2018 at 11:07:28AM +0100, Henrik Austad wrote:
> From: Henrik Austad
>
> Short story:
Sorry for the spam, it looks like I was not very specific in /which/
version I targeted this to, as well as not providing a full Cc-list for the
cover-letter.
The series is
icios.com
Cc: dvh...@infradead.org
Cc: bris...@redhat.com
Link: http://lkml.kernel.org/r/20170322104151.751993...@infradead.org
Signed-off-by: Thomas Gleixner
Tested-by: Henrik Austad
---
kernel/futex.c | 165 +
1 file changed, 132 inser
From: Peter Zijlstra
commit bf92cf3a5100f5a0d5f9834787b130159397cb22 upstream.
Add a put_pit_state() as counterpart for get_pi_state() so the refcounting
becomes consistent.
Signed-off-by: Peter Zijlstra (Intel)
Cc: juri.le...@arm.com
Cc: bige...@linutronix.de
Cc: xlp...@redhat.com
Cc:
From: Thomas Gleixner
commit b4abf91047cf054f203dcfac97e1038388826937 upstream.
Sasha reported a lockdep splat about a potential deadlock between RCU boosting
rtmutex and the posix timer it_lock.
CPU0CPU1
rtmutex_lock(>rt_mutex)
-by: Henrik Austad
---
kernel/futex.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index bb87324..9e92f12 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1284,8 +1284,7 @@ static void mark_wake_futex(struct wake_q_head *wake_q,
struct
icios.com
Cc: dvh...@infradead.org
Cc: bris...@redhat.com
Link: http://lkml.kernel.org/r/20170322104151.751993...@infradead.org
Signed-off-by: Thomas Gleixner
Tested-by: Henrik Austad
---
kernel/futex.c | 165 +
1 file changed, 132 inser
From: Peter Zijlstra
commit bf92cf3a5100f5a0d5f9834787b130159397cb22 upstream.
Add a put_pit_state() as counterpart for get_pi_state() so the refcounting
becomes consistent.
Signed-off-by: Peter Zijlstra (Intel)
Cc: juri.le...@arm.com
Cc: bige...@linutronix.de
Cc: xlp...@redhat.com
Cc:
From: Thomas Gleixner
commit b4abf91047cf054f203dcfac97e1038388826937 upstream.
Sasha reported a lockdep splat about a potential deadlock between RCU boosting
rtmutex and the posix timer it_lock.
CPU0CPU1
rtmutex_lock(>rt_mutex)
-by: Henrik Austad
---
kernel/futex.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index bb87324..9e92f12 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1284,8 +1284,7 @@ static void mark_wake_futex(struct wake_q_head *wake_q,
struct
From: Henrik Austad
Short story:
The following patches are needed on a 4.4 kernel to avoid
Oops in the scheduler when a sched_rr and sched_deadline task contends
on the same futex (with PI).
Longer story:
On one of our arm64 systems, we occasionally crash with an Oops in the
scheduler
From: Henrik Austad
Short story:
The following patches are needed on a 4.4 kernel to avoid
Oops in the scheduler when a sched_rr and sched_deadline task contends
on the same futex (with PI).
Longer story:
On one of our arm64 systems, we occasionally crash with an Oops in the
scheduler
Cc: Peter Zijlstra
Cc: Darren Hart
Cc: Davidlohr Bueso
Cc: bhuvanesh_surach...@mentor.com
Cc: Andy Lowe
Link: http://lkml.kernel.org/r/20151219200607.259636...@linutronix.de
Signed-off-by: Thomas Gleixner
Tested-by: Henrik Austad
---
kernel/futex.c | 17 ++---
1 file changed, 10
Cc: Peter Zijlstra
Cc: Darren Hart
Cc: Davidlohr Bueso
Cc: bhuvanesh_surach...@mentor.com
Cc: Andy Lowe
Link: http://lkml.kernel.org/r/20151219200607.259636...@linutronix.de
Signed-off-by: Thomas Gleixner
Tested-by: Henrik Austad
---
kernel/futex.c | 17 ++---
1 file changed, 10
...@goodmis.org
Cc: mathieu.desnoy...@efficios.com
Cc: jdesfos...@efficios.com
Cc: dvh...@infradead.org
Cc: bris...@redhat.com
Link: http://lkml.kernel.org/r/20170322104151.950039...@infradead.org
Signed-off-by: Thomas Gleixner
Tested-by: Henrik Austad
---
kernel/futex.c | 5
...@goodmis.org
Cc: mathieu.desnoy...@efficios.com
Cc: jdesfos...@efficios.com
Cc: dvh...@infradead.org
Cc: bris...@redhat.com
Link: http://lkml.kernel.org/r/20170322104151.950039...@infradead.org
Signed-off-by: Thomas Gleixner
Tested-by: Henrik Austad
---
kernel/futex.c | 5
c: juri.le...@arm.com
Cc: bige...@linutronix.de
Cc: mathieu.desnoy...@efficios.com
Cc: jdesfos...@efficios.com
Cc: bris...@redhat.com
Link: http://lkml.kernel.org/r/20170323150216.110065...@infradead.org
Signed-off-by: Thomas Gleixner
Tested-by: Henrik Austad
---
kernel/futex.c | 5 +-
nel.org/r/20170322104151.850383...@infradead.org
Signed-off-by: Thomas Gleixner
Tested-by: Henrik Austad
---
kernel/futex.c | 50 ++
1 file changed, 14 insertions(+), 36 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index 9d7d462..91acb65 100644
---
From: Peter Zijlstra
commit 5293c2efda37775346885c7e924d4ef7018ea60b upstream.
Part of what makes futex_unlock_pi() intricate is that
rt_mutex_futex_unlock() -> rt_mutex_slowunlock() can drop
rt_mutex::wait_lock.
This means it cannot rely on the atomicy of wait_lock, which would be
preferred
From: Peter Zijlstra
commit 16ffa12d742534d4ff73e8b3a4e81c1de39196f0 upstream.
There's a number of 'interesting' problems, all caused by holding
hb->lock while doing the rt_mutex_unlock() equivalient.
Notably:
- a PI inversion on hb->lock; and,
- a SCHED_DEADLINE crash because of pointer
c: juri.le...@arm.com
Cc: bige...@linutronix.de
Cc: mathieu.desnoy...@efficios.com
Cc: jdesfos...@efficios.com
Cc: bris...@redhat.com
Link: http://lkml.kernel.org/r/20170323150216.110065...@infradead.org
Signed-off-by: Thomas Gleixner
Tested-by: Henrik Austad
---
kernel/futex.c | 5 +-
nel.org/r/20170322104151.850383...@infradead.org
Signed-off-by: Thomas Gleixner
Tested-by: Henrik Austad
---
kernel/futex.c | 50 ++
1 file changed, 14 insertions(+), 36 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index 9d7d462..91acb65 100644
---
From: Peter Zijlstra
commit 5293c2efda37775346885c7e924d4ef7018ea60b upstream.
Part of what makes futex_unlock_pi() intricate is that
rt_mutex_futex_unlock() -> rt_mutex_slowunlock() can drop
rt_mutex::wait_lock.
This means it cannot rely on the atomicy of wait_lock, which would be
preferred
From: Peter Zijlstra
commit 16ffa12d742534d4ff73e8b3a4e81c1de39196f0 upstream.
There's a number of 'interesting' problems, all caused by holding
hb->lock while doing the rt_mutex_unlock() equivalient.
Notably:
- a PI inversion on hb->lock; and,
- a SCHED_DEADLINE crash because of pointer
oy...@efficios.com
Cc: jdesfos...@efficios.com
Cc: dvh...@infradead.org
Cc: bris...@redhat.com
Link: http://lkml.kernel.org/r/20170322104152.161341...@infradead.org
Signed-off-by: Thomas Gleixner
Tested-by: Henrik Austad
---
kernel/futex.c | 30 +
ker
Cc: bris...@redhat.com
Link: http://lkml.kernel.org/r/20170322104152.112378...@infradead.org
Signed-off-by: Thomas Gleixner
Tested-by: Henrik Austad
---
kernel/futex.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/kernel/futex.c b/kernel/fute
oy...@efficios.com
Cc: jdesfos...@efficios.com
Cc: dvh...@infradead.org
Cc: bris...@redhat.com
Link: http://lkml.kernel.org/r/20170322104152.161341...@infradead.org
Signed-off-by: Thomas Gleixner
Tested-by: Henrik Austad
---
kernel/futex.c | 30 +
ker
Cc: bris...@redhat.com
Link: http://lkml.kernel.org/r/20170322104152.112378...@infradead.org
Signed-off-by: Thomas Gleixner
Tested-by: Henrik Austad
---
kernel/futex.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/kernel/futex.c b/kernel/fute
From: Xunlei Pang
commit e96a7705e7d3fef96aec9b590c63b2f6f7d2ba22 upstream.
A crash happened while I was playing with deadline PI rtmutex.
BUG: unable to handle kernel NULL pointer dereference at 0018
IP: [] rt_mutex_get_top_task+0x1f/0x30
PGD 232a75067 PUD 230947067
at.com
Cc: rost...@goodmis.org
Cc: mathieu.desnoy...@efficios.com
Cc: jdesfos...@efficios.com
Cc: dvh...@infradead.org
Cc: bris...@redhat.com
Link: http://lkml.kernel.org/r/20170322104152.001659...@infradead.org
Signed-off-by: Thomas Gleixner
Tested-by: Henrik Austad
---
kernel/f
redhat.com
Link: http://lkml.kernel.org/r/20170322104152.062785...@infradead.org
Signed-off-by: Thomas Gleixner
Tested-by: Henrik Austad
---
kernel/futex.c | 77 +
kernel/locking/rtmutex.c| 26 --
kernel/locking/rtmutex_c
at.com
Cc: rost...@goodmis.org
Cc: mathieu.desnoy...@efficios.com
Cc: jdesfos...@efficios.com
Cc: dvh...@infradead.org
Cc: bris...@redhat.com
Link: http://lkml.kernel.org/r/20170322104152.001659...@infradead.org
Signed-off-by: Thomas Gleixner
Tested-by: Henrik Austad
---
kernel/f
redhat.com
Link: http://lkml.kernel.org/r/20170322104152.062785...@infradead.org
Signed-off-by: Thomas Gleixner
Tested-by: Henrik Austad
---
kernel/futex.c | 77 +
kernel/locking/rtmutex.c| 26 --
kernel/locking/rtmutex_c
From: Xunlei Pang
commit e96a7705e7d3fef96aec9b590c63b2f6f7d2ba22 upstream.
A crash happened while I was playing with deadline PI rtmutex.
BUG: unable to handle kernel NULL pointer dereference at 0018
IP: [] rt_mutex_get_top_task+0x1f/0x30
PGD 232a75067 PUD 230947067
: xlp...@redhat.com
Cc: rost...@goodmis.org
Cc: mathieu.desnoy...@efficios.com
Cc: jdesfos...@efficios.com
Cc: dvh...@infradead.org
Cc: bris...@redhat.com
Link: http://lkml.kernel.org/r/20170322104151.554710...@infradead.org
Signed-off-by: Thomas Gleixner
Tested-by: Henrik Austad
---
kernel/futex.c
: jdesfos...@efficios.com
Cc: dvh...@infradead.org
Cc: bris...@redhat.com
Link: http://lkml.kernel.org/r/20170322104151.652692...@infradead.org
Signed-off-by: Thomas Gleixner
Conflicts:
kernel/locking/rtmutex.c (WAKE_Q)
Tested-by: Henrik Austad
---
kernel/locking/rtmutex-debug.c | 9
: xlp...@redhat.com
Cc: rost...@goodmis.org
Cc: mathieu.desnoy...@efficios.com
Cc: jdesfos...@efficios.com
Cc: dvh...@infradead.org
Cc: bris...@redhat.com
Link: http://lkml.kernel.org/r/20170322104151.554710...@infradead.org
Signed-off-by: Thomas Gleixner
Tested-by: Henrik Austad
---
kernel/futex.c
: jdesfos...@efficios.com
Cc: dvh...@infradead.org
Cc: bris...@redhat.com
Link: http://lkml.kernel.org/r/20170322104151.652692...@infradead.org
Signed-off-by: Thomas Gleixner
Conflicts:
kernel/locking/rtmutex.c (WAKE_Q)
Tested-by: Henrik Austad
---
kernel/locking/rtmutex-debug.c | 9
On Tue, Nov 06, 2018 at 02:22:10PM +0100, Peter Zijlstra wrote:
> On Tue, Nov 06, 2018 at 01:47:21PM +0100, Henrik Austad wrote:
> > From: Xunlei Pang
> >
> > On some of our systems, we notice this error popping up on occasion,
> > completely hanging the system.
>
On Tue, Nov 06, 2018 at 02:22:10PM +0100, Peter Zijlstra wrote:
> On Tue, Nov 06, 2018 at 01:47:21PM +0100, Henrik Austad wrote:
> > From: Xunlei Pang
> >
> > On some of our systems, we notice this error popping up on occasion,
> > completely hanging the system.
>
(cherry picked from commit e96a7705e7d3fef96aec9b590c63b2f6f7d2ba22)
Conflicts:
include/linux/sched.h
Backported-and-tested-by: Henrik Austad
Cc: Greg Kroah-Hartman
---
include/linux/init_task.h | 1 +
include/linux/sched.h | 2 ++
include/linux/sched/rt.h | 1 +
kernel/fork.c
(cherry picked from commit e96a7705e7d3fef96aec9b590c63b2f6f7d2ba22)
Conflicts:
include/linux/sched.h
Backported-and-tested-by: Henrik Austad
Cc: Greg Kroah-Hartman
---
include/linux/init_task.h | 1 +
include/linux/sched.h | 2 ++
include/linux/sched/rt.h | 1 +
kernel/fork.c
On Tue, Oct 09, 2018 at 11:24:26AM +0200, Juri Lelli wrote:
> Hi all,
Hi, nice series, I have a lot of details to grok, but I like the idea of PE
> Proxy Execution (also goes under several other names) isn't a new
> concept, it has been mentioned already in the past to this community
> (both in
On Tue, Oct 09, 2018 at 11:24:26AM +0200, Juri Lelli wrote:
> Hi all,
Hi, nice series, I have a lot of details to grok, but I like the idea of PE
> Proxy Execution (also goes under several other names) isn't a new
> concept, it has been mentioned already in the past to this community
> (both in
t;
Cc: Jesus Sanchez-Palencia <jesus.sanchez-palen...@intel.com>
Cc: David S. Miller <da...@davemloft.net>
Signed-off-by: Henrik Austad <haus...@cisco.com>
---
net/core/dev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index fcddccb..d2b20e7 1
d S. Miller
Signed-off-by: Henrik Austad
---
net/core/dev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index fcddccb..d2b20e7 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2040,6 +2040,7 @@ int netdev_txq_to_tc(struct net_device *dev, unsigned int
e much in the way of AVB-support *In* kernel. Sorry about that!
Since then, the iMX7 from NXP has arrived, and this also has HW-support for
TSN, but not in the kernel AFAICT.
So, the next issue I plan to tackle, is how I do buffers, the current
approach where tsn_core allocates memory is on its way out and I'll let the
shim (which means alsa/v4l2) will provide a buffer. Then I'll start looking
at qdisc.
Thanks!
--
Henrik Austad
signature.asc
Description: Digital signature
e much in the way of AVB-support *In* kernel. Sorry about that!
Since then, the iMX7 from NXP has arrived, and this also has HW-support for
TSN, but not in the kernel AFAICT.
So, the next issue I plan to tackle, is how I do buffers, the current
approach where tsn_core allocates memory is on its way out and I'll let the
shim (which means alsa/v4l2) will provide a buffer. Then I'll start looking
at qdisc.
Thanks!
--
Henrik Austad
signature.asc
Description: Digital signature
mpressed video format" and then the shim/tsn_core will ship out the
frames over the network - and then you need to set TSN_CVF as subtype in
each header.
That does not that mean you should do H.264 encode/decode *in* the kernel
Perhaps this is better placed in include/uapi/tsn.h so that userspace and
kernel share the same header?
--
Henrik Austad
signature.asc
Description: PGP signature
mpressed video format" and then the shim/tsn_core will ship out the
frames over the network - and then you need to set TSN_CVF as subtype in
each header.
That does not that mean you should do H.264 encode/decode *in* the kernel
Perhaps this is better placed in include/uapi/tsn.h so that userspace and
kernel share the same header?
--
Henrik Austad
signature.asc
Description: PGP signature
On Fri, Dec 16, 2016 at 01:20:57PM -0500, David Miller wrote:
> From: Greg <gvrose8...@gmail.com>
> Date: Fri, 16 Dec 2016 10:12:44 -0800
>
> > On Fri, 2016-12-16 at 18:59 +0100, hen...@austad.us wrote:
> >> From: Henrik Austad <haus...@cisco.com>
> &g
On Fri, Dec 16, 2016 at 01:20:57PM -0500, David Miller wrote:
> From: Greg
> Date: Fri, 16 Dec 2016 10:12:44 -0800
>
> > On Fri, 2016-12-16 at 18:59 +0100, hen...@austad.us wrote:
> >> From: Henrik Austad
> >>
> >>
> >> The driver is d
On Fri, Dec 09, 2016 at 08:22:05AM +0100, Greg KH wrote:
> On Fri, Dec 09, 2016 at 07:34:04AM +0100, Henrik Austad wrote:
> > Instead of using get_user_pages_fast() and kmap_atomic() when writing
> > to the trace_marker file, just allocate enough space on the ring buffer
> >
On Fri, Dec 09, 2016 at 08:22:05AM +0100, Greg KH wrote:
> On Fri, Dec 09, 2016 at 07:34:04AM +0100, Henrik Austad wrote:
> > Instead of using get_user_pages_fast() and kmap_atomic() when writing
> > to the trace_marker file, just allocate enough space on the ring buffer
> >
t immediately explode on impact. By
definition [2] it must therefore be perfect
2) https://www.spinics.net/lists/kernel/msg2400769.html
2) http://lkml.iu.edu/hypermail/linux/kernel/9804.1/0149.html
Cc: Ingo Molnar <mi...@kernel.org>
Cc: Henrik Austad <hen...@austad.us>
Cc: Peter Zijls
t immediately explode on impact. By
definition [2] it must therefore be perfect
2) https://www.spinics.net/lists/kernel/msg2400769.html
2) http://lkml.iu.edu/hypermail/linux/kernel/9804.1/0149.html
Cc: Ingo Molnar
Cc: Henrik Austad
Cc: Peter Zijlstra
Cc: Steven Rostedt
Cc: sta...@vger.kernel.o
On Thu, Nov 10, 2016 at 01:38:40PM +0100, luca abeni wrote:
> Hi Henrik,
Hi Luca,
> On Thu, 10 Nov 2016 13:21:00 +0100
> Henrik Austad <hen...@austad.us> wrote:
> > On Thu, Nov 10, 2016 at 09:08:07AM +0100, Peter Zijlstra wrote:
> [...]
> > > We define the time
On Thu, Nov 10, 2016 at 01:38:40PM +0100, luca abeni wrote:
> Hi Henrik,
Hi Luca,
> On Thu, 10 Nov 2016 13:21:00 +0100
> Henrik Austad wrote:
> > On Thu, Nov 10, 2016 at 09:08:07AM +0100, Peter Zijlstra wrote:
> [...]
> > > We define the time to fail as:
> &g
On Thu, Nov 10, 2016 at 09:08:07AM +0100, Peter Zijlstra wrote:
>
>
> Add support for single CPU affinity to SCHED_DEADLINE; the supposed reason for
> wanting single CPU affinity is better QoS than provided by G-EDF.
>
> Therefore the aim is to provide harder guarantees, similar to UP, for
On Thu, Nov 10, 2016 at 09:08:07AM +0100, Peter Zijlstra wrote:
>
>
> Add support for single CPU affinity to SCHED_DEADLINE; the supposed reason for
> wanting single CPU affinity is better QoS than provided by G-EDF.
>
> Therefore the aim is to provide harder guarantees, similar to UP, for
On Wed, Oct 19, 2016 at 07:25:10AM -0700, Jesse Brandeburg wrote:
> On Wed, 19 Oct 2016 14:37:59 +0200
> Henrik Austad <hen...@austad.us> wrote:
>
> > The current list of E1000_TXDCTL-registers is incomplete. This adds
> > the missing parts for the Transmit
On Wed, Oct 19, 2016 at 07:25:10AM -0700, Jesse Brandeburg wrote:
> On Wed, 19 Oct 2016 14:37:59 +0200
> Henrik Austad wrote:
>
> > The current list of E1000_TXDCTL-registers is incomplete. This adds
> > the missing parts for the Transmit Descriptor Control
that this was left out in the commit that added support for
82575 Gigabit Ethernet driver 9d5c8243 (igb: PCI-Express 82575 Gigabit
Ethernet driver).
Signed-off-by: Henrik Austad <hen...@austad.us>
Cc: linux-kernel@vger.kernel.org
Cc: Jeff Kirsher <jeffrey.t.kirs...@intel.com>
Cc:
that this was left out in the commit that added support for
82575 Gigabit Ethernet driver 9d5c8243 (igb: PCI-Express 82575 Gigabit
Ethernet driver).
Signed-off-by: Henrik Austad
Cc: linux-kernel@vger.kernel.org
Cc: Jeff Kirsher
Cc: intel-wired-...@lists.osuosl.org
Signed-off-by: Henrik Austad
perhaps use the timestamp
in skb.
Hooking into ktime_get() instead of directly to the PTP-subsystem (if that
is even possible) makes it a lot easier to debug when running this in a VM
as it doesn't *have* to use PTP-time when I'm crashing a new kernel :)
Thanks!
--
Henrik Austad
signature.asc
Description: Digital signature
perhaps use the timestamp
in skb.
Hooking into ktime_get() instead of directly to the PTP-subsystem (if that
is even possible) makes it a lot easier to debug when running this in a VM
as it doesn't *have* to use PTP-time when I'm crashing a new kernel :)
Thanks!
--
Henrik Austad
signature.asc
Description: Digital signature
I will be looking into what to put in the .trigger-handler in
the ALSA shim and experimenting with this to see how it make sense to
connect it from the TSN-stream.
Thanks!
--
Henrik Austad
signature.asc
Description: Digital signature
I will be looking into what to put in the .trigger-handler in
the ALSA shim and experimenting with this to see how it make sense to
connect it from the TSN-stream.
Thanks!
--
Henrik Austad
signature.asc
Description: Digital signature
On Sun, Jun 19, 2016 at 11:46:29AM +0200, Richard Cochran wrote:
> On Sun, Jun 19, 2016 at 12:45:50AM +0200, Henrik Austad wrote:
> > edit: this turned out to be a somewhat lengthy answer. I have tried to
> > shorten it down somewhere. it is getting late and I'm getti
On Sun, Jun 19, 2016 at 11:46:29AM +0200, Richard Cochran wrote:
> On Sun, Jun 19, 2016 at 12:45:50AM +0200, Henrik Austad wrote:
> > edit: this turned out to be a somewhat lengthy answer. I have tried to
> > shorten it down somewhere. it is getting late and I'm getti
k, but more importantly, no
dropped frames. gPTP gives you a central reference to time.
> [1] [alsa-lib][PATCH 0/9 v3] ctl: add APIs for control element set
> http://mailman.alsa-project.org/pipermail/alsa-devel/2016-June/109274.html
> [2] IEEE 1722-2011
> http://ieeexplore.ieee.org/servlet/opac?punumber=5764873
> [3] 5.5 Timing and Synchronization
> op. cit.
> [4] 1394 Open Host Controller Interface Specification
> http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/ohci_11.pdf
I hope this cleared some of the questions
--
Henrik Austad
signature.asc
Description: Digital signature
k, but more importantly, no
dropped frames. gPTP gives you a central reference to time.
> [1] [alsa-lib][PATCH 0/9 v3] ctl: add APIs for control element set
> http://mailman.alsa-project.org/pipermail/alsa-devel/2016-June/109274.html
> [2] IEEE 1722-2011
> http://ieeexplore.ieee.org/servlet/opac?punumber=5764873
> [3] 5.5 Timing and Synchronization
> op. cit.
> [4] 1394 Open Host Controller Interface Specification
> http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/ohci_11.pdf
I hope this cleared some of the questions
--
Henrik Austad
signature.asc
Description: Digital signature
On Wed, Jun 15, 2016 at 01:49:08PM +0200, Richard Cochran wrote:
> 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:
>
On Wed, Jun 15, 2016 at 01:49:08PM +0200, Richard Cochran wrote:
> 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:
>
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?
In short:
modprobe
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?
In short:
modprobe
On Tue, Jun 14, 2016 at 08:26:15PM +0200, Richard Cochran wrote:
> 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 wh
On Tue, Jun 14, 2016 at 08:26:15PM +0200, Richard Cochran wrote:
> 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 wh
On Mon, Jun 13, 2016 at 09:32:10PM +0200, Richard Cochran wrote:
> 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/
&g
On Mon, Jun 13, 2016 at 09:32:10PM +0200, Richard Cochran wrote:
> 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/
&g
ably don't want
> another mechanism to map hw queues/tcs/etc if the existing interfaces
> work or can be extended to support this.
Sure, I get that, as long as the complexity for setting up a link doesn't
go through the roof :)
Thanks!
--
Henrik Austad
signature.asc
Description: Digital signature
ably don't want
> another mechanism to map hw queues/tcs/etc if the existing interfaces
> work or can be extended to support this.
Sure, I get that, as long as the complexity for setting up a link doesn't
go through the roof :)
Thanks!
--
Henrik Austad
signature.asc
Description: Digital signature
On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote:
> Henrik,
Hi Richard,
> 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?
driv
On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote:
> Henrik,
Hi Richard,
> 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?
driv
On Sun, Jun 12, 2016 at 10:22:01PM -0400, Steven Rostedt wrote:
> On Sun, 12 Jun 2016 23:25:10 +0200
> Henrik Austad <hen...@austad.us> wrote:
>
> > > > +#include
> > > > +#include
> > > > +/* #include */
> > > >
On Sun, Jun 12, 2016 at 10:22:01PM -0400, Steven Rostedt wrote:
> On Sun, 12 Jun 2016 23:25:10 +0200
> Henrik Austad wrote:
>
> > > > +#include
> > > > +#include
> > > > +/* #include */
> > > > +
> > > > +/* FIXME: update t
On Sun, Jun 12, 2016 at 12:58:03PM -0400, Steven Rostedt wrote:
> On Sun, 12 Jun 2016 01:01:34 +0200
> Henrik Austad <hen...@austad.us> wrote:
>
> > From: Henrik Austad <haus...@cisco.com>
> >
> > This needs refactoring and should be updated to use TRACE_CL
On Sun, Jun 12, 2016 at 12:58:03PM -0400, Steven Rostedt wrote:
> On Sun, 12 Jun 2016 01:01:34 +0200
> Henrik Austad wrote:
>
> > From: Henrik Austad
> >
> > This needs refactoring and should be updated to use TRACE_CLASS, but for
> > now it provides a fair d
On Sun, Jun 12, 2016 at 12:35:10AM -0700, Joe Perches wrote:
> On Sun, 2016-06-12 at 00:22 +0200, Henrik Austad wrote:
> > From: Henrik Austad <haus...@cisco.com>
> >
> > In short summary:
> >
> > * tsn_core.c is the main driver of tsn, all new links go
On Sun, Jun 12, 2016 at 12:35:10AM -0700, Joe Perches wrote:
> On Sun, 2016-06-12 at 00:22 +0200, Henrik Austad wrote:
> > From: Henrik Austad
> >
> > In short summary:
> >
> > * tsn_core.c is the main driver of tsn, all new links go through
> > here and
From: Henrik Austad <haus...@cisco.com>
This defines the general TSN headers for network packets, the
shim-interface and the central 'tsn_list' structure.
Cc: "David S. Miller" <da...@davemloft.net>
Signed-off-by: Henrik Austad <haus...@cisco.com>
--
From: Henrik Austad <haus...@cisco.com>
This needs refactoring and should be updated to use TRACE_CLASS, but for
now it provides a fair debug-window into TSN.
Cc: "David S. Miller" <da...@davemloft.net>
Cc: Steven Rostedt <rost...@goodmis.org> (maintainer:
From: Henrik Austad
This needs refactoring and should be updated to use TRACE_CLASS, but for
now it provides a fair debug-window into TSN.
Cc: "David S. Miller"
Cc: Steven Rostedt (maintainer:TRACING)
Cc: Ingo Molnar (maintainer:TRACING)
Signed-off-by: Henrik Austad
---
inc
From: Henrik Austad
This defines the general TSN headers for network packets, the
shim-interface and the central 'tsn_list' structure.
Cc: "David S. Miller"
Signed-off-by: Henrik Austad
---
include/linux/tsn.h | 806
1 file ch
From: Henrik Austad <haus...@cisco.com>
In short summary:
* tsn_core.c is the main driver of tsn, all new links go through
here and all data to/form the shims are handled here
core also manages the shim-interface.
* tsn_configfs.c is the API to userspace. TSN is driven from use
remains
- tie to (g)PTP properly, currently using ktime_get() for presentation
time
- get time from shim into TSN and vice versa
- let shim create/manage buffer
Henrik Austad (8):
TSN: add documentation
TSN: Add the standard formerly known as AVB to the kernel
Adding TSN-driver to Intel
From: Henrik Austad
In short summary:
* tsn_core.c is the main driver of tsn, all new links go through
here and all data to/form the shims are handled here
core also manages the shim-interface.
* tsn_configfs.c is the API to userspace. TSN is driven from userspace
and a link is created
1 - 100 of 279 matches
Mail list logo
