On Mon, Aug 22, 2016 at 3:00 PM, Sebastian Reichel <sre@xxxxxxxxxx> 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
>> <gnomes@xxxxxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
