Re: [Xenomai] About the timer interrupt in beaglebone
On Thu, Jan 03, 2013 at 09:19:37PM +0100, Gilles Chanteperdrix wrote: Of course some of the code they contain is not really acceptable in mainline, but at least it is there and takes less time to debug than it would if starting from scratch. That it takes less time is only sometimes true. Just trying to give a different opinion from Richard. I actually agree with you, Gilles. If you are developing a consumer device - with a three year product lifetime - that will never receive a firmware upgrade - where time to market is most important then the TI kernel is the best choice. But if you want to build, let's say, a platform for a family of products with a five to ten year scope, then maybe using TI's heavily modified v3.2 kernel is not best way. In any case, what is clearly best for the community is having mainline support. I myself am interested in and am willing to help out with xenomai on the beaglebone, but I will not waste my time with the TI kernel. It is just too far away for me. Thanks, Richard ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] About the timer interrupt in beaglebone
Jack, Am 03.01.2013 um 23:00 schrieb Jack Mitchell: On 03/01/2013 09:18, Michael Haberler wrote: Am 03.01.2013 um 09:53 schrieb Richard Cochran: On Wed, Jan 02, 2013 at 10:40:05AM +0100, Henri Roosen wrote: My decision to base the port on the Arago project was also that it looked 'most TI official' to me. TI ships an evaluation disk with the AM335x-evm board that is based on this project. The arago thing has gazillions of hacks, must of which are never going mainline. I would avoid it if at all possible. I have been pushing to get the beaglebone working out of the box in mainline Linux, and as of v3.8-rc2 it does work with a ramfs and Ethernet networking. However, I don't know which other drivers are still not working on that board. Richard - fine, but my requirement is a working Xenomai kernel with - in the minimum - GPIO, PRU, PWM, cape support, and I dont see that combination of Xenomai and v.3.8 around the corner anyday soon what would you then suggest as an alternative base for getting Xenomai to run on the beaglebone with the above laundry list? OT: I would suggest now starting with [1] for any beaglebone based work. The only thing that I'm not sure about is PRU support. it looks like PRU support is in fact included: config: https://github.com/beagleboard/kernel/commit/fb146ec635a8a6cab3527a924a0e068d382f2549 driver: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/uio/uio_pruss.c;h=6e2ab007fe9c03fc7768bf84144155f73e1bd871;hb=d1c3ed669a2d452cacfb48c2d171a1f364dae2ed thanks! Michael ps: OT - we have a 200kHz software stepper motor driver running on the PRU by now - while the main CPU is idle; there's no realistic chance of getting anywhere near this figure without the PRU Regards, Jack [1] https://github.com/beagleboard/kernel/tree/3.8 - Michael ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] About the timer interrupt in beaglebone
On Fri, Jan 04, 2013 at 10:50:07AM +0100, Gilles Chanteperdrix wrote: Well, at some point you can still decide to abandon the vendor driver and start from scratch. Well, yes, you will probably only do this when you have to. And then you will cry a tear for your wasted efforts :,( Thanks to the stable kernel releases, a kernel still gets updates for security fixes. But not for TI's out of tree bugs. A product I have worked on around three years ago used the 2.6.32 kernel from the arago tree, this looks old, but on the other hand, the debian stable distribution default kernel running on the xenomai.org server is also based on the 2.6.32 kernel. But does debian have as many custom patches as TI? I would guess not. I agree with that too, and I would like to help mainline the support for the TI processors I am using at work, but the fact is that at work, I do not really have time to do it, because the drivers for the TI processor I am working with (the TI processors for video encoding, ex-DaVinci family) represent big masses of code, and getting code into mainline means many iterations, especially for someone who does not do it often, and at home, well, most of the time I devote to free-software contributions is devoted to the xenomai project. Maybe I was discouraged by the attempt of contributing the FCSE patch too. FCSE is a special, esoteric case I think. New drivers are not so hard to get merged, but you are right about the iterations. The effort should come from TI, because if the support for new processors directly lands into mainline, we will no longer have to choose between the vendor kernel and the mainline kernel. I guess that is the point of having created Linaro. Yep, but TI is only willing to spend so much effort. It is frustrating to watch how they and other vendors go about their Linux support. Thanks, Richard ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] XNARCH_TIMER_IRQ
On 2013-01-04 11:01, Philippe Gerum wrote: On 01/03/2013 06:57 PM, Jan Kiszka wrote: On 2013-01-03 18:34, Philippe Gerum wrote: On 01/03/2013 06:25 PM, Jan Kiszka wrote: On 2013-01-03 17:27, Philippe Gerum wrote: On 01/03/2013 04:44 PM, Jan Kiszka wrote: On 2013-01-03 16:16, Gilles Chanteperdrix wrote: On 01/02/2013 06:43 PM, Jan Kiszka wrote: Hi, this may involve some refactoring of the HAL and a bit of I-pipe, so I better ask first: Not sure when it changed, but XNARCH_TIMER_IRQ may no longer return the same values when called on different CPUs. Therefore, It should rather be called XNARCH_THIS_CPU_TIMER_IRQ now. Looking at its users (an I-pipe debug warning pointed it out), there are two that don't expect this: xnintr_query_next() and format_irq_proc(). The former actually wants XNARCH_TIMER_IRQ(cpu), the latter needs something like is_timer_irq_on_any_cpus(irq). So I would propose to refactor XNARCH_TIMER_IRQ and RTHAL_TIMER_IRQ accordingly. But this unfortunately requires extensions of I-pipe to provide something like __ipipe_hrtimer_irq(cpu) and __ipipe_this_cpu_hrtimer_irq. And some ugly workaround in Xenomai for older I-pipe versions. Does this make sense? Made something similar for forge: http://git.xenomai.org/?p=xenomai-gch.git;a=commitdiff;h=37ca257af466e7e5fbfb402b39f088487d048fd5;hp=a9971c363fd361b428f12200536bc5a01dff9c05 Caution, this code is WIP. nktimer will have to move to the percpu scheduler descriptor to complete this. That's nkclock in 2.6. Mostly a cosmetic issue, the interrupt name will not be properly printed, statistics are already per-cpu. Could be improved nevertheless. My point is to tell you that what you look to in -forge regarding this area is in a state of flux. I'm not referring to 2.6, I'm focusing almost exclusively on 3.x these days. Is there an easy way to find out if we have per-CPU timers on some arch? Why should we assume differently? To avoid dumping redundant statistic lines when some timer IRQ has no home on a given CPU. But as there are also mixed setups possible as Gilles pointed out, we need a different approach, likely just skip when there are no hits. Your question sounded like is it possible to know whether an SMP arch may use different per-CPU IRQs for the timer. I was about to answer that testing for any pipeline core API rev = 2 would do, excluding all legacy patches. For the cosmetic issue you mention, testing rthal_supported_cpus would do. Nope, this is not sufficient. A per-CPU timer IRQ would then still generate useless lines in stat for all those CPUs it is not bound to. I'll resume the work on this as soon as I found the reason for the zero page corruption we face now with 3.5. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] XNARCH_TIMER_IRQ
On 01/04/2013 11:16 AM, Jan Kiszka wrote: On 2013-01-04 11:01, Philippe Gerum wrote: On 01/03/2013 06:57 PM, Jan Kiszka wrote: On 2013-01-03 18:34, Philippe Gerum wrote: On 01/03/2013 06:25 PM, Jan Kiszka wrote: On 2013-01-03 17:27, Philippe Gerum wrote: On 01/03/2013 04:44 PM, Jan Kiszka wrote: On 2013-01-03 16:16, Gilles Chanteperdrix wrote: On 01/02/2013 06:43 PM, Jan Kiszka wrote: Hi, this may involve some refactoring of the HAL and a bit of I-pipe, so I better ask first: Not sure when it changed, but XNARCH_TIMER_IRQ may no longer return the same values when called on different CPUs. Therefore, It should rather be called XNARCH_THIS_CPU_TIMER_IRQ now. Looking at its users (an I-pipe debug warning pointed it out), there are two that don't expect this: xnintr_query_next() and format_irq_proc(). The former actually wants XNARCH_TIMER_IRQ(cpu), the latter needs something like is_timer_irq_on_any_cpus(irq). So I would propose to refactor XNARCH_TIMER_IRQ and RTHAL_TIMER_IRQ accordingly. But this unfortunately requires extensions of I-pipe to provide something like __ipipe_hrtimer_irq(cpu) and __ipipe_this_cpu_hrtimer_irq. And some ugly workaround in Xenomai for older I-pipe versions. Does this make sense? Made something similar for forge: http://git.xenomai.org/?p=xenomai-gch.git;a=commitdiff;h=37ca257af466e7e5fbfb402b39f088487d048fd5;hp=a9971c363fd361b428f12200536bc5a01dff9c05 Caution, this code is WIP. nktimer will have to move to the percpu scheduler descriptor to complete this. That's nkclock in 2.6. Mostly a cosmetic issue, the interrupt name will not be properly printed, statistics are already per-cpu. Could be improved nevertheless. My point is to tell you that what you look to in -forge regarding this area is in a state of flux. I'm not referring to 2.6, I'm focusing almost exclusively on 3.x these days. Is there an easy way to find out if we have per-CPU timers on some arch? Why should we assume differently? To avoid dumping redundant statistic lines when some timer IRQ has no home on a given CPU. But as there are also mixed setups possible as Gilles pointed out, we need a different approach, likely just skip when there are no hits. Your question sounded like is it possible to know whether an SMP arch may use different per-CPU IRQs for the timer. I was about to answer that testing for any pipeline core API rev = 2 would do, excluding all legacy patches. For the cosmetic issue you mention, testing rthal_supported_cpus would do. Nope, this is not sufficient. A per-CPU timer IRQ would then still generate useless lines in stat for all those CPUs it is not bound to. What we can do is, like linux, not print any irq number for the timer irq, simply something like local timer, in which case whether the local timer irq is the same on all cpus or not does not matter. -- Gilles. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] XNARCH_TIMER_IRQ
On 01/04/2013 11:16 AM, Jan Kiszka wrote: On 2013-01-04 11:01, Philippe Gerum wrote: On 01/03/2013 06:57 PM, Jan Kiszka wrote: On 2013-01-03 18:34, Philippe Gerum wrote: On 01/03/2013 06:25 PM, Jan Kiszka wrote: On 2013-01-03 17:27, Philippe Gerum wrote: On 01/03/2013 04:44 PM, Jan Kiszka wrote: On 2013-01-03 16:16, Gilles Chanteperdrix wrote: On 01/02/2013 06:43 PM, Jan Kiszka wrote: Hi, this may involve some refactoring of the HAL and a bit of I-pipe, so I better ask first: Not sure when it changed, but XNARCH_TIMER_IRQ may no longer return the same values when called on different CPUs. Therefore, It should rather be called XNARCH_THIS_CPU_TIMER_IRQ now. Looking at its users (an I-pipe debug warning pointed it out), there are two that don't expect this: xnintr_query_next() and format_irq_proc(). The former actually wants XNARCH_TIMER_IRQ(cpu), the latter needs something like is_timer_irq_on_any_cpus(irq). So I would propose to refactor XNARCH_TIMER_IRQ and RTHAL_TIMER_IRQ accordingly. But this unfortunately requires extensions of I-pipe to provide something like __ipipe_hrtimer_irq(cpu) and __ipipe_this_cpu_hrtimer_irq. And some ugly workaround in Xenomai for older I-pipe versions. Does this make sense? Made something similar for forge: http://git.xenomai.org/?p=xenomai-gch.git;a=commitdiff;h=37ca257af466e7e5fbfb402b39f088487d048fd5;hp=a9971c363fd361b428f12200536bc5a01dff9c05 Caution, this code is WIP. nktimer will have to move to the percpu scheduler descriptor to complete this. That's nkclock in 2.6. Mostly a cosmetic issue, the interrupt name will not be properly printed, statistics are already per-cpu. Could be improved nevertheless. My point is to tell you that what you look to in -forge regarding this area is in a state of flux. I'm not referring to 2.6, I'm focusing almost exclusively on 3.x these days. Is there an easy way to find out if we have per-CPU timers on some arch? Why should we assume differently? To avoid dumping redundant statistic lines when some timer IRQ has no home on a given CPU. But as there are also mixed setups possible as Gilles pointed out, we need a different approach, likely just skip when there are no hits. Your question sounded like is it possible to know whether an SMP arch may use different per-CPU IRQs for the timer. I was about to answer that testing for any pipeline core API rev = 2 would do, excluding all legacy patches. For the cosmetic issue you mention, testing rthal_supported_cpus would do. Nope, this is not sufficient. A per-CPU timer IRQ would then still generate useless lines in stat for all those CPUs it is not bound to. You know which CPU has a real-time timer attached via rthal_supported_cpus, which timer IRQ # is attached to each real-time CPU when per-CPU timer IRQs are supported by the pipeline. For legacy patches which only allow a common IRQ line for all timers regardless of the CPU, the matter is solved by design. I still don't get where the issue would be. I'll resume the work on this as soon as I found the reason for the zero page corruption we face now with 3.5. Jan -- Philippe. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] XNARCH_TIMER_IRQ
On 2013-01-04 11:32, Philippe Gerum wrote: On 01/04/2013 11:16 AM, Jan Kiszka wrote: On 2013-01-04 11:01, Philippe Gerum wrote: On 01/03/2013 06:57 PM, Jan Kiszka wrote: On 2013-01-03 18:34, Philippe Gerum wrote: On 01/03/2013 06:25 PM, Jan Kiszka wrote: On 2013-01-03 17:27, Philippe Gerum wrote: On 01/03/2013 04:44 PM, Jan Kiszka wrote: On 2013-01-03 16:16, Gilles Chanteperdrix wrote: On 01/02/2013 06:43 PM, Jan Kiszka wrote: Hi, this may involve some refactoring of the HAL and a bit of I-pipe, so I better ask first: Not sure when it changed, but XNARCH_TIMER_IRQ may no longer return the same values when called on different CPUs. Therefore, It should rather be called XNARCH_THIS_CPU_TIMER_IRQ now. Looking at its users (an I-pipe debug warning pointed it out), there are two that don't expect this: xnintr_query_next() and format_irq_proc(). The former actually wants XNARCH_TIMER_IRQ(cpu), the latter needs something like is_timer_irq_on_any_cpus(irq). So I would propose to refactor XNARCH_TIMER_IRQ and RTHAL_TIMER_IRQ accordingly. But this unfortunately requires extensions of I-pipe to provide something like __ipipe_hrtimer_irq(cpu) and __ipipe_this_cpu_hrtimer_irq. And some ugly workaround in Xenomai for older I-pipe versions. Does this make sense? Made something similar for forge: http://git.xenomai.org/?p=xenomai-gch.git;a=commitdiff;h=37ca257af466e7e5fbfb402b39f088487d048fd5;hp=a9971c363fd361b428f12200536bc5a01dff9c05 Caution, this code is WIP. nktimer will have to move to the percpu scheduler descriptor to complete this. That's nkclock in 2.6. Mostly a cosmetic issue, the interrupt name will not be properly printed, statistics are already per-cpu. Could be improved nevertheless. My point is to tell you that what you look to in -forge regarding this area is in a state of flux. I'm not referring to 2.6, I'm focusing almost exclusively on 3.x these days. Is there an easy way to find out if we have per-CPU timers on some arch? Why should we assume differently? To avoid dumping redundant statistic lines when some timer IRQ has no home on a given CPU. But as there are also mixed setups possible as Gilles pointed out, we need a different approach, likely just skip when there are no hits. Your question sounded like is it possible to know whether an SMP arch may use different per-CPU IRQs for the timer. I was about to answer that testing for any pipeline core API rev = 2 would do, excluding all legacy patches. For the cosmetic issue you mention, testing rthal_supported_cpus would do. Nope, this is not sufficient. A per-CPU timer IRQ would then still generate useless lines in stat for all those CPUs it is not bound to. You know which CPU has a real-time timer attached via rthal_supported_cpus, which timer IRQ # is attached to each real-time CPU when per-CPU timer IRQs are supported by the pipeline. For legacy patches which only allow a common IRQ line for all timers regardless of the CPU, the matter is solved by design. I still don't get where the issue would be. rthal_supported_cpus doesn't contain enough information. We need is_valid_irq(irq, cpu): if (timer_irq(cpu) == irq) return true for_each_cpu(n) if (timer_irq(n) == irq) return false return true for a cleaned up /stat output as we iterate over all combinations of (irq, cpu) there. That for_each_cpu is a bit ugly, and that's why I was considering to derive is_valid_irq from irq.hits 0. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] XNARCH_TIMER_IRQ
On 01/04/2013 12:22 PM, Jan Kiszka wrote: On 2013-01-04 11:32, Philippe Gerum wrote: On 01/04/2013 11:16 AM, Jan Kiszka wrote: On 2013-01-04 11:01, Philippe Gerum wrote: On 01/03/2013 06:57 PM, Jan Kiszka wrote: On 2013-01-03 18:34, Philippe Gerum wrote: On 01/03/2013 06:25 PM, Jan Kiszka wrote: On 2013-01-03 17:27, Philippe Gerum wrote: On 01/03/2013 04:44 PM, Jan Kiszka wrote: On 2013-01-03 16:16, Gilles Chanteperdrix wrote: On 01/02/2013 06:43 PM, Jan Kiszka wrote: Hi, this may involve some refactoring of the HAL and a bit of I-pipe, so I better ask first: Not sure when it changed, but XNARCH_TIMER_IRQ may no longer return the same values when called on different CPUs. Therefore, It should rather be called XNARCH_THIS_CPU_TIMER_IRQ now. Looking at its users (an I-pipe debug warning pointed it out), there are two that don't expect this: xnintr_query_next() and format_irq_proc(). The former actually wants XNARCH_TIMER_IRQ(cpu), the latter needs something like is_timer_irq_on_any_cpus(irq). So I would propose to refactor XNARCH_TIMER_IRQ and RTHAL_TIMER_IRQ accordingly. But this unfortunately requires extensions of I-pipe to provide something like __ipipe_hrtimer_irq(cpu) and __ipipe_this_cpu_hrtimer_irq. And some ugly workaround in Xenomai for older I-pipe versions. Does this make sense? Made something similar for forge: http://git.xenomai.org/?p=xenomai-gch.git;a=commitdiff;h=37ca257af466e7e5fbfb402b39f088487d048fd5;hp=a9971c363fd361b428f12200536bc5a01dff9c05 Caution, this code is WIP. nktimer will have to move to the percpu scheduler descriptor to complete this. That's nkclock in 2.6. Mostly a cosmetic issue, the interrupt name will not be properly printed, statistics are already per-cpu. Could be improved nevertheless. My point is to tell you that what you look to in -forge regarding this area is in a state of flux. I'm not referring to 2.6, I'm focusing almost exclusively on 3.x these days. Is there an easy way to find out if we have per-CPU timers on some arch? Why should we assume differently? To avoid dumping redundant statistic lines when some timer IRQ has no home on a given CPU. But as there are also mixed setups possible as Gilles pointed out, we need a different approach, likely just skip when there are no hits. Your question sounded like is it possible to know whether an SMP arch may use different per-CPU IRQs for the timer. I was about to answer that testing for any pipeline core API rev = 2 would do, excluding all legacy patches. For the cosmetic issue you mention, testing rthal_supported_cpus would do. Nope, this is not sufficient. A per-CPU timer IRQ would then still generate useless lines in stat for all those CPUs it is not bound to. You know which CPU has a real-time timer attached via rthal_supported_cpus, which timer IRQ # is attached to each real-time CPU when per-CPU timer IRQs are supported by the pipeline. For legacy patches which only allow a common IRQ line for all timers regardless of the CPU, the matter is solved by design. I still don't get where the issue would be. rthal_supported_cpus doesn't contain enough information. We need is_valid_irq(irq, cpu): if (timer_irq(cpu) == irq) return true for_each_cpu(n) if (timer_irq(n) == irq) return false return true for a cleaned up /stat output as we iterate over all combinations of (irq, cpu) there. That for_each_cpu is a bit ugly, and that's why I was considering to derive is_valid_irq from irq.hits 0. The problem goes away with cpus displayed on lines, and irq # on columns. -- Philippe. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] XNARCH_TIMER_IRQ
On 2013-01-04 12:33, Philippe Gerum wrote: On 01/04/2013 12:22 PM, Jan Kiszka wrote: On 2013-01-04 11:32, Philippe Gerum wrote: On 01/04/2013 11:16 AM, Jan Kiszka wrote: On 2013-01-04 11:01, Philippe Gerum wrote: On 01/03/2013 06:57 PM, Jan Kiszka wrote: On 2013-01-03 18:34, Philippe Gerum wrote: On 01/03/2013 06:25 PM, Jan Kiszka wrote: On 2013-01-03 17:27, Philippe Gerum wrote: On 01/03/2013 04:44 PM, Jan Kiszka wrote: On 2013-01-03 16:16, Gilles Chanteperdrix wrote: On 01/02/2013 06:43 PM, Jan Kiszka wrote: Hi, this may involve some refactoring of the HAL and a bit of I-pipe, so I better ask first: Not sure when it changed, but XNARCH_TIMER_IRQ may no longer return the same values when called on different CPUs. Therefore, It should rather be called XNARCH_THIS_CPU_TIMER_IRQ now. Looking at its users (an I-pipe debug warning pointed it out), there are two that don't expect this: xnintr_query_next() and format_irq_proc(). The former actually wants XNARCH_TIMER_IRQ(cpu), the latter needs something like is_timer_irq_on_any_cpus(irq). So I would propose to refactor XNARCH_TIMER_IRQ and RTHAL_TIMER_IRQ accordingly. But this unfortunately requires extensions of I-pipe to provide something like __ipipe_hrtimer_irq(cpu) and __ipipe_this_cpu_hrtimer_irq. And some ugly workaround in Xenomai for older I-pipe versions. Does this make sense? Made something similar for forge: http://git.xenomai.org/?p=xenomai-gch.git;a=commitdiff;h=37ca257af466e7e5fbfb402b39f088487d048fd5;hp=a9971c363fd361b428f12200536bc5a01dff9c05 Caution, this code is WIP. nktimer will have to move to the percpu scheduler descriptor to complete this. That's nkclock in 2.6. Mostly a cosmetic issue, the interrupt name will not be properly printed, statistics are already per-cpu. Could be improved nevertheless. My point is to tell you that what you look to in -forge regarding this area is in a state of flux. I'm not referring to 2.6, I'm focusing almost exclusively on 3.x these days. Is there an easy way to find out if we have per-CPU timers on some arch? Why should we assume differently? To avoid dumping redundant statistic lines when some timer IRQ has no home on a given CPU. But as there are also mixed setups possible as Gilles pointed out, we need a different approach, likely just skip when there are no hits. Your question sounded like is it possible to know whether an SMP arch may use different per-CPU IRQs for the timer. I was about to answer that testing for any pipeline core API rev = 2 would do, excluding all legacy patches. For the cosmetic issue you mention, testing rthal_supported_cpus would do. Nope, this is not sufficient. A per-CPU timer IRQ would then still generate useless lines in stat for all those CPUs it is not bound to. You know which CPU has a real-time timer attached via rthal_supported_cpus, which timer IRQ # is attached to each real-time CPU when per-CPU timer IRQs are supported by the pipeline. For legacy patches which only allow a common IRQ line for all timers regardless of the CPU, the matter is solved by design. I still don't get where the issue would be. rthal_supported_cpus doesn't contain enough information. We need is_valid_irq(irq, cpu): if (timer_irq(cpu) == irq) return true for_each_cpu(n) if (timer_irq(n) == irq) return false return true for a cleaned up /stat output as we iterate over all combinations of (irq, cpu) there. That for_each_cpu is a bit ugly, and that's why I was considering to derive is_valid_irq from irq.hits 0. The problem goes away with cpus displayed on lines, and irq # on columns. Not applicable to /stat. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] About the timer interrupt in beaglebone
On 01/04/2013 11:04 AM, Richard Cochran wrote: FCSE is a special, esoteric case I think. New drivers are not so hard to get merged, but you are right about the iterations. Is it? Still working on that consumer device I have another example of patch that never made it to mainline. Maybe simply different communities have different goals? http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2011-January/021885.html https://lkml.org/lkml/2011/2/3/43 for a consumer device, it makes sense to continue working properly even if a storage device was removed uncleanly, the linux community, on the other hand, may consider this issue a corner case, just like using the FCSE. -- Gilles. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
[Xenomai] (no subject)
I am starting my project on pandaboard(OMAP4430).For that I want to know the stable supported version of linux,xenomai adeos patch for that board. Thank you. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] About the timer interrupt in beaglebone
On Fri, Jan 04, 2013 at 03:16:12PM +0100, Gilles Chanteperdrix wrote: On 01/04/2013 11:04 AM, Richard Cochran wrote: FCSE is a special, esoteric case I think. New drivers are not so hard to get merged, but you are right about the iterations. Is it? Still working on that consumer device I have another example of patch that never made it to mainline. Maybe simply different communities have different goals? http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2011-January/021885.html https://lkml.org/lkml/2011/2/3/43 Looks like this patch didn't go to the arm list, the arm maintainer, or the soc mainainter, and it probably should have. In any case, if a patch gets ignored, then it is okay to nag* the gate keepers until they respond. The squeaky wheel gets the grease, you know. I was able to push the beaglebone to the present (v3.8-rc2) state of actually booting with Ethernet working only by kicking and screaming on the arm list. The real problem there is the TI people who are posting the the lists, but fail to follow through, saying things like it is already working (but only with their out of tree patches) and we submitted a patch that will appear soon (but the patch is only on some omap list an not in maintainer tree) and yes, we got driver merged into the tree, but it is not our fault that it doesn't actually work. The TI people are clearly focused on their arago-whatever trees, and they are not gettings things done for mainline. That is the whole problem. Thanks, Richard * Post to the arm list. That is the one that counts. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] About the timer interrupt in beaglebone
On Fri, Jan 04, 2013 at 03:16:12PM +0100, Gilles Chanteperdrix wrote: https://lkml.org/lkml/2011/2/3/43 Also, that patch says RFC. After getting no feedback, I would have resubmitted a bugfix or something more assertive in the subject line. Thanks, Richard ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] xenomai version for pandaboard
On 01/04/2013 03:37 PM, RAGHAVENDRA GANIGA wrote: I am starting my project on pandaboard(OMAP4430).For that I want to know the stable supported version of linux,xenomai adeos patch for that board. Thank you. The pandaboard is supported in all the the I-pipe patches for linux versions greater than 2.6.37 and all xenomai stable versions since 2.6.0. Please use a subject next time you post a message. -- Gilles. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
