lkml.org 
[lkml]   [2016]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC PATCH 0/3] UART slave device bus
    From
    Date
    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.
    >>>> - Split out the controller for uart_ports into separate driver. Do we see
    >>>> a need for controller drivers that are not standard serial drivers?
    >>>> - 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)?
    >>>> - Test with other UART drivers
    >>>> - Convert a real driver/line discipline over to UART bus.
    >>>>
    >>>> 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).
    >>>
    >>> Some quick comments (can't do any real life tests in the next weeks) from my (biased) view:
    >>>
    >>> * tieing the solution into uart_port is the same as we had done. The difference seems to
    >>> me that you completely bypass serial_core (and tty) while we want to integrate it with standard tty operation.
    >>>
    >>> We have tapped the tty layer only because it can not be 100% avoided if we use serial_core.
    >>>
    >>> * one feedback I had received was that there may be uart device drivers not using serial_core. I am not sure if your approach addresses that.
    >>>
    >>> * what I don't see is how we can implement our GPS device power control driver:
    >>> - the device should still present itself as a tty device (so that cat /dev/ttyO1 reports NMEA records) and should
    >>> not be completely hidden from user space or represented by a new interface type invented just for this device
    >>> (while the majority of other GPS receivers are still simple tty devices).
    >>> - how we can detect that the device is sending data to the UART while no user space process has the uart port open
    >>> i.e. when does the driver know when to start/stop the UART.
    >>
    >> I am actually not convinced that GPS should be represented as
    >> /dev/ttyS0 or similar TTY. It think they deserve their own driver
    >> exposing them as simple character devices. That way we can have a
    >> proper DEVTYPE and userspace can find them correctly. We can also
    >> annotate them if needed for special settings.
    >
    > I would _love_ to see that happen, but what about the GPS line
    > discipline that we have today? How would that match up with a char
    > device driver?

    we have a GPS line discipline? What is that one doing? As far as I know all GPS implementations are fully userspace.

    Regards

    Marcel

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