Hi Laurent,
On Tue, 2014-04-01 at 15:49 +0200, Laurent Pinchart wrote:
> Hi Olivier,
>
> On Sunday 30 March 2014 00:23:01 Olivier Langlois wrote:
> > Hi Laurent,
> >
> > > > Yes. ffmpeg uses wall clock time to create timestamps for audio packets
> > &
Hi Laurent,
> > Yes. ffmpeg uses wall clock time to create timestamps for audio packets from
> > ALSA device.
>
> OK. I suppose I shouldn't drop support for the realtime clock like I wanted
> to
> then :-)
>
> > There is a bug in ffmpeg describing problems to synchronize audio and
> > the vid
> > >
> > > Before applying this, I'm curious, do you have a use case for realtime
> > > time stamps ?
> >
> > Yes. ffmpeg uses wall clock time to create timestamps for audio packets from
> > ALSA device.
>
> OK. I suppose I shouldn't drop support for the realtime clock like I wanted
> to
> t
Hi Laurent,
On Fri, 2014-03-28 at 17:20 +0100, Laurent Pinchart wrote:
> Hi Olivier,
>
> Thank you for the patch.
>
> On Friday 28 March 2014 01:42:38 Olivier Langlois wrote:
> > timestamps in v4l2 buffers returned to userspace are updated in
> > uvc_video_clock_upd
with ffmpeg:
ffmpeg -y -f v4l2 -input_format yuyv422 -video_size 640x480 -framerate 30 -i
/dev/video0 \
-f alsa -acodec pcm_s16le -ar 16000 -ac 1 -i default \
-c:v libx264 -preset ultrafast \
-c:a libfdk_aac \
out.mkv
and inspecting the v4l2 input starting timestamp.
Signed-off-by: Olivier
has proven to work is
to reenable the irqs during the function rtl92ce_hw_init().
I think that it is safe doing so since the device interrupt will only be
enabled after the init function succeed.
Signed-off-by: Olivier Langlois
Cc: Stable
---
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 18
rtl_ps_enable_nic() is called from loops that will loop until this function
returns true or a
maximum number of retries is performed.
hw_init() returns non-zero on error. In that situation return false to
restore the original design intent to retry hw init when it fails.
Signed-off-by: Olivier
has proven to work is
to reenable the irqs during the function rtl92ce_hw_init().
I think that it is safe doing so since the device interrupt will only be
enabled after the init function succeed.
Signed-off-by: Olivier Langlois
---
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 18
On Thu, 2014-01-30 at 14:19 -0600, Larry Finger wrote:
> On 01/30/2014 12:22 AM, Olivier Langlois wrote:
> > Signed-off-by: Olivier Langlois
> > ---
> > drivers/net/wireless/rtlwifi/ps.c | 2 +-
> > drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 18 +
rtl_ps_enable_nic() is called from loops that will loop until this function
returns true or a
maximum number of retries is performed.
hw_init() returns non-zero on error. In that situation return false to
restore the original design intent to retry hw init when it fails.
Signed-off-by: Olivier
reenable the irqs during the function rtl92ce_hw_init().
I think that it is safe doing so since the device interrupt will only be
enabled after the init function succeed.
Signed-off-by: Olivier Langlois
---
drivers/net/wireless/rtlwifi/ps.c | 2 +-
drivers/net/wireless/rtlwifi/
() (posix-timers.c)
I believe this misunderstanding may partly explain the current state of
the code.
On Mon, 2013-11-25 at 14:25 -0500, Olivier Langlois wrote:
> When a periodic process timer is fired, a signal is generated.
> Rearming the timer, if necessary, will be performed in a secon
010] cputimer started
[ 181.917008] cputimer stopped
[ 181.917058] cputimer started
[ 181.918009] cputimer stopped
[ 181.918029] cputimer started
[ 181.919006] cputimer stopped
[ 181.919010] cputimer started
[ 181.920006] cputimer stopped
After:
[ 859.722119] cputimer started
[
>
> Then please test everything again. I.e.
> o speaker-test -D hdmi:CARD=Generic,DEV=0 -c8 -r192000 -F S32_LE
>
this work fine
> o Is there any difference seen
> with these, in the beginning/end (i.e. fade-out/in):
> speaker-test -D hdmi:CARD=Generic,DEV=0,AES0=0x04 -c2 -r48000
>
> >
> > Rear left and rear right channels are flipped.
>
> Thanks for testing.
>
> That seems a bit strange, I would've expected everything to be flipped
> if there was a bug there.
>
Anssi, you were right to be suspicious. The bug was in my wiring.
>
> >>
> >> o Contents of /proc/asound/ca
Anssi,
Your patch has been applied on 3.11.3
>
> I'm especially interested in testers with:
>
> - Older codecs other than 0x1002aa01. My best guess still is that the
> new code works on them as well.
> o On these I'd like to know if multichannel and the new formats
> work, i.e. e.g.
>
Frederic,
On Tue, 2013-05-07 at 01:18 +0200, Frederic Weisbecker wrote:
> On Mon, Apr 29, 2013 at 02:04:09PM -0400, Olivier Langlois wrote:
> >
> >
> > Forbids the cputimer to drift ahead of its process clock by
> > blocking its update when a tick occurs whil
t; signal->cputimer accounting.
> >
> > This inconsistency makes POSIX timer wake up too early. This patch fixes it.
> >
> > Cc: Thomas Gleixner
> > Cc: Frederic Weisbecker
> > Cc: Ingo Molnar
> > Acked-by: Peter Zijlstra
> > Signed-off-by: O
>
> > Maybe the condition around the posix_cpu_timer_schedule() block inside
> > cpu_timer_fire() could even be a good candidate for 'unlikely'
> > qualifier.
>
> Well, cpu_timer_fire() is probably not a fast path. So helping branch
> prediction there probably won't have much measurable effect i
On Mon, 2013-04-29 at 23:17 -0400, kosaki.motoh...@gmail.com wrote:
> From: KOSAKI Motohiro
>
> Currently glibc's rt/tst-cputimer1 testcase is spradically fail because
> a timer created by timer_create() may fire earlier than it's specified.
>
> posix_cpu_timer_set() uses "val" as current time f
On Mon, 2013-04-29 at 15:09 -0400, KOSAKI Motohiro wrote:
> (4/29/13 2:54 PM), Olivier Langlois wrote:
> > On Mon, 2013-04-29 at 14:31 -0400, KOSAKI Motohiro wrote:
> >> (4/29/13 2:20 PM), Olivier Langlois wrote:
> >>>
> >>>>
> >>>>&
On Mon, 2013-04-29 at 14:31 -0400, KOSAKI Motohiro wrote:
> (4/29/13 2:20 PM), Olivier Langlois wrote:
> >
> >>
> >>>> I'm confused. glibc's rt/tst-cputimer1 doesn't have thread exiting code.
> >>>> I have
> >>>> no
>
> >> I'm confused. glibc's rt/tst-cputimer1 doesn't have thread exiting code. I
> >> have
> >> no seen any issue in this accounting.
> >
> > glibc launch a helper thread to receive timer signal and will also
> > create a new thread upon signal reception when a timer is created with
> > sigev_
-cputimer1.c
2. There is a race condition hard to fix that the code simply need to
acknowledge
its presence and workaround.
3. Also, cputimer is initialized to the process clock value minus deltas. This
is
required for absolute timers.
Signed-off-by: Olivier Langlois
---
kernel/posix-cpu-timers.c | 91
().
Signed-off-by: Olivier Langlois
---
include/linux/kernel_stat.h | 1 +
include/linux/sched.h | 5 +
kernel/sched/core.c | 22 +
kernel/sched/cputime.c | 47 +++--
4 files changed, 65 insertions(+), 10 deletions
because they are added to the global process stats located
in the signal struct from release_task().
Signed-off-by: Olivier Langlois
---
kernel/sched/fair.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7a33e59..52d7b10
On Mon, 2013-04-29 at 13:10 -0400, Olivier Langlois wrote:
> On Mon, 2013-04-29 at 01:06 -0400, KOSAKI Motohiro wrote:
> > (4/27/13 12:40 AM), Olivier Langlois wrote:
> > >
> > >
> > > Forbids the cputimer to drift ahead of its process clock by
> > >
On Mon, 2013-04-29 at 02:45 +0200, Frederic Weisbecker wrote:
> 2013/4/27 Olivier Langlois :
> >
> >
> > Forbids the cputimer to drift ahead of its process clock by
> > blocking its update when a tick occurs while a autoreaping task
> > is currently in do_exit()
On Mon, 2013-04-29 at 02:25 -0400, KOSAKI Motohiro wrote:
> (4/27/13 12:41 AM), Olivier Langlois wrote:
> >
> >
> > Add thread group delta to cpu timer sample when computing a timer
> > expiration.
> >
> > This is mandatory to make sure that the pos
On Mon, 2013-04-29 at 01:06 -0400, KOSAKI Motohiro wrote:
> (4/27/13 12:40 AM), Olivier Langlois wrote:
> >
> >
> > Forbids the cputimer to drift ahead of its process clock by
> > blocking its update when a tick occurs while a autoreaping task
> > is currently
>
>
> I did vary HZ from 300 to 1000 HZ, I tried the 3 three different
> preemption models.
>
> With all these combinations, I still have the problem.
>
Actually, I may have observed more failure with 1000 HZ and
CONFIG_PREEMPT=y (low-latency desktop)
Also make sure that High resolution timer
>
>
> Also other factors to consider it is are you doing the test on a very
> loaded system? What is your platform?
>
> I have tested it positively on 32 bit, 64 bits build on Atom N450
>
> i7 first and second generation system.
>
> I did vary HZ from 300 to 1000 HZ, I tried the 3 three diffe
> 2) tst-cputimer1.c only have CLOCK_PROCESS_CPUTIME_ID test and
> don't have any utime, stime tests.
>
Sorry, I should take a couple minutes break before pressing send to be
sure that I have said everything :-)
CLOCK_PROCESS_CPUTIME_ID is user space name for kernel space
CPUCLOCK_SCHED clock.
On Fri, 2013-04-26 at 22:15 -0400, KOSAKI Motohiro wrote:
> On Fri, Apr 26, 2013 at 9:51 PM, Olivier Langlois
> wrote:
> > On Fri, 2013-04-26 at 15:08 -0400, KOSAKI Motohiro wrote:
> >> > I need to add that I can only confirm that to be true with
> >> > sum_e
sequences.
Signed-off-by: Olivier Langlois
---
kernel/posix-cpu-timers.c | 91 +++
1 file changed, 76 insertions(+), 15 deletions(-)
diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
index 8fd709c..10d28cc 100644
--- a/kernel/posix-cpu-timer
keep the same
pace than the process clock but in fact, what should be done is to
speed up the process clock by adding the missing stats to it.
Signed-off-by: Olivier Langlois
---
kernel/sched/fair.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c
().
Signed-off-by: Olivier Langlois
---
include/linux/kernel_stat.h | 1 +
include/linux/sched.h | 5 +
kernel/sched/core.c | 22 +
kernel/sched/cputime.c | 47 +++--
4 files changed, 65 insertions(+), 10 deletions
On Fri, 2013-04-26 at 15:08 -0400, KOSAKI Motohiro wrote:
> > I need to add that I can only confirm that to be true with
> > sum_exec_runtime.
> >
> > To affirm it to be true for stime and utime would require more
> > investigation. I didn't look them at all. I was only concerned with
> > sum_exec
On Fri, 2013-04-26 at 00:40 -0400, Olivier Langlois wrote:
> On Fri, 2013-04-19 at 11:08 -0700, KOSAKI Motohiro wrote:
> > On Fri, Apr 19, 2013 at 10:38 AM, KOSAKI Motohiro
> > wrote:
> > >> I feel we are hitting the same issue than this patch:
> > >
>
>
> IMO, a more likely scenario, posix_cpu_timer_schedule() will be called
> from dequeue_signal() which will be from from a different context than
> the interrupt context.
>
I'll be even more explicit. Inside dequeue_signal(),
do_schedule_next_timer() is called which then call
posix_cpu_tim
On Fri, 2013-04-19 at 11:08 -0700, KOSAKI Motohiro wrote:
> On Fri, Apr 19, 2013 at 10:38 AM, KOSAKI Motohiro
> wrote:
> >> I feel we are hitting the same issue than this patch:
> >> https://lkml.org/lkml/2013/4/5/116
> >>
> >> I'm adding Kosaki in Cc, who proposed roughly the same fix.
> >
> > Th
On Fri, 2013-04-19 at 14:47 +0200, Frederic Weisbecker wrote:
>
> >
> > I might be mistaken but I believe that firing timers are not rescheduled
> > in the current interrupt context. They are going to be rescheduled later
> > from the task context handling the timer generated signal.
>
> No, whe
Hi Frederic,
> /*
> @@ -1279,6 +1277,7 @@ void run_posix_cpu_timers(struct task_struct *tsk)
> LIST_HEAD(firing);
> struct k_itimer *timer, *next;
> unsigned long flags;
> + struct signal_struct *sig;
>
> BUG_ON(!irqs_disabled());
>
> @@ -1336,6 +1335,10 @@ void run
complex to achieve.
Signed-off-by: Olivier Langlois
---
kernel/posix-cpu-timers.c | 44 +---
kernel/sched/fair.c | 10 +-
2 files changed, 34 insertions(+), 20 deletions(-)
diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
index
On Fri, 2013-04-12 at 17:55 +0200, Peter Zijlstra wrote:
> On Fri, 2013-04-12 at 12:50 +0200, Peter Zijlstra wrote:
>
> > I'll try and dig through the rest of your email later.. sorry for
> > being
> > a tad slow etc.
>
>
> So at thread_group_cputimer() we initialize the cputimer->cputime state
On Fri, 2013-04-12 at 11:16 +0200, Peter Zijlstra wrote:
> On Wed, 2013-04-10 at 11:48 -0400, Olivier Langlois wrote:
> > Please explain how expensive it is. All I am seeing is a couple of
> > additions.
>
> Let me start with this, since your earlier argument also refers to
&
On Wed, 2013-04-10 at 13:35 +0200, Peter Zijlstra wrote:
> On Fri, 2013-04-05 at 13:59 -0400, Olivier Langlois wrote:
> > Process timers are moving fasters than their corresponding
> > cpu clock for various reasons:
> >
> > 1. There is a race condition when getting a
On Wed, 2013-04-10 at 13:35 +0200, Peter Zijlstra wrote:
> On Fri, 2013-04-05 at 13:59 -0400, Olivier Langlois wrote:
> > Process timers are moving fasters than their corresponding
> > cpu clock for various reasons:
> >
> > 1. There is a race condition when getting a
voking tst-cputimer1 in an infinite loop.
Signed-off-by: Olivier Langlois
---
include/linux/kernel_stat.h | 1 +
include/linux/sched.h | 5 +++
kernel/posix-cpu-timers.c | 93 +
kernel/sched/core.c | 22 +--
kernel/sched
49 matches
Mail list logo
