Driver configuration using Device Tree
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
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation.
Quoted 28 lines · Eric Holmberg
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 */ };
Quoted 8 lines
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?
It still is a reasonable leap to say that the DT contains the known-sane configuration settings that are needed by the platform. It may not be /strictly/ a hardware description, but it is a description of the usage model of the platform.
I would however say that you only want that configuration to appear once in the system. If, say, the linux host sets up and configures the SMD regions, then I would like to see the remote systems dynamically receiving the configuration from the linux host instead of having a separate configuration file.
g.
Quoted 38 lines · Grant Likely
Quoted 28 lines · Eric Holmberg
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 */ };Quoted 8 lines
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?
Quoted 4 lines
It still is a reasonable leap to say that the DT contains the known-sane configuration settings that are needed by the platform. It may not be /strictly/ a hardware description, but it is a description of the usage model of the platform.
That's a good, practical interpretation. In particular, I feel that the "description of the usage model of the platform" hits the nail on the head for this use case.
Quoted 9 lines
I would however say that you only want that configuration to appear once in the system. If, say, the linux host sets up and configures the SMD regions, then I would like to see the remote systems dynamically receiving the configuration from the linux host instead of having a separate configuration file.
g.
The DT configuration for SMD itself just covers the shared memory addresses and interrupt configuration. The SMD regions/channels are dynamically configured using tables in shared memory, so that should address your system-level duplication of configuration concern at the level of SMD itself.
At the level of SMD TTY and SMD PKT, these drivers are just exporting the SMD kernel API to userspace through either a TTY device or a character device. Since this driver topology is OS-specific, each OS should have its own local configuration. I think this addresses your system-level duplication of configuration concern at the level of SMD TTY and SMD PKT.
It sounds like the configuration presented here for SMD TTY and SMD PKT using DT is acceptable since it is a description of the usage model of the platform and there is no duplicate of configuration throughout the system. We can always change it in the future if other configuration options show up that are a better fit.
Thanks,
Eric Holmberg
Signature · 1 line
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation.