devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
To: NeilBrown <neilb@suse.de>
Cc: balbi@ti.com, Nishanth Menon <nm@ti.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	marcel@holtmann.org, gustavo@padovan.org,
	johan.hedberg@gmail.com, jslaby@suse.cz, grant.likely@linaro.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-bluetooth@vger.kernel.org, linux-serial@vger.kernel.org,
	devicetree@vger.kernel.org,
	Linux OMAP Mailing List <linux-omap@vger.kernel.org>,
	Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH 10/13] tty: serial: omap: remove some dead code
Date: Fri, 25 Apr 2014 12:47:57 +0100	[thread overview]
Message-ID: <20140425124757.3f2069b2@alan.etchedpixels.co.uk> (raw)
In-Reply-To: <20140425193412.7d32e429@notabene.brown>

> I had a quick look and I guess that uart_change_pm() is the most likely
> candidate for what you are referring to.
> I can see how that interfaces to the specific piece of uart hardware, such as
> omap-serial.c
> But I cannot see how you would plumb that though to the device that was
> plugged in to the serial port.  I guess if that device could be registered as
> a child of the omap_serial device, then power management inheritance might
> come in to play, but I cannot see any way to tell a serial port that it has
> some arbitrary child device.

If your device is powered by something like a regulator then you can
drive the regulator from the uart_pm helpers.

> In one case the "power on" sequence is substantially more complex that just a
> gpio or regulator.  I would need to write a device driver for the (GPS) chip
> which could receive a poweron/poweroff signal from the uart and do the
> required magic.

In which case giving the tty a child device (or devices) would probably
be more sensible yes. No problem with that either.

> I would really like to see the "runtime interpreted power sequences" become a
> real thing.  Then serial-core could activate a "RIPS", and that would have
> the flexibility to do whatever is needed without adding complexity to
> serial-core.

Something like ACPI has you mean ? When we put the device into D0 the
ACPI methods can do stuff.

> So ... with your "serial" hat on, if I were to write/test a patch to allow
> any serial port to have a "power-gpio" described in DT and the gpio would be
> driven in uart_change_pm(), would you consider accepting that patch, or did I
> misunderstand?

We are going to need it anyway for other devices fairly soon. It's common
for new PC class hardware to have gpio management for the bluetooth,
gps and and sometimes sensor devices attached to the tty. That's true
irrespective of whether you happen to choose to use it for virtual gpio
hacks.

Alan

  parent reply	other threads:[~2014-04-25 11:47 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-23 14:58 [PATCH 01/13] tty_ldisc: add more limits to the @write_wakeup Felipe Balbi
2014-04-23 14:58 ` [PATCH 02/13] bluetooth: hci_ldisc: fix deadlock condition Felipe Balbi
2014-04-24  9:01   ` Andreas Bießmann
2014-04-23 14:58 ` [PATCH 03/13] Revert "serial: omap: unlock the port lock" Felipe Balbi
2014-04-23 14:58 ` [PATCH 04/13] serial: fix UART_IIR_ID Felipe Balbi
2014-04-23 14:58 ` [PATCH 05/13] tty: serial: add missing braces Felipe Balbi
2014-04-23 14:58 ` [PATCH 06/13] tty: serial: omap: switch over to devm_request_gpio Felipe Balbi
2014-04-23 14:58 ` [PATCH 07/13] tty: serial: omap: cleanup variable declarations Felipe Balbi
2014-04-23 14:58 ` [PATCH 08/13] tty: serial: omap: switch over to platform_get_resource Felipe Balbi
     [not found]   ` <1398265117-11793-8-git-send-email-balbi-l0cyMroinI0@public.gmane.org>
2014-04-23 15:27     ` Fabio Estevam
2014-04-23 15:49       ` Felipe Balbi
2014-04-23 14:58 ` [PATCH 09/13] tty: serial: omap: switch over to devm_ioremap_resource Felipe Balbi
2014-04-23 14:58 ` [PATCH 10/13] tty: serial: omap: remove some dead code Felipe Balbi
     [not found]   ` <1398265117-11793-10-git-send-email-balbi-l0cyMroinI0@public.gmane.org>
2014-04-23 15:26     ` Felipe Balbi
2014-04-23 15:35     ` Nishanth Menon
     [not found]       ` <5357DDA8.4040206-l0cyMroinI0@public.gmane.org>
2014-04-23 22:43         ` NeilBrown
     [not found]           ` <20140424084305.20c7f301-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2014-04-23 23:01             ` Felipe Balbi
2014-04-24  0:13               ` NeilBrown
     [not found]                 ` <20140424101329.02e6a62f-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2014-04-24  1:21                   ` Felipe Balbi
     [not found]                     ` <20140424012100.GB13374-HgARHv6XitL9zxVx7UNMDg@public.gmane.org>
2014-04-24  1:41                       ` NeilBrown
2014-04-24  1:43                         ` Felipe Balbi
2014-04-24  2:24                           ` NeilBrown
2014-04-24 14:19                       ` One Thousand Gnomes
2014-04-25  9:34                         ` NeilBrown
     [not found]                           ` <20140425193412.7d32e429-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2014-04-25  9:53                             ` Yegor Yefremov
2014-04-25 11:40                               ` One Thousand Gnomes
2014-04-25 11:47                           ` One Thousand Gnomes [this message]
2014-04-23 14:58 ` [PATCH 11/13] tty: serial: omap: remove unneeded singlethread workqueue Felipe Balbi
2014-04-23 14:58 ` [PATCH 12/13] tty: serial: omap: fix Sparse warnings Felipe Balbi
     [not found] ` <1398265117-11793-1-git-send-email-balbi-l0cyMroinI0@public.gmane.org>
2014-04-23 14:58   ` [PATCH 13/13] serial: 8250: add OMAP glue Felipe Balbi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140425124757.3f2069b2@alan.etchedpixels.co.uk \
    --to=gnomes@lxorguk.ukuu.org.uk \
    --cc=balbi@ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=gustavo@padovan.org \
    --cc=johan.hedberg@gmail.com \
    --cc=jslaby@suse.cz \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=marcel@holtmann.org \
    --cc=neilb@suse.de \
    --cc=nm@ti.com \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).