[Xenomai-core] new features for 16550A driver
Hello, I'm working on a project which aims at porting an application running under VxWorks to Linux. This application uses the serial port. I would like to add an ioctl or a field in the config structure to permit to strip or not the parity bit of each byte on reception. This feature is implemented on Linux and VxWorks. Is it something I can do and then submit to Xenomai or your driver is only an example and will never be improved? I think that I will have more feature to add to the driver, that's why I'm asking this. -- Guillaume Gaudonville E-mail: [EMAIL PROTECTED] ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Adeos PowerPC patch differences
Philippe Gerum wrote: > Yes. I have tested 2.6.22-DENX over two Freescale boards, namely mpc52xx > and mpc8548, using this very same setup. Btw, you will need to pick > 2.0-01 which landed today in the repo, since I fixed a couple of issues > (one being serious) there. > Thanks for the info about 2.0 issue. >> And is the DENX patch specific to DENX tree or can it be applied/used >> from vanilla kernel tree ? >> >> > > It should apply to the vanilla tree without too much fuss, but the > reference tree for the I-pipe/powerpc work is the DENX one, AFAIC. > > FYI, Adeos 2.0 / Xenomai 2.4 works fine on my PowerPC boards too. BTW, 2.6.23-rc5 patch does not apply "as it" on -rc7 and -rc8 (for ppc64 part at least). Ben ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Adeos PowerPC patch differences
Benjamin ZORES wrote: > Philippe Gerum wrote: >> Yes. I have tested 2.6.22-DENX over two Freescale boards, namely mpc52xx >> and mpc8548, using this very same setup. Btw, you will need to pick >> 2.0-01 which landed today in the repo, since I fixed a couple of issues >> (one being serious) there. >> > Thanks for the info about 2.0 issue. >>> And is the DENX patch specific to DENX tree or can it be applied/used >>> from vanilla kernel tree ? >>> >>> >> It should apply to the vanilla tree without too much fuss, but the >> reference tree for the I-pipe/powerpc work is the DENX one, AFAIC. >> >> > > FYI, Adeos 2.0 / Xenomai 2.4 works fine on my PowerPC boards too. > BTW, 2.6.23-rc5 patch does not apply "as it" on -rc7 and -rc8 > (for ppc64 part at least). Because head_4xx.S has been renamed to head_40x.S in arch/powerpc/kernel recently :-(. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Adeos PowerPC patch differences
Wolfgang Grandegger wrote: > Benjamin ZORES wrote: >> Philippe Gerum wrote: >>> Yes. I have tested 2.6.22-DENX over two Freescale boards, namely >>> mpc52xx >>> and mpc8548, using this very same setup. Btw, you will need to pick >>> 2.0-01 which landed today in the repo, since I fixed a couple of issues >>> (one being serious) there. >>> >> Thanks for the info about 2.0 issue. And is the DENX patch specific to DENX tree or can it be applied/used from vanilla kernel tree ? >>> It should apply to the vanilla tree without too much fuss, but the >>> reference tree for the I-pipe/powerpc work is the DENX one, AFAIC. >>> >>> >> >> FYI, Adeos 2.0 / Xenomai 2.4 works fine on my PowerPC boards too. >> BTW, 2.6.23-rc5 patch does not apply "as it" on -rc7 and -rc8 >> (for ppc64 part at least). > > Because head_4xx.S has been renamed to head_40x.S in > arch/powerpc/kernel recently :-(. > > Wolfgang. > No, it was due to changes in code in time.c and process.c iirc. Ben ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] Fast Context Switch Extension for ARM Linux
Richard Cochran wrote: > I know that this is a bit off topic, yet perhaps some on this list > have interest or knowledge in this area. I am also posting this idea > to the linux-arm-kernel list. > > I would like to implement the ARM FCSE under Linux, using the Intel > IXP425 board. Before I start, I would like to ask: > > 1. Has any work already been done in this area? Yes, we at emlix evaluate the feasibility of porting the FASS patch to a modern 2.6 kernel in the context of a customer project. It is far more work than expected because central MM implementations both ARM-specific and Linux-general have changed since the 2.4 days. What we have done is to take the FASS patch and tried to make it work with the 2.6 line rather than implementing the concepts from scratch. So far, we are able to compile a FASS-patched 2.6.21 kernel but it fails when trying to start init. We expect a huge amount of bugs hiding inside the code yet. No wonder, we are still in the middle of the work. I would call the code far from being releasable but before you also begin to do the work we have already performed it is reasonable to post our current status. We consider to set up a git repository so that you and all interested people will be able to clone from it. If anyone feels prepared to contribute code to this project we either can provide write access to the repository or do it the Linus' way (i.e. we would pull from others' repositories), whichever is preferred. Regards, Sebastian -- Dipl.-Ing. Sebastian Smolorz, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax -11, Bahnhofsallee 1b, 37081 Göttingen, Germany Geschäftsführung: Dr. Uwe Kracke, Dr. Cord Seele, Ust-IdNr.: DE 205 198 055 Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 emlix - your embedded linux partner ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] new features for 16550A driver
Guillaume Gaudonville wrote: > Hello, > > I'm working on a project which aims at porting an application > running under VxWorks to Linux. This application uses the serial > port. > > I would like to add an ioctl or a field in the config structure > to permit to strip or not the parity bit of each byte on reception. This > feature is implemented on Linux and VxWorks. > > Is it something I can do and then submit to Xenomai or your driver is only > an example and will never be improved? The driver is far from being just an example, it's used in real applications. If your feature is useful and doesn't turn the existing code upside down, it will surely be considered for merging. > > I think that I will have more feature to add to the driver, that's why I'm > asking this. I don't want to exclude anything (specifically as long as I haven't seen some patch yet), but I also don't want to overload the driver over the time with corner-case features. We need a good balance. But we first of all need more details about what you plan to add, what application scenario is behind it, why you need the driver to implement the feature, and what impact it may have on the code. You are welcome to elaborate on this or, even better, post some patch drafts here. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Adeos PowerPC patch differences
Benjamin ZORES wrote: > Wolfgang Grandegger wrote: >> Benjamin ZORES wrote: >>> Philippe Gerum wrote: Yes. I have tested 2.6.22-DENX over two Freescale boards, namely mpc52xx and mpc8548, using this very same setup. Btw, you will need to pick 2.0-01 which landed today in the repo, since I fixed a couple of issues (one being serious) there. >>> Thanks for the info about 2.0 issue. > And is the DENX patch specific to DENX tree or can it be applied/used > from vanilla kernel tree ? > > It should apply to the vanilla tree without too much fuss, but the reference tree for the I-pipe/powerpc work is the DENX one, AFAIC. >>> FYI, Adeos 2.0 / Xenomai 2.4 works fine on my PowerPC boards too. >>> BTW, 2.6.23-rc5 patch does not apply "as it" on -rc7 and -rc8 >>> (for ppc64 part at least). >> Because head_4xx.S has been renamed to head_40x.S in >> arch/powerpc/kernel recently :-(. >> >> Wolfgang. >> > No, it was due to changes in code in time.c and process.c iirc. I applied adeos-ipipe-2.6.23-rc5-powerpc-DENX-2.0-01.patch to the 2.6.23-rc7 version of linux-2.6-denx. Seems you are using the official kernel linux-2.6 tree. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTCAN (MSCAN) doesn't compile on latest Denx 2.6.23
Wolfgang Grandegger wrote: > > I have a patch already since a while but forgot to post it. Could you > please give the attached patch a try? > I have given the patch a try and it doesn't quite work out of the box, as there is an index off-by-one error concerning the configured CAN ports. The result is that probing the CAN controller starts with the second entry in the device tree and a random address will be probed for the second CAN controller where ioremap gladly bumps out with an error which results in a RT-CAN shutdown. The applied patch solves the issue for me. I don't know if it works in case of (! #defined CONFIG_PPC_MERGE) Best regards, Daniel. mscan_fix_ot_index.patch Description: mscan_fix_ot_index.patch ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTCAN (MSCAN) doesn't compile on latest Denx 2.6.23
Daniel Schnell wrote: > Wolfgang Grandegger wrote: > >> I have a patch already since a while but forgot to post it. Could you >> please give the attached patch a try? >> > > I have given the patch a try and it doesn't quite work out of the box, > as there is an index off-by-one error concerning the configured CAN > ports. The result is that probing the CAN controller starts with the > second entry in the device tree and a random address will be probed for > the second CAN controller where ioremap gladly bumps out with an error > which results in a RT-CAN shutdown. > > The applied patch solves the issue for me. I don't know if it works in > case of (! #defined CONFIG_PPC_MERGE) I'm going to check that. Thanks for reporting. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Adeos PowerPC patch differences
Wolfgang Grandegger wrote: > Benjamin ZORES wrote: >> Wolfgang Grandegger wrote: >>> Benjamin ZORES wrote: Philippe Gerum wrote: > Yes. I have tested 2.6.22-DENX over two Freescale boards, namely > mpc52xx > and mpc8548, using this very same setup. Btw, you will need to pick > 2.0-01 which landed today in the repo, since I fixed a couple of > issues > (one being serious) there. > Thanks for the info about 2.0 issue. >> And is the DENX patch specific to DENX tree or can it be >> applied/used >> from vanilla kernel tree ? >> >> > It should apply to the vanilla tree without too much fuss, but the > reference tree for the I-pipe/powerpc work is the DENX one, AFAIC. > > FYI, Adeos 2.0 / Xenomai 2.4 works fine on my PowerPC boards too. BTW, 2.6.23-rc5 patch does not apply "as it" on -rc7 and -rc8 (for ppc64 part at least). >>> Because head_4xx.S has been renamed to head_40x.S in >>> arch/powerpc/kernel recently :-(. >>> >>> Wolfgang. >>> >> No, it was due to changes in code in time.c and process.c iirc. > > I applied adeos-ipipe-2.6.23-rc5-powerpc-DENX-2.0-01.patch to the > 2.6.23-rc7 version of linux-2.6-denx. Seems you are using the official > kernel linux-2.6 tree. > Absolutely. Sorry for not having stated this before. Anyhow, it's easy to fix. Ben ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] Fix attribute reference in __wrap_pthread_create
Hi Gilles, my rt-cap changes to the posix lib caused another regression. I don't understand what my intention of changing the attribute reference once was (probably an intermediate change), but it was wrong. The attached patch now makes all programs happy that create pthreads without attributes (clocktest e.g.). Patch against 2.3.x, should be applied to trunk as well. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux --- ChangeLog|5 + src/skins/posix/thread.c |2 +- 2 files changed, 6 insertions(+), 1 deletion(-) Index: xenomai-2.3.x/ChangeLog === --- xenomai-2.3.x.orig/ChangeLog +++ xenomai-2.3.x/ChangeLog @@ -1,3 +1,8 @@ +2007-09-26 Jan Kiszka <[EMAIL PROTECTED]> + + * src/skins/posix/thread.c (__wrap_pthread_create): Use the correct + attribute reference when creating the real pthread. + 2007-09-16 Philippe Gerum <[EMAIL PROTECTED]> * RELEASE: Xenomai 2.3.4 (Cool #9) Index: xenomai-2.3.x/src/skins/posix/thread.c === --- xenomai-2.3.x.orig/src/skins/posix/thread.c +++ xenomai-2.3.x/src/skins/posix/thread.c @@ -170,7 +170,7 @@ int __wrap_pthread_create(pthread_t *tid iargs.ret = EAGAIN; __real_sem_init(&iargs.sync, 0, 0); - err = __real_pthread_create(
Re: [Xenomai-core] new features for 16550A driver
2007/9/26, Jan Kiszka <[EMAIL PROTECTED]>: > > Guillaume Gaudonville wrote: > > Hello, > > > > I'm working on a project which aims at porting an application > > running under VxWorks to Linux. This application uses the serial > > port. > > > > I would like to add an ioctl or a field in the config structure > > to permit to strip or not the parity bit of each byte on reception. This > > feature is implemented on Linux and VxWorks. > > > > Is it something I can do and then submit to Xenomai or your driver is > only > > an example and will never be improved? > > The driver is far from being just an example, it's used in real > applications. It was just to be sure... I'm using it for a real application. If your feature is useful and doesn't turn the existing code upside > down, it will surely be considered for merging. > > > > > I think that I will have more feature to add to the driver, that's why > I'm > > asking this. > > I don't want to exclude anything (specifically as long as I haven't seen > some patch yet), but I also don't want to overload the driver over the > time with corner-case features. We need a good balance. > > But we first of all need more details about what you plan to add, what > application scenario is behind it, why you need the driver to implement > the feature, and what impact it may have on the code. You are welcome to > elaborate on this or, even better, post some patch drafts here. I don't know which features I'll need. For the ISTRIP feature the goal is only to remove the eigth'th bit of every byte received: I've got a VxWorks application which communicate with an external clock on the serial port. The clock uses the parity bit but my application do not. In the original code an ioctl was done to say the serial driver to remove the parity bit on reception. This feature is also offered under Linux and seems to be posix (man tcsetattr, search ISTRIP). In order to reduce the code modifications, I would like to implement it in the driver. If so, I think the better way would be to add a field in the rtser_config struct, do you agree? And then depending upon this field to apply a mask (0x7f) to the character in the interrupt handler rt_16550_rx_interrupt() or only to the characters passed to user space depending upon what is done in other driver. to reproduce the same behaviour). Jan > > -- > Siemens AG, Corporate Technology, CT SE 2 > Corporate Competence Center Embedded Linux > -- Guillaume Gaudonville E-mail: [EMAIL PROTECTED] ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] new features for 16550A driver
I've attached the patch drafts. It works fine for me. it prepare the work to
implement the other iflag values as describe in man tcsetattr.
2007/9/26, Guillaume Gaudonville <[EMAIL PROTECTED]>:
>
>
>
> 2007/9/26, Jan Kiszka <[EMAIL PROTECTED]>:
> >
> > Guillaume Gaudonville wrote:
> > > Hello,
> > >
> > > I'm working on a project which aims at porting an application
> > > running under VxWorks to Linux. This application uses the serial
> > > port.
> > >
> > > I would like to add an ioctl or a field in the config structure
> > > to permit to strip or not the parity bit of each byte on reception.
> > This
> > > feature is implemented on Linux and VxWorks.
> > >
> > > Is it something I can do and then submit to Xenomai or your driver is
> > only
> > > an example and will never be improved?
> >
> > The driver is far from being just an example, it's used in real
> > applications.
>
>
> It was just to be sure... I'm using it for a real application.
>
> If your feature is useful and doesn't turn the existing code upside
> > down, it will surely be considered for merging.
> >
> > >
> > > I think that I will have more feature to add to the driver, that's why
> > I'm
> > > asking this.
> >
> > I don't want to exclude anything (specifically as long as I haven't seen
> > some patch yet), but I also don't want to overload the driver over the
> > time with corner-case features. We need a good balance.
> >
> > But we first of all need more details about what you plan to add, what
> > application scenario is behind it, why you need the driver to implement
> > the feature, and what impact it may have on the code. You are welcome to
> >
> > elaborate on this or, even better, post some patch drafts here.
>
>
> I don't know which features I'll need. For the ISTRIP feature the goal
> is only to
> remove the eigth'th bit of every byte received: I've got a VxWorks
> application which communicate
> with an external clock on the serial port. The clock uses the parity bit
> but my application
> do not. In the original code an ioctl was done to say the serial driver to
> remove the parity bit on
> reception. This feature is also offered under Linux and seems to be posix
> (man tcsetattr, search ISTRIP).
> In order to reduce the code modifications, I would like to implement it in
> the driver.
>
> If so, I think the better way would be to add a field in the rtser_config
> struct, do you agree? And then depending
> upon this field to apply a mask (0x7f) to the character in the interrupt
> handler rt_16550_rx_interrupt() or only
> to the characters passed to user space depending upon what is done in
> other driver.
> to reproduce the same behaviour).
>
> Jan
> >
> > --
> > Siemens AG, Corporate Technology, CT SE 2
> > Corporate Competence Center Embedded Linux
> >
>
>
>
> --
> Guillaume Gaudonville
> E-mail: [EMAIL PROTECTED]
>
--
Guillaume Gaudonville
E-mail: [EMAIL PROTECTED]
Index: ksrc/drivers/serial/16550A.c
===
--- ksrc/drivers/serial/16550A.c (révision 2765)
+++ ksrc/drivers/serial/16550A.c (copie de travail)
@@ -153,7 +153,10 @@ static inline int rt_16550_rx_interrupt(
do {
c = rt_16550_reg_in(mode, base, RHR); /* read input char */
- ctx->in_buf[ctx->in_tail] = c;
+ if (testbits(ctx->config.iflags, RTSER_IFLAG_ISTRIP))
+ ctx->in_buf[ctx->in_tail] = c & 0x7f;
+ else
+ ctx->in_buf[ctx->in_tail] = c;
if (ctx->in_history)
ctx->in_history[ctx->in_tail] = *timestamp;
ctx->in_tail = (ctx->in_tail + 1) & (IN_BUFFER_SIZE - 1);
@@ -426,6 +429,10 @@ static int rt_16550_set_config(struct rt
rtdm_lock_put_irqrestore(&ctx->lock, lock_ctx);
}
+ if (testbits(config->config_mask, RTSER_SET_IFLAGS)) {
+ ctx->config.iflags = config->iflags;
+ }
+
return err;
}
Index: include/rtdm/rtserial.h
===
--- include/rtdm/rtserial.h (révision 2765)
+++ include/rtdm/rtserial.h (copie de travail)
@@ -184,6 +184,7 @@
#define RTSER_SET_TIMEOUT_EVENT 0x0400
#define RTSER_SET_TIMESTAMP_HISTORY 0x0800
#define RTSER_SET_EVENT_MASK 0x1000
+#define RTSER_SET_IFLAGS 0x2000
/** @} */
@@ -238,6 +239,15 @@
#define RTSER_BREAK_SET 0x01
+/*!
+ * @anchor RTSER_IFLAG_xxx @name RTSER_IFLAG_xxx
+ * Input behaviour (when used every bits will be set by the ioctl command)
+ * @{ */
+#define RTSER_IFLAG_NONE 0x00
+#define RTSER_IFLAG_ISTRIP 0x01
+#define RTSER_IFLAG_DEFAULT 0x00
+
+
/**
* Serial device configuration
*/
@@ -280,6 +290,11 @@ typedef struct rtser_config {
/** event mask to be used with @ref RTSER_RTIOC_WAIT_EVENT, see
* @ref RTSER_EVENT_xxx */
int event_mask;
+
+ /** input flags, see @ref RTSER_IFLAG_xxx, RTSER_IFLAG_ISTRIP is
+ * the only one supported for the moment (when used every bits
+ * must be set according to the desired configuration)*/
+ int iflags;
} rtser_config_t;
/**
___
Xenomai-core mailin
[Xenomai-core] [BUG] sep-related oops on 2.6.20
Hi, [ 765.881682] general protection fault: [#2] [ 765.881686] SMP [ 765.881692] Modules linked in: xeno_timerbench sky2 xeno_rtdm xeno_native xeno_nucleus ipv6 binfmt_misc rfcomm l2cap bluetooth i915 drm ppdev capability commoncap dock button video sbs battery i2c_ec i2c_core ac af_packet nls_utf8 ntfs sbp2 lp fuse usbhid hid snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss tsdev snd_seq_midi joydev snd_rawmidi snd_seq_midi_event snd_seq evdev snd_timer snd_seq_device pcmcia ehci_hcd irda iTCO_wdt iTCO_vendor_support ohci1394 sdhci uhci_hcd parport_pc parport ata_generic generic piix ieee1394 intel_agp agpgart mmc_core usbcore serio_raw yenta_socket rsrc_nonstatic pcmcia_core pcspkr psmouse shpchp pci_hotplug crc_ccitt snd soundcore snd_page_alloc ext3 jbd mbcache sr_mod cdrom sd_mod sg ata_piix ahci libata scsi_mod fan [ 765.881825] CPU:1 [ 765.881826] EIP:0060:[]Not tainted VLI [ 765.881827] EFLAGS: 00010246 (2.6.20 #10) [ 765.881835] EIP is at sysenter_exit+0x13/0x18 [ 765.881839] eax: ebx: b7dda374 ecx: b7dda2b0 edx: e410 [ 765.881843] esi: 267f edi: b7dda374 ebp: esp: eada3fb8 [ 765.881846] ds: 007b es: 007b ss: 0068 [ 765.881851] Process sampling-14203 (pid: 14205, ti=eada2000 task=dfe52070 task.ti=eada2000) [ 765.881854] Stack: b7dda374 b7f81f1c 267f b7dda374 b7dda2d8 0801007b [ 765.881869]007b c0100033 0801022b e410 0073 0206 b7dda2b0 007b [ 765.881882]5a5a5a5a a55a5a5a [ 765.881887] Call Trace: [ 765.881890] [] show_trace_log_lvl+0x1f/0x40 [ 765.881896] [] show_stack_log_lvl+0xb1/0xe0 [ 765.881902] [] show_registers+0x1c4/0x340 [ 765.881907] [] die+0x127/0x280 [ 765.881912] [] do_general_protection+0x199/0x1d0 [ 765.881917] [] __ipipe_handle_exception+0x84/0x1b0 [ 765.881925] [] error_code+0x81/0x90 [ 765.881931] === [ 765.881933] Code: 0c bc 04 00 fb 8b 4d 08 66 f7 c1 ff fe 0f 85 6d 01 00 00 e8 e8 fc 00 00 8b 44 24 18 8b 54 24 2c 8b 4c 24 38 31 ed 8e 6c 24 24 fb <0f> 35 8d 76 00 50 fc 0f a8 06 1e 50 55 57 56 52 51 53 ba 7b 00 [ 765.882012] EIP: [] sysenter_exit+0x13/0x18 SS:ESP 0068:eada3fb8 Any bells ringing for someone? This happens only with --enable-x86-sep, not when going via int80 into the kernel. Setup is 2.6.20 with ipipe-1.8-08 (I switched back from 2.6.20.20 to exclude issues due to my adopted patch) and Xenomai trunk. To trigger this, I have to run "latency -c1" (-c0 doesn't cause this) and switch between X and text mode (which triggers some hw-related latencies, still meditating over this correlation...). Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] new features for 16550A driver
Guillaume Gaudonville wrote:
> I've attached the patch drafts. It works fine for me. it prepare the work to
> implement the other iflag values as describe in man tcsetattr.
>
...
>
> Index: ksrc/drivers/serial/16550A.c
> ===
> --- ksrc/drivers/serial/16550A.c (révision 2765)
> +++ ksrc/drivers/serial/16550A.c (copie de travail)
> @@ -153,7 +153,10 @@ static inline int rt_16550_rx_interrupt(
> do {
> c = rt_16550_reg_in(mode, base, RHR); /* read input char */
>
> - ctx->in_buf[ctx->in_tail] = c;
> + if (testbits(ctx->config.iflags, RTSER_IFLAG_ISTRIP))
> + ctx->in_buf[ctx->in_tail] = c & 0x7f;
> + else
> + ctx->in_buf[ctx->in_tail] = c;
OK, things become clearer.
Question: Switching parity checking on in the hardware does not work/is
no option for you? Shouldn't that clear the parity information as well?
> if (ctx->in_history)
> ctx->in_history[ctx->in_tail] = *timestamp;
> ctx->in_tail = (ctx->in_tail + 1) & (IN_BUFFER_SIZE - 1);
> @@ -426,6 +429,10 @@ static int rt_16550_set_config(struct rt
> rtdm_lock_put_irqrestore(&ctx->lock, lock_ctx);
> }
>
> + if (testbits(config->config_mask, RTSER_SET_IFLAGS)) {
> + ctx->config.iflags = config->iflags;
> + }
> +
> return err;
> }
>
> Index: include/rtdm/rtserial.h
> ===
> --- include/rtdm/rtserial.h (révision 2765)
> +++ include/rtdm/rtserial.h (copie de travail)
> @@ -184,6 +184,7 @@
> #define RTSER_SET_TIMEOUT_EVENT 0x0400
> #define RTSER_SET_TIMESTAMP_HISTORY 0x0800
> #define RTSER_SET_EVENT_MASK 0x1000
> +#define RTSER_SET_IFLAGS 0x2000
> /** @} */
>
>
> @@ -238,6 +239,15 @@
> #define RTSER_BREAK_SET 0x01
>
>
> +/*!
> + * @anchor RTSER_IFLAG_xxx @name RTSER_IFLAG_xxx
> + * Input behaviour (when used every bits will be set by the ioctl command)
> + * @{ */
> +#define RTSER_IFLAG_NONE 0x00
> +#define RTSER_IFLAG_ISTRIP 0x01
> +#define RTSER_IFLAG_DEFAULT 0x00
> +
> +
> /**
> * Serial device configuration
> */
> @@ -280,6 +290,11 @@ typedef struct rtser_config {
> /** event mask to be used with @ref RTSER_RTIOC_WAIT_EVENT, see
>* @ref RTSER_EVENT_xxx */
> int event_mask;
> +
> + /** input flags, see @ref RTSER_IFLAG_xxx, RTSER_IFLAG_ISTRIP is
> + * the only one supported for the moment (when used every bits
> + * must be set according to the desired configuration)*/
> + int iflags;
> } rtser_config_t;
>
> /**
The patch looks very clean, no question! Assuming my attempt above to
use the hardware for this is nonsense, I then wonder if the feature is
worth the additional conditional branch + another potential cache miss
(for ctx->config.iflags) inside the critical reception path.
This is precisely that question of balance: Is the extension of some
broader interest? Do we need it inside the driver (I see no reason yet
why the application cannot do the masking, and we are not forced into
compatibility with termios)? And does the extension impact critical paths?
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] Fast Context Switch Extension for ARM Linux
> -Original Message- From: Sebastian Smolorz > Sent: Wednesday, September 26, 2007 11:28 AM > > We consider to set up a git repository so that you and all > interested people will be able to clone from it. If anyone feels > prepared to contribute code to this project we either can provide > write access to the repository or do it the Linus' way (i.e. we > would pull from others' repositories), whichever is preferred. For now, can you post a diff against a known vanilla kernel version? Perhaps later we can set up a public project. Thanks, Richard ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
