All of lore.kernel.org
 help / color / mirror / Atom feed
* [Xenomai] Only 2 serial ports at a time with xeno_16550A driver
@ 2018-05-23  5:25 C Smith
  2018-05-23  9:18 ` Jan Kiszka
  0 siblings, 1 reply; 16+ messages in thread
From: C Smith @ 2018-05-23  5:25 UTC (permalink / raw)
  To: xenomai

I'm not familiar with the chaining of shared interrupts in the RTDM
architecture. I think the EOI should somehow be done in the very last
invocation of rt_16550_interrupt() by the last peripheral needing service.


I read this from an old interrupt handler:
(assuming IBM PC (Intel) architecture)
An interrupt handler issues an EOI by writing the value 0x20 to the PIC at
address 0x20. If the interrupt was number 8-15, do the same thing again,
write 0x20 to address 0x20.

So perhaps something like this at the end of rt_16550_interrupt() ?

if (ctx->irq_handle.irq <= 7)        /* non-specific EOI to 8259 */
  rt_16550_reg_out(mode, 0, 0x20, 0x20);
if (ctx->irq_handle.irq <= 15)          /* extra EOI for upper ISA IRQs */
  rt_16550_reg_out(mode, 0, 0x20, 0x20);

But again I don't know if that will work with shared interrupts. Surely
RTDM implements some "master" handler which is already doing an EOI?
Remember lower interrupts like IRQ 5 work fine with the xeno_16550A driver
unless another port is sharing the same IRQ.

-C Smith

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [Xenomai] Only 2 serial ports at a time with xeno_16550A driver
  2018-05-23  5:25 [Xenomai] Only 2 serial ports at a time with xeno_16550A driver C Smith
@ 2018-05-23  9:18 ` Jan Kiszka
  2018-05-23 14:56   ` Lennart Sorensen
  0 siblings, 1 reply; 16+ messages in thread
From: Jan Kiszka @ 2018-05-23  9:18 UTC (permalink / raw)
  To: C Smith, xenomai

On 2018-05-23 07:25, C Smith wrote:
> I'm not familiar with the chaining of shared interrupts in the RTDM
> architecture. I think the EOI should somehow be done in the very last
> invocation of rt_16550_interrupt() by the last peripheral needing service.
> 

Just like under Linux, the driver does not have to worry about that
details. Xenomai will EOI the IRQ when needed. The driver handler just
need to tell if a particular invocation was (also) triggered by the
device it drives.

> 
> I read this from an old interrupt handler:
> (assuming IBM PC (Intel) architecture)
> An interrupt handler issues an EOI by writing the value 0x20 to the PIC at
> address 0x20. If the interrupt was number 8-15, do the same thing again,
> write 0x20 to address 0x20.
> 
> So perhaps something like this at the end of rt_16550_interrupt() ?
> 
> if (ctx->irq_handle.irq <= 7)        /* non-specific EOI to 8259 */
>   rt_16550_reg_out(mode, 0, 0x20, 0x20);
> if (ctx->irq_handle.irq <= 15)          /* extra EOI for upper ISA IRQs */
>   rt_16550_reg_out(mode, 0, 0x20, 0x20);
> 
> But again I don't know if that will work with shared interrupts. Surely
> RTDM implements some "master" handler which is already doing an EOI?
> Remember lower interrupts like IRQ 5 work fine with the xeno_16550A driver

As noted in the other thread, IRQ 5 is most probably wrong. Check what
Linux uses when you attach the device to a normal Linux driver.

Jan

> unless another port is sharing the same IRQ.
> 
> -C Smith
> 

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [Xenomai] Only 2 serial ports at a time with xeno_16550A driver
  2018-05-23  9:18 ` Jan Kiszka
@ 2018-05-23 14:56   ` Lennart Sorensen
  0 siblings, 0 replies; 16+ messages in thread
From: Lennart Sorensen @ 2018-05-23 14:56 UTC (permalink / raw)
  To: Jan Kiszka; +Cc: xenomai

On Wed, May 23, 2018 at 11:18:04AM +0200, Jan Kiszka wrote:
> As noted in the other thread, IRQ 5 is most probably wrong. Check what
> Linux uses when you attach the device to a normal Linux driver.

Agreed.  PCs use IRQ 4 and 3 for serial ports at addresses 3f8, 2f8,
3e8 and 2e8.

ttyS0: 0x3f8 irq 4
ttyS1: 0x2f8 irq 3
ttyS2: 0x3e8 irq 4
ttyS3: 0x2f8 irq 3

It can often be changed, but those are the defaults.

-- 
Len Sorensen


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [Xenomai] Only 2 serial ports at a time with xeno_16550A driver
  2018-05-29  6:39 ` Jan Kiszka
@ 2018-05-30 17:39   ` C Smith
  0 siblings, 0 replies; 16+ messages in thread
From: C Smith @ 2018-05-30 17:39 UTC (permalink / raw)
  To: Jan Kiszka, xenomai

I configured BIOS so two ports shared IRQ5, and gave Linux kernel thoase
two ports with setserial:
/dev/ttyS0, UART: unknown, Port: 0x02e0, IRQ: 10
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 5
/dev/ttyS2, UART: unknown, Port: 0x03f8, IRQ: 4
/dev/ttyS3, UART: 16550A, Port: 0x02e8, IRQ: 5

Using Minicom to send some bytes (sucessfully) out of port 0x02f8, IRQ5
/proc/interrupts shows one more interrupt every time I send a byte out the
port:
           CPU0       CPU1       CPU2       CPU3
  5:         26         13          1          0   IO-APIC-edge      serial

But if I subsequently take those ports away from kernel with setserial
(with no changes to BIOS) and load xeno_16550A like this:
modprobe xeno_16550A io=0x02e0,0x02f8,0x03f8,0x02e8 irq=10,5,4,5
baud_base=115200,115200,115200,115200

I get file descriptors when the ports are initialized:
successfully initialized serial device rtser1 (fd=12)   [OK]
successfully initialized serial device rtser0 (fd=13)   [OK]
successfully initialized serial device rtser2 (fd=14)   [OK]
successfully initialized serial device rtser3 (fd=15)   [OK]

But the ports which share IRQ5 can't communicate.
While the port on 0x03f8 IRQ4 can communicate successfully.

So sharing IRQ5 is not working, and there is no way in the BIOS for these
ports to share another interrupt.

-C Smith
PS: Sorry Gmail was hiding your messages so I couldn't Reply to them.
<Trying a Reply here...>


On Mon, May 28, 2018 at 11:39 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:

> On 2018-05-28 19:21, C Smith wrote:
> > Jan wrote:
> >> Platform UART IRQs are assumed to be edge-triggered (see irqtype
> >> variable) - maybe your special board is different in this regard as
> >> well. Try removing RTDM_IRQTYPE_EDGE.
> >
> > I couldn't find a kernel option called RTDM_IRQTYPE_EDGE, either with
> 'make
> > menuconfig' or by grepping the Xenomai sources.
> >
> > So I assumed you meant do do this in include/rtdm_driver.h ?
> > /* #define RTDM_IRQTYPE_EDGE        XN_ISR_EDGE */   // just a test
> > #define RTDM_IRQTYPE_EDGE 0
> >
> > I  recompiled the xeno_16550A driver this way and it behaved no better. I
> > still can't get an interrupt if two serial ports share an IRQ.
> >
>
> How does /proc/interrupts look like when you have Linux driving all UARTs?
>
> Jan
>
> PS: You mail program is constantly breaking the topic threading - or you
> are not replying to the previous answers but writing new emails.
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [Xenomai] Only 2 serial ports at a time with xeno_16550A driver
  2018-05-28 17:21 C Smith
@ 2018-05-29  6:39 ` Jan Kiszka
  2018-05-30 17:39   ` C Smith
  0 siblings, 1 reply; 16+ messages in thread
From: Jan Kiszka @ 2018-05-29  6:39 UTC (permalink / raw)
  To: C Smith, xenomai

On 2018-05-28 19:21, C Smith wrote:
> Jan wrote:
>> Platform UART IRQs are assumed to be edge-triggered (see irqtype
>> variable) - maybe your special board is different in this regard as
>> well. Try removing RTDM_IRQTYPE_EDGE.
> 
> I couldn't find a kernel option called RTDM_IRQTYPE_EDGE, either with 'make
> menuconfig' or by grepping the Xenomai sources.
> 
> So I assumed you meant do do this in include/rtdm_driver.h ?
> /* #define RTDM_IRQTYPE_EDGE        XN_ISR_EDGE */   // just a test
> #define RTDM_IRQTYPE_EDGE 0
> 
> I  recompiled the xeno_16550A driver this way and it behaved no better. I
> still can't get an interrupt if two serial ports share an IRQ.
> 

How does /proc/interrupts look like when you have Linux driving all UARTs?

Jan

PS: You mail program is constantly breaking the topic threading - or you
are not replying to the previous answers but writing new emails.

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Xenomai] Only 2 serial ports at a time with xeno_16550A driver
@ 2018-05-28 17:21 C Smith
  2018-05-29  6:39 ` Jan Kiszka
  0 siblings, 1 reply; 16+ messages in thread
From: C Smith @ 2018-05-28 17:21 UTC (permalink / raw)
  To: xenomai

Jan wrote:
>Platform UART IRQs are assumed to be edge-triggered (see irqtype
>variable) - maybe your special board is different in this regard as
>well. Try removing RTDM_IRQTYPE_EDGE.

I couldn't find a kernel option called RTDM_IRQTYPE_EDGE, either with 'make
menuconfig' or by grepping the Xenomai sources.

So I assumed you meant do do this in include/rtdm_driver.h ?
/* #define RTDM_IRQTYPE_EDGE        XN_ISR_EDGE */   // just a test
#define RTDM_IRQTYPE_EDGE 0

I  recompiled the xeno_16550A driver this way and it behaved no better. I
still can't get an interrupt if two serial ports share an IRQ.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [Xenomai] Only 2 serial ports at a time with xeno_16550A driver
  2018-05-24  7:24 C Smith
@ 2018-05-24  7:34 ` Jan Kiszka
  0 siblings, 0 replies; 16+ messages in thread
From: Jan Kiszka @ 2018-05-24  7:34 UTC (permalink / raw)
  To: C Smith, xenomai

On 2018-05-24 09:24, C Smith wrote:
> Jan Kiska wrote:
>> Just like under Linux, the driver does not have to worry about that
>> details. Xenomai will EOI the IRQ when needed. The driver handler just
>> need to tell if a particular invocation was (also) triggered by the
>> device it drives.
> 
> I trust the EOI is taken care of automatically, as you say.
> 
> However I am on a special industrial motherboard whose BIOS allows the use
> of IRQ 5 for certain serial ports. There is no mistake, I chose IRQ 5 in
> the BIOS (only choices are 5 and 10, but 10 conflicts with a PCI card).
> Here is the kernel's dmesg at boot:
> [    0.536089] 00:05: ttyS1 at I/O 0x2f8 (irq = 5, base_baud = 115200) is a
> 16550A
> Here is setserial /dev/ttyS1 after boot:
> /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 5
> 
> When xeno_16550A module is invoked with one of the ports on IRQ 5 like this:
> xeno_16550A io=0x02e0,0x02f8,0x3f8 irq=10,5,4 baud_base=115200,115200,115200
> The port at 0x02f8 IRQ 5 behaves fine and transmits and receives OK.
> 
> But when the xeno_16550A module is invoked with more than one of the ports
> set to IRQ 5 in the BIOS like this:
> xeno_16550A io=0x02e0,0x02f8,0x03e8,0x02e8 irq=5,5,5,5
> baud_base=115200,115200,115200,115200
> All those ports fail to work, only one byte can be transmitted or received.
> 
> On this same motherboard, a Moxa PCI card can share IRQ17 between 4 ports
> OK using xeno_16550A, demonstrating that the kernel/modules are compiled
> correctly.
> But there seems to be a problem with sharing IRQ 5.
> 

Platform UART IRQs are assumed to be edge-triggered (see irqtype
variable) - maybe your special board is different in this regard as
well. Try removing RTDM_IRQTYPE_EDGE.

Jan
-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Xenomai] Only 2 serial ports at a time with xeno_16550A driver
@ 2018-05-24  7:24 C Smith
  2018-05-24  7:34 ` Jan Kiszka
  0 siblings, 1 reply; 16+ messages in thread
From: C Smith @ 2018-05-24  7:24 UTC (permalink / raw)
  To: xenomai

Jan Kiska wrote:
>Just like under Linux, the driver does not have to worry about that
>details. Xenomai will EOI the IRQ when needed. The driver handler just
>need to tell if a particular invocation was (also) triggered by the
>device it drives.

I trust the EOI is taken care of automatically, as you say.

However I am on a special industrial motherboard whose BIOS allows the use
of IRQ 5 for certain serial ports. There is no mistake, I chose IRQ 5 in
the BIOS (only choices are 5 and 10, but 10 conflicts with a PCI card).
Here is the kernel's dmesg at boot:
[    0.536089] 00:05: ttyS1 at I/O 0x2f8 (irq = 5, base_baud = 115200) is a
16550A
Here is setserial /dev/ttyS1 after boot:
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 5

When xeno_16550A module is invoked with one of the ports on IRQ 5 like this:
xeno_16550A io=0x02e0,0x02f8,0x3f8 irq=10,5,4 baud_base=115200,115200,115200
The port at 0x02f8 IRQ 5 behaves fine and transmits and receives OK.

But when the xeno_16550A module is invoked with more than one of the ports
set to IRQ 5 in the BIOS like this:
xeno_16550A io=0x02e0,0x02f8,0x03e8,0x02e8 irq=5,5,5,5
baud_base=115200,115200,115200,115200
All those ports fail to work, only one byte can be transmitted or received.

On this same motherboard, a Moxa PCI card can share IRQ17 between 4 ports
OK using xeno_16550A, demonstrating that the kernel/modules are compiled
correctly.
But there seems to be a problem with sharing IRQ 5.

-C Smith

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [Xenomai] Only 2 serial ports at a time with xeno_16550A driver
  2018-05-20  7:43 C Smith
  2018-05-20  7:53 ` Jan Kiszka
@ 2018-05-23  4:55 ` Jan Kiszka
  1 sibling, 0 replies; 16+ messages in thread
From: Jan Kiszka @ 2018-05-23  4:55 UTC (permalink / raw)
  To: C Smith, xenomai

On 2018-05-20 09:43, C Smith wrote:
> An update:
> In the modprobe, I tried putting first the two ports which share IRQ 5:
> modprobe xeno_16550A io=0x02f8,0x2e8,0x3f8 irq=5,5,4

BTW, the x86 platform UARTs use IRQ4 (port 1 and 3) and IRQ3 (port 2 and 4).

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [Xenomai] Only 2 serial ports at a time with xeno_16550A driver
  2018-05-22 18:31 C Smith
@ 2018-05-22 18:38 ` Greg Gallagher
  0 siblings, 0 replies; 16+ messages in thread
From: Greg Gallagher @ 2018-05-22 18:38 UTC (permalink / raw)
  To: C Smith; +Cc: Xenomai@xenomai.org

This is highly likely, I'm not sure when this driver was last tested.
Are you able to put a patch together?  Has anyone else sense similar
behaviour?

-Greg

On Tue, May 22, 2018 at 2:31 PM, C Smith <csmithquestions@gmail.com> wrote:
> I think I may have found a bug in the rtl_16550A driver when using shared
> interrupts. (I am on Xenomai 2.6.5. Kernel 3.18.20.)
>
> I think the interrupt handler is not sending an EOI to the lower (ISA 8259)
> interrupt controller, though it certainly is doing the right thing for
> higher IRQs above 16.
>
> I used a Moxa 4-port serial card in the PCI bus which has all 4 ports
> sharing IRQ 17. The rtl_16550A driver can use all 4 ports OK.
>
> But the rtl_16550A driver stalls after one interrupt when I use multiple
> serial ports on my motherboard where all the serial ports share IRQ 5. This
> is indicated by the fact that I can send one byte out the port, or I can
> get a single byte into the port, before the port can no longer send or
> receive anything further.
>
> I diffed the Xenomai 3.0.5 source versus the 2.6.5 rtl_16550A.c source and
> the code is very similar so the liability is in both branches I assume.
>
> -C Smith
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Xenomai] Only 2 serial ports at a time with xeno_16550A driver
@ 2018-05-22 18:31 C Smith
  2018-05-22 18:38 ` Greg Gallagher
  0 siblings, 1 reply; 16+ messages in thread
From: C Smith @ 2018-05-22 18:31 UTC (permalink / raw)
  To: xenomai

I think I may have found a bug in the rtl_16550A driver when using shared
interrupts. (I am on Xenomai 2.6.5. Kernel 3.18.20.)

I think the interrupt handler is not sending an EOI to the lower (ISA 8259)
interrupt controller, though it certainly is doing the right thing for
higher IRQs above 16.

I used a Moxa 4-port serial card in the PCI bus which has all 4 ports
sharing IRQ 17. The rtl_16550A driver can use all 4 ports OK.

But the rtl_16550A driver stalls after one interrupt when I use multiple
serial ports on my motherboard where all the serial ports share IRQ 5. This
is indicated by the fact that I can send one byte out the port, or I can
get a single byte into the port, before the port can no longer send or
receive anything further.

I diffed the Xenomai 3.0.5 source versus the 2.6.5 rtl_16550A.c source and
the code is very similar so the liability is in both branches I assume.

-C Smith

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Xenomai] Only 2 serial ports at a time with xeno_16550A driver
@ 2018-05-22  6:09 C Smith
  0 siblings, 0 replies; 16+ messages in thread
From: C Smith @ 2018-05-22  6:09 UTC (permalink / raw)
  To: xenomai

Update:
I installed a Moxa 4 port PCI serial card, which has a shared interrupt for
all 4 ports.
I did this:
modprobe xeno_16550A io=0xd040,0xd048,0xd050,0xd058 irq=17,17,17,17
baud_base=921600,921600,921600,921600

This worked fine, I was able to communicate bidirectionally on all four
ports in sequence, indicating that my kernel and xeno_16550A module are
compiled correctly for shared interrupts. I'll try simultaneous use of
these ports tomorrow.

The previous problem must have been the actual serial ports I was using,
which are the ones provided by the motherboard.

thanks,
-C Smith

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Xenomai] Only 2 serial ports at a time with xeno_16550A driver
@ 2018-05-21 18:07 C Smith
  0 siblings, 0 replies; 16+ messages in thread
From: C Smith @ 2018-05-21 18:07 UTC (permalink / raw)
  To: xenomai

Ah OK, I recompiled the kernel so xenomai has shared interrupts now. I
thought that flag was for level-sensitive interrupts. The attached patch
may clarify this for people in the future.

But although rt_dev_open() now successfully returns a file descriptor when
opening the two serial ports (which share IRQ 5), neither of those serial
ports can communicate.
I got only a single byte into my xenomai app from one of those ports.
This seems like the kind of behavior one would get if, in the handler,
there is no re-enable of of the interrupt at the controller level. It seems
the IRQ is firing only once.

thanks,
-C Smith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xeno_shirq-help.patch
Type: text/x-patch
Size: 656 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20180521/07c8b213/attachment.bin>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [Xenomai] Only 2 serial ports at a time with xeno_16550A driver
  2018-05-20  7:43 C Smith
@ 2018-05-20  7:53 ` Jan Kiszka
  2018-05-23  4:55 ` Jan Kiszka
  1 sibling, 0 replies; 16+ messages in thread
From: Jan Kiszka @ 2018-05-20  7:53 UTC (permalink / raw)
  To: C Smith, xenomai

On 2018-05-20 09:43, C Smith wrote:
> An update:
> In the modprobe, I tried putting first the two ports which share IRQ 5:
> modprobe xeno_16550A io=0x02f8,0x2e8,0x3f8 irq=5,5,4
> results:
> "successfully initialized serial device rtser1 (fd=12)
> Problem setting up serial port 0 on rtser0, got: -16
> successfully initialized serial device rtser2 (fd=13)"
> 
> So rt_dev_open() returns -EBUSY on the first port which shared IRQ 5
> 
> Then I tried initializing only the two ports which share IRQ 5:
> modprobe xeno_16550A io=0x02f8,0x2e8 irq=5,5
> results:
> "successfully initialized serial device rtser1 (fd=12)
> Problem setting up serial port 0 on rtser0, got: -16"
> 
> So rt_dev_open() returns -EBUSY on the first port which shared IRQ 5
> 
> I reversed the order of the two ports which share IRQ 5:
>  modprobe xeno_16550A io=0x02e8,0x2f8 irq=5,5
> results:
> "successfully initialized serial device rtser1 (fd=12)
> Problem setting up serial port 0 on rtser0, got: -16"
> 
> So again rt_dev_open() returns -EBUSY on the first port which shared IRQ 5,
> even though it is a different port address now.
> 
> I recompiled the xeno_16550A driver with some printk()s in function
> rt_16550_init_io() of 16550A_io.h. That function has the potential to
> return -EBUSY if request_region() or mapped_io[] indicate failure, but
> nothing printed to dmesg when rt_dev_open() failed.
> 
> How else can I analyze why rt_dev_open() thinks a port is unavailable?
> 

Do you have CONFIG_XENO_OPT_SHIRQ enabled in your kernel?

Jan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://xenomai.org/pipermail/xenomai/attachments/20180520/ee3c79a9/attachment.sig>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Xenomai] Only 2 serial ports at a time with xeno_16550A driver
@ 2018-05-20  7:43 C Smith
  2018-05-20  7:53 ` Jan Kiszka
  2018-05-23  4:55 ` Jan Kiszka
  0 siblings, 2 replies; 16+ messages in thread
From: C Smith @ 2018-05-20  7:43 UTC (permalink / raw)
  To: xenomai

An update:
In the modprobe, I tried putting first the two ports which share IRQ 5:
modprobe xeno_16550A io=0x02f8,0x2e8,0x3f8 irq=5,5,4
results:
"successfully initialized serial device rtser1 (fd=12)
Problem setting up serial port 0 on rtser0, got: -16
successfully initialized serial device rtser2 (fd=13)"

So rt_dev_open() returns -EBUSY on the first port which shared IRQ 5

Then I tried initializing only the two ports which share IRQ 5:
modprobe xeno_16550A io=0x02f8,0x2e8 irq=5,5
results:
"successfully initialized serial device rtser1 (fd=12)
Problem setting up serial port 0 on rtser0, got: -16"

So rt_dev_open() returns -EBUSY on the first port which shared IRQ 5

I reversed the order of the two ports which share IRQ 5:
 modprobe xeno_16550A io=0x02e8,0x2f8 irq=5,5
results:
"successfully initialized serial device rtser1 (fd=12)
Problem setting up serial port 0 on rtser0, got: -16"

So again rt_dev_open() returns -EBUSY on the first port which shared IRQ 5,
even though it is a different port address now.

I recompiled the xeno_16550A driver with some printk()s in function
rt_16550_init_io() of 16550A_io.h. That function has the potential to
return -EBUSY if request_region() or mapped_io[] indicate failure, but
nothing printed to dmesg when rt_dev_open() failed.

How else can I analyze why rt_dev_open() thinks a port is unavailable?

thanks,
-C Smith

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Xenomai] Only 2 serial ports at a time with xeno_16550A driver
@ 2018-05-19  5:30 C Smith
  0 siblings, 0 replies; 16+ messages in thread
From: C Smith @ 2018-05-19  5:30 UTC (permalink / raw)
  To: xenomai

The xeno_16550A driver works on my system but I can't get it to use more
than two ports at a time.

'dmesg' after the kernel boots shows this:
[    0.538264] 00:05: ttyS1 at I/O 0x2f8 (irq = 5, base_baud = 115200) is a
16550A
[    0.559280] 00:06: ttyS3 at I/O 0x2e8 (irq = 5, base_baud = 115200) is a
16550A
[    0.580306] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a
16550A
[    0.601275] 0000:00:16.3: ttyS2 at I/O 0xf0a0 (irq = 19, base_baud =
115200) is a 16550A

If I load xeno_16550A in either of these two ways below my code can use
both serial ports listed, so we know that all three ports work OK:
[root@neon ~]# modprobe xeno_16550A io=0x3f8,0x02f8 irq=4,5
[root@neon ~]# modprobe xeno_16550A io=0x3f8,0x02e8 irq=4,5

But this always fails to allow 3 ports to work:
modprobe xeno_16550A io=0x3f8,0x02f8,0x02e8  irq=4,5,5
Only the first two ports can be initialized, the third gets a "device or
resource busy", rt_dev_open() returns -16.

My code snippet is:

struct rtser_config serial_config = {
        .config_mask       = 0xFFFF,
        .baud_rate         = 115200,
        .parity            = RTSER_NO_PARITY,
        .data_bits         = RTSER_8_BITS,
        .stop_bits         = RTSER_1_STOPB,
        .handshake         = RTSER_NO_HAND,
        .fifo_depth        = RTSER_DEF_FIFO_DEPTH, //RTSER_FIFO_DEPTH_8,
    // I'd rather not initialize this, but compiler error if not
    .reserved          = 0,
        .rx_timeout        = 500000, /* 500 us */
        .tx_timeout        = RTSER_DEF_TIMEOUT,
        .event_timeout     = 5000000, /* 5 ms */
        .timestamp_history = RTSER_RX_TIMESTAMP_HISTORY,
        .event_mask        = RTSER_EVENT_RXPEND,
};

static int fd_tty[MAX_NUM_SERIAL_PORT];   /* file descriptors for serial
ports */

/* a for() loop on port_num is here. ports are not initialized in order,
BTW. */
fd_tty[port_num] = rt_dev_open(tmpstr, O_RDWR | O_NONBLOCK);
if (fd_tty[port_num] < 0)
{
   printf("Problem setting up serial port %d on %s, got: %d\n", port_num,
tmpstr, fd_tty[port_num]);
}
else
{
   int ser_return;
   ser_return = rt_dev_ioctl(fd_tty[port_num], RTSER_RTIOC_SET_CONFIG,
&serial_config);
   if (ser_return < 0)
   {
      printf("serial device %s initialization failed with: (%d)\n",tmpstr,
ser_return);
   }
   else if (ser_return >= 0)
   {
      printf("successfully initialized serial device rtser%d
(fd=%d)\n",port_num,fd_tty[port_num]);
   }
}

This is the output as ports get initialized:
successfully initialized serial device rtser1 (fd=12)
successfully initialized serial device rtser0 (fd=13)
Problem setting up serial port 2 on rtser2, got: -16

I tried this with serial compiled into the kernel and I took the ports away
from the kernel with 'setserial /dev/ttyS_ uart none', and also I tried
with serial as kernel modules and I removed the modules - so there was no
possibility of the kernel using the serial ports.

Is there somehow a limit of 2 ports compiled into the xeno_16550A driver ?
Or is the driver having trouble with the shared interrupt 5?

I am using Xenomai 2.6.5 on kernel 3.18.20

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2018-05-30 17:39 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-23  5:25 [Xenomai] Only 2 serial ports at a time with xeno_16550A driver C Smith
2018-05-23  9:18 ` Jan Kiszka
2018-05-23 14:56   ` Lennart Sorensen
  -- strict thread matches above, loose matches on Subject: below --
2018-05-28 17:21 C Smith
2018-05-29  6:39 ` Jan Kiszka
2018-05-30 17:39   ` C Smith
2018-05-24  7:24 C Smith
2018-05-24  7:34 ` Jan Kiszka
2018-05-22 18:31 C Smith
2018-05-22 18:38 ` Greg Gallagher
2018-05-22  6:09 C Smith
2018-05-21 18:07 C Smith
2018-05-20  7:43 C Smith
2018-05-20  7:53 ` Jan Kiszka
2018-05-23  4:55 ` Jan Kiszka
2018-05-19  5:30 C Smith

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.