From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752013AbbCYUxy (ORCPT ); Wed, 25 Mar 2015 16:53:54 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:60045 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750884AbbCYUxt (ORCPT ); Wed, 25 Mar 2015 16:53:49 -0400 Date: Wed, 25 Mar 2015 21:53:44 +0100 From: Pavel Machek To: "Dr. H. Nikolaus Schaller" Cc: Sebastian Reichel , NeilBrown , List for communicating with real GTA04 owners , Mark Rutland , One Thousand Gnomes , Peter Hurley , Arnd Bergmann , Greg Kroah-Hartman , Grant Likely , Jiri Slaby , devicetree@vger.kernel.org, lkml Subject: Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices. Message-ID: <20150325205344.GD381@amd> References: <20150318055437.21025.13990.stgit@notabene.brown> <20150318055831.21025.33670.stgit@notabene.brown> <20150320195451.146a7915@notabene.brown> <14FB51CF-9568-4BF4-B917-2C019D992FDB@goldelico.com> <20150321103122.23603014@notabene.brown> <20150325014543.GA967@earth> <6B657A35-68BD-45F6-BD55-A3D6AC1055C8@goldelico.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6B657A35-68BD-45F6-BD55-A3D6AC1055C8@goldelico.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi! > >> AFAIK the chip simply starts to emit NMEA records if powered on. > >> There is no command going over the serial interface to address it > >> or control it. > > > > Right, since GPS basically doesn't need any configuration/control. > > That’s not true for other UART attached devices, though. > > Do you have an example? Usually an UART data stream is transparently > presented to a /dev/tty - and user-space daemon can configure/control the > attached device. In most cases it can mix payload data and control command > by some AT command and escape sequences. Bluetooth H4P protocol is one example. > > well parent > child is not about power control, but about "primary" > > control. > > Can you clearly and precisely define what “primary” control is? I think > two people will have three opinions about that. This has not be a problem so far... > For example I would see the w2sg0004 on/off gpio as the primary “control” > which makes the light (NMES records) turned on. ...and I don't think it is a problem now. > > Main reason is, that I would need to go > > through the UART to “communicate" with the w2sg0004. > > You can always "communicate” through the UART. Even without DT. As long as > the connected chip is powered up by any means (could be some fixed-regulator > or hard wired). But you don't know "how" to communicate through the uart. > Let me raise the question: > > Why do we need to describe in the DT (independently of Linux power control > structures and drivers!) that the GPS data interface is connected to a specific UART? Because we want the phone to boot knowing "I have a bluetooth" or "I have a GPS", as it would if it was connected using USB, and not having user figure out what commands he needs to do to enable reasonable hardware support (and getting it wrong, because you need to specify _many_ critical parameters to hciattach). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html