From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756832AbcHVWBL (ORCPT ); Mon, 22 Aug 2016 18:01:11 -0400 Received: from mail.kernel.org ([198.145.29.136]:60078 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756008AbcHVWBI (ORCPT ); Mon, 22 Aug 2016 18:01:08 -0400 MIME-Version: 1.0 In-Reply-To: <20160822200026.4i32vakhzipv7asl@earth> References: <20160818011445.22726-1-robh@kernel.org> <12886761.WF058qtZp8@wuerfel> <2775954.hrE2UdODgU@wuerfel> <20160822180254.5c95af7c@lxorguk.ukuu.org.uk> <20160822200026.4i32vakhzipv7asl@earth> From: Rob Herring Date: Mon, 22 Aug 2016 17:00:40 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 0/3] UART slave device bus To: Sebastian Reichel Cc: One Thousand Gnomes , Arnd Bergmann , Greg Kroah-Hartman , Marcel Holtmann , Jiri Slaby , Pavel Machek , Peter Hurley , NeilBrown , "Dr . H . Nikolaus Schaller" , Linus Walleij , "open list:BLUETOOTH DRIVERS" , "linux-serial@vger.kernel.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 22, 2016 at 3:00 PM, Sebastian Reichel wrote: > Hi, > > On Mon, Aug 22, 2016 at 12:30:27PM -0500, Rob Herring wrote: >> On Mon, Aug 22, 2016 at 12:02 PM, One Thousand Gnomes >> wrote: >> >> > I think there are two other valuable features provided by serio: >> >> > >> >> > - an existing set of drivers written to the API >> >> > - the implementation of the tty_ldisc >> >> >> >> True, though I'd expect little of the data flow part of it to be reused. >> > >> > Then your design is broken. >> >> I'm talking about serio, not my design which I already said the >> receive side at least needs work. >> >> The serio API for rx and tx is a single character at a time. I thought >> we agreed that's not sufficient for things like BT. >> >> >> - a child of the uart node >> >> - a reg property containing the line number if the parent has multiple >> >> uarts (I'd expect this to rarely be used). >> > >> > That surprises me as for current x86 platforms it would be the norm, >> > except that we use ACPI. >> >> Exactly, we're talking DT bindings here. Each port will be a separate >> node otherwise things like serial aliases and stdout-path won't work >> correctly. Compatible strings for 8250 uarts are for a single port. >> But if you had h/w such that it has common and per port registers then >> it may be a single node. I'm not aware of any example offhand (maybe >> PPC CPM). But it doesn't matter as reg can handle this case just fine >> if we need to. > > I would expect, that your imaginary example h/w also has one node > per port using a mfd style h/w description: > > multi-uart-device { > uart1 { > child { }; > }; > uart2 { > child { }; > }; > }; Yes, that is certainly possible too. >> >> - baudrate and other line configuration (though I would expect the >> >> slave driver to know all this and set it w/o DT. Also, we already have >> >> a way to set baudrate in the parent node at least.) > > I'm not sure if every slave driver knows this. Maybe some generic > slave drivers will come up, once we have the infrastructure. So > it could be useful to have the settings as optional properties. > OTOH it can also be done once it is needed. Yes, you could have devices that do autobaud detect and don't care other than some max baudrate which could be limited by either the host or device. Then you have others that are fixed or start at a fixed baud and then switch. As for generic slaves, no doubt they will come up and I will be nak'ing the generic slave bindings. The "generic slave" is already supported via tty devices in userspace IMO. Rob From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Herring Subject: Re: [RFC PATCH 0/3] UART slave device bus Date: Mon, 22 Aug 2016 17:00:40 -0500 Message-ID: References: <20160818011445.22726-1-robh@kernel.org> <12886761.WF058qtZp8@wuerfel> <2775954.hrE2UdODgU@wuerfel> <20160822180254.5c95af7c@lxorguk.ukuu.org.uk> <20160822200026.4i32vakhzipv7asl@earth> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <20160822200026.4i32vakhzipv7asl@earth> Sender: linux-bluetooth-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Sebastian Reichel Cc: One Thousand Gnomes , Arnd Bergmann , Greg Kroah-Hartman , Marcel Holtmann , Jiri Slaby , Pavel Machek , Peter Hurley , NeilBrown , "Dr . H . Nikolaus Schaller" , Linus Walleij , "open list:BLUETOOTH DRIVERS" , "linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: linux-serial@vger.kernel.org On Mon, Aug 22, 2016 at 3:00 PM, Sebastian Reichel wrote: > Hi, > > On Mon, Aug 22, 2016 at 12:30:27PM -0500, Rob Herring wrote: >> On Mon, Aug 22, 2016 at 12:02 PM, One Thousand Gnomes >> wrote: >> >> > I think there are two other valuable features provided by serio: >> >> > >> >> > - an existing set of drivers written to the API >> >> > - the implementation of the tty_ldisc >> >> >> >> True, though I'd expect little of the data flow part of it to be reused. >> > >> > Then your design is broken. >> >> I'm talking about serio, not my design which I already said the >> receive side at least needs work. >> >> The serio API for rx and tx is a single character at a time. I thought >> we agreed that's not sufficient for things like BT. >> >> >> - a child of the uart node >> >> - a reg property containing the line number if the parent has multiple >> >> uarts (I'd expect this to rarely be used). >> > >> > That surprises me as for current x86 platforms it would be the norm, >> > except that we use ACPI. >> >> Exactly, we're talking DT bindings here. Each port will be a separate >> node otherwise things like serial aliases and stdout-path won't work >> correctly. Compatible strings for 8250 uarts are for a single port. >> But if you had h/w such that it has common and per port registers then >> it may be a single node. I'm not aware of any example offhand (maybe >> PPC CPM). But it doesn't matter as reg can handle this case just fine >> if we need to. > > I would expect, that your imaginary example h/w also has one node > per port using a mfd style h/w description: > > multi-uart-device { > uart1 { > child { }; > }; > uart2 { > child { }; > }; > }; Yes, that is certainly possible too. >> >> - baudrate and other line configuration (though I would expect the >> >> slave driver to know all this and set it w/o DT. Also, we already have >> >> a way to set baudrate in the parent node at least.) > > I'm not sure if every slave driver knows this. Maybe some generic > slave drivers will come up, once we have the infrastructure. So > it could be useful to have the settings as optional properties. > OTOH it can also be done once it is needed. Yes, you could have devices that do autobaud detect and don't care other than some max baudrate which could be limited by either the host or device. Then you have others that are fixed or start at a fixed baud and then switch. As for generic slaves, no doubt they will come up and I will be nak'ing the generic slave bindings. The "generic slave" is already supported via tty devices in userspace IMO. Rob