On Tue, Sep 25, 2018 at 7:13 PM Sai Dasari wrote:
> On 9/24/18, 4:21 PM, "openbmc on behalf of Joel Stanley"
>
> wrote:
>
> I will then add it to the set of tests I run when testing aspeed
> kernels.
>
> Thanks Joel! Curious to know what would be the best place to keep these kind
>
On Tue, Sep 25, 2018 at 7:13 PM Sai Dasari wrote:
> On 9/24/18, 4:21 PM, "openbmc on behalf of Joel Stanley"
>
> wrote:
>
> I will then add it to the set of tests I run when testing aspeed
> kernels.
>
> Thanks Joel! Curious to know what would be the best place to keep these kind
>
On 9/24/18, 4:21 PM, "openbmc on behalf of Joel Stanley"
wrote:
I will then add it to the set of tests I run when testing aspeed
kernels.
Thanks Joel! Curious to know what would be the best place to keep these kind of
Kernel test cases for sake of review and/or adding new test
On 9/24/18, 4:21 PM, "openbmc on behalf of Joel Stanley"
wrote:
I will then add it to the set of tests I run when testing aspeed
kernels.
Thanks Joel! Curious to know what would be the best place to keep these kind of
Kernel test cases for sake of review and/or adding new test
On 9/24/18, 4:20 PM, "Joel Stanley" wrote:
> Whatever method is easiest for you. A patch file or a tarball is fine.
> I will then add it to the set of tests I run when testing aspeed
> kernels.
No problem, Joel. I will share the test code with you offline.
Thanks,
Tao Ren
On 9/24/18, 4:20 PM, "Joel Stanley" wrote:
> Whatever method is easiest for you. A patch file or a tarball is fine.
> I will then add it to the set of tests I run when testing aspeed
> kernels.
No problem, Joel. I will share the test code with you offline.
Thanks,
Tao Ren
On Sat, 22 Sep 2018 at 03:41, Tao Ren wrote:
>
> On 9/20/18, 8:33 PM, "Joel Stanley" wrote:
>
> > I gave this a spin on the ast2400. It looked okay, but I was wondering
> > if you could share you test case so I can run the same test?
>
> Thank you Joel for the testing.
> Sure I can share the
On Sat, 22 Sep 2018 at 03:41, Tao Ren wrote:
>
> On 9/20/18, 8:33 PM, "Joel Stanley" wrote:
>
> > I gave this a spin on the ast2400. It looked okay, but I was wondering
> > if you could share you test case so I can run the same test?
>
> Thank you Joel for the testing.
> Sure I can share the
On 9/20/18, 11:22 PM, "Lei YU" wrote:
> Tested on Palmetto (OpenPOWER P8 with AST2400), and it does show the fix is
> working on AST2400 as well.
> Without the patch, usleep(100) takes tens of milliseconds randomly;
> With the patch, usleep(100) takes about 600~700 microseconds stably.
>
>
On 9/20/18, 11:22 PM, "Lei YU" wrote:
> Tested on Palmetto (OpenPOWER P8 with AST2400), and it does show the fix is
> working on AST2400 as well.
> Without the patch, usleep(100) takes tens of milliseconds randomly;
> With the patch, usleep(100) takes about 600~700 microseconds stably.
>
>
On 9/20/18, 8:33 PM, "Joel Stanley" wrote:
> I gave this a spin on the ast2400. It looked okay, but I was wondering
> if you could share you test case so I can run the same test?
Thank you Joel for the testing.
Sure I can share the test (a small c program which measures delay introduced by
On 9/20/18, 8:33 PM, "Joel Stanley" wrote:
> I gave this a spin on the ast2400. It looked okay, but I was wondering
> if you could share you test case so I can run the same test?
Thank you Joel for the testing.
Sure I can share the test (a small c program which measures delay introduced by
> >
> > Make sense. I actually booted up kernel on qemu-palmetto (ast2400) but I'm
> > doubting if test is valid because it depends on how qemu emulates the
> > hardware. It would be great if someone can help to verify the patch on
> > physical ast2400.
>
> I gave this a spin on the ast2400. It
> >
> > Make sense. I actually booted up kernel on qemu-palmetto (ast2400) but I'm
> > doubting if test is valid because it depends on how qemu emulates the
> > hardware. It would be great if someone can help to verify the patch on
> > physical ast2400.
>
> I gave this a spin on the ast2400. It
On Fri, 21 Sep 2018 at 06:39, Tao Ren wrote:
>
> On 9/20/18, 8:46 AM, "Linus Walleij" wrote:
>
> > Actually this is much more intuitive too, it is the typical way to handle
> > a down-counting timer. Good catch!
> > Reviewed-by: Linus Walleij
>
> Thank you Linus for the quick review!
>
> >
On Fri, 21 Sep 2018 at 06:39, Tao Ren wrote:
>
> On 9/20/18, 8:46 AM, "Linus Walleij" wrote:
>
> > Actually this is much more intuitive too, it is the typical way to handle
> > a down-counting timer. Good catch!
> > Reviewed-by: Linus Walleij
>
> Thank you Linus for the quick review!
>
> >
On 9/20/18, 8:46 AM, "Linus Walleij" wrote:
> Actually this is much more intuitive too, it is the typical way to handle
> a down-counting timer. Good catch!
> Reviewed-by: Linus Walleij
Thank you Linus for the quick review!
> Sorry for any cargo-cult programming on my part :/
> Would be
On 9/20/18, 8:46 AM, "Linus Walleij" wrote:
> Actually this is much more intuitive too, it is the typical way to handle
> a down-counting timer. Good catch!
> Reviewed-by: Linus Walleij
Thank you Linus for the quick review!
> Sorry for any cargo-cult programming on my part :/
> Would be
On Wed, Sep 19, 2018 at 3:13 PM Tao Ren wrote:
> Currently, the aspeed MATCH1 register is updated to cycles> in set_next_event handler, with the assumption that COUNT
> register value is preserved when the timer is disabled and it continues
> decrementing after the timer is enabled. But the
On Wed, Sep 19, 2018 at 3:13 PM Tao Ren wrote:
> Currently, the aspeed MATCH1 register is updated to cycles> in set_next_event handler, with the assumption that COUNT
> register value is preserved when the timer is disabled and it continues
> decrementing after the timer is enabled. But the
On 20/09/2018 00:13, Tao Ren wrote:
> Currently, the aspeed MATCH1 register is updated to cycles> in set_next_event handler, with the assumption that COUNT
> register value is preserved when the timer is disabled and it continues
> decrementing after the timer is enabled. But the assumption is
On 20/09/2018 00:13, Tao Ren wrote:
> Currently, the aspeed MATCH1 register is updated to cycles> in set_next_event handler, with the assumption that COUNT
> register value is preserved when the timer is disabled and it continues
> decrementing after the timer is enabled. But the assumption is
Currently, the aspeed MATCH1 register is updated to in set_next_event handler, with the assumption that COUNT
register value is preserved when the timer is disabled and it continues
decrementing after the timer is enabled. But the assumption is wrong:
RELOAD register is loaded into COUNT register
Currently, the aspeed MATCH1 register is updated to in set_next_event handler, with the assumption that COUNT
register value is preserved when the timer is disabled and it continues
decrementing after the timer is enabled. But the assumption is wrong:
RELOAD register is loaded into COUNT register
24 matches
Mail list logo
