Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752075AbbEFN3R (ORCPT ); Wed, 6 May 2015 09:29:17 -0400 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.221]:60577 "EHLO mo4-p00-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750816AbbEFN3N convert rfc822-to-8bit (ORCPT ); Wed, 6 May 2015 09:29:13 -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: <20150506123632.GA1764@leverpostej> Date: Wed, 6 May 2015 15:28:58 +0200 Cc: Peter Hurley , Pavel Machek , List for communicating with real GTA04 owners , NeilBrown , One Thousand Gnomes , Arnd Bergmann , Greg Kroah-Hartman , Sebastian Reichel , "grant.likely@linaro.org" , 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> <20150506123632.GA1764@leverpostej> To: Mark Rutland 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: 5843 Lines: 172 Hi Mark, Am 06.05.2015 um 14:36 schrieb Mark Rutland : > On Wed, May 06, 2015 at 01:27:03PM +0100, Dr. H. Nikolaus Schaller wrote: >> 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> >> }; >> }; > > If this happens, you can move the slave device into a fragment that you > can include under the correct node. That's trivial. But less readable. And that is important as well. > > If you have a large amount of variation within a given platform, that is > a problem with your platform. Agreed. > >> 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). > > We already place child nodes under their respective busses I still wonder why UART is considered as a bus? For me it is a point-to-point interface, and not a bus. I assume that a majority of engineers outside of our discussion tend to agree. [random pick: http://www.avrfreaks.net/comment/473738#comment-473738 "So basically, UART is not a bus. If you really want to connect N devices together, use I2C maybe, it too has two wires and anyone can be master.?] Even some ISO standards define a ?bus? as something with addressable clients (and UART has no addresses since it has no protocol by itself). > for other > interfaces like SPI and I2C. I do not see a compelling reason to do > otherwise for devices why the plural? Is there a practical example where multiple devices are connected to a single UART and how is addressing solved? > hanging off of UARTs -- doing so would make things > less straightforward because you have a fundamentally different idiom. Yes, my proposal is fundamentally different from I2C and SPI practice, but it is the same that is heavily used for e.g. GPIOs and Regulators. So it is not at all a ?different? idiom. Just one that IMHO better fits for point-to-point connections (like power distribution or GPIOs). Therefore I have a reason to use a different idiom for a technically different task. > > Having the slave live under the UART node also gives you sane probe > ordering -- you must probe the parent before the slave as the parent > driver (perhaps via common code) will trigger the scan of children. This is a good and interesting argument in favour of the subnodes approach. I know there was (is?) a problem with GPIO controllers not probed before they are referenced. That made some problems for OMAP around release 3.14. But AFAIK it is solved now (don?t know the details how it is solved). Anyways, I wonder why probing and probe order should be implicitly reflected by the DT? If DT is really a hardware description (and not a tool for kernel code optimisation), then it should not matter and other aspects should have a higher priority. E.g. which information is to be provided by the slave node and which by the uart node. The key point appears to be how we want to see the serial connection. Is the device connected to the uart or the uart to a device? In OO terminology: ?device connects to uart? vs. ?uart has device connected?. "d -> u? vs. "u <- d?. For a bus like I2C or SPI it is ?controller has device connected? but for a good reason (somehow the address must be specified - and addressing belongs to the master side). >From my DT designer PoV I would say the UART exists in some SoC (independently of a device being connected) and then, a device is connected to the UART. Hence the proposal of adding this connection link to the device?s node and not making the device a subnode. And having the device driver do power management and only ask the uart/tty driver to be notified about open() and close() events. How power is managed in detail is then not any part of the tty/serial drivers. 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/