> From: Thomas Gleixner [mailto:t...@linutronix.de]
(..)
> So we need two fixes:
>
> 1) The replacement of the dummy timer and the effect on the broadcast
>mask/device
>
> 2) tick_check_oneshot_broadcast needs a sanity check
>
> Patch below.
Hi,
Thank you for your patch Thomas; I think it
On Mon, 1 Jul 2013, Stephen Boyd wrote:
> On 07/01/13 14:24, Thomas Gleixner wrote:
> > On Mon, 1 Jul 2013, Stephen Boyd wrote:
> >> On 07/01/13 13:14, Thomas Gleixner wrote:
> >>> The issue is very subtle. What happens is:
> >>>
> >>> CPU0 CPU1
> >>>
>
On 07/01/13 14:24, Thomas Gleixner wrote:
> On Mon, 1 Jul 2013, Stephen Boyd wrote:
>> On 07/01/13 13:14, Thomas Gleixner wrote:
>>> The issue is very subtle. What happens is:
>>>
>>> CPU0CPU1
>>>
>>> Switch to oneshot mode
>>>
>>> Copy the bits from
On Mon, 1 Jul 2013, Stephen Boyd wrote:
> On 07/01/13 13:14, Thomas Gleixner wrote:
> > The issue is very subtle. What happens is:
> >
> > CPU0CPU1
> >
> > Switch to oneshot mode
> >
> > Copy the bits from tick_broadcast_mask to
> > tick_broadcast_o
On 07/01/13 13:14, Thomas Gleixner wrote:
> The issue is very subtle. What happens is:
>
> CPU0 CPU1
>
> Switch to oneshot mode
>
> Copy the bits from tick_broadcast_mask to
> tick_broadcast_oneshot_mask. We need to do
> that so the other cpus reach the t
On Mon, 1 Jul 2013, Stephen Boyd wrote:
> On 07/01/13 10:49, Thomas Gleixner wrote:
> >
> > Though that does not explain why dev->next_event is set to KTIME_MAX
> > after we installed the mxc_timer1 as the system clocksource. And we
> > really need to know why that happens.
> >
> > Here is some mo
On 07/01/13 10:49, Thomas Gleixner wrote:
> On Mon, 1 Jul 2013, Stehle Vincent-B46079 wrote:
>
>> From: Thomas Gleixner [mailto:t...@linutronix.de]
>>> (..) Can you please apply the patch below and provide the output?
>> Sure; thanks for the patch. The kernel seems to be in a loop, as it prints
>
From: Thomas Gleixner [mailto:t...@linutronix.de]
(..)
> Though that does not explain why dev->next_event is set to KTIME_MAX
> after we installed the mxc_timer1 as the system clocksource. And we
> really need to know why that happens.
>
> Here is some more debugging which should shine some light
On Mon, 1 Jul 2013, Stehle Vincent-B46079 wrote:
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> > (..) Can you please apply the patch below and provide the output?
>
> Sure; thanks for the patch. The kernel seems to be in a loop, as it prints
> many messages and never stops. I copy only
From: Thomas Gleixner [mailto:t...@linutronix.de]
> (..) Can you please apply the patch below and provide the output?
Sure; thanks for the patch. The kernel seems to be in a loop, as it prints many
messages and never stops. I copy only the first ones:
...
Switched to clocksource mxc_timer1
next
On Mon, 1 Jul 2013, Stehle Vincent-B46079 wrote:
So up to this point everything looks ok. mxc timer is the broadcast
and the local timer is preferred over the dummy timer.
But after switching the clocksource:
> Switched to clocksource mxc_timer1
> [ cut here ]
> WARNING:
From: Stephen Boyd [mailto:sb...@codeaurora.org]
> (..) Is this an SMP capable device? What devicetree blob are you using?
Yes, this is an i.MX6 quad. I boot with imx6q-sabresd.dtb
> (..) Well oddly I don't see any twd in the timer list
> but that may be because you're not running more than one
On Sat, Jun 29, 2013 at 03:07:38AM +0100, Stephen Boyd wrote:
> On 06/28, Stephen Boyd wrote:
> > On 06/28/13 09:58, Stehle Vincent-B46079 wrote:
> > > From: linux-next-ow...@vger.kernel.org
> > > [mailto:linux-next-ow...@vger.kernel.org] On Behalf Of Stephen Boyd
> > > (..)
> > >> Do you have deb
On 06/28, Stephen Boyd wrote:
> On 06/28/13 09:58, Stehle Vincent-B46079 wrote:
> > From: linux-next-ow...@vger.kernel.org
> > [mailto:linux-next-ow...@vger.kernel.org] On Behalf Of Stephen Boyd
> > (..)
> >> Do you have debug_ll support to get some serial logs?
> > Hi,
> >
> > Thanks for your con
On 06/28/13 09:58, Stehle Vincent-B46079 wrote:
> From: linux-next-ow...@vger.kernel.org
> [mailto:linux-next-ow...@vger.kernel.org] On Behalf Of Stephen Boyd
> (..)
>> Do you have debug_ll support to get some serial logs?
> Hi,
>
> Thanks for your concern on the matter. You are right, there is de
From: linux-next-ow...@vger.kernel.org
[mailto:linux-next-ow...@vger.kernel.org] On Behalf Of Stephen Boyd
(..)
> Do you have debug_ll support to get some serial logs?
Hi,
Thanks for your concern on the matter. You are right, there is debug_ll support
for i.MX6. If I activate it for next-201306
On 06/28/13 05:09, Thomas Gleixner wrote:
> On Thu, 27 Jun 2013, Stehle Vincent-B46079 wrote:
>
> Cc'ed Mark and Stephen.
>
>> FYI I remark that today's Linux next 'next-20130627' breaks i.MX6
>> sabre sd UART console with ARM config imx_v6_v7_defconfig.
>> This was working fine yesterday with 'nex
On Thu, 27 Jun 2013, Stehle Vincent-B46079 wrote:
Cc'ed Mark and Stephen.
> FYI I remark that today's Linux next 'next-20130627' breaks i.MX6
> sabre sd UART console with ARM config imx_v6_v7_defconfig.
> This was working fine yesterday with 'next-20130626'.
>
> Bisecting gave me this commit:
>
18 matches
Mail list logo
