I am trying to determine if Device Tree is an appropriate use for
configuring drivers and would like to request comments. We currently
use Device Tree in our Shared Memory Driver (SMD) that manages up to 64
ports (where a port consists of an RX FIFO and a TX FIFO) between any
two processors and a pair of interrupts for each processor. The shared
memory address and interrupt configuration is stored in Device Tree and
since this is hardware, this is considered an acceptable use. However,
we also have two separate modules that use SMD and export devices to
userspace through either the TTY framework (SMD TTY) or through a
character device (SMD PKT). For these drivers, the configuration has
less to do with hardware and more about which port to connect to in the
SMD driver and how to expose the port to userspace through a device
node. This code is used in Linux-based phones.
The DT configuration looks like this:
qcom,smdtty {
compatible = "qcom,smdtty";
qcom,smdtty-ds {
qcom,smdtty-port-name = "DS";
qcom,smdtty-edge = <0>;
qcom,smdtty-dev-idx = <0>;
};
. . .
/* on the order of 10 more port config items */
};
Question
--------
Is there a concern that DT should only be used for hardware
configuration and that this "driver configuration" is not an acceptable
use? If it is not acceptable, should I go back to using platform
devices (seems like a step backwards) or some other method such as
exporting a control channel to userspace that can be configured using an
IOCTL?
More Detailed Background Information
------------------------------------
Here’s a diagram showing the modules to help visualize the system.
+-------------------------------+
| |
| SMD Userspace Clients |
| |
+-------------------------------+
User space ^ ^
+-------------------------|--------------|----------------------+
Kernel space + +
+--------------------------+
| Linux Virtual File Sys |
| |
+--------------------------+
^ ^
| |
| +---------------+
| | Linux |
| | TTY Framework |
| +---------------+
| ^
| |
+---------+ | | +---------+
| DT | +-----------+ +-----------+ | DT |
| Config |+---->| SMD | | SMD |<-------+| Config |
| | | PKT | | TTY | | |
+---------+ +-----------+ +-----------+ +---------+
| |
| |
v |
O <------------+
|
+---------+ |
| DT | +------------------------+
| Config |+---->| SMD |
| | | |
+---------+ +------------------------+
| ^ |
| | |
| | |
| | |
| | |
| | |
v | |
+--------------------+ | |Interrupts
| | | |
| Shared Memory | | |
| | | |
+---------+----------+ | |
| | |
| | |
| | |
| | |
| | |
| | |
v | v
+-----------------------------------+
| |
| Remote System (Modem, etc) |
| |
+-----------------------------------+
Here’s an example of our DT schema. Each SMD channel is uniquely
identified in the system by the NAME:EDGE, so this is included in the
configuration along with the index or name of the device node to export
to userspace (either a TTY device for streaming-mode data or a character
device for packet-mode data).
[Root level node]
Required properties:
-compatible: should be "qcom,smdtty"
[Second level nodes]
qcom,smdtty-port-names
Required properties:
-qcom,smdtty-port-name: the name that identifies the smd channel
-qcom,smdtty-edge: the smd edge (this is an enumeration that
identifies the local<->remote processor edge)
-qcom,smdtty-dev-idx: the device node index
Example:
qcom,smdtty {
compatible = "qcom,smdtty";
qcom,smdtty-ds {
qcom,smdtty-port-name = "DS";
qcom,smdtty-edge = <0>;
qcom,smdtty-dev-name = <0>;
};
qcom,smdtty-apps-fm {
qcom,smdtty-port-name = "APPS_FM";
qcom,smdtty-edge = <6>;
qcom,smdtty-dev-name = <1>;
};
qcom,smdtty-gpsnmea {
qcom,smdtty-port-name = "GPSNMEA";
qcom,smdtty-edge = <0>;
qcom,smdtty-dev-name = <27>;
};
};
Thanks,
Eric Holmberg
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation.
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
