[RFC] Driver configuration using Device Tree

[RFC] Driver configuration using Device Tree

[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 */
       };


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.

Re: [RFC] Driver configuration using Device Tree

[Grant Likely]

On Tue, 09 Jul 2013 14:10:58 -0600, Eric Holmberg <eholmber-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> 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?

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.

Re: [RFC] Driver configuration using Device Tree

[Eric Holmberg]

On 7/20/2013 12:02 AM, Grant Likely wrote:
> On Tue, 09 Jul 2013 14:10:58 -0600, Eric Holmberg <eholmber@codeaurora.org> wrote:
>> 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?
>
> 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.

>
> 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
-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation.