Well almost all my issues ;) At the moment there is missing support for having more than one SC16IS7xx device. Because of this there is a name conflict in sysfs: [ 3.241912] sysfs: cannot create duplicate filename '/class/tty/ttySC1' ... [ 3.312774] [<c01b157c>] (sysfs_warn_dup) from [<c01b188c>] (sysfs_do_create_link_sd.isra.2+0xa8/0xb4) [ 3.323974] [<c01b188c>] (sysfs_do_create_link_sd.isra.2) from [<c03cd5a4>] (device_add+0x200/0x520) [ 3.333557] [<c03cd5a4>] (device_add) from [<c039d834>] (tty_register_device_attr+0x1c8/0x240) [ 3.333557] [<c039d834>] (tty_register_device_attr) from [<c03b8e84>] (uart_add_one_port+0x1c4/0x48c) [ 3.352294] [<c03b8e84>] (uart_add_one_port) from [<c03c0d0c>] (sc16is7xx_i2c_probe+0x334/0x520) [ 3.353271] [<c03c0d0c>] (sc16is7xx_i2c_probe) from [<c04cc52c>] (i2c_device_probe+0xf4/0x14c) ... I will see if I can find a solution for this. It must be possible as the USB serial core has no problem adding ttyUSBX interfaces for each device plugged in... Any hints as always would be appreciated. Cheers, Michael Michael Allwright PhD Student Paderborn Institute for Advanced Studies in Computer Science and Engineering University of Paderborn Office-number 02-10 Zukunftsmeile 1 33102 Paderborn Germany On 25 June 2015 at 10:29, Michael Allwright <michael.allwright@xxxxxx> wrote: > Hi Jon and Jakub, > > Thanks for the link, that patch solved the remaining issues on my > platform. I can confirm that the new version of the driver (using the > kworker_threads) + Bo's patch allowed me to connect simultaneously to > both UARTs on the SC16IS762 at 57600bps on the OMAP4 platform. There > were no errors or warnings displayed in the kernel log during this > test. > > My test was conducted in kernel version 4.0.5 stable, with an external > oscillator using a GPIO enable. This configuration was entirely set up > using the device tree. > > Thanks again Jon, Jakub and Bo! > > All the best, > > Michael > Michael Allwright > > PhD Student > Paderborn Institute for Advanced Studies in Computer Science and Engineering > > University of Paderborn > Office-number 02-47 > Zukunftsmeile 1 > 33102 Paderborn > Germany > > > On 24 June 2015 at 19:15, Jakub Kiciński <moorray3@xxxxx> wrote: >> Hi Jon and Michael, >> >> On Wed, 24 Jun 2015 12:47:16 -0400, Jon Ringle wrote: >>> +Jakub, linux-serial >>> >>> Michael, let the list know what you find. I don't have access to a >>> sc16is7xx device with more than one port. >>> >>> Jon >>> >>> On Wed, Jun 24, 2015 at 10:59 AM, Michael Allwright >>> <michael.allwright@xxxxxx> wrote: >>> > Thanks Jon, >>> > >>> > This version of the driver is no longer causing those threading >>> > complaints on the OMAP4 platform, opening the first port of the >>> > sc16is762 works perfectly, but the second port appears to be >>> > overflowing and giving me garbage. Even after exiting picocom I get >>> > these messages every 2-3 seconds and the system takes a long time (a >>> > minute or so?) to recover. >>> > >>> > [ 505.289154] sc16is7xx_handle_rx: XXXX callbacks suppressed >>> > [ 505.294921] sc16is7xx 1-0048: Port 1: Possible RX FIFO overrun: 64 >>> > [ 505.303894] sc16is7xx 1-0048: Port 1: Possible RX FIFO overrun: 64 >>> > [ 505.312835] sc16is7xx 1-0048: Port 1: Possible RX FIFO overrun: 64 >>> > [ 505.321807] sc16is7xx 1-0048: Port 1: Possible RX FIFO overrun: 64 >>> > [ 505.330688] sc16is7xx 1-0048: Port 1: Possible RX FIFO overrun: 64 >>> > [ 505.339599] sc16is7xx 1-0048: Port 1: Possible RX FIFO overrun: 64 >>> > [ 505.348663] sc16is7xx 1-0048: Port 1: Possible RX FIFO overrun: 64 >>> > [ 505.357635] sc16is7xx 1-0048: Port 1: Possible RX FIFO overrun: 64 >>> > [ 505.366577] sc16is7xx 1-0048: Port 1: Possible RX FIFO overrun: 64 >>> > [ 505.375701] sc16is7xx 1-0048: Port 1: Possible RX FIFO overrun: 64 >>> > >>> > where XXXX is typically around 2000 callbacks. I will investigate >>> > tomorrow and try find a solution. >> >> I don't have any dual-port devices to test either unfortunately but it >> looks like the issue Bo was trying to fix recently [1]. Please try his >> patch and let us know if it solves the problem for you. The patch did >> not make it into tty-next before the merge window so it will take at >> least two weeks before it shows up there. I don't have any dual-port >> devices to test this either unfortunately. >> >> [1] http://www.spinics.net/lists/linux-serial/msg17820.html -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
