Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751976AbbEFM1R (ORCPT ); Wed, 6 May 2015 08:27:17 -0400 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.163]:9870 "EHLO mo4-p00-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751130AbbEFM1O convert rfc822-to-8bit (ORCPT ); Wed, 6 May 2015 08:27:14 -0400 X-RZG-AUTH: :JGIXVUS7cutRB/49FwqZ7WcKdUCnXG6JabOfSXKWrat+gdPsz+SM X-RZG-CLASS-ID: mo00 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3. From: "Dr. H. Nikolaus Schaller" In-Reply-To: <554A03A7.2000504@hurleysoftware.com> Date: Wed, 6 May 2015 14:27:03 +0200 Cc: Pavel Machek , List for communicating with real GTA04 owners , NeilBrown , Mark Rutland , One Thousand Gnomes , Arnd Bergmann , Greg Kroah-Hartman , Sebastian Reichel , Grant Likely , Jiri Slaby , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8BIT Message-Id: References: <20150318055437.21025.13990.stgit@notabene.brown> <55492001.30806@hurleysoftware.com> <20150506092738.GB4508@amd> <554A03A7.2000504@hurleysoftware.com> To: Peter Hurley X-Mailer: Apple Mail (2.1878.6) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3210 Lines: 125 Hi Peter, Am 06.05.2015 um 14:05 schrieb Peter Hurley : > On 05/06/2015 07:50 AM, Dr. H. Nikolaus Schaller wrote: >> No, I am not playing devil?s advocate (which would imply that I am doing this >> for fun to tease the dog), but I feel I have to be the advocate of future board >> designers who want to easily import an existing board DT and overwrite device >> tree nodes to describe design changes, i.e. what slave device is connected to >> which uart. > > I dont' see a big distinction at the DTS source level, so your concern is wrt > binary dtbs? No. My concern is wrt including existing board files and making small modifications on source level (or overlays). We discuss: board1.dts: uart3 { // subnode of some SoC slave { // slave connected to uart3 compatible = ???; gpio = <&gpio5 12 0> }; }; vs. board1.dts: / { slave { compatible = ???; gpio = <&gpio5 12 0> uart = &uart3; // slave connected to uart3 }; }; uart3 { // subnode of some SoC }; now let?s have a spin of the board design which just rewires the slave to uart4 (somtimes hardware engineers do such things). board2.dts: #include // reconnect device to uart4 uart4 { // subnode of some SoC slave { // slave connected to uart4 compatible = ???; gpio = <&gpio5 12 0> }; }; uart3 { // subnode of some SoC slave { // slave connected to uart3 compatible = ?none? // we can?t delete imported subnodes }; }; /// add another device to uart5? uart5 { // subnode of some SoC slave2 { // slave connected to uart5 compatible = ???; gpio = <&gpio5 13 0> }; }; vs. board2.dts: #include // reconnect device to uart4 &slave { uart = &uart3; }; // add another device to uart5? slave2 { compatible = ???; gpio = <&gpio5 13 0> uart = &uart5; }; So the main difference is if the slave device tells to which uart it is connected or the uart which slave device it is connected to. And I think the second approach is easier and more straightforward (on DT level). > >> At least in this regard, the alternatives are really differently easy to handle. >> >> And, the alternatives have some influence how a tty driver and a slave device >> driver is designed. So that is for me the root question, before discussing (some) >> implementation details. > > I would expect _no_ impact on the tty driver; have I overlooked something? The way a tty driver finds the slave or the slave finds the tty driver instance. In my proposal, the slave device has to look up the uart instance it is connected to and must register itself as a power management client to get notifications. It can also receive other notifications or change the line discipline to its needs. In Neil?s original proposal the tty driver simply imposes some special power management methods (control gpio or a regulator) over the slave driver which does not encapsulate it?s power management methods. BR, Nikolaus-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/