Re: [Xenomai-core] Remove outdated x86 adeos patches
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Hi Philippe, as adeos-ipipe-2.4.35.5-i386-1.3-05.patch and adeos-ipipe-2.6.29.5-x86-2.4-02.patch are no longer up to date /wrt to latest i-pipe fixes, I would suggest to remove them for 2.5-final. Avoids that people trap into known issues. What latest fixes? Are they expected to oops or something? 2.6.29 on x86-64: definitely (irq stack corruption). 32 bits and 2.4.35 are lacking the halt fix (I bet other arch beyond x86 that use a hlt-like idle do so as well). It's not that they aren't fixable, it's just the question if we should bother anymore. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] Add support for sharing kernel/userland data between Xenomai and Linux
From: Wolfgang Mauerer wolfgang.maue...@siemens.com
A new structure (struct xnshared) is introduced. It allows us to share
generic data between user and kernel of Linux and Xenomai; a bitmap
of feature flags located at the beginning of the structure identifies
which data are shared. The structure is allocated in the global semaphore
heap, and xnsysinfo.xnshared_offset identifies the offset of the
structure within the heap.
Currently, no shared features are yet supported - the patch only
introduces the necessary ABI changes. When the need arises
to share data between said entities, the structure must
be accordingly extended, and a new feature bit must be added
to the flags.
Signed-off-by: Wolfgang Mauerer wolfgang.maue...@siemens.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
include/asm-generic/syscall.h |1 +
include/nucleus/xnshared.h| 33 +
ksrc/nucleus/module.c | 23 +++
ksrc/nucleus/shadow.c |4
4 files changed, 61 insertions(+), 0 deletions(-)
create mode 100644 include/nucleus/xnshared.h
diff --git a/include/asm-generic/syscall.h b/include/asm-generic/syscall.h
index 483b99f..7d68580 100644
--- a/include/asm-generic/syscall.h
+++ b/include/asm-generic/syscall.h
@@ -53,6 +53,7 @@
typedef struct xnsysinfo {
unsigned long long cpufreq; /* CPU frequency */
unsigned long tickval; /* Tick duration (ns) */
+ unsigned long xnshared_offset; /* Offset of xnshared in the sem heap */
} xnsysinfo_t;
#define SIGSHADOW SIGWINCH
diff --git a/include/nucleus/xnshared.h b/include/nucleus/xnshared.h
new file mode 100644
index 000..4293cda
--- /dev/null
+++ b/include/nucleus/xnshared.h
@@ -0,0 +1,33 @@
+#ifndef XNSHARED_H
+#define XNSHARED_H
+
+/*
+ * Data shared between Xenomai kernel/userland and the Linux kernel/userland
+ * on the global semaphore heap. The features element indicates which data are
+ * shared. Notice that xnshared may only grow, but never shrink.
+ */
+struct xnshared {
+ unsigned long long features;
+
+ /* Embed domain specific structures that describe the
+* shared data here */
+};
+
+/*
+ * For each shared feature, add a flag below. For now, it is still
+ * empty.
+ */
+enum xnshared_features {
+/* XNSHARED_FEAT_A = 1,
+ XNSHARED_FEAT_B, */
+ XNSHARED_MAX_FEATURES,
+};
+
+extern struct xnshared *xnshared;
+
+static inline int xnshared_test_feature(enum xnshared_features feature)
+{
+ return xnshared xnshared-features (1 feature);
+}
+
+#endif
diff --git a/ksrc/nucleus/module.c b/ksrc/nucleus/module.c
index 5404182..3963fbd 100644
--- a/ksrc/nucleus/module.c
+++ b/ksrc/nucleus/module.c
@@ -34,6 +34,7 @@
#include nucleus/pipe.h
#endif /* CONFIG_XENO_OPT_PIPE */
#include nucleus/select.h
+#include nucleus/xnshared.h
#include asm/xenomai/bits/init.h
MODULE_DESCRIPTION(Xenomai nucleus);
@@ -51,6 +52,9 @@ u_long xnmod_sysheap_size;
int xeno_nucleus_status = -EINVAL;
+struct xnshared *xnshared;
+EXPORT_SYMBOL_GPL(xnshared);
+
struct xnsys_ppd __xnsys_global_ppd;
EXPORT_SYMBOL_GPL(__xnsys_global_ppd);
@@ -82,6 +86,23 @@ void xnmod_alloc_glinks(xnqueue_t *freehq)
}
EXPORT_SYMBOL_GPL(xnmod_alloc_glinks);
+/*
+ * We re-use the global semaphore heap to provide a multi-purpose shared
+ * memory area between Xenomai and Linux - for both kernel and userland
+ */
+void __init xnheap_init_shared(void)
+{
+ xnshared = (struct xnshared *)xnheap_alloc(__xnsys_global_ppd.sem_heap,
+ sizeof(struct xnshared));
+
+ if (!xnshared)
+ xnpod_fatal(Xenomai: cannot allocate memory for xnshared!\n);
+
+ /* Currently, we don't support any sharing, but later versions will
+* add flags here */
+ xnshared-features = 0ULL;
+}
+
int __init __xeno_sys_init(void)
{
int ret;
@@ -106,6 +127,8 @@ int __init __xeno_sys_init(void)
goto cleanup_arch;
xnheap_set_label(__xnsys_global_ppd.sem_heap, global sem heap);
+
+ xnheap_init_shared();
#endif
#ifdef __KERNEL__
diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
index 0c94a60..0373a8d 100644
--- a/ksrc/nucleus/shadow.c
+++ b/ksrc/nucleus/shadow.c
@@ -50,6 +50,7 @@
#include nucleus/trace.h
#include nucleus/stat.h
#include nucleus/sys_ppd.h
+#include nucleus/xnshared.h
#include asm/xenomai/features.h
#include asm/xenomai/syscall.h
#include asm/xenomai/bits/shadow.h
@@ -1746,6 +1747,9 @@ static int xnshadow_sys_info(struct pt_regs *regs)
info.cpufreq = xnarch_get_cpu_freq();
+ info.xnshared_offset =
+ xnheap_mapped_offset(xnsys_ppd_get(1)-sem_heap, xnshared);
+
return __xn_safe_copy_to_user((void __user *)infarg, info,
sizeof(info));
}
--
1.6.4
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Remove outdated x86 adeos patches
On Mon, 2009-12-21 at 09:58 +0100, Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Hi Philippe, as adeos-ipipe-2.4.35.5-i386-1.3-05.patch and adeos-ipipe-2.6.29.5-x86-2.4-02.patch are no longer up to date /wrt to latest i-pipe fixes, I would suggest to remove them for 2.5-final. Avoids that people trap into known issues. What latest fixes? Are they expected to oops or something? 2.6.29 on x86-64: definitely (irq stack corruption). 32 bits and 2.4.35 are lacking the halt fix (I bet other arch beyond x86 that use a hlt-like idle do so as well). It's not that they aren't fixable, it's just the question if we should bother anymore. Ack. I don't even know whether anybody ever tried to run Xenomai over 2.4/x86 anyway, and I don't think this would ever make sense to do so today, so 2.4.35 will be removed. 2.6.29.4 will go away as well, since 2.6.30.8 and 2.6.31.1 have been fixed, and hopefully, 2.6.33/86 will be supported in a foreseeable future. In any case, the README in the patches/ directory clearly states that adventurous people may try other options available from http://download.gna.org/adeos/patches/ -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Remove outdated x86 adeos patches
Philippe Gerum wrote: On Mon, 2009-12-21 at 09:58 +0100, Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Hi Philippe, as adeos-ipipe-2.4.35.5-i386-1.3-05.patch and adeos-ipipe-2.6.29.5-x86-2.4-02.patch are no longer up to date /wrt to latest i-pipe fixes, I would suggest to remove them for 2.5-final. Avoids that people trap into known issues. What latest fixes? Are they expected to oops or something? 2.6.29 on x86-64: definitely (irq stack corruption). 32 bits and 2.4.35 are lacking the halt fix (I bet other arch beyond x86 that use a hlt-like idle do so as well). It's not that they aren't fixable, it's just the question if we should bother anymore. Ack. I don't even know whether anybody ever tried to run Xenomai over 2.4/x86 anyway, and I don't think this would ever make sense to do so today, so 2.4.35 will be removed. 2.6.29.4 will go away as well, since 2.6.30.8 and 2.6.31.1 have been fixed, and hopefully, 2.6.33/86 will be supported in a foreseeable future. In any case, the README in the patches/ directory clearly states that adventurous people may try other options available from http://download.gna.org/adeos/patches/ Ok. However, if we want to check that Xenomai 2.5 still compiles with linux 2.4 base patches, can we keep at least one 2.4 patch in the repository? -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] digital I/O with analgoy using ni_pcmcia
Hi, Stefan Schaal wrote: Hi everybody, we have an NI6259 board working xenomai 2.5, using the analogy APIs. Read/write to analog channels is quite straightforward and can be inferred from the cmd_read and cmd_write source code. Now I would also like to use the digital I/O of this board (e.g., the 32 digital I/O lines). In Comedi, there are functions to set the DIO lines to input/output mode (comedi_dio_config), and then functions to read/write, like comedi_dio_read and comedi_dio_write. Does xenomai/analogy already have similar functionality? Many thanks for this question, it is an issue I have been keeping on postponing the resolution. Currently, the functions are not implemented but it could be quickly done. Here is my understanding of the Comedi DIO features; please, correct me if I am wrong. In Comedi, here is the list of functions related with DIO: - comedi_dio_read (insn_read or deprecated insn trigger) - comedi_dio_write (insn_write or deprecated insn trigger) - comedi_dio_config (insn_config or deprecated insn trigger) - comedi_dio_get_config (insn_config or deprecated trigger) - comedi_dio_bitfield (insn_bits or comedi_dio_read/write) - comedi_dio_bitfield2 (insn_bits or comedi_dio_read/write) The instruction insn_bits is a combination of a read operation and a write operation (that is why, the function comedi_dio_bitfield* call comedi_dio_read and comedi_dio_write if the driver does not provide an insn-bits handler). I had a look at many Comedi drivers and most of them register the handler insn_bits for the DIO subdevice. The instructions insn_read and insn_write are not oftenly used in DIO contexts. comedi_dio_bitfield() uses the insn_bits instruction. However, it only works with DIO subdevice limited to 32 channels; that was why comedi_dio_bitfield2() was introduced, this latter function contains one more argument so as to shift the bits. Consequently, we may need a more limited set of functions: - a4l_sync_dio(dsc, idx_subd, mask, buf) - a4l_sizeof_subd(dsc, idx_subd) - a4l_config_subd(dsc, idx_subd, idx_chan, cfg_type, *val) a4l_sync_dio() could work with any DIO subdevice (more or less than 32 channels). The last argument would be a pointer to a buffer which size should be defined thanks to a4l_sizeof_subd() (8, 16, 32, 64 or more bits). a4l_config_subd() could be used to configure the polarity of the DIO channels. The argument cfg_type could be set to DIO_INPUT, DIO_OUTPUT, DIO_QUERY. And, we could even imagine that this function would not be limited to DIO subdevice; so, the argument cfg_type could accept more values (SERIAL_CLOCK, BIDIRECTIONAL_DATA, SET_CLOCK_SRC, GET_CLOCK_SRC, etc.) How do you see this approach ? Do you (or anyone else) have a better solution in mind ? Best regards, Thanks a lot, -Stefan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai-git Digest, Vol 9, Issue 40
Jan Kiszka wrote: xenomai-git-requ...@gna.org wrote: Date: Mon, 21 Dec 2009 16:04:33 +0100 From: GIT version control g...@xenomai.org Subject: [Xenomai-git] Gilles Chanteperdrix : rtcan: use the new pci_ids header for pci rtcan drivers To: xenomai-...@gna.org Message-ID: e1nmjoh-0003st...@xenomai.org Content-Type: text/plain; charset=UTF-8 Module: xenomai-head Branch: master Commit: 5662ced95f1f51dbf4285d5ff5a6da84cc74af83 URL: http://git.xenomai.org/?p=xenomai-head.git;a=commit;h=5662ced95f1f51dbf4285d5ff5a6da84cc74af83 Author: Gilles Chanteperdrix gilles.chanteperd...@xenomai.org Date: Sun Dec 20 02:43:36 2009 +0100 rtcan: use the new pci_ids header for pci rtcan drivers --- ksrc/drivers/can/sja1000/rtcan_ems_pci.c |1 + ksrc/drivers/can/sja1000/rtcan_esd_pci.c |1 + ksrc/drivers/can/sja1000/rtcan_ixxat_pci.c |1 + ksrc/drivers/can/sja1000/rtcan_peak_pci.c |1 + 4 files changed, 4 insertions(+), 0 deletions(-) diff --git a/ksrc/drivers/can/sja1000/rtcan_ems_pci.c b/ksrc/drivers/can/sja1000/rtcan_ems_pci.c index f69b5b8..a0921b4 100644 --- a/ksrc/drivers/can/sja1000/rtcan_ems_pci.c +++ b/ksrc/drivers/can/sja1000/rtcan_ems_pci.c @@ -23,6 +23,7 @@ #include linux/delay.h #include linux/pci.h #include asm/io.h +#include asm-generic/xenomai/pci_ids.h Is there any prerequisite for including this header? If not, can't we drag it in via Xenomai's rtdm_driver.h? That avoids diverging too much from the only Linux or RTDM rule in our drivers. I understand, RTcan would not compile with RTAI. This header is also used by the smi module, which is not an RTDM module, that said we can include it through RTDM for RTDM drivers, and smi module would include it directly. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] digital I/O with analgoy using ni_pcmcia
Hi Alexis, thanks a lot for all these suggestions. For my applications, the functions you listed below would be entirely sufficient. Essentially, I need to be able to put selected channels on the DIO in either read or write mode, and then simply read from them or write from them. The protocol I use requires 16 data bits, and 3 additional control lines. It was originally implemented under vxWorks. Nothing fancy at all. Thanks a lot for your kind help! -Stefan On Dec 21, 2009, at 15:23, Alexis Berlemont wrote: Hi, Stefan Schaal wrote: Hi everybody, we have an NI6259 board working xenomai 2.5, using the analogy APIs. Read/write to analog channels is quite straightforward and can be inferred from the cmd_read and cmd_write source code. Now I would also like to use the digital I/O of this board (e.g., the 32 digital I/O lines). In Comedi, there are functions to set the DIO lines to input/output mode (comedi_dio_config), and then functions to read/write, like comedi_dio_read and comedi_dio_write. Does xenomai/analogy already have similar functionality? Many thanks for this question, it is an issue I have been keeping on postponing the resolution. Currently, the functions are not implemented but it could be quickly done. Here is my understanding of the Comedi DIO features; please, correct me if I am wrong. In Comedi, here is the list of functions related with DIO: - comedi_dio_read (insn_read or deprecated insn trigger) - comedi_dio_write (insn_write or deprecated insn trigger) - comedi_dio_config (insn_config or deprecated insn trigger) - comedi_dio_get_config (insn_config or deprecated trigger) - comedi_dio_bitfield (insn_bits or comedi_dio_read/write) - comedi_dio_bitfield2 (insn_bits or comedi_dio_read/write) The instruction insn_bits is a combination of a read operation and a write operation (that is why, the function comedi_dio_bitfield* call comedi_dio_read and comedi_dio_write if the driver does not provide an insn-bits handler). I had a look at many Comedi drivers and most of them register the handler insn_bits for the DIO subdevice. The instructions insn_read and insn_write are not oftenly used in DIO contexts. comedi_dio_bitfield() uses the insn_bits instruction. However, it only works with DIO subdevice limited to 32 channels; that was why comedi_dio_bitfield2() was introduced, this latter function contains one more argument so as to shift the bits. Consequently, we may need a more limited set of functions: - a4l_sync_dio(dsc, idx_subd, mask, buf) - a4l_sizeof_subd(dsc, idx_subd) - a4l_config_subd(dsc, idx_subd, idx_chan, cfg_type, *val) a4l_sync_dio() could work with any DIO subdevice (more or less than 32 channels). The last argument would be a pointer to a buffer which size should be defined thanks to a4l_sizeof_subd() (8, 16, 32, 64 or more bits). a4l_config_subd() could be used to configure the polarity of the DIO channels. The argument cfg_type could be set to DIO_INPUT, DIO_OUTPUT, DIO_QUERY. And, we could even imagine that this function would not be limited to DIO subdevice; so, the argument cfg_type could accept more values (SERIAL_CLOCK, BIDIRECTIONAL_DATA, SET_CLOCK_SRC, GET_CLOCK_SRC, etc.) How do you see this approach ? Do you (or anyone else) have a better solution in mind ? Best regards, Thanks a lot, -Stefan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
