lkml.org 
[lkml]   [2016]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH 0/3] UART slave device bus
    On Thu, Aug 18, 2016 at 12:30:32PM +0200, Marcel Holtmann wrote:
    > Hi Greg,
    >
    > >> Currently, devices attached via a UART are not well supported in the
    > >> kernel. The problem is the device support is done in tty line disciplines,
    > >> various platform drivers to handle some sideband, and in userspace with
    > >> utilities such as hciattach.
    > >>
    > >> There have been several attempts to improve support, but they suffer from
    > >> still being tied into the tty layer and/or abusing the platform bus. This
    > >> is a prototype to show creating a proper UART bus for UART devices. It is
    > >> tied into the serial core (really struct uart_port) below the tty layer
    > >> in order to use existing serial drivers.
    > >>
    > >> This is functional with minimal testing using the loopback driver and
    > >> pl011 (w/o DMA) UART under QEMU (modified to add a DT node for the slave
    > >> device). It still needs lots of work and polish.
    > >>
    > >> TODOs:
    > >> - Figure out the port locking. mutex plus spinlock plus refcounting? I'm
    > >> hoping all that complexity is from the tty layer and not needed here.
    > >
    > > It should be.
    > >
    > >> - Split out the controller for uart_ports into separate driver. Do we see
    > >> a need for controller drivers that are not standard serial drivers?
    > >
    > > What do you mean by "controller" drivers here? I didn't understand them
    > > in the code.
    > >
    > >> - Implement/test the removal paths
    > >> - Fix the receive callbacks for more than character at a time (i.e. DMA)
    > >> - Need better receive buffering than just a simple circular buffer or
    > >> perhaps a different receive interface (e.g. direct to client buffer)?
    > >
    > > Why? Is the code as-is slow?
    > >
    > >> - Test with other UART drivers
    > >> - Convert a real driver/line discipline over to UART bus.
    > >
    > > That's going to be the real test, I recommend trying that as soon as
    > > possible as it will show where the real pain points are :)
    >
    > maybe we can get the Intel LnP driver ported over and see how that one
    > works out. It is one of the more complex ones when it comes to
    > bootloader and firmware loading. Maybe Loic can take a stab at this.
    > We would then also see how we can map the ACPI tables into a driver.

    Yes, I was going to complain about the OF-only bent of this patch, but I
    figured it would get fixed up once Rob started to use a "real" machine
    for his testing of this code :)

    > >> Before I spend more time on this, I'm looking mainly for feedback on the
    > >> general direction and structure (the interface with the existing serial
    > >> drivers in particular).
    > >
    > > Yes, I like the idea (minor nit, you still have SPMI in a lot of places
    > > instead of UART), so I recommend keeping going with it.
    > >
    > >> drivers/uart/Kconfig | 17 ++
    > >> drivers/uart/Makefile | 3 +
    > >> drivers/uart/core.c | 458 +++++++++++++++++++++++++++++++++++++++
    > >> drivers/uart/loopback.c | 72 ++++++
    > >
    > > Why not just put this in drivers/tty/uart/ ?
    >
    > Is it really then a TTY at all. Would be the UART become the basic
    > core for a TTY?

    Hm, interesting idea. Not for all TTYs of course, but for those that
    are on UART devices, maybe? How would a usb-serial device fit into that
    picture?

    > Having tty/uart/ seems a bit backward. Then again, it is just a
    > directory name ;)

    And as we know, naming is hard :)

    thanks,

    greg k-h

    \
     
     \ /
      Last update: 2016-09-17 09:57    [W:2.268 / U:22.120 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site