devel@lists.zephyrproject.org | Per-device-instance software configuration in devicetree

Home Messages Hashtags Subgroups

Date Date 1 - 6 of 6

Per-device-instance software configuration in devicetree

Bolivar, Marti #8456 Hi, Summary: This is a proposal for how to handle per-struct-device software configuration for Zephyr in devicetree. My goals are to: - summarize the problem and proposed solution - look for consensus or more feedback TL;DR: we propose zephyr-specific configuration should be allowed in devicetree, but in properties beginning with "zephyr,". Please read this if you need more context on DT than what I've written below: https://docs.zephyrproject.org/latest/build/dts/index.html Zephyr developers allocate individual 'struct device' instances using devicetree. They can also perform initial hardware configuration in devicetree. For example, developers can already configure things like bus devices, associated GPIOs, clock rates, line rates, etc. in the devicetree nodes that are used to allocate devices. For more details, watch my talk from ZDS 2021: https://www.youtube.com/watch?v=sWaxQyIgEBY However, there is no obvious place to configure software features that are associated with individual struct devices. This is a problem because developers need to do this, too. There's no obvious place because the contents of the devicetree are "supposed" to only be a description of the hardware and its initial configuration. Things like the sizes of buffers associated with a particular struct device don't fit those categories. For this reason, there's been resistance to putting per-device software configuration values into devicetree in the past. Unfortunately, we don't really have a good alternative to devicetree for this in Zephyr. Each 'struct device' is created from a devicetree node. The device instantiation macros have no other device-specific context at build time beyond the contents of that devicetree node. Since Zephyr drivers are generally statically allocated and configured, and the devicetree is the only build-time place to stash device-specific context, it really is the only place for this that we have now. And in fact, some software features are already being configured in devicetree. One example is in this PR: https://github.com/zephyrproject-rtos/zephyr/pull/43806/ Although the above PR is for a devicetree compatible that is already specific to zephyr, we want to be able to do similar types of configuration as properties in nodes that might also have bindings in the Linux kernel or other projects using devicetree. That is a problem because the namespace of properties associated with each devicetree compatible in a binding is shared among projects using devicetree. We want to try to avoid using property names in a Zephyr-specific way that might pose egregious source compatibility issues with other projects. This is important because DTS source compatibility with other operating systems is a design goal for our use of devicetree: https://docs.zephyrproject.org/latest/build/dts/design.html#source-compatibility-with-other-operating-systems As a compromise to avoid things getting out of control while still solving the problem, I'm proposing that all new values which are clearly software configuration for Zephyr may go into devicetree properties, but those properties must begin with "zephyr,". Examples: - you MAY NOT make a "foo-buffer-size" property - you MAY make a "zephyr,foo-buffer-size" property - you MAY NOT make a "work-queue-priority" property - you MAY make a "zephyr,work-queue-priority" property This keeps things clean by not clashing with property names that other devicetree users may add for the same compatibles. Kumar is on board with this proposal. The ship has already sailed on some cases, like the usb-audio-* related bindings here: https://docs.zephyrproject.org/latest/build/dts/api/bindings.html#generic-or-vendor-independent There's no proposal on the table right now to re-work those so they have a "zephyr," prefix. At this time, we're just talking about new bindings changes. Feedback and more discussion is welcome. Once this is resolved, I'll write up the results in the zephyr bindings documentation so it doesn't get lost, and will request that individual driver subsystem maintainers help enforce this. Thanks, Martí
More All Messages By This Member
Erwan Gouriou #8457 Hi Marti, This makes sense. Few years ago this proposal would have been turned down, as we wanted to stick with Linux practices. But I think today we have the necessary experience with device tree to consider this is the right thing for us to do. Erwan On Thu, 7 Apr 2022 at 19:23, Bolivar, Marti via lists.zephyrproject.org <marti.bolivar=nordicsemi.no@...> wrote: toggle quoted message Show quoted text Hi, Summary: This is a proposal for how to handle per-struct-device software configuration for Zephyr in devicetree. My goals are to: - summarize the problem and proposed solution - look for consensus or more feedback TL;DR: we propose zephyr-specific configuration should be allowed in devicetree, but in properties beginning with "zephyr,". Please read this if you need more context on DT than what I've written below: https://docs.zephyrproject.org/latest/build/dts/index.html Zephyr developers allocate individual 'struct device' instances using devicetree. They can also perform initial hardware configuration in devicetree. For example, developers can already configure things like bus devices, associated GPIOs, clock rates, line rates, etc. in the devicetree nodes that are used to allocate devices. For more details, watch my talk from ZDS 2021: https://www.youtube.com/watch?v=sWaxQyIgEBY However, there is no obvious place to configure software features that are associated with individual struct devices. This is a problem because developers need to do this, too. There's no obvious place because the contents of the devicetree are "supposed" to only be a description of the hardware and its initial configuration. Things like the sizes of buffers associated with a particular struct device don't fit those categories. For this reason, there's been resistance to putting per-device software configuration values into devicetree in the past. Unfortunately, we don't really have a good alternative to devicetree for this in Zephyr. Each 'struct device' is created from a devicetree node. The device instantiation macros have no other device-specific context at build time beyond the contents of that devicetree node. Since Zephyr drivers are generally statically allocated and configured, and the devicetree is the only build-time place to stash device-specific context, it really is the only place for this that we have now. And in fact, some software features are already being configured in devicetree. One example is in this PR: https://github.com/zephyrproject-rtos/zephyr/pull/43806/ Although the above PR is for a devicetree compatible that is already specific to zephyr, we want to be able to do similar types of configuration as properties in nodes that might also have bindings in the Linux kernel or other projects using devicetree. That is a problem because the namespace of properties associated with each devicetree compatible in a binding is shared among projects using devicetree. We want to try to avoid using property names in a Zephyr-specific way that might pose egregious source compatibility issues with other projects. This is important because DTS source compatibility with other operating systems is a design goal for our use of devicetree: https://docs.zephyrproject.org/latest/build/dts/design.html#source-compatibility-with-other-operating-systems As a compromise to avoid things getting out of control while still solving the problem, I'm proposing that all new values which are clearly software configuration for Zephyr may go into devicetree properties, but those properties must begin with "zephyr,". Examples: - you MAY NOT make a "foo-buffer-size" property - you MAY make a "zephyr,foo-buffer-size" property - you MAY NOT make a "work-queue-priority" property - you MAY make a "zephyr,work-queue-priority" property This keeps things clean by not clashing with property names that other devicetree users may add for the same compatibles. Kumar is on board with this proposal. The ship has already sailed on some cases, like the usb-audio-* related bindings here: https://docs.zephyrproject.org/latest/build/dts/api/bindings.html#generic-or-vendor-independent There's no proposal on the table right now to re-work those so they have a "zephyr," prefix. At this time, we're just talking about new bindings changes. Feedback and more discussion is welcome. Once this is resolved, I'll write up the results in the zephyr bindings documentation so it doesn't get lost, and will request that individual driver subsystem maintainers help enforce this. Thanks, Martí
More All Messages By This Member
Carles Cufi #8458 For completeness I’d also like to point to our current use of Devicetree to configure OpenAMP resources, a construct that is fundamentally software in nature. https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/bindings/ipc/zephyr%2Cipc-openamp-static-vrings.yaml Carles toggle quoted message Show quoted text From: devel@... <devel@...> On Behalf Of Erwan Gouriou via lists.zephyrproject.org Sent: 08 April 2022 15:09 To: Bolivar, Marti <Marti.Bolivar@...> Cc: devel@...; tomasz.bursztyka@...; kumar.gala@... Subject: Re: [Zephyr-devel] Per-device-instance software configuration in devicetree Hi Marti, This makes sense. Few years ago this proposal would have been turned down, as we wanted to stick with Linux practices. But I think today we have the necessary experience with device tree to consider this is the right thing for us to do. Erwan On Thu, 7 Apr 2022 at 19:23, Bolivar, Marti via lists.zephyrproject.org <marti.bolivar=nordicsemi.no@...> wrote: Hi, Summary: This is a proposal for how to handle per-struct-device software configuration for Zephyr in devicetree. My goals are to: - summarize the problem and proposed solution - look for consensus or more feedback TL;DR: we propose zephyr-specific configuration should be allowed in devicetree, but in properties beginning with "zephyr,". Please read this if you need more context on DT than what I've written below: https://docs.zephyrproject.org/latest/build/dts/index.html Zephyr developers allocate individual 'struct device' instances using devicetree. They can also perform initial hardware configuration in devicetree. For example, developers can already configure things like bus devices, associated GPIOs, clock rates, line rates, etc. in the devicetree nodes that are used to allocate devices. For more details, watch my talk from ZDS 2021: https://www.youtube.com/watch?v=sWaxQyIgEBY However, there is no obvious place to configure software features that are associated with individual struct devices. This is a problem because developers need to do this, too. There's no obvious place because the contents of the devicetree are "supposed" to only be a description of the hardware and its initial configuration. Things like the sizes of buffers associated with a particular struct device don't fit those categories. For this reason, there's been resistance to putting per-device software configuration values into devicetree in the past. Unfortunately, we don't really have a good alternative to devicetree for this in Zephyr. Each 'struct device' is created from a devicetree node. The device instantiation macros have no other device-specific context at build time beyond the contents of that devicetree node. Since Zephyr drivers are generally statically allocated and configured, and the devicetree is the only build-time place to stash device-specific context, it really is the only place for this that we have now. And in fact, some software features are already being configured in devicetree. One example is in this PR: https://github.com/zephyrproject-rtos/zephyr/pull/43806/ Although the above PR is for a devicetree compatible that is already specific to zephyr, we want to be able to do similar types of configuration as properties in nodes that might also have bindings in the Linux kernel or other projects using devicetree. That is a problem because the namespace of properties associated with each devicetree compatible in a binding is shared among projects using devicetree. We want to try to avoid using property names in a Zephyr-specific way that might pose egregious source compatibility issues with other projects. This is important because DTS source compatibility with other operating systems is a design goal for our use of devicetree: https://docs.zephyrproject.org/latest/build/dts/design.html#source-compatibility-with-other-operating-systems As a compromise to avoid things getting out of control while still solving the problem, I'm proposing that all new values which are clearly software configuration for Zephyr may go into devicetree properties, but those properties must begin with "zephyr,". Examples: - you MAY NOT make a "foo-buffer-size" property - you MAY make a "zephyr,foo-buffer-size" property - you MAY NOT make a "work-queue-priority" property - you MAY make a "zephyr,work-queue-priority" property This keeps things clean by not clashing with property names that other devicetree users may add for the same compatibles. Kumar is on board with this proposal. The ship has already sailed on some cases, like the usb-audio-* related bindings here: https://docs.zephyrproject.org/latest/build/dts/api/bindings.html#generic-or-vendor-independent There's no proposal on the table right now to re-work those so they have a "zephyr," prefix. At this time, we're just talking about new bindings changes. Feedback and more discussion is welcome. Once this is resolved, I'll write up the results in the zephyr bindings documentation so it doesn't get lost, and will request that individual driver subsystem maintainers help enforce this. Thanks, Martí
More All Messages By This Member
Simon Glass <sjg@...> #8460 Hi, I strongly agree with this approach. U-Boot has the same issue (no other way to provide config) and has quite a few software-related bindings. The idea of device tree only describing the hardware is out-of-date, IMO. See also the /options node: https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/options.yaml Regards, Simon toggle quoted message Show quoted text On Fri, 8 Apr 2022 at 07:14, Carles Cufi via lists.zephyrproject.org <carles.cufi=nordicsemi.no@...> wrote: For completeness I’d also like to point to our current use of Devicetree to configure OpenAMP resources, a construct that is fundamentally software in nature. https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/bindings/ipc/zephyr%2Cipc-openamp-static-vrings.yaml Carles From: devel@... <devel@...> On Behalf Of Erwan Gouriou via lists.zephyrproject.org Sent: 08 April 2022 15:09 To: Bolivar, Marti <Marti.Bolivar@...> Cc: devel@...; tomasz.bursztyka@...; kumar.gala@... Subject: Re: [Zephyr-devel] Per-device-instance software configuration in devicetree Hi Marti, This makes sense. Few years ago this proposal would have been turned down, as we wanted to stick with Linux practices. But I think today we have the necessary experience with device tree to consider this is the right thing for us to do. Erwan On Thu, 7 Apr 2022 at 19:23, Bolivar, Marti via lists.zephyrproject.org <marti.bolivar=nordicsemi.no@...> wrote: Hi, Summary: This is a proposal for how to handle per-struct-device software configuration for Zephyr in devicetree. My goals are to: - summarize the problem and proposed solution - look for consensus or more feedback TL;DR: we propose zephyr-specific configuration should be allowed in devicetree, but in properties beginning with "zephyr,". Please read this if you need more context on DT than what I've written below: https://docs.zephyrproject.org/latest/build/dts/index.html Zephyr developers allocate individual 'struct device' instances using devicetree. They can also perform initial hardware configuration in devicetree. For example, developers can already configure things like bus devices, associated GPIOs, clock rates, line rates, etc. in the devicetree nodes that are used to allocate devices. For more details, watch my talk from ZDS 2021: https://www.youtube.com/watch?v=sWaxQyIgEBY However, there is no obvious place to configure software features that are associated with individual struct devices. This is a problem because developers need to do this, too. There's no obvious place because the contents of the devicetree are "supposed" to only be a description of the hardware and its initial configuration. Things like the sizes of buffers associated with a particular struct device don't fit those categories. For this reason, there's been resistance to putting per-device software configuration values into devicetree in the past. Unfortunately, we don't really have a good alternative to devicetree for this in Zephyr. Each 'struct device' is created from a devicetree node. The device instantiation macros have no other device-specific context at build time beyond the contents of that devicetree node. Since Zephyr drivers are generally statically allocated and configured, and the devicetree is the only build-time place to stash device-specific context, it really is the only place for this that we have now. And in fact, some software features are already being configured in devicetree. One example is in this PR: https://github.com/zephyrproject-rtos/zephyr/pull/43806/ Although the above PR is for a devicetree compatible that is already specific to zephyr, we want to be able to do similar types of configuration as properties in nodes that might also have bindings in the Linux kernel or other projects using devicetree. That is a problem because the namespace of properties associated with each devicetree compatible in a binding is shared among projects using devicetree. We want to try to avoid using property names in a Zephyr-specific way that might pose egregious source compatibility issues with other projects. This is important because DTS source compatibility with other operating systems is a design goal for our use of devicetree: https://docs.zephyrproject.org/latest/build/dts/design.html#source-compatibility-with-other-operating-systems As a compromise to avoid things getting out of control while still solving the problem, I'm proposing that all new values which are clearly software configuration for Zephyr may go into devicetree properties, but those properties must begin with "zephyr,". Examples: - you MAY NOT make a "foo-buffer-size" property - you MAY make a "zephyr,foo-buffer-size" property - you MAY NOT make a "work-queue-priority" property - you MAY make a "zephyr,work-queue-priority" property This keeps things clean by not clashing with property names that other devicetree users may add for the same compatibles. Kumar is on board with this proposal. The ship has already sailed on some cases, like the usb-audio-* related bindings here: https://docs.zephyrproject.org/latest/build/dts/api/bindings.html#generic-or-vendor-independent There's no proposal on the table right now to re-work those so they have a "zephyr," prefix. At this time, we're just talking about new bindings changes. Feedback and more discussion is welcome. Once this is resolved, I'll write up the results in the zephyr bindings documentation so it doesn't get lost, and will request that individual driver subsystem maintainers help enforce this. Thanks, Martí
More
Benjamin Lindqvist #8461 Hi, Enforcing "zephyr," suffix is a great idea given that software config is allowed in the dts - the one grievance I have is that using dts overlays for configuration purposes isn't great UX. It's not very welcoming first of all, but it's also harder to control during build time (Kconfigs can be selected/defaulted by both new custom Kconfigs and is also more easily controllable via CMake and other build scripts). Perhaps some form of dts overlay inlet that is easily accessible via CMake could be constructed? I.e. just a wrapper for conditionally activating overlays that is easier to work with than creating a bunch of files in your project root. I don't think the idea is bad without this feature - just throwing out a potential UX improvement out there :) Best, Ben toggle quoted message Show quoted text On Sun, Apr 10, 2022 at 7:49 PM Simon Glass <sjg@...> wrote: Hi, I strongly agree with this approach. U-Boot has the same issue (no other way to provide config) and has quite a few software-related bindings. The idea of device tree only describing the hardware is out-of-date, IMO. See also the /options node: https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/options.yaml Regards, Simon On Fri, 8 Apr 2022 at 07:14, Carles Cufi via lists.zephyrproject.org <carles.cufi=nordicsemi.no@...> wrote: For completeness I’d also like to point to our current use of Devicetree to configure OpenAMP resources, a construct that is fundamentally software in nature. https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/bindings/ipc/zephyr%2Cipc-openamp-static-vrings.yaml Carles From: devel@... <devel@...> On Behalf Of Erwan Gouriou via lists.zephyrproject.org Sent: 08 April 2022 15:09 To: Bolivar, Marti <Marti.Bolivar@...> Cc: devel@...; tomasz.bursztyka@...; kumar.gala@... Subject: Re: [Zephyr-devel] Per-device-instance software configuration in devicetree Hi Marti, This makes sense. Few years ago this proposal would have been turned down, as we wanted to stick with Linux practices. But I think today we have the necessary experience with device tree to consider this is the right thing for us to do. Erwan On Thu, 7 Apr 2022 at 19:23, Bolivar, Marti via lists.zephyrproject.org <marti.bolivar=nordicsemi.no@...> wrote: Hi, Summary: This is a proposal for how to handle per-struct-device software configuration for Zephyr in devicetree. My goals are to: - summarize the problem and proposed solution - look for consensus or more feedback TL;DR: we propose zephyr-specific configuration should be allowed in devicetree, but in properties beginning with "zephyr,". Please read this if you need more context on DT than what I've written below: https://docs.zephyrproject.org/latest/build/dts/index.html Zephyr developers allocate individual 'struct device' instances using devicetree. They can also perform initial hardware configuration in devicetree. For example, developers can already configure things like bus devices, associated GPIOs, clock rates, line rates, etc. in the devicetree nodes that are used to allocate devices. For more details, watch my talk from ZDS 2021: https://www.youtube.com/watch?v=sWaxQyIgEBY However, there is no obvious place to configure software features that are associated with individual struct devices. This is a problem because developers need to do this, too. There's no obvious place because the contents of the devicetree are "supposed" to only be a description of the hardware and its initial configuration. Things like the sizes of buffers associated with a particular struct device don't fit those categories. For this reason, there's been resistance to putting per-device software configuration values into devicetree in the past. Unfortunately, we don't really have a good alternative to devicetree for this in Zephyr. Each 'struct device' is created from a devicetree node. The device instantiation macros have no other device-specific context at build time beyond the contents of that devicetree node. Since Zephyr drivers are generally statically allocated and configured, and the devicetree is the only build-time place to stash device-specific context, it really is the only place for this that we have now. And in fact, some software features are already being configured in devicetree. One example is in this PR: https://github.com/zephyrproject-rtos/zephyr/pull/43806/ Although the above PR is for a devicetree compatible that is already specific to zephyr, we want to be able to do similar types of configuration as properties in nodes that might also have bindings in the Linux kernel or other projects using devicetree. That is a problem because the namespace of properties associated with each devicetree compatible in a binding is shared among projects using devicetree. We want to try to avoid using property names in a Zephyr-specific way that might pose egregious source compatibility issues with other projects. This is important because DTS source compatibility with other operating systems is a design goal for our use of devicetree: https://docs.zephyrproject.org/latest/build/dts/design.html#source-compatibility-with-other-operating-systems As a compromise to avoid things getting out of control while still solving the problem, I'm proposing that all new values which are clearly software configuration for Zephyr may go into devicetree properties, but those properties must begin with "zephyr,". Examples: - you MAY NOT make a "foo-buffer-size" property - you MAY make a "zephyr,foo-buffer-size" property - you MAY NOT make a "work-queue-priority" property - you MAY make a "zephyr,work-queue-priority" property This keeps things clean by not clashing with property names that other devicetree users may add for the same compatibles. Kumar is on board with this proposal. The ship has already sailed on some cases, like the usb-audio-* related bindings here: https://docs.zephyrproject.org/latest/build/dts/api/bindings.html#generic-or-vendor-independent There's no proposal on the table right now to re-work those so they have a "zephyr," prefix. At this time, we're just talking about new bindings changes. Feedback and more discussion is welcome. Once this is resolved, I'll write up the results in the zephyr bindings documentation so it doesn't get lost, and will request that individual driver subsystem maintainers help enforce this. Thanks, Martí
More All Messages By This Member
Bolivar, Marti #8832 Hi again, I'm necroposting because I finally got around to documenting this as part of a larger DT docs PR: https://github.com/zephyrproject-rtos/zephyr/pull/53727 See this commit if you are still interested in this conversation: doc: dts: document zephyr, prefix for props/compats Thanks, Martí toggle quoted message Show quoted text From: Bolivar, Marti <Marti.Bolivar@...> Sent: Thursday, April 7, 2022 10:23 AM To: devel@... <devel@...>; tomasz.bursztyka@... <tomasz.bursztyka@...>; kumar.gala@... <kumar.gala@...> Subject: Per-device-instance software configuration in devicetree Hi, Summary: This is a proposal for how to handle per-struct-device software configuration for Zephyr in devicetree. My goals are to: - summarize the problem and proposed solution - look for consensus or more feedback TL;DR: we propose zephyr-specific configuration should be allowed in devicetree, but in properties beginning with "zephyr,". Please read this if you need more context on DT than what I've written below: https://docs.zephyrproject.org/latest/build/dts/index.html Zephyr developers allocate individual 'struct device' instances using devicetree. They can also perform initial hardware configuration in devicetree. For example, developers can already configure things like bus devices, associated GPIOs, clock rates, line rates, etc. in the devicetree nodes that are used to allocate devices. For more details, watch my talk from ZDS 2021: https://www.youtube.com/watch?v=sWaxQyIgEBY However, there is no obvious place to configure software features that are associated with individual struct devices. This is a problem because developers need to do this, too. There's no obvious place because the contents of the devicetree are "supposed" to only be a description of the hardware and its initial configuration. Things like the sizes of buffers associated with a particular struct device don't fit those categories. For this reason, there's been resistance to putting per-device software configuration values into devicetree in the past. Unfortunately, we don't really have a good alternative to devicetree for this in Zephyr. Each 'struct device' is created from a devicetree node. The device instantiation macros have no other device-specific context at build time beyond the contents of that devicetree node. Since Zephyr drivers are generally statically allocated and configured, and the devicetree is the only build-time place to stash device-specific context, it really is the only place for this that we have now. And in fact, some software features are already being configured in devicetree. One example is in this PR: https://github.com/zephyrproject-rtos/zephyr/pull/43806/ Although the above PR is for a devicetree compatible that is already specific to zephyr, we want to be able to do similar types of configuration as properties in nodes that might also have bindings in the Linux kernel or other projects using devicetree. That is a problem because the namespace of properties associated with each devicetree compatible in a binding is shared among projects using devicetree. We want to try to avoid using property names in a Zephyr-specific way that might pose egregious source compatibility issues with other projects. This is important because DTS source compatibility with other operating systems is a design goal for our use of devicetree: https://docs.zephyrproject.org/latest/build/dts/design.html#source-compatibility-with-other-operating-systems As a compromise to avoid things getting out of control while still solving the problem, I'm proposing that all new values which are clearly software configuration for Zephyr may go into devicetree properties, but those properties must begin with "zephyr,". Examples: - you MAY NOT make a "foo-buffer-size" property - you MAY make a "zephyr,foo-buffer-size" property - you MAY NOT make a "work-queue-priority" property - you MAY make a "zephyr,work-queue-priority" property This keeps things clean by not clashing with property names that other devicetree users may add for the same compatibles. Kumar is on board with this proposal. The ship has already sailed on some cases, like the usb-audio-* related bindings here: https://docs.zephyrproject.org/latest/build/dts/api/bindings.html#generic-or-vendor-independent There's no proposal on the table right now to re-work those so they have a "zephyr," prefix. At this time, we're just talking about new bindings changes. Feedback and more discussion is welcome. Once this is resolved, I'll write up the results in the zephyr bindings documentation so it doesn't get lost, and will request that individual driver subsystem maintainers help enforce this. Thanks, Martí
More All Messages By This Member

1 - 6 of 6

1

Previous Topic Next Topic

Home Hashtags Subgroups Terms