* Re: [PATCH] serial: 8250: Fix THRE flag usage for CAP_MINI
From: Phil Elwell @ 2017-06-28 8:09 UTC (permalink / raw)
To: Andy Shevchenko, Stefan Wahren, Greg Kroah-Hartman, Peter Hurley,
Yegor Yefremov, Jan Kiszka, linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1498636112.22624.212.camel-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On 28/06/2017 08:48, Andy Shevchenko wrote:
> On Tue, 2017-06-27 at 22:00 +0100, Phil Elwell wrote:
>> On 27/06/2017 18:52, Andy Shevchenko wrote:
>>> On Tue, 2017-06-27 at 11:30 +0100, Phil Elwell wrote:
>>>> On 27/06/2017 10:15, Andy Shevchenko wrote:
>>>>> On Mon, 2017-06-26 at 16:15 +0100, Phil Elwell wrote:
>
>>>>>> Besides, the "HFIFO" capability looks a lot like quirk to me.
>>>>>
>>>>> To me either, which raises a question "Should it be fixed
>>>>> accordingly?"
>>>>
>>>> If I was going to make these quirks, are we simply talking about
>>>> renaming the
>>>> capability or is there another mechanism? I've found the 8250_pci
>>>> quirks, and
>>>> they look quite different.
>>>
>>> Okay, we have several types of flags in the code
>>> 1. Capabilities: UART_CAP: looks like it defines features of
>>> hardware
>>> solely for 8250 compatible devices.
>>> 2. Flags as quirks UPF_<something, not all of them> (I have a patch
>>> to
>>> convert them to quirks, need by the way to update and resend): they
>>> are
>>> for any serial devices.
>>> 3. Flags as capabilities: UPF_<the rest>, similar function as
>>> UART_CAP,
>>> but for any serial device.
>>>
>>>>
>>>> I'm also happy to make this code conditional on
>>>> CONFIG_SERIAL_8250_BCM2835AUX
>>>> if that is more acceptable.
>>>
>>> No, it is undesired.
>>>
>>> Can you describe which one from the above suits the best for your
>>> case?
>>
>> This bug I am trying to work around is found in the 8250
>> implementation of
>> one family of CPUs, so I would say capabilities are the best fit
>> because
>> they are specific to 8250 drivers.
>
> Yeah, looks like UART_CAP suits the best for now.
>
> One more comment that UART_CAP_* gather capabilities and quirks at the
> same time.
Is that a request for an additional comment? Is there anything else needed
for an ack?
Thanks,
Phil
^ permalink raw reply
* Re: [PATCH] serial: 8250: Fix THRE flag usage for CAP_MINI
From: Andy Shevchenko @ 2017-06-28 7:48 UTC (permalink / raw)
To: Phil Elwell, Stefan Wahren, Greg Kroah-Hartman, Peter Hurley,
Yegor Yefremov, Jan Kiszka, linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <aeee2737-623c-c45b-bb18-4ff488684d0c-FnsA7b+Nu9XbIbC87yuRow@public.gmane.org>
On Tue, 2017-06-27 at 22:00 +0100, Phil Elwell wrote:
> On 27/06/2017 18:52, Andy Shevchenko wrote:
> > On Tue, 2017-06-27 at 11:30 +0100, Phil Elwell wrote:
> > > On 27/06/2017 10:15, Andy Shevchenko wrote:
> > > > On Mon, 2017-06-26 at 16:15 +0100, Phil Elwell wrote:
> > > > > Besides, the "HFIFO" capability looks a lot like quirk to me.
> > > >
> > > > To me either, which raises a question "Should it be fixed
> > > > accordingly?"
> > >
> > > If I was going to make these quirks, are we simply talking about
> > > renaming the
> > > capability or is there another mechanism? I've found the 8250_pci
> > > quirks, and
> > > they look quite different.
> >
> > Okay, we have several types of flags in the code
> > 1. Capabilities: UART_CAP: looks like it defines features of
> > hardware
> > solely for 8250 compatible devices.
> > 2. Flags as quirks UPF_<something, not all of them> (I have a patch
> > to
> > convert them to quirks, need by the way to update and resend): they
> > are
> > for any serial devices.
> > 3. Flags as capabilities: UPF_<the rest>, similar function as
> > UART_CAP,
> > but for any serial device.
> >
> > >
> > > I'm also happy to make this code conditional on
> > > CONFIG_SERIAL_8250_BCM2835AUX
> > > if that is more acceptable.
> >
> > No, it is undesired.
> >
> > Can you describe which one from the above suits the best for your
> > case?
>
> This bug I am trying to work around is found in the 8250
> implementation of
> one family of CPUs, so I would say capabilities are the best fit
> because
> they are specific to 8250 drivers.
Yeah, looks like UART_CAP suits the best for now.
One more comment that UART_CAP_* gather capabilities and quirks at the
same time.
--
Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Intel Finland Oy
^ permalink raw reply
* Re: [PATCH] serial: 8250: Fix THRE flag usage for CAP_MINI
From: Eric Anholt @ 2017-06-27 22:36 UTC (permalink / raw)
To: Phil Elwell, Greg Kroah-Hartman, Andy Shevchenko, Peter Hurley,
Yegor Yefremov, Jan Kiszka, linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1498485581-72097-1-git-send-email-phil-FnsA7b+Nu9XbIbC87yuRow@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1364 bytes --]
Phil Elwell <phil-FnsA7b+Nu9XbIbC87yuRow@public.gmane.org> writes:
> The BCM2835 MINI UART has non-standard THRE semantics. Conventionally
> the bit means that the FIFO is empty (although there may still be a
> byte in the transmit register), but on 2835 it indicates that the FIFO
> is not full. This causes interrupts after every byte is transmitted,
> with the FIFO providing some interrupt latency tolerance.
>
> A consequence of this difference is that the usual strategy of writing
> multiple bytes into the TX FIFO after checking THRE once is unsafe.
> In the worst case of 7 bytes in the FIFO, writing 8 bytes loses all
> but the first since by then the FIFO is full.
>
> There is an HFIFO ("Hidden FIFO") capability that causes the transmit
> loop to terminate when both THRE and TEMT are set, i.e. when the TX
> block is completely idle. This is unnecessarily cautious, potentially
> causing gaps in transmission.
>
> Add a new conditional to the transmit loop, predicated on CAP_MINI,
> that exits when THRE is no longer set (the FIFO is full). This allows
> the FIFO to fill quickly but subsequent writes are paced by the
> transmission rate.
>
> Signed-off-by: Phil Elwell <phil-FnsA7b+Nu9XbIbC87yuRow@public.gmane.org>
Confirmed the hw behavior, so as far as the platform goes,
Acked-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 206 bytes --]
_______________________________________________
linux-rpi-kernel mailing list
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel
^ permalink raw reply
* Re: Moxa UPort 1150 and RS-422/485… what's the "proper" way to switch modes
From: Stuart Longland @ 2017-06-27 22:07 UTC (permalink / raw)
To: Oliver Neukum, Johan Hovold
Cc: Alan Cox, linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1498565331.30390.5.camel-IBi9RG/b67k@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1862 bytes --]
On 27/06/17 22:08, Oliver Neukum wrote:
> Am Dienstag, den 27.06.2017, 19:43 +1000 schrieb Stuart Longland:
>> Maybe a good start would be a "standard" option (referring to the
>> physical signalling standard, TTL/RS-232/RS-422/RS-485), that lists the
>> available standards when read and shows the "selected" standard in
>> brackets (like the 'trigger' option of the LEDs sysfs interface)… so for
>> this case:
>>
>> # cat /sys/class/tty/ttyUSB0/standard
>> [rs232] rs422 rs485 rs485fd
>>
>> and to select 4-wire ("full duplex") RS-485, one does:
>> # echo rs485fd > /sys/class/tty/ttyUSB0/standard
> This looks like something that people will put into udev.
> So the switch will be done via udev, but the user not necessarily
> started via udev. Looks like a race to me.
It is a race, but unless a daemon is watching for the very moment that a
particular serial interface appears, it's one that init scripts are very
likely to win.
Short of having a flag that blocks reads/writes until a given sysfs file
is written to say "I'm ready, go ahead"… there aren't that many options
I can think of.
> And what do you if the interface is already opened and the sysfs
> interface is used?
We return -EBUSY? If the interface is open, there isn't a lot we can
do, the user either puts up with unpredictable behaviour or we refuse
the switch.
By unpredictable behaviour: if the device is well behaved, there might
be a small signal level glitch… but I'd expect serial devices to be
tolerant of that kind of step change in signal. (Think hot-plugging
serial links.)
This beats the official Moxa solution: their Windows driver wants a
reboot of the entire machine to switch between serial standards.
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] serial: 8250: Fix THRE flag usage for CAP_MINI
From: Phil Elwell @ 2017-06-27 21:00 UTC (permalink / raw)
To: Andy Shevchenko, Stefan Wahren, Greg Kroah-Hartman, Peter Hurley,
Yegor Yefremov, Jan Kiszka, linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1498585950.22624.210.camel-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On 27/06/2017 18:52, Andy Shevchenko wrote:
> On Tue, 2017-06-27 at 11:30 +0100, Phil Elwell wrote:
>> On 27/06/2017 10:15, Andy Shevchenko wrote:
>>> On Mon, 2017-06-26 at 16:15 +0100, Phil Elwell wrote:
>>>
>>>>> But this looks like a bug / quirk than a capability?
>>>>>
>>>>> It would be better to name this define more self-explaining.
>>>>>
>>>>> Btw can't see the definition of UART_CAP_MINI?
>>>>
>>>> The capability was added in
>>>> d087e7a991f1f61ee2c07db1be7c5cc2aa373f5d,
>>>> which
>>>> is in linux-next. Given that the "capability" already exists and
>>>> the
>>>> quirk
>>>> is likely to be unique to BCM2835 MINI UART, I don't think we
>>>> should
>>>> create
>>>> a new quirk.
>>>>
>>>> Besides, the "HFIFO" capability looks a lot like quirk to me.
>>>
>>> To me either, which raises a question "Should it be fixed
>>> accordingly?"
>>
>> If I was going to make these quirks, are we simply talking about
>> renaming the
>> capability or is there another mechanism? I've found the 8250_pci
>> quirks, and
>> they look quite different.
>
> Okay, we have several types of flags in the code
> 1. Capabilities: UART_CAP: looks like it defines features of hardware
> solely for 8250 compatible devices.
> 2. Flags as quirks UPF_<something, not all of them> (I have a patch to
> convert them to quirks, need by the way to update and resend): they are
> for any serial devices.
> 3. Flags as capabilities: UPF_<the rest>, similar function as UART_CAP,
> but for any serial device.
>
>>
>> I'm also happy to make this code conditional on
>> CONFIG_SERIAL_8250_BCM2835AUX
>> if that is more acceptable.
>
> No, it is undesired.
>
> Can you describe which one from the above suits the best for your case?
This bug I am trying to work around is found in the 8250 implementation of
one family of CPUs, so I would say capabilities are the best fit because
they are specific to 8250 drivers.
Phil
^ permalink raw reply
* Re: [PATCH] serial: 8250: Fix THRE flag usage for CAP_MINI
From: Andy Shevchenko @ 2017-06-27 17:52 UTC (permalink / raw)
To: Phil Elwell, Stefan Wahren, Greg Kroah-Hartman, Peter Hurley,
Yegor Yefremov, Jan Kiszka, linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <2669bcda-e1f5-ecb1-a986-99947658bac7-FnsA7b+Nu9XbIbC87yuRow@public.gmane.org>
On Tue, 2017-06-27 at 11:30 +0100, Phil Elwell wrote:
> On 27/06/2017 10:15, Andy Shevchenko wrote:
> > On Mon, 2017-06-26 at 16:15 +0100, Phil Elwell wrote:
> >
> > > > But this looks like a bug / quirk than a capability?
> > > >
> > > > It would be better to name this define more self-explaining.
> > > >
> > > > Btw can't see the definition of UART_CAP_MINI?
> > >
> > > The capability was added in
> > > d087e7a991f1f61ee2c07db1be7c5cc2aa373f5d,
> > > which
> > > is in linux-next. Given that the "capability" already exists and
> > > the
> > > quirk
> > > is likely to be unique to BCM2835 MINI UART, I don't think we
> > > should
> > > create
> > > a new quirk.
> > >
> > > Besides, the "HFIFO" capability looks a lot like quirk to me.
> >
> > To me either, which raises a question "Should it be fixed
> > accordingly?"
>
> If I was going to make these quirks, are we simply talking about
> renaming the
> capability or is there another mechanism? I've found the 8250_pci
> quirks, and
> they look quite different.
Okay, we have several types of flags in the code
1. Capabilities: UART_CAP: looks like it defines features of hardware
solely for 8250 compatible devices.
2. Flags as quirks UPF_<something, not all of them> (I have a patch to
convert them to quirks, need by the way to update and resend): they are
for any serial devices.
3. Flags as capabilities: UPF_<the rest>, similar function as UART_CAP,
but for any serial device.
>
> I'm also happy to make this code conditional on
> CONFIG_SERIAL_8250_BCM2835AUX
> if that is more acceptable.
No, it is undesired.
Can you describe which one from the above suits the best for your case?
--
Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Intel Finland Oy
^ permalink raw reply
* Re: Moxa UPort 1150 and RS-422/485… what's the "proper" way to switch modes
From: Oliver Neukum @ 2017-06-27 12:08 UTC (permalink / raw)
To: Stuart Longland, Johan Hovold
Cc: Alan Cox, linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <42601356-656d-57d0-d366-a0933780b8f9-3e+Fe6x+DsgJbe36r25VNhCuuivNXqWP@public.gmane.org>
Am Dienstag, den 27.06.2017, 19:43 +1000 schrieb Stuart Longland:
> Maybe a good start would be a "standard" option (referring to the
> physical signalling standard, TTL/RS-232/RS-422/RS-485), that lists the
> available standards when read and shows the "selected" standard in
> brackets (like the 'trigger' option of the LEDs sysfs interface)… so for
> this case:
>
> # cat /sys/class/tty/ttyUSB0/standard
> [rs232] rs422 rs485 rs485fd
>
> and to select 4-wire ("full duplex") RS-485, one does:
> # echo rs485fd > /sys/class/tty/ttyUSB0/standard
This looks like something that people will put into udev.
So the switch will be done via udev, but the user not necessarily
started via udev. Looks like a race to me.
And what do you if the interface is already opened and the sysfs
interface is used?
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] serial: sirf: make of_device_ids const.
From: Arvind Yadav @ 2017-06-27 11:36 UTC (permalink / raw)
To: gregkh, jslaby, baohua; +Cc: linux-serial, linux-arm-kernel, linux-kernel
of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by <linux/of.h> work with const
of_device_ids. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
877 1864 88 2829 b0d drivers/tty/serial/sirfsoc_uart.o
File size after constify:
text data bss dec hex filename
1885 840 88 2813 afd drivers/tty/serial/sirfsoc_uart.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
drivers/tty/serial/sirfsoc_uart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/sirfsoc_uart.c b/drivers/tty/serial/sirfsoc_uart.c
index e03282d..684cb8d 100644
--- a/drivers/tty/serial/sirfsoc_uart.c
+++ b/drivers/tty/serial/sirfsoc_uart.c
@@ -1253,7 +1253,7 @@ static int __init sirfsoc_uart_console_init(void)
return HRTIMER_RESTART;
}
-static struct of_device_id sirfsoc_uart_ids[] = {
+static const struct of_device_id sirfsoc_uart_ids[] = {
{ .compatible = "sirf,prima2-uart", .data = &sirfsoc_uart,},
{ .compatible = "sirf,atlas7-uart", .data = &sirfsoc_uart},
{ .compatible = "sirf,prima2-usp-uart", .data = &sirfsoc_usp},
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] serial: 8250: Fix THRE flag usage for CAP_MINI
From: Phil Elwell @ 2017-06-27 10:30 UTC (permalink / raw)
To: Andy Shevchenko, Stefan Wahren, Greg Kroah-Hartman, Peter Hurley,
Yegor Yefremov, Jan Kiszka, linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1498554936.22624.180.camel-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On 27/06/2017 10:15, Andy Shevchenko wrote:
> On Mon, 2017-06-26 at 16:15 +0100, Phil Elwell wrote:
>
>>> But this looks like a bug / quirk than a capability?
>>>
>>> It would be better to name this define more self-explaining.
>>>
>>> Btw can't see the definition of UART_CAP_MINI?
>>
>> The capability was added in d087e7a991f1f61ee2c07db1be7c5cc2aa373f5d,
>> which
>> is in linux-next. Given that the "capability" already exists and the
>> quirk
>> is likely to be unique to BCM2835 MINI UART, I don't think we should
>> create
>> a new quirk.
>>
>> Besides, the "HFIFO" capability looks a lot like quirk to me.
>
> To me either, which raises a question "Should it be fixed accordingly?"
If I was going to make these quirks, are we simply talking about renaming the
capability or is there another mechanism? I've found the 8250_pci quirks, and
they look quite different.
I'm also happy to make this code conditional on CONFIG_SERIAL_8250_BCM2835AUX
if that is more acceptable.
Phil (still hoping to lose newb status one day)
^ permalink raw reply
* Re: Moxa UPort 1150 and RS-422/485… what's the "proper" way to switch modes
From: Stuart Longland @ 2017-06-27 9:43 UTC (permalink / raw)
To: Johan Hovold
Cc: linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Alan Cox
In-Reply-To: <20170627090449.GG3025@localhost>
[-- Attachment #1.1: Type: text/plain, Size: 3642 bytes --]
On 27/06/17 19:04, Johan Hovold wrote:
>> What's the "proper" way to configure such ports for RS-422 and/or 4-wire
>> RS-485? Is there an example driver in the tree that I can use as a
>> guide to porting Moxa's mode-switch code over to the ti_usb_3410_5052
>> driver?
>
> I'm afraid not. We have the TIOCSRS485 ioctl, but that doesn't really
> fit here (currently) as we're not just enabling 2-wire-rs485 style
> signalling (using RTS to control the tranceiver), but are also
> configuring the electrical interface (e.g. which pins on the DB9
> connector are being used for which functions).
>
> This question is raised every now and then; typically when a new
> driver is being merged (e.g. mxuport or when support for your device was
> added), but we have yet to decide on the proper interface.
>
> Extending the TIOCSRS485 ioctl has been discussed, and one alternative
> could be a sysfs-based interface as this would typically be something
> you'd want to configure at boot and before opening the device (and
> toggling DTR).
I did consider sysfs this morning… this would make a lot of sense.
These things being USB, it is possible that a udev trigger could put it
in the appropriate mode when they are plugged in. Sounds a much better
option than re-purposing other fields.
> Either way, we need do determine the right level of abstraction as some
> of the related properties are fairly device dependent (master/slave
> mode, terminating resistors, auto direction, echo, etc).
>
> For the record, note that we do have the mxser driver, and a few more
> old drivers, implementing custom ioctls for this, but we really should
> not be adding more of those.
Yeah, I won't be adding ioctls… it makes the interface too
hardware-specific. If anything, the ioctls might be a hint to what
enumerated properties to expose on sysfs, then the ioctl interface can
be gradually phased out.
I'll have a look at mxser. At this point I'm thinking gathering a
listing of what devices support what configuration options would be
worthwhile. I know the UPort 1150 supports 2-wire RS-485, 4-wire
RS-485, RS-422 and RS-232… the UPort 1100 drops support for RS-232… I
don't think either offer termination resistance options.
Maybe a good start would be a "standard" option (referring to the
physical signalling standard, TTL/RS-232/RS-422/RS-485), that lists the
available standards when read and shows the "selected" standard in
brackets (like the 'trigger' option of the LEDs sysfs interface)… so for
this case:
# cat /sys/class/tty/ttyUSB0/standard
[rs232] rs422 rs485 rs485fd
and to select 4-wire ("full duplex") RS-485, one does:
# echo rs485fd > /sys/class/tty/ttyUSB0/standard
A hypothetical dongle that supports pin re-mapping might have
properties: rxd, txd, rts, cts, dtr, dsr, cd, ri, gnd (for RS-232; maybe
a, b and gnd for RS-485 or txa, txb, rxa, rxb, gnd for
RS-422/full-duplex-RS-485) that gives the pin numbers/labels:
cd: [1] 2 3 4 5 6 7 8 9
rx: 1 [2] 3 4 5 6 7 8 9
tx: 1 2 [3] 4 5 6 7 8 9
… etc …
and termination resistance (separate options for RX and TX) might be a
selection of off, and the available resistances. (e.g. "50", "75",
"120", "1k" … whatever the device supports.)
I'm open to ideas here, I'm not sure how many configurable serial
interfaces there are out there (USB or otherwise), so if people watching
the list can provide some examples of these devices, this will be a big
help.
Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] serial: 8250: Fix THRE flag usage for CAP_MINI
From: Phil Elwell @ 2017-06-27 9:24 UTC (permalink / raw)
To: Andy Shevchenko, Greg Kroah-Hartman, Peter Hurley, Yegor Yefremov,
Jan Kiszka, linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1498555113.22624.182.camel-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On 27/06/2017 10:18, Andy Shevchenko wrote:
> On Mon, 2017-06-26 at 14:59 +0100, Phil Elwell wrote:
>> The BCM2835 MINI UART has non-standard THRE semantics. Conventionally
>> the bit means that the FIFO is empty (although there may still be a
>> byte in the transmit register), but on 2835 it indicates that the FIFO
>> is not full. This causes interrupts after every byte is transmitted,
>> with the FIFO providing some interrupt latency tolerance.
>>
>> A consequence of this difference is that the usual strategy of writing
>> multiple bytes into the TX FIFO after checking THRE once is unsafe.
>> In the worst case of 7 bytes in the FIFO, writing 8 bytes loses all
>> but the first since by then the FIFO is full.
>>
>> There is an HFIFO ("Hidden FIFO") capability that causes the transmit
>> loop to terminate when both THRE and TEMT are set, i.e. when the TX
>> block is completely idle. This is unnecessarily cautious, potentially
>> causing gaps in transmission.
>>
>> Add a new conditional to the transmit loop, predicated on CAP_MINI,
>> that exits when THRE is no longer set (the FIFO is full). This allows
>> the FIFO to fill quickly but subsequent writes are paced by the
>> transmission rate.
>>
>
>> if ((up->capabilities & UART_CAP_HFIFO) &&
>> (serial_in(up, UART_LSR) & BOTH_EMPTY) !=
>> BOTH_EMPTY)
>> break;
>> + /* The BCM2835 MINI UART THRE bit is really a not-
>> full bit. */
>> + if ((up->capabilities & UART_CAP_MINI) &&
>> + !(serial_in(up, UART_LSR) & UART_LSR_THRE))
>> + break;
>
> Might this end up with two sequential read of LSR?
The same thought crossed my mind, but CAP_MINI is essentially CAP_BCM2835,
and we won't be setting CAP_HFIFO on BCM2835.
^ permalink raw reply
* Re: [PATCH] serial: 8250: Fix THRE flag usage for CAP_MINI
From: Andy Shevchenko @ 2017-06-27 9:18 UTC (permalink / raw)
To: Phil Elwell, Greg Kroah-Hartman, Peter Hurley, Yegor Yefremov,
Jan Kiszka, linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1498485581-72097-1-git-send-email-phil-FnsA7b+Nu9XbIbC87yuRow@public.gmane.org>
On Mon, 2017-06-26 at 14:59 +0100, Phil Elwell wrote:
> The BCM2835 MINI UART has non-standard THRE semantics. Conventionally
> the bit means that the FIFO is empty (although there may still be a
> byte in the transmit register), but on 2835 it indicates that the FIFO
> is not full. This causes interrupts after every byte is transmitted,
> with the FIFO providing some interrupt latency tolerance.
>
> A consequence of this difference is that the usual strategy of writing
> multiple bytes into the TX FIFO after checking THRE once is unsafe.
> In the worst case of 7 bytes in the FIFO, writing 8 bytes loses all
> but the first since by then the FIFO is full.
>
> There is an HFIFO ("Hidden FIFO") capability that causes the transmit
> loop to terminate when both THRE and TEMT are set, i.e. when the TX
> block is completely idle. This is unnecessarily cautious, potentially
> causing gaps in transmission.
>
> Add a new conditional to the transmit loop, predicated on CAP_MINI,
> that exits when THRE is no longer set (the FIFO is full). This allows
> the FIFO to fill quickly but subsequent writes are paced by the
> transmission rate.
>
> if ((up->capabilities & UART_CAP_HFIFO) &&
> (serial_in(up, UART_LSR) & BOTH_EMPTY) !=
> BOTH_EMPTY)
> break;
> + /* The BCM2835 MINI UART THRE bit is really a not-
> full bit. */
> + if ((up->capabilities & UART_CAP_MINI) &&
> + !(serial_in(up, UART_LSR) & UART_LSR_THRE))
> + break;
Might this end up with two sequential read of LSR?
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
_______________________________________________
linux-rpi-kernel mailing list
linux-rpi-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel
^ permalink raw reply
* Re: [PATCH] serial: 8250: Fix THRE flag usage for CAP_MINI
From: Andy Shevchenko @ 2017-06-27 9:15 UTC (permalink / raw)
To: Phil Elwell, Stefan Wahren, Greg Kroah-Hartman, Peter Hurley,
Yegor Yefremov, Jan Kiszka, linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <bf050731-6b05-9e35-8b50-ea9115b4197f-FnsA7b+Nu9XbIbC87yuRow@public.gmane.org>
On Mon, 2017-06-26 at 16:15 +0100, Phil Elwell wrote:
> > But this looks like a bug / quirk than a capability?
> >
> > It would be better to name this define more self-explaining.
> >
> > Btw can't see the definition of UART_CAP_MINI?
>
> The capability was added in d087e7a991f1f61ee2c07db1be7c5cc2aa373f5d,
> which
> is in linux-next. Given that the "capability" already exists and the
> quirk
> is likely to be unique to BCM2835 MINI UART, I don't think we should
> create
> a new quirk.
>
> Besides, the "HFIFO" capability looks a lot like quirk to me.
To me either, which raises a question "Should it be fixed accordingly?"
--
Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Intel Finland Oy
^ permalink raw reply
* Re: Moxa UPort 1150 and RS-422/485… what's the "proper" way to switch modes
From: Johan Hovold @ 2017-06-27 9:04 UTC (permalink / raw)
To: Stuart Longland
Cc: linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Alan Cox
In-Reply-To: <4a469222-d48d-f498-f2db-ca582295adc3-3e+Fe6x+DsgJbe36r25VNhCuuivNXqWP@public.gmane.org>
[ +CC: Alan and linux-usb ]
On Fri, Jun 23, 2017 at 09:44:31AM +1000, Stuart Longland wrote:
> Hi all,
>
> A silly question: I have a Moxa UPort 1150 USB serial interface that I
> am trying to coax into either RS-422 or 4-wire RS-485 mode. Internally,
> this is a TI USB 3410 device, and works with the ti_usb_3410_5052 module.
>
> Moxa have a (poorly maintained as usual) driver for these devices, and I
> see reference to things like RS-485 in the TI driver. Moxa's driver did
> a kludge where they used `setserial` to control the mode, and used the
> device "port" number to set that mode. I do not think it wise to try
> and replicate that same kludge, as I understand that parameter is for
> configuring the I/O port (e.g. 0x3f8 for /dev/ttyS0 on older
> IBM-compatibles).
Agreed, and that's why we have rejected this interface when support for
Moxa devices have been added.
> Now, *some* versions of `stty` allegedly have an "rs485" option: mine
> (in coreutils 8.25) does not. I suspect this is 2-wire RS-485, which
> won't do here, as my RX and TX are on different RS-485 pairs.
Neither does mine, I think that's some out-of-tree support for the
TIOCSRS485 ioctl mentioned below.
> What's the "proper" way to configure such ports for RS-422 and/or 4-wire
> RS-485? Is there an example driver in the tree that I can use as a
> guide to porting Moxa's mode-switch code over to the ti_usb_3410_5052
> driver?
I'm afraid not. We have the TIOCSRS485 ioctl, but that doesn't really
fit here (currently) as we're not just enabling 2-wire-rs485 style
signalling (using RTS to control the tranceiver), but are also
configuring the electrical interface (e.g. which pins on the DB9
connector are being used for which functions).
This question is raised every now and then; typically when a new
driver is being merged (e.g. mxuport or when support for your device was
added), but we have yet to decide on the proper interface.
Extending the TIOCSRS485 ioctl has been discussed, and one alternative
could be a sysfs-based interface as this would typically be something
you'd want to configure at boot and before opening the device (and
toggling DTR).
Either way, we need do determine the right level of abstraction as some
of the related properties are fairly device dependent (master/slave
mode, terminating resistors, auto direction, echo, etc).
For the record, note that we do have the mxser driver, and a few more
old drivers, implementing custom ioctls for this, but we really should
not be adding more of those.
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 4/9] serial: atmel: Use common rs485 device tree parsing function
From: Richard Genoud @ 2017-06-27 8:27 UTC (permalink / raw)
To: Nicolas Ferre, Uwe Kleine-König, linux-serial,
linux-arm-kernel
Cc: devicetree, Sascha Hauer, Alexandre Belloni, kernel
In-Reply-To: <bac50abd-9c55-c9cb-7d10-24ef8efbdb53@microchip.com>
On 27/06/2017 09:41, Nicolas Ferre wrote:
> On 26/06/2017 at 11:07, Uwe Kleine-König wrote:
>> From: Sascha Hauer <s.hauer@pengutronix.de>
>>
>> We just got a common helper for parsing the rs485 specific
>> device tree properties. Use it and drop the open coded parser.
>>
>> Note that there is a small difference between the removed and the now
>> used implementation: The former cleared flags to 0 if rs485-rts-delay
>> was given, the common helper clears SER_RS485_RX_DURING_TX and
>> SER_RS485_ENABLED only but always which makes more sense.
>
> Sure:
> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
>
> Thanks Sasha and Uwe!
>
Acked-by: Richard Genoud <richard.genoud@gmail.com>
Thanks !
>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>> [ukleinek: point out semantic change in commit log]
>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>> ---
>> drivers/tty/serial/atmel_serial.c | 25 +------------------------
>> 1 file changed, 1 insertion(+), 24 deletions(-)
>>
>> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
>> index 937d67f22fba..245d9c227ad5 100644
>> --- a/drivers/tty/serial/atmel_serial.c
>> +++ b/drivers/tty/serial/atmel_serial.c
>> @@ -1684,29 +1684,6 @@ static void atmel_init_property(struct atmel_uart_port *atmel_port,
>> }
>> }
>>
>> -static void atmel_init_rs485(struct uart_port *port,
>> - struct platform_device *pdev)
>> -{
>> - struct device_node *np = pdev->dev.of_node;
>> -
>> - struct serial_rs485 *rs485conf = &port->rs485;
>> - u32 rs485_delay[2];
>> -
>> - /* rs485 properties */
>> - if (of_property_read_u32_array(np, "rs485-rts-delay",
>> - rs485_delay, 2) == 0) {
>> - rs485conf->delay_rts_before_send = rs485_delay[0];
>> - rs485conf->delay_rts_after_send = rs485_delay[1];
>> - rs485conf->flags = 0;
>> - }
>> -
>> - if (of_get_property(np, "rs485-rx-during-tx", NULL))
>> - rs485conf->flags |= SER_RS485_RX_DURING_TX;
>> -
>> - if (of_get_property(np, "linux,rs485-enabled-at-boot-time", NULL))
>> - rs485conf->flags |= SER_RS485_ENABLED;
>> -}
>> -
>> static void atmel_set_ops(struct uart_port *port)
>> {
>> struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>> @@ -2390,7 +2367,7 @@ static int atmel_init_port(struct atmel_uart_port *atmel_port,
>> atmel_init_property(atmel_port, pdev);
>> atmel_set_ops(port);
>>
>> - atmel_init_rs485(port, pdev);
>> + of_get_rs485_mode(pdev->dev.of_node, &port->rs485);
>>
>> port->iotype = UPIO_MEM;
>> port->flags = UPF_BOOT_AUTOCONF | UPF_IOREMAP;
>>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 9/9] of: document rs485 bindings for Atmel USART, Freescale UARTs and OMAP UART
From: Nicolas Ferre @ 2017-06-27 7:42 UTC (permalink / raw)
To: Uwe Kleine-König, linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <20170626090803.10981-10-u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 26/06/2017 at 11:08, Uwe Kleine-König wrote:
> The drivers support the rs485 binding described in rs485.txt, this commit
> just makes that explicit.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Acked-by: Nicolas Ferre <nicolas.ferre-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
> ---
> Documentation/devicetree/bindings/serial/atmel-usart.txt | 1 +
> Documentation/devicetree/bindings/serial/fsl-imx-uart.txt | 1 +
> Documentation/devicetree/bindings/serial/fsl-lpuart.txt | 1 +
> Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
> 4 files changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/atmel-usart.txt b/Documentation/devicetree/bindings/serial/atmel-usart.txt
> index e6e6142e33ac..7c0d6b2f53e4 100644
> --- a/Documentation/devicetree/bindings/serial/atmel-usart.txt
> +++ b/Documentation/devicetree/bindings/serial/atmel-usart.txt
> @@ -24,6 +24,7 @@ Optional properties:
> - dma-names: "rx" for RX channel, "tx" for TX channel.
> - atmel,fifo-size: maximum number of data the RX and TX FIFOs can store for FIFO
> capable USARTs.
> +- rs485-rts-delay, rs485-rx-during-tx, linux,rs485-enabled-at-boot-time: see rs485.txt
>
> <chip> compatible description:
> - at91rm9200: legacy USART support
> diff --git a/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt b/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt
> index 574c3a2c77d5..860a9559839a 100644
> --- a/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt
> +++ b/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt
> @@ -9,6 +9,7 @@ Optional properties:
> - fsl,irda-mode : Indicate the uart supports irda mode
> - fsl,dte-mode : Indicate the uart works in DTE mode. The uart works
> in DCE mode by default.
> +- rs485-rts-delay, rs485-rx-during-tx, linux,rs485-enabled-at-boot-time: see rs485.txt
>
> Please check Documentation/devicetree/bindings/serial/serial.txt
> for the complete list of generic properties.
> diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
> index c95005efbcb8..4eca15378584 100644
> --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
> +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
> @@ -14,6 +14,7 @@ Required properties:
> Optional properties:
> - dmas: A list of two dma specifiers, one for each entry in dma-names.
> - dma-names: should contain "tx" and "rx".
> +- rs485-rts-delay, rs485-rx-during-tx, linux,rs485-enabled-at-boot-time: see rs485.txt
>
> Note: Optional properties for DMA support. Write them both or both not.
>
> diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
> index 7a71b5de77d6..43eac675f21f 100644
> --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
> +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
> @@ -19,6 +19,7 @@ Optional properties:
> - dmas : DMA specifier, consisting of a phandle to the DMA controller
> node and a DMA channel number.
> - dma-names : "rx" for receive channel, "tx" for transmit channel.
> +- rs485-rts-delay, rs485-rx-during-tx, linux,rs485-enabled-at-boot-time: see rs485.txt
>
> Example:
>
>
--
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 4/9] serial: atmel: Use common rs485 device tree parsing function
From: Nicolas Ferre @ 2017-06-27 7:41 UTC (permalink / raw)
To: Uwe Kleine-König, linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Richard Genoud, devicetree-u79uwXL29TY76Z2rM5mHXA, Sascha Hauer,
Alexandre Belloni, kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <20170626090803.10981-5-u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 26/06/2017 at 11:07, Uwe Kleine-König wrote:
> From: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>
> We just got a common helper for parsing the rs485 specific
> device tree properties. Use it and drop the open coded parser.
>
> Note that there is a small difference between the removed and the now
> used implementation: The former cleared flags to 0 if rs485-rts-delay
> was given, the common helper clears SER_RS485_RX_DURING_TX and
> SER_RS485_ENABLED only but always which makes more sense.
Sure:
Acked-by: Nicolas Ferre <nicolas.ferre-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
Thanks Sasha and Uwe!
> Signed-off-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> [ukleinek: point out semantic change in commit log]
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> ---
> drivers/tty/serial/atmel_serial.c | 25 +------------------------
> 1 file changed, 1 insertion(+), 24 deletions(-)
>
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index 937d67f22fba..245d9c227ad5 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -1684,29 +1684,6 @@ static void atmel_init_property(struct atmel_uart_port *atmel_port,
> }
> }
>
> -static void atmel_init_rs485(struct uart_port *port,
> - struct platform_device *pdev)
> -{
> - struct device_node *np = pdev->dev.of_node;
> -
> - struct serial_rs485 *rs485conf = &port->rs485;
> - u32 rs485_delay[2];
> -
> - /* rs485 properties */
> - if (of_property_read_u32_array(np, "rs485-rts-delay",
> - rs485_delay, 2) == 0) {
> - rs485conf->delay_rts_before_send = rs485_delay[0];
> - rs485conf->delay_rts_after_send = rs485_delay[1];
> - rs485conf->flags = 0;
> - }
> -
> - if (of_get_property(np, "rs485-rx-during-tx", NULL))
> - rs485conf->flags |= SER_RS485_RX_DURING_TX;
> -
> - if (of_get_property(np, "linux,rs485-enabled-at-boot-time", NULL))
> - rs485conf->flags |= SER_RS485_ENABLED;
> -}
> -
> static void atmel_set_ops(struct uart_port *port)
> {
> struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
> @@ -2390,7 +2367,7 @@ static int atmel_init_port(struct atmel_uart_port *atmel_port,
> atmel_init_property(atmel_port, pdev);
> atmel_set_ops(port);
>
> - atmel_init_rs485(port, pdev);
> + of_get_rs485_mode(pdev->dev.of_node, &port->rs485);
>
> port->iotype = UPIO_MEM;
> port->flags = UPF_BOOT_AUTOCONF | UPF_IOREMAP;
>
--
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 3/9] serial: Add common rs485 device tree parsing function
From: Nicolas Ferre @ 2017-06-27 7:40 UTC (permalink / raw)
To: Uwe Kleine-König, linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Sascha Hauer, devicetree-u79uwXL29TY76Z2rM5mHXA,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <20170626090803.10981-4-u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 26/06/2017 at 11:07, Uwe Kleine-König wrote:
> From: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>
> Several drivers have the same device tree parsing code. Create
> a common helper function for it.
>
> Signed-off-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> [ukl: implement default <0 0> for rts-delay, unset unspecified flags]
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Acked-by: Nicolas Ferre <nicolas.ferre-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
> ---
> drivers/tty/serial/Kconfig | 4 ++++
> drivers/tty/serial/Makefile | 2 ++
> drivers/tty/serial/of.c | 47 +++++++++++++++++++++++++++++++++++++++++++++
> include/linux/serial_core.h | 13 +++++++++++++
> 4 files changed, 66 insertions(+)
> create mode 100644 drivers/tty/serial/of.c
>
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 5c8850f7a2a0..8baef5b95bed 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -14,6 +14,10 @@ config SERIAL_EARLYCON
> the console before standard serial driver is probed. The console is
> enabled when early_param is processed.
>
> +config OF_SERIAL
> + depends on SERIAL_CORE
> + def_bool y
> +
> source "drivers/tty/serial/8250/Kconfig"
>
> comment "Non-8250 serial port support"
> diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
> index 53c03e005132..0fee8f4e36cb 100644
> --- a/drivers/tty/serial/Makefile
> +++ b/drivers/tty/serial/Makefile
> @@ -7,6 +7,8 @@ obj-$(CONFIG_SERIAL_CORE) += serial_core.o
> obj-$(CONFIG_SERIAL_EARLYCON) += earlycon.o
> obj-$(CONFIG_SERIAL_EARLYCON_ARM_SEMIHOST) += earlycon-arm-semihost.o
>
> +obj-$(CONFIG_OF_SERIAL) += of.o
> +
> # These Sparc drivers have to appear before others such as 8250
> # which share ttySx minor node space. Otherwise console device
> # names change and other unplesantries.
> diff --git a/drivers/tty/serial/of.c b/drivers/tty/serial/of.c
> new file mode 100644
> index 000000000000..b24e4357661b
> --- /dev/null
> +++ b/drivers/tty/serial/of.c
> @@ -0,0 +1,47 @@
> +#include <linux/kernel.h>
> +#include <linux/export.h>
> +#include <linux/of.h>
> +#include <linux/serial_core.h>
> +
> +/**
> + * of_get_rs485_mode() - Implement parsing rs485 properties
> + * @np: uart node
> + * @rs485conf: output parameter
> + *
> + * This function implements the device tree binding described in
> + * Documentation/devicetree/bindings/serial/rs485.txt.
> + *
> + * Return: 0 on success, 1 if the node doesn't contain rs485 stuff.
> + */
> +int of_get_rs485_mode(struct device_node *np, struct serial_rs485 *rs485conf)
> +{
> + u32 rs485_delay[2];
> + int ret;
> +
> + if (!IS_ENABLED(CONFIG_OF) || !np)
> + return 1;
> +
> + ret = of_property_read_u32_array(np, "rs485-rts-delay" rs485_delay, 2);
> + if (!ret) {
> + rs485conf->delay_rts_before_send = rs485_delay[0];
> + rs485conf->delay_rts_after_send = rs485_delay[1];
> + } else {
> + rs485conf->delay_rts_before_send = 0;
> + rs485conf->delay_rts_after_send = 0;
> + }
> +
> + /*
> + * clear full-duplex and enabled flags to get to a defined state with
> + * the two following properties.
> + */
> + rs485conf->flags &= ~(SER_RS485_RX_DURING_TX | SER_RS485_ENABLED);
> +
> + if (of_property_read_bool(np, "rs485-rx-during-tx"))
> + rs485conf->flags |= SER_RS485_RX_DURING_TX;
> +
> + if (of_property_read_bool(np, "linux,rs485-enabled-at-boot-time"))
> + rs485conf->flags |= SER_RS485_ENABLED;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_get_rs485_mode);
> diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
> index 64d892f1e5cd..5ba00b1be093 100644
> --- a/include/linux/serial_core.h
> +++ b/include/linux/serial_core.h
> @@ -500,4 +500,17 @@ static inline int uart_handle_break(struct uart_port *port)
> (cflag) & CRTSCTS || \
> !((cflag) & CLOCAL))
>
> +/*
> + * Common device tree parsing helpers
> + */
> +#ifdef CONFIG_OF_SERIAL
> +int of_get_rs485_mode(struct device_node *np, struct serial_rs485 *rs485conf);
> +#else
> +static inline int of_get_rs485_mode(struct device_node *np,
> + struct serial_rs485 *rs485conf)
> +{
> + return 1;
> +}
> +#endif
> +
> #endif /* LINUX_SERIAL_CORE_H */
>
--
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 5/6] tty: serial: Add RDA Micro UART driver
From: Andreas Färber @ 2017-06-27 0:55 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, service, zhao_steven, Andreas Färber,
Jonathan Corbet, Greg Kroah-Hartman, Jiri Slaby, linux-doc,
linux-serial
In-Reply-To: <20170627005520.23731-1-afaerber@suse.de>
Add "rda" earlycon driver for RDA8810PL UART.
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
Documentation/admin-guide/kernel-parameters.txt | 6 ++
drivers/tty/serial/Kconfig | 19 ++++
drivers/tty/serial/Makefile | 1 +
drivers/tty/serial/rda-uart.c | 117 ++++++++++++++++++++++++
4 files changed, 143 insertions(+)
create mode 100644 drivers/tty/serial/rda-uart.c
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 0e2091c6fa6b..c97f8b64b3f1 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -967,6 +967,12 @@
specified address. The serial port must already be
setup and configured. Options are not yet supported.
+ rda,<addr>
+ Start an early, polled-mode console on a serial port
+ of an RDA Micro SoC, such as RDA8810PL, at the
+ specified address. The serial port must already be
+ setup and configured. Options are not yet supported.
+
smh Use ARM semihosting calls for early console.
s3c2410,<addr>
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 1f096e2bb398..25e106a62e06 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1707,6 +1707,25 @@ config SERIAL_OWL_CONSOLE
Say 'Y' here if you wish to use Actions Semiconductor S500/S900 UART
as the system console. Only earlycon is implemented currently.
+config SERIAL_RDA
+ bool "RDA Micro serial port support"
+ depends on ARCH_RDA || COMPILE_TEST
+ select SERIAL_CORE
+ help
+ This driver is for RDA8810PL SoC's UART.
+ Say 'Y' here if you wish to use the on-board serial port.
+ Otherwise, say 'N'.
+
+config SERIAL_RDA_CONSOLE
+ bool "Console on RDA Micro serial port"
+ depends on SERIAL_RDA=y
+ select SERIAL_CORE_CONSOLE
+ select SERIAL_EARLYCON
+ default y
+ help
+ Say 'Y' here if you wish to use the RDA8810PL UART as the system
+ console. Only earlycon is implemented currently.
+
endmenu
config SERIAL_MCTRL_GPIO
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index fe88a75d9a59..87f5a6e1e2d4 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -93,6 +93,7 @@ obj-$(CONFIG_SERIAL_MVEBU_UART) += mvebu-uart.o
obj-$(CONFIG_SERIAL_PIC32) += pic32_uart.o
obj-$(CONFIG_SERIAL_MPS2_UART) += mps2-uart.o
obj-$(CONFIG_SERIAL_OWL) += owl-uart.o
+obj-$(CONFIG_SERIAL_RDA) += rda-uart.o
# GPIOLIB helpers for modem control lines
obj-$(CONFIG_SERIAL_MCTRL_GPIO) += serial_mctrl_gpio.o
diff --git a/drivers/tty/serial/rda-uart.c b/drivers/tty/serial/rda-uart.c
new file mode 100644
index 000000000000..c3c9cf1df015
--- /dev/null
+++ b/drivers/tty/serial/rda-uart.c
@@ -0,0 +1,117 @@
+/*
+ * RDA8810PL serial console
+ *
+ * Copyright RDA Microelectronics Company Limited
+ * Copyright (c) 2017 Andreas Färber
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/console.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/serial.h>
+#include <linux/serial_core.h>
+
+#define RDA_UART_CTRL 0x00
+#define RDA_UART_STATUS 0x04
+#define RDA_UART_RXTX_BUFFER 0x08
+#define RDA_UART_IRQ_MASK 0x0c
+
+#define RDA_UART_STATUS_TX_FIFO_SPACE_MASK (0x1f << 8)
+
+static inline void rda_uart_write(struct uart_port *port, u32 val, unsigned int off)
+{
+ writel(val, port->membase + off);
+}
+
+static inline u32 rda_uart_read(struct uart_port *port, unsigned int off)
+{
+ return readl(port->membase + off);
+}
+
+#ifdef CONFIG_SERIAL_RDA_CONSOLE
+
+static void rda_console_putchar(struct uart_port *port, int ch)
+{
+ if (!port->membase)
+ return;
+
+ while (!(rda_uart_read(port, RDA_UART_STATUS) & RDA_UART_STATUS_TX_FIFO_SPACE_MASK))
+ cpu_relax();
+
+ rda_uart_write(port, ch, RDA_UART_RXTX_BUFFER);
+}
+
+static void rda_uart_port_write(struct uart_port *port, const char *s,
+ u_int count)
+{
+ u32 old_irq_mask;
+ unsigned long flags;
+ int locked;
+
+ local_irq_save(flags);
+
+ if (port->sysrq)
+ locked = 0;
+ else if (oops_in_progress)
+ locked = spin_trylock(&port->lock);
+ else {
+ spin_lock(&port->lock);
+ locked = 1;
+ }
+
+ old_irq_mask = rda_uart_read(port, RDA_UART_IRQ_MASK);
+ rda_uart_write(port, 0, RDA_UART_IRQ_MASK);
+
+ uart_console_write(port, s, count, rda_console_putchar);
+
+ /* wait until all contents have been sent out */
+ while (!(rda_uart_read(port, RDA_UART_STATUS) & RDA_UART_STATUS_TX_FIFO_SPACE_MASK))
+ cpu_relax();
+
+ rda_uart_write(port, old_irq_mask, RDA_UART_IRQ_MASK);
+
+ if (locked)
+ spin_unlock(&port->lock);
+
+ local_irq_restore(flags);
+}
+
+static void rda_uart_early_console_write(struct console *co,
+ const char *s,
+ u_int count)
+{
+ struct earlycon_device *dev = co->data;
+
+ rda_uart_port_write(&dev->port, s, count);
+}
+
+static int __init
+rda_uart_early_console_setup(struct earlycon_device *device, const char *opt)
+{
+ if (!device->port.membase)
+ return -ENODEV;
+
+ device->con->write = rda_uart_early_console_write;
+
+ return 0;
+}
+OF_EARLYCON_DECLARE(rda, "rda,8810pl-uart",
+ rda_uart_early_console_setup);
+
+#endif /* CONFIG_SERIAL_RDA_CONSOLE */
--
2.12.3
^ permalink raw reply related
* [PATCH 4/6] dt-bindings: serial: Document RDA Micro UART
From: Andreas Färber @ 2017-06-27 0:55 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, service, zhao_steven, Andreas Färber,
Greg Kroah-Hartman, Rob Herring, Mark Rutland, linux-serial,
devicetree
In-Reply-To: <20170627005520.23731-1-afaerber@suse.de>
Add an initial binding for the RDA8810PL UART.
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
Documentation/devicetree/bindings/serial/rda-uart.txt | 13 +++++++++++++
1 file changed, 13 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/rda-uart.txt
diff --git a/Documentation/devicetree/bindings/serial/rda-uart.txt b/Documentation/devicetree/bindings/serial/rda-uart.txt
new file mode 100644
index 000000000000..6840a8aee035
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/rda-uart.txt
@@ -0,0 +1,13 @@
+RDA Micro UART
+
+Required properties:
+- compatible : "rda,8810pl-uart" for RDA8810PL
+- reg : Offset and length of the register set for the device.
+
+
+Example:
+
+ uart3: serial@20a90000 {
+ compatible = "rda,8810pl-uart";
+ reg = <0x20a90000 0x1000>;
+ };
--
2.12.3
^ permalink raw reply related
* Re: [PATCH 02/11] dma-mapping: replace dmam_alloc_noncoherent with dmam_alloc_attrs
From: Tejun Heo @ 2017-06-26 20:53 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-fbdev, linux-scsi, netdev, alsa-devel, Christoph Hellwig,
linux-serial, nios2-dev, linux-metag, linux-kernel
In-Reply-To: <20170626070730.GB12711@infradead.org>
On Mon, Jun 26, 2017 at 12:07:30AM -0700, Christoph Hellwig wrote:
> Tejun, does this look ok to you?
Acked-by: Tejun Heo <tj@kernel.org>
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 01/11] dma-mapping: remove dmam_free_noncoherent
From: Tejun Heo @ 2017-06-26 20:53 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Christoph Hellwig, linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-metag-u79uwXL29TY76Z2rM5mHXA,
nios2-dev-g9ZBwUv/Ih/yUk5EbOjzuce+I+R0W71w,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170626070715.GA12711-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
On Mon, Jun 26, 2017 at 12:07:15AM -0700, Christoph Hellwig wrote:
> Tejun, does this look ok to you?
Sure,
Acked-by: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 07/11] 53c700: switch to dma_alloc_attrs
From: Martin K. Petersen @ 2017-06-26 18:21 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-scsi, linux-serial, netdev, linux-metag, nios2-dev,
linux-fbdev, alsa-devel, linux-kernel
In-Reply-To: <20170616071716.17321-8-hch@lst.de>
Christoph,
> Use dma_alloc_attrs directly instead of the dma_alloc_noncoherent
> wrapper.
Applied to 4.13/scsi-queue.
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: [PATCH 06/11] sigwd93: switch to dma_alloc_attrs
From: Martin K. Petersen @ 2017-06-26 18:20 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-metag-u79uwXL29TY76Z2rM5mHXA,
nios2-dev-g9ZBwUv/Ih/yUk5EbOjzuce+I+R0W71w,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170616071716.17321-7-hch-jcswGhMUV9g@public.gmane.org>
Christoph,
> Use dma_alloc_attrs directly instead of the dma_alloc_noncoherent
> wrapper.
Fixed driver name typo and applied to 4.13/scsi-queue.
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* RE: [PATCH 00/20] Update STM32 usart driver
From: Bich HEMON @ 2017-06-26 15:50 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre TORGUE, Jiri Slaby,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2270 bytes --]
Dear all,
Please, do not take into account this patchset. A newer version is currently being prepared with typo/format corrections and will be sent later. The previous version has to be abandoned.
Sorry for the inconvenience,
Bich HEMON
-----Original Message-----
From: Bich HEMON
Sent: lundi 26 juin 2017 14:49
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>; Rob Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; Maxime Coquelin <mcoquelin.stm32@gmail.com>; Alexandre TORGUE <alexandre.torgue@st.com>; Jiri Slaby <jslaby@suse.com>; linux-serial@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org
Cc: Bich HEMON <bich.hemon@st.com>
Subject: [PATCH 00/20] Update STM32 usart driver
From: Bich Hemon <bich.hemon@st.com>
This patchset updates the stm32 usart driver. It mainly adds support for fifo, dma, debugfs anf fixes various bugs.
Bich Hemon (20):
serial: stm32: adding fifo support
dt-bindings: serial: each stm32 usart needs an alias
serial: stm32: fix multi ports management
serial: stm32: make fifoen as property for each port
serial: stm32: add debugfs
serial: stm32: fix pio transmit timeout
serial: stm32: less messages on dma alloc error
serial: stm32: timeout interrupt using with dma
serial: stm32: fix end of transfer
serial: stm32: fix dma receive
serial: stm32: add RTS support
serial: stm32: fix last_res value
serial: stm32: fix error handling in probe
dt-bindings: serial: document option wake-up interrupt for STM32 USART
serial: stm32: Add wakeup mechanism
serial: stm32: fix fifo usage
dt-bindings: serial: stm32: add dma using note
serial: stm32: update dma buffers length
serial: stm32: add dma rx callback
serial: stm32: fix rx interrupt handling in startup
.../devicetree/bindings/serial/st,stm32-usart.txt | 55 +++-
drivers/tty/serial/stm32-usart.c | 310 ++++++++++++++++++---
drivers/tty/serial/stm32-usart.h | 51 +++-
3 files changed, 375 insertions(+), 41 deletions(-)
--
1.9.1
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·zøœzÚÞz)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢j.ïÛ°\½½MŽúgjÌæa×\x02››–' ™©Þ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾\a«‘êçzZ+ƒùšŽŠÝ¢j"ú!¶i
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox