[Xenomai] i8253 clocksource vs. rthal_get_8254_tsc

[Xenomai] i8253 clocksource vs. rthal_get_8254_tsc

[Jan Kiszka]

Hi Gilles,

I just realized that there is now a 8253 clocksource in core-3.4+. How
does this work together with Xenomai's TSC emulation via the 8254 in the
x86 hal_32? Xenomai reprograms the PIT in rthal_setup_8254_tsc - is this
harmless?

I came across this while trying to get rid of Xenomai's "depends on
!INPUT_PCSPKR" to avoid that circular Kbuild dependency.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] i8253 clocksource vs. rthal_get_8254_tsc

[Gilles Chanteperdrix]

On 02/06/2013 11:20 AM, Jan Kiszka wrote:

> Hi Gilles,
> 
> I just realized that there is now a 8253 clocksource in core-3.4+. How
> does this work together with Xenomai's TSC emulation via the 8254 in the
> x86 hal_32? Xenomai reprograms the PIT in rthal_setup_8254_tsc - is this
> harmless?
> 
> I came across this while trying to get rid of Xenomai's "depends on
> !INPUT_PCSPKR" to avoid that circular Kbuild dependency.


This emulation replaces Xenomai's TSC emulation when the kernel boots on
a cpu without a TSC: the detection is made at run-time instead of
compilation time using self-modifying code (this in order to be able to
build Debian kernels which boots with any configuration). There is no
reason to keep the compilation-time dependency on !INPUT_PCSPKR with
I-pipe core, as now the pc speaker is disabled at run-time too.
Unfortunately, I could not find how to arrange the Kconfig either.

-- 
                                                                Gilles.

Re: [Xenomai] i8253 clocksource vs. rthal_get_8254_tsc

[Jan Kiszka]

On 2013-02-06 13:18, Gilles Chanteperdrix wrote:
> On 02/06/2013 11:20 AM, Jan Kiszka wrote:
> 
>> Hi Gilles,
>>
>> I just realized that there is now a 8253 clocksource in core-3.4+. How
>> does this work together with Xenomai's TSC emulation via the 8254 in the
>> x86 hal_32? Xenomai reprograms the PIT in rthal_setup_8254_tsc - is this
>> harmless?
>>
>> I came across this while trying to get rid of Xenomai's "depends on
>> !INPUT_PCSPKR" to avoid that circular Kbuild dependency.
> 
> 
> This emulation replaces Xenomai's TSC emulation when the kernel boots on
> a cpu without a TSC: the detection is made at run-time instead of
> compilation time using self-modifying code (this in order to be able to
> build Debian kernels which boots with any configuration).

Hmm, that's for the kernel. But what prevents rthal_setup_8254_tsc from
being executed in addition? I'm currently a bit lost in the #ifdefs.

> There is no
> reason to keep the compilation-time dependency on !INPUT_PCSPKR with
> I-pipe core, as now the pc speaker is disabled at run-time too.
> Unfortunately, I could not find how to arrange the Kconfig either.

As this is only about practically unsupported combinations of Xenomai
(2.6.x) and I-pipe (for kernel 2.6.x) on x86, we could move from a
configure-time to a build-time detection (#ifdef CONFIG_INPUT_PCSPKR ->
BUILD_BUG()).

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] i8253 clocksource vs. rthal_get_8254_tsc

[Jan Kiszka]

On 2013-02-06 13:28, Jan Kiszka wrote:
> On 2013-02-06 13:18, Gilles Chanteperdrix wrote:
>> On 02/06/2013 11:20 AM, Jan Kiszka wrote:
>>
>>> Hi Gilles,
>>>
>>> I just realized that there is now a 8253 clocksource in core-3.4+. How
>>> does this work together with Xenomai's TSC emulation via the 8254 in the
>>> x86 hal_32? Xenomai reprograms the PIT in rthal_setup_8254_tsc - is this
>>> harmless?
>>>
>>> I came across this while trying to get rid of Xenomai's "depends on
>>> !INPUT_PCSPKR" to avoid that circular Kbuild dependency.
>>
>>
>> This emulation replaces Xenomai's TSC emulation when the kernel boots on
>> a cpu without a TSC: the detection is made at run-time instead of
>> compilation time using self-modifying code (this in order to be able to
>> build Debian kernels which boots with any configuration).
> 
> Hmm, that's for the kernel. But what prevents rthal_setup_8254_tsc from
> being executed in addition? I'm currently a bit lost in the #ifdefs.

Ah! IPIPE_CORE_APIREV < 2, right?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] i8253 clocksource vs. rthal_get_8254_tsc

[Gilles Chanteperdrix]

On 02/06/2013 01:28 PM, Jan Kiszka wrote:

> On 2013-02-06 13:18, Gilles Chanteperdrix wrote:
>> On 02/06/2013 11:20 AM, Jan Kiszka wrote:
>>
>>> Hi Gilles,
>>>
>>> I just realized that there is now a 8253 clocksource in core-3.4+. How
>>> does this work together with Xenomai's TSC emulation via the 8254 in the
>>> x86 hal_32? Xenomai reprograms the PIT in rthal_setup_8254_tsc - is this
>>> harmless?
>>>
>>> I came across this while trying to get rid of Xenomai's "depends on
>>> !INPUT_PCSPKR" to avoid that circular Kbuild dependency.
>>
>>
>> This emulation replaces Xenomai's TSC emulation when the kernel boots on
>> a cpu without a TSC: the detection is made at run-time instead of
>> compilation time using self-modifying code (this in order to be able to
>> build Debian kernels which boots with any configuration).
> 
> Hmm, that's for the kernel. But what prevents rthal_setup_8254_tsc from
> being executed in addition? I'm currently a bit lost in the #ifdefs.


rthal_setup_8254_tsc is not called.

> 
>> There is no
>> reason to keep the compilation-time dependency on !INPUT_PCSPKR with
>> I-pipe core, as now the pc speaker is disabled at run-time too.
>> Unfortunately, I could not find how to arrange the Kconfig either.
> 
> As this is only about practically unsupported combinations of Xenomai
> (2.6.x) and I-pipe (for kernel 2.6.x) on x86, we could move from a
> configure-time to a build-time detection (#ifdef CONFIG_INPUT_PCSPKR ->
> BUILD_BUG()).


There is already a run-time detection which simply does not declare the
PC speaker platform device when there is no tsc.

-- 
                                                                Gilles.

Re: [Xenomai] i8253 clocksource vs. rthal_get_8254_tsc

[Jan Kiszka]

On 2013-02-06 13:31, Gilles Chanteperdrix wrote:
> On 02/06/2013 01:28 PM, Jan Kiszka wrote:
> 
>> On 2013-02-06 13:18, Gilles Chanteperdrix wrote:
>>> On 02/06/2013 11:20 AM, Jan Kiszka wrote:
>>>
>>>> Hi Gilles,
>>>>
>>>> I just realized that there is now a 8253 clocksource in core-3.4+. How
>>>> does this work together with Xenomai's TSC emulation via the 8254 in the
>>>> x86 hal_32? Xenomai reprograms the PIT in rthal_setup_8254_tsc - is this
>>>> harmless?
>>>>
>>>> I came across this while trying to get rid of Xenomai's "depends on
>>>> !INPUT_PCSPKR" to avoid that circular Kbuild dependency.
>>>
>>>
>>> This emulation replaces Xenomai's TSC emulation when the kernel boots on
>>> a cpu without a TSC: the detection is made at run-time instead of
>>> compilation time using self-modifying code (this in order to be able to
>>> build Debian kernels which boots with any configuration).
>>
>> Hmm, that's for the kernel. But what prevents rthal_setup_8254_tsc from
>> being executed in addition? I'm currently a bit lost in the #ifdefs.
> 
> 
> rthal_setup_8254_tsc is not called.
> 
>>
>>> There is no
>>> reason to keep the compilation-time dependency on !INPUT_PCSPKR with
>>> I-pipe core, as now the pc speaker is disabled at run-time too.
>>> Unfortunately, I could not find how to arrange the Kconfig either.
>>
>> As this is only about practically unsupported combinations of Xenomai
>> (2.6.x) and I-pipe (for kernel 2.6.x) on x86, we could move from a
>> configure-time to a build-time detection (#ifdef CONFIG_INPUT_PCSPKR ->
>> BUILD_BUG()).
> 
> 
> There is already a run-time detection which simply does not declare the
> PC speaker platform device when there is no tsc.

That's for core-3.4+, but not for older kernels. If we are fine with
ignoring them, I'll just write a patch to remove that Kconfig dependency.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] i8253 clocksource vs. rthal_get_8254_tsc

[Gilles Chanteperdrix]

On 02/06/2013 01:33 PM, Jan Kiszka wrote:

> On 2013-02-06 13:31, Gilles Chanteperdrix wrote:
>> On 02/06/2013 01:28 PM, Jan Kiszka wrote:
>>
>>> On 2013-02-06 13:18, Gilles Chanteperdrix wrote:
>>>> On 02/06/2013 11:20 AM, Jan Kiszka wrote:
>>>>
>>>>> Hi Gilles,
>>>>>
>>>>> I just realized that there is now a 8253 clocksource in core-3.4+. How
>>>>> does this work together with Xenomai's TSC emulation via the 8254 in the
>>>>> x86 hal_32? Xenomai reprograms the PIT in rthal_setup_8254_tsc - is this
>>>>> harmless?
>>>>>
>>>>> I came across this while trying to get rid of Xenomai's "depends on
>>>>> !INPUT_PCSPKR" to avoid that circular Kbuild dependency.
>>>>
>>>>
>>>> This emulation replaces Xenomai's TSC emulation when the kernel boots on
>>>> a cpu without a TSC: the detection is made at run-time instead of
>>>> compilation time using self-modifying code (this in order to be able to
>>>> build Debian kernels which boots with any configuration).
>>>
>>> Hmm, that's for the kernel. But what prevents rthal_setup_8254_tsc from
>>> being executed in addition? I'm currently a bit lost in the #ifdefs.
>>
>>
>> rthal_setup_8254_tsc is not called.
>>
>>>
>>>> There is no
>>>> reason to keep the compilation-time dependency on !INPUT_PCSPKR with
>>>> I-pipe core, as now the pc speaker is disabled at run-time too.
>>>> Unfortunately, I could not find how to arrange the Kconfig either.
>>>
>>> As this is only about practically unsupported combinations of Xenomai
>>> (2.6.x) and I-pipe (for kernel 2.6.x) on x86, we could move from a
>>> configure-time to a build-time detection (#ifdef CONFIG_INPUT_PCSPKR ->
>>> BUILD_BUG()).
>>
>>
>> There is already a run-time detection which simply does not declare the
>> PC speaker platform device when there is no tsc.
> 
> That's for core-3.4+, but not for older kernels. If we are fine with
> ignoring them, I'll just write a patch to remove that Kconfig dependency.


You could replace !INPUT_PCSPKR with !X86_TSC && !INPUT_PCSPKR
I-pipe core kernels can be compiled with CONFIG_X86_TSC anyway.

-- 
                                                                Gilles.

Re: [Xenomai] i8253 clocksource vs. rthal_get_8254_tsc

[Jan Kiszka]

On 2013-02-06 13:36, Gilles Chanteperdrix wrote:
> On 02/06/2013 01:33 PM, Jan Kiszka wrote:
> 
>> On 2013-02-06 13:31, Gilles Chanteperdrix wrote:
>>> On 02/06/2013 01:28 PM, Jan Kiszka wrote:
>>>
>>>> On 2013-02-06 13:18, Gilles Chanteperdrix wrote:
>>>>> On 02/06/2013 11:20 AM, Jan Kiszka wrote:
>>>>>
>>>>>> Hi Gilles,
>>>>>>
>>>>>> I just realized that there is now a 8253 clocksource in core-3.4+. How
>>>>>> does this work together with Xenomai's TSC emulation via the 8254 in the
>>>>>> x86 hal_32? Xenomai reprograms the PIT in rthal_setup_8254_tsc - is this
>>>>>> harmless?
>>>>>>
>>>>>> I came across this while trying to get rid of Xenomai's "depends on
>>>>>> !INPUT_PCSPKR" to avoid that circular Kbuild dependency.
>>>>>
>>>>>
>>>>> This emulation replaces Xenomai's TSC emulation when the kernel boots on
>>>>> a cpu without a TSC: the detection is made at run-time instead of
>>>>> compilation time using self-modifying code (this in order to be able to
>>>>> build Debian kernels which boots with any configuration).
>>>>
>>>> Hmm, that's for the kernel. But what prevents rthal_setup_8254_tsc from
>>>> being executed in addition? I'm currently a bit lost in the #ifdefs.
>>>
>>>
>>> rthal_setup_8254_tsc is not called.
>>>
>>>>
>>>>> There is no
>>>>> reason to keep the compilation-time dependency on !INPUT_PCSPKR with
>>>>> I-pipe core, as now the pc speaker is disabled at run-time too.
>>>>> Unfortunately, I could not find how to arrange the Kconfig either.
>>>>
>>>> As this is only about practically unsupported combinations of Xenomai
>>>> (2.6.x) and I-pipe (for kernel 2.6.x) on x86, we could move from a
>>>> configure-time to a build-time detection (#ifdef CONFIG_INPUT_PCSPKR ->
>>>> BUILD_BUG()).
>>>
>>>
>>> There is already a run-time detection which simply does not declare the
>>> PC speaker platform device when there is no tsc.
>>
>> That's for core-3.4+, but not for older kernels. If we are fine with
>> ignoring them, I'll just write a patch to remove that Kconfig dependency.
> 
> 
> You could replace !INPUT_PCSPKR with !X86_TSC && !INPUT_PCSPKR
> I-pipe core kernels can be compiled with CONFIG_X86_TSC anyway.

We already have "depend on (X86_TSC || !X86 || !INPUT_PCSPKR)", and
that's not impressing kconfig's dependency analyzer. I suppose it is not
taking the ! into account in its cycle detection.

CONFIG A
	depends on !B

CONFIG B
	depends on !A

A cycle, but harmless.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux