Hi,
On Mon, Aug 22, 2016 at 05:07:06PM -0400, Marcel Holtmann wrote:
> >> Would it make sense then to define a DT binding that can cover these
> >> four cases independent of the Linux usage:
> >>
> >> a) an existing tty line discipline matched to a tty port
> >> b) a serio device using the N_MOUSE line discipline (which
> >> happens to cover non-mouse devices these days)
> >
> > These two are the same basic thing
> >
> > port x expects ldisc y {with properties ...}
> >
> >> c) a uart_port slave attached directly to the uart (like in your
> >> current code)
> >
> > c) needs to be a tty_port slave attached directly to a tty_port.
> > Important detail, but as uart_port is just a subset of tty_port it's a
> > trivial detail to the DT.
> >
> >> d) the same slave drivers using a new tty line discipline
> >
> > and this is also just a/b again.
> >
> >
> > What use cases and connectivity do you need to describe. Looking at the
> > ACPI platforms we have
> >
> > - the expected serial port configuration
> > - the properties of the port (FIFO etc)
> > - the power management for the port
> >
> > - the children of the port
> > - the power management of the children (at a very simplistic abstracted
> > level)
> >
> > So we want to be able to describe something like
> >
> > ttyS0 {
> > baud: 1152008N1
> > protocol: bluetooth hci
> > fixed: yes
> > powermanagement: { ... }
> > }
>
> we also need to know what Bluetooth vendor is there. Since we need
> to match the vendor to the firmware loading and configuration.
>
> Additionally there might be PCM audio configurations that need to
> be considered. Since we have to configure direct PCM interconnect
> with the audio codec.
It's not enough to automatically set a ldisc. There is also need for
additional resouces. For example the Nokia bluetooth driver needs
some extra GPIOs. The same is true for the in-tree hci_bcm, which
misuses the platform_device exactly like Greg doesn't want it.
> > and if I look at the usermode crapfest on a lot of Android systems it
> > looks similar but with the notion of things like being able to describe
> >
> > - Use GPIO mode sleeping and assume first char is X to save power
> >
> > - Power up, wait n ms, write, read, wait n ms, power down (which
> > has to be driven at the ldisc/user level as only the ldisc
> > understands transactions, or via ioctls (right now Android user
> > space tends to do hardcoded writes to /sys.. gpio to drive power
> >
> > - And a few variants thereof (power up on write, off on a timer
> > etc)
>
> Actually the sad part about the Android mess is that we can fix it
> for Bluetooth. We have HCI User Channel that allows to grab a HCI
> device and assign it to Bluedroid stack on Android. So it would
> work with whatever bus or whatever vendor is underneath. All this
> hacking would go away. And we have used this successfully for
> Intel based Android platforms. We know this works.
>
> > So I can imagine wanting to describe something like
> >
> > - The bluetooth HCI hardware is managed by gpio 11 (or UART DTR,
> > or PMIC n etc)
> > The uart can switch into GPIO mode and is gpio 15
> >
> > or
> >
> > - Raise gpio 4 when writing, drop it after 50mS with no read/write
> >
> > Then the ldisc needs to make port->ops. calls for enabling/disabling low
> > power mode and expected char, and the uarts that can do it need to
> > implement the gpio/uart switching and any timers.
>
> I now wonder if we can not just turn the ldisc into a bus. So we
> have a ldisc bus that exposes devices that have no business of
> having a userspace /dev/ttyX exposed. And our Bluetooth UART
> support just turns into a ldisc driver on the ldisc bus.
>
> One of the problems is that attaching the ldisc from userspace you
> still need to figure out what /dev/ttyX you get assigned in the
> end. And figure out which one is the Bluetooth UART. If we want
> single images where things just work out of the box, we need to
> get extra information for doing auto-detection. So some sort of
> bus enumeration is key to make this work smoothly.
I don't understand your propsoal. First you write, that no ttyX
needs to be exported at all, then you need to figure out what ttyX
got assigned in the end.
I think the problem with line disciplines is, that they do
not follow the Linux device model. UART slaves may have extra
resources like gpios or regulators. The current workaround from
the drivers is an additional platform device, which only is
used as resource storage and accessed by the line discipline.
I think having a proper slave devices would be better in the long
run than adding more hacks to work around the problem of line
discplines not being devices. It probably makes sense to make the
API similar to the line discipline API, though. That way old code
can be reused.
-- Sebastian
Attachment:
signature.asc
Description: PGP signature
