Message-ID: <20160822200026.4i32vakhzipv7asl@earth>
Date:   Mon, 22 Aug 2016 22:00:28 +0200
From:   Sebastian Reichel <sre@...nel.org>
To:     Rob Herring <robh@...nel.org>
Cc:     One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Marcel Holtmann <marcel@...tmann.org>,
        Jiri Slaby <jslaby@...e.com>, Pavel Machek <pavel@....cz>,
        Peter Hurley <peter@...leysoftware.com>,
        NeilBrown <neil@...wn.name>,
        "Dr . H . Nikolaus Schaller" <hns@...delico.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        "open list:BLUETOOTH DRIVERS" <linux-bluetooth@...r.kernel.org>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 0/3] UART slave device bus

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
> <gnomes@...rguk.ukuu.org.uk> 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 { };
    };
};

> >> - 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.

> >> - other standard device properties for interrupt, gpios, regulators.
> >>
> >> Also to consider is whether muxing of multiple slaves is needed. It's
> >> not anything I've seen come up, but it's not hard to imagine. I think
> >> that can be considered later and shouldn't impact the initial binding
> >> or infrastructure.
> >
> > You can describe the child of the serial device as a mux and the children
> > of the mux as whatever so it comes out fine when you get to that point.
> 
> Yes, that's what I had in mind.

I guess it can be discussed, when it becomes relevant. Until then
let's not open another topic.

-- Sebastian

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists