* [RFC] Driver configuration using Device Tree
@ 2013-07-09 20:10 Eric Holmberg
[not found] ` <51DC6E52.3080102-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
0 siblings, 1 reply; 3+ messages in thread
From: Eric Holmberg @ 2013-07-09 20:10 UTC (permalink / raw)
To: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ; +Cc: kramasub-sgV2jX0FEOL9JmXXK+q4OQ
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC] Driver configuration using Device Tree
[not found] ` <51DC6E52.3080102-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
@ 2013-07-20 6:02 ` Grant Likely
2013-07-22 20:05 ` Eric Holmberg
0 siblings, 1 reply; 3+ messages in thread
From: Grant Likely @ 2013-07-20 6:02 UTC (permalink / raw)
To: Eric Holmberg, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ
Cc: kramasub-sgV2jX0FEOL9JmXXK+q4OQ
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC] Driver configuration using Device Tree
2013-07-20 6:02 ` Grant Likely
@ 2013-07-22 20:05 ` Eric Holmberg
0 siblings, 0 replies; 3+ messages in thread
From: Eric Holmberg @ 2013-07-22 20:05 UTC (permalink / raw)
To: Grant Likely; +Cc: devicetree, kramasub, mbohan
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-07-22 20:05 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-09 20:10 [RFC] Driver configuration using Device Tree Eric Holmberg
[not found] ` <51DC6E52.3080102-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2013-07-20 6:02 ` Grant Likely
2013-07-22 20:05 ` Eric Holmberg
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.