From: Johan Hovold <johan@kernel.org>
To: Andreas Kemnade <andreas@kemnade.info>
Cc: "H. Nikolaus Schaller" <hns@goldelico.com>,
Johan Hovold <johan@kernel.org>, Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
devicetree <devicetree@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Discussions about the Letux Kernel <letux-kernel@openphoenux.org>
Subject: Re: [Letux-kernel] [PATCH 0/5] gnss: sirf: add support for w2sg0004 + lna
Date: Wed, 5 Dec 2018 16:19:16 +0100 [thread overview]
Message-ID: <20181205151916.GJ15689@localhost> (raw)
In-Reply-To: <20181119194414.1c7d6887@aktux>
On Mon, Nov 19, 2018 at 07:44:14PM +0100, Andreas Kemnade wrote:
> On Mon, 19 Nov 2018 09:22:59 +0100
> "H. Nikolaus Schaller" <hns@goldelico.com> wrote:
> > > Am 18.11.2018 um 22:57 schrieb Andreas Kemnade <andreas@kemnade.info>:
> > >
> > > Here is another chapter of the story to get gta04 gnss power
> > > management into the mainline kernel.
> > > There is a w2sg0004 without wakeup line in there, so power state
> > > can only be determined indirectly by looking at the serial data lines.
> > > Then there as also an lna which needs to be powered for real gps
> > > reception. That part needs probably more discussion, since it might
> > > be an idea to have it more generalized since it has nothing todo
> > > with the chip itself.
> >
> > On the other hand if we follow the "SoC is the spider in the net"
> > way of looking at DTS hierarchy, we have the uart as a child of the
> > SoC and the gnss receiver as a serdev child of the UART. The LNA
> > is even one step more distantly connected to the gnss. So it makes
> > sense to me to have it as a property/reference of the gnss chip's
> > DTS record which is a sibling of the compatible records. So the only
> > place where it can be reasonably processed is the driver.
> >
> Or the lna is a child of the gnss receiver. The whole thing
> should probably not be overdesigned, but it does not make sense that
> every gnss chip driver has some lna logic.
Did you mean "does make sense" here?
> Maybe the regulator should just be stored in the struct
> gnss_device and then drivers/gnss/core.c takes care.
Maybe eventually, but keeping it per driver is fine for now.
As you say above, this really isn't part of the chip itself, and
therefore should probably be a generic gnss property as it could be
required for any receiver (in principle).
But we still need driver support for coordinating it with the rest of
the receiver power management, so adding it to drivers as need arises
seems reasonable.
Thanks,
Johan
next prev parent reply other threads:[~2018-12-05 15:19 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-18 21:57 [PATCH 0/5] gnss: sirf: add support for w2sg0004 + lna Andreas Kemnade
2018-11-18 21:57 ` [PATCH 1/5] gnss: sirf: write data to gnss only when the gnss device is open Andreas Kemnade
2018-12-05 14:47 ` Johan Hovold
2018-12-05 20:14 ` Andreas Kemnade
2018-11-18 21:57 ` [PATCH 2/5] gnss: sirf: power on logic for devices without wakeup signal Andreas Kemnade
2018-11-19 8:37 ` H. Nikolaus Schaller
2018-12-05 15:01 ` Johan Hovold
2018-12-05 22:15 ` Andreas Kemnade
2018-11-18 21:57 ` [PATCH 3/5] dt-bindings: gnss: add w2sg0004 compatible string Andreas Kemnade
2018-12-04 22:57 ` Rob Herring
2018-12-05 15:01 ` Johan Hovold
2018-11-18 21:58 ` [PATCH RFC 4/5] gnss: sirf: add a separate supply for a lna Andreas Kemnade
2018-11-19 8:41 ` [Letux-kernel] " H. Nikolaus Schaller
2018-11-27 18:03 ` Pavel Machek
2018-11-30 6:38 ` Andreas Kemnade
2018-11-30 8:43 ` Pavel Machek
2018-12-05 15:06 ` Johan Hovold
2018-11-18 21:58 ` [PATCH RFC 5/5] dt-bindings: gnss: add lna-supply property Andreas Kemnade
2018-12-04 22:59 ` Rob Herring
2018-12-05 15:09 ` Johan Hovold
2018-12-09 19:11 ` Andreas Kemnade
2018-11-19 8:22 ` [Letux-kernel] [PATCH 0/5] gnss: sirf: add support for w2sg0004 + lna H. Nikolaus Schaller
2018-11-19 18:44 ` Andreas Kemnade
2018-11-19 19:05 ` H. Nikolaus Schaller
2018-12-05 15:19 ` Johan Hovold [this message]
2018-12-05 16:01 ` [Letux-kernel] " Johan Hovold
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=20181205151916.GJ15689@localhost \
--to=johan@kernel.org \
--cc=andreas@kemnade.info \
--cc=devicetree@vger.kernel.org \
--cc=hns@goldelico.com \
--cc=letux-kernel@openphoenux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
/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).