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
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
