All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Andreas Kemnade <andreas@kemnade.info>
Cc: "Johan Hovold" <johan@kernel.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	devicetree@vger.kernel.org, "Thierry Reding" <treding@nvidia.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Tony Lindgren" <tony@atomide.com>,
	"H. Nikolaus Schaller" <hns@goldelico.com>,
	"Russell King" <linux@armlinux.org.uk>,
	linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
	"Rob Herring" <robh+dt@kernel.org>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Benoît Cousson" <bcousson@baylibre.com>,
	kernel@pyra-handheld.com,
	"Discussions about the Letux Kernel"
	<letux-kernel@openphoenux.org>,
	"Andreas Färber" <afaerber@suse.de>,
	"Jonathan Cameron" <jic23@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Letux-kernel] [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver
Date: Mon, 19 Mar 2018 15:02:52 +0100	[thread overview]
Message-ID: <20180319140252.GM18359@localhost> (raw)
In-Reply-To: <20180308071459.310d0ba2@aktux>

On Thu, Mar 08, 2018 at 07:16:44AM +0100, Andreas Kemnade wrote:
> Hi,
> 
> On Thu, 18 Jan 2018 17:47:36 +1100
> Johan Hovold <johan@kernel.org> wrote:
> 
> [...]
> > > 
> > > So to avoid having hardware information spread all over the table at least
> > > these information would need to be in devicetree. But that also all feels
> > > like a hack and hard to maintain.  
> > 
> > Having the device described in the device tree is certainly desirable,
> > not least for chip identification. And with a GPS framework in the
> > kernel with a well-defined interface, implementing power management
> > would be straight forward.
> > 
> Hmm, devicetree without in-kernel drivers, do we have anything like that
> somewhere? I thought that was a big no-go. But maybe I am wrong.

No, that's probably not a good idea, even if it may be possible (what
about ACPI then, for example?).

> > I'm just not convinced that the proposed tty interface is the right
> > interface for this. User space would still rely on gpsd for the GPS
> > protocols, and would also ultimately be managing power by killing gpsd
> > or whatever daemon that would otherwise be holding the port open.
> > 
> > Something like the generic power sequences that has been discussed
> > elsewhere might be a better fit for this if all you want to do is power
> > on and off on port open and close (and on suspend/resume). There really
> > isn't anything GPS-specific in the current proposal (besides the
> > suggested tty-device name).
> 
> So a bit like that mmc-powerseq stuff we already have?

Yeah, the generic power sequence patches were inspired by that and
intended to generalise it (e.g. to be used by the USB bus to power on
devices so that they could be enumerated). There were some issues with
that work though (which also precludes it from being used for something
like this), and it still wouldn't be sufficient to deal with the gps
device in question (which needs to monitor the incoming data).

> > But sure, that wouldn't be sufficient to deal with the
> > unknown-power-state problem with the device in question.
>
> Maybe there could be a kind of active flag set by the tty if
> there is traffic, so that active flag could be used in these
> power sequence stuff? But then again the tty layer has to be extended
> which would probably also cause a lot of ruffled feathers.

Yeah, I think this is a dead end. We need some kind of gps framework
with drivers that can implement the device specific bits.

I may have some time to look at little closer at it this week.

Johan

WARNING: multiple messages have this Message-ID (diff)
From: johan@kernel.org (Johan Hovold)
To: linux-arm-kernel@lists.infradead.org
Subject: [Letux-kernel] [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver
Date: Mon, 19 Mar 2018 15:02:52 +0100	[thread overview]
Message-ID: <20180319140252.GM18359@localhost> (raw)
In-Reply-To: <20180308071459.310d0ba2@aktux>

On Thu, Mar 08, 2018 at 07:16:44AM +0100, Andreas Kemnade wrote:
> Hi,
> 
> On Thu, 18 Jan 2018 17:47:36 +1100
> Johan Hovold <johan@kernel.org> wrote:
> 
> [...]
> > > 
> > > So to avoid having hardware information spread all over the table at least
> > > these information would need to be in devicetree. But that also all feels
> > > like a hack and hard to maintain.  
> > 
> > Having the device described in the device tree is certainly desirable,
> > not least for chip identification. And with a GPS framework in the
> > kernel with a well-defined interface, implementing power management
> > would be straight forward.
> > 
> Hmm, devicetree without in-kernel drivers, do we have anything like that
> somewhere? I thought that was a big no-go. But maybe I am wrong.

No, that's probably not a good idea, even if it may be possible (what
about ACPI then, for example?).

> > I'm just not convinced that the proposed tty interface is the right
> > interface for this. User space would still rely on gpsd for the GPS
> > protocols, and would also ultimately be managing power by killing gpsd
> > or whatever daemon that would otherwise be holding the port open.
> > 
> > Something like the generic power sequences that has been discussed
> > elsewhere might be a better fit for this if all you want to do is power
> > on and off on port open and close (and on suspend/resume). There really
> > isn't anything GPS-specific in the current proposal (besides the
> > suggested tty-device name).
> 
> So a bit like that mmc-powerseq stuff we already have?

Yeah, the generic power sequence patches were inspired by that and
intended to generalise it (e.g. to be used by the USB bus to power on
devices so that they could be enumerated). There were some issues with
that work though (which also precludes it from being used for something
like this), and it still wouldn't be sufficient to deal with the gps
device in question (which needs to monitor the incoming data).

> > But sure, that wouldn't be sufficient to deal with the
> > unknown-power-state problem with the device in question.
>
> Maybe there could be a kind of active flag set by the tty if
> there is traffic, so that active flag could be used in these
> power sequence stuff? But then again the tty layer has to be extended
> which would probably also cause a lot of ruffled feathers.

Yeah, I think this is a dead end. We need some kind of gps framework
with drivers that can implement the device specific bits.

I may have some time to look at little closer at it this week.

Johan

  reply	other threads:[~2018-03-19 14:02 UTC|newest]

Thread overview: 100+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-01  7:49 [PATCH v5 0/5] misc serdev: new serdev based driver for Wi2Wi w2sg00x4 GPS module H. Nikolaus Schaller
2017-12-01  7:49 ` H. Nikolaus Schaller
2017-12-01  7:49 ` [PATCH v5 1/5] dt-bindings: define vendor prefix for Wi2Wi, Inc H. Nikolaus Schaller
2017-12-01  7:49   ` H. Nikolaus Schaller
2017-12-01 14:44   ` Andreas Färber
2017-12-01 14:44     ` Andreas Färber
2017-12-01  7:49 ` [PATCH v5 2/5] dt-bindings: gps: add w2sg00x4 bindings documentation (GPS module with UART)) H. Nikolaus Schaller
2017-12-01  7:49   ` H. Nikolaus Schaller
2017-12-01  7:49   ` H. Nikolaus Schaller
2017-12-01  7:49 ` [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver H. Nikolaus Schaller
2017-12-01  7:49   ` H. Nikolaus Schaller
2017-12-01  7:49   ` H. Nikolaus Schaller
2017-12-22 12:44   ` Johan Hovold
2017-12-22 12:44     ` Johan Hovold
2017-12-22 12:44     ` Johan Hovold
2017-12-22 14:40     ` H. Nikolaus Schaller
2017-12-22 14:40       ` H. Nikolaus Schaller
2017-12-22 14:40       ` H. Nikolaus Schaller
2018-01-09 11:55       ` [Letux-kernel] " H. Nikolaus Schaller
2018-01-09 11:55         ` H. Nikolaus Schaller
2018-01-09 11:55         ` H. Nikolaus Schaller
2018-01-12 15:39         ` Johan Hovold
2018-01-12 15:39           ` Johan Hovold
2018-01-12 15:39           ` Johan Hovold
2018-01-12 17:59           ` H. Nikolaus Schaller
2018-01-12 17:59             ` H. Nikolaus Schaller
2018-01-12 17:59             ` H. Nikolaus Schaller
2018-01-18  6:13             ` Johan Hovold
2018-01-18  6:13               ` Johan Hovold
2018-01-18  6:13               ` Johan Hovold
2018-01-18 13:43               ` H. Nikolaus Schaller
2018-01-18 13:43                 ` H. Nikolaus Schaller
2018-01-18 13:43                 ` H. Nikolaus Schaller
2018-03-07 15:53                 ` H. Nikolaus Schaller
2018-03-07 15:53                   ` H. Nikolaus Schaller
2018-03-07 15:53                   ` H. Nikolaus Schaller
2018-03-19 14:05                   ` Johan Hovold
2018-03-19 14:05                     ` Johan Hovold
2018-03-19 14:05                     ` Johan Hovold
2018-02-12 15:26           ` [Letux-kernel] " Pavel Machek
2018-02-12 15:26             ` Pavel Machek
2018-02-12 15:26             ` Pavel Machek
2018-02-27  7:04             ` Johan Hovold
2018-02-27  7:04               ` Johan Hovold
2018-02-27  7:04               ` Johan Hovold
2018-02-27  7:32               ` H. Nikolaus Schaller
2018-02-27  7:32                 ` H. Nikolaus Schaller
2018-02-27  7:32                 ` H. Nikolaus Schaller
2018-03-19 13:54                 ` Johan Hovold
2018-03-19 13:54                   ` Johan Hovold
2018-03-19 13:54                   ` Johan Hovold
2018-03-20 14:49                   ` H. Nikolaus Schaller
2018-03-20 14:49                     ` H. Nikolaus Schaller
2018-03-20 14:49                     ` H. Nikolaus Schaller
2018-03-26 13:59                     ` Pavel Machek
2018-03-26 13:59                       ` Pavel Machek
2018-02-27 18:38               ` Pavel Machek
2018-02-27 18:38                 ` Pavel Machek
2018-02-27 18:38                 ` Pavel Machek
2018-02-12 15:25         ` Pavel Machek
2018-02-12 15:25           ` Pavel Machek
2018-01-09 17:43     ` Andreas Kemnade
2018-01-09 17:43       ` Andreas Kemnade
2018-01-09 17:43       ` Andreas Kemnade
2018-01-12 14:46       ` Johan Hovold
2018-01-12 14:46         ` Johan Hovold
2018-01-12 18:40         ` Andreas Kemnade
2018-01-12 18:40           ` Andreas Kemnade
2018-01-12 18:40           ` Andreas Kemnade
2018-01-18  6:47           ` Johan Hovold
2018-01-18  6:47             ` Johan Hovold
2018-01-18  6:47             ` Johan Hovold
2018-03-08  6:16             ` Andreas Kemnade
2018-03-08  6:16               ` Andreas Kemnade
2018-03-19 14:02               ` Johan Hovold [this message]
2018-03-19 14:02                 ` Johan Hovold
2017-12-01  7:49 ` [PATCH v5 4/5] DTS: gta04: add uart2 child node for w2sg00x4 H. Nikolaus Schaller
2017-12-01  7:49   ` H. Nikolaus Schaller
2017-12-21 14:53   ` Tony Lindgren
2017-12-21 14:53     ` Tony Lindgren
2017-12-21 14:53     ` Tony Lindgren
2017-12-01  7:49 ` [PATCH v5 5/5] misc serdev: w2sg0004: add debugging code and Kconfig H. Nikolaus Schaller
2017-12-01  7:49   ` H. Nikolaus Schaller
2017-12-01  7:49   ` H. Nikolaus Schaller
2017-12-22 12:51   ` Johan Hovold
2017-12-22 12:51     ` Johan Hovold
2017-12-22 12:51     ` Johan Hovold
2017-12-22 14:41     ` H. Nikolaus Schaller
2017-12-22 14:41       ` H. Nikolaus Schaller
2017-12-22 14:58       ` Greg Kroah-Hartman
2017-12-22 14:58         ` Greg Kroah-Hartman
2017-12-22 14:58         ` Greg Kroah-Hartman
2017-12-18  8:52 ` [PATCH v5 0/5] misc serdev: new serdev based driver for Wi2Wi w2sg00x4 GPS module H. Nikolaus Schaller
2017-12-18  8:52   ` H. Nikolaus Schaller
2017-12-18  8:52   ` H. Nikolaus Schaller
2017-12-18 14:48   ` Greg Kroah-Hartman
2017-12-18 14:48     ` Greg Kroah-Hartman
2017-12-18 14:52     ` H. Nikolaus Schaller
2017-12-18 14:52       ` H. Nikolaus Schaller
2017-12-18 14:52       ` H. Nikolaus Schaller

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=20180319140252.GM18359@localhost \
    --to=johan@kernel.org \
    --cc=afaerber@suse.de \
    --cc=andreas@kemnade.info \
    --cc=arnd@arndb.de \
    --cc=bcousson@baylibre.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hns@goldelico.com \
    --cc=jic23@kernel.org \
    --cc=kernel@pyra-handheld.com \
    --cc=khilman@baylibre.com \
    --cc=letux-kernel@openphoenux.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=tony@atomide.com \
    --cc=treding@nvidia.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 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.