Using serial devices under linux

NeilBrown | 1 May 2012 01:35

Picon

Re: Question: How to power-manage UART-attached devices.

On Mon, 30 Apr 2012 23:33:22 +0100 Mark Brown
<broonie <at> opensource.wolfsonmicro.com> wrote:

> On Tue, May 01, 2012 at 08:22:09AM +1000, NeilBrown wrote:
> 
> >  The question is how can user-space tell the kernel that these devices are
> >  'inactive'?
> 
> >  I would like to integrate this into Linux in the most  "natural" way that I
> >  can but am having trouble.  My current approach involves using "rfkill" but
> >  that doesn't work very well for reasons that are probably not very relevant
> >  here.  It probably does make sense for powering the GPS antenna, but not
> >  much else.
> 
> The userspace consumer was added for users like this that live entirely
> in userspace.

Hi Mark,
 thanks for the reply.

 I assume you mean REGULATOR_VIRTUAL_CONSUMER (drivers/regulator/virtual.c)?

 The one where the Kconfig entry says:
    This is mainly useful for test purposes.

 That certainly was useful for test purposes but I want to move beyond
 testing.

 One of the purposes of an operating system is to provide useful abstractions
 and hide irrelevant details, so I don't want user-space to have to

(Continue reading)

NeilBrown | 1 May 2012 01:47

Picon

Re: Question: How to power-manage UART-attached devices.

On Mon, 30 Apr 2012 15:51:59 -0700 "H. Peter Anvin" <hpa <at> zytor.com> wrote:

> On 04/30/2012 03:22 PM, NeilBrown wrote:
> > 
> > What I would really like is to integrate it closely with the state
> > of the UART.  i.e. if the /dev/ttyO1 device is open, then the GPS
> > is "on".  If not then it is "off".  Similarly if /dev/tty/O0 is
> > open, bluetooth is "on", else "off". However I cannot find any way
> > to "plug in" to the tty or serial drivers to perform an arbitrary
> > action on first-open or last-close.  Is something like that
> > possible? If not, is it a reasonable thing to ask? Any suggests
> > about where to put such a hook?
> > 
> 
> I don't think that's the right interface.  Just because the port is
> currently open doesn't mean the device is active, nor vice versa.  ALL
> it means is that someone currently has an access handle to it.
> 
> Since a serial port models, well, a *port*, it is logical to think of
> a (hypothetical) socket containing an RS-232 connector as well as a
> power outlet.  Given that, it would be logical to drive the "power
> connector" using the same type of interface used for the other parts
> of an RS-232 control, meaning either with termios flags or via a
> dedicated control ioctl (TIOCPOWER?).
> 
> 	-hpa

Hi Peter,

 I agree that in general there is not necessarily a 1-1 correspondence between

(Continue reading)

H. Peter Anvin | 1 May 2012 01:50

Re: Question: How to power-manage UART-attached devices.

On 04/30/2012 04:47 PM, NeilBrown wrote:
> 
> I imagine this proposal as being like a virtual DTR line.  It may
> not always be appropriate to connect DTR to the power switch, but
> sometimes it is.
> 

Yeah, that's pretty much what I'm suggesting.

	-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

NeilBrown | 1 May 2012 02:12

Picon

Re: Question: How to power-manage UART-attached devices.

On Tue, 1 May 2012 00:34:20 +0100 Alan Cox <alan <at> lxorguk.ukuu.org.uk> wrote:

> On Mon, 30 Apr 2012 15:51:59 -0700
> "H. Peter Anvin" <hpa <at> zytor.com> wrote:
> 
> > On 04/30/2012 03:22 PM, NeilBrown wrote:
> > > 
> > > What I would really like is to integrate it closely with the state
> > > of the UART.  i.e. if the /dev/ttyO1 device is open, then the GPS
> > > is "on".  If not then it is "off".  Similarly if /dev/tty/O0 is
> > > open, bluetooth is "on", else "off". However I cannot find any way
> > > to "plug in" to the tty or serial drivers to perform an arbitrary
> > > action on first-open or last-close.  Is something like that
> > > possible? If not, is it a reasonable thing to ask? Any suggests
> > > about where to put such a hook?
> > > 
> > 
> > I don't think that's the right interface.  Just because the port is
> > currently open doesn't mean the device is active, nor vice versa.  ALL
> > it means is that someone currently has an access handle to it.
> > 
> > Since a serial port models, well, a *port*, it is logical to think of
> > a (hypothetical) socket containing an RS-232 connector as well as a
> > power outlet.  Given that, it would be logical to drive the "power
> > connector" using the same type of interface used for the other parts
> > of an RS-232 control, meaning either with termios flags or via a
> > dedicated control ioctl (TIOCPOWER?).
> 
> Actually several of our virtual tty interfaces treat open as meaning
> powered up. It's a fairly logical power management model. A lot of our

(Continue reading)

NeilBrown | 1 May 2012 02:27

Picon

Re: Question: How to power-manage UART-attached devices.

On Mon, 30 Apr 2012 16:50:16 -0700 "H. Peter Anvin" <hpa <at> zytor.com> wrote:

> On 04/30/2012 04:47 PM, NeilBrown wrote:
> > 
> > I imagine this proposal as being like a virtual DTR line.  It may
> > not always be appropriate to connect DTR to the power switch, but
> > sometimes it is.
> > 
> 
> Yeah, that's pretty much what I'm suggesting.
> 
> 	-hpa

Yes, so you are 

I was distracted by the TIOCPOWER suggestion, and I really didn't want any
new action by user-space, I would much prefer it all "just works".
But you also mentioned "termios flags" but by that I suspect you are
referring to HUPCL which is documented as:

       HUPCL  Lower modem control lines after last process closes  the  device
              (hang up).

without really saying which modem control lines.  Looking at the code it
seems to be talking about DTR and RTS.  It only says "lower on last close"
but doesn't say "raise on first open" but maybe that is assumed.
So as long as HUPCL is the default, defining a virtual DTR line might be just
what I want, and HUPCL could be disabled of someone want to keep the device
powered on while it is closed.

(Continue reading)

Preston Fick | 1 May 2012 06:06

Picon

[PATCH 1/3] usb: cp210x: Corrected USB request type definitions

The original request types in the cp210x driver are labled as "DEVICE_TO_HOST" and
"HOST_TO_DEVICE" but the actual bit definition corresponds to a request to the
interface. This has been corrected, and the actual definition for the device
requests have been added.

Signed-off-by: Preston Fick <preston.fick <at> silabs.com>
---
 drivers/usb/serial/cp210x.c |   12 +++++++-----
 1 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index ec30f95..e67ccf3 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
 <at>  <at>  -188,8 +188,10  <at>  <at>  static struct usb_serial_driver * const serial_drivers[] = {
 };

 /* Config request types */
-#define REQTYPE_HOST_TO_DEVICE	0x41
-#define REQTYPE_DEVICE_TO_HOST	0xc1
+#define REQTYPE_HOST_TO_INTERFACE	0x41
+#define REQTYPE_INTERFACE_TO_HOST	0xc1
+#define REQTYPE_HOST_TO_DEVICE	0x40
+#define REQTYPE_DEVICE_TO_HOST	0xc0

 /* Config request codes */
 #define CP210X_IFC_ENABLE	0x00
 <at>  <at>  -286,7 +288,7  <at>  <at>  static int cp210x_get_config(struct usb_serial_port *port, u8 request,

 	/* Issue the request, attempting to read 'size' bytes */

(Continue reading)

Ivo Sieben | 1 May 2012 16:30

Picon

Re: Deterministic behavior for TTY serial

Hello,

2012/4/26 Ivo Sieben <meltedpianoman <at> gmail.com>:
>
> I did some analyses using the ftrace 'function_graph' tracer to find
> out what causes the TTY read to take longer than expected.
> I use a test application, running on RT prioirty 99 that writes bursts
> of 24 Bytes data to a my TTY device. A loop back connector is used, so
> the application also reads back these 24 bytes. Non blocking reads &
> writes are used.
>
> This analyses is still ongoing...
> Regards,
> Ivo Sieben

I've proceeded with my analyses, and I think I've found one cause for
the non deterministic read behavior ...
(there is also an issue with the flip buffer read handling, but I'm
still investigating that)

On line 47 of tty_ldisc.c a Spin Lock is defined that guards the line
discipline administration.
It protects two reference counters:
"users", atomic counter in the tty_ldisc struct, that holds the number
of active users of the ldisc in each tty instance. Used for "idle"
handling.
"refcount", counter in the tty_ldisc_ops struct, that holds the number
of lines using the discipline. (when the user count of a line reaches
0, the refcount of the line discipline is decreased by one) Only when
the refcount is 0, it is allowed to unregister the line discipline.

(Continue reading)

Alan Cox | 1 May 2012 17:04

Face

Picon

Re: Deterministic behavior for TTY serial

> This Spin Lock is defined globally, This causes that my high priority
> process to get blocked because of a lower priority process that holds
> this spin lock. Of course you get priority inheritance, but this adds
> quite a lot of extra execution time to the read function (because of
> additional spin lock behavior, and scheduling to the lower priority
> process)

It's a spin lock and its only held across very small numbers of
instructions in any normal path so this rather surprises me - in your
actual capture data can you see what is holding the lock for long times
causing this ?

> Since the "user" and "refcount" reference counters have combined
> behavior (refcount is decremented when users reaches zero), I don't
> see a way to remove this global lock. Any ideas how this can be
> improved?

I've never really thought about it because it should never be contended
in any meaningful way.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Sergei Shtylyov | 1 May 2012 18:16

Re: [PATCH 2/3] usb: cp210x: Added in support to get and store part number

Hello.

On 01-05-2012 8:06, Preston Fick wrote:

> This change gets the part number of the device when the driver is loaded and
> stores it in the private portion of the port structure. This addition will
> allow for part specific functionality to be added to the driver if needed.

> Signed-off-by: Preston Fick<preston.fick <at> silabs.com>
> ---
>   drivers/usb/serial/cp210x.c |   24 ++++++++++++++++++++++++
>   1 files changed, 24 insertions(+), 0 deletions(-)

> diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
> index e67ccf3..b3646b8 100644
> --- a/drivers/usb/serial/cp210x.c
> +++ b/drivers/usb/serial/cp210x.c
[...]
>  <at>  <at>  -862,6 +874,7  <at>  <at>  static int cp210x_startup(struct usb_serial *serial)
>   {
>   	struct cp210x_port_private *port_priv;
>   	int i;
> +	unsigned int partNum;
>
>   	/* cp210x buffers behave strangely unless device is reset */
>   	usb_reset_device(serial->dev);
>  <at>  <at>  -876,6 +889,17  <at>  <at>  static int cp210x_startup(struct usb_serial *serial)
>   		    serial->interface->cur_altsetting->desc.bInterfaceNumber;
>
>   		usb_set_serial_port_data(serial->port[i], port_priv);

(Continue reading)

Huang Shijie | 2 May 2012 10:19

[PATCH] serial/imx: enable the clock when we really use the uart port

The current code keeps the clock enabled even when we do not really
use the uart port. But keep the clock enabled will consume some power.

In order to save more power, disable the clock when we do not use
the uart, and enable the clock when we really use the uart port.

Signed-off-by: Huang Shijie <b32955 <at> freescale.com>
---
 drivers/tty/serial/imx.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index e7fecee..f5dcdf6 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
 <at>  <at>  -694,6 +694,8  <at>  <at>  static int imx_startup(struct uart_port *port)
 	int retval;
 	unsigned long flags, temp;

+	clk_prepare_enable(sport->clk);
+
 	imx_setup_ufcr(sport, 0);

 	/* disable the DREN bit (Data Ready interrupt enable) before
 <at>  <at>  -877,6 +879,8  <at>  <at>  static void imx_shutdown(struct uart_port *port)
 		temp &= ~(UCR1_IREN);

 	writel(temp, sport->port.membase + UCR1);
+
+	clk_disable_unprepare(sport->clk);

(Continue reading)

Group

gmane.linux.serial.

Search Archive

Page

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 18

Articles in period: 176

May 2012

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

[PATCH 1/1] serial: vt8500: Remove redundant use of of_match_ptr macro (22 May 2013)
[PATCH] tty: mxser: fix usage of opmode_ioaddr (21 May 2013)
[PATCH] serial: 8250_dw: add ACPI ID for Intel BayTrail (21 May 2013)
[PATCH v2] serial: sccnxp: Improve verify_port (14 May 2013)
[PATCH] serial: sccnxp: Improve verify_port (14 May 2013)
[PATCH v2] serial: imx: Add Rx Fifo overrun error message (14 May 2013)
Investment Placement (6 May 2013)
Investment Placement (3 May 2013)
6 (11 May 2013)
[PATCH] serial: pl011: protect attribute read from NULL platform data (9 May 2013)
[PATCH] serial: 8250_dw: set clock rate (9 May 2013)
3 (9 May 2013)
dringender Vorschlag (8 May 2013)
[PATCH] serial: 8250_dw: Add valid clk pointer check (7 May 2013)
[PATCH 15/15] serial: pxa: remove unnecessary platform_set_drvdata() (7 May 2013)
[PATCH 14/15] serial: vt8500: remove unnecessary platform_set_drvdata( (7 May 2013)
[PATCH 13/15] serial: sirfsoc: remove unnecessary platform_set_drvdata (7 May 2013)
[PATCH 12/15] serial: sccnxp: remove unnecessary platform_set_drvdata( (7 May 2013)
[PATCH 11/15] serial: sa1100: remove unnecessary platform_set_drvdata( (7 May 2013)
[PATCH 10/15] serial: pnx8xxx: remove unnecessary platform_set_drvdata (7 May 2013)
[PATCH 09/15] serial: pmac_zilog: remove unnecessary platform_set_drvd (7 May 2013)

Archives

118	May 2013
182	April 2013
261	March 2013
184	February 2013
221	January 2013
139	December 2012
258	November 2012
215	October 2012
289	September 2012
177	August 2012
121	July 2012
131	June 2012
176	May 2012
115	April 2012
181	March 2012
150	February 2012
151	January 2012
115	December 2011
143	November 2011
219	October 2011
98	September 2011
136	August 2011
90	July 2011
147	June 2011
151	May 2011
98	April 2011
148	March 2011
84	February 2011
66	January 2011
53	December 2010
109	November 2010
93	October 2010
124	September 2010
67	August 2010
39	July 2010
26	June 2010
80	May 2010
25	April 2010
133	March 2010
99	February 2010
49	January 2010
10	December 2009
33	November 2009
28	October 2009
65	September 2009
34	August 2009
52	July 2009
47	June 2009
28	May 2009
2	April 2009
67	March 2009
19	February 2009
164	January 2009
45	December 2008
87	November 2008
129	October 2008
60	September 2008
63	August 2008
56	July 2008
33	June 2008
44	May 2008
57	April 2008
31	March 2008
30	February 2008
70	January 2008
18	December 2007
30	November 2007
67	October 2007
26	September 2007
77	August 2007
91	July 2007
14	June 2007
29	May 2007
51	April 2007
54	March 2007
59	February 2007
30	January 2007
30	December 2006
16	November 2006
36	October 2006
18	September 2006
84	August 2006
15	July 2006
48	June 2006
30	May 2006
17	April 2006
39	March 2006
4	February 2006
28	January 2006
15	December 2005
23	November 2005
25	October 2005
4	September 2005
12	August 2005
24	July 2005
24	June 2005
37	May 2005
19	April 2005
32	March 2005
38	February 2005
2	January 2005
1	December 2004
11	November 2004
12	October 2004
13	September 2004
29	August 2004
35	July 2004
5	June 2004
6	May 2004
5	April 2004
22	March 2004
16	February 2004
11	January 2004
50	December 2003
22	November 2003
10	October 2003
8	September 2003
20	August 2003
8	July 2003
1	June 2003
8	May 2003
15	April 2003
53	March 2003
31	February 2003
12	January 2003
4	December 2002
1	November 2002
17	October 2002
16	September 2002
19	August 2002
26	July 2002
15	June 2002
13	May 2002
12	April 2002

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template