Re: [Xenomai-core] Xenomai on PXA
Gilles Chanteperdrix wrote: Philippe Gerum wrote: Fixing the I-pipe is the way to go, definitely. If I understand this correctly, the best way to handle the demux case is to implement an I-pipe variant of the demultiplexing code currently available in pxa_gpio_demux_handler(), which would be called from __ipipe_grab_irq() when processing the multiplexed interrupt channel. The I-pipe-specific demux code would then log the decoded IRQ by a call to __ipipe_handle_irq() instead of running the root handler directly (i.e. desc_handle_irq), which would in turn preserve the ability to wire GPIO interrupts and also handle IRQ stickiness issues. This was also my first idea. But after a bit of musing on that idea, I'm not really sure that this is the best way to go. We're talking here about more than 100 bits that have to be tested one after the other (on PXA270, it's 116, though the actual code checks 126 bits), and even on a fast CPU this takes some time. So I've thought about a way to register a GPIO-IRQ into I-pipe that gets checked directly under I-pipe, while all other GPIOs are only checked and handled in the domain that handles the original multiplexing IRQ. But I have to admit that I have no idea how to implement that... [snip] +++ linux-2.6.16.5-tcl1-ipipe/arch/arm/mach-pxa/irq.c 2006-08-03 19:04:52.0 +0200 +#ifdef CONFIG_IPIPE +void __ipipe_mach_demux_irq(unsigned irq, struct pt_regs *regs) + __ipipe_handle_irq(irq, regs); Just to check: this only marks the interrupt, but not actually handles it, doesn't it? Detlef -- Detlef Vollmann vollmann engineering gmbh Linux and C++ for Embedded Systemshttp://www.vollmann.ch/ Linux for PXA270 Colibri module: http://www.vollmann.ch/en/colibri/ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai on PXA
On Thu, 2006-08-03 at 19:14 +0200, Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
On Thu, 2006-08-03 at 15:18 +0200, Gilles Chanteperdrix wrote:
Bart Jonkers wrote:
Here is a new version of the ipipe-sa1100-pxa patch that unmaks
interrupts at the end of the demux handlers, and that attempt to
fix the
gettimeoffset issue. I have run 20 minutes (time for OSCR to wrap)
latency
with a test program verifying that time returned by gettimeofday is
never going backward.
The patch and the test program are attached, it would be nice if you
could test them.
I have tested the patch and ran the test program.
The test program give no problems.
The interrupt problem in Linux is also solved. But I have another one.
I have created a small real-time kernel module which uses the native
interface to handle an GPIO interrupt. The problem is that Xenomai
doesn't see the interrupt. When I use GPIO0 (which doesn't use the
chained handler) to receive the interrupt everything works as it
should.
So it seems to be that xenomai have a problem with the chained
handler.
Does someone have an idea to solve this problem?
The problem is that the demux handler is a root domain handler, and
directly call the cascaded interrupts root domain handlers through
desc_handle_irq, whereas in order for the I-pipe to intercept the
interrupt for any domain, the demux handler should be run for any
domain, and invoke __ipipe_grab_irq, __ipipe_handle_irq or
ipipe_trigger_irq so that the cascaded interrupts are pipelined.
So, there are two possible fixes:
- either fix the I-pipe patch so that the demux handler is invoked when
the multiplexed interrupt is received for any domain, and triggers
interrupts through ipipe_trigger_irq;
Fixing the I-pipe is the way to go, definitely. If I understand this
correctly, the best way to handle the demux case is to implement an
I-pipe variant of the demultiplexing code currently available in
pxa_gpio_demux_handler(), which would be called from __ipipe_grab_irq()
when processing the multiplexed interrupt channel.
The I-pipe-specific demux code would then log the decoded IRQ by a call
to __ipipe_handle_irq() instead of running the root handler directly
(i.e. desc_handle_irq), which would in turn preserve the ability to
wire GPIO interrupts and also handle IRQ stickiness issues.
This would resemble what we are doing right now on the powerpc arch,
pulling the received IRQ number from a request to the machine-dependent
layer. I'd see no issue in duplicating such handling since this is a
rather short piece of invariant, hw-specific code which would not depend
on Linux internals, but rather on the I-pipe's.
Ok, here is an implementation of this idea for integrator_cp, sa1100 and
pxa as a patch that should be applied after the ipipe patch. As usual,
Bart, could you test it ?
Tested. It works, now it is possible to receive GPIO interrupts in the
real-time domain.
Bart
plain text document attachment (ipipe-sa1100-pxa.3.patch)
diff -Naurdp -x '*~' -x '*.orig' -x '*.rej'
linux-2.6.16.5-tcl1-ipipe-ref/arch/arm/kernel/ipipe-root.c
linux-2.6.16.5-tcl1-ipipe/arch/arm/kernel/ipipe-root.c
--- linux-2.6.16.5-tcl1-ipipe-ref/arch/arm/kernel/ipipe-root.c
2006-08-03 18:08:48.0 +0200
+++ linux-2.6.16.5-tcl1-ipipe/arch/arm/kernel/ipipe-root.c2006-08-03
17:51:52.0 +0200
@@ -302,7 +302,10 @@ asmlinkage int __ipipe_grab_irq(int irq,
}
}
- __ipipe_handle_irq(irq, regs);
+ if (__ipipe_mach_irq_mux_p(irq))
+ __ipipe_mach_demux_irq(irq, regs);
+ else
+ __ipipe_handle_irq(irq, regs);
ipipe_load_cpuid();
diff -Naurdp -x '*~' -x '*.orig' -x '*.rej'
linux-2.6.16.5-tcl1-ipipe-ref/arch/arm/mach-integrator/integrator_cp.c
linux-2.6.16.5-tcl1-ipipe/arch/arm/mach-integrator/integrator_cp.c
--- linux-2.6.16.5-tcl1-ipipe-ref/arch/arm/mach-integrator/integrator_cp.c
2006-08-03 18:08:48.0 +0200
+++ linux-2.6.16.5-tcl1-ipipe/arch/arm/mach-integrator/integrator_cp.c
2006-08-03 19:05:46.0 +0200
@@ -20,6 +20,7 @@
#include linux/amba/bus.h
#include linux/amba/kmi.h
#include linux/amba/clcd.h
+#include linux/ipipe.h
#include asm/hardware.h
#include asm/io.h
@@ -220,6 +221,31 @@ sic_handle_irq(unsigned int irq, struct
} while (status);
}
+#ifdef CONFIG_IPIPE
+void __ipipe_mach_demux_irq(unsigned irq, struct pt_regs *regs)
+{
+ unsigned long status = sic_readl(INTCP_VA_SIC_BASE + IRQ_STATUS);
+ struct irqdesc *desc_unused = irq_desc + irq;
+ unsigned irq_unused = irq;
+
+ if (status == 0) {
+ do_bad_IRQ(irq, desc_unused, regs);
+ return;
+ }
+
+ do {
+ irq =
Re: [Xenomai-core] Future of Xenomai's RTDM driver repository
Philippe Gerum wrote: Hi Wolfgang, First of all, thx for the CAN stack. Great job. On Thu, 2006-08-03 at 09:58 +0200, Wolfgang Grandegger wrote: Jan Kiszka wrote: snip Now I would suggest to look at RTCAN (or what it will be called in the end) and to discuss on this first concrete example how we can proceed towards the sketched goal. Looking forward to your feedback! As you have said, maintaining a RTDM driver within the Xenomai repository clearly has some advantages but it also puts more burden onto the Xenomai maintainers and some developers might even prefer to keep thing separated. Therefore I suggest a simple RTDM add-on framework to support external RTDM drivers as well. They could be announced and listed on the Xenomai home page and then it would alsl be visible that there is a FireWire stack for Xenomai. What I had first was a add-rtdm-driver.sh, a modified version of Philippe's prepare-kernel.sh script, to add the RTDM driver to the kernel tree. Similarly, as script could be used to add loosely the driver to Xenomai. What do you think? I can't speak for Jan wrt providing a RTDM add-on framework, but since Xenomai is currently the reference platform for RTDM (at least, the real-time infrastructure over which most of this work is experimented, debugged and stabilized), I would rather seek integration of RTDM-based drivers into the Xenomai tree, instead of a complete separation. I understood that Jan also prefers driver integration into Xenomai. Just for some big external package like RTnet, an add-on would be nice to benefit from the Xenomai infrastructure (static linking, etc.). The reason being that it makes sense (to a Xenomai maintainer, that is) to reduce the odds of discrepancies between the core real-time framework, the driver infrastructure and the client drivers, at least while the first two are undergoing a rapid evolution. The same in-tree vs out-of-tree drivers maintenance dilema which is known from the kernel folks will also apply to us, if RTDM, and/or RTDM over Xenomai are as successful as we wish, i.e. creating opportunities to provide lots of RT drivers sharing a common infrastructure. Said differently, the day a significant number of people will start relying on a rich collection of RTDM-based drivers over Xenomai, we _will_ have maintenance issues to deal with, anyway, starting with answering a lot of questions on xenomai-whatever*. In such a case, I'd rather reduce the odds of integration issues between Xenomai-RTDM and/or RTDM/drivers. This said, I'm not saying that Xenomai should be the only RTDM-based driver repository in the long run; but I'm arguing that Xenomai could be used as a centripetal force to help developing and stabilizing the RT driver ecosystem around RTDM. OK, I can follow your arguments. It's fine for me. Thanks. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai on PXA
Detlef Vollmann wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: Fixing the I-pipe is the way to go, definitely. If I understand this correctly, the best way to handle the demux case is to implement an I-pipe variant of the demultiplexing code currently available in pxa_gpio_demux_handler(), which would be called from __ipipe_grab_irq() when processing the multiplexed interrupt channel. The I-pipe-specific demux code would then log the decoded IRQ by a call to __ipipe_handle_irq() instead of running the root handler directly (i.e. desc_handle_irq), which would in turn preserve the ability to wire GPIO interrupts and also handle IRQ stickiness issues. This was also my first idea. But after a bit of musing on that idea, I'm not really sure that this is the best way to go. We're talking here about more than 100 bits that have to be tested one after the other (on PXA270, it's 116, though the actual code checks 126 bits), and even on a fast CPU this takes some time. So I've thought about a way to register a GPIO-IRQ into I-pipe that gets checked directly under I-pipe, while all other GPIOs are only checked and handled in the domain that handles the original multiplexing IRQ. But I have to admit that I have no idea how to implement that... Maybe a reasonable alternative would be to use fls in order to find the set bits in the mask ? This way, if the masks are sparse, which they should be, we will skip a lot of checks. [snip] +++ linux-2.6.16.5-tcl1-ipipe/arch/arm/mach-pxa/irq.c 2006-08-03 19:04:52.0 +0200 +#ifdef CONFIG_IPIPE +void __ipipe_mach_demux_irq(unsigned irq, struct pt_regs *regs) + __ipipe_handle_irq(irq, regs); Just to check: this only marks the interrupt, but not actually handles it, doesn't it? This handles it if the current or higher domains have a registered handler and are not stalled. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai on PXA
On Thu, 2006-08-03 at 19:14 +0200, Gilles Chanteperdrix wrote: Philippe Gerum wrote: On Thu, 2006-08-03 at 15:18 +0200, Gilles Chanteperdrix wrote: Bart Jonkers wrote: Here is a new version of the ipipe-sa1100-pxa patch that unmaks interrupts at the end of the demux handlers, and that attempt to fix the gettimeoffset issue. I have run 20 minutes (time for OSCR to wrap) latency with a test program verifying that time returned by gettimeofday is never going backward. The patch and the test program are attached, it would be nice if you could test them. I have tested the patch and ran the test program. The test program give no problems. The interrupt problem in Linux is also solved. But I have another one. I have created a small real-time kernel module which uses the native interface to handle an GPIO interrupt. The problem is that Xenomai doesn't see the interrupt. When I use GPIO0 (which doesn't use the chained handler) to receive the interrupt everything works as it should. So it seems to be that xenomai have a problem with the chained handler. Does someone have an idea to solve this problem? The problem is that the demux handler is a root domain handler, and directly call the cascaded interrupts root domain handlers through desc_handle_irq, whereas in order for the I-pipe to intercept the interrupt for any domain, the demux handler should be run for any domain, and invoke __ipipe_grab_irq, __ipipe_handle_irq or ipipe_trigger_irq so that the cascaded interrupts are pipelined. So, there are two possible fixes: - either fix the I-pipe patch so that the demux handler is invoked when the multiplexed interrupt is received for any domain, and triggers interrupts through ipipe_trigger_irq; Fixing the I-pipe is the way to go, definitely. If I understand this correctly, the best way to handle the demux case is to implement an I-pipe variant of the demultiplexing code currently available in pxa_gpio_demux_handler(), which would be called from __ipipe_grab_irq() when processing the multiplexed interrupt channel. The I-pipe-specific demux code would then log the decoded IRQ by a call to __ipipe_handle_irq() instead of running the root handler directly (i.e. desc_handle_irq), which would in turn preserve the ability to wire GPIO interrupts and also handle IRQ stickiness issues. This would resemble what we are doing right now on the powerpc arch, pulling the received IRQ number from a request to the machine-dependent layer. I'd see no issue in duplicating such handling since this is a rather short piece of invariant, hw-specific code which would not depend on Linux internals, but rather on the I-pipe's. Ok, here is an implementation of this idea for integrator_cp, sa1100 and pxa as a patch that should be applied after the ipipe patch. As usual, Bart, could you test it ? I'm testing the interrupt system a little bit more and have encountered a problem. I use a OS timer match register of the PXA to generate interrupts on a regular base. In the interrupt handler I reprogram the match register so the interrupt fires hole the time. In the interrupt handler happens nothing special (no special calls or something, just toggling of GPIO). When the interrupt stops (after 1000 times) everything still hangs. When I does this in the xenomai domain (native skin) Linux get stuck. User-space doesn't react anymore and some parts of the kernel also doesn't react. Pinging the system still works but a timer that toggles a LED doesn't do anything . When I does the same in the linux domain everything still works. Has somebody an idea? Bart ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [Xenomai-help] [ANNOUNCE] RTDM driver for CAN devices
Hi Wolfgang,
Wolfgang Grandegger wrote:
Hello,
at ftp://ftp.denx.de/pub/xenomai/rtcan; you can find a first version of
RTCAN, an Open Source hard real-time protocol stack for CAN devices
based on BSD sockets. It is based on the SJA1000 socket-based CAN driver
for RTDM by Sebastian Smolorz (see CREDITS file).
I started a review of the patch, and here are some first results. A
deeper look into critical paths is pending. But given that your
driver(s) already proved to work fine for us here and for your own
scenarios, only very sneaking issues can persist - if at all. :)
- AF_CAN is still set to 30 which meanwhile became TIPC. The Socket-CAN
project moved to 29 now. However, this could become a nice race until
Socket-CAN is upstream and reserved a final ID. How to cope with this?
We just had some fun here after moving our AF_TIMS from 0 to 27,
breaking many installation on our robots due to the ABI change. Should
we better move the ID beyond AF_MAX for now? Also a question for the
socketcan-core list...
- Out-commented debug messages: If they can be useful for driver
development / hardware testing, I would say make them selectable via
some CONFIG-switch. The rest should be removed.
- rtcan_mscan_mode_stop() contains some #if 1-#else-#endif block. What
are the alternatives here? Is it an open issue or just a pending cleanup?
- rtcan_mscan_init_one() contains a #ifdef FIXME. What needs to be
fixed? Comments for non-obvious pending issues would be helpful.
- Can rtcan_mscan_exit() be tagged with __exit?
- Is rtcan_mscan_proc_regs() a kind of debug option or useful for normal
operation as well? If it's the former, we may bundle it with the debug
print CONFIG-switch.
- Private data alignment in rtcan_dev_alloc(): you tapped on something
that looks ugly in RTnet as well. We copied this from Linux which still
does magic 32-byte alignment (encapsulated by NETDEV_ALIGN today). But
it also uses a smarter priv lookup now:
#define NETDEV_ALIGN32
#define NETDEV_ALIGN_CONST (NETDEV_ALIGN - 1)
static inline void *netdev_priv(struct net_device *dev)
{
return (char *)dev + ((sizeof(struct net_device)
+ NETDEV_ALIGN_CONST)
~NETDEV_ALIGN_CONST);
}
Maybe something that should be adopted as well (for both stacks).
Nothing critical though.
- rtcan_dev_unregister() looks racy: down(rtcan_devices_nrt_lock) comes
after the device state check. Is this ok?
- EXPORT_SYMBOL vs. EXPORT_SYMBOL_GPL: For me this makes no practical
difference anymore (kernel modules, specifically drivers must be GPL, no
matter what kind of symbols they use). Anyway, shouldn't we better go
the kernel path and introduce new APIs under _GPL? Just takes a wrapper
for 2.4 I guess.
- struct rtcan_device: what the heck are max_brp and max_sjw
(comments...)? This isn't something generic, right? That's why FIXME I
guess.
- LIST_POISON1 and some other stuff in rtcan_internal.h should
definitely be moved to the nucleus's wrapper. Nothing critical, just a
to-do. Likely the whole header will be obsolete in the end.
- [This is a note for me] RTCAN_ASSERT: Looks like we should introduce
RTDM_ASSERT() for this, maybe accepting some driver subsystem ID to
control this separately from the rest of Xenomai.
- RTCAN_PROC_... requires some thoughts: Generalise it? Some users
(haven't checked RTCAN for this, but RTnet has some) should better be
converted to seq_operations. And the rest could benefit from a generic
interface here. Uncritical for now.
- rtcan_dev_get_state_name(): Mm, having some array lookup for the name
here may shorten things.
- rtcan_read_proc_info: Should be done as in rtcan_mscan_proc_regs. Even
better: By increasing the buffer block in RTCAN_PROC_PRINT_VARS() you
could combine several PROC_PRINTs to a single one.
- rtcan_raw_remove_filter(): if (sock-flistlen 0), a real check or
rather an internal ASSERT?
- struct rtcan_rb_frame differs from struct can_frame in the type of
can_dlc. The VW guys find __u8 for this nicer than a natural unsigned
int, but I stopped arguing on this. If we follow or not, it should be
consistent.
- rtcan_socket_context(): container_of?
- [Another note for me] module_param_array vs. MODULE_PARM-array: there
is some not that bad wrapper in RTnet now. I should push it to Xenomai
to simplify such blocks.
- Well known issue: the RTCAN name. This should definitely get resolved
before we merge. Any feedback already?
- Low prio (as long as my own code doesn't follow this ;)): Linux coding
style.
No guarantee that I found every critical point (most of the stuff above
is nitpicking anyway). I will try to repeat this more in details when
time permits. Hope my comments help nevertheless.
Jan
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
