lkml.org 
[lkml]   [2018]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Subject[RFC PATCH v2 0/3] usb: typec: Support for Alternate Modes
    Date
    Hi guys,

    This is second version of my proposal for more complete USB Type-C
    Alternate Mode support. The original proposal can be read from here:
    https://www.spinics.net/lists/linux-usb/msg161098.html

    These patches now depend on series from Hans where he is introducing
    mux handling support for USB Type-C and USB in general:
    https://lkml.org/lkml/2018/3/2/340

    The major difference compared to v1 is that I'm proposing change to
    the sysfs ABI we have for the alternate mode devices. The files are
    not changed, but they are moved to the parent directory from the
    mode<index> folder. Since the alternate mode devices are not yet used
    and in practice not supported in mainline, I felt brave enough to
    propose that.

    The reason for removing the mode<index> folder is because as in patch
    1/3 I now create a device for every mode of every SVID, there will
    never be more then one mode folder. I.e. the folder serves no purpose.
    The mode<index> is still kept for now, but it's just deprecated.

    There are no alternate mode drivers included yet in this version.


    Original commit message (subject was "usb: typec: alternate mode
    bus"):

    The bus allows SVID specific communication with the partners to be
    handled in separate drivers for each alternate mode.

    Alternate mode handling happens with two separate logical devices:
    1. Partner alternate mode devices which represent the alternate modes
    on the partner. The driver for them will handle the alternate mode
    specific communication with the partner using VDMs.
    2. Port alternate mode devices which represent connections from the
    USB Type-C port to devices on the platform.

    The drivers will be bind to the partner alternate modes. The alternate
    mode drivers will need to deliver the result of the negotiated pin
    configurations to the rest of the platform (towards the port alternate
    mode devices). This series includes API for that, however, not the
    final implementation yet.

    The connections to the other devices on the platform the ports have
    can be described by using the remote endpoint concept [1][2] on ACPI
    and DT platforms, but I have no solution for the "platform data" case
    where we have neither DT nor ACPI to describe the connections for us.

    [1] Documentation/devicetree/bindings/graph.txt
    [2] Documentation/acpi/dsd/graph.txt


    Heikki Krogerus (3):
    usb: typec: Register a device for every mode
    usb: typec: Bus type for alternate modes
    usb: typec: tcpm: Support for Alternate Modes

    Documentation/ABI/obsolete/sysfs-class-typec | 48 +++
    Documentation/ABI/testing/sysfs-bus-typec | 51 ++++
    Documentation/ABI/testing/sysfs-class-typec | 62 +---
    Documentation/driver-api/usb/typec_bus.rst | 143 +++++++++
    drivers/usb/typec/Makefile | 2 +-
    drivers/usb/typec/bus.c | 421 ++++++++++++++++++++++++++
    drivers/usb/typec/bus.h | 37 +++
    drivers/usb/typec/class.c | 424 ++++++++++++++++++---------
    drivers/usb/typec/tcpm.c | 156 +++++++---
    include/linux/mod_devicetable.h | 15 +
    include/linux/usb/typec.h | 50 +---
    include/linux/usb/typec_altmode.h | 136 +++++++++
    scripts/mod/devicetable-offsets.c | 4 +
    scripts/mod/file2alias.c | 13 +
    14 files changed, 1285 insertions(+), 277 deletions(-)
    create mode 100644 Documentation/ABI/obsolete/sysfs-class-typec
    create mode 100644 Documentation/ABI/testing/sysfs-bus-typec
    create mode 100644 Documentation/driver-api/usb/typec_bus.rst
    create mode 100644 drivers/usb/typec/bus.c
    create mode 100644 drivers/usb/typec/bus.h
    create mode 100644 include/linux/usb/typec_altmode.h

    --
    2.16.1

    \
     
     \ /
      Last update: 2018-03-09 16:20    [W:3.122 / U:0.952 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site